> Apple, if you want to start naming names puts out hardware that is far more closed than the Raspberry Pi foundation and yet you don't see the same level of aggression against Apple.<p>Ooooh of course, I 'member the days right here when they announced they'd drop Intel. And I am fairly certain the echo across the tech blogosphere was what led them to, while not <i>openly</i> announcing they'd support a competing OS like they did with Bootcamp, they'd at least not lock down the bootloader like on iOS devices.<p>> What you do see is a couple of very talented hackers that won't take 'you can't' for an answer and that will RE stuff until they know enough to scratch their itch.<p>Apple, to my knowledge, never explicitly said "you can't" - at least not on Mac devices, for iOS the situation is different. All they're saying is "we won't help you, but you may try your best".<p>> Not having UEFI on ARM has never held me back.<p>The thing is the lack of UEFI adoption in the ARM sphere is holding <i>everyone</i> back! An OS / distribution shouldn't have to manage devicetree overlays on its own, they should be provided by the BIOS/UEFI management layer as a finished component.<p>RPi is the biggest toppest dog in the embedded world, at least when it comes to an ecosystem. They would have all the muscle needed to force everyone else's hand.<p>> I do have a nice Apple laptop lying around here that is unusable because the network drivers need a functioning copy of Apple's OS on that machine to get bootstrapped.<p>What did you do to that thing? On any pre-ARM machine, the bare bootloader should <i>always</i>, even if the primary storage is gone, be able to bring up enough hardware to support a UI, an USB and networking stack to allow restoring it from the Internet. ARM machines I'm not sure, haven't had the misfortune of having to dig down that deep, but I think even they should be able to do that in case you somehow manage to fry your partition table. And even if you managed to fry <i>that</i>, any other Apple device should be able to do a DFU restore on its lowest level bootloader.
Agreed that the EUFI thing could be better, but I don't see how you could compel Raspberry Pi to fix it without knowing the exact details of the license agreement that the foundation signed with Broadcom and I suspect that that more than anything is what is holding this back. It's not as if they're deaf or can't read at the Raspberry Pi foundation.<p>As for that machine: it's got a bunch of stuff on it and I have dongle with ethernet so I can live without it. It's one of the last line of Intel portables they made and there just aren't enough people that want this fixed and I'm not smart enough to fix it.<p>Meanwhile, and probably ironically, that too is a Broadcom chip...