from Hacker News

Systemd, ten years later: a historical and technical retrospective

by vezzy-fnord on 5/3/20, 9:41 PM with 432 comments

  • by gorgoiler on 5/4/20, 5:10 AM

    When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules.

    What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base.

    SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell.

    At this point the gentler folk start quietly honing their CVs and sneaking their personal belongings off their desks, one night at a time, in the hope no one notices they are all about to quit.

    It felt like Unix systems administration was a haven from this sort of politics — I don’t remember tmux, git, or python trying to push behavior changes on upstream components of the OS[1]. I’m sure it’s why Unix attracted a certain type of personality for so many years and I’m sad to see that changing.

    [1] If you are thinking “but those are command line utilities, whereas the init process is a much more specialized case” then I’d encourage you to revisit the Unix principles of every component being a small and simple program! Even init, cron, and login! It’s not some grand ideal to be zealously adhered to: it’s the principles of small components that mean the same OS can run on a quad core Xeon as runs on a $45 network switch.

  • by nine_k on 5/4/20, 3:26 AM

    My beef with systemd is not its reinventing things. That part may actually be good.

    One problem is that a number of reinventions were poorly made.

    E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas.

    Another problem is the "I know better" attitude.

    Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior.

    No wonder I don't run systemd on my desktops / laptops.

  • by ttctciyf on 5/3/20, 11:46 PM

    As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this:

    https://www.reddit.com/r/programming/comments/4ldewx/systemd...

    Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out.

    This would include processes like "screen" whose entire raison d'etre is to persist after the user logs out. (Well, it has other uses, but this is the main one IMO.)

    The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed.

    I don't know whether this situation is a problem with systemd or the distro, but it seems very much a problem with the culture summarised by the top commenter in the above thread, of (paraphrasing) glibly breaking existing workflows then casually brushing away criticism with arguments often boiling down to: "this is the right way, I don't care about tradition or protecting 'incorrect' usage."

  • by acdha on 5/3/20, 11:22 PM

    I think this really sums this article up:

    > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem.

    It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to the question of how open-source projects work. An init system is harder than it might seem at first and requires buy-in from an unusually large number of parties since it affects the OS, everyone shipping daemons, and the operators. If you’re not going to invest that level of engineering time, I don’t see how it’s reasonable to expect an equal voting share with those who do.

  • by ratsmack on 5/3/20, 9:56 PM

    >systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it.

    This statement makes no sense. It is well understood and has been studied and critiqued by many, including me. Also, I don't know what "social level" has to do with anything here. It was just created for the commercial aspect of Linux and forced into the relevant distro's by commercial interests... it's just that simple.

  • by zozbot234 on 5/3/20, 11:39 PM

    Systemd is an amazingly clear example of the second-system effect, as described in The Mythical Man Month. I fully expect it to be replaced down the line by something dramatically simpler and more intuitive, but that might take some time. Nonetheless, it does seem to solve some real problems with the earlier, rc-scripts approach.
  • by k_bx on 5/4/20, 8:33 AM

    Can I just say, from a non-sysadmin perspective, how happy am I that these days I don't have to install something like Supervisord and just use the systemd + journald toolchain. Setup script is just one cp and few systemctl commands (start/stop/enable).
  • by dvfjsdhgfv on 5/4/20, 9:18 AM

    A key quote:

    > As it turns out, there was a little-known Freedesktop-affiliated project called xdg-hostname in 2009 which was a start towards creating such D-Bus “utility daemons” for use in desktop widgets and others, all as a standalone project. Had this been followed through instead of having the utility daemons end up being part of the systemd source tree, a good deal of political acrimony could have been avoided – though at the cost of reducing systemd’s leverage.

    That is, if they used xdg-hostname instead, SystemD wouldn't be tightly coupled with Gnome, so users could choose between SystemD and InitV, and all this mess could have been avoided.

  • by reacharavindh on 5/4/20, 7:32 AM

    God I wish more people used VoidLinux and packaged more and more stuff without needing Systemd. Systemd may be good for some, bad for some. But, it certainly should not be the only way to get things done. We need alternatives.

    It’s as if web developers were told now that there is IE, that is prevalent, we can write web apps that only work there ;-)

  • by keymone on 5/4/20, 12:22 PM

    One thing I’m surprised about in the init wars of past decade(s?) is that in almost half a century of Unix nobody got up and said “why don’t we, instead of bickering about implementation details, come up with single format to declare desired system startup behavior, and then users can pick whichever implementation they like to read and execute that format”?

    Can’t be impossible to distill some basics about service startup configuration and dependencies, can it?

    Then make it extensible and cry about differences in extension support like we do about per-browser css options, but at least converge on some basics.

  • by gjvc on 5/4/20, 1:19 AM

    If you don't like something, put your energy into implementing it the way you do. With any luck, the ensuing distraction will be more effective at weakening the original than simply complaining about it.
  • by nyanpasu64 on 5/4/20, 8:26 AM

    I don't fully understand systemd, but the technical critique looks interesting and seems to indicate systemd is poorly designed (but I don't understand it all). Anyone else commenting on that?
  • by bandrami on 5/5/20, 3:33 PM

    10 years ago I never had shutdowns hang with "Stop job waiting for PID 10834: 30 seconds... 90 seconds..."

    I do now. Regressions are a bad thing.

  • by whereistimbo on 5/4/20, 1:27 AM

    vezzy-fnord! I have always enjoyed your commentary and perspective of operating system, it's nice to see you back again!
  • by AndrewStephens on 5/4/20, 1:09 PM

    I do really appreciate this type of long form, researched blog post. I have no strong opinions on systemd, I've made simple service units and it has worked well enough. Having the history behind the design is a great aid to understanding.
  • by noitpmeder on 5/4/20, 5:20 AM

    My worst gripe with systemd is that I cannot find reliable docs for older versions.
  • by Koshkin on 5/4/20, 12:16 PM

    My biggest gripe with it is that its name is not ‘sysd.’
  • by lidHanteyk on 5/4/20, 12:37 AM

    The author sounds distressingly prescient with their prediction that BPF will be the next venue for this sort of farce.
  • by meddlepal on 5/4/20, 1:16 AM

    Oh good, the monthly HN systemd 5 minute hate is upon us once again.
  • by bepvte on 5/4/20, 1:51 AM

    Interesting comparisons of a GNOME volunteer to Stalin. Also found it very interesting that the author put inclusivity in quotes.
  • by Stierlitz on 5/4/20, 11:00 AM

    TLDR: down with sYstemd :]
  • by nn3 on 5/4/20, 12:58 AM

    The dependency problems he's describing sound like they could be relatively easily fixed with some new systemd keywords?

    Of course it would take some time to migrate existing unit files.

    It doesn't sound like a fundamental critique. Would be nice to turn this into a constructive proposal to fix systemd.

  • by arh68 on 5/4/20, 11:06 AM

    PulseAudio is the only program I've seen really stress my Ryzen. I recommend fixing the default sampling config if you have similar issues.

    This is a really entertaining writeup, given the subject matter.

  • by aganame on 5/4/20, 4:04 AM

    I wish systemd haters would make a public petition to remove systemd from this world. I would absolutely use such a list to make sure I never accidentally hire any one of them for any system administration positions.