Chromebrew: der Paketmanager, der Chromebooks zu Linux macht
Dieses Projekt rundet „Package manager for Chrome OS. The only missing pieces to use them as full-featured Linux distro were gcc and make with their dependencies.“ zu einer praxistauglichen Open-Source-Lösung zusammen, mit wiederverwendbarer Tooling- und Integrationsunterstützung für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Ein in Ruby geschriebener Paketmanager für Chrome OS, der über den Entwicklermodus gcc, make und tausende Pakete auf Chromebooks bringt, mit klaren Fußnoten zu Architekturen und Kanälen.
- Für wen ist es gedacht?
- Chromebrew passt für Besitzer von Chromebooks, die ein echtes Linux-Toolchain-Erlebnis auf dem Gerät wollen und bereit sind, den Entwicklermodus mit seinen Sicherheitskonsequenzen bewusst zu verwalten. Es passt nicht für verwaltete Geräte ohne Entwicklermodus und nicht für Nutzer der Beta-, Dev- oder Canary-Kanäle, deren Kombination das README als Problemquelle nennt.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Ruby, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
gcc und make auf Chromebooks: die Lücke, die Chromebrew schließt
Chromebooks laufen zwar auf einem Linux-Kernel, aber als Entwicklungsumgebung fehlten lange die Grundwerkzeuge. Das README formuliert es als Ausgangslage: Es fehlten gcc und make samt Abhängigkeiten, und genau diese Lücke füllt Chromebrew, das sich selbst als fehlender Paketmanager für Chrome OS bezeichnet. Die Idee ist, ein Chromebook mit denselben Gewohnheiten nutzbar zu machen wie eine vollwertige Linux-Distribution, inklusive Kompilieren aus dem Quellcode.
Technisch steht hinter dem Projekt ein in Ruby geschriebenes System mit dem zentralen Befehl crew. Die Metadaten zählen 2.508 Sterne, 421 Forks und 44 offene Issues, die Lizenz ist GPL-3.0. Das Paketangebot wird in einem eigenen packages-Verzeichnis im Repository gepflegt, das README verlinkt dorthin als Liste verfügbarer Pakete. Community-Kanäle sind ein Discord-Server und eine Slack-Gruppe, wobei das README anmerkt, dass Discord-Nachrichten derzeit nicht nach Slack synchronisiert werden.
Entwicklermodus, VT-2 und chromeos-setdevpasswd
Die Voraussetzung ist ein Chromebook im Entwicklermodus. Das README verweist für die gerätespezifische Aktivierung auf das ChromiumOS-Wiki und warnt ausdrücklich, dass der Entwicklermodus unsicher ist, wenn er nicht richtig konfiguriert wird. Als Härtungsschritte empfiehlt es zwei Befehle wörtlich: sudo chromeos-setdevpasswd setzt ein Passwort für die Entwicklerumgebung, sudo crossystem dev_boot_signed_only=1 aktiviert das signierte Boot, damit das Gerät nur verifizierte Bootloader-Wege anbietet.
Die Installation selbst läuft nicht über die übliche Shell crosh, sondern über eine VT-2-Sitzung, erreichbar mit Strg+Alt+Pfeil nach rechts. Darin meldet man sich als Benutzer chronos an, mit dem oben gesetzten Passwort, sofern vorhanden. Wer diese Sitzung nicht öffnen kann, bekommt vom README die klare Rückmeldung, noch einmal die Voraussetzungen zu prüfen, denn ohne Entwicklermodus läuft nichts. Die eigentliche Installation ist dann eine Zeile: bash <(curl -L git.io/vddgY) && . ~/.bashrc.
Architektur-Tabelle: x86_64, armv7l und die Fußnoten zu i686 und aarch64
Die Supported-Systems-Tabelle unterscheidet vier Architekturen mit zweistufiger Ehrlichkeit. x86_64 und armv7l sind ohne Vorbehalt unterstützt. i686 steht mit einer Fußnote: Weil Google den Support eingestellt hat, liefert das Projekt nur noch eingeschränkte Hilfe, CLI-Programme weiter, GUI-Anwendungen nicht mehr. aarch64 trägt die zweite Fußnote: Selbst wenn der Userspace des Geräts aarch64 ist, werden derzeit nur armv7l-Pakete bereitgestellt, Details verweist das README auf Issue #8044.
Diese Fußnoten sind praktisch relevant, nicht nur Formsache. Wer ein älteres i686-Book hat, sollte kein grafisches Programm erwarten, wer ein modernes ARM-Gerät besitzt, läuft über die armv7l-Kompatibilitätsschiene. Für die Paketwahl heißt das, vor crew install zu prüfen, ob das gewünschte Paket für die eigene Architektur gebaut wird, die Liste im packages-Verzeichnis und der crew-Befehl list helfen dabei.
crosh-Sperre ab ChromeOS M117 und die Kanalwarnung
Zwei Warnungen im README betreffen den Rahmen der Installation. Erstens: Ab ChromeOS M117 funktioniert der Installer nicht mehr in crosh, begründet mit Sicherheitsänderungen dieser Version. Deshalb der Umweg über VT-2, der kein Schönheitsdetail ist, sondern Pfad. Zweitens: Die Beta-, Dev- und Canary-Kanäle werden nicht unterstützt und sollen nicht mit Chromebrew kombiniert werden, das README warnt, dass die Missachtung dieser Regel zu gravierenden Problemen der Installation führt, mit Verweisen auf Issue #2890 und die FAQ im Wiki.
Die Kombination beider Punkte zeichnet ein klares Betriebsbild: Chromebrew will auf der stabilen Version von Chrome OS laufen, im Entwicklermodus, in einer VT-2-Sitzung eingerichtet. Wer von diesen drei Bedingungen abweicht, verlässt den dokumentierten Raum, und die Features des Paketmanagers sind dann keine verlässliche Basis mehr.
crew im Alltag: install, upgrade, whatprovides und das --keep-Flag
Die Befehlsstruktur folgt dem Muster crew <command> <package1> [<package2> ...]. Die Befehlsliste im README ist lang und deckt den vollen Lebenszyklus ab: install mit Bestätigungsaufforderung, remove, reinstall, upgrade für alle oder einzelne Pakete, update für crew selbst, search zum Auffinden, deps für Abhängigkeiten, files für installierte Dateien, postinstall für Hinweise nach der Installation. Für Diagnose gibt es check, sysinfo im Markdown-Stil, diskstat für den Speicherplatz installierter Pakete und version für Programm- oder Paketstand.
Zwei Befehle ragen für Fehlersuche und Pflege heraus: whatdepends zeigt, welche Pakete von einem gegebenen Paket abhängen, whatprovides sucht per Regex, welches Paket eine Datei enthält. build erzeugt Pakete aus dem Quellcode und hinterlässt Archiv und Prüfsumme im Arbeitsverzeichnis, download legt Pakete ohne Installation in CREW_BREW_DIR ab, standardmäßig /usr/local/tmp/crew. Dieses Verzeichnis wird nach der Installation geleert, außer man übergibt -k oder --keep bei crew install, ein Detail, das beim Debuggen von Builds relevant wird.
GPL-3.0, docopt.rb und der Stand der Release-Historie
Lizenzrechtlich steht Chromebrew unter der GNU General Public License in Version 3 oder später, Copyright 2013 bis 2025 bei Michal Siwek und den Beiträgern. Der Lizenztext erlaubt freie Nutzung, Veränderung und Weitergabe unter den GPL-Bedingungen, was für eigene Forks der Paketverwaltung relevant ist. Eine Besonderheit nennt das README: Die Datei docopt.rb ist als Bibliothek eingebettet und behält ihre MIT-Lizenz, dokumentiert in einer eigenen Lizenzdatei im lib-Ordner.
Ein Blick auf die Metadaten zeigt ein Bild mit Schatten: Die Release-Liste nennt als letzte Tags 0.4.1 und v0.4 aus dem Januar 2017 sowie v0.3.1 aus 2015, und auch der Zeitstempel des letzten Pushs liegt dort. Demgegenüber referenziert das README ChromeOS M117, Issue #8044 und ein Copyright bis 2025, was auf eine Pflege über die Tag-Veröffentlichungen hinaus deutet, vermutlich als Rolling-Modell über den master-Zweig und das packages-Verzeichnis. Für Nutzer bedeutet das: Der Projektzustand sollte nicht an den Release-Tags gemessen werden, sondern an der Aktivität im Repository und im Wiki, bevor man sich auf die Installation einlässt.
Redaktionelles Fazit
Chromebrew passt für Besitzer von Chromebooks, die ein echtes Linux-Toolchain-Erlebnis auf dem Gerät wollen und bereit sind, den Entwicklermodus mit seinen Sicherheitskonsequenzen bewusst zu verwalten. Es passt nicht für verwaltete Geräte ohne Entwicklermodus und nicht für Nutzer der Beta-, Dev- oder Canary-Kanäle, deren Kombination das README als Problemquelle nennt. Vor der Installation lohnt der Blick auf zwei Punkte: die eigene Architektur in der Supported-Systems-Tabelle, besonders bei aarch64 mit Verweis auf Issue #8044, und die Einrichtung von dev_boot_signed_only über crossystem, bevor die erste Sitzung in VT-2 geöffnet wird.
Community-Notizen