5 ms·

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

by s_tec 15y ago

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: [Unit] Description=My Daemon [Service] ExecStart=/usr/bin/mydaemon --some --flags 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.

mst 15y ago
"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.
- s_tec 15y ago
  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.
maratd 15y ago
> 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.
- jeltz 15y ago
  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.

by s_tec 15y ago

mst 15y ago

"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.

s_tec 15y ago
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.

maratd 15y ago

> 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.

jeltz 15y ago
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.