Wandering Thoughts archives

The problem with a custom laptop environment: designing it

For reasons beyond the scope of this entry I was recently irritated into putting my custom laptop environment plans into action (I do a surprising number of things due to irritation). In the interests of avoiding analysis paralysis I'm basing the first attempt on my existing fvwm-based desktop configuration (with an ever increasing number of changes). Somewhat to my surprise, the difficult part so far has not turned out to be what I expected.

My two biggest problems are related. The first one is simply designing things, in the sense of what goes where and how things will actually work (and also how I will avoid everything looking hideously ugly, which is so far being harder than I'd like). My usual desktop layout doesn't really work on a 1024 by 768 screen (there just aren't enough pixels) and I'm pretty sure I'm going to need a collection of new launchers and widgets.

(I'm basing this partly on my experience with my current Gnome 2 environment on Fedora 14, where the Gnome taskbar has launchers for several things and I use them frequently.)

The second problem is that there seem to be a huge collection of choices for the various pieces of such an environment (and some of them even work). Since I need some stuff beyond what I already have in my existing desktop fvwm configuration I've been forced into picking my way through this field of options. Many of the programs seem very powerful but their documentation is mostly focused on people who already know what they do and what they're good for; sadly this doesn't describe me right now.

(What I dream of finding is a guide to assembling your own custom desktop, laying out the options for application launcher bars, system trays, status monitors, essential applets, and so on. Given the huge amount of work it would take to assemble such a thing, this is crazy talk.)

On a closely related issue, I will note that there is nothing like trying to copy bits and pieces of your personal environment to another machine to rub one's nose in just how intertwined, baroque, and encrusted with various relics of history the whole mess is. I'm getting very tempted to conduct a slash and burn expedition through $HOME/bin in order to clean up a bunch of things.

(I should not have just looked at how many files I have in there, because the answer is 'too many'.)

PS: part of my uncertainty is that I haven't tried my in progress environment on the actual laptop yet. So far I've only been working in a VM (at the right resolution) since I wanted to have the basics there before I reinstalled the laptop.

Update: all my grand plans fell through spectacularly when I tried my in-progress environment on the actual laptop. See here for the depressing update and reversal of plans.

Sidebar: on the matter of alternate window managers

Most of the popular modern window managers for minimal desktops seem to be primarily or entirely tiling ones. From current experience with my laptop, a 1024 by 768 resolution is simply too small to not have plenty of overlapping windows (and thus a whole bunch of support for moving, restacking, and resizing windows). I also like using some amount of the mouse and don't want to have to memorize a big list of keyboard sequences for a machine that I only use infrequently.

I've looked briefly at awesome but the idea of writing Lua to configure my window manager is even more extreme that fvwm's elaborate configuration language. Maybe I'll try it some time for a (strictly hypothetical) version two of my custom laptop environment.

A fun problem: monitoring randomness reduces it

The Linux kernel exports a /proc entry that reports on how many bits of entropy are in the kernel's randomness pool, /proc/sys/kernel/random/entropy_avail. Recently, Matt Simmons noticed his server monitoring looking at this and noticed that when he checked the /proc entry by hand the reported entropy went down. It turns out that this was not random fluctuations and the explanation for it is rather interesting, as pointed out by @rejectreality on Twitter.

As a security measure, modern versions of Linux randomize various parts of a process's memory space in various ways; this goes by the general name of ASLR (address space layout randomization) and especially affects the stack. In order for this randomness to be really effective it should be unpredictable, which means that it can't be based on any of the usual simple seeds for pseudo-random generators like the time of day the process started or its PID. Instead it turns out that the kernel exports some randomness to user space processes when it execs them.

You can see where this is going. This exported randomness comes from the kernel's general random number infrastructure and so it winds up depleting some of the entropy from the entropy pool. So if you run a program to read out the value of entropy_avail, the very act of doing so will deplete some of that entropy. If you repeatedly run the program you'll repeatedly lower the entropy (although repeatedly reading the entropy value from within one program won't do it). Of course this isn't unique to looking at entropy_avail; running pretty much any program will deplete some entropy no matter what it does.

(It turns out that this has apparently led to some problems. Indeed most of our active servers turn out to have very low entropy_avail values. Hopefully people aren't doing much that required strong randomness.)

Fedora 19 and the search for volume management

Every so often I am unhappily reminded of one of the hidden problems of modern Linux systems. Today's direct problem is that when I upgraded my office machine to Fedora 19, automatic mounting of USB memory keys and so on stopped working because gnome-fallback-mount-helper (which is what I've used since Fedora 16) has now disappeared, just like every one of its predecessors. The real core problem is that a great deal of modern Linux is essentially opaque.

After all, I know that Gnome, Cinnamon, MATE Desktop, XFCE, LXDE, and KDE (at least) all implement volume management somehow, through something. If modern Linux was a relatively transparent environment it would be possible for me to actually find out what bit of one of the desktop environments did this volume management and then just run it by hand; I could probably find at least one of these that did it with a basically standalone program. As is now, though, while some of these may actually have such a program it appears all but impossible to actually find it due to the programs, components, and interconnections all being relatively opaque.

This is all the more frustrating because such a program is actually pretty trivial. The hard work is done by system daemons that broadcast device information over DBus (and can be asked to mount the devices). All that automatic volume management actually needs is a little program that listens for announcements of appropriate new devices showing up and then tells the system 'yes please mount that'.

(There are reasonable reasons why such a little program isn't good enough for actual desktop environments and so probably doesn't exist.)

DBus itself is part of this opacity issue because it has become a central IPC mechanism without particularly good observability. While you can monitor some amount of DBus traffic, as far as I know there is no way to tap into it to find out (for example) which process is sending certain sorts of messages to a standard system bus address. If there was such a monitoring method you could snoop on an existing desktop environment to find out who was sending the 'please mount' DBus messages. This might not give me a distinct standalone program I could run, but at least I'd have a better idea of how the environment was actually doing all of this magic.

(Possibly I am behind the times and all of this stuff is nicely documented somewhere, along with writeups of standard modular tools that people use to support the various magic desktop operations that happen today. I would actually like that to be the case even if it would make this entry a bit foolish.)

(I've written before about the difficulty of custom environments on modern Linux, which is another aspect of this.)

Systemd needs sensible, non-truncated output

If you run 'systemctl status <service>', you get (among other things) some recent log messages from the service in question. Well, in theory you get that. In practice, well, here is part of what one of my machines shows:

Jul 15 17:18:20 mumble123.cs.toronto.edu unbound[31622]: [31622:0] notice: in...

Yeah.

What's Unbound trying to tell me? I have no idea because systemd has truncated the output in a useless way. I don't believe in truncating output by default to start with but if systemd is going to do it it should do it intelligently. Almost all of this line is useless. Especially useless is the huge hostname, because by definition systemctl is reporting on things from the local machine.

Of course, you may say, systemd is really just reporting some lines from syslog and chopping them off at 77 characters and thus the formatting is not its fault. Well, actually, it is. If systemd is going to truncate the output at all, it has to take responsibility for the formatting of the whole thing; effectively the rule is 'you break it, you own it'. Truncating the output is breaking it, so it becomes systemd's job to make it useful again.

Unfortunately this isn't a small issue. If you have a service that doesn't start, these very log messages may contain important information, information that systemd by default won't show you. You can make systemd show you in various ways (piping the output to something, remembering the --full argument, and probably others), but speaking as a sysadmin, you shouldn't have to remember any of this. Systemd should do the right thing by default because sysadmins already have enough to keep track of and truncating the output (especially in useless ways) is almost never what we want.