Recently I saw Serving 200 million requests per day with a cgi-bin ( via , and there's a follow-up ),which talks about how fast modern CGIs can be in compiled languageslike Rust and Go (Rust more so than Go, because Go has a runtimethat it has to start every time a Go program is executed). I'm along standing fan of CGIs (and Wandering Thoughts , this blog, runs as a CGI some of the time), but while

One of the GNU Emacs packages that I use is which-key (whichis now in GNU Emacs v30). I use it because I don't always rememberspecific extended key bindings (ones that start with a prefix) thatare available to me, especially in MH-E ,which effectively has its own set of key bindings for a largecollection of commands. Which-key gives me a useful but minimalpopup prompt about what's available and I can usually use that tonavigate to

Every so often I think about random things, and today's random thingwas how our environment mightlook if it was rebuilt from scratch as a modern style greenfielddevelopment. One of the obvious assumptions is that it'd involve alot of use of containers, which led me to wondering how you handletraditional Unix style login servers. This is a relevant issue forus because we have such traditional login servers and somewhat toour surprise, they still see plenty of use.

We have two sorts of loginservers

I've used OpenZFS on my office and home desktops (on Linux) forwhat is a long time now, and over that time I've consistently usedthe development version of OpenZFS, updating to the latest git tipon a regular basis ( cf ). There have beenoccasional issues but I've said, and continue to say, that the codethat goes into the development version is generally well tested andI usually don't worry too much about it. But I do worry somewhat,and

About five years ago I wrote an entry on what OSes we were using atthe time . Five years is both a short time and along time here , and in that timesome things have changed.

Our primary OS is still Ubuntu LTS; it's our default and we use iton almost everything. On the one hand, these days 'almost everything'covers somewhat more ground than it did in 2020, as some machineshave moved from OpenBSD to Ubuntu. On the other hand,

I recently read systemd has been a complete, utter, unmitigatedsuccess ( via among other places), where I found a mention of an interestingsystemd piece that I'd previously been unaware of, systemd-socket-proxyd .As covered in the article, the major purpose of systemd-socket-proxydis the bridge between systemd dynamic socket activation and aconventional programs that listens on some socket, so that you candynamically activate the program when a connection comes in.Unfortunately the systemd-socket-proxyd manual

Linux's NFS export handling system has a very convenient optionwhere you don't have to put all of your exports into one file,/etc/exports, but can instead write them into a bunch of separatefiles in /etc/exports.d. This is very convenient for allowing youto manage filesystem exports separately from each other and to add,remove, or modify only a single filesystem's exports. Also, one ofthe things that exportfs(8) can dois 'reexport'

A variety of things in typical graphical desktop sessions communicatethrough the use of environment variables; for example, X's $DISPLAYenvironment variable. Somewhat famously, modern desktops run alot of things as systemd user units , andit might be nice to do that yourself ( cf ). When you put these twofacts together, you wind up with a question, namely how the environmentworks in systemd user units and what problems you're going to runinto.

The simplest case is using systemd-run to

I recently wrote about a new little script of mine ,which I use to start programs in terminals in a way that I can interactwith them (to simplify it). Much of what I start with this tool doesn'tneed to run in a terminal window at all; the actual program will talkdirectly to the X server or arrangeto talk to my Firefox or the like. I could intheory start them directly from my X session startup script, as I dowith other things.

The reason I