Tilix gehört für mich seit vielen Jahren zu den Terminal-Programmen, die ich seit Jahren immer wieder installiere. Die frei aufteilbaren Terminalbereiche und die Möglichkeit, mehrere Shells gleichzeitig zu verwalten, haben meinen Arbeitsalltag deutlich erleichtert. Leider wird das Projekt inzwischen kaum noch gepflegt und basiert weiterhin auf GTK3 und VTE3.

Mit Rutile entsteht deshalb ein spannendes Projekt. Die Entwickler schreiben Tilix nicht einfach weiter, sondern entwickeln den Terminal-Emulator vollständig in Rust neu. Gleichzeitig bleibt das Bedienkonzept erhalten. Statt einer Neuerfindung soll eine moderne Umsetzung entstehen, die sich nahtlos in aktuelle GNOME-Systeme mit GTK4 und libadwaita einfügt.

Bewährtes Konzept auf moderner Basis

Viele Terminal-Emulatoren unterscheiden sich hauptsächlich durch ihr Erscheinungsbild oder kleinere Zusatzfunktionen. Rutile verfolgt dagegen einen anderen Ansatz. Ziel ist es, die Arbeitsweise von Tilix möglichst vollständig zu übernehmen und auf eine moderne technische Grundlage zu stellen. Bestehende Nutzer sollen sich sofort zurechtfinden.

Die Anwendung verwendet GTK4, libadwaita und VTE4 und profitiert dadurch von aktuellen Bibliotheken des GNOME-Desktops. Gleichzeitig setzen die Entwickler auf Rust als Programmiersprache. Das verspricht langfristig eine besser wartbare Codebasis und eröffnet die Möglichkeit, neue Funktionen auf einer modernen Architektur aufzubauen.

Flexible Terminalaufteilung

Die wichtigste Funktion übernimmt Rutile direkt von Tilix. Das Terminalfenster lässt sich rekursiv horizontal und vertikal aufteilen. Jeder Bereich kann anschließend erneut geteilt werden. Dadurch entstehen flexibel verschachtelte Arbeitsbereiche, ohne dass die Anwendung auf ein festes Raster oder eine bestimmte Fensteranordnung beschränkt ist.

Im Alltag bietet diese Arbeitsweise viele Vorteile. Links lassen sich beispielsweise Logdateien beobachten, während rechts gleichzeitig mehrere Server oder Container geöffnet sind. Zwischen den einzelnen Bereichen wechselt ihr bequem per Tastatur. Das spart Mausbewegungen und sorgt für einen flüssigen Arbeitsablauf bei komplexeren Aufgaben.

Andere Terminals wie Ghostty bieten diese Funktion ebenfalls, allerdings muss man sich dafür Tastenkombinationen merken. Alternativ kann man natürlich auch Terminal-Multiplexer wie tmux verwenden. Dort gilt jedoch dasselbe. Auch wenn es nicht viele Tastenkombinationen sind: Ich persönlich möchte dafür einfach Buttons haben.

Mehrere unabhängige Sitzungen

Neben den frei aufteilbaren Terminalbereichen unterstützt Rutile mehrere voneinander getrennte Sitzungen. Jede Sitzung besitzt ihre eigene Fensteraufteilung und ihren eigenen Arbeitskontext. Dadurch lassen sich unterschiedliche Projekte oder Aufgaben sauber voneinander trennen, ohne dafür mehrere Programmfenster öffnen zu müssen.

Zwischen den Sitzungen wechselt ihr entweder per Tastenkombination oder über eine Seitenleiste. Diese zeigt kleine Vorschaubilder der jeweiligen Arbeitsumgebung und bleibt standardmäßig ausgeblendet. Wer sie benötigt, blendet sie einfach über die Werkzeugleiste ein und behält so auch bei vielen geöffneten Sitzungen leichter den Überblick.

Synchronisierte Eingaben

Besonders praktisch finde ich die Funktion zur synchronisierten Eingabe. Aktiviert ihr sie, überträgt Rutile sämtliche Tastatureingaben gleichzeitig an mehrere Terminalbereiche einer Sitzung. Das spart Zeit, wenn identische Befehle auf mehreren Servern oder virtuellen Maschinen ausgeführt werden sollen.

Einzelne Terminalbereiche lassen sich jederzeit von der gemeinsamen Eingabe ausnehmen. Dadurch können einzelne Systeme gezielt abweichende Befehle erhalten, ohne die Synchronisierung komplett zu deaktivieren. Trotzdem empfiehlt sich etwas Vorsicht, denn fehlerhafte Befehle werden ansonsten ebenso gleichzeitig auf allen verbundenen Systemen ausgeführt.

Vertraute Bedienung

Auch die Tastenkombinationen orientieren sich eng am Vorbild. Mit Strg+Umschalt+O und Strg+Umschalt+E teilt ihr das Fenster horizontal oder vertikal. Strg+Umschalt+W schließt den aktiven Bereich, während ihr mit den Pfeiltasten zwischen den einzelnen Terminalfenstern wechselt.

Neue Sitzungen öffnet ihr mit Strg+Umschalt+T. Zwischen vorhandenen Sitzungen wechselt ihr per Strg+Umschalt+Bild auf beziehungsweise Bild ab. Wer lieber mit der Maus arbeitet, erreicht dieselben Funktionen zusätzlich über die Werkzeugleiste oder das Kontextmenü der einzelnen Terminalbereiche.

Noch in einer frühen Entwicklungsphase

Rutile befindet sich derzeit noch am Anfang seiner Entwicklung. Die erste Version konzentriert sich bewusst auf die wichtigsten Funktionen. Features wie der Quake-Modus, das Speichern kompletter Sitzungen, Desktop-Benachrichtigungen oder die Nautilus-Integration sollen erst folgen, wenn die vorhandenen Funktionen zuverlässig arbeiten.

Diesen Ansatz halte ich für sinnvoll. Statt möglichst viele Funktionen früh bereitzustellen, konzentriert sich das Projekt zunächst auf einen stabilen Kern. Gerade bei Werkzeugen, die viele Anwender täglich nutzen, sind Zuverlässigkeit und ein konsistentes Bedienkonzept meist wichtiger als eine möglichst lange Funktionsliste.

Was aktuell wirklich fehlt, sind Übersetzungen – einige Dialoge erscheinen derzeit ausschließlich auf Französisch. Außerdem lassen sich die Terminalfarben noch nicht direkt in den Einstellungen anpassen. Das voreingestellte Farbschema macht Programme wie den Midnight Commander teilweise schwer lesbar. Allerdings ist die aktuelle Version von Rutile erst vor wenigen Tagen erschienen, sodass sich hier vermutlich bald etwas tun wird.

Installation

Unter Arch Linux steht Rutile sowohl als Quellpaket als auch als vorkompilierte Variante im AUR zur Verfügung. Für Debian, Ubuntu und Fedora bieten die Entwickler fertige DEB- beziehungsweise RPM-Pakete an. Zusätzlich lässt sich eine eigenständige Binärdatei herunterladen, sofern die benötigten GTK4-Komponenten bereits installiert sind. Alle Informationen zur Installation finden sich auf der GitHub-Seite des Projekts.

Wer Tilix seit Jahren nutzt und auf einen modernen GTK4-Unterbau wechseln möchte, sollte Rutile im Auge behalten. Noch fehlen einige Funktionen, doch der bisherige Entwicklungsstand macht einen sehr vielversprechenden Eindruck. Das Projekt verfolgt einen klaren Fokus und könnte sich zu einem würdigen Nachfolger für Tilix entwickeln.

Microsoft hat mit Edit einen neuen, quelloffenen Texteditor für die Kommandozeile vorgestellt. Das unter der MIT-Lizenz veröffentlichte Projekt ist nicht nur für Windows, sondern auch für Linux verfügbar. Zudem nicht nur für PCs, sondern auch für die ARM64-Architektur, wie sie auf dem Raspberry Pi genutzt wird. Der Editor richtet sich an Nutzer, die ein einfaches, schnelles Werkzeug für das Bearbeiten von Textdateien im Terminal suchen. Microsofts Edit reiht sich irgendwo zwischen Nano, Micro oder Kilo ein.

Kompakter Editor für den Terminaleinsatz

Edit ist ein schlanker Editor mit Text User Interface (TUI), der insbesondere auf Portabilität und geringe Abhängigkeiten ausgelegt ist. Die Software setzt auf eine eigene TUI-Bibliothek, die laut Projektentwickler besser zu einer geplanten Plugin-Schnittstelle auf Basis einer C-ABI passt. Außerdem wurde Wert auf UTF-8-Unterstützung, kompakte Dateigröße, VT-kompatible Ausgabe (für bessere SSH-Kompatibilität) und statische Kompilierung gelegt. So lässt sich das Programm ohne Abhängigkeiten ausführen.

Der Editor wurde in Rust geschrieben, nachdem erste Prototypen in C, C++ und Zig entstanden waren. Die Entscheidung für Rust fiel, weil die Sprache innerhalb Microsofts bereits offiziell unterstützt wird und sich gut für systemnahe Programmierung eignet. Der Editor ist natürlich für Windows-Admins interessant, weil man sich seit Windows 10/Windows Server 2019 via SSH auch auf Windows-Kisten einloggen kann. Für administrative Aufgaben braucht es dann auch einen effektiven Editor.

Veröffentlichung auf GitHub

Der Quellcode sowie vorkompilierte Binaries sind auf GitHub unter github.com/microsoft/edit verfügbar. Für Linux steht ein statisch gelinktes Binary bereit, das ohne weitere Abhängigkeiten ausgeführt werden kann:

$ wget https://github.com/microsoft/edit/releases/download/v1.0.0/edit-1.0.0-x86_64-linux-gnu.xz
$ unxz edit-1.0.0-x86_64-linux-gnu.xz
$ chmod +x edit-1.0.0-x86_64-linux-gnu
$ ./edit-1.0.0-x86_64-linux-gnu

Im Arch User Repository (AUR) stehen mehrere inoffizielle Pakete zur Verfügung, unter anderem edit, ms-edit, ms-edit-bin und microsoft-edit. Ich möchte hier keine Empfehlung ausgeben, mit Sicherheit wird hier in den nächsten Tagen ein wenig aufgeräumt. Dazu kommen Kochrezepte mit der Endung -git, die das Programm aus dem Quellcode bauen.

$ yay -Ss microsoft edit
aur/edit 1.0.0-1 (+0 0.00) 
    A simple editor for simple needs (Microsoft Edit)
aur/ms-edit 1.0.0-1 (+1 1.00) 
    A simple editor for simple needs (Microsoft Edit)
aur/ms-edit-git 1.0.0.r1.ge8d40f6-1 (+2 1.98) 
    A simple editor for simple needs (Microsoft Edit)
aur/ms-edit-bin 1.0.0-1 (+3 2.99) 
    A simple editor for simple needs (Microsoft Edit)
aur/microsoft-edit-git 1.0.0.r1.ge8d40f6-2 (+1 1.00) 
    Modern version of the MS-DOS Editor with a modern UI and keybindings similar to VS Code
aur/microsoft-edit 1.0.0-2 (+2 1.99) 
    Modern version of the MS-DOS Editor with a modern UI and keybindings similar to VS Code

Entwicklung aus Eigeninitiative

Der Editor entstand im Rahmen eines internen Microsoft-Projekts, wurde jedoch größtenteils in der Freizeit des Entwicklers umgesetzt. In einem ausführlichen Kommentar auf Hacker News beschreibt der Autor Hintergründe zur Entstehung, den Technologiestack sowie die Beweggründe für die Eigenentwicklung anstelle der Verwendung bestehender TUI-Editoren. Einen neuen Editor für Linux-User zu schaffen, stand allerdings nicht auf dem Zettel. /s

Ziel sei es unter anderem gewesen, ein möglichst kleines Binary mit guter Unicode-Unterstützung bereitzustellen, das systemnah arbeitet und sich auch für automatisierte Systemumgebungen oder Remote-Shells eignet. Ob sich Edit langfristig gegen etablierte Editoren behaupten kann, bleibt abzuwarten. Der Fokus auf Minimalismus, Portabilität und UTF-8-Kompatibilität dürfte insbesondere in reduzierten oder serverseitigen Umgebungen relevant sein.

Ich bin gerade in der Situation, dass ich meinen Arbeitsplatz ein wenig umgestalten möchte. Die Monitoren sollen nicht mehr nur einfach auf dem Schreibtisch stehen, sondern auf einem Gestell an den Tisch geklemmt werden — Ergo: mehr Platz auf dem Tisch. Nun gilt es dabei ein paar Dinge zu beachten. Etwa die Frage, wie schwer meine Monitore eigentlich sind. Da ich keine Lust habe alles abzubauen und die Geräte auf die Waage zu stellen, wäre es recht nett zu wissen, vor was für Geräten ich da eigentlich täglich sitze. Da Information könnte ich sicherlich aus alten Rechnungen herauskramen, doch das geht sicherlich auch ein wenig cleverer.

Das Logo des Herstellers glitzert mir auf der Frontseite des Gehäuses entgegen, doch weitere Informationen zum Gerät finden sich dort nicht. Und auch auf der Rückseite gibt es keine weiteren Details. Ein Schildchen mit der Typenbezeichnung gab es in der Regel bei den guten alten Röhrenmonitoren, doch bei meinen aktuellen Dell-Flatscreens findet sich dort nichts mehr. Auch die Monitor-Einstellungen der Gnome-Desktopumgebung lässt den Nutzer im Stich. Die zeigen nur dann Informationen zum Typ des Monitors an, wenn zwei Displays angeschlossen sind. Mehr als den Hersteller und die Bildschirmdiagonale erfährt man jedoch nicht.

Gnome geizt mit Informationen

Wenn die grafischen Tools so sparsam mit Informationen sind, dann hilft doch sicherlich das Terminal. Tools zur Anzeige von Hardware-Informationen gibt es unter Linux ja wie Sand am Meer, da müsste doch was dabei sein. Das Go-To-Werkzeug für diese Aufgabe wäre hier Inxi, das sich bei vielen Distributionen aus den Paketquellen installieren lässt (etwa via pacman -S inxi bei Arch Linux oder apt install inxi bei Ubuntu, Debian und Derivaten). Das Kommando inxi -F spuckt dann sämtliche Details zum System aus, aber auch hier Pustekuchen: keine Details zu den angeschlossenen Monitoren.

Details zum Monitor über das Terminal

Um mir eine weitere Suche unter den zahlreichen Tools zu ersparen, greife ich nun gleich auf das „richtige“ Werkzeug zurück. Details zum Displayserver liefert das Kommandozeilenwerkzeug Xrandr. Tools wie Inxi machen in der Regel nichts anderes, also solche Kommandos auszuführen und die Ausgabe optisch aufgewertet anzuzeigen. Über xrandr -q --verbose bekommt man also zahlreiche Details zu den unterstützten Auflösungen und Wiederholraten, doch der Name und Typ des Monitors fehlt immer noch. Aber nicht ganz: Die Daten sind im Feld EDID oder Extended Display Identification Data codiert.

Wer diese Daten nun jetzt nicht von Hand decodieren möchte, muss sich ein wenig unter die Arme greifen lassen. Das bei Stack Overflow gepostete Skript beispielsweise braucht keine weiteren Helferlein, um die EDID zu dekodieren. Ihr speichert folgenden Code einfach als monitor.sh ab und macht die Skriptdatei via chmod +x monitor.sh ausführbar. Aus dem Terminal heraus aufgerufen, zeigt das Skript dann die angeschlossenen Monitore inklusive den Namen des Herstellers und der Typenbezeichnung an. Technische Details zu Auflösungen oder Wiederholraten fehlen, doch die lassen sich ja auch an zahlreichen anderen Stellen ermitteln.

#!/bin/bash
while read -r output hex conn; do
    [[ -z "$conn" ]] && conn=${output%%-*}
    echo "# $output $conn   $(xxd -r -p <<< "$hex")"
done < <(xrandr --prop | awk '
    !/^[ \t]/ {
        if (output && hex) print output, hex, conn
        output=$1
        hex=""
    }
    /ConnectorType:/ {conn=$2}
    /[:.]/ && h {
        sub(/.*000000fc00/, "", hex)
        hex = substr(hex, 0, 26) "0a"
        sub(/0a.*/, "", hex)
        h=0
    }
    h {sub(/[ \t]+/, ""); hex = hex $0}
    /EDID.*:/ {h=1}
    END {if (output && hex) print output, hex, conn}
    ' | sort
)

$ ./monitor.sh 
# DP1-8 DP1   DELL U2515H
# HDMI1 HDMI1   DELL P2213

Alternativ holt ihr euch das Paket edid-decode auf den Rechner. Bei Ubuntu/Debian oder Linux Mint direkt über die offiziellen Paketquellen (via apt install edid-decode), bei Arch Linux oder Manjaro lediglich über das AUR (etwa mit einem AUR-Helper via yay -S edid-decode-git). Hier genügt dann der folgende Einzeiler, der allerdings nicht mit dem proprietären Nvidia-Treiber funktioniert. Hier bekommt ihr dann allerdings nicht nur den Hersteller und den Monitortyp angezeigt, sondern auch gleich die Seriennummer der Geräte — falls ihr an diesen Interesse haben solltet.

$ for file in $(ls -1 /sys/class/drm/*/edid); do text=$(tr -d 0 <"$file"); if [ -n "$text" ]; then edid-decode "$file" | grep -e Manufacturer: -e Product; sleep 0.0001; fi done
  Vendor & Product Identification:
    Manufacturer: DEL
    Display Product Serial Number: '9X2VY55I0J0L'
    Display Product Name: 'DELL U2515H'
  Vendor & Product Identification:
    Manufacturer: DEL
    Display Product Serial Number: 'Y57VF31AAT3M'
    Display Product Name: 'DELL P2213'

Letztendlich wäre es natürlich schneller gewesen die alten Rechnungen herauszusuchen, oder vielleicht auch mal einen Blick über den Tellerrand zu KDE zu werfen. Im Gegensatz zu den Einstellungen von Gnome zeigen die Systemeinstellungen von KDE nämlich gleich die Bildschirmkennungen mit an. Wie immer ist Gnome ein wenig arg spartanisch und geizig mit Funktionen und Details. In meinen Augen dürften die System-Settings von Gnome ruhig auch die Bezeichnungen ausgeben. Nötig sind sie in der Regel nicht, doch ab und an können sie doch auch praktisch sein.