18 ms·

Debian votes for Proposal B, “Systemd but we support exploring alternatives”

319 points by mroche 7y ago

kardos 7y ago
In the event that the vote calculation is new to anyone else (it was to me), it looks like this [1] is what they are doing [1] https://en.m.wikipedia.org/wiki/Schulze_method https://en.m.wikipedia.org/wiki/Schulze_method
- deleted 7y ago
  [deleted]
- usr1106 7y ago
  This is considered one of the most democratic systems, it tries to make sure that the preferences of most voters are met in an optimal way. However, I would claim that with a list of 8 options it is close to impossible for a human to come up with a stable ordering. If you were to vote 3 times or 5 times without being allowed to look at your previous ballot sheets, how much would the votes change?
  - heftig 7y ago
    You don't have to produce a well-ordered ballot. E.g. you can pick your favorites and let everything else share last place.
  - pacifika 7y ago
    You vote once in the Schulze method
    - klez 7y ago
      That wasn't the point of GP's comment. Of course you only have one round of voting. Their point was, if you have 8 options and you don't really care for most of them (i.e. only the ordering of the first two or three matters to you) than the ordering of the options you don't care for won't carry much significance to the single voters (so they may order them randomly or leave them in the order they are presented), but it can matter in the end results. (I hope what I mean is clear, if not feel free to push me for clarification)
      - tialaramex 7y ago
        What you mean is _clear_ but it's _wrong_ Intentionally or not you've performed a little bit of sleight of hand. At first our voter doesn't care which of "most of them" gets chosen, they've no preference. Then one of these gets picked and "it can matter". But it doesn't matter to the voter we're thinking about at all. The people "it can matter" for thought hard about this option because it mattered to them by definition, and so their sincere preference was incorporated into the decision. By smuggling their preference back in as a concealed preference of other voters who didn't actually care, you inflate their position. If I say I don't care between Pizza and Burgers, and then Burgers win, you don't get to count me as a secret supporter of your "Let's eat these stale Doritos I found" faction just because you feel my support of Burgers ought not to really count.
  - raverbashing 7y ago
    Funny how the most democratic systems are absolutely dependent on electronic vote, because no one can count all those different orderings by hand
    - Yen 7y ago
      I disagree with the assertion that "no one can count all those different orderings by hand". To steelman a bit, let's consider a worst-case brute force manual tabulation of the results (there certainly may be more efficient ways to do it by hand than what I write here): On a ranked ballot with 8 proposals, there's effectively (8 * 7)=56 binary options (do you prefer A over B, do you prefer B over A, do you prefer A over C, etc.) In this vote, there were 452 valid ballots. 452 * 56 = 25,312 individual data points to tabulate, into a 8x8 matrix of results. If reading an individual result off a ballot and counting it takes a person 1-10 seconds, the entire tabulation would take 7-70 person-hours. With that 8x8 matrix of individual results tabulated, determining the Condorcet winner (or the members of the Schulze set, if there's no Condorcet winner), takes less than 1 person-hour, by hand. Now, that's certainly not an instantaneous result, but it's certainly within the realm of feasibility for a completely non-electronic election or referendum. As another way of sanity-checking, consider that major elections in the U.S. often involve a combination of local, state, and federal ballots that can have upwards of 30 individual questions in total, and millions of ballots are cast, and results are typically certified within a fairly short timeframe. It offline's certainly the case that an all-electronic vote is faster, more convenient, and that this lower cost can also allow for more proposals on the ballot, and more frequent and more granular elections, but I'd say it's a far cray from being "absolutely dependent on electronic vote".
  - JeremyNT 7y ago
    Is that stability actually an issue? It would seem to indicate that the voter has no strong preference for the items that they could not remember how to order consistently, and so either outcome would be roughly equally acceptable to them.
    - matthewbauer 7y ago
      It could mean that in a close vote like this, the result was due to random chance and not the will of voters. This does happen in fptp as well but not to this extreme.
  - jchook 7y ago
    I have seen a lot of buzz around Quadratic Voting as an alternative. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531
  - jcranmer 7y ago
    Schulze requires only a weak order of your votes: you can say that you like options B and C better than D, E, and F, but not prefer B over C or C over B. This is going to be an easier way to reflect your inner vote preference, because instability of votes is likely to be a result of choosing arbitrary orders for different tranches--and Schulze doesn't require you to pick that order.
    - usr1106 7y ago
      You are correct. The voter has the option to lead options unranked or rank several ones equally. So it's easier than having to come up with a complete ordering. Still, I would expect than many voters would come up with slightly different ballot sheets when having to do it several times. Did I give these 3 or 4 options the same low rank? Even if not required most Debian voters seem to give complete orderings https://www.debian.org/vote/2019/vote_001_tally.txt https://www.debian.org/vote/2019/vote_001_tally.txt in "normal" elections. In this complicated systemd voting less so https://vote.debian.org/~secretary/gr_initsystems/tally.txt https://vote.debian.org/~secretary/gr_initsystems/tally.txt
arcticbull 7y ago
Man, I feel like the Linux world is moving to systemd but this whole process has been like pulling teeth. I'm totally unaffected by this but even I'm feeling worn out on it. Feels like brexit, honestly -- nobody's enthusiastic about either systemd or sysv init, ok, fine, its happening but... ugh.
- jakeogh 7y ago
  The real mistake is having the arg in the first place. https://news.ycombinator.com/item?id=21842994 https://news.ycombinator.com/item?id=21842994
- ernst_klim 7y ago
  > nobody's enthusiastic The vast majority of people are fine with it, it's just the loud minority opposes it. The bulk of linux userbase is systemd only: Centos, Ubuntu, Arch, Opensuse, Fedora. I think these 5 have already 90+% of installations.
  - kijin 7y ago
    Fine doesn't mean enthusiastic. Most people are just going along with the trend with no strong preference either way. I'm actually quite fond of systemd now that I'm used to it, but I wouldn't have "moved" to systemd if it wasn't for the major distros making the choice for me.
    - oaiey 7y ago
      Are not the distros who design the composition of the actual overall system the exact right people to make this call? In an ideal world (and by your comment I assume you are close to it) you do not care or maybe even realize which startup system the system utilizes.
      - int_19h 7y ago
        That is only true for a casual user's desktop, maybe. If you're a power user or a server admin, you will likely be setting up services, or diagnosing their failures, at some point - and then the features and the ergonomics of the init system are very relevant.
usr1106 7y ago
For those of us who have forgotten the details https://lwn.net/Articles/806332 https://lwn.net/Articles/806332
usr1106 7y ago
More statistics https://vote.debian.org/~secretary/gr_initsystems/ https://vote.debian.org/~secretary/gr_initsystems/
oaiey 7y ago
I am curious about the "exploring alternatives". Anything known about that?
- deleted 7y ago
  [deleted]
- peterwwillis 7y ago
  Basically it just means "if somebody proposes something better we won't tell them to go screw themselves by default". Which I think is very important, as the future of operating systems like Linux is where it has been for the past 2 decades: in distributed computing. For non-desktop computing, what we really need are distributed operating systems. We have been poorly cobbling them together for decades, yet only a few research operating systems actually ship the needed functionality. Currently we use an array of layers of things, like hypervisors, container schedulers, service meshes, etc to sort of fudge together something that can do distributed computing in very specific ways. But they're all very complex, costly, and time-consuming to set up, and usually tailored to specific use cases. What we need is for Linux itself to natively ship all a distributed OS's features, so that apps can simply take advantage of them without having to be strapped into 20 layers of glue. But at the current pace of kernel development, I imagine it'd take 10 years to get all those patches developed, tested, and merged. So instead you could merge only the most core functionality, and extend the rest into the userland, and you'd get something kinda resembling systemd, but actually oriented toward running apps and services on a distributed network. I believe that would make most Linux-specific "cloud" technology obsolete, and in the process greatly simplify the entire technology stack, reducing TCO, speeding up development, and simplifying operations. Assuming that gets developed, "exploring alternatives" is a necessity to eventually get it adopted into Debian, so I'm really glad at least the option is there.
  - JdeBP 7y ago
    According to Ian Jackson, it was other options and not option B that were the options that encompassed not telling people to go screw themselves. * https://diziet.dreamwidth.org/3482.html https://diziet.dreamwidth.org/3482.html * https://diziet.dreamwidth.org/3999.html https://diziet.dreamwidth.org/3999.html
earenndil 7y ago
> Dropping Option 6 because of Majority. (0.8084112149532710280373831775700934579439) 0.808 (173/214) < 1 Not particularly relevant, but is there any reason to include that many digits, especially when the source-of-truth fraction is right there?
- fake-name 7y ago
  99% chance it's just some calculation tool not truncating. I wouldn't be surprised if that text is machine generated from a template.
  - mike_hock 7y ago
    It's obviously tool-generated. I think the question was, why does the tool show the non-truncated value for that one line, considering it put the truncated (%0.03f) version right next to it.
    - JdeBP 7y ago
      Here's the repository. Look it up and tell us. * https://vote.debian.org/~secretary/devotee.git/ https://vote.debian.org/~secretary/devotee.git/
      - mike_hock 7y ago
        What do you want me to tell you? dvt-rslt:367-368 the ratio is interpolated into the string output without any format specification (resulting in the full decimal expansion), whereas in the passing case (line 382) it is not. The ratio is formatted with %6.3f in both cases (369-372, 384-387). That's what it does. Doesn't tell us why (though it looks like a simple oversight on the programmer's part).
      - nemetroid 7y ago
        Just for fun, I had a look. The commit which adds the non-truncated print changed some behaviour with regard to < vs <=, so it might have been added for debugging purposes and simply never removed.
hazeii 7y ago
I hope that "exploring alternatives" isn't code for dropping sysvinit. Even with the latest debian, switching away from systemd is easy as:- apt-get install sysvinit-core sysvinit-utils cp /usr/share/sysvinit/inittab /etc/inittab reboot apt-get remove --purge --auto-remove systemd Our reasons for doing this are we run stripped-down systems that go for years (even decades), but which we absolutely must be able to fix ourselves with the proverbial rusty hairclip. The general bloat of linux distros (due to gnome/systemd and others) really doesn't suit our use case (although obviously it suits others, even the majority).
- ckastner 7y ago
  > I hope that "exploring alternatives" isn't code for dropping sysvinit. It's not about dropping, it's about how much effort the invididual maintainer must put into a package to support sysvinit, with the answer now being "none". The burden of work is shifted to from the maintainer those wishing to support sysvinit (or any other alternative).
  - japanoise 7y ago
    That's probably for the best. Writing init scripts is easy enough for that small percentage of users (like gp) who really need it. Good choice on Debian's part, imho.
    - gwd 7y ago
      The issue isn't actually so much about writing init scripts, as about all the other bits of functionality that systemd has been aquiring. One example apparently is logind. Important key packages have (as I understand it) started depending on functionality provided by logind; I think something like "Gnome Desktop". Which would mean, if you want to run Debian with Gnome, you have to run systemd. The non-systemd crowd wrote elogind in response to this. But of course, now elogind is in a situation like WordPerfect was with Microsoft Word back in the 90's -- trying to remain compatible with a moving target. So the point of this vote is to answer the question: How does a package manager of a package like the "Gnome desktop" interact with the non-systemd crowd, when they want to depend on a new feature that's in logind but not in elogind? Option F is basically, "The package manager says, 'systemd is our primary init system; we depend on systemd's logind period.'" Option B is, "The package manager says, 'I'm making this dependency change. Hope you can manage to get elogind up to scratch before the release; otherwise your package will be broken, but that's not my problem.'" Options D and H were variants on, "The non-systemd people have 6 months to get elogind up to parity with logind. Before 6 months, a breaking change would have to be reverted before release; after 6 months, a breaking change is allowed in a release." Personally I think H was the best option; the fact is they're all actually quite close. 425 people voted, and the deltas between them are 22, 31, and 34. The community is really quite divided still.
LessDmesg 7y ago
The vote's rigged, it didn't have the best option: "reject systemd and anything else made by Lennart Poettering"
- petre 7y ago
  Lennart Pottering.
  - LessDmesg 7y ago
    Corrected the name, but his surname is Poettering.
- phatfish 7y ago
  Lennart sure has damaged a lot of egos. No one else had the technical and soft skills required to replace a core part of a distributed project like "Linux user space". Or maybe more importantly didn't have the motivation to do so. It feels very much like when a new person turns up at work, with the same ideas you had, but could never get implemented or kept to yourself. Somehow they get it done. Either you embrace their success or become bitter.
  - LessDmesg 7y ago
    Poettering doesn't have any skills, as shown by both Pulseaudio and systemd, both of which are crap. Embracing systemd as the basis of Linux is just insanity. Now we real Linux users get to sit back and watch you people turn Linux into Lindows.
- progval 7y ago
  Options were submitted by potential voters. No one submitted this option, therefore it wasn't part of the vote.
gioele 7y ago
A couple of details for those who did not follow the discussion and are not familiar with Debian's voting system: * Proposal E "Support for multiple init systems is Required" has been firmly rejected. (In the Debian voting system, rating an option worse than "Further discussion" effectively means considering it even unworthy of being in the ballot.) * The core of Proposal B is «The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work». The full text can be found at https://www.debian.org/vote/2019/vote_002#textb https://www.debian.org/vote/2019/vote_002#textb * In case the message were not clear enough, the runner up option is Proposal E "Focus on systemd". Proposal E is also the most voted option.
- cperciva 7y ago
  You mean the runner up is Proposal F, yes?
- IceWreck 7y ago
  > Proposal E "Support for multiple init systems is Required" has been firmly rejected. > In case the message were not clear enough, the runner up option is Proposal E "Focus on systemd". Typo here, Its proposal F: Focus on systemd which is the runnerup and like you said E has been rejected.
- h1x 7y ago
  > the runner up option is Proposal F "Focus on systemd". Proposal F is also the most voted option. I'd say that in this voting system a statment like that is not really important in any way. You'd have to compare it to sum of options that don't focus on systemd as an example or some other combinations. * fixed proposal letter in the quote
  - dcow 7y ago
    I don’t think so. Looking at the most voted option tells you what the majority thinks. The voting system is designed to promote a most agreeable resolution not simply the majority’s choice, but knowing what the majority wants is still interesting.
antpls 7y ago
Rather than "considering alternatives", couldn't Debian invest time and money to make a public study of init systems with their pro and cons, then draft a spec of what they would like to have that doesn't already exist ?
- jdub 7y ago
  It's a community of mostly volunteer contributors. This vote shows what they've decided to do with their time and money.
- the_why_of_y 7y ago
  Recommended reading: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=1729;bug=727708 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=1729;bug=7... In case you don't have anything better to do for a week, the entire discussion can be read here, but be warned there's quite a bit of trolling in that thread: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
gwd 7y ago
The "graphical" page is a bit more interesting, I think, with a graph of how each option fared compared to the other ones: https://vote.debian.org/~secretary/gr_initsystems/ https://vote.debian.org/~secretary/gr_initsystems/ The ballot graph looks a bit strange to me. For one, votes seemed to come in all the way through the voting period, and actually increased just before the deadline. For two, nearly 20% of the ballots -- 100 out of 550 were rejected. I hope that's not evidence of "voting irregularities" -- the top 4 options were all within 50 points of each other. EDIT: From the bottom of the page: "Most of the bad ballots are due to the presence of a non printing character (usually one that displays as a space) in the ballot that confuses the parser. "
- JoshTriplett 7y ago
  > For one, votes seemed to come in all the way through the voting period, and actually increased just before the deadline. That doesn't seem surprising at all; many people vote (and rally others to vote) just under the wire. The same pattern appears in conference submission graphs; there's always a huge number of submissions on the last day.
- owl57 7y ago
  Wow. If 20% of the ballots are rejected in our next election due to some invisible garbage, the opposition and Western media will cry "they stopped even pretending to count the actual votes". Seriously, opinion on systemd and choice of software used to fill the ballot seem likely to be correlated.
- the_why_of_y 7y ago
  > For two, nearly 20% of the ballots -- 100 out of 550 were rejected. Of 552 ballots receieved, 548 passed "MIME Decoded" and 459 passed "Sig Check", with 452 Votes Tallied and 7 Bad Ballot - so, the vast majority of the failed ballots had invalid GPG signatures. This data doesn't tell you how many of the valid ballots were re-sends from voters who had previously sent in an invalid ballot.
  - tytso 7y ago
    Note that you get an e-mail either saying that your vote was accepted, or that your vote was rejected and why (bad GPG signature, unrecognized GPG key, mangled ballot, etc.) So if someone screws up, they know and can resend. Also, you're allowed to send in a second ballot which supersedes your previous ballot, up until the deadline. So if you change your mind during the voting period, you can update your selection.
jwildeboer 7y ago
FYI - here the full text of the winning proposal: https://www.debian.org/vote/2019/vote_002#textb https://www.debian.org/vote/2019/vote_002#textb Choice 2: B: Systemd but we support exploring alternatives Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus. The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include. Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.
- upofadown 7y ago
  >It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. This part directly addresses the current issue; people were just ignoring those that were working to make non-systemd debian possible and were refusing to even talk about the issue. It will be interesting to see what happens now if those people continue to behave in the same way. So this actually ends up being a victory for the non-systemd faction, at least in a political sense.
jbverschoor 7y ago
I don't get why people are so against systemd. I'm very happy using since it became available on debian. It's simply a clone of Apple's launchd. If it's about 'choice', go swap out your kernel for hurd or sth.
- ldng 7y ago
  It is not simply a clone of Apple's launchd. It's a lot more. Too much at that. It's about it getting in the way.
  - jbverschoor 7y ago
    Afaik they both do: - init - dependency management - inetd-type spawning - timed / cron launching - managing processes depending on network state or filesystem mounting
    - chongli 7y ago
      You’re missing some: - logging (replacing syslog) - login (replacing login managers such as ConsoleKit) - network configuration - tmpfiles - timedated (replacing ntpd) - udev (userspace /dev manager) - boot (replacing boot managers like grub) As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. The fact that it continues to grow and take over all these other facilities and the fact that the systemd team actively fights people trying to develop alternatives is why people hate the project so much.
      - throw0101a 7y ago
        Per JWZ's Law, I am waiting for it to read mail: * https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
      - fulafel 7y ago
        - systemd-nspawn (replacing Docker) - systemd-resolved (DNS resolver) - systemd-cryptsetup etc etc
aiCeivi9 7y ago
> alternate init systems Yeah, I am just end-user and I don't really care what is under the hood as long as it works, but isn't the biggest complaint against `systemd` is that it integrates a lot of other functions/subsystems that are not part of other init systems? And you kinda have to take whole package?
- the_why_of_y 7y ago
  The only non-init part of the systemd that is required is systemd-journald; every other part can be disabled at build time via configure switch, or at runtime by disabling the corresponding unit files. Whether optional parts can be disabled on any particular distro is the distro packagers' responsibility.
- seriesf 7y ago
  It does have a lot of features but my beef with it is how its integration into Debian still leaves all the misleading old cruft laying about. Take the MySQL server package. Suppose you want to change the limit of how much shared memory it can use. Well, the package comes with an init script, let’s put the ulimit statement in there. Restart. No effect. Ok, limits.conf. Restart. No effect. Ok, edit mysqld_safe script. Restart. No effect. Oh I figured it out, systemd ignores all these things and you have to set limits in its service file. But if you set it to ‘unlimited’ it silently ignores the statement. You have to say ‘infinity’ for some reason. All this crud has just been left here to confuse users and I hate it.
shrubble 7y ago
Can anyone recall a similar situation with a different piece of system software? Where it was shipping as a default and then was publicly questioned as to its utility?
- opan 7y ago
  New Windows versions, maybe. Or to keep more relevant, Wayland.
- VLM 7y ago
  Gnome Bash shell Pulseaudio The earliest days of grub bootloader, which is baroque complex compared to the LILO everyone used for years previous. Classic nvi as default vi (as opposed to vim) Some of the turn of the century weirdness around xfree86 and x.org fork battle Frankly, worship of POSIX was always tiresome to deal with.
  - marcosdumay 7y ago
    And the classical egcc vs. gcc, but this one is older than Debian. Anyway, Gnome was eventually downgraded into "an alternative"; Bash is not the default Debian default shell anymore, it's only default for interactive sessions; Pulse is impossible to get ride of nowadays and still impossible to use; the Grub one kept going until Grub2 that was actually better than LILO; vim won, hands down, as it should; everybody gave up on xfree86 once x.org become better. Except for pulse, as soon as the preferred alternative became better than the one the change-resistant people wanted, resistance simply vanished. Pulse is outed on the above example because well, it never became better than the alternatives, but still there was never any sizeable resistance, just some noise or lack of it.
- bitwize 7y ago
  HAL was widely used in the 2000s, and virtually nobody uses it now, as its functionality could be -- and was -- much more simply implemented inside udevd.
gorgoiler 7y ago
I think I understand the way Debian’s Condorcet voting works, but my word it is not at all obvious! Are there better examples of ways in which results like this can be presented more intuitively?
- jcranmer 7y ago
  Voting systems basically break down into two main processes: runoffs and Condorcet. In a runoff, you basically throw out failing candidates from the vote until you get a winner, with there being different criteria for who gets thrown out. In a Condorcet voting scheme, you instead consider all possible two-way races simultaneously. If one person wins all those races, they win the vote (Condorcet majority criterion). If such a person doesn't exist, different methods handle this scenario differently. A good way to think of it is like this. Runoff-style systems have the goal of maximizing happiness: prioritize giving more people their high-rank options. Condorcet-style systems have the goal of minimizing unhappiness: minimize giving people their low-rank options. If you have an electorate between two partisan candidates and a centrist candidate, most people are partisans who prefer their partisan candidate, and the partisans are roughly equivalent in strength, a runoff system is going to eliminate the centrist candidate first and give the election to a partisan, while a Condorcet system will find that more people prefer the centrist to the wrong partisan and give the election to the centrist.
smitty1e 7y ago
As a theoretical matter, non-systemd alternatives are as important as the HURD is to the Linux kernel. Practically, I'm booting Linux and using systemctl like a boss, chiefly due to that 24hour/day invariant that nobody escapes.
ai_ja_nai 7y ago
My God, this is so stale. It reminds me of Python 2 vs 3 debate. Get over it, Sys V is just not sufficient anymore.
- ddtaylor 7y ago
  Python 2 is now EOL https://pythonclock.org/ https://pythonclock.org/
- harryruhr 7y ago
  It's not about SysVInit. It's about supporting other init systems (OpenRC, runit, s6)
nealmcb2 7y ago
The raw ballots are available at https://www.debian.org/vote/2019/vote_002_tally.txt https://www.debian.org/vote/2019/vote_002_tally.txt It would be helpful to also have that shared in in a way that makes it easier to see how many top-ranks each choice had, how many bottom-ranks etc. But note that it seems that equal rankings are allowed, and many common ranked-choice cast vote record formats don't represent equal rankings.
johnr2 7y ago
First resignation: http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-December/002888.html http://www.chiark.greenend.org.uk/pipermail/debian-init-dive...
SuperSandro2000 7y ago
God thank you for not switching again. Nothing is worse than changing habbit all the time.
exabrial 7y ago
I was hoping uselessd would gain some traction. The thesis of the project started well

319 points by mroche 7y ago

In the event that the vote calculation is new to anyone else (it was to me), it looks like this [1] is what they are doing [1] https://en.m.wikipedia.org/wiki/Schulze_method https://en.m.wikipedia.org/wiki/Schulze_method

deleted 7y ago
[deleted]
usr1106 7y ago
This is considered one of the most democratic systems, it tries to make sure that the preferences of most voters are met in an optimal way. However, I would claim that with a list of 8 options it is close to impossible for a human to come up with a stable ordering. If you were to vote 3 times or 5 times without being allowed to look at your previous ballot sheets, how much would the votes change?
- heftig 7y ago
  You don't have to produce a well-ordered ballot. E.g. you can pick your favorites and let everything else share last place.
- pacifika 7y ago
  You vote once in the Schulze method
  - klez 7y ago
    That wasn't the point of GP's comment. Of course you only have one round of voting. Their point was, if you have 8 options and you don't really care for most of them (i.e. only the ordering of the first two or three matters to you) than the ordering of the options you don't care for won't carry much significance to the single voters (so they may order them randomly or leave them in the order they are presented), but it can matter in the end results. (I hope what I mean is clear, if not feel free to push me for clarification)
    - tialaramex 7y ago
      What you mean is _clear_ but it's _wrong_ Intentionally or not you've performed a little bit of sleight of hand. At first our voter doesn't care which of "most of them" gets chosen, they've no preference. Then one of these gets picked and "it can matter". But it doesn't matter to the voter we're thinking about at all. The people "it can matter" for thought hard about this option because it mattered to them by definition, and so their sincere preference was incorporated into the decision. By smuggling their preference back in as a concealed preference of other voters who didn't actually care, you inflate their position. If I say I don't care between Pizza and Burgers, and then Burgers win, you don't get to count me as a secret supporter of your "Let's eat these stale Doritos I found" faction just because you feel my support of Burgers ought not to really count.
- raverbashing 7y ago
  Funny how the most democratic systems are absolutely dependent on electronic vote, because no one can count all those different orderings by hand
  - Yen 7y ago
    I disagree with the assertion that "no one can count all those different orderings by hand". To steelman a bit, let's consider a worst-case brute force manual tabulation of the results (there certainly may be more efficient ways to do it by hand than what I write here): On a ranked ballot with 8 proposals, there's effectively (8 * 7)=56 binary options (do you prefer A over B, do you prefer B over A, do you prefer A over C, etc.) In this vote, there were 452 valid ballots. 452 * 56 = 25,312 individual data points to tabulate, into a 8x8 matrix of results. If reading an individual result off a ballot and counting it takes a person 1-10 seconds, the entire tabulation would take 7-70 person-hours. With that 8x8 matrix of individual results tabulated, determining the Condorcet winner (or the members of the Schulze set, if there's no Condorcet winner), takes less than 1 person-hour, by hand. Now, that's certainly not an instantaneous result, but it's certainly within the realm of feasibility for a completely non-electronic election or referendum. As another way of sanity-checking, consider that major elections in the U.S. often involve a combination of local, state, and federal ballots that can have upwards of 30 individual questions in total, and millions of ballots are cast, and results are typically certified within a fairly short timeframe. It offline's certainly the case that an all-electronic vote is faster, more convenient, and that this lower cost can also allow for more proposals on the ballot, and more frequent and more granular elections, but I'd say it's a far cray from being "absolutely dependent on electronic vote".
- JeremyNT 7y ago
  Is that stability actually an issue? It would seem to indicate that the voter has no strong preference for the items that they could not remember how to order consistently, and so either outcome would be roughly equally acceptable to them.
  - matthewbauer 7y ago
    It could mean that in a close vote like this, the result was due to random chance and not the will of voters. This does happen in fptp as well but not to this extreme.
- jchook 7y ago
  I have seen a lot of buzz around Quadratic Voting as an alternative. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531
- jcranmer 7y ago
  Schulze requires only a weak order of your votes: you can say that you like options B and C better than D, E, and F, but not prefer B over C or C over B. This is going to be an easier way to reflect your inner vote preference, because instability of votes is likely to be a result of choosing arbitrary orders for different tranches--and Schulze doesn't require you to pick that order.
  - usr1106 7y ago
    You are correct. The voter has the option to lead options unranked or rank several ones equally. So it's easier than having to come up with a complete ordering. Still, I would expect than many voters would come up with slightly different ballot sheets when having to do it several times. Did I give these 3 or 4 options the same low rank? Even if not required most Debian voters seem to give complete orderings https://www.debian.org/vote/2019/vote_001_tally.txt https://www.debian.org/vote/2019/vote_001_tally.txt in "normal" elections. In this complicated systemd voting less so https://vote.debian.org/~secretary/gr_initsystems/tally.txt https://vote.debian.org/~secretary/gr_initsystems/tally.txt

arcticbull 7y ago

Man, I feel like the Linux world is moving to systemd but this whole process has been like pulling teeth. I'm totally unaffected by this but even I'm feeling worn out on it. Feels like brexit, honestly -- nobody's enthusiastic about either systemd or sysv init, ok, fine, its happening but... ugh.

jakeogh 7y ago
The real mistake is having the arg in the first place. https://news.ycombinator.com/item?id=21842994 https://news.ycombinator.com/item?id=21842994
ernst_klim 7y ago
> nobody's enthusiastic The vast majority of people are fine with it, it's just the loud minority opposes it. The bulk of linux userbase is systemd only: Centos, Ubuntu, Arch, Opensuse, Fedora. I think these 5 have already 90+% of installations.
- kijin 7y ago
  Fine doesn't mean enthusiastic. Most people are just going along with the trend with no strong preference either way. I'm actually quite fond of systemd now that I'm used to it, but I wouldn't have "moved" to systemd if it wasn't for the major distros making the choice for me.
  - oaiey 7y ago
    Are not the distros who design the composition of the actual overall system the exact right people to make this call? In an ideal world (and by your comment I assume you are close to it) you do not care or maybe even realize which startup system the system utilizes.
    - int_19h 7y ago
      That is only true for a casual user's desktop, maybe. If you're a power user or a server admin, you will likely be setting up services, or diagnosing their failures, at some point - and then the features and the ergonomics of the init system are very relevant.

usr1106 7y ago

For those of us who have forgotten the details https://lwn.net/Articles/806332 https://lwn.net/Articles/806332

usr1106 7y ago

More statistics https://vote.debian.org/~secretary/gr_initsystems/ https://vote.debian.org/~secretary/gr_initsystems/

oaiey 7y ago

I am curious about the "exploring alternatives". Anything known about that?

deleted 7y ago
[deleted]
peterwwillis 7y ago
Basically it just means "if somebody proposes something better we won't tell them to go screw themselves by default". Which I think is very important, as the future of operating systems like Linux is where it has been for the past 2 decades: in distributed computing. For non-desktop computing, what we really need are distributed operating systems. We have been poorly cobbling them together for decades, yet only a few research operating systems actually ship the needed functionality. Currently we use an array of layers of things, like hypervisors, container schedulers, service meshes, etc to sort of fudge together something that can do distributed computing in very specific ways. But they're all very complex, costly, and time-consuming to set up, and usually tailored to specific use cases. What we need is for Linux itself to natively ship all a distributed OS's features, so that apps can simply take advantage of them without having to be strapped into 20 layers of glue. But at the current pace of kernel development, I imagine it'd take 10 years to get all those patches developed, tested, and merged. So instead you could merge only the most core functionality, and extend the rest into the userland, and you'd get something kinda resembling systemd, but actually oriented toward running apps and services on a distributed network. I believe that would make most Linux-specific "cloud" technology obsolete, and in the process greatly simplify the entire technology stack, reducing TCO, speeding up development, and simplifying operations. Assuming that gets developed, "exploring alternatives" is a necessity to eventually get it adopted into Debian, so I'm really glad at least the option is there.
- JdeBP 7y ago
  According to Ian Jackson, it was other options and not option B that were the options that encompassed not telling people to go screw themselves. * https://diziet.dreamwidth.org/3482.html https://diziet.dreamwidth.org/3482.html * https://diziet.dreamwidth.org/3999.html https://diziet.dreamwidth.org/3999.html

earenndil 7y ago

> Dropping Option 6 because of Majority. (0.8084112149532710280373831775700934579439) 0.808 (173/214) < 1 Not particularly relevant, but is there any reason to include that many digits, especially when the source-of-truth fraction is right there?

fake-name 7y ago
99% chance it's just some calculation tool not truncating. I wouldn't be surprised if that text is machine generated from a template.
- mike_hock 7y ago
  It's obviously tool-generated. I think the question was, why does the tool show the non-truncated value for that one line, considering it put the truncated (%0.03f) version right next to it.
  - JdeBP 7y ago
    Here's the repository. Look it up and tell us. * https://vote.debian.org/~secretary/devotee.git/ https://vote.debian.org/~secretary/devotee.git/
    - mike_hock 7y ago
      What do you want me to tell you? dvt-rslt:367-368 the ratio is interpolated into the string output without any format specification (resulting in the full decimal expansion), whereas in the passing case (line 382) it is not. The ratio is formatted with %6.3f in both cases (369-372, 384-387). That's what it does. Doesn't tell us why (though it looks like a simple oversight on the programmer's part).
    - nemetroid 7y ago
      Just for fun, I had a look. The commit which adds the non-truncated print changed some behaviour with regard to < vs <=, so it might have been added for debugging purposes and simply never removed.

hazeii 7y ago

I hope that "exploring alternatives" isn't code for dropping sysvinit. Even with the latest debian, switching away from systemd is easy as:- apt-get install sysvinit-core sysvinit-utils cp /usr/share/sysvinit/inittab /etc/inittab reboot apt-get remove --purge --auto-remove systemd Our reasons for doing this are we run stripped-down systems that go for years (even decades), but which we absolutely must be able to fix ourselves with the proverbial rusty hairclip. The general bloat of linux distros (due to gnome/systemd and others) really doesn't suit our use case (although obviously it suits others, even the majority).

ckastner 7y ago
> I hope that "exploring alternatives" isn't code for dropping sysvinit. It's not about dropping, it's about how much effort the invididual maintainer must put into a package to support sysvinit, with the answer now being "none". The burden of work is shifted to from the maintainer those wishing to support sysvinit (or any other alternative).
- japanoise 7y ago
  That's probably for the best. Writing init scripts is easy enough for that small percentage of users (like gp) who really need it. Good choice on Debian's part, imho.
  - gwd 7y ago
    The issue isn't actually so much about writing init scripts, as about all the other bits of functionality that systemd has been aquiring. One example apparently is logind. Important key packages have (as I understand it) started depending on functionality provided by logind; I think something like "Gnome Desktop". Which would mean, if you want to run Debian with Gnome, you have to run systemd. The non-systemd crowd wrote elogind in response to this. But of course, now elogind is in a situation like WordPerfect was with Microsoft Word back in the 90's -- trying to remain compatible with a moving target. So the point of this vote is to answer the question: How does a package manager of a package like the "Gnome desktop" interact with the non-systemd crowd, when they want to depend on a new feature that's in logind but not in elogind? Option F is basically, "The package manager says, 'systemd is our primary init system; we depend on systemd's logind period.'" Option B is, "The package manager says, 'I'm making this dependency change. Hope you can manage to get elogind up to scratch before the release; otherwise your package will be broken, but that's not my problem.'" Options D and H were variants on, "The non-systemd people have 6 months to get elogind up to parity with logind. Before 6 months, a breaking change would have to be reverted before release; after 6 months, a breaking change is allowed in a release." Personally I think H was the best option; the fact is they're all actually quite close. 425 people voted, and the deltas between them are 22, 31, and 34. The community is really quite divided still.

LessDmesg 7y ago

The vote's rigged, it didn't have the best option: "reject systemd and anything else made by Lennart Poettering"

petre 7y ago
Lennart Pottering.
- LessDmesg 7y ago
  Corrected the name, but his surname is Poettering.
phatfish 7y ago
Lennart sure has damaged a lot of egos. No one else had the technical and soft skills required to replace a core part of a distributed project like "Linux user space". Or maybe more importantly didn't have the motivation to do so. It feels very much like when a new person turns up at work, with the same ideas you had, but could never get implemented or kept to yourself. Somehow they get it done. Either you embrace their success or become bitter.
- LessDmesg 7y ago
  Poettering doesn't have any skills, as shown by both Pulseaudio and systemd, both of which are crap. Embracing systemd as the basis of Linux is just insanity. Now we real Linux users get to sit back and watch you people turn Linux into Lindows.
progval 7y ago
Options were submitted by potential voters. No one submitted this option, therefore it wasn't part of the vote.

gioele 7y ago

A couple of details for those who did not follow the discussion and are not familiar with Debian's voting system: * Proposal E "Support for multiple init systems is Required" has been firmly rejected. (In the Debian voting system, rating an option worse than "Further discussion" effectively means considering it even unworthy of being in the ballot.) * The core of Proposal B is «The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work». The full text can be found at https://www.debian.org/vote/2019/vote_002#textb https://www.debian.org/vote/2019/vote_002#textb * In case the message were not clear enough, the runner up option is Proposal E "Focus on systemd". Proposal E is also the most voted option.

cperciva 7y ago
You mean the runner up is Proposal F, yes?
IceWreck 7y ago
> Proposal E "Support for multiple init systems is Required" has been firmly rejected. > In case the message were not clear enough, the runner up option is Proposal E "Focus on systemd". Typo here, Its proposal F: Focus on systemd which is the runnerup and like you said E has been rejected.
h1x 7y ago
> the runner up option is Proposal F "Focus on systemd". Proposal F is also the most voted option. I'd say that in this voting system a statment like that is not really important in any way. You'd have to compare it to sum of options that don't focus on systemd as an example or some other combinations. * fixed proposal letter in the quote
- dcow 7y ago
  I don’t think so. Looking at the most voted option tells you what the majority thinks. The voting system is designed to promote a most agreeable resolution not simply the majority’s choice, but knowing what the majority wants is still interesting.

antpls 7y ago

Rather than "considering alternatives", couldn't Debian invest time and money to make a public study of init systems with their pro and cons, then draft a spec of what they would like to have that doesn't already exist ?

jdub 7y ago
It's a community of mostly volunteer contributors. This vote shows what they've decided to do with their time and money.
the_why_of_y 7y ago
Recommended reading: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=1729;bug=727708 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=1729;bug=7... In case you don't have anything better to do for a week, the entire discussion can be read here, but be warned there's quite a bit of trolling in that thread: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708

gwd 7y ago

The "graphical" page is a bit more interesting, I think, with a graph of how each option fared compared to the other ones: https://vote.debian.org/~secretary/gr_initsystems/ https://vote.debian.org/~secretary/gr_initsystems/ The ballot graph looks a bit strange to me. For one, votes seemed to come in all the way through the voting period, and actually increased just before the deadline. For two, nearly 20% of the ballots -- 100 out of 550 were rejected. I hope that's not evidence of "voting irregularities" -- the top 4 options were all within 50 points of each other. EDIT: From the bottom of the page: "Most of the bad ballots are due to the presence of a non printing character (usually one that displays as a space) in the ballot that confuses the parser. "

JoshTriplett 7y ago
> For one, votes seemed to come in all the way through the voting period, and actually increased just before the deadline. That doesn't seem surprising at all; many people vote (and rally others to vote) just under the wire. The same pattern appears in conference submission graphs; there's always a huge number of submissions on the last day.
owl57 7y ago
Wow. If 20% of the ballots are rejected in our next election due to some invisible garbage, the opposition and Western media will cry "they stopped even pretending to count the actual votes". Seriously, opinion on systemd and choice of software used to fill the ballot seem likely to be correlated.
the_why_of_y 7y ago
> For two, nearly 20% of the ballots -- 100 out of 550 were rejected. Of 552 ballots receieved, 548 passed "MIME Decoded" and 459 passed "Sig Check", with 452 Votes Tallied and 7 Bad Ballot - so, the vast majority of the failed ballots had invalid GPG signatures. This data doesn't tell you how many of the valid ballots were re-sends from voters who had previously sent in an invalid ballot.
- tytso 7y ago
  Note that you get an e-mail either saying that your vote was accepted, or that your vote was rejected and why (bad GPG signature, unrecognized GPG key, mangled ballot, etc.) So if someone screws up, they know and can resend. Also, you're allowed to send in a second ballot which supersedes your previous ballot, up until the deadline. So if you change your mind during the voting period, you can update your selection.

jwildeboer 7y ago

FYI - here the full text of the winning proposal: https://www.debian.org/vote/2019/vote_002#textb https://www.debian.org/vote/2019/vote_002#textb Choice 2: B: Systemd but we support exploring alternatives Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus. The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include. Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.

upofadown 7y ago
>It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. This part directly addresses the current issue; people were just ignoring those that were working to make non-systemd debian possible and were refusing to even talk about the issue. It will be interesting to see what happens now if those people continue to behave in the same way. So this actually ends up being a victory for the non-systemd faction, at least in a political sense.

jbverschoor 7y ago

I don't get why people are so against systemd. I'm very happy using since it became available on debian. It's simply a clone of Apple's launchd. If it's about 'choice', go swap out your kernel for hurd or sth.

ldng 7y ago
It is not simply a clone of Apple's launchd. It's a lot more. Too much at that. It's about it getting in the way.
- jbverschoor 7y ago
  Afaik they both do: - init - dependency management - inetd-type spawning - timed / cron launching - managing processes depending on network state or filesystem mounting
  - chongli 7y ago
    You’re missing some: - logging (replacing syslog) - login (replacing login managers such as ConsoleKit) - network configuration - tmpfiles - timedated (replacing ntpd) - udev (userspace /dev manager) - boot (replacing boot managers like grub) As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. The fact that it continues to grow and take over all these other facilities and the fact that the systemd team actively fights people trying to develop alternatives is why people hate the project so much.
    - throw0101a 7y ago
      Per JWZ's Law, I am waiting for it to read mail: * https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles
    - fulafel 7y ago
      - systemd-nspawn (replacing Docker) - systemd-resolved (DNS resolver) - systemd-cryptsetup etc etc

aiCeivi9 7y ago

> alternate init systems Yeah, I am just end-user and I don't really care what is under the hood as long as it works, but isn't the biggest complaint against `systemd` is that it integrates a lot of other functions/subsystems that are not part of other init systems? And you kinda have to take whole package?

the_why_of_y 7y ago
The only non-init part of the systemd that is required is systemd-journald; every other part can be disabled at build time via configure switch, or at runtime by disabling the corresponding unit files. Whether optional parts can be disabled on any particular distro is the distro packagers' responsibility.
seriesf 7y ago
It does have a lot of features but my beef with it is how its integration into Debian still leaves all the misleading old cruft laying about. Take the MySQL server package. Suppose you want to change the limit of how much shared memory it can use. Well, the package comes with an init script, let’s put the ulimit statement in there. Restart. No effect. Ok, limits.conf. Restart. No effect. Ok, edit mysqld_safe script. Restart. No effect. Oh I figured it out, systemd ignores all these things and you have to set limits in its service file. But if you set it to ‘unlimited’ it silently ignores the statement. You have to say ‘infinity’ for some reason. All this crud has just been left here to confuse users and I hate it.

shrubble 7y ago

Can anyone recall a similar situation with a different piece of system software? Where it was shipping as a default and then was publicly questioned as to its utility?

opan 7y ago
New Windows versions, maybe. Or to keep more relevant, Wayland.
VLM 7y ago
Gnome Bash shell Pulseaudio The earliest days of grub bootloader, which is baroque complex compared to the LILO everyone used for years previous. Classic nvi as default vi (as opposed to vim) Some of the turn of the century weirdness around xfree86 and x.org fork battle Frankly, worship of POSIX was always tiresome to deal with.
- marcosdumay 7y ago
  And the classical egcc vs. gcc, but this one is older than Debian. Anyway, Gnome was eventually downgraded into "an alternative"; Bash is not the default Debian default shell anymore, it's only default for interactive sessions; Pulse is impossible to get ride of nowadays and still impossible to use; the Grub one kept going until Grub2 that was actually better than LILO; vim won, hands down, as it should; everybody gave up on xfree86 once x.org become better. Except for pulse, as soon as the preferred alternative became better than the one the change-resistant people wanted, resistance simply vanished. Pulse is outed on the above example because well, it never became better than the alternatives, but still there was never any sizeable resistance, just some noise or lack of it.
bitwize 7y ago
HAL was widely used in the 2000s, and virtually nobody uses it now, as its functionality could be -- and was -- much more simply implemented inside udevd.

gorgoiler 7y ago

I think I understand the way Debian’s Condorcet voting works, but my word it is not at all obvious! Are there better examples of ways in which results like this can be presented more intuitively?

jcranmer 7y ago
Voting systems basically break down into two main processes: runoffs and Condorcet. In a runoff, you basically throw out failing candidates from the vote until you get a winner, with there being different criteria for who gets thrown out. In a Condorcet voting scheme, you instead consider all possible two-way races simultaneously. If one person wins all those races, they win the vote (Condorcet majority criterion). If such a person doesn't exist, different methods handle this scenario differently. A good way to think of it is like this. Runoff-style systems have the goal of maximizing happiness: prioritize giving more people their high-rank options. Condorcet-style systems have the goal of minimizing unhappiness: minimize giving people their low-rank options. If you have an electorate between two partisan candidates and a centrist candidate, most people are partisans who prefer their partisan candidate, and the partisans are roughly equivalent in strength, a runoff system is going to eliminate the centrist candidate first and give the election to a partisan, while a Condorcet system will find that more people prefer the centrist to the wrong partisan and give the election to the centrist.

smitty1e 7y ago

As a theoretical matter, non-systemd alternatives are as important as the HURD is to the Linux kernel. Practically, I'm booting Linux and using systemctl like a boss, chiefly due to that 24hour/day invariant that nobody escapes.

ai_ja_nai 7y ago

My God, this is so stale. It reminds me of Python 2 vs 3 debate. Get over it, Sys V is just not sufficient anymore.

ddtaylor 7y ago
Python 2 is now EOL https://pythonclock.org/ https://pythonclock.org/
harryruhr 7y ago
It's not about SysVInit. It's about supporting other init systems (OpenRC, runit, s6)

nealmcb2 7y ago

The raw ballots are available at https://www.debian.org/vote/2019/vote_002_tally.txt https://www.debian.org/vote/2019/vote_002_tally.txt It would be helpful to also have that shared in in a way that makes it easier to see how many top-ranks each choice had, how many bottom-ranks etc. But note that it seems that equal rankings are allowed, and many common ranked-choice cast vote record formats don't represent equal rankings.

johnr2 7y ago

First resignation: http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-December/002888.html http://www.chiark.greenend.org.uk/pipermail/debian-init-dive...

SuperSandro2000 7y ago

God thank you for not switching again. Nothing is worse than changing habbit all the time.

exabrial 7y ago

I was hoping uselessd would gain some traction. The thesis of the project started well