Embedded weblog

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, avril 29 2010

Microsoft sentirait-il le sapin embarqué ?

D'après Engadget, il semblerait que la firme de Redmond sente le vent tourner. La preuve : tout à coup, les voilà qui se réveillent et trouvent qu'Android a l'air de violer quelques uns de leurs zillons de brevets logiciels débiles (je rappelle qu'ils ont réussi à breveter le double-clic...). La bonne affaire. Sans même se donner la peine de dresser une (fausse) liste, les voilà qui réclament déjà leur obole aux intégrateurs, HTC en tête. On remarque que (coïncidence !) ces derniers ont totalement viré Windows Mobile de leurs téléphones, OS largement instable, pour le remplacer par de l'Android : Hero, Desire (que je viens d'acquérir, j'ai craqué, Meego va mettre trop longtemps pour arriver) et bientôt l'Incredible. Forcément, dans ce genre de cas, personne ne se fâche, et l'on paie contre réduction. Qui sera le premier à se rebeller et à aller au bout d'un procès ? Après tout, pourquoi vouloir encore caresser Microsoft, et ses technique commerciales que nous éviterons de qualifier afin de ne pas choquer la ménagère de moins de 50 ans, dans le sens du poil ?

Le chant du cygne embarqué, manifestement.

mardi, avril 13 2010

RTS10: journée spéciale Linux Embarqué

Après cinq années de visite de ce salon, et pour cette sixième fois, j'ai été conférencier. Francis Mantes m'avait entretenu l'année dernière de sa volonté de monter une sorte d'atelier thématique autour de l'OS libre embarqué. Revu à la baisse, le projet s'est concrétisé en une journée de conférence complète consacrée au sujet, organisée par l'incontournable François Gautier. J'en avais ici-même fait la publicité. Battage aussi par mail qui n'aura pas donné grand chose, ai-je bien eu l'impression, mais ce ne fut pas bien grave : si l'on se disait que les 215 inscrits une semaine avant l'événement ne viendraient pas tous, force a été de constater que le public a été très nombreux. Et il n'est pas même improbable qu'une partie ait abandonné l'idée de s'arrêter pour s'asseoir : car cela était tout bonnement impossible à une trentaine de personnes ! À la louche : entre 80 et 90 "spectateurs". Debout contre les fines parois, au fond, sur les côtés, on s'arrange comme on peut. Dans le public, je reconnais même un collègue et mon ancien responsable commercial de ma précédente boîte !

Pourtant, l'affichage de l'événement n'était pas bien clair : déclaré deux fois (en réalité pour différencier le matin de l'après-midi), avec des intitulés similaires, bien du monde n'avait compris que les contenus seraient différents. En réalité, il y avait donc le matin Colin WALLS pour MENTOR GRAPHICS, Guillaume CHAUSSIN pour WIND RIVER et Pierre FICHEUX pour OPENWIDE ; tandis que l'après-midi ne faisait figurer que Pierre (again) et (enfin) votre serviteur pour LINAGORA (on l'aura deviné). Nicolas NAVET, de l'INRIA, n'ayant en réalité animé que l'après-midi, le matin étant assuré par François GAUTIER.

Colin Walls est très américanisé dans sa présentation corporate : avec son polo, il nous donne une vue d'ensemble très haute sur Andoid, avec des briques de couleur très jolies ; Guillaume Chaussin est pour sa part très francisé, avec son costard-cravate il nous donne un autre vue très haute sur Android. Là où ça devient amusant, c'est que le public posant à peu près les mêmes questions pour l'un et l'autre, à 45 minutes d'intervalle, le discours est tout différent : sur l'usage de RAM (et donc le dimensionnement nécessaire qui en découle), sur la possibilité de détourner la libc pour en faire du "natif" (comprendre du binaire à partir de code C), bref tout ce qui peut intéresser la vie réelle. Questions pertinentes aussi sur la "certification" Google, qui ressemble fortement au business model Apple (avec son iPhone) : l'accès au vivier d'applications (qui fait beaucoup, sinon toute, de la valeur ajoutée) n'est disponible que si la déclaration de compatibilité est statuée ; imaginons un appareil qui dispose de hardware (une webcam, par exemple) nécessitant quelques hooks, nous voilà privé du tampon. Je trouve que pour du libre, c'est compréhensible d'un point de vue industriel, mais ça craint dans l'absolu. Ceci me conforte dans mon idée : j'attendrai MeeGo (c'est cher, un smartphone, avez-vous remarqué ?). Toujours est-il que le succès d'Android est manifestement fulgurant (mais les entraves plaisent au monde industriel, je pense qu'il y a une fonction psychologique de masochisme latent, un jour j'écrirai un mémoire de socio dessus, promis -- enfin, si j'ai le temps).

Je me disais que l'après-midi, personne ne viendrai. Après tout, la présentation de Pierre le matin, sur Qemu, afin de tester sur la plate-forme de développement un système cible (le userspace, en fait, mais justement Pierre a fait pour nous un détour par le kernelspace : OpenWide -- enfin, OS4i, la branche pour l'embarqué -- a utilisé Qemu pour supporter un vieux système faisant appel à du matériellement deprecated pour une couche de virtualisation bien maligne), aurait pu satisfaire les aspirations techniques de l'auditoire. Que nenni : ce fut plus geek, plus roots, plus avide de bas niveau et de goût du silicium. Un public tellement nombreux qu'il y en avait assis dans la travée centrale, d'autres ayant même détourné des sièges pour les ramener sur le côté. Juste impressionnant.

Pierre Ficheux a donc montré l'étendu de son savoir-faire en matière de présentation (mais pas en matière de schématisation ! :)  Il faut lui proposer un DIF pour manier Inkscape, je ne vois que ça), en enchaînant coup sur coup "Comment accélérer le temps de boot d’un Linux" (trucs et astuces au programme) puis "Comment déboguer le cœur Linux" (en l'occurrence avec kgdb et kdb). Qu'il me soit permis de remercier Pierre : il a introduit admirablement bien ma conférence, soit volontairement (avec des "cf conférence suivante par Gilles Blanc" explicites), soit... involontairement, avec le bricolage de debug ou la phrase qui m'a fait bien rire : débugguer en assembleur le kernel Linux, c'est la galère la plus totale. Ce qui est fort vrai, preuve en a été donnée par ma personne juste ensuite.  :)

Il m'a donc non seulement été donné de mener ma première conférence à RTS, mais en plus de le faire après Pierre, ce qui est un grand honneur : la dernière conférence sur Linux embarqué à laquelle j'avais assisté le faisait figurer en bonne place, c'était il en 2007 ce me semble, j'étais tout jeune et dans l'assistance, mais n'en avais pas moins envie de franchir la table des conférenciers. Hasard du sort, mon sujet s'est donc porté sur de l'ultra-geek (tandis qu'habituellement, en conférence, je donne exactement le contraire : état des lieux du marché, stratégie de mise en place de Linux, pertinence, etc, le tout pour un large public) : comment utiliser le câble J-Tag du pauvre (sinon, on parlerait de "sonde") pour débugger sur le pouce un Linux récalcitrant, et ce dès le démarrage (c'est-à-dire que l'on n'a même pas de log en console, ou une console inopérante, et peut-être pas même encore de MMU).

Mes lecteurs depuis les débuts (ou presque) de ce blog auront sans doute reconnu mon aventure de 2008, que j'avais conté en deux parties. En version simplifiée sur slides, ça donne du burlesque, et je suis fier de vous annoncer que seulement une quinzaine de personnes ont abandonné en cours de route. Denis Bodor, rédacteur en chef de GNU/Linux Magazine France (dont le dernier numéro hors série sur les systèmes embarqués est excellent -- à ce propos, Pierre a reçu un mail de remerciement pour son article sur Buildroot, qui a sauvé des vies : pourquoi ne reçois-je rien dans ce genre, moi, hein ?), et qui a du fond de la salle assisté à ma présentation, m'a révélé que plusieurs personnes se disaient entre elles que dans la vraie vie, c'est souvent comme ça que ça se terminait. Avec la méthode scout. D'ailleurs, à la fin de ma conférence (et donc de la journée spéciale Linux embarqué), après ma démonstration (qui a marché du premier coup !) consistant à "rediriger" les logs, normalement envoyés sur le port série, sur la console gdb via le J-Tag, un petit groupe d'intéressés s'est formé, et entre ceux qui dessoudent au briquet et ceux qui soudent du FPGA à l'étain, on s'est retrouvés un peu bête. On trouve toujours pire que soit (surtout chez les hardeux).

Mais revoilà que je suis trop long (quoique cette fois-ci, comme on m'a beaucoup pressé, j'ai terminé à l'heure !). Voici donc les slides : bonne (re)lecture !

jeudi, avril 8 2010

RTS2010

Très bon cru pour cette session 2010 du salon RTS. Certes la période des années 2000 est définitivement résolue, et le hall 8 de la porte de Versailles pour être rempli fait toujours appel aux pendants M2M (communications de Machine à Machine) et Display (composants d'affichage). Les grands stands privatifs d'exposition ont disparu, mais les groupes étrangers de matériel ont fait leur apparition ; note pour les Chinois : de grands sourire et l'air avenant sont nécessaire en Europe ! Déjà que l'on présage avec appréhension une séance d'Anglais baragouiné pas bien constructive, la bonne vieille méthode de la jolie communicante a aussi toujours son succès ; même si son taux a très fortement décru aussi. Petite aparté sur la parité : c'est hautement catastrophique, dans les allées, dans les salons, sur les stands (où c'est forcément beaucoup mieux), c'est juste pire qu'avant ; compter à la louche 5% de représentation. Autre disparition aussi : les quelques rares sociétés de service (je pense notamment à Teamlog, l'année dernière, qui avait une jolie démo sur son stand, pas assez aguicheur à mon avis) ; je n'en ai compté qu'une seule, proposant de l'offshoring en Tunisie. Mais dans l'ensemble, c'est une sacrée réussite, et il faut saluer le travail d'organisation de Francis Mantes (rapidement croisé, l'appareil photo à la main).

Comme d'habitude, WindRiver avait l'entrée du salon, et NI le stand le plus grouillant de T-shirts corporate devant des démos attirantes : le pendule inversé existe donc bien en dehors des TDs Matlab de cours d'automatique... À ce propos, Matlab n'était pas présent cette année, donc Polyspace non plus, et son concurrent Coverty ne s'est pas plus déplacé (adieu le goodie de l'année !) ; ne restait plus que Emenda, comme micro-société distributrice de solutions de logiciels de couverture de code. Des cartes électroniques sont suspendues ou sous cloche un peu partout, et l'on compte presqu'autant d'Atom que d'ARM, même si à la discussion, c'est toujours les Anglais qui gagnent. À ce petit jeu, WindRiver reste tout autant agnostique que pour le non-choix entre Moblin (Intel) et Android (Google) : on se rappelle qu'ils ont été rachetés par Intel au moment où ils nous parlent de la prochaine génération d'Atom dans les cartons (Morse, si mes souvenirs sont bons). Rachetés aussi et disposant cette fois d'un stand indépendant, contrairement à deux ans auparavant où ils squattaient Neomore (toujours présents, non loin d'Anticyp), Trolltech devenu Nokia (la marque norvégienne s'est totalement effacée, mais les bureaux n'ont pas déménagé en Finlande) faisait figurer les deux même Français expatriés, et présentant une solution Qt 4.6 au succès largement plus important : voilà un rachat qui a eu du bon pour eux. Leur conférence, à 13h, le second jour du salon, a aussi connu un franc succès -- cependant, les informations réellement trépidantes ont été un peu absentes, surtout lorsqu'on apprend que le projet MeeGo, fusion de Moblin et Maemo mais sur du Qt, est très très loin d'être prêt).

L'intéraction sur les stands était fort constructives, et si aucune affaire immédiate n'a pu être rapportée -- nous sommes sur un salon de vendeurs, c'est assez logique, il faudrait son propre stand pour cela, et je ne suis pas bien certain, vu le succès des fournisseurs de service, de la pertinence par rapport au public industriel assez prudent --, des partenariats très intéressants sont clairement à attendre. L'avenir dira. On constate par ailleurs le problème récurrent de mauvaise vision des "partenaires" (ou concurrents, plutôt) entre eux, tout clairsemés qu'ils sont au quatre coins de la France, si ce n'est du monde, et ne navigant pas eux-mêmes dans les allées -- à l'exception de quelques uns, par ailleurs très notables. Passons à la page publicité pour ceux à qui j'ai promis de parler ici, parce qu'ils le méritent, parce qu'ils m'ont fort bien accueilli, ou parce qu'ils m'ont fortement intéressé.

Tout d'abord, un petit erratum pour Greenhills (à l'équipe toujours aussi sympathique), puisque dans mon précédent compte-rendu j'avais totalement fourché sur un paragraphe, à présent corrigé ; je précise au passage que seul le Pape est infaillible (sous certaines conditions, qui plus est), et je peux donc écrire des bêtises scandaleuses, que vous pouvez me pointer en commentaire ou par mail (ceci dit, s'en rappeler un an plus tard était impressionnant de la part de Serge Plagnol !). Ensuite, je voudrais attirer votre attention sur un jeune entrepreneur ayant réalisé (en PyQt !) un logiciel de création de Linux embarqué du même nom que la distribution ainsi obtenu : Yaeld (Yet Another Embedded Linux Distribution : on est geek ou on ne l'est pas). Basé sur OpenEmbedded, l'interface est extrêmement intuitive, et permet de paramétrer très finement le projet sur-mesure. Reste à sortir une version définitive du projet (très prochainement, si ce n'est déjà fait) et à arriver à le commercialiser : c'est-à-dire à se faire connaître (j'y participe) et à convaincre qu'un tel outil fait facilement gagner une semaine de production et quelques arrachages de cheveux, soit de quoi justifier un investissement de quelques milliers d'Euros. Je souhaite bonne chance à notre héros breton Thomas Jourdan. Enfin, un petit mot sur AcidOS (attention : site moche), micro-kernel très innovant, écrit from scratch sur un modèle L4 mais bien plus optimisé (en se débarrassant de la couche POSIX), pouvant relancer des services à la volée en faisant migrer la mémoire virtuelle : en cas de détection d'instabilité ou de faille de sécurité (ce sont des anciens de Hackademy, m'a-t-on dit), le service kernel (en mode protégé) peut être ainsi relancé à chaud au prix d'une interruption de service imperceptible. Quand on sait qu'à la manière d'OKL4, un service peut être une paravirtualisation de Linux, voilà qui est tout à coup extrêmement intéressant ! (en outre était présente sur le stand à l'ambiance fort sympathique, la plus agréable des expertes en café qu'il m'ait été donné de rencontrer)

La seconde journée était consacrée pour ma part (et celles de beaucoup d'autres !) aux conférences de la journée spéciale Linux Embarqué. Un compte-rendu est donc à venir dans un prochain billet. Le temps que je rajoute une licence à mes slides, pour commencer...

jeudi, mars 25 2010

Solutions Linux 2010

Plus exactement, pour ce qui nous intéresse : les conférences sur l'embarqué du jeudi 18 mars, toujours organisées par Sébastien Dinot, membre émérite de l'APRIL et salarié de CS. Les conférences étant payantes sur Solutions Linux, le public était assez peu nombreux, une douzaine de personnes en plus des conférenciers eux-même, dirais-je. Suite au désistement de l'intervenant d'Armadeus, le nombre de conférences s'est donc réduite à trois, mais le contenu s'est prêté au remplissage du temps imparti, de 14h00 passés à 17h30 environ.

Première intervention de la part d'un enseignant-chercheur de l'ENAC (Aviation Civile), Pascal Brisset, à propos du projet paparazzi UAV System (Unmanned Air Vehicule). Il s'agit d'un ensemble de composants logiciels (en C/C++/OCaml, basé sur Debian, compilé par GCC, usant de GTK et du bus logiciel Ivy : que du libre !) permettant de mettre en place "simplement" un système de d'autoguidage (pilote automatique) : aérien de type microdrône ou quadrotors (sorte d'hélicoptère à quatre hélices), ou terrestre. La présentation a mis l'accent sur les problématiques inhérentes à ce type de système (notamment en terme de détection et les latences que cela implique, différentes selon les types de véhicules). Très particulier, mais idéal pour ouvrir des horizons insoupçonnés (il est assez étonnant de constater qu'une communauté, certes réduite mais active, s'est formée autour de ce projet très particulier !).

La seconde intervention portait sur OpenEmbedded, système que je connais fort bien pour l'avoir pratiqué il y a trois ans, chez Sagem (ma vie avant Linagora). La présentation du jeune Cyril Romain, employé aussi par CS mais sur d'autres sujets que l'embarqué, qui s'est passionné à titre personnels pour le sujet notamment à cause de son PDA, fut fort claire, à mon sens. Elle ne souffrait seulement de n'être pas assez orientée vers les problématiques des utilisateurs professionnels, ce qu'a inévitablement été soulevé en questions ; j'ai donc pu compléter en ce sens sa présentation sur ces points : comment OpenEmbedded aide aux respects des licences, les temps de prise en main et de construction et surtout les limites de l'automatisme de la construction d'images (un firmware est quasiment tout le temps composé d'une partie RO et d'une autre RW, soit deux partitions, sur lesquelles s'étale le système : à ma connaissance, aucun SDK ne gère cette problématique complexe). Au final, la présentation était très bonne, et notre intervenant de qualité : j'espère que ses slides seront disponibles publiquement, auquel cas je ne manquerai pas d'ajouter un lien vers elles dans mon cours sur Linux embarqué !

La troisième et dernière intervention était de mon collègue et responsable d'équipe Benoît Donnette, à propos du bus logiciel Tango. Ce middleware de bus logiciel nous a effectivement occupé essentiellement de mai à septembre 2009, dans le cadre d'un projet de refonte d'un système de contrôle-commande pour le compte du CEA, et ayant réalisé la plupart des "device servers" (couche logicielle de contrôle-commande côté machines) et les interfaces graphiques (côté utilisateur), tout autant que la première étude technique sur le sujet, j'étais hautement concerné, et ai pu participer à l'intéraction avec le public, puisqu'étaient spécialement présents quelques personnes du CEA, et notamment l'un des concepteurs originaux du projet.

Forcément, à la fin de cette série de conférences, les discussions sont allées bon train, et des contacts très intéressants ont été pris.

mardi, mars 23 2010

Conférence RTS2010 : Journée spéciale « Linux embarqué »

Mercredi prochain (31 mars) aura lieu toute la journée sur le salon RTS une série de conférences sur le thème de Linux embarqué. Thème qui m'est cher, comme vous le savez bien. Le modérateur sera l'habituel François Gauthier, qui a communiqué le programme exact hier (outre le fait que 215 personnes sont déjà inscrites !) :

Linux est devenu au fil des ans un système d’exploitation incontournable dans l’embarqué. Et il ne cesse d’évoluer, notamment à travers la notion de plates formes, comme Android, pour les appareils portables ou Genivi pour l’automobile. Le matin les exposés porteront sur les ambitions de ces plates forme logiciel en Open Source, basées sur Linux, et l’après midi sur les méthodes de débogage et d’analyse de Linux pour l’embarqué.

Matin (10h-12h30) :
“Android, Linux and Real-time Development for Embedded Systems”, par Colin WALLS, Mentor Graphics
“Accélérer et innover avec Android”, par Sebastien Lalaurette, Wind River
“Le simulateur Qemu et le projet couverture”, par Pierre FICHEUX, Openwide

Après-midi (14h-16h30) :
Tutorial Linux pour l’embarqué, par Pierre FICHEUX Open Wide
    _ Part I : Comment accélérer le temps de boot d’un Linux
    _ Part II : Comment déboguer le cœur Linux
“Utilisation de gdb et OpenOCD (logiciel de gestion J-TAG libre) dans le cadre du débogage bas niveau du kernel lors de la phase d'initialisation”, par Gilles BLANC, Linagora.

Vous l'aurez remarqué, j'interviendrai en dernier, et honneur m'est fait de succéder à Pierre Ficheux. Cependant, ma présentation ne sera certainement pas sur le même ton, mais plutôt une plongée technophile dans le coeur de Linux, avec peu de moyens et beaucoup de courage : ce sera une reprise d'un développement que j'ai effectué en 2008, et relaté ici-même. La présentation devrait durer 45 minutes environ, et si le Dieu des Pingouins sera clément, il devrait y avoir une démo (très impressionnante, avec des effets pyrotechniques, et qui donnera lieu à... l'obtention d'un shell).

vendredi, mars 12 2010

dolosif arrière

Une technique très SSIIène consiste en la vente d'un projet sous-évalué, puis en la signature d'avenants au fur-et-à-mesure, surtout quand le client est dos au mur et ne peut plus reculer, qui s'accumulent jusqu'à faire exploser le budget initial. Technique célèbre, qui est évidemment le mal. Ne serait-ce que parce que la réputation du métier en pâtis. On pourrait d'ailleurs se demander si c'est la baisse des tarifs acceptables par les clients (longtemps plumés, dans les années 80/90 -- si vous saviez combien a coûté le site web de Radio France, et encore pas la totalité, c'est à pleurer -- c'est que ce sont nos impôts...) qui a entrainé ce genre de techniques contestables pour se rattraper (faire croire que ce n'est pas cher alors que oui, ça l'est vraiment), ou si c'est la concurrence entre sociétés proposant du service informatique, tirant toujours plus bas les prix (et donc les salaires -- problème connexe : un ingénieur mal payé est un ingénieur démotivé, faudrait-il toujours se rappeler ; et un ingénieur démotivé travaille plus lentement et produit plus d'erreurs), qui a pour effet de fausser ladite concurrence en annonçant des prix qui ne sont pas les bons dès le départ. Ou peut-être est-ce dû à une mauvaise émulation des deux phénomènes.

C'est en tout cas une dérive clairement constatée, qui en fait part d'un fait tout bête : les engagements contractuels portant sur du résultat (et non du moyen) nécessitent une estimation et une vision qui est rarement la bonne dès le départ (évidemment on fait ce que l'on peut, mais la boule de cristal est hors de prix chez Swarovsky® !), et qui est donc sujette à évolution (sachant que les cas litigieux ne sont pas rares : j'ai un ami informaticien fraichement retraité qui ne s'occupait plus que de ça à la fin de sa carrière, notamment sur la ligne 14 Meteor du métro parisien, où ça a pas mal chauffé paraît-il) ; on sait aussi que l'on fait généralement son beurre sur les avenants (ne serait-ce que parce que la phase d'avant-vente est inutile ou réduite à son maximum, et que l'expertise à faire valoir sur le produit est évidente). Il n'empêche que les (très) gros projets peuvent déraper, et ce de manière spectaculaire.

Rappelons encore : l'ingénieur a un devoir de conseil, et a fortiori la société qui l'embauche. Question de bonne ou de mauvaise foi. Les 11 millions d'Euros de condamnation d'IBM (première instance, appel évidemment interjeté, mais en tout cas une exécution provisoire ordonnée, donc les 11 millions doivent être versés, avec tout ce que ça implique en terme de trésorerie) tendraient à mettre un frein sérieux à ce genre de pratiques, qualifiées "manoeuvres dolosives" (rappelez-vous de vos cours de droit, différence dol/vol -- le dol est la tromperie, la fraude, ce qui implique d'avoir su dès le départ mais de n'avoir rien dit pour en tirer profit, dans notre affaire). C'est sûr que doubler une facture de 7,3 millions et le temps de réalisation en cours de route, avec tout un tas d'inconvénients très impactant sur la société cliente, ça fait vraiment mal. À noter aussi que la MAIF s'est plainte au TGI, et non au tribunal de commerce (je me demande pourquoi, en fait, puisque Niort en possède un ; va falloir que je demande à notre juriste). Je partage en tout cas l'analyse de l'experte de 01 (encadré tout en bas).



Au passage, un peu de linguistique historique, histoire d'expliquer le titre (il me semblait bien que le Littré n'allait pas au bout des choses entre dolus pour dol, et dolorem pour douleur -- quelqu'un a un Alain Rey sous la main ?) :

En latin classique, la notion de deuil fait partie du sémantisme de dolor. Cicéron, de Oratorio, 2, 199 : "Par mon discours, je ravivais la douleur (dolorem), de ceux qui avaient à pleurer des parents."
Ainsi dolus est une simple variante de dolor. Pourquoi apparaît-il ? Cela s'explique probablement par des considérations formelles et sémantiques :
- forme : le paradigme de dolor renferme une forme ambiguë : le génitif pluriel dolorum. Une réinterprétation permet le changement à dolus.
- sens : il y a des exemples limites : dolus : mal, malice; mal s'apparente à douleur.
L'exemple ambigu remonte au Ier ap., dans la Thébaïde de Stace, 5, 117-119, qui fait allusion aux crimes des Danaïdes qui tuèrent leur mari avec la complicité de leur père qualifié de "la‘tus (riche) dolorum (ruse et deuil)." La ramification au dédoublement lexical se produit à l'époque du latin tardif. La comparaison des langues romanes joue un rôle. L'histoire d'une langue particulière s'appuie aussi sur l'histoire des langues du même groupe.

jeudi, mars 11 2010

acceptable values

}

static int
dacmdsizesysctl(SYSCTL_HANDLER_ARGS)
{
    int error, value;

    value = *(int *)arg1;

    error = sysctl_handle_int(oidp, &value, 0, req);

    if ((error != 0)
     || (req->newptr == NULL))
        return (error);

    /*
     * Acceptable values here are 6, 10, 12 or 16.
     */
    if (value < 6)
        value = 6;
    else if ((value > 6)
          && (value <= 10))
        value = 10;
    else if ((value > 10)
          && (value <= 12))
        value = 12;
    else if (value > 12)
        value = 16;

    *(int *)arg1 = value;

    return (0);
}

static cam_status
daregister(struct cam_periph *periph, void *arg)

Au moins, ça ne manque pas d'originalité. Je vous ai mis ce qu'il y autour afin de bien se rendre compte du vide intersidéral de commentaires utiles autour de ce fabuleux effet de bord sur une variable récupérée par macro, et transvasée de manière bien folklorique (dommage que le traitement ne soit pas fait par masques de bits, tout de même !). Autour de la ligne 1010 du driver SCSI de freebsd.

vendredi, mars 5 2010

le vendredi c'est permis

The $5 Guerrilla User Test est un article proprement hilarant mais on ne peut plus sérieux : il expose une manière simple de tester ses créations logicielles sans avoir à embaucher un crétin, ou quelqu'un qui "pense crétin" afin de rendre le programme "idiot-proof" "user-proof". L'idée de base est qu'en réalité, l'utilisateur n'est pas stupide, il est juste distrait en permanence, et ne porte pas attention à ce qu'il fait (OK, il y en a qui sont vraiment stupides, mais gardons foi en l'humanité -- c'est notre vivier de clientèle potentielle après tout). Embaucher un fonctionnel pensant stupide n'est donc pas la bonne solution : la seule chose que cela va créer, c'est une interface ultra-simplifiée qui ne fera pas ce qui est attendu, et deviendra à terme une insulte à l'intelligence (ça me rappelle...). En revanche, le "$5 guerrilla user test" propose d'aller voir de vrais gens de tous les jours, mais dans un état entre la concentration et la distraction.

Pour cela, il suffit d'aller dans le bar d'en face (pour nous : le Washington ou le Bowler ; faudra se re-renseigner après le déménagement), et d'aller vers la bonne personne qui semble ouverte pour tester le logiciel (l'article propose tout un tas d'astuce pour repérer les bonnes personnes -- personnellement j'aurais plutôt tendance à aller vers la gent féminine, mais je n'aime pas beaucoup les blondes), pour lui proposer une bière en l'échange du test (d'où les 5$ -- notez que la bière vient en récompense après, logique, ce qui implique de choisir une personne déjà "installée"). La technique d'approche est aussi longuement exposée (retours d'expérience en commentaires, aussi). Les résultats sont paraît-il exceptionnels. À quand des sessions de Linshare ou d'OBM dans les bars ? (on pourrait installer une distributeur de bières sur le stand de solution Linux, sinon... Je suis sûr d'emporter l'adhésion de beaucoup de geeks linagoriens)


disclaimer: l'auteur de ce billet ne boit que du lait fraise ; à consommer avec modération, l'abus de génie logiciel est mauvais pour la santé

update 10 minutes plus tard: on me fait déjà remarquer qu'en France, surtout à Paris, ce serait plutôt autour de 8€ le test (le cours de la bière est bien supérieur)

mercredi, mars 3 2010

money drain

Très bon article des échos : "Start-up informatiques : razzia sur les pépites". Après le brain drain qui prive le pays de ses brillants cerveaux (sur mon nouveau compte linkedIn, je vois du Citrix à Cambridge, du VMWare à SF, mais je connaissais déjà du Microsoft à Redmond, et j'en passe -- c'est d'ailleurs comme ça, à mon avis, que la promotion de Génie Industriel de l'EPITA a surpassé en terme de salaires les autres filières, il ne faut pas se le cacher : allez simplement voir les salaires de techniques chez ARM outre-manche), tandis que c'est l'État qui paie la formation, l'inquiétude peut légitiment se porter sur les multiples rachats de start-ups françaises, par les américains principalement. C'était le cas d'ailleurs de la société d'un ami, dans la téléphonie mobile, par Microsoft (c'est lui qui bosse à présent à Redmond). Ça été aussi le cas de Trango Virtual Processor, où j'ai travaillé, par VMWare ; et avant ça de Mobivillage, où j'ai été stagiaire, par un groupe géant japonais (en 2004, pourtant, mais la téléphonie mobile, c'est impressionnant là-bas). L'année dernière, on notait sur le salon RTS le rachat de Polyspace par Mathworks (notons qu'avec un nom anglophone, ça facilite d'autant la mondialisation -- et ses effets secondaires de "concentration"). Quant à Business Object... (couic, dans l'oeuf !)

Des start-ups, j'en connais aussi. Et l'investissement par levée de fonds, je connais indirectement, soit en observant du côté des entreprises, soit en discutant avec l'un de mes amis (qui effectivement investit encore plus depuis la loi TEPA). Généralement, c'est un gouffre : des millions d'Euros en entrée, pas grand chose en sortie. Pourtant, il faut bien évoluer, l'innovation est une absolue nécessité. J'avoue ne pas bien voir comment résoudre la situation. Un pacte PME acté par une loi ("investissement" des grandes société obligatoire dans les petites) peut effectivement sembler pertinent (après tout, on se bat pour des bouts de ficèles quand les grands groupes dégagent des bénéfices extraordinaires, sur des marchés souvent étrangers ou publics...). À entendre Daniel Glazman, par exemple (disruptive innovation : in English, again), les formalités, le poids de l'administration, entravent grandement la productivité (et donc l'innovation) seule (d'un autre côté, c'est notre identité nationale !). J'avoue être assez pessimiste d'une manière générale sur l'entrepreneuriat à l'heure actuelle ; d'ailleurs je pense que toutes les sociétés rachetées ne faisaient pas un sou de bénéfice (ah, les levées de fonds à 2 ou 4 millions d'Euro, malgré la collection de projets estampillés "Européens" ou les CIR à en pleuvoir...). Vraiment, je ne vois pas. Mais de la technologie qui s'en va à l'étranger (même en restant sur le sol national), ce n'est jamais très bon signe.

(c'est quelque part une sécurité à Linagora : je sais qu'on ne se vendra jamais, question d'hommes)

jeudi, février 25 2010

slides de la conférence GCC par Basile Starynkevitch

Basile Starynkevitch avait déjà donné une conférence pour Parinux il y a deux ans ; il est revenu ce 12 janvier dernier à l'espace rue de la Bourdonnais donner une conférence sur son même sujet de prédilection, le compilateur libre gcc. Sous une optique propren car il est le développeur d'un outil d'analyse de code MELT, greffon de gcc, consistant un langage de programmation pouvant être greffé à du code compilé par gcc pour effectuer de l'analyse (type tests unitaires, ça me semble très utile en tout cas dans le cadre de la certification logicielle) ; MELT est un langage complet, et le greffon MELT est codé en MELT. Ses slides sont disponibles, et je vous invite à les consulter (en réalité, deux tiers de conférence, soit 1h30, ont été consacrés à gcc en général). On constatera ainsi le franc parler de l'un des 2000 développeurs de gcc de par le monde, notamment à propos des préjugés sur le C ou l'assembleur.

lundi, janvier 25 2010

commentaire expiatoire du jour

Il ne faudrait pas que cela devienne une habitude, mais comment m'empêcher, chers lecteurs, de vous faire partager ce commentaire d'excuse d'une mauvaise foi évidente ? (trouvé là)

GHashTable *gaim_dbus_iter_hash_table(DBusMessageIter *iter, DBusError *error) {
    GHashTable *hash;

    /* we do not need to destroy strings because they are part of the message */
    hash = g_hash_table_new(g_str_hash, g_str_equal);

    do {
        char *key, *value;
        DBusMessageIter subiter;

        if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_DICT_ENTRY)
            goto error;         /* With all due respect to Dijkstra,
                                   this goto is for exception
                                   handling, and it is ok because it
                                   avoids duplication of the code
                                   responsible for destroying the hash
                                   table.  Exceptional instructions
                                   for exceptional situations. */

        dbus_message_iter_recurse(iter, &subiter);
        if (!gaim_dbus_message_iter_get_args(&subiter, error,
                                             DBUS_TYPE_STRING, &key,
                                             DBUS_TYPE_STRING, &value,
                                             DBUS_TYPE_INVALID))
            goto error;         /* same here */

        g_hash_table_insert(hash, key, value);
    } while (dbus_message_iter_next(iter));

    return hash;

 error:
    g_hash_table_destroy(hash);
    return NULL;
}

add: Et juste en dessous, le scandale :

#include "dbus-bindings.c"

void *gaim_dbus_get_handle(void) {
    static int handle;

    return &handle;
}

lundi, janvier 18 2010

le code geekesque du jour

static void
to_be_or_not_to_be (void)
{
/*
* If all of the options that control our policy are disabled, then we
* have no point in living. Save the user some memory and exit.
*/
/* you used to say live and let live... */
gboolean live = FALSE;
size_t i;

/* ...but in this ever changing world in which we live in... */
for (i = 0; i < G_N_ELEMENTS (gvm_settings) && !live; i++) {
if (gvm_settings[i].type == TYPE_BOOL)
live = *((int *) gvm_settings[i].var);
}

/* makes you give it a cry... */
if (!live) {
dbg ("daemon exit: live and let die ");
exit (EXIT_SUCCESS);
}
}

Toi aussi, amuse-toi à compter les références dans ce morceau de code...

jeudi, janvier 7 2010

man of the day

struct hostent *gethostbyaddr(const void *addr,
                                     socklen_t len, int type);

The gethostbyaddr() function returns a structure of type hostent for the given host address addr of length len and type type.  Valid address types are AF_INET and AF_INET6.  The host address argument is  a  pointer  to struct a of  a  type depending on the address type, for example a struct in_addr * (probably obtained via a call to inet_addr(3)) for address type AF_INET.

Les italiques sont de moi. Bon bein pour réimplémenter le bousin, je sens que ça va être fun...

dimanche, décembre 27 2009

revue de presse

Il faut bien avouer qu'avec la masse de boulot de ces derniers temps, la revue de presse est quelque peu passée à l'as. Pourtant, bien des choses intéressantes peuvent être trouvées en tant que parfaite transition avec le billet précédent. Et déjà, comme je me demandais ce que devenais l'architecture SuperH, chez Renesas (qui possède la licence), la branche SH-mobile (sous SH4-A) tourne à présent sous Linux par défaut -- leur site peu prolixe en terme de software, il n'est pas précisé si le "RTOS" remplacé est cette horreur de la nature de OS20/0S21, reliques d'un autre temps. 35% moins cher.

Ensuite, parlons Android, alors qu'une "alliance" Google-Intel prend implicitement forme avec la décision par WindRiver de lancer une offre comerciale Android. A considérer les concepts de programmation mêlant java, html et javascript, je reste quelque peu dubitatif. Et l'API mouvante autant que la dépendance au SDK ne me rassure guère. Pis encore, la licence permissive Apache recèle de désagréables surprises, et c'est à se demander au final quel est donc ce bordel made by Google que l'on hérite là. Quant à Chromium, machin plutôt mal défini déjà sujet à bouts de scotch, la cible visée serait finalement assez réduite -- bien plus en tout cas que ce que prés(s)entait ARM sur son salon. J'ai peur de faire une présentation trop pessimiste, et invite donc à la lecture des différents (et fournis) articles ; pour ma part, j'en garde une impression de prudence à montrer vis-à-vis de ce nouvel engouement. Peut-être deviens-je moi aussi un vieux barbu ayatollah sur les bords, allez savoir.

En tout cas, côté interface web, la fonera 2.0n basée sur du OpenWRT est très sexy. Et le Nokia N900, sur Maemo5, est absolument formidable, avec cependant deux bémols : la weberie est basée sur un navigateur mystère (Firefox allégé ?) et un Firefox-bloatware, et le framework n'a pas encore migré sur Qt, donc toujours du GTK. N'empêche, bavez donc comme moi sur les vidéos, c'est impressionnant, et l'ouverture de la plate-forme est bien plus assurée que lors des premières releases en 2006 (quelle galère pour trouver le code !), avec des applications par lots qui ne nécessite pas d'avoir un avocat (Adroid) ou une carte blueue (iPhone) sous la main. Bref, si Google n'avait pas un gros rouleau-compresseur commercial, je parierais plutôt sur Maemo6 avec Cortex-A9 (pour l'instant, le N900 est sur du A8, il rame manifestement moins qu'un iPhone, mais ce n'est pas encore parfait à voir les vidéos de tests indépendants) avec une sortie d'ici 9 mois. Mais avec le peu de vague soulevée par un concurrent pourtant très sérieux au machin d'Apple (à l'intégration toujours très réussie, mais aussi pénible à délocker qu'un Android à rooter : ce n'est pas ouvert pour un sou !), je crois que je vais redevenir pessimiste...  :/   (d'un autre côté, Nokia reste leader et compte remplacer définitivement sa branche haut de gamme avec le N97 par du Linux/Maemo, sachant que son public habituel n'est pas forcément habitué à verser 650€ pour un téléphone ; il faut aussi considérer que la concurrence ayant été longtemps dépendante de Symbian -- quand bien même Motorola et RIM proposait des alternatives sérieuses --, un détachement de Nokia pour autre chose, même moins libre, mais "apparemment indépendant" pourrait se comprendre)

Pour finir, et parce que c'est Noël, un excellent article de démystification des SSDs, qui dépasse un peu le cadre "NAND avec contrôlleur" pour parler Flash d'une manière plus générale.

mardi, décembre 22 2009

ARM European Technical Conference 2009

Comme l'année dernière, et certainement celles d'avant (j'avoue ne pas connaître les origines exactes de l'événement), avait lieu en ce jeudi 10 décembre passé l'ARM European Technical Conference (AETC pour les intimes) 2009, au même lieu que l'année dernière, CAP15 près de la tour Eiffel. J'arrive très tôt (pour moi) mais manifestement, beaucoup de monde a son rythme de vie câlée sur nos amies aviaires, et la grande salle de conférence est déjà bien garnie. On y parle Anglais, comme toujours dans les conférences de cet événement réellement européen -- comprendre qu'il y a quantité d'Allemands (patron, ma formation de langue !), d'Anglais, et quelques Russes --, mais la langue véhiculaire laisse plus souvent que l'année dernière au vernaculaire sur les stands du forum voisin -- je n'ai pas pris de photo, mais l'organisation était tout aussi semblable qu'en 2008. Pour les personnes présentes qui passeraient sur ce compte-rendu, puisque chez Anticyp on m'a dit être déjà venu me lire, et qui ne me remettrait pas, j'étais tout de gris et violet vêtu, un chapeau sur la tête (quelques commentateurs, mais pas des plus fins, s'inquiétant régulièrement sur ce point).

Comme je ne pense jamais trop aux mékeskidi, et que chez Linagora, certains administrent des réseaux ou mettent en place des messageries, bref n'ont rien à voir avec l'embarqué mais trouvent peut-être ma prose intéressante, je rappelle donc que ARM est la société anglaise à l'origine du microprocesseur du même nom, que l'on trouve décliné sous différentes gammes depuis une vingtaine d'années dans tellement d'appareils embarqués, qu'il ne fait aucun doute qu'ils dominent le marché (et x86/Intel, me direz-vous ? Comptez le nombre de téléphones portables par foyer ; puis le nombre d'ordinateurs ; vous y êtes). ARM possède cependant une spécificité : ils ne sont pas fondeurs, comprendre qu'ils ne vendent pas directement des puces ni aucune sorte de hardware, mais seulement de la R&D pure, autrement dit pour les fondeurs que sont ST, NXP, TI ou ATMEL, pour parler des présents, il s'agit de récupérer des plans -- pour simplifier. La cible est néanmoins déterminée : il ne s'agit pas de grosses infrastructures réseautiques (plus propices à être sous PowerQUICC/PPC voire x86), ni de microcontrôleurs extrêmement simples de style PIC/68k (qui cèdent, certes, devant le Coldfire, dont on peut se demander si ARM ne gourmande pas par anticipation les parts de marché avec son dernier né, le Cortex-M3, mais je m'avance), mais il n'empêche que d'une cible de CE (Consumer Electronic), représentée sur le diagramme final par le "1 milliard de téléphones", la compagnie lorgne du côté des nouveaux mini-PCs (tout une histoire marketting, ce machin-là) avec 100 millions d'unités visées, et vers les "specialized devices" à hauteur de 10 milliards d'unités (une paille). Le démarrage en flèche du Cortex-M3, tout minuscule qu'il est (visible sur l'un des nombreux stands éparpillés d'ARM), destiné par exemple à être embarqué dans des montres, tendrait à soutenir cette espérance.

Malgré la crise, ARM va bien, et le fait savoir (quand bien même il n'y avait plus de fontaine au chocolat cette année -- mais le buffet était excellent, mes compliments au traiteur et à son équipe dévouée). Une slide montrant le foisonnement des microprocesseurs disponibles il y a une bonne quinzaine d'années, et de ce qu'il en reste en comparaison, fait l'impasse sur SH4 (pourtant très présent dans les STB et autres lecteurs en tout genre), sur SPARC (pourtant certaines archi intéressent le spatial -- ok, ça n'a pas empêché les CPUs de Thomson de défunter) ou sur PPC, montrant une promptitude à enterrer la concurrence qui m'a quelque peu amusé -- je n'ai pas eu le temps de demander sur le stand de ST ce qu'ils en pensaient... En fait, le concurrent principal Atom n'a pas droit de cité non plus. Et ça c'est vraiment méchant -- et pas forcément pertinent, mieux vaut prendre l'adversaire à bras le corps que de l'ignorer, en tout cas dans la bataille on sait où mon coeur va.

Il est beaucoup question de communauté, non pas libre mais autour de ARM, naturellement : par exemple, pour l'extension 3D Mali, le site malideveloper.com partage les informations plus simplement entre développeurs (le marché étant assez récent de ce côté, mais néanmoins à pente rapide comme on peut le constater en considérant les consoles de jeu video portables ; le vrai challenge pour ARM est clairement désigné : le multimédia et notamment la télévision, en concurrence frontale avec SH4) ; on évoque mbed.org, "rapid prototyping for microcontrollers" ; ou encore le projet plugcomputer, qui se donne d'agréger (le concept est un peu flou, je trouve) les idées de serveur miniature de "domotique" (le mot est devenu quelque peu tabou, à force), dans le style DLNA, connectivité centralisée à but applicatif, etc. En fait, remplacez le fameux "developers developers developers" de Ballmer par "community community community" : c'est le nouveau maître-mot. Désenclaver le développeur, mais aussi le décideur (cf la multiplication des blogs pro), voilà une idée qui a l'air aussi bête qu'évidente, mais qu'aucun ne s'était attelé à mettre en oeuvre jusqu'à présent. Si l'on considère la récente communauté autour de Montavista (meld), on voit bien que le mouvement est amorcé : c'est à qui fédèrera le plus autour de lui, en offrant comme valeur ajoutée un partage de connaissance. Ça ne vous dit rien, comme fonctionnement ? Linux embarqué, ce n'est pas seulement un OS gratuit qui entre dans le paysage, je ne cesse de le répéter, c'est l'arbre qui cache la forêt du libre dans l'embarqué, techniquement et dans la pratique : c'est une nouvelle façon de penser, de concevoir, par le partage (d'information pour le moment, mais le code commence à venir, voyez la suite), mot totalement inconnu jusqu'alors dans le monde industriel. Ça fait du bien.

Linux est un mot qui revient souvent, et que l'on trouve décliné sous les formes "Ubuntu" ou "Mozilla" (bon, on sait ce que j'en pense...). Mais ce qui revient encore plus, c'est Android, et Chrome. Le premier, on commence à le connaître, son succès, surtout depuis la dernière version, est impressionnant, et il ne faut pas s'étonner de le voir partout où l'environnement est pensé pour du fenêtrage simple, c'est-à-dire une application à la fois sur l'écran. Pour le multi-fenêtrage, ARM nous parle de Chrome : et là, j'avais raté un épisode. ChromeOS a été montré le 19 novembre dernier, et en fait, c'est l'une de mes prophéties qui se réalise (je suis meilleur que St-Jean le Baptiste, d'une manière générale, je fais donc attention à ne pas perdre la tête) : la migration de l'OS vers du tout-web, ie l'interface graphique utilisateur entièrement conçue à base de technologie web de type html/javascript, rendues par un navigateur puissant mais léger. C'est une question de logique : le but (dans lequel s'inscrit parfaitement Linux, qui est d'ailleurs le kernel sous ce ChromeOS) est d'abaisser le ticket d'entrée dans le monde de l'embarqué, et de le rendre plus fonctionnel ; fini les interfaces toutes pourries et obscures en assembleur et en frame buffer ! La montée en puissance (phénoménale) du hardware pour une consommation en énergie toujours meilleure sert exactement ces intérêts. À travers le logiciel, c'est l'utilisateur qui est remis au centre du problème. D'où la conclusion que je retiens : "Software is all about now", "software ecosystem decides !". La fin annoncée de l'électronicien raté, et l'arrivée du monde logiciel en position de force.

Après toutes ces bonnes nouvelles, place est laissée pour l'orateur suivant, qui nous parle d'un consortium rapidement identifié par mes soins comme du lobbying de hardeux, ce qui ne m'intéresse guère (on sait le milieu assez doué en la matière, parfois trop). Je migre donc vers les stands : passage chez -- ne riez pas -- Windows Embedded Business Group Microsoft France (toujours sur son WinCE 6.1, qui commence à dater, mais se voit affublé de service packs -- c'est une manie !), qui me donne gentiment une version de Windows Embedded 2011 (3cd : 32bit, 64bit et le toolkit), qui contrairement à XP standard est encore supporté quelques années ; entretien chez Montavista, qui distribue de la belle documentation sur son tout nouveau MontaVista Linux 6 (j'ai raté Maxime Petazzoni, dont je n'ai été au courant de la présence qu'à son appel en fin de journée pour gagner une mini-console de jeu, mais il était déjà parti !) ; et puis Ubuntu, qui présentait un petit PC de poche à clavier et écran tactile (dans les deux cas, mes doigts de pianistes étant déjà un peu trop gros : c'est pour le marché japonais, aussi...), de chez Sharp il me semble, sympathique mais à mon avis beaucoup trop geek, il n'y a qu'à considérer les parts de marché du N800, plus sexy quoique moins fonctionnel (mais plus réactif, en échange) -- côté software, en revanche, l'intégration est très bonne, mais firefox bouffe presque toute la mémoire, le menu convivial sur le bureau buggue encore un peu (ce n'est pas une version définitive qui était montrée), et parfois la machine freeze...

Tout le long de la journée, il y a aussi les sessions de conférences, quasiment toutes données par des gens de ARM, ou plus vastement de Keil, la partie software rachetée il y a maintenant un bon bout de temps : il ne faut alors pas s'étonner que lors du track32 "Advanced Debug and Optimization of Cortex-M processor-based Systems", on ne parle uniquement de la sonde J-Tag et des outils Keil, et nullement du JtagX ou autre sonde WindRiver que l'on vante tout aussi bien sur les stands d'Anticyp ou de Neomore. J'avoue sur la journée avoir moins assisté aux conférences que l'année précédente, ayant privilégié cette fois les stands -- sans pour autant avoir pu tout visiter, de ce qui aurait pu m'intéresser. C'est ainsi que je découvre MVD Training, dont le site affreux prouve bien qu'il s'agit de barbus de l'embarqué très bas niveau, et si l'on se fait concurrence sur les formations Linux embarqué/drivers, le reste est tout à fait complémentaire (notamment en terme de programmation), et l'offre assez unique à ma connaissance sur les formations très bas niveau (microprocesseur particulier, programmation, et au milieu : VHDL) me fait penser que mon DIF est plein à craquer (message subliminal).

Et puis je passe beaucoup de temps sur le stand Texas Instrument (Angleterre et Allemagne), pas seulement parce qu'ils possèdent la plus charmante des communicantes qui m'ait été de rencontrer (ciel, une Anglaise blonde -- immigrée en Allemagne --, je n'aurais jamais cru, si on peut lui donner mon URL, puisqu'elle doit manifestement savoir lire le Français, que l'on n'hésite surtout pas !), mais parce que ce sont des personnes extrêmement agréables et Elizabete De Freitas (TI serait-il un avant-goût du paradis ? Des femmes aussi sympathiques que belles...) ne met pas longtemps, alors que je lui explique un projet, pour m'offrir une beagle board ! (que j'ai failli me faire dérober à la station Tour Eiffel, mais après avoir piqué une gueulante monumentale sur les pickpockets, ils ont bizarrement fini par retrouver mon objet) Autant dire que ce geste me touche beaucoup, et à présent, je cherche du temps pour m'impliquer dans le support de la bête, le problème principal étant pour le moment de chercher comment en sortir une console (c'est très bête, mais brancher un video proj sur la sortie S-Video me semble un peu compliqué pour bosser, et monter un RS232 va nécessiter un passage en magasin d'électronique et une séance de soudage : autant dire que ça attendra après les fêtes, puisque je serai... en Allemagne).

J'arrête ici mon compte-rendu par anticipation de bonne résolution pour l'année prochaine : faire plus synthétique. Et puis surtout, parce que je suis en vacances dès demain. Enfin, parce que je n'ai pas encore reçu les slides (par mail, nous a-t-on dit, attention, ça veut dire "courrier" en anglais -- en ricain, ça aurait donné "snail mail", désambigüisé --, on se laisse toujours avoir...  :)   ), de fait il est plus difficile de tout se rappeler (et comme l'année dernière je m'étais ruiné la santé à prendre un maximum de notes, alors que j'avais ensuite reçu le CD complet...). Bref, je vous souhaite de bonnes fêtes, plein de beagle boards sous le sapin (non, je ne suis pas sponsorisé, juste un peu corrompu -- et puis la concurrence n'est pas facile à débusquer, alors même qu'on m'en a parlé), et j'espère bien me rendre à l'AETC 2010 l'an prochain !

mercredi, décembre 16 2009

Python et OpenOffice.org

Je me rends compte avec effroi que j'ai oublié d'écrire ce billet promis à un ami : c'est qu'il a rencontré des soucis de création de fichiers Excel dans une application Python devant faire du reporting. Problématique déjà rencontrée au sein de l'équipe embarqué, la solution a consisté en l'utilisation de PyUno, le binding Python-OpenOffice.org (et ça tombe bien, puisqu'on propose aussi des migrations sur la suite bureautique libre). La bonne nouvelle, c'est que l'on peut trouver des exemples et autres documentations très complètes (je ne vais donc pas m'amuser à tout reprendre) ; la mauvaise est qu'il faut savoir deux ou trois choses pour que ça marche dans la vie réelle (ou alors l'information importante est un peu perdue).

En premier lieu, il faut veiller à ce que votre environnement soit correct. D'une part, bien vérifier que la version de PyUno correspond à la bonne version de Python et de OOo que vous utilisez (sous Linux, les distributions assurent l'homogénéité, mais il en va autrement sous windows). Ensuite, mettre en place les bonnes variables d'environnement (évidemment, si PYTHONPATH est déjà défini, on concatène avec des ":" sous Linux, mais des ";" sous Windows qui ne fait jamais rien comme les autres -- il faut assumer son péché originel de "C:\" et les ambigüité consécutives). Sous Linux, cela se résume à :

export PYTHONPATH=:/usr/lib/ooo3/basis3.0/program/

Sous Windows en revanche, il faut définir (vous savez, en passant par le panneau de conf, "Système", onglet "Avancé", bouton "Variables d'environnement" -- mais puisqu'on vous dit que c'est simple et intuitif !) PYTHONPATH  à "C:\Program Files\OpenOffice.org 3\Basis\Program" et URE_BOOTSTRAP à "file:///C:/program%20File/OpenOffice.org%203/program/fundamental.ini" (bug documenté).

On peut à présent dans son code python faire un magnifique :

import uno

Et ça marche (rappel : on peut try-catcher des import sous Python, histoire de faire des messages d'erreur sexy au cas où l'environnement ne serait pas d'équerre, par exemple).

Arrive la subtilité de fonctionnement : PyUno s'adresse à un OOo en train de tourner via socket à travers une API, il n'utilise pas l'API de OOo directement ! Il faut donc avoir un serveur OOo qui tourne. Pour cela, il existe deux méthodes : avec ou sans l'option "-invisible" (notons aussi "-headless" qui fait la même chose mais sans avoir besoin de display -- explications par là --, et "-nologo" pour un lancement sans logo à l'affichage). Avec, nous obtenons un démon, c'est-à-dire que OOo est lancé sans fenêtre visible. Si on l'omet, une fenêtre "standard" (en apparence) s'ouvre. On pourrait penser qu'il suffit alors de lancer le serveur au démarrage de la machine, et de l'adresser ensuite. En fait c'est une erreur (attention, le passage qui suit ne convient pas aux âmes sensibles et aux enfants) : si l'on ouvre une fenêtre OOo alors que l'option "invisible" était invoqué, puis qu'on la ferme, le serveur disparaît aussi ; et de même, si l'on ferme la fenêtre-serveur (sans l'option "invisible"), le serveur aussi se ferme. C'est très, très stupide et contre-intuitif (de mémoire, j'ai eu le même problème avec "-headless"). Résultat des courses : mieux vaut lancer le serveur OOo à la volée, quand on en a besoin (au pire, si le serveur tourne déjà, c'est automatiquement détecté, aucun risque de doublon). Pour cela, rien ne vaut une fonction Python à appeler plus tard.

    def ooo_start(self):
        """ start OOo in server mode """
        if os.name == "nt":
                prog = 'start "" "C:\Program Files\OpenOffice.org 3\program\soffice.exe" -invisible -accept="socket,host=localhost,port=2002;urp;"'
        else:
                prog = 'soffice -invisible -accept="socket,host=localhost,port=2002;urp;"'
        if os.system(prog) == 0:
                self.wait_time(5)
                return True
        else:
                return False

Comme on peut le constater, cette procédure gère à la fois Windows et le reste du monde (en l'occurrence Linux, c'est bien connu). La partie optionnelle "accept=..." définit l'état de serveur par socket et l'hôte et le port. La commande Python "os.system" utilise "system" de la libC pour lancer l'application, et si cela réussit, on attend 5 secondes le temps que ça se lance (oui, gruik, je sais, mais ça marche et il n'y a pas trop le choix, puisque ça rend la main alors que ce n'est pas encore opérationnel). Il ne reste alors plus qu'à mettre en oeuvre :

        if not self.ooo_start():
                return
        local = uno.getComponentContext()
        resolver = local.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", local)
        context = resolver.resolve("uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext")
        desktop = context.ServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop", context)

Comme on peut le constater, la succession de commandes est ésotérique, mais la bonne nouvelle est qu'il ne s'agit pas forcément de comprendre ce que l'on fait. À ce niveau, on est connecté à notre serveur PyUno, et l'idée va être maintenant de créer un document que l'on va manipuler. Par exemple, le document /home/gblanc/Documents/example.xls :

       document = desktop.loadComponentFromURL("file:///home/gblanc/Documents/example.xls" ,"_blank", 0, ())

L'idée pourrait être, pour un rapport, de copier un fichier-template à l'aide de "shutil.copyfile" et d'ouvrir la copie. Je rappelle aussi les fonctionnalités portables de manipulation de fichiers que l'on trouve dans "os.path" (qu'il s'agit d'importer auparavant) : os.path.join, os.path.basename, os.path.realpath, etc. On a vu au dessus que l'URL du document à ouvrir a été retravaillée : en effet, "file://" a été ajouté ; quiconque a déjà navigué en local avec Firefox se dit qu'il a déjà vu ce genre de syntaxe. Et que sous Windows, ça va devenir plus complexe : il va en effet falloir ajouter un "/" devant, remplacer les espaces par des "%20" (comme sous le ouèbe avant l'invention des IRL), et changer les "\" en "/" (toujours pareil, assumer les conneries des développeurs sous-doués de Microsoft des années 80). Ce qui donne au final, en prenant notre hypothèse que "fineName" contient un chemin standard de fichier (tel que retourné par une boîte de dialogue Qt, au hasard) :

        if os.name == "nt":
                fileName = "/" + os.path.realpath(fileName).replace(" ", "%20").replace('\\', '/')
        else:
                fileName = os.path.realpath(fileName)
        document = desktop.loadComponentFromURL("file://" + fileName, "_blank", 0, ())

Notre variable "document" est donc à présent notre document de travail sur lequel on va pouvoir agir (remarque : notre fileName se terminant par ".xls", ".ods" ou assimilé, c'est Calc qui est lancé automatiquement par OOo). À ce niveau-là, je ne saurais que trop recommander d'entrer les commandes précédentes sur un iPython, et d'utiliser la tabulation pour constater à quel point l'API est aussi riche que labyrinthique, et qu'un outil d'autocomplétion et de documentation (souvent absente) peut nous être utile. L'API est calquée en réalité (m'a-t-on affirmé) sur celle des macros. D'un autre côté, ai-je une tête à faire des macros sous OOo ?? (en revanche, nous avons ça à Linagora, mais ce n'est pas moi qui m'en occuperait, n'est-ce pas ?). Bref, quelques fonctions utiles :

        document.Sheets.getByIndex(0).getCellByPosition(0, 0).setString("du texte")
        document.Sheets.getByIndex(0).getCellByPosition(0, 1).setValue(42)

Trois remarques : d'abord dans une feuille Excel (ou ods), se déplacer plutôt par "Sheets.getByIndex" plutôt qu'en appelant le raccourci du nom de l'onglet, histoire de pouvoir s'en sortir le jour où un gus renommera l'onglet du modèle. Ensuite, "getCellByPosition" se déplace selon le même système de coordonnées que sur une matrice. Enfin, il faut différencier "setString" qui ajoute du texte (qui peut être un chiffre) de "setValue" qui ajoute un nombre à la cellule : pour faire des calculs, par exemple, c'est "setValue" qu'il faut utiliser, sinon le résultat est juste catastrophique (et lorsqu'on n'est pas au courant, pour débuguer, on reste un peu bête).

Comme on peut s'en apercevoir lorsqu'on entre beaucoup de valeurs (plus d'une centaine, disons), c'est franchement super-lent comme traitements. Rassurez-vous : toute usine à gaz aura les mêmes problèmes, inutile de pester. On peut rendre en revanche la chose plus intéractive pour l'utilisateur, qui devant son écran et au lieu de se tourner les pouces (ou jouer au démineur) pourra voir les jolies valeurs être entrées auto-magiquement, ce qui est toujours ulta-sex et donne l'impression au client d'avoir payer une appli qui poutre. Pour cela, il existe dans notre document une sous-classe "controller" qui va permettre d'en prendre le contrôle (on l'aura deviné) :

        controller = document.getCurrentController()
        controller.setActiveSheet(document.Sheets.getByIndex(1))

Et paf que ça change l'onglet de la feuille Excel (ou Ods, etc, bref Calc) dans notre OOo Calc ! C'est juste beau.

Il s'agit à présent que toutes les données ont été entrées de sauver le document (sinon, il est perdu, ce serait bête) :

        document.store()

On peut aussi faire un :

       document.dispose()

Mais cela ferme la fenêtre et le serveur, ce qui peut être regrettable lorsqu'il s'agit de vérifier qu'un rapport a été bien rempli comme il convient (cf notre problématique initiale).

Voilà c'est tout (ouf !). Aucun plantage n'a jamais été signalé ni constaté, et aucune mouette n'a été blessé (ni mordu par un serpent). Vous avez économisé une licence de l'affreux concurrent Microsoft Office (qui dispose d'un binding Python crassouillet sous windows ; et d'une méthode par ActiveX sinon, il me semble, mais c'est gore, n'est-ce pas ?), vous avez un code portable, sans passer par cette horreur de Perl et son API Excel (qui a le mérite d'exister, mais le problème intrinsèque de Perl, c'est que ça existe tout court), et grâce à ce tutoriel, c'est d'une simplicité relative (sinon, contactez notre zélé commercial Cédric Ravalec, il se fera une joie de vous proposer de l'AT dans la demi-heure). C'est beau.

mercredi, décembre 2 2009

le code qui fait mal aux yeux du jour

J'en reste sur le postérieur : il n'y a pas de fonction sleep en Javascript (gare à celui qui me demande ce que je fiche avec un truc pareil !). En cherchant sur le net, on trouve des solutions de callback scabreuse, et une vieille méthode, qui comment dire, bref...

function sleep(time){
     var start = date.getTime();
     while(start+time > date.getTime()) true;
     return;
}

J'espère que vous ne venez pas de manger. Ça ferait presque penser aux vieux temps du nop en asm pour occuper le CPU. On est en 2009, un langage de programmation ne propose pas de moyen de faire une pause autre que d'occuper 100% des ressources du CPU en attente active ; après demande aux webeux linagoriens, incrédule, confirmation a été donnée. Tout à coup, une citation de Linus Torvalds m'est revenue :

Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.

J'en pense de même pour les créateurs du Javascript...

vendredi, novembre 20 2009

Linux is evolution, not intelligent design

Les manchots, viennent de découvrir les scientifiques, ont un cycle d'évolution beaucoup plus rapide que ce que l'on pensait (via Phersu).

D'un autre côté, parmi les geeks, on le savait déjà.

(la citation en titre est de Linus Torvalds)

jeudi, novembre 12 2009

conférence Paris8, deuxième

Pile poil un an après ma conférence à Paris 8, me revoilà au même lieu, toujours sous le regard d'Isis Truck, et celui d'une assemblée assez nombreuse et hétéroclite. Début de conférence retardé pour cause de câble manquant (ma faute, c'était dans mon sac, en plus...) et de projo à aller chercher à l'autre bout de St-Denis l'université, j'aurai tout de même bien parlé deux bonnes heures, ce qui me fait penser que je devrais peut-être songer à une version "light" -- pas gagné. Voici en tout cas les slides de la conférence Paris 8 2009 remis à jour (c'est-à-dire sans coquille).

Encore une fois, je remercie l'équipe de Paris 8 pour m'avoir si sympathiquement accueilli.

lundi, octobre 26 2009

decreasing the size of the distribution [OpenBSD]

Voilà qu'aujourd'hui, sur la ML d'OpenBSD, quelqu'un cherche à faire baisser la taille d'OpenBSD tout en gardant les fonctionnalités (réseaux) dont il a besoin. C'est trivial sous Linux, mais avec le poisson qui pique, c'est une autre affaire. Comme toujours sur cette mailing list, le pauvre se fait gentiment éconduire ; florilège :

I'd suggest spending the additional ~$2 for the 1GB flash and not to mess with anything!

Lastly if you do build a little shrip frankensystem, asking for help here isn't going to get a lotof sympathy.  You'll be on your own.

If you have to ask, you shouldn't be doing it.  Why would you possibly  need to get smaller than the baseXX, etcXX and manXX sets?  These easily  fit on a few hundered MB.  What modern flash disk won't fit this?

Ah ces barbus, ils sont formidables, et toujours au fait de ce qui se passe dans la vraie vie de tous les jours. Soit le monde de l'embarqué, où il n'est guère décent de proposer une distribution de 512Mo qui embarque les pages man autant que le fabuleux répertoire /usr/share/misc/, qui pour 7,2Mo propose la liste complète des aéroports dans le monde (fichier airports), ou les codes postaux aux États-Unis (zipcodes) ; bon, je suis méchant, il faut garder à tout prix terminfo.db (3,0Mo), mais on peut bazarder termcap.db (2,7Mo).

Il existe deux projets qui se proposent cependant de passer outre la religion inflexible du "touche à rien" (un autre concept de la geek-attitude) : flashdist et soekris (il y eut aussi flashboot). Mais voilà : basées sur des scripts qui copient les fichiers nécessaires à la nouvelle distribution réduite depuis le système de fichier de la distribution courante vers un répertoire donné (avant de l'intégrer dans un master), leur méthode est clairement de type top-down. Pour du bottom-up, c'est-à-dire de la compilation des sources pour obtenir le firmware (ou le master, à savoir le firmware plus le bootloader et d'autres partoches qui servent à stocker par exemple de gros fichiers, ce qui en soit justifie de réduire la taille de la distrib' -- qui pèse plus de 250Mo quand on ne met que le package "base", celui qui contient tellement peu de choses réellement utiles qu'on est rapidement embêté), j'ai bien peur que ce soit une autre paire de manches.

5.2 - Why do I need to compile the system from source?
Actually, you very possibly do not.
Some reasons why NOT to build from source:
     * Compiling your own system as a way of upgrading it is not supported.
     * You will NOT get better system performance by compiling your own system.
     * Changing compiler options is more likely to break your system than to improve it.

Et c'est sans compter le système de mise à jour assez rudimentaire (euphémisme) du firmware proposé par nos deux solutions :

You now need to take the image file and write it to your compact flash device using dd. Make sure you are using the correct device otherwise you can blow away your hard-disk or other devices.
 dd if=image_cf of=/dev/??? bs=1k

(pour faire bref : tu démontes ton serveur, tu enlèves la compact flash, tu la branches dans ton adaptateur universel, et après tu ne te trompes surtout pas de device où copier comme un gros cochon, sinon tu risques de flinguer des trucs pas bons, style ton disque dur -- c'est super industriel comme procédé, je me vois bien proposer ça à un client)

Oh, il y a des recettes pour faire ça dans son garage, mais pour des applications industrielles, ça reste assez vague. "Homemade Embedded BSD Systems" et "Embedded OpenBSD" sont dans le genre de bonnes intros, mais on est loin du compte.

Ou alors, il y a Linagora. Et en plus, vous ne serez même pas mal accueilli (et on s'étonne que je n'aie jamais laissé de messages sur cette ML...). Et en plus, le firmware peut être mis à jour à chaud, et on peut revenir en arrière en un clin d'oeil. Et en plus... Ah ah, il faut garder des surprises !  :)

- page 2 de 5 -