# Tiny Linux: Wenn jedes Kilobyte zählt

TL;DR / Management Summary Jenseits von Debian und RHEL existiert eine Welt von “Tiny Linux” Varianten. Distributionen wie Tiny Core, Slax oder Puppy Linux sind so klein (< 200MB), dass sie vollständig im RAM laufen können. Sie löschen sich beim Herunterfahren selbst und bieten maximale Sicherheit und Geschwindigkeit für Kiosk-Systeme, industrielle Controller oder als ultimatives Rettungswerkzeug für die Hosentasche.

# 1. Einführung & Architektur

Das OS im Arbeitsspeicher.

Tiny Linux Varianten nutzen meist ein schreibgeschütztes Root-Dateisystem (oft SquashFS), das beim Booten entpackt wird.

# Die RAM-Architektur (Mermaid)

graph TD
    A[Boot Medium: USB / PXE] --> B[Bootloader]
    B --> C[Kernel & initrd]
    C --> D[Load OS into RAM]
    D --> E[Read-Only Root FS]
    E --> F[Overlay: Writeable Layer in RAM]
    F --> G[Persistence: Optional Sync to Disk]

# 2. Die Protagonisten

Wahl der Spezialisten.

# Tiny Core Linux

Das wohl kleinste Linux-System mit GUI (~16MB).

• Konzept: Nutzt das Tool tce-load, um Applikationen dynamisch als Extensions nachzuladen.
• Einsatz: Thin Clients, Cloud-Instanzen mit minimalem Speicher.

# Slax

Basiert auf Debian, nutzt aber ein geniales Modul-System.

• Konzept: Applikationen sind .sb Dateien, die im laufenden Betrieb gemountet und dem Dateisystem hinzugefügt werden können.
• Einsatz: Live-Systeme zur Netzwerkdiagnose.

# 3. Day-2 Operations: Persistenz

Wie man Daten rettet.

Da diese Systeme im RAM laufen, sind Änderungen nach einem Reboot weg.

# Methoden der Speicherung

1. Home-Mounting: Das /home Verzeichnis liegt auf einer echten Disk-Partition.
2. Backup-Scripts: Beim Herunterfahren werden geänderte Dateien in ein .tar.gz Archiv geschrieben und beim nächsten Boot entpackt.
3. Cloud-Config: Die Konfiguration wird bei jedem Boot frisch von einem Web-Server geladen.

# 4. Einsatzszenarien für Admins

Warum wir sie brauchen.

# Das Rettungs-System

Ein USB-Stick mit Puppy Linux oder Slax bootet auf fast jeder Hardware (auch uralt) und ermöglicht das Mounten von defekten Partitionen und den Datentransfer via Netzwerk.

# Die Kiosk-Appliance

Ein Rechner, der nur eine einzige Webseite anzeigen soll.

• Sicherheit: Keine Festplatte = kein bleibender Befall mit Malware. Ein einfacher Reboot säubert das System zu 100%.

# 5. Troubleshooting & “War Stories”

Wenn klein zu klein ist.

# Story 1: “Der RAM-Tod”

Symptom: Ein Tiny Core System stürzt nach 2 Tagen ab, obwohl kaum Last herrscht. Ursache: Alle Schreibvorgänge (Logs, /tmp) landen im RAM-Overlay. Wenn die Logs nicht rotiert werden, ist der RAM irgendwann physisch voll. Lösung: Schalten Sie unnötiges Logging ab oder leiten Sie Logs sofort an einen externen Syslog-Server weiter (siehe Artikel 046).

# Story 2: “Das fehlende Kernel-Modul”

Symptom: Auf einem modernen Server wird die Netzwerkkarte nicht erkannt. Ursache: Tiny Linux Kerne sind oft modular aufgebaut, und die speziellen Treiber-Module (.ko Dateien) wurden aus Platzgründen nicht in das Basis-Image gepackt. Lösung: Laden Sie die passenden Modul-Extensions (tce-load oder Slax-Module) manuell nach und integrieren Sie diese in das neue Boot-Image.

# 6. Fazit & Empfehlung

• Wartung: Diese Systeme sind “Fire and Forget”. Man wartet sie nicht durch Updates, sondern ersetzt das Boot-Image durch eine neuere Version.
• Performance: Nichts ist schneller als ein OS, das komplett aus dem RAM ausgeführt wird.
• Wahl: Nutzen Sie Tiny Core für maximale Minimalisierung und Slax für die beste Debian-Kompatibilität auf Live-Systemen.

# Anhang: Cheatsheet