Created this for a reply on LinkedIn, but it applies pretty generally, so posting it here, too:

I don't know who needs to hear this, but reminder that µ is not a fancy u, but a fancy m

This one will hurt: I love 1Password as a product. But I'm the son of a concentration camp survivor. I will not give money to companies that align themselves with nationalism, and certainly not ethnic cleansing. Completely disappointing, @1password. https://www.flyingpenguin.com/dhh-nazism-funded-by-1password-vp-who-wrote-honest-security/

People: Sara, why did you retire from Software Eng in your 40s?

Me: Gestures at this absolutely perfect encapsulation...

"I’m European. The whole continent is assumed to have a Google and a Meta account.

This is frightening. We are putting all our eggs in the same basket. And our milk, our water, our house, our furniture and our loved ones. In an electrical-auto-closing basket remotely controlled by a foreign entity that openly spies on us and wants to extract as much money as they can. For some reason, it is considered weird not to like the basket."

https://ploum.net/2026-09-02-i_dont_have_a_smartphone.html

I mean, find me a single American tech organisation that *isn’t* full of right wing libertarians.

That’s the secret lurking in open source - it’s actually a weird combo of gun-toting anti-government survivalists and radical progressives* who have managed for years to share some similar goals because politics wasn’t mentioned. But then software ate the world; software *is* politics, and vice versa.

* (I’m in the second camp, I’m sure the first camp would use different words for me.)

the AI was a grandmaster chess player until it being horrible at chess became a meme

the AI is an incredible mathematician in countless breathless papers but every time you ask it a basic math question it fucks it up badly

the AI is just a tool until you refuse to use it, then it’s a revolution and we can’t afford to be left behind and using it is required

the AI is an incredible boon to open source, as it fractures communities and generates unsalvageably bad code in quantities so massive it can’t realistically be cleaned up

the AI will set you free, but your access to it is gated by a gigantic corporation that’s losing money at every realistic price point they can charge for the thing

the AI is loved by most people until you look at literally any of the polls we’ve done asking people what they think of AI

boost this poost if you support a unionized wikipedia

I don’t have a smartphone…
…or, at least, I wish I didn’t.

https://ploum.net/2026-09-02-i_dont_have_a_smartphone.html

Resonance

Bonus speedpaint: https://www.peppercarrot.com/en/miniFantasyTheater/068.html#bonus

#webcomic #krita #miniFantasyTheater

RE: https://beige.party/@gildilinie/117182364841041560

This is really key for a lot of ‘AI’ success stories. The baseline is always not trying a thing. It’s never trying a different technique and allocating the same amount of compute power specialised for the task to it.

Vulnerability discovery is like this. We currently limit static analysers for C/C++ to a single compilation unit because the memory and CPU requirements for that work on a laptop or cheap cloud VM, whereas doing cross-compilation-unit analysis can require hundreds of GiBs of RAM and many hours of CPU time. Yet, when people are talking about the LLMs doing vulnerability discovery, they’re comparing against the run-on-a-cheap-laptop version, not the costs-as-much-to-run-as-LLM-inference model.

If you were willing to throw a huge amount of compute at static analysis, then generate coverage points for the paths in the predicted bug and use guided fuzzing techniques to create a reduced test case, I suspect you’d get higher success rates than LLM-based approaches. But VCs are willing to throw tens of thousands of dollars of compute per bug at the LLM approach because it makes the companies that they’ve invested in look good.

New article: this time, we use Heidegger to explain why the "it's just a tool" line that often comes up in tech is so very silly:

https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool

"With blockchain we shot ourselves in the foot. With AI we're aiming higher."

@casandro @whitequark

I thought we'd have stopped arguing about CPU instruction sets when microarchitectures kinda made them unimportant and even x86 became as fast as its competitors.

Article-length version of this post.

We absolutely haven't. There are a lot of things in an architecture that bias it towards easy or difficult implementations with different microarchitectures.

The memory model on x86 was never really designed. The original 8086 had no caches and could overwrite the next instruction that followed it. That's simple to implement on an in-order microarchitecture with no caches. And software depended on this behaviour. TSO with instruction caches being coherent with data caches imposes a whole bunch of issues. The clearest example we have of the performance impact of TSO is from Apple's chips, because they were designed both to run native code (Arm's weak memory model) and emulated x86 code. They have an option that automatically makes every load into a load-acquire and every store into a store-release, which gives the same effect as the TSO bits. Turning this on gives about a 7% performance hit. They don't bother to try to emulate the instruction-cache consistency in hardware, Rosetta just makes every page containing code read-only and hits (very) slow paths for stores to them. Modern x86 does something similar: stores anywhere in the speculation window flush the pipeline and make everything slow (on a recent Xeon, you can still do a store over the next instruction to do a conditional jump but don't if you care at all about performance).

There's a lot more in x86 that makes it hard to scale. The decoder complexity is legendary. You can avoid much performance cost here by caching decoded micro-ops, but that then costs power for the extra caches.

Given enough money, you can make any ISA fast, but you can't make it both fast and power efficient. Hardware people talk about PPA: power, performance and area are all axes in a trade-off space. But the reachable points in that space depend on the ISA.

The observation that led to RISC was that (on fairly simple in-order pipelined processors in the '80s), the decoder was an enormous part of the total area. CISC chips were spending over 20% of their total area on a decoder. This happened at about the same time as the transition from mostly running hand-written assembly code to mostly running compiled code. Compilers had smallish instruction-selection windows (tree matching engines) and so largely ignored the complex instructions. Most of these were microcoded anyway, so these chips had big microcode engines and RAM (or even RAM!). Removing all of this meant more area to dedicate to functional units.

Microcode got more annoying with superscalar architectures because you want to dispatch a bunch of micro-ops, but now the places where you can take interrupts are more complex. A lot of non-x86 systems that have microcode for infrequent operations basically just stop the pipeline and issue microcode in-order. x86 used to do that too, but it turns out there are too many useful microcoded x86 instructions.

On a high-end microarchitecture, register rename is one of the hottest parts of the chip. At each point in speculation, you're tracking which of a large set of physical registers corresponds to each architectural register. This is closely related to instruction scheduling. Between the two, there's a huge (power / area) cost for executing any instruction, independent of how much work the instruction does.

This means some of x86's early disadvantage in terms of decoder complexity is often offset by doing more work per instruction. Not fully, but it's less of a disadvantage than it was. Doing more work per instruction is the goal if you want a good ISA for superscalar out-of-order pipelines.

To give a simple example, both AArch64 and x86-64 have fairly rich addressing modes. A load or store instruction in each may be equivalent to a short arithmetic sequence followed by a load or store in a purist RISC architecture. And those arithmetic operations each need scheduling and need rename registers allocating for the temporaries.

Krste's answer to all of this is 'micro-op fusion!'. If the compiler generates a sequence of a compressed add / multiple / shift / whatever followed by a load that clobbers the architectural register into a single micro-op that does some arithmetic. Only now you've got a per-implementation ad-hoc variable-length instruction encoding. The compiler needs to know to emit the instruction sequences that get optimised but your decode stage is almost more complex because it has to handle spotting pairs of instructions that can be folded. x86 does this, but no one notices the cost because the x86 front end is already ludicrously complex. For a fixed-length instruction-set front end, it's a big overhead.

Oh, and it doesn't actually solve the problem. Loads can fault. If they do, you are required by the architecture to have the values in the registers from before the load. And that means that you either need to allocate a rename register for the intermediate (you know, the thing you were trying to avoid), or you need to track the corresponding architectural register so that the load/store unit can write back the temporary value if it faults. All of that consumes power and area to achieve the same performance that a richer addressing mode in an instruction could do.

RISC-V makes it hard to add additional instructions because they've burned so much encoding space on things that aren't that helpful for complex microarchitectures. The C extension uses a huge amount of the 16-bit encoding space and is 100% duplication: every C instruction was designed to be expanded to an equivalent I instruction, so this is pure redundancy. If you design this in from the start, you can remove those cases from the 32-bit encodings and free up more space there.

The JAL instruction in RISC-V is enormous for the sole reason of avoiding marking the link register architectural for purity reasons. Except that, if you want a branch predictor that isn't terrible, you need to treat it as architectural. So it has a full 5-bit link-register field. This gives it 26 bits of operand space where any other RISC encoding (which just uses one bit to discriminate between jump and jump-and-link cases) would need 22 for the same instruction. With 26 bits of operand space, it's an entire major opcode: 1/128 of the total encoding space for 32-bit instructions. Actually more, because the RISC-V encoding requires two bits to have fixed values for 32-bit instructions, so it's 1/32 of the entire available 32-bit encoding space. For a single instruction.

To put this in perspective, AArch64 uses about as big a proportion of its encoding space for all memory instructions with all of its rich addressing modes as RISC-V uses for JAL.

I like to pick on x86's encoding because the long encodings are ludicrous but the shorter ones are actually not terrible. Most instructions are two-operand destructive operations. Compilers are really good at generating those now (in part because x86 performance is really bad if they aren't). In some measurement we did when we were designing a custom ISA at Microsoft, we found that around 2/3 of instructions had exactly one use of the result (around 2/3 of instructions were used only in the same basic block as well, but annoyingly not the same 2/3). Almost all of these can use two-operand encodings, which can be a huge space saving. If you disassemble an x86 binary, you might be surprised at the number of 16-bit instructions.

#FediHelp Does anyone have experience with Copenhagen public transport? I have questions ... (among other things I have trouble installing the app -- for Rejsebillet the SMS never came and for Rejsekort the app complains that I am offline when I am not, but I am not on Danish soil yet either so I am wondering if that is the problem)

This is both brilliant and absolutely cursed: https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database

Can't decide if my excitement about Canvas in #emacs is irrational or entirely rational. https://monadicsheep.org/blog/an-introduction-to-canvas-in-emacs.html

“A Technology of Unlearning”

https://2ndbreakfast.audreywatters.com/a-technology-of-unlearning/

> Rather, this “unlearning” of “AI” involves cognitive surrender and cognitive atrophy. It involves dependence and perhaps even (if you accept this medical and moral framework) addiction. It involves the monopolistic control and, so damningly, the erasure of knowledges.

new blog post!
https://lina.sh/blog/hijacking-e164-arpa
i hijacked some telephone infrastructure of a few islands over the span of multiple months; and accidentally logged information of a few hundreds of thousands of phone calls going to military bases in the process..

it's a really really silly story :P

I don't understand why Tiramisu isn't considered the ideal breakfast.

It has caffeine, sugar, and fat to give you energy for the day and a touch of booze to numb how stupid reality really is right now.