Apple Helps Asahi Linux
twitter.com
twitter.com
You're assuming wrong. Booting unsigned kernels on Apple hardware has been possible since January. This just makes it slightly less annoying since you don't need to build a Mach-O binary to do it, and more future-proof since it decouples it from Apple's binary format which they can change the requirements for at any time (as they did this time). It means I don't have to go off and reverse engineer what the new requirements are, I can just stop using Mach-Os and know the raw option will never break (assuming it continues to exist), since there is nothing to break with a raw file.
Apple's machines are designed as an end-to-end ecosystem that suits their needs, and that they can change at any time - open, but without stability guarantees. This feature is effectively an acknowledgement that people using these machines outside of their ecosystem exist, and might want some stability guarantees.
"Apple helps Asahi Linux" (American).
"Apple help Asahi Linux" (British), as if there's a "people" after Apple.
However, the word Americans is not a group of people in the same sense that USA, England, Apple, or family is. Its kind of like the distinction between people and persons.
Edit: the term for words like family is "collective noun". More at https://blog.harwardcommunications.com/2017/02/07/the-family...
> Labour [singular] takes comfort partly from the fact it expended little effort or money on the seat, allowing the Lib Dems [plural] to declare themselves in the best position to challenge the Tories.
But an American publication would probably write the same, because the name Lib Dems is itself pluralized.
British English peers past the corporate veil to see the singular corporation as it's underlying people.
Brits would be more likely to say “Led Zeppelin are on stage”, while Americans would prefer “Led Zeppelin is on stage”, and the reason is the disagreement between whether Led Zeppelin is singular (one band) or plural (4 people constituting the band.)
See here for details: https://editorsmanual.com/articles/collective-nouns-singular...
We get constantly bombarded by our own employers with messages of unity and vision statements and the business plan and the message etcetera. So even when we pause and think about our own experiences and we realize how many varied voices and agendas there are within, we’re conditioned when referring to a brand employer like Apple to reduce them to a single point of view.
we’re conditioned when referring to a brand employer
like Apple to reduce them to a single point of view.
It's probably informative that British English tends to refer to most (all?) collective nouns this way. It's not some corporation-specific thing.
Sports teams are the most obvious example - a Brit would say "Team A have defeated Team B" rather than "Team A has defeated Team B."
As others have pointed out, it may also help if they are moving to add back bootcamp support for Windows (on ARM).
Apple has added better support for virtualization at the OS level in recent years and that handles the needs of most devs.
The M1 Macs have their security settings applied per partition instead of per computer.
If you set the bootloader to "permissive security policy", you can boot from a Linux partition without effecting the security of the system when you boot from the MacOS partition.
This is a big change over the way things have previously worked on iOS (where there is no option to unlock the bootloader) or the Mac. It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking.
Reduced security mode is needed to boot into outdated macOS installs (specifically, I believe this is "outdated, insecure, at install-time"), along with loading kernel extensions (which aren't supported in full security mode on Apple Silicon).
Permissive security mode is needed to boot into macOS with a custom XNU kernel.
But yes, this is a significant change to iOS devices, but not to older macOS devices.
Previously the Macs had their security settings applied per computer, not per partition.
The fact that someone decided to provide support for a raw image instead of a Mach-O file could very well be the work of someone ar a much lower level.
Likely there is a very small bit of bootstrap code stuffed into a ROM somewhere, and the only thing that bootstrap code enables it to read from some protected part of the onboard SSD, which then gives you the next round of bootstrap enabling you to read from other devices (e.g. all the code needed to power up and use the hardware needed to get to an external drive, and the code to read the partitions on said drive).
Someone made the decision that it would be better to use the bit of internal SSD (since it would "always" be there), that could be changed later, rather than hard-code this into comparatively expensive silicon. Unless your internal drive goes bad, it is a pretty good compromise. I seriously doubt that anyone in marketing cared about this.
The SecureROM boots iBoot1 from NOR flash, then that has the SSD driver code. It would certainly be possible to add support for external storage, as long as it still fits in NOR. But I doubt they will.
My take is the company deliberated about this trade-off quite explicitly at some length and decided the Mac serves the world in its current capacity as a "computer" (i.e. the truck in the truck vs car analogy) and that they do not wish to limit the capabilities of the existing Mac that people love in any shape or form by moving to ARM, which was highly speculated and ripe for potential backlash. They probably decided the Mac would be an "open" system to some degree (at least as open as it already was) and iOS would be the closed mass market computing device optimizing for security and dependable end-to-end experience.
I mean, that's not what the parent comment said:
> I agree that this is mostly a small number of engineers (with approval) being helpful.
Here's some more details from someone who actually worked on this: https://twitter.com/XenoKovah/status/1339914714055368704
The bigger opportunity is expanding the footprint and flexibility of Apple Silicon in general. As a developer the new MacBook Pros performance characteristics were too juicy to ignore, the main pain points are virtualization and architecture shift. I'm not knowledgeable enough about the low level details to have a fully formed idea of impact of these pain points yet—maybe Apple Silicon and ARM support are equivalent in practice when it comes to development/deployment—but it certainly makes me feel more comfortable paying the Apple premium the more diverse and open the supported use cases are.
The addition of raw mode sounds like a stable abi for booting linux. The Asahi developers have found "stuff" with the hardware. Just that feedback will be of great value to the continued development of the Apple SoCs. So my guess is that the raw mode is a gift with the expectation to be able to see how the Linux folks solves other issues.
And outside of government intervention, the response from the general public will be: who cares? None of them want to or care to run Linux on a macbook. Heck even within the HN community I'm willing to bet the number of folks who run linux as a daily driver desktop on a macbook is a rounding error.
if anyone on the outside knows, then Federighi (sp?) and insiders know and approved publishing with visibility?
>we're up to a 94% pass rate for dEQP-GLES2
By not being official, they can probably do more internally.
People don't often think about that, but in some cases it's very true.
Deeds, not words.
- it means they've made a public commitment to a project, and suddenly will get bombarded by other projects, making them less willing to engage again
- any failure of the project to run well will also be a reflection of the company, even if it's outside their control.
- it can be seen as an endorsement of a single project, when multiple ones might benefit. Also if that one project becomes problematic it is hard to detangle.
- the commitment to it would make it difficult to move in a different, better direction if needed in the future
Craig Federighi (their SVP of software) mentioned that support for other OSs is an explicit goal of their boot setup in interviews.
https://www.youtube.com/watch?v=Hg9F1Qjv3iU&t=3785s
In this one, Craig Federighi says “We’re not direct booting an alternate operating system. Purely virtualization is the route. These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.”
I understand this is very useful to the stability and future of the project, but we should expect more than the bare minimum from big companies in matters like this. Not being actively harmful != helping.
Personally, I wouldn't consider buying a Macbook unless I knew I could run Linux on it after it EOL. My oldest laptop is 14+ years old and is still useful because I run Linux on it. A 2022 Macbook should make a very nice ssh Linux client in 2037.
Nope. The number of people who would buy an M1 Mac solely if they can run Linux on it is tiny. Incredibly so. Apple sells over 20 million of these things a year, they’re not looking at a few thousand people who want native asahi Linux as a product center.
Exactly. One argument that I can see it that Apple want to be able to say: When we're no longer supporting old M1 Macs, you can run Linux, or sell it to a Linux user, rather than throwing it out. Branding it as an environmental benefit.
It's a bit far fetch though.
The bare minimum would have been to not do that.
https://keith.github.io/xcode-man-pages/kmutil.8.html
I recall an Apple developer saying that no one internally believed it would get any traction, but they did it anyway.
That is an assertion with no evidence to support it, and lots to do the opposite (starting with the fact that this appeared a year after the initial M1 public avail).
> They test their hardware on Linux, if it doesn't work properly then they can potentially lose money.
That doesn't make any sense, apple does not support Linux on their machine (as demonstrated by Asahi having been working on that for more than a year now).
And even if they did "test their hardware on linux", that would have no relevance to the issue and change: Apple can build mach-o linux kernel files in whatever fashion they need, that is quite literally what Asahi did. TFA states that unambiguously and they're the Asahi project lead, they'd know.
Probably I'm too cynical (or maybe realistic?) because it's not hard to imagine situation in the future where thousands of work hours poured into project like this is easily and effortlessly decimated by corporation execs decision.
Or the defaults(1) command, or how networking config works (it's just plain BSD configs with a GUI on top).
Apple isn't against tinkering or customization, they just don't document or guarantee it.
--
[0] Simon Willison has neat demos with it https://simonwillison.net/2020/May/21/dogsheep-photos/
Following that path is how companies lose their way.
They've learned enough from using azure, gcp and aws. Their multi-billion contract with aws will end soon..
They will offer a fast energy efficient public cloud. First the xcode cloud, then their own hosting, and later it'll become public
I strongly believe they will, and that it's a natural progression.
Mac hardware is extremely popular with developers. M1 on Macbooks has lead to ARM platform Docker containers, which in turn will lead to a much increased demand for ARM platform Docker hosting. Meanwhile, ARM is much more power efficient than x86, and who has by far the best ARM CPUs for the foreseeable future? Apple.
If Apple wanted to help push a server or cloud product, do you think AWS would be racking retail Mac Minis?
This has informal geek cred motivation written all over it. More of a good-will measure than anything else. If this was an explicit market/new product motivation, any assistance would look very different and be more formal.
Or maybe as a preparation for Boot Camp for ARM64 Windows? Rumors are that Qualcomm's exclusivity deal is soon over.
It could be that they work on it internally and naturally want to keep it a secret for as long as possible. However, in that case, they would absolutely also want the community to advance "independently" so that Linux software on Apple Silicon has most of the practical issues ironed out by the time Apple is ready to announce their stuff. Think of it as having a free alpha/beta testing even before your product is publicly announced. A pure win-win.
This, at least, is how I would do it if I was pulling the strings at Apple.
If you want a rack of M1 servers, buy a couple of Mac Minis. But if you want them to also run Linux, that’s going to be a bit more difficult. macOS is compatible enough for many (most? all?) *nix server software, so why would Apple need to have a separate product?
Thank you, I had not seen that before:)
This[1] is exactly what I claimed would happen when ARM Macs were announced and people bemoaned lack of support for booting other OSes. I’m glad to see it.
1: specifically that Apple would not prioritize booting other OSes, but that they’d let the community drive the effort, and eventually embrace it.
Formally helping this project creates a potential burden on the organization that they do not want to have.
Interesting, since Microsoft is also putting so much work into Linux interoperability these days. Perhaps these are the seeds of convergence. Or at least Linux being the common denominator OS on all machines.
Does the latest macOS provide a firmware update to M1 which is what’s making it easier to install Asahi?
In macOS 12.1, Apple engineers changed the format of the kernel image, which broke the Asahi install process. However, they also added a “raw image mode” which allows the bootloader to load things that don’t look like macOS kernels — it’s an officially-supported boot flow for the Asahi project to use going forwards without fear of macOS updates breaking it again. (Plus, it makes that linker script much simpler [2]).
[1]: https://github.com/AsahiLinux/m1n1/blob/84acf60c24b8c9e28e60... [2]: https://github.com/AsahiLinux/m1n1/blob/92aca22119a0afda9799...
Assuming for the sake of argument that they did, what you're left with is what you had before: having to build the process around format changes to Apple's supported process. The Asahi devs went into this project knowing that they were working around Apple's internal needs, and having to revert back to their original solution and its tradeoffs at some undefined future point isn't an existential threat to the project.
> Seriously, I can't think of a single reason why they'd add that for themselves. They build real Mach-Os with their own process. They have no use for raw images.
> They are saying "hey, use this, it's easier and we won't break it in the future". This is for Asahi.
Previously, the bootloader only supported loading macOS kernels. Asahi had to work around this by creating a second-stage bootloader that looked like a macOS kernel. Now, Apple has added official support for booting things other than macOS kernels -- which is not something Apple needs to do internally.
Remember, Apple spent a LOT of engineering effort developing a boot policy system that allows users to run unsigned operating systems on an M1. This is not something that came about by accident; the M1 uses an iPhone-based secure boot chain that's not anything like the UEFI-based bootloaders on x86 Macs. The Apple engineers who designed this system often hang out in marcan's livestreams and answer questions.
If Apple didn't want people to run alternative operating systems on Macs, the M1 would have been the perfect excuse to block them for good. In fact, it would have been easier to lock down the bootloader -- just use the iPhone bootloader as-is, instead of developing all the extra features needed to boot unsigned kernels. The sheer amount of effort they spent on the boot policy system indicates that they plan to keep it around for a long time.
Now, people are using Apple's custom-operating-system support to run custom operating systems, as intended. Apple engineers realized upcoming changes to macOS would break their customers' officially-supported workflows, and so they added a better workflow that won't break again in the future.
It's quite likely this isn't specifically for Asahi Linux. Some BSDs are also working on booting on this, which might permit Apple some flexibility in future products using Apple Silicon (Apple's Time Capsules, say, have apparently run NetBSD as opposed to an iOS derivative).
Apple would also likely be welcoming to Windows for Arm running natively on macOS. While Apple wouldn't probably be justified in coughing up the costs for writing complicated drivers - notably graphics drivers - to make Windows run on it, they have incentives to make someone else doing that as easy as possible. Macs running Windows just sells them some percentage more Macs. As does Macs running Linux/BSD most likely, but that percentage is smaller.
Not saying it's a bad thing, just pointing out the obvious for those who're not seeing it.Apple is well-aware of the state their operating system('s') and ecosystem is, especially to the tech-savy and skeptics around privacy and the shitty general trend that computing follows. In the case that people magically start growing a conscience or care more about these things, they're prepared to switch gears or stop "thinking differently".
Arm macs are a nice piece of HW(with the exception of non-upgradable memory due to SoC but it's a understandable compromise given the gained performance of such glued design-choice), however it's a shame we need to pray the Gods for decent ports/development of Linux distributions to make them usable.
Seriously. It's for us.
It's not because they believe in open source and free software, it's more that they realized they can coexist with and even benefit from helping such projects. It's a beneficial means to a selfish end, but it's better than the old Microsoft who just wanted to destroy anything related to Linux and free software out of pure spite.
Yeah. Basically they're smarter this time and found a way to remove the reason to install a Linux Distro on any desktop by just 'extending' WSL2 and adding optimized NVIDIA drivers that are designed only for WSL2.
Which means Windows is the best Linux distro then. Why bother with the Linux Desktop since that has failed anyway?
And regarding Microsoft, while I certainly embrace them being more open than before, VS Code still has proprietary bits, and you'll need to run your own extension store if you don't want to use those (which the VSCodium project does, I think). Of course, that's not even mentioning the forced telemetry in Windows...
VSCodium has just disabled that Microsoft store by default. You can enable it and use all the extensions normally, without proprietary bits.
Apple has literally written documents about why they think sideloading is a bad idea.
As it turns out, doing things in the browser is more convenient than apps anyway (given that it's a tablet), and I underestimated the restrictiveness of the OS, but those are the things that are hard to glean from reviews. It's my first tablet in a decade, so you'll have to forgive me for not having any prior knowledge on these things.
This may not be something that is made clear in reviews, but it’s hard to see how someone could read HN and not see hundreds of comments about this.
What surprises me is that a regular visitor to HN has not seen this opinion expressed. It also seems weird that they wouldn’t know that sideloading was a problem given how many front page stories have either attacked Apple over this policy or defended it.
I have sympathy for anyone who buys something they don’t end up liking. I’m just very surprised that this particular fact was somehow not known to an HN commenter.
Perhaps we misunderstand each other. Of course I have read that sideloading specifically is more difficult on iPadOS; this was not an unknown fact to me. However, that wasn't the sole factor in my choice of device (and if openness was my #1 priority, I could've just asked for (it was a gift) a PineTab).
The usability of the device for day-to-day tasks is the most important, and since I use a lot of apps on my phone, I mistakenly thought that this would also be an important factor w.r.t. usability when it comes to tablets. Therefore, when I read in reviews that the app ecosystem was much worse on other tablet OSes, that pushed me towards iPadOS. Again, privacy was also a factor (when compared to Android).
In 2021, any OS choice is ultimately a balance between usability, privacy and openness. If your last experience with a device class was a decade ago, it can be difficult to balance those factors.
(Now, if the mobile landscape resembled the PC landscape a bit more, trying different OSes wouldn't be so cumbersome. But that's a whole other can of worms...)