After the just-after-warranty-expired demise of my Thinkpad T13s - an ARM on Windows laptop - I was in the market for something that gave anywhere near the absolutely astounding battery life that I got used to, hauling it around on several flights.
Costco had an M2 MacBook Air on sale, so I cross referenced the Asahi Linux Feature Support wiki page and found out that everything except the webcam, speakers, and microphones worked at least a little bit as of late July 2023.
So I ordered it and decided to get GNOME and my primarily Go/Python/JavaScript-based development workflow running. My installation saga - detailing various solutions for core functionality, pet peeves, and various apps - begins after the break.
Full disclosure: I've installed (and accidentally destroyed) Arch Linux before, so I might be talking casually about something really complicated at various points here. Feel free to ask for clarification in the comments or whatevs.
installing the operating system
The easiest part about this was installing it! As someone that's done operating system-level corporate security for a tech giant or two, I was expecting the install process to be a SIP-fueled hellscape and never actually got one.
The installer linked from the front page of asahilinux.org is incredible. Major props to the folks who made it so, so easy to make a partition, do the bootloader nonsense, and all that jazz.
However during installation I was confronted with my first choice: do I install Asahi Linux Desktop or Asahi Linux Minimal (Arch Linux ARM)? As a Fedora and Ubuntu-when-I-really-gotta user for almost a decade, the choice was clear after I found out that the former uses KDE.
I decided to rawdog it and bootstrap GNOME from minimal.1
from a tty to "haha yes graphics"
As soon as I did the reboot dance and logged in with default root creds, I did the usual stuff: change the hostname, generate locales, rotate superuser credentials, and mint myself a user - but I needed to connect to the internet to download sudo. I tried to autocomplete some commands I knew offhand configured wifi, found wifi-menu and:
# wifi-menu
Please install 'dialog' to use wifi-menu
I got Arch Linux'd! So I connected some rando Realtek USB ethernet adapter and installed both dialog and wpa_supplicant to get wirelessly connected. For now, I'll have to type wifi-menu and go through the whole config process after every reboot.
On a lark, I bet that graphics software rendering would work so I did not install the linux-asahi-edge package just yet, which is required to bring in Lina's hottest newest GPU drivers, the process of which she livestreams. I wanted GNOME to work under the worst circumstances, just in case a change rendered the GPU temporarily unusable.
Wayland on GNOME time
One of the funniest parts about installing Arch Linux nowadays is that getting GNOME running is a very simple, one shot sudo pacman -Syu gnome && sudo systemctl enable gdm && sudo reboot.
(After you reboot you just pray that the login screen shows up so you don't have to crawl back to a tty, defeated by Arch Linux.)
So I logged in and got greeted by the new GNOME version tour and everything worked. Because this is a MacBook, my muscle memory greeted me with my first pet peeve.
My muscle memory of being on a MacBook keyboard means I pressed ⌘ + C to copy, ⌘ + W to close windows, and all of the other shortcuts, so remapping this would have to come soon after we do all of the actually necessary stuff.
One of the things to do was to run wifi-menu after reboot for the last time so that I could install and enable NetworkManager, which has tight integration with GNOME. I installed some web browsers and an AUR helper, anticipating having to do some yak shaving to make this feel as useful as a Fedora install on a normal laptop.
The default GNOME web browser, epiphany, is installed with the gnome package group and worked well enough for some cross referencing on wikis and various GitHub issues. However the display was crawling and my MacBook Air battery was diving pretty quickly from all of this high resolution software rendering, so I figured it was time to try to get GPU acceleration working.
ok but the GPU
After getting NetworkManager working, I ran pacman -Syu linux-asahi-edge mesa-asahi-edge and rebooted (I saw that GRUB reacted appropriately to the kernel change, so I skipped the grub-update step mentioned in the article).
I logged in, three finger swiped up, typed "about" and saw "Graphics: software rendering". After an initial confused panic of typing glxinfo, lspci, and dmesg - I considered that maybe my package set and the KDE Plasma distribution might have some important divergences.
I thumbed around the asahi repository's package file listings and found out that I did not have asahi-meta installed - a metapackage that brought in a whole boatload of tooling and is required for firmware updates and other kinds of shenanigans. I installed it and found out that one of the dependent packages - asashi-configs - contained the thing that I needed:
$ pacman -Ql asahi-configs
asahi-configs /etc/
asahi-configs /etc/X11/
asahi-configs /etc/X11/xorg.conf.d/
asahi-configs /etc/X11/xorg.conf.d/20-natural-scrolling.conf
asahi-configs /etc/X11/xorg.conf.d/30-modeset.conf
asahi-configs /etc/profile.d/
asahi-configs /etc/profile.d/asahi.sh
asahi-configs /etc/xdg/
asahi-configs /etc/xdg/kcminputrc
asahi-configs /etc/xdg/kwinrc
$ cat /etc/X11/xorg.conf.d/30-modeset.conf
Section "OutputClass"
Identifier "appledrm"
MatchDriver "apple"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection
Fun that it says /etc/X11 in the path but let's not think about that - I rebooted and got the screenshot used at the top of the post, Apple M2 (G14G B0) in the graphics field.
haha yes, graphics!
getting productive
Visual Studio Code
Because the IDE ship has already sailed for the entire American web stack tech industry, I ran yay -S visual-studio-code-bin, popped it open, and the visual studio code window looked like
Concerning! I then installed vscodium with yay -S vscodium-bin, noticed it had two application menu launchers, clicked one, was astounded that it worked, and saw:
$ cat /usr/share/applications/codium-wayland.desktop
[Desktop Entry]
Name=VSCodium - Wayland
Comment=Code Editing. Redefined.
GenericName=Text Editor
Exec=/usr/bin/codium --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland --unity-launch %F
[...]
Internet searching reveals that --enable-features and --ozone-platform are Chromium/Electron flags to kick binaries into rendering with Wayland properly. Looks like the GPU driver really doesn't like anything that smells of X11.
So I typed $ code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland, saw it worked, and ayy lmao just hot edited the Exec property of /usr/share/applications/code.desktop and /usr/share/applications/code-url-handler.desktop to make things work until they mysteriously stop working after I forget to edit the files after an upgrade.
⌘ muscle memory
I've used all three major operating systems for all sorts of hardware for years at various jobs, and I can tell you that getting used to not pressing the command shortcuts on Apple hardware is a very bad idea, especially if you need to type on someone else's computer.
So this really isn't a pet peeve as much as a "I don't want to screw myself over for work" thing.
To accomplish this, I tried a few utilities that mean to help with this, including kinto and toshy, but I eventually settled on remapping the ⌘ + [key] combo to Ctrl + [key] for the most part using https://github.com/samvel1024/kbct, which you can install with yay -S kbct-git.
I use this super key remapping config.yml file linked in kbct's docs. I did the Copy key remapping thing mentioned for gnome-terminal; this is fine for me because the three applications that get the most screen time for me on Linux are the web browsers, gnome-terminal, and Visual Studio Code.
There are a few other shortcuts to define in GNOME itself, like ⌘ + shift + 3 to take a screenshot, but I personally feel like those are things you just kinda do on the spot after you realize it didn't work.
The kbct solution here obviously isn't completely consistent with how macOS works of course, but it is enough for me personally to call it... mitigated? I really don't type anything more complicated than ⌘ + [single key] most of the time.
vivaldi
For the first couple days I used Firefox, but my web browser of choice is Vivaldi; I was a diehard Opera user. However, the package for Vivaldi is just x86 only by default.
So I cloned a copy, changed the rpm to be aarch64, appended --enable-features [] --ozone-platform=[] to the thing and it all Just Works!
However because patching these additional flags into the .desktop file is not a particularly sustainable move and the package is only in Arch Linux proper, I'm not going to try to upstream this package into Arch Linux ARM just yet.2
Go, Python, and JavaScript toolchains
No notes, just do exactly what you would've done.
You'll run into essentially the same problems everyone does with ARM hardware: so macOS users, Raspberry Pi folks, and tech giants using ARM64 CICD pipelines will likely front run most of the problems you will otherwise experience.
Enjoy the really fast compile times!
my TODO list
- chase up getting
dialogpreinstalled installed in the minimal distribution because wifi-menu needs it - chase up aarch64 in the Vivaldi PKGBUILDs
- figure out what to do about these Wayland flags for Electron and Chromium in a hopefully permanent manner
- figure out cross-platform OCI container builds
A followup post will cover this and other things as I maybe start using this as a daily driver laptop for a while. At least for now, this shit slaps! Year of Linux on the Apple Laptop.
-
Obviously installing Linux and then GNOME immediately destroys any prospect of incredible battery saving but listen, let me live my life
-
Yes, I already know about
chromium://flags/#ozone-platform-hint, but vscode and the other Electron apps need the same flag set. Maybe an alpm hook would work...