Hacker News Reader

Comment by tliltocatl | Hacker News Reader

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.

View on HN

I'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"

> 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.

That 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

It'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.

What 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.

The 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.

I'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.

I'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".

I'm suspicious of those trying to "kill" x86 in the same way I'm suspicious of proprietary messaging apps trying to "kill" email.

Yeah, 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.

Yup. 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.

>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.

On paper, yes. But how many desktop-suitable systems out there that actually implement it?

Show 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.

That'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.

RISC-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.

Doesn'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.

As 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!

What 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-tr...

x86 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.

Yet 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/

Graphics 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?).

> 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.

DTB it's hell. A lot of devices today only work with obsolete kernel releases.

Yes, when support is not upstream.

Reply on news.ycombinator.com