FrameOS-Dokumentation

Projektausrichtung

FrameOS beschreibt sich selbst als Betriebssystem für Smart Frames mit einer einzigen Funktion. Die README positioniert es für den Einsatz auf einem Raspberry Pi und für eine Vielzahl von E-Ink- und herkömmlichen Displays. Es deckt sowohl Bildschirme ab, die alle 60 Sekunden aktualisiert werden, wie Smart-Home-Kalender oder Meeting-Raum-Anzeigen, als auch Bildschirme, die 60 Mal pro Sekunde aktualisiert werden, wie Informationsanzeigen. Die Repository-Metadaten zeigen, dass das Projekt in TypeScript geschrieben und unter der AGPL-3.0-Lizenz verbreitet wird. Diese Kombination grenzt den Einsatz klar ein: FrameOS ist als Geräteplattform für eine festgelegte Anzeige gedacht, nicht als allgemeines Desktop-Betriebssystem. Die README erklärt keine zentrale Verwaltung beliebiger Display-Hersteller und nennt keine Leistungswerte für die beiden Aktualisierungsraten. Auch Angaben zu Stromverbrauch, Ausfallszenarien und Zugriffsschutz fehlen im gelieferten Material. Für eine Auswahl zählt daher zuerst, ob das konkrete Panel in `frameos.net/devices` abgedeckt ist und für den geplanten Dauerbetrieb vorab.

Bereitstellungsablauf

Die Bereitstellung umfasst laut README zwei Teile: eine Backend-Anwendung und die einzelnen Frames. Das Backend ist eine dockerisierte Python-App, die Apps über SSH auf Frames bereitstellt. Der Benutzer installiert das Backend, liest den Geräte-Hardwareleitfaden für seinen Bildschirmtyp, verbindet das Display mit einem Raspberry Pi und stellt sicher, dass es im Netzwerk erreichbar ist, und stellt dann vorgefertigte Szenen bereit oder programmiert eigene im Backend. Die README erwähnt das 3D-Drucken eines Gehäuses um den Frame als optionalen letzten Schritt.

Unterstützte Displays

Die README listet unterstützte Plattformen im Geräte-Hardwareleitfaden auf: Pimoroni E-Ink-Frames, Waveshare E-Ink, Framebuffer-HDMI-Ausgabe und Web-Server-Kioskmodus. Sie verweist für die vollständige Liste auf frameos.net/devices. Die Dokumentation beschreibt keine funktionalen Unterschiede zwischen diesen Gerätetypen oder ob sie alle dieselben Funktionen unterstützen.

Backend-Installation

Die README bietet zwei Wege zur Installation des Backends. Einer ist ein Installationsskript für Mac oder Debian/Ubuntu Linux, aufgerufen mit `bash <(curl -fsSL https://frameos.net/install.sh)`. Der andere ist ein manueller Docker-Lauf, der den Container startet, ein `./db`-Verzeichnis mountet und eine `SECRET_KEY`-Umgebungsvariable setzt. Sie erwähnt auch einen Watchtower-Container für tägliche oder einmalige Updates und einen lokalen Entwicklungs-Build über Docker. Die Installation auf anderen Betriebssystemen oder Umgebungen ist in der README nicht dokumentiert.

Flox-Entwicklungsumgebung

Für Entwickler, die Flox verwenden, beschreibt die README eine eingecheckte Umgebung. Das Ausführen von `flox activate` bootstrappt die Kern-Toolchains und installiert repository-lokale Entwicklungsabhängigkeiten für Python, pnpm und Nim. Der Aktivierungshook erstellt ein lokales `.venv`, installiert `backend/requirements.txt`, führt `pnpm install --frozen-lockfile` für den Workspace aus und installiert Nim-Abhängigkeiten für `frameos/` und `frameos/remote/`. Die README erwähnt auch das Starten von Redis über Flox mit `flox services start redis`.

Cross-Compilation und Images

Die README beschreibt die Cross-Compilation in mehreren Abschnitten. Die Cross-Compilation verwendet nach Möglichkeit vorgefertigte Toolchain-Container von Docker Hub unter `frameos/frameos-cross-toolchain`, um ein Neubauen des Toolchain-Images für jedes Ziel zu vermeiden. Der Image-Name wird aus einem Format aufgelöst, das Distribution, Version, Plattform und Tag enthält. Umgebungsvariablen können das Image-Repository, das Tag und die Frage, ob lokale Builds erzwungen oder Pulls übersprungen werden sollen, überschreiben. Der Workflow `.github/workflows/frameos-cross-toolchain.yml` baut und veröffentlicht diese Images.

Buildroot-Image-Erzeugung

Die Dokumentation beschreibt ein gecachtes Buildroot-Image für die SD-Image-Erzeugung, mit vorinstallierten Abhängigkeitspaketen und vorab geladenem Buildroot-Tarball unter `/frameos-buildroot`. Erzeugte SD-Images haben vier Partitionen: Boot, Root, FrameOS-Laufzeitdaten und Assets. Beim ersten Start erweitern sich die Images auf die Ziel-SD-Karte, wobei `/srv/frameos` und `/srv/assets` je nach Kartengröße dimensioniert werden. Umgebungsvariablen zur Steuerung des gecachten Images und der Workflow `.github/workflows/frameos-buildroot.yml` sind dokumentiert.

Lizenz

Das Repository wird unter der AGPL-3.0-Lizenz verbreitet, die im Lizenztext als so konzipiert beschrieben wird, dass modifizierter Quellcode Benutzern von Netzwerkservern zur Verfügung steht. Der Lizenztext erlaubt das Kopieren, Verbreiten und Modifizieren und verlangt die Bereitstellung des Quellcodes, wenn eine modifizierte Version der Öffentlichkeit angeboten wird. Die Lizenz macht keine Aussagen über Sicherheitsgarantien, Support oder die Eignung für bestimmte Hardware oder Software; diese Aspekte sind weder im Lizenztext noch in der README enthalten.

Redaktionelles Fazit

FrameOS passt zu Teams, die Raspberry-Pi-basierte Einzelzweckanzeigen mit eigener Hardware und klarer Gerätesteuerung betreiben wollen. Für eine beliebige Digital-Signage-Plattform ohne passende Display-Anbindung ist es ungeeignet. Vor der Auswahl sind die konkrete Anzeige im Gerätehandbuch, der Backend-Zugriff per SSH und das Verhalten bei offline geschaltetem Backend zu prüfen. Für Builds müssen außerdem FRAMEOS_CROSS_TOOLCHAIN_IMAGE und die Buildroot-Partitionen zur Zielplattform passen. Die AGPL-3.0-Lizenz verlangt bei öffentlich angebotenen modifizierten Versionen besondere Beachtung der Quellcodebereitstellung. Der belastbare erste Schritt ist daher der Backend-Start mit bash <(curl -fsSL https://frameos.net/install.sh) und die anschließende Bereitstellung einer kleinen Szene auf der tatsächlich vorgesehenen Raspberry-Pi-Hardware.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes