Today, for reasons beyond the scope of this entry, I was checkingthe various SSH host keys that some of our servers were using, byconnecting to them and trying to harvest their SSH keys. When Itried this with a CentOS 7 host, I discovered that while I couldget it to offer its RSA host key, I could not get it to offer anEd25519 key. At first I wrote this off as 'well, CentOS 7 is old',but then I noticed

Last night, one of our compute servers briefly stopped acceptingSSH connections, which set off an alert in our monitoring system . On compute servers, the usual causefor this is that some program (or set of them) has run the systemout of memory, but on checking the logs I saw that this wasn't thecase. Instead, sshd had logged the following (among other things):

sshd[649662]: error: beginning MaxStartups throttlingsshd[6496

UEFI has been the officialfuture of x86 PC firmware for a very long time, and for much ofthat time your machine's UEFI firmware has still been willing to bootyour systems the traditional way x86 PCs booted before UEFI, with'BIOS MBR '(generally using UEFI CSM booting ). Some people haveno doubt switched to booting their servers with UEFI (booting) yearsago, but for various reasons we have long preferred BIOS (MBR)booting and almost always configured ourservers that

IBM compatible x86 PCs have come with firmware since their firstdays. This firmware was called (the) BIOS , and so over time 'BIOS' becamethe generic term for 'IBM compatible x86 PC firmware' (which couldcome from various companies who carefully reimplemented it fromscratch in ways that didn't violate IBM's copyrights). Over time,PC firmware ('BIOS') got more complex and acquired more (boot time)user interface features, like all sorts of splash

Historically, many filesystems have devoted a significant amountof effort to sophisticated space allocation policies. For example,in Unix one of the major changes from V7 to 4.x BSD was the changeto the Berkeley Fast File System ( also ) with its conceptof 'cylinder groups' that drastically improved the locality of filedata, directory data, and inodes. Various other (Unix) filesystemallocation related technologies have been developed since, forexample the idea of delaying deciding where exactly data will livein the filesystem until

Today we discovered something :

Apparently our (university) machine room now comes with the bonus ofa visiting raccoon. I have nothing against Toronto's charming trashpandas, but I do have a strong preference for them to be outdoors andmaybe a bit distant.

(There are so far no signs that the raccoon has decided to be aresident of the machine room. Hopefully it is too cool in the room forit to be interested in that.)

Naturally there is a story here. This past Monday morning

Ubuntu 24.04 LTS has just been released and as usual it's on our minds, although not as much soas Ubuntu 22.04 was . So once again I feellike doing a quick review of the state of Python in 24.04, asI did for 22.04 . Since Fedora 40 has alsojust been released I'm going to throw that in too.

The big change between 22.04 and 24.0

Over on the Fediverse I said something that's probably notparticularly surprising :

In re Canonical and Ubuntu: at work we are still using Ubuntu LTS(and we're going to start using 24.04), but this is on servers wherewe don't have to deal with snaps (we turn them off, they don't workin our environment). But the Canonical monetization drive is obviousand the end point is inevitable, so I expect we'll wind up on Debian

Once upon a time, back a reasonable while ago, I used to routinelyconfigure (in the './configure' sense) and build a fair amount ofsoftware myself, software that periodically got updates and soneeded me to rebuild it. If you've ever done this, you know thatone of the annoying things about this process is keeping track ofjust what configuration options you built the software with, soyou can re-run the configuration process as necessary (which maybe on new releases of