The article also mentions that typestates can be cumbersome:
> Typestate improves code faultlessness and testability, but comes at the cost of more boilerplate code and can degrade readability.
I have noticed this in my own code. `Ticket` with an internal variable tracking the state makes using it simpler. I just have to store one object in my struct `struct MyData { ticket: Ticket }` and call `ticket` methods in the correct order.
Typestate `Ticket<T>` is not as simple. I have to wrap it in my own enum: `enum TicketState { Ticket1(Ticket<Func1Done>), Ticket2(Ticket<Func2Done>), }` to store in my struct: `struct MyData { ticket: TicketState }`. Then every time I call `ticket` methods, I must extract the correct variant value first. That degrades readability and creates extra run-time cost.
Rumors say that Apple will only release M6 base variant and skips M6 Pro, M6 Max and M6 Ultra variants to concentrate all efforts to create a good AI capable M7:
"According to reports from Bloomberg, Apple will be skipping its M6 Pro, M6 Max, and M6 Ultra chips to accelerate development of the M7 chip. That means the only chip to be released from the M6 family will be the base M6.
The reason for this break with tradition: AI. Apple had been planning major neural-processing upgrades for the M7 family and ultimately decided those improvements were important enough to justify accelerating the next generation rather than completing the M6 lineup." https://9to5mac.com/2026/08/08/apple-m7-chip-heres-why-it-ma...
I'd skip M5 and M6 chips for LLM work and wait for a year for M7.
I wonder when/if we will start to see Apple include a silicon encoded model into their chips. Similar to Taalas build Llama 3.1 silicon with 17,000 tok/s inference.
So could the M7 actually include an AFM 3B model, alongside a generic neural engine?
It would make zero sense. These things are improving by leaps and bounds every week, we are not at the point where you can burn weights into silicon and put it on one of the largest consumer devices on the planet yet.
On the other hand, models these days are getting to the point where even if all development halted permanently, they would continue to be useful long into the future. (At least until their knowledge base or linguistics become too outdated.)
I cant shake the feeling of "640KB is enough for everybody". Imagine not one AI answering over 1 minute but a team of 100+ agents in hieararchical structure taking care of your request in seconds, checking each other.
Apple's biggest bottleneck for real-world inference is prefill processing. They need a better GPGPU architecture, which is what I'm expecting M7 to reveal.
Agreed, seems like the M5 has already made steps in that direction, with 4x prompt processing / prefill performance vs. M4. [1] And token generation also got a 10% boost. The data below is only for Pro & Max but I think the base M5 got the same relative boosts vs. M4 base.
Chip BW (GB/s) GPU Cores Q4_0 Prompt Q4_0 Gen
M4 Pro (20c) 273 20 439.78 50.74
M4 Max (40c) 546 40 885.68 83.06
M5 Pro (20c) 307 20 ~1500 to 1700 ~56
M5 Max (40c) 614 40 ~3000 to 3500 ~92
The M5 GPU added better matmul and dot product support in hardware (IIRC) that really boosted performance of those kernels over previous GPUs. Current transformer models rely heavily on matmuls. Prefill (processing the current context) is mostly limited by raw GPU processing power where token generation (predicting the next token from the current context) is mostly limited by memory bandwidth.
While an older M-series might run a matmul or dot product kernel just fine the M5 can run them much faster.
The Apple chips are quick when the model is "warm" on your second and subsequent requests. It's also quick if you don't have a harness, and feed "Hi, how are you?" as a prompt. However, a lot of common usage is to have a harness with lots of instructions and context. Loading that context is slow. So, the first response may take ~1 minute to return the first token (varies widely by hardware, model, etc.).
Look at the "Q4_0 Prompt" column. That's the tokens-per-second processing the initial prompt/system prompt. This is where the "neural accelerators inside each GPU core" is seen most prominently.
i sold my m3 ultra /512 for £14000, or about $18000. The difference is what is important to me for a new one, and assuming $6k or so for the 256->512 boost, my cost will be about $16k, so i’ll save $2k by upgrading to the top-of-the-range model, bar it being a 4TB drive
Their chip release cycle doesn't make any sense to me. Compared to their other hardware like iPhones or Apple Watches they just release a new chip when they feel like it. It might have a pro, ultra, or max version, or it might not. Sometimes that better version only releases when the next generation of the silicon is already out. I think that they really need some structure in their releases.
The phones are watches are primarily sold on annual leases through carriers. And no one is buying them for the chips, it's all camera and form factor.
The macs, on the other hand, can more easily swap between chips in manufacturing. And the form factor is pretty static. So Apple, in a race to have the best chip in the field at any given time, is just releasing them as soon as they're ready.
I agree the whole "m5 max > m6" is confusing, but I think they figure only the nerds who learn the specifics are going to care anyway.
Apple has a dedicated "neural engine" which is designed as an inference NPU. Where as Google's TPU has a dual focus, both inference and training, which is a more complex design.
> I'd skip M5 and M6 chips for LLM work and wait for a year for M7.
Another note on this, it's likely the M7 ultra will be released around 6 months after the M7 Max, if the M1 and M5 are taken as reference. So the M7 ultra may be delayed until early 2028.
If you expect a large leap in performance, buying now means that (a) you will want to buy again in a year but (b) the large leap in performance hurts the resale of what you buy today.
Local models will be that much better in a year, so unless you have to have a top-of-the-line local rig today (the argument goes), stick with Claude for another year.
That makes sense. I also think that we are at the point where maybe the expectation of a yearly refresh on everything should be reconsidered. They can end up on a Tick-Tock schedule when the Pro/Max/Ultra can be done every second year.
W3C has been defining SVG Native, but it hasn't progressed much lately — mostly because there hasn't been any interest in it. SVG Native is a small subset of SVG 2.0 which doesn't support scripting, animations or any external references. https://svgwg.org/specs/svg-native/
It isn't only corporate development teams — open source development teams want to spy on their users, too. For instance, Homebrew: "Anonymous analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew." [1]
I can understand running an old 486 machine for nostalgia reasons, or because you have some old industrial equipment that relies on it and even one second spent replacing it is a second too many, but I struggle to imagine why you'd want or need to run a modern Linux kernel on it.
I think that's fair. Funny to have a language that makes it prohibitively difficult to use most of the core computer science constructs (lists, graphs etc.).
Debian Trixie drops 32-bit x86 support. Ubuntu dropped 32-bit support already earlier, which meant that lightweight Lubuntu and Xubuntu don't support it either. It's sad to see old hardware support getting dropped like that. They are still good machines as servers and desktop terminals.
Are there any good Linux distros left with 32-bit x86 support? Do I have to switch to NetBSD?
> They are perfectly good machines as servers and desktop terminals.
On the power usage alone surely an upgrade to a still extremely old 64bit machine would be a significant upgrade. For a server that you run continuously a 20+ year old machine will consume quite a bit.
Indeed. I still keep around a couple of old computers, because they have PCI slots (parallel, not PCIe), unlike any newer computer that I have, and I still use some PCI cards for certain purposes.
However, those computers are not so old as to have 32-bit CPUs, they are only about 10 years old, but that was because I was careful at that time to select MBs that still had PCI slots, in order to be able to retire all older computers.
The only peripherals that truly don't work in more modern boards would be AMR/ACR/CNR? ISA and plain PCI being reasonably easy to acquire expansion boxes (might be a problem for EISA though, I guess...)
> It's sad to see old hardware support getting dropped like that.
The problem is that someone needs to work to support different hardware architectures. More exotic hardware, more complicated and expensive the work becomes.
People who run these 32-bit machines are unlikely to vouch in terms of work contributed or money contributed to get the people paid for this work, so it is better to drop the support and focus the same developer resources on areas which benefits larger user base.
the real problem is Linux is written in such manner that APIs change very often, and code all over the place including drivers is monkeyed without testing and often broken, sometimes in very subtle and hard to debug ways.
It is an overall design issue. Linux has a huge maintenance burden.
Indeed it is. I am not sure if BSD people have better support for legacy hardware. Outside BSD, there is no competition for open source operating systems, or generally legacy PC hardware systems overall as Windows support was dropped long time ago.
The kernel APIs change never and 32bit support is still within the kernel without any issue at all. How does this implicate drivers?
The rest is user space code. Usually in C. Which has plentiful facilities for managing this. We've been doing it for decades. How is it a sudden burden to continue?
Where are the examples of distributions failing because of this "issue?"
The internal kernel API used by device drivers changes at every version, even at minor versions.
If you maintain an out-of-tree driver, it is extremely likely that it will fail to compile at every new kernel release.
The most common reasons are that some definitions have been moved from one kernel header to another or some members have been added to a structure or deleted from it, or some arguments have been added to a function invocation or deleted from it.
While the changes required to fix a broken device driver are typically small, finding which they are can require wasting a lot of time. The reason is that I have never seen any of the kernel developers who make these changes that break unrelated device drivers writing any migration document that instructs the device maintainers how to change the old source code to be compatible with the new interfaces.
Normally there is absolutely no explanation about the purpose of the changes and about what the users of the old API should do. Only in rare cases scanning the kernel mail messages may find some useful information. In other cases you just have to read the kernel source, to discover the intentions of whoever has changed the API.
That does the job eventually, but it consumes far more time than it should.
Even in-tree drivers for old devices, which may no longer have a current maintainer, will become broken eventually.
I have actually upgraded a really old 32 bit only laptop from bookworm to trixie - it works. Two important (for the desktop environment) packages required SSE3 which the CPU doesn't support, so... I installed package "sse3-support" with environment variable IGNORE_ISA=1 set. The kernel was not upgraded because trixie doesn't contain an i386 kernel. The laptop works surprisingly okay, though of course it's not much fun with its weak performance, low RAM and mechanical disk.
32-bit userspace packages are still supported, though with increased hardware requirements compared to Bookworm. You may find that you're able to run a more-or-less complete 32-bit Trixie userspace, while staying on Bookworm wrt. the kernel and perhaps a few critical packages.
If 32-bit support gets dropped altogether (which might happen for 'forky' or 'duke') it can probably move to the unofficial Debian Ports infrastructure, provided that people are willing to keep it up-to-date.
I kept my old 32-bit laptop alive for quite a bit using archlinux32 but in the end more and more software started breaking, so that is not really a route I can recommend anymore. I was using the laptop mainly if I was traveling or on holidays, so not so very often so it felt wasteful to to buy a new one. But this year the software breakages really started costing too much time, so I bought a new one. RIP old laptop (2007-2025).
Alpine still supports x86 and other 32bit platforms. It’s also very lightweight, though I’d say it targets a very different userbase than Debian or Ubuntu — the default install is quite minimal and requires more setup.
Does dropping 32-bit support just mean that there are no supported x86-32 OS images, or that 32-bit applications are generally not supported?
If it means that no 32-bit apps are supported, how does Steam handle this? Does it run 32-bit games in a VM? Is the Steam client itself a 64-bit application these days or still stuck on 32-bits?
Just keep in mind that this does not apply to armhf, which is 32 bits and all old Raspberry Pi boards use.
What's your use case for 32-bit x86 where you are still keeping Debian at its latest version? Alone for the power consumption you might be better off by switching to a newer low-spec machine.
>It's sad to see old hardware support getting dropped like that. They are still good machines as servers and desktop terminals
How many 32 bit PCs are still actively in used at scale to make that argument? Linux devs are now missing kernel regression bugs on 64bit Core 2 Duo hardware because not enough people are using them anymore to catch and report these bugs, and those systems are newer and way more capable for daily driving than 32 bit ones. So then if nobody uses Core 2 Duo machines anymore, how many people do you think are using 32bit Pentium 4/Athlon XP era machines to make that argument?
But let's pretend you're right, and assume there's hoards of Pentium 4 users out there refusing to upgrade for some bizarre reason, and are unhappy they can't run the latest Linux, then using a Pentium 4 with its 80W TDP as a terminal would be an insane waste of energy when that's less capable than some no-name Android table with a 5W ARM SoC which can even play 1080p Youtube while the Pentium 4 cannot even open a modern JS webpage. Even most of the developing world now has more capable mobile devices in their pockets and don't have use for the Pentium 4 machines that have long been landfilled.
And legacy industrial systems still running Pentium 4 HW, are just happy to keep running the same Windows XP/Embedded they came from the factory since those machines are airgapped and don't need to use latest Linux kernel for their purpose.
So sorry, but based on this evidence, your argument is literally complaining for the sake of complaining about problems that nobody outside of retro computing hobbyists have who like using old HW for tinkering with new SW as a challenge. But it's not a real issue for anyone. So what I don't get is the entitled expectations that the SW industry should keep writing new SW for free to keep it working for your long outdated 25+ year old CPU just because you, for some reason, refuse to upgrade to more modern HW that can be had for free.
There are good faith arguments to be had about the state of forced obsolescence in the industry with Microsoft, Apple, etc, but this is not one of them.
>Are there any good Linux distros left with 32-bit x86 support? Do I have to switch to NetBSD?
Yes there are, tonnes: AntiX, Devuan, Damn Small Linux, Tiny Core Linux, etc
> 80W TDP as a desktop terminal would be an insane waste of energy when that's less capable than some no-name Android table with a 5W ARM SoC which can even paly 1080p Youtube while the Pentium 4 cannot
Insane how far hardware got: the pentium 4 engineers probably felt like the smartest people alive and now a pentium 4 looks almost as ridiculous and outdated to us as vacuum tube computers.
What I find truly insane is how we're "wasting" the hardware.
I ran a mailserver for thousands of people on a 486 DX 33Mhz. It had smtp, pop3 and imap. It was more than powerful enough to handle it with ease.
I had a Pentium 3 w/1GB of RAM, and it was a supremely capable laptop.
These days I have a a machine from 2018 or 2019, which I upgraded to 32G of RAM and I added an NVME drive in addition to the spinning rust earlier this year.. because firefox got (extremely, more than a minute to start the browser) sluggish due to an HDD instead of NVME.
Now, it's obvious that an NVME drive is superior, but it surprises me how incredibly lackadaisical we've gotten with resource usage. It surprises me how little "extra" we get, except ads that requires more and more resources. Sure, we've got higher resolution photos, higher resolution videos, and now AI will require vast resources (which of course is cool). At the same time, we don't get that much more utility out of our computers.
>What I find truly insane is how we're "wasting" the hardware.
Only if you ignore the business economic realities of the world we live in. Unless you work at hyperscaleres of MS/google/meta where every fraction of percent optimization save millions of dollars, nobody is pays SW engineers to optimize SW for old consumer devices because it's money wasted you won't recoup so you offload it on the customer to buy better HW. Rinse and repeat.
>I had a Pentium 3 w/1GB of RAM, and it was a supremely capable laptop.
Why isn't it supremely capable anymore? It will still be just as capable if you run the same software from 1999 on it. Or do you expect to run 2025 SW on it?
Chips that old would be on a ~100nm process node, which is ancient. Anything using Flintstone transistors like those isn't going to hold up.
> the pentium 4 engineers probably felt like the smartest people alive
The P4's NetBurst architecture had some very serious issues, so that might not be true. NetBurst assumed that 10GHz clock speeds would soon be a thing, and some of the engineers back then might have had enough insight to guess that this approach was based on an oversimplified view of semiconductor industry trends. The design took a lot of stupid risks, such as the ridiculously long instruction pipeline, and they were always unlikely to pay off.
Did you read the comment I was replying to? They said old 32 bit systems can still be kept around to be used as a terminal. I replied saying that Android tablets can also be used as terminals with the right SW if that's what you're after.
Or if you have specific X86 terminal SW, use a PC with a 64 bit CPU if you want to run modern PC SW. They've been making them since 2003. That's 23 years of used 64bit HW on the market that you can literally get for free at this point.
Or keep using your old 32 bit system to run your old 32 bit terminal SW. Nobody's taking away your ability to run your old 32 bit version of the SW when new 64 bit SW comes out.
> Typestate improves code faultlessness and testability, but comes at the cost of more boilerplate code and can degrade readability.
I have noticed this in my own code. `Ticket` with an internal variable tracking the state makes using it simpler. I just have to store one object in my struct `struct MyData { ticket: Ticket }` and call `ticket` methods in the correct order.
Typestate `Ticket<T>` is not as simple. I have to wrap it in my own enum: `enum TicketState { Ticket1(Ticket<Func1Done>), Ticket2(Ticket<Func2Done>), }` to store in my struct: `struct MyData { ticket: TicketState }`. Then every time I call `ticket` methods, I must extract the correct variant value first. That degrades readability and creates extra run-time cost.