[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: