5 Linux-Distros, die Sie vielleicht noch nicht kennen

Die beste Linux-Distro für Entwickler ist diejenige, mit der sich Toolchains, Container und GPU-Treiber mit dem geringsten Aufwand zum Laufen bringen lassen. CachyOS, Bazzite, Nobara, Vanilla OS und Chimera Linux gewichten diese drei Punkte jeweils unterschiedlich.

Die meisten „Beste Distro“-Listen sind in Wahrheit Gaming-Benchmarks. Sie nennen Ihnen Frameraten, sagen aber nichts darüber, ob npm install, Docker oder Ihre IDE an einem ganz normalen Dienstagmorgen reibungslos funktionieren.

Ihr Laptop muss nicht mehr der Produktionsumgebung entsprechen, denn darum kümmern sich heute Container. Bei der Wahl des Host-Betriebssystems geht es daher um drei Dinge: Treiber, Update-Verhalten und die Art, wie Sie Tools installieren. Dieser Artikel betrachtet fünf weniger bekannte Distros unter genau diesen drei Gesichtspunkten. Omarchy und Garuda Linux haben eigene Artikel und werden hier daher nicht behandelt.

CachyOS: Performance-optimiertes Arch

CachyOS ist eine Rolling-Release-Distribution auf Basis von Arch. Vom Standard-Arch unterscheidet sie sich in zwei Punkten: einem von CachyOS optimierten Kernel, der standardmäßig einen angepassten EEVDF-Scheduler nutzt (BORE und andere Scheduler sind optional), sowie Paket-Repositories, die für x86-64-v3, x86-64-v4 und AMD Zen 4/5 kompiliert sind. Sie eignet sich für Entwickler, die Arch bereits schätzen und sich das Tuning abnehmen lassen möchten.

• Pakete: Arch-Repos plus das AUR. Ausgefallene CLIs, Language Server und Nischen-SDKs sind meist nur ein Paket entfernt.
• Bis Sie loslegen können: Installieren Sie Ihre Runtimes und Docker oder Podman aus den Repos. Nichts steht Ihnen im Weg.
• NVIDIA: Die NVIDIA-Pakete von Arch und die NVIDIA-Seite im Arch Wiki gelten unmittelbar.
• Als Arbeitsrechner: Kernel-, Mesa- und Toolchain-Updates kommen laufend, und es wird erwartet, dass Sie vor größeren Upgrades die News lesen.

Der Preis dafür: Der Pflegeaufwand eines Rolling Release. Ein fehlerhaftes Update am Tag einer Deadline müssen Sie selbst beheben.

Bazzite: Fedora Atomic mit eigenen NVIDIA-Images

Bazzite ist eine immutable Distribution, deren Basissystem ein schreibgeschütztes Fedora-Atomic-Image ist. Es wird als Ganzes aktualisiert, und ein Rollback erfolgt, indem Sie das vorherige Image booten. Entwicklungswerkzeuge installieren Sie daher nicht wie mit dnf systemweit. Bazzite eignet sich für Entwickler, die ein konsistent bleibendes System wünschen und bereit sind, in Containern zu arbeiten.

• Pakete: Flatpak für GUI-Anwendungen, rpm-ostree-Layering für Host-Software und Container für Toolchains. Bazzite liefert Distrobox mit. Wer Docker direkt einsatzbereit haben möchte, bekommt es mit der Bazzite-DX-Variante, nicht mit dem Standard-Image.
• Bis Sie loslegen können: Richten Sie einen Dev-Container ein.
• NVIDIA: Bazzite bietet eigene NVIDIA-Images an. Wählen Sie das passende auf der Download-Seite aus.
• Als Arbeitsrechner: Updates sind atomar und lassen sich zurückrollen, für Ihr Home-Verzeichnis, Ihre Container und gelayerte Pakete sind Sie jedoch weiterhin selbst verantwortlich.

Auf einem immutablen Fedora-System legen Sie Pakete auf Host-Ebene mit rpm-ostree auf das Image. Sie werden nach einem Neustart wirksam. Sprach-Toolchains gehören in einen Distrobox- oder Toolbx-Container, der Ihr Home-Verzeichnis mitnutzt:

rpm-ostree install zsh          # host layer, applied on next boot
systemctl reboot

distrobox create --name dev --image registry.fedoraproject.org/fedora:latest
distrobox enter dev
sudo dnf install nodejs gcc make   # inside the container only

rpm-ostree rollback             # revert to the previous deployment

Alles, was Sie innerhalb von dev installieren, bleibt außerhalb des Host-Images. Löschen Sie den Container, ist es wieder entfernt.

Das schreibgeschützte Basissystem von Bazzite bricht mit Gewohnheiten. Vielleicht lösen Sie Probleme normalerweise mit sudo und einem Texteditor und beherrschen Dateiberechtigungen und Besitzverhältnisse aus dem Effeff. Unter Fedora Atomic ist /usr jedoch schreibgeschützt. /etc bleibt beschreibbar, allerdings führt OSTree Ihre Änderungen bei jedem neuen Image zusammen. Hinzu kommt eine weitere Falle: Eine als Flatpak paketierte IDE läuft in einer Sandbox und sieht Compiler in Ihrem Container oder auf dem Host unter Umständen nur, wenn Sie das entsprechend konfigurieren.

Der Preis dafür: Vor jeder Tool-Installation müssen Sie zunächst entscheiden, ob es auf den Host, in einen Container oder in ein Flatpak gehört.

Nobara: Fedora ohne Ecken und Kanten

Nobara ist ein gewöhnliches, beschreibbares Fedora, ergänzt um Medien-Codecs, NVIDIA-Treiber und auf Gaming ausgerichtete Kernel-Patches. Die meiste Fedora-Dokumentation und gewohnte dnf-Arbeitsweisen lassen sich unverändert übernehmen. Gepflegt wird Nobara von GloriousEggroll. Die Distro eignet sich für Fedora-Nutzer, die es leid sind, nach jeder Installation Codecs und Treiber einzurichten.

• Pakete: dnf, Flatpak und das Fedora-Ökosystem, ergänzt um die eigenen Repositories von Nobara.
• Bis Sie loslegen können: Sehr wenig. Installieren Sie Ihre Runtimes und Ihre Container-Engine wie unter Fedora.
• NVIDIA: Vorinstalliert. Damit entfällt die häufigste Hürde beim ersten Start von Fedora.
• Als Arbeitsrechner: Ein veränderbares (mutable) System. Sie können alles bearbeiten und damit auch alles kaputtmachen.

Der Preis dafür: Ein kleineres Projekt als Fedora. Wenn etwas nicht funktioniert, müssen Sie neben Upstream auch die Nobara-eigenen Patches als Fehlerquelle in Betracht ziehen.

Vanilla OS: Immutable und Container-First

Vanilla OS hält das Basissystem immutable und verlagert die Softwareinstallation in Container. Bei der Installation eines Compilers entscheiden Sie zuerst, in welchem Container er liegen soll, nicht, aus welchem Repository er stammt. Die Distro eignet sich für Entwickler, die regelmäßig Pakete aus mehreren Distributionen auf einem Rechner benötigen.

• Pakete: Der Host wird von ABRoot verwaltet, das jedes Update auf eine zweite Root-Partition anwendet und beim nächsten Neustart auf diese umschaltet. Apx verwaltet Container auf Basis anderer Distributionen und macht deren Paketmanager vom Host aus nutzbar. GUI-Anwendungen werden über Flatpak abgedeckt.
• Bis Sie loslegen können: Legen Sie für jede Toolchain-Familie einen eigenen Apx-Container an.
• NVIDIA: Prüfen Sie die Projektdokumentation für Ihre Hardware.
• Als Arbeitsrechner: Es gelten dieselben Kompromisse eines immutablen Systems wie bei Bazzite, allerdings mit Vanillas eigenen Tools statt rpm-ostree.

Der Preis dafür: Vanilla-spezifische Werkzeuge. Dokumentation zu Fedora Atomic oder Arch lässt sich nicht eins zu eins übertragen.

Chimera Linux: Der echte Exot

Chimera Linux ist eine unabhängige Rolling-Release-Distribution, die GNU vermeidet, wo immer es geht. Sie verwendet musl statt glibc, FreeBSD-Core-Tools statt GNU coreutils, LLVM/Clang als System-Toolchain und dinit als Init-System. Pakete werden über apk-tools bezogen. Chimera eignet sich für Systemprogrammierer und alle, die die Portabilität ihres Codes testen möchten.

• Pakete: apk-Repositories. Alles, was Arch- oder Fedora-Pakete voraussetzt, benötigt einen Container.
• Bis Sie loslegen können: Prüfen Sie, ob Ihre Runtimes unter musl laufen.
• NVIDIA: Informieren Sie sich in der Projektdokumentation über die NVIDIA-Unterstützung.
• Als Arbeitsrechner: Shell-Skripte, die für GNU coreutils geschrieben wurden, können sich unerwartet verhalten, da die BSD-Tools andere Flags verwenden.

Eine musl-basierte Distribution wie Chimera Linux kompiliert und führt Ihren eigenen Code problemlos aus. Anders sieht es bei vorkompilierten, gegen glibc gelinkten Binaries aus: Hersteller-CLIs und Pakete, die ausschließlich glibc-Builds anbieten, laufen unter Umständen nicht ohne Kompatibilitätsschicht oder glibc-Container.

Der Preis dafür: Annahmen des Ökosystems. Die meisten Binaries werden für glibc gebaut und ausgeliefert.

Welche Linux-Distro ist die beste für Entwickler?

• Wenn Sie praktisch im AUR leben und Rolling Updates Sie nicht stören, bietet Ihnen CachyOS Arch mit bereits erledigtem Tuning.
• Wenn Sie ein Betriebssystem möchten, das stabil bleibt, und gern in Containern entwickeln, decken das Image-Modell von Bazzite und Distrobox Ihre Anforderungen ab.
• Wenn Sie Fedora bereits kennen und nur NVIDIA und Codecs geregelt haben möchten, können Sie mit Nobara Ihre gewohnte Arbeitsweise beibehalten.
• Wenn Sie regelmäßig Pakete aus mehreren Distributionen auf einem Rechner benötigen, legt Vanilla OS jede Toolchain in einen eigenen Apx-Container.
• Wenn Sie ein unkonventionelles System suchen, um die Portabilität Ihres Codes zu testen, deckt Chimera jede glibc- und GNU-Annahme in Ihrem Code auf.

Keine dieser Distros ändert etwas daran, worauf Ihr Code in der Produktion läuft. Die Wahl entscheidet darüber, wie Toolchains auf den Rechner gelangen, wie Updates eingespielt werden und wie viel Treiberarbeit anfällt, bevor Sie einen Editor öffnen. Wählen Sie das Szenario, das zu Ihrer Situation passt, installieren Sie die entsprechende Distro auf einer freien Partition und bauen Sie dort Ihre aktuelle Projektumgebung nach, bevor Sie sich festlegen.

FAQs

Muss ich unter Bazzite oder Fedora Atomic nach jedem rpm-ostree install neu starten?

Nein, nicht wenn Sie ausschließlich Pakete hinzufügen. Standardmäßig arbeitet jede rpm-ostree-Operation offline und wird beim nächsten Start wirksam. Mit rpm-ostree install --apply-live (Kurzform -A) werden neu gelayerte Pakete jedoch sofort auf das laufende System angewendet. Live Apply funktioniert nur beim Hinzufügen von Paketen, wenn keine anderen Änderungen ausstehen. Für das Entfernen von Paketen ist weiterhin ein Neustart nötig, und rpm-ostree apply-live --reset setzt das System auf den gebooteten Stand zurück.

Läuft CachyOS auch auf älteren CPUs ohne x86-64-v3-Unterstützung?

Ja. CachyOS pflegt neben den Builds für x86-64-v3, x86-64-v4 und Zen 4/5 auch ein generisches x86-64-Repository. Bei der Einrichtung ermitteln der Installer und das Repo-Skript, was der Prozessor unterstützt, und wählen die am besten passende Repository-Stufe aus. CPUs ohne AVX2 erhalten die generischen Pakete, sodass die Rolling-Arch-Basis und die CachyOS-Tools weiterhin nutzbar sind. Mit /lib/ld-linux-x86-64.so.2 --help können Sie prüfen, welche Stufen Ihre CPU unterstützt.

Was ist der Unterschied zwischen Distrobox und Toolbx für Entwicklungscontainer?

Beide erstellen langlebige Container, die Ihr Home-Verzeichnis mit dem Host teilen. Toolbx läuft ausschließlich auf Podman und funktioniert am besten mit Images im Fedora-Stil. Distrobox setzt auf Podman oder Docker auf, greift ersatzweise auf den eigenen Manager Lilipod zurück und unterstützt Images nahezu jeder Distribution. Toolbx deckt Fedora-Container unter Fedora Atomic ab. Distrobox ist die richtige Wahl, wenn Sie ein Arch-, Ubuntu- oder Alpine-Userland benötigen, etwa für ein Hersteller-Tool, das nur als .deb ausgeliefert wird.

Kann die Flatpak-Version von VS Code Compiler nutzen, die in Distrobox oder auf dem Host installiert sind?

Nicht standardmäßig. Das VS-Code-Paket von Flathub läuft in einer Sandbox, die keinen Zugriff auf auf dem Host installierte SDKs hat. Toolchains in einem Distrobox-Container oder per rpm-ostree gelayerte Toolchains bleiben daher unsichtbar. Die Hinweise zum Paket nennen drei Workarounds: Host-Befehle über flatpak-spawn --host oder host-spawn ausführen, das integrierte Terminal auf eine Host-Shell umstellen oder Freedesktop-SDK-Erweiterungen wie das Go- oder .NET-SDK innerhalb der Sandbox installieren.