6 ms·
>Standardized parts and a well defined firmware interface (and thus "standard" bootloaders instead of a multitude like on ARM) That was true ~15years ago but l
by simias 6y ago
>Standardized parts and a well defined firmware interface (and thus "standard" bootloaders instead of a multitude like on ARM)
That was true ~15years ago but less so today. Modern PC EUFI bootloaders are bigger and more bloated than any uboot build in existence, and things like device tree support in linux means that you can support various boards with the same kernel (including boards that don't exist yet). Sure you'll probably still need custom bootloaders for most boards, but it's not like you can swap your motherboard BIOS/UEFI chips and expect them to work either. The PC "platform" with hardcoded physical addresses for your serial ports is nice if you're running DOS but it's not really relevant for modern operating systems which have to employ much more complex hardware discovery mechanisms.
It's true that on ARM it's still a bit anarchic and bespoke in practice but that's mainly because there's no reason to push for strong standardization when every vendor is building their own kernels for their own devices anyway.
But the tools do exist (on Linux at least, not sure about the other OSs), if desktop ARM becomes mainstream things could settle fairly quickly. It's less of a technical problem and more of a "why bother?" problem.
- ForHackernews 6y ago> if desktop ARM becomes mainstream things could settle fairly quickly. It's less of a technical problem and more of a "why bother?" problem. This is exactly right, but I fear the incentives have changed and we'll never again see something like the x86/IBM-compatible/Wintel world of "standard" inter-compatible systems. As you say, it's a "why bother?" problem, and no manufacturer will want to bother: Apple has no interest in making it easy to run other OSes, Microsoft wants to sell you "Windows Surface" devices, not general-purpose computers, corporate buyers want a "secure" locked-down environment with a signed bootloader... Are there any powerful stakeholders who benefit from interoperability?
- ithkuil 6y ago> Are there any powerful stakeholders who benefit from interoperability? All those companies selling motherboards for gamers etc?
- ForHackernews 6y agoSo firms that sell speciality hardware direct to consumers? Are they big players?
- jaywalk 6y agoI'd definitely consider companies like ASUS, MSI, etc. to be big players.
- Hamuko 6y ago>Apple has no interest in making it easy to run other OSes I'm not convinced that this is necessarily true. They advertised running Linux VMs during their presentation, they made a tool specifically for installing Windows on Macs and they even recently stated how Windows on ARM Macs is really up to Microsoft. If you could run Windows on an M1 Mac, it'd really turn it into a powerful and power-efficient "do-it-all" machine, since you could still boot into Windows and run that niche Windows software that you need from time to time.
- buran77 6y agoOf course but obviously they don't and probably will never allow you to replace MacOS, rather just to run something else on top of it in one form or another. Notably the PC standard meant things were interchangeable, not "interlayerable". You picked a CPU, you picked an OS, you did not have to emulate or virtualize whatever you wanted on top of what was imposed on you. Imagine that 30 years ago someone pitched a PC that only runs a specific OS and the only way to run anything else is on top of that like an app. You'd think "ridiculous". Today having a device that runs as sealed monolith both HW and SW wise, and all you can do is run stuff on top of that without the ability to replace anything is considered a good sign. Tells you where we're going.
- Hamuko 6y agoBootcamp is not virtualization, so your point is moot.
- AsyncAwait 6y agoBootcamp doesn't run on ARM Macs so your point is moot.
- Hamuko 6y agoThat's not really because Apple hates allowing you to install Windows, but rather because you can't actually acquire a Windows for ARM license. Once again, Apple has stated that Bootcamp for Apple Silicon is "up to Microsoft". And ARM Macs are still just a minority of the computers that Apple sells. The rest have Bootcamp, which allows you to just turn your Mac into a Windows machine. Saying that "Apple will never allow you to replace macOS" is just plain wrong when they've been allowing you to do that for the past 14 years. You might as well argue how Bootcamp doesn't run on iPads.
- oaiey 6y agoMicrosoft selling Windows to DELL, HP, ... they will not start writing their own operating system. And at that point the same effect will start like it did with Microsoft/Intel/computer manufacturer. If Microsoft however succeed with their Surfaces like Apples does .. than maybe we are screwed. Luckily, they do not.
- pjmlp 6y agoThey do actually. Outside Apple heavens like US, Windows tablets and 2-1 laptops are the to go option, as Google keeps failing to move the Android ecosystem beyond phone apps on bigger screen.
- someperson 6y agoIn the 1980s, the IBM PC standardized the entire industry around ISA ("Industry Standard Architecture") which was pushed forward by the manufacturers of IBM-compatible hardware ("clones"). The consortium of like-minded manufacturers later went to help develop develop all the subsequent variants that persist to this day (PCI and ATX form-factor etc). The standardization benefited them greatly. Now that ARM Holdings is owned by NVidia I hope Jensen Huang sees that if ARM is to take over the desktop it makes sense to bring that same level of standardization that allowed the PC industry (and NVidia) to dominate. I think ARM Holdings needs to be the one to spearhead the initiative. It will help industry-wide adoption of ARM (for desktops, laptops and servers) which will benefit them greatly.
- yjftsjthsd-h 6y ago> Modern PC EUFI bootloaders are bigger and more bloated than any uboot build in existence, and things like device tree support in linux means that you can support various boards with the same kernel (including boards that don't exist yet). Sure you'll probably still need custom bootloaders for most boards, but it's not like you can swap your motherboard BIOS/UEFI chips and expect them to work either. This feels like, at best, getting back to where PCs already were, at least as a user. If a device tree can be embedded in firmware and fed to the booting system, then that's fine, it's just a minor implementation detail. If you need to go get a file and put it on your boot media, then that's extra friction. Likewise, I don't really care what the hardware's boot firmware looks like, but if I need a different bootloader per-device then that's a problem - can you imagine if Dell laptops and HP laptops needed different GRUB builds to work?
- simias 6y agoI feel like we're kind of mixing up a bunch of things here, or maybe I am. The reason you don't need to mess with GRUB or you BIOS when you change your hardware is that modern hardware interfaces have built-in discovery and resource allocation features. Before that you had to deal with pesky low level details like IRQ allocations and the like (which was a thing on PC not that long ago). That's not really a feature of "PC" per se, it's a feature of USB, PCI etc... That stuff works exactly the same on ARM or anywhere else. The things that need to be described in the device tree are generally internal components of the SoC and motherboard, things like IO expanders, SPI interfaces, serial interfaces, and of course the USB/PCI/... controllers themselves. I think there maybe some confusion because of the term "bootloader". It's true that both u-boot and GRUB are bootloaders, but bootloaders in the ARM world have a lot more to do than PC bootloaders, they're effectively the equivalent of UEFI + GRUB, not just GRUB. You can write a simplistic boot sector loader for PC in a few hundred ASM opcodes, that would be a lot more difficult for the average ARM bootloader because there's a lot more to do before you can just call into Linux. In general you won't even have RAM or caches available when u-boot begins executing. And I think it's actually a better design, because it means that proprietary built-in firmware crap is usually kept to a minimum on ARM: the BOOTROM usually just initializes the bare minimum to be able to load u-boot (or some other loader) into on-chip SRAM and then it's over. Of course that means that the loader is significantly more complex, but that complexity has to be some place or an other.