Wandering Thoughts archives

Running servers and Fred Brooks on transforming programs to products

One of the seminal books on software engineering and project management is Fred Brooks' justly famous The Mythical Man-Month. One of the things that Brooks discusses in the book is the additional effort it takes to transform a program (that has been written) into a product (that can be sold). The modern open source world has its own equivalent of this transformation that many people experience; to make your program useful for other people it needs documentation, build instructions, and often generalization and more testing than you gave it in your own personal use.

A while back I wrote an entry about how running servers and services well is not trivial, which is about exactly that. It has recently occurred to me that one part of this difficulty, and also how setting up and running servers often appears easy for non specialists, is another version of Fred Brooks' transformation from programs to products and the extra effort it takes. Just as it's easy to write a one off program for your own use, it's easy these days to set up a one off special server. But that's not the server equivalent of a product; it's the server equivalent of a program before it's been transformed into a product. To become a product (a production server), you need a whole raft of additional things (many of which I outlined in my entry).

Many programs can be transformed into products through incremental improvements and developments (writing documentation, for example). Unfortunately servers are often less malleable this way, and it may not be very easy (or even possible) to transform a casually set up server into a production grade server. Often you'll wind up rebuilding the server from scratch. The good news is that it's usually much easier (and faster) to build new versions of servers than it is to rewrite programs from scratch.

I think that this can also provide a guide and a caution for when you should set up a casual server yourself. If all you need is the server equivalent of a one-off program, you can spin it up just as you would write that program. But watch out; just as one off programs not infrequently get drawn into (or pressed into) long term use, your 'one off' server may not be so temporary or unimportant after all. If it becomes a load bearing component of your environment, the initial quick approach will likely have left you with lingering problems.

Linux desktop application autostarting is different from systemd user units

When I wrote about how applications autostart on modern Linux desktops, there was a Reddit discussion, and one of the people there noted that things could also be autostarted through systemd user units. As covered in the Arch Wiki page on this, Linuxes that are systemd based generally automatically start a 'systemd --user' user systemd instance for you, and one of the things this will do is it will start things in ~/.local/share/systemd/user and ~/.config/systemd/user, which you can manipulate.

However, there are some significant differences between the two that help explain why Linux desktops don't use systemd user units. The big one is that systemd user units are per-user, not per-session. By their nature, desktop applications are a per session thing and so not a great fit for a per-user system. In fact even getting systemd user units to be able to talk to your desktop session takes what is basically a hack, as covered in the Arch wiki section on DISPLAY and XAUTHORITY, and this hack must be carefully timed so that it works correctly (it has to happen before units that need to talk to your desktop are started, and that means they have to be terminated when you log out).

Desktops also have a lot more fine control over what gets started with their current mechanisms. Obviously these things only get started for desktop sessions, not things like SSH logins, and they can be specific to certain desktops or not start in some desktops. I don't believe there is a native systemd unit option for 'run only if this environment variable is defined', so you can't readily make a systemd unit that only runs in desktop sessions, never mind only a particular sort of desktop.

(Relying to any significant degree on user units would also more strongly tie desktops to systemd, although I don't know if that's something they worry about these days or if it's full steam ahead on systemd in general.)

My general impression is that systemd user .service units are not a good fit for what most users want and do with autostarting things today, whether or not they're using a desktop. Systemd user units are probably a better fit for socket and dbus units, because those are more naturally activated on the fly as needed, but I don't know if people are doing this very much (especially for desktop related things).

(As a practical matter, I'd consider it pretty obnoxious if a program decided to set itself to autostart as a systemd user unit. I suspect I'm not alone in this.)