Would I Still Choose Linux After 30 Years

SYNTHÈSE STRUCTURÉE

Linux offre des choix, pas des dogmes

L’intervenant explique qu’il ne suit pas une seule distribution pour toutes ses machines. Il a récemment migré ses serveurs de Debian 12 vers Debian 13, puis vers Devuan 6, car il préfère éviter systemd. « Je ne veux pas faire le même choix pour chaque machine. » Sur ses postes de travail, il a testé NixOS, MX, antiX, Alpine, Void, mais est resté sur Fedora KDE et Arch, car ses habitudes sont trop ancrées. La leçon : chaque machine a un rôle, et le choix de l’OS doit suivre ce rôle, pas l’inverse.

Adapter la cadence de mise à jour au rôle de la machine

Pour ses serveurs, il impose une règle stricte : « long-term support, sans exception ». Il refuse qu’un serveur soit surpris par une mise à jour qui casse tout un mardi. Sur ses postes de travail, il utilise un modèle hybride, proche d’une rolling release, et sur son laptop Arch, il teste tout ce qui est nouveau. « C’est là que vit la bleeding edge. » Cette approche à trois vitesses évite les surprises et permet de valider les changements avant de les généraliser.

Comprendre l’opération, pas la commande

DJ Ware raconte son passage de SunOS à Solaris : ps -ef ne fonctionnait pas, il a cherché dans le man et trouvé ps -aux. « Une fois que je comprends ce que j’essaie d’accomplir, trouver comment le système le fait est la partie facile. » Il insiste sur le fait que mémoriser des commandes est moins utile que de comprendre le concept sous-jacent (par exemple, la différence entre les options BSD et System V). Sur Linux, ps -ef et ps -aux donnent deux vues différentes des processus, un héritage de cette époque.

Utiliser le GUI et le shell en complémentarité

Pour une simple copie ou un renommage, il utilise le gestionnaire de fichiers. Mais quand il a dû supprimer 4 721 fichiers vidéo bruts pour libérer son pool ZFS, il est passé au shell. Il a d’abord construit une liste des fichiers à supprimer, l’a vérifiée, puis a exécuté une commande find pour tout effacer. « Tu penses que je vais m’asseoir devant un gestionnaire de fichiers et faire du copier-coller toute la journée ? Non. » Il a ensuite mis la commande dans un script pour la réutiliser plus tard.

Construire des outils dans le shell pour automatiser

Pour son benchmark de systèmes de fichiers, il a automatisé un processus qui lui prenait 10 jours de travail manuel (montage, tests, collecte de données, création de 26 graphiques). Après automatisation, le tout s’exécute en 20 minutes. « J’ai réduit 10 jours à 20 minutes. » Il a enregistré toutes les opérations dans des scripts, ce qui lui permet de relancer le benchmark avec une seule commande. C’est un exemple concret de la puissance du shell pour transformer une tâche répétitive en un processus reproductible.

Linux révèle les vérités que l’on préférerait ignorer

DJ Ware raconte un projet d’entreprise où il devait réécrire un système électoral COBOL en Informix 4GL. Après 110 jours, il n’avait terminé que 30 programmes sur 200. En analysant les données avec Linux (nombre de lignes de code, temps restant), il a compris qu’il était impossible de tenir les délais. « Le panneau que Linux tenait disait : “Tu vas échouer.” Et j’ai écouté. » Il a négocié avec le client pour livrer uniquement la partie terminée et rembourser le reste. La leçon : les chiffres ne mentent pas, et il faut savoir les écouter, même quand ils annoncent un échec.

Adapter l’outil au travail, pas l’inverse

Un client voulait adopter SAP, mais le vendeur a refusé de modifier le workflow pour s’adapter aux processus internes du client. « Ce qu’il disait vraiment, c’est : changez votre workflow pour correspondre à l’application, ne changez pas l’application pour utiliser votre workflow. » Le client n’a pas acheté SAP. À l’inverse, un ami a modifié SAP en profondeur, mais à chaque mise à jour, il devait fusionner son code, et au bout de cinq ans, SAP a changé ses API et tout a cassé. La conclusion : « Je ne veux pas changer le travail pour faire plaisir au logiciel, mais je ne veux pas non plus être soudé à une version particulière. » Linux permet de construire une solution à partir de briques, en partant du besoin.

Linux est une école permanente

DJ Ware conclut que toutes ses leçons se résument à une seule : « Linux continue de m’enseigner. Parfois la leçon est de faire mieux, parfois c’est de fuir. » Il évoque la vidéo de Linus Tech Tips sur les limites de Linux pour le montage vidéo, notamment l’absence de véritable enregistrement ISO (audio et vidéo synchronisés). Il insiste sur l’importance de définir ses besoins avant de choisir un outil : « On parle enfin de mes exigences, pas de la solution préférée de quelqu’un d’autre. » Il critique aussi le modèle en cascade (waterfall) qui livre des solutions obsolètes, et prône une approche itérative : « concevoir un peu, coder un peu, tester un peu, livrer un peu. »

CONCEPTS CLÉS

Systemd : gestionnaire de services et d’init utilisé par la plupart des distributions Linux ; certains utilisateurs lui préfèrent des alternatives comme SysV init ou OpenRC pour des raisons philosophiques ou de contrôle.
Rolling release : modèle de mise à jour continue où les logiciels sont constamment mis à jour, sans versions majeures distinctes (ex. Arch Linux).
ZFS : système de fichiers et gestionnaire de volumes avec des fonctionnalités avancées comme les snapshots et la compression ; DJ Ware surveille le seuil de 70-80 % de remplissage pour éviter des baisses de performance.
ISO recording : enregistrement vidéo où chaque piste audio et vidéo est enregistrée séparément et synchronisée, indispensable pour un montage professionnel.
Waterfall model : méthode de développement séquentielle (exigences → conception → implémentation → test → livraison), critiquée pour sa lenteur et son manque de flexibilité.

CONCLUSION

La vidéo de DJ Ware est une démonstration pratique que Linux n’est pas un simple outil, mais un écosystème qui s’adapte à des besoins variés, à condition de comprendre les principes sous-jacents plutôt que de mémoriser des commandes. Sa leçon la plus importante est peut-être celle-ci : « Le travail passe en premier. La charge de travail passe en premier. Les outils sont secondaires. » Linux excelle parce qu’il permet de construire des solutions sur mesure, mais il exige aussi de l’honnêteté intellectuelle — parfois, les données montrent qu’il faut abandonner un projet ou changer d’approche. Pour un administrateur système, c’est un rappel que la flexibilité technique doit s’accompagner d’une discipline dans la gestion des changements et d’une écoute attentive des signaux que le système nous envoie.