I always thought systemd would be a messy pioneering attempt that would be redesigned later on. Because dependency based parallel boot is a good thing.
What features would a "slimmed down version of systemd" provide that isn't available in various independent tools we used to use (and still use today).
* Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
* journald? Logging tools - including multiple types of syslog daemons - are numerous; use whatever you want. Choice is good. Even journald could be an option some people might prefer If it wasn't monolithically tied to systemd and could be used as a stand-alone daemon.
* cgroups? Other managers exist.
* timedated? Managing the clock was never difficult. The standard solution is to delegate most/all clock management to ntpd. If you had especially unusual needs, you probably had to set it up manually anyway (probably with a tiny amount of sh script).
* udevd? Other hardware managers exist. Some of us prefer the peace-of-mind of a simple static configuration instead of a manager, but you should be able to use udevd if you prefer it; udevd used to work stand-alone, but Lennart added it to the systemd monolith[1] when they were trying to push kdbus into the kernel. -sigh-
* daemon/process management? daemontools, runnit, s6, etc.
* logind? This attempts to create the concept of a "session" as a privilege boundary that is orthogonal to the actual privilege boundary in UNIX: the UID. The entire concept is a terrible security problem waiting to happen. The entire concept of a session is especially stupid considering most people don't actually use the traditional multiuser features of UNIX or this new "session" concept. In the rare situation where someone actually is running an actual multiseat setup, an extra step to install an optional package with these features wouldn't be a burden. The rest of just need a simple login/password prompt that can launch gnome/kde/.xinitrc/whatever at login time, which already existed as {x,g,sd,lx}dm.
If there are features that were only provided by systemd, is a monolithic[1] daemon really the best solution? Or could those feature simply be encapsulated into a small stand-alone package that could work wherever it is needed?
edit:
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
Systemd's real value proposition is its tight coupling. As you pointed out, there were several logging systems, several daemon programs, several hardware managers, a combinatorial smorgasbord of options available.
This means you can't assume almost anything about the distro or setup you're targeting as an application developer. Should I log to /var/log or use journald? Can I bundle a .service file or should I have shell scripts? Can I rely on udev rules or do I need to touch /dev? You can't assume unless you're only targeting Ubuntu.
Systemd is so integrated that programs require minimal porting. The alternative is either supporting everything, which leads to massive bloat, or forcing downstream patches to make the damn thing compile and run. Having a non-modular set of services you can rely on means even small alternative distros like NixOS can support many packages, because those packages require minimal changes.
Consistency across environments is critical. it's why docker is so big - all the wiring lives in one place, and what's inside runs everywhere.
But reducing choices to get consistency and consensus strips away the freedom that Linux offered - you can't uproot and replace components as easily. You can have that freedom or you can have a hassle-free package ecosystem; it's an inherent trade-off.
For resource quotas? Cgroups is a kernel interface. What kind of manager do you have in mind?
> daemon/process management? daemontools, runnit, s6, etc.
None of them can deal with runaway daemons. Some of them can deal with ordering and pre/post conditions and instancing, but not as extensively. Each provides a different subset of systemd's init features.
> Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
Inetd works in entirely different way. Those approaches are not comparable at all. (Systemd can hand off the whole listening socket)
All of the tools you mentioned have different syntaxes. With sd I onlt have to keep a single syntax - ini files - which is incredibly more efficient than ten years ago when I had to memorize a dozen different things to make my system run. I'd rather slit my wrists than write another init script in bash / dash, even for the simplest service.
agumonkey|6 years ago
unknown|6 years ago
[deleted]
inopinatus|6 years ago
etaioinshrdlu|6 years ago
pdkl95|6 years ago
* Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
* journald? Logging tools - including multiple types of syslog daemons - are numerous; use whatever you want. Choice is good. Even journald could be an option some people might prefer If it wasn't monolithically tied to systemd and could be used as a stand-alone daemon.
* cgroups? Other managers exist.
* timedated? Managing the clock was never difficult. The standard solution is to delegate most/all clock management to ntpd. If you had especially unusual needs, you probably had to set it up manually anyway (probably with a tiny amount of sh script).
* udevd? Other hardware managers exist. Some of us prefer the peace-of-mind of a simple static configuration instead of a manager, but you should be able to use udevd if you prefer it; udevd used to work stand-alone, but Lennart added it to the systemd monolith[1] when they were trying to push kdbus into the kernel. -sigh-
* daemon/process management? daemontools, runnit, s6, etc.
* logind? This attempts to create the concept of a "session" as a privilege boundary that is orthogonal to the actual privilege boundary in UNIX: the UID. The entire concept is a terrible security problem waiting to happen. The entire concept of a session is especially stupid considering most people don't actually use the traditional multiuser features of UNIX or this new "session" concept. In the rare situation where someone actually is running an actual multiseat setup, an extra step to install an optional package with these features wouldn't be a burden. The rest of just need a simple login/password prompt that can launch gnome/kde/.xinitrc/whatever at login time, which already existed as {x,g,sd,lx}dm.
If there are features that were only provided by systemd, is a monolithic[1] daemon really the best solution? Or could those feature simply be encapsulated into a small stand-alone package that could work wherever it is needed?
edit:
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
sterlind|6 years ago
This means you can't assume almost anything about the distro or setup you're targeting as an application developer. Should I log to /var/log or use journald? Can I bundle a .service file or should I have shell scripts? Can I rely on udev rules or do I need to touch /dev? You can't assume unless you're only targeting Ubuntu.
Systemd is so integrated that programs require minimal porting. The alternative is either supporting everything, which leads to massive bloat, or forcing downstream patches to make the damn thing compile and run. Having a non-modular set of services you can rely on means even small alternative distros like NixOS can support many packages, because those packages require minimal changes.
Consistency across environments is critical. it's why docker is so big - all the wiring lives in one place, and what's inside runs everywhere.
But reducing choices to get consistency and consensus strips away the freedom that Linux offered - you can't uproot and replace components as easily. You can have that freedom or you can have a hassle-free package ecosystem; it's an inherent trade-off.
viraptor|6 years ago
For resource quotas? Cgroups is a kernel interface. What kind of manager do you have in mind?
> daemon/process management? daemontools, runnit, s6, etc.
None of them can deal with runaway daemons. Some of them can deal with ordering and pre/post conditions and instancing, but not as extensively. Each provides a different subset of systemd's init features.
> Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
Inetd works in entirely different way. Those approaches are not comparable at all. (Systemd can hand off the whole listening socket)
jcelerier|6 years ago
marcosdumay|6 years ago
cies|6 years ago
JdeBP|6 years ago