Ein zweites Leben für mein 2017 MacBook Pro – mit KI

Dieser Beitrag ist etwas anders als meine üblichen Artikel. Ich möchte von einer Erfahrung berichten, die mich besonders beeindruckt hat: wie weit die Zusammenarbeit mit KI inzwischen reicht – bis hin zur Entwicklung und Anpassung von Treibern und Modulen für den Linux-Kernel. Noch vor wenigen Monaten hätte ich es kaum für möglich gehalten, ein solches Projekt gemeinsam mit einem KI-Assistenten umzusetzen.

Vor etwas mehr als einer Woche habe ich mit Hilfe von KI ein altes MacBook Pro wieder nutzbar gemacht. Gemeinsam haben wir Hardwareprobleme untersucht, bestehende Treiber angepasst, Linux-Kernel-Module erstellt und ein Verfahren entwickelt, damit diese Anpassungen auch zukünftige Systemupdates überstehen. Inzwischen konnten wir dieses Verfahren bereits bei mehreren Kernel-Updates und beim Upgrade von Fedora 44 auf Fedora 45 erproben.

Besonders überrascht hat mich, dass KI auf einer so tiefen technischen Ebene mitarbeiten kann – direkt an der Software, die ein Betriebssystem mit der physischen Hardware verbindet. Das hat mich zum Nachdenken gebracht: Welche weiteren Möglichkeiten eröffnen sich dadurch? Können wir ältere hardwarenahe Systeme modernisieren oder technische Probleme lösen, die bisher zu komplex oder zu aufwendig erschienen?

Gleichzeitig wurde mir bewusst, dass diese Fähigkeiten auch eine Kehrseite haben. Wenn KI selbst komplexe, systemnahe Software analysieren und verändern kann, erleichtert sie auch das Aufspüren und Ausnutzen von Sicherheitslücken. Die Sicherheitsmeldungen der vergangenen Wochen haben bereits einen Vorgeschmack darauf gegeben, welche neuen Herausforderungen für die IT-Sicherheit damit verbunden sind.

Eine neue Aufgabe für einen alten Mac

Ausgangspunkt war ein 13-Zoll-MacBook Pro von 2017 mit Intel Core i5, Modell MacBookPro14,2. Die Hardware war eigentlich noch gut zu gebrauchen, doch ich hatte das Gerät praktisch abgeschrieben. Apples offizieller Upgrade-Pfad endet für dieses Modell bei macOS Ventura.

Ich benötigte einen separaten Entwicklungsrechner, auf dem zusätzliche KI-Coding-Agenten unabhängig von meinem Hauptrechner arbeiten können – mit eigenen Werkzeugen, einem eigenen Desktop und Browser. So kam mir die Idee, das alte MacBook mit Linux wieder nutzbar zu machen.

Inspiriert haben mich das Omarchy-Projekt und die Bemühungen der Community, Linux auf älteren Intel-Macs zum Laufen zu bringen. Entschieden habe ich mich schliesslich für Fedora. Ich bevorzuge die GNOME-Desktopumgebung, und Fedora erschien mir als solide, etablierte Grundlage für das Experiment. Das ist eine persönliche Präferenz – Omarchy hat mich überhaupt erst auf die Idee gebracht.

Ein funktionierender Desktop ist erst der Anfang

Die Installation von Fedora war vergleichsweise einfach. Schon bald hatte ich einen funktionierenden Desktop. Einige wichtige Funktionen fehlten jedoch oder arbeiteten unzuverlässig. Apples proprietäre Hardware, insbesondere der Broadcom-WLAN-Chip und die Touch Bar, machte die Sache deutlich komplizierter. Ein Laptop, der zwar startet, aber unzuverlässiges WLAN, eine funktionslose Touch Bar und Probleme beim Aufwachen aus dem Ruhezustand hat, ist noch lange kein praxistauglicher Entwicklungsrechner.

Wir haben die Probleme nacheinander untersucht und gemeinsam Lösungen erarbeitet.

• WLAN: Anfangs funktionierte die drahtlose Netzwerkverbindung überhaupt nicht. Nachdem wir sie zum Laufen gebracht hatten, war sie zunächst quälend langsam. Wir analysierten den Broadcom-Treiber und passten ihn so an, dass die WLAN-Verbindung sowohl beim Start als auch nach dem Ruhezustand zuverlässig funktioniert. Spätere Tests erreichten in meinem Netzwerk rund 150 Mbit/s – mehr als genug für den vorgesehenen Einsatz.
• Ruhezustand und USB-C: Besonders schwierig war das Aufwachen aus dem Ruhezustand. Manchmal schien der Mac normal aufzuwachen, danach funktionierten aber das Netzwerk oder die USB-C-Anschlüsse nicht mehr. Schliesslich entwickelten wir eine Lösung, welche den Zustand der betroffenen Hardware-Controller vor dem Ruhezustand sichert und beim Aufwachen wiederherstellt. Auch die Probleme mit der Erkennung externer USB-C-Speicher konnten wir beheben.
• Ton: Die internen Lautsprecher blieben stumm. Wir passten einen bestehenden, von der Community entwickelten Audiotreiber an, kompilierten ihn für meinen Fedora-Kernel und prüften, ob der Ton nach Neustarts und Ruhezustandszyklen weiterhin funktionierte.
• Touch Bar: Ich wollte die vertrauten Grundfunktionen nutzen: Escape, Funktionstasten sowie Helligkeits- und Lautstärkeregelung. Wir brachten sie zum Laufen, einschliesslich des Wechsels zu den Funktionstasten bei gedrückter Fn-Taste.

Auch Kamera, Mikrofon, Kopfhörer und Bluetooth haben wir überprüft. Ein Teil davon funktionierte bereits mit den vorhandenen Fedora-Treibern. Das gehörte zum Vorgehen: erst das jeweilige Problem verstehen und dann entscheiden, ob überhaupt etwas geändert werden muss.

Die Touch Bar: proprietäre Hardware, offene Treiber

An Apples proprietärer Touch Bar lässt sich das Ergebnis besonders gut zeigen. Zwei Linux-Kernel-Module arbeiten dabei zusammen: apple_ibridge stellt die Verbindung zu Apples T1-Bridge her, während apple_touchbar die Bedienelemente bereitstellt. Als Grundlage dienten Treiber aus der Open-Source-Community, die wir für meine Fedora-Installation angepasst und neu kompiliert haben.

Fünf Module, mit dem Kernel von Fedora

Ein grosser Teil der Anerkennung gebührt den Open-Source-Entwicklern, deren Arbeit diese Lösungen erst möglich gemacht hat. Bestehende Treiber, veröffentlichte Patches und Untersuchungen aus der Community bildeten die Grundlage. KI half uns, diese Arbeit zu finden und zu verstehen, an mein konkretes Gerät anzupassen und die verschiedenen Teile zusammenzuführen.

Am Ende umfasste unsere Lösung fünf Kernel-Module. Einfach ausgedrückt sind das Softwarebausteine, über die Linux mit bestimmter Hardware kommunizieren kann. Wir kompilierten sie für genau die verwendete Fedora-Kernel-Version und behielten einen älteren, funktionierenden Kernel als Rückfalloption. Einen eigenen Linux-Kernel mussten wir nicht bauen; die Grundlage blieb der Kernel von Fedora.

Was Codex konnte – und was ich selbst testen musste

Beeindruckt hat mich die Bandbreite der Aufgaben, die Codex übernehmen konnte. Es untersuchte den Rechner, analysierte Diagnoseprotokolle, prüfte Quellcode, schlug Änderungen vor, kompilierte Kernel-Module und überprüfte deren Abhängigkeiten. Auch die Installation und die Schritte zur Wiederherstellung wurden dokumentiert.

Dass ein KI-Assistent direkt in der Entwicklungsumgebung arbeiten konnte, machte einen erheblichen Unterschied. Er konnte komplexe Untersuchungen über viele zusammenhängende Schritte hinweg fortsetzen, statt mir lediglich Befehle vorzuschlagen, die ich selbst ausführen musste.

Meine eigene Mitwirkung blieb unverzichtbar. Ich legte die Ziele fest, beschrieb Probleme, berichtete, was ich tatsächlich sehen oder hören konnte, testete physische Bedienelemente und startete den Rechner bei Bedarf neu. Ein Build kann erfolgreich durchlaufen, während die Lautsprecher weiterhin stumm bleiben. Jemand muss noch immer hinhören.

Damit es auch nach Updates funktioniert

Alles zum Laufen zu bringen war die eine Herausforderung. Dafür zu sorgen, dass es nach künftigen Fedora-Updates weiterhin funktioniert, war die andere.

Linux-Kernel-Updates können Änderungen mitbringen, die sich auf angepasste Kernel-Module auswirken. Ohne Vorbereitung könnte ein gewöhnliches System-Update dazu führen, dass WLAN, Ton oder andere Hardwarefunktionen wieder ausfallen.

Gemeinsam mit Codex entwickelten wir ein Vorgehen, um diese Updates kontrolliert und mit einer Rückfalloption durchzuführen. Vor dem Wechsel auf einen neuen Kernel bereiten wir die passenden Module vor, kompilieren sie und überprüfen ihre Abhängigkeiten. Schlägt eine automatisierte Prüfung fehl, wird der Vorgang gestoppt. Ein nachweislich funktionierender Kernel bleibt als Wiederherstellungsoption erhalten. Nach dem Update teste ich die Hardware im normalen Gebrauch, bevor ich es als erfolgreich betrachte.

Dieses Vorgehen haben wir bereits über aufeinanderfolgende Kernel-Versionen hinweg erprobt: 7.2.13, 7.2.14 und 7.2.15. Ausserdem haben wir das System von Fedora 44 auf Fedora 45 aktualisiert. Dabei behielten wir bewusst den zuvor geprüften Kernel bei, statt sofort auf einen neuen Fedora-45-Kernel-Build zu wechseln.

Das Ergebnis zu erhalten ist genauso wichtig, wie es einmal zum Laufen zu bringen.

Quellcode und Anleitungen

Wer sich für die technischen Details interessiert, findet Quellcode, Patches und Build-Anleitungen im GitHub-Repository macbookpro-2017-fedora. Dort sind auch Installation, Wartung und Wiederherstellung dokumentiert – einschliesslich Verweisen und Anerkennung für die Open-Source-Projekte, die diese Arbeit ermöglicht haben.

rdesimone / macbookpro-2017-fedora Quellcode, Patches und Anleitungen auf GitHub

Die Lösung wurde nur auf meinem eigenen MacBook Pro von 2017 getestet. Sie funktioniert möglicherweise auf anderen Geräten nicht, auch nicht auf ähnlichen Modellen, und wird ohne Gewähr bereitgestellt.

Wieder sinnvoll im Einsatz

Eine angenehme Überraschung ist, wie flüssig und schnell sich dieser alte Intel-Mac mit Fedora und GNOME anfühlt. Er erfüllt jetzt genau die Aufgabe, die ich ursprünglich für ihn vorgesehen hatte: eine separate Entwicklungsumgebung, in der KI-Coding-Agenten unabhängig von meinem Hauptrechner arbeiten können.

Die Erfahrung hat mich auch darüber nachdenken lassen, ob Linux mehr Menschen einen praktischen Weg zu grösserer Unabhängigkeit von Microsoft Windows eröffnen könnte. Natürlich müssten dafür die benötigte Software und die Hardwarekompatibilität sorgfältig geprüft werden. Aber das ist eine Geschichte für einen anderen Beitrag.

Für den Moment habe ich einem Computer, den ich beinahe aufgegeben hatte, eine neue Aufgabe gegeben. Gleichzeitig ist mir einmal mehr bewusst geworden, wie leistungsfähig KI inzwischen ist und wie grundlegend sie unsere Arbeitswelt verändern wird.