- SysVinit
- xinetd
- atd
- crond
- supervisor
- syslogd
and the other things systemd replaces.
'Small, single purpose tools' is Unix philosophy. But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors.
One could also argue that 'doing one thing well' is handling services.
That's what we know about this company from an old (2007) article:
> “When we rolled into Baghdad, we did it using open
> source,” General Justice continued. “It may come as a
> surprise to many of you, but the U.S. Army is “the” single
> largest install base for Red Hat Linux. I'm their largest customer.” [1]
It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government (especially the one that has a tendency to indiscriminately infect other people's systems [2]).
Also, the Interface Stability Promise [3] by systemd team is just a promise, nothing more. Will Red Hat keep it if it is to decide at some point, that it no longer serves it's bottom line? I wonder if it can be considered legally binding.
[1] http://archive09.linux.com/feed/61302
[2] https://www.youtube.com/watch?v=vILAlhwUgIU
[3] http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt...
Originally posted in this thread: https://news.ycombinator.com/item?id=7210064
I hope so. My concern is that when we'll see systemd grow in size and more and more software depend on it's interfaces and components (as in GNOME with logind) at the certain point it could take an insurmountable amount of resources to maintain the fork. At this point it might be easier to give up on Linux and build around some other kernel and userland, I hope this will never happen, though.
Also, there is a difference between steering the developments in the preferred direction and outright destructive actions. As in https://en.wikipedia.org/wiki/Boiling_frog.
Such as? I'm pretty sure code shared between these systems lives in (or could easily be moved to) shared libraries, specifically to avoid this problem. But this is orthogonal to the design of the init system.
> But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors.
While DRY is a great engineering principle within the scope of a single project, it doesn't justify excluding alternative implementations or entangling unrelated concerns. Specifically, DRY is not an excuse to forbid competing init system implementations, even though having more than one creates code redundancy. Moreover, "doubling the scope for errors" is meaningless from the user's perspective in the context of init systems: if there are X errors in systemd and Y errors in OpenRC, I will not be plagued by X+Y errors because I will only be running one of them at a time.
> One could also argue that 'doing one thing well' is handling services.
Ah, but "handling services" is not a well-defined task. To some, it means doing something like what sysvinit does--reaping orphaned processes and nothing more. To others, it means doing something like what systemd does--not only managing processes, but also managing devices, sessions, storage, power management, cgroups, system IPC, and network interfaces (and possibly more in the future).
No-one is forbidding anything. You can run Debian with any init you choose. All we ("systemd proponents") want is that when upstream software decides to depend on something systemd provides, the debian maintainers don't have to (they can, if they feel like it) bend over backwards to replicate all systemd features for non-systemd platforms. Not demanding unpaid volunteers to do extra work is not the same thing as forbidding other init systems.
When layers above the init system begin to make hard dependencies on it, this will be unavoidable in practice. This is the problem, since it either takes away my choice in init system, or requires unpaid volunteers to work on removing the dependency. Neither is desirable, and the grandparent's argument is that this could all have been avoided if the systemd developers had made better design choices.
Don't get me wrong, I want systemd to be an option. I like the idea of using cgroups to manage services. I do it every day. What I do not want, however, is for systemd to be a requirement for having a working system.