It's a major scandal for our industry that decades in, there is no general purpose bootloader and OS install method for non-x86 devices.

I have these perfectly fine ARM-based Android tablets lying in my tech stuff drawer and there is no way to keep them useful few years after the manufacturer unilaterally decided to EOL them, while I can put Linux onto any 15 yr old laptop and keep using it (granted, as long as it has a 64 bit x86-CPU).

@hzulla That's taking the problem backwards. It's that everything not-a-desktop (and servers are just souped up desktops) has taken nominally open reference designs and locked them down and there's more than enough prominent FOSS people saying that's totally fine with the license terms.

@trini I see the same problem with Win-on-ARM laptops/desktops, though.

@hzulla That's still a Qualcomm exclusive I think, and Phone vendors will be phone vendors. Non-Windows-on-ARM desktop/laptop/server hardware is UEFI and others pointed out the relevant standards, which even if not as strict as envisioned are still a standard.

@trini @hzulla Nothing is locked on Qualcomm ARM laptops. After 15 years to can still develop generic purpose loader or kernel... But if you want someone else to do your job (like they did on ACPI), that's a bit different question and not really a scandal. Scandal is if vendor would lock you out of doing it. Here no one is locked out and you have the freedom to implement whatever you find necessary. What others did not implement in SW what you find necessary is not a scandal.

@krzk @hzulla But that just gets back to the original point of, in short, wouldn't it be nice if there was a standard and vendors used the standard? That we have to have this conversation, but aren't for random amd64 laptop is the problem.

@trini @hzulla That "standard way" was actually developed by someone, e.g. company or hobbyists, so cost money/time. Lack of such investment is not a scandal. It's really harmful language, because it suggests there is here some sort of malice or incompetence or just negligence. Basically it feels like years of mine and your work were part of that negligence. But no.

Our choices or economies are driven by demand and there was no demand for generic bootable ARM phone or laptop. Demand was for a cheap phone or laptop. There are BTW reasons why there is no x86 (laughing at Intel Atom) in embedded, IoT or phone/tablet market. That "general purpose bootloader and OS install" comes with a cost and there was and there is no demand for it.

Scandal would be if someone could not even develop that "general purpose bootloader and OS install", because of vendor lockdown. This is actually partially true for mobile market due to secure boot restrictions, but not for arm64 laptops, not for embedded/IoT.

@krzk @hzulla Perhaps "scandal" is a strong word? But that for Qualcomm Windows laptops, they didn't just do UEFI+ACPI apparently, is a Qualcomm problem (and a Microsoft problem, for not pushing back on their chosen HW partner), not a community problem.
And for all of the embedded examples everywhere it too is a vendor problem, not a community problem, when it's not "step 0, only signed firmware can run".

@trini @krzk @hzulla Windows boots using UEFI and ACPI. Linux also boots using UEFI but the ACPI tables are too borked for it, so it was hacked around with device trees.

Also the firmware installs a hypervisor Gunyah in EL2 and Windows disables it during boot, but Linux itself usually boots in EL1 unless you involve things like slbounce.