OpenSuse est (avec Slackware) l'une des seules distributions à utiliser le système de fichier ReiserFS par défaut.
La situation va changer car c'est maintenant ext3 qui sera utilisé.
L'explication : http://linux.wordpress.com/2006/09/27/suse-102-ditching-reis(...)
Résumé des arguments :
Il y a une foultitude de problèmes techniques dans le système de fichier ReiserFS (problème de montée en charge; problème de Big Kernel Lock; problème de gestion des droits étendus de type ACL).
De plus le nombre de devs est très réduit (3 ou 4) et le support pour la v3 est quasi-mort.
Le passage vers la v4 sera difficile du fait qu'aucune transition n'est prévue. Il faudra reformater ce qui est inacceptable pour certains.
De plus la v4 n'est pas encore intégrée dans le noyau Linux standard et sa stabilité est aléatoire.
De l'autre coté Ext3 est supporté par beaucoup de devs car il est standard dans presque toutes les distributions. Sa stabilité est très bonne et les perspectives techniques sont claires avec un plan de transition vers Ext4.
A plus long terme il est envisagé (uniquement pour les serveurs) de basculer sur le système OCFS2 afin de faciliter la clusterisation et la virtualisation. Dans l'intervalle Ext3 est une bonne solution.
La situation va changer car c'est maintenant ext3 qui sera utilisé.
L'explication : http://linux.wordpress.com/2006/09/27/suse-102-ditching-reis(...)
Résumé des arguments :
Il y a une foultitude de problèmes techniques dans le système de fichier ReiserFS (problème de montée en charge; problème de Big Kernel Lock; problème de gestion des droits étendus de type ACL).
De plus le nombre de devs est très réduit (3 ou 4) et le support pour la v3 est quasi-mort.
Le passage vers la v4 sera difficile du fait qu'aucune transition n'est prévue. Il faudra reformater ce qui est inacceptable pour certains.
De plus la v4 n'est pas encore intégrée dans le noyau Linux standard et sa stabilité est aléatoire.
De l'autre coté Ext3 est supporté par beaucoup de devs car il est standard dans presque toutes les distributions. Sa stabilité est très bonne et les perspectives techniques sont claires avec un plan de transition vers Ext4.
A plus long terme il est envisagé (uniquement pour les serveurs) de basculer sur le système OCFS2 afin de faciliter la clusterisation et la virtualisation. Dans l'intervalle Ext3 est une bonne solution.
> Lire le journal (39 commentaires, moyenne: 2,5).
Vous avez demandé le commentaire #763179.
Run by 
Cette page a été générée par Templeet en 0.083s (dont 0.0077 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Et Slack ?
Il restait Slackware sur ReiserFS d'après mes souvenirs. Je ne sais pas si c'est toujours le cas sur la version qui se fait attendre (la 11), mais c'était toujours le cas sur la 10.1).
[^]Re: Et Slack ?
étant donné le conservatisme de Volkerding je pense que ReiserFS va rester dans Slackware. après tout le kernel en est encore au 2.4 par défaut !!!!!
Le 2.6 est sorti depuis quoi ? Trois ans ?
[+] [^]Re: Et Slack ?
après tout le kernel en est encore au 2.4 par défaut !!!!!
Et alors? Quand la dernière version top-moumoute du noyal est sorti on doit l'adopter sinon on est has been?
Moi je serais toi, je ferais une pétition pour supprimer toutes les versions antérieures au 2.6 des mirroirs de kernel.org !
[^]Re: Et Slack ?
Il n'est pas question d'être has been ou autre c'est juste que pour faire fonctionner Linux sur du matos récent il faut un noyau 2.6.
Pas besoin de caricaturer mon post.
[^]Re: Et Slack ?
Sans compter que technologiquement parlant un 2.6 récent est à des années lumières d'un 2.4. (j'exagère un peu :p )
[^]Re: Et Slack ?
C'est l'hopital qui se fout de la charité.
Tu traites Slackware de "conservateur" parce qu'il utilise toujours un noyau 2.4 (par défaut, bien qu'un 2.6 soit présent depuis ces mêmes 3 ans), alors qu'il intégre des logiciels plus qu'à jour, tu mets un tas de "!!!!!" en faisant de l'ironie et tu trouves que je caricature?
Maintenant, pour ton matos récent qui ne fonctionne pas avec le 2.4, ce qui ne doit pas représenter la plus grande part des utilisateurs de Slackware, le 2.6 est fourni dans les extra/ ou dans testing/.
Patrick a cru bon d'attendre la stabilisation du noyau 2.6 pour l'intégrer par défaut dans Slackware, au vu des déboires qu'on a connu jusqu'à de très récentes versions, je doute que qui que ce soit puisse lui en vouloir.
[^]Re: Et Slack ?
A la lecture des packages de la version 11, tu vois clairement une philosophie conservatrice sur les logiciels composant le système et relativement bleeding-edge du point de vue des applications utilisateurs (j'ai schématisé).
Par exemple, tu retrouves :
- glibc 2.3.6
- X11R6.9.0
- gcc-3.4.6
- Apache 1.3.37
Et de l'autre côté, KDE 3.5.4, Koffice 1.5.2 ou Amarok 1.4.3.
[^]Re: Et Slack ?
Ca s'explique assez simplement:
- La glibc 2.4 n'est pas utilisable avec un noyau 2.4 standart (voir le changelog de slackware-current).
- X11R7.1 est sorti fin mai. Slackware devait sortir aux alentours de juin, c'était une modification trop importante d'autant plus que le support des cartes NVidia n'était pas encore officiel.
- gcc ne permettait pas de compiler toutes les applications possibles il y a encore quelques mois. La politique de Slackware n'étant pas d' "overpatcher" les logiciels, il a décidé de sortir Slackware 11.0 avec un gcc qui reste parfaitement fonctionnel (et dans la dernière version de la branche 3.x).
- Apache 1.x est extrèmement populaire et il a prouvé sa robustesse. Tout comme pour le noyau, il attend que celui fasse ses preuves avant de faire le "grand saut". La stabilité est primordiale pour Slackware. Je ne vois pas ici du conservatisme mais plutôt une certaine continuité.
Je ne suis pas le dernier pour râler sur certaines longueurs prises par Patrick Volkerding, mais le choix de services stables et d'applications graphiques récentes me paraissent bons.
[+] [^]Re: Et Slack ?
> - La glibc 2.4 n'est pas utilisable avec un noyau 2.4 standart
??
C'est uniquement car il manque linuxthread ?
> - gcc ne permettait pas de compiler toutes les applications possibles il y a encore quelques mois.
gcc 4 était utilisé par FC4 (pour compiler toute la distribution + extra). FC4 est sorti il y a plus d'un an et demi !
Pour FC6 (qui a quelques paquet de plus que FC4) ça fait 3320 src.rpm et 5700 (i386|noarch).rpm. C'est grosso-modo la même chose pour FC4.
Donc les applis qui ne compilent pas avec gcc 4 doivent être très rare et très fort probablement non livré par Slackware. A moins que Slack utilise des programmes si vieux qu'ils nécessitent un vieux gcc...
> - Apache 1.x est extrèmement populaire et il a prouvé sa robustesse.
Apache 2.0.40 (2.0.36 était estimé stable) est sorti il y a plus de 4 ans ! Il était dans RH 8.0. Dans RHEL (pour entreprise et serveurs critiques) c'est utilisé depuis 3 ans !
> Tout comme pour le noyau, il attend que celui fasse ses preuves avant de faire le "grand saut".
Noyau 2.6 pour RHEL 4 (pour entreprise et serveurs critiques) sorti il y a plus d'an. Idem pour Novell/SuSE.
> La stabilité est primordiale pour Slackware.
Excuse bidon. C'est plus de la stabilité, c'est de l'immobilisme.
[^]Re: Et Slack ?
Mouais alors je vais faire très court ... Attention !
-/- La Slackware ne patch pas le noyau ! -/-
Bah je crois que j'ai tout dit.
"Debian est un ancien mot Africain qui signifie "Je m'la pête".
[^]Re: Et Slack ?
Même pour les trous de sécurité ?
Si t'attends une correction "officielle", ça peut prendre du temps (quelques semaines).
[^]Re: Et Slack ?
Bon diou! Peux pas encore plusser!
Et comme le dit si bien le message dessous, effectivement même pour les patchs de sécu. Mais si on reprend la config d'origine (ou si on connaît son matos et ses besoins), ça prend à tout casser 1/4 heure pour compiler et installer un kernel patché.
[^]Re: Et Slack ?
> ça prend à tout casser 1/4 heure pour compiler et installer un kernel patché.
Parles pour toi.
[^]Re: Et Slack ?
et il est vraiment stable depuis quand ?
pour protester contre la dadvsi , je n'achete plus de produit soumis au droit d'auteur ou voisins
[^]Re: Et Slack ?
>> et il est vraiment stable depuis quand ?
Depuis le 2.6.8 de Sarge ?
[^]Re: Et Slack ?
Marrant je pensais que c'était depuis le 2.6.16 par défaut de la Slackware 11.0 ...
Comme quoi on pas la même notion de la stabilité !
"Debian est un ancien mot Africain qui signifie "Je m'la pête".
[^]Re: Et Slack ?
Et ça fait quoi, trois ans qu'on a des kernels 2.6 sous slack ?
En tout cas je suis sous 2.6 depuis qu'il marche correctement. Les premières versions c'était la galère, maintenant c'est nickel.
Et le kernel 2.6 sous slack est un 2.6.17.13, soit un truc vieux de 23 jours seulement...
D'autres question ?
Ca te parait trop difficile à toi de mettre à jour un kernel ?
Alors ne passe surtout pas sous slack, bien que cette opération soit triviale, cette distrib n'est probablement pas faite pour toi si tu as peur de changer le kernel...
Yth.
[^]Re: Et Slack ?
Et le noyau 2.6.18 est même disponible sous Linux Slackware 11.0 dans testing/ et pendant l'installation (test26) ! Il s'agit évidemment d'un noyau fourni pour test et surtout pour ceux qui auraient du matériel qui ne passerait pas avec des noyaux moins récents.
[^]Re: Et Slack ?
Il parlait pas de kernel par défaut ?
[^]Re: Et Slack ?
Et alors ?
Slack met par défaut un kernel stable sûr et bien rodé.
Et permet aux gens qui le souhaitent de mettre un kernel plus récent.
Et avec la 11.0 c'est directement au démarrage de l'install que tu peux faire ce choix, ce qui certes n'était pas le cas pour la 10.2 sortie il y a un peu plus d'un an quand le kernel en était à la version 2.6.13, version qui était parmis les premières vraiment utilisable...
La Slack est robuste, donc oui, par défaut il y a encore un 2.4.
La Slack est à jour, donc il y a le choix avec un 2.6.17.13 ou même un 2.6.18 !
C'est pas du conservatisme ça, c'est de la fiabilité, et du choix.
De plus la Slackware est réputée tourner sur de très vieilles machines (j'ai deux 486 sur lesquels elle tourne nickel), et sur ce genre de matériel, un 2.6 ne s'impose vraiment pas, et on est content d'avoir un 2.4 extrêmement stable, fiable et éprouvé (2.4.33.3 le dernier des 2.4).
Yth.