
Prochaines sessions de formation Linux embarqué et noyau Linux à Toulouse
Les sessions de formation Linux embarqué et noyau Linux que j'ai animé au mois de mars à Toulouse ayant été un succès, j'animerai à nouveau deux nouvelles sessions publiques de formation :
Comme pour toutes nos formations: les supports sont librement disponibles en ligne (vous pouvez donc vérifier le contenu avant d'acheter la formation), les TPs se font sur une carte ARM que chaque participant conserve à l'issue de la formation. Le tarif est de 1950 Euros HT par personne, mais il y a une réduction de 20% si l'inscription est reçue avant deux mois avant le début de la formation, ou pour les personnes venant de la même société.
Ouverture d'un poste à Free Electrons
Dans la perspective de l'ouverture d'un bureau à Toulouse,
Free Electrons, la boîte pour laquelle je travaille, recherche un
ingénieur jeune diplômé pour travailler sur des projets Linux embarqué.
L'annonce, à l'adresse
http://free-electrons.com/fr/blog/recrutement-toulouse-2010/ donne tous les détails.
Mode Javascript pour Emacs
Le mode Javascript disponible par défaut dans Emacs est vraiment pourri, il ne sait même pas indenter proprement le code. Du coup, je vous recommande
Espresso, un mode Javascript pour Emacs qui est bien plus utilisable.
Buildroot 2010.05
Buildroot 2010.05 est sorti juste à temps, le 30 mai. Je continue à contribuer de manière assez active au projet, et c'est assez plaisant: j'ai enfin trouvé un projet sur lequel j'arrive à m'investir sur une durée suffisamment longue pour contribuer de manière significative, être en mesure de répondre aux retours des utilisateurs, relire les patches pour les valider, etc. Sur cette release, j'ai notamment réalisé la ré-écriture complète du code de génération des systèmes de fichier racine, le support des toolchains externes multilib et pas mal de cleanup de code. Voir
le billet sur le blog de Free Electrons pour tous les détails.
Séminaire « Linux et le temps réel », 5 mai à Toulouse
Alors que je suis bloqué à San Francisco depuis 4 jours, où je venais participer à l'
Embedded Linux Conference, une petite annonce concernant un séminaire d'une journée, gratuit après inscription, qui aura lieu le mercredi 5 mai à Toulouse, toute la journée. Il aura pour thème
« Linux et le temps réel ».
Le résumé du séminaire est le suivant :
Linux est un système d’exploitation libre dont l’utilisation dans des contextes embarqués est déjà forte et croît d’année en année. Ces contextes embarqués sont notamment dans des cadres industriels souvent associés à des problématiques temps réel. Au travers d’un séminaire d’une journée, nous vous proposons de faire un état des lieux des solutions temps réel pour Linux puis de procéder à la mise en œuvre des solutions PREEMPT_RT et Xenomai sur une carte de développement ARM.
Programme complet:
http://www.captronic.fr/documents/documentsAssocies/Viratelle/invitation-seminaire-linux-temps-reel-toulouse-5-mai-2010.pdf
Inscription:
http://www.mp-i.fr/2010/03/24/linux-et-le-temps-reel/
Contributions à Buildroot
Je n'en ai pas parlé depuis un moment, mais je continue à contribuer activement au projet
Buildroot, un outil de construction de systèmes Linux embarqué.
Pour la release 2009.11, j'ai notamment travaillé sur une simplification de l'arborescence générée par Buildroot lors de la compilation, qui était devenue difficile à comprendre pour un nouveau venu. Je l'ai détaillé sur un
post du blog de Free Electrons.
En octobre 2009, j'ai également organisé la première édition du
Buildroot Developer Day à Grenoble, auquel se sont joints 8 personnes. Ce fût une journée très intéressante, notamment parce qu'elle a permis de rencontrer de visu les contributeurs les plus actifs.
Pour la release 2010.02, j'ai notamment travaillé sur une nouvelle infrastructure pour la gestion des paquets, qui diminue grandement la quantité de code dupliquée et va nous permettre à l'avenir de faire des changements plus facilement sur l'ensemble des paquets. J'ai aussi travaillé sur l'amélioration de la documentation du projet, sur la simplification de certains aspects, et sur de très nombreux correctifs d'erreurs de construction (grâce à un accès à une machine de build puissante qui m'a été fourni). Pour cette release j'ai été le premier contributeur en nombre de patches au projet, grâce au temps que Free Electrons me permet de consacrer à ce type de projet. Voir
ce billet pour tous les détails.
En février 2010, j'ai organisé une autre journée de travail sur Buildroot, plus confidentielle, avec seulement trois contributeurs: Peter Korsgaard, le mainteneur de Buildroot, Yann E. Morin, le mainteneur de Crosstool-NG et moi-même.
Pour la release 2010.05, j'ai encore plein de projets, dont certains sont déjà implémentés ou en cours d'implémentation. Il s'agit surtout de poursuivre le travail de nettoyage et de simplification entrepris depuis janvier 2009, quand le projet a été repris. D'ailleurs, on note une augmentation du nombre de retours des utilisateurs, ce qui veut dire soit que nous faisons un logiciel pourri, soit que notre base d'utilisateurs augmente.
Enfin notons que Buildroot a fait l'objet de deux articles dans le dernier hors-série de Linux Magazine. Voir
ce billet pour plus d'infos concernant ce numéro que je conseille fortement d'acheter à tous les amateurs de développement embarqué.
Places gratuites dans des formations noyau Linux et Linux embarqué à Toulouse
Au mois de mars 2010, j'animerai deux formations à Toulouse :
- Une formation développement noyau Linux, du lundi 8 au vendredi 12 mars 2010. Cette formation est conçue pour les ingénieurs qui souhaitent développer ou améliorer des pilotes de périphériques dans le noyau Linux, pour des projets sur plateforme embarqué ou sur plateforme PC traditionnelle. En cinq jours, au travers de cours théoriques et de travaux pratique, la formation introduit les bases essentielles du développement noyau : architecture du noyau, les principales APIs, intégration du pilote de périphérique avec le reste du noyau et avec les applications. Voir la brochure.
- Une formation développement de système Linux embarqué, du lundi 29 mars au vendredi 2 avril 2010. Cette formation est conçue pour les ingénieurs qui souhaitent utiliser le système Linux dans de nouveaux projets embarqués. En cinq jours, au travers de cours théoriques et de travaux pratiques, elle vous familiarise avec l’architecture d’un système embarqué sous Linux, la construction d’un tel système, la façon de tirer parti de composants open source pour accélérer l’ajout de fonctionnalités à votre système et réduire les coûts de développement, puis détaille comment développer et mettre au point vos applications dans le système embarqué. Voir la brochure.
Chacune de ces formations dure cinq jours et coûte 1950 € par participant, chaque participant repartant avec la carte de développement ARM utilisée lors de la formation.
Comme nous en avons l'habitude, nous offrons pour chacune de ces formations une place gratuite à un membre méritant de la communauté du Logiciel Libre. Si vous avez fait des contributions visibles au Logiciel Libre (pas forcément dans le domaine de l'embarqué), alors vous pouvez candidater. Évidemment, nous privilégions les étudiants, personnes en recherche d'emploi ou qui ne sont pas dans le domaine de l'embarqué, dans la mesure où les salariés du domaine peuvent faire prendre en charge le coût de la formation par leur entreprise. Voir
Free seats in our public sessions pour tous les détails.
Sessions de formation Linux embarqué et développement noyau Linux à Toulouse début 2010

La première session de formation Linux embarqué que j'ai donné à Toulouse ayant bien fonctionné, je viens de programmer deux nouvelles sessions en début 2010 : la première édition à Toulouse de notre formation au
développement noyau Linux, et une deuxième édition de la
formation Linux embarqué.
La session sur le
développement noyau aura lieu du lundi 1er au vendredi 5 février 2010. Sur cinq jours, elle couvre les principales thématiques nécessaires pour pouvoir développer des pilotes de périphériques dans le noyau Linux : architecture du noyau, configuration et compilation, modules noyau, pilotes de périphériques caractère, gestion mémoire, communication avec le matériel, gestion des interruptions, DMA, PCI,
device model, etc.
La session sur
Linux embarqué aura lieu du lundi 22 au vendredi 22 mars 2010. Sur cinq jours, cette formation permet de comprendre l'architecture d'un système Linux embarqué et de le mettre en place en pratique, en partant du bootloader jusqu'aux applications, en passant par le noyau, la chaîne de compilation croisée, BusyBox, les bibliothèques, les outils de construction, le développement et la mise au point d'applications.
Pour ces deux sessions, pas de surprise sur le formateur, ce sera moi :-)
Comme d'habitude :
- Les supports de formation sont librement disponibles sur le site de Free Electrons, donc on peut vérifier à l'avance que le contenu de la formation correspond bien aux besoins
- Les travaux pratiques, qui occupent une part importante dans nos formations, sont réalisées pour la plupart sur une carte de chez Calao Systems qui repose sur un processeur ARM
- Chaque participant repart avec la carte Calao Systems utilisée pendant la formation (ou avec une autre carte de son choix si il possède déjà la carte Calao utilisée pour la formation)
Enfin,
last but not least, nous offrons comme d'habitude une place gratuite dans chacune de ces deux sessions de formation à un contributeur méritant de la communauté du Logiciel Libre. Voir
pour tous les détails.
Conférence Linux Embarqué demain à Grenoble, puis Embedded Linux Conference
À l'invitation de la
GUILDE, je donnerai demain à 19h45 à l'ENSIMAG une conférence sur
Linux embarqué. Voir
pour les détails.
C'est assez amusant d'aller à l'ENSIMAG pour donner une conférence Linux embarqué. Un enseignant de là-bas,
Bernard Cassagne a été une des personnes qui m'a encouragé dans le projet
KOS il y a maintenant 10 ans. Et c'est très certainement le projet
KOS qui m'a poussé à m'orienter vers le monde du système/bas-niveau et qui me permet donc de donner une conférence sur Linux embarqué.
Retour aux sources, donc.
Évidemment, je ne viens pas à Grenoble seulement pour donner cette conférence. Le mercredi, je serai à l'
Embedded Systems Exhibition pour faire connaître les services de développement Linux embarqué de
Free Electrons. Puis le jeudi/vendredi, j'assisterai à ELCE. J'y animerai le jeudi un atelier de travail sur Buildroot, et mon collègue Michael Opdenacker présentera une conférence sur la réduction du temps de démarrage et animera un atelier sur la gestion de petites entreprises qui travaillent dans le monde Linux embarqué. Enfin, le samedi, j'organise et participe au premier
Buildroot Developer Day.
Semaine chargée !
Conférence sur OpenERP
Après quelques péripéties, c'est finalement une conférence sur
OpenERP qui aura lieu demain dans le cadre de la rencontre Logiciels Libres de
Toulibre. C'est Michel Renon qui a accepté d'animer cette conférence, qui aura donc bénéficier d'un temps de préparation très court, et ne sera donc qu'une introduction à OpenERP.
Si le sujet vous intéresse ou que vous souhaitez partager votre expérience sur la thématique des ERPs, n'hésitez pas à venir nous rencontrer. C'est au Centre Culturel Bellegarde, 17, rue Bellegarde à Toulouse, métro Jeanne d'Arc.
À demain !
Du nouveau dans Buildroot, booter plus vite via AT91Bootstrap et le Buildroot Developer Day
Quelques nouveaux billets intéressants sur le
blog de Free Electrons :
- Le programme d'Embedded Linux Conference Europe 2009 a été annoncé (plein de conférences passionnantes, miam!), et évidemment, Free Electrons y sera assez fortement présent. J'y animerai avec Peter Korsgaard, le mainteneur officiel de Buildroot, une BOF (session de réflexion) sur ce même projet. Mon collègue Michael Opdenacker donnera une conférence sur les techniques de réduction du temps de démarrage et animera une « Small Business BOF » consacrés aux petites entreprises du monde Linux embarqué. La société aura également un stand, partagé avec Calao Systems, sur le salon Minalogic en même temps que la conférence.
- J'organise juste après ELCE le premier Buildroot Developer Day. L'évènement est rendu possible grâce à Calao Systems pour les locaux, et Free Electrons pour l'organisation et le paiement du déjeuner pour tous les participants.
- Mon collègue Albin Tonnerre (excellent stagiaire que nous avons eu pendant quelques mois et dont le stage vient malheureusement de se terminer) explique comment réduire le temps de démarrage sur les cartes à base de processeur AT91 en supprimant U-Boot et en faisant directement charger le noyau Linux par le bootloader de premier niveau de ces cartes, AT91Bootstrap. À la clé, 2 secondes de temps de démarrage en moins, ce qui est très important quand on est dans des temps de démarrage d'environ 5-7 secondes au total. J'ai utilisé cette technique avec succès pour le projet d'un client, tout récemment.
- Enfin, quelques explications sur mes travaux de simplification de Buildroot qui ont tout récemment été intégrés. Et j'ai encore plein d'idées pour la suite.
Formation Linux embarqué à Toulouse, du 19 au 23 octobre
Au mois de juin,
j'annonçais une session de formation Linux embarqué que j'animerai du 19 au 23 octobre à Toulouse. Cette session de formation aura bien lieu et il reste encore quelques places disponibles, alors n'hésitez pas à en parler autour de vous, la prochaine session n'aura pas lieu avant un bon moment !
C'est une formation de cinq jours, qui s'intitule « Développement d'un système embarqué Linux », et qui couvre du bootloader aux applications utilisateur, en passant par le noyau, les outils de base et les bibliothèques, l'ensemble des notions nécessaires pour construire, développer, intégrer et mettre au point un système embarqué utilisant le noyau Linux et d'autres briques libres.
La formation coûte 1950 €, avec une réduction de 20% pour les personnes venant de la même société. Elle peut tout à fait s'inscrire dans le cadre du Droit Individuel à la Formation, auquel chaque salarié a droit (demandez à votre chef !).
Les travaux pratiques (nombreux !) sont effectués sur une carte de développement ARM de Calao Systems et chaque participant repart avec sa carte de développement. Et n'importe qui peut vérifier la qualité de la formation et son adéquation aux besoins, car tous nos supports de formation sont disponibles librement en ligne !
Pour plus d'informations, voir la page sur
La formation Linux embarqué à Toulouse du 19 au 23 octobre 2009.
Toulibre, Agenda du Libre, Trivialibre hors service
En raison du décès du disque dur du serveur hébergeant Toulibre, l'Agenda du Libre et Trivialibre, tous ces sites et services sont inaccessibles depuis vendredi dernier. Le disque dur a été remplacé, les sauvegardes sont en cours de restauration. J'espère un retour à la normale très prochainement.
Vidéos de l'Embedded Linux Conference 2009, le point sur Buildroot
Du coté du
blog de Free Electrons, deux nouveaux billets intéressants.
On the road to Buildroot 2009.08 qui fait le point sur la prochaine release du projet Buildroot. Je suis plutôt content, car j'ai réussi à trouver du temps pour participer de manière significative à ce projet. J'y avais contribué une première fois en 2004 en écrivant la documentation et en contribuant quelques correctifs. Mon arrivée à Free Electrons m'a permis de m'y remettre, et depuis quelques mois, j'y contribue de manière réellement régulière. Au point d'être le deuxième contributeur en nombre de patches sur la prochaine release :
$ git --no-pager shortlog -n -s 2009.05..
103 Peter Korsgaard
58 Thomas Petazzoni
13 Will Newton
11 Gustavo Zacarias
[...]
Au mois d'avril, j'étais à San Francisco pour l'Embedded Linux Conference. Comme d'habitude, nous avons filmé des conférences, avec l'aide de Satoru Ueda et Tim Bird de Sony. Nous avons je crois réussi à filmer l'intégralité des conférences, soit
45 vidéos disponibles sous licence libre, avec les liens vers les slides. À noter que coté Free Electrons nous avons également animé plusieurs conférences ou ateliers :
- Une conférence sur Buildroot, par moi-même
- Une session de réflexion sur les outils de construction de systèmes Linux embarqués (type Buildroot et autres), également animée par moi-même
- Une conférence sur les systèmes de fichiers pour Flash, par mon collègue Michael Opdenacker
- Une session de réflexion sur les problématiques de taille de système, animée également par mon collègue
Dès que j'aurai eu le temps de les extraire et de les encoder, les vidéos du thème Embarqué des Rencontres Mondiales du Logiciel Libre seront mises en ligne.
Passer d'une toolchain à l'autre facilement
Sur le blog de
Free Electrons, je viens de publier un petit billet intitulé
Switching between toolchains made easy qui donne un petit script pour facilement passer d'une chaîne de cross-compilation à une autre en modifiant la variable d'environnement PATH.
Rien de bien fantastique, mais c'est agréable de voir que quelques lignes de shell peuvent rendre bien service. En plus, la complétion est gérée, ce qui peut peut-être vous donner d'autres idées.
Concours de l'ICFP
En 2006 puis
en 2007, j'avais un peu participé au concours de l'International Conference of Functional Programming (qui n'est pas obligatoirement réalisé avec des langages fonctionnels).
Cette année, le concours avait lieu ce WE, de vendredi 20:00:16 à lundi 20:00:16. Nous avons travaillé dessus à 4, mais seulement de vendredi 20:00:16 à environ 4h du matin, soit en gros huit heures de travail sur les 72h de concours. Forcément, le
résultat est à la hauteur de notre modeste participation: l'équipe
Toulibre++ termine 307ème sur 317 participants classés. Nous n'avons en effet soumis la résolution que pour 2 problèmes sur 16. D'ailleurs, une personne de notre équipe a résolu 2 autres problèmes après notre séance de travail, mais nous ne les avons pas soumis.
Même si le concours est terminé, une petite description du sujet vous donnera peut-être envie d'y jeter un œil. Avant la publication du sujet, la FAQ du site Web disait que des indices étaient déjà en ligne. Pourtant, en regardant de fond en comble le tout petit site Web du concours, je n'avais rien vu d'intéressant. Un seul détail paraissait étrange: le démarrage du concours à 13:00:16 CDT. Pourquoi pas à 13h pile ?
Ça s'est expliqué quand le
sujet a été dévoilé : un shuttle s'est accroché à la station Mir le 29 juin 1995 à 13:00:16. Le sujet serait donc lié à l'espace. Et effectivement, l'objectif était de guider un satellite.
Le sujet se décomposait en 4 problèmes comportant chacun 4 scénarios similaires mais avec des données de départ différentes. Pour chaque problème était fourni un blob binaire, pour lequel il fallait écrire une petite machine virtuelle. Il était en effet écrit avec un jeu d'instruction assez particulier (pas de sauts par exemple, et une écriture en mémoire possible seulement à l'adresse de l'instruction), décrit dans le sujet. Cette machine virtuelle faisait donc tourner le code qui simulait le déplacement du satellite. Il fallait fournir des données en entrée (scénario utilisé, et vitesse du satellite en x et en y), et une exécution du binaire renvoyait des données en sortie (position courante du satellite, score actuel, essence restante, position à atteindre). À partir de ces données de sortie, il fallait recalculer des données d'entrée pour le prochain cycle, les injecter dans la machine virtuelle, puis relancer l'exécution du binaire.
Le développement de la machine virtuelle fût relativement simple, si ce n'est que nous avons perdu du temps sur une erreur du sujet, sur laquelle toutes les équipes ont buté (d'après ce que nous avons pu lire sur le canal IRC du concours). La description du jeu d'instruction comportait une erreur de décalage d'un bit, ce qui évidemment faussait complètement l'exécution. En bons bourrins que nous sommes, nous avons donc développé la chose en C (avec un soupçon de C++), car tout le monde ne connaissait pas le Python dans notre petite équipe. Comme quoi le «fonctionnel» dans le titre n'est pas vraiment important :-)
Une fois la machine virtuelle développée, il fallait s'attaquer aux problèmes en tant que tels. Ils relevaient finalement plus de la physique que de l'informatique pure. Dans le premier problème, le satellite que nous contrôlions était en orbite à une altitude donnée, et il fallait l'amener à une autre altitude. Évidemment, la ligne droite n'est pas la bonne solution car il n'y a pas assez d'essence pour cela. Il faut parcourir une trajectoire elliptique qui ne nécessite que deux impulsions : une impulsion pour sortir de la première orbite, puis une seconde impulsion pour se caler sur la deuxième orbite. Heureusement, ce principe était expliqué dans le sujet, et
Wikipédia donnait plus d'informations à ce sujet.
Nous nous sommes amusés à générer un fichier avec toutes les positions du satellite pour tracer avec Gnuplot la trajectoire du satellite ainsi que les orbites de départ et d'arrivée. Ce fût fort utile pour mettre au point le bazar.
Le second problème, que nous n'avons pas abordé, était assez similaire, mais il ajoutait une contrainte sur l'orbite d'arrivée : il fallait arriver au même moment qu'un satellite gravitant sur cette orbite. En bref, il fallait bien calculer le moment de départ de l'orbite initiale.
Tout cela était bien amusant, j'espère pouvoir participer à nouveau l'an prochain, peut-être en prévoyant une participation plus intensive.
Formation Linux embarqué à Toulouse, avec une place gratuite

Ça y est, la date de la première
Formation Linux embarqué à Toulouse est fixée, elle aura lieu du
lundi 19 au vendredi 23 octobre 2009. Cette formation inter-entreprises est ouverte à tous. Je serai évidemment l'animateur de cette formation, qui aura lieu en langue française. N'hésitez pas à la faire connaître autour de vous !
Quelques éléments clés :
- Cinq jours consacrés à l'apprentissage de Linux embarqué, avec de nombreux travaux pratiques réalisés sur une carte de développement ARM. Tout ce qui est nécessaire pour démarrer avec Linux embarqué est abordé: chaîne de compilation croisée, bootloader, noyau, bibliothèque C, applications de base, réutilisation de composants libres comme des bibliothèques, développement et mise au point de vos applications, etc. Voir le programme détaillé
- Chaque participant repart avec la carte de développement ARM utilisée pendant la formation. Il s'agit d'une carte assez sympathique de chez Calao Systems, avec un processeur AT91, 64 Mo de RAM, 256 Mo de Flash, de l'Ethernet, de l'USB, etc.
- La formation coûte 1950 €, ce qui comprend la formation évidemment, les supports, la carte de développement, une pause le matin et l'après-midi ainsi que le déjeuner. Nous proposons des tarifs plus avantageux si plusieurs personnes viennent de la même société ou pour les personnes en recherche d'emploi.
- Cette formation peut s'inscrire dans le cadre du Droit Individuel à la Formation auquel tous les salariés ont droit.
- Nous offrons une place gratuite dans cette session de formation à un membre de la communauté du Logiciel Libre. Cette gratuité inclut la formation, les supports, la carte de développement et le déjeuner. Voir cette page pour les détails.
Free Electrons possède une grande expérience en formation Linux embarqué. Nous avons déjà donné des
dizaines de formations partout dans le monde, pour des clients comme Freescale, Alstom, Micronas, Siemens, Marvell, Logiplus, EBV Elektronik, Orange, Nokia Siemens Networks, Asidua, Gamesa, Thales, ST Microelectronics, Motorola, Philipps, Atmel, etc. Nous mettons également publiquement en ligne les
enquêtes de satisfaction proposées à tous les participants de toutes nos formations.
Pour plus d'informations :
Haute résolution sur écran externe avec carte Intel
Sur mon sympathique portable Dell Latitude D430, je dispose d'une carte graphique Intel, et donc probablement du meilleur support X.org possible. En particulier, je suis particulièrement satisfait du support
xrandr : je donne de nombreuses formations et conférences, ce qui implique la nécessité de se connecter à de nombreux vidéo-projecteurs, et jusqu'ici aucun d'entre eux n'a résisté à
xrandr. Pas besoin de rédémarrer le serveur X, tout se fait en direct. En tout cas, en mode clone, pas de soucis (je n'ai pas essayé les autres modes).
Par contre, jusqu'à maintenant, je n'avais pas réussi à utiliser convenablement mon écran 22" dont la résolution native est 1680x1050.
xrandr ne me proposait que 1280x1024 comme plus haute résolution disponible, ce qui est peu satisfaisant. Ça fait un bon moment que j'avais connaissance du problème mais je n'avais jamais pris le temps de regarder ce qui clochait. Hier soir, après un peu de recherche Google, j'ai enfin trouvé la solution au problème... et elle a nécessité un truc que je n'avais pas fait depuis un looong moment : éditer le fichier de configuration de X.org (comme quoi les distributions GNU/Linux se sont notoirement améliorées au fil des années, car éditer le fichier de conf de X.org était monnaie courante il y a encore 5-7 ans de cela).
En fait, dans la section
Screen, sous-section
Display, il faut ajouter la ligne :
Cette option est plutôt bien expliquée dans
une page Wiki consacrée au support des portables Thinkpad sous Linux. Apparemment, lors de son lancement, le serveur X alloue une zone de mémoire permettant de stocker ce qui est affiché à l'écran, et calcule la taille de cette zone de mémoire en fonction de la plus haute résolution supportée par toutes les sorties connectées... au moment du lancement ! Donc si l'on connecte plus tard un écran externe ayant une résolution plus importante, on est dans l'impossibilité d'utiliser ce mode. Et effectivement, après l'ajout de la ligne
Virtual et connexion (après le lancement de X !) de l'écran externe,
xrandr annonce bien des résolutions supplémentaires, dont la tant attendue 1680x1050. Et le pire, c'est que ça marche. Merveilleux !
Quelques réflexions :
- J'ai édité un fichier de configuration. Ça veut donc dire que pour un utilisateur lambda, cette fonctionnalité n'est pas accessible, et c'est bien dommage. Les distributions devraient probablement faire quelque chose pour corriger ce problème. (Vous me direz que j'ai utilisé xrandr en ligne de commande, ce qui est vrai, mais je sais qu'il existe des front-ends graphiques pour Gnome et KDE)
- Pour l'instant, je n'ai réussi à faire fonctionner qu'un mode Clone. Pour un mode où les deux écrans seraient côte à côte, il faut augmenter les valeurs dans Virtual, et chez moi, cela fait crasher xfdesktop au démarrage (je suis utilisateur d'XFCE).
Hack de DOM avec GreaseMonkey
Aujourd'hui, j'avais besoin d'éditer des pages dans un
Wordpress. L'interface d'administration de la chose est plutôt agréable, mais un point me chagrinait : le formulaire servant à rédiger le contenu de la page est ridiculement petit (on doit voir 7-10 lignes maximum). Vraiment pas pratique pour rédiger une page un peu longue, on souhaite en général avoir un peu plus de contexte autour de ce que l'on est en train d'écrire.
Je fouille les options de Wordpress, je ne trouve rien. Je cherche un peu sur le Web, je ne trouve rien non plus de vraiment probant, ou alors il faut aller hacker le code de Wordpress à la main, ce qui n'était pas possible dans mon cas.
Du coup, je dégaine
Firebug, je lui dis d'inspecter l'élément
textarea qui sert de zone d'édition, et j'ajoute
height: 300px dans les propriétés CSS de la chose. Et ça marche. Génial! Sauf qu'évidemment, dès que je recharge la page, cette bidouille disparaît, et il faut recommencer à zéro.
Je me souviens avoir lu plusieurs journaux sur
LinuxFr.org (comme quoi mouler sur LinuxFr.org peut
parfois s'avérer utile) qui parlaient d'un plug-in pour Firefox permettant d'écrire des scripts pour modifier à la volée des pages HTML. Après quelques recherches, je retrouve enfin le nom de ce fameux plugin:
GreaseMonkey.
La documentation n'est pas particulièrement claire, en particulier pour débuter. Mais je suis tombé sur un
exemple Hello World simple qui a permis de démarrer. En gros, c'est tout simple :
// ==UserScript==
// @name Hello World
// @namespace http://diveintogreasemonkey.org/download/
// @description alert "Hello world!" on mypage.com
// @include http://www.mypage.com
// ==/UserScript==
alert('Hello world!');
On sauvegarde ça dans un fichier dont le nom se termine par
.user.js, et on l'ouvre avec Firefox, et paf, le plug-in
GreaseMonkey nous propose de l'installer. Une fois ceci fait, dès qu'on va charger la page
mypage.com, l'infâme boîte de dialogue Javascript s'affiche. Merveilleux. Il ne reste plus qu'à adapter l'exemple à notre problème, et ce sera très simple, puisqu'il suffira de remplacer la ligne de Javascript par :
document.getElementById('content').rows = 50;
Et hop, ça marche. Dès qu'on charge un site listé dans
@include contenant un élément d'id "content" (ce qui est le cas de Wordpress), notre script va positionner le champ "rows" à 50.
Un petit détail: une fois le fichier
.user.js installé, modifier ce fichier là ne sert à rien, car Firefox en garde une copie quelque part dans son
~/.mozila/firefox/. Il faut donc soit le réinstaller à chaque fois, soit aller dans les préférences de GreaseMonkey et utiliser le bouton
Edit pour éditer un script déjà installé.
À propos de Git

Qu'on le veuille ou non,
Git, le système de gestion version initialement lancé par Linus Torvalds pour le développement du noyau, est aujourd'hui incontournable. De très nombreux projets y passent : le noyau évidemment, U-Boot (bootloader très populaire dans l'embarqué),
Buildroot (projet auquel je contribue de temps à autre), Gnome et bien d'autres.
Sauf que Git, même quand on est familier de CVS ou SVN, ce n'est quand même pas facile à aborder. Des concepts nouveaux, des centaines de commandes aux noms un peu obscurs. Franchement, ce n'est pas facile. D'ailleurs, d'autres outils du même type comme Mercurial proposaient dès le départ une interface utilisateur plus conviviale et compréhensible que celle de Git, mais clairement, Git semble avoir gagné la bataille des outils de gestion de version distribuée. Est-ce dû à une véritable supériorité technique, ou à l'aura de son initiateur, Linus Torvalds ? Je serai tenté de dire que cette dernière raison a probablement eu une influence significative dans le succès de Git, mais je ne suis sans doute pas assez expert pour juger des finesses techniques respectives de Git et de Mercurial.
Sur Git, il y a maintenant
pléthore de documentation. Le
tutorial est un bon point de départ. Ces documentations sont faciles à trouver, mais d'autres le sont moins, et sont pourtant intéressantes :
- Deux billets de Federico Mena-Quintero, le premier et le deuxième. Ces deux billets expliquent drôlement bien ce qui se passe au sein d'un dépôt Git lorsqu'on committe ou qu'on merge des branches. En effet, un des points qui m'a donné le plus de fil à retordre lors du passage à Git, c'est la non-linéarité de l'historique. Avec Subversion, on est habité à un historique plutôt linéaire (la révision 12345 est avant la révision 12346). Avec Git, on passe à un graphe de commits, plus compliqué à comprendre.
- Git Casts contient une dizaine de screencasts expliquant progressivement comment utiliser Git. Plutôt sympathique à regarder, mais je dirai qu'il faut déjà avoir quelques notions basiques de Git (style le tutorial) pour pouvoir vraiment comprendre ces screencasts.
- Enfin, The Thing About Git explique un point particulièrement puissant de Git : la possibilité de committer sélectivement des bouts de fichiers. Supposons que vous avez travaillé sur différents trucs dans votre copie de travail, et que vous voulez maintenant committer ces différents trucs en plusieurs commits, car ils ne sont pas vraiment liés entre eux. Avec des outils de gestion de version classique style Subversion, on se retrouve à sauvegarder le patch, l'éditer à la main, bref bricoler. Avec Git, on a git add --patch qui est véritablement merveilleux : il permet de sélectionner chunk par chunk quel morceau du patch on souhaite committer. Ça et git rebase --interactive, c'est vraiment des outils très puissants.
Hackable:1 sur mon OpenMoko

Aujourd'hui, j'ai enfin pris le temps de ressortir mon OpenMoko avec l'objectif principal de faire marcher le GPS. J'ai commencé à mettre
Hackable:1, la distribution que je teste actuellement. Une nouvelle version est sortie récemment, elle apporte quelques polissages bienvenus. Le temps de démarrage est par contre toujours aussi long, sans doute parce que tout le bazar lancé par défaut sous Debian est un peu trop gourmand par rapport à ce qui est réellement nécessaire sur un OpenMoko. Par contre, niveau interface, ils sont toujours sur l'interface Gtk d'OM 2007.2 avec le gestionnaire Matchbox, et j'aime beaucoup. Beaucoup plus que le machin affreux qu'ils ont pondu pour OM 2008.X.
Coté GPS, j'ai réussi à obtenir un
fix, visible soit avec
gpspipe en ligne de commande, ou avec
TangoGPS pour une interface graphique. Malheureusement, le
fix met parfois une demi-heure à venir alors que je suis en extérieur... C'est un
problème connu, mais un fix logiciel était censé le rendre plus acceptable, ce qui n'est pas vraiment le cas ici. Sur la liste francophone d'OpenMoko, ils discutent actuellement de l'envoi groupé de téléphones vers une entreprise en Allemagne qui pourrait appliquer le
Buzz Fix (bourdonnement lors de la communication). Ça serait bien si ils pouvaient en même temps faire le
correctif matériel pour le problème d'interférence entre le lecteur SD et le GPS.
Par contre, une fois le
fix arrivé,
TangoGPS est vraiment sympathique. Il télécharge tout seul les cartes OpenStreetMap. Je me suis baladé un peu dans le quartier. TangoGPS permet de démarrer l'enregistrement d'une trace et de le stopper très simplement. Puis un
script Perl disponible sur le site de TangoGPS converti cette trace en un fichier
GPX utilisable par
JOSM pour uploader dans OpenStreetMap. Sympathique.
Coté Wifi, ils ont commencé le développement d'une petite application appelée
wifig. Elle n'est pas dans les menus, il faut la lancer depuis le terminal. Cette application permet de lister les réseaux Wifi disponibles (ça marche !) puis de se connecter à l'un de ces réseaux. Là, par contre, j'ai eu moins de succès, puisque je n'ai pas réussi à me connecter au réseau Wifi WPA2 de la Freebox. Avec le
FreeWifi, j'ai pu récupérer une adresse IP, mais je n'ai pas réussi à avoir la page de login pour donner mes identifiants
FreeWifi. Une petite investigation s'imposera un de ces jours.
Je n'ai pas retesté la téléphonie, donc je ne peux rien dire là-dessus. Sur la précédente version d'Hackable:1, ça marchait bien.
Coté application, ils ont développé un petit browser Web basé sur Webkit, à l'interface simple et bien adaptée au petit écran de l'OpenMoko. Pas mal du tout.
Enfin coté développement, j'ai vu qu'ils proposaient maintenant une infrastructure pour cross-compiler les paquets Debian pour OpenMoko, plutôt que de faire du développement natif. Le tout basé sur
Emdebian, et qui doit donc être fort sympathique. Il faudrait que je trouve le temps de tester tout ça.
Superbe présentation sur X.org hier à Toulouse
Comme je l'avais
annoncé, une présentation sur
X.org a eu lieu hier à Toulouse dans le cadre de
Toulibre. Elle était animé par Matthieu Herrb, développeur historique d'X.org et membre du Board of Directors du projet. Durant la présentation, Matthieu a même précisé qu'il avait développé le premier pilote pour joystick dans X.org (qui ne s'appelait évidemment pas X.org à l'époque). Le sujet a clairement intéressé du monde puisque 49 personnes précisément étaient présentes au début de la présentation et nous sommes montés à 55-60 personnes dans notre petite salle du Centre Culturel Bellegarde : des gens debouts, assis sur des tables, assis par terre...
La présentation a commencé par un rappel sur l'architecture client/serveur de X.org, puis s'est poursuivie par une très grande partie sur l'affichage. En partant de l'affichage 2D basique, Matthieu a ensuite présenté les différentes évolutions de l'accélération 2D puis de l'accélération 3D. De nombreux schémas venaient renforcer les explications sur le rôle des différents composants dans cette architecture. Des acronymes barbares comme GLX, DRI, GL, XAA, EXA et autres ont été discutés et expliqués de manière très didactique. Après cette longue partie sur l'affichage, Matthieu a attaqué la partie sur les périphériques d'entrée. Comme il le disait, quand on pense à X.org, on pense principalement à l'affichage, mais en effet, la gestion des périphériques d'entrée est aussi un problème assez complexe. Il a donc décrit le fonctionnement d'X.org sur le sujet et les récentes évolutions dans le domaine.
Malheureusement, la partie sur l'organisation du développement de X.org n'a pas pu se faire, puisque nous avions atteint l'heure limite de 23h fixée par notre convention avec le Centre Culturel Bellegarde. En effet, les très nombreuses questions ont fait prendre du retard dans le déroulement de la présentation, mais elles ont en même temps permis au public de mieux comprendre X.org. Au vu de la popularité du sujet, Matthieu semblait partant pour faire une deuxième présentation dans la continuité, peut-être à l'automne prochain.
En tout cas, les slides et la vidéo de cette conférence seront prochainement mis en ligne. Stay tuned!
Se former à Linux embarqué, avec des places gratuites !

Quelques annonces concernant les prochaines formations organisées par
Free Electrons, avec notamment des places gratuites à gagner pour les membres de la communauté !
Les
prochaines sessions publiques de nos formations auront lieu aux dates suivantes :
Chaque formation coûte 1950 € par personne, avec une réduction de 20% pour les personnes venant de la même société ou pour les personnes en recherche d'emploi.
Et pour chacune des deux formations à Vence, une place gratuite à gagner pour un membre de la communauté du Logiciel Libre qui souhaite se former à Linux embarqué, voir cette page pour les détails ! Même si la page indique que la date limite était le 12 avril pour la prochaine formation, il est encore possible de gagner cette place !
Chaque participant à la formation, y compris le gagnant de la place gratuite, repart avec un exemple de la carte de développement Calao USB-A9263 (processeur Atmel AT91SAM9263, 64 Mo de RAM, 256 Mo de Flash, USB host, USB device et connecteur d'extension pour cartes filles).
La formation
Embedded Linux system development couvre tout ce qui est la création et l'intégration d'un système Linux embarqué : quels sont les différents composants d'un système Linux embarqué, comment les configurer, les compiler et les intégrer, comment réutiliser des bibliothèques et applications existantes, comment développer et mettre au point de nouvelles applications, etc. La seconde formation,
Linux kernel and drivers development, se consacre intégralement au fonctionnement du noyau et au développement de pilotes de périphériques. L'agenda exact de ces deux formations est disponible, vous pouvez vous faire une idée par vous-même.
Comme les terminaux à La Poste
Lorsque j'étais étudiant à l'
UTBM, les salles de TP étaient équipées de deux types de machines :
- des machines sous Microsoft Windows
- des machines sous Solaris, avec CDE comme environnement graphique, tcsh comme shell par défaut (pas de complétion), un Netscape 4 comme navigateur qui ramait terriblement et n'affichait pas la moitié des sites. En fait, plus que de machines, il s'agissait plus exactement de terminaux X tous connectés à un serveur. Lors des séances de travaux pratiques, le serveur était régulièrement à genoux quand 10 personnes travaillaient en même temps à compiler et exécuter du Java.
Ce Solaris était le seul environnement Unix utilisé par les étudiants qui n'étaient pas suffisamment curieux pour installer GNU/Linux chez eux. Et entre l'austérité et la mocheté d'un Solaris (en tout cas celui de l'époque) et les sympathiques environnements d'un GNU/Linux du moment, il n'y avait pas photo. Mais la plupart des étudiants n'avaient pour image d'Unix que ce Solaris moisi. Et pour moi qui cherchait à promouvoir les Logiciels Libres, et donc GNU/Linux, au travers de
Lolut, cet horrible Solaris était probablement l'un de mes pires ennemis. « Ah ouais, Linux c'est comme le machin tout pourri en salle de TP ? » me disait-on régulièrement.
Autre lieu, cinq ans plus tard, je suis maintenant de l'autre coté du bureau, j'anime un TP sur la gestion de versions à l'Université Paul Sabatier. La salle est crade au possible, le ménage n'a probablement pas été fait depuis environ un an ou deux (même chez moi des moutons de poussière pareils, je n'ai pas réussi).
Les machines sont sous Microsoft Windows. On utilise un serveur X propriétaire qui tourne sous Windows pour se connecter à une machine Unix distante. Là aussi : entourage des fenêtres immonde, vieux navigateur, tcsh en shell par défaut. Je ne sais pas si c'était Solaris, mais si ce n'est pas Solaris, c'est qu'il y a un administrateur zélé qui a réussi à transformer un sympathique environnement GNU/Linux en un truc aussi infame que le CDE solarisien.
Remarques des étudiants, captées au vol :
- « J'aime pas Linux »
- (ironiquement) « Aaaaah, j'aime Linux ! »
- « C'est comme les terminaux à la Poste ! »
C'est sûr qu'avec de telles expériences d'Unix, les étudiants ne sont pas vraiment incités à aller plus loin.
À quand un bureau Gnome ou KDE, des applications à jour sur les ordinateurs de TP dans les facultés ? À quand des environnements qui donnent envie d'utiliser GNU/Linux ? On les a maintenant depuis plusieurs années, faudrait penser à les installer !
Cours sur la gestion de version
Mardi, j'ai donné deux heures de cours puis deux fois deux heures de TP sur la gestion de version à des étudiants en licence 3 à l'IUP ISI de l'Université Paul Sabatier. Un peu de "théorie" sur la gestion de version (à quoi ça sert, quels problèmes ça résout, comment bien l'utiliser) et pas mal de pratique, en utilisant Subversion comme exemple. La gestion de version distribuée a été évoquée, mais il m'a semblé que dans le temps imparti, aborder la gestion de version centralisée était déjà bien suffisant.
Comme d'habitude, je publie les documents correspondants :
- le support de cours, au format OpenDocument et PDF. À noter qu'il contient un certain nombre d'animations importantes pour la compréhension qui ne sont visibles que dans la version OpenDocument.
- l'énoncé de travaux pratiques, au format OpenDocument et PDF.
Cher 82.244.211.40
Cher 82.244.211.40,
Vous êtes utilisateur ou utilisatrice de
l'Agenda du Libre, apparemment du service iCal, au travers du plugin Lightning 0.9 pour Thunderbird 2.0.0.18 sous Microsoft Windows. J'espère que le service de l'Agenda du Libre vous apporte toute satisfaction.
Néanmoins, le logiciel que vous utilisez, bien que libre, semble soit buggé, soit mal configuré, ou alors vous vous êtes endormi sur le bouton « Rafraîchir ». En effet, sur le
mois de décembre 2008, vous êtes responsable de 77% du trafic généré sur le site, environ 31 Go, et responsable de 51% des hits.
Sur la seule période allant du 11 décembre à 6h53 au 11 décembre à 12h34, vous êtes responsable de 14085 requêtes sur l'Agenda du Libre. Sur 5 heures et 41 minutes, 14085 requêtes, soit 41 requêtes par minute, environ une toutes les secondes et demi.
Je comprends fort bien qu'à l'heure de l'Internet Web 2.0 multimédia interactif avec Twitter et Face de bouc on veuille rester au courant du dernier buzz à la mode, mais rafraîchir le calendrier de l'Agenda du Libre toutes les secondes et demi me semble totalement inutile au regard de la vitesse d'apparition de nouveaux évènements dans l'agenda. Une période de rafraîchissement de plusieurs heures est largement suffisante.
Mademoiselle, Madame ou Monsieur 82.244.211.40, votre sort a été réglé par l'ajout d'une ligne
deny from 82.244.211.40 dans la configuration du serveur Web. Vous n'avez donc plus accès à l'Agenda du Libre, mais le serveur, dont la charge montait à plus de 35, se porte mieux avec une charge autour de 0.5.
Mademoiselle, Madame ou Monsieur 82.244.211.40, si vous souhaitez pouvoir utiliser à nouveau l'Agenda du Libre, merci de configurer votre logiciel de calendrier convenablement et de m'envoyer un courrier électronique pour que je retire l'interdiction d'accès qui porte actuellement sur votre adresse IP.
Je vous prie d'agréer, Mademoiselle, Madame ou Monsieur 82.244.211.40, mes agendesques salutations,
Thomas Petazzoni, animateur de l'Agenda du Libre
Free Electrons new website and blog
My colleague at
Free Electrons, Michael Opdenacker, has been working recently on setting up a new website for the company. It is now live and online since a few days. Apart from an improved design, an updated content, the website now features a
blog where one can follow what we're doing, news about embedded Linux, and other technical bits. My intention is to not use this blog only for corporate-marketing informations, but mostly for technical stuff: things we're discovering, testing, experimenting, and so on.
You can subscribe to the
RSS feed to get these news in your favorite RSS agregrator. I'm not sure yet how I will handle my blog posts here and on this new company blog. Maybe from time to time I'll copy the blog posts here, or just point to them. Or if I finally manage to migrate to Wordpress, I might use one of the automated importation plugin. We'll see.
Going to Embedded Linux Conference Europe 2008

So, on Wednesday I'm leaving for the Nederlands, in order to attend to
Embedded Linux Conference Europe 2008 on Thursday and Friday. Thanks to KLM, there are direct flights between Toulouse and Amsterdam, which means that the trip is quite certainly going to be an easy one, except if the
strike continues. In April, I went to
Embedded Linux Conference 2008 near San Francisco, CA, and it was a really great conference: the talks, the informal discussions and the organization were all very good, and I'm eager to come again to an Embedded Linux related conference. For those just tuning in, I've written a quite extensive report of ELC, together with videos from many talks, it's available on
Free-Electrons website.
Keynotes

For ELCE 2008, there are two keynote speakers: Harald Welte and David Woodhouse. Harald Welte is kind of a hero for any free software enthusiast and embedded linux geek: he worked on many different embedded Linux projects, including OpenMoko, did a lot of reverse engineering and hacking on embedded devices, and worked on gpl-violations.org to make sure that the rights of free software developers are respected when their GPL softwares are distributed. And as a "detail", he is one of the designer and main author of Netfilter, the packet filtering framework of the Linux kernel, even though nowadays it seems that other people have taken the lead on this project. He now works for VIA, and his keynote will discussion relationships between chip makers and the free software community. The second keynote speaker, David Woodhouse, is one of the new « embedded Linux » maintainers, that volunteered after Andrew Morton's call for such maintainers at ELC. I had the opportunity to work a little bit with David on Linux-Tiny related stuff, and working with him was really nice, because it was really supportive, despite the general dislike for Linux-Tiny work by many other kernel developers.
Personal talk selection
Of course, desides these two keynotes, there are many more
interesting talks. Just a personal selection :
- Digital Television with Linux - Architecture and Opportunities, because it's probably going to be an interesting feedback on using Linux in consumer electronic devices (the speaker works for Philipps), even though the talk happening at the same time Managing NAND longevity in a product is also probably going to be very interesting. The speaker, Matthew Porter, was also a speaker at ELC and his talk (video and slides) on using Linux on a consumer electronic device was very interesting
- Kernel Summer Report, by Thomas Gleixner, one of the x86 maintainers, -rt maintainers, and much more. A lot is happening these days in the kernel towards embedded systems, having a regular report about this is certainly refreshing, even though I think that I follow the kernel development close enough to be aware of most of the major stuff
- Rich GUI Without Pain, by Gustavo Sverzut Barbieri, where the speaker will present the capabilities of the Enlightenment Foundation Libraries. I've seen demonstrations and feature lists on the speaker website, and they are very impressive
- A quart into a pint pot: porting uClinux to small micros by Peter Griffin. The porting process is still a tedious process, and listening to more experiences always grows each other experience. At the same time, there will be a talk given by an anthropologist, entitled Embedded Magic, or How People Suddenly Find Out That They Are Collaborating (Some Thoughts Parsed Through the Brain of an Anthropologist). As I have a personal interest on how free software projects are organized, I might attend this talk.
- Taking Linux Power Management to Production Quality, which is probably to be interesting, as it looks like it comes from real experience, and so certainly contains a valuable feedback.
-
Tim Bird will this time discuss boot time, an issue he works on at Sony. At the same time, Perry Ismangil will present pjsip, but I already attended this presentation at FOSDEM this year (. And Jake Edge, from LWN will again discuss Web application flaws in embedded devices
- Frank Rowand will give the second part of this Adventures in real-time performance tuning, whose first part was given at ELC and was very interesting, full of real-world experience.
- Vitaly Bordug, from Montavista (where my brother is currently doing an internship, BTW) will present Device Tree's in Linux. It's a mechanism used by the PowerPC Linux port to give the kernel details about the hardware configuration as a separate entity from the kernel, so that thousands different kernels are not needed to support thousands different hardware platforms. At OLS this year, kernel developers more or less agreed on using this mechanism for other architectures as well. See the summary of the Device Tree BOF at OLS.
- Then, Philip Lougher will give an Overview of SquashFS filesystem, a popular compressed read-only file system, used by many embedded systems and LiveCDs. SquashFS has been sent for inclusion into the mainline kernel recently. As to my knowledge, it hasn't been merged during the 2.6.28 merge window, so that might probably happen during the next merge window. At the same time, Vasileios Laganakos will give a talk about Portability and Optimization of GNU / Open Source Applications with ARM Embedded Linux, which it seems will discussion compiling/building issues with embedded systems, a never-ending problem.
- During the timeframe of both of the preceding talks, Mike Anderson will give a tutorial Using a JTAG for Linux driver debugging, that he already gave at ELC. Unfortunately, at the ELC edition, he in my opinion, spent too much time discussion kernel driver development and not enough discussing JTAG debugging. But the tutorial was really great, clear, understandable, full of informations. See the video and slides.
- Next, Denis Oliver Kropp, the main developer of DirectFB? will discuss Open Integration Layer - DirectFB 2.0. At the same time Andrew Christian from Nokia will present Handhelds Mojo - Building and Running Ubuntu Distributions on ARM. It's again a talk about compiling/building issues, but this time while trying to get some kind of Ubuntu distribution working on ARM devices.
-
Finally, Nedjelko Miljevic and Klaas van Gend will discuss Building Embedded Userlands and the different tools available to do that (manual scripts, Scratchbox, Buildroot, and so on). A topic that my colleague Michael Opdenacker quickly covered through a BOF at the Ottawa Linux Symposium this year (video and slides). At the same time, the power management talk and the talk by FSFE representative are also probably worthwhile.
Our talks
My colleague Michael Opdenacker will give a talk entitled
Update on Filesystems For Flash Storage where he will discuss the various filesystems available for flash storage, a quickly moving area these days, with UBIFS being mainlined, AXFS released and so on.
On my side, I'll present a talk entitled
Choosing Free Software Graphical Libraries for Embedded Devices, during which I will quickly present most of the serious free software graphical libraries available. During the last weeks, I spent a significant amount of time trying, building and testing all these graphical libraries, and learned a lot from this, a knowledge (even if still incomplete, it's basically impossible to have a deep knowledge in everything) I'd like to share with ELCE attendees.
Merge window and Linux-Tiny work
The merge window for the
2.6.28 kernel has been opened about two weeks ago and has now be closed with the release of
2.6.28-rc1. In the context of my work at
Free-Electrons, I have the opportunity to contribute to the Linux-Tiny project, whose goal is to try to reduce the size of the kernel. Some of my patches have been integrated during this merge window :
- PCI quirks disabling patch, which allows to remove almost 12 Kb of kernel code/data
- AIO disabling patch, which allows to remove ~7 Kb of kernel code/data when asynchronous input/output operations are not needed
- file locking disabling patch, which allows to remove ~11 Kb of kernel code/data when file locking is not needed
- x86 CPU architecture selection, which allows to remove ~6 Kb of kernel code/data by disabling code only used for other CPU types. This modification in fact involved several distinct patches.
It's amazing to see how the kernel workflow works well. I haven't had to care about sending these patches during the merge window: I just submitted them to the proper subsystems maintainers, and they took care of updating them as needed and sending them to Linus once the merge window opened. Once one change has been accepted by a subsystem maintainer, the Linux kernel contributor doesn't have to do anything to see his patch integrated in mainline. This is how dozens of thousands of patches are merged between every kernel version.
However, the Linux-Tiny patches specifically are not always well received by the kernel community. Most of them are patches that add new configuration options to disable features. But most of these features are seen as absolutely mandatory for non-embedded developers, even though a kernel can work perfectly fine without them in certain conditions, conditions which can be guaranteed to be true on embedded systems were the environment, feature-set and used applications are most of the time precisely defined. Developers also tend to not like them because more configuration options means more #ifdef machinery and more complexity for future maintenance, which is an absolutely valid concern. But numbers clearly show that the size of the kernel is growing over time, and this is problematic to embedded users who care about size.
See also
my report of Matt Mackall's talk at Embedded Linux Conference this year concerning kernel size, and the associated
video.
Libtool brain damage
Trying to understand what the whole "libtool" crap does, I made some basic examples with libtool, and I'm still being hit by libtool crappyness. First try:
$ libtool --mode=link gcc -g -O -o libplap.la tata.lo libplop.la -rpath /tmp/prout/usr/lib/
[...]
$ libtool --mode=install install -c libplap.la /tmp/prout/usr/lib/libplap.la
libtool: install: error: cannot install `libplap.la' to a directory not ending in /tmp/prout/usr/lib/
Second try (after reading /usr/bin/libtool and executing it through bash -x to understand the completely strange message) :
$ libtool --mode=link gcc -g -O -o libplap.la tata.lo libplop.la -rpath /tmp/prout/usr/lib
[...]
$ libtool --mode=install install -c libplap.la /tmp/prout/usr/lib/libplap.la
[...], but works
See the difference ? Yes, just the
-rpath ending with a slash in the first case and not in the second case. Isn't this a completely broken test ?
First step towards AACI emulation in Qemu
I just spent some time writing the first few bits of AACI emulation in Qemu. AACI stands for Advanced Audio CODEC Interface, and the specification is available at least
here. I'm pretty new to the audio low-level stuff, but it seems that this piece of hardware is simply an interface to an audio codec, the famous AC97.
Until now, my Qemu
patch only provides the first bits. It registers the I/O memory region that corresponds to AACI, and implements some dummy
read() and
write() operations. This AACI emulation is hooked into the Versatile PB platform emulation by a simple call to the new aaci_init() function.
Of course, the bulk of the work is to implement the
read() and
write() operations. For the moment, the read() operation only allows to get the vendor and product ID. It allows the AMBA bus driver of the Linux kernel to figure out that an AACI device is present, and to call the probe() method of the AACI driver, which was the first step. Qemu is rather well-designed: adding the emulation for a new device is very simple.
Now that the kernel correctly detects the AACI, I'm receiving AC97 requests. Qemu already implements the AC97 codec, in
hw/ac97.c, but it seems that the implementation is hardcoded to work over the PCI bus, which is not the case with AACI. So I'll probably have to make Qemu AC97 support a bit more generic, so that it can be used both from the PCI bus and the AACI interface.
More on this later...
Using U-Boot and Flash emulation in Qemu
For the embedded Linux trainings of
Free-Electrons, we use virtual machine environments for the practical labs, because we haven't found yet a nice board that matches all our criterias. Qemu, of course, is used in all our labs, and provides a very nice emulation environment since it emulates several CPU architectures often used in embedded systems (ARM, MIPS and PowerPC).
However, until recently, there was no emulation of flash memory in Qemu, which is sad because flash memory is very common in embedded systems, and is handled by different tools, different filesystems than normal block devices, and we wanted our training participants to get used to these tools. We also wanted to allow the training participants to configure, compile and use an embedded bootloader, the famous
U-Boot. Now, the emulation of Intel flashes is present in Qemu (in
hw/pflash_cfi01.c) and this emulation is already used in some emulated ARM platforms, but not the Versatile PB platform that we use for our trainings (this platform is nice because it has Ethernet, serial ports, LCD, etc.). So, I decided to add flash emulation to the Versatile PB platform. It turned out not to be so easy, even if the patches are in the end relatively small.
I've written four small patches for Qemu, which have been written and tested for Qemu revision 5391 from the Subversion repository (I don't think the Flash emulation has yet been part of an official stable Qemu release). They have all been submitted to the Qemu mailing-list. Here are the patches :
- pflash-cfi01-increase-write-buffer-size, which increases the size of the write buffer declared by Qemu in the CFI table of the flash. The advertised buffer size was only 16 bytes, which is small compared to usual buffer sizes, and makes the writing process very slow, at least from U-Boot. The size has been increased to 2048 bytes.
- pflash-cfi01-after-erase-confirm-reset-wcycle, which fixes a problem in the code handling the erase command. When the "erase confirm" command was sent to Qemu, it didn't reset the wcycle variable, which lead Qemu to think that the next command wasn't a new one, but was part of the "erase command", which obviously was wrong. I'm not 100% sure about this patch, since there was already a pfl->wcycle = 1 at the place where it should have been pfl->wcycle = 0. But hey, we'll what the Qemu developers say about it.
- pflash-cfi01-improve-debug-msgs, which only improves two debugging messages that were useful while working on the other patches. Nothing fancy.
- versatilepb-add-flash-support, which adds the flash emulation to the Versatile PB platform. It wasn't really easy to understand the qemu_ram_alloc() mechanism, but in the end, it seems to work. The RAM size of a Versatile PB platform is now fixed to 128 MB and the Flash size is fixed to 64 MB. The file containing the flash is specified using the -pflash option. When this option is absent, Qemu falls back to the traditionnal way of loading the kernel given with the -kernel option. If the -pflash option is present, then the contents of the file are used as the contents of the emulated flash, and the emulation starts at the beginning of the Flash (address 0x34000000).
Of course, the goal of all this is to run something on the Flash, basically U-Boot to start with. I've used U-Boot 1.3.4, which also requires
a patch, which changes the following things :
- Switch for the Versatile specific flash driver to the CFI generic flash driver
- Adjust the flash settings (sector size, location of the environment, etc.)
- Configure the Ethernet driver for an external PHY, because it seems that Qemu doesn't emulate the PHY operations
- Fix the timer code to use the CFG_TIMER_CTRL constant instead of hardcoding it
- Tweak the CFG_HZ and CFG_TIMER_CTRL to get a relatively working time. Without these tweaks, the time was going very fast for U-Boot, all delays were instantaneous, the network timeouts were reached instantaneously. However, the tweaks are only work-arounds at the moment, as I don't have a clear understanding of how the time is handled under Qemu.
With all these patches in place, one can run U-Boot, download a Linux kernel, flash it from U-Boot and run it. Basically, the 128 MB RAM is mapped from 0x0 to 128 MB, and the 64 MB Flash is mapped from 0x34000000 to 0x38000000, with 256 KB sectors. U-Boot is stored at the beginning of the Flash, at address 0x34000000 where the CPU starts its execution. The U-Boot environment is stored in the next sector, at 0x34040000, which leaves the flash free starting at 0x34080000. This is the place where I flash the kernel. To load the kernel from TFTP, I use the RAM address 0x200000 (2 MB), because U-Boot is loaded at address 0x100000 (1 MB).
To create the Flash file, I use :
dd if=/dev/zero of=flash.img bs=1M count=64
dd if=/path/to/u-boot-1.3.4/u-boot.bin of=flash.img conv=notrunc
Then, to run Qemu, I use :
sudo qemu-system-arm -M versatilepb -m 192 -serial stdio -net nic,model=smc91c111 -net tap -pflash flash.img
I get into the U-Boot prompt, and do :
setenv ipaddr 172.20.0.2
setenv serverip 172.20.0.1
setenv bootfile /uImage
setenv bootcmd bootm 34080000
setenv bootargs console=ttyAMA mem=128M
saveenv
tftpboot 200000
protect off 1:2-32
erase 1:2-32
cp.b 200000 34080000 ${filesize}
protect on 1:2-32
boom 34080000
Which basically does :
- set environnement variables for the IP address of the embedded system, IP address of the server, file to download using TFTP from the server, the default command to run when U-Boot starts, and the kernel command line. The console=ttyAMA allows to get the console on the serial port.
- save the environment. It is saved in the second flash sector, for 0x34040000 to 0x34080000, so that next time, the previous environment variable settings will be kept.
- download the kernel image at address 0x200000
- unprotect flash sectors 2 to 32 (sector 0 is U-Boot, sector 1 is the environment)
- erase these sectors
- copy the kernel to the flash. U-Boot is smart enough to know that the destination is a flash memory and that it shouldn't copy to it as usual, but that it should use the flash driver instead.
- re-protect the flash sectors
- boot the kernel. And hippy !
Next steps: play with the kernel MTD layer, JFFS2 and other flash filesystems on one hand, and implement the Versatile sound emulation in the other hand.
Ottawa Linux Symposium 2008

Je rentre tout juste ce matin de la dixième édition du
Linux Symposium qui s'est une nouvelle fois tenue à Ottawa au Canada. Cette conférence est l'une des deux principales conférences en ce qui concerne le noyau Linux, et j'avais déjà eu l'opportunité d'y assister en 2005 (voir le
compte-rendu) et en 2007.
Cette année, de nombreuses conférences très intéressantes étaient au programme et l'ont effectivement été en réalité. Plusieurs points marquent une rupture avec la "tradition" de ce symposium :
- la traditionnelle keynote d'ouverture The Kernel Report réalisé par l'excellentissime Jonathan Corbet de LWN n'était pas au programme, remplacée par une keynote d'ouverture The Kernel: 10 Years in Review présentée par Matthew Wilcox, un développeur noyau d'Ottawa, qui s'est révélée nettement, nettement moins bonne que la traditionnelle de Corbet. Décevant.
- la traditionnelle keynote de fermeture n'a tout simplement pas eu lieu. Réalisée par Dave Jones en 2005, Greg KH en 2006 (voir ici) puis James Bottomley en 2007, elle n'a pas eu lieu cette année. Traditionnellement, l'orateur de l'année N qui réalise la keynote de fermeture annonce également l'orateur de l'année N+1 pour cette keynote. Et cette keynote, à la fois sérieuse et humoristique, véritable exercice de style, était un moment très attendu de la conférence. Petite déception avec l'absence de cette keynote
- deux autres keynotes étaient au programme cette année, en plus de celle d'ouverture: une keynote de Werner Almesberger intitulée The making of OpenMoko Neo, fort intéressante, et une autre de Mark Shuttleworth intitulée The Joy of Synchronicity: Coordinating the Releases of Upstream and Distributions. Ceux qui ont suivi l'actualité trollifère de Marc Shuttleworth ces derniers temps peuvent aisément deviner la teneur d'une telle keynote.
En dehors de ces keynotes, j'ai donc assisté à un certain nombre de présentations, en général orientées sur l'embarqué, mais pas toujours. En vrac: ateliers sur SystemTap et ftrace, présentations sur Guilt, le wireless dans le noyau, le suspend to RAM, le temps réel, l'embarqué, la gestion d'énergie, les systèmes de fichiers et bien d'autres choses. Avec mon collègue de
Free-Electrons Michael Opdenacker, nous avons filmé 25 conférences et ateliers que nous mettrons prochainement en ligne.
Globalement, le Linux Symposium reste une très bonne conférence, mais la qualité semble tout de même avoir sensiblement baissé (avis partagé par un certain nombre de participants avec lesquels j'ai discuté), et le nombre de participants est inférieur aux années précédentes. Traditionnellement, le Kernel Summit avait lieu juste avant ce Symposium, ce qui assurait la présence d'un grand nombre de développeurs noyau importants et donc de bonnes présentations, ce qui attire le public. Depuis 2007, ce Kernel Summit n'est plus attaché au linux Symposium: en 2007, il a eu lieu conjointement avec Linux.conf.eu en Angleterre, et en 2008, il aura lieu conjointement à Linux Plumbers, une toute nouvelle conférence lancée à Portland, Oregon.
Enfin,
last but not least, l'année prochaine, le Linux Symposium aura lieu à Montréal, Canada et non plus à Ottawa !
Slides des présentations aux RMLLs

Comme annoncé dans un
précédent billet, j'ai réalisé deux interventions aux Rencontres Mondiales du Logiciel Libre à Mont de Marsan au début du mois. Les slides de ces présentations sont maintenant disponibles en ligne.
Les deux présentations ont eu pas mal de succès, puisqu'elles ont attiré une quarantaine de personnes, remplissant aisément la petite salle de TD qui avait été attribué à ces deux thèmes. Le noyau Linux semble donc toujours être un sujet de fascination pour un grand nombre d'utilisateurs et de développeurs du Logiciel Libre, et c'est vrai qu'il y a énormément de choses très intéressantes à regarder dans le noyau.
Dix ans après

Juin 1998, je suis au lycée, en seconde, pas encore 15 ans. C'est à cette date que débutent les premiers échanges avec
Dimitri Ara avec l'idée de développer un petit système d'exploitation pour comprendre comment cela fonctionne et apprendre à programmer. À l'époque, à part quelques notions de BASIC et la lecture du premier chapitre du Kernighan et Ritchie, mes connaissances en programmation sont très réduites et rétrospectivement, l'idée de démarrer un tel projet avec les connaissances que nous avions me paraît totalement ridicule. Les hostilités commencent avec l'achat du célèbre livre d'Andrew Tanenbaum sur les systèmes d'exploitation, une lecture difficile pour le néophyte que j'étais. Néanmoins, nous perséverons et créons le projet KOS, pour
Kid Operating System.
Novembre 1998, les premiers bouts de code commencent à faire quelque chose: démarrer depuis une disquette et afficher un message à l'écran (l'historique du projet retient la date du 11 novembre 1998 pour le premier MBR valide et du 16 décembre 1998 pour l'affichage du premier message). Pour la postérité, je suis allé faire quelques fouilles dans mes archives, et j'y ai déniché les toutes premières versions de KOS, qui sont maintenant en ligne à l'adresse
http://thomas.enix.org/pub/oldkos/. C'est aussi à cette date que les premiers échanges avec David Decotigny ont débuté, où Dimitri et moi-même lui posions de nombreuses questions, très basiques, sur le fonctionnement d'un système d'exploitation.
La suite de l'histoire du projet KOS est résumée sur le site, dans
l'historique.
C'était donc il y a dix ans. Depuis ce défi stupide lancé en juin 1998, je n'ai fait que travailler autour des systèmes d'exploitation et du bas-niveau : cette coïncidence a finalement décidé du reste de mon début de carrière.
Nostalgie.
Encodage et montage de vidéos en série
Récemment, j'ai eu à réaliser l'encodage et un montage simple de plusieurs dizaines de vidéos de conférences: celles du FOSDEM, d'Embedded Linux Conference, de l'évènement KDE de janvier à Toulouse et de plusieurs conférences données dans le cadre des rencontres de Toulibre. Le site de
Free-Electrons propose déjà un
mini-HOWTO sur l'extraction et l'encodage de vidéos, mais pas d'informations sur le montage en série.
Pour l'extraction, on utilise donc
dvgrab, qui va nous créer un fichier d'environ 12 giga-octets pour chaque cassette d'une heure de vidéo. Ensuite, avec
KDEnLive, on réalise le montage que l'on souhaite, en enregistrant dans un fichier
.kdenlive chaque projet, un pour chaque vidéo finale. Un projet peut évidemment combiner plusieurs vidéos et images source. Pour ma part, il s'agissait simplement d'une image PNG 720x756 réalisée avec Inkscape pour faire une petite page d'introduction avant la vidéo, puis de couper la vidéo aux bons endroits pour qu'il ne reste plus que la conférence elle-même. À noter que j'utilise les paquets de Debian Multimédia pour KDEnLive et MLT (la bibliothèque multimédia utilisée par KDEnLive), mais pas la dernière version des paquets car elle contient une version buggée de KDEnLive qui désynchronise le son et la vidéo. Au jour d'aujourd'hui, j'utilise les versions
svn20071228.
Une fois que tous les fichiers
.kdenlive sont générés, il faut maintenant écrire un script qui va tout d'abord réaliser le rendu de la vidéo, l'encoder en Ogg Theora puis l'uploader sur un serveur. Pour l'encodage et l'upload, pas de soucis, on dispose d'outils en ligne de commande. Pour lancer le rendu, à première vue, il faut lancer KDEnLive et cliquer sur plein de boutons, ce qui est difficilement scriptable en shell. Sauf qu'il existe un outil appelé
inigo qui permet justement de lancer un rendu KDEnLive en ligne de commande. Il n'est pas livré dans les paquets
svn20071228 de MLT, donc il faut se le compiler à la main à partir des sources de MLT, ce qui se révèle assez simple car c'est un outil très basique. Une fois ceci fait, on peut écrire un script comme celui-ci :
inigo video1.kdenlive -consumer avformat:video1-rendered.dv format=dv ildct=1 pix_fmt=yuv420p size=720x576 profile=dv_pal
ffmpeg2theora -a 3 -v 7 --pp de,tn:256:512:1024 --artist "Mon Artiste" --title "Mon Titre" --location "Ma Ville, France" \
--organization "Mon Asso (http://www.monasso.org)" --license "Ma License" -o video1.ogg video1-rendered.dv
scp video1.ogg moncompte@monserveur: &
inigo video2.kdenlive -consumer avformat:video2-rendered.dv format=dv ildct=1 pix_fmt=yuv420p size=720x576 profile=dv_pal
ffmpeg2theora -a 3 -v 7 --pp de,tn:256:512:1024 --artist "Mon Artiste" --title "Mon Titre" --location "Ma Ville, France" \
--organization "Mon Asso (http://www.monasso.org)" --license "Ma License" -o video2.ogg video2-rendered.dv
scp video2.ogg moncompte@monserveur: &
La commande
inigo va donc générer le fichier
videoX-rendered.dv à partir du fichier de projet KDEnLive. Attention, ce fichier est également au format DV, soit environ 12 Go par heure de vidéo, il faut donc prévoir beaucoup de place. La commande
ffmpeg2theora va ensuite encoder en Ogg Theora. On donne des métadonnées sur la vidéo (artiste, titre, organisation, licence), mais surtout, on demande à
ffmpeg2theora d'utiliser un filtre anti-bruit. En réduisant le bruit de la vidéo, on réduit la quantité de petits changements inutiles dans celle-ci, et donc l'encodage est plus performant. Pour la même vidéo, le fichier Ogg résultant peut être environ deux fois plus petit après utilisation de ce filtre, particulièrement utile quand la vidéo a été prise dans une pièce sombre, ce qui est souvent le cas pour des conférences. Enfin, une fois notre fichier Ogg généré, on peut l'uploader sur notre serveur en arrière plan, pendant que la prochaine vidéo est en train d'être rendue.
Chez moi, le processus de rendu et d'encodage étaient assez longs, je ne pouvais faire qu'environ trois vidéos par nuit. Pour toutes les vidéos d'Embedded Linux Conference, j'ai laissé tourner pendant un WE de quatre jours, le processus s'est terminé au bout de trois jours complets
Free-Electrons slashdotté
Hier, j'ai posté sans grand espoir une dépêche sur
Slashdot concernant la mise en ligne des vidéos et du rapport de l'Embedded Linux Conference. Ce matin, le site de Free-Electrons ramait comme pas possible: je me rends donc sur Slashdot, et ô surprise, ma
dépêche a été validée. C'est ce qu'on appelle un
slashdottage en règle. Le serveur passe donc probablement un mauvais moment, mais un plus grand nombre de personnes profiteront sans doute de ces vidéos et du rapport.
Cette publication a également été annoncée sur
LinuxDevices.com et
LinuxFr.org. Elle sera probablement annoncée sur
Linux Weekly News également.
Publication de vidéos et d'un rapport d'Embedded Linux Conference

Du 15 au 17 avril dernier avait lieu la
Embedded Linux Conference à Mountain View, Californie. Il s'agit probablement de la plus importante conférence uniquement consacrée à l'utilisation de Linux dans l'embarqué, avec plus de cinquante interventions: conférences, tutoriels, keynotes, etc. Via mon travail pour
Free Electrons, j'ai eu la chance de pouvoir m'y rendre afin de découvrir de nouvelles technologies, apprendre, rencontrer les développeurs de différents projets, etc. Ce fût une expérience très intéressante, comme le sont souvent ce genre de conférences.
Comme le fait Free Electrons d'habitude, j'ai filmé toutes les conférences auxquelles j'ai assisté, soit dix neufs conférences et tutoriels. Nous venons de publier
ces vidéos sur le site de Free Electrons. Pour la première fois, Free Electrons publie également un
rapport de cette conférence, que j'ai rédigé dans l'esprit du
compte-rendu du Linux Symposium d'Ottawa de 2005 que j'avais publié sur ce site. Les conférences couvertes par les vidéos et ou le rapport sont:
- Keynote: The Relationship Between kernel.org Development and the Use of Linux for Embedded Applications, by Andrew Morton (Google):
- UME - Ubuntu Mobile and Embedded, by David Mandala (Canonical):
- Appropriate Community Practices: Social and Technical Advice, by Deepak Saxena (MontaVista):
- Adventures In Real-Time Performance Tuning, by Frank Rowand:
- Shifting Sands: Lessons Learned from Linux on an FPGA, by Grant Likely:
- Disko - An Application Framework for Digital Media Devices, by Guido Madaus:
- Keynote: Tux in Lights, by Henry Kingman (LinuxDevices.com):
- Back-tracing in MIPS-based Linux Systems, by Jong-Sung Kim (LG Electronics):
- Making a Phone Call With Phase Change Memory, by Justin Treon (Numonyx):
- Using Real-Time Linux, by Klaas van Gend (MontaVista):
- Every Microamp is Sacred - A Dynamic Voltage and Current Control Interface for the Linux Kernel, by Liam Girdwood (Wolfson Microelectronics):
- Power Management Quality of Service and How You Could Use it in Your Embedded Application, by Mark Gross (Intel):
- OpenEmbedded for product development, by Matt Locke (Embedded Alley):
- Kernel Size Report, and Bloatwatch Update, by Matt Mackall (Selenic Consulting):
- Leveraging Free and Open Source Software in a Product Development Environment, by Matt Porter (Embedded Alley):
- Using a JTAG for Linux Driver Debugging, by Mike Anderson (PTR Group):
- DirectFB Internals - Things You Need to Know to Write Your DirectFB gfxdriver, by Takanari Hayama ():
- Linux Tiny - Penguin Weight Watchers, by Thomas Petazzoni (Free Electrons):
- Keynote: Status of Embedded Linux and CELF Plenary Meeting, by Tim Bird (Sony):
Je recommanderai en particulier la keynote d'Andrew Morton, l'intervention de Klass van Gend sur le temps réel, celle de Liam Girdwood sur la gestion des régulateurs, l'excellente explication sur l'utilisation d'OpenEmbedded par Matthew Locke et le très bon tutoriel de Mike Anderson sur le développement de pilotes noyau et leur déboguage à l'aide d'une sonde JTAG. À noter que j'ai également réalisé une intervention lors de cette conférence concernant le projet
Linux Tiny auquel je commence à contribuer, puisque mon collègue, Michael Opdenacker en est le mainteneur officiel.
Enfin, nous venons également de publier les vidéos que Michael et moi avons enregistrées lors du FOSDEM et que j'ai encodé ces dernières semaines. Au total neuf vidéos ont été mises en ligne, elles concernent évidemment l'embarqué, sauf une consacrée à X.org, par Keith Packard:
- Modest, email client for embedded systems, by Dirk-Jan Binnema (Nokia):
- Design a Linux robot companion with 8 bits microcontrollers, by David Bourgeois:
- Linux on the PS, by Olivier Grisel:
- Xen for Secure Isolation on ARM11, by Jean-Pihet (MontaVista):
- Building blocks for Embedded Power Management, by Kevin Hilman (MontaVista):
- Emdebian Update: Rootfs, GPE and tdebs, by Neil Williams:
- pjsip: lightweight portable SIP stack, by Perry Ismangil:
- Roadmap to recovery - pain and redemption in X driver development, by Keith Packard:
Bon visionage !
Un électron libre
Depuis mars 2005, je travaillais dans la société
Seanodes, à Colomiers, en tant qu'ingénieur R&D, mais depuis le 21 janvier, je suis maintenant un électron libre, je travaille pour la société
Free Electrons. L'occasion de faire un petit retour sur ce que j'ai fait à Seanodes (ce que je n'ai jamais évoqué ici) ainsi que sur ce qui m'attend au sein de Free Electrons.
Seanodes
Seanodes développe un logiciel de virtualisation de stockage pour les clusters de calcul. Pour résumer en quelques phrases, l'idée est d'aggréger tous les disques des différents noeuds d'un cluster pour constituer un stockage virtuel performant, scalable et tolérant aux pannes. Une sorte de LVM/RAID, sauf que les données ne sont pas réparties sur des disques locaux, mais sur des disques distants, et que la tolérance aux pannes doit être gérée puisque des noeuds peuvent subitement tomber en panne alors que l'on souhaite conserver la disponibilité des données stockées. Tout cela est uniquement géré de façon logicielle, avec un logiciel plutôt compliqué : les problématiques de distribution et de tolérance aux pannes sont plutôt ardues.
Pour ma part, j'ai principalement travaillé sur le composant de virtualisation, un module en mode noyau qui propose à l'espace utilisateur un périphérique bloc et qui derrière va gérer le placement des données sur les différents disques du cluster, gérer la création/destruction de volumes, la réplication, la reconstruction et bien d'autres choses. Il s'agit d'un composant relativement complexe d'environ 30.000 lignes de C en mode noyau (si mes souvenirs sont bons) sur lequel nous travaillions à deux. Avec autant de lignes de code dans le noyau, j'ai eu l'occasion de bien me frotter au développement de module noyau et surtout à leur déboguage. En dehors de l'aspect mode noyau, la difficulté de ce composant était le déboguage des corruptions de données sur disque, surtout quand elles se produisent seulement après plusieurs heures ou plusieurs journées de tests intenses. Il m'est arrivé de passer plusieurs semaines voire mois avec des collègues pour trouver l'origine d'une corruption de données. Valérie Henson
parlait d'ailleurs de ce sujet il y a quelques temps sur
son blog.
Malheureusement, il n'est pas vraiment possible d'en dire beaucoup plus sur le fonctionnement du produit : l'entreprise a choisi de fonctionner selon le modèle traditionnel du logiciel propriétaire. Pour un ingénieur, fan de Logiciel Libre, d'ouverture et de collaboration, ne pas pouvoir montrer, expliquer, exposer ce que l'on fait est frustrant. J'ai eu beau travailler sur des choses complexes pendant ces quelques années, rien n'est visible de l'extérieur : pas de code source, pas de présentation lors de conférences techniques type Linux Symposium. De ce point de vue, le monde du Logiciel Libre a un grand plus : le travail d'un ingénieur est visible de tous et constitue ensuite une très bonne carte de visite pour évoluer vers d'autres sociétés. Il ne faut pas se voiler la face : une part de la motivation pour travailler sur du Libre peut être de nature éthique ou philosophique, mais il y a également une grande part de motivation liée à la reconnaissance par les pairs, à la reconnaissance du travail accompli et de son (éventuelle) qualité. Travailler en mode ouvert, c'est de mon point de vue aussi un moyen d'attirer des ingénieurs vers son entreprise et vers son projet, et surtout de fidéliser leur implication dans le projet et l'entreprise (sans parler du levier marketing de la communauté pour répendre un produit sans effort commercial ou de la possibilité d'avoir des contributeurs et testeurs extérieurs, etc.).
Pour revenir à ce que j'ai fait à Seanodes, en plus de ce module noyau de virtualisation, j'ai également contribué, plus modestement, à quelques autres morceaux du logiciel. Enfin j'ai eu, en collaboration avec un ancien collègue, le rôle de
leader technique à partir de janvier 2006 et jusqu'à l'annonce de mon départ. Un rôle très intéressant et très formateur, mais qui s'est révélé beaucoup plus difficile à jouer que ce que j'imaginais, pour de multiples raisons. Après presque trois ans à Seanodes, une autre opportunité s'est présentée, dans le monde du Logiciel Libre justement, et après une longue phase de réflexion, je me suis décidé à changer.
Free Electrons
Depuis le 21 janvier, je travaille donc pour
Free Electrons, une société fondée en 2004 par Michael Opdenacker, que j'ai rencontré au cours de conférences sur le Logiciel Libre. La société propose des formations et du service/conseil dans le domaine de Linux et des Logiciels Libres pour l'embarqué. Michael Opdenacker était jusqu'ici seul dans la société, mon arrivée augmente donc de 100% les effectifs de celle-ci.
Aujourd'hui, la principale activité de la société est principalement liée aux formations, avec notamment une formation plutôt complète sur l'utilisation de Linux et de Logiciels Libres dans l'embarqué, mais nous souhaitons maintenant développer
l'activité de conseil et services (développement de pilotes, portage du noyau Linux, mise à jour de pilotes, intégration dans la version officielle du noyau, développement d'un kit de développement intégrant le nécessaire pour faire fonctionner une plateforme, du noyau jusqu'aux bibliothèques graphiques, etc.). Je suis donc disponible pour vos projets dans le domaine de l'embarqué, n'hésitez pas ! :-)
Un choix intéressant réalisé par Michael Opdenacker est de publier tous les
supports de formation sur le site, en les distribuant sous une licence libre (Creative Commons BY-SA), que ce soit les cours ou les instructions pour les travaux pratiques. Cela présente plusieurs avantages : les clients potentiels peuvent se faire une idée très précise du contenu des formations, les supports transmettent une partie des connaissances même à ceux qui ne peuvent pas participer aux formations, réception de contribution et de traduction et surtout, ils sont un puissant moyen de faire connaître les formations proposées par la société. Cette distribution sous licence libre est clairement gagnante-gagnante, pour les clients potentiels, pour les visiteurs et pour la société. C'est un aspect que j'apprécie beaucoup dans la stratégie de Free Electrons : se baser sur l'ouverture pour fonctionner. Ainsi, au delà des supports, même les fiches d'évaluation des formations, remplies par les participants
sont publiées en ligne, en toute transparence.
En ce qui concerne mon poste, sa description est
toujours en ligne sur le site de Free-Electrons. En gros, mon travail se décompose en trois parties :
- un tiers du temps, je donne des formations sur Linux et les Logiciels Libres pour l'embarqué. J'ai toujours aimé faire des présentations, expliquer, partager ce que je sais, et échanger pour apprendre des autres. Je pense que ça se voit vu le nombre d'interventions que j'ai donné, ou la rédaction des articles SOS dans Linux Magazine, la participation à des GULLs menant des actions orientées vers le public, etc. Donner des formations rentre tout à fait dans cette orientation et me convient parfaitement. En plus, ces formations sont réalisées un peu partout dans le monde, mais surtout en Europe, ce qui permet de voyager, de faire un peu de tourisme, de découvrir d'autres pays.
- un tiers du temps, je travaille de chez moi (la société est basée à Nice, mais je travaille depuis Toulouse) pour des projets directement liés à l'activité de la société. Veille technologie pour se tenir au courant des évolutions du monde de l'embarqué et donc continuer à donner de bonnes formations, mise à jour de formations, développement de nouvelles formations, ou encore conseil et services pour les clients. La veille technologique, ça veut aussi dire présence à diverses conférences, FOSDEM, Rencontres Mondiales, Linux Symposium, Embedded Linux Conference et Embedded Linux Conference Europe, c'est-à-dire des conférences vraiment très intéressantes.
- le dernier tiers, je travaille toujours de chez moi en contributant à des projets libres dans le monde de Linux et de l'embarqué, que ce soit au travers de code, de documentation, publication d'articles ou autre.
Comme ce nouveau travail est complètement orienté vers le Logiciel Libre et l'ouverture, j'aurai, je l'espère, beaucoup plus souvent l'occasion de relater ce sur quoi je travaille sur ce blog. J'aurai donc l'occasion dans un prochain billet de raconter un peu mes six premières semaines de travail à Free Electrons, qui ont été déjà très actives !
Évènement autour de KDE 4

Comme je le disais dans un précédent billet, les contributeurs toulousains à KDE organisent avec
Toulibre un
évènement pour fêter la sortie de KDE 4, une étape important pour ce projet. À Toulouse, cet évènement, ouvert à toutes et à tous, aura lieu en deux parties : vendredi soir et samedi toute la journée. Notons que cet évènement est organisé avec l'aide de partenaires, les sociétés
Communication et Systèmes et
KDAB.
Le vendredi 25 janvier, à 20h, une soirée orientée utilisateurs. Un extrait du lancement officiel aux États-Unis (qui aura lieu du 17 au 19 janvier aux États-Unis dans les locaux de Google) sera diffusé, sous-titré en français, puis Kévin Ottens, contributeur à KDE, fera une présentation de KDE et des nouveautés de cette version. La soirée se cloturera par un cocktail dinatoire. Cette partie aura lieu dans l'auditorium du Centre Culturel Bellegarde.
Le samedi 26 janvier, de 9h à 18h, une journée de conférences autour de KDE, orientées vers les contributeurs et ceux qui aimeraient le devenir. Le
programme est très intéressant :
- « Contribuer à KDE : Bienvenue à tous ! », par Alexis Ménard
- « Présentation de Qt », par David Faure
- « Présentation de CMake », par Laurent Montel
- « Solid: Intégration avec le matériel sans utiliser d'aspirine », par Kévin Ottens
- « Plasma : Un nouvelle approche du gestionnaire de bureau », par Alexis Ménard
- « Phonon: Multimédia facile pour vos applications », par Kévin Ottens
- « Guide de contribution à la traduction de KDE », par Anne-Marie Mahfouf
- « Présentation KIO », par David Faure
- « Les feuilles de style de Qt », par Aurélien Gateau
- « Des logiciels éducatifs dans KDE », par Anne-Marie Mahfouf
Toutes ces présentations sont réalisées par des contributeurs à KDE, qui connaissent donc bien leurs sujets. David Faure travaille sur KDE depuis 1998, maintient le gestionnaire de fichiers et navigateur Web Konqueror et travaille sur les kdelibs, il a également travaillé sur KWord, le traitement de texte de KDE. Aurélien Gateau est l'auteur de Gwenview, la visionneuse d'images de KDE 4. Anne-Marie Mahfouf est l'initiatrice du projet KDE-Edu et développe des applications éducatives pour KDE. Alexis Ménard a travaillé sur KPlato et se focalise maintenant sur Plasma, le nouveau gestionnaire de bureau. Kévin Ottens contribue à KDE depuis 2003 et est à l'origine de Solid. Il travaille également sur la gestion des fichiers et les kdelibs.
Cette journée aura également lieu au Centre Culturel Bellegarde, dans la salle où ont lieu toutes les présentations réalisées lors des rencontres bi-mensuelles de Toulibre. Pour ma part, je ne pourrais malheureusement pas m'y rendre, la date entrant en conflit avec l'assemblée générale de l'
April, mais je profiterai quand même de la soirée du vendredi... et du cocktail dinatoire :-)
Vidéo en ligne
Dans mon
précédent billet, je relatais mes expérimentations en matière de mise à disposition de vidéos en ligne, lisibles directement dans un navigateur. Via
Linux Weekly News, j'ai découvert que le site
Transmission.cc a publié une
étude assez complète sur ce sujet. Ils évoquent tout, du codec, au transcodage sur le serveur, en passant par les containers, les différentes solutions de visualisation dans les navigateurs, etc. Une rapide lecture me laisse penser qu'effectivement, actuellement, la solution du
player Flash est la meilleure solution d'un point de vue pragmatique... et qu'il n'y a pas encore d'alternative libre suffisamment diffusée pour être pertinente, surtout quand l'objectif de la mise en ligne de vidéo est de faciliter leur accès au plus grand nombre.
Mise en ligne de vidéos
Sur le site de
Toulibre, on commence à avoir quelques vidéos de conférences passées (sur le Logiciel Libre, sur Jabber, sur IRC, sur le droit d'auteur, la conférence de Richard Stallman, etc), et au lieu de simplement les mettre en téléchargement, j'aimerais permettre aux visiteurs de les visionner directement en ligne.
Une solution serait simplement de les uploader sur
Youtube,
Dailymotion ou
Google Vidéo, mais bon, c'est quand même plus sympa de les héberger chez soi. J'ai donc commencé à chercher des solutions, et j'ai expérimenté
ITheora et
Flowplayer.
ITheora
ITheora est un emballage en PHP autour de
Cortado, une applet Java qui permet de visionner des vidéos encodés en Ogg Theora. Itheora y ajoute la possibilité de passer par le visionneur intégré dans le navigateur si il est disponible, ce qui est sympathique si l'on a pas Java ou qu'on ne souhaite pas l'utiliser. Cela étant, pour ceux qui n'ont pas de visionneur installé, il faut passer par Java, et Java est nettement moins souvent installé sur les machines qu'un visionneur Flash, tout propriétaire soit-il. Je suis pas fan de Java pour des applets Web, mais en l'occurence, c'est la seule alternative bientôt-libre à Flash que je vois.
L'installation est très facile, et on arrive rapidement à streamer un gros fichier Ogg Theora. Seul soucis: la barre de progression dans ma vidéo ne fonctionne pas, et il n'arrive pas à trouver la durée de la vidéo. Je peux seeker dans la vidéo, mais à chaque fois que je seeke, la barre revient au début, même si il a bien seeké dans la vidéo. Étrangement,
mplayer a aussi du mal à seeker dans mes vidéos Ogg Theora (alors que
Xine y arrive très bien). Elles sont pourtant simplement générées avec
ffmpeg2theora, sans magie particulière. C'est plutôt ennuyeux de ne pas pouvoir se balader dans une vidéo, surtout quand elle fait plus d'1h30 comme la conférence de Richard Stallman.
En plus du fait que c'est en Java, l'autre "inconvénient" de ITheora, c'est que l'habillage PHP n'est pas parfaitement intégré avec l'applet Java: l'habillage PHP propose des boutons lecture, arrêt, mais pas la barre de progression, et l'applet Java propose elle aussi les boutons de lecture, arrêt et également une barre de progression, bref les contrôles sont en double. Pas hyper gênant, mais pas très élégant non plus.
Flowplayer
Flowplayer est un visionneur de vidéos Flash libre. Vous avez toujours besoin d'un player Flash (je n'ai testé qu'avec le player Flash privateur d'Adobe, il faudrait tester avec Gnash pour voir si ça fonctionne). Flowplayer n'accepte pas les vidéos au format Ogg Theora, il faut d'abord les
convertir au format FLV. C'est un point ennuyeux, car cela signifie qu'il faut deux versions de chaque vidéo sur son site Web: une au format Ogg Theora pour ceux qui veulent télécharger, une au format FLV pour ceux qui veulent regarder en ligne. Là dessus, ITheora marque un point, car il utilise directement la vidéo en Ogg Theora.
Une fois converti en FLV, si la vidéo est de courte durée, on arrive assez rapidement à faire fonctionner Flowplayer. Par contre, dès qu'on attaque une vidéo de plus longue durée, ça ne fonctionne plus: comme expliqué sur
cette page, il faut un serveur de streaming. Ils proposent plusieurs solutions, assez compliquées puisqu'il faut mettre en place un vrai serveur de streaming.
J'ai donc cherché un peu et suis tombé sur un
module Apache permettant de streamer les FLV. Livré sans aucun Makefile, sans aucune documentation, j'ai bataillé pendant un moment pour compiler ce module. Une fois qu'il était compilé et installé, ça ne fonctionnait toujours pas. J'ai commencé à débugger le code, compris quelques problèmes du machin, corrigé ces problèmes, mais ça ne fonctionnait toujours pas (cela, il peut être intéressant de reprendre ce travail, et de packager proprement ce module, il peut certainement être utile à d'autres personnes).
Je me suis donc rabattu sur la solution
bidouille PHP proposée sur le site de Flowplayer. Et effectivement, en dix minutes, c'était fonctionnel. On peut seeker dans la vidéo sans soucis. Flowplayer est agréable à utiliser, l'interface est propre et soignée (bien plus que pour ITheora/Cortado).
Mais évidemment, deux inconvénients restent de taille: l'utilisation de Flash et l'obligation de convertir les vidéos au format FLV et donc de les avoir en double.
Conclusion
Au final, je n'ai donc toujours pas trouvé de solution qui me convenait totalement. Si j'arrive à résoudre le problème de seek avec les Ogg Theora et Cortado, peut-être que ce sera le bon choix. Cela étant, ça oblige aussi à avoir toutes les vidéos en Ogg Theora (ce qui n'est pas le cas aujourd'hui), et cela pose aussi des soucis: tout le monde, notamment les gens sous Microsoft Windows, n'a pas de lecteur capable de lire le Ogg Theora, et le Ogg Theora n'est
clairement pas un bon codec en terme de qualité d'image, même ça semble bouger de ce coté.
Une autre alternative serait de tester Flowplayer avec Gnash et de voir si ça fonctionne. Mais même si cela fonctionne, ce n'est pas vraiment satisfaisant de faire la promotion d'un format fermé comme Flash sur un site de promotion des Logiciels Libres.
Digital Scratch 1.0
Digital-Scratch est un projet lancé il y a quelques années par deux amis de l'
UTBM. Il consistait à développer un logiciel libre permettant de piloter un lecteur MP3 à partir des mouvements effectués par un DJ sur un vinyle. Des solutions commerciales, comme Final Scratch, existaient, mais aucune n'était sous licence libre. Au départ, ils ont commencé en essayant de réaliser leur propre vinyle, avec un
timecode approprié, avec des résultats qui commencaient à être intéressants, mais pas totalement satisfaisants. Puis la fin des études est arrivée, le travail a commencé, et le projet s'est un peu calmé.
Quelques mois plus tard, l'un des deux, Julien Rosener, a repris le travail sur ce projet. Plutôt que de travailler sur des vinyles conçus maisons, chers à faire produire, il est parti sur le vinyle de Final Scratch, la solution propriétaire et commerciale. En effet, il est possible d'acheter séparement le vinyle pour une poignée d'Euros. Après plusieurs mois de travail et de mise au point, il a sorti le mois dernier la version 1.0 de Digital Scratch, qui fonctionne avec ce vinyle conçu à l'origine pour Final Scratch. Digital Scratch se présente sous la forme d'une bibliothèque sous licence GPL, intégrée au logiciel libre
Mixxx. Pour l'instant, le MIxxx utilisé est un
fork du Mixxx original, mais l'intégration dans la version officielle de Mixxx des améliorations nécessaires est en cours.
En terme de fonctionnalités, Digital Scratch fait les choses suivantes: lecture du MP3 quand la tête de lecture de la platine vinyle est sur le vinyle, pause du MP3 quand la tête de lecture ne lit plus le vinyle, accélération et ralentissement de la lecture du MP3 en fonction de la vitesse de lecture du vinyle, changement de position dans le MP3 en fonction de la position de la tête sur le vinyle, etc. Tout cela est mieux illustré au travers d'une démonstration, sous forme de
vidéo disponible sur le site de Digital Scratch.

Si le sujet vous intéresse, des paquets pour Ubuntu Feisty sont disponibles, et vous pouvez également rejoindre la
liste de discussion.
Informatique et Logiciels Libres à Dédougou, Burkina Faso

Bruno Binet, un ami et ancien collègue de l'
UTBM est avec sa femme depuis le début du mois de juillet et jusqu'à fin août à
Dédougou, une ville du Burkina Faso. Leur projet est
« d'équiper une salle informatique de 15 ordinateurs en réseau, de former des gens pour l'exploiter et le maintenir, de proposer des logiciels éducatifs, des supports de formation, des applications de bureautique et de gestion, et d'initier le plus grand nombre à l'utilisation de l'outil informatique ». Ce projet est décrit en détail sur
leur site.
Sur le
blog qu'ils tiennent depuis le début de leur aventure, ils relatent la progression de leur projet sur place (montage de la salle informatique, formation des personnes, initiations), mais aussi la vie sur place, puisqu'ils sont en immersion complète dans la culture et dans la vie quotidienne du Burkina Faso.
Pour ceux intéressés par le coté technique, Bruno a rédigé une série de billets sur
le matériel, sur
l'installation du système, sur
l'environnement des utilisateurs, sur
le peaufinage de l'environnement et l'automatisation de la configuration ainsi que sur
l'administration du réseau. Et évidemment, tout ça fonctionne avec des Logiciels Libres, avec évidemment GNU/Linux, mais aussi la suite éducative libre
GCompris.
Ceux qui veulent en savoir plus sur la culture et la vie quotidienne peuvent parcourir les autres billets, comme par exemple celui sur
le marché de Dédougou ou celui sur le
mariage burkinabé.
En tout cas, cette expérience doit être vraiment dépaysante, et donc passionnante !
À propos des assertions
Lu récemment dans un courrier électronique de la
LKML (Linux Kernel Mailing List), un propos que j'ai trouvé très juste :
"A programmer who uses assertions during testing and turns them off during production is like a sailor who wears a life vest while drilling on shore and takes it off at sea."
Tony Hoare
Traduction rapide: un programmeur qui utilise des assertions durant les tests et les désactive lors de la mise en production est comme un navigateur à voile qui porte un gilet de sauvetage lorsqu'il navigue près du rivage et qu'il l'enlève lorsqu'il part en mer.
Pour ceux qui ne connaissent pas le principe des
assertions, il s'agit en gros d'insérer dans un programme informatique des lignes de code qui vont vérifier que certaines conditions qui doivent être vraies (de par la construction du programme) sont réellement vraies. Par exemple, les pré-conditions d'une fonction, les invariants de boucle, les post-conditions, ou autres. Il ne s'agit évidemment pas de faire du traitement d'erreur, mais de vérifier que le code que l'on a conçu pour s'exécuter dans des conditions bien précises s'exécutent bien dans les conditions prévues.
Pour information,
Tony Hoare est l'inventeur de l'algorithme de tri Quicksort ainsi que du principe du moniteur en synchronisation, et de bien d'autres choses encore. Il travaille actuellement chez
Microsoft Research. Il a également écrit un petit papier sur les assertions, intitulé
Assertions: a personal perspective, que je n'ai pas encore eu le temps de lire.
Vidéos Google: Git et The Paradox of Choice
Aujourd'hui, j'ai enfin pris le temps de regarder la vidéo de la
conférence donnée par Linus Torvalds à propos de Git dans les locaux de Google. Mon
frère y avait assisté, et m'avait indiqué que ce n'était pas terrible. Et effectivement, ce n'est pas terrible. Presque la moitié du temps, Linus Torvalds dit que CVS c'est pourri, Subversion c'est pourri, que tous les trucs centralisés sont pourris, et qu'en fait, à part Git, tous les trucs distribués sont également pourris. On a parfois l'impression qu'il utilise la technique du « à force de répéter un truc sans argumenter, je vais finir par convaincre les gens ».
En réalité, il avance quand même quelques arguments (heureusement). Par exemple, que l'aspect distribué permet de créer des branches locales sans embêter tout le monde et permet à des développeurs de travailler ensemble sans nécessairement passer par le dépôt central (ce qui peut-être problématique si l'on doit mettre au point une grosse fonctionnalité à plusieurs avant de pouvoir la
committer dans le dépôt central). Il m'arrive effectivement d'utiliser
Quilt pour préparer tranquillement un ou plusieurs patches avec de les committer dans un dépôt Subversion commun.
Ensuite, il avance l'argument de la facilité de
merging. Autant je rejoins totalement Linus sur les difficultés du
merging avec CVS, autant je n'arrive pas à saisir les difficultés de
merging dont il parle avec Subversion. Peut-être est-ce parce que je n'ai jamais travaillé sur des projets aussi volumineux en terme de code que le noyau, mais j'ai le sentiment qu'avec Subversion, le processus de
merging est on ne peut plus simple. La seule difficulté est évidemment de résoudre les conflits quand il y en a, mais j'ai du mal à croire que Git résolve automagiquement les conflits. Bref, j'aimerais bien en savoir plus sur cette fonctionnalité de
merge magique de Git.
(Pour l'anecdote, le processus de
merging est si difficile qu'il m'a fait découvrir
awk : il m'était en effet nécessaire d'écrire des scripts shell pour résoudre des conflits automatiquement et faire d'autres opérations pseudo-automatiques pour rendre le
merging vivable. Depuis, je connais
awk et j'aime ça :-))
Après avoir regardé cette vidéo, je me suis mis à traîner dans les vidéos de confs ayant eu lieu à Google, et je suis tombé sur
The Paradox of Choice - Why More Is Less, que j'ai trouvé vraiment très intéressant. En général, on considère que plus de choix implique plus de liberté et que plus de liberté implique plus de bonheur, de joie de vivre, etc. À partir de quelques exemples et de quelques études, l'orateur essaie de montrer que ce n'est pas toujours vrai. J'ai trouvé le propos souvent assez juste, m'étant moi-même retrouvé dans certains des exemples. Il est assez difficile de résumer cette présentation en quelques lignes, alors je vous invite plutôt à la regarder.
Elle est sous-titrée en anglais, ce qui rend sa compréhension relativement aisée, même si les sous-titres se décalent de plus en plus au fur et à mesure que l'on avance dans la vidéo. Le son est de très bonne qualité et l'orateur a un accent très compréhensible. Seul reproche : on comprend que l'orateur montre de temps en temps des transparents avec des petites bandes dessinées qui font rigoler l'audience, mais en tant que spectateur, on ne les voit malheureusement pas.
Canon Powershot S3 IS

Il y a
une semaine, c'était mon anniversaire, et j'ai été très heureux de recevoir pour cadeau un appareil photo numérique
Canon Powershot S3 IS. Ce n'est pas un de ces tous petits appareils photo numériques qu'on peut glisser dans la poche, mais plutôt un modèle un peu plus imposant, avec donc des fonctionnalités et des possibilités un peu plus intéressantes. Un zoom optique 12x, un stabilisateur d'image, le réglage manuel de nombreux paramètres, la prise de vidéo en 640x480 et son stéréo avec une image vraiment bonne, etc.
Les quelques clichés déjà pris avec cet appareil me semblent pas mal du tout, mais il faut maintenant que
j'apprenne un peu les principes de base de la photographie, qui me sont pour l'instant plutôt étrangers.
D'un point de vue compatibilité avec le Logiciel Libre, l'appareil fonctionne parfaitement avec
gphoto2 : on peut donc récupérer les photos et les vidéos directement depuis l'appareil, sans débrancher la carte SD. On peut également commander l'appareil depuis gphoto2, par exemple pour prendre des clichés toutes les
x secondes, automatiquement transférés vers l'ordinateur. Par contre, je n'ai pas encore réussi à faire une vidéo qui est transférée au fur et à mesure vers l'ordinateur. Je ne sais pas si l'appareil le permet, mais ce serait fort pratique pour enregistrer des conférences.
Toujours du coté Logiciel Libre, j'ai découvert pas plus tard qu'aujourd'hui que des gens avaient développé
CHDK, un firmware libre (sous licence GPL) pour plusieurs appareils photos numériques Canon, dont le Powershot S3 IS. Ce firmware permet d'ajouter des fonctionnalités telles que l'enregistrement des images RAW (qui n'est pas disponible dans l'appareil par défaut), un navigateur de fichiers, des histogrammes live (histogramme RGB, histogramme de luminance, etc.). Visiblement, l'appareil fonctionne avec un processeur ARM, le firmware libre est développé en C et se compile avec
gcc, tout simplement.
Évidemment, comme toujours avec ces machins customisés se pose la
question de la garantie. Question rendue encore plus épineuse par le fait que le firmware en question, dans son mode par défaut, n'est pas flashé dans l'appareil : il s'exécute seulement si on le demande. Le firmware d'origine reste en place, sans être modifié.
Concours de l'ICFP
Tous les ans, en marge de l'
International Conference on Functional Programming a lieu l'ICFP Contest, un concours de programmation de 72 heures.
L'
année dernière, je n'avais pas participé pendant le concours, mais avait fait une partie du sujet. Ce dernier était vraiment amusant : on récupérait une grosse image binaire et les spécifications d'une machine capable d'exécuter l'image binaire. Il fallait donc commencer par programmer une sorte de machine virtuelle, pour exécuter l'image binaire. Une fois ceci fait, l'exécution de l'image binaire permettait d'entrer dans une sorte de mini-système d'exploitation, dans lequel il y avait tout un tas de défis à relever. À chaque défi réussi, on recevait un
hash permettant d'attester du succès de l'équipe et de le saisir dans le site Web (ce que je n'avais pas fait, puisque le concours était terminé depuis bien longtemps). Il fallait par exemple bricoler avec un interpréteur
BASIC qui numérotait les lignes avec les chiffres romains, ou encore travailler avec un langage de programme en 2D, style ASCII-Art. C'était vraiment passionnant. Le code de la machine virtuelle que j'avais écrit et optimisé avec l'aide de quelques amis est
par ici.
Du coup, pour cette année, je me suis dit que j'allais essayé de participer. Le concours a lieu ce WE, de vendredi midi à lundi midi, et le sujet est disponible sur
icfpcontest.org. On récupère l'ADN d'un extraterrestre, qu'il faut modifier pour l'adapter à la vie sur terre. Pour cela, il faut transformer cet ADN en ARN, puis en image PNG. L'ADN fourni permet d'aboutir à une
image donnée, et tout l'objectif est de modifier l'ADN pour qu'après la génération de l'ARN, puis de l'image, on arrive à une
autre image. Les règles pour passer de l'ADN à l'ARN, puis de l'ARN à l'image sont fournies.
Entre hier soir et ce matin, j'ai réussi à faire un convertisseur ADN vers ARN, implémenté en Python. Il passe les tests basiques, mais est vraiment très lent: 1 minute 22 secondes pour 1000 itérations, alors qu'il y a près de 2 millions d'itérations à faire d'après le sujet. Visiblement, les rédacteurs du sujet s'attendaient à cela, puisque dans le chapitre 6, il est clairement indiqué qu'il faut faire très attention aux performances. Ne sachant pas vraiment comment fonctionne Python en interne, j'ai choisi de recoder le tout en C. Mais les performances ne sont guère meilleures : 1 minute et 12 secondes pour 1000 itérations. Pour les curieux, mon code est
par là. Le code C est clairement immonde, avec des gros buffers statiques à droite à gauche pour aboutir rapidement à un prototype fonctionnel.
Du coup, même après avoir passé la journée sur ce convertisseur ADN vers ARN, je suis toujours bloqué. Il doit y avoir une astuce, un raccourci qui n'est pas exprimé dans le sujet, mais qu'il faut trouver.
Enfin, en tout cas, comme l'an dernier, le sujet est vraiment très prenant.
Départ pour le Linux Symposium

Comme je l'avais annoncé dans un précédent billet, je pars demain au
Linux Symposium à Ottawa, une conférence de 4 jours, principalement sur le noyau Linux. Comme tous les ans, le
programme est absolument somptueux, et on se demande bien quelle conférence choisir parmi les 3 ou 4 simultanées, toutes plus intéressantes les unes que les autres. Des orateurs comme Jonathan Corbet (Linux Weekly News), Avi Kivity (développeur de KVM), Paul Ménage (qui travaille chez Google sur les mécanismes de conteneurs), Greg Kroah Hartmann (de très nombreux pilotes de périphériques, et la couche de gestion des pilotes elle-même), Arnd Bergmann (un des développeurs du noyau Linux pour le processeur Cell), Rusty Russell (plein de choses, en particulier coté réseau, mais sa conférence portera sur lguest), Zach Brown, Mel Gorman (avec son interminable travail sur la VM du noyau), Christophe Lameter (et son obsession pour la scalabilité), et bien d'autres, dont Michael Opdenacker, de la société
Free-Electrons. La keynote de cloture sera donnée par James Bottomley, qui travaille notamment sur la couche SCSI du noyau Linux.
Comme il y a
deux ans, j'espère que j'aurai la possibilité de faire sur ce site un compte-rendu détaillé des différentes conférences auxquelles j'aurai assisté.
Travailler à la campagne
Quand je regarde les entreprises qui sont dans le domaine du développement logiciel ou les offres d'emploi dans le monde du Logiciel Libre, je constate toujours qu'une très grande partie de ces entreprises sont entassées dans Paris ou la proche banlieue. Par exemple, la société
Mandriva est basée en plein Paris, alors qu'une partie significative de son activité consiste en du développement logiciel, qui pourrait très bien être fait n'importe où en France, à partir du moment où un accès Internet est disponible. Autant pour les activités administratives ou commerciales de l'entreprise, je comprends tout à fait les avantages à être dans une grande ville, autant pour les départements plus orientées recherche et développement, je ne saisis pas vraiment l'intérêt à aller s'entasser tous à Paris. Certes, la vie culturelle et associative y est riche, les transports en commun nombreux et pratiques, mais il n'y a pas de verdure, de la pollution, du bruit, des temps de transport importants, du stress, des loyers élevés et une vie globalement assez chère. Pourquoi est-ce que les départements recherche et développement ne pourraient pas s'installer dans des villes plus agréables, à la montagne ou à la mer ?
J'en discutais justement ce week-end avec un ancien camarade de l'
UTBM, et j'ai été agréablement surpris de trouver un article sur ce sujet dans le dernier numéro de
01 Informatique (celui du 30 mars). L'article est intitulé
Un éditeur attire ses recrues en Ariège, et évoque l'ouverture par la société de services en Logiciels Libres
Anyware Technologies, basée à Toulouse, de l'ouverture d'un département de développement dans le département de l'
Ariège, à 60 kilomètres au sud de Toulouse.
Le chapeau de l'article:
L'entreprise Anyware opère son prochain recrutement en Ariège. L'idée ? Une qualité de vie inégalable pour ingénieurs de haut niveau ! Au menu: ski, air pur et logiciel libre.
Le début de l'article:
Et si les meilleures idées jaillissaient sur les pistes de ski ? Ludovic Le Moan, fondateur et PDG d'Anyware Technologies, n'est pas loin de le penser. Voilà pourquoi la société de conseil et de développement en logiciel libre recrute une quinzaine d'ingénieurs de haut niveau pour les installer à une soixantaine de kilomètres de son siège toulousain.. en Ariège. « Nos ingénieurs sont des "geeks" et de vrais créatifs. Ils ont besoin d'un environnement favorable au travail de leur imagination, met en avant Ludovic Le Moan. De plus, ce sont souvent des amateurs de sports de glisse. Alors pourquoi n'iraient-ils pas skier entre deux développements ?»
Il est précisé qu'
Anyware ne se contentera pas d'une poignée de télétravailleurs isolés. La société ambitionne de disposer un noyau de quelques personnes pour créer un vrai pôle..
Une initiative vraiment intéressante, à mon avis: une qualité de vie plus grande, une vie moins chère, et certainement des coûts moins importants pour l'entreprise.
Pour ma part, l'entreprise dans laquelle je travaille a installé l'équipe de recherche et développement à
Colomiers, donc en banlieue toulousaine, où il reste encore un peu de verdure et où je peux me rendre facilement en vélo au travail.
Note: non, je ne suis pas personnellement abonné au génialissime magazine 01 Informatique, je le lis à mon job :-)
PyRPC 1.1
Suite à une demande d'une personne m'ayant contacté par courrier électronique, peut-être un des rares utilisateurs de
PyRPC, j'ai mis à jour ce petit bout de code qui permet d'utiliser des
Sun RPC depuis du code Python. Seule la génération des
stubs client est possible, mais cela permet déjà de se connecter à un serveur existant en développant un client en Python.
En fait, ce petit bout de code que j'avais repris et un peu amélioré fin 2005 ne fonctionnait plus parce qu'entre temps,
PLY (une implémentation en Python de Lex et Yacc) est passé de la version
1.6 à la version
2.2. Après un peu de temps pour se replonger dans ce code, j'ai finalement trouvé ce qui clochait.
PyRPC 1.1 est donc disponible, fonctionnel avec PLY 2.2. J'ai testé en utilisant
pydemexp, et j'arrive correctement à m'interfacer avec le serveur
demexp.
Spam, snif ...
Malgré l'utilisation de Spamassassin sur mon serveur de courrier électronique (les courriers dont le score est supérieur à 8 sont supprimés, les courriers dont le score est compris entre 5 et 8 sont redirigés vers le dossier
spam), je reçois une quantité assez impressionante de
spam. Et c'est lourd, vraiment lourd. Mon spamassassin semble être efficace, puisque le jour où je l'ai désactivé pour tester, j'ai reçu 75 spams dans l'heure. Mais aujourd'hui, même activé, j'en reçois au moins une dizaine par heure, si ce n'est plus.
Mais le pire, c'est peut-être le spam qui arrive sur les listes de discussions. Je suis administrateur d'un certain nombre de listes de discussions (3 pour
Toulibre, 2 pour l'
Agenda du Libre) et quelques autres encore. Et là, il n'y a pas de Spamassassin derrière, alors il faut régulièrement aller faire le ménage dans l'interface d'administration pour dégager toutes les propositions de Viagra ou d'or en quantité astronomique au Nigéria. Et évidemment, à chaque mail bloqué en modération sur une liste, je reçois une notification par courrier électronique... amplifiant encore le nombre de mails indésirables que je reçois.
Franchement, ce spam commence à rendre vraiment pénible l'utilisation du courrier électronique. Y'a-t-il une solution à part personnaliser sans cesse spamassassin pour qu'il s'améliore un peu ?
Projet Nouveau, pilote libre pour les cartes Nvidia
En mai de cette année, j'
évoquais le projet
nouveau qui avait pour objectif de produire un pilote libre supportant l'accélération 3D pour les cartes graphiques du constructeur Nvidia. Un projet assez fou, mais évidemment très intéressant, car le monde des cartes graphiques semble aujourd'hui de plus en plus bouché vis-à-vis du monde du Logiciel Libre.
Aujourd'hui,
une faille de sécurité dans le pilote propriétaire Nvidia relance le débat sur le problèmes des pilotes propriétaires, et remet sur le devant de la scène ce projet
nouveau. Je suis donc allé faire un tour, et le projet semble avoir avancé: il y a maintenant du code qui fait quelque chose (visiblement principalement une reprise du pilote 2D libre, mais sans l'obfuscation du pilote d'origine), et l'ingénérie inverse des fonctionnalités 3D semble avoir progressé au vu de la
matrice disponible sur le site.
Il y a même une
documentation expliquant comment compiler et utiliser ce pilote libre. C'est encore un peu funky, mais cela semble néanmoins très prometteur.
Dans un autre domaine, mais toujours sur le sujet des alternatives libres qu'on attend depuis longtemps: le lecteur Flash libre
Gnash est entré dans Debian. Apparemment, il supporte de nombreuses fonctionnalités de Flash 7 (même si aujourd'hui Flash 8 semble être de plus en plus utilisé sur le Web). Le chemin d'un lecteur Flash libre utilisable semble donc tracé.
Statistiques de flux RSS
Aujourd'hui, j'ai cherché un outil de statistiques de flux RSS pour l'Agenda du Libre, mais je n'ai rien trouvé. En fait, je cherche quelque chose qui soit capable de générer des statistiques similaires à ce que propose le service
FeedBurner, et notamment le nombre d'abonnés à chaque flux RSS. Seulement, ça m'embête un peu de faire passer tous les flux RSS de l'Agenda du Libre par "FeedBurner", je préfèrerais utiliser un outil libre que j'installe sur le serveur directement.
Évidemment, j'ai déjà les statistiques HTTP fournies par Webalizer, mais ça ne me donne pas le nombre d'abonnés à chaque flux RSS.
Une idée ?
La magie ou l'horreur de CUPS
CUPS, le machin d'impression sous GNU/Linux, c'est vraiment le truc qui me donne mal au cerveau rien que de penser qu'il faille y toucher.
Bref, je voulais remettre en route mon imprimante HP, sachant que j'avais déjà une imprimante Canon installée et configurée. Mes deux imprimantes sont connectées via USB à mon serveur, et je voulais que les autres ordinateurs y aient accès via le serveur. Ceci se fait "relativement" simplement, mais un point me choquait: pourquoi sur toutes les bécanes clientes il fallait sélectionner la marque et le modèle de l'imprimante (ce qui permet de choisir le fichier PPD), alors que le serveur sait très bien tout ça. J'ai donc creusé un peu cette mystérieuse affaire.
Dans le fil de l'histoire, je suis tombé sur
doc de KDE qui explique plutôt bien ce qu'est le Postscript, le RIP, où interviennent CUPS, les PPDs et autres filtres. Une bonne introduction, en français qui plus est. Une fois ces idées bien remises en places, me voilà en quête de la documentation de CUPS. Sur le site Web, il y a plein de
bordel, mais je n'ai pas trouvé de doc complète sur l'aspect "Utilisateur". Ah bah, oui, forcément, ils vendent $45.00 un
bouquin qui explique tout...
Un peu plus tard, au fil de mes recherches, je tombe sur un
texte d'Eric Raymond qui résume plutôt bien l'impression que ça peut faire de toucher à un truc comme CUPS.
Bref, au détour de tout ça, j'arrive quand même à découvrir que CUPS supporte le protocole
IPP, un protocole normalisé par l'IETF avec des RFCs et tout ce qui va bien. Et d'après la
doc de KDE, ce protocole permet justement de récupérer le fichier PPD décrivant une imprimante, évitant d'avoir à installer un pilote sur tous les postes clients. Voilà qui semble intéressant. Malheureusement, lorsque j'essaie d'ajouter une imprimante réseau via l'interface Web de CUPS ou via gnome-cups-manager avec une adresse du genre
ipp://gate:631/printers/hp, il me demande invariablement la marque et le modèle de l'imprimante. Saleté.
Un peu plus tard, je découvre la commande
lpinfo, qui permet d'interroger un serveur d'impression:
thomas@skim# lpinfo -h gate:631 -v
network socket
network beh
direct usb://Canon/S300
direct hp:/usb/DeskJet_930C?serial=CN0CN1S1J2JJ
network http
network ipp
network lpd
direct parallel:/dev/lp0
direct canon:/dev/lp0
direct epson:/dev/lp0
network smb
Magique: depuis ma machine cliente, j'arrive à interroger le serveur pour lister les imprimantes qui sont disponibles... Mais ça ne m'avance pas beaucoup.
Puis, au détour d'un
Wiki, je découvre que normalement, le PPD peut-être récupéré très simplement par HTTP en récupérant le fichier à l'adresse
http://hote:port/printers/nom_imprimante.ppd, chez moi
http://gate:631/printers/hp.ppd. Et effectivement, ça marche ! Alors, si c'est aussi simple, pourquoi l'interface Web ou Gnome de CUPS ne le récupèrent pas ?
Si c'est l'interface qui est merdique, alors passons en ligne de commande. J'édites donc le fichier
/etc/cups/printers.conf sur la machine cliente et j'ajoute une section
Printer en donnant l'adresse
IPP qui va bien. Et là, effectivement, comme par magie, ça fonctionne sans donner le PPD ni le modèle de l'imprimante. C'est pas beau la vie ?
Bon, dans tout ça, il faudrait maintenant comprendre pourquoi 1) l'outil ne permet pas de "voir" les imprimantes du réseau et surtout 2) pourquoi il ne sait pas récupérer le PPD tout seul, comme un grand. Enfin en attendant, les deux imprimantes marchent et sont faciles à configurer sur tous les postes clients une fois que c'est fait sur le serveur.
Reste quand même des questions: quand le PPD est récupéré sur la machine cliente, est-ce que c'est la machine cliente qui fait la transformation Postscript vers le langage tout propriétaire bizarre de l'imprimante ? Si oui, comment fait la machine cliente pour exécuter tous les filtres (programmes exécutables) qui sont nécessaires pour le PPD ? Et si c'est le serveur qui fait la transformation, comment fait le client pour envoyer les paramètres listés dans le PPD (contraste, luminosité, qualité, etc..) ? Mystère et boule de gomme.
Newsforge, un site de nouvelles pas mal
Ça fait un moment que je suis abonné au flux RSS de
NewsForge, un site de dépêches concernant Linux et le Logiciel Libre. Bien que le site soit un peu trop rempli de publicités à mon goût, j'ai le sentiment de voir depuis quelques temps des nouvelles et articles intéressants. Par exemple, il y a eu des comptes-rendus intéressants pour des conférences comme le Linux Symposium (
jour 1 jour 2 jour 3 jour 4), sur OSCON (
jour 1 jour 2 jour 3 jour 4 et un peu plus) et Black Hat (
jour 1 jour 2). Il y aussi des petits tests comme un test de
Thunderbird 2.0 ou des articles un peu plus
d'opinion. Alors ce n'est peut-être pas du grand journalisme, mais je trouve les articles plus complets que ceux que l'on peut trouver sur LinuxFr.org ou Slashdot, et ils traitent des sujets assez variés.
Bref, je veux pas faire de pub', mais si vous connaissiez pas ce site, ça vaut peut-être le coup d'y jeter un oeil.
Toulouse Carnet
À Paris, il y a
Paris Carnet, « une rencontre parisienne mensuelle autour d’une bière (ou autre breuvage), chaque premier mercredi du mois, entre blogueurs, carnétistes, jouébeurs, wikistes et autres sympathisants ». Ces rencontres sont souvent relatées par
Bix sur son blog, et ses billets à ce sujet donnent envie d'aller à une de ces rencontres.
Il y a quelques jours, j'ai reçu un courrier électronique m'invitant à participer au premier Toulouse Carnet. Comme Paris Carnet, mais ici, dans la ville rose. Une excellente initiative qui peut donner lieu à des rencontres intéressantes. À Paris, le public semble assez être d'origines assez diverses, ce qui donne tout l'intérêt de la rencontre. À Toulouse, je ne sais pas si il en sera ainsi dès le départ, mais peut-être qu'au fur et à mesure le public s'élargira. À voir !
Le premier Toulouse Carnet (qui ne semble pas encore avoir de site Web) aura donc lieu demain vendredi 4 août. Je ne pourrais malheureusement pas m'y rendre, mais j'espère être tenu au courant de la prochaine édition, et je compte bien m'y rendre.
Planet UTBM
J'avais proposé il y a quelques temps la création d'un site Web
Planet UTBM, pour syndiquer les blogs d'étudiants ou d'anciens étudiants de l'UTBM. Puis finalement, c'était passé à la trappe. Il y a quelques jours, j'ai proposé à nouveau cette idée sur IRC, quelques personnes ont semblé emballées, alors je me suis lancé.
Planet UTBM tourne maintenant, à l'adresse
http://planet.utbm.info.
Pour l'instant, seuls 5 blogs sont syndiqués. Lecteur, si tu es à l'UTBM, ou que tu as été à l'UTBM, tu peux m'envoyer le lien vers le flux RSS de ton blog, ton nom, ton surnom, ta promo et ton
hackergotchi. Toi, là au fond, tu sais pas ce que c'est qu'un
hackergotchi ? Tu as de la chance, parce que moi non plus, je savais pas. En fait, c'est la petite tête du bonhomme auteur d'un billet que l'on voit fréquemment sur les différentes planètes. La page Wikipédia explique ça mieux que moi, et d'ailleurs il faudrait en faire une dans la Wikipédia française. Avis aux amateurs ;-)
Sinon, pour les geeks qui me lisent, ce Planet est bien sûr basé sur
PlanetPlanet. Visiblement, c'est le truc de référence dans le domaine. Enfin, c'est forcément le truc de référence puisque c'est plus ou moins le seul qui existe apparemment. C'est relativement simple à configurer, et la documentation explique ça assez bien. Au niveau du design Web, comme mes talents de graphistes laissent à désirer, j'ai repompé sans vergogne
ce design trouvé sur
Open Source Web Design. Ça fait un truc assez propre je trouve.
Avec tout ça, j'en ai profité pour améliorer un peu le flux RSS de ce blog. Maintenant, les champs dc-language, mais surtout dc-date sont renseignés. Et de plus, le titre du billet n'est plus présent en double (dans le titre et dans le corps). Trop fort ;-)
Vidéos de l'atelier « Petit voyage au coeur d'un OS »
Comme annoncé sur
LinuxFr.org,
Michael Opdenacker vient de mettre en ligne les vidéos de l'atelier « Petit voyage au coeur d'un OS » que Renaud Lottiaux et moi-même avons présenté lors des
RMLL. La vidéo est découpée est 5 parties, pour un total d'environ 3.5 Go (environ 6 heures de vidéo).
Par ailleurs, les slides sont disponibles au format
OpenOffice (la version
PDF n'est pas terrible car toutes les animations ont disparu). Le code source des petits programmes d'illustration utilisés pendant l'atelier est également disponible
ici.
Avec cette formule de 2 fois 3 heures, j'ai eu l'impression que nous avons eu le temps de balayer la plupart des sujets vraiment importants. L'an dernier, à Dijon, je n'avais que 3-4h pour la présentation, et c'était vraiment insuffisant pour aborder sérieusement les systèmes de fichiers ou le VFS. Au niveau de la présentation en elle-même, je pense que les parties gestion de la mémoire, systèmes de fichiers et VFS étaient plutôt pas mal. Claires, complètes, compréhensibles. Par contre, je pense que toute la partie sur la gestion des processus et les changements de contexte gagnerait à être améliorée. Je sais pas dans quel sens, mais j'ai le sentiment que ce n'est pas encore vraiment compréhensible. De plus, la partie sur la pile et les conventions d'appel, dès le début, est un peu indigeste.
N'hésitez pas à me faire part de vos remarques et suggestions sur la façon d'améliorer ou de compléter cet atelier. Il se pourrait qu'il soit à nouveau réalisé dans d'autres lieux.
Ottawa Linux Symposium 2006
L'année dernière, j'ai eu la chance de pouvoir participer à l'Ottawa Linux Symposium, dont j'avais fait un
compte-rendu ici même. J'ai reçu des relances par courrier électronique pour cette année, mais je viens seulement de consulter le programme de cette conférence. Et bien, comme l'année dernière, le programme est très, très intéressant. Il y a de nombreuses
conférences mais aussi plusieurs
tutoriaux. Il y a notamment plusieurs confs sur les systèmes de fichiers, le stockage ou le réseau:
The Effects of Filesystem Fragmentation par
Giel de Nijs, qui avait présenté
ABISS l'an dernier,
The Need for Asynchronous Network I/O, Problems, and Possible Solutions,
OCFS2: The Oracle Clustered File System, Version 2,
MD RAID Acceleration and the ADMA Interface, une nouvelle conf autour des algos génétiques par le même Jake Moilanen,
I/O Workload Fingerprinting in the Genetic-Library. Il y a également son lot de conférences autour de la gestion de version (Git, Cogito, Mercurial), autour de la virtualisation, mais aussi beaucoup de choses autour des techniques de déboguage et de test du noyau Linux: SystemTap, KProbes, KDump et autres.
J'ai noté que parmi les conférenciers, il y a un toulousain,
Cédric Le Goater, qui travaille pour IBM et qui viendra parler de
Making Applications Mobile Under Linux, c'est à dire de la migration en
live d'applications entre noeuds. Deux autres français présenteront des choses : Tony Reix, de Bull, qui était déjà là l'an dernier, viendra cette fois-ci parler de l'
effort de test réalisé autour de NFSv4, tandis que Stephane Eranian, d'HP, viendra parler de
perfmon2: a Flexible Performance Monitoring Interface for Linux.
Un programme qui s'annonce donc passionnant, alors si vous avez la possibilité d'y aller, n'hésitez pas !
Appel à témoignage de l'UFC Que Choisir
En juin 2005, j'avais fait l'acquisition d'un ordinateur portable Dell. Un système d'exploitation bien connu m'avait alors été imposé lors de cet achat. Comme d'autres, j'avais fait parvenir à Dell une lettre recommandée avec AR pour demander le remboursement de ce système. Sans réponse à ce jour. Par conséquent, j'ai rédigé aujourd'hui
une lettre, destinée à l'U.F.C Que Choisir, qui a lancé un
appel à témoignage :
L'achat d'un ordinateur sans logiciels est-il possible ?
Web 2.0
Au fil de mes balades sur le Web, je suis tombé sur la
traduction en français de ce qui est visiblement considéré comme un des textes fondateurs du buzzword
Web 2.0, le texte
What is Web 2.0, par Tim O'Reilly. Et évidemment, son analyse va bien au-delà du simple buzz autour d'Ajax et de RSS. Il y décortique les mutations du Web, avec des réflexions qui m'ont paru souvent très pertinentes, en particulier dans la partie
Tirer parti de l'intelligence collective.
Git en cinq minutes
Je n'avais jamais eu le temps de regarder Git. J'avais lu quelques articles et tutoriels, mais tout cela m'avait paru un peu obscur. Aujourd'hui, j'ai découvert
ce tutoriel, qui m'a permis de tester en cinq minutes le fonctionnement. Ça ne montre rien d'exceptionnel par rapport à un autre gestionnaire de version distribué, mais ça permet une rapide prise en main de la chose. Suivre les évolutions des branches et des modifications avec
gitk est agréable, aussi.
Mettre en ligne des données avec Bittorrent
Aujourd'hui, j'ai uploadé une vidéo d'une conférence réalisée par Toulibre le mois dernier, et afin de faciliter son téléchargement par d'autres personnes, j'ai regardé comment mettre en place le nécessaire pour permettre le téléchargement via
Bittorrent. Mon cas me semblait assez simple: je voulais simpler ajouter un fichier .torrent à coté de chaque vidéo, et faire que le serveur de Toulibre serve tout ça au travers de Bittorrent, en s'aidant des gens qui téléchargent.
Et finalement, pour faire ça, ça s'est avéré finalement plus complexe que je ne l'imaginais. Je vous propose ici un petit résumé de ce que j'ai fait, largement inspiré de
cette documentation.
Tout d'abord, il faut lancer un
tracker, le bout de logiciel qui va permettre aux clients de se causer entre eux pour récupérer les bouts de fichiers aux endroits où ils sont disponibles :
nohup bttrack --port 6969 --dfile dstate --show_names 1 --allowed_dir ~/WWW/repertoire1/ > /dev/null &
On voit déjà qu'il faut lister tous les répertoires où sont stockés les fichiers
.torrent à partager. Il n'y a visiblement pas d'option qui permette de dire de partager tout ce qui est dans ~/WWW/ récursivement, et on ne peut pas passer plusieurs
allowed_dir. Enfin, on peut,
bttrack ne dit rien, mais ça ne marche pas. Autre solution, on ne met pas l'option
--allowed_dir et dans ce cas, le tracker devient public et peut partager tout et n'importe quoi.
Une fois ceci fait, il faut générer les fameux fichiers
.torrent pour chaque fichier à partager :
btmakemetafile monfichier.avi http://www.toulibre.org:6969/announce
Cette commande va générer le fichier
monfichier.avi.torrent dans le répertoire courant.
toulibre.org:6969 désigne évidemment l'hôte et le port sur lequel le
tracker tourne.
Vous pouvez maintenant mettre en ligne ce fichier
.torrent, le distribuer par courrier électronique, ou pigeon voyageur, et les gens peuvent commencer à télécharger. Sauf que lorsqu'ils lanceront le téléchargement, rien ne se passera, tout restera à 0 : il n'y a pas de client qui partage les données, et le
tracker n'a donc rien à donner aux autres clients. Il faut donc en réalité lancer un client Bittorrent sur le serveur (ici toulibre.org) qui ne va en fait rien télécharger, mais tout uploader. La solution la plus simple que j'ai trouvé est d'utiliser
btlaunchmany dans le répertoire contenant des fichiers
.torrent, en supposant que les fichiers d'origine sont contenus dans le même répertoire (ce qui est le cas, puisque c'est là où vous avez sûrement exécuté
btmakemetafile). On lancera donc dans ce répertoire quelque chose comme :
nohup btlaunchmany . > /dev/null &
Et hop, au bout d'un moment, le téléchargement va commencer auprès des vrais clients. Pour résumer, il faut sur le serveur un tracker ainsi qu'un faux client dans le répertoire contenant des données à partager. Et si il y a plusieurs répertoires contenant des données à partager, il faut un tracker et un faux client par répertoire. Pas pratique. Du coup, j'ai donc laissé tomber l'idée de partager des fichiers qui sont dans plusieurs répertoires.
J'ai cherché des alternatives à ces commandes Bittorrent de base, mais je n'ai rien trouvé de convaincant.
eztorrent encapsule tout ça, mais il n'apporte finalement pas grand chose. Sinon, il existe
tout plein de
trackers en PHP, pas vraiment maintenus, et qui ne jouent que le rôle de
tracker, pas de faux client pour uploader les données à partager.
Soit je n'ai pas bien cherché, soit il y a vraiment une place pour un tracker/server Bittorrent libre, simple et efficace ;-)
Changements dans le dépôt Debian
Il y a quelques temps, j'avais
évoqué mes galères dans la recherche d'un outil simple et efficace me permettant de créer un dépôt Debian dans les règles de l'art. Finalement, n'ayant rien trouvé, je me suis résolu hier à écrire le script
shell ad-hoc pour réaliser cela. Mon
dépôt Debian a maintenant la même structure qu'un dépôt classique (ce qui permet d'avoir des lignes standards dans votre
/etc/apt/sources.list) et il est signé (ce qui évite les warnings GPG et permet de valider que je suis bien à l'origine des paquets). J'en ai profité pour supprimer les paquets concernant la distribution Ubuntu Hoary, estimant que les utilisateurs d'Ubuntu avaient probablement tous migrés vers Breezy.
Pour résumer, il faut maintenant utiliser une ligne du type :
deb http://thomas.enix.org/pub/debian/packages DIST main où DIST peut-être au choix
stable,
testing,
unstable,
sarge,
etch,
sid ou
breezy.
D'autre part, il faut ajouter ma clé dans le trousseau de clé d'APT, en utilisant par exemple les commandes suivantes :
gpg --keyserver pgpkeys.mit.edu --recv-key 98D3F7A7
gpg -a --export 98D3F7A7 | sudo apt-key add -
Bon téléchargement ! ;-)
Café citoyen: « Démocratie Électronique »
Ce lundi, j'ai reçu un courrier électronique annonçant que le soir-même se tenait à Toulouse un
café citoyen autour du thème de la
démocratie électronique. Le thème m'intéressant bien, je m'y suis rendu.
Sur la forme d'abord, cette soirée fût intéressante. Je ne me suis jamais rendu à un café citoyen, donc le déroulement est peut-être classique, mais il m'est apparu original. Arrivé un peu en retard, j'ai raté une bonne partie de l'intervention initiale de la personne du PIC. Une fois son intervention terminée, le débat s'est déroulé de façon très organisée. Lorsqu'une personne souhaitait intervenir, il fallait lever la main. Le responsable de séance, notait alors le souhait de cette personne d'intervenir sur une feuille, afin de lui donner la parole le moment venu. Ainsi, personne n'interrompait personne: chacun avait le temps d'exprimer son idée dans sa totalité, sans être coupé. Les interventions des uns et des autres se faisaient dans l'ordre où les personnes avaient levé la main, modulo les
tours de parole. Ainsi, si une personne lève la main pour la première fois, alors que les personnes sur la liste sont inscrites pour une deuxième intervention, alors cette personne a la priorité et son intervention passe avant les autres. À l'issue des débats, chaque personne est invitée à donner son impression rapide sur la soirée.
Sur le fond, le débat n'a pas pu vraiment s'orienter vers la
démocratie électronique. Moi qui pensait pouvoir parler de
Demexp par exemple, il a fallu finalement parler de bien d'autre chose: Internet, tout simplement. Une bonne partie des personnes présentes, dont la moyenne d'âge devait facilement être autour de 50-60 ans, n'avait en effet pas vraiment connaissance de ce qu'était Internet, et de ce qui était possible avec Internet. Certains n'avaient tout simplement pas Internet, et d'autres l'utilisaient, mais très peu. La vision qu'ils en avaient, c'est un peu la vision stéréotypée que l'on peut s'en faire au travers des médias traditionnels: une montagne de pornographie, un repaire de pirates, d'anonymat permettant aux terroristes de pulluler, une quantité gigantesque d'informations dans laquelle on ne peut pas se retrouver, et dont la qualité n'est pas au rendez-vous, une grosse machine commerciale, un coût important pour l'accès, etc.. Il y a aussi eu l'argumentaire du problème de la perte de contact physique avec les individus lorsque la communication se faisait au travers du réseau. Le débat a donc bien plus porté sur Internet lui-même, que sur l'utilisation d'Internet pour la démocratie.
Gaël, un collègue de
Toulibre et moi-même sommes donc intervenus chacun une fois, pour donner une vision différente d'Internet. D'abord, pour essayer de faire réfléchir, en reprenant chacun des reproches faits à Internet, et en se demandant si on ne pouvait pas formuler ces mêmes reproches aux autres médias. Pour le coût par exemple, quelqu'un disait qu'il fallait débourser 1000 Euros pour un ordinateur et 30 Euros par mois pour un abonnement, ce qui est vrai. Mais pour accéder à l'information (ce qui est primordial dans une démocratie), il faut acheter des journaux, des livres, aller à la bibliothèque, ce qui a aussi un coût. Internet ne résout pas le problème du coût, mais ce n'est pas un problème spécifique à Internet. De la même façon, la pornographie est sur les étagères de toutes les librairies de toutes les villes, rien de bien spécifique à Internet. En ce qui concerne la quantité d'informations, même constat: si l'on voulait lire tous les journaux et tous les livres, ce serait impossible. De la même façon qu'il est impossible de lire tout ce qu'il y a sur Internet. Au niveau de la qualité, idem: la presse écrite n'est pas une garantie absolue de véracité des informations. Internet non plus. Seul le recoupage des sources, l'esprit critique et le discernement permettent au citoyen de s'informer correctement, et se faire un avis sur un sujet donné. En ce qui concerne l'anonymat sur Internet, il est bien difficile à obtenir, et la police et les services de la justice disposent de moyens pour remonter à l'émetteur d'un site illégal ou d'une communication illégale.
Le débat ne fût donc pas inintéressant: il a permis de mesurer à quel point l'image d'Internet auprès du grand public était déformée. Ils ne voient Internet qu'au travers du site commercial de leur quotidien et du portail de leur fournisseur d'accès. Ils voient donc Internet comme une machine commerciale, sans penser qu'il existe une myriade de blogs, de journaux et de textes mis en ligne par des particuliers souvent bénévoles et qu'Internet est donc un formidable outil pour la diffusion d'informations, de citoyen à citoyen, sans centralisation ou monopolisation par des entreprises. Partant de cette méconnaissance des possibilités du réseau des réseaux, le fond du débat (sur la démocratie électronique) n'a malheureusement pas pu être abordé.
Le débat fût aussi intéressant pour une autre raison: il a montré qu'avoir un débat utile et constructif sans avoir une connaissance préalable de ce qui est discuté est difficile, vraiment difficile. N'ayant pas pu écouter l'intervention initiale, je ne sais pas quelle en était la teneur, mais il me paraît clair qu'une intervention de présentation exhaustive et complète d'Internet, de ses mécanismes sous-jacents et de ses possibilités est nécessaire avant d'aborder un tel débat. Le débat sans information n'avance pas, chacun y va de ses affirmations à l'emporte-pièce, parfois justes, mais parfois sans fondements, et le débat ne progresse pas.
D'ailleurs, c'est également un avantage du débat par courrier électronique que j'ai mentionné pendant mon unique intervention de la soirée. Le fait que la communication soit asynchrone permet de répondre lorsque l'on en a le temps, en prenant le temps nécessaire pour construire une réponse complète, précise, étayée par des informations et des références.
Voilà pour ce premier café citoyen. Je vais regarder les prochains thèmes, pour voir ce qu'il s'y raconte ;-)
uClibc pour SOS, ça continue, et ça avance !
Le travail de portage de la uClibc sur SOS continue, et progresse à bonne allure. Dans mon
premier billet à ce sujet, j'indiquais que quelques appels systèmes fonctionnaient. Depuis, de nouvelles fonctionnalités ont été testées et débuggées: malloc() et free() fonctionnent, de même que mmap(), munmap() et mprotect(). Fork() et exec() fonctionnent également.
D'autre part,
David, mon collègue
KOS/
SOS a
tout récemment modifié SOS pour que le passage des arguments d'un programme et des variables d'environnement (les
argv et
envp) puissent être transmis lors d'un appel système
exec(). Ce WE, j'ai donc utilisé cette nouvelle fonctionnalité dans mon portage de la uClibc. Ce ne fût finalement pas trivial, car il a été nécessaire de modifier le format proposé initialement par David, pour mieux coller à ce qu'attendait la uClibc, comme j'en parle
dans ce mail. Le résultat, c'est qu'on peut maintenant passer des arguments aux programmes uClibc qui tournent dans SOS, et que ceux-ci peuvent accéder aux variables d'environnement. Magique ! ;-)
Le plus magique, c'est autre chose. C'est d'avoir commencé à faire fonctionner un compilateur C sous SOS. Alors évidemment, ce n'est pas
GCC, bien trop gros, mais
TinyCC, le mini-compilateur C de Fabrice Bellard (encore lui !).
Tiny peut-être (17 fichiers C pour 27.000 lignes de code), mais costaud quand même: il est possible de compiler le noyau Linux avec. Grâce à la uClibc, ce TinyCC compile pour SOS, et on peut exécuter "tcc -h" dans SOS pour avoir l'aide de TinyCC. Malheureusement, la compilation d'un fichier C proprement dite ne fonctionne pas encore, parce que SOS n'implémente pour l'instant pas l'appel
fcntl().
J'espère pouvoir faire ça prochainement, et donc poursuivre ces aventures. Si vous voulez tester tout ça, il y a
joli document qui explique pas à pas comment procéder. N'hésitez pas ;-)
Avec tout ça, le développement de la couche réseau de SOS n'a pas avancé, ce qui retarde d'autant plus le prochain article SOS dans GNU/Linux Magazine...
Paquet GCompris, mise à jour
Le paquet du logiciel éducatif libre
GCompris, déjà disponible pour Ubuntu Breezy, est maintenant également disponible pour Debian Stable. Pour cela, il a été nécessaire de recompiler
python-pysqlite2, également disponible dans mon dépôt de paquets Debian. Si vous êtes sous Debian Stable, une simple installation de GCompris (apt-get install gcompris) récupérera automagiquement ce paquet
python-pysqlite2 spécialement préparé.
D'autre part, la version de GCompris a été mise à jour, c'est maintenant une 7.3.1.
Paquets Debian et Ubuntu: quel bazar !
Aujourd'hui, j'ai mis à jour le paquet Ubuntu Breezy de
GCompris, puisqu'une nouvelle version, la 7.3, vient de sortir. Elle est donc disponible comme d'habitude dans mon dépôt de paquets.
Ensuite, j'ai essayé de me repencher sur la construction d'un dépôt de paquets un peu plus propres, c'est-à-dire avec une arborescence standard et des paquets signés. Et bien ce n'est vraiment, vraiment, vraiment pas gagné.
J'avais déjà regardé
debarchiver qui ne m'avait pas convaincu, je n'avais pas réussi à en tirer quelque chose. J'ai donc regardé du coté de
reprepro, mais celui-ci créé une arborescence avec
pool, comme dans les mirroirs Debian. Or, dans mon cas, je génère plusieurs paquets qui ont le même nom, le même numéro de version et la même architecture, mais pour des distributions différentes, puisque je fais des
backports. Donc une arborescence avec
pool ne convient pas.
Je suis donc revenu vers
debarchiver. À l'aide d'une
documentation en allemand, j'ai commencé à obtenir quelque chose, une arborescence qui ressemble à un truc utilisable. Seul hic: il refuse de m'ajouter le fichier
.orig.tar.gz, qui contient les sources originales du logiciel empaqueté. Et impossible de lui faire avaler.
Je m'en vais donc demander sur
#debian-fr, point de réponse. Je demande ensuite sur
#debian-devel, où on me conseille
reprepro. J'explique mon problème, et on m'explique que c'est mal d'avoir des paquets de même nom, architecture, version dans le même dépôt. Ça risque de confusionner
apt et
dpkg. Et donc qu'il faut que j'appelle mes paquets
blabla1.0+sarge,
blabla1.0+etch,
blabla1.0+sid,
blabla1.0+breezy. Vraiment pas pratique de devoir changer la version du paquet pour chaque
backport...
Alors après, on pourrait regarder du coté des alternatives à
debarchiver et
reprepro. Il en existe des dizaines, qui font toutes plus ou moins la même chose, mais pas vraiment. On sait pas ce qui marche, ce qui est documenté. C'est vraiment le bazar.
Au final, comme la dernière fois, j'ai laissé tomber. Donc j'ai toujours un dépôt avec une arborescence pas classique, et qui fait plein d'erreurs GPG quand on l'utilise. Pas cool ;-(
uClibc pour SOS... et contribuer au Libre
Hier, j'ai enfin pris le temps de finaliser le petit travail que j'avais commencé concernant le portage de la
uClibc sur le système d'exploitation
SOS.
uClibc est une bibliothèque standard C, c'est à dire implémentant les fonctions que tout programmeur C connaît en utilisant les
appels systèmes du système d'exploitation sous-jacent.
uClibc est une alternative plus légère à la
GNU Libc, couramment utilisée dans les distributions GNU/Linux.
uClibc est très utilisée dans le domaine de l'embarqué: tout en étant plus légère, elle offre quasiment toutes les fonctionnalités de la
GNU Libc qui sont indispensables pour faire tourner la plupart des programmes.
Actuellement, la
uClibc n'existe que pour le système Linux, et j'ai donc commencé un travail consistant à l'adapter pour
SOS. Cela permettrait d'exécuter des programmes C standards sous C, si l'on parvient à convertir suffisamment d'appels de la libc, de recompiler des programmes existants pour SOS.
Donc, hier,
j'ai annoncé sur la liste de discussion de
SOS, de la mise à disposition d'une première version de ce portage de la
uClibc sur SOS. Une
documentation est disponible, expliquant les différentes étapes permettant de compiler et de tester la
uClibc sur SOS. Il faut notamment récupérer
les sources,
les entêtes ainsi que
deux patches pour SOS. J'ai déjà pu tester les appels read(), write(), open(), close(), fopen(), fwrite(), fread() et printf(). Je commence à déboguer tout ce qui utilise brk(), donc tout ce qui alloue de la mémoire. J'espère qu'en mettent à disposition tout ça, quelques personnes s'intéresseront au sujet, et m'aideront à poursuivre le travail.
C'est un travail très intéressant, car c'est un peu la dernière brique pour un système d'exploitation. Mais une nouvelle fois, je me penche sur un projet intéressant, mais pas
utile. Tout au long des années, j'ai passé beaucoup de temps à écrire du code pour apprendre:
KOS,
SOS et maintenant ce petit portage. Mais ce code n'est pas réellement utilisé, par des vrais utilisateurs. J'aimerais maintenant participer et contribuer au développement d'un logiciel réellement utilisé, même si c'est seulement par un petit nombre de personnes. Avoir une communauté d'utilisateurs, c'est une motivation supplémentaire pour avancer, pour continuer.
Sachant que je programme couramment en C et Python, que je peux m'adapter à quasiment n'importe quel langage et n'importe quelle bibliothèque, avez-vous des idées de projets qui ont besoin d'aide ?
SOS, l'aventure continue
Après une très longue pause, l'aventure
SOS continue dans GNU/Linux Magazine France. Dans le
numéro 79 actuellement disponible en kiosque, il y a entre autres le 11ème volet de la série consacrée à SOS. Cet épisode de la série discute des périphériques de type caractère, de l'implémentation de pilotes pour ces périphériques et de leur intégration dans le système SOS et en particulier dans le VFS. Ceci est illustré par l'implémentation d'un pilote clavier, d'un pilote console et d'un pilote série, permettant de dialoguer avec SOS au travers de terminaux. Un petit
shell permet maintenant d'entrer quelques commandes de base, depuis le terminal clavier/écran ou depuis la ligne série.
Le magazine est feuilletable
ici, le code source est disponible sur le site de
SOS, et le texte de l'article y sera publié dans deux mois.
Toujours pour SOS, je m'amuse en ce moment avec ARP, IP, ICMP et UDP pour un prochain article qui concernera le réseau et l'implémentation d'une pile réseau minimaliste !
Pilotes binaires dans Linux: quel est le problème ?
Je reproduis ici une dépêche que j'ai soumis il y a quelques jours sur
LinuxFr, pour ceux qui ne lisent pas ce site. À l'origine de cette dépêche, il y a un texte d'Arjan van de Ven publié sur la liste du noyau Linux, sous forme de fiction, qui expose les problèmes posés par la prolifération des pilotes binaires propriétaires sous Linux. Ce problème étant important, j'ai réalisé une traduction de ce texte en français, avec quelques notes supplémentaires pour faciliter sa compréhension.
Introduction
Aujourd'hui, le nombre de périphériques nécessitant des pilotes binaires dans le noyau Linux s'accroît. Du côté des cartes graphiques, NVidia a toujours livré des pilotes binaires pour Linux. ATI, qui à l'origine fournissait des pilotes libres a rejoint NVidia et livre maintenant des pilotes binaires. De nombreux chipsets Wifi ne disposent pas non plus de pilotes libres, et les utilisateurs doivent passer par ndiswrapper, une couche de compatibilité permettant d'utiliser sous Linux des pilotes prévus pour Windows.
Ces pilotes binaires posent un certain nombre de problèmes, qui ont poussé Arjan van de Ven, développeur du noyau Linux, à publier une petite fiction intitulée « Linux dans un monde binaire, une hypothétique débâcle ». Cette petite fiction, dont une traduction rapide et non-officielle est proposée dans le corps de l'article, pourrait bien devenir réalité si les pilotes binaires venaient à se généraliser. Le traducteur a ajouté des notes de bas de page à l'histoire afin de faciliter sa compréhension par des non-spécialistes.
Pour résumer, voici quelques-uns des problèmes posés par les pilotes non-libres:
- Il est impossible de mettre à jour son noyau si le constructeur n'a pas sorti de nouvelle version de son pilote. Si le constructeur décide que le matériel ne vaut plus le coup d'être supporté, alors il n'y a tout simplement plus de pilote ;
- Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau (voir ce document de Greg Kroah-Hartman) ;
- Le fait d'utiliser des pilotes binaires implique d'avoir du code qui s'exécute en mode privilégié et qu'on ne peut pas auditer ou étudier. Il est alors impossible de savoir si ce code n'effectue rien de malveillant (l'histoire du rootkit Sony n'est pas si lointaine). Les bugs qu'il comporte peuvent entraîner des corruptions de données ou des plantages qui affecteront la totalité de la machine, et pas simplement un programme individuel. C'est d'ailleurs la raison pour laquelle les développeurs du noyau refusent aujourd'hui de corriger des « oops » signalés par un utilisateur lorsque des modules binaires sont chargés ;
- L'utilisation de pilotes binaires, ou de pilotes Windows au travers de ndiswrapper réduit la pression sur les constructeurs pour qu'ils mettent à disposition des pilotes libres ou les spécifications de leur matériel, et réduit la pression sur les développeurs de Logiciels Libres pour qu'ils développement des pilotes compatibles et libres.
- Les pilotes binaires livrés par les constructeurs le sont souvent pour la ou les quelques architectures les plus courantes, à savoir aujourd'hui x86 et x86_64. Les utilisateurs d'autres types d'ordinateurs sont laissés de coté, sans aucune solution.
En cette époque de fin d'année et d'achats pour Noël, choisissez donc bien votre matériel !
Linux dans un monde binaire, une hypothétique débâcle, par Arjan van de Ven
Que se passerait-il si demain les développeurs du noyau Linux acceptaient que les modules binaires sont une bonne chose et qu'ils sont essentiels au progrès de Linux ?
L'hypothèse principale sur laquelle est basé ce scénario ne va évidemment pas se produire, mais toutes les affirmations qui suivent sont basées sur des éléments tangibles.
Le
6 décembre 2005, les développeurs du noyau décident en masse que les modules binaires sont légaux [1] et qu'ils sont souhaitables pour le progrès de Linux. Au départ, le processus de développement du noyau Linux ne change pas vraiment, à part le fait que de nouveaux symboles sont exportés, et que EXPORT_SYMBOL_GPL [2] est supprimé.
Trois semaines plus tard, des distributions comme Red Hat Enterprise Linux et
SuSE? SLES commencent à inclure de nombreux modules binaires dans leurs CD d'installation. Debian s'y refuse et reste fidèle à sa cause, ainsi que les autres distributions ouvertes comme Fedora Core ou openSuSE.
Les distributions professionnelles n'incluent pas seulement les modules NVidia et ATI, mais incluent également les modules fakeraid et les différents pilotes wifi, winmodem, windsl et TCP-offloading. À l'inverse de NVidia et ATI, la plupart des constructeurs livrant des pilotes binaires ne proposent pas de couche d'abstraction [3] dont le code source est disponible: ils proposent seulement la version binaire finale.
Plusieurs constructeurs de matériel qui avaient jusqu'à présent été coopératifs avec la communauté du Logiciel Libre voient leurs concurrents livrer uniquement des pilotes binaires. Chez eux, la pression monte pour que la « propriété intellectuelle » soit sauvegardée. Certaines fonctionnalités de leurs matériels ne sont pas exploitées par les pilotes parce que leurs départements juridiques estiment que le risque de divulgation de leur « propriété intellectuelle » est beaucoup trop important. Par conséquent, ils considèrent que les pilotes binaires de leurs concurrents ont un avantage concurrentiel, ou au moins que leurs propres pilotes pourraient y gagner en étant fermés, parce qu'ils pourraient alors utiliser ces quelques fonctionnalités supplémentaires afin de dominer la compétition. [4] Le 1er février 2006, environ la moitié des constructeurs de matériel ont recentré leur travail sur les pilotes pour Linux autour de la création de valeur ajoutée dans des pilotes binaires qu'ils distribueront en plus des pilotes libres qui existent déjà. Certains constructeurs ont même stoppé le support des pilotes libres parce qu'ils n'ont pas assez de ressources pour maintenir deux versions en parallèle.
Premier mars. Toutes les nouvelles gammes de serveurs des plus grands constructeurs embarquent la nouvelle génération de matériel réseau et de stockage. Ce matériel est livré avec des pilotes binaires pour les deux dernières versions des distributions RHEL et SLES, et ces pilotes sont déjà intégrés dans les mises à jour de février de ces distributions. L'un des constructeurs livre son pilote sous la forme d'un binaire et d'une couche d'abstraction, les autres n'y attachent pas d'importance et livrent uniquement des pilotes binaires pour ces deux distributions. Deux des constructeurs de cartes réseau publient une mise à jour de leur pilote libre avec un support réduit des nouvelles cartes. Les autres constructeurs ne le font pas. Le matériel grand public n'est pas vraiment affecté: la plupart des chipsets des produits grand public sont basés sur le standard AHCI pour le stockage SATA, et conservent les fonctionnalités existantes dans les chipsets réseau.
Premier avril. Deux des constructeurs de chipsets ont mis à jour leurs puces pour inclure une nouvelle fonctionnalité audio intéressante qui permet une lecture améliorée des DVD, mais malheureusement, cela les oblige à dévier de l'interface audio "standard" i810. L'un des constructeurs publie un pilote binaire pour quelques distributions, les autres ne considèrent pas Linux intéressant pour le desktop et ne jugent pas utile de faire un pilote pour Linux pour le moment.
Premier mai. Tous les serveurs que l'on peut acheter demandent au moins un, mais souvent deux ou trois modules binaires pour fonctionner. Bien que certains de ces pilotes soient disponibles sous la forme d'un « blob binaire » et d'une couche d'abstraction, plusieurs sont seulement disponibles pour RHEL3, RHEL4 et SLES 9 et parfois pour la nouvelle distribution SLES10. Les utilisateurs de Linux sur ces serveurs n'ont d'autre choix que ces quatre noyaux, sans le moindre espoir de pouvoir exécuter un noyau « vanilla » [5] provenant de kernel.org. La communauté d'Ubuntu est sérieusement agacée, et essaie, avec un succès mitigé, d'inclure des pilotes libre sa distribution. Grâce au demi-succès de ce lobbying, environ 50% de ces serveurs pourront fonctionner avec le noyau Ubuntu.
Premier juin. Une énorme « flamewar&nsbp;», la quatrième sur ce sujet depuis janvier, a lieu sur la liste de diffusion du noyau Linux. Les utilisateurs et quelques développeurs demandent à ce que les développeurs du noyau officiel (kernel.org) adoptent l'ABI module [6] existante dans la distribution RHEL ou la distribution SLES. Après investigation, il apparaît que cela n'est pas possible, et le fil de discussion s'oriente vers un débat entre la définition d'une nouvelle ABI, ou le gel de l'ABI actuelle. De nombreux développeurs du noyau ont le sentiment que l'ABI existante ne convient pas pour devenir une ABI stable, et qu'une nouvelle ABI et API, conçue de manière à pouvoir rester stable plus facilement est la bonne solution. D'autres disent que cela prendra trop de temps et que cela ne servira à rien pendant les deux prochaines années, tant que RHEL et SLES n'auront pas adopté cette ABI. Ils demandent au moins un gel immédiat de l'ABI du noyau « vanilla » de façon à ce que la prochaine RHEL5 l'utilise et livre des pilotes écrits pour cette ABI. Les utilisateurs utilisent généralement la RHEL ou la SLES pour les serveurs de productions, ou des clones comme
CentOS? qui disposent d'une compatibilité binaire au niveau du noyau.
Premier juillet. Il devient de plus en plus difficile de faire fonctionner Linux sans modules binaires sur la plupart des nouveaux PCs grand public. Alors qu'un an plus tôt, les gens devaient pour cette raison abandonner l'accélération 3D, maintenant même la 2D ne fonctionne plus sans pilotes binaires, pas plus que le réseau (aussi bien filaire que sans fil) ou le son. Pour la moitié des machines, il n'y a pas de support Linux, tandis que 20% des machines utilisent des systèmes de traduction comme
NdisWrapper? pour faire fonctionner les pilotes son et réseau conçus pour Windows sous Linux. Le projet Debian, qui ne peut maintenant plus fonctionner sur la plupart des machines, perd une énorme quantité d'utilisateurs qui migrent vers Ubuntu, ou des hybrides Ubuntu-Debian. La liste Debian-legal et d'autres listes du projet sont monopolisées par ce sujet, déclenchant de vifs débats. La plupart des constructeurs qui livraient encore des pilotes libres plus à moins à jour ont tout simplement arrêté de le faire.
Quartorze juillet. Linus Torvalds déclare que l'ABI du noyau est maintenant stable, mais crée en même temps la branche 2.7 du noyau, et annonce que le noyau 2.8 aura une ABI différente. En pratique, seules les personnes qui ont encore accès à leurs vieilles machines peuvent désormais aider au développement du noyau 2.7, puisqu'aucun pilote fourni par les constructeurs, même ceux qui ont encore une couche d'abstraction ne peuvent suivre l'arbre de développement du noyau dans lequel les changements sont "trop rapides" pour être suivi par les constructeurs.
Vingt-et-un août. Une faille de sécurité sérieuse est découverte dans les noyaux de la série 2.6. Cette faille de sécurité s'avère être liée à un problème de conception d'une API importante du "sysfs" [7]. Corriger cette faille nécessiterait de casser l'ABI des modules, et donc en pratique tous les modules binaires disponibles, alors que la non-correction de cette faille laisserait ouvert un trou de sécurité dont l'exploitation permet de passer "root". Un correctif est rapidement publié sous la forme d'une option de configuration, mais les utilisateurs ayant besoin de pilotes binaires n'ont pas d'autre choix que de laisser leurs systèmes vulnérables [8]. Les trolls sur la liste de diffusion du noyau recommencent et Linus est accusé d'avoir commis une erreur en gelant l'ABI existante plutôt qu'en créant une nouvelle ABI destinée à être gelée. Le développement du 2.7 est quasiment à l'arrêt et un patch est proposé afin de disposer dans le 2.7 d'une ABI similaire à celle du 2.6, patch nécessitant de retirer de nombreuses améliorations importantes du sous-système de gestion de mémoire virtuelle ainsi que les patchs de gestion du temps réel d'Ingo [9].
Vingt-six août. Un exploit prêt à l'emploi pour le trou de sécurité arrive sur
BugTraq? et est identifié comme étant utilisé par différents rootkits. Un exploit PHP l'utilise pour passer de l'utilisateur httpd à root. Les utilisateurs mettent la pression sur les distributeurs de modules pour qu'ils mettent à jour ceux-ci avec la nouvelle ABI, et plusieurs d'entre eux le font dans les trois semaines qui suivent. Les autres, principalement les constructeurs fabriquant du matériel grand public, disent que la matériel en question n'est plus construit et qu'ils ne sont pas prêts à dépenser du temps ou de l'argent pour produire des pilotes compatibles avec la nouvelle ABI.
Maintenant, ce scénario peut vous sembler improbable. Et fort heureusement la principale hypothèse (l'évènement du 6 décembre) est effectivement très peu probable.
Malheureusement, plusieurs des autres faits ne sont pas si improbables. En fait, certains de ces faits sont même très probables, comme en témoignent les trolls sur la liste de diffusion du noyau concernant la rupture de l'API et l'ABI des modules, ou l'effet « ndiswrapper » sur les constructeurs qui disent maintenant « nous supportons Linux, parce que ndiswrapper permet d'utiliser notre pilote Windows ». J'espère que cela n'aura pas lieu. Une partie de cet espoir est un espoir silencieux, mais je crois que les avantages de la liberté sont suffisamment importants pour surmonter les forces contraires.
Notes du traducteur, pour faciliter la compréhension de l'histoire par des non-spécialistes
[1] Aujourd'hui, les modules binaires sont plus ou moins tolérés. Il n'y a pas réellement de position officielle à ce sujet, et les débats sont souvent vifs sur la liste de développement du noyau. Tout le débat repose sur l'interprétation de la notion de « travail dérivé », tel que défini par la licence GPL.
[2] Dans le noyau Linux, pour que des modules externes puissent appeler des fonctions du coeur du noyau, il faut que ces fonctions soient « exportées ». Pour cela, les développeurs du noyau peuvent utiliser les instruction EXPORT_SYMBOL() ou EXPORT_SYMBOL_GPL(). EXPORT_SYMBOL() rend la fonction utilisable dans les modules libres et propriétaires, tandis que, en principe, EXPORT_SYMBOL_GPL() rend la fonction utilisable uniquement dans les modules sous licence GPL. Cette différence n'a pas de valeur juridique, mais elle est une indication du fait que les développeurs considèrent que l'utilisation de telle ou telle fonction du noyau constitue un travail dérivé de celui-ci.
[3] NVidia livre ses pilotes binaires sous une forme un peu particulière. Ils sont constitués d'une partie binaire, le coeur du pilote, et d'une partie dont les sources sont disponibles, qui sert de couche d'abstraction entre le noyau et la partie binaire. En anglais, la couche d'abstraction est souvent appelée « glue layer ». Ce fonctionnement permet de recompiler son noyau et la glue, tout en conservant la même partie binaire. Sans ce mécanisme, il faudrait à chaque fois qu'un nouveau noyau sort où que l'on recompile son noyau, que NVidia sorte une nouvelle version de ses pilotes.
[4] À ce sujet, ATI livrait auparavant des pilotes libres et les spécifications de leur matériel. Depuis que NVidia met à disposition des pilotes binaires, ATI fait de même.
[5] Le noyau dit « vanilla » est le noyau officiel disponible sur kernel.org. Il est dit « vanilla » par opposition aux noyaux fournis par les distributions (Fedora, Debian, Ubuntu, Mandriva, etc.) qui incluent des patches qui les font dériver de la version officielle.
[6] ABI désigne l'« Application Binary Interface », c'est-à-dire l'interface binaire entre deux sous-systèmes. Un changement d'ABI a lieu lorsque des structures de données changent, ou lorsque des prototypes de fonction changent. Un changement d'ABI nécessite une recompilation, ce qui pose problème aux constructeurs souhaitant livrer des modules propriétaires. Ils font donc pression pour disposer d'une ABI stable pour programmer des modules noyau. Pourtant, c'est une aberration technique, voir ce document de Greg Kroah-Hartman.
[7] « sysfs » est un des sous-systèmes du noyau Linux 2.6 permettant à des applications d'interagir avec les pilotes de périphériques en mode noyau.
[8] En effet, la correction de la faille de sécurité entraînant un changement d'ABI, il n'est plus possible d'utiliser les pilotes binaires: il faut attendre que le constructeur publie une nouvelle version de son pilote. Aujourd'hui, les utilisateurs de routeurs personnels Linksys WRT54 ne peuvent pas migrer leur petite machine vers le noyau 2.6: ils sont bloqués, car le pilote Wifi Broadcom 43xx n'est disponible qu'en module binaire pour le noyau 2.4. Heureusement deux équipes de fous très compétentes se sont lancées dans la rétro-ingénierie du pilote binaire avec des résultats intéressants, mais est-ce véritablement une solution viable ?
[9] En référence à Ingo Molnar qui travaille sur des patches pour le noyau Linux améliorant la latence de celui-ci, le rendant plus adapté à des applications audio très sensibles aux temps de réponse.
Un grand merci à Gaël Utard et Colin Leroy pour la relecture et les corrections.
KOS, nostalgie ...
Il y a 7 ans quasiment jour pour jour, j'envoyais le mail suivant sur le newsgroup
fr.comp.sys.pc. Cela faisait alors 6 mois que j'avais commencé à réfléchir avec
Dimitri Ara au développement d'un petit système d'exploitation. Ce mail avait pour objectif de trouver de nouveaux développeurs. On y reconnaît le style « je suis jeune, je n'y connais rien, mais je veux coder mon OS à moi parce que je suis un vrai » ;-)
Le voici, pour l'histoire, notez la jolie signature de plus de 10-15 lignes. Il est aussi disponible sur
Google Groups, c'est d'ailleurs là que je l'ai trouvé.
From: Petazzoni <peta@club-internet.fr>
Subject: Developpement d'un OS...
Date: 1998/11/23
Message-ID: <3659BCF5.692399EA@club-internet.fr>#1/1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
X-Trace: front7.grolier.fr 911850691 29434 194.158.110.231 (23 Nov 1998 19:51:31 GMT)
Organization: Club-Internet (France)
Mime-Version: 1.0
Reply-To: peta@club-internet.fr
NNTP-Posting-Date: 23 Nov 1998 19:51:31 GMT
Newsgroups: fr.comp.sys.pc
Salut a tous,
nous sommes de jeunes de 15 et 16 ans désirant tenter la programmation
d'un système d'exploitation. Cependant, nous recherchons des partenaires
pour ce développement. Nous sommes ouverts à toutes les
propositions.....
Nous savons que ce projet est ambitieux, mais pourquoi pas ?
Voilà merci
--
+------------------------------------------------+
| PETAZZONI |
+-----------------------+------------------------+
| Thomas | Maxime |
+------------------------------------------------+
| E-mail : peta@club-internet.fr |
| ICQ : 23310800 |
+--------------+----------------+----------------+
| | | |
| KKK KKK | OOOO | SSS S |
| K K | O O | S SS |
| K K | O O | S S |
| K K | O O | SS |
| KKK | O O | SS |
| K K | O O | S |
| K K | O O | S S |
| K K | O O | SS S |
| KKK KKKK | OOOO | S SSS |
+--------------+----------------+----------------+
Nostalgie ...
MyPixmania 1.0.4
Pffiou, je n'ai rien écrit depuis le 1er novembre. Pourtant, ce n'est pas les choses à dire qui manquent. En voici une: Christophe Lucas et moi-même avons sorti la version 1.0.4 de MyPixmania, cet ensemble de scripts Python qui permet de faciliter l'utilisation du site MyPixmania.com, et en particulier l'envoi de photographies à faire développer. Depuis la précédente version, beaucoup de choses ont changé:
- il y a maintenant une interface texte (mypixmania) et une interface graphique (gmypixmania) ;
- le coeur du logiciel, qui gère l'interaction avec le site Web, est séparé des interfaces, et la bibliothèque de base propose une API documentée, donc utilisable pour d'autres choses ;
- il est maintenant possible de supprimer des albums et de récupérer les photos d'un album précédemment uploadé ;
- il y a une page de manuel pour l'interface texte
- il y a une jolie page Web ;-)
- il y a des paquets pour Debian Sarge, Etch et Sid, pour Ubuntu Hoary et Breezy et pour Mandriva 2006.
Pour tous les détails, rendez-vous justement sur la
jolie page Web !
Biloba 0.4
Il y a quelques jours,
Colin a annoncé la sortie de Biloba 0.4, ce petit jeu de plateau fort sympathique dont j'avais déjà parlé. Comme il se doit, j'ai mis à jour les paquets Debian Sarge, Etch, Sid et Ubuntu Hoary. Ils sont disponibles, comme d'habitude dans mon
dépôt Debian. Il n'y a pas encore de paquets pour Ubuntu Breezy, car le script pour créer une
chroot Pbuilder pour cette distribution n'est pas encore disponible.
Petite astuce pour finir. Si vous utilisez
Pbuilder avec des dépôts qui n'ont pas encore mis en place le système de signature GPG désormais activé par défaut dans
Sid, le plus simple est d'éditer le fichier
/etc/apt/apt.conf de la
chroot, et d'y ajouter la ligne:
APT::Get::AllowUnauthenticated 1 ;
Et voilà ;-)
Actualité du noyau #2
Le résumé de l'actualité du noyau de la semaine dernière semblant avoir été apprécié par quelques lecteurs, j'ai essayé de faire de même pour cette semaine. Malheureusement, je me rends compte que je n'aurai certainement pas le temps de continuer toutes les semaines. Peut-être faudrait-il monter un site communautaire francophone où plusieurs rédacteurs pourraient se partager la tâche. D'un autre coté, est-il vraiment nécessaire d'avoir quelque chose de plus que
LWN ou
KernelTrap ?
Cette semaine:
- Ram Pai a posté un jeu de patches important implémentant les VFS Shared subtrees. Une des parties du patch est une documentation, expliquant de quoi il s'agit. Cette fonctionnalité était en discussion depuis plusieurs mois, puisque déjà en janvier 2005, Al Viro avait résumé la sémantique des différentes opérations par rapport aux shared subtrees.
Depuis le noyau 2.5, il est possible sous Linux de mettre en place des
per-process namespace, c'est-à-dire d'offrir aux
process des visions différentes de l'espace de nommage (l'arborescence des fichiers). Comme l'explique
Jonathan Corbet, le concept vient du système d'exploitation
Plan 9 (voir également
ce papier).
Par ailleurs, depuis les noyaux 2.4, on peut utiliser l'option --bind de la commande mount qui permet de remonter une partie de l'arborescence à un autre endroit de l'arborescence.
Néanmoins, comme l'explique Ram Pai,
les montages «bind» et les espace de nommage sont statiques par nature. Ils créent un snapshot des points de montage courants. Cependant, tous les nouveaux montages et démontages réalisés dans le point de montage originel ne seront pas répercutés dans le nouveau point de montage. Les «shared subtrees» rendent les montages «bind» et les espaces de nommage dynamique par nature. Les montages et les démontages réalisés sous n'importe lequel des réplicats sont répercutés dans les autres. Le développeur annonce dans son courrier électronique que cette fonctionnalité est attendue par des projets tels que
FUSE (systèmes de fichiers en espace utilisateur),
SeLinux (Security-Enhanced Linux, développé par la NSA), MVFS (multiversions file system, un système de fichiers développé par IBM, et visiblement utilisé par le système de gestion de version propriétaire ClearCase) et
autofs (mécanisme permettant le montage automatique).
Ram Pai distingue 4 types de montages, pour lesquels il donne des exemples dans sa documentation:
- les montages partagés ou shared mounts, qui propagent les nouveaux montages et démontages dans tous les réplicats ;
- les montages esclaves ou slave mounts, qui fonctionnent comme les montages partagés, sauf que les montages/démontages réalisés au sein du montage esclave ne sont pas propagés au montage parent ;
- les montages privés ou private mounts sont les montages classiques que nous connaissons. Il n'y a pas de propagation des nouveaux montages et démontages dans les réplicats ;
- les montages inclonables ou unclonable mounts, qui sont des points de montage qu'on ne peut répliquer.
La documentation donne beaucoup d'autres détails: elle précise la sémantique de toutes les opérations par rapport aux différents types de montage, elle donne plusieurs cas d'utilisation, et propose même un Quiz pour permettre au lecteur de tester sa compréhension de la chose ;-)
Le patch lui-même, découpé en 10 parties, touche bien évidemment le coeur du VFS, en particulier fs/namespace.c et ajoute un nouveau fichier fs/pnode.c.
- La semaine dernière, nous évoquions le processus de développement des versions 2.6.x.y, mené par Chris Wright. Celui-ci avait alors proposé une liste de patches pour la version 2.6.13.2, et avait invité les autres développeurs à lui soumettre des patches avant « Sat Sep 17 01:00 2005 UTC ». Et effectivement, le 17 septembre à 1h20 UTC, il a livré cette version 2.6.13.2, contenant 8 correctifs, dont aucun ne concerne un problème de sécurité. Le processus de construction de ces versions stables semble être bien rodé.
- Le déménagement de master.kernel.org à Open Source Lab de l'Université de l'Oregon a été annoncé et réalisé par avion privé. Visiblement, ce déménagement a un peu affecté la sortie de la version 2.6.14-rc2: les arbres git ont mis plusieurs heures à se répliquer, et les tarballs et patchs officiels ont mis plusieurs jours après l'annonce de la sortie de la version par Linus Torvalds pour être disponibles. KernelTrap parle également de ce déménagement.
- Hans Reiser, récemment interviewé sur KernelTrap a une nouvelle fois demandé l'inclusion de ReiserFS 4 dans le noyau. Cette demande a déjà été effectuée à plusieurs reprises, mais à chaque fois les développeurs du noyau n'étaient pas prêts à intégrer ce nouveau système de fichiers. Au début, c'est la fonctionnalité d'avoir des fichiers se comportant comme des répertoires afin d'accéder à des méta-données qui a posé problème, car cela semblait mal s'accorder avec la sémantique de certaines opérations sur les fichiers. D'autre part, ReiserFS dispose d'un propre mécanisme de plugin que les développeurs du noyau aimeraient mieux voir intégré de manière générique au VFS. Mais dans ce nouveau fil de discussion consacré à ReiserFS, c'est plutôt le style de code qui a été discuté. Comme dans toutes les discussions avec Hans Reiser, le débat a été très houleux, mélangeant des attaques personnelles et quelques arguments techniques semblant parfois assez faibles. Extraits choisis:
- Christoph Hellwig, chargé de la relecture du code des systèmes de fichiers: « additinoal comment is that the code is very messy, very different from normal kernel style, full of indirections and thus hard to read. », Hans Reiser répond: « Most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code. So yes, it is different. »
- Denis Vlasenko: « This is it. I do not say "accept reiser4 NOW", I am saying "give Hans good code review". », Christoph Hellwig répond: « After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. ».
- Hans Reiser répondant à Christoph Hellwig: « Hellwig, people who write slow file systems should not lecture their measurably superiors on how to code. [...] If you were as well suited to doing code reviews as I am, you would have written a faster file system yourself. Anybody can find things to fix in someone else's code, and it can go on for years if they want it to. I could get what you do from hiring a college junior, and if it was a good university I'd probably learn more from that junior in college than from you. We are doing work, and you are getting in the way. Nobody who wants reiser4 views your contributions as the least bit positive. ». Et également « Reiser4? works just fine without Christoph. Users are happy with it. None of them have asked for his help. I don't consider Christoph to be qualified to work on our filesystem. I would not hire him if he applied - he is not capable of innovative work. »
Bref, on voit bien que les attaques personnelles sont légion, et que la personnalité d'Hans Reiser n'arrange pas les choses. Certains ont même suggéré qu'une autre personne de la société Namesys (gérée par Hans Reiser) s'occupe de dialoguer avec les développeurs du noyau en ce qui concerne l'incusion de ReiserFS. KernelTrap
propose également un résumé de la situation.
- Suite à l'article de la semaine passée concernant l'utilisation d'outils d'analyse statique de code, Christophe Lucas m'a fait remarquer que sparse et le standford checker étaient utilisés par de nombreuses personnes du projet Kernel Janitors, dont l'objectif est « go through the linux kernel sources, doing code reviews, fixing up unmaintained code and doing other cleanups and API conversion. It is a good start to kernel hacking. ». Sur le même sujet, David Mentré m'a indiqué l'adresse d'une liste d'outils de vérification formelle de code, qui comprend une section consacrée aux outils aidant à la vérification de « programmes réels ». Il y mentionne Why, CIL, Splint, CQual, CCured, Chic, Smatch, Sparse et Focal.
- Soeren Sandman a annoncé Sysprof 1.0, « a sampling, systemwide Linux profiler ». Sysprof prend la forme d'une module noyau, qui permet de profiler tous les processus en exécution. Une interface graphique simple permet de visualiser le temps passé dans chaque branche du graphe d'appel. Un des points mis en avant par le développeur est sa simplicité d'utilisation.
Plusieurs développeurs se sont montrés sceptiques, indiquant que cela ressemblait ni plus ni moins à ce que fait déjà
O'Profile. Pour défendre son outil, Soeren a
avancé plusieurs arguments: OProfile ne fonctionne pas en SMP, OProfile ne peut pas extraire de graphe d'appel sans recompiler le noyau, et OProfile dispose d'une interface graphique difficile à comprendre. Il a donc de nouveau mis en avant la simplicité de mise en oeuvre de son outil, mais ses arguments face à OProfile semblent un peu léger: il aurait sans doute été plus simple et plus constructif de contribuer à cet outil existant.
Les autres développeurs ont persisté à demander pourquoi avoir réimplémenté OProfile, et Soeren
a indiqué que le module noyau ne représentait que 296 lignes, et que ce n'était pas vraiment ce qui l'intéressait, mais plutôt le code d'analyse et l'interface graphique.
Certains ont donc suggéré de brancher l'interface graphique et le code d'analyse de
sysprof sur le module noyau
OProfile. Une discussion
a alors été démarrée sur la liste d'OProfile.
- Au cours de mes lectures de la LKML, je suis tombé sur un bug sympathique. Des utilisateurs de systèmes bi-Opteron ont reporté avoir des problèmes de Segmentation fault aléatoires, le genre de bug pas très sympathique. Au départ, c'est la fonctionnalité de « randomization » de l'espace virtuel qui a été incrimée, puisque le problème ne se produisait plus lorsque cette fonctionnalité était désactivée à l'aide de echo 0 > /proc/sys/kernel/randomize_va_space. Plusieurs utilisateurs ont indiqué que cela corrigeait le problème, et les recherches se sont orientées dans cette direction. Toutefois, un peu plus tard, un utilisateur a reporté avoir réussi à reproduire le problème, même avec la « randomization » désactivée. Un membre de l'équipe de PaX a alors résumé les diverses hypothèses plausibles. Et finalement, Linus Torvalds, qui n'était jamais intervenu sur ce bug, est arrivé avec un patch qui désactive une fonctionnalité des processeurs Opteron, car celle-ci est buggée dans les systèmes multi-processeurs ("TLB Flush Filter causes coherency problem in multiprocessor systems"). J'ai trouvé particulièrement intéressant de suivre le cheminement allant de la constatation du bug jusqu'à la découverte de l'origine du problème.
- Con Kolivas a annoncé plusieurs versions de son patch swap prefetch, la dernière annoncée étant la version 11. Ce patch implémente le swap prefetching, c'est à dire le fait d'aller chercher des données dans le swap avant qu'elles ne soient réellement nécessaires. Ce prefetching a lieu lorsque le sous-système de gestion de mémoire virtuelle ne fait pas grand chose et que de la mémoire physique est disponible. Voici un petit descriptif du fonctionnement de la bête, traduit du courrier électronique de Con Kolivas:
Le patch permet de maintenir une liste des pages swappées, dans une liste ordonnée de la plus récemment utilisée à la moins récemment utilisée et dans un
radix tree, une structure de donnée que nous avons
évoqué dans le compte-rendu d'une conférence du Linux Symposium 2005 concernant les performances du
page cache. En plus de ceci, le patch créé un thread noyau de faible priorité qui sera chargé d'effectuer le préchargement.
Une fois que des pages ont été ajoutés à la liste des pages swappées, un timer est démarré, testant toutes les 5 secondes si certaines conditions sont réunies pour permettre le préchargement de pages swappées. Les conditions sont relativement complexes (pas de déplacement de pages vers ou depuis le swap en cours, peu de mémoire « sale », une quantité suffisante de mémoire libre disponible, etc.), mais lorsqu'elles sont réunies, le thread va récupérer 128 Kb de données du swap toutes les secnodes, jusqu'à ce que les conditions précédemment listées ne soient plus valides. Les pages sont copiées en mémoire, mais sont conservées sur le disque, de manière à ce qu'elles puissent être libérées sans réaliser d'entrées-sorties si cela est nécessaire.
D'après Con Kolivas, ce patch améliore nettement le temps de chargement des applications qui ont été complètement swappées.
- Junio Hamano, le nouveau mainteneur de Git, a annoncé la sortie de la version 0.99.7. Certaines commandes ont été renommées pour plus de cohérence, et une commande git merge a été ajoutée, permettant d'utiliser d'autres algorithmes de merge que le classique three-way merge.
« Not a whole lot o' excitement, ye scurvy dogs, but it has t' ALSA, LSM, audit and watchdog merges that be missed from -rc1, and a merge series with Andrew. But on t' whole pretty reasonable - you can see t' details in the shortlog (appended). »
Comme prévu donc, pas de nouvelles fonctionnalités, seulement des correctifs. Comme je le disais plus haut, le déplacement de master.kernel.org a entraîné un délai assez important entre le moment où Linus a annoncé la sortie de cette version, le moment où elle était disponible via GIT et le moment où elle était disponible via kernel.org. Pour ma part, ce nouveau noyau tourne sur ma machine depuis 4 jours, sans que j'ai noté de problèmes particuliers.
- Andrew Morton a annoncé 2.6.14-rc2-mm1. Cette branche -mm est en quelque sort le bac à sable des nouveaux patches: Andrew Morton y intègre quasiment tout ce qui passe sur la liste, ce qui permet de tester de manière un peu plus intensive de nouvelles fonctionnalités ou de nouveaux correctifs. Une fois que les patches sont intégrés à la version officielle, Andrew les retire de sa branche -mm et sort une nouvelle version basée sur la nouvelle version officielle du noyau. Dans un prochain billet, j'évoquerai Quilt, l'outil développé à l'origine par Andrew Morton pour gérer des patches.
- Un certain John Richard Moser a proposé sur la liste une idée d'implémentation pour une fonctionnalité de « Hot-patching », qui permettrait de patcher un noyau binaire sans redémarrer la machine, en insérant des modules noyau contenant du code noyau qui ira remplacer le code noyau en exécution. Cette fonctionnalité avait déjà été discutée et de nombreux commentaires avaient été faits. La discution sur cette nouvelle proposition n'a donc pas été très loin. Un développeur a fait remarquer que ce n'est pas simple, puisque si les correctifs binaires introduisent un nouveau champ dans une structure ou de nouveaux bits d'état, alors ça ne pourra pas fonctionner.
- Thomas Gleixner a annoncé un patch contenant un nouveau sous-système pour la gestion du temps. N'étant pas un spécialiste du domaine de la gestion du temps, je n'apporterai pas plus que l'excellent descriptif réalisé dans son courrier électronique, ni à l'article de Jonathan Corbet publié sur LWN, dont je vous recommande la lecture. Le lecteur intéressé par le sujet pourra également lire le papier « We are not getting any younger. A new approach to time and timers » publié au Linux Symposium 2005 et disponible page 227 du premier volume des proceedings.
- Enfin, pour terminer, je voulais parler d'un petit outil fort pratique: Ketchup. Développé par Matt Mackall, également développeur de Mercurial, il s'agit d'un outil permettant de récupérer ou de mettre à jour ses sources du noyau Linux. Une page du Wiki donne quelques exemples d'utilisation. En se plaçant dans votre arbre des sources du noyau, vous pourrez le mettre à jour vers n'importe quelle version, que ce soit la dernière version officielle ou une branche -mm, -rc ou autre. Ainsi, si vous êtes en 2.6.10, plutôt que de retélécharger complètement une version 2.6.13.2, il suffit de faire ketchup 2.6-tip, et ketchup va récupérer et appliquer automatiquement les patches 2.6.10 -> 2.6.11, 2.6.11 -> 2.6.12, 2.6.12 -> 2.6.13 et 2.6.13 -> 2.6.13.2. Simple, mais fort sympathique !
La suite au prochain numéro !
Papiers, enregistrements et slides du thème OS
Plus de deux mois après la fin des
Rencontres Mondiales du Logiciel Libre 2005,
Ludovic et moi avons enfin terminé de récupérer les papiers et les slides du thème OS et de mettre en ligne les enregistrements des conférences. L'ensemble est disponible à l'adresse
http://medias.2005.rencontresmondiales.org/topics/os/.
Bonne lecture... ou bonne écoute !
L'actualité du noyau
Depuis le début de la semaine, j'essaie de suivre le développement du noyau Linux en lisant quelques messages de la
Linux Kernel Mailing List au travers d'un
newsgroup. Ça faisait plusieurs années que je n'avais pas utilisé de
newsgroups, les délaissant au profit des listes de diffusion. Mais finalement, pour une liste avec un traffic comme la
LKML (plusieurs centaines de courriers électroniques par jour), les newsgroups sont une bonne idée, car ils évitent de surcharger une boîte aux lettres vers laquelle affluent déjà de nombreux courriers électroniques.
Durant ces lectures, j'ai pu y découvrir plusieurs choses intéressantes:
- Un étudiant a posté le résultat de son travail réalisé dans le cadre d'une EndThesis à l'Université de Niederrhein. Il s'agit d'un framework permettant d'automatiser la création du fichier .config (contenant la configuration du noyau à compiler). Pour cela, il se base sur la configuration actuelle de la machine. Le README explique relativement bien le fonctionnement de la chose: un fichier XML définit des règles pour les différentes options du noyau. Pour déterminer si une option doit être activée ou pas, il fait appel à un script ou à un binaire externe qui répond simplement "y", "n" ou "m", en fonction des besoins. En utilisant les informations de /proc/cpuinfo, on peut déterminer automatiquement pour quel CPU le noyau doit être compilé, avec le résultat de lspci, on peut déterminer les périphériques présents sur la machine et activer les pilotes correspondants.
Dans tous les cas, même pour les power-users, ce genre d'automatisation peut-être assez pratique. Combien de fois n'éprouve-t-on pas des difficultés à trouver quel module du noyau correspond à tel ou tel périphérique. Une opération qui peut très bien être automatisée.
- Peter T Breuer a publié un outil appelé tout simplement "c". Il s'agit d'un analyseur statique de code pour le noyau Linux qui permet de détecter des choses intéressantes comme les sleep alors qu'un spinlock est pris, les prises doubles de spinlocks ou les utilisations de mémoire après libération par kfree. En particulier, sa demande concernait les fichiers .o.cmd: il souhaitait que d'autres développeurs lui envoient de tels fichiers, car ils contiennent la ligne de compilation utilisée pour compiler le fichier .o correspondant. Ainsi, Peter pourrait tester son outil sur une plus vaste partie du noyau. D'autres développeurs noyau lui ont rappelé l'existence de la cible allmodconfig du Makefile du noyau, qui active la compilation de tous les modules.
À noter que Linus développe déjà un outil d'analyse statique du code appelé
Sparse et qui permet de vérifier un certain nombre de choses dans les sources du noyau. Ces outils d'analyse statique semblent décidement être à la mode, puisque Rusty Russell en a parlé à l'Ottawa Linux Symposium, et Dave Jones également dans sa
Keynote.
Je ne suis absolument pas un expert dans le domaine de la compilation, mais je pense que disposer d'un analyseur statique de code qui comprend correctement toute la grammaire du C, avec toutes les extensions de Gcc ne doit pas être évident. Du coup, je trouve dommage d'avoir ces duplications d'efforts: il y a
sparse, il y a
c, mais également
ncc, un compilateur destiné à générer des informations pour réaliser des graphes d'appel. Ne serait-il pas possible d'avoir un seul analyseur statique de code qui sache parfaitement parser le langage C, auquel on puisse « brancher » différents outils de vérification. Ainsi, la partie « analyse de la grammaire C » serait factorisée et donc serait sans doute de meilleure qualité, et cela faciliterait le développement de nouveaux types de vérification. Pour donner une illustration de la difficulté de bien analyser un source en C, j'ai découvert un bug dans
ncc qui le faisait purement et simplement segfaulter avec un bout d'assembleur... alors que
ncc passe sans problème sur le noyau Linux. Avoir un analyseur qui marche vraiment dans tous les cas est donc difficile, alors autant regrouper les efforts.
- L'éternel troll sur devfs n'en finit plus. Pour rappel, ce système de fichiers développé par Richard Gooch et intégré dans la branche de développement 2.3.x permettait d'avoir un "/dev/" dynamique. Au lieu d'avoir des noeuds stockés en dur, les périphériques apparaissent automagiquement dans "/dev/". Néanmoins, ce système de fichiers n'a jamais donné entière satisfaction, et depuis l'intégration de son remplaçant, udev, il vise à être supprimé. Greg KH avait déjà proposé sa suppression pour le 2.6.13, qui a été finalement refusée au profit d'une désactivation. Greg KH a donc soumis de nouveau des patches pour le supprimer dans le 2.6.14, soumission qui a relancé le vif débat sur le sujet. Greg KH, principal développeur d'udev soutient que sa solution remplace avantageusement devfs, en particulier parce qu'une grosse partie de ce que devfs faisait en espace noyau est maintenant fait en espace utilisateur par udev, grâce aux évènements envoyés par hotplug. Toutefois, certains pensent qu'il est encore trop tôt pour retirer devfs, par exemple parce que l'installeur de Debian est fortement dépendant de devfs. Pour clarifier la discussion, Mike Bell a publié une FAQ udev vs devfs qui liste les avantages et les inconvénients des différentes solutions. L'affaire devfs n'est donc pas encore close...
- Quelques jours plus tard, le même Greg KH annonçait la version 070 de udev et surtout un changement de mainteneur. C'est donc maintenant Kay Sievers qui est responsable d'udev.
- En début de semaine, Linus Torvalds a annoncé la sortie du 2.6.14-rc1. Comme son nom l'indique, c'est la première release candidate depuis la sortie du 2.6.13. En application du nouveau modèle de développement discuté par les développeurs noyau à Ottawa durant le Linux Kernel Summit, cette première release candidate, publiée 2 semaines après la sortie du 2.6.13, clôture la période durant laquelle les patches intégrant de nouvelles fonctionnalités sont acceptés. À partir de maintenant, et jusqu'à la sortie du 2.6.14, seuls des patches corrigeant des bugs seront acceptés. Ce nouveau modèle de développement est censé permettre aux développeurs de se focaliser pendant un moment sur la correction de bugs plus que sur le développement de nouvelles fonctionnalités. Linus Torvalds a d'ailleurs appelé à jouer le jeu, en intitulant son mail « Read my lips: no more merges », et en rappelant « Be nice now, and follow the rules: put away the new toys, and instead work on making sure the stuff that got merged is all solid. Ok? »
En même temps que j'ai décidé d'essayer de suivre un peu plus l'actualité du noyau, j'ai décidé d'essayer de tester les versions release candidate de ce dernier. J'ai donc téléchargé le patch de cette 2.6.14-rc1, qui s'applique sur le noyau 2.6.13 lui-même. En effet, bien qu'un noyau 2.6.13.1 soit sorti avant le 2.6.14-rc1, le développement du noyau se poursuit à partir du 2.6.13 officiel: les 2.6.x.y ne sont que des versions stabilisées du noyau 2.6.x, maintenues dans une branche séparée.
La configuration de ce
2.6.14-rc1 s'est déroulée très rapidement et sans encombre grâce à
make oldconfig. Avec cette cible, seules sont posées des questions concernant les options de compilation ayant changé. La compilation s'est bien déroulée et le tout fonctionne très bien, aucun plantage, et j'utilise donc ce noyau de manière courante. D'autre part, j'ai mis en place le système
KLive proposé par
Andrea Arcangeli. Il s'agit d'un petit script qui tourne en tâche de fond, et qui va régulièrement informer un serveur de la version du noyau utilisée, de l'
uptime, et de quelques informations sur la configuration de la machine. L'objectif de ce projet est de répondre à une question que se posait les développeurs noyau à Ottawa cet été: combien de personnes testent les noyaux
-rc. J'ajoute donc ma toute petite pierre à cet édifice en signalant que j'utilise le
2.6.14-rc1 avec succès. Vous pouvez faire de même ;-)
- J'ai été assez impressionné par la mise en application de la fonctionnalité bisect de git, dont j'avais déjà parlé. Un utilisateur a reporté une régression intervenue entre le 2.6.12.6 et le 2.6.13-rc1 (et toujours visible dans 2.6.14-rc1). Finalement, l'utilisateur a décidé d'utiliser git bisect pour déterminer précisement le patch ayant introduit la régression. Au bout de 13 compilations de noyau et reboots, le patch incrimé a été trouvé. Cela peut paraître beaucoup, mais comme le souligne Torvalds, 13 recompilations sont finalement assez peu si l'on considère le fait qu'il y eu 2069 patches intégrés entre le 2.6.12.6 et le 2.6.13-rc1. Git bisect semble donc définitivement être un outil très pratique.
- Dès la sortie du 2.6.13.1, le travail sur la 2.6.13.2 a commencé, mené par Chris Wright. Rappelons que l'objectif de la branche 2.6.x.y est de proposer une version un peu plus stable que la version 2.6.x de base, grâce à l'intégration de correctifs de bugs et de sécurité. Cette branche a été appelée sucker tree par Linus Torvalds lors de sa création, en raison du caractère ingrat du travail consistant à la maintenir.
Le processus pour la sortie d'un 2.6.x.y semble être le suivant: Chris Wright
poste une liste de patches (ici au nombre de 11), en demandant l'avis des autres développeurs noyau, et en leur demandant de signaler d'autres patches qui auraient vocation à être intégrés. Chris précise également à la fin de son courrier :
« Responses should be made by Sat Sep 17 01:00 2005 UTC. Anything received after that time, might be too late.». Il semble qu'il souhaite maintenir une certaine fréquence dans la sortie des versions 2.6.x.y et impose donc des dates limites. Tout ce qui n'est pas intégré dans 2.6.x.y pourra l'être dans 2.6.x.(y+1) de toute façon. À partir de ce post de Chris, vous pouvez suivre l'organisation et le déroulement de la sortie de ces versions stabilisées du noyau.
Le read-ahead est un mécanisme qui permet d'améliorer les performances en lecture depuis les périphériques de stockage. Il part du principe que le plus souvent, lorsqu'une application lit une petite quantité de données depuis un disque dur, il y a de fortes chances pour qu'elle accède à la suite de ces données (par exemple parce qu'elles sont dans le même fichier). Par exemple, si une application lit un fichier 4 Ko par 4 Ko un fichier de 16 Ko, et qu'on lit naïvement sur le disque dur, il faudra réaliser 4 requêtes de lecture. En étant un peu plus intelligent, on peut lire en avance (d'où le terme de read-ahead), ce qui a un double avantage. Tout d'abord, on réalisé une seule requête de lecture au lieu de quatre: il n'est donc nécessaire de calibrer la tête de lecture qu'une seule fois. En effet, les disques durs ont la propriété d'être lent pour le déplacement de leur tête de lecture, et d'offrir un bon débit une fois la tête positionnée. Ainsi, lire 16 Ko au lieu de 4 Ko ne prend que très peu de temps supplémentaire, puisque la majorité du temps est passé à déplacer la tête. Le second avantage est que grâce à cette lecture en avance, les données à lire sont présentes en mémoire avant même que l'application ne les demande.
Le problème est bien entendu de calibrer cette lecture en avance, pour qu'elle lise suffisamment (pour qu'elle soit utile), mais pas trop (pour ne pas qu'elle dégrade les performances en chargeant des données qui ne seront jamais utilisées). Et évidemment, le paramétrage de ce read-ahead dépend du type d'entrées-sorties réalisées par l'application. Si elles sont purement séquentielles (bloc N, puis bloc N+1, puis bloc N+2), alors il vaut mieux augmenter le read-ahead. En revanche, si les requêtes d'entrées-sorties concernent des blocs aléatoires sur le disque, alors il vaut mieux diminuer le read-ahead.
Le travail de WU Fengguang propose donc d'adapter le
read-ahead en fonction du contenu du
page cache. J'avoue ne pas avoir eu le temps de lire et de comprendre en détail le fonctionnement de son mécanisme d'adaptation, mais celui-ci est détaillé avec précision dans
le courrier électronique et
accompagné de nombreux benchmarks.
- Arnd Bergmann a publié une nouvelle série de patches concernant spufs. Je n'ai absolument pas regardé les patches, je n'y comprendrai rien, mais il m'a paru intéressant de parler brièvement de ce qu'est spufs.
spufs s'intègre dans le portage de Linux sur le
processeur Cell. Celui-ci, qui sera utilisé dans la Playstation 3, propose une architecture assez originale. Il est constitué d'un PowerPC 64bits "classique", mais également de 8 unités spécialisées appelées
Synergistic Processing Elements (SPE). Comme l'explique la page Wikipédia, chaque SPE est un petit processeur RISC disposant de 256 Ko de mémoire cache, qui permet d'exécuter du code en parallèle du processeur principal, le PowerPC 64 bits.
Pour que le portage de Linux soit complet, il fallait non seulement que le noyau Linux fonctionne sur le PowerPC 64 bits, mais également qu'il fournisse une interface de programmation pour ces
SPE, afin que des applications tournant sur le processeur principal puissent lancer des traitements spécifiques en parallèle dans les
SPE. Pour cela, les ingénieurs chargés du portage ont choisi d'utiliser un système de fichiers baptisé
spufs. Dans ce système de fichiers spécialisé, chaque répertoire représente un
SPE, et les différents fichiers contenus dans ce répertoire permettent de manipuler ce
SPE. La
page consacrée à ce sujet sur le site d'IBM donne l'exemple suivant:
$ mkdir /spu/myspu-12345
$ ls -lR /spu/
spu/:
total 0
drwxr-xr-x 2 arnd arnd 4096 Jun 17 21:00 my-spu-12345
spu/my-spu-12345:
total 0
-r--r----- 1 arnd arnd 0 Jun 17 21:01 ibox
-r--r----- 1 arnd arnd 0 Jun 17 21:01 mbox
-rw-rw---- 1 arnd arnd 262144 Jun 17 21:01 mem
-rw-rw---- 1 arnd arnd 2048 Jun 17 21:01 regs
-rw-rw---- 1 arnd arnd 0 Jun 17 21:01 run
--w--w---- 1 arnd arnd 0 Jun 17 21:01 wbox
Le fichier /spu/myspu-12345/mem représente le contenu des 256 Ko de mémoire cache d'un SPE. En réalisant des écritures dans ce fichier, on peut donc charger le contenu de la mémoire du SPE avec du code et des données. Je trouve ça assez amusant comme fonctionnement ;-)
Voilà, ce sera tout pour l'actualité du noyau. N'hésitez pas à poster vos remarques et suggestions dans les commentaires, en particulier sur ce qui vous a intéressé ou pas intéressé. On sait jamais, peut-être que je trouverais le temps de faire d'autres résumés de temps à autre.
MyPixmania... vers la 1.0.4
Parti d'un petit script réalisé pour des besoins personnels, le script
MyPixmania prend de l'ampleur. Peu après avoir sorti la version 1.0.3, Christophe Lucas m'a proposé quelques patches séparant le coeur du script (interaction avec le site) de l'interface texte et graphique. Tout ne me convenait pas entièrement, mais j'ai amélioré cette idée, et ce qui est disponible sur le
dépôt Subversion est séparé en trois parties:
- pixmania.py, qui contient les fonctions de base d'interaction avec le site
- mypixmania, qui contient l'interface en mode texte
- gmypixmania, qui contient l'interface en mode graphique
J'en ai profité pour ajouter une page de manuel pour
mypixmania, ainsi que les classiques fichiers README, TODO, LICENSE, AUTHORS et ChangeLog.
Étant donné que l'interface graphique était encore en développement, j'avais choisi de ne pas sortir de version 1.0.4 immédiatement, afin de laisser le temps à Christophe Lucas de finaliser son développement.
Et hier, coup de théatre: un développeur du site web
myPixMania envoie un mail à Christophe Lucas et moi-même indiquant qu'il était en train de développer une API nous permettant d'interagir avec le site sans utiliser de périlleuses
regexps avec
Curl. Au départ, il a proposé une API qui renvoyait les informations au format
Json. Bien qu'une API pour Json
soit disponible pour Python, Christophe Lucas et moi avons trouvé problématique que cette bibliothèque ne soit pas disponible dans les distributions majeures. Même dans Debian, ce n'est pas disponible. Utiliser une telle bibliothèque empêcherait au script
MyPixMania de marcher
out-of-the-box sur la plupart des distributions. J'ai donc proposé au développeur du site
myPixMania avec qui nous sommes en contact d'utiliser plutôt une API utilisant du XML, supporté directement par Python. Et il a accepté de modifier ses développements pour utiliser une telle interface.
Après le courrier électronique du
directeur systèmes et réseaux de Fotovista, je trouve très sympathique de pouvoir collaborer avec un développeur pour mettre en place une solution technique pérenne. L'ouverture de Fotovista est vraiment remarquable, et change des réactions un peu parfois brutales des entreprises en ce qui concerne la collaboration avec la communauté du Logiciel Libre (voir l'exemple de Plextor relaté dans un
journal LinuxFr).
Cette nouvelle interface permettra d'ajouter des fonctionnalités au script, notamment la récupération des photos stockées dans un album, le tout de manière plus pérenne. Du coup, avec tout ça, la version 1.0.4 est un peu reportée ;-)
En tout cas: merci myPixMania !
MyPixmania 1.0.3
La version 1.0.3 de
MyPixmania vient de sortir.
MyPixmania est un script qui permet d'utiliser les albums en ligne de Pixmania à l'aide d'une interface plus efficace que l'interface Web.
Nouveautés
Cette nouvelle version apporte les améliorations suivantes:
- possibilité de créer un album, grâce à une contribution de Christophe Lucas ;
- stockage de la configuration dans un fichier ~/.mypixmania.cfg et non plus dans le script directement, ce qui est plus propre, et permet d'envisager l'installation du script system-wide ;
- vérification que les photos à uploader sont bien en jpg. Pour l'instant, la vérification se fait sur l'extension du fichier, on pourrait envisager une autre solution ;
- une superbe option version qui affiche la version du script et les auteurs
Christophe Lucas travaille sur une interface graphique utilisant PyGtk qui sera vraisemblament intégrée dans une prochaine version.
Téléchargement
Ce
script est disponible dans un
dépôt Subversion. Il est distribué sous licence GPL.
Retour
À propos de ce script, j'ai récemment reçu un courrier électronique du
directeur systèmes et réseaux du groupe Fotovista auquel appartient Mypixmania. Il a trouvé que ce script Python était une très bonne chose, que cela palliait au manque de support pour les utilisateurs de Pixmania, et me remerciait du temps passé dessus. Sympathique, non ?
MyPixmania version 0.1.2
Le
script Mypixmania que j'avais écrit il y a quelques temps ne fonctionnait plus, car le site Web avait changé, et les expressions régulières utilisées ne convenaient donc plus. Jusqu'ici, j'avais eu la flemme de faire les modifications nécessaires. Heureusement, une
sympathique personne répondant au nom de
lud77 sur
LinuxFr m'a donné les modifications à effectuer.
J'en ai donc profité pour sortir la version 0.1.2 de ce magnifique script, qui remarche avec la version actuelle de Pixmania et corrige une petite erreur dans l'aide en ligne. C'est pas magnifique ? ;-)
Free, nouvelle Freebox
Suite à l'orage de la semaine dernière qui a
grillé ma Libre Boîte, j'ai ce soir appelé la Hotline de Free pour en demander une nouvelle. C'est la première fois que j'appelais cette hotline tant décriée dans les forums ici ou là. J'ai donc appelé vers 19h, une heure supposée être très encombrée. En réalité, à peine au bout d'une minute d'attente, un conseiller humain (pas une machine parlante) a pris en charge mon appel. Après une brève explication du problème, des tests effectués avec une autre Freebox, la communication du numéro de série de la Libre Boîte et quelques autres informations, ça y est, ma nouvelle boîte est commandée.
Alors forcément, ils sont peut-être plus diligents pour encaisser 400 Euros du remplacement d'une Freebox que pour aller réparer une ligne chez qui ça ne fonctionne pas ou plus, mais en tout cas, ils ont traité mon problème rapidement.
Par contre, quand à tout hasard j'ai demandé des conseils pour éviter les surtensions au téléconseiller, j'ai été un peu déçu. Je me suis vu conseillé l'achat d'un
ondulateur. Oui Madame, d'un
ondulateur, pas d'un
onduleur. Et quand j'ai demandé si les
ondulateurs filtrant les surtensions sur les lignes téléphoniques étaient compatibles avec l'ADSL, le téléconseiller n'a pas su me répondre.
Alors toi, ô lecteur de ce modeste journal, que me conseillerais-tu pour protéger mon installation technico-informatique ? Je n'ai pas besoin de moultes batteries, je me fiche que le jus soit coupé, je veux simplement éviter de griller des appareils. Et pour la ligne téléphonique, est-ce que les prises para-surtensions fonctionnent avec l'ADSL ? (Je me demande si le filtrage n'est pas un peu agressif avec les fréquences élevées utilisées par l'ADSL).
Hacker du matériel: la Xbox
Un
intéressant article, sur
xbox-linux.org résume les protections mises en place par Microsoft dans la Xbox pour empêcher l'exécution de code autre que leur code, ainsi que les failles trouvées dans ces protections qui ont permis de porter Linux sur la Xbox. Assez amusant de voir les
hacks en tout genre qui sont utilisés, ainsi que les astuces pour les contourner.
Sur un
autre site sont résumées les premières étapes du
crack de la Xbox. En particulier, cette
image montre une carte électronique développée spécifiquement pour
sniffer le bus reliant le
Northbridge au
processeur (c'est le
Northbridge qui contenait la clé de crypto). Sympathique bricolage, n'est-ce pas ?
Cet artiste du circuit imprimé, ce poète du condensateur a même écrit un livre intitulé
Hacking the Xbox, dont quelques chapitres sont disponibles en ligne. D'après
cette page, il semblerait que l'auteur ait éprouvé quelques soucis avec la DMCA: les éditeurs ne voulaient pas éditer ou vendre son ouvrage, et il a donc du l'éditer de manière indépendante, ce qui n'a pas dû être une partie de plaisir vu
la photo de sa voiture remplie de bouquins prêts à être envoyés.
En tout cas, son bouquin est
en vente pour $25, et peut sans doute être une lecture intéressante. On peut regretter qu'il n'ait pas décidé de le diffuser en PDF quelques mois après sa sortie...
Freebox ... au grill
Hier, la région toulousaine a subi un orage. Pas très violent, mais un orage quand même. Quand je suis rentré, les plombs avaient sauté. En remettant le courant, tout est reparti, sauf la Freebox, qui ne fonctionne plus. Donc plus d'Internet pour l'instant.
Dans ce cas, on peut se faire remplacer la Freebox par
Free pour la modique somme de 400 Euros. "Heureusement", je suis assuré, et je pourrais peut-être me faire rembourser cette somme par mon assurance, moyennant le paiement de la franchise pour la (un peu plus) modique somme de 125 Euros.
Ce cas de la foudre est un cas intéressant. Comme personne ne peut être pris pour responsable de la foudre qui tombe, c'est le consommateur-utilisateur qui trinque. C'est un choix... intéressant.
Je vais ressortir le bon vieux Sagem Fast 800, me battre pendant 15 ans pour faire marcher cette saleté, et espérer que ça peut marcher avec Free dégroupé. Courage ! ;-)
Du coup, je vais me prendre un petit WE prolongé pour aller faire un tour à Condom, dans le Gers. J'emmène la bécane portative, tout de même ;-)
Le syndrome de l'informaticien, ça commence...
Jusqu'ici, j'y avais échappé, et je pensais y échapper. Mais non, ça y est. Depuis hier, j'ai très mal au poignet droit. Je suis obligé de m'arrêter fréquemment de taper, et même si la douleur n'est pas intense, elle est constante et génante. Vu que je n'ai mal qu'au poignet droit, je me demande si c'est pas la cassure du poignet liée à l'utilisation de la souris qui est à l'origine de la douleur. Comment savoir ? Et que faire ? Pour l'instant, j'utilise un livre comme repose-poignet lorsque j'utilise la souris, ce qui limite la cassure du poignet. Mais sinon, que faut-il faire ? Changer de clavier ? Pour utiliser quoi ? Changer de
keymap ?
À propos de changer de
keymap, j'ai commencé à apprendre le
dvorak, grâce à
ce petit logiciel. Ce n'est pas évident, mais ça vient assez rapidement. Ce qui m'ennuie, c'est que le
keymap dvorak est très différent du
keymap dvorak-fr : même les lettres ne sont pas dans le même ordre. Et comme le logiciel est fait pour apprendre le
dvorak normal, ce n'est pas très pratique. Ceci dit, pour l'instant, je reste en
azerty, mes essais avec le
dvorak ne sont que des essais.
Avec tout ça, presque pas avancé ce soir, j'espère que ce mal de poignet va passer...
Générer du iCal en PHP
Pour l'
Agenda du Libre, quelques personnes ont proposé de générer des calendriers au format iCal, qui seraient ainsi importables directement dans des applications comme
Mozilla Sunbird. Ainsi, à coté de vos rendez-vous pros et persos, vous pourriez avoir « Bouffe Linux du coin », « Atelier ZorGlub v3.12 ». Ça serait fort, n'est-ce pas ?
J'ai donc commencé à regarder à quoi ça ressemblait. Déjà, je m'aperçois que iCal est un format ouvert, normalisé par la
RFC 2445, ce qui est plutôt une bonne nouvelle. Je me dis donc que des gens biens ont dû écrire une petite classe PHP sympathique pour générer les fichiers
ics prêts à être importés dans votre logiciel de calendrier favori.
Je demande à mon copain Google, et assez difficilement, je tombe sur
ça, puis après déchiffrage de l'allemand, sur
la page de téléchargement. Je télécharge, je décompresse. L'ensemble fait 6 fichiers plus un fichier d'exemple, ce qui semble assez léger, et donc convenir à mes besoins. J'ouvre un fichier au hasard, et voilà l'entête:
//+----------------------------------------------------------------------+
//| WAMP (XP-SP1/1.3.27/4.0.12/5.0.0b2-dev) |
//+----------------------------------------------------------------------+
//| Copyright (c) 1992-2003 Michael Wimmer |
//+----------------------------------------------------------------------+
//| I don't have the time to read through all the licences to find out |
//| what the exactly say. But it's simple. It's free for non commercial |
//| projects, but as soon as you make money with it, i want my share :-) |
//| (License : Free for non-commercial use) |
//+----------------------------------------------------------------------+
//| Authors: Michael Wimmer <flaimo@gmx.net> |
//+----------------------------------------------------------------------+
L'auteur n'a pas voulu prendre du temps pour comprendre les licences, et du coup, il est tombé dans le panneau du
free for non-commercial use. Par le même coup, je ne peux pas utiliser ce code pour l'Agenda du Libre, dont le code est sous licence GPL ;-( J'ai quand même écrit au développeur, au cas où, mais le
« as soon as you make money with it, i want my share » me laisse supposer qu'il sera assez réticent à l'idée de le diffuser sous une licence qui autorise les utilisations commerciales.
Je me remets donc à la recherche d'une classe PHP pour faire ce travail, car je n'ai pas envie d'en écrire une moi-même. D'une part, la RFC du format iCal a l'air assez longue, donc certainement pas très facile à implémenter, et d'autre part, je préfère réutiliser le code déjà écrit plutôt que de réinventer une n-ième fois la roue (j'ai fait
KOS pour réinventer la roue, ça suffit !). Jusqu'à maintenant, je n'ai rien trouvé. Il y a tout un tas de
groupware en PHP qui permettent d'afficher sur une page Web un calendrier iCal, mais je n'ai pas trouvé de bibliothèque pour générer du iCal. Et vous, en connaissez-vous ?
Sinon, au fil de mes déambulations, j'ai découvert :
- que des zigotos se prenaient la tête pour faire du PHP closed-source. Intéressant, non ? L'article précise tout de même: « Some may claim that distributing PHP applications as 'closed-source', in binary form, is a bad thing as it is detrimental to the open source community from which PHP itself comes. » ;-)
- que le tarball, compressé avec bzip2 de PHPgroupware, fait pas loin de 17 Mo. Bloat^WGroupware ?
Les tags sur les paquets Debian, c'est parti
À la mi-juin, dans un
billet sur la classification de l'information, je parlais de
debtags. Il s'agit d'un projet visant à classer les paquets Debian non plus dans de simples sections, mais en les marquant avec un ou plusieurs
tags. C'était à l'époque encore en projet, et n'était pas intégré officiellement à la distribution.
Aujourd'hui, en lisant le dernier
Debian Weekly News, j'apprends :
Debtags finally integrated. Enrico Zini reported that Packages files recently started to include debtags information that others had already noticed. The tag information can be browsed online and edited with either debtags-edit or tagcolledit.
Debtags est donc intégré officiellement dans Debian, et les utilisateurs sont invités à participer à la classification des paquets en y ajoutant des
tags. Sympa !
Dans les mêmes DWN (Debian Weekly News), j'ai noté deux autres informations intéressantes :
- Un lien vers une proposition de mécanisme pour supporter les architectures multiples, c'est à dire les architectures qui permettent d'exécuter plusieurs types de code. Par exemple, sur une plateforme x86-64, on peut exécuter à la fois du code i386 et du code amd64. On veut donc pouvoir installer le même paquet en i386 et en amd64, par exemple parce qu'on utilise la version amd64 couramment, mais qu'à cause d'une application propriétaire quelconque, on a besoin de la version 32 bits d'une bibliothèque. Le document décrit comment Debian pourrait supporter cela. Une lecture intéressante
- Un lien vers les vidéos de Debconf5, la conférence Debian qui a eu lieu mi-juillet en Finlande. Par exemple, il y a les vidéos des conférences de Branden Robinson (actuel leader du projet Debian), une conférence de Benjamin Mako Hill dont j'ai parlé récemment ici ou une conférence de Mark Shuttleworth, l'homme à l'origine d'Ubuntu. Il y a également des conférences sur la gestion des architectures multiples (puisque j'en parle ci-dessus), sur debtags (puisque j'en parle aussi ci-dessus), et sur plein d'autres sujets passionants !
Les scripts, j'adore
J'adore les petits bricolages qu'on peut faire avec des scripts rapidement écrits. Ça peut paraître assez stupide, mais je trouve ça assez fantastique. Dernier exemple en date : j'avais envie d'une page Web liste les flux RSS auxquels je suis abonné grâce à
Feed2Imap. Mieux, il faudrait que cette page Web soit sur mon Wiki, et qu'elle se mette à jour automagiquement, sans que j'ai besoin de faire quoi que ce soit. La recette est la suivante.
Soit un fichier
.feed2imaprc qui contient la liste des flux RSS avec leur URL, de la forme :
- name: KernelTrap
url: http://kerneltrap.org/node/feed
target: imap://user:pass@host/mail/rss/vrac
Un petit script Perl parse ce fichier, et crache une requête SQL de type
update qui peut mettre à jour la page
ListeFluxRss de mon blog :
#!/usr/bin/perl -w
use strict;
my $name = "";
my $url = "";
my $body = "===== Liste de flux RSS =====
Ci-dessous sont listés les flux RSS auxquels je suis abonné, grâce à [[http://home.gna.org/feed2imap Feed2Imap]].
";
while(<>)
{
if (/- name: (.*)/) {
$name = $1;
}
if (/url: (http\:\/\/.*)/) {
$url = $1;
}
if ($url) {
$body .= " - [[" . $url . " " . $name . "]]\n";
$url = "";
}
}
my $sql = "update wikini_pages set body='$body', time=NOW() where (tag='ListeFluxRss' and latest='Y')";
print $sql;
Il suffit alors de lancer quelque chose comme (le mot de passe de la base MySQL étant dans le fichier
~/.my.cnf) :
cat .feed2imaprc | ./rsslist2html | mysql -h localhost -u thomas thomas
Et hop, la page
ListeFluxRss est mise à jour. On rentre la commande dans la
crontab pour qu'elle soit appelée tous les jours, et voilà, c'est mis à jour automagiquement.
Franchement, j'adore ce genre de petits bricolages. C'est peut-être crado, pas bien conçu ou que sais-je encore, mais en tout cas, ça a pris 5 minutes en réutilisant les outils qui existent déjà. Je trouve vraiment ça merveilleux.
Git bisect
Via le
blog de Dave Miller, je découvre une fonctionnalité amusante et intéressante de
git. Pour ceux qui ne connaissent pas
git, c'est le nouveau système de gestion de version utilisé par les développeurs du noyau depuis l'abandon de la version gratuite de BitKeeper par la société BitMover (voir les dépêches
LinuxFr là,
là et
là).
La fonctionnalité dont parle Dave Miller, expliquée dans l'
entrée de ChangeLog correspondante, est
git bisect. Elle permet de rechercher quelle changement dans le noyau a introduit un bug. En gros, on marque une version comme étant "bonne" (sans le bug) et une version comme étant "mauvaise" (avec le bug). Entre ces deux versions, il y a un certain nombre de changements.
git propose alors automatiquement de tester une version du noyau avec la moitié des changements entre la "bonne" et la "mauvaise" version. On peut alors vérifier si cette version fonctionne ou pas. Si elle fonctionne, alors
git propose une autre version sur laquelle auront été appliqués 3/4 des changements entre la "bonne" et la "mauvaise" version d'origine. Et si elle ne fonctionne pas,
git propose une autre version sur laquelle auront été appliqués 1/4 des changements entre la "bonne" et la "mauvaise". Et ainsi de suite, par
dichotomie, on finit par trouver le changement dans le noyau qui a introduit un bug. Sympathique, non ?
Vérification formelle des logiciels
Wikipédia décrit les
méthodes formelles de la façon suivante :
les méthodes formelles sont des techniques permettant de raisonner rigoureusement sur des programmes informatiques, ou aussi des matériels électroniques, afin de démontrer leur correction, en se basant sur des raisonnements de logique mathématique.
Je ne suis pas du tout un spécialiste de la vérification formelle, loin de là. Ce qui m'amène à en parler, c'est un article de
Kuro5hin,
A Case for Formal Specification, que je trouve assez clair et abordable pour le néophyte comme moi. Il vante les mérites de la vérification formelle, mais comme tous les articles d'initiation se limite à un exemple simpliste, qui ne permet pas de convaincre le lecteur de la viabilité de la méthode, ce qui se ressent quelques peu dans les commentaires. Toutefois, ça reste une lecture intéressante que je recommande à tous ceux qui programment.
Lorsque j'étais en stage à Rennes, mon maître de stage (et développeur de
demexp) était un fan des méthodes formelles, il tient d'ailleurs une
liste de quelques outils adaptés. À propos de vérification formelle, il y a eu une conférence sur le système d'exploitation
Coyotos dans le thème OS des RMLLs cette année, j'en ai parlé
ici. Un des objectifs de ce projet est de
Construct the kernel and key utilities in a new systems programming language (BitC) with a well-defined, mechanically-specified semantics. This will allow us to formally verify security and correctness properties of the system and its key utilities.
Il serait sans doute intéressant de voir ce que cela va donner en pratique.
Quelques articles techniques d'un nouveau venu dans la blogosphère
Pour fêter la première année de son
blog (qui n'avait vu qu'un seul billet en un an),
David Decotigny publie trois petits HOWTOs techniques qui peuvent servir :
- Des notes sur la génération d'un cross-compilateur gcc
- Une documentation sur l'installation de Debian Sarge sur un iBook
- Quelques notes sur l'installation et la configuration de Software Suspens 2
Malheureusement, le blog de David utilise
WikiBlog, et ne dispose donc pas de flux RSS. En effet, je n'ai jamais eu le temps de sortir une version de
WikiBlog avec la génération de flux RSS que j'utilise sur ce site. C'est tellement un
hack ce
WikiBlog de toute façon... ;-)
Retour du Canada, et du boulot...
Je viens de rentrer aujourd'hui du Canada. Quatre jours de conférences très intéressantes, de nombreuses rencontres et discussions, ce déplacement au Linux Symposium fut vraiment intense. J'ai pris pas mal de notes sur les conférences, j'espère pouvoir en faire très prochainement un compte-rendu ici afin de faire profiter mes quelques lecteurs de mes impressions sur ce symposium.
Six jours d'absence, ça veut dire aussi plein de choses à faire au retour, mais en attendant, je vais essayer de me remettre du décalage horaire ;-)
Départ pour le Canada
Aujourd'hui, je m'envole pour le
Canada, dans le cadre d'un déplacement professionnel qui m'amène à assister au
Linux Symposium 2005. Au programme, pendant quatre jours, une
quantité intéressante de conférences, sur plein de sujets autour du noyau Linux. La qualité devrait être également de la partie, avec des orateurs comme Jonathan Corbet, de
LWN, Rusty Russell, Greg Kroah-Hartman, Ian Pratt de Xen, Jeff Dike de User-Mode-Linux que j'ai déjà rencontré aux RMLLs, Rik Van Riel et au niveau des clusters des gens comme Bruce Walker ou Daniel Philipps.
Les proceedings des conférences sont déjà disponibles, sous la forme de
deux PDF.
Je ne sais pas encore si je vais pouvoir faire un compte-rendu des conférences comme je l'ai fait pour les RMLLs, mais si j'ai la possibilité, je le ferai!
Il s'appelle Skim
Ça y est, j'ai reçu aujourd'hui mon portable Dell Latitude D410. Il s'appelle
skim. Il est assez léger, petit, plutôt joli et en tout cas très rapide. J'ai démarré l'ordinateur, accepté le
Contrat de licence Dell, mais refusé le
Contrat de licence Microsoft Windows XP. Comme indiqué dans cette dernière, je m'apprête à demander le remboursement des logiciels fournis.
Sans plus attendre, j'ai installé une Debian sur la machine. Plutôt que d'utiliser la traditionnelle installation par CD-ROM, j'ai décidé de tenter l'installation par
clé USB. Pour moi, tout a bien marché, sauf que j'ai mis les fichiers directement dans /dev/sda et non dans une partition /dev/sda1. J'ai utilisé
ces fichiers, qui permettent de démarrer un noyau 2.6 avec support réseau pour installation par Internet. Tout a magiquement fonctionné, c'est impressionant.
J'utilise le
Xorg expérimental proposé par un
développeur Debian. Pour l'instant, je suis obligé de tourner en VESA, parce que le pilote accéléré pour ma carte graphique n'est disponible que dans la version de développement de Xorg, d'après
cette page.
Ensuite, il va falloir que j'étudie les trucs bizarres comme l'ACPI, la gestion de la batterie, des ventilateurs, de la température, l'hibernation en mémoire et l'hibernation sur disque, peut-être voir ce qu'est une DSDT et voir si la mienne est en bon état, faire marcher le Wifi, la sortie VGA externe, et tout plein d'autres trucs rigolos.
Il faudra également que je trouve une méthode de synchronisation entre mon HOME sur ma machine de travail et sur le portable. Vous, qu'utilisez-vous ? Je trouve que NFS fait trop ramer les machines. Avant je faisais du
rsync, je vais peut-être passer à
unison, qu'en dites-vous ?
L'heureux élu : un Dell Latitude D410
En novembre 2000, j'ai acheté d'occasion un portable, un Fujitsu doté d'un Celeron 333 Mhz et de 96 Mo de RAM. La machine était peu véloce, mais suffisait largement à mes besoins portatifs. Malheureusement, le jour du départ pour les Rencontres Mondiales du Logiciel 2003 qui avaient lieu à Metz, celui-ci a eu le mauvais goût de me lâcher. La veille, il marchait impeccable, et paf, le lendemain, plus rien. Pourtant, il est resté posé sur mon bureau toute la nuit. Ça va bientôt faire deux ans, et je n'ai toujours pas élucidé ce mystère.
Bref, depuis deux ans, je me dis qu'il faut que je me rachète un portable. Depuis de longs mois, je regarde ce qui sort en portable, je mets au point des critères de sélection. J'avais besoin d'un portable léger (inférieur à 2kg), petit (écran 12"), bien équipé (Wifi, réseau), mais pas forcément le dernier cri en matière de processeur. Trouver un tel portable à un prix raisonnable est assez difficile : les IBM Thinkpad sont trop chers, de même que les Toshiba Portégé. Bref, je ne trouvais rien de bien.
Tout récemment, j'ai regardé les derniers portables Dell, et j'ai découvert le
Latitude D410 et le
Latitude X1. Au départ, c'est ce dernier qui m'intéressait le plus : écran panoramique 12.1", 1.14kg seulement. Toutefois, après réfléxion, je me suis rabattu sur le D410. Bien qu'un peu plus lourd (1.70 kg), il dispose en standard d'une batterie 9 cellules, offrant une autonomie bien supérieure à la pauvre 3 cellules du X1. En plus, pour un même niveau d'équipement (512 Mo de RAM, 60 Go de disque dur, réseau, Wifi), il est 250 Euros moins cher. Par contre, aussi bien sur le X1 que sur le D410, le lecteur DVD/graveur CD est externe. C'est pas très pratique, mais en même temps, de nos jours, un lecteur DVD ce n'est pas utile tous les jours. Je pense donc pouvoir le laisser la plupart du temps à la maison. L'autre inconvénient, c'est qu'il est livré d'office avec Windows XP Pro, dont je n'ai pas besoin. Je vais peut-être me rapprocher du groupe Detaxe de l'AFUL qui a
réussi à se faire rembourser les logiciels livrés d'office avec un ordinateur portable Dell.
J'ai donc commandé ce WE un Dell Latitude D410 pour un peu plus de 1300 Euros frais de port compris. Dell m'offre avec ça une clé USB 512 Mo (la classe !), et surtout une garantie de 3 ans sur site J+1, ce qui n'est pas négligeable par rapport aux autres constructeurs. J'espère le recevoir avant de partir aux RMLLs !
Wiki utilisant Subversion
Dans ma
TODO-list, il y a (avait ?) quelque chose comme
«Faire un Wiki avec un truc genre CVS ou Svn derrière». Et bien, apparemment, cet élément de la liste est réglé, grâce à un Logiciel Libre que j'ai découvert il y a quelques temps.
En regardant le
programme de OSCon 2005, la conf organisée par O'Reilly à Portland, j'ai vu une présentation appelée
Building apps with Subversion, donnée par
Greg Stein, de Google. Dans cette présentation, il abordera apparemment comment utiliser Subversion dans des applications en utilisant les APIs Subversion, en particulier depuis Python. Et comme exemple, il cite
SubWiki. D'après la page Web :
«This project is focused around the development and support of SubWiki?, a Wiki that uses Subversion for its data repository. It is implemented as a Python-based CGI script.»
C'est précisement ce que je cherchais ! En fouillant un peu plus, on découvre même un
message d'un développeur signalant qu'il avait créé la même chose en Scheme. Il a baptisé son logiciel
SvnWiki.
Il existe donc au moins deux Wikis reposant sur Subversion. Il reste maintenant à les tester pour voir comment ça fonctionne et si ça fonctionne bien !
Classification de l'information
La
classification de l'information est un problème complexe, surtout avec l'avènement d'Internet qui permet à tout un chacun d'accéder à une masse d'informations gigantesque. Aux débuts du Web, des annuaires comme
Yahoo étaient suffisants, mais rapidement, des systèmes de recherche plus évolués (comme ceux développés par
Google) sont devenus nécessaires pour s'y retrouver.
Lorsque l'on classe des informations en catégories, un problème revient souvent : il y a plusieurs éléments que l'on pourrait classer dans plusieurs catégories. C'est ce problème que rencontre actuellement
Debian. En effet, chaque paquet Debian fait partie d'une
Section, qui identifie la catégorie du logiciel contenu dans le paquet. Par exemple :
thomas@crazy:~$ apt-cache show mozilla-firefox | grep ^Section
Section: web
Toutefois, les limitations de ce système de classification sont connues et il pose
des problèmes. Firefox doit-il être dans la section
Web ou dans la section
Net ? Un éditeur HTML doit-il être dans
Web ou dans
Devel ? Un lecteur vidéo doit-il être dans
Vidéo ou
Multimédia ?
Au sein de Debian, un projet a vu le jour pour développer un nouveau système de classification basé sur des
tags :
Debtags. Un ou plusieurs tags sont affectés à chaque paquet, ce qui permet à même paquet d'être présent dans plusieurs catégories, et donc de faire des recherches plus fines sur les paquets. Au niveau de Debian, cela est d'autant plus nécessaire que le nombre de paquets a explosé dans les dernières versions pour atteindre environ 15.000 paquets dans
Sarge. Le projet Debtags utilise une classification appelée
faceted classification :
«A faceted classification differs from a traditional one in that it does not assign fixed slots to subjects in sequence, but uses clearly defined, mutually exclusive, and collectively exhaustive aspects, properties, or characteristics of a class or specific subject. Such aspects, properties, or characteristics are called facets of a class or subject, a term introduced into classification theory and given this new meaning by the Indian librarian and classificationist S.R. Ranganathan and first used in his Colon Classification in the early 1930s.»
Ces problématiques de classification des informations se retrouvent dans le projet
DemExp. L'objectif de
DemExp? est (brièvement) de permettre à chaque citoyen de s'exprimer sur toutes les questions poltiques, économiques, culturelles, environnementales, etc. Pour cela,
DemExp? utilise comme support un logiciel de vote qui permet d'accéder à une base de question. Or, on s'aperçoit que dès que le nombre de questions augmente (au delà d'une centaine, par exemple), il devient difficile de s'y retrouver, même avec une classification par
tag. D'autre part, la classification par
tag est difficile : comment décider si telle ou telle question doit être associée à tel ou tel tag ?
Tout ceci n'est pas trivial, mais ce sont des problématiques majeures pour l'avenir, où de plus en plus d'informations seront disponibles et où il sera de plus en plus difficile de trouver l'information pertinente.
Comment cramer sa machine en 5 minutes...
Samedi matin, je reçois le disque dur de 200 Go commandé quelques jours auparavant sur LDLC. Après un démontage de mon serveur, j'ajoute le disque dur à celui-ci, et le démarre. Le noyau Linux m'informe donc dans un jargon aussi incompréhensible qu'imbitable :
hdb: cannot use LBA48 DMA - PIO mode will be used for accessing sectors > 268435456
Bien, dis-je, pourquoi pas. Tant pis, on n'utilisera pas le DMA pour accéder à la fin du disque. Le noyau continue de démarrer, mais galère vraiment sur la détection des partitions. Une fois ceci passé, il termine son démarrage. Le lancement d'un
fdisk sur le disque dur n'est pas plus probant : ça ne marche pas.
Je savais déjà que ce K6-2 500 Mhz avait des problèmes avec les gros disques durs. Il dispose déjà d'un disque de 120 Go qui n'est pas détecté par le BIOS, mais seulement par le noyau Linux. Un bon vieux disque dur de 1 Go traine dans la machine avec juste le noyau Linux pour permettre de démarrer et détecter les autres disques. Je m'attendais à ce que cette méthode fonctionne également avec un disque de 200 Go. Apparemment, non.
À l'aide de ma machine de bureau, je mets donc à la recherche d'une mise à jour du BIOS pour la carte mère, une recherche qui s'avère difficile à travers le site Javascripteux de Asus, surtout lorsque l'on ne se souvient plus de la marque de la carte mère achetée d'occasion. Finalement, je trouve cette mise à jour, ainsi que l'outil qui va avec, évidemment prévu pour DOS. Je télécharge donc
FreeDOS? pour pouvoir lancer la chose sur le serveur. Après 5 disquettes foireuses essayées, j'en trouve finalement deux assez coopérantes pour y placer
FreeDOS? et la mise à jour du BIOS.
Mon serveur ne disposant pas de lecteur de disquette, j'emprunte celui de ma machine de bureau et l'installe dans le serveur. Je boote sous
FreeDOS?, et retrouve la sympathique invite :
J'insère la disquette avec la mise à jour du BIOS, puis tape
dir. Mais rien n'y fait, le contenu du fameux
A: ne change pas. Pourtant,
A:, c'est bien le lecteur de disquette me semble-t-il. J'en ai conclu que
FreeDOS? émulait une disquette à partir d'une image compressée contenue sur la disquette, mais je n'ai pas vérifié. Enfin, en tout cas, la mise à jour du BIOS, pas possible.
Je rallume donc ma machine de bureau pour farfouiller sur Google. Et là, rien. Clic. Clic. Clic. Rien. Toujours rien. Le silence. Démontage de toutes les cartes, de tous les disques. Clic. Clic. Toujours rien. Ah si :
beep,
beep,
beep. Trois
beeps stridants qui se répètent. Rien sur l'écran, rien nulle part. Que se passe-t-il ?
Une recherche Google avec (encore) une autre bécane m'informe que trois
beeps, c'est
64K Base RAM Failed. Oups, la RAM serait morte ? Je débranche donc la barrette de RAM, la reconnecte. Clic, je rallume la machine, puis vois apparaître, sous mes yeux ébahis, la fumée caractéristique d'un évènement malheureux, l'odeur nauséabonde du plastique et de la poussière brulée indiquant un problème manifeste. La chose est brûlée.
Incompréhensible, je ne comprends pas. J'ai simplement déconnecté le lecteur de disquette, la machine était bien sûr éteinte. Et ça a tout fait foirer. Voilà un samedi qui commence bien. Moi qui comptait garder cette machine encore un ou deux ans, c'est raté. Me voilà obligé d'aller racheter des pièces neuves, moi qui suis un adepte de l'occasion pour l'informatique, parce que j'ai rarement besoin des cartes
machin-chose dernier cri.
Finalement, après cette aventure malheureuse, me voilà chevauchant un AMD 64 bits à 1.8 Ghz et 512 Mo de RAM, bien plus silencieux que la bécane que j'avais avant. J'aurai pu trouver un peu moins cher en prenant du 32 bits, mais je me suis dit que tant qu'à faire, autant être moderne et opter sur le 64 bits. Pour l'instant, j'ai conservé ma Debian GNU/Linux 32 bits, mais j'espère tester la Debian AMD64 un jour.
Voilà comment cramer sa bécane en 5 minutes. La reproductibilité de cette technique n'est pas garantie. Si elle ne fonctionne pas, vous pouvez toujours renverser un verre d'eau sur votre carte mère, ça devrait avoir un effet assez semblable.
Pour finir, revenons sur ce disque dur de 200 Go, dont le problème sous Linux n'était toujours pas résolu. En fait, après farfouillage sur le Web, je constate qu'effectivement le contrôleur IDE de cette carte mère ne gère pas le DMA sur les disques durs de plus de 127 Go, mais qu'il marche en PIO. Et plus précisement, je m'aperçois dans le
ChangeLog du noyau 2.6.11.11 (le tout dernier), des corrections ont été apportées à la gestion du LBA48 (le
ChangeLog? parle de LBA8, mais c'est une erreur). Et effectivement, avec ce nouveau noyau, le disque dur s'est mis à marcher à merveille. Pour les lignes de C suivantes, j'ai donc cramé ma machine de bureau :
+++ b/drivers/ide/ide-disk.c
@@ -133,6 +133,8 @@ static ide_startstop_t __ide_do_rw_disk(
if (hwif->no_lba48_dma && lba48 && dma) {
if (block + rq->nr_sectors > 1ULL << 28)
dma = 0;
+ else
+ lba48 = 0;
}
if (!dma) {
@@ -146,7 +148,7 @@ static ide_startstop_t __ide_do_rw_disk(
/* FIXME: SELECT_MASK(drive, 0) ? */
if (drive->select.b.lba) {
- if (drive->addressing == 1) {
+ if (lba48) {
task_ioreg_t tasklets[10];
Sympathique, non ? ;-)
Lectures autour du noyau Linux
Passionné de système, je m'informe régulièrement sur l'actualité du développement du noyau Linux. Au delà de la bouillonante affaire
BitKeeper?, il y a une foultitude de choses intéressantes à apprendre au sujet du noyau sur divers sites Webs ou mailing-list. J'ai cru intéressant de partager ces pointeurs avec mes quelques lecteurs (Ô lecteur, es-tu là ?).
- Tout d'abord, on peut citer la fameuse lkml, Linux Kernel Mailing List, dont les archives sont disponibles par exemple sur Marc The Aims Group. Tout lire ou s'y abonner est quasiment impossible : de 6000 à 9000 mails y sont postés chaque mois, soit environ 300 par jour. Il est donc nécessaire de se tourner vers d'autres sources d'informations.
- Linux Weekly News offre chaque semaine un résumé de l'actualité du développement noyau. Le résumé est réalisé par Jonathan Corbet, un des auteurs du Linux Device Drivers, qui est donc très compétent dans le domaine. Les résumés sont d'excellentes qualités, on y apprend énormément. Souvent, Jonathan n'offre pas seulement qu'un résumé de l'actualité, mais aussi un peu de recul par rapport à l'avancée de certains projets ou de certaines idées. Vraiment une source d'informations excellentes. D'ailleurs, LWN n'est pas seulement excellent pour sa partie noyau, mais aussi pour des articles dans d'autres sections. À la parution, les articles sont réservés aux abonnés pendant une semaine, puis deviennent accessibles à tous. Ceci étant dit, l'abonnement ne coûte que 5 dollars par mois, soit vraiment pas grand chose en comparaison du travail effectué par Jonathan.
- Kernel Traffic est un résumé plus terre à terre de l'activité du développement noyau, réalisé par Zack Brown. Sa périodicité est plus irrégulière, et sa lecture est à mon avis un peu moins intéressante. On peut bien entendu y trouver des informations, mais souvent le résumé porte sur des discussions peu passionantes. On peut noter également que Zack Brown a récemment lancé Git Traffic, dans le même esprit, mais qui résume l'activité autour de Git, le nouveau système de gestion de contenu des développeurs noyau.
- KernelTrap donne des informations un peu moins techniques sur tout ce qui concerne le développement du noyau Linux ou des BSDs. Jeremy, l'auteur du site, résume le plus souvent quelques discussions importantes ayant lieu sur la liste, mais sans vraiment donner de recul comme peut le faire Jonathan Corbet. À mon avis, c'est un site de nature complémentaire à LWN.
- Kernel Planet, c'est la planète des blogs de quelques développeurs noyau. Ils sont pour l'instant assez peu, et à vrai dire, je ne sais pas si la plupart des développeurs noyau sont des fans de blog. Enfin, en tout cas, de temps en temps, il y a des choses intéressantes sur Kernel Planet. Pas souvent, mais ça arrive ;-) En tout cas, pour connaître les potins, ragots et rumeurs, c'est parfait !
- Kernel Newbies et surtout sa mailing-list. Le site est moche et contient assez peu d'informations, mais la mailing-list est intéressante. Ça faisait quelques temps que je voulais m'y abonner, et j'ai récemment franchi le pas. Le traffic est tout à fait raisonnable, et des développeurs importants du noyau tels que Rik Van Riel ou Greg KH répondent aux messages. J'ai d'ailleurs été impressionné de voir que ces gens continuaient à répondre à des «newbies». Et effectivement, sur la liste kernelnewbies, il y a de vrais «newbies», qui posent parfois des questions assez stupides, et surtout ne savent pas rédiger un mail (réponse au dessus, un simple «OK» avec tout le mail originel en citation, etc.). Bref, je suis abonné, je lis et je réponds parfois.
Voilà pour mes lectures du coté du noyau Linux. Si vous avez d'autres pointeurs intéressants, n'hésitez pas à me les faire parvenir !
Deuxième paquet Debian
Ça y est, après
CamlRPC, mon deuxième paquet Debian est entré dans
unstable. Il s'agit de
CDuce, un langage de programmation adapté au traitement de fichiers XML. C'est un outil qui est utilisé dans
DemExp. Le
paquet est en train d'être déployé sur les
mirroirs FTP. Des versions pour alpha, hppa, i386, m68k, mipsel, powerpc sont déjà disponibles.
Maintenant, la prochaine étape, c'est l'entrée dans
testing du paquet
CamlRPC? !
My Pixmania
Vous connaissez sans doute le site
MyPixmania qui permet d'uploader des photos, de les stocker dans des albums, puis de les faire développer et se les faire envoyer par la Poste. Comme uploader des dizaines de photos une par une par un formulaire Web est un peu laborieux, le site propose un système d'
ActiveX? pour Microsoft Windows, et un logiciel spécifique pour
MacOS?. Mais évidemment, pour les utilisateurs de GNU/Linux ou d'autres Unices, rien n'a été prévu.
Pour apprendre le Python, et puisque j'en avais besoin, j'ai écrit un petit script qui permet d'automatiser l'upload de photos. Ses fonctionnalités sont assez limitées, mais font ce que je veux :
- se logger sur le site
- lister les albums existants
- uploader une ou plusieurs photos dans un album
Il n'est donc pas possible (pour l'instant ?) de :
- renommer ou supprimer une photo
- créer, renommer ou supprimer un album
Le script fonctionne en imitant un navigateur, en utilisant la bibliothèque
Curl et son module Python associé. Il envoie les requêtes HTTP GET et POST qui conviennent pour faire ce qu'il faut. L'écriture du script n'a pas été évidente, car le site
MyPixmania?.fr est assez complexe : beaucoup de
JavaScript?, des cookies, des sessions PHP, etc... D'autre part, la pérennité du script n'est pas excellente : le script repose sur la sortie HTML des pages du site. Si le site est modifié, alors il y a des chances pour que le script ne fonctionne plus. Toutefois, pour l'instant, il fonctionne ;-)
Le
script est disponible et distribué sous les termes de la
licence GPL. Il s'appelle tout simple
MyPixmania?, nom que je devrais probablement changer pour éviter des soucis avec le site officiel Mypixmania.com.
Merci à
Dave pour l'aide en Python !
Paquet Debian uploadé !
Ça y est, le
bug 298117 de Debian a été fermé ! Ce bug était en fait l'
ITP (
Intent to package) que j'avais soumis pour indiquer mon intention de packager la bibliothèque RPC pour Ocaml. Après une longue découverte du processus de création de paquets Debian, de prise de contacts avec les mainteneneurs Debian des paquets Ocaml, l'upload sur le Subversion des mainteneurs, et surtout la très longue attente dans la
NEW queue de Debian, le paquet a été réellement uploadé aujourd'hui. Il est par exemple disponible sur
ftp://ftp.debian.org/debian/pool/main/c/camlrpc/.
Néanmoins, tout n'est pas fini : les mainteneurs Debian OCaml ont entre temps mis en place une nouvelle version du compilateur Caml, la 3.08.3, incompatible avec la 3.08.2. Il est donc nécessaire de modifier un peu les dépendances des paquets et de les recompiler. J'essaierai de m'y atteler les prochains jours. Je suis également toujours sur le paquet Debian de
CDuce. J'espère pouvoir avancer assez rapidement sur ces projets.
C'est donc heureux d'avoir mon premier paquet Debian dans la section
main de ma distribution préférée que je vais aller me coucher pour me reposer d'une longue journée de travail !
Brevet : du mal à le croire
Au détour d'un canal IRC, j'ai découvert un brevet intitulé
Is Not Operator. Le résumé indique qu'il s'agit d'
« un système, d'une méthode et d'un média lisible par un ordinateur supportant l'utilisation d'un opérateur simple permettant la comparaison de deux variables pour déterminer si les deux variables pointent à la même adresse en mémoire » (traduction personnelle).
Les revendications ne donnent pas plus de détails sur cette technologie innovante, utile et inventive. Revendication 1 :
« Un système pour déterminer si deux opérandes pointent vers des adresses différentes en mémoire, le système comprenant : un compilateur pour recevoir le code source et générer un code exécutable depuis le code source, le code source comprenant une expression qui comprend un opérateur associé avec une première opérande et une seconde opérande, l'expression étant évalué à vrai lorsque la première opérande et la seconde opérande pointent vers des adresses mémoire différentes. » (traduction personnelle).
Si j'ai bien compris (on peut en douter, vu le caractère assez charabiotique de l'énoncé précédent), le principe suivant est breveté :
Intéressant, non ? Là où je ne comprends vraiment pas, c'est la date de dépôt du brevet :
Filed: May 14, 2003. Il a donc vraiment été déposé le 14 mai 2003 ? Pourtant, il parle de BASIC et d'autres trucs complètement dépassés. J'ai raté quelque chose ?
Du rififi chez Qemu
Qemu est un émulateur qui permet d'émuler le fonctionnement d'une machine x86 ou
PowerPC?, ou de faire fonctionner des binaires x86,
PowerPC? ou ARM sur n'importe quelle architecture. Ce projet, lancé, maintenu et développé principalement par
Fabrice Bellard présente la particularité d'utiliser de la
traduction dynamique, ce qui lui permet d'atteindre des vitesses d'émulation largement supérieures à celles qu'on peut obtenir avec
Bochs. La
documentation technique donne plus d'informations sur le fonctionnement interne de Qemu. Pour info,
Fabrice Bellard n'en était pas à son coup d'essai avec les trucs vraiment, vraiment balèzes. C'est aussi lui qui est derrière
FFMPEG,
TCC, un mini-compilateur C, qui permet par exemple de compiler son
noyau Linux à la volée au démarrage de la machine, ou encore d'une
amélioration de l'algorithme de recherche de la n-ième décimale binaire de Pi.
Qemu est assez pratique, car en plus d'une émulation rapide, il est simple à configurer, s'interface avec
gdb, ce qui le rend plus agréable à utiliser que
Bochs.
Depuis quelques temps, j'étais abonné à la liste de développement de
Qemu, parce que j'ai corrigé un petit
bug, et que j'ai proposé une nouvelle
fonctionnalité. Je suis (du verbe suivre) donc les développements de loin.
Il y a un moment (j'avais mis un brouillon de ce billet de coté, j'y reviens seulement maintenant), Fabrice Bellard a annoncé la sortie d'un module supplémentaire :
kqemu. Il s'agit d'un module noyau qui permet apparemment de grandement accélérer l'émulation réalisée par Qemu. Jusque là, on peut se dire que c'est très bien !
Là où ça se corse, c'est que ce module est distribué sous une licence propriétaire : les sources ne sont pas disponibles. Fabrice Bellard ne l'avait pas annoncé, il a simplement
committé la chose, et certains développeurs ont alors
découvert directement dans le CVS la licence du module en question. Pas très fair-play. En plus, ce module a la licence propriétaire a été committé sur un CVS de Savannah, alors que les conditions d'utilisation précisent qu'il s'agit d'un hébergement pour des projets sous licence libre. Depuis, il a évidemment été retiré du CVS et hébergé ailleurs, et Fabrice Bellard a donné une
explication à la fermeture du code : il souhaite se faire sponsoriser par une entreprise pour rendre ce code libre. Un gigantesque débat opposant les gens comprennant la décision à ceux ne la comprennant s'en est suivi, générant un traffic important sur la liste.
On peut comprendre les raisons de Fabrice, mais on peut également trouver dommage qu'il soit obligé d'utiliser ce genre de chantage pour parvenir à se faire sponsoriser par une entreprise...
Personnellement, je n'ai pas testé le module en question, mais de nombreuses personnes sur la mailing-list ont reporté une grande accélération de l'émulation. En revanche, ça ne marche pas sur toutes les architectures, seulement x86 et x86-64... forcément, vu que personne ne dispose des sources, on a le même problème qu'avec les logiciels propriétaires classiques...
Brevets sur le logiciel
Tout le monde en parle, partout. Enfin, tout le monde, j'entends dans le cercle des informaticiens informés :
- La FFII, forcément ;
- LinuxFr, avec une news totalisant déjà plus de 400 commentaires. Le débat a beaucoup dérivé sur le Traité constitutionnel qu'on nous propose d'étudier en ce moment ;
- Même TF1 en parle et assez précisement qui plus est ;
- Tristan Nitot, après nous avoir lâché un gros Beuaaaark et annoncé la fermeture de son blog, a finalement continué avec un billet assez croustillant, une sorte d'éloge à l'ignorance. À la fois drôle, mais également tellement réaliste ... ;
- et plein d'autres que j'ai la flemme de lister ;-)
Sur un blog de ZDNet (et oui, de temps en temps, je lis ZDNet !), un certain
Cyril Fievet se demande si le brevet sur le logiciel va vraiment tuer l'innovation. Il avoue ne pas y comprendre grand chose (
J’avoue mal maîtriser le sujet, à la fois sur la forme [...] que sur le fond [...]), mais se positionne quand même, et annonce fièrement qu'il ne voit pas en quoi cela va tuer l'innovation. Effectivement, la FFII ne s'en prend dans beaucoup de ses critiques qu'à la
forme de la procédure. Mais pourquoi ? Parce que sur le fond, les députés européens sont déjà pour la plupart convaincus de la nocivité des brevets sur le logiciel. Maintenant, les seules méthodes utilisées par les pro-brevets sont des méthodes très liées aux procédures administratives. Donc la FFII en parle.
Il poursuit avec plusieurs remarques «intéressantes» :
- «D’abord, brevet ne rime pas avec interdiction, me semble-t-il. C’est même le contraire : le détenteur d’un brevet a tout intérêt à voir se généraliser l’utilisation de son invention, puisqu’il en perçoit alors des royalties.» : je me demande si il a entendu parler des Logiciels Libres ;
- «Ensuite, les brevets ne sont pas l’apanage des entreprises. Qui empêche un développeur de breveter son innovation et de bloquer ainsi par avance d’autres démarches purement commerciales ?» : je me demande si il connait le coût de dépôt et de maintien d'un brevet ;
- Selon lui, en informatique, les innovations ne sont pas forcément incrémentales. J'aimerais bien qu'il me cite une innovation qui ne l'est pas. Quelle innovation aujourd'hui n'utilise pas un compilateur, une interface graphique, une communication réseau ? Dans tous ces domaines, il y a des brevets ;
- «Il n’est pas inutile de rappeler que les brevets logiciels existent de longue date dans d’autres pays, à commencer par les Etats-Unis (software patents). A ma connaissance, cela n’a vraiment pas empêché l’innovation, ni le développement du plus gros marché mondial du logiciel.» : je me demande si il a entendu parlé des procès en tout genre pour contrefaçon de brevet. Exemples : Microsoft vs. Eolas, Apple vs Pat-Right. Comment une petite société pourrait-elle résister à de telles attaques ? D'autre part, les brevets coûtent cher, pas uniquement en dépôt, mais également en vérifications : il faut vérifier que l'on ne viole pas les brevets d'autrui, ce qui est une tâche très très délicate dans le cas d'un logiciel. D'ailleurs, les firmes comme Microsoft doivent employer de nouveaux experts en brevets. Donc au lieu d'embaucher de nouveaux ingénieurs de R&D, ils embauchent des spécialistes en brevets. Qui a dit frein à l'innovation ? ;
- «Quant au procès plus récent entre SCO et IBM, portant sur la possible réutilisation de code Unix dans son Linux, il semble bien patauger dans le manque de preuves, depuis deux ans déjà.» : certes, mais on parlait de brevets, pas de droit d'auteur, non ? Je crois qu'il met un peu tout ce qui est propriété intellectuelle dans le même sac, alors que les brevets n'ont rien à voir avec le droit d'auteur, ni avec le droit des marques ;
Toutefois, on lit quand même quelques réfléxions intéressantes :
«Dans les arguments avancés, on lit souvent qu’un brevet trop général pourrait avoir des conséquences dramatiques. C’est sans doute vrai. Mais cela ne doit-il pas simplement pousser à définir avec davantage de précision ce que recouvre un brevet ?» Bien sûr que si. Mais actuellement, c'est apparemment bien le dernier soucis de l'Office Européen des Brevets que de vérifier convenablement la validité des brevets enregistrés vis à vis des fameux trois critères d'inventivité, de nouveauté et d'utilité. Forcément, vu qu'il est payé au brevet accepté, ça créé un biais ...
À l'inverse de nombreux blogs, celui de
Lucas s'élève contre le
FUD de la FFII. Selon lui, la FFII pousse à voter «non» au traité constitutionnel, alors que tout le monde s'accorde à dire (y compris Fabius) que les nouvelles règles donneront plus de pouvoir au parlement. Comment le savoir ? Ce texte est tellement énorme, tellement complexe qu'il faut faire confiance à des soit-disants spécialistes. M'enfin, cette question fera l'objet d'un autre billet ;-)
Paquet Debian camlrpc et autres ...
Il y a
quelques temps, je racontais que j'avais commencé à faire des paquets Debian pour le projet
DemExp. J'avais commencé l'aventure par un paquet Debian
camlrpc, qui générait le paquet binaire
librpc-ocaml-dev. Il s'agit d'une bibliothèque permettant de réaliser des appels RPC depuis un programme écrit en OCaml. Depuis les premières versions de ce paquet, il s'est passé pas mal de choses.
Tout d'abord, j'ai réussi à compiler
DemExp en utilisant ce nouveau paquet, puis même à réaliser deux paquets pour
DemExp :
demexp-server,
demexp-client-gtk2, respectivement le serveur et le client en
Gtk2 pour
DemExp.
Ensuite, j'ai commencé à prendre contact avec les mainteneurs des paquets Ocaml dans Debian, au travers de la liste
debian-ocaml-maint et du channel du même nom sur IRC. C'est amusant de constater que quasiment tous les mainteneurs de paquets Debian Ocaml sont des français ou francophones. On sent que le
langage a des racines profondes dans son pays de création et de développement. J'ai d'ailleurs pu découvrir que
Dimitri Ara faisait partie de cette communauté, parce qu'il package son logiciel
ocamldsort. Vous devez certainement vous demander pourquoi je parle en particulier de Dimitri. En fait, Dimitri est la personne avec qui j'ai co-fondé le projet
KOS, comme vous pouvez le voir dans l'
historique du projet.
Revenons aux paquets Debian. La prise de contacts avec les développeurs a été très positive, ils m'ont tout de suite demandé de créer un compte sur
Alioth et m'ont ajouté au groupe des
mainteneurs de paquets Debian Ocaml. J'ai obtenu très rapidement l'accès en écriture au
dépôt Subversion du projet. J'ai alors pris connaissance de la manière dont sont structurés les paquets Debian dans ce dépôt. Seuls le répertoire
debian/ et l'archive orginelle du logiciel sont présents dans le dépôt. Ils utilisent un script spécifique,
opkg-buildpackage pour compiler automatiquement un paquet sous cette forme. Ce
opkg-buildpackage est simplement un wrapper pour
dpkg-buildpackage.
Une fois que j'avais bien mis en forme le paquet
camlrpc, j'ai pu l'
uploader dans le dépôt. Les développeurs m'ont alors fait diverses remarques au sujet du paquet, que j'ai prise en compte. Et le 5 mars, mon paquet était officiellement uploadé dans la
NEW queue, la file des nouveaux paquets. Dès qu'il sera traité par cette file, il entrera dans
Debian unstable !
D'ailleurs, à propos de cette
NEW queue, on m'a prévenu que le temps de traitement des paquets était particulièrement long en ce moment, souvent supérieur à un mois. Plusieurs développeurs s'en plaignent :
Nico Golde, sur
Planet Debian, et dans le cadre de l'élection du nouveau
Debian Project Leader, Sven Luther, un important packageur Debian du coté des paquets Ocaml, a
posté une question concernant précisement cette
NEW queue.
Parallèlement à cela, j'ai également travaillé sur le paquet Debian de
CDuce, un langage spécialisé dans le traitement de fichiers XML. Il est désormais utilisé par le projet
DemExp pour le stockage de la base de questions et de votes. Ce logiciel est assez spécial : pour être compilé, il a besoin des sources du compilateur Ocaml. Comme si un programme C avait besoin des sources de GCC pour se compiler ! En réalité, il n'a besoin que de certains fichiers objets des sources du compilateur, et un paquet Debian contenant déjà ces fichiers avait déjà été créé, il s'agit de
ocaml-compiler-libs. En reposant sur ce paquet, j'ai pu rapidement produire un paquet
CDuce fonctionnel, que j'ai d'ailleurs
uploadé dans le dépôt Subversion. Je l'ai ensuite utilisé pour produire les dernières versions des paquets Debian de
DemExp, et ça marche !
Jusqu'à aujourd'hui, CDuce n'était pas intégrable dans
main de Debian, car il était distribué sous une licence non-libre. Je viens tout juste d'apprendre que la sortie de la version 0.3.0 s'accompagne d'un changement de licence, pour une licence de type MIT. En fait, on le savait déjà, le changement de licence a en partie était demandé par les développeurs de
DemExp. J'ai donc de nouveau du travail pour compiler cette nouvelle version !
Pour finir, voilà la ligne à ajouter dans votre
/etc/apt/sources.list pour tester
DemExp :
deb http://thomas.enix.org/pub/debian/packages ./
Bon test !
Rss2email, vos flux RSS par e-mail
Depuis quelques temps, je me suis mis au truc à la mode : les
flux RSS. Pour ceux qui me lisent et qui ne savent pas ce que c'est,
RSS est un système qui vous permet d'être averti lors de la publication de quelque chose de nouveau sur vos sites préférés, et de lire ces nouvelles choses dans un unique lecteur tout intégré. Ainsi, tous les matins, au lieu de visiter les 250 sites que vous aimez, les nouvelles arrivent au fur et à mesure dans votre
agrégateur de flux RSS (c'est ainsi qu'on nomme le logiciel qui permet de lire des flux RSS). Les agrégateurs de flux RSS connus sont ceux intégrés à
Firefox et à
Thunderbird, ainsi que
Liferea.
Jusqu'à maintenant, j'utilisais Thunderbird, car il me sert également de client de courrier électronique. Pour mes courriers électroniques, c'est parfait, car j'utilise IMAP, donc où que je sois (maison, travail, ailleurs), j'ai accès à tous mes mails. Par contre, pour les flux RSS, c'est la galère, car ils ne sont pas partagés. Donc chez moi et au boulot, je n'étais pas inscrit aux mêmes flux, les attributs lus/non-lus n'étaient pas les mêmes. Bref pas cool.
Depuis un moment, je m'étais dit qu'il fallait écrire un petit script qui surveille les flux RSS et m'envoie un mail avec le contenu des nouvelles. C'est alors que je suis tombé sur l'idée de Lucas, qui proposait dans son blog de faire un
Agrégateur de RSS itinérant, en gros ce que je cherchais. L'avantage de ce que propose Lucas, c'est que les flux RSS sont directement balancés dans le serveur IMAP, ce qui permet de les classer automatiquement dans des dossiers.
Cependant, en attendant, j'ai voulu tester d'autres solutions. J'ai commencé par regarder du coté de
rss2mail, mais c'est écrit en Perl, et ça demande plein de modules Perl pour fonctionner, donc ça ne marchait pas sur
enix.org. Du coup, je me suis penché sur
rss2email, écrit en Python, et qui dépend juste d'un interpréteur Python.
Ça me convient plutôt bien. J'ai hacké un peu le machin pour pouvoir spécifier une adresse de
From: personnalisée pour les flux, ainsi qu'un nom personnalisé, ce qui permet de faire plus facilement le tri avec
procmail et fait plus joli dans le client de courrier électronique.
Néanmoins, il manque quand même des choses
- une interface de configuration graphique et jolie pour visualiser les abonnements aux flux RSS
- le tri automatique dans les dossiers. Pour cela, il faut causer directement au serveur IMAP au lieu d'envoyer des mails
Alors, Lucas, tu le fais quand ton agrégateur itinérant ?
Debian, des lents ?
Non, ce n'est pas un n-ième
troll sur la date de sortie de
Sarge comme vous pourriez le supposer d'après le titre. Non, c'est bien pire que ça.
À
Gulliver, nous installons plein de machines sous Debian GNU/Linux pour les gens qui le souhaitent. Souvent, certains reviennent quelques temps après en disant "tel logiciel ne marche plus" ou "tel périphérique ne marche plus". Souvent, nous suspectons une mise à jour, mais la personne ne se souvient en général pas de ce qui a été mis à jour, de ce qui a été installé et quand. Bref, nous avons pensé qu'il serait souhaitable d'avoir un
log de toutes les actions d'installation/suppression/mise à jour de paquet réalisées au travers de
dpkg.
Aujourd'hui, je me suis donc rapidement penché sur la question en regardant les sources de
dpkg, c'est écrit en C, et ça n'a pas l'air très gros. Il semblerait que la fonctionnalité puisse être implémentée assez rapidement. Le plus complexe étant de la tester, vu que
dpkg est un élément fondamental du système, se retrouver avec une version défectueuse peut être ennuyeux. M'enfin, avec un bon coup de
User Mode Linux, ça doit pouvoir se tester en toute sécurité.
Toutefois, avant de me lancer, je me dit qu'il vaut mieux déclarer la fonctionnalité en
wishlist sur le paquet
dpkg, ce qui permet de demander si c'est une fonctionnalité existante (et aussi de demander où se passe le développement de
dpkg, afin de récupérer la dernière version des sources et de pas répéter la connerie que j'ai faite avec
Weex). Je commence mon
reportbug, et je regarde ce qui est déjà reporté en
wishlist.
Et bingo, je tombe pile poil sur la fonctionnalité que je cherchais, dans un bug nommé
dpkg should automatically log everything. Ce bug est le bug numéro
957. Oui, oui,
957, alors qu'il y a largement plus de 200.000 bugs enregistrés dans Debian !
Il a été reporté le 7 juin 1995, soit il y 9 ans et demi. En 1998, un commentaire a été ajouté (automatiquement je suppose) pour dire que c'est un vieux, qu'il faudrait penser à le fermer pour la sortie de Debian 2.0. Le 8 juin 2004, au neuvième anniversaire du bug, quelqu'un a posté un patch pour implémenter la fonctionnalité attendue depuis presque la nuit des temps.
Et nous sommes le 13 février 2005, et à ma connaissance, la fonctionnalité n'est toujours pas implémentée dans dpkg, alors que c'est plutôt trivial à implémenter !
Woody est sortie le 19 juillet 2002, ça fait seulement 2 ans et demi. Quand je vous disais que j'avais trouvé pire !
Modes pour Emacs
Si vous utilisez Subversion, vous avez peut être envie d'utiliser le mode
Version Control approprié pour Emacs. Pour CVS, il est activé par défaut, mais pour Subversion, il faut ajouter la ligne suivante à votre
~/.emacs.el :
Ainsi, lorsque vous ouvrez un fichier qui est versionné grâce à un dépot Subversion, vous avez le numéro de la révision qui s'affiche au dessus du mini-buffer. En faisant C-x v v, vous pourrez commiter les modifications effectuées sur le fichier courant. Emacs vous demandera un message de commit, et avec C-c C-c vous validerez définitivement le commit. Si quelqu'un d'autre a modifié le fichier entre temps, il vous proposera de mettre à jour, et si il y a un conflit, vous proposera un mot
ultra-moumoutte pour résoudre les conflits. Vous pouvez également demander un
diff entre votre version courante et la version dans le dépôt pour voir ce que vous allez committer. Emacs permet alors de "désappliquer" certains éléments du
diff de manière simple.
A noter qu'il existe aussi le mode
psvn (il faut alors mettre
(require 'psvn)), mais je ne sais pas quelle est la différence, je ne l'ai pas testé.
Si vous écrivez du
LaTeX?, vous avez peut être envie d'utiliser un mode un peu plus évolué que le mode de base. Ce mode évolué s'appelle
auctex, et nécessite l'installation du paquet Debian
auctex (logique, non ?) pour fonctionner. Ce mode permet par exemple d'avoir des raccourcis clavier pour la mise en gras (
C-c f b), la mise en emphase (
C-c f e), la mise en caractères à chasse fixe (
C-c f t) ou des raccourcis pour démarrer une nouvelle section/sous-section. Il a un rendu un peu plus agréable que le mode normal, en mettant en police plus grosse les titres/sous-titres ce qui facilite la navigation dans le document. Seul reproche : il analyse le contenu des environnements
verbatim, et donc quand il y a un
$ au sein de cet environnement, tout part un peu en vrille. Ce problème est déjà
enregistré.
Comme pour
vc-svn, pour activer le mode
auctex, il faut ajouter la ligne suivante à votre
~/.emacs.el :
Il existe un autre mode qui a l'air
uber-tuning pour faire du
LaTeX? :
preview-latex. Je n'ai pas testé, mais apparemment, ça offre une sorte de rendu WYSIWYG directement dans Emacs. Ça peut être rigolo ;-)
Premiers paquets Debian
Il y a quelques semaines, j'avais travaillé avec
Fred et
David sur un paquet Debian pour
librpc-ocaml-dev. Ce paquet est nécessaire pour pouvoir compiler les logiciels de l'Expérience Démocratique.
Je me suis remis aujourd'hui sur ce projet, et j'ai donc généré le paquet
librpc-ocaml-dev, puis à partir de là, les paquets
demexp-server et
demexp-client-gtk2. Ils sont accessibles dans le répertoire
./pub/debian/packages. Si vous voulez les utiliser dans votre Debian, le plus simple est d'ajouter la ligne suivante à votre
/etc/apt/sources.list :
deb http://thomas.enix.org/pub/debian/packages ./
Les paquets ne sont peut être pas parfaits (il reste des
warnings relevés par Lintian), mais sur ma Debian unstable, ils fonctionnent.
Tout ça m'a permis de découvrir un peu les outils Debian pour la création de paquets. C'est relativement complexe, entre
dh_make,
dpkg-buildpackage,
pbuilder,
lintian et les formats des fichiers de configuration, on a un peu du mal à s'y retrouver. Il y a de la documentation, mais elle n'est vraiment, vraiment pas complète. Il y aurait du travail à faire de ce coté là.
Pour plus d'informations sur le projet de l'Expérience Démocratique :
http://www.demexp.org.
Ouverture du code de DTrace et économie du logiciel
A la mi-décembre,
je parlais d'un outil intéressant qui allait sortir avec Solaris 10,
Dtrace. Sun avait annoncé il y a quelques temps l'ouverture des sources de Solaris. Aujourd'hui, je
lis une nouvelle sur
SlashDot qui annonce l'ouverture du site
OpenSolaris.org. Je vais donc voir de quoi il s'agit, et qu'est-ce que je lis ? "
The opensolaris.org web site will be the center for OpenSolaris activity. Program content will be released in stages. The source code for one of the Solaris operating system's most advanced features – Dynamic Tracing (DTrace) is available here. We invite you to take a look. Expect to see buildable Solaris code here in Q2 2005.". Le code source de DTrace, l'outil de traçage de Solaris 10, est donc disponible. D'ailleurs
osnews.com l'annonçait déjà depuis quelques jours, mais vu que je ne lis pas osnews ...
Jusque là, rien de bien fabuleux. Que faire du code source de DTrace ? Là où ça devient intéressant, c'est quand on tombe sur le blog de Bryan Cantrill,
The Observation Deck. Bryan est un des développeurs de DTrace. Dans un dernier billet,
Solaris 10 Revealed, il annonce l'ouverture du code source de DTrace, et surtout donne quelques détails techniques sur le code source de DTrace, et des détails amusants qu'on peut trouver dans ce code et dans les commentaires. Parfois un peu technique, mais intéressant tout de même. Là où ça devient vraiment génial, c'est lorsqu'on lit son billet
Demo'ing DTrace qui explique comment il fait une démonstration de DTrace. Il part d'un système en éxécution, puis de fil en aiguille, il trouve qu'un processus fait des choses étranges. Je vous laisse lire la suite pour en savoir plus, ça se lit presque comme un romain ;-)
D'ailleurs, ce monsieur ne parle pas que de technique, mais aussi d'autres choses intéressantes. Dans un autre billet,
The economics of software, il explique quelle est la différence fondamentale entre un logiciel et les autres biens de consommation au regard des lois de l'offre et de la demande, et explique selon lui quelles sont les stratégies des éditeurs de logiciels pour faire face à ces différences. Tout ça pour conclure que dans de nombreux domaines, les logiciels
OpenSource font forcément percer au bout d'un moment. C'est une explication peut être un peu libérale du succès du mouvement
OpenSource, mais ça n'en reste pas moins très intéressant. Suite aux commentaires, il revient sur ce sujet dans un autre billet,
The Economics of Software, redux.
Backup des fichiers personnels
De nos jours, les disques durs deviennent de plus en plus gros, mais j'ai aussi l'impression qu'ils deviennent de moins en moins fiable. La seule solution pour être sûr de conserver ses données sur le long terme, c'est d'utiliser une stratégie de duplication. Dans l'attente de faire quelque chose de propre avec du RAID5, j'ai mis en place une procédure de sauvegarde utilisant
rsync. La sauvegarde se fait depuis ma machine de travail vers mon serveur, et ce à chaque fois que j'éteins ou que je redémarre ma machine perso. En effet, j'éteins toutes les nuits mes machines (économies d'électricité, moins de bruit), donc je suis sûr qu'au moins une fois par jour, mes données sont sauvegardées.
Dans mon répertoire personnel sur ma machine de travail, j'ai un script
synchronize.sh, qui se charge de réaliser la synchronisation proprement dite en faisant appel à
rsync :
#!/bin/sh
export RSYNC_PASSWORD=le-mot-de-passe-rsync
rsync -avuz --delete --exclude '*~' ~/ rsync://thomas@gate.kos.nx/tombackup
Comme vous pouvez le constater, je ne fais pas passer
rsync au travers de
ssh : le serveur étant une machine peu puissante, je ne veux pas l'encombrer d'opérations de cryptage/décryptage, et de toute façon, comme je suis sur un réseau privé avec seulement ces deux machines, cela ne pose pas de problèmes de confidentialité.
Sur le serveur, il faut également avoir
rsync installé, puis mette en place un fichier
/etc/rsyncd.conf :
pid file=/var/run/rsyncd.pid
[tombackup]
comment = Backup Thomas
path = /home/thomas/home_backup/
use chroot = yes
lock file = /var/lock/rsyncd
read only = no
list = no
uid = thomas
gid = nogroup
auth users = thomas
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = gate.kos.nx crazy.kos.nx
hosts deny = *
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 600
refuse options = checksum dry-run
dont compress = *
Cela créé un "module" (dans la terminologie
rsync) qui s'appelle
tombackup. C'est le nom de ce module qu'on retrouve dans l'URL
rsync du script
synchronize.sh. On doit donner un commentaire pour ce module, le chemin et on précise qu'il est en lecture écriture (
read only = no). On demande à rsync de ne pas le lister lorsque la liste des modules est demandée (
list = no), on précise avec quels
uid et
gid le
rsync doit tourner, et que seul l'utilisateur
thomas est autorisé à se connecter. Les mots de passe sont stockés dans un fichier
/etc/rsyncd.secrets. On précise également que aucun hôte n'est autorisé à se connecter (
hosts deny = *), sauf le serveur et la machine de travail (
hosts allow = gate.kos.nx, crazy.kos.nx). Enfin, quelques options qui étaient là par défaut. Il reste
dont compress = *. Normalement, cette directive sert à ne pas compresser les fichiers déjà compressés (.tar.gz, .tar.bz2, etc..), mais finalement, vu que j'ai une bande passante suffisante, je n'ai pas jugé inutile de perdre du temps processeur à compresser les données avant le transfert et à les décompresser après.
Le fichier
/etc/rsyncd.secrets contient une liste des noms d'utilisateurs avec leurs mots de passe. Évidemment, on préfèrera rendre ce fichier lisible uniquement par root (
chmod 600) :
thomas:le-mot-de-passe-rsync
Enfin dernière chose pour activer le serveur
rsync : ajouter la ligne qui va bien dans
/etc/inetd.conf. Comme cela est expliqué dans la documentation de
rsync, il suffit d'ajouter :
rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon
Il est maintenant possible de lancer
synchronize.sh pour faire la synchronisation de mon répertoire personnel avec le serveur. Toutefois, on souhaite automatiser la procédure de manière à ce qu'elle s'effectue à chaque extinction ou redémarrage de ma machine personnelle. On créé donc un petit script
/etc/init.d/backup :
#!/bin/sh
echo -e "\e[31mBackup Thomas home ...\e[m"
su thomas -c 'cd $HOME ; ./synchronize.sh'
Et on ajoute les liens symboliques qui vont bien dans
/etc/rc0.d (répertoire utilisé lors d'un
halt) et
/etc/rc6.d (répertoire utilisé lors d'un
reboot). Il faut lancer le script assez tôt pendant la désinitialisation, pour avoir encore le réseau et tous les services qui tournent. Chez moi, j'ai mis le script au niveau
K09.
Maintenant que cela est fait, nous voulons le fin du fin : que l'extinction de la machine de travail provoque non seulement le backup, mais également l'extinction du serveur. Évidemment, ce n'est pas souhaitable si l'on veut laisser le serveur allumer 24/24, mais vu que j'éteins systématiquement mes machines, ça permet d'éteindre automatiquement les deux en faisant juste un joli
Éteindre cet ordinateur dans mon GDM préféré.
Il faut donc se logger en
ssh sur le serveur et y éxécuter la commande
halt, mais sans que cela ne nous demande de mot de passe. Nous allons donc utiliser une clé
ssh spécifique, sans phrase de pass.
Crééons cette clé dans le répertoire personnel sur la machine de travail, en donnant une phrase de pass vide.
ssh -t dsa -i ~/.ssh/haltgatekey
Ensuite, on copie la clé publique dans le fichier
~/.ssh/authorized_keys du répertoire personnel de
root sur le serveur pour autoriser de se logger avec cette clé. Néanmoins, comme on ne veut pas que celui qui possède la clé puisse faire n'importe quoi, on ajoute des attributs à la clé qui précisent que cette clé ne permet pas d'obtenir un terminal, et qu'elle permet seulement d'éxécuter la commande
halt. L'éxécution de tout autre commande provoquera un échec. Voilà à quoi doit ressembler le
~/.ssh/authorized_keys sur le serveur :
command="halt",no-pty ssh-dss LA_CLE_EST_ICI thomas@crazy
Il suffit maintenant de modifier le script
/etc/init.d/backup pour qu'il lance la commande
halt sur le serveur avant de poursuivre :
#!/bin/sh
echo -e "\e[31mBackup Thomas home ...\e[m"
su thomas -c 'cd $HOME ; ./synchronize.sh ; ssh -i ~/.ssh/haltgatekey root@gate halt'
Et voilà, le tour est joué ! Avec l'ACPI bien configuré sur les deux machines, il suffit de demander à GDM d'éteindre la machine de travail, et hop on peut aller dormir, tout se fait tout seul, jusqu'à l'extinction physique des machines. La synchronisation de mon répertoire personnel est assez longue (plus de 100.000 fichiers), donc c'est pratique de ne pas avoir à attendre.
Outils pour blogs
Au détour d'un
blog d'une personne de chez
Gnome, j'ai découvert qu'il existait des applications permettant de poster des billets sur des blogs, sans passer par une page Web. Le blog en question parle de
Gnome Blog, un outil pour Gnome permettant de poster des billets sur différents types de blogs. En particulier, il permet de poster des billets sur des moteurs de blogs respectant certaines APIs : la
metaWebblogAPI et la
bloggerAPI.
D'après un
article de kuro5hin.org, ces APIs ne sont pas parfaites, mais je trouve ça intéressant quand même ;-)
Graver en Gtk 2
Depuis pas mal de temps, j'étais à la recherche d'un logiciel de gravure bien conçu et convivial en Gtk 2, et je n'en trouvais pas. En logiciel de gravure sous GNU/Linux, il existe déjà :
- L'excellent K3B, vraiment convivial, vraiment bien foutu. Mais pour les "intégristes" comme moi, ce logiciel n'est pas acceptable, car il faut installer la bibliothèque Qt. Horreur et damnation ;-)
- X-CD-Roast déjà nettement moins sympathique, et en Gtk 1, mais toujours maintenu
- Gtoaster un vieux machin en Gtk 1, plus maintenu depuis 2002. La dernière version dans Debian unstable est la 0.2002083100+1.0Beta6-2.1, c'est dire !
- L'infame et horrible Gcombust, avec sa très laide interface en Gtk 1 avec des dizaines (des centaines ?) de boutons partout, des fenêtres qui s'ouvrent dans tous les sens. Bref, inutilisable. D'ailleurs tellement moisi que le mainteneur du paquet Debian a décidé de laisser tomber
Personnellement, j'utilise un script shell maison à base de
mkisofs et de
cdrecord qui me grave le contenu du répertoire courant. Il est vraiment basique. D'ailleurs tellement basique qu'il ne vérifie pas que la taille des fichiers dans le répertoire rentre sur le CD, et donc il démarre la gravure, et une fois qu'il n'y a plus de place sur le CD,
cdrecord m'envoie des injures pas très sympathiques pour me dire qu'il n'y a pas assez de place sur le CD ! Bref, c'est assez rustique comme technique, et j'aimerais avoir un truc un peu plus user-friendly. En plus, avoir un bon logiciel de gravure en Gtk 2, c'est pratique, comme ça j'aurai un logiciel à conseiller aux gens chez qui j'installe GNU/Linux !
Tout récemment, j'ai découvert lors d'un tour sur
Je Suis Libre un logiciel appelé
Graveman !. Le projet consiste à développer un logiciel de gravure en Gtk 2, et les screenshots sont sympathiques. Pour l'instant, le projet n'en est qu'à ses balbutiements : page Web sommaire, pas de mailing list, pas de CVS, mais c'est certainement une très bonne base.
J'ai compilé la chose chez moi et ai découvert un petit soucis lors de la compilation. J'ai donc envoyé un petit patch au mainteneur, ce qui permettait de tester sa réactivité et de le pousser à ouvrir un CVS. Il m'a effectivement répondu aujourd'hui, mais les modifications proposées par mon patch avaient déjà été intégrées ... ce qui m'a permis de le pousser de nouveau à ouvrir un CVS ! ;-)
Voilà, donc je pense que je vais tester fréquemment ce petit logiciel, éventuellement rapporter des bugs, voire peut-être contribuer, qui sais ?
Et vous vous utilisez quoi comme logiciel pour graver ?
Sinon, dernière question métaphysique avant de partir : à votre avis, en français, on doit dire "reporter un bug" ou "rapporter un bug" ?
Fire Starter
Les personnes venant du monde Windows et du monde des firewalls graphiques sont souvent désorientées par le mécanisme de configuration du firewall de Linux,
Netfilter. Il faut y aller à gros coup de lignes de commande aux options tarabiscotées et à coup de script shells pas forcément évidents à mettre en place.
En fait, il existe une interface graphique qui a l'air assez aboutie : elle s'appelle
FireStarter. Même si le site est en
.com (ce dont je me méfie toujours, je ne sais pourquoi), le logiciel est bien distribué sous les termes de la licence
GPL et est
packagé dans Debian Sid. Cette interface graphique en Gtk qui s'intègre apparemment bien à Gnome permet de contrôler le firewall de la machine locale.
De plus, on peut être informé en temps réel des tentatives bloquées de connexion, pour éventuellement agir en conséquence, un peu à la mode des boîtes de dialogue qui apparaissent subitement sous Windows pour dire qu'une connexion sur un port fermé a eu lieu et qui ont deux zolis bouton : un rouge pour dire "non c'est un méchant", ou un vert pour dire "c'est bon, c'est un gentil" ;-)
Je n'ai pas testé le logiciel, donc je ne sais pas ce que ça vaut, mais ça serait intéressant de tester. J'ai regardé rapidement les sources, j'ai l'impression que le logiciel génère des gros scripts shells pour commander iptables. Donc à priori, il faut que le logiciel s'éxécute sur la machine qui fait firewall, mais c'est à vérifier. Il serait pourtant intéressant qu'on puisse commander à distance un firewall.
Je ne suis pas spécialement fan des interfaces graphiques, mais je pense que la ligne de commande et en particulier les options d'
iptables font fuir pas mal de gens, et si ce type d'outil peut favoriser l'adoption du Logiciel Libre chez M. Tout Le Monde, c'est tant mieux !
Des cours de sécurité étonnants
Vu sur
Slashdot, une news plutôt intéressante intitulée
DJB Announces 44 Security Holes In *nix Software. Pour ceux qui ne connaissent pas, DJB n'est autre que DJ Bernstein, développeur de DJBDNS, un serveur DNS conçu pour la sécurité, mais qui est malheureusement distribué sous une licence non-libre.
Ce DJB s'occupe d'un
cours de sécurité intitulé "UNIX Security Holes". Comme on peut le voir dans les slides, durant les cours il est question des problèmes de sécurité classiques lors du développement d'une application sous Unix (buffer overflows, etc...). Mais le plus intéressant est sur la page 7 des
premiers slides du cours : 40% de la note de l'UV est constituée de la note aux examens, alors que 60% est constitué à un travail personnel qui consiste à trouver 10 failles de sécurité dans des applications Unix et d'écrire les exploits correspondants. Oui, tout à fait, dans le cadre d'un cours à l'université, DJB demande à ses étudiants de rechercher des failles de sécurité, et le résultat des étudiants à cette UV dépend de leurs trouvailles. DJB annonce que si ses 40 étudiants trouvent 10 failles de sécurité, alors 400 failles de sécurité seront découvertes, ce qui est quand même pas mal.
La news de
Slashdot relate que cette année, les 25 étudiants n'ont trouvé que 44 failles de sécurité. Elles ont bien évidemment été
toutes communiquées aux auteurs des logiciels impliqués. L'auteur de la news a trouvé 2 failles de sécurité seulement, et doute que cela soit suffisant pour obtenir l'UV !
Voilà de vrais TPs, en situation réelle, au cours desquels on doit apprendre pas mal de choses. Peut-être que certaines écoles, dont l'
UTBM devraient s'en inspirer...
Partage de liste de flux RSS
Au boulot comme à la maison, j'utilise
Mozilla Thunderbird pour lire mon courrier électronique et suivre des flux RSS. Grâce à IMAP, je partage très simplement mon courrier électronique entre le Thunderbird du boulot et celui de la maison. J'ai les mêmes mails, les mêmes dossiers, les mêmes attributs lus/non-lus. Bref c'est parfait.
Par contre, pour la liste des flux RSS et l'état lu/non-lu des billets des divers flux, je ne sais pas comment partager ça entre le boulot et chez moi. Existe-t-il une solution ? Y'a-t-il des protocoles de partage de liste de flux RSS ?
KOS : Motivation trouvée
Ce soir, j'ai trouvé un peu de motivation pour travailler sur KOS : j'ai finalement codé la macro
EXPORT_FUNCTION_RESTRICTED qui permet de restreindre l'accès à des symboles exportés à certains modules seulement. Bon, c'est assez technique, mais pour celui qui s'intéresse à KOS, c'est intéressant. (Edit:
voilà le mail que j'ai envoyé sur la liste de développement de kos et qui explique tout).
Il reste deux grands chantiers en cours : la VMM et le portage sur MIPS. Ce sont des travaux de longue haleine, et parfois, le soir, j'hésite à rentrer dedans, car une soirée laisse trop peu de temps pour entrer à fond dans les problèmes. Mais pas le choix, il va falloir se forcer un peu, surtout que quand ça marche, il y a de quoi être satisfait !
Bon, pas le temps de bosser sur KOS ni demain soir (je vais suivre un atelier sur GIMP à
Gulliver) ni ce week-end, je rentre à
Méridon ! La suite des aventures la semaine prochaine donc !
DTrace : un outil intéressant de Solaris 10
Un
journal un peu trollesque sur
LinuxFr a attiré mon attention sur Solaris 10 et en particulier sur l'outil
DTrace. L'auteur du journal compare ça à un bête
strace. En fait, en y regardant de plus près, ce n'est pas du tout ça, et les gens de chez Sun ont une nouvelle fois fait un truc vraiment intéressant.
En résumé, il s'agit d'un système d'instrumentation dynamique. Ce système permet d'avoir des informations sur ce qui se passe aussi bien au niveau des applications utilisateur que du noyau. Ce qui est assez fort c'est que pour récupérer ces informations, il n'est pas nécessaire de recompiler ou même de relancer les applications ou le système : l'instrumentation est entièrement dynamique. En gros, si on trace une fonction, alors en entrée et en sortie de fonction, DTrace va remplacer une instruction de la fonction par un appel au système de traçage qui va faire ce qu'il a à faire puis éxécuter l'instruction qui a été remplacée.
En plus de cette instrumentation dynamique des fonctions, DTrace propose aussi de l'instrumentation statique, le traçage des locks, des appels systèmes mais aussi le profiling.
Comme le traçage génère souvent beaucoup d'informations, DTrace permet à l'utilisateur de décrire les évènements qu'il souhaite matcher et de donner les actions à réaliser lorsqu'un évènement est matché. Un exemple tout bête, sorti du papier :
syscall::read:entry
{
self->t = timestamp;
}
En gros, lorsque l'appel système
read va être appelé, le timestamp courant va être noté dans une variable locale au thread (tout ça est géré par DTrace). En sortie d'appel système, on pourra faire de même pour savoir combien de temps on a passé dans l'appel système
read. Sympathique quand même ?
Le langage en question est une sorte de C amélioré pour pouvoir faire plein de choses simplement comme l'aggrégation. Par exemple, il est possible de compter le nombre d'appels à un appel système donné, ou de compter le nombre d'appels système
write réalisés par une application en les classant par taille du buffer à écrire.... (Exemples issus également du papier).
Évidemment, tout ça est possible dans les applications utilisateur et dans le noyau, le passage de l'un à l'autre se faisant de manière complètement transparente. On peut donc avoir un graphe d'appel d'une fonction d'une application utilisateur qui va jusque dans le noyau, puis repasse dans l'espace utilisateur. (Voir le papier pour la démonstration).
Et enfin, il y a la spéculation. En gros, vous voulez récupérer des informations sur les appels à un appel système, mais seulement quand celui-ci foire (retourne -22 par exemple). Le problème c'est qu'au moment où l'on sait qu'il va retourner -22, l'appel système est terminé, et c'est trop tard pour sauvegarder des informations sur son déroulement. Par contre, si on sauvegarde le déroulement de tous les appels systèmes, on va avoir une énorme quantité de données. DTrace permet de sauvegarder les données dans un coin, puis une fois l'appel système terminé de décider si il faut ou non conserver les données de coté.
Bref, c'est vraiment intéressant tout ça. Le système est prévu pour être extensible et ne pas poser de problèmes de sécurité ou de corruption, de manière à ce qu'il soit utilisable dans un environnement de production.
Sources :
KOS, que faire ?
KOS a démarré en juin 1998. A l'époque, j'étais en seconde, et maintenant je termine mes études d'ingénieur. Autant dire que beaucoup de choses ont changé depuis les débuts. J'ai énormément appris de ce projet, en particulier grâce et avec Julien Munier et David Decotigny. Avec ce dernier, nous avons démarré un autre projet,
SOS qui consiste à rédiger une série d'articles pour Linux Magazine France concernant le développement d'un petit OS simplissime.
Avec ce projet, les activités professionnelles des uns et des autres, KOS n'a pas bougé depuis le mois de janvier 2004, et la motivation n'y est plus. Pourtant, depuis le mois de septembre, j'ai entrepris deux grands travaux :
- une refonte complète de la gestion de la mémoire physique et de la façon de mapper et de démapper les pages en mémoire virtuelle. Cette refonte était nécessaire pour permettre la mise en place de la synchronisation (protection contre les accès concurrents) dans la partie gestion de la mémoire virtuelle. Malheureusement, personne n'a relu mon patch, il n'est toujours pas dans le CVS et je n'ai pas eu le courage/temps de poursuivre le travail pour terminer avec la refonte de la VMM;
- un début de portage sur MIPS, avec un loader qui fonctionne, reloge les modules et lance le module principal. Mais le plus gros reste à faire : arriver à démarrer un petit bout de KOS avec quelques modules. Comme KOS n'a jamais été porté, il y a pas mal de bazar dépendant de l'architecture un peu partout, voire même des mécanismes carrément dépendant de l'architecture Intel. Bref, ce n'est pas une tâche évidente.
Ce soir, j'ai commencé une petite bidouille consistant à ajouter un système de restriction dans l'export des symboles vers d'autres modules. En gros, l'idée est qu'au lieu qu'un symbole soit soit visible de tous les modules, soit invisibles des autres modules, qu'il soit visible pour un ou plusieurs modules seulement. La bidouille a commencé, mais je me suis aperçu que KOS ne fonctionnait pas quand il était compilé avec GCC 3.4.
Pour tout ça, manque de motivation, trop de fatique, manque de temps. Peut-être que le manque de motivation est du à l'absence de vie au sein du projet. Quelques nouveaux développeurs ne feraient pas de mal. Mais le travail déjà accompli est déjà suffisamment important pour qu'il soit difficile de se plonger dedans, et cela en décourage plus d'un.
Que faire avec KOS ? Laisser tomber ? Laisser tomber ce projet avec lequel j'ai tout démarré, tout appris ? Ou bien persévérer en essayant de maintenir en vie un projet sous perfusion et respiration artificielle ?
Beep media player
Ceux qui utilisent encore
XMMS et qui en ont marre des fenêtres de configuration en Gtk 1 peuvent tester
Beep Media Player. Ça fonctionne exactement comme XMMS, ça peut utiliser les Skins de XMMS ou Winamp, sauf que toute l'interface de configuration, d'ouverture de fichiers est en Gtk 2, donc c'est plus joli et plus utilisable.
Allez hop, faites tous un
apt-get install beep-media-player
Et bonne utilisation !
Flux RSS
Ça y est, c'est fait, j'ai rejoint le monde des bloggeurs qui utilisent des flux RSS. Celui de mon blog est disponible à l'adresse
http://thomas.enix.org/rss. N'étant pas un spécialiste du RSS, il est possible que celui-ci ne soit pas tout à fait conforme ou ne fonctionne pas avec certains outils. N'hésitez pas à me dire si vous constatez des problèmes. En tout cas, dans Thunderbird et dans Liferea, ça fonctionne.
Pour ceux qui ne connaissent pas, RSS permet d'être "averti" lorsqu'un nouveau billet est posté ou lorsqu'une nouvelle news est publiée sur un site. Pour pouvoir utiliser ces flux RSS, il faut disposer d'un logiciel qui sait les lire, comme par exemple Liferea ou Thunderbird. Il faut ensuite ajouter les flux RSS que vous voulez consulter, et automagiquement, lorsqu'un nouveau billet sera posté, votre lecteur RSS vous avertira et le marquera comme non lu. C'est vraiment très pratique pour suivre de nombreux blogs sans aller visiter tous les jours tous les blogs qu'on souhaite lire.
Alors
Lucas, content ?
Gnome Meeting, la suite...
J'utilise maintenant quotidiennement
GnomeMeeting depuis environ une semaine. J'ai été étonné de constater que sur une liaison ADSL Free 2048/128, il est possible de faire de la Webcam et d'utiliser en même temps les fonctionnalités téléphoniques de la Freebox. Étonnant avec les maigres 128kbit/s d'upload disponibles. La Webcam prend environ 5 Ko/s pour la vidéo plus 1.5 Ko/s pour le son. Ce n'est pas énorme, mais quand même.
Cependant, il y a des trucs bizarres. Parfois, quand on établit la connexion, il n'y a que le son, ou que l'image, ou alors que le son dans un sens, et l'image dans l'autre sens. On a eu à peu près toutes les combinaisons possibles. En rappelant 2, 3, 4 ou 5 fois, on arrive toujours à avoir une configuration dans laquelle on a le son et la vidéo dans les deux sens. J'ai l'impression que dans certains cas il tombe sur un port UDP qui n'est pas ouvert d'un coté ou de l'autre. Pourtant, les firewalls sont bien configurés, et
GnomeMeeting a été configuré convenablement dans
gconf-editor (on peut y bricoler les ports utilisés).
On a également testé au travers d'un tunnel TCP avec
vtun. Ca semble marcher un peu moins bien que sans le tunnel, ce qui est peut être lié au fait qu'un tunnel TCP n'a pas les mêmes caractéristiques au niveau retransmission de paquets que les liaisons UDP utilisées par défaut dans
GnomeMeeting.
Bref, ça marche, mais faudrait investiguer le problème pour que ça fonctionne à tous les coups. Pour ça, il faut recompiler
GnomeMeeting, ce qui veut dire qu'il faut installer moultes moultes bibliothèques de développement. Bref, la flemme ;(
Gnome Meeting, ça marche !
Après les tests de
GnomeMeeting sur un réseau local sans firewall, j'ai pu tester l'utilisation de
GnomeMeeting à travers deux firewalls. En effet, ma machine est située derrière un serveur personnel faisant office de firewall, et la machine de ma copine est également située derrière un firewall.
Depuis la version 0.94,
GnomeMeeting supporte le NAT si des redirections de ports convenables du firewall vers la machine faisant tourner
GnomeMeeting sont mises en place. Cette configuration est très bien détaille sur la
FAQ de GnomeMeeting. Nous avons effectué les manipulations sur les deux firewalls, et hop,
GnomeMeeting a fonctionné du premier coup.
La vidéo, le son, tout fonctionne. La qualité du son est tout à fait convenable, on comprend très bien son interlocuteur. La vidéo est assez lente, mais c'est quand même bien sympathique de pouvoir voir son amie à des centaines de kilomètres de distance !
Voilà, donc
GnomeMeeting ça marche !
User Mode Linux et paquets Debian
Il y a
quelques temps, j'avais parlé de
http://user-mode-linux.sf.net sur ce blog. Je me suis remis dessus récemment, puisque je voulais tester un paquet Debian que nous avons créé avec David Mentré et Frédéric Lehobey sans l'installer sur mon système. En effet, comme c'est notre premier paquet Debian, il y avait des chances pour qu'il soit foireux.
J'ai donc commencé à reprendre UML. Je suis reparti du
root_fs Debian Woody fourni sur le site de UML, que j'ai essayé d'upgrader en
sarge, puisque c'est pour cette distribution que le paquet a été prévu. Or, pour une raison obscure, le
dist-upgrade se foirait sur la mise à jour de la libc avec une étrange assertion incompréhensible. Bref, ça ne fonctionnait pas.
J'ai donc décidé de créer un
root_fs pour Debian Sarge. Évidemment, je n'ai pas fait ça a la main, j'ai utilisé un outil formidable :
rootstrap. Après moultes péripéties, j'ai réussi à obtenir un
root_fs fonctionnel, que vous
pouvez télécharger. J'en ai profité pour écrire un petit HOWTO sur comment ça se déroule :
HowtoRootStrap. D'ailleurs, je viens de voir qu'il était déjà à la 4ème place dans Google pour la recherche
rootstrap uml.
Résultat, j'ai pu tester le paquet Debian que nous avions créé. Pour information, ce paquet est
librpc-ocaml-dev, c'est une bibliothèque de développement pour Objective Caml qui permet de faire des RPC. En fait le but est de packager le logiciel de l'
Expérience Démocratique qui a besoin de cette bibliothèque. Le paquet pour Sarge, totalement expérimental, est
disponible. Je l'ai testé dans UML, et il s'installe parfaitement dans une Sarge.
Ensuite, j'ai testé la compilation du logiciel de l'Expérience Démocratique dans UML avec ce paquet installé. La compilation s'effectue correctement, ce qui signifie que Objective Caml a bien trouvé la bibliothèque RPC. En revanche, le serveur de l'Expérience Démocratique se vautre lamentablement avec un
Segmentation Fault lorsqu'on le lance. Je n'ai pas encore déterminé si c'était lié à UML ou non. D'une manière ou d'une autre, c'est sûrement le cas, parce que sur ma machine, il fonctionne parfaitement.
Tout cela m'a également fait découvrir la façon dont on créé un paquet Debian. Brièvement, je vais citer quelques outils utilisés pour donner quelques pistes aux éventuels lecteurs. Tout d'abord, l'outil
dh_make (paquet Debian
dh-make) permet de créer dans les sources originales le répertoire
debian avec les fichiers par défaut, ansi que les fichiers
.orig.tar.gz et
.dsc. A partir de là, il faut modifier
debian/control pour y mettre la description et les dépendances du paquet, puis
debian/rules pour indiquer comment le paquet se compile et s'installe. Dans notre cas, c'était à la fois simple puisque nous avions des exemples, mais pas évident, puisque la compilation de la bibliothèque Objective Caml n'utilise pas le simple triplet
./configure && make && make install. Il a donc fallu un peu bricoler, s'inspirer d'autres
debian/rules pour obtenir quelque chose de satisfaisant et fonctionnel. Une fois ceci terminé, on peut construire le paquet en utilisant
dpkg-buildpackage. Toutefois, il existe un paquet encore plus fort :
pbuilder. En utilisant la commande
pbuilder create vous allez créer un tarball contenant un système Debian minimal. Puis en utilisant
pbuilder build paquet vous allez lancer la construction de votre paquet au sein du sous-système
pbuilder (en fait c'est une Debian chrooté). Ceci permet de vérifier que les dépendances de compilation du paquet (
Build-Depends) sont correctes, et que celui-ci se compile bien dans un environnement sain. C'est assez fort comme outil.
Ensuite, pour tester, soit vous utilisez directement votre machine, soit vous utilisez un sous-système UML !
Webcam, ça marche !
Il y a environ un mois, ma copine a reçu sa webcam
Logitech QuickCam Zoom (Refresh). J'avais donc essayé de la faire fonctionner à distance, mais rien n'y faisait, aussi bien l'
ancien driver que le
nouveau driver ne fonctionnait pas. J'avais alors commencé à triturer le driver pour voir où était le problème, j'avais contacté l'auteur du driver, Luc Saillard, un français, mais je n'avais rien trouvé de probant.
La semaine dernière, j'étais à Belfort, et j'ai donc pu me pencher plus précisement sur cette Webcam. En fait, après d'autres recherches infructueuses dans le code source du module dans lequel j'avais rajouté moultes messages de debug, j'ai finalement trouvé la solution sur un
forum tchèque ! Au milieu d'un charabia incompréhensible pour moi, j'ai vu que la personne utilisait les options
power_save=1 compression=1 leds=250,250 trace=128 size=vga pour le module
pwc. J'ai donc testé avec ça, et ça a fonctionné !
Par élimination, j'ai trouvé que c'était le paramètre
power_save qui changeait tout. J'ai donc écrit un
petit patch qui active par défaut le
power_save sur ce modèle de Webcam, de manière à ce que le driver fonctionne
out-of-the-box pour les autres.
Une fois ceci fait, il restait à configurer le micro intégré. Je n'avais absolument aucune idée de comment ça fonctionnait. Je me suis baladé dans les options du noyau, et j'ai découvert le module
snd-usb-audio dans la configuration d'ALSA. Il a suffit de compiler et d'insérer ce module pour que magiquement le micro fonctionne. Le volume est réglable en utilisant
alsamixer -c 1 (le micro est considéré comme une carte son avec juste une entrée), et le micro est directement détecté par
GnomeMeeting comme un périphérique d'entrée son.
Avec tout cela, nous avons pu faire des tests avec deux Webcams et deux
GnomeMeeting sur deux ordinateurs reliés par un réseau local. Cela fonctionne très bien, et utilise environ 1.5 Ko/s de bande passante pour le son et 6 à 8 Ko/s pour la vidéo. J'espère pouvoir tester dans les prochains jours le fonctionnement au travers d'une liaison ADSL et derrière des firewalls !
Encore des hacks sur Wikini et une réflexion ...
Hier, je me suis enfin décidé à mettre en ligne toutes les photos que j'avais du
Château de Méridon. Tout d'abord, il a fallu trier et sélectionner des photos parmi les 550 Mo que j'avais. A grands coups de commandes shell, on les renomme, on les redimensionne, on les déplace dans tous les sens. Voilà, j'ai 199 photos, avec 3 versions :
big, en taille originale,
medium en 800x600 et
small en 120x90. Les photos en taille originale font 405 Mo, les photos en taille
medium et
small ne font que 55 Mo ;)
Maintenant, il faut placer tout cela sur le site qui est un
Wikini. Or il n'y a rien de prévu pour faire des galeries. Je reprends donc du code HTML et CSS du site de
Lolut (merci
Bouil !), et je hacke Wikini pour permettre l'intégration de galleries.
Maintenant, il suffit de faire :
-----
{{{./chemin/image/en/grand.jpg ./chemin/image/en/petit.jpg Legende en plusieurs mots}}}
{{{./chemin/image/en/grand2.jpg ./chemin/image/en/petit2.jpg Patati}}}
-----
Pour faire une galerie d'images pas trop moche, comme on peut le voir sur
http://www.meridon.com/PhotosChateauRezDeChausseeFr. Toutes les galeries d'images sont sur
http://www.meridon.com/PhotosChateauFr
Wikini, on peut en faire vraiment plein de choses, et j'aimerais bien avoir une version qui intègre les galeries photos, l'upload de documents, la gestion des groupes, les blogs, les flux RSS. Le problème, c'est que si on intègre plein de choses dans Wikini, celui-ci va perdre une de ses caractéristiques fondamentales : sa simplicité. J'aimerais vraiment trouver un système modulaire qui permettent de plugger ces différentes fonctionnalités de manière propre dans un Wikini de base. Seulement, la nature de toutes ces fonctionnalités est tellement variée que je me demande s'il est possible de construire une architecture modulaire pour permettre tout ça.
Bref, du coté des Wiki, il y a des choses à faire, mais arriver à un Wiki suffisamment simple pour qu'il reste modifiable tout en ayant de nombreuses fonctionnalités est un vrai challenge. Et puis me lancer dans un Wiki, alors qu'il en existe déjà 12354 sur la planète, ça ne fera qu'un de plus que je n'aurai sûrement pas le temps de maintenir.
URL courtes !
Je viens de mettre en place les URLs courtes dans mon Wikini. Pour cela, il a fallu que je modifie un peu mes
hacks sur Wikini (voir
WikiBlog), parce que j'avais codé en dur des URLs contenant wakka.php&wiki=. Au lieu de tout cela, j'utilise maintenant le paramètre
base_url de la configuration de Wikini stockée dans
wakka.config.php.
En plus de cela, j'utilise un fichier
.htaccess à la racine du site, qui gère la réécriture des URLs pour que tout fonctionne bien. Merci à
Sam et
Olivier Peningault pour leur aide sur la question. Voilà le fichier :
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([0-9a-zA-Z_\/\&=\-]+)$ /wakka.php?wiki=$1
En gros, ça dit que "si l'URL ne pointe pas vers un fichier
et que l'URL ne pointe pas vers un répertoire,
alors réécrire l'URL en wakka.php?wiki=".
Simple, non ?
Si j'avais le courage, il faudrait que je me replonge dans
WikiBlog pour y ajouter ceci, pour y ajouter un fil RSS pour le blog, et d'autres choses encore ;)
Un bon WE d'informaticien
Après un WE à Belfort et un WE à Toulouse, j'étais seul chez moi ce WE, j'en ai profité pour me faire un
bon WE d'informaticien ;-) Alors, oui ce n'est pas très social, mais j'ai d'autres occasions pour rencontrer des gens !
Gulliver et IMAP ...
Tout commence vendredi soir par la rencontre
Gulliver à la MJC du Grand Cordel, quelques discussions, tentative d'installation infructueuse d'une Webcam, puis bouffe dans une petite crêperie sympathique rue de Fougères pour les plus courageux (dont je faisais partie !). En rentrant, configuration d'IMAP, mon problème de création de dossiers étant solutionné, je me mets à configurer mon .procmailrc, voir
IMAP : Stockage du courrier électronique.
EDHEC et Weex
Le samedi, je devais mettre à jour le site de l'
UTBM EDHEC. Mélanie avait fait un nouveau design pour les pages Web, et je voulais que ce design soit le même dans les galleries d'images que j'avais généré grâce à
igal. Je modifie un peu les sources du site pour que ça utilise
GTML, un pré-processeur de pages HTML. Ça évite de recopier le header et le footer dans tous les fichiers HTML, et ça permet de définir quelques variables. C'est assez pratique pour un petit site statique.
Ensuite, la génération des galeries. Jusqu'à maintenant, j'avais fait un script Perl, mais en fait, c'était pas assez souple (comprendre pas assez crado) le Perl pour faire ce que je voulais faire. Donc je convertis le tout en script Shell et fait un script qui génère toutes les galleries dans tous les répertoires, avec les liens dans le menu qui pointent au bon endroit, etc... Bref la classe internationale ;-)
Puis là, je veux mettre à jour la chose sur le serveur. Sauf qu'il faut passer par
sftp pour cela, et que
rsync, ça passe pas par
sftp. Donc je regarde du coté de
Weex, un outil que j'utilisais il y a quelques années et qui permet de faire de la synchronisation par FTP. Malheureusement le support SFTP n'était pas présent.
Alors je me suis dit, tant pis, on va l'ajouter ;-) Un petit défi pour le WE, c'est assez sympathique. Me voilà donc parti :
apt-get source weex
apt-get source openssh
Et avec tout ça, j'ai réussi à pondre vers 6h du matin le dimanche un
Weex supportant SFTP complètement fonctionnel. Le code de
Weex est maintenant un peu plus modulaire, avec des backends (FTP, SFTP) bien séparés du coeur du code. J'ai réutilisé pas mal de code de
OpenSSH?, donc il n'y avait pas énormément de code à écrire, mais pas mal de bricolage pour faire la glue entre le code de
Weex et le code importe d'
OpenSSH?.
J'espère pouvoir faire intégrer ça à la version officielle de
Weex. Apparemment, ce logiciel n'est plus trop développé, la plupart des fichiers du CVS ont été modifiés il y a deux ans, et quelques fichiers ont été modifiés il y a 7 mois.
Il reste encore un peu de travail pour faire un patch vraiment propre. Du coté de la compilation, comme j'ai créé des répertoires, sous-répertoires pour organiser des backends, les fichiers
Makefile.am présents ne fonctionnaient pas. J'ai donc temporairement utilisé un
Makefile maison, parce que je connais pas du tout les
autotools, et on m'a souvent dit qu'il fallait prendre un peu de temps pour y comprendre quelque chose.
Subtitle-offset-modificator et Daily Debian Package
Le dimanche, j'ai eu besoin de modifier les timestamps d'un fichier de sous-titre. En effet, j'ai récupéré des sous-titres pour un film, mais les sous-titres étaient décalés dans le temps. Un rapide Google ne m'a pas donné d'outils simples et pratiques pour le faire, alors j'ai écrit un petit script Perl pour faire cela. Tout est dispo sur
SubtitleOffsetModificator !
J'ai passé le reste du dimanche à mettre en place un petit script Perl que je voulais faire depuis longtemps : Daily Debian Package. Voilà la description que j'ai envoyé sur quelques mailing-listes :
Des paquets Debian il y en a plein, tellement qu'il est impossible de
les connaître tous. Pourtant en dehors des paquets majeurs et bien
connus, il existe une foultitude de petits paquets avec des utilitaires
ou des bibliothèques de programmation intéressants et utiles.
Pour découvrir des nouveaux paquets, il existe déjà le Debian Package a
Day's Journal (http://www.livejournal.com/users/debaday/), mais
personnellement, je préfère recevoir des informations par courrier
électronique plutôt que d'aller visiter une page Web.
J'ai donc mis en place un petit système qui vous envoie si vous le
souhaitez un courrier électronique par jour, contenant la description
d'un paquet Debian. Le système s'assure que la description d'un même
paquet n'est pas renvoyée deux fois, et prévient explicitement si le
paquet est dans non-free !
En revanche, il n'y a aucun système de "vote" sur les paquets, ils sont
choisis totalement au hasard. Il se peut très bien que le système envoie
la description d'un paquet pas forcément intéressant comme
xfonts-cronyx-koi8r-misc par exemple ;-)
Pour s'abonner, c'est très simple, c'est une mailing-list tout ce qu'il
y a de plus classique :
http://the-doors.enix.org/cgi-bin/mailman/listinfo/daily-debian-package
Le script en question, est, bien entendu, sous licence GPL :
http://thomas.enix.org/wakka.php?wiki=DebianPackageDay
Voilà, tout est dit, le reste est dans
DebianPackageDay
Pour conclure
Alors, oui, je ne suis pas sorti du WE, mais j'ai appris plein de choses intéressantes, j'ai fait des choses amusantes, et j'ai l'impression d'avoir fait quelque chose de "productif". Alors j'aime bien ;-)
Flip : un petit paquet Debian intéressant
Le paquet
Debian flip contient un outil très pratique :
flip. Celui-ci permet de convertir des fichiers DOS (se terminant par CR LF) en fichiers Unix (se terminant par LF). C'est tout bête, mais c'est bien pratique, et ça évite de s'embêter avec une regexp sed.
Pour convertir un fichier au format Unix :
Mon fichier ASCII contenait des accents et caractères bizarres qui faisaient croire à
flip que c'était un binaire, donc il ne voulait pas le convertir. On peut toutefois le forcer en utilisant :
Voilà !
IMAP : Stockage du courrier électronique
Jusqu'à la fin du mois de juin, pour lire mes courriers électroniques, je les relevais simplement par POP, et je les lisais avec un client de courrier électronique en local. J'ai successivement utilisé Netscape (à l'époque où Mozilla n'existait pas), puis
Gnus, puis
Sylpheed. À la fin du mois de juin, sachant que je n'allais plus avoir de connexion Internet pour quelques mois, j'ai configuré
Mutt sur
enix.org, mon hébergeur favori. Depuis ce moment là, j'utilisais donc
Mutt à distance par
ssh. Mutt est un client de courrier électronique en mode texte assez sympathique, il est très rapide et tout faire au clavier fait gagner pas mal de temps. Je le lançais dans un
screen pour qu'il soit toujours actif sur le serveur. Où que j'aille, un simple client ssh suffisait pour lire mes mails. En plus, enix.org mettait à ma disposition un spamassassin pour filtrer les spams, bref c'était sympathique.
Cependant, je n'avais pas tout mon historique de messages sur enix.org, et je ne pouvais pas signer mes messages étant donné que ma clé privée GPG était chez moi, en local. L'uploader sur un serveur sur lequel d'autres personnes ont les droits d'administration est un peu génant. J'ai donc décidé de tester IMAP.
IMAP est un protocole qui remplace POP. Au lieu de télécharger les messages et de les supprimer du serveur, IMAP laisse les messages sur le serveur, et permet de les organiser en répertoires et sous-répertoires. On pourrait penser que c'est très lent, mais en fait, c'est assez bien pensé. Lorsque l'on rentre dans un répertoire de courriers électroniques, le client télécharge seulement les entêtes de messages. Le corps des messages n'est téléchargé que lorsque l'on clique dessus. De plus, le client conserve un cache des messages et des en-têtes, il n'est donc pas nécessaire de tout retélécharger à chaque fois.
Tous les bons clients de courrier électronique supportent l'IMAP. Pour ma part, j'utilise Thunderbird, et je me connecte sur enix.org à l'aide d'une connexion IMAPS (IMAP sécurisé). Sur enix.org, un fichier
.procmailrc filtre les messages et les range dans les répertoires qui conviennent. Le filtrage pourrait se faire au niveau de Thunderbird, mais dans ce cas, si je change de client ou que je lis mes messages d'ailleurs, il faut remettre en place les filtres.
Pour la mise en place dans Thunderbird, c'est assez simple, il suffit de créer un nouveau compte de courrier électronique, lui dire que c'est de l'IMAP. Ensuite, dans les propriétés du compte, on précise que la connexion doit se faire en IMAPS. Enfin, dans les propriétés avancées, on précise que les messages sont stockés dans le répertoire ~/mail/ sur le serveur. Et voilà, c'est tout !
Pour filtrer mes messages, j'ai commencé le
procmailrc suivant :
:0fw
| /usr/bin/spamassassin
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*
/dev/null
:0:
* ^X-Spam-Level: \*\*\*\*\*
mail/spam
:0:
* ^TOlinux-mips@linux-mips.org
mail/linux-mips
:0:
* ^TOlolut@lolut.utbm.info
mail/lug/lolut
:0:
* ^TOgulliver@listes.gulliver.eu.org
mail/lug/gulliver
:0:
* ^TOuclibc@uclibc.org
mail/uclibc
La première règle fait passer les messages dans
SpamAssassin?. La seconde règle envoie vers /dev/null les messages qui ont une note de plus de 10 avec
SpamAssassin?. La troisième règle envoie les messages qui ont eu une note de plus de 5 avec
SpamAssassin? vers le répertoire
spam. Les autres règles redirigent les messages dans les répertoires correspondants.
Pour que tout-ceci fonctionne, il faut que Thunderbird vérifie de temps en temps dans chaque répertoire qu'il y a des nouveaux messages (puisque ce n'est pas lui qui fait le filtrage). Pour cela, sur chaque répertoire, un clic droit, et dans les propriétés, il faut cocher "Surveiller les nouveaux messages dans ce dossier".
Avec tout ça, ça fonctionne bien, et je dispose en local d'un client mail sympathique et graphique, qui permet de classer les messages, de signer/chiffrer mes mails, de lire des flux RSS, etc...
Deux dernières astuces pour Thunderbird :
- Pour désactiver l'affichage des mails en HTML (merci à David Anderson). Les mails en HTML sont convertis au format texte brut. Dans le fichier .mozilla-thunderbird/<votrecompte>/prefs.js, il faut ajouter :
user_pref("mailnews.display.html_as",1);
- Pour que les liens Web dans Thunderbird ouvrent Firefox, il faut ajouter éditer /etc/mozilla-thunderbird/global-config.js, et décommenter les lignes :
pref("network.protocol-handler.app.http","mozilla-firefox");
pref("network.protocol-handler.app.https","mozilla-firefox");
Notez que j'ai eu un problème au début avec l'IMAP : le serveur ne voulait pas créer de répertoires pour stocker mes messages. J'ai cherché pendant quelques temps, et je n'ai rien trouvé. Sur le serveur, j'ai donc supprimé mon fichier /var/mail/thomas, mon fichier ~/mbox, et ce qu'il y avait dans le répertoire ~/mail/. J'ai supprimé ma configuration de Thunderbird en local, et je l'ai relancé et refait une configuration, et ça a fonctionné. Vraisemblablement, le serveur IMAP n'avait pas aimé qu'un mbox soit déjà présent ...
Merci à
Jérome pour l'hébergement sur enix.org, et l'aide pour la configuration d'IMAP !
Firefox, un bon navigateur !
Tout le monde l'a fait sauf moi. J'aurais pu faire l'original et ne pas en parler, mais c'est tellement important que j'en parle quand même : de Firefox bien sûr ! Je profite d'un très bon
article du Monde sur le sujet pour me lancer dans l'aventure !
Firefox est un
navigateur Web libre, c'est à dire que tout le monde peut librement l'utiliser, le copier, le modifier et le diffuser. En dehors de ces avantages "philosophiques", Firefox présente aussi (et surtout diront certains) de nombreux avantages techniques :
- La navigation par onglets, une fonctionnalité incontournable dont on ne peut plus se passer une fois qu'on l'a essayé. Au lieu d'avoir 15 fenêtres différentes se superposant quand vous naviguez sur le Web, vous n'avez qu'une seule fenêtre, et chaque page Web chargée est bien rangée dans un onglet.
- Le blocage de pop-up est également sympathique, ainsi que le blocage de publicité.
- Le nombre de failles de sécurité est moins important que dans Internet Explorer, et surtout elles sont corrigées très rapidement.
- Respect des standards du W3C dans l'affichage des pages
- Le logiciel est petit : moins de 5 Mo pour la version Windows, un peu plus de 8 Mo pour la version Linux.
- Il est rapide, pratique et joli ;-)
Si vous utilisez encore Internet Explorer, je vous conseille vivement d'essayer
Firefox, évidemment disponible en français. Il faut également noter que dans la même suite de logiciels, on trouve également le client de courrier électronique
Thunderbird, également très sympathique, avec un filtre à
spam très efficace intégré. On peut également trouver le logiciel
Nvu qui est un éditeur de pages HTML pour ceux qui souhaitent réaliser simplement leur site Web.
Personnellement, je l'utilise sous Windows au travail et sous Linux à la maison, et je le trouve vraiment excellent !
Bitkeeper
Aujourd'hui, j'ai eu besoin d'utiliser
Bitkeeper dans le cadre de mon stage. Pour ceux qui ne savent pas, c'est un outil de gestion de versions notamment utilisé par les développeurs du noyau Linux. D'ailleurs, son utilisation avait provoqué de nombreux débats à l'époque, en raison du caractère
non-libre de Bitkeeper. Les sources sont disponibles, mais la licence est plutôt restrictive. En fait, il est distribué sous
4 licences différentes.
Je commence par télécharger Bitkeeper. Il faut obligatoirement passer par un formulaire, donner son nom et son e-mail et dire "non, merci, je ne veux pas recevoir vos publicités à deux sous". Je reçois alors un mail contenant le précieux mot de passe pour télécharger le logiciel. Le login n'est autre que
bitkeeper et le mot de passe
get bitkeeper, ça doit donc être le même login/pass pour tout le monde ...
J'installe ensuite la chose, une jolie interface me pose deux ou trois questions, et j'ai enfin la chose installée dans ~/bin/, histoire de pas polluer le système avec ce genre de saletés ;-)
Ensuite, je commence à récupérer un arbre Bitkeeper, en utilisant la commande
bk clone :
bk clone bk:/ /sources.mvista.com/linux-2.5-marvell. Le logiciel mouline pendant un paquet de temps pour récupérer tout le bazar. Si j'ai bien compris, il récupère tout l'historique de tous les fichiers, pour que je puisse en local revenir en arrière, repartir, etc...
Une fois le téléchargement terminé, je m'aperçois qu'il n'y rien dans les répertoires ... pas de fichiers. Ils sont dans un format bizarroïde dans un sous-répertoire SCCS. En fait, il faut faire un
bk get si on veut voir le fichier, et un
bk edit si on veut l'éditer (avec un
bk get il est en lecture seule). Et pour l'éditer, il faut apparemment passer par la commande
bk vi, je n'ai pas encore bien compris pourquoi. Je fais donc deux modifications à la noix dans deux fichiers, juste pour tester et voir comment se passe un commit.
Je tente donc un
bk citool qui lance un outil graphique pour entrer les logs de commit, on peut aussi faire
bk ci pour avoir la même chose en mode texte apparemment. Un truc sympa, c'est qu'on peut entrer un message de log pour chaque fichier, et un message de log pour le changeset complet. Je fais tout ça, et je clique sur le bouton commit. Et là, ça se met à mouliner, puis après ça me dit qu'il est pas content, parce qu'il ne peut pas contacter openloggin.org.
Alors là, je trouve ça louche. Pourquoi il veut contacter ce site quand je committe ? Je vais donc voir sur le fameux
OpenLogging, et j'y lis :
This site contains the changelog information for all projects which use BitKeeper? under the free use license (BKL). The intent is that anyone may watch what is going on in the distributed collection of BitKeeper? repositories worldwide. En gros, dans la version gratuite de Bitkeeper, tu es obligé d'envoyer des changelog à
OpenLogging?, c'est comme ça. C'est super, non ?
Je reviens sur le site de Bitkeeper, pour voir de quoi il retourne, et je tombe sur la licence "gratuite", la fameuse BKL, et j'y lis
non-commercial users must participate in Open Logging and may receive a reduced level of support. Et dans le chapitre 3 de la
licence BKL, on trouve :
3. LICENSEE OBLIGATIONS
(a) Maintaining Open Logging Feature: You hereby warrant
that you will not take any action to disable or oth-
erwise interfere with the Open Logging feature of the
BitKeeper Software. You hereby warrant that you will
take any necessary actions to ensure that the Bit-
Keeper Software successfully transmits the Metadata
to an Open Logging server within 7 days of the cre-
ation of said Metadata. By transmitting the Metadata
to an Open Logging server, You hereby grant BitMover,
or any other operator of an Open Logging server, per-
mission to republish the Metadata sent by the Bit-
Keeper Software to the Open Logging server.
Donc on est obligé de conserver cette "fonctionnalité". Une autre partie intéressante de la licence, qui avait fait couler beaucoup d'encre, c'est l'impossibilité d'utiliser Bitkeeper si on participe au développement d'un autre outil de gestion de version :
(d) Notwithstanding any other terms in this License, this
License is not available to You if You and/or your
employer develop, produce, sell, and/or resell a
product which contains substantially similar capabil-
ities of the BitKeeper Software, or, in the reason-
able opinion of BitMover, competes with the BitKeeper
Software.
Voilà, donc Bitkeeper, d'un point de vue licence, ça craint vraiment. Heureusement qu'il existe des alternatives viables comme
Subversion ou
GNU Arch !
Open-source marketing
Un article sur
Clickz.com, trouvé via
LinuxToday nous parle du
Marketing Open-Source. Hans-Peter Brondmo, l'auteur, nous explique que le marketing peut s'inspirer du fonctionnement du logiciel open-source, en intégrant le "client", la "cible" dans le développement de la publicité. Ainsi, ce dernier pourrait transformer la publicité, l'adapter selon ses goûts, la redistribuer autour de lui.
Alors, soit j'ai rien compris, soit ce mec est complètement fou. Vous en pensez quoi ?
Quelques lectures
Voilà quelques liens que j'ai posté ces derniers jours sur la mailing list de
Lolut parce qu'ils m'ont paru intéressants :
- Téléchargement : les propositions à contre-courant de l'Adami
- Un rapport épingle le manque de productivité des sociétés d'auteurs
- Les censeurs du Net censurés
- Pirater, c'est aussi consommer
- Le logiciel libre : une démonstration du libéralisme ?
- La GPL déclarée d'intérêt public
Une série de plusieurs articles sur ZDNet
http://www.zdnet.fr/actualites/technologie/0,39020809,39157351,00.htm
- Les sites web du gouvernement gérés par une plate-forme logicielle libre
- Le ministère des Finances choisit les logiciels libres pour recouvrer les impôts
- Le ministère de l'Intérieur passe aux logiciels libres pour gérer son courrier
- Jusqu'à 15% des PC de l'administration devront passer à l'"open source" d'ici à 2007
- Le dossier médical partagé, un chantier taillé pour les logiciels libres
- et des articles sur les tendances à l'étranger
- «Si j'avais essayé de demander des royalties, il n'y aurait pas eu de world wide web»
- L'Etat français veut passer à Linux
- Microsoft prêt à relever le défi des logiciels libres
Wiki Blog
La version 0.1 du
Wiki Blog est sortie. En gros, il s'agit des sources utilisées pour réaliser ce site Web.
Si vous l'utilisez, n'hésitez pas à me le signaler, et à me faire part de vos remarques, suggestions, problèmes ...
Et un de plus !
De quoi je veux parler ? De quelque chose que je ne connais plus depuis quelques années :
les virus informatiques. Un nouveau virus est
apparu hier, son petit nom est
Sasser. Il exploite de nouveau une faille d'un composant obscur du système d'exploitation Microsoft Windows. Apparemment, le patch pour la faille de sécurité existait déjà, mais évidemment, personne ne l'avait appliqué.
Bref, qu'est-ce qui m'amène à parler de ça : tous les journaux en parlent, et je n'en ai que faire. C'est simplement pour dire que la réaction à ce virus sur le canal IRC sur lequel je traîne était plutôt amusante. C'était la panique à bord, les gens avaient 30 secondes avant que leur ordinateur ne rebootent, il leur fallait le correctif dans les 10 secondes, et ils étaient une bonne dizaine comme ça pour lesquels c'était la panique. Évidemment, on en a profité pour revenir comme des gros lourds avec notre Linux préféré, mais cela n'a pas eu l'effet escompté.
En attendant,
Le Monde nous précise
Du type "ver", le virus a un fichier d'une taille de 15 872 bytes et n'affecte pas les systèmes Linux, Macintosh, Novell Netware, OS/2, UNIX, Windows 95, Windows 98, Windows Me, Windows NT, ajoute Symantec sur son site. ...
Libr'East
Libr'East c'est 3 jours avec plein de conférences et d'ateliers sur les Logiciels Libres (techniques ou non). Ça a eu lieu du 23 au 25 avril à Marne la Vallée, et c'était la première édition. Pour ma part, je suis arrivé le samedi dans l'après midi. L'ambiance est assez habituelle : un grand hall avec quelques associations exposantes, toujours les mêmes, et trois amphis de conférences. Plein de conférences intéressantes, avec plein de gens intéressants. J'ai pu assister in-extremis à la fin de la présentation sur
Expérience démocratique, et donc retrouver
David Decotigny et ses potes rennais initiateurs du projet : David Mentré, Frédéric Lehobey et d'autres. J'étais assez déçu du faible nombre d'auditeurs pour cette conférence. Pour certaines conférences techniques remplies de vent, il y a des dizaines et des dizaines de personnes, là il devait y avoir 6 à 8 personnes extérieures au projet, tout au plus.
Suite à cette conférence, un peu de bricolage avec
Jérome pour finaliser ma conf du lendemain, puis resto chinois avec une cinquantaine de membres de la communauté. Ambiance sympageek ;)
Le lendemain à 9h (arghh ... dimanche matin à 9h), j'ai fait une petite présentation qui avait pour thème
Fonctionnement d'un OS et KOS (les
slides). En fait, ça a commencé vers 9h20, et j'étais tellement long que je n'ai pas eu le temps de finir dans le temps imparti. Une vingtaine de personnes étaient présentes, et l'interactivité avec le public était bonne puisque j'ai eu le droit à plusieurs questions pendant l'exposé, ce qui montre que les gens suivaient. Au menu : quelques définitions sur les concepts d'un OS, puis application au noyau Linux : gestion de la mémoire virtuelle, physique, gestion des processus, fonctionnement du VFS et des pilotes de périphériques. J'aurai aimé avoir plus de temps sur certains sujets ... notamment sur la présentation de
KOS qui a du être sérieusement écourtée. La présentation a été filmée, donc je pense que d'ici quelques semaines, ça sera possible de revoir le truc et de bien rigoler ;-)
Après discussion avec David, on est bien décidé à refaire un truc dans le genre aux LSM à Bordeaux en juillet, en un peu plus long peut être, mais d'ici là, je vais animer une présentation de 2 * 3h sur les OS à l'
UTBM.
Pour finir, mes remerciements et mes félicitations à l'équipe de Libr'East qui a réussi à réunir pas mal de conférenciers, à bien organiser la chose et à faire venir quand même un peu de monde. A l'année prochaine au prochain Libr'East, et d'ici là, aux LSM ;-)
User Mode Linux
Ça y est, j'ai
enfin trouvé le temps d'installer et de configurer
User Mode Linux, le bidule qui permet de lancer un noyau Linux comme un processus, et donc d'avoir un sous-système Linux qui tourne dans votre machine, sans avoir de droits root. Ce mécanisme offre plein d'applications intéressantes : débuggage du kernel sans risques et avec plus de facilité, sécurisation de services, hébergement virtuel, et surtout bricolages en tous genres.
En fait, c'est pas complique :
- Vous récupérez un noyau classique (j'ai pris le 2.6.4)
- Vous appliquez le patch qui va bien sur le noyau
- Configuration avec make menuconfig ARCH=um puis compilation avec make linux ARCH=um
- Tout ça génère un éxécutable linux qu'il faut stripper, sinon il fait 20 Mo
- Ensuite, faut récupérer une image de système de fichiers, moi j'ai récupéré celle d'une Debian. Il faut la nommer root_fs
- Dans le même répertoire vous mettez le binaire Linux et le fichier root_fs. Et hop ./linux et c'est parti, le noyau boote !
Pour avoir le réseau, j'ai utilisé TUN/TAP. Faut compiler le support dans le noyau de la machine hôte. Ensuite, faut dire à ./linux de créer une interface tap0 sur la machine hôte (genre avec l'IP 192.168.2.1) et ensuite dans votre Linux dans le Linux, vous configurez eth0 avec l'adresse 192.168.2.2. Ça y est les 2 Linux communiquent.
En une heure tout était compilé et configuré. Franchement, ça marche nickel leur machin. J'ai plus qu'à ajouter un peu de NAT sur ma machine pour donner l'accès à Internet au Linux dans le Linux, et c'est parti, je vais pouvoir faire joujou sans rien casser.
Edit : ça y est, j'ai réussi à faire fonctionner le Net dans la boîte UML. Sur la machine hôte, un petit
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -i eth0 -j MASQUERADE a suffit, et dans la boîte UML, un
route add default gw 192.168.2.1, et voilà. Ensuite, j'ai voulu installer des packages, mais le système de fichiers était trop petit. Aucun problème, la
solution sans reformater existe. J'ai pu installer Apache et y accéder depuis la machine hôte. Excellent excellent. J'adooooooooore ;-)
Standards du Web
The Way Forward with Web Standards est un document qui résume l'intérêt de l'utilisation des standards, en particulier pour l'entreprise. J'ai commencé à lire le texte, ça me paraît très intéressant, donc je vous en fais profiter. A mon avis, il y a plein d'arguments fort intéressants à tirer de ce document.
Conférence à Libr'east
Le dimanche 25 avril, je serai à
Libr'east pour faire une petite conférence sur le fonctionnement d'un système d'exploitation et sur le projet
KOS. C'est un peu mission impossible que de présenter le fonctionnement d'un OS en 1h30, mais je vais essayer de faire quelque chose d'à la fois accessible et utile. La conférence a lieu de 9h à 10h30.
Sinon, Libr'east c'est du vendredi 23 au dimanche 25 avril, et il y a plein d'autres conférences qui ont l'air réellement intéressantes. Personnellement, je suis particulièrement intéréssé par la partie Libre et philosophie. On y verra des gens comme Bernard Lang, Nat Makarevitch, Thierry Stoehr, Christophe Le Bars, Ludovic Penet, Frédéric Couchet, Christophe Espern, Tristan Nitot ... bref que du bon.
Je vous encourage également à aller voir la présentation du projet
Expérience Démocratique. Le plus intéressant est à mon avis la présentation générale de ce projet. C'est David Mentré qui s'y colle le dimanche juste après le repas ;)
C'est pas souvent qu'il y a plein de conférences comme ça en dehors des Rencontres Mondiales du Logiciel Libre, alors venez tous !
Crash disque
Hier, subitement :
thomas@crazy$ man ls
bash: man: command not found
Étonnant, non ? En fait, mon disque système contenant /usr, / et /var venait de me crasher entre les mains. Comme ça, subitement. La veille, j'avais regardé, et des fichiers dataient du 12 février 2000, quand mon système a été initialement installé par les bons soins de
Jérome Petazzoni, mon cousin. D'ailleurs, cette date correspond à la seconde assemblée
KOS.
Quatre ans de configuration perdus. Tout à refaire. Heureusement, mon disque de données est encore vivant, de toute façon, je fais régulièrement des sauvegardes. Enfin bon, ça fait quand même perdre du temps cette histoire.
Gobelins
Depuis quelques temps, mon frère,
Maxime Petazzoni travaille sur un projet de
Nekeme Prod, un jeu appellé
Gobelins. Personnellement, je ne connais pas bien le monde des jeux, et j'ai du mal à comprendre de quoi il s'agit, mais apparemment, le projet a l'air d'intéresser pas mal de monde, et une
interview sur
LinuxFrench a été réalisée.
La news a été reprise chez
Toolinux.
Hébergement : la galère !
Le
Livret du Libre était auparavant hébergé chez
TuxFamily. Depuis la fermeture brutale de cet excellent hébergeur associatif, il a fallu trouver une solution pour héberger un projet libre. Et bien, pas facile ! Nous avons essayé les diverses solutions suivantes :
- Gna!. Après une première soumission du projet, ils ont refusé à cause d'une possible incompatibilité de notre licence bricolée avec la GPL. Je contacte donc tous les contributeurs, et on passe enfin à une vraie licence : la Creative Commons Attribution and Share Alike. Je resoumets le projet à Gna! qui me réitère sa remarque d'incompatibilité avec la GPL. Effectivement, les versions modifiées d'une oeuvre sous CC SA doivent être redistribuées sous CC SA, et ne peuvent pas l'être sous GPL. D'où incompatibilité. Ceci dit, la GPL pose exactement la même conditions pour les versions modifiées des oeuvres sous GPL. Donc Gna!, pas possible à moins de placer le document sous GPL (stupide pour un document texte), ou sous FDL (ce qui obligerait à inclure le texte intégral de la licence dans toutes les versions imprimées du document).
- Savannah n'ouvre plus de comptes depuis leur piratage il y a quelques temps.
- Alioth serait un choix possible, mais il nous faudrait un DD (Debian Developer) qui "sponsorise" le Livret du Libre. Si un DD me lit et est intéressé, qu'il me contacte !
- SourceForge nous semble être un mauvais choix. Il semblerait que VA Software ait pris une direction relativement peu compatible avec l'idée du Libre que nous défendons dans le Livret du Libre
Que nous reste-t-il ? Pour l'instant, la seule solution trouvée a été l'hébergement sur une ligne ADSL amateur. Nous ne disposons pas d'outils de bugtracking, pas de mailing lists, bref, c'est du temporaire. Et surtout, on aimerait être hébergé à un endroit où tout est déjà prévu, et où nous n'avons pas à nous préoccuper de l'administration. Si quelqu'un a une idée, on est preneur !
Tramp : éditer à distance !
On m'a fait découvrir aujourd'hui un outil formidable pour
Emacs, j'ai nommé
Tramp. Il s'agit d'un add-on pour Emacs qui permet d'ouvrir des fichiers à distance via
ssh (et d'autres). Ainsi, on ouvre le fichier
/ssh:thomas@gate:/etc/apache/httpd.conf et hop, ça va le chercher tout seul au bon endroit. Le plus étonnant, c'est qu'il y a la complétion, on peut lister les répertoires avec
Dired, comme si on était en local. Vraiment formidable.
Pour l'installer :
apt-get install tramp, puis dans votre
~/.emacs, il faut ajouter la ligne
(require 'tramp). Attention, si le prompt du shell auquel vous accédez est trop exotique, Tramp va s'emmeler les pinceaux.
Merci à
Alex pour la découverte !
KOS : quel avenir ?
Je n'ai pas encore présenté le projet
KOS sur ce blog. Je suppose que la plupart de mes rares lecteurs connaissent ce projet, qui consiste à programmer un mini système d'exploitation pour PC. L'objectif du projet est purement éducatif : le but est d'apprendre, mais de créer un n-ième système d'exploitation soit-disant révolutionnaire. C'est un projet que j'ai lancé il y a plus de 5 ans avec Dimitri Ara. A l'époque, nous savions à peine programmer en langage C et ne savions pas à quoi servait l'allocation dynamique de mémoire. Depuis, le projet a parcouru son
petit bonhomme de chemin et a bien progressé ses derniers temps.
L'équipe qui existe, constituée de 3 personnes, est très sympathique. Le projet avance au coup par coup, quand les membres de l'équipe se rencontrent. Mais j'aimerais bien que d'autres personnes rejoignent ce projet pour le faire vivre tous les jours, amenez de nouvelles idées, découvrir de nouvelles choses. Il y a beaucoup de choses à faire dans ce projet, comme par exemple :
- développer des pilotes de périphériques. Maintenant que les bases du système commencent à exister, il est envisageable de développer en parallèle des pilotes de périphériques. Il serait intéressant d'ajouter le support écriture pour le système de fichiers FAT, d'ajouter le support ext2, d'ajouter le support pour des cartes réseaux, etc...
- faire de la documentation. L'objectif de KOS n'a jamais été de construire un système complet et réellement fonctionnel. L'objectif était clairement éducatif et pédagogique. Il semble que cet objectif ait été atteint en ce qui concerne les développeurs, puisqu'ils ont tous appris le fonctionnement interne d'un système d'exploitation, et parfait leurs connaissances en programmation. En revanche, la partie documentation, qui permettrait à des personnes n'ayant pas commencé le projet de s'y intéresser a été complètement laissée de coté. Il serait donc intéressant qu'une ou plusieurs personnes intéressées par le projet commencent par le documenter afin de découvrir son fonctionnement et de pouvoir ensuite participer au développement.
- améliorer le site Web. Le site Web du site se voulait un grand répertoire d'informations, de documents et de liens sur les systèmes d'exploitation. Il y a bien quelques documents et liens, mais beaucoup moins que ce qui était prévu. Il serait également intéressant qu'une personne prenne en charge ce site Web pour le faire faire vivre.
Du coté des 3 développeurs, les projets futurs sont les suivants : reprise complète de la synchronisation au sein du noyau, puis portage de la GNU libc. Ce deuxième objectif est un objectif à long terme, qui recouvrira sans doute des objectifs plus restreints.
Le projet KOS progresse donc toujours, mais a réellement besoin de nouvelles personnes pour lancer une nouvelle dynamique, recevoir de nouvelles idées, confronter les avis. Pour les personnes intéressées, je suis prêt à organiser une présentation de KOS complète durant une réunion (physique) d'une journée par exemple. Si un de mes rares lecteurs est motivé par ce projet, qu'il n'hésite pas à nous contacter.
FLAC
FLAC pour Free Lossless Audio Codec est un codec audio, tout comme
Ogg Vorbis ou MP3, sauf qu'il s'agit d'une compression sans perte. La qualité n'est pas altérée. Cela revient donc à de la compression classique sans perte, comme avec
gzip, sauf que
FLAC utilise une méthode spécifiquement adaptée à la compression de données audio, ce qui permet de diminuer d'environ 50% la taille des fichiers (sans perte de qualité).
Bien que le commun des mortels avec son équipement hifi classique n'entende pas ou très peu la différence entre la version CD et la version compressée Ogg ou MP3 d'une musique, il peut s'avérer intéressant dans certains cas d'utiliser
FLAC.
Webmail ou la mort du mail
Un webmail ?
Les
webmails, comme
Horde IMP ou
SquirrelMail, sont ces clients de courrier électronique que l'on consulte directement à partir de son navigateur Internet. Cela présente l'avantage de pouvoir accéder de n'importe où à son courrier électronique, depuis n'importe quel poste informatique, avec n'importe quel navigateur, et éventuellement de façon sécurisée (https). De plus, tout le système de courrier électronique est centralisé, ce qui simplifie le travail de l'administrateur réseau, et qui explique sans doute la popularité croissante de ce genre d'outils.
Le problème
Toutefois, face à ces avantages, je vois un défaut important à ces courriers électroniques : il ne permette plus de brasser des quantités importantes de mails de façon efficace. De nombreuses personnes se plaignent de recevoir un nombre considérable de messages par jour. On s'aperçoit généralement que les personnes émettant cette remarque utilisent des clients de type
webmail. Effectivement, pour plusieurs raisons, les
webmails sont relativement peu pratiques en ce qui concerne la consultation d'un nombre important de messages :
- Ils sont utilisés au travers d'un réseau, et même si celui-ci est local et très performant, la génération des pages n'en reste pas moins relativement longue, en tout cas trop longue pour pouvoir consulter rapidement plusieurs dizaines de courriers électroniques par jour. Les clients de courrier électronique normaux n'ont pas ce défaut : une fois les mails téléchargés en local, le passage de l'un à l'autre est instantané.
- Ils ne permettent pas de visionner rapidement des mails : une fois dans un message, il faut soit revenir à la liste des messages, soit passer au suivant à l'aide d'un clic, puis attendre le chargement de la page. Avec un client de courrier électronique classique, un simple appui sur une touche (Espace la plupart du temps) ouvre automatiquement le prochain message non plus. On peut donc très rapidement passer d'un message à un autre, et ainsi survoler en quelques minutes des dizaines de messages.
- La plupart ne permettent pas la vision sous forme de fil de discussions. Cette fonctionnalité est présente dans tous les clients de courrier électronique classiques corrects. Elle permet de visualiser sous forme d'arbre le cheminement d'une discussion : toutes les réponses à un message sont classés dans un sous-arbre, les réponses des réponses dans le niveau de l'arbre inférieur, etc... On peut visualiser ainsi de manière graphique le fil de la discussion, et donc voir que si le début de la discussion ne nous intéresse pas, le reste ne nous intéressera pas non plus. En anglais, cette fonctionnalité s'appelle le threading, les mails sont classés en thread.
- Les webmails permettent le tri des messages électroniques par dossier dès leur réception à l'aide de filtres, mais ne permettent pas de visualiser en un clin d'oeil où sont les nouveaux messages, ce que permet un client de courrier électronique classique.
Par exemple, cette
capture d'écran montre le client de courrier électronique intégré à
Mozilla, avec des dossiers contenants des messages non lus sur la gauche et sur la droite la liste des messages organisés par fils de discussion.
Ainsi, l'utilisation d'un client de courrier électronique classique propose des facilités qui permettent de consulter un nombre très important de messages, de les classer automatiquement, de visualiser lesquels sont importants, d'y répondre rapidement, etc... A titre personnel, je suis abonné à un grand nombre de listes de diffusion, ce qui engendre un traffic de courrier important, mais ne m'empêche pas d'en tirer les informations que je souhaite.
Comment faire ?
Tout d'abord, vous devez installer un client de courrier électronique correct :
Ensuite, vous devez posséder une adresse e-mail chez un fournisseur d'accès qui propose l'accès selon le protocole
POP ou
IMAP. Ces protocoles permettront à votre client de courrier électronique de récupérer vos messages. Oubliez donc les Hotmail et autres Caramail, et utilisez un compte chez votre fournisseur d'accès (Wanadoo, Free, etc...).
Solution ultime ?
Bien entendu, les clients de courrier électronique ne sont pas la solution ultime : ils permettent difficilement d'accéder à son courrier électronique lorsque l'on est en déplacement. A titre personnel, j'utilise donc à la maison un client de courrier électronique classique, et lorsque que je ne suis pas chez moi, j'accède à mon courrier à l'aide d'un
Webmail. Je choisis l'outil le plus adapté en fonction de là où je me trouve ;)
Alors, vous aussi, si vous avez l'impression de recevoir trop de messages, essayez un client de courrier électronique classique, vous verrez, ça vous changera la vie ;-)
Travaux dérivés
La question du
travail dérivé est fondamentale pour déterminer les limites de la "contamination" des licences copyleftées.
En fait, quand un logiciel est sous licence GPL, ce sont les travaux dérivés ("derivative works") qui doivent également être sous GPL. Toute la subtilité réside donc dans la définition de ce terme "travail dérivé".
Ce sont des préoccupations que l'on retrouve actuellement dans des discussions de la mailing list du kernel Linux. Les programmes utilisateurs utilisant des appels systèmes du kernel Linux sont-ils des travaux dérivés du noyau ? A priori, non, mais les avocats ont quand même souhaité qu'une mention spéciale y soit consacrée dans le fichier COPYING du noyau :
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered
normal use of the kernel, and does *not* fall under the heading of
"derived work". Also note that the GPL below is copyrighted by the Free
Software Foundation, but the instance of code that it refers to (the
Linux kernel) is copyrighted by me and others who actually wrote it.
La question des programmes utilisateur est donc claire : il y a une interface bien définie entre ces programmes et le noyau, ils ne sont pas
forcément conçus pour ne fonctionner qu'avec le noyau Linux : ce ne sont pas des travaux dérivés.
En revanche, la question se corse quand il s'agit des modules noyau livrés sous forme binaire (par exemple les drivers de cartes graphiques
Nvidia). En effet, à l'origine, les symboles exportées par le noyau vers les modules étaient peu nombreux, et faisait que les modules étaient
juste périphériques au noyau, et n'entrait pas dans le coeur de son fonctionnement. Maintenant, cela a bien changé : plusieurs milliers de
symboles sont exportés, et la séparation entre noyau et modules est bien plus difficile à cerner. Les modules binaires doivent-ils être
considérés comme des travaux dérivés du noyau ? Dans ce cas, ils seraient illégaux.
Comme vous pouvez le constater, la question du travail dérivé est très pointue, comme l'explique Dan Ravicher dans une
interview sur Lwn.net. Il explique entre autres que les cours américaines ont mis en place des
procédures pour déterminer si un travail est dérivé d'un autre.
D'autres sources sont le chapitre
Binary modules and derived works, ainsi que les
résumés de la liste du kernel.
Donc, pour savoir si un article de journal utilisant une photo sous licence Art Libre doit aussi être distribué sous licence Art Libre, il
faut répondre à la question : est-ce que cet article de journal est un travail dérivé de la photo ?
Note: ce blog est issu d'un courrier électronique que j'avais rédigé pour la liste de diffusion du Club Lolut
libxml2 et validation par DTD
Dans le cadre du projet
KOS, nous utilisons la librairie
libxml2 pour générer à partir de fichiers XML divers codes sources C. Celà se fait de manière très simple grâce à l'API DOM (Document Object Model).
Un point intéressant est que
libxml2 permet de valider un document XML par rapport à une
DTD. Ainsi, la structure du document XML peut facilement être validée.
Grossièrement (sans le test des erreurs), voilà comment valider un document XML. Le programme prend en premier argument le document XML, en deuxième argument la DTD.
#include <libxml/tree.h>
#include <libxml/xpath.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
xmlDocPtr xmldoc;
xmlDtdPtr dtd;
xmlValidCtxtPtr ctxt;
int valid;
xmldoc = xmlParseFile (argv[1]);
if (!xmldoc) { }
dtd = xmlParseDTD(NULL, argv[2]);
if (!dtd) { }
ctxt = xmlNewValidCtxt();
if(!ctxt) { }
valid = xmlValidateDtd(ctxt, xmldoc, dtd);
xmlFreeParserCtxt(ctxt);
printf("Le document est %s\n", (valid == 1) ? "valide" : "invalide");
return 0;
}
Toute l'API de
libxml2 est décrite sur
http://www.xmlsoft.org/html/libxml-parser.html, à regarder de près si vous voulez analyser du XML. A noter également qu'on peut utiliser
libxml2 depuis d'autres langages que du C.