Debian Init GR result: "B: Systemd but we support exploring alternatives" by 22 votes

The winning proposal is here
Can someone explain how this voting works? Never seen anything like that before.
It doesn't even tell how many votes each individual item got, it only gives the indirect information on that - how many votes other items got over a specific item. And why there are no negatives? If X is 20 votes and Y is 40 votes, wouldn't X receive -20 votes over Y? And Y obviously positive 20 votes over X - the chart has to be symmetric over the diagonal, just with a flipped sign, yet it isn't symmetric for some reason: row 1 col 2 is 185, but row 2 col 1 is 207. How can you find X and Y such that X-Y=185 and Y-X=207?
The first table has the amount of votes each option got above each other.
That table is the number of users that prefered one option over another not as you seem to be implying the number of users that prefered one option substrates by the number that prefered the other options. In other words they are X and Y. The differences are below.
in terms of init freedom/diversity is this better or worse than it was before?
It boils down to "anything but systemd will be on the developers of alternative init systems and package maintainers to provide support".
Let's take a look at the result (as I understand it):
The wining propsal says "systemd first, others might do something else if they want" (proposal B)
Second place was "systemd only, fuck the rest" (proposal F)
Third place was "other inits are fine if they do not block us from going forward with systemd" (proposal D)
Last spot is reserved for "multiple inits are supported".
"Multiple inits are required" was entirely rejected.
That surely sounds like we have a divided community with an effective majority for init freedom to me.
A nice graph of the result set can be found here:
(Edited the last two proposals, add link to result page)
Init scripts were always a mess to upgrade and that is what made me to switch from sysv to systemd (+ logging)
That and systemd service files are declarative and are largely portable between distributions.
init shell scripts are not.
It's funny that people keep bringing up 'do one thing well' and 'be portable' as arguments against systemd when it's plainly obvious that these are more of a indictment against continued use of sysv more then anything else.
The only difference is that the people that want to use alt init system are the ones that have to do the work. They no longer get to try to use Debian's bureaucratic nature to try to force contributors to spend a great deal of their personal time on maintaining scripts and code that really isn't necessary.
If you want to produce a shitload of OpenRC code to make Debian work nobody is going to hunt you down and stop you from doing it. Doing this work would also be a tiny fraction of the work necessary to make a OpenRC-centric distribution.
The real reason why systemd 'won' the 'init wars' is because people were willing to put the work into making it work and that didn't happen for the other init systems. Except for sysv, of course. But the people doing the actual work into making sysv work generally hated it far more then then working on systemd. Generally speaking.
I think I'd have to agree, even as a systemd fan supporting both basically entails a compromise design which no one is happy with.
I live systemd-free currently, but shit, now its probably just a matter of time until packages drop the sysv style init scripts.
However, it shouldn't be too hard to patch deb packages to get rid of their hard dependencies on systemd, if any, and then add some sysv style init scripts by hand. Then running a local debian repo to serve the patched packages. I heard many FreeBSD people take a similar approach when they customize ports. Well anyways, where there is open source there is always a way.
Yeah sure, as long as somebody (you?) is doing the work, test the result and can guarantee the maintainer that he will continue to do so in the future to not impede the work of the maintainer when there is a (security) bug or a new upstream release.
I believe the resolution indicates "patches accepted".
Lots of that work is already done by the marvelous people at Antix working on the nosystemd repo which, basically, consists of software recompiled or repackaged to allow-but-not-require systemd. Network Manager comes to mind. I have had this repo enabled on all my machines since jessie and it's a godsend.
In fact I'm (not that much, alas) surprised it's not just merged into main Debian.
This is good. The last few years updates have bot gotten along with Systemd for me.
Sure, but things are going to change for devuan, since so far a lot of the work to keep sysvinit working has been done in debian itself. This GR result will probably mean that devuan will have significantly more work ...
Considering how
Completely predictable given the late 2014 GR (
--- Debian User (from 2000 to late 2014).
Guess I stay on Devuan then.
It doesn't seem clear what the effect of this choice will be. Last I looked at the debian policy guide which is the rulebook for package maintainers, the debian policy guide stated that all packages had to have sysV init scripts if appropriate or whatever. The way I read proposal B it's entirely superficial with no real effect. Thousands of debian packages are still technically not following official debian policy by their maintainers in an act to sabotage debian have removed the required SysV support.
Debian's policy is not set into stone by a superior being, it is a living document that changes all the time. And one that is almost always outdated in some parts:-)
Policy will surely change now that there is this GR.
Let's say a package maintainer does drop the SysV support for a package..
What can the Debian project do? Fire him? Or merely stop cutting the paychecks and wait the things to work out in the end..
Removing a Debian developer would also mean the packages maintained by such a person would be left without maintenance, unless someone else were to pick them up. So probably not something that's done without a very big reason.
install gentoo
At some point it would seem logical that a lot of distros need to be killed off and merged. They all appear to be doing exactly the same thing, to exactly the same standard, and the only differences seem to be branding and package selection (and lack of a sane installer if you're particularly special)
Debian doesn't need to exist when Ubuntu does a better job. Now that SystemD is the only supported init-system it's the same distro as dozens more. Kernel + GNU tools + SystemD + PulseAudio + GNOME or KDE. Big wow.
I mean I agree that there are too many distros and many are redundant.
But Ubuntu is built on top of Debian. If you’re going to get rid of one, wouldn’t it be Ubuntu?
If you wanted uniform everything you should just return to windows or Mac.
You're being downvoted by people mad that you're accurate.
What a nice bikeshed.... Between the numerous options that seem to have no significant difference (honestly what is the difference between #1 and #2), and the ridiculously crazy voting process (45.224440295044 WTF???), I'm surprised they were even able to get to the point of having any kind of vote.
The voting is just numbering by preference. The actual ballot looks simpler than the tally.
There is a great deal of overhead in a project like Debian in maintaining multiple init systems. The difference between #1 and #2 is that the overhead is allowed to exist, but it's on the shoulders of people who want to use alternative init systems to make it work.
What this will likely end up in practice is that a lot of packages will ship with a lot of configuration and code that almost nobody uses. Which sucks. But they will continue working for the time being and won't break people's sysv init installs. Over the next couple releases as "anything but systemd" crowd lose interest and accept the changes then the various shell scripts and perl programs will become increasingly stale. People will file bug reports, press the issue, refuse to do the work themselves, and then the developers will end up purging the code instead in order to close the bugs.
It's a hell of a lot superior then anything people use to elect government representatives.
The voting system may look crazy to you, but it works remarkably well, and they use it at least once a year to pick the Project Leader. (More often if other things need to be voted on, like this resolution.)