Encore un petit mot pour dire que la France, et même en 2001 n'est pas la honte de l'europe si les statistiques sont rapportées au nombre de conducteurs ou au nombre de kilomètres parcourus. Même en 2001 on était dans la moyenne européen.
Il faut faire quelque chose et les 8000 morts et x blessé par an justifient des actions.
C'est l'évalution du problème qu'il faut relativiser. Si c'était la catastrophe qu'on entend partout, pourquoi la France à l'espérance de vie la plus importante ?
Il y a presque autant de sucides "réussis" que de morts sur la route.
Les morts dans les hopitaux suite à une infection nosocomiale fait dans les 10 000 morts/ans.
Les accidents domestiques font autant de morts que la route.
Sur le discours, on ne peut pas faire dans le deux poids deux mesures. Un barouffe du diable pour la route et rien ou presque pour d'autres domaines qui font autant de morts. Si on ajoutes les suicides et les accidents domestiques on a le double de la route !.
> Les limitations de vitesse sont mises en focntions de la visibilité
Je doute grave.
Les radars aussi sont mis en fonction de la visibilité ?
Ils sont mis dans les lignes droites où il y a aucun danger pour être sûr de te faire "avoir". L'idéal est en bas d'une côte...
Je dis ça mais des contraventions il en faut. La route ce n'est pas le far west.
> La réduction de la vitesse qui endort les conducteurs c'est l'argument le plus ridicule que j'ai jamais entendu.
Prends une bonne voiture (si t'as les moyens), va sur l'autoroute A5 où il n'y a pratiquement personne un jour de beau temps. A 130 km/h tu t'emmerdes grave de chez grave et t'as le sentiment que la limitation à 130 est vraiment stupide. A 130 km/h, tu passes ton temps à regarder le paysage et pas la route. A 160 km/h, comme il y a plus d'"animation", tu regardes plus la route, t'es plus vigilent et j'ai pas l'impression que les risques sont plus élevés.
Le problème de l'A5, c'est qu'il y a plein de radars (cette autoroute est parfaite pour les flics). Alors je préfère prendre l'A7 à 130 et prendre des risques car le traffic est dense et avec plein de camion que de prendre l'A5 en toute sécurité à 160 km/h mais risquer probablement une prune (à 130 je risque l'endormissement et l'accident grave).
> La vitesse est un facteur EXTREMEMENT agravant des accidents
L'avion est l'un des moyens de transport le plus sûr... et il y a moins de risque sur autoroute que sur départementale. Le rapport est au minimum de 3.
Ce n'est pas si simple. Ce qu'il faut en priorité, c'est diminuer le nombre d'accidents comme dans l'aviation. Un avion qui se crash, c'est un drame dans 95 % des cas. Un avion est une grosse merde lors d'un accident mais l'avion fait peu d'accident. Donc l'avion va à la vitesse qu'il veut si les conditions le permettent. Le seul accident du concorde, n'était pas à mach 2 :-).
Il y a beaucoup plus d'accident sur autoroute à cause de l'endormissement, de l'inattention que de la vitesse. Et pourquoi se fixer sur les excès de vitesse sur autoroute alors que ça fait très très peu de morts ou blessés et c'est sans comparaison avec l'alcool ou les accidents sur départementale ou en ville ?
> aucune voiture ne supporte un accident à 130km/h
Dépend de l'accident. Mais contre un mur c'est vrai.
> des crash tests qui sont réalisés rappelont le à 36km/h
- "Les voitures sont projetés à 64 km/h (La directive européenne prévoit "uniquement" 56 km/h) contre une barrière métallique déformable. 40% de la voiture uniquement (coté conducteur) heurte la barrière."
64 km/h et 40 % du véhicule et avec une voiture moderne, tu t'en tires (mais pas avec le sourire et ça dépend des voitures). Ce type de choc est comme si deux voitures allaient l'une vers l'autre à 64 km/h et se heurtaient avec 40 % de recouvrement. Ou que l'une des deux voitures était arrêtée et l'autre allait à 128 km/h ...
Mais comme c'est contre une barrière déformable... avec une barrière rigide (un mur) et à 64 km/h (ou 56) il y a d'énorme risque.
Comme on ne sait pas sur quoi on va taper, il faut rester attendif (s'endormir à 130 km/h ou même 90 est une catastrophe !), modérer sa vitesse, et il faut éviter en premier les excès ... de confiance que les excès de vitesses réglementaires qui font seulement mal au porte-feuille.
Je ne retrouve plus la référence mais les vieilles voitures ont moins d'accidents au kilomètre que le voitures récentes. Dans l'article, il indiquait qu'au début de l'ABS certains assureurs faisait des réductions. Ils ont vites arrêtés.
C'est l'infrastructure routière (et le comportement des conducteurs) qui fait le plus diminuer le nombre d'accident et non les aides à la conduite qui sont souvent utilisé comme des aides pour aller vite.
C'est rapide, même très rapide en période de forte demande. Lors de la sortie de mandrake 9.1 c'était le moyen le plus rapide et fiable (inutile de tester une dizaine de mirroir pour en trouver un rapide).
> plus sur
Sauf utiliser les signatures GPG comme quand tu utilises un mirroir ou kernel.org. Bittorrent vérifie ton download avec md5sum.
En plus, ça soulage les mirrors. Il n'y a aucun problème dans l'utilisation de bittorrent et c'est dans l'esprit du libre. Tu downloades et ce que tu as downloadé est uploadé par les autres. Tu participes à la diffusion du noyau. Laissez tourner bittorrent quelque minutes après le download :-)
Le problème doit être ailleurs.
La différence entre rc8 et final est le minimum du minimum : http://www.fr.kernel.org/pub/linux/kernel/v2.4/testing/incr/patch-2(...)
diff -urN linux-2.4.21-rc8/Makefile linux-2.4.21/Makefile
--- linux-2.4.21-rc8/Makefile 2003-06-13 07:54:36.000000000 -0700
+++ linux-2.4.21/Makefile 2003-06-13 07:54:41.000000000 -0700
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 21
-EXTRAVERSION = -rc8
+EXTRAVERSION =
Je parlais de façon général et c'était pour dire qu'Alan bosse sur IDE et donc ceux qui ont des problèmes doivent regarder et tester la branche -ac et il y a un patch-2.4.21-rc8-ac1 (marche sur un 2.4.21). La version marcelo est "logiquement" en retard sur la version Alan. Je ne trouve pas ça vraiment anormal.
Enfin, les corrections et ajout de driver que tu annonces sont d'un mois environ. Soit en pleine phase rc.
Alan bosse depuis un bon moment sur la IDE pour la refaire presque complètement. Les versions -ac sont plus avancées sur l'IDE. Le développement est fait en premier sur 2.4 puis est porté sur 2.5.
> mais Alan n'a pas livré à Marcelo la dernière version (pour une raison inconnue)
Peut-être parce qu'on ne peut pas demander un noyau stable et les derniers développements dedans.
Il est normal que les disques soient /dev/hda ...
Dans le noyau de la mandrake, l'option "Boot off-board chipsets first support" est activé. Si tu veux le même comportement il faut activer l'option.
> Tu vois ou que je parles de invente ou code en premier ?
Tu dis : "notre stack TCP/IP est 100% made in MS" . Ça sous entend que la pile tcp/ip utilisée partout (et non seulement MS) a été faite par MS. Je voulais souligner que c'était faut.
Dire "notre stack" sur dlfp pour parlé de la stack MS, c'est pas évident à comprendre.
D-BUS va peut-être passé chez xwin. Et puis c'est vrai que je commence a en avoir marre des extensions. Je veux dire que xft, par exemple, n'est plus une extension mais doit faire parti des briques fondamentales.
Maintenant, il faut clairement dire que telle ou telle techno est obsolète. Il faut étendre le protocole X11 (qui date de plusieurs milliers d'année informatique) pour supporter des nouvelles technos sans que ce soit "ugly".
que ce soit NGPL, NTPL ou autre, que ce soit fait dans Linux ou la libc, j'en ai strictement rien à foutre. Je dis seulement que je fait confiance au dev de linux de la libc de binutils (bref tout ceux que ça regarde) ... pour faire le bon choix.
J'ai bien compris que pour NGPL et NPTL Linux 2.5 fourni le nécessaire et que c'est la libc qui fait la différence.
Mais je répète, je n'y connait rien en thread et j'ai pas envis de rentrer dans ce débat.
J'ai rebondi sur un commentaire plus haut :
- "Donc, au 6 mars 2002, NGPT était déjà inclu dans le noyau. Quel retour arrière!"
Je voulais dire que redhat ne va rien imposer. C'est les developpeurs qui vont faire le choix, que ce choix peut évoluer en fonction des développements (c'était pour le "retour arrière" (qui n'en est pas un, c'est pas la peine de t'énerner) et que je leur fait confiance pour ce choix.
Je réagissait à ça :
> > Mais si NGTL est meilleur, je fais confiance à l'intelligence des developpeurs Linux pour l'utiliser
>
> http://www.kernelnewbies.org/status/Status-06-M(...) Donc, au 6 mars 2002, NGPT était déjà inclu dans le noyau. Quel retour arrière!
Simplement pour dire que le système qui restera sera le globalement meilleur et que si les dev ont fait "retour arrière" c'est peut-être pour les raisons que j'ai donné. Mais ok, j'ai oublié le "peut-être" et ma phrase ne reflète pas ce que je pensais.
> Donc, au 6 mars 2002, NGPT était déjà inclu dans le noyau. Quel retour arrière!
Tu viens de découvrir qu'en développement rien n'est figé. C'est pas forcément l'avis des devs qui a changé. C'est NPTL qui a évoluer, c'est NGPT qui n'a pas tenu ces promesses, etc...
Est généralement plus performant. Il n'est pas toujours plus performant.
De plus, c'est un bench réalisé par le team NGTL. Le bench a été peut-être (je dis bien "peut-être") choisi car il favorise NGTL. C'est de bonne guerre :-)
Mais si NGTL est meilleur, je fais confiance à l'intelligence des developpeurs Linux pour l'utiliser. D'ailleur côté noyau il y a rien à faire et côté glibc, nptl est un "add-on". Donc soit tu fournis NPTL ou NGPL. Personnellement, NPTL ou NGTL, je m'en balance ccoommppllèètteemmeenntt du moment que j'ai le meilleur et qu'il est sous GPL (ce qui est le cas pour les deux).
Notes aussi :
- "No changes were made to the kernel patches and thanks to the NPTL effort, all changes required to run NGPT on the latest 2.5.x kernels are already included."
C'est redhat qui "mène" NPTL et ils ne "retiennent" pas NGTL. Si NGTL est meilleur que NPTL pour rapport à leur besoin, aux besoins de leurs clients, redhat prendra NGTL et NPTL va mourrir. C'est la vie du free software, impitoyable...
> Ce genre de chose se constate à l'usage (qui sait c'est peut-être fiable, j'en sais rien), non pas à priori.
C'est stable j'ai un rh9 depuis 1 semaine et ça roule nickel. Par contre qui y a des vieille appli que je doit lancer avec ENV LD_ASSUME_KERNEL=2.4.1 .
> Si il s'avere que la NPTL rende le système plus instable qu'autre chose, ça sera un argument de plus en faveur de Mandrake.
C'est pas de savoir si nptl est stable qui t'interesse. Ce que tu veux, c'est savoir si tu peux en faire un argument en faveur de Mandrake.
Ben t'as pas de chance car nptl sera dans la prochaine Mandrake.
[^] # Re: Honteuses pubs pour les voitures
Posté par ptit_tux . En réponse au journal Honteuses pubs pour les voitures. Évalué à 2.
Il faut faire quelque chose et les 8000 morts et x blessé par an justifient des actions.
C'est l'évalution du problème qu'il faut relativiser. Si c'était la catastrophe qu'on entend partout, pourquoi la France à l'espérance de vie la plus importante ?
Il y a presque autant de sucides "réussis" que de morts sur la route.
Les morts dans les hopitaux suite à une infection nosocomiale fait dans les 10 000 morts/ans.
Les accidents domestiques font autant de morts que la route.
Sur le discours, on ne peut pas faire dans le deux poids deux mesures. Un barouffe du diable pour la route et rien ou presque pour d'autres domaines qui font autant de morts. Si on ajoutes les suicides et les accidents domestiques on a le double de la route !.
[^] # Re: Honteuses pubs pour les voitures
Posté par ptit_tux . En réponse au journal Honteuses pubs pour les voitures. Évalué à -1.
Je doute grave.
Les radars aussi sont mis en fonction de la visibilité ?
Ils sont mis dans les lignes droites où il y a aucun danger pour être sûr de te faire "avoir". L'idéal est en bas d'une côte...
Je dis ça mais des contraventions il en faut. La route ce n'est pas le far west.
> La réduction de la vitesse qui endort les conducteurs c'est l'argument le plus ridicule que j'ai jamais entendu.
Prends une bonne voiture (si t'as les moyens), va sur l'autoroute A5 où il n'y a pratiquement personne un jour de beau temps. A 130 km/h tu t'emmerdes grave de chez grave et t'as le sentiment que la limitation à 130 est vraiment stupide. A 130 km/h, tu passes ton temps à regarder le paysage et pas la route. A 160 km/h, comme il y a plus d'"animation", tu regardes plus la route, t'es plus vigilent et j'ai pas l'impression que les risques sont plus élevés.
Le problème de l'A5, c'est qu'il y a plein de radars (cette autoroute est parfaite pour les flics). Alors je préfère prendre l'A7 à 130 et prendre des risques car le traffic est dense et avec plein de camion que de prendre l'A5 en toute sécurité à 160 km/h mais risquer probablement une prune (à 130 je risque l'endormissement et l'accident grave).
[^] # Re: Honteuses pubs pour les voitures
Posté par ptit_tux . En réponse au journal Honteuses pubs pour les voitures. Évalué à 1.
L'avion est l'un des moyens de transport le plus sûr... et il y a moins de risque sur autoroute que sur départementale. Le rapport est au minimum de 3.
Ce n'est pas si simple. Ce qu'il faut en priorité, c'est diminuer le nombre d'accidents comme dans l'aviation. Un avion qui se crash, c'est un drame dans 95 % des cas. Un avion est une grosse merde lors d'un accident mais l'avion fait peu d'accident. Donc l'avion va à la vitesse qu'il veut si les conditions le permettent. Le seul accident du concorde, n'était pas à mach 2 :-).
Il y a beaucoup plus d'accident sur autoroute à cause de l'endormissement, de l'inattention que de la vitesse. Et pourquoi se fixer sur les excès de vitesse sur autoroute alors que ça fait très très peu de morts ou blessés et c'est sans comparaison avec l'alcool ou les accidents sur départementale ou en ville ?
> aucune voiture ne supporte un accident à 130km/h
Dépend de l'accident. Mais contre un mur c'est vrai.
> des crash tests qui sont réalisés rappelont le à 36km/h
C'est pas 56 km/h ?
Petite recherche google : http://www.ifrance.com/rouxel/PageO14.html(...)
- "Les voitures sont projetés à 64 km/h (La directive européenne prévoit "uniquement" 56 km/h) contre une barrière métallique déformable. 40% de la voiture uniquement (coté conducteur) heurte la barrière."
64 km/h et 40 % du véhicule et avec une voiture moderne, tu t'en tires (mais pas avec le sourire et ça dépend des voitures). Ce type de choc est comme si deux voitures allaient l'une vers l'autre à 64 km/h et se heurtaient avec 40 % de recouvrement. Ou que l'une des deux voitures était arrêtée et l'autre allait à 128 km/h ...
Mais comme c'est contre une barrière déformable... avec une barrière rigide (un mur) et à 64 km/h (ou 56) il y a d'énorme risque.
Comme on ne sait pas sur quoi on va taper, il faut rester attendif (s'endormir à 130 km/h ou même 90 est une catastrophe !), modérer sa vitesse, et il faut éviter en premier les excès ... de confiance que les excès de vitesses réglementaires qui font seulement mal au porte-feuille.
[^] # Re: Honteuses pubs pour les voitures
Posté par ptit_tux . En réponse au journal Honteuses pubs pour les voitures. Évalué à 1.
C'est l'infrastructure routière (et le comportement des conducteurs) qui fait le plus diminuer le nombre d'accident et non les aides à la conduite qui sont souvent utilisé comme des aides pour aller vite.
# Propagande pro-grèves
Posté par ptit_tux . En réponse au journal Propagande anti-grèves. Évalué à 3.
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 2.
C'est rapide, même très rapide en période de forte demande. Lors de la sortie de mandrake 9.1 c'était le moyen le plus rapide et fiable (inutile de tester une dizaine de mirroir pour en trouver un rapide).
> plus sur
Sauf utiliser les signatures GPG comme quand tu utilises un mirroir ou kernel.org. Bittorrent vérifie ton download avec md5sum.
En plus, ça soulage les mirrors. Il n'y a aucun problème dans l'utilisation de bittorrent et c'est dans l'esprit du libre. Tu downloades et ce que tu as downloadé est uploadé par les autres. Tu participes à la diffusion du noyau. Laissez tourner bittorrent quelque minutes après le download :-)
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 2.
http://www.lerhaupt.com/linux.html(...) (chercher devlabel)
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 4.
Le problème doit être ailleurs.
La différence entre rc8 et final est le minimum du minimum :
http://www.fr.kernel.org/pub/linux/kernel/v2.4/testing/incr/patch-2(...)
diff -urN linux-2.4.21-rc8/Makefile linux-2.4.21/Makefile
--- linux-2.4.21-rc8/Makefile 2003-06-13 07:54:36.000000000 -0700
+++ linux-2.4.21/Makefile 2003-06-13 07:54:41.000000000 -0700
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 21
-EXTRAVERSION = -rc8
+EXTRAVERSION =
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 2.
Le 2.4.21-0.18mdk est sorti le 4 juin et le 2.4.21 officiel le 13. Donc « sérieusement », à part ipot pour faire ça, je vois pas.
$ rpm2cpio kernel-2.4.21.0.18mdk-1-1mdk.src.rpm | cpio -t
linux-2.4.20.tar.bz2
patch-2.4.21-pre4.bz2
C'est un 2.4.21-pre4 qui est sorti vers janvier février 2003.
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 5.
Oui, Mandrake a récupéré le 2.4.21 officiel il y a 3 mois avec ipot ( http://kadreg.free.fr/ipot/(...) ) .
- pardon ?
- DEHORS ----> []
# Linux 2.5.71 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 2.
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 1.
Enfin, les corrections et ajout de driver que tu annonces sont d'un mois environ. Soit en pleine phase rc.
Pour info, les patchs Alan sont là :
http://www.fr.kernel.org/pub/linux/kernel/people/alan/(...)
C'est toujours comme ça, un noyau n'est jamais parfait et la com entre les devs non plus. C'est la vie... mais globalement ça roule.
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 2.
[^] # Re: Linux 2.4.21 est sorti
Posté par ptit_tux . En réponse à la dépêche Linux 2.4.21 est sorti. Évalué à 1.
[^] # Re: Fork d'XFree86
Posté par ptit_tux . En réponse à la dépêche Fork d'XFree86. Évalué à 7.
Faut le savoir.
> Tu vois ou que je parles de invente ou code en premier ?
Tu dis : "notre stack TCP/IP est 100% made in MS" . Ça sous entend que la pile tcp/ip utilisée partout (et non seulement MS) a été faite par MS. Je voulais souligner que c'était faut.
Dire "notre stack" sur dlfp pour parlé de la stack MS, c'est pas évident à comprendre.
[^] # Re: Fork d'XFree86
Posté par ptit_tux . En réponse à la dépêche Fork d'XFree86. Évalué à 10.
Maintenant, il faut clairement dire que telle ou telle techno est obsolète. Il faut étendre le protocole X11 (qui date de plusieurs milliers d'année informatique) pour supporter des nouvelles technos sans que ce soit "ugly".
[^] # Re: Fork d'XFree86
Posté par ptit_tux . En réponse à la dépêche Fork d'XFree86. Évalué à 5.
> Le hic etant que notre stack TCP/IP est 100% made in MS
Quand tu dis "notre stack", tu parles des utilisateurs qui comme toi utilise Windows ?
Parce que tcp/ip, c'est pas ms qui l'a inventé ni codé en premier.
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 8.
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 8.
que ce soit NGPL, NTPL ou autre, que ce soit fait dans Linux ou la libc, j'en ai strictement rien à foutre. Je dis seulement que je fait confiance au dev de linux de la libc de binutils (bref tout ceux que ça regarde) ... pour faire le bon choix.
J'ai bien compris que pour NGPL et NPTL Linux 2.5 fourni le nécessaire et que c'est la libc qui fait la différence.
Mais je répète, je n'y connait rien en thread et j'ai pas envis de rentrer dans ce débat.
J'ai rebondi sur un commentaire plus haut :
- "Donc, au 6 mars 2002, NGPT était déjà inclu dans le noyau. Quel retour arrière!"
Et encore plus haut http://linuxfr.org/comments/193027.html(...) :
- "RH veux imposer la NPTL"
Je voulais dire que redhat ne va rien imposer. C'est les developpeurs qui vont faire le choix, que ce choix peut évoluer en fonction des développements (c'était pour le "retour arrière" (qui n'en est pas un, c'est pas la peine de t'énerner) et que je leur fait confiance pour ce choix.
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 8.
Je réagissait à ça :
> > Mais si NGTL est meilleur, je fais confiance à l'intelligence des developpeurs Linux pour l'utiliser
>
> http://www.kernelnewbies.org/status/Status-06-M(...) Donc, au 6 mars 2002, NGPT était déjà inclu dans le noyau. Quel retour arrière!
Simplement pour dire que le système qui restera sera le globalement meilleur et que si les dev ont fait "retour arrière" c'est peut-être pour les raisons que j'ai donné. Mais ok, j'ai oublié le "peut-être" et ma phrase ne reflète pas ce que je pensais.
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 8.
Tu viens de découvrir qu'en développement rien n'est figé. C'est pas forcément l'avis des devs qui a changé. C'est NPTL qui a évoluer, c'est NGPT qui n'a pas tenu ces promesses, etc...
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 8.
Est généralement plus performant. Il n'est pas toujours plus performant.
De plus, c'est un bench réalisé par le team NGTL. Le bench a été peut-être (je dis bien "peut-être") choisi car il favorise NGTL. C'est de bonne guerre :-)
Mais si NGTL est meilleur, je fais confiance à l'intelligence des developpeurs Linux pour l'utiliser. D'ailleur côté noyau il y a rien à faire et côté glibc, nptl est un "add-on". Donc soit tu fournis NPTL ou NGPL. Personnellement, NPTL ou NGTL, je m'en balance ccoommppllèètteemmeenntt du moment que j'ai le meilleur et qu'il est sous GPL (ce qui est le cas pour les deux).
Notes aussi :
- "No changes were made to the kernel patches and thanks to the NPTL effort, all changes required to run NGPT on the latest 2.5.x kernels are already included."
C'est redhat qui "mène" NPTL et ils ne "retiennent" pas NGTL. Si NGTL est meilleur que NPTL pour rapport à leur besoin, aux besoins de leurs clients, redhat prendra NGTL et NPTL va mourrir. C'est la vie du free software, impitoyable...
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 7.
[^] # Re: bug review
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 7.
- je ne vois pas d'outil pour transférer mes partitions sur LVM
[^] # Re: Test de la RedHat 9
Posté par ptit_tux . En réponse à la dépêche Test de la RedHat 9. Évalué à 8.
C'est stable j'ai un rh9 depuis 1 semaine et ça roule nickel. Par contre qui y a des vieille appli que je doit lancer avec ENV LD_ASSUME_KERNEL=2.4.1 .
> Si il s'avere que la NPTL rende le système plus instable qu'autre chose, ça sera un argument de plus en faveur de Mandrake.
C'est pas de savoir si nptl est stable qui t'interesse. Ce que tu veux, c'est savoir si tu peux en faire un argument en faveur de Mandrake.
Ben t'as pas de chance car nptl sera dans la prochaine Mandrake.