At this point we've been running our ZFS based NFS fileserverenvironment for about fifteenyears, starting with Solaris 10 and evolving over time to the currentUbuntu 22.04 based servers. Over that time we've managed the variousiterations of the same basic thing primarily through a local setof programs ( all with names starting in 'san', despite the factthat we don't have a SAN any more ).These programs have always been written in Python. They started outas

Once upon a time, back in V7 Unix or so, Unixsignal handling in programs was nominally very simple. You'd set asignal handler with signal(2) , andthen when it was invoked it would do things, possibly includingusing longjmp(3) topop back to the top level of your programs. Among other examples,the Bourne shell famously used SIGSEGV as a memory allocationmethod . Even today, a lot of programsbehave as if this is the signal handling model in effect;

It has been an article of faith for some time that "cool URLs don'tchange", as seen in (for example) this 1998 W3C article writtenby Tim Berners-Lee (you mayhave heard of him). Sadly, time has shown that cool URLs do oftenchange , and sometimes they become inaccessibleeven when they don't change . But there isanother part of this that I feel the need to say out loud: coolURLs keep their contents .

It

The idea that "cool URLs don't change" has been an article of faithfor a very long time . Ofcourse this is false in practice; decades of experience have shownus that cool URLs do change for all sorts ofreasons ( for example, forced changes in your domain name ). Recently, we've seen at leasttwo examples where cool URLs may not change as such, but they dobecome broadly inaccessible.

The first case is Reddit, where people's protests against recentcorporate moves

We have a bunch of Linux fileservers ,which use ZFS pools on ordinary SATA SSDs and export the filesystemsfrom those pools over NFS. To make managing this environment easier,we have a suite of local programs (including our own ZFS sparessystem ). All of these tools havenames that start with 'san' (for example 'sanpool' and 'sanspares').All of the hostnames of the fileservers also start with 'san'(they're mostly but not entirely named after cities, so we

We all know about the HTTP User-Agent header ,which browsers and other web things send to web servers. The nominalpurpose of this is covered in RFC 9110 section 10.1.5 , and it'snot terrible, but in practice websites have abused the header foryears (if not decades) and the whole thing is a major mess ( eg ).A very long time ago, some mail clients decided that they'd advertiseby adding an 'X-Mailer'

Today I confessed on the Fediverse that I had somehowmentally overwritten what I once knew about Python's assert with a C-like version that I wrote as' assert(expression) ' ( which I apparently started doing morethan a decade ago ). What caused me to noticethis was that I was revising some Python code to cope with a newsituation, and I decided I wanted to fail in some way if an impossiblething turned out to not be as impossible as I thought. This wasn't

On June 15th (2023), Let's Encrypt paused issuing certificates for about an hour ( their status issue ).Later, Andrew Ayer wrote up the outside details of what happenedin The Story Behind Last Week's Let's Encrypt Downtime , andLet's Encrypt's Aaron Gable explained the technical details inthe Mozilla issue about it . Thereasons for what happened are interesting, at least to me, andmake a lot of sense even if the result is unfortunate

Recently I saw this Fediverse post on using dedicated test IPsand domains ( via ), and it sparked a littledull light of realization in my mind. I've always considered itobvious why your documentation shouldn't use real IP addresses orIP address ranges. They belong to someone, they are or may becomeroutable on the Internet, and if someone reading your documentationuses your sample IP ranges, bad things happen. However, it wasn'tas obvious to me why you shouldn't use RFC