[erhardm]

I see the whole pro/anti systemd as a philosophical debate. Basically each part is arguing where the complexity should be in the system and how dense it should be distributed. I think we need two competing init systems to really know maybe in 5-10 years what the best trade-offs are. A modern sys V init and systemd.

[exelius]

I think the point is that you can't have two competing init systems: the market will eventually need to standardize on one of them or risk forking the entire Linux ecosystem. What you call "modern sysv" would look a lot like systemd depending on your definition of modern. I think that definition of what modern should look like is what's being debated here.

The big features sysvinit are missing require user space applications to be able to interact with [generic launch system]. Those applications must use some sort of standard taxonomy and flow control. As applications are ported to [generic launch system], they cease working on sysvinit systems because sysv either doesn't support those features or supports them in a different manner.

Sysvinit doesn't really do all that much, to be honest. So it's really easy for [generic init system] to emulate most of its functionality. [generic init system] does a lot more, so it's harder to copy. Even more, if you were to "clone" [generic init system], applications make big assumptions as to how [generic init system] functions, so your [generic init system] replacement would need to function nearly identically to [generic init system].

Basically, someone made a call and said "this is how a modern init system should function". There is a vocal group of people who disagree with that definition. But no matter what the definition is, people would disagree because different people have different ideas about what Linux is/should be. You would see the same problem if a sysvinit derivative was the leading candidate instead of systemd.

[erhardm]

They're good points, but from the philosophical point The Unix Way, systemd leaves some things to desire. Is there a modern Unix way? I don't see a lot of exploring in this area/side, but I see a lot of this is the way it's gonna be from now on on the other side.

I'm not on either side, but I appreciate the way some complexity is dealt with simple little things. So elegantly solving problems: https://www.youtube.com/watch?v=S0mviKhVmBI#t=450

[exelius]

I'm not on either side myself, either. But "this is the way we've always done things" is a terrible reason to keep doing them that way. Systems change, requirements change, and so implementations and methods must change as well. I'm not saying this is warranted or not in the case of systemd (I don't know enough of the details to opine either way) but it has been a cultural problem in the Linux community for a number of years. Modern use cases require a more coordination between multiple parts of the system, which is I think where a lot of the friction comes from.

The entire systemd debate is as bad as it is because this is a can that has been kicked down the road for two decades because nobody wanted to have the same argument again. Everyone has known for a long time that at some level, Linux needed better coordination between user applications, hardware, and system services. systemd seems to deliver on most of the functional requirements of such a system, though the implementation method has upset some people on a philosophical level because they believe it's counter to the Unix way, whatever that means.

I would argue that software development in general has drifted away from "the Unix way". Modern software development is a mess of dependencies, abstraction layers, control points and dominant standards controlled by individuals/companies with a vested interest. Linux is a good counterbalance to that, but at the same time it can't stray too far away from the way that people use systems or it becomes too outdated to matter. Is systemd the answer? Who knows. But in the absence of something that performs its function, companies will step up with proprietary solutions for their use cases (launchd on OS X/iOS, whatever Android uses) that lead to more walled gardens, not less.

[agrover]

I think the fallacy is looking at the composability of tools on the command line and thinking you want/need the same composability in how the system runs. You don't. The Unix Way is actually TWO things: one is shellscripting and the composability of the command line, and the other is C and libraries. "Whipupitude vs manipulexity", to quote Larry Wall. Systemd is the result of determining that running system services is complex and needs to be handled by a real program instead of scripts. This is easier in C, but the flipside is the unavoidable loss of whipupitude. For most people this is fine. When Unix was young, whipping up something simple was fine. Now it isn't, and really hasn't been for quite a long time.

[anko]

Thank you, this is the most insightful comment I've read.

People like the whipupitude, because they know it. But nearly every init.d script I've read has bugs. There isn't a testing framework to ensure correctness and even if there were it would be needlessly complex because you'd spend a bunch of time mocking out the filesystem / the process table / whatever else init scripts do.

We know what initialising a process should look like and we should be stabilising this API so that we limit mistakes/bugs.

[bnolsen]

Unix had high goals but ended up compromising. It's been a good system, good enough to fend off other system competitors. Trying to argue details using precedence and pointing to the exceptions and compromises to prop up arguments doesn't excite me very much.

Plan9 seems to have better distilled and refined the "unix way". But it's been too little too late and I'm sure if it became popular there's be wars about it too.

[vidarh]

We've had multiple competing init systems for years without forking the entire Linux ecosystem any worse than before.

[exelius]

Because they all largely did the same things that sysv did with a few bolt-on features. After many years, it's become apparent that approach won't work when you need multiple processes to be able to coordinate and schedule threads, power management, etc. Things need to be done at the hardware level, and sometimes those need to be triggered from user applications. But you can't have random applications tinkering in the kernel, so systemd arose and took over a number of those functions.

So I guess I can amend that to say "you can't have multiple init systems that do the things that systemd does".

[uselessdguy]

Because they all largely did the same things that sysv did with a few bolt-on features.

That is a total misrepresentation, I'm sorry. The fact is SysV was probably one of the weakest init systems around, besides deliberately minimal ones like busybox-init and sinit.

I devoted the "sysvinit: the eternal red herring" section precisely to debunk that. I just want people to stop comparing everything to SysV, because it only demonstrates that you're unwashed or closed-minded more than anything. The recent parody site forkfedora.org really aggravated me for that same reason. Instead of doing some witty response to the Debian fork stupidity, they just basically posted "LOL look at this SysV initscript, and now this systemd service file. Checkmate, systemd-haters!"

Much to my disappointment, people keep committing the same fallacies even when discussing an article meant to try and silence them at least this one time. I guess it only proves my point, I don't know.

[exelius]

I agree with you; my entire point that they were sysv with bolt-on features was to say that many of the alternate init systems really weren't very advanced and spent too much effort trying to replicate sysv for compatibility reasons when the entire thing should have been scrapped.

Anyway, I think the pro-systemd folks often think that anti-systemd folks would react the same way to any init system that isn't sysv. This is probably fair, because there haven't been many credible non-systemd alternatives to sysv.

[JdeBP]

> ... spent too much effort trying to replicate sysv for compatibility reasons ...

This is wrong, too. Only upstart, systemd, and runit include any form of System V rc compatibility. (It's worth noting that no alternative system has implemented System V init compatibility.) None of the others do.

[bkor]

The GR is specifically about keeping support for sysvinit around. So comparisons to that are entirely logical IMO. Note that I find the GR to be very vague. There's a post on Planet Debian to explain how to interpret it (jeez!).

[fbt2lurker]

Why two? As many as people would write. There is already a bunch of em.

[erhardm]

At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.

[fbt2lurker]

There aren't actually two sides of this. There are only in the scope of systemd vs everyone else (just because systemd is something that is pushed as THE solution).

There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects. It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it. It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.

[fbt2lurker]

Just to be clear: I know that among the bigger projects it's just GNOME3 that is planning to hard-depend on systemd and even they want a shim, externnal or internal, to accomodate systemd-less systems (not necessarily BSDs, maybe other linux distros too). Currently systemd is very much optional (opt-out, not opt-in, learn the difference) and I personally mantain an Arch flavour that uses sinit, smdev and a bunch of other small projects while still relying on Arch's package base. It's the attitude of the upstream that seems like a threat: “we want everyone to use systemd”. And if they succeed, developers of userspace software will be very much justified in hard-depending on it. Who cares if everyone uses it, right?

[erhardm]

TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).

[bkor]

systemd provides things and does things that are useful. That is why GNOME depends on those. Blaming us? Try actually understanding why. It's not a hard dependency btw, you still have ConsoleKit support. A project not maintained for almost 3 years or so. Then there is that systemd-shim. Initially very very buggy, but now ok-ish. OpenBSD is working on some shim thing as well.

[erhardm]

Others working on systemd shims out of necessity is a sign, IMHO, that systemd is in reality a hard dependency in the near future (and developers trying to free from that dependency). I don't say systemd is not useful, GNOME using it shows also to good sides of it, but others feeling a little forced to choose systemd or The Unix Way I think is the wrong way to do it. Why can't we have both(modern init system and unix philosophy)? Not possible? Not enough interest/resources?

[kbenson]

I think you have a much more stylized view of what a side of a debate is than reality suggests is the case. Creating an implementation for a side that wasn't already rallying around one would just exacerbate the differences in opinion on that side and fragment it into multiple smaller sides.