[HN Gopher] The Shepherd 1.0.0 released
___________________________________________________________________
The Shepherd 1.0.0 released
Author : sharpshadow
Score : 131 points
Date : 2025-01-14 16:07 UTC (6 hours ago)
(HTM) web link (guix.gnu.org)
(TXT) w3m dump (guix.gnu.org)
| danudey wrote:
| 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" "-g")
| #:log-file "/var/log/ntpd.log")
|
| They say you don't need to be an expert on guile scheme to build
| a service file, but it does seem as though you need to know
| things like what `'(ntpd)` means, which I assumed was some kind
| of identifier literal, and it seems to be what's called a 'data
| literal' in scheme, but I had to google to discover that since
| the actual guile scheme documentation didn't seem to explain that
| syntax at all.
|
| I get that there are benefits to being able to do more advanced
| scripting in a service file, but this seems like a classic
| example of programmers writing things for programmers and not for
| users (or at least, not for users who don't 'get it').
|
| Going to chalk this up as another 'GNU reimplemented something
| badly because of NIH syndrome' incident and move on.
| teddyh wrote:
| > _the actual guile scheme documentation didn 't seem to
| explain that syntax at all._ (quote data)
| 'data
|
| Quoting is used to obtain a literal symbol (instead of a
| variable reference), a literal list (instead of a function
| call), or a literal vector. ' is simply a shorthand for a quote
| form. For example, 'x = x
| '(1 2 3) = (1 2 3) '#(1 (2 3) 4) = #(1
| (2 3) 4) (quote x) = x (quote (1 2 3))
| = (1 2 3) (quote #(1 (2 3) 4)) = #(1 (2 3) 4)
|
| Note that an application must not attempt to modify literal
| lists or vectors obtained from a quote form, since they may be
| in read-only memory.
|
| -- <https://www.gnu.org/software/guile/manual/html_node/Express
| i...>
| blueflow wrote:
| I vaguely learned lisp years ago and i already prefer the guile
| scheme over systemd - guile correctly takes an argument vector
| instead of a command string which needs to be split using some
| obtuse shell quoting rules.
|
| Having the shell taken out of the equation is what Lennart
| promised but never delivered.
| f1shy wrote:
| The system is integrated into Guix, so makes sense to use s-exp
| for the configuration.
|
| Systemd has done things that previously were trivial very
| difficult. I would like to know how it fares in that arena. The
| syntax can just be learned.
| uludag wrote:
| 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 presume.
|
| And I think it's also hard to claim that one is _better_ than
| the other. I personally have gotten my feet wet with Guix and I
| would love the time to become more familiar it.
| packetlost wrote:
| Eh, I'm a Schemer (not Guile though) but the above is
| dramatically less readable and, at a glance, understandable
| than the equivalent systemd .target file. The problem with
| Lisps (but _especially_ Schemes) is there 's magic everywhere
| that makes no sense without having a sizeable context of the
| program you're working in.
| Bootvis wrote:
| IMO in this example there seems too be to little magic.
| yencabulator wrote:
| I would _definitely_ bat an eye at "make fork exec
| constructor", regardless of what syntax sugar you sprinkle on
| that abomination.
| vvillena wrote:
| You don't have to be an expert, but knowing the basics of Lisp
| helps. The full definition of the example "ntpd" service is
| clear to read.
|
| > the actual guile scheme documentation didn't seem to explain
| that syntax at all
|
| It does, here:
| https://www.gnu.org/software/guile/manual/html_node/Expressi...
|
| It's a basic concept of Lisp. Everything is evaluated, unless
| quoted. Code is data is code!
| baq wrote:
| > Code is data is code!
|
| Which nowadays is 'yaml is code is yaml is code is yaml' in
| the devops world. The wheel turns.
| nine_k wrote:
| ...only with more parsing gotchas :(
| davexunit wrote:
| I tell ya, it was sometimes difficult to be a lisp guy
| doing devops full-time.
| baq wrote:
| Guile has been the scripting language of choice for GNU before
| the Internet was called Internet. It hasn't even been disliked,
| it's been simply ignored, for the most part.
| kstrauser wrote:
| I know that's true, having heard it talked about a lot over
| the years. But why, though? What is it about Guile that made
| GNU pick it over CL or Scheme (or TCL or Lua or...)?
|
| NM, answered my own question. It's literally Scheme.
| NeutralForest wrote:
| I mean, they're pretty much the same right? You can't abstract
| away the services and you need to pass arguments to the
| executable (ntpd in this case).
|
| I don't see more or fewer issues, but I also don't see the
| value to using Scheme instead of a conf. file like format.
|
| At the end, there's talk about adding the possibility to live
| reconfigure services, which is pretty cool but I don't really
| see what kind of users are targeted by that use-case, at least
| not regular users like me who's running Linux on a single
| laptop.
|
| The link at the end (https://spritely.institute/news/spritely-
| nlnet-grants-decemb...) is IMO much more interesting since it
| would make it possible to orchestrate several machines and
| their services as well. If you have live reloading as well, I
| think it would make for good developer experience.
|
| My main gripe with Guile is its ergonomics and tooling: no LSP,
| no linter, no step-debugger that I know of and the docs are
| often unhelpful imo.
|
| Maybe I'm not Scheme brained enough but I think it's a shame
| because there are some really cool projects out there (anything
| https://spritely.institute/ really).
|
| P.S: I know that some people will tell me to get used to REPL
| based development which I think is fine for small-ish projects
| but I can't understand the flow one uses for larger projects
| where many components might need to talk to each other.
| n8henrie wrote:
| Interesting take. As a hobbyist, I get special characters and
| escapes wrong in systemd all the time, because they try to look
| like regular shell but aren't. And systemd-escape (or whatever
| it's called) just makes an ugly mess that makes it hard for me
| to read.
|
| I don't know lisp, but the idea of having each argument be part
| of a list (kind of like launchd's xml format) resonates with
| me.
| IshKebab wrote:
| To be fair the Guile one is properly quoted and specifies the
| log file. make-forkexec-constructor is a really terrible name
| though, and Guile is a poor choice.
| choobacker wrote:
| I agree systemd's is easier to understand, and I'm a happy
| systemd user.
|
| But some of Shepherd's strengths are in other examples, and it
| makes sense to evaluate the whole.
|
| A few examples:
|
| * if we want multiple similar services, I'd prefer writing a
| Guile function than using systemd templates.
|
| * the above Shepherd guile code lives lexically alongside your
| wider Guix guile code. AST-aware syntax highlighting and
| refactoring tools would treat them the same. That's pretty neat
| and beats having two different languages. Guix calls this
| g-expressions.
|
| This "one language for all your system" is pretty compelling,
| but Guix's feature set is a bit too far behind NixOS at the
| moment for me.
| mmstr wrote:
| For those that don't know, GNU Shepherd is an init system (like
| systemd) written in Guile (a LISP), the unit files are written
| with Guile too.
| k3vinw wrote:
| That's actually a pretty badass name for an init system.
| davexunit wrote:
| 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
| cooperate. https://nlnet.nl/project/DistributedShepherd/
| paroneayea wrote:
| Also a note since there are a number of comments on here about
| this being a rival for Systemd: Shepherd precedes Systemd by
| quite a bit! Shepherd was previously known as "dmd", the
| "daemon for managing daemons", which was made in 2003! So in
| that sense, if anything was imitating anything (and not
| claiming anything _was_ ), it would be the reverse :)
| skulk wrote:
| 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.
| tmtvl wrote:
| Eh, I'd say systemd still has far better dmcrypt support. The
| bad (I used to think it was terrible, but I tried installing
| Debian today, which lowered the bar even further) support for
| full-disk encryption is what keeps me off Guix, as a matter of
| fact.
| jauntywundrkind wrote:
| "give a man an inch and they'll take a mile" and what not, but,
|
| I wonder how hard this would be to port to Hoot, a web
| assembly/wasm-ified Guile Scheme.
| https://spritely.institute/hoot/
|
| It would be neat to have some real management APIs for the things
| running on a page, to be able to manage long running processes &
| workers.
|
| A bit more niche than for general webapps, but systemgo comes to
| mind; a re-impl of some of systemd in go, specifically designed
| to be run on the web in Browsix. https://github.com/plasma-
| umass/systemgo
| davexunit wrote:
| > I wonder how hard this would be to port to Hoot
|
| It would be interesting, though I don't know if it would make
| sense. In any case, the way to do it would be to extract all
| the code that does POSIX things into an abstraction layer.
| Shepherd is built on the Fibers async system which Hoot
| supports so that part shouldn't be an issue.
| dannyobrien wrote:
| 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 Guile's fibers library to
| work in WASM, and that's probably the biggest lift.
| paroneayea wrote:
| 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!
| NeutralForest wrote:
| 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.
| jauntywundrkind wrote:
| 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
| kkfx wrote:
| My main remark is: please do consider DESKTOP more than HPC etc,
| Guix System have a great potential to surpass NixOS for good but
| can't until the desktop will be the main driver, because before
| working on a system we enjoy it personally, and personally means
| desktops and homeservers...
___________________________________________________________________
(page generated 2025-01-14 23:00 UTC)