On Thu, 2 Jun 2016 12:53:55 +0200 Jaromil <[email protected]> wrote:
> however I'd really recommend to sit down a bit and watch OpenRC as it > seems to me the best candidate to follow up sysvinit. My opinion is quite the opposite. OpenRC is, in my opinion, pretty similar to sysvinit. Both use "init scripts" that can grow huge and unfathomable. I've heard that OpenRC has some kind of parallel-foo, but for most use cases you don't care whether you boot in 2 seconds or 30 second. If OpenRC can respawn at all (without addition of daemontools-encore or equivalent), the way to do that is severely underdocumented. If I were going to switch away from sysvinit, I'd do it only if the new system were a huge improvement. I see sysvinit and OpenRC as very similar: No need to switch from one to the other. > One thing I > cannot find mentioned in the soy thread is that the init system should > be 100% compatible with existing sysvinit scripts and OpenRC seems to > achieve that with well written and well documented code, I think that any new init system should be 100% INcompatible with existing sysvinit scripts. Existing sysvinit scripts are the spawn of the devil, and provided lots of cover for the systemd fans to say "systemd is better than sysvinit." My opinion: If the init specification of a daemon exceeds 25 lines, that's a problem. Many sysvinit and OpenRC daemon init specifications are over 100 lines, especially if you take into account all the stuff imported from the "functions" file. I never want one of those long files darkening my door again. That's why I switched to Runit, where most of my run scripts are less than 10 lines long, and understandable by anyone. Anything resembling sysvinit init scripts must die. Another opinion: The original Epoch init system that Subsentient criticized and now wants to make parallel is arguably the best init system, and I wish I'd given him that feedback. First, process startup was sequential, and in most use cases that turns out to be the best. Screw parallelism. You *know* sequential is going to work. Second, Epoch's process config sections are tiny: Almost always less than 10 lines. Third, other than the new s6-rc and systemd, Epoch was the *only* init system that could easily and natively intermix long-run and run-once processes. Fourth, now that systemd exists, we can exploit systemd to programmatically create Epoch config sections. systemd unit files contain info which is close to a 1 to 1 correspondence with what's in Epoch configuration units. Systemd's after this and before that and depends on this and provides that can all be programmatically be converted into a boot order. The resulting confs could be given to the upstreams, or a Devuan Epoch maintainer could just test them all. And of course in 2016 there's no shortage of systemd unit files. Fifth, for the person manually installing an init system, Epoch is the quickest init system to install. It's a couple hours, as opposed to several hours for runit. Now I REALLY wish I'd told Subsentient how much I appreciated his sequential start Epoch. It was one in a million. SteveT Steve Litt May 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
