Yazelix Nova: Terminal-Arbeitsplatz mit Popup-Philosophie unter Nix

Nova setzt auf klare Paketgrenzen statt Kontrollschicht

Yazelix Nova ist ein Nix-verpackter Terminal-Arbeitsbereich für lokale Nutzung und SSH. Der Kern besteht aus Mars, einem vom Rio abgeleiteten Terminalemulator, einem Yazelix-eigenen Zellij-Fork, einem eigenen Helix-Fork als Standardeditor, dazu Yazi, Nushell, Bash, Zsh und Fish mit Atuin-Verlaufshistorie. Ein Lazygit-Popup lässt sich gegen andere Git-Clients tauschen, ein optionaler Coding-Agent läuft ebenfalls als Popup. Eine konfigurierbare Widget-Leiste zeigt CPU-, RAM- und AI-Nutzung, dazu kommen Cursor-Effekte und Terminal-Animationen. Die Nova-Version entstand aus einer selbstkritischen Bestandsaufnahme: Das frühere Classic-Repository bündelte laut README Produktlaufzeit, Komponenten-Steuerung, Konfigurationsreparatur, Kompatibilitätsschicht und Wartzeugkasten in einem Codepfad. Nova gibt jeder First-Party-Komponente ein eigenes, versioniertes Paket mit fester Grenze; Nova selbst pinnt nur noch deren Paketausgaben. Metadaten: Rust als Hauptsprache, Apache-2.0, rund 1150 Sterne, Release nova-v1.1.0 vom 10. August 2026.

23.272 statt 91.545 Zeilen: der Nova-Classic-Vergleich

Das README führt die Umbauarbeit mit einer fest auf Nova v1.0.0 bezogenen Tabelle: 23.272 Zeilen Code und Konfiguration in Rust, Nix, Shell und TOML stehen 91.545 Zeilen bei Classic gegenüber, eine Reduktion um 68.273 Zeilen oder 75 Prozent. Allein der Rust-Anteil fiel von 80.957 auf 19.872 Zeilen, sodass der alte Classic-Rust-Code 3,5-mal größer war als Novas gesamte Code- und Konfigurationsoberfläche. Das README zieht daraus ein doppeltes Fazit: Nova liefere mehr Features, stärkere Defaults und eine geschlossene Popup-Oberfläche bei einem Viertel des Codes, und Classic habe die Idee zwar bewiesen, aber mit dem falschen Besitzmodell gebaut. Classic bleibt als eingefrorener classic-Zweig und über das unveränderliche Tag v17.12 als Migrations- und Rollback-Pfad verfügbar. Für Wartende bedeutet die kleinere Basis konkreter: weniger Berührungspunkte zwischen Komponenten, weniger doppelte Logik, und ein leichter zu lesender Konfigurationsvertrag je Komponente.

Drei Kanäle: stable, main und edge mit eigenen Paketnamen

Voraussetzung ist Nix mit aktivierten Flakes. Der stable-Zweig rückt höchstens einmal pro Woche von einer geprüften und selbst genutzten main-Revision vor, main liefert häufigere Updates, und edge ist der freiwillige experimentelle Dogfood-Kanal; wer einen exakten Stand will, greift zu einem unveränderlichen nova-v*-Tag. Ausprobieren ohne Installation geht mit nix run github:Yazelix/nova/stable -- launch beziehungsweise mit -- enter. Im Profil landet die App über nix profile add --refresh github:Yazelix/nova/stable, deklarativ über das Home-Manager-Modul aus docs/installation.md. Die Kanäle sind auch sichtbar: Linux-Starter heißen Yazelix Nova (Stable), (Main) oder (Edge), mit den expliziten Ausgaben yazelix-main und yazelix-edge, und innerhalb der Sitzung erscheint die Identität als NOVA 1.1 STABLE, MAIN oder EDGE. Linux ist die dogfooded Plattform, CI baut alle Pakete plus eine Home-Manager-Aktivierung auf aarch64-darwin; macOS ist als Beta deklariert, die Rio-GUI und die alte Befehlscheckliste bleiben dort laut README unverifiziert.

Erste Schritte mit yzx tutor, Alt-Grid und Ratconfig

Nach dem Start führt yzx tutor begin durch eine geführte Tour, yzx help listet alle Befehle, und yzx doctor prüft die verwaltete Laufzeit, ohne Rio oder Zellij zu öffnen. Yazelix erweitert das h/j/k/l-Bewegungsmodell aus Helix und Vim zu einem Arbeitsplatzraster: Die Alt-Ebene bewegt den Fokus zwischen Panes und Tabs, die Ctrl-Alt-Ebene verschiebt sie, und die Alt-Shift-Ebene schaltet vier Oberflächen um. Alt Shift M öffnet die Befehlspalette, Alt Shift Y den Yazi-Dateimanager, Alt Shift K Ratconfig. Ratconfig ist eine eigene Konfigurationsoberfläche mit Zeilen für Tab-Sprünge über die Ziffern 1 bis 9, Suche über alle Einstellungen mit Slash, kontextuellen Aktionen über Enter und Leertaste sowie dem Entfernen expliziter Overrides mit u. Die Fußzeile zeigt jeweils die verfügbaren Tasten. Dieser Ansatz erspart das Durchblättern von Dokumentenseiten für kleine Änderungen.

Konfiguration mit Overrides unter ~/.config/yazelix

Das Konfigurationsmodell folgt einem Besitzprinzip: Yazelix erbt die Paketdefaults und speichert nur explizite Overrides in einem verwalteten Baum unter ~/.config/yazelix/. Die Ratconfig-Oberfläche trennt eine Overview-Ansicht mit empfohlenen Einstellungen von der vollständigen All-Ansicht mit dem Eigentümer-Inventar. Die Bearbeitbarkeit variiert je Komponente: Mars und Yazi bieten editierbare endliche Auswahlsteuerungen, Helix-Zeilen bleiben schreibgeschützt, weil Helix keinen maschinenlesbaren Konfigurationskatalog veröffentlicht. Über appearance.mode mit dark oder light steuert man verwaltete Komponenten und die Ratconfig-Palette; das README beschreibt, wie der Modus auf Mars, Zellij und Yazi übertragen wird, inklusive des Themenpaars bei Zellij und der Flavor-Pools aus Yazi Bistro. Wer lieber Hand anlegt, editiert die Overrides direkt; wer nur schauen will, prüft mit yzx doctor, welche Pfade Nova tatsächlich geladen hat. Pfade mit nova=unused wurden nicht geladen, ownership=ambiguous heißt, der Besitzer lässt sich am Pfadnamen allein nicht belegen.

Paketvarianten und die First-Party-Familie

Paketnamen folgen dem Muster yazelix[-no-mars][-no-helix][-no-yazi]; jedes Suffix entfernt genau dieses verwaltete Paket, behält aber die Integration darum herum. Das README listet acht Varianten vom vollen yazelix bis yazelix-no-mars-no-helix-no-yazi, dazu die Kanalausgaben yazelix-main und yazelix-edge mit eigenen Starter- und Sitzungsidentitäten. Die First-Party-Familie umfasst Mars, den Yazelix-Zellij-Fork, den Yazelix-Helix-Fork, Zellij-Plugins einschließlich Pane Orchestrator, Popup und Bar, Ratconfig, Yazelix Screen, Yazelix Cursors, Yazi Bistro, auto-layout.yazi und einen zjstatus-Fork. Diese Aufteilung ist der eigentliche Unterschied zu Classic: Komponenten haben einen Besitzer pro Anliegen und veröffentliche Verträge, statt sich überlays im Haupt-Repository. Wer einen Komponenten-Editor bevorzugt, setzt editor.command auf seinen bevorzugten Terminal-Editor und verzichtet so auf den Helix-Fork, ohne die übrige Arbeitsplatzintegration zu verlieren.

Migration von Classic mit der v17.12-Brücke

Für Umsteigende gibt es eine Brücke: Classic v17.12 übersetzt veränderliche Classic-Dateien wie settings.jsonc oder config.toml in Nova-Konfiguration, greift aber nicht in Home-Manager-Deklarationen oder Home-Manager-eigene Dateien ein. Der Lauf erfolgt einmalig über nix run github:Yazelix/nova/v17.12#yazelix -- launch; wer keine individuellen Classic-Einstellungen pflegt, startet direkt mit den Nova-Defaults auf stable. Der Nova-Schnitt ersetzt bewusst die alte main-Historie, bestehende Git-Klone sollen daher frisch geklont werden statt per Pull aktualisiert zu werden. Nach dem Wechsel meldet yzx doctor erkannten Classic-Zustand in configs/ und sessions/ als schreibgeschützte Warnungen, dazu erzeugte Nushell-Extern-Artefakte und Migrations-Backups in den aktiven Yazelix-Wurzeln. Nova archiviert oder löscht gemeldete Pfade nicht, externe Scripts können weiter auf sie verweisen. Das Quellmaterial nennt keine Leistungsbenchmarks oder Sicherheitsgarantien; für Erwartungen an Geschwindigkeit bleibt nur der eigene Test auf dem Zielsystem.

Redaktionelles Fazit

Yazelix Nova passt für Nix-Nutzer, die einen fertig konfigurierten Terminal-Arbeitsplatz mit Editor, Dateimanager und Git-Popup wollen, und weniger für alle, die ihren bestehenden Editor behalten oder Windows einsetzen. Vor dem Wechsel von Classic lohnt der Lauf von yzx doctor, um erkannte Altlasten in configs/ und sessions/ zu sehen.

Offizielle Quellen

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