Is Shepherd meant to be a replacement for systemd (et al), then?
If so, what makes it different?
If not, what's it for?
If so, what makes it different?
If not, what's it for?
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 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.
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.
https://www.gnu.org/software/guix/manual/en/html_node/Instal...
Most shepherd service definitions are simple and stupid, but as always it is a matter of taste.
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.
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.
(make <service>
#:provides '(blahblah)
#:start (...)
#:stop (...)))
If you (the project) cant show a full example service definition to start something why would anyone bother going forward.
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'.
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.
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.
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.
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.
It replaces the init & service management features of systemd.