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

21–30 of 158 posts

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

#21

Post by throwaway092834 »

vacri wrote: post #19
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…

The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't Systemd is winning this war because it created the war, by conflicting with sysv init. Upstart predates Systemd, systemd just has more traction.

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

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

#22

Post by vacri »

throwaway092834 wrote: post #21
vacri wrote: post #19

Earlier quoted context omitted.

The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't Systemd is winning this war because it created the war, by conflicting with sysv init. Upstart predates Systemd, systemd just has more traction.

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

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.

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

#23

Post by [deleted] »

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…

[deleted]

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

#24

Post by pjmlp »

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.

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

#25

Post by cliffbean »

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…

I take issue with the "nobody is forcing you" part. If you want to use Linux, and there are good reasons for it, it will likely be increasingly difficult to avoid systemd. You can argue whether that's "forcing" or just "applying pressure", but it's real.

That said, your other comments resonated with me. I used to fear systemd, and worried that losing the ability to hack on init guts shell scripts meant loosing the power to make my system work for me. I've since discovered that with systemd I don't feel the need to hack on init guts shell scripts like I used to, because it actually manages services intelligently on its own.

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

#26

Post by teddyh »

theophrastus wrote: post #6
ChuckMcM wrote: post #2

Interesting follow-up, this stuck out for me: "To start with and as usual, social problems are the real problems." This really resonates with me. Once any organization gets to a certain size, getting change to happen is more "social problem" and less "technical problem." When you don't select for people at that stage who can move an entire organization over to a new way of doing things, your organization will stagnat…

yes indeed social problems. or as one of my favorite quotes goes: "Trust no one! The minute God crapped out the third caveman, a conspiracy was hatched against one of them!" --Col. Hunter Gathers, OSI (Venture Bros parody of Hunter S. Thompson)

More likely, three conspiracies were hatched, one against each one of them.

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

#27

Post by spartango »

Petty politics aside, it seems to me that the comparisons between Systemd and Upstart are analogous to those between launchd and Solaris' SMF.

The crux of the comparison is whether init should explicitly follow a dependency tree or resolve dependencies dynamically.

The other complaints fall out of that concern: in following the launchd model of dynamic resolution, systemd is forced to bundle in complex features. On OSX launchd serves as a hub from day one, so coordinating IPC and mount-watching is not so foreign. Similarly, this hub functionality restricts modularity, although launchd doesn't subsume autofs fully.

The reality here is that we're looking at a philosophical difference. While religious wars start over which is the "right" view, I'm unconvinced there is one. Much as SMF and launchd are comparably functional, so will upstart and systemd be.

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

#28

Post by krakensden »

vacri wrote: post #19
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…

The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't Systemd is winning this war because it created the war, by conflicting with sysv init. Upstart predates Systemd, systemd just has more traction.

Several of the systemd developers worked on upstart or worked on porting fedora to upstart. Lots of the design decisions- socket based activation vs event based, cgroups integration- were made because of things that were (and still are) broken in upstart.

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

#29

Post by throwaway092834 »

vacri wrote: post #22
throwaway092834 wrote: post #21

Earlier quoted context omitted.

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

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.
Post reply on HN