I think armhf CPUs are still being manufactured, and there are still boards like https://www.olimex.com/Products/OLinuXino/Home-Server/Pioneer-FreedomBox-HSK/open-source-hardware being sold. I think their main issue is the amount of RAM and number and frequency of the cores, but I think that's not an armhf issue, more the fact that some software requires more resources than others. On the other hand, those devices pull at most 5W (and idle much lower), and every new generation of RPi has required more power, so as long as what you are doing can be done with the specified resources, then those devices remain quite useful.
James On Sun, 17 Aug 2025 at 06:09, Simon McVittie <s...@debian.org> wrote: > > On Sat, 16 Aug 2025 at 07:28:24 -0500, John Goerzen wrote: > >Without getting into a debate over whether i386 should or should not be > >dropped, as someone that runs other 32-bit archs, I wonder why armhf and > >armel weren't similarly targeted? > > Each of these 32-bit ports has different characteristics and different > tradeoffs. > > i386-without-SSE2 on real 32-bit CPUs (as opposed to i386 as a > compatibility architecture on newer CPUs) is a problematic porting > target because it has non-IEEE floating-point behaviour that frequently > causes trouble: test suites often expect to see the same exact values, > simulations (e.g. networked games) want to see deterministic results > from running the same simulation on different CPUs, and the thing that > finally prompted raising the baseline was that it turned out that it > even harms soundness (ability to generate correct machine code) in > LLVM/rustc. i386-with-SSE2 is a lot easier, because it has the same IEEE > floating point as every other release architecture, but there were only > a few CPU generations that have SSE2 but not 64-bit support (I think the > Pentium 4 around 20 years ago was the most common example). > > armel is also on its way out, because it has a *different* > characteristic that makes it a problematic porting target: unlike every > other release architecture, it doesn't have atomic operations in the > baseline instruction set, and they have to be emulated. For example this > is why mozjs/gjs had to be removed from armel in trixie. I suspect we > would have lost armel already if it wasn't for the fact that it's the > newest/highest-functionality Debian port that will run unmodified on > first-generation Raspberry Pi hardware, because ARMv6 is slightly too > old for official Debian's armhf baseline; Raspberry Pi OS, a Debian > derivative, works around this by recompiling armhf with a lower > baseline. > > armhf has had CPUs that can run it but not its successor manufactured > more recently than i386 or armel, has normal IEEE floating-point unlike > i386, and has normal atomic operations unlike armel, so it is both less > painful to support and more likely to be useful as a "bare metal" OS > when compared with either i386 or armel. > > (I do think that armhf's useful lifetime is limited, too, though.) > > smcv >
