Les realeses de Netscape sont suffisament rare pour passer en première page.
Et n'oublions pas que Netscape est LE plus gros contributeur de Mozilla et non une boite qui pompe le travail des autres !
Netscape mérité de passer en première page.
Pour moi, mozilla est aussi important que le noyau Linux.
Si les versions mineur de mozilla passe dans la page "autres", les versions mineurs de Linux doivent également passer dans la page "autres".
> A set of promises to keep compatibility with various APIs, broadly construed (XUL 1.0 is an API), until a 2.0 or higher-numbered major release. All milestone releases and trunk development between 1.0 and 2.0 will preserve frozen interface compatibility. Mozilla 1.0 is a greenlight to hackers, corporations, and book authors to get busy building atop this stable base set of APIs.
Sourtout, il ne faut pas oublier le boulot des distributions qui sont la pour fournir un environnement sans bug. Si tu "tapes" dans la dernière version de Linux tu prends des risques (moindre avec un x.y.z (y pair) qu'avec un x.y.z (z pair).
La RedHat 7.2 est fournie avec un 2.4.7 (2.4.9 avec errata) car RedHat à largement testé/audité ce noyau.
Autre exemple, la ditrib RedHat haute-disponibilité est basé sur un 2.2.19 !
Pour le boulot, je prend un noyau uniquement fourni par RedHat. Je fait de même pour la partie serveur (apache/php, etc...) car au boulot je n'ai pas envis de mettre un truc risqué.
Pour un usage perso, je m'amuse un peu plus :-).
Intégré des logiciels critiques prend du temps...
PS: je parle de RedHat car j'utilise RedHat. Je ne critique pas les autres...
Pour t'aider il faudrait mettre plus d'info (messages d'erreur, etc...).
Galeon 0.12.5 se compile et tourne sur RedHat 6.2 (compilation depuis les src.rpm). Mais il faut faire beaucoup de mise à jour de librairie.
Galeon 0.12.7 se compile et tourne sur RedHat 7.2. Par rapport à une RedHat 7.2 d'origine, il faut Mozilla 0.9.5. Ceci impose de virer nautilus (que je n'utilise pas :-) ) et c'est la seule modification par rapport à un RH 7.2 d'origine.
Pour ceux qui veulent toujours nautilaus, la RedHat Rawhide à un nautilus qui tourne avec Mozilla 0.9.5 mais demande la mise à jour de plusieurs librairies gnome.
Je ne vais pas passer à Galeon 1.0 :
1 - il faut passer de mozilla 0.9.5 à 0.9.6.
2 - si je veux nautilus, il faut aussi le mettre à jours (dépendance avec Mozilla).
3 - pour l'installation d'evolution 1.0 qui utilisera surement mozilla 0.9.x (x>6) çà va être encore la valse des mises à jours.
Bref, je vais attendre mozilla > 1, evolution > 1 etc, puis je met tout à jour.
Si j'ai tout compris aux XP (actuellement tu as : -7/#30) :
30 personnes en voté pour ton poste :
* 11 (37%) pensent qu'il est pertinent de rappeler l'adresse des mirrors de kernel.org qui est assez chargé.
* 19 (63%) personnes en ont rein à foutre.
Conclusions :
* La news est excellente car elle fait pas chier la majorité avec une url sur les mirrors dont elle n'a rien à foutre.
* Modérateurs, si on vous propose une news avec une url sur la liste des mirrors, virer cette url.
* Utilisateurs de linuxfr, évitez de poster une url sur la liste des mirrors, c'est mauvais pour vos XP.
Tu crois que RedHat va dire du "mal" ext3 pour se faire plaisir?
C'est comme si Microsoft annoncais des bugs dans Windows qui n'existent pas.
> Tout le principe des fichiers journalisés repose ...
> ...
Globalement, tout ce que tu dis est juste ! C'est le même principe de transaction que les bases de données qui est atonique :-> .
Tu parles de coupure de courant sur les disques dures. Hors RedHat parle de coupure de courant sur la carte mère. Dans ce cas, la mémoire vive peut être corrompue alors que l'os envois la demande d'écrire (les données peuvent également être corrompu au niveau du controleur IDE). Les disques font correctement leur travail mais écrivent des données corrompues. Bien sure, si les disques dures tombent avant la carte-mère il n'y a pas de problème.
Il faut bien noté que c'est un problème de hardware auquel Linux (ou windows ou Solaris ou ...) ne peut rien !
Imaginons une solution (je ne connais rien à l'électronique).
Sur coupure de courant une capa permet à ma CM de tourner encore 1 seconde.
Un système en amont de la carte mère controle l'arrivé du courant.
S'il détecte un problème sur l'arrivé du courant :
- 0,5 secondes après, fait un reset hard (d'après RedHat ext3 le supporte) si alimentation non stable.
- 0,9 secondes après, arrêt de la carte mère jusqu'au retour d'une alimentation stable.
Enfin, l'autre problème soulevé par RedHat est que les disques IDE peuvent réorganiser l'ordre d'écriture. Ceci afin de limiter les déplacements du bras du disque dure. l'OS dans ce cas ne peut rien. L'os ne connait pas la géométrie du disque : en effet sur les disques moderne, les informations de géométrie retournées ne correspondent pas toujours à l'organisation réelle. Donc l'os ne peut limiter les déplacements de bras aussi finement que peut le faire le controleur du disque qui lui connait la géométrie réelle du disque. Ne parlons même pas des cartes raid qui font croire à l'os qu'il n'y a qu'un disque dur alors qu'il y en a plusieurs...
Par contre SCSI garanti l'ordre d'écriture et fait l'impasse sur l'optimisation des déplacements des bras.
Avec SCSI :
- l'OS demande :
---- écriture donnée
---- validation donnée
- le disque SCSI fait :
---- écriture donnée
---- validation donnée (atonique)
Avec IDE :
- l'OS demande :
---- écriture donnée
---- validation donnée
- le disque IDE PEUT FAIRE :
---- validation donnée (atonque)
---- écriture donnée. S'il y a coupure de courant avant écriture des données tu as un journal qui indique des données validées alors qu'elles n'ont pas été écrites !
> tous les outils Linux/Unix qui marchent encore sur ext2 ne sont pas tous portés sur ext3
C'est un peut "naze" comme remarque.
Par exemple, tu peux utiliser fsck fournie avec, par exemple, une redhat 6.2 sur un ext3. Dans ce cas, le journal peut être supprimé et tu ne peux plus monté la partition en ext3.Il faut recréer le journal avec tune2fs. Et si tu n'as pas une version de tune2fs qui permet l'ajout du journal, tu supprimes la journalisation avec l'option "-O". Tu reboot sous ta RH7.2 (par exemple) et tu réactives la journalisation avec tune2fs.
Quand je pense aux reproches fait à RedHat de ne pas intégrer ReiserFS (ou avec toutes les options de debug activé) alors que Suse et Mandrake l'ont fait très tôt et que je vois des posts sur des problèmes de fiabilité avec ReiserFS (sans parler des problèmes NFS et quota) , je me marre...
Heureusement qu'il y a RedHat, Debian (liste non complète !) pour ne pas sauter sur tout ce qui bouge et faire la course à la dernière version de noyau (surtout pour les systèmes de fichier).
J'ai parfois l'impression que les "Linuxiens" sont aussi c.. que les windowsiens (pas peur de suicider mes XP !).
Plus une copie partielle du fichier :
> Veuillez prendre note que les fichiers journaux aussi peuvent être
> endommagés en cas de panne d'électricité. Lorsqu'un système est privé
> de courant, le comportement de ce système est indéterminé. Exemple : le
> contenu de la mémoire peut se dégrader (devenir corrompu de façon
> aléatoire) car il est copié sur le disque dur exécutant les derniers
> souffles d'énergie. Cette situation est complètement différente de la
> séquence d'événements définie qu'est l'arrêt du système en appuyant sur
> le bouton « réinitialiser » lorsque le système est en cours d'exécution.
> En outre, les disques durs IDE n'offrent pas toutes les garanties d'ordre
> d'écriture que les disques SCSI offrent.
Maintenant t'es libre de faire comme les autres et de dire que les systèmes de fichier journalisé c'est top génial pour ton PC personnel sans onduleur avec disque ide qui passe par un controleur avec 16 Mo de cache et un noyau 2.5.x (x > 0).
J'ai une RedHat 7.2 ou boulot avec ext3 depuis 1 moi. Mon pc avait des problèmes avec les nappes IDE (c'est un pc de dev, donc du IDE c'est nettement suffisant). A cause de ce problème, le noyau a fait plusieurs panic/freeze (les données qui venait du swap je pense). A chaque reboot le fsck n'était pas complet mais rapide (c'est le "plus" d'ext3). J'ai fait des fsck forcés (-f) et il restait des erreurs ! C'est normal. Le noyau (et ext3) croit avoir écrit correctement sur le disque, hors ce n'est pas le cas. Une foi le problème des nappes fixé, pas de plantage et donc peu d'interrêt d'ext3.
Je me répète, mais un système de fichier journalisé c'est pas très intéressant pour un usage courant (sauf peut-être sous Windows :-) ).
Je veux simplement que la comparaison soit faite à niveau de sécurité équivalent. Ou alors indiquer clairement que le niveau de sécurité n'ai pas le même.
Je dis çà que il y a 3 ou 4 ans, MySQL était souvent livré avec fsync() désactivé (ce qui est abominable pour la sécurité des données). Et lorsqu'il y avait une comparaison être PostgreSQL et MySQL, MySQL était évidament plus rapide. Alors que sous PostgreSQL on peut aussi désactivé l'appel à fsync() (à évité bien évidament...).
Il faut comparer ce qui est comparable ou être très claire dans ce qui est comparé. exemple :
ext2 : pas de journalisation
ext3 conf 1 : journalisation data/metadata
ext3 conf 2 : journalisation metadata
ReiserFS : journalisation metadata
Les lecteurs de linuxfr aime les systèmes de fichier performant. La popularité de ReiserFS sur linuxfr est significative (çà change avec ext3).
Hors la sécurité c'est plus important.
Avec ext3 et avec les paramètrages par défaut, les données sont journalisé contrairement à ReiserFS. Avec ReiserFS lors d'un reboot violent, il indique aucun problème au niveau système de fichier mais les données peuvent être corrompues.
Pour les aspects performance, si quelqu'un fait un bench entre ext3 et ReiserFS il faut qu'il désactive la journalisation des données d'ext3 (mode writeback) pour faire une comparaison juste.
Enfin, avec ext3, le journal peut être mis sur un autre disque physique ce qui peut encore améliorer les performances.
Ce que je veux dire :
- Je préfère un système très fiable sans système de fichier journalisé qu'un système moyennement fiable avec système de fichier journalisé. Par exemple, un système de fichier journalisé sous windows pour des postes de travail, c'est super cool. Un système de fichier journalisé sous Linux (Qui pour des raison technique hardware, ne peut supporter les coupures de courant ni les disques IDEs, idem avec Windows) est moins interressant pour un usage classique.
Après si du fait des tests noyau, que tu as des disque SCSI, un serveur qui doit être disponible 24h/24 7j/7 365j/ans alors dans ce cas un système de fichier journalisé est super cool moins pour un système hyper fiable.
PS :
Pour les fautes d'orthographe, je te laisse corriger...
Avis sur ext2 et ext3.
En gros c'est la même chose. Les performances sont très proche.
Pour mon usage perso avoir un système journalisé n'apporte partiquement rien. De plus les systèmes de fichier journalisé sont sure avec SCSI (ordre d'écriture garanti) et ne supporte pas les coupures de courant. Bref, c'est uniquement pour les plantages noyau (le reset hard est supporté). Ces infos sont dans le README de la 7.2.
Pour une utilisation au boulot:
station de travail : ext3 n'apporte rien.
serveur : nos serveur (qui sont de petits serveurs...) ne plante pas. Donc très peut de gain.
Conclusion ext2/ext3 :
ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver .
Les modérateurs peuvent-il expliqué ce qui les a motivé a passer cette article en première page?
Ce type attaque RedHat sans ce pencher sur le système rpm.
S'il veut fait des package kde dans /opt/kde, il peut.
si je veut connaitre les packages qui utilisent gnome-libs :
$ rpm -q --whatrequires gnome-libs
Je n'ai pas besoin qu'il soit dans /opt/gnome ou autre...
Si je veut avoir la liste des fichiers associés :
$ rpm -q -l --whatrequires gnome-libs
Mettre toute les libs dans /usr/lib et tous les include dans /usr/include est FORMIDABLE et c'est possible de façon controlé grace à rpm (ou apt de debian). Car avant il fallait :
./configure --with-truc=/opt/truc --with-truc-lib=/opt/truc/lib --with-toto ....
Alors vive le chois de RedHat, Debian, Mandrake, etc... C'est mille foi mieux que sous HP-UX avec les /usr/contrib, /usr/ccs, etc, etc...
Damned, j'ai un score super-négatif.
En fesant une recherche (moteur de recherche) sur linuxfr j'ai trouvé la news annoncant la sorti de mozilla 0.9.6. Les commentaires indiquent que la news est dans la boîte "autre".
Hors je n'ai pas l'annonce de la sortie de mozilla dans ma boite "autre". Dans la boite autre, je n'ai rien pour le 20 et 21 novembre.
Pourquoi je n'ai pas la sortie de mozilla dans la boite "autre"?
=> j'aimerai une réponse/explication.
=> çà m'évitera de passer pour con...
[^] # Re: Petite remarque !
Posté par matiasf . En réponse à la dépêche Galeon 1.0 est sorti. Évalué à 1.
Et n'oublions pas que Netscape est LE plus gros contributeur de Mozilla et non une boite qui pompe le travail des autres !
Netscape mérité de passer en première page.
Pour moi, mozilla est aussi important que le noyau Linux.
Si les versions mineur de mozilla passe dans la page "autres", les versions mineurs de Linux doivent également passer dans la page "autres".
[^] # Re: Compil sur Mandrake
Posté par matiasf . En réponse à la dépêche Galeon 1.0 est sorti. Évalué à 1.
Je confirme qu'évolution n'utilise pas le moteur d'affichage de Mozilla.
[^] # Re: Compil sur Mandrake
Posté par matiasf . En réponse à la dépêche Galeon 1.0 est sorti. Évalué à 1.
BuildRequires: mozilla-devel = 0.9.6
Requires: mozilla = 0.9.6
$ grep MOZILLA_REQUIRED configure
MOZILLA_REQUIRED=0.9.6
En forçant, çà marche peut-être avec la 0.9.5
> l'api de mozilla est freezée depuis la 0.9
Non.
L'api sera freezé avec la version 1.0:
http://www.mozilla.org/roadmap/mozilla-1.0.html(...)
> A set of promises to keep compatibility with various APIs, broadly construed (XUL 1.0 is an API), until a 2.0 or higher-numbered major release. All milestone releases and trunk development between 1.0 and 2.0 will preserve frozen interface compatibility. Mozilla 1.0 is a greenlight to hackers, corporations, and book authors to get busy building atop this stable base set of APIs.
[^] # Re: Pas de panique
Posté par matiasf . En réponse à la dépêche Kernel 2.4.15/2.5.0 buggé. Attention !. Évalué à 1.
$ cd /usr/src/linux
$ patch -p1 < ~/le_patch_qui_va_bien.patch
L'idéal est d'utiliser des sources propres.
- tu vires /usr/src/linux et remet les sources depuis le tar.gz
- OU "make mrproper" dans /usr/src/linux
[^] # Re: evolution !
Posté par matiasf . En réponse à la dépêche Kernel 2.4.15/2.5.0 buggé. Attention !. Évalué à 1.
Il faut lire :
"moindre avec un x.y.z (y pair) qu'avec un x.y.z (y impair).
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Dans un post plus haut je donnais mon avis sur ext2/ext3 de mon point de vu utilisateur :
> Conclusion ext2/ext3 :
> ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver.
[^] # Re: evolution !
Posté par matiasf . En réponse à la dépêche Kernel 2.4.15/2.5.0 buggé. Attention !. Évalué à 1.
Sourtout, il ne faut pas oublier le boulot des distributions qui sont la pour fournir un environnement sans bug. Si tu "tapes" dans la dernière version de Linux tu prends des risques (moindre avec un x.y.z (y pair) qu'avec un x.y.z (z pair).
La RedHat 7.2 est fournie avec un 2.4.7 (2.4.9 avec errata) car RedHat à largement testé/audité ce noyau.
Autre exemple, la ditrib RedHat haute-disponibilité est basé sur un 2.2.19 !
Pour le boulot, je prend un noyau uniquement fourni par RedHat. Je fait de même pour la partie serveur (apache/php, etc...) car au boulot je n'ai pas envis de mettre un truc risqué.
Pour un usage perso, je m'amuse un peu plus :-).
Intégré des logiciels critiques prend du temps...
PS: je parle de RedHat car j'utilise RedHat. Je ne critique pas les autres...
[^] # Re: Aie...
Posté par matiasf . En réponse à la dépêche Kernel 2.4.15/2.5.0 buggé. Attention !. Évalué à 1.
s/2\.2/2.4/g :
çà veut dire remplacer toute les occurences de la chaine "2.2" par "2.4".
Glandium essai d'élargir ton public. Surtout pour dire des trucs aussi simple.
PS: t'es pas le seul à faire une sorte d'"élitisme".
[^] # Re: Compil sur Mandrake
Posté par matiasf . En réponse à la dépêche Galeon 1.0 est sorti. Évalué à 1.
Galeon 0.12.5 se compile et tourne sur RedHat 6.2 (compilation depuis les src.rpm). Mais il faut faire beaucoup de mise à jour de librairie.
Galeon 0.12.7 se compile et tourne sur RedHat 7.2. Par rapport à une RedHat 7.2 d'origine, il faut Mozilla 0.9.5. Ceci impose de virer nautilus (que je n'utilise pas :-) ) et c'est la seule modification par rapport à un RH 7.2 d'origine.
Pour ceux qui veulent toujours nautilaus, la RedHat Rawhide à un nautilus qui tourne avec Mozilla 0.9.5 mais demande la mise à jour de plusieurs librairies gnome.
Je ne vais pas passer à Galeon 1.0 :
1 - il faut passer de mozilla 0.9.5 à 0.9.6.
2 - si je veux nautilus, il faut aussi le mettre à jours (dépendance avec Mozilla).
3 - pour l'installation d'evolution 1.0 qui utilisera surement mozilla 0.9.x (x>6) çà va être encore la valse des mises à jours.
Bref, je vais attendre mozilla > 1, evolution > 1 etc, puis je met tout à jour.
[^] # Re: et voila la liste des miroirs
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
30 personnes en voté pour ton poste :
* 11 (37%) pensent qu'il est pertinent de rappeler l'adresse des mirrors de kernel.org qui est assez chargé.
* 19 (63%) personnes en ont rein à foutre.
Conclusions :
* La news est excellente car elle fait pas chier la majorité avec une url sur les mirrors dont elle n'a rien à foutre.
* Modérateurs, si on vous propose une news avec une url sur la liste des mirrors, virer cette url.
* Utilisateurs de linuxfr, évitez de poster une url sur la liste des mirrors, c'est mauvais pour vos XP.
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
C'est l'idéal. mais un onduleur c'est cher.
Je parle d'un truc à 5 francs et non 1000.
Et linux ne s'arrête pas en 0,5 seconde...
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Tu crois que RedHat va dire du "mal" ext3 pour se faire plaisir?
C'est comme si Microsoft annoncais des bugs dans Windows qui n'existent pas.
> Tout le principe des fichiers journalisés repose ...
> ...
Globalement, tout ce que tu dis est juste ! C'est le même principe de transaction que les bases de données qui est atonique :-> .
Tu parles de coupure de courant sur les disques dures. Hors RedHat parle de coupure de courant sur la carte mère. Dans ce cas, la mémoire vive peut être corrompue alors que l'os envois la demande d'écrire (les données peuvent également être corrompu au niveau du controleur IDE). Les disques font correctement leur travail mais écrivent des données corrompues. Bien sure, si les disques dures tombent avant la carte-mère il n'y a pas de problème.
Il faut bien noté que c'est un problème de hardware auquel Linux (ou windows ou Solaris ou ...) ne peut rien !
Imaginons une solution (je ne connais rien à l'électronique).
Sur coupure de courant une capa permet à ma CM de tourner encore 1 seconde.
Un système en amont de la carte mère controle l'arrivé du courant.
S'il détecte un problème sur l'arrivé du courant :
- 0,5 secondes après, fait un reset hard (d'après RedHat ext3 le supporte) si alimentation non stable.
- 0,9 secondes après, arrêt de la carte mère jusqu'au retour d'une alimentation stable.
Enfin, l'autre problème soulevé par RedHat est que les disques IDE peuvent réorganiser l'ordre d'écriture. Ceci afin de limiter les déplacements du bras du disque dure. l'OS dans ce cas ne peut rien. L'os ne connait pas la géométrie du disque : en effet sur les disques moderne, les informations de géométrie retournées ne correspondent pas toujours à l'organisation réelle. Donc l'os ne peut limiter les déplacements de bras aussi finement que peut le faire le controleur du disque qui lui connait la géométrie réelle du disque. Ne parlons même pas des cartes raid qui font croire à l'os qu'il n'y a qu'un disque dur alors qu'il y en a plusieurs...
Par contre SCSI garanti l'ordre d'écriture et fait l'impasse sur l'optimisation des déplacements des bras.
Avec SCSI :
- l'OS demande :
---- écriture donnée
---- validation donnée
- le disque SCSI fait :
---- écriture donnée
---- validation donnée (atonique)
Avec IDE :
- l'OS demande :
---- écriture donnée
---- validation donnée
- le disque IDE PEUT FAIRE :
---- validation donnée (atonque)
---- écriture donnée. S'il y a coupure de courant avant écriture des données tu as un journal qui indique des données validées alors qu'elles n'ont pas été écrites !
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
C'est un peut "naze" comme remarque.
Par exemple, tu peux utiliser fsck fournie avec, par exemple, une redhat 6.2 sur un ext3. Dans ce cas, le journal peut être supprimé et tu ne peux plus monté la partition en ext3.Il faut recréer le journal avec tune2fs. Et si tu n'as pas une version de tune2fs qui permet l'ajout du journal, tu supprimes la journalisation avec l'option "-O". Tu reboot sous ta RH7.2 (par exemple) et tu réactives la journalisation avec tune2fs.
Bref, je comprend pas ta remarque...
[^] # Re: reiser et meta
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Heureusement qu'il y a RedHat, Debian (liste non complète !) pour ne pas sauter sur tout ce qui bouge et faire la course à la dernière version de noyau (surtout pour les systèmes de fichier).
J'ai parfois l'impression que les "Linuxiens" sont aussi c.. que les windowsiens (pas peur de suicider mes XP !).
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Tu as raison, c'est dans le "RELEASE-NOTES".
REALSE-NOTES :
ftp://ftp.free.fr/pub/Distributions_Linux/RedHat/redhat/redhat-7.2(...)
Plus une copie partielle du fichier :
> Veuillez prendre note que les fichiers journaux aussi peuvent être
> endommagés en cas de panne d'électricité. Lorsqu'un système est privé
> de courant, le comportement de ce système est indéterminé. Exemple : le
> contenu de la mémoire peut se dégrader (devenir corrompu de façon
> aléatoire) car il est copié sur le disque dur exécutant les derniers
> souffles d'énergie. Cette situation est complètement différente de la
> séquence d'événements définie qu'est l'arrêt du système en appuyant sur
> le bouton « réinitialiser » lorsque le système est en cours d'exécution.
> En outre, les disques durs IDE n'offrent pas toutes les garanties d'ordre
> d'écriture que les disques SCSI offrent.
Maintenant t'es libre de faire comme les autres et de dire que les systèmes de fichier journalisé c'est top génial pour ton PC personnel sans onduleur avec disque ide qui passe par un controleur avec 16 Mo de cache et un noyau 2.5.x (x > 0).
J'ai une RedHat 7.2 ou boulot avec ext3 depuis 1 moi. Mon pc avait des problèmes avec les nappes IDE (c'est un pc de dev, donc du IDE c'est nettement suffisant). A cause de ce problème, le noyau a fait plusieurs panic/freeze (les données qui venait du swap je pense). A chaque reboot le fsck n'était pas complet mais rapide (c'est le "plus" d'ext3). J'ai fait des fsck forcés (-f) et il restait des erreurs ! C'est normal. Le noyau (et ext3) croit avoir écrit correctement sur le disque, hors ce n'est pas le cas. Une foi le problème des nappes fixé, pas de plantage et donc peu d'interrêt d'ext3.
Je me répète, mais un système de fichier journalisé c'est pas très intéressant pour un usage courant (sauf peut-être sous Windows :-) ).
[^] # Re: Ext3 !!!
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Je dis çà que il y a 3 ou 4 ans, MySQL était souvent livré avec fsync() désactivé (ce qui est abominable pour la sécurité des données). Et lorsqu'il y avait une comparaison être PostgreSQL et MySQL, MySQL était évidament plus rapide. Alors que sous PostgreSQL on peut aussi désactivé l'appel à fsync() (à évité bien évidament...).
Il faut comparer ce qui est comparable ou être très claire dans ce qui est comparé. exemple :
ext2 : pas de journalisation
ext3 conf 1 : journalisation data/metadata
ext3 conf 2 : journalisation metadata
ReiserFS : journalisation metadata
[^] # Re: Ext3 !!!
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Les lecteurs de linuxfr aime les systèmes de fichier performant. La popularité de ReiserFS sur linuxfr est significative (çà change avec ext3).
Hors la sécurité c'est plus important.
Avec ext3 et avec les paramètrages par défaut, les données sont journalisé contrairement à ReiserFS. Avec ReiserFS lors d'un reboot violent, il indique aucun problème au niveau système de fichier mais les données peuvent être corrompues.
Pour les aspects performance, si quelqu'un fait un bench entre ext3 et ReiserFS il faut qu'il désactive la journalisation des données d'ext3 (mode writeback) pour faire une comparaison juste.
Enfin, avec ext3, le journal peut être mis sur un autre disque physique ce qui peut encore améliorer les performances.
[^] # Re: 2.4.15-greased-turkey
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
version.h est un fichier généré par un Makefile (avec "make dep" par exemple).
D'ailleur, il sera supprimé par un "make mrproper" !
[^] # Re: 2.4.15-greased-turkey
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Mais fait un :
$ vi /usr/src/linux/Makefile
au début il y a un truc du style :
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 9
EXTRAVERSION = -13custom
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
mais à "" EXTRAVERSION et regarde si çà corrige le problème.
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
- Je préfère un système très fiable sans système de fichier journalisé qu'un système moyennement fiable avec système de fichier journalisé. Par exemple, un système de fichier journalisé sous windows pour des postes de travail, c'est super cool. Un système de fichier journalisé sous Linux (Qui pour des raison technique hardware, ne peut supporter les coupures de courant ni les disques IDEs, idem avec Windows) est moins interressant pour un usage classique.
Après si du fait des tests noyau, que tu as des disque SCSI, un serveur qui doit être disponible 24h/24 7j/7 365j/ans alors dans ce cas un système de fichier journalisé est super cool moins pour un système hyper fiable.
PS :
Pour les fautes d'orthographe, je te laisse corriger...
[^] # Re: Enfin journalisé !
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
En gros c'est la même chose. Les performances sont très proche.
Pour mon usage perso avoir un système journalisé n'apporte partiquement rien. De plus les systèmes de fichier journalisé sont sure avec SCSI (ordre d'écriture garanti) et ne supporte pas les coupures de courant. Bref, c'est uniquement pour les plantages noyau (le reset hard est supporté). Ces infos sont dans le README de la 7.2.
Pour une utilisation au boulot:
station de travail : ext3 n'apporte rien.
serveur : nos serveur (qui sont de petits serveurs...) ne plante pas. Donc très peut de gain.
Conclusion ext2/ext3 :
ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver .
# ext3
Posté par matiasf . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
Depuis les sources Linux il est possible de faire un rpm :
$ cd /usr/src/linux-2.4*
$ make rpm
ou
$make spec
puis faire un rpm -bb kernel.spec
PS : c'est une procédure très grossière...
# beurck
Posté par matiasf . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 0.
Ce type attaque RedHat sans ce pencher sur le système rpm.
S'il veut fait des package kde dans /opt/kde, il peut.
si je veut connaitre les packages qui utilisent gnome-libs :
$ rpm -q --whatrequires gnome-libs
Je n'ai pas besoin qu'il soit dans /opt/gnome ou autre...
Si je veut avoir la liste des fichiers associés :
$ rpm -q -l --whatrequires gnome-libs
Mettre toute les libs dans /usr/lib et tous les include dans /usr/include est FORMIDABLE et c'est possible de façon controlé grace à rpm (ou apt de debian). Car avant il fallait :
./configure --with-truc=/opt/truc --with-truc-lib=/opt/truc/lib --with-toto ....
Alors vive le chois de RedHat, Debian, Mandrake, etc... C'est mille foi mieux que sous HP-UX avec les /usr/contrib, /usr/ccs, etc, etc...
[^] # Re: Moi, Eclipse m'écoeure
Posté par matiasf . En réponse à la dépêche Test Eclipse. Évalué à -3.
En fesant une recherche (moteur de recherche) sur linuxfr j'ai trouvé la news annoncant la sorti de mozilla 0.9.6. Les commentaires indiquent que la news est dans la boîte "autre".
Hors je n'ai pas l'annonce de la sortie de mozilla dans ma boite "autre". Dans la boite autre, je n'ai rien pour le 20 et 21 novembre.
Pourquoi je n'ai pas la sortie de mozilla dans la boite "autre"?
=> j'aimerai une réponse/explication.
=> çà m'évitera de passer pour con...
[^] # Re: Moi, Eclipse m'écoeure
Posté par matiasf . En réponse à la dépêche Test Eclipse. Évalué à -7.
Donc, pour ceux (j'en fait parti) qui pense qu'une nouvelle realese de Mozilla est aussi importante qu'une nouvelle version de Linux :
Mozilla 0.9.6 est sorti !
PS : j'ai posté la news ce matin mais elle n'est pas passée...
Scrore -1 sinon les modulos vont sortir leurs chalumeaux.