The “AI” hype these days is inescapable, particularly with Large Language Models (LLMs) that have impressive ability to create images, generate plausible text, and do everything from answering your tax questions to writing your code for you (of course when it comes to accuracy, caveat emptor)! There’s plenty of controversy about the training of these LLMs, discussed by wiser folks than me. People point out that 1) the training sets are often pure plagiarism, 2) the output of these systems reflect the biases of the training sets, and 3) the aforementioned accuracy problem. There are plenty of places to read about those concerns elsewhere.

Thing that has been bothering me about AI lately is that it is, structurally, something of a mediocrity machine.

To explain this, I first need to describe a particular type of person I’ve encountered numerous times in my career. I’ll do this by focusing on one former boss I had who best exemplified the character of what I call the “Idea Guy.” For the sake of anonymity and convenience I’ll call this prior boss “Steve.” In fact, I took the term “Idea Guy” from Steve, since that’s how he described himself and the captains of industry he admired.

Now, there are some industries and times where a single instance of great luck or skill can make you — for example, if you were an A&R person in the ’70s and you discovered a band that went platinum, or if you were a stock broker and bought a lot of Apple in 2016. In some ways, it’s not unlike betting on horse races. It’s very difficult to differentiate between skill and luck in these circumstances. If there’s repeat performance, and you repeat those successes, that might give some indication. But the world is a noisy, random place, and the conditions for these big wins are only rarely available, even highly skilled people don’t tend to have more than a few big wins.

In any case, Steve was a guy who had had one enormous win (and a string of smaller, less lauded failures which were always someone else’s fault), and was therefore utterly convinced of his own brilliance. He regularly had profound insights into what the world needed, and if he could only get people to implement his visions, he’d change the world. I was hired on as one of the people to implement these visions.

It was a peculiar job. One aspect of being an Idea Guy is that the details are beneath you. And if the details are beneath you, then the people who worried about details were also tremendously inferior to the people who had Ideas. Steve would regularly parade investors through the facility where I worked, and proudly wave his hand over my department. “These are my nerds,” he’d smirk. “They deal with the mundane part of things.”

Let me go on an aside about the “mundane” part for a moment. One of these projects involved a web-based calendar system. Steve had online events that he wanted to enter into the system which would appear to end users. He called me into his office one day to yell at me because one of his friends had looked at a prototype of the system and had been very critical. This friend was a designer who wanted everything to be super minimalist, so he told Steve that the registration form had too many fields: “It should only have three: name, email, and password.” Steve demanded to know why I required other details. I explained that we needed the user’s year of birth because events were age-restricted, and we needed their time zone so we could display the event time to them correctly¹.

Steve flew into a rage. “You nerds always make things so complicated! Get rid of everything but name, email, and password!” I tried to explain again but Steve wouldn’t listen. Eventually, he said “do it my way, or I’ll find someone else who will!” I ended up being reassigned to a different project, and the calendar task was assigned to “Kent²,” a junior programmer. Kent was bright, motivated, and very inexperienced. He came up with some complicated scheme based on a complete misunderstanding of how IP addresses work and the Internet Time Service, built it, and reported to Steve that it was done. Steve smugly announced to me that the problem had been solved — he just had to get “the right nerd on the job.” He pointedly said that if I didn’t learn to listen to him, I’d be replaced by more compliant coders.

The fact is, details matter. Needless to say, the deployment of the site was a disaster, and it wasn’t long before I left Steve’s company.

Most LLM programs are like that junior programmer, “Kent.” They come up with something that looks like a solution. You tell them what you want to solve, and they use pattern matching to find a solution that seems the most similar to problems like the one you’re describing. They don’t have any understanding of what’s going on. If the problem is close enough to one they’ve seen, the solution may well work. But if the problem is significantly different, or the way you describe it is different than other people have described it, you’ll get a solution that looks right … but probably isn’t. You can then correct the LLM, and it’ll apologize, and try again.

Like Kent, the LLM will generate something that looks like it will do what you tell it, whether it makes sense or not. If you’re like Steve, and have contempt for the people who get caught up in details, “AI” is perfect because it won’t argue with you. It’ll just go ahead and come up with something. The kicker is the more that what you’re doing is like stuff that’s been done before, the more likely it is the solution you’re given will work. To say that in a different way: the more original the idea or approach, the less likely the solution will work.

Now, in a lot of cases, the average is a good target. For basic building blocks, using a tried-and-true approach makes sense. A programmer shouldn’t reinvent sorting algorithms every time they want to sort something (which is why there are libraries). And a programmer probably shouldn’t ever invent an encryption algorithm.

Here’s where the Idea Guy jumps in and says “Yes, my brilliant original idea is the key, and the details are mundane so should be handled by nerds who know that sort of thing.” But this requires knowing how to break down the so-called brilliant original idea into the constituent mundane components in order to implement it. It requires understanding details like “I can’t present a time to someone correctly unless I know their time zone.”

Anyway, the more original and novel your idea, the less likely it is that the LLM will be able to put together the details correctly, and the more your idea resembles ideas that have been integrated into the training data, the more likely it is to succeed. So when you have the idea for the Next Great Thing, if your LLM can build it quickly and accurately, it probably means your idea isn’t very original. So you can probably get it to build your “Facebook but for pets” or “DoorDash, but for weed delivery,” but not for … well, I’d best not reveal The Greatest Idea Since Sliced Bread here.

¹This was in the days before you could reliably use JavaScript to detect time zone.

²Not even remotely his real name.

I keep some directories synchronized between my notebook and desktop with rsync. After upgrading my desktop to Mac OS 15.4.1, I started getting errors:

[sjg@BigThud 2025-04-21 13:01:05] ~/Documents/Backup
$ rsync -auP . sjg@10.3.2.xx:Documents/Backup
(sjg@10.3.2.xx) Password:
rsync: failed to set times on "/Users/sjg/Documents/Backup/Whatever": Operation not permitted (1)

Interestingly, ssh also showed an error:

[sjg@BigThud 2025-04-21 13:04:29] ~/Documents/Backup
$ ssh sjg@10.3.2.xx "ls /Users/sjg/Documents/Backup/Whatever"
(sjg@10.3.2.xx) Password:
ls: /Users/sjg/Documents/Backup/Whatever: Operation not permitted

On the desktop, I look again at Documents/Backup/Whatever, and the permissions are fine. What gives?

To make a long story short, something in the latest update on the desktop changed sshd‘s full disk access permission. Looking at System Preferences > Privacy & Security > Full Disk Access, sshd-keygen-wrapper was checked, so it should have been enabled. I tried toggling that, but it didn’t help.

Apparently, the sshd-keygen-wrapper was pointing at an old version or something? I had to go into System Preferences > General > Sharing and turn Remote Login off then on again, then go into System Preferences > Privacy & Security > Full Disk Access and re-enable sshd-keygen-wrapper.

Et voilà, I could ssh and rsync again!

I don’t want to use biometrics on my phone. There are a lot of reasons, most of them not very good for a nobody like me. Still, I like reading about OPSEC and thinking about it.

Biometrics are not revocable like a code. That may seem like a strange concern, but if, say, your fingerprint gets reproduced on the internet, there’s no way to prevent its abuse. People have 3D-printed fingers in gelatin with a captured image and gotten past phone fingerprint sensors. Many years ago when I was in the aerospace industry, we’d joke about the Russians “borrowing” your head if they wanted to get through the retina scanner at a secure facility. Again, do I have this kind of security requirements? No, but I still don’t want to use biometrics.

For the longest time, I couldn’t find the way to get Apple to honor my preference. I get a daily pop-up telling me to “finish setting up your phone.” Naturally, it pops up when I’m in the middle of a phone call and trying to do something with my calendar or something, and it gets in the way. Furthermore, it’s disrespectful. I don’t want to set up Face ID. Stop bugging me, Apple!

I used to be able to click into Preferences > Finish Setting Up Your iPhone and clicking the “Set up later…” button on each feature I didn’t want. Now there’s only an “Enable” feature. But it turns out that you can click the “Enable” and then “Cancel” when it asks for your passcode. This stops the nagging.

Apple has always thought they know best how you should be using their products. I’m finding it increasingly annoying. Why should each update turn on Apple Intelligence? I don’t want “AI” just as much as I don’t want biometrics.

I don’t want to go full Luddite, but maybe it’s time for me to start thinking more along the lines of a dumber phone.

A long PDF was to be printed, but only the text was important. As it was full of images, it seemed like removing the images would save a whole lot of ink.

It turns out ghostscript has some very nice filters for removing classes of content from a file. You can very simply remove text, images, or vector objects without changing the rest of the layout.

For example, to strip vector and images from a PDF, you can use:

gs -o text-only.pdf -sDEVICE=pdfwrite -dFILTERVECTOR -dFILTERIMAGE pdf-with-pictures.pdf

If you don’t have ghostscript installed but use Docker, there are containers that make it easy:

docker run --rm -v pwd:/app -w /app minidocks/ghostscript gs -o text-only.pdf -sDEVICE=pdfwrite -dFILTERVECTOR -dFILTERIMAGE pdf-with-pictures.pdf

The Department of Water and Power is doing work near the office, and over the weekend, there was a sustained power outage. I came in Monday to shrieking UPSes and had to power up the firewall and a few other machines. It was the normal stupid kind of stuff.

We have a few virtual servers out in “the cloud,” and we use point-to-point VPNs to make them seem local to our network. Those VPNs also needed restarting.

Through the course of the day, however, one VPN connection kept unceremoniously disconnecting. Looking at logs on the various servers was unenlightening. Everything was running normally, other than the surprise disconnects.

In the evenings, I’ve been watching the old Grenada TV/Jeremy Brett Sherlock Holmes series, so I had to apply Holmes’ deductive process. The virtual servers had experienced no changes except being disconnected, so I needed to focus on the firewall. The firewall had experienced no change, except being restarted. What could have happened?

I finally found a configuration that was incorrect (it was a netmask that was insufficiently restrictive, allowing devices not on the VPN to collide with VPN IP addresses). I fixed the netmask, and the VPN has been up and stable ever since.

But how could this be? It had been running properly literally for years. It had to be something to do with the power outage. But if that had corrupted the configuration, it wouldn’t have been a single IP netmask changing. “[W]hen you have eliminated the impossible, whatever remains, however improbable, must be the truth.” The bad configuration file could not have been in use.

The best theory is that the configuration file had been (accidentally?) modified at some point in the past, but never loaded. When the firewall was restarted, it loaded this modified configuration for the first time.