Honestly I’m pretty convinced that this « open » bootloader was just there to avoid criticism and bad press from specialized outlets when they presented the M1 because, for once, they needed specialized outlet to benchmark the M1 performance and not have anything bad to say about anything else.
They constantly break everything year after year without documenting any change which effectively makes Asahi unusable in anything recent.
I’m betting that they are just patiently waiting for Asahi to die by being too late of several years (which is already the case) to announce « The most secure Mac ever » silently releasing with closed bootloader when nobody and especially the press will care anymore.
Don’t get me wrong, I love Asahi and I even have it installed on my M2 Air, the project is doing incredible quality work. But I don’t believe it will last long. Hope I’m wrong, though.
But at the time there was nothing, because Apple Silicon wasn't a platform anyone but them was targeting, because they had just created it.
So they built the infrastructure, and then waited for someone to actually start taking advantage of it, before bothering to acknowledge it.
And because that "someone" isn't a bigcorp (i.e. Microsoft) wanting to do a co-marketing push, but just FOSS people gradually building something but never quite "launching" a 1.0 of it — Apple just "acknowledged" it quietly, at developer conferences, exposing it only via developer-centric CLI tooling, rather than with the sort of polished UI experience they would need if Microsoft was trying to convince Joe Excel User to dual-boot Windows on their Apple Silicon MBP.
> announce « The most secure Mac ever » silently releasing with closed bootloader
That's extremely unlikely to happen, as Apple's hardware and OS developers build Macs and macOS (and all the other hardware + OSes) using Macs and macOS. And those engineers (and engineers working at Apple's hardware and accessory manufacturing partners) will always need to be able to diddle around with the kernel and extensions "in anger" without needing to go through a three-day-turnaround code-signing process.
There's a whole proprietary, distributed kernel development and QC flow for macOS, that looks a lot like the Linux one (i.e. with all the same bigcorps involved making sure their stuff works), but all happening behind closed doors. But all the same stuff still needs to happen regardless, to ensure that buggy drivers don't ship. Thus macOS kernel development mode being just one reboot-and-toggle away.
It's also important to remember that Microsoft was in the middle of their Qualcomm exclusivity deal at the time of the M1's release, and thus Windows for ARM wasn't available on anything other than a few select devices or unofficial use of Insider builds.
That deal didn't actually expire until 2024[1], at which point Windows for ARM finally started to be sold in an official capacity with stable builds widely available.
It's entirely possible, though unconfirmed, that Apple was intentionally leaving the door open for "Boot Camp 2", and Microsoft simply never took them up on the offer, either because they were stuck in a deal made prior to the M1's release that prevented it, or because they no longer saw a financial benefit to being able to sell Windows to Mac users (possibly since Windows license sales are effectively a rounding error to Microsoft at this point; they make way more off of subscription services and/or Office, all of which are already available on macOS without having to dual-boot Windows).
[1]: https://www.tomshardware.com/pc-components/cpus/windows-on-a...
AFAICT, the way Microsoft wants things to work, is that "Windows" is the native fat-client platform / SDK that ISVs are supposed to use/target when building fat-client apps that interact with (i.e. generate spend on) Azure-based backend systems. The #1 way Microsoft makes money at this point isn't from direct consumer or even volume-licensed subscriptions; it's from providing paid backend infra to dev shops who had long since locked themselves into the Microsoft/Windows development ecosystem, and who therefore saw Azure as the only valid cloud backend to integrate with when "cloud-enabling" their software (and/or, where the compliance story of integrating their previously native-and-local-syncing software with Azure, was 100x simpler than with integrating with any other cloud, due to Azure+Windows being able to act as a trusted principal-agent pair that can enforce policy-based security via a shared "cloud domain" identity [Entra ID] baked right into the OS ACL layer.)
Until recently, though, Microsoft thought of the Windows "platform" the same way Apple do of the Mac "platform": that "Windows"-the-platform-SDK was the same thing as Windows-the-OS. Which necessarily meant that consumers must be pushed with all conceivable effort toward using Windows-the-OS on their machines, so that these dev shops who had targeted Windows-the-SDK could reach them with their software (so that those dev shops would in turn spend more on Azure.)
But I think this equivalence is going away!
From what I've seen of discussions in various Microsoft-aligned sources recently, it feels to me like some part of what Windows 12 may mean by calling itself a "modular OS", is that Microsoft may be establishing some kind of very clean boundary layer between Windows-the-OS and Windows-the-platform/SDK.
---
What would that look like? I don't know for sure, but here's some spitballing:
Picture Mono, but as a complete UWP projection, shipping with all the native libraries that are built into Windows.
Or, if you'd prefer, picture Wine/Proton; but rather than black-box-reverse-engineered equivalents to Windows DLLs, it is all the DLLs that come with Windows. Except, now rebuilt from the ground up so that they compile against NTOS or Mach or Linux syscalls.
Basically, "the complete Windows platform" as a JVM-like runtime you "get for free" when installing Windows-the-OS, but can install on top of macOS and Linux. (Probably in various runtime profiles, as with Embedded vs Server vs Desktop JREs. You don't need D3D on your server.)
This would be likely to take 100% of the wind out of the sails of the Wine/Proton projects overnight. And maybe kill Mono itself, too. After all, why bother with half-assed third-party implementations of the Windows Platform, when you can just install the "real" Windows Platform, and get guaranteed bug-for-bug compatibility with existing Windows software (relying on the same databases of app shims and fixes Windows-the-OS has shipped with for ~forever)?
SteamOS would be reduced to "a Linux distro that preinstalls the Windows Platform." ReactOS might or might not (depends on stubbornness) be reduced to "a clean-room-implemented NTOSKRNL-compatible base OS, that preinstalls the Windows target of the Windows Platform."
Wine/Proton themselves would, if they even bothered to keep going, end up rebranded as "an alternative ground-up Windows Platform runtime." (If the official "Windows Platform runtime" was then open-sourced, then likely Wine/Proton would fully fade into obscurity, as anyone who wanted to maintain their own libre Windows Platform runtime would just start by forking Microsoft's. Very similar to the situation with OpenJDK.)
---
In any case, regardless of how they do it, any move in this direction would make it blindingly obvious why Microsoft wouldn't care about enabling something like a "Boot Camp 2" feature on Macs any more: they no longer care if you install Windows-the-OS on a Mac; they rather want you to install the Windows Platform runtime under macOS. And then they'll have you as a consumer of Windows Platform products all the same.
(Actually, even better, as they'll have you far more of the time. In the Boot Camp business strategy, any time you spend booted into macOS puts you out of Microsoft's reach, save for the few first-party apps Microsoft has ported to macOS + sells on the App Store. In the Windows Platform business strategy, meanwhile, you can be running arbitrary Windows Platform apps on your Mac [and so generating Azure spend for some ISV somewhere] 100% of the time you're using it!)
That doesn't mean that the engineeers will necessarily ship something more flexible than what the PMs asked for. Often not.
But sometimes they will.
Is that gonna be before or after the iphone with no usb port?
Though let's be realistic, here: $600 is much more than the typical school-assigned Chromebook.
The bootloader kids get my deep respect. I think I'd rather give my kid a Neo to begin with.
These use the A series chip, and even supporting new M chip revisions has been enough of an undertaking that I wouldn't really expect this to get Asahi linux anytime soon....
And apple can lock down the bootloader to be closer to the iPad/iPhone at any time with no notice, and based on their past actions, it would be quite in-line with their character to do so.
The terminal app is not iterm. But Apple's own Terminal.app
And no there's no package manager but there's brew and macports.
But we know there’s lots of other models that they’re already working on. We don’t know how similar or different it is from an OS perspective.
Reverse engineering needs a lot of time and hard work, which may not be worthwhile.
Sometimes someone does this work, and everyone may benefit from it, but you should never count on this happening, unless you do the work yourself.
I think folks want to hate Apple more than they want to admit that Chromebooks kinda suck.
And macOS frankly provides a far better Unix experience than ChromeOS, in my experience, having actually used both (including for development, though only for a short time on ChromeOS because it was horrible).
What would have been a trivial porting work with documentation, becomes extremely time-consuming and hard work without documentation.
That is why Asahi Linux lags by several years with the support for Apple computers, and it is unlikely that this lag time will ever be reduced. Even for the old Apple computers the hardware support is only partial, so such computers are never as useful for running Linux as AMD/Intel based computers.
Oh so all our hypothetical child has to do to discover what computers can actually do is completely rebuild one's software from scratch with no prior knowledge.
Next you'll tell me F1 drivers in their teens just have to LS swap a Saturn SC2 and book time at a track.
5 seconds of googling will get you an answer to "install blender on a Chromebook"
Of course not. I could do it in a coma. I've also been using computers since 2004, and you're probably similar.