Asahi-Linux-Fortschrittsbericht Linux 7.0

 (asahilinux.org)
1 Punkte von GN⁺ 3 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Linux-Unterstützung für Apple Silicon macht gleichzeitig in mehreren Bereichen Fortschritte: Automatisierung des Installers, Energieverwaltung, Audio, Display und bis hin zur Aktivierung von M3
  • Der Asahi Installer wurde so umgestellt, dass Image-Manifeste von der Codebasis getrennt sind, und nutzt nun GitHub-Workflow-Deployment, wodurch häufigere Aktualisierungen möglich werden; in 0.8.0 kamen ein Update von m1n1 stage 1, Unterstützung für die Installation auf dem Mac Pro und ein Firmware-Update-Modus hinzu
  • Die ALS-Kalibrierungs-Firmware kann aus macOS extrahiert und auch nach der Installation erneut aktualisiert werden, Bluetooth-Audio-Aussetzer verschwanden dank Unterstützung für Broadcom-Coexistence-Befehle, und die PMP-Unterstützung senkt auf dem M1 Pro die Idle-Leistungsaufnahme um etwa 0,5 W
  • VRR-Unterstützung wird wegen Apple-DCP-Einschränkungen derzeit noch nicht korrekt an den Userspace durchgereicht, kann aber nach dem Merge des Pull Requests per Kernel-Modulparameter erzwungen aktiviert werden; durch Upstream-Arbeiten am Audio-Stack kamen außerdem eine generische API für Bus Keeper sowie zusätzliche Sample-Rates für den CS42L84 hinzu
  • Der M3-Unterstützungsumfang wurde auf PCIe, Eingabegeräte, RTC, Reboot-Controller und NVMe erweitert, und Fedora Asahi Remix 44 hält den Release-Termin rund um Fedora 44 zusammen mit einem neuen Plasma-basierten Installationsablauf ein

Automatisierung des Installers und Firmware-Aktualisierung

  • Der Asahi Installer, der fast zwei Jahre lang nur selten aktualisiert wurde, hatte wegen eines manuellen Release-Verfahrens und der Abhängigkeit von CDN-Administratorrechten lange Update-Zyklen, außerdem hatten sich seit dem Tag von Juni 2024 viele Änderungen angesammelt
  • Bei einer rein UEFI-basierten Installation werden nur m1n1 stage 1, Devicetree und U-Boot installiert; wenn der Devicetree im Installer-Bundle nicht zu den Erwartungen des Kernels passt, wird bereits der Bootvorgang selbst blockiert
    • Während der Upstream-Arbeit änderten sich Devicetree-Bindings, wodurch sich Inkonsistenzen ansammelten, und in Kernel 6.18 gab es viele Apple-USB-bezogene Änderungen, sodass sich Live-Medien nicht mehr mit 6.18 oder neuer booten ließen
  • Das Manifest installierbarer Images wurde nach asahi-installer-data ausgelagert, sodass es unabhängig von der Codebasis des Installers aktualisiert werden kann
  • Das Deployment von asahi-installer wird nun automatisch per GitHub-Workflow durchgeführt
    • Pushes auf den Branch main werden automatisch gebaut und nach https://alx.sh/dev hochgeladen
    • Pushes von GitHub-Tags werden automatisch nach https://alx.sh ausgerollt
  • Die aktuelle Version 0.8.0 hebt das mitgelieferte m1n1 stage 1 auf 1.5.2 an und ergänzt Unterstützung für die Installation auf dem Mac Pro sowie einen Firmware-Update-Modus

ALS und Firmware-Extraktion

  • In Apples True-Tone-Umgebung muss nicht nur die Umgebungshelligkeit, sondern auch die Farbcharakteristik des Lichts gemessen werden, weshalb die ALS-Datenverarbeitung und die Genauigkeit der Kalibrierung wichtig werden
  • AOP und der ALS-Treiber selbst funktionierten bereits, aber ohne Kalibrierungsdaten ist die Genauigkeit der vom AOP gelieferten ALS-Rohdaten gering
    • Diese Kalibrierungsdaten sind ein binärer Blob, der zur Laufzeit in den AOP geladen werden muss, dürfen nicht weiterverteilt werden und müssen deshalb bei der Installation aus macOS übernommen werden
  • Der Asahi Installer sammelt die für Linux benötigte Firmware und speichert sie auf der EFI System Partition; ein Dracut-Modul bindet sie dann unter Unterverzeichnissen von /lib/firmware/ ein, damit Treiber sie finden können
  • Um zu verhindern, dass nach einer bereits abgeschlossenen Installation zusätzliche Firmware benötigt wird, unterstützt der Installer nun die automatische Aktualisierung von Vendor-Firmware-Paketen
    • Ab ALS kann die benötigte Firmware aktualisiert werden, indem man in macOS oder macOS Recovery bootet, den Installer erneut ausführt und den Anweisungen folgt
  • Für ALS-Unterstützung und spätere Firmware-Upgrades werden Asahi Kernel 6.19 oder neuer sowie iio-sensor-proxy benötigt

Energieverwaltung und PMP

  • Die Idle-Leistungsaufnahme war vor allem bei Pro/Max/Ultra-SoCs weiterhin ein Problem, und das Energieverwaltungssystem dieser Plattform ist eine komplexe Struktur, in der PMGR und PMP miteinander verflochten sind
  • PMGR ist für das Ein- und Ausschalten der Stromdomänen des SoC zuständig, während PMP Berichte über Energiezustände verarbeitet, die SoC-Blöcke und Anwendungskerne über Shared Memory übermitteln
    • Wenn PMP nicht gebootet wird, kann es diese Berichte nicht lesen, und bestimmte Energieverwaltungsfunktionen arbeiten dann ebenfalls nicht
  • Der von chaos_princess entwickelte Treiber für PMP-Unterstützung sorgt dafür, dass PMP Berichte von SoC-Blöcken und PMGR erhält, und erreicht im Idle auf einem 14-Zoll-MacBook-Pro mit M1 Pro eine Einsparung von etwa 0,5 W
    • Das entspricht einer Senkung der Idle-Leistungsaufnahme um etwa 20 %
  • Bis zu Idle- und Schlafzeiten auf macOS-Niveau ist noch zusätzliche Arbeit nötig, aber diese Änderung ist bereits ein großer Fortschritt
  • Das Basismodell M1 verwendet eine ältere PMP-Variante, die nicht mit späteren Generationen kompatibel ist; dd-dreams arbeitet an der entsprechenden Unterstützung
  • PMP wurde noch nicht auf allen unterstützten Geräten verifiziert und soll bis zum Upstream-Merge auch nicht standardmäßig aktiviert werden
    • Nutzer, die ihren Devicetree anpassen können, können es durch Definieren von APPLE_USE_PMP in der Geräte-DTS aktivieren

Behebung von Bluetooth-Audio-Aussetzern

  • Bluetooth und WiFi teilen sich dasselbe 2,4-GHz-Band, wodurch leicht Interferenzen entstehen; Verbindungen wie Audio-Streams, bei denen Latenz und Kontinuität wichtig sind, benötigen eine höhere Priorität
  • Broadcoms Coexistence-Konfiguration wird über vendor-spezifische Erweiterungsbefehle von Bluetooth-HCI verarbeitet, aber der Upstream-Linux-Kernel unterstützte diese bisher nicht, wodurch es beim Bluetooth-Scanning zu Paketverlusten im Audio-Stream kam
    • Wenn KDE Connect Bluetooth-Scans auslöste, konnten Audio-Dropouts auftreten
  • chaos_princess hat Unterstützung für diese Befehle zum Bluetooth-Stack des Kernels hinzugefügt, und BlueZ markiert alle Audio-Streams als high priority, sodass die erforderlichen Befehle beim Streaming automatisch ausgelöst werden
  • Dadurch treten Bluetooth-Audio-Dropouts nicht mehr auf

DCP und VRR

  • Die DCP-Firmware-Schnittstelle ist sehr groß und zwischen Versionen instabil, und während andere Hardwarearbeiten nach der grundlegenden Display-Unterstützung priorisiert wurden, blieben Funktionen wie VRR zunächst liegen
  • Für VRR-Unterstützung sind spezieller Paketaustausch zwischen Display-Controller und Display, die Anpassung des Vertical Blanking je nach Frame-Anzeige-Timing, die Bekanntgabe der VRR capability des Displays sowie die KMS-Integration erforderlich
  • Beim Tracing stellte sich heraus, dass ein DCP-Parameter, der beim Einschalten externer Displays auf 0 gesetzt wurde, beim Ein- und Ausschalten von VRR zwischen 0x300000 und 0x0 wechselte
    • Das Test-Display hatte eine minimale Bildwiederholrate von 48 Hz, und im DCP-Fixed-Point-Format entsprach 48 dem Wert 0x300000
    • Dieser Parameter war nicht für die Power-Sequenz gedacht, sondern ein Schalter für die minimale VRR-Bildwiederholrate; wenn vor dem Modeset 0 eingetragen wurde, führte das zur Deaktivierung von VRR
  • Das integrierte ProMotion-Display des MacBook Pro wird auf dieselbe Weise aktiviert, aber interne Panels melden kein EDID/DisplayID, weshalb der Linux-Treiber anhand des internen LCDs die nötigen Eigenschaften statisch setzt
  • VESA DisplayPort Adaptive Sync und die KMS-API erlauben beim Wechsel des VRR-Status keinen Modeset, aber Apple DCP kann dies nicht vermeiden
    • Wegen dieser Einschränkung kann VRR nicht korrekt an den Userspace exponiert werden, und KWin ignoriert eine solche Schnittstelle ebenfalls
  • Derzeit kann nach dem Merge des Pull Requests per Kernel-Modulparameter appledrm.force_vrr VRR erzwungen aktiviert werden
    • Wenn das Display VRR unterstützt, verwendet DCP VRR, ohne KMS oder den Compositor darüber zu informieren
    • Unter KWin funktionierte das gut, bei anderen Compositoren kann die Erfahrung anders ausfallen
  • Auf der HDMI-Seite wird ein Modeset zwischen VRR-Umschaltungen nicht verboten, und auch andere Display-Controller wie Intel verhalten sich ähnlich
    • Upstream wird derzeit darüber diskutiert, VRR entweder immer eingeschaltet zu lassen oder Modesets während des Wechsels zu erlauben; sobald die Richtung feststeht, soll VRR wie erwartet exponiert werden

Upstream des Audio-Stacks und erweiterte Sample-Rates

  • Die Upstream-Arbeit am gesamten Audio-Stack läuft weiter; Treiber für Kopfhörerbuchsen und Lautsprecherverstärker rund um Cirrus Logic und Texas Instruments, I2S-Peripherie sowie Änderungen am Apple-DMA-Controller wurden bereits gemergt
  • Der Lautsprecherschutz dieser Plattform arbeitet so, dass TI-Verstärker Spannung und Strom per I2S an das SoC senden, wo zusammen mit den Thiele/Small-Parametern der Lautsprecher die Temperatur der Schwingspule berechnet wird
  • In einer Struktur, in der die Data-Transmit-Pins mehrerer Verstärker seriell verbunden sind und die linken und rechten Leitungen per OR zusammengeführt werden, muss die jeweils andere Seite beim Senden der einen Seite logic low garantieren, weshalb eine Bus-Keeper-Konfiguration erforderlich ist
  • Bisher wurde der Bus Keeper über Verstärkerchip-Treiber und ein spezielles Devicetree-Binding behandelt, aber für den Upstream war das zu restriktiv, weshalb es in eine generische API umgewandelt wurde
    • Nun kann jede konfigurierbare ASoC-Komponente das Vorhandensein eines Bus Keepers offenlegen, und der Plattformtreiber kann die zur Laufzeit nötige Konfiguration anwenden
    • Dieses Patchset wurde in Linux 7.1 gemergt
  • Auch die Unterstützung für Apple-spezifische Chip-Varianten wird weiter ausgebaut
    • Beim TI-Lautsprecherverstärker ließ sich Unterstützung für Apple-Varianten relativ problemlos zu den Upstream-Treibern für TAS2764 und TAS2770 hinzufügen
    • CS42L84 unterscheidet sich stärker vom CS42L42 und benötigte deshalb einen eigenen Linux-Treiber, der bereits upstream eingeflossen ist
  • Wenn man sich nur am macOS-Tracing orientiert, besteht die Grenze darin, dass nur die von macOS genutzten Funktionen sichtbar werden; daher unterstützte auch der CS42L84 anfangs nur 48 kHz und 96 kHz
    • Diese Einschränkung zwang PipeWire dazu, andere Streams zu resamplen, was mehr CPU und Akku verbrauchte und zudem die Klangqualität verschlechterte
  • Nachdem andere gemeinsame Sample-Rate-Werte aus dem Datenblatt des CS42L42 auf den Treiber für den CS42L84 angewendet wurden, funktioniert nun Hardware-Unterstützung für 44.1, 88.2, 176.4 und 192 kHz sowohl bei Ein- als auch Ausgängen der Kopfhörerbuchse
    • Der entsprechende Patch wurde upstream eingereicht, in Linux 7.1 gemergt und außerdem auf Asahi Kernel 6.19.9 zurückportiert

Erweiterte M3-Unterstützung

  • In den Asahi-Kernel-Tree fließen auch zusätzliche Patches zur Hardware-Aktivierung für M3-Geräte ein
  • Der Umfang wurde auf PCIe, MacBook-Tastatur und -Trackpad, SMC-basiertes RTC und Reboot-Controller sowie den NVMe-Controller erweitert
  • Durch die Arbeit von Michael Reeves und Alyssa Milburn hat das Linux-Unterstützungsniveau für M3 inzwischen ungefähr die gleiche Stufe erreicht wie das erste Asahi-Linux-Alpha für M1
  • Die Vorbereitungen, M3-Installationen direkt im Asahi Installer freizuschalten, sind noch nicht abgeschlossen, aber die Arbeit schreitet weiter voran

Fedora Asahi Remix 44

  • Trotz der Verzögerung bei Fedora Asahi Remix 43 hält Fedora Asahi Remix 44 am Plan fest, am 28. April gleichzeitig mit Fedora Linux 44 oder innerhalb weniger Tage danach veröffentlicht zu werden
  • Die neue KDE-Plasma-basierte Installation wird neue Funktionen aus Plasma 6.6 nutzen
    • Plasma Setup ersetzt den bisherigen Calamares-basierten Einrichtungsassistenten und bietet einen nativen Plasma-Ablauf für Kontoerstellung und Systemeinstellungen
    • Plasma Login Manager wird zum Standard-Greeter und Session-Manager und ersetzt SDDM
  • Diese Änderung gilt nur für Neuinstallationen; die Konfiguration von Nutzern, die von früheren Fedora-Asahi-Remix-Versionen aktualisiert haben, wird nicht verändert
  • Fedora Asahi Remix 44 beendet die mitgelieferten Pakete für Mesa und virglrenderer
    • Nutzer, die noch nicht manuell umgestellt haben, wechseln automatisch auf die Mesa- und virglrenderer-Pakete aus den Upstream-Fedora-Repositories

Sponsoring und Infrastruktur-Unterstützung

  • Spenden werden weiterhin über OpenCollective und GitHub Sponsors angenommen
  • Bunny unterstützt das Projekt seit den Anfangstagen mit kostenlosem CDN und Hosting-Diensten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 일 전
Hacker-News-Kommentare

  • CS42L84 war unter macOS so konfiguriert, dass nur 48/96 kHz verwendet werden, aber als man andere Sampleraten aus dem CS42L42-Datenblatt in den Treiber eintrug, funktionierte es einfach direkt so
    Ein Patch, der 44.1/88.2/176.4/192 kHz für Ein- und Ausgabe über die Kopfhörerbuchse unterstützt, wurde upstream aufgenommen, in 7.1 gemergt und auch auf Asahi kernel 6.19.9 zurückportiert, sodass man es sofort nutzen kann
    Das Chip-Tracking und Reverse Engineering sind wirklich beeindruckend

    • Am überraschendsten ist, dass nur 48/96 kHz zu unterstützen dazu führt, dass PipeWire wegen Resampling mehr CPU und Akku verbraucht
      Apple ist doch eine Firma, die von Energieeffizienz besessen ist, deshalb fragt man sich, warum sie das immer noch so lassen
    • Dass jetzt 44.1 kHz bitperfekte CD/FLAC-Wiedergabe möglich ist, wirkt wie ein wirklich großes Feature

  • Die technischen Artikel und Ergebnisse des Asahi-Teams sind wirklich großartig, aber es macht trotzdem etwas Sorgen, dass das weiterhin ein eigenständiges Projekt ist und nicht in einer Form fortbesteht, die innerhalb des Kernel-Mainline oder in Mainstream-Distributionen wie Ubuntu, Debian oder Fedora getragen wird
    Reverse-Engineering-Projekte können zwar relativ leicht bis zu 80 % nützliche Ergebnisse liefern, aber um die für normale Nutzer ausreichend ausgereiften 95 % Fertigstellungsgrad zu erreichen, braucht es fast dieselbe Menge an mühsamer und kleinteiliger Zusatzarbeit

    • Asahi betreibt bereits viel Upstreaming genau in diese Richtung
      Ein wichtiger Grund, warum der Fortschritt zuletzt langsamer wirkte, ist auch, dass man sich darauf konzentriert hat, die Zahl der Diffs zu reduzieren, und ziemlich viel Arbeit ist bereits im Mainline-Kernel gelandet
      Asahi dient außerdem als Raum, um neue Funktionen zu erproben
    • Hinzu kommt die zusätzliche Schwierigkeit, dass ARM-Macs selbst ein bewegliches Ziel sind
      Apple hat überhaupt nicht vor, Stabilität oder Support für Asahi Linux zu bieten, und hat anders als die PC-Industrie auch keinen Grund, langfristige Kompatibilität einzuhalten, daher wird es Apple wohl auch künftig nicht kümmern, Änderungen vorzunehmen, die Asahi das Leben schwer machen
    • Das Gute an Linux ist, dass es freie Software ist und nicht an Aktionäre oder Rentabilität gebunden ist
      Ich nutze Asahi auf einem M1 MacBook Air als Standard-OS und bin ziemlich zufrieden; selbst wenn es Schwächen wie 1 % Akkuverlust pro Stunde im Standby gibt, ist die jetzige Form viel besser, als es gar nicht zu haben, nur weil noch keine 100 % Funktionsumfang erreicht sind
      Ich habe auch nicht das Gefühl, dass es unbedingt perfekt für die breite Masse poliert sein muss
    • Die Entwicklung des Mainline-Kernels läuft ohnehin so, dass alle erst in ihrem eigenen Fork arbeiten und dann Patches upstream schicken
      Dass Asahi besonders wirkt, liegt nur daran, dass die Hardware ungewöhnlich und stark spezialisiert ist und deshalb viele Spezialtreiber braucht; niemand entwickelt direkt in Linus’ Tree
    • Der Vortrag auf der 39c3 https://youtu.be/3OAiOfCcYFM war ebenfalls gut
      Das Ziel ist letztlich, dass Linux Apple Silicon nativ unterstützt

  • Ich hoffe, dass dieses Projekt weiter Fahrt aufnimmt
    Die Kombination aus Apple-Hardware + Linux fühlt sich an wie das am wenigsten kaputte OS auf der besten Hardware, während macOS wegen Bugs und Änderungen, die sich mit jeder Version wieder umdrehen, immer chaotischer wirkt

    • Wenn man Fedora auf einem Framework nutzt, könnte man seine Meinung ändern
      Die Erfahrung war sehr rund, und beim bald erscheinenden Framework 13 Pro gibt es die Erwartung, dass Akku und Trackpad auf macOS-Niveau sein werden oder der Akku sogar besser
    • Ich habe alle drei großen Betriebssysteme verwendet, und macOS hatte die wenigsten Bugs und lief einfach am zuverlässigsten
      Unter Linux musste ich immer seltsame Patches wegen Audio- oder Bildschirmkompatibilität einspielen, und unter Windows waren die Akkuprobleme heftig
      Viele Leute, die Linux-Tuning mögen, scheinen am Ende eigentlich eine Mac-ähnliche Erfahrung zu wollen, nur mit mehr Anpassbarkeit
    • Insgesamt stimmt das, aber das Ökosystem rund um MLX ist ziemlich stark zusammengewachsen
      Die Disk-I/O ist nicht besonders gut und das OS hat auch Bugs, aber zumindest lässt sich ML auf dem aktuellen OS kompilieren und ausführen
      Bei rocm wirkt es dagegen fast fertig und dann braucht man doch wieder vorgebaute Pakete oder ein über zwei Jahre altes Ubuntu, was frustrierend ist
      https://github.com/ROCm/TheRock/issues/3477
    • Ich habe kürzlich beruflich ein MacBook Air benutzt, und der Aussage, die Hardware sei absolute Spitzenklasse, würde ich wirklich nicht zustimmen
      Für 5 Euro bekommt man wahrscheinlich schon eine bessere Tastatur

  • Ich verstehe nicht ganz, warum Apple bei diesen Bemühungen nicht kooperiert und keine Dokumentation offenlegt
    Die klassischen Gründe wie Wettbewerbsvorteil oder Geheimhaltung wirken inzwischen nicht mehr besonders überzeugend

    • Der wahre Grund könnte viel einfacher sein
      Apple hat hohe Hardware-Margen, verdient also schon daran, MacBooks an Linux-Nutzer zu verkaufen, aber sobald man offiziell Linux-Support anerkennt, wird daraus sofort eine Support-Verpflichtung
      Dann gäbe es bei jedem Kernel Panic Besuche in der Genius Bar und bei jedem Treiberbug würde @AppleSupport gerufen; aus Apples Sicht könnte der aktuelle inoffizielle Zustand also das beste Szenario sein: Hardwareverkäufe mitnehmen und Supportlast vermeiden
    • Es gibt kaum finanziellen Nutzen, und jedes Mal, wenn sich die Hardware ändert, entsteht zusätzlicher Dokumentationsaufwand für Linux
      Dass es sich zugleich um eine kleine, aber besonders laute und kritische Nutzergruppe handelt, dürfte es für Apple ebenfalls unattraktiv machen
    • Eine klare Linie nach dem Motto wir spielen dieses Spiel nicht zu ziehen, ist womöglich viel einfacher, als sich Vorwürfe wegen selektiver Offenheit oder gebrochener Kompatibilität mit nichtöffentlichen Schnittstellen einzuhandeln
      Intern kann man so auch vermeiden, ständig Diskussionen anzustoßen, die nichts mit den eigentlichen Prioritäten zu tun haben
    • Das fühlt sich fast wie ein Thema rund um right to repair an
      Ein Laptop besteht aus verschiedenen Hardwarekomponenten und den Treibern, die sie betreiben; damit stellt sich die Frage, ob das, was ich gekauft habe, ein untrennbares Paket aus Hardware und Treibern ist oder ob ich Handbücher bekommen sollte, damit ich die eine Seite selbst retten kann, wenn die andere ausfällt
      Apple könnte behaupten, Treiber würden sich im Gegensatz zu Zahnrädern oder Motoren nicht abnutzen, aber das bedeutet meiner Meinung nach nicht, dass damit auch das Recht verschwindet, zu verstehen, wie etwas funktioniert
      Es würde mich nicht wundern, wenn es eines Tages einen Präzedenzfall gäbe, in dem jemand vor Gericht Dokumente verlangt, weil /System/Trackpad.kext von einem Raumschiff getroffen wurde und man den Treiber nun selbst schreiben muss
    • Klingt plausibel
      Es wäre für Apple wohl leicht, das zu unterstützen, und sie würden in der Community wahrscheinlich auch einiges an Goodwill gewinnen

  • Ich frage mich, ob es Interesse an einem Asahi-Remix-Spin gäbe, der auf eine Mac-ähnliche Standarderfahrung ausgerichtet ist
    Also mit cmd als primärer Modifikatortaste sowie standardmäßig Mac-artigen Shortcuts, Themes und Gesten
    Man kann das zwar in jeder Distribution selbst anpassen, aber gut kuratierte Voreinstellungen haben nochmal ihren eigenen Wert

    • cmd als „primäre Modifikatortaste“ zu nehmen, ist etwas schwierig
      In typischen X/Wayland-Umgebungen ist Cmd für DE-Funktionen ohnehin schon zentral, während auf Anwendungsebene Ctrl im Mittelpunkt steht; wenn man das ändert, entstehen viele Überschneidungen
    • Ich habe es in KDE geschafft, es ziemlich ähnlich einzurichten
      Ich habe Claude Code gebeten, das umzusetzen, und es hat per Websuche sogar die Konfigurationsdateien erstellt
    • Eine Cmd-zentrierte Tastenbelegung ist faktisch fast ein verlorener Kampf
      Ich habe es mehrfach versucht, aber am Ende das Leben mit Ctrl akzeptiert und mein letztes MacBook auch verkauft

  • Ich frage mich, ob bei der Traum-Entwicklungsmaschine MacBook Pro + Linux zuerst die Hardware- oder die Software-Seite Realität wird
    Es bleibt spannend, ob Asahi softwareseitig zuerst dort ankommt oder Framework hardwareseitig zuerst dorthin gelangt

  • Die Kombination MacBook Neo + Asahi wäre wirklich stark

  • Es ist erfreulich zu sehen, dass der M3-Support mit dem Abarbeiten des Upstream-Backlogs und verbesserten Tools solide vorankommt
    Patches für PCIe, MacBook-Tastatur und -Trackpad, SMC-basiertes RTC und Reboot-Controller sowie NVMe-Controller-Support landen im Asahi-Kernel-Tree, wodurch der Linux-Support für den M3 ungefähr das Niveau der ersten Asahi-Linux-Alpha für M1 erreicht

    • In diesem Tempo könnte es sein, dass es erst rund um die Einführung des M6 wirklich brauchbar wird

  • Dass in solchen Projektberichten immer wieder Durchbrüche auftauchen und dabei genau benannt wird, wo echte Nutzer auf Probleme stoßen, zeigt für mich, wie erfahren das Asahi-Team wirklich ist
    Ich bekomme richtig Lust, bald wieder komplett zu Asahi zurückzukehren

  • Die Nachricht, dass M3 fast Alpha-Niveau erreicht, ist wirklich großartig, und ich freue mich schon auf M4
    Umgekehrt freue ich mich überhaupt nicht darauf, was Apple dieses oder nächstes Jahr wieder mit macOS anstellen wird