Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Sunday September 28 2014, @06:27AM   Printer-friendly
from the yet-another-systemd-story dept.

Controversy is nothing new when it comes to systemd. Many people find this new Linux init system to be inherently flawed in most ways, yet it is still gaining traction with major distros like Arch Linux, openSUSE, Fedora, and soon both Ubuntu and Debian GNU/Linux. The adoption of systemd for Debian 8 "Jessie" has been particularly fraught with strife and animosity.

Some have described the systemd adoption process as having been a "coup", while others are vowing to stick with Debian 7 as long as possible before moving to another distro. Others are so upset by what they see as a complete betrayal of the Debian and open source communities that there is serious discussion about forking Debian. Regardless of one's stance toward systemd, it cannot be argued that it has become one of the most divisive and disruptive changes in the long history of the Debian project, threatening to destroy both the project and the community that has built up around it.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by boristhespider on Sunday September 28 2014, @09:47AM

    by boristhespider (4048) on Sunday September 28 2014, @09:47AM (#99126)

    of what's so bad about systemd and so great about init? I've got no irons in the fire here - I just like machines that work. Is there a genuine reason for all this upset over systemd? (Beyond the understandable reaction to change for change's sake.) For the record my desktop machine is currently dual-booting Mint, which so far as I know is on systemd, and my Macbook is dual-booting Fedora, which is definitely on systemd.

  • (Score: 5, Informative) by tonyPick on Sunday September 28 2014, @10:18AM

    by tonyPick (1237) on Sunday September 28 2014, @10:18AM (#99135) Homepage Journal

    Init isn't great, but it's been good enough for 20 or 30 years, and whilst systemd is sort of replacing init, it's also throwing in a much wider re-architecture of the basic system at the same time, and then pushing this onto most everyone else by breaking compatibility with "non-systemd" approaches and making sure Gnome requires it.

    And, reprinting my comment from the last time we did this:

    Fundamentally? systemd is trying to do Too Damn Much and weld it in via the init system, which could be better, but isn't terribly broken for most all the traditional use cases.

    Removing and improving on legacy init is one job (which does need doing). The consolidation and centralisation of a grab bag of system capabilities into a common infrastructure is a different job; systemd is munging them both into one thing. Bad.

    So for any core system update you're balancing risk, benefits and costs: As a developer/user (primarily in the mid-range embedded space) I'm seeing no solid benefits, large risks and massive knock on costs on the future of the infrastructure, as systemd becomes an increasingly pervasive dependency for everything from logging to authentication to networking etc...

    It's not a "vi versus emacs" that if you don't like it you pick something else and go with that - it's becoming increasingly hard (as per TFA) to avoid the damn thing. This should be because it's *better*, but it isn't - it's because it's *different*. This is not a problem for Gnome and Redhat, and if you're looking at their distribution then this may even be a good thing, but the world is not RHEL, and we aren't all worried about containerised Gnome.

    I could go on, but whilst I don't agree with it all this essentially covers a lot of what I would say: http://ewontfix.com/14/ [ewontfix.com] [ewontfix.com]

    Now having said all that; I'd _like_ to be wrong, and for it to be a painless improvement, but having looked at it I'm not seeing anything persuasive from the systemd folks and from the sheer level of crud thrown about (e.g. the Kernel debug line debacle, wrong on *so* many levels) to the state of the docs (quantity != quality) to the source code in the repo (journal-qrcode.c? Seriously?) don't fill me with the warm and fuzzies.

    See also: http://blog.lusis.org/blog/2014/09/23/end-of-linux/ [lusis.org]

    • (Score: 3, Insightful) by maxwell demon on Sunday September 28 2014, @11:30AM

      by maxwell demon (1608) on Sunday September 28 2014, @11:30AM (#99150) Journal

      breaking compatibility with "non-systemd" approaches

      That's the biggest problem. Just like Gnome 3 making sure you couldn't run your old Gnome 2 applications (not even by installing Gnome 2 on the side, due to conflicts between the libraries). And Firefox breaking some extensions on almost every update.

      Thou shalt not create incompatible interfaces.

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 0) by Anonymous Coward on Monday September 29 2014, @03:18AM

        by Anonymous Coward on Monday September 29 2014, @03:18AM (#99441)

        That's the biggest problem. Just like Gnome 3 making sure you couldn't run your old Gnome 2 applications (not even by installing Gnome 2 on the side, due to conflicts between the libraries). And Firefox breaking some extensions on almost every update.

        Thou shalt not create incompatible interfaces.

        The same for Linux API. So what? Don't use programs that you don't like. I haven't had Firefox break any extensions I use on any upgrade yet, and I don't even use Gnome since it's slow and bloated.

        • (Score: 0) by Anonymous Coward on Monday September 29 2014, @11:54AM

          by Anonymous Coward on Monday September 29 2014, @11:54AM (#99538)

          I don't want to use systemd. I'd love to avoid it completely. But how the fuck am I supposed to do that if Debian forces it onto my systems? Now I have to give up Debian completely, just because they made a stupid decision in one area? That's bollocks! Total bollocks! Systemd just shouldn't be included in Debian at all. If users want systemd, make them switch to Fedora or one of the other shitty distros that uses it.

  • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @10:32AM

    by Anonymous Coward on Sunday September 28 2014, @10:32AM (#99137)

    First off there isnt really a single init, we talk about SysV but that's just a specification and everyone made their own slightly different implementation. Some are better than others. There are also a whole new generation e.g. runit s6 finit openRC monit dmd and others that enable the same sorts of additional features that systemd does.

    The difference is that systemd has powerful corporate backing, and it keeps rolling up other aspects of the system, completely outside of the scope of an init system, which it then alters. Embrace, extend, extinguish - well systemd is classic extend. Journald is required, and it uses a binary file format for logging, which is ridiculous and unacceptable. It's eaten consolekit, it's eaten udev, and it's getting harder and harder to work around it.

    A couple of differences between it and the alternatives; working with existing tools versus requiring reinvented tools, and being designed to work with arbitrary components versus requiring unrelated components all be selected as a block.

    One more difference - a corporation funding development and pushing adoption. Now why on earth would free software people let anyone *push* us to adopt something? Have we really learned nothing?

    This [coreos.com] is what it is about - and in a nutshell you could say it's Android for server farms.

  • (Score: 5, Insightful) by mtrycz on Sunday September 28 2014, @10:57AM

    by mtrycz (60) on Sunday September 28 2014, @10:57AM (#99144)

    I won't go into the gritty details, here's a quick overview. It'll be lenghty nonetheless.

    I don't know if this was clear form the start, but systemd wants to become the OS. Instead of small and simple (single-purpose) utilities, you have centralized everything: startup, logs, etc. It's a monolithic piece of software. It does present advantages: mainly performace increases (since it's tightly coupled with many software, last addition is Gnome3, so you have a faster desktop, like it even matters) and startup times (am I the only one to think this doesn't even matter?). For distro developers systemd comes in handy, because the more things are integrated, the less things they need to configure. Also they say it's well documented, so it's easier to integrate and use than replacement software (can't confirm: didn't check it out).

    This philosophy goes right against the unix motto of doing one thing right. That's how admins like their systems, for lots of hardened reasons. One example: this week we had a serious vulnerability in bash. bash is a widely used piece of software, it does one thing, it has alternatives you can use (been looking into zsh lately), and when a fix comes out you can easily patch it. The codebase is kinda big, but it's focused on one thing only: processing commands and running scripts. Bugs (and security holes) pop around all of the time, even in time-proven software, but then it's not that difficult to fix. Also, small, modular software is easier to audit, if need be.

    systemd is ever growing, instead. It does multiple things, and is over 250k lines-of-code already; it will continue to grow, because features! You probably already know that big software is harder to debug (or audit) than smaller code. We'd all rather stick with single-purpose utilities.

    An other fact is that the authors of systemd don't really like being questioned. If you ask "did you really had to do binary logs?" you'll just get a middle finger. If you say "my binary logs got corrupted, how do I restore them?", they'll just WONTFIX.

    -------------------------
    TINFOILHAT WARNING: all of the above are facts; all of the below are my personal conjecture.
    -------------------------

    systemd is made at Red Hat, which has the US Army as their biggest contractor. It's not improbable that the services want to install a backdoor in you linux system. They pay Microsoft for backdoors in Windowses, they pay the big IT companies to hand over data, why wouldn't they want access to your Linux too? systemd is the perfect piece of software to install a backdoor to: it has all of the systems priviledges, it's too big and too fast-moving to audit; it's easy to put an undiscovered "bug" inside. Even if you assume the devs are in good faith.

    As I see it, Red Hat should roll their own OS (even if it's with the Linux kernell), and leave GNU/Linux alone. Let's call it sytemd/Linux, or something, or maybe Red Hat Enterprise OS?

    There are lots of other things to say, but this is *my personal* main concern. You can obviously read up more at
    http://boycottsystemd.org/ [boycottsystemd.org]
    http://judecnelson.blogspot.com.au/2014/09/systemd-biggest-fallacies.html [blogspot.com.au]
    and other sources. Some are more technical, others more security oriented, others more choice oriented, but for me the backdoors in Linux is the #1 reason not to go with systemd.

    Everybody is welcome to add their own.

    --
    In capitalist America, ads view YOU!
    • (Score: 1) by boristhespider on Sunday September 28 2014, @11:04AM

      by boristhespider (4048) on Sunday September 28 2014, @11:04AM (#99145)

      Thanks to all three of you - very informative.

    • (Score: 2) by tonyPick on Sunday September 28 2014, @11:14AM

      by tonyPick (1237) on Sunday September 28 2014, @11:14AM (#99147) Homepage Journal

      TINFOILHAT WARNING:

      That _is_ a bit tinfoily. I'd agree that it's a lot harder to audit the systemd codebase, and that certain security agencies will *love* the opportunity to sneak in a bit of malicious code there and get it to own the entire system, however RH aren't necessarily in need of any further motivation than owning the core integration, and (by extension) being able to monetize a bigger slice of the market, control the direction of development, and keeping Oracle and Canonical on the back foot is a definite plus.

      (And hey, if I worked at RH I'd probably be busy convincing myself the whole "integrated modular platform" thing was a good idea too: It'd be developing tons of the shiny cool "stuff", and probably solving problems I actually had in the process).

    • (Score: 5, Insightful) by VLM on Sunday September 28 2014, @11:39AM

      by VLM (445) Subscriber Badge on Sunday September 28 2014, @11:39AM (#99158)

      One thing that concerns me about monoliths is giant codebase = giant security patches and giant updates in general. You can't upgrade init without rebooting for all practical purposes and even if there is a hack if something goes wrong...

      So in a non-monolith I can upgrade sysklogd or more likely rsyslog without rebooting anything or even the slightest danger of reboot. With a monolith, nope. Like using Windows again. Reboot reboot reboot reboot. No thanks.

      I mean, my god, they're trying to integrate dhcp and ntp into it. Thats insane. All tightly coupled into ring 0. Dumb architectural idea.

      The other thing that concerns me is EEE embrace extend extinguish. Someone is being paid to shove a unreplaceable no-upgrade path unavoidable universal system down our throats because they have a submarine patent on "integrating ntp into an init system" or some such foolishness and after its utterly unavoidable we'll be issued lawsuits and licensing offers and gigatons of FUD from competitors. Pretty much the SCO/Novell thing all over except it won't be a lie, it'll really be true.

      • (Score: 1) by canopic jug on Sunday September 28 2014, @02:36PM

        by canopic jug (3949) Subscriber Badge on Sunday September 28 2014, @02:36PM (#99216) Journal

        I mean, my god, they're trying to integrate dhcp and ntp into it. Thats insane. All tightly coupled into ring 0. Dumb architectural idea.

        The other thing that concerns me is EEE embrace extend extinguish. Someone is being paid to shove a unreplaceable no-upgrade path unavoidable universal system down our throats because they have a submarine patent on "integrating ntp into an init system" or some such foolishness and after its utterly unavoidable we'll be issued lawsuits and licensing offers and gigatons of FUD from competitors...

        Or DRM, to follow on with more speculation. There is no technical advantage to the architecture of systemd that I can see, only disadvantages -- unless. Unless the goal is to be a blob between the kernel and userspace and restrict and monitor all system components and data.

        The part that I find particularly strange and unfortunate is the fact that it is being slammed through important distros like Debian. Getting it into Debian means it spreads to downstream distros like Ubuntu and Knoppix, to name just two. But it also means further disregard for healthy software engineering practices. I could have seen either phasing it in over several releases and/or offering it as an option along side Upstart and Openrc. However, just slamming it through reeks. It raises big red flags about the process and the people pushing systemd.

        --
        Money is not free speech. Elections should not be auctions.
    • (Score: 5, Interesting) by zocalo on Sunday September 28 2014, @03:09PM

      by zocalo (302) on Sunday September 28 2014, @03:09PM (#99224)
      I'm no fan of SystemD, in fact we are currently migrating a large number of RHEL systems to BSD in part because of it [1], but some of your "facts" are actually FUD:

      SystemD is *not* monolithic, at least not any more. It's actually quite modular, consisting of a large number of separate binaries that can be include or excluded at build time. The problem here is that it is very easy for distros that have decided to adopt SystemD's init replacement to adopt everything else that does with it - it does make life a lot easier for them, so users get SystemD versions of Cron, Syslog and all the others on the growing list by default, whether they want them or not. Depending on the daemon it may be possible for the user the disable and replace the SystemD version, or they may need to run both in parallel - the amount of effort to do this however can be quite cumbersome, in a way no different from how Microsoft embeds IE into Windows (albeit at a much lower level, at least for now) - and that quite rightly provoked a lot of protests from those that didn't want it on their system in the first place.

      SystemD is *not* responsible for the applications that rely on the services it provides; e.g. Gnome. That is a decision that you need to lay with the relevant developers of the tools that have SystemD as a dependency, although since many of those development teams are heavily influenced by Red Hat you may feel free to make allegations of collusion - I certainly suspect this may have occured. SystemD itself actually has very few pre-requisites; the Linux kernel and a few other essential bits and pieces that will almost certainly need to be installed anyway, but that's about it.

      When it works (which is most of the time, to be fair), then for many users it does generally make life easier, and few users will need to do more than use SystemD to start/stop/disable daemons anyway. The original init, while it gets the job done, *is* long in the tooth. Debugging it can be a nightmare, despite the claims made by the team, and while the code might be somewhat modular many of the interprocess communications are still hard, if not impossible, to get a handle on depending on what state the system is in - especially given the braindead decision to adopt a binary logfile format. The "NOTABUG" / "WONTFIX" attitude of the devs is also well documented - unlike the software itself, although the documentation is still better than many other OSS projects.

      Personally though, I've made my view clear in several discussion on the topic here and on the other site: I'd still like to see SystemD replaced with something else, or at least take the current modularity to the next step, making it much easier for users to disable and/or replace services that it provides. Specifically, I'd like to see the various daemons SystemD is replacing in their own packages so I can, for instance, choose to install systemd-{daemon}, a third party daemon of my choice, neither, or both, depending on my personal preference and build requirements. That's an issue for the distros though, not the SystemD team, although they could certainly help make this task a lot easier for packagers to undertake. I'd also say that they need to make troubleshooting it when you are in recovery mode following a major crash or system compromise much easier, provide an option for text only logfiles, and addressing several other outstanding issues that people clearly have with it. SystemD is clearly dividing the Linux community, and while some might jump ship to BSD, the main beneficiary of this infighting is going to be Microsoft - and none of us want that.

      [1] We started looking elsewhere because we didn't like RHEL6 in general. We run a mix of desktops and servers, but mostly headless servers. The prevalence of SystemD prompted us to include BSDs in our candidates along with other Linux distros and the cleaner installs, less complex dependencies, and generally much faster performance we saw with BSD made us make the leap.
      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 1, Interesting) by Anonymous Coward on Sunday September 28 2014, @03:54PM

        by Anonymous Coward on Sunday September 28 2014, @03:54PM (#99232)

        Some of the complaints could be expressed better, interesting that you dissected them when you are well aware of the real issues.

        SystemD is *not* monolithic

        Technically correct but as you point out, effectively not since the default for everything will be systemd-daemons and replacing them is cumbersome. I fear the word monolithic is being banded about here when the real complaint is that linux distros may become a monoculture.

        SystemD is *not* responsible for the applications that rely on the services it provides

        Systemd *is* responsible for consuming udev and dbus. The developers are responsible for making underhand political decisions and attempting to pass them off as technical concerns -- as if we're all morons.

      • (Score: 4, Insightful) by tonyPick on Sunday September 28 2014, @04:37PM

        by tonyPick (1237) on Sunday September 28 2014, @04:37PM (#99240) Homepage Journal

        SystemD is *not* monolithic, at least not any more. It's actually quite modular, consisting of a large number of separate binaries that can be include or excluded at build time.

        Great. So you can take a machine that doesn't have systemd and is running a 2.6 series kernel, and just run the standalone journald binary on it? Or put it on a BSD box? (Answer: not really)

        The thing that makes it monolithic is the fact that all the pieces of it are interdependent. Putting it into separate binaries makes it Modular, but it can still be a Monolithic architecture. Monolithic and Modular are not antonyms.

        Or, to quote wikipedia, a monolithic architecture is one in which the functionally distinct aspects:

        are not architecturally separate components but are all interwoven

        And given the systemd authors stance that you can't take out some key pieces like logind and reimplement it separately (See http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ [freedesktop.org]), that's a pretty good description of systemd to me.

        • (Score: 2) by zocalo on Sunday September 28 2014, @05:13PM

          by zocalo (302) on Sunday September 28 2014, @05:13PM (#99247)
          That's a semantic difference that you didn't make in your original post, hence my response. It is, however, one that I agree with - that's what I was getting at with the bit about being able to break the SystemD bundle up into different packages, then more cleanly and completely swap the non-PID1 components of SystemD out for alternates. At the moment I would also argue that it is monolithic in that context, but there is no technical reason why it couldn't become a suite of standalone tools, albeit with a high level of integration. The biggest issue with that though is likely breakages of those projects that have drunk deep of the SystemD kool-aid and insist on it being present to run, but you reap what you sow...

          Ultimately, I think SystemD is here to stay, and will likely end up as much a part of Linux as the kernel and GLibC. Too many distros have too much invested in it now to change direction, and it would be a rare distro that will be prepared to completely drop all of the growing numbers of packages that only work if SystemD is present. We can either keep bitching about it (which appears to be futile), produce a workable alternative that is appealing enough to encourage distros to switch (which will probably take too long given the growing list of dependencies upon SystemD that will break), or try and convince the SystemD team and distro packagers to address the concerns being raised by the community (which currently appears to be falling on deaf ears). It's a Hobson's Choice, but I think the last one is probably the best option - other than switching to BSD, anyway.
          --
          UNIX? They're not even circumcised! Savages!
    • (Score: 4, Funny) by maxwell demon on Sunday September 28 2014, @04:02PM

      by maxwell demon (1608) on Sunday September 28 2014, @04:02PM (#99235) Journal

      Maybe they should rename systemd to Master Control Program.

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 2) by aristarchus on Sunday September 28 2014, @07:44PM

        by aristarchus (2645) on Sunday September 28 2014, @07:44PM (#99318) Journal

        Tron? Is that you?

      • (Score: 2) by danomac on Sunday September 28 2014, @10:18PM

        by danomac (979) on Sunday September 28 2014, @10:18PM (#99367)
        Better yet just rename it to Borg.
    • (Score: 2) by cafebabe on Sunday September 28 2014, @07:02PM

      by cafebabe (894) on Sunday September 28 2014, @07:02PM (#99295) Journal

      250k lines-of-code

      That code is likely to have more than one bug per 1,000 lines. A proportion of those bugs may be security flaws. Unlike init, systemd is network exposed. So, some of those bugs may allow remote attacks.

      Old code has less bugs per line because the bugs have been found in audits and through deployment. Unfortunately, the number of bugs may never be zero. As we've seen with a security flaw in bash being network exposed via various daemons, some bugs may survive for decades and may be deployed on hundreds of millions of devices before they are found. However, new code (especially code which replaces a working implementation [joelonsoftware.com]) is almost guaranteed to be a greater risk.

      --
      1702845791×2
  • (Score: 2) by Nerdfest on Sunday September 28 2014, @02:35PM

    by Nerdfest (80) on Sunday September 28 2014, @02:35PM (#99215)

    If nothing else, binary logging and binary configuration. Windows uses these and it causes rather a lot of problems.

  • (Score: 1, Informative) by Anonymous Coward on Sunday September 28 2014, @06:41PM

    by Anonymous Coward on Sunday September 28 2014, @06:41PM (#99283)

    systemd-udevd[142]: renamed network interface wlan0 to wlp1s0

    This is most helpful. Take descriptors that we understand perfectly like eth1 and wlan0 and turn them into cryptic strings.

    • (Score: 0) by Anonymous Coward on Sunday September 28 2014, @07:09PM

      by Anonymous Coward on Sunday September 28 2014, @07:09PM (#99301)

      Holy fuck, that is not acceptable. Every day I learn some new way that systemd fucks up something very basic.

    • (Score: 1) by GeminiDomino on Monday September 29 2014, @01:51PM

      by GeminiDomino (661) on Monday September 29 2014, @01:51PM (#99575)

      Dafuq? My first thought was "why would they turn the wireless card into a UFS partition?"

      --
      "We've been attacked by the intelligent, educated segment of our culture"
  • (Score: 3, Interesting) by hash14 on Sunday September 28 2014, @09:53PM

    by hash14 (1102) on Sunday September 28 2014, @09:53PM (#99362)

    The problem isn't just limited to the awful technical and design decisions which went into making it. Though systemd is rife with poor decision-making and design (which I will not get into), the biggest problem to me is what it means for the future of Linux and the Free Software environment.

    I personally have no qualms with _using_ systemd and am currently using a distro running it (which will be wiped in a few weeks and replaced with Slackware, Gentoo, or Freebsd). It's buggy, but that's the price you pay for user-friendliness.

    I was largely on the fence about systemd for a while - I knew a lot of people didn't like it, but wasn't sure if they were being purists or pedants. But now that Debian has been overtaken by the systemd mafia and the absurd political games taking control of the project and its technical decisions, I can see that it's the centerpiece of Red Hat taking a page from Redmond's book and using Embrace, Extend, Extinguish to eliminate all competitors. And the longer we delay in fighting it, the more hopeless the fight will become because systemd is such an important player in this vertical integration scheme.

    It's frankly shocking to me to see this happening in the Linux world, but I fear very much what will happen to the kernel, the popular DEs, and the myriad userspace applications which will become unusable simply because I choose to do something different from what Lennart Poettering tells me to do. In short, systemd is nothing less than a way for Lennart to take over the Free Software ecosystem (via udev, dependencies, etc.) and play Steve Jobs - you will get what I will give you, you will be told that it's the best thing you could possibly want, and (worst of all), dissent will be silenced.

    The Free Software ecosystem doesn't need a Steve Jobs. It does not need to become corrupted by Red Hat's commercial interests. And if it does, then we need a way to separate ourselves out from that - if we don't, then we risk losing everything that Linux has become up to this point.

    While this explanation may not pertain to you and your uses, I frankly think it would be a shame to see projects like BSD fade (or even disappear entirely) because they chose to not go down the same path of poor design that systemd decided to become. And I don't feel like I should be forced to use what other developers and maintainers decide simply because it was technically designed to preclude those alternatives.

  • (Score: 1) by Arik on Monday September 29 2014, @12:42AM

    by Arik (4543) on Monday September 29 2014, @12:42AM (#99407) Journal
    I've been thinking about this for some time and I think I have come up with an analogy that should make it reasonably accessible (at least to a geek) and yet still not take more than a page.

    Think of the BASH bug. What would you do if you found out tomorrow that it was deliberately introduced, and furthermore that the core team had been compromised from the beginning and there were probably dozens of more subtle exploits left?

    Well, we'd switch to zsh. Or csh, tcsh, ksh, whatever freaking sh you prefer. There are several, they are independent, and they are essentially drop in replacements for each other, with each adding new features but maintaining backward compatibility so that scripts dont break. Each does the same job, and you dont really have to worry about 'does the new shell support all the same programs as the old one' - there is a standard interface and the program doesnt care which shell you used to start it.

    Same is true for practically any element of the architecture. Same is definitely true for inits. People talk about 'SysV Init' like it's a thing, but it's just a spec a lot of people implemented in their own way. But each init basically does that one thing, and each can be ripped out and replaced with whatever you want. Like, ironically, /bin/sh. Yes, that's right, want a really fast boot? Set /bin/sh to init, done, go home. Most people want a little bit more setup than that done before getting to the login prompt, but it DOES work, and your init CAN be as simple as a shell script with a few commands you got sick of typing in every boot.

    Now imagine a shell replacement that included an incompatible format for text, an editor for that incompatible format, and a large and growing pile of ABIs for program development and system management and so forth. It doesnt just replace the shell, but a good chunk of your system. And if you adopt it and use it, more and more of your work going forward will only be accessible to people using the same shell. Which is all well and good, cause it's better, see?

    Systemd is not just an init system, and you cannot just rip it out and replace it with another init system when you want to. The seriously disturbing track record of the main personalities behind it in regards to bugs is really beside the point. I want an init system. Not an init system + obligatory binary logger with a pointless broken text option + superwonderful obligatory binary log file viewer (want to suck it into vi for a sec for something? NO SOUP FOR YOU!) + dev manager (only non-obligatory at this point because of eudev - thank you gentoo!) + consolekit replacement (someone want to pick that one up and dust if off?) + "services management" suite all in one non-negotiable whole.

    I've watched the same kind of thinking at work in the Windows world for decades and Linux has been my refuge from that insanity. I have no intention of importing it.
    --
    If laughter is the best medicine, who are the best doctors?