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.<p>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.<p>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.<p>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.<p>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.<p>[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.
My beef with systemd is not its reinventing things. That part may actually be good.<p>One problem is that a number of reinventions were poorly made.<p>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.<p>Another problem is the "I know better" attitude.<p>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 <i>widely considered as not broken</i> 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.<p>No wonder I don't run systemd on my desktops / laptops.
As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this:<p><a href="https://www.reddit.com/r/programming/comments/4ldewx/systemd_kills_screen_and_tmux_by_default_on_logout/" rel="nofollow">https://www.reddit.com/r/programming/comments/4ldewx/systemd...</a><p>Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out.<p>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.)<p>The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed.<p>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) <i>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."</i>
I think this really sums this article up:<p>> 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.<p>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.
>systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it.<p>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.
Systemd is an amazingly clear example of the second-system effect, as described in <i>The Mythical Man Month</i>. 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.
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).
A key quote:<p>> 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.<p>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.
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.<p>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 ;-)
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 <i>declare</i> desired system startup behavior, and then users can pick whichever implementation they like to read and execute that format”?<p>Can’t be impossible to distill some basics about service startup configuration and dependencies, can it?<p>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.
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.
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?
10 years ago I never had shutdowns hang with "Stop job waiting for PID 10834: 30 seconds... 90 seconds..."<p>I do now. Regressions are a bad thing.
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.
The dependency problems he's describing sound like they could be relatively easily fixed with some new systemd keywords?<p>Of course it would take some time to migrate existing unit files.<p>It doesn't sound like a fundamental critique. Would be nice to turn this into a constructive proposal to fix systemd.
PulseAudio is the <i>only</i> program I've seen really stress my Ryzen. I recommend fixing the default sampling config if you have similar issues.<p>This is a really entertaining writeup, given the subject matter.
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.