Tout a commencé ce mois-ci l’année dernière
En mars 2022, la version alpha d’Asahi a été mise à disposition et je l’ai immédiatement installée sur un Mac Mini avec un processeur Apple Silicon (ARM64) M1 à 8 cœurs. Asahi est une distribution Linux qui peut s’exécuter en mode natif sur les Mac basés sur Apple Silicon grâce à une ingénierie inverse astucieuse fournie par les membres de la communauté open source. De plus, l’exécution d’Asahi est parfaitement légale car Apple autorise formellement le démarrage de systèmes d’exploitation autres que macOS sur leur plate-forme Apple Silicon.
Et bien qu’Asahi ne prenne pas en charge tous les composants matériels du Mac Mini à l’époque, les pilotes matériels essentiels étaient disponibles, et j’ai été surpris par la rapidité du système. Après avoir appris que je pouvais installer tous les logiciels dont j’avais besoin, c’est rapidement devenu mon pilote quotidien comme je l’ai détaillé dans mon article de blog de juillet. En décembre, les pilotes étaient disponibles pour tout le matériel restant (Bluetooth, audio, GPU), et tous les packages open source que je souhaitais ont été mis à jour pour prendre en charge la taille de page de 16K nécessaire pour Apple Silicon.
C’est à ce moment-là que je me suis dit : « Et si je pouvais exécuter Asahi Linux en mode natif sur le Apple Silicon Mac le plus rapide d’Apple ? Ce serait la station de travail Linux ARM64 ultime. Et je veux absolument exécuter la station de travail Linux ARM64 ultime.
Alors j’ai pris les choses au niveau suivant
En janvier dernier, j’ai installé Asahi Linux sur le système ARM64 le plus puissant d’Apple : le Mac Studio avec un processeur M1 Ultra à 20 cœurs et 128 Go de RAM. Il est associé à un superbe moniteur incurvé à écran large Dell de 34 pouces via HDMI.
En même temps, j’ai décidé qu’il était temps de migrer du puissant gestionnaire de fenêtres i3 (qui doit fonctionner sur l’ancien système X Window) vers le compositeur Sway qui s’exécute sur le nouveau système de fenêtres Wayland. C’était beaucoup plus facile que prévu – le balancement fonctionne mieux et utilise une configuration plus simplifiée par rapport à i3.
Vous trouverez ci-dessous une capture d’écran haute résolution de mon bureau Sway sur Mac Studio (cliquez avec le bouton droit sur l’image et choisissez de l’ouvrir dans un nouvel onglet de navigateur si vous souhaitez effectuer un zoom avant facilement). Vous pouvez trouver ma configuration personnalisée de fichiers de points sway dans ce dépôt GitHub.
Y a-t-il quelque chose qui ne fonctionne pas ?
Pour citer Hamlet, Acte 3, Scène 3, Ligne 87 : « Non ».
Tout fonctionne… et fonctionne parfaitement. Tout le matériel (Bluetooth, audio, HDMI, USB, Ethernet 10G, WiFi et GPU) fonctionne parfaitement avec les pilotes créés par l’équipe Asahi l’année dernière, et il n’y a pas un seul logiciel que je veux ou dont j’ai besoin. ne fonctionne pas magnifiquement dans Asahi sur ce système.
La plupart des packages logiciels que j’ai installés proviennent du référentiel d’utilisateurs Arch (puisque Asahi est basé sur Arch), mais certains d’entre eux sont installés en tant que bacs à sable Flatpak (par exemple, Visual Studio Code). Pour les systèmes logiciels plus complexes, j’obtiens souvent des images de conteneurs prêtes à l’emploi et je les exécute en tant que conteneurs (par exemple, mon instance NextCloud). Vous noterez également de la htop sortie dans ma capture d’écran que j’exécute un cluster K3s pour tester les microservices que je développe.
Étant donné que la plupart de mes charges de travail sont conteneurisées, je n’ai pas besoin d’exécuter d’autres machines virtuelles Linux. Cependant, je dois prendre en charge plusieurs applications Web qui s’exécutent dans les prisons BSD. Pour cela, j’ai installé une machine virtuelle QEMU dédiée de FreeBSD UNIX qui utilise 8 cœurs et 64 Go de RAM. Vous trouverez ci-dessous une image de la console de la machine virtuelle exécutée dans un terminal de mon bureau Sway. Vous pouvez trouver mon script QEMU dans ce dépôt GitHub.
C’est de loin le bureau Linux le plus rapide que j’ai jamais utilisé.
Tout – et je veux dire tout – est incroyablement rapide. Les choses fonctionnent instantanément et les écrans de démarrage des applications ne semblent pas exister.
Dans certains cas, c’est trop rapide. Lorsque j’ai installé K3, tous les conteneurs de l’espace de noms kube-system continuaient d’entrer dans l’état redouté CrashLoopBackOff (quelque chose que je n’avais jamais vu auparavant en dehors d’un conteneur de production). Après quelques recherches, j’ai découvert que Mac Studio était tout simplement trop rapide pour le timing des ressources de Kubernetes, et j’ai dû ajouter des limites de ressources à chaque pod pour remédier à la situation.
L’une des principales raisons pour lesquelles j’aime développer sur Linux/ARM64 est que cela correspond à mon développement parascolaire. La startup avec laquelle je travaille actuellement utilise une application basée sur des microservices lourds de calcul qui s’exécute généralement dans une instance AWS c6g.12xlarge Graviton avec 48 cœurs ARM64. L’application est si lourde que nous avons intégré nos propres microservices de simulation de charge et de surveillance des performances dans l’application elle-même (notre maillage de services y contribue également).
J’ai donc mis en scène l’application sur mon Mac Studio exécutant Asahi et exécuté la simulation de charge pour voir comment elle fonctionnait avec notre environnement de mise en scène sur AWS. Le Mac Studio a fait sauter l’instance de Graviton hors de l’eau. La latence à la même charge était environ 20 % inférieure en moyenne et le calcul à notre pic était exactement 36 % plus rapide de manière constante. Les E/S étaient plus difficiles à surveiller et à interpréter, mais à mon avis, ce n’était pas significativement différent dans l’ensemble.
C’est vraiment la station de travail Linux ARM64 ultime. Et j’adore l’utiliser.
