FOSDEM 2008

Pour l'ouverture des rencontres du FOSDEM, nous n'avons pas coupé à la désormais traditionnelle danse avec une annonce de l'organisateur qui a passé le flambeau pour cette année.

La première matinée est prise par trois conférences dans l'amphithéâtre Janson.

Il y a une première conférence sur Linux et Hollywood, une seconde sur les projets Open Source de grande ampleur et une présentation concernant les brevets sur les logiciels.

Dès l'arrivée, nous voyons des piles de rouleaux de posters, et chaque auditeur qui entre dans l'amphithéâtre en amène un.

Tux in Shades Linux in Hollywood

Cette présentation du FOSDEM a un format étonnant. Robin Rowe et Gabrielle Pantera présentent les différents outils utilisés par différents studios de production d'Hollywood pour la création artistique, la retouche, les fermes de calcul, etc.

Quelques outils sont énumérés et quelques bandes annonces sont diffusées. Dans le même temps, les orateurs expliquent le détail de quelques effets spéciaux réalisés pour des films d'action ou des films d'animation.

Les studios utilisent Linux depuis 1997. J'ai d'ailleurs été surpris d'apprendre que le premier long-métrage d'Hollywood pour lequel une ferme de calcul sous Linux a été employée est « Dante's Peak » (« Le Pic de Dante »).

Un de mes voisins a marmonné la remarque suivante : « We don't wanna see movie trailers, we want geek stuff. Show us the hardware! »

La keynote se termine par une série de quelques questions, parmi lesquelles :

• Pourquoi les studios ne développent pas des outils libres, mais des outils propriétaires ? La concurrence acharnée que se livrent les studios et les délais de production ne laissent pas le temps à la publication et l'ouverture de logiciels de traitement d'image ou de video. Ensuite, les studios embauchent souvent les développeurs qui travaillent sur des projets liés à la création multimédia qui délaissent alors les projets, faute de temps, ou pour éviter les conflits d'intérêt entre le logiciel produit en interne et ce qui peut être diffusé sous des licences de logiciels libres.

• Pourquoi des compagnies tentent d'empêcher la lecture des films sous Linux, entre autres alors qu'ils utilisent Linux pour produire les films ? Cette question a été acclamée par un tonnerre d'applaudissements. Les grandes compagnies ont des intérêts contradictoires. Par exemple, la division grand public et la division Films d'un groupe comme Sony ne partagent pas les mêmes craintes ni les mêmes bénéfices.

Cette présentation était un peu étonnante. Sa place sur l'agenda en ouverture alors que le contenu n'était pas très technique semble indiquer que les studios d'Hollywood sont des interlocuteurs efficaces ou qu'ils emploient en ce moment.

How a large scale OSS project works ?

Le titre est une manière de détourner l'auditeur du sujet qui sera traité : FreeBSD ;-)

L'ampleur ne concerne pas seulement la taille en terme de ligne de codes, mais aussi le nombre de membres du projet et des utilisateurs de ce système.

Robert Watson rappelle l'organisation du projet. Il est lui-même membre de la core team. Il y a donc le core, les committers et les mainteneurs.

Un diagramme a retenu en particulier mon attention, qui décrit les échanges entre les divers BSD, Linux, OpenSolaris et GNU entre autres.

Perl 6

La présentation suivante m'intéressait particulièrement, car je suis un grand fan de la syntaxe de Perl. Patrick Michaud commence par nous rappeler une citation de Larry Wall : « What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against » qui fait rire une bonne partie de l'assistance (nombreuse).

Il enchaîne sur une constatation : Perl 5 présente quelques inconvénients. Des concepts de programmation ont été ajoutés au langage au fur et a mesure, la courbe d'apprentissage est ardue du fait de sa syntaxe et du motto TIMTOWTDI.

Perl 6 part de cette constatation, et est un redesign complet apportant énormément de changements. Les spécifications de Perl 6 ont été faites avec, par et pour la communauté Perl depuis 2001 au travers des « apocalypses » (voir lien).

Perl 6 apporte principalement du typage de données, encore plus de sucre syntaxique : $a[0] devient @a[0], +$a interprète $a comme un nombre, ~$a comme une chaîne de caractères, on peut maintenant faire des comparaisons telles que 0 <= $a < 10, l'opérateur de comparaison avancée (smart match) ~~ (aussi présent dans Perl 5.10), une vraie construction switch/case apparait avec given/when ...

Bref, ceux qui n'aimaient pas Perl 5 ne vont pas être déçus !

P. Michaud insiste ensuite sur le fait que Perl 6 en lui même n'est qu'une spécification, dont il existe déjà plusieurs implémentations : Pugs en Haskell, qui est la plus développée mais un peu au point mort, KindaPerl6, une implémentation de Perl 6 sur Perl 5, et enfin Rakudo Perl implémenté sur la machine virtuelle Parrot.

S'ensuit une petite présentation de Parrot : c'est non seulement une machine virtuelle avec un assembleur de haut niveau, mais surtout un ensemble d'outils annexes, plus particulièrement une boîte à outils de créations de compilateurs et de grammaires.

Il termine sa présentation en rappelant que si le développement de Perl 6 a pris autant de temps, c'est que les objectifs de départ étaient très ambitieux, et que la spécification a été refondue itérativement plusieurs fois pour atteindre la perfection.

Update on software patents

Pieter Hintjens, précédemment président de la FFII, fait un tour d'horizon des brevets en général et des brevets logiciels en particulier.

Sur un format plus proche de la discussion, et sans projection de feuilles sur l'écran géant, la présentation est un peu floue.

FreeBSD 7.0

C'est une présentation que j'avais trouvé à l'avance sur le web. Ce n'était donc pas une découverte, mais l'orateur est excellent, clair, précis. Ce devait être Robert Watson, mais il a dû être remplacé au pied levé par Kris Kennaway.

La salle était bondée. J'ai assisté à la présentation debout.

Intéressant. Un peu de troll, avec des comparaisons qui disent globalement «on est meilleur » que Linux.

L'un des buts de FreeBSD 7.0 était d'améliorer dramatiquement le support SMP, en particulier au niveau de la stabilité et des performances.

De nombreux benchmarks réalisés avec sysbench ont été joués pour illustrer les améliorations dans la gestion du SMP. Il y a eu des comparaisons avec CFS, le nouvel ordonnanceur de tâches de Linux. Un peu de troll au passage. Sachant que CFS est vraiment nouveau alors que celui de FreeBSD a commencé à être développé il y a un peu plus de temps.

Cet ordonnanceur s'appelle ULE. Il en existe des variantes pour prendre en compte la topologie des CPU. Pour le moment, l'ancien ordonnaceur est toujours le défaut mais il devrait changer dans les versions à venir.

Comme les tests ont mis en jeu des applications, il semblerait que les limites observées proviennent de l'architecture des applications au-dessus mais pas du système.

Globalement, ce qui ressort, c'est que BIND est scalable jusqu'à 6 threads, après il a tendance à ne pas tirer parti de beaucoup plus de cœurs d'exécution. D'autres limitations du même genre sont illustrées sur MySQL.

La version 7 n'est pas encore prête, mais semble très prometteuse sur le papier. En fait, elle est sortie quelques jours après la conférence.

Entre autres, il y aura le support de XFS en lecture seule et un support complet de ZFS.

PostgreSQL.org infrastructure

Stefan Kaltenbrunner fait un retour d'expérience sur la mise en place des serveurs web de l'association postgresql.org.

Il parle de la gestion dynamique des miroirs, avec une application pour facilement ajouter ou supprimer des miroirs, et des tests de latence qu'ils font pour trouver les meilleurs miroirs.

Ça semble justement la partie la plus intéressante.

Tout ce qui concerne le site de PostgreSQL est... sur le site de PostgreSQL, même la description du site lui-même.

SNMP monitoring in FreeBSD

Shteryana Shopova présente les implémentations de SNMP disponibles pour FreeBSD.

Tout d'abord, elle rappelle rapidement l'existence de Net-SNMP, comme une solution de référence disponible rapidement, puis elle passe à un projet fonctionnellement moins avancé, à savoir bsnmpd.

Il s'agit d'un daemon SNMP qui fonctionne bien, qui est simple, et pour lequel il faudra certainement développer ses MIB si l'on souhaite surveiller des choses non encore implémentées. En fait, sa force et sa faiblesse sont à la fois que l'on peut étendre le daemon en développant des nouvelles bibliothèques et en même temps qu'il faut justement les développer.

Shteryana présente ce qu'il faut faire pour écrire une MIB. Tout d'abord, il faut décrire la MIB en ASN.1, et ensuite, il faut l'implémenter. Hé oui, ça ne se fait pas tout seul.

Bref, il y a tout à (re)faire. Pour ajouter à l'ironie, il est possible d'ajouter les MIB Enterprise de UCD.

Stéphane Marchesin - Nouveau: Cooking an open source driver

La conférence suivante se déroulait dans la salle X.org, bondée aussi et surtout surchauffée. marcheu@ commence par présenter les avancées du projet depuis son annonce au FOSDEM'06 : l'accélération EXA et glxgears marchent sur la plupart des cartes !

D'ailleurs, il rappelle que le projet vise à supporter tout les types de cartes Nvidia, de la plus ancienne à la plus récente (contrairement au pilote binaire qui supprime progressivement le support pour les cartes les plus anciennes), et présente les différentes générations de cartes ainsi que leurs similarités et les différentes évolutions.

Le projet nouveau est composé actuellement de 6 développeurs actifs, la communication passe surtout par le canal IRC #nouveau@freenode, et toute aide est la bienvenue. Il présente ensuite les différents outils d'ingénierie inverse développés pour analyser le comportement du driver binaire :

• mmiotrace est un outil générique pour tracer les entrées sorties au niveau du kernel, et il vise l'inclusion dans le noyau Linux 2.6.26 (ce travail est fait en collaboration avec Ingo Molnar)

• valgrind-mmt est utilisé pour tracer les accès mémoires faits par la carte

• renouveau est le premier outil historique du projet, et vise à tracer les FIFO de la carte

Il présente ensuite plus en détail les avancements du projet : en particulier, l'extension Xvideo marche mieux que le pilote binaire, et XRandR 1.2 commence à bien marcher sur les cartes récentes (code chipset supérieur à nv17). Au niveau de l'accélération matérielle (DRI), il présente la bibliothèque gallium3d qui vise a factoriser du code entre les pilotes.

Ensuite, quelques mots sur le kernel modesetting qui vise a intégrer xrandr dans le noyau Linux, ce qui pose le problème d'un intérpréteur de bytecode dans le noyau. Dans tout les cas, le support pour le suspend/resume avec nouveau en dépend, donc ca finira par arriver..

Il termine en expliquant que si le projet n'a pas encore fait de release, c'est que les choses changent a grande vitesse, que les API ne sont pas du tout stabilisées, et que ce serait une perte de temps de devoir maintenir des releases avec des API figées. Enfin, une petite démonstration avec OpenArena tire des salves d'applaudissements de la salle.

Olivier Fourdan - Xfce

Le hasard du FOSDEM fait que je tombe sur Olivier Fourdan, créateur du projet Xfce, et il à bien voulu répondre à mon grand plaisir à quelques questions sur l'historique du projet, quelques anecdotes, et quelles sont les idées à venir pour le futur. J'essaie ici de retranscrire cette micro-interview..

Xfce est né en décembre 96, à cette époque Olivier utilisait professionnellement CDE sur HP-UX, l'interface de Windows 95 était la référence, et il n'existait pas d'alternatives convaincante sous Linux. Il décida tout d'abord d'implémenter un panel similaire au dock de CDE, le tout sous forme d'un module pour fvwm2 (qui était a l'époque un des WM les plus répandus). Ce panel utilisait le toolkit graphique XForms, propriétaire à l'époque.

En 97, Xfce dans sa version 2.0 devient un environnement plus riche, avec en plus du panel un gestionnaire de fenêtre à part entière, xfwm, se basant sur un fork de fvwm2 allégé, avec déjà des possibilités de personnalisation avancées de l'affichage. Olivier est alors contacté par Miguel de Icaza, qui lui demande de porter son panel sur la bibliothèque GTK en vue d'une inclusion dans ce qui allait devenir GNOME. Par manque de temps et de motivation, Olivier ne donne pas suite, mais l'idée de l'utilisation de GTK fait son chemin, car de plus en plus de désagréments se font sentir avec l'utilisation d'un toolkit propriétaire (toujours XForms).

En 99, Xfce3 voit donc le jour, et est le résultat de la réécriture complète en GTK du gestionnaire de fenêtres et du panel. De nouveaux outils voient le jour, comme le gestionnaire de fichiers xftree, et du fait de l'utilisation d'un toolkit sous GPL, le projet connaît une exposition grandissante et de plus en plus de contributions et patches voient le jour. A ce moment, l'équipe de développement atteint 3 personnes. Plusieurs versions de Xfce3 voient le jour avec ces nouveaux outils, particulièrement Xfce 3.6 et Xfce 3.8 mais toujours basés sur GTK1.

En 2004 et après un long cycle de développement, Xfce 4.0 sort enfin : c'est encore une réécriture majeure, cette fois ci basée sur GTK2, et visant a supporter le plus possible les standards portés par freedesktop.org. De nouveaux outils apparaissent, comme le gestionnaire de fichiers xffm (pour son interface et son mode de fonctionnement particulier, il sera décrié par certains et adulé par d'autres), un gestionnaire de réglages (le mcs-manager), un gestionnaire de bureau (xfdesktop, qui a ce moment proposait juste une gestion du fond d'écran, de la liste des applications ouvertes, et un menu de lancement d'applications) et enfin un tout nouveau gestionnaire de fenêtres, xfwm4, basé sur oroborus (quoique peu de code encore reste de cette filiation). Les développeurs d'Xfce sont alors environ une demi-douzaine, et la popularité de cet environnement de bureau est grandissante.

En janvier 2005 sort Xfce 4.2, avec l'apparition d'un gestionnaire de sessions, l'utilisation grandissante de D-BUS pour la communication interne entre les divers composants, des fonctionnalités avancées de composition dans xfwm4, un nouveau terminal, et de plus en plus de plugins pour le panel écrits majoritairement par des utilisateurs. Après un an et demi de développement, Xfce 4.4 sort mi-2006, avec beaucoup de changements en interne invisibles, et comme principales nouveautés un gestionnaire de fichiers simple (Thunar), un panel complètement réécrit (les plugins sont maintenant des processus à part entière), un compositeur grandement amélioré (d'ailleurs le gestionnaire de fenêtres de GNOME Metacity utilise le code de xfwm4 pour cette partie) et le support des icônes sur le bureau, ainsi que des applications minimisées via xfdesktop. Les développeurs sont alors au nombre d'une petite dizaine, avec de plus en plus de petits contributeurs et traducteurs.

Les développeurs ne se reposent pas sur leurs lauriers, et des grands chantiers sont déjà en cours pour ce qui deviendra Xfce 4.6 : un gestionnaire d'archives (Squeeze) et un afficheur d'images (Ristretto) sont déjà sortis, une refonte du gestionnaire de menus et de la configuration est en cours (avec toujours plus de D-BUS et de normes freedestkop.org en interne). D'ailleurs Xfce est candidat au Google Summer of Code 2008, en espérant que le projet soit accepté.

Pour finir, Olivier me donne son avis sur compiz : il pense que c'est un très bon projet, et pense qu'a terme xfwm4 pourrait être modularisé pour aussi pouvoir faire office de décorateur pour compiz. Il déplore le fait de ne pas avoir de date de sorties fixes, et espère pouvoir pousser vers un modèle de développement basé sur le feature freeze plutôt qu'ajouter sans cesse des nouveautés et repousser sans cesse la sortie (comme ce qui avait eu lieu avec Xfce 4.4). L'équipe de développement étant toujours très restreinte, il insiste sur le fait que les goodies écrites par les utilisateurs sont très importantes en tant que point de départ à l'utilisation des bibliothèques fournies par Xfce, afin d'attirer de nouveaux développeurs. Il répond aux critiques sur la lenteur supposée d'Xfce sur certaines machines par le fait de devoir faire un compromis entre la légèreté et le support des standards, ainsi que des nouvelles fonctionnalités apportant un réel confort d'utilisation. Finalement, nous concluons cette interview autour d'une bonne bière, Xfce est vraiment une très belle success story !

Pour ma part, j'ai été vraiment enchanté de faire sa connaissance, et je compte bien participer de plus en plus au développement d'Xfce. et rappelez vous, le code n'est pas tout, une part importante de travail est faite du coté de la documentation et des traductions.

Bill Hoffman - CMake

L'orateur commence par se présenter devant une salle peu peuplée : il est vice président de Kitware, une société développant divers toolkits utilisés surtout dans la visualisation 3D médicale (VTK, ITK et Paraview). Cette société est sponsorisée par divers laboratoires médicaux, et à tout d'abord développé CMake pour son besoin personnel avant de le mettre à disposition de la communauté sous licence BSD.

PostgreSQL 8.3 performance

Présentation de benchmarks MySQL/PostgreSQL (sysbench) par Simon Riggs.

Globalement, dans beaucoup de cas de figure, PostgreSQL se comporte beaucoup mieux que MySQL. À noter que sous de forte charges, les performances de PostgreSQL ne se dégradent pas comme avec MySQL, elles restent relativement stables, avec toutefois une petite inflexion, mais dans des proportions très raisonnables.

Il existe une limite sur 8.2 autour de 20 threads en lecture et pour 8.3 autour de 64 threads. Ces limites concernent surtout les opérations de lectures.

Bien entendu, on peut avoir des charges mélangées, et ça continue de fonctionner normalement, les threads qui gèrent les lectures continuent à rester scalable.

Les tables plus petites tiennent en cache et ont des meilleurs performances que les autres, en plus d'être plus faciles/rapides à récupérer sur disque.

Il sera possible de mixer les requêtes synchrones et asynchrones sur une même table.

Il sera possible de désynchroniser le commit au niveau serveur / utilisateur / transaction.

HOT (Heap Only Tuples) est une technique qui permet la réutilisations de pages pour éviter les VACUUM sur une table entière.

Update on virtualization in Debian

Henning Sprang fait un tour d'horizon des différents outils disponibles dans Debian pour la virtualisation ou l'émulation.

Les variantes sont Xen, KVM, VServer, VirtualBox, UML, OpenVZ et Qemu.

libvirt est intégré. Initialement développé par Red Hat il est disponible sous licence GNU GPL. Il fournit une bibliothèque d'abstraction des technologies de virtualisation (pour l'instant Xen et Qemu/KVM) sur laquelle on peut s'appuyer pour développer des outils de gestion. virt-manager est une interface graphique d'administration utilisant libvirt.

Le support de Xen a été ajouté récemment dans unstable.

Pour le Desktop, il est peut-être préférable d'utiliser VirtualBox, développé par une société allemande. On peut l'envisager comme une alternative à Vmware Workstation. Le projet est actif et réactif.

Quelques outils viennent d'ajouter, comme autopkgtest-xenlvm ou autopkgtest.

KVM, Vserver et OpenVZ sont régulièrement mis à jour.

Les outils de gestion graphique de Qemu sont nombreux. Qtemu (disponible dans Lenny/Sid), qemu-launcher (plus difficile à appréhender mais avec plus d'options) Qemu-monitor (monitoring, lancé seul ou par qemu-launcher), qemulator (dans Lenny/sid) a une interface complexe avec toutefois un peu moins de fonctionnalités que qemu-launcher.

Les paquetages de Xen 3.2 on été rendus disponibles peu après la publication de Etch.

Pour Xen, il y a aussi de nombreux outils.

xen-tools est un ensemble de scripts en Perl, simples, qui utilisent des modèles pour générer des fichiers de configuration et qui démarrent ensuite des DomU. C'est une nouveauté de Lenny. Il est possible de configurer un NFS root et d'utiliser conjointement FAI. Les outils ont des noms comme xen-create-image, xen-delete-image, et de nombreuses options de configurations sont décrites, pour les schémas de partitionnement dans /etc/xen-tools/partitions.d/*.

xen-shell propose des commandes de base, comme la connexion via SSH et les manipulations classiques sur les DomU. Les permissions sont définies dans le fichier de configuration.

Update on Debian on inexpensive NAS devices

Martin Michlmayr revient pour une nouvelle présentation, qui porte le même nom que celle de l'année dernière. C'est donc un rafraîchissement. Et effectivement, il y a du changement.

Les NAS dont il parle sont des petits boîtiers vendus pas très cher qui embarquent éventuellement des disques, mais qui ont surtout un CPU, de la mémoire, et une interface série. On peut donc les assimiler à des ordinateurs.

En un an, les prix ont baissé. La gestion de l'alimentation est plus efficace.

Quelques appareils ont retenu son attention. Le slug, ou NSLU2 vendu autour de 85 EUR. Son nom doit vouloir dire qu'il est lent (slow). Il est surtout silencieux et il est possible de mettre à jour son firmware à travers le réseau. En fait, il est possible de faire tourner un OS uniquement sur la mémoire flash interne. Mais certains utilisateurs ont eu quelques mauvaises surprises en essayant de faire ça. Du coup Martin rétorque généralement : « Pourquoi avez-vous fait ça ? », même si la plupart du temps tout se passe bien.

L'inconvénient de cet appareil est qu'il faut utiliser un microcode propriétaire pour la carte réseau. On peut aussi lui reprocher d'avoir peu de mémoire (32 Mo si la mienne est bonne).

Il y a des travaux en cours dans l'installeur Debian pour intégrer ce microcode. En l'état, Martin considère le support de cet équipement complet, en phase de maintenance. Les paquets à utiliser seront nslu2-utils et ixp4xx-microode.

Le problème du driver d'Intel est qu'il est libre, mais qu'il utilise une bibliothèque propriétaire, et qu'il ne peut pas être intégré au noyau Linux pour cette raison. Un développement est actuellement en cours, et sera peut-être disponible pour 2.6.26.

Le Thecus N2100 est un appareil aussi intéressant, il dispose de plein de connectique, de plein de mémoire, de plein de CPU, et il est en outre possible d'ajouter de la mémoire, mais il est cher, et le ventilateur souffle sur l'arrière du disque, pas sur le disque lui-même. Il coûte environ 400 EUR.

Il y a d'autres appareils qui ne seront pas supportés. Par exemple, le NAS de Iomega est utilisé par trop peu de gens. Le Freecom fsg3 n'a pas assez de RAM (4 Mo). Le Kuro ne sera pas non plus supporté.

Orion est ce que l'on qualifie de « system on a chip ». Marvel travaille beaucoup avec la communauté et a d'ailleurs embauché des personnes qui travaillent sur les drivers libres. Il y a déjà le support de la carte Ethernet et le support de sata_mv dans le noyau. L'année dernière, Martin était sceptique, mais il a été très heureusement surpris du travail de Marvel et du bon support qui en résulte.

Le QNAP est un appareil solide, silencieux, mais l'installation initiale est pour le moment obligatoirement sous Windows ou Mac OS. En fait, il y a un firmware initial avec une configuration minimale. On doit utiliser un outil appelé le finder qui se connecte, récupère l'ID du disque, crée une table de partition en dépose quelques fichiers. Comme on ne peut pas décemment demander à des utilisateurs de Debian d'installer un Microsoft Windows en pré-requis, Martin a bricolé manuellement cette étape. Il est parvenu à déposer un firmware, puis exécuter un sshd et se connecter pour lancer debinstall. En fait, QNAP est intéressé pour un support plus large. L'appareil (en fait, il y a une gamme d'appareils) peut recevoir de un à quatre disques.

Le HP Media Vault est silencieux, il a un tftp pour la dépose de fichiers, et il est facile à utiliser, mais il n'y a pas pour le moment de support matériel dans le noyau (réseau et stockage). Pour corser le tout, il n'y a pas de documentation disponible, mais des requêtes pour avoir accès à la documentation sont en cours.

Tous les futurs appareils seront vraisemblablement basés sur des puces Orion.

Les prérequis des développeurs et des utilisateurs sont très différents. Le développeur a besoin d'une connexion série, alors que l'utilisateur aura besoin d'un client SSH, d'une connexion à Internet, mais pas de console série ni d'opérations manuelles.

L'approche générale pour l'installation de la distribution sur les NAS est tout d'abord de déposer un firmware qui est en fait le Debian installer. Ensuite, il faut redémarrer l'appareil, récupérer quelques valeurs via SSH après le boot sur l'installeur, dérouler une installation normale, et terminer par un reboot sur le disque.

Quelques soucis peuvent apparaître à ce niveau, Si certains paramètres ne sont pas fournis avant l'installation, l'installeur va passer en mode interactif et demander des valeurs (par exemple DNS) alors que le réseau n'est pas démarré. Martin va blinder cette partie pour éviter ces blocages.

Les autres petits malheurs que l'on peut avoir concernent l'installation d'un disque supplémentaire. Il n'y a pas de nommage constant des disques.

À l'avenir, Martin envisage de supporter beaucoup de matériels suplémentaires, d'utiliser udev pour pouvoir avoir un nommage persistent des disques. Il va certainement éclater netcfg pour ne pas fournir tous les paramètres réseau à l'avance, fixer l'adresse MAC, développer rescue sur la mémoire flash, avec un serveur SSH. Il propose aussi l'installation sur des MTD flash, le support des systèmes avec seulement 4 Mo de mémoire, et l'écriture d'un finder pour QNAP.

Quelques questions arrivent à propos du support de NFS3 sur TCP qui a disparu, mais qui pourra être ajouté avec des options différentes pour la construction. En fait, il n'aurait pas dû partir et il devrait revenir sur les versions suivantes.

Le support de RAID est possible dans l'installeur.

Un utilisateur demande si le support de ator est envisageable. Ce n'est clairement pas possible dans les slug mais possible avec les Orion parce qu'ils ont un support cryptographique.

Présentation de Miro

Je pensais assister à une autre présentation, mais une salle a changé de nom, et ce qui était la veille la salle OpenSuSE est devenue dans la nuit la salle Mozilla. Bien entendu, la salle Mozilla est devenue OpenSuSE.

Beaucoup de monde a déjà téléchargé Miro. C'est un WebTV player libre. Il est disponible pour de nombreuses plate-formes.

Avec 2 millions de téléchargements en 2007, ils espèrent atteindre les 6 millions en 2008.

System imaging with KIWI

Il faisait une chaleur incroyable dans cette salle. C'était à peine croyable.

La présentation commence par un tour de l'auditoire rapide pour savoir qui utilise des systèmes d'images, et pour quels usages.

Quelques participants font des images USB, d'autres des images ISO pour de CD ou des DVD.

kiwi est un outil en ligne de commandes. Il n'est pas prévu pour être utilisé directement, mais plutôt pour être intégré dans d'autres outils de plus haut niveau ou pour être intégré dans une chaîne d'outils.

En fait, ce n'est pas un produit.

En plus des images de systèmes sur CD ou DVD, il permet de faire de images sur clefs USB. Le but de la démonstration est justement d'essayer un « system on a stick ».

kiwi est utilisé pour SLEPO (SuSE Linux Point Of Sale) et pour SLETC (SuSE Linux Thin Client).

Il peut être utilisé pour créer des images de préchargement de systèmes d'exploitation pour des fabricants de matériels, pour générer des live CD (par exemple ceux de KDE et d'OpenSuSE) ou des CD ou des clefs USB de secours (rescue).

Il peut aussi être utilisé pour générer des images de systèmes (Qemu, Xen, VMware).

La description de ce que l'on souhaite obtenir est réalisée dans un document XML, où l'on définit des priorités dans les repositories, des exceptions. Il est possible d'implémenter des scripts (hooks).

En fait, c'est puissant et ça permet de faire plein de choses, mais il faut vraiment apprendre à utiliser Autobuild pour créer des listes de paquets et des scripts.

Un auditeur demande quelques précisions sur les modes, propriétaires et contextes SELinux qui peuvent être définis. La réponse est un peu floue.

Un autre auditeur trouve que le document XML de configuration de l'image à générer ressemble à celui de YaST. Comme il s'agit de deux outils totalement différents, la ressemblance est fortuite.

À la fin de la présentation, nous avons une demo de boot d'un portable sur une clef usb. L'initrd est un gros script shell.

Introduction to CentOS

Je suis arrivé un peu en retard pour cette présentation de CentOS par Fabian Arrotin. Pour mémoire, CentOS signifie « Community Enterprise Operating System ».

Les avantages et inconvénient de la distribution, avec les architectures supportées Les architectures Alpha et Sparc sont supportées en CentOS 4. Pour CentOS 5, les architectures supportées sont en plus PowerPC 32, PowerPC 64 et Sparc.

L'intérêt de cette distribution est les 7 ans de mises à jour.

Pour l'essayer, il y a un bon nombre de Live CD et de projets annexes :

• Project cranberry pour un système avec plein d'outils de récupération ;

• Pandora est un outil d'exploration de paquetages ;

• Dasha est un projet qui vise à apporter des drivers supplémentaires ;

Les dépôts de paquets (repositories) sont nombreux.

• Base contient les paquets de la distribution standard ;

• Updates contient les mises à jour pour le repository Base ;

• Extras contient des paquets supplémentaires comme freenx, heartbeat, drbd. Ces paquets n'existent pas upstream, et n'écrasent pas ceux de Base ;

• CentOSplus contient des paquets qui n'apparaissent pas upstream, et d'autres qui peuvent écraser les paquets upstream (xfs, resiserfs, jfs, Postfix+MySQL) ;

• De nombreux autres dépôts externes existent, comme rpmforge (dag, dries, others), ATrpms, KBS-Extras (rebuild of Fedora for CentOS) ou EPEL (Extras Packages for Enterprise Linux qui proviennent du projet Fedora) ;

Quand on mélange des dépôts de différente origine, c'est une excellente idée d'utiliser le plugin priorities de yum.

Update sur LVM2

Alasdair Kergon fait tourner sa présentation sur un portable Mac. Il n'a pas de slides, mais juste une petite note en papier avec la liste des choses dont il doit parler. Après quelques soucis de microphone, il abandonne et demande : « Si je crie, ça vous va ? » et la salle de crier « Oui ! »

Il présente l'avancement de LVM2 depuis l'année dernière.

Les opérations de redimensionnement se font toujours en deux temps. Par exemple, lors d'un agrandissement d'un système de fichiers, il faut au préalable agrandir le volume logique sous-jacent. Pour la réduction, il faut procéder à l'inverse, c'est à dire réduire le système de fichiers, puis réduire le volume logique.

Il ne faut évidemment pas le faire dans le mauvais ordre si l'on tient à ses données. Justement, pour simplifier la gestion des systèmes de fichiers, un outil fsadm est en cours de développement. C'était au départ un binaire en C et c'est devenu un script shell. Il s'agit de fournir un outil générique, un peu comme fsck ou mkfs qui permet de gérer des systèmes de fichiers ext2, ext3, xfs, reiserfs, gfs et éventuellement d'autres. À terme, il devrait aussi supporter les cryptfs.

Ci-après, quelques nouvelles syntaxes possibles :

 # crée un volume logique qui consomme tout l'espace libre
 lvcreate vg1 -l100%FREE

 # supprime tous les volumes logiques de ce VG
 lvremove vg1

 # crée un volume logique qui consomme un quart du VG
 lvcreate vg1 -l25%VG

 # suppression d'un volume logique
 lvremove vg1/lvol0

 # doublement de la taille d'un volume logique
 lvextend vg1/lvol1 -l+100%LV

On peut configurer le readahead sur un volume logique, dans la commande lvcreate avec l'option readahead.

L'un des soucis que l'on rencontre quand on a des nombreux volumes physiques, par exemple quand on utilise quelques dizaines voire centaines de LUN est l'absence de cache. En effet, les metadonnées des VG sont copiées sur chaque devices.

L'absence de cache se justifie pour les exécutions de commandes de manipulation des objets exécutées en parallèle. Dans cette situation, pour éviter la corruption, un verrou est posé, et la seconde commande est bloquée en attente de la levée du verrou. À ce moment, comme les metadonnées peuvent avoir changées, il faut à nouveau toutes les relire.

Une solution est de mettre en place un cache interne pour les commandes qui ne nécessitent pas la pose d'un verrou, et de les lire quand on ne peut pas faire autrement. Une autre solution envisagée est de mettre en place un daemon, à l'instar de ce qui existe pour clvmd.

Par défaut, les metadonnées des VG sont copiées sur sur chaque périphérique, mais pour des centaines de volumes physiques, ça peut représenter un nombre de copies et de lectures conséquent. On peut aussi spécifier un nombre de copies spécifiques. Si on choisit deux copies, il y en aura un au début et un à la fin, ce qui est d'ailleurs cohérent avec les volumes créés avec mdadm qui stocke les métadonnées à la fin. Le fait de stocker les métadonnées à la fin permet aussi d'éviter la perte intégrale des données en cas d'effacement accidentel à coup de dd.

Un nouveau chantier concerne la notification en espace utilisateur avec dm-eventd. Par exemple, en cas de panne d'un miroir pour puiser dans une réserve et utiliser un volume de secours, ou appliquer toute règle, comme par exemple agrandir automatiquement un snaphot.

dm-eventd est utilisable pour faire une sorte de gestion du système. Le but serait de fusionner dm-eventd et lvmd pour éviter les recoupement de fonctionnalités.

Le binaire statique va disparaître. Il posait le problème de la maintenance de deux copies de LVM. Le LVM dynamique utilise la glibc de base et la glibc sera dans l'initrd. C'est par exemple possible dans Fedora 9. Si la version statique n'est maintenue par personne, il est tout à fait possible qu'elle meure.

La gestion des sources de LVM et LVM2 est dans deux branches CVS. Malheureusement, il n'y a pas de merge possible. LVM2 restera LVM2. Quand les arbres seront stabilisés, une migration vers git est envisagée.

lvmdump est utilisable pour le diagnostic. Il produit une tarball de toutes les metadata pour le cas où l'on fait un appel au support.

Il y a eu quelques changements à vgsplit. Ce qui suit est équivalent à un vgrename.

 vgsplit vg1 vg3 /dev/loop0 /dev/loop1

Alasdair termine avec quelques commandes d'affichage des segments. Comme il travaille sur la version de développement, il met en lumière un bug dans la gestion du cache pendant la démonstration.

 lvs --segments -o+devices
 lvs --segments -o+devices -v
 pvs --segments
 pvs --segments -v

Le dernier champ peut être utilisé dans les commandes comme pvmove. Et c'est très pratique pour migrer des données avec une granularité très fine.

search.postgresql.org

2-phase commit for PostgreSQL

Heikki Linnakangas, un développeur principal de PostgreSQL parle du 2-phase commit.

Il y a besoin d'un resource manager. Quand un resource manager accepte un PREPARE, il dit en gros « je pourrai valider dans tous les cas ». Le PREPARE est un point de non-retour.

Le « commit to committing » valide la transaction sur disque.

Le COMMIT final valide le résultat auprès du resource manager.

Ce mécanisme est aussi fiable que le moins fiable de tous les resource managers, du réseau, ou du transaction manager lui-même.

Le problème est que le 2PC est lent (3 fsync() par resource manager).

C'est implémenté dans 8.1 et supporté par le driver JDBC.

Il y a une vue système pg_prepared_xacts pour voir les transactions préparées.

Normalement, ls 2PC est utilisé par le middleware et par PostgreSQL lui-même mais pas par les applications elles-mêmes.

PREPARE TRANSACTION ressemble à COMMIT (les triggers sont exécutés, les ressources sont libérées, les verrous sont posés ou libérés et l'état des événements est enregistré dans un fichier (pour un rollback sur un serveur arrêté, il suffit de supprimer le fichier).

Les transactions en attente de fermeture inhibent le VACUUM. Tous les verrous sont tenus en attendant le deuxième COMMIT.

Il n'y a pas de support complet de JTA dans Java. Mais certains Transaction Managers (TM) comme JBoss, Jonas, Bitronix TM et Weblogic sont compatibles.

La phrase suivante est effrayante, mais je n'ai aucune idée de traduction plus claire, désolé. Certains serveurs d'applications ont besoin de flags dans la configuration de la datasource pour désactiver l'interleaving de transactions ou le suspend/resume.

Le 2PC n'est pas la panacée. Avant de commencer à l'utiliser, il faut s'assurer qu'il y en a vraiment besoin. Il y a besoin de beaucoup de pré-requis, il faut tester énormément de choses, pour des transactions concurrentes, il faut des resource managers, prévoir le failure recovery.

Une astuce : max_prepared_transactions = max_connections

Et pour aller plus loin, il faut savoir comment gérer les transactions orphelines, le 3-phase commit (3PC), qui est complexe avec des heuristiques pour les abort/commit.

RoR on FreeBSD

Le planning ne faisait pas état de la modification, mais la présentation de pbi comme nouveau système de gestion de paquets a été remplacée par une démonstration de Ruby On Rails au pied levé.

Il n'y avait pas de feuilles, juste une démonstration.

End-user migration from Linux to FreeBSD

Gregory Holland présente les différentes étapes à envisager pour une migration d'un utilisateur de Linux à BSD.

Tout d'abord, il parle des caractéristiques similaires, comme la gestion d'utilisateurs multiples, le multitâche préemptif, la mémoire protégée, et les couches de compatibilité avec d'autres systèmes d'exploitation comme Linux, d'autres BSD et SCO, par exemple.

Comme il y a certaines divergences, il en présente quelques-unes, en particulier pour établir des alias entre noeuds de périphériques, en générant automatiquement des liens symboliques à l'aide d'entrées dans /etc/devfs.conf, ce qui évite de régénérer ces liens systématiquement. Cette astuce permet d'associer des noms de périphériques humainement lisibles à des noms moins connus.

Pour compléter les applications en espace utilisateur, Gregory rappelle l'existence des ports et les commandes d'administration pour les recherches, les installations, les suppressions.

Enfin, pour une similitude encore plus complète, il suggère des modifications de xinitrc, de loader.conf, etc.

PostgreSQL HA options

Simon Riggs revient après sa présentation des améliorations de performances dans 8.3.

La présentation concerne à la fois la réplication et la récupération (replication and recovery) pour 8.3 et pour les futures versions.

Pour la réplication, slony transmet les différences sur un second serveur inactif (qui ne traite pas de requêtes) et gère le VACUUM sur les tables.

Une solution de multi master replication existe déjà. Elle a été développé pour un client de 2ndQuadrant (la société de Simon Riggs) mais pas disponible en open source. Un accord devra être trouvé, mais l'intégration est prévue dans le futur à slony.

Pour le recovery, quelques techniques sont suggérées.

• Le PITR, pour point in time recovery permettent de revenir dans le passé à un point défini sur toute une base de données.

• Un cache de relations supprimées permettrait de récupérer une table supprimée accidentellement. Il faudrait régler une taille de cache par tablespace :

   ALTER TABLESPACE tsname SET dropped_relation_cache = 10GB;

• Inclusion/exclusion de tables, tablespaces ou index lors des récupérations

• Optimisation des resource managers (btree, GIN)

• Global restore points

  Cette technologie permet d'écrire des points de restoration toutes les n minutes pour permettre un rollback sur toute une base.

  Cette technologie ressemble à Oracle Flashback. Néanmoins, implique beaucoup de changements et ce n'est pas possible pour 8.4.

  Quelques problèmes restent à régler concernant les blocages et les pertes des performances pour les VACUUM et de suppression des snapshots intermédiaires.

Les développements sur la réplication sont les suivants :

• hot standby

• synchronous replication

  Les commit peuvent être asynchrones ou synchrones mais il n'est jamais pertinent de faire un commit synchrone après un asynchrone.

  Un des modes de slony permet de faire SAS (synchrone-asynchrone-synchrone), ce qui n'est pas judicieux.

  Ce mode devrait disparaître parce que non-performant dans tous les cas.

• log-based replication

  slony est trigger-based.

  Si on ajoute les instructions de langage de définition de données (DD)L, il serait possible de répliquer vers n'importe quelle autre base de données, comme par exemple Oracle ou MySQL. L'idée me séduit, et je vote avec une minorité d'autres auditeurs pour cette suggestion.

  Le choix pour les réplications synchrones a remporté l'adhésion.

Pour les futurs développements sur le recovery, trois pistes sont envisagées :

• Recovery parallelism

  Cette technologie permettrait de faire tourner la récupération sur plusieurs processus en parallèle.

• WAL compression

• xlogdump

  Cet outil, laissé un peu de côté, permet de regarder le contenu des logs.

La majorité des auditeurs vote pour le parallélisme.

Conclusion

Ce fut encore une excellente édition de cette conférence internationale, avec beaucoup de représentants de nombreux projets.

Les appareils très mobiles, comme les eeePC et autres Nokia n800 et n810 prolifèrent. Il y en avait à tous les coins de salles. En outre, un tirage au sort pour gagner cinq n810 a aussi été organisé.

Auteurs

Laurent Gautrot et Landry Breuil