These kind of project reports showing consistent breakthroughs and clearly a finger on the pulse of what users are encountering as pain points are a good indication that the Asahi team are real pros :)
Look forward to switching back to Asahi full time soon!!
They do also make a lot of money selling hardware, and as things stand today that business happens to make them look like the first tech giant to actually profit from the AI boom (because the hardware they've been developing internally for years happens to be among the best consumer-grade options for self-hosting LLMs). Making their hardware more attractive to tinkerers could be a winning move right now.
They pay for the hardware that they run Linux on. Apple's hardware division is very profitable without the "value" adds they run through their ecosystem, and those people never would have bought into the ecosystem whether they used MacOS or not.
This, but also you would be allowing people to learn Linux. Developer with a Mac has to be one of the most common linux defectors. I suspect most people don't realize how doable and comfortable the switch can be.
It’s been my experience that developers running Mac already know how to use Linux and actively choose to use Mac. Unless the company is forcing it at least.
Yeah, and having the only supported OS be MacOS means they can entice people to upgrade when they want. No continuing on with 8+ year old hardware and a lightweight Linux distro even if it's fine for the intended use case.
The vast majority of people that buy Macs for the ecosystem aren't going to switch to Linux. That market will remain untouched. Outside of a few gamers who might want to put up with the x86-to-ARM translation layer and (for most A to AAA games) Proton to run some non-Mac games. And even they'll probably still dual-boot.
There's a portion of another market: people who want to run Linux and want a powerful laptop who buy x86 Laptops right now. Apple could expend very little relative effort while offering no official support by helping Asahi get that to a first class platform. They won't capture them in the ecosystem (and they never would have) but will still benefit from hardware sales to them.
Obviously, if they sold their hardware at a loss and subsidized that with ecosystem capture that would be a non-starter. But from everything we know, the hardware itself is very profitable.
I imagine the real reason is that if they change things they now have an obligation to promptly share technical docs and if they're slow people will whine and bitch online about them. Not worth it. They have zero to gain (and I say this as someone who would love to dual boot Linux on my M4).
Apple's whole thing is hardware + software working together. Endless other options available to Linux users. They'd also need to be prepared for people bringing laptops to stores with hardware problems that aren't running macOS. Again, more burden for Apple for no gain other than winning over a couple of dozen users.
Do you seriously think someone who installed Asahi is gonna walk into a genius bar and ask for help with it? And often enough that it becomes a burden??
And according to their stats page that sibling linked it’s more like a few tens of thousands of users.
Plenty are whining now and that doesn't seem to bother them. I mean, this is one of the largest companies in the world. This is the company that once told people they were holding the phone wrong. I can't see them being particularly more bothered by people complaining in a slightly different way.
One of the reasons I can see is it’s much easier to say “we don’t play this game” than get a lot of negative press for selective openness and breaking compatibility of non-public interfaces. Maybe it’s even more important internally, as it enables new kind of internal discussions distracting from priority work.
I was trying to come up with a response but you're right. It would be easy for Apple and Apple would get so much goodwill from the community in return.
Yes, Linux developers are officially supported by both Apple and Microsoft, with Microsoft developers being a major contributor to upstream Linux and WSL2 having grown into a capable Linux development environment.
Looking at: https://stats.asahilinux.org/ there is still a pretty large userbase who are so interested in it they go this route. I imagine that count would easily 10x if it would be officially supported. Those numbers are nothing to sneeze at.
I'm running asahi on my macbook. And never touch OSX. I wouldn't even had gotten it if asahi wasn't so well supported.
And let’s be honest, they still wouldn’t be satisfied. The goal post would move to something else. Why don’t my AirPods seamlessly handoff to my Linux MacBook?
I doubt that. The developer community is what made the MacBook predominant in every tech organization. Before that Macs were mostly popular in the creative sector.
We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.
The list here though is long: priorities, accuracy concerns, blurring the line on official support, IP restrictions with third parties (even Apple uses plenty of licensed cores), etc.
I don't see it that way. It's just the GP poster saying that they don't get it. Usually that means the GP poster isn't experienced enough to understand the rationality. So I generally assume the GP poster is simply naive.
This is the big one IMHO. Apple is all about control of the stack, top to bottom. Any sort of "help" with linux on macos would be threatening to that control. Apple "helped" even more than I would have expected by not locking alt OSes out of the bootloader. Probably for less than altruistic reasons, but they did do it.
I don't know if that's true. Linux users are curious and will try more stuff but people mistake that they file bug reports (and usually detailed ones...) with complaining more.
Apple's MO is that it's their baby. End of. They don't do open. Their compiler is closed source, and so on.
Being the least bad doesn't make something good. macOS is the least bad choice for the majority of people that just want a machine to mostly browse the Internet, look at their photos, do some light productivity work, and participate in their ecosystem. It also arguably hosts has the best software options for creative work (although that's reaping the fruits of seeds planted long ago - not sure there's much about macOS that makes it inherently better for those tasks these days). For development, its advantage is the hardware it's running on. To achieve any level of customization or to define my own workflow that isn't what Apple wants me to do or to work across multiple systems, I have to fight macOS rather than work with it. Linux on the other hand does what I tell it to do.
Linux as a desktop OS for the vast overwhelming majority of people is a far inferior option. It just is, and always has been. Even for developers, MacOS doesn't prevent you from getting your job done and getting paid, while using arguably the best laptop hardware. Shit just works and stays out of your way.
If all MacOS has going for it is better hardware, someone would have stepped up and shipped a better linux laptop ages ago. God knows I'm not going back to a flimsy creaking chassis, shit screen, and horrible battery life just so my Docker container doesn't have to run in a VM.
I’ve been using macOS because its creative ecosystem for decades. And over the last 10 years, it’s started to be apparent to me this is an expensive and unstable place to be. It will not be a place where tools find longstanding stability measured in decades. It is and will be a place where various sandcastle taxes are periodically assessed so the particular vision of the platform as a novel current luxury experience will be reinforced, and developers and users will be asked to keep pace on the treadmill and smile.
The real answer is probably simpler than anyone here is making it. Apple hardware margins are healthy enough that selling macbooks to linux users is pure profit, so no services lock-in needed. However, the moment they officially acknowledge Linux support, then it becomes a support surface. Every kernel panic becomes a genius bar visit. Every driver bug becomes a tweet at @AppleSupport. It's the value of plausible deniability. The Asahi team being unofficial is actually the best possible outcome for Apple in that they get hardware sales to Linux enthusiasts without any support burden.
As used by commercial hardware and software vendors, "support" can mean anything from "we'll come fix it for you when it breaks, or your money back" to merely "theoretically, it should work, and we won't get in the way of you trying". Likewise, "unsupported" can mean anything from "don't complain to us if it doesn't work" to "we're going to spend significant engineering effort to prevent it from working".
A stance of "here's some hardware documentation, implement the drivers yourself" definitely falls within that spectrum of "support", and is the kind of "support" for Linux that some hardware vendors have in the past been lauded for, eg. when AMD started documenting their GPUs.
That level of "support" from Apple for running Linux bare-metal on Apple Silicon would be an improvement from the status quo, and in practice would probably be sufficient to get good drivers written and upstreamed in short order, given how much interest there is in running Linux on these devices.
We're talking about "people walking into Genius Bar expecting help with Linux" support. It's not philosophical discussion on what support is, there's literally a specific thing discussed here.
That's one of the several forms of support under discussion, under the specious claim that it would become the expected level of support as soon as Apple declared any level of support for Linux. But as the comments you're refusing to understand have explained, Apple could meaningfully "support" Linux in the form of providing hardware documentation, without making any promises to help any customers troubleshoot Linux running on that hardware.
> What do you mean by needed? A lock-in is more profitable so is needed to maximise profits.
You can't lock-in Linux users because vast majority of them won't switch to macOS and ecosystem at large. This is simply a currently untapped market they could easily almost entirely own if they wanted to. With growing Linux popularity, extra 3-4% of the laptop market share is nothing they can ignore in front of shareholders.
I am not convinced they would "entirely own" the market - they have a small range of hardware. Even less so in the long term. That extra few percentage points would be a lot less profitable as they would only have the margin on extra hardware sales so would not add much to profits - not enough for shareholders to care about.
It also risks existing users switching to Linux which could be a huge loss. Apple has a very loyal user base how do not try anything else and the last thing they want to do is risk encouraging them to try alternatives. Losses could be quite significant: if an existing user switches to Linux not only might you lose software and services sales, but you also risk losing future hardware sales (longer replacement cycle, and no barrier to switching to other hardware).
> I am not convinced they would "entirely own" the market - they have a small range of hardware. Even less so in the long term. That extra few percentage points would be a lot less profitable as they would only have the margin on extra hardware sales so would not add much to profits - not enough for shareholders to care about.
I am aware of that, but there's another factor here: accelerating Windows users switching to Linux on Apple hardware. Those Linux MacBooks would be killer devices that nothing in Windows world can compete against! I mean we can all agree the tech social media would go bonkers over that, wouldn't it? If a couple of YouTubers were able to bump those Linux numbers significantly and spearhead gamers questioning their choices, imagine the dent Apple would make. I am absolutely certain Apple would gain couple extra percentage points with Apple on Linux devices within first year and make Microsoft shit their pants in the process.
> It also risks existing users switching to Linux which could be a huge loss. Apple has a very loyal user base how do not try anything else and the last thing they want to do is risk encouraging them to try alternatives.
Aren't you contradicting yourself here a bit? If they're very loyal, there isn't much risk of them switching, is there?
But yeah, Product Cannibalization is always a risk, though it doesn't mean they couldn't actually embrace Linux and offer ecosystem integration there. iCloud integration? Sure, why not? iPhone integration? Why not? Apple TV app? Again, especially to attract those Windows users making a switch, who are much more used to paying for services and software?
Heck, they could even port AppStore over and improve Swift's cross-platform compatibility, especially considering Swift is fairly cross-platform already. I doubt many software products wold get ported, though. Besides, macOS AppStore is not a huge earner for Apple, considering the platform is open, unlike iOS, so macOS users switching to Linux don't have to imply a significant loss of income from ecosystem spending. Also, many loyal macOS users would likely dual-boot and be happy to continue to buy and use macOS-exclusive software as needed.
This isn't unrealistic, I seriously think it's a matter of time when those numbers start making sense for Apple. Also, if US administration changes, both US and EU regulation bodies will be back on Big Tech asses and for Apple to open to Linux to say "hey, we're pretty open" is another win.
> Aren't you contradicting yourself here a bit? If they're very loyal, there isn't much risk of them switching, is there?
That needs clarification. They are loyal because they do not try anything else and often make assumptions that other OSes are worse than they actually are. They often assume a lot of features (e.g. shared clipboards across devices) are Apple only. They will not take the risk of buying non-Apple hardware to try another OS.
> Product Cannibalization is always a risk, though it doesn't mean they couldn't actually embrace Linux and offer ecosystem integration there. iCloud integration?
It reduces the lock-in the have with existing customers. Having that lockin over the whole stack is what keeps them in the ecosystem.
> Also, if US administration changes, both US and EU regulation bodies will be back on Big Tech asses and for Apple to open to Linux to say "hey, we're pretty open" is another win.
I have less faith in the regulators than that. The push to open has never been that strong. No-one has challenged things like limiting software installation to the app-store, and Google is confident enough that no-one will to be switching to the same with Android in a few months time.
> Besides, macOS AppStore is not a huge earner for Apple, considering the platform is open, unlike iOS, so macOS users switching to Linux don't have to imply a significant loss of income from ecosystem spending
Not yet. They have the option of gradually making "side loading" harder (for our own security, of course) and increasing that profit.
Well, agreed on all points. I guess the conclusion is time will tell, but I am sure Apple is legitimately looking into this on some level, especially since Steam is doing so well and keeps expanding Linux user-base.
> However, the moment they officially acknowledge Linux support, then it becomes a support surface.
Apple documents lots of things the genius bar won't help with. For example, Apple provides instructions for compiling custom builds of the XNU kernel. However, if you replace the stock kernel and your Mac kernel panics, the genius bar isn't going to help you. (Maybe they'd help you wipe the computer and restore everything to stock, but I imagine they'd do that if a Linux user walked in too, even today.)
I suspect Apple hasn't shared documentation because it would take time to prepare for external release (legal stuff, plus the need to avoid leaking future products). What I don't understand is why Apple hasn't made an engineer available to talk on the phone for a couple of hours a month. This would amount to a rounding error in their budget.
> the moment they officially acknowledge Linux support, then it becomes a support surface
untrue. There are no obligations from other hardware vendors, yet you can sometimes get good drivers from them, or at least specs. I think Apple indeed want their hardware to fade out to enforce buying another. Imagine that 20% of your returning customers no longer return after 3-5 years of planned obsolence
I am baffled by how people commonly parrot that flawed logic. Hint: by not seeling those laptops to Linux users they're not making money at all, neither on hardware nor on services.
By selling laptops to users who will never spend on highly profitable recurring revenue stream Apple would be depleting precious Ram stock for tiny one time profit.
So you're suggesting company would rather not sell a product now but rather wait until a "proper" Apple customer is ready for an upgrade? Product that has a significant profit margin upfront?
Also, have you heard about Apple's multi-billion RAM contracts they sign every few years to lock in the prices and supply?
It has already been reported Apple ran out of parts for NEOs. M4 minis are sold out. High end Mac Studio configs have been cancelled. Yes Apple does feel the crunch.
It feels very close to “right to repair”. The coffee grinder you bought came as a single package but it has burrs, gears, machine screws, a motor, etc. If one of those components fails, we should be able to replace it ourselves and as such they should be documented.
The laptop has various pieces of hardware in it and corresponding drivers in macOS to make them tick. Did we buy the hardware and the drivers as an inseparable package, or should we be provided with the manual to make one component work when the other breaks, be that either third party trackpads or third party (Linux) drivers.
Apple might argue that drivers, unlike gears or motors, will never wear down and fail. They won’t need repairing so you don’t get to know how they work. Does right to repair only apply to products that could ever need repairing? Does it also extend to knowing how your purchased product is built so that you could repair it?
Maybe we’ll see a test case some day when a cosmic ray blows out /System/Trackpad.kext and a litigant applies to a court for the documentation to repair their laptop — to write their own driver!
(Or vice versa: a manufacturer of coffee grinders arguing in court that they are exempt from right-to-repair because they repair their machines for free at their Genius Espresso Bar.)
This is an interesting thought exercise. I immediately thought of the counter argument that Apple's driver quality is worse, especially for laptops nearing end of life (for the sake of argument assume this were true).
Could I then submit a warranty claim and demand Apple replace my aging laptop with their latest model?
I think there is a strong case that "the right to repair" includes software. If that doesn't mean drivers must be open source, it should at least mean hardware is documented such that a driver can be written from it.
But the US still doesn't have the right to repair hardware, haha.
I hope the EU is listening. They won't get far with their sovereign software push if hardware cannot be used. Even on the Android side, you can't write an alternative to Android because all of the hardware has locked bootloaders and hidden drivers. Good luck reverse engineering the hardware/drivers on a Samsung Galaxy - let alone an iPhone or MacBook.
I think the biggest value Apple gets from Asahi is they can point EU regulators at it as proof the Mac isn't a closed platform that should be a designated DMA gatekeeper. They don't need Asahi to be complete, they just need it to exist.
Unfortunately iPhones have locked bootloaders that prohibit installing other operating systems. People have gotten Linux running on iPhones, but it requires jailbreaking and that has gotten much harder over time. And it's not really worth putting effort into developing an OS if nobody is going to be able to install it.
I wonder if there would be interest in an Asahi Remix spin focused on a more Mac-like out-of-the-box experience: cmd as the main modifier key, Mac-like keyboard shortcuts, theming, gestures, etc.
Of course, you can tweak any distro however you want, but I think a curated default experience is a different thing.
> while Ctrl is the modifier used at an application level.
DE features don't matter at all outside of cmd-tab and whatever the equivalent of spotlight is. The application level is the main modifier, and changing them all to cmd is essentially impossible at this point. A detail Haiku got just about perfect, I think.
Either way, ctrl as a gui modifier is a dealbreaker for me. It also breaks the use of readline keybindings for text entry.
I’ve had the same thought and would love this. MacOS shortcuts are too deeply ingrained in my fingers.
But every attempt of mine to make Linux shortcuts Mac-like has had too many sharp edges to be useable.
Toshy didn’t seem to work well with Wayland and felt heavy.
Probably the best so far I’ve found has been keyd and custom configs for your most used apps.
A community effort might get us there. Distribute the hours of tinkering across many passionate users instead of everyone doing it in a vacuum.
>.. macOS only ever programs CS42L84 to operate at either 48 or 96 kHz, we could only add support for those two sample rates to the Linux driver ..
> However, CS42L42 supports all the other common sample rates, and while the register layout and programming sequence is different, the actual values programmed in for 48 and 96 kHz are the same across both chips. What would happen if we simply took the values for all other sample rates from the CS42L42 datasheet and added those to the CS42L84 driver? As it turns out, you get support for those sample rates!
> The patch to enable hardware support for 44.1, 88.2, 176.4 and 192 kHz sample rates on both the input and output of the headphone jack was submitted directly upstream, and has been merged for 7.1. We also backported this to Asahi kernel 6.19.9, allowing users to take advantage of this immediately.
Nice bit of chip sleuthing and reverse engineering from the Asahi team!
This is presumably what Apple does. You kind of have to anyway or you have the stupid situation Linux used to have where only one app could play audio at a time.
> you have the stupid situation Linux used to have where only one app could play audio at a time
When was that? I think my first Linux distribution was Ubuntu 8.04 and fairly sure it shipped with PulseAudio which in mind always been able to play audio from multiple sources at the same time, maybe I misremember?
If you have two audio streams, you can't play them as is on the audio device, you have to mix them together. The same happens with analog speakers as you can't just add two signals together. I believe at one point with Alsa, when an application takes control of the audio device, no one else could play with it. Now Alsa comes with dmix (a digital mixer feature) enabled in its default configuration, so two applications may play how they want. And we have PulseAudio, Jack, and Pipewire on top of Alsa to add more features.
OpenBSD still present raw audio devices, but they have sndio which provides a more helpful interface for applications including resampling (not the best algorithms there, according to them).
Most distributions shipped ALSA preconfigured with dmix, which means multiple applications could play sound at the same time just fine.
Which is why the whole "we must use pulseaudio even if it's terrible and has awful standards that blast volume or multiple streams won't work!" was so weird… everybody who tried knew that just removing pulseaudio the multiple streams kept working :)
So only those who never applied the scientific method kept insisting that without PA it was not possible to do that.
I think PA allows for setting applications volumes and have a modular design. But it's kinda the poster child of overengineering (challenged by systemd now). Something like sndiod is more sensible for most desktop distro. People that need a more complex setup can bring in the big gun like pipewire.
I don't think the problem was over-engineering. I think the problem was that if you plugged in headphones it would instantly set the volume to 100% from whatever value it was before.
Plus of course, initially you had to regularly run killall -9 pulseaudio to fix the sound. All in a moment when ALSA with dmix worked just fine.
Sometimes I think fedora and ubuntu are trying to hinder linux as mainstream desktop.
As I recall it was rarely enabled by default and was a pain to set up so in practice not really used.
The most common solution at the time was PulseAudio, which was so bad it usually was better to just use direct ALSA and live with the idiotic one-at-a-time limitation.
Thankfully Pipewire seems to actually work reliably so I guess that's at least one thing ticked off the Year of the Linux Desktop checklist.
Even back then, it could play more than one stream. You had to have a sound card or kernel drivers that supported it (and all non-obsolete ones did by the time pulse audio came out).
I still don’t know what purpose pulseaudio serves, other than adding latency and making stuff less reliable.
PipeWire is better, but it turns out you can just use OSS under freebsd these days, and everything just works, but with lower latency.
If you have some sort of potato sound card that can’t mix output channels in hardware, note that OSS added sw mixing by 2007 (with support for 16 channels by default).
Nonsense - HDA systems were overwhelmingly the majority of Linux systems at that point, and didn't have any hardware support for multiple streams. OSS with software mixing was a commercial product that wasn't upstream. ALSA had userspace mixing but it was very much not an out of the box experience, and didn't take advantage of hardware capabilities in the way Pulseaudio did to reduce wakeups and power consumption.
Even so, surely it would have been easier and better to just fix or replace dmix (in kernel, in the existing data path) than introduce a userspace daemon, break API compatibility, and so on.
It’s been 20 years and pulseaudio is still flaky / high latency / incomprehensible. Professional flows that care use stuff like jack.
Doing audio mixing well is something that is, for a number of reasons, hard to do in kernel. And if you're still using pulseaudio, why? The rest of the world's moved to pipewire, which also provides a jack-compatible interface.
TBH pipewire works much better than pulse, up to the point to replacing jack itself. But DMIX worked fine for non-professional user needs and with very low CPU usage. Yes, it was Jackd for the professional but Windows had ASIO drivers too.
PipeWire replaced Pulse like five years ago; who is using Pulse at this point to make statements like "20 years" meaningful? It isn't really an ongoing concern.
This is the era where I was the lead on Ubuntu laptop support, and I promise you that dmix was not a trivial option to make things work out of the box.
I always had some Knoppix live CD/DVD which had better defaults than Ubuntu itself on hardware autodetection and setup. I think they used kudzu from RH for a good while plus custom patches.
Bear in mind the Knoppix creator had a blind wife, up to the point to creating A.R.I.A.N.E, one of the best distros for the blind (and it was merged with main KNOPPIX, making the distro one of the best accesible ones out there). Thus, proper audio mixing was mandatory.
With the bundled installer you could install it to as a Debian Testing install in the spot. As I didn't have internet at home, I remember using Knoppix before Debian Sarge because it had a huge amount of things to play and test without worrying about odd hardware setups.
Some of the context here is that that at the time, Ubuntu was aiming to work on as close to 100% of existing PCs as possible to make it available to the largest number of users. Knoppix had a lot of great features and also was very opinionated, and that had an influence on the set of hardware it worked well on by default. I evaluated basically every decision made there in terms of whether Ubuntu should adopt the same ones, and there were several that were just not good choices in terms of supporting the widest set of hardware possible.
Look forward to switching back to Asahi full time soon!!
All the classic reasons ("competitive advantage", "secrets", etc) do not hold water in this day and age.
There's a portion of another market: people who want to run Linux and want a powerful laptop who buy x86 Laptops right now. Apple could expend very little relative effort while offering no official support by helping Asahi get that to a first class platform. They won't capture them in the ecosystem (and they never would have) but will still benefit from hardware sales to them.
Obviously, if they sold their hardware at a loss and subsidized that with ecosystem capture that would be a non-starter. But from everything we know, the hardware itself is very profitable.
I’d love to dual boot Linux too but I’m under no delusions about being a very small segment of the Mac population.
And according to their stats page that sibling linked it’s more like a few tens of thousands of users.
I'm running asahi on my macbook. And never touch OSX. I wouldn't even had gotten it if asahi wasn't so well supported.
We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.
The list here though is long: priorities, accuracy concerns, blurring the line on official support, IP restrictions with third parties (even Apple uses plenty of licensed cores), etc.
> We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.
My dear friend I thought I was alone on this hill. It brings a tear to my eye, to learn I will not die alone.
Go team Asahi!
Apple's MO is that it's their baby. End of. They don't do open. Their compiler is closed source, and so on.
A 1-3% of the market out of the 5% that Linux already is, is little to no monetary benefit?
EDIT: I now see what you said: I meant 1-3 percentage points out of the 5%, but I am sure you actually know that.
Important context to understand why.
If all MacOS has going for it is better hardware, someone would have stepped up and shipped a better linux laptop ages ago. God knows I'm not going back to a flimsy creaking chassis, shit screen, and horrible battery life just so my Docker container doesn't have to run in a VM.
A stance of "here's some hardware documentation, implement the drivers yourself" definitely falls within that spectrum of "support", and is the kind of "support" for Linux that some hardware vendors have in the past been lauded for, eg. when AMD started documenting their GPUs.
That level of "support" from Apple for running Linux bare-metal on Apple Silicon would be an improvement from the status quo, and in practice would probably be sufficient to get good drivers written and upstreamed in short order, given how much interest there is in running Linux on these devices.
What do you mean by needed? A lock-in is more profitable so is needed to maximise profits.
You can't lock-in Linux users because vast majority of them won't switch to macOS and ecosystem at large. This is simply a currently untapped market they could easily almost entirely own if they wanted to. With growing Linux popularity, extra 3-4% of the laptop market share is nothing they can ignore in front of shareholders.
It also risks existing users switching to Linux which could be a huge loss. Apple has a very loyal user base how do not try anything else and the last thing they want to do is risk encouraging them to try alternatives. Losses could be quite significant: if an existing user switches to Linux not only might you lose software and services sales, but you also risk losing future hardware sales (longer replacement cycle, and no barrier to switching to other hardware).
I am aware of that, but there's another factor here: accelerating Windows users switching to Linux on Apple hardware. Those Linux MacBooks would be killer devices that nothing in Windows world can compete against! I mean we can all agree the tech social media would go bonkers over that, wouldn't it? If a couple of YouTubers were able to bump those Linux numbers significantly and spearhead gamers questioning their choices, imagine the dent Apple would make. I am absolutely certain Apple would gain couple extra percentage points with Apple on Linux devices within first year and make Microsoft shit their pants in the process.
> It also risks existing users switching to Linux which could be a huge loss. Apple has a very loyal user base how do not try anything else and the last thing they want to do is risk encouraging them to try alternatives.
Aren't you contradicting yourself here a bit? If they're very loyal, there isn't much risk of them switching, is there?
But yeah, Product Cannibalization is always a risk, though it doesn't mean they couldn't actually embrace Linux and offer ecosystem integration there. iCloud integration? Sure, why not? iPhone integration? Why not? Apple TV app? Again, especially to attract those Windows users making a switch, who are much more used to paying for services and software?
Heck, they could even port AppStore over and improve Swift's cross-platform compatibility, especially considering Swift is fairly cross-platform already. I doubt many software products wold get ported, though. Besides, macOS AppStore is not a huge earner for Apple, considering the platform is open, unlike iOS, so macOS users switching to Linux don't have to imply a significant loss of income from ecosystem spending. Also, many loyal macOS users would likely dual-boot and be happy to continue to buy and use macOS-exclusive software as needed.
This isn't unrealistic, I seriously think it's a matter of time when those numbers start making sense for Apple. Also, if US administration changes, both US and EU regulation bodies will be back on Big Tech asses and for Apple to open to Linux to say "hey, we're pretty open" is another win.
That needs clarification. They are loyal because they do not try anything else and often make assumptions that other OSes are worse than they actually are. They often assume a lot of features (e.g. shared clipboards across devices) are Apple only. They will not take the risk of buying non-Apple hardware to try another OS.
> Product Cannibalization is always a risk, though it doesn't mean they couldn't actually embrace Linux and offer ecosystem integration there. iCloud integration?
It reduces the lock-in the have with existing customers. Having that lockin over the whole stack is what keeps them in the ecosystem.
> Also, if US administration changes, both US and EU regulation bodies will be back on Big Tech asses and for Apple to open to Linux to say "hey, we're pretty open" is another win.
I have less faith in the regulators than that. The push to open has never been that strong. No-one has challenged things like limiting software installation to the app-store, and Google is confident enough that no-one will to be switching to the same with Android in a few months time.
> Besides, macOS AppStore is not a huge earner for Apple, considering the platform is open, unlike iOS, so macOS users switching to Linux don't have to imply a significant loss of income from ecosystem spending
Not yet. They have the option of gradually making "side loading" harder (for our own security, of course) and increasing that profit.
Apple documents lots of things the genius bar won't help with. For example, Apple provides instructions for compiling custom builds of the XNU kernel. However, if you replace the stock kernel and your Mac kernel panics, the genius bar isn't going to help you. (Maybe they'd help you wipe the computer and restore everything to stock, but I imagine they'd do that if a Linux user walked in too, even today.)
I suspect Apple hasn't shared documentation because it would take time to prepare for external release (legal stuff, plus the need to avoid leaking future products). What I don't understand is why Apple hasn't made an engineer available to talk on the phone for a couple of hours a month. This would amount to a rounding error in their budget.
untrue. There are no obligations from other hardware vendors, yet you can sometimes get good drivers from them, or at least specs. I think Apple indeed want their hardware to fade out to enforce buying another. Imagine that 20% of your returning customers no longer return after 3-5 years of planned obsolence
Also, have you heard about Apple's multi-billion RAM contracts they sign every few years to lock in the prices and supply?
The laptop has various pieces of hardware in it and corresponding drivers in macOS to make them tick. Did we buy the hardware and the drivers as an inseparable package, or should we be provided with the manual to make one component work when the other breaks, be that either third party trackpads or third party (Linux) drivers.
Apple might argue that drivers, unlike gears or motors, will never wear down and fail. They won’t need repairing so you don’t get to know how they work. Does right to repair only apply to products that could ever need repairing? Does it also extend to knowing how your purchased product is built so that you could repair it?
Maybe we’ll see a test case some day when a cosmic ray blows out /System/Trackpad.kext and a litigant applies to a court for the documentation to repair their laptop — to write their own driver!
(Or vice versa: a manufacturer of coffee grinders arguing in court that they are exempt from right-to-repair because they repair their machines for free at their Genius Espresso Bar.)
Could I then submit a warranty claim and demand Apple replace my aging laptop with their latest model?
But the US still doesn't have the right to repair hardware, haha.
I hope the EU is listening. They won't get far with their sovereign software push if hardware cannot be used. Even on the Android side, you can't write an alternative to Android because all of the hardware has locked bootloaders and hidden drivers. Good luck reverse engineering the hardware/drivers on a Samsung Galaxy - let alone an iPhone or MacBook.
I wonder if there would be interest in an Asahi Remix spin focused on a more Mac-like out-of-the-box experience: cmd as the main modifier key, Mac-like keyboard shortcuts, theming, gestures, etc.
Of course, you can tweak any distro however you want, but I think a curated default experience is a different thing.
Ok typical X/Wayland setups, Cmd is already the main modifier for DE features, while Ctrl is the modifier used at an application level.
There would be a lot of weird overlap with changing that.
DE features don't matter at all outside of cmd-tab and whatever the equivalent of spotlight is. The application level is the main modifier, and changing them all to cmd is essentially impossible at this point. A detail Haiku got just about perfect, I think.
Either way, ctrl as a gui modifier is a dealbreaker for me. It also breaks the use of readline keybindings for text entry.
But every attempt of mine to make Linux shortcuts Mac-like has had too many sharp edges to be useable. Toshy didn’t seem to work well with Wayland and felt heavy. Probably the best so far I’ve found has been keyd and custom configs for your most used apps.
A community effort might get us there. Distribute the hours of tinkering across many passionate users instead of everyone doing it in a vacuum.
> However, CS42L42 supports all the other common sample rates, and while the register layout and programming sequence is different, the actual values programmed in for 48 and 96 kHz are the same across both chips. What would happen if we simply took the values for all other sample rates from the CS42L42 datasheet and added those to the CS42L84 driver? As it turns out, you get support for those sample rates!
> The patch to enable hardware support for 44.1, 88.2, 176.4 and 192 kHz sample rates on both the input and output of the headphone jack was submitted directly upstream, and has been merged for 7.1. We also backported this to Asahi kernel 6.19.9, allowing users to take advantage of this immediately.
Nice bit of chip sleuthing and reverse engineering from the Asahi team!
https://github.com/hasenbanck/resampler#quality-analysis
This is presumably what Apple does. You kind of have to anyway or you have the stupid situation Linux used to have where only one app could play audio at a time.
When was that? I think my first Linux distribution was Ubuntu 8.04 and fairly sure it shipped with PulseAudio which in mind always been able to play audio from multiple sources at the same time, maybe I misremember?
OpenBSD still present raw audio devices, but they have sndio which provides a more helpful interface for applications including resampling (not the best algorithms there, according to them).
Upsite: Highest quality playback.
Downside: Only one process could play audio at a time.
Which is why the whole "we must use pulseaudio even if it's terrible and has awful standards that blast volume or multiple streams won't work!" was so weird… everybody who tried knew that just removing pulseaudio the multiple streams kept working :)
So only those who never applied the scientific method kept insisting that without PA it was not possible to do that.
Plus of course, initially you had to regularly run killall -9 pulseaudio to fix the sound. All in a moment when ALSA with dmix worked just fine.
Sometimes I think fedora and ubuntu are trying to hinder linux as mainstream desktop.
The most common solution at the time was PulseAudio, which was so bad it usually was better to just use direct ALSA and live with the idiotic one-at-a-time limitation.
Thankfully Pipewire seems to actually work reliably so I guess that's at least one thing ticked off the Year of the Linux Desktop checklist.
I still don’t know what purpose pulseaudio serves, other than adding latency and making stuff less reliable.
PipeWire is better, but it turns out you can just use OSS under freebsd these days, and everything just works, but with lower latency.
If you have some sort of potato sound card that can’t mix output channels in hardware, note that OSS added sw mixing by 2007 (with support for 16 channels by default).
It’s been 20 years and pulseaudio is still flaky / high latency / incomprehensible. Professional flows that care use stuff like jack.
PipeWire replaced Pulse like five years ago; who is using Pulse at this point to make statements like "20 years" meaningful? It isn't really an ongoing concern.
Bear in mind the Knoppix creator had a blind wife, up to the point to creating A.R.I.A.N.E, one of the best distros for the blind (and it was merged with main KNOPPIX, making the distro one of the best accesible ones out there). Thus, proper audio mixing was mandatory.
With the bundled installer you could install it to as a Debian Testing install in the spot. As I didn't have internet at home, I remember using Knoppix before Debian Sarge because it had a huge amount of things to play and test without worrying about odd hardware setups.