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 : <italique>mon texte</italique>, avec une balise <x> pour indiquer le début, </x> 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 <i>de l'italique</i>, <b>du gras</b>, et du <b><i>gras italique</i></b>.

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 <exemple>ceci</exemple>, 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 <italique>cela</italique> 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 :

<journal>
<rubrique nom="Homo numericus">
<article>
<titre>La puissance d'XML</titre>
<chapeau>Mon introduction</chapeau>
<texte>Le texte</texte>
<signature nom="Amarilli" prénom="Antoine" classe="TS1" />
</article>
</rubrique>
</journal>

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 :

<titre police="Verdana" taille="20" effet="gras" alignement="centré">La puissance d'XML</titre>

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 <titre>. 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 <titre>Bla bla</titre> 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 de très bons 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.

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...

Sources

Si vous voulez télécharger le texte de l'article au format texte brut :

  • main.txt, texte brut UTF-8 (licence Creative Commons Attribution-Share Alike 3.0 License).