The current state of Linux architecture support

By Daroc Alden
November 18, 2025

There have been several recent announcements about Linux distributions changing the list of architectures they support, or adjusting how they build binaries for some versions of those architectures. Ubuntu introduced architecture variants, Fedora considered dropping support for i686 but reversed course after some pushback, and Debian developers have discussed raising its architecture baseline for the upcoming Debian 14 ("forky"). Linux supports a large number of architectures, and it's not always clear where or by whom they are used. With increasing concerns about diminishing support for legacy architectures, it's a good time to look at the overall state of architecture support on Linux.

Not counted: The designers of Elbrus 2000 CPUs, Tachyum Prodigy CPUs, Kalray KVX CPUs, and Shenwei SW64 CPUs maintain their own non-upstream kernel ports with support for their own architectures.

The 6.17 kernel supports 21 different architectures (perhaps soon to be 22, thanks to the recent WebAssembly port), but making that statement already requires going into a bit more detail on what counts as an architecture. For example, Linux supports the User Mode Linux "architecture", which lets the kernel run as an unprivileged process inside an existing kernel for testing purposes. By most normal definitions, User Mode Linux isn't really a CPU architecture, even if the code for it lives alongside the kernel's other architecture support code. On the other hand, the kernel considers all PowerPC CPUs to be one architecture, regardless of whether they're running in big-endian or little-endian mode; most distributions count those as two architectures because software compiled for different endiannesses must be packaged separately. Even without architecture-wide incompatibilities like that, several architectures also offer different "levels" or optional extensions that make describing a piece of software's requirements a bit difficult. RISC-V has, at the time of writing, 48 different standards adding a larger number of extensions.

Still, the kernel's list of supported architectures is the closest thing to a definitive list of what counts as an architecture in the Linux world. Using that as a baseline, I checked the status of support in several popular distributions. The most restrictive is Arch, which only supports x86_64. Close behind is Fedora, which only has two main architectures and three secondary ones. Debian supports the second-most architectures, with six or seven officially supported architectures and something like 11 unofficial ones, depending on how one counts. Gentoo offers official installers for 13 architectures. Ubuntu is somewhere in between, with five official architectures and a vague suggestion that it may work on Debian's unofficial architectures as well.

The distinction between official and unofficial support is a bit fuzzy. In practice, a lot of software packaged by the different distributions will compile fine on unsupported architectures, provided an appropriate compiler is available. In Debian's case, official support means that it is part of the official release, it has been tested, and it will receive security updates. Unofficial architectures may be released on a delayed schedule, may have to deal with breaking changes, and might be dropped in between major versions if there are no volunteers to keep things working. For Fedora, a primary architecture is one where build failures on Koji, Fedora's package build farm, block the release process. Secondary architectures might also cause build failures on Koji, or might have their own separate package-build infrastructure, but failures don't stop the release.

Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH. The discussion around Rust's architecture support was recently reinvigorated by the fact that Debian's APT packaging tool will require Rust after May 2026. The project offers different tiers of support for various architectures, ranging from tier one (continuously tested and has official releases), through tier two (builds but does not have dedicated tests), to tier three (code is present to handle it, but support isn't being tested automatically).

A well-formatted table is worth a thousand words, so here is one summarizing the current state of architecture support on Linux:

Architecture	Commercially available	In kernel since	Minimum supported in kernel	Debian	Ubuntu	Fedora	Rust
Alpha	1992-2007	1994	EV56+	Unofficial	-	-	-
ARC	1996-	2013	ARC600	-	-	-	-
Arm (32-bit)	1985-	1998	ARMv4	ARMv5 (forky increases this to ARMv7-A+VFPv3D16)	-	-	Tier 2
Arm (64-bit)	2011-	2012	ARMv8-A+	Official	Official	Official	Tier 1
C-SKY	2017-	2018	v1	-	-	-	v2+, Tier 3
Hexagon	2006-	2011	V2+	-	-	-	Tier 3
LoongArch	2021-	2022	N/A	Unofficial	-	-	Tier 2
m68k	1979-	1996	68000+	Unofficial*	-	-	Tier 3
MicroBlaze	2002-	2009	v3.00.a+	-	-	-	-
MIPS	1985-	1995	mips1+	-	-	-	Tier 3
Nios II	2000-2023	2014	r1+	-	-	-	-
OpenRISC	2000-	2011	OR1k	-	-	-	-
PA-RISC	1986-2008	2000	1.1+	Unofficial [edited]	-	-	-
PowerPC (32-bit)	1992-2021	1995	ppc8xx, ppc603, or better	Unofficial, big-endian	-	-	Tier 2
PowerPC (64-bit)	1997-	2002	powerpc970+	Little-endian, officially; big-endian unofficially; version 8 or newer (proposed to raise to 9)	-	Little-endian; version 8 or newer	Tier 2
RISC-V	2014-	2017	It's complicated	Official	Official	Official	Tier 2
s390	1965-	2000	z10+	Official (z196; proposed to raise to z15)	Official	Official	Tier 2
SPARC	1986-	1994	v8+	Unofficial	-	-	Tier 2
SuperH	1992-2025	1999	SH-2 (with no MMU) or SH-3 (with a MMU)	Unofficial	-	-	-
x86 (32-bit)	1985-	1991	i486+	User-space only (i686+)	User-space only	User-space only	Tier 1
x86_64	2003-	2003	All	Official (raising baseline to v2 proposed)	Official (both v2 and v3)	Supported (all versions)	Tier 1
Xtensa	1999-	2005	N/A	-	-	-	Tier 3

Looking at this table, a few things are immediately clear. For one, the Debian project is doing a lot of work to ensure older CPUs remain usable. For another, the only architectures that are supported by Debian but not Rust are Alpha (for which no new CPUs have been produced since 2007), and SuperH. It might be tempting to assume that this means concerns about Rust compatibility are overblown, but it would be more accurate to say that people working with unpopular CPU architectures are probably not using mainstream Linux distributions.

In Arnd Bergman's OSS EU talk this year, he said that some of these architectures, primarily 32-bit Arm, are being kept alive for embedded development. New hardware is still being produced with 32-bit Arm CPUs, so he expects the kernel to support that configuration for at least ten years. The kernel still supports over a dozen 32-bit architectures that are used in older embedded systems, but their 64-bit replacement designs have almost exclusively moved to Arm and RISC-V, he said.

The Linux kernel's support for many architectures is both a strength — allowing it to be deployed in a huge number of possible use cases — and a source of complexity for maintainers. The kernel's memory-management code is particularly prone to architecture-induced special cases. For now, the kernel supports many more architectures than the mainstream distributions that depend on it do. If embedded uses continue to adopt RISC-V, however, that might not be the case in another few decades.

Appendix: Architecture information

RISC-V, SPARC, PowerPC64, and OpenRISC all have actively used open hardware implementations. ARMv2, MIPS II, SH-2, and i486 have also had projects to implement open designs, but these do not appear to be in active use.

Many of the architectures listed above were unfamiliar to me, so it was hard to imagine who might be using them. Below are brief descriptions of each architecture supported by the kernel, for context.

Alpha

Supported by: Debian (unofficially).

Introduced by DEC in 1992, Alpha is a 64-bit RISC architecture. The underlying intellectual property was sold to Compaq in 1998, which didn't do much with it until Hewlett-Packard purchased the company in 2002. The last Alpha-based systems were sold in 2007.

The kernel has supported Alpha since version 1.1.67 in 1994, making it the first non-x86 port. Alpha support is still kept up to date by Richard Henderson and Matt Turner. Debian officially supported Alpha between versions 2.1 and 5.0, and the port is still maintained unofficially.

ARC

Arc processors were first introduced in 1996, although support only reached the kernel in 2013. The kernel only supports 32-bit ARC CPUs; 64-bit support has not made it upstream so far. Work is continuing, though. The primary manufacturer of ARC CPUs, Synopsys, has largely pivoted to RISC-V designs, but ARC CPUs are still available. Support in the kernel is maintained by Vineet Gupta.

Arm

Supported by: Debian, Ubuntu, Fedora.

Arm is a considerably older architecture, dating from 1985. Despite its age, it has continued evolving and specifying different compatibility levels. Debian and Ubuntu both only support it when the CPU has built-in hardware for processing floating point numbers, but, as that is the typical configuration for Arm CPUs outside of embedded development, that doesn't pose any great hardship.

The kernel has supported Arm CPUs since version 2.1.80 in 1998, but the CPU version required has increased over time. Debian currently requires at least "armv7-a+fp": version 7-A, with floating point support. The kernel theoretically still compiles with GCC version 8, which in turns supports Arm version 2, but the kernel has deprecated anything earlier than Arm version 4. That release added support for half-word loads and stores, and removed support for 26-bit addressing.

C-SKY

C-SKY v1 CPUs are compatible with Motorola M·CORE, which have been available since 1997, but the first C-SKY-branded CPUs were released in 2017. C-SKY is the second most recent architecture added to the kernel. It was introduced in 2018, in version 4.20. At the time, Bergman said that it might well be the last architecture ever added to the kernel, since newer designs seem to be focusing on RISC-V, which the kernel already supports. That prediction did not prove to be correct, however, with LoongArch being added to the kernel in 2022. C-SKY is a 32-bit architecture that is not much used outside of China, where it is produced by a company of the same name.

Hexagon

Unlike the other architectures in this list, Hexagon is the architecture of a family of digital signal processors from Qualcomm. First introduced in 2006, support was added to the kernel in 2011, where it is maintained by Brian Cain. Hexagon is notable for having a number of features dedicated to hardware-assisted parallelism.

LoongArch

Supported by: Debian (unofficially).

LoongArch is the newest architecture supported by the kernel, arriving in 2022. It is a RISC architecture quite similar to MIPS, although newer architecture revisions have been adding more custom instructions. The company that created it, Loongson, uses it in high-performance, multi-core servers; its previous lower-power CPUs used MIPS. Kernel support is maintained by Huacai Chen.

m68k

Supported by: Debian (unofficially).

Motorola 68000, usually abbreviated m68k, is a big-endian 16- or 32-bit architecture originally released in 1979. It was discontinued in 1996 — ironically, the same year that support first appeared in the kernel, in version 1.3.94. It is maintained in the kernel by Geert Uytterhoeven. The unofficial Debian port runs on the original m68k CPUs, but not the newer coldfire CPUs.

This architecture is notable for powering several early home computers and portable computing devices, including early Apple Macintoshes, Commodore Amigas, the Atari ST, the Sega Genesis, the AT&T UNIX PC, the NeXTstation, TI-89 calculators, and the Palm Pilot. Because of its extremely wide use, m68k is likely to continue being supported, one way or another, by folks passionate about that era of hardware.

MicroBlaze

MicroBlaze is a CPU core design intended for embedding in a field-programmable gate array. It was introduced in 2002, with support coming to the kernel in 2009. Support in the kernel is maintained by Michal Simek. The kernel has, so far, supported only the 32-bit version of the CPU. 64-bit support exists out-of-tree, but is unlikely to be merged in the future because the company behind MicroBlaze, Xilinx, has moved on to RISC-V designs.

MIPS

MIPS was released in 1985. Since then, it has received regular updates, the most recent of which was version 6 in 2014. Linux has supported it since version 1.1.82 in 1995. Even though the architecture is regularly updated (and the oldest processors for it have fallen out of their patent period), no major Linux distribution maintains a port. The overall maintainer for MIPS in the kernel is Thomas Bogendoerfer, but there are a large number of other maintainers who work on specific chips, drivers, and other components of MIPS support.

Nios II

A 32-bit RISC CPU intended for embedded use in field-programmable gate arrays (FPGAs), Nios II has been supported in the kernel since 2014, where it is maintained by Dinh Nguyen. Intel deprecated the design in 2023 in favor of a RISC-V-based successor. Nios II is interesting because it was implemented entirely in programmable logic, meaning that the CPU could be extended with custom instructions or peripherals that were programmed directly into the same FPGA.

OpenRISC

OpenRISC is a project to develop an open-source CPU; the design of the OpenRISC 1000 CPU is available under a GPL license. It was introduced in 2000, with support in the kernel introduced in 2011. It is maintained by Jonas Bonn, Stefan Kristiansson, and Stafford Horne. The OpenRISC web site has links to three different processor implementations and several simulators that can be used to try out OpenRISC code.

PA-RISC

Supported by: Debian (unofficially).

Also known as HPPA, PA-RISC was released in 1986 as a way for HP to consolidate its different computer offerings on the same CPU design. That sort of happened, although HP continued offering some products based on other designs. Support was added to the kernel in 2000, where it is maintained by James Bottomley and Helge Deller.

PowerPC

Supported by: Debian, Ubuntu, and Fedora.

PowerPC is another architecture that supports running in big-endian or little-endian mode; unlike Alpha, SPARC, or MIPS, however, there is good support for actually running Linux on it in either endianness configuration. The architecture was introduced in 1992, and supported in the kernel since version 1.3.45 in 1995, although that support has moved around between a few different architecture names over time. PowerPC code has gone by "ppc", "ppc64", and "powerpc" at various points in the kernel's history (currently the latter). Presently, support for the architecture is maintained by Madhavan Srinivasan and Michael Ellerman.

Debian supports little-endian 64-bit PowerPC officially, and has two different unofficial ports for 32-bit big-endian PowerPC and 64-bit big-endian PowerPC. The official port seems to require version 8 (released in 2014) or newer hardware, although there is a proposal to increase that to version 9 (released in 2017) for the next Debian release, since Debian's build fleet is all version 9. Ubuntu has official support for both the big-endian and little-endian 64-bit variants, interestingly. That makes big-endian 64-bit PowerPC the only architecture that Ubuntu supports officially that Debian does not. Fedora restricts itself to supporting little-endian 64-bit PowerPC.

RISC-V

Supported by: Debian, Ubuntu, and Fedora.

RISC-V is an interesting architecture because, while it has taken some time to get going, there are a large number of implementations with different targeted use cases in development at the moment. It's also notable for having a large number of optional extensions that can be implemented independently. On the one hand, this makes it possible for the same architecture to scale from low-power embedded cores to high-performance server CPUs. On the other hand, it makes testing software more difficult. Since the extensions can be implemented independently, there isn't a simple way to agree on a baseline for support beyond just listing extensions. Kernel support was added in 2017, and is maintained by Paul Walmsley, Palmer Dabbelt, and Albert Ou.

s390

Supported by: Debian, Ubuntu, and Fedora.

IBM's System/390 mainframes, with their custom microprocessors, are surprisingly well-supported by modern Linux. The base design of the architecture dates from the s/360 in 1965, but the first mainframes theoretically capable of running Linux were introduced in 1990. Those mainframes transitioned to a new 64-bit architecture with a different name in 2000, the same year that support was introduced to the kernel in version 2.3.99pre8. Despite the new architecture officially being "z/Architecture", most references call it s390x.

The architecture has continued receiving updates, and Ubuntu requires the relatively recent z15 version, released in 2019. Debian has proposed updating to the same baseline, although the build infrastructure is actually composed entirely of z16 processors. Fedora theoretically supports anything after z13, although the project's documentation on the topic has not been updated in some time.

SPARC

Supported by: Debian (unofficially).

SPARC is an architecture introduced in 1986. Support in the kernel was added in version 1.1.71 in 1994, and is maintained today by David Miller and Andreas Larsson. Debian unofficially supports 64-bit SPARC, but no distribution still supports 32-bit SPARC. A new open-source design for SPARC cores, LEON5, was released in 2019. The kernel supports v8, but that version lacks proper atomics, which can lead to problems. A more practical lower limit would be v8e or v9.

SuperH

Supported by: Debian (unofficially).

SuperH is a 32-bit architecture originally produced by Hitachi and later sold to Renesas. It's notable for being entirely out from under its design patents, which has allowed the architecture to be reverse engineered and reimplemented. Official support from Renesas ended in 2025, so those reimplementations are the only source of new SuperH CPUs.

x86

Supported by: Debian, Ubuntu, Arch, and Fedora.

Released in 1978, and then incrementally updated to larger word sizes in 1985 and 2003, x86 is an extremely popular architecture. It is little-endian, still under active development, and has been supported in the kernel since the beginning. Despite that, the support story is actually not as straightforward as it might appear. Since x86 has evolved over time, there are differences between support for the 32-bit version and the 64-bit version. ~~Debian supports a full 32-bit installation on CPUs newer than i486~~Debian supports a 32-bit userspace in some circumstances, but has stopped shipping 32-bit kernels. Ubuntu only supports some 32-bit binaries running in a 64-bit installation. Other distributions are all-in on 64-bit, but still have different baseline architecture versions.

Ubuntu recently announced that the project, while continuing to support older versions, would compile separate versions of all packages for x86-64-v3, dating from 2013. Fedora and Arch both support any 64-bit-capable CPU, regardless of version.

Xtensa

Finally, Xtensa is yet another 32-bit RISC architecture. It's specifically designed for extension, with the possibility of configuring many CPU features and adding custom instructions. It is mostly used in digital signal processors.

[ Thanks to Bergman for his help in fact-checking this article. ]

to post comments

Fedora does support ARM64

Posted Nov 18, 2025 15:48 UTC (Tue) by cdamian (subscriber, #1271) [Link] (2 responses)

At least it is on their download page: https://fedoraproject.org/server/download

It is also on their primary architecture list: https://fedoraproject.org/wiki/Architectures#Primary_Arch...

Fedora does support ARM64

Posted Nov 18, 2025 16:04 UTC (Tue) by daroc (editor, #160859) [Link]

... I double-checked the table so many times, because I knew I would be missing something. Of course you're right. I'll go make a correction.

Fedora does support ARM64

Posted Nov 18, 2025 18:09 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

In fact, they are now the "official" Asahi Linux distro I think. Apple Silicon is of course ARM64.

ArchLinuxARM as non official?

Posted Nov 18, 2025 15:53 UTC (Tue) by Kamiccolo (subscriber, #95159) [Link] (2 responses)

I wonder if ArchLinuxARM initiative would count as "non-official"? :) Sadly, I'm been hearing only talks for over a decade now to move somewhere... more connected and mayhaps official on that front.

ArchLinuxARM as non official?

Posted Nov 18, 2025 16:12 UTC (Tue) by chris_se (subscriber, #99706) [Link] (1 responses)

Unfortunately for the people invested in Arch on ARM the official Arch appears to be taking a more negative stance towards this (see the removal of FEX from AUR a year ago), so my guess (as someone from the complete outside looking in) is that ArchLinuxARM becoming more official is a long ways away...

ArchLinuxARM as non official?

Posted Nov 19, 2025 12:31 UTC (Wed) by Kamiccolo (subscriber, #95159) [Link]

After recent Steam hardware announcements it sounds even weirder :( I was under impression that there is some happy collaboration happening, while basing SteamOS on Arch. And here we event get neat ARM-based device running it.

m68k support is partly the result of passionate people

Posted Nov 18, 2025 16:05 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

I would note that if you want to see an architecture continue, you could do worse than follow the example of Adrian Glaubitz, who's spent a significant amount of time and effort on ensuring that, whatever it is that's needed for modern Debian, it's available on m68k.

He's done a lot of work to make sure that m68k doesn't die off, and because of the nature of this sort of work, it's hidden from most users - it's just quietly getting on with building the things that are needed to keep m68k alive, rather than getting "big headlines".

m68k support is partly the result of passionate people

Posted Nov 18, 2025 19:59 UTC (Tue) by ballombe (subscriber, #9523) [Link]

I hope someone will publish specs for m68k-64 someday (and preferably not on 04/01).
Since almost all m6k code run inside emulators, lack of hardware will not be a problem.

m68k support is partly the result of passionate people

Posted Nov 19, 2025 9:15 UTC (Wed) by glaubitz (subscriber, #96452) [Link] (2 responses)

> I would note that if you want to see an architecture continue, you could do worse than follow the example of Adrian Glaubitz, who's spent a significant amount of time and effort on ensuring that, whatever it is that's needed for modern Debian, it's available on m68k.

Thank you so much for the praise. It's always nice to read such warm and praising words!

> He's done a lot of work to make sure that m68k doesn't die off, and because of the nature of this sort of work, it's hidden from most users - it's just quietly getting on with building the things that are needed to keep m68k alive, rather than getting "big headlines".

I have. But there also many other great people in the community that have helped me make this happen.

FWIW, I'm not only working on m68k but also on basically every other architecture in Debian Ports, i.e.: alpha, hppa, m68k, powerpc, ppc64, sh4, sparc64 and x32.

For SPARC, I just recently created the sparclinux GitHub organization to track bugs and collect patches for SPARC support that have not been upstreamed yet:

https://github.com/sparclinux/

Oracle engineers have contributed a lot of work on SPARC that are part of Oracle Linux 6 but unfortunately never got upstreamed. I'm trying to save those patches and get them upstreamed.

If you're interested in supporting my work in either way, preferably with your own elbow grease, please get in touch!

Again, thanks a lot for the kind words!

Adrian

m68k support is partly the result of passionate people

Posted Nov 19, 2025 9:17 UTC (Wed) by glaubitz (subscriber, #96452) [Link]

Forgot to mention: I'm also working on LoongArch and I'm trying to make it an official Debian release architecture. I was the person who bootstrapped Debian on LoongArch [1] and openSUSE [2].

> [1] https://lwn.net/Articles/941743/
> [2] https://hackweek.opensuse.org/projects/bootstrap-opensuse...

m68k support is partly the result of passionate people

Posted Nov 19, 2025 9:39 UTC (Wed) by farnz (subscriber, #17727) [Link]

Firstly, a disclaimer - I personally am not that interested in running modern software on old hardware; but I can distinguish "doing it right" from "whining unproductively", and I'd like the people who are interested in old hardware to "do it right" - and how better to encourage them than to show them that someone is successfully "doing it right"?

In case people are wondering, a big of part of what I'm referring to is the work that you and Ricky Taylor did to get m68k support into Rust; as far as I can see, you started from pretty much nothing, and between you built up an LLVM backend for m68k, followed by rustc support.

This sort of hidden backend work really matters for the long-term support of an architecture - and it has the nice benefit that when you show up asking for help with something, you're not asking that I "hold back" the architectures I care about, but rather that I help you drive everyone forwards.

You're omitting Gentoo.

Posted Nov 18, 2025 17:22 UTC (Tue) by dilfridge (subscriber, #85278) [Link] (4 responses)

See the Gentoo download page for installation stages in many variants, for systemd and openrc:

alpha
amd64 (x86-64): multilib and non-multilib, glibc and musl, also x32 abi or libc++/LLVM
arm: several hardware levels, glibc and musl
arm64 (aarch64): glibc and musl, also libc++/LLVM and big-endian
hppa (PA-RISC): hppa1.1 and hppa2.0
loong (LoongArch)
mips: little- and big-endian, 32bit (O32 ABI) and 64bit (N32 and N64 ABI), musl for O32
m68k
ppc (PowerPC): 32bit and 64bit big-endian, 64bit little-endian
riscv: 64bit hard-float (rv64gc/lp64d) and soft-float (rv64gc/lp64), 32bit hard-float (rv32gc/ilp32d) and soft-float (rv32gc/ilp32), glibc and musl
s390: 64bit (s390x) and 31bit (s390)
sparc: 64bit and 32bit
x86: i686 and i486, glibc and musl

You're omitting Gentoo.

Posted Nov 18, 2025 17:28 UTC (Tue) by Lionel_Debroux (subscriber, #30014) [Link] (2 responses)

Well... I can count 13 architectures in your list, which matches the "Gentoo offers official installers for 13 architectures." sentence in the OP. Am I missing something ?

You're omitting Gentoo.

Posted Nov 18, 2025 17:30 UTC (Tue) by sam_c (subscriber, #139836) [Link]

Notably, there's a bunch of different ABIs, not all of which are supported by Rust (or have binaries available if they are supported).

s390 (not x) is an interesting example as well where we've recently dropped it, as the kernel plans to soon.

You're omitting Gentoo.

Posted Nov 18, 2025 17:33 UTC (Tue) by dilfridge (subscriber, #85278) [Link]

Good point. That got kinda lost with the big tables and statements elsewhere.

The "13 points" are in any case only a very limited approximation. A BE mips binary won't run in a LE installation, and a x86-64 musl binary won't run in a glibc installation, and so on...

You're omitting Gentoo.

Posted Nov 18, 2025 18:58 UTC (Tue) by daroc (editor, #160859) [Link]

I couldn't include every distribution (or even many more, without making the table unreadably wide on some screens), so I had to pick a somewhat arbitrary set of popular distributions. I think one of Gentoo's strengths, as a distribution, is that since everything is compiled from source, an experienced Gentoo user can probably get some subset of packages working in any environment they please.

OpenWrt supports many official architectures

Posted Nov 18, 2025 17:48 UTC (Tue) by rknight (subscriber, #26792) [Link]

OpenWrt officially support the following architectures from your list:

* Arm (32-bit)
* Arm (64-bit)
* LoongArch
* MIPS
* PowerPC (32-bit)
* PowerPC (64-bit)
* RISC-V
* x86 (32-bit)
* x86_64

"Tested" vs "Full support"

Posted Nov 18, 2025 17:54 UTC (Tue) by josh (subscriber, #17465) [Link] (6 responses)

The "Rust" column in the table has some targets that say "Tested" and others that say "Full support". Are these meant to refer to tier 2 vs tier 1? If so, that's misleading: tier 2 targets are "compile-tested", but explicitly are not guaranteed to pass the test suite.

"Tested" vs "Full support"

Posted Nov 18, 2025 18:56 UTC (Tue) by daroc (editor, #160859) [Link] (3 responses)

That's fair; I could have been clearer. Yes, by "Tested", I meant Tier 2 support, which includes compile testing but not the rest of the rustc test suite. I meant to draw a distinction between that and Tier 3, which isn't even compile-tested, and therefore may break without notice.

"Tested" vs "Full support"

Posted Nov 19, 2025 19:15 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

Would you mind clarifying the table, please, to clearly distinguish "fully tested", "compiles but untested", and "not compiled or tested", or something like that?

If it helps, https://doc.rust-lang.org/nightly/rustc/platform-support.... is the page to link to for platform support info, and https://doc.rust-lang.org/nightly/rustc/target-tier-polic... is the page for the policy defining "tier 1", "tier 2", and "tier 3".

"Tested" vs "Full support"

Posted Nov 19, 2025 21:33 UTC (Wed) by daroc (editor, #160859) [Link] (1 responses)

I thought the words I picked might be helpful for people just skimming the table, but I can see why it would be unclear. I've updated the table to just refer to the tiers as tier 1, tier 2, and tier 3. (With an explanation above about what those entail)

"Tested" vs "Full support"

Posted Nov 20, 2025 14:19 UTC (Thu) by josh (subscriber, #17465) [Link]

Thank you!

"Tested" vs "Full support"

Posted Nov 21, 2025 22:00 UTC (Fri) by kepstin (subscriber, #72391) [Link] (1 responses)

MIPS, (32bit, little-endian specifically), is well supported in openwrt since it is the instruction set used by many popular home wifi router chipsets (Broadcom in particular, whose chips were used in the old Linksys WRT-54G routers that gave the project its name).

Newer routers with chipsets by Qualcomm (formerly Atheros) and MediaTek generally have ARM instead - I think 32bit is still more common than 64bit? 64bit tends to be used by people running openwrt on a modern raspberry Pi or similar.

x86(-64) is normally used by people building routers from PCs, but there's a fair number of PC based network appliances boxes out there.

Apparently there were actually a few consumer routers shipped using embedded Power processors. I recall seeing a video recently where someone used a PCIe riser cable from a wifi card mini-PCIe slot to do some gaming on one of these.

"Tested" vs "Full support"

Posted Nov 21, 2025 22:03 UTC (Fri) by kepstin (subscriber, #72391) [Link]

(oh, dang, hit reply on the wrong post-this was intended to follow up the post listing architectures supported by openwrt)

Debian on i386 is less complete than this would indicate

Posted Nov 18, 2025 17:59 UTC (Tue) by smcv (subscriber, #53363) [Link] (2 responses)

> Debian supports a full 32-bit installation on CPUs newer than i486

This hasn't been true for a while.

Debian 13 only supports i386 (our name for 32-bit x86) as a chroot, container or secondary multiarch/multilib architecture on an x86_64 kernel [0]: we no longer ship 32-bit x86 kernels, and I'm not sure whether bootloaders and similar early-boot infrastructure have already disappeared from i386 (if they haven't, then I'd expect that to start happening during the Debian 14 cycle). In a container running on a 64-bit machine under an x86_64 kernel, it is still possible to run fully 32-bit from the init system up.

This is slightly more i386 support than Ubuntu, but less than Debian 12 (which had fully bootable i386 systems, albeit with questionable kernel security because i386 kernels are missing many of the workarounds for security-sensitive CPU errata).

The i386 port in Debian 13 requires the Pentium 4 feature-set [0] (a subset of x86_64, notably including SSE2), because LLVM/Rust requires that. In older releases, Debian 12 requires i686 [1], and Debian 9, 10 and 11 required a large subset of i686 [2] (everything except "long NOP" instructions).

Unofficially, it is probably technically possible to run Debian 13 on a Pentium 4 or similar system with a self-built kernel or a Debian 12 kernel, but the project doesn't intend to provide support for this configuration.

[0] https://www.debian.org/releases/trixie/release-notes/issu...
[1] https://www.debian.org/releases/bookworm/i386/release-not...
[2] https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1

Debian on i386 is less complete than this would indicate

Posted Nov 18, 2025 18:54 UTC (Tue) by daroc (editor, #160859) [Link] (1 responses)

Thanks for the correction; I've applied it to the article.

Debian on i386 is less complete than this would indicate

Posted Dec 5, 2025 14:11 UTC (Fri) by zuki (subscriber, #41808) [Link]

The line for "x86 (32-bit)" in the table is still mostly wrong: as discussed here, Debian should be "user-space only", and Fedora actually the same.

Debian ports still has hppa maintained unofficially

Posted Nov 18, 2025 18:19 UTC (Tue) by guillemj (subscriber, #49706) [Link] (1 responses)

The hppa port is still maintained in Debian ports (see https://www.debian.org/ports/ and https://www.ports.debian.org/). And AFAIR it was also one of the architectures that would have issues with a core component imposing Rust (if that ends up happening at all).

Debian ports still has hppa maintained unofficially

Posted Nov 18, 2025 18:53 UTC (Tue) by daroc (editor, #160859) [Link]

Ah, shoot. Yes, I see that you're right. I've updated the table.

Elbrus (e2k)

Posted Nov 18, 2025 18:46 UTC (Tue) by xose (subscriber, #535) [Link]

There is one arch out of the official tree, currently in use. Elbrus (e2k): https://git.openelbrus.ru/mcst/osl/linux

And at https://en.wikipedia.org/wiki/List_of_Linux-supported_com... there is a comprehensive list of the removed ones.

Arch has also proposed providing x86-64-v3 packages

Posted Nov 18, 2025 19:29 UTC (Tue) by karkhaz (subscriber, #99844) [Link]

Ubuntu recently announced that the project, while continuing to support older versions, would compile separate versions of all packages for x86-64-v3, dating from 2013. Fedora and Arch both support any 64-bit-capable CPU, regardless of version.

Arch had an RFC back in 2020 about providing separate x86-64-v3 package builds, but it hasn't been implemented yet beyond an unofficial package repository.

Fedora correction

Posted Nov 18, 2025 19:33 UTC (Tue) by AdamW (subscriber, #48457) [Link] (3 responses)

"For Fedora, a primary architecture is one where build failures on Koji, Fedora's package build farm, block the release process. Secondary architectures might also cause build failures on Koji, or might have their own separate package-build infrastructure, but failures don't stop the release."

This is not quite correct. I don't blame you - we probably have outdated info in the docs or wiki somewhere (hat tip to former FPL Robyn Bergeron and her backronym for wiki, Where Information Kills Itself...)

The correct info is at the top of https://fedoraproject.org/wiki/Architectures . "There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."

Currently, s390x and ppc64le are built in primary Koji, so build failures on those arches are fatal for the overall build. Only riscv is currently in the "ones built on their own koji instances where build failures on the alternative architecture are not fatal" bucket (the Koji instance for riscv is https://riscv-koji.fedoraproject.org/koji/ ).

Fedora correction

Posted Nov 18, 2025 19:46 UTC (Tue) by daroc (editor, #160859) [Link] (2 responses)

Ah, I see! I did read that link, but I must have misunderstood it. So you're saying that some alternative architectures do block releases, and some do not? What's the actual difference between a primary architecture and an alternative architecture that must build for Koji to be happy?

Fedora correction

Posted Nov 18, 2025 19:59 UTC (Tue) by AdamW (subscriber, #48457) [Link] (1 responses)

Excellent question! Ten points, that editor.

It is, uh, a mostly vibes-based difference, tbh. The main practical consequence I'm really aware of is that nothing related to an alternative arch can be considered release blocking. There are other miscellaneous things - e.g. the packaging guidelines state "All Fedora packages must successfully compile and build into binary rpms on at least one supported primary architecture, except where the package is useful only on a secondary architecture...Fedora packagers should make every effort to support all primary architectures" (using the old term for "alternative" architecture). The difference exists in the download server layout - the secondary arches are under a separate tree, which means mirrors can skip them if they like, and some mirrors do. (Ask me why I hate this because it makes the compose metadata a lie!)

Beyond places it's formally written down, everyone *knows* about the difference, so it tends to play informally into things like Change review - if a Change is problematic on a primary arch that's a bigger deal than if it's problematic on a secondary arch, stuff like that.

Fedora correction

Posted Nov 18, 2025 20:01 UTC (Tue) by AdamW (subscriber, #48457) [Link]

Sorry, I should clarify - when I say "release blocking" I mean for the *distribution as a whole*. Alternative-arches-in-primary-Koji are "blocking" in the sense that they fail the overall build of the individual package. But when we use the term "release blocking" in the Fedoraverse we're generally referring to the release *of a new Fedora* as a whole. Images for alternative arches cannot be "release blocking" in this sense, and bugs specific to alternative arches cannot be release blockers.

PPC support inaccuracies

Posted Nov 18, 2025 19:37 UTC (Tue) by calvin (subscriber, #168398) [Link] (6 responses)

> Debian supports little-endian 64-bit PowerPC officially, and has two different unofficial ports for 32-bit big-endian PowerPC and 64-bit big-endian PowerPC. The official port seems to require version 8 (released in 2014) or newer hardware, although there is a proposal to increase that to version 9 (released in 2017) for the next Debian release, since Debian's build fleet is all version 9. Ubuntu has official support for both the big-endian and little-endian 64-bit variants, interestingly. That makes big-endian 64-bit PowerPC the only architecture that Ubuntu supports officially that Debian does not. Fedora restricts itself to supporting little-endian 64-bit PowerPC.

This isn't the case for Ubuntu. Like Fedora, they only support little endian 64-bit, and also like Fedora, they have POWER9 as the minimum CPU. (I'm not sure why they want POWER9 as their minimum anyways, since POWER8 is capable of little endian.)

PPC support inaccuracies

Posted Nov 18, 2025 19:42 UTC (Tue) by calvin (subscriber, #168398) [Link]

To also add, there's also the ELFv1 vs. ELFv2 ABI split on ppc64, and this is orthogonal to endianness. glibc is ELFv1 on BE and v2 on BE, but very early LE was v1 and musl uses v2 on big and little. (Speaking of, Alpine would be a good candidate for the table, since it's a realistic alternative libc situation, no crusty uclibc type stuff.)

PPC support inaccuracies

Posted Nov 18, 2025 19:43 UTC (Tue) by daroc (editor, #160859) [Link] (4 responses)

Interesting. I was going off of the official Ubuntu documentation, but the downloads page agrees with you. So either the documentation is out of date, or the website isn't showing all the 'supported' architectures.

PPC support inaccuracies

Posted Nov 18, 2025 20:00 UTC (Tue) by calvin (subscriber, #168398) [Link]

I think it's out of date as well. The `powerpc` entry in that table refers to 32-bit PPC, which I don't think Ubuntu has supported in over a decade. I didn't see 64-bit big endian in there.

PPC support inaccuracies

Posted Nov 18, 2025 21:58 UTC (Tue) by bluca (subscriber, #118303) [Link]

Documentation bitrots easily, an easy way to check is to see what is actually built for important packages, e.g.:

https://packages.ubuntu.com/resolute/libc6

libc on Ubuntu is built for armv7 and ppc64le, which indeed are supported as architectures

PPC support inaccuracies

Posted Nov 19, 2025 10:54 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

Looks like when you finish consolidating the list you’ll end up with pretty much the same level of full arch support for Debian Ubuntu and Fedora. Which is completely logical all the major distributions know how to build new architectures and there is zero reason to refuse building an healthy arch already supported by one of the competitors.

The only discrepancies that can exist is slight temporal de-phasing when bringing up a new major arch or giving up on one past its prime.

PPC support inaccuracies

Posted Nov 21, 2025 21:36 UTC (Fri) by plugwash (subscriber, #29694) [Link]

It's sad but perhaps inevitable, that it's got to the point it's very hard for hobbyists to support an architecture at "release level" without corporate support.

That said

Debian had mips ports for years whereas I don't think ubuntu has ever supported any variant of mips.

Loongarch (which is arguablly a mips variant) seems likely to make it into the next Debian release, while I haven't seen Canonical/Ubuntu showing any interest in it.

Ubuntu "supports" riscv, if you define "supports" as the existence of a riscv64 port. The thing is the riscv port in Ubuntu 25.10 bumped the baseline to a level that cut-off all of the riscv hardware that was out there. Will be interesting to see if the new hardware makes it to market before Ubuntu 26.04 is released.

Fedora offers user-space x86_32 (with SSE2 matching x86_64-v1 baseline)

Posted Nov 18, 2025 21:15 UTC (Tue) by Conan_Kudo (subscriber, #103240) [Link] (2 responses)

Like Debian, Fedora offers an x86_32 (i686) userspace stack purely for the purposes of running legacy applications. The i686 baseline was raised to match x86_64-v1 in Fedora 29. The i686 kernel package was dropped in Fedora Linux 31.

Fedora offers user-space x86_32 (with SSE2 matching x86_64-v1 baseline)

Posted Nov 19, 2025 11:13 UTC (Wed) by smcv (subscriber, #53363) [Link] (1 responses)

Is this a full user-space like Debian, though (with 32-bit bash and coreutils and all the rest), or is it just 32-bit shared libraries that you can install into an x86_64 user-space, like on Arch?

Either one can make sense as an approach: it's a question of whether continuing to build a mostly-full i386 user-space is estimated to be more or less work than making i386 be a special case.

Either way, if you don't intend to actually boot on 32-bit CPUs, setting the baseline to x86_64-v1 as Fedora has done, or at least i686 + MMX + SSE + SSE2 as Debian has done, makes a lot of sense as a way to reduce the ways in which i386 needs to be special-cased (by eliminating i387 excess precision).

Fedora offers user-space x86_32 (with SSE2 matching x86_64-v1 baseline)

Posted Dec 5, 2025 14:05 UTC (Fri) by zuki (subscriber, #41808) [Link]

> Is this a full user-space like Debian, though (with 32-bit bash and coreutils and all the rest)

Yes. Fedora does not do cross-builds of official packages, so a functional chroot with 32-bit bash, coreutils, rpm, compiler and linker, and any required libraries is a basic requirement for us to say that the provide packages for an architecture. That said, "leaf" packages that are not required to build other packages are allowed and encouraged to not compile a 32-bit version. So over time the number of packages available in the 32-bit version is dropping. But or now the basic "full userspace" remains available.

Thanks -- really appreciate computer arch articles

Posted Nov 18, 2025 21:30 UTC (Tue) by decaffeinated (subscriber, #4787) [Link]

I'm sure this article took a _lot_ of effort to put together. Thanks!

Impact of RISC-V

Posted Nov 18, 2025 23:33 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

> For now, the kernel supports many more architectures than the mainstream distributions that depend on it do. If embedded uses continue to adopt RISC-V, however, that might not be the case in another few decades.

This is a somewhat unappreciated aspect of RISC-V. We think of the processors running on our desktops and in our phones as representing the industry, but the world has been awash in dozens of architectures and ISAs for decades. The embedded world is a vast ecosystem.

All that started to change with ARM as it began to fill some of these niches. RISC-V has greatly accelerated that trend--especially in microcontrollers. Why create your own custom ISA when you can pick a RISC-V profile and perhaps add a custom instruction or two? The savings on toolchain maintenance alone are huge.

It is not all about the "main" CPU. Even things like an NVIDIA GPU may contain a dozen chips with a number of different ISA in them (power management, thermal management, security, DSPs, PCIe, etc). At least, that used to be common. These days, many of those have migrated to RISC-V.

Being able to use RISC-V at every level is a massive win. The "complicated" optional extensions in the RISC-V world are actually a huge simplification over what came before. And with profiles, you can have things like RVA23 ("application" level standard for desktops and servers) and soon something similar for "microcontrollers".

SBC projects have gotten away with RV64GC for quite a while (a strict subset of both RVA20 and RVA23). Ubuntu has been targeting RVA20 (a strict subset of RVA23). All of these will move to RVA23 soon. And for generic microcontrollers today, targeting RV32IMC (or whatever) is still better than an ISA you have never heard of. And adding additional extensions or even custom instructions to that is easier than a whole new architecture even if it looks like "RV32IMACB + Zicsr + Zifencei" when you write it.

In the past, you targeted new niches with a new ISA. In the future, you will target them with a RISC-V profile. 20 progressively compatible RISC-V profiles are a lot easier to manage than 20 totally different architectures.

Not that it will not be nice to trim down the number of RISC-V options you have to consider in Linux.

RVA23 is going to do wonders to standardize the RISC-V world (it is directly comparable to ARMv9-A and x86-64v4). It will be good when they define a new microcontroller baseline profile as well (work in progress).

RISC-V Profiles

Posted Nov 19, 2025 0:14 UTC (Wed) by jmalcolm (subscriber, #8876) [Link] (4 responses)

In the section on RISC-V, it says...

> there isn't a simple way to agree on a baseline for support beyond just listing extensions.

Yes, there is. RISC-V International provides "profiles" which are bundles of RISC-V extensions that serve as a common target for hardware and software providers.

The RISC-V equivalent to ARMv9 or X86-86v4 is RVA23.
https://riscv.org/blog/risc-v-announces-ratification-of-t...

RVA23 is the target that the SBC, desktop, and server RISC-V suppliers will target for the next few years until something like RVA30 comes along. RVA30 will be a super-set of RVA23 (much like I expect x86-64v5 will be a superset of x86-64v4).

RVA23 is a short-hand that corresponds to a list of extensions. If you have code compiled with some but not all of these extensions, it will still run on RVA23. So you will be able to run Ubuntu 24.04 (which targets RVA20) on RVA23 hardware (as an example). But already, desktop or server Linux users do not really need to know anything about extensions when thinking about RISC-V. And every SBC level or better RISC-V chip is likely to support at least RVA23 from now on.

Since RVA23 has feature parity with x86-64v4 for things like vector and hypervisor extensions, I expect it will remain a viable desktop target for a quite a while. On the server, I guess the wildcard is probably if it becomes table stakes to have more advanced matrix extensions to support AI workloads. But even then, saying RVA23 + matrix is not so bad while we wait for that to be called RVA30 (pure speculation by me).

On the microcontroller side, the "profile" standardization has not matured as far. So, you are listing extensions in that world. But microcontrollers tend to differ quite a lot from each other regardless of architecture. At least with RISC-V, the entire ISA and memory model is not switching on you from chip to chip. There is an effort to create a "standard" microcontroller profile to fill the same role as RVA23 does on higher-end chips. But I have no doubt that, even after a "standard" profile exists, extensions will continue to feature more prominently in that world.

RISC-V Profiles

Posted Nov 19, 2025 5:56 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (2 responses)

RISC-V profiles only matter if hardware exists for it. Right now, it doesn't. "It's complicated" is a reasonable way to describe RISC-V right now.

RISC-V Profiles

Posted Nov 19, 2025 17:19 UTC (Wed) by danielthompson (subscriber, #97243) [Link]

"It's complicated" described figuring out the minimum hardware revision supported kernel version supported by the kernel. It's a great summary of that but I don't think it applies more widely.

In particular I haven't found the RISC-V extensions and profiles approach to be significantly different to the Arm approach. Just like RISC-V, Arm is based around frequently added extensions. Many Arm extensions are optional when first announced and become mandatory in later ArmxX.Y releases. Put differently, ISA extensions are complex but they are complex on pretty much every architecture that wants to stay relevant (otherwise the article above would have been very short).

So it's true that everyone is waiting for RVA23 hardware but that doesn't mean that profiles are not already a useful way to describe baseline RISC-V features. RVA22 was already very effective at adding feature cohesion to the ecosystem and RVA23 is *already* driving baseline support for RISC-V software.

RISC-V Profiles

Posted Nov 21, 2025 1:02 UTC (Fri) by jmalcolm (subscriber, #8876) [Link]

> RISC-V profiles only matter if hardware exists for it"

Ubuntu 24.04 LTS targets the RVA20 profile. There is lots of RVA20 compliant RISC-V hardware out there. If you are trying to run Linux as an SBC, desktop, or server today, the hardware you are using almost certainly supports RVA20.

Many other RISC-V distros only require RV64GC which is even less demanding (and a subset of RVA20) so you are even more covered there.

But everything I just said is legacy and anybody already not versed in RISC-V or trying to buy RISC-V hardware "right now" does not need to know anything about it.

When you say "RISC-V profiles only matter if hardware exists for it", you are talking about the RVA23 profile. I concede that RVA23 compliant hardware is not shipping yet. However, it is only a matter of months as at least a dozen chips and devices have been announced for 2025 / 2026.

There are two reasons to put the RVA23 cart before the horse here:

1) RVA23 is such a massive leap forward for desktop and server use cases (eg. vector and hypervisor stuff)

2) If you are not the very early adopter type, the solution to "it's complicated" is to wait for RVA23 hardware to appear

I am not an Ubuntu user but I agree with their decision to make RVA23 the baseline for Ubuntu 25.10 and 26.04 LTS precisely because, for the world at large, instead of "it's complicated" the answer should be "target RVA23" now and for the next several years. The first hardware that is going to be fast enough that you want to buy it is right around the corner and will be RVA23 compliant. All the RISC-V RVA23 compliant software that runs on that hardware will continue to run on the hardware that comes out over the next several years.

It is not complicated--all you need to know is RVA23.

And since you only need to focus on one profile, you do not need to focus on any at all. By mid next year, RVA23 will be what people in the SBC, desktop, mobile, and server spaces will mean when they say RISC-V.

For micro-controllers, I again concede that it is a bit more complicated. But that is nothing new. And a new profile is coming for that that will even calm that space down a bit.

RISC-V Profiles

Posted Nov 20, 2025 10:42 UTC (Thu) by roc (subscriber, #30627) [Link]

What would be really useful is a way to run userspace processes with a specific set of extensions enabled and the rest disabled, so that if the code accidentally uses a disabled extension, there is a fault. Even if the underlying hardware supports the extension. Then you could test that code works in RVA23 even if your hardware supports extensions beyond RVA23.

Exceptional summary

Posted Nov 19, 2025 0:53 UTC (Wed) by intelfx (subscriber, #130118) [Link] (2 responses)

Thank you for the summary table and the series of primers on each mentioned architecture — for someone curious but not entirely fluent in non-mainstream computing, this was very interesting to read.

> MIPS was released in 1985. <...> Even though the architecture is regularly updated (and the oldest processors for it have fallen out of their patent period), no major Linux distribution maintains a port.

Does OpenWrt count, perhaps?

Exceptional summary

Posted Nov 19, 2025 1:18 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> Does OpenWrt count, perhaps?

I think "major Linux distribution" refers to "desktop and/or server" use.

If you expand the scope to include embedded devices, even where product lifecycles aren't measured in decades, there are still a substantial number of MIPS cores still shipping. Including new designs.

Exceptional summary

Posted Nov 19, 2025 4:35 UTC (Wed) by willmo (subscriber, #82093) [Link]

Indeed, I would guess that 32-bit MIPS runs more installations of recent OpenWrt than any other ISA besides possibly 64-bit ARM. (I’m sure 64-bit ARM will take the lead soon if it hasn’t already, but still, MIPS was/is a big deal in networking.)

Debian

Posted Nov 19, 2025 2:44 UTC (Wed) by pabs (subscriber, #43278) [Link]

Debian has a third level of architecture support; those that can be built from source but aren't distributed in binary form. These are tested by the rebootstrap project. Some related links:

https://wiki.debian.org/HelmutGrohne/rebootstrap
https://bootstrap.debian.net/
https://wiki.debian.org/Ports
https://wiki.debian.org/PortsDocs/New

Mill Computing

Posted Nov 19, 2025 3:01 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

Sounds like Mill Computing might add a Linux port (likely running on top of L4) if they eventually release some hardware.

https://millcomputing.com/topic/linux-port/
https://millcomputing.com/topic/microkernels-vs-monolithic/

Mill Computing

Posted Nov 20, 2025 23:24 UTC (Thu) by intgr (subscriber, #39733) [Link]

You do realize that the linked posts are over 10 years old?

If Mill ever sees the light of day, their patents will have already expired many times over.

But I suspect it will stay vaporware. Ivan Godard seems like a brilliant engineer but sadly he has zero business sense.

IA-64

Posted Nov 21, 2025 17:55 UTC (Fri) by anton (subscriber, #25547) [Link] (1 responses)

I looked for IA-64 in the tables, but did not find it. Why? Because it has been removed from the Linux kernel tree in November 2023 (there is out-of-tree development with a 6.17 release in September 2025). Discontinuations of IA-64 CPUs was announced in 2019, and the official last ship data was 2021.

IA-64

Posted Nov 24, 2025 10:06 UTC (Mon) by taladar (subscriber, #68407) [Link]

Not sure architectures like Itanium which many considered dead on arrival a year or so after the initial release are really representative of your typical architecture lifecycle.

My thoughts and nitpicks.

Posted Nov 21, 2025 19:57 UTC (Fri) by plugwash (subscriber, #29694) [Link] (2 responses)

> The distinction between official and unofficial support is a bit fuzzy. In practice, a lot of software packaged by the different distributions will compile fine on unsupported architectures, provided an appropriate compiler is available.

Someone still has to do that compilation, and for a full-scale linux distro that is not designed to be cross-compiled it's not a trivial process, particularly if you don't have a working and reasonably up to date system to start with.

> In Debian's case, official support means that it is part of the official release, it has been tested, and it will receive security updates. Unofficial architectures may be released on a delayed schedule, may have to deal with breaking changes, and might be dropped in between major versions

The "unofficial" architectures on debian-ports.org are not released at all. Effectively only "unstable" exists for them. This is one-of the reasons raspbian ended up as an independent project.

> Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH.

> For another, the only architectures that are supported by Debian but not Rust are Alpha (for which no new CPUs have been produced since 2007), and SuperH.

The problem is that "teir 3" can mean anything from "this works mostly ok, but we don't want to commit the manpower to make it teir 2 and/or there are some nasty but not totally breaking issues" to "this is completely broken". My understanding is that rust for m68k is being worked on, but the documentation implies it is not yet ready for prime-time.

Ubuntu supported 32-bit big endian powerpc in the past but dropped it from new releases some time ago. I don't think they ever supported 64-bit big endian.

> Ubuntu is somewhere in between, with five official architectures an a vague suggestion that it may work on Debian's unofficial architectures as well.

Whoever wrote that vauge suggestion seems out of touch with reality. No Ubuntu repositories exist for those architectures, and creating them would be non-trivial.

My thoughts and nitpicks.

Posted Nov 24, 2025 13:43 UTC (Mon) by arnd (subscriber, #8866) [Link] (1 responses)

> Ubuntu supported 32-bit big endian powerpc in the past but dropped it from
> new releases some time ago. I don't think they ever supported 64-bit big
> endian.

The 32-bit powerpc image that they used to have did explicitly target 64-bit machines, with installation instructions for Apple G5, Sony PS3 and IBM OpenPower (along with 32-bit Apple G3/G4). Apparently the same was true for the SPARC and PA-RISC ports they had at the same time, all of which used 32-bit userspace on 64-bit kernels despite the IBM/HP/Sun hardware being 64-bit since the mid-1990s.

See http://old-releases.ubuntu.com/releases/ports/releases/9....

My thoughts and nitpicks.

Posted Nov 28, 2025 9:37 UTC (Fri) by geert (subscriber, #98403) [Link]

None of the targeted machines (except OpenPower?) had enough RAM to need a 64-bit address space.
I suppose individual applications could still contain optimized code using 64-bit arithmetic instructions?

ARC600 is not supported in kernel

Posted Nov 25, 2025 16:26 UTC (Tue) by vineetg (subscriber, #85161) [Link]

ARC600 was MMU less, non-precise exceptions etc so the minimum/initial support in kernel was ARC700.

s390x is big endian

Posted Dec 5, 2025 8:55 UTC (Fri) by daenzer (subscriber, #7050) [Link]

It might be interesting to note that s390x is big endian, and supported by commercial LTS distros. It's the one remaining reason why many of us still need to care about big endian at all.