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.
I disagree with your assertion that the requirement for the internal SSD was a marketing decision (your word was "corporate", but that could mean anything). I think that it was probably a technical decision.
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.
Support for external disks massively increases the attack surface of the security-sensitive iBoot bootloader, and anything messing with USB (nevermind Thunderbolt) is almost guaranteed to have exploitable attack surface. This was absolutely a technical decision. iBoot is a lot simpler not supporting external storage.
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.
(not the GP) I think you are attacking the strawman here, as your own post admits, by interpreting "corporate" as exclusively "marketing" and not including technical folks in it. I agree with you the decision is also partially driven by technical folks at the company, but given macOS on ARM is really closer to iOS, the natural course of action would have been to simply clone the iOS model of secure boot, not to rethink it. That observation alone almost certainly implies it has been given explicit thought at relatively senior levels of the engineering hierarchy, at the very least.
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.
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.
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.
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.
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.
Not really. It's absolutely normal to see, for example, sports clubs and teams used as plural noun in the UK press; hence by extension it cann be used for any org. I know because it's a big gotcha for us Europeans, who tend to use the singular there.
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?
Yes, I believe that would be correct. Apple is plural in the sense that it is made up of multiple people acting in unison. Same as "My family are visiting over Christmas."
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.
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?
I am Canadian myself and generally follow the American style, but I believe it is very common, though not universal. Scanning The Guardian, they (!) seem to follow the American style, though this paragraph popped out at me where they use both:
> 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.
"Labour" is a party name, and it is singular. "Liberal Democrats" is a party name, and it is plural. The verb is agreeing with the number of the noun, just as is usual in English.
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 ...".
American English generally uses singular for collective nouns. British English generally uses plural. There are exceptions (such as if the name itself is pluralised), but that's the general rule. Whether its "peering past the corporate veil" or not is neither here nor there, as they treat all collective nouns this way.
Sure, but there is some disagreement across the pond on which nouns are singular.
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.)
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.
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.
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.
Yes, sorry, the wording I used was misleading. What I meant by “contribution” is in a broad sense “something that helps”, not actual OSS code contributions.
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.
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.
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.
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 was really hoping to see Apple acknowledging that they were helping rather than assuming based on code changes that make it seem like they are. However, happy to see the direction this is going. I’m grateful for the work of both sides.
A company saying they're helping has lots of side effects people don't think about:
- 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
They don't need to endorse Asahi to endorse the use of alternative OS on ARM Macs, which wouldn't have any of those downsides. The first Intel Macs were great machines to run Linux on. Later machines had too many compatibility issues. From that experience I'll steer away from Macs as I have no interest in OSX and don't trust them to not break Linux. If they publicly commited to alternative OS friendliness that would go a very long way for me.
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.”
Allowing booting other OSs is different than actually supporting those efforts with documentation for example. The problem with Intel Macs is not being able to boot another kernel it's all the device support that's now gone.
The fully documented BootPolicy system, all new to M1 Macs and not found on iOS devices, explicitly supports running your own kernel on these devices. It’s also supported by new tools for implementing boot code. Apple has clearly devoted a lot of resources to this, as the Asahi Linux team have repeatedly pointed out.
If your comparison is iOS devices then sure, being allowed to boot your own kernel is a sign of progress. It's a very low bar even when compared to Intel Macs though, not to mention competing laptops. But this is definitely going much better than I anticipated. They've gotten quite far in not too much time. I'm definitely hopeful Apple laptops will again become an interesting option.
It's different with Apple Silicon because their hardware is more differentiated; meaning it might be more interesting for them to see non-macOS usage for it.
"Microsoft loves open source, so please ignore the way we are stripping hot reload out of .Net 6 to force you to buy Visual Studio instead" would be an improvement?
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.
I agree, and that's exactly what they had done before now! I am glad they've done this and think it's a good thing all round, but it would be nice for the expectations to shift and the standards we hold companies to be higher where a situation where they allow you to install your own operating system without jumping through hoops is viewed as the norm as opposed to a benevolent action.
It's a feature they do need though...? They test their hardware on Linux, if it doesn't work properly then they can potentially lose money. This is a random internal change that just so happened to align with the Asahi project. If they were trying to help, they'd let us know. It strikes me as desperation to call this a tacitly helpful move on their behalf.
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.
I'm seriously admiring spirit of people working on Asahi Linux project. In my eyes Apple, it's hardware, software, whole ecosystem and philosophy is openly hostile towards any tinkering, customization, modifications - kind of antithesis of open source/linux.
Yet another angle which would be a problem for me is about putting personal non-paid time towards increasing value of one of the wealthiest corporations on the globe.
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.
Check out https://libimobiledevice.org ; using it iOS will provide access to your Photos.app's SQLite database, including machine learning tags and other metadata[0].
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.
The Asahi Linux project is basically free labor that makes the M1 Macs more appealing to consumers. Perhaps this help is profitable to capture the Linux crowd?
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.
> The Asahi Linux project is basically free labor that makes the M1 Macs more appealing to consumers.
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.
To validate the point if I'll ever buy something Apple it would be a Mac to run Linux on, but I don't see why I should pay an Apple premium and throw away many of the reasons to pay for it. The Mn processor of the future should be so much faster than anything else (say x10) to leave me no choice. I doubt it will ever happen.
> The number of people who would buy an M1 Mac solely if they can run Linux on it is tiny.
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.
Pretty sure Apple's answer to environmental issues is recycling, which to be fair they're good at. (...And also to be fair, which is quite possibly strictly inferior to keeping the same hardware going indefinitely)
I agree about the "consumers" angle, but I don't think it's entirely crazy to think that unlocking Linux on Apple Silicon will eventually have a non-negligible impact on Apple's bottom line. Think Linux on PS3.
It's also one of the best high-performance ARM machines you can currently buy (unless you go for insanely expensive exotic servers). I consider buying one just to have a low power server.
Actually running server Linux on Mac Mini for some workloads might be very useful and economical thing to do. I wouldn't be surprised to find out many companies buying those babies for their internal needs. It's like HP Microserver.
Asahi Linux is really interesting to me. A distro that only has to care about a very small number of hardware configurations could be great. I could see it becoming the number one desktop Linux very quickly if they succeed.
Engineering goodwill is probably limited by legal / marketing departments. To do more or provide documentation would probably amount to a potential liability with little added benefit to the bottom line.
The sad faсt is that given Apple' track record even not interfering might be considered by some as help, let alone adding specific features for people who reverse engineer their hardware.
Considering that it's very possible for the bar to go into the floor (Apple actively frustrating the project, as it may not be in their interest), this is pretty huge.
Do you really think that Apple couldn’t port Linux to an M1 chip without outside help? If Apple wanted a server product, they wouldn’t need to rely on outside volunteers and they would be more actively helping. Apple used to make servers, and hardware wise, they were great. Software wise, it was more of a mixed bag.
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.
> Do you really think that Apple couldn’t port Linux to an M1 chip without outside help?
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.
I think you answered your own question they had server hardware with bad software , with community and ecosystem enablement they could get into it . Why they can’t release a server rack with m1 macs ??
Because the server business has lower margins than they’d like? Trying to sell Mac laptops vs Windows laptops is very different than selling ARM servers vs x86 servers (all running Linux). The margins and support costs would be very high for not very many unit sales. And I doubt they would want to sell chips to someone like Supermicro for them to integrate into servers. I can’t imagine Apple trying to sell to OEMs and reducing their own relative fab capacity to sell chips to someone else.
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?
Yup.. Apple needs to grow somewhere. Cars? Maybe in terms of software.. The real margin currently is in cloud hosting. Even more than in appstore fees.
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
Apple currently uses commodity PC hardware, from vendors including HP, and Linux as their standard data centre platform. I suppose it's possible they might start experimenting with Apple silicon servers in their data centres, but I doubt it mainly for supply reasons. They need all the 5nm TSMC fab capacity they can get for their consumer products. There's no way there's enough spare capacity to start diverting significant numbers of these chips into their data centres. Maybe one day.
But that's more of a short term blocker, isn't it? Fab capacity shouldn't be a roadblock to pursuing it long term. I could definitely see a desire to take all of the security and efficiency features and use them in the datacenter. E.g. it seems a bit silly that my Mac is encrypted with special hardware etc, but as soon as I sync my data to iCloud that security disappears.
> I suppose it's possible they might start experimenting with Apple silicon servers in their data centres, but I doubt it mainly for supply reasons.
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.
With their super low-power/high-perf chip architecture, this actually makes a lot of sense. I don't think we'd see anything for a really long time, but Apple actually needs to expand into new verticals if they want to continue providing value for the shareholders.
I think if Apple was seriously eyeing a server market, Linux would not be the target OS. Apple already relies on quiet a bit from the BSD sphere, I think it would be more likely they have an internal port of FreeBSD or NetBSD. The advantage here is, it would already share some common traits with MacOS and because of licensing, Apple can rebrand it and make modifications without opening the source. Apple has done this before as their Apple AirPorts way back when ran a version of NetBSD.
Some context: "Asahi Linux is a project and community with the goal of porting Linux to Apple Silicon Macs, starting with the 2020 M1 Mac Mini, MacBook Air, and MacBook Pro."
Now, Godspeed to get GPU cores working in Linux!! If we can get a usable Linux distribution working in Apple Silicon without too many compromises, the new hardware would make a heck of a laptop.
Basically Apple's equivalent to ELF. I personally think the multi-architecture support via fat binaries is really neat and I kinda wish Linux adopted the format so we could use one binary for multiple architectures.
I don't like being cynical like this, but Linux can't even sort itself even on a single architecture: glibc (with the whole versioned symbol mess), musl variants, and so on, before we even consider shared libraries and package managers. Despite all the hard work of so many people, if you aren't running Ubuntu on x86-64, you will very quickly run into real problems running any kind of third-party software.
It can be difficult depending on your ecosystem, but often you can; when I said I'd like multi-arch fat binaries I was specifically thinking of Packer (and most Hashicorp products, actually), which distributes as a nice static binary per architecture right now. Also musl is quite friendly to static linking.
FatELF exists, though not widely used, and would make more sense than adopting Mach-O, which has worse tooling than ELF. Because of tooling, it'd be preferable for Apple to switch from Mach-O to ELF in fact (though they won't do so, because that would require a lot of work and Mach-O is working fine for them).
> And people said they wouldn't help. This is intended for us.
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.
Surely Apple can see the value in having devs buying and using its machines... Why not contribute to this project in an even more substantive manner? Share documentation and donate money, it would be a great feel good story that harkens back to Apple's pirate roots.
I can only guess ... and my guess is that Apple likes this project and would like to see it succeed but to formally help it creates a situation that in the future could be problematic for them. Imagine their team that builds the MacBook wants to make some change that would bring some big improvement to the platform but it breaks projects like this.
Formally helping this project creates a potential burden on the organization that they do not want to have.
Maybe Apple is headed toward Bootcamp for Linux, since Bootcamp for Windows doesn't exist for the M1.
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.
The changes are in macOS’s bootloader. Previously, the bootloader was only designed to load a macOS kernel executable, which was stored on disk as a Mach object file with some particular constraints. The Asahi project had to use a rather ugly linker script to generate an executable that “looks like like” a macOS kernel but is actually a first-stage Linux bootloader [1].
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]).
Ok, but nothing stops them from removing it. It might allow for a raw image to boot in 12.1, but there are no guarantees it won't go away in 12.2. Why is there no concern about that?
Because it isn't a new problem? Apple could have locked out Asahi at any time, but have shown no inclination of doing so. There's no reason for them to build a feature that facilitates this specific use case and then remove it in a future version.
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.
It is a huge assumption that Apple is explicitly doing anything for the benefit of Asahi Linux. Apple likely has their own reasons for doing whatever they are doing.
> 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.
Apple really has no business getting in the way of this - it would just hurt them on a general purpose computing platform like Macs are.
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.
Yes... "helps" as in 'help Asahi grow sales for Apple laptops'.
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.
Heartening to see Apple reaching out to Asahi and providing them with a stable kernel image format. This is proof that Apple cares about open source on the M1
I don’t believe this for a second. That would have been a completely daft thing for them to do (not that corporations can’t be daft).
I think the stagnation perceived with the Mac was a combination of distraction (focussed on mobile), lack of general invasion on desktop in the market, Intels recent problems, and waiting. I believe they were waiting for their silicone to get the point that they could do a proper coordinated refresh.
Yeah Apple tried to kill the Mac… and then popped out with the biggest jump in laptop chips in a decade. That chip effort, along with everything that supports it in the new M1 machines was many years in the making.
As well as Ive having way too much influence and not grokking what the mac is actually used for, trying to turn it into an aspirational luxury product.
Developing in house silicon over around 10 years that craps all-over competitors is 'begrudgingly' updating?
The mac is the pinnacle of their product line up - it may not be their biggest priority or largest profit center... but its clear they consider it as a pro level device and treat it very differently from the iOS based products.
The M1 is quite clearly a derivative of designs developed for and deployed first in iOS devices. It's great, really. But other than die size and instance count, it's just a "phone chip". It's an iPhone with more cores/cache/etc...
The upthread point wasn't that the "M1" wasn't good as a laptop chip (it is!), it was that the "Macintosh" product line is clearly evolving in a direction where it's a derived product from the main revenue-producing lines.
You're applying the thought of 'they use it on iOS so it's the mac thats shifting' way too hard on Apple just choosing a new architecture that suits their products best...
If the performance hadn't been what it is then I'd agree. But I'd say the vast majority of hardcore mac users are hyped about the new devices. That's a sign that they're keeping the mac as the mac.
I can't wait to move from my intel to a M* in the next couple of years when software support is fully there for audio stuff.
> Developing in house silicon over around 10 years that craps all-over competitors is 'begrudgingly' updating?
...developing in-house silicon that has architecture parity with your iPad an iPhone. They've quite literally made the statement that "you people don't want computers anymore, so we're removing 32-bit support, we're taking away every mainstream GPU and graphics API, we're giving you a few more years before we disable x86 support altogether, and you'll be happy about it".
If that's not a begrudging update then I honestly don't know what is. You'd have to be pretty deep in their marketing campaign to tell yourself that removing those features is just business as usual.
Would you please stop posting flamewar comments to HN? You've been doing it a ton lately, unfortunately. It's not what this site is for, and it destroys what it is for.
That’s a fair comment. That having been said, most of what I’m relying to is straight up dishonesty that HN has no way to police and also ‘destroys what it is for’.
> Desktop operating systems like MacOS and Windows belong in corporate, not consumers. They are archaic and still use the file system, which is no longer a thing that consumers need or want. Most people use a tablet and smartphone as their primary computer.
I don't believe most people use a tablet/phone as their primary computer (though maybe their primary web surfing device).
I also don't believe most people want their files on someone else's computer.
Do you have any studies to back up these assertions?
Some of that will be because smartphones last shorter than desktops, but It wouldn’t surprise me if half the smartphone users didn’t even have a desktop PC.
> I also don't believe most people want their files on someone else's computer.
They wouldn't want that if they knew how the cloud works, true. But it seems marketing did a great job at convincing people their new shiny tech product is trustworthy and pure magic.
A lot of people already use their phone/tablet as their "PC". I don't think it'll be the majority in the foreseeable future, but appstores cover a lot of use-cases and are supported by all mainstream services. And for some the smartphone/tablet is the first and maybe only contact with a computer. It runs Fortnite, so what more do you need? ;)
I'll believe it when I see it. I recently got an iPad, and sideloading apps is a ridiculous endeavor that involves a server app (that depends on iTunes and thus only works on macOS and Windows) that has to re-sign your sideloaded apps once every 7 days.
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...
If you look at tablet OS reviews online, a recurring theme is that the app ecosystem is more developed on iPadOS, with reviewers lamenting the Android tablet app ecosystem. I also thought that iPadOS might be a bit better privacy-wise.
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.
I chose a product to the best of my abilities, and it turns out that it may not have been a right fit. Next time I will try another product. I don't see why that warrants such a confrontational tone and/or downvotes; nobody's perfect.
Hacker News users tend to take device choices pretty personally, unfortunately. It seems like the level to which they defend corporations is directly proportional to the amount of money they have sunk into their purchases. If you're looking for sympathy towards how truly reprehensible modern iOS/iPadOS is, you're not going to find it here. The majority will just tell you to get rid of it, since criticism is verboten wherever trillion-dollar companies are concerned.
You are one of many people who go to great pains to inform people on HN about how ‘truly reprehensible’ modern iOS/iPadOS is. Had they listened to you, they might have been saved from their mistake.
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.
> 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...)
> 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.
Since apple stuff is expensive anyway, you can just consider the developer program a 99$/year sideloading feature unlock.
I use TestFlight to push some private apps to my own and friends devices and find it quite convenient. It even updates in the background for them. 90 days is still kind of a chore but doable.
There are only 1-2 apps I want that are locked out of the App Store due to Apple's policies, so at that point it's cheaper to subscribe to the developer's Patreon to get access to their private beta TestFlight (which I might do, it's not expensive).
Microsoft has embraced Linux and open source in general to the extent that it helps them expand into larger markets. Linux is to servers as Windows is to desktop computing, Microsoft has finally acknowledged that they can't "win" in the server and cloud market without conceding to that, and have been "supporting" Linux and open source/free software in various ways over the last several years.
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.
> Microsoft has embraced Linux and open source in general to the extent that it helps them expand into larger markets.
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?
Yep. The saving grace is they don't have a need to reach the third stage and extinguish anything; their focus is on developers and server/cloud, they likely don't feel intimidated by "desktop Linux".
