Alles begann diesen Monat im letzten Jahr
Im März 2022 wurde die Alpha-Version für Asahi bereitgestellt und ich habe sie sofort auf einem Mac Mini mit einem Apple Silicon (ARM64) M1-Prozessor mit 8 Kernen installiert. Asahi ist eine Linux-Distribution, die nativ auf Apple Silicon-basierten Macs ausgeführt werden kann, da einige Mitglieder der Open-Source-Community ein raffiniertes Reverse Engineering zur Verfügung gestellt haben. Darüber hinaus ist die Ausführung von Asahi vollkommen legal, da Apple formell das Booten von Nicht-macOS-Betriebssystemen auf seiner Apple Silicon-Plattform erlaubt.
Und obwohl Asahi zu dieser Zeit nicht alle Mac Mini-Hardwarekomponenten unterstützte, waren die wesentlichen Hardwaretreiber verfügbar, und ich war überrascht, wie schnell das System war. Nachdem ich gelernt hatte, dass ich alle Software installieren konnte, die ich brauchte, wurde sie schnell zu meinem täglichen Treiber, wie ich in meinem Blogbeitrag vom Juli ausführlich beschrieben habe. Bis Dezember waren Treiber für die gesamte verbleibende Hardware (Bluetooth, Audio, GPU) verfügbar, und alle von mir gewünschten Open-Source-Pakete wurden aktualisiert, um die für Apple Silicon erforderliche Seitengröße von 16 KB zu unterstützen.
An diesem Punkt dachte ich mir: „Was wäre, wenn ich Asahi Linux nativ auf Apples schnellstem Apple Silicon Mac ausführen könnte? Das wäre die ultimative ARM64-Linux-Workstation. Und ich möchte auf jeden Fall die ultimative ARM64-Linux-Workstation betreiben.“
Also habe ich die Dinge auf die nächste Ebene gebracht
Diesen Januar habe ich Asahi Linux auf Apples leistungsstärkstem ARM64-System installiert: dem Mac Studio mit einem M1 Ultra-Prozessor mit 20 Kernen und 128 GB RAM. Es ist über HDMI mit einem atemberaubenden gebogenen 34-Zoll-Breitbild-Monitor von Dell gekoppelt.
Gleichzeitig beschloss ich, dass es an der Zeit war, vom mächtigen i3-Window-Manager (der auf dem alten X-Window-System laufen muss) auf den Sway-Compositor zu migrieren, der auf dem neuen Wayland-Window-System läuft. Das war viel einfacher, als ich erwartet hatte – Sway ist leistungsfähiger und verwendet im Vergleich zu i3 eine optimiertere Konfiguration.
Unten ist ein hochauflösender Screenshot meines Sway-Desktops auf dem Mac Studio (klicken Sie mit der rechten Maustaste auf das Bild und öffnen Sie es in einem neuen Browser-Tab, wenn Sie es einfach vergrößern möchten). Sie können meine benutzerdefinierte Sway-Dotfiles-Konfiguration finden in diesem GitHub-Repo.
Gibt es etwas, das nicht funktioniert?
Um Hamlet zu zitieren, Akt 3, Szene 3, Zeile 87: „Nein.“
Alles funktioniert… und funktioniert perfekt. Die gesamte Hardware (Bluetooth, Audio, HDMI, USB, 10G-Ethernet, WLAN und GPU) funktioniert einwandfrei mit den vom Asahi-Team im vergangenen Jahr erstellten Treibern, und es gibt keine einzige Software, die ich möchte oder brauche, die dies tut läuft in Asahi auf diesem System nicht gut.
Die meisten Softwarepakete, die ich installiert habe, stammen aus dem Arch User Repository (da Asahi auf Arch basiert), aber einige davon sind als Flatpak-Sandboxes installiert (z. B. Visual Studio Code). Für kompliziertere Softwaresysteme besorge ich mir oft fertige Container-Images und betreibe sie als Container (z. B. meine NextCloud-Instanz). Sie werden auch von der beachten htop gibt in meinem Screenshot aus, dass ich einen K3s-Cluster zum Testen der von mir entwickelten Microservices betreibe.
Da die meisten meiner Workloads containerisiert sind, muss ich keine anderen virtuellen Linux-Maschinen ausführen. Allerdings muss ich mehrere Web-Apps unterstützen, die in BSD-Gefängnissen laufen. Dazu habe ich eine dedizierte virtuelle QEMU-Maschine von FreeBSD UNIX installiert, die 8 Kerne und 64 GB RAM verwendet. Unten sehen Sie ein Bild der Konsole der virtuellen Maschine, die in einem Terminal auf meinem Sway-Desktop ausgeführt wird. Sie können mein QEMU-Skript finden in diesem GitHub-Repo.
Dies ist bei weitem der schnellste Linux-Desktop, den ich je benutzt habe.
Alles – und ich meine wirklich alles – geht unglaublich schnell. Die Dinge laufen sofort und App-Begrüßungsbildschirme scheinen nicht zu existieren.
In einigen Fällen ist es zu schnell. Als ich K3s installierte, traten alle Container im kube-system-Namespace immer wieder in den gefürchteten CrashLoopBackOff-Zustand ein (etwas, das ich noch nie zuvor außerhalb eines Produktionscontainers gesehen habe). Nach einigen Nachforschungen fand ich heraus, dass das Mac Studio einfach zu schnell für das Kubernetes-Ressourcen-Timing war, und ich musste jedem Pod Ressourcenbegrenzungen hinzufügen, um das Problem zu beheben.
Einer der Hauptgründe, warum ich gerne auf Linux/ARM64 entwickle, ist, dass es zu meiner außerschulischen Entwicklung passt. Das Startup, mit dem ich derzeit arbeite, verwendet eine rechenintensive Microservice-basierte App, die normalerweise in einer AWS c6g.12xlarge Graviton-Instanz mit 48 ARM64-Kernen ausgeführt wird. Die App ist so schwer, dass wir unsere eigenen Lastsimulations- und Leistungsüberwachungs-Microservices in die App selbst eingebaut haben (unser Service Mesh hilft auch dabei).
Also stellte ich die App auf meinem Mac Studio bereit, auf dem Asahi lief, und führte die Ladesimulation durch, um zu sehen, wie sie mit unserer Staging-Umgebung auf AWS abschneidet. Das Mac Studio hat die Graviton-Instanz aus dem Wasser gesprengt. Die Latenz bei gleicher Last war im Durchschnitt etwa 20 % niedriger, und die Berechnung war in unserem Spitzenwert konstant genau 36 % schneller. I/O war schwieriger zu überwachen und zu interpretieren, aber meiner Meinung nach war es insgesamt nicht wesentlich anders.
Es ist wirklich die ultimative ARM64-Linux-Workstation. Und ich liebe es, es zu benutzen.
