Over on the Fediverse, I had a realization :

This is my face when I realize that on a big multi-core machine, Iwant to do 'sed ... | sed ... | sed ...' instead of the nominally moreefficient 'sed -e ... -e ... -e ...' because sed is single-threadedand if I have several costly patterns, multiple seds will parallelizethem across those multiple cores.

Even when doing on the fly

I've been a fan of the Cloudflare eBPF Prometheus exporter for some time, eversince I saw their example of per-disk IO latency histograms. Andthe general idea is extremely appealing; you can gather a lot ofinformation with eBPF (usually from the kernel), and the abilityto turn it into metrics is potentially quite powerful. However,actually using it has always been a bit arcane, especially if youwere stepping outside the bounds of Cloudflare's canned examples .So here's some notes

One of the interesting and convenient things about Ubuntu forpeople like us is that theyprovide pre-built and integrated ZFS kernel modules in theirmainline kernels. If you want ZFS on your (our) ZFS fileservers , you don't have to add any extra PPArepositories or install any extra kernel module packages; it's justthere. However, this leaves us with a little mystery , which is howthe ZFS modules actually get there. The reason this is a mysteryis that the ZFS modules are not

Every window system has windows, as an entity. Usually we think of theseas being used for, well, windows and window like things; applicationwindows, those extremely annoying pop-up modal dialogs that are alwaysinterrupting you at the wrong time, even perhaps things like pop-upmenus. In its original state, X has more windows than that. Part of howand why it does this is that X allows windows to nest inside each other,in a window tree, which you can still see today

In a comment on yesterday's entry talking about X's server sidegraphics rendering , B.Preston mentionedthat another reason for this was to conserve memory. This is verytrue. In general, X is extremely conservative about requiringmemory, sometimes to what we now consider extreme lengths, and thereare specific protocol features (or limitations) related to this.

The modern approach to multi-window graphics rendering is that eachwindow renders into a buffer that it owns (often with hardwareassistance) and then the

Recently, Thomas Adam (of fvwm fame) pointedout on the FVWM mailing list ( here , also ) a differencebetween X and Wayland that I'd been vaguely aware of before buthadn't actually thought much about. Today I feel like writing itdown in my own words for various reasons.

X is a very old protocol (dating from the mid to late 1980s), andone aspect of that is that it contains things that modern graphicsprotocols don't. From a

When I wrote about how the speed of improvement in servers mayhave slowed down , I didn't address CPUcore counts, which is one area where the numbers have been goingup significantly. Of course you have to keep those cores busy, butif you have a bunch of CPU-bound workloads, the increased core countis good for you. Well, it's good for you if your workload is genuinelyCPU bound, which generally means it fits within per-core caches.One of the areas

In an ideal world, your metrics never change their names; once youput them into a Grafana dashboard panel, they keep the same nameand meaning forever. In the real world, sometimes a change in metricname is forced on you, for example because you might have to movefrom collecting a metric through one Prometheus exporter to collecting it with another exporter which naturally gives it a different name. And sometimes a metricwill be renamed by its source.

In a Prometheus environment, the verybrute force way to deal

One of the bits of technology news that I saw recently was that AWSwas changing how long it ran servers, from five years to six years.Obviously one large motivation for this is that it will save Amazona nice chunk of money. However, I suspect that one enabling factorfor this is that old servers are more similar to new servers thanthey used to be, as part of what could be called the great slowdownin computer performance improvement.

New CPUs and to a lesser extent memory are somewhat better than