GNU Shepherd 0.6.0 | Hacker News Reader

GNU Shepherd 0.6.0

lists.gnu.org

94 pointslelf48 comments

It makes me happy to see the GNU OS still being assembled, bit by bit. I've written previously about how much I appreciate the Guile info manual. For a document in a relatively obscure help system (other than Emacs users, who even knows about Texinfo?), it's carefully written with an eye to empowering its users. It's perhaps a bit quixotic, but you get the feeling that the GNU project really wants to deliver an OS written in Scheme all the way down, totally under the control of an enlightened end user. The Shepherd project certainly fits with that vision.

I love dearly the GNU project and the beautiful, nicely worded documentation which is always a pleasure to read (when rendered as pdf documents). However, the info format is unfathomable; if it is possible to really hate one file format, it must be this one.

Note that Texinfo != info, the former is a document source format similar to DocBook (but much simpler), the latter is a very simple hypertext format with preformatted text and support for indices (think of it as a text-based CHM). You can use the former to generate the latter, but Texinfo can be used to generate several other types of documents, including plain text, PDF and HTML (and yes, also CHM).

Also note that the info file format is independent from the GNU info viewer, that most people associate with, and there are other viewers for it, including pinfo and tkinfo (Tcl/Tk viewer) and some other help systems have support for it, like GNOME's and KDE's help viewers. And yes, there is also support for it on Emacs (which AFAIK is the only viewer with image support). FWIW personally i like using tkinfo.

> Note that Texinfo != info,

Sure. Nothing against texinfo (a bit dated, but perfectly acceptable). My problem is with the ridiculous "info" documentation format for which no browser seems to be even remotely usable. The only one I can cope with is "pinfo", but then again I'm always lost at the stupid hierarchy of "nodes", and no way to do global search/next.

Nodes are just pages, nothing else. Think of them as HTML pages in a browser.

Note that info does allow for global search, if anything searching is one of its main strengths over a bunch of HTML files in a directory, and it even allows both for arbitrary text search and for index-based search (where documents can place invisible index markers mid-text and searching for the text of markers as keywords you jump to the exact text position).

Of course this relies on the info viewer to implement. In the default GNU info viewer the / key does a search in the current page only, Alt-/ does a search in the current page and any pages linked as subpages (so you can do a search across pages but only at the current node - e.g. if you are in a book about a programming language and you are in the reference section you can search the entire reference, but ignore any tutorials or guides that may be placed in sections adjacent to the reference), i does a search in the index (here the prompt can do entry completion for you by pressing tab) and jumps to the appropriate entry and finally I (shift+i) does a search in the index and displays the results in a generated node (page) with links to each target (you can search this generated node using the / too).

Tkinfo provides similar functionality although i do not have an installation at the moment available to ensure (i'm under Windows where i have GNU info via msys2 but not tkinfo). Being a GUI application it does provide a few niceties like displaying the index and search results in separate windows and you also can choose to open links in separate windows (no tab support though).

I haven't used pinfo much, although IIRC from the little i used it (mainly to see how an info file i was working on looked there) despite it colorfulness it was a bit limited compared to other viewers.

> Nodes are just pages, nothing else. Think of them as HTML pages in a browser.

And there's my main problem. I do not want a hierarchical documentation, or anything to do with "pages". I want a single document with the whole documentation, where I can move and search normally, by myself.

I think info is really only usable inside Emacs. But inside Emacs, it is hands down the best documentation system I've ever used. A properly indexed manual is a joy to use, and beats the pants off anything PDF or HTML-based.

I hesitate to speak for emacs users, because I'm not one really, but I suspect the info format feels really comfortable when viewed with emacs.

I started using info more after installing the Guix system. One thing that made me use emacs over info was that with evil-mode you could use vim bindings to read info pages through emacs. It was a bit more like 'less' then.

It’s nice indeed. Not special, but certainly smooth to use. Never used it outside of emacs though.

I'd like to know how this compares to Systemd's actual service management features (systemctl, journalctl, etc). I love how declarative Systemd is.

There's an example in the docs which gives a good idea (https://www.gnu.org/software/shepherd/manual/shepherd.html#S...), but it helps to hear the experiences of people who use it in practice.

For those interested in shepherd, I highly recommend GNU Guix[1] which is a great functional package manager and can also bundle it's own Linux distro (called Guix SD).

1. https://www.gnu.org/software/guix/

Does anyone have experience with both Shepherd and runit[1]? And if so, can you provide a comparison of the two?

[1]: http://smarden.org/runit/

I use both. However, I'm mainly interacting as a 'regular user', but as such a user, both are pleasant to interact with, and don't try to be too clever or overly complex, and thus I don't encounter the same sorts of issues with them that I do with other init/daemon-managers.

As a side note the GNU SD distro looks cool. I like the declarative way of doing things and it really seems to be following the infrastructure as code idea.

Is Shepherd meant to be a replacement for systemd (et al), then?

If so, what makes it different?

If not, what's it for?

It is the unit system of GNU guix, and it has a better integration with the guix. You write guix packages and manage the Daemon using the same language.

I'd suspect that you with ease can programmatically interface with both of them using guile as well.

As a scheme fanboy I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts

Edit: read about how guix uses services here: https://www.gnu.org/software/guix/manual/en/html_node/Defini...

> I like the idea of being able to use a proper programming language (opinions may differ) for my startup scripts

I don't know. I rather like the NixOS way, where a proper programming language generates the startup scripts (or, in that case, systemd units), but then those scripts are dumb and obvious. Many things are better when they're dumb and obvious.

I agree, but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat.

Most shepherd service definitions are simple and stupid, but as always it is a matter of taste.

> but having an option instead of having to do ExecStop=path-to-shell-script-that-does-some-stupid-housekeeping is pretty neat.

IMO this is usually the result of eg a Debian package that also ships sysvinit startup scripts, and thus they share some logic.

If it’s not that case I wonder why the cleanup can’t just be handled in the unit directly.

Perhaps the service being managed doesn't clean up after itself properly? It is a fairly common pattern for a program to ship without startup scripts, and then have startup scripts added by package maintainers.

Right that’s certainly a thing but what I meant is, why not just put the cleanup instructions in the unit file.

Because "cleanup" can be non-trivial. Maintaining scripts inside unit files is a pain in the ass.

But the shell scripts are more or less portable across systems, whereas this way you were asking developers to re-implement the same cleanup logic in another language.

The problem with Nix is that it's not a proper programming language. I'll take Scheme over yet another obscure language that manages to irritate me in many ways.

I setup and used a headless nixos box for about a year or so, it was fun to play around with but I did get tired after a while of the nix programming language. It was just too weird to figure out and google around to try and find what I needed to do sometimes. Trying to get virtualenvs of python packages, or using rbenv / bundler type installs for ruby was also just too much of a pain in the butt.

https://nixos.org/nixpkgs/manual/#sec-language-ruby

Trying to figure my way around installing ruby/python libraries just was too hard most of the time without a good amount of work that it wasn't worth it in the long run.

Guix has been on my radar to try and install and play with in-depth soon. If their installer will work with a VM without a days worth of research to work around any quirks I'm all in for checking it out.

Installing Guix in a VM has its own section of the manual:

https://www.gnu.org/software/guix/manual/en/html_node/Instal...

I think I remember trying that a while back and couldn't quite get it working, I'll need to try again soon.

If you want immutability with a traditional package manager, try Darch: https://godarch.com

As someone typically working with others startup units but sometimes writing my own, I appreciate a declarative format that allows user-overrides and has pretty standardised ways of doing things.

Sysvinit scripts showed us what happens when you give startup authors more power.

Even if you hate systemd’s politics/etc the actual units themselves are objectively better IMO because they’re declarative.

Well, the service difinition part of shepherd is pretty declarative:

    (make <service> 
          #:provides '(blahblah)
          #:start (...)
          #:stop (...)))

The difference is that start/stop must be guile procedures that starts or stops a command. I suspect there is a nice macro for just running a regular shell command, but I'm not sure.

It’s guile. They’re instances of the <service> class (apparently). That is specifically not declarative and the fact that the only example in the official documentation is essentially the same as your example, says this project is not ready for use by humans.

If you (the project) cant show a full example service definition to start something why would anyone bother going forward.

> Even if you hate systemd’s politics/etc the actual units themselves are objectively better IMO because they’re declarative.

It's a pity the overall system is so inflexible and brittle. Well, that and the 'death by a thousand (theoretically independent but tightly coupled) systemd components'.

It has it's issues, definitely, and I'm not thrilled about "make everything part of the systemd project" - but in terms of providing a way to run your services, I think it's got a lot of functionality that e.g. sysvinit could never really support.

Yes, but it would be more useful to compare systemd to something that's actually comparable, i.e. a modern init like shepherd or runit, rather than sysvinit.

Runit to the best I can tell doesn’t have a declarative service definition. It executes (albeit simple) scripts in directories.

Shepherd service definitions also don’t appear to be declarative, and they’re written in guile, a language I can best sum up as someone’s “hold my beer” response when told Perl was too hard for causal users to understand.

Searching for examples of shepherd service definitions gives me one such example: the skeleton example without any details for “Apache”.

So sorry but no. Regardless of systemd’s issues those are not comparable alternatives.

> Regardless of systemd’s issues those are not comparable alternatives.

I agree with this, but for different reasons. I have various machines, with various distros, using various init/daemon-managers, including a number of fairly complicated setups (multiple LUKS drives, ZFS, etc.). The systemd systems are invariably more burdensome to maintain, and it's nearly always systemd that's the issue.

> and they’re written in guile, a language I can best sum up as someone’s “hold my beer” response when told Perl was too hard for causal users to understand.

I agree that the current shepherd configuration itself seems more opaque than one would like, but to compare guile to perl in this fashion is ridiculous. Guile is a Scheme, which means it has consistent, simple syntax and is more easily understandable than C, much less perl.

> what makes it different?

It's GNU, others aren't.

There will be other well reasoned arguments in favour of Shepherd but it essentially boils down to the same reason Hurd (the kernel) is a thing when GNU/Linux is already widespread.

That all said, I don't see the harm in competing solutions. Better to have a choice rather than lock ins.

Systemd is licenced under LGPL, why would it lock you in?

It's locking people in by eating the OS and making it difficult to move away from its tightly coupled and increasingly tightly integrated components (that, we must never forget, are not a single binary).

Sorry, that was a poor choice of words on my part. What I really meant was "better to have more options rather than fewer".

It only supports Linux, for one. Shepherd supports HURD and probably other systems.

Yes, it is an alternative init system. So it can replace systemd. It is in fact used as such in GuixSD, the NixOS alternative by GNU which is written in Guile Scheme.

Yowks - I know systemd gets lots of hate and this is “real” programming - but it does feel a bit niche from a language etc perspective?

I don't think Guile is too niche. In fact, Guix has a quite active community. Nowhere as Nix in terms of activity, but it's pretty nice and very friendly too.

I don't know about Guile's popularity, but I use NixOS as my daily driver distro and in my experience Nix is already very niche in the programming circles I run in.

That's not to say Guix shouldn't be developed or that Shepherd is bad, it's just that I would definitely call Guix niche.

https://www.gnu.org/software/shepherd/

It replaces the init & service management features of systemd.

Shepherd (as dmd) predates the systemd project considerably. It is intended to fill the same niche (init system, process monitor) as systemd, though.

Reply on news.ycombinator.com