Phil Lapsley
Giganews Usenet Geschichte > Phil Lapsley
Phil Lapsley ist der Mitautor des Netzwerk-Nachrichtenübertragungsprotokolldas bis heute die Standardmethode für die Usenet-Übertragung ist.
Lapsley besuchte die Universität von Kalifornien in Berkeley, wo er 1988 einen Bachelor- und 1991 einen Master-Abschluss in Elektrotechnik und Informatik erwarb. Neben der Entwicklung von NNTP war er während seiner Zeit in Berkeley Mitbegründer der Experimental Computing Facility und trug zum Berkeley UNIX-Projekt bei.
Nach seinem Abschluss in Berkeley war Lapsley Mitbegründer von Berkeley Design Technology, Inc. einem Beratungsunternehmen für digitale Signalverarbeitungstechnologie, und SmartTouch, einem Unternehmen, das sich auf die Verarbeitung biometrischer Finanztransaktionen spezialisiert hat.
Zusätzlich zu seinen in Berkeley erworbenen Abschlüssen hat Lapsley auch einen MBA der MIT Sloan School of Management. Lapsley arbeitete als Unternehmensberater in der High-Tech-Praxis des Büros von McKinsey and Company im Silicon Valley. Derzeit schreibt er ein Buch über die Geschichte des "Phone Phreakings" (dem Vorläufer des Computer-Hackings).
Interview (5/1/2007) mit Phil Lapsley
1. Mai 2007
Bevor ich Ihre Fragen beantworte, lassen Sie uns eine kurze Reise in die Vergangenheit machen, um einen Blick auf die Computerumgebung an der U.C. Berkeley im Jahr 1984 zu werfen und die Voraussetzungen für meine Beteiligung an all dem zu schaffen:
- Das war fast 10 Jahre vor dem World Wide Web. Es gab zwar so etwas wie "das Internet", aber in Form des ARPANET. Eine "Hochgeschwindigkeits"-Verbindung im ARPANET betrug 56 kbit/s, d. h. ungefähr das, was man heute mit einem guten Einwahlmodem erreicht. ( Benutzt eigentlich noch jemand Einwahlmodems?)
- Ethernet war eine neue Erfindung und wurde erst kürzlich in einigen Bereichen des Berkeley-Campus eingesetzt. Das Haupt-Ethernet der CS-Abteilung hatte eine Geschwindigkeit von 3 Megabit/Sekunde, und ein neues Ethernet mit 10 Megabit/Sekunde war gerade installiert worden. Das vorherige RS-232-basierte serielle Netzwerk, etwas namens "Berknet", wurde von einem Berkeley-Masterstudenten namens Eric Schmidt entwickelt(hmm... wo habe ich diesen Namen in letzter Zeit gehört? Vielleicht sollte ich ihn mal googeln... hmm...) wurde ausgemustert, aber ein paar Rechner benutzten es noch.
- Der beste Computer, auf den man vernünftigerweise hoffen konnte, war die Digital Equipment Corporation VAX. Berkeley verfügte über etwa ein Dutzend dieser Computer auf dem gesamten Campus, die von Studenten, Professoren, Forschern und Mitarbeitern genutzt wurden. Die großen Maschinen waren VAX-11/780, von denen es nur ein paar gab, und die kleinen Maschinen waren VAX-11/750. Ein typischer Rechner hatte 4 Megabyte (ja, Megabyte) Speicher und einige hundert Megabyte Festplattenspeicher.
- Das beste Festplattenlaufwerk zu dieser Zeit war die Fujitsu Eagle. Dieses Monstrum nahm einen guten Teil eines 19″-Racks ein und wog 143 Pfund. Es wurde ab Werk mit Hebegurten in der Schachtel ausgeliefert, um es in das Rack zu heben. Beim Einschalten dauerte es 30 Sekunden, bis er hochgefahren war, und er bot satte 470 Megabyte (ja, Megabyte) im unformatierten Zustand, was etwa 330 Megabyte im formatierten Zustand entsprach. Sie kostete etwa 10.000 Dollar. Wenn Sie Glück hatten, hatte Ihre VAX vielleicht noch ein paar davon.
- Die Interaktion mit einem Computer erfolgte über ein "intelligentes" Terminal, d. h. nur Text, 24 Zeilen mit 80 Zeichen. 1986 begann sich dies ein wenig zu ändern, als die ersten schwarz-weißen Sun 3/50-Workstations auf den Markt kamen, aber sie waren selten, und die Mehrheit der Menschen interagierte mit Computern über Terminals - keine Grafiken, keine Maus, nur Text.
- Wenn man sich von zu Hause aus in einen Computer einwählte oder wenn man zwei Computer miteinander verband (und nicht das Glück hatte, einen ARPANET-Zugang zu haben), benutzte man ein Einwahlmodem. Das damals gängige Modem hatte eine Geschwindigkeit von 1200 bps, während 2400 bps gerade erst aufkamen. Das klingt langsam, war aber ein großer Fortschritt gegenüber den 300 bps-Modems, die nur ein oder zwei Jahre zuvor verwendet wurden.
Ok, mit diesem Hintergrund lassen Sie uns über USENET oder Netnews sprechen, wie es allgemein genannt wurde.
Damals wurden die Netnews über ein Einwahlmodem mit dem UUCP-Protokoll verteilt. Das heißt, die Computer wählten sich gegenseitig an und tauschten Netnews und E-Mail-Dateien mit 1200 oder 2400 bps aus. Einige wenige Glückliche hatten Telebit-Modems, die mit 9600 bps half-duplex liefen (was für UUCP in Ordnung war). Aber es gab einige Probleme damit, zumindest in Berkeley.
Erstens hatten die meisten Computer in Berkeley weder Modems noch Telefonleitungen, so dass die meisten Computer einfach keine UUCP-Einwahlverbindung zu einem anderen Computer herstellen konnten. Und selbst wenn Ihr Rechner über ein Modem verfügte, waren Ferngespräche teuer. Sogar Ortsgespräche kosteten ein paar Cent pro Minute, weil es sich bei den Telefonleitungen um Geschäftsleitungen (und nicht um Privatleitungen) handelte.
Das zweite Problem war, dass netnews als frivol angesehen wurde - nicht als etwas, das wirklich akademische Priorität hatte. Tatsächlich gab es einen Professor, Richard Fateman, der mehrmals im Jahr eine kurze Nachricht veröffentlichte, in der er die Leute daran erinnerte, dass "csmsgs" (das interne netzwerkähnliche Nachrichtenbrett der CS-Abteilung in Berkeley) nur für den offiziellen Gebrauch bestimmt war und nicht dazu benutzt werden durfte, etwas anderes zu posten, wie z. B. zu vermietende Wohnungen, da dies Computerressourcen verschwendete. Sie können sich vorstellen, wie er über netnews dachte. (Ich frage mich, was er heute über das Web denkt.)
In einem Punkt hatte Prof. Fateman jedoch recht, und das war das dritte Problem: Netnews war teuer in Bezug auf Festplatten- und CPU-Ressourcen. Wenn ich mich richtig erinnere, verbrauchte 1985 oder so ein typischer "voller" News-Feed 5 Megabyte pro Woche, wenn man also einen Monat lang Netnews abspielte, waren das 20 Megabyte Festplattenplatz. Denken Sie daran, dass damals 300 Megabyte alles waren, was Ihr Computer an Speicherplatz hatte, und ein großer Teil davon wurde vom UNIX-Betriebssystem verwendet, so dass Sie es sich nicht wirklich leisten konnten, etwa 10 % Ihres gesamten Speicherplatzes (und noch viel mehr Ihres verfügbaren Speicherplatzes) für irgendwelchen frivolen Kram zu verwenden.
Infolgedessen hatten nur zwei Rechner in Berkeley Netnews: ucbvax und ucbcad. Leider hatten nur sehr wenige Leute Konten auf diesen Rechnern. Das bedeutete, dass man als typischer Student oder sogar als typischer Professor einfach keinen Zugang zu netnews hatte.
Und da kam ich ins Spiel: Ich war ein aufdringlicher Studienanfänger in Elektrotechnik und Informatik, wollte Zugang zu den Netnews und konnte ihn nicht bekommen, weil ich kein ucbvax-Konto hatte.
Aber ich hatte ein paar gute Gründe. Zum einen war ich fasziniert von Netzwerken und Telekommunikation. Noch vor meinem ersten Semester in Berkeley, in der High School, hatte ich mein eigenes Bulletin-Board-System für die Einwahl geschrieben. Es war nicht so ausgefallen wie netnews, aber es war mein eigener Schritt in diese Richtung, und es gab mir einen ausreichenden Vorgeschmack auf die Kommunikation im Stil von netnews, um stark motiviert zu sein, Zugang dazu zu bekommen.
Die zweite Sache, die für mich sprach, war die Bereitschaft, etwas zu lernen und Code zu schreiben. Noch bevor ich in Berkeley war, hatte ich mir das "ARPANET Resource Handbook" (im Wesentlichen eine Sammlung früher RFCs) besorgt und studierte es wie verrückt, auch wenn es für mich damals nicht viel Sinn ergab.
Ich war schon seit meiner Highschool-Zeit (1983 oder so) in Berkeley und half schließlich beim Berkeley UNIX-Projekt der Computer Systems Research Group mit. Ich wollte mehr darüber erfahren, wie Netzwerke unter BSD UNIX funktionieren, also sprach ich mit Mike Karels, einem der leitenden CSRG-Forscher, und fragte ihn, was ich tun könnte, um zu helfen. Wir einigten uns darauf, dass ich die "Sockets"-Dokumentation (besser bekannt als die "4.2BSD Interprocess Communications Primer") überarbeiten würde. Dies führte dazu, dass ich an dem Programm "inetd" arbeitete, und 1985 war ich einer der wenigen Leute in Berkeley, die sich mit Client/Server-Architektur und Socket-Programmierung auskannten.
Vor diesem Hintergrund schlug ich Mike und (dem inzwischen verstorbenen) Bob Henry vor, ein Protokoll für den Fernzugriff auf netnews von ucbvax über das Ethernet zu entwickeln. Dies würde den Leuten in der Computergemeinschaft in Berkeley zugute kommen und auch Bob das Leben erleichtern, da er nicht mehr von Leuten belästigt werden würde, die ihn um Konten bei ucbvax bitten!
Sie hielten das für eine gute Idee, und so begann ich, Code zu schreiben, wobei ich das Ganze auf eine SMTP-ähnliche Client/Server-Architektur stützte, und schon bald hatte ich etwas Funktionierendes. Ich modifizierte eine Version von Larry Walls "rn"-Programm, um das Protokoll zu sprechen, so dass es eine Benutzeroberfläche dafür gab. Ein paar Monate später erwähnte mein Freund Dave Pare von der U.C. San Diego, dass sein Freund Brian Kantor an etwas Ähnlichem arbeitete. Ich hatte Brian über Dave 1983 oder so bei einem Besuch in San Diego kennengelernt, also kannten Brian und ich uns bereits, zumindest flüchtig. Soweit ich mich erinnere, tauschten wir ein paar E-Mails und etwas Code aus und beschlossen, dass es albern wäre, wenn wir beide unabhängig voneinander etwas entwickeln würden, und die Zusammenarbeit war geboren.
An dieser Stelle sei darauf hingewiesen, dass meine gesamte Arbeit auf das Lesen von Nachrichten ausgerichtet war, nicht auf die Übertragung von Nachrichten. Das heißt, das Ziel war, dass ein Newsreader in der Lage sein sollte, einem Benutzer Artikel anzuzeigen, und nicht, News zwischen Rechnern zu übertragen, um UUCP zu ersetzen. Uns war zwar klar, dass es dafür verwendet werden könnte, aber das war nicht meine treibende Motivation. Aber Erik Fair, ein Freund von mir und eine Größe in USENET-Kreisen, überzeugte uns, dass es so modifiziert werden könnte und sollte, dass es sowohl zum Lesen als auch zum Transportieren geeignet ist.
Nun zu Ihren Fragen:
1. Welche Vorteile hat das Usenet für Ihr berufliches oder akademisches Leben gebracht?
Ich habe viel gelernt: Programmieren, wie man Software vertreibt, wie man mit anderen Menschen zusammenarbeitet, das Konzept, einen Bedarf zu finden und ihn zu erfüllen".
Ich habe dadurch einen ziemlich hohen Bekanntheitsgrad erlangt. Ich erinnere mich, dass ich Anfang der 1990er Jahre einen Mitarbeiter eines großen Unternehmens einstellte und seinen ehemaligen Chef anrief, den er als Referenz angegeben hatte. Als ich ihn anrief und mich als Phil Lapsley vorstellte, antwortete er: "Der Phil Lapsley?" Das war nett.
Ich habe nie Geld damit verdient - nicht, dass jemand von uns damals auch nur daran gedacht hätte, das zu tun.
Hey, wenn Giganews an die Börse geht, wirst du mich doch an den Anteilen von Freunden und Familie beteiligen, oder? 🙂 .
2. Wie haben die verschiedenen NNTP-Entwickler zusammengearbeitet?
Brian Kantor und ich arbeiteten fast ausschließlich per E-Mail. Brian war an der U.C. San Diego und ich war in Berkeley, so dass es fast zwangsläufig so ablief. Tatsächlich habe ich nie persönlich mit ihm zusammengearbeitet, nicht einmal per Telefon, bis zum Ende des Projekts, als wir an der endgültigen Version des RFC arbeiteten. Ich flog nach San Diego, um einen Freund zu besuchen, und kam in seinem Büro vorbei, um über den RFC zu sprechen. Ich erinnere mich, dass er sagte: "Verdammt, wir hätten uns eigentlich nicht persönlich treffen sollen. Dann hätten wir allen sagen können, dass wir das Ganze aus der Ferne gemacht haben!"
Erik Fair und ich waren beide in Berkeley, so dass wir uns oft bei chinesischem Essen trafen, aber wir tauschten uns auch viel per E-Mail aus. Ich erinnere mich auch daran, dass er einen Entwurf der Spezifikation geprüft hat, als er in Europa im Skiurlaub war. Er hatte keinen E-Mail-Zugang, also schrieb er seine Kommentare auf und schickte sie per Post an das Büro der CS-Abteilung in Berkeley. Leider war ich nur ein einfacher Student und hatte keinen Briefkasten, so dass sie das Paket in den toten Briefkasten warfen... und das, obwohl er meine E-Mail-Adresse an mehreren Stellen unterstrichen und eingekreist auf den Umschlag geschrieben hatte...
<sigh>
3. Technische Herausforderungen?
Die Dinge waren eigentlich relativ einfach, da keine "physikalischen Gesetze" verletzt wurden. Im Nachhinein betrachtet gab es eine ganze Reihe von Dingen, die wir hätten besser machen können (z.B. das Protokoll zustandslos machen), aber was wir taten, war keine Raketenwissenschaft (besonders im Nachhinein betrachtet!).
Die größte Sorge war wahrscheinlich, dass der NNTP-Server, nntpd, effizient sein musste, damit ucbvax nicht ins Stocken geriet. Es hätte den Zweck der ganzen Sache zunichte gemacht, wenn das passiert wäre, denn dann wäre Bob Henry gezwungen gewesen, ihn abzuschalten, und der Versuch, netnews einem breiteren Publikum zugänglich zu machen, wäre damit gescheitert. Glücklicherweise war nntpd am Ende ziemlich effizient, so dass das kein großes Problem darstellte. Das Client-Programm rn war ein ziemliches Schwein (hallo, Larry! J), und auf einigen der "Lehr"-Computer in Berkeley war rn nicht zugelassen, weil es den Rechner zu sehr belastete. Am Ende schrieben wir ein leichtgewichtiges Leseprogramm mit dem Namen "rmsgs" oder so ähnlich, das in Bezug auf die CPU-Auslastung viel weniger kostspielig war.
Es war eine ziemliche Herausforderung, nntpd für die verschiedenen UNIX-Versionen (von BSD über SysV bis Xenix und Gott weiß was noch alles) zu pflegen und mit neuen Versionen von rn von Larry Wall zu synchronisieren. Aber das waren nicht wirklich technische Herausforderungen, sondern eher betriebliche Herausforderungen - sie erforderten einfach Zeit, Energie und Mühe, und das war etwas, das ich als Vollzeitstudent in dieser Zeit nur in geringem Maße hatte.
4. Client-Server-Modell?
Das Client/Server-Modell war ziemlich neu. Es hört sich komisch an, das jetzt zu sagen, wo es doch ein so akzeptierter Teil der Funktionsweise ist, aber damals war es eine exotische Sache. Aber selbst damals war es die Hauptstütze der Internet-Architektur: Es gab SMTP, telnet, ftp, rlogin, rsh usw., die alle auf Client/Server basierten. Und tatsächlich wurde inetd geschrieben, um mit der wachsenden Anzahl von Daemons umzugehen, die geschrieben und benutzt wurden. Mit inetd mussten Sie nicht Dutzende von Hintergrundservern haben, die Ihr System verstopften, während Sie auf Verbindungen warteten.
Tatsächlich war beides hilfreich und schädlich. Auf der einen Seite sah man keine lästigen nntpd-Prozesse, wenn niemand News las, was die Sache gut aussehen ließ. Andererseits bedeutete es auch, daß man einen nntpd-Prozeß pro entferntem Newsreader hatte, was die Dinge ein wenig verstopfen konnte. Ich weiß, dass wir mit der Idee eines Multi-Threaded nntpd (ein nntpd bedient mehrere Clients) gespielt haben, aber ich kann mich nicht erinnern, dass wir jemals dazu gekommen sind, es zu implementieren.
5. Besondere Rollen?
Wie ich oben schon sagte, hatten Brian und ich beide unabhängig voneinander unsere eigenen Newsserver entwickelt und beschlossen, zusammenzuarbeiten und einen einzigen Server zu erstellen. Es war nie eine bewusste Entscheidung, aber irgendwann fing Brian an, sich mehr um das Schreiben des RFC zu kümmern, während ich mich mehr um das Schreiben des Codes kümmerte. Das war letztendlich ein ziemlich gutes System, da wir nicht nur eine Spezifikation (RFC), sondern gleichzeitig auch eine Referenzimplementierung für die Spezifikation hatten. In der Zwischenzeit stieß Erik Fair uns an und drängte und überredete uns, verschiedene richtige Dinge zu tun ... und er schrieb selbst etwas Code.
Es ist dieser Satz, der David Clark zugeschrieben wird: "Wir lehnen Könige, Präsidenten und Abstimmungen ab. Wir glauben an groben Konsens und funktionierenden Code." Ich denke, NNTP hat diesen Ansatz sehr gut verkörpert.
6. Waren Sie an anderen USENET-Projekten beteiligt?
Nicht wirklich. Ich betreute NNTP einige Jahre lang und übergab es dann um 1988 an Stan Barber in Baylor, der großartige Arbeit damit leistete. Zu dieser Zeit hatte ich ein Studium der digitalen Signalverarbeitung begonnen und wollte mehr Zeit mit dem Erlernen von DSP-Algorithmen und weniger mit dem Schreiben von UNIX-Code verbringen, so dass ich ganz natürlich ausstieg.
7. War die Entwicklung Teil Ihres Studiums oder persönlich?
Wie Sie oben wahrscheinlich sehen können, ist es persönlich. Sie müssen wissen, dass in Berkeley in den frühen 1980er Jahren noch nicht einmal C-Programmierung gelehrt wurde und die Professoren keine Ahnung hatten, was TCP/IP ist, so dass dies auf keinen Fall für einen Kurs geeignet gewesen wäre.