En fait, sur beaucoup de tes points, tu compares deux manières de fonctionner différentes : MySQL intègre plein de trucs dans la base alors que PostgreSQL a plus une philosophie de faire du SGBDR et c'est tout. MySQL est plus pragmatique ce qui a certains avantages, au mépris parfois de la cohérence, du fait que le comportement soit correct et du respect des standards.
Après, il est difficile de savoir ce qui va mieux te convenir. Je me suis limité ici aux points que tu as cités vu que ça doit être ce qui est important pour toi, je suppose.
> MySQL
--- Commande SHOW trés simple et pratique
Mouaif. C'est lesquels de SHOW que tu trouves pratique ?
--- Planificateur de tache intégré
Il existe pgAgent qui est configurable via pgAdmin III. Mais effectivement, ça demande un composant complémentaire. Personnellement, je préfère faire ce genre de trucs via une crontab.
--- Pas mal polyvalent grace aux différents moteurs, une base de donnée de cache par exemple n'a pas besoin de transactions
Well, une base de données, c'est fait pour conserver des données. Si tu veux du cache ou des sessions, memcached et sharedance sont probablement plus adaptés. Encore une fois, on retrouve la philosophie UNIX (une tâche, un outil) dans PostgreSQL.
--- Trés utilise, énormement de documentation
Je ne pense pas qu'on puisse le retenir contre PostgreSQL. La doc PostgreSQL officielle est vraiment une mine d'informations et le wiki commence à être bien rempli aussi.
--- Mode Embedded
Oui, ça, PostgreSQL ne le fait pas et ne le fera probablement jamais. Ce n'est pas son objectif.
Si tu as besoin de cela, il faut soit aller voir côté Sqlite, soit effectivement rester sur du MySQL.
--- Possibilités de monitoring énorme
C'est à dire ?
PostgreSQL a quelques outils pas mal non plus : des plugins Munin, un plugin Nagios très bien fichu, pgFouine...
--- Les bases de données prennent peut de place par apport a Postgresql
Euh ? Ca me paraît sorti du chapeau ça. J'ai notamment vu pas mal de gens se plaindre de la place prise par des bases InnoDB. Après, je dois avouer que le stockage est rarement un problème pour nous donc je n'ai jamais fait trop gaffe.
Je n'ai jamais eu l'impression d'avoir une taille déconnante, notamment parce que le stockage des champs en PostgreSQL est très optimisé et très souple, mais encore une fois, jamais trop fait gaffe.
--- Systeme de backup complexe dues aux differents moteurs, mais la 6.0 corrige ca si j'ai bien comprit
Attention quand même aux annonces MySQL. La 5.1 vient juste de sortir après 3 ans de développement. Je ne suis pas sûr qu'il faille compter sur une 6.0 rapidement (même si tout le monde espère qu'ils ne vont pas refaire le coup de la 5.1).
> PostgreSQL
> Ce que je n'aime pas :
--- Pas la possibilité de désactiver l'aspect relationnel sur certaines tables (pour une table de cache par exemple)
Répondu plus haut, PostgreSQL ne traite effectivement pas cette problématique, il y a d'autres outils pour ça.
--- Pas de commande show, donc certaines commandes sont assez complexes
Tu prends mal le problème là. Je ne suis pas persuadé que ce soit plus complexe mais même si ça l'est, si tu choisis un SGBDR pour un bout de temps, tu vas te construire ton petit référentiel de vues qui te remontent toutes les informations que tu veux comme tu les veux.
Je serai curieux de savoir ce que tu trouves complexe tout de même. Les versions récentes (genre la 8.3) sont vraiment simples à manipuler de ce point de vue là. Le fait que ce soit du SQL rend en plus les manipulations très simples et cohérentes : on peut faire des vraies requêtes.
--- Performances moins bonne que Mysql (surtout avec MyISAM quand l'on a pas besoin de transactionnel)
Dépend de ce que tu appelles performances. Ca dépend beaucoup de la complexité de tes requêtes, de ton nombre d'utilisateurs concurrents.
Bref, difficile à dire sans avoir une idée de la typologie de charge qu'il y aura.
> Indice : regarde du côté des "neufs et occasion", ie le "marketplace"... la plupart des CD que je m'achète y sont entre 5€ et 10€, y compris les nouveautés.
Ouais bof. Je dois avouer que les trucs qui viennent des US ou d'Australie, je préfère acheter un minimum local quand même (même si ça reste Amazon).
Amazon et la Marketplace, c'est quand même un tout petit peu différent.
Accessoirement, autant je trouve que la fnac abuse sur les prix Internet, autant ça ne me semble pas déconnant que ce soit plus cher en boutique. C'est un service de proximité et c'est aussi bien sympa de traîner dans les rayons de temps en temps.
> Et ? Tu as des preuves que le bilan est au désavantage de l'industrie des ayant-droits ? Des preuves non achetées par l'industrie des ayant-droits ?
Faut quand même un peu arrêter de se leurrer, hein... Il est clair que le téléchargement fait acheter plus de CDs à certaines personnes mais il est clair aussi que ça permet à plein d'autres de ne rien acheter du tout.
Certains avant écoutaient simplement la radio donc ça ne change rien mais il y a quand même aussi des gens qui auraient acheté des albums avant, une fois de temps en temps et qui n'en achètent plus du tout.
J'ai déjà discuté avec Debout Sur Le Zinc aussi lors d'un concert, les mecs sont sympas, ouverts et certainement pas bouffés par la propagande des maisons de disques. S'ils te disent qu'ils vendent moins de disques et qu'ils doivent monter le prix de leurs concerts pour s'y retrouver, il y a plutôt des chances que ce soit vrai.
Après, on peut dire que leur nouvel album est ptet moins bien que le précédent, que la répartition des recettes n'est pas terrible... Reste qu'il y a un malaise, même chez des artistes pas outrageusement commerciaux, et qu'on a plutôt intérêt à essayer de le comprendre qu'autre chose.
CirKus vendredi, c'était pareil. Le mec a juste demandé à ce qu'on achète l'album si on aimait et a dit qu'il n'était pas cher (et c'est vrai, ils sortent leur album à un prix raisonnable). Il a aussi ajouté avec un brin d'humour qu'ils étaient affamés (le concert était vraiment fun sans prise de tête donc c'est bien passé). Ce n'est vraiment pas un groupe commercial mais ils ont fait passer le message quand même. Plutôt proprement, sans parler de téléchargement, sans dire que c'était mal, juste en nous donnant envie, en vendant leurs CDs à un prix raisonnable, et en restant avec les gens pour discuter et dédicacer les albums.
Après, la propagande foireuse des maisons de disques n'aide pas à avoir une vision claire des choses...
Ils se plaignaient déjà que ça baissait alors que les chiffres de ventes globales en France présentés dans le magazine de la FNAC étaient en hausse :).
On a quand même le droit d'être plus intelligent qu'eux et essayer d'avoir un discours mesuré.
Ceci dit la solution n'est clairement pas celle qu'ils envisagent.
> L'époque des cassettes audios et des minidiscs est-elle déjà si loin qu'on ne se rappelle déjà plus ce qui se pratiquait ?
Il y a une différence tout de même entre avoir un pote qui a le CD (donc limite de rayon de proximité par rapport à ton cercle d'amis - élargi, on est d'accord) et qu'il suffise d'avoir un mec dans le monde qui ait le CD et le partage. Il y a une question d'échelle et de côté pratique aussi.
Je pense qu'on peut admettre tout de même que ça a un impact plus important dans un sens (la découverte avant achat) et dans l'autre (le fait d'avoir capacité à ne plus payer).
L'information sur l'équilibre entre les deux n'est pas forcément évidente à avoir alors que c'est clairement la clé de l'édifice.
Après, il est vrai que les discours à deux balles des maisons de disques, sans chiffres, sans analyse... me saoulent.
Leur manière d'affirmer les choses de manière péremptoire est tellement débile qu'on est obligé de remettre en cause ce qu'ils disent alors qu'il est possible qu'ils aient quand même raison, vu que quelques artistes plutôt non commerciaux font aussi passer le message. Mais on ne le saura jamais :/.
Accessoirement, quand bien même les ventes de disque baisseraient, ça peut être dû à plein de facteurs :
- canal de distribution obsolète (c'est quand même hallucinant qu'on ne puisse pas bêtement écouter un album avant d'acheter : à la fnac de Lille, un moment (je ne sais pas si c'est toujours le cas), tu ramenais n'importe quel CD, ils te l'ouvraient et te le faisaient écouter).
- non adéquation à la demande ;
- mise en valeur d'artistes pourris et formatés au lieu de pousser les gens qui font des choses qui sortent de l'ordinaire ;
- réchauffement climatique et montée du niveau des océans ;
- Ingrid Bétancourt prisonnière en Colombie (mais du coup, ça devrait repartir).
Ceci dit, malgré tout, je pense que la musique gratuite se banalise (y compris via des moyens légaux types Deezer) et qu'il ne serait pas un mal de lui redonner ses lettres de noblesse et de redonner aux gens envie de dépenser de l'argent dans la culture. Les achats influencent aussi ce que vont produire les maisons de disque.
> Cette loi est inique : stupide, car elle s'attaque à un problème factice - et injuste, car elle ne poussera certainement pas les gens à acheter plus, au contraire
Je n'ai jamais dit le contraire. Comme je le disais dans mon post un peu longuet plus haut, ce n'est pas comme ça qu'on va donner envie aux gens d'acheter. Je trouve cette loi toute aussi débile que toi et ça me gêne de plus en plus cette manière de présumer les gens coupables.
Et au delà de ça, j'en ai vraiment marre de ces saloperies de vidéo anti piratage au début des DVDs que j'ai *achetés* (et au prix fort régulièrement...). Le plus drôle, c'est que si je les avais téléchargés, je n'aurai pas ce message :). Ah ben non, c'est pas drôle, en fait.
Tout ça pour dire qu'on doit être globalement d'accord, je pense. Juste que je me dis qu'il y a quand même un malaise (et c'est peut-être juste un problème de communication, de compréhension et de bonne volonté) et qu'il faudra le règler d'une manière ou d'une autre.
Je ne suis pas vraiment sûr que tu veuilles une réponse vu le ton péremptoire mais allons-y quand même.
Déjà, sur Amazon, les nouveautés sont plus entre 12 et 17 euros qu'à 5 euros. Pour en acheter pas mal sur ce site, je pense en avoir une bonne idée.
Après, on est presque d'accord sauf qu'on prend le problème complètement différemment.
Le téléchargement partage pour faire découvrir est bien évidemment positif pour les artistes et en particulier pour les petits groupes. Quand ça devient le moyen naturel de se procurer un album, ça devient un souci. Je ne suis pas personnellement sûr que ça en soit un pour l'instant (notamment car ça aide pas mal d'artistes à se faire connaître) mais si ça continue comme ça évolue en ce moment (que les gens considèrent la musique et les films comme quelque chose de gratuit), ça en sera un dans pas si longtemps.
Il n'y a clairement pas que du téléchargement partage pays des bisounours. Il y en a aussi pas mal de "si je peux avoir un truc gratos, pourquoi payer ?". Le premier est ultra positif pour tout le monde, le deuxième, pas vraiment.
Et l'évolution, c'est clairement que le produit musical devienne plus attractif (cf mon post plus haut sur ce sujet : facilité d'accès, artwork, jolie pochette, bonus sympa, live...) mais aussi que les gens fassent l'effort de se rendre compte que c'est normal de payer pour que les artistes continuent à faire leur taf et que les maisons de disque continuent à prendre des risques sur certains artistes (clair qu'elles ne le font pas toutes, mais certaines le font, et plutôt bien).
Ca n'empêche pas le partage et la découverte : juste que quand on aime vraiment, on ait le réflexe d'acheter.
Yep. On peut effectivement faire ce constat sans trop se tromper.
Le truc, c'est de comprendre qu'on a tous intérêt à trouver une solution qui satisfasse tout le monde, maisons de disque, artistes et "consommateurs" (je n'aime pas le terme pais pas trouvé mieux). Sinon, la production musicale va vite devenir hyper gavante.
Opposer les méchantes maisons de disque aux méchants "consommateurs" ne mènera pas bien loin... Il faut que tout le monde comprenne qu'il y aura des compromis à faire pour chacun. Et si les compromis peuvent éviter d'être du côté des petits artistes et de lisser la production musicale, je pense que ce sera un bien pour tout le monde.
Oui, c'est clair qu'il y a largement du progrès à faire, pour plein d'artistes.
Je suis entièrement d'accord que ne pas fournir de moyen de découvrir l'album est vraiment dommage. Un des rares artistes qui a tout compris à ce niveau, c'est Wax Tailor (que je conseille chaudement en albums et concerts) : le player sur son site permet d'écouter toutes les chansons de ses albums.
Les sites de vente en ligne en France sont vraiment pourris pour ça (supaire 30 secondes du début de la chanson en 20kb/s \o/). Amazon US est pas mal à ce niveau-là.
Ceci dit, soyons clair : ce sera toujours plus chiant d'acheter un album que de le télécharger gratuitement :
- il faut aller sur un site (même si on peut aussi faire une appli) ;
- il faut rentrer son numéro de CB ;
- et puis, au final, ça coûte des sous quand même.
C'est un peu pareil au supermarché, ça irait plus vite de sortir directement sans payer, ça évite de faire la queue. Même si tu enlèves les queues, il reste toujours le paiement qui prend un peu de temps.
Bref, même si tu enlèves tous les trucs lourds, que tu rends le truc attractif (cf mon très très long post plus haut), reste au final qu'il faut un petit effort qui demande que les gens aient un comportement responsable vis à vis des artistes qu'ils aiment et, franchement, on est largement tous gagnant à acheter les albums des artistes qu'on aime.
Réduire cet effort semble déjà une bonne piste à suivre. Reste après à avoir confiance en la nature humaine : je laisse chacun avoir son opinion sur ce point :).
Lien Télécharger cet album (j'ai pris la Fnac parce que je connais, je suis sûr que plein d'autres sites le proposent).
Bref, pareil que si je voulais acheter un album normal.
Prendre l'exemple d'un site mal gaulé (ce n'est pas forcément le groupe qui pond le site d'ailleurs) pour généraliser est peut-être un peu facile, non ?
Quelle solution as-tu à proposer qui règlerait le problème ?
L'inquiétude du "il faut bien qu'on mange" est compréhensible. On parle de petits groupes là, pas de Céline Dion. Moi, c'est pareil, je taffe, j'aime bien être payé.
Dire que les artistes n'ont qu'à se rémunérer sur les concerts, c'est supposer qu'ils ne peuvent vivre qu'avec ça. Je ne suis pas sûr que ce soit bien le cas pour ce genre de groupes. On n'est pas tant que ça à aller à des concerts et la place est souvent juste un peu plus cher que le prix d'un album. Ca aurait été une question intéressante à leur poser d'ailleurs.
Accessoirement, les patterns de consommation de musique que je vois se généraliser sont plus tournés vers le single que vers l'album. Je ne suis pas sûr que ça aide à remplir les salles de concert : les gens ont plus l'air obsédés par un titre que par un artiste ou un album. Quand on coupe ce lien, ça devient difficile de créer un lien "affectif" avec un artiste ou un album et d'avoir le déclic concert.
La licence globale est, à mon sens, un truc relativement pervers. Le calcul de la répartition se fera forcément par rapport à des indicateurs chiffrés qui mettront en difficulté les petits artistes. Qu'on compte les passages à la radio, le nombre de spectateurs au concert ou le nombre de téléchargements, il y aura forcément un souci pour eux... Alors que justement, ce sont probablement eux qui bénéficient le plus du fait qu'on achète vraiment les CD. Je pense qu'ils sont de loin les moins "piratés".
Accessoirement, ça me ferait profondément chier de sponsoriser la production des albums des gros artistes alors que je n'écoute pas ça du tout : je veux pouvoir choisir les artistes que j'aime et dont j'achète les albums, bref où mon argent va.
Le téléchargement et Deezer sont vraiment chouettes pour découvrir des trucs (je ne compte pas le nombre de groupes que j'ai découvert comme ça) et ensuite acheter les albums et aller les voir en concert. Mais ça a aussi l'effet pervers d'enlever de la valeur à la musique : on considère vite que c'est quelque chose de gratuit. Bref, ça ne marche que si les gens sont globalement corrects.
Accessoirement, les Deezer-like enferment l'écoute musicale dans un cadre géré par des sociétés et des contrats. J'aime quand même être libre d'avoir les albums chez moi et pouvoir écouter ce que je veux, quand je veux, autant de fois que je le veux. C'est donc vraiment un moteur de découverte mais je ne suis pas sûr d'avoir envie que tout aille dans ce sens.
La musique libre, c'est pareil, on va compter sur le fait que les gens sont corrects. Dans leur majorité, ils ne le sont même pas alors que c'est interdit. J'ai des doutes sur le fait que la musique libre puisse se généraliser en étant vraiment viable pour les artistes (ie qu'ils ne puissent faire que ça, sans avoir un vrai boulot à côté) - je ne parle pas de cas particuliers qui peuvent s'en sortir mais bien de l'écosystème global.
Faire un parallèle avec le logiciel libre est assez caduque car la majorité des modèles économiques du LL sont basés sur le service. Accessoirement, actuellement en tout cas, on a une minorité qui paye pour que la majorité puisse se servir et une grosse partie de la production de LL qui se fait bénévolement. Et je ne m'étendrais pas sur la difficulté de faire de la vraie édition de logiciels avec une approche services.
La seule solution non répressive est l'éducation et le fait que les gens aient un comportement responsable. Maintenant, vu ce que je vois autour de moi comme comportements chez des gens de mon âge (donc vers les 30 ans), je me dis que ce n'est pas gagné de compter là-dessus...
Le principe de production par les consommateurs qui se base sur un single (je précise single) me semble aussi assez dangereux. Ca ne me semble pas forcément la meilleure idée pour créer des choses chouettes. On va vite se retrouver avec un tas d'albums bidons produits parce qu'un single sexy et easy listening a plu à la majorité des gens sur un site. Je ne dis pas que ce n'est pas intéressant comme concept mais, à mon avis, il y a un petit peu de réflexion à avoir si on ne veut pas se retrouver avec une production musicale bien pauvre.
Perso, les albums que j'écoute le plus sur le long terme sont ceux qui ne m'ont pas forcément plu à la première écoute et qu'il a fallu que je découvre vraiment (ou que j'attende le bon moment).
Reste qu'à mon sens, il faudrait au moins arriver à quelques avancées :
- avoir un prix qui soit plus bas. Perso, je me ferai quand même plus plaisir avec des albums vers 15 euros plutôt que vers 20 euros (voire parfois beaucoup plus pour des trucs un peu vieux). Idem pour les DVD. Typiquement, je suis allé voir CirKus en concert vendredi : ancien CD à 10E, nouveau à 12E avec des pochettes plutôt chouettes : et ben ça fait envie. J'avais déjà l'ancien album, je n'ai pas hésité deux secondes avant d'acheter le deuxième.
- changer la manière de communiquer sur la musique et mettre plus en valeur les trucs qui sortent de l'ordinaire, plutôt que le nième groupe à la mode. Ceci dit, j'ai l'impression que ça évolue quand même un peu dans le bon sens de ce côté là - les diffusions de festival à la télé sont vraiment bien pour ça.
- si c'est bien l'oeuvre qu'on achète (et tout le monde a l'air d'accord là-dessus), nous permettre après achat de la récupérer sur n'importe quel support à un prix qui tiennent compte des précédents achats. Ca s'applique à la musique en ligne et à la VOD. Pour prendre l'exemple des séries américaines par exemple, on paye aussi cher en VOD qu'à acheter le coffret DVD donc si tu veux regarder un peu rapidement les séries légalement et avoir le DVD après, tu payes 2 fois...
- faire des belles pochettes, que l'objet soit sexy et donne envie de l'avoir.
- vendre les enregistrements live : qu'est-ce que j'aimerai retrouver le son de certains concerts !
- avoir capacité à acheter tous les albums possibles sous quelque forme que ce soit et ne pas galérer à trouver certains groupes.
- arrêter avec cette connerie de DRM et ces conneries de messages anti-piratage au début des DVDs qui ne gênent que les gens qui achètent les albums et les DVDs.
- ne plus supposer que tout téléchargement est illégal. On est au moins un certain nombre à acheter des CDs et des DVDs en pagaille. Malheureusement, on a beau dire ça, le comportement de la majorité des gens n'aide pas vraiment à changer cette vision...
En conclusion, arrêtons aussi de diaboliser les artistes qui se posent des questions sur leur avenir, c'est relativement compréhensible et il n'y a pas forcément d'issue super simple qui ne demande pas un compromis des deux côtés. La situation est loin d'être toute blanche ou toute noire, il faut aussi que les gens évoluent vers des comportements de consommation responsable.
On peut déjà les y inciter en leur donnant envie, reste qu'il y a aussi un chemin à faire du côté des gens qui écoutent et regardent la production des artistes.
1. Toujours faire ce genre d'opération dans un screen : si tu es déconnecté, tu te reconnectes et tu fais un screen -d -r pour récupérer ton screen
2. xargs est ton ami : ls | xargs rm -f
(à faire dans le bon répertoire, évidemment)
Le problème avec ta méthode est que bash récupère la liste de tous les fichiers en développant le * puis qu'il essaie de passer la liste directement en argument de rm.
Le souci, c'est que là, tu n'es pas dans une situation normale : tu n'arrives pas à stabiliser la nouvelle mouture de ton produit étendard depuis 3 ans (ça ne représente pas forcément grand chose dans d'autres secteurs mais vu la vitesse de l'évolution logicielle et matérielle, c'est énorme).
La date limite est archi dépassée en fait et tu es dans une situation inquiétante.
Clairement, la décision du manager est marketing et politique mais elle peut se comprendre compte tenu du contexte. Et elle n'est pas si déconnante vu que Monty dit lui-même que cette version est de toute manière moins buggée que la 5.0 sur les fonctionnalités existantes (et compte tenu du nombre de releases mineures de la 5.0, ça donne une bonne idée de la qualité de la GA de la 5.0).
Dégager les nouvelles fonctionnalités instables, ce n'est pas trop jouable vu que des gens tournent déjà avec cette version (et même si ça semble peu excusable, MySQL est très fautif à mon sens de part la manière de présenter les produits sur le site et la numérotation de version utilisée) et qu'elles sont annoncées depuis deux ans. Et on n'a pas l'impression que les efforts de développement soient vraiment portés sur la 5.1 alors que tout le monde parle déjà de la 6 et de ses nouveaux moteurs qui vont être trop bien. Accessoirement, tu traînes aussi un paquet de bugs majeurs qui ne sont même pas dans les nouvelles fonctionnalités de la nouvelle version...
Bref, pour moi, la décision est vraiment la conséquence directe de la politique de développement et de marketing de MySQL (ajout de fonctionnalités dans un état loin d'être stable sur une branche de release, release de 5.1.x alors que le produit n'est clairement pas fini, annonces trop tôt des nouvelles fonctionnalités qui font qu'il est difficile de se rétracter).
Encore une fois, je défend un peu la position du manager parce que c'est un peu le mauvais flic dans l'histoire. C'est le modèle développement/marketing complet qui est à revoir. Typiquement, ce qui se passe du côté de PostgreSQL est plutôt un modèle du genre à ce niveau (même si du coup, on en paye le prix en marketing).
Rétrospectivement, je suis un peu étonné qu'on fasse tout un pataquès sur la sortie d'une 5.1 avec des bugs alors qu'en fait le message induit par ce que dit Monty est que c'était encore pire sur la 5.0. Il s'agit donc plus d'une politique inscrite dans le temps qu'un truc épisodique. Autant, je comprends presque la décision pour la 5.1 compte tenu du contexte, autant c'est beaucoup plus discutable pour la sortie de la 5.0, où le contexte était très différent.
"A moins que tu ne parle des scripts qu'on doit se bricoler pour ajouter les sets et les séquences au fur et à mesure que la structure de la / des base change ? (mais dans ce cas il s'agit plutôt d'un problème de configuration et d'"interface utilisateur" que d'intégration dans pg non ?)."
Non, je ne parle même pas de Slony mais de la réplication par log shipping qui demande des scripts pour gérer tout ça correctement.
"et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien"
Hmmm, un doute sur le "ça marche bien". Ca doit bien marcher dans certains cas, oui, mais la résolution de conflit dans le cas du multi master est très loin d'être trivial.
C'est là où MySQL a une approche beaucoup plus pragmatique que les autres bases. Le fait que ça marche dans la majorité des cas suffit en général.
"Si tu n'a pas les WAL depuis les tout débuts de ta base (bonjour le volume), tu dois tomber un backup puis repérer jusqu'où tu applique tes logs"
Euh, personnellement, je fais régulièrement des snapshots de la base. Donc, ce n'est pas depuis le tout début mais depuis le dernier snapshot. C'est déjà beaucoup moins long, même si ça peut effectivement déjà l'être.
"Sérieux, c'est une blague ?"
Non non. La réplication via log shipping qui saute a l'air d'être assez classique (je ne fais que répéter ce que les gens m'en ont dit - des gens en contact direct avec le problème et des gens assez variés et assez compétents pour que ça ne me paraisse pas une erreur triviale).
"Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;)"
Tu as mal compris ma phrase. Je disais justement que ça le limitait au failover donc que ça n'avait pas d'utilité en dehors de ça. On est bien d'accord là-dessus.
"J'ai cru comprendre que problème serait réglé *après* que le support pour la réplication "row based" serait intégrée, soit peut être dans 8.4, plus probablement post-8.4, quelqu'un à des nouvelles ?"
Il y a deux patches en attente d'intégration pour la 8.4 :
- un patch pour gérer la réplication standard en interne au lieu de recourir à des scripts, réplication toujours basée sur l'envoi des fichiers de WAL ;
- un patch pour permettre d'accéder au standby en lecture seule.
Après, nul ne peut parier qu'ils seront intégrés dans la 8.4.
"Il n'y a rien de spécial à « voir ». C'est juste que les selects sont beaucoup plus lents qu'ils pourraient l'être parce que les ressources disponibles ne sont pas exploitées de façon optimale."
Tu prends un peu trop les mots au pied de la lettre :). L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas. Comme je le disais, ça a un coût, tout le monde en convient, mais c'est un choix.
Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
"hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?"
Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix). Et j'ai vu plusieurs personnes avec ce même problème.
Bof comme argument. Je suis de très près les listes PostgreSQL depuis plusieurs années maintenant et je vois bien comment sont traités les bugs.
Le fait que tu ne puisses pas le vérifier sans faire un travail conséquent ne dit pas que je mens (cf plus bas pour les raisons qui font que c'est une réalité).
PostgreSQL n'a jamais eu besoin de bugtracker et les développeurs préfèrent gérer cela avec des mails. C'est leur choix... Ce choix est remis en cause régulièrement mais pour l'instant, c'est comme ça. Je suis d'accord que ça a parfois des inconvénients mais la recherche dans les archives des listes marche assez bien pour que ça ne soit pas vraiment gênant (en tous les cas, pas dans l'utilisation que j'en ai).
Et je maintiens ce que je disais pour la sortie de la 8.3.
Et la 8.4 sortira également sans bug majeur connu. C'est comme ça que ça marche depuis la nuit des temps avec PostgreSQL.
Ils reculeront la sortie le temps nécessaire s'il y a un bug connu ou enlèveront la fonctionnalité qui pose problème : il n'y a pas de deadline ou de fonctionnalités cibles imposées et la décision de publier une version est faite par les développeurs eux-même : ça fait une grosse différence.
Comme je le disais dans un autre post, ça n'empêche pas qu'il y ait de bugs découverts après la release.
"Qu'elle ne soit pas intégrée dans les sources standards de PostgreSQL n'est vraiment pas le problème cependant."
C'en est un, en fait. Il faut vraiment que ça marche out of the box sans avoir à scripter des trucs (même si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Ca ne pose pas de souci aux gens qui ont l'habitude mais ça rend cette fonctionnalité peu accessible alors qu'elle est simplissime et très robuste.
"La réplication master-master"
Mouaif. La réplication master-master pose énormément de problèmes en soi et MySQL n'est vraiment vraiment pas un modèle du genre... Clairement, il ne faut pas espérer voir arriver ça dans PostgreSQL avant très très longtemps (si ça arrive un jour).
Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
"La réplication délayée"
Mauvaise réponse au problème. Tu tomberas toujours dans le cas où, pas de bol, ton délai n'était pas suffisant. PostgreSQL répond à ce problème avec le Point In Time Recovery : tu indiques simplement le moment où tu veux t'arrêter dans le "rejouage" des logs. C'est *beaucoup* plus fiable.
"les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne"
C'est déjà le cas dans la réplication via log shipping. Evidemment le fait que le slave ne soit pas accessible en lecture pour l'instant le limite au failover. J'espère que cette limitation sera levée en 8.4.
Slony n'est clairement pas un modèle du genre de simplicité et il est, à mon sens, assez difficile à imposer en dehors du cadre de sa propre boîte (typiquement, je ne le propose pas au client dont on exploite les plates-formes).
Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Clairement, un hot standby est suffisant pour 99% des besoins et je préfère très largement avoir un failover très fiable qu'un truc bancal qui me permet de faire du readonly sur un autre noeud. Note bien que je suis d'accord que c'est limitant pour certains besoins, juste que je préfère des fondations solides, ça se casse moins souvent la gueule :).
Pour l'histoire du cache disque, c'est l'argument qu'on entend souvent. Je dois avouer qu'on voit assez peu de cas où ça pose réellement un problème. Clairement, PostgreSQL se focalise sur faire du SGBDR, pas sur faire un OS au dessus de l'OS. Ca a parfois un coût, tout le monde en convient, mais c'est finalement assez sain.
Sinon, tu es gentil sur le "les performances de MySQL ne progressent plus au-delà de 8 cpus", j'ai vu plus de benchs où ça s'écroulait dès que le nombre de CPU et le nombre de connexions augmentaient et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte. Le fait de ne pas avoir sorti de version en 3 ans (et donc de ne pas avoir pu s'adapter à la nouvelle mode des multi-cores) joue sans doute un peu là-dessus.
Les points qui posent souci, à mon sens, sont principalement :
1- la réplication via log shipping qui n'est pas intégré (nécessité de scripts externes). Ceci dit, elle est par contre beaucoup plus stable que la réplication MySQL par log shipping ;
2- impossibilité d'accéder en lecture au slave dans le cas de réplication par log shipping ;
3- quelques requêtes type le SELECT COUNT(*) FROM table qui sont lentes comparées à du Oracle (MyISAM ne compte pas vraiment à cause du table locking et le fait que ce ne soit pas MVCC et InnoDb a le même problème que PostgreSQL) ;
4- le fait que la locale et l'encoding soient globaux et par par colonne ;
5- le partitionning vraiment vraiment pas top.
Beaucoup de ces points vont être améliorés par le travail fait sur la 8.4 (en tous les cas, si tous les patches en attente sont intégrés) :
- les points 1 et 2 ont des patches en attente ;
- le point 3 devrait bénéficier du travail sur la visibility map fait en 8.4 mais ne sera pas résolu avant la 8.5 au moins ;
- le point 4 est très partiellement traité : on pourra avoir une locale par base de données ;
- le point 5 n'a pas vraiment bougé (il y a eu du boulot de fait mais je ne pense pas que ce sera intégré).
Ca n'empêche pas PostgreSQL d'être mon SGBDR de prédilection mais il faut aussi être au courant de ses points faibles pour l'apprécier pleinement.
"Il suffit de consulter le changelog de la 8.3.5 pour voir que la branche 8.3 est sortie avec des problèmes sévères."
Bof. Le principal problème corrigé dans la 8.3.5 (et qui a principalement motivé sa sortie) est un problème introduit dans la version mineure d'avant et qui n'était pas présent dans la 8.3.0. Mais c'est clair qu'il y avait des bugs dans la 8.3 comme dans toutes les versions précédentes.
La grosse différence est que la 8.3 est sortie sans bug grave connu. Après il y a toujours des bugs comme dans tout logiciel et ils sont découverts et corrigés au fur et à mesure.
Pour voir arriver les bugs sur les mailing lists, ils ne restent en général pas longtemps non corrigés, raison pour laquelle PostgreSQL peut encore se passer d'un bugtracker, d'ailleurs.
A mon sens, il est un peu facile de mettre la responsabilité de la release sur le management. MySQL n'avait pas connu de version majeure depuis 3 ans, ce qui est énorme. Et même s'ils prennent des libertés douteuses sur les ajouts de fonctionnalités/modifications de comportement dans le cadre de releases mineures (cf le changelog de la 5.0), il n'en reste pas moins que c'était une situation assez critique, que ce soit au niveau technique ou au niveau de l'image.
Accessoirement, rappelons tout de même que MySQL AB avait fait une tentative de RC de la 5.1 il y a environ un an, avant que Sun prenne le contrôle.
Il y a clairement un *énorme* problème technique dans le fait de ne pas arriver à stabiliser une version en 3 ans et, pour moi, la responsabilité du fiasco de la 5.1 est surtout du côté des décisions techniques qui ont été prises (implémentation, volonté d'ajouter trop de choses d'un coup... ?). Le problème de base est vraiment là : impossible de stabiliser la 5.1 (que ce soit parce que c'est effectivement injouable ou parce que tous les efforts sont déjà mis dans la 6). La décision à prendre était grosso modo : soit la publier, soit abandonner et attendre la sortie de la 6 qui reste un truc très très flou pour l'instant. Je comprends un peu la position du management même si c'est une mauvaise décision technique. Accessoirement, ce n'est pas comme si la 5.0 était exempt d'un gros tas de bugs gênants à sa sortie : d'ailleurs, le discours de Monty Widenius est limite encore plus inquiétant pour ceux qui font tourner la 5.0 actuellement : "If you are a new user trying out MySQL for the first time, you should use MySQL 5.1; At least it's better than the MySQL 5.0 community version which has not been updated for some time.".
Pour ce qui est du futur de MySQL, il me semble que Falcon est abandonné suite au départ de son créateur et que l'avenir est plutôt du côté de Maria, le nouveau moteur développé notamment par Monty Widenius. Peu importe sa qualité, il mettra de toute manière un peu de temps à se stabiliser et à faire preuve de la robustesse qu'on attend de la part d'un moteur de SGBD généraliste.
AMHA, MySQL est dans une situation assez critique actuellement :
- même le créateur de MySQL a l'air de croire très moyennement dans la qualité de cette 5.1
- la sortie de la 5.1 ne règle pas le problème de fond de la base actuelle de code : ils ont laissé un paquet de problèmes en suspens et, s'ils étaient triviaux à régler, ça fera longtemps que ce serait fait
- l'avenir semble être à l'adoption d'un tout nouveau moteur qui va forcément faire preuve de jeunesse dans les premiers temps (et l'abandon de Falcon n'arrange pas trop les choses de ce côté-là)
- des forks apparaissent : notamment drizzle dont l'orientation montre assez bien que peu de gens croient dans ce qui a été ajouté dans la 5.1 (et dans la 5.0)
Bref, il semble que la course à l'ajout de fonctionnalités à tout va montre ses limites et qu'il va falloir prendre une autre orientation rapidement. Personnellement, j'aurai préféré que cette version 5.1 soit une version 5.0 où les fonctionnalités existantes de la 5.0 sont toutes implémentées dans leur totalité, sans limites bizarres et sans bugs bizarres. C'était le principal problème AMHA.
Pour l'instant, ils arrivent encore à faire en sorte que ces problèmes ne soient pas trop visibles mais ça commence à se savoir : on commence notamment à avoir des clients qui se posent des questions à ce sujet, ce qui est plutôt pour me plaire.
C'est une release, difficile à dire si elle contient de nouvelles mises à jour de sécurité. En général, les releases mettent un peu de temps à se préparer donc ça ne paraît pas déconnant.
Il faut bien noter le "The Debian project is pleased to announce the eighth and final update of its old stable distribution Debian GNU/Linux 3.1", ce qui semble bien en accord avec la news dont je postais le lien.
Tu confonds le temps séparant la sortie de deux versions avec la période de support : Sarge est encore supportée.
En l'occurrence, elle n'est plus censée l'être depuis fin mars (pour moi les mises à jour de sécurité sont un élément clé du support) : http://www.fr.debian.org/News/2008/20080229
Ce que je voulais dire, c'est que ta phrase expliquant les changements de nom par "Ne plus être un projet principalement de recherche, mais être un SGBD utile et de qualité." n'a pas grand chose à voir avec la réalité.
C'est une conséquence du boulot des gens, c'est tout.
Il y a beaucoup de raccourcis et de contre-vérités dans ce que tu dis.
Sur la partie historique, je t'invite à lire : http://www.postgresql.org/about/history qui te donnera un éclairage différent (et un peu plus proche de la réalité).
J'utilise PostgreSQL depuis 2001 donc mes raisons ne sont pas forcément celles des gens qui font le pas maintenant.
Ce que j'ai apprécié et que j'apprécie toujours c'est :
- la qualité du moteur, les fonctionnalités, la qualité des outils (client psql, EXPLAIN ANALYZE très détaillé, log_min_duration_statement en ms et pas en s)
- la cohérence de l'ensemble : les fonctionnalités présentes marchent, pas de limitation bizarre suivant des paramètres bizarres (types de champs, taille de la base, moteur choisi...), tout est cohérent
- la qualité des échanges avec la communauté (réactivité, niveau des échanges, implication des acteurs, retours d'expérience) et l'accessibilité des développeurs
- compatibilité entre les versions : pas de modification posant des problèmes de compatibilité entre versions mineures, éviter au maximum les nouveaux mots clés réservés (toujours embêtant de se retrouver avec un nom de champ qui est maintenant un mot clé réservé - c'est du vécu avec certains autres SGBDR)
- les performances et la scalabilité
- la qualité et la clarté de la documentation, bien séparée par version (pratique quand on fait de l'archéologie chez des clients)
- le fait que ce soit un vrai projet communautaire
- la transparence et l'absence de discours marketing qui a tendance à biaiser les choses. Là, c'est clair et net, y compris les aspects négatifs et on ne parle pas des fonctionnalités présentes dans des versions alpha/beta/gamma comme étant des acquis
- les trucs en plus : les types avancés et leurs index associés, PostGIS
- les progrès faits version après version que ce soit en terme de performances, de scalabilité, d'usabilité ou de fonctionnalités
J'ai probablement oublié des choses mais c'est ce qui me vient à l'esprit là maintenant.
Certains points sont purement absolus et pas relatifs à d'autres bases de données, notamment ce qui concerne la communauté, n'étant pas impliqué dans les communautés des autres bases de données du marché.
Certains points ont également leur revers comme l'absence de marketing, ça se sent au niveau de la notoriété.
La RHEL 5 est en PHP 5.1.6 (et donc les clones type CentOS aussi) et ce sera la RHEL officielle pour encore quelques années. De manière générale, je trouve que c'est une mauvaise idée de passer directement au 5.2 sachant qu'une des distributions majeures en entreprise propose PHP 5.1 pour un bon bout de temps et s'engage à le maintenir longtemps.
Oui, il y a des paquets 5.2 sur divers repositories externes mais quand on peut éviter, on préfère en général les paquets maintenus par Red Hat (sinon, on perd le principal intérêt d'utiliser une distribution à cycle de maintenance très long).
En particulier, avoir besoin de mettre des paquets PHP 5.2 pour un service périphérique d'administration comme PhpPgAdmin, c'est un peu dommage.
Bref, je milite pour le support de PHP 5.1+ et j'en profite aussi pour te remercier pour ton travail sur PhpPgAdmin.
Elles sont persistantes pour la durée de vie d'un fils que tu peux ajuster comme tu le souhaites.
Elles ne sont pas partagées, elles sont complètement indépendantes de l'application (ce qui est assez logique vu qu'il n'y a pas de notion d'application) mais elles sont persistantes.
Après, il est sûr que si tu souhaites trouver une définition qui te donne raison, ça ne me pose pas plus de souci que ça...
Note bien que ce que tu disais dans ton premier commentaire est :
"Se reconnecter à Mysql pour chaque page, au LDAP ..."
ce qui est donc faux comme nous te l'avons tous indiqué.
Tu devrais relire mon commentaire dans son entier et tu verras que je ne remets pas en cause la persistance par l'utilisation d'un pool de connexions.
Utiliser un pool résout une problématique différente. Ce n'est pas le problème de la persistance que je règle avec ça, c'est le problème d'avoir beaucoup trop de connexions sur ma base qu'il n'est vraiment utile quand j'ai beaucoup de fils Apache dont certains n'ont pas spécialement besoin de la base à l'instant t.
Après, qu'un pool de connexions utilisé en direct comme ce qu'il se fait en Java soit plus intelligent et plus économe en ressources, c'est une autre histoire. Note que même dans ce cas, les implémentations classiques de pool ferment en général les connexions au bout d'un certain temps pour en réouvrir d'autres. Et que de la même manière, tu peux avoir plein de connexions suivant les besoins de ton application et son utilisation.
Cela n'empêche pas de pouvoir trouver un équilibre tout à fait satisfaisant avec du PHP en module Apache et, pour ne pas le citer, PgBouncer.
Et certains trouvent même leur équilibre sans connection pooling additionnel.
# Quelques éléments
Posté par Guillaume Smet (site web personnel) . En réponse au message Quelle base de donnée open source est la plus polyvalente ?. Évalué à 8.
Après, il est difficile de savoir ce qui va mieux te convenir. Je me suis limité ici aux points que tu as cités vu que ça doit être ce qui est important pour toi, je suppose.
> MySQL
--- Commande SHOW trés simple et pratique
Mouaif. C'est lesquels de SHOW que tu trouves pratique ?
--- Planificateur de tache intégré
Il existe pgAgent qui est configurable via pgAdmin III. Mais effectivement, ça demande un composant complémentaire. Personnellement, je préfère faire ce genre de trucs via une crontab.
--- Pas mal polyvalent grace aux différents moteurs, une base de donnée de cache par exemple n'a pas besoin de transactions
Well, une base de données, c'est fait pour conserver des données. Si tu veux du cache ou des sessions, memcached et sharedance sont probablement plus adaptés. Encore une fois, on retrouve la philosophie UNIX (une tâche, un outil) dans PostgreSQL.
--- Trés utilise, énormement de documentation
Je ne pense pas qu'on puisse le retenir contre PostgreSQL. La doc PostgreSQL officielle est vraiment une mine d'informations et le wiki commence à être bien rempli aussi.
--- Mode Embedded
Oui, ça, PostgreSQL ne le fait pas et ne le fera probablement jamais. Ce n'est pas son objectif.
Si tu as besoin de cela, il faut soit aller voir côté Sqlite, soit effectivement rester sur du MySQL.
--- Possibilités de monitoring énorme
C'est à dire ?
PostgreSQL a quelques outils pas mal non plus : des plugins Munin, un plugin Nagios très bien fichu, pgFouine...
--- Les bases de données prennent peut de place par apport a Postgresql
Euh ? Ca me paraît sorti du chapeau ça. J'ai notamment vu pas mal de gens se plaindre de la place prise par des bases InnoDB. Après, je dois avouer que le stockage est rarement un problème pour nous donc je n'ai jamais fait trop gaffe.
Je n'ai jamais eu l'impression d'avoir une taille déconnante, notamment parce que le stockage des champs en PostgreSQL est très optimisé et très souple, mais encore une fois, jamais trop fait gaffe.
--- Systeme de backup complexe dues aux differents moteurs, mais la 6.0 corrige ca si j'ai bien comprit
Attention quand même aux annonces MySQL. La 5.1 vient juste de sortir après 3 ans de développement. Je ne suis pas sûr qu'il faille compter sur une 6.0 rapidement (même si tout le monde espère qu'ils ne vont pas refaire le coup de la 5.1).
> PostgreSQL
> Ce que je n'aime pas :
--- Pas la possibilité de désactiver l'aspect relationnel sur certaines tables (pour une table de cache par exemple)
Répondu plus haut, PostgreSQL ne traite effectivement pas cette problématique, il y a d'autres outils pour ça.
--- Pas de commande show, donc certaines commandes sont assez complexes
Tu prends mal le problème là. Je ne suis pas persuadé que ce soit plus complexe mais même si ça l'est, si tu choisis un SGBDR pour un bout de temps, tu vas te construire ton petit référentiel de vues qui te remontent toutes les informations que tu veux comme tu les veux.
Je serai curieux de savoir ce que tu trouves complexe tout de même. Les versions récentes (genre la 8.3) sont vraiment simples à manipuler de ce point de vue là. Le fait que ce soit du SQL rend en plus les manipulations très simples et cohérentes : on peut faire des vraies requêtes.
--- Performances moins bonne que Mysql (surtout avec MyISAM quand l'on a pas besoin de transactionnel)
Dépend de ce que tu appelles performances. Ca dépend beaucoup de la complexité de tes requêtes, de ton nombre d'utilisateurs concurrents.
Bref, difficile à dire sans avoir une idée de la typologie de charge qu'il y aura.
[^] # Re: Refus de vendre
Posté par Guillaume Smet (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 2.
Ouais bof. Je dois avouer que les trucs qui viennent des US ou d'Australie, je préfère acheter un minimum local quand même (même si ça reste Amazon).
Amazon et la Marketplace, c'est quand même un tout petit peu différent.
Accessoirement, autant je trouve que la fnac abuse sur les prix Internet, autant ça ne me semble pas déconnant que ce soit plus cher en boutique. C'est un service de proximité et c'est aussi bien sympa de traîner dans les rayons de temps en temps.
> Et ? Tu as des preuves que le bilan est au désavantage de l'industrie des ayant-droits ? Des preuves non achetées par l'industrie des ayant-droits ?
Faut quand même un peu arrêter de se leurrer, hein... Il est clair que le téléchargement fait acheter plus de CDs à certaines personnes mais il est clair aussi que ça permet à plein d'autres de ne rien acheter du tout.
Certains avant écoutaient simplement la radio donc ça ne change rien mais il y a quand même aussi des gens qui auraient acheté des albums avant, une fois de temps en temps et qui n'en achètent plus du tout.
J'ai déjà discuté avec Debout Sur Le Zinc aussi lors d'un concert, les mecs sont sympas, ouverts et certainement pas bouffés par la propagande des maisons de disques. S'ils te disent qu'ils vendent moins de disques et qu'ils doivent monter le prix de leurs concerts pour s'y retrouver, il y a plutôt des chances que ce soit vrai.
Après, on peut dire que leur nouvel album est ptet moins bien que le précédent, que la répartition des recettes n'est pas terrible... Reste qu'il y a un malaise, même chez des artistes pas outrageusement commerciaux, et qu'on a plutôt intérêt à essayer de le comprendre qu'autre chose.
CirKus vendredi, c'était pareil. Le mec a juste demandé à ce qu'on achète l'album si on aimait et a dit qu'il n'était pas cher (et c'est vrai, ils sortent leur album à un prix raisonnable). Il a aussi ajouté avec un brin d'humour qu'ils étaient affamés (le concert était vraiment fun sans prise de tête donc c'est bien passé). Ce n'est vraiment pas un groupe commercial mais ils ont fait passer le message quand même. Plutôt proprement, sans parler de téléchargement, sans dire que c'était mal, juste en nous donnant envie, en vendant leurs CDs à un prix raisonnable, et en restant avec les gens pour discuter et dédicacer les albums.
Après, la propagande foireuse des maisons de disques n'aide pas à avoir une vision claire des choses...
Ils se plaignaient déjà que ça baissait alors que les chiffres de ventes globales en France présentés dans le magazine de la FNAC étaient en hausse :).
On a quand même le droit d'être plus intelligent qu'eux et essayer d'avoir un discours mesuré.
Ceci dit la solution n'est clairement pas celle qu'ils envisagent.
> L'époque des cassettes audios et des minidiscs est-elle déjà si loin qu'on ne se rappelle déjà plus ce qui se pratiquait ?
Il y a une différence tout de même entre avoir un pote qui a le CD (donc limite de rayon de proximité par rapport à ton cercle d'amis - élargi, on est d'accord) et qu'il suffise d'avoir un mec dans le monde qui ait le CD et le partage. Il y a une question d'échelle et de côté pratique aussi.
Je pense qu'on peut admettre tout de même que ça a un impact plus important dans un sens (la découverte avant achat) et dans l'autre (le fait d'avoir capacité à ne plus payer).
L'information sur l'équilibre entre les deux n'est pas forcément évidente à avoir alors que c'est clairement la clé de l'édifice.
Après, il est vrai que les discours à deux balles des maisons de disques, sans chiffres, sans analyse... me saoulent.
Leur manière d'affirmer les choses de manière péremptoire est tellement débile qu'on est obligé de remettre en cause ce qu'ils disent alors qu'il est possible qu'ils aient quand même raison, vu que quelques artistes plutôt non commerciaux font aussi passer le message. Mais on ne le saura jamais :/.
Accessoirement, quand bien même les ventes de disque baisseraient, ça peut être dû à plein de facteurs :
- canal de distribution obsolète (c'est quand même hallucinant qu'on ne puisse pas bêtement écouter un album avant d'acheter : à la fnac de Lille, un moment (je ne sais pas si c'est toujours le cas), tu ramenais n'importe quel CD, ils te l'ouvraient et te le faisaient écouter).
- non adéquation à la demande ;
- mise en valeur d'artistes pourris et formatés au lieu de pousser les gens qui font des choses qui sortent de l'ordinaire ;
- réchauffement climatique et montée du niveau des océans ;
- Ingrid Bétancourt prisonnière en Colombie (mais du coup, ça devrait repartir).
Ceci dit, malgré tout, je pense que la musique gratuite se banalise (y compris via des moyens légaux types Deezer) et qu'il ne serait pas un mal de lui redonner ses lettres de noblesse et de redonner aux gens envie de dépenser de l'argent dans la culture. Les achats influencent aussi ce que vont produire les maisons de disque.
> Cette loi est inique : stupide, car elle s'attaque à un problème factice - et injuste, car elle ne poussera certainement pas les gens à acheter plus, au contraire
Je n'ai jamais dit le contraire. Comme je le disais dans mon post un peu longuet plus haut, ce n'est pas comme ça qu'on va donner envie aux gens d'acheter. Je trouve cette loi toute aussi débile que toi et ça me gêne de plus en plus cette manière de présumer les gens coupables.
Et au delà de ça, j'en ai vraiment marre de ces saloperies de vidéo anti piratage au début des DVDs que j'ai *achetés* (et au prix fort régulièrement...). Le plus drôle, c'est que si je les avais téléchargés, je n'aurai pas ce message :). Ah ben non, c'est pas drôle, en fait.
Tout ça pour dire qu'on doit être globalement d'accord, je pense. Juste que je me dis qu'il y a quand même un malaise (et c'est peut-être juste un problème de communication, de compréhension et de bonne volonté) et qu'il faudra le règler d'une manière ou d'une autre.
[^] # Re: Refus de vendre
Posté par Guillaume Smet (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 2.
Déjà, sur Amazon, les nouveautés sont plus entre 12 et 17 euros qu'à 5 euros. Pour en acheter pas mal sur ce site, je pense en avoir une bonne idée.
Après, on est presque d'accord sauf qu'on prend le problème complètement différemment.
Le téléchargement partage pour faire découvrir est bien évidemment positif pour les artistes et en particulier pour les petits groupes. Quand ça devient le moyen naturel de se procurer un album, ça devient un souci. Je ne suis pas personnellement sûr que ça en soit un pour l'instant (notamment car ça aide pas mal d'artistes à se faire connaître) mais si ça continue comme ça évolue en ce moment (que les gens considèrent la musique et les films comme quelque chose de gratuit), ça en sera un dans pas si longtemps.
Il n'y a clairement pas que du téléchargement partage pays des bisounours. Il y en a aussi pas mal de "si je peux avoir un truc gratos, pourquoi payer ?". Le premier est ultra positif pour tout le monde, le deuxième, pas vraiment.
Et l'évolution, c'est clairement que le produit musical devienne plus attractif (cf mon post plus haut sur ce sujet : facilité d'accès, artwork, jolie pochette, bonus sympa, live...) mais aussi que les gens fassent l'effort de se rendre compte que c'est normal de payer pour que les artistes continuent à faire leur taf et que les maisons de disque continuent à prendre des risques sur certains artistes (clair qu'elles ne le font pas toutes, mais certaines le font, et plutôt bien).
Ca n'empêche pas le partage et la découverte : juste que quand on aime vraiment, on ait le réflexe d'acheter.
[^] # Re: Refus de vendre
Posté par Guillaume Smet (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 0.
Le truc, c'est de comprendre qu'on a tous intérêt à trouver une solution qui satisfasse tout le monde, maisons de disque, artistes et "consommateurs" (je n'aime pas le terme pais pas trouvé mieux). Sinon, la production musicale va vite devenir hyper gavante.
Opposer les méchantes maisons de disque aux méchants "consommateurs" ne mènera pas bien loin... Il faut que tout le monde comprenne qu'il y aura des compromis à faire pour chacun. Et si les compromis peuvent éviter d'être du côté des petits artistes et de lisser la production musicale, je pense que ce sera un bien pour tout le monde.
[^] # Re: Refus de vendre
Posté par Guillaume Smet (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 4.
Je suis entièrement d'accord que ne pas fournir de moyen de découvrir l'album est vraiment dommage. Un des rares artistes qui a tout compris à ce niveau, c'est Wax Tailor (que je conseille chaudement en albums et concerts) : le player sur son site permet d'écouter toutes les chansons de ses albums.
Les sites de vente en ligne en France sont vraiment pourris pour ça (supaire 30 secondes du début de la chanson en 20kb/s \o/). Amazon US est pas mal à ce niveau-là.
Ceci dit, soyons clair : ce sera toujours plus chiant d'acheter un album que de le télécharger gratuitement :
- il faut aller sur un site (même si on peut aussi faire une appli) ;
- il faut rentrer son numéro de CB ;
- et puis, au final, ça coûte des sous quand même.
C'est un peu pareil au supermarché, ça irait plus vite de sortir directement sans payer, ça évite de faire la queue. Même si tu enlèves les queues, il reste toujours le paiement qui prend un peu de temps.
Bref, même si tu enlèves tous les trucs lourds, que tu rends le truc attractif (cf mon très très long post plus haut), reste au final qu'il faut un petit effort qui demande que les gens aient un comportement responsable vis à vis des artistes qu'ils aiment et, franchement, on est largement tous gagnant à acheter les albums des artistes qu'on aime.
Réduire cet effort semble déjà une bonne piste à suivre. Reste après à avoir confiance en la nature humaine : je laisse chacun avoir son opinion sur ce point :).
[^] # Re: Refus de vendre
Posté par Guillaume Smet (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 5.
http://musique.fnac.com/a2484197/Debout-Sur-Le-Zinc-De-chary(...)
Lien Télécharger cet album (j'ai pris la Fnac parce que je connais, je suis sûr que plein d'autres sites le proposent).
Bref, pareil que si je voulais acheter un album normal.
Prendre l'exemple d'un site mal gaulé (ce n'est pas forcément le groupe qui pond le site d'ailleurs) pour généraliser est peut-être un peu facile, non ?
[^] # Re: La répression c'est pas cool?
Posté par Guillaume Smet (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 10.
L'inquiétude du "il faut bien qu'on mange" est compréhensible. On parle de petits groupes là, pas de Céline Dion. Moi, c'est pareil, je taffe, j'aime bien être payé.
Dire que les artistes n'ont qu'à se rémunérer sur les concerts, c'est supposer qu'ils ne peuvent vivre qu'avec ça. Je ne suis pas sûr que ce soit bien le cas pour ce genre de groupes. On n'est pas tant que ça à aller à des concerts et la place est souvent juste un peu plus cher que le prix d'un album. Ca aurait été une question intéressante à leur poser d'ailleurs.
Accessoirement, les patterns de consommation de musique que je vois se généraliser sont plus tournés vers le single que vers l'album. Je ne suis pas sûr que ça aide à remplir les salles de concert : les gens ont plus l'air obsédés par un titre que par un artiste ou un album. Quand on coupe ce lien, ça devient difficile de créer un lien "affectif" avec un artiste ou un album et d'avoir le déclic concert.
La licence globale est, à mon sens, un truc relativement pervers. Le calcul de la répartition se fera forcément par rapport à des indicateurs chiffrés qui mettront en difficulté les petits artistes. Qu'on compte les passages à la radio, le nombre de spectateurs au concert ou le nombre de téléchargements, il y aura forcément un souci pour eux... Alors que justement, ce sont probablement eux qui bénéficient le plus du fait qu'on achète vraiment les CD. Je pense qu'ils sont de loin les moins "piratés".
Accessoirement, ça me ferait profondément chier de sponsoriser la production des albums des gros artistes alors que je n'écoute pas ça du tout : je veux pouvoir choisir les artistes que j'aime et dont j'achète les albums, bref où mon argent va.
Le téléchargement et Deezer sont vraiment chouettes pour découvrir des trucs (je ne compte pas le nombre de groupes que j'ai découvert comme ça) et ensuite acheter les albums et aller les voir en concert. Mais ça a aussi l'effet pervers d'enlever de la valeur à la musique : on considère vite que c'est quelque chose de gratuit. Bref, ça ne marche que si les gens sont globalement corrects.
Accessoirement, les Deezer-like enferment l'écoute musicale dans un cadre géré par des sociétés et des contrats. J'aime quand même être libre d'avoir les albums chez moi et pouvoir écouter ce que je veux, quand je veux, autant de fois que je le veux. C'est donc vraiment un moteur de découverte mais je ne suis pas sûr d'avoir envie que tout aille dans ce sens.
La musique libre, c'est pareil, on va compter sur le fait que les gens sont corrects. Dans leur majorité, ils ne le sont même pas alors que c'est interdit. J'ai des doutes sur le fait que la musique libre puisse se généraliser en étant vraiment viable pour les artistes (ie qu'ils ne puissent faire que ça, sans avoir un vrai boulot à côté) - je ne parle pas de cas particuliers qui peuvent s'en sortir mais bien de l'écosystème global.
Faire un parallèle avec le logiciel libre est assez caduque car la majorité des modèles économiques du LL sont basés sur le service. Accessoirement, actuellement en tout cas, on a une minorité qui paye pour que la majorité puisse se servir et une grosse partie de la production de LL qui se fait bénévolement. Et je ne m'étendrais pas sur la difficulté de faire de la vraie édition de logiciels avec une approche services.
La seule solution non répressive est l'éducation et le fait que les gens aient un comportement responsable. Maintenant, vu ce que je vois autour de moi comme comportements chez des gens de mon âge (donc vers les 30 ans), je me dis que ce n'est pas gagné de compter là-dessus...
Le principe de production par les consommateurs qui se base sur un single (je précise single) me semble aussi assez dangereux. Ca ne me semble pas forcément la meilleure idée pour créer des choses chouettes. On va vite se retrouver avec un tas d'albums bidons produits parce qu'un single sexy et easy listening a plu à la majorité des gens sur un site. Je ne dis pas que ce n'est pas intéressant comme concept mais, à mon avis, il y a un petit peu de réflexion à avoir si on ne veut pas se retrouver avec une production musicale bien pauvre.
Perso, les albums que j'écoute le plus sur le long terme sont ceux qui ne m'ont pas forcément plu à la première écoute et qu'il a fallu que je découvre vraiment (ou que j'attende le bon moment).
Reste qu'à mon sens, il faudrait au moins arriver à quelques avancées :
- avoir un prix qui soit plus bas. Perso, je me ferai quand même plus plaisir avec des albums vers 15 euros plutôt que vers 20 euros (voire parfois beaucoup plus pour des trucs un peu vieux). Idem pour les DVD. Typiquement, je suis allé voir CirKus en concert vendredi : ancien CD à 10E, nouveau à 12E avec des pochettes plutôt chouettes : et ben ça fait envie. J'avais déjà l'ancien album, je n'ai pas hésité deux secondes avant d'acheter le deuxième.
- changer la manière de communiquer sur la musique et mettre plus en valeur les trucs qui sortent de l'ordinaire, plutôt que le nième groupe à la mode. Ceci dit, j'ai l'impression que ça évolue quand même un peu dans le bon sens de ce côté là - les diffusions de festival à la télé sont vraiment bien pour ça.
- si c'est bien l'oeuvre qu'on achète (et tout le monde a l'air d'accord là-dessus), nous permettre après achat de la récupérer sur n'importe quel support à un prix qui tiennent compte des précédents achats. Ca s'applique à la musique en ligne et à la VOD. Pour prendre l'exemple des séries américaines par exemple, on paye aussi cher en VOD qu'à acheter le coffret DVD donc si tu veux regarder un peu rapidement les séries légalement et avoir le DVD après, tu payes 2 fois...
- faire des belles pochettes, que l'objet soit sexy et donne envie de l'avoir.
- vendre les enregistrements live : qu'est-ce que j'aimerai retrouver le son de certains concerts !
- avoir capacité à acheter tous les albums possibles sous quelque forme que ce soit et ne pas galérer à trouver certains groupes.
- arrêter avec cette connerie de DRM et ces conneries de messages anti-piratage au début des DVDs qui ne gênent que les gens qui achètent les albums et les DVDs.
- ne plus supposer que tout téléchargement est illégal. On est au moins un certain nombre à acheter des CDs et des DVDs en pagaille. Malheureusement, on a beau dire ça, le comportement de la majorité des gens n'aide pas vraiment à changer cette vision...
En conclusion, arrêtons aussi de diaboliser les artistes qui se posent des questions sur leur avenir, c'est relativement compréhensible et il n'y a pas forcément d'issue super simple qui ne demande pas un compromis des deux côtés. La situation est loin d'être toute blanche ou toute noire, il faut aussi que les gens évoluent vers des comportements de consommation responsable.
On peut déjà les y inciter en leur donnant envie, reste qu'il y a aussi un chemin à faire du côté des gens qui écoutent et regardent la production des artistes.
# screen et xargs
Posté par Guillaume Smet (site web personnel) . En réponse au message Supprimer une grande quantité de fichiers impossible. Évalué à 4.
1. Toujours faire ce genre d'opération dans un screen : si tu es déconnecté, tu te reconnectes et tu fais un screen -d -r pour récupérer ton screen
2. xargs est ton ami : ls | xargs rm -f
(à faire dans le bon répertoire, évidemment)
Le problème avec ta méthode est que bash récupère la liste de tous les fichiers en développant le * puis qu'il essaie de passer la liste directement en argument de rm.
--
Guillaume
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 3.
http://blog.hagander.net/archives/128-On-the-topic-of-releas(...)
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 2.
C'était pas très clair donc je précise :
Le fait que ça marche dans la majorité des cas suffit en général *pour MySQL*.
Ce n'est pas trop ma position sur le sujet : je préfère la bonne vieille rigueur :).
[^] # Re: La situation de MySQL
Posté par Guillaume Smet (site web personnel) . En réponse au journal La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 2.
La date limite est archi dépassée en fait et tu es dans une situation inquiétante.
Clairement, la décision du manager est marketing et politique mais elle peut se comprendre compte tenu du contexte. Et elle n'est pas si déconnante vu que Monty dit lui-même que cette version est de toute manière moins buggée que la 5.0 sur les fonctionnalités existantes (et compte tenu du nombre de releases mineures de la 5.0, ça donne une bonne idée de la qualité de la GA de la 5.0).
Dégager les nouvelles fonctionnalités instables, ce n'est pas trop jouable vu que des gens tournent déjà avec cette version (et même si ça semble peu excusable, MySQL est très fautif à mon sens de part la manière de présenter les produits sur le site et la numérotation de version utilisée) et qu'elles sont annoncées depuis deux ans. Et on n'a pas l'impression que les efforts de développement soient vraiment portés sur la 5.1 alors que tout le monde parle déjà de la 6 et de ses nouveaux moteurs qui vont être trop bien. Accessoirement, tu traînes aussi un paquet de bugs majeurs qui ne sont même pas dans les nouvelles fonctionnalités de la nouvelle version...
Bref, pour moi, la décision est vraiment la conséquence directe de la politique de développement et de marketing de MySQL (ajout de fonctionnalités dans un état loin d'être stable sur une branche de release, release de 5.1.x alors que le produit n'est clairement pas fini, annonces trop tôt des nouvelles fonctionnalités qui font qu'il est difficile de se rétracter).
Encore une fois, je défend un peu la position du manager parce que c'est un peu le mauvais flic dans l'histoire. C'est le modèle développement/marketing complet qui est à revoir. Typiquement, ce qui se passe du côté de PostgreSQL est plutôt un modèle du genre à ce niveau (même si du coup, on en paye le prix en marketing).
Rétrospectivement, je suis un peu étonné qu'on fasse tout un pataquès sur la sortie d'une 5.1 avec des bugs alors qu'en fait le message induit par ce que dit Monty est que c'était encore pire sur la 5.0. Il s'agit donc plus d'une politique inscrite dans le temps qu'un truc épisodique. Autant, je comprends presque la décision pour la 5.1 compte tenu du contexte, autant c'est beaucoup plus discutable pour la sortie de la 5.0, où le contexte était très différent.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 4.
Non, je ne parle même pas de Slony mais de la réplication par log shipping qui demande des scripts pour gérer tout ça correctement.
"et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien"
Hmmm, un doute sur le "ça marche bien". Ca doit bien marcher dans certains cas, oui, mais la résolution de conflit dans le cas du multi master est très loin d'être trivial.
C'est là où MySQL a une approche beaucoup plus pragmatique que les autres bases. Le fait que ça marche dans la majorité des cas suffit en général.
"Si tu n'a pas les WAL depuis les tout débuts de ta base (bonjour le volume), tu dois tomber un backup puis repérer jusqu'où tu applique tes logs"
Euh, personnellement, je fais régulièrement des snapshots de la base. Donc, ce n'est pas depuis le tout début mais depuis le dernier snapshot. C'est déjà beaucoup moins long, même si ça peut effectivement déjà l'être.
"Sérieux, c'est une blague ?"
Non non. La réplication via log shipping qui saute a l'air d'être assez classique (je ne fais que répéter ce que les gens m'en ont dit - des gens en contact direct avec le problème et des gens assez variés et assez compétents pour que ça ne me paraisse pas une erreur triviale).
"Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;)"
Tu as mal compris ma phrase. Je disais justement que ça le limitait au failover donc que ça n'avait pas d'utilité en dehors de ça. On est bien d'accord là-dessus.
"J'ai cru comprendre que problème serait réglé *après* que le support pour la réplication "row based" serait intégrée, soit peut être dans 8.4, plus probablement post-8.4, quelqu'un à des nouvelles ?"
Il y a deux patches en attente d'intégration pour la 8.4 :
- un patch pour gérer la réplication standard en interne au lieu de recourir à des scripts, réplication toujours basée sur l'envoi des fichiers de WAL ;
- un patch pour permettre d'accéder au standby en lecture seule.
Après, nul ne peut parier qu'ils seront intégrés dans la 8.4.
"Il n'y a rien de spécial à « voir ». C'est juste que les selects sont beaucoup plus lents qu'ils pourraient l'être parce que les ressources disponibles ne sont pas exploitées de façon optimale."
Tu prends un peu trop les mots au pied de la lettre :). L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas. Comme je le disais, ça a un coût, tout le monde en convient, mais c'est un choix.
Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
"hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?"
Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix). Et j'ai vu plusieurs personnes avec ce même problème.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 1.
Le fait que tu ne puisses pas le vérifier sans faire un travail conséquent ne dit pas que je mens (cf plus bas pour les raisons qui font que c'est une réalité).
PostgreSQL n'a jamais eu besoin de bugtracker et les développeurs préfèrent gérer cela avec des mails. C'est leur choix... Ce choix est remis en cause régulièrement mais pour l'instant, c'est comme ça. Je suis d'accord que ça a parfois des inconvénients mais la recherche dans les archives des listes marche assez bien pour que ça ne soit pas vraiment gênant (en tous les cas, pas dans l'utilisation que j'en ai).
Et je maintiens ce que je disais pour la sortie de la 8.3.
Et la 8.4 sortira également sans bug majeur connu. C'est comme ça que ça marche depuis la nuit des temps avec PostgreSQL.
Ils reculeront la sortie le temps nécessaire s'il y a un bug connu ou enlèveront la fonctionnalité qui pose problème : il n'y a pas de deadline ou de fonctionnalités cibles imposées et la décision de publier une version est faite par les développeurs eux-même : ça fait une grosse différence.
Comme je le disais dans un autre post, ça n'empêche pas qu'il y ait de bugs découverts après la release.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 7.
C'en est un, en fait. Il faut vraiment que ça marche out of the box sans avoir à scripter des trucs (même si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Ca ne pose pas de souci aux gens qui ont l'habitude mais ça rend cette fonctionnalité peu accessible alors qu'elle est simplissime et très robuste.
"La réplication master-master"
Mouaif. La réplication master-master pose énormément de problèmes en soi et MySQL n'est vraiment vraiment pas un modèle du genre... Clairement, il ne faut pas espérer voir arriver ça dans PostgreSQL avant très très longtemps (si ça arrive un jour).
Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
"La réplication délayée"
Mauvaise réponse au problème. Tu tomberas toujours dans le cas où, pas de bol, ton délai n'était pas suffisant. PostgreSQL répond à ce problème avec le Point In Time Recovery : tu indiques simplement le moment où tu veux t'arrêter dans le "rejouage" des logs. C'est *beaucoup* plus fiable.
"les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne"
C'est déjà le cas dans la réplication via log shipping. Evidemment le fait que le slave ne soit pas accessible en lecture pour l'instant le limite au failover. J'espère que cette limitation sera levée en 8.4.
Slony n'est clairement pas un modèle du genre de simplicité et il est, à mon sens, assez difficile à imposer en dehors du cadre de sa propre boîte (typiquement, je ne le propose pas au client dont on exploite les plates-formes).
Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Clairement, un hot standby est suffisant pour 99% des besoins et je préfère très largement avoir un failover très fiable qu'un truc bancal qui me permet de faire du readonly sur un autre noeud. Note bien que je suis d'accord que c'est limitant pour certains besoins, juste que je préfère des fondations solides, ça se casse moins souvent la gueule :).
Pour l'histoire du cache disque, c'est l'argument qu'on entend souvent. Je dois avouer qu'on voit assez peu de cas où ça pose réellement un problème. Clairement, PostgreSQL se focalise sur faire du SGBDR, pas sur faire un OS au dessus de l'OS. Ca a parfois un coût, tout le monde en convient, mais c'est finalement assez sain.
Sinon, tu es gentil sur le "les performances de MySQL ne progressent plus au-delà de 8 cpus", j'ai vu plus de benchs où ça s'écroulait dès que le nombre de CPU et le nombre de connexions augmentaient et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte. Le fait de ne pas avoir sorti de version en 3 ans (et donc de ne pas avoir pu s'adapter à la nouvelle mode des multi-cores) joue sans doute un peu là-dessus.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 10.
1- la réplication via log shipping qui n'est pas intégré (nécessité de scripts externes). Ceci dit, elle est par contre beaucoup plus stable que la réplication MySQL par log shipping ;
2- impossibilité d'accéder en lecture au slave dans le cas de réplication par log shipping ;
3- quelques requêtes type le SELECT COUNT(*) FROM table qui sont lentes comparées à du Oracle (MyISAM ne compte pas vraiment à cause du table locking et le fait que ce ne soit pas MVCC et InnoDb a le même problème que PostgreSQL) ;
4- le fait que la locale et l'encoding soient globaux et par par colonne ;
5- le partitionning vraiment vraiment pas top.
Beaucoup de ces points vont être améliorés par le travail fait sur la 8.4 (en tous les cas, si tous les patches en attente sont intégrés) :
- les points 1 et 2 ont des patches en attente ;
- le point 3 devrait bénéficier du travail sur la visibility map fait en 8.4 mais ne sera pas résolu avant la 8.5 au moins ;
- le point 4 est très partiellement traité : on pourra avoir une locale par base de données ;
- le point 5 n'a pas vraiment bougé (il y a eu du boulot de fait mais je ne pense pas que ce sera intégré).
Ca n'empêche pas PostgreSQL d'être mon SGBDR de prédilection mais il faut aussi être au courant de ses points faibles pour l'apprécier pleinement.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 4.
Bof. Le principal problème corrigé dans la 8.3.5 (et qui a principalement motivé sa sortie) est un problème introduit dans la version mineure d'avant et qui n'était pas présent dans la 8.3.0. Mais c'est clair qu'il y avait des bugs dans la 8.3 comme dans toutes les versions précédentes.
La grosse différence est que la 8.3 est sortie sans bug grave connu. Après il y a toujours des bugs comme dans tout logiciel et ils sont découverts et corrigés au fur et à mesure.
Pour voir arriver les bugs sur les mailing lists, ils ne restent en général pas longtemps non corrigés, raison pour laquelle PostgreSQL peut encore se passer d'un bugtracker, d'ailleurs.
# La situation de MySQL
Posté par Guillaume Smet (site web personnel) . En réponse au journal La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 9.
Accessoirement, rappelons tout de même que MySQL AB avait fait une tentative de RC de la 5.1 il y a environ un an, avant que Sun prenne le contrôle.
Il y a clairement un *énorme* problème technique dans le fait de ne pas arriver à stabiliser une version en 3 ans et, pour moi, la responsabilité du fiasco de la 5.1 est surtout du côté des décisions techniques qui ont été prises (implémentation, volonté d'ajouter trop de choses d'un coup... ?). Le problème de base est vraiment là : impossible de stabiliser la 5.1 (que ce soit parce que c'est effectivement injouable ou parce que tous les efforts sont déjà mis dans la 6). La décision à prendre était grosso modo : soit la publier, soit abandonner et attendre la sortie de la 6 qui reste un truc très très flou pour l'instant. Je comprends un peu la position du management même si c'est une mauvaise décision technique. Accessoirement, ce n'est pas comme si la 5.0 était exempt d'un gros tas de bugs gênants à sa sortie : d'ailleurs, le discours de Monty Widenius est limite encore plus inquiétant pour ceux qui font tourner la 5.0 actuellement : "If you are a new user trying out MySQL for the first time, you should use MySQL 5.1; At least it's better than the MySQL 5.0 community version which has not been updated for some time.".
Pour ce qui est du futur de MySQL, il me semble que Falcon est abandonné suite au départ de son créateur et que l'avenir est plutôt du côté de Maria, le nouveau moteur développé notamment par Monty Widenius. Peu importe sa qualité, il mettra de toute manière un peu de temps à se stabiliser et à faire preuve de la robustesse qu'on attend de la part d'un moteur de SGBD généraliste.
AMHA, MySQL est dans une situation assez critique actuellement :
- même le créateur de MySQL a l'air de croire très moyennement dans la qualité de cette 5.1
- la sortie de la 5.1 ne règle pas le problème de fond de la base actuelle de code : ils ont laissé un paquet de problèmes en suspens et, s'ils étaient triviaux à régler, ça fera longtemps que ce serait fait
- l'avenir semble être à l'adoption d'un tout nouveau moteur qui va forcément faire preuve de jeunesse dans les premiers temps (et l'abandon de Falcon n'arrange pas trop les choses de ce côté-là)
- des forks apparaissent : notamment drizzle dont l'orientation montre assez bien que peu de gens croient dans ce qui a été ajouté dans la 5.1 (et dans la 5.0)
Bref, il semble que la course à l'ajout de fonctionnalités à tout va montre ses limites et qu'il va falloir prendre une autre orientation rapidement. Personnellement, j'aurai préféré que cette version 5.1 soit une version 5.0 où les fonctionnalités existantes de la 5.0 sont toutes implémentées dans leur totalité, sans limites bizarres et sans bugs bizarres. C'était le principal problème AMHA.
Pour l'instant, ils arrivent encore à faire en sorte que ces problèmes ne soient pas trop visibles mais ça commence à se savoir : on commence notamment à avoir des clients qui se posent des questions à ce sujet, ce qui est plutôt pour me plaire.
[^] # Re: C'est rapide.
Posté par Guillaume Smet (site web personnel) . En réponse au journal Des nouvelles de Debian Lenny. Évalué à 5.
Il faut bien noter le "The Debian project is pleased to announce the eighth and final update of its old stable distribution Debian GNU/Linux 3.1", ce qui semble bien en accord avec la news dont je postais le lien.
[^] # Re: C'est rapide.
Posté par Guillaume Smet (site web personnel) . En réponse au journal Des nouvelles de Debian Lenny. Évalué à 6.
En l'occurrence, elle n'est plus censée l'être depuis fin mars (pour moi les mises à jour de sécurité sont un élément clé du support) :
http://www.fr.debian.org/News/2008/20080229
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 3.
C'est une conséquence du boulot des gens, c'est tout.
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 3.
Sur la partie historique, je t'invite à lire : http://www.postgresql.org/about/history qui te donnera un éclairage différent (et un peu plus proche de la réalité).
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 4.
La seule utilisation réelle de l'héritage que j'ai vu, c'est pour le partitionnement de données.
[^] # Re: La tendance PostgreSQL
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche phpPgAdmin 4.2. Évalué à 10.
J'utilise PostgreSQL depuis 2001 donc mes raisons ne sont pas forcément celles des gens qui font le pas maintenant.
Ce que j'ai apprécié et que j'apprécie toujours c'est :
- la qualité du moteur, les fonctionnalités, la qualité des outils (client psql, EXPLAIN ANALYZE très détaillé, log_min_duration_statement en ms et pas en s)
- la cohérence de l'ensemble : les fonctionnalités présentes marchent, pas de limitation bizarre suivant des paramètres bizarres (types de champs, taille de la base, moteur choisi...), tout est cohérent
- la qualité des échanges avec la communauté (réactivité, niveau des échanges, implication des acteurs, retours d'expérience) et l'accessibilité des développeurs
- compatibilité entre les versions : pas de modification posant des problèmes de compatibilité entre versions mineures, éviter au maximum les nouveaux mots clés réservés (toujours embêtant de se retrouver avec un nom de champ qui est maintenant un mot clé réservé - c'est du vécu avec certains autres SGBDR)
- les performances et la scalabilité
- la qualité et la clarté de la documentation, bien séparée par version (pratique quand on fait de l'archéologie chez des clients)
- le fait que ce soit un vrai projet communautaire
- la transparence et l'absence de discours marketing qui a tendance à biaiser les choses. Là, c'est clair et net, y compris les aspects négatifs et on ne parle pas des fonctionnalités présentes dans des versions alpha/beta/gamma comme étant des acquis
- les trucs en plus : les types avancés et leurs index associés, PostGIS
- les progrès faits version après version que ce soit en terme de performances, de scalabilité, d'usabilité ou de fonctionnalités
J'ai probablement oublié des choses mais c'est ce qui me vient à l'esprit là maintenant.
Certains points sont purement absolus et pas relatifs à d'autres bases de données, notamment ce qui concerne la communauté, n'étant pas impliqué dans les communautés des autres bases de données du marché.
Certains points ont également leur revers comme l'absence de marketing, ça se sent au niveau de la notoriété.
--
Guillaume
[^] # Re: GoPHP 5
Posté par Guillaume Smet (site web personnel) . En réponse au journal Des nouvelles de phpPgAdmin. Évalué à 7.
La RHEL 5 est en PHP 5.1.6 (et donc les clones type CentOS aussi) et ce sera la RHEL officielle pour encore quelques années. De manière générale, je trouve que c'est une mauvaise idée de passer directement au 5.2 sachant qu'une des distributions majeures en entreprise propose PHP 5.1 pour un bon bout de temps et s'engage à le maintenir longtemps.
Oui, il y a des paquets 5.2 sur divers repositories externes mais quand on peut éviter, on préfère en général les paquets maintenus par Red Hat (sinon, on perd le principal intérêt d'utiliser une distribution à cycle de maintenance très long).
En particulier, avoir besoin de mettre des paquets PHP 5.2 pour un service périphérique d'administration comme PhpPgAdmin, c'est un peu dommage.
Bref, je milite pour le support de PHP 5.1+ et j'en profite aussi pour te remercier pour ton travail sur PhpPgAdmin.
--
Guillaume
[^] # Re: Durée de vie des objets et connexions permanentes...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Zend Framework 1.5 : consolidation et disponibilité. Évalué à 2.
Elles ne sont pas partagées, elles sont complètement indépendantes de l'application (ce qui est assez logique vu qu'il n'y a pas de notion d'application) mais elles sont persistantes.
Après, il est sûr que si tu souhaites trouver une définition qui te donne raison, ça ne me pose pas plus de souci que ça...
Note bien que ce que tu disais dans ton premier commentaire est :
"Se reconnecter à Mysql pour chaque page, au LDAP ..."
ce qui est donc faux comme nous te l'avons tous indiqué.
Tu devrais relire mon commentaire dans son entier et tu verras que je ne remets pas en cause la persistance par l'utilisation d'un pool de connexions.
Utiliser un pool résout une problématique différente. Ce n'est pas le problème de la persistance que je règle avec ça, c'est le problème d'avoir beaucoup trop de connexions sur ma base qu'il n'est vraiment utile quand j'ai beaucoup de fils Apache dont certains n'ont pas spécialement besoin de la base à l'instant t.
Après, qu'un pool de connexions utilisé en direct comme ce qu'il se fait en Java soit plus intelligent et plus économe en ressources, c'est une autre histoire. Note que même dans ce cas, les implémentations classiques de pool ferment en général les connexions au bout d'un certain temps pour en réouvrir d'autres. Et que de la même manière, tu peux avoir plein de connexions suivant les besoins de ton application et son utilisation.
Cela n'empêche pas de pouvoir trouver un équilibre tout à fait satisfaisant avec du PHP en module Apache et, pour ne pas le citer, PgBouncer.
Et certains trouvent même leur équilibre sans connection pooling additionnel.