Broken by design: systemd

How has it affected your uptime? Any specifics?

I'll run systemd only after you pry openrc[1] from my cold, dead hands.

FAR too much of the project makes exactly the wrong design choices. The worst of these flaws is the binding of previously-independent components discussed near the end of this article.

This bundling Is not even necessary! The features that systemd gets right - an interesting daemon management tool, and providing a useful default start/stop mechanism ("4 lines of config instead of re-writing the same generic shell script") - can obviously be independent features.

This mess should be limited to merely bad design in a particular software niche(s)., but now we're seeing the "my way or nothing" attitude spill over into existing user-level software. (e.g., Gnome[2] I would probably already be using part of it was properly modular. Instead, the bundle is growing even more monolithic and incompatible.

When a similar "forced upgrade/incompatibility" happened to OpenGL (with ES dropping the traditional fixed-function pipeline, JWZ had a very good summary[3] of the the problem, from a "having to maintain old software" prespective:

    Let's say you have a well-specified system that is in wide use (a language, a
    library API, whatever) and because of changes in some substrate (operating 
    systems, hardware, whatever) you find that you need to add a new way of doing 
    things to it.

    The way you do this is, you add new features to the specification and you 
    clearly document the version in which those features become supported.

    If there are old features that you would like to discourage the use of, then 
    you mark them as obsolete -- but you do not remove them because thou shalt not 
    break working code.

    If you don't agree with that, then please, get out of the software industry 
    right now. Find another line of work. Please.

    Your users have code that works. Maybe the new APIs would serve them better. 
    Maybe things would be so much more efficient if they updated their code to use 
    the new API. Or maybe it doesn't matter to them and they just want working code 
    to continue to be working code. At least until such a time as they need the new 
    features, or new efficiency. Remember the First Rule of Optimization: DON'T. 

sigh - one of the big reasons behind my I left the world of Microsoft and Windows behind ~15 year ago was to be free of this kind of forced change...

1: Not giving up my .xinitrc/.Xresources or E16 theme, either. In all cases (along with openrc/sysvinit), they have over a decade's worth of bugfixes and tweaks. Any replacement would have to be very good to be worth the time/effort involved in switching.

2: to be fair, Gnome has been merging thing that shouldn't be merged all the way back to the beginning of the project, and is as much at fault here as systemd itself.

3: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

I think Gnome has been taking that approach going back years in part because of the opposite criticism: many people attack Linux UI as being a hodge-podge with no coherent design, comparing it unfavorably to a unified UI system like OSX's, which has a coherent and integrated take on windowing/libraries/widgets/etc. One of Gnome's goals was to fix that. They might unsuccessful at doing so, but attempting a unified/integrated UI was/is a core project goal, so I'm not surprised that they'd have no shyness about integrating components that Unix has traditionally kept separate. The tiling window manager scene (which I prefer myself) is perhaps the polar opposite (some wms don't even integrate the status bar into the wm), but isn't really targeting Gnome's target audience either.

In addition to the prudential concern issues (which are laid out in the article), there are some concrete issues:

With sysv init, it is very easy to add new services that may not be supported out of the box. There are scripts like rc.local, etc, which can be edited to start anything. This means that setting up a new service that can be supported properly is a lot more work, especially if it is for development systems. While I haven't had systemd crash, I have had issues with stuff requiring manual start (i.e logging in as root and running the startup script for the app) when a simple rc.local-type approach would have been far simpler.

Another problem I have had is the issue of process accounting, where if the process starts up a daemon and exits, then systemd has trouble determining the status properly. This can cause issues for things like monitoring (which means basically I don't use systemd for monitoring whether services are running).

What this means, in essence, is that to make this work the way I would like I have had to reinvent part of the sysv init system inside of systemd and then handle things like process tracking the old fashioned way (pid files and shell scripts).

In short, in addition to the "I don't want my system to have to reboot and this is a bad architecture for that requirement" you have quite a bit of areas where there are leaky abstraction layers which don't really add any benefit to administration of the system.

Except that sysv init, having tiny attack surface, very rarely needs updates.