Vous allez tomber sur le Chapitre 4, 1er paragraphe:
"In 2002, TPC-C database measures found that a Linux based system was faster than a Windows 2000 based system. More specifically, an HP ProLiant DL580 with 32 Intel Xeon 900MHz CPUs running Oracle 9i R2 Enterprise edition ran faster running on a stock Red Hat Linux Advanced Server than on Microsoft Windows 2000 Advanced Server. You can see the Linux and Windows reports; note that HP did not modify the Linux kernel to get these results."
Il y a des liens sur cet article, suivez les jusqu'aux PDFs vous verez alors les résultats chiffrés.... "Linux" se débrouille mieux que W2K.. et HP certifie ne même pas avoir "tuné" le kernel pour ça.
Je n'ai malheureusement pas eu le bonheur de récuperer la totalité de mes études lors du départ de mon ancienne société où j'avais fait ces comparatifs là.
Par contre, je n'ai pas le souvenir d'une telle différence entre Oracle/NT et Oracle/RH!!... C'est cependant vrai que sous Linux (Debian pour mes tests), j'avais toujours des résultats plus rapides mais c'était de l'ordre de 10% hein, pas 200%.
Il est cependant indéniable qu'Oracle est vraiment plus souple à gérer sous Unix que sous Windows. Et c'est la véritable raison qui me fait préferer Unix à Windows pour Oracle.
Un exemple tout bête: sous windows quand tu veux faire une sauvegarde à froid (comprendre copie des fichiers de la bdd, une fois celle ci complètement fermée) d'une BD, t'est obligé d'attendre qques minutes que Windows "libère" les fichiers. Autrement, lorsque tu copies les fichiers, ils te jette parceque un "autre processus utilise actuellement le fichier'"!! Sous Unix c'est immédiat. Des que la Bd est fermée, tu peux copier les fichiers dessuite.
Sinon, Oracle sous NT, Unix ou autre (VMS par ex) c'est le MEME PRODUIT. C'est en tout cas ce que je constate depuis 98 que je fais mumuse avec Oracle. Et c'est ce qui ce dit dans les classes d'Oracle University.
Je regrette juste un truc, c'est l'installer graphique en Java qui est là depuis la 8i... C'est franchement n'importequoi et ça n'emène que des emmerdes, notament sous unix.
Sans parler des problemes de compatibilité, vu qu'Oracle est livré avec des objets pré-compilés dans une vieille glibc, et que pour pouvoir les linker, il faut installer les compat-* ...
Sinon, une fois le stade pas toujours simple de l'install d'Oracle sur linux (pour cela, utilisez et abusez de http://staff.in2.hr/denis/oracle/(...) Denis Klaric à fait un super travail...), Oracle sous Linux c'est un pur bonheur: stabilité et performance d'Unix avec la souplesse de Linux.....
J'en ai juste assez de devoir supporter Flash pour pouvoir naviguer sur le net. Il en va de tous les formats propriétaires, ça me révulse.
Je suis souvent sur des machines où il n'y a pas X d'installé et je navigue alors avec w3m, d'où le ras le bol.
Je supporterais les sites qui proposent du Flash à partir du moment où une alternative est proposée, ce qui montre qu'on a au moins le respect de la différence. Là ce n'est pas le cas.
Alors quand il s'agit d'un site qui veut promouvoir le libre ou l'Open Source, ça me fait d'autant plus râler.
Alors pensez ce que vous voulez, mais ce commentaire tenais plus d'un dégoût que d'un commentaire juste pour faire chier.
Veuillez toutesfois accepter mes excuses, tant il est vrai que le commentaire n'apportait rien à la nouvelle.
PG tire complètement parti des plates-formes SMP de part son architecture.
C'est le cas d'Oracle sous Unix (dont Linux). Oracle est composé d'un ensemble de processus qui sont dédiés à des tâches bien particulières.
Sous windows par contre, mise à part la toute derniere mouture de la 9i Database, qui serait multi-threadée vraiment (pas testé, d'où le conditionnel), Oracle est monolithique. Donc, Oracle sous Windows ne tire pas parti du SMP.
Cluster:
*******
Existant sous Oracle depuis longtemps.
A l'étude sous PostgreSQL, c'est dans la TODO list, en priorité "URGENT"!
Pour Sybase, je ne connais pas du tout, je laisse le soin à d'autres pour la comparaison
Je rejoins les remarques de Pierre sur le RAWFS d'Oracle. C'est effectivement archaïque et à éviter à tout prix.
Sauf dans le cas des clusters Oracle, ou le RAWFS est obligatoire, pour ce que j'en sais. Dans le cas des clusters, il se pose en effet bon nombre de problèmes complexes et Oracle par ce biais, contrôle absolument toutes les IOs.
-*-
Je ne résiste pas à la tentation de faire part de ma petite expérience à tous ici:
1) Que dire de PostgreSQL?
C'est une SGBDR (et aussi OO pour ceux que ça interresse) robuste et fiable. Les possibilités d'extension sont extraordinaires, tant par la qualité et le nombre de fonctionalités avancées. Je suis DBA Oracle au quotidien, depuis plusieurs années, et je suis sans cesse emerveillé par PostgreSQL, tant par les performances qu'on peut en tirer que par sa souplesse d'utilisation.
2) Une anecdote sur les performances comparées Oracle / PG
Pour la petite histoire, je fus jadis le "consultant base de données" d'une SS2L (sniff...) . Un "client grand compte" était intérressé par une migration Oracle 7.3.4 sous NT4 SP6 vers PostgreSQL 7.2 sous Red Hat 7. Nous devions obtenir des performances au maximum 1,5 fois celle d'Oracle. Au final, nous avons obtenu:
- temps identiques à Oracle sur des SELECT complexes
(dont portage des formes CONNECT BY)
- temps 1,33 fois à Oracle sur des traitements lourds nocturnes par batch..
Sur ce dernier point, il s'agissait de porter un programme représentatif de l'ensemble à migrer. Le programme était à l'origine en PRO*C, nous l'avons naturellement porté en ECPG. L'isofonctionalité était parfaite, jusque dans l'affichage lors de l'exécution du programe (merci à Sebastien, il se recconaîtra...).
Nous avons juste souffert à cause des curseurs à bind variables, par exemple:
SELECT toto, tata, tutu
FROM table
WHERE toto = :id;
:id est la bind variable.
Eh bien, A L'EPOQUE PostgreSQL ne permettait pas cela. A chaque ouverture de notre curseur, PG re-parsait l'ordre et donc re calculait le plan d'exécution, d'où le surcout par rapport à Oracle, qui lui ne parse et calcule le plan d'exécution qu'à la 1ere ouverture du curseur. D'ou le 33% de temps perdu en plus...
Depuis la 7.3 PG sait maintenant faire cela (PREPARE et EXECUTE statment...), donc il faudrait reccomencer cette partie...
...TO BE CONTINUED...
3) La formation Oracle comparé à PG
Il faut en effet plusieurs semaines de formation pour commencer à comprendre et maîtriser Oracle, alors qu'il faut quelques jours pour maîtriser PostgreSQL.
De même pour le tuning. Sous Oracle, il est compliqué, vraiment. Mais d'un autre côté, il est plus fin, on maîtrise plus de choses, même si au final on se rends compte que pour que la base Oracle marche mieux, il faut lui donner plus plus toujours plus de mémoire!
Comme le dit Bruce MOMJIAN, PostgreSQL est finalement un SGBD qui n'a pas besoin de beaucoup de tuning. Et c'est tant mieux!
(cf son article sur le hardware tuning).
4) Les benchmarks
Je voulais enfin ajouter qu'il ne faut pas croire les benchmark. J'ai personellement abandonné toute idée de comparer les performances des SGBD entre eux: aucun ne fonctionnant de la même façon, ils ont tous leurs forces et leurs faiblesses. Il faut arrêter de comparer des pommes et des bananes.
Le seul benchmark qui tienne la route, c'est d'essayer les performances de son application sur tel SGBD ou tel autre. En fonction de ce que l'on veut faire, tel SGBD sera plus approprié que tel autre.
Je pense que l'on peut toujours demander mais je crois que je devine la réponse, non? ;-)
Quand on descend le libre comme ça, c'est qu'on a des raisons pour le faire il me semble. Ca n'est jamais gratuit.
Les raisons sont diverses et variées, ça peut aller du pigiste aigri parcequ'il n'arrive pas à s'en sortir à la maison avec son système linux - bien souvent par manque de méthode et de réelle envie de s'investir, autrement, on lit les docs ;-) -
... et ça peut aller jusqu'à des intêrets financiers communs entre éditeurs de magasines et éditeurs de logiciels. Bien souvent, il suffit de parcourir un magazine pour comprendre qui le soutient: voir les publicités par exemple :-)
Ca fait un bout de temps que je me dis qu'on est nul en communication, tous autant que nous sommes. C'est vraiment le pb de notre communauté, on sait pas communiquer.
Je pense aussi qu'on n'est presque pas présent dans les médias de masse (hors Linux mag, Login...) On devrait y etre bien plus!..
Je suis toujours surpris lorsque je fais des démos linux à des amis ou autres. Linux est tout simplement inconnu du grand public, à l'inverse de Windows. Pire, les gens pensent que Windows est obligatoire pour faire tourner un PC!
Ayez tous à l'esprit que chaque fois que vous faites découvrir Linux à quelqu'un, c'est le Logiciel Libre qui avance, parceque cette personne contribuera _peut être_ dans 1 mois, 1 an ou 10 ans.
Cherchez autour de vous, il y a forcément des utilisateurs pour lesquels vous vous êtes dits un jour " mince... si il(elle) savait qu'avec XtrucMuche on peut faire mieux... " . C'est à cecis que vous devez faire une démo...
Mais ton pb m'interpelle. Peut-on en savoir plus sur ton probleme? Je trouve cela très bizzare. La version 7.3 a de meilleures perfs encore au niveau global que la 7.2.
Ca m'interresserait grandement que tu mettes ici les explain plan de la requete. Celui de la 7.2 et celui de la 7.3
Enfin, je trouve que c'est domage de descendre une release parceque tu as eu un souci pontuel sur une recette dans une base. C'est pas franchement honnête je pense et c'est manquer un peu de respect pour le travail formidable de l'équipe de PG.
La critique que tu fais de PostgreSQL m'indigne sur plusieurs points
* Le pb d'index corrompus
Tu ne précises pas la version de PostgreSQL ni les détails de la machine sur laquelle ce problème peut intervenir. J'aimerais que tu nous précise tout cela. Je me demande aussi si tu as personnellement eu ce problème, ou si tu relates juste cela comme ça...
D'ailleurs, qui a eu ce problème, et en quelles circonstances?...
En 3 années d'utilisation intensive de PostgreSQL, cela ne m'est jamais arrivé personnellement. Pas meme chez les clients ou j'installe et administre les bases PG.
* la partoche remplie: boom Pg explose
C'est complètement faux. PostgreSQL s'arrête tout simplement. Il faut alors déplacer les fichiers de la bdd et la restarter, un processus de recovery se met alors en marche et remet les choses d'aplomb...
* la partoche remplie:
AMHA, si tu en arrives là c'est que tu ne sais pas administrer une base de données. Le manque d'espace disque est néfaste à tout système de base de données pas seulement PostgreSQL. Quand cela arrive, c'est caractéristique d'une installation non pensée à l'avance et surtout pas suivie comme il se doit.
J'aurais aimé avoir donc l'avis d'un vrai DBA sur Firebird, plutot que le tien.
* Interbase Public License
Tu parles d'une license! Pas la peine de rajouter à ce qui est dit dans les autres commentaires que ton post malheureux a suscité...
Du bon FUD en gros, et un total irrespect des contributeurs PG qui font un travail formidable et qui ont fait tant évoluer PG ces deux dernières années.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche PostgreSQL : le plein de nouvelles. Évalué à 1.
J'ai retrouvé qques liens:
Je vous donne le point d'entrée:
http://www.doc.ic.ac.uk/~sue/475/oss_fs_why.html(...)
A partir de là cherchez le mot "oracle"
Vous allez tomber sur le Chapitre 4, 1er paragraphe:
"In 2002, TPC-C database measures found that a Linux based system was faster than a Windows 2000 based system. More specifically, an HP ProLiant DL580 with 32 Intel Xeon 900MHz CPUs running Oracle 9i R2 Enterprise edition ran faster running on a stock Red Hat Linux Advanced Server than on Microsoft Windows 2000 Advanced Server. You can see the Linux and Windows reports; note that HP did not modify the Linux kernel to get these results."
Il y a des liens sur cet article, suivez les jusqu'aux PDFs vous verez alors les résultats chiffrés.... "Linux" se débrouille mieux que W2K.. et HP certifie ne même pas avoir "tuné" le kernel pour ça.
Bonne lecture!
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche PostgreSQL : le plein de nouvelles. Évalué à 1.
Par contre, je n'ai pas le souvenir d'une telle différence entre Oracle/NT et Oracle/RH!!... C'est cependant vrai que sous Linux (Debian pour mes tests), j'avais toujours des résultats plus rapides mais c'était de l'ordre de 10% hein, pas 200%.
Il est cependant indéniable qu'Oracle est vraiment plus souple à gérer sous Unix que sous Windows. Et c'est la véritable raison qui me fait préferer Unix à Windows pour Oracle.
Un exemple tout bête: sous windows quand tu veux faire une sauvegarde à froid (comprendre copie des fichiers de la bdd, une fois celle ci complètement fermée) d'une BD, t'est obligé d'attendre qques minutes que Windows "libère" les fichiers. Autrement, lorsque tu copies les fichiers, ils te jette parceque un "autre processus utilise actuellement le fichier'"!! Sous Unix c'est immédiat. Des que la Bd est fermée, tu peux copier les fichiers dessuite.
Sinon, Oracle sous NT, Unix ou autre (VMS par ex) c'est le MEME PRODUIT. C'est en tout cas ce que je constate depuis 98 que je fais mumuse avec Oracle. Et c'est ce qui ce dit dans les classes d'Oracle University.
Je regrette juste un truc, c'est l'installer graphique en Java qui est là depuis la 8i... C'est franchement n'importequoi et ça n'emène que des emmerdes, notament sous unix.
Sans parler des problemes de compatibilité, vu qu'Oracle est livré avec des objets pré-compilés dans une vieille glibc, et que pour pouvoir les linker, il faut installer les compat-* ...
Sinon, une fois le stade pas toujours simple de l'install d'Oracle sur linux (pour cela, utilisez et abusez de http://staff.in2.hr/denis/oracle/(...) Denis Klaric à fait un super travail...), Oracle sous Linux c'est un pur bonheur: stabilité et performance d'Unix avec la souplesse de Linux.....
... un régal :-)
[^] # Re: Evénements à Montpellier entre le 17 et le 22 mars 2003
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche Evénements à Montpellier entre le 17 et le 22 mars 2003. Évalué à -1.
J'en ai juste assez de devoir supporter Flash pour pouvoir naviguer sur le net. Il en va de tous les formats propriétaires, ça me révulse.
Je suis souvent sur des machines où il n'y a pas X d'installé et je navigue alors avec w3m, d'où le ras le bol.
Je supporterais les sites qui proposent du Flash à partir du moment où une alternative est proposée, ce qui montre qu'on a au moins le respect de la différence. Là ce n'est pas le cas.
Alors quand il s'agit d'un site qui veut promouvoir le libre ou l'Open Source, ça me fait d'autant plus râler.
Alors pensez ce que vous voulez, mais ce commentaire tenais plus d'un dégoût que d'un commentaire juste pour faire chier.
Veuillez toutesfois accepter mes excuses, tant il est vrai que le commentaire n'apportait rien à la nouvelle.
JPaul
# Re: Evénements à Montpellier entre le 17 et le 22 mars 2003
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche Evénements à Montpellier entre le 17 et le 22 mars 2003. Évalué à -4.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche PostgreSQL : le plein de nouvelles. Évalué à 4.
****
PG tire complètement parti des plates-formes SMP de part son architecture.
C'est le cas d'Oracle sous Unix (dont Linux). Oracle est composé d'un ensemble de processus qui sont dédiés à des tâches bien particulières.
Sous windows par contre, mise à part la toute derniere mouture de la 9i Database, qui serait multi-threadée vraiment (pas testé, d'où le conditionnel), Oracle est monolithique. Donc, Oracle sous Windows ne tire pas parti du SMP.
Cluster:
*******
Existant sous Oracle depuis longtemps.
A l'étude sous PostgreSQL, c'est dans la TODO list, en priorité "URGENT"!
Pour Sybase, je ne connais pas du tout, je laisse le soin à d'autres pour la comparaison
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche PostgreSQL : le plein de nouvelles. Évalué à 10.
Sauf dans le cas des clusters Oracle, ou le RAWFS est obligatoire, pour ce que j'en sais. Dans le cas des clusters, il se pose en effet bon nombre de problèmes complexes et Oracle par ce biais, contrôle absolument toutes les IOs.
-*-
Je ne résiste pas à la tentation de faire part de ma petite expérience à tous ici:
1) Que dire de PostgreSQL?
C'est une SGBDR (et aussi OO pour ceux que ça interresse) robuste et fiable. Les possibilités d'extension sont extraordinaires, tant par la qualité et le nombre de fonctionalités avancées. Je suis DBA Oracle au quotidien, depuis plusieurs années, et je suis sans cesse emerveillé par PostgreSQL, tant par les performances qu'on peut en tirer que par sa souplesse d'utilisation.
2) Une anecdote sur les performances comparées Oracle / PG
Pour la petite histoire, je fus jadis le "consultant base de données" d'une SS2L (sniff...) . Un "client grand compte" était intérressé par une migration Oracle 7.3.4 sous NT4 SP6 vers PostgreSQL 7.2 sous Red Hat 7. Nous devions obtenir des performances au maximum 1,5 fois celle d'Oracle. Au final, nous avons obtenu:
- temps identiques à Oracle sur des SELECT complexes
(dont portage des formes CONNECT BY)
- temps 1,33 fois à Oracle sur des traitements lourds nocturnes par batch..
Sur ce dernier point, il s'agissait de porter un programme représentatif de l'ensemble à migrer. Le programme était à l'origine en PRO*C, nous l'avons naturellement porté en ECPG. L'isofonctionalité était parfaite, jusque dans l'affichage lors de l'exécution du programe (merci à Sebastien, il se recconaîtra...).
Nous avons juste souffert à cause des curseurs à bind variables, par exemple:
SELECT toto, tata, tutu
FROM table
WHERE toto = :id;
:id est la bind variable.
Eh bien, A L'EPOQUE PostgreSQL ne permettait pas cela. A chaque ouverture de notre curseur, PG re-parsait l'ordre et donc re calculait le plan d'exécution, d'où le surcout par rapport à Oracle, qui lui ne parse et calcule le plan d'exécution qu'à la 1ere ouverture du curseur. D'ou le 33% de temps perdu en plus...
Depuis la 7.3 PG sait maintenant faire cela (PREPARE et EXECUTE statment...), donc il faudrait reccomencer cette partie...
...TO BE CONTINUED...
3) La formation Oracle comparé à PG
Il faut en effet plusieurs semaines de formation pour commencer à comprendre et maîtriser Oracle, alors qu'il faut quelques jours pour maîtriser PostgreSQL.
De même pour le tuning. Sous Oracle, il est compliqué, vraiment. Mais d'un autre côté, il est plus fin, on maîtrise plus de choses, même si au final on se rends compte que pour que la base Oracle marche mieux, il faut lui donner plus plus toujours plus de mémoire!
Comme le dit Bruce MOMJIAN, PostgreSQL est finalement un SGBD qui n'a pas besoin de beaucoup de tuning. Et c'est tant mieux!
(cf son article sur le hardware tuning).
4) Les benchmarks
Je voulais enfin ajouter qu'il ne faut pas croire les benchmark. J'ai personellement abandonné toute idée de comparer les performances des SGBD entre eux: aucun ne fonctionnant de la même façon, ils ont tous leurs forces et leurs faiblesses. Il faut arrêter de comparer des pommes et des bananes.
Le seul benchmark qui tienne la route, c'est d'essayer les performances de son application sur tel SGBD ou tel autre. En fonction de ce que l'on veut faire, tel SGBD sera plus approprié que tel autre.
My 2 cents.
[^] # Re: Droit de réponse ?
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche Programmez ! Un numéro spécial pour discréditer le logiciel libre.. Évalué à 9.
Quand on descend le libre comme ça, c'est qu'on a des raisons pour le faire il me semble. Ca n'est jamais gratuit.
Les raisons sont diverses et variées, ça peut aller du pigiste aigri parcequ'il n'arrive pas à s'en sortir à la maison avec son système linux - bien souvent par manque de méthode et de réelle envie de s'investir, autrement, on lit les docs ;-) -
... et ça peut aller jusqu'à des intêrets financiers communs entre éditeurs de magasines et éditeurs de logiciels. Bien souvent, il suffit de parcourir un magazine pour comprendre qui le soutient: voir les publicités par exemple :-)
Ca fait un bout de temps que je me dis qu'on est nul en communication, tous autant que nous sommes. C'est vraiment le pb de notre communauté, on sait pas communiquer.
Je pense aussi qu'on n'est presque pas présent dans les médias de masse (hors Linux mag, Login...) On devrait y etre bien plus!..
Je suis toujours surpris lorsque je fais des démos linux à des amis ou autres. Linux est tout simplement inconnu du grand public, à l'inverse de Windows. Pire, les gens pensent que Windows est obligatoire pour faire tourner un PC!
Ayez tous à l'esprit que chaque fois que vous faites découvrir Linux à quelqu'un, c'est le Logiciel Libre qui avance, parceque cette personne contribuera _peut être_ dans 1 mois, 1 an ou 10 ans.
Cherchez autour de vous, il y a forcément des utilisateurs pour lesquels vous vous êtes dits un jour " mince... si il(elle) savait qu'avec XtrucMuche on peut faire mieux... " . C'est à cecis que vous devez faire une démo...
[^] # Re: Sortie de PostgreSQL V7.3
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche Sortie de PostgreSQL V7.3. Évalué à 1.
Mais ton pb m'interpelle. Peut-on en savoir plus sur ton probleme? Je trouve cela très bizzare. La version 7.3 a de meilleures perfs encore au niveau global que la 7.2.
Ca m'interresserait grandement que tu mettes ici les explain plan de la requete. Celui de la 7.2 et celui de la 7.3
Enfin, je trouve que c'est domage de descendre une release parceque tu as eu un souci pontuel sur une recette dans une base. C'est pas franchement honnête je pense et c'est manquer un peu de respect pour le travail formidable de l'équipe de PG.
Cordialement,
[^] # Re: indexes corrompus ?
Posté par Jean-Paul ARGUDO (site web personnel) . En réponse à la dépêche Sortie du SGBD Firebird en version 1.0 finale. Évalué à 10.
* Le pb d'index corrompus
Tu ne précises pas la version de PostgreSQL ni les détails de la machine sur laquelle ce problème peut intervenir. J'aimerais que tu nous précise tout cela. Je me demande aussi si tu as personnellement eu ce problème, ou si tu relates juste cela comme ça...
D'ailleurs, qui a eu ce problème, et en quelles circonstances?...
En 3 années d'utilisation intensive de PostgreSQL, cela ne m'est jamais arrivé personnellement. Pas meme chez les clients ou j'installe et administre les bases PG.
* la partoche remplie: boom Pg explose
C'est complètement faux. PostgreSQL s'arrête tout simplement. Il faut alors déplacer les fichiers de la bdd et la restarter, un processus de recovery se met alors en marche et remet les choses d'aplomb...
* la partoche remplie:
AMHA, si tu en arrives là c'est que tu ne sais pas administrer une base de données. Le manque d'espace disque est néfaste à tout système de base de données pas seulement PostgreSQL. Quand cela arrive, c'est caractéristique d'une installation non pensée à l'avance et surtout pas suivie comme il se doit.
J'aurais aimé avoir donc l'avis d'un vrai DBA sur Firebird, plutot que le tien.
* Interbase Public License
Tu parles d'une license! Pas la peine de rajouter à ce qui est dit dans les autres commentaires que ton post malheureux a suscité...
Du bon FUD en gros, et un total irrespect des contributeurs PG qui font un travail formidable et qui ont fait tant évoluer PG ces deux dernières années.