Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
Ein Betriebssystem, das die IT-Welt am Laufen hält - Autor Brian Kernighan ist einer der Väter von UNIX - Mit vielen Geschichten von Weggenossen und IT-Veteranen - Ein Buch für UNIX-Fans, Nerds und IT-Profis Brian W. Kernighan war in der Entwicklung von UNIX beteiligt. In diesem kurzen Band erzählt er eine umfassende Geschichte des äußerst einflussreichen und weit verbreiteten Betriebssystems und erzählt aus einer persönlichen Perspektive von den Anfängen. Unix war in seinen frühen Tagen weitgehend das Produkt von Kernighans Kollegen Ken Thompson und Dennis Ritchie von den Bell Labs. Aber Kernighan leistete fast von Anfang an aktive Beiträge. Sein persönliches Wissen verleiht dem Buch einen großen Wert. Kernighan schafft eine gelungene Balance zwischen "offizieller Geschichte" und seinem eigenen Engagement während der Entwicklung von UNIX. Die Konzepte, die mit UNIX und seinem Ökosystem zusammenhängen, erklärt er klar und methodisch. "Die UNIX-History" ist ein kurzweiliges Buch für alle, die mehr über die Geschichte hinter der Geschichte von UNIX erfahren wollen. Mit Insider-Storys und technischen Erklärungen bekommen Sie einen ganz neuen Blick auf UNIX und auf die Entwicklung von Betriebssystemen.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 302
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Brian Wilson Kernighan ist ein kanadischer Computerpionier (Jahrgang 1942). Er arbeitete lange Jahre in den Bell Labs und trug zusammen mit den Unix-Erfindern Ken Thompson und Dennis Ritchie zur Entwicklung von Unix bei.
Brian W. Kernighan
Die faszinierende Geschichte, wie Unix begannund wie es die Computerwelt eroberte
Brian W. Kernighan
Lektorat: Dr. Michael Barabas
Lektoratsassistenz: Anja Weimer
Übersetzung&Satz: G&U Language & Publishing Services GmbH, Flensburg,
www.GundU.com
Copy-Editing: Petra Heubach-Erdmann, Düsseldorf
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Herstellung: Stefanie Weidner & Frank Heidt
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über
http://dnb.d-nb.de abrufbar.
ISBN:
Print978-3-86490-778-4
PDF978-3-96910-072-1
ePub978-3-96910-073-8
mobi978-3-96910-074-5
1. Auflage 2021
Translation Copyright für die deutschsprachige Ausgabe © 2021 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Brian W Kernighan: UNIX: A History and a Memoir, 1st Edition, ISBN 978-1695978553
© 2020 by Brian W. Kernighan. All rights reserved.
This work may not be translated or copied in whole or part without the written
permission of the Author (www.kernighan.com).
Hinweis:
Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.
Schreiben Sie uns:
Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Vorwort
Danksagung
Die Bell Labs
Naturwissenschaften in den Bell Labs
Kommunikationstechnik und Informatik
Meine Zeit in den Bell Labs
Die Büros
137 → 127 → 1127 → 11276
Das Ur-Unix (1969)
Technischer Hintergrund
CTSS und Multics
Die Ursprünge von Unix
Namen sind Schall und Rauch
Biografie: Ken Thompson
Erste Version (1971)
Unix für Patentanträge
Der Unix-Raum
Das Unix-Programmiererhandbuch
Anmerkungen zum Thema Speicher
Biografie: Dennis Ritchie
Sechste Version (1975)
Das Dateisystem
Systemaufrufe
Die Shell
Pipes
Grep
Reguläre Ausdrücke
Die Programmiersprache C
Ratfor und »Software Tools«
Biografie: Doug McIlroy
Siebte Version (1976–1979)
Die Bourne-Shell
Yacc, Lex und Make
Dokumenterstellung
Sed und Awk
Andere Sprachen
Weitere Errungenschaften
Jenseits der Forschung
Programmer’s Workbench
Universitätslizenzen
Benutzergruppen und Usenix
John Lions’ Kommentar
Portierbarkeit
Kommerzialisierung
Zerschlagung
USL und SVR4
UNIX™
Public Relations
Abkömmlinge
BSD (Berkeley Software Distribution)
Die Unix-Kriege
Minix und Linux
Plan 9
Diaspora
Das Vermächtnis
Technische Aspekte
Organisatorische Aspekte
Anerkennung
Könnte sich die Geschichte wiederholen?
Quellen
Quellen
Index
In memoriam DMR
»Eine der tröstlichen Eigenschaften von alten Erinnerungen ist, dass sie oft einen rosa Schimmer annehmen. Das Gedächtnis klammert sich an die Dinge, die gut waren und Bestand hatten, und an die Freude darüber, an Verbesserungen mitgewirkt zu haben, die das Leben erleichtern.«
– Dennis Ritchie, The Evoloution of the Unix Time-sharing System, Oktober 1984
Seit das Betriebssystem Unix 1969 im Dachgeschoss der Bell Labs zur Welt gekommen ist, hat es sich weiter ausgebreitet, als seine Urheber es sich jemals hätten vorstellen können. Es hat zur Entwicklung einer großen Menge innovativer Software geführt, unzählige Programmierer beeinflusst und die Computertechnik in völlig neue Bahnen gelenkt.
Außerhalb eines bestimmten Kreises von Benutzern sind Unix und seine Abkömmlinge kaum bekannt, und doch bilden sie den Kern verschiedenster Systeme, die Bestandteil unseres Alltags geworden sind. Google, Facebook, Amazon und viele andere Dienste laufen auf Linux, einem Unix-artigen Betriebssystem, über das ich weiter hinten noch mehr schreiben werde. Auf Handys und Macs wird eine Unix-Version ausgeführt. Auch Geräte wie Alexa und Navigationssoftware für Autos nutzen Unix-artige Systeme. Wenn Sie im Web mit Werbung überschüttet werden, stecken ebenfalls Unix-Systeme dahinter, und die Trackingeinrichtungen, die herauszufinden versuchen, was Sie im Web machen, um Sie noch gezielter mit Reklame zu bombardieren, basieren sehr wahrscheinlich ebenfalls auf Unix.
Unix wurde vor über 50 Jahren hauptsächlich von zwei Personen sowie einer kleinen Gruppe von Mitarbeitern erschaffen. Aufgrund einer Kette glücklicher Zufälle war ich damals ebenfalls zugegen, wobei ich mir jedoch nichts davon als eigenen Verdienst anrechnen kann. Mein eigener Beitrag bestand höchstens aus einer bescheidenen Menge an nützlicher Software sowie – dank erstklassiger Co-Autoren – einigen Büchern, die anderen geholfen haben, mehr über Unix, seine Sprachen und seine Tools sowie über die dahinterstehende Philosophie zu lernen.
Dieses Buch ist zum Teil geschichtlicher Abriss und zum Teil persönliche Erinnerung. Es schildert die Ursprünge von Unix und versucht zu erklären, was Unix ist, wie es zustande kam und welche Bedeutung es hat. Ganz sicher ist es kein akademisches Werk – es enthält keine Fußnoten – und hat auch weniger von einem Geschichtswerk und dafür mehr von Memoiren bekommen, als ich ursprünglich geplant hatte.
Das Buch ist für alle gedacht, die sich für Computer oder Technikgeschichte interessieren. Es enthält auch einige technische Ausführungen, wobei ich aber stets versucht habe, ausreichende Erklärungen zu geben, damit auch Leser ohne umfassende Hintergrundkenntnisse die Grundprinzipien verstehen und deren Bedeutung erkennen können. Sie können jedoch auch problemlos über Stellen hinwegblättern, die Ihnen zu kompliziert erscheinen; es ist nicht nötig, jedes einzelne Wort zu lesen. Wenn Sie Programmierer sind, mögen Ihnen einige der Erklärungen überflüssig oder zu stark vereinfacht vorkommen, aber vielleicht finden die Ausführungen zur Geschichte von Unix und die damit verbundenen Anekdoten ja Ihr Interesse.
Ich habe mich zwar um Korrektheit bemüht, aber natürlich ist mein Gedächtnis nicht perfekt. Überdies lassen sich die Interviews, persönlichen Erinnerungen, Zeitzeugenberichte, Bücher und Artikel, auf die ich mich gestützt habe, nicht immer mit meinen Erinnerungen oder auch nur miteinander in Einklang bringen, wenn es darum geht, wer wann was gemacht hat.
Zum Glück sind viele derjenigen, die in der Frühzeit von Unix dabei waren, noch am Leben und konnten mich korrigieren. Auch sie haben natürlich mit Gedächtnislücken und der rosa Brille zu kämpfen, aber für jegliche im Text verbliebenen Fehler bin ich verantwortlich, zumindest sofern ich sie nicht mit Bestimmtheit jemand anderem anlasten kann.
Mein wichtigstes Anliegen beim Schreiben war es, einige der faszinierenden Geschichten aus einer besonders produktiven und prägenden Zeit in der Geschichte der Computer zu erzählen. Es ist wichtig, sich über die Entwicklung der Technologie im Klaren zu sein, die wir heute nutzen und für selbstverständlich halten. Die Entscheidungen, die diese Entwicklung bestimmten und damit unseren Weg vorgaben, wurden von Menschen getroffen, die dem Druck und den Einschränkungen ihrer Zeit ausgesetzt waren. Je mehr wir über die Geschichte wissen, umso mehr können wir das erfinderische Genie schätzen, das zu Unix geführt hat, und vielleicht auch besser verstehen, warum moderne Computersysteme so sind, wie sie sind. Zumindest kann es helfen, manche Entscheidungen, die aus heutiger Sicht falsch oder absurd erscheinen, als die natürlichen Folgen dessen zu erkennen, was man damals wusste und mit den verfügbaren Ressourcen erreichen konnte.
Es geht hier jedoch nicht nur um das Betriebssystem Unix, auch wenn es die Hauptsache darstellt, sondern auch um die Programmiersprache C. Sie gehört zu den am häufigsten verwendeten Sprachen und bildet das Herz der Systeme, die das Internet und die darin verfügbaren Dienste bereitstellen. Im Zusammenhang mit Unix kamen in den Bell Labs noch weitere Sprachen in die Welt, insbesondere das ebenfalls weitverbreitete C++, in dem Microsoft Office-Anwendungen wie Word, Excel und Power Point sowie die meisten Browser geschrieben sind. Ein oder zwei Dutzend der wichtigsten Werkzeuge, die Programmierer noch heute nutzen und für selbstverständlich halten, wurden in den Anfangstagen von Unix erstellt und sind nach 40 oder 50 Jahren zum Großteil noch unverändert.
Die theoretische Informatik spielte ebenfalls eine wichtige Rolle und ermöglichte oftmals die Entwicklung enorm praktischer Werkzeuge. Die Hardwareforschung untersuchte Designwerkzeuge, integrierte Schaltungen, Computerarchitekturen und ungewöhnliche Geräte für Sonderzwecke. Das Zusammenspiel all dieser Tätigkeitsbereiche führte oft zu unerwarteten Erfindungen und war einer der Gründe dafür, dass das gesamte Unternehmen auf so vielen verschiedenen Gebieten so produktiv war.
Es lassen sich auch einige bemerkenswerte und wichtige Einsichten darüber gewinnen, wie technischer Fortschritt zustande kommt. Die Bell Labs, in denen Unix seinen Anfang nahm, waren eine erstaunliche Einrichtung, die viele gute Ideen hervorbrachte und zu Geld machte. Hier wurde eine Menge umwälzender Erfindungen gemacht, und aus der Art und Weise, wie das geschah, lässt sich viel lernen.
Die Geschichte von Unix vermittelt viele Erkenntnisse darüber, wie man Software entwirft und erstellt und wie man Computer wirkungsvoll einsetzt, was ich beim Schreiben auch hervorzuheben versucht habe. Ein simples, aber typisches Beispiel dafür ist die Unix-Philosophie der Software-Tools, nach der man einfach vorhandene Programme unterschiedlich kombiniert, um eine breite Palette von Aufgaben zu lösen, anstatt neue Software dafür zu schreiben. Durch die Aufteilung umfangreicher Aufgaben in kleinere lassen sich die einzelnen Teile nicht nur besser handhaben, sondern können auch auf zuvor unvermutete Weise kombiniert werden.
Unix war zwar die prominenteste Software aus den Bell Labs, aber auf keinen Fall deren einziger Beitrag zur Informationstechnologie. Das Computing Science Research Center – das legendäre »Center 1127« oder auch nur kurz »1127« – war zwei oder drei Jahrzehnte lang überaus produktiv. Es bezog Anregungen aus Unix und nutzte Unix als Grundlage für die Forschung, aber seine Errungenschaften gingen weit darüber hinaus. Die Mitglieder von 1127 schrieben bedeutende Bücher, die viele Jahre lang Standardwerke der Informatik und wichtige Nachschlagewerke für Programmierer darstellten. Das Center 1127 war ein außerordentlich einflussreiches kommerzielles Forschungslabor auf dem Gebiet der Informatik und eine der produktivsten Gruppen vergleichbarer Größe sowohl damals als auch in späterer Zeit.
Was hat Unix und sein Umfeld so erfolgreich gemacht? Wie konnte sich das Experiment zweier Personen zu etwas entwickeln, was die Welt veränderte? War dies ein einzigartiges und so unwahrscheinliches Ereignis, dass nie wieder mit etwas Ähnlichem zu rechnen ist? Zu der umfassenderen Frage, ob sich solche umwälzenden Ergebnisse planen lassen, werde ich mich gegen Ende des Buches noch ausführlicher äußern. Lassen wir es zunächst dabei bewenden, dass der Erfolg von Unix meiner Ansicht nach auf das zufällige Zusammentreffen verschiedener Faktoren zurückzuführen ist: zwei außergewöhnliche Menschen, hervorragende Mitarbeiter, ein fähiges und vorurteilsfreies Management, sichere Finanzierung durch ein Unternehmen mit einer langfristigen Sichtweise und eine Umgebung, die freie Forschung ungehindert erlaubte, wie unkonventionell sie auch immer sein mochte. Die Verbreitung von Unix wurde durch den rasanten technischen Fortschritt gefördert, durch den die Hardware exponentiell kleiner, billiger und schneller wurde.
Die Anfangstage von Unix waren für mich und viele andere in den Bell Labs eine ausnehmend produktive und vergnügliche Zeit. Ich hoffe, Ihnen mit diesem Buch ein wenig von der Freude vermitteln zu können, etwas zu erschaffen und das Leben zu erleichtern, die Dennis Ritchie in dem einleitenden Zitat beschrieben hat.
Eine der unerwarteten Freuden beim Schreiben dieses Buches bestand darin, wieder mit so vielen alten Freunden und Kollegen in Berührung zu kommen. Sie waren so großzügig, mir ihre Erinnerungen mitzuteilen und einige wunderbare Geschichten zu erzählen. Wie wertvoll all dies für mich war, kann ich nur schwer in Worte fassen. Es war mir zwar nicht möglich, alle ihre Anekdoten hier zu verwenden, aber ich habe es sehr genossen, sie zu hören, und bin den vielen außergewöhnlichen Menschen zu Dank verpflichtet, mit denen ich zusammenarbeiten durfte.
Im ganzen Buch finden sich hier und da verstreut biografische Angaben zu verschiedenen Personen, wobei drei größere Abschnitte den drei Hauptverantwortlichen gewidmet sind, ohne die Unix nicht zustande gekommen wäre – Ken Thompson, Dennis Ritchie und Doug McIlroy. Ken und Doug haben mir außerordentlich wertvolle Rückmeldung zu dem Buch gegeben. Allerdings sind sie auf keinen Fall für irgendetwas verantwortlich zu machen, was ich falsch verstanden oder versehentlich falsch dargestellt haben sollte. Dennis’ Brüder John und Bill haben ebenfalls nützliche Anmerkungen und Vorschläge gemacht, und sein Neffe Sam hat mehrere Entwurfsfassungen ausführlich kommentiert.
Wie schon so oft zuvor hat mir Jon Bentley unschätzbare Einsichten vermittelt, hilfreiche Vorschläge zur Struktur des Buches und zur Schwerpunktsetzung gemacht, zahllose Anekdoten erzählt und mindestens ein halbes Dutzend Entwurfsfassungen stilistisch kommentiert. Abermals bin ich Jon zu großem Dank verpflichtet.
Gerard Holzmann hat mir Ratschläge gegeben und Archivmaterial sowie viele Originalfotos zur Verfügung gestellt, die mir geholfen haben, das Buch aufzulockern.
Paul Kernighan hat mehrere Fassungen gelesen und dabei unzählige Tippfehler entdeckt. Außerdem hatte er einige hervorragende Vorschläge für den Titel, wobei ich mich jedoch schließlich widerstrebend gegen A History of the Unix-speaking Peoples (»Eine Geschichte der Unix-sprachigen Völker«) entschieden habe.
Al Aho, Mike Bianchi, Stu Feldman, Steve Johnson, Michael Lesk, John Linderman, John Mashey, Peter Neumann, Rob Pike, Howard Trickey und Peter Weinberger haben das Buch mit kritischem Auge gelesen und mir Geschichten aus den Anfangstagen von Unix erzählt, von denen ich viele zitiert oder in eigenen Worten wiedergegeben habe.
Viele hilfreiche Anmerkungen und sonstige Beiträge habe ich auch von Michael Bachand, David Brock, Grace Emlin, Maia Hamin, Bill Joy, Mark Kernighan, Meg Kernighan, William McGrath, Peter McIlroy, Arnold Robbins, Jonah Sinowitz, Bjarne Stroustrup, Warren Toomey und Janet Vertesi erhalten.
Ich bin sehr dankbar für die großzügige Unterstützung, aber für alle Irrtümer und Fehleinschätzungen bin ich allein verantwortlich. In den letzten fünfzig Jahren haben noch viele andere Menschen in der einen oder anderen Form wichtige Beiträge zu Unix geleistet, und ich möchte mich hier bei allen entschuldigen, deren Arbeit ich nicht erwähnt habe.
»Eine Richtlinie, ein System, universeller Service.«
– Devise von AT&T, 1907
»In dieser unerwartet ländlichen Gegend von New Jersey wirkt der Hauptsitz der Bell Telephone Laboratories auf den ersten Blick wie eine große und moderne Fabrik, was er in gewissem Sinne auch ist. Allerdings handelt es sich um eine Ideenfabrik, weshalb die Fertigungsanlagen nicht zu sehen sind.«
– Arthur Clarke, Voice Across the Sea, 1974; zitiert nach The Idea Factory von Jon Gertner, 2012
Um nachvollziehen zu können, wie Unix in die Welt gekommen ist, müssen Sie zunächst die Bell Labs näher kennenlernen, insbesondere ihre Arbeitsweise und das kreative Milieu, das darin vorherrschte.
Das Unternehmen AT&T (American Telephone and Telegraph Company) entstand aus dem Zusammenschluss vieler örtlicher Telefonanbieter in den Vereinigten Staaten. Schon früh in der Firmengeschichte wurde klar, dass AT&T eine Forschungsgruppe benötigte, um systematisch all die wissenschaftlichen und technischen Probleme anzugehen, die sich dem Unternehmen bei der Bereitstellung landesweiter Telefondienste stellten. 1925 wurde dazu die Forschungsniederlassung Bell Telephone Laboratories gegründet. Auch wenn der Name gewöhnlich zu Bell Labs, BTL oder einfach nur Labs verkürzt wurde, kam der Telefontechnik immer zentrale Bedeutung zu.
Die Bell Labs waren ursprünglich in 463 West Street in New York City untergebracht, doch die meisten Tätigkeitsbereiche wurden zu Beginn des Zweiten Weltkriegs nach außerhalb der Stadt verlegt. AT&T war ein kriegswichtiges Unternehmen und bot fachliche Beratung für ein breites Spektrum von militärischen Problemen – selbstverständlich für Kommunikationssysteme, aber auch für die Feuerleitrechner von Flugabwehrgeschützen, für Radar und Kryptografie. Ein Teil dieser Arbeit wurde in Vororten und ländlichen Gegenden von New Jersey erledigt. Der größte Standort befand sich in einem Gebiet namens Murray Hill, das zu den Kleinstädten New Providence und Berkeley Heights gehörte und 33 km westlich des alten Standorts lag.
Abbildung 1.1
Der alte Standort in New York City und der neue in Murray Hill, New Jersey (Karte: OpenStreetMap)
Abbildung 1.1 zeigt die geografische Lage. 463 West Street befindet sich am Hudson River, auf der Karte ein wenig nördlich der Markierung für den Highway 9A. Die Bell Labs in Murray Hill liegen auf der Grenze zwischen New Providence und Berkeley Heights, etwas nördlich der Interstate 78. Beide Standorte sind mit roten Punkten markiert.
Immer mehr Tätigkeiten der Bell Labs wurden nach Murray Hill verlegt. Der Standort in der West Street wurde 1966 endgültig aufgegeben. In den 60er Jahren arbeiteten in Murray Hill mehr als 3.000 Personen, davon mindestens 1.000 mit einem Doktortitel in einer naturwissenschaftlich-technischen Disziplin wie Physik, Chemie, Mathematik oder verschiedenen Ingenieurswissenschaften.
Abbildung 1.2 zeigt eine Luftaufnahme der Einrichtungen in Murray Hill aus dem Jahr 1961. Aufgeteilt ist die Anlage in drei Hauptgebäude. Nr. 1 befindet sich in der Bildmitte und Nr. 2 oben links. Bei dem Viereck mit dem offenen Innenhof rechts handelt es sich um Nr. 3. Von dem einen Ende von Gebäude 1 bis zum anderen Ende von Gebäude 2 verlief damals ein durchgehender Korridor von 400 m Länge, der erst in den 70er Jahren durch zwei neu errichtete Gebäude unterbrochen wurde.
Ich habe mehr als 30 Jahre in Gebäude Nr. 2 gearbeitet, von meinem Praktikum im Jahr 1967 bis zu meiner Pensionierung 2000. Meine Büros befanden sich in den mit Punkten gekennzeichneten Seitenflügeln im vierten (obersten) Stock. Zur besseren Orientierung bei den folgenden Beschreibungen: Treppenhaus 9 befindet sich am hintersten Ende von Gebäude Nr. 2, Treppenhaus 8 einen Seitenflügel näher im Vordergrund. In den ersten Jahren war der Unix-Raum in der Dachkammer im fünften Stock zwischen diesen beiden Treppenhäusern untergebracht.
Abbildung 1.3 zeigt eine Google-Satellitenaufnahme der Bell Labs aus dem Jahr 2019. Die Gebäude Nr. 6 (unterhalb und links der Bildmitte, markiert) und Nr. 7 (oberhalb und rechts der Bildmitte) wurden Anfang der 70er hinzufügt. Nach 1996 fungierte Gebäude Nr. 6 einige Jahre lang als Hauptsitz von Lucent Technologies. Es ist faszinierend zu sehen, wie viel Firmengeschichte in den von Google hinzugefügten Beschriftungen steckt: Bell Labs als Hauptmarkierung, Lucent Bell Labs auf der Ausfahrt, Alcatel-Lucent Bell Labs an der Einfahrt und Nokia Bell Labs am Anbau der Verwaltungspyramide in Gebäude Nr. 6.
Ich bin nicht wirklich qualifiziert, um eine ausführliche Geschichte der Labs zu schreiben, aber das haben zum Glück schon andere Autoren erledigt. Mir persönlich gefallen besonders das Buch The Idea Factory von Jon Gertner, das den Schwerpunkt auf die physikalische Forschung legt, sowie The Information von James Gleick, eine hervorragende Quelle für die Tätigkeiten auf dem Gebiet der Informationswissenschaft. Die umfangreiche offizielle Publikation der Bell Labs (fast 5.000 Seiten in sieben Bänden) unter dem Titel A History of Science and Engineering in the Bell System ist ausführlich, zuverlässig und für meinen Geschmack äußerst interessant.
Abbildung 1.2
»Irgendwann bemerkte ich, dass ich drei Wochen von einem Betriebssystem entfernt war.«
– Ken Thompson, Vintage Computer Festival East, 4. Mai 2019
Das Betriebssystem Unix erblickte 1969 das Licht der Welt, aber es entstand nicht einfach aus dem Nichts heraus, sondern fußte auf den Erfahrungen verschiedener Personen bei den Bell Labs, die an anderen Betriebssystemen und Sprachen gearbeitet hatten.
Dieser Abschnitt gibt eine kurze Einführung in die technischen Aspekte, um die es in diesem Buch geht, also Computer, Hardware, Software, Betriebssysteme, Programmierung und Programmiersprachen. Wenn Sie mit diesen Begriffen bereits vertraut sind, können Sie ruhig vorblättern, und wenn nicht, hoffe ich, dass Ihnen die folgenden Beschreibungen helfen, den Rest besser zu verstehen. Als ausführlichere Erklärung für technisch nicht versierte Leser empfehle ich mein Buch Understanding the Digital World, wobei ich natürlich nicht ganz unvoreingenommen bin.
Ein Computer ist im Grunde genommen nicht viel mehr als einer der Taschenrechner, die es früher als eigenständige Geräte gab und die jetzt als App auf Smartphones zu finden sind. Sie können arithmetische Berechnungen ungeheuer schnell ausführen. Heutzutage erledigen sie Milliarden Rechenvorgänge pro Sekunde, während es in den 70er Jahren noch deutlich weniger als Millionen pro Sekunde waren.
Ein typischer Computer der 60er und 70er verfügte über einen Vorrat von wenigen Dutzend Instruktionen, die er ausführen konnte, etwa um arithmetische Operationen vorzunehmen (Addition, Subtraktion, Multiplikation und Division), um Informationen aus dem primären Speicher zu lesen und darin zu speichern und um mit Festplatten oder anderen angeschlossenen Geräten zu kommunizieren. Von entscheidender Bedeutung aber sind Anweisungen, die aufgrund der Ergebnisse vorheriger Berechnungen bestimmen, welche Instruktionen als Nächstes ausgeführt werden sollen. Der Computer entscheidet also aufgrund dessen, was er getan hatte, was er als Nächstes tut. In diesem Sinne lenkt er sein eigenes Schicksal.
Instruktionen und Daten werden im selben primären Speicher untergebracht, der gewöhnlich als Arbeitsspeicher oder RAM (Random Access Memory, also »Speicher mit wahlfreiem Zugriff«) bezeichnet wird. Je nachdem, was für eine Folge von Instruktionen Sie in das RAM laden, erledigt der Computer bei der Ausführung eine andere Aufgabe. Das geschieht etwa, wenn Sie auf das Symbol für ein Programm wie Word oder Chrome klicken: Dem Betriebssystem wird dadurch befohlen, die Instruktionen für das betreffende Programm in den Arbeitsspeicher zu laden und sie auszuführen.
Unter Programmierung versteht man die Tätigkeit, Folgen von Operationen zusammenzustellen, um eine gegebene Aufgabe zu erledigen. Dazu wird eine Programmiersprache verwendet. Es ist zwar auch möglich, die erforderlichen Instruktionen direkt zu erstellen, allerdings ist das selbst für kleine Programme eine mühselige Aufgabe, bei der viele Einzelheiten zu beachten sind. Bei den meisten Fortschritten, die auf dem Gebiet der Programmierung erzielt wurden, ging es daher darum, Programmiersprachen zu erschaffen, die stärker daran angelehnt sind, wie Menschen eine Berechnung ausdrücken würden. Als Compiler bezeichnete Programme (die natürlich ebenfalls geschrieben werden müssen) übersetzen von Sprachen höherer Ordnung (die sich stärker an menschlichen Sprachen orientieren) in die einzelnen Instruktionen für die jeweilige Art von Computer.
Ein Betriebssystem schließlich ist ein umfangreiches und kompliziertes Programm, das aus den gleichen Instruktionen aufgebaut ist wie gewöhnliche Programme, etwa Word oder ein Browser. Seine Aufgabe besteht darin, alle anderen Programme zu steuern, die ausgeführt werden wollen, und sich um die Wechselwirkung mit dem Rest des Computers zu kümmern.
Das klingt alles ziemlich abstrakt. Das folgende kleine Beispiel soll Ihnen daher konkret zeigen, worum es bei der Programmierung geht. Nehmen wir an, Sie möchten die Fläche eines Rechtecks aus seiner Länge und Breite berechnen. Auf Deutsch können wir sagen: »Die Fläche ist das Produkt aus Länge und Breite.« Als Formel ausgedrückt, ergibt sich Folgendes:
In einer höheren Programmiersprache (deren Elemente meistens aus dem Englischen entlehnt sind) können wir das wie folgt schreiben:
In den meisten Programmiersprachen von heute würde diese Anweisung tatsächlich genau so aussehen. Ein Compiler übersetzt dies in eine immer noch verständliche, rechnerspezifische Folge von Maschineninstruktionen für einen Computer. Für einen einfachen hypothetischen Computer kann das Ergebnis wie folgt aussehen:
load length
multiply width
store area
Ein als Assembler bezeichnetes Programm überführt diese Folge von mehr oder weniger verständlichen Instruktionen schließlich in eine Folge von Maschineninstruktionen, die in den Arbeitsspeicher des Computers geladen werden. Bei der Ausführung dieser Instruktionen wird die Fläche aus der gegebenen Länge und Breite berechnet. Diese vereinfachte Darstellung schweigt sich zwar über viele Einzelheiten aus – etwa wie wir den Kompilier- und Ladevorgang festlegen, wie die Werte für die Länge und die Breite in den Computer gelangen, wie die Fläche ausgegeben wird usw. –, vermittelt aber die Grundzüge des Vorgangs.
Als konkretes, funktionierendes Beispiel finden Sie hier ein vollständiges Programm in der Sprache C, das eine Länge und eine Breite liest und die daraus berechnete Fläche ausgibt:
Dieses Programm kann auf jedem beliebigen Computer kompiliert und ausgeführt werden.
Moderne Betriebssysteme wie Windows und macOS oder auf Smartphones auch Android und iOS sind zumindest dem Namen nach allgemein bekannt.
Ein Betriebssystem ist ein Programm, das den Computer steuert. Es verteilt die Ressourcen auf die laufenden Programme, verwaltet den Hauptspeicher und weist ihn den Programmen nach deren Bedarf zu. Auf einem Desktop- oder Laptopcomputer sorgt das Betriebssystem dafür, dass Sie einen Browser, eine Textverarbeitung, ein Musikwiedergabeprogramm und vielleicht auch unser kleines Programm zur Flächenberechnung ausführen können, und zwar alle zugleich, wobei es seine Aufmerksamkeit nach Bedarf einmal dem einen und einmal dem anderen zuwendet.
Es steuert auch die Anzeige, um die einzelnen Programme auf dem Bildschirm darzustellen, wenn es gefordert wird, und verwaltet Speichergeräte wie die Festplatte, sodass beispielsweise ein Word-Dokument beim Speichern so abgelegt wird, dass Sie es später wieder aufrufen und weiterbearbeiten können.
Das Betriebssystem koordiniert auch die Kommunikation mit Netzwerken wie dem Internet, sodass Sie Ihren Browser zur Recherche, zur Kommunikation mit Freunden, zum Einkaufen und zum Veröffentlichen von Katzenvideos nutzen können, und all das zur gleichen Zeit.
Auch wenn es für Nichtprogrammierer nicht so offensichtlich ist, dient das Betriebssystem auch dazu, die einzelnen Programme und sich selbst vor fehlerhaften oder schädlichen Programmen und Benutzern zu schützen.
Betriebssysteme auf Telefonen funktionieren ähnlich. Hinter den Kulissen geschieht sehr viel, um die Kommunikation über ein Mobilfunknetz oder ein WLAN aufrechtzuerhalten. Apps entsprechen dabei Programmen wie etwa Word, auch wenn es Unterschiede in den Einzelheiten gibt. Sie sind auch in den gleichen Programmiersprachen geschrieben.
Heutzutage handelt es sich bei Betriebssystemen um große und komplizierte Programme. In den 60er Jahren war das Leben einfacher, aber nach den Maßstäben jener Zeit waren die damaligen Betriebssysteme ebenfalls groß und kompliziert. Gewöhnlich stellte ein Computerhersteller wie IBM oder DEC (Digital Equipment Corporation) ein oder mehrere Betriebssysteme für seine verschiedenen Hardwareprodukte bereit. Es gab keine Gemeinsamkeiten zwischen Hardware von verschiedenen Herstellern und manchmal nicht einmal zwischen den Geräten ein und desselben Herstellers. Daher wiesen auch die verschiedenen Betriebssysteme keinerlei Gemeinsamkeiten auf.
Noch komplizierter wurde die Sache dadurch, dass die Betriebssysteme in Assemblersprache geschrieben waren, also einer Form von Maschineninstruktionen, die zwar für Menschen lesbar war, aber stark in die Einzelheiten ging und auf den Befehlsumfang einer bestimmten Hardware zugeschnitten war. Jede Art von Computer brachte ihre eigene Assemblersprache mit. Bei den Betriebssystemen handelte es sich daher um umfangreiche und komplizierte Assemblerprogramme, die in der spezifischen Sprache für die jeweilige Hardware geschrieben waren.
Dieser Mangel an Gemeinsamkeiten und die Verwendung inkompatibler maschinennaher Sprachen behinderten erheblich den Fortschritt, da sie es erforderlich machten, jedes Programm in mehreren Versionen zu schreiben. Um ein Programm, das für ein bestimmtes Betriebssystem erstellt worden war, auf ein anderes Betriebssystem oder eine andere Architektur zu übertragen, musste es komplett neu geschrieben werden. Wie Sie noch sehen werden, wurde es mit Unix möglich, das gleiche Betriebssystem auf allen Arten von Hardware auszuführen. Als Unix schließlich nicht mehr in einer Assembler-, sondern einer Hochsprache geschrieben war, ließ es sich mit relativ wenig Aufwand von einem Computer auf einen anderen übertragen.
Das innovativste Betriebssystem seiner Zeit war das 1964 beim MIT entwickelte CTSS (Compatible Time-Sharing System). Die meisten Betriebssysteme waren für das da, was man damals unter »Stapelverarbeitung« verstand: Programmierer stanzten ihre Programme in Lochkarten (das war vor langer Zeit!), übergaben diese dann einem Operator und warteten darauf, dass ihnen die Ergebnisse ausgehändigt wurden, was Stunden und manchmal sogar Tage dauern konnte.
Lochkarten bestanden aus hochwertigem, steifen Karton und konnten bis zu 80 Zeichen speichern. Gewöhnlich enthielt jede Karte eine Programmzeile. Unser sechszeiliges C-Programm hätte also sechs Karten beansprucht. Bei einem Programmwechsel mussten die Karten ausgetauscht werden. Abbildung 2.1 zeigt eine Standardkarte mit 80 Spalten.
Abbildung 2.1
Lochkarte, 18,7 cm × 8,3 cm
Dagegen verwendeten CTSS-Programme schreibmaschinenähnliche Geräte (»Terminals« wie der Teletype 33 in Abbildung 3.1 im nächsten Kapitel), die direkt oder über Telefonleitungen an einen Großrechner angeschlossen waren – eine IBM 7094 mit doppelt so viel Speicher wie den üblichen 32K Wörtern. Das Betriebssystem verteilte seine Aufmerksamkeit auf die angemeldeten Benutzer, wobei es schnell von einem aktiven Benutzer zum anderen umschaltete und so die Illusion hervorrief, dass jeder den kompletten Computer zu seiner Verfügung hatte. Dieses Timesharing-System (»Zeitscheibensystem«) war meiner persönlichen Erfahrung nach unendlich viel angenehmer und produktiver als die Stapelverarbeitung. Meistens hatte man das Gefühl, als ob es gar keine anderen Benutzer gäbe.
CTSS erwies sich als eine so produktive Programmierumgebung, dass sich die Forscher am MIT entschlossen, eine noch bessere Version zu erstellen, die als »Informationsversorger« Computerdienste für umfangreiche und weit verteilte Benutzergruppen bereitstellen sollte. 1965 begannen sie, ein System namens Multics zu konstruieren, was für »Multiplexed Information and Computing Service« stand.
Die Entwicklung von Multics erforderte einen erheblichen Aufwand, da sie sowohl anspruchsvolle neue Software als auch neue Hardware mit mehr Möglichkeiten erforderte, als sie die IBM 7094 bot. Daher nahm das MIT zur Unterstützung noch zwei weitere Organisationen ins Boot. Das Unternehmen General Electric, das damals Computer baute, sollte einen neuen Rechner mit Hardwaremerkmalen konstruieren, die Timesharing-Systeme und mehrere Benutzer besser unterstützten. Die Bell Labs, die schon seit den frühen 50er Jahren viel Erfahrung durch die Entwicklung ihrer eigenen Systeme gewonnen hatten, sollten am Betriebssystem mitarbeiten.
Die Aufgabenstellung des Multics-Projekts an sich stellte bereits eine Herausforderung dar, und schon bald traten Probleme auf. Rückblickend betrachtet lag das wohl zum Teil am Zweitsystemeffekt: Wenn man ein erfolgreiches System hat (wie CTSS), ist die Versuchung groß, ein neues System erstellen zu wollen, das alle restlichen Probleme des ursprünglichen beseitigt und zusätzlich die Wunschmerkmale aller Beteiligter erfüllt. Das resultiert oft in einem zu komplizierten System, da versucht wird, zu vieles auf einmal zu erreichen. Das war auch bei Multics der Fall. Es wurde mehrfach als »überkonstruiert« beschrieben, und Sam Morgan nannte es den »Versuch, auf zu viele Bäume auf einmal zu klettern«. Außerdem muss man nicht einmal Organisationswesen studiert haben, um zu ahnen, dass bei einem Projekt, an dem eine Universität und zwei Unternehmen an drei verschiedenen Standorten beteiligt sind, Schwierigkeiten auftreten werden.
Von 1966 bis 1969 arbeiteten gut ein halbes Dutzend Forscher der Bell Labs an Multics, darunter Doug McIlroy, Dennis Ritchie, Ken Thompson und Peter Neuman, der Vic Vyssotskys Posten übernommen hatte, nachdem Vic zu einem anderen Standort der Bell Labs umgezogen war.
Doug war intensiv mit PL/I beschäftigt, der Programmiersprache, die zum Schreiben von Multics-Software vorgesehen war. Dennis hatte als Student in Harvard an der Multics-Dokumentation gearbeitet und kümmerte sich in den Bell Labs um die Ein- und Ausgabesysteme. Ken konzentrierte sich ebenfalls auf diese Teilsysteme, was sich bei der Arbeit an Unix noch als hilfreich erweisen sollte. Nach seinen Äußerungen in einem Interview aus dem Jahre 2019 war die Arbeit an Multics für ihn jedoch »ein Zahn in einem riesigen Zahnrad« und »führte zu etwas, das ich selbst nicht verwenden wollte«.
1968 wurde deutlich, dass Multics zwar eine gute Umgebung für die Handvoll Benutzer darstellte, die es unterstützte, aber niemals zu dem vorgesehenen System werden konnte, das in der Lage war, für die Bell Labs Computerdienste zu vertretbaren Kosten bereitzustellen. Es war einfach zu teuer. Daher verabschiedeten sich die Bell Labs im April 1969 von dem Projekt und ließen das MIT und GE allein weitermachen.
Multics wurde schließlich fertiggestellt und zumindest zu einem Erfolg erklärt. Es wurde bis zum Jahr 2000 unterstützt und verwendet, war allerdings nicht weit verbreitet. Aus Multics gingen viele gute Ideen hervor, aber sein bedeutendster Beitrag war ganz und gar ungeplant, nämlich sein Einfluss auf das kleine Betriebssystem Unix, das zumindest zum Teil als Reaktion auf die Komplexität von Multics geschaffen wurde.
Als sich die Bell Labs aus dem Multics-Projekt zurückzogen, mussten sich die damit beschäftigten Mitarbeiter eine andere Aufgabe suchen. Ken Thompson (Abbildung 2.2) wollte weiterhin an Betriebssystemen arbeiten, aber nach den Erfahrungen mit Multics war das obere Management ein gebranntes Kind und scheute den Kauf neuer Hardware für ein weiteres Betriebssystemprojekt. Daher nutzten Ken und andere ihre Zeit dazu, Ideen zu entwickeln und theoretische Designs für verschiedene Komponenten von Betriebssystemen zu entwickeln, ohne sie konkret zu implementieren.
Abbildung 2.2
Ken Thompson, ca. 1984 (freundlicherweise zur Verfügung gestellt von Gerard Holzmann)
Etwa um diese Zeit stieß Ken auf einen wenig genutzten Computer vom Typ DEC PDP-7, der hauptsächlich als Eingabegerät zum Erstellen von Entwürfen für elektronische Schaltungen genutzt wurde. Der PDP-7 war 1964 auf den Markt gekommen, und da Computer einer schnellen Entwicklung unterliegen, galt er 1969 schon als veraltet. Mit einem Arbeitsspeicher von lediglich 8K 18-Bit-Wörtern (16 KByte) war er nicht sehr leistungsfähig, aber da er eine hübsche grafische Anzeige hatte, schrieb Ken eine Version des Spiels Space Travel dafür. Darin konnte ein Spieler die verschiedenen Planeten des Sonnensystems besuchen und dort landen. Es hatte einen gewissen Suchtfaktor, und ich spielte es viele Stunden lang.
Die PDP-7 hatte aber noch ein anderes bemerkenswertes Peripheriegerät, nämlich ein sehr großes Plattenlaufwerk mit einer einzigen, senkrechten Platte. Es ging das glaubhafte Gerücht, dass es gefährlich sein konnte, davorzustehen, wenn irgendetwas kaputtging. Die Festplatte war außerdem zu schnell für den Computer, was ein bemerkenswertes Problem darstellte. Ken schrieb einen Festplatten-Zeitplanungsalgorithmus, um den Durchsatz beliebiger Festplatten zu maximieren, insbesondere aber dieser Platte.
Nun stellte sich aber die Frage, wie er diesen Algorithmus testen sollte. Dazu war es erforderlich, Daten auf die Platte zu laden. Ken kam zu dem Schluss, dass er ein Programm brauchte, das Mengen von Daten auf die Platte packte.
»Irgendwann bemerkte ich, dass ich drei Wochen von einem Betriebssystem entfernt war«, erinnert er sich. Er musste drei Programme schreiben, eines pro Woche: einen Editor, um Code schreiben zu können, einen Assembler, um den Code in Maschinensprache für den PDP-7 zu übersetzen, und ein »Kernel-Overlay – was man auch ein Betriebssystem nennen kann«.
Genau zu diesem Zeitpunkt fuhr Kens Frau mit ihrem ein Jahr alten Sohn zu einem dreiwöchigen Besuch zu Kens Eltern in Kalifornien, weshalb Ken drei Wochen lang ungestört arbeiten konnte. In einem Interview im Jahr 2019 sagte er: »Eine Woche, noch eine Woche und noch eine Woche, und wir hatten Unix.« Das ist nun wirklich wahre Softwareproduktivität!
Einige Jahre, nachdem Ken und ich beide unseren Abschied von den Bell Labs genommen hatten, erkundigte ich mich bei ihm noch einmal über die Geschichte, nach der er die erste Version von Unix in drei Wochen geschrieben hatte. Seine Antwort-E-Mail entspricht genau dem, was er indem viel späteren Interview gesagt hat:
Datum: Donnerstag, 9. Jan. 2003 13:51-:56 -0800
unix war eine dateisystem-implementierung, um durchsatz usw zu testen. einmal implementiert, war es schwer, daten zum hochladen dort hineinzubekommen. ich konnte lese/schreib-aufrufe in schleifen stellen, aber anspruchsvollere aufgaben waren so gut wie unmöglich. so sah es aus, als bonnie meine eltern in san diego besuchen ging.
ich erkannte, dass ich kurz vor einem timesharing-system stand, dem nur ein exec-aufruf, eine shell, ein editor und ein assembler fehlten. (kein compiler.) der exec-aufruf war trivial und die anderen 3 erledigte ich 1 pro woche – genauso lange, wie bonnie weg war.
der computer hatte 8k x 18 bits. 4k war der kernel und 4k war die auslagerungsdatei für den benutzer.
ken
Diese erste Version eines schon als Unix erkennbaren Systems lief Mitte bis Ende 1969. Es ist durchaus angebracht, dies als die Geburt von Unix zu bezeichnen.
Das System hatte in diesem Frühstadium nur eine kleine Gruppe von Benutzern. Dazu gehörten natürlich Ken und Dennis sowie Doug McIlroy, Bob Morris, Joe Ossanna und zufällig auch ich. Jeder Benutzer hatte eine numerische Benutzer-ID. Einige der IDs gehörten auch zu Systemfunktionen statt zu menschlichen Benutzern, etwa 0 für Root oder den Super-User. Dazu kamen noch eine Reihe weiterer IDs für Sonderfälle. Die IDs für richtige Benutzer begannen bei 4. Wenn ich mich recht entsinne, hatte Dennis die 5, Ken die 6 und ich die 9. Eine einstellige Benutzer-ID auf dem ursprünglichen Unix-System gehabt zu haben, stellt schon eine gewisse Auszeichnung dar.
Noch in seiner Frühzeit erhielt das neue Betriebssystem für den PDP-7 seinen Namen. Die Einzelheiten sind allerdings etwas unklar.
Ich erinnere mich, dass ich in der Tür zu meinem Büro stand und mit mehreren Leuten sprach, unter denen sich zumindest Ken, Dennis und Peter Neumann befanden. Zu diesem Zeitpunkt hatte das System noch keinen Namen. Da Multics »vieles von allem« bot, schlug ich daher vor, das neue System, das höchstens eines von allem hatte, als Wortspiel mit den lateinischen Wurzeln »uni« und »multi« auf den Namen UNICS zu taufen.
Allerdings erfand nach einer anderen Erinnerung Peter Neumann den Namen Unix als Abkürzung für »UNiplexed Information and Computing Service«. Er selbst sagt dazu:
»Ich kann mich noch lebhaft daran erinnern, dass Ken eines Tages zum Mittagessen vorbeikam und mir sagte, dass er über Nacht einen tausendzeiligen Einzelbenutzer-Betriebssystemkernel für den PDP-7 geschrieben hätte, den Max Matthews ihm ausgeliehen hatte. Ich schlug ihm vor, daraus ein Mehrbenutzersystem zu machen, und als er am nächsten Tag wieder zum Essen kam, hatte er weitere tausend Zeilen mit einem Mehrbenutzerkernel geschrieben. Es war der Einbenutzerkernel, der die Vorstellung eines ›kastrierten Multics‹, also UNICS, aufkommen ließ.«
Großzügigerweise hat Peter gesagt, dass er sich an keine weiteren Einzelheiten mehr erinnert, weshalb mir die Prägung der Bezeichnung zugeschrieben wird, ob verdient oder nicht.
Wie dem auch immer sei, mutierte UNICS schließlich zu Unix, was deutlich besser aussieht. (Angeblich gefiel der Rechtsabteilung von AT&T das Wort »Unics« nicht, da es ähnlich wie »eunuchs« klang.) Dennis Ritchie hat den Namen später als »etwas hinterhältige Anspielung auf Multics« bezeichnet, was er auch tatsächlich war.