Marc Haber <mh+debian-de...@zugschlus.de> writes: > Russ Allbery <r...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
