Alpine no longer builds new Java packages for 32-bit platforms, leaving armhf stuck with version 8 of the JRE. MongoDB dropped support for 32-bit platforms with version 4.x which necessitated our forthcoming deprecation of the armhf version of our Unifi Controller container. Nobody wanted to port the fix to the older 32-bit platforms because it just wasn't seen as worth the effort. If you've been with us for a while you're probably aware of the libseccomp issue that affected our 32-bit ARM (armhf) images when Ubuntu Focal was released. Until February this year there was no stable 64-bit release of Raspberry Pi OS and that meant that the majority of people who bought a Pi ended up unwittingly running a 32-bit OS, even though there were plenty of 64-bit alternatives available such as Ubuntu, SUSE, and even Arch. Given all this, why do we still produce armhf images for (almost) all of our containers? The short answer is Raspbian (now Raspberry Pi OS).
Arch linux raspberry pi windows#
It's not just ARM, of course, x86_64 has been the defacto standard for over a decade now and with Windows 11 Microsoft have finally dropped 32-bit support entirely (Windows Server dropped support way back in 2009). At this point it's all but impossible to buy 32-bit-only ARM hardware and consequently things are not looking great for the future of 32-bit computing on ARM. Did you know it's been 11 years since ARMv8 was introduced? And 6 years since the release of the Raspberry Pi 3 Model B, the first mainstream SBC to use it, making 64-bit ARM (aarch64) devices available to just about anyone who wanted one? Well it has.
0 kommentar(er)
