Betriebssystem

Wozu überhaupt?

Stell dir ein Restaurant vor. Die Gäste sind die Programme, die Küche ist die Hardware. Würde jeder Gast selbst in die Küche laufen, an den Herd drängeln und im Kühlschrank wühlen, gäbe es Chaos – und jeder Gast müsste wissen, wie genau dieser Herd funktioniert.

Also gibt es Personal: Die Gäste bestellen am Tisch, das Personal teilt Herde und Zutaten zu, sorgt dafür, dass niemand fremde Teller isst, und die Gäste müssen von der Küche nichts wissen. Dieses Personal ist das Betriebssystem.

Ohne Betriebssystem müsste jedes Programm selbst wissen, wie man genau diese SSD anspricht, diese Grafikkarte, diesen WLAN-Chip. So war es tatsächlich in der Frühzeit der Computer – und so ist es heute noch bei sehr einfachen Geräten wie einer Fernbedienung.

Die Schichten

Ein Computer ist wie ein Stapel aufgebaut. Jede Schicht benutzt nur die darunterliegende. Klick dich durch:

Die entscheidende Linie ist die gestrichelte: die Grenze zwischen Benutzermodus und Kernelmodus. Der Prozessor selbst kennt diese beiden Modi. Im Benutzermodus verweigert er bestimmte Befehle – etwa direkt auf ein Gerät zuzugreifen oder fremden Speicher zu lesen. Versucht ein Programm es trotzdem, hält die CPU an und übergibt an den Kernel, der das Programm meist beendet.

Der Systemaufruf: eine Datei speichern

Was passiert eigentlich, wenn du in einem Texteditor Strg+S drückst? Eine erstaunlich lange Reise – mit einer Überraschung am Ende.

Die Überraschung steckt in Schritt 7 und 8: „Gespeichert“ heißt zunächst nur, dass der Kernel die Daten übernommen hat. Auf die SSD kommen sie oft erst Sekunden später. Deshalb gibt es „Hardware sicher entfernen“ – und deshalb rufen Datenbanken ausdrücklich fsync auf, wenn eine Buchung wirklich auf der Platte sein muss.

Interrupts: wenn die Hardware sich meldet

Der Weg geht auch umgekehrt. Kommt ein Netzwerkpaket an oder drückst du eine Taste, schickt das Gerät der CPU einen Interrupt – eine Unterbrechung. Die CPU lässt alles stehen, springt in den Kernel, der Treiber holt die Daten ab, und dann geht es weiter, wo sie war. Das passiert tausende Male pro Sekunde, ohne dass man es merkt.

Prozesse und Scheduling

Ein Programm ist eine Datei auf der Platte. Startest du es, wird daraus ein Prozess: das laufende Programm samt eigenem Speicher, offenen Dateien und einer Nummer, der Prozess-ID. Ein Prozess kann mehrere Threads haben – Ausführungsstränge, die sich den Speicher teilen.

Auf einem normalen Laptop laufen Hunderte Prozesse mit Tausenden Threads, aber nur 8 oder 16 Kerne. Wie geht das? Der Scheduler des Kernels lässt jeden Thread kurz rechnen – typischerweise wenige Millisekunden –, unterbricht ihn dann und lässt den nächsten ran. Das geht so schnell, dass alles gleichzeitig wirkt.

Das ist der Kern des Scheduling-Problems: Wer alles nacheinander abarbeitet, hat am wenigsten Wechsel-Aufwand – aber der Musikplayer stottert, weil er warten muss, bis der Compiler fertig ist. Kurze Zeitscheiben machen das System reaktionsschnell, kosten aber Wechsel. Jeder Wechsel (Kontextwechsel) bedeutet: Register sichern, anderen Thread laden, Caches werden kalt.

Echte Scheduler sind deutlich klüger als dieses Spiel. Sie bevorzugen Programme, die gerade auf Eingaben reagieren müssen, geben Hintergrundjobs weniger Zeit und verteilen auf moderne Prozessoren mit schnellen und sparsamen Kernen.

Speicher: Jeder glaubt, er hätte alles

Jeder Prozess sieht einen eigenen, riesigen Adressraum, der bei Adresse 0 beginnt – als hätte er den Arbeitsspeicher für sich allein. Das ist eine Illusion: der virtuelle Speicher. Der Speicher wird in kleine Seiten zerlegt, meist 4 KiB groß. Eine Tabelle pro Prozess, die Seitentabelle, legt fest, welche virtuelle Seite in welchem echten Speicherrahmen liegt. Die Übersetzung macht ein eigener Baustein in der CPU, die MMU, bei jedem einzelnen Speicherzugriff.

Was die Illusion leistet:

• Schutz: Prozess A kann die Speicherseiten von B gar nicht adressieren – sie stehen nicht in seiner Tabelle. Greift ein Programm auf eine nicht zugeordnete Adresse zu, beendet der Kernel es: der berühmte Segmentation fault unter Linux und macOS, unter Windows eine Zugriffsverletzung.
• Teilen: Bibliotheken, die viele Programme benutzen, liegen nur einmal im Speicher und erscheinen in vielen Seitentabellen.
• Mehr als da ist: Selten benutzte Seiten lagert das Betriebssystem auf die SSD aus (Swap oder Auslagerungsdatei). Wird so eine Seite gebraucht, gibt es einen Seitenfehler: Der Kernel holt sie zurück, das Programm merkt nur eine kurze Verzögerung. Wird das zu viel, beginnt der Rechner zu „zähen“ – er ist nur noch mit Hin- und Herschaufeln beschäftigt.

Dateien, Geräte und Treiber

Ein Dateisystem verwandelt eine SSD – im Grunde eine lange Reihe nummerierter Blöcke – in Ordner, Dateinamen, Rechte und Zeitstempel. Verbreitet sind NTFS (Windows), APFS (Apple) und ext4 oder Btrfs (Linux). USB-Sticks benutzen oft exFAT, weil es alle Systeme lesen können.

Ein Treiber ist der Übersetzer für ein bestimmtes Gerät: Der Kernel sagt „schreib diese Blöcke“, der Treiber weiß, welche Register dieses SSD-Controllers dafür wie gesetzt werden müssen. Treiber laufen meist im Kernelmodus – deshalb kann ein fehlerhafter Treiber das ganze System abstürzen lassen, was ein normales Programm nie könnte.

Was beim Einschalten passiert

Der erste Prozess startet alle weiteren. Unter Linux kann man das sehen: Prozess Nummer 1 ist der Urahn, von dem alle anderen abstammen.

Wie viel gehört in den Kernel?

Alles, was im Kernel läuft, ist schnell – aber ein Fehler darin trifft das ganze System. Darüber gibt es seit Jahrzehnten Streit. Berühmt ist die Debatte von 1992, in der der Informatikprofessor Andrew Tanenbaum Linux öffentlich „obsolet“ nannte, weil es einen großen Kernel hatte. Linus Torvalds widersprach heftig. Linux läuft heute auf Milliarden Geräten; Tanenbaums Mikrokernel-Ideen stecken trotzdem in vielen Systemen, bei denen Ausfallsicherheit zählt.

Die großen Familien

Streng genommen ist „Linux“ nur der Kernel. Ein benutzbares System entsteht erst mit den Werkzeugen und Bibliotheken drumherum – deshalb spricht man von Distributionen.

Kurze Geschichte

• 1950erStapelverarbeitung: Ein Programm nach dem anderen, Lochkarten rein, Ergebnis Stunden später.
• 1964IBM kündigt OS/360 an – ein Betriebssystem für eine ganze Rechnerfamilie.
• 1969Ken Thompson und Dennis Ritchie beginnen Unix bei den Bell Labs. Seine Ideen prägen bis heute Linux, macOS, Android und iOS.
• 1981MS-DOS auf dem IBM-PC: ein Programm zur Zeit, kaum Schutz.
• 1984Der Macintosh macht die grafische Oberfläche populär.
• 1991Linus Torvalds kündigt Linux an – „nur ein Hobby“, wie er schrieb.
• 1993Windows NT erscheint; sein Kernel steckt bis heute in Windows 11.
• 2007/2008iPhone und das erste Android-Smartphone: Betriebssysteme für die Hosentasche.

Für Entwickler übersetzt

// Was die JVM vom Betriebssystem erfährt
System.out.println(ProcessHandle.current().pid());       // Prozess-ID, vergeben vom Kernel
System.out.println(Runtime.getRuntime().availableProcessors());
// Kerne, die das OS diesem Prozess zugesteht – die JVM beachtet auch Container-Grenzen

Files.writeString(Path.of("brief.txt"), "Hallo");
// darunter: Systemaufrufe zum Öffnen, Schreiben, Schließen – ohne fsync!

Thread.ofPlatform().start(task);  // ein echter OS-Thread
Thread.ofVirtual().start(task);   // von der JVM geplant, läuft auf einem OS-Thread

Unter Linux zeigt strace -f java Hallo, welche Systemaufrufe die JVM tatsächlich macht – schon ein „Hello World“ erzeugt Tausende.

Häufige Irrtümer

Verwandte Begriffe