L'aimable Fredrick Brennan m'a demandé mes commentaires sur la discussion concernant la suppression de ReiserFS V3 du noyau. Je ne poste pas directement parce que je suis en prison pour avoir tué ma femme Nina en 2006.
Je suis vraiment désolé pour mon crime - des excuses en bonne et due forme seraient hors sujet pour ce forum, mais elles sont disponibles pour tous ceux qui le demandent.
Des excuses détaillées sur la façon dont j'ai interagi avec la communauté du noyau Linux, ainsi qu'un historique des V3 et V4, sont inclus, de même que des descriptions des problèmes techniques. J'ai participé à des ateliers en prison et j'ai travaillé dur pour améliorer mes compétences sociales afin de devenir moins dangereux pour la société. L'homme que je suis aujourd'hui agirait très différemment de ce que j'ai fait à l'époque.
Peut-être que certains accepteront mes excuses ; d'autres apprendront de mes erreurs si je les décris bien ; d'autres encore trouveront les problèmes de conception intéressants.
Je laisserai aux utilisateurs le soin de décider si ReiserFS V3 est toujours utile. Les utilisateurs doivent comprendre que c'est un fardeau pour ceux qui maintiennent VFS et autres de devoir tester leurs changements sur un système de fichiers supplémentaire, en particulier parce que les systèmes de fichiers Linux sont codés en dur au niveau de la couche VFS.
ReiserFS 4 fournit une base plus facile à maintenir pour l'avenir pour les utilisateurs qui aiment les fonctionnalités de la V3. Si V3 n'est pas utilisé, il doit disparaître. Je fais confiance aux utilisateurs et aux responsables du noyau pour discuter de son utilisation et prendre ensemble la bonne décision.
Message principal
La V3 a eu un moment d'utilité, et je suis heureux que nous ayons pu contribuer au succès de GNU/Linux pendant quelques années cruciales au cours desquelles son utilisation a connu une croissance rapide. La contribution de Chris Mason à la journalisation a été la fonctionnalité la plus utile de la V3, et je l'en remercie.
Je suis triste que SUSE n'ait pas réussi à s'imposer sur le marché, j'ai trouvé que c'était une distribution bien conçue et ce fut un privilège de pouvoir y contribuer. Je leur suis reconnaissant pour leur parrainage et leur soutien.
Reiser FS V3 a été notre premier système de fichiers, et nous avons fait des erreurs parce que nous ne savions pas ce que nous faisions. Je dois vous dire que lorsque j'ai fait les premiers benchmarks, les performances étaient terribles, et je ne savais pas pourquoi. Par terribles, je veux dire qu'aucune personne sensée ne l'utiliserait pour quoi que ce soit, il y a eu des années de sombre dépression avant qu'il ne soit suffisamment débogué pour fonctionner, et puis, 5 % ici et 5 % là, je l'ai amené à être un peu plus rapide que la concurrence, et à gagner de l'espace pour les tailles traditionnelles de systèmes de fichiers, et plus d'espace pour les petits fichiers. La modification de l'allocation des blocs aux fichiers - un code simple heureusement - a permis d'obtenir la plupart des gains de performance. Lors du réglage des performances de la V3, Ext2, le système de fichiers GNU/Linux existant, s'est avéré être un système de fichiers très performant, probablement le meilleur au monde. L'homme que j'étais à l'époque a présenté des documents contenant des repères montrant que ReiserFS était plus rapide qu'Ext2. L'homme que je suis aujourd'hui commencerait ses articles en leur attribuant le mérite d'être plus rapides que les systèmes de fichiers d'autres systèmes d'exploitation, et en les remerciant pour les années pendant lesquelles nous avons utilisé leur système de fichiers pour écrire le nôtre. Ne pas faire cela a été ma première grave erreur sociale dans la communauté Linux, et c'était complètement inutile.
Vladimir Saveliev, qui a eu pitié de moi et est revenu après que tous les autres aient abandonné, est l'homme qui a fait fonctionner le code suffisamment bien pour que quelqu'un veuille l'utiliser pour plus qu'un point de repère. Après son retour, je lui ai confié le débogage. C'est l'un des hommes les plus bons, les plus doux et les plus travailleurs qui soient, tous ceux qui ont travaillé avec lui en conviendront. Il n'en parlait pas beaucoup, mais il croyait au mouvement du logiciel libre. À force de volonté et de travail, il est devenu un programmeur d'une compétence extraordinaire, dont vous pouvez voir les effets dans notre code Reiser4. Il est passé du statut de programmeur le plus jeune au début de la V3 à celui de programmeur principal, en gagnant sa place par un travail acharné.
En supposant que la décision soit de retirer la V3 du noyau, je n'ai qu'une seule requête : que pour une dernière version le README soit édité pour ajouter Mikhail Gilula, Konstantin Shvachko, et Anatoly Pinchuk aux crédits, et pour supprimer tout ce que j'aurais pu y dire sur les raisons pour lesquelles ils n'ont pas été crédités. Il est temps de lâcher prise.
En prison, j'ai travaillé dur pour développer mes compétences sociales, en particulier mes compétences en matière de résolution et d'évitement des conflits. Il y a beaucoup de conflits en prison, comme vous pouvez l'imaginer, et c'est un bon endroit pour apprendre ces compétences. Il n'y a rien de tel que beaucoup de pratique, et les groupes qu'ils nous permettent de suivre si nous le souhaitons ont un programme assez bien développé, la répétition aide, du moins pour moi. Cela m'a changé.
J'avais tendance à voir les gens dans les extrêmes. J'y travaille en y étant attentif et en côtoyant des gens qu'il serait facile de voir dans les extrêmes, Beaucoup d'entre eux sont devenus de très bonnes personnes [sic] depuis leurs crimes.
Je regarde en arrière, avec l'avantage que le passage des années a contribué à améliorer ma vision, et je vois que si j'avais l'intention d'être utile à des chercheurs en Russie vivant avec moins de cent dollars par mois, je ne pouvais pas être aussi utile qu'un travailleur en Amérique gagnant un salaire occidental. J'ai mis tout ce que j'avais dans le projet, en travaillant plus de 40 heures par semaine dans un emploi de jour, la plupart des employeurs n'étant pas satisfaits que je veuille travailler seulement 40 heures si je le pouvais, et j'ai ensuite passé 15 à 20 heures par semaine à discuter d'algorithmes, d'architecture, de code, etc. par courrier électronique. J'ai appris à faire abstraction de tout ce qui se passait dans ma vie en dehors du projet, car sinon mon rêve n'aurait pas pu se réaliser.
J'avais plus de rêves que d'expérience. Je pense que Mikhail Gilvla était l'esprit le plus brillant de sa génération d'informaticiens et que son talent a été gâché. D'abord parce que l'économie russe rendait son succès impossible, puis en Amérique parce que la plupart des spécialistes des bases de données n'étaient pas en mesure de comprendre qu'il avait raison de vouloir réécrire les bases de leur domaine comme il l'entendait, parce qu'il était tellement plus brillant qu'eux. Je ne pense pas qu'ils aient pu comprendre pourquoi c'était important, ce qu'il voulait faire.
Nous pensions tous deux que l'algèbre relationnelle était un cas particulier de quelque chose de plus général, quelque chose qui était nécessaire pour les "données semi-structurées". Il a appelé son approche "théorie des ensembles" et l'a mise en œuvre sous la forme d'une base de données. J'avais ma propre syntaxe qui étendait l'espace de noms du système de fichiers. Nous avons eu nos idées indépendamment l'un de l'autre, avant de nous rencontrer.
J'avais l'idée que l'endroit où l'implémenter était un système de fichiers, et que la motivation pour l'implémenter à cet endroit était de le faire évoluer vers un espace de noms qui permettrait d'unifier tous les espaces de noms du système d'exploitation en un seul espace de noms. Je pensais qu'il s'agirait de la refonte de code la plus importante jamais réalisée et qu'elle augmenterait le pouvoir d'expression de tout ce qui se trouve dans ces espaces de noms. J'ai fait des analogies entre l'effet des routes et des voies navigables sur le développement de la civilisation selon Adam Smith, et les effets du libre-échange sur la spécialisation et donc la richesse selon Adam Smith à nouveau, et les effets de l'unification des espaces de noms sur la puissance expressive du système d'exploitation.
C'était mon rêve.
Je n'étais pas le seul à faire ce rêve. Le terme "espace de noms" n'est pratiquement utilisé que par les personnes qui partagent suffisamment ce rêve pour utiliser un terme qui implique une équivalence entre les bases de données, les systèmes de fichiers, le DNS, etc. Rob Pike et Plan 9 sont des exemples de travaux visant à élargir l'espace de noms du système de fichiers. Ma vision particulière du rêve était que je disposais d'une syntaxe permettant d'élargir l'espace de noms hiérarchique du système de fichiers afin de traiter des "données semi-structurées". Cela signifie que les requêtes sont construites à partir de primitives qui peuvent être combinées dans l'équivalent des requêtes des moteurs de recherche (associations non structurées), des requêtes de bases de données (paires ordonnées non ordonnées pour rechercher des tables), ou des systèmes de fichiers (noms entièrement ordonnés pour rechercher des hiérarchies), ou des choses qui sont plus riches que n'importe lequel de ces cas spéciaux. Voilà ce dont je rêvais ! Vous ne serez probablement pas surpris d'apprendre que j'étais adolescent lorsque j'ai eu l'idée de ce rêve et de sa syntaxe pour la recherche de données semi-structurées.
Je m'excuse auprès des utilisateurs qui n'ont pas pu réaliser ce rêve à cause de mon crime et de mon incarcération, et qui n'ont pas pu voir les améliorations sémantiques apportées à Reiser 4.
La tâche la plus difficile sur le plan technique, qui était une condition préalable à la mise en œuvre de ma syntaxe, une tâche qui devait être mise en œuvre en premier pour que les choses se passent bien, était de rendre le système de fichiers efficace pour les petits fichiers.
Dès le début, j'ai été très sensible au pouvoir des effets de réseau pour noyer les efforts visant à changer les paradigmes, à introduire de meilleures façons de faire les choses. Les effets de réseau étant abstraits, je les comprenais mieux que l'importance de croire que je pouvais me faire des amis et des alliés parmi des personnes qui commençaient par être hostiles parce que je ne leur avais pas donné le sentiment d'être incluses.
La conscience des effets de réseau est la raison pour laquelle j'ai décidé que le chemin vers l'unification des espaces de noms du système d'exploitation commençait par l'amélioration de la sémantique du système de fichiers, qui commençait par la création d'une couche de stockage qui pourrait émuler un système de fichiers plus rapidement que n'importe quel système de fichiers existant, mais qui pourrait aussi être efficace pour stocker de petits objets comme le sont les bases de données. Oui, c'était arrogant de tenter cela, mais il semblait possible de le faire. Je n'avais aucune idée du temps qu'il faudrait pour y parvenir.
Mikhail m'a conseillé d'utiliser des arbres équilibrés au lieu du hachage extensible (ce que dcache utilise). J'allais finir par comprendre que la localité de référence est la condition sine qua non de la performance, et que les arbres équilibrés sont les meilleurs outils pour mettre en œuvre des moyens astucieux de maximiser la localité de référence, Mikhail avait essayé le hachage extensible, et avait appris à ses dépens qu'essayer de résoudre ses problèmes conduisait à utiliser des arbres équilibrés. La localité de référence n'affecte pas seulement les performances des disques durs, elle affecte les performances des données compressées (c'est-à-dire les performances de la SPRAM), et même les performances du cache de l'unité centrale (et donc les performances des données stockées dans la DRAM). Il m'a dit qu'il me faisait gagner deux ans en me disant d'utiliser des arbres équilibrés, et c'est vrai, et je l'en remercie,
Je n'ai jamais dit à Mikhail qu'Oracle avait essayé d'implémenter un système de fichiers en utilisant des arbres équilibrés, et que ses performances étaient terribles, ce qui a conduit la plupart des initiés de l'industrie à conclure que les arbres équilibrés étaient peu performants pour les modèles de taille de fichiers du système de fichiers. Je ne l'ai pas dit à Mikhail, je ne l'ai dit à aucun des programmeurs, je ne l'ai dit à personne impliqué dans le projet. Je ne voyais pas pourquoi ils seraient plus lents, alors je n'en ai pas tenu compte. Vladimir aurait de bonnes raisons d'être en colère contre moi s'il lisait ceci.
Je pense qu'une partie de leurs problèmes de performance était liée à la façon dont ils géraient leur journalisation. J'ai observé que la plupart des implémentations d'arbres équilibrés sont trop synchrones, et que la plupart des systèmes de fichiers ne sont pas très synchrones pour des raisons de performances. fsync() revient à utiliser un marteau de forgeron pour faire tourner une vis en donnant des coups latéraux répétés sur la tête de la vis. Ce qu'il faut pour avoir des garanties d'intégrité des données élevées sans pertes de performances inutiles, c'est une nouvelle API qui permette de le faire intelligemment en permettant aux différentes couches de partager leur plus grande intelligence avec les autres couches. Nous devons permettre à l'utilisateur de partager son intelligence avec l'application, à l'application de partager son intelligence avec le système de fichiers, au système de fichiers et au planificateur de processus de partager leur intelligence avec le planificateur d'E/S, au planificateur d'E/S de partager son intelligence avec le planificateur d'E/S et d'autres aspects du disque dur, puis de partager l'intelligence dans l'autre sens de cette pile, et d'y associer également le gestionnaire de mémoire. Il ne suffit pas d'ordonner les E/S, mais de spécifier des groupes d'E/S qui doivent s'engager ou non en tant que groupe, afin de communiquer cette intelligence et de ne pas être plus synchrone que nécessaire. D'autres caractéristiques relatives aux priorités, à l'équité, à la garantie des taux d'E/S, etc. seraient également souhaitables. C'est un domaine dans lequel Reiser 4 devrait faire plus que ce que nous avons eu le temps de faire.
J'aurais aimé avoir l'argent nécessaire pour retenir Joshua MacDonald quand Orade l'a embauché loin de moi, et en apprendre plus de lui sur les idées logiques de journalisation qu'il avait à l'époque, j'espère qu'il se porte bien - c'était tout simplement un jeune homme brillant, je dirai simplement que la journalisation par alignement de blocs n'est pas nécessairement optimale pour tous les besoins de l'espace utilisateur, et je renverrai le lecteur à lui pour plus d'informations. Ce que je ne savais pas lorsque nous nous disputions sur la conception de la V3, c'est que les références au FFS sont trompeuses et ne mettent pas en évidence quelque chose qui nuit également aux performances de la base de données, le FFS est le système de fichiers BSD, et il était considéré comme le meilleur de son époque. Il utilisait des blocs de 4k, à l'exception de la fin des fichiers pour lesquels il utilisait des blocs de 1k, et il combinait ces blocs de 1k provenant de différents fichiers dans le même bloc de 4k, ce qui leur permettait d'augmenter la taille des blocs tout en conservant de l'espace.
Cela semble tout à fait correct, n'est-ce pas ? Hélas, le coût en termes de performances de l'extraction des queues de fichiers hors de la ligne du reste du fichier pour les combiner avec les queues d'autres fichiers est une recherche plus un délai de rotation (20 ms), ce qui est extrêmement coûteux par rapport à la taille de la queue divisée par le taux de transfert, les recherches dominant les performances du système de fichiers à moins que la disposition ne soit parfaite. Les recherches dominent les performances du système de fichiers à moins que la disposition ne soit parfaite. Vous pouvez voir l'importance d'éviter d'ajouter des recherches en plaçant la queue d'un fichier en ligne avec le reste du fichier,
Les bases de données avec leurs "BLOBS", ReiserFS V3 et FFS combinent toutes les queues d'une manière qui ajoute des recherches et nuit considérablement aux performances. Pour les bases de données et ReiserFS V3, c'est encore pire, car les BLOBS font qu'il ne s'agit pas vraiment d'un arbre équilibré, et la capacité de mettre en cache efficacement tous les nœuds internes de l'arbre est perdue. Recherchez "Reiser 4 twigs" sur Google, et vous trouverez une discussion plus longue à ce sujet pour les lecteurs intéressés, y compris sur la manière de résoudre le problème.
Les plugins, et la modularité du code qu'ils ont créé, sont la caractéristique la plus importante de Reiser 4. Il est beaucoup plus facile d'ajouter des fonctionnalités à Reiser 4 que de les ajouter à d'autres systèmes de fichiers, parce qu'il suffit d'ajouter de nouveaux plugins. Le plus dur est fait, et les nouvelles fonctionnalités ne sont qu'une descente. Enfin, sauf que je suis en prison et que je dois donc laisser tout cela à d'autres.
Il y a un problème que les systèmes de fichiers ont, et c'est que les changements de format ne sont pas désirés par beaucoup pour de bonnes raisons, c'est la raison principale pour laquelle les systèmes de fichiers stagnent, eh bien, cela, et stagner est facile...
J'avais juste à corriger tous ces défauts, les corriger et faire un système de fichiers qui était bien fait. Il est difficile d'expliquer pourquoi je devais le faire, mais je ne pouvais pas me reposer tant que la conception était mauvaise et que je savais qu'elle l'était.
SUSE ne voulait pas d'un changement de format, ils voulaient des améliorations incrémentales jusqu'à la V3. C'est ainsi que les choses se passent pour beaucoup d'architectes de systèmes de fichiers. Ils changent progressivement des choses qu'ils savent être profondément mauvaises pour leur cœur, mais ils sont coincés dans la misère de le faire. J'ai dit non à cela, ce dont je ne m'excuserai pas et que je ne regrette pas, parce que j'ai une âme et que j'avais un rêve. Ce dont je m'excuse, c'est de l'inarticulation et du manque de sociabilité dont j'ai fait preuve en expliquant cela à SUSE. Ce que j'ai essentiellement dit à SUSE, c'est que le code n'était pas maintenable et qu'il fallait le réécrire à partir de zéro, croyez-moi, il fallait le faire, nous ne savions pas ce que nous faisions à l'époque et maintenant nous avons appris ce que nous aurions dû savoir, mais nous corrigerons tous les bogues dans la V3 qui seront découverts.
J'aurais pu dire que je les entends, et que je les entends bien, si bien que Reiser 4 a des plugins de format de nœud qui résolvent le problème du changement de format. J'aurais pu leur parler de nos projets de reconditionnement pour Reiser 4, afin que les partitions puissent être réduites et la disposition parfaitement optimisée, et ... passer une journée à leur rendre visite et à faire de Reiser 4 notre rêve et non le mien. Au lieu de cela, j'ai fait savoir que je ne pouvais pas poursuivre mon rêve sans changer de format. SUSE et moi-même voulions ce qu'il y avait de mieux pour Linux et SUSE. La raison de mon échec était donc que je n'avais pas réussi à établir un lien social en dépassant l'hostilité initiale au changement de format pour faire de mon rêve (et de celui de la DARPA) notre rêve. J'ai répété ce style d'échec avec la communauté du noyau Linux lorsque Reiser 4 a été soumis pour inclusion, mais en pire.
Permettez-moi de remonter le temps jusqu'aux premiers jours de la V3. Peu de temps après l'achat des ordinateurs et le démarrage du projet, Mikhaïl a trouvé un emploi aux États-Unis, et c'est grâce à lui que j'avais engagé ce groupe. Désormais, je n'avais plus sur place quelqu'un avec qui j'étais intellectuellement compatible, et des frictions sont apparues. Je ne les avais pas choisis, et ils ne m'avaient pas choisi, pas plus qu'ils n'avaient choisi mon rêve ou le mouvement du logiciel libre. Hélas, j'étais inexpérimenté, et ils ne le respectaient pas, ce qui est compréhensible, n'est-ce pas ? J'avais un sens des abstractions plus fort que mon sens des gens, et un plaisir désinvolte à bousculer les algorithmes socialement établis qui les rendait encore moins à l'aise que le fait de porter un chapeau de cow-boy au lieu d'une cravate, Rien de tout cela n'était un problème avec Mikhail, mais Mikhail était parti.
Il fallait s'attendre à ce qu'il y ait des problèmes, mais j'étais trop jeune et trop plein d'espoir pour m'en rendre compte. Passer d'administrateur système à architecte sans avoir passé quelques années en tant que codeur avait un coût.
L'utilisation de BLOBS dans la V3 en est un exemple. Je ne savais pas que le fait de placer des nœuds non formatés à un niveau de l'arbre en dessous des feuilles putatives de l'arbre était la manière standard de faire les choses dans le monde des bases de données. Lorsque je l'ai vu dans le code, je m'y suis opposé. J'étais trop inexpérimenté en tant que chef de projet logiciel pour savoir qu'il s'agissait d'un argument à ne prendre en compte qu'après la livraison de la première version d'un produit, car tout ce qui est écrit avant la livraison du produit n'est pas susceptible d'être réécrit avant la livraison du produit, surtout si vous savez que la conception est erronée. C'est particulièrement vrai si l'on sait que la conception est mauvaise. Ce que je ne savais pas, c'est à quel point la conception était mauvaise, le coût des performances était plus élevé que je ne le craignais, je devrais également dire que le coût du codage pour faire les choses correctement était plus élevé que je ne le pensais, Aux jeunes architectes, laissez-moi vous dire que si vous savez que quelque chose est mauvais, ne le laissez pas se produire juste pour être agréable ou pour accepter le consensus, Oui, écoutez tous les arguments, mais si vous n'avez pas une meilleure perception des algorithmes, vous ne devriez pas exercer le métier d'architecte. Croyez en vous, j'ai payé le prix pour ne pas avoir su être ferme, quand les benchmarks sont arrivés, et encore une fois quand les corriger a nécessité un changement de format qui m'a fait perdre SUSE.
Ensuite, l'employeur de Mikhaïl a embauché les autres et m'a laissé avec un tas de code mal commenté qui ne pouvait pas fonctionner. Il aurait été plus sage pour moi de le réécrire à partir de zéro, mais cela aurait signifié admettre que tout ce que j'avais investi dans le projet était une perte totale.
Maintenant, avec la distance du temps, je peux voir que leur départ était simplement la chose raisonnable de leur point de vue, Il y a eu quelques désagréments dans la façon dont ils sont partis, mais c'est à prévoir, dit la distance du temps, Alors je me suis senti tellement trahi. Aujourd'hui, je souhaite oublier cela. Ce n'étaient que des gens ordinaires pris dans les forces économiques et qui n'appréciaient pas de travailler pour le type qui avait plus de rêves que d'expérience. Eux aussi étaient inexpérimentés : aucun d'entre nous n'avait travaillé sur un système de fichiers auparavant. Nous étions tous jeunes et impatients. Je n'ai jamais réussi à gagner assez d'argent pour pouvoir bien payer les gens, et j'en suis vraiment désolé. Si je n'avais pas commis mon crime, le jour où Reiser 4 a été une utilisation digne de l'extraordinaire talent des programmeurs qui y ont travaillé serait probablement arrivé. J'ai été insensible et indifférent à leurs besoins et à leurs rêves lorsque j'ai commis mon crime, je les ai victimisés financièrement et j'ai ruiné les rêves que je leur avais fait miroiter.
L'un de mes grands regrets est d'avoir laissé tomber Mikhail en tant qu'ami. J'espère qu'il est toujours en vie et qu'il se porte bien.
Un vendredi, j'ai lu sur Slashdot qu'un appel d'offres de la DARPA pour des logiciels libres avait été lancé et que la date limite de soumission était fixée au lundi. Je suis entré dans une frénésie d'écriture et j'ai proposé ce qui est devenu Reiser 4. La DARPA a été très gentille avec nous, et j'ai beaucoup appris sur la comptabilité et la sécurité grâce à eux. J'aimerais m'excuser auprès de la DARPA pour deux choses :
- Tout ce que nous avons pu réaliser, c'est l'infrastructure permettant d'activer les fonctions de sécurité que j'avais proposées, et ce malgré le fait que j'ai investi dans le projet plusieurs fois l'argent qu'ils nous avaient donné, y compris en utilisant des avances de fonds sur carte de crédit à 29 % d'intérêt pour payer les salaires vers la fin du projet. Maintenant que Reiser 4 est stable, l'infrastructure des plugins rendrait si facile l'ajout de fonctionnalités supplémentaires, que nous aurions probablement pu réaliser le plugin d'encryptage et l'héritage des données statistiques en seulement 6 mois.
- À l'époque où j'ai fait la proposition de Reiser 4, il semblait que la démocratie avait gagné en Russie, je crois que nous étions un point de lumière dans les relations américano-russes, le problème était qu'il fallait un millier de points de lumière, et nous étions l'un des rares.
Les services de renseignement et les forces de l'ordre russes, après s'être assurés que nous n'étions pas une opération de couverture de la CIA, ont été très aimables avec nous et nous ont soutenus, nous et le mouvement du logiciel libre. Ce n'est peut-être pas une coïncidence si nous n'avons pas eu de problèmes avec la mafia. Je sais que l'on n'est pas censé dire du bien d'eux, mais mon expérience personnelle est qu'ils ont été très efficaces, gentils, et même sagement guidés. D'une manière importante,
La culture russe permet de mieux comprendre les gens. Par exemple, l'un d'entre eux m'a dit que ma femme souffrait beaucoup. Aujourd'hui, je vois clairement que c'était tout à fait exact et que cela m'a parfaitement éclairé sur la voie que j'aurais dû suivre. Hélas, je n'ai pas eu la sagesse de comprendre les mots en les répétant une seule fois.
En prison, j'ai appris que l'aliénation, que j'ai l'intention d'utiliser pour me protéger, est souvent une cage que je construis autour de moi. La peur d'être naïf peut souvent être aussi dangereuse dans ses distorsions de la réalité que le fait d'être naïf. Ce n'est pas le moment d'essayer d'être une lumière dans les relations entre les États-Unis et la Russie. J'espère qu'il y aura à nouveau un tel moment, et qu'il y aura une fin à tous ces morts et ces mourants. J'espère que le temps viendra à nouveau pour dépasser l'aliénation et trouver l'amitié et l'amour entre la Russie, l'Ukraine et les États-Unis, ainsi qu'entre mes enfants et moi.
Revenons à Reiser4 : nous avons construit un magnifique système de fichiers qui intégrait tout ce que nous avions compris que nous aurions dû faire la première fois, appelé Reiser 4, et il fonctionnait. De plus, il avait cette architecture de plugins que j'avais proposée à la DARPA dans cette frénésie d'écriture, mais que Nikita Danilov avait rendue encore meilleure que ce que j'avais proposé (il a aussi fait les plugins d'opérations d'équilibrage, et je suis si heureux qu'il ait été plus intelligent que moi et qu'il ait montré que les coûts en termes de performances étaient acceptables).
Avec la plupart des systèmes de fichiers, l'ajout d'une fonctionnalité consiste à 80 % à modifier le code existant et à 20 % à écrire la nouvelle fonctionnalité, et vous risquez alors d'ajouter un changement de format que quelqu'un qui ne travaille même pas dans le groupe du système de fichiers refusera. Avec Reiser 4, nous avons transformé en plugin tous les aspects de Reiser pour lesquels nous pouvions imaginer le faire. Si vous voulez ajouter une nouvelle fonctionnalité, vous passez simplement votre temps à écrire les nouveaux plugins pour cela, et 90 % du temps c'est tout ce que vous aurez à écrire, ou à défaut, ce sera 80 % de ce que vous aurez à écrire, vous pouvez passer votre temps sur votre idée intelligente au lieu de vous demander pourquoi c'était tellement plus difficile que ça aurait dû l'être de l'écrire. Je pense que vous trouverez qu'il est plus de 3 fois plus rapide de l'ajouter à Reiser 4 qu'à n'importe quel autre système de fichiers, avec toutes les fonctionnalités requises d'un système de fichiers pour la compatibilité (un fardeau énorme à écrire - si vous avez une idée intelligente de système de fichiers, épargnez vous ce fardeau et ajoutez un plugin à Reiser 4 à la place - vous pouvez être un programmeur faisant un plugin de 6 mois au lieu d'avoir à financer une équipe pendant 5 ans pour faire un système de fichiers) terminé, tout allait être en baisse à partir de là. Le code écrit par Alexander Zarochentcev, Nikita Danilov et Vladimir Saveliev (tous trois contribuant à parts égales, travaillant ensemble comme les trois mousquetaires) était magnifique, puis le programmeur junior Edward Shishkin est arrivé en tant que quatrième mousquetaire et son plugin de compression a encore doublé les performances pour les fichiers compressibles. Je ne me souviens pas avoir trouvé quoi que ce soit à améliorer dans le code d'Alexander Zarochentcev : il était toujours parfaitement écrit, du genre "lisez-le et apprenez comment les choses devraient être écrites".
Je ne suis pas connu pour être incapable de trouver des choses à critiquer ou à louer facilement. D'une manière ou d'une autre, avec le plus petit budget pour les payer dans le monde du système de fichiers, j'ai eu la chance d'avoir la meilleure équipe de programmation dans le monde du système de fichiers. Le système de fichiers était digne de leurs talents - j'aurais aimé être digne d'eux en tant que personne.
Le problème était qu'il n'utilisait pas le code écrit par d'autres membres de la communauté du noyau, et les gens n'aiment pas vraiment que leur code ne soit pas utilisé. Les gens veulent se sentir inclus. J'ai répondu à leur besoin social en, eh bien, faisant des bêtises en réponse (benchmarks et contestation de leur expertise). Imaginez que j'aie répondu en disant que j'avais besoin de leur aide pour imaginer de nouveaux plugins de fichiers ?
Vous savez que les gens sont beaucoup plus enclins à lire un e-mail s'il est long d'un écran, plutôt que de la longueur de ceci :-/ ? C'est la même chose avec la contribution au code du noyau. Il est beaucoup plus social et plus propice aux relations de contribuer à un ou deux écrans de code une fois toutes les semaines ou toutes les deux semaines pendant des années. Nous leur avons livré 90 000 lignes de code d'un coup, après avoir travaillé dessus dans un isolement social total pendant 5 ans à Moscou. La méthode la plus sociale consiste à procéder par petites étapes. Les améliorations progressives de la V3 n'auraient rencontré aucune opposition. Nous aurions pu vivre une vie en étant un peu meilleurs que ext3, et être respectés dans le domaine en attendant que quelqu'un de jeune nous rende obsolètes,
Hélas, il a fallu repartir de zéro pour l'écrire correctement, l'écrire du mieux que je savais le concevoir, pour corriger ce que les benchmarks avaient révélé à un empiriste. Mes échecs en matière de leadership et de gestion de projet devaient être expiés. La maintenabilité d'un système de fichiers basé sur des plugins était peut-être plus importante que les benchmarks, j'avais ajouté des commentaires, et nous avions ajouté des corrections de bogues, mais je suis si heureux de n'avoir rien gardé de tout cela pour la V4.
Si j'avais eu les compétences en matière de résolution des conflits que j'ai acquises dans les cours d'intervention cognitivo-comportementale en prison, j'aurais peut-être été capable de surmonter tout cela.
Ensuite, mon attitude a été la suivante : c'est le système de fichiers le plus rapide au monde, pourquoi n'êtes-vous pas heureux et utiles ? Regardez ces benchmarks ! Ces plugins ! Pourquoi dois-je traiter avec ces gens qui n'ont pas écrit un système de fichiers aussi rapide ? Laissons-les écrire les leurs, et nous écrire les nôtres - VFS devrait le permettre ! Mon attitude aurait dû être d'ignorer l'hostilité, il faut s'y attendre au début et la surmonter, je peux surmonter l'hostilité, et la façon de le faire est simple : 1) faire en sorte que les gens se sentent appréciés et pris en compte, 2) faire en sorte que les gens se sentent inclus, 3) faire en sorte que les gens aient envie de faire des choses avec ces plugins eux-mêmes en leur demandant leurs idées sur les plugins qu'ils pourraient imaginer.
Je sais maintenant qu'il est possible de surmonter ces problèmes si je m'applique activement à trouver une voie émotionnelle ou sociale pour que les gens se sentent bien.
Le plus important est de croire que je peux y arriver. Auparavant, je n'avais pas la capacité d'imaginer que je pourrais réussir à surmonter l'hostilité, mais en faisant les exercices dans mes cours d'intervention cognitivo-comportementale en milieu carcéral, j'ai commencé à voir que je pouvais le faire, j'ai commencé à croire que je pouvais le faire,
Si vous croyez que vous pouvez le faire, vous le pouvez généralement, lorsqu'il s'agit de faire en sorte que les choses se passent bien avec les autres, si vous vous concentrez sur la recherche d'un moyen de surmonter un problème, plutôt que sur votre sentiment d'avoir été lésé, vous pouvez généralement surmonter un problème relationnel. Si vous échouez, vous n'avez rien perdu ou presque en essayant de le faire, alors pourquoi avoir peur de le faire ? Contrairement à ce que les jeunes hommes craignent si souvent, si vous échouez dans une telle tentative, vous ne perdez pas la face - vous gagnez le respect des autres qui vous regardent essayer - en particulier les plus âgés. Si vous prenez l'habitude de toujours essayer, vous deviendrez inévitablement bon.
L'un de mes rêves est de convaincre un jour la législature de l'État d'enseigner le programme qu'ils enseignent à nous, les prisonniers, à l'école élémentaire, afin que les gens comme moi puissent mieux l'apprendre sans avoir à aller en prison pour l'apprendre, j'essaie de convaincre quelques personnes de le présenter aux législateurs - si quelqu'un souhaite m'aider, faites-le moi savoir. Il ne s'agit pas seulement d'éviter la prison, mais aussi de résoudre tous les conflits relationnels, et qui n'en a pas ? Le cours sur la parentalité en prison devrait également être enseigné au lycée...
Un exemple de ce que j'aurais pu faire différemment, c'est lorsque Viro a annoncé qu'il y avait une situation de compétition dans notre code, mais qu'il ne nous dirait pas où elle se trouvait parce que si nous ne pouvions pas auditer notre code pour les situations de compétition, nous ne devrions pas être autorisés à entrer dans le noyau, Viro était un type dont l'orientation de carrière était insuffisante, je ne savais rien sur l'audit de code pour les situations de compétition, et malheureusement Google ne m'a pas aidé à trouver comment auditer les situations de compétition. Mon attitude à l'époque était que cela semblait être un travail nécessaire mais fastidieux, vraiment fastidieux, qu'avec un peu de chance les gars qui faisaient le débogage trouveraient pendant que j'essayais d'obtenir l'argent pour leur prochain chèque de paie. J'aurais dû faire plus que communiquer le problème, j'aurais dû demander "
quel est le plan d'audit pour les situations de compétition, et m'aider à trouver de la documentation sur la façon de le faire, puis diviser le code concerné et le faire, tout le code devant être audité par deux personnes différentes". Les situations de compétition sont très coûteuses à déboguer lorsqu'elles sont rares - l'audit aurait permis d'économiser de l'argent. C'est un domaine dans lequel nous devions tous améliorer notre méthodologie.
J'ai échoué à communiquer en omettant de demander si c'était un domaine dans lequel mes collaborateurs ne savaient pas comment faire et étaient trop timides pour le dire, et en cela ils étaient comme moi.
Ce que j'aurais dû faire, c'est demander à Viro plutôt qu'à Google, et l'inviter à venir à Moscou, à rester dans ma chambre d'amis, à goûter à la vie nocturne la plus sauvage du monde (Moscou), à donner à notre équipe un séminaire sur l'audit des situations de compétition et à nous superviser pendant que nous prenions chacun une partie du code et que nous faisions l'audit selon ses instructions. Il n'y avait qu'une mauvaise raison : je répondais à l'hostilité initiale au lieu de la dépasser pour me faire un allié de quelqu'un qui avait beaucoup de potentiel pour nous être très utile. Bien sûr, il aurait pu refuser l'invitation, dire qu'il était trop occupé, nous dire de mieux utiliser Google, etc. mais même s'il avait refusé l'invitation, il se serait probablement senti quelque peu apaisé. S'il avait accepté l'invitation, nous aurions tous pu nouer des amitiés précieuses, susceptibles de nous être utiles pour le reste de notre vie, en le nourrissant de shi [sic] (щи, soupe russe, l'un des meilleurs aspects de la cuisine russe étant leurs soupes) et de pelmenie (elmeni, bâtonnets géorgiens épicés), et en l'emmenant danser jusqu'au bout de la nuit lorsque les situations de compétition n'étaient plus réunies.
J'aurais pu approcher de la même manière d'autres personnes clés de la communauté du Kernel qui ont exprimé leur mécontentement face à notre offre de contribution, si seulement j'avais eu à l'époque la confiance sociale et la conviction qu'il est possible de surmonter les premiers signes d'aliénation, que j'ai développées aujourd'hui.
Au lieu de cela, j'ai répondu à l'hostilité par ma propre hostilité.
En prison, lors de la journée de MLK, j'ai appris les mots de MLK :
"
Only love can fight hate" (" Seul l'amour peut combattre la haine ").
J'ai fini par apprécier et comprendre pleinement ces mots, mais j'aurais aimé les comprendre à l'époque.
J'ai géré un certain nombre de situations qui n'ont pas permis aux gens de se sentir appréciés ou inclus, et je tiens à saisir cette occasion pour m'en excuser.
Je tiens tout particulièrement à m'excuser auprès des autres membres de notre équipe qui ont investi une grande partie de leur vie dans notre rêve et qui ont été déçus par moi et par le fait que j'ai aliéné d'autres membres de la communauté du noyau Linux.
Le noyau Linux n'est pas une question de critères, c'est une communauté de personnes qui aiment travailler ensemble dans l'esprit de Noël pour donner aux utilisateurs tout au long de l'année. Maintenant que j'ai changé d'identité, je peux mieux m'en rendre compte.
Je ne sais pas ce qu'il y a dans Reiser 5 - on ne me l'a pas dit et je ne peux pas aller sur Internet. Edward Shishkin est un homme très intelligent, et l'un de mes regrets est de ne pas avoir passé plus de temps avec lui. Je suis convaincu qu'il a fait quelque chose de bien dans Reiser 5. Qui sait, il a peut-être créé des plugins intéressants que je n'aurais jamais imaginés. Le plugin de compression qu'Edward a codé est la chose qui a apporté le plus grand gain de performance de toutes les choses que nous avons faites dans Reiser 4. Il y a de fortes chances que je ne sois pas libéré de sitôt. J'encourage les gens à permettre à ceux qui ont travaillé si dur pour construire un beau système de fichiers pour les utilisateurs d'échapper aux effets de ma réputation. Je vous invite à comprendre ce qu'ils ont vécu pendant une minute.
Laissez leurs rêves s'échapper du mal que j'ai fait, si cela vous semble juste.
Conclusion
J'aurais aimé apprendre les choses que j'ai apprises en prison sur le fait de parler des problèmes, de croire que je peux parler des problèmes et de le faire, avant de me marier ou de rejoindre le LKML. J'espère que le jour où l'on enseignera ces choses à l'école primaire viendra.
Je remercie Richard Stallman pour son inspiration, ses logiciels et ses grands sacrifices,
Ce fut un honneur d'être d'une valeur même passagère pour les utilisateurs de Linux. Je vous souhaite à tous bonne chance.
Hans
Hans Reiser s'exprime sur la dépréciation de ReiserFS dans le noyau Linux
Qu'en pensez-vous ?
Répondre avec citation
Envoyé par chrtophe
Partager