The early Unix machines were what we would today call 'servers',and generally used serial terminals as their system console (well,they used serial ttys for pretty much everyone, but one of them wasspecial). But then Unix workstations came along, which is to saysmall Unix machines with graphical displays. In theory these machinescould have been designed to boot with their system console as aserial terminal (and often you could reconfigure them that way),but in practice that would have been rather awkward,

In the abstract, Linux's kernel mode setting (KMS) is having thekernel configure the display resolution, depth, and frequency inthe graphics hardware instead of leaving it to user level code likethe X server. In practice, KMS is three things that are currentlycompletely tied together; the kernel graphics driver handling theactual mode setting, the kernel console switching from VGA textmode to a framebuffer console , and thekernel changing the graphics hardware to what is supposed to be theideal (display) resolution when

If you've been running x86 Linux servers for long enough, you'veprobably noticed two changes in the kernel's text console . On the one hand, the text console has gottensubstantially bigger, sporting sizes like 128x40 instead of themuch smaller old sizes, for example 80x25. On the other hand, textoutput to the console has generally gotten slower, usually muchslower than you would expect for the change in console size. Thesetwo changes

Once upon a time, not quite back when dinosaurs roamed the earth,computer displays were CRTs and fundamentallyoperated by scanning an electron beam or beams back and forth overthe screen. Usually the computer sent the CRT an analog streamof either monochrome or red, green, and blue intensity signals, andthe CRT did all the work of scanning the electron beam(s) acrossthe display. Initially, computer CRTs tended to work only at asingle frequency of these signals, the horizontal and verticalscan rates . As

One of the cornerstones of modern cryptography algorithms is Kerckhoffs's principle , "acryptosystem should be secure even if everything about the system,except the key, is public knowledge". The reasons for having yourcryptography algorithms be public knowledge are usually explainedin pragmatic terms ( eg ),and they're all very good reasons, but for a while it's been rattlingaround in my head that there's also a mathematical informationtheory basisto say this.

In a sense, the fundamental problem in

TLS Certificate Transparency is a system where browser vendors require TLS Certificate Authoritiesto publish information about all of their TLS certificates incryptographically validated logs, which are generally run by thirdparties (see also Wikipedia ). Theinformation in CT logs is public and various people actively monitorthem, sometimes for nasty purposes such as rapidly compromisingnew Wordpress websites ( also ).

Certificate transparency is partly a de facto replacement for earliersystems that attempted to do certificate revocation at scale on theweb, those being Certificate Revocation Lists (CRLs)

Suppose that you have some hosts that run additional exporters overand above the Prometheus host agent , such as the mtaillog exporter or perhaps a Blackboxexporter that lets you check an additional network segment. Obviouslyyou want to alert if one these additional exporters is down, butif the host itself is down you don't necessarily want to also betold that all of its exporters are down. It's sort of implied byeverything on the host is down with it.

When I was writing alerts for mtail (

Back in my entry on monitoring the status of Linux networkinterfaces with Prometheus ,I mentioned that one of our alerts was for if any of the smallnumber of network interfaces that were supposed to be at 10G weren'tactually at 10G. However, I didn't explain how you did this; instead,I sort of treated it as obvious, since I had earlier written anentry that sort of did this .

(At some point what's obvious to me about PromQL will stop

Generally, the path portion of web URLs maps more or less on to the idea of a hierarchical filesystem ,partly because the early web was designed with that in mind . However, in thinking about this I'verealized that there is one place where paths are actually a supersetof the broad filesystem API; in fact this place actually causessome amount of heartburn and different design decisions in webservers when they serve static files.

The area of divergence is that in the general filesystem API,directories don't have