Huit concepts qu'il faudrait faire connaître aux utilisateurs Windows
Si vous avez un ordinateur avec accès au Web, il y a environ 95.6%
de chances pour que celui-ci fonctionne avec une version de Windows
(Windows XP représente à lui tout seul plus de 85%). Or, si le système
d'exploitation de Microsoft domine de loin le marché des ordinateurs
familiaux (alors qu'il n'est que challenger du marché des serveurs),
il y a pourtant bon nombre d'idées que l'on trouve assez peu chez lui
comparé à d'autres systèmes. Ce sont des outils, des concepts, dont
l'usage est moins courant sous Windows qu'ailleurs, ou qui, en tout cas,
sont plus mis en valeur chez les concurrents de la firme de Redmond
(et notamment les systèmes libres dérivés d'Unix, comme Linux). Non
pas que Windows n'en soit pas techniquement capable, ni qu'il faille un
niveau élevé de compétence en informatique pour les mettre en jeu. Ce
sont juste des concepts que l'utilisateur Windows n'a probablement pas
entendu, et qui, quand il en entend parler, déclenchent en général
une réaction de surprise se manifestant par un regard étonné et une
remarque du genre : « Je savais pas que ça existait déjà, ce truc ! »
Système de contrôle de versions
Sous ce nom barbare se cachent des outils destinés à répondre à deux
problèmes simples et en fait liés :
- Comment suivre les modifications apportés à mes fichiers au cours
du temps ?
- Comment faire collaborer plusieurs personnes sur un même projet ?
Gageons que vous vous êtes déjà au moins une fois posé l'une de
ces questions, que ce soit en entendant la prof de français parler
des manuscrits de tel grand auteur où les ratures sont visibles (et
où on peut voir comment le texte a évolué, ce que l'ordinateur,
déplorait-elle sans doute, ne permet plus), ou que ce soit en essayant
tant bien que mal d'organiser le travail d'une équipe autour des TPE en
utilisant l'outil informatique pour mettre en page votre rapport. Eh bien,
les informaticiens se posent la même question depuis fort longtemps,
et le premier programme de contrôle de versions, au doux nom de "Source
Code Control System" (SCCS), a été créé en 1972.
Comme son nom l'indique, ce programme servait à gérer du code source
(des logiciels). C'est en effet pour ce type de données que ces logiciels
sont le plus souvent utilisés. Non pas qu'ils soient inutiles pour
d'autres types de données ; même si on en a particulièrement besoin
pour le code source, la principale raison reste l'absence de logiciel
de contrôle de version vraiment simple à utiliser. Toutefois, même
si leur installation et utilisation peut être délicate au début,
il reste profitable de s'intéresser à leur fonctionnement.
Comment fonctionnent ces logiciels ? Ils se basent sur un dossier nommé
"dépôt" (en anglais "repository") où le programme va stocker toutes
vos données et l'histoire de leur évolution. Pour y accéder, vous, en
tant qu'utilisateur, devez demander au programme de vous créer une "copie
de travail" qui représente l'état de vos données dans le dépôt. Vous
travaillez dessus comme bon vous semble, et, quand vous voulez sauvegarder
les données dans le dépôt, vous demandez au programme de sauvegarder
l'état actuel des données (cette opération est une "propagation",
ou en anglais un "commit"). Chaque état des données sauvegardé est
une révision qui a un numéro (de 1 à l'infini), une date, une heure,
et le plus souvent un message pour indiquer ce que vous avez fait depuis
la dernière sauvegarde. Vous pouvez alors demander au programme :
À quoi ressemblait ce fichier à la révision 42 ? Quel travail ai-je
fait sur ce projet entre les révisions 17 et 37 ? Restaure la version
1337 de ce fichier à la place de la version actuelle.
« Mais qu'y a-t-il dans le dépôt ? », vous demandez-vous sans
doute. La réponse est : « On s'en fiche ! » C'est le programme qui
va lire le dépôt et obéir à vos ordres ; vous, vous travaillez dans
la copie de travail. Par contre, ce qu'il est important de savoir à
propos de ce dépôt, c'est que le système de contrôle de versions va
probablement gérer vos fichiers de manière intelligente, pour gagner
de la place. La manière la plus simple de fonctionner pour sauvegarder
l'évolution de votre travail au cours du temps serait de sauvegarder
une copie de tous les fichiers pour chaque révision : bien entendu,
le problème est que l'on stocke des copies inutiles de fichiers qui
n'ont pas changé entre deux révisions. On peut aussi sauvegarder les
changements effectués d'une révision à l'autre, mais dans ce cas,
pour connaître l'état d'un fichier à la révision 1701, il faut
appliquer toutes les modifications de la révision 0 à la révision
1701, ce qui peut être long... Par ailleurs, il peut arriver que vous
ayez plusieurs copies d'un même fichier dans votre copie de travail,
auquel cas il est inutile de stocker plusieurs fois les données dans le
dépôt. C'est le travail de votre système de contrôle de versions de
gérer ce genre de casse-tête, et croyez-moi, vous n'avez aucune envie
de connaître les détails, du moment qu'il répond docilement à toutes
les questions que vous lui posez sur vos fichiers.
Ces logiciels permettent aussi de travailler à plusieurs sur un projet,
ai-je dit plus haut : voici comment. Supposons que le dépôt soit
mis en ligne sur Internet, à l'aide d'un programme spécial. Chacun
des utilisateurs peut se connecter au dépôt pour se télécharger
une copie de travail. Il travaille dessus, et quand il sauvegarde,
les nouvelles informations sont envoyées au dépôt. Quand les autres
membres du projet mettront à jour leur copie de travail, les nouvelles
versions des fichiers seront téléchargées automatiquement chez eux.
Le drame survient lorsque un utilisateur (appelons-le Bob) avait déjà
créé dans sa copie de travail une nouvelle version d'un certain
fichier, sans la sauvegarder dans le dépôt. Un autre utilisateur
(Alice) a créé de son côté une autre version du même fichier et
l'a envoyée au dépôt. Quand Bob met à jour sa copie de travail, les
deux versions (la sienne, et celle d'Alice) sont en conflit. Que faire
? Les bons systèmes de contrôle de version pourront parfois concilier
intelligemment les deux versions (par exemple, si Bob et Alice ont chacun
corrigé une faute d'orthographe dans un fichier texte, à des endroits
différents), mais si les deux versions ne sont pas compatibles (si
Alice a effacé le paragraphe sur lequel Bob travaillait, par exemple),
le logiciel ne peut pas deviner ce qui est le plus judicieux et... c'est
à Bob de faire à la main une nouvelle version en conciliant les
modifications de chacun. Pour éviter ce genre de conflits, certains
programmes de contrôle de versions permettent de mettre des "verrous"
(en anglais "locks") sur les fichiers : si Alice commence à travailler
sur un fichier, elle le verrouille, et Bob, de son côté, ne pourra pas
commencer à modifier le fichier. Une fois qu'Alice a terminé, elle
sauvegarde et enlève le verrou : Bob pourra alors, s'il le souhaite,
verrouiller le fichier et travailler dessus à son tour.
Un dernier élément intéressant est l'émergence de nouveaux systèmes
de gestion de versions dits "décentralisés". Avec ce modèle,
il n'y a plus de dépôt central : chaque copie de travail est une
sorte de dépôt qui contient toute l'histoire de l'évolution des
fichiers. Les utilisateurs travaillent de leur côté, et, quand ils
le souhaitent, deux (ou plusieurs) utilisateurs peuvent mettre à jour
leurs copies en y intégrant chacun toutes les modifications faites
par l'autre (possiblement étalées sur plusieurs révisions, vu que
chaque utilisateur peut propager de son côté), et en résolvant les
éventuels conflits.
Différences entre deux fichiers
Comment trouver les différences entre deux versions d'un fichier
? Les systèmes de contrôle de version ont besoin de le savoir. De
votre côté, vous vous êtes certainement déjà demandé si tel et
tel fichier que vous aviez trouvés sur Internet ou sur votre disque dur
étaient identiques ou différents. Peut-être regardez-vous la taille des
fichiers pour le savoir, mais, bien entendu, il arrive que deux fichiers
aient la même taille mais pas le même contenu, de la même façon que
deux textes peuvent avoir la même longueur sans avoir le même contenu.
Le premier élément de réponse s'appelle les sommes de contrôle
(en anglais "checksums"). C'est une sorte de code calculé à partir de
votre fichier, qui dépend de son contenu. Par exemple, vous pourriez dire
que la somme de contrôle de "ABC" est 1+2+3=6. Si le fichier change, ne
serait-ce que d'un caractère, la somme de contrôle change aussi. Enfin,
en théorie. Puisqu'il faut que les sommes de contrôle soient plus
courtes que les fichiers qu'elles traitent (sinon, quel intérêt ?) ;
puisqu'en général, on leur donne une longueur fixe indépendante de
celle du fichier traité, il y a forcément une infinité de fichiers qui
ont la même somme de contrôle. Seulement, les méthodes pour fabriquer
les sommes de contrôle sont faites de telle façon que les collisions
(les fichiers ayant une même somme de contrôle) soient aussi différents
les uns des autres que possible. En pratique, une infime modification
du fichier de départ entraînera toujours une variation énorme de la
somme de contrôle. Pour vérifier que deux fichiers sont identiques,
facile : on calcule la somme de contrôle des deux. Si elle est égale,
c'est que les deux fichiers sont très probablement les mêmes.
Ces sommes de contrôle ont une autre utilité : elles servent à
vérifier sur Internet que des données ont bien été transmises. Comme
il arrive que les données soient mal transmises, on vous indique
fréquemment la somme de contrôle à côté du lien pour télécharger
des fichiers volumineux pour que vous puissiez vérifier à l'arrivée
qu'aucune erreur ne s'est glissée dans les données.
Enfin, certains algorithmes pour créer des sommes de contrôle (ou
"hashs" dans ce cas précis) ont ceci de particulier qu'il est facile
de calculer la somme de contrôle d'un fichier, mais qu'il est très
difficile (et en pratique impossible) de créer un fichier ayant une somme
de contrôle donnée. Le plus utilisé est MD5 (pour "Message Digest
5"), qui date tout de même de 1992. Il permet d'avoir une certaine
sécurité : quelqu'un qui voudrait modifier le fichier devrait aussi
modifier la somme de contrôle, et si cela n'est pas possible, il lui sera
presque impossible de créer un fichier différent avec la même somme de
contrôle. Une autre utilisation astucieuse : si je signais cet article
avec le hash MD5 de mon nom et prénom (8cd9e8f59b9fdb55373cc84f4320c369),
personne ne pourrait connaître l'auteur de ces propos subversifs. Mais
une fois qu'un nouveau gouvernement favorable à mes idées est au
pouvoir, je n'ai qu'à donner mon nom et on pourra instantanément
vérifier (en calculant son hash MD5) que je suis bien l'auteur.
Maintenant que vous avez vu que vos deux fichiers n'étaient pas
identiques mais différents, peut-être voudriez-vous connaître les
différences entre eux ? Je ne connais aucun moyen simple de faire
cela sous Windows ; par contre, presque tous les systèmes libres
dérivés d'Unix incluent parmi les utilitaires de base le programme
"diff". Donnez-lui vos deux fichiers et il vous retournera une liste
des différences (un "diff"). C'est aussi simple que ça.
Mieux encore, il existe un programme "patch" qui permet de faire
l'opération inverse. Générez un diff entre les fichiers A et B. Avec
"patch", vous pouvez reconstituer B à partir de A et du diff, ou revenir
à A à partir de B et du diff. Les amateurs de jeux vidéo connaissent
sans doute déjà les patches correctifs qui, plus légers que le jeu
entier, ne sont qu'un diff entre l'ancienne version et la nouvelle,
accompagnés d'un programme jouant le même rôle que "patch". Avec
"diff" et "patch", par contre, vous aussi, vous pouvez créer des patchs
! Si vous avez envoyé à quelqu'un une vidéo de plusieurs centaines de
mégaoctets, et que vous remarquez une horrible faute d'orthographe dans
les sous-titres (que vous corrigez), ce n'est pas la peine de renvoyer le
tout : faites seulement un diff entre les deux versions (il sera léger,
vu que presque rien n'aura changé) et envoyez-le à votre correspondant,
qui, sachant bien sûr utiliser "patch", pourra reconstituer la nouvelle
version. Si ça vous rappelle l'histoire des systèmes de contrôle de
version, c'est normal. Leur grande spécialité est de générer des
diffs entre deux versions d'un fichier, et ils peuvent aussi appliquer
des patches : lorsque Bob mettait à jour sa copie de travail, il y a
fort à parier que le système de contrôle de version ne téléchargeait
que des diffs et non les fichiers entiers, pour ensuite utiliser "patch".
Texte marqué
Si vous êtes utilisateur Windows, votre habitude est certainement
d'ouvrir Word dès que vous avez quelque chose à taper. Pour faire de la
mise en page, sans doute utiliserez-vous aussi Word. Le fonctionnement
général des logiciels tels que Word est simple : vous tapez votre
texte, et vous utilisez des options de menu pour le mettre en forme,
ce qui apparaît immédiatement sur le rendu à l'écran. De tels
logiciels sont dits WYSIWYG (pour "What You See Is What You Get", Ce
que vous voyez est ce que vous obtenez).
L'approche Unix est différente ; elle peut paraître étrange, mais a
ses avantages. Vous tapez votre texte dans un simple éditeur de texte,
comme le bloc-notes de Windows. Et, dans le texte, vous ajoutez des
commandes qui expliquent comment il doit être mis en forme. Par exemple,
une manière de mettre un texte en italique pourrait être : mon
texte, avec une balise pour indiquer le début, pour
indiquer la fin. L'italique n'apparaît pas directement dans le document ;
après, vous utilisez un logiciel qui va compiler votre document, c'est
à dire appliquer vos consignes de formatage pour obtenir le document
final, prêt à être imprimé. On parle alors de texte marqué.
Cette démarche a l'avantage de distinguer le texte et sa mise en
forme. Vous pouvez taper votre texte "au kilomètre" sans être distrait
par son apparence à l'écran. Si vous voulez entrer tout de suite des
commandes pour dire que telle ou telle partie est en italique, vous
pouvez le faire sans avoir à chercher la souris, simplement en entrant
les commandes au fil du texte. Et, comme le rendu n'apparaîtra qu'après
compilation, vous ne serez pas tenté de perfectionner la mise en page
du texte en perdant le fil de la rédaction. Ce n'est qu'une fois le
texte écrit que vous compilerez et commencerez à peaufiner la mise en
page pour obtenir un meilleur rendu.
En plus, s'il vous faut une application spéciale pour compiler le
document, il suffit d'avoir à sa disposition un éditeur de texte pour le
rédiger. Vous n'avez besoin d'aucune application pour spécifier comment
le texte sera mis en page, vous en avez juste besoin une fois que tout
est terminé pour générer le document final. Par contre, sur un poste
Unix, vous aurez accès à des éditeurs de texte très performants,
capables de gérer des fichiers gigantesques, configurables à l'infini,
et incluant toutes les fonctions dont vous pourriez rêver (le plus
connu, EMACS, inclut une quinzaine de jeux, un psychiatre virtuel, peut
être configuré pour relever ses mails et a même été bidouillé pour
servir d'interface à certains modèles de cafetières). Bien entendu,
ils sont entièrement pilotables au clavier, pour ne pas avoir à les
lâcher pour prendre la souris (pour changer la longueur de la marge
sous EMACS à 80 caractères, il faut taper Ctrl-U 8 0 Ctrl-X f).
Par ailleurs, avec le texte marqué, vous avez toujours sous les yeux
les commandes de formatage que vous avez entrées. Pour qui s'est
déjà acharné contre Word pour numéroter des titres correctement,
il est frustrant et désorientant que toutes les informations fournies
n'apparaissent pas dans le document, mais (enfin on l'espère) dans les
boîtes de dialogue correspondantes. Avec la méthode Unix, vous savez
que toutes les informations fournies au logiciel sont dans le document
texte. Pas de risque de voir vos heures de navigations dans les options
de Word perdues, vu qu'elles sont stockées comme du texte dans votre
document.
Enfin, cette approche est beaucoup moins gourmande en
ressources. L'affichage en temps réel de l'état du document au fur et
à mesure de sa mise en forme est très éprouvante pour l'ordinateur. Si
vous entrez toutes les commandes dans un document texte, elles ne sont
pas interprétées en cours de frappe. La compilation prendra peut-être
un peu de temps, mais une fois le document final généré, il n'y aura
plus de calcul à faire.
Le langage le plus connu de texte marqué est sans doute HTML, le
langage utilisé pour rédiger des pages web. Il existe de nombreux
logiciels "à la Word" pour rédiger du HTML en WYSIWYG, mais il est
très simple et souvent plus efficace de le faire à la main, avec un
éditeur de texte. HTML fonctionne avec des balises selon le principe
exposé précédemment : voici de l'italique, du gras,
et du gras italique.
Cependant, un logiciel redoutable de mise en page se basant sur du
texte marqué est LaTeX (prononcer "latek", la dernière lettre est le
"chi" de l'alphabet grec). LaTeX est peu connu sous Windows en dehors
du milieu universitaire où il est le logiciel de référence pour
rédiger des thèses et documents de toutes sortes. Ses points forts
? Une mise en page par défaut sobre mais élégante, une gestion très
développée du texte justifié, la césure automatique des mots, et
une qualité typographique bien au-dessus des standards Word. LaTeX
peut générer une table des matières complète en une seule commande,
est spécialisé dans la gestion des formules mathématiques et des
bibliographies, et accepte sans broncher des textes d'une longueur assez
impressionnante : il ne lui faut que cinq minutes sur mon poste pour
compiler un document de plus de 75000 pages. Au lieu de placer le texte
entre des balises, comme ceci, LaTeX procéderait
comme \exemple{cela}. Pour créer une section, la commande serait
: \section{Introduction}. Pour mettre un texte en valeur (avec de
l'italique), on utilise \emph{texte}. La table des matières s'obtient
en tapant \tableofcontents.
XML
L'idée d'XML (eXtensible Markup Language) est toute bête,
nous l'avons déjà vue plus haut. Utiliser des balises, c'est
cela XML. XML est ce qu'on peut appeler un
"métaformat" de documents. Ce n'est pas un format de document comme
HTML ou LaTeX, mais un ensemble de règles pour créer ses propres
formats. C'est très facile à faire : je peux créer un format XML
(un "dialecte" XML) pour faire un journal comme le Pontonews, avec des
rubriques, des articles, etc. Par exemple :
La puissance d'XML
Mon introduction
Le texte
Mieux encore, XML permet de décrire son format d'une manière
compréhensible par l'ordinateur. Je vais lui expliquer dans un format
spécial que le journal contient au moins une rubrique, que les rubriques
contiennent au moins un article, que les articles ont un titre, peuvent
avoir un chapeau, ont un texte et au moins une signature avec nom,
prénom, classe. Et une fois mon journal rédigé, je le ferai "valider",
et l'ordinateur pourra me dire : erreur, il y a une signature où il
manque la classe à la ligne 312.
Une fois le journal préparé, il faudrait le mettre en page. Remarquez
que mon exemple ne dit pas que le titre est en Verdana 20 gras centré,
il dit juste que c'est un titre. Je pourrai ensuite écrire un document
appelé "feuille de style" où j'indiquerai que les titres sont en Verdana
20 gras centré, et il existe des logiciels pour appliquer la mise en
page et afficher le document XML avec les titres comme je le voulais
(je n'ai alors plus qu'à l'imprimer). Peut-être auriez-vous eu envie
d'écrire directement dans le document :
La
puissance d'XML
Mauvaise idée ! Si vous changez d'avis et décidez de mettre tous
les titres en rose, par exemple, il faudra changer toutes les balises
. Alors que si vous avez fait une feuille de style, vous n'aurez
à changer ça qu'une seule fois pour que tous les titres de votre
document deviennent roses. Mieux encore, vu que plusieurs documents
peuvent utiliser la même feuille de style, vous pouvez d'un seul coup
rendre roses les titres de tous les numéros du Pontonews.
En résumé : dans le document, on indique le sens de chaque élément
(c'est un titre, c'est un exemple, c'est un mot important, c'est une
signature). Dans la feuille de style, on indique comment mettre en page
chaque élément (les titres sont en Verdana 20 gras centré rose,
les exemples sont dans une boîte avec "Exemple :" en haut, les mots
importants sont surlignés en bleu, les signatures sont alignées à
droite). C'est ce que l'on appelle la séparation du contenu et de la
présentation. Si vous avez compris, bravo ! Pas mal de webmasters n'y
sont toujours pas arrivés...
Une dernière fonctionnalité impressionnante d'XML : il est simple
de transformer des documents XML vers autre chose. Cela se fait à
l'aide d'un langage nommé XSLT. Supposons que vous vouliez exporter
le document du Pontonews dans un fichier LaTeX pour profiter de ses
fonctionnalités avancées de mise en page. XSLT vous permet de donner une
liste de modifications à faire : transformer les Bla bla
en \section{Bla bla}, mettre au début un \tableofcontents, etc. Un
programme spécial appliquera ensuite vos règles au document, et bien
évidemment, vous pouvez utiliser les mêmes règles pour convertir tous
les documents rédigés dans le même dialecte (une fois les règles
écrites, ça devrait marcher pour tous les numéros du Pontonews). Et
tenez-vous bien, le langage XSLT est lui-même un dialecte XML ! Vous
pouvez donc dire que vous écrivez un document XML pour transformer du
XML en XML... ou en autre chose (LaTeX n'est pas un dialecte XML.)
Scripts make
Sous Linux, on aime bien utiliser la ligne de commande. Ainsi, pour
compiler l'exemple du Pontonews, il faut d'abord transformer le fichier
XML en LaTeX : une commande. Il faut ensuite compiler le fichier LaTeX :
une autre commande. Cela fait donc deux commandes (pas nécessairement
simples) pour compiler le Pontonews à partir des "sources" (le document
XML). C'est bien trop ! Puisque nous sommes des informaticiens, nous
sommes paresseux et préférons taper une seule commande. De plus,
celle-ci devrait toujours être la même pour tous les projets, pour
éviter de surcharger notre mémoire. La commande traditionnelle qui
doit tout faire est :
"make"
On crée donc ce que l'on appelle un script make. On lui donne le nom
traditionnel "Makefile", et on indique dedans quelles commandes il faut
exécuter pour compiler notre projet.
Maintenant, supposons que l'on veuille mettre en couverture du Pontonews
des smileys de différentes tailles. L'approche naïve est de créer
une image pour chaque taille à la main, pour ensuite les apposer sur
la couverture. Mauvaise idée ! Si je décide de changer la couleur
des smileys, il va falloir changer toutes les images une à une. Il
est plus pratique de ne garder qu'une grande image de smiley : c'est
la source. J'indique dans mon script make les commandes pour générer
les smileys de toutes les tailles en partant du grand. Ainsi, quand je
compile, je génère tous les smileys et je les inclus au document. Mais
si je préfère que les smileys soient en rose, je n'ai qu'à changer
le grand smiley et à recompiler, et tous les petits smileys deviendront
roses.
En poussant ce système à l'extrême, vous pourriez vous dire : c'est
bête de stocker le smiley, stockons plutôt les instructions pour
dessiner un smiley (par exemple : faire un rond à contour noir et à
fond jaune (ou rose) pour la tête, deux cercles noirs pour les yeux,
une courbe noire pour la bouche). Bravo, vous venez de (ré)inventer
ce que l'on appelle des images vectorielles. Les images vectorielles
contiennent les instructions pour dessiner un smiley ; les images normales
(images bitmap) sont un tableau de points représentant un smiley. Un
ordinateur peut facilement vous dessiner un smiley bitmap à partir des
instructions en vectoriel, mais il sera incapable (ou difficilement
capable) d'ouvrir un smiley bitmap et de vous dire comment vous avez
fait pour le dessiner. (Notez aussi que le vectoriel ne sert à rien
dans le cas de photos ou d'images scannées, par exemple : vous ne les
avez pas dessinées, mais obtenues à partir de la réalité.)
Cependant, la plupart des applications préfèrent traiter des images
bitmap. Dans ce cas, pas de problème : mettons dans notre script make les
instructions pour convertir toutes nos images vectorielles en bitmap. Sauf
qu'en mettant une instruction pour chaque image, si on décide de
changer l'instruction, il faudra le faire pour chaque image. Et s'il
faut beaucoup d'instructions avec beaucoup d'images, le fichier make va
grossir inutilement. Dans un script make, vous pouvez créer des règles
de conversion, qui expliquent comment convertir une image. Après, il
suffira de mettre dans le script make "Occupe-toi des images a, b, c, d",
et votre ordinateur appliquera la règle de conversion pour chaque image.
Pour finir avec make, notons qu'il permet de définir des cibles. Par
exemple, vous pourriez définir une cible "pdf" pour générer le
Pontonews en PDF, "html" pour faire une version web, et "latex" pour
générer une version en code LaTeX. Make vous permet de préciser une
cible en tapant la commande "make cible", selon que vous voulez le PDF,
l'HTML, ou le LaTeX. "make" sans cible appellera la cible par défaut. Là
où ça devient intéressant, c'est que vous pouvez dire que telle cible A
dépend d'une autre cible B. Dans ce cas, à la compilation, on générera
B avant de générer A. On peut arriver au même résultat en copiant à
la main les commandes de B dans A, mais ce n'est pas élégant, vu que,
si une commande doit être changée, il faudra le faire à deux endroits
différents. Par exemple, pour générer du PDF, il faut du LaTeX, et
certains programmes permettent de passer du LaTeX au HTML. Il est donc
judicieux de n'écrire qu'une fois les instructions pour convertir le XML
en LaTeX (cible "latex"), et d'écrire deux cibles "pdf" et "html" qui
dépendent de "latex" et convertissent le LaTeX en PDF ou en HTML.
Système de gestion de paquets
Pour installer un logiciel sous Windows, le moyen classique est de
télécharger sur Internet un programme d'installation (setup) qui va
faire les opérations nécessaires pour installer le programme. Sous
les systèmes Unix, on utilise plutôt des gestionnaires de paquets :
les données du programme et les étapes à suivre pour l'installer
sont dans un paquet, et c'est le gestionnaire de paquets qui va faire
l'installation. L'avantage est qu'il n'y a pas besoin d'intervenir durant
l'installation, et qu'on peut installer tranquillement des dizaines de
programmes sans avoir à cliquer des centaines de fois sur "Suivant".
Par ailleurs, les sites pour télécharger des paquets (on appelle ça
des dépôts, mais ça n'a rien à voir avec les systèmes de contrôle
de version) sont faits pour être utilisés par gestionnaire de paquets
interposé. C'est lui qui va aller chercher le paquet et le télécharger
sur le site. Conséquence : il suffit de dire à votre gestionnaire de
paquets : installe-moi le programme "truc", pour qu'il aille télécharger
le paquet "truc" au bon endroit, l'installe et le configure.
Plus fort encore : si les applications du dépôt sont mises à jour,
le gestionnaire de paquets va automatiquement télécharger la nouvelle
version disponible en ligne. C'est la même chose que Windows Update, mais
étendu à tous les logiciels, pas seulement aux logiciels Microsoft. Sous
Windows, certaines applications doivent être mises à jour à la main
en allant télécharger la mise à jour et en repassant par un setup
(et il faut vérifier régulièrement qu'une nouvelle version n'est pas
sortie), d'autres ont leur propre système de mise à jour laborieusement
développé par l'éditeur du logiciel, qui va mettre à jour seulement
cette application, le plus souvent quand vous venez de la démarrer et
avez besoin de vous en servir. Sous les dérivés d'Unix, le système
met tout à jour tout seul comme un grand.
En plus, ceux qui créent les paquets peuvent définir des dépendances
entre eux. Vous vous rappelez des dépendances des scripts make ? C'est
la même chose : de nombreux programmes utilisent des blocs communs
appelées bibliothèques (en anglais library). Par exemple, beaucoup
de jeux utiliseront une bibliothèque pour lire de la musique, et une
autre pour afficher des fichiers 3d, et la même bibliothèque servira
à plusieurs jeux. Sous Windows, vu qu'il n'y a pas de dépendances,
soit le programme que vous téléchargez inclut toutes les bibliothèques
dont il a besoin (dont certaines étaient sans doute déjà sur votre
système, donc vous les téléchargez pour rien), soit il ne les inclut
pas toutes, et, si l'une d'entre elles manque, il affichera au mieux
"Veuillez installer la bibliothèque truc.", au pire "Fatal error
0x0abf2a67: resmodx.dll not found." Sous les systèmes Unix, le paquets
n'incluent aucune bibliothèque, mais indiquent le nom du ou des paquet(s)
permettant d'installer les bibliothèques requises. Lorsque vous installez
le programme, le gestionnaire de paquets téléchargera tous les paquets
nécessaires si vous ne les avez pas déjà : vous ne téléchargez que
ce dont vous avez besoin.
Cryptographie
Les systèmes Unix permettent facilement de crypter des fichiers. Pourquoi
faire, me direz-vous ? Eh bien, tout d'abord pour des données
confidentielles auxquelles vous ne voudriez pas que les autres aient
accès.
Mais aussi pour vos mails. Peut-être ne le savez-vous pas, mais les
données voyageant sur Internet, sauf mention contraire, le font
en clair. Vos mails aussi. Toute personne qui les intercepte peut
(techniquement si pas légalement) les lire. Et il y en a beaucoup. Votre
fournisseur d'accès, tout d'abord, qui a accès à tout le trafic
provenant de votre machine. Tous les responsables des équipements
réseaux entre vous et votre destinataire. Et, bien sûr, le fournisseur
d'accès de votre destinataire. Sans parler de ceux qui hébergent vos
boîtes mail (Microsoft avec Hotmail, Google avec GMail, etc.) Peut-être
serez-vous surpris d'apprendre que le gouvernement américain a
récemment été pris la main dans le sac alors qu'il surveillait les
échanges Internet de certains de ses citoyens, en toute illégalité,
en espérant identifier ainsi des terroristes. Si vous n'appréciez
pas que tout ce que vous dites par mail ait la confidentialité d'une
carte postale, la solution est de crypter ses messages. Pour ce faire,
le logiciel libre Thunderbird avec la librairie de cryptographie Enigmail
et le moteur GPG est assez pratique. À ma connaissance, ni Hotmail ni
GMail ne permettent de crypter ses communications.
TODO : principes de base de la crypto asymétrique
Répertoire utilisateur
Si vous vouliez faire une copie de sauvegarde de vos données (ce que
je vous recommande de faire au minimum tous les mois), où iriez-vous
les chercher ? Dans votre dossier "Mes Documents", bien sûr. Mais
pas seulement. Certaines applications stockent leurs données dans un
sous-répertoire de "Program files". Vous avez peut-être des fichiers
sur votre bureau. Et certains paramètres de votre session sont dans un
répertoire Documents and Settings. Sans parler des informations de la
base de registre, qui ne correspondent même pas à un fichier. Quelle
galère...
Sous les systèmes Unix, une règle simple est mise en application
à la perfection : toutes vos données sont dans un seul répertoire,
votre répertoire personnel. Les applications s'installent ailleurs,
mais tous leurs paramètres vont dans le répertoire personnel. C'est
bien simple, le système ne leur permet d'écrire que là. Pour faire
une copie de sauvegarde de toutes vos données, il suffit de sauvegarder
le répertoire personnel. Simple et efficace.
Ne parlons même pas de la sauvegarde des applications. Si vous deviez
réinstaller sur votre ordinateur toutes les applications que vous avez
tirées d'Internet, vous en auriez pour des heures à télécharger
et à lancer des programmes d'installation. La seule solution est de
sauvegarder le répertoire Program files, mais cela prend une place
énorme, et n'est même pas sûr de marcher : certaines applications
ont besoin de bibliothèques (qui sont ailleurs) ou d'informations de
la base de registre (qui sont encore ailleurs). Sous un système Unix,
grâce au gestionnaire de paquets, il vous suffit de lui demander la
liste des paquets installés (il n'y a pas besoin de sauvegarder leur
contenu). En cas de problème, il suffira de lui redonner la liste
pour qu'il télécharge et installe à nouveau les paquets que vous
aviez. L'opération prendra un certain temps, mais elle est complètement
automatique.
Un dernier petit détail. Sous Windows, vous pouvez avoir plusieurs
sessions, avec des données en théorie séparées. Sauf que de nombreuses
vieilles applications stockent les mêmes paramètres pour tout le monde
sans se soucier des sessions, et qu'un utilisateur peut donc changer
d'un seul coup les paramètres de tout le monde sans prévenir. Sous un
système Unix, vu que chaque utilisateur a son répertoire personnel,
chacun a son propre système indépendant. D'ailleurs, vu que chacun
ne peut accéder qu'à son propre répertoire, il n'y a pas de risque
d'endommager ou d'aller espionner les données des autres. De même,
vu que seul l'administrateur peut accéder aux données système (qui ne
sont pas dans les répertoires personnels), il n'y a pas de risque qu'un
utilisateur empêche le système de fonctionner. Vous pouvez créer une
session à n'importe qui sur votre machine : même s'il le voulait, il
ne pourrait pas (à moins d'avoir votre mot de passe) accéder à vos
données ni faire planter le système. À moins, bien sûr, d'attaquer
physiquement la machine en la balançant par la fenêtre...
TODO : SSH
Sources :
Les systèmes d’exploitation : Windows Vista encore
discret. [En ligne]. AT Internet / XiTi.com, 2007
[consulté le 21 mars 2007]. Disponible à l'adresse :
http://www.xitimonitor.com/fr-fr/technique/systemes-d-exploitation-fevrier-2007/index-1-1-3-73.html
Wikipédia [En ligne]. Wikimedia Foundation, 2007 [consulté le 21 mars
2007]. Disponible à l'adresse : http://fr.wikipedia.org
Copyright © 2007 Antoine Amarilli
This work is licensed under the Creative Commons Attribution-Share
Alike 3.0 License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to
Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California,
94105, USA.