Sylvain AVRIL a écrit 23 commentaires

Notez qu'il existe un autre colorimètre Open Source (et français en plus): http://www.homecinema-fr.com/colorimetre/.

Bon, le logiciel n'est pas sous Linux (Win ou Mac), soit. Mais rien n'empêche une bonne âme de s'y atteler.

Pour moi l'avantage de Puppet, c'est qu'il n'utilise pas Ruby. :-)
Je n'ai pas envie d'apprendre un langage ainsi que l'ensemble des bibliothèques associées avant de pouvoir déployer un truc.

Et c'est bien là que réside la différence de philosophie entre les 2 outils.
Avec Chef, tu développe des scripts.
Avec Puppet tu décris l'archi que tu veut déployer (il utilise un langage déclaratif).

Pour configurer un cluster, tu peut utiliser les exported ressources. Dans mon cas, je l'utilise pour que chaque base de données déployée modifie automatiquement la config de mon serveur bacula pour y inclure le backup de ces BD.

Puppet apporte son propre langage et son propre mode d'exécution et c'est comme avec l'apprentissage de chaque nouveau langage, au début on galère, après tout vient bien plus vite, j'en conviens.

Mais pour moi, utiliser Chef n'aurait pas été plus facile (peut être plus, ruby est plus riche que puppet). Après il m'a quand même fallu apprendre ruby lorsque j'ai voulu étendre les possibilitées de puppet (même si on peut faire déjà pas mal de chose, écrire des types personnalisés est plus propre dans certains cas).

En tout cas, je reste convaincu de l'intérêt d'avoir un langage déclaratif pour décrire un déploiement. Quand tu lis du puppet, tu sais ce qui est installé. Quand tu lis du Chef, tu est obligé d'imaginer chaque étape pour comprendre le résultat final.
Autre élément intéressant quand le déploiement plante au milieu, puppet est capable de reprendre là où il s'était arrêté. Avec un script...

Puppet n'a pas son propre serveur web. Il utilise le standard ruby Webrick (qui est plutôt nul j'en conviens). Tu peut utiliser passenger ou mongrel pour monter en charge.

Petite précision concernant Xen en dom0. Contrairement à Redhat, il n'est pas prévu que Debian abandonne Xen. Cependant il n'y a qu'une personne (Bastian Blank) qui s'est déclarée volontaire pour le portage des patchs depuis l'upstream (Xen fait des patchs pour la 2.6.18) vers la version du kernel qui se sera choisie par debian. Et le travail de portage est quand même important ! Suse propose déjà des patchs Dom0 pour le kernel 2.6.31 mais Debian part vers la 2.6.32. Reste donc à voir si Bastian arrivera à faire le portage avant la release de squeeze.

Par contre ce qui est sûr c'est qu'il n'y aura plus de kernel xen pour la prochaine release après squeeze. En effet, xen va tirer parti du travail paravirt_ops sur le kernel (interface multi-hyperviseur: xen, lguest, vmware) : [http://wiki.xensource.com/xenwiki/XenParavirtOps]. On n'aura donc plus besoin de patchs spécifiques à Xen et on pourra utiliser un kernel tout ce qu'il y a de plus standard en dom0 (c'est déjà le cas pour les domU). La finalisation est prévue pour la 2.6.33 ou 2.6.34 (m'enfin je dirais plutôt 2.6.34 ou 2.6.35, au départ c'était prévu pour la 2.6.32).

d'ailleurs les boites continuent de se ruiner

Elle ne se ruinent pas, elles créent de la fausse valeur, nuance.
Lorsque tu dépose un brevet, tu peut le valoriser dans ton bilan comptable : tu augmente la valeur de ta boite. Le fait qu'il ne soit pas réellement applicable importe peu.
De plus, ça peut te rapporter en réduction d'impôts...

T'es pas forcément obligé d'être Debian Developer (DD) pour contribuer des paquets.
Il existe debian mentors : http://mentors.debian.net/cgi-bin/welcome.
Tu fais ton paquet et tu l'upload. Ensuite un DD vérifie ton paquet (règles, qualité), te fait éventuellement des retours et à la fin ton paquet arrive dans la distrib Debian (la vraie, pas des repository annexes).

Ce que tu as dit m'a fait sursauter : DB2 Mainframe, une base de données performante ?

Ce n'est pas ce que j'en ai retenu la dernière fois que j'ai dû l'utiliser.
Nous avions un gros projet (> 2000 mois/homme) qui avait commencé son développement avec Oracle 8i sous AIX. Nous avions ensuite migré sous DB2/zOS (nous utilisions un moteur de mapping objet/relationnel), pour des raisons politiques. Les temps des transactions ont tout simplement explosé. Nous avons passer des mois à optimiser la base, toutes les recommandations IBM y sont passées : optimisation index, partionnement, convertion des VARCHAR en CHAR, ...

Ce que j'en ai retenu : DB2 z/OS c'est très bien pour les bases hiérarchiques, mais inutile de chercher à faire du relationnel avec. Toute sa conception est basée sur les concepts de BD mainframe. C'est donc on ne peut plus optimisé pour les bases "à la papa" mais pas pour les besoins des BD "nouvelles technos". DB2 UDB (versions AIX et autres OS) a une conception totalement différente et se révella plus concurentiel vis à vis d'Oracle sous AIX pour ces applications.
Ca me ferait bien rire de voir un datawarehouse sous DB2/zOS.
Au final, le projet a choisi de passer en prod sur du Oracle en cluster pour un coût bien plus faible.

J'ai eu la même conclusion entre l'utilisation de Websphere zOS et Websphere/Weblogic sous AIX.

Euh et pour le prix, c'est une blague ?

Pour l'aspect robustesse, un bon cluster bien administré, ça peut faire l'affaire.

Enfin un post plus modéré et éclairé. Oui QNX est un bon exemple de micro-noyau, je l'avais oublié. Tu as tout fait raison de préciser que les systèmes µ-noyau trouvent beaucoup d'écho dans l'embarqué et les télécoms.
Il faut éviter le troll avec Windows qui n'est pas vraiment un micro-noyau.

Je pense aussi qu'il ne faut pas considérer la parole de Linus comme celle du messie. Il a fourni de bons arguments pour le monolithique (facilité de développement, ...) mais il a aussi rejeté des arguments pour le micro-noyau sans réelles justifications (stabilité, sécurité).

Le micro-noyau apporte plus de sécurité et de stabilité 'by-design'. Il n'y a qu'à compter le nombre d'exploits noyau pour Linux, ils suivent une courbe exponentielle. Bien sûr on ne peut pas comparer avec des systèmes peu utilisés mais pour la sécurité, la séparation des espaces mémoire se justifie.

Bien sûr on peut faire aussi bien en monolithique en peaufinant le code, en résolvant les bugs... Mais plus la complexité du système augmente plus ceci devient coûteux alors que l'isolation dans des systèmes étanches permet de limiter le périmètre impacté par les bugs.

>> Bien sûr, y'a la solution d'écrire des pilotes sans bug, hum hum.

> Pourquoi pas. Ce n'est pas plus irréaliste que de faire un micronoyau
> hypra souple et capable de gérer toutes les erreurs (voire de faire
> de l'auto-guérison comme le dit la dépêche). Le principe de Minix 3
> supose qu'il y a une partie (assez grosse) sans bug.
> C'est pareil avec GNU/Linux, sauf que la partie sans bug est plus
> grosse. Mais comme c'est moins compliqué, il n'est pas dit que l'un
> soit intrasèquement moins fiable que autre.

Je ne sais plus quel scientifique démontrait que les logiciels sans bugs sont une utopie. Quelque soit la qualité des développeurs, il y aura toujours des bugs (même si ce sont les très qualifiés développeurs du kernel).
Le kernel linux a atteint une telle taille que je suis impressionné qu'il puisse tout simplement marcher. Si cela avait été fait dans un mode propriétaire/commercial avec des contrainte de temps/budget, il aurait fait parti des nombreux projets abandonnés (car l'une des forces de l'open source AMHA c'est de mettre les techniciens au centre des décisions et qu'elles sont les plus justes et pérennes).

Donc même si l'approche ultime/idéaliste est de dire qu'il ne vaut mieux ne pas avoir de bug est juste, l'approche de redémarrer le code fautif est aussi une solution ... court terme, efficace mais qui ne justifie aucunement de ne pas corriger le bug.

Vu que les serveur d'applications J2EE fournissent une énorme quantité de services (gestion de transactions J2EE, bus de message, ...), la consommation mémoire n'est pas choquante (d'autant plus que cela doit être plus lié au Xmx).

SI tu savais configurer JBoss ou Jonas, tu saurais que tu peut choisir les composants qui seront lancés et utilisés. Tu peut réduire les 2 serveurs au niveau fonctionnel d'un tomcat ou moins et là forcément ça consomme beaucoup moins. La conso d'un tomcat qui ne fait rien par rapport à un apache 2 + PHP 5 reste comparable.

Je vous recommande fortement d'aller voir cette vidéo :
http://www.youtube.com/watch?v=EI926O4qOiw&feature=chann(...)
C'est la vidéo qui résumé vraiment la force de Rigs of Rods.
Je ne suis pas expert en conception de jeux vidéos mais ça m'a vraiment éclairé sur le sujet et la manière dont il a été traité. Cela me rappelle quand je codais un moteur 3D il y a presque 20 ans : il y a des solutions simples à des problèmes compliqués.
Félicitations à l'auteur pour l'inventivité.

C'est pas forcément irréaliste :).
Microsoft a fait récemment une démo d'un cluster à base d'Intel Atom. Bon, passons sur le fait que c'était pour démontrer que Windows 7 était moins gourmand que son prédécesseur.
L'avantage de ce type de solution est que l'Atom a un rapport consommation électrique/puissance bien supérieur aux processeurs Intel classiques (Core 2, Xeon), donc cela permet de faire des clusters plus "Green" (moins de conso électrique et moins de besoin de refroidissement).
Bon après y'a une méthode plus simple : installer Linux/BSD au lieu de Windows, ça consomme vachement moins de CPU :-).
Ensuite, faudra apprendre aux développeurs à paralléliser leurs traitements. Là j'ai plus de doutes.
A l'avenir par contre, les gestionnaires de datacenters risquent de se poser la question.
Déjà il y a une question que les décideurs avertis se posent : doit-on proposer des netbook plutôt que des PCs portables si nos applications sont toutes web ou utilisables avec la puissance d'un netbook ?

A priori si j'ai bien compris les messages précédents, il me semble que brtfs n'ait pas pris le même chemins que ZFS. Ils ne cherchent pas à réécrive des fonctionnalités disponibles sur une couche plus basse (LVM, MD-RAID) mais ils en tirent parti pour optimiser les fonctions FS comme la répartition des metadata sur plusieurs disques, etc.

Vraiment très intéressant cet approche que je reprochais à ZFS. J'applaudis des 2 mains.

Et si tu veut profiter de la résolution HD, il te faut une carte vidéo et un écran HDMI avec HDCP. Par exemple, sur mon PC avec un écran connecté en VGA, j'ai eu la surprise de ne voir la vidéo qu'en SD sur mon écran.
Et on ne peut pas non plus utiliser un écran non-HDCP en même temps qu'un autre écran HDCP pour avoir par exemple le bureau sur l'écran VGA et la vidéo sur l'écran agréé par les lobbys.
Bref, sous Windows c'est une grosse source de problèmes ces nouveaux DRM. Même sans vouloir pirater, on en devient obligé d'installer AnyDVD.

Alors que sous Linux, il sera au pire nécessaire d'ajouter un dépot "anti-lobby" sur son PC pour pouvoir profiter librement des contenus BR.
J'avais acheté quelques BR puis j'avais arrêté pour cause de DRM. Je vais pouvoir continuer (même si j'ai toujours une dent contre ces lobbys qui ne cherchent qu'à e*****r le consommateur).

Je suis tout à fait d'accord. Sous Windows, lire un BluRay avec PowerDVD est une galère. Au final, il devient indispensable d'installer un soft comme xxxDVD (auto-censure pour cause de DADSVI) pour faire sauter les verrous d'un disque acheté légalement afin de le lire sur un moniteur non drmisé (soit la majorité). Pire, il est encore plus simple de télécharger illégalement le même film pour le lire.
Il y a quelques temps, je sortais la formule suivante propos des DRM :
"Les DRM ça sert plus à faire ch*** les gens honnêtes que les pirates".
Là, c'est pire que ce qu'on pouvait imaginer.

Bof moi je conseille pas trop.

Les arguments contre :
- c'est plus cher pour le même débit qu'en ADSL (mais pas d'abonnement téléphone obligatoire)
- les débits en voie ascendante sont minables sauf si on paye 5¤ de plus et là on accède au débit faramineux de 256 kbits/s
- les quotas pour l'offre 20 Mbits/s
- les débits descendants sont alétoires, je suis en offre 2Mbits/s et ça râme souvent, même pour de bêtes pages webs (yahoo, google, ...).
- faut Windows pour activer leur bouzin lors de la première installation

Les arguments pour :
- c'est bien quand on a que ça de dispo, ce qui est mon cas, je suis à Nantes mais dans immeuble truffé de câble pourris, à 4.5 km du central, soir -65 db, je ne peut que pleurer et accepter mon sort
- le modem ethernet avec DHCP
- renouvellement de l'IP toute les semaines, faute d'avoir une IP fixe (payante là aussi)
- pas eu beaucoup de problème de disco, mais c'est arrivé

Moi j'attend toujours :
- un groupware utilisable correctement sous Evolution (sans passer par un infame connecteur Exchange)
- que l'on peut utiliser aussi bien online qu'offline
- qui peut se synchroniser avec un PDA (et pas seulement Palm, je pense au Zaurus)
- utilisable aussi sous Windows (même si c'est Exchange)
- qui ne m'impose pas de changer de serveur web ou de serveur de mail
- qui ait aussi une interface web

Lorsque l'on aura ça, on aura vraiment un groupware open-source qui permettra de migrer depuis Exchange.
La majorité des boites qui installent Exchange n'ont pas besoin de toutes les fontionnalités mais veulent seulement : mail, calendrier partagé, gestion des tâche et planification de réunion.

Note préliminaire : Je ne suis pas DBA et donc pas expert en BD. J'ai cependant pas mal de notions de BD (en ce moment, je m'occupe de l'aspect Persistance pour un client avec des solutions JDO).

Postgresql est un produit a beaucoup plus de fonctionnalités que Mysql.
Pour faire un classement grossier, on aurait : Access < Mysql < Postgresql < Oracle.

Dans le monde Opensource, je pense que Mysql et Postgresql s'utilisent dans des buts différents.
Postgresql est le plus adapté aux systèmes de gestion car il a toujours possédé une avance dans les domaines suivants :
- intégrité des données (contraintes : FK, NOT NULL)
- fiabilité (journal des transactions)
- intégrité des transactions (isolation, XA)
- les procédures PL/SQL pour soit avoir une isolation vis à vis des données : on n'accède au données que par des procédures (une sorte de DAO) soit faire des traitements lourds
- les triggers (mise à jour automatique de compteurs, ...)

Mysql a lui toujours eu des performances optimum (car moins de fonctions). Il a prouvé sa capacité à supporter de lourdes charges (Slashdot). Il est aussi beaucoup plus simple. Ca m'a frappé quand j'ai installé la version Windows. En cliquant, on installe la BD, les outils d'administration très sympathiques (mieux que ceux de DB2 et Oracle je trouve). Et pour un développeur qui veut juste stocker des données sans avoir de contraintes sur la fiabilité (moins que si c'était une opération de virement fait par une banque), c'est vraiment la solution idéale : légère et simple.

A mon avis, Mysql ne devrait pas chercher à intégrer trop de fonctionnalités pour ne pas se surcharger. Il devrait rester sur sa cible. Et de toute façon au niveau des fonctionnalités, Mysql a encore un bon retard.

Sinon, j'ai regardé les démos flash du produit et d'un point de vue utilisateur, ça à l'air vachement sympa. Je réfléchissais à l'intégration du solution de gestion de documents pour ma boite et en regardant les démos, je serais prêt à l'installer! Mais bon, je vais être plus pragmatique et évaluer toutes les solutions opensource disponibles. ^_^

J'ai trouvé encore mieux....

Je vais passer pour un neuneu, mais bon je vais quand même partager mes expérimentations.
En fait tout est prévu dans l'installeur debian.
J'avais fait mes installation en bootant le cd d'install en mode par défaut (kernel 2.4). Dans ce mode, l'install root raid+lvm ne marchait pas chez moi. Je n'ai plus de doute sur la non-fiabilité de ma machine de test, donc peut être que ça peut marcher en kernel 2.4.
Il faut booter l'install avec un kernel 2.6 (option linux26 ou expert26 du boot lilo).
J'ai fait une install avec l'option expert26 en utilisant partman pour la configuration du raid et du lvm. En passant, l'ergonomie est pas forcément très efficace mais on configure quand même tout par une interface simple. Et ça marche directement au reboot !333

J'avais du louper une étape dans mon installation.
J'ai apparament des problèmes supplémentaires liés à ma config matériel (détermination du disque de boot par le BIOS, ...).
J'ai refait un essai avec une installation debian sous qemu et j'ai réussi à utiliser la procédure indiquée ici http://www.poochiereds.net/svn/lvm2/(...)
Lorsque j'aurais le temps, je ferais un HOWTO en français.

Donner c'est donner, reprendre c'est voler.

Non, le terme "non-free", c'est pour non-libre, pas pour commercial.

J'utilise une version béta de la Mandrake 7.0 sur de vieilles sun (les premières ultra) et ça marche plutôt bien. En fait, je n'ai pas eu de problèmes jusque là. Je l'utilise sur 6 sun qui sont utilisées modéremment (faut d'abord que tous les PC soient déjà utilisés pour qu'on s'intéresse à ces bécanes :). Pour une béta c'est carrément utilisable, je n'ai eu aucun plantage.