Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Shepherd 1.0.0 released

guix.gnu.org

Post reply on HN
Print view View original

41–50 of 58 posts

Re: The Shepherd 1.0.0 released

#41

Post by davexunit »

NeutralForest wrote: post #29
paroneayea wrote: post #23

Earlier quoted context omitted.

It may be possible to get Shepherd to work with Hoot eventually! I'm not sure what on earth it would mean though. What daemons would you manage in the browser? But it's indeed a fun idea!

If you could configure a fleet of machines from a browser window, over the network; that would be pretty cool. No clue how that would work in practice here though.

Since everything would be speaking OCapN you could use the browser interface as a convenient command center. This idea is becoming quite appealing to me actually... would be cool to have a little dashboard showing the health of my servers and be able to restart a failed service if I needed to.

Re: The Shepherd 1.0.0 released

#42

Post by davexunit »

jauntywundrkind wrote: post #30
dannyobrien wrote: post #22

Earlier quoted context omitted.

Amusingly enough, the main direction Shepherd is exploring right now is integrating Spritely Goblins (the folks that are also writing Hoot), so that it would have a distributed, capability-based process manager. I wouldn't say running Shepherd with Hoot is a direct goal of this, but it may fall out naturally from it. Shepherd may actually work in Hoot right now -- I know the Spritely team were working on getting Guil…

Wow, that's a very fun reply! Nice. Fingers crossed that the Stack Switching spec gets adopted & serves Guile Hoot's needs for fibers. https://github.com/WebAssembly/stack-switching

Stack switching in wasm would be great (as long as they aren't nerfed which they might be!) but note that Hoot has fibers right now: https://gitlab.com/spritely/guile-hoot/-/tree/main/lib/fiber...

Re: The Shepherd 1.0.0 released

#43

Post by xelxebar »

skulk wrote: post #25
davexunit wrote: post #16

Shepherd is a wonderful little service manager. The project has been integrating the good features of systemd (socket activation, timers, etc.) while retaining the hackability of using a fully featured programming language for configuration. Been happily using it with Guix for over a decade! NLnet has funded a really cool project to turn Shepherd into a distributed system that enables a fleet of Shepherds to cooperat…

You've been using Guix for over a decade? Is there somewhere I can read more about your experience? I think Guix is a cooler version of nix but I've been put off by the lack of packages and smaller community.

Not OP, but I've been daily driving Guix for about 5 years now quite happily. The biggest paint point with vanilla Guix is probably a lack of non-libre packages, especially the linux-libre kernel which strips out blobs. However, the nonguix [1] channel handily fills that hole, and there is first-class support for running a Nix daemon service [0] to cover anything not in nonguix.

Guix documentation is top notch, and it's really nice having all that available locally as texinfo pages. For writing packages yourself, I've found the Guix source to be eminently more greppable than Nix, which eases the dev onramp.

Nix's daemon is definitely more performant than Guix's, so equivalent operations will usually be quite a bit slower in Guix, but on the whole I'd say that Guix's more cohesive design makes the system more pleasant to work with.

Happy to help if you have any specific questions!

[0] https://guix.gnu.org/manual/en/guix.html#Nix-service

[1] https://gitlab.com/nonguix/nonguix/

Re: The Shepherd 1.0.0 released

#44

Post by rmgk »

uludag wrote: post #7
danudey wrote: post #2

Taking a quick look at this, the first thing I notice is that the configuration file syntax is obtuse and nigh-illegible unless you already know what things are, and even then it's cumbersome and looks frustrating to write. e.g. instead of systemd's simple: Exec=/path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g We have this mess: #:start (make-forkexec-constructor (list "…/bin/ntpd" "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd"…

I think this may be just due to unfamiliarity. Like, if that mess you shared was written as follows: { start: makeForkexecConstructor(["…/bin/ntpd", "-n", "-c", "/…/…-ntpd.conf", "-u", "ntpd", "-g"]), logFile: "/var/log/ntpd.log" } this wouldn't bat an eye. Even though I've never used Guile, just familiarity with Elisp makes that example pretty straightforward. Lisp-adjacent people would all pretty quickly grok this…

I don’t think this is about lisp syntax.

The systemd variant uses one of the universal DSLs for key-value pairs (key=value) and the universal DSL for calling programs (program name, space separated list of arguments).

The latter is even the same syntax that lisp uses for functions calls – thus I would argue the systemd config file looks more like a lisp program than the Guix version does.

As a person that has seen a reasonable amount of sexpression, this is what I would not bat an eye at:

(start /path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g)

Re: The Shepherd 1.0.0 released

#45

Post by skulk »

xelxebar wrote: post #43
skulk wrote: post #25

Earlier quoted context omitted.

You've been using Guix for over a decade? Is there somewhere I can read more about your experience? I think Guix is a cooler version of nix but I've been put off by the lack of packages and smaller community.

Not OP, but I've been daily driving Guix for about 5 years now quite happily. The biggest paint point with vanilla Guix is probably a lack of non-libre packages, especially the linux-libre kernel which strips out blobs. However, the nonguix [1] channel handily fills that hole, and there is first-class support for running a Nix daemon service [0] to cover anything not in nonguix. Guix documentation is top notch, and i…

(I know I could just RTFM but since you offered!) Does it do something like NixOS for declaring modules as functions and resolving the configuration as a fixed point of all module function applications (roughly, I don't think I'm describing it well)? This is a beautifully elegant way of defining configuration-with-options using lazy evaluation but it often leads to headaches like infinite recursion. Since Guile is not a lazy language I wonder how it achieves this.

Re: The Shepherd 1.0.0 released

#46

Post by qazxcvbnm »

skulk wrote: post #45
xelxebar wrote: post #43

Earlier quoted context omitted.

Not OP, but I've been daily driving Guix for about 5 years now quite happily. The biggest paint point with vanilla Guix is probably a lack of non-libre packages, especially the linux-libre kernel which strips out blobs. However, the nonguix [1] channel handily fills that hole, and there is first-class support for running a Nix daemon service [0] to cover anything not in nonguix. Guix documentation is top notch, and i…

(I know I could just RTFM but since you offered!) Does it do something like NixOS for declaring modules as functions and resolving the configuration as a fixed point of all module function applications (roughly, I don't think I'm describing it well)? This is a beautifully elegant way of defining configuration-with-options using lazy evaluation but it often leads to headaches like infinite recursion. Since Guile is no…

I don’t know how Guile does this, but note that finding a fixed point does not generally require a lazy language; you just can’t do it naively — you can still take a bunch of functions that act on a config and ‘while (changing) keep applying’ — equivalently, the Y combinator can’t be evaluated strictly to get your fixed points, but the Z combinator can.

Re: The Shepherd 1.0.0 released

#47

Post by Pay08 »

skulk wrote: post #45
xelxebar wrote: post #43

Earlier quoted context omitted.

Not OP, but I've been daily driving Guix for about 5 years now quite happily. The biggest paint point with vanilla Guix is probably a lack of non-libre packages, especially the linux-libre kernel which strips out blobs. However, the nonguix [1] channel handily fills that hole, and there is first-class support for running a Nix daemon service [0] to cover anything not in nonguix. Guix documentation is top notch, and i…

(I know I could just RTFM but since you offered!) Does it do something like NixOS for declaring modules as functions and resolving the configuration as a fixed point of all module function applications (roughly, I don't think I'm describing it well)? This is a beautifully elegant way of defining configuration-with-options using lazy evaluation but it often leads to headaches like infinite recursion. Since Guile is no…

In all honesty, I don't know what that means, but the way Guix does configuration is with the Lisp equivalent of a builder pattern, which ends up looking quite like a key-value store.

(foo-configuration (bar-property baz-value) ...)

Re: The Shepherd 1.0.0 released

#48

Post by Pay08 »

rmgk wrote: post #44
uludag wrote: post #7

Earlier quoted context omitted.

I think this may be just due to unfamiliarity. Like, if that mess you shared was written as follows: { start: makeForkexecConstructor(["…/bin/ntpd", "-n", "-c", "/…/…-ntpd.conf", "-u", "ntpd", "-g"]), logFile: "/var/log/ntpd.log" } this wouldn't bat an eye. Even though I've never used Guile, just familiarity with Elisp makes that example pretty straightforward. Lisp-adjacent people would all pretty quickly grok this…

I don’t think this is about lisp syntax. The systemd variant uses one of the universal DSLs for key-value pairs (key=value) and the universal DSL for calling programs (program name, space separated list of arguments). The latter is even the same syntax that lisp uses for functions calls – thus I would argue the systemd config file looks more like a lisp program than the Guix version does. As a person that has seen a…

It is also strictly less powerful because of that, often needing to launch bash scripts instead of the programs directly.

Re: The Shepherd 1.0.0 released

#49

Post by Pay08 »

ebilgenius wrote: post #36
uludag wrote: post #7

Earlier quoted context omitted.

I think this may be just due to unfamiliarity. Like, if that mess you shared was written as follows: { start: makeForkexecConstructor(["…/bin/ntpd", "-n", "-c", "/…/…-ntpd.conf", "-u", "ntpd", "-g"]), logFile: "/var/log/ntpd.log" } this wouldn't bat an eye. Even though I've never used Guile, just familiarity with Elisp makes that example pretty straightforward. Lisp-adjacent people would all pretty quickly grok this…

While I agree it's hard to claim one is outright better than the other and there are a lot of factors that go into it, I do feel it's important to toss my chip in as someone who's not familiar with Lisp, Scheme, or any other functional language that I find it's syntax and layout particularly difficult to parse, let alone get started with compared to say, the INI-inspired systemd conf files. I can detail why but the m…

This is very basic Scheme syntax (plus Guile's keyword argument extension), nothing advanced and definitely not all of Scheme.

Re: The Shepherd 1.0.0 released

#50

Post by Pay08 »

zamalek wrote: post #35
danudey wrote: post #2

Taking a quick look at this, the first thing I notice is that the configuration file syntax is obtuse and nigh-illegible unless you already know what things are, and even then it's cumbersome and looks frustrating to write. e.g. instead of systemd's simple: Exec=/path/to/ntpd -n -c /etc/ntpd.conf -u ntpd -g We have this mess: #:start (make-forkexec-constructor (list "…/bin/ntpd" "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd"…

> NIH syndrome I would be using nonGuix if it booted on my machine (libre seemingly has its claws too deep), instead of Nix, precisely because Guix has far less NIH: Nix is homegrown everything. Guile was a pre-existing project (for both Guix and The Shepherd), for a pre-existing language family.

If you ever want to return to it, the nonguix ISO can be notoriously buggy. A better approach is to use the normal Guix ISO with an ethernet cable during installation and while setting up nonguix and your drivers.
Post reply on HN