259 lines
11 KiB
XML
259 lines
11 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE html
|
||
PUBLIC "-//ENS/Tuteurs//DTD TML 1//EN"
|
||
"tuteurs://DTD/tml.dtd">
|
||
<html>
|
||
<head>
|
||
<title>Machines Unix</title>
|
||
</head>
|
||
<body>
|
||
|
||
<h1>Présentation technique des machines Unix</h1>
|
||
|
||
<p>Le contenu de cette page est assez aride, mis à part pour les deux
|
||
premiers paragraphes, et nettement plus difficile à comprendre que le
|
||
reste de cette documentation. Si vous êtes néophyte en informatique,
|
||
lisez plutôt notre <a href="prelude.html">page d'introduction</a> à
|
||
Unix.</p>
|
||
|
||
|
||
<h2>Qu'est-ce qu'une station Sun ?</h2>
|
||
|
||
<p>Sun Microsystems est un fabricant américain d'ordinateurs, qui
|
||
vend(ait) les ordinateurs qui équipaient l'ENS il y a quelques années.
|
||
Le mot « station » est une abréviation de « station de travail », un
|
||
vieux vocable désignant les machines reliées en réseau et disposant
|
||
d'une puissance de calcul propre (différant en cela des <a
|
||
href="&url.jargon;#xterm">terminaux</a>).</p>
|
||
|
||
|
||
<h2>Qu'est-ce qu'Unix ?</h2>
|
||
|
||
<p>Unix est le nom générique d'un certain type de systèmes
|
||
d'exploitation pour machines haut de gamme. <a href="histoire.html">Pour
|
||
des raisons historiques</a>, ces machines se regroupent en (en gros)
|
||
deux catégories, System V et BSD. La version qui tourne sur les stations
|
||
Sun de l'ENS s'appelle Solaris, c'est un System V. La plupart des PC de
|
||
l'ENS tournent sous Fedora, une distribution Linux. Ce n'est pas à
|
||
proprement parler un Unix (il n'appartient à aucune des deux familles
|
||
BSD et SystemV), mais son fonctionnement est très voisin de celui
|
||
d'Unix. La présence de deux systèmes différents explique les petites
|
||
différences de comportement que vous pouvez observer entre les stations
|
||
Sun et les PC FreeBSD.</p>
|
||
|
||
<p>Unix est sans conteste le système préféré des informaticiens de l'ENS.
|
||
Veuillez donc m'excuser d'être partial dans les questions qui vont
|
||
suivre...</p>
|
||
|
||
|
||
<h2>Pourquoi Unix est-il meilleur que MS-DOS et MacOS ?</h2>
|
||
|
||
<ul><li><strong>Multitâche :</strong> une machine Unix peut lancer
|
||
plusieurs programmes à la fois, et ce avec une efficacité inconnue
|
||
sous les systèmes d'exploitation susmentionnés. Ceux-ci sont en effet
|
||
incapables de faire autre chose pendant qu'ils accèdent à leurs
|
||
périphériques (par exemple, pour écrire ou lire sur le disque dur), et
|
||
perdent donc le plus clair de leur temps à attendre. Il est tout à
|
||
fait possible sous Unix de rédiger un mémoire dans une fenêtre avec
|
||
quatre versions de brouillon tout autour, et ce pendant qu'un gros
|
||
fichier se télécharge...</li>
|
||
|
||
<li><strong>Multi-utilisateurs :</strong> une station Unix peut servir
|
||
plusieurs utilisateurs en même temps, et les protéger les uns des
|
||
autres au moyen des <a href="loguer.html">mots de passe</a> et de <a
|
||
href="&url.tuteurs;unix/droits.html">droits d'accès</a>. Personne ne
|
||
peut lire votre courrier électronique à votre place, et si vous
|
||
désirez garder confidentiel un document, c'est possible !</li>
|
||
|
||
<li><strong>Protection mémoire :</strong> aucun programme ne peut
|
||
faire planter le système ; si il tente d'effectuer une opération qui
|
||
devrait avoir ce résultat, il sera terminé de force, sans conséquences
|
||
pour le reste du système. L'allégation que Windows ou Mac OS possèdent
|
||
cette qualité est une plaisanterie.</li>
|
||
|
||
<li><strong>Sécurité :</strong> en règle générale, le système n'est
|
||
pas prévu pour respecter les impératifs ci-dessus dans la plupart des
|
||
cas, mais dans tous les cas, si bien que faire planter l'ordinateur ou
|
||
contourner les protections est un véritable challenge (même si ce
|
||
n'est malheureusement pas impossible). De plus, la découverte d'un tel
|
||
« trou de sécurité » occasionne une réaction consciencieuse de la part
|
||
du vendeur du système d'exploitation, qui fournit continuellement de
|
||
nouvelles versions pour que l'administrateur système ait toujours une
|
||
longueur d'avance sur le pirate. On ne peut certes pas en dire autant
|
||
de Microsoft ni Apple...</li>
|
||
|
||
<li><strong>Fiabilité :</strong> <code>clipper</code>, le serveur des
|
||
élèves, point névralgique du résdeau de l'École, ne réamorce en
|
||
moyenne qu'une fois tous les trois mois (et pour faire des opérations
|
||
de maintenance, rajouter des disques durs, etc.) ! Cela permet de
|
||
faire de très longs calculs sur plusieurs semaines, ou bien de faire
|
||
de nuit de grosses opérations réseau.</li>
|
||
|
||
<li><strong>Fonctionnalité :</strong> toutes les stations Sun et les
|
||
PC sous FreeBSD gèrent le réseau dans les deux sens. On peut s'y
|
||
connecter à distance, on peut lancer un programme sur une machine et
|
||
avoir l'affichage sur une autre, etc. Unix fournit toujours au
|
||
programmeur plus de possibilités que sur tout autre système, toutes
|
||
choses égales par ailleurs (c'est-à-dire sans acheter de kit de
|
||
développement supplémentaire) : il existe des compilateurs gratuits et
|
||
la rétention d'information n'y est pas de mise.</li>
|
||
|
||
<li><strong>Configurabilité :</strong> le système Unix est construit
|
||
pour avoir le moins possible de présupposés du genre « les extensions
|
||
système sont toutes dans le dossier du même nom » (respectivement,
|
||
« dans <code>C:\WINDOWS\SYSTEM</code> »). C'est pourquoi Unix est
|
||
extrêmement configurable et s'adapte à tous types d'environnement, de
|
||
la plus petite à la plus grosse des machines, avec ou sans réseau, et
|
||
quelle que soit la marque de l'ordinateur considéré.</li>
|
||
|
||
<li><strong>Portabilité :</strong> les différents constructeurs d'Unix
|
||
se sont mis d'accord depuis longtemps sur toutes les normes utiles à
|
||
leur travail. La conséquence est qu'un programme écrit pour <a
|
||
href="&url.jargon;#sunos">SunOS</a> tournera sans aucune modification
|
||
sous <a href="&url.jargon;#solaris">Solaris</a>.</li></ul>
|
||
|
||
|
||
<h2>Quels inconvénients à Unix ?</h2>
|
||
|
||
<p>Bon, soyons vraiment honnêtes : la qualité d'Unix se traduit par un
|
||
aspect spartiate décourageant, et il est vrai que la sécurité coûte un
|
||
peu en performances (mais la puissance correspondante est de toute
|
||
façon perdue sous Windows 95 ou MacOS). Pourtant, si autant d'efforts
|
||
avaient été consacrés à l'aspect extérieur d'Unix qu'il y en eut pour
|
||
Windows et le Système 7, nul doute qu'il les ridiculiserait
|
||
aujourd'hui sur tous les tableaux ! Mais programmer des interfaces
|
||
utilisateur est un travail long et peu passionnant (c'est toujours la
|
||
même chose), et l'histoire d'Unix est surtout faite de programmeurs
|
||
bénévoles.</p>
|
||
|
||
<p>Depuis plusieurs années, avec le développement de Linux et son
|
||
ouverture au grand public, des interfaces graphiques se développent;
|
||
citons en particulier KDE (dont une partie des logiciels sont
|
||
installés sur les stations), Gnome, etc. Unix ne se traduit plus
|
||
forcément par « interface fruste »...</p>
|
||
|
||
|
||
<h2>Pourquoi les stations Unix ont-elles des noms ?</h2>
|
||
|
||
<p>Parce qu'il est plus facile de dire « trimaran » que « la station
|
||
Sun 4 située à gauche le mur Sud de la salle S ». Il est également
|
||
plus facile de dire « trimaran » que « la station trimaran » (ou même
|
||
pire, « la station 42 »), ce qui conduit à une personnalisation
|
||
affectueuse (certains diront lobotomique) des machines par les
|
||
habitués...</p>
|
||
|
||
<p>Quoi qu'il en soit, les machines administrées par le SPI sont
|
||
repérables au fait qu'elles ont un nom de bateau ; parmi elles,
|
||
<code>clipper</code> est le serveur des élèves à Ulm (il est dans une
|
||
salle du niveau -2 du DI climatisée et inaccessible au commun des
|
||
mortels) ; <code>vedette</code> est le serveur de Jourdan ;
|
||
<code>paquebot</code> est le serveur de Montrouge.</p>
|
||
|
||
<p>Les autres groupements de machines respectent également l'unité de
|
||
noms : ainsi, les machines du DMI ont un nom de végétal ou de
|
||
champignon, dont l'embranchement caractérise le bâtiment et l'étage, et
|
||
les machines des biologistes ont des noms de dieux (<code>horus</code>
|
||
est leur serveur).</p>
|
||
|
||
<p>Pour connaître le nom d'une machine dans une salle d'informatique
|
||
élèves, il y a deux méthodes :</p>
|
||
|
||
<ul><li>Sur la mire de login, la machine <code>steamer</code> (par
|
||
exemple) affiche <code>steamer login:</code> (c'est le cas le plus
|
||
simple). Et pour un utilisateur de la config conscrits, le nom de sa
|
||
machine apparaît dans l'invite de ses fenêtres de terminal une fois qu'il
|
||
est logué ; par exemple :</li></ul>
|
||
|
||
<pre>
|
||
<span class="prompt">steamer ~ $</span>
|
||
</pre>
|
||
|
||
<ul><li>Vous pouvez obtenir un plan de salle avec la commande <a
|
||
href="&url.tuteurs;unix/communiquer.html#qui"><code>qui</code></a> :</li></ul>
|
||
|
||
<table class="tableau">
|
||
<tr>
|
||
<td><code>qui</code></td>
|
||
<td>Salle S</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>qui t</code></td>
|
||
<td>Salle T</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>qui i</code></td>
|
||
<td>Infi</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>qui j</code></td>
|
||
<td>Salle de Jourdan</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>qui m</code></td>
|
||
<td>Salle de Montrouge</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>qui p</code></td>
|
||
<td>Salle des physiciens</td>
|
||
</tr>
|
||
|
||
</table>
|
||
|
||
|
||
<h2><a name="root">Qu'est-ce que <code>root</code> ?</a></h2>
|
||
|
||
<p><code>root</code> est le nom de login traditionnel de l'administrateur
|
||
système. Il a tous les droits, c'est-à-dire qu'aucune opération ne lui
|
||
sera refusée sous prétexte qu'elle outrepasse la limite de l'utilisateur
|
||
<code>root</code> (par contre, il est toujours sous le coup de la
|
||
protection contre le plantage par exemple). Il peut donc lire votre
|
||
courrier électronique, savoir quels programmes vous avez utilisés,
|
||
suspendre ou fermer votre compte, etc. Ces droits sont nécessaires à
|
||
assurer le fonctionnement du système : que feriez-vous sinon lorsque vous
|
||
oubliez votre mot de passe ?</p>
|
||
|
||
<p>Mais à l'ENS, les administrateurs sont intègres et dignes de confiance
|
||
et ne se servent presque jamais de ce droit de « super-utilisateur » :
|
||
même si votre boîte aux lettres électronique déborde, l'administrateur en
|
||
fait une copie chez vous et ne regarde pas dedans (le cas s'est déjà
|
||
présenté).</p>
|
||
|
||
<p>« Devenir root » est un fantasme courant d'une certaine frange de la
|
||
population de la salle S, parce que c'est interdit et théoriquement
|
||
impossible (donc tentant) et que les informaticiens se divisent en deux
|
||
sous-castes : ceux qui savent passer root sans y être autorisés et les
|
||
autres... C'est la raison d'être de la banderole en salle S. N'oubliez
|
||
jamais que Jacques Beigbeder n'est pas un imbécile, et que si vous vous
|
||
faites prendre la sanction sera très lourde...</p>
|
||
|
||
|
||
<h2>Peut-on détourner la table d'interruptions ?</h2>
|
||
|
||
<p>Non (sur les Suns, on appelle cela la <em>trap table</em>). La
|
||
philosophie même du système d'exploitation Unix fait que pour garantir
|
||
la sécurité et la disponibilité de la machine, il doit absolument
|
||
interdire quiconque de prendre le contrôle exclusif d'un élément
|
||
matériel. Même l'administrateur système n'a pas ce pouvoir, à moins de
|
||
modifier Unix lui-même.</p>
|
||
|
||
<p>De toute façon, dans la pratique on n'a jamais besoin de le faire :
|
||
sous réserve que vous en ayez le droit, vous avez toujours moyen de
|
||
faire ce que vous voulez en programmation Unix sans avoir à réinventer
|
||
la roue à la place d'un incompétent qui aurait dû le faire pour vous
|
||
comme c'est le cas sur un PC sous DOS.</p>
|
||
|
||
<p>Les copyrights de divers noms cités ici se trouvent <a
|
||
href="copyright.html">là-bas</a>.</p>
|
||
|
||
<div class="metainformation"> Auteurs : Dominique Quatravaux (1998),
|
||
François-Xavier Coudert (2002). Mise à jour : Marc Mezzarobba.
|
||
<date value="from git" />
|
||
</div>
|
||
|
||
</body>
|
||
</html>
|