Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd is winning the init wars and other things aren't

utcc.utoronto.ca

Post reply on HN
Print view View original

31–40 of 158 posts

Re: Why systemd is winning the init wars and other things aren't

#31

Post by jakeogh »

colin_mccabe wrote: post #13
pdkl95 wrote: post #7

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…

systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handl…

If a process dies I would rather it stay dead. Can systemd monitoring and auto-restart be globally disabled?

Re: Why systemd is winning the init wars and other things aren't

#32

Post by pekk »

rodgerd wrote: post #14
pdkl95 wrote: post #7

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…

> Why do the anti-choice people refuse to recognize that other people might have different requirements. Go build your own LFS systems if you want ultimate choice. You don't get to force upstream authors (who like systemd) and distribution developers (who like systemd) to do what you want. > I'm sticking with what already works. sysvinit works only if you combine incredibly low expectations with a bad case of Stockho…

But you get to force upstream authors and distribution developers who would like to be able to use something else? Sure.

That is not a real argument on the merits of permitting this choice. It is just saying "nyah nyah I have the power and you do not."

Re: Why systemd is winning the init wars and other things aren't

#33

Post by krakensden »

throwaway092834 wrote: post #5

This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why…

> Systemd is winning this war because it created the war, by conflicting with sysv init

Except Upstart also has config files instead of shell scripts. And both of them support all your old sysv init scripts. And writing the config files is so much easier to get right the first time than rolling your own goddamn shell script by default.

On a sort of related note, I have never had an interaction with daemontools that wasn't miserable. I always find the fact that it gets waved around like a bloody shirt in these discussions terrible and terrifying.

Re: Why systemd is winning the init wars and other things aren't

#34

Post by cssx »

jakeogh wrote: post #31
colin_mccabe wrote: post #13

Earlier quoted context omitted.

systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handl…

If a process dies I would rather it stay dead. Can systemd monitoring and auto-restart be globally disabled?

It's disabled by default, you need to enable it on a per-service basis.

Re: Why systemd is winning the init wars and other things aren't

#35

Post by exDM69 »

falconfunction wrote: post #11

What about openrc? https://wiki.gentoo.org/wiki/Comparison_of_init_systems What's up with the words words words

According to one of the links in the original article, OpenRC and sticking with SysVinit were also evaluated as options early in the discussions.

Re: Why systemd is winning the init wars and other things aren't

#36

Post by wila »

I read his article and didn't see anything besides "it is better because well.. it is better" without much technical explanations on the why. Then read over it again and saw a link to his earlier article.

http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight

which does help defend his position even while I don't share his opinion.

Re: Why systemd is winning the init wars and other things aren't

#37

Post by mercurial »

throwaway092834 wrote: post #29
vacri wrote: post #22

Earlier quoted context omitted.

well, I wouldn't call the technical conflict unnecessary - if there wasn't a need for a more featureful init system, then there wouldn't have been a motive to write a new one. As for the social conflict, that's just what you get with social groups experiencing change.

Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.

> All features of this new process invocation system could be implemented without making a "new init system."

Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse.

If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency system working. And socket-based activation? Sysvinit is a dead end. It's the counter to "keep it simple, stupid": when you fail to capture enough information in your "simple" model, you are going to end up with more issues than if you had created a slightly more complex system.

Re: Why systemd is winning the init wars and other things aren't

#38

Post by xorbyte »

pjmlp wrote: post #24
pdkl95 wrote: post #7

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…

The main issue is like it ever was with the UNIX wars, now Linux wars. Cloning UNIX was not enough, now each distribution wants to "improve" UNIX on its own way.

Not sure how you see progress and innovation otherwise. Much of what is good in Linux comes from experimentation and people/distros 'doing their own thing' which sometime improved the ecosystem, and sometimes resulted in abandoned projects. But things have not stagnated.

As for UNIX, perhaps you're familiar with Plan 9? Some of the principal UNIX designers were unhappy with the result, so they went and worked on improving it. Nothing is good enough the first time around.

Re: Why systemd is winning the init wars and other things aren't

#39

Post by exDM69 »

pdkl95 wrote: post #7

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…

> This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features.

This is the argument we've heard over and over again.

The problem with traditional unix init scripts, together with cron, acpid, inetd, etc is that you need a big brittle mess of shell scripts to tie it all together to form a system that actually works.

While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device. There may be changes in power (mains/battery/low power), network connectivity (ethernet, wifi, mobile) and connecting peripherals (including external disks) and lots of other things which need starting/stopping services or mounting/unmounting partitions. The amount of shell script glue to make these things work is unwieldy and doesn't really work that well.

And distribution maintainers have to make a choice, supporting more than one init system is going to be a burden that will hurt end users in the long run.

Finally, no one is forcing you to use a systemd based distribution. If OpenRC solves your problems, do go ahead and use Gentoo or another OpenRC based system.

Re: Why systemd is winning the init wars and other things aren't

#40

Post by pyalot2 »

Have you actually looked at what systemd does? Here's a handy chart curtesy of wikipedia: http://en.wikipedia.org/wiki/File:Systemd_components.svg

That just seems insane to me, what do I know... (admittedly not much about init systems)

Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such.

Post reply on HN