I recently looked at Prometheus's new feature to keep alertsfiring for a while (often to avoid flapping alerts) and in the process realized that itwasn't really what I want. The simple way to put it is what I careabout getting less of is not the alerts themselves, but alertnotifications. And for that, what I really want is for notificationsthat can (at some point) aggregate together information aboutmultiple alerts over time. Instead of getting one notification eachtime the alert triggers,

Suppose, not hypothetically ,that you have a top level directory which contains some number ofsubdirectories, and you want to selectively create and maintain acopy of only part of this top level directory. However, what youwant to copy over changes over time and you want un-wanted thingsto disappear on the destination (because otherwise they'll stickaround using up space that you need for things you care about).Some of the now-unwanted things will still exist on the source butyou don't

In the past I've written about maybe avoiding flapping Prometheusalerts , which is a topic of interestto us for obvious reasons. One of the features in Prometheus2.42.0 is a new ' keep_firing_for ' setting for alert rules (documentedin Recording rules ,see also the pull request ). As describedin the documentation, it specifies 'how long an alert will continuefiring after the condition that triggered it has cleared' anddefaults to being off (0 seconds).

The traditional way to do a VPN is that your VPN endpoint ('server')is the single point of entry for all traffic from VPN clients. When aVPN client talks to anything on your secured networks, it goes throughthe endpoint. In what I'm calling a mesh-capable VPN, you can havemultiple VPN endpoints, each of them providing access to a differentnetwork area or service. Because it's one VPN, you still have a singleunified client identity and authentication and a single

Suppose that your organization has a VPN server that people use toaccess internal resources that you don't expose to the Internet. One ofthe traditional decisions you had to make when you were setting up sucha VPN server was whether you would funnel all traffic over the VPN, nomatter where it was to, or whether you'd funnel only internal trafficand let external traffic go over people's regular Internet connections.In many environments the answer is that the VPN server is only reallyfor internal traffic;

A while back I wrote about how you can sensibly move orcopy Prometheus's time series database (TSDB) with rsync . This is how we moved our TSDB, withmetrics data back to late 2018, from a mirrored pair of 4 TB HDDs on oneserver to a mirrored pair of 20 TB HDDs on another one. In that entryI also mentioned that we were hoping to use this technique to keep apartial backup of our TSDB, one that covered the last year or two.

Today on the Fediverse I saw a post by @nytpu :

Reminder that the C spec specifies an abstract virtual machine; it'sjust that it's not an interpreted VM *in typical implementations*(i.e. not all, I know there was a JIT-ing C compiler at somepoint), and C was lucky enough to have contemporary CPUs andexecutable/library formats and operating systems(…) designed withits VM in mind

(There have also been actual C interpreters, some of

Normally, pages of virtual memory are a relatively small size, suchas 4 Kbytes. Hugepages ( also ) area CPU and Linux kernel feature which allows programs to selectivelyhave much larger pages, which generally improves their performance. Transparent hugepage support isan additional Linux kernel feature where programs can be more orless transparently set up with hugepages if it looks like this willbe useful for them. This sounds good but generally I haven't hadthe best of luck with them :

It appears to have been '0

Over on the Fediverse I said something I want to elaborate on :

One of the reasons I still prefer BIOS MBR booting over UEFI is thatUEFI firmware is almost always clever and the failure mode of cleveris 💥 . I dislike surprises and explosions in my bootprocess.

Old fashioned BIOS MBR booting is very simplistic but it's also very predictable; pretty much theonly variable in the process is which disk the BIOS will pick asyour boot drive. Once that drive is chosen, you'll know exactlywhat