Stop the madness before it is too late!
If you are a desktop linux user, especially if you like Gnome, there’s a big change (risk) that you are using systemd. Fine. No problem. Good for you.
If you however want to be in control of your server, enjoy flexibility and simple-to-grasp concepts, pretty much the essence of unix for the last 40+ years, you have probably come across an init or rc script that you can read and understand, as well as figure out how to replace it with something else. Perhaps when switching from sendmail to postfix.
Computers still get faster and faster, especially in parallel processing power, and operating systems, especially with a graphic desktop environment, get more and more complex. Thus it makes sense to utilise the increased processing power by doing more things at the same time, thereby reducing start times.
Another aspect of the increased complexity in todays computer systems are that, partly thanks to the open source software movement, these complex systems are built much according to the unix philosophy: modularly. You take generic pieces of software that does something (and doing it well), and stick them together. This way you get much functionality, built on stable components, which is much better than in the closed-source version, where everybody reinvents the wheel, only with less quality.
How can I say that? Mostly because of very simple mathematical proof:
- software takes time to write
- time exists only 24h each day
- the human brain can only focus on 1 thing at a time
- bugs can be found in software
- software is written by humans with brains
Because there are bugs in software, the less software (smaller codebase) there is, the fewer number of bugs it can contain. Smaller, less complex software pieces are more stable than big monoliths. Making changes in a big monolith is more difficult than changing the internals of a small tool/module with a clearly defined interface. The small module can be replaced/rewritten and exchanged with something that implements the same interface, without affecting the functionality of the complex system using it.
What is systemd?
A very bad idea in many ways, that looks appealing in some other ways.
Why is it bad?
Because it replaces /sbin/init, (PID EINS! as the author titles the pages on his nullpointer blog). PID 1, /sbin/init is the most important program in a unix system. It is responsible only for reaping zombies, being the parent process of daemons, and initially starting the system (hence the name “init”). This is the only special process in a unix system, and it is in fact so special that if this process dies, the entire system (the kernel) dies.
What do we know about bugs and code size/complexity? How would we want our most important process? Small and bug-free? Big and bloated? I’d like to say it’s your pick, choose what you like, but with systemd it’s not that simple, because it infects the major linux distributions, gaining momentum and requiring everybody that writes system-oriented open system software to adapt to systemd. After a while it will be too much trouble to maintain compatibility with traditional/portable solutions that have functioned very well for 40+ years now. Things that work on Solaris, BSD, Linux, OS-X that change to systemd, will be Linux-only, because systemd is linux-only, and will never be ported to other kernels.
Remember when Gnome was a desktop environment that you could run on Solaris and BSD? Well, no more. Gnome will have dependencies on systemd, meaning that because systemd always will be linux-only, so will Gnome.I’m late to the party, screaming about this now, many years too late, but it is IMPORTANT. Someone is wrong on the internet. Many before me have been upset about systemd and the many ways in which systemd is bad. There are lists detailing the top 5 systemd troubles, other good summaries on why systemd is bad for you. Some funnier than others, but I very much recommend reading all the linked pages from this post. Most of them are much more insightful and debating than what I can show in this short blog post.