Articles : Pourquoi Reiser4 n'est toujours pas intégré à Linux
Posté par Jérôme Pinot (page perso, ). Modéré le 17 juillet 2006.
La question de l'intégration de Reiser4 au noyau officiel a donné lieu à de nombreuses discussions enflammées sur la LKML, qui finissent bien souvent par des attaques personnelles entre les différents protagonistes. En effet, Reiser4 est dans la branche -mm de Linux, c'est-à-dire la branche de test du noyau 2.6 maintenue par Andrew Morton, depuis bien trop longtemps maintenant.
Il n'est également pas rare de voir ici ou là des commentaires désabusés concernant la politique des mainteneurs Linux. ReiserFS 3 ayant été très populaire, de nombreux utilisateurs attendent impatiemment la mise à disposition de la nouvelle version dans le noyau officiel.
Alors pourquoi Reiser4 n'est-il toujours pas intégré au noyau 2.6 ?
Diego Calleja tente de répondre à cette question via une page d'informations sur le wiki de Kernel Newbies afin d'expliquer au mieux la situation. En voilà les grandes lignes.
Il n'est également pas rare de voir ici ou là des commentaires désabusés concernant la politique des mainteneurs Linux. ReiserFS 3 ayant été très populaire, de nombreux utilisateurs attendent impatiemment la mise à disposition de la nouvelle version dans le noyau officiel.
Alors pourquoi Reiser4 n'est-il toujours pas intégré au noyau 2.6 ?
Diego Calleja tente de répondre à cette question via une page d'informations sur le wiki de Kernel Newbies afin d'expliquer au mieux la situation. En voilà les grandes lignes.
Explications sur Kernel Newbies (2288 hits)
ReiserFS (1644 hits)
Hans Reiser sur la LKML (559 hits)
> Lire la dépêche (78 commentaires, moyenne: 3,8).
Vous avez demandé le commentaire #734991.




De la maintenance..
J'ai été très choqué quand j'ai appris qu'Hans comme un gamin a abandonné la maintenance de reiser3 quand ils sont passés à Reiser4 et qu'ils ont laissé ce boulot aux développeurs du kernel, qui ont dû avoir une mauvaise surprise sur le coup.
Je n'encourage personne à utiliser ni reiser3, ni reiser4, personnellement.
Je pense que ça doit jouer à l'intégration de reiser4 : les développeurs du kernel ne veulent sûrement pas se retrouver avec une merde de plus sous le bras si monsieur décide de réécrire encore une fois son système.
[^]Re: De la maintenance..
Personellement, ce que j'ai eu comme probleme avec reiserfs3, c'est la fiabilité.
J'ai eu une fois une corruption de fs avec reiserfs3 et j'ai eu alors la désagréable surprise de découvrir que la récupération de donnée par fsck ne fonctionnait pas pour reiserfs3..
--> partition perdue.
Depuis je pense que ext3fs, c'est bienTM: son fsck fonctionne bien lui, en cas de gros problème..
[^]Re: De la maintenance..
d'après ce que j'avais lu en retour sur les forums d'autre personne on eu le même problème que toi, ce qui m'a toujours refroidis pour l'utilisation de reiserfs3. Perso c'est toujours un "bon vieux" ext3 qui à le mérite d"avoir des outils de diagnostiques qui fonctionnent et dont la connaissance est partagé par mes collègues.... sa évite les pertes en cas de petits pépins, un fs ce doit d'apporter un minimum de fiabilté
[^]Re: De la maintenance..
> c'est toujours un "bon vieux" ext3
Il a évolué le "bon vieux" ext3.
Il y a maintenant index_dir (accès rapide aux fichiers quand il y en a beaucoup dans un répertoire), reservation (une optimisation : meilleurs tenue en charge et moins de fragmentation), resize_inode (retaillage à chaud des partitions, c-à-d sans umount), large_file (fichier de plus de 2 Toctets), attributs étendus, support selinux.
Une version de développement de ext4 va pointer le bout de son nez :
http://lwn.net/Articles/187336/
http://lwn.net/Articles/190169/
[^]Re: De la maintenance..
Le premier lien que tu donnes cite une remarque intéressante d'Andrew Morton :
Autrement dit, il constate que les systèmes de fichiers sous Linux commencent à être vieux et bancals et qu'il serait bon de tout réécrire depuis zéro, en se basant, pourquoi pas, sur l'architecture de Reiser4.
Cette remarque montre aussi la divergence d'opinion avec Linus qui est plutôt pour une approche lente progressive.
J'en profite pour rappeller, même si ce n'est qu'un détail, qu'il faut parler de ReiserFS pour la version 3, et de Reiser tout court, pour la version 4.
[^]Re: De la maintenance..
J'ai un portable qui est en Reiser3 et j'ai des problèmes avec Nautilus lorsque je navigue dans des répertoires avec beaucoup de fichiers. En général je finis par tuer Nautilus. Sur une autre machine en ext3 je n'ai pas ce soucis (Nautilus est certe lent sur le même genre de répertoire mais ça reste "raisonnable").
Ma question: est-il possible de convertir une partition reiser3 en ext3?
[^]Re: De la maintenance..
> est-il possible de convertir une partition reiser3 en ext3?
Non.
Mais avec un peu d'huile de coude, une sauvegarde faite avec tar ou cpio ou autre (bien lire la doc pour les options) et un CD de boot tu peux passer sous ext3.
Il faut aller avec du doigté pour grub ou lilo ainsi que le répertoire /boot.
Pour finir, il ne faut pas oublier de mettre à jour /etc/fstab.
ATTENTION : l'opération est aisée pour un "expert" mais peut conduire à un arrache de cheveux dans les rêgles pour un non-expert.
> j'ai des problèmes avec Nautilus lorsque je navigue dans des répertoires avec beaucoup de fichiers.
Quel version de Gnome/Nautilus ?
Nautilus a fait de gros progrès niveau performance avec les dernières versions.
[^]Re: De la maintenance..
Pour la migration j'ai déjà fait un changement complet de IDE vers SCSI sans rien réinstaller et sans trop de galère. Donc avec un peu de concentration et de courage je devrais peut-être y arriver...
Pour Gnome/Nautilus c'est 2.14 (Debian testing).
[^]Re: De la maintenance..
Avec mondorescue, il négocie bien les changements de disques/fs !
[^]Re: De la maintenance..
Depuis je pense que ext3fs, c'est bienTM: son fsck fonctionne bien lui, en cas de gros problème..
dis ca a mes 40 Go de perdu dut a une coupure de courant...
Ou en parlant des fs : dis ca a ma partition actuel (tjrs en ext3)qui se traine parce que j'ai eu le malheur d'utiliser ma partition de 40 Go (toujours elle \o/) avec que 40 mo de libre (c'était ponctuel , et je vais pas acheter un dd pour 3 heures d'utilisation)
Depuis ca rame.
(Ps j'ai jamais dis que reiser 4était mieux de ce point de vue vu que le meme test , sur une autre partition donne le meme probleme en plus prononcé !)
Je dis juste arreter de croire que ext3 saisbien et reiser4 sapux
Perso en ayant lut la lkml , hans était de mauvaise foie , mais j'ai trouvé que le responsable de l'inclusion des fs dans le kernel l'était aussi !
Mais bon c'est toujours plus facile de rejeter toutes les fautes sur une seule personne, et les autres sont forcément des saints ...
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: De la maintenance..
Je suis un peu d'accord avec cette remarque : la réputation des FS dans la communauté me semble pour le moins relever d'appréciations subjectives. Les experts manquant, ce ne sont que quelques expériences, peu étayées et documentées qui font et défont ces réputations.
A mon tour d'apporter ma brique subjective :
<mon experience>
Mon exemple favori est celui de XFS : ce FS est arrivé avec une réputation excellente, initialement écrit pas Silicom Graphics (SGI) pour Irix, utilisé sur des FS énormes, de la vidéo, etc. Il est difficile de trouver quelqu'un qui mette en doute sa fiabiité.
Il n'empêche, de tous les FS que j'ai testés (ext2, ext3, reiserfs3, xfs, jfs et reiser4), c'est celui qui m'a fait perdre le plus de données, avec 3 plantages non récupérables lors de transferts de gros fichiers (je suis persévérant, non).
A l'inverse, Reiser4, sur une utilisation de 6 mois, n'a planté que deux fois (c'est beaucoup pour un FS, mais il est en experimental et je l'utilise sur un portable avec de grosses bases de données, mais aussi plein de petits fichiers, ...) ET a pu se récupérer... Il donnait en plus une impression de rapidité étonnante. Je ne l'ai abandonné (temporairement ?) que parce qu'il n'est pas intégré aux noyaux packagés de ma distribution (qui par ailleurs intégrent d'autres éléments qui m'intéressent)
Quant à ext3, il a un petit défaut (qui sûrement se corrige par quelques paramètres dans fstab) : il fait un fsck régulièrement (tous les 20 démarrages par défaut sur ma distrib), ce qui est tout bonnement insuportable sur un portable (surtout que c'est toujours le jour ou il faut démarrer vite, devant une salle de réunion pleine de clients exigeants et peu patients, qui ont déjà du mal à admettre que je n'utilise pas Windows dans le monde du vrai travail sérieux :-(
</mon experience>
En bref, j'attends avec impatience l'inclusion de Reiser4 dans le noyau officiel.
[^]Re: De la maintenance..
> il fait un fsck régulièrement (tous les 20 démarrages
C'est paramétrable avec tune2fs (voir les options "-c" "-i" et "-e").
[^]Re: De la maintenance..
Il n'empêche, de tous les FS que j'ai testés (ext2, ext3, reiserfs3, xfs, jfs et reiser4), c'est celui qui m'a fait perdre le plus de données, avec 3 plantages non récupérables lors de transferts de gros fichiers (je suis persévérant, non).
J'en ai une tout autre avec le XFS, mais bien plus heureuse...
zero perte de donnée critique depuis 4ans, sauf deux fois (mais j'ai fait sciemment des conneries sur un matériel défaillant).
Il faut prévoir un mini-système avec xfs_repair pour le / :
1 => en cas de plantage, on reboot systématiquement sur celui-là
2 => on monte le / (si ça passe), déplacement de /lost+found en /lost+found-$(date -formatquivabien), démontage
3 => on lance un xfs_repair -n /dev/hda1 (le /) pour tester le niveau de fichier qui seront balancé dans /lost+fount
4 => on lance un xfs_repair /dev/hda1 (pour réparer le sf)
5 => montage du /, rmdir /lost+found, démontage
6 => on reboot
Je recommande l'étape 2 en semi automatique, du style :
mount -o ro /dev/hda1 /mnt/disk
[ -d /mnt/disk/lost+found ] && mount -o rw /mnt/disk && mv /mnt/disk/lost+found /mnt/disk/lost+found-$(date -formatquivabien)
umount /mnt/disk
#ceci est pour éviter de perdre les fichiers balancé dans /lost+found a la dernière vérification (la plus grosse faiblesse du XFS)
L'étape 4 peux être conditionnée par la valeur de retour de xfs_repair -n (qui renvoie un code de retour différent si il y a une erreur ou aucune)
L'étape 5 permet de s'éviter des cheveux blanc, si on a aucun fichier dont xfs_repair ne sait que faire on peux virer le répertoire vide (pas de vérification de contenu, prochaine exécution plus rapide)
En fait le soucis que j'ai rencontré est que il n'existe pas de fsck.xfs (en faire c'est un script/binaire a la con qui fait un return 0) et que xfs_repair refuse certaine fois de vérifier le / en lecture seule, donc j'ai opté pour la version seconde partition (qui permet de limiter les dégats et d'avoir un système de backup au cas où)
Mais c'est intégrable au système a condition de modifier les initscripts qui vont bien (chose que j'ai eu une sainte flemme de faire, mais qui sait, si j'ai le temps...)
Quand a la robustesse du XFS, j'ai vraiment rien trouvé de mieux (a part le JFS de IBM, mais il consomme/ait trop de cpu).
=> résistance au hard lock (carte nvidia qui faisait tout freeze un temps)
=> résistance a la coupure de courrant (reboot hard)
Ceci modulo d'appuyer sagement sur alt+print scr+s pour syncroniser les données sur disque après un changement important.
=> bonne tollérance au syndrome du système de fichier remplis (90% utilisé)
=> très bonne performance en tant que sf dans une partition cryptoloop (aes2048), le pross passe a 100% pour le temps d'écriture, mais en lecture 0% d'utilisation de processeur ou presque (lecture de vidéo/son sans lag ni rien)
Il a tout de même des petites faiblesses :
=> non support de selinux (sans augmenter la taille des inodes, mais ça fait perdre une place folle !!!)
=> fragmention gênante dès qu'on dépasse les 80% d'utilisation
Il faut alors libérer beaucoup de Go sur de grosses partition et défragmenter a coup de xfs_fsr -v /mnt/data (point de montage de la partition montée, mais ça peux se faire en user si le système de fichier appartient a votre uid)
Bref, le XFS c'est du bon, mais faut savoir ce qu'on fait :
=> redémarage rapide après gros problème
=> tollérer que des fichiers partent dans /lost+found en cas de coupure de courrant
(genre les pid et très petits fichier récemments écris)
=> faire des BACKUP !!! (on peux très bien perdre les deux magic block en cas de corruption physique du support)
N'est pas fait pour :
=> les personnes ne sachant par replacer les fichiers a coup de file fichier, vim fichier pour savoir qu'en faire
=> personnes peux consciencieuses qui appuie sur power avant même d'avoir fermé openoffice par exemple (si si ça existe, depuis le bouton power est systématiquement sous clef chez moi)
Bref, XFS c'est SGI, qui est mort ou presque, alors l'intégration de leur système de réparation dans un fsck.xfs j'y crois plus du tout, pour le futur va falloir aller voir plus loin (ZFS ?)
Sinon un petit plus du XFS c'est l'économie de place sur le disque, sur une même partition du XFS stocke plus de fichiers (toutes taille confondue) que de l'ext3
site perso : http://rapsys.free.fr/
[^]Re: De la maintenance..
> dis ca a mes 40 Go de perdu dut a une coupure de courant...
Peut-être un problème de hardware. Pour les coupures de courant, ça marche avec SCSI, ça merde avec certains disques SATA, et pour IDE il faut la capacité "cache flushes" sinon il faut désactiver le cache du disque.
Pour les coupures de courant, le hardware a un rôle important. Si la coupure n'est pas brutale, le hardware peut être dans des états transitoires (voire bizarres) et faire n'importe quoi (d'une certaine manière, il n'est plus sous le contrôle du système d'exploitation).
Ceci dit, je n'écarte pas un problème soft. Ca peut arriver.
> Je dis juste arreter de croire que ext3 saisbien et reiser4 sapux
Tu as raison, évitons le fanatisme. Mais notes qu'il s'est longtemps dit l'inverse :-)
[^]Re: De la maintenance..
c'est sûr que ça peut surprendre mais je croyais que l'un des bénéfices du libre tout ça c'était qu'on puisse justement subvenir au départ d'un ou du développeur et continuer le projet concerné, par exemple au minimum l'entretenir et fixer les bugs découverts au fur et à mesure ?
heureusement qu'il n'est pas passé sous un train pendant qu'il s'occupait de reiser3, hein.
faudra peut-être qu'il y ait un peu plus de développeurs noyaux vraiment interessés par ce filesystem, et pas juste lui. et si il n'y en pas assez, effectivement, reiser4 n'a pas sa place dans le noyau "officiel". et ça ne sera rien de personnel envers ce Hans
Windows has no users. It has hostages.
[^]Re: De la maintenance..
" c'est sûr que ça peut surprendre mais je croyais que l'un des bénéfices du libre tout ça c'était qu'on puisse justement subvenir au départ d'un ou du développeur et continuer le projet concerné, par exemple au minimum l'entretenir et fixer les bugs découverts au fur et à mesure ?"
Tu as tout à fait raison, mais des experts en FS, t'en as pas à tous les coins de rue, aussi, on aurait pu s'attendre de Hans qu'il maintienne ReiserFS 3 jusqu'à ce qu'il soit un minimum bug-free (ce qu'il était loin, loin d'être quand il a arrêté, et je ne sais pas si aujourd'hui ce FS est bien).
Ext3 était un bien meilleur choix et je suis sûr qu'attendre Ext4 sera encore un meilleur choix actuellement plutôt que d'être pressé et passer en Reiser4.
Le logiciel libre n'est pas un modèle magique où tout utilisateur devient programmeur.. et à ce propos, ce n'est pas un "bénéfice" du libre mais plutôt du "gros" proprio, la maintenance des logiciels après la mort ou l'arrêt d'un dev. Les logiciels produits par des grosses boites comme Microsoft ou Adobe, ben tu peux assassiner toute l'equipe des développeurs, l'entreprise elle mettra les sous qu'il faudra pour embaucher, voire en former d'autres programmeurs et voilà. Dans le logiciel libre faut plutôt compter sur de bonnes âmes.
Dans le proprio, ça ne pose problème que pour les petits (sharewares et freewares).
[^]Re: De la maintenance..
ce n'est pas un "bénéfice" du libre mais plutôt du "gros" proprio, la maintenance des logiciels après la mort ou l'arrêt d'un dev. Les logiciels produits par des grosses boites comme Microsoft ou Adobe, ben tu peux assassiner toute l'equipe des développeurs, l'entreprise elle mettra les sous qu'il faudra pour embaucher, voire en former d'autres programmeurs et voilà. Dans le logiciel libre faut plutôt compter sur de bonnes âmes.
pardon ? au contraire, tu fais quoi quand Microsoft refuse d'assurer le support, parce que le produit est déclaré obsolète par exemple, ou qu'ils ont vraiment envie de te pousser à mettre à jour tout ton parc d'Office 97 et 2000 qui marche pourtant très bien ? ou quand Adobe va jeter GoLive et Freehands parce qu'elle vient de racheter Macromedia et son Dreamweaver ?
dans le proprio, il faut compter sur la bonne volonté de l'éditeur, en plus de lui faire confiance pour qu'un dispositif de "sécurité" ne fasse pas tout planter pendant la nuit ou tes vacances quand tu es à 5000 km.
dans le libre et si tu n'es pas programmeur tu PEUX toujours payer quelqu'un pour le faire à ta place, si tu n'arrives à convaincre personne que ton idée est bonne au point que le projet l'adopte. la porte reste ouverte, dans le proprio on peut te dire non même si tu t'amènes avec un gros carnet de chèques à la main.
Windows has no users. It has hostages.
[^]Re: De la maintenance..
"pardon ? au contraire, tu fais quoi quand Microsoft refuse d'assurer le support, parce que le produit est déclaré obsolète par exemple, ou qu'ils ont vraiment envie de te pousser à mettre à jour tout ton parc d'Office 97 et 2000 qui marche pourtant très bien ? ou quand Adobe va jeter GoLive et Freehands parce qu'elle vient de racheter Macromedia et son Dreamweaver ?"
Soit réaliste, dans 10 ans tu crois qu'il y aura encore du support pour Openoffice 1 ? effectivement, il y a la solution comme tu dis après de raquer beaucoup (beaucoup) de sous pour qu'une équipe de programmeurs supportent ton programme.. le temps nous dira si le jeu en vaux plus la chandelle qu'une upgrade.
[^]Re: De la maintenance..
Je passe sur ton couplet du proprio.
> Dans le logiciel libre faut plutôt compter sur de bonnes âmes.
Pas forcément. Redhat (le développeur principal d'ext3)) a des clients qui payent. Si ext3 merde Redhat demandera à tel ou tel employé de fixer le problème et "fissa".
Le logiciel libre n'est pas équivalent à gratuit !
On ne le répètera jamais assez !
Le logiciel libre, c'est la liberté.
S'il y a un bug, t'es libre de le corriger et t'es aussi libre de payer qui tu veux pour le corriger.
Avec le logiciel propriétaire, t'es pas libre de corriger et tu ne peut payer que le boîte qui a le soft pour le corriger et aux conditions de cette dernière.
Enfin, au niveau FS, Linux propose une très large palette de FS (et c'est très bien). Ce n'est absolument pas le cas pour le logiciel proprio.
[^]Re: De la maintenance..
Juste une petite remarque : fixer un problème, en français, au mieux ça ne veut rien dire, au pire ça veut dire qu'on le rend définitif...
Je dirais plutôt corriger un problème.
(je sais, je pinaille, mais ce genre de barbarisme m'empêche de me concentrer sur le fond, avec lequel je suis d'accord par ailleurs !)
[^]Re: De la maintenance..
> je sais, je pinaille
C'est une juste mise au point.
> ce genre de barbarisme
Il faut les "combattre" et personne n'y est à l'abris :-)
[^]Re: De la maintenance..
S'il y a un bug, t'es libre de le corriger et t'es aussi libre de payer qui tu veux pour le corriger.
Oui, t'es libre de le faire, mais si on parlait un peu de pratique ?
Combien de societes sont capables de maintenir un OS entier ?
Parce que te fixer ton bug a toi c'est bien marrant, mais quand tu repasses 9 mois plus tard pour un autre bug, faut etre sur que le 1er bug est toujours corrige, que les autres correctifs inseres n'ont pas foutu le bordel, ...
Ca coute tres tres cher tout ca en infrastructure, machines de test, employes,..., et ca demande des gens ayant des competences, qu'on trouve pas n'importe ou.
Bref, si tu crois que tu peux debarquer chez la SSII du coin et leur demander de faire ca, tu te mets le doigt dans l'oeil hyper profond.
[^]Re: De la maintenance..
Evites de fumer la moquette avant de répondre à un commentaire.
Le file était libre vs proprio. Je n'ai pas dit que le libre virait toutes les contraintes.
Le complexité en logiciel est un problème difficile à gérer dans le libre et dans le proprio.
Personne a la prétention de résoudre tous les problèmes le weedend au fond de son jardin.
[^]Re: De la maintenance..
Peut-etre, mais avant de dire "avec le libre, tu es libre de XXX", faut aussi penser a voir si le XXX est faisable.
C'est comme dire "avec la GPL, tu es libre de teletransporter ton code dans une autre galaxie", c'est une super liberte, simplement elle vaut rien vu que c'est impossible a faire.
[^]Re: De la maintenance..
> faut aussi penser a voir si le XXX est faisable.
Le libre permet de faire beaucoup de chose. Ce que ne permet pas le libre, le proprio ne le permet pas.
Sauf que le proprio permet de s'en mettre plein les poches si les brevets et autres licences tordues sont permises.
Génial ?
Tu crois qu'une approche "propriétaire" de la recherche, où on cache les inovations et contrôle leurs utilisations, rendrait la recherche plus "puissante" ?
Si oui, on n'est pas du tout sur la même longueur d'onde et le mieux est d'arrêter cette discussion.
[^]Re: De la maintenance..
Le libre permet de faire beaucoup de chose. Ce que ne permet pas le libre, le proprio ne le permet pas.
Sauf que le proprio permet de s'en mettre plein les poches si les brevets et autres licences tordues sont permises.
Génial ?
C'est pas le probleme et c'est pas ce dont je parles.
Dire "Le libre permet XXX" alors que XXX est infaisable en pratique, c'est raconter des aneries.
Voila, c'est tout ce que je dis, et ce que tu racontes dans ce post n'a pas grand-chose a voir avec ca.
[^]Re: De la maintenance..
J'ai dit :
- "S'il y a un bug, t'es libre de le corriger et t'es aussi libre de payer qui tu veux pour le corriger."
C'est infaisable ?
D'ailleurs, où est la notion de faisabiliité ?
J'ai dit que le libre permettait de résoudre toutes les problèmes ?
J'aurais peut-être du dire "... de payer qui tu veux pour tenter de le corriger".
OK, désolé. Notes que c'est valable avec le propriétaire.
Pour le propriétaire il faut dire : "S'il y a un bug, tu n'es pas forcément libre de le corriger^W^W tenter de le corriger et t'es pas libre de payer qui tu veux pour tenter de le corriger".
Le support, qu'il soit pour du logiciel libre ou propriétaire n'offre qu'une garantie de moyen.
Dans le logiciel libre, les moyens sont :
- les bonnes volontées
- l'argent
Dans le logiciel proprio c'est principalement et presque uniquement :
- l'argent
Le libre a autant de moyens que le propriétaire : c'est-à-dire ce que les utilisateurs sont prêts à mettre "sur la table" pour corriger un problème ou ajouter une fonctionnalité.
Certes actuellement le marché du logiciel est dominé par le propriétaire. Mais rapporté au nombre d'utilisateur le libre a indiscutablement autant les moyens que le propriétaire. Donc à nombre équivalent d'utilisateur... Je ne te fais pas un dessin.
L'"avantage" du propriétaire est qu'il a des méthodes de "rackettes" (faut-il que je te les rappelle ?) et/ou monopolistiques que n'a pas le libre. Peut-être trouves-tu ce "rackette" légitime. Pourquoi pas. Pour moi il est problèmatique. Probablement une question de "sensibilité".
Mais je ne vois absolument pas pourquoi, a nombre d'utilisateur équivalent, les logiciels propriétaires offriraient plus de garantits que le logiciel libre.
Le libre a des moyens plus que respectable face au propriétaire (si tu ne vis pas dans une grotte au fond d'une montagne, tu te dois de le reconnaitre). Sois moins condescendant envers le libre. Le libre n'empêche pas d'avoir des grosses boîtes qui payent plein de développeurs. On en est plus à Linux 1.0 avec le leader commercial du libre qui a moins de 40 employés.
Ca te fout pas les boules j'espère ?
[^]Re: De la maintenance..
Le support, qu'il soit pour du logiciel libre ou propriétaire n'offre qu'une garantie de moyen.
Dans le logiciel libre, les moyens sont :
- les bonnes volontées
- l'argent
Dans le logiciel proprio c'est principalement et presque uniquement :
- l'argent
Le libre a autant de moyens que le propriétaire : c'est-à-dire ce que les utilisateurs sont prêts à mettre "sur la table" pour corriger un problème ou ajouter une fonctionnalité.
Encore une fois, tu parles en theorie.
Moi je te parles en pratique.
Tu me donnes le nom d'une SSII qui fait du support pour disons une Redhat 5.2 ? Va pas me dire que je prend un truc trop vieux hein, MS supporte encore NT4.
C'est pas pour denigrer le libre que je dis ca, parce que le proprietaire c'est la meme chose, mais faut rester lucide, demander a une SSII de maintenir un soft un peu complexe(Firefox, OpenOffice, Kernel+trucs de base,...) c'est pas tres possible en pratique du fait des investissements humains et financiers requis par rapport au nombre de gens qui le demandent.
Bref, arretes de tout voir comme une attaque contre le libre, je ne fais que mettre un peu de realisme dans tes affirmations, c'est tout.
[^]Re: De la maintenance..
> Tu me donnes le nom d'une SSII qui fait du support pour disons une Redhat 5.2 ?
J'ai dit : "tu peux !".
Je n'ai pas dit : "tu dois !".
> Va pas me dire que je prend un truc trop vieux hein, MS supporte encore NT4.
Ben maintenant redhat fait du support sur 7 ans. Il y a de la demande et l'offre est satisfesante pour les utilisateurs. En plus maintenant il y a des partenariats entre les distributeurs et les fournisseurs de hardware et logiciel pour fournir du support etc...
Vas savoir si la RHEL 12 n'aura pas un support de 15 ans.
Quoiqu'il en soit si redhat ne veux pas prolonger le support et qu'il y a de la demande alors il y aura une offre qui va apparaitre. Si MS ne veut pas prolonger le support de NT4 pour, par exemple, pousser les utilisateurs a prendre des licences windows 2008 et se faire plus de pognon (ce qui en soit n'est pas choquant vu que c'est une boîte commerciale), alors il n'y a rien. C'est ça la différence entre libre et proprio. Je n'ai pas dit que "le support libre roxor et support proprio puxor".
Regardes la redhat 7.3 qui n'est plus supportée par redhat depuis bien longtemps. Ben elle est supportée par fedora legacy. Certe, ce n'est pas la panacée. Mais c'est en rapport avec la base utilisateur. Et les utilisateurs doivent être bien content que le libre offre cette possibilité. Possibilité que n'offre pas le proprio. Tu peux dire que compte tenu de la base installée c'est négligeable. OK et en un sens je te suis. Les boites de proprio, si elles sont trop tiraniques, se tirent une balle dans le pied. Mais ce n'est pas négligable pour l'utilisateur concerné.
Peut-être qu'un projet "windows legacy" pour supporter windows 98 a sa place (la base utilisateur est encore assez large). Mais MS l'interdit. Redhat ne peut interdir une offre de support pour les produits qu'il ne supporte pas et aussi pour les produits qu'il supporte. Voir par exemple :
http://www.centos.org/
Les moyens de centos sont sans commune mesure avec redhat. Mais si redhat déconne, alors les moyens (c'est-à-dire les utilisateurs) iront vers centos (ou un autre). C'est une garantit (ou une voie de secours) que n'offre pas le proprio.
Tu continues toujours à nier cette différence évidente entre le libre et le proprio ?
> Tu me donnes le nom d'une SSII qui fait du support pour disons une Redhat 5.2 ?
Tu me donnes le nom d'une SSII qui fait du support pour disons windows 98 ?
> C'est pas pour denigrer le libre que je dis ca, parce que le proprietaire c'est la meme chose, mais faut rester lucide, demander a une SSII de maintenir un soft etc, etc...
C'est pas pour denigrer le propriétaire que je dis ca, parce que le libre c'est la meme chose, mais faut rester lucide, demander a une SSII de maintenir un soft etc, etc...
> je ne fais que mettre un peu de realisme dans tes affirmations, c'est tout.
Sauf que j'ai jamais affirmé : "support libre roxor et support proprio puxor".
[^]Re: De la maintenance..
J'ai dit : "tu peux !".
Je n'ai pas dit : "tu dois !".
Justement, moi je dis "meme si en theorie tu peux, en pratique tu peux pas".
Regardes la redhat 7.3 qui n'est plus supportée par redhat depuis bien longtemps. Ben elle est supportée par fedora legacy.
Genial, qui a cree Fedora Legacy ? Ah oui tiens, Redhat
Les moyens de centos sont sans commune mesure avec redhat. Mais si redhat déconne, alors les moyens (c'est-à-dire les utilisateurs) iront vers centos (ou un autre). C'est une garantit (ou une voie de secours) que n'offre pas le proprio.
Pourtant il y a plein de societes qui auraient voulu rester sur les anciennes versions de Redhat et qui n'ont pas pu car personne n'etait la pour assurer le support.
Tu continues toujours à nier cette différence évidente entre le libre et le proprio ?
Le jour ou te me montrera que c'est possible pour le libre d'avoir une autre partie qui fasse le support pour un soft non-trivial, je serai d'accord, d'ici la je continuerai a dire que tu racontes n'importe quoi quand tu dis que c'est un avantage du libre vu qu'en pratique c'est infaisable.
me donnes le nom d'une SSII qui fait du support pour disons windows 98 ?
La n'est pas la question, j'ai jamais dit que c'etait possible pour le proprio,encore une fois, je sais pas pourquoi tu t'amuses a faire une comparaison, je sais tres bien que c'est pas possible pour le proprio.
Le truc c'est que toi tu t'amuses a dire "avec le libre on peut", alors qu'en pratique c'est infaisable.
[^]Re: De la maintenance..
Dans le cadre de la maintenance de Reiser4, les développeurs du Kernel le disent eux même qu'ils ne veulent pas avoir un FS sous les bras si Hans arrête de s'en occuper comme le petit gamin qu'il est.
http://lkml.org/lkml/2005/9/18/131
From : Alan Cox
[...]
It doesn't matter if reiser4 causes crashes. It matters that people can
fix them, that they are actively fixed and the code is maintainable. It
will have bugs, all complex code has bugs. Hans team have demonstrated
the ability to fix some of those bugs fast, but we also all remember
what happened with reiser3 later on despite early fast fixing.
One big reason we jump up and down so much about the coding style is
that its the one thing that ensures someone else can maintain and fix
code that the author has abandoned, doesn't have time to fix or that
needs access to specific hardware the authors may not have.[...]
C'est saoulant ces supporters du libre qui croient mieux dire que les mainteneurs du kernel eux même. Le libre n'est pas une potion magique et je soutiens PBPG dans son dur combat qui consiste à réveiller les esprits endormis qui trônent sur ce site.
[^]Re: De la maintenance..
TU parles de pas tout à fait la même chose. Evidemment que personne ne veut supporter un code mal foutu ou autre.
Ici Alan dit pourquoi reiserfs n'est pas intégré au noyau. C'est, entre autre, car reiserfs en mal maintenu.
Pour la maintenance (c'est-à-dire avoir des développeurs qui "s'y collent") on est une une problèmatique de demande.
Quelle distribution aujourd'hui met reiserfs par défaut ? A ma connaissance pas les distributions majeurs.
Quand SuSE proposais reiserfs, il y avait un développeur pour maintenir reiserfs (Jeff Mahoney je crois, qui a contribué significativement à reiserfs).
Mais SuSE ne propose plus reisers (du moins c'est ext3 par défaut). Donc la base d'utilisateur de reiserfs c'est restrainte. Et notament des utilisateurs qui payent (ce qui permet de payer des développeurs).
S'il y avait une demande (évidemment significative) alors reiserfs serait maintenu. Mais reiserfs c'est fait dépassé petit à petit par ext3.
Pour avoir fait quelques tests comparatifs entre ext3 et reiserfs, reiserfs est significatifement plus rapide en lecture que ext3, un poil plus rapide en écriture, et est dépassé par ext3 lorsque le système est stressé (en lecture et écriture). Bref ext3 a une meilleur tenue en charge (mais les écarts ne sont pas immenses). Ajoutons qu'ext3 a des utilitaires qui roxent des ours (e2fsck, debugfs, e2image), qu'il supporte "tout" alors que pour reiserfs il faut des patchs pour avoir un support de NFS et des quotas, et reiserfs a "trainé" pour supporté selinux.
Puis reiserfs (et dans une moindre mesure jfs et xfs) est dépassé par ext3 au niveau fiabilité (suivre le thread pour quelques explications ) :
http://www.redhat.com/archives/fedora-test-list/2004-July/ms(...)
The ext3 have almost a perfect record with the write cache off: I have
run over 300 cycles on the two drives and only had two corrupted lines
in the output files. So out of 600 total cycles on the two drives there
were only two lines with bad data, I think that is a pretty good record.
None of the other journaling file systems have come anywhere near this
performance. After 3 or 4 power cycles, ReiserFS became corrupted to
the point that the system would not boot up (the fsck failed and the
bootup stopped there).
On assiste avec reiserfs à une sélection "naturelle" comme on l'a déjà vu maintes fois dans le logiciel libre.
Enfin, Alan bosse pour redhat (je ne nie en aucun cas sa liberté d'expression, j'essaie d'évaluer le contexte). Redhat n'a jamais supporté reiserfs. Pour rhel, reiserfs est fournis dans le paquet kernel-unsupported. Pour fedora, c'est fourni mais non supporté :
http://www.fedorafaq.org/#reiserjfs
Donc redhat dans le cadre de support contracté avec ses clients et des plannifications d'évolution de son système d'exploitation pour répondre aux attentes de ses clients n'a fort probablement jamais demandé à Alan (et d'autres employés) de maintenir ou corriger un bug de reiserfs. C'est tout le contraire pour ext3 qui est le seul FS supporté par redhat (avec GFS). En terme de moyen (pognon pour payer des développeurs) ça fait une différence énorme.
Si Alan maintenait reiserfs, ça serait hors redhat et là il dit en gros qu'il n'a pas le "gout" à ça (comme l'explique ton lien).
Faut dire qu'Alan n'a jamais été tendre avec reiserfs. Lorsqu'on demandait pourquoi reiserfs n'était pas supporté il répondait une truc du style :
- "la question de se pose pas, reiserfs ne passe pas les tests de redhat."
> C'est saoulant ces supporters du libre qui croient mieux dire que les mainteneurs du kernel eux même.
Si google (ou un autre gros client de redhat ou novell) qui tourne sous rhel (c'est au minimum 5000 machines) utilisait reiserfs ou exigait reiserfs, je peux te garantir que redhat supporterait reiserfs (et donc payerait des développeurs pour ce taff même si ça ne les emballent pas car le code est mal foutu). Il n'y a pas ou peu de demande, donc il n'y a pas ou peu de moyens mis en place.
> je soutiens PBPG dans son dur combat qui consiste à réveiller les esprits
A réveiller ou endormir ?
Si t'écoutes PBPG, le logiciel libre serait mort depuis 10 ans car ce n'est qu'un effet de mode, il ne serait même pas de le radar de microsoft, aucun grand compte n'utiliserait Linux car c'est un OS de kékés et le support est pourri, s'il avait un peu de popularité il serait infesté de virus comme windows, etc...
Que voit-on ?
Linux est là et bien là. C'est le seul OS a augmenter ses parts de marché et bientôt il va bouffer des parts de marché de Windows significativement.
Le discours de PBPG c'est :
- "Le logiciel libre ce n'est pas aussi bien que vous croyez bande de gros naïfs, il n'y a que les grosses boîtes qui peuvent innovées à coup de brevets et faire une bon OS".
Evidemment, je caricature.
Je te souhaite une bonne nuit à l'écoute de sa douce mélopée.
[^]Re: De la maintenance..
>> J'ai dit : "tu peux !".
>> Je n'ai pas dit : "tu dois !".
> Justement, moi je dis "meme si en theorie tu peux, en pratique tu peux pas".
moi je dis tu peux. après c'est peut être pas le meilleur choix, mais seuls des débiles profonds auront pris ça au pied de la lettre comme étant la chose à faire sans aucune reflexion.
c'est un peu comme clamer "Le libre n'est pas une potion magique". ben, euh, c'est connu. ça passe peut etre mieux sous la forme "le libre n'est pas une panacée".
>> Regardes la redhat 7.3 qui n'est plus supportée par redhat
>> depuis bien longtemps. Ben elle est supportée par fedora legacy.
> Genial, qui a cree Fedora Legacy ? Ah oui tiens, Redhat
et ? tu t'attendais à ce que ça soit Saddam Hussein ? le petit chaperon rouge ? et surtout quel rapport avec la question ? d'autres boites en font le support, et surement plus crédibles que Fedora Legacy.
> il y a plein de societes qui auraient voulu rester sur les anciennes versions de Redhat et qui n'ont pas pu car personne n'etait la pour assurer le support.
foutaises. peut-être qu'elles ont plutot fait la gueule quand elles ont lu le devis, non ? "COMBIEN ?" ah c'est sur que ca a dû leur faire un choc après avoir payé pas cher ou rien du tout pour quelques boites quelques années avant.
elles ont eu un choix économique à faire, elles l'ont fait. apparement le monde a continué de tourner.
ah, accessoirement il faudra voir ce que veut dire le terme de "support". et ces systemes sont suffisamment modulaires pour qu'on puisse se préoccuper de certaines parties vitales qui servent à quelque chose et pas du reste.
> > Tu continues toujours à nier cette différence évidente entre le libre et le proprio ?
> Le jour ou te me montrera que c'est possible pour le libre d'avoir une autre partie qui fasse le support pour un soft non-trivial, je serai d'accord, d'ici la je continuerai a dire que tu racontes n'importe quoi quand tu dis que c'est un avantage du libre vu qu'en pratique c'est infaisable.
les grosses SSII qui fournissent des prestations et du support pour les Unix depuis 20 ans et plus n'ont pas attendu Linux pour supporter des outils classiques d'Unix dont certains libres, et se sont retrouvées ravies de recycler plus tard leurs compétences en Unix et outils Unix sur les unix libres (linux & bsd) quand les autres ont commencé à disparaitre. bon, peut-être que tu vas me dire que Bull ou IBM c'est des mauvais exemples et que ca ne concerne pas le particulier ou la petite PME ?
après, évidement, les compétences rares vont être chères. c'est peut-être surtout ça qui est intéressant. les softs libres mais peu connus ou peu diffusés seront alors un choix risqué, les softs libres développés en autiste (par exemple OpenOffice avec quasi que des contributeurs de Sun) ça sera pas mal non plus.
bref ton "en pratique tu peux pas" c'est surtout "en pratique ca sera trop cher" et ça sera vrai pour tout ce qui n'est pas devenu très répandu et très commun. ça n'empeche.
Windows has no users. It has hostages.
[^]Re: De la maintenance..
> Justement, moi je dis "meme si en theorie tu peux, en pratique tu peux pas".
Car avec le proprio tout ce qui est théoriquement possible l'est aussi pratiquement ?
Arrêtes d'enfoncer des portes ouvertes.
> Genial, qui a cree Fedora Legacy ? Ah oui tiens, Redhat
Je crois que tu joues les crétins.
Un peu d'historique :
* Redhat lance le project fedora (au début c'était le redhat linux project dont l'url était : http://rhl.redhat.com/ )
* fedora est découpé en :
- fedora core : c'est principalement au début les employés de redhat qui s'y colle. En gros ceux qui bossaient sur rh9 bossent sur fc1.
- fedora extra : c'est principalement fedora.us
- fedora legacy : c'est encore principalement fedora.us : http://www.fedora.us/wiki/FedoraLegacy (malheureusement la page est morte).
Avant Fedora, on trouvait en autre :
http://linux.duke.edu/projects/univ-linux/
http://www.fedora.us/wiki/FedoraLegacy
et aussi pas mal de boîtes commerciales dont j'ai la flemme de chercher l'url. Mais citons progeny qui avait proposé du support dès le lendemain de l'abandon du support par Redhat :
http://lwn.net/Articles/61178/
http://www.progeny.com/services/transitionService.htm
support arrêté le 31/12/05 mais ça fait toujours 2 ans de support en plus. Puis il y reste encore fedora legacy.
Il est claire que Fedora Legacy, mais aussi redhat qui propose deux branches de son OS (un a sortie fréquente (fedora) et un a sortie lente (rhle)) ont changé la donne.
Redhat a aidé à la mise en place de Fedora Legacy. Redhat aide encore fedora legacy pour le hardware, la bande passante, l'utilisation du bugzilla de redhat, etc. Ce qui est normal puisqu'à l'origine du project fedora (je ne parle pas de fedora.us) redhat avant annoncé fedora legacy. Mais redhat n'aide pas pour le support.
Néanmoins des employés de redhat, sur leur temps personnel (c'est-à-dire sans être payé par redhat) aident le projet fedora legacy.
Redhat n'aide pas pour le support car sinon il se tire une balle dans le pied. Il faut pour redhat une distinction claire entre fedora et rhel. Cette distinction passe principalement par le support.
> Pourtant il y a plein de societes qui auraient voulu rester sur les anciennes versions de Redhat et qui n'ont pas pu car personne n'etait la pour assurer le support.
Pourtant il y a plein de societes qui auraient voulu rester sur les anciennes versions de Windows et qui n'ont pas pu car personne n'etait la pour assurer le support.
Redhat 7.3 : dernière mise à jours le 6 juin 2006 :
http://www.fedoralegacy.org/updates/RH7.3/2006-06-06-FLSA-20(...)
> Le jour ou te me montrera que c'est possible pour le libre d'avoir une autre partie qui fasse le support pour un soft non-trivial,
Car chez MS celui qui fait le support de, par exemple, IE est le développement d'IE ? Il n'y a pas de mouvement de personnel chez MS ?
Je ne savais pas.
redhat, toute petite société à côté de MS, fait le support complet de rhel. Les rares packets qui ne sont pas supporté sont marqués avec "unsupported" et il n'y en a qu'un. C'est un paquet avec des modules noyaux. Sinon tout est supporté : mysql, apache, php, X11, gnome, KDE, postgresql, sendmail, bind, etc.
Ben je vais t'apprendre un truc, mais redhat n'a pas développé 10 % de ce qu'il livre !
Pourtant leur support marche et n'a pas l'air d'être moins bon que celui de MS :
http://www.redhat.com/promo/vendor/
> je serai d'accord, d'ici la je continuerai a dire que tu racontes n'importe quoi quand tu dis que c'est un avantage du libre vu qu'en pratique c'est infaisable.
Ben en pratique c'est faisable et fin.
En pratique le logiciel libre est mieux supporté que le logiciel proprio. Si l'envis te prend de mettre ça en doute, rapporte le au nombre d'utilisateur ou au pognon et l'affaire est classée.
Donc, et je ne voulais pas avancer cette conclusion, en pratique le support du libre est meilleur que le proprio.
Regardes qu'il faut plusieurs années à MS pour corriger des bugs dans IE et MS-office. Et il y en a encore beaucoup qui ne sont toujours pas corrigé, qu'il reste de problème de sécurité et de virus à la pelle, etc...
Imagine comme IE aurait moins de bug (voir l'exemple firefox) s'il était libre...
Tu n'as toujours pas montré en quoi un logiciel proprio est forcément mieux supporté qu'un logiciel libre. Tu ne restes que dans les affirmations gratuites.
> Le truc c'est que toi tu t'amuses a dire "avec le libre on peut", alors qu'en pratique c'est infaisable.
En pratique c'est faisable. Pas toujours. OK.
Sachant que RH7.3 est sorti en mai 2002 on a déjà 4 ans de support dont seulement 2 par Redhat. Donc arrêtes de dire que ce n'est pas faisable alors que les faits prouvent le contraire.
[^]Re: De la maintenance..
Car avec le proprio tout ce qui est théoriquement possible l'est aussi pratiquement ?
Arrêtes d'enfoncer des portes ouvertes.
C'est ch*ant ta manie de tout rapport a une opposition libre<->proprio, t'es pas capable de juste regarder le libre sans chaque fois sentir le besoin de comparer avec le cote d'en face ?
J'ai dit nulle part que le proprio est mieux, pourtant tu le ressort a tout bout de champs.
Redhat a aidé à la mise en place de Fedora Legacy. Redhat aide encore fedora legacy pour le hardware, la bande passante, l'utilisation du bugzilla de redhat, etc. Ce qui est normal puisqu'à l'origine du project fedora (je ne parle pas de fedora.us) redhat avant annoncé fedora legacy. Mais redhat n'aide pas pour le support.
Néanmoins des employés de redhat, sur leur temps personnel (c'est-à-dire sans être payé par redhat) aident le projet fedora legacy.
C'est marrant comme tu decris ca, a te lire on dirait que Fedora peut pas vivre sans Redhat...
Ben en pratique c'est faisable et fin.
Pourtant la realite montre l'inverse, je ne vois aucune SSII offrant une maintenance d'anciennes distribs
En pratique le logiciel libre est mieux supporté que le logiciel proprio. Si l'envis te prend de mettre ça en doute, rapporte le au nombre d'utilisateur ou au pognon et l'affaire est classée.
On s'en fout du nombre d'utilisateurs et du pognon, soit c'est supporte soit ca ne l'est pas. Quand j'utilises un OS j'en ai rien a battre d'avoir une excuse "mais il n'y a que 200 utilisateurs", je veux un support decent.
Regardes qu'il faut plusieurs années à MS pour corriger des bugs dans IE et MS-office. Et il y en a encore beaucoup qui ne sont toujours pas corrigé, qu'il reste de problème de sécurité et de virus à la pelle, etc...
Imagine comme IE aurait moins de bug (voir l'exemple firefox) s'il était libre...
Ah le grand n'importe quoi, on met des annees a corriger les bugs dans IE ? Ca sort d'ou ca ?
Qualite du code ? Tu me fais bien rire, tu veux pas comparer Apache 2 a IIS 6 qu'on rigole ? Pourtant il est libre Apache, et il est proprio IIS.
Sans parler du fait que nous, on corrige encore les bugs dans NT4 qui date de 1996, c'est pas pour rien que je te demandais une boite qui maintient Redhat 5.2...
Sachant que RH7.3 est sorti en mai 2002 on a déjà 4 ans de support dont seulement 2 par Redhat. Donc arrêtes de dire que ce n'est pas faisable alors que les faits prouvent le contraire.
Non, ca fait 4 de support, les 4 par Redhat, car Fedora sans Redhat, ils sont rien du tout. Sans parler du fait que Fedora n'a evidemment pas les memes moyens de test que Redhat avait pour la maintenance.
[^]Re: De la maintenance..
> C'est marrant comme tu decris ca, a te lire on dirait que Fedora peut pas vivre sans Redhat...
Ben actuellement on peut dire que Fedora vit grace à redhat. Sans redhat fedora serait-il mort ?
Je n'en sais rien.
> Pourtant la realite montre l'inverse, je ne vois aucune SSII offrant une maintenance d'anciennes distribs
T'es charmant. Oui, redhat 4.2 ou mandrake 6.0 ne sont plus supportées. Je te dit que ce qui est fait pour redhat 7.3 (ce que permet le libre) ne peut être fait pour windows 98 (MS ne le permet pas). Je ne te dis pas que les anciennes distributions sont systématiquement supportées. Je dis que le libre le permet et parfois c'est fait. Le proprio ne le permet pas et donc ce n'est jamais fait.
Je crois que microsoft a décidé de ne plus supporter visual basic à terme. Donc même s'il y a de la demande, VB ne sera pas supporté. Même s'il y a de la demande, on n'a même pas à ce demandé s'il y a une SSII qui a les compétences pour le faire et si elle peut proposer une offre intéressante.
Toi tu pars du principe qu'une boîte proprio fait les choses forcément bien. Et si une boîte proprio arrête le support trop tôt par rapport à la demande ? Tu fais quoi ?
Rien. Tu subis.
Et si une boîte proprio arrête le support d'un produit pour des raisons statégique (genre forcée les mises à jours) ? Tu fais quoi ?
Rien. Tu subis.
De plus, si tu me relis, j'ai jamais dit que c'était la panacée. J'ai dit que pour les clients concernés, c'est un plus significatif.
> On s'en fout du nombre d'utilisateurs et du pognon, soit c'est supporte soit ca ne l'est pas. Quand j'utilises un OS j'en ai rien a battre d'avoir une excuse "mais il n'y a que 200 utilisateurs", je veux un support decent.
Ce que j'utilise est supporté. Et toi ?
> car Fedora sans Redhat, ils sont rien du tout.
Plus haut tu semblais dire l'inverse.
> Sans parler du fait que Fedora n'a evidemment pas les memes moyens de test que Redhat avait pour la maintenance.
Ce n'est pas pareil, le public de Fedora et rhel est différente. Je pourrait même dire que Fedora est plus testé que rhel. rhel a besoin de moins de test car rhel est basé sur fedora (les différences entre ces deux distributions sont très minimes). Les tests de rhel sont surtout orienté vers les partenaires de redhat (Oracle, Dell, etc). Moins il y a de bug dans fedora, moins il y a de bug dans rhel. Redhat et les employés de redhat le savent très bien.
Pour ses finances (point crucial pour une société commerciale) redhat dépend de rhel. Mais rhel dépend de Fedora. Donc il y a nettement plus de développeurs redhat sur le projet fedora que sur rhel (ça a été reconnu par redhat).
Pour ce qui est des ressources, depuis plusieurs mois (voire années car ça a débuté avec fedora) redhat met tout en libre. C'etait une veille promesse non officielle de redhat qui depuis quelques mois est officielle. Redhat a reconnu que ça a pris beaucoup beaucoup plus de temps que prévu (entre autre car redhat utilisait des logiciels avec des clauses de non divulgation).
Pour le build automatique, c'est fait depuis plus d'un an.
Il manque les outils de test.
C'est en cours :
http://trends.newsforge.com/trends/06/07/11/1431207.shtml?ti(...)
and anticipates integrating a fuller set of them into the Fedora Core 6 test releases later in the summer. "We're going to be running them basically through the same tests we run RHEL through," he says. After the release of Fedora Core 6, he plans to move the testing lab outside of Red Hat to make it generally accessible to everyone in the Fedora community.
http://www.108.redhat.com/
Les gens sous-estiment énormément l'importance capitale qu'a Fedora pour RedHat.
En étant simpliste : pas de fedora alors pas de rhel, pas de rhel alors pas de redhat.
Il est de l'intérêt de redhat de faire de fedora la meilleur distribution possible qu'ils peuvent et de la supporter au mieux afin d'enlever un maximum de bug (du moins sur la durée de vie définie par redhat).
Quand redhat (le marketing) veut ajouter xen à rhel pour ces clients et se faire du pognon, redhat ne laisse pas vivoter fedora dans son coin et se met à coder pour rhel. Non, redhat met le paquet sur Fedora pour avoir xen sous fedora.
Mais n'oublies que fedora et rhel n'a pas le même public.
Le public de fedora est les développeur et les hobbyistes. Fedora doit sortir souvent et tôt même si tout n'est pas parfait. Sinon les développeur s'emmerdent et les hobbyistes vont voir ailleurs. Il y a des compromis à faire mais la qualité n'est pas une enjeux mineur. C'est pour celà que bien que fc2 a selinux, selinux a été désactivé par défaut lors de la sortie (mais celui qui veut "jouer" avec peut). Idem pour cairo ou xen dans fc5 mais qui est désactivé par défaut.
Fedora c'est pour la communauté du libre, rhel pour les entreprises.
[^]Re: De la maintenance..
< Pourtant la realite montre l'inverse, je ne vois aucune SSII offrant une maintenance d'anciennes distribs
T'es charmant. Oui, redhat 4.2 ou mandrake 6.0 ne sont plus supportées. Je te dit que ce qui est fait pour redhat 7.3 (ce que permet le libre) ne peut être fait pour windows 98 (MS ne le permet pas). Je ne te dis pas que les anciennes distributions sont systématiquement supportées. Je dis que le libre le permet et parfois c'est fait. Le proprio ne le permet pas et donc ce n'est jamais fait.
Je crois que microsoft a décidé de ne plus supporter visual basic à terme. Donc même s'il y a de la demande, VB ne sera pas supporté. Même s'il y a de la demande, on n'a même pas à ce demandé s'il y a une SSII qui a les compétences pour le faire et si elle peut proposer une offre intéressante.
Toi tu pars du principe qu'une boîte proprio fait les choses forcément bien. Et si une boîte proprio arrête le support trop tôt par rapport à la demande ? Tu fais quoi ?
Rien. Tu subis.
Et si une boîte proprio arrête le support d'un produit pour des raisons statégique (genre forcée les mises à jours) ? Tu fais quoi ?
Rien. Tu subis.
De plus, si tu me relis, j'ai jamais dit que c'était la panacée. J'ai dit que pour les clients concernés, c'est un plus significatif.
Je pense que PbPg n'a pas compris une différence fondamentale !!!
Dans le monde du proprio changer de version veux dire :
- achat de licence a coût prohibitif^Wprix sympa ;)
- achat des versions n+1 des logiciels métiers utilisés car l'api a changé, tout ne marche plus pareil, etc...
- achat de support pour les versions de l'os+logiciel métier
Dans le monde du libre :
- changer de version ne coûte rien (ou presque)
- achat de la version n+1 du logiciel métier (si il n'est pas en libre et gratuit)
- achat de support pour la nouvelle version de l'os+logiciel métier.
La seule différence est que les compétences internes peuvent débroussailler le terrain.
Exemple :
Équipe de test qui valident tout sur une mandriva cooker (future 2007)
=> on sait si on doit acheter (ou non) la version n+1 du logiciel (si il est proprio)
=> vérification de l'api (être sur que la chaîne dont dépend le logiciel est toujours la même), ce qui limite la casse...
=> on limite les besoins de support, on a validé toutes les utilisations courante, donc il reste "seulement" la sécurité et les bugs triviaux (la compétence interne peux suffire pour ceux-ci)
Bref, en étant ouvert le logiciel libre change la donne et laisse le choix a l'utilisateur/entreprise (et permet de limiter le coûts).
Après l'entreprise n'est pas prisonnière, a savoir que si ça lui chante elle peux rester sur une version non supportée de l'os interne et payer quelqu'un pour s'occuper de limiter la casse, prévoir les migrations a moindre coût.
=> Si on tombe dans les grands compte, la donne est pas pareille, eux ont les moyens de payer, même a prix d'or, un support.
=> Si on reste dans les PME/PMI, vu le prix/niveau de support pour le proprio par rapport a celui du libre elle ne sont pas perdantes en passant au libre (rapport finances/support réel/prix du ticket de correction).
site perso : http://rapsys.free.fr/
[^]Re: De la maintenance..
Ext3 était un bien meilleur choix et je suis sûr qu'attendre Ext4 sera encore un meilleur choix actuellement plutôt que d'être pressé et passer en Reiser4.
bizarre que tu parle d'ext4 (a l'état de projet) et pas de zfs ...
Pourquoi les gens croient qu'il n'y a que deux candidats ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: De la maintenance..
C'est vrai que ZFS c'est de la tuerie si on en croit ce lien :
http://www.sun.com/2004-0914/feature/
Mais il est intéressant quand on a bcp de disques durs (baies de stockage). Du coup on a un espace de stockage virtuel pour l'OS et zfs fait l'interface avec le monde physique (le stripping des données sur plusieurs disques, les partitions virtuelles, etc, etc...)
J'ai peur qu'il n'ai pas trop d'utilités sur une machine perso toujours limitée à 4 partitions par nos super bios
[^]Re: De la maintenance..
ZFS sera de plus intégré dans le futur Mac OS. Pour Reiser4, on dirait que la distrib Linspire le soutient : http://www.linspire.com/lindows_news_pressreleases_archives.(...)
[^]Re: De la maintenance..
> ZFS sera de plus intégré dans le futur Mac OS.
C'est officiel maintenant ou toujours juste une rumeur?
[^]Re: De la maintenance..
Ce n'est que rumeur et affabulations, tout ça parce qu'un développeur de MacOS X a un jour dit qu'il trouvait ZFS assez sympa, ou quelque chose de ce genre.
[^]Re: De la maintenance..
Le bios limite à 4 partitions primaires, mais avec des partitions étendues, tu peux avoir plus de partitions (grâce aux partitions logiques). En plus linux peut s'installer sans problème sur une partition logique contrairement à windows qui dois être installé sur une partition primaire.
Sur mon disque dur, j'ai 8 partitions (3 primaires, et 5 logique).
[^]Re: De la maintenance..
En fait on ne peut stocker que 4 partitions dans le mbr, et on peut ensuite dans chaque partition parincipale créer des "sous-partitions". (en fait on est d'accord :-)
Mais cette adresse l'explique mieux que moi :
http://www.generation-nt.com/dossiers/lire/29/table-de-parti(...)
Il s'agit bien d'une LIMITATION du BIOS, car à l'époque des amiga en OS3.1 (1992), le mbr n'avait rien à voir avec celui des PC et les informations de partitionnement étaient bien placés différement.
Après tout le mbr en premier secteur et la table de 4 partitions principales sont une convention.
On peut imaginer un bios qui gére un MBR de 128ko avec un gestionnaire de boot intégré et la possibilité de créer jusqu'à 128 partitons primaires ou plus.
Finallement je regrette presque que l'itanium n'est pas marché, ça nous aurait peut être finallement débarassé du bios de 82 !
Vivement un linuxBios avec xen intégré :-)
[^]Re: De la maintenance..
en fait on ne peut stocker que 4 partitions primaires si on utilise un partitionnement compatible windows
c'est pas le seul qui existe (regardez les options du noyau sur ce point la pour vous en convaincre)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: De la maintenance..
Est-ce que par hasard tu as un lien qui explique ces différentes possibilités ?
[^]Re: De la maintenance..
aucun non , désolé (meme apres une recherche rapide google).
Mais je sais qu'il y a eu une discution dans un journal dessus il y a longtemps (quand quelqu'un était venu proposé un nouveau schéma de table de partition) .
Peut etre en creusant vers cette direction ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: De la maintenance..
Il y a le systeme de partitions GPT, qui va avec EFI et permet d'avoir 128 partitions primaires. Il me semble qu'on pouvait, moyenant un peu de tuning, augmenter le nombre... Le probleme n'est pas tellement les OS, vu que meme Windows 2000 savait reconnaitre les tables de partitions GTP. Le truc c'est que je crois que les BIOS n'aiment pas trop...
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: De la maintenance..
c'est sûr que ça peut surprendre mais je croyais que l'un des bénéfices du libre tout ça c'était qu'on puisse justement subvenir au départ d'un ou du développeur et continuer le projet concerné, par exemple au minimum l'entretenir et fixer les bugs découverts au fur et à mesure ?
Justement, pour pouvoir faire ça, il faut que le code soit maintenable.
À ce titre, au fur et à mesure des engeulades avec Hans Reiser, les devs du kernel ont formulé explicitement des exigences minimales et de bon sens pour l'acceptation d'une grosse nouvelle fonctionalité sensible dans le noyau, car Hans Reiser semblait les ignorer ou les négliger:
- Le code doit respecter les coding standards du noyau (longeur des lignes etc.). Hans Reiser a fait le malin lorsqu'on lui a dit ça: "ouiii mais les coding standards, ça limite ma créativité [...]", mais il devra y passer, comme tout le monde.
- Le code doit utiliser les frameworks & API type vfs (qui eux sont bien maintenus) du kernel lorsqu'ils existent, et ne pas chercher à réinventer la roue "parce que je suis génial et j'ai réinventé l'idée même de filesystem, donc je vais tout refaire: les autres sont des cons, leur framework est pourri".
- Le code doit être relu, corrigé et aprouvé par (au moins) un autre expert du domaine (ça permet de remonter des bugs assez tot, et surtout ça fait une nouvelle personne qui connait assez le code pour le maintenir). C'est assez difficile avec le code d'Hans Reiser car celui-ci conteste la moindre remarque, puis monte sur ses grands cheveaux, puis fait le coup du géni incompris ("tu ne peut pas auditer mon code parce que tu est trop imprégné des concepts des fs classiques"), puis fini en attaque personnelles ("tu es un mauvais developpeur", "tu es un idiot", "tu m'en veut personnellement", ...). Si bien que tout les developpeurs qui ont bien voulu aider Reiser en tenant ce role ont finalement déclaré forfait.
- Le code doit être pret. Hans Reiser prétend que son reiserfs4 est pret depuis plusieurs années (en fait, avant même le 2.6.0 !). Celà dit il a récement publié sa "todolist" de choses importantes à finir pour que reiserfs4 soit au point (selon lui): preuve qu'il ne faut pas le prendre au sérieux quand il dit que c'est pret, et qu'il faut vraiment un tiers expert pour auditer et décider.
- Facultatif (mais ça accèlere grandement l'inclusion), le code peut être soutenu par un "vendor" (une distribution) qui par ex. essai de l'améliorer, le corriger et l'intègre comme fs par défaut. Malheureusement, les diverses distros qui ont soutenu Hans en tenant ce role pour reiserfs3 sont maintenant échaudées (elles l'on vu se dégager de tout intéret et ne pas participer aux corrections de bugs), et aucune ne semble prete à recommencer pour reiserfs4 (bien qu'Andrew Morton ai formulé cette demande au sujet de reiserfs4 sur lkml).
heureusement qu'il n'est pas passé sous un train pendant qu'il s'occupait de reiser3, hein.
C'est tout comme.
Presque aussitot que reiserfs3 a été intégré dans le noyau, Hans est passé à l'implem de reiserfs4 et a cessé de travailler à la correction de bugs. Cette expérience n'encourage pas les developpeurs à relacher les contraintes que j'ai listé ci-dessus. D'autant que la maintenance des filesystems est une des choses les plus sensibles (on peut abandonner le support d'un driver, mais pas d'un fs), et que reiserfs4 veut "revolutionner" beaucoup de concepts acquis (ce qui l'expose encore plus aux problèmes de maintenabilité potentiels).
Sur ce point, je regrette même que le noyau Linux ai une politique trop lâche par rapport à d'autres OS (les *BSD) où, lorsqu'un dev s'est grillé en incluant du mauvais code ou ne le maintenant pas, il est mis en quarantaine et en tout cas, ne peut plus se permettre de publier des nouveautés wizbang tant qu'il n'a pas corrigé les problèmes. Et dans la culture (et la com: les releases/changelogs/, inteviews, mailing-lists...) ils essaient de mettre plus en avant le travail de ceux qui nettoient et corrigent que de ceux qui ajoutent du code (l'inverse de Linux depuis 2.6 quoi).
Bénéfice secondaire, le newbie qui veut se faire admettre (ou qui cherche la gloire ;) va plutôt chercher à trouver et corriger un nouveau bug qu'à implémenter un quarantième scheduler ; et les utilisateurs de ces systèmes, qui sont dès lors plus sensibilisés à ces questions de qualité de code, ne mettent plus la pression sur les devs pour qu'ils intégrent le dernier fs survendu par le marketing narcissique d'un teuton paranoïaque. La culture qualité, c'est tout bon.
Récement Alan Cox et Linus Torvald ont tiré la sonette d'alarme en reprochant aux developpeurs (surtout ceux payés par des fabriquants de matériel) de ne pas s'occuper du bugzilla, et de passer immédiatement à l'implem d'un nouveau truc dès que leur code est accépté. Il a même été question de faire une release uniquement dédiée à la correction du merdier, avec interdiction d'ajouter des fonctionalités.
Je crois qu'il est vraiment temps que Linux devienne exigeant non plus seulement sur la qualité apparement du code, mais sur l'attitude des developpeurs (eg. refuser le nouveau code d'un dev qui a des bugs à corriger, même si ce code parrait bon), pour qu'enfin ces devs se responsabilisent.
En somme, être un logiciel libre n'oblige pas a abandonner tout le travail de qualité logicielle et a accepter n'importe quel patch douteux. C'est le problème avec l'inclusion des produits Reiser...
[^]Re: De la maintenance..
Le code doit utiliser les frameworks & API type vfs (qui eux sont bien maintenus) du kernel lorsqu'ils existent, et ne pas chercher à réinventer la roue "parce que je suis génial et j'ai réinventé l'idée même de filesystem, donc je vais tout refaire: les autres sont des cons, leur framework est pourri".
Et quand le 'truc bien maintenu' est bien pour les developpeurs qui l'ont dévellopé mais absolument pas pour toi , tu fais quoi ? tu fais des gros hack immondes pour que ca fasse ce que tu veux, tu attend que ca change, ou tu "réimplémente a ta sauce" ?
Je ne sais pas si c'est le cas pour reiser4 , mais je connais aucun dévellopeur pro (dont c'est son métier) qui s'amuser a réinventer la roue pour le plaisir.
Le code doit être pret. Hans Reiser prétend que son reiserfs4 est pret depuis plusieurs années (en fait, avant même le 2.6.0 !). Celà dit il a récement publié sa "todolist" de choses importantes à finir pour que reiserfs4 soit au point (selon lui): preuve qu'il ne faut pas le prendre au sérieux quand il dit que c'est pret, et qu'il faut vraiment un tiers expert pour auditer et décider.
Le code peut tres bien etre "pret" et quand meme avoir du boulot dessus (optimisation, ajout de fonctionnalité etc ...).
A t'entendre le code de linux (le noyau) n'est pas pret vu qu'il y a quand meme une todo list dessus !
Récement Alan Cox et Linus Torvald ont tiré la sonette d'alarme en reprochant aux developpeurs (surtout ceux payés par des fabriquants de matériel) de ne pas s'occuper du bugzilla, et de passer immédiatement à l'implem d'un nouveau truc dès que leur code est accépté.
De l'autre coté ils disent que c'est au distribution de s'occuper de la stabilité du noyau.
Faut savoir ce qu'on veux aussi , soit on veux assurer un support, soit on dis "c'est aux autres de le faire".
Mais on peut pas reprocher aux gens de suivre les lignes de conduites .
Soit on fait des noyaux bien stables, soit on est dans le systeme actuel et dans ce cas on accepte que les gens n'assurent pas le support .
Subete ga wakatta toki…watashi ga anta wo korosu.