Works here, here's the text for anyone who can't access it:
> Turns out APFS has an undocumented "VolBootable" flag that we were never setting since, well, it is undocumented, and the boot picker never cared about it (it read it and printed it's state to system log, just did not take any action). Anyway, fix PR-ed to asahi-installer, old installs will have an installer option to set the flag. But still, probably hold off on installing macos betas :P.
It seems like this is a bug, apple went through the trouble to allow something like asahi to be possible in the first place. I doubt they're purposely trying to break it.
Apple designed a bootloader for Apple Silicon Macs that allows you to run an unsigned OS without degrading security when you boot into MacOS. This wasn't an accident.
M series macs are weird tho, yes the bootloader allows it but absolutely no documentation on the hardware, drivers etc. Can't help but to think the goal of this wasn't to actually allow third-party OSes, but for development purposes(and ye they could hide the feature behind apple account with paid dev license) or anti-anti-trust measures à-la Google with Firefox: in front of a jury of normal people they can simply say "look there's these nerds making Asahi" the same way "look we're not a monopoly Firefox has .2% market share".
More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over?
> Can't help but to think the goal of this wasn't to actually allow third-party OSes
Apple has explicitly stated that allowing third party OSes is exactly the purpose of the new bootloader.
You should probably do do some reading on the subject to gain a bit more understanding:
> This puts [Apple Silicon Macs] somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
> the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response".
Critics worry it can be used as a backdoor and is a security concern.
Now explain to me how Apple's Secure Enclave does not do this:
> the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response".
It implements TPM or something similar. It is used in the boot process for a secure boot chain. And the last generic point is probably just that it implements the hardware random number generator for the CPU, which Secure Enclave also does (in a different way).
I could worry about Secure Enclave being used as a backdoor and being a security concern, too. Doesn't mean it actually is!
Yes, more weird than that. x86 PCs have fairly standardised boot and autoconfiguration (UEFI and ACPI). ARM based systems, including the Apple M series, don't. You just have to know what's there (device trees), and Apple isn't going to tell you. Hence why it's difficult to make another OS run on it, because you first need to find out what hardware's even there, and how to talk to it. It's initialised by Apple before iBoot runs, sure, but you don't even know what it is, so good luck writing a driver for it.
The Intel ME / AMD PSP are creepy, and probably a security risk to the device owner, but they're not weird, you can run an OS without even knowing they're there, and they like it that way.
Apple's Secure Enclave and ARM's Truszone work the same way as Intel ME and AMD PSP. All of them have a separate specialized minimal OS running on a specially protected memory that cannot be accessed by the normal OS.
Apple can lock your Mac just like other manufacturers can do via Intel ME. All of them are backdoors.
They don't. ME and PSP are separate cores with full memory and configuration bus access. TrustZone is nothing like this, it is a higher privilege level on the main cpu cores, more similar to SMM and used for pretty much the same purposes. Secure enclave is yet again nothing like any of the former and is similar to a TPM.
It's true that UEFI and ACPI cover a lot of ground whose equivalent on Apple Silicon is undocumented. But note that Linux on x86 does still rely on lots of reverse-engineered drivers to talk to various devices - not necessarily on servers which are designed to run Linux, but very much so on desktops and (especially) laptops.
>ARM based systems, including the Apple M series, don't.
You're thinking of old SBCs, most likely. ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) have +/- same level of auto-configuration and hardware resource discovery as x86 PCs.
> ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included)
Either this is untrue or misinterpreted - the SystemReady DeviceTree band (the only one Macs could possibly fit into, given they don't implement ACPI) still requires that devices implement EBBR, which requires that devices implement UEFI. Macs don't, and so are very much not SystemReady compliant.
>More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over?
Considering they're pretty much fully undocumented (officially, that is) and could contain any number of IME equivalents since we know that they already have independent processors like the secure enclave running its own OS: yeah, probably more weird. Just because Asahi did not find one doesn't mean it doesn't exist.
That's just a normal part of Mac development. Apple sees documentation as a net negative for them, something that can constrain them in the future. So they only document the major highways and leave everything else as an exercise to the reader.
If you're using an unstable API they expect you to figure everything out yourself. It doesn't mean that they don't want you to use it though.
The design of the exposed mechanism is explicitly about booting unsigned versions of MacOS. There is zero support for booting anything else, but no enforcement that it must be MacOS.
However, apple's justification for exposing this mechanism to users appears to explicitly include "booting linux" even if the mechanism has zero explicit support for booting linux.
And if Apple were going to change their mind and try to block linux, they would intentionally modify the bootloader to remove that functionality, not break the boot picker.
Reminds me of when the Xbox 360 came out, Microsoft had to buy a bunch of Macs because Macs had PowerPC processors, so it was kind of a no-brainer to get the darn thing going quickly enough. Ultimately Windows was the standard way to build Xbox games but it is kind of funny to think, one day someone at Apple saw an order for easily several dozens of Macs from Microsoft, and wondered if hell froze over.
Back in the 2000s MS agreed to port Office and Internet Explorer to the Mac. This was a good move for both companies. Bill Gates appeared on screen during an Apple Conference to talk with Steve. Huge boos. Steve had to work the crowd back from the ledge.
Then Office and IE were ported. It was so weird running Word on a Mac. It was a good port too. They did a good job of embracing Mac UI ideas. I found the Mac Word better than Win Word.
I was kind of new to the Mac back then.
I imagine Apple donated a bunch of early OS 10 machines to MS for development. I wonder if the MS Mac Dev team was a pariah at MS.
Word was originally released for the Mac in 1985, so the deal was not that Office would be ported, just that MS would keep developing Office for the Mac.
> I think it would be nice if we could run unsigned apps on iOS
Apple enforces those restrictions via the permanently locked bootloader. The main benefit of unlocking the bootloader on an iPhone would be to run a modified version of iOS that allows for the installation of unsigned apps. Apple wouldn't like it and might even get litigious over it, but still.
> (in the US)
Apps intended for release onto alternative app stores in the EU, Japan, and Brazil still need to be approved and signed by Apple. These laws were nearly useless.
I think iPhone hardware is better for the price on the used market. (I refuse to buy new phones. They're too locked down and shitty to warrant spending that much.)
I have fond memories in the early 2000s of getting the first MacBook Pro's with Intel Core i7's and the first thing we did at my company was build and install gentoo.
IDecices should absolutely be treated as laptops and desktops which allow another OS to run on the device. This why I have not bought an Apple device for years.
EU is the only governing body that would push owning the device you _buy_. Unfortunately their seem more geared moving to a surveillance state at the moment with chat control.
They're different for now, but it's frog-boiling. Apple has been steadily adding more and more hoops to the process for Macs, and eventually they are going to end up as locked down as iPhones.
The boot flag was undocumented, like most features of Apple devices that are required knowledge for being able to port another operating system to them.
Because of this lack of documentation, every release of a new version of Apple hardware or software may require the restarting of the reverse engineering work, like in this case, just to keep working the alternative operating system.
The boot flag might have been undocumented, but so was absolutely everything else that was reverse engineered to make Asahi possible.
Rather than blaming Apple for this, the correct approach would have been to post something like "if you dual boot Asahi, don't upgrade to macOS 27 until you've done this".
I keep wondering when "undocumented" stopped meaning "don't rely on this because it can and probably will change at the vendors will and they don't want you to shoot yourself in the foot and then you're on your own"? Nothing was "owed" for the undocumented...if it worked after an upgrade, it was a good day.
The "correct approach" is "Apple doesn't support Linux on M-series processors. If you're not willing to accept shit breaking regularly and having to do (much more likely, relying on other people without compensating them) the actual work to RE Apples ever-changing stuff then don't buy hardware that explicitly does not support the OS you want to run. If you want 'plug-and-play', you are barking up the wrong tree." This really isn't hard.
Back in the heyday of Hackintosh, there was always someone who wandered into one of the forums to shittalk Apple for not supporting some chunk of hardware they owned but Apple never shipped (usually with some whining to the effect "Windows supports my knock-off of a knock-off Alibaba special and it's totally unreasonable that unsupported MacOS on unsupported hardware doesn't Just Work!"), but I don't recall the adults in the room giving that sort of nonsense the time of day other than to say "here's the stuff that we know works...if you don't have that, it's on you not Apple or the uncompensated Hackintosh devs to figure it out".
How times change, I guess.
Edit: s/plug-and-pay/plug-and-play/ Freudian slip, I guess.
The 'onus' is on Apple to support an OS they never said they'd support, to the potential detriment of the one they do support, because a tiny number of people bought Apple hardware to run...lemme look again...an OS Apple never said they'd support? That's an...interesting...point of view, but probably not suprising considering the pervasive "how dare you not do unpaid work to make me happy no matter what your priorities are" attitude running around OSS these days. At least Apple won't rage-quit the project or have a nervous breakdown because the free-riders are demanding something never promised.
Such bugs have happened and been reported before. Asahi exercises "raw boot" facilities that just don't get all that much attention in any other context.
If the happy path disappears, the not-so-happy path will be taken to allow for booting custom kernels, one that will likely rely on turning the some or a lot of the RE energy towards breaking the Secure Enclave, the bootloader, and so on. Apple practically laid the red carpet out to avoid people trying to crack the parts of the hardware/software chain-of-trust they would really rather not have cracked. A similar strategy helped keep the Xbox One un-pwned for over a decade (running homebrew was allowed in a specific mode). It is doubtful Apple's legal department isn't aware of the value of the current software strategy.
Nothing is perfectly secure on its own. No system designed or checked by humans ever will be. After all, the Xbox One was indeed pwned, relatively recently. However, because the juice wasn't worth the squeeze for so long, it got pwned years after it was a relevant, money making console.
Novel jailbreaks for ancient iPhones are not worth much. But attention on current, brand new devices means increasing the danger that a mistake gets found, which increases the odds that that mistake is found by someone who wants to sell it for the most money. Also, from Apple's perspective a zero-day in the bootloader on macOS also means a zero-day in the bootloader in all of the billions of iOS devices out there too. They do not want to give anyone anymore reason than what already exists to try and pwn LLB or iBoot. Given a happy path, all of that hacker energy for "put Linux on my M1 Macbook" is put towards device drivers and support, rather than "how the hell do we get an alternative kernel booting on this thing".
Fewer bullets pinging off the armor. Fewer cracks in the fuselage forming. Fewer knives to dodge. All of it means Apple's boot process for their current devices are less likely to be pwned before they turn into e-waste (whenever that is, not making a comment on Apple's perhaps accelerated or otherwise practices in obsolescence).
Just like a jetliner will eventually succumb to entropy and become dangerous to fly, so too will a lot of "secure" software. You only need to actively maintain a jetliner while it is flying passengers or cargo. Once it is retired, it can rot, people can break into the husk of it at the junkyard and fornicate and smoke crack and smash windows and steal parts of the fuselage. At that point, who cares?
No, if their lawyers want it gone, Apple will just update the bootloader to reject local signing keys.
The actual problem was that Apple has an undocumented APFS key for if a volume is bootable, which Asahi wasn't setting and Apple wasn't checking, but now they do, so they do.
The comments there are absolutely insane lol, especially now that we know it's a bug.
I did not realize that some people were still so anti-Apple. I'm of course not saying that there's not a small element of truth in many of the comments, but talk about some straw man arguments.
It was not a bug, it was just another undocumented Apple feature.
However, when a company sells a device, as opposed to providing it for lease, I do not believe that it has the right to not document any feature of the device that is relevant for its usage, like it should also not have the right to impose any constraints on how the owner should use what has been bought.
Obviously, the owner of any kind of things may not use them to perform illegal acts, but that is a constraint imposed by the valid laws, not by the seller of the things.
Today, far too many companies claim to sell things, but they also attempt to control what the owner may do with them. I avoid to buy such things, but my choices are limited by those who buy them, allowing these policies to be beneficial for the sellers.
MacBooks are not designed to boot any OS other than macOS. Just because someone hacks one such that they get custom code running that doesn't mean all of that now becomes in scope for what is relevant for usage. Someone had to go above and beyond to hack the device to get another OS to run.
I mean, do you expect a blender to come with instructions on how to replace the engine?
> I do not believe that it has the right to not document any feature of the device that is relevant for its usage.
This is an extremely broad requirement to place on any and all manufacturers. I agree companies shouldn't intentionally restrict what you can do with your stuff, but on the other hand, if you're trying to rebuild your lawn mower into a motorbike, you can't really be mad that the company didn't provide you with a specification the exact dimensions of the exhaust, can you?
People were screwed so many times by so many companies, they have been taught the hard way to behave like that: either make a lot of noise and hate in the first stage, or just agree that some functionality has been removed to milk more money etc.
Apple transformed handheld computing into walled garden, brainwashed installation into "sideloading". Apple software update made Apple laptops to fail booting Linux.
"Concerned people are insane anti-Apple without any solid arguments, lol"
Not how I'm intending to come off as. I am more specifically mentioning the comments that say stuff like "Apple laptops are overpriced pieces of junk" but without thinking of those whose workflows would be impacted very negatively by moving to more open platforms (not because of the platform, but I mean because of hardware)
It's like they are looking at a specific application, finding that Macs are bad at it, and declaring it crap in every way, which isn't true.
That's true, if you want a Linux laptop. However, no ThinkPad at this moment can come close to the horsepower + battery life in a modern Mac. Not saying Apple is excused because of that, just an observation.
I am not (purposefully) granting them the benefit of the doubt.
In my comment I simply noted that the comments there are extremely anti-Apple yet without any solid arguments behind them, and I also noted that the whole thing is just because of an APFS flag which could be fixed from Asahi's side. The main reason I made the comment is because I am shocked at how poorly backed the arguments are.
As for Apple not helping the Linux team, why would they, or any major OEM? Apple is perfectly happy with https://github.com/apple/container
When Microsoft futzes with the MBR and locks out Linux users, we complain. When Apple futzes with the APFS partition flags, we complain. It's not that hard to understand.
> why would they, or any major OEM?
Apple Silicon doesn't expose any obvious ACPI-equivalent power management interface. Apple could very easily document that hardware without exposing proprietary devicetree drivers, but someone internally must love watching Asahi users suffer through cpuidle. There isn't likely to be advanced power management drivers for Apple Silicon on Linux within this decade.
At the very least, I think it's fair to expect Apple to document breaking iBoot changes. They don't have to, but they feed a dog's dinner to their power users when they don't.
You should read the report, it basically repeats what I just said:
> The power management architecture on this platform is incredibly complex, and there are a lot of moving parts involved in making it all work. There is Power Manager (PMGR), which is responsible for the SoC’s power domains, but there is also the Power Management Processor (PMP), which does… stuff?
> The actual low-level details of how power is managed across the SoC are quite opaque. [...] PMP will not read these reports if it is not booted, and certain power management functionality will not work. We are not sure exactly what it does with this information, but it likely involves controlling Apple Fabric power and clocking, among other things.
> There is obviously still work to be done to reach macOS levels of idle and suspend time
I still do not think that we will get advanced power management equivalent to ACPI within this decade, unless Apple starts documenting stuff. It took Asahi six years to replace cpuidle on M1, we're going to be here for a while.
I have said it for a while, Microsoft's business strategy was probably the best thing that ever happened to Free/Open software. They were ones pushing for more open systems so that they could sell DOS and Windows to other vendors. yes, it left the door open for others but they also figured they could push their software far harder than others could.
I agree with the ARM/RISCV stance that we should be cautious with what we ask. I have seen some RiscV providers in China are starting to push for a BIOS compatible boot system which is great to see, but there is no guarantee that it will be adopted or it will last for long.
This is also not guaranteed to be adopted widely, but the RISC-V Server Platform Specification was recently standardized with mandatory UEFI and ACPI support: https://github.com/riscv-non-isa/riscv-server-platform/relea... I'd rather have OpenFirmware like enterprise POWER, but anything is better than static device trees.
Other than this situation, what other landmines are there? I have an M1 with Asahi Arch Linux that I've been using as my primary laptop for the last 8 months, its my favorite laptop by far out of the 5ish I have.
Pretty much all ARM platforms are. Even ARM devices designed from the ground up to be Linux devices are full of issues, like the MNT Pocket Reform's lack of HW suspend. The tight interop between vendor and implementation is a huge anti-pattern for software freedom, and the standardization initiatives like ARM SR are nowhere to be seen. It's probably the most problematic part of ARM being the future of personal computing, yet another impending manifestation of enshittification.
Those are currently suffering from high power draw because they have to keep the cores awake for memory speeds. Lackluster performance as well, but thats the problem with the majority of the ARM ecosystem ever since apple started crafting SoCs.
I must have missed something...what does Apple creating M-series have to do with Allwinner, Qualcom, Mediatek, AWS, and the rest of the ARM ecosystem having 'lackluster performance'?
You do actually get UEFI on a few of these, though personally I've always fared better with U-Boot. (Sooner or later, I always run into something that is a simple edit in the device tree or uEnv, but UEFI doesn't expose.)
i run linux on both in arch and fedora versions with zero problems, by using the hypervisor framework of macos and wsl2 (wrapper for hyperv). do you need a more direct than hypervisor access to some hardware?
On the other hand, your “us” is not very big compared to your “not us.” I like Linux as a server OS (and would pick it over Windows or MacOS for that any day of the week that ends in y), but as a desktop OS it’s just more work than I care to exert (in fact, Windows also exceeds my tolerance for fiddliness in a desktop OS). My general preference is for “you don’t have to” over “you can” as much as possible which is the exact opposite of the Linux desktop experience.
macOS and Windows are both such a chore for development, though. WSL was the closest I got to an "it just works" dev environment, but it exposes just how bad native toolchains like Cygwin and git bash are. macOS is hardly any better, and once you manage to install all of the GNU utilities it just feels like a poorly-supported Linux distro. It's a bunch of wasted effort to imitate a fraction of Linux's power.
So what are we supposed to use? ReactOS? SerenityOS? The entire mainstream is a "you have to..." OS, I fear the day when I have to abandon GNOME for a desktop that treats developers like chopped liver. Your general preference is fine, but I'm surprised that it aligns with the OEMs that want to put advertisements all over your desktop.
macOS, as shipped, is only Unix-like. Even when configured to pass UNIX certification, it doesn't qualify without the temporary waivers:
if you want your installation of macOS 15.0 to pass the UNIX® 03 certification test suites, you need to disable System Integrity Protection, enable the root account, enable core file generation, disable timeout coalescing, mount any APFS partitions with the strictatime option, format your APFS partitions case-sensitive (by default, APFS is case-insensitive, so you’ll need to reinstall), disable Spotlight, copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin, set the setuid bit on all of these binaries, add /usr/local/bin to your PATH before /usr/bin and /usr/sbin, enable the uucp service, and handle the mystery issues listed in the four Temporary Waivers. [1]
Maybe your installation of macOS is technically Unix, but mine sure as hell ain't. Desktop "Unix" in 2026 is little more than lipstick on a pig anyhow.
> ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ...
This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local.
It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.
Oh, that makes more sense. I'm still not sure why you couldn't give the binaries setuid in their default locations, given that compliance testing also requires SIP to be disabled - but, in any case, at least they aren't setuid by default.
Anyways, "real UNIX systems must implement UUCP" is still extremely silly.
Disabling SIP still leaves the root filesystem as read-only and signature-checked (this is referred to as SSV, 'signed system volume'). There is a separate command to disable SSV, but it breaks the ability to install OS updates and is rarely used. /usr/local is one of the paths that's redirected to the read-write data volume.
I get most of this, but spotlight doesn’t need to be disabled altogether. That is a requirement for the verification, not the actually running as unix.
The nature of temporary waivers makes this untrue per the post you cited - The Open Group only grants them for 12 months, and the post is over a year old.
IMO, the only significant call-out is APFS case insensitivity by default, which makes the default volume a non-conforming filesystem. However, UNIX certification does not forbid you from mounting non-conforming filesystems (such as FAT32). Instead, this means the majority of software which makes certain assumptions about being used with UNIX conforming filesystems in addition to running on a UNIX conforming operating system are at risk of breaking.
Let's just say I have my doubts the author would have written a similar post if the final HP-UX release had "lied" about their certification by shipping with root login disabled by default and ulimit -c defaulting to zero.
To add on. If I remember correctly, its been awhile keeping track of it, they recommend you do because macOS is how you will get firmware updates as there are not any or many mechanisms to update firmware on Apple Silicon devices from Linux.
> I don't believe that Apple has ever acknowledged the project at all, let alone promote it. Apple is neutral towards their work as far as I can tell.
How do you draw that conclusion based on their public indifference? If they acknowledged it and promoted, you could assume they are pro Asahi. But them not acknowledging it doesn't imply they aren't anti Asahi.
If they actually wanted that project to succeed and bring more diversity to Mac dev ecosystem, they'd help the project outright. Meanwhile they continue to exploit Linux for their dev purposes while still locking you into the macOS. This is their clear strategy, i.e. to make you continue to use macOS even when you prefer Linux as dev platform, just based on what they showed during WWDC. They aren't neutral.
On the other hand I doubt that's intentional.
Even as an avid Apple critic I want to mention that people I trust and are more involved with Asahi, always pointed out that Asahi received the occasional little help from Apple devs where possible (surely, not with official documentation, or confidential infos).
So, I would wait until things had time to calm down and not get too invested with Apple bashing.
I’m sorry but some of the comments are out of touch. Apple devices do not have any intent of supporting separate OSes . Asahi supports M1 to M2. I can see this as a PSA to not install a beta but I am confused who would install both Akashi and macOS 27 beta at the same time when you could run the beta in a VM for development ? Others have said that this has been a fix that will happen soon.
There is clear intent, albeit not as good as the Boot Camp days. One doesn't just accidentally the Boot Policy subsystem to enable doing so every step of the way as it is. It has even been remarked as much by an Apple dev:
> I purposely designed a mechanism so that M1 Macs would retain the capability to boot completely arbitrary code instead of XNU if users wanted. But you have to 1) reboot to recoveryOS with a physical power button press and 2) put in your SEP-backed credentials.
> The challenge to running arbitrary code of course, as @marcan42 noted in his crowdfunding effort to getting linux on the M1, is that the SOC is undocumented, so you still have to reuse bits of XNU and/or reverse engineer a bunch of stuff.
> As one senior architect said "the contract is that there is no contract". So that Apple can change things to suit its own needs, not others', to build the best macOS experience, which is what most customers (besides y'all who follow me) are there for.
12.1 also added support for raw image boot, which was seemingly for, and has only been relevant to, making booting Asahi Linux easier. Discussion at the time https://news.ycombinator.com/item?id=29591578 and an archive of the tweet's content below:
> Looks like Apple changed the requirements for Mach-O kernel files in 12.1, breaking our existing installation process... and they also added a raw image mode that will never break again and doesn't require Mach-Os. And people said they wouldn't help. This is intended for us.
A consumer shouldn't be restricted from installing their own OS on a device that they bought, be it a smartphone, tablet, laptop, desktop, or server.
A company the size of Apple should also be required to release proper documentation that enables the porting of operating systems to these kinds of devices.
The reverse engineering work that the Asahi team did is remarkable but so much of it is ultimately busy work that didn't need to be done if we regulated the consumer electronics market appropriately.
If you believe this, the fight should be against PlayStation and Xbox.
They’re 100% commodity hardware and fully locked down from any user freedom. Weirdly everyone focuses on Apple with all their might instead of gaming consoles.
Because gaming consoles are for a very specific purpose (and sold as such – the ruling against Sony for blocking Linux on the PS3 only happened because they advertised Linux compatibility) and Macs are general purpose computers
No Universal Machine inside any consumer product should "be for a very specific purpose," where it is locked down to prevent the consumer-owner from making software or firmware modifications to it. This goes for pacemakers, automobiles, microwave ovens, MRI machines, and even Intel IME or the little microcontroller on your NVME drive. If I were elected Benevolent Dictator For Life of the United States, I would immediately withdraw us from WIPO, strike down the DMCA, and implement a 100%+ sales tax on all "finished products" for sale which had even just one such Universal Machine in it locked down as described, AND mandate a minimum of 25 years full warranty and support on such products with forced 100% buy-back for failure to support or patch or open. We must relegate today's form of 'proprietary' to a rental/lease-only model and quit calling it 'ownership'.
We must demand hardware which strongly adheres to the GNU/FSF ethos or it must be rejected society-wide (or made too expensive for the average normie to afford, effectively killing its market). Universal Machines are to free humanity, not limit or enslave us! THIS is why I don't buy Apple and hold my nose buying x86 (Qubes OS) and Google Pixels (GrapheneOS); if I could afford Raptor Engineering's TALOS II, I would own only that!
Macs are special purpose hardware for running macOS. A PC you build from custom components in your office is a general purpose machine. The gaming console example by oc is quite apt.
So what you're saying is it would be acceptable for Microsoft and PC manufacturers to lock down their hardware to running Windows only? Most ship with Windows so why not?
Yes? That's what the law currently allows. If we want to make a law that says companies are required to let end users install _any_ software they want onto any device they legally own, that encompasses almost the entire consumer product ecosystem. It is becomes hard to determine what is "general purpose" and what happens if Acer says "this machine runs windows specifically and isn't general purpose?" or they say "you no longer own this machine, you are licensing the hardware from us?"
It would not be acceptable, and it is the duty of ethical whitehat hackers to break such digital locks, flip the bird to Congress and the WIPO's DMCA, and free humanity. It would be ethical to form militias and raid federal prisons to free whitehat victims caught up by the state for it. Liberty is not free.
As long as consumers understand that is the kind of device they are purchasing then it is acceptable.
It is cheaper for hardware manufacturers to only support a single operating system instead of designing a platform to be used by many. It also makes security simpler.
Sure, but where do you draw the line? Many PCs ship with some custom hardware but are not locked down. The MacBook Neo is probably not locked down but uses the same SoC as the iPhone 16 Pro which is locked down.
IMO it's pretty arbitrary. I wouldn't expect to run software on an appliance, even if the underlying hardware is commodity. And an appliance is something that performs a specific task (fridge, car, etc.). There are gray area cases though when an appliance does more than its basic function (smart fridge, car infotainment).
What fundamentally makes a box which has a web browser, allows for third party app installs, and can drive them by connecting to a 4k monitor in addition to a keyboard and mouse different than a PC - other than the vendor setting policy such that their store only allows game and media streaming apps?
There was a brief period of time where you could buy your car like this. You'd purchase a rolling chassis from one manufacturer, and commission a coachbuilder to put a body on top. Many premium brands such as Bugatti, Rolls-Royce and Jaguar (Swallow) started in this fashion.
Today, outside of a few niche areas such as motorsport and commercial uses such as buses and coaches, nobody buys a vehicle this way. If you walked into your local Ford or Toyota and asked for a rolling chassis they would look at you as if you were insane, and rightly so. Integrating the development of the chassis and body into a single unit (both philosophically and literally [0]) has given us cars which are lighter, faster, more efficient, more featureful and safer by every measure.
We had our coachbuilding period in personal computing and it's all but over[1]. Nobody asks for the hardware and operating system to be sold separately for their washing machine, their TV, their microwave oven, PlayStation or Tesla EV. And yet for some reason some still cling to the idea that tablets and smartphones are personal computers rather than recognising them for the appliances they are.
As Steve Jobs allegedly said, design is not how something looks, design is how something works. How a feature works on a highly evolved device like an iPhone is a function of tightly coupled and carefully designed hardware and software.
Having this design process take place in different teams inside different companies, selling in different commercial models would not lead to a better outcome, it would be worse, much worse. The staggering commercial success of both iPhone and iPad is all the proof you need.
If hobbyists want to hobby, more power to them! But it's not something any government needs to regulate into existence.
No one said otherwise. Apple tightly coupling macOS is not mutually exclusive with Apple publishing specs for allowing to support other OS on that hardware.
That might be reasonable for a general purpose computer if we were talking about something like a Parallel Inference Machine running KL1 software on a KL0 kernel. But I think conflating Apple's products with that level of foundational engineering is highly disingenuous. They're not exactly trundling into the dark woods of exotic hardware and reinventing the bridge between human and computer. It's an ARM computer running a Unix clone. Apple's engineers aren't mapping every codepath and counting every micro-op, Darwin contains extensive amounts of third-party code.
Hardware and software have to interface at some point. When the people designing the hardware work at the company designing the software it's not unreasonable for them to come to some shared understanding of that interface which may not be standard, portable, or even publicly documented, and certainly not one that is stable.
This isn't incompatible with allowing users to install their own software. There just isn't an obligation on the original designers to make sure that software works. That onus is on the designers of that software.
That's all very well and true. However where I disagree is built upon the context that Apple is a very large corporation with a very large market share. There is a point at which an organization, private it may be, has grown to encompass a mass of the commons. It follows that it must be compelled to act in the public interest, and in a moral manner. Failure to implement architectural standards like ARM SR inhibits software freedom in no small manner, and for a general purpose computer with a large market share, it can be considered a failure to act in the public interest. The lack of a legal obligation is precisely the problem. Of course I support such regulation.
No Universal Machine, as a component or the whole product, which prevents owner modification through DMCA-styled digital locking mechanisms, must be allowed to be sold on the open market. Such contravenes the rights of ordinary citizens. It is disgusting to me that we have allowed this state of affairs through our collective and individual inaction. America's founding fathers (terrorists by today's definitions) tarred and feathered for much less!
The EU is not some kind of god that will make others do your bidding if you pray enough to them. You've been misguided into following a false religion.
For every niche thing you wish that Apple or other third parties do only for your own enjoyment, there are hundreds of millions of other people who want different niche things. Buy the products that suit your needs and wants, and companies have incentive to make them. And if no company wants to provide a feature or function that you know a huge portion of people will want, then you have a golden opportunity to start a business providing this.
> For every niche thing you wish that Apple or other third parties do only for your own enjoyment, there are hundreds of millions of other people who want different niche things.
We're talking Apple publishing specs for their hardware. That's not some "niche, particular, random" feature each persons asks for. We're all asking the same thing. Same thing that IBM did and what made the PC and IT industry as we know it.
> You've been misguided into following a false religion.
You're being misguided by your patronizing attitude.
I don't believe it. Ask a random number of people or a random number of Apple customers, and less than a fraction of a percent will say that the option to install Linux on their MacBook is what they most want from Apple.
More people will probably ask for a handle, or LED flashlight, or how about built-in invoicing software? Should the EU (praised be their names) force Apple to give these customers what they want? Why would their wants be any less important than yours?
Honestly this shouldn't be limited to traditional computing devices. Why do I need some hacker to reverse engineer my robot vacuum and then fully disassemble it just to install custom firmware to it? Should be a basic requirement of right to repair so all this smart crap doesn't wind up in a landfill when a company goes out of business or decides to arbitrarily drop support for it.
I can see the argument when it comes to locked-down mobile devices, but macOS is a general-purpose operating system with no restrictions on software sources that can't be easily disabled. Nearly every program available for Linux (excepting OS-specific stuff like desktop environments) is available for macOS, commercial and free, and there's plenty more that's macOS-only. Asahi is cool, but it's mostly used by enthusiasts - there's very little practical use for it as a macOS alternative. I think that you'd have a hard time convincing regulators that this cause really matters.
In any case, though, Apple agrees with you, and they explicitly built support for non-macOS OSes into the bootloader. This is a bug in the first developer beta of a new release.
Apparently fixed already, or will be fixed soon. https://social.treehouse.systems/@chaos_princess/11672546441...
So it was unintentional behavior in a beta release? Yeah that definitely does feel like something we should be getting up in arms about
404
Works here, here's the text for anyone who can't access it:
> Turns out APFS has an undocumented "VolBootable" flag that we were never setting since, well, it is undocumented, and the boot picker never cared about it (it read it and printed it's state to system log, just did not take any action). Anyway, fix PR-ed to asahi-installer, old installs will have an installer option to set the flag. But still, probably hold off on installing macos betas :P.
It seems like this is a bug, apple went through the trouble to allow something like asahi to be possible in the first place. I doubt they're purposely trying to break it.
Apple designed a bootloader for Apple Silicon Macs that allows you to run an unsigned OS without degrading security when you boot into MacOS. This wasn't an accident.
Macs have always allowed you to run another OS.
iDevices have always had a locked bootloader.
People shouldn't confuse the two.
M series macs are weird tho, yes the bootloader allows it but absolutely no documentation on the hardware, drivers etc. Can't help but to think the goal of this wasn't to actually allow third-party OSes, but for development purposes(and ye they could hide the feature behind apple account with paid dev license) or anti-anti-trust measures à-la Google with Firefox: in front of a jury of normal people they can simply say "look there's these nerds making Asahi" the same way "look we're not a monopoly Firefox has .2% market share".
> M series macs are weird
More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over?
> Can't help but to think the goal of this wasn't to actually allow third-party OSes
Apple has explicitly stated that allowing third party OSes is exactly the purpose of the new bootloader.
I don't know about Intel ME but AMD PSP is basically the equivalent of Apple's Secure Enclave, so there's that.
You should probably do do some reading on the subject to gain a bit more understanding:
> This puts [Apple Silicon Macs] somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads).
https://asahilinux.org/docs/platform/introduction/
The Secure Enclave is equivalent to a PC's TPM (a TPM is now required to run Windows) not any form of a management engine.
> The Secure Enclave is equivalent to a PC's TPM
AMD PSP is little more than an embedded TPM. The capabilities are significantly different vs. Intel ME.
> AMD PSP is little more than an embedded TPM
Again, you've got some reading to do.
> the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response".
Critics worry it can be used as a backdoor and is a security concern.
https://www.wikipedia.org/wiki/AMD_Platform_Security_Process...
Now explain to me how Apple's Secure Enclave does not do this:
> the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response".
It implements TPM or something similar. It is used in the boot process for a secure boot chain. And the last generic point is probably just that it implements the hardware random number generator for the CPU, which Secure Enclave also does (in a different way).
I could worry about Secure Enclave being used as a backdoor and being a security concern, too. Doesn't mean it actually is!
Did Apple state it? I remember it was one of the lead engineers who worked on Apple Silicon, which I guess could count as an Apple statement
Yes, more weird than that. x86 PCs have fairly standardised boot and autoconfiguration (UEFI and ACPI). ARM based systems, including the Apple M series, don't. You just have to know what's there (device trees), and Apple isn't going to tell you. Hence why it's difficult to make another OS run on it, because you first need to find out what hardware's even there, and how to talk to it. It's initialised by Apple before iBoot runs, sure, but you don't even know what it is, so good luck writing a driver for it.
The Intel ME / AMD PSP are creepy, and probably a security risk to the device owner, but they're not weird, you can run an OS without even knowing they're there, and they like it that way.
Asahi Linux already does use an open source UEFI implementation (U-Boot) to boot Linux.
https://en.wikipedia.org/wiki/Das_U-Boot
The Asahi installer will also allow you to install UEFI alone, in case you want to use UEFI to install some other OS.
The hardware management engines in modern x86 chips are backdoors running at a higher privilege level than the installed OS's kernel.
It's hard to see them as anything else.
Apple's Secure Enclave and ARM's Truszone work the same way as Intel ME and AMD PSP. All of them have a separate specialized minimal OS running on a specially protected memory that cannot be accessed by the normal OS.
Apple can lock your Mac just like other manufacturers can do via Intel ME. All of them are backdoors.
They don't. ME and PSP are separate cores with full memory and configuration bus access. TrustZone is nothing like this, it is a higher privilege level on the main cpu cores, more similar to SMM and used for pretty much the same purposes. Secure enclave is yet again nothing like any of the former and is similar to a TPM.
Secure Enclave is a completely different core, I don't understand why you are conflating it with TrustZone
It's true that UEFI and ACPI cover a lot of ground whose equivalent on Apple Silicon is undocumented. But note that Linux on x86 does still rely on lots of reverse-engineered drivers to talk to various devices - not necessarily on servers which are designed to run Linux, but very much so on desktops and (especially) laptops.
>ARM based systems, including the Apple M series, don't.
You're thinking of old SBCs, most likely. ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) have +/- same level of auto-configuration and hardware resource discovery as x86 PCs.
> ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included)
Either this is untrue or misinterpreted - the SystemReady DeviceTree band (the only one Macs could possibly fit into, given they don't implement ACPI) still requires that devices implement EBBR, which requires that devices implement UEFI. Macs don't, and so are very much not SystemReady compliant.
Most of the ARM Servers support this, in any case.
>More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over?
Considering they're pretty much fully undocumented (officially, that is) and could contain any number of IME equivalents since we know that they already have independent processors like the secure enclave running its own OS: yeah, probably more weird. Just because Asahi did not find one doesn't mean it doesn't exist.
There are plenty of people looking, not just the Asahi people.
That's just a normal part of Mac development. Apple sees documentation as a net negative for them, something that can constrain them in the future. So they only document the major highways and leave everything else as an exercise to the reader.
If you're using an unstable API they expect you to figure everything out yourself. It doesn't mean that they don't want you to use it though.
I think they are wary about macOS becoming a designated DMA gatekeeper, it would certainly be very close to the user and income thresholds.
> Can't help but to think the goal of this wasn't to actually allow third-party OSes, but for development purposes
Could also be pretending to be open while making sure nothing dangerous actually gets made.
The design of the exposed mechanism is explicitly about booting unsigned versions of MacOS. There is zero support for booting anything else, but no enforcement that it must be MacOS.
However, apple's justification for exposing this mechanism to users appears to explicitly include "booting linux" even if the mechanism has zero explicit support for booting linux.
And if Apple were going to change their mind and try to block linux, they would intentionally modify the bootloader to remove that functionality, not break the boot picker.
Reminds me of when the Xbox 360 came out, Microsoft had to buy a bunch of Macs because Macs had PowerPC processors, so it was kind of a no-brainer to get the darn thing going quickly enough. Ultimately Windows was the standard way to build Xbox games but it is kind of funny to think, one day someone at Apple saw an order for easily several dozens of Macs from Microsoft, and wondered if hell froze over.
Back in the 2000s MS agreed to port Office and Internet Explorer to the Mac. This was a good move for both companies. Bill Gates appeared on screen during an Apple Conference to talk with Steve. Huge boos. Steve had to work the crowd back from the ledge.
Then Office and IE were ported. It was so weird running Word on a Mac. It was a good port too. They did a good job of embracing Mac UI ideas. I found the Mac Word better than Win Word.
I was kind of new to the Mac back then.
I imagine Apple donated a bunch of early OS 10 machines to MS for development. I wonder if the MS Mac Dev team was a pariah at MS.
Word was originally released for the Mac in 1985, so the deal was not that Office would be ported, just that MS would keep developing Office for the Mac.
If they allowed something similar on iphones, I'd switch to an iPhone the day an alternate os worked well enough for daily use.
why? In my mind the appeal of the iPhone is iOS. The hardware is nice, but so is the hardware of certain Android phones.
I think it would be nice if we could run unsigned apps on iOS (in the US), but booting your own OS on an iPhone is a whole different story
> I think it would be nice if we could run unsigned apps on iOS
Apple enforces those restrictions via the permanently locked bootloader. The main benefit of unlocking the bootloader on an iPhone would be to run a modified version of iOS that allows for the installation of unsigned apps. Apple wouldn't like it and might even get litigious over it, but still.
> (in the US)
Apps intended for release onto alternative app stores in the EU, Japan, and Brazil still need to be approved and signed by Apple. These laws were nearly useless.
I'd run ios if I could build my own apps for it without begging for Apple's approval to use my own device.
Really, all I want from a phone is to be able to run Linux/xfce on it.
I think iPhone hardware is better for the price on the used market. (I refuse to buy new phones. They're too locked down and shitty to warrant spending that much.)
I have fond memories in the early 2000s of getting the first MacBook Pro's with Intel Core i7's and the first thing we did at my company was build and install gentoo.
People forgot already about Bootcamp
IDecices should absolutely be treated as laptops and desktops which allow another OS to run on the device. This why I have not bought an Apple device for years.
EU is the only governing body that would push owning the device you _buy_. Unfortunately their seem more geared moving to a surveillance state at the moment with chat control.
They're different for now, but it's frog-boiling. Apple has been steadily adding more and more hoops to the process for Macs, and eventually they are going to end up as locked down as iPhones.
You get clicks for "Apple bad", not for "there was this boot flag and once we figured that out problem solved".
The boot flag was undocumented, like most features of Apple devices that are required knowledge for being able to port another operating system to them.
Because of this lack of documentation, every release of a new version of Apple hardware or software may require the restarting of the reverse engineering work, like in this case, just to keep working the alternative operating system.
The boot flag might have been undocumented, but so was absolutely everything else that was reverse engineered to make Asahi possible.
Rather than blaming Apple for this, the correct approach would have been to post something like "if you dual boot Asahi, don't upgrade to macOS 27 until you've done this".
I keep wondering when "undocumented" stopped meaning "don't rely on this because it can and probably will change at the vendors will and they don't want you to shoot yourself in the foot and then you're on your own"? Nothing was "owed" for the undocumented...if it worked after an upgrade, it was a good day.
The "correct approach" is "Apple doesn't support Linux on M-series processors. If you're not willing to accept shit breaking regularly and having to do (much more likely, relying on other people without compensating them) the actual work to RE Apples ever-changing stuff then don't buy hardware that explicitly does not support the OS you want to run. If you want 'plug-and-play', you are barking up the wrong tree." This really isn't hard.
Back in the heyday of Hackintosh, there was always someone who wandered into one of the forums to shittalk Apple for not supporting some chunk of hardware they owned but Apple never shipped (usually with some whining to the effect "Windows supports my knock-off of a knock-off Alibaba special and it's totally unreasonable that unsupported MacOS on unsupported hardware doesn't Just Work!"), but I don't recall the adults in the room giving that sort of nonsense the time of day other than to say "here's the stuff that we know works...if you don't have that, it's on you not Apple or the uncompensated Hackintosh devs to figure it out".
How times change, I guess.
Edit: s/plug-and-pay/plug-and-play/ Freudian slip, I guess.
It's Apple's bootloader. They were the ones that chose to use iBoot and not implement UEFI-style booting like prior Macs.
...why would they, this is a strict improvement with less surface area
Because it was a featureset they supported without trouble on prior Macs?
The onus is on Apple to not make iBoot suck, they don't get a free pass for Microsoft-level boot volume ignorance.
The 'onus' is on Apple to support an OS they never said they'd support, to the potential detriment of the one they do support, because a tiny number of people bought Apple hardware to run...lemme look again...an OS Apple never said they'd support? That's an...interesting...point of view, but probably not suprising considering the pervasive "how dare you not do unpaid work to make me happy no matter what your priorities are" attitude running around OSS these days. At least Apple won't rage-quit the project or have a nervous breakdown because the free-riders are demanding something never promised.
Such bugs have happened and been reported before. Asahi exercises "raw boot" facilities that just don't get all that much attention in any other context.
(removed)
If the happy path disappears, the not-so-happy path will be taken to allow for booting custom kernels, one that will likely rely on turning the some or a lot of the RE energy towards breaking the Secure Enclave, the bootloader, and so on. Apple practically laid the red carpet out to avoid people trying to crack the parts of the hardware/software chain-of-trust they would really rather not have cracked. A similar strategy helped keep the Xbox One un-pwned for over a decade (running homebrew was allowed in a specific mode). It is doubtful Apple's legal department isn't aware of the value of the current software strategy.
So isn't that just purely security by obscurity then? Would they not rather have someone publicly break it instead of selling a zero day?
Nothing is perfectly secure on its own. No system designed or checked by humans ever will be. After all, the Xbox One was indeed pwned, relatively recently. However, because the juice wasn't worth the squeeze for so long, it got pwned years after it was a relevant, money making console.
Novel jailbreaks for ancient iPhones are not worth much. But attention on current, brand new devices means increasing the danger that a mistake gets found, which increases the odds that that mistake is found by someone who wants to sell it for the most money. Also, from Apple's perspective a zero-day in the bootloader on macOS also means a zero-day in the bootloader in all of the billions of iOS devices out there too. They do not want to give anyone anymore reason than what already exists to try and pwn LLB or iBoot. Given a happy path, all of that hacker energy for "put Linux on my M1 Macbook" is put towards device drivers and support, rather than "how the hell do we get an alternative kernel booting on this thing".
Fewer bullets pinging off the armor. Fewer cracks in the fuselage forming. Fewer knives to dodge. All of it means Apple's boot process for their current devices are less likely to be pwned before they turn into e-waste (whenever that is, not making a comment on Apple's perhaps accelerated or otherwise practices in obsolescence).
Just like a jetliner will eventually succumb to entropy and become dangerous to fly, so too will a lot of "secure" software. You only need to actively maintain a jetliner while it is flying passengers or cargo. Once it is retired, it can rot, people can break into the husk of it at the junkyard and fornicate and smoke crack and smash windows and steal parts of the fuselage. At that point, who cares?
No, if their lawyers want it gone, Apple will just update the bootloader to reject local signing keys.
The actual problem was that Apple has an undocumented APFS key for if a volume is bootable, which Asahi wasn't setting and Apple wasn't checking, but now they do, so they do.
>apple went through the trouble to allow something like asahi to be possible in the first place
if going through trouble means "doing less shit to lock their systems down", then yes.
Apple ultimately dgaf about linux.
The comments there are absolutely insane lol, especially now that we know it's a bug.
I did not realize that some people were still so anti-Apple. I'm of course not saying that there's not a small element of truth in many of the comments, but talk about some straw man arguments.
It was not a bug, it was just another undocumented Apple feature.
However, when a company sells a device, as opposed to providing it for lease, I do not believe that it has the right to not document any feature of the device that is relevant for its usage, like it should also not have the right to impose any constraints on how the owner should use what has been bought.
Obviously, the owner of any kind of things may not use them to perform illegal acts, but that is a constraint imposed by the valid laws, not by the seller of the things.
Today, far too many companies claim to sell things, but they also attempt to control what the owner may do with them. I avoid to buy such things, but my choices are limited by those who buy them, allowing these policies to be beneficial for the sellers.
MacBooks are not designed to boot any OS other than macOS. Just because someone hacks one such that they get custom code running that doesn't mean all of that now becomes in scope for what is relevant for usage. Someone had to go above and beyond to hack the device to get another OS to run.
I mean, do you expect a blender to come with instructions on how to replace the engine?
> I do not believe that it has the right to not document any feature of the device that is relevant for its usage.
This is an extremely broad requirement to place on any and all manufacturers. I agree companies shouldn't intentionally restrict what you can do with your stuff, but on the other hand, if you're trying to rebuild your lawn mower into a motorbike, you can't really be mad that the company didn't provide you with a specification the exact dimensions of the exhaust, can you?
This is defence mechanism I guess.
People were screwed so many times by so many companies, they have been taught the hard way to behave like that: either make a lot of noise and hate in the first stage, or just agree that some functionality has been removed to milk more money etc.
Apple transformed handheld computing into walled garden, brainwashed installation into "sideloading". Apple software update made Apple laptops to fail booting Linux.
"Concerned people are insane anti-Apple without any solid arguments, lol"
Not how I'm intending to come off as. I am more specifically mentioning the comments that say stuff like "Apple laptops are overpriced pieces of junk" but without thinking of those whose workflows would be impacted very negatively by moving to more open platforms (not because of the platform, but I mean because of hardware)
It's like they are looking at a specific application, finding that Macs are bad at it, and declaring it crap in every way, which isn't true.
Maybe because you can just buy a nice ThinkPad, slap any distro on and be done with it. Without all this hassle.
That's true, if you want a Linux laptop. However, no ThinkPad at this moment can come close to the horsepower + battery life in a modern Mac. Not saying Apple is excused because of that, just an observation.
I did not realize all the tech companies had completely changed their behaviors to be granted the benefit of the doubt.
Sure they don't do EVERYTHING we think they do, but they do so much, and so much more we DON'T know about...
Anyway, Apple could help the Linux team in months to close huge amounts of functionality gaps but ... they don't.
I am not (purposefully) granting them the benefit of the doubt.
In my comment I simply noted that the comments there are extremely anti-Apple yet without any solid arguments behind them, and I also noted that the whole thing is just because of an APFS flag which could be fixed from Asahi's side. The main reason I made the comment is because I am shocked at how poorly backed the arguments are.
As for Apple not helping the Linux team, why would they, or any major OEM? Apple is perfectly happy with https://github.com/apple/container
When Microsoft futzes with the MBR and locks out Linux users, we complain. When Apple futzes with the APFS partition flags, we complain. It's not that hard to understand.
> why would they, or any major OEM?
Apple Silicon doesn't expose any obvious ACPI-equivalent power management interface. Apple could very easily document that hardware without exposing proprietary devicetree drivers, but someone internally must love watching Asahi users suffer through cpuidle. There isn't likely to be advanced power management drivers for Apple Silicon on Linux within this decade.
At the very least, I think it's fair to expect Apple to document breaking iBoot changes. They don't have to, but they feed a dog's dinner to their power users when they don't.
> There isn't likely to be advanced power management drivers for Apple Silicon on Linux within this decade.
Amazing levels of confidence, when per Asahi's last progress report, one exists already.
You should read the report, it basically repeats what I just said:
> The power management architecture on this platform is incredibly complex, and there are a lot of moving parts involved in making it all work. There is Power Manager (PMGR), which is responsible for the SoC’s power domains, but there is also the Power Management Processor (PMP), which does… stuff?
> The actual low-level details of how power is managed across the SoC are quite opaque. [...] PMP will not read these reports if it is not booted, and certain power management functionality will not work. We are not sure exactly what it does with this information, but it likely involves controlling Apple Fabric power and clocking, among other things.
> There is obviously still work to be done to reach macOS levels of idle and suspend time
I still do not think that we will get advanced power management equivalent to ACPI within this decade, unless Apple starts documenting stuff. It took Asahi six years to replace cpuidle on M1, we're going to be here for a while.
Sadly both main ARM platforms (Apple silicon and Qualcomm) are a mine field for Linux
Most computers have been like that, FOSS got lucky that IBM failed to secure the PC for themselves, thus the PC clones.
When folks say Intel and AMD are done, and we should all be on ARM, or RISC-V, beware of what to wish for.
Yes there are device trees now, however someone has to keep them up to date, and that is only part of what makes a motherboard.
I have said it for a while, Microsoft's business strategy was probably the best thing that ever happened to Free/Open software. They were ones pushing for more open systems so that they could sell DOS and Windows to other vendors. yes, it left the door open for others but they also figured they could push their software far harder than others could.
I agree with the ARM/RISCV stance that we should be cautious with what we ask. I have seen some RiscV providers in China are starting to push for a BIOS compatible boot system which is great to see, but there is no guarantee that it will be adopted or it will last for long.
This is also not guaranteed to be adopted widely, but the RISC-V Server Platform Specification was recently standardized with mandatory UEFI and ACPI support: https://github.com/riscv-non-isa/riscv-server-platform/relea... I'd rather have OpenFirmware like enterprise POWER, but anything is better than static device trees.
Yeah the mainstream alternatives to x86 are all super locked down
Other than this situation, what other landmines are there? I have an M1 with Asahi Arch Linux that I've been using as my primary laptop for the last 8 months, its my favorite laptop by far out of the 5ish I have.
does suspend and other hw fully works on it? however it is an old gen computer
The M1 is still perfectly fine.
Only M1 and M2 (and Pro versions).
Pretty much all ARM platforms are. Even ARM devices designed from the ground up to be Linux devices are full of issues, like the MNT Pocket Reform's lack of HW suspend. The tight interop between vendor and implementation is a huge anti-pattern for software freedom, and the standardization initiatives like ARM SR are nowhere to be seen. It's probably the most problematic part of ARM being the future of personal computing, yet another impending manifestation of enshittification.
what about the ones from CIX like the orangepi or their framework mainboard? (though I agree, I miss UEFI for all its faults)
Those are currently suffering from high power draw because they have to keep the cores awake for memory speeds. Lackluster performance as well, but thats the problem with the majority of the ARM ecosystem ever since apple started crafting SoCs.
I must have missed something...what does Apple creating M-series have to do with Allwinner, Qualcom, Mediatek, AWS, and the rest of the ARM ecosystem having 'lackluster performance'?
They showed what ARM could pull off, and no one has caught up since at least on a single core performance level.
Ah...it's "they haven't matched Apple" (not even Graviton?), not "Apple impeded them in some way". Fair, but that was not clear.
You do actually get UEFI on a few of these, though personally I've always fared better with U-Boot. (Sooner or later, I always run into something that is a simple edit in the device tree or uEnv, but UEFI doesn't expose.)
i hope, but i dubt that will be mass produced.. so no economy of scale
i run linux on both in arch and fedora versions with zero problems, by using the hypervisor framework of macos and wsl2 (wrapper for hyperv). do you need a more direct than hypervisor access to some hardware?
A lot of us would prefer MS/Apple to never be within touching range of our hardware.
On the other hand, your “us” is not very big compared to your “not us.” I like Linux as a server OS (and would pick it over Windows or MacOS for that any day of the week that ends in y), but as a desktop OS it’s just more work than I care to exert (in fact, Windows also exceeds my tolerance for fiddliness in a desktop OS). My general preference is for “you don’t have to” over “you can” as much as possible which is the exact opposite of the Linux desktop experience.
macOS and Windows are both such a chore for development, though. WSL was the closest I got to an "it just works" dev environment, but it exposes just how bad native toolchains like Cygwin and git bash are. macOS is hardly any better, and once you manage to install all of the GNU utilities it just feels like a poorly-supported Linux distro. It's a bunch of wasted effort to imitate a fraction of Linux's power.
So what are we supposed to use? ReactOS? SerenityOS? The entire mainstream is a "you have to..." OS, I fear the day when I have to abandon GNOME for a desktop that treats developers like chopped liver. Your general preference is fine, but I'm surprised that it aligns with the OEMs that want to put advertisements all over your desktop.
> it just feels like a poorly-supported Linux distro.
That's because it's Unix, not Linux.
macOS, as shipped, is only Unix-like. Even when configured to pass UNIX certification, it doesn't qualify without the temporary waivers:
Maybe your installation of macOS is technically Unix, but mine sure as hell ain't. Desktop "Unix" in 2026 is little more than lipstick on a pig anyhow.[1] https://www.osnews.com/story/141633/apples-macos-unix-certif...
As an aside:
> ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ...
This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local.
It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.
Oh, that makes more sense. I'm still not sure why you couldn't give the binaries setuid in their default locations, given that compliance testing also requires SIP to be disabled - but, in any case, at least they aren't setuid by default.
Anyways, "real UNIX systems must implement UUCP" is still extremely silly.
Disabling SIP still leaves the root filesystem as read-only and signature-checked (this is referred to as SSV, 'signed system volume'). There is a separate command to disable SSV, but it breaks the ability to install OS updates and is rarely used. /usr/local is one of the paths that's redirected to the read-write data volume.
I get most of this, but spotlight doesn’t need to be disabled altogether. That is a requirement for the verification, not the actually running as unix.
> it doesn't qualify without the temporary waiver
The nature of temporary waivers makes this untrue per the post you cited - The Open Group only grants them for 12 months, and the post is over a year old.
IMO, the only significant call-out is APFS case insensitivity by default, which makes the default volume a non-conforming filesystem. However, UNIX certification does not forbid you from mounting non-conforming filesystems (such as FAT32). Instead, this means the majority of software which makes certain assumptions about being used with UNIX conforming filesystems in addition to running on a UNIX conforming operating system are at risk of breaking.
Let's just say I have my doubts the author would have written a similar post if the final HP-UX release had "lied" about their certification by shipping with root login disabled by default and ulimit -c defaulting to zero.
I don’t use Windows so I don’t have advertisements on my desktop. I have had very little friction with using MacOS for development.
Then maybe a "lot of" you should not be buying Apple hardware?
Or Apple could just fix these issues.
what issues are you referencing?
Guys its a beta, did we forget what those were? Save the assumptions of ill intent until it hit at least hits production
Source: https://social.treehouse.systems/@AsahiLinux/116719749555082...
Do you need to keep a MacOs installation when you install Asahi?
I believe it's not strictly necessary, but the project recommends that you do.
To add on. If I remember correctly, its been awhile keeping track of it, they recommend you do because macOS is how you will get firmware updates as there are not any or many mechanisms to update firmware on Apple Silicon devices from Linux.
It’s a beta… Apple is very pro Asahi
> Apple is very pro Asahi
I don't believe that Apple has ever acknowledged the project at all, let alone promote it. Apple is neutral towards their work as far as I can tell.
> I don't believe that Apple has ever acknowledged the project at all, let alone promote it. Apple is neutral towards their work as far as I can tell.
How do you draw that conclusion based on their public indifference? If they acknowledged it and promoted, you could assume they are pro Asahi. But them not acknowledging it doesn't imply they aren't anti Asahi.
If they actually wanted that project to succeed and bring more diversity to Mac dev ecosystem, they'd help the project outright. Meanwhile they continue to exploit Linux for their dev purposes while still locking you into the macOS. This is their clear strategy, i.e. to make you continue to use macOS even when you prefer Linux as dev platform, just based on what they showed during WWDC. They aren't neutral.
Beers not allowed
[dead]
macOS 27 Golden Cage /s
On the other hand I doubt that's intentional. Even as an avid Apple critic I want to mention that people I trust and are more involved with Asahi, always pointed out that Asahi received the occasional little help from Apple devs where possible (surely, not with official documentation, or confidential infos).
So, I would wait until things had time to calm down and not get too invested with Apple bashing.
I’m sorry but some of the comments are out of touch. Apple devices do not have any intent of supporting separate OSes . Asahi supports M1 to M2. I can see this as a PSA to not install a beta but I am confused who would install both Akashi and macOS 27 beta at the same time when you could run the beta in a VM for development ? Others have said that this has been a fix that will happen soon.
There is clear intent, albeit not as good as the Boot Camp days. One doesn't just accidentally the Boot Policy subsystem to enable doing so every step of the way as it is. It has even been remarked as much by an Apple dev:
https://x.com/XenoKovah/status/1339914716454526979
> I purposely designed a mechanism so that M1 Macs would retain the capability to boot completely arbitrary code instead of XNU if users wanted. But you have to 1) reboot to recoveryOS with a physical power button press and 2) put in your SEP-backed credentials.
> The challenge to running arbitrary code of course, as @marcan42 noted in his crowdfunding effort to getting linux on the M1, is that the SOC is undocumented, so you still have to reuse bits of XNU and/or reverse engineer a bunch of stuff.
> As one senior architect said "the contract is that there is no contract". So that Apple can change things to suit its own needs, not others', to build the best macOS experience, which is what most customers (besides y'all who follow me) are there for.
12.1 also added support for raw image boot, which was seemingly for, and has only been relevant to, making booting Asahi Linux easier. Discussion at the time https://news.ycombinator.com/item?id=29591578 and an archive of the tweet's content below:
> Looks like Apple changed the requirements for Mach-O kernel files in 12.1, breaking our existing installation process... and they also added a raw image mode that will never break again and doesn't require Mach-Os. And people said they wouldn't help. This is intended for us.
I wish the EU would regulate this kind of stuff.
A consumer shouldn't be restricted from installing their own OS on a device that they bought, be it a smartphone, tablet, laptop, desktop, or server.
A company the size of Apple should also be required to release proper documentation that enables the porting of operating systems to these kinds of devices.
The reverse engineering work that the Asahi team did is remarkable but so much of it is ultimately busy work that didn't need to be done if we regulated the consumer electronics market appropriately.
If you believe this, the fight should be against PlayStation and Xbox.
They’re 100% commodity hardware and fully locked down from any user freedom. Weirdly everyone focuses on Apple with all their might instead of gaming consoles.
Because gaming consoles are for a very specific purpose (and sold as such – the ruling against Sony for blocking Linux on the PS3 only happened because they advertised Linux compatibility) and Macs are general purpose computers
No Universal Machine inside any consumer product should "be for a very specific purpose," where it is locked down to prevent the consumer-owner from making software or firmware modifications to it. This goes for pacemakers, automobiles, microwave ovens, MRI machines, and even Intel IME or the little microcontroller on your NVME drive. If I were elected Benevolent Dictator For Life of the United States, I would immediately withdraw us from WIPO, strike down the DMCA, and implement a 100%+ sales tax on all "finished products" for sale which had even just one such Universal Machine in it locked down as described, AND mandate a minimum of 25 years full warranty and support on such products with forced 100% buy-back for failure to support or patch or open. We must relegate today's form of 'proprietary' to a rental/lease-only model and quit calling it 'ownership'.
We must demand hardware which strongly adheres to the GNU/FSF ethos or it must be rejected society-wide (or made too expensive for the average normie to afford, effectively killing its market). Universal Machines are to free humanity, not limit or enslave us! THIS is why I don't buy Apple and hold my nose buying x86 (Qubes OS) and Google Pixels (GrapheneOS); if I could afford Raptor Engineering's TALOS II, I would own only that!
And PS3 had Linux support because of EU taxes :)
Game consoles had a higher import tax than "computers" -> allow linux, save money.
IIRC they did a similar thing with the PS2 with some janky-ass BASIC interpreter being available.
Macs are special purpose hardware for running macOS. A PC you build from custom components in your office is a general purpose machine. The gaming console example by oc is quite apt.
Macs are specialized in running macOS and its app ecosystem and integrating with other Apple devices. Apple don't advertise Linux compatibility.
So what you're saying is it would be acceptable for Microsoft and PC manufacturers to lock down their hardware to running Windows only? Most ship with Windows so why not?
Yes? That's what the law currently allows. If we want to make a law that says companies are required to let end users install _any_ software they want onto any device they legally own, that encompasses almost the entire consumer product ecosystem. It is becomes hard to determine what is "general purpose" and what happens if Acer says "this machine runs windows specifically and isn't general purpose?" or they say "you no longer own this machine, you are licensing the hardware from us?"
It would not be acceptable, and it is the duty of ethical whitehat hackers to break such digital locks, flip the bird to Congress and the WIPO's DMCA, and free humanity. It would be ethical to form militias and raid federal prisons to free whitehat victims caught up by the state for it. Liberty is not free.
DMCA allows circumventing this kind of stuff for repair and interoperability.
As long as consumers understand that is the kind of device they are purchasing then it is acceptable.
It is cheaper for hardware manufacturers to only support a single operating system instead of designing a platform to be used by many. It also makes security simpler.
> Weirdly everyone focuses on Apple
Lifetime Xboxes sold: ~200 Million
Lifetime iPhones sold: 3 Billion
Why is it weird?
Well, currently 6 Billion active Android phones exist. Not lifetime total: current active. So there's that.
Android phones can come with the bootloader unlocked, although many vendors do lock them, particularly in the US.
They are actually not commodity hardware. The PlayStation and Xbox CPU/GPU is custom built for the console. Try finding a CPU that can use GDDR RAM!
Why would I need to "find a CPU"? It's there inside the console.
I should be able to put in a Linux DVD or memory stick and install Linux on it.
Or at the _very_ least an alternative app store.
Wouldn't that be the same argument for Apple hardware?
Sure, but where do you draw the line? Many PCs ship with some custom hardware but are not locked down. The MacBook Neo is probably not locked down but uses the same SoC as the iPhone 16 Pro which is locked down.
IMO it's pretty arbitrary. I wouldn't expect to run software on an appliance, even if the underlying hardware is commodity. And an appliance is something that performs a specific task (fridge, car, etc.). There are gray area cases though when an appliance does more than its basic function (smart fridge, car infotainment).
What fundamentally makes a box which has a web browser, allows for third party app installs, and can drive them by connecting to a 4k monitor in addition to a keyboard and mouse different than a PC - other than the vendor setting policy such that their store only allows game and media streaming apps?
There was a brief period of time where you could buy your car like this. You'd purchase a rolling chassis from one manufacturer, and commission a coachbuilder to put a body on top. Many premium brands such as Bugatti, Rolls-Royce and Jaguar (Swallow) started in this fashion.
Today, outside of a few niche areas such as motorsport and commercial uses such as buses and coaches, nobody buys a vehicle this way. If you walked into your local Ford or Toyota and asked for a rolling chassis they would look at you as if you were insane, and rightly so. Integrating the development of the chassis and body into a single unit (both philosophically and literally [0]) has given us cars which are lighter, faster, more efficient, more featureful and safer by every measure.
We had our coachbuilding period in personal computing and it's all but over[1]. Nobody asks for the hardware and operating system to be sold separately for their washing machine, their TV, their microwave oven, PlayStation or Tesla EV. And yet for some reason some still cling to the idea that tablets and smartphones are personal computers rather than recognising them for the appliances they are.
As Steve Jobs allegedly said, design is not how something looks, design is how something works. How a feature works on a highly evolved device like an iPhone is a function of tightly coupled and carefully designed hardware and software.
Having this design process take place in different teams inside different companies, selling in different commercial models would not lead to a better outcome, it would be worse, much worse. The staggering commercial success of both iPhone and iPad is all the proof you need.
If hobbyists want to hobby, more power to them! But it's not something any government needs to regulate into existence.
[0] https://en.wikipedia.org/wiki/Vehicle_frame#Unibody
[1] Servers/Linux are the commercial vehicles in this analogy
I don't think it's unreasonable for a device manufacturer to tightly couple it to the software they design to run on it.
No one said otherwise. Apple tightly coupling macOS is not mutually exclusive with Apple publishing specs for allowing to support other OS on that hardware.
That might be reasonable for a general purpose computer if we were talking about something like a Parallel Inference Machine running KL1 software on a KL0 kernel. But I think conflating Apple's products with that level of foundational engineering is highly disingenuous. They're not exactly trundling into the dark woods of exotic hardware and reinventing the bridge between human and computer. It's an ARM computer running a Unix clone. Apple's engineers aren't mapping every codepath and counting every micro-op, Darwin contains extensive amounts of third-party code.
Hardware and software have to interface at some point. When the people designing the hardware work at the company designing the software it's not unreasonable for them to come to some shared understanding of that interface which may not be standard, portable, or even publicly documented, and certainly not one that is stable.
This isn't incompatible with allowing users to install their own software. There just isn't an obligation on the original designers to make sure that software works. That onus is on the designers of that software.
That's all very well and true. However where I disagree is built upon the context that Apple is a very large corporation with a very large market share. There is a point at which an organization, private it may be, has grown to encompass a mass of the commons. It follows that it must be compelled to act in the public interest, and in a moral manner. Failure to implement architectural standards like ARM SR inhibits software freedom in no small manner, and for a general purpose computer with a large market share, it can be considered a failure to act in the public interest. The lack of a legal obligation is precisely the problem. Of course I support such regulation.
No Universal Machine, as a component or the whole product, which prevents owner modification through DMCA-styled digital locking mechanisms, must be allowed to be sold on the open market. Such contravenes the rights of ordinary citizens. It is disgusting to me that we have allowed this state of affairs through our collective and individual inaction. America's founding fathers (terrorists by today's definitions) tarred and feathered for much less!
> A consumer shouldn't be restricted from installing their own OS on a device that they bought
That is not what the industry, that pays lobby money, wants. They want to be able to control what the user runs and extract profits.
The EU is not some kind of god that will make others do your bidding if you pray enough to them. You've been misguided into following a false religion.
For every niche thing you wish that Apple or other third parties do only for your own enjoyment, there are hundreds of millions of other people who want different niche things. Buy the products that suit your needs and wants, and companies have incentive to make them. And if no company wants to provide a feature or function that you know a huge portion of people will want, then you have a golden opportunity to start a business providing this.
> For every niche thing you wish that Apple or other third parties do only for your own enjoyment, there are hundreds of millions of other people who want different niche things.
We're talking Apple publishing specs for their hardware. That's not some "niche, particular, random" feature each persons asks for. We're all asking the same thing. Same thing that IBM did and what made the PC and IT industry as we know it.
> You've been misguided into following a false religion.
You're being misguided by your patronizing attitude.
> We're all asking the same thing.
I don't believe it. Ask a random number of people or a random number of Apple customers, and less than a fraction of a percent will say that the option to install Linux on their MacBook is what they most want from Apple.
More people will probably ask for a handle, or LED flashlight, or how about built-in invoicing software? Should the EU (praised be their names) force Apple to give these customers what they want? Why would their wants be any less important than yours?
>I wish the EU would regulate this kind of stuff.
Regulate what exactly? Bugs? That's what this was...
Hardware documentation.
This wasn't a hardware issue
Isn't it a hardware documentation issue?
Dude, you're talking about beta software. Get a fucking grip.
Honestly this shouldn't be limited to traditional computing devices. Why do I need some hacker to reverse engineer my robot vacuum and then fully disassemble it just to install custom firmware to it? Should be a basic requirement of right to repair so all this smart crap doesn't wind up in a landfill when a company goes out of business or decides to arbitrarily drop support for it.
The EU is probably going to want tight control over users like any other government body. Bring your own software runs counter to that.
I can see the argument when it comes to locked-down mobile devices, but macOS is a general-purpose operating system with no restrictions on software sources that can't be easily disabled. Nearly every program available for Linux (excepting OS-specific stuff like desktop environments) is available for macOS, commercial and free, and there's plenty more that's macOS-only. Asahi is cool, but it's mostly used by enthusiasts - there's very little practical use for it as a macOS alternative. I think that you'd have a hard time convincing regulators that this cause really matters.
In any case, though, Apple agrees with you, and they explicitly built support for non-macOS OSes into the bootloader. This is a bug in the first developer beta of a new release.
>I think that you'd have a hard time convincing regulators that this cause really matters.
"A foreign power could potentially deny access to the OS" sounds like a compelling argument.
foreign or domestic