Ce livre m’a appris 6 faits incontournables sur Linux

L’art de la programmation Unix (TAoUP), d’Eric S. Raymond, n’est pas un tutoriel ou un livre pratique. Il s’agit plutôt d’un livre sur l’histoire et la philosophie d’Unix. Mais aucun autre livre n’a eu une plus grande influence sur mon approche de Linux/macOS, ou sur mon utilisation quotidienne de celui-ci. Voici quelques-unes des choses qu’il m’a apprises.

6. Unix est (même) plus vieux que vous ne le pensez

Vous n’avez pas besoin de connaître l’histoire complète d’Unix pour l’utiliser, ni de Linux, ni de macOS aujourd’hui. Mais en savoir un peu plus sur l’origine d’Unix ne peut pas faire de mal. Comprendre le contexte du système d'exploitation vous aide à comprendre l'écran que vous regardez, et l'historique peut répondre à bon nombre de vos questions initiales, comme « Pourquoi les noms de commande sont-ils si courts ? ”

Le deuxième chapitre, « Histoire : une histoire de deux cultures », explique comment Unix a commencé en 1969, sur des téléscripteurs qui ressemblaient à des machines à écrire glorifiées. C’est incroyable de penser que ces machines ont encore quelque chose en commun avec de nombreux serveurs qui alimentent nos vies en ligne.

De nos jours, il est bon de considérer Linux comme un clone d’Unix, ce qu’il est essentiellement. Mais cette histoire est beaucoup plus longue et plus riche qu’il n’y paraît, et je suis fier d’utiliser un système aux racines vieilles de cinquante ans, même face à toutes les avancées technologiques depuis lors.

5. L’open source ne serait rien sans Linux

TAoUP poursuit en abordant la naissance de Linux et comment l’approche de Linus Torvald était un compromis entre les systèmes propriétaires et verrouillés et la liberté idéologique dans laquelle vivait le mouvement open-source en plein essor.

Le mouvement open-source est si vital pour l’histoire de Linux, qu’il est facile de les considérer comme une seule et même chose. Mais il est fascinant d’en savoir plus sur l’histoire de l’open-source et comment il se compare à l’approche propriétaire ou à l’alternative GNU (« logiciel libre »).

Dès les années 1950, les ingénieurs partageaient le code source, le lisaient et le modifiaient. Mais ce n’est que dans les années 1990, lorsque Linux est arrivé sur la scène, que les logiciels open source ont commencé à être largement utilisés. Cela a coïncidé avec une plus grande disponibilité d’Internet, un mécanisme de distribution qui a permis au développement open source de vraiment décoller.

4. Linux embrasse la simplicité (honnête !)

Bien que cela puisse sembler compliqué au premier abord, Linux repose sur des principes fondamentaux simples. S’il y a une leçon que le livre enseigne plus que toute autre, c’est celle-ci. Toute la section sur la conception (chapitres 4 à 13) explique pourquoi l’éthique de base d’Unix est si bénéfique.

Raymond explore ce concept en le décomposant en un ensemble de « règles » que les « anciens » d’Unix (des gens comme Rob Pike et Ken Thompson) avaient auparavant énoncées de manière moins formelle. Ces 17 règles comprennent :

• Modularité
• Composition
• Simplicité
• Transparence
• Silence

Les règles se résument essentiellement à un principe familier : KISS (Keep it simple, stupid !) En encourageant les petits programmes, qui effectuent des tâches basiques et concrètes et communiquent à l’aide d’un protocole texte simple, la philosophie Unix aboutit à des outils réutilisables et fiables.

3. Des programmes précis et modulaires font tout fonctionner

La première des règles de Raymond est la « modularité », qui est décrite comme suit : « Écrivez des parties simples connectées par des interfaces propres. « Comme beaucoup d’autres règles, l’accent est mis ici sur le contrôle de la complexité. De nombreux problèmes liés à l’utilisation de l’ordinateur proviennent de systèmes complexes difficiles à comprendre. En prônant la simplicité, cette règle vise à réduire les échecs et à améliorer la compréhension globale.

Lorsque vous rencontrez pour la première fois des outils Linux comme ls ou grep, il peut être difficile de les considérer comme des programmes à part entière. Ils en font beaucoup moins que votre navigateur Web ou votre traitement de texte, de sorte qu’ils peuvent sembler triviaux ou sans importance. Mais c’est négliger le pouvoir inhérent de la modularité : combiner de petits programmes pour réaliser plus que la somme de leurs parties.

L’un des exemples les plus pratiques de la puissance de la modularité est le tuyau :

        ls | grep "foo"

    

Voici un exemple d’un motif très courant que je me retrouve à rechercher, encore et encore :

        du -sk * | sort -rn | head

    

Ce pipeline exécute trois programmes : du pour rapporter la taille totale des fichiers/répertoires correspondants, trier pour les classer numériquement, et head pour renvoyer les dix premiers résultats. Le résultat est un petit ensemble de répertoires qui occupent le plus d’espace sur le disque, que je peux ensuite suivre pour nettoyer.

Sans tubes, l’alternative serait un seul programme appelé quelque chose comme « get-biggest-ten-folders ». Un tel programme peut même être plus pratique, mais il est beaucoup plus restreint que les outils généraux disponibles ici. Vous auriez besoin d’un grand nombre de programmes mal nommés pour vous en sortir sans canaux, et leur complexité serait sans aucun doute horrible à utiliser.

2. Le texte sous-tend tout

Le chapitre 5 du livre traite de la textualité, à la fois en termes de formats de fichiers et de la façon dont les programmes Unix communiquent. C’est l’une des choses qui m’a le plus frappé chez Unix, surtout en ce qui concerne la configuration. Venant de Windows, j’étais habitué au registre, cette fameuse base de données opaque et monolithique qui abrite les paramètres des programmes.

Les outils Linux, en revanche, ont tendance à avoir des fichiers de configuration basés sur du texte, disséminés partout dans votre système de fichiers (à des endroits standard, si vous le souhaitez). Vous pouvez modifier ces fichiers à l’aide d’un éditeur de texte standard et les interroger à l’aide des outils de ligne de commande courants. Cela signifie qu’il n’est pas nécessaire de modifier les paramètres à l’aide d’outils d’interface graphique personnalisés, bien que ceux-ci puissent toujours être construits sur le format de fichier texte traditionnel.

Cette philosophie s’étend également à la façon dont les programmes communiquent. Lorsque vous utilisez un pipeline, vous transmettez du texte d’un programme à un autre. À tout moment, vous pouvez interrompre le pipeline pour le déboguer. Prenons l’exemple de ce pipeline :

        ls | grep "txt"

    

En insérant la commande tee, vous pouvez capturer la sortie à un point spécifique et l’enregistrer dans un fichier pour le débogage :

        ls | tee debug-ls-output.txt | grep "txt"

    

Cela est lié à la règle de transparence de Raymond :

« Concevoir pour la visibilité afin de faciliter l’inspection et le débogage »

L’utilisation du texte comme format de communication et de données signifie que les programmes fonctionnent de manière ouverte, avec moins de parties cachées. Il est ainsi plus facile de corriger des programmes, d’en tirer des leçons et de les utiliser.

1. Linux est obstinément traditionnel, pour le meilleur et pour le pire

Linux – et, plus encore, Unix – est souvent considéré comme « à l’ancienne », un système apprécié des « barbes grises » et des zélotes. Bien qu’il puisse y avoir une part de vérité à cela, cela néglige le fait que les technologies matures et évoluées ne sont pas nécessairement mauvaises.

Dans le chapitre 14, Raymond discute de l’utilisation du C, qui a joué un rôle déterminant dans le développement de Linux. Bien que la situation évolue, de nombreux outils standard en ligne de commande sont encore écrits en C aujourd’hui. Le livre note comment le C a proliféré, en partie, à cause de l’excellent support d’outillage qui a survécu au passage du temps.

Raymond n’est pas un absolutiste ; il explique comment Python, un langage relativement moderne, est un meilleur choix pour les nouveaux projets. Mais il explore également les avantages et les inconvénients de la programmation shell et soutient que la programmation orientée objet n’est pas parfaite. Comme une grande partie du livre, cette section plaide contre les solutions universelles et souligne à quel point le contexte est toujours important.

L’art de la programmation UNIX

Ce livre explore l’origine et la philosophie d’UNIX, ainsi que la façon dont il a évolué au fil des décennies pour devenir des systèmes d’exploitation modernes.

L’art de la programmation Unix est disponible en ligne gratuitement et en version papier. Je suis un grand fan des deux parce que le premier est une excellente référence, mais le livre est tellement bon à lire qu’il est agréable de s’asseoir et d’explorer d’un bout à l’autre.