Posts by marcan

We take Asahi Linux alpha for a spin on an M1 Mac Mini

Re: 53GB

It's not 53GB, it's 18GB for a full install (that still leaves 5GB or so free, and includes the full Plasma application suite). The 53GB is because *macOS* needs something like 30+GB free for system upgrades not to break. We don't want people to shoot themselves in the foot, so the installer asks for that much extra slack by default, and won't let you resize macOS tighter than that. So 53GB free before the install, and 38GB free after the install, giving Linux 18GB. You can bypass that safety check in expert mode if you really want to.

We're just trying to avoid getting people stuck so tight that they can't upgrade macOS, especially folks who intend to just use Linux and want to make the macOS partition as small as possible - if you shrink it so much you can never actually free up enough storage for an upgrade to go through, you're kind of screwed and defeating the purpose of leaving a macOS partition in the first place (which, right now, is largely for firmware updates and other things we don't handle from Linux yet, but will in the future).

On resolutions

Linux in the alpha currently relies on the boot-time framebuffer, meaning there is no support for switching resolutions, VSync, hot-plugging, or anything like that. We have a driver for that (DCP), and it will be merged and released soonish, but first it needs a bit of clean-up and making sure it works on all the laptops too. That will make monitors work as you'd expect, with resolution switching and scaling and VSync and standby mode and all that jazz (and brightness control on the laptops). And as soon as the physical bits to switch the Type C ports to DisplayPort mode are ready (which is also being worked on as we speak), that will enable multi-monitor too.

The black screen you saw is probably because our bootloader (m1n1) failed to initialize video on the first boot. This is something we've seen happen; some monitors are temperamental and will do a reconnect cycle, and it's not clear why this happens (the internal DisplayPort-to-HDMI converter chip is probably also partially to blame). But the bootloader needs to kick off the screen and it needs to stick unattended, since at that point there's no real driver to handle hotplugging and all that. This is something that also affected Apple's bootloader (iBoot); it relies on the same interface to initialize monitors and what Apple put together is... quite primitive. Then in 12.0 Apple disabled that feature on the Mac Mini and they provide *no* boot-time display so now we have to use the same interface and take a guess as to what the best approach is. m1n1 is better than iBoot was with some monitors, and worse with others. We could make it more reliable, forcing it to wait several seconds for the output to stabilize, at the expense of increasing boot times for everyone... The good news is none of that matters once the Linux DCP driver loads, so the worst that an unreliable bootloader display will do is that your screen will sometimes stay black during the boot process until the real driver loads. Not great, but not a showstopper. But until DCP is in, yeah, a broken boot display means no display until you reboot.

We'll still take a stab at poking around and seeing if we can make it more reliable. It might come down to giving users a "flaky boot display mode" option on install, something where they can add 5 seconds to the boot process in exchange for handling these weird situations better.

Fun fact: when a display is not connected or just by default since 12.0, iBoot initializes a fake display mode that has the screen resolution of the iPhone 5.

Asahi Linux devs merge effort to run Linux on Apple M1 silicon into kernel

Re: A nice idea

The final end-user installer for Asahi Linux will be something like "hold down the power button, select Options, open a terminal from the menu, type 'curl https://alx.sh | sh' and follow the prompts."

That installer will happen once the actual drivers are working well enough, until then there isn't much point ;)

Asahi's plan for Linux on Apple's new silicon shows Cupertino has gone back to basics with iOS booting

Re: Serious questions

1. Installing another OS does not void the warranty. Every Mac, past and present, has officially supported installing a third-party OS. Apple Silicon is no exception.

2. Apple Silicon Macs natively support multi-boot. You can install as many instances of macOS as you care to partition your disk for, officially, and switch between them by holding down the power button at startup. Installing Linux instead is an analogous process. Our end-user installer will do the repartitioning for you (probably better than Apple's GUI-based Disk Utility, which is flaky :-) ), once it is ready. Our dev guide already tells you how to do it manually, and I have been dual-booting all my M1 machines from the beginning.

Boot Camp isn't what you think it is. It is not an "other OS" feature. The first Boot Camp was a CSM module (BIOS compatibility) for the Mac EFI firmware, to make old versions of Windows work (which were not fully UEFI compatible), plus a GUI-based install assistant. Modern Macs no longer include CSM, and modern versions of Windows (and Linux) are fully UEFI-compatible. Nothing called "Boot Camp" is required to install Windows (or Linux) on a modern Intel Mac - the "Boot Camp" tool is just a stupid install assistant you can ignore. They are just UEFI machines. You plug in a USB stick with a Windows installer, add the Mac drivers, and just install it. Same for Linux. There is no it "not being fond" of anything; those Macs will boot any random UEFI executable placed in the standard path on any attached storage device's UEFI System Partition. Just like any PC. I am writing this comment on an iMac Retina 2015 running Linux. From a third-party NVMe drive even; the UEFI supports those fine if you plug it in via an adaptor. All this weird "Macs are special" mythology seems to come from slightly quirky/proprietary devices and hardware features that somehow people construct to be "Apple not liking third party software". What it actually is is Apple not *caring* about breaking compatibility with third-party software; when they put in the effort to support it (Windows Boot Camp drivers) it works, when they don't someone else can do it (Linux Intel Mac-specific drivers, and everything we're doing for M1). The whole point of our project is we are doing exactly this for M1 Macs, so they *will* work well. It doesn't matter what Apple does :-)

3. Linux (and Windows) *already* run in a VM just fine (under qemu; not sure why everyone is waiting for VMWare and Parallels when open source tools already work - google "mac getutm"), but Linux in a VM will never have the performance of Linux on bare-metal hardware (e.g. native accelerated graphics). In fact, Linux on a VM on *macOS* is slower than it needs to be, because Apple do not use the M1's virtual GIC support, so their Hypervisor.framework (which all third-party virtualization apps are required to use) has a larger performance overhead emulating interrupts. Linux VMs running on Linux will quite likely benchmark faster than Linux VMs running on macOS on these machines, because yes, we already support some M1 features that Apple themselves don't :-)

4. Apple will iterate on their hardware and firmware just like they always have, and we will iterate with them. Some parts of the M1 hardware that we are reverse engineering have been unchanged since the iPhone 2G; some parts even came from PASemi chips, as I mentioned in the article. M2 is almost certainly going to be 90% identical to M1; in fact, those M1X leaks look like it's largely the same thing with another CPU core cluster tacked on and twice the GPU cores. Some chip generations will require more forward-porting effort than others, e.g. when they make a generational change to the GPU, but many won't. Apple don't go changing things up for no reason or just to spite third-party developers; all these changes are things *they* also need to support, and so they only do them when there is a good reason. I bet for a good fraction of Apple's silicon iterations, once we have the M1 baseline well covered, full support will take on the order of weeks, even perhaps a day or two in some lucky cases (just adjusting device trees, pulling out chicken bits, and perhaps a small handful of patches to fix things up - in some cases zero Linux kernel patches might be needed, just a few changes to our bootloader). A new GPU ISA will push the timeline to months, but they aren't going to do that every year, and that's just about the worst possible case.