En quoi Linux est-il différent d'UNIX et qu'est-ce qu'un système d'exploitation de type UNIX ? Caractéristiques des systèmes d'exploitation de la famille UNIX.

De plus, chacun d'eux peut effectuer de nombreux processus informatiques différents qui utiliseront les ressources de cet ordinateur particulier.

Le deuxième mérite colossal d'Unix est sa nature multiplateforme. Le cœur du système est conçu de telle manière qu'il peut être facilement adapté à presque tous les microprocesseurs.

Unix a d'autres caractéristiques :

  • utiliser de simples fichiers texte pour configurer et gérer le système ;
  • utilisation généralisée des utilitaires lancés à partir de la ligne de commande;
  • interaction avec l'utilisateur via un appareil virtuel - un terminal ;
  • représentation des dispositifs physiques et virtuels et de certains moyens de communication interprocessus sous forme de fichiers ;
  • l'utilisation de pipelines de plusieurs programmes, chacun effectuant une tâche.

Application

Actuellement, les systèmes Unix sont distribués principalement entre les serveurs, et également en tant que systèmes embarqués pour divers équipements, y compris les smartphones. Les systèmes Unix dominent également les supercalculateurs, en particulier, Linux est installé sur 100% des supercalculateurs TOP500.

Les premières versions d'Unix étaient écrites en langage d'assemblage et n'avaient pas de compilateur de langage de haut niveau intégré. Vers 1969, Ken Thompson, avec l'aide de Dennis Ritchie, développa et implémenta le langage B (B), qui était une version simplifiée (pour une implémentation sur des mini-ordinateurs) du langage BCPL développé dans le langage. Bi, comme BCPL, était un langage interprété. Sorti en 1972 deuxième édition Unix réécrit en B. En 1969-1973 sur la base de Bi, un langage compilé a été développé, appelé C (C).

Diviser

Une raison importante de la scission d'Unix était la mise en œuvre en 1980 de la pile de protocoles TCP/IP. Avant cela, la communication machine à machine sous Unix en était à ses balbutiements - la méthode de communication la plus importante était UUCP (un moyen de copier des fichiers d'un système Unix à un autre, fonctionnant à l'origine sur des réseaux téléphoniques utilisant des modems).

Deux interfaces de programmation pour les applications réseau ont été proposées : les sockets Berkley et l'interface de couche transport TLI (Transport layer interface).

L'interface des sockets Berkley a été développée à l'Université de Berkeley et a utilisé la pile de protocoles TCP/IP développée là-bas. TLI a été créé par AT&T selon la définition de la couche de transport du modèle OSI et est apparu pour la première fois dans la version 3 de System V. Bien que cette version contienne TLI et des flux, elle n'implémentait pas à l'origine TCP/IP ou d'autres protocoles réseau, mais de telles implémentations étaient fournies. par des tiers. .

L'implémentation de TCP/IP a été officiellement et définitivement incluse dans la distribution de base de System V version 4. Ceci, ainsi que d'autres considérations (essentiellement marketing), a causé la démarcation finale entre les deux branches d'Unix - BSD (Université de Berkeley) et System V (version commerciale d'AT&T). Par la suite, de nombreuses entreprises, ayant obtenu une licence System V d'AT&T, ont développé leurs propres versions commerciales d'Unix, telles que AIX, CLIX, HP-UX, IRIX, Solaris.

Les implémentations modernes d'Unix ne sont généralement pas des systèmes V ou BSD purs. Ils implémentent des fonctionnalités de System V et de BSD.

Systèmes d'exploitation gratuits de type Unix

À l'heure actuelle, GNU/Linux et les membres de la famille BSD prennent rapidement le contrôle du marché des systèmes Unix commerciaux et infiltrent simultanément les ordinateurs de bureau des utilisateurs finaux et les systèmes mobiles et embarqués.

Systèmes propriétaires

Depuis la scission d'AT&T, la marque Unix et les droits sur le code source d'origine ont changé plusieurs fois de propriétaires, en particulier, ils ont longtemps appartenu à Novell.

L'influence d'Unix sur l'évolution des systèmes d'exploitation

Les systèmes Unix ont une grande importance historique parce qu'ils ont propagé certains des concepts et approches de systèmes d'exploitation et de logiciels les plus populaires d'aujourd'hui. De plus, lors du développement des systèmes Unix, le langage C a été créé.

Largement utilisé dans la programmation système, le langage C, créé à l'origine pour le développement d'Unix, a dépassé Unix en popularité. Le langage C a été le premier langage "tolérant" qui n'a pas essayé d'imposer un style de programmation au programmeur. C a été le premier langage de haut niveau qui a donné accès à toutes les fonctionnalités du processeur, telles que les références, les tables, les décalages de bits, les incréments, etc. D'autre part, la liberté du langage C a conduit à des erreurs de débordement de tampon dans de tels la bibliothèque C standard fonctionne comme gets et scanf. De nombreuses vulnérabilités infâmes en ont résulté, comme celle exploitée dans le célèbre ver Morris.

Les premiers développeurs d'Unix ont contribué à l'introduction des principes de programmation modulaire et de réutilisation dans la pratique de l'ingénierie.

Unix a permis l'utilisation des protocoles TCP/IP sur des ordinateurs relativement bon marché, ce qui a conduit à la croissance rapide d'Internet. Ceci, à son tour, a contribué à la découverte rapide de plusieurs vulnérabilités majeures dans la sécurité, l'architecture et les utilitaires système d'Unix.

Au fil du temps, les principaux développeurs Unix ont développé des normes culturelles de développement logiciel qui sont devenues aussi importantes qu'Unix lui-même. ( )

Certains des exemples les plus connus de systèmes d'exploitation de type Unix sont macOS, Solaris, BSD et NeXTSTEP.

Rôle social dans la communauté des professionnels de l'informatique et rôle historique

L'Unix d'origine fonctionnait sur de grands ordinateurs multi-utilisateurs, qui offraient également des systèmes d'exploitation propriétaires du fabricant de matériel, tels que RSX-11 et son descendant VMS. Malgré le fait que selon un certain nombre d'opinions [ à qui?] l'Unix d'alors avait des inconvénients par rapport à ces systèmes d'exploitation (par exemple, le manque de moteurs de base de données sérieux), il était : a) moins cher, et parfois gratuit pour les institutions académiques ; b) a été porté de matériel à matériel et développé dans un langage C portable, qui « découplait » le développement logiciel du matériel spécifique. De plus, l'expérience utilisateur s'est avérée «déliée» de l'équipement et du fabricant - une personne qui a travaillé avec Unix sur VAX a facilement travaillé avec sur 68xxx, etc.

Les fabricants de matériel à cette époque étaient souvent cool à propos d'Unix, le considérant comme un jouet et offrant leur système d'exploitation propriétaire pour un travail sérieux - principalement des SGBD et des applications commerciales basées sur eux dans des structures commerciales. Il y a des commentaires connus à ce sujet de DEC concernant son VMS. Les entreprises ont écouté cela, mais pas l'environnement universitaire, qui avait tout pour lui dans Unix, n'avait souvent pas besoin d'un soutien officiel du fabricant, gérait lui-même et appréciait le bon marché et la portabilité d'Unix. Ainsi, Unix a peut-être été le premier système d'exploitation portable sur différents matériels.

La deuxième montée majeure d'Unix a été l'introduction des processeurs RISC vers 1989. Même avant cela, il y avait des soi-disant. Les postes de travail sont des ordinateurs personnels mono-utilisateur à haute puissance dotés de suffisamment de mémoire, de disque dur et d'un système d'exploitation suffisamment avancé (multitâche, protection de la mémoire) pour fonctionner avec des applications sérieuses telles que les CAO. Parmi les fabricants de telles machines, Sun Microsystems s'est démarqué en s'y faisant un nom.

Avant l'avènement des processeurs RISC, ces stations utilisaient généralement le processeur Motorola 680x0, le même que celui des ordinateurs Apple (bien que sous un système d'exploitation plus avancé que celui d'Apple). Vers 1989, des implémentations commerciales de processeurs d'architecture RISC sont apparues sur le marché. La décision logique d'un certain nombre d'entreprises (Sun et autres) a été de porter Unix sur ces architectures, ce qui a immédiatement conduit au portage de l'ensemble de l'écosystème logiciel Unix.

Les systèmes d'exploitation propriétaires sérieux, comme les VMS, commencent leur déclin dès ce moment (même s'il était possible de porter l'OS lui-même en RISC, tout était beaucoup plus compliqué avec les applications pour celui-ci, qui dans ces écosystèmes étaient souvent développées en assembleur ou dans des langages propriétaires ​​​​comme BLISS ), et Unix est devenu le système d'exploitation des ordinateurs les plus puissants du monde.

Cependant, à cette époque, l'écosystème a commencé à évoluer vers l'interface graphique sous la forme de Windows 3.0. Les énormes avantages de l'interface graphique, ainsi que, par exemple, la prise en charge unifiée de tous les types d'imprimantes, ont été appréciés à la fois par les développeurs et les utilisateurs. Cela a considérablement sapé la position d'Unix sur le marché des PC - des implémentations telles que SCO et Interactive UNIX ne pouvaient pas faire face à la prise en charge des applications Windows. Quant à l'interface graphique pour Unix, appelée X11 (il y avait d'autres implémentations, beaucoup moins populaires), elle ne pouvait pas fonctionner complètement sur le PC d'un utilisateur normal en raison des besoins en mémoire - X11 nécessitait 16 Mo pour un fonctionnement normal, tandis que Windows 3.1 avec suffisamment de performances pour exécuter à la fois Word et Excel en même temps en 8 Mo (ce qui était la taille de mémoire PC standard à l'époque). Avec des prix de mémoire élevés, c'était le facteur limitant.

Le succès de Windows a donné une impulsion à un projet interne de Microsoft appelé Windows NT, qui était compatible avec Windows par API, mais avait en même temps toutes les mêmes caractéristiques architecturales d'un système d'exploitation sérieux qu'Unix - multitâche, protection complète de la mémoire, prise en charge du multiprocesseur machines, autorisations de fichiers et répertoires, journal système. Windows NT a également introduit le système de fichiers de journalisation NTFS, qui à l'époque dépassait tous les systèmes de fichiers standard fournis avec Unix en termes de capacités - les analogues Unix n'étaient que des produits commerciaux distincts de Veritas et d'autres.

Bien que Windows NT n'ait pas été populaire au départ, en raison de ses besoins élevés en mémoire (les mêmes 16 Mo), il a permis à Microsoft d'entrer sur le marché des solutions de serveur, telles que le SGBD. Beaucoup à l'époque ne croyaient pas en la capacité de Microsoft, traditionnellement spécialisé dans les logiciels de bureau, à être un acteur du marché des logiciels d'entreprise, qui comptait déjà de grands noms comme Oracle et Sun. Ajoutant à ce doute, le fait que le SGBD de Microsoft - SQL Server - a commencé comme une version simplifiée de Sybase SQL Server, sous licence de Sybase et compatible à 99 % dans tous les aspects de son utilisation.

Dans la seconde moitié des années 1990, Microsoft a également commencé à pousser Unix sur le marché des serveurs d'entreprise.

La combinaison des facteurs ci-dessus, ainsi que l'effondrement des prix des contrôleurs vidéo 3D, qui sont devenus la maison des équipements professionnels, ont essentiellement tué le concept même de station de travail au début des années 2000.

De plus, les systèmes Microsoft sont plus faciles à gérer, en particulier dans les cas d'utilisation typiques.

Mais en ce moment, la troisième forte montée d'Unix a commencé.

De plus, Stallman et ses camarades étaient bien conscients que les outils de développement propriétaires n'étaient pas adaptés au succès des logiciels non commerciaux. Par conséquent, ils ont développé un ensemble de compilateurs pour divers langages de programmation (gcc), qui, avec les utilitaires GNU développés précédemment (remplaçant les utilitaires Unix standard), constituaient un progiciel nécessaire et assez puissant pour le développeur.

FreeBSD était un concurrent sérieux de Linux à cette époque, cependant, le style "cathédrale" de gestion du développement par opposition au style "bazar" de Linux, ainsi qu'un archaïsme beaucoup plus technique dans des domaines tels que la prise en charge des machines multiprocesseurs et des fichiers exécutables formats, ont fortement ralenti le développement de FreeBSD par rapport à Linux, faisant de ce dernier le fleuron du monde du logiciel libre.

Dans le futur, Linux a atteint de plus en plus de sommets :

  • le portage de produits propriétaires sérieux tels qu'Oracle ;
  • l'intérêt sérieux d'IBM pour cet écosystème comme base de ses solutions verticales ;
  • l'apparition d'analogues de presque tous les programmes familiers du monde Windows;
  • le refus de certains fabricants de matériel de la pré-installation obligatoire de Windows ;
  • la sortie des netbooks avec uniquement Linux ;
  • utiliser comme noyau dans Android.

À l'heure actuelle, Linux est un système d'exploitation à juste titre populaire pour les serveurs, bien que beaucoup moins populaire sur les ordinateurs de bureau.

Quelques caractéristiques architecturales du système d'exploitation Unix

Les fonctionnalités Unix qui distinguent cette famille des autres systèmes d'exploitation sont répertoriées ci-dessous.

  • Le système de fichiers est arborescent, sensible à la casse dans les noms, très faibles restrictions sur la longueur des noms et des chemins.
  • Le noyau du système d'exploitation ne prend pas en charge les fichiers structurés ; au niveau des appels système, un fichier est un flux d'octets.
  • La ligne de commande est située dans l'espace d'adressage du processus en cours de lancement et n'est pas récupérée par un appel système du processus d'interpréteur de commandes (comme cela se produit, par exemple, dans RSX-11).
  • Le concept de "variables d'environnement".
  • Démarrage des processus en appelant fork(), c'est-à-dire la possibilité de cloner le processus en cours avec tout l'état.
  • Les concepts de stdin/stdout/stderr.
  • E/S uniquement via des descripteurs de fichiers.
  • Prise en charge traditionnellement très faible des E/S asynchrones par rapport à VMS et Windows NT.
  • L'interpréteur de commandes est une application ordinaire qui communique avec le noyau avec des appels système ordinaires (dans RSX-11 et VMS, l'interpréteur de commandes était exécuté comme une application spéciale, placée en mémoire d'une manière spéciale, à l'aide d'appels système spéciaux, les appels système étaient également pris en charge, permettant à l'application d'accéder aux commandes de son interpréteur parent).
  • Une commande de ligne de commande n'est rien de plus que le nom d'un fichier de programme, aucun enregistrement spécial ni développement spécial de programmes en tant que commandes n'est requis (ce qui était une pratique courante dans RSX-11, RT-11).
  • L'approche avec un programme qui pose à l'utilisateur des questions sur ses modes de fonctionnement n'est pas acceptée, à la place des paramètres de ligne de commande sont utilisés (dans VMS, RSX-11, RT-11, les programmes fonctionnaient également avec la ligne de commande, mais en son absence, ils ont été invités à entrer des paramètres).
  • Un espace de noms de périphérique sur disque dans le répertoire /dev qui peut être géré par un administrateur, contrairement à l'approche Windows, où cet espace de noms est situé dans la mémoire du noyau, et l'administration de cet espace de noms (par exemple, la définition des autorisations) est extrêmement difficile en raison de la manque de stockage permanent sur disques (construit à chaque démarrage).
  • Utilisation intensive de fichiers texte pour stocker les paramètres, par opposition à une base de données de paramètres binaires, comme dans Windows.
  • Utilisation généralisée d'utilitaires de traitement de texte pour effectuer des tâches quotidiennes sous le contrôle de scripts.
  • "Promotion" de l'OS après chargement du noyau en exécutant des scripts avec un interpréteur de commandes standard.
  • Large utilisation

L'histoire d'UNIX® commence en 1969. La plupart des systèmes UNIX modernes sont des versions commerciales des distributions UNIX d'origine. Solaris de Sun, HP-UX de Hewlett-Packard, AIX® d'IBM sont les meilleurs représentants d'UNIX, qui ont aussi leurs propres éléments uniques et leurs propres solutions fondamentales. Par exemple, Sun Solaris est UNIX, mais il contient également de nombreux outils et extensions conçus spécifiquement pour les stations de travail et les serveurs Sun.

Linux® a été développé dans le but de fournir une alternative gratuite aux environnements UNIX commerciaux. Son histoire remonte à 1991, voire 1983, lors de la création du projet GNU, dont le but initial était de fournir une alternative libre à UNIX. Linux fonctionne sur de nombreuses autres plates-formes, telles que Intel®/AMD x86. La plupart des systèmes d'exploitation UNIX ne peuvent fonctionner que sur une plate-forme.

Linux et UNIX ont des racines historiques communes, mais il existe également des différences significatives. De nombreux outils, utilitaires et applications gratuites fournis en standard avec Linux ont été initialement conçus comme des alternatives gratuites aux programmes UNIX. Linux prend souvent en charge de nombreuses options et applications, empruntant les fonctionnalités les meilleures ou les plus populaires à UNIX.

En tant qu'administrateur ou développeur habitué à travailler avec Linux, le système UNIX peut ne pas sembler très convivial. D'autre part, la base d'un système d'exploitation de type UNIX (outils, système de fichiers, API) est assez standardisée. Cependant, certains détails des systèmes peuvent présenter des différences importantes. Ces différences seront discutées plus loin dans l'article.

Différences techniques

Les développeurs de distributions commerciales UNIX s'appuient sur un ensemble spécifique de clients et de plates-formes serveur pour leur système d'exploitation. Ils ont une bonne idée du type de support et d'optimisation des applications à mettre en œuvre. Les fabricants d'UNIX font de leur mieux pour assurer la compatibilité entre les différentes versions. De plus, ils ont publié les normes de leur système d'exploitation.

Le développement GNU/Linux, d'autre part, n'est pas axé sur la plate-forme ou le client, et les développeurs GNU/Linux ont des antécédents et des perspectives différents. Il n'y a pas d'ensemble standard strict d'outils ou d'environnements dans la communauté Linux. Pour résoudre ce problème, le projet Linux Standards Base (LSB) a été lancé, mais il ne s'est pas avéré aussi efficace que nous le souhaiterions.

Ce manque de standardisation conduit à des incohérences importantes au sein de Linux. Pour certains développeurs, la possibilité d'utiliser le meilleur des autres systèmes d'exploitation est un plus, mais copier des éléments UNIX vers Linux n'est pas toujours pratique, par exemple, lorsque les noms de périphériques sous Linux peuvent être extraits d'AIX, alors que les outils de système de fichiers sont HP- Orienté UX. Des incompatibilités de ce type se produisent également entre différentes distributions Linux. Par exemple, Gentoo et RedHat implémentent différentes méthodes de mise à jour.

En comparaison, chaque nouvelle version du système UNIX est accompagnée d'une description bien documentée des nouvelles fonctionnalités et des modifications apportées à UNIX. Les commandes, outils et autres éléments changent rarement, et souvent les mêmes arguments de ligne de commande pour les applications restent les mêmes dans de nombreuses versions de ce logiciel. Lorsque des modifications importantes sont apportées à ces éléments, les fournisseurs de systèmes UNIX commerciaux fournissent souvent l'encapsuleur nécessaire pour assurer la compatibilité avec les versions antérieures de l'outil.

Cette compatibilité signifie que les utilitaires et les applications peuvent être utilisés sur les nouvelles versions des systèmes d'exploitation sans vérifier ou modifier leur code source. Par conséquent, la migration vers une nouvelle version d'UNIX, qui ne diffère généralement pas fondamentalement de l'ancienne version, représente beaucoup moins d'efforts pour les utilisateurs ou les administrateurs que la migration d'une distribution Linux à une autre.

Architecture matérielle

La plupart des versions commerciales d'UNIX sont conçues pour une ou un petit nombre d'architectures matérielles. HP-UX ne fonctionne que sur les plates-formes PA-RISC et Itanium, Solaris sur SPARC et x86, et AIX est réservé aux processeurs POWER.

En raison de ces restrictions, les fournisseurs UNIX sont relativement libres de modifier leur code pour ces architectures et de profiter de tout avantage de leur architecture. Parce qu'ils connaissent si bien les périphériques qu'ils prennent en charge, leurs pilotes fonctionnent mieux et ils n'ont pas à faire face aux limitations du BIOS spécifiques au PC.

Linux, d'autre part, a toujours été conçu pour une compatibilité maximale. Linux est disponible sur une variété d'architectures, et le nombre de périphériques d'E/S et autres périphériques pouvant être utilisés avec le système d'exploitation est presque illimité. Les développeurs ne peuvent pas savoir à l'avance quel matériel spécifique sera installé sur un ordinateur et ne peuvent souvent pas s'assurer qu'il est utilisé efficacement. Un exemple est la gestion de la mémoire sous Linux. Auparavant, Linux utilisait un modèle de mémoire segmentée conçu à l'origine pour x86. Il est maintenant adapté pour utiliser la mémoire paginée, mais conserve toujours certaines exigences de mémoire segmentée, ce qui pose des problèmes si l'architecture ne prend pas en charge la mémoire segmentée. Ce n'est pas un problème pour les fournisseurs UNIX. Ils savent exactement sur quel matériel leur UNIX fonctionnera.

Noyau

Le noyau est le cœur du système d'exploitation. Le code source du noyau des distributions UNIX commerciales est la propriété de leurs développeurs et n'est pas distribué à l'extérieur de l'entreprise. Situation complètement opposée avec Linux. Les procédures de compilation et de mise à jour des noyaux et des pilotes sont assez différentes. Pour Linux et d'autres systèmes d'exploitation open source, un correctif peut être publié sous forme de code source et l'utilisateur final peut l'installer, le tester et même le modifier. Ces correctifs ne sont généralement pas testés avec autant de soin que les correctifs des fournisseurs commerciaux de systèmes d'exploitation UNIX. Parce qu'il n'y a pas de liste complète des applications et des environnements qui doivent être testés pour fonctionner correctement sous Linux, les développeurs Linux dépendent des utilisateurs finaux et d'autres développeurs pour détecter les bogues.

Les fournisseurs commerciaux de distribution UNIX ne publient les noyaux que sous forme de code exécutable. Certaines versions sont monolithiques, tandis que d'autres vous permettent de mettre à jour uniquement un module de noyau particulier. Mais dans tous les cas, cette version n'est fournie que sous la forme d'un code exécutable. Si une mise à jour est nécessaire, l'administrateur doit attendre que le fabricant publie un correctif en binaire, mais peut être rassuré par le fait que le fabricant vérifiera soigneusement la rétrocompatibilité de son correctif.

Toutes les versions commerciales d'UNIX ont évolué dans une certaine mesure vers un noyau modulaire. Les pilotes et les fonctionnalités spécifiques du système d'exploitation sont disponibles en tant que composants distincts et peuvent être chargés ou déchargés du noyau selon les besoins. Mais l'architecture modulaire ouverte de Linux est beaucoup plus flexible. Cependant, la flexibilité et l'adaptabilité de Linux impliquent des changements constants. Le code source de Linux change constamment et, au gré du développeur, l'API peut changer. Lorsqu'un module ou un pilote est écrit pour une version commerciale d'UNIX, il durera beaucoup plus longtemps que le même pilote pour Linux.

Prise en charge du système de fichiers

L'une des raisons pour lesquelles Linux est devenu un système d'exploitation si puissant est sa large compatibilité avec d'autres systèmes d'exploitation. L'une des caractéristiques les plus évidentes est l'abondance de systèmes de fichiers disponibles. La plupart des versions commerciales d'UNIX prennent en charge deux ou trois types de système de fichiers. Linux, cependant, prend en charge la plupart des systèmes de fichiers modernes. montre quels systèmes de fichiers sont pris en charge par UNIX. N'importe lequel de ces systèmes de fichiers peut être monté sur Linux, bien que tous ces systèmes de fichiers ne prennent pas entièrement en charge la lecture et l'écriture de données.

Tableau 1. Systèmes de fichiers standard pour UNIX

La plupart des versions commerciales d'UNIX prennent en charge les systèmes de fichiers journalisés. Par exemple, HP-UX utilise hfs comme système de fichiers standard, mais il prend également en charge le système de fichiers journalisé vxfs. Solaris prend en charge ufs et zfs. Un système de fichiers journalisé est un composant essentiel de tout environnement de serveur d'entreprise. La prise en charge des systèmes de fichiers journalisés a été introduite tardivement dans Linux, mais il existe désormais plusieurs options, des clones de systèmes de fichiers commerciaux (xfs, jfs) aux systèmes de fichiers spécifiques à Linux (ext3, reiserfs).

Les autres fonctionnalités du système de fichiers incluent la prise en charge des quotas, les listes de contrôle d'accès aux fichiers, la mise en miroir, les instantanés du système et le redimensionnement. Ils sont pris en charge sous une forme ou une autre par les systèmes de fichiers Linux. La plupart de ces fonctionnalités ne sont pas standard sous Linux. Certaines fonctionnalités peuvent fonctionner sur un système de fichiers, tandis que d'autres nécessitent un système de fichiers différent. Certaines de ces fonctionnalités ne sont tout simplement pas disponibles sur certains systèmes de fichiers Linux, tandis que d'autres nécessitent l'installation d'outils supplémentaires, tels qu'une version spécifique de LVM ou la prise en charge d'une baie de disques (package raid logiciel). Historiquement, la compatibilité entre les interfaces de programmation et les outils standard a été difficile à réaliser sous Linux, de sorte que de nombreux systèmes de fichiers implémentent ces fonctionnalités de différentes manières.

Étant donné que les systèmes UNIX commerciaux prennent en charge un nombre limité de systèmes de fichiers, leurs outils et techniques pour travailler avec eux sont plus standardisés. Par exemple, comme un seul système de fichiers maître était pris en charge dans Irix, il n'y avait qu'une seule façon de définir des listes de contrôle d'accès. C'est beaucoup plus pratique pour l'utilisateur final et pour une meilleure prise en charge de ce système d'exploitation.

Disponibilité des applications

La plupart des applications de base sont les mêmes sous UNIX et Linux. Par exemple, les commandes cp , ls , vi et cc sont disponibles sous UNIX et Linux et sont très similaires, voire complètement identiques. Les versions Linux de ces outils sont basées sur les versions GNU de ces outils, tandis que les versions UNIX de ces outils sont basées sur les outils UNIX traditionnels. Ces outils UNIX ont une longue histoire et changent rarement.

Mais cela ne signifie pas que les versions commerciales d'UNIX ne peuvent pas être utilisées avec les outils GNU. En fait, de nombreux fournisseurs commerciaux de systèmes d'exploitation UNIX incluent de nombreux outils GNU dans leurs distributions ou les proposent en tant que modules complémentaires gratuits. Les outils GNU ne sont pas seulement des outils standard. Certains de ces utilitaires gratuits n'ont pas d'équivalents commerciaux (emacs ou Perl). La plupart des fabricants préinstallent ces programmes et ils sont soit automatiquement installés avec le système, soit disponibles en option.

Les applications gratuites et open source sont presque toujours intégrées à toutes les distributions Linux. Il existe une grande quantité de logiciels libres disponibles pour Linux, et nombre de ces applications ont été portées sur des versions commerciales du système d'exploitation UNIX.

Applications commerciales et/ou fermées (CAO, programmes financiers, éditeur graphique) peut ne pas avoir d'analogues pour Linux. Bien que certains fournisseurs publient des versions de leurs applications pour Linux, la plupart des fournisseurs tardent à le faire jusqu'à ce que Linux devienne plus populaire auprès des utilisateurs.

D'autre part, les versions commerciales d'UNIX ont historiquement pris en charge un grand nombre d'applications au niveau de l'entreprise, telles qu'Oracle ou SAP. Linux est fortement perdant en raison de la difficulté de certifier de grandes applications, tandis que les versions commerciales d'UNIX ne changent pas beaucoup d'une version à l'autre. Linux peut beaucoup changer, non seulement avec chaque nouvelle distribution, mais parfois entre les versions de la même distribution. Il est donc très difficile pour un éditeur de logiciel de comprendre exactement dans quel environnement son application sera utilisée.

L'administration du système

Bien que certaines distributions Linux soient livrées avec un ensemble standard d'outils d'administration système, tels que YaST de SUSE, il n'existe pas de norme commune pour les outils d'administration système Linux. Des fichiers texte et des outils de ligne de commande sont disponibles, mais leur utilisation peut parfois être gênante. Chaque version commerciale UNIX possède sa propre interface de gestion de système.Avec cette interface, vous pouvez gérer et modifier les éléments du système.Ce qui suit est un exemple de System Administration Manager pour HP-UX.

Ce SAM contient les modules suivants :

  • Utilisateurs ou groupes à gérer.
  • Options du noyau pouvant être modifiées.
  • Configuration du réseau.
  • Configuration et initialisation des disques.
  • Configuration du serveur X.

La qualité de ce pack d'utilitaires est excellente et le pack d'utilitaires fonctionne bien avec les fichiers texte. Il n'y a pas d'analogue de cet outil pour Linux. Même YaST dans SUSE n'a pas la même fonctionnalité.

Un autre aspect sous UNIX et Linux qui semble changer avec presque toutes les versions du système d'exploitation est l'emplacement des scripts d'initialisation du système. Heureusement, /sbin/init et /etc/inittab sont des répertoires standard. Mais les scripts de démarrage du système se trouvent dans des répertoires différents. montre les emplacements où les scripts d'initialisation du système sont stockés pour diverses distributions UNIX et Linux.

Tableau 2. Emplacement des scripts d'initialisation du système pour différentes versions d'UNIX
HP-UX/sbin/init.d
AIX/etc/rc.d/init.d
Irix/etc/init.d
Solaris/etc/init.d
chapeau rouge/etc/rc.d/init.d
SUSE/etc/rc.d/init.d
DebianName/etc/init.d
Slackware/etc/rc.d

En raison du grand nombre de distributions Linux et du nombre presque infini d'applications disponibles (étant donné qu'il existe également de nombreuses versions de cette application) pour ce système d'exploitation, la gestion des programmes sous Linux devient une tâche difficile. Le choix du bon outil dépend de la distribution avec laquelle vous travaillez. Un autre inconvénient provient du fait que certaines distributions utilisent le format de fichier Redhat Package Manager (RPM), alors que leurs programmes sont incompatibles. Cette division conduit à un grand nombre d'options pour travailler avec des packages, et il n'est pas toujours clair quel système est utilisé dans un environnement particulier.

D'autre part, les distributions commerciales d'UNIX contiennent des gestionnaires de packages standard. Même s'il existe différentes versions d'applications et des formats spécifiques pour différentes versions d'UNIX, l'environnement de gestion des applications est le même. Par exemple, Solaris utilise les mêmes outils de gestion de packages d'application depuis sa création. Et très probablement, les moyens d'identifier, d'ajouter ou de supprimer des packages logiciels dans Solaris resteront inchangés.

Les fournisseurs de distributions UNIX commerciales fournissent également le matériel sur lequel leur système d'exploitation est conçu pour fonctionner, afin qu'ils puissent introduire de nouveaux périphériques dans leur système d'exploitation, ce qui est beaucoup plus difficile à faire pour Linux. Par exemple, dans dernières versions Linux a tenté d'implémenter la prise en charge des composants remplaçables à chaud (avec plus ou moins de succès). Les versions commerciales d'UNIX ont cette capacité depuis de nombreuses années. De plus, dans les versions commerciales d'UNIX, la surveillance du matériel est meilleure que sous Linux. Les fabricants peuvent écrire des pilotes et les intégrer dans leur système d'exploitation, qui surveillera la santé du système, comme le nombre d'erreurs de mémoire ECC, les paramètres d'alimentation ou tout autre composant matériel. Ce type de support pour Linux n'est prévu que dans un avenir lointain.

Le matériel des systèmes UNIX commerciaux dispose également d'options de démarrage plus avancées. Avant le démarrage du système d'exploitation, il existe de nombreuses options pour personnaliser son démarrage, vérifier l'état du système ou ajuster les paramètres matériels. Le BIOS d'un PC standard a peu ou pas de ces options.

Soutien

L'une des différences les plus importantes entre Linux et UNIX est le coût. Les fournisseurs de systèmes UNIX commerciaux facturent un prix élevé pour leur UNIX, même s'il ne peut être utilisé qu'avec leurs plates-formes matérielles. Les distributions Linux, en revanche, sont relativement peu coûteuses, voire gratuites du tout.

Lorsque vous achetez une version commerciale d'UNIX, les fournisseurs fournissent généralement un support technique. La plupart des utilisateurs Linux ne sont pas pris en charge par le fabricant du système d'exploitation. Ils ne peuvent obtenir une assistance que par e-mail, forums et diverses communautés d'utilisateurs Linux. Cependant, ces groupes ne sont pas réservés aux utilisateurs de Linux. De nombreux administrateurs de systèmes d'exploitation commerciaux de la famille UNIX participent à ces groupes de support ouverts afin de pouvoir à la fois fournir une assistance et, si nécessaire, l'utiliser. De nombreuses personnes trouvent ces groupes d'entraide encore plus utiles que le système d'assistance proposé par le fabricant du système d'exploitation.

Conclusion

Les principes fondamentaux d'UNIX et de Linux sont très similaires. Pour un utilisateur ou un administrateur système, le passage de Linux à UNIX ajoutera quelques inconvénients au travail, mais en général, la transition sera indolore. Même si leurs systèmes de fichiers et leurs noyaux sont différents et prennent un certain temps pour s'y habituer, les outils et les API restent les mêmes. Pour la plupart, ces différences ne sont pas plus importantes que les différences entre les principales versions d'UNIX. Toutes les branches d'UNIX et de Linux évoluent progressivement et différeront légèrement les unes des autres, mais en raison de la maturité des concepts UNIX, les fondamentaux du système d'exploitation ne changeront pas beaucoup.

Introduction

Qu'est-ce qu'Unix ?

Où obtenir un Unix gratuit ?

Quelles sont les principales différences entre Unix et les autres systèmes d'exploitation ?

Pourquoi Unix ?

Concepts Unix de base

Système de fichiers

interpréteur de commandes

Manuels - homme

Introduction

Écrire sur le système d'exploitation Unix est extrêmement difficile. Premièrement, parce que beaucoup a été écrit sur ce système. Deuxièmement, parce que les idées et les décisions d'Unix ont eu et ont un impact énorme sur le développement de tous les systèmes d'exploitation modernes, et nombre de ces idées sont déjà décrites dans ce livre. Troisièmement, parce qu'Unix n'est pas un système d'exploitation, mais toute une famille de systèmes, et qu'il n'est pas toujours possible de "suivre" leur relation les uns avec les autres, et qu'il est tout simplement impossible de décrire tous les systèmes d'exploitation inclus dans cette famille . Cependant, sans aucunement prétendre à l'exhaustivité, nous tenterons de donner un aperçu rapide du "monde Unix" dans les domaines qui nous paraissent intéressants pour les besoins de notre tutoriel.

La naissance du système d'exploitation Unix remonte à la fin des années 60, et cette histoire a déjà acquis des "légendes", qui racontent parfois de différentes manières les détails de cet événement. Le système d'exploitation Unix est né au centre de recherche Bell Telephone Laboratories (Bell Labs), qui fait partie de la société AT&T. Initialement, ce projet d'initiative pour l'ordinateur PDP-7 (plus tard - pour le PDP-11) était soit un système de fichiers, soit un jeu informatique, soit un système de préparation de texte, soit les deux. Il est cependant important que dès le début le projet, qui s'est finalement transformé en OS, ait été conçu comme un environnement logiciel à usage collectif. L'auteur de la première version d'Unix est Ken Thompson, cependant, une grande équipe d'employés (D. Ritchie, B. Kernigan, R. Pike et autres) a participé à la discussion du projet, puis à sa mise en œuvre . A notre avis, plusieurs circonstances heureuses de la naissance d'Unix ont déterminé le succès de ce système pour de nombreuses années à venir.

Pour la plupart des membres de l'équipe où Unix est né, ce système d'exploitation était "le troisième système". Il existe une opinion (voir, par exemple) selon laquelle un programmeur système n'obtient des qualifications élevées qu'à la fin de son troisième projet: le premier projet est encore "étudiant", le deuxième développeur essaie d'inclure tout ce qui n'a pas fonctionné dans le premier, et en conséquence, il s'avère trop encombrant, et ce n'est que dans le troisième que l'équilibre nécessaire des désirs et des possibilités est atteint. On sait qu'avant la naissance d'Unix, l'équipe des Bell Labs a participé (avec un certain nombre d'autres entreprises) au développement de MULTICS OS. Le produit final de MULTICS (Bell Labs n'a pas participé aux dernières étapes de développement) porte toutes les caractéristiques d'un "second système" et n'est pas largement utilisé. Il convient de noter, cependant, que de nombreuses idées et décisions fondamentalement importantes sont nées dans ce projet, et certains concepts que beaucoup considèrent comme nés sous Unix proviennent en fait du projet MULTICS.

Le système d'exploitation Unix était un système créé « pour moi et pour mes amis ». Unix n'était pas destiné à conquérir le marché et à concurrencer n'importe quel produit. Les développeurs du système d'exploitation Unix eux-mêmes en étaient les utilisateurs et ils ont eux-mêmes évalué l'adéquation du système à leurs besoins. Sans la pression des conditions du marché, une telle évaluation pourrait être extrêmement objective.

Unix était un système créé par des programmeurs pour des programmeurs. Cela a déterminé l'élégance et l'harmonie conceptuelle du système - d'une part, et d'autre part - la nécessité de comprendre le système pour un utilisateur Unix et le sens des responsabilités professionnelles pour un programmeur développant des logiciels pour Unix. Et aucune tentative ultérieure de faire "Unix pour les nuls" n'a été capable de débarrasser le système d'exploitation Unix de cette vertu.

En 1972-73. Ken Thompson et Dennis Ritchie ont écrit une nouvelle version d'Unix. Spécialement à cette fin, D. Ritchie a créé le langage de programmation C, qui n'est plus nécessaire aujourd'hui. Plus de 90% du code Unix est écrit dans ce langage, et le langage est devenu partie intégrante du système d'exploitation. Le fait que la partie principale du système d'exploitation soit écrite dans un langage de haut niveau permet de le recompiler dans les codes de n'importe quelle plate-forme matérielle et c'est la circonstance qui a déterminé l'utilisation généralisée d'Unix.

Lors de la création d'Unix, les lois antitrust américaines empêchaient AT&T d'entrer sur le marché des logiciels. Par conséquent, le système d'exploitation Unix était non commercial et librement distribué, principalement dans les universités. Là, son développement s'est poursuivi et il a été mené le plus activement à l'Université de Californie à Berkeley. Dans cette université, le groupe Berkeley Software Distribution a été créé, qui était engagé dans le développement d'une branche distincte du système d'exploitation - BSD Unix. Tout au long de l'histoire ultérieure, Unix grand public et Unix BSD ont évolué en parallèle, s'enrichissant mutuellement à plusieurs reprises.

Au fur et à mesure que le système d'exploitation Unix se répandait, les entreprises commerciales s'y sont de plus en plus intéressées, qui ont commencé à publier leurs propres versions commerciales de ce système d'exploitation. Au fil du temps, la branche "principale" d'Unix d'AT&T est devenue commerciale, et une filiale d'Unix System Laboratory a été créée pour la promouvoir. La branche BSD Unix s'est à son tour bifurquée en BSD commercial et BSD libre. Divers systèmes commerciaux et gratuits de type Unix ont été construits sur le noyau AT&T Unix, mais ont inclus des fonctionnalités empruntées à BSD Unix ainsi que des fonctionnalités originales. Malgré la source commune, les différences entre les membres de la famille Unix se sont accumulées et ont finalement rendu extrêmement difficile le portage d'applications d'un système d'exploitation de type Unix à un autre. A l'initiative des utilisateurs d'Unix, il y a eu un mouvement de standardisation de l'API Unix. Ce mouvement a été soutenu par l'Organisation internationale de normalisation ISO et a conduit à l'émergence de la norme POSIX (Portable Operation System Interface eXecution), qui est toujours en cours de développement et qui est la norme la plus faisant autorité pour le système d'exploitation. Cependant, faire de la spécification POSIX une norme officielle est un processus lent et ne répond pas aux besoins des éditeurs de logiciels, ce qui a conduit à l'émergence de normes alternatives de l'industrie.

Avec la transition d'AT&T Unix vers Nowell, le nom de ce système d'exploitation est devenu Unixware et les droits sur la marque Unix ont été transférés au consortium X / Open. Ce consortium (maintenant l'Open Group) a développé sa propre spécification de système (plus large que POSIX), connue sous le nom de Single Unix Specification. La deuxième édition de cette norme a récemment été publiée, bien mieux alignée sur POSIX.

Enfin, un certain nombre d'entreprises produisant leurs propres versions d'Unix ont formé le consortium Open Software Foundation (OSF), qui a publié leur propre version d'Unix, OSF/1, basée sur le micro-noyau Mach. OSF a également publié les spécifications du système OSF / 1, qui ont servi de base aux entreprises membres de l'OSF pour publier leurs propres systèmes Unix. Ces systèmes incluent SunOS de Sun Microsystems, AIX d'IBM, HP/UX de Hewlett-Packard, DIGITAL UNIX de Compaq, et d'autres.

Initialement, les systèmes Unix de ces entreprises étaient principalement basés sur BSD Unix, mais maintenant la plupart des systèmes Unix industriels modernes sont construits en utilisant (sous licence) le noyau AT&T Unix System V Release 4 (S5R4), bien qu'ils héritent également de certaines propriétés de BSD Unix. . Nous ne prenons pas la responsabilité de comparer les systèmes Unix commerciaux, car les comparaisons de ce type qui apparaissent périodiquement dans la presse fournissent souvent des résultats complètement opposés.

Nowell a vendu Unix à Santa Crouse Operations, qui a produit son propre produit Unix, SCO Open Server. SCO Open Server était basé sur une version antérieure du noyau (System V Release 3), mais était superbement débogué et très stable. Santa Crouse Operations a intégré son produit avec AT&T Unix et a sorti Open Unix 8, mais a ensuite vendu Unix à Caldera, le propriétaire de l'Unix "classique" aujourd'hui (fin 2001).

Sun Microsystems a commencé son introduction dans le monde Unix avec SunOS, basé sur le noyau BSD. Cependant, il l'a ensuite remplacé par un système Solaris basé sur le S5R4. La version 8 de cet OS est en cours de distribution (il existe également la v.9-beta). Solaris fonctionne sur la plate-forme SPARC (processeurs RISC fabriqués selon les spécifications Sun) et Intel-Pentium.

Hewlett-Packard propose le système d'exploitation HP-UX. v.11 sur la plateforme PA-RISC. HP-UX est basé sur S5R4, mais contient de nombreuses fonctionnalités qui révèlent ses origines de BSD Unix. Bien entendu, HP-UX sera également disponible sur la plate-forme Intel-Itanium.

IBM sort avec le système d'exploitation AIX, la dernière version à ce jour est 5L (on en reparlera plus tard). IBM n'a pas annoncé le « pedigree » d'AIX, il s'agit surtout d'un développement original, mais les premières versions portaient des signes d'origine de FreeBSD Unix. Maintenant, cependant, AIX ressemble plus à S5R4. AIX était à l'origine disponible sur la plate-forme Intel-Pentium, mais n'a ensuite été (conformément à la politique générale d'IBM) plus pris en charge sur cette plate-forme. AIX fonctionne actuellement sur des serveurs IBM RS/6000 et d'autres plates-formes informatiques basées sur PowerPC (y compris les supercalculateurs IBM).

DIGITAL UNIX de DEC était la seule implémentation commerciale d'OSF/1. Le système d'exploitation DIGITAL UNIX fonctionnait sur les serveurs Alpha RISC de DEC. Lorsque DEC a été repris par Compaq en 1998, Compaq a acquis les serveurs Alpha et DIGITAL UNIX. Compaq a l'intention de rétablir sa présence sur le marché des serveurs Alpha et, à cet égard, développe intensivement un système d'exploitation pour eux. Le nom actuel de ce système d'exploitation est Tru64 Unix (la version actuelle est 5.1A), il continue d'être basé sur le noyau OSF/1 et possède de nombreuses fonctionnalités BSD Unix.

Bien que la plupart des systèmes Unix commerciaux soient basés sur un seul noyau et soient conformes aux exigences POSIX, chacun a son propre dialecte d'API et les différences entre les dialectes sont cumulatives. Ceci conduit au fait que le portage d'applications industrielles d'un système Unix à un autre est difficile et nécessite au moins une recompilation, et souvent aussi une correction du code source. Une tentative de surmonter la "confusion" et de créer un seul système d'exploitation Unix pour tous a été entreprise en 1998 par une alliance de SCO, IBM et Sequent. Ces entreprises se sont regroupées dans le projet Monterey pour créer un système d'exploitation unique basé sur Unixware, détenu à l'époque par SCO, IBM AIX et le système d'exploitation DYNIX de Sequent. (Sequent est un leader dans la production d'ordinateurs NUMA - multiprocesseurs asymétriques - et DYNIX est Unix pour de tels ordinateurs). Le système d'exploitation Monterey devait fonctionner sur la plate-forme Intel-Pentium 32 bits, la plate-forme PowerPC 64 bits et la nouvelle plate-forme Intel-Itanium 64 bits. Presque tous les leaders de l'industrie du matériel et du middleware ont déclaré leur soutien au projet. Même les entreprises qui ont leurs propres clones Unix (à l'exception de Sun Microsystems) ont annoncé qu'elles ne prendraient en charge Monterey que sur les plates-formes Intel. Les travaux sur le projet semblaient bien se dérouler. Monterey OS a été parmi les premiers à prouver ses performances sur Intel-Itanium (avec Windows NT et Linux) et le seul à ne pas émuler l'architecture Intel-Pentium 32 bits. Cependant, dans la phase finale du projet, un événement fatal s'est produit : SCO a vendu sa division Unix. Même plus tôt, Sequent faisait partie d'IBM. Le "successeur" de toutes les fonctionnalités de Monterey OS est IBM AIX v.5L OS. Cependant, pas tout à fait. La plate-forme Intel-Pentium n'est pas un axe stratégique pour IBM et AIX n'est pas disponible sur cette plate-forme. Et parce que d'autres leaders de l'industrie informatique ne partagent pas (ou ne partagent pas tout à fait) la position d'IBM, l'idée d'un système d'exploitation Unix commun ne s'est jamais concrétisée.

Si vous avez récemment commencé à apprendre Linux et à vous familiariser avec ce vaste univers, vous avez probablement beaucoup rencontré le terme Unix. Cela ressemble beaucoup à Linux, mais qu'est-ce que cela signifie ? Vous vous demandez probablement quelle est la différence entre unix et linux. La réponse à cette question dépend de ce que vous entendez par ces mots. Après tout, chacun d'eux peut être interprété de différentes manières. Dans cet article, nous examinerons un historique simplifié de Linux et Unix pour vous aider à comprendre ce qu'ils sont et comment ils sont liés. Comme toujours, vous pouvez poser des questions ou ajouter plus d'informations dans les commentaires.

Unix a commencé son histoire à la fin des années 1960 et au début des années 1970 chez AT&T Bell Labs aux États-Unis. En collaboration avec le MIT et General Electric, Bell Labs a commencé à développer un nouveau système d'exploitation. Certains chercheurs n'étaient pas satisfaits du développement de ce système d'exploitation. Ils ont cessé de travailler sur le projet principal et ont commencé à développer leur propre système d'exploitation. En 1970, ce système s'appelait Unix, et deux ans plus tard, il était complètement réécrit en langage de programmation C.

Cela a permis à Unix d'être distribué et porté sur divers appareils et plates-formes informatiques.

Alors qu'Unix continuait d'évoluer, AT&T a commencé à le concéder sous licence pour une utilisation universitaire ainsi qu'à des fins commerciales. Cela signifiait que tout le monde ne pouvait pas, comme maintenant, modifier et distribuer librement le code du système d'exploitation Unix. Bientôt, de nombreuses éditions et variantes du système d'exploitation Unix ont commencé à apparaître, conçues pour résoudre divers problèmes. Le plus célèbre d'entre eux était BSD.

Linux est similaire à Unix dans les fonctionnalités et les fonctionnalités, mais pas dans la base de code. Ce système d'exploitation a été assemblé à partir de deux projets. Le premier est le projet GNU développé par Richard Stallman en 1983, le second est le noyau Linux écrit par Linus Torvalds en 1991.

L'objectif du projet GNU était de créer un système similaire à Unix, mais indépendant de celui-ci. En d'autres termes, un système d'exploitation ne contenant aucun code Unix pouvant être librement redistribué et modifié sans restriction, comme un logiciel libre. Étant donné que le noyau Linux libre ne pouvait pas fonctionner seul, le projet GNU a fusionné avec le noyau Linux et le système d'exploitation Linux est né.

Linux a été conçu sous l'influence du système Minix, un descendant d'Unix, mais tout le code a été écrit à partir de zéro. Contrairement à Unix, qui était utilisé sur les serveurs et les grands ordinateurs centraux de diverses entreprises, Linux a été conçu pour être utilisé sur ordinateur de famille avec un matériel plus simple.

Aujourd'hui, Linux fonctionne sur plus de plates-formes que tout autre système d'exploitation, y compris les serveurs, les systèmes embarqués, les micro-ordinateurs, les modems et même les téléphones portables. Maintenant, la différence entre Linux et Unix sera examinée plus en détail.

Qu'est-ce qu'Unix

Le terme Unix peut faire référence à ces concepts :

  • Le système d'exploitation original développé par AT&T Bell Labs à partir duquel d'autres systèmes d'exploitation sont développés.
  • Marque déposée, écrite en majuscules. UNIX appartient à The Open Group, qui a développé la spécification UNIX unique, un ensemble de normes pour les systèmes d'exploitation. Seuls les systèmes conformes aux normes peuvent légitimement s'appeler UNIX. La certification n'est pas gratuite et oblige les développeurs à payer pour l'utilisation de cette marque.
  • Tous les systèmes d'exploitation sont enregistrés avec le nom Unix. Parce qu'ils répondent aux normes susmentionnées. Ce sont AIX, A/UX, HP-UX, Inspur K-UX, Reliant UNIX, Solaris, IRIX, Tru64, UnixWare, z/OS et OS X - oui, même ceux qui fonctionnent sur des ordinateurs Apple.

Qu'est-ce que Linux

Le terme Linux se réfère uniquement au noyau. Un système d'exploitation ne serait pas complet sans un environnement de bureau et des applications. Étant donné que la plupart des applications ont été développées et sont actuellement développées dans le cadre du projet GNU, le nom complet du système d'exploitation est GNU/Linux.

Beaucoup de gens utilisent maintenant le terme Linux pour désigner toutes les distributions basées sur le noyau Linux. Pour le moment, la dernière version du noyau Linux est la 4.4, la version 4.5 est en cours de développement. La renumérotation des versions du noyau de 3.x à 4.x a eu lieu il n'y a pas si longtemps.

Linux est un système d'exploitation de type Unix qui se comporte comme Unix mais ne contient pas son code. Les systèmes d'exploitation de type Unix sont souvent appelés Un*x, *NIX et *N?X, ou même Unixoids. Linux n'a pas de certification Unix, et GNU signifie GNU et non Unix, donc Mac OS X est plus Unix que Linux à cet égard. Néanmoins, le noyau Linux et le système d'exploitation GNU Linux sont très similaires à Unix en termes de fonctionnalités, implémentant la plupart des principes de la philosophie Unix. Il s'agit d'un code lisible par l'homme, stockant la configuration du système dans des fichiers texte séparés et utilisant de petits outils de ligne de commande, un shell graphique et un gestionnaire de session.

Il est important de noter que tous les systèmes de type Unix n'ont pas reçu la certification UNIX. Dans un certain contexte, tous les systèmes d'exploitation basés sur UNIX ou ses idées sont appelés UNIX-like, qu'ils aient ou non un certificat UNIX. De plus, ils peuvent être commerciaux et gratuits.

J'espère maintenant qu'il est devenu plus clair en quoi Unix diffère de Linux. Mais allons encore plus loin et résumons.

Principales différences

  • Linux est un système d'exploitation libre et open source, mais l'Unix d'origine ne l'est pas, à l'exception de certains de ses dérivés.
  • Linux est un clone de l'Unix original, mais il ne contient pas son code.
  • La principale différence entre Unix et Linux est que Linux n'est qu'un noyau, alors qu'Unix était et est un système d'exploitation à part entière.
  • Linux a été conçu pour les ordinateurs personnels. Et Unix se concentre principalement sur les gros postes de travail et les serveurs.
  • Aujourd'hui, Linux prend en charge plus de plates-formes qu'Unix.
  • Linux prend en charge plus de types de systèmes de fichiers qu'Unix.

Comme vous pouvez le voir, la confusion vient généralement du fait que linux vs unix peut signifier des choses complètement différentes. Quelle que soit la signification, le fait demeure qu'Unix est venu en premier et que Linux est venu plus tard. Linux est né d'un désir de liberté logicielle et de portabilité, inspiré de l'approche Unix. Il est prudent de dire que nous sommes tous redevables au mouvement du logiciel libre, car le monde serait bien pire sans lui.

MINISTERE DE L'EDUCATION ET DES SCIENCES DE LA RUSSE

FÉDÉRATION

AGENCE FÉDÉRALE POUR L'ÉDUCATION

ÉTABLISSEMENT ÉDUCATIF D'ÉTAT

ENSEIGNEMENT PROFESSIONNEL SUPERIEUR

Université d'ingénierie radio d'État de Taganrog

Discipline "Informatique"

"Système d'exploitation UNIX"

Complété par: Orda-Zhigulina D.V., gr. E-25

Vérifié: Vishnevetsky V.Yu.

Taganrog 2006


Introduction

Qu'est-ce qu'Unix 3

Où obtenir gratuitement Unix 7

Partie principale. (Description d'Unix)

1. Concepts de base d'Unix 8

2. Système de fichiers 9

2.1 Types de fichiers 9

3. Interpréteur de commandes 11

4. Noyau UNIX 12

4.1 Organisation générale du noyau UNIX traditionnel 13

4.2 Fonctions principales du noyau 14

4.3 Principes d'interaction avec le noyau 15

4.4 Principes de gestion des interruptions 17

5. Contrôle E/S 18

5.1 Principes de la mise en mémoire tampon des E/S du système 19

5. 2 appels système pour le contrôle des E/S 21

6. Interfaces et points d'entrée des conducteurs 23

6.1 Bloquer les pilotes 23

6.2 Pilotes de personnage 24

6. 3 pilotes de flux 25

7. Commandes et utilitaires 25

7. 1 Organisation de l'équipe sous UNIX OS 26

7.2 Redirection d'E/S et tuyauterie 26

7. 3 Commandes intégrées, bibliothèque et utilisateur 26

7.4 Programmation en langage de commande 27

8. Outils de l'interface graphique 27

8.1 ID utilisateur et groupes d'utilisateurs 30

8.2 Protection des fichiers 32

8.3 Systèmes d'exploitation prometteurs prenant en charge l'environnement UNIX OS 33

Conclusion

Principales différences entre Unix et les autres OS 36

Applications d'Unix 37


Introduction

Qu'est-ce qu'Unix

Le terme Unix et UNIX pas tout à fait équivalent sont utilisés avec des significations différentes. Commençons par le second des termes, le plus simple. En un mot, UNIX (sous cette forme) est une marque déposée détenue à l'origine par AT&T Corporation, qui a changé de mains au fil des ans et est maintenant la propriété d'une organisation appelée Open Group. Le droit d'utiliser le nom UNIX est obtenu par une sorte de "vérification des poux" - en passant des tests de conformité aux spécifications de certains systèmes d'exploitation de référence (Single Unix Standard - qui dans ce cas peut être traduit par Single Standard on Unix). Cette procédure est non seulement compliquée, mais aussi très coûteuse, et donc seuls quelques systèmes d'exploitation parmi les systèmes actuels l'ont subie, et tous sont propriétaires, c'est-à-dire qu'ils sont la propriété de certaines sociétés.

Parmi les corporations qui ont mérité le droit au nom UNIX puis développeurs/testeurs et le sang (plus précisément, le dollar) des propriétaires, on peut nommer les suivants :

Sun avec son SunOS (mieux connu dans le monde sous le nom de Solaris);

IBM, qui a développé le système AIX ;

Hewlett-Packard est le propriétaire du système HP-UX ;

IRIX est le système d'exploitation de SGI.

De plus, le nom UNIX correct s'applique aux systèmes :

True64 Unix, développé par DEC, dont la liquidation est passée à Compaq, et maintenant, avec ce dernier, est devenu la propriété du même Hewlett-Packard;

UnixWare appartient à SCO (un produit de la fusion de Caldera et Santa Cruz Operation).

Étant propriétaires, tous ces systèmes sont vendus très cher (même selon les normes américaines). Cependant, ce n'est pas le principal obstacle à la diffusion d'UNIX lui-même, car leur caractéristique commune est contraignante pour certaines plates-formes matérielles : AIX tourne sur des serveurs et des stations de travail IBM avec des processeurs Power, HP-UX sur leur propre HP-PA (Precision Architecture) machines , IRIX - sur les stations graphiques de SGI, portant des processeurs MIPS,True64 Unix - conçu pour les processeurs Alpha (malheureusement, dans le défunt Bose) Seul UnixWare se concentre sur la plate-forme PC "démocratique", et Solaris existe en versions pour deux architectures - le sien, Sparc, et toujours le même PC, qui, cependant, n'a pas beaucoup contribué à leur prévalence - en raison du support relativement faible des nouveaux périphériques PC.

Ainsi, UNIX est avant tout un concept juridique. Mais le terme Unix a une interprétation technologique. C'est le nom commun utilisé par l'industrie informatique pour désigner toute la famille des systèmes d'exploitation, soit dérivés de la société UNIX "originale" AT&T, soit reproduisant ses fonctions "à partir de zéro", y compris les systèmes d'exploitation libres tels que Linux, FreeBSD et autres BSD, aucune vérification de conformité au Single Unix Standard n'a jamais été exposée. C'est pourquoi ils sont souvent appelés Unix-like.

Le terme "systèmes compatibles POSIX", au sens proche, est également largement utilisé, qui réunit une famille de systèmes d'exploitation correspondant à l'ensemble des normes du même nom. Les normes POSIX (Portable Operation System Interface based on uniX) elles-mêmes ont été développées sur la base des pratiques adoptées dans les systèmes Unix, et donc ces derniers sont tous, par définition, conformes à POSIX. Cependant, ceux-ci ne sont pas complètement synonymes : la compatibilité avec les normes POSIX est revendiquée par des systèmes d'exploitation qui ne sont qu'indirectement liés à Unix (QNX, Syllable), ou pas du tout liés (jusqu'à Windows NT/2000/XP).

Pour clarifier la question de la relation entre UNIX, Unix et POSIX, nous devons plonger un peu dans l'histoire. En fait, l'histoire de ce problème est discutée en détail dans le chapitre correspondant du livre "Free Unix: Linux, FreeBSD and Others" (prochainement par BHV-Petersburg) et dans des articles sur l'histoire des systèmes Linux et BSD.

Le système d'exploitation Unix (plus précisément sa première version) a été développé par des employés de Bell Labs (une division d'AT & T) en 1969-1971. Ses premiers auteurs - Ken Thompson et Dennis Ritchie - l'ont fait uniquement pour leurs propres besoins, notamment pour pouvoir s'amuser avec leur jeu StarTravel préféré. Et pour un certain nombre de raisons juridiques, l'entreprise elle-même ne pouvait pas l'utiliser comme produit commercial. Cependant, l'application pratique d'Unix a été trouvée assez rapidement. Tout d'abord, il a été utilisé aux Bell Labs pour préparer divers types de documentation technique (y compris les brevets). Et deuxièmement, le système de communication UUCP (Unix to Unix Copy Program) était basé sur Unix.

Un autre domaine où Unix était utilisé dans les années 70 et au début des années 80 du siècle dernier s'est avéré assez inhabituel. A savoir, dans les textes sources, il a été réparti entre les institutions scientifiques menant des travaux dans le domaine de l'informatique. Le but de cette diffusion (elle n'était pas totalement gratuite au sens courant du terme, mais s'est en fait avérée très libérale) était : l'éducation et la recherche dans le domaine de connaissance ci-dessus.

Le plus célèbre est le système BSD Unix, créé à l'Université de Berkeley, en Californie. Qui, se libérant progressivement du code propriétaire de l'Unix d'origine, a finalement, après des hauts et des bas dramatiques (décrits en détail ici), donné naissance aux systèmes BSD libres modernes - FreeBSD, NetBSD et autres.

L'un des résultats les plus importants du travail des pirates universitaires a été (1983) l'introduction du support du protocole TCP / IP dans Unix, sur lequel était basé l'ARPANET d'alors (et qui est devenu le fondement de l'Internet moderne). C'était une condition préalable à la domination d'Unix dans tous les domaines liés au World Wide Web. Et cela s'est avéré être la prochaine application pratique de cette famille de systèmes d'exploitation - à ce moment-là, il n'était plus nécessaire de parler d'un seul Unix. Parce qu'il a, comme mentionné précédemment, séparé ses deux branches - provenant de l'UNIX d'origine (au fil du temps, il a reçu le nom de System V) et du système d'origine Berkeley. D'autre part, System V a constitué la base de ces différents UNIX propriétaires qui, en fait, avaient le droit légal de revendiquer ce nom.

La dernière circonstance - la ramification de l'ancien système d'exploitation unique en plusieurs lignes qui perdent progressivement leur compatibilité - est entrée en conflit avec l'une des pierres angulaires de l'idéologie Unix : la portabilité du système entre différentes plates-formes et ses applications d'un système Unix à une autre. Ce qui a donné vie aux activités de divers types d'organismes de normalisation, qui ont finalement abouti à la création de l'ensemble de normes POSIX, qui a été mentionné plus tôt.

C'est sur les normes POSIX que Linus Torvalds s'est appuyé, créant "à partir de zéro" (c'est-à-dire sans utiliser de code préexistant) son système d'exploitation - Linux. Et elle, ayant rapidement et avec succès maîtrisé les domaines d'application traditionnels des systèmes Unix (développement de logiciels, communications, Internet), leur en a finalement ouvert un nouveau - les plates-formes d'utilisateurs de bureau à usage général. C'est ce qui l'a rendu populaire parmi les gens - une popularité qui surpasse celle de tous les autres systèmes Unix combinés, à la fois propriétaires et libres.

De plus, nous parlerons de travailler sur des systèmes Unix au sens le plus large du terme, sans tenir compte des marques et autres problèmes juridiques. Bien que les principaux exemples liés aux méthodes de travail soient tirés du domaine de leurs implémentations libres - Linux, dans une moindre mesure FreeBSD, et encore moins - d'autres systèmes BSD.

Où obtenir un Unix gratuit ?

Base de données FreeBSD - www.freebsd.org ;

Vous pouvez aller sur www.sco.com


Partie principale. (Description d'Unix)

1. Concepts de base d'Unix

Unix est basé sur deux concepts de base : « processus » et « fichier ». Les processus sont le côté dynamique du système, ce sont des sujets ; et les fichiers - statiques, ce sont les objets des processus. Presque toute l'interface entre les processus interagissant avec le noyau et les uns avec les autres ressemble à l'écriture / lecture de fichiers. Bien que vous deviez ajouter des éléments tels que des signaux, de la mémoire partagée et des sémaphores.

Les processus peuvent être grossièrement divisés en deux types : les tâches et les démons. Une tâche est un processus qui fait son travail, en essayant de le terminer le plus tôt possible et de le terminer. Le démon attend les événements qu'il doit traiter, traite les événements qui se sont produits et attend à nouveau ; il se termine généralement sur l'ordre d'un autre processus, le plus souvent il est tué par l'utilisateur en donnant la commande "kill numéro_processus". En ce sens, il s'avère qu'une tâche interactive qui traite les entrées de l'utilisateur ressemble plus à un démon qu'à une tâche.

2. Système de fichiers

Dans les anciens Unix "s, 14 lettres étaient attribuées au nom, dans les nouveaux cette restriction a été supprimée. En plus du nom de fichier, le répertoire contient son identifiant d'inode - un entier qui détermine le numéro du bloc dans lequel le les attributs du fichier sont enregistrés, parmi lesquels : le numéro d'utilisateur - le propriétaire du fichier ; les groupes de numéros Le nombre de références au fichier (voir ci-dessous) La date et l'heure de création, la dernière modification et le dernier accès au fichier Les attributs d'accès Les attributs d'accès contiennent le fichier type (voir ci-dessous), les droits de modification des attributs au démarrage (voir ci-dessous) et les autorisations d'accès pour le propriétaire, le camarade de classe et d'autres personnes pour la lecture, l'écriture et l'exécution. Le droit de supprimer un fichier est déterminé par le droit d'écrire sur le fichier annuaire.

Chaque fichier (mais pas un répertoire) peut être connu sous plusieurs noms, mais ils doivent être sur la même partition. Tous les liens vers le fichier sont égaux ; le fichier est supprimé lorsque le dernier lien vers le fichier est supprimé. Si le fichier est ouvert (en lecture et/ou en écriture), alors le nombre de liens vers celui-ci augmente d'une unité ; c'est le nombre de programmes qui ouvrent un fichier temporaire le suppriment immédiatement de sorte que s'ils plantent, lorsque le système d'exploitation ferme les fichiers ouverts par le processus, ce fichier temporaire sera supprimé par le système d'exploitation.

Il existe une autre caractéristique intéressante du système de fichiers: si, après la création du fichier, l'écriture n'était pas consécutive, mais à de grands intervalles, aucun espace disque n'est alloué pour ces intervalles. Ainsi, le volume total de fichiers dans une partition peut être supérieur au volume de la partition, et lorsqu'un tel fichier est supprimé, moins d'espace est libéré que sa taille.

2.1 Types de fichiers

Les fichiers sont des types suivants :

dossier d'accès direct régulier;

répertoire (fichier contenant les noms et identifiants des autres fichiers) ;

lien symbolique (chaîne avec le nom d'un autre fichier) ;

périphérique bloc (disque ou bande magnétique);

périphérique série (terminaux, ports série et parallèle ; les disques et les bandes ont également une interface de périphérique série)

canal nommé.

Les fichiers spéciaux conçus pour fonctionner avec les périphériques se trouvent généralement dans le répertoire "/dev". En voici quelques-uns (dans la nomination FreeBSD):

tty* - terminaux, y compris : ttyv - console virtuelle ;

ttyd - Terminal DialIn (généralement un port série);

cuaa - Ligne DialOut

ttyp - pseudo-terminal réseau ;

tty - le terminal auquel la tâche est associée ;

wd* - disques durs et leurs sous-sections, y compris : wd - disque dur ;

wds - partition de ce disque (appelée ici "slice");

wds - section de partition ;

fd - disquette ;

rwd*, rfd* - identique à wd* et fd*, mais avec accès séquentiel ;

Parfois, il est nécessaire qu'un programme lancé par un utilisateur n'ait pas les droits de l'utilisateur qui l'a lancé, mais d'un autre. Dans ce cas, l'attribut des droits de modification est défini sur les droits de l'utilisateur - le propriétaire du programme. (A titre d'exemple, je vais donner un programme qui lit un fichier avec des questions et des réponses et, en fonction de ce qu'il a lu, teste l'étudiant qui a lancé ce programme. Le programme doit avoir le droit de lire le fichier avec des réponses, mais l'étudiant qui l'a lancé ne devrait pas.) Par exemple, le programme passwd fonctionne, avec lequel l'utilisateur peut changer son mot de passe. L'utilisateur peut exécuter le programme passwd, il peut apporter des modifications à la base de données système - mais l'utilisateur ne le peut pas.

Contrairement à DOS, où le nom de fichier complet est "drive:pathname" et RISC-OS, qui est "-filesystem-drive:$.pathname" (ce qui a généralement ses avantages), Unix utilise une notation transparente sous la forme "/path/name ". La racine est mesurée à partir de la partition à partir de laquelle le noyau Unix a été chargé. Si une partition différente doit être utilisée (et que la partition de démarrage ne contient généralement que ce qui est nécessaire pour démarrer), la commande `mount /dev/partitionfile dir` est utilisée. Dans le même temps, les fichiers et sous-répertoires qui se trouvaient auparavant dans ce répertoire deviennent inaccessibles jusqu'à ce que la partition soit démontée (naturellement, toutes les personnes normales utilisent des répertoires vides pour monter des partitions). Seul le superviseur a le droit de monter et de démonter.

Au démarrage, chaque processus peut s'attendre à avoir trois fichiers ouverts pour lui, qu'il connaît comme entrée standard stdin au descripteur 0 ; sortie standard stdout sur le descripteur 1 ; et la sortie standard stderr sur le descripteur 2. Une fois connecté, lorsque l'utilisateur entre un nom d'utilisateur et un mot de passe et que le shell est démarré, tous les trois sont dirigés vers /dev/tty ; plus tard, n'importe lequel d'entre eux peut être redirigé vers n'importe quel fichier.

3. Interpréteur de commandes

Unix est presque toujours livré avec deux shells, sh (shell) et csh (un shell de type C). En plus d'eux, il y a aussi bash (Bourne), ksh (Korn) et d'autres. Sans entrer dans les détails, voici les principes généraux :

Toutes les commandes, à l'exception de la modification du répertoire courant, de la définition des variables d'environnement (environnement) et des instructions de programmation structurées, sont des programmes externes. Ces programmes se trouvent généralement dans les répertoires /bin et /usr/bin. Programmes d'administration système - dans les répertoires /sbin et /usr/sbin.

La commande se compose du nom du programme à lancer et d'arguments. Les arguments sont séparés du nom de la commande et les uns des autres par des espaces et des tabulations. Certains caractères spéciaux sont interprétés par le shell lui-même. Les caractères spéciaux sont " " ` ! $ ^ * ? | & ; (quoi d'autre ?).

Vous pouvez donner plusieurs commandes sur la même ligne de commande. Les équipes peuvent être divisées; (exécution de commande séquentielle), & (exécution de commande simultanée asynchrone), | (exécution synchrone, le stdout de la première commande sera envoyé au stdin de la seconde).

Vous pouvez également prendre l'entrée standard d'un fichier en incluant "file" (le fichier sera mis à zéro) ou ">>file" (l'entrée sera écrite à la fin du fichier) comme l'un des arguments.

Si vous avez besoin d'informations sur une commande, lancez la commande "man command_name". Cela sera affiché à l'écran via le programme "more" - voyez comment le gérer sur votre Unix avec la commande `man more`.

4. Noyau UNIX

Comme tout autre système d'exploitation multi-utilisateurs qui protège les utilisateurs les uns des autres et protège les données système de tout utilisateur non privilégié, UNIX dispose d'un noyau sécurisé qui gère les ressources informatiques et fournit aux utilisateurs un ensemble de services de base.

La commodité et l'efficacité des versions modernes du système d'exploitation UNIX ne signifient pas que l'ensemble du système, y compris le noyau, est conçu et structuré de la meilleure façon possible. Le système d'exploitation UNIX a évolué au fil des ans (c'est le premier système d'exploitation de l'histoire qui continue de gagner en popularité à un âge aussi mûr - depuis plus de 25 ans). Naturellement, les capacités du système ont augmenté et, comme cela arrive souvent dans les grands systèmes, les améliorations qualitatives de la structure du système d'exploitation UNIX n'ont pas suivi le rythme de la croissance de ses capacités.

En conséquence, le cœur de la plupart des versions commerciales modernes du système d'exploitation UNIX est un gros monolithe pas très bien structuré. Pour cette raison, la programmation au niveau du noyau UNIX continue d'être un art (à l'exception de la technologie bien établie et compréhensible pour développer des pilotes de périphériques externes). Ce manque de fabricabilité dans l'organisation du noyau UNIX n'en satisfait pas beaucoup. D'où le souhait d'une reproduction complète de l'environnement UNIX OS avec une organisation complètement différente du système.

En raison de la plus grande prévalence, le noyau UNIX System V est souvent discuté (il peut être considéré comme traditionnel).

4.1 Organisation générale du noyau UNIX traditionnel

L'une des principales réalisations du système d'exploitation UNIX est que le système a la propriété d'une grande mobilité. La signification de cette qualité est que l'ensemble du système d'exploitation, y compris son noyau, est relativement facile à transférer sur différentes plates-formes matérielles. Toutes les parties du système, à l'exception du noyau, sont complètement indépendantes de la machine. Ces composants sont soigneusement écrits en C et leur portage sur une nouvelle plate-forme (au moins sur la classe d'ordinateurs 32 bits) ne nécessite qu'une recompilation. code source aux codes informatiques cibles.

Bien sûr, les plus gros problèmes sont associés au noyau du système, qui masque complètement les spécificités de l'ordinateur utilisé, mais dépend lui-même de ces spécificités. À la suite d'une séparation réfléchie des composants du noyau dépendants de la machine et indépendants de la machine (apparemment, du point de vue des développeurs de systèmes d'exploitation, il s'agit de la plus haute réalisation des développeurs du noyau UNIX OS traditionnel), il a été possible de faire en sorte que la partie principale du noyau ne dépende pas des caractéristiques architecturales de la plate-forme cible, soit entièrement écrite en C et ne nécessite qu'une recompilation pour être portée sur une nouvelle plate-forme.

Cependant, une partie relativement petite du noyau dépend de la machine et est écrite dans un mélange de C et du langage d'assemblage du processeur cible. Lors du transfert d'un système vers une nouvelle plate-forme, cette partie du noyau doit être réécrite en langage assembleur et en tenant compte des spécificités du matériel cible. Les parties du noyau dépendantes de la machine sont bien isolées de la partie principale indépendante de la machine, et avec une bonne compréhension de l'objectif de chaque composant dépendant de la machine, la réécriture de la partie spécifique à la machine est principalement une tâche technique (bien qu'elle nécessite des compétences en programmation).

La partie spécifique à la machine du noyau UNIX traditionnel comprend les composants suivants :

promotion et initialisation du système à un niveau bas (jusqu'à présent, cela dépend des fonctionnalités du matériel);

traitement primaire des interruptions internes et externes ;

la gestion de la mémoire (dans la partie relative aux fonctionnalités de support matériel de la mémoire virtuelle) ;

changement de contexte de processus entre les modes utilisateur et noyau ;

cibles spécifiques à la plate-forme des pilotes de périphériques.

4.2 Principales fonctions du noyau

Les principales fonctions du noyau du système d'exploitation UNIX sont les suivantes :

(a) Initialisation du système - fonction de démarrage et d'accélération. Le noyau fournit un outil d'amorçage qui charge le noyau complet dans la mémoire de l'ordinateur et démarre le noyau.

(b) Gestion des processus et des threads - la fonction de création, de terminaison et de suivi des processus et des threads existants ("processus" s'exécutant sur la mémoire virtuelle partagée). Étant donné qu'UNIX est un système d'exploitation multiprocessus, le noyau prévoit le partage du temps processeur (ou des processeurs dans les systèmes multiprocesseurs) et d'autres ressources informatiques entre les processus en cours d'exécution pour donner l'impression que les processus s'exécutent réellement en parallèle.

(c) La gestion de la mémoire consiste à mapper la mémoire virtuelle virtuellement illimitée des processus dans la RAM physique de l'ordinateur, dont la taille est limitée. Le composant noyau correspondant permet une utilisation partagée des mêmes zones de RAM par plusieurs processus utilisant de la mémoire externe.

(d) Gestion de fichiers - une fonction qui met en œuvre l'abstraction du système de fichiers - hiérarchies de répertoires et de fichiers. Les systèmes de fichiers UNIX prennent en charge plusieurs types de fichiers. Certains fichiers peuvent contenir des données ASCII, d'autres correspondront à des périphériques externes. Le système de fichiers stocke les fichiers objets, les fichiers exécutables, etc. Les fichiers sont généralement stockés sur des périphériques de stockage externes ; l'accès à ceux-ci est fourni au moyen du noyau. Il existe plusieurs types d'organisation de système de fichiers dans le monde UNIX. Les versions modernes du système d'exploitation UNIX prennent simultanément en charge la plupart des types de systèmes de fichiers.

(e) Moyens de communication - une fonction qui permet d'échanger des données entre des processus s'exécutant à l'intérieur du même ordinateur (IPC - Inter-Process Communications), entre des processus s'exécutant dans différents nœuds d'un réseau de données local ou étendu, ainsi qu'entre des processus et les pilotes de périphériques externes.

(f) Interface de programmation - une fonction qui permet d'accéder aux capacités du noyau du côté des processus utilisateur basés sur le mécanisme des appels système, organisés sous la forme d'une bibliothèque de fonctions.

4.3 Principes d'interaction avec le noyau

Dans tout système d'exploitation, un mécanisme est pris en charge qui permet aux programmes utilisateur d'accéder aux services du noyau du système d'exploitation. Dans les systèmes d'exploitation du plus célèbre ordinateur soviétique BESM-6, les moyens de communication correspondants avec le noyau étaient appelés extracodes, dans les systèmes d'exploitation IBM, ils étaient appelés macros système, etc. Sous UNIX, ces fonctions sont appelées appels système.

Le nom ne change pas la signification, qui est que pour accéder aux fonctions du noyau du système d'exploitation, des "instructions spéciales" du processeur sont utilisées, lorsqu'elles sont exécutées, un type spécial d'interruption interne du processeur se produit, le transférant au mode noyau (dans la plupart des OS ce type d'interruption est appelé trap - trap). Lors du traitement de telles interruptions (déchiffrement), le noyau du système d'exploitation reconnaît que l'interruption est en fait une demande au noyau du programme utilisateur pour effectuer certaines actions, sélectionne les paramètres de l'appel et le traite, puis effectue un "retour de l'interruption ", reprenant l'exécution normale du programme utilisateur.

Il est clair que les mécanismes spécifiques pour déclencher des interruptions internes initiées par le programme utilisateur diffèrent dans différentes architectures matérielles. Étant donné que le système d'exploitation UNIX s'efforce de fournir un environnement dans lequel les programmes utilisateur peuvent être entièrement mobiles, une couche supplémentaire était nécessaire pour masquer les spécificités du mécanisme spécifique de déclenchement des interruptions internes. Ce mécanisme est fourni par la soi-disant bibliothèque d'appel système.

Pour l'utilisateur, la bibliothèque d'appels système est une bibliothèque régulière de fonctions pré-implémentées du système de programmation C. Lors de la programmation en C, l'utilisation de n'importe quelle fonction de la bibliothèque d'appels système n'est pas différente de l'utilisation de n'importe quelle fonction C native ou de la bibliothèque. Cependant, à l'intérieur de toute fonction d'une bibliothèque d'appels système particulière, il y a du code qui est, en général, spécifique à une plate-forme matérielle donnée.

4.4 Principes de gestion des interruptions

Bien sûr, le mécanisme de gestion des interruptions internes et externes utilisé dans les systèmes d'exploitation dépend principalement du type de support matériel pour la gestion des interruptions fourni par une plate-forme matérielle particulière. Heureusement, à l'heure actuelle (et depuis un certain temps maintenant), les principaux fabricants d'ordinateurs se sont de facto mis d'accord sur les mécanismes d'interruption de base.

Pour ne pas parler très précisément et spécifiquement, l'essence du mécanisme adopté aujourd'hui est que chaque interruption possible du processeur (qu'il s'agisse d'une interruption interne ou externe) correspond à une adresse fixe de RAM physique. Au moment où le processeur est autorisé à interrompre en raison de la présence d'une demande d'interruption interne ou externe, il y a un transfert matériel de contrôle vers la cellule de RAM physique avec l'adresse correspondante - généralement l'adresse de cette cellule est appelée "l'interruption vector" (généralement, les requêtes d'interruption interne, c'est-à-dire les requêtes provenant directement du processeur sont satisfaites immédiatement).

Le rôle du système d'exploitation est de placer dans les cellules appropriées de la RAM le code de programme qui assure le traitement initial de l'interruption et lance le traitement complet.

Fondamentalement, le système d'exploitation UNIX adopte une approche générale. Dans le vecteur d'interruption correspondant à l'interruption externe, c'est-à-dire interruption d'un périphérique externe, contient des instructions qui définissent le niveau d'exécution du processeur (le niveau d'exécution détermine les interruptions externes auxquelles le processeur doit répondre immédiatement) et passe au gestionnaire d'interruption complet dans le pilote de périphérique approprié. Pour une interruption interne (par exemple, une interruption initiée par le programme utilisateur lorsque la page de mémoire virtuelle requise est manquante dans la mémoire principale, lorsqu'une exception se produit dans le programme utilisateur, etc.) ou une interruption temporisée, le vecteur d'interruption contient un passer au programme correspondant du noyau UNIX.

5. Contrôle des E/S

Traditionnellement, UNIX OS distingue trois types d'organisation des E/S et, par conséquent, trois types de pilotes. Block I/O est principalement destiné à travailler avec des répertoires et des fichiers réguliers du système de fichiers, qui, au niveau de base, ont une structure de blocs. Au niveau de l'utilisateur, il est désormais possible de travailler avec des fichiers en les mappant directement sur des segments de mémoire virtuelle. Cette capacité est considérée comme le niveau supérieur des E/S de bloc. Au niveau inférieur, les E/S de bloc sont prises en charge par les pilotes de bloc. Les E/S de bloc sont également prises en charge par la mise en mémoire tampon du système.

L'entrée/sortie de caractères est utilisée pour les échanges directs (sans mise en mémoire tampon) entre l'espace d'adressage de l'utilisateur et l'équipement correspondant. La prise en charge du noyau commune à tous les pilotes de caractères consiste à fournir des fonctions de transfert de données entre les espaces d'adressage de l'utilisateur et du noyau.

Enfin, les E/S de flux sont similaires aux E/S de caractères, mais en raison de la possibilité d'inclure des modules de traitement intermédiaires dans le flux, elles sont beaucoup plus flexibles.

5.1 Principes de la mise en mémoire tampon des E/S du système

La manière traditionnelle de réduire la surcharge lors de l'exécution d'échanges avec des périphériques de mémoire externes qui ont une structure de bloc est la mise en mémoire tampon d'E/S de bloc. Cela signifie que tout bloc d'un périphérique de mémoire externe est d'abord lu dans un tampon de la zone de mémoire principale, appelé cache système sous UNIX OS, et à partir de là, il est entièrement ou partiellement (selon le type d'échange) copié dans l'espace utilisateur correspondant.

Les principes d'organisation du mécanisme traditionnel de mise en mémoire tampon sont, premièrement, qu'une copie du contenu du bloc est conservée dans la mémoire tampon du système jusqu'à ce qu'il devienne nécessaire de la remplacer en raison d'un manque de mémoires tampons (une variante de l'algorithme LRU est utilisée pour organiser la politique de remplacement). Deuxièmement, lors de l'écriture de n'importe quel bloc d'un dispositif de mémoire externe, seule une mise à jour (ou une formation et un remplissage) du tampon de cache est réellement effectuée. L'échange réel avec le périphérique se fait soit en faisant apparaître le tampon en raison du remplacement de son contenu, soit en émettant un appel système spécial de synchronisation (ou fsync), pris en charge spécifiquement pour pousser de force les tampons de cache mis à jour vers la mémoire externe.

Ce schéma de mise en mémoire tampon traditionnel est entré en conflit avec les outils de gestion de la mémoire virtuelle développés dans les versions modernes du système d'exploitation UNIX, et en particulier avec le mécanisme de mappage des fichiers sur les segments de mémoire virtuelle. Par conséquent, System V Release 4 a introduit un nouveau schéma de mise en mémoire tampon, qui est actuellement utilisé en parallèle avec l'ancien schéma.

L'essence du nouveau schéma est qu'au niveau du noyau, le mécanisme de mappage des fichiers sur les segments de mémoire virtuelle est en fait reproduit. Tout d'abord, rappelez-vous que le noyau UNIX s'exécute effectivement dans sa propre mémoire virtuelle. Cette mémoire a une structure plus complexe, mais fondamentalement la même que la mémoire virtuelle de l'utilisateur. En d'autres termes, la mémoire virtuelle du noyau est une page de segment et, avec la mémoire virtuelle des processus utilisateur, est prise en charge par un sous-système de gestion de mémoire virtuelle commun. Il s'ensuit, deuxièmement, que presque toutes les fonctions fournies par le noyau aux utilisateurs peuvent être fournies par certains composants du noyau à d'autres composants du noyau. En particulier, cela s'applique également à la possibilité de mapper des fichiers sur des segments de mémoire virtuelle.

Le nouveau schéma de mise en mémoire tampon du noyau UNIX est principalement basé sur le fait que vous ne pouvez presque rien faire de spécial pour organiser la mise en mémoire tampon. Lorsqu'un des processus utilisateur ouvre un fichier qui n'a pas été ouvert jusque-là, le noyau forme un nouveau segment et connecte le fichier en cours d'ouverture à ce segment. Après cela (indépendamment du fait que le processus utilisateur travaillera avec le fichier en mode traditionnel en utilisant les appels système de lecture et d'écriture ou connectera le fichier à son segment de mémoire virtuelle), au niveau du noyau, le travail sera effectué avec le segment du noyau auquel le fichier est attaché au niveau des noyaux. L'idée principale de la nouvelle approche est que l'écart entre la gestion de la mémoire virtuelle et la mise en mémoire tampon à l'échelle du système est éliminé (cela aurait dû être fait il y a longtemps, car il est évident que la mise en mémoire tampon principale du système d'exploitation doit être effectuée par le composant de gestion de la mémoire virtuelle).

Pourquoi ne pas abandonner l'ancien mécanisme de mise en mémoire tampon ? Le fait est que le nouveau schéma suppose la présence d'un adressage continu à l'intérieur de l'objet de mémoire externe (il doit y avoir un isomorphisme entre les objets mappés et mappés). Cependant, lors de l'organisation des systèmes de fichiers, UNIX OS est assez difficile à allouer de la mémoire externe, ce qui est particulièrement vrai pour les i-nodes. Par conséquent, certains blocs de mémoire externe doivent être considérés comme isolés, et pour eux, il s'avère plus avantageux d'utiliser l'ancien schéma de mise en mémoire tampon (bien qu'il soit possible dans les futures versions d'UNIX de passer complètement à un nouveau schéma unifié).

5. 2 appels système pour le contrôle des E/S

Pour accéder (c'est-à-dire pour pouvoir effectuer des opérations d'E/S ultérieures) à tout type de fichier (y compris les fichiers spéciaux), un processus utilisateur doit d'abord se connecter au fichier à l'aide de l'un des appels système open, creat, dup ou pipe .

La séquence d'actions de l'appel système open (chemin, mode) est la suivante :

la cohérence des paramètres d'entrée (essentiellement liés aux drapeaux du mode d'accès au fichier) est analysée ;

allouer ou localiser de l'espace pour un descripteur de fichier dans la zone de données de processus système (zone u);

dans la zone à l'échelle du système, l'espace existant est alloué ou localisé pour accueillir le descripteur de fichier système (structure de fichier);

l'archive du système de fichiers est recherchée pour un objet nommé "pathname" et un descripteur de fichier au niveau du système de fichiers (vnode dans les termes UNIX V System 4) est généré ou trouvé ;

le vnode est lié à la structure de fichiers précédemment formée.

Les appels système open et creat sont (presque) fonctionnellement équivalents. Tout fichier existant peut être ouvert avec l'appel système creat, et tout nouveau fichier peut être créé avec l'appel système open. Cependant, en ce qui concerne l'appel système creat, il est important de souligner que, dans son utilisation naturelle (pour créer un fichier), cet appel système crée une nouvelle entrée dans le répertoire correspondant (selon le chemin donné), et crée également et initialise de manière appropriée un nouveau i-node.

Enfin, l'appel système dup (dupliquer - copier) conduit à la formation d'un nouveau descripteur pour un fichier déjà ouvert. Cet appel système spécifique à UNIX est destiné uniquement à la redirection d'E/S.) Son exécution consiste à créer un nouveau descripteur de fichier ouvert dans la région u de l'espace système du processus utilisateur, contenant le descripteur de fichier nouvellement formé (entier), mais se référant à la structure de fichiers déjà existante à l'échelle du système et contenant les mêmes signes et drapeaux qui correspondent au fichier d'échantillon ouvert.

Les autres appels système importants sont les appels système de lecture et d'écriture. L'appel système read est exécuté comme suit :

le descripteur du fichier spécifié est situé dans la table de fichiers à l'échelle du système, et il est déterminé si l'accès depuis le processus donné au fichier donné dans le mode spécifié est légal ;

pendant un certain temps (court), un verrou de synchronisation est posé sur le vnode de ce fichier (le contenu du descripteur ne doit pas changer aux moments critiques de l'opération de lecture) ;

la lecture réelle est effectuée à l'aide de l'ancien ou du nouveau mécanisme de mise en mémoire tampon, après quoi les données sont copiées pour devenir disponibles dans l'espace d'adressage de l'utilisateur.

L'opération d'écriture fonctionne de la même manière, mais modifie le contenu du tampon du pool de mémoire tampon.

L'appel système close amène le pilote à abandonner le processus utilisateur associé et (dans le cas de la fermeture de périphérique la plus récente) définit l'indicateur "pilote libre" à l'échelle du système.

Enfin, un autre appel système ioctl "spécial" est pris en charge pour les fichiers spéciaux. C'est le seul appel système qui est fourni pour les fichiers spéciaux et qui n'est pas fourni pour les autres types de fichiers. En fait, l'appel système ioctl vous permet d'étendre arbitrairement l'interface de n'importe quel pilote. Les paramètres ioctl incluent un opcode et un pointeur vers une zone de la mémoire du processus utilisateur. Toute interprétation de l'opcode et des paramètres spécifiques associés est gérée par le pilote.

Naturellement, étant donné que les pilotes sont principalement conçus pour contrôler des périphériques externes, le code du pilote doit contenir les moyens appropriés pour gérer les interruptions du périphérique. L'appel au gestionnaire d'interruption individuel dans le pilote provient du noyau du système d'exploitation. De même, un pilote peut déclarer une entrée "timeout" à laquelle le noyau accède lorsque le temps précédemment commandé par le pilote expire (un tel contrôle de la synchronisation est nécessaire lors de la gestion de périphériques moins intelligents).

Le schéma général de l'organisation de l'interface des pilotes est illustré à la figure 3.5. Comme le montre cette figure, en termes d'interfaces et de gestion à l'échelle du système, il existe deux types de pilotes - caractère et bloc. Du point de vue de l'organisation interne, un autre type de pilotes se démarque - les pilotes de flux. Cependant, en termes d'interface externe, les pilotes de flux ne diffèrent pas des pilotes de caractères.

6. Interfaces et points d'entrée des conducteurs

6.1 Bloquer les pilotes

Les pilotes de bloc sont conçus pour servir des périphériques externes avec une structure de bloc (disques magnétiques, bandes, etc.) et diffèrent des autres en ce qu'ils sont développés et exécutés à l'aide de la mise en mémoire tampon du système. En d'autres termes, ces pilotes fonctionnent toujours via le pool de mémoire tampon du système. Comme vous pouvez le voir sur la figure 3.5, tout accès en lecture ou en écriture à un pilote de bloc passe toujours par un prétraitement, qui consiste à essayer de trouver une copie du bloc souhaité dans le pool de mémoire tampon.

Si une copie du bloc requis ne se trouve pas dans le pool de tampons ou si, pour une raison quelconque, il est nécessaire de remplacer le contenu d'un tampon mis à jour, le noyau UNIX appelle la procédure de stratégie du pilote de bloc correspondant. Strategy fournit une interface standard entre le noyau et le pilote. Avec l'utilisation de sous-programmes de bibliothèque destinés à l'écriture de pilotes, la procédure de stratégie peut organiser des files d'échanges avec le dispositif, par exemple, afin d'optimiser le déplacement des têtes magnétiques sur le disque. Tous les échanges effectués par le pilote de bloc sont effectués avec la mémoire tampon. La réécriture des informations nécessaires dans la mémoire du processus utilisateur correspondant est effectuée par les programmes du noyau qui gèrent les tampons

6.2 Pilotes de personnage

Les pilotes de caractères sont principalement conçus pour servir des périphériques qui communiquent des chaînes de caractères caractère par caractère ou de longueur variable. Un exemple typique d'un périphérique de caractères est une simple imprimante qui accepte un caractère par échange.

Les pilotes de caractères n'utilisent pas la mise en mémoire tampon du système. Ils copient directement les données de la mémoire du processus utilisateur lors de l'exécution d'opérations d'écriture, ou dans la mémoire du processus utilisateur lors de l'exécution d'opérations de lecture, en utilisant leurs propres tampons.

Il est à noter qu'il est possible de prévoir une interface caractères pour un dispositif bloc. Dans ce cas, le pilote de bloc utilise les fonctionnalités supplémentaires de la procédure de stratégie, ce qui permet d'effectuer l'échange sans utiliser la mise en mémoire tampon du système. Pour un pilote qui possède à la fois des interfaces de bloc et de caractère, deux fichiers spéciaux sont créés dans le système de fichiers, bloc et caractère. A chaque appel, le conducteur reçoit des informations sur le mode dans lequel il est utilisé.

6. 3 pilotes de flux

L'objectif principal du mécanisme de flux est d'augmenter le niveau de modularité et de flexibilité des pilotes avec une logique interne complexe (cela s'applique surtout aux pilotes implémentant des protocoles réseau avancés). La spécificité de ces pilotes est que la majeure partie du code du programme ne dépend pas des fonctionnalités du périphérique matériel. De plus, il est souvent avantageux de combiner des parties du code de programme de différentes manières.

Tout cela a conduit à l'émergence d'une architecture de flux de pilotes, qui est un pipeline bidirectionnel de modules de traitement. Au début du pipeline (le plus proche du processus utilisateur) se trouve l'en-tête de flux, auquel l'utilisateur accède principalement. À la fin du pipeline (le plus proche du périphérique) se trouve le pilote de périphérique normal. Un nombre arbitraire de modules de traitement peuvent être situés dans l'espace, chacun d'eux étant conçu conformément à l'interface de flux requise.

7. Commandes et utilitaires

Lorsqu'ils travaillent de manière interactive dans un environnement UNIX OS, ils utilisent divers utilitaires ou commandes externes du langage shell. Beaucoup de ces utilitaires sont aussi complexes que le shell lui-même (et d'ailleurs, le shell lui-même est l'un des utilitaires que vous pouvez appeler depuis la ligne de commande).

7. 1 Organisation de l'équipe sous UNIX OS

Pour créer une nouvelle commande, il vous suffit de suivre les règles de la programmation C. Tout programme C bien formé commence son exécution par la fonction principale. Cette fonction "semi-système" a une interface standard, qui est la base pour organiser les commandes qui peuvent être appelées dans l'environnement shell. Les commandes externes sont exécutées par l'interpréteur shell à l'aide d'un ensemble d'appels système fork et de l'une des options exec. Les paramètres de l'appel système exec incluent un ensemble de chaînes de texte. Cet ensemble de chaînes de texte est passé en entrée à la fonction principale du programme en cours d'exécution.

Plus précisément, la fonction main prend deux paramètres - argc (le nombre de chaînes de texte à transmettre) et argv (un pointeur vers un tableau de pointeurs vers des chaînes de texte). Un programme prétendant l'utiliser comme une commande shell doit avoir un bien défini interface externe(les paramètres sont généralement entrés à partir du terminal) et doit contrôler et analyser correctement les paramètres d'entrée.

De plus, afin de se conformer au style shell, un tel programme ne devrait pas lui-même remplacer les fichiers correspondant à l'entrée standard, à la sortie standard et à l'erreur standard. La commande peut ensuite être redirigée d'E/S de la manière habituelle et peut être incluse dans des pipelines.

7.2 Redirection d'E/S et tuyauterie

Comme vous pouvez le voir dans la dernière phrase du paragraphe précédent, vous n'avez rien de spécial à faire pour activer la redirection d'E/S et le pipelining lors de la programmation des instructions. Il suffit simplement de laisser les trois descripteurs de fichier initiaux intacts et de travailler correctement avec ces fichiers, à savoir, sortie dans un fichier avec un descripteur stdout, entrer les données du fichier stdin et imprimer les messages d'erreur dans le fichier stderror.

7. 3 commandes intégrées, bibliothèque et utilisateur

Les commandes intégrées font partie du code du programme shell. Ils s'exécutent comme des sous-programmes d'interprétation et ne peuvent pas être remplacés ou redéfinis. La syntaxe et la sémantique des commandes intégrées sont définies dans le langage de commande correspondant.

Les commandes de bibliothèque font partie du logiciel système. Il s'agit d'un ensemble de programmes exécutables (utilitaires) fournis avec le système d'exploitation. La plupart de ces programmes (tels que vi, emacs, grep, find, make, etc.) sont extrêmement utiles dans la pratique, mais leur discussion dépasse le cadre de ce cours (il existe des livres épais séparés).

Une commande utilisateur est tout programme exécutable organisé conformément aux exigences énoncées dans. Ainsi, tout utilisateur UNIX OS peut étendre indéfiniment le répertoire de commandes externes de son langage de commande (par exemple, vous pouvez écrire votre propre interpréteur de commandes).

7.4 Programmation en langage de commande

Chacune des variantes mentionnées du langage shell peut, en principe, être utilisée comme langage de programmation. Parmi les utilisateurs d'UNIX, il y a beaucoup de gens qui écrivent des programmes assez sérieux sur le shell. Pour la programmation, il est préférable d'utiliser des langages de programmation (C, C++, Pascal, etc.) plutôt que des langages de commande.


8. Outils d'interface graphique

Bien que de nombreux programmeurs UNIX professionnels préfèrent aujourd'hui utiliser les moyens traditionnels d'interaction avec le système basés sur des lignes, l'utilisation généralisée de terminaux graphiques couleur haute résolution relativement peu coûteux a conduit au fait que toutes les versions modernes du système d'exploitation UNIX prennent en charge les utilisateurs graphiques. interfaces avec le système, et les utilisateurs disposent d'outils pour développer des interfaces graphiques avec les programmes qu'ils développent. Du point de vue de l'utilisateur final, les outils d'interface graphique pris en charge dans diverses versions du système d'exploitation UNIX et dans d'autres systèmes (par exemple, MS Windows ou Windows NT) sont approximativement de même style.

Premièrement, dans tous les cas, un mode de fonctionnement multi-fenêtres avec un écran de terminal est supporté. A tout moment, l'utilisateur peut créer une nouvelle fenêtre et l'associer au programme souhaité qui fonctionne avec cette fenêtre comme avec un terminal séparé. Les fenêtres peuvent être déplacées, redimensionnées, temporairement fermées, etc.

Deuxièmement, dans toutes les variétés modernes de l'interface graphique, le contrôle de la souris est pris en charge. Dans le cas d'UNIX, il s'avère souvent que le clavier de terminal normal n'est utilisé que lors du passage à l'interface de ligne traditionnelle (bien que dans la plupart des cas, au moins une fenêtre de terminal exécute l'un des shells de la famille de shell).

Troisièmement, une telle diffusion du style de travail "souris" est possible grâce à l'utilisation d'outils d'interface basés sur des pictogrammes (icônes) et des menus. Dans la plupart des cas, un programme s'exécutant dans une certaine fenêtre invite l'utilisateur à sélectionner une fonction à exécuter par celui-ci, soit en affichant un ensemble d'images symboliques de fonctions possibles (icônes) dans la fenêtre, soit en proposant un menu à plusieurs niveaux. . Dans tous les cas, pour une sélection ultérieure, il suffit de contrôler le curseur de la fenêtre correspondante avec la souris.

Enfin, les interfaces graphiques modernes sont "conviviales", offrant la possibilité d'obtenir immédiatement une aide interactive en toute occasion. (Peut-être serait-il plus exact de dire qu'un bon style de programmation d'interface graphique est celui qui fournit réellement de tels conseils.)

Après avoir énuméré toutes ces propriétés générales des outils GUI modernes, une question naturelle peut se poser : s'il existe une telle uniformité dans le domaine des interfaces graphiques, qu'est-ce qui est particulier aux interfaces graphiques dans l'environnement UNIX ? La réponse est assez simple. Oui, l'utilisateur final dans n'importe quel système d'aujourd'hui traite à peu près le même ensemble de fonctionnalités d'interface, mais dans différents systèmes, ces fonctionnalités sont réalisées de différentes manières. Comme d'habitude, l'avantage d'UNIX est la disponibilité de technologies standardisées qui permettent de créer des applications mobiles avec des interfaces graphiques.

8. Principes de protection

Depuis que le système d'exploitation UNIX a été conçu dès sa création comme un système d'exploitation multi-utilisateurs, le problème de l'autorisation d'accès de différents utilisateurs aux fichiers du système de fichiers a toujours été d'actualité. L'autorisation d'accès fait référence aux actions du système qui autorisent ou refusent à un utilisateur donné l'accès à un fichier donné, en fonction des droits d'accès de l'utilisateur et des restrictions d'accès définies pour le fichier. Le schéma d'autorisation d'accès utilisé dans le système d'exploitation UNIX est si simple et pratique et en même temps si puissant qu'il est devenu la norme de facto des systèmes d'exploitation modernes (qui ne prétendent pas être des systèmes à protection à plusieurs niveaux).

8.1 ID utilisateur et groupes d'utilisateurs

Chaque processus en cours d'exécution sous UNIX est associé à un ID utilisateur réel, un ID utilisateur effectif et un ID utilisateur enregistré. Tous ces identifiants sont définis à l'aide de l'appel système setuid, qui ne peut être exécuté qu'en mode superutilisateur. De même, chaque processus est associé à trois ID de groupe d'utilisateurs : ID de groupe réel, ID de groupe effectif et ID de groupe enregistré. Ces identifiants sont définis par l'appel système privilégié setgid.

Lorsqu'un utilisateur se connecte au système, le programme de connexion vérifie que l'utilisateur est connecté et connaît le mot de passe correct (le cas échéant), crée un nouveau processus et démarre le shell requis pour cet utilisateur. Mais avant cela, login définit les identifiants d'utilisateur et de groupe pour le processus nouvellement créé à l'aide des informations stockées dans les fichiers /etc/passwd et /etc/group. Une fois que les ID d'utilisateur et de groupe sont associés à un processus, les restrictions d'accès aux fichiers s'appliquent à ce processus. Un processus peut accéder ou exécuter un fichier (si le fichier contient un programme exécutable) uniquement si les restrictions d'accès du fichier le lui permettent. Les identifiants associés à un processus sont passés aux processus qu'il crée, soumis aux mêmes restrictions. Cependant, dans certains cas, un processus peut modifier ses autorisations à l'aide des appels système setuid et setgid, et parfois le système peut modifier automatiquement les autorisations d'un processus.

Considérons, par exemple, la situation suivante. Le fichier /etc/passwd n'est accessible en écriture à personne sauf au superutilisateur (le superutilisateur peut écrire dans n'importe quel fichier). Ce fichier contient, entre autres, les mots de passe des utilisateurs et chaque utilisateur est autorisé à modifier son mot de passe. Disponible programme spécial/bin/passwd, qui change les mots de passe. Cependant, l'utilisateur ne peut pas le faire même avec ce programme, car le fichier /etc/passwd n'est pas autorisé à être écrit. Sur un système UNIX, ce problème est résolu comme suit. Un fichier exécutable peut spécifier que lors de son exécution, des identifiants d'utilisateur et/ou de groupe doivent être définis. Si un utilisateur demande l'exécution d'un tel programme (en utilisant l'appel système exec), alors l'ID utilisateur du processus correspondant est défini sur celui du propriétaire de l'exécutable et/ou sur l'ID de groupe de ce propriétaire. En particulier, lorsque le programme /bin/passwd est exécuté, le processus aura un identifiant racine et le programme pourra écrire dans le fichier /etc/passwd.

Pour l'ID utilisateur et l'ID de groupe, l'ID réel est l'ID véritable et l'ID effectif est l'ID de l'exécution en cours. Si l'ID utilisateur actuel correspond au superutilisateur, cet ID et l'ID de groupe peuvent être réinitialisés à n'importe quelle valeur avec les appels système setuid et setgid. Si l'ID utilisateur actuel est différent de l'ID superutilisateur, l'exécution des appels système setuid et setgid entraîne le remplacement de l'ID actuel par le véritable ID (utilisateur ou groupe, respectivement).

8.2 Protection des fichiers

Comme il est d'usage dans un système d'exploitation multi-utilisateurs, UNIX maintient un mécanisme uniforme pour contrôler l'accès aux fichiers et aux répertoires du système de fichiers. Tout processus peut accéder à un certain fichier si et seulement si les droits d'accès décrits avec le fichier correspondent aux capacités de ce processus.

La protection des fichiers contre les accès non autorisés sous UNIX repose sur trois faits. Tout d'abord, tout processus qui crée un fichier (ou un répertoire) est associé à un identifiant d'utilisateur unique (UID - User Identifier) ​​​​dans le système, qui peut en outre être traité comme l'identifiant du propriétaire du fichier nouvellement créé. Deuxièmement, chaque processus tentant d'accéder à un fichier est associé à une paire d'identifiants, l'utilisateur courant et les identifiants de groupe. Troisièmement, chaque fichier correspond de manière unique à son descripteur - i-node.

Tout i-node utilisé dans le système de fichiers correspond toujours de manière unique à un et un seul fichier. Le nœud I contient pas mal d'informations différentes (la plupart d'entre elles sont disponibles pour les utilisateurs via les appels système stat et fstat), et parmi ces informations, il y a une partie qui permet au système de fichiers d'évaluer les droits d'accès d'un processus donné à un fichier donné dans le mode requis.

Les principes généraux de protection sont les mêmes pour toutes les variantes existantes du système : les informations de l'i-node incluent l'UID et le GID du propriétaire actuel du fichier (immédiatement après la création du fichier, les identifiants de son propriétaire actuel sont définis sur identifiant courant correspondant du processus créateur, mais pouvant être modifié ultérieurement par les appels système chown et chgrp) . De plus, l'i-node du fichier contient une échelle qui indique ce que l'utilisateur - son propriétaire peut faire avec le fichier, ce que les utilisateurs appartenant au même groupe d'utilisateurs que le propriétaire peuvent faire avec le fichier et ce que les autres peuvent faire avec les utilisateurs du fichier. Les petits détails de mise en œuvre dans les différentes versions du système diffèrent.

8.3 Futurs systèmes d'exploitation prenant en charge l'environnement UNIX OS

Un micro-noyau est la plus petite partie centrale d'un système d'exploitation, servant de base aux extensions modulaires et portables. Il semble que la plupart des systèmes d'exploitation de nouvelle génération auront des micro-noyaux. Cependant, il existe de nombreuses opinions différentes sur la manière dont les services du système d'exploitation doivent être organisés en relation avec le micro-noyau : comment concevoir des pilotes de périphérique aussi efficaces que possible, tout en gardant les fonctions du pilote aussi indépendantes que possible du matériel ; si les opérations non liées au noyau doivent être effectuées dans l'espace noyau ou dans l'espace utilisateur ; s'il vaut la peine de conserver les programmes des sous-systèmes existants (par exemple, UNIX) ou vaut-il mieux tout jeter et recommencer à zéro.

Le concept de micro-noyau a été largement utilisé par Next, dont le système d'exploitation utilisait le micro-noyau Mach. Le petit noyau privilégié de ce système d'exploitation, autour duquel tournaient des sous-systèmes en mode utilisateur, était théoriquement censé offrir une flexibilité et une modularité sans précédent du système. Mais en pratique, cet avantage a été quelque peu réduit par la présence d'un serveur monolithique qui implémente le système d'exploitation UNIX BSD 4.3, que Next a choisi pour envelopper le micro-noyau Mach. Cependant, le recours à Mach a permis d'inclure dans le système des outils de messagerie et un certain nombre de fonctions de service orientées objet, sur la base desquelles il a été possible de créer une interface utilisateur élégante avec des outils graphiques pour la configuration du réseau, l'administration du système et le développement de logiciels.

Le prochain système d'exploitation à micro-noyau était Windows NT de Microsoft, où le principal avantage de l'utilisation d'un micro-noyau était non seulement la modularité mais aussi la portabilité. (Notez qu'il n'y a pas de consensus sur la question de savoir si NT doit réellement être considéré comme un système d'exploitation à micro-noyau.) NT a été conçu pour être utilisé sur des systèmes monoprocesseurs et multiprocesseurs basés sur Processeurs Intel, Mips et Alpha (et ceux qui viennent après eux). Étant donné que les programmes écrits pour les systèmes compatibles DOS, Windows, OS / 2 et Posix devaient s'exécuter sur NT, Microsoft a utilisé la modularité inhérente à l'approche du micro-noyau pour créer une structure NT globale qui n'imitait aucun système d'exploitation existant. Chaque système d'exploitation est émulé en tant que module ou sous-système distinct.

Plus récemment, des architectures de système d'exploitation à micro-noyau ont été annoncées par Novell/USL, l'Open Software Foundation (OSF), IBM, Apple et d'autres. L'un des principaux concurrents de NT dans les systèmes d'exploitation à micro-noyau est Mach 3.0, un système créé à l'Université Carnegie Mellon qu'IBM et OSF ont entrepris de commercialiser. (Next utilise actuellement Mach 2.5 comme base pour NextStep, mais étudie également de près Mach 3.0.) Un autre concurrent est le micro-noyau Chorus 3.0 de Chorus Systems, choisi par USL comme base pour les nouvelles implémentations UNIX. Certains micro-noyaux seront utilisés dans SpringOS de Sun, le successeur orienté objet de Solaris (si, bien sûr, Sun complète SpringOS). Il y a une tendance évidente à passer des systèmes monolithiques aux systèmes micro-noyaux (ce processus n'est pas simple : IBM a pris du recul et a abandonné la transition vers la technologie micro-noyau). Soit dit en passant, ce n'est pas du tout une nouveauté pour QNX Software Systems et Unisys, qui publient des systèmes d'exploitation à micro-noyau à succès depuis plusieurs années. Le système d'exploitation QNX est en demande sur le marché du temps réel et le CTOS d'Unisys est populaire dans le secteur bancaire. Les deux systèmes utilisent avec succès la modularité inhérente aux systèmes d'exploitation à micro-noyau.


Conclusion

Les principales différences entre Unix et les autres systèmes d'exploitation

Unix se compose d'un noyau avec des pilotes et des utilitaires inclus (programmes externes au noyau). Si vous devez modifier la configuration (ajouter un périphérique, modifier un port ou une interruption), le noyau est reconstruit (relié) à partir de modules objets ou (par exemple, dans FreeBSD) à partir de sources. Ce n'est pas tout à fait vrai. Certains paramètres peuvent être corrigés sans reconstruction. Il existe également des modules de noyau chargeables.

Contrairement à Unix, sous Windows (si on ne précise pas lequel, alors on entend 3.11, 95 et NT) et OS/2, lors du chargement, ils relient en fait les pilotes en déplacement. noyau assemblé et la réutilisation du code commun sont d'un ordre de grandeur inférieur à De plus, si la configuration du système est inchangée, le noyau Unix peut être écrit en ROM et exécuté _non_amorcé_ en RAM sans retravail (il vous suffit de changer la partie de départ de le BIOS) La compacité du code est particulièrement importante, car le noyau et les pilotes ne quittent jamais la mémoire physique n'est pas permutée sur le disque.

Unix est le système d'exploitation le plus multiplateforme. WindowsNT essaie de l'imiter, mais jusqu'à présent, cela n'a pas réussi - après avoir abandonné MIPS et POWER-PC, W "NT n'est resté que sur deux plates-formes - le traditionnel i * 86 et DEC Alpha. Portabilité des programmes d'une version d'Unix Un programme écrit de manière bâclée, qui ne prend pas en compte les différences dans les implémentations Unix, fait des hypothèses déraisonnables comme "l'entier doit être long de quatre octets" peut nécessiter une refonte majeure, mais c'est toujours beaucoup plus facile que le portage à partir de OS/2 vers NT, par exemple.

Applications d'Unix

Unix est utilisé à la fois comme serveur et comme poste de travail. Dans la nomination des serveurs, MS WindowsNT, Novell Netware, IBM OS/2 Warp Connect, DEC VMS et les systèmes d'exploitation mainframe lui font concurrence. Chaque système a son propre domaine d'application dans lequel il est meilleur que les autres.

WindowsNT est destiné aux administrateurs qui préfèrent une interface conviviale aux économies de ressources et aux hautes performances.

Netware - pour les réseaux où des services de fichiers et d'imprimantes hautes performances sont nécessaires et où d'autres services ne sont pas si importants. Le principal inconvénient est qu'il est difficile d'exécuter des applications sur un serveur Netware.

OS / 2 est bon là où vous avez besoin d'un serveur d'application "léger". Il nécessite moins de ressources que NT, est plus souple dans la gestion (bien qu'il puisse être plus difficile à mettre en place), et le multitâche est très bon. L'autorisation et la différenciation des droits d'accès ne sont pas implémentées au niveau du système d'exploitation, ce qui est plus que payant par une implémentation au niveau des serveurs d'application. (Cependant, souvent d'autres systèmes d'exploitation font de même). De nombreuses stations FIDOnet et BBS sont basées sur OS/2.

VMS est un serveur d'applications puissant, en aucun cas inférieur au serveur d'applications d'Unix (et à bien des égards supérieur à celui-ci), mais uniquement pour les plates-formes VAX et Alpha de DEC.

Mainframes - pour servir un très grand nombre d'utilisateurs (de l'ordre de plusieurs milliers). Mais le travail de ces utilisateurs est généralement organisé sous la forme non pas d'une interaction client-serveur, mais sous la forme d'une interaction hôte-terminal. Le terminal de cette paire n'est pas un client, mais un serveur (Internet World, N3 pour 1996). Les avantages des mainframes incluent une sécurité et une tolérance aux pannes plus élevées, et les inconvénients sont le prix correspondant à ces qualités.

Unix est bon pour l'administrateur qualifié (ou désireux de l'être), car nécessite la connaissance des principes de fonctionnement des processus qui s'y déroulent. Le multitâche réel et le partage de la mémoire matérielle offrent une grande fiabilité du système, bien que les performances des services de fichiers et d'impression Unix soient inférieures à celles de Netware.

Le manque de flexibilité dans l'octroi des droits d'accès aux fichiers par rapport à Windows NT rend difficile l'organisation _au_niveau_du_système_de_fichiers_ de groupes d'accès aux données (plus précisément aux fichiers), ce qui, à mon avis, est compensé par la facilité de mise en œuvre, ce qui signifie moins de matériel conditions. Cependant, des applications telles que SQL Server résolvent elles-mêmes le problème de l'accès de groupe aux données, de sorte que l'absence de capacité Unix à refuser l'accès à un _fichier_ à un utilisateur spécifique, à mon avis, est clairement redondante.

Presque tous les protocoles sur lesquels repose Internet ont été développés sous Unix, en particulier la pile de protocoles TCP/IP a été inventée à l'université de Berkeley.

La sécurité d'Unix, lorsqu'elle est correctement administrée (et quand elle ne l'est pas ?), n'est en aucun cas inférieure à celle de Novell ou de Windows NT.

Une caractéristique importante d'Unix qui le rapproche des mainframes est sa multi-terminalité, de nombreux utilisateurs peuvent exécuter simultanément des programmes sur la même machine Unix. Si vous n'avez pas besoin d'utiliser des graphiques, vous pouvez vous débrouiller avec des terminaux texte bon marché (spécialisés ou basés sur PC bon marché) connectés sur des lignes lentes. En cela, seul le VMS lui fait concurrence. Les terminaux graphiques X peuvent également être utilisés lorsque des fenêtres de processus s'exécutant sur différentes machines sont présentes sur le même écran.

Dans la nomination des stations de travail, Unix est en concurrence avec MS Windows*, IBM OS/2, Macintosh et Acorn RISC-OS.

Windows - pour ceux qui privilégient la compatibilité à l'efficacité ; pour ceux qui sont prêts à acheter une grande quantité de mémoire, d'espace disque et de mégahertz ; pour ceux qui aiment ne pas plonger dans l'essentiel, cliquez sur les boutons de la fenêtre. Certes, tôt ou tard, vous devrez encore étudier les principes du système et des protocoles, mais il sera alors trop tard - le choix a été fait. Un avantage important de Windows doit également être reconnu comme la capacité de voler un tas de logiciels.

OS/2 - pour les fans d'OS/2. :-) Bien que, selon certains rapports, OS / 2 interagisse mieux que d'autres avec les mainframes et les réseaux IBM.

Macintosh - pour les œuvres graphiques, éditoriales et musicales, ainsi que pour ceux qui aiment une interface claire et belle et ne veulent pas (ne peuvent pas) comprendre les détails du système.

RISC-OS, flashé en ROM, permet de ne pas perdre de temps à installer le système d'exploitation et à le restaurer après des pannes. De plus, presque tous les programmes qui en dépendent utilisent les ressources de manière très économique, ils n'ont donc pas besoin d'être échangés et fonctionnent très rapidement.

Unix fonctionne à la fois sur des PC et sur des stations de travail puissantes avec des processeurs RISC, des systèmes de CAO et des systèmes d'information géographique vraiment puissants sont écrits sous Unix. L'évolutivité d'Unix en raison de sa nature multiplateforme est d'un ordre de grandeur supérieur à tout autre système d'exploitation, selon certains auteurs.


Bibliographie

1. Manuel Kuznetsova S.D. "Système d'exploitation UNIX" 2003 ;

2. Polyakov A.D. « UNIX 5e édition sur x86, ou n'oubliez pas l'histoire » ;

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

4. Fedorchuk A.V. Maîtrise Unix, 2006

5. Matériaux du site http://www.citforum.ru/operating_systems/1-16 ;

MINISTÈRE DE L'ÉDUCATION ET DES SCIENCES DE LA FÉDÉRATION DE RUSSIE AGENCE FÉDÉRALE POUR L'ÉDUCATION ÉTABLISSEMENT D'ÉTAT D'ENSEIGNEMENT PROFESSIONNEL SUPÉRIEUR
mob_info