Hacker News Reader

Comment by ekianjo | Hacker News Reader

> But I think the overarching point is true: now desktop and laptop makers can't just pretend that having a hot and/or slow, clunky, noisy x86-based architecture is just a fact of life. I hope and expect that it'll help create a new generation of ARM-based laptops and maybe even desktops that will run cool and smooth.

Be careful what you wish for. X86 is the most open architecture right now. ARM, on the other hand, has locked bootloaders, messy device trees and so on. You can see that virtually every Linux distro running on an ARM SOC needs some specific tweaks.

View on HN

> X86 is the most open architecture right now.

x86 is not "Open" in any fashion. You can't license x86 even for a fee, let alone free.

While ARM isn't open either, it is by comparison far more available to license at reasonable cost.

> ARM, on the other hand, has locked bootloaders

It also has open/ unlocked boot loaders. One of the advantages of licensable technology like this is you can have a lot of different architectures with the same underlying core. With x86, you get whatever the Intel/ AMD duopoly decide to ship you.

> x86 is not "Open" in any fashion. You can't license x86 even for a fee, let alone free.

OP is not talking about being able to manufacture x86 CPUs kind of open, that's useless for most folks.

They're talking about being able to install any OS, drivers being fairly universal, no device specific out of tree kernel patches for the vast majority of PCs, no device trees etc.

It's a lousy use of the word "Open" in a discipline where Open has a fairly specific meaning.

I mentioned that as well though. Using your goofy definition of Open, x86 is no more "Open" than ARM. Pinebook and Raspberry Pi both use no bullshit ARM setups. With ARM, how accessible the architecture is is 100% dependent on the implementation which vary greatly by manufacturer.

> Using your goofy definition of Open

If I buy any x86 PC, chances are I can install mainline Linux on it. Picking up any particular recent ARM SoC and the chance of doing so is much, much less. The M1 included, after all.

> Pinebook and Raspberry Pi both use no bullshit ARM setups.

Both of these took considerably longer to get mainline support that your average x86 hardware needs.

> Both of these took considerably longer to get mainline support that your average x86 hardware needs.

Not sure what you are thinking here. It's taken 25 years so far and we still have tons of x86 hardware which isn't supported well in Linux. There is a reason Dell ships a specific laptop for developers with Linux pre-installed.

> There is a reason Dell ships a specific laptop for developers with Linux pre-installed.

And yet, even Windows DELL laptops are more likely to run mainline Linux than any average ARM SoC, even including the ones targeted at developers.

I am no fan of x86, but trading what we have now for an M1 is a net loss in terms of our ability to install anything we want as users, no question.

Consider for a moment how many independent developers rely on x86 based Linux systems versus ARM. x86 isn't open, Linux's support for it is a symptom of Intel's monopoly.

> And yet, even Windows DELL laptops are more likely to run mainline Linux than any average ARM SoC, even including the ones targeted at developers.

This is more about inertia and developer resources than openness. The more developers you have on ARM, the faster device and software support will come.

> I am no fan of x86, but trading what we have now for an M1 is a net loss in terms of our ability to install anything we want as users, no question.

You've changed the question here. We were speaking about ARM in general, not the M1.

Well there's two issues there. One is if the bootloader is open, which it is.

The second is if there's linux port for that hardware, which it isn't. There's a project underway, seems likely that the CPU (which is still AARCH64) will work, and likely networking. However to make a usable desktop you'll need a GPU which is much harder.

> x86 is no more "Open" than ARM. Pinebook and Raspberry Pi both use no bullshit ARM setups.

They're ARM SoCs, meaning that you can't just download the Ubuntu ARM ISO[1] and run it on either device like you could with an x86 ISO and an x86 machine.

To run Ubuntu or any Linux distribution, you need to use images that were specially crafted for either SoC.

This is because ARM SoCs use custom bootloaders and don't have hardware on enumerable buses. Each SoC model is essentially a unique hardware configuration that needs an individual Linux port.

ARM servers are more similar to x86 machines in that they use UEFI and have enumerable buses.

As long as machines are shipped that use ARM SoCs, Linux support for all of them will be quite difficult to achieve[2] compared to x86 machines.

[1] https://ubuntu.com/download/server/arm

[2] https://elinux.org/images/a/ad/Arm-soc-checklist.pdf

While Apple likely has no motivation currently to make a UEFI-based ARM computer, there's nothing that prevent anyone else from doing so. UEFI is not x86-specific.

(I also think it's a bit too early to say definitively that no ARM-based Apple computer will ever be able to boot into Linux. I don't think Apple has any motivation to make that easy, but that may not be the same as making it impossible.)

It's cheaper to just design a ARM SoC with a custom bootloader.

> I also think it's a bit too early to say definitively that no ARM-based Apple computer will ever be able to boot into Linux.

There's a big difference between a SoC running a Linux fork and actually running Linux distributions in the same sense that we can on x86 computers or ARM servers.

There is also nothing pushing OEMs to do this and in the decades we have had ARM SoCs we have not seen this happen.

Windows Mobile/phones actually had UEFI bootloaders with Windows Boot Manager [1]. For some Windows mobile devices, people have managed to unlock the bootloaders and load other EFI applications.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/br...

UEFI can be just as closed as custom non-UEFI bootloaders. Windows Mobile devices were UEFI, but they had Secure Boot enabled making it almost impossible to boot non-OEM signed images. (Un)fortunately, their Golden Key was leaked allowing experimentation with some Windows Mobile devices [1].

[1] https://www.xda-developers.com/microsofts-debug-mode-flaw-an...

> Raspberry Pi both use no bullshit ARM setups.

Seriously? You need a blob from Broadcom to even boot the thing, and you call that a no bullshit ARM setup? I am astounded.

Compared to the amount of bullshit we had to to deal with in the 90s and 00s getting Linux running on a laptop, it's a walk in the park. Often it was a choice between mediocre FLOSS drivers or binary blobs from 2-3 private parties... when things even had drivers at all. It's been a while, but how many laptops lack wifi support or require proprietary drivers to work now?

Are the FLOSS drivers for Nvidia's cards great now? How many years have people been hacking on that project to make them work as well as they do?

What people are describing as "Open" is actually an enormous amount of work on the part of developers and the grudging support of hardware vendors after decades of struggle.

> It's been a while, but how many laptops lack wifi support or require proprietary drivers to work now?

Very few actually.

> Are the FLOSS drivers for Nvidia's cards great now?

Don't shift goalposts, we are talking about CPU support, not GPUs... GPU support on ARM is anyway not that great to begin with.

> What people are describing as "Open" is actually an enormous amount of work on the part of developers and the grudging support of hardware vendors after decades of struggle.

Intel has Linux dedicated teams at least, pushing FOSS code every single day. Most ARM licensees could not care one bit about FOSS.

> Don't shift goalposts, we are talking about CPU support

Linux already supports ARM CPUs and has for some time. The challenge is drivers. Getting video/ wifi/ etc running is the part that makes devices actually useful. The Broadcom Blob the poster I replied to was referring to is not for supporting ARM. Very similar to the Nvidia blob many people install (often unknowingly) when they install Linux on a system with Nvidia.

> Intel has Linux dedicated teams at least, pushing FOSS code every single day. Most ARM licensees could not care one bit about FOSS.

Intel didn't give a shit about Linux for how many years? Companies don't care about FOSS until it has potential to affect their bottom line. It was only after Linux servers were running half the Internet, that Intel stepped up and started supporting Linux.

I'm guessing you missed the first couple decades of Linux adoption. Linux on ARM is just a fast motion repeat of the early days of Linux on x86.

The is a free one: https://opencores.org/projects/zet86 (I don't know how complete/production grade is it).

I am pretty sure the most open at the moment are OpenPOWER and RISC-V, while there is is MIPS I am sure how open it is.

Can you buy a desktop with those right now?

POWER: Yes, https://www.raptorcs.com/content/base/products.html

RISC-V: Not really. The closest thing is probably https://www.sifive.com/boards/hifive-unmatched

> POWER

at prohibitive costs. So not really an option...

They don't seem that expensive. They're high-end machines themselves, and their pricing seems on-par with high-end x86 workstations, like the Dell Precision series.

> Be careful what you wish for. X86 is the most open architecture right now

You might want to take a look at PowerPC/OpenPOWER.

ARM not being very open is mostly because there's been limited development interest in it, aside from specialised devices, and those companies have no real need or interest to have open things. Doesn't mean ARM itself can't evolve past it.

> ARM not being very open is mostly because there's been limited development interest in it, aside from specialised devices

That's an extremely weird thing to say...

I know very little about this space, but presumably that will change if/when a significant portion of the laptop space (and probably the server space as well) moves from x86 to ARM? It might be painful for early adopters for a few years, but I would expect this stuff to get ironed out in time, no?

No, that ship has sailed. Anything new that comes now can be built according to the expectations smartphones have set over the past decade and a half. Closed systems that are treated like disposable items. Even PCs in their mobile incarnation are now far less open and flexible than they used to be.

The reason PCs are still open is historical, they started like this and people can't really see PCs any other way but they're a dying breed and whatever comes after is a different game with different rules. We'll have some niche manufacturer building something more open for the small segment of enthusiasts.

Sadly, I find this persuasive.

"Developer Mode" exists in many new devices, eg. Chromebooks, Oculus Quest, Android phones.

There's a difference between swapping or adding any of the many standardized components you want or installing pretty much any operating system you can think of on your PC, compared to enabling "developer mode" on an Oculus Quest.

The fact that so many people casually say how a platform is open or flexible because if you jump through enough hoops you get to make some minor modifications to your device, or applauding the openness of a system for allowing you to sideload standard apps is the reason manufacturers don't see a need to propagate the PC philosophy anymore. Too many users grew up with this new model so they don't see the loss.

None of the devices you mention are user serviceable in any way hardware-wise, the software is almost always locked onto the device and there's no easy, or even supported way of changing it. And if you do change it you just get a small variation of the same software. Your phone may get a slightly degooglified version of Android but it's unlikely you'll get it to run Ubuntu, Windows, or a FreeBSD without a massive investment in time and knowledge.

My understanding is that developer mode on Android and Chromebook will unlock the bootloader. Software wise, that's about as user-hackable as you can get. It's true that the Oculus Quest is not as open.

I don't expect or even really want to swap hardware on these devices: if that was a priority for me I would get a PC, Arduino, Raspberry Pi, etc. I get the desire to tinker and customize, but from where I'm sitting I have plenty of opportunity to do that.

I also don't expect the device manufacturers to do the work to make Ubuntu or FreeBSD run. They didn't do that for PCs, the community did.

We've basically got one foot though that door already.

> We'll have some niche manufacturer building something more open for the small segment of enthusiasts.

I would argue that's exactly what Raspberry Pi and Arduino is.

The raspberry pi requires a very proprietary and custom boot process. Nothing can start until you first load the GPU driver blob on to the SoC.

This is why you need rpi specific distro builds.

The apple M1's don't have locked bootloaders, there's a warning in the firmware about enabling unsigned booting, but it's just warning. That's why there's an attempted linux port underway.

> messy device trees

Can you please elaborate?

> * the x86 world resolves around standards such as ACPI, BIOSes and general-purpose dynamic buses. > * ACPI normalises every single piece of hardware from the perspective of most low-level peripherals. > * the BIOS also helps in that normalisation. DOS INT33 is the classic one i remember. > * the general-purpose dynamic buses include: - USB and its speed variants (self-describing peripherals) - PCI and its derivatives (self-describing peripherals) - SATA and its speed variants (self-describing peripherals)

> exceptions to the above include i2c (unusual, and taken care of by i2c-sensors, which uses good heuristics to "probe" devices from userspace) and the ISA bus and its derivatives such as Compact Flash and IDE. even PCMCIA got sufficient advances to auto-identify devices from userspace at runtime.

> so as a general rule, supporting a new x86-based piece of hardware is a piece of piss. get datasheet or reverse-engineer, drop it in, it's got BIOS, ACPI, USB, PCIe, SATA, wow big deal, job done. also as a general rule, hardware that conforms to x86-motherboard-like layouts such as the various powerpc architectures are along the same lines.

> so here, device tree is a real easy thing to add, and to some extent a "nice-to-have". i.e. it's not really essential to have device tree on top of something where 99% of the peripherals can describe themselves dynamically over their bus architecture when they're plugged in!

> now let's look at the ARM world.

> * is there a BIOS? no. so all the boot-up procedures including ultra-low-level stuff like DDR3 RAM timings initialisation, which is normally the job of the BIOS - must be taken care of BY YOU (usually in u-boot) and it must be done SPECIFICALLY CUSTOMISED EACH AND EVERY SINGLE TIME FOR EVERY SINGLE SPECIFIC HARDWARE COMBINATION.

> * is there ACPI present? no. so anything related to power management, fans (if there are any), temperature detection (if there is any), all of that must be taken care of BY YOU.

> * what about the devices? here's where it becomes absolute hell on earth as far as attempting to "streamline" the linux kernel into a "one size fits all" monolithic package.

> the classic example i give here is the HTC Universal, which was a device that, after 3 years of dedicated reverse-engineering, finally had fully-working hardware with the exception of write to its on-board NAND. the reason for the complexity is in the hardware design, where not even 110 GPIO pins of the PXA270 were enough to cover all of the peripherals, so they had to use a custom ASIC with an additional 64 GPIO pins. it turned out that that wasn't enough either, so in desperation the designers used the 16 GPIO pins of the Ericsson 3G Radio ROM, in order to do basic things like switch on the camera flash LED.

> the point is: each device that's designed using an ARM processor is COMPLETELY AND UTTERLY DIFFERENT from any other device in the world.

https://lists.debian.org/debian-arm/2013/05/msg00009.html

ARM UEFI systems exist. There are now the norm on servers along with ACPI. Even some embedded devices use UEFI. There are other standards to address those various points.

This post is so outdated, that ARM servers' companies had the time to have everything, then still die (most of them). And then revive with the AWS Graviton2 and other Neoverse chips.

It's not outdated, it holds true for ARM SoCs. Consumer ARM devices are ARM SoCs, and not server hardware. It's cheaper and easier to design custom SoCs than it is to build consumer hardware that conforms to the standards that ARM servers do.

Reply on news.ycombinator.com