Every complex problem is a dependency management problem.

The only robust solutions are the simplest things which can work, created by people who fully understand the problem and have to work with the system regularly.

But the fastest temporary fix for any specific problem is to add a complex layer without fixing the underlying problem.

And every layer reduces your ability to understand the problem.

Every complex solution is a dependency management problem.

-30-

I had assumed that when certbot does an http authentication of a domain name as part of getting Let’s Encrypt to issue or renew a cert, it would do so by touching the appropriately named file in http://domain.name.tld/.well-known/acme-challenge, waiting for the challenge to resolve, and then deleting it.

And sure, that’s what it does with --webroot. And I assumed that if you passed it --nginx, certbot would use that to look for the right config to parse to get the right domain to directory mapping, and then reload nginx afterwards.

It does not do that.

Instead, it inserts new config into nginx to just return a 200 success code for the challenge name as though it were a 0-length file on disk. Nothing hits disk in the .well-known directory.

It turns out that this can backfire in a number of very hard to debug ways.

So, if you are having an authentication problem with certbot, try passing --webroot and the appropriate -w directory.

And if you’re writing some bit of utility code, howzabout not being so clever. Do the expected things.

Hey academics!

Your papers, thesis, dissertation, project – whatever – is based on data, right? No data, nothing to talk about.

So every paper should have a data management section. It should be quite straightforward and easy to fill out, assuming that you were doing things well to begin with. (Hint: make it easy to fill out.)

• Data was stored prior to processing at this facility with the following access restrictions and encryption.

• Data was anonymized / is still live / was cleared by the IRB as not sensitive. Total data is X records.

• Data is archived at the university at this URL. Access is open / requires IRB clearance.

• Processing was done at these facilities. Intermediate results are archived / were securely deleted. Programs used were X (version), Y (version)… with the following licenses.

• No new code or configs were written for this dissertation / source code, executable artifacts and configs are archived at the university at this URL

-30-

Start with an Android phone with sufficient storage capability and a decent DAC/headphone amplifier. Built-in is great; otherwise, find something that works and doesn’t suck up too much power.

Add IEMs of choice, for less than $50, or cans that are reasonably efficient. It stops being so portable if you have 800g cans and a 500g battery-powered amp to drive them.

Install F-Droid, and use that to install Vanilla Music and RootlessJamesDSP.

Configure Vanilla Music to point to your music data.

Use ADB to enable RootlessJamesDSP (it needs 2-3 android system permissions).

Download convolution equalization for your IEMs or cans. https://autoeq.app is an acceptable and very convenient source. If Oratory1990 covers your equipment ( https://old.reddit.com/r/oratory1990/wiki/index/list_of_presets ) then choose that, first.

Apply in RootlessJamesDSP.

Enjoy.

-30-

When the Let’s Encrypt certbot says it failed and it was probably a firewall issue – yes, it’s probably a firewall issue. On your side. On port 80.

-30-

Specifically, a wiki which uses a non-database backend. I like Dokuwiki for this, but anything which basically saves in text files is fine.

(Why? Because you don’t need to bring up the database and/or fix the web server to grep for the page you need right now.) …

There is a new software technology. It has a bunch of boosters. There are some companies formed around the idea that they will make a lot of money by providing the technology. Then they go out and try to convince other people that they should use the technology – and by extension, pay them for it. If not them, then one of their competitors, but preferably them.

That’s marketing…

New paper: LLMs don’t do formal reasoning.

Well, of course.

LLMs don’t do informal reasoning, either.

Humans are great at pattern recognition. We even recognize faces in clouds and tree trunks. We recognize wheelbarrows, bears and crabs and archers in the stars. We make things that have meaning, and we communicate through speech and text and art.

LLMs are great pattern-generators. They are extremely well-tuned to make patterns that look like they might have meaning. A human trying to communicate may be bad at it, but they have an underlying model of the world that they are referencing and updating. An LLM is not trying to communicate anything. An LLM has a model of language, not a model of the world.

The map is not the territory. All models are wrong, but some are useful.

The situations in which it is reasonable to use an LLM are exactly the situations in which it is reasonable to roll some dice and use that to read the table of random monster encounters; to pull a card from an Oblique Strategies deck; to twirl the knobs on the synth and see if you can get a cool sound. In years past, you could type in a good list of keywords to Google and hit the I’m Feeling Lucky button.

Attempts to use LLMs for more than this fail. Often they do not fail in such an obvious way that the results are immediately discarded, which is where most of the danger resides.

-30-

The Linux kernel doesn’t consider routing to be a separate process, so it can eat lots of CPU capacity and still be at a load average of 0.

Load averages are calculated as the number of running and uninterruptible processes, sampled every 5 seconds, and then displayed as an exponentially decaying average, optionally per core (or SMT “core”). A process actively computing stuff is counted the same as a process that has an outstanding I/O request, which can be a source of excitement.

The act of routing packets (as opposed to working on a routing protocol exchange) is handled by the kernel, so it does not have a countable process identifier, so it does not count for load averages.

-30-

Self: you have managed to make some cert renewals dependent on IPv6 connectivity through to the main server. This is not bad, but it is odd.

-30-

Many organizations claim to be following Agile in some way. The vast majority are wrong, and most of them should not be Agile anyway.

You will recall that the Agile Manifesto, in total, is this set of four guidelines and an interpretation:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

That’s a recipe for making certain customers happy with your perpetual engagement. But:

Repeat the following metaphor until you internalize it:

Security is the skin of an organization, IT infrastructure is the bones.

Everything else is the digestive system or the nervous system. Breaking the skin is a bad idea. It needs to be done for certain specific reasons, but all of those holes need good defense systems including real-time sensors and reflexes. Repeatedly stressing parts makes them tired and calloused, not more flexible. Careful and deliberate exercise builds strength and flexibility.

If I had less integrity and more time I could spin this out into a 140 page business advice book.

-30-

There’s a game which you have probably played in some form, possibly not even knowing that it was a game. It goes like this: an author writes fiction, and the reader comes across an interesting element and asks how it works, in-universe.

And people come up with answers…

My RSI prevention strategy involves change: I use three different keyboards, four or five pointing devices, and move around to different places. On my main desktop, I mostly use a thumb trackball, with a mouse in second place and a drawing pad in distant third.

On Friday the trackball died in a peculiar way.

I have almost 30 years of professional experience as a sysadmin.

Failure is inevitable. Hardware will fail, software will be discovered to have flaws, reconfiguration will be mistaken.

The antidote is to have reliable recovery mechanisms: everything will eventually break or need to be changed, so in turn you need to be able to recover back to a stable position, so you can try again.

Recovery mechanisms are not all-purpose. I usually describe them in three phases: