Comment by goranmoomin
4 years ago
Everyone is like how having Asahi makes Apple more profit, so it makes sense in a business sense, e.g... but am I the only person thinking that this is probably just one or two core kernel engineers just feeling good someday and decided to provide this to Asahi? I don't think the high-level people would really know that these changes even existed...
I agree that this is mostly a small number of engineers (with approval) being helpful. This has almost no bearing on Apple profit. The number of people who want to run Linux on an Apple Mac is very small compared to their other markets. The only tangible benefit to the company is that this may add a bit of goodwill and slightly reduce the volume of the vocal detractors.
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.
> I agree that this is mostly a small number of engineers (with approval) being helpful.
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.
The fact that you can boot the M1 from a different OS (but you still need the internal SSD even if you boot from an external disk) is a corporate decision.
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.
3 replies →
Note there's also macOS-related reasons to use the different modes:
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.
1 reply →
Oh cool, I wasn't aware of that. I like that option a lot. It's nice to have access to both a walled garden and an open one.
> It probably wasn't a quick hack that a couple of guys stuck in when nobody was looking.
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
I don't disagree with what you're saying, but focusing on the number of people that want to run Linux on a Mac and the tangible short-term benefits misses the larger dynamics that could play out over time.
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.
Maybe they want to ship Apple Silicon to server vendors?
Yep, there seems to be this tendency to evaluate all the actions of all the people inside a company as a single coherent whole, expecting there to be single coherent thread running through it all. It's almost like people think of the company as a single person - a kind of anthropomorphization maybe. Companies may strive for alignment, but they're not the Borg, and they certainly don't have the capacity to micromanage every single decision for every single employee.
It's interesting how American/Canadian English uses the singular for groups of people, while British English uses the plural:
"Apple helps Asahi Linux" (American).
"Apple help Asahi Linux" (British), as if there's a "people" after Apple.
As someone who has worked as a sub (copy-editor) in the UK for many years in the past I cannot begin to describe exactly how completely incorrect this is.
5 replies →
That seems odd to me (as an American) because Apple is not plural, and often times when it is a group of people by identity you do use the plural for them (eg Americans help Asahi Linux). Would British folks say “England help Asahi Linux” as well?
2 replies →
Another American here. I never knew this. How common is this? Have I just assumed it’s a typo every time I see it? Or has (have?) the British media just become more Americanized like most places?
2 replies →
I don't think that's the case; British English would say "X help Y" when X is a collective noun referring explicitly to a group of people, eg a football team ("Manchester United have scored"), or a band ("Radiohead are playing a concert today"). This means that "Spain (the country) is ..." but "Spain (the football team) are ...".
See here for details: https://editorsmanual.com/articles/collective-nouns-singular...
1 reply →
It's not that American English uses singular for groups of people. It's that American English sees Apple as a singular corporate entity.
British English peers past the corporate veil to see the singular corporation as it's underlying people.
4 replies →
Is that because whatever company we work for ourselves, those in charge tend to push that narrative so much?
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.
Maybe? Americans also tend to be individualistic (often to a fault, many would say)so I'm not sure there's a cultural significance at work here.
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."
I didn't work on the OS team, but when I worked at Apple, if I had snuck in an altruistic change without direct order/approval, I would be in trouble. I suspect there's a good chance that the higher-ups are aware of this.
This may have security implications, I highly doubt they would be authorized to make such a change without consulting anyone.
The shift to moving the Mach-O parsing from iBoot to kmutil has positive security implications. Adding a raw input option on top of that has zero additional security implications. It's a strict subset of the attack surface.
I believe parent is not talking about the security implications of the contributions themselves, but the security implications of the act of making contributions as an Apple employee. And it’s a reasonable assumption; from my (not many) interactions with Apple employees in OSS world, they are generally very careful about doing this sort of things, and I would be very very surprised if not at least a few managers know about this beforehand.
2 replies →
There is no way that two random kernel engineers pushed a feature that allows booting unsigned kernels on Apple hardware (I'm assuming that's what raw image is?). I don't know how _high_ up it goes but I am very certain it was not some low-level skunkworks thing.
> I'm assuming that's what raw image is?
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.
Thanks for the correction. Glad to see these steps being taken by Apple.
Well I think this falls right into the anti-competitive argument. With the option of booting unsigned code the platform is available for anyone. Microsoft did sign boot loaders so linux can boot, there would have been some kind of fallout if they had not. So the booting of unsigned Mach-O sunds like a minimal action to not let it become a public issue for Apple.
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.
Why would it become a public issue for Apple? You're going to have a REAL tough time getting the government to intervene because you can't run linux on a macbook. You have literally thousands of alternatives.
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.
Mac’s have a 16% market share. I don’t think Apple is concerned about antitrust in this part of their business.
It's not like they're huge contributors to anything open source. I have to agree. This is probably an engineer or two. They may even have personal reasons for wanting it to work.
They're not that different people from the rest of us, so why wouldn't some of them want to run Linux themselves on those machines? MacOS isn't that great.
I agree, this seems likely to be a couple folks at Apple trying to be helpful rather than a real policy. If Apple were serious about helping open source efforts they could, for example, release the documentation for their different peripherals and ISA extensions.
> I don't think the high-level people would really know that these changes even existed...
if anyone on the outside knows, then Federighi (sp?) and insiders know and approved publishing with visibility?
Apple Engineers don't even come on a podcast to discuss stuff without thinking and asking internally if it's ok.