Marc Cousin a écrit 26 commentaires

Et même pas traduit correctement :)

Mmm, de ce que j'en comprends, c'est l'utilisation du site clevo.fr qui est reprochée. Les PCs vendus par pcw sont bien des clevo, je ne pense pas que ce point soit interdit, si ?

Sinon, comment vous obtenez les correspondances entre la machine vendue par ldlc et l'original clevo ?

Suffit d'aller les chercher à la source :)

http://pcw.fr/shop/

Et puis t'as un PC sans logo. Ça me plait bien, je n'ai pas vocation à faire homme sandwich à chaque fois que j'ouvre mon portable.

Avant de commencer, je préfère préciser que je fais le plus gros de mes devs en perl, et que donc je fais aussi beaucoup de non-typé.

Malgré tout, pour beaucoup de contextes, avoir un langage fortement typé, ça a de gros avantages. Le principal étant de détecter beaucoup d'erreurs dès la compil, et pas uniquement quand le programme passe dans le bout de code qui pose problème.

C'est donc pas une question d'être L33T ou autre. Ça a des avantages réels. Et je pense qu'il vaut mieux commencer sur du fortement typé, prendre les bonnes habitudes au départ, quitte à passer sur des langages plus laxistes sur ce sujet après. Mais bon, on va pas refaire le monde, Python a été choisi (et oui, malgré ma préférence pour Perl, je pense qu'il vaut encore mieux débuter en Python, Perl pouvant faire beaucoup plus de dégâts dans des mains inexpérimentées :) ). D'mon temps, on leur faisait faire du Pascal sur des 286, aux élèves de «CPGE», ma bonne dame :)

Oui, tu as raté un truc:) "(" c'est ouvert, "[" c'est fermé, dans la syntaxe des range.

Donc le 1000 est ouvert dans le résultat.

Sinon, les WAL, ce sont les «Write Ahead Log», les journaux de transaction. C'est équivalent aux Redo-Logs d'Oracle par exemple. Comme ce sont des fichiers qui sont, au moins en partie, écrits de façon synchrone sur le disque, et checksummés (donc avec un lock exclusif pendant le temps du calcul du checksum), toute réduction du volume d'écriture dedans est la bienvenue :)

C'est la commande IDLE qui fait le push sous IMAP. Par contre, je crois que le défaut, c'est que ça ne marche que sur un dossier à la fois.

http://en.wikipedia.org/wiki/IMAP_IDLE

À part l'absence de support des podcast, je n'ai rien trouvé qui me manque d'amarok. Et j'ai retrouvé une interface qui me plaît. Après les goûts et les couleurs…

Si c'est pour avoir une appli de type amarok, il y a clementine, qui est plutôt un clône d'amarok 1.4, et qui n'a pas ce genre de dépendances. Il est en QT, mais ne dépend pas de KDE.

Bref, pour moi qui navigue entre kde et gnome (au gré de ma frustration avec l'un et l'autre :) ) clementine a l'avantage de tourner vraiment très bien avec les deux (et de s'intégrer parfaitement avec les raccourcis multimedias tels qu'ils sont gérés sous Gnome)

En Français :
http://blog.postgresql.fr/index.php?post/2010/06/16/Pr%C3%A9(...)

>Par contre je ne comprend pas tout à fait ce que tu entends par réécriture automatique des requêtes. C'est propre à Oracle 10g cette utilisation transparente des vues matérialisées? Je ne l'ai jamais rencontré. (pas été plus loin que la v9)

Ca existe au moins en 9i, même si il y a des nouveautés je crois en 10g sur le sujet :
http://www.oracle.com/technology/oramag/oracle/03-sep/o53bus(...)

C'est pas que j'aime pas Mysql ou PostgreSQL, mais ce que tu peux faire avec des triggers n'est pas exactement la même chose : une requête qui rame sous Oracle, si je peux lui demander de s'appuyer sur une vue matérialisée (il y a des choses qu'on ne peut pas faire...), je peux le faire de façon transparente pour le développeur ou l'utilisateur : le moteur réécrira dans son dos la requête pour utiliser la vue matérialisée plutôt que de lire la table. Cela évite de toucher au code de l'application.
Donc c'est faisable sous PostgreSQL ou Mysql avec des procédures stockées, et des triggers pour les mettre à jour, mais sans la réécriture automatique des requêtes, qui est bien extrèmement pratique. Peut être avec des rules PosgreSQL, mais ca peut vite devenir lourd à gérer.
Enfin, de toutes façons, là on parle de grosses bases décisionnelles, c'est pas encore la cible pour Pg ou Mysql à ma connaissance.

Oui, je simplifiais ... par en permanence je voulais dire que le résultat est en permanence présent dans la base, pas recalculé à chaque demande. mais les données peuvent être décalées suivant la facon dont tu déclares la vue matérialisée...

Je ne crois pas que développer un logiciel de façon professionnelle ait voir avec la peur.
Mettre des contraintes, c'est une question de robustesse. Si tu mets une contrainte au niveau de la base, tu es sur que personne ne peut la court-circuiter (sauf en la désactivant, bien sur). Cette contrainte ne change en rien le code qui est derrière, et peut t'économiser pas mal de soucis (comprendre : de travail, pas de peur...) en te protégeant de tes propres erreurs.

Pour les perfs, il y a les vues dites matérialisées (sous Oracle au moins). Ca consiste à fabriquer une table qui contient en permanence exactement le contenu qu'aurait ta vue. C'est surtout utilisé pour les bases sur lesquelles on fait du data mining, afin de préparer les résultats des requêtes les plus complexes (regroupements sur des grands nombres d'enregistrements par exemple).
Ca n'existe pas pour le moment sous PostgreSQL ou Mysql. On peut le faire avec des triggers, mais c'est quand même pas mal de boulot...

Une vue normale n'accélère pas les perfs. Ca ne fait que simplifier le développement.

> Les serveurs applicatifs sont pas non plus dans la DMZ? C'est mal(r).
Mpff ... pas dans la même. C'est CA la vraie paranoïa... :) Ca fait quand même un firewall à traverser.

>> Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).

> C'est pas du traitement fonctionnel ça?

Je pense que c'est à la limite... Ca dépend des raisons de la contrainte.
C'est avant tout de la vérification de cohérence à l'insertion. Ca permet d'être sur que même si tu as un développeur qui veut corriger en urgence une donnée dans une table (qu'il aurait amenée avec un autre programme) et lance un ordre UPDATE à la main (oui, déja vu, malheureusement) ne te vérole pas totalement ta base si il a oublié un petit détail. En théorie, le développeur ne devrait pas avoir accès à la base de prod en direct, mais il y a des environnements ou tout est permis.

Evidemment, tout est dans le savant dosage, et dans la capacité à savoir s'arrêter dans les contraintes d'intégrité. De la à ne pas en mettre du tout parce qu'on est sur de son code ou parce que le PL c'est moche ...

Tu n'es pas obligé de mettre du fonctionnel dans les procédures stockées. Tu peux te limiter à l'accès aux données...
Ca évite tout de même de faire de nombreuses requêtes successives au moteur pour récupérer quand les données à récupérer sont complexes. C'est très utile par exemple quand le réseau entre la BDD et le serveur d'appli peut avoir un impact sur les temps de réponse de requêtes simples (par exemple, serveur BDD dans une DMZ).
Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).
Evidemment, écrire un traitement fonctionnel de plusieurs dizaines de milliers de lignes en PLSQL par exemple, c'est aimer se faire mal... et je présume que c'est plutôt à cela que tu pensais.

Uniquement pour des vues "matérialisées".
Le reste du temps, une vue, c'est a peu près rien d'autre qu'une règle de réécriture de requête.

En théorie, un raid 5 sur trois disque, c'est sensé être environ 2X plus rapide qu'un de ses disques en lecture (parallelisme), mais 2X plus lent qu'un de ses disques en écriture :
Pour écrire un bloc, il faut :
- lire l'ancien contenu du bloc et la parité (parallélisables)
- ecrire le nouveau bloc et la parité (parallélisables)
Ce qui fait 2 lectures et 2 ecritures pour une écriture logique...

Evidemment, ces valeurs dépendent après du controleur raid, de la qualité du driver, du paramétrage raid, etc ...

Il me semble bien qu'avec les noyaux 2.4 'standards' l'extraction audio, par défaut, se fait sans DMA pour les cdroms IDE. Y a meme un patch pour ca ...
Peut être qu'il est dans les derniers 2.4, j'ai pas regardé.
En 2.6, l'extraction audio, ca prend 2 ou 3%.
Ce qui ne change rien au fait qu'un controleur SCSI consomme effectivement un peu moins qu'un controleur SCSI (mais c'est le moindre de ses avantages), ce qui est important sur un serveur.

Probablement parce que la majeure partie d'entre eux sont des utilisateurs de debian convertis (ou de futurs utilisateurs de gentoo reconvertis ) :)

A la poursuite d'Octobre Rouge?

Y parait qu'il y a meme des malades qui testent tous les -mm ... moi en l'occurence ... :)
Je me demande si a partir d'un certain moment c'est pas une forme de dependance ...

... racheté par Sco et devenu unixware depuis je crois bien

En ce qui me concerne (via KT aussi, mais KT133), j'ai du mettre acpi=off ou pci=noacpi pour pouvoir booter ...

Ils ont pas mis la nouvelle version 'révolutionnaire' du configurateur dont ils avaient parlé a un moment (celle qui permettait de faire du MUD...).
Mais l'outil de compil du 2.6 est tout de meme plus sympa. Les make xconfig sont plus joli (pas crucial, mais possibilité de les avoir en qt ou gtk), et surtout il n'y a plus besoin de make dep et make clean ...