Paving the Road to Vulkan on Asahi Linux
asahilinux.org
asahilinux.org
> Not only that, our driver passes 100% of the dEQP-GLES2 and dEQP-EGL conformance tests, which is better OpenGL conformance than macOS for that version. But we’re not stopping there of course, with full GLES 3.0 and 3.1 support well underway thanks to Alyssa’s tireless efforts!
That's very impressive work. Congrats to Asahi and Alyssa.
What
Not that they can't, it would be nice. When they capitulated and came out with the intel macs around 2007ish, it became sort of a golden era. You could run macos and windows on their machines, and the smart computer folks started getting and usefully using macs.
But now apple is years into a disappointing inward looking phase.
What a decent future would be like...
- vulcan/x
- take back xquartz into the fold
- actively pursue other linux graphics apis
- apple does virtualization
- maybe like rosetta but for all their software
- run macos9 in a window
- apple does containers
- what if there was something like docker for macos natively?
FROM macos:10.3
- apple actively supports open source projects
- open up ios
- let me see the filesystem
- let me run a firewall (true privacy?)
Edit: The latest macOS has a great virtualization system built in, that many of the container platforms have already switched to.
edit: fixed the nickname
But you lose the ability to talk about it.
* Please don’t take the exact number too seriously, as there are other differences too (Xonotic runs under Rosetta on macOS, but it was also rendering at a lower resolution there due to being a non-Retina app).
Is that surprising? Fewer pixels usually means faster rendering.
_Hence why she claims that it is in a similar performance range._
(instead of saying it's way fast, which is a result from taking sentences out of context and not fully reading the article)
A Steam for iOS & Android might be worth it for Valve, but for Mac it's like not worth the money it costs.
Additionally Apple is one of the main offenders pushing for a lockdown of PC platforms and one of the main lobbyist trying to prevent regulation requiring the possibility of (well working) 3rd party app stores. Which means not only would good Mac support be costly it also is constantly at risk of "defacto" being killed off. (Yes there are currently regulations for requiring 3rd party app stores, but it being theoretical possible and it being practically viable for a business are not the same.)
> > I wonder if Apple will budge on their not-invented-here syndrome and allow for a real vulkan.kext on upcoming macOS versions
> Native Vulkan support could also pave the way for a proper Mac version of DXVK
I think the proposition was that if Valve lets it happen, other interested developers might be inclined to improve the situation enough that it's not so much extra work for Valve to add Mac support to Proton.
I'm not sure who all would be interested, but I imagine the motivation would be similar to whatever is keeping the MoltenVK developers going.
You're right that Apple provides an a hostile and precarious platform compared to Linux, of course.
Nonsense.
They haven’t even implemented power management and it’s not even a fair comparison.
https://www.reddit.com/r/AsahiLinux/comments/11mjhx5/tips_fo...
Marcan (two weeks ago):
It's a known issue blocked on bureaucracy/politics with the kernel, so you just have to wait. Sorry.
ARM64 Linux does not want hardware-specific cpuidle drivers, instead relying on the PSCI firmware standard, but that standard is designed to rely on optional ARM features that Apple Silicon does not implement, so we can't implement it. Basically, PSCI assumes you have a "super-hypervisor" running the platform (TrustZone/EL3 on most Androids, but also somewhat similar to SMM mode on Intel), which is something Apple very deliberately stripped out of their CPUs very quickly because they don't need it and their security model relies on better solutions. Linux on AS truly runs on bare metal at the highest privilege, unlike the vast majority of other ARM64 platforms.
The current thinking is we need to make a new standard, either a new PSCI transport that does work on AS or something simpler/ad-hoc. We haven't had time to start that long conversation formally yet. I could write a hardware-specific cpuidle driver in a day, but of course they'd reject it upstream.
Do you realize that Vulkan as an idea (not even as a spec) appeared 1 year after Metal was shipped?
Do you realize that apart from Android there's no platform that truly supports Vulkan?
> That would solidify it as not only the best graphical workstation OS, but also the best gaming OS
Of course it wouldn't. Vulkan is on its way to become the next OpenGL
1. I try not to tell people what to do with their free time. While you may think it's "bizarre", this use of their time has value to them, not only in the hopeful end result (fully-functional Linux on ARM Macs), but also in the satisfaction of the technical challenge, bragging rights, and general reputation. I'm sure there are some people who might look at what you do with your spare time and think you're "wasting" it sometimes. But that's in the eye of the beholder, and at any rate, that's your prerogative, as this is theirs.
2. I used to run Linux on Mac laptops (gave up around 2016 or so, tried again in 2018, gave up again shortly after), and I get the appeal: the hardware is really nice. And by all accounts, the ARM Macs are even nicer than the Intel Macs. Sure, they're not perfect (lack of upgradeability/repairability, etc.), but running Linux on them can be great, if the hardware support is there. "I like this hardware and I want to run Linux on/with it, so I'll figure it out myself" seems like a perfectly reasonable thing to do. Many of the drivers in the Linux kernel for various bits of hardware only exist because someone adopted this attitude.
I also just think your premise is a bit flawed:
> open source developers go so far to contribute to a closed source proprietary ecosystem
This is a little bit of a weird statement, because these developers aren't doing that. The "closed source proprietary ecosystem" is macOS and its app store. The hardware itself is more or less just as open (or closed) as most non-Apple hardware. I mean, I can't rewrite the BIOS in my Framework Laptop, nor can I make heads or tails of any of the binary firmware blobs Linux loads into the WiFi chipset, graphics chipset, etc. Apple's hardware is undocumented, certainly, but that's pretty common when it comes to Linux hardware support.
> but they at times actually intentionally impede their work
Do they, though? From what I've read of the Asahi project's progress, they didn't run into cases where Apple intentionally tried to make things harder on them. Sure, some things were harder, but I don't think we can ascribe a malicious motive to Apple. The most likely explanation is that they just decided to design things in a particular way because they felt it would be best for their own purposes, and didn't really care to think about anything else.
They could have decided to actively cryptographically lock down the boot process to prohibit other OSes from running, but they didn't do that.
> That is a lot of time and effort of someone doing something for free that the manufacturer should be paying them to do and assist with.
Why "should" they? All hardware manufacturers decide what software to write, and what platforms to support. If they don't think the cost of writing and supporting drivers for Linux is worth what they'll get in return, they'll make the logical choice to just... not do that. We've seen plenty of vendors over the 30-odd-year lifetime of Linux do that math and decide Linux support wasn't worth it to them. It's a shame, but I don't think it's fair to come down on them hard for that. Certainly some vendors (nvidia comes to mind) have been actively hostile toward the Linux community at times, but I don't think we can say the same of Apple.
I don’t see people making the same statements about work on the nouveau driver or on the Broadcom opensource wifi drivers. But somehow because the hardware was built by apple folks seem to think it’s more proprietary than anything else linux has run on.
Didn't they make an undocumented change to the boot loader that serves literally no purpose other than to give Asahi a somewhat stable target than what they were using before?
No, a person who used to work on the bootloader at Apple said on Twitter they did it because they wanted to enable different OSes. That's not an "Apple confirmed", that's "employee X said".
A lot of peoples careers start this way. A lot of the hacking and the cracking scene was born this way. There is a certain kind of pleasure and satisfaction involved when you get a device that was previously not designed to do a certain thing behave in that way.
Off-topic: FreeBSD had an early version of Grand Central Dispatch ported to it, I wonder if Linux could benefit from that maybe with some io-uring goodness.
The sorry state of Apple's OpenGL drivers is a part of their strategy. They're choosing to not invest in OpenGL, and have even officially deprecated it. They want you to use Metal instead.
But macOS is not the go-to platform for this sort of thing, especially when it comes to games. This does seem like a strategic mistake. Maybe they just don't care, for whatever reason. I mean, it doesn't seem like Metal has been catastrophic for Apple, has it?
Then again, OpenGL is probably still good enough on macOS for most 3D apps, deprecated or not. And if Apple does decide to actually remove it, I believe there are projects that implement the OpenGL API on top of Metal (certainly with performance impact). And third-party developers certainly have the option to wait to write a Metal backend only after Apple announces OpenGL is being dropped completely.
Maybe that's the whole strategy? To provide an API which exposes what's easy to do in a well-performing way on their hardware, and let the community worry about getting the standards to work? It certainly seems to be working, and it probably means they need to spend less resources on driver development than if they tried to stay current on OpenGL and Vulkan.
All major AAA engines support Metal, even if the main target for them is iOS.
OpenGL is old, crufty and for modern standards sucks no matter how grate it once was. Most new 3D software doesn't use OpenGL, a lot of new software which does use OpenGL limits itself to OpenGL ES (which is roughly a subset of OpenGL).
Apple always had issues with a "Not Invented Here" syndrome and an obsession to control every little bit. Apple always pushed that software should be explicitly written for Apple, or if not at least with an Apple focus. New GUIs "should" be written with SwiftUI, etc.
For apple having a different API means they don't have spent time with standards outside of things they want to pus beyond their ecosystem, this means they can just further develop Metal however they want, ignoring inputs from everyone else. This can remove friction, but also will remove valuable feedback and profiting from other peoples innovation.
Lastly Vulcan, DirectX12 and Metal aren't too different hence why thinks like MoltenVK (Vulkan API/emulation on top of Metal) or VKD3D (DirectX12 API/emulation on top of Vulcan) exists. (Through no surprise all three have their own edge cases which does make such cross libraries non trivial, still they are quite viable and most important performant as they don't have to do much emulation and mostly can just map functionality.)
It isn't.
Vulkan as an idea appeared a year after Metal was released.
And even today:
- Windows first-party support is DirectX
- Xbox is DirectX
- Playstation is whatever Playstation uses
- Switch has nominal Vulkan support, but you're better off using their non-Vulkan SDKs
- MacOS and iOS are Metal
- Android support Vulkan. Some versions of it, depends on phone, version, and manufacturer.
- WebGL is browser-only... and on its way to be replaced by WebGPU
Yeah. Great cross-platform story
MacOS is a joke for gaming. iOS though of course is all metal. If you wanna target that platform then that’s all you got. But translating or porting to other platforms DX12 on Windows Vulkan is the answer.
They literally just ported the whole platform to ARM which has had some great benefits for the whole OS + UX of using laptops.
If you're a layman it can be hard to find information on how graphics works that is technical enough (uses terms like "user space" and "kernel"), but simple and high-level enough for somebody who doesn't know much. There is stuff like that throughout the piece.
Here's the first example:
> In every modern OS, GPU drivers are split into two parts: a userspace part, and a kernel part. The kernel part is in charge of managing GPU resources and how they are shared between apps, and the userspace part is in charge of converting commands from a graphics API (such as OpenGL or Vulkan) into the hardware commands that the GPU needs to execute.
> Between those two parts, there is something called the Userspace API or “UAPI”. This is the interface that they use to communicate between them, and it is specific to each class of GPUs! Since the exact split between userspace and the kernel can vary depending on how each GPU is designed, and since different GPU designs require different bits of data and parameters to be passed between userspace and the kernel, each new GPU driver requires its own UAPI to go along with it.
Presumably there was an era of console games that did things this way, back before game consoles had OSes — but since that would be about 10–15 years ago now (the Gamecube + PS2 era) it'd be somewhat hard to judge from that what the perf margin for modern devices would be, since the modern rendering pipeline is so different than back then.
Probably not much. Applications already directly build data structures in userspace and hand them off to be rendered by the hardware; the kernel intervention is minimal, and AFAIK mostly concerns itself with memory allocation and queue management.
Presumably you're quite seasoned so I would assume you'd know: but Windows itself put a lot of its graphics rendering in kernel-space, they saw considerable performance gains from doing so but suffered 2 decades of severe bugs in rendering.
And yeah, if you imagine having to write a game as an OS kernel driver, then yeah, that's probably impractical. You don't want to have to program a game using kernel APIs.
But imagine instead, taking a regular OS with protected memory, and:
• Stripping out the kernel logic during context switches / interrupts, that de-elevates userland processes down to "ring 3" (or whatever the equivalent is on other ISAs.)
• Ensuring the kernel is mapped into every process's address space at a known position.
• Developing a libc where all the functions that make syscalls, have been replaced with raw calls to the mapped OS kernel functions that those syscalls would normally end up calling.
So you're still developing "userland" applications (i.e. there are still separate processes that each have their own virtual address space); but there's no syscall overhead. So a series of synchronous kernel syscalls to e.g. allocate O(N) tiny video-memory buffers, would be just as fast as (or faster than) what mechanisms like io_uring enable on Linux.
I'm excited for the day that I can easily install SteamOS (the modern one that runs on the Steamdeck) on an M2 Mac mini for an insanely powered "Steam console" for my living room TV.
Then I guess Metal on Mac can't be such a big issue either.
Things are certainly looking better than they did a couple years ago, but getting ARM to run x86 code faster-than-native is an uphill battle. Maybe even an impossible one, but I've been surprised before (like with DXVK).
[0] Crysis on a Rockchip ARM SOC, for example: https://youtu.be/k6C5mZvanFU?t=1069
I'm pretty sure it's just vanilla ARM NEON so I don't think it will take any reverse engineering. The Apple Silicon GPU is custom, but the CPU is just minor extensions to (and compatible with) AArch64. Rumour has it that this is because AArch64 was designed by Apple and donated to ARM (who Apple has close relationship with being that they were a founding member).
though amx won’t help out with emulation much
...it also raises the question of how emulated titles fare against translated ones. It would be fascinating to see how something like Dark Souls Remastered performs through Yuzu vs DXVK on Apple Silicon.
Not having any experience in that industry, I wonder what the driving forces of this are. I suspect it's some combination of incredibly brittle codebases that cease to build if glanced at the wrong way and aversion to spending anything on games post-release.
An example that come to mind immediately is how much of a mess it is to get games that were built with Games for Windows Live like the PC port of Fable 3 running on modern Windows. It's possible, but there's a ridiculous number of hoops to jump through, none of which would be necessary if Microsoft shipped a quick and dirty update that pulled out the Games for Windows Live dependency.
I am pretty sure that is the answer. Unless the game is Cyberpunk levels of unplayable, there is no money in post release support unless it is bundled with DLC or GOTY releases.
Back in the day it was pretty commonly sited figure that like 90% of a game's revenue came in the first 3-4 weeks of release. DLC and "seasons" are an attempt to stretch it out and make more off a single release, but I haven't heard how well that works.
That also dates back to back in the days, we just called it expansion packs.
- Total dependency on an engine's build system
- Lack of official support for uncommon platforms
- Extremely low expected ROI even if it were possible to deliver on other platforms
Gamedevs aren't in the business of building platforms, they're in the business (mostly) of consuming them and going where the players are.
Gamedevs not updating is because
- The engines themselves are indeed outrageously brittle at times, with LTS releases sometimes containing significant bugs that persist against newer releases of minor and major versions
- New releases can actually cause dramatic regressions, not just in terms of bugs, but in terms of features, stability, binary size, and more
- AAAs are wasting time chasing the next big thing, non-AAAs are struggling with few people and need to constantly be building the next thing because they're building products, not services
- Gamedevs are largely media/entertainment companies, very few act like technology companies
The primary reason is that there's no money in it. Like movies, your "one shot" game (without some sort of continuous billing e.g. mmo, subscription, continuous stream of DLCs) makes most of its revenue in the first few weeks, and once the kinks are ironed out what it makes afterwards doesn't really depend on maintenance.
Additional maintenance doesn't pay for itself, the producer doesn't pay the devs for that, and thus the devs take on the next contract to pay the bills. Not to mention additional maintenance is a risk.
On macOS, IIRC the userspace and kernel-space page size can be different and different userspace programs can run with diferent page sizes, however on Linux the page size is currently fixed across the system and set at compile time. The M1's IOMMU only supports 16k-aligned pages, so memory regions that need to be shared with other hardware (e.g. the GPU) need to be 16k-aligned. As such (and because Linux doesn't currently have great support for mixed page sizes), the Asahi Linux project has decided to run with 16k pages globally. However, that breaks a number of applications that are expecting 4k pages.
More info: https://github.com/AsahiLinux/docs/wiki/Broken-Software
I think that Fedora may be leading the pack here, see https://danielpocock.com/power9-aarch64-64k-page-sizes/
That means a lot of software has come to assume that.
Certain memory buffers need to be page size aligned, or a multiple of pages long. Code can only be loaded to a page aligned memory address. Memory mapping and read/write/execute permissions can only be set on a per-page basis.
If all that stuff is hardcoded now, there will be lots of fixes necessary to make things work properly with a different page size.
And those fixes probably will need the software to be recompiled. And some software is only distributed in binary form, and getting someone to recompile it may be nearly impossible.
Wine FAQ concludes
> "Wine is not just an emulator" is more accurate. Thinking of Wine as just an emulator is really forgetting about the other things it is. Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.
Wine (written as WinE when I first encountered it, IIRC) emulates the Windows runtime environment.
He/she is quite the creative person I must say.
He's been clear that he's not Asahi Lina... and he's also not a GPU hacker as far as I know.
I'm not really willing to indulge the greater discussion, but marcan has done some serious GPU hacking before, reverse engineering the microcode (not shaders) of the PS4's GPU to fix bugs that the PS4 hacked around in the drivers.
He even did a super-cringe "take over" video, where Asahi Lina "broke into" one of streams: https://www.youtube.com/watch?v=effHrj0qmwk
I have no specific knowledge, but it seems very clear to me that at the very least marcan is a collaborator in the persona of Asahi Lina; and absent further contrary evidence, them being the same makes sense.
—⁂—
¹ And if stream key exfiltration actually happened, I find it hard to imagine anything but acrimony arising.
> If you want to support my work, you can donate to marcan’s Asahi Linux support fund on GitHub Sponsors or Patreon, which helps me out too!
Probably some pre-recorded, agreed upon advertisement to promote a new channel.
You cannot be this gullible. "Asahi Lina" is a pseudonym for Marcan.
/home/marcan and /home/lina on the same box.
I don't really get the V-Tuber thing (other than wanting to stay anonymous) but having code explained to me by an anime character is hilarious.
I honestly find it very hard to take someone seriously who chooses this kind of persona, even though it's hard to argue with their technical ability and results.
Wow that's impressive!
The Asahi writeups are great, but certainly not all there is. Tons of reverse-engineering stuff and Linux documentation gets submit to this website, it just doesn't generally do as well in the ranking system.
[0] https://thisweek.gnome.org/
[0] https://pointieststick.com/category/this-week-in-kde/
Some people might not remember this, but hardware support for Linux was a real crapshoot back then, and it's only "mostly smooth" on PC today because we have a quarter century of work building out drivers and modules for the platform.
It's fun watching the breakneck pace at which they are going through the same processes with a brand new and proprietary consumer-oriented computing platform.
Also every blog they post are great read!
They have ~16% of the global market. In no way do they have a dominant position.
Battery life is really the core differentiator at the moment.
What if you price out a replacement with the full RAM and SSD capacity you want from the OEM rather than as an aftermarket upgrade? I think the problem usually is not so much "Apple over-charges for upgrades" as it is "all OEMs over-charge for upgrades", with a side of "Apple uses non-upgradable storage".
Moot point. Of course if you tie your hands behind your back your options will be limited. The point, for the parent, is that they aren't limited by insane markup pricing.
The reality is that, if you need a lot of RAM and SSD space, it’s going to cost you a lot more than buying a laptop and replacing the RAM and SSD yourself.
If someone said that the price of SSD and RAM in, say, a System76 laptop was outrageous and that’s why they won’t buy one, that would be a bit silly since they can upgrade those themselves.
What you can’t do is perform a RAM or SSD upgrade on a MacBook. So it’s a reasonable issue to have with their pricing.
To throw one more datapoint in: for my own development, I have to closely manage (closing and reopening stuff constantly, paying the cognitive overhead of context switching as I go) just to keep RAM use between 32gb-64gb — use never managed to go below the former, and the latter is the total my laptop can support. I’m usually sitting around 90%-95% utilization. So 64gb is an absolute minimum for what I can reasonably get away with (and I’d be much more productive if my laptop had the same 128gb my desktop has).
Some people just need as much RAM and storage they can get their hands on, and that quickly makes the MacBook a really expensive option. No bitching (really, no sentiment at all), just facts and reasoning.
https://www.macrumors.com/2021/04/06/m1-mac-ram-and-ssd-upgr...
A $3k lenovo thinkpad p16 uses DDR4-4800 or 76.8GB/sec peak. That also ignores the arm relaxes memory model, which means you get (on average) a greater fraction of peak bandwidth when running something memory intensive.
So apple does 1.3x, 2.6x, or 5.2x better. On a desktop you can get another 2x with the M1 Extreme. Seems quite a bit better than "Pretty ok", it's a big part of why the apple's get great GPU performance compared to Intel/AMD laptops with an iGPU and run at a small fraction of the power of the dGPUs used in laptops.
They have an ARM64 offering, but it's PlaySkool premium.
If that were remotely true TFA wouldn't be about reverse engineered GPU support on Apple Silicon. Nor would there really be a need for Asahi Linux to be developed in its own silo while it gets Apple Silicon support hammered out.
The differentiator for decades now is intel-based laptops, including thinkpads, have been well-supported by mainline kernels including GPU support. Support that Intel has directly funded development and maintenance of.
Where are the @apple.com commits supporting Apple Silicon in mainline Linux?
Even AMD is better as of amdgpu.
Such as? What "proprietary Lenovo hardware" is obfuscating my boot process, I'm really curious now.
> Intel supports Linux as a business decision
Yes. Intel supports Linux because the concept of selling Unix doesn't work. Take it from Apple, who gave up on selling their OS after realizing that people were really only in it for the hardware. If Intel is the begrudging neighbor to Open Source software, then Apple is holding them in a Mexican standoff with their userbase. Somehow, Intel's "business decision" manages to be the more civilized relationship between the two.
Believe it or not, they sell hardware with Linux OOTB thanks to others reverse engineering their proprietary subsystems.
Seems like the #1 reason thinkpads are well supported is that they are relatively popular among the people who modify the OS and kernel for compatibility.
I don't recall that Lenovo is a particularly big contributor to the linux kernel.
False. Lenovo hardware contains a lot of proprietary undocumented parts that required reverse engineering to get working on Linux/BSD. The parts that didn't require reverse engineering (Intel GPU) were not made by Lenovo.
Apple hardware is "open" as far as they don't try to prevent other operating systems to be installed. Apparently they made it reasonably straightforward for the Asahi team.
1. This is not true for "Apple hardware" as a rule.
2. Removing support for third-party OSes would be a shocking product regression for the Macbook.
3. If Apple's definition of "Open" excludes any transparent documentation or explanation, then they have provided precisely nothing.
You contradict yourself by praising Apple for keeping standard features while deriding Lenovo for doing the same thing. All of this ignores the Linux certification Lenovo offers on their products, their Linux support contracts and even the freely-provided firmware updates through fwupd (something Apple will never provide). Regardless of whether you characterize "open"-ness as non-hostility or constructive support, Lenovo is still the more open company by a country mile. And Lenovo doesn't even do that much to-boot.
Putting words in my mouth. I never praised Apple and I never derided Lenovo. I am simply stating the facts. I am trying to explain that both companies have the same approach. Neither of them are open source idealists. Lenovo is not more open than Apple. Apple is not more open than Lenovo. I am pointing out the double standards and hypocrisy in this thread. I have owned many Lenovo and Apple products and I'm not a fanboy of any company.
> 1. This is not true for "Apple hardware" as a rule.
It is true for their laptops and desktops. iPhone/iPad are not relevant to this discussion.
This is straight-up untrue, though. In this specific situation, they are markedly more open than Apple.
Here is their commit for ACPI support: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux...
Here is their commit for always-on USB power: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platfo...
Here is the official hwmon patch for an otherwise unsupported laptop: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux...
Lenovo is doing what Apple doesn't, and publishing their contributions as GPL code. In this particular arena, they are provably more open in the sense that they make official Linux contributions and Apple does not.
I too have owned hardware from either company, and have plenty to complain about for both. One thing I cannot deride is the quality of first-party Linux support for my Lenovo hardware. It's not perfect and they're an ill-fit successor to IBM, but they make marked FOSS contributions that other companies would refuse. Because these changes are made freely available with an Open license, I think it's fully fair to say that Lenovo is shipping more Open systems than Apple is. Like I said in my other post, they don't even have to do much to cement themselves in that position either, just offer a few of their own patches.
> It is true for the current hardware. [sic]
> It is true for their laptops and desktops. iPhone/iPad are not relevant to this discussion.
Ah, there's the caveat. We can agree to disagree, frankly I'm more interested to see where the legislation takes this.
How is it false? Whether the parts were made by Lenovo or not is irrelevant. It may not be 100% open (and this is probably not due to parts that Lenovo themselves created), but it is substantially open, which is far more than can be said about the Macs, which are virtually undocumented system-architecture wise, and who knows what Apple will do in the future to hamstring efforts to use them outside the walled garden.
> Apple hardware is "open" as far as they don't try to prevent other operating systems to be installed. Apparently they made it reasonably straightforward for the Asahi team.
That is not "open", it's just "not openly hostile to reverse engineering...yet".
No it is not. I'm amazed that people just don't get this simple fact. The drivers were reverse engineered. ThinkPad is not an open platform. It contains some Intel and AMD stuff that is open, but you can't give credit to Lenovo for that.
I'm not giving credit to Lenovo, I'm saying that the platform is mostly open because it is based on mostly open components. In contrast to Apple's devices, where the platform is closed because it is based on undocumented components. You could say the same about pretty much any standard PC, Lenovo is just one of many vendors, I have no idea why they got singled out here.
But they do sell boxes explicitly qualified and supported to run Linux, and they do contribute to the Linux kernel development process.
The fact remains that claiming any of Apple's hardware platforms are remotely open is laughable.
"ThinkPad linux driver reverse engineered" or "lenovo linux driver reverse engineered"
Power management, I2C devices, touchpad, touchscreen, audio, WiFi, bluetooth, etc. Many things besides the GPU. Maybe some of it is open now (Intel parts) but that wasn't always the case.
As another smart person (smoldesu) pointed out here, Lenovo has recently started contributing some updates to the kernel, but the vast majority has been reverse engineered over decades.
The attitude of Linux devs was always to accept that hardware is proprietary/undocumented and get to work on reverse engineering. Then users take it for granted that stuff just works and have no appreciation of the effort that it took to get it working.
The Asahi Linux developers themselves have praised the openness of Apple Silicon, not because they have access to documentation or source code that we don't, but because it seems Apple has gone out of their way to make sure their platform can securely accommodate third party operating systems even though they have no incentive to. It's surprising in contrast to Microsoft, who has been slowly trying to make booting Linux on PCs that ship with Windows harder and harder.
I definitely think calling Apple Silicon an "open platform" is a bit of a stretch, but it's not the iron clad walled garden people think it is either.
Such as what, though?
Intel and AMD both wrote support for their systems themselves. Nvidia has long offered a proprietary driver for Linux users, and even Intel Macbooks were a shoo-in once the firmware is sorted out. It's been a long time since someone has approached a full-scale reverse engineering project like Asahi, and I think characterizing it as "non-unique" undersells the amount of bespoke work here.
Apple made the right move by continuing to allow third-party OSes, but that's not equivalent to building out support. The work required to bring up a black-box SOC is hugely distinct from using first-party drivers to boot into Linux through UEFI.
Of course what Asahi Linux has undertaken still feels like a bigger and more impressive task, I'm just saying that this kind of work is not entirely unprecedented. The current Linux ecosystem on Apple Silicon is more comparable to that of the PC Linux ecosystem from 25 years ago than from today.
Drivers for WiFi, audio, Bluetooth, a heap of I2C devices like keyboards on laptops and temp/fan control, graphics cards, and much much more.
Not a single company “built out support” for all these things. And none of it is covered by some common interface — each must be reverse engineered (or implemented following reference manuals, if they are available). Intel and AMD did not provide support for these, because they can’t — the processor architecture is oblivious of these peripherals.
I think you’re underestimating how much volunteer work has been done to get Linux to be usable on any machine. From your wording, I suspect you may think there are some grand unifying abstractions that, when implemented once, provide compatibility with most machines, and that Intel and AMD did just that. But that would be mistaken.
UEFI provides some of this, but UEFI didn't become ubiquitous on consumer hardware until the 2010s.
And I do have a distaste for putting money in Apple's pockets for various personal reasons, from the huge pile of cache they're sitting on to the way they repeatedly updated my long-dead iPod's firmware just to break its compatibility with open-source tools for syncing music to it way back in the day to the upstream-hostile forming of WebKit from KHTML to their utterly cynical use of 'open-source' as a marketing ploy when they launched OS X. So if I do get an Apple Silicon Mac, it will have to be used even though I wouldn't otherwise want it to be.
Because most other hardware vendors suck, too, there are still things Apple could do, short of becoming some kind of open hardware company, that would make me reconsider that general sense of hostility I've gotten from them over the years, which I acknowledged in this other comment on this post: https://news.ycombinator.com/item?id=35233479
I just wish my interest in the Apple Silicon option could be wholehearted enthusiasm, instead of something complicated by my relationship to a company whose ethos screams that my values are unimportant on a bunch of different levels.
> Display Support
> Simultaneously supports full native resolution on the built-in display
> at 1 billion colors and:
>
> Up to two external displays with up to 6K resolution at 60Hz at over a
> billion colors (M1 Pro) or
> Up to three external displays with up to 6K resolution and one external
> display with up to 4K resolution at 60Hz at over a billion colors (M1 Max)
>
> Thunderbolt 4 digital video output
>
> Native DisplayPort output over USB‑C
> VGA, HDMI, DVI, and Thunderbolt 2 output supported using adapters (sold
> separately)
>
> HDMI digital video output
>
> Support for one display with up to 4K resolution at 60Hz
> DVI output using HDMI to DVI Adapter (sold separately)
https://support.apple.com/kb/SP854?viewlocale=en_US&locale=e...
Also, is anyone else afraid of the possibility of Apple deciding to screw us up by imposing restrictions to prevent people specifically from doing this for...reasons?
According to Marcan, Apple explicitly went out of their way to support secure booting of other OSs as well.
Also, it’s hard to predict, but I think it would only increase revenue if the small, but rich linux-using software community would choose MacBooks as “the next thinkpads”, and it’s not like most people would not just have both OSs available and switch between them.
On the other hand having kids is basically anathema to being able to live this life. So you are choosing work (in a broader sense of term than conventionally used) over family.
I can take you on a deep dive into every aspect of audio software. My kids and my wife did not obstruct that, and if anything, having responsibilities towards them forced me to be even better at the process that got me to where I am today.
Although it's unclear, perhaps you are talking about FOSS development (actually looking up Ardour from your profile, yes you definitely are). That's very impressive, then! So you did manage to juggle having a full-time job, FOSS development, and a family?
There are so few people with experiences like yours that it's sometimes hard to not let that get into my head.
So it's refreshing to see a different opinion.
It did not have any impact on my curiosity or learning process during the journey I've been on for the last 25 years.
The point is the the presence (or absence) of children is not determinative of your ability to deep-dive. Or so I am claiming.
Nevertheless, I would still like to claim that kids or not is not determinative of your ability to do the deep dive.
I'd also like to think that some distance in the future, it will be raising my daughter will turn out to have been the best possible way I contributed to the world. This software stuff is, in the end, a distraction for the most part (especially when there are/were already so many options in the particular niche that Ardour occupies).
I just did 5 months between contracts. The kids were at school for 6 hours a day. It took a good few weeks for the ideas to start flowing and my curiosity and enthusiasm to build, such that I actually started writing code and enjoyed the process.
It’s something I never experienced before with regular holiday leave, where all-day childcare would usually be involved.
It’s only recently I’ve been in a financial position to be able to create free time like this. It was really expensive though, and I’m unlikely to be doing it again for a few years.
Every time I see their progress in a such undocumented space, my jaw drops. Huge respect.
> If you want to support my work, you can donate to marcan’s Asahi Linux support fund on GitHub Sponsors or Patreon, which helps me out too! And if you’re looking forward to a Vulkan driver, check out Ella’s GitHub Sponsors page!
Lina also accepts donations on her streams. I think Alyssa is funded by her employer, but I'm not sure.
> No one talks about..
Yeah, nobody cares unless something new comes out.
Alyssa also works on the drivers for ARM Mali GPUs, which currently don't even support Vulkan 1.0.
This is actually what their plan is long term. That said in the short term it's way easier to implement opengl, it gives them a simple way to explore the hardware, and it also makes it so that real people will be able to run desktop linux on apple silicon macs way sooner.
> So what does this all mean for users of the Asahi Linux reference distro today? It means… things are way faster!
> Since the Mesa driver no longer serializes GPU and CPU work, performance has improved a ton. Now we can run Xonotic at over 800 FPS, which is faster than macOS on the same hardware (M2 MacBook Air) at around 600*! This proves that open source reverse engineered GPU drivers really have the power to beat Apple’s drivers in real-world scenarios!
If you're spending money on Mac I assume you want to buy in the whole MacOS environment, that's Apple value proposition in my eyes.
Is it the M1, it that fast and better than similar priced laptops running an x86-64? Or is it the novelty of using ARM-based stuff? Is the market for ARM-based laptops still Apple only?
Also is there relevant limitation on stuff you can't do on MacOS through homebrew or something and can on a Linux distro (not a mac user so I don't know).
That's definitely part of it. You probably need to include battery life for it to really make sense. There's nothing else that will give you that performance and close to 20 hours of battery life in a slim laptop form factor.
There's also people who are mostly happy using macOS but may want to boot into Linux for specific tasks.
Yes, I think the general opinion is that Apple's M1 and M2 platforms are superior to Intel, even at the Mac's (supposedly) higher price point.
Though MacOS is a complete Unix system, it is still proprietary, and there's nothing wrong with wanting to do your work (or play) on a free OS running on an excellent hardware platform. Asahi is giving people the opportunity to do that.
Finally, though I can't speak for the Asahi team, I think also there's an element of "because it's there". Here is a great new hardware platform offering a incredibly difficult challenge to a group of people who live for this kind of thing. Why would they not want to do it?
Also is there relevant limitation on stuff you can't do on MacOS through homebrew or something and can on a Linux distro (not a mac user so I don't know).
- i3/Sway type window managers are more comfy
- Homebrew is hit or miss
- Apple seems to make the best bang-for-buck ARM laptops at the moment
- Asahi is a fine beer :)
I would buy an iDevice if I could take it home, boot it up to make sure it works then install Fedora with everything working.
Even my current laptop failed that since I wanted to play with GPU programming and I had to hunt down drivers for the the AMD APU — which I never got working 100% correctly but that was probably my buggy code, GPU programming is hard.
I tend to run the same kinds of tools on both laptops (open source ones).
The Apple software experience matters less to me these days. I spend most of my time switching between the same applications that I would use on Linux and I mostly ignore all the iApps that come with macos. Beyond finder and preview, there aren't any Apple applications that I regularly use or need. Mostly I don't care about M1 vs. Intel. I'm not a native developer and all the stuff I care about is available for both cpu architectures. I just need the OS to get out of the way and allow me to do my thing. I used the linux laptop extensively for a while when I was without a Mac last year. Works great as a daily driver.
The first is apple hardware is reliably nice. It's just done right, with minimal corners cut. Full aluminum body (not plastic), great screen (bright, high resolution, great color (accuracy and range), great keyboard, great touchpad, amazing CPU (fast and low power), very nice GPU (better than any other integrated GPU and much lower power than any faster discrete GPU), with a great memory system (100, 200, or 400GB/sec).
Sure the best laptops some close on some metrics, but generally have lousy iGPUs or lousy battery life. Laptop memory systems typically max out at 75GB/sec, which drives the need for discrete GPUs, which drives the need for larger batteries. Sadly FCC limits max batter size, so you end up with terrible battery life and performance if you aren't plugged in. Or they have are great, except for a poor screen. Or have a nice screen and a lousy keyboard or track pad.
I also find it interesting that if you try to buy a 3 or 5 year old laptop, but far the most expensive are apple laptops. Almost as if they are built better.
My second issue is I find OSX to be MUCH less intuitive. The lack of a real package manage for the OS is painful. Having to add my own, like brew is ugly. Then the UI inconsistencies drive me nuts. Even things like cut/paste (control-c/v) are annoying. Doubly so when using iterm2 where you don't need the control-c. Or if running xquartz I'd need a state diagram to map all the copy/paste rules.
Linux seems much more sane, granted I'm more familiar with it. I'm on a website and want to drag an image in, I just drag the image from any image viewer or file browser and it works. I can drop files into signal by dragging. Or documents into thunderbird as attachments. OSX seems much more finicky about dragging objects between applications, and I end up in the finder, which I find particularly counter intuitive. Oh, sure I could try to remember that bang, splat, apple A goes straight to apps. Seems that browsing from ~ should be WAY easier, or even better just have better drag/drop supports.
Linux just makes more sense to me. 99% of my installs are apt install <appname>, not playing the do I search for the web for a DMG, or try to find it in brew, crap that was a different user, or maybe I need a 3rd app store? Oh that works in a brew cask, but not a brew app, etc. etc. etc.
I also find apple's handling of multiple monitors quite annoying. I don't have anything fancy, just N desktop of 2 monitors each, with a quick keyboard combo to switch (control-alt right or control alt-left). I ask apple folks about their setup and they seem to always mention some weird paid app that worked with the N-1 version of the Apple OS, but the devel got bored and stopped updating.
If you just need Signal, Teams, chrome, Firefox, terminal, and like a nice coherent package manager, drag and drop (not select, control-c, select, control v) of strings, images, documents I'd recommend Linux. I find OSX frustrating to use.
At some point it would be good to break it and get rid of implicit sync in the Wayland use case. Keeping it forever is not worth it.
Fully support bringing a well supported Linux distro to the hardware but MacOS is nothing like ChromeOS or some sort of thin client operating system.
All the icons are jumping around everywhere, everything is colourful, it's 2023 and you can't maximize a window or make it take up half the screen, etc.
I also hate the touch bar but I'd probably get used to that. I used a pre-touchbar Air for a few months and going back to windows felt amazing.
I am eagerly waiting for Asahi to be usable as a daily driver, my next laptop will probably run Apple silicon.
Yeah, the first thing I do when I get a new Mac is to install some tools to make the experience less annoying.
AltTab: https://alt-tab-macos.netlify.app/
Rectangle: https://rectangleapp.com/
Dato: https://apps.apple.com/us/app/dato/id1470584107
Caffeine: https://www.caffeine-app.net/
Paragon NTFS Driver (free for Seagate disks): https://www.seagate.com/support/software/paragon/
--
In my own experience, I found out GNOME 40+ to be more polished UI-wise than MacOS. I was really surprised when I installed Fedora Silverblue the first time. And also I'm a bit upset that MacOS seems to have stalled, and when Apple adds changes is to make it look more and more like iOS.
Doubly so when they are closed source and free. How are the developers making the money? Are they community supported somehow, maybe patreon? Are they tracking you? Inlining ads to your desktop? Who is paying for their apple devel tools or apple store ID?
As the saying goes, if the app is free, you are the product that company is selling
Imagine supporting 100 mac users, each with 6 random binaries installed.
* no built-in package manager
* low hackability/customizability
* constant code signing prompts with 3rd party software, my OS is fighting me trying to use software
* constant prompts to please finally sign into icloud
* deprecated OpenGL
* general handholding in the OS getting in the way
How much of that work is being done in Electron?
These are a couple of volunteers, working for free, and you're saying that it'd be better for them to volunteer their time for the benefit of a huge trillion dollar corporation and work on something that the aforementioned corporation explicitly does not want (but could very easily do itself).