Re: Is missing SysV-init support a bug?
Marc Haber <mh+debian-devel@zugschlus.de> writes:
> Russ Allbery <rra@debian.org> wrote:
>> Debian historically tries to handle these situations by just providing
>> everything simultaneously. The debate over init systems is as heated
>> as it is because it's quite difficult to do a good job at supporting
>> multiple init systems.
> And because it's a system-wide decision.
Yeah, that too, although I think that's somewhat less of a factor. (But
it is a factor.) Choosing your MTA or your cron daemon is also a
system-wide decision, but Debian supports tons of them and it's no big
deal. The init system has several tricky factors, though:
1. Init systems by their very nature integrate with huge classes of
software in the rest of the distribution, which is what makes it quite
difficult to do a good job at supporting multiple init systems since
there's quite a lot of work to do for each of them. It's not quite as
bad as supporting building Debian with multiple C compilers, but it's
in that ballpark.
2. It's something that any experienced sysadmin is going to have to mess
with, so it's not just something that Debian has to integrate, it's
also something that has a lot of careful, tricky custom configuration
done by the local administrator. Who is obviously going to have strong
opinions about how they work with it.
3. In the Debian context, it was a particularly stable (or stale,
depending on how you want to spin it) part of the distribution. Ubuntu
had upstart, Red Hat had played with other init systems, but Debian
largely hadn't. So none of the muscles around "oh, this doesn't have
to work exactly this way" were really being exercised. (Yes, there was
file-rc and a few other things, but the level of usage was miniscule.)
So it's a wrenching transition to consider something else.
4. Managing daemons is something about which many of us have Opinions.
Strong Opinions. Please allow us to relate them to you. They are
quite Strong, and are Very Important, and we have Thought About Them A
Great Deal, and your opinions, if they differ, are probably Wrong.
Managing daemons is to sysadmins what editors are to programmers. We
spend lots of time with that software. Opinions form.
5. It is arguable what the init system can or should do. By that, I mean
that some people think the init system should do quite a lot more than
it historically had done, because there was a bunch of stuff being done
poorly and inconsistently that benefits greatly from being
standardized. And other people who believe that, if anything, the
problem with sysvinit was that it was doing too much and was too
complex. And neither of these people are obviously wrong. Depending
on what angle you look at things from, you can make a lot of strong
arguments all around. It's much like the debate between writing
software in some very high-level language like Python versus writing
it in C, as mentioned in my other message.
6. systemd muddled this considerably because it's not only an init system
project, it's an operating system plumbing project whose contributors
are very excited to fix what they view as a wide variety of historical
warts and suboptimal solutions to a ton of various low-level plumbing
and integration issues. This is simultaneously exciting and scary.
(And I'm going to go out on a limb here and say that if you find it
only exciting, or if you find it only scary, you are not thinking
enough about it, are missing significant components of this effort, and
should really think about it some more until you can recognize both
halves of that reaction and why they both make sense.)
There is a bunch of low-level plumbing deep inside UNIX and Linux that
is, to be frank, archaic, cobbled-together bullshit, and that I think
we'd all admit was that if it came up in a context outside of a very
heated and divisive debate. Modern thinking on component separation,
configuration syntax, APIs, and the usefulness of things like event
buses are, shall we say, informed by decades of experience, much
broader communities and more varied goals, and a huge developer base,
compared to what the original designers of UNIX had available. It's
not at all hubris to look at the icky guts of OS plumbing, particularly
the bits that were never really designed but just accreted over the
years, and think "this could be a lot better if it were properly
designed for modern systems and problems." But change sucks, and part
of what accreted was decades of subtle workarounds to poorly-documented
issues for which we have minimal institutional memory. If
contemplating replacing that stuff doesn't terrify you from a stability
and disruption standpoint, you're not thinking about it hard enough.
7. systemd upstream sits at the perfect inflection point between
insufficiently good at communication and interpersonal politics to be
easy for everyone to work with, and sufficiently good at both of those
things to be a very comfortable, enjoyable, and supportive working
environment for many people. If they were assholes, this would be a
much simpler discussion. If they were, say, Perl or Python or Postfix
upstreams, just to pick a few generally low-drama upstreams that I've
interacted with personally, this would also be a much simpler
discussion. But they're prickly, kind, arrogant, confident,
supportive, thoughtful, sarcastic, and dismissive people, thus putting
the project at that perfect tipping point where everyone can form
strong opinions with sufficient evidence to feel justified in holding
them, and then yell at the people who formed the opposite strong
opinion in perpetuity, while constantly being fed enough supporting
evidence to retain moral certainty.
8. The systemd project positioning and public statements about the degree
to which it is a toolkit that can be used as separate pieces versus an
integrated system that you have to take or leave as a unified whole
have been, frankly, a muddled and incoherent mess. And the actual
position appears to be something around "we're building it as separate
components because that's just good engineering, but we don't
particularly care about use cases that involve picking and choosing
specific components and are not really prioritizing them," which is
essentially perfectly positioned to make no one happy and all
discussions around modularity arrive at frustratingly inconclusive
loose ends.
It's kind of a perfect storm. It makes sense if you sit down and
enumerate the reasons, but it's still kind of amazing just how much of a
perfect storm it is.
The result is that now one's opinions about init systems have transcended
technology and have become a tribal identification marker, with all that
entails, and the decision is sufficiently finely balanced that you are
never going to find some sort of objective evidence that is going to
convince someone they are wrong about their settled opinion.
Which doesn't, sadly, prevent people from inventing more evidence to
support their side that's, honestly, complete nonsense. I mostly pipe up
here occasionally to poke at evidence from the "systemd is horrible" side,
primarily because a lot of the bad arguments (and please note from the
above I'm not saying all the arguments are bad, just that I see bad
arguments a lot) are based on arguments from tradition or folk
understandings of the UNIX way that are simply not true and that I know
aren't true because I've been running UNIX systems for a long time. But
there's a bunch of nonsense on the pro-systemd side too, because it's
turned into the tribal choice.
(One of those, honestly, is this whole "Linux isn't about choice" thing,
which I can simultaneously appreciate as correct in a very specific,
narrow, constrained, and cautious application of the principle, and also
get intensely annoyed at because, in fact, Linux *is* about choice,
variety, a wonderful array of options, adaptability to different
circumstances, vi AND Emacs, and all of the other glorious diversity of
the ecosystem that we've all enjoyed and built for the last mumble-odd
years.)
TL;DR: I fear this init system is going to go on forever not because
people are horrible, not because it's just a matter of personal taste like
vi and Emacs, but because it's like the argument over how to fund health
care. It's an incredibly complicated decision involving alternatives and
tradeoffs that are often directly opposed to each other, deeply entangled
in not only a bunch of other policy questions but also questions of
identity and ideology, prone to endless opining by people who think they
know more about the gritty details than they actually do, subject to
endless anecdotes as data problems, home to both saints and assholes on
all sides of the argument, and REALLY FUCKING IMPORTANT because it's
foundational to a bunch of shit we want to get done.
But I do wish that people would acknowledge more of the above nuance when
having this argument, and realize that the last thing we should ever do is
claim that this decision is clear-cut or black and white.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: