Tartine Blog

Ce blog est strictement personnel et les opinions exprimées ici n'engagent donc que moi, et notamment pas mon employeur...

mercredi 27 avril 2011

Mars attack !

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

jeudi 13 janvier 2011

Heuristique des empreintes systèmes

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 :

  1. au fait, c'est quoi un bug ?
  2. comment ça se révèle ?
  3. comment ça se détecte ?
  4. comment ça se règle ?
  5. comment éviter qu'un bug ne se reproduise ultérieurement ?*
  6. ...
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 :

  1. depuis quand (date précise!) est-il observable ?
  2. 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!).


vendredi 19 novembre 2010

Invariant(s) cassé(s)

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). 
  1. T=avant T0, installation du paquet localepurge 
  2. T0, installation du paquet fakeroot avec l'intégralité de ses fichiers
  3. T0+quelques secondes, localepurge efface directement les fichiers de langues étrangères dont ceux de fakeroot
  4. 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.


mercredi 17 novembre 2010

Normes et formalisation B (I)

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 :
  1. le système a été développé correctement  (le comment)
  2. 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).

vendredi 17 septembre 2010

Burned to be a live

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 .

vendredi 10 septembre 2010

Belle vue

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 ...

jeudi 2 septembre 2010

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

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.