Unix -Philosophie

Ken Thompson und Dennis Ritchie, wichtige Befürworter der Unix -Philosophie

Das Unix -Philosophie, Entstanden durch Ken Thompsonist eine Reihe kultureller Normen und philosophischer Ansätze an minimalistisch, modular Software-Entwicklung. Es basiert auf der Erfahrung der führenden Entwickler der Unix Betriebssystem. Frühe Unix -Entwickler waren wichtig, um die Konzepte der Modularität und Wiederverwendbarkeit in die Software -Ingenieurpraxis zu bringen und ein "zu bringen", um ein "zu bringen"Software-Tools"Bewegung. Im Laufe der Zeit haben die führenden Entwickler von UNIX (und Programmen, die darauf ausgeführt) eine Reihe kultureller Normen für die Entwicklung von Software etabliert; diese Normen wurden genauso wichtig und einflussreich wie die Technologie der UNIX selbst und wurden als" Unix "bezeichnet. Philosophie."

Die Unix -Philosophie betont das Aufbau einfacher, kompaktes, klares, modulares und erweiterbar Code, der von anderen Entwicklern als Erschöpfer leicht gepflegt und wiederholt werden kann. Die Unix -Philosophie bevorzugt Komposition im Gegensatz zu monolithisches Design.

Herkunft

Die Unix -Philosophie wird dokumentiert von Doug McIlroy[1] im Bell System Technical Journal aus dem Jahr 1978:[2]

  1. Machen Sie jedes Programm eine Sache gut. Um einen neuen Job zu erledigen, bauen Sie neu auf, anstatt alte Programme zu komplizieren, indem Sie neue "Funktionen" hinzufügen.
  2. Erwarten Sie, dass die Ausgabe jedes Programms die Eingabe für einen anderen, noch unbekannten Programm wird. Die Ausgabe nicht mit fremden Informationen. Vermeiden Sie strenge Spalten- oder Binäreingangsformate. Bestehen Sie nicht auf interaktive Eingaben.
  3. Entwerfen und bauen Software und sogar Betriebssysteme, um innerhalb von Wochen frühzeitig zu probieren. Zögern Sie nicht, die ungeschickten Teile wegzuwerfen und sie wieder aufzubauen.
  4. Verwenden Sie die Vorlieben, um ungelernte Hilfe zu erhalten, um eine Programmieraufgabe zu erleichtern. Auch wenn Sie sich umziehen müssen, um die Werkzeuge zu erstellen, und erwarten, einige davon nach Abschluss zu werfen.

Es wurde später von zusammengefasst von Peter H. Salus In einem Vierteljahrhundert Unix (1994):[1]

  • Schreiben Sie Programme, die eine Sache tun, und machen Sie es gut.
  • Schreiben Sie Programme, um zusammenzuarbeiten.
  • Schreiben Sie Programme, um Textströme zu verarbeiten, da dies eine universelle Schnittstelle ist.

In ihrem preisgekrönten[3] UNIX -Papier von 1974, Ritchie und Thompson zitieren die folgenden Entwurfsüberlegungen:[4]

  • Machen Sie es einfach, Programme zu schreiben, zu testen und auszuführen.
  • Interaktiver Gebrauch statt von Stapelverarbeitung.
  • Wirtschaft und Eleganz des Designs aufgrund von Größenbeschränkungen ("Erlösung durch Leiden").
  • Selbsttragend System: Alle Unix -Software werden unter UNIX gepflegt.

Die UNIX -Programmierumgebung

In ihrem Vorwort zum Buch von 1984,, Die UNIX -Programmierumgebung, Brian Kernighan und Rob Pike, beide von Bell LabsGeben Sie eine kurze Beschreibung des UNIX -Designs und der Unix -Philosophie an:[5]

Rob Pike, co-author of Die UNIX -Programmierumgebung

Obwohl das UNIX -System eine Reihe innovativer Programme und Techniken einführt, funktioniert es kein einzelnes Programm oder eine Idee gut. Stattdessen ist es effektiv der Ansatz zur Programmierung, eine Philosophie der Verwendung des Computers. Obwohl diese Philosophie nicht in einem einzigen Satz niedergeschrieben werden kann, ist die Idee im Herzen, dass die Macht eines Systems mehr aus den Beziehungen zwischen den Programmen als von den Programmen selbst zurückzuführen ist. Viele UNIX -Programme tun isoliert ziemlich triviale Dinge, werden jedoch in Kombination mit anderen Programmen allgemeine und nützliche Werkzeuge.

Die Autoren schreiben weiter, dass ihr Ziel für dieses Buch "die Unix -Programmierphilosophie kommunizieren".[5]

Programmdesign in der UNIX -Umgebung

Brian Kernighan hat ausführlich über die Unix -Philosophie geschrieben

Im Oktober 1984 veröffentlichten Brian Kernighan und Rob Pike eine Zeitung mit dem Titel Programmdesign in der UNIX -Umgebung. In diesem Artikel kritisieren sie die Akkretion von Programmoptionen und Funktionen in einigen neueren Unix -Systemen wie z. B. 4.2bsd und System vund erklären Sie die Unix -Philosophie von Softwaretools, die jeweils eine allgemeine Funktion ausführen:[6]

Ein Großteil der Kraft des UNIX -Betriebssystems stammt aus einer Art von Programmdesign, die die Programme einfach zu verwenden und, was wichtiger ist, einfach mit anderen Programmen zu kombinieren ist. Dieser Stil wurde als Verwendung von genannt Software-Toolsund hängt mehr davon ab, wie die Programme in die Programmierumgebung passen und wie sie mit anderen Programmen verwendet werden können, als wie sie intern entworfen werden. [...] Dieser Stil basierte auf der Verwendung von Werkzeug: Verwenden von Programmen getrennt oder in Kombination, um einen Job zu erledigen, anstatt dies von Hand durch monolithische autarke Subsysteme oder durch Spezialpuls und einmalige Programme zu erledigen.

Die Autoren kontrastieren Unix -Tools wie z. Katze mit größeren Programmsuiten, die von anderen Systemen verwendet werden.[6]

Das Design von Katze ist typisch für die meisten UNIX -Programme: Es implementiert eine einfache, aber allgemeine Funktion, die in vielen verschiedenen Anwendungen verwendet werden kann (einschließlich vieler, die vom ursprünglichen Autor nicht vorgesehen sind). Andere Befehle werden für andere Funktionen verwendet. Beispielsweise gibt es separate Befehle für Dateisystemaufgaben wie Umbenennung von Dateien, Löschen oder Aussagen, wie groß sie sind. Andere Systeme füllen diese stattdessen in einen einzelnen "Dateisystem" -Fehl mit einer internen Struktur und einer eigenen Befehlssprache. (Das PIP -Dateikopieprogramm für Betriebssysteme wie CP/m oder RSX-11 ist ein Beispiel.) Dieser Ansatz ist nicht unbedingt schlechter oder besser, aber er ist sicherlich gegen die Unix -Philosophie.

Doug McIlroy über die UNIX -Programmierung

Doug McIlroy (zurückgelassen mit Dennis Ritchie

McIlroy, dann Leiter des Forschungszentrums des Bell Labs Computing Sciences und Erfinder der UNIX -Rohr,[7] fasste die UNIX -Philosophie wie folgt zusammen:[1]

Dies ist die Unix -Philosophie: Schreiben Sie Programme, die eine Sache tun und es gut machen. Schreiben Sie Programme, um zusammenzuarbeiten. Schreiben Sie Programme, um sie zu handhaben Textströme, weil das eine universelle Schnittstelle ist.

Über diese Aussagen hinaus hat er auch die Einfachheit und die Einfachheit betont und Minimalismus In der UNIX -Programmierung:[1]

Der Begriff der "komplizierten und schönen Komplexität" ist fast ein Oxymoron. UNIX -Programmierer wetteifern miteinander um "einfache und schöne" Ehrungen - ein Punkt, der in diesen Regeln impliziert ist, aber es lohnt sich, offen zu machen.

Umgekehrt hat McIlroy modern kritisiert Linux wie haben Software aufblähen, bemerken: "Verehrende Bewunderer haben Linux -Leckereien einem entmutigenden Zustand von Förder Fettleibigkeit. "[8] Er kontrastiert dies mit dem früheren Ansatz bei Bell Labs bei der Entwicklung und Überarbeitung Forschung Unix:[9]

Alles war klein ... und mein Herz sinkt auf Linux, wenn ich die Größe davon sehe. [...] Das Handbuch Seite, die früher wirklich ein Handbuch war SeiteIst jetzt ein kleines Volumen mit tausend Optionen ... wir saßen im Unix -Raum herum und sagte: „Was können wir wegwerfen? Warum gibt es diese Option? ' Es liegt oft daran, dass das Grunddesign einen gewissen Mangel hat - Sie haben nicht wirklich den richtigen Designpunkt erreicht. Überlegen Sie, was Sie gezwungen hat, diese Option hinzuzufügen, anstatt eine Option hinzuzufügen.

Mach eins und mach es gut

Wie von McIlroy angegeben und allgemein in der Unix -Community akzeptiert, wurde immer erwartet, dass UNIX -Programme dem Konzept von Dotadiw folgen oder "eins machen und es gut machen". Es gibt nur begrenzte Quellen für das Akronym Dotadiw im Internet, wird jedoch während der Entwicklung und Verpackung neuer Betriebssysteme, insbesondere in der Linux -Community, ausführlich erörtert.

Patrick Volkerding, der Projektleiter von Slackware Linux, rief dieses Designprinzip in einer Kritik an der systemd Architektur, die besagt: "Versuch, Dienstleistungen, Sockets, Geräte, Reittiere usw. zu kontrollieren, alle innerhalb eines Dämon fliegt dem Unix -Konzept, eines zu tun und es gut zu machen. "[10]

Eric Raymonds 17 Unix -Regeln

In seinem Buch Die Kunst der Unix -Programmierung Das wurde erstmals 2003 veröffentlicht,[11] Eric S. Raymond (Open Source Advocate und Programmierer) fasst die UNIX -Philosophie als zusammen Kussprinzip von "Halten Sie es einfach, dumm."[12] Er bietet eine Reihe von Designregeln:[1]

  • Bauen modular Programme
  • Schreiben Sie lesbare Programme
  • Verwenden Sie Komposition
  • Getrennte Mechanismen von der Politik
  • Schreiben Sie einfache Programme
  • Schreiben Sie kleine Programme
  • Schreiben Sie transparente Programme
  • Schreiben Sie robuste Programme
  • Daten bei Bedarf kompliziert machen, nicht das Programm
  • Bauen Sie auf dem erwarteten Wissen der potenziellen Benutzer auf
  • Vermeiden Sie unnötige Ausgabe
  • Schreiben Sie Programme, die in einer Weise versagen, die leicht zu diagnostizieren ist
  • Value Developer -Zeit über Maschinenzeit
  • Schreiben Abstrakte Programme, die Code generieren anstatt Code von Hand zu schreiben
  • Prototyp Software vor dem Polieren
  • Schreiben Sie flexible und offene Programme
  • Machen Sie das Programm und Protokolle ausdehnbar.

Mike Gancarz: Die Unix -Philosophie

1994 Mike Gancarz (ein Mitglied des Teams, das das entworfen hat X Fenstersystem) stützte sich auf seine eigenen Erfahrungen mit UNIX sowie Diskussionen mit anderen Programmierern und Menschen in anderen Bereichen, die von Unix abhängig waren, um zu produzieren Die Unix -Philosophie Was es in neun Paramount -Vorschriften zusammenfasst:

  1. Klein ist schön.
  2. Machen Sie jedes Programm eine Sache gut.
  3. Erstellen Sie so schnell wie möglich einen Prototyp.
  4. Wählen Sie die Tragbarkeit über die Effizienz.
  5. Daten in flach speichern Textdateien.
  6. Verwenden Sie die Software -Hebelwirkung zu Ihrem Vorteil.
  7. Verwenden Shell -Skripte Hebel und Portabilität erhöhen.
  8. Vermeiden Sie Captive User Interfaces.
  9. Machen Sie jedes Programm a Filter.

"Schlimmer ist besser"

Hauptartikel: Schlimmer ist besser

Richard P. Gabriel deutet darauf hin, dass ein wesentlicher Vorteil von UNIX darin bestand, dass es eine Designphilosophie verkörperte, die er als "schlechter ist ist besser", in der die Einfachheit beider Grenzflächen bezeichnete und Die Implementierung ist wichtiger als alle anderen Attribute des Systems - einschließlich Korrektheit, Konsistenz und Vollständigkeit. Gabriel argumentiert, dass dieser Designstil wichtige evolutionäre Vorteile hat, obwohl er die Qualität einiger Ergebnisse in Frage stellt.

Zum Beispiel verwendete Unix in den frühen Tagen a monolithischer Kernel (Dies bedeutet, dass Benutzerprozesse Kernel -Systeme aufgerufen haben, alle auf dem Benutzerstapel). Wenn ein Signal an einen Prozess geliefert wurde, während es langfristig blockiert wurde I/o Was sollte dann im Kernel getan werden? Sollte das Signal möglicherweise für eine lange Zeit (vielleicht auf unbestimmte Zeit) verzögert werden, während die E/A abgeschlossen ist? Der Signalhandler konnte nicht ausgeführt werden, wenn sich der Prozess im Kernelmodus befand, mit empfindlichen Kerneldaten auf dem Stapel. Sollte der Kernel den System zurückrufen und es später speichern, um später wiederzugeben und neu zu starten, vorausgesetzt, der Signalhandler schließt erfolgreich ab?

In diesen Fällen Ken Thompson und Dennis Ritchie Bevorzugte Einfachheit gegenüber Perfektion. Das UNIX -System kehrte gelegentlich früh von einem Systemaufruf zurück, wobei ein Fehler besagt, dass es nichts getan hatte - dem "unterbrochenen Systemaufruf" oder einer Fehler Nummer 4 (Eintr) In den heutigen Systemen. Natürlich war der Anruf abgebrochen worden, um den Signalhandler aufzurufen. Dies könnte nur für eine Handvoll langjähriger Systemanrufe wie z. lesen(), schreiben(), offen(), und auswählen(). Auf der positiven Seite machte das E/A -System ein Vielfaches einfacher zu entwerfen und zu verstehen. Die überwiegende Mehrheit der Benutzerprogramme war nie betroffen SIGINT und würde sofort sterben, wenn man erhöht würde. Für die wenigen anderen Programme - Dinge wie Shells oder Textredakteure, die auf die Taste der Arbeitskontrolle reagieren - können SYSTEMALLE WRAPERS zu Systemaufrufen hinzugefügt werden, um den Anruf sofort wiederzuholen, wenn dieser Eintr Fehler wurde aufgeworfen. Somit wurde das Problem einfach gelöst.

Kritik

In einem Artikel von 1981 mit dem Titel "Die Wahrheit über Unix: Die Benutzeroberfläche ist schrecklich"[13] veröffentlicht in DataMation, Don Norman kritisierte die Designphilosophie von UNIX für die mangelnde Sorge um die Benutzeroberfläche. Schreiben aus seinem Hintergrund in der kognitiven Wissenschaft und aus der Perspektive der damaligen Stromphilosophie von Kognitive Engineering,[14] Er konzentrierte Kognitiver Modell von Systemen - oder im Fall von UNIX nicht verstehen, dass katastrophale Fehler (z. B. die Arbeit einer Stunde Arbeit verlieren) allzu einfach sind.

Siehe auch

Anmerkungen

  1. ^ a b c d e Raymond, Eric S. (2004). "Grundlagen der Unix -Philosophie". Die Kunst der Unix -Programmierung. Addison-Wesley Professional (veröffentlicht 2003-09-23). ISBN 0-13-142901-9. Abgerufen 2016-11-01.
  2. ^ Doug McIlroy, E. N. Pinson, B. A. Tague (8. Juli 1978). "Unix Time-Sharing-System: Vorwort". Das Bell System Technical Journal. Bell Laboratories: 1902–1903.{{}}: Cs1 montiert: Mehrfachnamen: Autorenliste (Link)
  3. ^ "ACM - Dennis M. Richie". Archiviert von das Original am 26. Januar 2021. Abgerufen 26. August, 2021. ACM -Programmiersysteme und Sprachenpapier Preis
  4. ^ Dennis Ritchie; Ken Thompson (1974), "Das Unix Time-Sharing-System" (PDF), Kommunikation der ACM, 17 (7): 365–375, doi:10.1145/361011.361061, S2CID 53235982
  5. ^ a b Kernighan, Brian W. Pike, Rob. Die UNIX -Programmierumgebung. 1984. viii
  6. ^ a b Rob Pike; Brian W. Kernighan (Oktober 1984). "Programmdesign in der UNIX -Umgebung" (PDF).
  7. ^ Dennis Ritchie (1984), "Die Entwicklung des Unix Time-Sharing-Systems" (PDF), AT & T Bell Laboratories Technical Journal, 63 (8): 1577–1593, doi:10.1002/j.1538-7305.1984.tb00054.x
  8. ^ Douglas McIlroy. "Bemerkungen zur japanischen Preisverleihung für Dennis Ritchie, 19. Mai 2011, Murray Hill, NJ" (PDF). Abgerufen 2014-06-19.
  9. ^ Bill McGonigle. "Ancestry of Linux - Wie der Spaß begann (2005)". Abgerufen 2014-06-19.
  10. ^ "Interview mit Patrick Volkerding von Slackware". Linuxquestions.org. 2012-06-07. Abgerufen 2015-10-24.
  11. ^ Raymond, Eric (2003-09-19). Die Kunst der Unix -Programmierung. Addison-Wesley. ISBN 0-13-142901-9. Abgerufen 2009-02-09.
  12. ^ Raymond, Eric (2003-09-19). "Die Unix -Philosophie in einer Lektion". Die Kunst der Unix -Programmierung. Addison-Wesley. ISBN 0-13-142901-9. Abgerufen 2009-02-09.
  13. ^ Norman, Don (1981). "Die Wahrheit über Unix: Die Benutzeroberfläche ist schrecklich" (PDF). DataMation. Vol. 27, nein. 12.
  14. ^ "Eine mündliche Geschichte von Unix". Princeton Universität Geschichte der Wissenschaft.

Verweise

Externe Links