Ce livre m'a appris 6 faits incontournables sur Linux

L'art de la programmation Unix (Taoup), par Eric S. Raymond, n'est pas un tutoriel ou un livre pratiques. Au lieu de cela, c'est 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, ni mon utilisation quotidienne. Voici quelques-unes des choses qu'il m'a apprises.

6

Unix est (même) plus ancien que vous ne le pensez

Vous n'avez pas besoin de connaître l'historique complet d'Unix pour l'utiliser – ou Linux ou MacOS – Today. Mais savoir un peu sur la façon dont Unix est originaire de 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'histoire peut répondre à plusieurs 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 machines de télétype 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.

https://www.youtube.com/watch?v=OBGXRIYKQJC

De nos jours, c'est bien de considérer Linux comme un clone Unix, ce qu'il est essentiellement. Mais cette histoire est beaucoup plus longue et plus riche qu'elle ne le semble, et je suis fier d'utiliser un système avec des racines de cinquante ans, même face à chaque avance technologique depuis lors.

5

Open source ne serait rien sans Linux

Taoup continue à couvrir 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 que le mouvement en plein essor open a vécu.

Le mouvement open source est si vital pour l'histoire de Linux, qu'il est facile de les considérer comme un même. Mais il est fascinant d'en savoir plus sur l'histoire de l'ouverture 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 le logiciel open source a commencé à être largement utilisé. 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 décoller vraiment.

4

Linux embrasse la simplicité (honnête!)

Bien que cela puisse sembler compliqué au début, Linux repose sur des principes fondamentaux simples. S'il y a une leçon que le livre enseigne plus que toute autre, c'est ça. L'ensemble de la section de conception (chapitres 4 à 13) explique pourquoi l'éthique de base 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 précédemment déclaré moins formellement. Ces 17 règles comprennent:

• Modularité

• Composition

• Simplicité

• Transparence

• Silence

Les règles se résument essentiellement à un principe familier: baiser (gardez les choses simples, stupides!) En encourageant les petits programmes, qui effectuent des tâches de base et concrets et communiquez en utilisant un protocole de texte simple, la philosophie UNIX se traduit par des outils réutilisables et fiables.

3

Les programmes précis et modulaires font que tout coche

Le premier des règles de Raymond est la «modularité», qui est décrite comme «Écrivez des pièces 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 d'utilisation de l'ordinateur découlent de systèmes complexes difficiles à comprendre. En défendant 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 à part entière. Ils font beaucoup moins que votre navigateur Web ou votre traitement de texte, donc ils peuvent sembler triviaux ou sans importance. Mais cela néglige 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 modèle très commun que je me retrouve à atteindre, à maintes reprises:

        du -sk * | sort -rn | head

    

Ce pipeline exécute trois programmes: DU pour signaler la taille totale des fichiers / répertoires correspondants, trier pour les commander numériquement et rendre 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 tuyaux, l'alternative serait un seul programme appelé quelque chose comme «Get-Biggest-Ten-Rolders». 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 maladroitement nommés pour vous débrouiller sans tuyaux, et leur complexité serait sans aucun doute horrible de travailler avec.

2

Texte sous-tend tout

Le chapitre 5 du livre est une question de textualité, à la fois en termes de formats de fichiers et de la façon dont les programmes UNIX communiquent. C'était l'une des choses qui m'ont le plus frappé à Unix, surtout en ce qui concerne la configuration. Venant de Windows, j'étais habitué au registre, cette infâme, opaque et monolithique, qui abrite les paramètres du programme.

Les outils Linux, en revanche, ont tendance à avoir des fichiers de configuration de texte, parsemés partout dans votre système de fichiers (à des endroits standard, si vous le souhaitez). Vous pouvez modifier ces fichiers avec un éditeur de texte standard et les interroger avec des outils de ligne de commande courants. Cela signifie qu'il n'y a aucune exigence pour les outils d'interface graphique personnalisés pour modifier les paramètres, bien que ceux-ci puissent toujours être construits au-dessus du format de fichier texte traditionnel.

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

        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:

«La conception de la visibilité pour faciliter l'inspection et le débogage»

L'utilisation du texte comme format de communication et de données signifie que les programmes fonctionnent à l'air libre, avec moins de pièces cachées. Cela facilite la réparation des programmes, les apprendre d'eux et les utiliser.

1

Linux est obstinément traditionnel, pour de bon et de mauvais

Linux – et, plus encore, Unix – est souvent considéré comme «old-school», un système aimé par des «belles-gris» et des fanatiques. Bien qu'il puisse y avoir un élément de vérité à cela, il 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 de C, qui a joué un rôle déterminant dans le développement de Linux. Bien que la situation évolue, de nombreux outils de ligne de commande standard sont toujours écrits en C aujourd'hui. Le livre note comment C a proliféré, en partie, en raison de l'excellent support d'outillage qui a survécu au temps qui passe.

Raymond n'est pas un absolutiste; Il explique comment Python, une langue relativement moderne, est un choix supérieur pour les nouveaux projets. Mais il explore également les avantages et les inconvénients de la programmation des coquilles et soutient que la programmation orientée objet n'est pas parfaite. Comme une grande partie du livre, cette section s'affiche contre les solutions à une taille et souligne comment le contexte est toujours important.

---

La programmation Art of Unix est disponible en ligne gratuitement et comme copie papier. Je suis un grand fan des deux parce que le premier est idéal pour référence, mais le livre est une si bonne lecture qu'il est agréable de s'asseoir et d'explorer la couverture.