
Debian votes for Proposal B, “Systemd but we support exploring alternatives” - mroche
https://vote.debian.org/~secretary/gr_initsystems/results.txt
======
gioele
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.

~~~
h1x
> 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
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_.

~~~
h1x
> knowing what the majority wants is still interesting.

Totally agree.

> Looking at the most voted option tells you what the majority thinks.

My point is that the options are designed specifically for this type of voting
system.

Here it is possible that anti-systemd votes are spread across many options and
pro systemd votes are concentrated in only one or two. So even if you have
most votes on "Focus on systemd" it doesn't mean that it is what most people
want.

~~~
Tuna-Fish
> Here it is possible that anti-systemd votes are spread across many options
> and pro systemd votes are concentrated in only one or two. So even if you
> have most votes on "Focus on systemd" it doesn't mean that it is what most
> people want.

As I said in my above reply which you've ignored, that is not how the voting
system works. It is not possible to split votes like that in Condorcet.
Everyone who opposes systemd can vote for all of the non-systemd options and
not diminish the chances of any of them.

~~~
shawnz
They are talking about the result of the majority vote, not the result of the
Condorcet method.

~~~
cyphar
The result of the "majority vote" is done preferentially, which means that
there is no situation in which vote splitting will occur. It makes no sense to
refer to the "majority vote" in this context, because the whole point of
preferential voting systems is that (usually) no option wins outright on first
preferences alone. Thus the result of the Condorcet vote is the order which
the maximum number of people would've been most happy with.

------
hazeii
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).

~~~
thristian
I hope it does involve removing sysvinit. Compared to alternatives like runit
or s6, sysvinit increases bloat (because every service needs to include it's
own daemonising and logging code) and makes systems brittle and difficult to
debug (because the classic daemonisation process is subtle and easy to get
wrong). If I had to build a stripped-down, ultra-stable, long-running system,
I definitely wouldn't want to build it on sysvinit.

~~~
hazeii
Well, seems to have worked for us for 20+ years. I wonder where gnome and
systemd will be in 20 years?

Horses for courses.

~~~
xyproto
Systemd can do things that were not relevant 20 years ago.

~~~
castis
That's true but what we're hoping for is that Debian doesn't change things so
much that sysvinit is unusable. Systemd does have its advantages but some
people _like_ sysvinit.

~~~
shawnz
> but some people _like_ sysvinit

Is that really true, or is it just that some people have a grudge against
systemd and sysvinit is the only other practical option?

~~~
krzyk
sysvinit is simple, and I didn't have any major issues with it.

On the other hand, systemd is too big, takes on too much responsibility
(really I need a system to retrieve logs in it? or a way to run local dns?).

Since last update on my ubuntu desktop I can't get dns to work from DHCP, I
need to overwrite /etc/resolv.conf with correct nameservers after each restart
(BTW. Why would anyone think that running local DNS is a good default option -
I see `nameserver 127.0.0.1` in the overwritten file).

And the second one on Debian on my laptop, when I run VPN (openconnect) name
resolution fails, and I need again - ovewrite resolv.conf.

I didn't have such problems with sysvinit.

systemd is so controversial that I'm astonished why it is used in any distro.

~~~
ernst_klim
> sysvinit is simple, and I didn't have any major issues with it.

How do you encode service dependencies? If a service dies, what happens to
services relying on it on your system?

~~~
csande17
At least on my desktop machine, there aren't a whole lot of services that
directly depend on other services. Usually, a service will provide some
functionality (e.g. sound) used by _applications_ I launch. As far as I know,
systemd doesn't help with that, and I don't really want it to--imagine if
systemd suddenly killed and restarted your browser!

Also, maybe I'm just lucky (or using popular hardware, or something), but
services on my machine don't just randomly die for no reason. NetworkManager,
sshd, etc all seem pretty well-written and stable.

~~~
ernst_klim
>As far as I know, systemd doesn't help with that

It depends on the service in use and how is it defined. I have an embedded
system in production, which have quite a complex graph of dependencies, some
of which should be restarted on sudden death of others, some of which should
persist anyways.

Needless to say that systemd provides an incredible, robust and easy way of
solving that, I had to write just a few 10-line long unit files for in-house
software and use standard units provided by standard daemons.

>imagine if systemd suddenly killed and restarted your browser

Because your browsed doesn't rely on them. But my web interface definitely
depends on NetworkManager, because it speaks to it via d-bus.

~~~
csande17
To clarify, by "systemd doesn't help with that", I meant "systemd does not
attempt to manage, track service dependencies of, or restart applications I
launch through my desktop's Applications menu or in a Terminal window".

Which is a good thing! Even though my browser uses/"depends on" audio, I still
don't want systemd to restart it without warning if PulseAudio dies.

~~~
zaarn
Your browser can encode that it doesn't have to restart if pulse dies. Wants=
will try to ensure Pulse is started but if Pulse cannot start or crashes,
that's fine. Requires= will ensure pulse is started but doesn't do anything if
it crashes. Only BindsTo= will stop the browser if pulse crashes.

------
kardos
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)

~~~
usr1106
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?

~~~
JeremyNT
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
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.

------
jwildeboer
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
>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
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.

~~~
simion314
The issue I noticed are

\- systemd supporters are mainly desktop users, so their opinions are
irrelevant because as a desktop user the only thing you might do is restart a
service, is important to listen to server admins that know what they are
talking about

\- GNOME (other Red Hat tech) depends on a systemd component and refuses
patches to make it independent, so basically GNOME is forcing systemd adoption
and is trying to block alternatives by refusing patches

\- systemd projects and fans will ask you to create a better alternative to
systemd if you don't like it, but if you try to promote an alternative they
will try to block the alternatives by refusing to accept patches to keep
projects systemd independent.

Monoclultures are bad, when systemd will o longer be popular and we want to
implement a better succesor we will discover that many things are hard coded
to depend on some it's many components.

About what is the best init system, I don't know , I am desktop user, and as I
said all desktop users opinions are probably "it works for me so you are
wrong"

~~~
ninkendo
> systemd supporters are mainly desktop users

> is important to listen to server admins that know what they are talking
> about

Huh?

I got on the systemd train when race conditions with pidfiles caused essential
services not to restart correctly for the umpteenth time on a small subset of
the thousands of bare metal servers I managed.

Not a single sysadmin I worked with liked anything about sysvinit. Nearly
every distro-provided init script for the services we cared about had some
sort of subtle bug which we had to manually fix with our configuration
management.

Or maybe somebody had been diagnosing an issue and manually run “sudo
/etc/init.d/someservice start” and now congratulations, the service inherited
the cwd of the person who ran the init script.

Or you have to deal with inconsistent log rotation behavior, or the service
coming up before the network was ready on boot (better rename the symlink to
99_myservice!)

I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe
ones that only run one or two servers? After having managed tens of thousands
of them across many datacenters, systemd is a clear and obvious win.

~~~
simion314
I am not saying that all/most sysadmins hate systemd , I am just annoyed but
the random Joe Desktop Linux users throwing his opinion. I like reading
sysadmin experience and what issues they have like you but also ones that had
issues with systemd bugs and behavior and a random Fedora user will show up
and repeat something he has no clue about.

I personally had no issue with systemd or upstart or any other I used so I
would wish desktop user like me would read more and comment less about what is
better.

~~~
xnyan
Are the uninformed opinions of joe user really influencing decision makers?
The internet is mostly filled with people spouting uninformed opinions, it
does not seem worth it to spend any energy caring about it.

~~~
simion314
I don't think the decisions made in Debian were influenced a lot by the
average joe user, my complaint is about the discussions, my complaint is that
say if I find a thread that compares all the init systems I would prefer to
read expert opinions on it, people that had success with systemd but also
people that had trouble with systemd , but you get average joe pasting same
shit all the time on both sides.

But yeah you are right(this always happens on the internet), I was also guilty
of this, I remember back when C# appeared and I was sure is the best thing
ever and it will soon replace all the other languages. I think at my past
enthusiasm for C# when I see Rust/Go/CoolLang evangelizing why X is better and
in 3 years it will dominate.

------
usr1106
For those of us who have forgotten the details
[https://lwn.net/Articles/806332](https://lwn.net/Articles/806332)

------
gwd
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. "

~~~
the_why_of_y
> 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
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.

------
earenndil
> 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
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
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
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
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).

------
aiCeivi9
> 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
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.

------
smitty1e
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.

------
arcticbull
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.

~~~
gwd
The real problem I have with systemd isn't the technology itself, as much as
the attitude of the people who run it.

Off the top of my head, issues I've seen with systemd:

* At some point there was no way to say, "bring up this service once the network is up". I mean, there was technically a "network" target, but it considered "localhost" as a network. So if, say, you have automounted NFS, the automounter starts running before your main interface has DHCP. This setup been a widely-used configuration for decades; the systemd maintainers didn't care.

* At some point, if you typed "reboot ; exit" in an ssh session, the "reboot" would hard-kill your ssh session and your shell before the "exit" would be run; so your ssh connection would then hang until the machine came up again and refused a TCP resend request.

* The whole thing with systemd reading the kernel's command-line, deciding that "debug" was meant for it, and spamming the logs making it completely unable to boot; and forcing the kernel to introduce a work-around to hide "debug" from systemd.

* The whole interface renaming thing that's happening in Debian now; every time our project has upgraded our test systems from jessie to stretch, and then stretch to buster, we've had to spend dozens of man-hours figuring out why our network configurations aren't working.

The problem here isn't so much that there are these sorts of bugs; the problem
is that there seems to be an attitude of, "Well my set-up works; yours doesn't
matter." That's not the attitude such a core piece of infrastructure should
have.

Compare this to Linus' nearly fanatical insistence that things in userspace
should continue to work. If Lennart Pottering had the same attitude towards
breaking existing systems that Linus has, systemd would probably be incredibly
popular.

~~~
merb
well the first point is fixed when using networkd. the problem is/was that
many systems used their own network solution, like networkmanager (RedHat)
which did not fit well into systemd

~~~
dmurray
But that's a big problem: if the scope of systemd is just to be an init
system, its answer to everyone who wants to make their tools work with systemd
shouldn't be "just use our loosely associated tools instead".

------
usr1106
More statistics
[https://vote.debian.org/~secretary/gr_initsystems/](https://vote.debian.org/~secretary/gr_initsystems/)

------
nealmcb2
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.

------
shrubble
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?

~~~
VLM
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
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.

------
johnr2
First resignation:

[http://www.chiark.greenend.org.uk/pipermail/debian-init-
dive...](http://www.chiark.greenend.org.uk/pipermail/debian-init-
diversity/2019-December/002888.html)

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

~~~
peterwwillis
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
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)

~~~
tialaramex
Though he insists on claiming to be "neutral" Ian's position explained in the
latter link was to rank E (the only thing rejected more firmly than Further
Discussion in this vote in the end) near the top. Option E purports to force
every Debian contributor to do the heavy lifting for the systemd refuseniks,
their desires are "Required" by the project to be implemented.

Actually, with a tiny amount of human insight, what Option E forces is really
either: Another vote to kick out the refuseniks because this is intolerable OR
most Debian contributors quit and the project gradually stagnates.

The Diziet sobriquet seems appropriate. Diziet Sma is the Special
Circumstances agent "running" the win-at-all-costs mercenary Zakalwe in Iain M
Banks' novel "Use of Weapons". Win-at-all-costs is a reasonable strategic
choice in the last place we see Zakalwe (the War on Hells in "Surface Detail")
but it's probably a bad idea in a volunteer project like Debian.

------
gorgoiler
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
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.

------
antpls
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 ?

~~~
the_why_of_y
Recommended reading: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?msg=1729;bug=7...](https://bugs.debian.org/cgi-
bin/bugreport.cgi?msg=1729;bug=727708)

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)

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

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

