

The Biggest Myths (about systemd) - zzzeek
http://0pointer.de/blog/projects/the-biggest-myths.html

======
stonogo

             Myth: systemd is monolithic.
    

Myth confirmed. There is no way to use systemd components without systemd in
pid 1. There is no way to independently implement systemd components because
there is no specification or standard.

    
    
             Myth: systemd is about speed.
    

Myth confirmed. Speed was literally the first thing the creator wrote about
regarding systemd.

    
    
             Myth: systemd's fast boot-up is irrelevant for servers.
    

Myth disingenuous. Systemd's "fast" bootup is what makes it non-deterministic
(i.e. this is why you can't have a progress bar indication of the boot
process). The approach to making it fast is what makes it inappropriate for
servers.

    
    
             Myth: systemd is incompatible with shell scripts.
    

Myth disingenuous. Systemd does not support ANY of the _existing_ shell
scripts, even ones specifically developed to be compatible with multiple init
systems. There is no way to write a one-size-fits-all init script that also
works a priori and without external crutches on systemd.

    
    
             Myth: systemd is difficult.
    

Myth disingenuous. The creator talks about "system objects" and "systemd
units". He claims systemd is easier to understand than a shell-based init,
glossing over the fact that shell programming applies to the rest of the
computer as well, where systemd does not.

    
    
             Myth: systemd is not modular.
    

Myth confirmed. The creator misunderstands software modularity -- busybox is
modular. Systemd (and the linux kernel) are not.

    
    
             Myth: systemd is only for desktops.
    

Myth disingenuous. Almost all of the externally-visible aspects of systemd are
tailored for desktop deployments. He cites people using systemd in bizarre
ways as evidence systemd was designed for those purposes; this is clearly
nonsense.

    
    
             Myth: systemd was created as result of the NIH syndrome.
    

Myth irrelevant. The stated motivations behind systemd are mostly handwaving,
but the creator's motivation doesn't really matter.

    
    
             Myth: systemd is a freedesktop.org project.
    

Myth confirmed. The creator claims freedesktop.org is some kind of generic
code dump "like SourceForge, github, kernel.org," except the creator fails to
mention how tightly integrated systemd is with many other freedesktop.org
projects.

    
    
             Myth: systemd is not UNIX.
    

Myth confirmed. The creator just thinks that isn't important, and the bits
that are are matters of cultural relativism.

    
    
             Myth: systemd is complex.
    

Myth confirmed. The creator admits "some truth" to this claim, and then goes
forth to comment that the systemd approach is simpler ... because it comes in
fewer packages. Packaging is completely arbitrary -- I could put any init
system AND all its dependencies into a single RPM, or even an empty RPM that
builds everything at install time via scripts. This is just handwaving.

    
    
             Myth: systemd is bloated.
    

Myth confirmed. The creator pretends a minimal compile is relevant to anyone's
analysis, and handwaves away the fact that systemd has grown leaps and bounds
as it solves EVERY integration problem by rewriting the relevant subsystem
from scratch and including it with systemd.

    
    
             Myth: systemd being Linux-only is not nice to the BSDs.
    

Myth confirmed. The creator is apparently unaware that much software that was
previously portable has been rewritten to require systemd. While these second-
order effects are not the creator's fault, the creator's privileged position
in a dominant linux organization has (perhaps unwittingly) been used to wall
of previously portable software.

    
    
             Myth: systemd being Linux-only makes it impossible for Debian to adopt it as default.
    

Myth busted! The creator then goes on to pretend that supporting both systemd
(a monolithic all-encompassing suite of software) and classic loosely-coupled
unix methodologies is a "negligable" amount of work. This does not speak well
for the creator's understanding of software he did not write.

    
    
             Myth: systemd could be ported to other kernels if its maintainers just wanted to.
    

Myth busted! Systemd is not and will never be portable, it is written to glom
on to dozens of linux-specific kernel interfaces and become some kind of
parasitic middleman to all of them. This ob viously cannot be ported.

    
    
             Myth: systemd is not portable for no reason.
    

Myth busted! systemd is not portable because the creator is either unable or
unwilling to write portable init software.

    
    
             Myth: systemd uses binary configuration files.
    

Myth disingenuous. systemd uses plaintext config files; it just chooses the
silliest possible structure for those files. The structure has no
specification outside of systemd source code.

    
    
             Myth: systemd is a feature creep.
    

Myth confirmed. The creator pretends that turning things off negates this,
apparently failing to realize that the more "stuff" systemd does, the more
development resources are required to maintain it, and the more difficult it
is to test aspects of it independently.

    
    
             Myth: systemd forces you to do something.
    

Myth confirmed. systemd forces you to run systemd in pid 1. No other init
system totally breaks down when you run something else in pid 1.

    
    
             Myth: systemd makes it impossible to run syslog.
    

Myth disingenuous. This is another example of systemd as the parasitic
middleman.

    
    
             Myth: systemd is incompatible.
    

Myth very much confirmed. There is no way for a sysv init script to enter an
infinite loop under systemd. Systemd does not allow services to read from
stdin, a fundamental interface. Sysv services cannot get realtime scheduling.

    
    
             Myth: systemd is not scriptable, because of its D-Bus use.
    

Myth disingenuous. system is _only_ scriptable through explicit dbus APIs,
instead of native scripting tools provided by the OS. This is another example
of the parasitic middleman effect.

    
    
             Myth: systemd requires you to use some arcane configuration tools instead of allowing you to edit your configuration files directly.
    

Myth disingenuous. Systemd has no faculty for checking configuration validity
aside from systemd. There is no way to know what will work when you directly
edit configuration files, because there is no specification.

    
    
             Myth: systemd is unstable and buggy.
    

Myth disingenuous. It is not unstable or buggy when deployed by distributions
sponsored by the creator's employer. Everyone else can fuck themselves,
including kernel developers.

    
    
             Myth: systemd is not debuggable.
    

Myth disingenuous. systemd is debuggable only with the debugging tools
provided by systemd, which are not applicable to any other software and have
nothing in common with tools that are. Myth: systemd makes changes for the
changes' sake.

Myth irrelevant. What the hell does this even mean? And why bother defending
against such a meaningless "accusation"?

    
    
             Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world.
    

Myth confirmed. if Red Hat brass doesn't like something, you can bet your ass
it will not survive in the systemd repository. Full stop.

    
    
             Myth: systemd doesn't support /usr split from the root directory.
    

Myth irrelevant. systemd makes lip service to this, but one of its components,
udev, does not at all. It depends on whether you consider this a failure of
udev, or a failure of systemd-because-it-absorbed-udev.

    
    
             Myth: systemd doesn't allow your to replace its components.
    

Myth confirmed. Go ahead. Replace pid 1.

    
    
             Myth: systemd's use of D-Bus instead of sockets makes it intransparent.
    

Myth disingenuous. It doesn't "make it intransparent", it's just stupid. The
creator goes on to pretend that d-bus serialization is in any way standardized
(it is not, and never has been). _systemd_ may use it consistently, but that
means nothing, because systemd has no specifications whatsoever.

------
dozzie

      A package involving 69 individual binaries can hardly be called monolithic.
    

Of course it can. If those binaries are tightly coupled (try replacing
journald!), then the whole set is monolithic.

    
    
      Myth: systemd is not modular.
     
      Not true at all. At compile time you have [...]
    

Yes, like _modularity_ is about selecting what to _compile_.

    
    
      Myth: systemd could be ported to other kernels if its maintainers just wanted to.
      [...]
      [...] look at the others you didn't pick, and the complexity of replacing them.
    

And there it goes their argument about simplicity of systemd. How much
different subsystems does an init system need?

    
    
      Myth: systemd doesn't allow your to replace its components.
      
      Not true, you can turn off and replace pretty much any part of systemd [...]
    

OK, where's the spec so I could implement alternatives?

