How X Window Managers Work, and How to Write One (2014)

>Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.

Was bad faith, naive, and frankly... insulting -- so I just chose to ignore it.

My reservations are well grounded, and when ones concerns are echoed by ESR, Linus, and tytso, I don't think they can be dismissed so easily.

Certainly some people wanted features that sysvinit couldn't provide, obviously, because so much effort went into systemd. But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)

I'm still using sysvinit on my main machine, and on all "critical" servers not because I have an advanced use case requiring a specialized init system but because I have a simple use case and a computing philosophy that requires simple init system. I have a strong (I'll admit, borderline fanatic) affinity for the "unix philosophy" of accomplishing things through the composition of simple to understand and debug tools that do one thing, and do it well.

To me, SystemD is about as far as you can get from "do one thing, and do it well" and "simple to understand and debug". It's a monolith (right?) which is why it's not running directly on the hardware. Unfortunately, Debian now builds some packages that I use occasionally with SystemD specified during the configure stage, and I don't want to maintain my own packaging of tools with different compile flags, at least not yet. Presently, I solve this by having a separate VM for "all tasks that need systemd", but I hope to replace that with something lighter weight, perhaps containers instead.

SystemD provides some features I imagine most users want, and that I strongly see the benefit of, but for the vast majority of those features, those reasons I'd want to use systemd, I'd already solved it myself, through the composition of existing and simple tools. A good example is networking. My computer does exactly what I want it to do, every time, in all permutations of wireless, wired ethernet, wireguard, knowing to mount certain NFS shares when I'm at home, randomizing mac address in certain situations, knowing when &c. It's great functionality, and I got there over time by building simple and easy to debug shell scripts, which call out to tools like `ip`, `iw`, `wpa_supplicant` and reading from /sys/class/net.

I also don't use pulseaudio, as audio happens to be one of the subsystems I have strong experience with, and pulse is an unnecessary (and sometimes error prone) layer, considering I get along just fine with ALSA.

The one thing I'm jealous of is faster boot times. But I'll happily boot a few seconds slower in exchange for PID 1 being simple, and my other services being simple and hence easy to debug.

Fonts from one machine Window management from another An application running on yet another, with it's program data sourced from yet another machine accessing data on still another machine. All of which is displayed on another machine also supplying user input.

Or, I could do something crazy like put a window on your display, with appropriate permission of course, and you could interact with it.

A big wall type display could take windows from a number of users.

The promise back then, and something I used a lot, an many still do use today, is being able to run something and display it somewhere else. Say my cellphone is on my desk. I could ask it to do something for me, and the window into that activity appears on the display like any other window does.

Another case might be several users running on one machine each with their own displays and inputs.

Here is a real world case:

High end CAD software, managed data, many users.

With X, one can make a big application server and that is not visible to users at all in terms of the application or data to be manipulated.

Users run the program via X, running X servers on anything they want. PC, Mac, Linux, whatever.

The only way to interact with the managed data is through the application.

One copy of the application, one data repository, many users.

With X doing that kind of thing is easy, and it works whether one user runs the app on their local machine attached to a shared data repository, or many users run on a remote machine perhaps that machine itself also holding the data repository.

X also supports exactly this. Qt uses this information. gtk doesn't for whatever reason, forcing the workarounds.

Most the so-called "X limitations" are actually just toolkit bugs if you get into the weeds.

This is completely false. X offers both nesting for full isolation and a concept of "untrusted" connections for partial isolation. This is the reason why ssh -Y and ssh -X are separate things.

These facilities could use a little love to make them user friendly, etc., but they're there and have been for ages (enabled by default around 2013, present before then).

X also supports advanced mixed DPI, providing all the information to the application to handle it as they see fit.