BREAKING NEWS: A new vulnerability has been discovered in all versions of PHP. Details will be forthcoming, but I’m told that, under certain unusual conditions, it will execute PHP code. This has numerous exploitable consequences, not least of which is that it leads to more PHP code in the world. The details are currently embargoed but the team responsible for discovering the vulnerability report that a similar class of problem exists in GCC and Clang as well.

If I read the Apollo analysis (the one that claimed that the Fortune 500 minus the Magnificent Seven are not seeing productivity gains from AI) it's actually slightly misleading. It's looking at per-employee productivity. For the Fortune 493, that's been flat, for the Magnificent 7 it's been increasing.

The first missing thing is that most of the M7's revenue comes from things with high switching costs. It's a very long trailing indicator of their actual output. They can fail to improve their products for a relatively long time and not see a decline in revenue, but for all of this time they become increasingly vulnerable to market disruption and someone suddenly taking a big chunk of their market share.

The second missing thing is that these companies, whose revenue is more-or --less guaranteed over the short term, have all done significant headcount reduction over the periods that they looked at, partly trimming ZIRP and COVID over-exuberant hiring, partly to free up cashflow for investing in datacentres and GPUs. Reducing the number of employees while keeping the output roughly constant will eventually cause a decline in revenue but, in the short term, will show more revenue per head: their metric.

Finally, those revenue numbers are propped up by setting cash on fire. A company that spends $100B on capex for things that fail after 3-5 years, and uses it to drive a $10B revenue increase will see a revenue-per-capita increase, but is not in any way a sustainable business model.

All of these mean that their metrics look much better for the M7 than their fundamentals would reflect. And those are the companies that they're saying are the only winners.

Given the EU’s push to simplify the GDPR to make compliance easier, I propose the following replacement text:

Nope.

With the following additional non-normative additional guidance:

No. Seriously, what’s wrong with you people? Why would you ever think anyone would consent to that. No. Just no.

For a discussion elsewhere, I did some back-of-the-envelope calculations about the relative performance of disks and CPUs since the early 2000s. The number of retired instructions per byte of random disk reads between an early 2000s machine and today has changed by at least four orders of magnitude (possibly six, depending on exactly what you're measuring).

I knew disks had become faster, but that's an enormous change. If you wrote something 25 years ago that was entirely disk-I/O-bound and used 5% of the CPU, running today it wouldn't even be close to 1% of disk bandwidth usage but would be pegging the core at 100%. Even making it multithreaded and getting a perfect linear speedup wouldn't have come close to 1% disk-bandwidth usage.

The delta is less pronounced for large sequential reads.

Is there a good solution for TLS certs for consumer LAN devices? My ISP’s router recently moved to requiring TLS, but I access it via it’s IP address and it doesn’t have a TLS cert for an IP address (is it even possible to get a TLS cert for a private IP address?) and so the main change is that my browser no longer autocompletes the admin password (for good reasons: don’t autocomplete passwords in TOS sessions with invalid certs!).

EDIT: Yes, I know of many ways I can solve this for my personal network. That’s not what I’m asking. How can a vendor that ships a device that is accessed only via a local network enable TLS, have some vaguely useful security guarantees, and not just add inconvenience for end users?

EDIT2: To more precisely state requirements: user buys device. Device is connected to network, where the local address might not be known in advance (and, for IPv6, almost certainly won’t be). User can connect to device using a name printed on the manual (for example, a name advertised via mDNS) that can be changed later. User does not need to configure any TLS anchors on their devices. User gets TLS connection to device with no warnings from the browser and autofill works. When user goes to a different network that happens to have the same model of device, they can tell the difference and the browser will not autofill their passwords and give them to a different device of the same class that may not be trustworthy.

Reminder to people who have international meetings: the next week is George W Bush Golfing Time. The USA and Europe had an agreement to move clocks at the same time, so the time difference remained constant. George W Bush decided he wanted a few weeks more golfing time, so unilaterally moved the USA’s Daylight Saving Time. This move remains in effect so there are a few weeks of annoying disruption each year.

I made the mistake of flying the first time this happened, which is how I knew about it: the airlines were unprepared and sold me tickets on two flights where the time change meant that my slightly tight 45-minute change turned into a -15 minute connection time (fortunately the second flight was on a route they flew every two hours so I was only an hour late)l

I am glad that leap seconds are gone, but also annoyed that they ever existed. Time zones are typically an hour wide, some places use the same time zone for geographic regions that span 2-3 1/24s of the Earth's rotation.

This means, simply as an artefact of not living exactly at the centre of a time zone region, the offset between high noon and clock noon is likely to be at least half an hour, possibly over an hour.

Leap seconds correct for the fact that this may have drifted an additional 1-2 seconds in a year. It's second level precision in a thing where the accuracy is measured in tens of minutes.

And that extra precision came with a huge amount of complexity that everyone had to deal with.

I just fixed a bug where someone had sent an LLM-generated fix. At first glance, the LLM fix was mostly right, except for a redundant atomic fence (LLMs seem to love __atomic_thread_fence in this codebase, no idea why).

But then I went to fix the bug. The problem was that a lock was initialised too late and so could end up being initialised twice. Ooops, locks are not meant to introduce concurrency problems!

And the LLM fix moved it earlier, so that's fine.

Except... there's another way that the object containing the lock might be reached via a global pointer and that didn't have any guards. I don't think it's possible to trigger the bug that way, but some of the future changes that I'd considered might introduce that as a path.

And there's no real reason for anyone to want the object without the initialised lock, so moving the initialisation to just before the point where any other thread might reach the object is a simple fix.

But that isn't what the LLM proposed. Instead, it fixed the immediate issue without any reference to the long-term impact and maintainability of the codebase.

My fix was a fairly simple change: one new line of code, four new lines of comment, and six deleted lines of code (so worth doing for code readability even if the bug hadn't been real). And even a change that small, if you accepted the LLM recommendation (three new lines of code, no new comments, and six deleted lines), would have made the code less maintainable and more subtly broken.

And that's why I refer to these things as Technical Debt as a Service.

One of our SaaS providers sent out a marketing email to all of their customers about new AI features. I replied saying that we used them as a secure solution and integrating things that add no value for our use case but add significant attack surface undermines our trust in their product and will cause us to consider alternatives.

It turns out that the reply-to header was the CEO’s email address and I initially got an out-of-office auto responder then a worried reply saying that of course the AI nonsense that they’d been talking about would be opt in and would not be given access to anything without explicit consent.

But now their CEO has one data point that jumping on the bandwagon will lose sales.

I’d recommend doing the same for any such marketing emails you get. The replies may go to /dev/null, but normally they have a ‘contact sales’ link. The more replies they get saying that incorporating ‘AI’ features undermines your trust in their product and makes you less likely to buy even the non-‘AI’ versions, the more they’ll consider these things high risk to ship.

It's so weird listening to humans speak a language I don't understand because my brain keeps trying to pattern match on languages I do (at least partially) understand. And occasionally goes something like 'aha, these syllables form words in German', only they're words that make no sense together and so then I get parse errors in the sentence. Or just one word, which is definitely not a word that they said.

Written Dutch is the same. Sentences that start out getting past the error-correction part of my brain as English or German with a few typos suddenly become total gibberish a half a dozen words in.

And I think Mastodon is messing with me, because I periodically see a post and think 'I understand most of the words in this, but what is this one in the middle that gives me the context?' and then hit translate and it translates every word except that one (charitably, it might be a proper noun, but I suspect it's the French being nefarious again with their sneaky words).

I am trying a new thing:

Only boosting posts that make me happy or have something actionable for readers. It's good to be informed about depressing issues, it's not good to be constantly bombarded with things about them.

Not posting about things that annoy me unless I have an actionable proposal for how to improve them. Grumbling can be cathartic but is not especially helpful.

I don't promise I'll be good at this, but I'm going to try!

One of the most useful things I learned working on open source was the ability to usefully cooperate with people who had different goals. Finding the place where our requirements overlap and the things that are necessary for both.

I think a lot of people in the F/OSS ecosystem try to have this mindset but there’s a big difference between working with people whose goals are different from yours and working with people whose goals are completely antithetical to yours. If I want to empower users and you want to kill immigrants and gay people, that isn’t a ‘well, we can at least agree the UI should be better’ situation, that’s a ‘there is no world in which we both get what we want’ situation.

It’s very important to make that distinction.

Orbital AI datacentres come with latency issues. If they're in LEO, they will have moderately low latency to a moving point on Earth, but for a fixed client the latency will increase as more relays are needed to account for curvature, so the jitter is high. If you put them in geostationary orbit, the latency is fixed, but large.

The solution to this is to put not just the AI datacentres, but also the AI bros in orbit. If you put an AI bro and a small radio in LEO, in the same orbital trajectory as an AI datacenter, they will have very low latency - indeed, significantly lower latency than ground-based routing if both they and the datacentre are on the ground.

Importantly, AI bros have a lot less mass than datacentres. As such, they are much cheaper to launch. As a pilot programme, to assess feasibility, I recommend launching a test constellation of AI bros into LEO. Note that, unlike datacentres, AI bros are made out of non-toxic (at least, in the chemical sense) substances. The environmental impact of uncontrolled atmospheric reentry is significantly lower, making the risk from the failure of a pilot deployment significantly lower.