La communauté Open-Source s'échine à vouloir supporter le système de fichiers NTFS. Parallèlement, elle s'irrite de voir Microsoft proposer un remplaçant au système FAT32. Certains voudraient développer un équivalent Open-Source. Mais pourquoi créer un nouveau système de fichiers?

FAT32 est un système de fichiers simple et sans gestion des droits d'accès, idéal pour des supports amovibles privilégiant les échanges, comme des clefs USB. Il est déjà exploité par une pléthore d'équipements existants et sert dans toutes sortes de services, par exemple lorsque des décodeurs TNT enregistrent sur des supports USB. FAT32 est le seul format qui soit inter-plateforme, compatible avec Mac, Windows, Linux et tout d'un tas d'équipements utilisateur.

FAT32 n'a qu'un gros défaut, il existe une limite maximale à la taille d'un fichier. Comment palier à cette limite de plus en plus gênante?

Simplement par une convention de nommage des tronçons d'un gros fichier. Par exemple: FICHIER.P01, FICHIER.P02, etc.

En utilisant la technologie FUSE sous Linux et Mac, on pourrait exposer à l'utilisateur un système FAT32 tout en masquant ce tronçonnage des gros fichiers. Ainsi, la limite sur la taille des fichiers n'existerait plus aux yeux de l'utilisateur. En utilisant une technologie équivalente, on pourrait éventuellement faire de même sous Windows.

Cette solution "poor man" pourrait renouveler l'intérêt de FAT32 tout en restant globalement compatible avec le parc d'équipements existants.

L'idée est de proposer une distribution linux virtuelle prête à l'emploi pour Windows / OS X faisant office de Machine Virtuelle pour faire tourner nativement sur Windows ou OS X toutes les applications du monde Libre GNU/Linux.

• L'exécution de Linux est basée sur une solution de virtualisation libre telle que qemu. La stack GUI est rendue par un serveur X intégré tel que X-Ming. Sauf que le tout est entièrement caréné, transparent et installable en un click. Il faut faire en sorte d'avoir une liaison avec les FileSystem du système hôte et (éventuellement) les périphériques la plus élégante possible.
  
• Linux est exécuté en singleton (un par session utilisateur). On pourrait aussi proposer Linux en service, i.e. une tâche système pour toute la session windows.
• Ce Linux virtualisé peut alors être vu comme une VM à la Java, avec un icône de supervision sagement rangé dans la systray.
• L'icône systray donne accès à un menu de debug pour afficher la console (/dev/console), voire un pseudo-terminal.
• L'icône systray affiche aussi un menu des applications utilisant couramment la VM, avec pour chaque application la possibilité de la killer +ou- de force (fermer la session X correspondante, etc.).
• L'icône systray s'interface aussi avec le système de package Linux virtuel pour superviser les mises à jour.
  
• Les applications basées sur ce Linux virtuel peuvent être packagées sous la forme d'un installeur Windows/Mac ayant pour effet d'installer le package correspondant dans le Linux virtuel (de préférence par le réseau) et d'appliquer un script de post-post-installation pour l'adapter à ce contexte original (via RSH).
  
• Une fois une application basée sur cette VM installée, l'application est lancée par un "wrapper" ayant pour effet:
• le démarrage de la distro Linux virtualisée si c'est pas déja fait.
• le démarrage d'une session X dédiée pour l'application ciblée, si elle n'existe pas déja.
• le démarrage d'une commande Linux dans un utilisateur non-root de la session Linux en RSH.
• Un choix judicieux de point de montage permet de retrouver l'arborescence usuelle du système hôte quand on manipule des fichiers utilisateurs.
• etc.

• Les nices to have: L'accélération matérielle de la virtualisation ++, le support de la caméra, de la carte son du système hôte. Pas nécessairement à travers des périphériques virtuels, cela peut-être aussi proposés par des serveurs de son (esound) ou de streaming audio/video. Pourquoi pas l'accélération 3D.

• Applications candidates: Tout l'arsenal des logiciels libres qui ont des difficultés à être portés sous Windows.
  

C'est dans l'air: développer un système d'exploitation graphique Open Source complet sur la base de:

• un système d'exploitation ouvert. e.g. Linux
• un middleware approprié (voir ci-après)
• un navigateur web en mode "kiosque" faisant office de couche graphique (DHTML) et de moteur d'exécution (Javascript) pour des petites applications faciles à développer (Widgets)
• La différence notable avec des solutions existantes est de pouvoir se passer complétement d'une stack graphique telle qu'un serveur X ou d'une machine virtuelle supplémentaire telle que Java. La zone d'affichage plein écran du navigateur forme la couche la plus basse de l'environnement graphique. Certains navigateurs, notamment Opera, peuvent ainsi fonctionner au plus près du matériel, i.e. directement branché sur le "frame buffer" et les périphériques d'entrées (clavier, souris) sans couche intermédiaire.
• La couche logicielle permettant aux applications d'accéder aux fonctionnalités de l'appareil et de cohabiter entre elles serait disponible sous la forme d'une API Javascript. Elle serait sans doute implémenté en grande partie sous la forme d'une application AJAX chargée dans le navigateur au boot. Il s'agirait ni plus ni moins d'une version embarquée d'un "portail à widgets". La différence par rapport à -par exemple- le run-time de Netvibes est que l'API Javascript est étendue à des fonctionnalités de l'appareil (stockage persistant, fonctions multimédia, BDD locale, etc.) et à des contrôles transverses de l'IHM (barre système, système de notification, icônes d'un menu, etc.).
  
• Il serait par exemple judicieux de s'appuyer sur l'offre fonctionnelle du vieux Palm OS (comme le système d'alerte) pour spécifier cet environnement en Javascript.
  
• Le produit commercial le plus proche de cette solution semble justement être le nouveau Palm webOS. Toutefois, le tout semble enrobé dans une IHM très réactive manifestement non basée sur des technos web.

Mon idée est d'aller jusqu'au bout de cette approche, et d'obtenir véritablement un "navigateur web matériel" qui ne s'appuierait sur aucune autre techno que des technos webs. J'aimerais voir apparaître une distro basée sur cette approche, prête à installer pour du matériel avec écran tactile basé sur Linux.

Le point clef de cette architecture embarquée réside dans le middleware qui relie le navigateur ave l'OS et les démons en dessous. Cette couche doit donner accès à des fonctions locales habituellement inatteignables par un navigateur. Il existe 2 approches dans le domaine.

1. écrire un plugin. Par exemple, j'ai entendu en 2008 parler d'une société qui avait écrit un plugin pour donner accès à DBUS depuis le navigateur.
2. écrire un service web local pour accéder aux couches basses par HTTP.

Selon ma logique jusqu'au-boutiste, je préfère la deuxième solution: Un accès HTTP aux couches basses. Ce choix pose ceci-dit 2 sous-problèmes.

• Je veux conserver la politique de sécurité actuelle d'un navigateur. Un widget (ie. une application) distant devra donc être d'abord être hébergé et publié par le serveur web local pour accéder à l'API HTTP locale.
• HTTP n'est pas à l'origine conçu pour remonter des évenements poussés par le serveur (les couches basses),  par exemple dans ce contexte: des évenements réseaux, matériels, multimédia... Mais la situation est en train de changer, Opera permet par exemple de s'abonner à une source d'évenements poussés par le serveur ("server-side dom event"), il s'agit simplement d'une implémentation moderne des vieilles astuces de "push HTTP" à base de connexions HTTP à longue durée de vie.

La solution technique consiste donc en:

• un serveur HTTP
• qui publie les ressources des applications/widgets installés localement
• qui offre une API HTTP d'accès aux couches logicielles embarquées sous le navigateur
• qui supporte parfaitement le Push HTTP sous sa forme la plus moderne (server-side events)
• qui se substitue à des middlewares comme D-BUS.

Sur le download multiple

• 1er constat: les informaticiens sont des idiots. Les navigateurs web évoluent  en intégrant toujours plus de fonctionnalités "bling bling" alors que certaines interactions de base sont toujours aussi peu ergonomiques.
• Exemple: le download multiple. Alors que les sites web permettant de gérer des collections de données (vidéo, images, fichier) se multiplient, pourquoi n'existe t'il pas une méthode simple permettant de rappatrier plusieurs fichiers à la fois depuis son navigateur?
• La solution simple pourrait être de standardiser par une RFC un type mime "ensemble de fichiers" correspondant à une archive (à la zip) que le navigateur décompacterait à la volée.
• Si les navigateurs étaient modifiés en ce sens, alors on pourrait sélectionner plusieurs items dans une application web, appuyer sur un bouton download, et le navigateur ouvrirait une boîte de sélection de dossier local. Une fois le téléchargement terminé, tous les items téléchargés se retrouveraient sagement posés dans le dossier choisi. En cas de conflits avec des fichiers locaux existants, ce serait bien que le navigateur négocie avec l'utilisateur le "comment faire"...
  
• En attendant, certains sites fabriquent des zips à la volée. Problème: la décompression du zip nécessite un utilitaire et une action utilisateur pas forcément évidente.
• D'autres fabriquent des archives auto-extractibles. Problème, l'auto-extractible affiche souvent une IHM pas très sexy.
• Pour l'instant, la meilleure solution consiste en un auto-extractible complétement "seamless": un double click = décompression dans le répertoire courant + suppression du fichier compressé.

Backup intelligent

J'ai étudié récemment la stratégie employée dans 2 outils récents, robustes et efficaces concernant la copie, le versionnage et la synchronisation de fichiers, à savoir "git" et "rdiff-backup". J'en ai déduis une stratégie très simple et redoutablement efficace pour synchroniser 2 arborescences de fichiers sans la nécessité d'installer une paire de logiciels dédiés sur les 2 conteneurs.

• Soient un dossier local et un conteneur de fichiers distant traditionnels, sans fonctionnalités particulières pour faciliter la synchro (à la SyncML ou rdiff). Par exemple: une clef USB, un partage CIFS, un serveur FTP, un dossier sur un File System ordinaire, une solution de stockage en ligneà la box.net, etc.
• On va exécuter le script de backup sur la machine qui héberge le dossier local. Le but est de synchroniser ce dossier local avec une copie sur le support distant en limitant le transfert de données vers ce support (très couteux) et en essayant le plus possible de faire appels à des opérateurs de déplacement/renommage/copie du support, que l'on suppose au contraire peut coûteux.
  
• Lors d'une synchro, le script commence à générer une table des signatures de tous les fichiers locaux. Une signature pourrait être un haché cryptographique SHA-2 (comme "git") réputé capable d'identifier de manière unique n'importe quel fichier présent et futur. La table répertorie toutes les paires (chemin-de-fichier/signature). Le raffraîchissement ultérieure de cette table peut être accéléré en stockant une deuxième signature locale afin d'identifier les fichiers immobiles entre 2 synchro successives (inode,taille,timestamp).
  
• Puis le script télécharge la table correspondante sur le conteneur distant.
• Enfin, le script fait des comparaisons entre les 2 tables et applique les changements. Par exemple pour un fonctionnement en mirror source/destination classique, cela donne:
  
• signature dans la source absente dans la destination: on transmet le fichier à l'emplacement prévu (si plusieurs emplacements, on copie le fichier dans la destination sur les autres emplacements)
  
• Signature à des emplacements différents entre la source et la destination (suite, à déplacement, renommage ou copie de fichiers). on copie ou on déplace le fichier destination. Si le conteneur est bien fichu, l'opération ne nécessite pas le transfert de données sur le réseau.
• Signature dans la destination absente de la source: on supprime le fichier (ou les copies multiples du fichier).
• ce qui est vraiment génial (toute humilité mise à part), c'est que non seulement on synchronise que ce qui est nécessaire, mais en plus, lorsqu'on fait du rangement dans le conteneur source (renommage, classement...), le conteneur destination va être resynchronisé sans faire le moindre transfert de données. On va simplement faire appel aux opérateurs de copie/déplacement du support distant.
  

• Site web 2.0 de fabrication de fond d'écran: on upload des photos qu'on place ensuite sur un canevas facile d'accès (3 couches: un BG, 1 ou plusieurs photos/dessins + des accessoires (coeur, fleur, etoiles). Nombreux artwork prêts à l'emploi. Possibilité de publier son oeuvre sur un réseau social 2.0. Techno client lourd DHTML/Canvas sauf IE. Après validation/sauvegarde, affichage de l'image résultat et passage en fond d'écran par click droit "mettre en fond d'écran". Use case caractéristique: "Comment je fais pour mettre 2 photos sur mon fond d'écran?", Business Model publicitaire/Micro Payement (upload de photos persos). Les abonnés peuvent aussi héberger plusieurs fonds sur le site pour des changements rapides au bureau, à la maison. File de syndication pour économiseur d'écran.
  
• Un widget pour Netvibes et consort permettant de clipper n'importe quel page web (comme les webclip d'Apple je crois): paramètres= url,x,y,width,eight,... le backend génère une image de la portion de page de l'url désiré via un mozilla/WebKit automatisé, passer par un service style bugmenot pour passer un formulaire de login si nécessaire
  

L'idée est la suivante. Mettre au point un générateur de voix de synthèse pour marionnette.

Il disposerait d'une interface homme/machine dissimulé, par exemple un mini-clavier dans la main libre du marionnettiste. D'autres pistes à étudier. eg. un petit micro, couplé à de la reco vocale pour décoder de chuintement.

Deux pistes: soit l'IHM sert au manipulateur à entrer des phonèmes, soit elle permet de choisir un mot ou une expression dans un dictionnaire limité.

La voix de la marionnette est produite au fur et à mesure de la saisie, avec sans doute un léger délais. Il pourrait y avoir un tampon de saisie, annulable en cas d'erreur de saisie par un geste spécial qui fait faire "heu..."  à la marionnette.

Tout le monde pourrait se mettre à faire le ventriloque avec un peu d'expérience. Le système pourrait aussi avoir des applications non ludiques: pédopsychiatrie par exemple.

Un prototype pourrait être basé sur un PDA Linux (mais aussi iPhone, pocket PC, etc)

l'idée: comprimer l'image avec uniquement une solution de dithering couplé à une matrice de perte quantification/vs/résolution.

principe présenté avec à une image en teinte de gris, à géneraliser pour chaque composante d'un projection RGB, YUV, etc.

principe: on transforme l'image à compresser en une résolution supérieure avec une quantification inférieure. Les teintes de gris sont encodés par dithering. Par exemple, on multiplie la résolution par 8 et on passe en N&B. Un pixel original gris devient un groupe de 8 pixels formant une trame. L'encodage de la teinte d'origine doit être de sorte que beaucoup de bits à 1 correspond à une valeur élevée (A FAIRE: Nommer l'encodage). Il doit exister une fonction inverse pour retrouver exactement l'image originale.

Pour l'instant, rien n'a été compressé.

L'idée à présent est de réduire la résolution de l'image résultante. Grosso modo, on remplace un groupe majoritaire de 1 par un 1, et un groupe majoritaire de 0 par 0 (alèa à voir).

Il s'agit d'une compression par perte d'information.

Mais perte de quoi? c'est là l'astuce: on découpe l'image en zone, pour chaque zone on associe un attribut disant si l'on a plutôt perdu la quantification (proche de 0) ou la résolution de l'image (proche de 1).

sur une zone à fort détail, d'entropie élevée, on choisit un attribut proche de 0. On perd la quantification: les couleurs sont fortement quantifiées, mais les détails (forme des bords) sont préservés.

sur une zone à faible détail, on choisit un attribut proche de 1. Cela conserve la quantification (couleur proche de l'original), mais on sacrifie la résolution. on retrouve les gros applats carrés style JPEG.

On peut dire que cet attribut correspond à un degré de diffusion des pixels dans la zone.

enfin, on comprime le résultat par un algo de compression sans perte.

J'essaye tant bien que mal de référencer le site de mon café préféré: le café Théodore à Trédrez-Locquémau.

Je suis en train d'écrire cet article sur une Nintendo DS Lite avec le navigateur Opera. Et ca marche plutôt bien! L'affichage du blog sur joueb.com est plus réactive que la plupart des sites visités. Ca va sans doute redonner vie à ce journal.

Point 1: "X" personally uses more energy in one month than most people use in an entire year. Hippocrites can't be trusted. (replace "X" by any well-known environmentalist).

Counter-point:

That's so handy. If every environmentalist becomes the ascetic you want him to be, noone will be able to bother you and your scorched earth policy.

I hope that one day, the current biased so-called free market economy will be moderated and corrected by a parallel economy of societal and environmental costs. It could help clarify the situation when our job conduce us to have environmentaly expensive activities. Reason tells me it's admissible as long as we're mandated by a lot of people to do so, like politics.

I admit it's difficult to explain how a SUV may really be needed by any politic. But occidental world is so wrong that such over-branded goods may be required to gain and keep some credibility (OK, certainly not a SUV). That's why, for your information, as long as my children are not strong enough to deal with social pressure, I'll continue to buy them stupid and dispensable stuff like Spiderman school bags.