Pavucontrol is my go-to GUI application for full volume control on my Fedoradesktops. Recently (since updating to Fedora 40), pavucontrolstarted to choose giant font rendering , which made itmore than a bit inconvenient to use. Today I attempted to diagnosethis, without particular success, although I did find a fix , although it stillleaves pavucontrol with weird rendering issues. But investigatingthings more deeply led me to discover just what was going on.

Pavucontrol is one of the applications that is now based on

As sort of a follow on to how plaintext is not a great format forlogs , I said something on the Fediverse :

A hill that I will at least fight on is that text based structured logformats are not 'plain text logs' as people understand them, unlessperhaps you have very little metadata attached to your log messagesand don't adopt one of the unambiguous encoding formats. Sure you canread them with 'less', sort of, but not really well (much less skimthem rapidly)

Fedora, like various Linux distributions, has a system of 'alternatives',where several programs from several different packages can providealternative versions of the same thing, and which one is used ischosen through symbolic links in /etc/alternatives (Fedora's versionappears to be this implementation ). These alternatives canhave priorities and by default the highest priority version ofsomething gets to be that thing; however, if you manually chooseanother option, that option is supposed to stick. On a Fedora system,you

I recently read Phil Eaton's A write-ahead log is not a universalpart of durability ( via ),which is about what it says it's about. In the process it discussesusing Unix's fsync() to achieve durability, which woke up a littletwitch I have about this general area, which is the differencebetween durability and integrity (which I'm sure Phil Eaton is fullyaware of; their article was only about the durability side).

The core integrity issue of simple

Over on the Fediverse, I mentioned a little irritation with myiPhone :

Pretty much every time I change the time of an alarm on my phone Iam irritated all over again at the fundamental laziness and roboticcomputer-ness of time controls. What I want to do is move the timeforward or backward, not to separately change (or set) the hours andthe minutes. But separate 'hour' and 'minutes' spinners or options arethe easy computer way out so that's how UIs implement it

People are periodically grumpy that systemd's journal(d) doesn'tstore logs using 'plain text'. Sometimes this is used to imply thatyou can't have plain text logs with systemd's journal (or, morerarely, to state it). This is false. The systemd journal doesn'tforce you to not have plain text logs. In fact the systemd journalis often a practical improvement in the state of plain text logs,because your plain text logs will capture more information

Recently I saw some grumpiness on the Fediverse about systemd'sjournal not using 'plain text' for storing logs. I have variousfeelings here, but one of the probably controversial ones is thatin general, plain text is not a great format for logs, especiallysystem logs. This is independent of systemd's journal or of anythingelse, and in fact looking back I can see signs of this in my ownexperiences long before the systemd journal showed up (for instance,it's part of giving

Triggered by our recent (and repeated) issue with xinetd restarts , we're considering partially orcompletely replacing our use of xinetd with systemd socket unitson our future Ubuntu 24.04 machines. Xinetd generally works okaytoday, but our perception is that it's fallen out of style and maynot last forever as a maintained and packaged thing in Ubuntu (it'salready a 'universe' package). By contrast, systemd socket unitsand socket activation is definitely sticking around. However, I

A few years ago I wrote about how HTTP/3 needed us (and otherpeople) to make firewall changes to allow outgoing UDP port 443traffic . Recently this entry got discussed on lobste.rs ,and the discussion made me think about if our (sort of) default ofblocking outgoing traffic was a good idea these days, at least inan environment where we don't know what's happening on our networks .

(If you do know exactly what should be on your networks and what