Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 222

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 224

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/public/lib.urlhandlers.php on line 65

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 247
Embedded weblog - page 3

Embedded weblog

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

vendredi, octobre 23 2009

oui, non, 42

PgAdmin, version windows (oui, je sais, mais le client est roi -- oui, je sais aussi), m'afficha un jour ce message :

Je ne compris point sa portée jusqu'à ce message de windaube 2003 serveur, alors que je faisais un glisser-déplacer depuis le gestionnaire de fichiers vers le bureau :

Voilà un abyme de perplexité dans lequel je fus sans ménagement jeté. Oui, non ? 42 !

(il semblerait qu'il faille interpréter ce message selon : "je veux copier/déplacer" / "je ne veux pas" ; et qu'on ne vienne pas me demander à quoi ça sert !)

mercredi, octobre 21 2009

encart publicitaire

Vos produits éditoriaux en « 24h » et « 4 à 8 jours » seront expédiés en une seule fois entre le 29/10/2009 et le 31/10/2009.

Votre site web a la polio (par exemple, un bouton "ajouter" qui fait un submit sur plusieurs champs dont certains cachés puisque sur des onglet en javascript, de telle sorte que si l'on s'était trompé de champs et que l'on en a rempli plusieurs avant de cliquer sur le bouton, il ne se passe rien de bon, tout en restant silencieux), et vous avez besoin d'aide pour sa refonte ? On peut vous aider...

(autrement, il y a des prestataires, parfois, qui ne méritent pas de s'approcher à moins de 200 mètres d'un ordinateur)

jeudi, octobre 15 2009

conférence April/Eyrolles : le debrief

La conférence April/Eyrolles de samedi dernier a finalement été bien remplie en un temps record (on peut l'avouer, maintenant : il n'y avait aucun inscrit le samedi précédent !), grâce à une politique d'annonce active -- notamment sur Toolinux, merci au patron. Entre quarante et cinquante personnes, à la louche (je n'ai pas eu de stat' officielle), un bon tiers d'amphi rempli en tout cas. Il paraît que c'était très bien, avec une durée de deux heures au lieu d'une annoncée -- non, les compliments n'étaient pas obligatoires pour accéder à la buvette. Ravi aussi de la présence d'un ancien chef de projet, et de personnes qui avaient déjà assisté à ma conf' Parinux très similaire, ou même à mon cours complet à l'INSIA : au moins, on sait qu'on est apprécié, pour se faire ainsi des redif'.

Comme promis, voici donc conférence April/Eyrolles, mises à jour pour éliminer les deux ou trois coquilles trouvées. Jean-Luc Ancey de Parinux a aussi capté l'ensemble de la conférence, à l'exception des cinq premières minutes -- mais c'est bien connu, ce qui compte, ce sont les cinq dernières. Problème, je ne sais pour l'instant pas où l'uploader, je mettrai à jour ce billet dès qu'une solution convenable sera trouvée.

Pour finir, si je suis désolé pour la démonstration abandonnée (faute de câble RS232 femelle-femelle : après une bataille de trois heures à en trouver un, pas de bol, il ne marchait pas...), même si de toute façon on aurait manqué de temps (il fallait rendre l'amphi), vous pourrez vous référer aux deux billets de présentation du matos et de portage de Linux sur ce blog. Vous avez aussi le droit de lire le reste, après tout -- notamment les comptes-rendus de RTS 09 et des assises franco-allemandes de l'embarqué, puisque j'y ai fait allusion.

Je remercie évidemment la librairie Eyrolles et l'April pour l'organisation (même si c'était bénévole, faudrait pas que ça devienne une habitude, le libre n'est pas gratuit !  :)  ), notamment Eva Mathieu de l'April qui a même été imprimer des flyers de bibliographie, avec une page web de CR sur le site de l'asso.


PS: après écoute rapide du fichier de J-L, je tiens à m'excuser :
   * de bouffer des mots de temps en temps (mais je me soigne)
   * de dire "bein" et "bah" trop souvent
   * auprès des Indiens et des développeurs Java    (en fait, non)

mercredi, septembre 23 2009

conférence Eyrolles à venir

      Oyez oyez,

samedi 10 octobre 2009 aura lieu à 15h une conférence de votre serviteur sur le thème "Linux Embarqué", pour le compte de l'APRIL, sur hébergement d'Eyrolles. L'annonce complète se trouve sur l'APRIL. Attention, une erreur s'est glissée : c'est bien à l'ENSTP, qui prête son grand amphi, juste au dessus de la librairie Eyrolles de St-Germain (métro Maubert-Mutualité) qu'il faudra se rendre.

Réservation : conferences@eyrolles.com, tél. 01 44 41 11 31, ou à la librairie.

Évidemment, c'est galère, ce qui expliquerait peut-être qu'il y a aussi peu de personnes qui se sont déjà ainsi dénoncées (ou peut-être que cette remarque ne concernait que le premier de volet de conf' du 3 octobre, en concurrence avec l'OpenSource machin de la cité des sciences, ce qui n'est pas bien heureux). Mais essayez de le faire tout de même. Du moins, si vous souhaitez m'entendre.


update: attention, l'adresse d'inscription est "conference@eyrolles.com", sans "s" à "conference", et il vraiment, vraiment important de s'y inscrire, quitte à préciser que l'on n'est pas à 100% sûr de venir.

jeudi, septembre 17 2009

le code de la soirée

_colorline = ['#%02x%02x%02x' % (25+((r+10)%11)*23,5+((g+1)%11)*20,25+((b+4)%11)*23) for r in range(11) for g in range(11) for b in range(11) ]

(c'est dans OpenERP)

(et c'est du Python)

jeudi, septembre 3 2009

beach birds

Ce qui me connaissent bien savent à quel point j'aime la danse (pas danser, juste regarder -- et les danseuses aussi, mais c'est un autre sujet). Je vous indique donc qu'à l'opéra de Lyon, du 15 au 20 septembre, sera repris "Beach birds" du regretté Merce Cunningham (entre un Lemon et un Brown sur du Laurie Anderson -- pour avoir vu "O zlozony/O composite", je recommande fortement a priori), pour des tarifs allant de 10 à 30€ (moins cher que ça, tu meurs). Un extrait youtubesque (l'alpha et l'oméga de la balletomanie, de nos jours), et pour les flemmards (ou les incultes), vous comprendrez mieux le sens de cette annonce avec cette publicité que je viens de recevoir, et dont je me fais l'écho :

mardi, septembre 1 2009

le serpent et le troll

Comme je le dis toujours à mes étudiants, dans ce métier, de nos jours, il faut savoir tout faire, depuis l'assembleur (mécanique les mains dans le cambouis) jusqu'à l'Ajax (et la cuisine brille !). Voilà comment un ingénieur en informatique embarquée se retrouve à faire de l'IHM pour son backend (qui, je vous rassure chers lecteurs, est de type pilotage de matériel, il ne faut pas pousser non plus).

Une Interface Homme Machine, GUI en anglais, le nom fait peur ; de nos jours, on a plutôt tendance à faire dans le web service, à force de planter des projets de "progiciels" (déjà, quand on s'amuser à changer les noms, c'est qu'il y a du louche). Mais ce qui est demandé par le client, c'est du clickodrôme simple, efficace, qui propose d'exécuter différentes actions. Mon idée : Python + QT. Le résultat : impressionnant. Et en plus (surtout, pour le projet qui m'intéressait) : extrêmement portable (Linux/Windows/Mac/BSD/p'têtre même Solaris, c'est dire).

Prérequis : savoir coder en Python (ce que je prendrai réellement comme prérequis dans cet article : c'est assez facile à appréhender), et connaître la bibliothèque (notamment graphique, mais pas que) Qt de Trolltech, c'est-à-dire à présent Nokia (ce que l'on va étudier ici). Je vous rassure, avant de commencer ce projet, je ne connaissais ni l'un ni l'autre, mais j'en avais un bon a priori. Avec une autoformation rapide (d'abord en Python) et du développement itératif (on dit "méthode agile" pour faire style, de nos jours, mais je préfère toujours les histoires de bazar contre les cathédrales, même en développant seul -- avec mes multiples personnalités, certes, mais elles ne sont pas rémunérées --, ce qui ma foi réussi toujours -- on nomme ceci la "méthode à Gilles"), on y arrive très bien (ce que l'on dit toujours après avoir galéré deux heures à chercher une feature toute bête dans son esprit, et qui finalement marche du feu de dieu) ; merci le Qt Assistant (l'aide complète que l'on peut trouver dans le Qt Designer ou sur le net) et le Python reference manual ; et les (trop) nombreux sites web d'(entre-)aide (bonne chance pour trouver, cependant).

Commencez par installer Python, Qt, et le binding PyQt qui va bien avec vos versions Python/Qt (toute bonne distrib' Linux possède des paquets homogènes, sous windows ce n'est pas bien complexe, pour les autres débrouillez-vous vous l'avez cherché). Juste une précision sur les licences : Python est interpréteur de langage script, il n'y a donc aucun impact ; Qt est passé en LGPL sur ses dernières versions (>=4.5), cela n'a donc pas d'incidence sur votre code (seulement sur les éventuelles modifications que vous apportez à la bibliothèque même) ; en revanche, le binding est sous GPL, ce qui implique donc que votre code le sera aussi. La société privée qui développe le code (et il faut bien qu'ils mangent) propose en revanche une licence commerciale ; le business model est donc similaire à celui de Trolltech (peu) avant son rachat par Nokia (qui se moque à présent de faire de l'argent avec : ils voulaient surtout récupérer leurs technos pour faire... de l'embarqué bien sûr !).

On commence simplement : ouvrir le Qt Designer (Qt Creator maintenant, on n'arrête pas le progrès), et demander de créer une nouvelle fenêtre principale. Hop, la voilà qui s'affiche, on peut à présent la décorer de multiples boutons, label, menus, groupes, et j'en passe, le tout par simple glisser déplacer ; une fenêtre permet aussi de changer les propriétés des éléments graphiques, y compris la fenêtre elle-même (l'aide peut se trouver dans l'assistant). On enregistre : ça crée un fichier en ".ui" (user interface devine-t-on), qui n'est autre que du XML. Il va falloir passer ce fichier à la moulinette pour produire du code non pas C++ mais Python : pour cela, pyuic4 est à disposition (on suppose le fichier en ".ui" enregistré dans le répertoire "ui/").

pyuic4 -o ui_projwindow.py ui/projwindow.ui

Le fichier généré comporte alors une classe du nom de la fenêtre que vous avez créé (propriété Name renseignée dans le designer), par exemple "Ui_ProjWindow" ; celle-ci comporte deux fonctions, "setupUi" qui crée la fenêtre (chaque élément, bouton, label, etc, est créé et ajouté à la fenêtre, et ses propriétés initialisées), et "retranslateUi", qui appelée par la première fonction met en place les textes dans la langue que vous avez choisi. D'ailleurs, ce qui est chouette, avec Qt, c'est la localisation, et c'est ainsi que vous n'avez pas à vous soucier de remplacer "yes" par "oui" dans les boîtes de dialogue : il suffit simplement de connaître les bonnes incantations magiques (voir plus bas).

Nous avons donc une classe fenêtre, il va falloir l'appeler pour qu'elle s'affiche. La tradition agit en deux temps : d'une part une petite instanciation générale dans un fichier ".pyw" (l'extension est mal reconnu sous Linux, mais très bien sous windows ; donnez lui le droit de s'exécuter sous Linux, et appelez-le directement), et d'autre part le code massif de l'application en elle-même. Soit "proj.pyw" la première, et projwindow.py la seconde.

Disséquons proj.pyw :

#!/usr/bin/env python
# -*- coding: iso8859-1 -*-

# on importe de quoi créer une application graphique
from PyQt4.QtGui import QApplication
# on importe un minimum de la bilbiotheque (ce qui est dans QtCore n'est pas graphique)
from PyQt4.QtCore import Qt, QLocale, QTranslator, QLibraryInfo, QString
# on importe la classe qui va gerer l'application graphique
from projwindow import ProjWindow

# on entre ici des l'execution de ce fichier
if __name__ == "__main__":

# creation de l'application
    app = QApplication(sys.argv)

# incantations pour traduire la fenetre Qt dans la bonne langue
    locale = QLocale.system().name()
    translator = QTranslator ()
    translator.load(QString("qt_") + locale,
            QLibraryInfo.location(QLibraryInfo.TranslationsPath))
    app.installTranslator(translator)

# creation de l'interface graphique complete
    window = ProjWindow()
# affichage d'icelle (bloquant)
    window.show()
# en attente de fermeture
    sys.exit(app.exec_())

Jusqu'ici, rien de sorcier. On peut s'amuser à créer un hook (un crochet, quoi) qui affiche les exceptions Python dans une boîte de dialogue simple. Pour cela, après la création de l'application, insérer la ligne "sys.excepthook = excepthook", et définir au dessus de notre code la fonction "excepthook" :

import sys, os, traceback, time
from PyQt4.QtGui import QDialog, QLabel, QVBoxLayout

def excepthook(except_type, except_val, tbck):
    """ crochet python pour gerer les exceptions """
# on recupere la pile d'execution
    tb = traceback.format_exception(except_type, except_val, tbck)
# on cree une boite de dialogue avec un bouton de fermeture
    diag = QDialog(None, Qt.CustomizeWindowHint | Qt.WindowCloseButtonHint)
# defintion du titre
    diag.window().setWindowTitle("Une exception est survenue")
# la trace est une liste, on la concatene avec "join" et on la met dans un label
    lab = QLabel(''.join(tb))
# le label gere les retours a la ligne automatiques (evite d'avoir une boite qui fait la largeur de l'ecran)
    lab.setWordWrap(True)
# on donne la possibilite de selectionner le texte affiche avec la souris
    lab.setTextInteractionFlags(Qt.TextSelectableByMouse)
# on cree une boite verticale
    layout = QVBoxLayout()
# on ajoute le widget label cree au dessus au layout
    layout.addWidget(lab)
# on defini le layout par le precedent
    diag.setLayout(layout)
# on affiche la boite de dialogue
    diag.exec_()

On voit déjà avec cet exemple comment on crée "manuellement" une boîte de dialogue simple (sans bouton, juste un label) et comment on l'affiche. Plusieurs concepts apparaissent déjà : codé en C++, Qt est très hiérarchisé, et tout élément graphique hérite de la classe "QWidget". Les widget sont organisés selon des "layout", soit horizontaux soit verticaux, qui peuvent s'imbriquer. Voir à ce propos cette page très complète (en C++ forcément, mais vous êtes au moins bilingue). On remarque que le "exec()" de C++ est devenu "exec_()" en Python, tout simplement pour éviter une fâcheuse ambigüité, il faut ainsi prendre garde à ce genre d'exceptions très rares au niveau du binding. D'ailleurs il faut bien se rendre compte du travail de lien entre C++ et Python, qui peut ne pas être exempt de bugs (une mauvaise utilisation de la bibliothèque, au lieu de remonter une exception, peut très bien faire segfaulter l'application -- cela reste assez rare). Enfin, il faut remercier ce projet de gestion complète de graphes (un vrai bonheur d'inspiration) pour m'avoir donné l'idée de la fonction ci-dessus (qui s'avèrera je suis sûr fort pratique en cas de bug chez le client -- sait-on jamais, ma divinité est grecque et limitée -- pour nous remonter l'information) : je vous invite à aller admirer ce que l'on peut faire dans le genre hyper-poussé en PyQt !

Mais revenons-en à la création de notre interface en elle-même. Dans le fichier projwindow.py, placé dans le même répertoire, on va trouver la définition de la classe ProjWindow, qui hérite l'interface graphique "visible" créée dans le designer, et à laquelle va être "hooké" des fonctions diverses et variées.

# -*- coding: iso8859-1 -*-

import os, sys
from PyQt4.QtCore import pyqtSignature, QString, Qt, QVariant, QRect, QRectF, QThread, QEvent, QSize, SIGNAL, SLOT
from PyQt4.QtGui import *

from ui_projwindow import Ui_ProjWindow

class ProjWindow(QMainWindow, Ui_ProjWindow):
    def __init__(self, parent = None):
    QMainWindow.__init__(self, parent)
    self.setupUi(self)

Comme on voit, l'initialisation de la classe "ProjWindow", qui hérite de "Ui_ProjWindow" va appeler "setupUi", initialisant les graphismes. Mais cela après avoir appelé l'initialisation de QMainWindow, en faisant dès lors la fenêtre principale du projet (car on peut aussi créer les boîtes de dialogue ou les fenêtres filles avec le designer). On remarque au passage que l'application est codée en iso8859-1, ce qui permet de mettre des accents (faire attention lors de l'enregistrement du fichier) ; je ne l'ai pas mis en utf8 pour cause de problèmes avec l'affichage de texte dans widget purement graphiques (j'y reviendrai), mais on note que le générateur Qt-Python crée les fichiers en utf8, permettant donc l'inclusion de tous les caractères de la création. Il faut à présent compléter la fonction d'init de tout ce que l'on souhaite pour l'initialisation de notre application graphique (création de variables locales à l'objet, calculs divers, ouverture de fichiers, etc), et surtout : des crochets pour l'interactivité.

En Qt, l'intéractivité se gère via les signaux. On peut trouver de la bonne littérature sur le sujet, mais il faut déjà veiller à réadapter la syntaxe pour Python. Prenons quelques exemples.

    self.connect(self.menuSave, SIGNAL("triggered()"), self.menu_save)

On connecte ainsi le "signal" nommé "triggered()" de "menuSave" (un item de menu) à la fonction "menu_save(self)" (qui reste à définir plus bas dans la classe). Je rappelle que "self." indique que l'on se réfère à des procédures ou des variables de l'objet lui-même (équivalent de "this" en C++ ou Java, à ceci près qu'en Python c'est obligatoire de préciser). "triggered()" correspond à un clic sur un menu. On peut trouver "clicked()" sur un bouton, "toggled(bool)" pour une boîte de sélection à cocher (indique que l'on vient de cliquer sur l'un des éléments de la boîte), tout comme il y a "valueChanged(int)" sur un slider ou une boîte numérique (la fonction hookée devra alors prendre en argument un entier, qui prendra la valeur de l'objet graphique), ou encore "currentIndexChanged(QString)" pour une boîte de sélection, à différencier de "currentIndexChanged(int)" (le premier renvoie la chaîne de caractère de ce qui a été sélectionné, le second le numéro de l'index ; le traitement est donc différent dans la fonction appelée, sachant cependant que l'on peut ensuite récupérer ses informations en questionnant les propriétés de l'objet).

On peut aussi s'amuser à "automatiser" le traitement de signal, par exemple le fait de changer la combo box "combo_texts" change le texte du label "label_textcombo".

    self.label_textcombo = QLabel(self)
    self.combo_texts = QComboBox(self)
    self.combo_texts.addItem("toto")
    self.combo_texts.addItem("tata")
    self.combo_texts.addItem("titi")
    self.connect(self.combo_texts, SIGNAL("valueChanged(QString)"), self.label_textcombo.setText)

Pour ne pas se casser la tête, et parce que coder fait mal aux doigts (après il faut traiter l'arthrite, ça fait cher pour la SECU), Qt Designer dispose d'une petite fenêtre sympathique "Signal/Slot Editor" (il y a plusieurs autres onglets : "Action Editor" qui permet de gérer les menus, notamment d'ajouter des raccourcis clavier ; et "resource browser", qui doit servir à gérer les fichiers de langue, par exemple, à vue de nez), qui permet de choisir un élément graphique d'émission, un signal (comme on a vu), un autre élément graphique cette fois de réception, et un slot associé (c'est-à-dire une fonction interne comme "setValue(int)", "setText(QString)", etc) ; tout sera généré ensuite automatiquement en Python.

Évidemment, à toute règle ses exceptions : gérer le surlignement à la souris (passage de la souris par dessus un widget, par exemple un label) se fait via une surcharge de fonction :

        self.my_label.enterEvent = self.my_labelEnter

    def my_labelEnter(self, event):

De même lorsque la souris quitte notre label, ou lorsqu'on clique dessus :
        self.my_label.mousePressEvent = self.my_labelSelect
        self.my_label.leaveEvent = self.my_labelLeave

Idem pour la roulette de la souris, par dessus un QGraphicsView (cf plus bas) pour zoomer, par exemple :

       self.mygraph.wheelEvent = self.wheelZoomGraph

    def wheelZoomGraph(self, event):

Pour les événements de redimensionnement de la fenêtre et de fermeture, il suffit donc de surcharger les fonctions :

    def closeEvent(self, event):

    def resizeEvent(self, event):

Noter que l'on peut annuler un événement :

        event.ignore()

Vous en savez à présent assez pour écrire les doigts dans le nez (pardon, sur le clavier) un classique "hello world", et donc recoder avec un peu plus de temps l'ensemble des applications KDE. Il suffit juste de connaître quelques autres trucs et astuces (liste évidemment non exhaustive).

Création d'une boîte de dialogue simple :

    QMessageBox.critical(self, "Erreur !", "Une action a tout cassé.")

La boîte s'affiche toute seule, et attend que l'on clique sur "OK". D'autres boîtes prédéfinies existent, parfois avec plusieurs boutons :

    ret = QMessageBox.question(self, "Question existentielle", "Suis-je buggué ?",
                       QMessageBox.Yes | QMessageBox.No, QMessageBox.Yes)
    if ret == QMessageBox.No:
        return False

Pour ajouter des boutons personnalisés à une boîte de dialogue standard (on peut aussi ajouter des boutons prédéfinis tel QMessageBox.Abort) :

    msgBox = QMessageBox(QMessageBox.Critical, "Erreur !", "Une action a tout cassé.", QMessageBox.Ok, self)
    quitButton = msgBox.addButton("Quitter urgemment", QMessageBox.ActionRole)
    ret = msgBox.exec_()
    if msgBox.clickedButton() == quitButton:
        sys.exit()

Pour ajouter une option à notre boîte (on s'arrêtera là, on peut tout personnaliser, ça risque de faire long) :

    ch = QCheckBox("Redemander inlassablement", None)
    ch.setCheckState(Qt.Checked)
    msgbox = QMessageBox(QMessageBox.Question, "un tas d'étapes", "Voulez-vous passez à l'étape #2 ?",
                   QMessageBox.Yes | QMessageBox.No, self)
# notez ici l'utilisation du layout pour ajouter le widget
    msgbox.layout().addWidget(ch, 1, 1)
    ret = msgbox.exec_()
    if ret == QMessageBox.No:
        return
    # faire des trucs
    if ch.checkState() == Qt.Checked:
        msgbox.setText("Voulez-vous passer à l'étape #3 ?")
        ret = msgbox.exec_()
        if ret == QMessageBox.No:
            return
    #etc

Il existe aussi des boîtes de dialogue prédéfinies pour diverses actions (que l'on devinera aisément) :

    dirname = QFileDialog.getExistingDirectory(self, "Sélectionner un répertoire", default_path)

    file = QFileDialog.getOpenFileName(self, "Ouvrir un fichier", default_path, "Text (*.txt *.odt)")

    file = QFileDialog.getSaveFileName(self, "Enregistrer", "monbidule", "*.txt")
    if not file:
        return
    if not file.endsWith(".txt"):
        file += ".txt"

Autre fonctionalité sympathique et un peu cachée, l'affichage de texte dans la bande du bas de la fenêtre principale ("status bar") ; ici, durant 4 secondes (optionnel, mais penser alors à effacer manuellement en définissant un texte valant "") :

    self.statusBar().showMessage("la vie est belle", 4000)

Pour afficher/masquer et rendre disponible/indisponible un objet graphique, on procède avec :

   # griser
    self.mything1.setEnabled(False)
    # cacher
    self.mything2.setVisible(False)

Pour changer un texte de couleur et de propriété (c'est un peu lourd, mais extrêmement flexible ensuite) :

    self.color_text_black = QPalette()
    self.color_text_black.setColor(QPalette.WindowText, QColor(0, 0, 0))
    self.color_text_green = QPalette()
    self.color_text_green.setColor(QPalette.WindowText, QColor(65, 155, 50))
    self.color_text_red = QPalette()
    self.color_text_red.setColor(QPalette.WindowText, QColor(185, 50, 20))
    self.fontItBold = QFont()
    self.fontItBold.setItalic(True)
    self.fontItBold.setBold(True)
    self.fontDefault = QFont()
    # vert !
    label.setPalette(self.color_text_green)
    # italique
    label.setFont(self.fontItBold)
    # retour au noir
    label.setPalette(self.color_text_black)
    # font normale
    label.setFont(self.fontDefault)

Il reste l'épineuse question des threads à l'intérieur de l'application, notamment pour les traitements lourds : il est toujours pénible de voir la fenêtre se geler durant un temps indéfini. La méthode peut consister en l'affichage d'une boîte de progression, les exemples sur internet ne manquent pas. Pour cela, Qt met à disposition QThread. Voici comment procéder :

    self.mythread = QThread()
    self.mythread.run = self.myaction
    self.mythread.start()

La fonction myaction sera alors appelée dans un thread. Attention : "mythread" doit bien être une variable de l'objet (ici "WindowProj"), et donc initialisée à "None" avant "__init__", sous peine de voir le thread victime du garbage collector dès la sortie de la fonction appelante ! Une fois dans myaction, on peut faire ce que l'on veut (enregistrer un gros fichier par exemple), sauf interagir directement avec les graphismes. C'est-à-dire qu'il n'est pas possible d'afficher directement une boîte de dialogue "enregistrement terminé", par exemple (ou de le mettre dans la status bar, histoire d'être plus poli). Pour ce faire, il faut passer par des événements personnalisés.

    def myaction(self):
# creation d'un evenement personnalise
        event = QEvent(QEvent.User)
        event.event_type = "my_event"
        # faire des choses interessantes
        if success == False:
# on a detecte que ca a foire
            event.event_action = "failure"
        else:
# on est trop doue (penser a demander une augmentation)
            event.event_action = "success"
# on "poste" notre evenement
        qApp.postEvent(self, event)

# cette fonction est une surcharge pour traiter des event persos
    def customEvent(self, event):
# on filtre
        if event.event_type == "my_event"
            if event.event_action == "success":
                self.statusBar().showMessage("enregistrement réussi", 5000)
            elif event.event_action == "failure":
                QMessageBox.warning(self, "Erreur !", "enregistrement echoue, retenter ?", QMessageBox.Yes | QMessageBox.Abort)


Notons qu'avec Python, on peut ajouter n'importe quel champ simplement à customEvent, sans avoir à le faire hériter (attention à ne pas faire ensuite référence à une variable non existente dans le traitement !). Mais disons que dans l'ensemble, c'est un peu lourd, et que l'on a parfois des résultats pas très chrétiens. Personnellement, je préfère, lorsque l'action peut être découpé en petits morceaux (par exemple pour un enregistrement de fichier dans OpenOffice.org, avec le binding PyUno, on a une ou plusieurs boucles), placer à intervale régulier un :

    QApplication.processEvents()

Ce qui va forcer le traitement des événements en attente sur la fenêtre, et notamment la redessiner. On peut ainsi continuer de cliquer, et tout s'exécutera dans les threads "automatiques" de traitement habituels ; attention cependant à ne pas se prendre les pieds dans le tapis (par exemple, modifier les données que l'on est en train d'enregistrer, ou relancer cette commander : bref, il faut penser à verrouiller ce qui doit l'être, sinon gare au crash !).

Python étant un langage objet, on dispose des mêmes possibilités qu'en C++, et notamment on peut redéfinir certaines fonctions. Citons "resizeEvent(self, event)" et "closeEvent(self, event)" qui si elles sont redéfinies dans notre "ProjWindow" vont permettre d'intercepter les événements de redimensionnement et de fermeture de la fenêtre principale (et donc de l'application pour la fermeture), et pourquoi pas de les annuler avec "event.ignore()".

Gérons un peu de graphisme. Le widget qui sert à afficher est QGraphicsView :

    self.mygraph = QGraphicsView(self)

Il s'agit alors de lui ajouter une "scène", dans laquelle on peut dessiner. On peut ainsi définir plusieurs scènes, et les dessiner hors écran, et les interchanger à l'affichage.

    self.scene_img = QGraphicsScene(self)
    img = QPixmap("graphics/img.jpg")
    self.scene_img.clear()
    self.scene_img.addItem(QGraphicsPixmapItem(img))
    self.mygraph.setScene(self.scene_img)

On peut ainsi ouvrir quasiment tous les formats de fichiers d'image de la création, on peut coller du texte formaté en html, et j'en passe (par exemple, on peut récupérer l'image d'un widget non affiché grâce à "QPixmap.grabWidget(my_widget)", ou encore faire une capture d'écran). Le problème principal est de ne pas s'emmêler entre les QPixmap, les QImage, les QGraphicsPixmapItem -- et ce n'est vraiment pas une mince affaire. Une fois que l'on commence à devenir un Jedi, on peut commencer à ajouter du texte, à zoomer avec la roulette, puis à zoomer automatiquement pour ajuster la vue, et jouer avec la matrice pour ajouter des effets de rotation, etc (il y a des fonctions toutes faites, mais pour savoir comment les utiliser, ça doublerait presque la taille de ce billet -- et puis, je ne vais pas non plus tout vous dire, comment on fait tourner la boîte ensuite, hein, je vous le demande ?).

Il ne reste plus qu'à imprimer !

    def export_to_printer(self):
# creation de l'imprimante
        printer = QPrinter(QPrinter.HighResolution)
# on est en A4 et en couleur
        printer.setPageSize(QPrinter.A4)
        printer.setColorMode(QPrinter.Color)
# différents champs
        printer.setCreator("Dieu")
        printer.setDocName("ma belle image")
# gestion de l'export en PDF (chouette non ?)
        printer.setOutputFileName("image.pdf")

# affichage de la boite de dialogue (automatique)
        dialog = QPrintDialog(printer, self)
        ret = dialog.exec_()
        if ret != QDialog.Accepted:
            return

# creation d'un widget de dessin
        painter = QPainter()
# optionnel : l'antialiasing
#        painter.setRenderHint(QPainter.Antialiasing, False)
#        painter.setRenderHint(QPainter.TextAntialiasing, False)
        self.export_to_pages(painter, printer)

    def export_to_pages(self, painter, printer):
        """ export_to_pages: export the scene on painter with a number of pages
        """
# calcul du nombre de page : arrondi superieur de la hauteur de la scene sur celle du papier A4
        w = printer.pageRect().width()
        h = printer.pageRect().height()
        numPage = int(round(self.scene_img.height() / h))
# on initialise la zone dans laquelle tout ce qui passera par "render" sera sorti sur le QPrinter
        painter.begin(printer)
# boucle d'impression
        for page in range(0, numPage):
# capture de la partie A4 de la scene qui va bien, pour l'envoyer sur papier (avec la meme taille)
            self.scene_img.render(painter, QRectF(0, 0, w, h), QRectF(0, h * page, w, h))
# si l'on cherche a rajouter du texte supplementaire, comme un titre
#           painter.drawText(20, 16, "toto")
# demande de nouvelle page
           if page < numPage - 1:
               printer.newPage()
# fin du rendering
        painter.end()

Voilà c'est tout. On remarque que j'ai sous-traité le "rendering" dans une sous-fonction "export_to_pages" : il s'agit en fait de factoriser l'export en PDF. En effet, en Qt, on peut générer aussi facilement du PDF que ce que l'on imprime. Pour ce faire :

    def export_to_pdf(self):
# boite de dialogue habituelle
        file = QFileDialog.getSaveFileName(self, "Exporter en PDF", "mon_pdf", "*.pdf")
# le printer et le painter
        pdfPrinter = QPrinter()
        pdfPainter = QPainter()
# on veut sortir en PDF !
        pdfPrinter.setOutputFormat(QPrinter.PdfFormat)
# si l'on veut changer la taille du papier manuellement
#        pdfPrinter.setPaperSize(QSize(420, 420), QPrinter.Point)
# mais nous on veut du A4
        pdfPrinter.setPaperSize(QPrinter.A4)
# pour rogner les marges (pas très joli, et l'imprimante risque de vous en vouloir)
#        pdfPrinter.setFullPage(True)
# diverses proprietes (consultable dans votre lecteur PDF favori)
        pdfPrinter.setCreator("Dieu")
        pdfPrinter.setDocName("mon joli PDF")
# definition du nom de fichier de sortie
        if not file.endsWith(".pdf"):
        file += ".pdf"
        pdfPrinter.setOutputFileName(file)
# et l'export tout pareil qu'avant
        self.export_to_pages(pdfPainter, pdfPrinter)

Simple et efficace -- quand on sait comment manier la bête, mais maintenant, vous savez. D'ailleurs, il ne me reste plus grand chose d'important à vous apprendre, chers lecteurs. Allez, peut-être, en bonus : faire un logo de démarrage.

# le texte (a readapter, merci)
splashcopyr='''<font color="black"><b>My Appli v0.2beta<br></b>
Copyright (C) Linagora<br>
Conçu par LINAGORA (Gilles Blanc, gblanc@linagora.com)</font>
'''

def makeSplashLogo():
    """Make a splash screen logo."""
    border = 16
# la taille de l'image a l'ecran, attention au ratio
    xw, yw = 473, 427

# ouverture de "./graphics/logo.png"
    pix = QPixmap(os.path.realpath(os.path.dirname(__file__)) + "/" + 'graphics/logo.png')
# on dessine l'image
    p = QPainter(pix)

# creation d'un document texte
    doc = QTextDocument()
    doc.setPageSize(QSizeF(pix.width(), pix.height()))
    f = qApp.font()
# on ecrit en petit
    f.setPointSize(8)
    doc.setDefaultFont(f)
# on ecrit centre
    doc.setDefaultTextOption(QTextOption(Qt.AlignCenter))
# et paf, on interprete du html en deux coups de cuillere a pot !
    doc.setHtml(splashcopyr)
# translation en bas de l'ecran du texte
    p.translate(0, pix.height() - 80)
# on dessine le texte
    doc.drawContents(p)
# fin du dessin
    p.end()
    return pix

if __name__ == "__main__":

    app = QApplication(sys.argv)
    sys.excepthook = excepthook

# creation du splash screen
    splash = QSplashScreen(makeSplashLogo())
# on affiche le splash screen
    splash.show()
    app.processEvents()

    from tdsdgwindow import TdsDgWindow
#etc (ou retour a la case depart)

Ceci dit, c'est vraiment du cosmétique : les applications Python-Qt s'affichent très vite ! Grosso modo, avec un total de plus de 3000 lignes Python, dont près de 900 générés pour la création du graphisme de la fenêtre, mon application (enfin, la plus grosse) met moins de trois secondes pour s'afficher ! (et bouffer au passage 35Mo de mémoire, environ) En revanche, pour une exécution qui nécessite une recompilation en bytecode du Python (création des fichiers ".pyc" associés aux différents ".py"), il faut deux fois plus de temps. Ce qui normalement, lorsque l'on fait une livraison, n'arrive qu'une seule fois tout au plus.

J'allais oublier un problème épineux (j'avais bien dit pourtant au début que j'y reviendrai, souvenez-vous...) : l'encoding -- on a un nom en French pour ça ? Heu... --, l'encodage de caractères. De nos temps modernes, l'usage de l'utf8 est devenu très courant (tout ça parce qu'il y a des types sur Terre qui ne parlent pas anglais, j'vous jure... Bref). Or, on l'a vu, le fichier projwindow.py est en ascii tout simplement parce que sinon, il se passe des drames dans l'affichage de texte sur les QGraphicsView (vous savez les caractères étranges). Du coup, pour insérer une date en français avec accent (à tester en août, ni en juillet ni en septembre), il faut :

painter.drawText(42, 42, time.strftime("%A %d %B %Y, %H:%M").decode('utf-8')

Pour insérer à présent un texte dans une scène avec "addText", en allant le récupérer depuis un texte de QLabel, on transforme la QString en objet Python "unicode" (ie une "str" en utf-8) :

    caption = unicode(my_label.text())
    text = self.scene_img.addText(caption)
    text.setPos(42, 42)

Voilà, je crois avoir fait le tour de ce qui est le plus important à connaître (je vous ai passé "comment faire un zoom sur une zone graphique avec la roulette", ne m'en veuillez pas, il faut que je garde un peu de savoir-faire sinon je risque le chômage).

Une fois que vous serez passé maître jedi, vous pourrez alors recoder elasticnodes.py, du répertoire "examples/graphicsview" dans les sources du binding, totalement impressionnant. Mais il faudra peut-être lutter un peu, et parcourir un long chemin (petit scarabée), alors sait-on jamais que vous ayez un DIF de côté, contactez-moi donc, je suis sûr que l'on pourra s'arranger...  ;)



Best of webographique :
* sur le site de Python, les bindings de GUI et PyQt en particulier
* des slides de présentation
* intro par la création d'une appli
* intro par l'exemple
* un tuto très complet et très bien fait

mercredi, août 19 2009

2ème Assises franco-allemandes de l'Embarqué 2009

Plus de deux mois sans bloguer, et pourtant, chers lecteurs, je vous devais un long commentaire depuis un bon bout de temps. C'est qu'entre les projets qui font courir, et les vacances pour compenser (que la nature est bien faite !), on ne voit guère le temps passer. L'exercice de ce compte-rendu détaillé et commenté va donc se faire avec mes notes plus qu'avec des souvenirs très précis, je m'excuse de fait par avance pour les erreurs qui pourraient s'y glisser, et invite à les signaler en commentaires. Voyageons donc quelque peu dans le temps : mardi 9 juin 2009, 10h du matin ; et dans l'espace : ministère de l'économie, de l'industrie et de l'emploi, centre Mendes France, tout au bout des bâtiments de Bercy. Un site web, un temps trop court pour s'inscrire -- pas très grave, "Linagora", annoncé-je pour la création du badge, et alors que j'épèle par réflexe, "c'est bon, Zapolsky, on connaît !" (ça fait plaisir).

Les assises franco-allemandes de l'Embarqué fêtaient là leur second anniversaire ; l'événement est jeune, il a pour but de renforcer les liens industriels et commerciaux afférant au monde de l'Embarqué entre les deux pays leaders en Europe -- et fort bien placés dans le monde. L'Allemagne est le pays des plus au point sur ce secteur, il n'y a qu'à arpenter des salons ou consulter les chiffres pour s'en apercevoir ; héritage d'une tradition industrielle, et d'une culture de la recherche et du développement certainement. La France en réalité est moins au point, mais dispose d'une industrie militaro-industrielle génératrice de "dynamisme" -- même s'il est artificiel, puisqu'essentiellement soumis au bon vouloir du ministère de la Défense, qui passe commande et "investit", pour aller vite, les retombées se faisant sentir jusque dans les branches civiles ensuite. Il faut cependant bien arrêter le sujet principal : il s'agit avant toute chose de parler informatique, ce qui en l'occurrence intéresse au plus haut point Linagora (ce n'est pas comme si l'on était entre hardeux). D'ailleurs, les deux partenaires de chaque côté du Rhin sont d'un côté le Syntec informatique, et de l'autre BITKOM, qui pour ceux qui ne connaîtraient pas est l'Association Allemande pour les Technologies de l'Information, des Télécommunications et des Nouveaux Media, représentant plus de 1300 entreprises en Allemagne, dont 950 membres génèrent un CA de 135 milliards d'Euros.

Les participants sont accueillis par le p'tit dej' habituel (tellement que j'ai pris le mien chez moi, zut, j'aurais dû y penser, voilà une occasion de moins de rentabiliser mes impôts), et l'amphithéâtre consacré est très agréable (désolé, j'ai oublié de prendre des photos). Je retrouve un ami (qui est celui-là même qui m'a appris l'existence de l'événement) en la personne de Patrick Foubet (qui tient sa propre boutique), par ailleurs collègue professeur à l'INSIA (et voisin dans le civil, c'est dire l'accumulation des coïncidences, puisqu'il enseigne Linux Temps Réel, et moi Linux Embarqué). Nous commençons par une allocution, non pas par Luc Châtel, qui était encore à cette époque le secrétaire d'État chargé de l'Industrie et de la Consommation, auprès de la ministre de l'Economie, de l'Industrie et de l'Emploi, en plus d'être porte-parole du Gouvernement (mais pas de l'Industrie cette fois), mais par l'un de ses hauts-fonctionnaires de cabinet, le conseiller technique Michaël Reynier. Las, n'est pas politique qui veut, le discours est poussif (et plutôt creux), et l'on manque à plusieurs reprises de sombrer. Heureusement, ça ne dure pas bien longtemps, et Eric Bantegnie prend la parole à 10h30 (le planning est respecté à la minute près toute la journée, saluons la précision !), pour nous exposer la "feuille de route franco-allemande pour le développement des Logiciels & Systèmes Embarqués".

Le Président du Comité Embarqué de Syntec informatique (je note le poste pour une future carrière ; il est PDG d'Esterel, tout de même, ce n'est pas gagné) est un bon orateur, et nous présente le CG2E, club de donneurs d'ordres, regroupant le pôle de compétitivité System@tic, l'Aerospace Valley, Minalogic, ainsi que Image et réseaux clusters. Il nous parle de CTB, qui mis à part son homo-acronynimie malheureuse, signifie "Common Technical Baseline" (for embedded systems), et qui à travers son site web nous fait connaître l'avancée des travaux entre grands pontes (Français, Allemands et Néerlandais très essentiellement) pour se mettre d'accord sur un langage commun de spécifications de leurs besoins. Comme un petit peu à chaque fois, le site est moche (sans compter les redirections internes vers soi-même mais avec une racine d'url différente, comme on aura pu constater avec le lien précédent), plutôt vide, et finalement, il reprend juste ce qui existe déjà -- c'est-à-dire la mode des empilements de briques, avec ou sans flèches, qui sont souvent plus une vue de l'esprit qu'un reflet exact de la réalité, noterons-nous narquoisement. Mais il faut saluer l'effort (c'est nouveau dans le métier, qui a su conserver un esprit "maison" de réinvention de roue perpétuelle remarquable).

Son alter-ego germanique Knut Degen, présent du Comité Embarqué de BITKOM, nous parle un peu en français (et surtout en anglais, de mémoire), sur un autre genre plus avenant. Il lance à 10h50 la présentation et restitution des travaux du CG2E, "Club des Grandes Entreprises de l'Embarqué", par Dominique Potier (secrétaire général) et Jean-Claude Derrien. La CG2E comporte actuellement 25 à 30 entreprises, nous apprend-il, des petites, des PMEs et des grandes entreprises (surtout, à mon avis, avec en plus les moyennes débrouillardes habituelles que l'on retrouve un peu partout), et reste ouverte à l'adhésion de nouveaux membres. Son président (temporaire -- peut-être ne l'est-il déjà plus ?) est Dominique Vernay. Concernant l'administration et les finances, c'est le club des partenaires de la FIEEC qui s'en charge. Sont cités aussi parmi les importants Claude Lepape de Schneider pour Minalogic et Gérard Lardier d'Airbus pour l'Aerospace Valley.

Il existe différents groupes de travail : les normes et standards (J-C Derrien de SAFRAN et Eliane Fourgeau de Geensys), la productivité/qualité et le dimensionnement des enjeux économiques ; plus tard on évoquera la SG2 pour la sûreté de fonctionnement. Pour qui se rappelle du salon ARM, nous sommes dans le vent, les préoccupations sont habituelles. Notons que le libre dans l'embarqué s'inscrit exactement dans ce genre de questionnements : l'ouverture des standards (un point sur lequel j'insiste toujours en cours, qui pourtant n'a jamais eu à chercher partout un chargeur pour sa version de téléphone portable ? Ça en est d'ailleurs enfin fini de ce temps, le micro-USB est devenu la norme auto-imposée), la réduction du Time to Market, ou la qualité et la pérennité du code. D'ailleurs, pour qui se remémore les sujets abordés de manière assez récurrente au dernier salon RTS, la sécurité de fonctionnement dans le libre est un point épineux auquel on pense de plus en plus à s'attaquer. Sur tous ces sujets, Linagora a clairement une carte à jouer, par sa connaissance du monde du libre qui l'avantage (ouf, je n'y suis pas allé pour rien :)  ).

À 11h20, Knut Degen, président du comité embarqué de BITKOM, présente une restitution de l'étude BITKOM sur le marché allemand de l'embarqué. Autant dire que ce genre de prise de température de fort bonne qualité est toujours très appréciable. L'industrie embarquée en Allemagne représente un chiffre d'affaire de 19 milliards d'Euros, répartis selon 15 milliards pour les industriels, et 3,7 milliards pour les éditeurs. Si le hardware est environ deux fois plus important que le software, la prestation de service représente sur le camembert de répartition 44% de cette masse financière ! Les télécoms y sont bien plus importants que l'automobile, largement devant la défense (pour d'évidentes raisons) ; ceci est très différent de la France, précise-t-on. On note que l'automobile est tout de même au final le plus important, car en bout de chaîne (c'est de là que partent les commandes). 70% du CA est interne, 17% de l'UE. L'étude s'est aussi intéressée aux problématiques actuelles qui occupent les industriels : la réduction du TTM est bien devant la qualité, suivie des standards et de la complexité, assez devant la sécurité, plus loin l'OpenSource, et enfin en bout la chute des prix. Les secteurs de croissance attendus sont essentiellement le médical (très en vogue, nous le verrons d'ailleurs plus tard), la communication, les machines (spécialité très germanique) et l'électronique de transports (hors l'automobile, apparemment).

On remarque qu'il y a malheureusement peu d'Allemands cette année dans la salle -- l'année dernière, bien du monde avait les écouteurs de traduction sur les oreilles, me confirme mon voisin. On espère qu'il y aura en revanche des français à Francfort (c'était en juillet, apparemment, des nouvelles ?). Et l'on attire l'attention sur l'Embedded World à Nuremberg -- qui est il me semble le plus grand salon mondial du genre. À 11h40, séance de questions, on apprend que l'adhésion à la CG2E coute 1000€ par an, soit une somme assez faible dans l'absolu mais suffisante pour faire un tri à l'entrée, et qui donne toujours à mon avis assez de budget pour payer le stagiaire qui a conçu le site web, puisqu'en terme de fonctionnement l'association ne doit pas avoir grande dépense à faire. On se plaint que pour le médical, le marché est clos et l'on manque d'interlocuteurs : c'est tout à fait vrai. Le SYNTEC permet une comparaison avec nos voisins outre-Rhin en dévoilant qu'il y a deux fois plus de prestations dans notre pays, et que les éditeurs (hors électronique) génèrent un CA de 4 millions d'Euros. La crise va avoir comme impact de réduire une croissance de 12% à 5%, mais les chiffres sont avoués (ou désavoués) comme étant peu précis. On note cependant une inertie du marché de l'embarqué (bien propre au milieu industriel) : c'est mal parce que les adaptations rapides sont difficiles, c'est bien parce que ça empêche de tomber dans les affres de l'économie mondiale. L'Allemagne continue ainsi de vouloir embaucher massivement, ils leur manqueraient 200 à 250 mille ingénieurs !

Justement, à 11h50 est prévue une conférence sur les filières de formation aux métiers de l'Embarqué : "Adéquation entre les besoins en compétences en informatique embarquée et l'offre de formation ?", se demande-t-on. C'est Jean-François Lécole, PDG fondateur de Katalyse qui présente l'étude, menée conjointement avec Merlane pour le compte de l'OPIIEC (Observatoire paritaire des métiers de l'Ingénierie, de l'Informatique, des Etudes et du Conseil, on peut trouver les liens vers le rapport sur la page liée du CICF). Des chiffres : 220.000 emplois, répartis pour 65% chez les industriels, 29% chez les prestataires et 6% chez les éditeurs ; un besoin de 34.000 emplois supplémentaire (en solde net, c'est-à-dire corrigé des départs à la retraite) en cinq ans se fait sentir, pour une progression de 46%, et une répartition de 19.300 (en plus de 26.000 remplacements) dans les SSII et 14.600 (en plus des 48.000 remplacements) dans l'industrie ; 85% des profils sont généralistes, à qui l'on demande des capacités d'évolution en compétences techniques, d'adaptations importantes, et de gestion de projet. Aussi, les formations disponibles sont triés selon trois profils : 500 à 700 nouveaux entrants par an ont bénéficié d'une formation dédiée (260 à 420 en bac+5) ; 17.700 par an (dont 7.700 en bac+5) on suivi un cursus généraliste avec "coloration" embarqué ; et enfin 28.000 sortent d'un cursus scientifique bac+5 (comprenant des physiciens de cursus universitaires par exemple).

L'offre de formation est encore très jeune, et il existe un problème de prévision sur 6 ans ! En tant que professeur et ancien élève, je peux confirmer que le maintien d'une spécialisation en informatique embarquée au sein d'une école, surtout au regard des difficultés spécifiques de la filière (professeurs difficiles à trouver et à faire venir, très grandes variétés des matières souvent très/trop techniques donc spécifiques, problématique de la mise en pratique, et pour finir... très peu d'étudiants s'inscrivent spontanément dans cette spécialisation exigeante), est un problème récurrent. Prévoir une formation qui soit assez générique pour préparer à l'acquisition de technologies non encore existantes au début du cursus, tout en maintenant assez de cours techniques poussés afin de permettre une entrée rapide et sans douleur sur le marché du travail n'est pas de tout repos. On constate aussi, reprend notre conférencier, une forte évolution, des liens avec les laboratoires et une mutualisation. L'offre académique reste cependant pauvre, mais il y a peu de demandes aussi ; la formation continue, quant à elle, marche mieux dans les grandes entreprises.

Les besoins sont pourtant pressants : 12.800 travailleurs pour 3.400 non-ingénieurs, et 9.400 ingénieurs. La demande constatée y correspond à peu près : 12.500 pour 3.900 non-ingénieurs et 8.600 ingénieurs. À cela s'ajoutent 29.750 profils "expérimentés", pour arriver à un total de 42.500. La répartition selon nos trois critères précédemment énoncés se fait alors selon : 20% de formation dédiée, 70% de "coloration" et 10% de non-spécifique. L'avantage des ingénieurs se situe dans la gestion de projets, les langues et la meilleure adaptation au monde du travail que les cursus universitaires. On soulève enfin un dernier point, et non  des moindres : le problème d'image pour les étudiants. Il existe aussi un manque de visibilité des formations (y compris pour les DIF, je rappelle au passage que Linagora propose des formations à Linux Embarqué et Linux Temps Réel, ainsi qu'aux sujets afférents) : une page dédiée sur Internet devrait être créée. On remarquera cependant que l'on n'est pas encore sorti de l'auberge : sans aucun suivi par mails à la suite de ces assises, je trouve les slides de cette conférence sur le site gouvernemental de la partie "technologies de l'information et de la télécommunication" du MINEFI, qui arrive à me faire trouver une référence plus longue sous forme de compte-rendu (non relié au site principal de l'événement, mais qui y renvoie tout de même), qui lui-même ne référence apparemment pas les slides précédents. Bref, aucune idée d'où en est la création du site web sur les formations...

La séance des questions/réponse ne s'attarde pas trop, et en fait un certain nombre de personnes veut plutôt parler de manière informelle avec les intervenants. C'est ainsi que je m'entretiens quelque peu de mon expérience de formateur (d'ailleurs, des retours d'expériences concrets manquaient quelque peu à ce niveau, même si l'on n'avait pas le temps -- je vais regarder le rapport complet plus en détail), et je soulève deux points fondamentaux se rejoignant qui n'ont pas été abordés : pourquoi un étudiant choisirait-il une filière embarqué hautement complexe pour être amené à travailler à Vélizy (conditions de travail quasiment toujours dégradées, j'ai tout de même bossé six mois en face d'un mur, la fenêtre la plus proche à 50 mètres non visible, à Thales Colombe) payé au lance-pierre (c'est un fait, les salaires sont inférieurs aux autres spécialisations techniques, et je ne parle même pas à compétences égales), alors qu'il pourrait se caser pépère à la Défense pour faire du Java bidon dans une banque ? Sans parler des perspectives d'évolution de carrière et de la valorisation du travail (on croît que faire des satellites est a priori très valorisant, mais dès lors que l'on se retrouve comme une toute petite pièce d'un très grand rouage, quelle est la satisfaction réelle ?). Certes, la tendance est à l'amélioration du métier (ou à la dégradation des autres ? Pensons notamment à la crise économique qui a affecté les banques, donc nos adeptes de l'IHM Java), mais c'est ici que se situe le problème, et la forte demande en compétences très variées et techniques (on nous demande de savoir aussi bien faire de l'assembleur que de l'interface graphique...) n'aide pourtant pas la hausse des salaires dans le milieu ; ce n'est pas la peine de chercher longtemps ailleurs (le "ailleurs" qui peut être aussi la "pression" du métier : risquer de planter un avion est autre chose que risquer de planter une appli web).

Je m'entretiens aussi un peu avec un représentant de Wind River (il a remarqué que j'étais un peu partout, avec mon chapeau, pratique), qui a lui aussi des problèmes de visibilité sur les formations (au passage, je parle rapidement du rachat de la boîte par Intel, toujours sous l'émotion). Et puis c'est l'heure de partir à la chasse au fromage, ce qui est certes fort bon (surtout si l'on aime, pour les autres il y a du gâteau au chocolat), mais qui ne m'aurait pas semblé forcément très adapté pour les rencontres de visu a priori (admirez ce déploiement d'euphémismes). Le "networking" est en effet prévu dans la pause 12h30-14h00, mais je n'ai pas eu l'impression que les rendez-vous formels, à prendre d'avance sur le site web consacré, ait eu un succès énorme. Pour ce genre d'événements, il faut inciter au brassage, et de ce point de vue-là, l'événement a quelque peu péché. Les deux ou trois stands de partenaires, Sysgo à l'entrée, et de mémoire Geensys et Microsoft, n'accueillaient pas vraiment foule, tandis que leurs animateurs étaient partis directement au contact -- laissant bien souvent le stand vide. J'y reviendrai.

La reprise se fait sur les Trophées de l'Embarqué 2009 (par Jessica France), selon cinq catégories : l'Embarqué critique, l'Embarqué grand public, le capteur embarqué, l'Embarqué communicant et les Technologies de l'Embarqué. On en parle suffisamment dans les comptes-rendus officiels pour passer rapidement dessus, tout en saluant les mérites des gagnants (et des perdants...). À 14h45, il est temps de présenter rapidement le "livre blanc des systèmes embarqués"  (téléchargeable là), par Eric Mittelette, responsable du groupe de travail associé. La plaquette nous dit : "le Comité Embarqué de Syntec informatique, publie un Livre Blanc s'adressant au grand public qui illustre de manière concrète le monde des Systèmes Embarqués". Il a cette formule malheureuse d'entrée : "faire connaître notre jeune industrie", qui me laisse pantois avec mon ami, d'une vingtaine d'années plus âgé que moi, et d'ailleurs on retrouve bien en introduction du livre que l'informatique embarquée aurait moins de 20 ans. Il ne faut pas chercher bien loin pour déclarer que non, l'informatique embarquée est largement plus âgée, et tout dépend de la définition que l'on retient, apparaît même avec l'informatique tout court.

Le document d'une vingtaine de pages est clairement orienté très grand public, et avant un exemple tiré de la vie courante de confrontation à notre type de technologie, Eric Brantegnie fait justement remarquer que "paradoxalement cette industrie est peu connue du grand public, des décideurs économiques et politiques, des étudiants et du monde de l'enseignement". Une raison à cela selon moi : l'inculture technologique ambiante, qui associe à peu près tout ce qui existe à une aura de magie mystique complexe à appréhender. Il y a trois ans et demi, au salon du livre, je demandais à la personne sur le salon si elle savait sur quel système tournait le livre électronique (qui faisait alors son apparition) qu'elle proposait : "mais monsieur", me suis-je vu répondre, "c'est totalement électronique !". Idem à propos des téléphones portables, l'électronique a été assimilée, mais pas encore le fait que des personnes ont pu coder dessus, alors même que c'est là où se situe la véritable valeur ajoutée ! Bref, le livre blanc reste très général -- sans oublier cependant de mentionner les gagnants des trophées 2008, allez savoir --, et n'hésite pas à consacrer de larges pans à la "pollution et émissions de CO2" (page 17), au milieu d'une grosse tranche sur l'automobile, une interview de vrais gens de l'Embarqué dont on précise le nombre d'enfants qu'ils possèdent, et on nous tire même une larme à la page 22 ("tenir compte des considérations éthiques") : "[les logiciels embarqués] participeront ainsi activement au bonheur et à l'équilibre de notre société" ; avant de sauver les vieux (heu, personnes âgées), les logiciels embarqués, c'est avant tout du militaire. Bref, l'intention est bonne mais le résultat me paraît quelque peu bancal (comme on me dira que la critique est facile mais l'art difficile ; je précise donc que je me suis essayé à l'exercice et que j'ai produit un document interne -- orienté Linux, avec une vue d'ensemble du marché sous ce prisme --, que vous pouvez me demander, chers collègues -- pour les autres, envoyez un CV à notre RH, on étudiera votre demande). Peut-être est-ce dû à l'origine pas assez représentative des rédacteurs et intervenants -- mais comme Eric Mittelette est responsable groupe développeurs, division plate-forme d'entreprise Microsoft, j'ai peur que l'on m'accuse ensuite de partialité.  :)

15h00 : première table-ronde, "exemples de projets français, allemands ou franco-allemands dans les domaines du transport automobile et ferroviaire". Un animateur, Sylvain Dorschner, Délégué Général du pôle de compétitivité System@tic ; et différents intervenants, Christian Balle de Renault (directeur adjoint Electronique Avancée, membre du Bureau Exécutif System@tic, qui nous parle du système 4RD de la Laguna, qui est celui-la même qui a été primé peu avant, me semble-t-il -- il s'agit d'avoir 4 roues directionnelles), Louis-Claude Vrignaud ([ancien?] Président d'EICOSE, l'European Institute for Complex Safety Critical Systems Engineering -- voir ici aussi), Jacques Bercot (Valeo, directeur du centre pour l'Excellence Electronique du projet STOP&START -- la voiture s'arrête lorsqu'elle est à l'arrêt, si l'on me pardonne l'expression), et Daniel Cadet (Alstom Transport Technical, Directeur des relations extérieures -- ce qui est assez ironique, car il nous affirme qu'il est très heureux d'avoir échouer à faire parti de consortiums pataugeant dans la semoule à essayer de se mettre d'accord et de travailler ensemble, quand de son côté, Alstom a su faire progresser et réussir les même projets concernés tout seul et sans interférence extérieure). Une question du public porte sur la sécurité des automobiles : un intervenant répond que la certification sur automobile ne sera jamais poussée aussi loin que celle pour les avions ou autres transports en commun, pour une simple raison de coût-bénéfice, sachant que d'une part c'est quasiment toujours le conducteur qui fait la faute (on remarquera que de toute façon, lorsque l'électronique est en cause, le débat est toujours saboté, comme pour les régulateurs accusés ; quand on ne passe pas simplement sous silence les calculateurs de bord qui prennent feu chez Renault -- la faute à Siemens, avais-je entendu dire --, ou que l'on rappelle des milliers de voiture pour les patcher sans donner la raison exacte chez Peugeolt -- là encore, par des contacts, il semblerait qu'à un moment les portières automatisées avaient tendance à s'ouvrir inopportunément), et que d'autre part crasher un avion n'a tout simplement pas le même effet en terme de pertes humaines que planter une voiture ; c'était la minute de cynisme capitaliste (ce n'est pas péjoratif, mais enfin il est de bon ton de rappeler les fondamentaux économiques qui dirigent à l'industrie).

Au bout d'une demi-heure, c'est la pause café/networking (like we say in good French  German eerr), l'occasion de retrouver mon PDG, Alexandre Zapolsky, qui par une pure coïncidence (mais on avait répété la veille) se trouvait dans le ministère. Tandis qu'il va saluer le Syntec et autres très bonnes connaissances, je pars à la chasse aux contacts -- et tombe en premier sur mon ancien directeur d'étude de l'EPITA, avec qui je m'entretiens de la bonne évolution de la filière, surtout depuis qu'elle a absorbé une autre autrefois dédiée à la recherche. J'arrive à m'imisser dans une discussion (ça parlait des jeunes, coup de chance) et me fait un bon contact à la SNCF ; et par hasard, un universitaire de Nancy (je parle de la difficulté à mettre en place des TPs : leur professeur fait un séminaire d'une semaine, et le un jour est entièrement consacré à mettre en place la dizaine de postes, tandis que le TP prend la journée suivante). Du coup, j'arrive un peu en retard pour la seconde table ronde, qui de toute façon m'intéresse moins. D'ailleurs, les départs sont assez nombreux, comme mon ami qui m'a jusqu'ici accompagné (notamment à la chasse au fromage, ce qui est important, pardi).

Cette table-ronde parle de projets dans les domaines de la domotique et du développement durable. La domotique, cela fait tellement de temps que l'on en parle que l'on commencerait presque à en douter plus que fortement. La voilà associée au buzz world du moment, il n'y a plus qu'à ajouter "incitation fiscale", et nous y sommes. C'est Nicolas Leterrier, Délégué Général de Minalogic qui anime, et j'arrive sur la toute fin de la présentation de Jean-Luc Dormoy pour EDF Group Strategic Marketing Comitte, dont il est le Home Technology & Smart Meter European Programme Director (tout un program), à propos du produit "YELLO Sparzähler Compteur intelligent" (sic). Puis c'est Didier Pellegrin de Schneider Electric, qui nous présente le projet HOMES, dont il est le directeur : "HOMES définit de nouvelles architectures pour le contrôle et la distribution de l'énergie dans le bâtiment, pour mettre sur le marché les produits et solutions nécessaires à une meilleure efficacité énergétique et permettre le développement de nouveaux services". Bonne chance. Le responsable du Programme de Recherche M2M d'Orange Labs (Groupe France Telecom) André Bottaro a une mission tout aussi précise : "Senscity : Orange Labs et un réseau de PME collabore au développement d'une offre technologique et d'un business model pour des réseaux de capteurs destinés aux collectivités engagées dans une démarche de développement durable". Et justement, on finit avec Didier Dufournet, dirigeant de la société Azimut Monitoring, pour "les réseaux de capteurs et standardisation des protocoles".

16h30, c'est l'heure du grand témoin, en l'occurrence le Dr James Goldberg : "TIC et Cancérologie: que peut-on attendre de l'embarqué en matière médicale ?". Là, j'avoue que c'était franchement étrange. Nous sommes partis dans des considérations un peu folle (ça a tout de même dévié sur l'assurance maladie aux Etats-Unis -- prévoyez d'être riche si vous souhaitez avoir plusieurs échographies), et je me suis souvent demandé comment on allait retomber sur nos pattes. En tout cas, on était très éloigné d'une synthèse (de toute façon, avec des slides et un discours déjà préparés...), et cela a duré une demi-heure, tout de même. On a cependant eu droit à une liste de désidératas pour rendre la vie meilleure aux médecins et patients, on verra ce que General Electric propose -- car oui, le secteur est cloisonné... (oh, on parlait aussi du dossier médical électronique, ça en revanche ça peut nous intéresser au plus haut point)

Une heure restante avant la fermeture à 18h00, pour un cocktail de clôture, qui à vrai dire n'avait pas une pêche d'enfer, et a encore plus souffert, parmi les restants, du phénomène de grumeaux : ceux qui se connaissent forment des groupes de trois ou quatre personnes, et se tiennent en position fermée. Prendre d'assaut de telles forteresses sociales est d'autant plus difficile que l'on ne sait jamais trop sur qui l'on va tomber -- c'est ainsi que je me suis retrouvé au milieu de discussions dont il faut faire preuve du plus grand génie pour s'en échapper diplomatiquement. Manifestement, c'est là le gros point faible de cette journée : l'interaction entre les participants a été en réalité plutôt faible, en ce que les nouveaux contacts ont été particulièrement difficile (ainsi la pêche aux cartes de visite a été basse, et la distribution idoine). C'est d'autant plus dommage qu'il y avait particulièrement du beau linge, comme on a pu le voir dans les attributions de chacun. C'était généralement des directeurs de petites structures, des délégués généraux d'associations d'entreprises, des directeur de projets, ou encore des directeurs d'étude (on pouvait croiser un bon nombre d'écoles, dont certaines qui m'étaient jusque là inconnues). Bien du monde a fait le voyage depuis la province, moins depuis l'Allemagne -- je n'ai d'ailleurs pu discuter avec aucun Allemand ! Continuer a posteriori sous forme de discussion informelle un sujet avec le conférencier concerné était mission impossible, contrairement à un salon plus classique comme RTS (selon un autre modèle, certes).

L'événement est sans conteste original, mais je me demande toujours pourquoi le grand témoin n'était pas quelqu'un du ministère. On parle crédit impôt recherche, mais surtout emplois et R&D, développement technologiques de très haute importance -- automobile, satellites, télécom, et j'en passe, le militaire n'ayant pas été abordé, bref de ce qui intéresse le gouvernement --, on précise même dans le livre blanc que les décideurs connaissent mal le milieu, mais pourtant, outre que le secrétaire d'État concerné a annulé sa venue, il ne me semble pas que les conseillers de son cabinet étaient présents outre mesure. Peut-être ont-ils a posteriori visionné la vidéo complète de la journée (avec plus de chance que moi, pour qui ça ne marche pas), mais cela laisse une impression étrange. Autre complainte : une formule de speed dating aurait été tellement plus agréable pour parfaire son networking ! (avec une allitération gratuite, en plus) Mais le contenu des conférences étaient dans l'absolu de très bon niveau, l'organisation rigoureuse et le cadre très agréable, c'est donc un bilan positif que je dresse de cette journée -- après tout, il s'agissait avant tout d'assises, soit de dresser une sorte d'état des lieux, comme l'annonçait la dénomination de l'événement --, qui aura eu le mérite d'installer un peu plus Linagora dans sa stratégie de développement du pôle embarqué -- si ce n'est de nous faire simplement connaître sous cet aspect, notamment auprès du Syntec informatique.

vendredi, juin 5 2009

le choc avant le week-end

WindRiver est racheté par Intel ! Je suis allé vérifier ailleurs, ça semble bien vrai... (et l'annonce de dater d'hier)

J'en reste sans voix.

mercredi, mai 27 2009

au détour d'une macro crasseuse

#define ATOI2(ar)       ((ar) += 2, ((ar)[-2] - '0') * 10 + ((ar)[-1] - '0'))

Ça se trouve au milieu de date.c, de l'utilitaire date d'OpenBSD. Ça transforme tout nombre entre 10 et 99 (ou 00 et 99) en chaîne de caractère en integer (ou au moins en char), et ça passe même sur un gcc très récent. Outre l'idée d'avancer de deux dans le pointeur puis de référencer en négatif, et de flinguer au passage la variable d'entrée, autre chose interpelle : la syntaxe.

int i = 42;
int t = (2, i++, 4 + i);
printf("%d ", t);

Ceci affiche 47 !! Page 210 de votre K&R (A7.18), opérateur "," :

f(a, (t=3, t+2), c)
a trois arguements et le deuxième d'entre eux vaut 5.

Toutes les personnes interrogées, développeurs expérimentés en C, ne connaissaient pas ; je me suis senti moins seul...

lundi, mai 18 2009

photos libres

Jusqu'ici, les OS étaient essentiellement maison, ou alors on mettait du ThreadX. Mais il semblerait que les temps changent parmi les constructeurs d'appareils photos numériques. Certes, il existe déjà un projet libre pour Canon, mais il s'agit d'exécuter un code qui ajoute des fonctionalités à l'appareil. Ici, je parle de l'OS constructeur, à base de Linux embarqué : Sony (dont les téléviseurs étaient déjà tous linuxisés depuis quelques années) équipe à présent ses gammes de Linux embarqué, sur les Cybershots par exemple. Et ça, c'est nouveau, impensable il y a encore peu de temps (entre les prix de la flash et de la RAM, forcément très supérieures en quantité que pour du ThreadX, l'investissement, sans compter le coût du portage, ne se justifiait certainement pas), et un nouveau marché pour Linux embarqué qui s'ouvre !

Décidément, où la conquête de Tux s'arrêtera-t-elle ? (à noter que mon titre est forcément abusif et racoleur -- toujours cette histoire de future carrière commerciale -- : le soft qui fait interface et le traitement numérique via DSP sont forcément toujours fermés...)

mercredi, avril 22 2009

Alcatel migre vers Linux

Au début je me suis "certes, what else ?", mais j'ai tout de même cliqué. En fait, c'est d'embarqué qu'il s'agit : les appareils de networking d'Alcatel-Lucent qui migrent de VxWorks vers Linux. Ouais, apparemment, ça tourne sous VxWorks, ça fait un peu peur pour la peine (ils sont sympathiques, chez WindRiver, mais leur pile IP a une réputation qui n'est plus à refaire, dans le milieu...). En VO, ça donne :

"There are great packages that are available on Linux and a lot of new packages we can integrate into our switches if we decide to do so," Nikolova said. "VxWorks is old and doesn't have a lot of movement in it. The packages that VxWorks provides really aren't the latest and greatest. But basically everyone is moving toward Linux."

VxWorks is old, ça m'a fait un peu tiqué : un peu d'histoire, et on trouve bien que l'origine de l'OS remonte à du framework VRTX en 83, recodé de manière indépendante au niveau de son kernel (on touche à l'équivalence de ce qu'est Linux en terme fonctionnel) en 87. Or, Linux, ça date de 1991. Et après tout, on en fait depuis 2000, en embarqué. Et le plus drôle, c'est que les projets viables et utilisés les plus anciens que j'ai pu retrouver datent de cette époque, et c'était du poste téléphonique chez.. Alcatel ! Presque 10 ans, quand même... :)

En tout cas, cette réaction est totu à fait typique du moment fatidique dit du "ça ne va plus, le patchodrôme, il faut migrer" ; je croyais que tout le monde l'avait déjà fait (regardez votre *box ADSL en même temps), apparemment, non, il en reste. Linagora est là pour vous aider, si vous êtes retardataire.  ;)

mercredi, avril 15 2009

no comment

Vista today, post-Service Pack 2, which is now in the marketplace, is the safest, most reliable OS we've ever built. It's also the most secure OS on the planet, including Linux and open source and Apple Leopard. It's the safest and most secure OS on the planet today.

Remarks by Kevin Turner, chief operating officer for Microsoft, about the role of CIOs in a changing economy
MidMarket CIO Summit
Redmond, Wash.
April 6, 2009

mercredi, avril 8 2009

salons RTS et Solutions Linux 09

Les salons Real Time System et Solutions Linux se tenaient en même temps, cette année, porte de Versailles tout deux. J'avais déjà évoqué les bons et très mauvais points de cette connivence de dates et de lieux il y a six mois environ, et comme je le craignais, les seuls avantages que pouvait amener cette situation ont été annihilés par la distance assez élevée entre les bâtiments 8 et 2.2 : combien de fois n'ai-je entendu les uns et les autres avoir hésité entre les deux salons (WindRiver), ou promettre de passer sur l'autre (SFR) sans qu'on les y voie faute de temps, et en tout cas se plaindre de cette situation ? D'une manière générale, peu de société de Linux embarqué ont choisi Solutions Linux plutôt que RTS ; on pourra citer Concurrent Computer, tandis que Sphinx, habituellement présent sur les deux, a préféré RTS. Linagora était évidemment sur Solutions Linux, mais pas sur RTS. Avantage cependant de ces dates simultanées pour Linagora : pouvoir dépêcher sur RTS un commercial/avant-vente dès lors que j'avais repéré une affaire potentielle ; en l'occurrence, Sébastien Bahloul aura fait quelques allers-retours (compter un peu plus de dix minutes de déplacement pour l'opération...). Mais voilà : parfois, le simple temps d'alerter d'un bon, et le temps d'arriver (parfois le lendemain, quand on a repéré quelque chose d'intéressant la veille au soir), les intervenants sur les stands ont changé, et plus que répéter le travail d'approche, il est arrivé plusieurs fois où le bon interlocuteur, le seul qui pouvait faire interface, avait disparu. C'est ainsi qu'une fois une société me dit avoir grandement besoin de services Linux, et le temps de revenir, tout autre son de cloche, très peu de Linux en vue : en fait, les deux personnes adressaient des marchés totalement disjoints.

Cela fait cinq ans que je reviens sur le salon RTS, et six pour Solutions Linux. D'expérience, le premier est bien plus intéressant que le second, en ce qui concerne Linux embarqué, mais il n'est pas impertinent de choisir le second plutôt que le premier dès lors que l'on propose du software, surtout s'il s'agit de temps-réel pouvant avoir vocation à des applications de type serveurs. C'était cependant SL qui ouvrait le bal avec une conférence dès le premier jour (31 mars) au matin sur le sujet : Sébastien Dinot comme modérateur, et des gens connus ou reconnus comme intervenant ; citons donc le traditionnel Christian Charreyre de de CIO informatique (nos concurrents marseillais), et les plus nouveaux David Chabal (toulousain dont j'ai relu l'excellente documentation sur Xenomai, que je n'arrive toujours pas à trouver en diffusion publique, mais je suis dans les remerciements), Lucas Bonnet (monsieur OpenMoko France) et Etienne Juliot (Obeo). Pour un compte-rendu très complet, il suffit d'aller lire l'excellent rapport de Thomas Petazzoni. Il se trouve que j'ai décidé de sécher cette conférence : déjà, parce qu'elle était payante, et qu'il fallait donc magouiller un pass' conférencier sur notre stand (perte de temps, quand tu nous tiens), et ensuite parce que j'ai préféré arpenter RTS sur le peu de temps imparti, qui ne me semblait pas justifier de sacrifier une demi-journée. Je pense avoir eu raison : même si je n'avais pas assisté à la session RMLL 08, j'avais lu les slides, et il se trouve que le Chabal et le Bonnet ont fait de la redif' ; la conf' plus généraliste de CIO m'aurait certainement un peu ennuyé ; et celle d'Obéo a été rediffusée sur le salon RTS, où je n'ai d'ailleurs pas été plus avancé que Thomas (on y reviendra). Il ne m'étonne en tout cas que moyennement que seuls une dizaine de personnes y étaient présentes.

C'est ce que l'on appelle "un beau gâchis". J'avais moi-même pré-postulé il y a bien longtemps pour donner une conférence sur le portage Linux embarqué sur architecture ARM non supportée, mais le temps de confirmer (ie d'avoir réellement porté le bestiaux), les trois autres intervenants étaient retenus. Quatre, c'est bien peu, d'ailleurs. J'avais alors prévu de présenter le même sujet sous un angle différent pour la conf' RTS "les outils open source dans l'embarqué", qui a été annulée silencieusement (mais j'ai appris à la fin du salon que François Gauthier avait regardé les activité de Linagora suite à mon mail, et que c'est ainsi qu'il contacta Benjamin Jean, notre juriste, pour la session "la jungle des licences logicielles"). Je donnerais a priori cette conférence (dont l'université Paris 8 a pu avoir un court extrait) au RMLL 09, à Nantes, finalement. Il se trouve, en tout cas, que j'ai par le plus pur des hasards prédestiné, rencontré Francis Mantes, au sortir du salon RTS avec Sébastien, après être allé rencontré des gens intéressants : allumant sa pipe, j'aperçois son badge, et vais donc immédiatement à sa rencontre. Nous avons discuté un bon moment (il se souvenait par ailleurs du court échange que nous avions eu par mail), et avons déploré la distance des deux salons mis ainsi en concurrence (si Groupe Solutions organisait les deux auparavant, il semble que SL soit passé sous l'égide de Tarsus) : il a été décidé de prévoir une semi-journée Linux l'année prochaine, avec force ateliers et conférences à but technique plus que commercial ; non seulement j'abonde, mais je salue la pré-initiative (en outre, puisque l'on m'a invité à rappeler par mail cet échange, je ne manquerai pas de lier ce compte-rendu, et j'en profite donc pour saluer le travail organisationnel de notre hôte).

Mais revenons-en à nos hardeux. Car le salon RTS c'est avant tout du silicium et de l'époxy, il faut bien l'avouer. Les "softeux" (ça sonne plus mal) sont peu nombreux, on compte les gros WindRiver, GreenHills Software ; il y a Sysgo, mais nul LynuxWorks cette année, et pas de Montavista non plus. Bref, on fournit du BSP (Board Support Package, pour les n00bs), mais pas de service informatique à proprement parler : un seul concurrent -- et de taille, quoique, il faut considérer que l'informatique embarquée représente aussi chez eux une partie seulement de leurs activités --, possédant un stand, côté M2M, à savoir Teamlog. À noter au passage qu'outre RTS, il est de tradition depuis plusieurs années de lier M2M (Machine to Machine, toujours pour les n00bs) et Display (affichages numériques) ; il y a cinq ans, le second connaissait un succès monstre avec force téléviseurs, imprimantes 3D ou autres, mais il doit être concurrencé par un autre événement non identifié, car il n'y a plus que quelques sociétés proposant des affichages digitaux (on reste néanmoins admiratif devant des écrans cristaux liquides d'une qualité impressionnante).

Ma mission a donc consisté à aller démarcher les vendeurs de hard et de BSP, pour nous faire connaître : oui, nous, Linagora, société de services en informatique libre (et éditeur, sur d'autres parties), partant d'un concept généralisé mais experts dans notre partie, à l'originalité indéniable notamment concernant notre interfaçage privilégié avec la communauté (aka "le monde du libre"), et disposant depuis un an et demi d'une équipe aguerrie d'ingénieurs informaticiens rompus aux techniques de l'embarqué, du temps réel, de l'industriel.

Il faut reconnaître un certain succès a priori (a posteriori, on verra si des affaires nous reviennent, il faut attendre un certain temps pour cela) : premier bon point, j'ai l'habitude de ce salon, certains intervenants me connaissent fort bien à force, je suis donc à l'aise ; second bon point, et de taille, la démarche est fort originale, et répond à un besoin déjà identifié par les acteurs. En effet, les vendeurs de matériel électronique (le "hard"), qui peuvent aller de la puce à la carte, du module au PC durci, n'ont que très peu de connaissances logicielles, et lorsque des clients viennent les voir avec une idée de développement logiciel derrière la tête, les fameux "applicatifs métiers", ce n'est pas forcément en ayant déjà à disposition l'expertise technique suffisante. Or, acheter un bien matériel que représente une carte de développement, une carte industrielle, ou un module de communication M2M est une autre paire de manches que dégoter l'ingénieur expert pouvant concevoir le système software qui va faire d'un hardware inanimé monts et merveilles. J'ai assez assuré de prestations chez des grands comptes qui cherchaient une personne qualifiée depuis six mois ou plus pour le savoir. Le positionnement de Linagora est alors simple : vous savez faire le hard, nous savons faire le soft, nous existons, faîtes-le savoir à vos clients !

Aussi, nous n'entrons pas en concurrence frontale avec les autres acteurs comme Sysgo, Montavista ou autres, qui ont déjà des accords pour fournir des BSP ou autres solutions de Linux embarqué/RT "clef en main" : nous construisons au dessus, nous intégrons, nous apportons la plus-value sur mesure, du "bespoke (free) software solution", en somme (la fashion victime qui sommeille en moi va copyrighter cette expression, tiens). À noter aussi que Linagora n'est pas un ayatollah du libre : notre société promeut le libre mais n'y oblige pas ses clients, et si le sujet est sensible dans l'industrie, j'en suis tout aussi conscient ; cependant, nous pouvons concevoir du logiciel propriétaire à la demande par dessus du logiciel libre (notre spécialité se situant ici, ce qui comprend les problématiques de licences), et ce de l'avant-vente jusqu'au support OSSA (Open Source Software Assurance : le service après-vente de luxe par Linagora), tout en vous proposant de reverser les parties de modifications de logiciels libres utiles à la communauté selon votre bon vouloir (mais croyez-moi : mieux vaut participer, gagner en plus l'estime du public averti, et éviter de redévelopper les mêmes patches à chaque fois que l'on veut effectuer une mise-à-jour interne du produit ; bien des coûts cachés sommeillent dans le logiciel libre, il est de notre devoir de proposer de les optimiser pour le bien de tous).

Voilà pour la communication externe, toutes mes excuses aux collaborateurs qui se seraient ennuyés...

La pêche fut très bonne : il est envisageable de rassembler la masse de cartes de visite (sachant qu'il faut parlementer un minimum pour en obtenir une : pas tout le monde n'avait un stock à disposition, loin de là) en un jeu des sept familles, mais il sera plutôt préférable de faire du business avec. Je ne dirais donc pas que le salon était vide, à l'instar de Thomas dans son compte-rendu sus-lié, les allées étant peuplées et les stands quasiment toujours occupés ; de plus, trois ou quatre conférences se tenaient constamment en même temps, avec plus ou moins succès -- mais au moins, elles y sont gratuites. J'ai fait le constat inverse concernant SL dès lors que l'on s'éloignait des stands Linagora-Novell-Canonical (ces derniers exposant, juste en face de nous, leur réussite sur les migrations Assemblée Nationale et Gendarmerie, et ce sans nous citer ! Incroyable mais vrai), comme quoi ça devait dépendre de l'heure. Car finalement, je n'ai passé que peu de temps sur le salon linuxien, en fin de journée ou à la pause déjeuner essentiellement, histoire de voir un peu de monde, de passer sur notre stand, ou de saluer des amis d'associations de libristes. Et puis aussi participer au cheese'n'wine du second jour, le soir -- du moins au début des festivités, un pré-Wagner m'attendait au théâtre du Châtelet.

Puisque je réserve un retour détaillé des différents intervenants très intéressants à recontacter en interne (non, je ne donnerai pas des pistes à la concurrence, il ne faut pas pousser non plus  :)  ), passons donc aux comptes-rendus des différentes conférences. J'ai commencé par une première session de 14h00 à 16h00 consacrée à la certification logicielle : le sujet m'intéresse beaucoup, j'ai justement contacté quelqu'ami chef de centre de Systerel (associé l'année dernière à Sysgo par un stand commun, mais pas cette fois) à ce sujet, car il n'existe aucune formation dans l'absolu. Différents intervenants au programme : Lionel Burgaud de Geensys a parlé d'organisation collaborative, parce que spécifier chacun dans son coin des bouts de code similaires est passablement contre-productif. GreenHills, qui a fait certifier sa solution Integrity EAL6+, après trois ans de torture (les développeurs sont aussi passés à la question) par la NSA, montre effectivement les limites de la procédure (longueurs et retards technologiques) ; Serge Plagnol (ou son collègue Rolland Dudemaine ?) m'avait, peu de temps avant cette présentation, fait un exposé sur son stand de l'attachement de GHS à la sécurité (il a montré une vidéo de turbine piratée à distance poussée à son extrême limite : de quoi attirer l'attention sur les failles de sécurité qui émaillent le code des développeurs de l'industriel) : c'est clairement le positionnement marketting de la société à présent. La vague sécuritaire touche d'ailleurs aussi la solution concurrente (mais à l'architecture différente : virtualisation vs paravirtualisation) de Sysgo, et c'est l'habituel mais toujours intéressant José Almeida (cinq ans que l'on se voit, alors à la pause, on devise ensemble, forcément) qui cette fois ne nous parle plus Linux ou PikeOS, mais DO178B (du niveau E au A, pour l'avionique), Common Criteria avec EAL/MILS (du niveau 1 à 7), IEC61508/ENSO128 (de SIL 0 à 4, par un positionnement parallèle à la DO-178B, mais pour le ferroviaire cette fois), ou encore ECSS (espace), FDA (médical) et que sais-je encore : un vrai fouillis ! Les prédispositions communes sont la fiabilité, la disponibilité et la réutilisation, à mettre en corrélation avec le Time to Market ; d'autres concept sont encore abordés : certification incrémentale, méthode formelle, mélange de niveaux indépendants, utilisation en redondance (pas facile de relire ses notes, d'autant qu'il faut effectuer une traduction à la volée...). On évoque aussi des différences dans les habitudes de codage avec l'apparition d'APIs POSIX/ARINC. Enfin, on parle d'ESA, dont le projet est la convergence de certifications (ECSS, DO178B et CC/EAL5+), en recoupant les similitudes pour gagner du temps.

C'est ensuite à Matteo Bordin, d'AdaCore (tiens, un intervenant que je ne connais pas, uniquement anglophone d'ailleurs), "toward a lean approch of certification", qui parle d'open-do.org. Ce projet recoupe ce qui avait été abordé justement par GHS (mais ils ne se connaissaient pas tous les deux, un comble pour des prôneurs du coopératif !), à savoir la collaboration et la mise en commun pour accélérer les certifications, selon un nouveau moyen hérité des méthodes Agile. On remarque en premier que la certification actuelle se fait d'un seul bloc : on écrit entièrement le code, puis on le fait certifier, on attend quelques années, et voilà. Mais rajouter du code ensuite fait automatiquement sauter la certif', et il faut alors recommencer le cycle depuis le début : dans le cadre d'un logiciel communautaire (au hasard un compilateur pour langage Ada), on comprend que ce soit passablement gênant. L'idée est alors de recouper le libre, l'agile, et la certification High Assurance ; on voit une potentialité dans le militaire, l'espace et le ferroviaire pour une communauté HA, on compare la méthode de certif' DO178 vs Lean/Agile, et on expose enfin le but d'OpenDO : communauté ouverte, partage, base de connaissance, apprentissage méthodologique (education, en anglais dans le texte) et de l'Agile dans les process. Why not ? Comme "bootstrapping" (on reste parmi des techos, on a le droit au détournement d'expression -- quoique) : FP7 en Europe et DARPA aux USA. Bref, ça démarre...

C'est au tour d'Olivier Charrier de WindRiver, sur le sujet de l'avionique modulaire intégré (IMA), partant du concept qu'en avionique comme en automobile, l'augmentation des fonctionnalités s'observe parallèlement à la baisse du nombre de CPUs embarqués, qui deviennent multicoeurs, déjà qu'ils avaient tendance (oh my god tout ça) à avoir de la MMU, du DMA, et on en passe des meilleures qui imposent (attention puristes, ça va vous faire mal) l'utilisation d'un OS. Résultat : des problèmes de synchronisation dans les développement hardware, software, l'intégration des deux, le tout avant certification. On attire l'attention sur le point d'achoppement principal que constituent le debuggage et le testing. Thomas Cenni de MathWorks (éditeur de Matlab, évidemment) parle de tout autre chose : génération de code certifié, instrumentation simulink et le tout sous couvert de Polyspace, racheté il y a plus d'un an à présent (différence entre Polyspace et Coverty : le premier indique quelles sont les zones totalement fiables et certifiables, le second indique les bugs potentiels : chacun prend le problème par un bout, cependant à 45K€ la solution -- sans compter la prise en main que cela implique --, mieux vaut ne pas se tromper d'approche ou être riche !). Enfin, Luc Coyette d'Esterel entretient des problèmes de spécification et de tests, impliquant la détection tardive de bugs, faisant exploser les coûts (jusqu'à devenir intolérablement haut dans certains cas) ; sa solution : SCADE, aliant langage formel, générateur de code certifié, simulateur et vérification de compilation. Il annonce que 8 millions de lignes de codes générés pour 40 modules sont embarqués dans l'A380, au niveau A de la DO-178B ! En séance de questions, quelqu'un demande pourquoi on n'applique pas les même normes draconniennes à l'automobile (extrait du magazine "Electronique" : " 'le standard DO-254 [ndlr: certif' de systèmes un peu plus complexes que pour la 178], quant à lui, est très jeune puisque le document date d'avril 2000', explique Lionel Burgaud (GeenSys)", ça donne une idée du niveau) : réponse, parce que ça coûterait trop cher pour quatre morts de temps à autre, sans que l'on sache trop (et à vrai dire, on ne cherche pas trop à savoir) si c'est le régulateur de vitesse ou la mauvaise conduite qui en est à l'origine ; un avion de 240 personnes qui se crache, c'est une catastrophe qui passe au JT, mais effectivement, il y a bien 50 fois moins de morts par accident d'avion en France que par voiture, c'est juste que le coût par vie est moins rentable tout considéré. On apprécie la franchise.

Seconde conférence : tests et sécurisation en milieu embarqué, le second jour au matin (10h à midi). Le propos était fort semblable, et si l'on y ajoute que le magazine "Electronique", distribué gratuitement (au lieu de 12,20€ les 65 pages pubs nombreuses comprises, sacré pouvoir d'achat chez les hardeux !), consacrant un dossier en couverture de cinq pages sur le sujet (et deux à l'amélioration du temps de boot de Linux, au passage), cela montre l'intérêt porté à la question, d'autant que l'audience comportait encore trente à quarante personnes. Bref, sous l'égide de François Gauthier, de ladite revue électronique (mensuel arrivé au numéro 200, quand même), le premier intervenant est encore de chez GreenHills, le fort connu Serge Plagnol : il nous parle d'hyperviseurs (tendances, techniques et applications), comparant para et full (ainsi que l'hybride) virtualisation (notamment par rapport au portage de drivers, inutile dans le premier), mais aussi de type 1 (à la ESX) vs type 2 (à la VMW workstation) ou hybride, comme  c'est le cas de, KVM mais aussi d'Integrity, qui peut ainsi aussi exécuter des applications. On considère ensuite les différentes architectures : monolythique (ESXi, VLX -- VirtualLogix était d'ailleurs absents, tout comme Trango et OKL4), Dom0 (Xen par exemple, mais le TCB est encore trop gros, on compte plusieurs mégas de code !) et enfin à base de microkernel, comme OKL4 (que l'on connaît assez bien par ici : mon ancien stagiaire a passé six mois sur le sujet) et Integrity, qui présentent un très petit TCB. On parle rapidement de ce que propose l'architecture x86 en terme d'aide à la virtualisation : VT-x (niveaux de privilèges) et VT-d (I/O virtualisés, dont la DMA, plus quelques autres joyeuseries) ; pour l'instant, l'Atom ne propose que du VT-x, mais une évolution prochaine est à attendre ; de son côté, ARM propose TrustZone, une double partition de fiabilité. Si l'on rappelle (page de pub) qu'Integrity est certifié à présent EAL6+, on insiste sur le fait que la virtualisation n'implique pas en soi la sécurité, bien au contraire ! Enfin, les applications de ce type de sécurisation par hyperviseurs seraient la téléphonie, les PC portables d'entreprise, les terminaux de paiement, le jeu avec transaction financière, et tout ce qui implique à la fois une communication (militaire notamment) et la présence simultanée d'une IHM.

Après cette longue présentation, c'est au tour de Jean Philippe Dehaene de présenter AUTOSAR, l'outil de simulation de VECTOR, les spécialistes en solutions logicielles (notamment sur bus de comm' CAN et LIN) pour l'automobile ; c'est intéressant pour qui est du milieu (très particulier, et qui ne va pas forcément bien en ce moment : passons). Didier Vidal d'ISIT expose les mérites de LDRA, l'analyseur statique de code ; c'est que la relecture manuelle de code trouve sa limite à 10 pages par jour, même si elle corrige 80% des bugs fonctionnels. La relecture automatisée, à l'inverse, ne peut pas trouver les erreurs fonctionnelles mais relève 80 des bugs techniques. À l'aide de règles de codage (MISRA-C 2004), de graphes d'appels, d'étude de code, de statistiques, de commentaires automatisés (ça j'aime !), de suivi de variables et d'exports des résultats dans des formats divers et variés dont le web (ça dépasse la simple relecture automatisée !), la société entend nous faire économiser bien de la sueur (contre un gros chèque, certainement). Fait très amusant, dans le contexte : alors que l'on passe rapidement les très nombreux slides, et que le transparent 60/60 concerne la détection de buffer overflow et d'overrun, on continue la présentation jusqu'à la slide 67/60 !

Ben Chelf, CTO de Coverty (et anglophone only, sorry) parle d'une nouvelle solution d'analyse de compilation : ça c'est fort ! Le problème du build est l'effet "boîte noire" (black barrier), peu importe si le compilateur est est libre ou non, à la rigueur, étant donné la complexité actuelle. L'analyse de build construit une carte du système de compilation complet en s'interfaçant entre les outils et l'OS ; un exemple est alors donné en utilisant... OpenOffice.org ! Ça ne s'invente pas, et évidemment, le graphe peut servir à faire peur aux petits enfants le soir. À noter que d'une manière générale, les outils libres sont implantés partout : on s'en sert directement (gcc et eclipse en star, encore plus que Linux) ou indirectement, comme base de proof of concept ; coverty s'est fait une spécialité de découvrir les bugs de logiciels libres pour à la fois se faire de la pub à peu de frais sur une base de code énorme, et tester leur outil en même temps (ce qui me fait penser que je leur ai parlé du bug de ifstated sur bagotage d'interface réseau : arriveront-ils à le trouver ?). Leur logiciel explore les différentes phases de la compilation : le make clean, les macros DEBUG ou RELEASE, les options de sécurité, etc ; fini les peurs bleues d'avoir un fichier objet non regénéré à la suite d'une modification de .h ! (ça peut faire très, très mal, sur du code militaire mal foutu, surtout quand ça fait plusieurs dizaines voire centaines de milliers de lignes -- souvenirs douloureux). Outre l'analyse, un "build management" est proposé.

L'après-midi, je m'étais inscrit à la conférence sur la virtualisation, mais j'avais mal compris : c'était la virtualisation de la machine de développement dans le but d'émuler des plate-formes exotiques pouvant aller jusqu'à l'ARM OMAP ; comme j'avais déjà discuté assez en profondeur à mon goût de ce sujet avec les principaux intervenants, ECSI (attention ! web 0.2), je me suis enfui ; cependant, le sujet est extrêmement intéressant, pour avoir eu l'occasion de développer sur OMAP, justement, et donc de goûter aux 25 minutes de flashage intégral à chaque fois que l'on veut tester la solution (quant au développement par NFS, autant oublier : il n'y a pas d'Ethernet, voyons !) ; je crois donc sans problème le consortium européen (avec notamment une université lettone dans le lot, oui ça étonne) lorsqu'ils affirment pouvoir réduire par deux le TTM (Time to Market, si vous débarquez de Mars). J'ai donc opté pour l'autre conférence simultanée pouvant être intéressante : Agile dans le milieu industriel, encore introduit par François Gauthier qui avoue à la fois intérêt grandissant (ce que semble confirmer le monde présent) et la nouveauté de l'approche dans le milieu. Mauvaise pioche : Philippe Soulard (remplaçant Yves Lebeaupin) de Sodius me fait mal à la tête avec son exposé "Multi-tool & multi-model integration using IBM rules composer" : trop de sigles et concepts abstraits, c'est à se demander si l'on parle bien de méthodes Agile, en tout cas je ne suis pas ; Etienne Juliot d'Obeo (voir au dessus) prend la relève et commence par un remerciement à son prédécesseur d'avoir introduit autant de concept (ouille), avant de nous parler de ses outils de modélisation, avec du temps-réel et de la génération embarqués sous Eclipse (c'est ce que disent mes notes) ; je reste malgré le micro qui rend l'âme (embêtant, ces micros, vraiment) parce que ça parle OpenSource (j'ai appris plus tard que Linagora a un peu travaillé avec Obéo pour le ministère des finances, association qui n'a pu aboutir faute d'avoir obtenu le marché : je confirme que nous n'étions pas mentionné parmi les partenaires), mais au bout d'un moment, je finis par craquer (au bout d'une heure, en fait).

Dernier jour et dernière conférence : "la jungle des licences logicielles". L'intitulé a pas mal évolué, l'apparition de cette conférence le dernier jour (moins peuplé et terminant à 17h30) n'a pas non plus aidé au remplissage de la salle : seulement une dizaine de personnes présentes, ce qui a déçu François Gauthier (décidément, je n'ai pas fait exprès, mais nous partageons les mêmes goûts apparemment). L'année dernière, la salle était comble, et les intervenants clairement techniques et peu juridiques : cette année, tout le contraire, de vrais juristes et avocats, mais des erreurs techniques dans le discours (netfilter, le module Linux de firewall, est ainsi de venu "netfiles", logiciel). Pour l'année prochaine, il serait de bon ton de mêler les deux milieux, et je me propose dores et déjà, tant le sujet me passionne (le juridique d'une manière générale, en fait, et je devise régulièrement avec avocats et professeurs de droit, de surcroît) ; d'ailleurs, j'ai pu parler à la fin de l'affaire Guillermito, fort importante mais inconnus de mes interlocuteurs (pour ma part, j'avais tout simplement pris deux après-midi pour assister au procès et au délibéré). Les deux premiers intervenants sont Cendrine Claviez et Vincent Pollard du cabinet TAJ, mais arrivant en retard (pour cause de prospection), j'ai raté le début de l'intervention de la première, pour arriver au moment de la considération des effets héréditaires/viraux, classant GPL, EUPL, CeCILL A d'un côté, MPL, LGPL, Eclipse et CeCILL C de l'autre, et enfin MIT, BSD, ASF et CeCILLB ensemble. La volonté d'organisation de cette "jungle" est manifeste. On continue sur les résiliations, automatique pour la GPLv2 et l'EUPL, il y a un délai pour la GPLv3 : en cas de constatation de violation, on peut ainsi avoir le droit de continuer d'utiliser le logiciel en attendant la rectification, alors que pour les autres, la sanction est immédiate, avec l'injonction de cesser immédiatement l'utilisation ; pour la peine, la GPLv3 est bien plus favorable à l'industriel distrait ! (évidemment, nous considèrerons la bonne foi a priori de celui-ci) On parle de l'EUPL, versions 1.0 et 1.1, la licence libre européenne pensée pour agir dans la juridiction du licenceur en Europe, et selon le droit belge sinon, et comportant une clause de compatibilité avec la GPLv2, la CeCILL ou encore Eclipse (attention cependant à la GPLv3 ou tout autre licence rédigée après l'EUPL, et de facto non mentionnée : il faut rajouter en annexe). On rappelle que le relicenciement autorisé par la BSD implique de pouvoir rendre le code GPL.

C'est ensuite au tour d'Hervé Guyomard de présenter son outil phare de Black Duck Software, et il nous injective : "Know your code" ! Prenons un exemple : Cisco rachète Linksys pour 500M$, Linksys embarque dans son WRT54G du code de Broadcom, que lui a fourni son sous-traitant Cybertran ; pas de bol, c'est bourré de GPL, et la FSF intente un procès à Cisco. L'histoire va plus loin encore : le WRT54G à 60$ voit son code libéré pour respecter la licence, code qui se voit grandement amélioré par la communauté, et réembarquable dans le même appareil, concurrençant dès lors des solutions professionnelles de Cisco valant... 600$ ! Cette histoire bien connue des milieux libristes de l'embarqué illustre le propos de notre intervenant : avec 1400 licences OpenSource recensées (évidemment, la plupart sont des adaptations de licences bien connues : il suffit de rajouter des annexes ou de modifier des paragraphes -- on recense par exemple une GPL interdisant les usages militaires : il faut noter que cette licence n'est alors plus considérée comme libre, quoique toujours OpenSource), il n'est pas inhabituel de se prendre les pieds dans le tapis, et d'embarquer sans le savoir du code soumis à des termes de licences non pris en compte, et pouvant avoir de fâcheuses conséquences. Protex est une moulinette sur-évoluée de code basée sur une base de données et de métadonnées complète, pouvant dès lors détecter à l'aide de génération de fingerprint (inutile de ne changer que le nom des variables et des procédures : ce sera détecté) les composants OpenSource lors d'un audit de code ; l'outil sait même reconnaître les conflits de licences. Dans l'industrie mobile, Intel, Samsung, Siemens, Motorola, Nec, RIM, LG, Qualcomm, Palm, Cisco, Xerox, Sega ou encore NTT ont fait appel à leur service : c'est dire si le problème est largement pris au sérieux ! Hervé Guyomard affirme par ailleurs que toutes ces entreprises intègrent d'une manière ou d'une autre des produits OpenSource dans leurs appareils.

Le dernier intervenant est bien connu à Linagora, puisqu'il s'agissait de Benjamin Jean, notre juriste. Pris dans le marasme des transports (RER D ?), il est arrivé bien en retard et a totalement raté les premières interventions : sans filet et sans slides, il essaie de faire original en pointant les sujets les plus importants : droits et obligations, extension de la licence (jusqu'où la licence couvre-t-elle ?), l'élément déclencheur aussi (souvent, il s'agit de l'utilisation, donc de l'exécution, mais il peut s'agir du simple téléchargement !). Il indique qu'un groupe de réflexion est actuellement monté au sein du SYNTEC informatique. Et qu'il a donné une conférence complète dont les slides peuvent être trouvées sur le net (sauf que je n'ai rapidement pas trouvé, il faut mettre son blog à jour, Ben ! ;)  ). Il en oublie de citer le groupe dédié aux problèmes de licences libres qu'il anime, Veni Vidi Libri, on sent la fatigue après trois conférences sur le sujet en trois jours ! On passe à la séance de question, qui tournent toujours autour des mêmes points, le plus crucial étant : où commence et où s'arrête ce qui est couvert par la licence ? (dans le public, un représentant de Vector présente son activité : c'est surprenant de voir ça sur le salon RTS ! On a totalement changé de monde) C'est que le problème est pernicieux, sur des systèmes embarqués dont la limite avec le userland est parfois assez floue (WindRiver vient d'ailleurs d'en implémenter un sur VxWorks : je parie que c'est pour répondre à ce genre de problématiques), et je discute après la conférence avec un ingénieur s'occupant de l'interfaçage juridique (on se demande d'ailleurs comment on pourrait nommer ce nouveau métier, que j'ai déjà rencontré chez Philips : je ne sais pas trop, mais ça m'intéresse comme évolution de carrière) de la possibilité de jouer avec les share memory, via une couche logicielle libre mais plus permissible, y pour interfacer des modules GPL avec du propriétaire (technique quelque peu utilisée par les hyperviseurs de paravirtualisation, après tout -- et j'ai déjà croisé un projet réel pour cela lorsque j'ai travaillé pour Trango). Mais il est vrai que la GPL parle d'un "tout logiciel" : nulle technique, au juge d'apprécier en cas de litige, donc au meilleur expert ès enfumage (et vulgarisation) de montrer ses prouesses, nous voilà fortement rassurés... Notons pour finir que les brevets n'ont pas été abordés (sujet connexe aux licences), et donc que l'affaire Tomtom n'a pas été évoquée, ce qui est dommage.

C'est ainsi que s'acheva la dernière conférence : j'en avais bien prévu une autre, sur les standards logiciels, mais manifestement elle a été annulée, certainement faute d'audiance, le dernier jour étant effectivement largement plus vide. J'ai pour ma part pu observer que le VME vivait toujours et plutôt bien, même s'il partage à présent l'affiche avec toutes sortes de PCI industriels. Côté processeurs, les nouveaux ARM Cortex ont évidemment la côte, occultant ARM9 et 11, d'autant que de nouveaux OMAP sur base Cortex apparaissent (les ARM7 étant remplacés par les M8, les autres étant A8, avec une évolution en faisant monter les chiffres à côté de chaque lettre -- la nommenclature ARM est toujours très sportive, seul Intel fait mieux) ; la puissance de ces processeurs fait apparaître des solutions à base de Java, où pour une simple application en stand alone, un OS est inutile (certains abandonnent de fait Linux), la VM faisant office de tout, y compris de scheduler entre les différents threads. Côté PPC, on trouve du PowerQUICC III, qui se porte toujours aussi bien dès qu'il s'agit de faire de la communication. Et puis la star, l'Atom, que l'on retrouve partout : il faut qu'Intel a enfin corrigé les énormes pertes d'énergie qui font que les netbooks meurent de fatigue au bout de deux heures seulement, et qu'à présent, on peut réellement concurrencer du ARM, avec moins d'automie mais plus de puissance, dit-on ; en tout cas, la solution étant viable depuis environ quatre mois à présent, le temps de concevoir des cartes et l'on a pu constater que l'engouement était très, très récent ; le PC104 et le Geode ont en tout cas totalement disparu ! Les nouvelles techniques de virtualisation en cours d'implémentation devraient aussi pousser dans ce sens, et Intel promet l'arrivée d'un adressage direct de la flash, sans passer par un contrôleur (ce qui est, rappelons-le, la lose totale) : on pourra ainsi, comme sur ARM, considérer flash et RAM de manière contigüe, et avec la promesse de pouvoir outrepasser le BIOS (ils travaillent avec Microsoft, me dit-on, car actuellement nul OS ne supporte cela : il faut dire que le BIOS -- pour l'instant incontournable sur l'archi x86 -- ne fait pas grand chose, il initialise principalement des périphériques PCI avant de lancer le bootloader, mais il est bien connu que Linux outrepasse depuis longtemps le paramétrage du BIOS, et que le projet FreeBIOS s'appelait avant LinuxBIOS car il s'est basé sur du code d'amorçage de Linux). Bref, Intel va inventer ce qui existe depuis 20 ans, on s'en félicite. En fait, je ne sais jamais trop si c'est une bonne nouvelle de voir débarquer en force une architecture aussi mal foutue que le x86 dans le monde de l'embarqué, déjà que près de la moitié des projets l'utilisent (pourquoi ? Parce que c'est connu, effet "j'ai le même dans mon PC", psychologie commerciale basique...). Cependant, Linagora se fera une joie de développer vos applications sur ce type de processeur, nous avons d'ailleurs achevé un projet majeur sur plate-forme à base de Pentium M (qui, s'il n'avait tenu qu'à moi, tournerait sur PowerQUICC III).

Je n'ai malheureusement rencontré que fort peu de monde connu dans les allées de RTS, j'ai eu la joie de tomber par le plus pur hasard (je revenais de SL alors qu'il s'en allait) sur mon ancien chef de projet chez Sagem, à qui j'ai donc enfin pu demander des nouvelles de notre bébé, le MO300e (module Neptune avec Nucleus+Linux) : eh bien c'est une totale déception commerciale, les clients potentiels préfèrent une implémentation à deux CPUs, un OMAP très simple et rigide allié à un ARM9 très souple comportant son propre Linux customisable. Moralité : peu importe la dose de technique que l'on met dans un projet (en l'occurrence, le MO300e c'est de la virtualisation maison, une interface web pour administrer le Linux et notamment gérer ses propres applications additionnelles, une sécurité parfaite, un SDK facile à mettre en oeuvre où j'ai même incorporé un système facilité d'émulation, etc) tant qu'on n'adresse pas le bon marché, et que l'on ne répond pas aux attentes des clients. De peur de ne pas pouvoir faire face aux demandes de support Linux, le périmètre a été fortement réduit, avec notamment l'impossibilité de charger des modules personnels dans le noyau, figé au 2.6.18 : la solution étant fortement industrialisée, il n'y avait pas vraiment le choix, et la mise à jour de firmware est une plaie, puisque nous sommes sur des LU, les Logical Units, entièrement chiffrées puisqu'ayant accès au réseau GSM (je pense cependant qu'une solution pouvait être envisagée pour mettre à jour à chaud, mais la demande en mémoire flash aurait été trop coûteuse) : comme quoi mettre un seul chip est plus économique mais trop spécifique dans ce cas pour adresser un large marché aux besoins très divers. Bien dimmensionner veut aussi dire d'étudier le marché, et de ne pas ignoré -- comme cela avait été le cas à l'époque -- les demandes pressantes des clients sur certains points techniques ; une récente discussion par mail à ce propos avec une société de M2M autrichienne a confirmé cette tendance (après avoir testé durant quelques semaines le produit -- ils m'ont demandé quelqu'aide par mail, car la réactivité de Sagem n'était pas terrible --, les dernières nouvelles étaient que leur avis sur la viabilité du produit était de plus incertaine, et que Wavecom semblait être, à regret, de nouveau la "meilleure" solution).

J'aurais en tout cas bien voulu échanger quelques mots avec mes collègues de l'APRIL Sébastien Dinot et Thomas Petazzoni, recontrer enfin David Chabal, croiser Patrice Kadionik et Pierre Ficheux qui j'en suis sûr connaissent plus mon visage que mon nom (ou l'inverse, allez trop savoir, mais il y a un manque certain de corrélation :)  ), deviser avec Denis Bodor de Linux Mag' (mais il était tout le temps occupé, je lui enverrai un mail), ou me faire présenter au pôle édition d'Eyrolles (parce que finalement, à part un peu "Embedded Linux Primer", dont l'auteur a d'ailleurs écrit dans le "Electronique" du mois de mars distribué gratuitement, il n'y a jamais de technique pure et concrète de "comment embarque-t-on du Linux", ce qui est un peu un comble pour des bouquins de Linux embarqué au nombre de quatre ou cinq, qui restent pourtant très bons ! Bref, je caresse une certaine idée...). Il y avait du monde sur SL, mais il était difficile de le rencontrer. Patrick Sinz était en tout cas sur le stand de Emtec (ex-BASF), pour présenter le Gdium (il bosse maintenant pour Gdium SA, basé au... Luxembourg, hum), et d'autres STB/disques durs multimédias de la marque.

Pour conclure (comment ça, "enfin" ?), mon avis sur les deux salons est positif mais avec une petite réserve sur un sentiment diffus d'essoufflement ; comme je fais la même remarque chaque année, ça ne doit pas être si grave (et puis, c'est la crise). Mon principal regret est la disjonction des deux salons. Un workshop géant pour Linux embarqué me semble être la meilleure idée, à la condition que les deux salons soient très proches (il aurait été possible d'avoir une continuité physique, les locaux sont prévus pour à la porte de Versailles !), ou alors qu'ils ne tombent pas aux mêmes dates, comme avant. Dans ce workshop (sur le salon RTS, s'entend, il faut que cela reste gratuit), il serait idéal d'adresser toute sorte d'intervenants, de milieux divers (industriels, CE, M2M, comm', etc), des enseignants et formateurs (quelques uns se baladaient sur le salon, ai-je appris sur le stand de Neomore), des libristes (pourquoi pas aussi des gens du monde BSD, eux aussi ont des choses à apporter à l'embarqué ! Soekris était d'ailleurs présent cette année encore sur SL), des entreprises de type intégrateur ou de service (c'est ici que peut entrer Linagora, outre l'aspect formation et juridique), en plus des habituels éditeurs, et enfin, élargir le scope avec du juridique (licences et brevets) ; je rêve d'un village associé à un cycle de conférence techniques ; et de retours d'expériences qui forgent des liens entre visiteurs (et pas seulement entre exposants et visiteurs), d'autant que Linux s'embarque sur des appareils tellement divers et spécifiques qu'il est toujours très intéressant d'en embrasser une vue la plus globale possible.

Concernant la diffusion de Linux et bien plus encore celle du logiciel libre dans l'embarqué (on pense aux méga-stars que sont gcc et Eclipse : on les trouve partout, soit bien plus encore que notre kernel favori), on peut dire que l'évolution atteint une sorte de vitesse de croisière : ceux qui attendaient pour migrer l'ont presque tous fait, et les nouveaux projets peuvent choisir parmi une gamme de solutions complète, où Linux prend une place importante, mais en dehors de tout effet de mode et de tout engouement irréfléchi. De nombreux partenariats ont été formés avec les principaux éditeurs de BSP, Montavista, WindRiver et Sysgo, de telle sorte que les fournisseurs de hardware peuvent répondre aux attentes de leurs clients, manifestement mieux informés qu'auparavant (cinq ou six ans que l'on évangélise, aussi). Cependant, le logiciel s'est trouvé de fait dans un certain recul -- je compte de tête cinq stands dédiés au soft "génériques", c'est-à-dire outre le spécifique de contrôle-commande ou d'analyseurs --, assez important même par rapport aux années précédentes, de telle sorte que j'ai bien peur que les acquis des années précédentes ne se perdent, d'autant que l'évolution du libre et du monde du CE est rapide. Sur les stands, on a souvent avoué un manque d'expertise dans les domaines que nous adressons, et il faut ajouter à cela les demandes en formation comme en renseignements juridiques solides. Il faut cependant bien se rendre compte de l'inertie toujours flagrante du milieu, fonctionnant selon une certaine logique de "cercles de confiance", et même si les accueils reçus étaient toujours chaleureux et intéressés (y compris à des endroits que je ne soupçonnais pas, comme le concepteur de fonds de panier PolyRack), nous verrons combien d'affaires peuvent nous être adressées...

J'espère cependant qu'elles seront assez nombreuses pour me permettre de justifier de nouveau deux jours et demi de visite sur les salons, mais aussi faire exploser le chiffre d'affaire du pôle embarqué, dont une commission me sera évidemment reversée (pas vrai patron ? ;)  ). Plus sérieusement, les retours seront certainement à mesurer d'ici les six prochains mois (j'ai déjà reçu un coup de fil, mais pas d'affaire sur le court terme), espérons simplement de leur positivité, en attendant de se faire encore mieux connaître. À noter cependant une évolution des mentalités avec une attention particulière portée au TTM, pour lequel Linux peut battre des records pour peu que l'on soit bien entouré ; cela rejoint clairement le sentiment dégagé lors du salon ARM. J'ai oublié de prendre des photos, cette fois-ci, d'ailleurs. On attend à présent les slides des conférences, pour information ARM m'a envoyé celles de leur salon sur CD-Rom, disponible à mon bureau.

Il n'y a plus qu'à remercier encore une fois les différents organisateurs des deux salons pour cette édition 2009, et donner rendez-vous à tous pour l'année prochaine !

lundi, avril 6 2009

drôle d'annonce pour une bonne nouvelle...

Electronique international titre : "L'industrie du semiconducteur pourrait avoir touché le fond". Comprendre : maintenant qu'on a touché le fond, ça ne peut que remonter. Si si, je vous jure :

Les stocks de circuits seraient désormais à des niveaux historiquement bas et les fabricants de systèmes n'auraient plus d'autre choix que de repasser des commandes ce qui devraient booster les ventes des fabricants de semiconducteurs, alors même que la santé de l'industrie électronique reste fragile.

La positive attitude post-crise, ça fait un peu peur, quand même.

lundi, mars 23 2009

un troll peut cacher bien des vérités

Cela faisait longtemps que je n'avais point trouvé sujet à troll, et même si ce n'est pas vendredi, voici un billet sur une pile d'appel Java pour le moins... impressionnante. Même en ruby, on ne fait pas mieux, même si c'est déjà beaucoup. D'autant que nous ne somme pas encore dans le code de l'interpréteur. Cependant, il faut paraît-il minorer pour le Java : la pile présentée est celle "virtuelle" (correspondant aux sources), et non la "réelle" qui peut être bien plus optimisée ; on n'en demeure pas moins songeur.

Faut-il crier haro sur le Java pour autant ? (je rappelle que nous sommes sur un blog embarqué) Un ingénieur très expérimenté en informatique industrielle/embarquée (ça tombe bien) dit que non. Et il détaille très longuement. J'aurais tendance à appuyer cet argumentaire, mais constate que l'Ada est tout de même plus sympathique que le Java (même si les effets de bords y sont bien plus aisés, par exemple parser des chaînes de caractères en Ada est à la limite de la calamité). En attendant, chacun sait mon aversion pour le C (d'autant que je le maîtrise parfaitement, sinon je ne pourrais en faire état :)  ). De même, des implémentations "solidifiées" de Java se comptent au nombre de deux (au moins, il faut voir où en est Sun aussi) depuis bien des années maintenant, et je n'ai pas l'impression qu'elles suscitent un grand engoument ; on vérifiera cela sur le stand d'Aonix (qui n'hésite pas à comparer Ada et Java) au prochain salon RTS.

Vers la fin de cet argumentaire très intéresant que j'ai cité, on trouve ceci :

One of the biggest lessons I've learned in my many years of working, interviewing, and managing projects is that specific technical skills are far less important than outlook and character. Technical skills are the easiest skills to teach. They're also the skills that must be updated and replaced regularly.

Le hasard voulait que je tienne précisément le même discours fort récemment, ce week-end pour être précis. Le problème est alors l'enseignement de cette partie très importante du métier de l'ingénieur (à tel point que l'évolution de carrière tend à en faire l'unique sujet, alors que la technique "pure" disparaît du champ d'action à plus ou moins court terme) : pour moi, cette formation de l'esprit passe par du retour d'expériences à travers de la veille technologique et de l'étude de marché (mêler des cas réels à des graphes d'études), par exemple. Simplement, ça ennuie toujours les étudiants...  :)

mardi, mars 10 2009

l'instant geek


Moment furtif s'il en est, ce blog fête tout à coup son 43ème billet...

(cependant, 24 commentaires -- dont 4 spams --, ça ne fait pas beaucoup)

jeudi, mars 5 2009

inventions nouvelles et dernières nouveautés

Dell invente le portable "hybride" : deux CPUs, l'un du x86, l'autre du ARM. Deux OS : le premier fait tourner un windaube®, l'autre un Linux. L'idée est surprenante au départ (c'est-à-dire lors des vingt premières secondes), mais ensuite, comment dire...

Côté news en français, presence-pc réalise un triple combo :

En pratique, il reste à vérifier l’efficacité réelle de cette technologie (les processeurs ARM sont rarement des foudres de guerre) et surtout son prix : intégrer un Linux, c’est gratuit, un processeur ARM, il faut le payer.

Les perles sont en gras ; je sais, ça fait presque toute la phrase.

jeudi, février 12 2009

la consternation ksh

Mais quel est ce comportement ?

There is one restriction on integer variables. Once a variable is set to integer type, it can't be assigned a non-integer value:

$ typeset —i NUM=abc 
/bin/ksh: NUM: bad number

Je ne sais pas bien si c'était à la base une idée de typer a posteriori des variables non-typées a priori, mais dans tous les cas ça pue déjà parce que pas standard comme comportement, et ensuite c'est loin d'être la meilleure idée du siècle dans l'absolu (si le langage est pourri, autant y aller jusqu'au bout !). Mais le pire du pire, c'est que l'erreur renvoyée est aussi parlante que :

script[167]: 08: bad number `08'

Hors, 167, ici, c'est un numéro de ligne qui correspond à la fin du "if" dans lequel on se trouve (if qui fait bien 40 lignes...). Tout à l'heure, j'ai vu la même erreur avec "09", ça arrive une fois toutes les deux heures en test (pour une exécution toutes les 30 secondes), sachant que ça pourrait effectivement bien être dû à une arithmétique de dates. Quelques recherches sur internet montrent que bien du monde s'est arraché les cheveux dessus. Heureusement, la solution était au milieu de tout ça...

Comme d'habitude, on retiendra qu'il faut fuir ksh. Mais décidément, les systèmes UNIX [pré-]historiques en raffolent toujours.

Edit: raté ! C'était :

        case ET_BADLIT:
                warningf(true, "%s: bad number `%s'", es->expression, str);
                break;

dans ksh/expr.c (on remarque les backquotes dans l'erreur). Mais ça ne m'avance guère plus, à vrai dire... (il semble que ce soit bien dans une assignation de variable, en tout cas)

Ré-édit:

Osanna pour Patrick ! (qui a déjà dû subir la même erreur en son temps)  Ah bien c'est que "0" suivi d'un chiffre, c'est considéré comme de l'octal, et justement :

struct tbl *
setint_v(struct tbl *vq, struct tbl *vp, bool arith)
{
        int base;
        long num;

        if ((base = getint(vp, &num, arith)) == -1)
                return NULL;

Sauf que j'avais pas capté (ça m'apprendra à tester avec $((04)) pour une erreur de "08" ou "09" !). Alors, la solution en bois sera de concaténer un "1" au début de la chaîne, et d'enlever 100 ensuite dans l'opération : berk !!

Oh, et ksh est quand même bien pourri dans ses messages d'erreur :

# echo $((4+08))
ksh: 4+08: bad number `08'
# echo $((08))
ksh: 08: bad number `08'
# HOUR=12
# MIN=03
# SEC=08
# TIME=$((HOUR*3600+MIN*60+SEC))
ksh: 08: bad number `08'
# SEC=03
# TIME=$((HOUR*3600+MIN*60+SEC))
# echo $TIME
43383

jeudi, décembre 18 2008

conférence Paris8 (mais cette fois, ce n'était pas moi)

Non, c'était Pierre Gronlier, un plus-que-fort bon ami de mes années d'étude à l'EPITA, qui après avoir brillamment obtenu son diplôme spécialisé dans le logiciel embarqué et temps-réel (je précise, parce qu'on était classé au même niveau, donc je m'envoie indirectement des fleurs), a continué très originalement sur un master à l'ENS Cachan. Spécialité : le traitement de l'image. Tout un programme !

Coopté lors de ma propre conférence auprès de la gente Isis Truck -- qu'il est toujours un plaisir de revoir --, je peux me targuer d'avoir aussi recommandé Basile Starynkevitch pour le 26 janvier prochain, comme quoi je devrais penser à me reconvertir en agence (ça dépendra de mon EAD, hum :D ) ; en revanche, je ne suis pour rien dans la programmation de Loïc Dachary du 2 février suivant, mais le monde est décidément petit. Ce qui est certain, c'est que pour une première expérience, ce fut fort bon. La conférence a porté sur le codage vidéo (et non l'encodage, pensons aux apparatchik de l'orthographe françoise, même si la subtilité est tellement subtile que...), car Pierre travaille pour Actimagine. Le lien avec l'embarqué est évident : le but premier est de permettre une décompression vidéo de leur propre format, Mobiclip, équivalent en qualité au h264, sur des appareils déjà en circulation et non prévus pour (CPU pas assez puissant et GPU absent), ou disposant de peu de batterie : téléphones, consoles vidéos, etc. Bon, c'est pas libre, mais franchement, la démonstration est assez bluffante pour ne pas dire que ça pue, à moins d'être malhonnête (et puis, il y a aussi des choses pas libres qui puaient, et qui une fois libérés sentent toujours fort, Java par exemple, et le reconnaître vous empêche d'être qualifié d'ayatollah du libre, alors...). En revanche, aussi excellent soit le produit, il serait bien de penser à une version Linux autre que celle de l'ami Pierre sur son PC. Bref...

Pierre a parlé d'à peu près tout, et de fait ça a duré : après avoir galéré sur la ligne 13 et être arrivé à 18h20 (18h00 en prévision, c'est tôt, mais bon...), la présentation a terminé bien après 20h00 (une bouteille entière d'une célèbre boisson désaltérante fut sacrifiée). Différences de format de câbles, d'affichage, de codecs, subtilités afférentes au codage vidéo -- le gamma et ses histoires ubuesques, entre autres héritages-boulets que l'on traîne toujours --, on aura même parlé de la perception visuelle avec une plongée dans notre capteur oculaire portatif (qui peut cependant aussi servir à la drague). Comme les slides sont disponibles, il est inutile de s'étendre.

Mais louons tout de même cette forte introduction-et-plus à ce sujet plus passionnant que ça en a l'air de prime abord (quoique les cours de traitement de l'image n'étaient pas mes préférés, j'ai toujours préféré les manchots en boîte), et surtout que l'on peut être amené à croiser un jour ou l'autre : outre la petite digression dans l'échec de la DVB-H en France (et il se trouve que j'ai bossé sur l'implantation de la DVB-SH : mais en l'occurrence, le simulateur de communication satellite avec le récepteur-retransmetteur terrestre), la partie sur la transmission télévisuelle m'aura rappelé mon passage dans les services de Philips l'année dernière (aujourd'hui racheté par Pace), où j'ai dû ingurgité dans le métro les bases du métier, avec le très bon ouvrage maison (on y parle beaucoup d'OpenTV, de fait, qui comme l'indique son nom est très fermé -- c'est ce qui fait tourner C+, par exemple). Alors il est toujours bon, pour sa culture, de savoir de quoi l'on parle. Surtout lorsque les STB, les télés, les lecteurs DVD et j'en passe migrent tous peu à peu sous Linux (et même les retransmetteurs de DVB-SH, donc...).

J'invite donc tout un chacun à découvrir les 10Mo de slides de Pierre, que je peux encore remercier au passage.

- page 3 de 5 -