3 ms·
GNU Shepherd 0.8 Released as an Alternative to Systemd
- teleforce 6y agoI think the main reason most of the Linux based distros changed to systemd is due to the more systematic way it enables and support containers namespace and related technology (pardon the pun). This is evident by the mass adoption of systemd around 2015 when Docker is getting very popular and also the ability to use systemd-nspawn as a lightweight alternative to LXC (used originally by Docker). Since Shepherd is based on Guile Scheme it should enable more powerful abstraction and control similar to Guix, its related cousin. Guix is becoming more amazing by the day and you can check several of its related presentations at recent FOSDEM 2020 to get the big picture. One of them is "Guix: Unifying provisioning, deployment, and package management in the age of containers" https://fosdem.org/2020/schedule/event/guix/ https://fosdem.org/2020/schedule/event/guix/
- smcphile 6y agoI find the title here a little misleading, as the Gnu announcement itself doesn’t mention systemd in its title or even in the body of the announcement. I also believe that comparing gnu shepherd and systemd is potentially confusing, because systemd refers to a whole set of programs covering various aspects of networking, logging, etc. and not just to the pid 1 daemon launched on startup. (By the way, I have no strong opinion for or against systemd, to me it’s just another tool, and like any tool it’s more appropriate in some use cases than in others.)
- eeh 6y agoI'm a fan of the systemd umbrella project, and systemd PID 1. However, it's great to see innovation in this space, and with a clean design. For example, systemd bundles service management (Type=, Restart=) and containers (DynamicUser=, SyscallFilter=, etc.) into the same binary/process. Shepherd separates these roles. Shepherd just does service management. Containerisation can be provided by any tool, but Guix System provide call-with-container to make this easier: https://guix.gnu.org/blog/2017/running-system-services-in-containers/ https://guix.gnu.org/blog/2017/running-system-services-in-co...
- mattst88 6y agoI know nothing about the software, but I think this is one of the rare instances of a legitimately good pun-based name of a software project. > The GNU Daemon Shepherd or GNU Shepherd is a service manager written in Guile Oh, great. So it'll probably cease to work with the next Guile release like lilypond and texmacs.</angry-distro-maintainer>
- rad_gruchalski 6y agoNever heard of it. Is it any good?
- qqii 6y agoIt powers the Guix OS, and since its all Guile if you're a fan of lisp it's pretty good.
- davidwf 6y agoFascinating to see "systems programming" in Guile -- anyone actually using this for real work?
- lathiat 6y agoI assume this pairs well with GNU/Hurd? reads changelog Fix compilation on systems without ‘prctl’ such as GNU/Hurd Ahh yes.
- theamk 6y agoGuix/shepherd is a pretty unusual approach to a system, and in some ways an polar opposite of systemd. The systemd defines declarative configuration formats, include dirs, strict rules and so on to limit what startup scripts can do, and to keep system bootable. You can install many third-party software, and be pretty sure that when you say "stop", it stops; and when you say "status" you will get its status. The cost of that is that some things are non-trivial or require extra steps. Shepherd, on the other hand, fully trusts user. There are no safeties -- your config file is basically a lisp program running in PID 1. It is up to every programs' author to implement boot logic properly -- an infinite loop can render your system unbootable, and if "stop" command leaves stray processes around.. well, you can fix it yourself. The only safety Guix provides is an ability to roll back the system to the previous state, so if your latest changes rendered system unbootable, you can undo them.
- eeh 6y agoIs it common for Shepherd users to do dangerous things in Shepherd, or do they mostly just use existing safe functions to define their services?
- ncmncm 6y agoI wonder about its memory footprint. Does it grow ithout bound, until eventually you have to kill it? What control do you get? Systemd's memory footprint, it must be said, is nothing to write home about. Generallly you get good daemon behavior, when demands are very dynamic, by periodically starting a new process, passing the baton, and dying. Biology discovered this early on.