Regular expressions are effectively a (hard) programming language

A while back I read Hillel Wayne's Regexes are Cool and Good ,which sparked some thoughts about why regular expressions arefamously considered difficult. So here is one of them: regularexpressions are effectively a programming language, and that languageis a 'hard' one. This gives regular expressions two broad problems.

The first problem is the general problem of working with programminglanguages. Writing code in any programming language requires figuringout how to solve your problem with the features that the languagehas, without overlooking anything or


Serving static files versus dynamic web server APIs

In one part of There is no such thing as a static website ( via ),Wesley Aptekar-Cassels writes:

The world has changed since the static/dynamic divide wascreated. There have now been a significant number of attempts to"platformitize" dynamic computation — "serverless" programminglike AWS Lambda, WASM runtimes like those provided by CloudFlare andFastly, full container deployment via Fly.io and cloud providers. Noneof these have an API nearly as stable as the filesystem API usedto host static files,


Setting up Linux fair share CPU scheduling with systemd and cgroup v2

These days, modern versions of systemd on modern Linuxes, includingthe recently released Ubuntu 22.04, are using unified cgroups(cgroup v2) . Howto enable fair share CPU scheduling in this environment is differentthan how it used to work with systemd using cgroup v1 . How this works currently on Ubuntu22.04 with systemd 249 is sufficiently 'clever' that it may wellchange in the future.

In cgroup v2, fair share CPU scheduling for a cgroup is


The basics of Linux fair share CPU scheduling in cgroup v2 ('unified cgroups')

Linux has long been able to do fair share CPU scheduling, where CPUtime was evenly divided between, for example, the various differentusers. Originally this took some manual work, but systemd woundup making it fairly easy . This is donethrough the Linux kernel 'cgroup' feature. This comes in two versions,the now-old cgroup (v1), and the not so new any more unifiedcgroups (cgroup v2) . Whenusing systemd, these turn out to be different in some important


Systemd memory limits and strict memory overcommit

We run some of our servers with strict overcommit handling fortotal virtual memory , which unfortunatelyperiodically causes us heartburn because an increasing number ofimportant things run as non-root users and so can't be protectedfrom overcommit . For instance, the SLURMcontrol daemon on our SLURM cluster's master node runs as the ' slurm ' user insteadof root, and so one day we had slurmctld die on us as the resultof the system being run into its overcommit memory limits.

(This was not an out


My wish for per-port IP access controls in systemd .service units

I tweeted :

I wish systemd offered a simple way to say 'only allow the followingIP ranges to connect to port X of this service'. You can allow onlysome IP ranges, but then that applies to outgoing connections too andthings like DNS queries done by the service.

[...]

There are lots of general Linux options to firewall access to a port,but AFAIK none of them are easily tied to a .service unit so that youalways get the two together and can't deploy


It's a bit risky to give people access to your Prometheus Blackbox exporter

A lot of the time you run the Prometheus Blackbox exporter on the same machineas Prometheus itself, so you can makeit listen only on 'localhost' and block outside people connectingto it. But suppose that you need to run Blackbox on a differentmachine, for example to give Prometheus visibility into a networksegment the Prometheus host can't normally reach. How potentiallyrisky is it if you leave Blackbox accessible to everyone on thenetwork? Unfortunately, the answer is that it's potentially somewhatrisky to do


Modal dialogs and other things that steal keyboard focus are dangerous

Over on Twitter I said some things :

Focus stealing dialogs are actively dangerous. An Ubuntu 22.04Cinnamon session flashed a dialog up for less than half a secondbecause I was in the process of typing, so it stole focus, stole mykeyboard input, decided to accept something, and disappeared.

What did I just do or agree to or accept or whatever in that desktopsession? I have no idea and no way to find out. I sure hope it wasn'timportant, damaging or


Stopping an Ubuntu 22.04 desktop from suspending at the login screen

We have a little Ubuntu desktop in our machine room to serve as ageneral access point for system administrators working there (anda machine where you can run a graphical web browser to go look atsomething, and so on). The other day we deployed a new version ofit, replacing the 18.04 version (on very old hardware) with a 22.04version (on not as old hardware). I was rather unhappy to discoverthat 20 minutes later, the desktop


Shell scripts should be written to be clear first

When writing shell scripts, there's often a general tendency towardsminimalism and what could be called ' code golfing '. After all, one of theimportant things for shell script performance is to run as few extracommands as possible . However, shell scriptshave another problem, which is that for various reasons the shellis not a great programming language (see parts of my entry on whylarge shell scripts have problems ). Inparticular, shell scripts often lack clarity because they have todo a lot of things