Le week-end dernier, je parcourais - dans un moment de nonchalance - une page web décrivant ce qu'est un vrai défenseur du logiciel libre. Parmi les "caractéristiques" de ce genre d'individu se trouve :
«Il a lu et relu La cathédrale et le bazar, d'Eric S. Raymond, de sorte qu'il sait précisément pourquoi il défend le logiciel libre.»
Eh bien moi je ne l'ai pas lu, mais comme j'ai un peu de temps, je me lance [1]. C'est une lecture très intéressante et instructive pour comprendre le succès de Linux et d'autres projets, basé sur les qualités de celui qui tient les rênes du développement : paresse (de sorte qu'il est prompt à accepter le code des autres), communication, etc.
Sur le même site se trouve un autre essai ayant pratiquement le même titre : La cathédrale, le bazar et le conseil municipal, d'Alan Cox [2]. Il décrit ce qui a failli miner le développement de Linux pour l'architecture 8086. Son idée principale est que la communauté qui se forme autour d'un projet comme celui-là est composée de quelques programmeurs talentueux et expérimentés, mais aussi d'une «masse» de programmeurs débutants qui produisent beaucoup plus d'opinions que de code et qui finalement ralentit considérablement le projet. Le vrai problème apparaît si le noyau de programmeurs chevronnés décide de s'enfermer pour ne plus être ralentis par la masse. À court terme le projet gagne en rapidité, mais à long terme il perd l'opportunité de recruter de nouveaux participants talentueux et motivés. Il perd aussi la possibilité de transformer une partie de la «masse» en bons programmeurs en expliquant avec tact quels sont les points qui comptent vraiment, dans une démarche d'éducation.
Pour en venir à Reiser4, il me semble qu'il a souffert d'un aspect du fonctionnement de la communauté tel qu'il est décrit par Alan Cox. Le système de fichiers, supposé ultra-performant comparé aux actuels ext3 et consorts [3], vit actuellement dans la branche -mm du noyau linux, alors que son créateur Hans Reiser aimerait le voir intégré dans la branche principale. Alors qu'il s'est trouvé rejeté assez brutalement l'année dernière [4], Hans Reiser et son entreprise, Namesys [5], ont poursuivi le développement, en s'attachant sans doute à corriger ce qu' Andrew Morton et les autres développeurs de Linux lui avaient reprochés [6].
Plus récemment, un groupe d'utilisateurs a tenté de résumer la situation concernant reiser4 [7], et LinuxFr s'en est même fait l'écho en première page [8]. En ce qui me concerne, je trouve que la page en question fait plus de mal que de bien, car elle n'aborde pas l'aspect technique, mais au contraire se concentre sur le côté politique du processus, dont on a déjà trop longtemps parlé, avec pour effet de dégoûter ceux qui auraient pu s'intéresser sérieusement à Reiser4 et commenter le code.
L'apparition de cette page a entraîné avec elle un nouveau fil sur la lkml, entamé par Hans Reiser [9]. Une fois de plus, au lieu de s'attarder sur le vrai problème (les choix techniques), le fil a dérivé vers une discussion sur la difficulté d'obtenir l'inclusion d'un patch dans la branche principale de Linux. En revanche, contrairement à ce qui a été dit auparavant sur monsieur Reiser, son ton m'a paru retenu et cordial [10]. Malheureusement, le fil s'est enfoui sous une montagne de réponses provenant de la «masse» de non-techniciens, ou plutôt de gens non expérimentés et qui n'ont jamais lu une seule ligne du code de Reiser4 (il s'agit bel et bien d'une masse : le site marc.theaimsgroup.com répertorie 470 messages concernant Reiser4 pour le seul mois de juillet !). Même notre cher Linus Torvalds est tombé un peu dans le piège de cette discussion, et s'est fortement opposé aux soit-disant "plugins" de Reiser4 [11].
Heureusement, les développeurs de Linux, comme ceux du projet Linux 8086 décrits par Alan Cox, ne succombent pas à l'étouffement par la «masse»:
- Andrew Morton, responsable de la branche expérimentale, a finalement donné un coup d'oeil au code[12] et entre dans la discussion. En voici ma traduction:
«Pendant ce temps, je me retrouve pauvre et vieux en train de chercher quelques quatre autres heures pour finir le compte-rendu de la chose [NdT : parlant du code de Reiser4].
«Le code d'écriture [NdT: "writeout"] est horrible, mais ceci vient largement du décalage entre ce que reiser4 veut faire et ce que VFS/MM s'attend à ce qu'il fasse. Si ça marche comme ça, on peut vivre avec, même si le VFS pourrait être rendu plus intelligent.
«Je dirais que le problème majeur de reiser4 est le manque des xattrs, acls et direct-io. Il est probable que cela limite de manière significative l'enthousiasme des distributeurs (de même que l'attribution de copyright, mais est-ce notre problème ?).
«Les plugins semblent avoir été grossièrement mal nommés. Ce sont juste les éléments d'une couche intermédiaire d'abstraction qui permet d'ajouter ultérieurement de nouvelles fonctions d'une manière propre et sûre.
«Puis-je suggérer que toutes les critiques techniques à venir sur reiser4 incluent la référence du fichier et de la ligne en question ? Ça devrait réduire le débit sur vger [NdT : la liste de diffusion].
«Thanks»
C'est magistral, d'un coup la discussion est recentrée. D'une main de maître, Andrew a attiré une poignée de vrais interlocuteurs. Christoph Hellwig [13] ajoute concernant les plugins :
«[NdT : Si les plugins ne méritent plus leur nom], c'est parce que les vrais plugins ont été retirés du code depuis longtemps. C'est juste que ni ceux qui critiquent ni les fans de reiser4 dans ce fil n'ont jamais lu le code, ou plus généralement ils ne se sont jamais fait d'idée par eux-mêmes.»
Andi Kleen [14] poursuit :
«J'ai jeté un coup d'oeil rapide, et je dois dire que la plupart de ce qui m'avait retourné quand j'ai regardé la première fois il y a longtemps a été corrigé.»
Finalement, la vraie discussion s'est tassé, sur sur un conclusion positive. Les messages étaient écrits sur un ton tout à fait cordial, et faisant un bilan des quelques aspects techniques à peaufiner. Des développeurs de Namesys, comme Vladimir V. Saveliev, ont participé, et n'ont fait que de confirmer les conclusions d'Andrew Morton.
Et pendant ce temps, la «masse» continuait à s'étriper, cette fois sur ZFS, ou encore sur la capacité d'un système de fichiers à compenser les problèmes matériels...
J'espère que comme moi vous serez ravis de voir que la communauté a finalement fonctionné et a abouti à une vraie conclusion, constructive et enthousiasmante. Après lecture de ces quelques extraits de la lkml, il semble tout à fait raisonnable que Reiser4 soit finalement inclus dans une des prochaines versions de Linux.
[1] http://www.linux-france.org/article/these/cathedrale-bazar/c(...)
[2] http://www.linux-france.org/article/these/conseil-municipal/(...)
[3] http://marc.theaimsgroup.com/?l=linux-kernel&m=115437951(...)
[4] Il y a sûrement d'autres fils pertinents dans la liste de discussion, et vous serez sans doute fatigués après les 10 premiers messages sur les centaines de messages postés, mais voici quand même un lien http://lkml.org/lkml/2005/6/21/326
[5] http://www.namesys.com/
[6] http://lkml.org/lkml/2005/6/21/450
[7] http://kernelnewbies.org/WhyReiser4IsNotIn
[8] http://linuxfr.org/2006/07/17/21105.html
[9] http://lkml.org/lkml/2006/7/21/109
[10] http://lkml.org/lkml/2006/7/24/3
[11] http://lkml.org/lkml/2006/7/28/180
[12] http://lkml.org/lkml/2006/8/1/70
[13] http://lkml.org/lkml/2006/8/1/157
[14] http://lkml.org/lkml/2006/8/1/334
Journal Et Reiser4 nous apprend comment fonctionne la communauté
2
août
2006
# Journal privé?
Posté par tiot (site web personnel) . Évalué à 10.
Peut être est-ce un journal privé parce que le système d'XP de linuxfr.org est un mauvais système (la je joue la masse trollesque).
Voilà un type de journal que j'aime vraiment lire: intéressant, vulgarisé et bien écrit.
À ce que j'ai compris du problème de Reiser4 c'est le problème du doigt et la lune... on n'a regardé que le doigt d'Hans Reiser qui essaye de pointer vers son système de fichier.
Et au lieu de regarder la lune: le système de fichier, le code, ce qu'il est capable de faire, ce qu'il faut changer, ce qu'il faut améliorer, on a plutôt préférer discuter sur le doigt.
Notre Reiser4 à nous serait-il Ubuntu?
[^] # Re: Journal privé?
Posté par Zakath (site web personnel) . Évalué à 5.
Sans rire, Hans Reiser a énormément à se reprocher dans la manière dont les choses ont tourné. S'il avait eu une autre attitude, plus respectueuse et un peu plus humble, nul doute que reiser4 serait depuis longtemps dans le noyau.
Mais d'après ce qui est dit, il semblerait qu'il se soit calmé, ce qui est plutôt une bonne nouvelle (enfin va falloir se trouver des nouveaux trolls...).
# Excellent journal
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
[^] # Re: Excellent journal
Posté par B16F4RV4RD1N . Évalué à 4.
Cela me rappelle la qualité des articles de linuxfocus.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Excellent journal
Posté par Jean-Philippe (site web personnel) . Évalué à 4.
C'est le genre de truc que le commun des mortels ne peut pas faire ;)
[^] # Re: Excellent journal
Posté par Ontologia (site web personnel) . Évalué à 0.
On les mets en quelles sections alors, humeur ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Excellent journal
Posté par Thomas Petazzoni (site web personnel) . Évalué à 3.
Il est vrai qu'une news avec plein de "je pense que", "je trouve que" aura certainement un peu plus de mal à passer qu'une news un peu moins personnelle. Sauf si c'est une humeur, évidemment.
Cependant, ça ne veut pas dire qu'il doit absolument y avoir un évènement particulier pour faire une news. Mais une analyse peut très bien être faite sans utiliser "je pense que", "je trouve que" à tout bout de champ. Ça n'a rien à voir.
Ceci dit, c'est juste mon point de vue personnel. Les autres relecteurs et modérateurs ne pensent peut-être pas mal même chose.
[^] # Re: Excellent journal
Posté par Ontologia (site web personnel) . Évalué à 4.
Hum, ça sert à quoi d'être aggressif, immédiatement ? Tu voudrais pas commencer par discuter, d'abord ?
Je ne suis pas agressif, je pose une question.
Excuse moi, mais je ne vois que des news factuelle sur linuxfr depuis 5 ans. Je ne suis pas dans la tête des modérateurs, et je n'ai que https://linuxfr.org/moderateurs/moderation.html pour me donner quelques indices et me permettre de supposer certaines choses quand aux limites du hors sujet.
Dans le doute, je ne propose donc quasiment jamais d'articles.
Il est vrai qu'une news avec plein de "je pense que", "je trouve que" aura certainement un peu plus de mal à passer qu'une news un peu moins personnelle. Sauf si c'est une humeur, évidemment.
Cependant, ça ne veut pas dire qu'il doit absolument y avoir un évènement particulier pour faire une news. Mais une analyse peut très bien être faite sans utiliser "je pense que", "je trouve que" à tout bout de champ. Ça n'a rien à voir.
Ceci dit, c'est juste mon point de vue personnel. Les autres relecteurs et modérateurs ne pensent peut-être pas mal même chose.
Je sais parfaitement écrire une analyse sans la parcemer de "je pense que", "je trouve que", j'en ai fait plusieurs ici même.
Je pose simplement la question "Un évènement doit-il être la source d'une news" et tu m'a répondu, je t'en remercie.
La bonne question à se poser maintenant, est : Une news plutôt analytique traitant de problématique plus générale (en informatique), entre liée à Linux et/ou au logiciel libre a t-elle une chance de passer.
J'ai tendance à écrire beaucoup de journaux d'une part parce je tiens à ce que cette partie du site soit bien fournie, mais aussi parce que je ne sais pas sur quel pied danser quand à l'écriture d'une news, dont je dois potententiellement attendre longtemps avant d'avoir une réponse quand à son acceptation ou non.
Je pense ne pas être le seul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Excellent journal
Posté par patrick_g (site web personnel) . Évalué à 4.
Ah bon ?
J'avais tenté le coup d'une news d'analyse y'a deux ans et c'était passé donc tu peux tenter le coup.
cf : http://linuxfr.org/2004/07/23/16876.html
[^] # Re: Excellent journal
Posté par Thomas Petazzoni (site web personnel) . Évalué à 5.
Quelques exemples qui me passent par la tête:
http://linuxfr.org/2005/05/03/18845.html
http://linuxfr.org/2005/02/08/18276.html
http://linuxfr.org/2005/08/10/19413.html
http://linuxfr.org/2005/08/10/19418.html
et il doit y en avoir tout plein d'autres. Alors oui, ce n'est pas l'essentiel des dépêches, mais il y en a quand même. Personnellement, je suis totalement pour ce genre de dépêches, qui parlent de tendances générales, qui mettent en perspective, qui proposent une analyse, etc.
La bonne question à se poser maintenant, est : Une news plutôt analytique traitant de problématique plus générale (en informatique), entre liée à Linux et/ou au logiciel libre a t-elle une chance de passer.
Honnêtement, c'est difficile de répondre de manière générale, parce que je ne suis pas dans la tête des autres modérateurs, et chaque modérateur a ses propres avis. Tant que la dépêche est liée à Linux ou au Logiciel Libre, qu'elle propose des références et que l'analyse ne semble pas complètement bidon et à l'emporte-pièce, ça a de bonnes chances de passer. En tout cas, tu auras mon vote.
# Merci
Posté par Marc Poiroud (site web personnel) . Évalué à 10.
Sincèrement.
# De la definition d'un expert
Posté par shal . Évalué à 10.
Qu'est ce qu'un expert?
Je me suis rendu compte que quand tu t'intéresse à un domaine, tu peux rapidement te faire passer pour un expert auprés de quelqu'un d'un peu moins callé que toi.
J'en ai fait l'expérience l'autre jour en sortant à un collégue une phrase construit avec des bouts de phrases entendu par-ci par la: Je suis passé pour un dieu du domaine alors que ma phrase (en plus d'être surement fausse) je l'a comprennais même pas!!
La c'est pareil sur reseir4: plein de gens suive les discussions, au bout d'un certain temps ils se croient autorisé à donner leur avis alors qu'il ont jamais lu une ligne du code. Moi aussi je peux dire :" Hans c'est un con, il essaye de forcer l'architecture du VFS en incluant un systéme de plugin qui va tout pourrir".
Je pense que l'on devrait tous être plus humble sur ce que l'on connait tant que l'on a pas réellement été au fond des choses.
Voila, fini mes reflexions....
[^] # Re: De la definition d'un expert
Posté par Fanf (site web personnel) . Évalué à 10.
Excellent ! Tu es prêt pour travailler en SSII !
[^] # Re: De la definition d'un expert
Posté par farib . Évalué à 10.
Ben quoi, c'est vrai. Je l'ai lu sur la LKML.
[^] # Re: De la definition d'un expert
Posté par jms . Évalué à 6.
Quand on sort de l'école, on croit tout savoir. Et puis au fur et à mesure, quand on écoute les autres, quand on fait des boulettes, quand on cherche à apprendre, et bien on se rend compte qu'on en sait beaucoup moins.
Je dirais même que plus on apprend, plus la vision des connaissances possibles s'élargit.
Et je crois que c'est ce qu'on appelle (comme tu l'as dis) l'humilité et l'expérience.
[^] # Re: De la definition d'un expert
Posté par Sylvain Sauvage . Évalué à 10.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: De la definition d'un expert
Posté par SF . Évalué à 5.
N'ayant pas fait d'études d'informatique j'ignore comment ça se passe mais dans d'autres domaines je sais très bien qu'il n'est pas rare de croiser des enseignants très compétents ayant des avis radicalement opposés sur un même sujet.
L'école te transmet une partie des aptitudes nécessaires dans ton travail mais ce n'est qu'une partie, le reste c'est à toi de l'acquérir et ça a autant d'importance que le savoir transmis.
Si tu es sorti apte au travail de ton école je t'en félicite, mais une partie non négligeable du mérite revient à toi seul, pas à ton diplome.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: De la definition d'un expert
Posté par kraman . Évalué à 6.
kof kof.
on sort pret a affronter a peu pres n'importe quelle situation technique.
de la a dire que le mec est apte (ie : capable de rendre un projet pour avant hier, comprendre le besoin du client, employer les pincettes qui vont bien, estimer un besoin d'evolutivite ou le potentiel commercial d'un produit, etre capable de flairer un client emmerdeur qui va faire diverger etc.) ya un pas que je ne franchirais franchemnet pas.
Un mec qui sort de l'ecole (fac ou ecole), je le laisserais pas a un poste tout seul, plutot avec un un mec de 5-10 ans mini pas loin pour le driver en cas de connerie ou d'exces de zele.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: De la definition d'un expert
Posté par kraman . Évalué à 3.
a partir du moment ou t'es capable de canaliser sa fougue de jeune chien fou et d'eviter les catastrophes "j'pensais que c'etait une bonne idee" :-P
Le diplome ca sert surtout a trouver son premier taff, passe les qq premieres annees ca veut plus dire grand chose je trouve.
Pour ce qui est du reste ce que tu cites n'est pas du ressort d'un informaticien
mouaif...
c'est clairement pas un boulot d'informaticien pur et dur, mais on peut rapidement etre amene a faire ce genre de choses en etant ingenieur...
[^] # Re: De la definition d'un expert
Posté par icyfemur . Évalué à 3.
Je le constate particulièrement sur ce qui touche l'Espéranto, ou les gens les moins bien informés sont bien souvent les plus fervents détracteurs.
# Hum...
Posté par clearstream . Évalué à 8.
J'ai lu le fil de discussion consernant reiser4 (du moins une bonne partie) et j'ai bien l'impression que ton enthousiasme pour reiser4 te brouille la vue. C'est-à-dire que tu sembles dire que les techniciens (les développeurs) avaient du caca dans les yeux car ils étaient influencés par la masse. Mais, et fort heureusement, ils se sont recentrés sur les aspects techniques. Maintenant ils voyaient claires et trouvent que reiser4 est formidable.
C'est incohérent :
* les développeurs n'étaient pas sous l'influence de la masse. La masse veut reiser4 en standard dans Linux, pas les techniciens (du moins en l'état actuel des choses).
* tu dis qu'il faut privilégier l'avis de techniciens sur l'avis de la masse mais tu te félicite que les techniciens soient maintenant de l'avis de la masse. C'est-à-dire que tu te félicite que les techniciens soient influencés par la masse alors que tu disais que la masse avait une influence négative.
* ...
Bref, j'ai du mal à te suivre. Si ton journal était de redorer le blason de reiser4, pourquoi pas. Mais l'objectif devrait être anoncé un peu plus clairement au-lieu de suivre des chemins aussi tordus.
Il ne me semble pas que les développeurs aient significativement changé d'avis sur reiser4. D'ailleurs Andrew en faisant un audit rapide de reiser4 a trouvé rapidement des manques significatifs et que l'aspet plugin de reiser4 frisait le vaporware.
Par contre, et c'est tant mieux, quelques développeurs veulent sortir de cette merde qu'est reiser4. C'est-à-dire qu'il n'est pas bon pour l'image de Linux ainsi que sa communauté de se trainer indéfiniment reiser4 dans la branche -mm, même si c'est pour de bonnes raisons, car la "masse" ne le comprend pas (d'où un nombre important d'article qui critique la gestion de Linux) et que ça emmerde les utilisateurs de reiser4.
Je n'ai pas d'affinité avec reiser4 dont la réputation me semble très surévaluée. Mais si ce nouveau sursaut permet à reiser4 d'être proprement intégré à Linux, alors tant mieux.
> En ce qui me concerne, je trouve que la page en question fait plus de mal que de bien
Plus de mal que de bien à qui ?
> car elle n'aborde pas l'aspect technique
S'il n'y avait que l'aspect technique, tu n'en serais pas plus heureux. Reiser4 a des manques, est fragile (manque de redondance pour privilégier la performant), son principal développeur est inconstant et peu soucieux de la pérénité de son FS (il n'y a que les choses nouvelles qui l'intéressent), son fsck est moyen, etc...
Si tu as lu le thread, tu connais les faiblesses de reiser4.
> mais au contraire se concentre sur le côté politique du processus
Ben c'est un point important !
Si Hans se la jouait moins (relis le début du thread pour voir le mépris qu'il peut avoir envers le boulot des autres, ce qui a bien énervé un développeur d'ext3), s'il était un peu plus à l'écoute des autres développeurs, d'autres développeurs aurait envis de bosser sur reiser4.
Ce n'est pas forcément une question politique mais au minimum de respect.
Puis notes bien que c'est surtout Hans qui sort les apects politiques pour expliquer que reiser4 n'est pas en standard dans Linux (la vieille théorie du complot).
[^] # Re: Hum...
Posté par Prae . Évalué à 4.
* tu dis qu'il faut privilégier l'avis de techniciens sur l'avis de la masse mais tu te félicite que les techniciens soient maintenant de l'avis de la masse. C'est-à-dire que tu te félicite que les techniciens soient influencés par la masse alors que tu disais que la masse avait une influence négative.
Je pense que tu as du te tromper dans la suite de logique de l'histoire.
Je suppose que les premières versions de ReiserFS était pas forcément top, donc rejet des techniciens en haut lieu (Andrew Morton, Linus, etc...)
Les autres techniciens (ceux qui suivent d'un peu plus loin le dev krnl) reprennent, en général, comme parole d'évangile ceux que disent leurs "chefs".
Au fûr-et-à mesure, Hans Reiser a améliorer le code pour le rendre parfaitement compatible avec une sorte de charte de codification kernel.
Le seul problème c'est que Linus, Andrew et les autres n'ont pas forcément du temps pour revoir le code, donc ils laissent ce travail - de façon inconsciente - aux autres techniciens.
Cependant, ces autres techniciens ont du resté figé sur la première appréciation des codeurs en haut lieu: ils n'était pas favorable à ReiserFS (à l'époque).
Donc évidemment, durant des threads et des threads de conversation, les techs ont rejeté les propositions de Hans Reiser et bien entendu la plupart des core-dev devaient lire les mails rapidos en se disant que les petiots faisaient bien leurs taffs (cas généralement fréquent: tu fais plus confiance au giron du dev qu'à un codeur d'une autre équipe)
Puis un jour, Andrew a du se dire "tiens! je vais quand même relire le code de ReiserFS parce que je trouve qu'il y a beaucoup de bruit sans forcément de preuve concrète"
Finalement, il a posté un mail pour dire que ReiserFS avait pas mal changé et qu'il valait quand même le coup d'oeil.
Bien entendu Linus et les autres ont du se dire "merde! si Andrew - mon ami, mon lapin en susucre du pointeur sur pointeur - en dit du bien ... ca vaut peut-etre le coup que j'arrète 10 minutes de coder et de revoir le code de ReiserFS"
Bon, y'a plein de supposition, mais je pense pas trop me tromper sur l'histoire, surtout lorsqu'Andrew précise qu'il veut maintenant des références et plus du blah-blah pour l'argumentation.
[^] # Re: Hum...
Posté par clearstream . Évalué à 6.
Je suis globalement d'accord avec l'ensemble de ton commentaire. Il y avait probablement une erreur d'appréciation de reiserfs et il était temps d'évaluer à nouveau reiserfs.
Mais je ne crois pas que la donne ait été bouleversée. Je ne pense pas qu'aujourd'hui Linus regrette d'avoir jusqu'à maintenant refusé l'introduction de reiserfs ou qu'Andrew va lui dire qu'il est con s'il refuse une fois encore ou que la branche -mm n'est pas la place de reiserfs.
La situation est moins pire ou meilleure que supposée.
Au delà des aspects techniques, il reste le point le plus dur. Hans et son équipe vont-ils sérieusement maintenir Reiser4 ?
Parce que les développeurs Linux n'ont pas forcément envie de se retrouver avec un FS de plus sur les bras, ou d'avoir plein de rapport de bug parce que la dernière évolution du VFS fait planter Reiser4 et que Hans ne veut pas se retrousser les manches, ou de se refuser de faire évoluer l'API FS de Linux car personne ne maintient reiser4 et que reiser4 est très utilisé.
Ce dernier point semble politique mais c'est un très très sérieu problème. D'autant plus sérieu problème que ReiserFS V3 n'a pas été une réussite au niveau du suivie. D'autant plus sérieu problème qu'il y a d'utilisateur. Malheureusement :-), si reiser4 est en standard dans le noyau, beaucoup vont l'utiliser et ça, ça fouille la trouille aux développeurs de Linux si reiser4 est mal maintenu.
Je ne dis pas ça pour casser Hans gratuitement. Mais il faut bien comprendre les implications d'intégrer reiser4 en standard dans Linux.
Linus, qui en a la responsabilité, pourrait dire afin que Hans ne li pourrisse plus la vie :
- "OK pour l'intégration de reiser4 mais si ça merde, ce n'est pas de mes oignons."
Ca ne serait pas très responsable compte-tenu de l'historique de Reiserfs V3. Linus a peut-être tord, mais on n'intégre pas en standard dans le noyau un système de fichier comme on intègre un driver pour le dernier gadget USB à la mode.
> Bon, y'a plein de supposition
Ca fait son charme.
[^] # Re: Hum...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Le système de plugin est sympa mais si elle rend les reiserfs4 imcompatible entre eux, cela va être un bordel sans nom. Il y aura reserfs4 vanilla, reserfs4+compression, reiserfs4+compressionv2, reiserfs4+compression+schedulerbdd, reiserfs4+compression+schedulerbigfile, etc...
Bref, un beau merdier. Imagines tu upgrades ton linux et ta partition devient illisible...
Le VFS permet d'avoir une interface standard entre le fs et le reste du noyau. Cela permet d'avoir du code commun et surtout de (correctement) gérer les concurences d'acces, ce qui peut être très complexe. reiserfs4 bouleverse ça et rajoute une autre interface qui peut effectivement foutre la merde...
Au vue des commentaires, notament sur le writeout code, on comprends que la solution serait d'étendre un peu VFS et de communalisé le code reiserfs4 avec les autres systèmes de fichiers (un module de compression devrait pouvoir bénéficier à tout le monde !).
L'autre problème de base conceptuel est dans le fait que tous les fichiers sont des directory pour gérer les metadonnés, ce qui pose un énorme problème pour la gestion des liens pour les applications (en gros imaginez un "find" qui part en boucle...).
Bref, les problèmes posés sont interrescants et mérite d'être corrigé. Mais c'est des gros problèmes conceptuels de design du noyau pas des questions politiques.
"La première sécurité est la liberté"
[^] # Re: Hum...
Posté par clearstream . Évalué à 2.
Je connais mal winFS. Mais si l'objectif est de faire d'un système de fichier un gestionnaire de base de donnée côté noyau, je préfère alors un gestionnaire de base de donnée côté utilisateur. Sinon ça demande un bordel énorme côté noyau.
Pour l'utilisateur final "bureautique" je trouve l'idée très bonne. Mais je ne crois pas que l'implémentation soit un jour fait à la winFS (c'est à dire dans le FS) dans le logiciel libre.
> Il y aura reserfs4 vanilla, reserfs4+compression, reiserfs4+compressionv2
De telle chose sont possibles avec ext3. D'ailleur il y a ext2, ext2+journalisation, ext2+journalisation+compression (le patch n'est plus maintenu), ext2+acl, ext2+journalisation+acl+selinux+dir_index+...
Compte-tenu de l'historique d'ext2, l'implémentation est peut-être moins générique que celle de reiser4.
> Bref, les problèmes posés sont interrescants
Résoudre le problème est peut-être interessant, flatteur intellectuellement, mais je ne suis pas convaincu que la solution apporte quelque chose intéressant au final.
Voir ce que je pense des "méta-données"...
[^] # Re: Hum...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il me semble que toutes les saveurs de ext3 que tu cites sont retrocompatible entre elle (sauf peut-être la compression). Mais c'est suite à l'évolution trop rapide de ext3 que ext4 a été lancé.
"La première sécurité est la liberté"
[^] # Re: Hum...
Posté par clearstream . Évalué à 2.
Oui.
Mais pour l'aspect rétrocompatible, il faut utiliser le système le plus à jour, virer la fonctionnalité (avec tune2fs) et forcer un e2fsck. On ne peut pas arriver avec un FS ext3 dernière mouture et le monter sur un vieux système. Ca ne marchera pas forcément.
> Mais c'est suite à l'évolution trop rapide de ext3
Peut-on évoluer trop vite ?
> que ext4 a été lancé.
Les développeurs n'exclus pas de conserver la compatibilité ascendant et descendant. Il est fort probable qu'au minimum ils fassent le forcing pour garantir une convertion en douceur de ext3 vers ext4 des partitions.
La principale motivation de la création d'ext4, était d'avoir une branche ext3-devel (qui évidemment sera nommée ext4-devel) où les développeurs pourront s'en donner à coeur joie et débrider leur imagination.
# Pour les nul ?
Posté par Mais qui suis-je ? :) . Évalué à 3.
mais cest quoi ( bon OK c'est un sytème de fichier ) ?
Je veux dire quelles sont les particularité de Reiser 4 par rapport à d'autre FS ?
Plus rapide plus fiable ? moin sensible à une casse du disque ??
plus économique en énérgie et moins usant pour les disques ??
Bref qu'est ce que ça change pour un pekin lambda d'avoir reiser 4 au lieu de ext 3
et plus généralement c'est quoi les différences entre un FS reiser et ext ??
Parce que changer de FS juste car ça fait Geek non merci ...
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
Ext3 est plus solide que reiserfs. Je ne dis pas que reiserfs explose toute les 10 secondes, mais si ça déconne t'as plus de chance d'être dans la merde avec reiserfs qu'avec ext3. Si rien ne déconne alors tant mieux pour toi et tu auras profité des meilleurs performances de reiserfs.
Aucun des deux n'est plus innovant que l'autre.
Voilà un papier sur ext3 (le passé, le présent et l'avenir) :
http://ext2.sourceforge.net/2005-ols/paper-html/index.html
Ici pour reiserfs (pas toujours très honnète) :
http://www.namesys.com/
[^] # Re: Pour les nul ?
Posté par benja . Évalué à 6.
- une meilleure utilisation de l'espace disque (il n'y a pas d'alignations sur les inodes)
- des répertoires cachés (mais accessibles)
- un système de plugins qui permettent de faire un peu n'importe quoi: compression, chiffrement, ...
- un journal voyageur (évite d'écrire le journal toujours au même endroit sur le disque -> moins d'usure et moins de seeks)
Le débat est aussi de savoir si ces features doivent être implémentées dans reiser4 ou si une architecture générique (tel que le vfs) ne serrait pas mieux pour que tous les fs en profitent.
[^] # Re: Pour les nul ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
J'ai entendu ça vite fait, j'ai très peu d'informations dessus. Certains disent que Reiser 4 est le WinFS du libre à cause de ce truc de méta-données.
Haypo
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
Ext3 le permet aussi et probablement beaucoup d'autres.
> Ceci permettrait (je n'ai pas bien compris comment) de pouvoir faire des recherches très fines sur les fichiers. Un peu comme Beagle le fait, mais au niveau du système de fichier
Sur le papier c'est mignon mais dans la pratique c'est quasiment sans intérêt.
Imaginons que dans les méta-données tu mets le nom de l'auteur du fichier (fichier txt, ou ogg, ...). Que doit faire apache s'il doit servir ces fichiers ? Il doit envoyer les méta-données avec le fichier ? Que doit faire le client web (firefox) ? Que ce passe-t-il si tu mets ces fichiers sur un serveur NFS ou SMB ? Et si le fichier est join à un mail ?
Avec méta-données tu fais :
- read(fichier)
- read_meta_data(fichier)
Sans méta-données tu peux faire :
- read(fichier)
- read(fichier.meta_data)
Sans méta-données tu peux faire :
- read(fichier) : et dans le fichier tu mets les "méta-données", comme openoffice stocke le nom de l'auteur et d'autres attributs dans les fichiers qu'il crée.
La seconde et troisième solutions marchent partout (apache, smb, nfs, client web, etc...).
La troisième solutions est la meilleure et de loins la plus utilisée.
La seconde est plus souple.
L'avantage de la première sur la seconde est une meilleur gestion des espaces de nom. Exemple : si "fichier" supprimé alors supprimer méta-données de "fichier" (le noyau peut faire ça systématiquement). Par contre avec la seconde solution, c'est aux programmes de le faire.
Il y a aussi les méta-données par fichier dédiés à un programme. Par exemple nautilus a ses méta-données par fichier/répertoire (définition de la taille de la fenêtre pour le répertoire "rep", sa couleur, etc).
Ben que ça soit dans ~/.nautilus ou dans de "vrais" méta-données ne change par grand chose. Et à y réflécher la première solution est sûrement la meilleure.
> plus rapide donc ?
Je ne vois pas pourquoi.
[^] # Re: Pour les nul ?
Posté par dinomasque . Évalué à 4.
BeOS le faisait il y a 20 ans !
[^] # Re: Pour les nul ?
Posté par lasher . Évalué à 5.
Imaginons que dans les méta-données tu mets le nom de l'auteur du fichier (fichier txt, ou ogg, ...). Que doit faire apache s'il doit servir ces fichiers ? Il doit envoyer les méta-données avec le fichier ? Que doit faire le client web (firefox) ? Que ce passe-t-il si tu mets ces fichiers sur un serveur NFS ou SMB ? Et si le fichier est join à un mail ? »
Dans le cas de NFS ou SMB, deux solutions : soit le système de méta-données est standardisé (façon "POSIX meta data" :-) ), et là, pas de pb ; soit il ne sert qu'en local, et il faut "stripper" toutes les méta-données lorsqu'on exporte des fichiers. Un peu comme le fait de considérer VFAT comme un système de fichier avec toutes les permissions à 1. Pour les mails, je pense que le problème est identique.
Eventuellement, comme on l'a suggéré avant moi, fournir les méta données dans un fichier à part (avec un mécanisme d'importation dans le système qui reçoit).
Pour moi, le « problème » des méta données n'en est pas réellement un : il s'agit plus du problème de leur standardisation.
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
La standardisation pour accéder aux méta-données est un petit problème.
Le problème est la standardisation du contenu des méta-données. Que les méta-données (auteur, charmap, mots clés, etc) soient dans le fichier ou "à côté" ne change rien.
Imaginons que le format des méta-données soit standardisés et considérons un exemple hypothétique avec find.
Avec les méta-données dans le fichier :
- find . -type f -exec meta_data_is "Auteur: Albert" {} \;
Avec les méta-données "à côté" :
- find . -type f -meta_data "Auteur: Albert"
Rien empêche de bidouiller find pour avoir la même syntax dans les deux cas.
Donc, je persiste et signe, je ne vois pas d'intérêt significatif à avoir les méta-données "à côté".
[^] # Re: Pour les nul ?
Posté par Thomas Douillard . Évalué à 2.
Ce genre d'info est pas standardisable, elles sont propres à l'utilisateur.
[^] # Re: Pour les nul ?
Posté par Ph Husson (site web personnel) . Évalué à 2.
Ext3 le permet aussi et probablement beaucoup d'autres.
Petite erreur sur la personne
C'est pas l'association à proprement parler
C'est à dire qu'il ne faut pas lire le fichier pour avoir les méta données
Mais le contraire est possible, c'est à dire de retrouver le fichier par les méta données, et c'est là tout l'interet
Alors bien sur il est possible de faire en userland, mais pour avoir tenté de coder un truc simple, et pour avoir testé kat et beagle
ben je suis pas pret de recommencer !
(Le probleme c'est de comment suivre l'activité des fichiers principalement (en fait en modifiant le noyau c'est faisable et ca existe déjà, voir rlocate (m'enfin c'est juste un locate normal avec surveillance continue(et qui est un peu tordu dans l'implémentation m'enfin bon(non j'ai jamais fait de lisp pourquoi?))))
Et venez pas me parler de inotify, parce que pour tout un FS (ou juste mon home qui est pas petit), c'est même pas la peine..
Donc bon quelque chose du genre du côté FS, je suis pour
Du côté du kernel c'est à voir, si on peut faire en userland on fait (un / en Fuse ca se tente non? :)
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
Comme ext3.
> Mais le contraire est possible, c'est à dire de retrouver le fichier par les méta données, et c'est là tout l'interet
Ok, c'est différent. Donc c'est en gros comme une base de données.
> Le probleme c'est de comment suivre l'activité des fichiers
Si le méta-donnée
> Et venez pas me parler de inotify
Et pourquoi ? Dnotify avait des limitations embêtantes (beaucoup de descripteurs de fichier ouverts). Mais inotify semble plus que correcte (testé avec un noyau 2.6.17) .
Tu peux jouer avec :
http://inotify-tools.sourceforge.net/
> Du côté du kernel c'est à voir, si on peut faire en userland on fait (un / en Fuse ca se tente non? :)
Je ne reviendrait pas sur ce que je pense de "toussa". Si je me trompe tant mieux.
Si je devais le faire, ça serait autour de :
- un gestionnaire de base de donnée (style db4). Une base de donnée par utilisateur.
- une librairie cliente pour que ça soit mieux intégré aux programmes qui le désire. Permet aussi aux programmes clients de dire "ignore les changements reporté par inotify, c'est moi qui les communiquerait.". Ca serait bien aussi pour être intégré à nautilus.
- des utilitaires en ligne de commande pour faire des requêtes, utiliser dans des scripts shell, faire des dump/restore etc...
- un serveur pour être à l'écoute des changements, intéroger, etc... Probablement utilisé via dbus. Ca ne serait pas un serveur sur l'ensemble du système mais seulement par utilisateur.
- un système de plugin pour le serveur afin d'avoir des "helpers" pour extraire les méta-données des fichiers. Par exemple oowriter a enregistré un fichier, inotify le signale au serveur, le serveur en utilisant l'helper extrait ces donnés puis les stock. Les helpers pourrait ainsi être fournis par les programmes.
- inotify. Seul le serveur utiliserait inotify. En fait plus probablement utilisation de gamin (qui utilise inotify). Permettrait de suivre les suppressions de fichier, les déplacements, etc...
- au lancement du serveur, un contrôle de la cohérence méta-donnée donnée serait fait (dans le cas où des fichiers sont supprimés, renommés, etc depuis le dernier état connu). Il est claire que stocker que numéros la pair dev/inode/mdate peut aider pour si retourner a rattraper les changements.
Une des grosses difficultées selon moi, est de standardiser les données qui seront stocké.
Il y a aussi le lourd problème de la configuration. Il faudrait pourvoir dire :
- pour ce répertoire, tu ne fais rien
- pour cet autre répertoire, je veux que tu "marques" chaque fichier comme étant de la catégorie "projet : dupond" et que tu me demandes d'enregistrer des mots clés sauf pour les fichiers openoffice où tu récupères les valeurs directement du fichier.
C'est horriblement compliqué.
Avec reiserfs, c'est un gain pour les déplacements/suppression de fichier et... c'est tout. Par contre si on est dépendant de reiserfs, et bien ca ne marche d'avec reiserfs. C'est très limitant.
Je ne prévois rien pour ceux qui se logguent sur une console texte. Sauf la disponibilité des outils (faire un dump, faire une modification à la main, etc).
Je signale que je ne me suis jamais réellement penché sur le problème et d'ailleurs je n'ai jamais utilisé kat ou beagle.
[^] # Re: Pour les nul ?
Posté par Ph Husson (site web personnel) . Évalué à 2.
Bah pourquoi pas
bon sinon j'ai du loupé le couche pour inotify:
struct inotify_event {
__s32 wd; /* watch descriptor */
__u32 mask; /* watch mask */
__u32 cookie; /* cookie to synchronize two events */
__u32 len; /* length (including nulls) of name */
char name[0]; /* stub for possible name */
};
(sur un noyau 2.6.17 (je precise parce que l'api a changé plein de fois))
Ou alors on peut lui dire de surveiller un répertoire et il le fera réccursivement ?
À l'époque de mes essais (j'avoue que ca remonte à longtemps), et de mémoire ca ne marchait tout simplement pas.
Enfin il fallait faire la récursivité soit même, donc bon on doit ouvrir un FD par fichier (ou juste par repertoire? (Le changement d'mtime(par exemple) d'un fichier étant répercuté sur l'inode et donc le répertoire je crois)
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
???
> Ou alors on peut lui dire de surveiller un répertoire et il le fera réccursivement ?
Non. Il faut scanner le répertoire et ajouter les sous-répertoires à surveiller.
> bon on doit ouvrir un FD par fichier (ou juste par repertoire?
Par répertoire.
Il y a une difficulté.
Inotify surveille le répertoire tmp/.
On crée le répertoire tmp/tmp/.
Inotify le voit.
On crée le fichier tmp/tmp/toto.
Inotify ne le voie pas. Normal, on ne lui a pas demander de surveiller tmp/tmp/
Donc il faut ajouter tmp/tmp/ a surveiller lorsque inotify détecte sa création. Il faut aussi vérifier s'il n'y a pas eu des fichiers ou répertoires de créé dans tmp/tmp/ entre la détection de la création de tmp/tmp/ et sa surveillance. S'il y a eu des répertoires de créés, il faut recommencer la procédure avec ces nouveaux répertoires.
Ce n'est pas la mer à boire à réaliser.
> d'un fichier étant répercuté sur l'inode et donc le répertoire je crois
Non. La modification d'un inode d'un fichier ne change pas le répertoire. C'est lorsque le répertoire change (ajout de fichier, renommage de fichier, suppression de fichier) que ça change.
Mais ce n'est pas un problème car inotify surveille les fichiers du répertoire à surveiller.
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
> Par répertoire.
Par fichier c'est aussi possible.
[^] # Re: Pour les nul ?
Posté par Ph Husson (site web personnel) . Évalué à 1.
mais s'il faut lire le contenu de tous les repertoires, puis dans tous ces repertoires ouvrir les sous repertoires et lire leur contenu etc, désolé mais ca risque de prendre quelques secondes (je dirais même minute vu le temps qu'un find -type d prend)
Et pour un service à lancer au démarrage ca m'est inadmissible (avec un init maison je boot en 10secondes maximum, si c'est pour multiplier ce temps par 10 je m'en passerais largement)
PS:Ah le find -type d vient de finir j'ai 84622 répertoires dans mon home, et un time find -type f apres (donc une partie devrait encore être en cache), prend la modeste somme de 8 minutes
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
J'ai déjà fait avec 40 000 répertoires et 300 000 fichiers. Ca marche et ça bouffe peu de mémoire.
> mais s'il faut lire le contenu de tous les repertoires
Pas le contenu. Le répertoire et faire un stat() sur les entrées du répertoire. En gros faire un "find . -type d".
Je t'ai peut-être mal compris.
> Et pour un service à lancer au démarrage ca m'est inadmissible
Ben ca dépend de ce que tu veux faire. Il ne peut pas être lancé après ton login ce service ?
Qu'es-ce qui dépend de inotify ?
Ce que doit lancer inotify peut-il est fait après coup ? Genre faire un : "find . -newer .notify-init -type f -exec bidule {} \;" (ce qui peut être fait en même temps que l'initialisation de inotify). Si c'est pour la base Beagle (que je ne connais pas, désolé) si elle n'est pas à jour durant 5 ou 10 minutes, ce n'est pas un drame.
> je m'en passerais largement
Tu n'en as peut-être pas tant besoin que ça.
[^] # Re: Pour les nul ?
Posté par Ph Husson (site web personnel) . Évalué à 2.
Hof niveau mémoire je m'inquiète pas
Mais niveau entrée/sorties sur le disque à l'initialisation !
Chez toi ca donne combien de temps ?
De mémoire même en faisant la récursivité avec une base de données qui fait que j'ai que le open() et le inotify_add à faire ca rame donc bon
Pas le contenu. Le répertoire et faire un stat() sur les entrées du répertoire. En gros faire un "find . -type d".
Je t'ai peut-être mal compris.
Quand je dis qu'il faut le lire, c'est lire pour savoir ses sous repertoires rien de plus
Ce que doit lancer inotify peut-il est fait après coup ? Genre faire un : "find .
-newer .notify-init -type f -exec bidule {} \;" (ce qui peut être fait en même temps que l'initialisation de inotify).
Oui oui bien sur, mais bon ca déplace le problème, si c'est pour avoir un système ralenti (bon à coup de ionice y a moyen que ca ne se sente pas mais bon pour le principe)
Tu n'en as peut-être pas tant besoin que ça.
Oui ca c'est sur m'enfin bon.
[^] # Re: Pour les nul ?
Posté par clearstream . Évalué à 2.
Environ 4 minutes.
[^] # Re: Pour les nul ?
Posté par Mark Havel . Évalué à 2.
# Problème de personnes?
Posté par mickabouille . Évalué à 0.
Non?
# Hmmmm
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
"une «masse» de programmeurs débutants qui produisent beaucoup plus d'opinions que de code"
[^] # Re: Hmmmm
Posté par kowalsky . Évalué à 5.
de produire quoi que se soit...
Ce n'est pas le cas des mailings-list cité plus haut.
[^] # Re: Hmmmm
Posté par Mr F . Évalué à 0.
de produire quoi que se soit...
A mais si, de l'information. Et de l'information noyé dans des commentaire inutiles, c'est plus long et désagréable à parcourir.
Pas que les commentaires ici soient nul ou stupides, simplement ils manquent pour beaucoup de pertinance. C'est le vrai gros problème de linuxfr.org, lire 50 commentaires pour apprendre quelque chose de 2 commentaires, c'est vraiment très pénible.
Du coup, moi aussi je rajoute ma couche d'impertinance dans ce thread, ça fera un post de plus à lire sans apprendre quoi que ce soit. :-)
# Guider la masse...
Posté par Axel R. (site web personnel) . Évalué à 6.
Je fais moi aussi de la masse, je participe rarement au développement de logiciels libres, pourtant j'aimerais beaucoup, mais je perds du temps à essayer de comprendre le code existant (parfois je perds du temps à comprendre le code... ou même simplement à faire tourner la version CVS/SVN sur ma machine) quand ce n'est pas le temps des autres que je perds...
Je suis dans une association et on a un peu le même probleme (sauf que je suis président et c'est plutot moi le noyau qui "connait tout"...) si des gens veulent nous aider, on perd bcp de temps à leur expliquer comment faire, mais si on ne leur explique pas, on est voué à rester dans le noyau toute notre vie...
Quels sont les solutions ?
Pour notre association, on pense faire des documents et/ou des week-end de travail/formation...
Pour ça, le projet KDE est plutot pas mal, la documentation développeur est bien fourni... peut etre pas completement à jour, mais bon...
Axel
[^] # Re: Guider la masse...
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Haypo
[^] # Re: Guider la masse...
Posté par Sylvain Sauvage . Évalué à 2.
Mais, bien trop souvent, il s'agit juste de règles de codage, de directives pour voir son code intégré (où, quand, comment, quoi poster) : il manque une vision de l'architecture, de l'organisation du système¹. L'excuse est souvent le temps, l'accèssibilité. Un wiki serait effectivement une bonne idée.
¹ Si on pouvait n'avoir quelques diagrammes UML (qu'on ne soit pas obligé de passer par cpp2dia et un audit poussé du code), ou les schémas des tables des BD.
J'ai du mal à comprendre qu'un groupe puisse travailler sur un projet sans avoir ce genre de documentation (même partiellement).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.