Moby-Dik a écrit 2937 commentaires

Lorsque nos impôts construisent un hôpital mais que nous ne tombons pas "suffisament" malade, sommes-nous aussi "blouser" ? Le sommes-nous plus lorsque nous y allons mais que nous devons payer ensuite ?

Y a un truc qui s'appelle la Sécurité Sociale et qui t'assure un accès raisonnable (voire gratuit) aux soins indispensables....

Si l'IGN est un institut public (est-ce le cas ?), il serait normal que les informations collectées soient à disposition des citoyens, et en des termes "ouverts", non ?

Y a-t-il déjà eu une campagne en ce sens ?

A mon avis ce genre de catégorisation est une grosse erreur. Il y a des tas de gens qui bossent sur et dans l'informatique (programmeurs, etc.) sans vouloir passer leur temps à "gérer" leur bécane.

C'est l'écran de configuration d'impression comme "Panneau de configuration > Imprimante" sous Windows. Ben, oui, c'est ce que j'avais compris aussi. Mais cet écran est tout de même délirant.

Quant au système d'impression il est ultra performant et simple à utiliser. Si tu en es resté à l'époque de "lp" c'est que tu as une imprimante de Cro-Magnon ;). Ca t'arrive jamais de vouloir imprimer dans un pdf ? De vouloir imprimer 4 pages sur une feuille ? De changer la luminosité ? D'ajouter un header ? Ce n'est pas ça que je voulais dire. Un écran de configuration d'impression n'a pas à contenir plus de 40 icones et trois ou quatre panels simultanés, comme dans le screenshot sus-cité....

Hum, hum, les problèmes d'utilisabilité n'intéressent pas grand'monde semble-t-il ;-)) Dommage, après on aura droit aux sempiternelles jérémiades sur les méchants décideurs (ainsi que les traîtres OEM) qui ne veulent pas mettre "linux sur le desktop"...

A lire : "De Gemplus à MandrakeSoft ... Impasses d'une non-politique industielle" http://www.temps-reels.net/article.php3?id_article=1202

L'inconvénient des cartes à puce c'est quand même leur débit : on ne peut pas se permettre de chiffrer des gros volumes avec une carte à puce, à moins de ne pas être pressé. Ben, tu (dé)chiffres une clé de session avec la clé privée, puis le CPU fait du chiffrement symétrique avec la clé de session.

KDE vient d'inventer le dialogue d'ouverture de fichier qui prend tout le bureau et la gestion d'imprimante qui nécessite un brevet de pilote de ligne ? http://ktown.kde.org/%7Edirk/kde-3.1/fullsize/92.png http://ktown.kde.org/%7Edirk/kde-3.1/fullsize/9.png

Bizarre. Chez moi au deuxième lancement OOWriter ne met que 3 ou 4 secondes...

Il a moins de deux ans.

la sonnerie du réveille-matin

Trouve pas ça amusant. Grmmmbll.

J'ai trouvé ça aussi : http://www.sqlite.org/speed.html(...)

Pour les histoires de lock tu dois parler des accès concurrents en lecture et écriture sur une même table. Effectivement c'est quelque chose que MySQL ne sait pas faire (avec les tables par défaut). Par contre si tu modifies souvent une table qui est très peu consultée, les écritures sont très rapides. Il faut aussi penser à regrouper plusieurs écritures en une seule pour accélérer encore les choses. Il y a même moyen d'optimiser encore plus en n'écrivant les index sur le disque que lors du vidage du bout de cache correspondant (option DELAY_KEY_WRITE).

Pour les transactions il y a des benchs ici (mais ils sont faits par l'auteur des transactions sous MySQL...) : http://www.innodb.com/bench.html(...) . J'ai essayé les tables transactionnelles sur ma propre appli au boulot, ça s'approche à 10 ou 20% près des performances des tables par défaut (non-transactionnelles). Par contre ça prend beaucoup plus d'espace disque, ce qui est normal mais dissuasif dans mon cas précis.

Heu, justement, MySQL ne rendant pas les transactions obligatoires, c'est au niveau des écritures qu'il peut être beaucoup plus rapide...

Non non. Si tu utilises Mozilla, autant lui apprendre à cacher Zataz !

Oui mais que fait un serveur de base de données dans une DMZ ????

Il sera intéressant de voir quel format donnera la meilleure qualité. La décision de beaucoup de gens se fera sur ce critère.

Faut ptêt le signaler à Mandrake, c'est pas normal que la FNAC continue à vendre une aussi vieille version (et ça peut donner une mauvaise image de la distrib).

Je ne vois pas le rapport. Il y a des tas de gens qui utilisent MySQL sans être hébergeurs.

Tu peux aussi faire des stats sur les versions de PHP et d'Apache installées par les hébergeurs, et en déduire que PHP 4.3 et Apache 2 sont inutilisables en production... Ou d'autres foutaises du même genre ;) Par contre, si tu as des arguments constructifs pour dissuader l'utilisation de MySQL 4 en prod, tu es le bienvenu. Personnellement j'ai essuyé un bug chiant avec OPTIMIZE TABLE (4.0.4), mais c'est tout.

(pour répondre à ta question, altern.com se prépare à migrer en 4.0.x (depuis la 3.22 ;-)), et OVH s'y intéresse aussi. Mais c'est une discussion spécieuse).

- dans le temps, MySQL était beaucoup plus rapide pour des requêtes simples comme celles d'un site Web. Je ne sais pas si ce surcroît de rapidité est toujours nécessaire (comme pour une carte graphique, atteindre 220 fps c'est pas vraiment utile).

Il n'y a pas que le Web dans la vie. Je peux te dire que quand on stocke des événements en temps réel, on est bien content de tirer parti de la rapidité de MySQL...

La 4.0 est parfaitement utilisable en prod depuis au moins la 4.0.4 (c'en est à la 4.0.9). Elle est étiquetée "gamma" ce qui correspond à quelque chose de très stable chez MySQL. Par contre la 4.1 est effectivement balbutiante.

Les hébergeurs ont d'ailleurs pas mal à gagner avec la 4.0, qui introduit un cache de requêtes très utile avec les grosses bouses genre phpNuke.

Malheureusement on n'a pas le détail des amendements intégrés. De plus je ne sais pas si la Commission Culture a un rôle uniquement consultatif ou peut peser réellement sur la décision finale. Par contre il est agréable de voir le Monde Informatique (magazine de cadres tristoune) faire un lien vers le site de l'ABUL :-)

Surtout, tous laissent clairement sentir qu'ils n'y comprennent pas grand'chose, hélas...

Selon toute vraisemblance, il s'agit vraiment d'un blacklistage (filtrage selon l'IP source) derrière le peering. Cela explique que tous les services ne soient pas redevenus accessibles aux clients Wanadoo en même temps (si c'était le peering qui avait été coupé, tout serait revenu d'un seul coup lors de la remise en route du peering - alors que d'après les commentaires il y a eu un décalage de plusieurs heures selon les services). Cela explique aussi que Free ait pu mettre en place un serveur POP spécial pour Wanadoo (pop-ft.free.fr) sans qu'il soit affecté par le blacklistage.