Traduction de l'entretien donné par Patrick Volkerding sur LinuxQuestions.org

Le 6 juin 2012, Patrick Volkerding, fondateur et mainteneur de Slackware, a accordé un entretien à LinuxQuestions.org. Au cours de celui-ci, il a répondu aux questions collectées auprès des utilisateurs du forum Slackware du site, qui depuis des années est plus ou moins considéré comme le forum officiel du projet. On y apprend beaucoup de choses sur la cuisine interne de la distribution et les conditions (notamment économiques) de son maintien. Pat y revient également sur la genèse et l'évolution de son bébé, qui soufflera ses vingt bougies l'année prochaine, et livre sur un ton mesuré son sentiment sur les évolutions récentes de l'écosystème Linux (Wayland, systemd, versement de /bin et /sbin sous /usr, etc. ).

Étant donnée la discrétion générale de Pat, et s'agissant de quelqu'un qui depuis le tout début a vécu de près l'évolution du monde Linux, il nous a semblé intéressant de proposer sur LinuxFr.org une traduction française de cet entretien. Les noms qui suivent entre parenthèses certaines questions sont les pseudonymes des utilisateurs qui les ont initialement proposées. Nous avons également jugé bon d'ajouter des liens, notamment pour clarifier ce qui peut ne pas être familier aux lecteurs francophones et aux plus jeunes (relativement à Pat, envoyé sur Terre en l'an de grâce 1966).

Pour finir, nous remercions LinuxQuestions.org qui a autorisé cette traduction, pour autant qu'un lien vers l'original y demeure et que tout changement éditorial par rapport à celui-ci soit clairement indiqué — oui, oui, ces restrictions sont valables pour vous aussi ;-).

Bonne lecture à tous, et Have fun!

NdM : Merci à Alain pour sa participation à la traduction et à Cyrille Pontvieux et Yves Bourguignon pour leur relecture.

1) Pour commencer, peux-tu nous donner quelques informations sur toi ? (LQ)

Bien sûr. Je suis né en Virginie alors que mon père y était affecté en tant que dentiste de la Marine. Nous avons déménagé dans le Dakota du Nord alors que j'étais très jeune. Aussi loin que je puisse m'en souvenir, j'ai toujours été intéressé par la science, la conquête spatiale, et par d'autres centres d'intérêt typiques chez un gamin qui voulait devenir un jour une sorte de scientifique. J'ai eu un Meccano, plein de briques Lego, ainsi qu'un kit de petit chimiste tout à fait convenable, plein de poisons avec lesquels aujourd'hui les gamins ne seraient jamais autorisés à jouer. Quand j'ai eu 7 ou 8 ans, ma classe a fait une sortie scolaire à l'Université d'État du Dakota du Nord pour y voir le département informatique, et c'est là que j'ai goûté pour la première fois à de l'UNIX et réalisé que je voulais travailler avec des ordinateurs. J'ai possédé une console Atari 2600 et ai voulu avoir la cartouche BASIC assez difficile à trouver qui allait avec (sans jamais y parvenir), et quand les ordinateurs personnels se sont mis à apparaître, j'ai commencé à squatter les Radio Shacks et les magasins d'électronique pour faire réparer mon ordinateur. Le Radio Shack du centre commercial avait le Modèle TRS-80 en exposition, et une collection sympa de livres sur le BASIC. J'ai appris à programmer en tapant les listings d'un livre de jeux pour ordinateur de David Ahl, puis en essayant de voir comment les modifier. Le magasin était content de me voir arriver et entrer du code, et ils ont sauvegardé les programmes sur des cassettes, de sorte qu'ils avaient des démos. Mais malheureusement, ça ne s'est pas vendu et mon premier ordinateur a été un Apple ][+, et avec lui j'ai appris à programmer en Pascal (sur UCSD p-System), dans un C entier appelé Hyper-C, en Forth, et dans d'autres langages. Forth m'a amené à apprécier la notation polonaise inversée, et à ce jour je n'utilise encore que des calculatrices HP à notation polonaise inversée. Après le lycée, je suis entré à l'université pour un cursus dominé par l'ingénierie informatique (en gros, 5 années de cours de base / programmation), mais au bout de deux ans de cela il était clair pour moi que l'informatique bas niveau n'était vraiment pas ma voie et qu'un cursus en programmation me conviendrait mieux. En plus, l'école que j'avais choisie était très focalisée sur VMS . J'ai fini transféré à l'Université d'État de Moorhead, à qui on venait de donner un tas d'équipement UNIX AT&T et qui était connectée à Internet pour de vrai (les autres écoles avaient un accès BITNET uniquement, ce qui était plutôt inutile). C'est durant la fin de mon cursus à Moorhead que j'ai commencé pour la première fois à travailler avec Linux.

2) Comment t'es tu retrouvé impliqué dans Linux et l'Open Source, et quel parcours t'a conduit à commencer Slackware ? (LQ)

C'est en 1992 que pour la première fois j'ai entendu parler de ce projet en cours où quelqu'un en Finlande essayait de construire un clone d'UNIX. À cette époque, j'utilisais OS/2 sur un 386/sx 16MHz. C'était un bon système d'exploitation, mais ce que je voulais vraiment était une sorte d'UNIX. J'avais vu les les pubs pour le Coherent dans le magazine Byte et avais envisagé ça, de même que Minix. J'étais même descendu à la boutique d'informatique locale pour me renseigner sur le Xenix SCO pour lequel, si je me souviens bien, ils demandaient deux-trois milles balles pour une licence d'utilisateur unique ! Je repasserai, merci. J'étais donc vraiment enthousiasmé d'aller dans le labo informatique et de commencer à surveiller les groupes USENET et les sites FTP où le développement se passait. Ça semblait en grande partie trop beau pour être vrai à l'époque, mais bientôt j'ai eu les disquettes d'H.J. Lu tournant sur ma machine (ça marche ! ), et j'ai ensuite suivi de près la distribution MCC Interim Linux. Yggdrasil était quelque part par-là, aussi, mais je n'ai essayé celle-ci que beaucoup plus tard, car ma machine n'avait pas de lecteur CD. Très rapidement, je suis tombé (doucement) sur une des premières versions de SLS, la distribution de Peter MacDonald.

Je prenais des cours sur l'intelligence artificielle, et tout était codé en LISP. On nous avait donné à utiliser un interpréteur LISP basé sur DOS, mais l'interpréteur CLISP fourni avec SLS se révéla bien meilleur et de très loin. J'ai parlé à mon professeur de CLISP, et de Linux, et il m'a demandé si je pouvais l'aider à installer Linux sur un des ordinateurs du labo, un 486 AT&T avec une carte vidéo S3. On a fait une descente là-bas et effectué l'installation, et tout s'est déroulé vraiment bien. J'ai sorti mon cahier (« Il est temps de corriger les bugs ! ») et j'ai commencé à corriger tous les problèmes que j'avais documentés alors que j'utilisais SLS, ce qui l'a conduit à me demander s'il serait possible de corriger tout ces bugs sur les disquettes, et de rendre l'installeur plus automatisé, de sorte que les classes futures puissent faire leur programmation sous Linux et ne pas avoir à payer de licence pour une version de LISP franchement médiocre. J'étais prêt à relever le défi, et j'ai commencé par chercher à comprendre tout simplement comment les choses avait été mises ensembles. SLS avait été conditionnée comme une version à peu près uniquement binaire avec pratiquement aucun code source pour quoi que ce soit, et pas beaucoup d'indices sur la façon dont les choses avaient été faites. Il n'y avait aucun script de construction pour quoi que ce soit, mais c'était vraiment typique pour les distributions Linux de 1993 (et ça a été un piège dans lequel moi-même je suis tombé au début, jusqu'à ce que je sois fatigué d'avoir toujours à réapprendre ce que j'avais fait à chaque fois que quelque chose nécessitait d'être reconstruit). Durant le mois suivant ou quelque chose comme ça, j'ai corrigé tous les bugs que je connaissais dans SLS, mis à jour le noyau, et ai fait un grand nettoyage de l'installeur. Mon ami Brett Person a été mon bêta-testeur original (et contribua également beaucoup à l'installeur), et m'a encouragé au seuil d'avril 1993 à partager sur Internet ce que j'avais fait. J'ai obtenu à cette époque quelques bêta-testeurs de plus, en contactant directement par courriel les gens qui postaient leurs problèmes avec SLS sur comp.os.linux et en leur demandant s'ils aimeraient tester ce sur quoi on travaillait. J'ai eu beaucoup de bons retours, et des encouragements supplémentaires à proposer la bêta sur FTP. Ainsi, en juillet 1993 j'ai mis la première version publique de Slackware sur un FTP tournant sur un UNIX AT&T 3b2 et j'ai annoncé ça sur comp.os.linux. La réponse dépassa vraiment les espérances… en particulier pour l'UNIX qui l'hébergeait. J'ai essayé de faire tenir les choses pendant quelques jours, mais ça n'allait pas le faire, et Linux non plus n'était alors pas au point pour cette tâche (TCP/IP était encore sous le coup de gels aléatoires), j'ai donc lancé un appel pour aider à l'héberger. Parmi les réponses, il y en avait une de Rod Grimes, du projet FreeBSD, offrant un espace sur le serveur ftp.cdrom.com de Walnut Creek CDROM, ce que j'ai accepté avec reconnaissance. Cela a débouché sur une longue relation avec les gens de Walnut Creek CDROM.

3) Quelle version de Slackware a été la plus contraignante/difficile à assembler ? Quelle a été la plus gratifiante ? (solarfields)

En y repensant, il y en a sans aucun doute quelques-unes qui se démarquent par leur difficulté de réalisation, en général à cause d'une quelconque transition majeure. Le passage du format a.out au format ELF en fait assurément partie, comme cela a été le cas également pour la conversion de ELF libc5 à glibc quand la première version stable de la bibliothèque glibc est arrivée. J'étais vraiment heureux de la sortie de la glibc en version stable parce que j'avais pour politique de ne pas fournir de versions beta de composants critiques du système, comme les bibliothèques C ou le compilateur, mais la plupart des autres distributions avaient déjà pris les devants et s'étaient basées sur des pré-versions de la glibc. Je n'étais pas loin de violer cette ligne de conduite lorsque la version stable de la glibc, si longtemps attendue, est enfin arrivée. La version la plus difficile et également la plus gratifiante à sortir a probablement été la Slackware 13.0, la première version à offrir le support de l'architecture x86_64. Eric Hameleers mérite beaucoup de reconnaissance pour son travail de portage de Slackware sur des systèmes AMD64/x86_64 et pour s'être assuré qu'il serait possible d'y ajouter assez facilement le support « multilib ». J'avais été tenté de ne prendre en charge que l'architecture 64 bits seule en utilisant pour les bibliothèques les mêmes dossiers que dans la version 32 bits de Slackware, et je voyais le répertoire /lib64 comme une complication inutile qui allait demander de patcher un grand nombre de sources pour le faire fonctionner. Cela a vraiment requis un grand nombre de correctifs au départ et le demande encore à certains endroits, mais /lib64 a été la solution que tout le monde a fini par utiliser.

4) On affirme que Slackware est la plus ancienne distribution existante ; à quoi attribues-tu cette longévité ? (ChrisAbela)

Dans le cas de Slackware, je m'efforce particulièrement de respecter la volonté des développeurs en amont. Ce n'est pas le bon endroit pour patcher, ajouter de nouvelles fonctionnalités ou empaqueter des versions bêta (si ça peut être évité). Lao Tseu a dit que pour diriger, on doit suivre. J'ai bien sûr mes propres idées sur la façon dont les choses doivent fonctionner mais j'essaie de ne pas les imposer égoïstement. Le but est d'aller de l'avant sans perdre de vue pour autant les racines du projet. Je n'ai rien contre le changement mais en même temps j'essaie de ne pas laisser les choses s'embrouiller uniquement pour le plaisir de les rendre différentes. Les gens qui reviennent à l'utilisation de Slackware après un certain temps sont en général agréablement surpris car il n'ont pas besoin de tout réapprendre. Cela nous a apporté tout un public de fidèles utilisateurs auquel je suis reconnaissant. J'en déduis que nous faisons quelque chose de bien.

5) Avais-tu jamais envisagé que Slackware durerait aussi longtemps ? Sortir une Slackware te rend-t-il aussi enthousiaste qu'à tes débuts ? (jmccue)

Non, je ne pensais pas que Slackware durerait aussi longtemps, ou du moins je ne pensais pas que je serais encore en train d'y travailler, mais une sorte de masse critique a été atteinte rapidement à partir de laquelle son développement allait se poursuivre sous une forme ou sous une autre, que ce soit sous ma direction ou non. Slackware m'enthousiasme encore énormément mais cela est différent des premiers jours quand les choses avançaient comme sur des roulettes. Compte tenu de leur adoption rapide par les utilisateurs, ça été des moments passionnants pour Slackware et Linux. Slackware a eu le premier stand lié à Linux au COMDEX et nous avons été joliment pris d'assaut par la foule lors de la démonstration d'un serveur web tournant sur un ordinateur portable ! Le premier Linux Kongress qui s'est tenu aux Pays-Bas en 1994 a été un autre temps fort du succès rapide de Linux. Il est difficile d'atteindre de tels sommets. Plus tard, la fusion de Walnut Creek avec BSDI et nos tentatives pour gagner en visibilité ont été des moments passionnants, puis dévastateurs lorsque le marché s'est effondré : l'introduction en bourse a été annulée, et la société a été bradée lorsque les liquidités ont été épuisées. Je suis cependant heureux d'être encore en train de faire ce que je fais. J'aime travailler au développement de Slackware et faire partie de la grande communauté Linux, et je continue à croire que c'est un travail important.

6) Comment vois-tu l'avenir de Slackware d'ici à 5 ans ? (jmccue)

Sur ce point, vos suppositions sont probablement aussi bonnes que les miennes. Une durée de cinq ans, c'est très long dans le domaine informatique. En repensant à l'historique du projet, je n'aurais vraiment pas pu prévoir le cours des événements qui, pour une grande part, est déterminé par les projets en amont ainsi que par les besoins en évolution perpétuelle des utilisateurs. Ainsi, j'aime rester concentré sur des objectifs plus immédiats. Quand ceux-ci sont atteints, ce qui vient ensuite devient mon nouveau sujet d'attention. C'est plus un processus évolutif qu'une conception bien déterminée. Dans les cinq ans à venir, le défi sera de rester fidèle aux racines de Slackware dans la philosophie UNIX alors que d'autres projets et développeurs ayant des objectifs potentiellement complètement différents contribuent à Linux dans son ensemble. Le monde semble être en train de s'éloigner de l'ordinateur personnel pour s'orienter vers les appareils communicants et les applications (en particulier dans le monde des affaires) se dirigent vers les services du cloud. Il reste à voir comment cela influera sur l'orientation du projet Slackware.

7) As-tu envisagé un plan de succession telle qu'une fondation Slackware comme pour Mozilla, LibreOffice, etc ? (kingbeowulf)

Je ne suis pas certain qu'on puisse vraiment appeler ces exemples des « plans de succession » — la fondation Mozilla est une organisation à but non lucratif tandis que LibreOffice est un fork issu d'une insatisfaction générale sur les orientations prises par Oracle pour OpenOffice (ou au moins issu du sentiment que cela allait dans le mauvais sens). Dans le premier cas, j'ai déjà envisagé, par le passé, quelque chose d'approchant. FreeBSD dispose d'une société sans but lucratif dont le rôle est d'accepter les dons matériels et financiers pour aider à soutenir le projet, et il semble que cela fonctionne pour eux. J'ai envisagé ce genre de choses mais je ne saurais vraiment pas par où commencer. La mise sur pieds d'une sorte de structure à but non lucratif ou sans but lucratif constitue une entreprise plutôt considérable et ce n'est pas quelque chose que je vois comme étant possible à réaliser sans une importante aide extérieure.

Maintenant, pour répondre au point que, je pense, vous voulez en fait aborder (y a-t-il un avenir pour Slackware après Patrick) : je pense qu'il y en aura un. Si l'on revient à l'année 2004 lorsque je suis tombé malade, l'équipe a eu de nombreuses discussions sur ce sujet, nous avons abouti à des conclusions sur la façon de gérer la grande question «que faire si…». Les gars de l'équipe n'étaient pas sur le point de laisser tomber le projet.

Quoi qu'il en soit, nous n'avons pas de projet de succession, pas en tant que tel, mais c'est un pas que nous aurons à sauter le moment venu. Dans l'intervalle, nous essayons de ne pas monter tous dans le même bateau.

8) Que penses-tu de la panique qui semble se produire dès que le site web principal de Slackware tombe en panne ? (kristizz)

La panique a tendance à créer encore plus de panique, et quand je vois tout le monde flipper, je fais de même. Surtout quand le code du site web est quelque chose qui a été bricolé il y a longtemps par des gens qui depuis sont passés à autre chose. Malheureusement, il semble que chaque fois que le projet se heurte à un obstacle, il y ait des gens qui essaient de dépeindre la situation de telle façon que cela semble sonner le glas du projet. Et c'est comme ça depuis longtemps et pas seulement pour notre projet. Je pense que Netcraft a déjà confirmé, à un moment donné ou à un autre, la mort d'à peu près tous les projets open source existants. Cela dit, cela fait vraiment mal quand le ton des commentaires tend à suggérer que la raison pour laquelle il n'y a pas de solution immédiate est due à mon désintérêt pour ce problème. Croyez-moi, je m'en préoccupe, et quand les trolls me décochent leurs piques, je peux me sentir vraiment découragé et commencer à penser des bêtises du type « j'étais un as sur Linux, mais là j'ai du plomb dans l'aile ». J'essaie cependant de m'en détacher avec un sentiment de détermination renouvelée. Et le site web est de retour, ayant été porté sur un nouveau code PHP par Mark Post. Nous cherchons à améliorer les choses pour l'avenir, comme un système de gestion de contenu convenable qui nous permettrait de poster des nouvelles plus fréquemment. Cela fait longtemps que slackware.com n'est plus vraiment le centre de notre activité — la majeure partie de notre présence sur le web est ici sur LinuxQuestions et personnellement je préfère ça plutôt que de penser à essayer de faire fonctionner notre propre forum web. Nous l'avons fait aux alentours de l'année 2000 et avons trouvé qu'une part croissante de notre temps était consacré à cette activité plutôt qu'à l'avancement du projet. Et c'est en partie pourquoi nous avons fini par porter l'ancien site et par le remettre en ligne plutôt que de procéder à la construction de quelque chose de neuf à partir de zéro. Il y a eu des progrès significatifs accomplis en vue de mettre en place un site web entièrement nouveau mais les efforts devaient plutôt porter sur la mise en forme de -current en vue d'une nouvelle version. Il y a beaucoup de choses à traiter dans la file d'attente.

9) Dirais-tu que le dur travail que tu accomplis est payant et le développement de Slackware te satisfait-il d'un point de vue économique et personnel ? (BlackRider)

Eh bien, économiquement parlant les dernières années ont été plutôt maigres. Si je n'avais pas pris la décision stratégique de revenir au Minnesota il y a plusieurs années je n'aurais pas pu rester financièrement à flot en vivant dans la région de la baie de San Francisco. La Californie n'est pas du tout un endroit où la vie est bon marché et, là-bas, le bouclage de mon budget était toujours serré. Dernièrement, c'était aussi le cas ici. Je n'ai même plus de couverture sociale… je touche du bois. Du point de vue personnel, ce travail me satisfait complètement. Je me suis fait des amis partout dans le monde. J'entends parler, tous les jours, de gens qui aiment Slackware et en dépendent pour des tâches critiques, et qui ne veulent pas utiliser autre chose. Travailler sur le projet est enthousiasmant et amusant, et les personnes de l'équipe font partie de mes meilleurs amis. Il n'est tout simplement pas possible d'évaluer cela en termes financiers.

10) Peux-tu décrire ta journée de travail type ? (slacker77)

Je n'obéis pas à un format de journée type mais celle-ci comprend généralement du café (très important !), la lecture de mes courriels et de LinuxQuestions et les échanges avec le reste de l'équipe sur IRC. Je suis un grand nombre de listes de diffusion, telles que BugTraq et oss-security, ainsi que beaucoup d'autres listes gérées par des projets en amont afin de garder un œil sur les changements qui vont nous affecter. Les autres membres de l'équipe ont des domaines pour lesquels ils surveillent et mettent en attente des paquets proposés et je reviens sur tout cela pour voir si c'est le bon moment pour commencer à les intégrer dans -current. Il y a beaucoup de travail de compilation et de tests des mises à jour potentielles et cela implique maintenant plus de correctifs à gérer qu'il n'y en avait dans les années passées, donc je passe une grosse partie du temps soit à chercher les correctifs dont nous avons besoin soit à les écrire moi-même. Nous devons tous vraiment procéder comme ça. Il semble que les mises à niveau de la toolchain (gcc et la glibc en particulier) aient tendance à casser le code existant plus souvent qu'avant, donc ce qui devrait être un simple changement de version revient à porter quelque chose sur le nouveau compilateur (je suis curieux de voir dans quelle mesure llvm/clang seront adoptés parce que je soupçonne que cela pourrait rendre la cible moins mouvante). Bien sûr, la mise à jour des scripts de compilation, la compilation, l'empaquetage et les essais sont le lot quotidien du projet mais ces phases n'arrivent qu'après beaucoup de recherches … Je préfère livrer des versions basées sur la qualité plutôt que sur la fréquence parce que ce n'est pas toujours si facile de revenir sur une erreur une fois qu'elle a été intégrée à -current, et encore moins quand ça fait partie d'une version stable.

cf. fortune -m "three lines" fortunes2

11) Peux-tu décrire la configuration de ta machine personnelle (gestionnaire de fenêtres/environnement de bureau) ?

Sur ma machine personnelle je fais tourner KDE quasiment tel que Slackware le fournit et je l'ai utilisé comme ça de façon à peu près exclusive depuis qu'il est présent. Avant cela, j'ai utilisé FVWM pendant des années. J'ai essayé la plupart des gestionnaires de fenêtres et des environnements de bureau populaires, à un moment ou un autre, assez longtemps pour connaître les tenants et aboutissants de chacun d'eux. Je suis également un fan de XFCE parce qu'il est simple et rapide sur mes machines plus anciennes, tout en fournissant un environnement complet.

12) Peux-tu nous donner un aperçu des coulisses concernant le matériel que tu utilises pour tester/développer/faire le travail courant ? (tuxrukes)

La machine que j'utilise pour presque tout le développement ici est un AMD Phenom II X6 1100T cadencé à 3.3 GHz, avec 16 GB de RAM. Il possède 5 disques SATA à l'intérieur, 4 d'entre eux tournant sous LVM en RAID5, et un autre étant configuré en disque de base pour tester les installations. Je conserve les ordinateurs de manière compulsive et ai beaucoup de mes machines plus anciennes utilisées pour une chose ou une autre, comme signer les paquets et générer les fichiers checksum et manifest, et synchroniser les mises à jour avec le serveur que nous utilisons pour garder les arborescences qui ne sont pas encore publiques. Et il y a là des spécimens de matériel vidéo nVidia, Intel et AMD, de sorte que je peux m'assurer que ceux-ci fonctionnent correctement. Ça a été particulièrement important pour mener à bien la version 13.37, dans la mesure où tout était en transition vers des pilotes utilisant le kernel modesetting… il y a eu des problèmes épineux à surmonter avec ça.

13) Slack a toujours suivi un modèle d'élaboration quelque peu fermé. Quelle est la meilleure façon de contribuer à Slackware ? Peut-être de contribuer à des projets communautaires populaires ? Ou est-ce préférable de commencer une projet lié à Slack et de voir si cela prend ? (bobzilla)

Si vous voyez que quelque chose manque et que vous pensez avoir une audience assez large, vous pouvez toujours soumettre un Slackbuild sur slackbuilds.org (s'il n'y en a pas déjà un … le catalogue est assez fourni). Cela nous est également utile si jamais nous décidons de l'empaqueter dans l'arbre de développement officiel. Le démarrage d'un projet lié à Slackware est aussi une voie à suivre. Lorsque nous avons cessé d'empaqueter GNOME, nous étions heureux de voir certaines équipes s'investir pour en fournir les paquets. Tester ce qui est dans -current et faire remonter les bugs constitue également une aide importante, surtout si vous avez travaillé sur un correctif pour les résoudre. Il en va de même pour les mises à jour susceptibles d'être intégrées dans l'arbre de développement. Nous recevons vraiment pas mal d'aide de personnes qui testent des choses issues des projets en amont et qui, constatant que le Slackbuild existant ne fonctionne pas pour la compilation, comprennent pourquoi et nous le rapportent. Une grande partie des discussions sur les développements en cours se passe sur le site LinuxQuestions, donc s'il vous plaît partagez-y ce que vous savez.

14) Comment choisis-tu qui travaille dans ton équipe ? Comment AlienBOB, Alan_Hicks, rworkman, etc. ont-ils été choisis ? (suppy)

Tout d'abord, un petit rappel historique — le noyau dur de Slackware tel qu'il est aujourd'hui est vraiment l'équipe de deuxième génération. La première équipe était constituée de David Cantrell, Chris Lumens et Logan Johnson. David et Logan m'ont approché dans un salon à Chicago. À cette époque, Slackware n'avait jamais eu de site web et ils se sont portés volontaires pour aider à en construire un. Quand j'ai emmenagé en Californie pour travailler pour Walnut Creek, ils leurs ont proposé des boulots à eux aussi, et ils ont travaillé avec moi jusqu'à l'éclatement de la bulle Internet. David et Chris travaillent pour Red Hat maintenant, essentiellement sur l'installeur, et Logan travaille chez MOVL. Chris a eu une petite renommée il y a quelques années en tant que tête pensante du thème hot dog pour Fedora.

L'équipe actuelle a commencé en tant que système de miroirs Slackware non-officiels. Erik Jan Tromp (alias alphageek) maintenait une page web listant ces sites miroirs et en plus de son propre miroir Slackware il y avait plusieurs autres sites miroirs et administrateurs, et ils avaient un canal IRC qu'ils utilisaient pour parler de tout ce qui se passait à propos des miroirs. Finalement ils en sont venus à me contacter par courriel à ce sujet, et m'ont incité à aller sur l'IRC. Initialement, c'était pour parler des problèmes relatifs à la distribution des logiciels, mais ça a évolué en discussion sur les problèmes de développement. Parmi les gens qui utilisent le canal IRC depuis plus longtemps que moi, on compte mrgoblin, amrit, karlmag, alphageek, et quelques autres qui continuent à suivre mais n'y sont plus aussi actifs. Après cette époque, les gens qui ont intégré le noyau dur ont en général fait une sorte de contribution majeure à Slackware d'une manière non-officielle, et ont alors été invités à le rejoindre. Robby et Alan l'ont été à cause de leur boulot sur SlackBuilds.org, et alienBOB au travers de la création d'un portage soigné sur l'architecture x86_64 ainsi que tout son travail d'empaquetage public additionnel. Fred Emmott de Slamd64 (qui travaille à présent chez Facebook) y a été également invité et on le voit toujours ici. Mark Post a été ajouté après avoir porté Slackware sur IBM S/390 (et avoir remonté les corrections des bugs découverts en chemin). Heinz Wiesinger a été invité pour avoir réalisé des miracles divers, tout dernièrement en comprenant les problèmes rencontrés avec MySQL et PHP, miracles parmi lesquels on peut compter le procédé de construction de PHP en une seule passe en restant compatible avec les diverses nuances de PHP dans les paquets et avec les différents Modules Multi-Processus d'Apache. Nous avons également fini par intégrer beaucoup de ses SlackBuilds depuis slackbuilds.org, donc ça semblait une juste contre-partie.

Impressionnez-nous comme il faut et peut-être que nous vous ajouterons aussi. Mais gaffe au terrible bizutage.

15) As-tu envisagé des moyens plus cohérents pour communiquer avec les utilisateurs de Slackware (peut-être via un blog ou Google +) ? Que penses-tu d'un modèle de développement plus ouvert, du genre quelque chose basé sur git ? (collégial)

J'ai envisagé de faire un plus grand usage des médias sociaux. J'ai des comptes Google+ et Twitter et je m'en sers pour faire des annonces ou pour discuter de questions liées à Slackware. J'ai aussi un compte Facebook mais ne l'utilise pas tant que ça. Je n'ai jamais vraiment été attiré par l'idée d'avoir mon propre blog (même si je suis heureux qu'alienBOB en ait un). J'ai quand même essayé de mettre plus d'informations dans le fichier ChangeLog qu'une simple liste des changements de paquets.

En ce qui concerne un modèle de développement plus ouvert tel que git ou un autre système de contrôle de version, il va probablement devenir nécessaire à un moment donné d'aller plus loin et, en particulier, rworkman pousse vraiment à l'adoption de quelque chose comme ça dans notre modèle de développement. À l'heure actuelle, nous avons plusieurs personnes qui maintiennent leur propre arbre de développement privé et je passe une partie croissante de mon temps à régler les différences entre des mises à jour qui ont été développées en parallèle. J'ai toujours su que je gérais mal le changement d'échelle mais il devient très douloureusement évident que jouer le rôle du grand maître validant tout changement entrant dans la branche -current ne va pas pouvoir durer encore longtemps à mesure que le nombre de paquets de supports nécessaires pour KDE et les autres choses ne cessent d'augmenter. Cela est particulièrement vrai si jamais nous espérons pouvoir porter Slackware sur ARM et sur d'autres architectures à partir de la même arborescence source. Sur ce sujet, il serait également temps de commencer à penser à la centralisation de certaines parties du système des Slackbuilds. Bien qu'il soit agréable d'avoir un script de compilation complètement autonome, ce n'est pas très commode quand arrive le moment d'assurer le support d'une nouvelle architecture. Rien à voir avec décider d'ajouter de nouvelles options au bloc ARCH et éditer chaque Slackbuild un par un pour parvenir à faire ce qui n'est censé être qu'un simple ajout. Ce sont donc quelques-unes des choses à regarder dès que nous aurons fait paraître cette version et entamé un autre cycle de développement.

16) Que penses-tu des tendances actuelles dans le domaine des environnements de bureau (Unity, Gnome 3) ? Il y a des années que tu as choisi KDE pour Slackware, es-tu satisfait de la direction prise (bureau sémantique) par KDE ? (fgcl2k)

Je n'ai pas vraiment assez expérimenté personnellement Unity ou GNOME 3 pour m'être forgé une opinion solide sur eux, mais ce que j'ai pu observer de Unity me porte à croire que c'est probablement un environnement intuitif pour les gens qui sont habitués aux interfaces utilisées sur smartphone ou sur tablette graphique. Et je suppose qu'ils visent ce marché. Pour ma part, je suis quasiment sûr que je serais plus à l'aise avec GNOME Shell. Entre GNOME et KDE, je suis heureux que ce soit KDE qui soit dans l'arbre de développement principal de Slackware. J'aime beaucoup KDE et je crois qu'il est plus conforme à Slackware. Peut-être que c'est parce que son framework est principalement développé en C++. J'ai tendance à préférer C à C++ globalement pour la plupart des choses, mais je pense vraiment que C++ est le meilleur langage pour le développement d'interfaces graphiques parce qu'il facilite l'utilisation de composants existants et que, de ce fait, il rend moins forte la tentation de réinventer la roue en dehors du framework. Le passage de Qt3/KDE3 à Qt4/KDE4 était un peu chaotique (mais nous avons laissé passer quelques versions) et je pense que la plupart des gens seraient d'accord pour dire que KDE4 est devenu un environnement de bureau de très grande classe. J'attends également avec impatience une nouvelle mouture de Xfce mais cela va exiger d'assimiler quelques-unes des dépendances de GNOME que j'étais plutôt content de voir partir. Même si ce n'est pas vraiment un gros problème, puisque Robby a supporté la majeure partie de cette lourde charge et que les nouvelles versions de Xfce ont l'air vraiment bonnes, donc les quelques paquets de gestion additionnelle que nous aurons besoin de réintroduire vaudront le coup.

17) Tout dernièrement, il y a de nombreux changements techniques potentiellement intrusifs qui ont affecté quelques unes des distributions majeures. Comment crois-tu que certains d'entre eux vont toucher Linux en général et Slackware en particulier ? Y en a-t-il que tu songes à introduire dans Slackware ? (55020 & tuxrules)

Ouais, je vois deux-trois choses pointer qui pourraient bouleverser notre manière habituelle de faire les choses, et pourraient forcer Slackware à devenir, disons, peut-être moins UNIX-like. Je crois que les deux grosses à l'horizon sont Wayland et Systemd. Si oui ou non nous finirons par les utiliser reste à voir. Il est vraiment possible que nous finirons par ne plus avoir le choix en la matière, selon la manière dont s'orientera le développement qui n'est pas de notre ressort. Il est difficile de dire si adopter ces technologies serait ou non une bonne chose pour Slackware au final. Concernant systemd, j'aime assurément l'idée d'un temps de chargement plus rapide (évidemment), mais j'aime également contrôler le démarrage du système avec des scripts shell qui sont lisibles, et je crois que c'est ce que la plupart des utilisateurs de Slackware préfèrent également. Je ne passe pas ma journée à redémarrer ma machine, et pour avoir regardé les fichiers de config de systemd, il me semble que c'est une manière étrange pour moi de contrôler un système et que tenter de contrôler les services, les sockets, les périphériques, les montages, etc. tous au sein d'un seul daemon heurte le concept UNIX qui consiste à faire une chose et à la faire bien. Pour l'utilisateur final moyen, si cela débouche sur un démarrage plus rapide, alors mission accomplie. Avec Udev peu à peu délaissé au profit de systemd pour la réalisation de ces tâches-là, nous aurons à un moment à décider si nous voulons essayer de maintenir udev nous-mêmes, ou avoir systemd juste pour remplacer les fonctionnalités d'udev, ou si nous voulons toute la panoplie. Wayland, en comparaison, semble vraiment sans gravité, pour autant qu'ils parviennent à implémenter la transparence réseau directement ou au travers d'une sorte de sur-couche de compatibilité. À nouveau une chose qui n'a pas beaucoup d'utilité pour les utilisateurs de bureau mais dont beaucoup d'utilisateurs ne peuvent se passer. J'aime X11, et j'y resterais probablement si migrer vers Wayland signifiait perdre cette fonctionnalité, même si la méthode de rendu de Wayland amenait avec elle quelques bénéfices comme réduire les artefacts et accroître les performances vidéo. Je pense que nous aurons juste à regarder le bénéfice total lorsque suffisamment de temps se sera écoulé pour faire de telles comparaisons.

Tout dernièrement, le grand changement qui m'a inquiété sur le futur de non seulement Slackware mais de Linux en général est l'implémentation à venir de Secure Boot dans tous les matériels clients certifiés pour Windows8, et le verrouillage total du matériel ARM sans aucune option pour couper cette « fonctionnalité ». J'imaginais que nous poursuivrions en requérant que Secure Boot soit désactivé pour pouvoir installer Slackware, et j'ai été (pour le moins) plutôt surpris que toutes les distributions Linux ne soient pas en train de prendre ce chemin. Si cela rend impossible de faire un dual boot sans changer des paramètres dans le BIOS, ou que ça nous laisse sans pilotes parce qu'ils sont conçus pour ne tourner qu'avec certains noyaux signés, alors nous aurons à reconsidérer cette approche, mais je ne peux imaginer que nos utilisateurs soient contents s'ils découvrent soudainement qu'il leur est interdit de compiler leurs propres noyaux et modules. Le but ici sera de maximiser la latitude de l'utilisateur final à modifier son propre système, et si cela signifie qu'il doit aller dans le BIOS et inverser la valeur d'un switch ça ne paraît pas placer la barre très haut. Espérons que cela n'évoluera pas jusqu'à rendre nécessaire un flashage du BIOS parce que le switch aura disparu à la sortie de la prochaine génération de machines, s'il est alors encore seulement possible de flasher le BIOS. Tout ce qu'il y aurait à faire serait de mettre cela en pré-requis pour la prochaine certification matérielle de Windows. J'encouragerais tout le monde à signer la pétition secure-boot-vs-restricted-boot de la Free Software Foundation pour faire savoir aux fabricants où vous vous situez par rapport à ce problème. Je suis particulièrement déçu d'entendre que les systèmes basés sur ARM pour Windows ne laisseront aucun moyen d'accès, mais peut-être est-il possible que Google ou une autre société donne de la voix pour nous. Et peut-être qu'Alan Hicks était en avance quand il a acheté un portable Apple pour faire du développement Linux dessus. C'est assurément une époque intéressante que nous vivons là.

18) Que penses-tu de Fedora et Solaris, qui « simplifient » l'arborescence système en faisant des trucs comme fusionner /usr/bin et /bin ? Est-ce quelque chose que tu pourrais jamais envisager ? (ruario)

Pour sûr, je pourrais envisager ça, mais nous verrons comment ça se passe ailleurs et dans quelle mesure tout commencera à s'attendre à ce que soit ainsi. Sur Slackware (et sur d'autres systèmes) beaucoup des binaires qui s'installeraient autrement dans /usr/bin doivent être déplacés dans /bin, parce qu'on a besoin d'eux avant que /usr ne soit accessible, dans le cas où /usr est sur une partition à part. De même, des bibliothèques doivent également être déplacées. Cela a conduit à faire beaucoup de liens symboliques pointant de /usr/bin vers /bin, ou de /usr/sbin vers /sbin, et partout ailleurs dans le système. Maintenant, je ne suis pas sûr de considérer cela comme une situation assez mauvaise pour que ça vaille la peine de la changer, mais c'est certainement à prendre en considération. Vraiment, le pré-requis le plus pénible concernant /usr a été la règle qu'il devait être possible de le monter en tant que volume distant. Ça a pu être une bonne idée à l'époque où les disques durs étaient chers et petits, mais aujourd'hui c'est complètement dépassé. Si nous décidions de faire un changement comme celui-là ce serait un changement majeur (et qui assurément justifierait une incrémentation majeure du numéro de version) et je ne sais pas comment (ou si) la mise à niveau à partir d'une version antérieure marcherait. Peut-être avec un outil dans l'installeur qui transformerait le système selon le nouveau schéma ? Jouer ce jeu-là sur une machine en production serait un casse-tête difficile avec une gestion des paquets basée sur des scripts shell utilisant des binaires qui devront simultanément être déplacés partout.

Notons à ce sujet que nous essayons de voir comment gérer au mieux un répertoire de premier niveau /run. Ça fait certainement sens, si ce n'est de le fusionner avec /var/run, d'au moins l'avoir à disposition au début du chargement du système.

Pour autant que ces genres de changements sont envisagés, nous devons être certains qu'ils résolvent des difficultés importantes et nous laissent dans une situation meilleure que celle dans laquelle nous nous trouvions avant, et sans nouveaux problèmes que nous n'avions pas précédemment. Pour sûr, de la manière dont les choses sont à présent jusqu'à ce que /usr soit en place peut-être avons-nous à nous débrouiller avec un jeu limité d'utilitaires, mais nous avons été jusqu'ici capables de faire avec eux dès les premières phases du chargement du système. Si, par exemple les changements nécessitaient d'utiliser un initramfs sur tous les systèmes, je ne considérerais pas nécessairement que cela simplifie les choses.

19) Étant donné le succès de certaines distributions plus jeunes, as-tu des regrets par rapport à la direction qu'a prise Slackware et désirerais-tu que ta création soit adoptée plus volontiers par les masses ? (vdemuth)

Euh… elle est dure celle-là. Bien sûr, en supposant un pouvoir de prescience, je peux rétrospectivement voir plein de ce qu'on pourrait qualifier de « moments Gary Kildall », où faire les choses différemment aurait conduit à la gloire et à la fortune. Est-ce que ça aurait été bon pour moi, ou pour Slackware ? C'est très dur à dire. Regardez ce qui arrive à certains de ces gagnants à la loterie. La raison pour laquelle je n'ai pas saisi les opportunités précoces qui auraient pu prendre ce chemin est que les gens qui avaient l'argent ne voulaient pas vraiment de Slackware. Ils voulaient des parts de marché Slackware à l'époque. Je n'étais même pas sûr qu'ils me voulaient moi — j'aurais pu très vite être poussé hors de l'affaire. Je ne connaissais rien aux start-ups et aux appels de fonds, et très tôt j'ai été rétif à accepter de l'argent pour ce que je faisais, parce que je sentais que ça aurait été profiter de tous les développeurs bénévoles créant les composants que je mettais ensemble. Bien sûr, depuis cette époque une industrie complète s'est développée autour de Linux, et ça ne m'aurait pas dérangé d'avoir une plus grosse part dans tout ça, mais si mon but avait été de faire le plus d'argent possible, je ne suis vraiment pas sûr que ça serait arrivé de toute façon, et il est fort probable que Slackware aurait été un feu de paille ou serait devenue quelque chose de complètement différent. Sous beaucoup d'aspects, Slackware a évolué en outil d'apprentissage. Il y a d'abord une courbe d'apprentissage, puis la gratification d'avoir compris. Slackware ne se mettra pas sur votre route si vous essayez de remplacer ou de recompiler certains de ses éléments. D'une certaine manière, je pense que ça ne deviendra jamais ce que les masses voudront, mais je l'accepte tout à fait.

20) Quels outils utilises-tu pour suivre tous les paquets de Slackware et comment décides-tu ce qui doit être mis à jour et quand ? (trxdraxon)

En réalité il n'y a vraiment pas besoin de beaucoup d'outils spécifiques pour suivre le nombre de paquets que nous avons actuellement. Je conserve des marque-pages de lftp, de sorte qu'il est facile de trouver le site FTP d'un projet en amont en faisant un lftp <paquet> et je laisse quelques trucs dans l'arborescence (paquet.url). À part ça, le gros de la liste des choses à faire et du suivi se fait ici sur deux-trois cahiers. J'en connais certains d'entre vous qui pourraient se marrer à l'idée de suivre les choses sur papier, mais c'est suffisamment efficace pour savoir ce qu'on doit faire ensuite. Une chose plus difficile que de trouver les paquets périmés est d'évaluer l'impact que la mise à niveau d'un paquet donné peut avoir sur l'ensemble du système. Pour une part c'est un travail de réflexion, et pour une autre ça s'appuie sur les leçons du passé. Quand vous faites ça depuis longtemps, vous commencez à avoir une intuition des paquets qu'on peut mettre à niveau sans soucis, et de ceux pour lesquels il faut faire gaffe (malgré les promesses de compatibilité des API/ABI). Nous avons par ailleurs tous nos projets favoris, dont nous suivons le développement et les annonces. Les demandes des utilisateurs sont également incroyablement importantes pour déterminer ce qui doit être mis à jour, spécialement si une mise à jour est nécessaire en tant que dépendance pour quelque chose que nous ne fournissons pas. Nous avons deux-trois outils écrits par Stuart Winter que nous utilisons pour trouver les paquets qui sont liés à une bibliothèque donnée, ou les binaires qui ont besoin d'être recompilés parce que les bibliothèques auxquelles ils sont liés sont devenues manquantes. Ils s'avèrent pratiques lorsque les bibliothèques dynamiques incrémentent leurs numéros de version majeurs. Je pense que ça ne me dérangerait pas d'avoir un script qui rechercherait en amont les nouvelles versions de tous les paquets Slackware et générerait un rapport sur ce qui est disponible, mais on a tendance à trouver ces informations ailleurs de toute manière. Mettre à jour ce qui n'est ni une bibliothèque ni une dépendance pour d'autres paquets peut être fait n'importe quand dès qu'on trouve le temps. Les paquets qui sont une dépendance pour d'autres choses doivent être traités avec plus de prudence, et si quelque chose va engendrer beaucoup de reconstructions il peut arriver que j'attende la mise à jour de certains plus gros morceaux qui vont devoir être reconstruits (par ex. KDE). Si la mise à niveau d'une dépendance va nécessiter la reconstruction de beaucoup de paquets, je fais tout en une fois dans la même fournée. Même dans -current, je n'aime pas voir très longtemps quelque chose de cassé, et laisser les dépendances à la ramasse est absolument hors de question. La maintenance des anciennes versions de Slackware est essentiellement faite pour des raisons de sécurité et dans ce domaine je préfère mettre à niveau les paquets que les patcher si on peut se fier à la compatibilité (cela résoudra parfois en même temps d'autres problèmes), mais si une mise à niveau est susceptible de casser la compatibilité, alors nous préfèrerons patcher les problèmes que risquer de mettre le bazar sur les systèmes en production.

21) Quels sentiments personnels t'inspire la réputation de Slackware ? Est-ce un sujet de fierté pour toi que ta distribution soit considérée comme difficile à installer/utiliser et réservée aux experts, ou bien, considères-tu que c'est négatif parce que cela dissuade les nouveaux utilisateurs d'essayer Slack ? (trademark91)

J'espère que Slackware n'a pas que cette réputation ! Et je ne suis pas d'accord sur le fait qu'elle soit aussi largement répandue. L'objectif, lorsque le projet a été lancé, était de le rendre facile à utiliser et de rester simple. Mais pour paraphraser Einstein, vous voulez rendre les choses les plus simples possible mais pas simplistes. Il y a un point où le gain diminue quand on ajoute des couches supplémentaires et des interfaces, en particulier quand cela concerne la configuration système. J'ai vu des configurations automatiques enlever tous les commentaires dans un fichier de configuration, ou pire le réécrire complètement parce que vous aviez eu l'audace de tenter de l'éditer en dehors du système prévu. Et j'ai vraiment le sentiment qu'au fil des années Slackware a été traitée injustement dans les rapports de tests, largement à cause de la tendance à tester seulement l'installateur et pas le système en tant que tel. Il y a certainement une courbe d'apprentissage mais c'est vrai pour toutes les versions de Linux. Nous n'avons jamais essayé de rendre les choses difficiles, mais peut-être que nous n'avons pas non plus essayé d'empêcher les gens de se tirer une balle dans le pied. Faire des choses comme un alias rm pour rm -i n'incite pas l'utilisateur à apprendre la prudence.

22) La base des utilisateurs passionnés de Slackware a une sale réputation. As-tu quelques mots à lui dire ? (dugan)

Il se peut que Slackware n'ait pas une énorme base d'utilisateurs mais ceux-ci sont extrêmement dévoués et fidèles. Il y a des gens vraiment super dans la communauté Slackware. Merci de me maintenir dans la bonne voie !

23) Par défaut, Slackware installe une sélection inhabituellement étendue d'éditeurs de texte. Quel est celui que tu utilises effectivement ? (dugan)

J'utilise en fait elvis la plupart du temps (par habitude et parce qu'il fait son boulot) mais je suis également un fan de vim. La colorisation syntaxique de vim m'a sans aucun doute fait gagner beaucoup de temps dans le débogage des scripts shell.

Quand j'étais à la Southeast Linux Fest l'année dernière, Andrew Psaltis a donné une conférence sur Emacs qui m'a cependant impressionné au plus haut point. Je disais à certaines personnes de là-bas que j'allais essayer de passer à Emacs. J'ai bien essayé de l'utiliser pendant un certain temps, mais pas assez longtemps pour vraiment être accroché (même si je suis resté impressionné). Quoi qu'il en soit, je suis assez vite retombé dans la facilité avec vi.

24) Comment ça va en général ? Les fans de Slackware peuvent-ils faire quoi que soit pour te simplifier la vie ? (H_TeXMeX_H )

Envoyer des avocats, des armes, et de l'argent ! J'ai vu les choses mieux se passer avant mais je les ai aussi vu se passer plus mal et je suis heureux que nous soyons repartis au Minnesota avant la récession économique … cela aurait été bien pire pour nous sur la côte ouest, financièrement parlant. Je suis très reconnaissant envers les donateurs car ils nous ont permis de rester à flot. Si j'ai de nouvelles idées sur la façon dont les fans de Slackware peuvent nous aider autrement, je vous le ferai savoir. Franchement, un modèle d'entreprise qui est basé essentiellement sur la vente de supports physiques n'a pas beaucoup de sens à une époque où l'accès réseau haut-débit est largement répandu — il suffit de regarder ce que les maisons de disques affirment avoir subi de ce fait. Comment arriver à assurer la viabilité financière du projet est une question prégnante. Peut-être en menant des collectes de fonds périodiques comme le fait la radio publique ?

25) Dans un entretien ancien que tu as donné en 1994, tu déclarais que tu brassais de la bière maison. As-tu encore le temps pour ça actuellement ? À ce sujet, quelle est ta bière préférée ? La bière est-elle ta boisson de prédilection ? (ruario)

Oui, j'ai effectivement brassé de la bière ; cela remonte à des années maintenant. Je n'en ai jamais rebrassé après mon emménagement en Californie, mais j'ai gardé la plus grande partie de mon matériel et ça m'a démangé récemment d'essayer à nouveau. J'ai donc récupéré du malt blond allemand et du houblon de Spalt et je me remettrai à brasser de l'Altbier un de ces jours. J'ai raté la saison fraîche mais la chaufferie reste assez froide en été quand l'air conditionné est en marche (c'est aussi un bon endroit pour y garder les serveurs).

Si je bois de l'alcool, oui, je dirais que la bière est ma boisson habituelle (sinon il y a le café … et les sodas mais j'essaie de réduire ma consommation). La Guinness est une de mes bières favorites (en particulier la Foreign Extra). Pour de la bière bon marché, je prendrai une Pabst Blue Ribbon.

26) J'ai entendu ton entretien sur la Hacker Public Radio. À part Grateful Dead et l'encens, quels autres genres musicaux aimes-tu ? Quand tu ne travailles sur Slackware, quels autres passe-temps ou activités aimes-tu pratiquer ? (kingbeowulf)

J'aime aussi écouter du jazz, des trucs classiques de super musiciens comme Miles Davis et John Coltrane. J'aime aussi J.S. Bach, en particulier les partitas pour clavecin. C'est grâce à Hofstadter et son « Gödel, Escher, Bach: an Eternal Golden Braid » que je me suis intéressé à ces morceaux (ainsi qu'à l'« Offrande musicale » de Bach) qui sont très intéressants autant musicalement que du point de vue mathématique. Earl Scruggs et John Hartford sont mes joueurs de banjo préférés. Au milieu des années 90, je suis allé voir un concert de Jorma Kaukonen (qui jouait en tant que guitare solo pour le groupe Jefferson Airplane) non loin de l'endroit où j'habite maintenant dans le Minnesota. John Hartford était également de la partie, mais je n'étais pas encore très attentif à son style de musique qui consiste en des airs de banjo de style ancien avec beaucoup de chansons qui parlent des bateaux à vapeur et du fleuve Mississippi. J'ai fini par collectionner un grand nombre de ses CDs au fil des ans et je me suis moi-même mis au banjo à 5 cordes probablement à cause de ce concert-là. Comme autre musique, j'écoute du blues, du hot jazz, du big band, du trance/glitch (comme le groupe Oval), des pots-pourris de « found sound » comme Negativland, de la musique country ancienne. Il y a une super station de radio AM à Fallon (Nevada) sur laquelle je me calais lors de mes trajets quand tout ce dont je disposais était la radio de la voiture. Maintenant, j'ai la radio par satellite dans ma voiture … dernièrement, j'ai écouté une station de musique des années 40.

J'aime les voitures anciennes et j'ai une Firebird 1967 que j'ai conduite pendant plus de la moitié de mon existence. Ma femme a acheté une Chevy 1950 l'été dernier. Cette voiture est équipée d'un moteur 6 cylindres Stovebolt 230 et a seulement 85.000 km au compteur mais elle va nous demander du boulot… il faut tirer le starter à fond et elle semble s'étouffer à chaud. J'ai un kit de reconstruction pour le carburateur Rochester B qui devrait améliorer les choses (il y a une fuite de gaz au niveau des joints) et je vais peut-être aussi examiner les fuites de la pompe à vide ou le réchauffeur qui se bloque et brûle le carburant. Ah, de super réjouissances en perspective pour un fondu de la mécanique !

Je suis également passionné par la photographie. J'avais l'habitude de prendre des photos en noir et blanc (Kodak Tri-X) et de les développer moi-même. Maintenant, tous mes appareils photo sont numériques et je ne possède pas de reflex mono-objectif (SLR) mais j'aime toujours voir si je peux obtenir de bons résultats avec un équipement relativement bon marché. J'utilise un Canon S90 point and shoot qui bénéficie du firmware amélioré CHDK (Canon Hacker's Development Kit), ce qui me permet d'avoir un grand nombre de fonctionnalités avancées qu'on ne trouve normalement que sur les reflex mono-objectif. Le Canon S90 peut enregistrer nativement des images au format RAW mais même des appareils Canon moins chers peuvent le faire en utilisant le kit CHDK. J'ai pris une tonne de photos selon la technique de la prise de vues en fourchette (bracketing) qui consiste à prendre une série de photos à des expositions différentes qui peuvent être combinées pour faire des photos à grande gamme dynamique (High Dynamic Range). J'ai aussi fait de la photographie aérienne par cerf-volant (Photo cervolisme) à l'aide des fonctions de temporisation du kit CHDK, en réglant l'appareil photo pour prendre une image toutes les 15 secondes et en l'envoyant en l'air attaché à un cerf-volant. Jusqu'ici tout s'est bien passé, j'ai récupéré l'appareil intact et j'ai ainsi obtenu de super photos.

27) Au cours des années, tu as dû accorder vraiment peu d'entretiens. Y a-t-il une question que tu aurais depuis toujours aimé que quelqu'un te pose sans jamais le faire ? (jeremy)

Veux-tu qu'on rentre chez moi s'envoyer en l'air ?

Non, je plaisante, mais je n'ai pas pu résister à placer une référence aux Monty Python ici. :-) Et pour répondre à la question, aucune à laquelle je puisse penser.

Merci tout le monde, ça a été marrant ! Faisons ça sur Reddit un de ces jours.

Bonne continuation,

Pat

Aller plus loin

• Texte original de l'entretien avec Patrick Volkerding sur LQ (186 clics)
• Slackware (47 clics)
• Le forum Slackware sur LinuxQuestions (70 clics)
• Slackware sur Wikipédia (53 clics)
• Dépêche sur LinuxFr.org de l'entretien avec Patrick Volkerding sur LQ (130 clics)
• Patrick Volkerding sur Wikipédia (63 clics)
• Portail Slackware-fr (104 clics)