Darüber hinaus kann jeder von ihnen viele verschiedene Rechenprozesse ausführen, die die Ressourcen dieses bestimmten Computers verwenden.

Der zweite große Vorteil von Unix ist seine Multiplattform-Natur. Der Kern des Systems ist so konzipiert, dass es problemlos an nahezu jeden Mikroprozessor angepasst werden kann.

Unix hat andere charakteristische Merkmale:

• Verwenden einfacher Textdateien zum Konfigurieren und Verwalten des Systems;
• weit verbreitete Verwendung von Dienstprogrammen, die von der Befehlszeile aus gestartet werden;
• Interaktion mit dem Benutzer über ein virtuelles Gerät - ein Terminal;
• Darstellung physischer und virtueller Geräte und einiger Mittel der Kommunikation zwischen Prozessen in Form von Dateien;
• die Verwendung von Pipelines aus mehreren Programmen, die jeweils eine Aufgabe erfüllen.

Anwendung

Derzeit werden Unix-Systeme hauptsächlich auf Server verteilt und auch als eingebettete Systeme für verschiedene Geräte, einschließlich Smartphones. Unix-Systeme dominieren auch Supercomputer, insbesondere Linux ist auf 100% der TOP500-Supercomputer installiert.

Die ersten Versionen von Unix waren in Assemblersprache geschrieben und hatten keinen eingebauten Hochsprachen-Compiler. Um 1969 entwickelte und implementierte Ken Thompson mit Unterstützung von Dennis Ritchie die Bee (B)-Sprache, die eine vereinfachte (für die Implementierung auf Minicomputern) Version der in der Sprache entwickelten BCPL-Sprache war. Bi war wie BCPL eine interpretierte Sprache. 1972 veröffentlicht zweite Ausgabe Unix umgeschrieben in B. 1969-1973. auf der Grundlage von Bi wurde eine kompilierte Sprache namens C (C) entwickelt.

Teilt

Ein wichtiger Grund für die Spaltung von Unix war die Implementierung des TCP/IP-Protokollstacks im Jahr 1980. Zuvor steckte die Maschine-zu-Maschine-Kommunikation in Unix noch in den Kinderschuhen – die bedeutendste Kommunikationsmethode war UUCP (ein Mittel zum Kopieren von Dateien von einem Unix-System auf ein anderes, das ursprünglich über Telefonnetze mit Modems funktionierte).

Es wurden zwei Programmierschnittstellen für Netzwerkanwendungen vorgeschlagen: die Berkley-Sockets und die TLI-Transportschichtschnittstelle (Transport Layer Interface).

Die Berkley-Sockets-Schnittstelle wurde an der University of Berkeley entwickelt und nutzte den dort entwickelten TCP/IP-Protokollstack. TLI wurde von AT&T gemäß der Transportschichtdefinition des OSI-Modells erstellt und erschien erstmals in System V Version 3. Obwohl diese Version TLI und Streams enthielt, hatte sie ursprünglich keine Implementierung von TCP/IP oder anderen Netzwerkprotokollen, aber solche Implementierungen wurden von Drittanbietern bereitgestellt.

Die Implementierung von TCP/IP wurde offiziell und endgültig in die Basisdistribution von System V Version 4 aufgenommen. Dies führte zusammen mit anderen Überlegungen (hauptsächlich Marketing) zu der endgültigen Abgrenzung zwischen den beiden Zweigen von Unix - BSD (University of Berkeley) und System V (kommerzielle Version von AT&T). Anschließend entwickelten viele Unternehmen, die System V von AT&T lizenziert hatten, ihre eigenen kommerziellen Varianten von Unix, wie AIX, CLIX, HP-UX, IRIX, Solaris.

Moderne Implementierungen von Unix sind im Allgemeinen keine reinen V- oder BSD-Systeme. Sie implementieren Funktionen von System V und BSD.

Kostenlose Unix-ähnliche Betriebssysteme

Im Moment übernehmen GNU/Linux und Mitglieder der BSD-Familie schnell den Markt von kommerziellen Unix-Systemen und infiltrieren gleichzeitig sowohl Endbenutzer-Desktops als auch mobile und eingebettete Systeme.

Proprietäre Systeme

Seit der Aufspaltung von AT&T wechselten die Unix-Marke und die Rechte am Original-Quellcode mehrfach den Besitzer, insbesondere gehörten sie lange Zeit Novell.

Der Einfluss von Unix auf die Entwicklung von Betriebssystemen

Unix-Systeme sind von großer historischer Bedeutung, weil sie einige der heute populären Betriebssystem- und Softwarekonzepte und -ansätze propagiert haben. Außerdem wurde während der Entwicklung von Unix-Systemen die C-Sprache geschaffen.

Die in der Systemprogrammierung weit verbreitete Sprache C, die ursprünglich für die Entwicklung von Unix entwickelt wurde, hat Unix an Popularität übertroffen. Die C-Sprache war die erste "tolerante" Sprache, die nicht versuchte, dem Programmierer einen Programmierstil aufzuzwingen. C war die erste Hochsprache, die Zugriff auf alle Funktionen des Prozessors gab, wie Referenzen, Tabellen, Bitverschiebungen, Inkremente usw. Andererseits führte die Freiheit der Sprache C zu Pufferüberlauffehlern in solchen Standard-C-Bibliotheksfunktionen wie Gets und Scanf. Daraus resultierten viele berüchtigte Sicherheitslücken, wie die, die im berühmten Morris-Wurm ausgenutzt wurde.

Die frühen Unix-Entwickler trugen zur Einführung der Prinzipien der modularen Programmierung und Wiederverwendung in der Ingenieurpraxis bei.

Unix ermöglichte die Verwendung von TCP/IP-Protokollen auf relativ kostengünstigen Computern, was zum schnellen Wachstum des Internets führte. Dies wiederum trug zur schnellen Entdeckung mehrerer großer Schwachstellen in der Unix-Sicherheit, -Architektur und -Systemdienstprogrammen bei.

Im Laufe der Zeit entwickelten führende Unix-Entwickler kulturelle Normen für die Softwareentwicklung, die so wichtig wurden wie Unix selbst. ( )

Einige der bekanntesten Beispiele für Unix-ähnliche Betriebssysteme sind macOS, Solaris, BSD und NeXTSTEP.

Soziale Rolle in der IT-Fachwelt und historische Rolle

Das ursprüngliche Unix lief auf großen Mehrplatzrechnern, die auch proprietäre Betriebssysteme des Hardwareherstellers wie RSX-11 und dessen Nachkommen VMS anboten. Trotz der Tatsache, dass nach einer Reihe von Meinungen [ Deren?] Das damalige Unix hatte Nachteile gegenüber diesen Betriebssystemen (z. B. das Fehlen ernsthafter Datenbank-Engines), es war: a) billiger und manchmal kostenlos für akademische Einrichtungen; b) wurde von Hardware zu Hardware portiert und in einer portablen C-Sprache entwickelt, die die Softwareentwicklung von spezifischer Hardware „entkoppelte“. Darüber hinaus stellte sich heraus, dass die Benutzererfahrung von der Ausrüstung und dem Hersteller „nicht gebunden“ war – eine Person, die mit Unix auf VAX gearbeitet hatte, arbeitete problemlos damit auf 68xxx und so weiter.

Die damaligen Hardwarehersteller standen Unix oft kühl gegenüber, betrachteten es als Spielzeug und boten ihr proprietäres Betriebssystem für ernsthafte Arbeiten an - hauptsächlich DBMS und darauf basierende Geschäftsanwendungen in kommerziellen Strukturen. Es sind diesbezügliche Kommentare von DEC zu seinem VMS bekannt. Die Konzerne hörten darauf, nicht aber das akademische Umfeld, das in Unix alles für sich hatte, oft keine offizielle Unterstützung des Herstellers benötigte, sich selbst verwaltete und die Billigkeit und Portabilität von Unix schätzte. Somit war Unix vielleicht das erste Betriebssystem, das auf unterschiedliche Hardware portierbar war.

Der zweite große Aufstieg von Unix war die Einführung von RISC-Prozessoren um 1989. Schon davor gab es sog. Workstations sind leistungsstarke Einzelbenutzer-PCs mit genügend Arbeitsspeicher, Festplatte und genügend fortschrittlichem Betriebssystem (Multitasking, Speicherschutz), um mit ernsthaften Anwendungen wie CADs zu arbeiten. Unter den Herstellern solcher Maschinen stach Sun Microsystems hervor und machte sich damit einen Namen.

Vor dem Aufkommen von RISC-Prozessoren verwendeten diese Stationen normalerweise den Motorola 680x0-Prozessor, derselbe wie in Apple-Computern (allerdings unter einem fortschrittlicheren Betriebssystem als dem von Apple). Um 1989 erschienen kommerzielle Implementierungen von Prozessoren mit RISC-Architektur auf dem Markt. Die logische Entscheidung einer Reihe von Unternehmen (Sun und andere) war, Unix auf diese Architekturen zu portieren, was sofort zur Portierung des gesamten Unix-Software-Ökosystems führte.

Proprietäre seriöse Betriebssysteme wie VMS begannen ab diesem Moment ihren Niedergang (auch wenn es möglich war, das Betriebssystem selbst auf RISC zu übertragen, war alles viel komplizierter mit Anwendungen dafür, die in diesen Ökosystemen oft in Assembler oder entwickelt wurden in proprietären Sprachen wie BLISS), und Unix wurde zum Betriebssystem für die leistungsstärksten Computer der Welt.

Ungefähr zu dieser Zeit begann sich das Ökosystem jedoch in Richtung der GUI in Form von Windows 3.0 zu bewegen. Die enormen Vorteile der GUI sowie beispielsweise die einheitliche Unterstützung aller Druckertypen wurden sowohl von Entwicklern als auch von Benutzern geschätzt. Dies untergrub die Position von Unix auf dem PC-Markt erheblich – Implementierungen wie SCO und Interactive UNIX konnten mit der Unterstützung von Windows-Anwendungen nicht fertig werden. Die GUI für Unix namens X11 (es gab andere, viel weniger beliebte Implementierungen) konnte aufgrund des Speicherbedarfs nicht vollständig auf dem PC eines normalen Benutzers ausgeführt werden - X11 benötigte 16 MB für den normalen Betrieb, während Windows 3.1 über genügend Leistung verfügte Führen Sie sowohl Word als auch Excel gleichzeitig in 8 MB aus (das war damals die Standardgröße des PC-Speichers). Bei hohen Speicherpreisen war dies der limitierende Faktor.

Der Erfolg von Windows gab Anstoß zu einem internen Microsoft-Projekt namens Windows NT, das mit Windows per API kompatibel war, aber gleichzeitig die gleichen architektonischen Merkmale eines ernsthaften Betriebssystems wie Unix hatte - Multitasking, vollständiger Speicherschutz, Unterstützung für Multiprozessoren Maschinen, Dateiberechtigungen und Verzeichnisse, Systemprotokoll. Windows NT führte auch das Journaling-Dateisystem NTFS ein, das zu dieser Zeit alle standardmäßig mit Unix gelieferten Dateisysteme in Bezug auf die Fähigkeiten übertraf - Analoga für Unix waren nur separate kommerzielle Produkte von Veritas und anderen.

Obwohl Windows NT aufgrund seines hohen Speicherbedarfs (gleiche 16 MB) anfangs nicht beliebt war, ermöglichte es Microsoft den Eintritt in den Markt für Serverlösungen wie DBMS. Viele glaubten damals nicht an die Fähigkeit von Microsoft, das traditionell auf Desktop-Software spezialisiert ist, ein Akteur auf dem Markt für Unternehmenssoftware zu sein, der bereits große Namen wie Oracle und Sun hatte. Hinzu kam die Tatsache, dass Microsofts DBMS – SQL Server – als vereinfachte Version von Sybase SQL Server begann, lizenziert von Sybase und zu 99 % kompatibel in allen Aspekten der Arbeit damit.

In der zweiten Hälfte der 1990er Jahre begann Microsoft, Unix auch auf den Unternehmensservermarkt zu drängen.

Die Kombination der oben genannten Faktoren sowie der Preisverfall für 3D-Videocontroller, die von professionellen Geräten zu Hause geworden sind, haben das Workstation-Konzept Anfang der 2000er Jahre im Wesentlichen zerstört.

Zudem sind Microsoft-Systeme gerade in typischen Anwendungsfällen einfacher zu verwalten.

Aber im Moment hat der dritte starke Aufstieg von Unix begonnen.

Zudem war Stallman und seinen Mitstreitern durchaus bewusst, dass proprietäre Entwicklungswerkzeuge für den Erfolg von Nicht-Unternehmenssoftware nicht geeignet waren. Daher entwickelten sie eine Reihe von Compilern für verschiedene Programmiersprachen (gcc), die zusammen mit den früher entwickelten GNU-Dienstprogrammen (die die Standard-Unix-Dienstprogramme ersetzten) ein notwendiges und ziemlich leistungsfähiges Softwarepaket für den Entwickler darstellten.

FreeBSD war zu dieser Zeit ein ernsthafter Konkurrent von Linux, jedoch der "Kathedralen"-Stil des Entwicklungsmanagements im Gegensatz zum "Bazaar"-Stil von Linux sowie viel mehr technischer Archaismus in Angelegenheiten wie der Unterstützung von Multiprozessormaschinen und ausführbaren Dateien Formate, verlangsamten die Entwicklung von FreeBSD im Vergleich zu Linux erheblich und machten letzteres zum Flaggschiff der Welt der freien Software.

In der Zukunft erreichte Linux immer mehr Höhen:

• Portierung seriöser proprietärer Produkte wie Oracle;
• das ernsthafte Interesse von IBM an diesem Ökosystem als Grundlage für seine vertikalen Lösungen;
• das Erscheinen von Analoga fast aller bekannten Programme aus der Windows-Welt;
• die Weigerung einiger Hardwarehersteller von der obligatorischen Vorinstallation von Windows;
• die Veröffentlichung von Netbooks nur mit Linux;
• Verwendung als Kernel in Android.

Im Moment ist Linux ein zu Recht beliebtes Betriebssystem für Server, obwohl es auf Desktops viel weniger beliebt ist.

Einige Architekturmerkmale des Unix-Betriebssystems

Unix-Funktionen, die diese Familie von anderen Betriebssystemen unterscheiden, sind unten aufgeführt.

• Das Dateisystem ist baumartig, unterscheidet zwischen Groß- und Kleinschreibung bei Namen, sehr schwache Beschränkungen für die Länge von Namen und Pfaden.
• Es gibt keine Unterstützung für strukturierte Dateien durch den OS-Kernel; auf der Ebene von Systemaufrufen ist eine Datei ein Strom von Bytes.
• Die Befehlszeile befindet sich im Adressraum des gestarteten Prozesses und wird nicht durch einen Systemaufruf vom Befehlsinterpreterprozess abgerufen (wie dies beispielsweise bei RSX-11 der Fall ist).
• Das Konzept der "Umgebungsvariablen".
• Starten von Prozessen durch Aufrufen von fork(), d. h. die Möglichkeit, den aktuellen Prozess mit dem gesamten Status zu klonen.
• Die Konzepte von stdin/stdout/stderr.
• E/A nur über Dateideskriptoren.
• Traditionell sehr schwache Unterstützung für asynchrones I/O im Vergleich zu VMS und Windows NT.
• Der Befehlsinterpreter ist eine gewöhnliche Anwendung, die über gewöhnliche Systemaufrufe mit dem Kernel kommuniziert (in RSX-11 und VMS wurde der Befehlsinterpreter als spezielle Anwendung ausgeführt, auf besondere Weise im Speicher platziert, wobei spezielle Systemaufrufe verwendet wurden, Systemaufrufe waren wird ebenfalls unterstützt, sodass die Anwendung auf ihre übergeordneten Interpreterbefehle zugreifen kann).
• Ein Befehlszeilenbefehl ist nichts anderes als der Name einer Programmdatei, es ist keine spezielle Registrierung und spezielle Entwicklung von Programmen als Befehle erforderlich (was in RSX-11, RT-11 üblich war).
• Der Ansatz mit einem Programm, das dem Benutzer Fragen zu seiner Funktionsweise stellt, wird nicht akzeptiert, stattdessen werden Kommandozeilenparameter verwendet (in VMS, RSX-11, RT-11 arbeiteten Programme auch mit der Kommandozeile, aber ohne sie wurden aufgefordert, Parameter einzugeben).
• Ein Geräte-Namespace auf der Festplatte im /dev-Verzeichnis, der von einem Administrator verwaltet werden kann, im Gegensatz zum Windows-Ansatz, bei dem sich dieser Namespace im Kernelspeicher befindet, und die Verwaltung dieses Namespace (z. B. das Festlegen von Berechtigungen) ist aufgrund der Mangel an permanentem Speicher auf Festplatten (wird bei jedem Booten erstellt).
• Umfangreiche Verwendung von Textdateien zum Speichern von Einstellungen im Gegensatz zu einer binären Einstellungsdatenbank wie in Windows.
• Weit verbreitete Verwendung von Textverarbeitungsprogrammen, um alltägliche Aufgaben unter der Kontrolle von Skripten auszuführen.
• "Promotion" des Betriebssystems nach dem Laden des Kernels durch Ausführen von Skripten mit einem Standard-Befehlsinterpreter.
• Weit verbreitet

Die Geschichte von UNIX® beginnt im Jahr 1969. Die meisten modernen UNIX-Systeme sind kommerzielle Versionen der ursprünglichen UNIX-Distributionen. Solaris von Sun, HP-UX von Hewlett-Packard, AIX® von IBM sind die besten Vertreter von UNIX, die auch ihre eigenen einzigartigen Elemente und ihre eigenen grundlegenden Lösungen haben. Beispielsweise ist Sun Solaris UNIX, enthält aber auch viele Tools und Erweiterungen, die speziell für Sun-Workstations und -Server entwickelt wurden.

Linux® wurde entwickelt, um eine kostenlose Alternative zu kommerziellen UNIX-Umgebungen bereitzustellen. Seine Geschichte reicht bis 1991 oder sogar 1983 zurück, als das GNU-Projekt gegründet wurde, dessen ursprüngliches Ziel es war, eine kostenlose Alternative zu UNIX bereitzustellen. Linux läuft auf vielen weiteren Plattformen wie Intel®/AMD x86. Die meisten UNIX-Betriebssysteme können nur auf einer Plattform ausgeführt werden.

Linux und UNIX haben gemeinsame historische Wurzeln, aber es gibt auch signifikante Unterschiede. Viele Tools, Dienstprogramme und kostenlose Anwendungen, die standardmäßig mit Linux geliefert werden, wurden ursprünglich als kostenlose Alternativen zu UNIX-Programmen konzipiert. Linux bietet oft Unterstützung für viele Optionen und Anwendungen und leiht sich die besten oder beliebtesten Funktionen von UNIX.

Als Administrator oder Entwickler, der es gewohnt ist, mit Linux zu arbeiten, mag das UNIX-System nicht sehr benutzerfreundlich erscheinen. Andererseits ist die Grundlage eines UNIX-ähnlichen Betriebssystems (Tools, Dateisystem, APIs) ziemlich standardisiert. Einige Details der Systeme können jedoch erhebliche Unterschiede aufweisen. Diese Unterschiede werden später in diesem Artikel besprochen.

Technische Unterschiede

Entwickler kommerzieller UNIX-Distributionen verlassen sich auf eine bestimmte Gruppe von Clients und Serverplattformen für ihr Betriebssystem. Sie haben eine gute Vorstellung davon, welche Art von Unterstützung und Optimierung welche Anwendungen umgesetzt werden müssen. UNIX-Hersteller tun ihr Bestes, um die Kompatibilität zwischen verschiedenen Versionen sicherzustellen. Darüber hinaus veröffentlichten sie die Standards ihres Betriebssystems.

Die GNU/Linux-Entwicklung hingegen ist nicht plattform- oder kundenorientiert, und GNU/Linux-Entwickler haben unterschiedliche Hintergründe und Perspektiven. In der Linux-Community gibt es keinen strikten Standardsatz von Tools oder Umgebungen. Um dieses Problem zu lösen, wurde das Projekt Linux Standards Base (LSB) ins Leben gerufen, das sich jedoch als nicht so effektiv herausstellte, wie wir es gerne hätten.

Dieser Mangel an Standardisierung führt zu erheblichen Inkonsistenzen innerhalb von Linux. Für einige Entwickler ist die Möglichkeit, die besten anderen Betriebssysteme zu verwenden, von Vorteil, aber das Kopieren von UNIX-Elementen nach Linux ist nicht immer bequem, beispielsweise wenn Gerätenamen innerhalb von Linux von AIX übernommen werden können, während Dateisystem-Tools HP- UX-orientiert. Auch zwischen verschiedenen Linux-Distributionen treten solche Inkompatibilitäten auf. Zum Beispiel implementieren Gentoo und RedHat unterschiedliche Update-Methoden.

Im Vergleich dazu enthält jede neue Version des UNIX-Systems eine gut dokumentierte Beschreibung der neuen Funktionen und Änderungen in UNIX. Befehle, Tools und andere Elemente ändern sich selten, und häufig bleiben die gleichen Befehlszeilenargumente für Anwendungen in vielen Versionen dieser Software gleich. Wenn an diesen Elementen wesentliche Änderungen vorgenommen werden, stellen Anbieter von kommerziellen UNIX-Systemen häufig den Wrapper bereit, der erforderlich ist, um die Kompatibilität mit früheren Versionen des Tools sicherzustellen.

Diese Kompatibilität bedeutet, dass Dienstprogramme und Anwendungen auf neuen Versionen von Betriebssystemen verwendet werden können, ohne deren Quellcode zu überprüfen oder zu ändern. Daher ist die Migration auf eine neue UNIX-Version, die in der Regel keine grundlegenden Unterschiede zur alten Version aufweist, für Benutzer oder Administratoren mit viel weniger Aufwand verbunden als die Migration von einer Linux-Distribution zu einer anderen.

Hardware-Architektur

Die meisten kommerziellen Versionen von UNIX sind für eine oder eine kleine Anzahl von Hardwarearchitekturen gebaut. HP-UX läuft nur auf PA-RISC- und Itanium-Plattformen, Solaris auf SPARC und x86 und AIX nur für POWER-Prozessoren.

Aufgrund dieser Einschränkungen können UNIX-Anbieter ihren Code relativ frei für diese Architekturen ändern und alle Vorteile ihrer Architektur nutzen. Da sie die von ihnen unterstützten Geräte so gut kennen, funktionieren ihre Treiber besser und sie müssen sich nicht mit PC-spezifischen BIOS-Einschränkungen auseinandersetzen.

Linux hingegen wurde historisch auf maximale Kompatibilität ausgelegt. Linux ist auf einer Vielzahl von Architekturen verfügbar, und die Anzahl der E/A-Geräte und anderer Peripheriegeräte, die mit dem Betriebssystem verwendet werden können, ist nahezu unbegrenzt. Entwickler können nicht im Voraus wissen, welche spezifische Hardware in einem Computer installiert wird, und können oft nicht sicherstellen, dass sie effektiv verwendet wird. Ein Beispiel ist die Speicherverwaltung unter Linux. Zuvor verwendete Linux ein segmentiertes Speichermodell, das ursprünglich für x86 entwickelt wurde. Es ist jetzt für die Verwendung von Seitenspeicher angepasst, behält aber immer noch einige segmentierte Speicheranforderungen bei, was Probleme verursacht, wenn die Architektur keinen segmentierten Speicher unterstützt. Dies ist kein Problem für UNIX-Anbieter. Sie wissen genau, auf welcher Hardware ihr UNIX laufen wird.

Kern

Der Kernel ist das Herzstück des Betriebssystems. Der Quellcode für den Kernel kommerzieller UNIX-Distributionen ist Eigentum ihrer Entwickler und wird nicht außerhalb des Unternehmens verteilt. Völlig entgegengesetzte Situation mit Linux. Die Verfahren zum Kompilieren und Patchen von Kerneln und Treibern sind ziemlich unterschiedlich. Für Linux und andere Open-Source-Betriebssysteme kann ein Patch als Quellcode veröffentlicht werden und der Endbenutzer kann ihn installieren, testen und sogar modifizieren. Diese Patches werden normalerweise nicht so sorgfältig getestet wie Patches von kommerziellen UNIX-Betriebssystemanbietern. Da es keine vollständige Liste von Anwendungen und Umgebungen gibt, die getestet werden müssen, damit sie unter Linux korrekt laufen, sind Linux-Entwickler darauf angewiesen, dass Endbenutzer und andere Entwickler Fehler finden.

Anbieter kommerzieller UNIX-Distributionen veröffentlichen Kernel nur als ausführbaren Code. Einige Releases sind monolithisch, während andere Ihnen erlauben, nur ein bestimmtes Kernelmodul zu aktualisieren. Aber in jedem Fall wird diese Version nur in Form von ausführbarem Code bereitgestellt. Wenn ein Update erforderlich ist, muss der Administrator warten, bis der Hersteller einen Patch in Binärform veröffentlicht, kann sich jedoch darüber trösten, dass der Hersteller seinen Patch sorgfältig auf Abwärtskompatibilität prüft.

Alle kommerziellen UNIX-Versionen haben sich bis zu einem gewissen Grad zu einem modularen Kernel entwickelt. Treiber und spezifische Betriebssystemfunktionen sind als separate Komponenten verfügbar und können je nach Bedarf aus dem Kernel geladen oder entladen werden. Aber die offene modulare Architektur von Linux ist viel flexibler. Die Flexibilität und Anpassungsfähigkeit von Linux bedeutet jedoch ständige Veränderung. Der Linux-Quellcode ändert sich ständig, und nach Lust und Laune des Entwicklers kann sich die API ändern. Wenn ein Modul oder Treiber für eine kommerzielle Version von UNIX geschrieben wird, hält es viel länger als derselbe Treiber für Linux.

Dateisystemunterstützung

Einer der Gründe, warum Linux zu einem so leistungsstarken Betriebssystem geworden ist, ist seine breite Kompatibilität mit anderen Betriebssystemen. Eines der offensichtlichsten Merkmale ist die Fülle der verfügbaren Dateisysteme. Die meisten kommerziellen UNIX-Versionen unterstützen zwei oder drei Dateisystemtypen. Linux unterstützt jedoch die meisten modernen Dateisysteme. zeigt, welche Dateisysteme von UNIX unterstützt werden. Jedes dieser Dateisysteme kann unter Linux gemountet werden, obwohl nicht alle diese Dateisysteme das Lesen und Schreiben von Daten vollständig unterstützen.

Tabelle 1. Standardmäßige Dateisysteme für UNIX

Die meisten kommerziellen UNIX-Versionen unterstützen Journaling-Dateisysteme. Beispielsweise verwendet HP-UX hfs als Standarddateisystem, unterstützt aber auch das Journaled vxfs-Dateisystem. Solaris unterstützt ufs und zfs. Ein Journaling-Dateisystem ist eine wesentliche Komponente jeder Unternehmensserverumgebung. In Linux wurde die Unterstützung für Journaled Filesysteme spät eingeführt, aber es gibt jetzt mehrere Optionen, von Klonen kommerzieller Dateisysteme (xfs, jfs) bis hin zu Linux-spezifischen Dateisystemen (ext3, reiserfs).

Weitere Dateisystemfunktionen umfassen Quota-Unterstützung, Dateizugriffskontrolllisten, Spiegelung, System-Snapshots und Größenanpassung. Sie werden in der einen oder anderen Form von Linux-Dateisystemen unterstützt. Die meisten dieser Funktionen sind unter Linux nicht Standard. Einige Funktionen funktionieren möglicherweise auf einem Dateisystem, während andere ein anderes Dateisystem erfordern. Einige dieser Funktionen sind auf bestimmten Linux-Dateisystemen einfach nicht verfügbar, und andere erfordern die zusätzliche Installation von Tools, wie z. B. eine bestimmte Version von LVM oder Unterstützung für Disk-Arrays (Software-Raid-Paket). In der Vergangenheit war die Kompatibilität zwischen Programmierschnittstellen und Standardwerkzeugen unter Linux schwierig, daher implementieren viele Dateisysteme diese Funktionen auf unterschiedliche Weise.

Da kommerzielle UNIX-Systeme eine begrenzte Anzahl von Dateisystemen unterstützen, sind ihre Tools und Techniken zum Arbeiten mit ihnen stärker standardisiert. Da beispielsweise in Irix nur ein Master-Dateisystem unterstützt wurde, gab es nur eine Möglichkeit, Zugriffskontrolllisten festzulegen. Dies ist viel bequemer für den Endbenutzer und für die weitere Unterstützung dieses Betriebssystems.

Anwendungsverfügbarkeit

Die meisten grundlegenden Anwendungen sind unter UNIX und Linux gleich. Beispielsweise sind die Befehle cp , ls , vi und cc unter UNIX und Linux verfügbar und sehr ähnlich, wenn nicht sogar völlig identisch. Die Linux-Versionen dieser Tools basieren auf den GNU-Versionen dieser Tools, während die UNIX-Versionen dieser Tools auf den traditionellen UNIX-Tools basieren. Diese UNIX-Tools haben eine lange Geschichte und ändern sich selten.

Aber das bedeutet nicht, dass kommerzielle Versionen von UNIX nicht mit GNU-Tools verwendet werden können. Tatsächlich enthalten viele kommerzielle UNIX-Betriebssystemanbieter viele GNU-Tools in ihren Distributionen oder bieten sie als kostenlose Add-Ons an. GNU-Tools sind nicht nur Standard-Tools. Einige dieser kostenlosen Dienstprogramme haben keine kommerziellen Gegenstücke (emacs oder Perl). Die meisten Hersteller installieren diese Programme vor und sie werden entweder automatisch mit dem System installiert oder sind als optionale Funktion verfügbar.

Kostenlose und Open-Source-Anwendungen sind fast immer in alle Linux-Distributionen integriert. Es gibt eine große Menge kostenloser Software für Linux, und viele dieser Anwendungen wurden auf kommerzielle Versionen des UNIX-Betriebssystems portiert.

Kommerzielle und/oder Closed-Source-Anwendungen (CAD, Finanzprogramme, grafischer Editor) hat möglicherweise keine Analoga für Linux. Obwohl einige Anbieter Versionen ihrer Anwendungen für Linux veröffentlichen, haben die meisten Anbieter keine Eile damit, bis die Popularität von Linux unter den Benutzern zunimmt.

Andererseits haben kommerzielle Versionen von UNIX in der Vergangenheit eine große Anzahl von Anwendungen auf Unternehmensebene wie Oracle oder SAP unterstützt. Linux verliert stark, weil es schwierig ist, große Anwendungen zu zertifizieren, während kommerzielle Versionen von UNIX sich von Release zu Release nicht wesentlich ändern. Linux kann sich stark ändern, nicht nur mit jeder neuen Distribution, sondern manchmal auch zwischen Releases derselben Distribution. Daher ist es für einen Softwarehersteller sehr schwierig, genau zu verstehen, in welcher Umgebung seine Anwendung verwendet wird.

Systemadministration

Obwohl einige Linux-Distributionen mit einem Standardsatz von Systemadministrationstools geliefert werden, wie YaST von SUSE, gibt es keinen gemeinsamen Standard für Linux-Systemadministrationstools.Textdateien und Befehlszeilentools sind verfügbar, aber manchmal kann ihre Verwendung unpraktisch sein.Jede kommerzielle Version UNIX verfügt über eine eigene Systemverwaltungsschnittstelle. Mit dieser Schnittstelle können Sie Systemelemente verwalten und ändern. Im Folgenden finden Sie ein Beispiel für System Administration Manager für HP-UX.

Dieses SAM enthält die folgenden Module:

• Zu verwaltende Benutzer oder Gruppen.
• Kernel-Optionen, die geändert werden können.
• Netzwerkkonfiguration.
• Festplatten einrichten und initialisieren.
• X-Server-Konfiguration.

Die Qualität dieses Dienstprogrammpakets ist ausgezeichnet, und das Dienstprogrammpaket funktioniert gut mit Textdateien. Es gibt kein Analogon dieses Tools für Linux. Selbst YaST in SUSE hat nicht die gleiche Funktionalität.

Ein weiterer Aspekt in UNIX und Linux, der sich mit fast jeder Version des Betriebssystems zu ändern scheint, ist der Speicherort der Systeminitialisierungsskripte. Glücklicherweise sind /sbin/init und /etc/inittab Standardverzeichnisse. Die Systemstartskripte befinden sich jedoch in anderen Verzeichnissen. zeigt die Speicherorte, an denen Systeminitialisierungsskripte für verschiedene UNIX- und Linux-Distributionen gespeichert sind.

Tabelle 2. Speicherort von Systeminitialisierungsskripten für verschiedene UNIX-Versionen

HP-UX	/sbin/init.d
AIX	/etc/rc.d/init.d
Irix	/etc/init.d
Solaris	/etc/init.d
roter Hut	/etc/rc.d/init.d
SUSE	/etc/rc.d/init.d
Debian	/etc/init.d
Slackware	/etc/rc.d

Aufgrund der großen Anzahl von Linux-Distributionen und der fast unendlichen Anzahl verfügbarer Anwendungen (da es auch viele Versionen dieser Anwendung gibt) für dieses Betriebssystem wird die Verwaltung von Programmen unter Linux zu einer schwierigen Aufgabe. Die Wahl des richtigen Tools hängt davon ab, mit welcher Distribution Sie arbeiten. Weitere Unannehmlichkeiten ergeben sich aus der Tatsache, dass einige Distributionen das Dateiformat Redhat Package Manager (RPM) verwenden, während ihre Programme nicht kompatibel sind. Diese Aufteilung führt zu einer Vielzahl von Möglichkeiten, mit Paketen zu arbeiten, und es ist nicht immer klar, welches System in einer bestimmten Umgebung verwendet wird.

Andererseits enthalten kommerzielle Distributionen von UNIX Standard-Paketmanager. Obwohl es verschiedene Anwendungsversionen und spezifische Formate für verschiedene UNIX-Versionen gibt, ist die Anwendungsverwaltungsumgebung dieselbe. Beispielsweise hat Solaris seit seiner Einführung dieselben Verwaltungstools für Anwendungspakete verwendet. Und höchstwahrscheinlich werden die Mittel zum Identifizieren, Hinzufügen oder Entfernen von Softwarepaketen in Solaris unverändert bleiben.

Hersteller kommerzieller UNIX-Distributionen liefern auch die Hardware, auf der ihr Betriebssystem ausgeführt werden soll, damit sie neue Geräte in ihr Betriebssystem einführen können, was für Linux viel schwieriger ist. Zum Beispiel im letzte Version Linux hat versucht, Unterstützung für Hot-Swap-fähige Komponenten zu implementieren (mit unterschiedlichem Erfolg). Kommerzielle Versionen von UNIX verfügen seit vielen Jahren über diese Fähigkeit. Außerdem ist die Hardwareüberwachung in kommerziellen Versionen von UNIX besser als in Linux. Hersteller können Treiber schreiben und in ihr Betriebssystem einbetten, das den Systemzustand wie ECC-Speicherfehler, Energieeinstellungen oder andere Hardwarekomponenten überwacht. Diese Art von Unterstützung für Linux ist erst in ferner Zukunft zu erwarten.

Hardware für kommerzielle UNIX-Systeme verfügt auch über erweiterte Boot-Optionen. Bevor das Betriebssystem startet, gibt es viele Optionen, um den Startvorgang anzupassen, den Zustand des Systems zu überprüfen oder Hardwareeinstellungen anzupassen. Das BIOS eines Standard-PCs hat, wenn überhaupt, nur wenige dieser Optionen.

Die Unterstützung

Einer der wichtigsten Unterschiede zwischen Linux und UNIX sind die Kosten. Die Anbieter kommerzieller UNIX-Systeme haben einen hohen Preis für ihr UNIX verlangt, obwohl es nur mit ihren Hardware-Plattformen verwendet werden kann. Linux-Distributionen hingegen sind relativ günstig, wenn nicht gar kostenlos.

Wenn Sie eine kommerzielle Version von UNIX kaufen, bieten Anbieter normalerweise technischen Support an. Die meisten Linux-Benutzer werden vom Betriebssystemhersteller nicht unterstützt. Sie können Unterstützung nur per E-Mail, Foren und verschiedenen Communitys von Linux-Benutzern erhalten. Diese Gruppen sind jedoch nicht nur für Linux-Benutzer. Viele Administratoren kommerzieller Betriebssysteme der UNIX-Familie beteiligen sich an diesen offenen Support-Gruppen, um sowohl Hilfestellung leisten als auch gegebenenfalls nutzen zu können. Viele Menschen finden solche Selbsthilfegruppen sogar nützlicher als das Support-System des OS-Herstellers.

Fazit

Die Grundlagen von UNIX und Linux sind sehr ähnlich. Für einen Benutzer oder Systemadministrator wird der Wechsel von Linux zu UNIX die Arbeit etwas umständlicher machen, aber im Allgemeinen wird der Übergang schmerzlos sein. Auch wenn die Dateisysteme und Kernel unterschiedlich und etwas gewöhnungsbedürftig sind, bleiben die Tools und APIs gleich. Diese Unterschiede sind größtenteils nicht signifikanter als die Unterschiede zwischen Hauptversionen von UNIX. Alle Zweige von UNIX und Linux entwickeln sich allmählich weiter und werden sich geringfügig voneinander unterscheiden, aber aufgrund der Reife der UNIX-Konzepte werden sich die Grundlagen des Betriebssystems nicht sehr ändern.

Einführung

Was ist Unix?

Wo bekommt man kostenloses Unix?

Was sind die Hauptunterschiede zwischen Unix und anderen Betriebssystemen?

Warum Unix?

Grundlegende Unix-Konzepte

Dateisystem

Befehlsinterpreter

Handbücher - Mann

Einführung

Über das Betriebssystem Unix zu schreiben ist extrem schwierig. Erstens, weil viel über dieses System geschrieben wurde. Zweitens, weil die Ideen und Entscheidungen von Unix einen enormen Einfluss auf die Entwicklung aller modernen Betriebssysteme hatten und haben, und viele dieser Ideen sind bereits in diesem Buch beschrieben. Drittens, weil Unix nicht ein Betriebssystem ist, sondern eine ganze Familie von Systemen, und es nicht immer möglich ist, ihre Beziehung zueinander zu "verfolgen", und es einfach unmöglich ist, alle in dieser Familie enthaltenen Betriebssysteme zu beschreiben . Dennoch versuchen wir, ohne Anspruch auf Vollständigkeit, einen oberflächlichen Überblick über die „Unix-Welt“ in den uns für unsere Schulung interessant erscheinenden Bereichen zu geben.

Die Geburt des Unix-Betriebssystems geht auf das Ende der 60er Jahre zurück, und diese Geschichte hat bereits "Legenden" erworben, die manchmal auf unterschiedliche Weise über die Details dieses Ereignisses berichten. Das Betriebssystem Unix wurde im Forschungszentrum Bell Telephone Laboratories (Bell Labs) geboren, das Teil der AT&T Corporation ist. Ursprünglich war dieses Initiativprojekt für den PDP-7-Computer (später - für den PDP-11) entweder ein Dateisystem oder ein Computerspiel oder ein Textvorbereitungssystem oder beides. Wichtig ist jedoch, dass das Projekt, das schließlich zu einem Betriebssystem wurde, von Anfang an als Softwareumgebung für die gemeinsame Nutzung konzipiert war. Der Autor der ersten Version von Unix ist Ken Thompson, jedoch nahm ein großes Team von Mitarbeitern (D. Ritchie, B. Kernigan, R. Pike und andere) an der Diskussion des Projekts und anschließend an seiner Implementierung teil . Unserer Meinung nach bestimmten einige glückliche Umstände der Geburt von Unix den Erfolg dieses Systems für viele Jahre.

Für die meisten Leute in dem Team, in dem das Unix-Betriebssystem geboren wurde, war dieses Betriebssystem das "dritte System". Es gibt die Meinung (siehe zum Beispiel), dass ein Systemprogrammierer erst mit Abschluss seines dritten Projekts hohe Qualifikationen erreicht: Das erste Projekt ist noch "Student", der zweite Entwickler versucht, alles einzubeziehen, was im ersten nicht geklappt hat, und dadurch erweist es sich als zu umständlich, und erst im dritten wird die notwendige Balance von Wünschen und Möglichkeiten erreicht. Es ist bekannt, dass das Bell Labs-Team vor der Geburt von Unix (zusammen mit einer Reihe anderer Firmen) an der Entwicklung des MULTICS-Betriebssystems beteiligt war. Das Endprodukt von MULTICS (Bell Labs war an den letzten Phasen der Entwicklung nicht beteiligt) trägt alle Merkmale eines "Zweitsystems" und wird nicht weit verbreitet. Es sollte jedoch beachtet werden, dass viele grundlegend wichtige Ideen und Entscheidungen in diesem Projekt geboren wurden und einige Konzepte, die viele als in Unix geboren betrachten, tatsächlich aus dem MULTICS-Projekt stammen.

Das Betriebssystem Unix war ein System, das „für mich selbst und für meine Freunde“ gemacht wurde. Unix war nicht darauf eingestellt, den Markt zu erobern und mit irgendeinem Produkt zu konkurrieren. Die Entwickler des Unix-Betriebssystems selbst waren seine Benutzer und beurteilten selbst die Eignung des Systems für ihre Bedürfnisse. Ohne den Druck der Marktbedingungen könnte eine solche Einschätzung äußerst objektiv sein.

Unix war ein System, das von Programmierern für Programmierer gemacht wurde. Dies bestimmte einerseits die Eleganz und konzeptionelle Harmonie des Systems, andererseits die Notwendigkeit, das System für einen Unix-Benutzer zu verstehen, und ein professionelles Verantwortungsgefühl für einen Programmierer, der Software für Unix entwickelt. Und keine nachfolgenden Versuche, "Unix für Dummies" zu machen, konnten das Unix-Betriebssystem von dieser Tugend befreien.

1972-73 Ken Thompson und Dennis Ritchie haben eine neue Version von Unix geschrieben. Speziell für diesen Zweck hat D. Ritchie die Programmiersprache C geschaffen, die nun nicht mehr benötigt wird. Über 90 % des Unix-Codes ist in dieser Sprache geschrieben, und die Sprache ist zu einem integralen Bestandteil des Betriebssystems geworden. Die Tatsache, dass der Hauptteil des Betriebssystems in einer Hochsprache geschrieben ist, ermöglicht es, es in den Code jeder Hardwareplattform neu zu kompilieren, und ist der Umstand, der die weite Verbreitung von Unix bestimmt hat.

Während der Gründung von Unix verhinderten US-Kartellgesetze, dass AT&T in den Softwaremarkt eintrat. Daher war das Betriebssystem Unix nicht kommerziell und wurde frei verteilt, hauptsächlich an Universitäten. Dort wurde seine Entwicklung fortgesetzt und am aktivsten an der University of California in Berkeley durchgeführt. An dieser Universität wurde die Gruppe Berkeley Software Distribution gegründet, die sich mit der Entwicklung eines separaten Zweigs des Betriebssystems BSD Unix befasste. Im Laufe der folgenden Geschichte haben sich Mainstream-Unix und BSD-Unix parallel entwickelt und sich gegenseitig immer wieder bereichert.

Als sich das Unix-Betriebssystem verbreitete, interessierten sich kommerzielle Firmen immer mehr dafür, die damit begannen, ihre eigenen kommerziellen Versionen dieses Betriebssystems herauszubringen. Im Laufe der Zeit wurde der "Haupt"-Zweig von Unix von AT&T kommerziell, und eine Tochtergesellschaft von Unix System Laboratory wurde gegründet, um ihn zu fördern. Der BSD-Unix-Zweig wurde wiederum in kommerzielles BSD und Free BSD gegabelt. Verschiedene kommerzielle und freie Unix-ähnliche Systeme wurden auf dem AT&T-Unix-Kernel aufgebaut, enthielten jedoch Funktionen, die von BSD-Unix entlehnt wurden, sowie Originalfunktionen. Trotz der gemeinsamen Quelle häuften sich die Unterschiede zwischen Mitgliedern der Unix-Familie und machten schließlich das Portieren von Anwendungen von einem Unix-ähnlichen Betriebssystem auf ein anderes extrem schwierig. Auf Initiative von Unix-Anwendern gab es eine Bewegung zur Standardisierung der Unix-API. Diese Bewegung wurde von der International Organization for Standards ISO unterstützt und führte zur Entstehung des POSIX-Standards (Portable Operation System Interface eXecution), der sich noch in der Entwicklung befindet und der maßgeblichste Standard für das Betriebssystem ist. POSIX-Spezifikationen zu einem offiziellen Standard zu machen, ist jedoch ein ziemlich langsamer Prozess und wird den Anforderungen von Softwareanbietern nicht gerecht, was zur Entstehung alternativer Industriestandards geführt hat.

Mit dem Übergang von AT&T Unix zu Nowell änderte sich der Name dieses Betriebssystems in Unixware, und die Rechte an der Unix-Marke wurden an das X / Open-Konsortium übertragen. Dieses Konsortium (jetzt die Open Group) entwickelte seine eigene (breiter als POSIX) Systemspezifikation, die als Single Unix Specification bekannt ist. Die zweite Ausgabe dieses Standards wurde kürzlich veröffentlicht und ist viel besser auf POSIX abgestimmt.

Schließlich gründeten eine Reihe von Firmen, die ihre eigenen Unix-Versionen produzierten, das Open Software Foundation (OSF)-Konsortium, das ihre eigene Version von Unix, OSF/1, basierend auf dem Mach-Mikrokernel veröffentlichte. OSF veröffentlichte auch die OSF/1-Systemspezifikationen, die den OSF-Mitgliedsfirmen als Grundlage für die Veröffentlichung ihrer eigenen Unix-Systeme dienten. Zu diesen Systemen gehören SunOS von Sun Microsystems, AIX von IBM, HP/UX von Hewlett-Packard, DIGITAL UNIX von Compaq und andere.

Anfangs basierten die Unix-Systeme dieser Firmen hauptsächlich auf BSD Unix, aber jetzt werden die meisten modernen industriellen Unix-Systeme unter Verwendung des Kernels AT&T Unix System V Release 4 (S5R4) (unter Lizenz) erstellt, obwohl sie auch einige Funktionen von BSD Unix erben . Wir übernehmen keine Verantwortung für den Vergleich kommerzieller Unix-Systeme, da solche Vergleiche, die periodisch im Druck erscheinen, oft völlig gegensätzliche Ergebnisse liefern.

Nowell verkaufte Unix an Santa Crouse Operations, die ihr eigenes Unix-Produkt, SCO Open Server, produzierten. SCO Open Server basierte auf einer früheren Version des Kernels (System V Release 3), war jedoch hervorragend debuggt und sehr stabil. Santa Crouse Operations integrierte sein Produkt mit AT&T Unix und veröffentlichte Open Unix 8, verkaufte Unix dann aber an Caldera, den Besitzer des heutigen "klassischen" Unix (Ende 2001).

Sun Microsystems begann seine Einführung in die Unix-Welt mit SunOS, basierend auf dem BSD-Kernel. Später wurde es jedoch durch ein Solaris-System auf Basis des S5R4 ersetzt. Version 8 dieses Betriebssystems wird derzeit verteilt (es gibt auch v.9-beta). Solaris läuft auf der SPARC-Plattform (RISC-Prozessoren, die nach Sun-Spezifikationen hergestellt werden) und Intel-Pentium.

Hewlett-Packard bietet das Betriebssystem HP-UX an. v.11 auf der PA-RISC-Plattform. HP-UX basiert auf S5R4, enthält aber viele Funktionen, die seine Herkunft von BSD Unix verraten. Natürlich wird HP-UX auch auf der Intel-Itanium-Plattform verfügbar sein.

IBM bringt das AIX-Betriebssystem heraus, die aktuellste Version ist 5L (wird später besprochen). IBM hat den "Stammbaum" von AIX nicht bekannt gegeben, es handelt sich größtenteils um Eigenentwicklungen, aber die ersten Versionen trugen Spuren der Herkunft von FreeBSD Unix. Jetzt ist AIX jedoch eher wie S5R4. AIX war ursprünglich auf der Intel-Pentium-Plattform verfügbar, wurde aber später (gemäß der allgemeinen IBM-Richtlinie) auf dieser Plattform nicht mehr unterstützt. AIX läuft derzeit auf IBM RS/6000-Servern und anderen PowerPC-basierten Computerplattformen (einschließlich IBM-Supercomputern).

DIGITAL UNIX von DEC war die einzige kommerzielle Implementierung von OSF/1. Das Betriebssystem DIGITAL UNIX lief auf Alpha RISC-Servern von DEC. Als DEC 1998 von Compaq übernommen wurde, erwarb Compaq sowohl Alpha- als auch DIGITAL UNIX-Server. Compaq beabsichtigt, seine Präsenz auf dem Markt der Alpha-Server wiederherzustellen und entwickelt in diesem Zusammenhang intensiv ein Betriebssystem für sie. Der aktuelle Name dieses Betriebssystems ist Tru64 Unix (aktuelle Version ist 5.1A), es basiert weiterhin auf dem OSF/1-Kernel und hat viele BSD-Unix-Funktionen.

Obwohl die meisten kommerziellen Unix-Systeme auf einem einzelnen Kernel basieren und den POSIX-Anforderungen entsprechen, hat jedes seinen eigenen API-Dialekt, und die Unterschiede zwischen den Dialekten sind kumulativ. Dies führt dazu, dass die Portierung industrieller Anwendungen von einem Unix-System auf ein anderes schwierig ist und zumindest eine Neukompilierung und oft auch eine Korrektur des Quellcodes erfordert. Ein Versuch, die "Verwirrung" zu überwinden und ein einziges Unix-Betriebssystem für alle zu schaffen, wurde 1998 von einer Allianz aus SCO, IBM und Sequent unternommen. Diese Firmen schlossen sich im Monterey-Projekt zusammen, um ein einziges Betriebssystem basierend auf Unixware zu erstellen, das damals im Besitz von SCO, IBM AIX und DYNIX OS von Sequent war. (Sequent ist führend in der Produktion von NUMA-Computern - asymmetrische Multiprozessoren - und DYNIX ist Unix für solche Computer). Das Monterey-Betriebssystem sollte auf der 32-Bit-Intel-Pentium-Plattform, der 64-Bit-PowerPC-Plattform und der neuen 64-Bit-Intel-Itanium-Plattform laufen. Nahezu alle führenden Unternehmen der Hardware- und Middleware-Industrie haben ihre Unterstützung für das Projekt erklärt. Sogar Firmen, die ihre eigenen Unix-Klone haben (außer Sun Microsystems), haben angekündigt, dass sie Monterey nur auf Intel-Plattformen unterstützen werden. Die Arbeit an dem Projekt schien gut voranzukommen. Monterey OS war eines der ersten, das seine Leistung auf Intel-Itanium (zusammen mit Windows NT und Linux) unter Beweis stellte, und das einzige, das die 32-Bit-Intel-Pentium-Architektur nicht emulierte. In der Endphase des Projekts ereignete sich jedoch ein fataler Zwischenfall: SCO verkaufte seine Unix-Sparte. Noch früher wurde Sequent Teil von IBM. Der "Nachfolger" aller Funktionen von Monterey OS ist IBM AIX v.5L OS. Allerdings nicht ganz alle. Die Intel-Pentium-Plattform ist kein strategischer Schwerpunkt für IBM und AIX ist auf dieser Plattform nicht verfügbar. Und weil andere führende Unternehmen der Computerindustrie die Position von IBM nicht (oder nicht ganz) teilen, wurde die Idee eines gemeinsamen Unix-Betriebssystems nie verwirklicht.

Wenn Sie kürzlich begonnen haben, Linux zu lernen und sich in diesem riesigen Universum wohl zu fühlen, dann ist Ihnen der Begriff Unix wahrscheinlich schon oft begegnet. Klingt sehr ähnlich wie Linux, aber was bedeutet das? Sie fragen sich wahrscheinlich, was der Unterschied zwischen Unix und Linux ist. Die Antwort auf diese Frage hängt davon ab, was Sie unter diesen Wörtern verstehen. Schließlich kann jeder von ihnen auf unterschiedliche Weise interpretiert werden. In diesem Artikel sehen wir uns eine vereinfachte Geschichte von Linux und Unix an, um Ihnen zu helfen, zu verstehen, was sie sind und wie sie zusammenhängen. Wie immer können Sie in den Kommentaren Fragen stellen oder weitere Informationen hinzufügen.

Unix begann seine Geschichte in den späten 1960er und frühen 1970er Jahren bei AT&T Bell Labs in den Vereinigten Staaten. Gemeinsam mit dem MIT und General Electric begann Bell Labs mit der Entwicklung eines neuen Betriebssystems. Einige Forscher waren mit der Entwicklung dieses Betriebssystems unzufrieden. Sie verließen die Arbeit am Hauptprojekt und begannen, ihr eigenes Betriebssystem zu entwickeln. 1970 hieß dieses System Unix und zwei Jahre später wurde es komplett in der Programmiersprache C neu geschrieben.

Dadurch konnte Unix verteilt und portiert werden verschiedene Geräte und Computerplattformen.

Als sich Unix weiterentwickelte, begann AT&T, es sowohl für den universitären Gebrauch als auch für kommerzielle Zwecke zu lizenzieren. Dies bedeutete, dass nicht jeder wie jetzt den Code des Unix-Betriebssystems frei ändern und verteilen konnte. Bald erschienen viele Editionen und Varianten des Unix-Betriebssystems, um verschiedene Probleme zu lösen. Das bekannteste davon war BSD.

Linux ähnelt Unix in Funktionalität und Features, aber nicht in der Codebasis. Dieses Betriebssystem wurde aus zwei Projekten zusammengestellt. Das erste ist das 1983 von Richard Stallman entwickelte GNU-Projekt, das zweite ist der 1991 von Linus Torvalds geschriebene Linux-Kernel.

Das Ziel des GNU-Projekts war es, ein Unix-ähnliches, aber von Unix unabhängiges System zu schaffen. Mit anderen Worten, ein Betriebssystem, das keinen Unix-Code enthält, der frei weitergegeben und ohne Einschränkungen modifiziert werden könnte, wie freie Software. Da der freie Linux-Kernel nicht alleine laufen konnte, fusionierte das GNU-Projekt mit dem Linux-Kernel und das Linux-Betriebssystem war geboren.

Linux wurde unter dem Einfluss des Minix-Systems entwickelt, einem Nachkommen von Unix, aber der gesamte Code wurde von Grund auf neu geschrieben. Im Gegensatz zu Unix, das auf Servern und großen Mainframes verschiedener Unternehmen verwendet wurde, wurde Linux für die Verwendung auf diesen entwickelt Heimcomputer mit einfacher Hardware.

Heute läuft Linux auf mehr Plattformen als jedes andere Betriebssystem, darunter Server, eingebettete Systeme, Mikrocomputer, Modems und sogar Mobiltelefone. Nun wird der Unterschied zwischen Linux und Unix genauer betrachtet.

Was ist Unix

Der Begriff Unix kann sich auf solche Konzepte beziehen:

• Das von AT&T Bell Labs entwickelte ursprüngliche Betriebssystem, aus dem andere Betriebssysteme entwickelt werden.
• Warenzeichen, in Großbuchstaben geschrieben. UNIX gehört The Open Group, die die Single UNIX Specification entwickelt hat, eine Reihe von Standards für Betriebssysteme. Nur solche Systeme, die den Standards entsprechen, dürfen berechtigterweise als UNIX bezeichnet werden. Die Zertifizierung ist nicht kostenlos und erfordert, dass Entwickler für die Verwendung dieser Marke bezahlen.
• Alle Betriebssysteme sind mit dem Unix-Namen registriert. Denn sie erfüllen die oben genannten Standards. Dies sind AIX, A/UX, HP-UX, Inspur K-UX, Reliant UNIX, Solaris, IRIX, Tru64, UnixWare, z/OS und OS X – ja, sogar solche, die auf Apple-Rechnern laufen.

Was ist Linux

Der Begriff Linux bezieht sich nur auf den Kernel. Ein Betriebssystem wäre ohne eine Desktop-Umgebung und Anwendungen nicht vollständig. Da die meisten Anwendungen unter dem GNU-Projekt entwickelt wurden und jetzt entwickelt werden, lautet der vollständige Name des Betriebssystems GNU/Linux.

Viele Leute verwenden jetzt den Begriff Linux, um sich auf alle Distributionen zu beziehen, die auf dem Linux-Kernel basieren. Im Moment ist die neueste Version des Linux-Kernels 4.4, Version 4.5 ist in Entwicklung. Die Umnummerierung der Kernel-Releases von 3.x auf 4.x ist noch gar nicht so lange her.

Linux ist ein Unix-ähnliches Betriebssystem, das sich wie Unix verhält, aber keinen eigenen Code enthält. Unix-ähnliche Betriebssysteme werden oft als Un*x, *NIX und *N?X oder sogar Unixoids bezeichnet. Linux hat keine Unix-Zertifizierung, und GNU steht für GNU not Unix, also ist Mac OS X in dieser Hinsicht eher Unix als Linux. Dennoch sind der Linux-Kernel und das GNU-Linux-Betriebssystem Unix in der Funktionalität sehr ähnlich und implementieren die meisten Prinzipien der Unix-Philosophie. Es handelt sich um lesbaren Code, der die Systemkonfiguration in separaten Textdateien speichert und kleine Befehlszeilentools, eine grafische Shell und einen Sitzungsmanager verwendet.

Es ist wichtig zu beachten, dass nicht alle Unix-ähnlichen Systeme eine UNIX-Zertifizierung erhalten haben. In einem bestimmten Kontext werden alle Betriebssysteme, die auf UNIX oder seinen Ideen basieren, als UNIX-ähnlich bezeichnet, unabhängig davon, ob sie ein UNIX-Zertifikat haben oder nicht. Darüber hinaus können sie kommerziell und kostenlos sein.

Ich hoffe, es ist jetzt deutlicher geworden, wie sich Unix von Linux unterscheidet. Aber gehen wir noch weiter und fassen zusammen.

Hauptunterschiede

• Linux ist ein freies Open-Source-Betriebssystem, das ursprüngliche Unix jedoch nicht, mit Ausnahme einiger seiner Derivate.
• Linux ist ein Klon des ursprünglichen Unix, aber es enthält keinen Code.
• Der Hauptunterschied zwischen Unix und Linux besteht darin, dass Linux nur ein Kernel ist, während Unix ein vollwertiges Betriebssystem war und ist.
• Linux wurde für PCs entwickelt. Und Unix konzentriert sich hauptsächlich auf große Workstations und Server.
• Heute unterstützt Linux mehr Plattformen als Unix.
• Linux unterstützt mehr Arten von Dateisystemen als Unix.

Wie Sie sehen können, kommt die Verwirrung normalerweise von der Tatsache, dass Linux und Unix völlig unterschiedliche Dinge bedeuten können. Was auch immer die Bedeutung sein mag, die Tatsache bleibt, dass Unix zuerst kam und Linux später. Linux wurde aus dem Wunsch nach Softwarefreiheit und Portabilität geboren, inspiriert vom Unix-Ansatz. Man kann mit Sicherheit sagen, dass wir alle der Freie-Software-Bewegung verpflichtet sind, weil die Welt ohne sie ein viel schlimmerer Ort wäre.

MINISTERIUM FÜR BILDUNG UND WISSENSCHAFT DER RUSSISCHEN

FÖDERATION

BUNDESAGENTUR FÜR BILDUNG

STAATLICHE BILDUNGSEINRICHTUNG

HOCHSCHULBILDUNG

Taganrog State Radio Engineering University

Disziplin "Informatik"

"UNIX-Betriebssystem"

Abgeschlossen von: Orda-Zhigulina D.V., gr. E-25

Geprüft: Vishnevetsky V.Yu.

Taganrog 2006

Einführung

Was ist Unix 3

Wo bekommt man kostenloses Unix 7

Hauptteil. (Beschreibung von Unix)

1. Grundkonzepte von Unix 8

2. Dateisystem 9

2.1 Dateitypen 9

3. Befehlsinterpreter 11

4. UNIX 12-Kernel

4.1 Allgemeine Organisation des traditionellen UNIX-Kernels 13

4.2 Hauptfunktionen des Kernels 14

4.3 Prinzipien der Interaktion mit dem Kern 15

4.4 Prinzipien der Interruptbehandlung 17

5. E/A-Steuerung 18

5.1 Prinzipien der System-E/A-Pufferung 19

5. 2 Systemaufrufe zur E/A-Steuerung 21

6. Schnittstellen und Eingabepunkte von Treibern 23

6.1 Treiber sperren 23

6.2 Zeichentreiber 24

6. 3 Stream-Treiber 25

7. Befehle und Dienstprogramme 25

7. 1 Teamorganisation in UNIX OS 26

7.2 E/A-Umleitung und Verrohrung 26

7. 3 Eingebaute, Bibliotheks- und Benutzerbefehle 26

7.4 Programmieren der Befehlssprache 27

8. GUI-Tools 27

8.1 Benutzerkennungen und Benutzergruppen 30

8.2 Dateischutz 32

8.3 Vielversprechende Betriebssysteme, die die UNIX-Betriebssystemumgebung unterstützen 33

Fazit

Hauptunterschiede zwischen Unix und anderen OS 36

Anwendungen von Unix 37

Einführung

Was ist Unix

Der Begriff Unix und das nicht ganz äquivalente UNIX werden mit unterschiedlichen Bedeutungen verwendet. Beginnen wir mit dem zweiten der Terme als dem einfacheren. Kurz gesagt, UNIX (in dieser Form) ist eine eingetragene Marke, die ursprünglich der AT&T Corporation gehörte, die im Laufe der Jahre den Besitzer gewechselt hat und nun Eigentum einer Organisation namens Open Group ist. Das Recht, den Namen UNIX zu verwenden, wird durch eine Art "Läuseprüfung" erreicht - das Bestehen von Tests zur Einhaltung der Spezifikationen eines Referenz-Betriebssystems (Single Unix Standard - was in diesem Fall als Single Standard on Unix übersetzt werden kann). Dieses Verfahren ist nicht nur kompliziert, sondern auch sehr teuer, und daher haben es nur wenige Betriebssysteme der aktuellen durchlaufen, und alle sind proprietär, dh sie sind Eigentum bestimmter Unternehmen.

Unter den Unternehmen, die sich das Recht auf den Namen UNIX dann Entwickler / Tester und das Blut (genauer gesagt der Dollar) der Eigentümer verdient haben, können wir die folgenden nennen:

Sun mit seinem SunOS (weltweit besser bekannt als Solaris);

IBM, das das AIX-System entwickelt hat;

Hewlett-Packard ist Eigentümer des HP-UX-Systems;

IRIX ist das Betriebssystem von SGI.

Darüber hinaus gilt für Systeme der richtige UNIX-Name:

True64 Unix, entwickelt von DEC, das mit der Liquidation an Compaq überging und nun zusammen mit letzterem Eigentum desselben Hewlett-Packard geworden ist;

UnixWare gehört SCO (ein Produkt aus der Fusion von Caldera und Santa Cruz Operation).

Alle diese Systeme sind proprietär und werden für viel Geld verkauft (selbst für amerikanische Verhältnisse). Dies ist jedoch nicht das Haupthindernis für die Verbreitung von UNIX selbst. Denn ihre Gemeinsamkeit ist die Bindung an bestimmte Hardwareplattformen: AIX läuft auf IBM-Servern und -Workstations mit Power-Prozessoren, HP-UX auf der eigenen HP-PA (Precision Architecture) Maschinen , IRIX - auf Grafikstationen von SGI, mit MIPS-Prozessoren, True64 Unix - entwickelt für Alpha-Prozessoren (leider der tote Bose) Nur UnixWare konzentriert sich auf die "demokratische" PC-Plattform, und Solaris existiert in Versionen für zwei Architekturen - seine eigene, Sparc, und immer noch derselbe PC, was allerdings nicht wesentlich zur Verbreitung beitrug - aufgrund der relativ schwachen Unterstützung für die neue PC-Peripherie.

Somit ist UNIX in erster Linie ein Rechtsbegriff. Aber der Begriff Unix hat eine technologische Interpretation. Dies ist der von der IT-Branche verwendete gebräuchliche Name für die gesamte Familie von Betriebssystemen, die entweder von der „ursprünglichen“ UNIX-Firma AT & T abgeleitet sind oder deren Funktionen „von Grund auf neu“ reproduzieren, einschließlich freier Betriebssysteme wie Linux, FreeBSD und anderen BSDs wurde noch nie eine Verifizierung zur Konformität mit dem Single Unix Standard aufgedeckt. Deshalb werden sie oft als Unix-ähnlich bezeichnet.

Weit verbreitet ist auch der eng gefasste Begriff „POSIX-konforme Systeme“, der eine Familie von Betriebssystemen vereint, die dem gleichnamigen Normenwerk entsprechen. Die POSIX-Standards (Portable Operation System Interface based on uniX) selbst wurden auf der Grundlage von Praktiken entwickelt, die in Unix-Systemen übernommen wurden, und daher sind letztere per Definition alle POSIX-kompatibel. Diese sind jedoch nicht vollständig synonym: Kompatibilität mit POSIX-Standards wird von Betriebssystemen beansprucht, die nur indirekt (QNX, Syllable) oder gar nicht (bis Windows NT/2000/XP) mit Unix verwandt sind.

Um die Frage nach dem Verhältnis von UNIX, Unix und POSIX zu klären, müssen wir ein wenig in die Geschichte eintauchen. Tatsächlich wird die Geschichte dieses Problems ausführlich im entsprechenden Kapitel des Buches "Free Unix: Linux, FreeBSD and Others" (demnächst bei BHV-Petersburg) und in Artikeln über die Geschichte von Linux- und BSD-Systemen diskutiert.

Das Betriebssystem Unix (genauer gesagt seine erste Version) wurde 1969-1971 von Mitarbeitern von Bell Labs (einem Geschäftsbereich von AT&T) entwickelt. Seine ersten Autoren - Ken Thompson und Dennis Ritchie - taten dies ausschließlich für ihre eigenen Zwecke, insbesondere um Spaß an ihrem Lieblingsspiel StarTravel haben zu können. Und aus einer Reihe von rechtlichen Gründen konnte das Unternehmen es selbst nicht als kommerzielles Produkt verwenden. Die praktische Anwendung von Unix war jedoch recht schnell gefunden. Zunächst wurde es bei Bell Labs verwendet, um verschiedene Arten von technischen (einschließlich Patent-) Dokumentationen zu erstellen. Und zweitens basierte das Kommunikationssystem UUCP (Unix to Unix Copy Program) auf Unix.

Ein weiterer Bereich, in dem Unix in den 70er und frühen 80er Jahren des letzten Jahrhunderts verwendet wurde, erwies sich als ziemlich ungewöhnlich. In den Quelltexten wurde es nämlich an wissenschaftliche Einrichtungen verteilt, die Arbeiten auf dem Gebiet der Informatik durchführen. Der Zweck einer solchen Verbreitung (sie war im heutigen Sinne nicht völlig frei, stellte sich aber tatsächlich als sehr liberal heraus) war: Bildung und Forschung auf dem oben genannten Wissensgebiet.

Das bekannteste ist das BSD-Unix-System, das an der University of Berkeley, Kalifornien, entwickelt wurde. Das sich nach und nach vom proprietären Code des ursprünglichen Unix befreite und schließlich nach dramatischen Höhen und Tiefen (im Detail hier beschrieben) zu modernen freien BSD-Systemen führte - FreeBSD, NetBSD und andere.

Eines der wichtigsten Ergebnisse der Arbeit von Universitätshackern war (1983) die Einführung der Unterstützung für das TCP/IP-Protokoll in Unix, das auf dem damaligen ARPANET-Netzwerk basierte (und das zur Grundlage des modernen Internets wurde). Dies war eine Voraussetzung für die Dominanz von Unix in allen Bereichen des World Wide Web. Und dies stellte sich als nächste praktische Anwendung dieser Familie von Betriebssystemen heraus - zu diesem Zeitpunkt musste nicht mehr von einem einzigen Unix gesprochen werden. Weil es, wie bereits erwähnt, seine zwei Zweige getrennt hat - den Ursprung des ursprünglichen UNIX (im Laufe der Zeit erhielt es den Namen System V) und das System mit Ursprung in Berkeley. Andererseits bildete System V die Grundlage für die verschiedenen proprietären UNIXs, die tatsächlich das Recht hatten, diesen Namen zu beanspruchen.

Der letzte Umstand – die Verzweigung des einst einzigen Betriebssystems in mehrere Linien, die allmählich an Kompatibilität verlieren – geriet in Konflikt mit einem der Grundpfeiler der Unix-Ideologie: der Portierbarkeit des Systems zwischen verschiedenen Plattformen und seiner Anwendungen von einem Unix-System zu Ein weiterer. Was die Aktivitäten verschiedener Arten von Standardisierungsorganisationen ins Leben rief, die schließlich mit der Schaffung des bereits erwähnten POSIX-Standardsatzes endeten.

Es waren die POSIX-Standards, auf die sich Linus Torvalds stützte, indem er sein Betriebssystem „von Grund auf“ (dh ohne Verwendung von bereits vorhandenem Code) – Linux – erstellte. Und nachdem sie die traditionellen Anwendungsgebiete von Unix-Systemen (Softwareentwicklung, Kommunikation, Internet) schnell und erfolgreich gemeistert hatte, erschloss sie ihnen schließlich ein neues – universelle Desktop-Benutzerplattformen. Das hat es unter den Leuten populär gemacht – eine Popularität, die die aller anderen Unix-Systeme zusammengenommen, sowohl proprietäre als auch freie, übertrifft.

Außerdem werden wir über die Arbeit an Unix-Systemen im weitesten Sinne des Wortes sprechen, ohne jegliche Art von Warenzeichen und anderen rechtlichen Problemen zu berücksichtigen. Obwohl die wichtigsten Beispiele für Arbeitsmethoden aus dem Bereich der freien Implementierungen stammen - Linux, in geringerem Maße FreeBSD und noch weniger - aus anderen BSD-Systemen.

Wo bekommt man kostenloses Unix?

FreeBSD-Datenbank - www.freebsd.org;

Sie können zu www.sco.com gehen

Hauptteil. (Beschreibung von Unix)

1. Grundkonzepte von Unix

Unix basiert auf zwei Grundkonzepten: „Prozess“ und „Datei“. Prozesse sind die dynamische Seite des Systems, sie sind Subjekte; und Dateien - statisch, das sind die Objekte der Prozesse. Fast die gesamte Schnittstelle zwischen Prozessen, die mit dem Kernel und untereinander interagieren, sieht aus wie das Schreiben / Lesen von Dateien. Obwohl Sie Dinge wie Signale, gemeinsamen Speicher und Semaphoren hinzufügen müssen.

Prozesse können grob in zwei Typen unterteilt werden – Tasks und Daemons. Eine Aufgabe ist ein Prozess, der seine Arbeit erledigt und versucht, sie so schnell wie möglich zu beenden und abzuschließen. Der Daemon wartet auf die Ereignisse, die er verarbeiten muss, verarbeitet die aufgetretenen Ereignisse und wartet erneut; es endet normalerweise auf Befehl eines anderen Prozesses, meistens wird es vom Benutzer beendet, indem er den Befehl "kill process_number" gibt. In diesem Sinne stellt sich heraus, dass eine interaktive Aufgabe, die Benutzereingaben verarbeitet, eher einem Daemon als einer Aufgabe ähnelt.

2. Dateisystem

In den alten Unix’s waren dem Namen 14 Buchstaben zugeordnet, in den neuen wurde diese Beschränkung aufgehoben. Neben dem Dateinamen enthält das Verzeichnis seinen Inode-Identifier – eine Ganzzahl, die die Nummer des Blocks festlegt, in dem die Dateiattribute werden erfasst, darunter: Benutzernummer - der Besitzer der Datei Nummerngruppen Anzahl der Verweise auf die Datei (siehe unten) Datum und Uhrzeit der Erstellung, der letzten Änderung und des letzten Zugriffs auf die Datei Zugriffsattribute Zugriffsattribute enthalten die Datei Typ (siehe unten), Rechte zum Ändern von Attributen beim Start (siehe unten) und Zugriffsberechtigungen für den Besitzer, Klassenkameraden und andere zum Lesen, Schreiben und Ausführen. Das Recht zum Löschen einer Datei wird durch das Recht zum Schreiben auf die darüber liegende Datei bestimmt Verzeichnis.

Jede Datei (aber kein Verzeichnis) kann unter mehreren Namen bekannt sein, aber sie müssen sich auf derselben Partition befinden. Alle Links zur Datei sind gleich; die Datei wird gelöscht, wenn der letzte Link zu der Datei entfernt wird. Wenn die Datei geöffnet ist (zum Lesen und/oder Schreiben), erhöht sich die Anzahl der Links zu ihr um eins mehr; so viele Programme, die eine temporäre Datei öffnen, löschen diese sofort, so dass bei einem Absturz, wenn das Betriebssystem die vom Prozess geöffneten Dateien schließt, diese temporäre Datei vom Betriebssystem gelöscht wird.

Es gibt noch ein weiteres interessantes Merkmal des Dateisystems: Wenn nach der Erstellung der Datei nicht hintereinander, sondern in großen Abständen darauf geschrieben wurde, wird für diese Intervalle kein Speicherplatz zugewiesen. Daher kann das Gesamtvolumen der Dateien in einer Partition größer sein als das Volumen der Partition, und wenn eine solche Datei gelöscht wird, wird weniger Speicherplatz freigegeben als ihre Größe.

2.1 Dateitypen

Dateien sind von den folgenden Typen:

regelmäßige Direktzugriffsdatei;

Verzeichnis (Datei mit Namen und Kennungen anderer Dateien);

symbolischer Link (String mit dem Namen einer anderen Datei);

Blockgerät (Platte oder Magnetband);

serielles Gerät (Terminals, serielle und parallele Schnittstellen; Platten und Bänder haben auch eine serielle Geräteschnittstelle)

benannten Kanal.

Spezielle Dateien, die für die Arbeit mit Geräten entwickelt wurden, befinden sich normalerweise im Verzeichnis „/dev“. Hier sind einige davon (in der FreeBSD-Nominierung):

tty* - Terminals, einschließlich: ttyv - virtuelle Konsole;

ttyd - DialIn-Terminal (normalerweise ein serieller Port);

cuaa - DialOut-Leitung

ttyp - Netzwerk-Pseudo-Terminal;

tty – das Terminal, dem die Aufgabe zugeordnet ist;

wd* - Festplatten und ihre Unterabschnitte, einschließlich: wd - Festplatte;

wds - Partition dieser Festplatte (hier "slice" genannt);

wds - Partitionsabschnitt;

fd - Diskette;

rwd*, rfd* - dasselbe wie wd* und fd*, aber mit sequentiellem Zugriff;

Manchmal ist es erforderlich, dass ein von einem Benutzer gestartetes Programm nicht die Rechte des Benutzers hat, der es gestartet hat, sondern eines anderen. In diesem Fall wird das Attribut „Rechte ändern“ auf die Rechte des Benutzers – des Eigentümers des Programms – gesetzt. (Als Beispiel gebe ich ein Programm, das eine Datei mit Fragen und Antworten liest und basierend auf dem, was es gelesen hat, den Schüler testet, der dieses Programm gestartet hat. Das Programm muss das Recht haben, die Datei mit Antworten zu lesen, aber der Schüler wer es gestartet hat, sollte es nicht.) Zum Beispiel funktioniert das Programm passwd, mit dem der Benutzer sein Passwort ändern kann. Der Benutzer kann das passwd-Programm ausführen, es kann Änderungen an der Systemdatenbank vornehmen - aber der Benutzer kann es nicht.

Im Gegensatz zu DOS, wo der vollständige Dateiname „Laufwerk:Pfadname“ lautet, und RISC-OS, das „-Dateisystem-Laufwerk:$.Pfad.Name“ lautet (was im Allgemeinen seine Vorteile hat), verwendet Unix eine transparente Notation in der Form „/ Pfad/Name". Die Wurzel wird ab der Partition gemessen, von der der Unix-Kernel geladen wurde. Wenn eine andere Partition verwendet werden muss (und die Boot-Partition normalerweise nur das enthält, was zum Booten benötigt wird), wird der Befehl `mount /dev/partitionfile dir` verwendet. Gleichzeitig werden Dateien und Unterverzeichnisse, die zuvor in diesem Verzeichnis waren, unzugänglich, bis die Partition ausgehängt wird (natürlich verwenden alle normalen Leute leere Verzeichnisse, um Partitionen einzuhängen). Nur der Vorgesetzte hat das Recht auf Auf- und Absteigen.

Beim Start kann jeder Prozess davon ausgehen, dass drei Dateien für ihn geöffnet sind, die er als Standardeingabe stdin bei Deskriptor 0 kennt; Standardausgabe stdout auf Deskriptor 1; und Standardausgabe stderr auf Deskriptor 2. Wenn der Benutzer angemeldet ist, einen Benutzernamen und ein Passwort eingibt und die Shell gestartet wird, werden alle drei an /dev/tty geleitet; Später kann jeder von ihnen in eine beliebige Datei umgeleitet werden.

3. Befehlsinterpreter

Unix kommt fast immer mit zwei Shells, sh (Shell) und csh (eine C-ähnliche Shell). Darüber hinaus gibt es noch bash (Bourne), ksh (Korn) und andere. Ohne auf Details einzugehen, hier die allgemeinen Grundsätze:

Alle Befehle außer dem Ändern des aktuellen Verzeichnisses, dem Setzen von Umgebungsvariablen (environment) und strukturierten Programmieranweisungen sind externe Programme. Diese Programme befinden sich normalerweise in den Verzeichnissen /bin und /usr/bin. Systemverwaltungsprogramme - in den Verzeichnissen /sbin und /usr/sbin.

Der Befehl besteht aus dem Namen des zu startenden Programms und Argumenten. Argumente werden vom Befehlsnamen und voneinander durch Leerzeichen und Tabulatoren getrennt. Einige Sonderzeichen interpretiert die Shell selbst. Die Sonderzeichen sind " " ` ! $ ^ * ? | & ; (was sonst?).

Sie können mehrere Befehle in derselben Befehlszeile eingeben. Teams können aufgeteilt werden; (sequentielle Befehlsausführung), & (asynchrone gleichzeitige Befehlsausführung), | (synchrone Ausführung, die stdout des ersten Befehls wird der stdin des zweiten zugeführt).

Sie können auch die Standardeingabe aus einer Datei nehmen, indem Sie "file" (die Datei wird auf Null gesetzt) ​​oder ">>file" (der Eintrag wird an das Ende der Datei geschrieben) als eines der Argumente angeben.

Wenn Sie Informationen zu einem Befehl benötigen, geben Sie den Befehl "man command_name" aus. Dies wird durch das "more"-Programm auf dem Bildschirm angezeigt - sehen Sie, wie Sie es auf Ihrem Unix mit dem Befehl "man more" verwalten.

4. UNIX-Kernel

Wie jedes andere Mehrbenutzer-Betriebssystem, das Benutzer voreinander und Systemdaten vor nicht privilegierten Benutzern schützt, verfügt UNIX über einen sicheren Kernel, der Computerressourcen verwaltet und Benutzern einen grundlegenden Satz von Diensten bereitstellt.

Der Komfort und die Effizienz moderner Versionen des UNIX-Betriebssystems bedeutet nicht, dass das gesamte System einschließlich des Kernels optimal gestaltet und strukturiert ist. Das UNIX-Betriebssystem hat sich im Laufe der Jahre weiterentwickelt (es ist das erste Betriebssystem in der Geschichte, das in einem so reifen Alter immer beliebter wird – seit mehr als 25 Jahren). Natürlich wuchsen die Fähigkeiten des Systems, und wie es bei großen Systemen oft vorkommt, hielten die qualitativen Verbesserungen in der Struktur des UNIX-Betriebssystems nicht mit dem Wachstum seiner Fähigkeiten Schritt.

Folglich ist der Kern der meisten modernen kommerziellen Versionen des UNIX-Betriebssystems ein großer, nicht sehr gut strukturierter Monolith. Aus diesem Grund bleibt das Programmieren auf UNIX-Kernel-Ebene eine Kunst (abgesehen von der gut etablierten und verständlichen Technologie zum Entwickeln externer Gerätetreiber). Dieser Mangel an Herstellbarkeit in der Organisation des UNIX-Kernels stellt viele nicht zufrieden. Daher der Wunsch nach einer vollständigen Reproduktion der UNIX-Betriebssystemumgebung mit einer vollständig anderen Organisation des Systems.

Aufgrund der größten Verbreitung wird der UNIX System V-Kernel oft diskutiert (er kann als traditionell angesehen werden).

4.1 Allgemeine Organisation des traditionellen UNIX-Kernels

Eine der Haupterrungenschaften des UNIX-Betriebssystems ist, dass das System die Eigenschaft hoher Mobilität besitzt. Der Sinn dieser Eigenschaft liegt darin, dass sich das gesamte Betriebssystem samt Kernel relativ einfach auf unterschiedliche Hardware-Plattformen übertragen lässt. Alle Teile des Systems, mit Ausnahme des Kernels, sind vollständig maschinenunabhängig. Diese Komponenten sind ordentlich in C geschrieben, und ihre Portierung auf eine neue Plattform (zumindest auf der 32-Bit-Computerklasse) erfordert nur eine Neukompilierung. Quellcode zu den Zielcomputercodes.

Die größten Probleme sind natürlich mit dem Systemkern verbunden, der die Besonderheiten des verwendeten Computers vollständig verbirgt, aber selbst von diesen Besonderheiten abhängt. Durch eine durchdachte Trennung von maschinenabhängigen und maschinenunabhängigen Kernelkomponenten (aus Sicht der Betriebssystementwickler offenbar die höchste Errungenschaft der Entwickler des traditionellen UNIX OS-Kernels) war dies möglich erreichen, dass der Hauptteil des Kernels nicht von den Architekturmerkmalen der Zielplattform abhängt, vollständig in C geschrieben ist und nur neu kompiliert werden muss, um auf eine neue Plattform portiert zu werden.

Ein relativ kleiner Teil des Kernels ist jedoch maschinenabhängig und in einer Mischung aus C und der Assemblersprache des Zielprozessors geschrieben. Beim Übertragen des Systems auf eine neue Plattform muss dieser Teil des Kernels in Assemblersprache und unter Berücksichtigung der Besonderheiten der Zielhardware neu geschrieben werden. Die maschinenabhängigen Teile des Kernels sind gut vom maschinenunabhängigen Hauptteil isoliert, und mit einem guten Verständnis des Zwecks jeder maschinenabhängigen Komponente ist das Umschreiben des maschinenspezifischen Teils meistens eine technische Aufgabe (obwohl es hohe Anforderungen an die Programmierkenntnisse).

Der maschinenspezifische Teil des traditionellen UNIX-Kernels umfasst die folgenden Komponenten:

Förderung und Initialisierung des Systems auf niedriger Ebene (bisher hängt es von den Eigenschaften der Hardware ab);

primäre Verarbeitung interner und externer Interrupts;

Speicherverwaltung (in dem Teil, der sich auf die Funktionen der Hardwareunterstützung für virtuellen Speicher bezieht);

Prozesskontextumschaltung zwischen Benutzer- und Kernelmodus;

Zielplattformspezifische Teile von Gerätetreibern.

4.2 Hauptfunktionen des Kernels

Zu den Hauptfunktionen des UNIX OS-Kernels gehören:

(a) Systeminitialisierung – Start-up- und Spin-up-Funktion. Der Kernel stellt ein Bootstrap-Tool bereit, das den vollständigen Kernel in den Arbeitsspeicher des Computers lädt und den Kernel startet.

(b) Prozess- und Thread-Verwaltung – die Funktion zum Erstellen, Beenden und Verfolgen bestehender Prozesse und Threads („Prozesse“, die auf gemeinsam genutztem virtuellem Speicher laufen). Da UNIX ein Mehrprozess-Betriebssystem ist, sorgt der Kernel für die gemeinsame Nutzung von Prozessorzeit (oder Prozessoren in Mehrprozessorsystemen) und anderen Computerressourcen zwischen laufenden Prozessen, um den Anschein zu erwecken, dass die Prozesse tatsächlich parallel laufen.

(c) Speicherverwaltung ist die Funktion, den praktisch unbegrenzten virtuellen Speicher von Prozessen in den physikalischen RAM des Computers abzubilden, der in seiner Größe begrenzt ist. Die entsprechende Kernel-Komponente ermöglicht die gemeinsame Nutzung derselben RAM-Bereiche durch mehrere Prozesse unter Verwendung von externem Speicher.

(d) Dateiverwaltung – eine Funktion, die die Abstraktion des Dateisystems implementiert – Hierarchien von Verzeichnissen und Dateien. UNIX-Dateisysteme unterstützen mehrere Dateitypen. Einige Dateien können ASCII-Daten enthalten, andere entsprechen externen Geräten. Das Dateisystem speichert Objektdateien, ausführbare Dateien usw. Dateien werden normalerweise auf externen Speichergeräten gespeichert; Der Zugriff darauf erfolgt über den Kernel. In der UNIX-Welt gibt es mehrere Arten der Dateisystemorganisation. Moderne Versionen des UNIX-Betriebssystems unterstützen gleichzeitig die meisten Arten von Dateisystemen.

(e) Kommunikationsmittel – eine Funktion, die die Möglichkeit bietet, Daten zwischen Prozessen auszutauschen, die innerhalb desselben Computers laufen (IPC – Inter-Process Communications), zwischen Prozessen, die in verschiedenen Knoten eines lokalen oder breiten Datennetzwerks laufen, sowie zwischen Prozessen und externe Gerätetreiber .

(f) Programmierschnittstelle – eine Funktion, die Zugriff auf die Fähigkeiten des Kernels von der Seite von Benutzerprozessen basierend auf dem Mechanismus von Systemaufrufen bereitstellt, angeordnet in Form einer Bibliothek von Funktionen.

4.3 Prinzipien der Interaktion mit dem Kern

In jedem Betriebssystem wird ein Mechanismus unterstützt, der es Benutzerprogrammen ermöglicht, auf die Dienste des Betriebssystemkerns zuzugreifen. In den Betriebssystemen des berühmtesten sowjetischen Computers BESM-6 wurden die entsprechenden Kommunikationsmittel mit dem Kernel als Extracodes bezeichnet, in den IBM-Betriebssystemen als Systemmakros und so weiter. Unter UNIX werden diese Funktionen als Systemaufrufe bezeichnet.

Der Name ändert nichts an der Bedeutung, das heißt, um auf die Funktionen des Betriebssystemkerns zuzugreifen, werden "spezielle Befehle" des Prozessors verwendet, bei deren Ausführung eine spezielle Art von internem Prozessor-Interrupt auftritt, der ihn in den Kernelmodus (in Bei den meisten modernen Betriebssystemen wird diese Art von Interrupt Trap - Trap genannt). Bei der Verarbeitung solcher Interrupts (Entschlüsselung) erkennt der OS-Kernel, dass der Interrupt tatsächlich eine Aufforderung des Benutzerprogramms an den Kernel ist, bestimmte Aktionen auszuführen, wählt die Parameter des Aufrufs aus und verarbeitet ihn und führt dann eine "Rückkehr vom Interrupt" durch ", wodurch die normale Ausführung des Benutzerprogramms fortgesetzt wird .

Es ist klar, dass sich die spezifischen Mechanismen zum Auslösen interner Interrupts, die durch das Benutzerprogramm initiiert werden, in verschiedenen Hardwarearchitekturen unterscheiden. Da das UNIX-Betriebssystem bestrebt ist, eine Umgebung bereitzustellen, in der Benutzerprogramme vollständig mobil sein können, war eine zusätzliche Schicht erforderlich, um die Besonderheiten des spezifischen Mechanismus zum Auslösen interner Interrupts zu verbergen. Dieser Mechanismus wird von der sogenannten System Call Library bereitgestellt.

Für den Benutzer ist die Systemaufrufbibliothek eine reguläre Bibliothek vorimplementierter Funktionen des C-Programmiersystems. Beim Programmieren in der Sprache C unterscheidet sich die Verwendung einer beliebigen Funktion aus der Systemaufrufbibliothek nicht von der Verwendung einer nativen oder Bibliotheks-C-Funktion. Innerhalb jeder Funktion eines bestimmten Systemaufrufs enthält die Bibliothek jedoch Code, der im Allgemeinen für eine bestimmte Hardwareplattform spezifisch ist.

4.4 Prinzipien der Unterbrechungsbehandlung

Natürlich hängt der in Betriebssystemen verwendete Mechanismus zum Handhaben interner und externer Interrupts hauptsächlich davon ab, welche Art von Hardwareunterstützung für das Interrupthandling von einer bestimmten Hardwareplattform bereitgestellt wird. Glücklicherweise haben sich inzwischen (und schon seit geraumer Zeit) die großen Computerhersteller de facto auf die grundlegenden Interrupt-Mechanismen geeinigt.

Um nicht sehr genau und spezifisch zu sprechen, besteht das Wesen des heute angenommenen Mechanismus darin, dass jeder mögliche Interrupt des Prozessors (ob es sich um einen internen oder externen Interrupt handelt) einer festen Adresse des physischen RAM entspricht. In dem Moment, in dem der Prozessor aufgrund einer internen oder externen Interrupt-Anforderung unterbrechen darf, erfolgt eine Hardware-Übergabe der Steuerung an die physikalische RAM-Zelle mit der entsprechenden Adresse - normalerweise wird die Adresse dieser Zelle als "Interrupt" bezeichnet Vektor" (normalerweise Anforderungen für internen Interrupt, d. h. Anforderungen, die direkt vom Prozessor kommen, werden sofort erfüllt).

Die Aufgabe des Betriebssystems besteht darin, in den entsprechenden Zellen des RAM den Programmcode zu platzieren, der die anfängliche Verarbeitung des Interrupts bereitstellt und die vollständige Verarbeitung einleitet.

Grundsätzlich verfolgt das UNIX-Betriebssystem einen allgemeinen Ansatz. In dem dem externen Interrupt entsprechenden Interrupt-Vektor, d. h. Interrupt von einem externen Gerät, enthält Befehle, die den Runlevel des Prozessors festlegen (der Runlevel bestimmt, auf welche externen Interrupts der Prozessor sofort reagieren soll) und zum vollständigen Interrupt-Handler im entsprechenden Gerätetreiber springen. Für einen internen Interrupt (z. B. einen vom Benutzerprogramm ausgelösten Interrupt, wenn die erforderliche Seite des virtuellen Speichers im Hauptspeicher fehlt, wenn im Benutzerprogramm eine Ausnahme auftritt usw.) oder einen Timer-Interrupt enthält der Interrupt-Vektor ein Sprung zum entsprechenden UNIX-Kernelprogramm.

5. E/A-Steuerung

Traditionell unterscheidet UNIX OS drei Arten von E/A-Organisation und dementsprechend drei Arten von Treibern. Block-I/O ist hauptsächlich für die Arbeit mit Verzeichnissen und regulären Dateien des Dateisystems gedacht, die im Grunde eine Blockstruktur haben. Auf Benutzerebene ist es nun möglich, mit Dateien zu arbeiten, indem sie direkt virtuellen Speichersegmenten zugeordnet werden. Diese Funktion wird als oberste Ebene der Block-I/O betrachtet. Auf der unteren Ebene wird Block-I/O durch Blocktreiber unterstützt. Block-I/O wird auch durch Systempufferung unterstützt.

Die Zeicheneingabe/-ausgabe wird für den direkten (ohne Pufferung) Austausch zwischen dem Adressraum des Benutzers und dem entsprechenden Gerät verwendet. Kernel-Unterstützung, die allen Zeichentreibern gemeinsam ist, besteht darin, Funktionen zum Übertragen von Daten zwischen Benutzer- und Kernel-Adressräumen bereitzustellen.

Schließlich ist Stream-I/O ähnlich wie Zeichen-I/O, aber aufgrund der Möglichkeit, Zwischenverarbeitungsmodule in den Stream aufzunehmen, hat es viel mehr Flexibilität.

5.1 Prinzipien der System-E/A-Pufferung

Die herkömmliche Methode zur Verringerung des Overheads beim Austausch mit externen Speichergeräten mit Blockstruktur ist die Block-I/O-Pufferung. Dies bedeutet, dass jeder Block eines externen Speichergeräts zuerst in einen Puffer des Hauptspeicherbereichs, der in UNIX OS als Systemcache bezeichnet wird, gelesen und von dort ganz oder teilweise (je nach Art des Austauschs) dorthin kopiert wird den entsprechenden Benutzerbereich.

Die Prinzipien der Organisation des traditionellen Puffermechanismus bestehen erstens darin, dass eine Kopie des Inhalts des Blocks im Systempuffer gehalten wird, bis es aufgrund fehlender Puffer notwendig wird, ihn zu ersetzen (eine Variation des LRU-Algorithmus wird verwendet, um Organisation der Ersatzpolitik). Zweitens wird beim Schreiben eines beliebigen Blocks einer externen Speichervorrichtung tatsächlich nur eine Aktualisierung (oder Bildung und Füllung) des Cache-Puffers durchgeführt. Der eigentliche Austausch mit dem Gerät erfolgt entweder durch Öffnen des Puffers aufgrund des Ersetzens seines Inhalts oder durch Ausgabe eines speziellen sync- (oder fsync-) Systemaufrufs, der speziell unterstützt wird, um aktualisierte Cache-Puffer zwangsweise in den externen Speicher zu verschieben.

Dieses traditionelle Pufferungsschema geriet in Konflikt mit den Verwaltungstools für virtuellen Speicher, die in modernen Versionen des UNIX-Betriebssystems entwickelt wurden, und insbesondere mit dem Mechanismus zum Zuordnen von Dateien zu virtuellen Speichersegmenten. Daher wurde mit System V Release 4 ein neues Pufferungsschema eingeführt, das derzeit parallel zum alten Schema verwendet wird.

Die Essenz des neuen Schemas besteht darin, dass auf der Kernel-Ebene der Mechanismus zum Zuordnen von Dateien zu virtuellen Speichersegmenten tatsächlich reproduziert wird. Denken Sie zunächst daran, dass der UNIX-Kernel tatsächlich in seinem eigenen virtuellen Speicher läuft. Dieser Speicher hat eine komplexere, aber grundsätzlich die gleiche Struktur wie der virtuelle Speicher des Benutzers. Mit anderen Worten, der virtuelle Speicher des Kernels ist eine Segmentseite und wird zusammen mit dem virtuellen Speicher von Benutzerprozessen von einem gemeinsamen Subsystem zur Verwaltung des virtuellen Speichers unterstützt. Daraus folgt zweitens, dass praktisch jede Funktion, die Benutzern vom Kernel bereitgestellt wird, von einigen Komponenten des Kernels anderen Komponenten des Kernels bereitgestellt werden kann. Dies gilt insbesondere auch für die Möglichkeit, Dateien virtuellen Speichersegmenten zuzuordnen.

Das neue Pufferungsschema im UNIX-Kernel basiert hauptsächlich auf der Tatsache, dass Sie fast nichts Besonderes tun können, um die Pufferung zu organisieren. Wenn einer der Benutzerprozesse eine Datei öffnet, die bis dahin noch nicht geöffnet wurde, bildet der Kernel ein neues Segment und verbindet die geöffnete Datei mit diesem Segment. Danach (unabhängig davon, ob der Benutzerprozess mit der Datei im traditionellen Modus mit den Systemaufrufen Lesen und Schreiben arbeitet oder die Datei mit ihrem virtuellen Speichersegment verbindet) wird auf Kernelebene mit dem Kernelsegment gearbeitet an die die Datei auf der Ebene Kernel angehängt ist. Die Hauptidee des neuen Ansatzes besteht darin, dass die Lücke zwischen virtueller Speicherverwaltung und systemweiter Pufferung beseitigt wird (dies hätte schon vor langer Zeit geschehen sollen, da es offensichtlich ist, dass die Hauptpufferung im Betriebssystem von der ausgeführt werden sollte virtuelle Speicherverwaltungskomponente).

Warum nicht den alten Puffermechanismus aufgeben? Die Sache ist die, dass das neue Schema das Vorhandensein einer kontinuierlichen Adressierung innerhalb des externen Speicherobjekts annimmt (es muss ein Isomorphismus zwischen den abgebildeten und den abgebildeten Objekten bestehen). Beim Organisieren von Dateisystemen ist es für das UNIX-Betriebssystem jedoch ziemlich schwierig, externen Speicher zuzuweisen, was insbesondere für I-Nodes gilt. Daher müssen einige Blöcke des externen Speichers als isoliert betrachtet werden, und für sie erweist es sich als vorteilhafter, das alte Pufferungsschema zu verwenden (obwohl zukünftige UNIX-Versionen möglicherweise vollständig auf ein einheitliches neues Schema umsteigen können).

5. 2 Systemaufrufe für E/A-Steuerung

Um auf jede Art von Datei (einschließlich spezieller Dateien) zuzugreifen (d. h. nachfolgende E/A-Operationen ausführen zu können), muss ein Benutzerprozess zuerst eine Verbindung zu der Datei herstellen, indem er eines der Systeme open, creat, dup oder pipe verwendet Anrufe.

Die Abfolge der Aktionen des Systemaufrufs open (Pfadname, Modus) ist wie folgt:

die Konsistenz der Eingabeparameter (hauptsächlich bezogen auf die Flags des Dateizugriffsmodus) wird analysiert;

Platz für einen Dateideskriptor im Systemprozessdatenbereich (u-Bereich) zuweisen oder lokalisieren;

im systemweiten Bereich wird vorhandener Platz zugewiesen oder lokalisiert, um den Systemdateideskriptor (Dateistruktur) aufzunehmen;

das Dateisystemarchiv wird nach einem Objekt mit dem Namen "Pfadname" durchsucht und ein Dateideskriptor auf Dateisystemebene (vnode in UNIX V System 4-Begriffen) wird erzeugt oder gefunden;

der vnode wird an die zuvor gebildete Dateistruktur gebunden.

Die Systemaufrufe open und creat sind (fast) funktional gleichwertig. Jede vorhandene Datei kann mit dem Systemaufruf creat geöffnet werden, und jede neue Datei kann mit dem Systemaufruf open erstellt werden. In Bezug auf den Systemaufruf creat ist jedoch wichtig zu betonen, dass dieser Systemaufruf in seiner natürlichen Verwendung (zum Erstellen einer Datei) einen neuen Eintrag im entsprechenden Verzeichnis (gemäß dem angegebenen Pfadnamen) erstellt und auch erstellt und initialisiert in geeigneter Weise einen neuen i-Knoten.

Schließlich führt der Systemaufruf dup (duplicate - copy) zur Bildung eines neuen Deskriptors für eine bereits geöffnete Datei. Dieser UNIX-spezifische Systemaufruf dient ausschließlich dem Zweck der E/A-Umleitung.) Seine Ausführung besteht darin, einen neuen offenen Dateideskriptor in der u-Region des Systemraums des Benutzerprozesses zu erzeugen, der den neu gebildeten Dateideskriptor (Ganzzahl) enthält, sich aber auf die bereits vorhandene systemweite Dateistruktur bezieht und dieselben übereinstimmenden Zeichen und Flags enthält Beispieldatei öffnen.

Andere wichtige Systemaufrufe sind die Lese- und Schreibsystemaufrufe. Der Lese-Systemaufruf wird wie folgt ausgeführt:

der Deskriptor der spezifizierten Datei befindet sich in der systemweiten Dateitabelle, und es wird bestimmt, ob der Zugriff von dem gegebenen Prozess auf die gegebene Datei in dem spezifizierten Modus legal ist;

für einige (kurze) Zeit wird eine Synchronisationssperre auf dem vnode dieser Datei gesetzt (der Inhalt des Deskriptors sollte sich in kritischen Momenten der Leseoperation nicht ändern);

das tatsächliche Lesen wird unter Verwendung des alten oder neuen Puffermechanismus durchgeführt, wonach die Daten kopiert werden, um im Adressraum des Benutzers verfügbar zu werden.

Der Schreibvorgang funktioniert auf die gleiche Weise, ändert jedoch den Inhalt des Bufferpool-Puffers.

Der Close-Systemaufruf veranlasst den Treiber, die Verbindung mit dem entsprechenden Benutzerprozess zu beenden, und setzt (im Falle des letzten Device-Close) das systemweite "Treiber frei"-Flag.

Schließlich wird ein weiterer „spezieller“ ioctl-Systemaufruf für spezielle Dateien unterstützt. Dies ist der einzige Systemaufruf, der für spezielle Dateien bereitgestellt wird und nicht für andere Arten von Dateien. Tatsächlich erlaubt Ihnen der ioctl-Systemaufruf, die Schnittstelle jedes Treibers beliebig zu erweitern. Die ioctl-Parameter enthalten einen Opcode und einen Zeiger auf einen Bereich des Benutzerprozessspeichers. Die gesamte Interpretation des Opcodes und der zugehörigen spezifischen Parameter wird vom Treiber gehandhabt.

Da Treiber in erster Linie dazu bestimmt sind, externe Geräte zu steuern, muss der Treibercode natürlich die geeigneten Mittel zum Handhaben von Interrupts von dem Gerät enthalten. Der Aufruf der einzelnen Interrupt-Handler im Treiber kommt vom Betriebssystem-Kernel. In ähnlicher Weise kann ein Treiber einen "Timeout"-Eingang deklarieren, auf den der Kernel zugreift, wenn die zuvor vom Treiber bestellte Zeit abgelaufen ist (eine solche Zeitsteuerung ist erforderlich, wenn weniger intelligente Geräte verwaltet werden).

Das allgemeine Schema der Schnittstellenorganisation von Treibern ist in Abbildung 3.5 dargestellt. Wie diese Abbildung zeigt, gibt es in Bezug auf Schnittstellen und systemweite Verwaltung zwei Arten von Treibern – Zeichen und Blöcke. Aus Sicht der internen Organisation sticht eine andere Art von Fahrern hervor - Stromfahrer. Stream-Treiber unterscheiden sich jedoch hinsichtlich ihrer externen Schnittstelle nicht von Zeichentreibern.

6. Schnittstellen und Eingabepunkte von Treibern

6.1 Treiber blockieren

Blocktreiber sind darauf ausgelegt, externe Geräte mit einer Blockstruktur (Magnetplatten, Bänder usw.) zu bedienen, und unterscheiden sich von anderen dadurch, dass sie unter Verwendung von Systempufferung entwickelt und ausgeführt werden. Mit anderen Worten, solche Treiber arbeiten immer durch den Systempufferpool. Wie Sie in Abbildung 3.5 sehen können, durchläuft jeder Lese- oder Schreibzugriff auf einen Blocktreiber immer eine Vorverarbeitung, bei der versucht wird, eine Kopie des gewünschten Blocks im Pufferpool zu finden.

Wenn sich keine Kopie des erforderlichen Blocks im Pufferpool befindet oder wenn es aus irgendeinem Grund erforderlich ist, den Inhalt eines aktualisierten Puffers zu ersetzen, ruft der UNIX-Kernel die Strategieprozedur des entsprechenden Blocktreibers auf. Strategy bietet eine Standardschnittstelle zwischen dem Kernel und dem Treiber. Durch die Verwendung von Bibliotheksunterprogrammen, die zum Schreiben von Treibern bestimmt sind, kann die Strategieprozedur Warteschlangen für den Austausch mit dem Gerät organisieren, um beispielsweise die Bewegung von Magnetköpfen auf der Platte zu optimieren. Alle vom Blocktreiber durchgeführten Austauschvorgänge werden mit Pufferspeicher durchgeführt. Das Umschreiben der notwendigen Informationen in den Speicher des entsprechenden Benutzerprozesses übernehmen Kernel-Programme, die Puffer verwalten

6.2 Zeichentreiber

Zeichentreiber sind in erster Linie dafür ausgelegt, Geräte zu bedienen, die Zeichen für Zeichen oder Zeichenketten mit variabler Länge kommunizieren. Ein typisches Beispiel für ein Zeichengerät ist ein einfacher Drucker, der ein Zeichen pro Austausch akzeptiert.

Zeichentreiber verwenden keine Systempufferung. Sie kopieren Daten direkt aus dem Benutzerprozessspeicher, wenn sie Schreiboperationen ausführen, oder in den Benutzerprozessspeicher, wenn sie Leseoperationen ausführen, indem sie ihre eigenen Puffer verwenden.

Es sollte beachtet werden, dass es möglich ist, eine Zeichenschnittstelle für ein Blockgerät bereitzustellen. In diesem Fall nutzt der Blocktreiber die zusätzlichen Eigenschaften des Strategieverfahrens, wodurch der Austausch ohne Verwendung von Systempufferung durchgeführt werden kann. Für einen Treiber, der sowohl über Block- als auch über Zeichenschnittstellen verfügt, werden im Dateisystem zwei spezielle Dateien erstellt, block und character. Bei jedem Aufruf erhält der Fahrer Informationen über den verwendeten Modus.

6. 3 Stream-Treiber

Der Hauptzweck des Streams-Mechanismus besteht darin, das Maß an Modularität und Flexibilität von Treibern mit komplexer interner Logik zu erhöhen (dies gilt vor allem für Treiber, die fortgeschrittene Netzwerkprotokolle implementieren). Die Besonderheit solcher Treiber besteht darin, dass der größte Teil des Programmcodes nicht von den Funktionen des Hardwaregeräts abhängt. Außerdem ist es oft vorteilhaft, Teile des Programmcodes auf unterschiedliche Weise zu kombinieren.

All dies führte zur Entstehung einer Streaming-Architektur von Treibern, die eine bidirektionale Pipeline von Verarbeitungsmodulen sind. Am Anfang der Pipeline (dem Benutzerprozess am nächsten) befindet sich der Stream-Header, der als erster vom Benutzer initiierte Aufrufe erhält. Am Ende der Pipeline (dem Gerät am nächsten) befindet sich der normale Gerätetreiber. In der Lücke können sich beliebig viele Verarbeitungsmodule befinden, die jeweils entsprechend der benötigten Streaming-Schnittstelle ausgelegt sind.

7. Befehle und Dienstprogramme

Wenn sie interaktiv in einer UNIX-Betriebssystemumgebung arbeiten, verwenden sie verschiedene Dienstprogramme oder externe Befehle der Shell-Sprache. Viele dieser Dienstprogramme sind so komplexe Programme wie die Shell selbst (und übrigens ist die Shell-Sprache selbst eines der Dienstprogramme, die Sie von der Befehlszeile aus aufrufen können).

7.1 Teamorganisation in UNIX OS

Um einen neuen Befehl zu erstellen, müssen Sie nur die Regeln der C-Programmierung befolgen. Jedes wohlgeformte C-Programm beginnt seine Ausführung mit der main-Funktion. Diese "Semi-System"-Funktion hat eine Standardschnittstelle, die die Grundlage für die Organisation von Befehlen ist, die in der Shell-Umgebung aufgerufen werden können. Externe Befehle werden vom Shell-Interpreter unter Verwendung einer Reihe von Fork-Systemaufrufen und einer der exec-Optionen ausgeführt. Die Parameter des Systemaufrufs exec enthalten eine Reihe von Textzeichenfolgen. Dieser Satz von Textzeichenfolgen wird als Eingabe an die Hauptfunktion des ausgeführten Programms übergeben.

Genauer gesagt nimmt die main-Funktion zwei Parameter entgegen – argc (die Anzahl der zu übergebenden Textstrings) und argv (ein Zeiger auf ein Array von Zeigern auf Textstrings). Ein Programm, das behauptet, es als Shell-Befehl zu verwenden, muss ein wohldefiniertes haben externe Schnittstelle(Parameter werden normalerweise vom Terminal eingegeben) und müssen die Eingabeparameter kontrollieren und korrekt analysieren.

Außerdem sollte ein solches Programm, um dem Shell-Stil zu entsprechen, nicht selbst die Dateien überschreiben, die der Standardeingabe, der Standardausgabe und dem Standardfehler entsprechen. Der Befehl kann dann auf die übliche Weise als E/A umgeleitet und in Pipelines aufgenommen werden.

7.2 E/A-Umleitung und Rohrleitungen

Wie Sie dem letzten Satz des vorherigen Absatzes entnehmen können, müssen Sie beim Programmieren von Anweisungen nichts Besonderes tun, um die E/A-Umleitung und das Pipelining zu aktivieren. Es reicht aus, die drei ursprünglichen Dateideskriptoren einfach unverändert zu lassen und mit diesen Dateien korrekt zu arbeiten, nämlich in eine Datei mit einem Deskriptor stdout auszugeben, Daten aus der stdin-Datei einzugeben und Fehlermeldungen in die stderror-Datei auszugeben.

7. 3 Eingebaute, Bibliotheks- und Benutzerbefehle

Eingebaute Befehle sind Teil des Shell-Programmcodes. Sie laufen als Interpreter-Subroutinen und können nicht ersetzt oder neu definiert werden. Syntax und Semantik eingebauter Befehle sind in der entsprechenden Befehlssprache definiert.

Bibliotheksbefehle sind Teil der Systemsoftware. Dies ist eine Reihe ausführbarer Programme (Dienstprogramme), die mit dem Betriebssystem geliefert werden. Die meisten dieser Programme (wie vi, emacs, grep, find, make usw.) sind in der Praxis äußerst nützlich, aber ihre Diskussion würde den Rahmen dieses Kurses sprengen (es gibt separate dicke Bücher).

Ein Benutzerbefehl ist jedes ausführbare Programm, das gemäß den in festgelegten Anforderungen organisiert ist. Somit kann jeder UNIX-OS-Benutzer das Repertoire an externen Befehlen seiner Befehlssprache unbegrenzt erweitern (z. B. können Sie Ihren eigenen Befehlsinterpreter schreiben).

7.4 Programmieren der Befehlssprache

Als Programmiersprache kann prinzipiell jede der genannten Varianten der Shell-Sprache verwendet werden. Unter den UNIX-Benutzern gibt es viele Leute, die ziemlich ernsthafte Programme auf der Shell schreiben. Für die Programmierung ist es besser, Programmiersprachen (C, C++, Pascal usw.) anstelle von Befehlssprachen zu verwenden.

8. GUI-Tools

Obwohl viele professionelle UNIX-Programmierer heute die traditionellen zeilenbasierten Mittel zur Interaktion mit dem System bevorzugen, hat die weit verbreitete Verwendung von relativ kostengünstigen, hochauflösenden Farbgrafikterminals dazu geführt, dass alle modernen Versionen des UNIX-Betriebssystems grafische Benutzer unterstützen Schnittstellen mit dem System, und den Benutzern werden Tools zur Entwicklung grafischer Schnittstellen mit den von ihnen entwickelten Programmen zur Verfügung gestellt. Aus der Sicht des Endbenutzers sind die in verschiedenen Versionen des UNIX-Betriebssystems und in anderen Systemen (z. B. MS Windows oder Windows NT) unterstützten grafischen Schnittstellenwerkzeuge im Stil ungefähr gleich.

Erstens wird in allen Fällen eine Multi-Window-Betriebsweise mit einem Terminalbildschirm unterstützt. Der Benutzer kann jederzeit ein neues Fenster erstellen und es mit dem gewünschten Programm verknüpfen, das mit diesem Fenster wie mit einem separaten Terminal arbeitet. Fenster können verschoben, in der Größe geändert, vorübergehend geschlossen usw. werden.

Zweitens wird in allen modernen Varianten der grafischen Benutzeroberfläche die Maussteuerung unterstützt. Im Fall von UNIX stellt sich oft heraus, dass die normale Terminaltastatur nur verwendet wird, wenn auf die herkömmliche Leitungsschnittstelle umgeschaltet wird (obwohl in den meisten Fällen mindestens ein Terminalfenster eine der Shell-Familien-Shells ausführt).

Drittens ist eine solche Verbreitung des "Maus"-Arbeitsstils durch die Verwendung von Schnittstellenwerkzeugen möglich, die auf Piktogrammen (Icons) und Menüs basieren. In den meisten Fällen fordert ein Programm, das in einem bestimmten Fenster läuft, den Benutzer auf, eine Funktion auszuwählen, die von ihm ausgeführt werden soll, entweder durch Anzeigen eines Satzes symbolischer Bilder möglicher Funktionen (Icons) in dem Fenster oder durch Anbieten eines mehrstufigen Menüs . Für die weitere Auswahl genügt es in jedem Fall, den Cursor des entsprechenden Fensters mit der Maus zu steuern.

Schließlich sind moderne grafische Schnittstellen „benutzerfreundlich“ und bieten die Möglichkeit, für jede Gelegenheit sofort interaktive Hilfe zu erhalten. (Vielleicht wäre es genauer zu sagen, dass ein guter GUI-Programmierstil tatsächlich solche Hinweise liefert.)

Nach der Aufzählung all dieser allgemeinen Eigenschaften moderner GUI-Werkzeuge stellt sich natürlich die Frage: Wenn es im Bereich der grafischen Schnittstellen eine solche Einheitlichkeit gibt, was ist das Besondere an grafischen Schnittstellen im UNIX-Umfeld? Die Antwort ist einfach genug. Ja, der Endbenutzer beschäftigt sich in jedem heutigen System mit ungefähr dem gleichen Satz von Schnittstellenfunktionen, aber in verschiedenen Systemen werden diese Funktionen auf unterschiedliche Weise erreicht. Wie üblich liegt der Vorteil von UNIX in der Verfügbarkeit standardisierter Technologien, mit denen Sie mobile Anwendungen mit grafischen Oberflächen erstellen können.

8. Schutzprinzipien

Da das Betriebssystem UNIX von Anfang an als Mehrbenutzer-Betriebssystem konzipiert war, war das Problem der Autorisierung des Zugriffs verschiedener Benutzer auf die Dateien des Dateisystems darin immer relevant. Die Zugriffsautorisierung bezieht sich auf Systemaktionen, die einem bestimmten Benutzer den Zugriff auf eine bestimmte Datei erlauben oder verweigern, abhängig von den Zugriffsrechten und Zugriffsbeschränkungen des Benutzers, die für die Datei festgelegt wurden. Das im UNIX-Betriebssystem verwendete Zugriffsberechtigungsschema ist so einfach und bequem und gleichzeitig so leistungsfähig, dass es zum De-facto-Standard moderner Betriebssysteme geworden ist (die nicht vorgeben, Systeme mit mehrstufigem Schutz zu sein).

8.1 Benutzer-IDs und Benutzergruppen

Jeder laufende Prozess in UNIX ist einer echten Benutzer-ID, einer effektiven Benutzer-ID und einer gespeicherten Benutzer-ID zugeordnet. Alle diese Bezeichner werden mit dem Systemaufruf setuid gesetzt, der nur im Superuser-Modus ausgeführt werden kann. In ähnlicher Weise sind jedem Prozess drei Benutzergruppen-IDs zugeordnet – reale Gruppen-ID, effektive Gruppen-ID und gespeicherte Gruppen-ID. Diese Bezeichner werden durch den privilegierten Systemaufruf setgid gesetzt.

Wenn sich ein Benutzer am System anmeldet, prüft das Login-Programm, ob der Benutzer angemeldet ist und das richtige Passwort kennt (sofern eines gesetzt ist), erstellt einen neuen Prozess und startet darin die für diesen Benutzer erforderliche Shell. Aber vorher setzt login die Benutzer- und Gruppen-IDs für den neu erstellten Prozess unter Verwendung der Informationen, die in den Dateien /etc/passwd und /etc/group gespeichert sind. Sobald Benutzer- und Gruppen-IDs einem Prozess zugeordnet sind, gelten Dateizugriffsbeschränkungen für diesen Prozess. Ein Prozess kann nur dann auf eine Datei zugreifen oder sie ausführen (wenn die Datei ein ausführbares Programm enthält), wenn die Zugriffsbeschränkungen der Datei dies zulassen. Die einem Prozess zugeordneten Bezeichner werden an die von ihm erstellten Prozesse weitergegeben, wobei dieselben Einschränkungen gelten. In einigen Fällen kann ein Prozess jedoch seine Berechtigungen mithilfe der Systemaufrufe setuid und setgid ändern, und manchmal kann das System die Berechtigungen eines Prozesses automatisch ändern.

Betrachten Sie zum Beispiel die folgende Situation. Die Datei /etc/passwd kann von niemandem außer dem Superuser geschrieben werden (der Superuser kann in jede Datei schreiben). Diese Datei enthält unter anderem Benutzerpasswörter und jeder Benutzer darf sein Passwort ändern. Verfügbar spezielles Programm/bin/passwd, das Passwörter ändert. Allerdings kann der Benutzer dies auch mit diesem Programm nicht, da die Datei /etc/passwd nicht beschrieben werden darf. Auf einem UNIX-System wird dieses Problem wie folgt gelöst. Eine ausführbare Datei kann spezifizieren, dass, wenn sie ausgeführt wird, Benutzer- und/oder Gruppenkennungen gesetzt werden sollen. Wenn ein Benutzer die Ausführung eines solchen Programms anfordert (unter Verwendung des exec-Systemaufrufs), dann wird die Benutzer-ID für den entsprechenden Prozess auf die ID des Eigentümers der ausführbaren Datei und/oder die Gruppen-ID dieses Eigentümers gesetzt. Insbesondere wenn das Programm /bin/passwd ausgeführt wird, hat der Prozess eine Root-ID und das Programm kann in die Datei /etc/passwd schreiben.

Sowohl für die Benutzer-ID als auch für die Gruppen-ID ist die echte ID die wahre ID, und die effektive ID ist die ID der aktuellen Ausführung. Wenn die aktuelle Benutzer-ID mit dem Superuser übereinstimmt, können diese ID und die Gruppen-ID mit den Systemaufrufen setuid und setgid auf einen beliebigen Wert zurückgesetzt werden. Wenn sich die aktuelle Benutzer-ID von der Superuser-ID unterscheidet, bewirkt die Ausführung der Systemaufrufe setuid und setgid, dass die aktuelle ID durch die wahre ID (Benutzer bzw. Gruppe) ersetzt wird.

8.2 Schützen von Dateien

Wie es in einem Mehrbenutzer-Betriebssystem üblich ist, unterhält UNIX einen einheitlichen Mechanismus zum Steuern des Zugriffs auf Dateien und Dateisystemverzeichnisse. Jeder Prozess kann genau dann auf eine bestimmte Datei zugreifen, wenn die mit der Datei beschriebenen Zugriffsrechte den Möglichkeiten dieses Prozesses entsprechen.

Der Schutz von Dateien vor unbefugtem Zugriff in UNIX basiert auf drei Tatsachen. Erstens wird jedem Prozess, der eine Datei (oder ein Verzeichnis) erstellt, eine eindeutige Benutzerkennung (UID - User Identifier) ​​​​im System zugeordnet, die weiter als Kennung des Eigentümers der neu erstellten Datei interpretiert werden kann. Zweitens ist jedem Prozess, der versucht, auf eine Datei zuzugreifen, ein Paar von Identifikatoren zugeordnet, die aktuellen Benutzer- und Gruppenidentifikatoren. Drittens entspricht jede Datei eindeutig ihrem Deskriptor - i-node.

Jeder im Dateisystem verwendete I-Node entspricht immer eindeutig einer und nur einer Datei. Der I-Knoten enthält ziemlich viele verschiedene Informationen (die meisten davon stehen Benutzern über die Systemaufrufe stat und fstat zur Verfügung), und unter diesen Informationen gibt es einen Teil, der es dem Dateisystem ermöglicht, die Zugriffsrechte eines bestimmten Prozesses auszuwerten zu einer bestimmten Datei im erforderlichen Modus.

Die allgemeinen Schutzprinzipien sind für alle existierenden Varianten des Systems gleich: Die I-Node-Informationen enthalten die UID und GID des aktuellen Besitzers der Datei (unmittelbar nach dem Erstellen der Datei werden die Identifikatoren ihres aktuellen Besitzers auf die gesetzt entsprechende aktuelle Kennung des Erstellerprozesses, kann aber später durch die Systemaufrufe chown und chgrp geändert werden) . Außerdem enthält der i-Knoten der Datei eine Skala, die angibt, was der Benutzer – sein Eigentümer – mit der Datei tun kann, was Benutzer, die derselben Benutzergruppe wie der Eigentümer angehören, mit der Datei tun können und was andere damit tun können die Dateibenutzer. Kleine Details der Implementierung in verschiedenen Versionen des Systems unterscheiden sich.

8.3 Zukünftige Betriebssysteme, die die UNIX-Betriebssystemumgebung unterstützen

Ein Mikrokernel ist der kleinste Kernbestandteil eines Betriebssystems und dient als Basis für modulare und portable Erweiterungen. Es scheint, dass die meisten Betriebssysteme der nächsten Generation über Mikrokerne verfügen werden. Allerdings gibt es viele unterschiedliche Meinungen darüber, wie Betriebssystemdienste in Bezug auf den Mikrokernel organisiert werden sollten: wie man Gerätetreiber so effizient wie möglich gestaltet, aber die Treiberfunktionen so unabhängig wie möglich von der Hardware hält; ob Nicht-Kernel-Operationen im Kernel-Space oder im User-Space durchgeführt werden sollen; ob es sich lohnt, die Programme bestehender Subsysteme (z. B. UNIX) zu behalten oder lieber alles zu verwerfen und von vorne anzufangen.

Das Konzept eines Mikrokernels wurde von Next weit verbreitet, dessen Betriebssystem den Mach-Mikrokernel verwendete. Der kleine, privilegierte Kern dieses Betriebssystems, um den herum Subsysteme im Benutzermodus liefen, sollte theoretisch eine beispiellose Flexibilität und Modularität des Systems bieten. In der Praxis wurde dieser Vorteil jedoch durch das Vorhandensein eines monolithischen Servers, der das Betriebssystem UNIX BSD 4.3 implementiert, das Next zum Verpacken des Mach-Mikrokernels auswählte, etwas zunichte gemacht. Das Vertrauen auf Mach ermöglichte es jedoch, Messaging-Tools und eine Reihe von objektorientierten Servicefunktionen in das System aufzunehmen, auf deren Grundlage es möglich war, eine elegante Endbenutzeroberfläche mit grafischen Tools für die Netzwerkkonfiguration und Systemverwaltung zu erstellen und Softwareentwicklung.

Das nächste Mikrokernel-Betriebssystem war Windows NT von Microsoft, bei dem der Hauptvorteil der Verwendung eines Mikrokernels nicht nur die Modularität, sondern auch die Portabilität war. (Beachten Sie, dass es keinen Konsens darüber gibt, ob NT tatsächlich als Mikrokernel-Betriebssystem betrachtet werden sollte.) NT wurde entwickelt, um auf Ein- und Mehrprozessorsystemen verwendet zu werden Intel-Prozessoren, Mips und Alpha (und die, die danach kommen). Da Programme, die für DOS-, Windows-, OS/2- und Posix-kompatible Systeme geschrieben wurden, auf NT ausgeführt werden mussten, nutzte Microsoft die inhärente Modularität des Mikrokernel-Ansatzes, um ein umfassendes NT-Framework zu erstellen, das kein vorhandenes Betriebssystem nachahmte. Jedes Betriebssystem wird als separates Modul oder Subsystem emuliert.

In jüngerer Zeit wurden Mikrokernel-Betriebssystemarchitekturen von Novell/USL, der Open Software Foundation (OSF), IBM, Apple und anderen angekündigt. Einer der Hauptkonkurrenten von NT bei Mikrokernel-Betriebssystemen ist Mach 3.0, ein an der Carnegie Mellon University entwickeltes System, dessen Kommerzialisierung sowohl IBM als auch OSF übernommen haben. (Next verwendet derzeit Mach 2.5 als Basis für NextStep, schaut sich aber auch Mach 3.0 genau an.) Ein weiterer Konkurrent ist der Mikrokernel Chorus 3.0 von Chorus Systems, der von USL als Basis für neue Implementierungen des UNIX-Betriebssystems ausgewählt wurde. Einige Mikrokernel werden in SpringOS von Sun, dem objektorientierten Nachfolger von Solaris, verwendet (sofern Sun natürlich SpringOS vervollständigt). Es gibt einen offensichtlichen Trend zum Wechsel von monolithischen zu Mikrokernel-Systemen (dieser Prozess ist nicht einfach: IBM trat einen Schritt zurück und gab den Übergang zur Mikrokernel-Technologie auf). Das ist übrigens nichts Neues für QNX Software Systems und Unisys, die seit einigen Jahren erfolgreiche Microkernel-Betriebssysteme veröffentlichen. QNX OS ist auf dem Echtzeitmarkt gefragt, und CTOS von Unisys ist im Bankwesen beliebt. Beide Systeme nutzen erfolgreich die Modularität, die Microkernel-Betriebssystemen innewohnt.

Fazit

Die Hauptunterschiede zwischen Unix und anderen Betriebssystemen

Unix besteht aus einem Kernel mit enthaltenen Treibern und Dienstprogrammen (Programme außerhalb des Kernels). Wenn Sie die Konfiguration ändern müssen (ein Gerät hinzufügen, einen Port oder einen Interrupt ändern), wird der Kernel aus Objektmodulen oder (z. B. in FreeBSD) aus Quellen neu erstellt (neu verknüpft). Dies ist nicht ganz richtig. Einige Parameter können ohne Neuaufbau korrigiert werden. Es gibt auch ladbare Kernelmodule.

Im Gegensatz zu Unix werden in Windows (wenn nicht angegeben ist welches, dann meinen wir 3.11, 95 und NT) und OS/2 beim Laden tatsächlich Treiber unterwegs eingebunden Zusammengebauter Kernel und die Wiederverwendung von gemeinsamem Code sind um eine Größenordnung geringer als Darüber hinaus kann der Unix-Kernel bei unveränderter Systemkonfiguration in das ROM geschrieben und ohne Nachbearbeitung _nicht_gebootet_ im RAM ausgeführt werden (Sie müssen nur den Anfangsteil von das BIOS) Code-Kompaktheit ist besonders wichtig, da der Kernel und die Treiber den physischen Speicher nie verlassen und nicht auf die Festplatte ausgelagert werden.

Unix ist das plattformübergreifendste Betriebssystem. WindowsNT versucht, es zu imitieren, aber bisher war es nicht erfolgreich - nach dem Aufgeben von MIPS und POWER-PC blieb W "NT auf nur zwei Plattformen - dem traditionellen i * 86 und DEC Alpha. Portabilität von Programmen von einer Version von Unix Ein schlampig geschriebenes Programm, das Unterschiede in Unix-Implementierungen nicht berücksichtigt, macht unangemessene Annahmen wie "Integer muss vier Bytes belegen", erfordert möglicherweise eine umfassende Überarbeitung, ist aber immer noch um viele Größenordnungen einfacher als die Portierung von OS/2 zum Beispiel auf NT.

Anwendungen von Unix

Unix wird sowohl als Server als auch als Workstation verwendet. In der Server-Nominierung konkurrieren MS Windows NT, Novell Netware, IBM OS/2 Warp Connect, DEC VMS und Mainframe-Betriebssysteme damit. Jedes System hat seinen eigenen Anwendungsbereich, in dem es besser ist als andere.

WindowsNT ist für Administratoren, die eine benutzerfreundliche Oberfläche gegenüber Ressourceneinsparungen und hoher Leistung bevorzugen.

Netware - für Netzwerke, in denen leistungsstarke Datei- und Druckerdienste benötigt werden und andere Dienste nicht so wichtig sind. Der Hauptnachteil besteht darin, dass es schwierig ist, Anwendungen auf einem Netware-Server auszuführen.

OS / 2 ist gut, wenn Sie einen "leichten" Anwendungsserver benötigen. Es erfordert weniger Ressourcen als NT, ist flexibler in der Verwaltung (obwohl es schwieriger einzurichten sein kann) und Multitasking ist sehr gut. Autorisierung und Unterscheidung von Zugriffsrechten werden nicht auf Betriebssystemebene implementiert, was sich durch die Implementierung auf Anwendungsserverebene mehr als auszahlt. (Allerdings tun andere Betriebssysteme oft dasselbe). Viele FIDOnet- und BBS-Stationen basieren auf OS/2.

VMS ist ein leistungsstarker Anwendungsserver, der dem Unix-Anwendungsserver in nichts nachsteht (und ihm in vielerlei Hinsicht überlegen ist), jedoch nur für die VAX- und Alpha-Plattformen von DEC.

Mainframes - um eine sehr große Anzahl von Benutzern (in der Größenordnung von mehreren Tausend) zu bedienen. Die Arbeit dieser Benutzer ist jedoch normalerweise nicht in Form einer Client-Server-Interaktion, sondern in Form einer Host-Terminal-Interaktion organisiert. Das Endgerät in diesem Paar ist eher kein Client, sondern ein Server (Internet World, N3 für 1996). Die Vorteile von Mainframes liegen in der höheren Sicherheit und Fehlertoleranz, die Nachteile sind der diesen Qualitäten entsprechende Preis.

Unix ist gut für den erfahrenen (oder dazu bereiten) Administrator, weil erfordert Kenntnis der Funktionsprinzipien der darin ablaufenden Prozesse. Echtes Multitasking und die gemeinsame Nutzung von Festplattenspeicher sorgen für eine hohe Zuverlässigkeit des Systems, obwohl die Leistung von Unix bei Datei- und Druckdiensten der von Netware unterlegen ist.

Der Mangel an Flexibilität bei der Gewährung von Benutzerzugriffsrechten auf Dateien im Vergleich zu WindowsNT macht es schwierig, den Gruppenzugriff auf Daten (genauer gesagt auf Dateien) auf_der_Dateisystemebene zu organisieren, was meiner Meinung nach durch eine einfache Implementierung, die weniger Hardware bedeutet, ausgeglichen wird Bedarf. Anwendungen wie SQL-Server lösen jedoch das Problem des Gruppenzugriffs auf Daten selbst, sodass die Möglichkeit, einem bestimmten Benutzer den Zugriff auf eine _Datei_ zu verweigern, die in Unix fehlt, meiner Meinung nach eindeutig überflüssig ist.

Fast alle Protokolle, auf denen das Internet basiert, wurden unter Unix entwickelt, insbesondere der TCP/IP-Protokollstack wurde an der Berkeley University erfunden.

Die Sicherheit von Unix steht bei richtiger Verwaltung (und wenn nicht?) der von Novell oder WindowsNT in nichts nach.

Eine wichtige Eigenschaft von Unix, die es Mainframes näher bringt, ist seine Multiterminalfähigkeit, viele Benutzer können gleichzeitig Programme auf demselben Unix-Rechner ausführen. Wenn Sie keine Grafiken verwenden müssen, können Sie mit billigen Textterminals (spezialisiert oder basierend auf billigen PCs) auskommen, die über langsame Leitungen verbunden sind. Damit konkurriert nur VMS. Grafische X-Terminals können auch verwendet werden, wenn Fenster von Prozessen, die auf verschiedenen Maschinen laufen, auf demselben Bildschirm vorhanden sind.

Bei der Workstation-Nominierung konkurriert Unix mit MS Windows*, IBM OS/2, Macintosh und Acorn RISC-OS.

Windows - für diejenigen, die Kompatibilität über Effizienz stellen; für diejenigen, die bereit sind, viel Speicher, Speicherplatz und Megahertz zu kaufen; für diejenigen, die nicht in die Essenz eintauchen möchten, klicken Sie auf die Schaltflächen im Fenster. Früher oder später müssen Sie zwar noch die Prinzipien des Systems und der Protokolle studieren, aber dann ist es zu spät - die Wahl ist getroffen. Ein wichtiger Vorteil von Windows ist auch die Fähigkeit, eine Menge Software zu stehlen.

OS/2 - für Fans von OS/2. :-) Obwohl OS / 2 einigen Berichten zufolge besser als andere mit Mainframes und IBM-Netzwerken interagiert.

Macintosh - für Grafik-, Verlags- und Musikarbeiten sowie für diejenigen, die eine übersichtliche, schöne Oberfläche lieben und die Details des Systems nicht verstehen wollen (nicht können).

RISC-OS, im ROM geflasht, ermöglicht es Ihnen, keine Zeit mit der Installation des Betriebssystems und der Wiederherstellung nach Ausfällen zu verschwenden. Außerdem gehen fast alle Programme darunter sehr sparsam mit Ressourcen um, müssen also nicht getauscht werden und arbeiten sehr schnell.

Unix funktioniert sowohl auf PCs als auch auf leistungsfähigen Workstations mit RISC-Prozessoren, wirklich leistungsfähige CAD-Systeme und Geoinformationssysteme werden unter Unix geschrieben. Laut einigen Autoren ist die Skalierbarkeit von Unix aufgrund seiner Multiplattform-Natur allen anderen Betriebssystemen um eine Größenordnung überlegen.

Referenzliste

1. Lehrbuch Kuznetsova S.D. „UNIX-Betriebssystem“ 2003;

2. Poljakow A. D. „UNIX 5th Edition auf x86, oder vergessen Sie die Geschichte nicht“;

3. Karpov D.Ju. "UNIX" 2005;

4. Fedorchuk A.V. Unix-Meisterschaft, 2006

5. Materialien der Website http://www.citforum.ru/operating_systems/1-16;

MINISTERIUM FÜR BILDUNG UND WISSENSCHAFT DER RUSSISCHEN FÖDERATION BUNDESAGENTUR FÜR BILDUNG STAATLICHE BILDUNGSEINRICHTUNG FÜR BERUFLICHE HÖHERE BILDUNG