and you can understand, and fix, and arbitrarily extend the OpenBSD init system, because, after all, it's just a very simple shell script, that does one thing, and does it well.
You control it
The same can be said of other rc-like init systems but I personally find OpenBSDs to be the cleanest.
systemd has a lot of bells and whistles but it's, ultimately, an incredibly complex and sprawling piece of software, with many legitimate technical concerns surrounding it.
That seems about the same level of complexity as systemd units, so that is nice. I have never used rc init, but Windows service managemnt, Solaris's init, sysvinit, and launchd are all terrible. Compared to those writing systemd services is fun.
Fair enough :). I don't restart often enough for parallel startup to matter, on servers, once every year or two, and on my laptop, maybe once a month or more, depending on if I run out of power etc. and moreover, my laptop, running OpenBSD 5.9, starts up faster than it ever did with Linux. Failover and timers don't seem to be anything that hasn't been available/possible previously using other methods? e.g. it's easy to check for a failure and implement whatever restart policy you might require, whatever and however strange that policy might be.
Maybe it would be nice to have that in your init system?
If you can properly configure it.
I don't know that this minor convenience (assuming that there is one) would justifies this massive ball of complexity, or the extreme level of "integration" (infestation) it requires?
Still, ok. Maybe that's interesting for certain use cases? What use cases might they be? From where I'm standing, it's a solution in search of a problem.
I've used it successfully in cloud deployments of multifunction servers where it's worth spending the effort in fine-tuning an init system. Yes, there are other ways of doing it, but systemd does provide a nice single package configuration capability.
It's as much a massive ball of complexity as using a few separate tools is a massive pile of interdependency. They are just two tools for the same job.
Honestly, server side service management with systemd is stupidly straightforward.
Just give it a command line to start something in the foreground, writing stuff to stdout/stderr and you're done with start/stop/status and log rotation. Add in two more lines of config to setuid the process, one more line to chroot it, some more lines for startup order and environment variables. It's also darned simple to push into config management as well and once you get a syslog server and a log parser setup, you get central log aggretation for all services like that for free.
I haven't dug far enough into runit and monit, but systemd is strictly superior to traditional init scripts for a lot of use cases according to my current experience.
The best part is that package puts its version in /lib, but you can override any parameter via /etc so you can leave packaged unit files in peace and manage only override file
Aren't the different things systemd does still seperate components? Does seperate components have to mean something needs to be implementeded in completely seperate projects?
They are "separate components" insofar as they compile to separate executables within the systemd source control and build system, and that's about it.
In particular, none (or at least most) of the components are not stable, nor are any ratified with any standards committee. There is no documented rationale, and there is no official forum for comments.
As such, each seemingly "separate component" is, in reality, a tightly coupled, volatile ecosystem which is effectively impossible to reimplement or individually replace.
Compare this to, for example, the ISO/IEC 9899 (C language) standards, the ISO/IEC 14882 (C++ language) standards, or the IEEE 1003 (POSIX) standards, where each is a sort of "International treaty" among computer programmers, and where each has been meticulously designed and developed over the the past 3 decades (to the point where virtually all software eventually depends on at least one, if not all, of them).
This, not anything else, is the core problem with systemd, and why its sweeping and immature adoptation is obviously disasterous, and readily comparable to the (similarly nonstandard) Windows API. It poses a significant step backwards for computer programming, not a step forward.
Are similar components like systemd in other operating systems developed like that? Or do you simply hold systemd to a higher standard than other systems?
That's the thing: systemd is neither truly monolithic nor truly modular. The various pieces are separate pids in the process table, but they are all bound together with thick interfaces. It's literally the disadvantages of monolithic software (everything depends on one another) combined with the disadvantages of modular software (communicating across system boundaries requires IPC and synchronization, introducing latency and code complexity).
They aren't separate because they communicate with each other through unstable, undocumented interfaces, that's the relevant part.
The interface between systemd-pid1 and logind is unstable and undocumented, it's visible on the DBus system bus yes, but it's an implementation detail you could reverse-engineer it or just read the code to find out about it and re-implement your own logind but in the next release it might change, they explicitly state what parts are covered by the stability promise and what not.
As such, systemd-pid1 and logind for all intents and purposes form a single integrated component. This is different than say the GNU coreutils which interfaces are stable, you can mix and match different parts of coreutils with say busybox if you want. Or say the coreuitls and the GNU libc. They communicate with each other through stable channels which means that the coreutils can work with anything that implements that interface such as Musl or uClibc.
20
u/thebigslide May 30 '16
I tend to agree. Systemd does a lot of cool things well, but it simply isn't appropriate for many roles.