3 ms·

I had my reservations when Arch shifted to systemd. It seems like a tremendous break from Unix philosophy and a blatant violation of everything I knew. I'm gla

I had my reservations when Arch shifted to systemd. It seems like a tremendous break from Unix philosophy and a blatant violation of everything I knew. I'm glad they did, though. Unit files are far easier to write and having a supervisor behavior in the init system alleviates a tremendous amount of administrative overhead. That's not to say shell scripts are difficult, but they can break in mysterious ways. Though I imagine the same is true for systemd, from an end user perspective, its implementation (once you understand it) requires less effort. There are those who disagree, and I respect that. But the improvements to my desktop boot time are substantial. And writing a quick unit file to run something on boot requires little mental overhead. Just a glance over the manpage is enough to get started. sysvinit scripts on the other hand... well, maybe my memory is really poor, but if it's been more than a few months since I've written one for the specific system I'm targeting, it takes substantially longer. ;) So, it's likely I'm stupid or systemd is easier. Or both. Probably both.

unhammer 13y ago
I had the same experience, would not have expected to be so pleasantly surprised by an init system :) And writing unit files for systemd was fantastically easy. systemd actually looks like it was designed based on experience. "Worse is Better" as a development philosophy works for getting stuff up and running and finding out what the real problems are so that you don't make solutions for non-existent problems. But when enough time has passed, and enough glue and pieces of string accumulated, it's time to take a step back and consider a redesign.
- Zancarius 13y ago
  I think that's my biggest problem with shell-scripts-as-an-init-system. There's nothing inherently wrong with it, but sooner or later, the only way to correct for broken or missing functionality is (to borrow your term) to add more glue. And if you want more correct behavior, you either have to wait for the distro maintainers to fix it or fix it yourself only to merge your changes back in on the next OS update. That's another thing I like about systemd. With the separation of "stock" unit files in /usr/lib and user-supplied ones in /etc/systemd, you can override the ones distributed by your OS vendor without worrying about updates breaking your changes. That's already saved me once or twice during Arch's transition from sysvinit to systemd, in fact. One thing that comes to mind is an issue I had some time back with running a proprietary service in a manner that would allow the init system to control it when it forked itself a number of times and spun up separate processes. start-stop-daemon was confused by this behavior and it required some tricks to collect the approriate PID just to be able to stop the service (I may be wrong, but I think it was the TeamSpeak 3 daemon which behaves weirdly). systemd's use of cgroups ignores this rubbish entirely, because it's effectively impossible for systemd to lose track of what processes belong to which service. Want to kill the service? No problem. Some in this thread seem convinced that systemd is a solution looking for a problem, but I suspect some of them lack experience with systemd. Or stubbornly cling to their ideals of what an init system should do. I like the unification of a supervisor-type service and the init system. It makes my job easier. And that's not even half of what systemd is capable of!

unhammer 13y ago

I had the same experience, would not have expected to be so pleasantly surprised by an init system :) And writing unit files for systemd was fantastically easy. systemd actually looks like it was designed based on experience. "Worse is Better" as a development philosophy works for getting stuff up and running and finding out what the real problems are so that you don't make solutions for non-existent problems. But when enough time has passed, and enough glue and pieces of string accumulated, it's time to take a step back and consider a redesign.

Zancarius 13y ago
I think that's my biggest problem with shell-scripts-as-an-init-system. There's nothing inherently wrong with it, but sooner or later, the only way to correct for broken or missing functionality is (to borrow your term) to add more glue. And if you want more correct behavior, you either have to wait for the distro maintainers to fix it or fix it yourself only to merge your changes back in on the next OS update. That's another thing I like about systemd. With the separation of "stock" unit files in /usr/lib and user-supplied ones in /etc/systemd, you can override the ones distributed by your OS vendor without worrying about updates breaking your changes. That's already saved me once or twice during Arch's transition from sysvinit to systemd, in fact. One thing that comes to mind is an issue I had some time back with running a proprietary service in a manner that would allow the init system to control it when it forked itself a number of times and spun up separate processes. start-stop-daemon was confused by this behavior and it required some tricks to collect the approriate PID just to be able to stop the service (I may be wrong, but I think it was the TeamSpeak 3 daemon which behaves weirdly). systemd's use of cgroups ignores this rubbish entirely, because it's effectively impossible for systemd to lose track of what processes belong to which service. Want to kill the service? No problem. Some in this thread seem convinced that systemd is a solution looking for a problem, but I suspect some of them lack experience with systemd. Or stubbornly cling to their ideals of what an init system should do. I like the unification of a supervisor-type service and the init system. It makes my job easier. And that's not even half of what systemd is capable of!