Tartine Blog

Mars attack !

2011-04-27T04:13:00.000-07:00

Traduction personnelle et partielle de http://www.eetimes.com/design/embedded/4215449/Mars-ate-my-spacecraft-?pageNumber=1

«

Considérons Mars Polar Lander (MPL), un triple échec en 1999. L'objectif de MPL était de fournir un atterrisseur sur Mars pour la moitié du coût de la mission Pathfinder succès spectaculaire lancé deux ans plus tôt. À 265 millions de dollars Pathfinder lui-même était beaucoup moins cher que le vaisseau planétaire précédent

Peu de temps avant qu'il ne commence sa descente, MPL largue 2 sondes Deep Space jumelles qui étaient censées impacter la surface de la planète à quelque 400 mph (640 km/h) et retourner des données "sous-strates".

MPL s'est écrasé lamentablement. Aucune des deux sondes DS2 n'a émis ne serait-ce un cri.

La commission d'enquête a fait l'observation, qui ne casse pas trois pattes à un canard, que le personnel fatigué commet des erreurs. Le contractant a utilisé de manière excessive les heures supplémentaires pour répondre à un calendrier ambitieux. Mars est exigeante sur la planification. Un décalage d'une seule journée sur la fin de la fenêtre de tir et la mission doit entrer en sommeil pour deux ans. Dans certaines affaires vous pouvez négocier avec le patron sur les dates d'échéance mais vous ne pouvez pas négocier avec la mécanique céleste.

Les développeurs MPL travaillait de 60 à 80 heures par semaines durant de longues périodes.

La commission releva également des tests insuffisants. Les analyses et modéles ayant remplacé tests et validations. Les analyses ne sont pas un mal en elles-mêmes, mais le test, c'est comme la comptabilité à double entrées, il trouve des erreurs de modélisation et des comportements étranges jamais envisagés lorsque les produit n'existent que sous forme de bits éthérés.

La doctrine de la NASA est de "tester comme vous volez et de faire voler ce que vous testez". Pourtant, aucun test d'impact d'une sonde opérationnelle DS2 n'a jamais eu lieu. Bien que prévu, ces tests ont été supprimés à mi-parcours du projet en raison de considérations de calendrier. Deux raisons possibles ont été avancées pour expliquer le flop des sondes jumelles DS2 : défaillance électronique en raison de l'impact à haute-vélocité, et une ionisation autour de l'antenne après l'impact. Étrangement, l'antenne n'a jamais été testée dans une simulation de l'atmosphére de Mars.

Pendant que les deux sondes s'écrasaient sur la Planète Rouge, la situation n'était pas meilleures sur MPL.
La commission d'enquête estime que les pieds d'atterrissage se sont déployés lorsque la sonde était à 1.500 mètres de hauteur, comme prévu. Trois capteurs, un par pied, signalent un touché avec succès, provoquant l'arrêt, par le logiciel, du moteur de descente.

Les ingénieurs savaient que lorsque les pieds seraient déployés, ces capteurs pourraient connaître une transition, provoquant la lecture d'une valeur "sol" fausse... mais on oublié d'en informer les équipes "firmware". L'erreur a donc été verrouillée ; à 40 mètres d'altitude le logiciel commence l'examen des données, lis les donnés fausses, et éteint scrupuleusement le moteur.

Un test en pré-lancement du système n'avait pas détecté le problème en raison d'un mauvais cablâge des capteurs. Après correction de l'erreur de câblage, le test n'a jamais été répété.

Il y a également les jumeaux de Mars Expedition Rovers, Spirit et Opportunity, qui à ce jour ont dépassé tous les objectifs de la mission et continuent de fonctionner. Nous avons tous entendu parler de l'arrêt désespérant de Spirit lorsqu'il a tenté de broyer une roche. La plupart d'entre nous savent que le répertoire du système de fichier flash était plein. VxWorks a remonté une exception, exactement comme prévu et a tenté de redémarrer. Ce qui exige plus d'espace de répertoire, causant une autre exception, un autre redémarrage, et ainsi de suite...

Comme dans le non-regretté DOS, les fichiers effacés consomment toujours l'espace du répertoire. Beaucoups de vieux dossiers accumulés lors de la naviguatin vers Mars dévoraient encore l'espace mémoire.

Initialement prévu comme une mission de 90 jours, le vaisseau spatial n'a jamais été testé pendant plus de 9 jours. Le fonctionnement en vol des moteurs et actionneurs a généré beaucoups plus de fichiers que cela n'avait été observé au cours des tests au sol. Les enquêteurs ont écrit: "Bien qu'il y ait des essais limités de longue durée dont le but était d'identifier la consommation de mémoire système de ce type là, aucun problème n'a été détecté parce que le système n'a pas été sollicité autant qu'il le serait plus tard en vol."

''Test like you fly, fly what you tested.''

Les gestionnaires d'exceptions étaient mal implémentés. Ils ont suspendu les tâches critiques après un échec d'allocation mémoire au lieu de placer le système dans un mode dégradé et sûr.

Une source de la NASA m'a indiqué que le même échec d'allocation mémoire VxWorks a provoqué des crash logiciels sur au moins 6 autres missions. L'OS n'est pas en faute, mais c'est gros morceau de code complexe. Dans tous les (chaque?) cas, les ingénieurs ont utilisé VxWorks de manière incorrecte.

Nous semblons incapables d'apprendre des catastrophes des autres. Nous avons le droit de faire une erreur. Répéter la même erreur toujours et encore est une forme de folie.

Il est facile de blâmer les ingénieurs, mais ils ont quand même diagnostiqué ce problème complexe en utilisant un débogueur à 100 (resp 160) millions de miles (resp km) du système cible, ont trouvé une solution, et transféré un correctif.

Ces gars là sont fortiches.

À suivre

Heuristique des empreintes systèmes

2011-01-13T04:44:00.000-08:00

Il m'arrive régulièrement de cogiter à la problématique très générale du traitement des problèmes (ou bugs) dans le fonctionnement d'un «système» informatique, le plus souvent une installation gnu/linux.
La question du traitement des bugs est évidemment très complexe. Elle peut-être décomposée en plusieurs sous-problèmes plus ou moins corrélés entre-eux. Sans souci de rigueur ou exhaustivité dans la démarche, énumérons :

au fait, c'est quoi un bug ?
comment ça se révèle ?
comment ça se détecte ?
comment ça se règle ?
comment éviter qu'un bug ne se reproduise ultérieurement ?*
...

Sans avoir de recette miracle, mon intention ici est d'exposer une technique (plutôt une heuristique) qui peut permettre de donner des éléments pour aborder les points 2 et 3 (voire 4 avec de la chance).

Tout administrateur système (plus ou moins amateur/professionnel) vous le dira, deux choses sont fondamentales pour espérer régler un problème/bug :

depuis quand (date précise!) est-il observable ?
quelles sont les modifications apportées au système puvant être considéré comme suspectes ?

Ok, deux questions apparemment simples, sauf que dans la vraie vie, ça se passe comme ça :

Admin : Ok, y'a un problème... depuis quand ? et tu faisais quoi ?

Utilisateur : Ben je sais pas trop... et je faisais rien de spécial, je te jure...

Que les réponses soient de bonne ou mauvaise foi, ça ne change pas grand chose... Il FAUT régler le problème (c'est le job de l'admin) avec très peu d'informations au départ.

Le principe de l'heuristique que j'utilise pourrait se résumer de multiples manières, en voici une :

Puisqu'on ne sait pas trop comment un système va se mettre à «fauter», regardons déjà comment il se comporte quand il fonctionne normalement. Le jour venu (bug!), les différences observables seront autant d'indices précieux.

Cette stratégie se décompose en deux aspects habituellement complémentaires : la statique et la dynamique.

Statique : De manière indépendant du temps (i.e. non dynamique), quelles sont les informations qui caractérisent qu'un système fonctionne correctement ?

C'est ici que l'aspect heuristique joue à plein. Il s'agit de se donner des photographies «correctes» de certains aspects observable d'un système, photographies associée au bon fonctionnement du système.

Des exemples en vrac (cette liste dépend évidemment du contexte informatique global):

- La liste des partages (samba) atteignables par défaut. (c-a-d le réseau fonctionne, les aspects nommages de machines également, ...)

- La liste des paquets (et versions!) installés (c-a-d une machine rend les services attendus grâce à cette liste là de paquets)

- La liste des modules noyaux chargés (c-a-d une machine est «matériellement» fonctionnelle grâce à cette liste là)

- La liste des paramètres Gnome pour l'utilisateur (c-a-d l'utilisateur est habituellement satisfait de son interface grâce à cet ensemble de valeurs de configuration)

Etc, toujours en vrac, la liste des connexions réseau, le paramétrage global de apt/dpkg, la liste des ports ouverts, ... Pour résumer, l'idée de base est de se doter d'un ensemble d'empreintes qui sont habituellement les indices d'un bon fonctionnement de la machine.

Le jour où, pour une raison encore inconnue, un module noyau n'est pas chargé, la sanction est immédiate, le réseau «tombe» ou bien la machine n'émet plus aucun son ou ...

Ce qui importe ici c'est d'avoir a priori (au sens premier du terme) des informations fiables sur le comportement habituel de la machine. En effet, quand le son «disparait», il devient fondamental de savoir si le son était précisément dépendant de la présence d'un module. Cela peut éviter de perdre énormément de temps à envisager inutilement les causes les plus diverses...

Dynamique : Le point précédent doit être maintenant considéré selon sa variabilité dans le temps, l'objectif étant d'être capable de déterminer sinon une date précise (seconde), au moins un intervalle de temps où des modifications de la statique sont observables et en relation avec le problème considéré.

Ici la démarche est simple. Il faut se mettre en configuration d'être capable d'observer une succession temporelle des «photos» prises précédemment ET ensuite de détecter les différences entre les photos «tout est ok» et la photo où, probablement, des traces permettant d'expliquer le bug sont observables (ah, tiens, il y a eu mise à jour automatique, donc imperceptible à l'utilisateur, de certains paquets).

Mise en oeuvre : La démarche étant expliquée, la mise en oeuvre est relativement simple.

On se donne k photos du système en «bon fonctionnement». Il faut ici préciser que la nature des distributions libres facilite grandement l'obtention de ces photos sous une forme textuelle simplement manipulable. Il est très facile d'obtenir un fichier texte avec la liste des ports ouverts (nmap), des fichiers ouverts (lsof), des montages actifs (mount), ... Seule limite, l'imagination de l'administrateur système.

Ces photos sont ensuite mémorisée dans un système quelconque (i.e. au choix) de gestion de versions. On comprend ici l'utilité du format textuel brut qui permet une mise en version optimale.

Il ne reste plus qu'à placer tout ça dans une mécanique de tâches automatiquement exécutables (cron) et l'on obtient un dispositif automatique adapté à la détection des variations pouvant être reliées à l'apparition d'un bug.

Les détails ne seront pas donnés ici car, sur la base de cette description, de multiples implémentations différentes sont possibles. À chacun de faire selon ses affinités.

Remarque 1 : Évidemment, les variations observées ne sont que potentiellement et indirectement reliées à la cause ou à la manifestation du bug. De manière duale, on ne peut garantir qu'un bug laisse nécessairement une trace observable dans l'ensemble limité de photos prises régulièrement.

Remarque 2 : En soit la mise en version d'informations «système» n'as grande chose de nouveau. La gestion en version de la configuration d'un système (/etc) devrait être même quasi obligatoire. Ce qui est un peu plus original c'est la conservation d'informations plus transitoires comme par exemple la liste des partages réseau effectivement visibles. Cette liste n'est pas dérivable des seuls fichiers de configuration de samba mais elle constitue bien un indice de son fonctionnement habituel (et même des autres machines fournissant ces partages!).

Invariant(s) cassé(s)

2010-11-19T04:55:00.000-08:00

Voici un billet qui va me permettre d'exposer l'importance d'un concept «en soit», les invariants. J'utilise l'expression «en soit» car ce concept se rencontre dans plusieurs domaines différents mais qu'il a la propriété constante (invariante ?) d'aider à la résolution de problèmes de type logique, informatique ... (ou tout du moins, d'aider à la compréhension de problèmes).

Le prétexte de ce sujet m'a été donné par les lignes suivantes obtenues en demandant la suppression du paquet fakeroot sur mon système informatique (ubuntu dérivé de debian).

Suppression de fakeroot ...
update-alternatives: avertissement: création de /usr/share/man/es/man1/faked.1.gz abandonnée car le fichier associé /usr/share/man/es/man1/faked-tcp.1.gz (du groupe de liens fakeroot) n'existe pas.
update-alternatives: avertissement: création de /usr/share/man/sv/man1/faked.1.gz abandonnée car le fichier associé /usr/share/man/sv/man1/faked-tcp.1.gz (du groupe de liens fakeroot) n'existe pas.
update-alternatives: avertissement: création de /usr/share/man/es/man1/fakeroot.1.gz abandonnée car le fichier associé /usr/share/man/es/man1/fakeroot-tcp.1.gz (du groupe de liens fakeroot) n'existe pas.
update-alternatives: avertissement: création de /usr/share/man/sv/man1/fakeroot.1.gz abandonnée car le fichier associé /usr/share/man/sv/man1/fakeroot-tcp.1.gz (du groupe de liens fakeroot) n'existe pas.

Le système tente d'effacer des fichiers qui n'existent pas (en fait qui n'existent plus), alors que les-dits fichiers sont effectivement répertoriés dans la liste des fichiers à effacer lors du retrait du paquet fakeroot. Sans information complémentaire, nous avons bien l'intuition qu'il y a là un problème. Cette intuition provient précisément de ce que nous attribuons implicitement une propriété au système observé : un système qui sait ce qu'il fait ne devrait pas vouloir effacer un fichier qui n'existe pas, n'est-ce pas ?

Sans vraiment en avoir conscience, nous faisons donc bien la distinction entre un fonctionnement (théorique) attendu et un fonctionnement (constaté) anormal par l'observation qu'une pré-supposée propriété n'est pas respectée. À première vue, cette propriété semble devoir être valide «à tout instant de la vie du système observé», elle ne varie pas pour le système considéré (et parfois, elle peut être transposée à d'autres systèmes plus ou moins analogues). C'est propriété est souhaitée invariante, c'est un invariant du système.

Paradoxalement, il n'est pas faux de dire qu'un invariant devient réellement intéressant que lorsqu'il n'est pas respecté. On dit également qu'il est «cassé». En effet, généralement un invariant caractérise le bon fonctionnement d'un système, ou plus exactement ce qui est observable quand tout fonctionne bien. Mon système informatique ne se contente pas de créer ou d'effacer des fichiers, mais le fait qu'il ne cherche jamais à effacer des fichiers inexistants contribue à définir son bon fonctionnement alors qu'inversement, lorsqu'il cherche à effacer un fichier inexistant, il y a anguille sous roche, selon l'expression consacrée... Un invariant, ou un ensemble d'invariants, agit donc comme un détecteur de problème ... potentiel!

Le fait qu'un invariant soit cassé n'est pas synonyme de catastrophe automatique. Mon système fonctionne très bien après avoir échoué sur l'effacement de plusierus fichiers. Mais cela révèle néanmoins qu'une partie du fonctionnement du système n'est pas complètement, globalement maîtrisée. Et chacun sait, que cela peut être le début d''un problème ultérieur bien réel.

Revenons à notre paquet fakeroot.

Les habitués de la gestion debian/ubuntu auront probablement eu l'intuition de la cause réelle de cet affichage parasite in fine sans réelle gravité. Les fichiers concernés étaient effectivement présents antérieurement lors de l'installation du paquet fakeroot mais l'utilisation du paquet localepurge engendre la suppression des fichiers concernant les langues étrangères à l'utilisateur (e.g. les traductions des pages de manuels en espagnol ne m'intéressent pas vraiment).

T=avant T0, installation du paquet localepurge
T0, installation du paquet fakeroot avec l'intégralité de ses fichiers
T0+quelques secondes, localepurge efface directement les fichiers de langues étrangères dont ceux de fakeroot
T0+un certain temps, désinstallation de fakeroot, qui tente d'effacer des fichiers qui ne sont plus là !

Avec le séquencement d'évènement donnés ci-dessus, il est facile de déduire que le mis en examen sera le paquet localepurge, celui-ci effaçant d'autorité des fichiers ne lui appartenant pas afin de suivre une politique globale de nettoyage d'installation par élimination de fichiers considérés comme inutiles.

Et quelle est la justification «juridique» cette mise en examen ? Tout simplement parce que ce paquet casse un autre invariant ! Et oui, dans une gestion de système par paquet, une règle basique de cohérence (c'est à dire un invariant à préserver) étant qu'un paquet ne peut modifier que des fichiers lui appartenant.

Si notre premier invariant s'applique a priori à un système informatique quelconque, en revanche ce dernier invariant est spécifique aux système gérés par paquet, et peut-être même uniquement les systèmes dérivés de Debian (à vérifier).

Le concept un peu abstrait d'invariant est donc central lorsque l'on cherche à caractériser ce qui constitue le bon fonctionnement d'un système, d'un logiciel. On peut raisonnablement affirmer que ce qui est identifiable comme un bug (de gravité très variable) est systématiquement la rupture d'une ou plusieurs propriétés invariantes.

Et déterminer, expliciter les propriétés cassées, c'est également déterminer une manière optimale de corriger les problèmes.

Normes et formalisation B (I)

2010-11-17T03:22:00.000-08:00

Avertissement : Compte tenu du sujet particulier évoqué ci-dessous, il est encore «plus vrai que d'habitude» que ce qui est écrit ne reflète que mon point de vue personnel sur la question.

Précaution 1 : N'ayant pas l'intention de faire un billet pédagogique ou de référence, aucun rappel technique, contextuel ne sera fait. Je suppose le lecteur intéressé suffisamment informé de la problématique.

Précaution 2 : La terminologie utilisée est largement approximative, il ne s'agit pas de couper les cheveux en 4 mais plutôt de discuter de l'«esprit des choses». Par exemple, si le terme «certification» possède plusieurs définitions précises selon les contextes, l'utilisation faite ici reste conceptuelle : grosso modo, on voit bien ce dont il est question.

Mes collègues se posent sérieusement la question d'utiliser du B dans leur développements logiciels ferroviaires. Un gros paquet de questions tourne autour de la certification.

Dans le domaine ferroviaire, et en particulier les aspects contrôle-commande, le cadre normatif est constitué des normes 50128/50129, normes dérivées de la norme CEI 61508 (cf google ;-). Ce cadre ne traite pas spécifiquement du cas B, ni d'ailleurs du cas UML, de Lustre ... Les normes sont généralement très générique en ce qui concerne les technologies particulières employées. Sinon, on ne s'en sortirait pas hein.

Donc, il revient à l'organisme de certification de dériver sa méthodologie «spécifique B» de celle suggérée par le cadre normatif. On pourrait formuler : appliquer à B l'esprit de la norme 50128, ou plus exactement, appliquer au processus de développement intégrant du B...

Quel est l'esprit de la 50128 ? Vaste question. Pour faire bref, la norme vise essentiellement à s'assurer que, dans le cadre du développement d'un système critique (comportant du logiciel en l'occurence) :

les personnes impliquées dans le processus sont compétentes à la hauteur des exigences
le fournisseur annonce l'existence des phases de développement exigées par les niveaux de criticité du système développé. Plusieurs documents de type «plans» sont à fournir.
le fournisseur produit les documents qui matérialisent l'existence et donc la réalisation effective de ces phases
l'ensemble de ces documentations présentent de bonnes propriétés (au premier rang la traçabilité) qui permettent d'établir un niveau de confiance adéquat sur les deux affirmations suivantes :

le système a été développé correctement (le comment)
le système développé est effectivement celui attendu (le quoi)

Voilà, pour simplifier. Reste à transposer à B, c'est à dire aux phases et artefacts produits lors du sous-processus de développement formel par B.

Le développement B c'est globalement l'écriture [itérative ou cascade] de spécifications (abstraites, raffinement, implémentation), la réalisation des preuves de cohérence de cette spécification, la génération automatique de code. Le tout étant assisté par un atelier logiciel (dont une version «publique» est disponible gratuitement).

On peut mettre de côté l'homologation des outils supports, on va |"admettre" que pour une version donnée des outils B, celle utilisée pour les gros projets, le problème n'est pas là. Les outils sont «certifiés/iables» (rappel de la précaution en préambule, cette formulation n'a pas vraiment de sens reconnu, mais on voit ce qu'elle prétent affirmer). Dans la pratique, les outils sont validés par l'historique de leur usage (e.g. le compilateur gcc est validé par la densité de son utilisation). Ici, l'industriel maintiendra une version spécifique utilisée et «ayant fait ses preuves» (sans jeu de mot) au cours de son expérience passé.

En particulier, comment se passe la certification vis à vis des preuves ?
Est-ce qu'il suffit de dire qu'on a développé le logiciel et prouvé à 100% avec l'Atelier B pour éviter à avoir à montrer des tests unitaires et d'intégrations, ou il faut en faire plus ?
Quoi ? Montrer des logs de preuves mécaniques ?

La phase de preuve se décompose généralement en preuve automatique et en preuve intéractive. La preuve automatique n'est pas remise en cause puisque réalisé par un outil ... satisfaisant aux exigences de fiabilité. Par contre la preuve interactive peut être réalisée par l'ajout manuel de règles dites «règles ajoutées». Ces règles doivent faire l'objet d'une phase de validation, c-a-d démontrer qu'elles n'introduisent pas d'incohérence dans le système de preuve. Boum, 50128, cette phase doit avoir été prévue et doit faire l'objet d'un document qui démontre sa réalisation effective. Il faut donc un document de «Validation des règles ajoutées».

Les preuves automatiques, sous-entendu, réussies n'ont pas vraiment d'intérêt sémantique et la manière la plus simple de vérifier leur existence consiste à dispose du modèle B, de l'atelier support et à appuyer sur le bouton de preuve pour vérifier le taux de preuve annoncé dans les rapports de développement. Certes, cela n'est pas toujours matériellement possible. Tout dépend des conditions (logistique) prévues pour le déroulement de l'audit (vaste sujet également...)

Des morceaux de code B ?

Si on a accès à des morceaux de code B, alors l'accès au modèle complet ne devrait pas être utopique ... Cela dit l'audit du modèle B, en pratique, revient à un échantillonnage de morceaux de modèles B.

Détailler les invariants de liaison ?

Fondamentalement, le travail d'audit ne consiste pas à essayer de trouver des failles dans la stylistique du développement, surtout lorsqu'il est formel et a priori prouvé, auquel cas les invariants de liaisons sont «corrects».

Par contre, ce qui est pour le moins fondamental, c'est de vérifier que les invariants (de liaison ou pas), qui constituent les fondations d'un développement B cohérent, sont effectivement la transcriptions des propriétés attendues du système. Propriétés qui se trouvent nécessairement décrites (dev critique, 50128, etc) dans la documentation amont du projet. Donc la traçabilité entre les exigences / propriétés exprimées informellement dans la documentation projet et les assertions logiques B (essentiellement les invariants) est LE critère fondamental a évaluer.

Faire quand même des tests ?

Pour éluder le débat, il est considéré comme acceptable de ne pas tester unitairement les fonctions «atomiques» développées en B. Par contre les test d'intégration reste évidemment nécessaires car il n'y a aucune garantie formelle de bon comportement lorsqu'on assemble un composants formel et un composant classique, ni même en assemblant deux composants formels développés séparément. Le point non maîtrisé étant ici les intéractions entre composants, intéractions non modélisées, non formalisées.

Côté documentation, que doit-on donner ?
Des explications sur le programme B ?
Des explications sur le lien entre spec informelle et spec formelle ?

Le raisonnement pourrait être le suivant : un modèle B, c'est à dire l'ensemble des spécifications formelles, peut-être considéré comme l'ultime documentation du code effectivement généré et in fine embarqué.

À ce titre, le modèle B étant dès lors une documentation, il peut être demandé/fourni lors d'un audit.

De même, considéré comme documentation, il doit respecter les exigences de liaisons (traçabilité) entre les documents en amont («d'où vient ce texte B?») et les documents en aval (ici le code généré donc par définition mécaniquement traçable).

Burned to be a live

2010-09-17T00:58:00.000-07:00

Actuellement, dans l'objectif de la journée logiciels libres organisée par la médiathèque de Valenciennes (19 octobre), nous cogitons à la fourniture d'une distrib live (dérivée d'ubuntu) avec pleins de morceaux de chocolats à l'intérieur...

Rien d'extraordinaire jusque là, il existe maintenant foultitude de méthodes / manières / outils de se procurer une live (cd ou usb) plus ou moins customisée. Sauf que, généralement ces distributions ont une durée de vie très limitée car elles ne sont pas maintenues.

Pour faire bref, la raison essentielle en est que la customisation est artisanale, se fait à la mimine et généralement ce savoir faire là se perd ou n'est pas transmis.

L'initiative BTBAL («Burned to be a live») est précisément destinée à éviter cela. Le principe est simple : tout ce qui est nécessaire à la construction / génération de la distrib doit être scriptable. C'est donc stockable dans un dépôt (éventuellement géré en versions) que chacun peut récupérer pour reconstuire l'iso.

NB : Contrairement aux méthodes habituellement connues, BTBAL n'utilise pas une iso déjà fournie comme point de départ. L'utilisation des outils debian live-helper est suffisante pour obtenir une iso simplement à partir d'un répertoire de configuration, d'une connexion internet, d'espace disque (quelques Go) et de temps (très variable, selon CPUs disponibles)

Nous utilisons donc actuellement cette méthode pour enrichir un peu une ubuntu/lucid de base. C'est opérationnel. Plusieurs isos successives générées et testées en virtualbox jusqu'ici.

Tout ce qui est nécessaire est donc stocké dans la forge. La gestion de version permet de suivre exactement les modifs réalisées.

http://svn.gna.org/viewcvs/libre-nord/trunk/Burned_to_be_a_live

Ajout : Pour répondre au premier commentaire, je n'ai pas été assez précis dans mon explication.

BTBAL n'apporte strictement rien de plus que Debian Live-Helper puisque nous ne faisons qu'utiliser cette technique. Nous explicitons simplement cet usage en «déposant» (libre-nord/gna.org) ce que l'on peut considérer comme la «spécification exécutable» de la construction d'une iso customisée.

Je n'ai pas connaissance d'une distribution live proposant ce point d'entrée. Généralement, une image iso est fournie (la release). Les customisations ultérieures se font à partir de cette iso initiale. Mais comment celle-ci a-t-elle été obtenue ? ...

On s'approche donc ici d'une démarche de bootstrap .

Belle vue

2010-09-10T07:47:00.000-07:00

L'air de rien, il est assez difficile de trouver un fond d'écran satisfaisant pour un bureau de 3x1024 de large...

Voici donc ce que cela donne lorsqu'on en a un, à la bonne taille et avec un paysage sympathique...

Du coups, pour ne pas gâcher la vue, je n'ose plus ouvrir de fenêtres ...

claws-mail et bogofilter sont sur une install ...

2010-09-02T06:50:00.000-07:00

claws-mail est mis à jour (et/ou inversement bogofilter n'est pas mis à jour). Que se passe-t-il ?

Boum.

Visible de deux manières (en plus de la disparition de la fenêtre de lecture de courrier) :

(dmesg) [10982099.563884] claws-mail[15488]: segfault at 9000e ip 0021a1b0 sp bfd8e8e0 error 4 in libgobject-2.0.so.0.2400.0[1f0000+3d000]

** (claws-mail:16953): WARNING **: plugin loading error: /usr/lib/claws-mail/plugins/bogofilter.so

En fait, après inspection, il s'avère que claws-mail est en version lucid alors que bogofilter est resté en karmic (oui, je mets à jour incrémentalement selon mes besoins/envies). Le problème n'est a priori devenu perceptible qu'après avoir demandé à répondre à un gros message (900ko)...

Enfin bref, ça se passe mieux après mise à jour de bogofilter sauf que ...

dpkg -l | grep bogofilter
ii  bogofilter             1.2.1-0ubuntu1  

ii  bogofilter-bdb         1.2.0-3ubuntu1  

ii bogofilter-common 1.2.0-3ubuntu1

Les versions ne sont pas homogènes... C'est quand même pas optimal.

Tout ça pour dire que même si la mise à jour incrémentale, en douceur, par petits bouts, d'un système "à la debian" est possible ce n'est absolument pas un argument de stabilité du système.

In fine, la mise à jour (globale) la plus stable c'est la réinstallation.

Nez à nez incongru

2010-08-25T17:17:00.000-07:00

Petite histoire véridique du jour...

Depuis quelques temps les «voitures google» sont revenues sur le devant de l'actualité. Ces voitures un peu spéciales sont équipées d'un mat de pratiquement deux mètres sur leur toit. Ce mat porte plusieurs appareils photographiques probablement très sophistiqués, disposés en éventail de manière à capter automatiquement des images de l'entourage de la voiture, images qui seront ensuite traitées pour alimenter les bases du service Streeview proposé par Google.

Il était question justement de ces voitures dans les informations que j'écoutais sur le trajet de retour boulot/maison. Et notamment de la polémique induite par le fait que ces voitures «spéciales» auraient également mémorisé des informations concernant les connexions wifi captées lors de leurs déplacements.

Indépendamment de cette polémique, je pensais alors au fait que mon domicile était effectivement bien visible sur Google StreetView, y compris «côté jardin». Il faut savoir que l'accès à mon domicile nécessite d'entrer par un passage assez étroit, donnant accès à un clos constitué d'une poignée d'habitation. Pour avoir une vue côté jardin de mon domicile il faut néanmoins le contourner et se retrouver ... dans une impasse.

J'imaginais donc que la voiture Goolge s'était engagée dans le clos, pensant ressortir ailleurs et, se retrouvant dans l'impasse, avait probablement fait piteusement demi-tour afin de ressortir... par l'entrée!

Mon trajet de retour se terminant, je m'apprétais donc à m'engager dans le passage étroit pour entrer dans mon clos, lorsque je me suis retrouvé nez à nez avec un véhicule... équipé d'un mat supportant un éventail d'appareils photographiques !

Ma première surprise a été bien vite remplacée par la seconde : le véhicule n'affichait pas de marquage «Google» mais je pouvais lire bien clairement «Mappy.fr» !

Serait-ce donc que Mappy.fr envisage un service analogue/concurrent de Google ? Ou alors, plus simplement, que Google sous-traite à Mappy, la collecte des images photographique ?

Confirmation : http://www.pcinpact.com/actu/news/57537-mappy-urbandive-car-eathmine-cartographie.htm

Uptime

2010-06-09T00:19:00.000-07:00

J'ai pas trop suivi cette année le déroulement du tournoi de Roland Garros. Néanmoins, j'ai entendu au détour d'un reportage une information qui m'a fait sourire.

L'élimination de Federer devait lui être particulièrement rageante (contrairement à la zen-attitude affichée en conférence de presse) car il était sur le point d'égaler puis de battre le record du nombre de semaines passées en tête du classement ATP. Ce record est actuellement de 285 semaines et il est détenu par P. Sampras.

À chacun son uptime à battre :)

Plone-4.0b2-UnifiedInstaller

2010-05-01T12:16:00.000-07:00

Ayé, je viens de réussir l'installation d'un Plone 4.0b2 par UnifiedInstaller récupéré sur le launchpad Ubuntu.

Comme ça ne s'est pas fait du premier coups, voici juste le mémo de la méthode utilisée.

Contexte un peu étonnant : il s'agit d'une machine installée Ubuntu Remix et qui me sert de Média-Center-À-Tout-Faire. En particulier la motivation initiale de cette installation est d'avoir un Plone de base opérationnel afin de comparer sa configuration d'origine avec celle d'un Plone 3.0 ayant visiblement un problème de fonctionnement.

La commande d'installation utilisée est en définitive la suivante :

./install.sh standalone --password=[...] --instance=[...] --with-python=/usr/bin/python2.6

Les tentatives précédentes ayant échoué sur l'installation d'un python2.6 local à l'installation (qui se fait par défaut dans /usr/local/Plone ), je me suis résigné à utiliser le python 2.6 système, d'où l'utilisation de l'option with-python.

Il a fallu néanmoins installer quelques paquets complémentaires. (notamment parce que le processus d'installation recompile pas mal de trucs python, si j'ai bien vu). Une méthode radicale pour connaître la liste exact des paquets utilisés lors de l'exécution d'une commande consiste à préfixer cette dernière par l'appel à dpkg-depcheck

Dernière minute : dans un chroot Debian/Squeeze, la commande orthodoxe (avec installation/compilation de python2.6) fonctionne du premier coups, simplement après installation du paquet build-essential (normal)... Ça vous fait l'installation d'une instance Zope à 700Mo environs (c-a-d sans nettoyer le chroot).

L'intérêt d'une installation en chroot (la machine virtuel du pauvre), c'est votre installation Zope/Plone est dans une bulle système relativement étanche et facilement déplaçable ou copiable. Très pratique pour les tests, mises à jour ...

Bon, maintenant me reste plus qu'à trouver la différence entre mon Plone 3.0 dégradé et ce Plone 4.0 tout frais.

Note : a priori, Plone 4.0 s'avère sympathique au premier abord... semble un peu moins austère... Évaluation à poursuivre.

Plone 3.3.4 et LDAP

2010-04-12T06:07:00.000-07:00

Petit billet juste pour indiquer, enfin confirmer, que connecter Plone et LDAP c'est faisable !

Le plus difficile c'est de s'y retrouver dans l'éparpillement des docs, tutos disponibles sur le net, et cela en fonction des diverses versions impliquées de Plone (2.5, 3.0, 3.0+, ...) et des méthodes choisies, plus ou moins directes avec recours à des extensions différentes (à première vue).

Moi-même, j'étais parti sur la piste la plus récente et potentiellement la plus simple (Plone + plone.app.ldap) mais pas moyen, je passais d'une erreur connue à une autre, sans avoir de réelle piste de correction.

En désespoir de cause, je me suis rendu sur l'irc #plone-fr, habituellement très silencieux... et surprise, on (merci «jeanmat:») m'indique que ça fonctionne avec la solution classique Products.PloneLDAP, même sur un Plone récent (3.3.4)...

Après quelques tatônnement, une première étape est franchie : l'instance Plone interroge correctement le LDAP même si celui-ci n'est pas encore utilisé pour authentifier réellement les utilisateurs.

Moyennant quelques échanges avec notre admin système, donc admin LDAP, j'ai actuellement une instance Plone qui authentifie correctement les utilisateurs par LDAP.

Pour résumer : Plone 3.3.4 (unified installer), avec Product.PloneLDAP et python-ldap dans le buildout.cfg, le tout dans un chroot debian python-2.4 et python-ldap 2.3.10-1+b1

La seule doc réellement disponible c'est celle fournie par le produit Products.PloneLDAP, qui date un peu, et qu'il faut donc décoder dans un contexte d'installation Plone récente.

Bref, quand ça marche, c'est pas très compliqué.

Petit schéma, pas transcendant mais descriptif. Seule la partie encadrée rouge est utilisée actuellement.

Il peut être étonnant et même frustrant que les solutions récentes, modernes et potentiellement les plus simples se révèlent parfois plus difficiles à mettre en oeuvre que les vieilles méthodes quasiment obsolètes...

Une explication simple peut être proposée : ces solutions modernes se basent généralement sur le paradigme de la «sur-couche» destinée à cacher la complexité réelle d'une adaptation (vis à vis des couches inférieures). Reste que toute sur-couche ajoute en fait un niveau d'indétermination car celle-ci doit être évidemment adaptée / compatible à la couche inférieure (ou inversement).

La solution Product.PloneLDAP fonctionne encore parce qu'elle s'adresse directement à l'infrastructure en place et n'apporte pas d'exigences sadditionnelles, comme plone.app.ldap, sur les librairies complémentaires disponibles dans le contexte (python, ldap, openssl et cie).

Plone Atreal MailServices

2010-03-26T05:16:00.000-07:00

Je continue la mise en place d'un intranet (plutôt expérimental mais de moins en moins)

ou gestion électronique de documents (GED) sur la base du CMS Plone.

Un point fort de Plone c'est la multitude de "produits" (ou extensions, ou plugins) disponibles

pour compléter les fonctionnalités du portail Plone.  C'est également un point génant car la

multitude pose le problème du choix (hors de question de tester les produits disponibles à tour de rôle).

Je souhaitais une extension capable d'envoyer un message de manière sélective

(utilisateurs et/ou groupes)  notamment pour diffuser les nouveautés de l'installation aux seuls

collègues concernés par l'expérimentation.

Le produit testé, que je voulais très simple est actuellement : MailServices développé par Atreal.

Et bien c'est exactement ce que je voulais.

Ci-dessous, une traduction perso du README

Généralité
MailServices permet l'envoi de messages aux membres, groupes du portail.

Description

* Cette extension très simple vous permet d'envoyer des messages à des groupes, à des utilisateurs simplement en les sélectionnant.

* Elle vous permet également d'envoyer des messages à des personnes qui ne sont pas membres du portail mais sans aucune vérification (pour l'instant).
* Elle ajoute une action "service mail" qui fonctionne de la même manière que l'action classique 'send_to', mais vous permet de choisir vos destinataires par sélection dans le panneau "groupes/utilisateurs".

* Elle ajoute également une "action utilisateur", qui fonctionne également de la manière décrite ci-dessus.

* Le gestionnaire peut déterminer dans le panneau de control de configuration du produit :

- le sujet par défaut

- le corps du message par défaut

- s'il va recevoir une copie de chaque message expédié

- si les utilisateurs peuvent envoyer des messages à des non-membres

* Les messages sont expédiés avec l'adresse de l'utilisateur. Par sécurité, cela ne peut être modifié.

Important
La permission est définie pour les gestionnaires et les membres.

Note

L'installation de la version testée (1.0.0 beta) se fait classiquement par eggs/zcml dans le buildout.

Puis activer le produit à partir du panneau de gestion des produits.

Conclusion

Très bon produit car  il réalise très simplement et correctement une fonction basique mais bien pratique.

Installation facile (mais pas vraiment documentée). Pas de dépendance pointilleuse.

Monsieur et Madame ont une adresse mail ...

2010-03-03T04:04:00.000-08:00

... et une seule !!

Non, il ne s'agit pas d'une nième devinette «Monsieur et Madame», mais simplement du constat (fréquent?) que dans un foyer, équipé internet, Monsieur et Madame partagent souvent un unique compte de messagerie, le plus souvent au nom de Monsieur. Çe qui donne :

Pour : marc.duchmol@fai.internet

Sujet : Joyeux anniversaire Sophie !!

En espérant que Marc ne réponde pas : Merci pour elle !

Et ben moi, ça m'horripile... Le seul aspect sensé être positif de cette utilisation commune de la messagerie serait que cela dénote une confiance élevée dans le couple... un peu comme avec le compte commun à la Banque quoi...

Mouai, bof, c'est moyennement convaincant.

En revanche, plusieurs connotations négatives pourraient être ici évoquées :

Fainéantise, ou flemme d'utiliser complètement et proprement les technologies modernes : «Faut faire des réglages...»
Contrôle, bridage du conjoint (implicite, subsconcient?) vis à vis de l'accès à ces mêmes technologies.
Transposition du «machisme banal(isé)» ? En voiture, c'est toujours Monsieur qui conduit (i.e. maîtrise le véhicule) n'est-ce pas ? Ben c'est Monsieur qui relève le courrier électronique ; Toute une technique qu'il ne faut pas laisser à n'importe qui !

En tout cas, l'un des points les plus négatifs, c'est que ça complique énormément les choses si l'on veut préparer une surprise à l'un des deux conjoints sans que l'autre le sache... (oui, c'est du vécu !)

PS : À la maison, chacun à son adresse électronique, même la petite dernière. Tout fière de rédiger (presque toute seule) des messages à sa marraine adorée, avant d'avoir l'age de faire du chat, cette fois vraiment seule, avec ses copines de classe.

Niveau 2 : Et, dans le cas d'adresses électroniques personnelles, qui connaît le mot de passe de l'autre ? ... hein ? ;)

Segfault festival

2010-02-26T05:44:00.000-08:00

Depuis quelques temps, des segfault sont (de plus en plus?) régulièrement détectés dans les logs de différentes machines

[2319728.817595] epiphany-browse[6395]: segfault at 0 ip 016bfd04 sp bfc1e380 error 4 in libwebkit-1.0.so.2.17.2[d7b000+d7f000]

[8480.688581] ntop[7624]: segfault at 8 ip b766dd0f sp b21189f0 error 4 in librrd_th.so.4.0.0[b7665000+2e000]

[857832.312321] munin-update[16837]: segfault at 756c6176 ip b7b4b54a sp bf83e410 error 4 in librrd.so.2.0.8[b7b3f000+41000] [858432.788318] munin-update[17359]: segfault at 756c6176 ip b7ba354a sp bf997200 error 4 in librrd.so.2.0.8[b7b97000+41000] [858732.572310] munin-update[17634]: segfault at 756c6176 ip b7b7e54a sp bfe71ed0 error 4 in librrd.so.2.0.8[b7b72000+41000]

[4121727.202715] monit[3800]: segfault at 48 ip b7f82397 sp bfab9174 error 4 in libpthread-2.7.so[b7f7c000+14000]
[4121830.967499] monit[7458]: segfault at 48 ip b7f2f397 sp bf866ea4 error 4 in libpthread-2.7.so[b7f29000+14000]

3 chamonix kernel: [1070104.300593] console-kit-dae[5096]: segfault at 201 ip 00000201 sp bfd07d1c error 4 in console-kit-daemon[8048000+1e000]

Jun 29 11:51:59 kylix kernel: [   65.981476] nm-applet[5649]: segfault at 00000008 eip 0805b02b esp bff7f6c0 error 4

 unetbootin[24516]: segfault at ec83e589 ip ec83e589 sp b42a734c error 5

[89097.539259] operapluginwrap[24485]: segfault at 0 ip (null) sp bf8b5cfc error 4 in libXt.so.6.0.0[110000+4f000]
[89097.575033] operapluginwrap[24486]: segfault at 0 ip (null) sp bf9791cc error 4 in libstdc++.so.6.0.13[110000+e9000]
[89097.609204] operapluginwrap[24487]: segfault at 0 ip (null) sp bfb8427c error 4 in libuuid.so.1.3.0[110000+3000]
[89105.066478] operapluginwrap[24536]: segfault at 0 ip (null) sp bfe8da2c error 4 in libxcb.so.1.1.0[110000+18000]

[88963.641975] file-roller[24118]: segfault at 5b ip 080600a8 sp bfc5b9a0 error 4 in file-roller[8048000+52000]

[11314705.647089] pdftohtml[18302]: segfault at 0 ip b7dd052f sp bfbdf290 error 6 in libc-2.9.so[b7d5d000+13b000]

...

«Voler n'est pas partager !»

2010-02-19T03:58:00.000-08:00

Le titre est une dérivation humouristique (et même sarcastique) de l'expression actuellement à la mode «Partager n'est pas voler !».

Replaçons très brièvement dans le contexte. Ce «slogan» est régulièrement utiliser par les opposants à la loi Hadopi (et autres dérivées) pour exprimer qu'une confusion serait artificiellement entretenue les notions de piratage, de copie, de partage... En gros, copier une oeuvre culturelle (généralement musicale) n'est pas un piratage, c'est un partage ! nuance...

Les défenseurs de cet argument assoient ce point de vue en reprochant à leurs adversaires de ne pas être capables de faire la distinction entre le monde matériel et le monde numérique. En d'autres termes, que leur «logiciel légal» est rendu obsolète par les évolutions technologiques. En effet, dans le monde numérique, quasi virtuel, le vol n'existe plus car une copie ne peut être la soustraction physique de «la chose d'autrui», définition juridique du vol.

Pas de physique, pas de vol. Et hop, problème réglé.

C'est ici que surgit l'analogie de la baguette du boulanger. Elle est généralement utilisée pour illustrer le pirate qui n'hésite pas à se servir sur les rayons et à repartir sans payer la fameuse baguette qu'il emporte sous son bras.

Mais le geek, défenseur du partage culturel, s'indigne alors en prétextant que cette analogie est fausse puisque le bien volé est matériel et non pas numérique et duplicable, quasi gratuitement, à l'infini.

Soit. Admettons. Mais prolongeons alors l'analogie par «numérisation» de la baguette. Supposons donc que la baguette se duplique aussitôt volée, pardon, on doit dire «partagée». Ah ben oui, évidemment, une fois sorti de la boulangerie le pirate s'empresse de partager la baguette avec l'intégralité de ses réseaux sociaux, plutôt que de la déguster égoïstement car solitairement.

Donc la baguette se duplique. Plus de problème. Le propriétaire de la boulangerie n'est pas lésé, il peut toujours la vendre. Heu, oui... mais à qui ? Qui serait assez stupide pour aller payer une baguette alors qu'il peut l'obtenir gratuitement par le truchement d'un réseau de contact ad-hoc ? Pas grand monde.

Le constat est simple : il est très peu probable que le modèle économique de la baguette «virtuelle donc partageable» tienne la route bien longtemps. Mais après tout qu'importe ? qui serait véritablement lésé par la disparition de la boulangerie ? ben oui, la baguette volée reste partageable à l'infini par son nouveau «propriétaire»... Donc, à première vue, pas de problème. Il y aura toujours de la baguette à ~~vendre~~ partager. À première vue seulement.

Développons complètement l'analogie... La baguette c'est le fichier musical mp3. Le passant accusé (injustement bien sûr) de vol c'est l'internaute. L'artiste, c'est ? ... c'est ? Ben facile : le boulanger, celui qui est au four, et même mieux : l'ouvrier boulanger... Et il me reste encore un rôle à distribuer, celui du (méchant) directeur de la «major», j'ai nommé le ... propriétaire de la boulangerie, qui éventuellement n'y connait rien en boulangerie/musique et se contente d'empocher les bénéfices de sa (ou ses) boutique(s).

Nous avons donc bien reconstituer la chaîne : le propriétaire «exploite» le boulanger-chef, qui à son tour éventuellement «exploite» l'ouvrier apprenti qui bosse au fond de la ~~mine~~ boulangerie pour à peine le SMIC. Le tableau est donc bien posé.

Il y a deux détails qui rendent indéfendable le slogan «Partager n'est pas voler».

Le premier est que l'acte de partage d'une oeuvre ne peut être décidé que par le propriétaire (sinon l'auteur) de l'oeuvre. Ainsi, le partage de la baguette virtuelle ne serait pas un problème s'il provenait de l'intention de l'apprenti, du boulanger ou du propriétaire. Mais rien ne légitime le passant-pseudo-client a imposer sa conception du «partage».

Le second est que la notion de reproduction ou diffusion n'est absolument pas «constitutif» de l'oeuvre culturelle. Il est donc trompeur de raisonner sur la question de savoir si la diffusion numérique «non régulée» est un partage (donc bénéfique) ou un piratage (donc néfaste). Le véritable foyer de la culture n'est pas sa diffusion mais surtout sa création.

Et l'analogie de la baguette virtuelle, atteignant ici sa limite, démontre cela de manière flagrante. En effet, la baguette virtuelle indéfiniment reproductible supprime donc l'éventualité d'une pénurie de baguette. Mais il n'est question que de la même baguette. Il n'est d'aucun intérêt de se contenter d'une source inépuisable de baguettes, toutes identiques, probablement délicieuses mais avec un goût identique.

Avec la musique, les films, l'essence même de culture vient de l'unicité, de la singularité de chaque création. Le problème n'est donc pas de permettre (ou pas) la duplication d'une oeuvre mais il est dans la préservation du potentiel créatif. Or, le problème du créateur (ouvrier-boulanger) n'est pas tellement qu'on lui copie/vole un exemplaire de la baguette mais plutôt qu'on lui vole, en détruisant la viabilité de la boulangerie, son moyen de subsistance, ce qui lui permettra de créer d'autres baguettes ou pains, avec des goûts différents...

Le slogan «Partager n'est pas voler !» est tout simplement une arnaque intellectuelle.

Tuyauterie (MAJ)

2010-02-03T20:00:00.000-08:00

Début de la cartographie de mon installation @home. Histoire d'y voir plus clair.

Ce qui est amusant c'est que le placement global (pas facile de ranger les éléments graphiques) provient essentiellement du «classement» par les prises de courant...

MAJ : Ajout d'un mini-PC «en dessous» de ma télé HD. C'est un Packard Bell (PB) imax mini, aucune motivation particulière à ce choix, excepté que c'était l'unique modèle dispo en rayon, respectant mes spécifications de base, avec un prix raisonnable, c'est à dire un peu moins cher que les ultra-portables à la mode actuellement.

Les truc qui restent à faire ou qui résistent :

Installation de ushare sur PC2. Même si la XboX détecte le partage ushare, refus de connexion/lecture. Problème réseau, soit-disant...
Bizarrement, le disque dure externe Ioméga reste "invisible" (même en USB). Panne ?

Sujet de stage (logiciels libres)

2010-02-02T07:49:00.000-08:00

Chaque année, c'est la même question. Est-ce que je propose un ou des stages, et si oui, comment diffuser au mieux le(s) sujet(s). Bon, ben petite innovation, je passe par ici...

Le sujet qui m'intéresse en ce moment est assez bien résumé ici, merci David ;)

J'ajoute à cette introduction la problématique du processus de développement de logiciels open-source. En effet, quoi qu'en dise le folklore du microcosme (limite propagande), aucune étude sérieuse ne démontre que le processus open-source produise «nécessairement» un code de qualité supérieure (au processus traditionnel). Il y a évidemment des réussites emblématique mais aussi beaucoups de déchet(s).

L'idée proposée ici est de compléter le développement «bazar» open-source par un outil permettant de définir des propriétés, contraintes sur le code cible afin d'en réduire les bugs et/ou problèmes de sécurité.

Le travail de ce stage consiste donc à étudier les différents outils avancés (certains cités par David) dont l'utilisation pourrait améliorer la qualité du code produit selon le critère fondamental du nombre de bugs.

Le candidat devra donc suivre la démarche suivante :

1- choisir un outil de «debug avancé» (la liste n'est pas encore arrêtée)
2- choisir un logiciel open-source intéressant
3- appliquer le premier sur le second et produire une synthèse des résultats.

On espère évidemment que cette synthèse donnera des pistes pour l'amélioration effective du logiciel cible (et par extension du processus de développement open-source).

Selon le choix réalisé, on pourra ultérieurement envisager une systématisation de la démarche à un ensemble de codes libres, probablement de type (language) analogue. Par exemple, l'utilisation de PyLint sur des logiciels développés en python.

La durée du stage pourrait être de 4 mois minimum, rémunération selon la législation en vigueur (et qui ne s'est pas améliorée ces derniers temps). Localisation : Campus LILLE 1 (Villeneuve d'Ascq)

Pour candidater ou avoir des précisions, me contacter par le biais des commentaires (qui resteront éventuellement privés).

m-a-j : «Google propose jusqu'à 1 337 dollars pour toute faille repérée dans Chrome». Comment répondre à ce genre de défi ? ;)

Ariane 501, à qui la ... faute ?

2010-02-02T06:23:00.000-08:00

De temps à autre, il m'arrive de donner des cours. Plus exactement, «un» cours, généralement intitulé (ou intitulable) «Introduction aux méthodes formelles pour le développement de logiciels critiques».

Le contenu de ce cours reste relativement classique (j'y reviendrai peut-être...), pas trop difficile je pense mais pas très drôle non plus. Aussi en guise d'introduction sympa, je commence par la projection d'une vidéo intitulée «Fiabilité des logiciels, de l’A380 à Microsoft» de mon éminent collègue David Monniaux (DM) (cf votre moteur de recherche favori pour télécharger la vidéo).

Cette vidéo constitue une bonne introduction à la problématique de ce que l'on appelait il y a quelques années «le logiciel zéro-défaut». Pourquoi n'est il pas si simple que cela de faire du logiciel sans bug ? La présentation réalisée est orientée grand public avec quelques morceaux du folklore habituel, comme le suggère le titre de la vidéo, un brin accrocheur...

Une fois la projection terminée, je laisse un peu de place pour en discuter et notamment pour apporter une contradiction à ce qu'indique DM dans l'exposé. Contradiction sur un point bien précis et bien célèbre qui fait partie du folklore de la «science appliquée du logiciel» (reformulation perso du terme habituel «génie logiciel») : le vol inaugural d'Ariane V, numéro 501, qui s'est terminé par une explosion déclenchée par sécurité au bout de 40s environs.

En effet, lors de sa présentation, DM indique que l'explosion est la résultante d'une «erreur informatique», et donc autre formulation, «une erreur logicielle». Je précise tout de suite que DM n'est pas le seul (loin de là) à reprendre cette formulation car, même si elle peut-être considérée comme fausse (c'est mon point de vue), elle n'en est pas moins confortable pour ceux qui l'emploi...

Pour ne pas entrer dans des discussions terminologiques inutiles, j'utilise délibérément un vocabulaire non scientifique mais probablement plus simple et/ou compréhensible. (Très) grossièrement une erreur ou un «problème» peut être classée dans trois grande catégories :

Elle peut être «logicielle», c'est qu'on appelle un bug ; «matérielle» lors de la défaillance d'un capteur, d'un moteur, ... ou «système» lorsque la défaillance ne peut pas être attribuée de manière unique à l'une des catégories précédentes.

Pour résumer, alors que DM et d'autres indiquent que le problème est ici de la 1ère catégorie, mon point de vue est qu'il serait plus exact de l'attribuer au «système». S'agissant de problématique «système», il faut encore préciser.

Dans la méthodologie de fabrication d'un système complexe, on peut encore distinguer deux aspects : les aspects dits «produits», c'est à dire les objets/artefacts (matériels ou logiciels) élaborés pour constituer le système et les aspects dits «processus», c'est à dire les méthodes (enchaînements d'étapes, phases) régissant l'élaboration des produits. Toujours en gros, les produits constituent le «quoi», les processus constituent le «comment».

Nous y voilà : le problème d'Ariane 501 est bien plus un problème «processus système» qu'un problème «produit logiciel» même si, au bout du compte, c'est effectivement par le comportement d'un logiciel que le problème est «révélé» (boum!).

La plus grosse «bourde» réalisée lors du développement de la partie logicielle du système Ariane V réside surtout dans la décision de réutiliser du logiciel Ariane IV sans prendre toutes les mesures nécessaires à la re-qualification du logiciel pour le nouveau domaine de vol (vitesses, accélérations et masses plus grandes). C'est à dire que le logiciel embarqué ne peut être rendu (seul) coupable puisqu'on lui a demandé de réagir dans un contexte pour lequel il n'était pas conçu!

La question qui se pose alors, et qui motive l'évocation quasi-systématique de ce cas dans les présentation techniques/scientifiques du domaine, «était-ce évitable ?». Sous-entendu : «En procédant autrement, pouvait-on éviter la catastrophe ?»

Au moins par deux fois dans le passé, la problématique Ariane 501 («à qui la faute?») s'est retrouvée sur ma «route» et dans les deux cas ma perception de cette question s'est retrouvée confirmée... et pas par n'importe qui !

(À SUIVRE...)

En attendant, une lecture complémentaire possible est ici : Design by Contract: The Lessons of Ariane

On y retrouve les aspects que je viens d'évoquer : l'erreur n'était pas seulement logicielle, le fait de l'affirmer permet de mettre en avant la problématique complexe des logiciels critiques, et j'en profite pour vendre ma méthode à moi qui aurait mieux fonctionné... Attention, c'est quand même Bertrand Meyer ! ;)

Zzzzzzzzz...en attitude

2010-01-20T03:27:00.001-08:00

Lu sur un blog quelconque (bah oui, tombé dessus en utilisant le bouton magique et aléatoire «blog suivant» disponible en haut de la présente page normalement).

«Si vous avez l'impression que vous êtes trop petit pour pouvoir changer quelque chose, essayez donc de dormir avec un moustique... et vous verrez lequel des deux empêche l'autre de dormir.» (Dalaï Lama)

Alors bon, le premier réflexe c'est de se dire «Excellent! Je garde, c'est bien vu, etc»

Sauf que, ben non. Ok, c'est effectivement le genre de maxime auquel on aimerait croire.

Sauf que, ben non. À la réflexion, les quelques moustiques qui ont un jour tenté de m'empêcher de dormir sont brutalement passés de la dimension 3 à la dimension 2 (plutôt 2,25...).

Certes, écraser un moustique n'est pas un acte envisageable dans la cosmologie de l'auteur cité.

Comme quoi, n'est pas Dalaï Lama qui veut.

Et si RMS se plantait ?

2010-01-16T03:59:00.000-08:00

Là je tente un truc dangereux... le post impulsif et qui plus est, contre une icône...

J'avais déjà une vague envie de prendre une certaine distance avec les propos (récents) de l'emblématique RMS mais là je viens de lire http://www.leprogres.fr/fr/france-monde/article/2578083,192/Richard-Stallman-L-informatique-a-restreint-nos-libertes.html (merci Daffy ;) et j'y trouve, à mon sens, des contre-vérités qui discréditent le discours tenu (et c'est bien dommage!).

(RMS) Si chaque utilisateur avait la liberté de donner 1 euro en appuyant sur un seul bouton pour acheter une œuvre, beaucoup le feraient

Argh... Ceci est une ... énormité.

En effet, cette affirmation ne pourrait être économiquement (et socialement) viable qu'à la condition qu'aucune autre possibilité d'appuyer sur le même bouton (oeuvre) n'existe... gratuitement !

En d'autres termes, la proposition de RMS n'est viable que si elle s'accompagne précisément des mesures nécessaires à l'éradication des solutions gratuites (et en l'occurrence illégales /je ne confonds pas avec l'offre «en licences libres»). Mesures actuellement incarnées par les lois contre les-quelles s'élève RMS dans son interview.

Parce qu'à choisir entre appuyer sur un bouton à 1 euro et un bouton gratuit...

(RMS) Elle [l'informatique] les a [nos libertés] restreintes !

Re-Argh... J'aimerai bien connaître un seul exemple de liberté que l'informatique ne permet plus.

La seule «liberté» qui est effectivement menacée par l'informatique (et internet en fait) c'est la «liberté» d'effacer les traces d'un acte (qu'il soit légal ou pas hein).
De manière corollaire, il devient difficile d'effectuer un acte de manière «anonyme» car il existe quelque part une trace établissant un lien entre votre identité virtuelle (pseudo/avatar) et votre identité tangible ou plutôt «administrative», celle qui établi vos droits d'accès/de services et accessoirement leur facturation...

Il reste que la «quantité» de liberté fournie par l'accès facilité à une multitude de services informatiques est sans commune mesure avec la probabilité que les réserves du paragraphe précédent ne vous cause de réels préjudices.

Ce qui est extrêment regrettable dans la dialectique actuelle de RMS c'est que, pour convaincre son auditoire, RMS entre facilement dans l'exagération et la caricature de ce qu'il dénonce. L'efficacité de la démarche est alors discutable car il est fort probable que la radicalité du discours ne séduise en fait que ceux qui sont déjà (les plus) convaincus...

(toujours RMS mais ailleurs, sur ZDnet ) Il invite ainsi à légaliser le partage afin que tous puissent partager des copies de n'importe quelles oeuvres publiées tant qu'aucun bénéfice financier n'est retiré de ce partage.

Euh, admettons... Mais là n'est pas le problème! Le problème réside non pas dans les bénéfices supposés des pirates mais dans le manque à gagner de la «chaîne de production» qui intègre les majors ET les artistes producteurs. Cet aspect fondamental de la question semble être complètement ignoré par RMS...

Ce qui m'inquiète un peu c'est que je retrouve dans le discours de RMS et dans la manière dont il est retranscrit par une certaine (blogo?)sphère, une dérive que j'ai déjà eu l'occasion d'observer dans un domaine qui n'a strictement rien à voir.

On y trouve au départ un éminent personnage qui, effectivement propose une innovation, ou une «rupture» dans le jargon actuel, innovation suffisamment importante pour élever au rang de gourou celui qui la porte (ou l'apporte, ça marche aussi!). Si au départ cette distinction est parfaitement justifiée, il reste qu'au fil du temps, le gourou se repose sur cette notoriété pour ensuite ajouter à son discours des éléments ou arguments bien plus discutables et confinant parfois à la contre-vérité la plus grossière.

Soyons précis, il ne s'agit pas d'affirmer que cette dérive est parfaitement délibérée, volontaire ou même consciente. Non. Il plus probable qu'à partir d'une certaine stature, ce genre de personnage, ne rencontrant plus d'objection (qui oserait aller contre ?), fini par s'auto-convaincre d'une sorte d'évidence ou de pertinence naturelle de leur point de vue. Celle-ci semblant découler de manière quasi héréditaire de leur contribution initiale. En effet, pourquoi se tromperait-il maintenant ?

Même si la «supériorité éthique» des logiciels libres sur les logiciels privateurs est une proposition à mettre au crédit de RMS, cela n'induit pas que toutes les pensées de RMS sur des sujets corollaires ou dérivés tels que l'éco-système de la production culturelle (éco au sens économique et/ou écologique ;), le modèle du cloud-computing, la dégradation mécanique des libertés par l'informatique, ... soient parole d'évangile.

Loin de là.

Profil numérique (draft)

2010-01-15T08:20:00.000-08:00

Gratuit ou pas gratuit, telle est la question...

2010-01-11T11:10:00.000-08:00

En cours de rédaction, publication anticipée pour info

Attention, ceci n'est pas une analyse détaillée de la stratégie Microsoft envers le corps enseignant. C'est juste une trace d'une petite discussion avec un enseignant justement. Il y a sans doute des pointeurs bien plus complet sur CETTE question.

D'après http://article.gmane.org/gmane.user-groups.linux.france.val-libre/3610 donc...

La question initiale était de déterminer l'exactitude de la «gratuité» de la suite Microsoft Office pour les enseignants.

Notons simplement que le site de promotion (http://www.microsoft.com/france/education/prim-sec/enseignants/office/home.aspx) n'utilise jamais le mot «gratuit» mais plutôt l'expression «télécharger sans frais».

L'expérience montre que la nuance, subtilement préservée par la formulation microsoft) suffit à générer des incompréhensions dans les discussions animées ;-)

Voici le lien le plus synthétique qui me semble répondre à cette question (et à d'autres) ...
http://www.microsoft.com/france/education/prim-sec/enseignants/office/faqs.aspx
Q3. Microsoft Office devient-il gratuit ?
R. Microsoft Office Professionnel 2007 n’est pas proposé gratuitement. [...]

Comme "prévu", la notion de gratuité n'est perceptible/effective que du point de vue de l'enseignant. Globalement, il y a évidemment une contre-partie. Pour en connaître les détails, quelques recherches sont nécessaires et l'on découvre que la gratuité accordée aux enseignants est mise en balance avec un volume de licences achetées par les établissements...

La stratégie est donc claire : il s'agit de favoriser la diffusion des logiciels (propriétaires) Microsoft parmis les enseignants car ceux-ci finissent par être prescripteurs. Prescripteurs envers leurs établissements (pourquoi se priver d'une offre aussi avantageuse ?), envers leurs élèves qui eux-même pourront profiter de la promotion analogue faite aux étudiants, étudiants qui seront eux-mêmes prescripteurs dans leurs emplois futurs (ou, à défaut, seront pré-formés)...

Quant à savoir si la démarche est pernicieuse ou n'est simplement qu'un geste commercial/économique, je pense que la lecture du paragraphe suivant est éclairante :

«Si vous avez besoin d’un logiciel destiné à être utilisé sur plus d’un ordinateur, vous devrez acquérir autant de licences qu’il y a d’ordinateurs à équiper.» (avant dernière réponse de la FAQ, tout en bas donc).

Il faut bien noter l'usage de la formulation très générale "un" logiciel, ce qui rend le paragraphe grossièrement faux. Un logiciel libre peut être installé autant de fois que voulu. Cette généralisation délibérément abusive me semble indiquer une intention qui frise la désinformation. On pouvait en effet se contenter de la formulation parfaitement correcte : si vous avez besoin d'un logiciel Microsoft ...

La clé du débat de l'autre soir revient in fine à savoir si ceux qui sont visés par cet accord, à savoir les profs, peuvent se contenter de ne voir que leur intérêt immédiat? Ce qui , dans un contexte de plus en plus difficile pour leur profession, pourrait être considéré comme parfaitement légitime.

La manoeuvre est particulièrement perverse car elle encourage l'enseignant à prendre la solution de facilité. Ou plutôt, elle le dissuade de prendre le chemin beaucoups plus ardu du choix d'une solution alternative libre (Open Office évidemment). Ce chemin est plus ardu car il exige de prendre à contre-sens les pentes les plus douces : renoncer aux habitudes déjà prises pour apprendre un nouvel environnement, endosser la charge de défendre la neutralité des enseignements visi à vis des entreprises commerciales, ...

Dans le même genre,
http://www.framablog.org/index.php/post/2009/10/20/universite-paris-descartes-microsoft,
«Même une direction rompue aux vertus du logiciel libre et sa culture aurait à mon avis du mal à ne pas sacrifier quelques unes de ses valeurs sur l’autel d’un certain pragmatisme dicté par le manque de moyens.»

Bonne année David Sapiro

2009-12-27T10:50:00.000-08:00

Encore (décidement!) une mésaventure qu'il me semble utile d'archiver tant elle donne une vue complémentaire du monde merveilleux de la communauté du Libre et des «bisounours» que l'on peut y croiser.

Tout a commencé de manière relativement anodine sur la liste plone-fr, suite à une question sommes-toute pertinente (j'aurais également pu la poser!). Le fil de discussion intégral est ici :

http://n2.nabble.com/Ou-on-en-est-pour-le-site-plone-fr-td3975585.html#a3976201

On y voit donc David Sapiro débouler dans la discussion et reprocher au premier intervenant de poser cette question de manière inconsidérée (pour le dire poliment).

Il me semblait alors la moindre des choses de faire comprendre à D.S. que le ton de sa réponse n'est pas franchement adapté à la teneur du questionnement.

Et c'est là que ça part en vrille car il y a deux choses que je ne savais pas :

D.S. est modérateur de la liste
D.S est visiblement un personnage à la limite du «traitement psychiatrique» comme le suggère l'un des intervenants de la discussion.

Très vite, tout s'accélère. Utilisant son pouvoir de modérateur, je suis illico-presto exclu de la liste sans autre forme de procès ou avertissement.

Mais cette manoeuvre ne m'a pas préparé à la suite hallucinante...

Voilà que dans la foulée, je reçois un coups de fil sur mon poste professionnel de David Sapiro en personne qui, ne me laissant pas la parole, m'innonde de menaces et d'insultes dans lesquelles il considère que «ma petite vie»(sic) n'ayant aucune importance pour lui, il ne verrait aucun inconvénient «à débouler pour voir si je ferai autant le malin»(re-sic). Ajoutons une dose de menaces légales pour le cas où j'oserai encore citer son nom (et/ou celui de sa boîte) où que ce soit...

En consultant un peu à droite et à gauche, j'apprends très vite que je ne suis pas le seul à avoir eu ce genre de mésaventure avec ce personnage et qu'il est préférable de laisser tasser et d'ignorer...

Ce que je fais jusqu'à ce que je constate que, même si les autres modérateurs m'avaient très rapidement ré-abonné, je reste (probablement le seul) inscrit "en modération" sur la liste plone-fr... C'est une sensation d'autant plus désagréable qu'imméritée (comparée à la violence du comportement de David Sapiro).

Mais il y a plus agaçant... En effet, je me suis également rendu compte, en discutant avec les autres modérateurs de la liste, qu'il y a toujours une personne pour défendre (je cite) «Effectivement, David à quelques défauts(!) mais il ne faut pas oublier ses contributions à la collectivité et ne pas jeter le bébé avec l'eau du bain».

En d'autre termes, il suffit d'avoir une certaine aura (que l'on supposera justifiée) pour que l'on puisse se permettre de ne pas respecter les principes élémentaires de la communauté, de la politesse ou simplement du respect d'autrui. J'ai déjà rencontré précédemment ce genre de réflexe...

Ne serait-ce pas là une forme de ce que l'on pourrait appeler le syndrome «Polanski» ?

Y'a plus de respect ...

2009-12-22T05:50:00.000-08:00

Sur le bureau d'un collègue qui restera anonyme... je suis trop bon.

Je laisse au lecteur un peu de gymnastique ... «cérébrale» ? :D

Des claques qui se perdent... (II)

2009-11-20T03:47:00.000-08:00

Bon, en fait, je pourrais tout aussi bien créer une catégorie «des claques qui se perdent» mais bon, ça m'obligerait aussi, à chaque fois, à trouver un titre original plus spécifique. Donc ;)

sudo apt-get install hevea=1.10-9
Les paquets supplémentaires suivants seront installés :
camlp4 camlp5 hevea ledit libjessie-ocaml-dev libocamlgraph-ocaml-dev ocaml ocaml-base ocaml-base-nox ocaml-compiler-libs
ocaml-findlib ocaml-interp ocaml-native-compilers ocaml-nox ocamlweb otags

Mais, sudo apt-get install hevea=1.10-5
Les NOUVEAUX paquets suivants seront installés :
hevea

La deuxième installation semble quand même plus intuitive que la première. Pourquoi cette différence ? En fait le paquet 1.10-5 est une recompilation perso de l'utilitaire (conversion LaTeX vers html) HeVeA en mode dit «natif». La version 1.10-9, tirée directement du dépôt Ubuntu (ou Debian, c'est kif-kif en l'occurrence), est elle fournie en mode «byte»(-code).

Les geek auront compris, mais très brièvement j'explique : HeVeA est développé à l'aide de l'excellent language OCaml, qui permet de générer des programmes binaires «compilés» soit en mode natif, et dans ce cas le programme est directement compréhensible par le CPU, soit en mode byte, et dans ce cas, un logiciel intermédiaire (l'interpréteur) est nécessaire pour exécuter ce programe «presque binaire». Sans développer la comparaison, indiquons que cette (vieille) technique est maintenant utilisé par nombre de langages modernes dont les programmes sont exécutés/interprétés sous la forme de byte-code (Java en tête de liste!).

Du point de vue utilisateur, la solution «byte code» nécessite donc l'installation de paquets supplémentaires (ocaml-base ocaml-base-nox ocaml-compiler-libs, ...) . L'avantage supposé de cette technique c'est que le développeur ne gère pas les soucis de portage sur les différentes architectures CPU, charge au client/utilisateur à se mettre en configuration pour être capable d'interpréter ce genre de programmes.

Mais ce dernier point n'est pas sans causer quelques soucis : Ainsi, dans le cas d'OCaml, il se trouve que la fourniture de base (contenant les compilateur et interpréteur) évoluent très régulièrement mais en créant au passage des incompatibilités. Moralité : l'utilisateur se retrouve régulièrement avec le casse tête d'une mise à jour globale OCaml alors qu'il souhaite simplement préserver le comportement d'un outil de transformation LaTeX vers html par exemple !

Obtenir une version native du paquet HeVeA ne demande que la modification de 2 fois 4 caractères (byte == native). Néanmoins, les développeurs Debian ont délibérément fait le choix (il y à quelques années) de privilégier une distribution byte-code (donc avec dépendances élargies) plutôt qu'une distribution native-code plus directe, naturelle.

Contrairement à ce que prétend le «Contrat Social Debian», il est manifeste que ce choix ne favorise que l'aspect packaging, développement et donc la partie développeur. En revanche, il ne reflète absolument pas le besoin de l'utilisateur.

Ce qui est un peu plus étonnant, après tout Debian n'a jamais eu vraiment une image «user-friendly», c'est qu'on retrouve donc le même principe de diffusion dans Ubuntu. Cela s'explique probablement par le fait que la base d'utilisateur de ce genre d'application est faible...

M'enfin bon, très régulièrement, lorsque je souhaite suivre les évolutions d'HeVeA, par ailleurs très bien développé, je me dis (en regardant la liste des dépendances in fine inutiles) qu'il y a des claques qui se perdent.

Des claques qui se perdent...

2009-10-30T04:52:00.000-07:00

Des fois je me dis que si je postais ici tout de suite après le jaillissement de l'idée, du coups de gueule, ... il y aurait probablement plus de «dynamique» dans mon rythme de publication. Les billets seraient probablement moins réfléchis mais un peu plus naturels sinon inspirés...

Mais là, bon, je me jette parce que ... euh, parce que !

Je m'apprétais à lancer une recompilation de noyau, comme ça, juste pour voir si ça recompile bien (*), c'est quand même la moindre des choses... Comme d'habitude, la première invocation du 'make' échoue, faut passer par l'étape de configuration (ma préférence va à 'make menuconfig').

J'accède donc à l'interface de configuration de compilation du noyau par menu, et je constate que dans tout ce qui activé par défaut, trônent en bonnes places de... l'EXPERIMENTAL !!

Indépendamment des risques effectifs amenés par ces options, je me demande vraiment si, Monsieur (presque) tout le monde à besoin, PAR DÉFAUT, d'activer des fonctionnalités expérimentales du noyau...

Il me semblait que, par défaut, un logiciel doit être configuré pour son usage le plus général... Là, je pige vraiment pas l'intérêt.

(*) Bon, honnêtement, c'est pas juste pour voir, mais c'est la première étape d'une exploration éventuelle de distcc et de ksplice...

Un bug ? c'est une propriété...

2009-10-24T02:00:00.000-07:00

... «cassée» !

Voilà une formulation qui résume au plus court ce que l'on pourrait qualifier de

«déformation professionnelle» (en ce qui me concerne) mais qui n'en est pas moins une transcription de ce qu'est la problématique de la «qualité logicielle». J'utilise cette terminologie pour éviter de rentrer inutilement dans le jargon spécialisé.

Bon, grossièrement, c'est quoi un bug ? Très vaste question mais que je résume ici à la phrase naïve «c'est quand ça va pas ...». L'utilisateur perçoit dans le fonctionnement du logiciel (quel qu'il soit) quelque chose qui ne «va pas», c'est à dire quelque chose qui sort du comportement ... attendu.

Il y a des bugs de toutes les tailles et toutes les couleurs, et à force d'en voir, le sujet de ce billet me titillait depuis longtemps. Il est revenu à la surface suite à l'observation d'un bug, d'apparence anodine et quasiment fugitif par ailleurs mais qui, avec un peu de déformation professionnelle, soulève une question profonde.

Voilà, je suis dans le TGV, je tapote un texte dans mon éditeur favori, emacs (le 22, version gtk pour les fanas). J'utilise (quand même un peu) ma souris, j'ouvre le menu "LaTeX" et, glissement involontaire ou mouvement du train, je clique deux fois ou je clique une fois et la souris glisse ou... enfin bref, je me retrouve avec deux menus ouverts ! Un seul des deux est réellement actif, le second dans l'ordre d'apparition. Le premier reste figé, immobile, quand bien même je viens de refermer le second !...

Un ou deux clics plus tard, tout est rentré dans l'ordre.

Rien de très grave, néanmoins, je ne _m'attendais pas_ à ce que deux menus puissent être affichés simultanément dans emacs. Et c'est effectivement très rares car apriori ce n'est pas prévu par le logiciel. Mais visiblement, cela n'est pas interdit non plus, bien que difficile à réaliser en pratique. (essayez!)

Déformation professionnelle : Pourquoi ce bug est-il possible ? Comment je le caractérise ?

Ce qui se passe fondamentalement c'est que le logiciel vient de «briser» une propriété que je lui attribuait. Ici, j'attribue cette propriété à emacs mais elle est en fait plus générale : un logiciel ne devrait pas permettre l'ouverture simultanée de deux menus.

Décortiquer le pourquoi du comment de ce bug précis peut-être assez complexe. En effet, intuitivement, on pourrait affirmer que c'est un bug emacs. Mais ce n'est pas si simple. Dans un système moderne, un simple clic déclenche toute une suite d'actions prises en charge par diverses briques logicielles (serveur graphique, gestionnaire de fenêtres, pilotes de matériel, application cible, ...).

Ce qui peut être affirmé c'est que la propriété n'est pas correctement maintenue par le «système». Il reste à déterminer à quel endroit celle-ci devrait être implantée...

Une question corollaire préalable : cette propriété peut-elle être effectivement codée dans une brique logicielle adéquate ? En d'autres termes, est-il toujours possible de détecter que deux menus d'une même application sont simultanément ouverts ?

Au fait, est-ce la bonne propriété ?

Burned to be a live ...

2009-10-23T08:46:00.000-07:00

J'en connais certains qui diraient : «Encore une idée fumeuse... » (sinon foireuse ;)
Je répondrai : «Pas faux!...»

Bon, c'est quoi encore ce truc «Burned to be a live» ?
Déjà, c'est une idée montée juste pour le jeu de nom foireux (donc assorti à l'idée...). Ouai, je suis capable de faire un truc juste pour les noms folkloriques...

Tout ça est parti premiêrement d'un intérêt régulièrement entrenu pour les distributions linux dites «live» c'est à dire fonctionnant sans avoir besoin d'altérer le disque dur de la machine hôte. Deuxièmement, dans le même temps, une certaine frustration geek-like, de ne pas trop savoir «comment on fait exactement»...

Oh, fut un temps, j'avais commis une customisation de knoppix sur le thème des applications 2D/3D, ça s'appellait la «Knopixel» (oui, encore un petit jeu de mot facile). Faudra que je raconte ça un jour.
Quand on commence à avoir une idée de thème pour une distrib live, il en survient rapidement une autre, puis une autre... Rien de transcendant mais bon...

Revenons à la frustration. Ce qui serait intéressant avec les distributions lives «à succès» c'est de savoir (et donc pouvoir) les reconstruire de A à Z. Et pas seulement une adaptation qui se résume à «entrer dedans» (je passe la technique), bricoler les modifs, «ressortir» et lancer la regénération de l'image à graver sur un CD, DVD ou même une clé USB.

L'idée de «Burned to be a live» contient deux volets :

expliciter intégralement le processus de spécification et génération d'une distribution live
généraliser la démarche à plusieurs distribs «simultanément»

Comment ? Ben c'est pas très compliqué en fait. Le heureux z'hasard m'a mis devant la fourniture Debian Live Helper au moment où je cogitais sur le premier point. Visiblement, «LH» fourni tout ce qui est nécessaire pour expliciter l'élaboration d'une live (des scripts, plus un ensemble de fichiers de configuration, et même la possibilité de définir des scripts de configuration). C'est du Debian, donc probablement très ... sérieux.

Après inspection du fonctionnement de Debian Live Helper, le point deux s'obtient assez facilement en gérant la configuration de chaque distrib avec un lien symbolique sélectionnant le «profil» à utiliser.

Donc sur le dépôt, il y a actuellement, accessible classiquement par svn :

pour simple archivage, une copie des scripts live helper utilisés
un script Makefile d'enclenchement de la génération
un répertoire de «profil» pour chaque distrib envisagée.

Les répertoires de configuration sont préfixés 'dist.' et l'un d'entre eux est sélectionné lors d'une invocation au script de construction.

NB : Le script Makefile est le résultat du travail d'un stagiaire, Clément Mondon, qui a permi la construction d'une distribution live spécialisée : La «Plug'n B». Faut que j'en cause aussi...

Voilà le tableau général, reste le plus intéressant, complexe et subtil : remplir ces répertoires avec les informations, scripts nécessaires à la «spécification» d'une distrib particulière.

Hier encore, je testais (après achat de Linux Pratique), la distribution Elive. Le test est assez agréable mais survient inévitablement la question : est-ce que je peux reconstruire la Elive dans l'infrastructure «Burned to be a live» ?

Exercice de style. S'il y a des volontaires...

Si ça c'est pas clair...

2009-10-14T05:33:00.000-07:00

Lu très récemment sur une liste de diffusion ... technico-théorique dirons nous...

Record foo (barfoo: A) :=
{ bar := a;
foobar : equiv bar barfoo;
barbar : foofoo bar
}
Definition get_alias_bar bf (f : foo bf) := bar f.

C'est destiné à illustrer une possibilité syntaxique soit-disant intéressante d'un outil formel (dont le nom est sans importance ici).

Quelle est donc l'utilité de transformer la simple compréhension des noms d'entités en jeu de piste ?

Z'avez une heure pour me dire si babar est un nom utilisé dans cet exemple.

Moi je dis, y'a des claques qui se perdent.

Attention aux dépendances internes

2009-10-13T04:49:00.000-07:00

Bon, ok, le titre n'est pas très clair ... mais je n'ai pas trouvé mieux pour l'instant.

Alors qu'est-ce qu'une dépendance «interne» ?

Petite précision contextuelle, qui va presque de soit, il s'agit de dépendances entre les paquets d'une distribution linux (et ici, plus précisément, des distributions dérivées de debian).

Une dépendance est une relation qui lie un paquet à un autre paquet (généralement une relation de la forme «dépend de»). Les deux paquets étant distincts l'un de l'autre, on peut dire qu'une dépendance est, pour un paquet, une relation «externe».

Bon, ok, mais une dépendance «interne» ? Un paquet vers lui-même ? Non, bien sûr, c'est un petit abus de langage.

Prenons une partie importante d'un système GNU/linux moderne, par exemple, le server d'impression «CUPS» (d'autres candidats possibles : X, Gnome, Kde, ...). Sur une installation normale, on peut facilement constater que plusieurs paquets constituent la «fourniture CUPS» (cups-bsd, cups-client, cups-common, ... cela varie selon l'usage de la machine, ou la distribution utilisée). Bref, nous avons plusieurs paquets installés alors que CUPS est originellement fourni de manière monolithique (consulter http://www.cups.org/software.php).

En effet, pour de justes raisons, la fourniture originelle est décomposée en plusieurs morceaux lors de la phase de «mise en paquets». De manière classique, on peut observer l'apparition de paquet serveur, paquet client, paquet commun, paquet de développement, etc.

Pour une même fourniture initiale, ces paquets portent donc le même numéro de version. Ce qui peut se traduire par une hypothèse raisonnable indiquant qu'un paquet client de version N «s'attend» à être mis en fonction au contact d'un paquet serveur également de version N... Logique. Rien de garanti qu'un composant de version N soit compatible avec un autre composant de version N+1 (et réciproquement en fait).

Sauf que, cette dépendance «interne» (nous y voilà!) à la fourniture initiale n'est pas nécessairement inscrite dans le système de gestion des dépendances. En d'autres termes, il est difficile d'empêcher qu'un utilisateur fasse cohabiter (volontairement ou non) des morceaux de fourniture en versions différentes.

Il est assez facile de constater que le système Debian (par exemple) permet de faire cohabiter des paquets appartenant à gnome 2.4 avec des paquets appartenant à gnome 2.6. Cette souplesse peut sembler intéressante mais il est inévitable qu'elle induise des dysfonctionnement dans certaines installations.

Encore très récemment, mon F-spot est subitement(!) tombé en rade. Sachant que F-spot repose sur l'infrastructure Mono, j'eu l'intuition de regarder les numéros de versions paquets installés relatifs à mono (dpkg -l | grep mono). De manière bien visible, un (numéro de version) intrus était présent dans le lot. Une vérification très rapide m'indiquait alors qu'une version homogène était disponible et me permettait de profiter à nouveau de F-spot.

Toujours est-il que le système de gestion des dépendances ne m'a pas empêcher de «casser» l'homogénéité «interne» de la fourniture mono...

P.S. : À noter que je ne me prononce pas sur les moyens à mettre en oeuvre pour préserver de manière efficace et pertinente les dépendances internes des composants principaux d'une distribution. C'est une question fort délicate.

Comment tester un produit Plone ?

2009-08-31T02:45:00.000-07:00

Depuis longtemps je m'intéresse pas mal au CMS Plone. J'en ai installé quelques uns, qui fonctionnent de manière robuste et satisfaisante. Reste que la maîtrise de la bête est délicate et qu'il m'est arrivé plusieurs fois de faire table rase ...

Comme j'ai bien l'intention de passer à la vitesse supérieur en basant un intranet «complet» sur Plone, je me renseigne et je recherches les bonnes pratiques, les astuces ...

Ce jour, je tombe sur une page au titre intéressant « Comment tester un produit Plone ?», sous-entendu sans mettre en péril le serveur en fonctionnement. Bah oui, même si on ne teste pas sur le serveur «en prod», il faut bien tôt ou tard franchir le Rubicon et déployer le nouveau produit. Ah oui, au fait, en terminologie Plone, un produit c'est une extension qui apporte la possibilité de manipuler de nouveaux objets dans le CMS (e.g. agenda, vidéo, flux RSS, ...).

J'ai quand même été un peu déçu en lisant l'article car il n'y a rien de véritablement bouleversifiant et il me semble que l'on peut faire plus complet / radical dans la démarche de test, tout en gardant ce qui est évidemment proposé.

Première remarque, la procédure de test d'un produit comporte évidemment le teste de son installation mais elle devrait égalemetn comporter le test de sa désinstallation ! Il n'est pas inutile de vérifier que le produit est développé de manière propre, dans le respect des sites sur lequel il va être installé et que son installation n'est pas un chemin sans retour possible.

Donc on installera le produit, on testera ses fonctionnalités de base (création, manipulation d'objets), puis on fera le chemin à rebours, en annulant les modifications, les créations, puis l'installation du produit. On pourra même vérifier dans les traces de lancement de Zope/Plone, qu'il n'y a pas de résidus de l'existence de ce produit.

La seconde remarque est plus «lourde»... Il est bien connu qu'on ne teste pas un (nouveau) produit sur un serveur en production. Tous les tutoriaux le disent ... mais aucun ne répond alors à la question évidente : «D'accord, mais je test où !?».

La réponse est évidente mais lourde de conséquences : On teste dans un serveur «clône» ! Et oui, le test ne peut être concluant que dans des conditions quasi-identiques à celles du serveur en prod. Le clônage est donc quasi obligatoire, au risque d'avoir une procédure de test non pertinente (et donc dangereuse).

Voici donc le résumé de la méthode proposée : faire le test d'un nouveau produit dans un clône du serveur zope/plone utilisé. L'espace de fonctionnement système de zope/plone(et /python en fait) étant très large, il faut clôner le système entier pour être certain de ne rien oublier. Une solution permettant de faciliter ce clonage c'est d'établir le zope/plone dans un chroot. Ce chroot est alors une zone facilement copiable/transportable car simplement délimitée.

On établit donc 2 chroots, l'un étant dérivé de l'autre. Dans le premier, le serveur en prod. Dans le second, son jumeau. Ce dernier peut soit «dormir», soit fonctionner simultanément (moyennant une utilisation adhoc des ports concernés).

Ce double-chroot peut être soumis à la synchronisation (permanente, régulière, au cas pas cas, selon besoins donc). Si les deux jumeaux se portent bien, on peut même établir une permutation des rôles prod/test à chaque fois qu'une évolution majeure est souhaitée. Si l'évolution est satisfaisante, le testeur devient prod, le prod devient testeur...

Évidemment, cette méthode du double-chroot est lourde et demande au moins de l'espace disque et une machine «solide». Mais n'est-ce pas la moindre des choses pour un serveur en production ?

Note : Oui, dans une certaine mesure, cette technique se généralise à la question délicate de la mise à jour d'un service/serveur «critique».

/dev/null c'est MAL...

2009-08-27T03:15:00.000-07:00

J'ausculte assez rarement le contenu des fichiers «code» fournis par un logiciel libre. Aparte : oui, c'est contraire au cliché qui prétend que les logiciels libres, donc les codes sont fournis, sont en permanence décortiqués par une armée de geek bénévoles... C'est du pipeau, mais passons.

Quand cela m'arrive c'est qu'il y a un problème dans le fonctionnement du logiciel. Surtout lorsque le logiciel ne donne pas beaucoup d'information sur la cause de sa défaillance. Là, y'a pas, faut ouvrir le capot...

Et quand on ouvre le capot, qu'on ausculte certains scripts, on constate la présence d'instruction de la forme "bla bla bla 2>/dev/null".

Explication très rapide : lorsqu'un programme (on va dire non graphique pour ultra-simplifié) produit une sortie (texte surtout), il peut le faire sur la sortie dite «standard», soit sur la sortie d'«erreur». Ces deux sorties, affichages, sont par défaut envoyés au même endroit, l'écran (ou terminal ou console). Elles sont donc pas «visuellement» différentiables.
Néanmoins, pour les logiciels, ces sorties sont respectivements numérotées 1 et 2. C'est un peu comme si on leur attribuait des «canaux» différents. L'extrait précédent signifie donc que les erreurs (canal '2') produites par mon bla bla sont envoyées (le '>') vers «/dev/null».

Et c'est quoi ça, /dev/null ? Ben c'est un fichier un peu particulier qui ne stocke rien de ce qu'on y écrit. Une sorte de poubelle sans fond.

Donc, pour résumer, les erreurs éventuellement produite par mon code bla bla sont purement est simplement «oubliée». Ah... Et pourquoi ça donc ?

Ben, deux possibilités :

* Quand le logiciel est au point, les erreurs produites résiduelles ne sont pas de véritables erreurs, mais plutôt des avertissements (genre, «attention, vous faîtes quelque chose de pas recommandable !!», et on lui fait comprendre que «je sais, je sais, mais fais quand même, je maîtrise».

* (Ici, faudrait vérifier techniquement) La production de message d'erreur provoque un état (status) d'erreur, détecté par le script englobant et qui déclenche l'arrêt du script (donc parce que l'une des étapes intermédiaires produit des messages d'erreurs que l'on souhaite ignorer).

Bref, le /dev/null c'est radical pour «polir» les sorties d'un logiciel/script en envoyant à la poubelle tout ce qui pourrait nous géner soit disant inutilement... Simple, radical.

Le /dev/null s'invite facilement lorsqu'on l'on pense que tel code est désormais «correct», après moult tests, et que donc, ce qui reste comme avertissements s'inscrit dans une maîtrise globale du fonctionnement et n'apporte plus rien au développement.

Sauf que. Ok, mais quand «ça marche pas quand même ...»

Ben là, on a tout perdu. Parce que, réduit au silence, le code ne peut plus nous donner d'indice sur la localisation du problème... Et là, le développeur ou l'utilisateur malheureux comme à s'amuser...

Très régulièrement, je me fais piéger. J'ai un souvenir douloureux (ok, n'exagérons pas) de deux heures passées à comprendre pourquoi je n'arrivais pas à adapter le démarrage graphique d'une knoppix. L'information caractéristique de l'erreur qui devait me mettre sur la piste était envoyée dans /dev/null...

Ce qui est particulièrement rageant, c'est que dans 90% des cas, la solution qui réconcilie tout le monde est très simple : définir une variable qui indique où l'on souhaite déverser les «erreurs».

LOG=probleme.log
bla bla bla >$LOG

En rédéfinissant cette variable, on passe d'un comportement «silencieux» à un comportement «je garde l'info, ça peut servir».

grep -sir 'dev/null' /etc | wc -l ==> 1146

Flshort, le retour

2009-08-12T00:49:00.000-07:00

Comme je l'expliquais précédemment, la traduction française du tutorial «Une courte introduction à LaTeX» n'était plus vraiment disponible sur la toile.

Tada... http://github.com/scolin/lshort-fr/tree/french ! Le revoilà... En version traduite, à jour et avec cette fois les sources bien en évidence.

Tout le mérite en revient à Samuel Colin, avec qui j'avais depuis un bon moment l'idée de ressuciter, «pour le principe» dirons-nous, la traduction française de ce tutorial. J'en rêvais, Samuel l'a fait.

Reste maintenant à faire vivre ce document dans le futur mais cette fois, cela ne dépend plus de la bonne ou mauvaise volonté d'une seule personne.

Merci Samuel.

Quasi bug

2009-06-23T03:27:00.000-07:00

Le genre de chose que l'on détecte parfois dans une installation et qui illustre bien les difficultés d'une gestion système ... «parfaite» !

Dans un message de log :

kylix x-session-manager[5595]: WARNING: Could not launch application 'restricted-manager.desktop': Unable to start application: L'exécution du processus fils « restricted-manager » a échoué (Aucun fichier ou dossier de ce type)

Bon, effectivement, souvent pour empêcher qu'un utilisateur ne tripote inconsidérément son install, je vire certains paquets ... dont restricted-manager, généralement inutile pour nous.

Mais si le paquet est viré, pourquoi le système s'obstine-t-il à vouloir lancer l'applicatif. La réponse est relativement simple après quelques recherches bestiales (locate+ grep). Le paquet est bien viré mais non purgé, et (si j'ai bien compris) il laisse un ficher de lancement automatique dans /etc/xdg/autostart.

Machinalement, je me pose la question de la cohérence du lien entre ce qui est dans ce répertoire de démarrage automatique et l'état des paquets potentiellement concernés (sont-ils encore présents ?).

Est-ce un bug ... ?

Petite debianerie pour tester la chose :

grep Exec /etc/xdg/autostart/*.desktop | awk -F "=" '{print $2}' | awk -F ' ' '{print $1}' | xargs dpkg -S | grep introuvable

Cette ligne peut permettre de détecter les applications lancées automatiquement en vain car elles ne sont pas/plus là...

NB : Elle est probablement améliorable (à cause du xargs dpkg -S pas très subtil).

6 octobre 1998

2009-06-23T02:27:00.000-07:00

Au hasard d'une recherche dans mes archives (donc nécessairement un processus complètement aléatoire), je viens de remettre la main sur le devis de la première machine m'ayant été fournie lors de ma prise de fonction...

En date du 6 octobre 1998, devis pour une machine Pentium II 233, 4Go de disque dur, 128Mo de SDRAM, carte réseau par port PCMCIA, Linux installé (j'avais choisi la Debian, sauf erreur "Hamm").

Tarif : 20000 F HT.

Pour l'anecdote, ce devait être la première machine personnelle pré-installée en linux/debian sur notre site. Et ce devait être également la première fois qu'un «permanent» s'équipait d'office en machine portable.

Le devis est émis par la société «ALCOVE»... Qui se souvient d'«ALCOVE» ? (*)

Je laisse faire les comparatifs prix/puissance avec les tarifs actuels.

(*) Je me souviens même très bien avoir eu Christophe Le Bars au téléphone pour spécifier les derniers détails et notamment faire un choix pas vraiment anodin pour la suite : «Mandrake ou Debian ?»

Merci Christophe pour le conseil ;)

Firefox et consommation CPU

2009-04-23T04:16:00.001-07:00

J'aime bien installer sur «mes» machines, un petit soft dénommé munin, qui génére assez facilement un ensemble de graphes traitant du comportement d'une machine (mémoire occupée, requêtes nfs, etc, utilisation cpu).

Ce matin, sur mon poste de travail principal, je sens comme un ralentissement, surtout dans le navigateur firefox. Donc, machinalement je consulte les graphes munin et en particulier le graphe ci-contre (utilisation du CPU, par jour)...

Assez étonnant en fait. Il arrive d'avoir ce genre de courbe légèrement croissante mais pour l'occupation mémoire. C'est d'ailleurs généralement le signe d'une «fuite» de mémoire, c-à-d une application qui ne gère pas correctement ses besoins en mémoire en gardant occupée de la mémoire qu'elle pourrait libérer.

Ici, il s'agit plutôt d'une consommation du CPU légèrement croissante. Cela n'est réellement visible que sur plusieurs jours, je n'arrête quasiment jamais ce poste de travail. Le jeudi 22, un peu après 10h00, j'ai donc arrété l'application visiblement coupable : Firefox. La courbe chute évidemment très nettement.

La conclusion du paragraphe précédent est en fait un peu trop rapide. Il est probable que Firefox ne soit pas directement coupable mais plutôt, intuition, l'un des nombreux scripts javascript qui tournent régulièrement en tâche de fond (par exemple en utilisant les applications google).

Lequel ? ... ben, si seulement j'avais le temps de chercher ça :P

Jeudi 16 Avril 2009

2009-04-16T13:48:00.000-07:00

Une poignée de brioches non entamées, récupérées dans un emballage de fortune, ça me fera un petit-déj demain matin.

Un crucifix de cercueil, en toc mais inestimable.

C'est tout ce qu'il reste d'une journée sans trace.

J'y ajoute une poignée d'octets, nouvelles cendres numériques.

Diversité biologique

2009-03-02T08:57:00.000-08:00

Dans les petites régressions qui figurent dans le quotidien du geek qui mets à jour son système plus ou moins régulièrement, la perte du son se trouve en bonne place, probablement sur le podium!

N'échappant pas à cette petite malédiction, j'avais jusqu`à très récemment deux machines souffrant de ce ... scrupule (ça y est, je l'ai placé !...) . Pour l'une, ma machine perso, il s'agit d'une véritable régression : ça marchait bien et boum, ça marche plus bien...

La nature exacte du boum régressif étant quasi inextricable dans la complexité croissante d'un système informatique, véritable mille-feuille de couches logicielles entre périphériques, pilotes et applications.

Pour l'autre, le mystère est plus épais (non, pas en nombre de couches). Après une réinstallation «from scratch», la carte son reste désespérément muette.

«Dans le temps» (tiens, j'ai déjà dis ça moi), pour réparer c'était assez facile, un grand coup de pied dans alsa ou oss, et ça repartait ! Maintenant... on ne sait plus où taper. Alors, on pifométrise, en espérant ne pas dégrader la situation.

L'une des heuristiques pifométrique consiste à faire appel à la diversité biologique de notre système préféré. En supposant que le problème ne soit pas véritablement matériel, comme nous avons plusieurs «piles logicielles» concernant le son, on les installe les unes après les autres, en espérant que l'une d'elles démontre qu'il est possible d'obtenir effectivement du son.

C'est précisément ce qui m'est arrivé suite à la lecture d'un blog quelconque (au sens où je ne me souviens plus lequel), apprenant la sortie de xfce 6, je me dis que je n'ai plus grand chose de la famille xfce (4) sur ma machine. Et je tente donc l'expérience avec xfce4-mixer-alsa (au hasard :P

Et c'est alors que le miracle survient. Sans même changer de session en cours (gnome), la restitution sonore est à nouveau opérationnelle, simplement après avoir reconfiguré les préférences sonores ! Pour information, la même manoeuvre avec les autres outils analogues avait échoué jusqu'ici !

14 février 00h01

2009-02-14T02:09:00.000-08:00

Oui, c'est la Saint-Valentin :)
J'ai indiqué 00h01 parce que je ne suis pas certain qu'à 00h00 ce soit déjà la Saint-Valentin...?
En fait, le sujet de ce billet ne concerne absolument pas la Saint-Valentin, ni-même... «le jour d'après» (arf) mais surtout le jour d'avant, un vendredi 13 !!

Donc, hier, enfin non, aujourd'hui, euh... bon tranchons, hier soir vendredi 13 donc, un peu avant minuit, j'étais devant la télé... pas tellement sommeil, le temps passe et je découvre une émission intitulée "Club" (à vérifier) débutant vers 00h30 sur une petite chaîne qui monte.

Pas trop bien compris le principe, m'enfin une présentatrice comment dire... «avenante» alterne des clips musicaux et un jeu question-réponse où les téléspectateurs téléphonent à un numéro évidemment surtaxé pour gagner la cagnotte.

Déjà un premier truc pas net, la-dite présentatrice a passé l'émission à se plaindre qu'elle ne recevait pas d'appel avec la bonne réponse. Bizarre, personne n'était donc capable de donner le nom de la star mondiale qui chantait les titres tels que "Like a virgin", "Holidays", "La Isla bonita" ... Même moi, je le sais. Enfin bref, me souviens pas avoir entendu un téléspectateur à l'antenne tenter de gagner les 1500 ou 2000 euros.

Le truc vraiment pas net et beaucoups plus drôle, vers 1h00 moins dix, j'entends très précisément :«Et oui, aujourd'hui Vendredi 13, profitez-en, la chance va vous être favorable... Té-lé-pho-nez nous!»
Et ainsi de suite, durant l'émission. Le vendredi 13 2009 a donc eu au moins 25 voire 26 heures.

Comme quoi, certains n'hésitent pas à jouer sur la fibre de la naïveté (restons polis) pour faire cracher les gogos...

Ce qui est pire, c'est que je crois que j'ai commencé à douter.

«Chérie!? On est quel jour aujourd'hui ? ... Bah, pourquoi tu fais la tête ?».

GPS : Geek Perdu en Solo

2009-02-04T04:00:00.000-08:00

J'étais récemment en déplacement «pro» sur la bonne ville de Toulouse. Un peu plus de deux jours gris et pluvieux (un wayka offert dans le paquetage de bienvenue, à Toulouse !), mais cependant fort intéressant en terme de rencontres.

Ne connaissant pas tellement Toulouse, j'avais emmené mon GPS «de voiture», notamment pour m'indiquer le trajet centre-ville / hôtel. Ce qu'il a correctement fait d'ailleurs. Merci le GPS!

De retour dans le Nooord, et plus précisément à l'aéroport de Lesquin, pour faire le malin, je branche le-dit GPS afin d'évaluer sa capacité à me trouver un petit raccourci entre l'aéroport et mon logis, ce qui devait logiquement m'amener sur l'autoroute A23. Au premier carrefour, j'ignore avec dédain la direction fléchée A23 et je suis avec confiance le GPS m'indiquant une autre direction.

Quelques kilomètres plus loin, comme j'ai un peu le sens de l'orientation, je commence à m'inquiéter car je ne voyais pas très bien comment le GPS pourrait me ramener rapidement sur l'autoroute, sauf à faire demi-tour, ce qui n'est pas dans la logique de l'utilisation d'un GPS.

Mon inquiétude se confirmait de kilomètre en kilomètre, d'autant que le trajet était ponctué d'indication de rond-points sans aucune annonce de sortie à prendre (ce qui est toujours le cas dans un rond-point). Je commençais à avoir des doutes sur la santée mentale de mon GPS.

Je fini par «atterrir» à Cappelle en Pévèle ! C'est d'ailleur ce passage qui a motivé la rédaction initiale de ce billet car cette commune est l'un des hauts-lieux d'activité du group d'utilisateur linux historique de la région. Les hasard du calendrier ont fait que, justement, le lendemain de mon périple, devait se tenir l'assemblée générale de ce club. J'avais été invité à y participer mais malheureusement j'avais décliné l'invitation (partiellement à cause de mon déplacement).

Me retrouvant un peu paumé à l'entrée de Cappelle en Pévèle, j'envisageais la mauvaise tournure de mon petit périple comme une vengeance des activistes linuxiens «Cappellois» par GPS interposé :)

Ce sentiment de complot s'est confirmé lorsque j'ai du constaté que les-dits activistes avaient bien préparé le coups en modifiant complètement le plan de circulation de la commune (ma carte mémoire GPS à deux ans d'âge). Autant le dire simplement : utiliser un GPS, dans une commune inconnue, avec des sens interdits comme seules suggestions de trajet, c'est catastrophique...

Et c'est là que je décroche le ponpon : le GPS m'affiche sobrement «Attention! batterie faible.»

Gulps. Inutile de préciser que je ne perdais pas de temps à suivre les rares indications du GPS en espérant qu'il finisse par me ramener sur le droit chemin avant que la batterie ne soit complètement vide.

ÉPILOGUE : J'ai bien fini par retrouver ma route; en rase campagne, le choix n'est pas énorme non plus. Positivons, j'ai traversé des communes que je ne connaissais pas (Genech, Mouchin...). J'ai donc appris des choses.

Et j'ai fini par comprendre, au détour d'une conversion n'ayant rien à voir avec cette histoire, le pourquoi du comment de mon foirage GPS : depuis ma visite toulousaine, mon GPS était toujours en mode ... piéton !

Ici Houston, autorisation de décoller...

2009-01-23T06:11:00.000-08:00

Allez, petit plaisir, une photo de mon «nouveau» poste de travail.

Rien de bien dantesque mais c'est amusant comme disposition...

La mise en place est des plus simples grâce à un dispositif 3 sorties vidéos VGA à partir d'une entrée.

Ceci est juste un essai un peu hétérogène de disposition, j'attends la livraison des trois écrans identiques ...

Ajout : un lien plus technique sur le même sujet.

Et alors, c'est quoi le problème ?

2009-01-23T03:25:00.000-08:00

Bon, ok, billet un peu facile mais je résiste pas.

En procédant à une mise à jour un peu naïve de OpenOffice.org 3.0 :

sudo apt-get install openoffice.org-base-core openoffice.org-bin openoffice.org-core openoffice.org-base
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Aucune version du paquet openoffice.org-bin n'est disponible, mais il existe dans la base
de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète
ou qu'il n'est disponible que sur une autre source
Cependant les paquets suivants le remplacent :
openoffice.org-core openoffice.org-base
E: Aucun paquet ne correspond au paquet openoffice.org-bin

Et ici, je copie-colle le titre du billet :)

Méli-Mélo-Rézo : Debian 2 - Ubuntu 0

2009-01-08T02:09:00.001-08:00

Dans la suite de mes tribulations réseau maison et remise dans le circuit de la machine «Cabernet», nouvelle expérience debian vs ubuntu.

Cette machine est équipée d'une carte wifi intégrée Broadcom machin chose... Opérationnelle il y a quelques temps (donc bien avant Intrepid) par installation du paquet b43-fwcutter (Utility for extracting Broadcom 43xx firmware), voilà que l'activation sous Intrepid me semble bien plus problématique tout en ayant installé le-dit paquet (version ubuntu évidemment).

L'installation de la version Debian de règle le problème. Carte wifi parfaitement activée après redémarrage et, cerise sur le gateau, connexion opérationnelle sur la fonera.

NB : Le score Debian vs Ubuntu est évidemment biaisé puisque je teste généralement à partir d'ubuntu. Il est donc peu probable que, alors que ça fonctionne sous ubuntu, je teste que cela foire sur Debian...

Pas très fair-play tout ça.

Dans le temps ...

2008-12-31T03:03:00.001-08:00

Où l'on commence à sentir que l'on a «du vécu» ...

Lorsqu'une réflexion commence par l'expression «Dans le temps ...»

Dans le temps donc, quand on (re)compilait un noyau linux, c'était simple, limite trivial.
On téléchargeait le gros paquet contenant les sources, on décompressait, petit lien symbolique vers /usr/src/linux, configuration par make menuconfig, make et zou...

De nos jours, semblerait que ce soit moins immédiat. Ça fait deux compilations que je tente sur deux machines différentes et où la recompilation se vautre alors que je n'ai rien modifié à la conf fournie «nativement».

Ok, on va me dire qu'il y a des tas de (bonnes?) raisons. N'empêche. Dans le temps...

Méli-Mélo-Rézo : Debian 1 - Ubuntu 0

2008-12-29T07:26:00.000-08:00

Suite au segfault sur network-admin (cf billet Méli-Mélo-Rézo), il me prend l'envie de faire un petit test sympa. Ces histoires de segfault c'est généralement lié au contexte de compilation initial de l'application c'est à dire lors de la mise en paquet.

Je décide donc de tester un autre contexte de compilation, tout simplement en installant la version debian(!) du paquet gnome-network-admin (contenant network-admin).

Aussitôt dit, aussitôt fait :

gnome-network-admin:
Installé : 2.22.0-3
Candidat : 2.22.1-0ubuntu1
Table de version :
2.22.1-0ubuntu1 0
500 http://fr.archive.ubuntu.com intrepid/universe Packages
*** 2.22.0-3 0
500 http://ftp.de.debian.org testing/main Packages

Et ben ça marche maintenant. (a) network-admin ne me demande plus de déverrrouiller avant utilisation (b) network-admin sauvegarde correctement une localisation «test».

Debian 1 / Ubuntu 0

NB : Le bug était répertorié sur launchpad mais supposé résolu (au moins pour hardy).
NB2 : Évidemment, ma manip n'est pas une correction de bug hein ...

Méli-Mélo-Rézo

2008-12-26T02:16:00.000-08:00

Je m'empresse de noter le paramétrage actuel de ma connexion wifi, histoire de bien vérifier que je n'ai pas la berlue...

wlan1 Link encap:Ethernet HWaddr 00:1f:3b:4c:0f:9d
inet adr:192.168.0.12 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::21f:3bff:fe4c:f9d/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:5935 erreurs:0 :0 overruns:0 frame:0
TX packets:6139 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:2334557 (2.3 MB) Octets transmis:749756 (749.7 KB)

Bon, ça connecte, c'est déjà ça. Je sors d'une période assez turbulente niveau connectivité réseau, essentiellement suite au passage hardy vers intrepid qui n'est visiblement pas sans (mauvaise) surprise. Après avoir eu un système «nickel» qui connectait proprement à la demande en filaire/dhcp au boulot, en wifi maison soit sur routeur, soit sur fonera, depuis intrepid, patatra, je viens même de galérer pour retrouver ma connexion wifi de base «default» !

J'en suis revenu aux vieux outils (network-admin) après avoir éliminé network-manager pas très rassurant en définitive (cf bug 191889 sur launchpad.net).

Ceci dit, lorsque je veux mémoriser cette conf en «localisation» network-admin, j'obtiens un joli segfault.

Ajoutons une couche d'avahi qui veut pas se faire discret et qui s'entête à me fournir des adresses en 169.254. alors que je n'ai rien demandé... Et cerise sur le gateau, l'explorateur «voisinage réseau» de nautilus ne m'affiche plus rien alors que findsmb me détecte bien le voisinage.

IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
---------------------------------------------------------------------
192.168.0.2 IDOLE [WORKGROUP] [Unix] [Samba 3.0.28a]
192.168.0.8 BOB +[BOB] [Unix] [Samba 3.2.3]
192.168.0.9 STORAGE-2770 [ȇ] [] [�]
192.168.0.12 APTERYX +[VDA] [Unix] [Samba 3.2.3]

Grrrr...

Ajout dernière minute : Voilà que mon disque dur de sauvegarde se met également délivrer des adresses dhcp !!

La théorie des six

2008-11-29T13:22:00.000-08:00

Dans la blogosphère, le sujet du présent billet n'est pas très original. On trouve donc d'autres discussions sur ce sujet assez étonnant.

Perso, jusqu'à y'a quelques jours, je connaissais pas.

«Selon la « théorie des six », énoncée en 1929 par le Hongrois Frigyes Karinthy, tout individu sur terre peut être relié à n'importe quel autre par une chaîne de connaissances ne comptant pas plus de cinq intermédiaires. Ainsi, chacun de nous est à six poignées de main de n'importe quel habitant du fin fond de la Mongolie-Extérieure.»

Ne chipotons pas sur les décomptes divers des intermédiaires ou des poignées de mains, les chiffres varient, mais la simplicité «universelle» de l'énoncé laisse perplexe / réveur...

Ce qui est marrant, c'est que généralement, le premier test qui vient en tête c'est : «À combien de poignées de main suis-je du Président des États-Unis ?»

Bon, perso, je ne tricherai pas comme d'autres bloggeurs qui sont pas très exigeants sur la notion de «connaître quelqu'un». Je ne considère ici que des personnes s'étant déjà serré la main une fois. Et bien, je suis lié à G.W.Bush !! (je le mets juste en italique, pas besoin de gras hein)

Pour le vérifier, il faut filer tout droit vers les hautes sphères hiérarchiques.

Je connais (poignée de main 1) mon directeur d'unité de recherche, qui connaît (poignée de main 2) le directeur de notre institut de recherche, qui connait (poignée de main 3) son ministre de tutelle, qui connaît (poignée de main 4) le président des français , qui connaît (poignée de main 5) le président des américains. Soyons précis, probable que la poignée de main 2 soit facultative...

Bon, ça c'est fait. Évidemment, trouver la chaîne qui me lie à un berger tibétain serait bien plus délicat. Déjà, y'a des bergers au Tibet ? On va dire que oui..

Il me vient à l'instant une pensée assez «drôle» : Selon cette théorie, chaque soldat américain est à au plus à 5 poignées de main de Ben-Laden... Et pourtant.

Céder à la facilité politique

2008-11-29T10:00:00.000-08:00

Il ne s'agit pas ici de faire un billet «politique» au sens habituel du terme, il n'est absolument pas dans mes intentions d'en faire ici. Sauf que, s'agissant de cohérence dans l'argumentation, de validité des analogies ou comparaisons, bref de l' «articulation logique» d'un discours (en l'occurence politique), ben ça m'interpelle...

Voilà, jécoutais distraitement la radio lorsque la journaliste annonce une intervention de notre premier ministre, devant un parterre de militant de son parti, où il se gausse de la situation actuelle du principal parti d'opposition. /Fortiche, pas un nom, pas un sigle jusqu'ici .../

Une critique était formulée ainsi : «S'il fallait débattre 6 mois entre les courants A, B et C du parti avant de prendre les décisions concernant les mesures à prendre face à la crise financière actuelle, où en serions-nous ? ». Sur ce notre premier ministre en concluait qu'il fallait se féliciter du résultat des dernières élections présidentielles. Applaudissement et rires de l'assistance. Normal.

Et c'est là que mon petit cerveau se met en marche et ... bah tiens ... les-dites mesures ne me semblent pas avoir été prise suite à débat au sein du parti de la majorité actuelle !! Mais plutôt à l'initiative de celui qui a été élu président! Au nom de quoi, en aurait-il été autrement si la victoire été allée à l'autre camps ? Depuis quand la France est gouvernée sur la base de débats au sein d'un parti politique (quelconque) ?

Enfin bref, il y a visiblement grossière entourloupe de dialectique politique... Le seul intérêt de cette transposition-fiction c'est de séduire un auditoire (déjà conqui, en fait). Le premier ministre s'appuie sur un débat strictement interne à un parti pour en extrapoler un mode de gouvernance du pays.

C'est évidemment «de bonne guerre». Néanmoins, il reste cette petite question dans la tête : Ce personnage est-il coutumier de ce genre de glissement sémantique ? Y-en aurait-il de plus subtils qui nous auraient échappés ? Est-ce ce mode de raisonnement qu'il utilise quotidiennement pour guider ses propres réflexions ?

Ça fait un peu peur ...

PS : On notera que, bien évidemment, en toute humilité, notre premier ministre s'est abstenu d'enfoncer le clou en citant en exemple le gouvernement, dont il est supposé avoir la direction, et qui s'illustre régulièrement par la cohérence «monolitique» exemplaire de sa «comm' ». Grand seigneur.

Mise à jour incrémentale, je rigole...

2008-11-27T08:23:00.000-08:00

Ah, ça c'est un de mes dadas...

Ma machine perso pro est installée ubuntu/hardy (hardy-upates même). Or, chacun le sait, la «next-one» , j'ai nommé intrepid-ibex est sortie.

Je n'ai pas de raison particulière pour mettre à jour dans l'immédiat, toutefois un léger bug d'affichage de apt me suggère de tenter la mise à jour ... de apt uniquement!

Je me fends donc d'un «apt-get update ; apt-get install apt» et là, ça défile, défile, défile !!

apt-get install apt -s | grep ^Conf | wc -l == 74

Et oui, cette petite demande implique la mise à jour de 74 paquets, rien que ça... Ah oui, et le retrait de 34 paquets.

Donc quand on parle de mise à jour en douceur des distributions modernes, faut quand même se méfier un tantinet.

Ok, les purs-et-durs m'expliqueront qu'il y a des (bonnes?) raisons m'enfin, ça surprend quand même. Pour le moins.

PS : Ah oui, ce (billet) faisant, je me suis rendu compte par un mouvement inopiné de souris et de fenêtre, qu'il ne s'agit probablement d'un bug d'affichage de apt mais du «bureau» (Xorg, gnome, ...?).

L'habit fait-il l'informaticien ?

2008-10-23T12:29:00.000-07:00

J'ai récemment participé à une école ou séminaire thématique. Le sujet exact importe peut, il suffit de savoir qu'il concernait essentiellement les personnels de la recherche ayant des activités d'ordre informatique, ce que l'on appelle donc globalement : des informaticiens.

Étant chercheur dans le domaine de l'informatique (génie logiciel si l'on veut préciser un peu), je suis donc considéré comme un ... informaticien. Enfin bref, moi qui n'aime pas trop voyager, il me prend la lubie de demander mon inscription ; celle-ci étant accceptée, me voilà parti pour une semaine encadrée au deux bouts par un long périple ferroviaire comportant notamment une correspondance dans une GRANDE gare.

À l'aller, j'ai 40 minutes d'attente pour ma correspondance. Largement le temps de flâner dans le GRAND hall de la GRANDE gare. Je trouve alors amusant de penser que, compte tenu de la destination et du réseau étoilé de la SNCF, il n'y a pas 36 horaires possibles pour parvenir à destination un dimanche après-midi et donc que je ne devrais pas être le seul «informaticien participant à ce séminaire» dans ce hall, à ce moment-précis.

Bref, je me mets à observer les nombreuses personnes qui passent dans mon champs de vision, afin de «détecter» un collègue de séminaire. En ce dimanche après-midi, je suis totu de même surpris par l'affluence. Ah tiens, ce grand monsieur, d'un certain âge, distingué... Il a bien une tête d'organisateur... Ah non, madame le rejoint, pas le genre de séminaire où l'on se rend en famille. C'est rapé.

Ah, celui-là, qui semble chercher son chemin, son quai, son train... Oui, oui, barbu à lunette, vêtements cools sans être débraillés, sac à dos pouvant contenir son ordinateur portable... Une manière d'être perdu tout en maîtrisant la situation ... Bon candidat ça.

Le temps passe et je dois me rendre sur le quai de ma correspondance. Le train est déjà en place, je monte. Quelques minutes passent et qui vois-je sur le même quai ? Mon «candidat» ! Il longe le train et va donc probablement y monter plus loin...

Deux heures plus tard, dans l'obscurité, nous arrivons à destination. La gare est bien plus petite... Objectif : trouver la navette destinée à m'amener à notre hébergement, légèrement à l'écart de la ville. Petite angoisse : il y a bien quelques autocars qui attendent, le moteur tournant au ralenti mais aucune indication me concernant.

Je ne suis visiblement pas le seul inquiet : je vois mon «candidat» arpenter le trottoir, s'efforçant de trouver quelque chose en regardant à droite, à gauche... Il s'éloigne rapidement pour explorer plus loin.

À ce moment là, j'entends une voix derrière moi qui me demande :

«Vous êtes du CNRS ??».

Argh!? Ce jeune homme qui m'adresse la parole, jouais donc également au détecteur de collègues !

Bien que n'étant pas du CNRS, je comprends très vite l'arrière pensée de la question : «Allez vous au même endroit que moi ?». Je réponds donc d'abord par un «non» et j'enchaîne en supposant que nous recherchons tous les deux la même navette :)

Cette brêve prise de contact à peine achevée, mon «candidat» est revenu de notre côté, le trottoir étant maintenant quasi désert, nous aboutissons à la conclusion que nous sommes donc trois participants au même séminaire. Une conclusion s'impose : être perdus au même endroit, dans une gare, dans l'obscurité, ça crée un lien très rapidement.

Soulagement, après un coup de fil, le problème est vite réglé, l'un des autocars anonymes en attente est notre navette. Par sécurité, avant de prendre la route, le chauffeur décide d'attendre le dernier TGV en provenance de Paris. Il ne descendra de ce TGV qu'un petite groupe de syndicalistes de retour d'une manifestation.

À bien y réfléchir, ce qui s'est passé dans la GRANDE gare est assez étonnant.

Nous étions donc seulement trois participants au séminaire a être dans la foule de ce dimanche après-midi. Cela ne me faisait donc que deux personnes à trouver parmis plusieurs centaines... Et j'en ai trouver une !! Soit un taux de réussite de 50 % ...

L'habit ferait-il donc l'informaticien ?

En tout cas, il semblerait que j'ai une tête à faire partie du CNRS :P

8 Octobre, Sainte-Pélagie

2008-10-08T00:54:00.001-07:00

Je vous présente Pélagie, baptisé(e?) à l'improviste selon le calendrier.

Elle(?) était ce matin devant notre entrée secondaire, immobile. N'a pas bronché quand je l'ai prise dans ma main (fallait bien ouvrir la porte).

Elle m'a tenu bien sagement compagnie sur mon bureau pendant quelques minutes, avant de reprendre ses forces et repartir par la fenêtre (tant bien que mal)...

Snif.

Le profileur (2)

2008-10-02T03:09:00.000-07:00

Quelques nouvelles de ma réflexion sur la notion de profil utilisateur.

Pour résumer l'épisode précédent, nous disposons d'un script qui permet de faire la liste des fichiers accédés depuis une période de temps donné (par exemple une heure).

Cette liste comprend donc les fichiers «de travail» (ouverture d'un document LaTeX, ou OpenOffice, ou...) mais également les accès réalisés par les logiciels à leurs configurations (gconf pour Gnome par exemple). Si on suppose les premiers sauvegardés par ailleurs, on peut se contenter de ne garder dans le profil que les fichiers de conf.

Selon le paramétrage du script et l'utilisateur, le nombre de fichiers détectés est évidemment variable. Avec quelques nettoyage sur des fichiers inutiles (tmp, caches, ...), et sur une durée d'une heure, le nombre varie entre 20 et 80 dans mon cas.

Par accumulation de ces listes dans des fichiers respectifs, on est alors en mesure de créer facilement une archive de l'ensemble des fichiers concernés sur une période plus longue :

@cat $(LISTES) | $(EXCLUDE) |sort | uniq >> profile

$(LISTES) ensemble des listes de fichiers modifiés, $(EXCLUDE) spécification d'exclusion/nettoyage avant archivage.

tar -T ./profile -cvf profile-$(USER).tar

pour créer l'archive contenant les fichiers constituant «profil».

Pour information, les archives constituées actuellement ont des tailles voisines de ... 100Mo ! (30Mo après compression). Il est très facile de lister le hit-parade des répertoires les plus importants/gros :

.mozilla/(65Mo) .mozilla-thunderbird/(23Mo) .claws-mail/ .galeon/ .purple/ (187ko)

Il est possible d'affiner la discussion sur ce qui doit-être exclu ou garder... Quelques remarques en vrac sur les avantages et défauts de cette approche :

au fur et à mesure, certains fichiers sélectionnés n'existent plus lors de la mise en archive (fichiers intermédiaires de stockage messagerie imap par exemple)
avec accumulation des listes, on obtient une sorte d'apprentissage en temps réel. Il n'est pas nécessaire de modifier le paramétrage du script pour prendre en compte de nouveaux fichiers de confiuration pour une nouvelle application.
avec la définition d'un horizon vers le passé, on peut également obtenir une fonctionnalité «d'oubli».
avec la seule démarche de création d'une archive (sur une clé usb par exemple), nous n'avons pas a priori la préservation de versions successives.
on peut égalemetn s'imaginer envoyer l'archive vers un compte gmail (prévoir cryptage et sécurisation nécessaire!?)

Jusquauboutissme

2008-09-30T03:40:00.000-07:00

Bon, on va écrire ça comme ça...

Pour qu'un principe, une théorie, une idée soit réellement satisfaisant(e), j'ai généralement constaté qu'il faut en faire une application sans concession. Sinon, on reste dans l'à peu-près, l'incertain.

Étant posé ce principe sur les principes (est-ce donc un méta-principe?), appliquons-le !

En ce qui concerne la gestion de machines Debian, deux principes/constations ne devraient pas nous être inconnus :

On installe que ce qui est (strictement) nécessaire à l'usage de la machine.
Le début des ennuis commence lorsqu'on a la possibilité d'enfreindre le principe précédent.

On peu en déduire que sur une machine parfaitement opérationnelle, i.e dont l'utilisateur ne s'est pas plaint disons depuis une grosse semaine, on a pas besoin d'installer de nouvelles applications. Et donc on a pas besoin des applications qui permettent d'en installer d'autres.

Ok, sur une machine avec un utilisateur humain normal, ça se discute (il en veut toujours plus). Par contre, pour un serveur, ça se justifie facilement.

Sur une distrib basée Debian, deux logiciels sont fondamentaux pour installer/désinstaller des applications : dpkg et apt. Le second dépendant fortement du premier.

Que se passe-t-il donc si j'élimine ces «paquets» de mon système ?

sudo apt-get remove apt

Le résultat est «raisonnable». Évidemment le système me demande de confirmer explicitement cette manoeuvre exceptionnelle (Pour continuer, tapez la phrase « Oui, faites ce que je vous dis ! »), et de plus il supprime les utilitaires dépendant de apt. Normal.

sudo apt-get remove dpkg

Le résultat est plus surprenant. Déjà c'est amusant de pouvoir supprimer dpkg avec apt alors qu'apt dépend de dpkg pour le faire... M'enfin, c'est pas impossible. Par contre, le système propose d'éliminer ce faisant la quasi-totalité des autres applications!

En quoi le retrait de dpkg ou apt rend indispensable le retrait de mon serveur apache qui fonctionne très bien par ailleurs ? (idem pour tout le reste, gnome, openoffice, ...)

NB /La suppression soit-disant déraisonnable de dpkg n'est pas une raison techniquement

satisfaisante.

Résonance

2008-09-26T14:04:00.000-07:00

L'autre jour, arrété à un feu rouge (pléonasme automobile), mon oeil est attiré sur le côté vers une publicité qui m'a interpellé...

Il s'agissait d'une affiche très sobre, pour l'une des emblématiques multinationales planétaires, j'ai nommé Mc Donald's, et contenant simplement un message laconique : «Pourquoi résister ?»

Ce qui m'a fait sourire c'est que je me rendais à une réunion organisée par un GUL du coin, ayant pour objectif la préparation d'autres réunions régulières et thématiques intitulées «Lundi des Libertés Numériques».

Résonances et résistances, ça rime, non ?

PS : Je n'ai pas retrouvé sur le net une image de cette affiche... pas beaucoup cherché non plus. Quelqu'un ?

Calculs patatoïdes et lignes de fichiers

2008-09-25T00:37:00.000-07:00

Petites colles sur la manipulation de fichiers-lignes, c'est à dire de fichiers sans autre structure que des lignes (de texte). Colles inspirées par le calcul sur les ensembles, calculs patatoïdes en référence au bon vieux temps où un ensemble était une patate.

Le lien dans le titre est la page wikipédia la plus proche du sujet traité ci-dessous, les patatoïdes en moins.

Soit 2 ensembles A et B, euh non, soit 2 fichiers fA et fB ne contenant donc que des lignes (par exemple, des résultats de recherches de noms de fichiers, une ligne = une information = un nom de fichier). On suppose les deux fichiers non-vides, sinon c'est moins drôle.

Je ne donne pas tout de suite de solution, j'écris ce billet au fil de l'inspiration, j'en connais qui se feront un plaisir de chercher des solutions avant que je ne poste les miennes (spéciale dédicace à hivernal.org :)

Comme on traite des ensembles, chaque fichier (de départ ou de résultat) ne comporte(ra) aucune ligne en doublon. On s'autorise toute commande en ligne, l'intérêt est ici de proposer les construction les plus simples (courtes?).

Union des deux ensembles/fichiers : (le plus facile ?) construire le fichier contenant la liste représentant la réunion des deux fichiers.

Intersection des deux ensembles/fichiers : construire le fichier contenant la liste des lignes présentent une fois dans les deux fichiers de départ.

Différence d'ensemble : La différence entre le premier fichier et le deuxième fichier est un fichier contenant chaque ligne du premier sauf si elle apparaît également dans le second.

Différence symétrique : Le fichier résultat doit contenir les lignes qui appartiennent à l'un des deux fichiers mais pas au deux à la fois. C'est également la différence entre l'union et l'intersection !

Comment généraliser à N fichier en entrée ?

===============================================================
SOLUTIONS
===============================================================

Union : Probablement le plus simple.

cat fA fB | sort | uniq > fC

Seule subtilité, l'obtention de l'unicité en combinant un classement (commande sort) alphabétique et une élimination des doublons (commande uniq).

Y-a-t-il des bugs dans cette solution ?

Intersection : Pas très difficile non plus...

cat fA fB | sort | uniq -c | grep ' 2 ' | awk '{print $2}' > fC

La commande uniq permet également de compter les occurences successives d'une ligne avant 'uniq-fication'. Il suffit donc de ne garder que les lignes préfixées par un compteur à 2. Cette méthode n'est valide que si les lignes sont uniques dans les fichiers de départ. Il est possible de s'en assurer mais cela complique la solution proposée.

Y-a-t-il des bugs dans cette solution ?

Différence : Un peu d'astuce ...

cat fA fA fB | sort | uniq -c | grep ' 2 ' | awk '{print $2}' > fC

Si les fichiers sont initialement des ensembles, le résultat de cat ne l'est pas! Cela permet de compter les occurences des lignes. En collectant deux fois le fichier A, on s'assure que les seules lignes apparaissant deux fois ne sont que celles de A.

Y-a-t-il des bugs dans cette solution ?

La dent dure...

2008-09-24T14:40:00.000-07:00

J'avais envie depuis longtemps que cette petite mésaventure soit mémorisée quelque part sur le net, histoire que l'individu concerné s'en souvienne...

Voilà, il y a quelques temps, on pouvait trouver facilement sur la toile le pdf d'une documentation LaTeX intitulée «Une courte introduction LaTeX». C'était en fait la traduction française de "The not so short Introduction to LaTeX 2e".

Toujours à cette époque, je cogitais avec d'autres sur la mise en place d'une intitiation LaTeX auprès d'enseignants du secondaire (essentiellement math.). Un support de cours s'imposait et la réutilisation du sus-cité document m'intéressait fortement. Quelques allègementes potentiels, éventuellement une mise en page plus économique... Enfin bref, une petite cuisine perso.

Le document étant sous licence libre (GPL), je contacte donc l'auteur, plus exactement le traducteur-adaptateur pour en obtenir les sources et expérimenter mes modifications. La réponse rapide fut que les sources en question n'étaient pas en état «diffusable».

Ce à quoi je répondis dans la foulée que ce n'était pas très grave, que je saurais juger sur pièce et que de toute manière, la GPL lui faisait obligation de les diffuser (ne serait-ce que sur simple demande).

Quelle ne fut pas ma surprise de recevoir une réponse dans la tonalité : « Je vois, Monsieur veut jouer les redresseurs de torts.» ! S'ensuivent quelques messages pour tenter d'expliquer qu'il n'y avait là qu'une demande parfaitement justifiée au regard de la licence du document, licence dont il avait lui-même profité pour élaborer et diffuser sa traduction. Peine perdue.

En ultime recours, je fais appel à quelques connaissances communes (des membres du GUL du coin) afin de convaincre l'individu de mon bon droit. Là encore, surprise. Nous en sommes resté à débattre dans le vide pour savoir si j'avais demandé suffisamment poliment !!

Pendant ce débat, nous nous sommes aperçu d'une petite subtilité non négligeable de la GPL. Il ne suffit pas que l'auteur initial d'un document GPL soit en mesure de fournir les sources ; il faut également que tout redistributeur soit en mesure de le faire (éventuellement par le biais de l'auteur évidemment).

Certains sites, dépositaires de la version pdf, ont très rapidement retiré le document dès lors que l'impossibilité d'obtenir les sources était avérée. Devant la dure réalité des faits et du droit GPL, l'auteur-traducteur s'est résigné à ... retirer son document de la circulation !

Plutôt le faire disparaître que d'en perdre l'exclusivité des sources.

Pendant quelques mois, on pouvait lire sur le site perso de l'auteur, que le document était indisponible en attendant que les sources soient remis en forme pour diffusion. Ce qui n'est jamais arrivé. Évidemment.

Voilà comment certains accaparent à leur profit la dynamique d'échange et de partage de la connaissance des logiciels et documentations libres. La communauté des utilisateurs LaTeX y aura perdu un tutorial de qualité. Heureusement, il y en a beaucoup d'autres.

Il reste que dans cette histoire ceux qui ont respecté, à la lettre, les principes du Libre ne sont pas ceux que l'on attendait.

NB : Vous ne trouverez actuellement sur le net qu'une version ancienne du document traduit en français par Matthieu Herrb. Vous noterez que les sources sont diffusés.

Le prix de la gratuité

2008-09-24T03:07:00.000-07:00

Hier soir, séance habituelle du LUG dont je suis «responsable», on va dire animateur. Début de saison, période de renouvellement des inscriptions à l'entité qui nous héberge.

Qui dit inscription dit cotisation / adhésion, la différence est subtile et importe peu. Tout ça s'exprime en euros.

Dans la conversation, certains habitués et fidèles ont évoqué le sentiment que «ça fait un peu cher...».

Honnêtement, je n'avais pas trop réflechi à la question. Les tarifs étant définis par catégories, nous sommes dans une catégorie. Voilà.

Il reste que la question posée est intéressante, notamment dans le contexte particulier d'un club «logiciels libres» : quel est le prix a accorder pour une assistance bénévole à l'utilisation de logiciels libres i.e gratuits (*) ?

Pour situer le contexte, l'adhésion annuelle peut se porter à 35 €. Ce tarif se décompose en deux parties (voire trois) :

10€ pour l'adhésion à notre entité d'accueil (en particulier assurances),
25€ pour la seule activité «logiciels libres», dont 5€ sont un surcoût pour les domiciliés hors-«commune d'accueil» (ce qui reste assez classique comme politique).

Il reste donc que l'on peut évaluer le coût intrinsèque du club à 20€ pour l'année (Septembre/Juin). Sur 10 mois donc, à compter de 4 séances par mois, cela fait 40 séances en théorie, disons 30 pour tenir compte des vacances et autres impossibilités. Ce qui amène à 2/3 € le prix d'une séance (généralement d'une durée de 2h30).

Ah oui, on suppose évidemment une certaine assiduité de la part de l'adhérent, sinon effectivement, il est toujours trop cher de payer alors qu'on ne participe pas ! Mais ce n'est pas le cas, en tout cas pas pour les présents d'hier soir.

La question posée est en fait celle de la valeur du «non-matériel». Le fonctionnement du club ne se base que sur l'échange de logiciels, des connaissances associées, et de temps passé.

La valeur n'étant accordée qu'à la notion de «service» (sic), quel(s) service(s) pourraient être attendus ?

20 € c'est aussi, 3 magazines linux, ou 3 places de cinés, ou un livre, ...

(*) Je laisse de côté le distinguo libre vs gratuit, plus exactement je le laisse aux coupeurs de cheveux en quatre.

Le profileur

2008-09-19T02:44:00.000-07:00

Question du jour : sous un système GNU/Linux, à quoi peut correspondre la notion de «profil utilisateur» ?

Cette question est en fait une reformulation de la préoccupation suivante : que dois-je mémoriser/sauvegarder de mon espace personnel pour être capable de reconstituer rapidement mon contexte de travail habituel ? mon «bureau» quoi.

On exclu donc ici ce qui concerne les applicatifs, fournis par le système global, ce dernier pouvant être mon poste personnel, le poste d'un collègue, un poste en libre accès...

Donc, qu'est-ce qui constitue mon «profil» ? Certaines parties de la réponse sont évidentes : mes préférences personnelles en matière d'ergonomie du bureau, mes différentes formes de contacts, adresses, signets internet, ...

Ok, ok, et tout ça c'est stocké où ? Et comment être certain de ne rien oublier ? Mon profil évolue pratiquement chaque jour !

Une réponse satisfaisante mérite donc quelques investigations supplémentaires. Dans un premier temps notre démarche va consister à collecter des informations pour avoir une meilleure vision de ce qui se passe aux niveaux de nos données (au sens large) quand nous avons une interaction avec notre système.

Nous élaborons donc un petit script qui va surveiller les modifications des fichiers (en fait surtout les dates de modifications) et nous faire la liste des fichiers modifiés. Dans cette liste, certaines modifications seront les traces du fonctionnement normal des applications et du système, c-a-d hors de notre «profil». Dans une certaine mesure, il est facile d'éliminer ces modifications et de ne garder que celles qui pourront être associées à notre profil. Plus précisément, l'ensemble des fichiers de cette catégorie sera considéré comme la représentation informatique de notre profil.

Ci-dessous la version préliminaire du script (make) de "profilage". C'est un script "make" i.e qui doit être exécuté en passant par l'outil make (qu'il faut donc avoir préalablement installé.

Dans ce script, selon l'organisation personnelle de l'utilisateur, on EXCLUDE d'office certains répertoires. Ce qui s'y trouve n'est pas considéré comme faisant partie du profil. Cette partie doit évidemment être adaptée à chaque contexte utilisateur.

#!/usr/bin/make -f

# (j)our annee / (H)eure / (M)inute
DATE=$(shell date +%j-%H-%M)

TAG=$(DATE)

EXCLUDE=
EXCLUDE+=grep -v /Desktop/
EXCLUDE+=| grep -v /MyWorld/
EXCLUDE+=| grep -v /MySVN/
EXCLUDE+=| grep -vi /cache/

# Trouver les fichiers modifiés depuis 1 journée
# Eliminer ce qui n'est pas pertinent (!?)

all:
 @find . -xdev -mtime -1 2>/dev/null | $(EXCLUDE) > MonProfile-$(TAG)
 @cat MonProfile-$(TAG)

Voici un (extrait) d'exemple de résultat obtenu :


./.gnome2/share/cursor-fonts/fonts.dir
./.gnome2/share/fonts/fonts.dir
./.gnome2/backgrounds.xml
./.newsbeuter
./.newsbeuter/cache.db
./.newsbeuter/urls
./.nautilus/metafiles
./.nautilus/metafiles/file:%2F%2F%2Fusers%2Festas%2Fmariano%2FDesktop.xml
./.nautilus/metafiles/file:%2F%2F%2Fusers%2Festas%2Fmariano%2FDesktop%2FA_RANGER.xml
./.nautilus/metafiles/file:%2F%2F%2Fmedia%2Fsda2%2Festas%2Fmariano%2Ftest.xml
./.nautilus/metafiles/x-nautilus-desktop:%2F%2F%2F.xml
./.mozilla-thunderbird/jeajfmm3.ESTAS/blocklist.xml
./.mozilla-thunderbird/jeajfmm3.ESTAS/XUL.mfasl
./.mozilla-thunderbird/jeajfmm3.ESTAS/virtualFolders.dat
./.mozilla-thunderbird/jeajfmm3.ESTAS/localstore.rdf
./.mozilla-thunderbird/jeajfmm3.ESTAS/training.dat
./.firefox/default/ljl0oqmu.slt/localstore.rdf
./.firefox/default/ljl0oqmu.slt/key3.db
./.firefox/default/ljl0oqmu.slt/hostperm.1
./.purple/prefs.xml
./.purple/accounts.xml
./.purple/blist.xml
./.purple/accels
./.bashrc
./MonProfile-066-12-34
./MonProfile-066-12-10
./.recently-used.xbel
./.gtkrc-1.2-gnome2
./monprofile
./.unison
./.unison/ar714749f516b154dd04ffd79d17e3d276
./MonProfile-066-12-35
./.liferea_1.4
./.liferea_1.4/liferea.db-journal
./.liferea_1.4/liferea.db
./.liferea_1.4/cache
./.liferea_1.4/feedlist.opml

On y retrouve pêle-mèle, le fonctionnement de la messagerie thunderbird, de la navigation internet par firefox, modification du fond d'écran pour Gnome2, etc ...

Nous avons donc bien une vision de ce qui a bougé dans notre espace personnel depuis 24 heures.

Le résultat de ce script est enregistré dans un fichier daté (./MonProfile-066-12-03). La suite de la manoeuvre consiste maintenant a exécuter de temps en temps notre script de manière à collecter des informations sur la vie de notre «profil» (en l'état, un peu large...)

La suite... plus tard.

PS : Ce billet est un exemple de l'utilité des formats dits «ouverts». Il était écrit à l'origine pour un test de blog ultra-léger (pluxml). Ce dernier sauvegardant en XML, il m'a suffit d'ouvrir le fichier avec emacs, de copier-coller la partie textuelle dans la saisie html du présent blog, de reformater légèrement, et hop ...

Nettoyage par le zéro (TM)

2008-09-19T01:28:00.000-07:00

Le titre est pas terrible, mais bon... si vous en trouvez un meilleur ;)

Par deux fois, une technique assez particulière m'a débloqué devant un problème de chargement de module noyau (kernel). J'explique d'abord la manip et je donne ensuite les deux cas où elle m'a été utile.

Préambule : certains points sont exprimés de manière «pifométrique», si le lecteur peut apporter des explications complémentaires plus sérieuses, ne pas s'abstenir ! :)

Voilà, tout d'abord «chacun» sait que l'on obtient la liste des modules actuellement chargés par le noyau linux avec la commande lsmod

lsmod

donne le résultat suivant

Module                  Size  Used by
af_packet              29960  2
binfmt_misc            16008  1
tulip                  55584  0
autofs4                24836  1
ipv6                  279616  27
hermes                 11392  0
firmware_class         14208  0
serial_core            25216  0
parport                40008  0
snd_ac97_bus            6528  0
snd_pcm                80004  0
snd_timer              26500  1 snd_pcm
snd_page_alloc         13960  1 snd_pcm
snd                    55396  2 snd_pcm,snd_timer
soundcore              12512  1 snd
intel_agp              27420  1
yenta_socket           30220  0
rsrc_nonstatic         17408  1 yenta_socket
pcmcia_core            43800  2 yenta_socket,rsrc_nonstatic
agpgart                36044  1 intel_agp
usbcore               135812  1
processor              36200  0

4 colonnes sont donc visibles : le nom du module, sa taille, un nombre, les noms de modules qui dépendent du-dit module. Je ne connais pas la signification exacte de ce nombre mais j'ai l'intuition qu'il compte le nombre de dépendances (ok, des fois c'est un 1 mais sans nom associé... gulps).

la commande lsmod | grep ' 0' (un espace devant le 0) a pour résultat :

tulip                  55584  0
hermes                 11392  0
firmware_class         14208  0
serial_core            25216  0
parport                40008  0
snd_ac97_bus            6528  0
snd_pcm                80004  0
yenta_socket           30220  0
processor              36200  0

C'est donc la liste des modules dont aucun autre ne dépend. Que peut-on faire maintenant ? Ben, les virer tiens! Puisque rien n'autre n'en dépend. Comment faire ?

lsmod | grep ' 0' | awk '{print $1}' | xargs rmmod

et voilà !

Attention! cette commande peut évidemment avoir des effets néfastes sur votre système .

Si aucun autre module ne semble dépendre de ceux là, certaines fonctions de votre système en dépendent ! Ceci dit, si la situation devient instable, un simple reboot immédiat devrait tout remettre en ordre.

En toute logique, cette commande peut être itérée, puisqu'en éliminant des modules, on peut mettre en évidence de nouveaux modules candidats au nettoyage par le zéro. Et ainsi de suite.

L'effet réel de cette commande reste un peu flou, on vire des modules, on nettoie, on élague... et alors?

Et bien par deux fois, cette manip m'a permis d'insérer respectivement deux modules qui, avant cela, refusaient mordicus de s'insérer dans le système (commande modprobe...

Primo: chargement du module ipw2200 pour carte wifi intégrée du portable (noyau 2.6.12) d'où je tape actuellement ce billet. Alors qu'a priori, ce module n'est pas sensé poser problème.

Deuxio: chargement du module tulip de la carte ethernet du vieux coucou qui héberge ce blog. Là encore, cela n'est pas sensé poser de problème. Et pourtant, ça coinçait.

Explication (hmmm, faut le dire vite). Tout se passe comme si parmi les modules «éliminés par le zéro»(TM), au moins l'un d'entre-eux bloquait le chargement des modules souhaités (ipw2200 et tulip).

Lesquels ? et pourquoi ? Ben, si j'ai des précisions un jour , cela fera un autre billet :)

PS : Ce billet est un exemple de l'utilité des formats dits «ouverts». Il était écrit à l'origine pour un test de blog ultra-léger (pluxml). Ce dernier sauvegardant en XML, il m'a suffit d'ouvrir le fichier avec emacs, de copier-coller la partie textuelle dans la saisie html du présent blog, de reformater légèrement, et hop ...

Machine linux opérationnelle ... sans système !

2008-09-16T07:04:00.000-07:00

Petite bizarrerie du jour :

root@chamonix:~# df -h

Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
varrun 1009M 244K 1009M 1% /var/run
varlock 1009M 0 1009M 0% /var/lock
udev 1009M 64K 1009M 1% /dev
devshm 1009M 12K 1009M 1% /dev/shm
/dev/sda5 24G 19G 3,2G 86% /home

ou encore

root@chamonix:~# mount
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda5 on /home type ext3 (rw)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

Où est donc passée la partition '/' ??

Comme dirait l'autre : «Et pourtant, elle tourne ...»

Pour les curieux, Linux 2.6.24-19-generic, sur une Ubuntu Hardy 8.04

Un test LaTeX+HeVeA+HTML = Blog

2008-09-09T08:55:00.000-07:00

1 Imprimante multi-fonction wifi HP C4380

J’ai acheté très récemment une nouvelle imprimante. Il s’agissait de remplacer une bonne vieille HP PSC 750xi un peu usée avec la contrainte d’être utilisable en wifi (question de confort d’installation, je ferai un jour l’inventaire des câbles dans le coin multimédia/info de mon salon).Mon choix s’est porté sur une HP C4380. Y’en avait pas 36 des imprimantes abordables, multifonctions et wifi. Laser c’est un peu plus cher donc je reste en jet d’encre. Honnêtement, j’ai pas trop fais gaffe à la compatibilité Linux, j’avais un a priori positif avec HP. De toute manière, c’est pour une utilisatrice «Vista» et j’imprime quasiment jamais en linux à la maison...Il faut effectivement avoir à l’esprit que cette imprimante se configure et s’installe uniquement à partir de Windows. Intuition : l’imprimante n’est pas capable de s’insérer seule dans un réseau local, elle le fait par l’intermédiaire d’un poste windows (relié par le câble USB).
L’installation est plutôt longue sans être laborieuse, une fois pigé le paragraphe précédent.Sous Ubuntu/Hardy tout commence de manière étonnament facile ! À peine lancé le panneau d’installation des imprimantes, celui-ci recherche automatique les imprimantes réseau... et me trouve illico l’imprimante wifi. La suite se fait de manière très classique sauf que je préfère aller cherche le fichier spécifique PPD (cf lien du titre) plutôt que l’approximation de pilote HP proposée par défaut.Tout se passe bien, jusqu’à la page de teste où ... rien ne se passe. Très rapidement, je constate dans les logs système :

Sep 4 22:48:30 apteryx kernel: [ 2807.343468] audit(1220561310.881:6): type=1503 operation="inode_permission" requested_mask="a::" denied_mask="a::" name="/dev/tty" pid=17622 profile="/usr/sbin/cupsd" namespace="default"

Et vlan. Je passe les détails de la boucherie(*) qui a suivi dans les manips d’installations diverses...
En tout cas, j’arrive (uniquement à l’aide de commandes apt-get) dans l’état suivant :

$ dpkg -S /etc/init.d/cupsys
cupsys: /etc/init.d/cupsys
$ ls -l /etc/init.d/cupsys

ls: ne peut accéder /etc/init.d/cupsys: Aucun fichier ou dossier de ce type

Imprimante multi-fonction wifi HP C4380

2008-09-04T13:39:00.000-07:00

J'ai acheté très récemment une nouvelle imprimante. Il s'agissait de remplacer une bonne vieille HP PSC 750xi un peu usée avec la contrainte d'être utilisable en wifi (question de confort d'installation, je ferai un jour l'inventaire des câbles dans le coin multimédia/info de mon salon).

Mon choix s'est porté sur une HP C4380. Y'en avait pas 36 des imprimantes abordables, multifonctions et wifi. Laser c'est un peu plus cher donc je reste en jet d'encre. Honnêtement, j'ai pas trop fais gaffe à la compatibilité Linux, j'avais un a priori positif avec HP. De toute manière, c'est pour une utilisatrice «Vista» et j'imprime quasiment jamais en linux à la maison...

Il faut effectivement avoir à l'esprit que cette imprimante se configure et s'installe uniquement à partir de Windows. Intuition : l'imprimante n'est pas capable de s'insérer seule dans un réseau local, elle le fait par l'intermédiaire d'un poste windows (relié par le câble USB).
L'installation est plutôt longue sans être laborieuse, une fois pigé le paragraphe précédent.

Sous Ubuntu/Hardy tout commence de manière étonnament facile ! À peine lancé le panneau d'installation des imprimantes, celui-ci recherche automatique les imprimantes réseau... et me trouve illico l'imprimante wifi. La suite se fait de manière très classique sauf que je préfère aller cherche le fichier spécifique PPD (cf lien du titre) plutôt que l'approximation de pilote HP proposée par défaut.

Tout se passe bien, jusqu'à la page de teste où ... rien ne se passe. Très rapidement, je constate dans les logs système :

Sep 4 22:48:30 apteryx kernel: [ 2807.343468] audit(1220561310.881:6): type=1503 operation="inode_permission" requested_mask="a::" denied_mask="a::" name="/dev/tty" pid=17622 profile="/usr/sbin/cupsd" namespace="default"

Et vlan. Je passe les détails de la boucherie(*) qui a suivi dans les manips d'installations diverses...
En tout cas, j'arrive (uniquement à l'aide de commandes apt-get) dans l'état suivant :

$ dpkg -S /etc/init.d/cupsys
cupsys: /etc/init.d/cupsys
$ ls -l /etc/init.d/cupsys
ls: ne peut accéder /etc/init.d/cupsys: Aucun fichier ou dossier de ce type

On verra plus tard...

(*) essentiellement test des versions 'intrepid' de cupsys, apparmor, et retour version hardy...

Blague de geek

2008-09-04T12:43:00.000-07:00

Une de mes blagues préférées, à connotation «geek». J'ai retrouvé très facilemet le texte original(?) grâce à Google : «joke stallman knuth linus»

Richard M. Stallman, Linus Torvalds, and Donald E. Knuth engage in a discussion on whose impact on the computerized world was the greatest.

Stallman: "God told me I have programmed the best editor in the world!"

Torvalds: "Well, God told *me* that I have programmed the best operating system in the world!"

Knuth: "Wait, wait - I never said that."

Libre-mytho

2008-08-31T10:41:00.000-07:00

Comme toute communauté, celle du Libre présente des aspects positifs et des aspects négatifs (que ce soit au niveau individuel ou au niveau collectif). J'aurais probablement l'occasion de revenir sur nombre d'entre-eux (les négatifs pour ce qui concerne la rubrique "Libre-mytho(mane)".

Pour cette première fois, le signe déclencheur m'est servi sur un plateau par l'introduction de l'article «Comment vos utilisateurs traversent votre firewall» de mon Linux Magazine n°108. On peut y lire :

«Enfin, il convient de rappeler l'opposition classique entre la sécurité par dissimulation, et la sécurité par la transparence. C'est un sujet classique, et les tenants du logiciel libre sont, naturellement, majoritairement partisans de la sécurité par la transparence, comme nous l'a montré l'exemple récent de faille majeure dans le générateur de nombre aléatoire d'Openssh (*) distribué par Debian.»

(*) À strictement parler, il s'agit en fait d'une faille de openssl ...

Suit un article relativement technique où l'auteur démontre une connaissance réelle du domaine de la sécurisation.

Et nous voici en plein paradoxe typique du libre : une expertise technique approfondie peut-être accompagnée dans le même temps par une totale incompréhension des enjeux périphériques.

L'auteur ne semble pas avoir pris la mesure réelle du cataclysme que constitue la faillite de la sécurisation par la transparence illustrée précisément par l'exemple cité.

Résumons très schématiquement cet exemple : pendant près de deux ans, suite à une bourde de développement, le système de sécurisation par clé SSH des distributions dérivées Debian était largement affaibli. Au lieu de générer «très» aléatoirement les clés SSH, celles-ci étaient en fait tirées dans un ensemble très petit, suite à une modification du script d'initialisation de la génération.

Et pourtant :

le processus de développement Debian est réputé pour être parmis les meilleurs,

pendant toute cette période le problème était clairement exposé sur la table

... et personne n'a rien vu !!

L'exemple cité ne doit donc pas faire référence parce que quelqu'un a vu le problème mais, exactement pour la raison inverse, parce que personne n'a rien vu pendant deux ans !

Pire, depuis cet épisode, défendre (uniquement) la sécurité par la transparence est devenu mission quasi impossible. Le contre-exemple fourni est en or massif.

La «sécurité par la transparence» c'est l'idée selon laquelle la vérification de la sécurisation d'un système est d'autant plus facile que le-dit système est complètement observable (transparent). Ce principe est couramment utilisé pour étayer la confiance portée aux logiciels libres puisque par définition ces-derniers sont complètement observables, leur code source étant publiquement disponible.

Il y a cependant une faille (évidente?) dans cet argument : le fait que le code soit observable ne signifie nullement qu'il est effectivement observé. Je peux laisser mon Linux Magazine dans la salle d'attente d'une gare, rien ne dit qu'il sera effectivement parcouru ou éventuellement lu.

Paradoxalement, on peut même affirmer que ce principe est son propre ennemi. En effet, à force de dire que le code libre est nécessairement audité, qui serait suffisamment motivé pour re-faire une vérification ? C'est un peu le syndrome «Avril 2002» : si tout le monde pense que les autres vont voter pour le candidat favori, ce dernier cours à sa perte ;)

Le dogme de la «sécurité par la transparence» est à ce point ancré dans la dialectique habituelle du libre que même un spécialiste ne peut envisager de le mettre en doute, quand bien même il en a sous les yeux le faire-part de décès.

Thunderbird cassé

2008-08-30T04:39:00.000-07:00

Et il me semble que ce n'est pas la première fois.
Moralité : je renomme les fichiers perso correspondants (mv ~/.mozilla-thunderbird ~/Attic) et je relance, pour me retrouver avec un thunderbird tout neuf.

Et oui, cela signifie aussi que ce n'est pas mon installation système de thunderbird qui défaille mais bien mon environnement perso !! Et ça, c'est plus inquiétant.

Plus précisément, j'ai bien une petite intuition de la cause initiale de mon problème mais ... pas le temps de rechercher une preuve tangible. En effet, avant cette défaillance fatale, j'ai bien eu quelques avertissements, thunderbird ne se lance pas, avec un message incompréhensible sur une histoire (Xorg? gtk?) de Bad Windows. Coïncidence, à la même époque, j'avais ma partition système pleine (100%), la flemme de procéder à certains nettoyages...

Bref, mon intuition est la suivante : la saturation de la partition système induit systématiquement des comportements aléatoires des logiciels (ça c'est pas une intuition, c'est certain), il ne serait pas impossible que pour thunderbird ces comportements aléatoires ne détruisent l'intégrité des fichiers personnels, ce qui rend thunderbird inutilisable.

Questionnement dérivé :

comment vérifier cette intuition (sans y passer des semaines) ?
comment s'organiser pour parer à ce genre de problème (piste = sauvegarde ... du profil utilisateur complet) ?

Academic 2.0

2008-08-26T14:57:00.000-07:00

Ce sera le nom d'un libellé (tag) pour classer un peu mes messages...

Cette étiquette concernera les sujets en relation avec l'utilisation des nouvelles technologies du web (dit "2.0") dans le contexte particulier de la recherche scientifique (d'où le "academic").
Ce sera simplement l'inventaire ou le retour d'expérience (avec ou sans recul) de mon utilisation plus ou moins intensive de ces nouveaux outils/sites...

Pour commencer, il conviendrait de faire la liste de ce que j'utilise. Et cela m'aiderait déjà a y voir un peu plus clair ! En voici quelques uns qui me viennent immédiatement à l'esprit, ils seront probablement détaillés dans d'autres messages :

mes signets peuvent être gérés par 'delicious', plus exactement et confortablement par le couple firefox/delicious (http://delicious.com/GeorgesMariano)
mes références bibliographiques par 'citeulike' (http://fr.citeulike.org/user/GMariano)
des 'sources' d'informations sont centralisées dans mon «univers» 'netvibes', partie publique et partie privée (http://netvibes.com/georgesmariano)

On peut remarquer que ces exemples partagent les particularités, souvent adjointes, de classer les items par l'utilisation de tags/étiquettes/libellés, et de définir ou collecter très facilement de multiples flux RSS (basés sur les tags).

Tout en permettant de gérer, classer, exploiter de multiples sources d'information, cela pose toutefois des problèmes ... d'organisation et/ou des choixs stratégiques!

est-il raisonnable de déporter ainsi le stockage de «mes» informations ?
par la multiplication des fluxs, des possibilité d'importation/exportation, où (se trouve|définir) la source primaire ? quelles sont les sources dérivées ?
doit-on éviter les redondances ? ou alors sont-elles souhaitables ?
... autres questions ?

À cette liste, il faudrait adjoindred'autres sites, que j'oublie ou que je ne connais pas encore, qui pourraient éventuellement être utilisés en complément. Si le lecteur a, sur ce point, des suggestions à faire, la rubrique des commentaires est grande ouverte.

Linux Verification Center

2008-08-26T03:39:00.000-07:00

Un site qui s'inscrit dans la lignée de l'une de mes vieilles marottes (voire même «idée» !). Cette idée qui me gratouille c'est ce que j'appelle «formal linux», d'où l'étiquette ou tag associé au présent message.

Je décrirais probablement plus longuement ce qu'est (ou pourrait-être) «formal linux», pour l'instant je note l'existence de ce site, qui existe depuis 2005 et dont l'essentiel de la production écrite est en russe ... Sans être entré dans le détail du site, il s'agit visiblement d'évaluer la correspondance entre les spécifications et le code source par le biais de tests intensifs...

Par ailleurs : http://delicious.com/georgesmariano/formal%3Alinux ;)