It's Back To Voting For The Debian Init System

[newwen]

Not quite. Under Debian's rules, you can't tie-break the F option. At least one more person has to vote something (anything) above F before it's over.

Voting tactically upstart backers could even make upstart win, but I don't think they're going to to it. They're going to block it again voting FD.

Ian Jackson is going to be pissed off when he reads this.

[mrugiero]

I'm bored, so don't expect anything useful from this post.
People should focus on the bright side: the economy should be moving pretty fast thanks to the rise on popcorn consumption.
Also, I read "Bdale" as "B Dale", which pretty much sounds like an action video game protagonist.

[newwen]

why L is really simple, but you need to understand that question order is required here (you can probably see that Langasek is whining about that)
if question T/L is first and L wins (upstart ppl were promoting that)... systemd loses everything it holds advantage in, upstart just some random things as it puts them on feature equal standing. then upstart proponents suddenly gains "PORTABLE" as highly valid reasoning on why upstart is best for second question. but, when question "Which" comes before "How", it probably changes both answers

but, one has to understand why upstart guys are so frantic. if debian chooses systemd, it basically spells death for upstart which probably goes bzr way as abandoned project

Exactly this.

[CTown]

not sure if it is great leadership, considering that it was known that Steve Langasek worked on a different version of the ballot, and his opinion was not heard on the new one.

The reason being that the other ballot had two questions on it:
(1) What init will be default on Jessie (only talking about Jessie right now).
(2) Do packagers have to maintain their packages for several inits (the L verus T options).

Bdale was saying that the two should not be on a single vote. Most users will deal with the defualt init, so packagers and testers can finally have some sort of focus.

Later, after taking in packagers' considerations, it can be decided if the packagers can handle maintaining package compatibility for several inits. So, everyone still has a chance to win. Plus, as this is only to set a default for Jessie, most likely they will have to keep sysV scripts anyways in Jessie (but that last part is just an assumption).

In all seriousness, they probably should pick systemd. Gnome has optional features that seem to depend on systemd (so, I hear) and the Plasma guys did already mention they will make a Wayland/systemd alternative way to boot Plasma as the current way works but just barely as messing with the old way can easily break it.

However, as already said on many of these Debian-init threads, there are other vendor-neutral inits coming along such as GNU dmd, Suckless's sinit. There's also the fact that OpenRC does not want to gobble everything in sight - not that I mind systemd's "healthy appetite".

[justmy2cents]

The reason being that the other ballot had two questions on it:
(1) What init will be default on Jessie (only talking about Jessie right now).
(2) Do packagers have to maintain their packages for several inits (the L verus T options).

Bdale was saying that the two should not be on a single vote. Most users will deal with the defualt init, so packagers and testers can finally have some sort of focus.

Later, after taking in packagers' considerations, it can be decided if the packagers can handle maintaining package compatibility for several inits. So, everyone still has a chance to win. Plus, as this is only to set a default for Jessie, most likely they will have to keep sysV scripts anyways in Jessie (but that last part is just an assumption).

In all seriousness, they probably should pick systemd. Gnome has optional features that seem to depend on systemd (so, I hear) and the Plasma guys did already mention they will make a Wayland/systemd alternative way to boot Plasma as the current way works but just barely as messing with the old way can easily break it.

However, as already said on many of these Debian-init threads, there are other vendor-neutral inits coming along such as GNU dmd, Suckless's sinit. There's also the fact that OpenRC does not want to gobble everything in sight - not that I mind systemd's "healthy appetite".

i don't think it would break as much as you think. systemd is designed really well as far as dependencies go unlike upstart where you deadlock in time you say "cake".

making DE session as systemd service really makes sense if you want to simplify code. not to even think how it simplifies whole management as you can control those services from os it self. that doesn't mean i'm saying it would just work. they would need to adapt their session manager to handle systemd and provide service files. good thread on this here (WIP)

http://kde.6490.n7.nabble.com/systemd-user-session-units-for-KDE-td1159117.html

major gain with this is that you kill 2 flies with 1 hit. you remove a lot of code which was never done well (we have to face it, but session management in linux DE sucked... only worked for one DE and didn't provide universal tool to handle them) and gain universal control over sessions

and if DE ppl finally started collaborating instead duplicating we could see more services like logind, localed and so on. D-Bus interfaces which work for all DEs. and with kdbus, whole D-Bus is slow is lost in time

[Skrapion]

Voting tactically upstart backers could even make upstart win

I don't think so. If they did:

D>U>F
D>U>F
D>U>F
D>U>F
F>U>D
---tactical votes below---
U>F>D
U>F>D
U>F>D

That would be:
D=U 4:4
D=F 4:4
U>F 7:1

The way the Shulze method works, U beats F, but D hasn't been beaten by either U or F, so it needs a tie breaker.

[CTown]

i don't think it would break as much as you think. systemd is designed really well as far as dependencies go unlike upstart where you deadlock in time you say "cake".

making DE session as systemd service really makes sense if you want to simplify code. not to even think how it simplifies whole management as you can control those services from os it self. that doesn't mean i'm saying it would just work. they would need to adapt their session manager to handle systemd and provide service files. good thread on this here (WIP)

http://kde.6490.n7.nabble.com/systemd-user-session-units-for-KDE-td1159117.html

major gain with this is that you kill 2 flies with 1 hit. you remove a lot of code which was never done well (we have to face it, but session management in linux DE sucked... only worked for one DE and didn't provide universal tool to handle them) and gain universal control over sessions

and if DE ppl finally started collaborating instead duplicating we could see more services like logind, localed and so on. D-Bus interfaces which work for all DEs. and with kdbus, whole D-Bus is slow is lost in time

I agree that code duplication means lost time. However, when I said that it would break I was referring to a blog post by dantii and a post by Aaron Seigo on mgr??lin's Google+ page. It's Seigo's second post in the thread. Basically, Plasma has two separate init systems, one for PC's and the other for Plasma Active; and they hate working on both of them. Why, beacuse they are a mess! Though, I should probably add (since this is Phoronix after all) that he seems to want a decentralized way to handle init systems (like Solid for hardware or Phonon for basic media playing).

Though, I guess this post is off topic.

I don't think so. If they did:
The way the Shulze method works, U beats F, but D hasn't been beaten by either U or F, so it needs a tie breaker.

Since, Debian chose this method, I assume that the better choices were not under a suitable license! That's Debian for you. ...Trolled (but in a good way) Sorry, it's been a slow day.<- Highlight over there.

[Skrapion]

If the remaining members stay consistent with their previous votes, we'll have:

Bdale: D>U>O>V>F
Don: D>U>O>V>F
Keith: D>U>O>V>F
Russ: D>U>O>V>F
Steve: F>U>D>O>V
--expected votes below--
Ian: F>U>D>O>V
Andi: U>D>O>V>F
Colin: U>D>O>F>V

The expected vote for Ian is exactly the same as last time. He explicitly does not like the wording of this ballot, and thinks they should keep voting F until they decide how tightly to allow integration with the default init system.

The expected vote for Andi is a little different. He voted F>U>D>O>V last time, but he said he doesn't intend to vote F again, and only did it last time so Steve would have time to air his concerns about the wording of the ballot.

Colin's expected vote is also exactly the same as last time. He explicitly prefers the simpler ballot, and refuses to vote tactically.

Given the votes above, Upstart and systemd will tie, beating everything else. Bdale's casting vote makes systemd the winner. Both Andi and Colin would have to go back on their words in order for this vote to fail.

[justmy2cents]

I agree that code duplication means lost time. However, when I said that it would break I was referring to a blog post by dantii and a post by Aaron Seigo on mgr??lin's Google+ page. It's Seigo's second post in the thread. Basically, Plasma has two separate init systems, one for PC's and the other for Plasma Active; and they hate working on both of them. Why, beacuse they are a mess! Though, I should probably add (since this is Phoronix after all) that he seems to want a decentralized way to handle init systems (like Solid for hardware or Phonon for basic media playing).

Though, I guess this post is off topic

i see what you mean. but, they are more or less concerned with portability issues. as far as hatred and breakage to do it... (i don't like to admit this) ALL session managers in linux are more or less half assed stiched up solutions since everyone is making new standard and changing it in every new version. now... go figure why they hate touching them, lol

also, i might be wrong here but i think i remember kde spin of fedora is using systemd like that. don't take me on my word here, i seem to remember reading that, but i'm no kde user

[xeekei]

If the remaining members stay consistent with their previous votes, we'll have:

Bdale: D>U>O>V>F
Don: D>U>O>V>F
Keith: D>U>O>V>F
Russ: D>U>O>V>F
Steve: F>U>D>O>V
--expected votes below--
Ian: F>U>D>O>V
Andi: U>D>O>V>F
Colin: U>D>O>F>V

The expected vote for Ian is exactly the same as last time. He explicitly does not like the wording of this ballot, and thinks they should keep voting F until they decide how tightly to allow integration with the default init system.

The expected vote for Andi is a little different. He voted F>U>D>O>V last time, but he said he doesn't intend to vote F again, and only did it last time so Steve would have time to air his concerns about the wording of the ballot.

Colin's expected vote is also exactly the same as last time. He explicitly prefers the simpler ballot, and refuses to vote tactically.

Given the votes above, Upstart and systemd will tie, beating everything else. Bdale's casting vote makes systemd the winner. Both Andi and Colin would have to go back on their words in order for this vote to fail.

How come everyone aren't voting at the same time? It leaves plenty of room for "tactical" voting when one party are able to see another party's votes ahead of their own votes.