3 ms·

> I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. The problem with this traditional un

by exDM69 13y ago

> I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. The problem with this traditional unix approach is that in addition to init, pm-utils, inetd, cron, etc you end up having thousands of lines of shell scripts that glue all this together in a big brittle mess. While this approach may be fine for servers which boot once and stay on for ages, are connected to fast wired network and are generally rather stable configurations, I don't want such a system for my desktop, laptop or mobile device. I expect modern devices to be able to deal with changes in power supply (battery/mains/low battery), connecting and disconnecting devices (storage, peripherals, audio devices, etc) and changes in network connectivity (intentional disconnection as well as network failure). This may involve starting and stopping services, mounting and unmounting partitions and taking other actions when the physical configuration changes. I also expect my computers to boot and shutdown quickly and effectively. Some of this is already doable in other systems, like the traditional Debian network setup (originally built in the era of wired networks) which can run scripts on connect/disconnect. But the situation ends up being what I described above: thousands of lines of brittle shell scripts. I welcome the changes and the effort put in systemd and other init systems. Traditional unix init just doesn't cut it any more, in particular on personal desktop and mobile devices.

Zancarius 13y ago
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!
Sssnake 13y ago
>The problem with this traditional unix approach is that in addition to init, pm-utils, inetd, cron, etc you end up having thousands of lines of shell scripts that glue all this together in a big brittle mess. No, I don't. Typical linux distros may, but I sure as hell don't. I have a very simple, easy to read and debug set of shell scripts that work very well: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc/rc?rev=1.420;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc/rc?...
midas007 13y ago
This is not the fault of unix, it's well suited for static systems. It's the fault of implementers trying to use something that was designed for an entirely different paradigm. Future apps will need to copy themselves and their data to other devices, perhaps even suspend on one device and wake-up on another. Making changes for one use case at the expense of another without knowing the history is an ignorant change for churn's sake. Churn is not productivity, but the appearance of doing something.

by exDM69 13y ago

Zancarius 13y ago

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!

Sssnake 13y ago

>The problem with this traditional unix approach is that in addition to init, pm-utils, inetd, cron, etc you end up having thousands of lines of shell scripts that glue all this together in a big brittle mess. No, I don't. Typical linux distros may, but I sure as hell don't. I have a very simple, easy to read and debug set of shell scripts that work very well: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc/rc?rev=1.420;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc/rc?...

midas007 13y ago

This is not the fault of unix, it's well suited for static systems. It's the fault of implementers trying to use something that was designed for an entirely different paradigm. Future apps will need to copy themselves and their data to other devices, perhaps even suspend on one device and wake-up on another. Making changes for one use case at the expense of another without knowing the history is an ignorant change for churn's sake. Churn is not productivity, but the appearance of doing something.