It's difficult to have an opinion here as I've seen both sides. While compatibility is nice, if you start kicking out reference hardware documentation you instantly open up several additional cans of worms from upstream IP licensing to crappy clone repair parts appearing on the market.

But realistically with Apple you don't know what's going to happen. They could be silent forever. They could suddenly dump a whole pack of documentation out tomorrow. An official position would be nice.

Switching it round though, 99.99% of customers are buying a toaster. I put bread in. It makes toast. I eat toast. Does it make commercial sense to support the 0.01% use case? That's their equivalent model of supporting the iPhone 5's market share for example.

> But realistically with Apple you don't know what's going to happen. They could be silent forever. They could suddenly dump a whole pack of documentation out tomorrow. An official position would be nice.

Apple implementing things like they have here is about as official a position they can make without making commitments to having to respond to requests from developers as to how to do this.

It's similar with their stance to Hackintosh, but more legal.

It was a violation of their terms of service, but they didn't prosecute people that didn't try to make money with it.

It's like saying "we'll leave this tiny window open. Suit yourselves"

> Switching it round though, 99.99% of customers are buying a toaster. I put bread in. It makes toast. I eat toast. Does it make commercial sense to support the 0.01% use case?

Fair enough. I think most toaster manufacturers will at least test what happens when you put a bagel inside, though. If said bagel causes an electrical fire or doesn't toast as well as the previous model did, it doesn't matter if ~1% of users will encounter it; it probably needs to get fixed before it ships.

I think this fully extends to Apple Silicon as well. Apple's "contributions" to Asahi mostly amount to adding a feature that pre-existed on x86 machines, and probably intended for Bootcamp/Windows rather than Linux. Hell, there's compelling evidence that Apple simply uses that functionality to flash testing firmware onto Macbooks, and the Linux compatibility is just a nice side-effect. Much like you said though, with Apple you never know. Until they release an official statement on the matter, it can only be assumed it's a coincidence.

> Apple's "contributions" to Asahi mostly amount to adding a feature that pre-existed on x86 machines

Nope.

Apple tossed out the UEFI used by Intel Macs and replaced it with a system that allows you to control the security settings per partition, so you can have a single machine with full security enabled on your Mac partition while allowing for the installation of an unsigned OS on the same disk.

It's a complete replacement of the boot system that preexisted on x86 machines.

It’s been 18 months on an entirely new platform and a small team of (BRILLIANT) people did such a good job discovering and porting to undocumented hardware that it worked on the M2 hardware essentially before it started shipping.

I don’t think Apple is trying to get in their way.

Also… developing for documented hardware is also an endless treadmill of work as it evolves/new products are released.

It just has much less uncertainty.

I 100% agree it would be awesome if Apple released full documentation. Broadcom too. Probably others.

(All IMHO)

Ah, does not releasing full documentation not count as Apple "trying to get in their way"? Not trying to be snarky, genuinely trying to figure out how folks draw the line, since in my head, keeping documentation private smells like obstructionism.

Have you never been involved in the process of making internal information public? In most companies it's not just a case of whack that shit online, there's a lot of process involved in making sure it is fit for public consumption and nothing that legal, sales, product development, etc. don't want leaked is in there. This kind of overhead only grows with the size of the company and number of interested parties. You then have to justify expending that time and effort, and the ROI of making documentation public is.. not in your favor.

If it's obstructionism it's passively so. They've done nothing to actively obstruct. They've also done nothing to help. When they say they don't support it they're not kidding, they don't just mean capital-S support.

If I had to put a label on their stance, it'd be "chaotic neutral".

Except they have helped, just not with the documentations side: https://news.ycombinator.com/item?id=29591578

That's not helping Asahi. Apple never mentioned the reason behind the change (or even publicly acknowledged Asahi, as far as I'm aware), and non-Marcan sources have speculated that it was added to help Apple run hardware testing firmware. It's equally likely that Apple added this in as an alternate entrypoint for Bootcamp, which wouldn't work on Apple Silicon otherwise. In other words, people are applauding Apple for fixing the problem Apple created: a perfect allegory for developers in the 21st century, if you ask me.

Putting in all the effort to design a system that allows you to install an unsigned OS without it effecting the boot security of the MacOS partition is definitely helping Ashai, NetBSD and any other OS that would like to add support for the hardware going forward.

Also, designing the boot menu so that unsigned OSes can show up as valid choices or be set as the default OS.

As well as the EULA allowing the use of unsigned OSes.

All of those things you listed also existed on x86 Macs, I fail to see how this represents a change in attitude towards supporting Linux users.

>All of those things you listed also existed on x86 Macs

Nope. Security settings on the Intel Macs were per machine just like other PCs.

The system of allowing per partition security settings so the user could install an unsigned OS without it effecting the security when booted into MacOS is new on Apple Silicon Macs.

As the Asahi Wiki puts it:

>From a security perspective, these machines may possibly qualify as the most secure general purpose computers available to the public which support third-party OSes, in terms of resistance to attack by non-owners.

https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...

> non-Marcan sources have speculated that it was added to help Apple run hardware testing firmware

Those sources are wrong. Apple doesn’t need to add or release anything to test their own hardware, they have an in-house Linux that hardware bringup uses.

That makes sense, fair enough, thanks!

> small team of (BRILLIANT) people

I wasn't trying to take anything away from them at all. It's astounding what they're accomplishing but the fact that it's necessary for this situation to exist at all is what I'm mainly commenting about.

Speaking from experience, there is no "full documentation" to release.

> The problem with these 100% vertically integrated stacks is that every hardware release could be completely different and it'll take years to catch up with just that release. In the intervening time more hardware generations were released

>At this point, it's pretty likely that M2 will be at feature parity with M1 with <24h of actual work.

https://twitter.com/marcan42/status/1542957901651685376

M2 is also basically the same chip.

Which makes the scaremongering about it theoretically taking years to add support for a next generation chip sound especially silly.

Well keep in mind that even M1 2+ years since its release is not yet fully supported enough to make it a daily driver with Linux. And it is not exactly a given.

Seems like it’s reaching that point for Linus

>On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It's something I've been waiting for for a _loong_ time, and it's finally reality, thanks to the Asahi team. We've had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.

https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...

> Not that I've used it for any real work, I literally have only been doing test builds and boots and now the actual release tagging.

Linus mostly compiles kernels and merges things and maybe replies to emails using a terminal, which is very different than most non-kernel development folks' idea of daily driveable. There's the whole GPU thing for example.

As a different reminder - Linux never worked really all that well on Apple's x86 hardware in the recent past!

Also as an compare and contrast - Lenovo has a dedicated Linux team to support Linux on standard x86 hardware - https://www.phoronix.com/news/Lenovo-Linux-2022-State - so does Dell. It takes a lot more than oh we will merely make sure other OS is a policy and rest is left to you to figure out OtherOS folks.

The parts are clearly cross-compatible and we’re again faced with what seems like an attempt to block repairs and replacements through software barriers. - https://www.ifixit.com/News/62684/were-pretty-sure-we-just-t...

That's a pretty misleading quote out of context (and to be honest, it's not great even with context - there's no real grounds for iFixit to make that assertion) - Apple made changes at the hardware & software level to how the touchpad & keyboard work - offloading more functionality to the main SoC, changing the comms protocol, etc.

There's no evidence at all that it is an attempt to block repairs with older hardware.

edit: if you think about it, it's even more awkward for Apple - now they have to have two sets of parts inventory for repairs, etc. It doesn't really make sense to do that unless you have a technical justification.

Does Apple have less reason to lock things down now? Being fully vertically integrated, with possibly the best mobile hardware in town, do they care that people will buy their hardware just to run Linux?

Help is good. But getting out of the way sounds like a good consolation prize.

Apple has never locked down a Mac.

The EULA on the Apple Silicon Macs allows you to run another OS.

Apple put in a large amount of work to design a system that applies security settings per partition instead of per machine, so that installing an unsigned custom OS doesn't require you to turn off "Secure Boot" for the whole machine.

Wait what? Did Intel macs have EULAs that go into what OSes you're allowed to install on the hardware you "own"? It blows my mind that we'd need Apple's permission, unless you're just licensing/renting your mac

When I used to have a personal macbook that I got to keep after an old internship, I even was able to find instructions online that helped me split the SSD between Linux and MacOS, with filevault still working on the MacOS partition and full disk encryption through LUKS like normal on Linux. It did require temporarily turning off filevault and SIP while doing the partitioning (and when setting the linux partition to boot by default, although that's not required by any means), but once the setup is done, it works fine after turning it back on.

> Requiring that a community exist that is willing to spend many years of collective time reverse engineering your products when you could have just released documentation is still a massive middle finger to everyone.

If you were handling this situation for Apple, how would you handle customer support for non-apple OSes?

I mean I wouldn't, but documentation would be appreciated. I feel like this is a common error in reasoning (not accusing you, honestly not accusing Apple, mostly accusing the people who would move the goalposts if Apple really did release documentation) where you identify one action as clearly good, and another action as possibly bad, and then not do the former for fear that you'll then choose to do the latter.

It's not quite slippery slope, because at least under slippery slope it's other people who are the concern. Apple could just choose to do the easy stuff and not the hard stuff! They could release documentation with no promise of support! You see the same argument with open sourcing things; "Oh well then I'd have to support it". Just literally choose to let people see the code and also choose not to give them support. Who exactly is gonna twist your arm?

M2 is already out and marcan got it up and running in, like, a few hours. Apple actually has a fair bit of engineering discipline and doesn't shuffle registers around on a whim. This isn't exactly Intel levels of "lol let me just run MS-DOS on my brand-new gaming rig" but it's way better than most ARM vendors.

If Qualcomm or Nvidia had half the compatibility discipline Apple had, third-party images for Android hardware would absolutely be a thing.

Agree with the sentiment of siblings. Apple writing public documentation would have a cost (server maintenance, full time technical writers, support for devs etc), and how would they justify it? Their mantra has always been a single unit formed by their hardware AND software. They are nice enough to allow you to play with the hardware and keep the security features, I don't think you should expect much more.

Apple has had lacking documentation for more than a decade now. They haven’t invested enough in that area, and I presume they are incapable of cleaning up their internal documents for external use.