3 ms·

The Biggest Myths (about systemd)

10 points by zzzeek 12y ago

dozzie 12y ago
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?
stonogo 12y ago
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.

10 points by zzzeek 12y ago

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?

stonogo 12y ago

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.