@ngompa filed Fedora-Council/tickets ticket #432. Discuss here and record votes and decisions in the ticket.
1 Like
From the presentation, I gathered that there might be some non-redistributable firmware as well?
It is true that there’s non-redistributable firmware, but we gather it at boot time from the device itself and load it into the OS. I wrote the dracut module to do this. It is packaged as dracut-asahi in Fedora.
So we don’t have to deal with it from a Fedora context. It also means Wi-Fi works out of the box. 
2 Likes
From talking with Neal and Eric after the FOSDEM talk, it seems like this is really close to not needing to be remix — there are a few forked packages, and it’s better with a replacement kernel from COPR, but it should be able to have this just be Fedora software.
What’s more, I think having the spin separate is a good way to indicate to people that it’s still a special case, and set expectations properly.
I propose:
- The Fedora Asahi spin should use Fedora Remix terminology (and put the Remix logo[1] somewhere prominent until those things are done).
- I need to talk to legal, but I’d like to allow “Fedora Asahi Remix”. My concern is that we don’t want to open up non-Fedora-associated “Fedora ____ Remix” — instead, that should be “_____ Fedora Remix”, or “_____, a Fedora Remix”. [2]
- We allow a special exception, granting the right to use the Fedora logo in the image (and there should be notice somewhere reasonably-prominent on the project’s web page explaining the special permission.
- When the not-Fedora-software issues are resolved, I’m in favor of a Fedora Asahi spin (again, because I think having it separate helps call attention).
- Eventually of course, everything should just work.
I’d like all of this to apply to the Fedora RISC-V images out there, too, and other similar things – efforts we need some distance from, but which we’d like to experiment with.
I’m open to the idea of some other label[3], but we’re bad at names, so I think probably keeping to Remix is best.
From talking with Neal and Eric after the FOSDEM talk, it seems like this is really close to not needing to be remix — there are a few forked packages, and it’s better with a replacement kernel from COPR, but it should be able to have this just be Fedora software.
So, for context, here’s what the Asahi-specific packages are:
- m1n1, the stage 1 bootloader, which is maintained in Fedora proper
- u-boot, the stage 2 bootloader, has basic support in Fedora already but isn’t terribly usable as-is at this time; our fork includes additional enablement patches that are in the process of being upstreamed
- asahi-scripts, the early boot integration for firmware loading and other enablement logic; this is maintained in Fedora proper as well
- alsa-ucm-asahi, a helper package for audio enablement, also maintained in Fedora proper
- mesa, which we maintain a fork of for GPU enablement; this is in active development and is moving very quickly, but it will all be eventually upstreamed
- finally, the kernel in Fedora has basic Apple Silicon support, and we expect this to improve going forward as enablement is merged upstream; however, because it’s built with 4k pages it lacks support for a PCIe and USB devices (including the GPU) and has a significant performance penalty; while the hardware support issue is theoretically fixable, the performance penalty isn’t, and running 4k pages on this hardware is unlikely to ever provide an optimal experience; our fork includes additional hardware enablement patches that are in the process of being upstreamed and is built with 16k pages (which is the native page size of this platform)
The other main deviation from stock Fedora is the use of the Asahi Installer for deployment, which takes care of grabbing the necessary non-free firmware from macOS, repartitioning, laying our Fedora image on disk and registering the OS with the Apple bootloader. Note that this installs a prebuilt image that boots to gnome-initial-setup – at this point in time we can’t use Anaconda for safety reasons, among others.
All of this is to say – getting this hardware supported in stock Fedora is definitely a goal we’re striving for, but the road ahead is long and I expect the Remix will provide the better experience for users in the near to medium term. And assuming Apple continues to release hardware, we’re likely to always have a long tail of support, so the Remix will likely provide a platform for integration and experimentation even after stock Fedora provides a good experience.
I propose:
- The Fedora Asahi spin should use Fedora Remix terminology (and put the Remix logo[1] somewhere prominent until those things are done).
- I need to talk to legal, but I’d like to allow “Fedora Asahi Remix”. My concern is that we don’t want to open up non-Fedora-associated “Fedora ____ Remix” — instead, that should be “_____ Fedora Remix”, or “_____, a Fedora Remix”. [2]
- We allow a special exception, granting the right to use the Fedora logo in the image (and there should be notice somewhere reasonably-prominent on the project’s web page explaining the special permission.
- When the not-Fedora-software issues are resolved, I’m in favor of a Fedora Asahi spin (again, because I think having it separate helps call attention).
- Eventually of course, everything should just work.
You’re using both “spin” and “Remix” here, which is a bit confusing. I don’t have strong feelings about the name, though it makes sense for “Asahi” to be in there as that’s what this ecosystem and its development community is known as. Our request is mostly about having to avoid maintaining separate branding for the deliverables, which allows us to spend more time on the upstream integration work.
Related to this, @ngompa reminded me today we don’t currently have SVG artwork for the Remix logos, which is a problem is we want Remixes to actually comply with the policy. See Update Fedora's Secondary Mark ("Fedora Remix") to match our new logo (#1) · Issues · fedora / Design / Fedora Design / Logos and Branding / Misc logos · GitLab for specifics (cc @duffy). Right now we’re using placeholders in our branding package as a workaround, but that’s obviously not ideal.
@duffy and I are working on this. SVG logos will be available from Fedora brand standards, logo download, and usage :: Fedora Docs
2 Likes
+1 for granting the Fedora Remix trademark usage with the infinity logo.
Good point. I will rephrase. I also haven’t had a chance to talk to trademark lawyers about the naming concerns. @ngompa, did you talk to Asahi about whether they’re ok with “Fedora Asahi” in some form? Do they have a preferred way to say it?
No particular preference from the Asahi side. Fedora is already the first distro to package our stuff upstream AFAIK and the spin will be the first distro spin backed by actual distro developers we have, so we’re pretty free to come up with the standard, if any. Personally I’m happy using whatever remix/spin/etc terminology each distro uses for other purposes, to make things easier for everyone. On our side, we’ll just list the OS images under that name, and it’s no problem if that winds up with naming scheme variety. So “Fedora Asahi”, “Fedora Asahi Remix”, etc. all work.
I imagine when we’re at the point where we’re usefully shipping and recommending plain upstream Fedora images (just repackaged for our installer but otherwise standard, including kernel etc.), that would just be “Fedora”, no Asahi branding necessary. At that point you could also just use the plain UEFI environment option in the installer, and then boot a vanilla Fedora USB installer on it (OpenBSD already does it this way, but they’re way faster at upstreaming things than Linux).
I do want to put out a press release when this is all ready (and hopefully coincident with a bunch of new hardware/driver support that’s all coming together), perhaps in a couple months or so, and I’d be very happy to coordinate to make sure we get the wording right 
Also I’m not sure if Neal mentioned this, but I do want to have KDE images available (both due to personal preference and because I’ve found it much easier to work with KDE developers to get stuff working well on these machines upstream). Not sure if that will complicate things, being two dimensions of spin?
This part will be fine, as I’m the active KDE SIG co-chair and I’m putting in the work to make this work to offer Fedora KDE for our Asahi variant.
Fedora Workstation is the one that’s in trouble since WebKitGTK is broken for M2, and that causes GNOME to crash and burn horribly. But you already knew that and was planning to work on it.
Ideally, Fedora GNOME and Fedora KDE will be offered initially. Our flagship is currently planned to be Fedora Asahi KDE because it works on everything right now.
I am looking for to install Fedora to M1 Apple hardware.
Today I just got my hand on the M1 MacAir - and the installer to install Asahi Desktop works very well. And in less than 30 minutes, Asahi is up and running.
I have a USB dock, the LAN port only has about 700-800 Mbit/s of iperf3 score with Mac and WindowsOnArm64 . With Fedora and Asahi, it reached 945 Mbit/s . For WIFI, the result at Asahi is the same as under macOS.
Well done, and looking forward to test Fedora on that machine.
2 Likes