As a tech interested noob I wonder how long it might take for ARM to have the same or similar support on linux as x86. What would need to be developed and changed to finally one day get there?
Posted by BangBang_McPew@reddit | linux | View on Reddit | 47 comments
I‘m watching youtube videos about various tech subjects for years, and one subject I occasionally come back to is arm vs x86, and how support for both differs on various platforms. From what I gathered ARM doesn’t have the legacy stuff x86 has and ARM doesn’t seem to have many standards, that would get it anywhere beyonds costom distros or modified distros for specific hardware. So my noob assumption is that ARM would have to adopt some standards x86 has or at least have something equivalent to help it with mass adoption on linux or in general.
INITMalcanis@reddit
The Steam Machine Lesson is that if investment is made, large improvements follow.
In this case, by a corporation as corporations are generally the entities able to make such a large effort - but it should be remembered that Valve is a private company, not answerable to shareholders, and not required to encumber itself with the self-defeating late-stage capitalist doctrine obsession with immediately compounding "line go up" returns.
The question to ask is: who wants ARM to have support similar to Linux. And who wants ARM to have locked-down, rent-seeking, rapidly enshittifying support similar to Windows.
BangBang_McPew@reddit (OP)
Who knows, maybe one day there will be distros, that support the snapdragon x chips, and those might set standards to make ARM chips from different manufacturers more similar for developers.
Finnish70@reddit
Sadly Qualcomm shows no interest in supporting Linux. They are the roadblock.
MatchingTurret@reddit
WTF? That's absolutely false. Qualcomm isn't the problem.
Finnish70@reddit
RTFA https://videocardz.com/newz/qualcomm-shuts-door-on-snapdragon-x-dsp-headers-open-sourcing-linux-support-hopes-fade
MatchingTurret@reddit
https://www.qualcomm.com/developer/blog/2025/10/same-day-snapdragon-8-elite-gen-5-upstream-linux-support
Finnish70@reddit
Ask yourself how many fully functioning Linux Distributions work on Snapdragon chips and you have your answer. They are far more interested in supporting Windows than Linux.
MatchingTurret@reddit
Attribute the blame where it belongs: It's the OEMs that make those laptops.
KnowZeroX@reddit
Qualcomm has always been a problem for decades, if your goal is just running things that is one thing, but a lot of the important stuff they leave out. Kind of like why in openwrt, you don't have Qualcomm NSS for mesh networking, they don't open source that. There are 3rd party which take out the proprietary binary blobs and make it work but its flakey at best.
ibmi_not_as400_kerim@reddit
Those laptops would 100% run fine with Linux, if it wasn't for Qualcomm.
Just look at the Honor MagicBook Art lineup. It's the same device, with only the CPU being the difference. 1 with Quallcomm and 1 with Intel. I am literally writing this comment on the Intel variant running Linux.
Quallcomm isn't interested in making the Snapdragon chips compatible with Linux. Maybe even to appease Microsoft.
MatchingTurret@reddit
There are plenty of Snapdragon Laptops that run Linux. It's not Qualcomm that is the roadblock.
m4tx@reddit
Have you actually tried running Linux on any of these machines?
"run Linux" means anything from "everything works perfectly" to "it barely displays some text when booting". Even the best supported ones have serious problems with camera, suspend, or speakers. See: https://github.com/kuruczgy/x1e-nixos-config?tab=readme-ov-file#feature-matrix
nightblackdragon@reddit
There are more differences between those two laptops than just CPU.
Finnish70@reddit
Qualcomm makes the SOC. They should open source their code but they prefer to provide binary blobs instead. This is not a company that truly supports Linux.
Exotic_Accident3101@reddit
A company design a chip and provide sdk and support for it, a manufactor fomany takes this base and build on it.
You don't see a gigbyte gpu driver but AMD or Nvidia driver and if the manufactor put an extra feature like RGB they build rhere own software and suuport it.
So CPU manufactor need to provide there support on linux and any extra features that was added by the manufactor its up to the manufactor to support it.
ibmi_not_as400_kerim@reddit
Fuck Snapdragon. Qualcomm can eat dirt. At this point, I just want to leapfrog to RISC-V.
Content_Chemistry_44@reddit
Qualcomm isn't really bad. Who is much worse, is Mediatek.
TheOgGhadTurner@reddit
Am I in a k-hole what the fuck? Raspberry Pi’s exist and run ARM no? Debian Ubuntu and Fedora definitely all support ARM architecture. Apple switched to arm and MacOS is technically a proprietary flavor of Linux that used to be based on FreeBSD whether or not that’s still true I’m unsure. I’m sure there’s still Linux roots. And it will trickle down in a few more years
BangBang_McPew@reddit (OP)
I wouldn’t say MacOS is a flavor of Linux, just related to it in some weird ways.
TheOgGhadTurner@reddit
The Kernel was originally derived from the Mach kernel from CMU which incorporated the bulk of it's kernel from 4.3BSD. After acquiring NeXT it was updated with code derived from OSFMK and FreeBSD.
MatchingTurret@reddit
ARM has been supported for over 30 years and the standards like ACPI exist. The problem is just that manufacturers don't implement the standards on hardware that is designed to run Windows or MacOS.
Content_Chemistry_44@reddit
Android is Linux already.
edparadox@reddit
See this is why I hate people saying Linux is Android, because if that was true, this kind of posts would simply not exist.
Same kernel does not make Android a Linux distribution.
Content_Chemistry_44@reddit
Same kernel does not make GNU a Linux distribution, but parrots keep repeating.
Why GNU or busybox are called as "Linux" distribution, ChromeOS and Android are not? What is the logical reason?
DeVinke_@reddit
And how many devices have mainline functional on them? Very few.
Read the comment. E.g. smartphone manufacturers don't implement ACPI, instead they hardcode all that stuff in enourmous devicetrees.
I don't count that as "supporting".
audioen@reddit
ARM laptops exist, and you can get those snapdragon based laptops for example. Chromebooks have been Arm-based for something like 10 years at this point, and apparently boot in a pretty standard way. I recently bought ARM based AI server similar to DGX Spark, though it was from another vendor. As far as I can tell, it is more or less a standard PC. I didn't install it from scratch, but I removed everything DGX Spark related that wasn't from Ubuntu repos and just run stock Ubuntu 26.04 on it. So, I am not sure how much more there is left to go in this respect any longer.
nightblackdragon@reddit
The issue here is not architecture by itself but lack of standard platform. x86 is not only architecture, it’s also standardized platform with standard boot process (UEFI), standard interfaces (like ACPI), standard chipset etc. There is nothing like that on ARM side, every ARM board is completely separate platform that, aside from architecture itself, doesn’t have much in common with other boards. Every board needs separate support and drivers that are often available only in downstream (patched) kernel or, in some cases, not available at all. Some boards have UEFI and ACPI that makes booting Linux easier but without drivers you are not going anywhere.
glity@reddit
I hope this is not a stupid question but I’ll ask anyways. If arm is based on risk architecture do all the comments about how to get Linux working on arm also apply to risk-v processors as well?
nightblackdragon@reddit
Nope, RISC-V and ARM are completely separate architectures that are not compatible with each other. “RISC” stands for “Reduced Instruction Set Computer” (as opposed to CISC “Complex Instruction Set Computer”) and it’s about architecture design. Generally RISC architectures have much less instructions than CISC architectures which makes instruction decoder simpler but in return they require more instructions to perform same task compared to CISC architectures. ARM is RISC architecture and so is RISC-V but aside from that they have nothing in common.
DeVinke_@reddit
Think of RISC as an base idea. ARM is a RISC architecture, and so is RISC-V. That doesn't really make them compatible.
Content_Chemistry_44@reddit
Linux is already working on all Android, ARM Chromebooks.
BangBang_McPew@reddit (OP)
I don’t think so. They are both RISC, but may still be very different.
glity@reddit
Ok thanks for the reply I’ll go dig into it a bit hadn’t put them together yet your post was very helpful thank you.
Kevin_Kofler@reddit
The problems have nothing to do with the ARM CPU architecture itself, but are all about locked-down devices (unmodifiable and non-unlockable bootloaders), peripheral hardware with no FOSS drivers (because they only support Android with blob drivers), and lack of plug&play (PCI or equivalent) support (requiring hardcoded device trees).
DeVinke_@reddit
This explains it perfectly.
IBNash@reddit
As someone who has hacked retail routers to run OpenWRT for a very long time, I can tell you the largest pain point in spite of established projects that provide cross-compilation toolchains is actually cross-compiling software. Modern 64-bit ARM SoCs makes this slightly easier but I would not recommend it to anyone.
It is a fragmented system to say the least and is not much less painful across the board in 2025 as it was in 2005.
gcc-aarch64-linux-gnudidn't even provide standard headers likestdio.h.killermenpl@reddit
The kernel itself runs perfectly fine on ARM. Drivers are also becoming less of a problem, as interfaces stabilize and standards emerge. Also, ARM is gaining popularity in datacenters, so companies have a reason to provide drivers.
Most software either already has ARM support, or can be compiled for ARM with relative ease. I'm saying most instead of all because I'm sure there are cases where devs rely on a very specific x86 feature that ARM doesn't have.
The big issue is that it's a 2nd architecture that the devs would have to support. Big projects like the Linux kernel, KDE, or Firefox can afford to spend the time and money on that support. However, a whole lot of software people take for granted is maintained by a single person, or a small group. Focusing their time on ARM would mean less time working on x86 support, which for the time being is the main platform
BangBang_McPew@reddit (OP)
I‘ve been wondering for a while how much developing for both differs, and much of an impact on development the chosen architecture makes. I don’t know how much development happens this close to the hardware.
killermenpl@reddit
In most cases, it's not that different. As long as you're using standard library, and the libraries you use have ARM support, you will most likely not have to do anything special. However, you never know if there won't be some subtle bug or performance issue because you assumed something about how the CPU works, and it's just a tiny bit different on ARM.
The dev has to spend time verifying that their software works on ARM, just in case. That takes time, which in open source is a very limited resource. Verification also requires the dev to have some ARM hardware, cause testing on a VM is never as good as on real hardware.
Add to that the complication of ARM having multiple versions currently in production. Most of it is at least somewhat backwards compatible, but you still need to decide which versions you're supporting. And of course, all the versions also require verifying that the software works
thsnllgstr@reddit
Manufacturers need to work with upstream just like Intel and AMD do
PraetorRU@reddit
ARM is already supported as a whole in linux.
The problem with ARM is that it allows any vendor to make their own complex chips with ARM building blocks, and such chips from different companies have very different internal structure. And for such chips to have support in linux, you either have to opensource everything, so people can write compatible drivers, or write drivers yourself. Reverse engineering also works, but since there's no solid standard, it's pretty much wasted time as by the time you'll be able to more or less get an idea how to support this hardware, a new version of a chip may arrive that has very few in common with the previous one, so you're always trailing far behind. With x86 it's different as both Intel and AMD are providing specs and drivers for their CPU's and for quite some time doing it before a new product even launched.
So, theoretically ARM support is already available, on practice it depends if chip creators decided to support linux or not.
MatchingTurret@reddit
It's generally not the SoCs but the stuff around them.
BangBang_McPew@reddit (OP)
As far as I‘ve gathered many manufacturers of SBC‘s connect the chips to the other hardware (like various sensors or other stuff that the manufacturer wants to cater to) with less standard connections rather than USB or PCIe I think.
PraetorRU@reddit
Sure, but result is the same. On paper ARM is supported, but ARM powered device as a whole is not.
BangBang_McPew@reddit (OP)
So, manufacturers should stick to more stanards and provide documentation, that they currently don’t do?
PraetorRU@reddit
Yes, lack of standardization makes it very hard to support devices. Everyone doing their own things and not providing drivers or specs.
xtifr@reddit
Debian has supported ARM for many, many years, and they're about as general purpose as a distro gets! I don't know the details of how they cope with incompatibilities between various ARM-based devices, but my understanding is that they do have mechanisms to help them cope.
You may be able to learn some from their Supported Hardware page, which seems to have quite a bit on ARM, which I barely skimmed. If you want more, you may be able to contact their ARM team.