
GNU Shepherd 0.6.0 - lelf
http://lists.gnu.org/archive/html/info-gnu/2019-04/msg00006.html
======
sevensor
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.

~~~
enriquto
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.

~~~
sevensor
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.

~~~
opan
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.

------
nerdponx
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...](https://www.gnu.org/software/shepherd/manual/shepherd.html#Service-
Examples)), but it helps to hear the experiences of people who use it in
practice.

------
preek
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/](https://www.gnu.org/software/guix/)

------
afranchuk
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/](http://smarden.org/runit/)

~~~
_emacsomancer_
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.

------
gigatexal
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.

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

If so, what makes it different?

If not, what's it for?

~~~
bjoli
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...](https://www.gnu.org/software/guix/manual/en/html_node/Defining-
Services.html#Defining-Services)

~~~
majewsky
> 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.

~~~
bjoli
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.

~~~
stephenr
> 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.

~~~
Skunkleton
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.

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

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

