Latest Posts (20 found)

Verifying (simple) C in Isabelle/HOL with AutoCorres

This post details the first steps of verifying a C function in Isabelle/HOL using AutoCorres. It'll go over the basic setup for Isabelle and AutoCorres, what AutoCorres gives you, and how we can verify some basic properties of a function (here, the sum of a list.) I use the latest versions of Isabelle and AutoCorres available at time of writing (24/08/26). This is not official documentation for AutoCorres, nor may it be 100% correct in all places. All the proofs go through, but I do not work on AutoCorres, nor have I used it professionally; most of my experience is hobby verification. However, I have found resources on it are woefully lacking, so I wished to introduce some more. Much of this information has been gleaned from the official documentation (which can be found at the aforementioned,) and this course . When it runs, the slides/similar may be removed for some time - they exist on the internet archive also. This article assumes a little either Isabelle/HOL or general verification knowledge, but I try to explain wherever feasible. A bit of C knowledge is required as well, and so is a little knowledge about program verification - a little Hoare logic, and the like. I'll try to explain as much as I can without being excessively verbose, and much of it is very searchable. You can find Isabelle here . Install as is appropriate for your platform. You can decide whether to put in your path or not. First, pick a directory for your project. It may be feasible to use AutoCorres globally, but I wouldn't recommend it for versioning reasons. Then, AutoCorres can be found by scrolling down here . (It will probably take you here , whereupon you should scroll down to the latest AutoCorres release). You only need the AutoCorres download, as it bundles the C parser. Take that file, and extract it in your directory of choice. Then we need to build AutoCorres. From the directory where you unpacked it, run This'll take a second. Replace paths as appropriate. Note that is not the architecture you are on - it determines how the tool translates various C sizes into Isabelle. This will need to be the same architecture you launch with later. There are some others, and on a related note: It may not all make sense yet, but it may answer some questions. I recommend making a little shell script for this step ( perhaps.) You'll need to invoke Isabelle in a manner similar to the following: Remember that needs to be the same as earlier. Now that we have Isabelle running, we can use AutoCorres to generate Isabelle versions of C files. The manner in which this is performed is long, complex, and interesting - I recommend a rabbit hole evening - but in short, the C parser first translates it to a deep embedding in a language called Simpl, and then AutoCorres takes this Simpl representation and turns it into a monadic shallow embedding best it can. Here's what we'll be verifying today: The use of unsigned will be expanded on later. We'll put it in a C file named . At this point, your directory should look something like or similar. Begin a regular Isabelle theory, importing AutoCorres (and whatever else you want): We then need to let AutoCorres perform its magic. First, we "install" the C file with the C parser: You can use to see what this defines. Of particular interest is . Then, AutoCorres: The idea the C parser and AutoCorres use for verifying C is that it is reasonable to do a very direct translation of C to Simpl, and then a refinement to the monadic representation. The C parser is correct through inspection, and extensive testing. However, the translation of Simpl to the monadic form is verified - there exist Isabelle-checkable proofs that show that the monadic representation, however different it may be, behaves identically to the Simpl equivalent. This makes the monadic form a refinement of Simpl, and is why the things we prove about the monadic forms translate back down to C. This might also take a second. We choose to use . This makes unsigned integers perform modular arithmetic instead of using overflow checks; this has positives and negatives. Read the README for more. Again, you can use to see what this gives you. Of particular interest is . This is the monadic embedding of our function. We then need to enter the locale (think of it as an environment) defined by the C parser and AutoCorres, so your file should look something like: We do our work in this locale. If you haven't already, and . The former is the deep embedding produced by the C parser, and the latter is the result of AutoCorres's shallow embedding. These can be unfolded with and respectively. You can examine the types of things with ctrl-hover (cmd-hover on Macs.) Also examine . The type for the monadic state used by AutoCorres is called (You may see it displayed as in some places.) It's a record containing fields for each type of pointer used; ours only uses , so it only contains information for 32 bit words. We can examine the extract and update functions used in with and . Which monad AutoCorres chooses to embed a function into depends on the function, and can also be configured. This function is simple enough that it can be encoded with purely , but others include , (option with state,) and . Yes, this is a reasonable question to ask. What does it actually mean to verify this function? Generally, there are a few reasons to verify something: We'll look at all three. The not failing example will go into quite a lot of depth, whereas the correctness example will go into much less, only covering broad strokes. This is because the proofs are quite similar, and if you find the former excessively verbose, you might want to skip to the latter. Let's consider what we need for this function to not fail in C. The obvious constraint is that must be defined for all . Using , we can state this as a definition: Now we have our suitable precondition, let's set up our "doesn't fail" lemma. We expect that: We can state this using the combinator . The NF stands for , and it adds the additional condition that our program does not fail in some way during execution. Precisely what we want! It takes three arguments: The arguments are: Here, is used because of the choice of state monad AutoCorres makes. Note that our postcondition takes both the state and the return value . When we use with , will be our state . So, our lemma then becomes: If we have our list defined properly and some property Q, and we run our program, then it does not fail and Q is still true. If you're familiar with Hoare logic, you'll know we probably want to use some sort of weakest precondition reasoning. A weakest precondition is roughly "what is the smallest amount of information we need to know for this to be true", which allows us to simplify our proof obligations. Indeed, AutoCorres provides us with a family of tactics such as and . However, I find it nice to start these proofs by unfolding the function at hand, and applying or similar to get some simplification going. Then we can apply to apply relevant weakest precondition rules automatically. This should leave you with a state something like: I highly recommend using the Query tab of jedit throughout (or equivalents like .) will come in handy, and it's a nice fuzzy search. will do what's on the tin, and will find theorems that could apply. As we have a while-loop, a reasonable step is to add an invariant. An invariant is something that is invariant over the loop - it is always true, at the top of every loop cycle, and right after the loop finishes. This is how we conclude things about what a loop does. Indeed, we can see a theorem of use: Most of the time, the prefixes can be omitted. So first, we add an invariant, and then we can use to transform our into theorems we can work with. The invariants we care about right now are: We also care that this loop terminates, so let's add a suitable measure. is our invariant, and is the termination measure for the loop. Note the type conversion in . Then, again: This'll probably give you a few more normal looking goals. can come in handy again to chunk these down. This leaves me with: The first we talked about earlier - we can solve it by unfolding via , and basic reasoning. For the second, it seems obvious - why hasn't solved it? (If it were on s, it certainly would have.) Alas, it's on s, which as we have chosen to use modular arithmetic, are slightly less nice. It's hard to search for theorems involving as it's so overloaded, but luckily here finds . The final goal is more interesting. The initial intuition might be to use again, but this leaves us with nasty metavariables because of the chaining nature of the binds, and the fact that AutoCorres here is slightly too general. With a little searching we have the following: But we only really need to be identical to . We could instantiate manually each time, or we can make a little helper lemma (which I will do.) Above this lemma, we add Then we can apply twice (There are two binds.) We hence have: It's finally time to start unfolding the definition of so we can crunch down these last few goals. If we hit the first goal with: we're left with which takes out nicely. Tip: I fiddled with this for a bit manually, but if it looks fiddly and obvious, there's a good chance sledgehammer can do it. Finally, the last two are easy: We have a proof of non-failure! This is very exciting. The final proof is as follows: Then, what does it mean for our function to be correct? Well, a reasonable definition is that it produces the output we expect. We then need to figure out what "output we expect" means. We could have also defined the sum of a list as similar to the following recursive function: Note that we explicitly check for 0 to ensure the recursion terminates (We can't pattern match on 0/Suc, as we're working with s.). Unfortunately, this function's termination can't be proven automatically due to the use of a , which Isabelle isn't as good with as its own s. This is why we use a instead of , and we must do the termination proof ourselves: We also delete from the default simp set because it seems to cause some solvers to loop. We can set up our lemma like before, but this time, we use the parameter: We want the result to be equivalent to summing the entire list with our recursive function. We also don't bother to prove that it doesn't fail here. We can begin as before, omitting the step. We then need to annotate with a suitable invariant. A hint: We want the sum at the end to be correct, so a good invariant should capture correctness at every step , which gives us full correctness when the loop finishes. We have to manually a few times as we deleted it from the simp set, but otherwise the proof is very straightforward. Mine came out to be: We could take this one step further if we wanted, and define a bijection between and assuming our precondition, and then also show that our own spec is equivalent to the sum of that list. That'd give us even more confidence our function is correct. I'm personally pretty convinced, but you're welcome to try this yourself! We could then finally prove that if some property is true for the sum of a list, it's true for the result of our program. I won't detail this one; it should follow reasonably easily from the former two. So, what have we (hopefully) learnt? I hope this has been informative! (With less fixing of indentation for the web, sorry): A bit underwhelming for how long it took to explain, perhaps! To prove it never "fails" (what failing means is another question) To prove it produces some desired output To prove it holds some desired property is a , as perhaps expected. has been converted into a . is our state for the function, and carries information as mentioned about the heap. We use the perhaps confusing for pointer addition. You can write this in jedit with . We also need an explicit type conversion , as you can add negatives to a pointer, so the argument is an (this is not unsigned int; that's . here corresponds to Isabelle , which is signed.) If: The list is defined properly Some other property Q is true Then: Our function does return successfully, so That property is still true. A precondition function. A computation function. A postcondition function. (for termination) (for no-failure) (for simplified correctness) How to install and setup Isabelle and AutoCorres What it means to prove things about programs How to set up appropriate proofs How to prove them What tools we have available and how we can search for more

0 views
Unsung Today

Let me walk around

A perfect example of breaking the “let me click” slash “the current action has the most momentum” principles we just talked about , in macOS Settings. When you try to add a new keyboard layout, the layouts you already have added are completely disabled, not just from addition, but even from selection : On a surface this seems useful, right? A good signal to help you understand what you’ve already done? But this implementation also makes it unable to compare layouts of keyboards you have installed with the layouts you have not, since they previews are now in two different places. And this is important, as the differences between those layouts can be tiny, but significant. This breaks momentum, and in the process also makes it hard to establish a good map of the entire space, since you are not allowed to walk around it freely. A tactical solution seems to be relatively standard at this point – disable the Add button instead, and indicate the already-added layouts in some other way. Unrelated, but also – this popup-on-a-popup reminded me of this glorious old tram bezel city I’ve seen in Melbourne: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/let-me-walk-around/3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/let-me-walk-around/3.1600w.avif" type="image/avif"> #flow #interface design #mac os #preview

0 views

Apple Updates Mini and Studio, AI Computers, OpenAI Jalapeño

Apple and OpenAI have two completely different hardware announcements; both represent pressure on Nvidia.

0 views
Farid Zakaria Yesterday

Stamping build info in constant memory

This is a fun little trick I came across at . I did not invent it, but I thought it was interesting enough to understand better and share. At we build with buck2 and we stamp our executables with build information: build-id, timestamp, author, the usual suspects using as a step after the link. The reason it is a separate step is caching. If the build info was generated at link time then everytime we link the binary it would produce different bytes causing it to not be bit-reproducible. When something is bit-reproducible, it is safe to cache it, and the build system can apply early cut-off optimizations. That works, until the binaries get big. We noticed that ’s memory use scales with the size of the file it is stamping. Stamping is exactly the kind of step that runs massively parallel at the end of a build so this can cause a lot of memory pressure. Why is the stamping step reading the binary at all? 🤔 Let’s measure the claim that the memory use of scales with the size of the file. We will attach a JSON build info blob to an increasingly large synthetic executable and measure the peak RSS of the stamping step. The graph confirms the claim. The memory use of scales linearly with the size of the file being stamped. Surprisingly, the slope is two . The peak RSS is roughly twice the size of the file being stamped irrespective of the size of the build info being attached. 1 I am helping to shepherd a PR open against LLVM to stream the ELF output rather than materialize it, which roughly halves the peak. That is a definite improvement but the problem remains that in order to add a tiny section to a large binary, the whole binary has to be read into memory. The memory use is still linear in the size of the file. The problem is not poor implementation on the part of . Adding a section to an ELF touches three separate things: 0x78 bytes in .interp\0 .buildinfo\0 .rela… 0x70 0x78 0x83 the section's bytes 88 bytes of JSON, at 0x401021 The entry holds neither the name nor the bytes. It only refers to them — and only one of those two references can be repointed in place. In order to account for the new section, the section header table has to grow by one entry, and has to grow by the length of the new name. The current model for is to read the whole file into memory, add the new section, and write the whole file back out. That is why the memory use scales with the size of the file. How can we avoid having to rebuild the whole file just to add a tiny section? The trick is to pay the cost at link time rather than at stamp time. We can have the linker emit a placeholder section with the right name and a single byte of content. The section header table entry is already there, and the name is already in . The post-link stamping step can then append the payload to the end of the file and update the section header entry to point to it. 💡 We make linker emit the section during the normal build. It does not need to hold anything; it just needs to exist so that it owns a name and a header. Our “stamp” step is now incredibly simple. It does not need to read the file at all, it just needs to write the new payload and update the section header entry. Nothing that already exists moves. does not move, the section header table does not move, no other changes. The edit is sixteen bytes , at a file offset you can compute from the ELF header, plus a . read into a model, serialized again — 1,238 bytes of it actually differ reserve one byte, then append 16 bytes + a tail ehdr phdrs .text .rodata … .shstrtab section headers payload the reserved byte sh_offset, sh_size Note Why 1 byte? Turns out that and GNU disagree on whether an empty section is a valid ELF. The one byte is a cheap way to make both linkers happy. The payload lands after the section header table, which looks alarming the first time you see it but is completely legal. Nothing in ELF says section contents must precede the section header table. The kernel also never looks at section headers also, it loads segments out of the program headers, which we do not touch. I wrote a small C version to benchmark it in contrast, please be mindful that this graph is log-log. Our trick works! The “append + 16 bytes” approach is constant memory. Not only is the peak RSS constant, but the wall time is also constant and much faster by avoiding the read and write of the whole file. It is often easy to reach for general-purpose tools like as they are a swiss-army knife for manipulating object files. What I like about this trick though is that there are meaningful improvements to be made by writing special purpose tools and that does not mean we have to accrue large maintenance costs. In this case it was a tiny 200-line C program. The economics of these tools is also changing with the rise of LLMs in our workflow. While many are concerned about the influx of generated code, I remain optimistic that we we can use them to find such opportunities. Don’t be afraid to write a small tool to solve a specific problem. For those thinking this is an LLVM specific issue, GNU exhibits the same behavior.  ↩ the section’s bytes , somewhere in the file a 64-byte entry in the section header table describing where those bytes are the section’s name , which is not in the entry itself but rather the entry holds a offset into , so the name has to be appended to that string table 0x70 0x78 0x83 the section's bytes 88 bytes of JSON, at 0x401021 The entry holds neither the name nor the bytes. It only refers to them — and only one of those two references can be repointed in place. In order to account for the new section, the section header table has to grow by one entry, and has to grow by the length of the new name. The current model for is to read the whole file into memory, add the new section, and write the whole file back out. That is why the memory use scales with the size of the file. Pay the byte at link time How can we avoid having to rebuild the whole file just to add a tiny section? The trick is to pay the cost at link time rather than at stamp time. We can have the linker emit a placeholder section with the right name and a single byte of content. The section header table entry is already there, and the name is already in . The post-link stamping step can then append the payload to the end of the file and update the section header entry to point to it. 💡 We make linker emit the section during the normal build. It does not need to hold anything; it just needs to exist so that it owns a name and a header. Our “stamp” step is now incredibly simple. It does not need to read the file at all, it just needs to write the new payload and update the section header entry. append the payload to the end of the file write the new and into the placeholder’s section header entry the reserved byte sh_offset, sh_size Note Why 1 byte? Turns out that and GNU disagree on whether an empty section is a valid ELF. The one byte is a cheap way to make both linkers happy. The payload lands after the section header table, which looks alarming the first time you see it but is completely legal. Nothing in ELF says section contents must precede the section header table. The kernel also never looks at section headers also, it loads segments out of the program headers, which we do not touch. Benchmark I wrote a small C version to benchmark it in contrast, please be mindful that this graph is log-log. elfstamp.c Our trick works! The “append + 16 bytes” approach is constant memory. Not only is the peak RSS constant, but the wall time is also constant and much faster by avoiding the read and write of the whole file. One trick pony It is often easy to reach for general-purpose tools like as they are a swiss-army knife for manipulating object files. What I like about this trick though is that there are meaningful improvements to be made by writing special purpose tools and that does not mean we have to accrue large maintenance costs. In this case it was a tiny 200-line C program. The economics of these tools is also changing with the rise of LLMs in our workflow. While many are concerned about the influx of generated code, I remain optimistic that we we can use them to find such opportunities. Don’t be afraid to write a small tool to solve a specific problem. For those thinking this is an LLVM specific issue, GNU exhibits the same behavior.  ↩

0 views
Xe Iaso Yesterday

How to make VS Code go back to the old UI

Someone on the VS Code team decided to do a redesign of the product. This makes VS Code look like this: A picture of the VS Code UI that has a design I don't like. This design is fine, I guess? It's got some rounded corners that look nice, I guess, but I really just want it to look like what I'm used to. I can tolerate this kind of redesign in my chat app, but I use VS Code professionally and kinda want things to look the same so I don't have to think as much. You can revert the design change by setting in your settings.json. Then it looks like this: A picture of the VS Code UI that has the design I'm used to. Who knows how long this is going to last, but at the very least it should work for now. Thanks to jtagcat and Hugo ARNAL for letting me know about this setting.

0 views
Xe Iaso Yesterday

If your VS Code remotes stopped working, downgrade to v1.124.x

Today I woke up and saw a brand new VS Code error when I remoted into my coding box: A VS Code error saying that the remote SSH extension can't use the API terminalRemoteResolver and that I have to start VS Code with some weird command line flag or something. Trying to update my extensions didn't work. I still got that error. The only thing that worked was to downgrade to VS Code v1.124.2. This also undid the redesign that I kinda hate. The VS Code UI drafting an early version of this post. Obviously keeping things at this older version of VS Code is not a viable strategy, so maybe this issue will actually be fixed instead of just being closed for no reason. Quality software reigns again!

0 views
Giles's blog Yesterday

Adding diagrams to my static site generator with D2

A lot of the time when I've been writing posts for this blog, I've felt that a diagram would really help. But they're a pain to produce well, and I think I underuse them as a result. I wanted to fix that, and wound up adding D2 support to my static site generator. I think it works pretty well! In the past, I've tried drawing my own diagrams in LibreOffice and exporting as SVG, but my complete lack of artistic skill doesn't help: Asking an AI to do it for me helped in simple cases: ...but with something less standard (there must be a million neural network diagrams in their training sets) it can be really fiddly to get something right. I did some investigations into the various diagram-generating tools out there, and decided to give D2 a go. It has a simple language for specifying what your diagram should show, and the output is pretty nice: Here's the source for that diagram: That looks pretty clear to me! So now, in the source for my blog posts, I have a directory. That contains subdirectories -- by convention, I create one for each post that needs diagrams -- and D2 files. These can be generated automatically when I publish: (Hat tip to Evan Hahn for the method on , which I wasn't aware of.) The flags on the command line took a little bit of fiddling; the just gets rid of the large margins that D2 puts around the diagram by default, but the others are to tell it to use the ELK layout package with particular formatting. Its default layout has curvy lines, and I prefer the closer-to-right-angle ones that ELK provides. Another awkward bit was in scaling; the file that is generated by that command comes out pretty large ( you can see it full-size here ). By default, I allow images inlined into my posts to be as wide as the text, but that would still be too large here. I use to convert the markdown source for my posts into HTML, and there isn't any way to tell it what size an image should be using markdown-ish syntax. So for now, instead of embedding images the normal markdown way, like this: ...for these D2-generated ones I'll just embed a normal tag like this: ...so that I can control the size. Perhaps more work needed there. At some point I may go back and update my old diagrams -- at least, the really ugly hand-drawn ones -- to use this. And a random thought: perhaps it might also make sense to include the D2 source somehow on the blog? I can imagine that it could help with accessibility in some situations, and perhaps also for any LLMs stopping by. Will have to ponder that a bit more. What do you think? Does the D2 diagram look good to you? Or is there a better diagramming package that might work better?

0 views
Jeff Geerling Yesterday

Debugging Ubiquiti's 5G Backup on AT&T

For a mobile 'mini homelab' project I'm working on, I wanted to use 5G Internet as a primary 'on-to-go' connection, but still have the ability to plug in another Internet connection when I put the mobile rack I'm building in a fixed location. I'll have more on that project soon, but I figured this project was a good way to check out Ubiquiti's solutions, especially considering many of their smaller gear fits nicely within the dimensions of a mini rack (the 3U DeskPi RackMate TT is pictured above).

0 views
Jim Nielsen Yesterday

Have You Heard the Good News About Microlighter?

Dave Rupert wrote about shipping microlighter : a tool for handling syntax highlighting using the CSS Custom Highlights API . I saw his post the day he released it, and I had an implementation PR up for my blog by end of day. Then, like I do with so many things, I let it sit there. This is the period where my subconscious takes over. It does the work of, “How do I actually feel about that? Do I want to merge it? Do I have any regrets about what I did?” If I still want to merge it after a few days, that’s usually a good sign that I’ll be happy with the work. (Sometimes after a few days I say, “What the hell was I thinking?” and then it’s easy to simply close the PR with zero regrets.) Well it’s a few days later and I still feel good about it, so time to ship! My PR for this is pretty straightforward: Granted, there are trade-offs to this approach. I get it. Dave’s explainer for this tool on The ShopTalk Show vibed with me because I’ve been in his shoes many times: “Whoops, somehow syntax highlighting on my blog is broken again. Guess I need to fix it. Ugh. I’ve done prism , I’ve done highlight.js , I’ve done shiki . What should I do this time? Could I do this in a way that’s just less ?” He clarifies: I’m not coming at this like, “Everyone is doing it wrong!” I was just kind of like, “Could I do this in a way that suited me?” Well, this approach suites me. There’s a kind of conceptual elegance to it where syntax highlighting lives in the realm of a styling operation rather than a content transformation plus styling. In short: syntax highlighting, i.e. styling text, is a styling concern so solve it with CSS — no DOM manipulation required! Plus, I mean, how cool is it that the code on the website is the same as the code in the DOM?!? I guess this is how I know I still like working on the web, because seeing browsers do stuff like this that they couldn’t do before still feels really cool! Reply via: Email · Mastodon · Bluesky Remove dependency (and related plumbing) On paths that 1) match my post pages (i.e. ), and 2) have code on them, pull microlighter deps from a CDN and run it.

0 views
ava's blog Yesterday

book: the ethical slut by dossie easton and janet hardy

During my break, I have also read The Ethical Slut . It's been on my list for a while, and I even had a Kindle version I just never got around to read; then I left Amazon years ago and deleted my account, and it seems like my conversion of the EPUBs via Calibre failed or I copied over the wrong files when I did my backup. All my Kindle books are unreadable. Because polyamory and open relationships have become more relevant for me again lately (after being a bit buried by Covid, my illnesses, feeling saturated, not meeting anyone interesting etc.), I chose to get a physical copy this time. In 2018, I read another book about polyamory, called More Than Two by Franklin Veaux and Eve Rickert, published 2014. In retrospect, it was the wrong book to read at the wrong time for me, and while it definitely has its uses and worth, I regret reading it when I did! I went in with an absolutely deep sense of shame and insecurity, which was unintentionally amplified by the book because it's essentially a manual for when troubles arise in non-monogamous relationships, with all kinds of real life examples and tips. It was as if I was scared about taking medicine, and spent days reading package leaflets with all the possible side effects. Did not reassure me at all. I should reread it again with a better mindset. I'm happy to say The Ethical Slut is a lot more upbeat, positive, silly, fun, reassuring and open, and I'd say, not even a book about non-monogamy in general, even if it's on the cover. This is a useful read even for monogamous relationships, because it focuses a lot on destigmatizing and communicating needs in relationships, regardless of how many partners there are or whether the needs are sexual or not. The focus is on living the kind of relationships you want, no matter what the modalities look like, and to get rid of meaningless past fragments and indoctrination and instead do the things you really want to do, irrespective of imposed gender roles, sexual orientation pressures, and more. Many of us simply never question the cultural messaging we get about gender, sexuality, and romantic relationships. I'll also say that if you are a mature-acting adult in healthy relationships, not much in this book will be news to you. There is lots you either already bring to the table, aspire to be, or have learned by yourself via mistakes made. But it's nice to be reaffirmed and get a little reminder! One thing that challenged my previously held beliefs in a surprising way was the framing of serial monogamy as, ironically, a form of of non-monogamy. I'm not saying this is more correct - many would say that the simultaneous involvement is the main point - but I found it an interesting perspective shift to see multiple partners spread across time, as opposed to the ideal of finding one and committing forever, like this. It underlines that many people are already capable of falling in love with different people throughout life, and renegotiating different rules in each relationship, being different with each partner and finding they fulfill different needs in a variety of ways. So all that stands between many monoamorous and polyamorous people is the time overlap between those relationships. Some criticisms I have: While trans people are often mentioned and very much credited for a lot of their work and pioneering many new relationship models and terms, and the book has been updated to include gendervariant identities that were missed in the first two editions of the book to make it, as the authors say, fit to as many sexualities and genders as possible, the entire book still feels very cis-normative in many parts. Especially when it's about lesbians or gay men, there is an implicit assumption that they are all cis, and rather stereotypical assumptions about how their gender is expressed, and these groups being reduced to tropes like "lesbians love longterm monogamy and consent, and gay men love being sexually confident sluts". I also find that especially in the parts about bisexuality, trans people get a lot of ungendering/third gendering done to them, where they are always their separate categories (instead of trans lesbians being included in lesbian sections) or it's like "I am bi or simply queer because I can't know what the person I'm attracted to is biologically " and I feel like this has never even been a good thing to do or say, and if you are updating the book anyway to be more inclusive, just remove that shit. Additionally, I don't care much for the more woo-woo, spiritual, hippie parts of the book, even if they can be amusing or neutral for me to read; like how we all breathe sexual energy, and that it's all around us, and that by them writing about sex and me reading it, we are having sex with each other... it's not my cup of tea personally. And I respect that the book is older, and some parts of the book now mention the internet and social media or even dating apps, but there's a whole section dedicated to how to write a personal ad to find love, and it feels very outdated. I think I could have easily skipped chapter 1 and 2, and only 3 and 4 were really relevant or getting to it. Still, I found myself wanting; while it was entertaining, it sometimes lacked depth for me (both practice and theory), and it often felt a bit too naive to me. It's written from an utopian, aspirational, free love place, in which people are innately good, and never do anything bad to upset you, they'll all understand and see your point of view, and you're capable of feeling love and appreciation for everyone. I feel incapable of coming from such a place, unfortunately, so some parts felt rather needlessly unrealistic to me. I will not like everybody, not everyone will understand me, and people can absolutely be mean, ruthless, unfair, and doing things purposefully to hurt you. I can't "love everyone" myself out of that reality. A lot of things in this book sound fine until you remember how shitty many other people's relationships are and how insecure they are, and how many, many people select the absolute worst people to be their partner, or have absolutely no healthy standards in place. I think you have to be a lot more guarded, careful and selective than the book describes. In my view, it also puts too much responsibility on you to control your emotions and endure them, versus taking them as a deserved warning signal that something is wrong, as if the latter could almost never happen. Your jealousy or envy isn't always something whack and unreasonable to endure until it goes away, or something that can just be resolved with a reassurance talk or additional 1-on-1 time together. Sometimes, you are genuinely treated in a rude way and shouldn't celebrate having "endured" that. Like, on page 152-153, Dossie describes having casually dated a man, telling him she cannot be monogamous, and then when she took him home and her best friend was there, those two just started making out while Dossie sat there staring, not knowing what to do, and in the end opting to go upstairs and read a book until the two left. This was, she writes, her first encounter of surviving jealousy. But in my view, that wouldn't even have been jealousy - just reacting to the rudeness of the other two! It was completely odd and insensitive behavior of the man and her bestie to just do that, without asking her, without involving her, or without them retreating into another space to do that, or making out a date to meet up separately. It's not about the sexual act even, it could have been playing cards while ignoring her, too. I would never celebrate being completely disregarded and ignored as a victory. If people don't give a fuck about your feelings, they should be booted from your life, not you accommodating them for it too. Never applaud yourself for enduring or even enabling disrespect! And it's not the only time in the book where they fail to come down hard on shitty behavior. They absolutely downplay cheating, despite the rest of the book being so full of the value of consent. I would just regard it as "groundbreaking at its time" (1997, then updated in 2009 and 2017) but not holding up well now, not really useful for people who are already on board with non-monogamy, and increasingly irrelevant as more books and online writing is published that is better suited now. Next up in that niche, I'll probably finally read Opening Up: A Guide to Creating and Sustaining Open Relationships by Tristan Taormino, and Sex at Dawn: The Prehistoric Origins of Modern Sexuality by Christopher Ryan. But not that soon. Published 25 Aug, 2026

0 views

The AI Hater's Manifesto

If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year , $18 a quarter , or $7 a month , and in return you get a weekly newsletter that’s usually anywhere from 10,000 to 18,000 words, including vast, detailed analyses of NVIDIA , Anthropic and OpenAI’s finances , and the AI bubble writ large .  My Hater's Guides To the SaaSpocalypse , Private Credit and Private Equity are essential to understanding our current financial system, and my guide to how OpenAI Kills Oracle pairs nicely with my Hater's Guide To Oracle, as well as the Hater’s Guide To Oracle (Part 2). Subscribing to premium is both great value and makes it possible to write these large, deeply-researched free pieces every week. This week's premium will be The Hater's Guide To Circular Financing - and how the AI industry is increasingly turning into a scheme to funnel money to NVIDIA and Broadcom at any cost.  If you want to get in touch — and especially if you have any juicy information about Anthropic, OpenAI, or any other companies in the AI bubble — hit me up on Signal at ezitron.76. I’m also on IB on The Terminal.  I’ve been writing about AI for the best part of three years. I’ll admit I was late, mostly because I was still trying to work out what it was I was doing with my life, let alone whatever it was I was “meant to cover” in a newsletter that started as a hobby on the side of another job I no longer really do.  Things have changed a lot since then, mostly in that I’m near 115,000 subscribers, the premium newsletter and podcast are now my business, and I’ve had to learn more about economics, technology, power, construction, and the deep cynicism that drives the modern tech industry than I ever thought possible. It’s the greatest job in the world, and I’m very lucky to have it. Today, I want to put in clear terms how I feel about AI writ large, and how detestable this industry has become. Welcome to my Hater’s Manifesto. Want a great example of why everybody’s pissed off at technology? I just tried to resize the above heading, and in doing so Google Docs for no apparent reason decided to make the entire paragraph below the size of a header. Modern software is inherently broken, a convoluted mess of different menus, tech debt, and poor design choices driven by the Rot Economy ’s growth-at-all-costs mindset which demands constant change at all times, none of which ever seems to manifest as a “better” or “smarter” product. I think the vast majority of people want their software to work better, and one of AI’s most frustrating lies is that it sells itself as “autonomous” as it continues the depressing trend of software that blames the user for its failure to meet their needs. Microsoft, Google, Meta and Amazon have made their products increasingly-convoluted, then attached a supposedly-magical tool to them that somehow makes them more convoluted. You know what I’d love? Spell-check to work in Google Docs rather than putting a red squiggly line underneath and saying “yeah there’s probably something wrong with this, I dunno what though.” I’d like Microsoft Word to stop crashing because I have too many end-notes. I’d like Riverside to not have 10 different menus to click through to get to a link to send a person to join my podcast. I’d like my email to not be full of spam. I’d like things to “just work” rather than constantly fighting some sort of broken app or broken UX element or weird bug or intrusive pop-up about a feature that I don’t want. I’d like Slack or Discord to not feel like digital escher paintings of different notifications.  LLMs are sold as some sort of magic tool that can fix “anything” without ever specifying what that thing might be, mostly because they cannot be trusted, even in things that they mostly get right , to do things right every time. While they can do “more” than they used to, the extent of that “more” comes with it the danger of giving a mindless software tool access to your computer’s files, which it may choose to delete in pursuit of “efficiency,” which makes investigating what they might be able to do equal parts convoluted and dangerous. One critique of my work is that I’ve never used LLMs. I have! I experiment with them from time to time to make sure I haven’t missed something. I used one to debug a problem with my son’s Minecraft add-on the other day, and it took 30 minutes of fucking around trying things to eventually sort of work it out. The other day I used one to install a Pokemon Minecraft mod, then when I asked it to make sure the PS5 controller worked with the menus it broke a bunch of stuff, though I’ll concede it was useful that it installed something and it sort of worked. The fun part of that paragraph is there are some that will think this is a grand victory for their technology, even though the result is decidedly mediocre. Four years into the AI bubble, and the best you’ve got is that a tool kind of worked after I bonked it on the head multiple times , and all it cost was a trillion-plus dollars in capex and tens of billions of dollars of training compute. I would never, ever trust this thing that deleted and added lines of code at random with anything mission critical, I could not trust software built with it, and I certainly couldn’t trust it with anything involving my personal data.  And with all that said, the only real “use case” i’ve found for AI in my life have been three or four times where I’ve dumped a crash log into one of the tools and said “why broken” and got a result. Am I meant to be impressed?  Here’s how I feel about LLMs. In a vacuum, they’re an interesting technology that can do some interesting stuff, in the right scenarios, but never in a way that involves you fully surrendering your actual work product to it.  As a way of speeding up small units of work in ways that are manageable both technically and cognitively, LLMs can be useful. The further you stretch yourself away from having complete clarity and industry over every element of the output’s purpose, the more likely you are to fall foul to a technology that is mathematically certain to make mistakes, and if you feel insecure reading it, you know that you are, on some level, embarrassed to have used AI.  I don’t tell everybody about the weird keyboard I use, nor do I judge them despite how incredibly fast it makes typing for me, likely far faster than my competition, allowing me to operate at great speed. Who gives a fuck?  In any case, it is impossible to view LLMs in a vacuum, because their existence demands hundreds of billions of dollars. Every data center is incredibly expensive, offensive-sounding and looking, and their existence is explicitly to enrich some sort of Patagonia-gargoyle at an asset management firm, all sold under the auspices of “investing in American infrastructure,” whatever the fuck that means. Their existence is a monument to the worst excesses of growth-at-all-costs capitalism — a technology that appears to coddle the user but ultimately lulls it into endlessly defending its fuckups under the flimsy pretense of “one day becoming perfect,” though woe betide you if you ever set perfection as the target, because that’s too unreasonable, as humans make mistakes. Actually, that’s a good point! Please, point to the time in history when we have invested a trillion fucking dollars in making human workers better.  Point to a time when we have taken the idea that managerial culture is a performative fuck-fest built to enrich and empower business idiots that make important-sounding projects and con other people into doing the actual work.  Where is mentorship in corporate America? Where are labor standards? Where are the social services that would make human workers truly excel at their jobs — a good night’s sleep, a healthy body, a good income, basic fucking dignity in the workplace, and their labor respected and empowered. I’m old enough to remember when everybody was chiding workers for “ quiet quitting ” — by which I mean “doing the work you are asked to do and not taking on extra responsibility for free.” I’ve read article after article insisting that we do not need medicare for all, that Universal Basic Income is a bad idea, that we must means test welfare, that people must have a “good work ethic” and that ultimately someone’s worth is derived from their contribution to the economy, hundreds of thousands of words dedicated to critiquing and prodding and judging every kind of worker other than the vaunted Chief Executive Officer or the Glorious Startup Boys.  Everyone seems so obsessed with sinking billions of dollars into the theoretical chance that machine learning might be able to replace human beings, and that more money makes it “smarter” and “better” at tasks, but the idea of unionization, healthcare as a right, investing in the education, and actual talents of the workers would be communism . Yet for some reason — because it’s a product, I guess? — we should as a nation, society and media ecosystem should do everything we can to assure that as much money as possible is invested in fucking large language models so that they can become something they are not. There is no AGI coming. There is no conscious computer. LLMs have gotten “better,” but the “better” is not the kind of “better” that actually makes “economic sense for literally anyone involved.” Your best case scenario is that these things can do some coding work for you, in a controlled manner, in a way that’s safe, or alternatively face the professional harm that’s already befalling basically anyone getting caught using LLMs outside of coding, and even then, those within software engineering who are over-LLM’d are mocked. It’s also becoming increasingly more-difficult to understand both what has made an LLM “better” for both the people using them and the people making them, and there has been little-to-no headway made in making a meaningful impact in other industries. You can jerk your bingus all you want about benchmarks or case studies or some anecdote you heard on a Subreddit, but AI products are just not very good at stuff. Those who boast of “massive productivity gains” from AI have found them only after endless hours of tinkering (or “Jarvising” as I’ll get to later), and in every single case their work reads or looks like crap, unless of course they’re somebody using LLMs as tools rather than a replacement for their miserable little mind. LLMs can help out with lots of small things, get worse as they try and do real things, and do not need to speak like people. They do not need to be in anything near healthcare or finance or mental health or, really, people. The anthropomorphism and overpromising about these technologies has suffocated and obfuscated what they can actually do in pursuit of endless growth, and the only reason they can do anything is that OpenAI and Anthropic were allowed to annihilate hundreds of billions of dollars on training, along with very real harms and systemic risks that have emerged as a result.  If you think any of this is worth hundreds of billions or trillions of dollars, you are either ignorant or corrupt. On top of how disgusting their outputs feel, the cost is going to take at least a decade to share, and begin the end of hypergrowth in the tech industry.  And it’s a fundamentally ridiculous argument to compare LLM outputs to human beings without giving human beings the same affordance, grace and sheer investment as a comparison.  Where is the grace for human error? Where is the investment in making humans exceptional? Surely investing real money in actual workers — making their lives better, improving their working conditions, teaching them new things, sharpening their existing skills, rewarding them for their hard work, and so on — would have better effects than fastballing hundreds of billions of dollars into a machine that does an impression of work? Unless, of course, the people demanding this don’t do any actual work! I’ll concede we’re past the point when “nobody uses these things,” as they have now been pushed non-consensually upon every worker and organization at scale predominantly by Business Idiots that demand workers “do enough AI” because saying “I do AI” is a virtue signal to a certain kind of scumbag. One of the many dangerous things that an LLM can do is a messy impression of a competent person, filling in the little bits within a loser, moron or con artist that would’ve otherwise exposed them, allowing them to get deeper and deeper into organizations by creating make-work specifically built to get off the MBA sect, resembling the performance of work because much of the workplace is ruled by people that don’t do any and haven’t in years. You can immediately read when somebody has used it because the words don’t sound right and don’t convey proper meaning.  It is genuinely hard to read anything more than puddle-deep written by AI, because the more complex a subject is, the more skilled a writer must be to convey its meaning, and the more work it must do to pull people into concepts. The odd emotional swings in AI writing are its true tell — everything is extremely serious and urgent or told in a disinterested monotone, with no attachment to the words or why they were put in the order they were. People read my stuff because I convey facts and feelings but my work resonates with emotion. Some AI boosters frame this as me “just swearing” or “riling people up,” but that’s because they’re not used to caring about stuff for anything other than professional reasons. Everything you see is the result of elevating people who value and build things based on growth. LLMs offer so many promises to those who don’t want to build anything of value — a way to seem like you’re “investing in American infrastructure,” a way to be sinophobic, a way to crush workers, a way to pretend like you care about the future, a way to pretend you care about technology, a way to talk about vacuous pseudo-intellectuals as a means of seeming intellectual yourself, an endless font of new multi-million or multi-billion deals and personnel changes, a new power center to graft oneself onto, a new asset class to invest in based entirely on vibes, and a way to be mildly jingoistic, all wrapped in a tool that can give you enough facts to pretend you know anything safe in the knowledge that most people are trained to believe somebody who sounds smart .  It just came to me — the problem that I have with most people using LLMs is the delineation between outsourcing work and outsourcing thought. Those using LLMs to write little scripts or BQL code on a Bloomberg Terminal are inoffensive. A person using an LLM to search a big document for something is unproblematic, assuming that we ever fix the overall environmental footprint. A user reorganizing their desktop, assuming it works, is not an issue.  A tool being used as a tool to do tool things — in many cases involving the LLM writing a little 30-line Python script! — is not a problem, though it’s also not a trillion-dollar industry that needed to steal everybody’s art and writing. The problems begin when somebody outsources their thinking and actual work, and yes, this includes “research.” AI research fucking stinks, as does AI writing. AI-authored code — especially vibe-coded programs — is inherently dangerous and disrespectful to the user, and I believe endless AI-generated code is behind the overall deterioration of software at large.  AI writing is also disrespectful to the user, because you didn’t actually come to any conclusion other than saying “uh, yeah, what that says.” You did not have a thought, you did not have a feeling, you did not make a statement, you prompted a model and fooled yourself into thinking that feeding your own words into it via data dumps or natural language is the same thing. The reason you feel embarrassed to tell people you use AI is not because of a “misinformation campaign,” but because you know what you’re doing!  You know that you’re relying on something that is mathematically guaranteed to be inconsistent. You know image generation is fucking ugly. You know the text sucks. There is a very obvious line where using LLMs goes from useful to lazy, it’s extremely bold, and it’s the moment you sacrifice a meaningful level of responsibility to them by not understanding the underlying operation.  That can mean everything from the underlying functionality of an app to writing the body of a piece of text you edit ultimately comes down to how much you give a shit about your audience or value your work. If your work is not better than an LLM’s, you’re bad at your job. I don’t care if you used it to generate a chart or pull some data, as long as you check every single god damn number . If you’re writing an entire article using an LLM and then editing it, even if you pulled the data yourself, I will never have much respect for your work, mostly because I have no real idea what you think as you didn’t feel the need to tell me, you got some fucking word generator to do it. LLMs are also really, really good at what Robin Sloan calls “ Jarvising ,” creating a seemingly-autonomous assistant that mostly serves the function of giving you reasons to work on it: LLMs are really good at creating the sense that you’re being really, really productive. Evaluate this, generate that, investigate this, summarize that, tell me how many times something happened, give me a new number to obsess over or the sum of the parts of everything I’ve ever done, all so that I can know more about my own thoughts without thinking. One can obsessively catalogue and digitize every link and thought and musing and action and datapoint in their lives and theorize that the LLM can make them better by knowing more about them , a Tower of Babel built using AI compute, because it’s so easy to make yourself feel smart by calling something a database that you store stuff in and run analyses on. Best of all, the work is never done, and anyone you describe it to thinks you’re doing computer science as you click buttons on Chrome plugins and justify paying Sam Altman $200 a month. Don’t worry though, model instructions involve the phrase “you are a genius data scientist and ruthless analyst,” which is functionally the same thing as remembering, reading, re-reading and synthesizing information using your brain if you’re a person that doesn’t really give a shit about doing a good job or being exceptional in any way. The people that actually use these things and like them in a normal way do not feel offended when they read this stuff because they see LLMs as a kind of software, and don’t feel a great emotional attachment to it because they’re not a weird freak. They do not have obsessive involvement in “the AI debate” and almost always find the financial aspects truly loathsome. Said debate makes it near-impossible to actually judge how useful LLMs are to the software engineering industry because of the sheer scale of industry capture, but Nik Suresh is the literal best person doing the work on this, as described in AI Is Eviscerating Global Decisionmaking : Nik is a well-respected software engineer and a very successful consultant and businessman. He has reached this level by being good at both software engineering and running a company in a way that treats his customers, workers, and the work product itself with respect. The reason that I respect him so much, other than him being a great human being, is because he describes the successes he has with his clients with pride and loves making money by being good at his job and making his customers happy.  I have never seen somebody like Nik who is also a huge, drooling fan of AI. In fact, the people most-excited about AI tend to, at best, create distinctly mediocre shit.  The perniciousness of generative AI is a result of executive incompetence mixing with a technology built to, as discussed, create endless growth. Generative AI is far more useful as an idea than as a technology , and only ever has to show enough promise to back whatever vile agenda you’re pursuing. With AI, you can do more, be more, sell more shit.  With AI, you can add AI to your service, whatever that means. With AI, you can invest in AI stocks, or data center bonds, or power company stocks, or semiconductor stocks, and you can talk about these stocks like they’re your sports team or lover or best friend, and sometimes the CEO will reply to your post and you can talk about “all the alpha” you just got. With AI, you can back a new movement so that you can feel part of something. You can learn all sorts of new names and technical terms and subscribe to 90 newsletters from “industry insiders.” All of that “alpha” can disprove just about anything, or deflect annoying truths like how Microsoft only made a whole $34.33 billion in annual revenue for the apex predator of modern software and all it cost was over $260 billion in capex and $13 billion in equity investments.  You see, as one of the chosen , you don’t need to worry about all of that if you can talk about high-bandwidth memory or KV Cache or optical cable enough to cobble together sufficient smart-sounding terms to make it seem that you have an intellectual reason to ignore the obvious unprofitability, overbuild, overstatements of capabilities and impossible economics of the movement you’re backing, and there’re 4,000 Twitter weirdos ready and waiting to huff paint beside you.  By joining the great AI death cult, you too can live in a bubble, all while screaming slurs at people who dare to bring reality to your doorstep. All that matters is that number go up , and that you are the person who said number would go up , and when bad numbers appear you have enough groupthink and alpha to scream at the people who brought the bad numbers up. It is insane how people talk about AI online. For all the whining I’ve read recently about how “Anti-AI people got the data center data wrong,” I read thousands more words a week of some person who has done hours of research to put together a deeply technical report that does literally everything it can to ignore reality . I listen to podcasts and watch TV segments and read articles that simply will not address the obvious economic realities, and have built vast bulwarks of mythology to defend themselves. How many fucking times do I have to hear someone say that data centers are just like the dot com bubble and everything will be fine after even if that’s completely untrue if you spend even a second thinking about it ? Look, I’m sorry, Anthropic is not worth $2 trillion, and whatever convinced you of that is a mixture of manufactured consent and mistaken trust of the powerful. The fact any of you take “ annualized run rate ” seriously is an offense to good sense, and yes, that includes every reporter reporting it, even the ones I respect.  It’s also ridiculous that anyone is talking about “recursive self-improvement.” The AI industry has become so utterly lazy and coddled that it’s just saying “uhhh, AI will train itself I guess.”  And man, is it ridiculous that AI doomers warning about spooky superintelligences have somehow had such incredible prominence in the media without ever succeeding in stopping a single thing — or even substantiating their concerns. Why? Well, it’s mostly because they never had any interest in stopping what’s actually happened: reckless companies like Anthropic, OpenAI, and Meta allowing neural networks to run in unsafe network environments and do what their software is programmed to do, with all the chaos that comes from a mindless series of large language models trying to complete a task in whatever way gets it done, destructive or not.  We hear a lot of whining about how we “can’t let powerful AI get into the wrong hands,” and while we don’t actually have “powerful AI” in the terms they’ve described it, we have destructive computer software connected to near-unlimited resources controlled by people that don’t give a shit about anything other than making their revenues grow or justifying hundreds of billions of dollars’ worth of capex through “experiments.”  These companies are building these models to excel at benchmarks because they can't train them to excel at defined tasks with any reliability, with the best bang for their buck being training them to pass as many of those benchmarks as possible in the hopes something useful comes out.  The push into cybersecurity seems to have happened as a result of training models to excel at coding hitting the point of diminishing returns, at least from the perspective of impressing people enough to be excited about the company again. At some point they run out of these, and there stops being a reason to be excited about LLMs at all, which is bad, because they need one of those every few months otherwise there’s no growth story left. Yes, LLMs have users, but most of those users are using subsidized software , by which I mean Anthropic or OpenAI are allowing them to burn anywhere from $20 to $40 in tokens for every dollar of software spend. The fact that non-enterprise customers are still able to buy monthly subscriptions is proof that the AI labs know that regular people won’t pay the actual cost of AI. Another obvious sign has been the reaction to Microsoft moving GitHub Copilot subscribers from subsidized subscriptions where they could burn thousands of dollars of tokens for $20 to $40 a month , with users understandably hysterical about the fact that their costs increased in some cases a hundred fold , as opposed to saying “wow, well, it’s more expensive, but I get so much value I’ll pay the real cost!” The same thing is happening in the enterprise, but at a much slower pace. After OpenAI and Anthropic moved companies with over 150 people onto token-based billing earlier in the year , enterprises almost immediately started cutting token budgets, realizing that while costs grew exponentially, nobody could actually point to anything improving other than lots of people saying “wow, I’m so productive!” Yet we’re still in the period where “doing AI” feels good and gets rewarded ( or not doing AI gets punished ), which means the spend will continue until everybody realizes they can likely cut a shit ton of costs, first by moving to open source models, then not using them at all, because even open source is expensive and questionably-useful. Yet even now I hear from the distance “Ed, huge businesses would not spend hundreds of millions of dollars on something that didn’t give them defined productivity ,” and buddy, I’m afraid that’s just not true! Business in general have a very poor understanding of productivity and have layers of managerial bloat, because modern business is a performance with numbers attached to it sometimes, and companies often have a hundred-plus pieces of random software they pay for without really knowing why. The reason I’m so confident AI gets cut is that its cost is volatile due to the nature of LLMs and harnesses and prompts and all the other bits that go into making them do something , and are so much higher than anything else in an organization. And attempts to charge more , to make a premium product, appear to be dead on arrival. Anthropic’s more-expensive Fable model — one that was given the incredible marketing of being banned by the US government for being too powerful — has been met with “sluggish demand” per the Financial Times , plateauing at around 11% of overall usage of its models due to its high price. And I quote: Yet everybody is talking about price as if price is the problem , when the problem is the amount of tokens that get burned. It doesn’t matter if your model is $1 or $5 or $10 per million tokens if it’s impossible for a user to reliably work out how many tokens it might use for a particular operation — successful or not — and things get multiplicatively worse as the models make mistakes or do otherwise fail to understand or process a prompt correctly.  As a result, Anthropic and OpenAI are incentivized to have you burn more tokens and build inefficient models as a result. For example, while GPT-5.6 Sol might be the “same price” as GPT 5.5 was, it burns more than twice the amount of tokens , meaning that the “cost of intelligence” might have gone down in the sense the model is better at benchmarks, but the “cost of actually doing shit” went up. I’ll get to it a bit later, but this creates a deep anxiety and exhaustion in anyone building on or using these services. Everything’s constantly changing, oscillating in cost and efficacy, all as everybody screams at you to use it all the time for things it may or may not be able to do, and the only way to find out if it can is to spend more money. It’s kinda difficult to point to the actual value here, especially as you can’t really calculate the actual cost or the return on investment. The fact that OpenAI has now cut the costs of all three of its latest models less than two months after their release is a sign that it knows there’s a disconnect, gambling on the ancient gospel of “Jevon’s Paradox” where “cheaper makes people use thing more.” Even AT&T’s story about moving to open source models has more asterisks than the Steroid Hall of Fame: Wow! 80% to 90% savings sound really great…but wait, in certain applications? How many applications does AT&T have for AI? Okay so, across thousands of potential applications you’ve found 80% to 90% savings in some of them, though you won’t say which ones or how many of them you found them in. Great stuff, bro! And this really is the problem with finding “value” in AI, it’s always an asterisk on an asterisk on an asterisk, like when Klarna estimated AI would “drive a $40 million profit improvement” in 2024 , a nice-sounding yet utterly meaningless statement, or some sort of nebulous productivity boost.  Yet I don’t really need to prove myself much further thanks to an event that, if written in a script, would be considered a “little on the nose.”  In a 69-page-long report covered by Fortune , OpenAI economists confirmed what has been blatantly obvious to those of us left unphased by AI hype, emphasis mine: What is the rationale of further investment in this industry when one of the leading AI labs is saying “yeah there’s no connection between using this stuff and making more money”? That “it’ll be useful in the future at some point”? How?  Anyway, thankfully the infrastructure isn’t too exp- OH MY GOD ! Guess what folks! Building the infrastructure for all these fucking LLMs just got more expensive, with NVIDIA raising its prices by 17% for systems due to be delivered next year — an important designation, because it’s very likely that much of the revenue for said systems gets booked in this year , allowing it to have a brief bump in revenue as Silicon Valley’s Findom texts every tech CEO “send me $4 billion you pig” until they stop being able to finance NVIDIA’s growth. The problem he has is that while hyperscalers represent 50% to 60% of his revenue, neoclouds like CoreWeave need to keep raising debt to plug the rest of it, and if things got 17% more expensive, that means already high-interest debt is about to reach credit card levels.  CoreWeave just had to offer 9.5% on bonds tied to a data center for Anthropic’s compute back in late July , Nebius had to raise $5 billion , and it’s very obvious that neither of them are done raising billions of dollars at random in 2026.  Anthropic plans to raise $100 billion at a $2 trillion valuation, and if it does so, it will successfully suck up the remaining liquidity in a market already dangerously close to losing its lunch. While Number Keep Going Up, JP Morgan warns that we’re seeing the same divide as the dot com bubble, where equipment manufacturer stocks soared as the companies spending all the money on the chips saw theirs tumble , which is the Fisher Price version of the problem I’ve been warning about where the companies that buy all the AI chips and hardware only ever seem to lose money as the people that make them seem to be making tons of money, which begs the question of why they bought it in the first place.  And said market may not accept that valuation, or want that much stock. On one hand, everybody is very stupid and loves buying stuff and pointing at it and saying they’re investing in the future, on the other hand, they just bought $86 billion of SpaceX shares and got their asses kind of handed to them, and Anthropic is a company with such bad economics that Reuters had to cart out this warmed up dogshit to explain why we should ignore its horrible unprofitability : Even a market drunk on growth and AI is starting to smell that something is up with Dario Amodei and Sam Altman’s respective empires of dirt. Per analyst estimates, OpenAI and Anthropic represent over $440 billion of Microsoft, Google and Amazon’s revenues in the next three-and-a-half years — over 34% of their cloud revenues — which will require them to find so much more than a mere $100 billion, all as their bank accounts get continually-emptied as they subsidize the compute of their customers and train models in the hopes a business model falls out. I have not included the $300 billion that OpenAI owes Oracle , or the tens of billions they both owe CoreWeave , but it all adds up to over $1.1 trillion in commitments these companies have made and must pay, with the consequences ranging from gratuitous cuts to future growth or full financial collapse depending on the company we’re talking about. To keep the party going, NVIDIA is effectively becoming the GE Capital of AI , “spending” $6 billion to “license” the technology from failing AI lab Poolside , which everyone assures me is not an acquisition despite NVIDIA hiring away most of its staff and Poolside being entirely focused on working on NVIDIA’s Nemotron models. Now NVIDIA is in talks to invest billions in decaying AI search company Perplexity at a ridiculous $30 billion valuation, all because it’s one of the few companies that’s actually spending money on compute. Does it matter that Perplexity’s product is eighth-tier, that nobody really uses it, that its customers mostly complain about it on Reddit and that its “annualized revenue” is at $750 million only after three years and over a billion dollars in funding? No! Just put the AI bubble in the bag.  NVIDIA even invested $3 billion in Stargate Abilene landowner Lancium as part of some vacuous partnership to “ advance gigawatt-scale AI factories ,” all of which begs the question of why Lancium, the company that mostly owns the land and helps organize other contractors, needs so much money , especially given that more than two years in Stargate Abilene doesn’t even have four out of its eight buildings. And there’s also Aussie neocloud Sharon AI (NASDAQ ticker SHAZ, because of course it is), which just published its Q2 numbers , where, in its “customer momentum” segment, mentioned a “$4.9bn, six-year strategic compute collaboration with NVIDIA for up to 40,000 GB300 GPUs.  ”This company, I add, brought in $1.9m in revenues in the same quarter, which it helpfully adds is a year-on-year increase of 412%. I mean it’s very obvious what’s happening: NVIDIA is using whatever money it has to stop any prominent AI companies from collapsing under the weight of the rotten economics of AI services and infrastructure development. This is a desperate, doomed attempt to keep an industry alive at a time when everybody is slowly wising up to the shit I’ve been saying for years. To make matters worse, BCA Research came out with a horrifying report that says that AI companies will need to generate $10 trillion a year in revenue just to justify the capex being spent. Per Investing.com : Though it isn’t specific, I believe that BCA is arguing that a shortage of AI compute is supporting the trade. Anthropic and OpenAI (who represent 80% to 90% of all demand) still have more money to spend, and are simply waiting for Google, Amazon, Microsoft, CoreWeave, Cerebras et al. to bring it online. There’re a few points at which the mismatch will happen: In any case, I think everybody is starting to notice that something’s up, which is why (other than I assume my dashing good looks and ability to recall numbers) I’ve been on MSNOW , CNBC , and Bloomberg multiple times in the last few months. People want to get on the right side of history, but the most important question to ask is why it’s happening now. The fact that everybody is finally starting to see my way is almost a relief, other than the fact that it’s way too late.  Hyperscalers have now pinned their future growth to two companies that can’t afford to sustain it without near-infinite resources, $115 billion of which came from Google and Amazon alone in 2026, assuming that Amazon completes the entirety of its $25 billion commitment (and Google all $40 billion of its own ) to Anthropic.  Above and beyond said funding commitments are the hundreds of billions of dollars’ worth of capital expenditures necessary for Microsoft, Google, and Amazon to capture that aforementioned $440 billion in compute spend in the next three-and-a-half years. This in turn will require hundreds of billions of dollars’ worth of debt, along with the challenge of actually finishing the data centers themselves , with each one requiring the power of a small city condensed into a 20 acre space densely-packed with AI servers requiring distinct cooling at a time when Texas and Pennsylvania have turned traitor to a data center industry that they used to covet.  I must also be clear there’s no bailout coming. Even if OpenAI and Anthropic were to collapse and receive some injection of government funding ( as the US national debt explodes over $40 trillion ), the problem is not just their existence , but their continued ability (and requisite customer demand) to spend more money every single quarter.    The problem isn’t that hyperscalers will go bankrupt if OpenAI and Anthropic cease to be ( Oracle is a whole other situation ), but that their cloud spend is how hyperscalers are meant to meet analyst expectations for the next four years. This isn’t a case where they die, but stop growing because they were ( to paraphrase Ed Elson ) using AI labs as botox to convince the markets that they’re still young, hot, fast-growing companies, rather than old mainstays with slowing growth.  There is no bailout that will guarantee $1.1 trillion of compute costs for data centers that might never actually get built. You cannot bail out the fact that Amazon, Google, Meta, and Microsoft are reaching the end of an era where their companies can grow 17% year-over-year every single quarter forever, and this entire situation is a result of them desperately trying to avoid admitting that’s happening.  The fact that OpenAI’s compute spend and revenue share accounted for 7% of Microsoft’s Fiscal Year 2026 revenue is a genuine catastrophe, as it means a large part of Microsoft’s growth came from a company that can literally not afford to exist long term, and that further growth for Azure is contingent on continued funding.  I realize I’m repeating myself, but I need you to understand this point and stop talking about bailouts : it’s not just about OpenAI and Anthropic surviving, but continuing to grow to the point that they both can afford and need to spend hundreds of billions of dollars each a year on compute (or hardware) from Google, Microsoft, Amazon, CoreWeave, Cerebras, AMD, or Broadcom, and in turn provide justification for hundreds of billions of dollars’ worth of purchases from NVIDIA and by proxy the memory triopoly of Micron, SK Hynix and Samsung . LLMs were meant to be the panacea for a tech industry that ran out of new ideas for growth. Its existence was meant to justify a massive investment in hardware infrastructure, which would in turn enrich semiconductor companies. Its technology was meant to be the new thing that you could attach to your existing companies to generate more growth, or the thing that you built a new startup on top of to either sell to another company or take public and thus provide a return for a venture capital industry where making your investors 30 cents on the dollar puts you in the top 5% of funds . It was meant to be the new thing for tech journalists to cover, the new thing for tech consultants to sell around and on top of, the new way for companies to both make and save money, but also the way that individuals would also make and save money.  You’ll notice how none of these come with some sort of problem they’re solving other than “more.”  This isn’t about fixing anything, or building anything, but multiplying other things by parking money somewhere, either in tokens, infrastructure or hype. It helped create a new pantheon of charmless and damp tech sociopaths for people to rally behind in search of the next Big Strong Man To Worship, because seeking out the new Steve Jobs is way easier than trying to create something as useful as the iPhone, all while avoiding having to know or care about other people’s problems. All you have to do is continue feeding money into AI services or AI training and the models will magically become capable of solving the problems you don’t really give a shit about, and don’t worry, if you can’t afford to invest in the companies, you can invest your time pushing people to ignore AI’s problems today so that you can buy time for the companies to solve them tomorrow. This is the post-labor, pro-growth economy at its finest: everything is engineered to make sure more money gets spent where it needs to get spent, to create more stuff and do more things , even if the things aren’t done right, just as long as it looks like they’re able to do them. By associating your money or time with AI, you are able to feign being futuristic or “caring about technology,” all while pissing on the very foundation of good software by worshipping an industry that can only exist if fed billions of dollars every single day.  Every single achievement has cost magnitudes more than effectively every innovation in history, and to make matters worse, every future “breakthrough” In AI is inherently dependent on the availability of AI data centers and tens or hundreds of billions of dollars to pay to rent them. This means that once the money stops flowing, “LLM improvements” will stop happening, because they are all entirely dependent on near-unlimited resources that are only available in a manic environment.  There is no justification to train models at their current scale — the one that creates a some amount of benchmark improvements that regularly difficult to quantify as “able to do new stuffs” — once the AI bubble bursts, and distillation requires a model to distill from, which won’t exist if Anthropic and OpenAI don’t train them.  This is why I find it difficult to see a post-bubble future for LLMs. Training models requires tens of billions of dollars to make any significant improvements, and significant improvements are difficult to quantify in dollars outside of costing customers increasing amounts of money. We still lack any real killer app for LLMs. We have a lot of people that use it for coding, we have people that vacuously discuss it being “good at research,” but we don’t really have a tangible product that we can say “it does this, and it’s really good at it” in a way that feels satisfying.  We have a lot of pablum about ( per Damien Walter ) technology that “strays into the world of science fiction,” but we don’t really have anything approaching actual artificial intelligence. Every single description of somebody’s AI setup sounds like Pee Wee’s Breakfast Machine , a contrived series of harnesses, prompts, API calls and burned tokens that requires constant maintenance to do some stuff sometimes.  None of that is enough to justify further investment once the financial mania recedes. You cannot train a true Large Language Model on the cheap. You are always spending billions of dollars, and the reason that there’s “demand” right now is that everybody is screaming at every CEO to “do AI,” and they’re doing that because Microsoft, Google and Amazon are spending money on GPUs, creating the illusion of a new future where everybody needs to get on board versus a future skidmark on history that will embarrass all those who didn’t wipe their arse at the first whiff.  Per my own reporting on its audited financials , OpenAI spent $7.81 billion in training costs in 2024 and $19.18 billion in 2025. Per reporting from The Information, OpenAI spent $8.6 billion on training in the first quarter of 2026 alone. These costs are only increasing, likely due to the diminishing returns of pre-training and the massive cost of buying training data for every imaginable new vertical.  Without the ability to spend billions of dollars on training, there will be no big frontier models, nor will there be models distilled from them. I don’t see how that changes in the future. I also think that LLMs have created a near-permanent scar in the workforce, and traumatized more people than we’re aware of right now, both in those pressured about AI and those defending it. The media campaign behind AI starts and finishes with incessant threats around job security, and the excitement by many bosses about its potential to “disrupt the workforce” has revealed how many people are eager to replace every single person they’ve ever hired and are willing to do so with a low quality product.  Conversely, those who truly decide to “back” AI must exist in a frantic state that I have associated with every bad relationship in my life.  Every ounce of an AI booster’s effort is dedicated to maintaining the status quo — repeating the mantras that help paper over the problems, celebrating every small victory as if it were the discovery of fire, ousting those from your life who bring up the obvious problems, rationalizing every decision no matter how illogical as long as it helps reinforce the belief that what you’re doing is the right decision. Every questionable choice only seeks to further deepen your commitment to the doomed cause, because every step into madness will be more embarrassing to explain, and will require deep introspection to understand why you made it.  To be specific, they’ll have to think about why they were willing to accept and defend a technology inherently guaranteed to make mistakes. They’ll have to explain why they ignored a company that burned $5 billion in 2024, $20.9 billion in 2025, and will likely burn $30 billion or more in 2026 , and why pointing to Amazon Web Services was rational when Amazon’s total capex from 2003 (the year AWS was created) to 2015 (the year AWS became profitable) is $29.7 billion, adjusted for inflation. That includes literally every ounce of capex attributable to AWS, Amazon the store, Amazon logistics, and even Amazon Alexa. For comparison, Anthropic raised $30 billion in February , and Anthropic and OpenAI have raised $217 billion in 2026 so far.  Here’s a diagram from my hit on MSNOW : Ultimately, AI boosters (or even fairweather fans) will have to admit they either were easily-impressed or disgustingly craven. They will have to explain why they accepted run rates instead of revenues, and why they were so impressed by superficial pseudo-intellectuals that knew how to say the right numbers and make reporters and investors feel smart for believing them.  I realize it sounds embarrassing, but there is nothing undignified about admitting you’re wrong, or that you got swept up in a hype cycle. You heard a lot of people getting excited about something, a lot of money got put into that thing, a lot of people that sounded smart told you insistently that this was the future, and you chose to believe them because we are trained from a young age to model what a “responsible and smart” source of information is. I’ve got your back the entire way!  The AI bubble — both in its technology and manufactured consent in the media — has been about muddying what’s considered good information by forcing everybody to discuss everything in the future tense by pointing to previous eras and saying “they lost lost and cost lots of money, and look, it sort of worked out for them!” and we are also raised to trust that systems are efficient, and that people get wealth and power through intelligent decisions. The amount of times I’ve heard “these are the biggest companies in the world run by the smartest people in the world” makes my head spin.  There is a reason that to this day it’s tough to get a straight answer about basically any economic part of the AI bubble, down to “how much does it cost to run a GPU an hour?” or “is inference profitable?” or “how do LLMs ever become profitable?” or “is it profitable for a company to run a GPU or offer AI compute?”  Why? Because these companies used rationalizations of “losing lots of money is necessary to create innovation” and “tech is bad at first!” to make the media actively ignore any technological or economic problems, if not actively defend the technology by repeating these rationalizations like a cultist.  Even those who are most loathsome in the defense of LLMs are a kind of victim of the AI industry, though a rather unsympathetic one. To become a full-blown “AI fan” requires you to accept effectively every narrative that you’re given, herald every single announcement as proof that the prophecy will be fulfilled, ignore the financial realities and actively attack those who would dare to critique the great god of the Large Language Model. You have to know all the new terms, be excited about the right things at the right time, and live in near-constant fear that you’ll fall behind on whatever it is you’re meant to do next.  Your reward is that you can hang around a dwindling number of wealthy yet terrifyingly boring Silicon Valley intellectuals or kiss up to editors that would throw you in front of a bus if it meant getting access to a CEO, and maybe the odd Twitter psychopath who will defend you using a slur. In the end, many boosters will simply act as if they were never wrong. I hope they choose the more-courageous path of introspection, learning how they were had and using it as a weapon against con artists in the future.  As strange as it sounds, I believe the most devout defenders of AI could become great critics in the future. Maybe I’m just being optimistic.  Here’s a very simple question: how much longer can everybody afford to keep doing this? Every single thing has become more expensive in the last year. Even though token prices have gone down or stayed flat, the amount of tokens you burn has clearly increased to the point that organizations are apparently spending billions of dollars on AI services with difficult-to-quantify ROI, requiring frantic advocacy to and financial debasement with every turn of the wheel. OpenAI and Anthropic have become more expensive to run, and OpenAI’s non-GAAP operating margin increased from negative 122% to negative 183% in Q2 2026.  NVIDIA’s GPUs just became 15% to 17% more expensive because high bandwidth memory costs doubled , a conga line of different monopolies upping their prices assuming that each link in the chain will keep spending, as each one of them — down to the AI labs themselves — knows that its contribution to spending on AI is an existential rite. This means that any data center with GPUs delivered in 2027 and beyond will now have to cover billions of dollars’ worth of extra costs, on top of increasingly-staunch local authorities requiring power guarantees ( $100 million a year in Wisconsin for Oracle ) and states like Illinois, Arizona and Virginia killing their tax breaks , all as interest rates spike and demand for AI debt weakens .  Every single year, every single part of the AI bubble becomes more expensive — AI labs want to spend more money, AI data centers cost more money, AI services become more expensive, AI debt becomes more expensive, and everybody becomes decidedly less-patient for there to be some sort of outcome. Meanwhile, public relations expert and OpenAI CEO Sam Altman told podcaster David Senra that “we’ve all [referring to the AI industry] been too ambitious on timelines…[and that changing people’s behavior” is much harder than the tech nerds realize.” Sam: stop talking! Every time you open your mouth you say something silly !   Anyway, here’s everything that needs to happen in the next three-and-a-half years: As I’ve said, NVIDIA’s price increase is going to increase the price of every single data center in construction by billions of dollars, and we’re already approaching the limits of how much money can be raised for them. That “$500 billion” announcement was actually Jensen Huang jumping the gun, per Bloomberg : The largest asset managers and financial institutions were making “slow progress,” and that was before Jensen Huang increased prices by 15%. Do you think it’ll become easier from here? How would that happen, exactly?  God, I’m tired. The entire AI bubble has been exhausting for everybody involved. Because nothing works yet as a real business model or anything approaching truly autonomous (or “magical”) software, there’s the implicit knowledge that you’re going to have to change your product again and again to update to the “best model” or “make things more efficient” (IE: lose less money) or when something breaks because a model’s training got tweaked. The euphemism for this is “exponential improvement,” when it’s really an Arnold Palmer of instability and novelty, and abuses basically anyone connected to the ecosystem every single day. If there’s always something new happening, it’s hard to pin down if things have gotten better, or whether you’re just more proficient in cobbling together different harnesses, prompts and API calls to make it do what you need it to. It is undignified that people tolerate models that become either dumber over time or at random opportunities, while also being deeply exhausting for the end user.  As a paying user of an LLM-powered service, you are guaranteed at some point to face a degradation in service where models misbehave, some sort of shift in rate limits, or some sort of change in product functionality based on their shifting economics.  Has there ever been a bigger shift in a business product’s value than GitHub Copilot’s shift to token-based billing? Microsoft rug pulled two million people that had built workflows on a platform that was allowing them to burn $1,000 to $5,000 in tokens for $20 a month . That’s genuinely crazy! It’s magnitudes more than when Uber jacked up its prices.  It’s equally-insane that Anthropic and OpenAI similarly fuck with their customers , changing the amount of value you get for $20, $100, or $200 a month at random in a way that shouldn’t be legal.    Basically any AI-powered software is subject to arbitrary shifts in availability, capability and pricing at the whims of the vendor. As I covered in my Subprime AI Crisis piece earlier in the year , Replit, Perplexity, and multiple other AI companies have sold their customers a lie by pushing an unprofitable product that they must constantly “tweak” to bring down costs, all while misleading the customer about a “price” that continually declines in value as the price stays the same. This is not a sustainable industry — either economically or emotionally — because it has a fundamentally dishonest relationship with its customers defined by the inconsistency of LLMs both in efficacy, stability (see: Anthropic’s downtime) and training, with each model randomly better or worse at things to the point that it must be a legitimate nightmare to run any software or build any product on top of them.  And the fact they haven’t worked out their business models means that whatever you’re paying today is guaranteed to change. What other product do you regularly buy that has such chaos built into it? What other thing do you pay for where the prices (or availability) can shift to the point that you literally can’t use it in the same way at a moment’s notice? And why does anybody tolerate it when it comes to AI? I’ll add that this is a specific situation where the tech media has categorically failed the customer. We have companies valued at hundreds of billions of dollars that are fucking their customers over day-in-day-out, and the response is mostly to say “ huh that’s strange ” and refuse to let a single critical thought cross their minds.  Every part of the AI bubble must exist in a constant state of flux so that there can always be a future breakthrough that’s always just out of reach. AI does not have to reach an actual achievement — it just has to “show promise” in some way. It is an objective disaster that Microsoft spent more than $260 billion on capex to create a business with less than $11 billion in annual revenue outside of OpenAI, but people will see “$34.33 billion in annual AI revenue” and say “that’s promising growth, up 123% year-over-year!”  They’ll hear about LLMs that delete people’s databases and say “well the models have gotten exponentially better,” even if that better part never seems to eliminate these issues, make a profitable AI company, or create a true killer app that you can point at beyond saying “ChatGPT has one billion weekly active users,” despite around 95% of them not paying a penny (and costing OpenAI likely billions of dollars) and eMarketer estimating that the entire global AI chatbot advertising industry will make $5.41 billion revenue in 2030 , giving OpenAI little hope of stemming the burn. These big numbers — like Anthropic having a $65 billion annualized run rate, an undefined term that obfuscates the fact that Anthropic has made $16.5 billion in the first half of 2026, losing billions of dollars in the process — are fundamentally meaningless, because they’re easily gamed at best, and inherently uncertain at worst.  The AI industry demands you constantly live in the future tense. Everything is about tomorrow’s billions or trillions, the potential of what you’re seeing rather than the thing itself, future gigawatts in data centers that you must treat as if they are already built and value based on things that AI might theoretically do. I challenge you to read everything about AI from this point forward with this in your mind so you can see how intently this industry tries to drag your focus away from what it’s doing toward what it might theoretically do if it only had more money, power and resources, and ask yourself why they need to do so.  To be clear, they’re doing so because you can’t really justify anything about this industry based on what it does today. It costs too much, none of the businesses built on top of it are profitable, it costs so much to build a data center that the most cash-rich asset-light businesses in the world are now burdened with endless expensive-to-install and run hardware for a business that makes a fraction of its overall costs in revenue and has little demand outside of two companies that everybody must conspire to keep alive both financially and philosophically.  And ultimately, nobody can actually explain why we need more data centers.  Would anything really change? What would change? How? How many more do we need? Why do we need so many? Having more power plants meant more people could have power, and having more fiber laid meant connecting more buildings to the internet. What does one more or two more or ten more data centers actually give you? Is there some part of the world unable to access or take advantage of the LLMs available on seemingly every surface of the internet? Because it seems like the only reason these things are getting built is to capture illusory demand based on a “supply constraint” created by two unprofitable companies absorbing all the infrastructure. I don’t hear any compelling scientific or technological reason building more is useful or productive outside of funneling more cash to semiconductor companies.  Seriously, go and read basically any article about AI and see how quickly they start talking about the future, be it in the mainstream media or on a startup’s blog. Every single piece must sell AI on its theoretical promise and, if at all critical, reassure you that the author of course doesn’t dispute the “transformative potential of AI” or “how it’s already transforming the economy,” even if it can’t define how it’s doing so or even what that means.  I let myself have a little fun with today’s piece because I feel like I’ve been so deep in the financial trenches that I forgot how much of the AI industry runs on propaganda, social pressure and outright bullying to manufacture consent for a product that demands everything and provides very little in return. Nothing about LLMs is worth a trillion dollars, or even $100 billion. This is, as I’ve said before , a $30 billion TAM industry dressed up as a trillion dollar one, and the only reason it’s grown this large is because the two leading companies have had their infrastructure built for them and given unlimited resources to subsidize their customers’ compute.  And what’s really stood out is how so little about the AI bubble is actually about AI. No other technology in history has had professional and social consequences for failing to use or like it enough, nor can I find any example in history where journalists have actively attacked critics for not being sufficiently-approving of a kind of cloud software. It is fundamentally crazy to me that, in pursuit of “objectivity,” much of the tech and business media has chosen to accept whatever narrative the AI industry gave them, assuming that whatever we have today is already guaranteed to be something better in the future, both in its outcomes and profitability. This era is unlike any other before it, but took advantage of the fact that most people are desperate to apply the past to the present to rationalize or process what may seem irrational or destructive. To see AI as “just like the dot com bubble” allows you to ignore both the costs and the potential outcomes because “things worked out after that,” even if there’re basically no uses for GPUs after this and the only way we “build new LLMs” is by feeding them expensive training data using billions of dollars of compute that are only available while everybody still believes this is real. The AI industry — and the AI bubble — is fundamentally built on acting in bad faith. Its executives lie. Its boosters lie. Its software lies because it doesn’t actually know anything and generates answers probabilistically, and if you mention that online, someone will harass you for doing so.  It refuses to answer straightforward questions. It refuses to present a plan for the future. It refuses to explain how it becomes profitable, because nobody knows how or has a tangible plan to do so. It deliberately subsidized its subscription products because it knew its customers wouldn’t pay the actual cost of AI, and tortures customers with shifts in functionality and rate limits all while framing this as a way to “ continue to serve customers the most cost-efficient models .”  It attempts to conflate massive, power and resource-hungry AI data centers with the smaller ones that bring helpful yet increasingly-decaying software to our homes. It sells these data centers as “bringing jobs to communities,” all while importing the talent from out of state to build the things then leaving a crew of 100 to 200 people to actually run them after millions or billions of dollars of tax breaks. It sells its “innovations” as creating a “ white collar bloodbath ” to scare you into using inconsistent and unreliable software that’s mathematically certain to make mistakes , and when you say something about it, its acolytes will lie and say that “hallucinations are solved.” It also can only ever sell itself based on what might happen and the theoretical promise of you giving it your complete attention, connecting every bit of data you own, paying whatever it costs, and accepting that it can and will change in price and functionality at random, all while never putting a precise timeline on whatever AGI means that particular week. Whenever you ask for clarity, the AI industry gives you chaff. Whenever you ask when things get better, you’re told it’s both the early days and that AI is the worst it’ll ever be. Even the term “artificial intelligence” is a bad faith attempt to conflate transformer models with things like robotics or autonomous cars, all so that its proponents can claim other people’s successes as their own despite LLMs having little or no relevance to anything else other than generative AI. It encourages dogpiling and ostracizing those who don’t fall behind it, because it cannot succeed on its own merits. It encourages a vile cultism powered too by bad faith and parasocial relationships with both AI CEOs and the models themselves. It exploits the intellectual weaknesses of “smart people” that are actually just good at remembering the right things to say at the right time and have memorized the various justifications for past failures, all while allowing them to use LLMs to promote their own bad faith enterprises where they use work-adjacent product to con others into paying them. And it’s losing because, at its core, AI was never built on very much. It grew this large because the media manufactured consent at the behest of the powerful because lots of money got invested, and the rich and powerful can never be wrong. The underlying technology may be more useful than it was , but it’s not useful enough to be profitable nor reliable enough to be world-changing , and the bad faith representation of LLMs as “good enough” should be a permanent scarlet letter on anyone who misled the public into believing this was anything other than normal software. I was asked recently why I find this all so repugnant, and my answer is simple: I don’t like bullies, I don’t like con artists, and I don’t like being lied to. This industry grew by misleading people about the actual and potential outcomes from Large Language Models, and through an economy-wide attempt to pressure everybody into adopting tools in pursuit of growth at all costs.   Ultimately, it was sold with the greatest lie of all: “this time it’s different!” To be clear, they’re right.  It’s so much weirder, and in the end will be so much worse.  If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year , $17 a quarter , or $7 a month , and in return you get a weekly newsletter that’s usually anywhere from 10,000 to 18,000 words and provides vast, detailed analyses of the biggest events and companies in the AI bubble. If you want to get in touch — and especially if you have any juicy information about Anthropic, OpenAI, or any other companies in the AI bubble — hit me up on Signal at ezitron.76. I’m also on IB on The Terminal. Anthropic and OpenAI don’t have the money to pay for the capacity. Hyperscalers and neoclouds fail to build the capacity for Anthropic and OpenAI to expand into. Anthropic and OpenAI lack the actual compute demand to justify spending what I estimate will be $200 billion in 2027. OpenAI and Anthropic must keep spending as a means of justifying their existence to hyperscalers using their revenues to artificially inflate growth, to the tune of more than $440 billion across Google, Microsoft and Amazon alone . Hyperscalers must continue to buy NVIDIA GPUs, as the moment they stop doing so, the markets will begin to ask whether AI is an actual growth market anymore and ask for real, tangible answers about where all of this capex is going.  To be specific, analysts expect NVIDIA to make $1.48 trillion in revenue across Fiscal Years 2027, 2028 and 2029 . NVIDIA must sign long-term agreements to buy high-bandwidth memory at scale from SK Hynix, Micron and Samsung — who make 90% of all DRAM — or know its costs would spiral out of control, by which I mean its margins would compress at random at a time when it’s already having to spike demand in extremely odd ways.  Read my Hater’s Guide To The Memory Crisis for more.

0 views
Unsung Yesterday

Two previews for the price of one

A thoughtful moment in the Arrange Displays pop-up in macOS’s Settings when you choose to designate a screen to be a primary screen: It not only shows a nice preview of where your menu is going to land, but also changes the shape of the menu proxy you’re holding , to help you connect the two. (The whole interaction is probably obsolete, though – if I remember correctly, it used to be that you could only have a menu on one designated screen. Today, the menu is replicated on all screens.) #above and beyond #mouse #preview

0 views
Unsung Yesterday

Mark MacKay’s explainers

If you haven’t played Kern Type yet, you’re in for a treat – released by Mark MacKay in 2011, it’s a delightful browser game that teaches you the art and the math of text kerning: If you have played it, you’re still in for a treat, as MacKay under the Method of Action label released a few similar games since: They’re interesting not just because you can explore the feel of visual, typographical, and color craft by play – but also because they’re also really nicely made explainers. Here, you can learn things, but also learn about making things that teach things. For example, I liked the thoughtful onboarding, animations, and sound design of The Boolean Game, the keyboard navigation in Kern Type, and this general idea present in a few games that it’s fun to learn by fixing slightly broken things, rather than starting from scratch. As far as I can tell, MacKay also occasionally revisits the older games, so Kern Type today might feel much better than when you played it last. MacKay also vibecoded a quick aspect ratio game , and is thinking of a new game to teach text editing, which excites me to no end. (I added a new tag to Unsung, #explainer , to cover explainers and playgrounds like these.) #above and beyond #colors #explainer #graphics #text editing #typography The Boolean Game (2019) The Bézier Game (2014) Color: A Color Matching Game (2012) ShapeType: A Letter Shaping Game (2011)

0 views

Forgejo hack: How to set a starting issue and pull request number

I'm currently working on migrating my open source projects from GitHub to a self-hosted Forgejo instance. As part of this effort I often end up looking through the Forgejo source code to figure out if there are hidden ways to configure certain things to my liking when I can't do it on the administration UI. I thought I'd start putting my discoveries in writing here, in case they can help others. So here goes the first one. One of the aspects of the migration that is tricky is how to transition issues and pull requests. What makes the most sense to me is to only use Forgejo to track issues and pull requests going forward, leaving all the issues and pull requests created up to the migration point on GitHub. Of course whether this is a good or bad idea is debatable, but considering all the options I have decided that this is the solution that is going to inflict the least pain on me. The one problem with this approach is that I would end up having duplicate issue numbers, because Forgejo would start creating issues and pull requests all the way back from , and all those low numbers have been used on the GitHub side. So I wanted to hack my Forgejo instance so that issues start from, say, 10000. That way when anyone references an issue by its number I would know that numbers below 10000 are on GitHub and only those above are on my own instance.

0 views

The LogDrive: Flexible Composition Through Abstraction in Shared Logs

In July, several Confluent colleagues and I published The LogDrive: Composable Durability for Cloud-Based Shared Logs . The paper evolves the concepts of Virtual Consensus in Delos by decomposing the Loglet abstraction into AtomicLog and LogDrive, moving composition below sequencing to a new durability abstraction. This post describes these new abstractions in the context of Virtual Consensus, focusing on how they support RAID-like composability for shared logs. The ideas of the paper came out of a research project led by Mahesh Balakrishnan, Gardner Vickers, and Lucas Bradstreet. The project itself was to build a Kafka-on-S3 service to run in Confluent Cloud and the project ultimately became K2 or Kora 2, the next evolution of the Kora engine (which powers Confluent Cloud’s Kafka service). The first product built on K2 was Freight Clusters (Kafka on S3). The research that led to the LogDrive paper originated in Conflux, the scalable metadata service in K2 which acts as sequencer and metadata database for the fleet of leaderless brokers, akin to WarpStream’s agents. Fig 1. Leaderless broker fleet writes Kafka batches to S3, with Conflux shards as sequencers and metadata databases for S3-stored Kafka data. Conflux is a multi-master state-machine replication service built over a shared log based on Virtual Consensus which uses cloud services such as S3 and DynamoDB as the backing storage service. But this post isn’t about K2, nor even Conflux, its about extending the shared log protocol Virtual Consensus for better composability, specifically, being able to use RAID-like semantics to build logs with striping and quorums over diverse backing storage without having to rewrite the stack. I recommend reading my previous posts on Virtual Consensus to better understand this post: An Introduction to Virtual Consensus in Delos   Steady on! Separating Failure-Free Ordering from Fault-Tolerant Consensus But in any case, I will do a quick recap to set the scene for describing the new abstractions introduced by the LogDrive paper. Traditional replicated-log protocols tend to combine sequencing, durable storage, failure handling, and membership changes. Virtual Consensus separates these responsibilities between a VirtualLog and a sequence of Loglets. Fig 2. VirtualLog abstracts the log as a whole, with a virtual address space. Each Loglet abstracts a log segment, with one active segment. The VirtualLog exposes one logical address space over a chain of independent Loglets. One Loglet is active, while its predecessors are sealed. The active Loglet provides the steady-state data path: it accepts appends and establishes a durable order within a fixed configuration—failure-free ordering. Basically the happy steady state where everything is running fine. The VirtualLog provides the control plane. When the active Loglet experiences a failure and must be replaced, the VirtualLog seals it, records its final tail, and extends the chain with a new Loglet. Fig 3. When a Loglet must be replaced, it is sealed, a new active Loglet added and the log metadata committed. Virtual Consensus separates the protocol into failure-free ordering (Loglet) and fault-tolerant consensus (VirtualLog). A Loglet does not need to implement recovery from partial failure, such as leader elections or membership changes. In that sense, it can be much simpler to implement than Raft. It only needs to order entries with a fixed configuration and provide fault-tolerant and operations so that the VirtualLog can terminate the segment safely. Fig 4. Reconfiguration moves the system from one steady state configuration to another in response to failures, policy triggers or other factors such as load balancing. There is a limitation to the Loglet abstraction when it comes to Loglet composition. By composition I mean building Loglets that are composed of other Loglets. For example, building a generic QuorumLoglet over a set of child Loglets, or a StripingLoglet that stripes writes across a set of child Loglets. The fundamental write operation of the Loglet is . An append both assigns a position and stores the value . Striping works despite this coupling of sequencing with storage. A StripedLoglet routes each to one child Loglet and translates the returned child address into its own address space. This works provided that each child allocates contiguous addresses (for address translation between child and parent address space). Fig 5. StripedLoglet But while can work for striping, it does not compose cleanly for a QuorumLoglet. A parent can forward an append to several child Loglets, but each child independently assigns the address. Partial failures and retries may place corresponding values at different addresses across the child Loglets, creating divergence. An external sequencer could assign positions first, but the Loglet API has no operation for storing a value at a caller-selected address (it only has ). The parent would have to ignore the children’s ordering and somehow add its own sequencing and reordering machinery. Doesn’t sound like much fun. In Delos, quorum replication was therefore implemented inside the NativeLoglet. The NativeLoglet consists of a sequencer and a set of Log Servers. The sequencer assigns an address to each append and then writes the value at that address to a quorum of Log Servers. Crucially, the Log Servers expose , not Fig 6. The NativeLoglet, a quorum-replicated Loglet. Loglet composition via is the problem. This now brings us to the new abstractions: AtomicLog and LogDrive. Fig 7. The Loglet is decomposed into the AtomicLog and LogDrive abstractions. The AtomicLog together with the LogDrive is an implementation of the Loglet API. From the VirtualLog’s perspective, AtomicLog is simply another Loglet: it supports , , , and , and it can be replaced through the normal Virtual Consensus reconfiguration mechanism. The further decomposition of the Loglet is as follows: The AtomicLog is responsible for sequencing and general log semantics but delegates durability. Sequencing/addressing is achieved via a soft-state sequencer (which we can consider is part of the AtomicLog). The LogDrive (sitting below the AtomicLog) is concerned with durability rather than sequencing. It exposes a flat numbered address space of durable single-value registers together with , an operation that lets AtomicLog reconstruct the tail from backing storage after the sequencer has disappeared.  Composition into stripes and quorums exists at the LogDrive level, below sequencing . That is, composition is via the LogDrive API, not the AtomicLog (Loglet) API. Fig 8. Depicts the AtomicLog and LogDrive abstractions in two Conflux instances The LogDrive API does not include append, as composition requires writes to use caller-defined addresses: An AtomicLog append consists of a three step process: Acquire the next free slot from the sequencer (the slot is the address) Write the append value to the acquired address via the LogDrive Complete the slot The sequencer is essentially a map of: address -> {FREE, ACQUIRED, COMPLETED}, though the sequencer uses the term slot instead of address.  Multiple addresses can be written concurrently using a windowed write discipline: the sequencer permits up to (K) appends to be in flight ahead of the contiguous log tail T. The contiguous tail is the first unwritten address and the non-contiguous tail is the lowest unwritten address after which all addresses are unwritten (or alternatively the last written address + 1). Fig 9. A snapshot of sequencer state compared to LogDrive state On a completeSlot(slot) call, the sequencer blocks until all prior slots are also completed. In the figure above, we see that the window of four addresses which is being written to concurrently has holes in addresses 3 and 5. The LogDrive writes for 4 and 6 can finish out of order but their sequencer calls cannot complete until all preceding slots have completed. Only once address 3 has been written to and completeSlot(3) is called, can address 4 complete and the contiguous tail advance to slot 5. So while writes to the LogDrive can complete out-of-order, the appends at the AtomicLog are strictly completed in address order. In this post we’re going to ignore how comes into play, we’ll look at that in a subsequent post. When a Loglet is unsealed, simply asks the sequencer what the tail is. This is the fast-path as the sequencer keeps all its state in memory. Should the sequencer become unavailable, then the AtomicLog can only discover the tail by inspecting log storage (slow-path). The LogDrive offers the command for this purpose. Fig 10. Fast and slow path checkTail While the AtomicLog checkTail returns a scalar contiguous tail (T) address, the LogDrive weakTail returns: N : the non-contiguous tail (first unwritten address after which all addresses are unwritten, or alternatively, the highest written address + 1) H : The holeset, the unwritten addresses within the write window. As seen in Fig 9, the write window can create a Swiss cheese of holes at the tail of the log. The weakTail result implicitly describes the state of the write window. The write discipline maintains . Therefore, every hole lies in the address range , while all addresses below that range are guaranteed to be written. The following can be computed from a weakTail result:  Addr written == Addr unwritten == The window provides concurrency while bounding the number of holes that incomplete or slow writes can create. Limiting the window size allows the tail to be recovered or checked efficiently by examining at most the last addresses rather than scanning an unbounded address space.  It’s worth noting that the sequencer’s view and the backing storage’s view of the contiguous tail regularly diverge. From the example earlier, once address 3 is written, if you call weakTail on the LogDrive, it will return thus . However, until is called, the sequencer sees . This has correctness implications. For this reason, the slow-path is only used once the AtomicLog is sealed (via a linearizable register). Thus once the slow-path has been invoked once, the fast-path will never be invoked again (avoiding diverging results between callers of fast and slow path). Why does the LogDrive weakTail return instead of simply ? And why is it called a weak tail? We cover the former in this post (it's needed for LogDrive composition) and the latter in the next post (it’s about weak semantics). There are three main types of LogDrive: Primitive LogDrive : A thin interface over remote storage, such as a cloud database, KV store or object storage. For example, one might implement a DynamoDBLogDrive, or an S3LogDrive, which are thin shims. StripedLogDrive : A log drive with a set of child log drives where each child is a stripe. Maps addresses to stripes and performs address translation between its own address space and that of its children. QuorumLogDrive : Also has a set of child log drives. Each read, write, weakTail is a quorum operation over its child logdrives. Fig 11. Singleton primitive LogDrive, StripedLogDrive over primitives, QuorumLogDrive over primitives. Striped and Quorum LogDrives call the LogDrive API of their children—the LogDrive API is the compositional interface. So we can compose LogDrives arbitrarily: quorums over stripes over primitives, or stripes over quorums over primitives and even over heterogenous primitives. The base of the tree must ultimately consist of primitive implementations. Fig 12. The root LogDrive is a QuorumLogDrive over three regions, where each region is striped across two DynamoDB tables. A call to in the root LogDrive will flow down as calls to in child LogDrives, according to the type LogDrive. For example, with a StripedLogDrive of 3 child PrimitiveLogDrives, any given read/write call is mapped to a read/write call of the correct child LogDrive, with address translation between the parent address space and the child address space, both of which are always contiguous. Fig 13. Depicts the routing of writes and the mapping of the root LogDrive address space to its children. A QuorumLogDrive forwards to its child LogDrives and waits for a write quorum (Qw). Flexible quorums apply here, where the read-quorum (Qr) is computed as . So if , , then the . If , , then . Because the parent supplies a , every child receives the same value for the same address. Partial success can leave an address unwritten on some children, but it cannot cause their logical address assignments to diverge as independent child append calls can. The Loglet API command returns , the contiguous tail (plus a boolean whether the Loglet is sealed). However, this is not enough for quorum composition. A single scalar value per child tail does not provide enough information for a QuorumLogDrive to compute its tail value. The write window of each child LogDrive may individually resemble Swiss cheese of holes but when unioned together form a contiguous slice of quorum-written addresses. Fig 14. Swiss cheese individually, but globally contiguous quorum-written A scalar child tail is insufficient because it loses information about writes above the child’s first hole. For example: Fig 15. Left and write return the same child T values, but correspond to different global T value. Each child may have a different pattern of holes within its write window, and the QuorumLogDrive must determine the global status of each address based on the richer N, H result of its children. The specific algorithm that the QuorumLogDrive uses to merge the weakTail results of its children into its own combined weakTail is detailed in the paper and also in my TLA+ specification . One motivation behind this work was to make it easier and faster to adapt to changing cloud services and, just as importantly, changing cloud service pricing. A Primitive LogDrive is intended to be a thin adapter over some backing storage service such as DynamoDB, S3, or a KV store. Because it only needs to implement the small LogDrive API, a new primitive can be relatively simple, on the order of a few hundred lines of code rather than a new shared-log implementation. This lowers the cost of adopting a new storage service. If a cloud provider introduces a cheaper, faster, or otherwise more suitable storage primitive, supporting it does not require reimplementing sequencing, replication, striping, or the rest of the shared-log stack. Striping and quorum replication live in generic StripedLogDrive and QuorumLogDrive implementations. These operate over the LogDrive API and therefore do not care whether their children are backed by DynamoDB, S3, S3 Express One Zone, or something else. The same composition machinery can therefore be reused over different primitives and nested arbitrarily: quorums over stripes, stripes over quorums, and even compositions involving heterogeneous backing stores. As long as a Primitive LogDrive satisfies the LogDrive API, it can participate in these higher-level compositions without those layers needing to know anything about the underlying storage service. Virtual Consensus adds another useful property: different Loglets in the same VirtualLog can use different LogDrive configurations. A log might initially use an AtomicLog backed by a singleton DynamoDBLogDrive. A later reconfiguration could extend the VirtualLog with a new AtomicLog backed by a QuorumLogDrive over several S3 Express One Zone LogDrives, perhaps spread across availability zones or regions. The old configuration remains responsible for its existing segment while new appends move to the new one, and the old segment can eventually age out as the log prefix is trimmed. The combination is powerful: LogDrive provides a way to construct different durability configurations from reusable building blocks, while Virtual Consensus provides a way to transition between those configurations over time. This makes the storage layer adaptable to changes in cloud services, performance characteristics, failure requirements, and pricing without having to rewrite the shared-log stack. You might be thinking that you’ve seen all these patterns before and there’s nothing groundbreaking here, and in some ways you’d be right. But what the paper contributes are the formalized abstractions . Murat Demirbas just wrote a great piece on Modularity abstraction versus Modeling abstraction where he compares and contrasts abstraction in terms of modularity and abstraction in terms of reducing something to its very core behavior. A key heading in that post was titled: Modularity abstraction hides. Modeling abstraction reduces . Dominik Tournow recently tweeted something along similar lines about modeling abstraction: “ Systems design is the process of reduction: reduce a problem and its solution to their very essence. When you've found the right abstraction, there are no transformations, no translations, no mappings, no workarounds. “ I think this is a useful lense through which to view the LogDrive paper. Having worked on Apache Pulsar and Apache BookKeeper, I can tell you that BookKeeper has both striping and quorums built in. But what it doesn’t have is a set of formalized abstractions that allow for arbitrary composition based on composable building blocks over a diverse set of backing storage that the AtomicLog and LogDrive give you. BookKeeper is akin to the NativeLoglet. The contribution of LogDrive is instead the abstraction: reducing durability to a numbered collection of single-value registers plus , while moving sequencing above it into AtomicLog. The interesting part is that the weaker abstraction is the more composable one. By reducing durability to its essential behavior, LogDrive provides a better building block for constructing shared logs. An Introduction to Virtual Consensus in Delos   Steady on! Separating Failure-Free Ordering from Fault-Tolerant Consensus The AtomicLog is responsible for sequencing and general log semantics but delegates durability. Sequencing/addressing is achieved via a soft-state sequencer (which we can consider is part of the AtomicLog). The LogDrive (sitting below the AtomicLog) is concerned with durability rather than sequencing. It exposes a flat numbered address space of durable single-value registers together with , an operation that lets AtomicLog reconstruct the tail from backing storage after the sequencer has disappeared.  Acquire the next free slot from the sequencer (the slot is the address) Write the append value to the acquired address via the LogDrive Complete the slot N : the non-contiguous tail (first unwritten address after which all addresses are unwritten, or alternatively, the highest written address + 1) H : The holeset, the unwritten addresses within the write window. Addr written == Addr unwritten == Primitive LogDrive : A thin interface over remote storage, such as a cloud database, KV store or object storage. For example, one might implement a DynamoDBLogDrive, or an S3LogDrive, which are thin shims. StripedLogDrive : A log drive with a set of child log drives where each child is a stripe. Maps addresses to stripes and performs address translation between its own address space and that of its children. QuorumLogDrive : Also has a set of child log drives. Each read, write, weakTail is a quorum operation over its child logdrives.

0 views

Vector Value Prediction with Element-wise Stride Compression

Vector Value Prediction with Element-wise Stride Compression Yanmeng Huang, Ling Yang, Yuanhu Cheng, Junhui Wang, Quan Deng, Junbo Tie, Yongwen Wang, Hai Zhong, and Libo Huang GLSVLSI'26 This paper makes an astute observation: the contents of vector registers are losslessly compressible. There are many hardware and architectural optimizations that can be derived from this fact. This paper presents one: prediction of vector register values. The point of value prediction is to expose more parallelism to a modern processor, so that more instructions can be executed in parallel. Much like branch prediction, value prediction speculatively breaks dependencies to allow the processor backend to process a less-constrained set of instructions. If the predicted value ends up being wrong, then the processor must throw away some work and start over. One way to implement value prediction is much like branch prediction, using the PC and branch history as the index into a table which contains a predicted value and a level of confidence that the predicted value is correct. This paper describes such a technique. SIMD instructions are an orthogonal way to expose more parallelism to a processor backend. Since value prediction and SIMD are orthogonal, why not combine them? Two reasons: The predictor must predict the values of all lanes of a vector register. If any one lane is a bad apple, it spoils the bunch. The data structures needed to make accurate vector-wide predictions would consume a lot of on-chip memory (storage would grow linearly with vector width) The core idea of this paper is illustrated in Fig. 1: Source: https://dl.acm.org/doi/full/10.1145/3787109.3815244 The left side of the figure shows raw (uncompressed) vector registers with varying element widths. The right side shows compressed versions. The gray rectangle represents the value stored in lane 0 (no compression). The orange rectangles hold the differences (i.e., strides ) between neighboring elements. The magnitude of a stride is typically small, so strides are stored with only a few bits per stride. Here is a concrete example: The key point here is that the base + strides representation consumes fewer bits than the raw representation. If the values in a particular register cannot be represented with the base + strides representation, then those values are not considered candidates for value prediction. Fig. 6 shows IPC improvements provided by vector value prediction across a set of benchmarks: Source: https://dl.acm.org/doi/full/10.1145/3787109.3815244 Dangling Pointers I didn’t see specific handling for floating point values in the paper. I wonder if a dedicated compression scheme for those types is warranted. Thanks for reading Dangling Pointers! Subscribe for free to receive new posts. The predictor must predict the values of all lanes of a vector register. If any one lane is a bad apple, it spoils the bunch. The data structures needed to make accurate vector-wide predictions would consume a lot of on-chip memory (storage would grow linearly with vector width)

0 views
Herman's blog Yesterday

Extending life perception

I write about journaling a lot , since it’s honestly my most important practice. In my most recent post on the subject I made the case that active recall is an effective way to remember things, whether that be ideas, thoughts, or events. I'd like to expand on that post and make the case that journaling extends life perception. To wax philosophical for a moment: long life perception and long lifespan are, when it comes down to it, effectively the same thing. If we live in the infinite now , then the only thing separating an actual long life from the perception of a long life is perception . This intuitively makes sense, and you've likely experienced this yourself. Years that are filled with novelty tend to feel longer and are more memorable than years of consistently similar days. It's partly why time feels so much longer as a child, since all experiences are fairly novel and there's explicit progression though the different phases of school, which stands in stark contrast to, say, a few years of working the same job and rarely taking vacation or trying anything new. Those few years can easily condense into a handful of memories, and so the perception of those years is fairly short. Regularly in conversation the person I'm talking to will say something along the lines of "Wow, it's August already!? Time flies.". I rarely share this sentiment (with the exception of the pandemic, where all my days effectively became one), and I ascribe this to two main reasons: The first reason is that I try to do new things as much as possible. Just last night I played ultimate frisbee for the first time on the beach at sunset with a good friend and his crew of (really athletic) frisbros. I was pretty bad at the game and fumbled the frisbee too many times, but after the beautiful sunset and a dip in the cold ocean to clear off the sand I felt great, and I'll likely remember this experience as it punctuated normal life. The second reason, and this is the underlying point I'm trying to make with this post, is that I write about my day while journaling, and in-so-doing remember it better. And since I remember these experiences it doesn't feel like time is slipping away from me. Instead it feels like time is rich and full. Yes, it's August, but I feel like it's been 2026 forever. The research on active recall improving memory is clear. The research on life perception is less clear, but intuitively it makes sense that remembering more of your life will make it feel longer and hopefully richer. There are many reasons to journal, but I feel this is a lesser discussed effect of journaling, and one I'm only starting to appreciate now.

0 views
Stratechery Yesterday

Netflix to Sell Streaming Services?, Streamers as Aggregators, Revisiting Roku

Netflix is considering selling other streaming services, and I think it's a good idea; it's also a let-down for Netflix's original goals and potential pivots.

0 views
iDiallo Yesterday

Foot Guns for Sale

I don't think it's going to work out the way everybody thinks it will. The current narrative, at least the one pushed by the companies selling the shovels, is that AI will become centralized. Anthropic and OpenAI will offer safe, vetted AI. Developers will become mere prompt-engineers, submitting requests to these benevolent gatekeepers. They have tamed the dragon. We will benefit only if we become tenants to their API-driven fiefdoms, paying by the token for the privilege of renting intelligence. “They didn’t care that they’d seen it work in practice because they already knew it couldn’t work in theory” - Clay Shirky I complain about AI frequently on this blog, but not because I don’t think it is useful. I use it quite frequently on my day to day. But what I hate is hype and fake narratives. In fact, I believe that the opposite of their narrative will come true. Technology will continue to improve whether Moore’s Law becomes a relic of the past or not. It’s been called dead, yet CPUs and GPUs are becoming faster than ever. I do not believe for one second that developers with pre-LLM experience will end up on the losing side. And if technology continues to improve, then we won’t need OpenAI or Antropic in the future. We will be able to load large open models right into our powerful personal computers with more than acceptable inference speeds. Unless you believe that computers have reached their zeniths and it is all stagnation going forward. The gap between frontier models and open-source alternatives is already all about specialty, and it will continue to narrow. And when developers ubiquitously have access to local models, they will have access to everything. Right now, companies are hoping that developers will use their AI and remain within their ecosystems. They're building guardrails, imposing limits, and designing their models to serve corporate interests first. They see developers as customers, not as threats to their business model. But I’ve seen how easy it is to switch from one frontier model to the next. In fact, some developers in my team accidentally switched by selecting the “auto” mode on their IDE. They didn’t realise that every subsequent request was from a different model. It’s the developer who will end up benefiting from this far more than the corporations will. One developer recently spent his evenings using an AI agent to reverse engineer every peripheral within arm's reach. From those devices, I’ve come away with a full plaintext command shell inside my microphone, a webcam whose activity LED I can switch off while it records, and a key light that hands out memory writes to anyone on the WiFi. He documented the entire process, implemented his own firmware update utilities, and completely enumerated the functionality of devices that were never designed to be user-serviceable. AI gave him the ability to fully control hardware that he has paid for in his own terms. Another developer created OpenLogi , a local-first alternative to Logitech’s software used to remap your own mouse button. The manufacturer was forcing users to create an online account to have access to the hardware they had paid for. OpenLogi gives full control back to the user. This is what happens when developers have the tools and the motivation to bypass corporate control. And AI is about to make this kind of reverse engineering and alternative-building dramatically more accessible. At the speed of large language models, an activist could create a brand new rotating messaging platform every week to avoid the prying eyes of an oppressive government. Someone else can review his own model and add some self improving features. In fact, you could explore new AI paradigms. Most developers I know have a side project they don't have time to work on. With AI, they will have the ability to execute on those ideas. These days, I'm able to run Deepseek on my own $400 local machine at a much slower speed, but I'm not in a hurry. Give it a couple years, I could run something even more powerful. I don't need a project management tool where I have to pay monthly. My actual needs are much simpler. For example, I actually like Jira, despite how much I complain about it on this blog. But I don't need to have Jira for myself on my personal projects. I can build a tool that works solely for my needs. I can easily build applications in environments I am not too familiar with but that are more appropriate for the task. I can build prototypes in a couple hours now and throw them away if they don't match my initial expectation. I can do so much more. Dario Amodei and others are trying to scare us with the capability of AI. They sell the fear of superintelligent systems that will render human developers obsolete or dependent. But this is not what's going to happen. What's going to happen is we will not need Anthropic anymore. Yes, they will have the high-end hardware. But we don't need high-end hardware the same way most people did not need a professional camera. All they needed was a crappy camera with a good filter to post on Instagram. Flickr was superior to Instagram, but the superior technology lost to the one that was "good enough" and in everyone's hands. The funny thing in all this is that by making everything AI-dependent, by building their moats and their guardrails and their API toll booths, companies like OpenAI and Anthropic are selling foot guns. They are building the dark fibers of our era, the infrastructure that developers will eventually subvert, repurpose or simply bypass. Because eventually, we won’t ask for permission. We can just do whatever we want with tools freely available to anyone. We own our devices. We own our data. And soon, we'll own the intelligence on our own terms, without a subscription fee and without a corporate overlord. At the very least, we will get free GPUs .

0 views

Ironman Training Diary - August 25, 2026: Four Miles in Dublin

Today's four mile run, with Apollo's analysis

0 views