Debian Still Debating Systemd vs. Upstart Init System

[zester]

I'm telling you, Debian should kill those responsible along with their friends and families.
Line them all up against a wall a shoot.

You do realize your advocating for murder because someone has a hobby you don't like! Are you fucking stupid?

[Guest]

Anyhow: the work systemd avoids on Linux would still have to be done before a release, since kfreebsd is an official port.

They should just drop this mess. It has less than 1% usage compared to Linux kernel in Debian. It's just plain stupid to keep something like this.

[Guest]

Here's what I suggest. OpenRC for a temporary/permanent replacement so there's more time to consider systemd and upstart.

As you should already notice openrc is not an option. It's just crap made by bsd fanboy which doesn't fit into modern Linux systems.

[Guest]

I'm telling you, Debian should kill those responsible along with their friends and families.
Line them all up against a wall a shoot.

I bet there's just few idiots who made such decision.

[Ibidem]

Last bit from Ian Jackson:

It seems unlikely
that there would be a majority in the TC for picking systemd, and
separately a majority in the TC for overruling the systemd maintainers'
refusal to implement a simpler readiness protocol.

So a decision to pick systemd automatically comes with the expectation
that all daemons will get the new build- and runtime dependencies, and
maintainers will be expected to accept those patches.

Isn't it shameful? There are still 4 TC members (Keith Parckard, Bdale Garbee, Don Armstrong, Andreas Barth) that must share their choice, but the guy is already saying that
systemd will not not be picked.

He's not saying that there isn't a majority for systemd, he's saying that there isn't a majority for systemd and a separate majority for requiring "a simpler readiness protocol".

[Ibidem]

FYI: There are more Debian developers working on kfreebsd-{amd64,i386} than on arm{el,hf}.

Anyhow, I'm in the process of incrementing the number of kfreebsd users.

[ceage]

The Upstart model may be more flexible [...]

Ironically, that ain't even the case. Systemd reacts to events as well, otherwise it wouldn't be able to make e.g. hot plugging work. It just doesn't make the whole event thing a sacred cow and the sole backbone for service management like Upstart. Upstart's insistence on doing just that makes it inherently inferior, because some things simply can't be expressed when relying exclusively on events, and it's clearly not enough to do proper service management. Fixing all of what's wrong with Upstart would mean making it more like systemd, with a proper notion of hierarchical relationships and the ability to keep track of the current system state, thereby acknowledging that the systemd folks were right in the first place.

Here's an example of how `simple' Upstart is. Consider the following Situation:

• user Alice has defined three services called A, B and C, respectively
• service A gets started after both B and C have started
• furthermore, service A stops when either B or C stops

Alice now wants to change the configuration of B and then restart it manually. So, here's what happens:

• Alice makes some changes
• Alice restarts B
• B goes down
• A goes down automatically
• B goes up ...

... and that's it. Wait, so what's up with A? Shouldn't that one get restarted automatically since all its `dependencies' are fulfilled once again? It sure should. That's the whole point of having a service manager. The reason why it doesn't is because Upstart doesn't actually know what a dependency is. It only knows about events.

So how does Alice get A to restart `the Upstart way'? Well, since A is currently waiting for Upstart to retrigger a `started' event for C, Alice just needs to restart C. There, that was easy! Poor Alice can finally rejoice over the simplicity of Upstart.

No, Seriously: what the fuck? What the hell does C have to do with anything? Alice never touched C, it just happens to be another dependency for A. So, because of Upstart's broken model, the system insists on that stupid event being fired.

In other words: Alice has to either restart a perfectly fine working service for no reason other than to satisfy Upstart's non-working way of thinking about things or, alternatively, she can choose to restart A explicitly. Option 1 is just grotesque. Option 2 defeats the whole purpose of having a service manager and is unacceptable for every init system that's advertised as an improvement over SysVinit.

The event concept can only be used to express time based ordering. It can't be used to express hierarchical relationships. Those concepts are completely unrelated to each other, and Upstart fails to acknowledge that very simple reality. It deliberately ignores a working concept only to be able to sound good on paper, and all attempts of covering that up by calling the model `elegant' won't help with that. Some of the assertions found in the Upstart documentation are just flat-out lies: Efficiency? It's quite the reverse. It does a lot of redundant work because of its flawed design, yet it fails to do the necessary work to try and keep the system fully functional. Upstart fails to fulfill it's own design goals, but at least it's `revolutionary' and `elegant', according to the Upstart Cookbook.

Seriously, those who quote Unix philosophy and then go ahead to promote Upstart for its alleged simplicity are full of shit.

[Rallos Zek]

If Debian refuses systemd, there is no point for me to install it.

If they adapt Upstart, they have to sign Canonical's CLA, if they want to change it even bit. This means any Debian works on that matter go into whatever license Canonical sees fit. Half the worry - they break a lot of things in ecosystem and will generate a lot of bugs, which they can't upstream to Linux, udev, systemd etc.

No they don't.

[endman]

You do realize your advocating for murder because someone has a hobby you don't like! Are you fucking stupid?

Hard decisions need to be made for the greater good.

I bet there's just few idiots who made such decision.

They should be identified and their names, email address and street address should be published on a web page visible to everyone.

FYI: There are more Debian developers working on kfreebsd-{amd64,i386} than on arm{el,hf}.

Anyhow, I'm in the process of incrementing the number of kfreebsd users.

Nice tried troll. Even if there were more devs in kfreebsd bsd then arm, kfreebsd is still not justified as it is useless for evrything while arm has it’s uses.


I really thing these distros need to disappear due to them holding back the progression of Linux and negative affliation with BSD:

-Debian (because of their kfreebsd port)
-Gentoo (their support of BSD. There are too many pro-BSD devs to gentoo. OpenRC was created by an ex-NetBSD developer Roy Marples)
-Slackware (refuse to accept modern features in favor of being BSD-like)
-CRUX (same as slackware)
-DracoLinux (same as slackware)

[Rallos Zek]

This systemd fiasco just keeps getting better and better!

15 year old Linux kiddies babbling about systemd and 'technical superiority' - you just can't make crap like this up. Priceless!

These posts are going to be hilarious to read when time comes for the Linux 'braintrust' to rip out the systemd garbage down the road with cries of how did we let this happen?!?

So much wisdom in this post I love it.