Une des exemples les plus flagrants est la gestion des mutexs pour les locks, MySQL génére un grand nombre de locks et de retraits de locks, sous Linux l'impact est quasi-nul car les mutexs créés apr défauts sont en mode "fast" mais sous BSD la méthode employée par défaut oblige le système à rescanner tout le contexte.
Un idiot te répondrait : "ben pourquoi les mutex sont "rapides" par défaut sous Linux et lents par défaut sous BSD ? après tout c'est aussi ce qu'un bench est censé montrer : les performances pour effectuer des opérations ; si les gens de BSD s'amusent à utiliser des mutex lents ils ont des mauvais résultats au bench et c'est normal".
Et vue que je suis un idiot sur ce sujet, hop c'est ce que je te réponds. Peut-être tu peux nous donner plus d'informations sur ces mutex "rapides" et "lents". Le problème vient-il du fait qu'il n'y a pas d'appel standardisé Unix pour manipuler les mutex efficacement, et que mysql en utilise un qui est performant sous Linux mais pas sous BSD (il en aurait choisi un autre ça aurait pu être le contraire) ? Si tel est le cas, on peut aussi se demander pourquoi un logiciel aussi utilisé et qui n'est plus tout jeune n'utilise toujours pas un appel plus performant lorsqu'il est compilé pour BSD ?
(quoique ça doit être régionalisé parce que le BusinessWeek que j'ai pu voir ici n'avait pas cette couverture, elle était faite sur le "global aging" plutôt)
Savez vous que la plupart des agriculteurs QUI NOUS NOURISSENT et sont reellement indispensables gagnent moins que le RMI ? mais il est vrai qu'ils n'ont pas vraiment besoin de plus.
Faut arrêter avec cette comparaison. On ne peut pas vivre avec moins que le RMI (et non plus avec le RMI d'ailleurs). Ce que "gagne" un agriculteur c'est ce qu'il lui reste, il déduit tous ses frais, professionnels ou personnels. Ce que "gagne" un employé ou un informaticien c'est son salaire net. Ce n'est pas comparable, ou alors il faut que l'employé déduise son loyer, ses frais de nourriture, de bagnole etc.
Loin de moi de dire que le métier d'agriculteur n'est pas dur, ou est payé rubis sur l'ongle. Je connais leur situation et leurs difficultés, et je ne voudrais pas faire leur métier, c'est un métier vraiment dur.
La production à distance ne marche que pour des produits standardisés, pas pour des besoins spécifiques.
Le plus drôle c'est qu'en suivant ce raisonnement, normalement un éditeur Chinois ou Indien devrait bouffer Microsoft sur le marché de l'OS et des suites bureautiques (c'est dur de trouver plus standard). Allez, tous derrière les Chinois et les Indiens !
Le théorème de l'emmerdement maximal étant ce qu'il est, une panne a affecté le serveur de liste des serveurs. Autrement dit, pour trouver un serveur de jeu dans la liste, c'est coton :-o
Vous n'utilisez pas une liste de serveurs de liste de serveurs ? Le serveur principal pouvant tomber, c'est quand même mieux comme ça... Avec 3 vous devriez vous en tirer.
Moi personnellement je développe un site web dynamique, avec peu de besoins en base de données. Au boulot j'utilise Postgres, et je connais et j'apprécie les contraintes. Les procédures stockées sont plutôt nécessaires pour des utilisations plus poussées comme tu le soulignes, et je n'en ai pas besoin, par contre je trouve les contraintes vraiment indispensables pour avoir une base à peu près clean, que le nombre de tables et les traitements soient réduits ou non. Résultat, en apprennant que les contraintes ne sont pas disponibles avec MySQL à moins d'utiliser InnoDB sur la version 3 (donc vraiment pas dispo sur woody), j'ai été "obligé" d'opter pour Postgres.
Je ne sais pas comment les utilisateurs de longue date de mysql font pour créer des tables qui se référencent entre elles sans utiliser de contraintes, ça me semble le minimum vital pour pas faire du grand n'importe quoi... Un petit exemple pour fixer les idées :
CREATE TABLE alerts (
uid SERIAL,
user_uid INTEGER NOT NULL,
item_uid INTEGER NOT NULL,
ok mais bon c'est un peu cheap seulement deux prises...
en fait c'est vraiment un mac cheap, normal qu'il soit relativement "peu cher". tout le monde va rajouter un LCD cher, un hub, etc, etc, a la fin c'est cher mais les maqueux pourront dire qu'enfin y'a un mac pas cher.
[^] # Re: MESS
Posté par gc (site web personnel) . En réponse au message Probleme. Évalué à 3.
# TP ?
Posté par gc (site web personnel) . En réponse au message lire les doubles. Évalué à 1.
# msg
Posté par gc (site web personnel) . En réponse au message Probleme. Évalué à 4.
[^] # Re: Adresse mac en perl
Posté par gc (site web personnel) . En réponse au message hello world. Évalué à 2.
$ifconfig_result = `/sbin/ifconfig`
à la place de la totalité de ton programme moins la dernière ligne ?
[^] # Re: J'ai pas tt bien compris
Posté par gc (site web personnel) . En réponse au message hello world. Évalué à 2.
[^] # Re: Désolé pour les trolls
Posté par gc (site web personnel) . En réponse au journal La guerre des OS. Évalué à 2.
Un idiot te répondrait : "ben pourquoi les mutex sont "rapides" par défaut sous Linux et lents par défaut sous BSD ? après tout c'est aussi ce qu'un bench est censé montrer : les performances pour effectuer des opérations ; si les gens de BSD s'amusent à utiliser des mutex lents ils ont des mauvais résultats au bench et c'est normal".
Et vue que je suis un idiot sur ce sujet, hop c'est ce que je te réponds. Peut-être tu peux nous donner plus d'informations sur ces mutex "rapides" et "lents". Le problème vient-il du fait qu'il n'y a pas d'appel standardisé Unix pour manipuler les mutex efficacement, et que mysql en utilise un qui est performant sous Linux mais pas sous BSD (il en aurait choisi un autre ça aurait pu être le contraire) ? Si tel est le cas, on peut aussi se demander pourquoi un logiciel aussi utilisé et qui n'est plus tout jeune n'utilise toujours pas un appel plus performant lorsqu'il est compilé pour BSD ?
[^] # Re: windows...
Posté par gc (site web personnel) . En réponse au journal La guerre des OS. Évalué à 10.
# papier
Posté par gc (site web personnel) . En réponse à la dépêche Le modèle économique de Linux dans BusinessWeek. Évalué à 8.
http://images.businessweek.com/mz/05/05/0505covdc.gif(...)
(quoique ça doit être régionalisé parce que le BusinessWeek que j'ai pu voir ici n'avait pas cette couverture, elle était faite sur le "global aging" plutôt)
[^] # Re: je m'appelle pohrteukoi et je suis un nain
Posté par gc (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
[^] # Re: find
Posté par gc (site web personnel) . En réponse au message Un "ls -rtl" récursif. Évalué à 2.
# cache
Posté par gc (site web personnel) . En réponse au message Quantité de ram utilisée crédible ?. Évalué à 4.
[^] # Re: Mistake
Posté par gc (site web personnel) . En réponse au journal Linux dans le « Canard Enchainé ». Évalué à 2.
[^] # Re: Quelques questions d'avenir...
Posté par gc (site web personnel) . En réponse à la dépêche Solaris officiellement annoncé sous licence Open Source. Évalué à 3.
Dans la mienne, le 17 janvier 2005 je n'ai vu aucun nouveau JDK libre sortir.
[^] # Re: J'ai la solution à la crise informatique
Posté par gc (site web personnel) . En réponse à la dépêche 11 raisons pour ne pas choisir la filière informatique. Évalué à 5.
Faut arrêter avec cette comparaison. On ne peut pas vivre avec moins que le RMI (et non plus avec le RMI d'ailleurs). Ce que "gagne" un agriculteur c'est ce qu'il lui reste, il déduit tous ses frais, professionnels ou personnels. Ce que "gagne" un employé ou un informaticien c'est son salaire net. Ce n'est pas comparable, ou alors il faut que l'employé déduise son loyer, ses frais de nourriture, de bagnole etc.
Loin de moi de dire que le métier d'agriculteur n'est pas dur, ou est payé rubis sur l'ongle. Je connais leur situation et leurs difficultés, et je ne voudrais pas faire leur métier, c'est un métier vraiment dur.
[^] # Re: Et encore...
Posté par gc (site web personnel) . En réponse à la dépêche 11 raisons pour ne pas choisir la filière informatique. Évalué à 3.
Le plus drôle c'est qu'en suivant ce raisonnement, normalement un éditeur Chinois ou Indien devrait bouffer Microsoft sur le marché de l'OS et des suites bureautiques (c'est dur de trouver plus standard). Allez, tous derrière les Chinois et les Indiens !
[^] # Re: Download?
Posté par gc (site web personnel) . En réponse au journal bzflag 2.0. Évalué à 3.
(on fait moins le malin là hein)
[^] # Re: kaffe n'est pas en reste non plus
Posté par gc (site web personnel) . En réponse à la dépêche [Débat] Implémentations libres de java : sont elles utilisées dans la pratique ?. Évalué à 3.
[^] # Re: Download?
Posté par gc (site web personnel) . En réponse au journal bzflag 2.0. Évalué à 2.
Vous n'utilisez pas une liste de serveurs de liste de serveurs ? Le serveur principal pouvant tomber, c'est quand même mieux comme ça... Avec 3 vous devriez vous en tirer.
[^] # Re: Bonne raison de changer de mySql à PostgreSQL
Posté par gc (site web personnel) . En réponse à la dépêche Sortie de PostgreSQL 8.0. Évalué à 6.
Je ne sais pas comment les utilisateurs de longue date de mysql font pour créer des tables qui se référencent entre elles sans utiliser de contraintes, ça me semble le minimum vital pour pas faire du grand n'importe quoi... Un petit exemple pour fixer les idées :
CREATE TABLE alerts (
uid SERIAL,
user_uid INTEGER NOT NULL,
item_uid INTEGER NOT NULL,
CONSTRAINT pk_alerts PRIMARY KEY(uid),
CONSTRAINT un_alerts_user_item UNIQUE(user_uid, item_uid),
CONSTRAINT fk_alerts_user FOREIGN KEY(user_uid) REFERENCES users(uid),
CONSTRAINT fk_alerts_item FOREIGN KEY(item_uid) REFERENCES items(uid)
);
[^] # Re: prises USB
Posté par gc (site web personnel) . En réponse au journal Mini-mac. Évalué à 6.
dit-il après avoir tenté de prouver son point sur une bonne vingtaine de lignes :)
[^] # Re: prises USB
Posté par gc (site web personnel) . En réponse au journal Mini-mac. Évalué à 2.
[^] # Re: kaffe n'est pas en reste non plus
Posté par gc (site web personnel) . En réponse à la dépêche [Débat] Implémentations libres de java : sont elles utilisées dans la pratique ?. Évalué à 3.
[^] # Re: kaffe n'est pas en reste non plus
Posté par gc (site web personnel) . En réponse à la dépêche [Débat] Implémentations libres de java : sont elles utilisées dans la pratique ?. Évalué à 5.
[^] # Re: prises USB
Posté par gc (site web personnel) . En réponse au journal Mini-mac. Évalué à 2.
[^] # Re: prises USB
Posté par gc (site web personnel) . En réponse au journal Mini-mac. Évalué à 1.
en fait c'est vraiment un mac cheap, normal qu'il soit relativement "peu cher". tout le monde va rajouter un LCD cher, un hub, etc, etc, a la fin c'est cher mais les maqueux pourront dire qu'enfin y'a un mac pas cher.