Articles précédents : Logiciel
- [10] Mise à jour de Qstat et XQF
- [38] Nouvelle version stable de BIE (v 6.0.3)
- [69] Linux 2.6.8, suivi de près par Linux 2.6.8.1
- [56] SpamAssassin devient un projet Apache, et corrige une faille de sécurité
- [39] L'éditeur HTML Nvu 0.40 est sorti
- [3] PloneiCalendar 1.0Beta2 est sorti !
- [31] Yzis sort sa deuxième version
- [38] Un aperçu de GNOME 2.8
- [27] Blender 2.34 est sorti
- [76] Nouvelles versions des pilotes ATI et NVIDIA pour GNU/Linux
Liens connexes
- Reiserfs V4 (1678 hits)
- Benchmarks Reiserfs VS ext3 (2336 hits)
- "dancing trees" (1203 hits)
- La news sur Slashdot (1273 hits)
- La news sur OSnews (675 hits)
- Téléchargement (1080 hits)
Dépêche modérée par
Dépêche éditée par
Reiserfs est un système de fichiers journalisé, c'est à dire qu'il apporte un gain de sécurité en terme d'intégrité des données par rapport à un système de fichiers classique. Cette version a été écrite sans utiliser le code de la version précédente, qui sera toujours maintenu pour corriger les bugs le cas échéant. Les développeurs affirment avoir conçu cette nouvelle mouture en portant une attention particulière à la qualité du code.
Reiserfs supporte les transactions atomiques : une modification sur le disque est effectuée ou non, mais elle n'est jamais effectuée "à moitié". Cela permet de s'assurer en permanence de l'intégrité du système de fichiers. Cette atomicité ne s'effectue pas au dépend des performances grâce à un algorithme assez sophistiqué.
Au menu également les "dancing trees", qui rendent obsolètes les "B-trees" utilisés auparavant. Cette technologie permet de gérer des systèmes de fichiers d'une taille importante. Reiserfs 4 intègre maintenant un système de plugins afin de faciliter le développement de fonctionnalités supplémentaires. Toutes ces fonctionnalités permettent d'envisager de nouvelles applications, ainsi sa très grande facilité de gestion de nombreux petits fichiers lui permettrait de remplacer avantageusement une base de données dans certains cas.
Au final Reiserfs met la barre assez haut et n'a pas à rougir face à ses principaux rivaux (ext3 notamment).
NdM : merci à Dario Spagnolo et à Mark Havel pour avoir également proposé des dépêches sur le sujet.
Reiserfs V4 (1678 hits)
Benchmarks Reiserfs VS ext3 (2336 hits)
"dancing trees" (1203 hits)
La news sur Slashdot (1273 hits)
La news sur OSnews (675 hits)
Téléchargement (1080 hits)
> Lire la suite (156 commentaires, moyenne: 3,5). [dépêche : 507 caractères]
déjà qlqs commentaires là
dans le journal de Brice Arnould :
http://linuxfr.org/~98111/15041.html(...)
-
[^]Re: déjà qlqs commentaires là ==> Performances
-
[^]Re: déjà qlqs commentaires là
Posté par Pierre Jarillon (page perso, ) le 27/08/2004 à 10:33. (lien). Évalué à 4.Attention, l'article n'est pas très rigoureux sur les noms. Alors, soyons précis :
- Hans Reiser est le nom de l'auteur, un homme aussi sympathique et discret que compétent dans ce domaine. Nous l'avons rencontré lors des premières RMLL en 2000 (*).
- reiserfs nom du système de fichier créé par Hans Reiser. Il y a eu trois versions majeures.
- reiser4 C'est le nouveau système de fichier. C'est aussi un changement de nom puisque "fs" a disparu du nom et est remplacé par un chiffre.
(*) Hans Reiser et David Axmark (MySQL) ne s'étaient pas quitté pendant les RMLL. Ils avaient pu comparer la problématique des transactions avec celle de la journalisation et aborder divers autres points à la frontière de leurs spécialités. David Axmark a ensuite implémenté les transactions et reiser4 a bien des points communs avec une base de données....
Kadreg est mailleur avec Photoshop
Après avoir s'être fait sponsorisé par SuSE pour le développement de Reiser3 et par Lindows.com pour le debuggage de Reiser4, j'espère que Reiser va réussir à trouver un autre sponsor pour payer des cours de Gimp au graphiste.
Quand je vois des horreurs comme http://namesys.com/r4pics/sequencebytes.jpg(...) j'hésite à utiliser ReiserFS, craignant de retrouver mes images toutes salies avec du texte mélangé.
Gestion des ACLs
J'ai pas le temps de parcourir les docs donc si quelqu'un connait la réponse à :
Est ce que ReiserFS support les ACLs ?
-
[^]Re: Gestion des ACLs
Posté par Anthony F. () le 24/08/2004 à 20:29. (lien). Évalué à 1.En tout cas, il n'est pas fait mention de ce système sur le guide des ACL de LinuxFrench :
http://www.linuxfrench.net/gnu_linux/comment_fonctionnent_les_acl_p(...)
-
[^]Re: Gestion des ACLs
Posté par Sebastien Binet () le 24/08/2004 à 20:38. (lien). Évalué à 3.Après un (rapide) tour chez notre ami google, j'ai trouvé ça :
http://thebsh.namesys.com/snapshots/2004.02.25/READ.ME(...)
Il semblerait donc bien que le support ACL soit là.
-
[^]Re: Gestion des ACLs
Posté par Julien MOROT (Jabber id, page perso, ) le 24/08/2004 à 20:39. (lien). Évalué à 3.Reiserfs 3 gère très bien les ACL avec un kernel 2.6.
Pour ce qui est de reiserfs 4, je ne sais pas.
-
[^]Re: Gestion des ACLs
Posté par Brice Arnould ( un_brice ) (page perso, ) le 24/08/2004 à 21:15. (lien). Évalué à 8.Sur http://namesys.com/v4/v4.html(...) il est dit que l'intégration des ACLs a été pensée, et que donc l'architecture du système de plugins le permet (si j'ai bien capté) mais que c'est pas encore fait.
Une bonne ocaz' de découvrir l'API donc -_^. De toutes manières, elles seront probablement implémentées de 60 manières différentes avant même que Reiserfs4 ne soit disponible en production.--
Respect à RMS.-
[^]Re: Gestion des ACLs
Posté par Temsa (Jabber id, page perso, ) le 25/08/2004 à 05:58. (lien). Évalué à 12.Pour ceux, qui, comme moi, les ACL ça dit vaguement quelquechose(voir a qui ça ne dit rien du tout), mais ne se rappellent plus ce que c'est, j'ai trouvé une très bonne explication ici:
http://okki666.free.fr/docmaster/articles/linux100.htm(...)-
[^]Re: Gestion des ACLs
Posté par tgl () le 25/08/2004 à 07:31. (lien). Évalué à 5.Vu aussi sur le feed RSS de linuxfrench :
http://www.linuxfrench.net/gnu_linux/comment_fonctionnent_les_acl_p(...)
-
[+] [^]Re: Gestion des ACLs
Posté par Jean Parpaillon (Jabber id, page perso, ) le 25/08/2004 à 08:06. (lien). Évalué à -8.Si tu ne sait pas ce que sont les ACLs, c'est que t'en a pas besoin, non ?
-
[^]Re: Gestion des ACLs
Posté par Sebastien Binet () le 25/08/2004 à 08:39. (lien). Évalué à 4.Et ?
Et bien il dit qu'il a plus de genou.
Il a peut-etre juste envie de savoir ce que c'est. Faut etre un peu ouvert dans la vie. La curiosite n'est pas un vilain defaut :)-
[+] [^]Re: Gestion des ACLs
Posté par Jean Parpaillon (Jabber id, page perso, ) le 25/08/2004 à 09:16. (lien). Évalué à -3.Je parlais dans le cas précis des ACLs, c'est le genre de truc qu'il vaut mieux ne pas utiliser si tu ne sais pas ce que c'est.
Si c'est juste pour le fun, bien sûr, il faut le faire puisque c'est inutile ;) Par contre, si c'est pour utiliser en production, vaut bien connaître le sujet.
C'est un peu comme se faire un cluster de User-Mode Linux ou installer Hurd...
-
-
-
[^]Re: Gestion des ACLs
Posté par Nÿco (Jabber id, page perso, ) le 25/08/2004 à 08:40. (lien). Évalué à 14.Je dirais que les ACLs suppriment les limitations du modèle rwx sur le owner, groupe et all (même avec les petits plus que sont les setuid et setgid), puisqu'on peut faire une liste illimitée de droits unitaires sur les fichiers et répertoires.
En d'autre termes, c'est absolument nécessaire, et à vrai dire ça ne devrait pas être une option du tout, mais bel et bien une fonctionnalité de base de tout FS sous Linux. De même, toutes les applis et interfaces graphiques devraient pourvoir gérer les ACLs, ce qui est loin d'être le cas actuellement.
Un des problèmes, c'est qu'entre XFS et Ext2/Ext3, ça n'est pas la même chose (commandes, etc.). Autre problème, le mapping Samba des ACLs Linux est simple voire simpliste mais ne correspond pas (est une sous-ensemble) des ACLs du monde Windows (NT-family). Encore un autre problème, les ACLs ne sont pas sauvegardés par les outils standards (GNU tar, etc.).
Je suis partisan du "ACL-everywhere" normalisé dans le monde Linux, et ne suis pas le seul.--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: Gestion des ACLs
Posté par DiZ () le 25/08/2004 à 10:26. (lien). Évalué à 0.Les ACLs sont bien plus complexes à gérer (admin) et à comprendre (utilisateur) que les droits *nix classique.
Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).-
[^]Re: Gestion des ACLs
Posté par Nÿco (Jabber id, page perso, ) le 25/08/2004 à 11:30. (lien). Évalué à 2.> Les ACLs sont bien plus complexes à gérer (admin) et à comprendre (utilisateur) que les droits *nix classique.
Les ACLs sont - au contraire - bien plus simples à gérer et comprendre car elles sont intuitives, ce qui n'est pas le cas du modèle rwx doublé des setuid+setgid (moins les aspects habitude de l'utilisateur/admin).
> Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
Elles sont également nécessaires dans un environnement bureautique Samba (authentification sur domaine + partages de répertoires et d'imprimantes autant sur des serveurs que des stations), autrement dit dans le cas d'un parc bureautique hétérogène Linux+Windows, donc à peu près partout où Linux essaie de s'insérer dans une entreprise ou une administration (puisque Windows est présent partout).
Idem pour les environnements Novell a priori je pense, à vérifier. Des utilisateurs de réseaux Novell peuvent-ils nous confirmer qu'ils utilisent bien les ACLs ?
Mac OS X ayant également Samba inclus un peu partout dans le système, il doit certainement avoir des ACLs, non ? Quelqu'un pour confirmer ?--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: Gestion des ACLs
Posté par DiZ () le 25/08/2004 à 12:31. (lien). Évalué à 2.>Les ACLs sont - au contraire - bien plus simples à gérer et comprendre car elles
>sont intuitives, ce qui n'est pas le cas du modèle rwx doublé des setuid+setgid
>(moins les aspects habitude de l'utilisateur/admin).
http://www.suse.de/~agruen/acl/linux-acls/online/(...) pour vous faire une idée et comparer avec les droits *nix classique :)
>> Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
>Elles sont également nécessaires dans un environnement bureautique Samba
Je crois que tu répètes ce que je viens de dire....
A noter qu'il faut pas que ce soit trop homogène non plus MacOS9 n'aime pas les ACL...
-
-
[^]Re: Gestion des ACLs
-
-
[^]Re: Gestion des ACLs
Posté par Thomas S. (page perso, ) le 25/08/2004 à 13:52. (lien). Évalué à 4.> Autre problème, le mapping Samba des ACLs Linux est simple voire
> simpliste mais ne correspond pas (est une sous-ensemble) des ACLs
> du monde Windows (NT-family)
C'est pas trop le mapping samba qui pose problème, c'est plutôt le modéle des ACL posix non ? Les ACL Windows à partir de 2000 sont bien plus complettes et compliqué que les ACL posix.
Ce qui me géne le plus c'est le manque de délégation pour la gestion des droits des fichiers (seul root et le owner ont ce droit).
> Je suis partisan du "ACL-everywhere" normalisé dans le monde Linux,
> et ne suis pas le seul.
Ensemble ça fait déjà deux ;)-
[^]Re: Gestion des ACLs
Posté par Nÿco (Jabber id, page perso, ) le 25/08/2004 à 14:13. (lien). Évalué à 2.> Les ACL Windows à partir de 2000 sont bien plus complettes et compliqué que les ACL posix.
s/bien plus/trop/ ?
Il y a vraiment trop de bruit dans les ACLs NT àmha. Mais bon, GNU/Linux sans ACLs fait quand même playschool à côté... ;-)--
Jabber ID : xmpp:Nyco@jabber.fr
-
[^]Re: Gestion des ACLs
Posté par Tom Sheldon () le 25/08/2004 à 18:41. (lien). Évalué à 4.La gestion des ACLs n'est qu'un sous-ensemble de la gestion de la sécurité.
Pour ce qui est de la délégation, SELinux devrait apporter un équivalent bien plus puissant.
Le hic pour l'instant reste la complexité de sa mise en place, mais debian, gentoo, redhat, suse sont en train d'y reflechir pour apporter ces outils à l'utilisateur de tout les jours. Ca avance, et vite !
Ce que j'attend avec impatience pour m'y lancer à fond, c'est la gestion SELinux d'Xfree.
Actuellement en cours de développement dans le cvs d'XOrg (branche XACE), sa sortie devrait démocratiser son utilisation.
-
-
-
[^]Re: Gestion des ACLs
Posté par ginkyo (page perso, ) le 25/08/2004 à 11:46. (lien). Évalué à 2.tiré de http://okki666.free.fr/docmaster/articles/linux100.htm(...)
>"Alice n'a pas d'accès en écriture aux fichiers qui pourraient être créés par >d'autres personnes dans tout répertoire sous shared."[..]
>"Le dernier point que nous avons soulevé tout à l'heure ne trouve pas de >solution en dehors des ACL."
Heu et le "setgid" alors ?
groupe users et le repertoire shared en setgid users...--
« Si quis scienter in tantum a vino abstineret ut naturam multum gravaret a culpa immunis non esset. »Saint Thomas d'Aquin, Somme théologique, II-II, 150, 1 ad 1.
-
-
-
[^]Re: Gestion des ACLs
Posté par gnumdk (page perso, ) le 24/08/2004 à 22:12. (lien). Évalué à 3.La suse 9.1 utiliser reiserfs3 + acl par defaut.
Pour le 4 je sais pas.
Conseils ?
Voilà, depuis que je suis sous Linux, j'utilise de l'ext3 partout.
Cependant, j'entend parler de ReiserFS, XFS, etc...
J'aimerais savoir lequels employer pour un maximum de performances pour :
- la partition /
- la partition /home/
- la partition qui contient mes rushes videos DV (entre 150 et 400Mo le fichier)
Qu'ai-je à gagner à utiliser un système plutôt qu'un autre ?
Je remercie d'avance celui qui prendra la peine d'un jour faire une petite comparaison assez simple et les domaines d'utilisation spécialisés de chaque FS. Je crois que je ne serai pas le seul à en profiter ;-)
-
[^]Re: Conseils ?
Posté par Yusei () le 24/08/2004 à 20:24. (lien). Évalué à 5.Je ne peux pas parler de performances, je n'ai pas fait de tests, mais pour la partition root (au moins), l'ext3 a l'immense avantage d'être compatible avec ext2, ce qui est une garantie que n'importe quel kernel Linux sera capable de monter la partition... utile en cas de crash, si tu veux utiliser un CD/clé USB/disquette pour booter.
Cependant, cet avantage perd de son importance au fil du temps. Moins la mémoire sera limitée et plus les noyaux supporteront de systèmes de fichier de base.-
[^]Re: Conseils ?
Posté par Nico_206 (page perso, ) le 24/08/2004 à 21:04. (lien). Évalué à 8.Tous les noyaux récent sur distrib "récentes" sous forme de live cd sont capablent de monter du reiserfs (et du xfs pour les noyau 2.6).
Je suis étonné que l'on compare reiserfs a l'ext3 qui est très lent.
Reiserfs est en théorie très rapide sur les petits fichier.
Le fs super rapide est l'ext2 mais n'est presque plus d'actualité pour les partition autres que le /boot. Attention au crash !
xfs est souvent bien classé mais j'ai eu pas mal de soucis avec lors de plantage -> fichiers corrompu. (le genre de truc que l'on évite avec les transaction atomique par ex).
Là je suis plutot content de ma reiserfs 3.6-
[^]Re: Conseils ?
Posté par ratatum () le 24/08/2004 à 21:37. (lien). Évalué à 3.
Le fs super rapide est l'ext2
D'aprés leurs benchs reiserfs4 semble être plus rapide que l'ext2 maintenant.
Par contre, les résultats CPU_TIME indiquent qu'il sollicite plus le processeur.
Quelqu'un sait il à quoi correspond la colonne DF?-
[^]Re: Conseils ?
Posté par Olivier Jeannet () le 25/08/2004 à 00:28. (lien). Évalué à 7.Quelqu'un sait-il à quoi correspond la colonne DF?
Je suppose qu'il s'agit du nombre de blocs occupés (ou libres), résultat de la commande usuelle "df", pour évaluer l'effacité de stockage du FS.
-
-
-
[^]Re: Conseils ?
Posté par Gaétan RYCKEBOER (page perso, ) le 25/08/2004 à 11:29. (lien). Évalué à 1.Oui, enfin... TOUS les noyaux, euh.. non.
Y'a plein de soucis dans des cas, genre si ton fichier journal est en vrac, si t'as certains type de corruption, etc, qui font que tu n'y arrivera pas forcément. Il vaut vraiment mieux avoir un kernel qui connaît bien ton FS, et les fsck qui vont avec.
Et le souci, c'est que tu monte toujours un vieux noyau quand ton FS est corrompu.. donc en plein dedans :)
Mais c'est vrai que la compatibilité EXT2/3, sur touts les autres aspects, est pratique.
-
-
[^]Re: Conseils ?
Posté par tgl () le 24/08/2004 à 21:03. (lien). Évalué à 13.Perso j'ai utilisé principalement ext3 et reiserfs3 jusqu'ici. Je me souviens avoir senti la différence de perfs entre les deux en faisant des grosses compiles (gros avantage pour reseirfs3, parceque c'est justement sur les nombreux accès à des petits fichiers qu'il excelle). Mais j'ai abandonné reiserfs3 depuis parceque ça m'est arrivé une fois où deux d'avoir des corruptions ou pertes de fichiers suite à des shutdowns violents, alors qu'avec ext3 jamais. Bon, c'est mon expérience, ça vaut ce que ça vaut hein...
Sinon, de ce que j'ai lu, c'est probablement XFS qui serait le plus adapté à ta partoche de vidéos. Il est apparement le plus performant pour les accès bien linéaires à des gros fichiers (streaming ou capture vidéo, etc.).
Quant à Reiser4, perso je vais tester pour ma prochaine installe de distrib¹. Sur le papier au moins, la robustesse à l'air d'être au rendez-vous cette fois, mais surtout j'ai bien envie de jouer avec les plugins, les fichiers aggregés, tout ça quoi. Y'a vraiment de l'inovation sur les features et pas juste une course à la vitesse, et ça ça mérite d'être essayé.
¹ D'ailleurs si qlqun connais un LiveCD supportant Reiser4 pour que je puisse amorcer un install gentoo, ça m'intérresse. Enfin sinon j'en ferais un, c'est pas bien grave.-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 01:19. (lien). Évalué à 5.> Je me souviens avoir senti la différence de perfs entre les deux en faisant des grosses compiles (gros avantage pour reseirfs3, parceque c'est justement sur les nombreux accès à des petits fichiers qu'il excelle).
Pour les compilations ?
Tu es sûre ?
Quand je compile, tout est en cache et le cpu est utilisé à 100 %.
Je ne suis pas un dingue de reiserfs, mais j'avoue qu'il me semble globalement plus rapide qu'ext3. Mais pas pour les compilations.-
[^]Re: Conseils ?
Posté par tgl () le 25/08/2004 à 01:52. (lien). Évalué à 3.> Quand je compile, tout est en cache
Comme tu le dis plus bas, ça n'est vrai que si la mémoire suit. À l'époque où j'utilisait du reiserfs, j'étais sur une petite config très juste à ce niveau, et ceci explique peut être celà. Bon maintenant, c'est vieux, donc je vais pas jurer cracher non plus, mais quand même, mon souvenir est vraiment celui d'une bonne surprise à ce niveau les premières fois que j'avais testé reiserfs.-
[^]Re: Conseils ?
Posté par Pierre Jarillon (page perso, ) le 28/08/2004 à 22:32. (lien). Évalué à 3.Le courrier stocké sous forme de maildir (et non de mailbox) semble fait pour reiser4.
-
-
[^]Re: Conseils ?
Posté par Tom Sheldon () le 25/08/2004 à 18:48. (lien). Évalué à 3.Que ton cpu soit utilisé à 100% lors d'une compilation ne m'étonne guère. Le contraire serait même inquiètant..
Reiser et ext3 n'ont pas d'optimisations spéciales quand aux compilations. Ce qui n'est pas le cas de reiser4 puisque, dès sa sortie, il supporte déja le plugin "fibration" qui consister à "mettre" cote à cote les fichiers ayant une extention identique, ce qui tendrait à accélérer les lectures/ecritures des .o et .c lors des compilations.
-
-
[^]Re: Conseils ?
Posté par SF () le 25/08/2004 à 08:38. (lien). Évalué à 4."D'ailleurs si qlqun connais un LiveCD supportant Reiser4 pour que je puisse amorcer un install gentoo, ça m'intérresse. Enfin sinon j'en ferais un, c'est pas bien grave."
La derniere YOPER en mode rescue semble répondre à ton besoin.
http://www.yoper.com/(...)
"Known to be a commercial strength Desktop Solution at 0 cost, this release provides the power user with many new features, encompassing REISER4 support for the root filesystem, new non-destructive NTFS resizing, graphical partitioning, option to use GRUB or LILO bootloaders, a new clustered control panel, KDE 3.3.0 Final, Linux Kernel 2.6.8.1, default Firewall and the OpenOffice.org Office Suite, all provided on 1 CD. The default "look and feel" has been enhanced and many bugfixes have been applied, including PCMCIA support during install and support for PPPoE."-
[^]Re: Conseils ?
-
-
-
[^]Re: Conseils ?
Posté par gallenza () le 24/08/2004 à 21:48. (lien). Évalué à 8.On ne peut pas vraiment comparer ReiserFS (ou XFS,etc...) à ext3, car ils ne boxent pas dans la même catégorie....ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2, c'est donc toujours un système de fichier avec une décennie de retard maintenant, alors que les autres systèmes de fichiers cités sont tous basés sur des théories du système de fichier beaucoup plus puissantes et évoluées....
Pour y voir plus claire : http://jfenal.free.fr/Traduc/LG55D/lg55d-fr/lg55d-fr-4.html(...)-
[^]Re: Conseils ?
Posté par Olivier Jeannet () le 25/08/2004 à 00:18. (lien). Évalué à 7.ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2
ext2 n'est pas le plus récent des systèmes de fichiers, mais il reste assez performant, même sur grosses partitions (qui n'existaient pas quand le FS a été conçu). En usage courant, chez moi ext3 est tout à fait satisfaisant (par ex, un "dd if=/dev/zero of=/big/toto" sur 1 Go se déroule à une vitesse proche de la vitesse d'écriture brute du disque), en tous cas je n'ai jamais perdu de fichier (il est vrai que je n'ai que très rarement eu de coupure brutale ou plantage), et c'est le plus important à mes yeux.
Je ne suis pas sûr qu'un FS conçu plus récemment soit beaucoup plus performant, surtout pour l'usage que nous avons généralement de nos machines (en tant que particulier).
NB: c'est antédiluvien ("anté" = avant, "diluvien" indique le déluge).
-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 01:38. (lien). Évalué à 12.> Pour y voir plus claire : http://jfenal.free.fr/Traduc/LG55D/lg55d-fr/lg55d-fr-4.html(...)
On y voit rien !
Ext3FS :
1) Taille maximale du système de fichiers : 4 To
2) Taille de blocs : De 1 à 4 Ko
3) Taille maximale de fichier : 2 Go
1) => faux. je n'ai pas d'url sous la main mais c'est faux au moins pour Linux 2.6
2) => vrai ! bravo !
3) => faux.
Voilà un de mes répertoires (j'enregistre les JO :-) :
$ ll -h
total 14G
-rw-r--r-- 1 me me 1,5G aoû 24 21:00 JO_2004-08-24-19:52.avi
-rw-r--r-- 1 me me 2,5G aoû 24 23:00 JO_2004-08-24-21:00.avi
-rw-r--r-- 1 me me 1,8G aoû 25 00:00 JO_2004-08-24-23:00.avi
-rw-r--r-- 1 me me 4,6G aoû 25 02:00 JO_2004-08-25-00:00.avi
-rw-r--r-- 1 me me 3,8G aoû 25 03:29 JO_2004-08-25-02:00.avi
C'est qu'un exemple...
Sinon ext3 supporte aussi htree. Il faut faire :
tune2fs -O dir_index /dev/...
e2fsck -f -D /dev/...
Je veux bien admettre qu'ext3 n'est pas la F1 des FS, mais ce n'est pas une 2CV.
De plus il a presque toutes les fonctionnalités et en rock solide. Il ne manque que le resize à chaud et c'est actuellement en phase de debug (dans FC2 et ça marche :-)).-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 07:40. (lien). Évalué à 2."De plus il a presque toutes les fonctionnalités et en rock solide. Il ne manque que le resize à chaud et c'est actuellement en phase de debug (dans FC2 et ça marche :-))."
Mwai, il n'empeche que ext3 n'a rien d'un fs moderne, il a pour base ext2 et c'est ca qui craint le plus. Il y'avait eu un tres bon article dans Linux Mag y'a deux ans(me semble) sur le sujet qui expliquait les caracteristiques de tous les FS.
Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2. Bon, je sais, comme tu l'as dit, y'a pas que ca, redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.-
[^]Re: Conseils ?
Posté par Romuald Delavergne () le 25/08/2004 à 08:08. (lien). Évalué à 9."Mwai, il n'empeche que ext3 n'a rien d'un fs moderne, il a pour base ext2 et c'est ca qui craint le plus.
Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé. Regarde les changelogs et tu comprendras. Et je trouve bien qu'on se base sur un système de fichiers robuste afin d'hériter de la caractéristique primordiale. C'est vrai qu'Ext3 a eu et a encore quelques désavantages par rapport aux autres dû à l'heritage d'ext2 (acl, taille maximum...) mais peu à peu il les comble. Et je trouve ça plutôt sain comme mode de développement.
Sur le papier reiserfs 4 est peut-être le meilleur. Maintenant faut voir en pratique parce que on a eu le même discours avec la version 3 et pour être reparti de zéro faut croire qu'il était pas si bien que ça.-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 08:50. (lien). Évalué à 3."Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé."
Oui, mais un fs vieux avec de vieux concepts dedans, pour resumer l'article de linux mag. En clair, XFS, reiserfs et autres utilisent des algos bien plus perfectionnés que ce que l'on trouve dans ext2.
"et pour être reparti de zéro faut croire qu'il était pas si bien que ça. "
Rien à voir, c'est pas parce que ils ont innovés que l'ancienne version etait mauvaise.-
[^]Re: Conseils ?
Posté par Christophe Lucas (page perso, ) le 25/08/2004 à 09:56. (lien). Évalué à 8."Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé."
Oui, mais un fs vieux avec de vieux concepts dedans, pour resumer l'article de linux mag. En clair, XFS, reiserfs et autres utilisent des algos bien plus perfectionnés que ce que l'on trouve dans ext2.
Et pour toi cela suffit à dire qu'un système de fichier craint ???
Pour moi, un SGF qui craint est un système de fichier peu fiable, peu performant... Dis tu que ext3 est ainsi ?
Pour ma part j'ai eu quelques coupure violentes et je n'ai jamais eu aucun problème. Je touche de la peau de singe (oups c'est ma tête).
Tu sembles dire que Redhat et Mandrake restent sur ext3 et que cela est dommage. Néanmoins, je pense que leur équipe de développement et des gens comme Alan Cox sont largement compétents pour prendre telle descision :-)
"et pour être reparti de zéro faut croire qu'il était pas si bien que ça. "
Rien à voir, c'est pas parce que ils ont innovés que l'ancienne version etait mauvaise.
Alors là je suis totalement d'accord avec toi. Ils ont eu d'autres idées et ont essayer d'évoluer et progresse voilà tout.
Christophe--
- Christophe --
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 16:12. (lien). Évalué à 2."Et pour toi cela suffit à dire qu'un système de fichier craint ???"
Ext3 est montrer comme un fs moderne et ce n'est pas le cas, comme le disait l'article de LinuxMag, c'est un fs de transition pour ext2. Mais sur une machine neuve, mieux vaut passer à quelques chose de mieux pensé. J'ai pas dit ext3 craint, j'ai dit ext2 craint. Je suis sur que la partie journalisation de ext3 est de bonne qualité mais le fs dessous(ext2) lui est tres basique. C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;)
"Tu sembles dire que Redhat et Mandrake restent sur ext3 et que cela est dommage. Néanmoins, je pense que leur équipe de développement et des gens comme Alan Cox sont largement compétents pour prendre telle descision :-)"
Deja, tu enleves Mandrake vu que leur politique est de faire comme RedHat :) Il y'a plein de truc suxorisant dans la Mandrake qui sont la paske c'est comme ca chez RedHat: le rc.sysinit par exemple. Je sais je me repete, mais bon, quand on compare un init Debian/Suse(similaire) à un init RedHat/Mandrake, y'a d'un coté la modularité et de l'autre la rigidité. Et franchement, je crois que leurs equipes de devel(de rh et mdk) sont capables d'ecrire un truc un peu mieux pensé que ce script qui ressemble au premier programme C d'un edudiant d'IUT premiere année.
Donc dire RedHat l'a choisit donc c'est une bonne solution, ca me fait sourire ;)-
[^]Re: Conseils ?
Posté par gnujsa () le 25/08/2004 à 16:38. (lien). Évalué à 5.« C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;) »
Hormis l'effet dévalorisant que tu semble chercher à produire en comparant fat et ext2, j'ai l'impression, sans être un spécialiste, que fat et ntfs sont beaucoups plus éloigné l'un de l'autre que ext2 et ext3/reseirfs/xfs, ...
Déjà rien que le fait que ext2, ntfs, reseirfs sont multiutilisateur et pas fat.
gnumdk:
« [...]Il y'a plein de truc suxorisant dans la Mandrake[...] »
On renie son premier amour ? ;-)-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 16:55. (lien). Évalué à 2."On renie son premier amour ? ;-) "
Non, je dis ce que je pense ;)
Apres, et ce n'est que mon avis personnel, je me trompe peut etre, je pense que cette volonté de MandrakeSoft de rester proche de RedHat est surement la pour s'assuré une meilleur compatiblité avec les solutions proprios utilisées en entreprise: Oracle, ... et certifié RedHat. En effet, si Mandrake prend le large par rapport a RedHat, il risque d'etre plus difficile de faire fonctionner ce genre de soft sur une Mandrake.
Mais sur d'autre points, Mandrake a su se remettre en question: la modularité des packages par exemple qui se rapproche(sans etre aussi modulaire) de ce que l'on a chez Debian.
C'est marrant cette facon que les gens ont de croire qu'une critique n'a lieu que pour descendre ce que l'on utilise pas ;).
La distrib que j'utilise actuellement a une facon tres bizarre de packager :) On a du kdebase3, du kdelibs3 à la redhat mais on a du koffice-wordprocessor à la Debian. J'ai toujours pas compris la logique du truc mais bon :)
-
-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 16:55. (lien). Évalué à 3.> RedHat: le rc.sysinit par exemple.
Juste pour information, le "monolitique" rc.sysinit fait 861 lignes sur FC2...
Y en a qui préfère 10 x 86 lignes mais c'est une affaire de gout.
Ça n'empêche pas d'avoir plein de fichiers dans /etc/rc.d/init.d/.
Sur FC2 avec tous les paquets, il y a 121 fichiers dans /etc/rc.d/init.d/ !
Enfin, rien ne t'empêche d'ajouter des tas d'include dans /etc/rc.d/rc.local .
> ce script qui ressemble au premier programme C d'un edudiant d'IUT premiere année.
Tu devrais plonger ton nez dedans avant d'avancer ça.-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 17:04. (lien). Évalué à 3."Ça n'empêche pas d'avoir plein de fichiers dans /etc/rc.d/init.d/."
Oui, mais ca empeche de virer des choses lors de l'init autrement qu'a grand coup de vim ;)
sous Debian,
update-rc.d -f bootmisc.sh remove
sous RH/Mandrake
vim /etc/rc.sysinit à la recherche du truc.
"Tu devrais plonger ton nez dedans avant d'avancer ça."
Vu qu'il est tres similaire à celui de la Mandrake et que je connais celui de la Mandrake(on va dire juska la 9.2) tres bien. Je pense pas avoir besoin de le faire.
Il faut voir que ce script fait tout et n'importe quoi: hdparm, hostname, ...
Sous une Suse par exemple, la modularité est tres bonne:
gnumdk@linux:/etc/init.d> ls boot.[!d]*
boot.clock boot.klog boot.md boot.scsidev
boot.crypto boot.ldconfig boot.proc boot.shm
boot.evms boot.loadmodules boot.restore_permissions boot.swap
boot.idedma boot.local boot.rootfsck boot.sysctl
boot.ipconfig boot.localfs boot.sched boot.udev
boot.isapnp boot.localnet boot.scpm
Et quand j'etais etudiant en IUT, j'ai commencé la programmation en mettant tout dans le meme fichier. Mes profs m'ont vite fait comprendre que ce n'est pas la bonne méthode.-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 17:20. (lien). Évalué à 1.> vim /etc/rc.sysinit à la recherche du truc.
Là tu n'y es pas :-)
Désolé.
La seul optimisation que tu peux trouver à éditer rc.sysinit est en vitesse de boot. Rien d'autre. rc.sysinit ne lance pas de processus résidents etc (sauf cas exceptionnel).
De plus, s'il est possible de déplacer une partie de rc.sysinit dans /etc/init.d sans perte de fonctionnalité, ça sera fait. Mais, par exemple, déplacer l'init de usb dans /etc/init.d est une mauvaise idée (comment faire un fsck par exemple). Idem pour raid.
Afin, RedHat/Fedora est une distribution qui "just works" (enfin, ils essaient :-)).
Donc rc.sysinit doit toujours initialiser tout les périphériques de façon minimum (usb, raid, etc). Sinon ça veut dire que lorsque tu ajoutes une partition (récupérée d'une autre machine), la partition ne sera pas vue s'il n'y a pas le paquet (ou autre) sysinit_usb ou firewire ou...
Juste par curiosité, pourquoi tu veux éditer /etc/rc.d/rc.sysinit à part pour avoir un boot très très légèrement plus rapide.
-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 17:29. (lien). Évalué à 2.> Et quand j'etais etudiant en IUT, j'ai commencé la programmation en mettant tout dans le meme fichier. Mes profs m'ont vite fait comprendre que ce n'est pas la bonne méthode.
Gros ou petit fichier, ce n'est pas le point ici.
Red Hat veux que tout soit initialisé au niveau hard.
Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées.
Tu peux critiquer cette politique si tu veux.
Si redhat fait :
include boot.usb
include boot.udev
etc
et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier.
Par contre, pour les services, Red Hat veut laisser plus de souplesse et là il y a plusieurs fichiers.
Mais faire plusieurs fichiers au-lieu d'un gros, sans un réelle objectif de modularité, n'a aucun intérêt. C'est le cas pour le rc.sysinit de RedHat :-) et donc c'est fort logiciquement qu'il n'y a qu'un seul fichier.-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 18:04. (lien). Évalué à 2."De plus, s'il est possible de déplacer une partie de rc.sysinit dans /etc/init.d sans perte de fonctionnalité, ça sera fait. Mais, par exemple, déplacer l'init de usb dans /etc/init.d est une mauvaise idée (comment faire un fsck par exemple). Idem pour raid."
Tu n'as pas compris, c'est pas parce que les fichier sont dans init.d que ca se lance comme les autres services. Comme sous Debian, c'est un autre fonctionnement. Et il n'y pas de perte de fonctionnalité.
Apres, le fait de pouvoir virer quelques parties permet sur de tres vieille babasse de gagner un temps precieux au boot ;) Surtout pour le pc de saisie de note de la secretaire qui trouve deja mozilla long a se lancer, alors si en plus le boot est long... :)
Mais la n'est pas mon argument principal, il s'agit d'abord d'un probleme de clarté. Suse n'offre aucun outils autre que rm pour virer les liens de boot.* dans /etc/init.d/boot.d (sous debian /etc/rcS.d).
Debian offre cette possibilité via la commande update-rc.d.
"et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier."
Si, la clarté. Si je te code un prog avec une fonction de 800 lignes dans un fichier et un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)
Et ton argument : " Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées." est vraiment moisi! Le mec qui s'interresse au boot de la redhat, c'est qu'il en a besoin et qu'il sait ce qu'il fait ;)-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 18:31. (lien). Évalué à 2.Je ne dis pas que Debian à tord.
J'essaie, mais je n'y arrive pas, d'expliquer pourquoi Red Hat fait comme ça.
Pour un usage classique (je ne parle pas d'embarqué qui de toute manière a des scripts spécifiques, ou de la secrétaire qui boot son PC i486 à 33Mhz 10 fois par jours).
> Si, la clarté
Pour un script de 860 lignes dont le niveau maxi d'indentation est de 5 !
Fichtre.
> un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)
C'est vraiment pas évident.
Le "Red Hat touch" :
fichier init :
# init usb
(...)
# init ide
(...)
Le "Debian touch" :
fichier init :
call init_usb
call init_ide
(...)
fichier init_usb :
(...)
fichier init_ide :
(...)
Avec le "Red Hat touch", c'est évident. Tout est excécuté dans un ordre, une fois et c'est tout.
Avec le "Debian touch", si je regarde le fichier init_usb, je ne sais pas s'il doit être appelé avant ou après init_ide, je ne sais pas s'il peut être appelé plusieurs fois, etc...
Si un programme n'est pas modulaire (comme le rc.sysinit de RedHat) il est inutile de faire croire qu'il est (surtout pour 800 lignes).-
[^]Re: Conseils ?
Posté par gnujsa () le 25/08/2004 à 19:06. (lien). Évalué à 3.L'init Debian, c'est l'init System V
Un petit aperçu ici:
http://www.debian.org/doc/manuals/reference/ch-system.fr.html#s-ini(...)
« Avec le "Debian touch", si je regarde le fichier init_usb, je ne sais pas s'il doit être appelé avant ou après init_ide, je ne sais pas s'il peut être appelé plusieurs fois, etc... »
ex:
/etc/rcS.d/S26lvm -> ../init.d/lvm
/etc/rcS.d/S35mountall.sh -> ../init.d/mountall.sh
D'aprés le nom des liens symboliques : S pour Start. Le script lvm démarre en 26ième position alors que mountall.sh démarre en 35 ième position.-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 19:52. (lien). Évalué à 2.> D'aprés le nom des liens symboliques
J'image bien que ce n'est pas fait au hazard...
Mais la compréhension est moins "fulgurante" qu'avec un "bête" rc.sysinit.
Ceci dit, je m'en fous :-)
rc.sysinit (tel qu'il est fait par Red Hat) ou /etc/rcS.d/ ne change rien ou presque.
Par contre, j'apprécie d'avoir /etc/httpd/conf.d/ ou /etc/ld.so.conf.d/ etc.
Ça évite d'éditer /etc/httpd/conf/httpd.conf etc. Mais /etc/rc.d/rc.sysinit n'est _jamais_ édité (par les scripts d'installation de rpm par exemple).-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 20:34. (lien). Évalué à 2."Mais /etc/rc.d/rc.sysinit n'est _jamais_ édité (par les scripts d'installation de rpm par exemple). "
Oui, mais il peut etre mis a jour dans une update.
Et si tu le modifie pour ajouter des truc, tu te retrouves a devoir mergé la correction du bug dans ton script vu que rpm a crée un .rpmnew.-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 20:54. (lien). Évalué à 2.C'est pour ça qu'il y a rc.local.
rc.local est vide à l'origine.
Oops, c'est faux, il y "touch /var/lock/subsys/local" :-)
Il y aura peut-être un .rpmnew pour rc.local mais tu peux l'ignorer (sûrement une mise à jour du commentaire dans le fichier). À moins que "touch /var/lock/subsys/local" soit buggé ou présente un trou de sécurité :-)
Et tu peux toujours faire un script dans /etc/rc.d/init.d/ (ala Debian).
Tu trouveras toujours un cas où il faut modifier rc.sysinit. Mais franchement, regardes les forums d'aide ou les mailings et tu verras qu'on ne propose pratiquement jamais de modifier rc.sysinit.
Et si c'était le cas, Red Hat utiliserait un système type Debian.
Ils ne sont pas cons :-)
-
-
-
-
-
-
-
-
-
[^]Re: Conseils ?
Posté par Christophe Lucas (page perso, ) le 26/08/2004 à 06:59. (lien). Évalué à 0.
Ext3 est montrer comme un fs moderne et ce n'est pas le cas, comme le disait l'article de LinuxMag, c'est un fs de transition pour ext2. Mais sur une machine neuve, mieux vaut passer à quelques chose de mieux pensé.
Est-ce que ReiserFS est-il bien plus performant et plus fiable qu'Ext3 ?????????????
Si cela m'est démontré alors, j'admettrais que mon point de vue est caduque. Néanmoins, jusqu'à là c'est le choix de certains d'utiliser ext3.
De plus, la réponse à ma question ne semble pas encore bien claire...
Alors l'argument, c'est plus moderne, c'est mieux pensé, me fait franchement sourire... On dirait : "oh il me manque le dernier schmurff en vogue sur ma machine !!". Alors en effet, c'est peut-être la dernière feature à la mode, mais pour l'instant il ne semble pas que tout ce qui semble vitale aux entreprises est dans ReiserFS !
J'ai pas dit ext3 craint, j'ai dit ext2 craint. Je suis sur que la partie journalisation de ext3 est de bonne qualité mais le fs dessous(ext2) lui est tres basique. C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;)
J'en conclu que ext3 ne craint pas ;-)
Deja, tu enleves Mandrake vu que leur politique est de faire comme RedHat :) Il y'a plein de truc suxorisant dans la Mandrake qui sont la paske c'est comme ca chez RedHat: le rc.sysinit par exemple. Je sais je me repete ...au premier programme C d'un edudiant d'IUT premiere année.
Donc dire RedHat l'a choisit donc c'est une bonne solution, ca me fait sourire ;)
Ai-je dis cela ? J'ai dis que c'était _leur_ décision et qu'ils étaient compétents pour choisir si tel ou tel système de fichier correspond à leur attente.
Douterais-tu de leur compétence ? Es-tu meilleur que ces équipes de dev ? Tes arguments semblent convaincants, contactes RH (et MDK)...
Bonne journée.
Christophe--
- Christophe --
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 26/08/2004 à 19:38. (lien). Évalué à 3."Si cela m'est démontré alors, j'admettrais que mon point de vue est caduque. "
GNU/Hurd a de moins bonnes perfs que GNU/Linux, pourtant GNU/Hurd est meilleur techniquement! Donc oui, ton point de vue est caduque ;) Et si tu regarde n'importe quel bench comparant XFS, reiserfs et ext3, XFS et Reiserfs seront tjs devant(avec des nuance entre les deux suivant le bench) et ext3 derriere. Par contre, ext2 lui est plus performant que tout les autres :) Mais rajouter la journalisation à quelque chose qui n'a pas été concu pour, ca donne pas de meilleurs perfs et en principe, il vaut mieux tout recommencer. Et de toute facon, ext3 est la pour la compatibilité, et pour cela c'est tres bien qu'il soit la!
"Douterais-tu de leur compétence ? Es-tu meilleur que ces équipes de dev ? Tes arguments semblent convaincants, contactes RH (et MDK)..."
Moi meilleur? mouahahah :) non :)
Mais bon, d'apres ce que j'ai compris(meme si je n'aime pas le rc.sysinit de RedHat), c'est plus problematique chez Mandrake qui met tout est n'importe quoi dans ce script(qui a depassé les 1000 lignes depuis un moment :) Ensuite, j'ai prevenu MandrakeSoft, si tu regardes la ml cooker, tu veras deux mail de moi sur le sujet à 6 mois d'intervalle(j'aim bien insister) mais bon, si ils veulent pas, je peux pas les forcer ;)
-
-
-
-
-
[^]Re: Conseils ?
Posté par tgl () le 25/08/2004 à 08:53. (lien). Évalué à 5.> Maintenant faut voir en pratique parce que on a eu le même
> discours avec la version 3 et pour être reparti de zéro faut
> croire qu'il était pas si bien que ça.
Mmmh... les objectifs de Reseir4 sont complètement différents, et il y a eu pour Reseir4 un paquet d'idées nouvelles, donc ça n'aurait pas eu grand sens de partir sur la base de ReseirFS 3. Mais ça ne prouve en rien que ReseirFS 3 était un échec ; qu'une boîte se lance dans un nouveau projet n'indique pas systématiquement qu'elle juge les pré précédents bons pour la poubelle.
-
-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 11:17. (lien). Évalué à 10.> Mwai, il n'empeche que ext3 n'a rien d'un fs moderne
???
On peut dire qu'Unix n'a rien d'un OS moderne si on commence avec ce type d'argument.
ext3 a toutes les fonctionnalités ou presque.
lvm => ça marche
acl => ça marche
selinux => ça marche
cluster type gfs => ça marche
fiabilité => excellente
Il lui manque ces petits trucs (mais techniquement difficile à réaliser) qui permet de gagner 2 à 3 % en perfo en usage typique et à fiabilité équivalente. Le problème des benchs est qu'ils sont rarement fait à niveau de fiabilité équivalent. Ils sont concentrés sur les performances.
> Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2.
Red Hat a largement démontré qu'ils n'hésite pas à ignorer la compatibilité si ça va dans le bon sens.
Red Hat est dédié serveur et leurs utilisateurs sont plus proches des administrateurs que des hobbystes.
La compatibilité c'est bien, mais s'il faut casser la compatibilité pour avoir meilleur, il le feront.
> redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.
Pas que ça. RedHat a aussi une floppée de tests (fiabilité, tenue en charge, fonctionnalité, etc) et ext3 les passes tous ce qui n'est pas le cas de reiserfs. Parole d'Alan Cox. NB : vrai pour Linux 2.4, j'ai pas d'info pour Linux 2.6.
Si Reiserfs4 est techniquement excellent (et aussi dans la pratique :-)), complet (un fsck qui roxor aussi), performant, fiable, etc, ajoutes 6/12 mois pour que le tout soit rock solide et Red Hat utilisera reiserfs.
Puis il faut arrêter de pointer Red Hat comme un méchant qui ne veut pas utiliser reiserfs. ext3 est aussi le fs le plus utilisé par les développeurs Linux.
En gros, Red Hat fait comme la majorité des développeurs.
J'ai lu beaucoup de bien de reiserfs v4. Si c'est pas du pipo publicitaire (comme reiserfs v3), ou pour draguer les filles en discothèque, reiserfs v4 passera devant ext3 (toutes distributions confondues).
Que je sache, Linux est un logiciel libre et ce sont les meilleurs solutions qui s'imposent. Les préférences de Red Hat ne change rien à ça (au moins à long terme).
SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs.-
[^]Re: Conseils ?
Posté par Richard Van Den Boom () le 25/08/2004 à 15:29. (lien). Évalué à 3.EXT2/3 a une limitation pesante dans certaines situations comparé aux autres FS standards de Linux, c'est sa gestion antédiluvienne, pour le coup, des inodes. Devoir encore formatter de manière particulière sa partition pour avoir un nombre fixe d'inodes est une restriction qui commence à se faire pesante quand tu dois travailler dans un environnement avec des arborescences profondes et un grand nombre de fichiers.
C'est probablement la seule vraie limitation que je lui vois, mais elle va de pair avec sa relative lenteur sur de répertoires avec beaucoup de petits fichiers. Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.
En ce qui me concerne, je trouve Ext3 bien mais ReiserFS3 mieux, donc j'utilise Reiser. Donc j'évite Red Hat (mais ça j'aurais évité de toutes les façons).
Richard-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 16:00. (lien). Évalué à 4.> Devoir encore formatter de manière particulière sa partition pour avoir un nombre fixe d'inodes est une restriction qui commence à se faire pesante
Ouais. Mais c'est rare les gens qui sont limités par la valeur par défaut lors du formatage.
En gros, une partition de 20 Go donne 2 500 000 inode !
J'ai jamais vu sur un forum quelqu'un demander à augmenter le nombre d'inode d'une partion ext3...
> quand tu dois travailler dans un environnement avec des arborescences profondes et un grand nombre de fichiers.
man tune2fs :
- dir_index
Use hashed b-trees to speed up lookups in large
directories.
sparse_super
Limit the number of backup superblocks to save space
on large filesystems.
sparse_super évite d'avoir 40 superblocks à mettre à jour. La profondeur ne change rien puisque le répertoire est repéré par l'inode.
man e2fsck :
- -D
Optimize directories in filesystem. This option causes e2fsck
to try to optimize all directories, either by reindexing them if
the filesystem supports directory indexing, or by sorting and
compressing directories for smaller directories, or for filesys-
tems using traditional linear directories.
> Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.
Où tu as vu ça ?
Exemple avec une partition de 120 Go :
# cat /proc/partitions
major minor #blocks name
9 0 120372992 md0
# df /dev/md0
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md0 120111456 70477292 49634164 59% /
# bc
(120372992-120111456)/120372992*100
.21727132
261536 blocks de 1k pour le FS uniquement.
Un peu plus de 0,2 % de blocs de 1K utilisé pour la gestion d'ext3. Imaginons qu'au pire de l'utilisation je monte à 0,5 % (faut beaucoup d'imagination...).
man mke2fs :
- size=journal-size
Create an internal journal (i.e., stored inside the
filesystem) of size journal-size megabytes. The
size of the journal must be at least 1024 filesystem
blocks (i.e., 1MB if using 1k blocks, 4MB if using
4k blocks, etc.) and may be no more than 102,400
filesystem blocks.
On est très très loin de tes 10 %.
Tu ne confond pas avec les "Reserved blocks" qui est configurable avec "tune2fs|mke2fs -m" ? Pour les "Reserved blocks", c'est 10 % par défaut.
Utilises "tune2fs|mke2fs -m 0 /dev/partition".-
[^]Re: Conseils ?
Posté par Richard Van Den Boom () le 29/08/2004 à 17:27. (lien). Évalué à 2.Sur mon bête poste de travail, je suis déjà à 630000 inodes utilisés. Je parlais bien de certaines situations : je fais de la sauvegarde et je suis régulièrement confronté à des clients qui ont des répertoires avec des millions de fichiers temporaires sur leurs serveurs. C'est typiquement le cas où cela pose un problème.
D'autre part, c'est très bien de pouvoir tuner EXT3 pour certains usages spécifiques mais j'imagine que du coup, ils sont moins efficaces sur d'autres usages. Tant qu'à faire je préfère le système de fichiers qui me fournit tous ces avantages sans inconvénients par défaut.
Pour la taille du journal, je n'avais qu'une petite partition comme référence, donc effectivement, c'est un mauvais argument.
Richard-
[^]Re: Conseils ?
Posté par 007 () le 30/08/2004 à 01:55. (lien). Évalué à 1.> Je parlais bien de certaines situations : je fais de la sauvegarde et je suis régulièrement confronté à des clients qui ont des répertoires avec des millions de fichiers temporaires sur leurs serveurs.
Temporaires ?!?
Il y a un problème alors.
M'enfin, en gros avec les paramètres par défaut, il y a 1 inodes pour 2 à 3 blocks.
Le maxi est 1 inodes par block (pour reiserfs ça doit aussi être le cas).
Bref, il faut vraiment en vouloir pour atteindre la limite de la valeur par défaut.
Je ne dis pas que ça n'arrive pas. Mais ça doit être rare.
Rendre la taille de la table des inodes dynamique est dans la TODO list. Ça passera peut-être par par un "umount ... ; tune2fs ... ; e2fsck (peut-être) ; mount".
Pas de délais annoncé.
-
-
-
-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 16:16. (lien). Évalué à 4."On peut dire qu'Unix n'a rien d'un OS moderne si on commence avec ce type d'argument."
Oui, c'est le cas ;) Ca m'empeche pas de l'utiliser mais je sais tres bien que Unix est loin d'etre parfait. Mais moi au moins je l'avoue :p
"SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs. "
Je parle de Mandrake parce que... Ben c'est expliqué deux commantaires plus haut ;) Mandrake a peur de s'eloigner de RedHat. C'est l'argument choc que l'on m'a sortie quand j'ai proposé aux devels de chez mdk de repenser leur init afin d'avoir quelque chose de plus modulaire.-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 17:02. (lien). Évalué à 2.> Mandrake a peur de s'eloigner de RedHat. C'est l'argument choc que l'on m'a sortie
Pour reiserfs, il y a de grosses différences entre RedHat et Mandrake :
- RedHat/Fedora ne propose pas de façon claire reiserfs. Il faut savoir qu'il faut taper "linux reiserfs" à l'invite de l'installation sinon reiserfs n'est pas proposé (idem pour jfs, xfs, etc).
- reiserfs n'est pas supporté par RHEL. Si t'es emmerdé par reiserfs, inutile d'appeler le support RH.
- RedHat (moins pour Fedora) ne fait pas l'effort de patché leur noyau avec les derniers bugfix de reiserfs. Il y a que ext3 qui est "soigné".
T'es un injuste sur ce coup avec Mandrake.-
[^]Re: Conseils ?
Posté par gnumdk (page perso, ) le 25/08/2004 à 17:16. (lien). Évalué à 2.Oui, mais la c'est cosmetique, le choix par defaut de Mandrake, c'est ext3.
"Si Reiserfs4 est techniquement excellent (et aussi dans la pratique :-)), complet (un fsck qui roxor aussi), performant, fiable, etc, ajoutes 6/12 mois pour que le tout soit rock solide et Red Hat utilisera reiserfs."
Désolé pour ce croisement de commentaire, c'est mal :)
Mais, XFS est la depuis longtemps, stable et a fait ses preuves chez SGI. Depuis le 2.6.0, il est officiellement dans le noyau et pourtant la fedora ne l'utilise pas par defaut. Pourquoi? :)
Et vu que tu as l'air de croire que je suis un grand fan de reiserfs, c'est pas du tout le cas, mon fs favoris, c'est XFS ;)-
[^]Re: Conseils ?
Posté par itstimetogo () le 25/08/2004 à 17:48. (lien). Évalué à 3.> Depuis le 2.6.0, il est officiellement dans le noyau et pourtant la fedora ne l'utilise pas par defaut. Pourquoi? :)
C'est une bonne question.
Déjà, XFS est moins fiable. Je ne dis pas qu'il est codé avec les pieds mais il n'a pas le mode data=ordered d'ext3.
Voir aussi :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
- 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). XFS never got corrupted to the point it wouldn't boot, but with approximately 100 power cycles on each drive, one drive had 73 corrupted lines and the other had 82. With JFS after 15 power cycles one of the drives was corrupted and the system would no longer boot up (fsck failed again).
Enfin, et ce point est important bien que souvent ignoré, Red Hat a des compétences en ext3.
S'il y a des problèmes avec xfs, RedHat n'a pas forcément les compétences en interne pour corriger ou expertiser rapidement le problème.
Si tu veux du reiserfs, prend du SuSE, ils ont les compétence. Pour ext3, regardes du côté de Red Hat. Pour XFS, install Irix :-)
Un distributeur ne peut pas avoir des compétences sur tous les FS. Surtout qu'avec toutes les combinaisons (FS/lvm/raid/acl/nfs/GFS) ça devient très très vite l'enfer pour tout tester si tu supports tous les FS (ext3, xfs, jfs, reiser3, reiser4, etc).
> mon fs favoris, c'est XFS ;)
Le mien, ext3. Principalement car il est fiable, il me suffit, il est en standard avec ma distrib (Je n'ai pas à récupérer de patch, etc) et j'ai pas envie de me prendre la tête pour gagne 0,2 % en perfo ou place disque.
Je suis fainéant et j'ai jamais pris le temps de tester les différents FS dispos sous Linux.
-
-
-
[^]Re: Conseils ?
Posté par Cook Captain () le 25/08/2004 à 20:58. (lien). Évalué à 3.Je crois que tu confonds modernité et efficacité. Une technologie peut être ancienne et parfaitement efficace et évoluer avec le temps.
Le cas d'Unix me semble justement un trés bon exemple. Des bonnes fondations ont permis au système de s'améliorer au fil des années et ce sans renier son passé. Certains OS supposés plus modernes que Linux/Unix ne parviennent pas forcément à le supasser dans biens de domaines. Unix n'est certes toujours pas parfait, mais à ma connaissance aucun OS ne l'est (fort heureusement!).
En ce qui concerne les systèmes de fichiers, les benchs de tests ne sont que très peu révélateurs de l'efficacité réelle du FS. La fiabilité me semble absolument primordiale. Malheureusement cette donnée n'est pratiquement jamais testée. Dans ce domaine, ReiserFS 3 avait peu convaincu (d'ou à mon avis son manque de succès), J'espère que la version 4 sera plus performante de ce coté. Rdv dans 1 an...-
[^]Re: Conseils ?
Posté par 007 () le 25/08/2004 à 21:36. (lien). Évalué à 1.Moderne ce dit de quelque chose utilisé actuellement.
Une fourchette est moderne.
MS-DOS n'est pas moderne.
Unix est moderne depuis 30 ans :-)-
[^]Re: Conseils ?
Posté par Mr F (page perso, ) le 26/08/2004 à 09:28. (lien). Évalué à 2.Absolument pas.
Moderne se dit d'une chose utilisé depuis peu, et se dit aussi d'une chose utilisant des concepts novateur.
Une fourchette n'est pas moderne.
La base d'Unix n'est pas moderne, mais le kernel 2.6 par exemple est moderne.
etc...
Maintenant, comme tu le dit si bien, il existe des choses que l'on ne peut qualifié de moderne (une fourchette) qui n'ont pourtant pas trouvé de meilleur remplaçant...
Comme quoi la modernité et l'efficacité sont deux concepts distincts.-
[^]Re: Conseils ?
Posté par 007 () le 26/08/2004 à 10:01. (lien). Évalué à 2.> Moderne se dit d'une chose utilisé depuis peu
La voiture et le metro ne sont pas des modes de transport modernes ?
http://colet.uchicago.edu/cgi-bin/dico1look.pl?strippedhw=MODERNE(...)
La dernière définition de Académie française :
Qui est soit de notre temps, soit d'un temps plus ou moins rapproché du nôtre, par opposition à Antique, à ancien.
Unix est de notre temps. MS-DOS non et pourtant il est moins vieux d'Unix.
Linux 2.6 est d'un temps rapproché du nôtre, par opposition à Unix qui est un ancien.
Unix est moderne (de notre temps).
Linux est moderne ET moderne (de notre temps ET non ancien).-
[^]Re: Conseils ?
Posté par Cook Captain () le 27/08/2004 à 08:10. (lien). Évalué à 2.Moderne est un adjectif. Il qualifie une action, une utilisation, un concept, une idée, une technique, etc.
utilisation moderne => utilisé depuis peu
conception moderne => conçu depuis peu
Cela signifie qu'un objet peut être de conception ancienne (donc non moderne) et d'utilisation moderne.
Le 'depuis peu' exprime une durée relative à l'espace de temps dans lequel on se situe.
La création d'Unix est donc ancienne (à l'échelle de l'infomatique). En revanche, de nouvelles techniques sont ajoutées chaque jour a linux. On pourrait donc dire que Linux est un os moderne dont les origines sont anciennes...
Bref tout cela c'est pas simple ....
-
[^]Re: Conseils ?
Posté par Mr F (page perso, ) le 28/08/2004 à 19:32. (lien). Évalué à 2.Le metro est moderne si l'on prend comme total temps toutes la période ou des transports furent utilisé, ce qui commence à la chaise à porteurs, a peu prêt et donc effectivement, par rapport à ceci le metro est moderne. Mais si on prend comme raltif temps les inventions de notre génération, c'est à dire des 10 dernières années en gros, le metro n'est clairement pas moderne.
C'est pareil pour l'informatique, Unix n'est absolument pas plus moderne que MS DOS. La base de Linux n'est pas moderne non plus, car au vu de l'ancienneté de l'informatique domestique, cela fait longtemps qu'il a vu le jour. Mais comme je le disais, certains concepts de Linux sont moderne.
Tu confond de notre temps (de notre époque) à "utilisé encore actuellement", ce qui est totalement différent, la fourchette est bien encore utilisé actuellement...-
[^]Re: Conseils ?
Posté par 007 () le 28/08/2004 à 20:57. (lien). Évalué à 1.????
Unix (n')est (pas) de notre temps.
Unix (n')est (pas) utilisé encore actuellement.
J'y comprend rien.
Il me semble, et j'ai peu de doute sur ça, qu'Unix est de notre temps et est encore utilisé.
Unix se trouve facilement aujourd'hui (OS, articles, etc...). Il est donc de notre temps.
Unix est utilisé.
> Unix n'est absolument pas plus moderne que MS DOS.
Impressionnant.-
[^]Re: Conseils ?
Posté par Mr F (page perso, ) le 29/08/2004 à 17:22. (lien). Évalué à 2.Moderne ne veut pas dire utilisé actuellement et ne pas être moderne ne veut pas dire plus utilisé (exemple, encore, la fourchette).
Enfin bref, nous n'avons pas la même perception des choses et tu essaye de raisonner avec une explication litéraire.
Mais je persiste et signe, et je pense que tu pourrais demander à ton entourage (en leur donnant des dates) pour qu'ils te disent ce qu'ils en pensent, tu es dans l'erreur.-
[^]Re: Conseils ?
Posté par 007 () le 30/08/2004 à 02:26. (lien). Évalué à 1.> tu essaye de raisonner avec une explication litéraire.
Je fais de mon mieux pour parler français et pas la banlieu.
Alors ziva, lâche moi la grappe :-)
Sinon j'ai mon "micro robert" (pas très litéraire...).
Moderne :
1- Actuel, contemporain, récent
2- Qui bénéficie des progrès récents, correspond au goût actuel
3- (personnes) qui tient compte de l'évolution récente dans son domaine
Le 1 et le 2 me conviennent. Le 3 pour les personnes me convient aussi.
Unix tombe en 1 et Linux plutôt en 2.
Tu préfères ne retenir que le 2.
Le français étant une langue vivante, je ne vais pas te le reprocher.-
[^]Re: Conseils ?
Posté par Mr F (page perso, ) le 30/08/2004 à 14:55. (lien). Évalué à 2.Dans le 1 il y a récent et c'est quand même très important. Et justement, si l'on prend Unix, il n'est absolument pas recent, voir même moins que MS DOS par ailleur.
Ensuite, Unix et même Linux n'ont rien de contemporain, un OS contemporain serait Windows ou MacOSX ou Pegasos etc, mais surement pas Unix qui date de la décennie précédente. Et encore une fois, le fait qu'il soit utilisé et qu'il convienne parfaitement à nombre d'utilisation ne veut pas dire qu'il soit moderne.
Le français étant une langue vivante, je ne vais pas te le reprocher.
Justement, c'est pour cela qu'il ne faut pas se baser sur un sens littéraire, le Français bouge et si tu prend un dictionnaire de 1920, tu serais bien surpris de la définition qu'avaient certains mots...
Le débât est sans fin et l'on trouvera des partisants des deux cotés, mais pour moi Unix n'est pas moderne, même si c'est l'OS que je préfére et qui me correspond le mieux.-
[^]Re: Conseils ?
Posté par 007 () le 30/08/2004 à 20:41. (lien). Évalué à 1.> un OS contemporain serait Windows ou MacOSX ou Pegasos etc
Après MS-DOS plus moderne qu'Unix...
btw, Unix a implémenté Internet (ipv4, mail, ftp, uucp, etc) bien avant Windows.
Le modèle ouvert d'Unix (normes) et le modèle open-source de Linux (et pourtant l'idée est vieille...) et beaucoup plus moderne/novateur que le modèle fermé basé sur l'exclusivité et capitaliste de Windows. C'est d'ailleur tellement "moderne" que beaucoup de journalistes et politiciens ne l'ont pas encore intégré.
> Justement, c'est pour cela qu'il ne faut pas se baser sur un sens littéraire
> un dictionnaire de 1920
Pour être honnète, tu m'énerves un peu.
1- Je n'ai pas pris un dico de littérature.
2- Mon "Robert" date de 1997 (c'est vieu mais c'est correct).
3- Toi et/ou ton quartier n'est pas forcément la meilleur référence pour le Français.
Désolé.-
[^]Re: Conseils ?
Posté par Mr F (page perso, ) le 31/08/2004 à 09:53. (lien). Évalué à 2.btw, Unix a implémenté Internet (ipv4, mail, ftp, uucp, etc) bien avant Windows.
Il y a 10 ans voir même 5 ans c'était un OS moderne :-)
Le modèle ouvert d'Unix (normes) et le modèle open-source de Linux (et pourtant l'idée est vieille...) et beaucoup plus moderne/novateur que le modèle fermé basé sur l'exclusivité et capitaliste de Windows. C'est d'ailleur tellement "moderne" que beaucoup de journalistes et politiciens ne l'ont pas encore intégré.
Oui enfin à noter quand même que le modèle n'est pas une invention de l'Open Source :-)
Pour être honnète, tu m'énerves un peu.
1- Je n'ai pas pris un dico de littérature.
2- Mon "Robert" date de 1997 (c'est vieu mais c'est correct).
3- Toi et/ou ton quartier n'est pas forcément la meilleur référence pour le Français.
ça n'émpèche en rien que qualifié Unix d'OS moderne, en 2004, est faux. Mais Unix (ou plutôt Linux) est un OS contenant des concepts modernes. C'est toute la différence :-)
Mais bref, peut importe.-
[^]Re: Conseils ?
Posté par 007 () le 31/08/2004 à 12:09. (lien). Évalué à 1.> Mais bref, peut importe.
Oui. Mais un petit truc. Je ne pense pas que la modernité se mesure sur une ou deux années.
Internet à plus de 20 ans et c'est depuis fin 90 que ça conserne nos "contemporains".
C'est depuis 2 ans environ que beaucoup de foyer français ont Internet.
L'accès à Internet, l'utilisation d'Internet, ses conséquences, etc reste un point chaud et le moins qu'on puisse dire, c'est que ça reste globalement opaque pour le citoyen moyen et pire encore pour les politiciens/journalistes et même pour les spécialistes (qui par exemple n'ont pas vu venir Internet ni Linux et un fois sur deux disent des conneries).
Pour ma part, tout ce qui conserne l'informatique et qui est utilisé actuellement est moderne (même en insistant sur "récent").-
[^]Mur
Posté par Mr F (page perso, ) le 31/08/2004 à 13:40. (lien). Évalué à 2.
Oui. Mais un petit truc. Je ne pense pas que la modernité se mesure sur une ou deux années.
C'est une question de contexte et de relativité. Sur quelque chose comme les transport qui évolue lentement, clairement pas. Sur quelque chose comme l'informatique qui évolue très vite, ta modernité d'il y a deux ans peut être complétement dépassé.
C'est depuis 2 ans environ que beaucoup de foyer français ont Internet.
L'accès à Internet, l'utilisation d'Internet, ses conséquences, etc reste un point chaud et le moins qu'on puisse dire, c'est que ça reste globalement opaque pour le citoyen moyen et pire encore pour les politiciens/journalistes et même pour les spécialistes (qui par exemple n'ont pas vu venir Internet ni Linux et un fois sur deux disent des conneries).
Aucun rapport, on juge une modernité (ou autre) sur un aspect globale de création, pas de démocratisation massive. De toute façon, dès que ça devient démocratisé, c'est moins moderne. Exemple l'Ipod, c'est moderne, mais tout le monde n'en a pas. Le téléphone portable, c'est plus vraiment moderne (ça date) et maintenant tout le monde ou presque en as.
Pour les "spécialistes", ils ont, tout au long de l'histoires, pratiquement jamais rien vu arrivé alors il ne faut pas trop s'en étonner pour le LL.
Pour ma part, tout ce qui conserne l'informatique et qui est utilisé actuellement est moderne (même en insistant sur "récent").
J'ai bien compris ton point de vue et tu reste opaque au miens et à mes arguments :
Etre utilisé actuellement ne veut pas dire être moderne. Exemple un browser n'est pas moderne, le concept est vieux. Par contre le css et le xml sont des concepts modernes. Bien qu'ils commencent à le devenir un peu moins avec le temps...
Bref, encore bref, Unix n'est pas moderne (il date d'au moins 1990) (je n'ai plus de date en tête) et 14 ans, c'est énorme en informatique. Mais, encore une fois, certains concepts de Linux sont modernes.-
[^]Re: Mur
Posté par 007 () le 31/08/2004 à 15:55. (lien). Évalué à 1.> Par contre le css et le xml sont des concepts modernes.
Selon ta définition, non.
C'est SGML en plus simple et SGML date de 15 ou 20 ans (j'ai oublié).
Pour css, la séparation de la présentation et des données est un très vieux concept aussi.
> Unix n'est pas moderne (il date d'au moins 1990)
Rires...
Unix, même époque que le language C. C-à-d fin 60 début 70.
> et 14 ans, c'est énorme en informatique
L'informatique en est encore à ses débuts. Au début de l'aviation ou de l'automobile, 14 ans c'était énorme aussi.
Tu peux aussi affirmer que l'avion n'est pas un mode de transport moderne alors.
> certains concepts de Linux sont modernes.
En fait, très peu. En tout cas pour l'utilisateur final. Si tu sais utiliser Unix tu n'es pas dépaysé sous Linux et vice versa.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.