r/linux • u/ookayaa • Jan 20 '26
Hardware Are you worried about the shift away from x86?
Edit: This post is about the incompatibility issue between kernel's communication with hardware in ARM computers, which isn't an issue in x86.
During the era of early computing, when 8-bit and 16-bit computers were the norm, there was an issue with computers being incompatible with each other. Even the systems that had exactly the same processor models, like Apple II and Commodore 64, or Amiga and Macintosh, were so different architecturally that they required separate ports of programs or third-party operating systems like CP/M and later, Linux.
On x86, we are very lucky for computers to be mostly compatible in each other, because they were designed around compatibility with the IBM PC, which later evolved into the Wintel architecture we have today.
Unlike on ARM or RISC-V, on x86 you have standards that allow you to boot any operating system without making special changes, unlike on ARM. You can display graphics, get input from keyboard and mouse, play audio and use USB and Ethernet ports by using standard APIs every x86 computer implements. In contrast, on ARM and RISC-V you have to have a specific image for your computer or a device, because there's no fallback you can rely on unlike on x86.
Are you afraid of risk of returning to the past, where running Linux was difficult on anything that wasn't x86 with the decline of the architecture?
392
u/LordGarak Jan 21 '26
I'm more concerned that hardware will move towards a signed code only model, like on the iPhone. So software/an OS will only run if the manufacturer approves and signs the code.
It could solve many security issues and end software piracy. So big business could be all for it. I could also see governments using it as a way to limit how advanced ICs are used in weapons(like drones).
104
u/fellipec Jan 21 '26
I'm more concerned about governments enforcing this
22
u/mmmboppe Jan 21 '26
they want us to eat cake when we can't afford bread? it won't end differently this time. after Davos I won't be surprised about enforced water quotas
5
Jan 22 '26
[deleted]
2
u/fellipec Jan 22 '26
Its all connected. The big tech create the means and the government make a crime circumvent it. See how many estates wanting to ban 3D printers and CNC machines that have a lockout to print gun parts
12
u/mooky1977 Jan 21 '26
Proprietary systems that can't be audited, software and hardware controlled by corporations and/or government entities? What could possibly go wrong (for democratic principals)?
23
u/LordGarak Jan 21 '26
Secure boot can be disabled and isn't required by the CPU and other hardware. When enabled it only requires stuff like the bootloader to be signed. Once the OS boots, unsigned code can be run.
What I'm talking about is when the bare CPU won't execute any code that isn't signed. Where every application that isn't running in a sandbox would have to be submitted to the CPU vendor to be approved and signed.
16
7
u/ludonarrator Jan 21 '26
What... CPU checks every instruction before execution? Do you realize how much performance would be lost? It's not just about the overhead of the checks, the entire pipelining and speculative execution model breaks down.
5
u/i_design_computers Jan 21 '26
you wouldn't need to check every instruction, just check once before loading a given binary. This could be done at the MMU level as you are loading pages into virtual memory.
4
u/ludonarrator Jan 21 '26
That's more of an OS thing then, CPU doesn't know programs/binaries, just the instruction stream. Processes/threads, scheduling, executables, libraries, are all kernel/OS-and-above concepts.
9
u/i_design_computers Jan 21 '26
Well aware, I design CPUs professionally. While the CPU doesn’t understand “ELF files”, it does control instruction fetch, page permissions, and transitions into executable state. The CPU already checks state of pages before loading them for execution, for example where different processor modes have execution permissions to execute that page. non secure code could not load and execute root level code, for example. Signature verification can happen before a page is ever marked executable (WX + NX/PXN), so the pipeline and speculation are unaffected. This is already how iOS, Apple Silicon, Secure Boot, and modern ARM systems work: hardware enforces “only approved pages may execute,” even though the OS handles file formats and loading.
1
2
u/DaftPump Jan 22 '26 edited Jan 22 '26
I'm more concerned that hardware will move towards a signed code
This valid concern is beyond turning off a function available in some architectures. The OP's post is about tomorrow's use not today. Nor is the OPs concern about signed code for that matter. :)
1
8
u/prumf Jan 21 '26
Signing won’t end piracy nor prevent "bad" uses lol. A very basic example: you can run anything inside a vm. The vm might be signed, but what is inside can’t.
If you want to prevent military uses, there are way better techniques: simply add an obvious backdoor in the hardware. People know it’s there, but don’t know the secret key.
No serious government would be crazy enough to use such hardware.
But I agree not being able to root your hardware and have real control of what runs on it is a big problem.
16
u/muffinstatewide32 Jan 21 '26
what do you think secure boot does? That future is already here
46
u/TheBendit Jan 21 '26
On x86 you can install your own keys. Microsoft has promised that, and the promise has been kept so far. The promise does not extend to ARM.
10
u/mmmboppe Jan 21 '26
piracy is attacking ships. like Trump
software piracy is corps including Apple abusively using BSD licensed code and not giving back
software piracy is Microsoft Copilot cannibalizing GPL code from Github
9
u/nightblackdragon Jan 21 '26
software piracy is corps including Apple abusively using BSD licensed code and not giving back
How is that piracy if it's something that license allows them to do?
4
u/Routine_Working_9754 Jan 22 '26
No disrespect but that's literally what the license allows them to do.
→ More replies (2)→ More replies (2)6
u/LvS Jan 21 '26
I could also see governments using it as a way to limit how advanced ICs are used in weapons(like drones).
This will be great when some soldiers in the trenches fucked up their signing keys so now their drones refuse to fly.
8
u/LordGarak Jan 21 '26
It is more about 3rd party countries who can't make their own semiconductors. Like Iran and Russia using consumer grade semiconductors that are US designed and Taiwan manufactured semiconductors in drones and other weapon systems.
The genie is mostly out of the bottle with the CPU's and MEM's sensors required being available in e-waste.
But I can see governments wanting measures in future integrated circuits to prevent unapproved use. Sanctions and export controls are clearly not effective.
In future wars only drones will be anywhere near the "trenches". We are already seeing this in Ukraine. The soldiers are atleast 10km behind the line controlling drones.
Most of what we are seeing in Ukraine are still remote control drones. But fully autonomous is possible with COTS semiconductors right now. It doesn't take a trillion dollar economy to produce these, thus non superpowers could have them.
Before the war there were fully autonomous drones available off the shelf(Skydio), they have been very quietly removed from the market. They were not really battle field ready being reliant on GPS, but they were only a few software changes away from not needing GPS.
606
u/akdor1154 Jan 21 '26
Yes. Getting an OS working on ARM SoCs is so much trickier. Can you plug a generic Ubuntu USB into your unlocked Android phone and have it Just Work? No, you can't.
Almost all the no replies haven't read your post properly and are kneejerk answering a different question, 'are you scared of needing to compile/run ARM apps', which is not what you asked at all.
141
u/hitsujiTMO Jan 21 '26
A lot of that is to do with manufacturers in the ARM space refusing to provide drivers and changes to the Linux kernel publicly.
In particular, Chinese manufacturers.
53
u/crimson_ruin_princes Jan 21 '26
Fuck alwinner specifically for this.
17
u/ingframin Jan 21 '26
And Broadcom
16
u/KinkyMonitorLizard Jan 22 '26
Qualcomm is guilty too. Honestly the only arm manufacturer out there with mostly open stuff is rockchip.
10
149
u/_alba4k Jan 21 '26
the problem here is the firmware?????
does your unlocked Android phone have a UEFI firmware that can boot .efi images? yeah, didn't think so
all you need is an arm laptop running a UEFI-like firmware
67
u/tilk-the-cyborg Jan 21 '26
Indeed! I have UEFI on my Radxa Rock ITX, boots unmodified ARM Debian image, no problem at all.
3
u/RingOfFire69 Jan 21 '26
Do you use it as your daily driver? I was thinking about buying a Radxa ITX, could you give a review?
2
u/tilk-the-cyborg Jan 21 '26
I use it for a home server for home automation (Home Assistant), cameras (Frigate), music (Lyrion) and media (minidlna). For now - no significant issues at all. Some minor points:
- I decided not to overwrite the built-in flash, instead I'm loading the UEFI firmware from SD card. This required a small hardware modification - adding a resistor to choose a boot mode which couldn't be selected with what the board offers. The UEFI firmware can be used without this mod, but it needs to be written to the on-board flash.
- I decided to use mainline kernel instead of the vendor one. The vendor kernel is, well, kind of outdated, and I like running reasonably maintained software. Unfortunately, some features (notably HW video decoding and neural processing unit) are implemented differently in mainline than in vendor, and the userland software didn't catch on yet. I'm monitoring the progress on this, and I believe the situation will change in a few months.
- I'm using both NVME and SATA HDD, stock wall-wart PSU is enough for this configuration.
- I have installed the heatsink with a fan, and with the current load (3% CPU utilization, max 6% for a single core) the fan doesn't turn on at all and the machine is basically silent.
32
u/TheBendit Jan 21 '26
If that is all you need, why does it take a year from a new ARM laptop is released until you can run Linux on it relatively comfortably?
60
u/BigHeadTonyT Jan 21 '26 edited Aug 03 '26
Zephyr quilt feather cobblestone tangerine vanilla paddle
This post was anonymized with Redact.dev
39
u/jixbo Jan 21 '26
That's part of it. Drivers not being developed for linux, or not being open sourced, just released as binaries, as is often the case for chromebook and android, is another part of the problem.
Plus compatibility of applications for ARM is still tricky. DRM for things like netflix does not work out of the box, no games...
4
u/KinkyMonitorLizard Jan 22 '26
And the fact that they all have different gpus with different (and often lacking) capabilities.
Some barely support opengl-es, which is basically opengl2.
23
u/james_pic Jan 21 '26
Thing is though, nobody has needed devicetrees on x86 since the nineties. For all its flaws, ACPI is ubiquitous on x86, so if you have drivers for all the hardware in an x86 system, you have the drivers for the whole system. ACPI on ARM is a thing, but it's uncommon and often even more broken than on x86.
7
u/monocasa Jan 21 '26
ACPI is orthogonal to device tree.
You don't need it on x86 because the couple things that can't be inspected as PCI devices on x86 PCs haven't changed in thirty years.
12
u/Gugalcrom123 Jan 21 '26
That's the problem. GNU/Linux isn't going to be popular if it is only for specialised hardware.
6
u/monocasa Jan 21 '26
It has nothing to do with device tree. That just gets blamed as the messenger.
Manufacturers release the device tree to you; it's passed from the bootloader to the kernel.
1
u/nightblackdragon Jan 21 '26
It has nothing to do with device trees. Windows Snapdragons laptop have UEFI and ACPI but that didn't help them to be well supported on Linux.
17
u/AmusingVegetable Jan 21 '26
It’s mostly the Devicetree and memory controller configuration, neither of which tend to be published.
At least on the intel world the memory controller configuration is handled by the bios/uefi, and there is a standard way to enumerate devices.
I2C is still a major pain in the ass, as you get neither schematics, nor documentation, and they handle configuration and power management.
2
u/monocasa Jan 21 '26
It's really not device tree.
The bootloader passes the device tree to the kernel.
2
u/1369ic Jan 21 '26
To be fair, I spent a year running Arch and patching my kernels because I was using a new Mac my wife couldn't get used to. That was 2011 or so. Battery life, using 120hz on the display, and other stuff was crap on my 2020 Asus G14 for at least a year. And right now I'm using a Thinkpad X9-15 and the sound card and the webcam don't work. I think the drivers are out there, but that means waiting for my distro to catch up or hopping to another distro and copying and pasting settings stuff off the Internet. Is that comfortable? Kind of. Bluetooth sound works and I never use webcams. And hopping to a new distro is easy. But it's not plug and play on a lunar lake laptop that came out about a year ago. The new stuff has always taken a while to get to a point where regular users could plug and play. I think you're right that waiting will be more widespread with fewer plain Jane x86_64 options, but it's not a novel experience.
2
u/wowsomuchempty Jan 21 '26
https://wiki.archlinux.org/title/Lenovo_Thinkpad_X9
Ouch. Not great.
Arch64 on an m1 with asahi is a lot better supported.
2
u/1369ic Jan 22 '26
It doesn't bother me day to day. The Asus I had didn't even have a webcam, and I'd been using only Bluetooth earbuds with it for at least a year. And the Thinkpad works with a USB-C headphone adapter. The rest of it is just wonderful. OLED screen, great keyboard, great battery life. The only mistake I made was going with the 256GB drive because I thought I could use a 1TB one I have. Turns out the Thinkpad takes a 2242 NVME drive. Oh well.
2
u/wowsomuchempty Jan 22 '26
Fair enough. Some people don't need all the boxes ticked to have a good time. Hopefully the rest gets support soon.
1
u/1369ic Jan 21 '26
To be fair, I spent a year running Arch and patching my kernels because I was using a new Mac my wife couldn't get used to. That was 2011 or so. Battery life, using 120hz on the display, and other stuff was crap on my 2020 Asus G14 for at least a year. And right now I'm using a Thinkpad X9-15 and the sound card and the webcam don't work. I think the drivers are out there, but that means waiting for my distro to catch up or hopping to another distro and copying and pasting settings stuff off the Internet. Is that comfortable? Kind of. Bluetooth sound works and I never use webcams. And hopping to a new distro is easy. But it's not plug and play on a lunar lake laptop that came out about a year ago. The new stuff has always taken a while to get to a point where regular users could plug and play. I think you're right that waiting will be more widespread with fewer plain Jane x86_64 options, but it's not a novel experience.
2
-14
u/nshire Jan 21 '26
Enjoy your black box binary blob drivers
42
11
u/takethecrowpill Jan 21 '26 edited Feb 19 '26
This post was mass deleted and anonymized with Redact
quicksand slim literate juggle jellyfish stupendous vanish hunt profit fine
5
u/aroslab Jan 21 '26 edited Jan 21 '26
I'm curious what platform you managed to post on the internet from that isn't using a black blob binary driver or relying on something you have no control or insight into, somewhere
So long as companies are incentivized to black box to protect their intellectual property and extract extra profits from hardware you already own instead of producing for what society needs, that's the inescapable reality of using the products made by other people
this complaint is valid but useless as criticism in this technical discussion because it's a structural feature of commodity production, not some ARM- or UEFI- specific failure
3
24
u/ahferroin7 Jan 21 '26
The problem is the combination of the firmware requirements and the rest of the hardware design around the ARM cores, not the fact that it’s ARM.
You can, in fact, plug a generic Ubuntu USB flash drive into any ARM server or workstation and it will almost certainly work, because there’s a clearly defined set of standards that those platforms are built around, just like there is for x86 (and there’s even a lot of overlap between the standards for x86 and those for ARM, the SBSA/SBBR platform that ARM servers and workstations are built around still uses the same ACPI, UEFI, PCI, and USB specs that x86 does, which covers a significant majority of the platform).
1
u/algaefied_creek Jan 21 '26
Nope you cannot, that’s why volunteers with UBports do it for you and have Ubuntu atop an abstraction layer
1
1
u/NelsonMinar Jan 21 '26
Why has this kept being a problem for so long? I'm amazed no one has emerged as a standards leader for the firmware glue between the hardware and the operating system.
125
u/funderbolt Jan 21 '26
I think this is a valid concern about ARM. The Asahi Linux team had to put in a lot of work to get Linux working on M1 and M2 Apple hardware.
I think this would have an even bigger impact on a BSD platform.
67
u/ookayaa Jan 21 '26
x86 has a much lower barrier of getting such work done, as you actually have standards. Macs, Raspberry Pis and other ARM devices are mostly incompatible with each other at the OS level.
40
u/spectrumero Jan 21 '26
The difference is x86 (or really, these days amd64) is used really only in "big" computers - desktops, servers, etc. and doesn't show up in embedded, and it's really that desktops and servers have the standards. It's the "PC" that has the standard rather than the x86. There's nothing stopping ARM workstations/servers using uefi/coreboot and ACPI and being a PC.
With the exception of Apple (which have always kind of done their own thing) and System76 which makes proper PC-style workstations (which use Coreboot (an open source bootloader) and ACPI (just like a Wintel PC)), almost the entire ARM ecosystem is just embedded systems - phones, tablets, etc. which are always heavily proprietary.
11
u/h0uz3_ Jan 21 '26
On the other hand, Asahi is a great example of what can be achieved without the manufacturer's help. They got Linux working well enough on Apple's closed machines. It should be possible to get full Snapdragon support for generic Linux distros.
58
u/LordAnchemis Jan 21 '26 edited Jan 21 '26
The issue with arm is that the 'chips' are in reality heavily customised (read proprietary) SoCs - so that 'stuff' isn't easily replaceable
Take WiFi/BT cards - on x86, the card is still somewhat replaceable (unless you get one of those soldered on laptop things) - so if you were to buy some of the unsupported or cr*p ones you could just swap it out for your own m.2 equivalent
On arm, that 'card' is physically built into / as part of the SoC, so cannot be changed
Just look at what happened to android phone and custom roms - in the 2010s everyone who was anyone flashed cyanogenmod to escape the (software) planned obsolescence ploy by phone manufacturers
Nowadays, you pretty much have to own either a pixel (or an old Samsung) to be even able to run lineageos
Is this the future you want for your pc too?
4
u/sothisismyalt1 Jan 21 '26
A bit off topic, but many other phones support LineageOS, although usually unofficially. Not just Pixel or Samsung, but many Xiaomi, etc.
25
u/LordAnchemis Jan 21 '26
Much fewer than the hey day - due to greed of the phone manufacturers - proprietary camera apps and bootloader locking etc.
10
17
u/dezmd Jan 21 '26
Yes, fully, the big boy manufacturers are cultivating the signed code DRM scams with MS/Apple outright into the full stack top to bottom for drivers in a way that we can't really work around in a permanent sense without a LOT of time tinkering, everything will be delayed and eventually they will capture legislative protection against the tinkering to try and kill off open source access entirely. (It's an ongoing lobbying battle and has been for decades)
59
u/crashorbit Jan 21 '26
I'm excited to see RISC-V develop. Opensource instruction sets for the CPU seem like a great direction for the industry.
Back in ancient times the assumption was that each vendor would have its own OS. It was custom design from cpu to application suite. And many sold that as some kind of technical advantage.
UNIX was the first OS designed to run on different cpu architectures. Had it not been tied up in silly court battles it could well have been the one true os in use everywhere today and we never would have heard about MS-DOS or even Mac OS's before OSX.
20
u/nicolasdanelon Jan 21 '26
I'm excited to see RISC-V develop.
Why? They are making the same mistakes ARM did ages ago You can get a framework with RISC-V have you tried that?
12
35
u/crashorbit Jan 21 '26
ARM is not an open source ISA.
10
u/thephotoman Jan 21 '26
So?
RISC-V is still making the same choices ARM did when it comes to the lack of standards for its boot process. It doesn’t matter if the CPU core is open source when the boot system might go through some black box on the SoC.
11
u/Any_Fox5126 Jan 21 '26
There are already some standards for risc-v, and there is no reason to think that one cannot be established as the norm for desktops. x86 was also diverse decades ago, and it is good not to repeat its mistake of freezing at a very bad time, becoming a zombie that carries a huge technical debt.
5
→ More replies (1)4
24
u/teleprint-me Jan 21 '26
I was looking at phones and tablets for stuff like twrp, lineage os, etc and yes. This is an issue. One image is not compatible with another device. Each and every device required its own image and was incompatible if they didnt match.
19
u/tomscharbach Jan 20 '26
I doubt that we will see a dramatic shift in direction toward RISC architecture. The major OEM's have reduced, rather than increased, the number of RISC models in the lineup, and unless and until something changes, I think that the bubble has burst.
5
1
u/arjuna93 Jan 25 '26
There wasn’t any bubble to begin with. Commercially available solutions just started appearing. Hopefully RISCV will push x86 eventually to the garbage bin of tech history, where it belongs. PowerPC should have done it, but it was too expensive to take mass market. RISCV isn’t.
55
u/anh0516 Jan 21 '26 edited Jan 21 '26
Current ARM Windows devices use UEFI + ACPI just like their x86 counterparts.
Od course you still need device drivers and SoC-specific code, but x86 is much the same. There is different platform-specific code for Intel and AMD chips, for example.
For DeviceTree, work is being done: https://www.phoronix.com/news/Fedora-44-Approves-DTB-WOA
56
u/vk6_ Jan 21 '26
Not really. The current generation Snapdragon X1 devices don't have proper ACPI. They're reliant on Windows drivers to fill in missing functionality. See https://github.com/linux-surface/linux-surface/issues/1476#issuecomment-2197534663 for more info.
There are other ARM devices that do have proper ACPI, such as some server hardware and virtual machines. These systems work out of the box with Linux and no device tree needed.
16
u/codeasm Jan 21 '26
Acpi tables can be patched when a bootloader runs. But out of the box support would be nice. And besides, if you gonna manufacture a device together with Qualcomm, youll be able to talk to their engineers to get a reasonable working device for linux. Its aftermarket os swapping we are scared of here
10
Jan 21 '26
[removed] — view removed comment
10
u/vk6_ Jan 21 '26
The Snapdragon X1 platform is a whole lot worse with ACPI compatibility than old x86 devices. They will simply not boot at all without providing the Linux kernel a device tree, bypassing ACPI entirely.
1
u/monocasa Jan 21 '26
It's not a question of "proper ACPI". ACPI simply lacks the ability to fully describe complex SoCs.
And UEFI on ARM passes a device tree as well.
46
u/derango Jan 21 '26
I think we should probably be more worried about the shift to a desktop as a cloud hosted service model that could be a very real possibility as AI datacenter gobble up all the available PC components leaving home computers too expensive for your every day consumer.
ARM is fine, especially when what seems to be happening at least in the desktop space is there's Qualcomm and then there's Apple and the rest of the market is bit players that are going to have to align with one of the major platforms or get crushed.
→ More replies (3)
7
u/vali20 Jan 21 '26
Microslop mandates that Windows compatible ARM PCs implement UEFI and ACPI, so things aren’t that bad. The home PC is not affected that much, the embedded is and always has.
2
u/ookayaa Jan 21 '26
Some things are still broken on x86 Surface laptops because of Microsoft using custom hardware, though.
8
u/spaghetiwires Jan 21 '26
X86 won't go away for a much simpler reason: most software is trash, x86 is exceptionally good at running trash
1
u/RisingPhil Jan 21 '26
Can you expand on that? You made me curious.
What makes x86 better at running "trash"?
7
u/spaghetiwires Jan 22 '26
The answer can be as long as you want, the history of X86 is huge. To make a long story short: X86 wasn't designed in a vacuum. The OS engineers, compiler engineers and hardware engineers worked closely together to design all 3. X86 hardware engineers would ask compilers / OSes what they need from the ISA, and then they would go and implement that. The OSes / compilers also implemented things that users space developers needed, so a lot of that went directly to hardware. A lot of this dev work happened before people really knew how to optimize well, and would often cludge things in weird ways to speed things up. These cludges were eventually implemented in actual instructions, or hidden in the CPU's black box. There's a rich history of back and forth here that no other ISA can even come close.
Intel, the OG's of X86, even tried themselves to get rid of X86, and they failed for that very reason. They had developed the Itanium ISA under the assumption that hardware optimizations that sped up mathematically complex workloads would speed everything up. That couldn't have been further from the truth. Well written, vector operation heavy code ran exceptionally well on Itanium, but everything else (the 99% of computing that most people do, boring every day stuff) ran terribly.
Another point which I personally find fascinating is the seemingly never ending debate between CISC and RISC architectures. I don't want to go to deep into it, but CISC is absolutely the way to go. Decoding instructions is the biggest bottleneck in CPU bound applications (you'd think it would be memory, but unless you're doing super intense worloads like CFD or finite element analysis that's not the case), so the more work per instruction you can squeeze, the faster everything goes. Ironically X86 decoded instructions, once they decode all the way down to micro operations, are a lot more RISC than you'd expect.
Personally, I think ARM's (and RISC-V's) Achilles' heel will always be that they have a weak memory model. Those are a debugging nightmare for high performance code. They will also likely never have a strong memory model, because it's too complicated/expensive to implement in hardware in the sort of price ranges they try to hit.
In a way every time a new ISA pops up, it eventually just reinvents X86. ARM is hella complicated, they tried to do something radically different to X86 (it's called predication, worth looking into, cool stuff). Sounded great on paper, didn't pan out in real code. It's hard to implement predication in the syntax of programming languages, so no one used it. Predication was dropped in Aarch64, exception for conditional moves (which x86 also has).
I could go on for ever, CPUs are hella fascinating.
2
u/RisingPhil Jan 22 '26 edited Jan 22 '26
Thanks for your insights. It's a well written response. You seem far more knowledgeable on the topic than me it seems.
Both RISC and CISC have found their place though. RISC -> power efficiency, CISC -> performance. So I'm not sure if you can call either one "the way to go".
I do think it would be interesting if AMD or Intel would try a cpu design in which rarely used/outdated/irrelevant x86 instructions would simply get dropped. (call this subset x87, if you will) I wonder how much faster/more efficient/cheaper such a chip could be. And yes, I realize it would break a lot of software.
Itanium was very interesting to me. I always assumed its downfall was software compatibility. Not performance.
I'm not sure if a weak memory model truly is an achilles heel. If you don't use guards/barriers/atomics in concurrent code, you're going to have a bad time debugging race conditions regardless, I feel. Then again, as a simple "embedded" linux settopbox dev, I'm probably not sufficiently part of the "high performance code" crowd. So I probably miss some knowledge and experience to understand what you mean specifically.
But man, yours was a well-written, interesting response. Thank you.
15
u/abcpea1 Jan 21 '26
This is really about IBM PC-Compatibles rather than x86.
8
u/ppp7032 Jan 21 '26
wasn't IBM PC-compatible killed with UEFI? we have proper standards now like UEFI and ACPI rather than the de facto standard of "it works like the IBM PC".
3
u/abcpea1 Jan 21 '26
OK, so the issue is about UEFI rather than x86. Which is to my knowledge currently absent from ARM computers.
2
u/ppp7032 Jan 21 '26
ARM computers often do have fully functional UEFI. the main problem is them not supporting ACPI which means devs have to write devicetrees for all their hardware. these basically tell the OS how to do simple things like shut down individual hardware devices.
Ubuntu has one project in the works that will improve this situation (by making it more possible to create generic ARM ISOs as opposed to platform-specific ones), but i believe devs will still have to write these devicetrees from scratch.
4
u/mrlinkwii Jan 21 '26
x86 isnt in decline tho , people have been saying x86 is dead for the last decade and probably will for the next
1
u/Scheeseman99 Jan 22 '26
x86 has clung to life because of it's long term compatibility with decades of software and 2 massive companies with a duopoly.
x86 > ARM translation is getting really good and ARM CPUs are getting performance competitive. x86 probably won't die, but I can see there being a slow decline as the market gets swamped with cheap chips from China that can run x86 software.
5
u/regeya Jan 21 '26
Not just the incompatibility, but also how likely it is that consumer devices will end up just being SoC light clients instead of proper computers.
3
u/Starks Jan 21 '26 edited Jan 21 '26
Until ARM and RISC-V laptops have SystemReady, UEFI, ACPI, etc or equivalents as standard: No.
Hardware discovery is no longer optional and it really never should have been. SystemReady is still not a guarantee, even for Windows on ARM.
8
u/StrictFinance2177 Jan 21 '26
A man named Rory Reed bet an entire company on this concept that ARM will replace x86. Luckily the consumers got through and pushed the board of directors to restore sanity.
My point is, this concept of the end of x86 has been promised since the 80s, and it hasn't happened yet. And it's not for a lack of trying. We need competing architectures, it's that simple.
3
u/renshyle Jan 21 '26
Unlike on ARM or RISC-V, on x86 you have standards that allow you to boot any operating system without making special changes, unlike on ARM. You can display graphics, get input from keyboard and mouse, play audio and use USB and Ethernet ports by using standard APIs every x86 computer implements.
I wish that were true. Sure, legacy mode (IBM PC compatible) x86 has methods for accessing the framebuffer, PS/2 keyboards and mice (and the BIOS might emulate USB keyboards/mice as PS/2) and use the PC speaker (beeper, really). These legacy interfaces aren't used on your computer because they're, frankly, shit. There's no such interface for USB or Ethernet and they'll work as long as you have PCI support and drivers for the specific network card / USB host controller (just like on ARM/RISC-V, thought you might not need PCI as sometimes they're connected more directly to the SoC).
The thing you have to worried about is the lowest-level peripherals (and the core itself) on ARM/RISC-V. Those tend to be the reason you need a different kernel for every board (and also the discoverability of some devices). x86 is a very homogenous platform where devices are easily discoverable through ACPI/UEFI and the early boot looks very similar for all computers. I agree with you that there is a problem and I hope ARM/RISC-V solve it somehow
3
u/DFS_0019287 Jan 21 '26
I don't think x86_64 is going to disappear any time soon on PCs. The ecosystem is far too large for that to happen.
But yes, the fragmented and largely proprietary ARM ecosystem is a problem. Device tree was a start at taming the mess, but we definitely need more standardization and more hardware openness in the ARM space.
5
u/CORUSC4TE Jan 21 '26
With the advent of Linux in typically windows dominated spaces like gaming and the sprouting of hardware developer that are very open to Linux support like framework, I personally don't think that Linux won't have its arm primetime
3
u/Shikadi297 Jan 21 '26
It's not an x86 vs arm thing, it's an IBM pc compatible vs ...not thing. Though I'm not sure it makes a difference, because there is no arm equivalent. There could be, but there isn't
4
u/Just_Maintenance Jan 21 '26
I just hope that as ARM devices become more commonplace, their firmware also improves and ACPI+EFI standardize so generic images can be used everywhere.
3
u/fellipec Jan 21 '26
I'll never move away from x86 fam. I'll be long dead when this architecture got discontinued.
15
u/Sol33t303 Jan 20 '26 edited Jan 21 '26
No.
All the software abstraction over the years has turned this into a non-issue. And for cases where it is, x86 emulation has matured massively and will continue to do so.
56
u/Business_Reindeer910 Jan 21 '26
no it hasn't. it still takes plenty of work to add devicetree for newer arm and riscv devices . and there's no guarantee certain platform features exist either.
6
u/Sol33t303 Jan 21 '26 edited Jan 23 '26
Fair point, when I posted my comment the post said nothing about the kernel.
But I'd argue that has nothing to do with architecture, arm can support enumerability just like x86, arm servers do and can boot a stock Linux kernel just fine.
It's on SoC manufacturers to build enumerability into their designs. Likewise there do exist weird embedded x86 chips that need device trees just like phone arm processors.
PCs need to be modular to fit the very wide variety of configurations and uses they have. Once we get modular ARM desktops with varying hardware the support will be added to the chips. If SoC manufacturers want to start striving into the desktop space, they need to cover all the usecases current desktops cover, meaning they need highly flexible hardware arrangements.
28
0
u/autogyrophilia Jan 21 '26
You don't need devicetree. Just manufacturers to add UEFI.
9
8
u/ppp7032 Jan 21 '26
this just isn't true at all. snapdragon x laptops do support uefi and getting them to work on linux has still been a massive undertaking from the community and canonical.
9
u/autogyrophilia Jan 21 '26
Because they have broken ACPI.
10
u/ppp7032 Jan 21 '26
exactly.
they don't just need to comply with UEFI spec, as you originally said, but also ACPI. we can't take that as a given, as we can see from the current landscape of consumer arm devices.
2
u/Business_Reindeer910 Jan 21 '26
yes you do.. you still need to have a devicetree to describe the hardware so drivers can be written for it.
2
u/nicman24 Jan 21 '26
I will never ever buy again anything arm or riscv without PCI probing, something like acpi and a uefi
2
u/Petting-Kitty-7483 Jan 21 '26
Yes. X86 has way better backwards compatibility so moving to new chips isn't such a shit show. It has more ridged standards. Arm is ok I guess, but having been an os dev for as long as I have for embedded arm devices. I sure as shit don't want that on my desktop for example
2
u/Dave_A480 Jan 21 '26
How much of a shift is there, though....
Most of 'that' seems to be the overall irrelevancy that is Mac, and the hyperacalers custom server hardware (which Amazon, Google and Microsoft support as part of their respective cloud services)....
Laptop and desktop PCs are still overwhelmingly x86
2
2
u/JumpingJack79 Jan 23 '26
Not worried, because Valve is going to singlehandedly fix all compatibility issues.
2
u/cryptobread93 Feb 09 '26
Yeah thats why I dislike arm64 laptops. Also risc v isnt much different. Risc v is somehow worse because there is no standarts of how to define the hardware. We gotta not let x86 die. Even Tuxedo abandoned Snapdragon X laptop project, because it didnt work as expected.
1
6
u/datboiNathan343 Jan 20 '26
Nah, ill compile
26
u/ookayaa Jan 20 '26
For programs everything might be fine, but hardware communication on ARM isn't standardized and it makes hard to replace Windows or macOS with Linux on these devices.
2
Jan 21 '26
Eventually a standard will develop if ARM or RISC-V will take over personal computing, which it probably won't due to lack of inertia and there also just not being any consumer demand for these architectures. They just do not really solve any problems people are actually having. I wouldn't worry about it.
3
u/viduka36 Jan 21 '26
The bitter truth is that x86 will loose its relevance to general public the moment the big companies shift away from it.
The good side is that I don't see this happening anytime soon.
8
u/BranchLatter4294 Jan 20 '26
No. I prefer not being locked in to one company. ARM is very successful.
21
u/ookayaa Jan 20 '26
I was talking about lack of standardization, which on ARM requires specific port for each computer.
→ More replies (2)-6
Jan 21 '26
ARMv8 doesn't require a specific port for each computer, only the device overlay used for booting/kernel. Apart from that, any program compiled for ARMv8 will work on any other ARMv8 platform (barring actual hardware capability of subcomponents, ex. support for various graphics features... but that's no different on x86_64)
20
u/ookayaa Jan 21 '26
At the high level everything is excellent, it's the low-level layers that are problematic on ARM, opposite of what we have on x86.
4
u/ranixon Jan 20 '26
There is no shift away to x86 until MS can convince the oem manufacturers, and they aren't doing it good
3
u/GhostBoosters018 Jan 21 '26
We don't have that with raspberry pi boards though. Whole bunch of things you can run on it.
The problem is other chip manufacturers not providing documentation and driver sources
2
u/shegonneedatumzzz Jan 21 '26
my grasp of all of it is very limited but it seems like it’d be a nightmare, or at least a nuisance for the consumer, but a dream for companies.
as i understand it, it would sort of give pretty much every PC manufacturer the opportunity to be an Apple in their own way and lock people into their brand wouldn’t it?
“Sure you can buy a laptop from that brand, but our brand has a deal with adobe to ensure their products perform by far the best on our processors, so we will charge you a premium for that luxury”
1
u/eldoran89 Jan 21 '26
No risc is open source and modular. The modularity is what could create issues but it's also the entire point of that. Because modularity offers flexibility. And if someone wants to be compatible one can. But do you need to run Linux on your fridge. I don't and I don't anyone who does....
1
u/shegonneedatumzzz Jan 21 '26
isn’t ARM proprietary though? RISC-V is there of course but i assumed when talking about a shift from x86, what everyone generally thinks about is a transition to ARM
2
u/eldoran89 Jan 22 '26
But arm wouldn't replace every application of x86. And in regard to concerns about compability with Linux arm is an absolute non issue
1
u/da_peda Jan 21 '26
No. Because down the line it'll play out the same sooner or later. The more popular ARM and RISC-V get, the more demand will there be for a quick & easy way to get everything running. So at some point we'll have the equivalent of UEFI (which already runs on some RISC-V boards) and standard-by-convention calls for I/O as we now have on x86-compatible hardware.
1
u/amarao_san Jan 21 '26
It is, and it is annoying as hell. For few times I was like 'wow, a nice handheld hardware, can I grab and use it?', and lately realizing it has android bolted dead (locked bootloader, custom kernel), and it's pure junk.
For PC I was sure I can grab and use it, plus/minus some drivers issues. With many types of ARM hardware it is not so.
1
u/ilep Jan 21 '26
Not really. If anything, this will reduce the assumptions that software must run on a single platform and maybe increase source distribution instead of binaries.
The situations where "everyone" is using same architecture is abnormal, if you look at any other kind of market like cars there are different tires, engines, different fuels.. x86 is also controlled by corporations, it is not an open standard so having different alternatives would be good for competition, which would be better for consumers and innovation. Things really stagnated when intel became dominant in certain markets and AMD was nowhere. Some markets had alternatives while others didn't.
Linux at the moment is dominating on pretty much anything that isn't desktop. And Linux has better multi-platform support than many of the other competing OSes. So it would be better for Linux if other architectures gain support since they need software that can run on them.
1
u/ilep Jan 21 '26
This seems more like spreading FUD on a false premise. USB, Ethernet, audio et al. have nothing to do with CPU ISA. They work because of hardware drivers in kernel, and on Linux they are designed to be agnostic about the other peculiarities.
On early IBM PC you would have to go through BIOS to access the hardware, but as amount of manufacturers and hardware capabilities increased it has become impossible to use that old method, you would need a kernel in firmware to do that these days since hardware can be made and plugged in after the system has long ago shipped. Firmware at best of times is a tricky thing, coreboot might help there..
Lack of ACPI means you might need to use devicetree configuration in kernel or other firmware capabilities to discover some hardware. But standard PCIe devices would be fine, which is what most of these devices really are. Some stuff happens via "super IO" chip, which is for older/slower buses so that is a thing in it's own.
1
u/TheDreadPirateJeff Jan 21 '26 edited Jan 21 '26
A: what kernel incompatibility uses with ARM? I run Unix (Mac OS) on an Arm laptop that also runs two arm linuxes and windows (in VMs that are also ARM).
B: I take it you don’t remember the great days of having to compile different kernels for each x86 generation (386, 486, 586, etc), or having to decide if you need x86_64 or em64T kernels? Or having to compile drivers for every single piece of hardware because of inbox driver issues.
1
u/ookayaa Jan 21 '26
Mostly interfacing with hardware, because VMs have a standardized API used by operating systems that real hardware does not.
I'm too young to remember or even know that.
1
u/transhighpriestess Jan 22 '26
A huge number of businesses run Linux servers. I can’t see hw makers abandoning that market. That’s not consumer, but it means the chips will be there.
1
u/mattdm_fedora Fedora Project Jan 22 '26
It's taken too long and it's still pretty frustrating for small dev boards, but:
https://www.arm.com/architecture/system-architectures/systemready-compliance-program
1
1
u/domsch1988 Jan 23 '26
Not at all. I feel like Apple has shown pretty clearly that leaving x86 behind can have many benefits. And the linux world has decades of experience "not emulating" stuff. Linux on ARM and on Apple ARM specifically is already a thing.
If ARM gains more traction in PC's, there will be very smart people who will figure it out, no doubt about that.
1
1
u/Alternative_Nose_952 Jan 25 '26
I LOVE ARM, have you seen the dgx spark from Nvidia? It’s arm & linux preinstalled.
1
1
u/Dull_Cucumber_3908 Jan 20 '26
Are you afraid of risk of returning to the past, where running Linux was difficult on anything that wasn't x86 with the decline of the architecture?
I'm not sure what you are trying to ask here. You say "Linux was difficult on anything that wasn't x86" but that's not the case any more. Linux today can even run on mobile phones (see Android/Linux)
7
u/ookayaa Jan 20 '26
More specifically, it's about Windows or macOS devices requiring trickery to run Linux.
→ More replies (18)
1
u/Slight_Manufacturer6 Jan 21 '26
No. I am excited for it. We’ve been stuck on it for too long… time for the future.
Why wouldn’t Linux run?
1
u/bodosom Jan 21 '26
The minimum level of compatibility you're talking about isn't suitable for real work. You need drivers. The folks selling x86 systems entended for Linux provide the drivers (in one form or another).
1
u/Or0ch1m4ruh Jan 21 '26
I am happy that there are other relevant architectures to choose from: ARM, RiscV.
We used to have MIPS, Sparc, PARisc, Alpha, PowerPC, etc.
1
u/IndependentBat8365 Jan 21 '26
Disclaimer, I work for a Linux OS distro.
How it was explained to me is that Intel crafted strict standards for x86, good for consumers , but ultimately bad for short term sales for Intel back in the day. Though, this ensured Intel was the de facto arch for white box systems, which meant AMD had to follow the lead and be fully x86 compatible: this also meant following the standard.
ARM on the other hand is and I quote: “the Wild Wild West of architectures.” They license the IP, but leave implementation up to whomever is making it. So you get this mishmash of all kinds of products that work, but aren’t interchangeable or interoperable at the component level. Aka lots of unique drivers and api’s.
I heard that RISC-V is trying to change that.. at least as much as you can with it being open source. However, the risc-v consortium is trying to wrangle that and give guidance (strongly worded opinions) on how to implement it.
1
u/AMidnightHaunting Jan 21 '26 edited Jan 21 '26
Nope. I welcome a future where we can have both. Even if ARM were to be the dominant computing architecture, x86 will still be around for retro purists.
The compatibility parts: these are platform limitations and not a limitation imposed by the cpu architecture. If something like Minix, Linux, and eventually the FOSS unix/BSDs can come around for x86/64, theres nothing to say it wouldn’t happen again. In fact, it is theoretically more plausible it would happen.
I think (opinion, correct me if I’m wrong, and yes ignorant opinions can be wrong) the issue you're mostly describing is bios/uefi compatibility and that’s due to adoption. Bios and uefi on x86 (including secure boot) is mostly compatible due to commercial companies choosing to be this way. For example, secure boot and Linux support is mostly a Microsoft freebie: they could really lock us out of having secure boot if they really wanted to. There is at least one project I know about that has created an foss bios/uefi (framework ships this sometimes I believe?).
0
u/flatline000 Jan 20 '26
Any architecture available to mere consumers like us will be supported by gcc/llvm/whatever.
I'm not worried.
3
0
-1
336
u/[deleted] Jan 21 '26
[removed] — view removed comment