Latest Round Of Debian Systemd vs. Upstart Voting Ends

[leidola]

I've seen this argument over and over but no one actually elaborates.
I would like to know what exactly makes systemd a superior alternative (I acknowledge my ignorance in init systems).
Thanks.

• It's dependency based and specifying dependencies is quite easy and reliable.
• in contrast to other init systems it's bookkeeping of what processes belong to what job is working . other init systems only use pid files and thus only know the master process and possibly leave processes running after stopping a service.
• you can reliably deconstruct complex storage setups even if they provide rootfs

There may be more, but this is what crossed my mind first.

[justmy2cents]

Debian is the new congress. In case of fire they wouldn't be able to pass the water act.

that is what you get when you allow people belonging to projects being voted on to vote.

presentation videos

http://www.youtube.com/watch?v=CUOAUQJ-y00

http://www.youtube.com/watch?v=rWux-PA6JCU

i don't know but if upstart wins, there is something really, really wrong. but, hey corporate takeovers usually are like that. simply change project direction until you're in position to actually drive it. that was always cheapest takeover

[c117152]

I've seen this argument over and over but no one actually elaborates.
I would like to know what exactly makes systemd a superior alternative (I acknowledge my ignorance in init systems).
Thanks.

https://wiki.debian.org/Debate/initsystem/systemd#Upstart

https://wiki.debian.org/Debate/initsystem/upstart

Looking just at the surface and language, observe how the systemd position statement is full of technical details while the Upstart one is mostly rhetoric. e.g. The "Upstart vs. systemd" section in the Upstart statement starts by claiming "there is really rather little to distinguish upstart from systemd" and follows by attacking systemd over wide concepts ("systemd is Linux-specific", "systemd is hasty", "systemd is "greedy".", "systemd is unproven") you can't define as technical.
Now, compare this to the systemd equivalent abstract "Upstart suffers from an improper design which replaces dependencies by purely event-driven actions..." and all the technical issues that were brought up ("Upstart treats dependencies as events", "The use of ptrace is a", "Socket activation is"...).
Even when the systemd document raises non-technical issues, it's still not conceptual but is rather a specific problem with specific consequences you can at least reason about ("Upstart?s contributor license agreement", and the rest of the "Community" sub-section).

Regardless of any truth to the claims, the documents leave one with a strong impression of systemd being technically superior.

[Ouroboros]

Ian had Steve change his vote to FD so systemd wouldn't win. As long as all the Canonical members keep changing their vote to FD when it looks like systemd will win we won't get anywhere.

Are these seriously the people that make decisions that impact millions and so many large companies? They're acting like immature children.

FWIW, all I see on the list is "Upstart doesn't have that right now, but we can implement it. systemd has it but I don't agree with the way it's done." and "systemd has too many features"

[Sergio]

https://wiki.debian.org/Debate/inits...ystemd#Upstart

https://wiki.debian.org/Debate/initsystem/upstart

Looking just at the surface and language, observe how the systemd position statement is full of technical details while the Upstart one is mostly rhetoric. e.g. The "Upstart vs. systemd" section in the Upstart statement starts by claiming "there is really rather little to distinguish upstart from systemd" and follows by attacking systemd over wide concepts ("systemd is Linux-specific", "systemd is hasty", "systemd is "greedy".", "systemd is unproven") you can't define as technical.
Now, compare this to the systemd equivalent abstract "Upstart suffers from an improper design which replaces dependencies by purely event-driven actions..." and all the technical issues that were brought up ("Upstart treats dependencies as events", "The use of ptrace is a", "Socket activation is"...).
Even when the systemd document raises non-technical issues, it's still not conceptual but is rather a specific problem with specific consequences you can at least reason about ("Upstart?s contributor license agreement", and the rest of the "Community" sub-section).

Regardless of any truth to the claims, the documents leave one with a strong impression of systemd being technically superior.

Yes, that was my impression too.

[gigaplex]

I wish they would just pick one, and move on. What ever it is, live with the decision and plan on how to proceed. If they go with either upstart or systemd, then they need to get cracking on porting efforts for thier freebsd and hurd branch, so the choice of either involves a ton of work, so just decide and start coding. Even a poor decision(hindsight is 20 20) is better than no decision.

That's a really bad idea. It's better to spend a bit of time up front to avoid making mistakes that you have to deal with for years and years. The hardest part about software is maintenance, not the initial code sprint.

[interested]

[snip: good comparison between the debate pages regarding systemd and Upstart]

Regardless of any truth to the claims, the documents leave one with a strong impression of systemd being technically superior.

I think most of the Upstart/Canonical people no longer consider a win for Upstart possible. However, they seem eager to ensure that systemd doesn't "win" either.

Their goal seems now to be that multiple init-systems on Debian Linux must be supported, and with a little luck, that all programs must be neutered to work with the lowest common init denominator.

The main advantage for Canonical for getting such a victory is that all Debian developers will then work for Canonical's goal, by making their programs compatible with Canonicals non-systemd stack, even if Debian chooses systemd as their init-system.

Anyway, this is just round one in Canonical's fight against the future Linux development stack, that is; systemd, kdbus, cgroups and Wayland.

The exact same battle will be repeated with Wayland, where the Canonical people in Debian's CTTE will fight bitterly to ensure that all Debian programs _must_ support X and therefore will work on Ubuntu too.

[s_j_newbury]

Gentoo DOES support systemd

What's with all the claims that Gentoo doesn't support systemd? OpenRC is the default, but the entire point of Gentoo is you chose which USEflags *you* want. I've been using systemd on Gentoo for years, it's taken a while for good coverage of systemd units for various services, but it's pretty much there now.

From my perspective it's much better than OpenRC. I've been using Gentoo for long enough that OpenRC still feels like a pretty new development!

[Marc Driftmeyer]

Simple: Default to systemd, Debian wide. Fall back to good old sysvinit.

Upstart/etc., if they want to support it to provide branches in parallel of the entire tree.

Done.

[Chaz]

Ian had Steve change his vote to FD so systemd wouldn't win. As long as all the Canonical members keep changing their vote to FD when it looks like systemd will win we won't get anywhere.

Are these seriously the people that make decisions that impact millions and so many large companies? They're acting like immature children.

FWIW, all I see on the list is "Upstart doesn't have that right now, but we can implement it. systemd has it but I don't agree with the way it's done." and "systemd has too many features"

Yup, as long as the Canonical guys all vote FD ahead of System D they can block System D. Perversely, this does not necessarily mean they deadlock. If any of the System D supporters vote D > U > FD then their bastardized Condorcet process will declare U the winner. So to defend against that the D supporters all have to bury U below FD as well so they deadlock.

It looks like rather than forcing a permanent deadlock the U backers are trying to force the L option (while accepting D). DT might be able to win outright under normal Condorcet (with the casting vote) but the U backers can get DL by abusing the process*, as long as one D backer puts DL ahead of FD. DT backers can in turn block this by voting DT > FD > anything else, but it looks like they won't.

What this all boils down to is that the Debian voting process is braindead. They say they use Cloneproof Schwarz Sequential Dropping (aka Schulze method, see Wikipedia), but they actually don't. They use CSSD modified to add a casting vote + a special status for the further discussion option. The casting vote lets the chairman break ties, which is important. But then they declare that to win, an option has to beat FD, not just tie it, and the casting vote does not count against FD. I guess they gave FD special status because it seems like it's "nice" and "let's everyone be heard", or because people think they shouldn't make a change unless there's agreement (these are again the exact same as stubborn U.S. senators say about the filibuster). But the reality is that refusing to choose is itself a choice; it's a choice of pointless fighting and paralysis. They ought to just use normal CSSD with a casting vote or with an odd number of voters; then the procedure would be almost exactly the same but it would be impossible to deadlock (unless everyone votes equal preference for each option, which would be dumb).

*Actually that's not quite fair; the Debian rules explicitly tell you to bury unacceptable alternatives below FD, so the abuse is mandatory.