Eine Notizdatei anlegen, eine Projektstruktur vorbereiten oder einen praktischen Verweis auf ein Verzeichnis erstellen: Solche Aufgaben gehören zum Linux-Alltag. Die grundlegenden Werkzeuge dafür sind touch, mkdir und ln.

Entscheidend ist, ihre Aufgaben auseinanderzuhalten: touch kann leere Dateien anlegen, mkdir erstellt Verzeichnisse und ln erzeugt zusätzliche Dateinamen oder symbolische Verweise. Besonders bei Links lohnt es sich, das Prinzip hinter dem Befehl zu verstehen.

Dateien mit touch erstellen

Mit touch legst du eine leere Datei an, sofern sie noch nicht existiert:

touch notizen.txt

Du kannst auch mehrere Dateien gleichzeitig erstellen:

touch aufgaben.txt ideen.txt termine.txt

Die Dateien entstehen im aktuellen Arbeitsverzeichnis. Alternativ kannst du einen Pfad angeben:

touch ~/Dokumente/notizen.txt

Das übergeordnete Verzeichnis muss bereits existieren. touch erstellt keine fehlenden Verzeichnisse.

Was passiert, wenn die Datei schon existiert?

Der eigentliche Zweck von touch ist das Aktualisieren von Zeitstempeln. Existiert die Datei bereits, bleiben ihre Inhalte erhalten; standardmäßig werden Zugriffs- und Änderungszeit aktualisiert. touch leert eine vorhandene Datei also nicht.

touch notizen.txt

Dieser Befehl bedeutet deshalb je nach Ausgangslage:

• Die Datei existiert nicht: Eine leere Datei wird erstellt.
• Die Datei existiert: Ihre Zeitstempel werden aktualisiert.

Mit -c unterbindest du das Anlegen fehlender Dateien:

touch -c notizen.txt

So bearbeitet touch nur eine bereits vorhandene Datei.

Dateien direkt mit Inhalt anlegen

Eine leere Datei ist nicht immer das Ziel. Möchtest du sofort Text hineinschreiben, kannst du eine Ausgabe in eine Datei umleiten. Dafür ist kein vorheriges touch nötig.

Eine Zeile mit echo schreiben

echo 'Meine erste Notiz unter Linux.' > notizen.txt

echo erzeugt die Textausgabe, und die Shell leitet sie mit > in die Datei um. Existiert die Datei noch nicht, wird sie angelegt. Existiert sie bereits, wird ihr bisheriger Inhalt normalerweise ersetzt.

Der Unterschied zwischen > und >> ist deshalb wichtig:

Umleitung

Wirkung

>

Datei erstellen oder bisherigen Inhalt ersetzen

>>

Datei erstellen oder Text am Ende anhängen

Eine weitere Zeile hängst du so an:

echo 'Eine weitere Notiz.' >> notizen.txt

Achte bei > besonders auf den Zielpfad: Die Umleitung kann vorhandene Inhalte überschreiben, ohne vorher nachzufragen.

Mehrere Zeilen mit einem Here-Document schreiben

Für einen mehrzeiligen Text eignet sich ein Here-Document:

cat > notizen.txt <<'EOF'
Projekt: Linux-Grundlagen

Aufgaben:
- Verzeichnisstruktur vorbereiten
- Notizen sammeln
- Links ausprobieren
EOF

Alles zwischen der ersten Zeile und dem abschließenden EOF wird als Eingabe an cat übergeben und in die Datei geschrieben. Der Abschlussmarker muss hier allein und ohne zusätzliche Leerzeichen in seiner Zeile stehen. Durch die Anführungszeichen in <<'EOF' werden beispielsweise Variablen wie $HOME im Text nicht ausgewertet. Auch hier ersetzt > einen vorhandenen Dateiinhalt.

Verzeichnisse mit mkdir erstellen

mkdir steht für „make directory“ und legt Verzeichnisse an:

mkdir Projekte

Mehrere Verzeichnisse kannst du in einem Aufruf erstellen:

mkdir Dokumente Bilder Skripte

Auch absolute und relative Pfade sind möglich:

mkdir ~/Projekte/linux-labor

Ohne zusätzliche Optionen müssen die übergeordneten Verzeichnisse bereits vorhanden sein. Außerdem meldet mkdir einen Fehler, wenn der gewünschte Name schon existiert.

Ganze Verzeichnisstrukturen mit mkdir -p

Mit -p legt mkdir fehlende übergeordnete Verzeichnisse gleich mit an:

mkdir -p ~/Projekte/linux-labor/notizen

Falls nötig, entstehen dabei nacheinander Projekte, linux-labor und notizen. Bereits vorhandene Verzeichnisse werden akzeptiert und bleiben erhalten. Das macht mkdir -p besonders praktisch für wiederholt ausgeführte Vorbereitungen und Skripte.

Mehrere Unterverzeichnisse kompakt vorbereiten

In Bash kannst du die Klammererweiterung verwenden:

mkdir -p ~/Projekte/linux-labor/{notizen,skripte,daten}

Die Shell erweitert den Ausdruck zu drei Pfaden. mkdir erhält diese anschließend als einzelne Argumente. Die geschweiften Klammern sind also eine Funktion der Shell, nicht von mkdir.

Die gewünschte Struktur:

linux-labor/
├── daten/
├── notizen/
└── skripte/

Links verstehen: Keine gewöhnlichen Kopien

Ein Link ist nicht einfach eine zweite, unabhängige Kopie einer Datei. Linux unterscheidet zwei grundlegende Arten:

• Ein harter Link ist ein weiterer Name für dieselbe Datei.
• Ein symbolischer Link ist eine eigene Datei, die einen Pfad zu einem Ziel enthält.

Diese Unterscheidung erklärt, warum sich die beiden Linktypen beim Verschieben, Löschen und Bearbeiten unterschiedlich verhalten.

Symbolische Links mit ln -s erstellen

Ein symbolischer Link – auch Symlink oder Softlink genannt – verweist über einen gespeicherten Pfad auf eine Datei oder ein Verzeichnis. Er kann auch auf ein Ziel in einem anderen Dateisystem zeigen.

Die Grundform lautet:

ln -s ZIEL LINKNAME

Ein Beispiel für eine Datei:

ln -s notizen.txt notizen-link.txt

Befinden sich Link und Zieldatei im selben Verzeichnis, verweist notizen-link.txt damit auf notizen.txt.

Auch ein Verzeichnis kannst du auf diese Weise zugänglich machen:

ln -s ~/Projekte/linux-labor ~/labor

Über ~/labor erreichst du nun das Verzeichnis ~/Projekte/linux-labor. Es entsteht keine Kopie seines Inhalts.

Absolute und relative Linkziele

Ein absolutes Linkziel beschreibt den vollständigen Weg ab /:

ln -s /var/log systemprotokolle

Ein relatives Linkziel wird dagegen vom Verzeichnis aus ausgewertet, in dem der Link liegt – nicht vom späteren Arbeitsverzeichnis des Benutzers. Das ist eine der wichtigsten Regeln beim Erstellen von Symlinks.

Beispiel:

linux-labor/
├── daten/
│   └── beispiel.txt
└── links/

Wenn du in linux-labor stehst, erstellst du den passenden Link so:

ln -s ../daten/beispiel.txt links/beispiel-link.txt

Warum ../daten/beispiel.txt? Der Link liegt in links. Von dort führt der Weg eine Ebene nach oben und anschließend in daten.

Relative Links bleiben auch dann brauchbar, wenn du die gesamte Struktur verschiebst und die Beziehung zwischen Link und Ziel gleich bleibt. Absolute Links sind dagegen an den angegebenen vollständigen Zielpfad gebunden.

Was passiert, wenn das Ziel fehlt?

Ein symbolischer Link kann erstellt werden, obwohl sein Ziel noch gar nicht existiert. Wird das Ziel später verschoben oder gelöscht, bleibt der Link ebenfalls bestehen – zeigt aber ins Leere. Man spricht dann von einem defekten oder „dangling“ Link.

Das Linkziel kannst du dir anzeigen lassen:

readlink links/beispiel-link.txt

Für das obige Beispiel lautet die Ausgabe:

../daten/beispiel.txt

readlink zeigt dabei den gespeicherten Verweis an.

Harte Links mit ln erstellen

Ohne -s erstellt ln standardmäßig einen harten Link:

ln original.txt weiterer-name.txt

Dafür muss original.txt bereits existieren. Anschließend bezeichnen beide Namen dieselbe Datei. Es gibt keinen technisch bevorzugten „Originalnamen“ und keine unabhängige Kopie.

Dieselbe Datei unter zwei Namen

Ein einfaches Beispiel:

echo 'Erste Zeile' > original.txt
ln original.txt weiterer-name.txt
echo 'Zweite Zeile' >> weiterer-name.txt
cat original.txt

Die Ausgabe enthält beide Zeilen:

Erste Zeile
Zweite Zeile

Der zusätzliche Text ist über beide Namen sichtbar, weil dieselbe Datei verändert wurde.

Eine wichtige Einschränkung: Manche Programme speichern Änderungen, indem sie die bisherige Datei durch eine neue ersetzen. In diesem Fall kann ein bearbeiteter Name anschließend auf eine andere Datei zeigen und die Verbindung zum anderen harten Link verlieren. Ein harter Link ist deshalb kein allgemeines Synchronisationswerkzeug.

Gleiche Inode erkennen

Mit ls -li kannst du die Inode-Nummern vergleichen:

ls -li original.txt weiterer-name.txt

Harte Links auf dieselbe Datei besitzen innerhalb desselben Dateisystems dieselbe Inode-Nummer. Die Inode repräsentiert die Datei und ihre Metadaten; die Namen stehen in den jeweiligen Verzeichniseinträgen.

Grenzen harter Links

Für die gewöhnliche Verwendung unter Linux gelten zwei wichtige Einschränkungen:

• Harte Links können keine Dateisystemgrenzen überschreiten.
• Harte Links auf Verzeichnisse sind für normale Benutzeroperationen nicht vorgesehen.

Wird einer der Dateinamen entfernt, bleibt die Datei über die anderen harten Links erreichbar. Genau deshalb ist „Original und Verknüpfung“ hier das falsche Denkmodell: Es handelt sich um gleichwertige Namen derselben Datei.

Symbolische und harte Links im Vergleich

Die wichtigsten Unterschiede ergeben sich daraus, ob ein Pfad gespeichert oder ein weiterer Name für dieselbe Datei angelegt wird.

Eigenschaft

Symbolischer Link

Harter Link

Erstellen

ln -s ZIEL LINKNAME

ln DATEI LINKNAME

Prinzip

Verweis über einen Pfad

Zusätzlicher Name derselben Datei

Eigene Inode

Ja

Nein, gemeinsame Inode mit der verlinkten Datei

Für Verzeichnisse geeignet

Ja

Im normalen Gebrauch nein

Über Dateisystemgrenzen hinweg

Ja

Nein

Ziel darf beim Erstellen fehlen

Ja

Nein

Verhalten beim Entfernen des Zielnamens

Kann ins Leere zeigen

Datei bleibt über weitere Namen erreichbar

Für bequem erreichbare Verzeichnisse sind symbolische Links meist die passende Wahl. Harte Links sind dann interessant, wenn bewusst mehrere Namen für dieselbe Datei innerhalb eines Dateisystems benötigt werden.

Links sind allerdings kein Ersatz für ein Backup: Ein Symlink enthält keine Sicherung des Ziels, und ein harter Link schützt nicht vor Änderungen an den gemeinsam genutzten Dateiinhalten.

Praxisübung: Eine kleine Arbeitsumgebung erstellen

Die folgende Übung verbindet Verzeichnisse, Dateien und beide Linktypen. Verwende dafür ein neues Übungsverzeichnis, damit die Umleitung keine vorhandene Arbeitsdatei überschreibt.

Schritt 1: Verzeichnisse vorbereiten

mkdir -p ~/linux-erstellen-uebung/{dokumente,links}
cd ~/linux-erstellen-uebung

Schritt 2: Dateien erstellen

touch dokumente/aufgaben.txt
echo 'Meine Linux-Notizen' > dokumente/notizen.txt

Schritt 3: Einen symbolischen Link anlegen

ln -s ../dokumente/notizen.txt links/notizen-symbolisch.txt

Der Zielpfad beginnt mit .., weil er aus Sicht des Verzeichnisses links ausgewertet wird.

Schritt 4: Einen harten Link anlegen

ln dokumente/notizen.txt links/notizen-hart.txt

Hier gibst du die vorhandene Datei relativ zu deinem aktuellen Arbeitsverzeichnis an. ln legt dafür einen weiteren Namen an; es speichert keinen Zielpfad wie bei einem Symlink.

Schritt 5: Das Ergebnis untersuchen

ls -li dokumente/notizen.txt links/notizen-hart.txt
ls -l links/notizen-symbolisch.txt
readlink links/notizen-symbolisch.txt

Du solltest erkennen:

• Die beiden harten Dateinamen besitzen dieselbe Inode-Nummer.
• Der symbolische Link zeigt in der langen Ausgabe mit einem Pfeil auf sein Ziel.
• readlink gibt ../dokumente/notizen.txt aus.

Fazit: Das passende Werkzeug bewusst wählen

Mit touch legst du leere Dateien an, ohne vorhandene Inhalte zu löschen. Mit Ausgabeumleitungen erstellst du Dateien direkt mit Text. mkdir baut Verzeichnisstrukturen auf, und mkdir -p übernimmt dabei auch fehlende übergeordnete Ebenen.

Bei ln entscheidet das Prinzip: Ein symbolischer Link verweist auf einen Pfad, ein harter Link gibt derselben Datei einen weiteren Namen. Wer diesen Unterschied versteht, kann Verweise gezielt einsetzen und typische Fehler bei relativen Linkzielen vermeiden.

Alt...

Dateien, Verzeichnisse und Links unter Linux erstellen

Ça peut intéresser du monde (pour l'usage perso ou pro) alors voilà un petit retour à chaud sur l'impression de prints chez soi avec une Canon Pixma iX6850 sur un pc sous Linux (Mint). Je résume tout à la fin.

Vous l'avez peut-être vu : en début de semaine j'ai complètement crashé parce que mon imprimante "pro" a fait de même pour cause de buses mortes. Comme mon boulot c'est (d'essayer) de vendre les créations que je réalise, j'ai dû chercher rapidement une nouvelle machine. Comme je ne suis pas super à l'aise j'ai dû faire avec un budget limité.

On m'a conseillé pas mal de modèles chez Brother ou chez Epson (notamment la EcoTank 8500 qui a une assez bonne réputation) et je vous remercie pour ces reco  mais c'était un poil cher pour mon budget comme je viens de le dire. Après avoir pas mal tourné sur les internets, j'ai vu que la Canon iX6850 était considérée comme un bon compromis avec un très bon rapport qualité-prix entre 180 et 200€.

J'ai reçu la bête rapidement, j'ai bouffé plein d'encre et de papier pour les tests et après 2 jours bien chargés, je peux confirmer que pour une imprimante jet d'encre à 4 couleurs (CMJN) (+ du noir pigmenté), elle a l'air de bien faire le taf.
Sur la base de recommandations, j'ai changé de papier pour utiliser le Mat Photo Paper (MP101) de Canon.
Les résultats de ce combo sont probants : couleurs vives et plutôt bien respectées, netteté au poil, rendu global très largement suffisant pour faire des tirages d'art (je n'ai pas encore testé sur papier photo brillant). Elle n'est pas super rapide mais c'est dans l'ordre du raisonnable. Elle prend aussi pas mal de place car elle permet de tirer des formats en A3+ (que j'ai juste testés mais je vais me limiter à du A4 sans marges.)

Pour ce qui est de la consommation d'encre, je ne peux pas faire de retours car, pour le moment, je n'ai cramé que les encres vendues avec la machine (donc des cartouches avec des capacités réduites). J'ai commandé un jeu de consommables XL de la marque. On verra ce que ça donne avec les impressions pendant la période de Noël. (Normalement j'utilise des compatibles mais là je préfère ne rien risquer côté machine et garantie) (et oui je sais que les cartouches c'est l'arnaque mais seuls les gens qui ont les moyens de se payer un truc cher dès le début peuvent éviter de se faire arnaquer. La théorie des bottes de Vimaire, tout ça...)

Pour la connectivité on est sur un modèle qui date un peu (2014, autrement dit les dinosaures dans le monde de l'informatique) mais il est compatible avec les impressions sans fil via PC, Android (CanonPrint) et Apple (AirPrint). C'est moyennement intuitif car il n'y a pas d'écran de contrôle mais ça se fait plutôt bien, un appui sur un bouton de l'imprimante, on active le WPS sur la box internet et hop.
Je n'ai pas testé sur Windows mais j'imagine que c'est très bien reconnu niveau pilotes. Idem sur Mac.
Pour Linux, bon... Les pilotes officiels ne sont pas/plus disponibles sur le site de Canon et j'ai l'impression qu'il n'y a pas de pilotes génériques (gratuits) pour ma Linux Mint. Je dis que "j'ai l'impression" parce qu'en début de semaine, dans le vain espoir de régler via des réglages mes problèmes avec l'autre imprimante, j'ai installé la version d'essai de TurboPrint (gestionnaire d'imprimantes plutôt poussé) et c'est lui qui a reconnu directement la iX6850. L'interface est un tantinet vieillotte mais il y a tous les réglages possibles, ça fait plaisir. Sauf le prix (entre 40 et 70€ en fonction des options qu'on veut).

Pour résumer, ce retour après un usage intensif mais à chaud quand même de la Canon iX6850 :

Inconvénients
- modèle ancien
- gabarit imposant (mais logique vu les formats d'impressions)
- système à cartouches d'encre (plus cher que des réservoirs)
- besoin d'un outil payant sur Linux
- pas super rapide

Avantages :
- bon rapport qualité/prix
- tirages de qualité
- moins de consommables (donc moins chers) que d'autres modèles à cartouches
- impressions jusqu'au A3+
- impressions sans fil

Pour les réglages et combo de papiers : il y aura peut-être des choses à affiner mais sur TurboPrint je suis en réglages de base pour les couleurs, l'intensité et le reste + le mode perception photo. Le tout avec le papier Canon MP101. Et c'est très quali (attention le MP101 ne s'imprime que sur une seule face)

Pour le budget, je compte 175€ d'imprimante + 40€ de TurboPrint (pilotes + gestionnaire impression Linux).
Le paquet de 50 feuilles de Canon Mat Photo Paper (MP101) est dans les 18€.
Le kit d'encre est dans les 45-50€ pour les quantités standard, 70-90€ pour la version XL.

En espérant ne pas vous faire de retours dans quelques mois en expliquant que finalement c'est juste de la merde.
Allez je retourne vider les cartouches de tests.

#FediArt #Art #Prints #Impression #Materiel #Recommandation #Imprimante #Linux

Alt...

Photo de mon bureau chargé avec de la déco ancienne et mes écrans d'ordinateur et de tablette graphique, un clavier, une souris et plusieurs tirages A4 et A3 imprimés avec la machine mentionnée et qu'on voir sur le coté gauche. Elle est large, noire et brillante. On peut remarquer sa taille grâce à un tirage A3 dans le bac de sortie. En plus de tout ça il y a une petite peluche sanglier à coté d'un écran et une grosse peluche ragondin sur l'imprimante

Im vorherigen Beitrag ging es darum, wie sich Befehle aus einem Befehlsnamen, Optionen und weiteren Argumenten zusammensetzen. Der nächste Schritt ist nicht, möglichst viele davon auswendig zu lernen. Wichtiger ist, selbstständig herauszufinden, welcher Befehl eine Aufgabe lösen kann und wie er verwendet wird.

Linux bietet dafür verschiedene Hilfesysteme: Mit apropos lassen sich passende Befehle suchen, man und info liefern Dokumentation, help erklärt Bash-interne Funktionen und tldr zeigt kompakte Anwendungsbeispiele. Diese Werkzeuge ergänzen sich, statt einander vollständig zu ersetzen.

Der grundlegende Ablauf: Suchen, verstehen, anwenden

Wenn der passende Befehl noch unbekannt ist, kann der Weg so aussehen:

Aufgabe formulieren
        │
        ▼
Mit apropos nach passenden Befehlen suchen
        │
        ▼
Einen Treffer auswählen
        │
        ▼
Dokumentation oder Beispiele aufrufen
        │
        ▼
Befehlsaufbau und Optionen verstehen
        │
        ▼
Mit eigenen Übungsdaten ausprobieren

Du musst dabei nicht jedes Mal alle Hilfesysteme verwenden. Manchmal reicht eine kurze Hilfeausgabe. Für eine unbekannte oder riskante Option ist eine ausführlichere Beschreibung sinnvoll.

apropos: Einen Befehl für eine Aufgabe finden

Du möchtest Dateien kopieren, kennst den passenden Befehl aber noch nicht? Dann hilft die Suche nach einem Stichwort:

apropos copy

apropos durchsucht die Namen und Kurzbeschreibungen der verfügbaren Manualpages. Es durchsucht standardmäßig nicht den vollständigen Text sämtlicher Handbuchseiten.

Da viele Beschreibungen auf Englisch vorliegen, sind englische Suchwörter häufig hilfreich. Die konkreten Treffer hängen von der installierten Dokumentation und deren Sprache ab.

Eine Ergebniszeile könnte sinngemäß so aussehen:

cp (1) - copy files and directories

Daraus lassen sich drei Dinge ablesen:

• cp ist der Name des dokumentierten Befehls.
• (1) bezeichnet den Handbuchabschnitt.
• Die Kurzbeschreibung nennt seinen Zweck.

Die Suche auf Benutzerbefehle beschränken

Manchmal erscheinen sehr viele Treffer, darunter auch Programmierschnittstellen. Mit einer Abschnittsauswahl lässt sich die Suche eingrenzen:

apropos -s 1 copy

-s 1 beschränkt die Suche auf Abschnitt 1, in dem gewöhnliche Benutzerbefehle dokumentiert werden.

Eine entsprechende Suche ist auch über man möglich:

man -k copy

Bei der verbreiteten man-db-Implementierung verwendet man -k dieselbe Art von Stichwortsuche wie apropos.

Wichtig: Kein Treffer bedeutet nicht automatisch, dass kein geeignetes Programm existiert. Die Suche hängt von den vorhandenen Handbuchseiten und ihrer Suchdatenbank ab.

man: Die Handbuchseite eines Befehls lesen

Wenn der Befehlsname bekannt ist, lässt sich seine Manualpage öffnen:

man cp

man zeigt die passende Handbuchseite an. Dort finden sich je nach Programm beispielsweise Zweck, Aufrufsyntax, Optionen, Besonderheiten und Verweise auf weitere Dokumentation.

Welche Bereiche sind zuerst interessant?

Viele Handbuchseiten folgen einer ähnlichen Gliederung:

Bereich

Inhalt

NAME

Name und kurze Beschreibung

SYNOPSIS

Schematischer Befehlsaufbau

DESCRIPTION

Ausführliche Erklärung

OPTIONS

Optionen und ihre Bedeutung, teilweise auch innerhalb der Beschreibung

EXAMPLES

Anwendungsbeispiele, sofern vorhanden

SEE ALSO

Verweise auf verwandte Dokumentation

Nicht jede Handbuchseite enthält alle diese Abschnitte. Die Gliederung hilft aber, gezielt zu lesen, statt sofort das gesamte Dokument durcharbeiten zu müssen.

Auszug aus der cp-Manpage

Gerade hier zahlt sich das Wissen aus dem vorherigen Beitrag aus: Eine Zeile wie

Befehl [Optionen] Quelle Ziel

ist eine Beschreibung des Aufbaus. Eckige Klammern und Platzhalternamen werden nicht einfach wörtlich übernommen.

In einer Manpage navigieren

man verwendet einen Seitenbetrachter, häufig less. In dieser üblichen Kombination helfen folgende Tasten:

Taste

Funktion

Leertaste

Weiterblättern

Pfeiltasten

Zeilenweise bewegen

/Suchwort und Enter

Vorwärts nach einem Begriff suchen

n

Zum nächsten Suchtreffer

q

Ansicht verlassen

Der verwendete Seitenbetrachter ist konfigurierbar; deshalb kann die Bedienung abweichen.

Du musst eine Manpage also nicht wie einen Roman lesen. Häufig genügt es, den Aufruf zu verstehen und anschließend gezielt nach der benötigten Option zu suchen.

Was bedeuten die Abschnittsnummern?

Ein Name kann in mehreren Handbuchabschnitten vorkommen. Häufig relevant sind:

Abschnitt

Typischer Inhalt

1

Benutzerbefehle

2

Systemaufrufe

3

Bibliotheksfunktionen

5

Dateiformate und Konfigurationsdateien

8

Administrationsbefehle

Mit einer Nummer lässt sich ein bestimmter Abschnitt auswählen.

man 1 printf

Das öffnet die Dokumentation des Benutzerbefehls printf, sofern sie installiert ist. Für die Bash-interne Variante ist dagegen help printf die gezieltere Anlaufstelle.

info: Zusammenhängende Handbücher lesen

Manpages sind oft kompakte Referenzen. GNU-Info-Dokumentation ist dagegen häufig stärker als zusammenhängendes Handbuch mit Kapiteln, Menüs und Querverweisen aufgebaut.

Ein Einstieg ist:

info bash

Vorausgesetzt, das entsprechende Handbuch ist installiert, öffnet info die Bash-Dokumentation.

Auch umfangreiche Programmsammlungen können ein gemeinsames Handbuch besitzen:

info coreutils

Info-Dokumente bestehen aus miteinander verknüpften Abschnitten, sogenannten Nodes. Über Menüs und Verweise gelangst du von der Übersicht zu einzelnen Themen.

Ausschnitt aus der Info-Page von Bash

Grundlegende Bedienung

Im eigenständigen GNU-Info-Programm sind unter anderem diese Tasten hilfreich:

Taste

Funktion

Leertaste

Weiterlesen

n

Zum nächsten zugeordneten Abschnitt

p

Zum vorherigen zugeordneten Abschnitt

u

Zur übergeordneten Ebene

h

Hilfe zur Bedienung

q

Info verlassen

Die Navigation folgt der Struktur des Handbuchs. Sie ist deshalb nicht in jedem Detail mit dem Blättern in einer Manpage identisch.

info lohnt sich besonders, wenn du nicht nur die Bedeutung einer Option nachschlagen, sondern ein Konzept gründlicher verstehen möchtest. Der Befehl info info zeigt übrigens die Infopages zu info selbst ab.

help: Hilfe für Bash-interne Befehle

Nicht jeder eingegebene Befehl startet ein externes Programm. Bash enthält eigene Befehle und Sprachkonstruktionen. Für diese stellt sie normalerweise den eingebauten Befehl help bereit.

Beispiele:

help cd

help read

help printf

Diese Aufrufe erklären die jeweiligen Bash-Funktionen. Ein alleinstehendes

help

zeigt die verfügbaren Hilfethemen an. Mit -s lässt sich die Ausgabe auf eine kurze Syntaxübersicht beschränken:

help -s cd

help ist kein allgemeines Linux-Hilfesystem

help ist hier eine Funktion von Bash. Andere Shells können andere Hilfemöglichkeiten verwenden. Selbst Bash kann mit abweichendem Funktionsumfang gebaut werden. Man sollte deshalb nicht voraussetzen, dass help in jeder Shell oder jeder reduzierten Umgebung vorhanden ist. Für Bash-interne Befehle ist es aber normalerweise der direkteste Einstieg.

Wenn unklar ist, was hinter einem Befehlsnamen steckt, hilft:

type cd

type zeigt beispielsweise, ob Bash einen eingebauten Befehl, einen Alias, eine Funktion oder ein externes Programm verwenden würde.

5. –help: Eine Option des aufgerufenen Programms

help und --help sehen ähnlich aus, sind aber unterschiedliche Dinge:

help cd

Hier wird der Bash-Befehl help ausgeführt.

ls --help

Hier wird ls mit der Option --help gestartet. Das Programm selbst liefert die Hilfeausgabe. Bei GNU-Programmen ist diese Option üblich.

Viele Bash-interne Befehle geben ebenfalls auf --help eine Hilfemeldung aus. Die verlässlichere und ausdrücklich für ihre Dokumentation vorgesehene Bash-Schnittstelle ist jedoch help Befehlsname.

Weder --help noch eine alternative Schreibweise wie -h ist bei sämtlichen Programmen garantiert. Die Bedeutung einer Option bestimmt immer das jeweilige Programm. Deshalb ist „einfach überall -h anhängen“ keine allgemeingültige Regel.

tldr: Verständliche Beispiele für häufige Aufgaben

Eine ausführliche Referenz beantwortet nicht immer sofort die Frage: „Wie sieht ein typischer Aufruf aus?“

Hier setzt das gemeinschaftlich gepflegte Projekt tldr-pages an. Es bietet kurze Beschreibungen und ausgewählte Beispiele für häufige Anwendungsfälle.

Mit einem passenden Client lautet der Aufruf beispielsweise:

tldr cp

Oder:

tldr tar

Statt sämtliche Optionen aufzulisten, zeigen die Seiten typische Aufgaben und dazugehörige Befehlsmuster. Das macht sie besonders zugänglich für den Einstieg.

Nutzung von tldr mit dem Befehl cd

tldr ergänzt man – es ersetzt die Referenz nicht

tldr ist keine automatisch gekürzte Ausgabe der jeweiligen Manpage. Die Seiten werden eigenständig von der Community gepflegt und konzentrieren sich auf Beispiele. Für Sonderfälle, genaue Einschränkungen oder seltene Optionen bleibt die Originaldokumentation wichtig.

Außerdem ist ein tldr-Client nicht überall vorinstalliert. Es gibt verschiedene Clients und auch eine Webansicht; Installation, Aktualisierung und Cache-Verhalten unterscheiden sich je nach Client.

In Fedora kann ich tldr wie folgt installieren:

sudo dnf install tldr

Welches Werkzeug passt zu welcher Frage?

Deine Frage

Passender Einstieg

„Welcher Befehl könnte diese Aufgabe lösen?“

apropos Stichwort

„Was bedeutet diese Option genau?“

man Befehl

„Ich möchte das Thema ausführlich verstehen.“

info Handbuch

„Wie funktioniert dieser Bash-interne Befehl?“

help Befehl

„Ich brauche eine kurze Optionsübersicht.“

Befehl --help, sofern unterstützt

„Wie sieht ein typischer Aufruf aus?“

tldr Befehl

Diese Auswahl folgt den unterschiedlichen Aufgaben der Hilfesysteme. Du musst dich nicht dauerhaft für eines entscheiden.

Ein praktischer Lernweg: Vom Suchwort zum verstandenen Aufruf

Angenommen, du möchtest Dateien kopieren, kennst den Befehl aber noch nicht.

Schritt 1: Einen passenden Befehl suchen

apropos -s 1 copy

Du suchst in den Beschreibungen der Benutzerbefehle nach einem passenden Werkzeug. Ein möglicher Treffer ist cp.

Schritt 2: Beispiele ansehen

tldr cp

Die Beispiele vermitteln einen ersten Eindruck vom Aufbau.

Schritt 3: Eine wichtige Option genau nachlesen

man cp

Dort kannst du beispielsweise die Option -i nachschlagen. Sie fordert eine Rückfrage vor dem Überschreiben einer vorhandenen Zieldatei an.

Schritt 4: Den Aufruf zerlegen

cp -i quelle.txt kopie.txt

Bestandteil

Bedeutung

cp

Kopieren

-i

Vor dem Überschreiben nachfragen

quelle.txt

Quelldatei

kopie.txt

Zieldatei, sofern hier kein Verzeichnis dieses Namens gemeint ist

Dieser Aufruf verändert Dateien und setzt eine vorhandene Quelldatei voraus. Er sollte nur mit eigenen Übungsdateien ausprobiert werden.

Du hast damit nicht einfach eine Zeile übernommen. Du hast den Befehl gefunden, Beispiele betrachtet und seine Wirkung anhand der Referenz geprüft.

Wenn Dokumentation fehlt

Gerade auf minimalen Systemen oder in Containern können Programme und ihre Dokumentation getrennt vorliegen. man, info, die jeweiligen Handbuchdateien oder ein tldr-Client müssen dann gegebenenfalls nachinstalliert werden.

Eine fehlende lokale Hilfeseite sagt deshalb nicht automatisch, dass der Befehl unbekannt oder falsch ist. Die Werkzeuge greifen auf unterschiedliche Dokumentationsbestände zurück. Alternativ kommen die offiziellen Online-Handbücher des Projekts infrage. Dabei sollte die Dokumentation möglichst zur eingesetzten Programmversion passen.

Fazit: Nicht alles wissen, sondern gezielt nachschlagen

Nach dem Verständnis der Kommandosyntax folgt der nächste wichtige Schritt: eigenständig Informationen finden und einen Aufruf begründen können.

apropos hilft bei der Suche, man bei der genauen Referenz, info beim vertieften Verständnis und tldr bei typischen Beispielen. Für Bash-interne Befehle ist help besonders nützlich; --help liefert bei vielen Programmen eine schnelle Übersicht, ist aber nicht universell verfügbar.

Das Ziel ist nicht, jede Option im Kopf zu behalten. Es ist, aus einer Aufgabe einen passenden, verstandenen und bewusst ausgeführten Befehl zu machen.

Alt...

Hilfe in der Linux-Shell finden: Mit apropos, man, info, help und tldr

Im ersten Teil ging es um die Theorie: was LoRa ist, was MeshCore daraus macht und warum ich hier bei MeshCore gelandet bin. Jetzt wird es praktisch. Bevor ein Repeater aufs Dach kommt, braucht man erst einmal ein Gerät, mit dem man selbst im Mesh mitreden kann. Bei MeshCore heißt das Companion: ein kleiner LoRa-Node, der per Bluetooth am Smartphone oder am PC hängt und für dich funkt. Ich habe dafür einen Heltec WiFi LoRa 32 V4 genommen. Es gibt natürlich noch mehr und auch Geräte, die kein Smartphone brauchen aber ich mag es mit dem Smartphone zusammen.

Was in der Box steckt

Mein erstes Board war ein einzelner Heltec V4 mit GPS. In der kleinen Plastikbox lagen die Platine, eine Federantenne mit u.FL-Stecker (oft IPEX genannt), ein GPS-Modul mit achtadrigem Kabel, zwei JST-Kabel für Akku oder Solarzelle und zwei Stiftleisten, die nicht eingelötet sind. Auf der Box steht „LoRa Band, HP 863-928 MHz“, auf der Platine selbst HTIT-WB32LAF V4.3. Das ist die Revision 4.3 mit dem Frontend KCT8103L, also einem zusätzlichen Leistungsverstärker (PA) und rauscharmen Vorverstärker (LNA) vor dem eigentlichen LoRa-Chip SX1262. Der Rechner auf dem Board ist ein ESP32-S3 mit 16 MB Flash und 2 MB PSRAM, dazu kommen ein kleines OLED, USB-C und zwei Taster.

Lieferumfang des Heltec V4: Board, GPS-Modul, Federantenne, zwei JST-Kabel und Stiftleisten. Achtung, auf diesem Foto steckt die Antenne noch an der 2,4-GHz-Buchse. Doof ich bin.

Später habe ich mir noch das Komplettset geholt: Heltec V4 ohne GPS, dafür mit fertigem Gehäuse und 3000-mAh-LiPo. Auf dem läuft heute mein persönlicher Node „Kernel-Error“. Wer einfach nur schnell ins Mesh will, ist mit diesem Set besser bedient als ich mit meinem nackten Board, denn Gehäuse und Akku sind dann schon erledigt. Wie der erste Heltec danach ins Auto gewandert ist, steht weiter unten.

Ab Werk war auf dem Board Meshtastic 2.7.22 installiert. Ein meshtastic --info über USB lief sofort. Die Region stand auf UNSET, so sendet das Board gar nicht, bevor man eine Region gesetzt hat. Das finde ich vernünftig, so schreit das Ding nicht schon in die Luft, ganz ohne config. Ich wollte aber MeshCore, also musste die Firmware runter.

Achtung: Der Heltec V4 hat zwei identische IPEX-Buchsen. LoRa ist die Buchse an der Spitze der Platine, auf der Oberseite direkt neben dem GNSS-Stecker. Die andere sitzt unten neben dem ESP32-S3 und gehört zum 2,4-GHz-Teil. Und schick nie ein Paket raus, ohne dass an der LoRa-Buchse eine Antenne oder ein Abschlusswiderstand hängt. Die Sendeleistung muss irgendwo hin, sonst kommt sie zurück und kann die PA beschädigen. Also erst die Antenne, dann USB. Wenn ihr das dann noch direkt richtig anschließt und nicht, wie ich, einfach mal fummelt….

So ist es richtig: Die Federantenne steckt an der LoRa-Buchse an der Spitze, direkt neben dem GNSS-Kabel. Auf dem Display steht der BLE-PIN fürs Pairing.

Erst sichern, dann flashen

Bevor ich irgendetwas überschreibe, ziehe ich ein komplettes Abbild des Flashs. Damit komme ich jederzeit zurück auf den Werkszustand. Klar könnte ich einfach wieder die Meshtastic Firmware drüber brennen. Ich bin aber schon ein paar mal mit so etwas auf die Nase gefallen und die drei Minuten für eine Sicherung habe ich dann doch. Der ESP32-S3 meldet sich über seinen nativen USB-Port als /dev/ttyACM0, einen USB-Seriell-Wandler gibt es auf dem Board nicht. Mit esptool schaue ich zuerst, was überhaupt verbaut ist, und lese dann die vollen 16 MB aus. Das hat bei mir knapp 100 Sekunden gedauert.

$ esptool --port /dev/ttyACM0 flash-id
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
Features:           Wi-Fi, BT 5 (LE), Dual Core + LP Core, 240MHz, Embedded PSRAM 2MB (AP_3v3)
Detected flash size: 16MB

$ esptool --port /dev/ttyACM0 --baud 921600 read-flash 0 ALL backup/heltec-v4-factory-16MB.bin

Die Zeile mit dem PSRAM ist wichtig für die Wahl der richtigen Firmware. MeshCore baut für den V4 mehrere Varianten: heltec_v4, heltec_v4_r8 und jeweils noch _tft-Versionen. Das „R2“ im Produktnamen steht für den ESP32-S3R2 mit 2 MB PSRAM, und das bestätigt esptool. Also heltec_v4. Die r8-Variante benutzt andere Pins für Display-Versorgung und LED, mit dem falschen Image bleibt das Display dunkel. Ratet doch mal, woher ich das so genau sagen kann? Nicht, dass noch das Gefühl aufkommt, dass ich hier Ahnung von dem hätte, was ich mache. Wie immer: Korrigiert mit bitte. Ich will was lernen.

Die Releases auf GitHub sind nach Rolle getrennt: Companion, Repeater und Room Server haben eigene Tags. Für das Handgerät brauche ich den Companion mit Bluetooth, also eine Datei nach dem Muster heltec_v4_companion_radio_ble-<version>-merged.bin. „merged“ heißt, dass Bootloader, Partitionstabelle und Anwendung in einem Image stecken, das ab Adresse 0x0 geschrieben wird. Die SHA-256-Summe habe ich gegen den Digest des GitHub-Assets geprüft, dann den Flash gelöscht, damit keine Meshtastic-Reste liegen bleiben, und das Image geschrieben (vergesst das mit dem Löschen nicht, kommt sonst schnell mal spannendes bei herum):

$ gh release download companion-v1.17.1 -R meshcore-dev/MeshCore -p 'heltec_v4_companion_radio_ble-v1.17.1-d929643-merged.bin'
$ sha256sum heltec_v4_companion_radio_ble-v1.17.1-d929643-merged.bin
$ esptool --port /dev/ttyACM0 erase-flash
$ esptool --port /dev/ttyACM0 --baud 921600 write-flash 0x0 heltec_v4_companion_radio_ble-v1.17.1-d929643-merged.bin

Die 1,3 MB waren in unter fünf Sekunden drauf. Wer keine Lust auf die Kommandozeile hat, kann auch den Web-Flasher von MeshCore im Browser nehmen. Den habe ich selbst nicht benutzt, das Backup vorher solltest du aber in beiden Fällen machen.

Eine Sache aus dem Quellcode der V4-Variante muss man kennen: Dort steht LORA_TX_POWER=10 mit dem Kommentar, dass daraus am Ende 22 dBm werden. Die Sendeleistung in der App ist auf diesem Board die Ausgangsleistung des SX1262, die externe PA legt laut diesem Kommentar etwa 12 dB obendrauf. Eine „22“ in der App bedeutet beim Heltec V4 also nicht 22 dBm an der Antenne. Mein Companion bleibt deshalb auf 10, dem Wert, den MeshCore für den V4 ohnehin mitbringt. Was das für die Grenzwerte heißt, rechne ich in Teil 4 durch. Ja, hehe… Der cliffhanger bleibt auch hier.

Pairing mit der App

Nach dem Flashen bootet das Board direkt in MeshCore und zeigt auf dem OLED einen sechsstelligen PIN. Den gibt man beim Bluetooth-Pairing in der MeshCore-App ein. Der PIN wird bei jedem Start neu gewürfelt. Der Companion nimmt immer nur einen BLE-Client gleichzeitig an. Hängt das Handy dran, findet der PC das Gerät nicht, und umgekehrt. Was mich bestimmt 10 min. meines Lebens gekostet hat, das zu realisieren.

Beim ersten Verbinden fragt die App nach einem Funk-Preset. Hier im Rheinland funkt die Community mit „EU/UK (Narrow)“, das sind 869,618 MHz, 62,5 kHz Bandbreite, Spreading Factor 8 und Coding Rate 8. Welches Preset in deiner Gegend gilt, solltest du bei der lokalen Community nachschauen, denn mit anderer Frequenz, Bandbreite oder anderem Spreading Factor hörst du schlicht niemanden. Die Coding Rate steht dagegen im LoRa-Header, ein Empfänger mit Coding Rate 5 versteht also auch Pakete mit Coding Rate 8. Danach bekommt der Node einen Namen. Meiner heißt „Kernel-Error“.

Die Node-Einstellungen in der App. Unter dem Namen steht die Kurzform des öffentlichen Schlüssels, die Position wird nicht im Advert geteilt.

Erstes Advert, erste Nachrichten

Ein Advert ist die Visitenkarte eines Nodes: Name, öffentlicher Schlüssel, Typ und optional eine Position, signiert mit dem privaten Schlüssel, aber nicht verschlüsselt. Ein Companion verschickt so etwas nur, wenn du es auslöst. Als Flood-Advert geht es über die Repeater in die Fläche, als Zero-Hop-Advert erreicht es nur die direkte Nachbarschaft.

Nach meinem ersten Flood-Advert war die Kontaktliste leer. Das ist normal und hat mich trotzdem kurz irritiert. Ein Advert holt keine Liste aus dem Netz, Kontakte tauchen erst auf, wenn du die Adverts der anderen hörst, und Repeater senden die nur in längeren Abständen. Etwas Geduld hilft also. Bei mir hat es zusätzlich etwas länger gedauert, weil die Antenne an der falschen Buchse steckte, siehe oben. Ja, ich bin einer von denen, die auf dem ersten Foto die Antenne an der falschen Buchse hatten.

Ob eine Nachricht wirklich rausgegangen ist, zeigt dir die App selbst. Unter jeder eigenen Kanalnachricht zeigt sie an, wie viele Repeater sie wiederholt haben. Hört dein Companion einen Repeater deine Nachricht weitersenden, ist sie im Mesh. Diese „heard repeats“ empfiehlt auch Mesh Rheinland zum Testen. Bei mir stand unter dem ersten „geht“ im Public-Kanal „1 Repeater empfangen“, drumherum liefen Testnachrichten aus Velbert, Euskirchen und Lengerich.

Der Moment, in dem es funktioniert: „1 Repeater empfangen“ unter der eigenen Nachricht heißt, dass ein Repeater sie weitergesendet hat.

Avatar per Emoji

Ein Profilbild kann man nicht hochladen. Die App erzeugt die Farbe des Icons aus dem Namen und zeigt den ersten Buchstaben. Steht am Anfang des Namens ein Emoji, nimmt die App das statt des Buchstabens. Ich habe mich zuerst „😈 Kernel-Error“ genannt, das kommt dem FreeBSD-Daemon am nächsten, einen echten Beastie gibt es als Emoji leider nicht. Falls jemand ein Unicode-Zeichen für Beastie kennt, sagt gerne Bescheid, ich schaue dann nach, ob die App es mitmacht. Der Name darf maximal 31 Byte lang sein, ein Emoji frisst davon meist vier. Nach dem Umbenennen ein Flood-Advert schicken, damit die anderen den neuen Namen lernen. Am Schlüssel ändert sich nichts. Das kleine OLED kann übrigens keine Emojis darstellen und zeigt nur den Text.

Nach ein paar Stunden füllt sich die Kontaktliste. Oben steht der Node mit Emoji im Namen.

Kontakte und warum der Schlüssel zählt

Wie in Teil 1 beschrieben, ist die Identität eines Nodes sein Schlüsselpaar und der Name nur ein Etikett. Die App zeigt deshalb neben jedem Kontakt eine Kurzform des öffentlichen Schlüssels, die ersten und letzten acht Hex-Zeichen, bei mir <b2035736...84ce8610>. Wenn du sicher sein willst, dass du wirklich mit der Person schreibst, die du meinst, vergleich diesen Fingerprint über einen anderen Weg: persönlich, am Telefon oder über eine Webseite, der du vertraust. Erst dann ist der Kontakt verifiziert.

Standardmäßig wird jedes gehörte Advert zum Kontakt. Das wird schnell viel: Die Kontakttabelle ist auf dem Heltec-BLE-Build auf 350 Einträge begrenzt, und im Rheinland gibt es viele Repeater. Ist die Tabelle voll und „älteste überschreiben“ aus, landen neue Kontakte nicht mehr in der Liste. Die Firmware reicht das Advert dann zwar noch an die App weiter und meldet, dass der Speicher voll ist, speichert den Kontakt aber nicht. Ich habe deshalb auf selektives Hinzufügen umgestellt: Chats, Repeater und Room Server ja, Sensoren nein, maximal drei Hops entfernt, älteste überschreiben an. Favoriten werden beim Überschreiben nicht angefasst, die eigenen wichtigen Kontakte sollte man also als Favorit markieren.

Die App kann die komplette Node-Konfiguration als JSON exportieren und wieder importieren. Achtung: In diesem Export steckt der private Schlüssel, und dazu die zuletzt bekannte Position, auch wenn du sie nicht im Advert teilst. Behandle die Datei wie einen privaten SSH-Schlüssel. Wer ihn hat, kann sich als dein Node ausgeben und deine Direktnachrichten lesen. Hier deshalb nur ein bereinigter Auszug mit den Teilen, die wirklich etwas einstellen:

"radio_settings": {
  "frequency": 869618,
  "bandwidth": 62500,
  "spreading_factor": 8,
  "coding_rate": 8,
  "tx_power": 10
},
"other_settings": {
  "manual_add_contacts": 1,
  "advert_location_policy": 0
},
"auto_add_settings": {
  "auto_add_chat": true,
  "auto_add_repeater": true,
  "auto_add_room_server": true,
  "auto_add_sensor": false,
  "overwrite_oldest": true,
  "auto_add_max_hops": 4
}

manual_add_contacts: 1 schaltet das selektive Hinzufügen ein, erst dann wirken die auto_add_*-Schalter. auto_add_max_hops: 4 bedeutet bis zu drei Hops, 0 hieße ohne Grenze. advert_location_policy: 0 hält die Position aus dem Advert raus. Ein Companion, der meistens zu Hause liegt, würde sonst die Wohnadresse ins Netz senden. Wenn du so etwas übernehmen willst, setz die Werte in der App oder kopier nur diese Blöcke. Einen fremden Export mitsamt Schlüssel zu importieren, klont eine fremde Identität, und zwei Nodes mit demselben Schlüssel bringen das Routing für beide durcheinander.

Die Einstellungen, auf die es ankommt

Zwei Einstellungen stehen nicht im Export und müssen von Hand gesetzt werden: die Größe der Pfad-Hashes und der Default-Scope. Den Pfad-Hash habe ich auf 2 Byte gestellt, damit sich Repeater auf dem Weg seltener verwechseln lassen. Der Default-Scope steht auf #de, weil die Repeater hier ungescopte Floods ignorieren. Beides erkläre ich ausführlich in Teil 6. Die Funkwerte entsprechen dem Preset, zur Sendeleistung von 10 steht oben schon alles. Ein Board ohne externe PA würde man dagegen mit seiner echten Ausgangsleistung einstellen.

Die Companion-Einstellungen von Kernel-Error: Sendeleistung 10, Pfad-Hash 2 Byte, Default-Scope #de, Position im Advert aus und Repeat-Modus aus.

Der Schalter „Repeat-Modus aktivieren“ sieht verlockend aus, macht aber nicht, was man erwartet. Laut Quellcode der Companion-Firmware ist er nur auf 433,000, 869,495 oder 918,000 MHz erlaubt. Auf 869,618 MHz lehnt die Firmware ihn ab. Wer ihn einschaltet, zieht also auf eine andere Frequenz um und verlässt das Netz der Community. Gedacht ist das für Off-Grid-Gruppen ohne Repeater. Bei meinen Companions bleibt er aus, das Weiterleiten erledigen hier die Repeater.

Kanäle

Neben Direktnachrichten an Kontakte gibt es Kanäle. Jeder MeshCore-Companion kennt den Kanal „Public“. Dessen Schlüssel 8b3387e9c5cdea6ac9e5edbaa115cd72 ist überall gleich und öffentlich, die Verschlüsselung schützt dort also vor niemandem im Mesh. Dazu kommen Hashtag-Kanäle wie #nrw, #bonn oder #rheinbach. Bei denen wird der Schlüssel per SHA-256 aus dem Namen abgeleitet. Wer den Namen kennt, kann mitlesen. Privat sind nur Kanäle mit einem selbst erzeugten, geheim geteilten Schlüssel.

Jeder Kanal kann zusätzlich einen eigenen Scope tragen, meinen Public-Kanal habe ich auf de gestellt. Welcher Scope für welchen Kanal sinnvoll ist und wie du den tatsächlich wirksamen Scope prüfst, steht in Teil 6. Ein Nebeneffekt, den man sofort sieht: Mit Scope begrenzt die App die maximale Nachrichtenlänge im Kanal auf 120 statt 130 Zeichen. Die Firmware selbst kürzt dabei nichts, der Transport-Code steckt im Paketkopf und nicht in den Nutzdaten.

Mein Kontakt als QR-Code

Über „Kontakt teilen“ erzeugt die App einen QR-Code. Darin steckt eine Adresse der Form meshcore://contact/add?name=...&public_key=...&type=1, also nur Name, öffentlicher Schlüssel und Typ (1 steht für Chat). Position, Zeitstempel und Signatur fehlen. Der Code beweist deshalb nicht von selbst, dass er von mir stammt. Das Vertrauen kommt hier aus dem Kanal: Du hast ihn aus meinem Blog. Wenn du mich hinzufügen willst, scann den Code und vergleich den Fingerprint mit <b2035736...84ce8610>. Der volle Schlüssel lautet:

b203573688347b345a560e0a8156ecc6c0dc7d14c4f53046064bfabe84ce8610

Mein Companion „Kernel-Error“ als MeshCore-Kontakt. Der Code enthält nur Namen und öffentlichen Schlüssel.

Viel gebe ich damit nicht preis. Name und Schlüssel stehen ohnehin in jedem Advert, das mein Node sendet. Was dazukommt, sind vielleicht ein paar ungefragte Direktnachrichten. Die nehme ich in Kauf.

Ein Gehäuse aus dem Drucker

Mein erstes Board lag anfangs nackt auf dem Tisch. Für unterwegs habe ich mir das Modell „WiFi LoRa 32 V4 (Heltec V4)“ von Adi_CEvil auf MakerWorld in Rot gedruckt. Danke dafür. Heltec und ein 1100-mAh-LiPo passen hinein, geladen wird über USB-C. Beim Filament lieber keine Varianten mit Carbon- oder Metallanteil nehmen, leitfähige Füllstoffe direkt an der Antenne verstimmen sie und schlucken Leistung. Ihr wickelt das Teil ja auch nicht in Alufolie ein, oder?

Fertig für die Hosentasche: Heltec V4 mit LiPo im gedruckten Gehäuse. Das OLED zeigt den Namen ohne Emoji, der kleine Font kennt keine Emojis.

Vom Linux-Rechner aus: meshcore-cli und Meshy

Am PC benutze ich zwei Werkzeuge. Für die Kommandozeile gibt es meshcore-cli, installiert mit pipx, der Befehl heißt dann meshcli. Gekoppelt wird über BlueZ. Vorher am Handy Bluetooth aus, denn es gibt nur den einen BLE-Platz. Nach dem Pairing hält bluetoothctl die Verbindung gern offen, dann findet meshcli das Gerät nicht. Ein disconnect löst das.

$ pipx install meshcore-cli
$ bluetoothctl
[bluetooth]# agent KeyboardOnly
[bluetooth]# pair <BLE-MAC>
  (PIN vom OLED eingeben)
[bluetooth]# trust <BLE-MAC>
[bluetooth]# disconnect <BLE-MAC>
$ meshcli -a <BLE-MAC> ver
Model: Heltec V4.3 OLED

Mit meshcli komme ich an Dinge, die die App nicht zeigt, etwa die Funkstatistik mit get stats_radio oder node_discover, bei dem Repeater in direkter Reichweite mit ihren Empfangswerten antworten. Den Pfad-Hash kann man dort mit set path_hash_mode 1 auf 2 Byte stellen. Ein Tipp aus der Praxis: meshcli 1.6.5 holt die Kontakte mit einem Timeout von 5 Sekunden. Bei über hundert Kontakten über BLE reicht das nicht, dann behauptet das Tool, es gäbe keine. Die Python-Bibliothek dahinter mit längerem Timeout schafft es.

Für den Alltag am Schreibtisch nehme ich Meshy, einen grafischen MeshCore-Client für den Linux-Desktop. Meshy verbindet sich ebenfalls per BLE, zeigt Geräteinfos, Kontakte, Kanäle und eine Karte und kann Adverts senden, Pfade tracen und Nodes in der Nähe suchen.

Meshy unter Linux: Geräteinfo des Companions, hier noch mit Firmware v1.17.1.

Kontakte in Meshy. Favoriten stehen oben, daneben steht, ob der Weg bekannt ist (Direct) oder geflutet wird (Flood).

Der Public-Kanal in Meshy. Unter jeder Nachricht stehen Hop-Anzahl und, falls vorhanden, der Scope.

KiekR auf Android

Auf dem Handy bin ich inzwischen bei KiekR gelandet, einer alternativen Android-App von Marcel Verdult (kiekr.app). Sie ist Closed Source, das sollte man wissen. Mir gefällt sie trotzdem besser als die offizielle App, weil sie mehr vom Funk zeigt: den Scope pro Nachricht, eine Statistik und vor allem „Live-Funk“, eine Rohansicht aller empfangenen Pakete, auch der, die der Node nicht entschlüsseln kann. KiekR ersetzt die offizielle App, parallel geht wegen des einen BLE-Platzes nicht.

Die Chatliste in KiekR. Die App meldet sogar Hashtag-Kanäle, die in der Nähe gehört wurden.

An einem Morgen zu Hause hat der Live-Funk innerhalb weniger Minuten 250 Pakete gezeigt, rund 23 pro Minute. 232 davon waren für meinen Node nicht lesbar. Das ist kein Fehler, das sind Direktnachrichten, Anfragen und Antworten anderer Nodes und Kanäle, deren Schlüssel ich nicht habe. Schön zu sehen war auch, wie weit gescopte Floods laufen: Eine Anfrage mit Scope de kam über 17 und 18 Hops, mit 1-Byte-Pfad-Hashes. Jeder dieser Hops kostet Sendezeit. Warum das relevant ist, steht in Teil 6.

Live-Funk in KiekR: Die meisten Pakete sind verschlüsselt und nicht für diesen Node. Oben ein gescopter Flood über 17 Hops.

336 Kontakte bei einem Limit von 350: Ohne „älteste überschreiben“ wäre die Tabelle bald voll.

KiekR hat außerdem optionale Community-Funktionen, etwa das Hochladen gehörter Repeater-Adverts auf Karten oder einen Observer-Modus, der Rohpakete an Analyse-Seiten weiterreicht. Die sind standardmäßig aus. Bevor du sie auf einem mobilen Node einschaltest, überleg kurz, was sie über deine Wege verraten.

Firmware-Update ohne Datenverlust

Mitten im Projekt erschien MeshCore v1.18.0 (Release-Notes). Unter anderem kann der BLE-Build für den Heltec V4 seitdem auch WLAN. Beim Update will ich weder Identität noch Kontakte verlieren, also gehe ich so vor:

• Erst wieder ein volles 16-MB-Backup mit read-flash. Darin steckt der private Schlüssel, die Datei bekommt Rechte 600 und bleibt auf dem eigenen Rechner.
• Die Partitionstabelle aus dem Backup lesen. Bei mir liegt die Anwendung ab 0x10000, Identität, Kontakte, Kanäle und Einstellungen liegen in einer eigenen Datenpartition weiter hinten.
• Prüfen, ob Bootloader und Partitionstabelle im neuen Merged-Image identisch sind. Nur dann reicht es, das reine App-Image an 0x10000 zu schreiben.
• Kein erase-flash. Damit bleiben Datenpartition und BLE-Kopplung unangetastet.

$ esptool --port /dev/ttyACM0 --baud 921600 read-flash 0 ALL backup/companion-before-1.18.0-16MB.bin
$ chmod 600 backup/companion-before-1.18.0-16MB.bin
$ esptool --port /dev/ttyACM0 --baud 921600 write-flash 0x10000 heltec_v4_companion_radio_ble-v1.18.0-81dbae5.bin

Das Schreiben hat acht Sekunden gedauert. Danach meldete sich der Node mit v1.18.0-81dbae5, gleichem Schlüssel, gleichem Namen, allen 244 Kontakten, allen Kanälen, 2-Byte-Pfad-Hash und Default-Scope #de. Auch das Pairing mit dem Handy hielt. Nur die Uhr lief nach den Resets ein paar Minuten hinterher. Nach einem Update also kurz die Zeit vom Handy oder PC synchronisieren. Keine Angst, hier fühlt man sich ganz schnell wieder zuhause, wenn man schon mal mit arduino, esp usw. gearbeitet hat.

Geräte-Info in der App nach dem Update auf v1.18.0.

Ein zweiter Node mit GPS fürs Auto

Als das Komplettset da war, habe ich meine Identität „Kernel-Error“ auf das neue Board umgezogen. SUPER WICHTIG: Ein Schlüssel gehört nur einem aktiven Gerät. Also zuerst das alte Board komplett löschen und neu flashen, dann auf dem neuen Board den gesicherten Export importieren. Pfad-Hash und Default-Scope stehen nicht im Export und müssen auf beiden Geräten neu gesetzt werden.

Das alte Board mit dem GPS-Modul hat einen neuen Schlüssel bekommen und wohnt jetzt als „ErrorCar“ im Auto. Die Position sendet es nicht im Advert. Stattdessen darf genau ein Kontakt, mein persönlicher Node, sie per Telemetrie abfragen. Die Antwort ist verschlüsselt, Repeater unterwegs sehen nur Chiffretext, und ohne Anfrage verrät das Auto gar nichts. Achtung: Das klappt nur, wenn neben der Standort-Telemetrie auch die Basis-Telemetrie für diesen Kontakt freigegeben ist, sonst antwortet der Node niemandem. Was ich mit dem Auto-Node sonst noch mache, zeige ich in Teil 5 über MeshMapper. Aber ich werde an dem Punkt nicht der Einzige sein, der den Satz „ich kann remote also die GPS Position abfragen?“ im Kopf hatte. Damit ist auch klar, warum ich an Sensoren denke und öhm einen GPS Tracker?!

Was du jetzt tun kannst

Wenn du selbst einsteigen willst, ist das Heltec-V4-Komplettset mit Gehäuse und 3000-mAh-Akku der bequemste Weg: Antenne an die LoRa-Buchse, Backup ziehen, MeshCore drauf, Preset deiner Region wählen, Advert senden und im Public-Kanal auf das erste „Repeater empfangen“ warten. Wer gleich einen Companion fürs Auto oder ein zweites Board für einen eigenen Repeater haben möchte, bekommt den Heltec V4 mit L76K-GPS im Doppelpack. Eins solltest du dabei wissen: Der V4 ist ein ESP32-S3 mit zusätzlichem Verstärker und braucht deutlich mehr Strom als Boards mit nRF52-Chip, etwa der RAK4631. Für meinen Einstieg war mir das egal. Wer lange am Akku laufen will, schaut sich besser so ein Board an. Und wenn du mich hinzufügst, freue ich mich über ein kurzes „Moin“ per Direktnachricht.

Siehe auch: Teil 1: LoRa und MeshCore, Teil 3: Der Repeater, Teil 4: Antennen und Messen, Teil 5: MeshMapper, Teil 6: Konfiguration, die zählt.

Links zu Amazon und AliExpress sind Affiliate-Links: Kaufst du darüber, bekomme ich eine kleine Provision, für dich ändert sich am Preis nichts. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Wenn ihr Fragen habt oder euer Companion partout keinen Repeater hören will, dann dürft ihr mich gerne fragen.

Wer Linux gut bis sehr gut beherrscht, kann in unterschiedlichen Bereichen arbeiten: als Systemadministrator, Cloud Engineer, Spezialist für wissenschaftliche Rechencluster, Embedded-Entwickler oder Linux-Consultant. Konkrete Stellenanzeigen zeigen dabei eine gemeinsame Linie: Linux bildet die Grundlage, beruflich interessant wird sie durch die Verbindung mit Automatisierung, Netzwerken, Programmierung oder einer fachlichen Spezialisierung.

Linux-Kompetenz ist deshalb kein einzelnes Berufsbild, sondern ein Ausgangspunkt für mehrere Karrierewege. Dieser Beitrag zeigt anhand echter Ausschreibungen, welche Aufgaben und Anforderungen dahinterstehen – und wo ein Einstieg realistisch ist.

Die Beispiele beziehen sich auf Stellen für den deutschen Arbeitsmarkt. Recherchestand ist der 5. November 2026. Anzeigen können kurzfristig geändert oder geschlossen werden; die Auswahl bildet keine vollständige Arbeitsmarktstatistik ab.

Linux-Systemadministrator: Infrastruktur zuverlässig betreiben

Die Systemadministration ist der direkteste Berufsweg für Menschen, die Linux-Systeme einrichten, verstehen und instand halten möchten. Im Mittelpunkt stehen laufende Dienste, Benutzerzugänge, Aktualisierungen, Monitoring und die Untersuchung von Störungen.

Dass dazu inzwischen deutlich mehr als manuelle Serverpflege gehört, zeigt eine Junior-Ausschreibung von Heinlein Support.

Stellenbeispiel: Junior Linux Systemadministrator bei Heinlein Support

Der Berliner Linux- und Open-Source-Spezialist sucht Unterstützung für sein Hosting-Team. Zu den Aufgaben zählen Linux-Administration, Monitoring, Skripte und Ansible-Playbooks sowie Mitarbeit an Containerplattformen und hochverfügbaren Datenbanken. Auch eine vergütete Rufbereitschaft ist vorgesehen.

Die Anzeige nennt unter anderem:

• sicheren Umgang mit der Linux-Kommandozeile, insbesondere unter SUSE und Debian,
• Grundlagen zu Netzwerken und Berechtigungen,
• erste Erfahrungen mit Docker oder Podman,
• Kenntnisse in Bash oder Python und Git,
• Basiswissen zu Kubernetes beziehungsweise OpenShift und Infrastructure as Code,
• eine IT-Ausbildung oder ein Informatikstudium,
• fließendes Deutsch und gute Englischkenntnisse.

Bemerkenswert ist die Abstufung: Bei Linux wird Sicherheit erwartet, bei mehreren weiterführenden Technologien reichen zunächst Grundlagen oder erste Erfahrungen. „Junior“ bedeutet hier also nicht „ohne Kenntnisse“, aber auch nicht „alle Plattformen bereits vollständig beherrschen“.

Für die Stellensuche passen neben „Linux-Systemadministrator“ auch Bezeichnungen wie „Linux Administrator“ oder „Linux Systems Engineer“. Entscheidend bleibt der Aufgabenbereich, nicht allein der Titel.

DevOps und Platform Engineering: Infrastruktur automatisieren

Wer wiederkehrende Aufgaben lieber durch Code löst, findet eine Entwicklungsmöglichkeit in Richtung Automatisierung und Plattformbetrieb.

Die Grenze zur Administration ist fließend: Bereits Heinleins Junior-Admin-Stelle enthält GitLab-Pipelines, GitOps und Werkzeuge wie OpenTofu oder Terraform. Tätigkeiten, die ein Unternehmen unter „Systemadministration“ führt, können andernorts Bestandteil einer DevOps-Rolle sein.

Stellenbeispiel: Software Engineer Test Infrastructure bei STACKIT

STACKIT sucht in Berlin einen Software Engineer für die Testinfrastruktur seiner Cloud-Produkte. Die Stelle richtet sich an erfahrene Entwickler oder Softwarearchitekten. Ziel ist, Werkzeuge und Frameworks aufzubauen, mit denen Infrastrukturänderungen automatisiert überprüft werden können.

Dafür werden unter anderem verlangt:

• sehr gute Programmierkenntnisse in Go oder Python,
• Erfahrung mit Backend-Tests,
• Verständnis von REST- beziehungsweise gRPC-Schnittstellen,
• Erfahrung mit Benchmarking, Profiling und Lasttests,
• idealerweise Kenntnisse zu Linux, Kubernetes und OpenStack.

Dieses Beispiel ist keine typische Einstiegsstelle nach einem Linux-Grundkurs. Es zeigt vielmehr, wohin sich ein Linux-Profil entwickeln kann, wenn professionelle Softwareentwicklung hinzukommt.

Der Unterschied zur rein manuellen Administration liegt im Ergebnis: Nicht nur ein einzelnes System soll funktionieren. Auch seine Bereitstellung, Prüfung und Veränderung sollen reproduzierbar werden.

Site Reliability Engineer: Ausfälle verstehen und verhindern

Ein Site Reliability Engineer, kurz SRE, beschäftigt sich mit der Zuverlässigkeit von Diensten. Dabei treffen Betriebswissen, Automatisierung und Softwareentwicklung aufeinander.

Stellenbeispiel: Senior SRE für Core Messaging Infrastructure bei STACKIT

Für Bad Friedrichshall sucht STACKIT einen Senior Engineer für zentrale Messaging-Infrastruktur. Die Aufgaben umfassen hochverfügbare Nachrichtenplattformen über mehrere Rechenzentren, Failover- und Wiederanlaufverfahren sowie Automatisierung, Monitoring und Logging.

Die Anforderungen verbinden:

• Erfahrung mit verteilten Produktionssystemen,
• Message Broker wie Apache Kafka oder Solace,
• Kubernetes und das Operator-Prinzip,
• Verwaltung virtueller Maschinen, etwa mit Ansible,
• Python, Go oder Bash,
• Linux-Performance-Tuning sowie TCP/IP und DNS.

Linux ist hier unverzichtbar, aber nicht ausreichend. Gesucht wird zusätzlich Erfahrung damit, wie mehrere Systeme unter Last zusammenarbeiten und wie sich Fehler auf den gesamten Dienst auswirken.

Wer gern untersucht, warum Anwendungen langsam werden, weshalb ein Cluster ausfällt oder wie sich Wiederherstellungszeiten reduzieren lassen, findet in diesem Bereich einen passenden Schwerpunkt.

Cloud- und Virtualisierungsengineer: Die Plattform hinter den Servern

Virtuelle Maschinen zu verwenden und eine Virtualisierungsplattform weiterzuentwickeln sind unterschiedliche Aufgaben. Für Letzteres werden besonders tiefe Linux-Kenntnisse benötigt.

Stellenbeispiel: Compute Products Engineer bei STACKIT

Die Ausschreibung für Bad Friedrichshall umfasst die Weiterentwicklung von Compute-Produkten, Optimierung virtueller Maschinen einschließlich Live-Migration und die Integration von GPU- sowie Confidential-Computing-Technologien.

Gefordert werden:

• starke Kenntnisse in Go und Python,
• praktische OpenStack-Erfahrung im Produktionsbetrieb,
• fundiertes Wissen zu KVM, QEMU und libvirt,
• automatisierter Infrastrukturbetrieb in größerem Maßstab,
• Verständnis von Kernel-Verhalten, Hypervisor-Interna und systemnaher Fehlersuche.

Das ist ein möglicher Weg für Menschen, die sich nicht nur für die Verwaltung virtueller Maschinen interessieren, sondern für deren technische Grundlage.

Ein eigenes Virtualisierungslabor kann hierfür Lernpraxis liefern. Die in der Anzeige geforderte Produktions- und Skalierungserfahrung ersetzt es allerdings nicht.

HPC-Administrator: Linux für Forschung und KI-Infrastruktur

High Performance Computing, kurz HPC, bündelt Rechenleistung für anspruchsvolle Berechnungen. Die Administration umfasst Betriebssysteme, Clusterverwaltung, Storage, Netzwerke und die Unterstützung der Nutzer.

Stellenbeispiel: HPC System Administrator bei Lenovo

Lenovo sucht für ein deutsches Data-Center-Operations-Team einen HPC System Administrator.

Die Stelle umfasst unter anderem:

• Betrieb und Überwachung von HPC- und KI-Umgebungen,
• Betriebssystem-, Firmware- und Sicherheitsupdates,
• Fehleranalyse über Server, Storage und Netzwerke hinweg,
• Incident- und Problemmanagement,
• technischen Kundensupport und Wissensvermittlung.

Verlangt werden starke Linux-Kenntnisse, insbesondere in SUSE-, RHEL- und CentOS-Umgebungen, praktische Kenntnisse in Slurm und Confluent, Erfahrung mit kritischer Infrastruktur sowie fließendes Englisch.

Slurm übernimmt dabei die Planung von Rechenaufträgen im Cluster. Das Berufsbild zeigt: An KI-Infrastruktur zu arbeiten bedeutet nicht zwangsläufig, selbst KI-Modelle zu entwickeln. Auch Betrieb, Bereitstellung und Fehleranalyse sind eigenständige Aufgaben.

Ein früherer Einstieg: Studentische HPC-Administration bei Fraunhofer

Fraunhofer IAO sucht in Stuttgart eine studentische Hilfskraft für HPC-Systemadministration und Quantum Service Engineering. Erwartet werden ein einschlägiges laufendes Studium und solide Linux-Serverkenntnisse. Kenntnisse in Slurm, Containern oder Monitoring sind als Vorteil beschrieben.

Das ist ein anderer Einstieg als eine erfahrene Vollzeit-Administratorstelle – allerdings ausdrücklich an den Studierendenstatus gebunden.

Embedded-Linux-Entwickler: Linux in Geräten einsetzen

Embedded Linux verbindet Betriebssystemwissen mit Softwareentwicklung und Hardware. Statt eines gewöhnlichen Servers steht ein konkretes Produkt im Mittelpunkt.

Stellenbeispiel: Senior Embedded Linux & Yocto Engineer bei Brunel

Für Heidelberg sucht Brunel einen Senior Embedded Linux & Yocto Engineer. Zu den Aufgaben gehören hardwarenahe Anwendungen, die Integration neuer Komponenten sowie die Weiterentwicklung von Linux-Plattformen und Yocto-basierten Build-Umgebungen.

Die Anzeige verlangt:

• ein einschlägiges Studium,
• mehrjährige Embedded-Entwicklungserfahrung,
• sehr gute C/C++- und Linux-Kenntnisse,
• praktische Erfahrung mit Yocto.

Stellenbeispiel: Embedded-Linux-Entwicklung bei ABUS Security Center

Eine über das Golem-Stellenportal veröffentlichte Ausschreibung von ABUS Security Center betrifft Smart-Security-Produkte. Genannt werden C++, Python, SQL, Yocto und Linux-Kernel-Erfahrung. Neben einem Studium wird einschlägige Berufserfahrung als Quereinsteiger akzeptiert; mindestens zwei Jahre Softwareentwicklung werden dennoch erwartet.

Der entscheidende Zusatz zu Linux ist hier die Programmierung. Gute Serveradministration hilft beim Verständnis, ersetzt aber keine Entwicklungserfahrung.

Linux-Consultant: Fachwissen beim Kunden einsetzen

Linux-Beratung eignet sich für Menschen, die unterschiedliche Umgebungen analysieren und technische Entscheidungen erklären möchten.

Stellenbeispiel: Senior Consultant Linux/Open Source bei B1 Systems

B1 Systems sucht Linux-Erfahrung und fortgeschrittene Kenntnisse in einem oder mehreren der folgenden Bereiche:

• PostgreSQL,
• Ansible,
• Kubernetes,
• Ceph,
• OpenStack.

Hinzu kommen analytisches Denken, Selbstorganisation und Kommunikationsfähigkeit. Die Stelle wird überwiegend im Homeoffice mit 32 oder 40 Wochenstunden angeboten.

Die Formulierung „in einem oder mehreren“ ist aufschlussreich: Nicht jeder muss alle Plattformen gleich tief beherrschen. Eine belastbare Spezialisierung kann ein überzeugendes Profil ergeben.

B1 Systems führt außerdem Tätigkeiten für Linux-Trainer und Technical Support Engineers auf. Wer gern erklärt oder Kunden bei schwierigen Problemen unterstützt, muss sich deshalb nicht auf klassische Administration beschränken.

Welche Richtung passt zu welchen Fähigkeiten?

Aus den untersuchten Stellen ergibt sich diese Orientierung:

Linux kombiniert mit …

Mögliche Berufsrichtung

Netzwerken, Diensten und strukturierter Fehlersuche

Systemadministration

Ansible, Git, CI/CD und Infrastructure as Code

Automatisierung und Plattformbetrieb

Programmierung, Performanceanalyse und verteilten Systemen

Site Reliability Engineering

KVM, QEMU, libvirt und OpenStack

Cloud- und Virtualisierungsengineering

Slurm, Clusterbetrieb und Storage

HPC-Administration

C/C++, Yocto und Hardwareverständnis

Embedded-Linux-Entwicklung

Fachlicher Spezialisierung und Kundenkommunikation

Consulting, Support und Training

Die Tabelle verdichtet die konkreten Anzeigen. Sie ist keine verbindliche Abgrenzung der Berufsbezeichnungen.

Ausbildung, Studium oder Quereinstieg?

Die Anzeigen zeigen keine einheitliche Zugangsvoraussetzung:

• Heinlein nennt eine IT-Ausbildung oder ein Studium und interessiert sich zugleich für eigene Projekte.
• Brunels Senior-Embedded-Stelle verlangt ein einschlägiges Studium und mehrjährige Erfahrung.
• ABUS akzeptiert einschlägige Berufserfahrung als Alternative zum Studium.
• B1 nennt in der betrachteten Senior-Consultant-Anzeige keinen bestimmten Abschluss, sondern Linux-Erfahrung und technische Schwerpunkte.

Ein Quereinstieg ist damit nicht grundsätzlich ausgeschlossen. Gute private Linux-Kenntnisse werden aber auch nicht automatisch als gleichwertiger Ersatz für mehrjährige berufliche Verantwortung behandelt.

Ebenso wichtig sind Sprache und Arbeitsbedingungen. Deutschkenntnisse, Kundenkommunikation, Rufbereitschaft oder Arbeit an kritischen Produktionssystemen können die Eignung ebenso bestimmen wie die technische Werkzeugliste.

Was sollte man praktisch nachweisen können?

Aus den Anforderungen lässt sich eine sinnvolle Empfehlung ableiten: Ein Portfolio sollte mehr zeigen als erfolgreiche Installationen.

Für eine betriebsorientierte Bewerbung sind beispielsweise nachvollziehbar dokumentierte Projekte interessant, in denen Systeme automatisiert bereitgestellt, überwacht und nach einem Fehler wiederhergestellt werden. Für entwicklungsnahe Stellen sollten eigener Code, Tests und technische Entscheidungen sichtbar sein. Das entspricht den Aufgaben der betrachteten Admin-, SRE- und Entwicklungsstellen.

Nicht die Anzahl installierter Distributionen ist dabei entscheidend, sondern die Fähigkeit, ein Problem selbstständig zu verstehen und eine belastbare Lösung zu begründen.

Fazit: Aus Linux-Wissen wird durch Spezialisierung ein Berufsprofil

Linux eröffnet auf dem deutschen Arbeitsmarkt mehrere Wege: vom Junior-Systemadministrator bis zur Entwicklung von Cloud-Plattformen und eingebetteten Produkten. HPC, Consulting und technischer Support erweitern das Spektrum zusätzlich.

Der sinnvollste nächste Schritt ist deshalb nicht, möglichst viele Werkzeuge oberflächlich zu lernen. Tragfähiger ist ein klares Profil: Linux sicher beherrschen, einen passenden Schwerpunkt vertiefen und die eigenen Fähigkeiten anhand nachvollziehbarer Arbeit belegen.

Alt...

Linux als Berufsfundament: Welche Karrierewege der deutsche Arbeitsmarkt bietet

Linux läuft nicht nur auf Servern oder auf den Rechnern technikbegeisterter Anwender. Banken betreiben damit Geschäftsanwendungen, SAP stellt Cloud-Dienste darauf bereit, Microsoft verwendet eine eigene Linux-Distribution für Kubernetes und Valve liefert sein Steam Deck mit einem Linux-basierten Betriebssystem aus.

Dabei gibt es nicht die eine Distribution für alle Aufgaben. Ausschlaggebend ist der Einsatzzweck: Ein Datenbankserver benötigt andere Eigenschaften als ein Router, ein Entwicklerrechner oder ein Gaming-Handheld.

Die folgenden Beispiele zeigen öffentlich dokumentierte Einsätze. Sie beschreiben jeweils bestimmte Produkte oder Unternehmensbereiche – nicht automatisch die gesamte IT einer Firma. Stand: November 2026.

Unternehmensserver: Geschäftsanwendungen und Datenbanken

Bei geschäftskritischen Anwendungen zählen planbare Änderungen, Sicherheitsaktualisierungen, Herstellerfreigaben und verlässlicher Support. Hier spielen Red Hat Enterprise Linux und SUSE Linux Enterprise Server eine wichtige Rolle. Die passende Distribution hängt dabei häufig auch davon ab, für welche Betriebssysteme die eingesetzte Fachsoftware unterstützt wird.

Emirates NBD: RHEL für die Bankeninfrastruktur

Die Bankengruppe Emirates NBD verwendet Red Hat Enterprise Linux als Grundlage wesentlicher Teile ihrer IT. Ein Red-Hat-Bericht von 2025 nennt ausdrücklich geschäftskritische Anwendungen vom Kernbankensystem bis zu Echtzeit-Streaming. Die aktuelle Fallstudie beschreibt zusätzlich den Einsatz von OpenShift für Container, virtuelle Maschinen und KI-Anwendungen.

Hier müssen zwei Ebenen unterschieden werden: RHEL ist das Betriebssystem, OpenShift die darauf aufbauende Anwendungs- und Infrastrukturplattform. „Die Bank nutzt OpenShift“ wäre deshalb noch keine ausreichend genaue Antwort auf die Frage nach ihrer Linux-Distribution.

SAP: SLES für Cloud-Dienste und Softwareentwicklung

SAP setzt SUSE Linux Enterprise Server sowie die auf SAP-Anwendungen zugeschnittene Variante für seine Infrastruktur ein. Die veröffentlichte Fallstudie beschreibt den Betrieb von SAP-HANA-Cloud-Diensten und die Nutzung von SLES für Entwicklung, Build und Test der eigenen Software.

Auch neuere Veröffentlichungen bestätigen die Verbindung: SUSE beschreibt 2026 SLES weiterhin als Plattform, auf der SAP-Ingenieure Software entwickeln und validieren. Das Beispiel zeigt, wie eng Betriebssystem, Datenbank und Herstellerunterstützung miteinander verzahnt sein können.

Cloud und Kubernetes: Linux als Plattform für Container

Bei Containerplattformen steht häufig nicht der individuell eingerichtete Server im Mittelpunkt, sondern eine standardisierte Flotte von Rechnern. Diese Hosts stellen die Laufzeitumgebung für Container bereit und müssen möglichst konsistent aktualisiert werden können.

Microsoft: Azure Linux als Kubernetes-Host

Microsoft entwickelt mit Azure Linux eine eigene Linux-Distribution. Sie wird unter anderem als Host-Betriebssystem für Azure Kubernetes Service, kurz AKS, angeboten. Die Dokumentation beschreibt eine schlanke Zusammenstellung mit den für Container-Workloads benötigten Paketen und einer auf Azure abgestimmten Systembasis.

Damit ist Microsoft ein konkretes Beispiel für einen Anbieter, der nicht lediglich eine klassische Distribution übernimmt, sondern eine eigene Linux-Plattform für einen bestimmten Betriebszweck entwickelt.

AKS unterstützt daneben auch Ubuntu. Die Wahl des Host-Betriebssystems ist somit selbst innerhalb eines einzelnen Cloud-Dienstes nicht auf eine Distribution beschränkt.

Alpine Linux: Kleine Umgebung für Container

Alpine Linux ist eine eigenständige, schlanke Distribution auf Basis von musl und BusyBox. Das Projekt stellt ausdrücklich minimale Root-Dateisysteme für Container bereit. Es gehört damit zu den wichtigen Beispielen außerhalb der Debian-, SUSE- und RHEL-Familien.

Hier ist eine Unterscheidung entscheidend: Eine Alpine-Umgebung im Container bedeutet nicht, dass auch der Host Alpine verwendet. Microsoft dokumentiert beispielsweise ausdrücklich, dass Alpine-basierte Container auf Azure-Linux-Hosts laufen können. Container-Image und Host-Betriebssystem sind unterschiedliche Ebenen.

Virtualisierung: Viele Systeme auf einer Hardwareplattform

Linux dient nicht nur als Betriebssystem innerhalb einer virtuellen Maschine. Es kann auch die Grundlage der Plattform sein, die virtuelle Maschinen und Container betreibt.

Proxmox: Debian als Basis einer Virtualisierungsplattform

Proxmox Server Solutions entwickelt mit Proxmox Virtual Environment eine auf Debian GNU/Linux basierende Plattform. Sie kombiniert einen angepassten Linux-Kernel mit KVM für virtuelle Maschinen und LXC für Container. Speicher und Netzwerke werden über dieselbe Verwaltungsoberfläche eingebunden.

Der konkrete Einsatz lautet hier also: Proxmox nutzt Debian als Betriebssystembasis seines Virtualisierungsprodukts. Proxmox VE ist dabei mehr als eine unveränderte Debian-Installation mit einer zusätzlichen Webseite – es ist eine integrierte Plattform mit eigenen Verwaltungswerkzeugen und abgestimmten Komponenten.

Dieses Beispiel zeigt die Bedeutung der Debian-Familie auch jenseits klassischer Web- und Dateiserver: Sie liefert die Grundlage für spezialisierte Infrastrukturprodukte.

KI und Entwicklung: Treiber, Werkzeuge und reproduzierbare Umgebungen

Bei KI-Anwendungen muss mehr zusammenpassen als nur der Linux-Kernel. GPU-Treiber, Rechenbibliotheken, Container und Entwicklungswerkzeuge müssen miteinander funktionieren. Deshalb ist die offiziell unterstützte Softwarekombination oft wichtiger als eine allgemeine Rangliste der Distributionen.

NVIDIA: Ubuntu in AI Workbench und auf DGX-Systemen

Canonical und NVIDIA integrieren Ubuntu in ihre KI-Angebote. Für NVIDIA AI Workbench dokumentiert Canonical Ubuntu-basierte Container sowie Ubuntu als Grundlage der Windows-Integration über WSL2.

Auch für NVIDIA-DGX-Systeme dokumentieren die Unternehmen die Unterstützung und Optimierung von Ubuntu. Ubuntu ist damit ein konkretes Beispiel aus der Debian-Familie für professionelle KI-Infrastruktur – nicht nur für den privaten Desktop.

Die Aussage bedeutet allerdings nicht, dass jede NVIDIA-Anwendung ausschließlich unter Ubuntu läuft. Sie bezieht sich auf die dokumentierten Produkte und Integrationen.

Wissenschaft: Interaktive Systeme und Rechenaufgaben

Forschungseinrichtungen benötigen häufig große, einheitlich verwaltbare Linux-Umgebungen. Gleichzeitig müssen wissenschaftliche Anwendungen und kommerzielle Spezialsoftware unterstützt werden.

CERN: AlmaLinux und RHEL mit unterschiedlichen Aufgaben

CERN unterstützt sowohl AlmaLinux als auch Red Hat Enterprise Linux. Die aktuelle Empfehlung unterscheidet ausdrücklich nach Einsatzzweck:

• Wenn eine Anwendung Herstellersupport benötigt, beispielsweise für Oracle oder WinCC OA, soll RHEL eingesetzt werden.
• Für Dienste mit interaktivem Zugang von außerhalb des CERN, etwa lxplus oder lxbatch, wird AlmaLinux empfohlen.
• Für bestimmte nach außen verteilte virtuelle Maschinen und Container-Images schreibt CERN AlmaLinux vor.

Das ist ein besonders anschauliches Beispiel dafür, dass verwandte Distributionen nicht einfach beliebig austauschbar eingesetzt werden. Lizenzbedingungen, Weitergabe und Softwareunterstützung beeinflussen die Entscheidung.

AlmaLinux gehört zum Enterprise-Linux-Umfeld rund um RHEL. Es ist somit eine Alternative innerhalb dieses Ökosystems, kein Beispiel für eine davon unabhängige Distributionsfamilie.

Gaming: Linux als fertiges Endkundenprodukt

Linux kann auch die Grundlage eines Geräts sein, dessen Benutzer sich kaum mit dem darunterliegenden Betriebssystem beschäftigen müssen.

Valve: Arch-basiertes SteamOS auf dem Steam Deck

Valve liefert das Steam Deck mit SteamOS aus. Die aktuelle SteamOS-Generation basiert auf Arch Linux und verwendet KDE Plasma für den Desktopmodus. Für Windows-Spiele kommt unter anderem die Kompatibilitätsschicht Proton zum Einsatz; native Linux-Spiele laufen ebenfalls auf dem Gerät.

Wichtig ist die zeitliche Einordnung: Frühere SteamOS-Versionen basierten auf Debian. Das Steam Deck verwendet dagegen die Arch-basierte Generation. Wer SteamOS pauschal als Debian-Distribution bezeichnet, vermischt unterschiedliche Produktgenerationen.

Valve nutzt hier also eine Grundlage außerhalb der drei großen Enterprise- und Serverfamilien. Gleichzeitig ist SteamOS ein gezielt gepflegtes Produkt und nicht einfach eine gewöhnliche Arch-Installation mit vorinstalliertem Steam.

7. Netzwerkgeräte: Linux im Router

Ein Router benötigt keine vollständige Desktopumgebung. Im Mittelpunkt stehen Netzwerkschnittstellen, Routing, WLAN, Firewall- und VPN-Funktionen. OpenWrt ist ein auf eingebettete Geräte ausgerichtetes Linux-System mit Paketverwaltung.

GL.iNet: OpenWrt-basierte Firmware für Router

GL.iNet verwendet OpenWrt als Grundlage seiner Router-Firmware und ergänzt eigene Funktionen und Software. Ein konkretes Produkt ist der Flint 2, den der Hersteller als OpenWrt-basierten WLAN- und VPN-Router anbietet.

Dabei sind Hersteller-Firmware und unverändertes OpenWrt nicht dasselbe. GL.iNet weist selbst darauf hin, dass OpenWrt-Versionen und Treibergrundlagen je nach Gerät und Firmwarezweig unterschiedlich sein können. Das ist für Updates, Funktionsumfang und Support relevant.

OpenWrt zeigt damit eine weitere eigenständige Linux-Welt außerhalb klassischer Desktop- und Unternehmensdistributionen.

8. Embedded Linux: Maßgeschneiderte Systeme im Produkt

Nicht jedes Linux-Gerät basiert auf einer allgemein bekannten Distribution. Hersteller können eine eigene, auf ihre Hardware zugeschnittene Systemumgebung zusammenstellen.

Tesla: Angepasste Linux-Systeme mit Buildroot

Tesla veröffentlicht Quellcode für Linux-basierte Komponenten seiner Fahrzeuge. Die offizielle Open-Source-Seite nennt unter anderem Kernel- und Buildroot-Quellen für Infotainment- und Fahrerassistenzsysteme bestimmter Plattformen. Eine Stellenbeschreibung für Energieprodukte nennt außerdem die Pflege von Bootloadern, Linux-Kernels und Buildroot-Software.

Buildroot ist dabei nicht mit einer fertig installierbaren Allzweckdistribution wie Debian gleichzusetzen. Es gehört zum Werkzeugkasten für die Erstellung angepasster Embedded-Systeme. Der konkrete Einsatz ist deshalb treffender als „Tesla verwendet angepasste Linux-Systeme“ beschrieben – nicht als „Alle Tesla-Produkte laufen mit Distribution X“. Die veröffentlichten Quellen erlauben keine solche pauschale Aussage über sämtliche aktuellen Gerätegenerationen.

Die Einsatzfelder auf einen Blick

Einsatzfeld

Dokumentiertes Beispiel

Distribution oder Systembasis

Bankeninfrastruktur

Emirates NBD betreibt geschäftskritische Anwendungen

RHEL

SAP-Cloud und Entwicklung

SAP betreibt und entwickelt eigene Lösungen

SLES und SLES for SAP Applications

Kubernetes-Hosts

Microsoft bietet AKS-Knoten mit eigener Linux-Basis an

Azure Linux

Virtualisierungsplattform

Proxmox entwickelt Proxmox VE

Debian-basiert

KI-Werkzeuge und GPU-Systeme

NVIDIA integriert Ubuntu in AI-Angebote

Ubuntu

Wissenschaftliche Infrastruktur

CERN unterscheidet nach Support- und Weitergabeanforderungen

AlmaLinux und RHEL

Gaming-Handheld

Valve liefert das Steam Deck aus

Arch-basiertes SteamOS

Router und VPN-Geräte

GL.iNet entwickelt Router-Firmware

OpenWrt-basiert

Eingebettete Produktsysteme

Tesla veröffentlicht Quellen für ausgewählte Plattformen

Angepasstes Linux mit Buildroot

Fazit: Nicht die bekannteste Distribution gewinnt, sondern die passende

Die Debian-, SUSE- und RHEL-Familien bleiben wichtige Grundlagen professioneller Linux-Systeme. Die Beispiele von Proxmox, SAP und Emirates NBD zeigen ihre unterschiedlichen Rollen: Produktbasis, Plattform für Unternehmenssoftware und Betriebssystem für geschäftskritische Infrastruktur.

Daneben stehen eigenständige Ansätze wie Arch beziehungsweise SteamOS, Alpine, OpenWrt und Azure Linux. Sie zeigen, dass Linux nicht auf das klassische Servermodell beschränkt ist. Je nach Aufgabe zählen andere Eigenschaften: Herstellerfreigaben im Unternehmen, standardisierte Hosts in der Cloud, eine abgestimmte Spieleplattform oder eine möglichst gezielte Softwareauswahl im Router.

Die sinnvollste Frage lautet deshalb nicht „Welche Distribution ist grundsätzlich die beste?“, sondern: Welche Distribution lässt sich für diese Aufgabe zuverlässig betreiben, aktualisieren und unterstützen?

Alt...

Wo Linux eingesetzt wird: Von Unternehmensservern bis zur Spielekonsole

Fedora, Debian oder openSUSE: Sie alle gehören zur Linux-Welt, unterscheiden sich aber in ihrer Softwareauswahl, Verwaltung und Weiterentwicklung. Der gemeinsame Linux-Kernel bildet die technische Grundlage. Erst die zusätzlichen Programme, Werkzeuge und Dienste machen daraus ein vielseitig nutzbares Betriebssystem.

Eine Distribution stellt diese Komponenten als abgestimmtes Gesamtpaket bereit. Sie entscheidet nicht nur, welche Software verfügbar ist, sondern auch, wie diese installiert, konfiguriert, aktualisiert und gepflegt wird.

Was ist eine Linux-Distribution?

Der Linux-Kernel verwaltet grundlegende Ressourcen wie Prozessorzeit, Arbeitsspeicher und Hardwarezugriffe. Für die tägliche Arbeit benötigt ein System jedoch weitere Bestandteile: Bibliotheken, Verwaltungswerkzeuge, Dienste und Anwendungen. Eine Distribution führt diese Komponenten zusammen.

Vereinfacht lässt sich der Zusammenhang so darstellen:

Linux-Distribution
├── Linux-Kernel
├── Systembibliotheken und grundlegende Werkzeuge
├── Systemdienste
├── Paketverwaltung und Softwarequellen
└── Anwendungen und gegebenenfalls eine Desktopumgebung

Die Distribution ist dabei nicht einfach eine weitere technische Schicht oberhalb des Kernels. Sie bezeichnet die gesamte Zusammenstellung einschließlich ihrer Pflege und Bereitstellung.

Was leisten die Entwickler einer Distribution?

Die einzelnen Bestandteile eines Linux-Systems entstehen häufig in unterschiedlichen Projekten. Eine Distribution übernimmt die Aufgabe, daraus ein zusammenhängendes System zu machen.

Dazu gehören unter anderem:

• Software als installierbare Pakete bereitzustellen,
• Abhängigkeiten zwischen Paketen zu berücksichtigen,
• verfügbare Versionen aufeinander abzustimmen,
• Aktualisierungen zu veröffentlichen,
• einen nachvollziehbaren Veröffentlichungs- und Pflegeprozess festzulegen.

Wie aufwendig diese Integration ist, zeigt beispielsweise Debian: Neue Paketversionen werden nicht beliebig in den Entwicklungszweig „testing“ übernommen. Dafür müssen unter anderem Abhängigkeiten erfüllbar sein und bestimmte Fehlerkriterien eingehalten werden.

Eine Distribution ist deshalb mehr als eine Sammlung von Downloadlinks. Sie übernimmt Verantwortung für das Zusammenspiel der Komponenten.

Die Paketverwaltung: Software zentral verwalten

Eine wichtige Aufgabe der Distribution ist die Bereitstellung von Softwarepaketen. Ein Paket enthält neben Programmdateien auch Informationen, die für Installation und Verwaltung benötigt werden. Die Paketverwaltung verfolgt, welche Pakete installiert sind, und unterstützt deren Aktualisierung oder Entfernung.

Häufig kommt die Software aus zentralen Paketquellen, den sogenannten Repositories. Über diese Quellen kann ein System Programme beziehen und aktualisieren, statt jede Anwendung einzeln von einer Webseite herunterladen zu müssen.

Dabei lohnt sich die Unterscheidung zwischen Paketformat und Verwaltungswerkzeug. Fedora und Red Hat Enterprise Linux verwenden beispielsweise RPM-Pakete. Werkzeuge wie DNF arbeiten mit Paketquellen und lösen benötigte Abhängigkeiten auf. Das niedrigere Werkzeug rpm dient dagegen unter anderem zum Installieren und Abfragen einzelner Pakete.

Die Distribution legt somit nicht nur fest, welche Programme angeboten werden. Sie schafft auch den organisatorischen Rahmen für deren Pflege.

Warum gibt es unterschiedliche Distributionen?

Nicht alle Systeme müssen dieselben Anforderungen erfüllen. Ein Entwicklungsrechner profitiert möglicherweise von neuer Software. Für einen produktiven Server können lange Pflegezeiträume und möglichst vorhersehbare Änderungen wichtiger sein. Distributionen gewichten solche Ziele unterschiedlich.

Das zeigt sich besonders bei:

• der Aktualität der bereitgestellten Programme,
• dem Veröffentlichungsmodell,
• der Länge der Wartung,
• dem Umfang kommerzieller Unterstützung,
• der vorgesehenen Zielgruppe.

Es gibt deshalb nicht die eine Distribution, die für jede Aufgabe automatisch am besten geeignet ist.

Feste Veröffentlichungen und Rolling Release

Ein wesentlicher Unterschied liegt darin, wie neue Softwareversionen beim Benutzer ankommen.

Feste Veröffentlichungen

Bei einem versionsbasierten Modell erscheint zu bestimmten Zeitpunkten eine neue Distributionsversion. Innerhalb einer Veröffentlichung bleibt die Softwarebasis vergleichsweise kontrolliert, während Fehlerbehebungen und Sicherheitsaktualisierungen eingepflegt werden. Größere Änderungen werden häufig mit dem nächsten Versionswechsel gebündelt.

Fedora veröffentlicht beispielsweise ungefähr alle sechs Monate eine neue Version und pflegt jede Veröffentlichung etwa 13 Monate. Das bedeutet: Wer Fedora dauerhaft mit Sicherheitsaktualisierungen betreiben möchte, muss regelmäßig auf eine neuere Distributionsversion wechseln.

Rolling Release

Bei einem Rolling-Release-Modell wird das installierte System fortlaufend durch neue Pakete weiterentwickelt. Statt auf einen klassischen Wechsel zwischen großen Distributionsversionen zu setzen, folgt die Installation dem aktuellen Paketbestand. Arch Linux ist ein bekanntes Beispiel.

Das bedeutet allerdings nicht, dass keine Wartung nötig wäre. Änderungen an Paketen und Konfigurationen müssen weiterhin berücksichtigt werden. „Fortlaufend aktualisiert“ ist kein Synonym für „wartungsfrei“.

Was bedeutet „stabil“ bei einer Distribution?

Im Alltag wird „stabil“ häufig mit „stürzt nicht ab“ gleichgesetzt. Bei Distributionen beschreibt der Begriff aber auch eine möglichst konstante Softwarebasis: Funktionen und Versionen ändern sich innerhalb eines Veröffentlichungszweigs weniger stark.

Debian Stable setzt beispielsweise auf eine getestete Zusammenstellung. Die Pakete sind dadurch nicht zwingend die neuesten verfügbaren Versionen. Trotzdem werden Sicherheitsprobleme und wichtige Fehler im Rahmen der Pflege behandelt.

Eine ältere sichtbare Versionsnummer bedeutet daher nicht automatisch, dass ein Paket ungepflegt oder unsicher ist. Entscheidend ist auch, welche Korrekturen die Distribution für diese Version bereitstellt.

Drei Beispiele für unterschiedliche Schwerpunkte

Distribution

Charakteristischer Schwerpunkt

Debian Stable

Getestete Zusammenstellung mit vergleichsweise wenig Veränderung innerhalb einer Veröffentlichung

Fedora

Moderne Software und neue Technologien bei regelmäßigem Versionswechsel

Red Hat Enterprise Linux

Unternehmenseinsatz mit kommerzieller Unterstützung und langen Pflegezeiträumen

Diese Einordnung beschreibt Schwerpunkte, keine festen Einsatzgrenzen. Sie hilft aber, die unterschiedlichen Ziele hinter den Projekten zu verstehen.

Auch die Beziehungen zwischen Projekten sind wichtig: Fedora steht in einer vorgelagerten Entwicklungsbeziehung zu Red Hat Enterprise Linux. Beide sind dennoch eigenständige Systeme mit unterschiedlichen Veröffentlichungs- und Supportmodellen. RHEL ist deshalb nicht einfach „Fedora mit anderem Namen“.

Desktop und Distribution sind nicht dasselbe

Die sichtbare Oberfläche ist nur ein Teil des Betriebssystems. Eine Distribution umfasst ebenso die darunterliegenden Dienste, Werkzeuge, Bibliotheken und Paketquellen. Zwei Systeme können ähnlich aussehen und trotzdem unterschiedlich verwaltet werden. Umgekehrt kann dieselbe technische Grundlage mit unterschiedlichen Softwarezusammenstellungen genutzt werden.

Wer Distributionen nur anhand von Bildschirmfotos vergleicht, übersieht daher wesentliche Unterschiede. Für den langfristigen Betrieb sind Paketverwaltung, Aktualisierungen und Pflegezeiträume oft wichtiger als das voreingestellte Erscheinungsbild.

Was bedeutet das für die Linux-Administration?

Beim Lernen hilft es, allgemeine Konzepte und distributionsspezifische Werkzeuge auseinanderzuhalten.

Die Aufgabe „Software installieren“ bleibt beispielsweise gleich. Das verwendete Paketformat und die dafür eingesetzten Befehle können sich jedoch unterscheiden. Ähnliches gilt für die Organisation von Softwarequellen und Aktualisierungen.

Auch die Wartungsplanung hängt von der Distribution ab. Ein System mit ungefähr 13 Monaten Pflege pro Veröffentlichung erfordert eine andere Upgradeplanung als eine Enterprise-Distribution mit deutlich längeren Supportzeiträumen.

Für die Administration reicht es deshalb nicht, nur den Namen der Distribution zu kennen. Ebenso wichtig sind die installierte Version, deren Wartungsstatus und die vorgesehenen Aktualisierungswege.

Fazit: Die Distribution macht Linux zu einem betreibbaren Gesamtsystem

Der Kernel stellt grundlegende Betriebssystemfunktionen bereit. Die Distribution ergänzt ihn um Software, Verwaltungswerkzeuge, Paketquellen und einen Pflegeprozess. Erst dieses Zusammenspiel ermöglicht einen dauerhaft nutzbaren und wartbaren Linux-Rechner.

Die entscheidenden Unterschiede liegen daher nicht nur im Aussehen. Sie betreffen vor allem die Frage, wie Software integriert wird, wie häufig sich das System verändert und wie lange es Unterstützung erhält. Wer diese Zusammenhänge versteht, kann Linux-Systeme gezielter auswählen und zuverlässiger administrieren.

Alt...

Linux-Distributionen: Wie aus dem Kernel ein nutzbares Betriebssystem wird