Debian Now Voting On Init System Coupling

[Skrapion]

If Steve votes L first, then neither L nor N would lose any comparisons, which means it requires a tie breaker.

You can try it yourself. Go to this calculator and paste in these results:

L>N>A>FD
N>A>L>FD
A>N>L>FD
L>N>A>FD
N>A>FD>L
N>A>FD>L
L>A>N>FD
L>N>A>FD

(The last line is my guess at Steve's vote.)

Then add Bdale's choice (N>A>FD>L) to the tiebreaker field and press the "Schulze" button.

It'll show you the breakdown of how it's calculated, and as long as Steve votes L first, it will always require Bdale's tiebreaker, no matter what Steve's second, third, or fourth choices are.

N was been guaranteed to win even before Andreas's vote (modulo vote changes of course) but it's interesting that this issue is so divisive that it's likely going to require two casting votes in a row, when they've never needed a casting vote for anything before this.

Also, for all the talk of strategic voting, it wouldn't have made a difference. Even if all of the L supporters buried their last choice under FD, and everybody else listed FD last, it still wouldn't have affected the outcome.

[Scimmia]

Debian's system is more complex than that, though. I'm not going to go through to calculate it all out, for all I know, it could turn out the same.

[GreatEmerald]

Then add Bdale's choice (N>A>FD>L) to the tiebreaker field and press the "Schulze" button.

Shouldn't that be "FD>N>A>L", given that FD has special powers? Not that it changes anything in this case, though.

[Skrapion]

Yeah, the only exception I'm aware of in Debian's system is that FD always wins ties, but since FD wasn't one of the ties, that rule doesn't count here. Ranking the tiebreaker as "FD>N>A>L" might be equivalent, but I haven't done the math.

[erendorn]

would you mind explaining why does it have to be pid 1 ?
i know why, and i know why it is bad
so please enlighten me just in case i am wrong
lennarts blog didn't explain bdw

Most of the SystemD ecosystem is not running as pid 1. It's even possible that only systemd is.

[tuubi]

Most of the SystemD ecosystem is not running as pid 1. It's even possible that only systemd is.

Well that's obvious, as only one process can be PID1.

The controversy is about what that process does and contains. Systemd does push some stuff into PID1 that isn't there in sysvinit or more conservative modern equivalents like OpenRC or Upstart. It's not there just for the heck of it though, the reasons seem quite valid to me. Others think this process should stay minimal (not that it's huge or anything in systemd either) and believe this design implies risks not worth taking.

There's no practical way to compromise without breaking the design and giving up on many of the advantages, and as this seems to be as much about politics as it is about technical issues for a large part of the interested community, the controversy isn't likely to just fade away any time soon.

[rohcQaH]

Disadvantages are always theoretical - until the point where your mission critical system crashes.

Because we all know that after installing systemd, most of the operating system's complexity will be in the init system, thus it'll be the primary thing that crashes on your machine, right?

Most of the time, if something crashes, it's still a service, not the init system. When that happens, I'd rather have an init system that'll catch the crash, log the crash and restart the service. I'd also rather have an init system that can transparently restart the service without dropping any connections, thanks to the magic of socket activation. Most of all, I'd rather have an init system with proper cgroup support that prevents a single rogue service from OOM-killing the whole system.

Sure, added complexity in an init system is a risk. So is every line that gets added to the linux kernel, and nobody seems to fuss about that. But the added features are designed to make the system more stable and easier to administrate.

Systemd does push some stuff into PID1 that isn't there in sysvinit or more conservative modern equivalents like OpenRC or Upstart. It's not there just for the heck of it though, the reasons seem quite valid to me. Others think this process should stay minimal (not that it's huge or anything in systemd either) and believe this design implies risks not worth taking.

However, the counterpoint seems to proclaim "stuff in pid1 is bad" and then stop. What are the alternatives? Not having the features at all? Cramming those features into pid2 instead, where a crash is just as fatal as a crash in pid1?

I'm aware that users of openrc, upstart or even sysvinit implicitly voted for "not having the features at all". But that's not really the solution for everyone.

[gens]

Why does what have to be PID1? cgroup control?

kinda

it is for process control
so it could easily get all dem PID's from daemons
and so double forked daemons can't hide from whatever started them (systemd in this case)
(since daemons are processes re-parented to init, that runs on PID 1)

thing is linux kernel gives other ways of achieving this, and even more

also if you cgroup something, it can't escape anyway


@tuubi, you stated things as facts
i called you up on it and your reply is "you dumb, just google it"
ye go google it, you wont find this on google
nor on lennarts blog that has the same kind of information you provided

[erendorn]

Well that's obvious, as only one process can be PID1.

The controversy is about what that process does and contains. Systemd does push some stuff into PID1 that isn't there in sysvinit or more conservative modern equivalents like OpenRC or Upstart. It's not there just for the heck of it though, the reasons seem quite valid to me. Others think this process should stay minimal (not that it's huge or anything in systemd either) and believe this design implies risks not worth taking.

There's no practical way to compromise without breaking the design and giving up on many of the advantages, and as this seems to be as much about politics as it is about technical issues for a large part of the interested community, the controversy isn't likely to just fade away any time soon.

Exactly, but my point was that most of the code in the systemd source tree does not actually run in PID 1, so that the claims that systemd does too much in PID 1 are a bit overblown, regardless of the actual need to put there what's actually in it.

[tuubi]

@tuubi, you stated things as facts
i called you up on it and your reply is "you dumb, just google it"
ye go google it, you wont find this on google
nor on lennarts blog that has the same kind of information you provided

I never called you dumb. Please do not put words in my mouth.

You didn't call me up on anything. You just asked me a rather ambiguous question (that has been asked countless times before), then proceeded to say you already know the answer but do not accept it. Not much point in answering something like that.

Anyway, Lennart's blog isn't the only source for information on systemd's design choices. Google will help you find several mailing list and forum threads, blogs and even presentations on the subject. Hell, you'll find several good posts on the subject even here on Phoronix forums if you're up to trawling for them amidst all the chaff and trolling. I simply do not have the inclination and frankly cannot spare the time to do this for you. Oh yeah, you'll find quite a lot of information on the subject presented in an entertaining way in GreatEmerald's Ace Attorney cases if you haven't already seen them. The links to these can be found in one of these threads, can't recall which one.