5 ms·
Our project's goal is not to produce an "unsupported hack", it's to make these machines work at least as good as, if not better than, any other machine with "ac
by marcan_42 5y ago
Our project's goal is not to produce an "unsupported hack", it's to make these machines work at least as good as, if not better than, any other machine with "actual Linux support" ;-)
- butterisgood 5y agoAll I can say is I wish you luck!
- nextos 5y agoThat's cool. Some Macs rank near the top in terms of Linux support and openness. E.g., the MacBook 2,1 is one of the very few laptops supported by Libreboot. Others are totally unusable. I like Apple hardware (and ThinkPads), but I prefer the openness of Linux (and BSD). Current MacBook Airs are pretty competitive in terms of price, and the fanless CPU is very appealing. Is it much of a gamble to purchase one now expecting to run mainline Linux in a year or so? Aside from the new architecture, some components Apple has been using are quite unfriendly. Broadcom wireless cards tend to perform really poorly with open source drivers.
- marcan_42 5y agoThe Broadcom fullmac cards should be well supported in Linux. I've seen people complain about poor WiFi range and the like on other Macs, but that is almost certainly caused by wrong/mismatched firmware and NvRAM distributed with linux-firmware for those machines. We're going to be using Apple's blobs exactly the same way macOS does, which are tuned to each specific machine and module variant, so radio performance should be identical to macOS. I wouldn't buy an M1 right now... just because the next generation is likely around the corner :-). But yes, I can't promise all the polish or that every single thing will be upstream, but things should be solidly in the "daily driver" category a year from now. I'd be surprised if there was any non-optional (i.e. excluding accelerators - no idea if anyone cares about the Neural Engine yet...) hardware left without usable support by then. GPU is a big question mark that should become clear in the next month or two as I poke at the kernel side, but honestly I expect solid OpenGL a year from now, at the very least.
- my123 5y agoFor the user-mode part of the neural engine, https://github.com/geohot/tinygrad/tree/master/accel/ane https://github.com/geohot/tinygrad/tree/master/accel/ane helps quite a bit today. There is also no generic neural engine support infrastructure at all in user-mode on Linux. :-( For the kernel mode part, ANE is behind an ASC.
- marcan_42 5y agoIt's really just a matter of someone caring. I don't see finding myself with enough time to work on that any time soon, but if someone has a good use case for it and motivation to get it done I'm sure it'll happen (and I'll gladly help). Some things are dodgier - e.g. though supporting the AMX CPU extensions is quite viable in a kernel fork, I'm not sure if that kind of thing would fly upstream. Same with security features like SPRR - not likely to happen. But these aren't really things the average end user has to care about; they're bonus features, not anything core.
- setpatchaddress 5y agoJust curious: if someone was inclined to build a set of good (correct style, well-documented, etc) patches to support those extensions, why would the kernel refuse them? (Put another way: I'm wondering whether you think the difficulty is technical or political.)
- marcan_42 5y agoIt's a bit of both. It basically boils down to it being an invasive change to core kernel code that doesn't have demonstrable benefit to users, and is specific to one platform. If we can point at a specific application and say "look, this speeds up 300% with AMX" then that might help convince people, but there would definitely be quite some political discussion, not in the least because what Apple did is a violation of the architecture. I'm hoping we can at least push through a prctl to turn on TSO mode for x86 emulation. I think that one will be simple enough and have enough benefits to convince people.
- techrat 5y agoAn admirable goal. Except this is Apple you're dealing with. Since they provide zero means or support for other OS compatibility... so even if you still get everything running as it should, it's still an unsupported (by Apple) hack (due to lack of Apple's code and documentation). Compare this to where people make a LineageOS release for their mobile device. Still unsupported by the manufacturer, but GPL requirements often mean there's still device code to work with, if not at least the device ROM being released that images can be used to boot another OS. Apple is still one of the only hardware companies who have gone out of their way to prevent Linux from being run on their hardware. As such, I cannot see why open source advocates would continue to try to get any distro running on Apple hardware, the allure of their devices be damned.
- marcan_42 5y agoApple spent countless development hours writing an entire BootPolicy framework to allow other OSes (and self-built macOS kernels) to run on these machines. Not only that, their secureboot implementation implements per-OS security modes, which means you can dual boot Linux with a full secure macOS, including running iOS apps and Netflix in 4K. Can't do that with LineageOS! Linux on M1 Macs is "supported" exactly the same as Linux on any random PC without manufacturer support. Sure, it's more work to get running, because it's a new undocumented platform... but we've signed up to do the work. If Linux on these machines is an "unsupported hack" then so is Linux on the vast majority of desktop/laptop computers people use.
- techrat 5y ago> Linux on Macs is "supported" exactly the same as Linux on any random PC without manufacturer support. Bullshit. Intel and AMD both contribute to the Linux kernel to have their hardware, CPUs and GPUs both, supported. Show me Apple's commits for supporting the M1 within the kernel and we'll talk. Until then, in this situation where you're trying to get Asahi Linux running for the M1, it is not exactly the same.
- marcan_42 5y ago