It's obvious that the author of this article has never actually used systemd. For example, he complains that the startup sequence is "written in C," so the only way to change it is to recompile systemd itself. This is utter nonsense; systemd uses tiny config files called units to configure everything, so there is no reason to recompile. It's hard to take these complaints seriously when the author clearly hasn't used the thing he's complaining about, or ever read the man page.
A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this:
So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.
> system bootup was controlled by a bunch of shell scripts that made no sense to me
And this is the problem. You're guilty of the very thing you're accusing the author of.
Some of those shell scripts are very simple and can be easily replaced with a configuration type file. Most are not. They do a ton of stuff, like create lock files, pid files, check for dependencies, check for existing processes, etc etc and couldn't be properly replaced by a configuration block.
Using shell script gives you unbelievable flexibility in how you start a daemon that can never be replaced by a configuration script.
So what happens? All that complex stuff stays in that script you can't understand and now you've added an additional layer of complexity that wasn't necessary.
Every additional layer adds a point of failure and in my humble opinion, isn't worth the additional user-friendliness.
My personal experience with writing sysvinit scripts agrees pretty well with s_tec's view. Those shell scripts would easily have been replaced by trivial .ini files and contained several bugs before I managed to figure out how to use start-stop-daemon correctly and fix some typos.
I have not used systemd myself but it seems trivial in comparison to my experience writing sysvinit scripts.
"It's obvious that the author of this article has never actually used systemd."
There's no need to start your article by being a douchebag. You could just make your point.
Also, I don't think you really got it right here. His point is that lots of functionality has moved from shell scripts to C. Yes, you have an ini-style configuration file. That's not the same as a shell script.
postfix took the simple-flat-config-file model whereas exim provides a much richer language. Some years ago I attempted to do something slightly odd for SQL auth in both, and found that postfix only let me use SASL, and SASL didn't have a driver for what I wanted, and therefore in order to make it do what I wanted I needed to write a C-based SASL driver to execute the SQL I wanted. In exim it was 3 or 4 lines of config.
Similarly, if I hit something systemd can't do I now have to write C to add a config file, rather than write a couple of lines of shell.
that is what the author means.
I could certainly see an advantage to providing an ini-based approach as well for people who regard current LSB conmpliant init scripts as "shell scripts that made no sense to me" - and for people like me who -do- love them, but would be quite happy with a simple way to configure simple things.
But please don't try and take that power away from me when I need it.
You can still use shell with systemd; just replace the "ExecStart=" binary with the name of your script. I've seen lots of systemd unit files where the ExecStart and ExecStop lines just shell out to the old LSB init scripts.
It really matters for servers how long they take to boot, particularly when you look at virtual machines / clouds, where they are thrown up and torn down rapidly.
Switching from shell to C is a problem from DoD users - you aren't allowed to have a compiler installed on a production machine, so to edit your init process (I guess they aren't scripts anymore!), you'd have to have a separate machine to do the compiling.
Systemd services are configured with a .service file, which is a text file (but not a shell script).
I don't know why the author made the bizarre suggestion that anybody would start tinkering with the source of systemd itself in order to configure services, and it would be impolite to speculate. Suffice to say that nobody does this.
Certainly you can take advantage of more systemd features by modifying the source of the service to explicitly support them; however, this is not something users/sysadmins should ever need to do themselves.
This isn't how it works -- you can use shell scripts within systemd, it's just that the so-called standard init scripts have been replaced.
Note that old-style SysV init scripts weren't really editable in most cases. They were supposed to stick to a rigid set of standards (which they often didn't, causing lots of bugs), and edits made to them might be silently reverted during an upgrade. For this reason, most distros recommend /etc/sysconfig/* files for persistent configuration of init scripts, which systemd also uses (or editing the textual foo.service file).
Not installing compilers on production machines is a relic from 1990 that doesn't impact security in any meaningful way. If I have access to your machine I can upload a compiler and/or I can upload binaries generated by a compiler at my end of the pipe.
I think systems that do not have a compiler will try hard to make it impossible for normal users to do chmod +x, too. Users likely will not have a login shell, and they will have a umask set to prevent creation of executable files.
I can't take this rant seriously when it dismisses the importance of fast startup. "You shouldn't care if your system starts up slowly" is just untenable.
The multi-second difference in software start time, after waiting 5+ minutes for my RAID to initialize and all the onboard crap to check out is really negligible.
Except if you're using ksplice on Linux to start a new kernel, you won't be waiting for RAID to initialise, which means those seconds do matter. (Or fast reboot on Solaris.)
In many SLAs, the amount of time the system is unavailable can count against the company providing the server. Minimising the amount of downtime is a win for everyone.
Yes. This is perhaps the point (s)he meant to make. There are other processes that take much longer, and the tens of seconds difference in the boot process isn't that great in the grand scheme of things.
I can't take you seriously when you don't justify your claims. Sure, it may be that fast startup is important for you, but it's not important for me as a desktop user, and it's not important for me as a server administrator. I reboot every couple of months at best when there's some kernel update, I suspend my desktops to RAM instead of shutting them down.
Two minutes of downtime per server is also irrelevant to its two month uptime, especially when you have clusters of servers so your service doesn't experience downtime at all.
Decades of user research has shown that users really care about fast bootup times. Your use case is the minority. Why do you think that fast start is Google's #1 selling point for Chromebooks, for example? (Not that Chromebooks are successful, but Google is famous for paying attention to user research.)
A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this:
So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.