Short lived TLS certificates and graceful rollover in web servers

One of the bits of recent TLS news is that Let's Encrypt is goingto start offering 6-day TLS certificates . One of thethings that strikes me about this is that various software, webservers included, may finally be motivated to handle changed TLScertificates in a better way than is common today, because TLScertificates will be changing much more frequently.

A lot of programs that use TLS certificates, web servers included,have historically (and currently) not actually 'handled' changingTLS certificates as such


Browser feed reader addons don't seem to do very well on caching

Over on the Fediverse, I said something disappointing :

Browser addons for syndication feed fetching appear to be theabsolute worst for frequent feed fetching and ignoring everything theserver says about this. They'll ignore Cache-Control hints for Atomsyndication feeds, ignore HTTP 429 errors, ignore any retry timing insaid headers (not surprising), and keep trying every few minutes. I amsorely disappointed.

(Or at least I assume this is from addons, based on the user-agentstrings.)

It


We have an unusual concern when we use Let's Encrypt

One of the bits of recent TLS news is that Let's Encrypt is goingto start offering 6-day TLS certificates . When I wasthinking about my reaction to this, I realized that we have some unusual concerns thatmake me more nervous than average about getting Let's Encrypt TLScertificates with such short lifetimes.

I'm not particularly worried about Let's Encrypt's certificateissuance going offline as a whole for five or six days. If thathappens, something catastrophic is going on in the


Some notes on "closed interfaces" in Go

One reaction to basic proposals for union types in Go is to notethat "closed interfaces" provide a lot of these features ( cf ).When I saw this I had to refresh myself about what such a closedinterface is, and then think about some of the potential issues andlimitations involved, leaving me with some things I want to notedown for my later reference.

What I've seen called a closed interface is an interface thatrequires an unexported method:

type Closed interface {  isClosed()  NormalMethod1

I think Go union type proposals should start with their objectives

At this point I've skimmed a number of relatively serious uniontype proposals for Go(which is to say, people who were serious enough to write somethingsubstantial in the Go issue tracker). One of the feelings I've woundup with as a result of this is that any such union type proposalshould probably start out by describing what its objectives are,not what its proposed syntax is.

There are a number of different things union types in Go could do,ranging from creating an interface type that


ZFS on Linux and block IO limits show some limits of being out of the kernel

ZFS on Linux (or, if youprefer, OpenZFS on Linux) is, famously, not included in the Linuxkernel source for a number of reasons (starting with its licensing).The usual drawback of this is that (Open)ZFS can need modificationsto support new Linux kernel versions because the internal kernel interfaces keep changing and, unlikein-kernel modules, there's nothing that keeps OpenZFS in sync withthem. However, that ZFS is out of the kernel also has some otherlimits, and


Cgroup V2's cpu.idle setting versus process niceness

In a comment on my entry on improving my desktop's responsivenesswith the cgroup V2 'cpu.idle' setting , Leah Neukirchen asked a good question:

How does this differ in practice to just using a high niceness forthese jobs?

This is a good question and after doing some quick experiments, atthe moment I have only partial answers. Let's start out with thebasics. If you want to leave interactive programs happy with lifeon your Linux desktop with a reasonably decent core count while you


Improving my desktop's responsiveness with the cgroup V2 'cpu.idle' setting

I periodically build things on my Linux desktops that use all ofthe CPU that they can get; my two general examples are Firefox andthe Go toolchain (Firefox uses all the CPU during its long compileprocess, while the Go toolchain uses it during self-tests). Doingthis has historically caused my desktop session to get less responsive,which I tended to especially notice in how fast dmenu popped upwhen I invoked it ( also ).

(Because dmenu normally pops up so fast, my reflex is to hit


The long (after)life of some of our old fileserver hardware

Over on the Fediverse, I mentioned that we were stillrunning a machine in production that was old enough that its BMCrequired Java for its KVM-over-IP functionality (and I've given upon working with it, rather than try to maintain a Java environmentthat could actually work with it). Naturally there's a story here.

The specific hardware in question is from our second generationZFS fileservers , which ran OmniOSand which we used between 2014 and somewhere around 201


My wish for VFS or filesystem level cgroup (v2) IO limits

Over on the Fediverse, I wished for better IO limits than cgroup (v2)has today :

I wish Linux cgroups (v2 of course) had an option/interface thatlimited *filesystem* IO that you could do, read and/or write. Theyhave 'block IO' limits but these are often ineffective for anassortment of reasons, including that you're not doing block IO (hi,NFS) or that the underlying filesystem and storage stack doesn'tsupport them (..