Operating System — Auf Deutsch lesen

Die Titel der Geschichten stehen noch auf Englisch; der Text jeder Geschichte ist auf Deutsch.

In der Mitte des zwanzigsten Jahrhunderts waren die ersten elektronischen Computer monumentale, raumfüllende Maschinen, Triumphe der Ingenieurskunst, aber geplagt von einer kritischen Ineffizienz. Jede Berechnung, jedes Programm erforderte eine akribische manuelle Einrichtung durch hochqualifizierte Bediener. In dieser Ära kämpften brillante Köpfe mit komplexen logistischen Herausforderungen und verwandelten rohe Hardware in funktionale Werkzeuge. „Ein weiterer Job ist für die IBM Siebenhundertvier in der Warteschlange“, bemerkte Senior Operator Thompson und zeigte auf einen Stapel Lochkarten. „Wir werden zwanzig Minuten brauchen, nur um die Bandlaufwerke zu wechseln und das Patchpanel für das nächste Programm neu zu konfigurieren.“ „Zwanzig Minuten ungenutzte CPU-Zeit, dann“, seufzte Ingenieur Davis und überprüfte ein Systemprotokoll. „Das ist fast eine Viertelstunde für jeden einzelnen Job, den wir ausführen. Diese Maschine ist ein Wunder, doch sie verbringt mehr Zeit damit, auf uns zu warten, als zu rechnen.“ Thompson nickte ernst. „Unsere kostbaren Rechenzyklen gehen in diesen manuellen Übergängen verloren. Wir brauchen eine schnellere, integriertere Methode, um diese Operationen zu verwalten.“

Der mühsame Prozess, einen Computer für jede neue Aufgabe vorzubereiten, war eine tiefgreifende technische und wirtschaftliche Belastung. Jedes Programm, ob eine komplexe wissenschaftliche Berechnung oder eine einfache Datensortierung, erforderte eine vollständige manuelle Neuinitialisierung der Maschine. Dies bedeutete, die richtigen Compiler zu laden, Ein- und Ausgabegeräte zu konfigurieren und Speicherpartitionen einzurichten – alles, bevor die eigentliche Berechnung beginnen konnte. Diese „Einrichtungszeit“ führte dazu, dass diese unglaublich teuren Maschinen oft untätig dastanden und auf menschliches Eingreifen warteten, ihre immense Rechenleistung vorübergehend ruhte. „Sehen Sie sich das an“, sagte Technikerin Anya Sharma, eine Frau Ende zwanzig mit dunklem, zurückgebundenem Haar und konzentriertem Ausdruck, die ein praktisches graues Arbeitskleid trug, und zeigte auf eine große Plantafel, die die Maschinenauslastung detailliert darstellte. „Auftrag A ist fertig, dann haben wir eine fünfzehnminütige Pause für die Neukalibrierung, dann Auftrag B, eine weitere zehnminütige Pause. Es ist, als würde man eine Fabrik betreiben, in der das Fließband zwischen jedem einzelnen Artikel komplett stoppt.“ Ingenieur Davis, der seine Brille zurechtrückte, schüttelte den Kopf. „Genau. Wir verlieren jeden Tag Stunden wertvoller Rechenzeit. Diese ‚toten Zeiten‘ zwischen den Prozessen sind astronomisch. Die Maschine wartet auf uns, und wir sind ihr Engpass.“ „Das ist für ein so leistungsfähiges Werkzeug einfach inakzeptabel“, fügte Thompson hinzu und ging langsam auf und ab. „Wir brauchen ein System, das diese Übergänge automatisch verwalten, Aufträge in die Warteschlange stellen und diese kostspieligen Ausfallzeiten reduzieren kann.“

Die harte Realität der ineffizienten Maschinenauslastung spornte eine radikale Vision unter den Computerpionieren an. Was wäre, wenn die Maschine ihre eigenen Prozesse verwalten könnte? Die Idee war, ein "Masterprogramm" zu schaffen, das im Speicher des Computers residieren, die Ausführung anderer Programme orchestrieren, die Ressourcenzuweisung handhaben und menschliches Eingreifen minimieren würde. Dieses Konzept eines "Supervisor-" oder "Monitorprogramms" war der intellektuelle Vorläufer des Betriebssystems und versprach, chaotische manuelle Operationen in einen optimierten, automatisierten Arbeitsablauf zu verwandeln. „Wir brauchen ein Supervisorprogramm, einen Verkehrsregler für die internen Operationen der Maschine“, schlug Dr. Evelyn Reed vor, eine brillante Computerwissenschaftlerin Ende Dreißig mit ordentlich frisiertem braunem Haar, die einen eleganten Geschäftsanzug aus den Fünfzigerjahren trug. Sie gestikulierte auf ein komplexes Schema an einer Whiteboard. „Stellen Sie sich ein Residentprogramm vor, das Aufträge empfängt, lädt, ausführt und die Maschine dann für den nächsten vorbereitet – alles ohne eine einzige menschliche Berührung zwischen den Aufgaben.“ Ingenieur David Kim, ein junger, ernsthafter Programmierer Ende Zwanzig mit kurzen schwarzen Haaren und Brille, der ein gestärktes weißes Hemd trug, sah nachdenklich aus. „Ein Programm, das andere Programme verwaltet. Das klingt, als würde man der Maschine ein Gehirn geben, um ihre eigenen Angelegenheiten zu regeln. Die schiere Komplexität dessen... Speicherschutz, E/A-Verwaltung, Fehlerbehebung...“ Dr. Reed lächelte. „Genau. Wie Leonardo da Vinci einmal bemerkte: ‚Einfachheit ist die höchste Form der Raffinesse.‘ Unsere Herausforderung besteht nicht nur darin, zu automatisieren, sondern dieses System mit einer zugrunde liegenden Eleganz zu entwerfen, die die inhärente Komplexität der Maschine bewältigen kann. Es muss dem Programmierer einfach erscheinen, auch wenn seine inneren Abläufe kompliziert sind.“

Die theoretischen Ideen begannen sich zu praktischen Lösungen zu verdichten. Eine der frühesten und einflussreichsten Implementierungen eines Monitorsystems war das GM-NAA I/O-System, das von Robert Patrick bei General Motors und North American Aviation für die IBM Siebenhundertvier im Jahr neunzehnhundertsechsundfünfzig entwickelt wurde. Dieses wegweisende System machte den entscheidenden Schritt, die manuelle Einrichtung durch eine automatisierte Jobsequenzierung zu ersetzen. Es war ein grundlegender Sprung, der den Betrieb kostspieliger Großrechner von einem manuell gespeisten Prozess zu einem kontinuierlicheren, batch-orientierten Arbeitsablauf transformierte. „Das GM-NAA I/O-System hat unsere Operationen auf der IBM Siebenhundertvier wirklich revolutioniert“, erklärte Robert Patrick, ein konzentrierter Ingenieur in seinen späten Dreißigern mit kurzem, praktischem braunem Haar und Brille, der ein eingestecktes kurzärmeliges Hemd und eine Krawatte trug, einem besuchenden Kollegen in einem geschäftigen Labor. „Unser Ziel war einfach: die manuelle Intervention zwischen Batch-Jobs zu eliminieren. Zuvor verschwendeten wir Minuten zwischen jedem Programm.“ Seine Kollegin, Ingenieurin Sarah Chen, in ihren frühen Dreißigern mit kurzem schwarzem Haar und einer praktischen Bluse, zeigte auf ein Diagramm, das einen „Resident Monitor“ zeigte. „Dieser ‚Monitor‘ bleibt also im Speicher. Er liest Job-Kontrollkarten, lädt das Benutzerprogramm und gibt dann die Kontrolle zurück, wenn der Job erledigt ist?“ „Genau“, bestätigte Patrick. „Es ist eine Endlosschleife. Der Monitor selbst ist ein Programm, aber seine Aufgabe ist es, die Ausführung anderer Programme zu verwalten. Dies reduziert unsere Leerlaufzeiten drastisch und erhöht den Durchsatz. Kein Herumfummeln mehr mit Bändern oder Schaltern zwischen jedem Lauf.“

Das GM-NAA I/O-System funktionierte nach einem einfachen, aber tiefgreifenden Prinzip: der Stapelverarbeitung. Anstatt ein Programm nach dem anderen zu laden, bündelten die Bediener mehrere Aufträge, denen jeweils spezielle Steuerkarten vorangestellt waren, zu einem einzigen „Stapel“. Das residente Monitorprogramm las dann diese Steuerkarten sequentiell, lud automatisch das richtige Benutzerprogramm, führte es aus und räumte dann auf, bevor es zum nächsten Auftrag im Stapel überging. Diese automatisierte Sequenzierung war ein monumentaler Schritt, da sie die CPU kontinuierlich beschäftigte und die kostspieligen Wartezeiten minimierte, die die frühe Computertechnik geplagt hatten. „So funktioniert es“, erklärte Patrick und demonstrierte es an einer Steuerkonsole. „Wir bereiten einen Stapel von Programmen vor, die jeweils durch diese speziellen Steuerkarten klar abgegrenzt sind. Das Monitorprogramm selbst ist winzig, aber leistungsstark. Es läuft immer in einem kleinen Teil des Maschinenspeichers.“ Chen beobachtete, wie ein Stapel Lochkarten in ein Lesegerät eingelegt wurde. „Der Monitor liest also eine Karte, identifiziert das Programm, weist Ressourcen zu und übergibt dann die Kontrolle an das Benutzerprogramm?“ „Genau“, bestätigte Patrick. „Sobald das Benutzerprogramm seine Aufgabe abgeschlossen hat, führt es eine bestimmte Anweisung aus, die die Kontrolle an unseren Monitor zurückgibt. Der Monitor prüft dann die nächste Jobkarte, lädt das nächste Programm, und der Zyklus geht weiter. Diese automatisierte Übergabe ist der Schlüssel zur Minimierung der Leerlaufzeit. Wir haben eine Abfolge manueller Stopps in einen fließenden, kontinuierlichen Rechenstrom verwandelt.“

Während die Stapelverarbeitung die Effizienz erheblich verbesserte, führte der Computer immer noch nur ein Programm gleichzeitig aus. Der nächste logische Schritt war Multiprogramming: mehrere Programme gleichzeitig im Speicher zu halten, wobei die CPU schnell zwischen ihnen wechselte. Dies, kombiniert mit Time-Sharing, das Multiprogramming erweiterte, um mehreren Benutzern die gleichzeitige Interaktion mit dem Computer zu ermöglichen, verwandelte das Computing dramatisch von einer einzelnen, stapelorientierten Aufgabe in ein leistungsstarkes, interaktives Dienstprogramm. Frühe Bemühungen wie das CTSS (Compatible Time-Sharing System) des MIT im Jahr neunzehnhunderteinundsechzig waren entscheidend und zeigten, dass eine einzelne Maschine viele Benutzer effektiv bedienen konnte. „Die wahre Herausforderung bestand darin, die CPU-Auslastung über die einfache Stapelverarbeitung hinaus zu maximieren“, erklärte Dr. Alice Sterling, eine visionäre Informatikerin in ihren Vierzigern mit kurzem, lockigem grauem Haar und scharfen, intelligenten Augen, die eine Tweedjacke trug, ihrem Team am MIT. „Warum sollte die CPU untätig warten, bis ein I/O-Vorgang für ein Programm abgeschlossen ist, wenn sie an einem anderen arbeiten könnte?“ Der junge Programmierer Michael Chen, Anfang zwanzig mit einem ordentlichen Haarschnitt und einem eifrigen Ausdruck, der einen College-Pullover trug, beugte sich vor. „Wir laden also mehrere Programme gleichzeitig in den Speicher, und das Betriebssystem wechselt die CPU schnell zwischen ihnen? Aber was ist mit Speicherkonflikten? Und wie stellen wir die Fairness zwischen den Programmen sicher?“ Dr. Sterling nickte. „Ausgezeichnete Fragen. Dies erfordert eine ausgeklügelte Speicherverwaltung und CPU-Planung. Das Betriebssystem wird zum Schiedsrichter, der Ressourcen vermittelt und jedem Programm seinen gerechten Anteil an Prozessorzeit gibt. Es ist die Kernverantwortung des Kernels – eine kritische Abstraktionsschicht, die Programme voreinander und vor den Hardware-Komplexitäten schützt.“

Im Herzen jedes Betriebssystems liegt der Kernel, seine fundamentale Komponente. Der Kernel verwaltet die kritischsten Ressourcen des Computers: die CPU, den Speicher und die Eingabe-/Ausgabegeräte. Er fungiert als Vermittlungsschicht, die komplexe Hardwaredetails von Anwendungsprogrammen abstrahiert und eine konsistente und sichere Umgebung bietet. Zu den Schlüsselmechanismen gehören die CPU-Planung, die bestimmt, welches Programm den Prozessor wann und wie lange nutzen darf; die Speicherverwaltung, die Speichersegmente für jedes Programm zuweist und schützt; und die E/A-Verwaltung, die die Kommunikation mit Peripheriegeräten wie Tastaturen, Bildschirmen und Speichern steuert. „Der Kernel ist das Gehirn des Betriebs, das erste geladene Programm und das letzte, das den Speicher verlässt“, erklärte die leitende Architektin Dr. Lena Petrova, eine Frau Ende Vierzig mit zurückgebundenem Salz-und-Pfeffer-Haar, die einen professionellen, etwas strengen Anzug trug, einem neuen Ingenieur. „Er kümmert sich um alles, von der Prozessplanung – die entscheidet, wer an der Reihe ist auf der CPU – bis zur Verwaltung jedes Bytes an Speicher und jedes Peripheriegeräts.“ Der neue Ingenieur, Alex Johnson, Anfang Zwanzig, eifrig und aufmerksam, ein dickes Handbuch haltend, antwortete: „Wenn also ein Programm eine Datei anfordert, ist es der Kernel, der diese Anforderung in tatsächliche Festplattenoperationen übersetzt, richtig? Und er verhindert auch, dass ein Programm den Speicher eines anderen überschreibt?“ „Genau, Alex“, bestätigte Dr. Petrova und zeigte auf ein Diagramm mit konzentrischen Ringen. „Der Kernel arbeitet in einem privilegierten ‚Ring Null‘, der ihm absolute Kontrolle gibt, während Anwendungen in ‚Ring Drei‘ laufen. Dieser Schutzmechanismus ist fundamental. Er bedeutet, dass eine fehlerhafte Anwendung nicht das gesamte System zum Absturz bringen kann. Diese Abstraktionsschicht ist es, die modernes Computing stabil und effizient macht.“

In den späten Neunzehnhundertsechzigern erreichte die Entwicklung von Betriebssystemen einen entscheidenden Punkt mit der Schaffung von Unix bei Bell Labs. Hauptsächlich von Ken Thompson und Dennis Ritchie entwickelt, wurde Unix als ein einfacheres, eleganteres und, entscheidend, portableres Betriebssystem als seine Vorgänger konzipiert. Sein innovatives Design, insbesondere der Fokus auf eine Kommandozeilen-Schnittstelle, ein hierarchisches Dateisystem und das mächtige Konzept der Pipes für die Interprozesskommunikation, machte es unglaublich flexibel und anpassungsfähig. Die Effizienz und klare Architektur von Unix adressierte und löste direkt die „Leerlaufzeit“- und Ineffizienzprobleme, die in früheren Computersystemen identifiziert wurden, und ermöglichte eine beispiellose Ressourcennutzung. „Wir wollten etwas Einfaches, Elegantes und Portables“, erklärte Ken Thompson, ein konzentrierter Ingenieur Ende zwanzig mit dunklem, zerzaustem Haar und Brille, der ein lässiges Button-up-Hemd trug, Dennis Ritchie. Sie beugten sich über ein Fernschreibterminal, dessen Papierausgabe mit Code scrollte. „Multics war zu ehrgeizig, zu komplex. Wir brauchten ein System, bei dem das Betriebssystem selbst eine Sammlung kleiner, fokussierter Werkzeuge war.“ Dennis Ritchie, mit seinem charakteristischen Bart und einem nachdenklichen Ausdruck, Ende zwanzig, ein einfaches Hemd tragend, tippte einen Befehl ein. „Und genau da glänzen das Dateisystem und die Pipes wirklich. Programme wie eine Rohrleitung zu verbinden – die Ausgabe des einen wird zur Eingabe des anderen. Das schafft immense Kraft aus Einfachheit.“ „Genau“, bestätigte Thompson, die Augen auf den Bildschirm gerichtet. „Indem wir einen robusten Kernel und eine Reihe von Dienstprogrammen entwarfen, die leicht kombiniert werden konnten, erschlossen wir ein neues Maß an Produktivität. Keine verschwendeten Zyklen mehr durch komplexe Einrichtung; Unix optimiert effektiv die Maschinenzeit, verwaltet Prozesse nahtlos und ermöglicht es Entwicklern, komplexe Systeme aus einfachen Komponenten zu bauen.“

Die von wegweisenden Betriebssystemen wie Unix etablierten Prinzipien beeinflussten die nächste Computergeneration maßgeblich. Als Mikroprozessoren aufkamen, die kleinere, erschwinglichere Computer ermöglichten, wurde der Bedarf an robusten und benutzerfreundlichen Betriebssystemen von größter Bedeutung. Systeme wie CP/M, MS-DOS und später Apple DOS und das Macintosh Operating System brachten ausgeklügeltes Ressourcenmanagement und Benutzerinteraktion auf den Personal Computer. Dieser Wandel demokratisierte den Zugang zu Rechenleistung und verlagerte ihn von spezialisierten Laboren und Unternehmensrechenzentren in Haushalte, Büros und Universitäten weltweit. „Das ist unglaublich! Ich kann tatsächlich Befehle direkt eingeben und sofort Ergebnisse sehen“, rief eine junge Studentin, Maria Rodriguez, Anfang zwanzig mit lockigem schwarzem Haar und einem lässigen Pullover aus den Achtzigerjahren, als sie an einem frühen Apple II Computer in einem Universitätslabor saß. „Das ist nicht wie die Batch-Jobs, die unsere Professoren beschreiben. Ich habe das Gefühl, ich spreche mit dem Computer.“ Ihr Kommilitone, David Lee, Anfang zwanzig mit glattem schwarzem Haar und nachdenklichem Ausdruck, eine Jeansjacke tragend, beugte sich vor. „Das ist die Macht des Betriebssystems, Maria. Es verwaltet alles darunter, sodass wir uns nur auf unsere Programme konzentrieren. MS-DOS auf dem IBM PC oder die grafische Oberfläche auf dem Macintosh macht es noch einfacher. Es macht das Computing für jeden zugänglich, nicht nur für Spezialisten.“ „In der Tat“, bemerkte ihre Professorin, Dr. Eleanor Vance, in ihren Fünfzigern mit elegantem grauem Haar und einem wissenden Lächeln, einen Blazer tragend. „Das Betriebssystem bietet eine intuitive Schicht zwischen uns und der Hardware. Es verwandelte ein Werkzeug für Experten in ein Hilfsmittel für die Massen. Hier geht es nicht nur um schnellere Berechnungen; es geht darum, Individuen zu befähigen.“

Heute sind Betriebssysteme die unsichtbaren Architekten unserer digitalen Welt, eine unverzichtbare Schicht, die nahezu jedes Stück Technologie untermauert, mit dem wir interagieren. Von den leistungsstarken Servern, die globale Netzwerke antreiben, bis zu den Smartphones in unseren Taschen, von eingebetteten Systemen in Autos und medizinischen Geräten bis zur komplexen Infrastruktur des Cloud Computings verwalten, verteilen und schützen Betriebssysteme die riesige Menge an Rechenressourcen. Sie sind die stillen, konstanten Orchestratoren, die Effizienz, Stabilität und Sicherheit gewährleisten – ein Erbe der visionären Ingenieure, die versuchten, chaotische Hardware in organisierte, intelligente Systeme zu verwandeln. „Die Erzählung ist hauptsächlich visuell, mit kurzen, integrierten Beschriftungen auf den Montageszenen.“