3 ms·
Everyone is commenting on "let x86 die" and I would agree if it was just about ISA. But the problem is that x86 has some-sorta-total-disaster-of-a-standard for
by tliltocatl 2y ago
Everyone is commenting on "let x86 die" and I would agree if it was just about ISA. But the problem is that x86 has some-sorta-total-disaster-of-a-standard for peripherals and configuration (ACPI, UEFI and so on) and you can actually buy a computer that is compliant and will run Linux out of the box, even if with some glitches.
ARM is a handful of totally incompatible SoCs and you are totally dependent on SoC integrator providing support (hopefully in the form of throw-over-the-fence-and-forget Linux kernel headers, but more common are just kernel binaries) to run it at all. In theory UEFI supports ARM, but can I buy a desktop ARM processor that does?
And this is going to be worse with RISC-V because hardware vendor are not interested in providing platform compatibility. So we would be back in pre-PC era platform-wise.
There is no replacement for x86, not because it is impossible to replace, but because no vendor is interested in making one.
- sidewndr46 2y agoI'm pretty fearful of the death of x86 because it probably implies the death of easily accessible hardware for general purpose computing. If I go to a big box store and buy any AMD or Intel laptop I can throw whatever kernel and userspace I want on it in a few minutes. The Chromebook movement has already been working to close this off. If x86 dies we will wind up with a bunch of devices where step 1 is "run this code to exploit a buffer overflow to bypass the locked bootloader. Only works on v1.2 PCB revision 7"
- yjftsjthsd-h 2y ago> The Chromebook movement has already been working to close this off. ? Chromebooks are like one of two decent non-PC options (the other is Macs). AFAIK every Chromebook can be flipped to developer mode in <5min and then you can boot anything you want.
- janice1999 2y agoThat is not necessarily true, especially for older Chrombooks. Distros like GalliumOS existed for a reason - many Chromebooks needed drivers not available upstream for things like touchpads. Not all have UEFI Firmware support either. There is a great resource though for people who want to boot regular Linux - MrChromebox[1]. [1] https://docs.mrchromebox.tech/docs/known-issues.html https://docs.mrchromebox.tech/docs/known-issues.html
- yjftsjthsd-h 2y agoIt's true that you'd need drivers for your hardware, but that's not really special; I own plenty of normal x86 PCs with hardware that Linux doesn't have drivers for. That said, AIUI Google is generally pretty good at pushing drivers upstream these days. And the aftermarket UEFI is a great thing - it means that Chromebooks are probably the easiest+cheapest way to have a coreboot machine - but you don't actually need that; the default firmware will, in developer mode, boot any properly-formed image, which is a touch annoying but does in fact let you boot any OS that handles that boot system without replacing the firmware. One of my main machines right now is an ARM chromebook that runs postmarketos on the stock firmware.
- sidewndr46 2y agoWhat hardware does Linux not have drivers for? I'm not counting WiFi cards connected via USB or PCI-E slots. Those don't have anything to do with x86. Also the reason why those commonly don't work is because the underlying hardware is crap.
- yjftsjthsd-h 2y agoThe annoying thing is that it doesn't need do be like this; as you note, ARM & RISC-V are perfectly capable of doing UEFI et al., but everyone apparently prefers to save a tiny bit of money and just not bother.
- anthk 2y agoDoesn't RISC-V computers have something akin ISA<->APIC? And yes, ARM it's a clusterfuck all-in-one were every device it's bound to a kernel version and good luck upgrading the kernel with free devices. The device-tree it's a light Tivoization.
- pjmlp 2y agoYeah, PC was also supposed to be like the other ecosystems, but IBM got fooled by Compaq in a clever way they failed to prevent. PS2 and MCA architecture was a kind of attempt to recover control over the PC, but it was too late.
- AnimalMuppet 2y agoYup. Microchannel had higher performance than ISA, but you were locked in to IBM. People instead wanted lower cost and the freedom to be able to use all the existing cards. This was a fundamental misunderstanding by IBM. The PC exploded, not because it was from IBM, but because it was not locked down. IBM wanted to re-create their locked-down world; the market was never going to go where IBM wanted it to.
- afr0ck 2y agoWhat you wrote doesn't make any sense. Arm has DTB [1]. Most SoCs re-use a lot of hardware IP blocks and they require very little modifications to DTB files in the kernel and device drivers to get them working. PCIe and USB support discoverability so no issue from that side. Arm ecosystem is cleaner in my experience and learned from the mistakes of the past. Arm CPUs are still not as fast as high-end x86 chips, but it's just a matter of time before that market is also eaten by Arm. [1] https://community.arm.com/oss-platforms/w/docs/525/device-tree https://community.arm.com/oss-platforms/w/docs/525/device-tr...
- janice1999 2y agox86 has a a mature open source driver system especially for graphics. Although there are great reverse engineering efforts (Collobra and others), with ARM SOCs you can find yourself dependent on blobs for graphics and locked into ancient and insecure Android and Linux images.
- snvzz 2y agoYet people are running games[0] on their MILK-V Jupiter boards, using the same discrete GPUs that you would on an x86 system. Meantime, companies such as PowerVR or ARM are funding their own open source mesa3d drivers. 0. https://box86.org/blog/ https://box86.org/blog/
- tliltocatl 2y agoGraphics is "fixable" as you can stick a PCIe video card into an ARM or RISC-V system that has PCIe and it will work. Integrated graphics is a mess, that's true. But then so is NVIDIA drivers (Do they ever care for graphics any more or is it just LLMs go brrr for them?).
- tliltocatl 2y ago> require very little modifications to DTB files DTB only describes what blocks are present, if the kernel doesn't know what "crapvendor,lockinregulator" means it would not work. Vs ACPI that actually provides drivers, however crappy.
- 2y ago
- snvzz 2y ago>you can actually buy a computer that is compliant and will run Linux out of the box, even if with some glitches. Note that neither RISC-V nor aarch64 are any worse in that regard. If anything, they're doing much better platform standardization wise.
- tliltocatl 2y agoOn paper, yes. But how many desktop-suitable systems out there that actually implement it?
- snvzz 2y agoShow me one (1) desktop-capable RISC-V system that does not follow the specs that were available at the time it was designed. As far as I am aware, it does not exist.
- tliltocatl 2y agoThat's because there are not many RISC-V systems out there yet (VisionFive2, MILK-V and Lichee Pi, are there any more?). aarch64, on the other hand, it is hard to pick find one that is does. And as incentives of RISC-V vendors are not going to be different from those of aarch64 vendors, we can assume they will behave similarly.
- snvzz 2y agoRISC-V is not ARM. Let's try and not extrapolate from ARM's failings. They were quite late with everything platform related, and suffer from it.
- EasyMark 2y agoAs a user, I don’t care about x86 bloat or “baggage”, all I care about is how fast is it relative to its competitors and how stable is it for what I need it for. A lot of hardware people will be angry with that but I say let the market decide; if RISC V or ARM supplant it, great!
- Sakos 2y agoI've recently discovered it isn't just per SoC. It's per device. You can't even buy a new laptop with an existing SoC without first checking how far along the manufacturer of that specific device is with mainlining the device tree for that specific device and providing tbds and whatever else. And then they have to do that for every kernel version or you'll be stuck with a device that can't be updated beyond 6.11 forever. Just what.
- xnx 2y agoI'm suspicious of those trying to "kill" x86 in the same way I'm suspicious of proprietary messaging apps trying to "kill" email.
- phendrenad2 2y agoI've made this same observation, and some RISC-V fan always points to some random ACPI/UEFI-for-RISCV github repo with like, five stars. I think x86(-64) is complete trash, and it would be nice to have something better, but we're not going to get there if "x exists" is a stand-in for "x is promoted and encouraged".