Pourquoi Linux ne percera pas sur le desktop

Disclamer

Voici un billet pourrait sembler aller à  contre sens de mes convictions, cependant je n’ai pas honte de dire que des convictions sont parfois amenées à évoluer en fonction de la réalité que l’on veut bien accepter. Dans le cas où l’on refuse d’admettre les faits, il faut accepter l’idée de vivre avec sa propre réalité dans sa tête et au final sans doute plus subir que jouir de ses convictions…

Ce billet n’est pas une tentative d’excuse, n’ayant rien à justifier à personne, mais un simple billet d’humeur pour pourrait intéresser quelques gouikers.

Contexte

J’ai donc eu l’occasion de tester un week end complet un vieux macbook blanc. Même si j’avais pu lorgner du coin de l’oeil un OS X, cela n’a rien à voir avec un test complet dans les mains. La première chose qui me vient à l’esprit c’est OS X est un OS taillé au laser. Il possède une finition remarquable, que cela soit dans les polices, dans les petits détails comme dans l’écosystème de store remarquablement bien présenté. La dernière version de l »OS (Lion) ne semble subir d’aucun lag même sur ce vieux macbook de 2006. Le matériel est du même niveau avec un trackpad très agréable et beaucoup plus utilisable que les versions PC…

Je ne vais pas m’étendre mais l’OS possède une cohérence et une finition qu’aucun desktop libre n’arrive à approcher, que cela soit GNOME ou KDE. Ubuntu essaye bien de ressembler à OS X, mais il subit la stack Linux/Xorg/GTK ce qui ne lui permettra pas d’atteindre ce même niveau d’excellence.

Théorie

Ma théorie est donc la suivante :

1. Linux est un noyau généraliste, qui essaye tant bien que mal de supporter une multitude de matériels.

2. Xorg est un serveur graphique en userspace qui possède une architecture très adaptée dans un ancien temps mais est archaïque de nos jours.

3. Les projets GNOME et KDE se concentrent uniquement sur les logiciels, ils ignorent sciemment la demande de services en ligne. Ils ne travaillent sur aucune API qui permettrait à un développeur d’un logiciel natif desktop de faciliter l’utilisation d’Internet. Chaque développeur doit donc redévelopper la roue de son côté et s’occuper de la partie développement et hébergement côté serveur s’il souhaite intégrer des fonctionnalités type cloud (synchronisation des préférences et des données en ligne, …).

A l’inverse Mozilla essaye d’adapter le web au desktop (sic) avec le projet WebAPI. Il est « amusant » de voir que ceux qui auraient le moins de boulot pour fournir un desktop libre qui exploite Internet ne sont pas ceux qu’on aurait pu imaginer…………..

Faits

Chez Apple on trouve :

  1. Un noyau (micro-noyau peu importe) optimisé pour une gamme de matériel
  2. Une stack graphique moderne et intégrée au plus profond de l’OS
  3. Une plateforme de développement cohérente, moderne et dernièrement des API pour exploiter les fonctionnalités d’Internet (cloud Apple), afin de proposer des services de synchronisation (datas et apps), backup et partage de données.

Les 2 premiers points me rappellent furieusement les Amiga et Atari. Pour rappel pour les plus jeunes, ça été deux énormes succès, les premiers ordinateurs grand public (années 80-90). Ils ont malheureusement fini par échouer plus pour des raisons de stratégies commerciales et d’égo des dirigeants que de techniques. Cependant leur réussite a été du à un OS 100% dédié a un type de matériel (et en grande partie en langage assembleur) ce qui permettait des optimisations de folies. Les développeurs d’applications tierces connaissaient la plateforme sur le bout des doigts, ils ne perdaient pas leur temps à gérer des configuration matériel tordues.

Face au melon qu’ont pris les dirigeants d’Atari et Amiga ce qui a bridé le renouvellement de la gamme, les PC à bas coûts fait de bric et de broc ont su séduire  malgré des interfaces MS-DOS bien inférieures…

Or, ce qui a fait le succès d’Atari et Amiga, a été clairement repris par Steve Jobs : Un OS conçu pour le desktop et dédié à un type de matériel. Cette recette est, à mon avis, la seule valable pour rendre l’informatique sexy, agréable, intuitive, ergonomique, moderne. Elle a certes le « petit » défaut de lier l’utilisateur à cet écosystème logiciel et à des types de matériels et périphériques. Mais c’est le prix à payer pour ceux qui souhaite bénéficier de ces avantages, et ce prix étaient d’ailleurs  à l’époque pleinement accepté par les Ataristes et Amigaiste.

Conclusion

Le calcul personnel à faire est donc mettre sur la balance le prix d’être lié à une marque et ses technologies proprios face au prix de subir une informatique dépassée qui n’apporte plus aucun plaisir. J’ai personnellement fait mon choix, car j’estime qu’en 2012 il est temps que l’informatique de bureau devienne un plaisir, quelque chose d’intuitif et transparent. Quelle liberté y a t-il a subir ses convictions ?

Pour ces raisons le desktop Linux ne pourra pas arriver aux genoux de ce que propose Apple avec OS X. Seule une entreprise qui ferait le choix de modifier profondément la stack Linux/Xorg pour l’optimiser à un matériel spécifique pourrait peut-être commencer à y arriver, encore que l’architecture de Haiku OS est à mon sens plus adapté par design.

Bien entendu le bureau Linux aura toujours son public, mais un public restreint, différent de la foule toujours plus grande qui souhaite se faire plaisir à utiliser un environnement sexy qui rend de plus en plus de services.  Si des communautés du libre pensent prétendre un jour opposer une alternative, il faudra autre chose que des paroles qui exigent au grand public de devenir informaticien pour « s’auto-héberger ». Il faudra arrêter de troller, sortir le doigt de son derrière et tapoter sur son clavier pour coder une alternative sexy qui rend des services.

J’ai d’ailleurs testé récemment le très sexy Enlightenment (E17). Le problème est que même si le bureau après de pénibles paramétrages est à tomber (KDE ET GNOME sont juste laids à côté), il n’y a aucune application en EFL… Utiliser des applications en Qt ou GTK sous E17 n’apporte donc aucune cohérence malheureusement, sauf à gruger mollement avec des thèmes…

BREF, je n’ai pas encore acheté de Mac faute de budget :) Je souhaite vraiment que le libre puisse un jour fournir une alternative complète qui pourrait séduire un grand public, cependant les choix stupides de certains et les non-choix stupides des autres me font douter fortement de cela à moyen terme. En attendant l’heure du plaisir est venu :) (ou pas)

Centralisation des logs Windows vers Linux via syslog

[Article publié sur linuxfr.org]

Intro

Lorsqu’on gère un parc de serveur qui comprend malheureusement des serveurs Windows, on souhaite centraliser leurs logs, voir même recevoir des alertes en fonction du contenu. C’est simple à faire sous Linux avec rsyslog, avec lequel je transmets les syslogs vers l’excellent Graylog2. Par contre dans le monde Windows il n’y a pas de serveur syslog natif. J’avais donc trouvé MonitorWare Agent un impressionnant logiciel propriétaire qui permet de définir des services qui vont lire n’importe quel type de logs, puis associer à ces services des ruleset qui vont déclencher une action comme faire suivre les logs vers un serveur syslog. L’interface graphique permet de créer un nombre de services et de rulesets impressionnants pour enchaîner des actions les plus tordus.
Le seul problème est le coût de la licence à environ 200€ par serveur, ce qui peut être bloquant.

NXLOG

Prêt à laisser tomber, mon collègue et voisin de bureau @ponteilla m’a judicieusement déniché le logiciel libre nxlog qui permet de faire exactement la même chose, sans interface graphique mais ça nous fait pas peur. Après de nombreux tâtonnement et quelques mails sur la liste j’ai pu transmettre les logs d’une application qui rotate elle meme ses logs en donnant un nouveau nom au log en cours (gruik)… Cependant nxlog permet d’utiliser des wildcard sur les noms des fichiers (*.log par ex) et même d’être récursif en allant lire tous les logs dans chaque sous répertoire. Un processor transformer permet de formater le log selon la RFC syslog voulue.
La doc montre le workflow très poussé de nxlog qui permet des enchaînements vraiment tordu, genre intégrer un schéduler dans un module input, surveiller un fichier de log et le convertir en CVS vers un autre fichier xm_csv_example. Il intègre également un langage qui permet par exemple de tester une expression régulière sur un flux en entrée :

if $Message =~ /^Test (\S+)/ log_info("captured: " + $1); 

Workflow

En entrée on choisi un input module (fichier, sgbd, syslog, tcp/udp, ..), puis un processor module qui va transformer ou filtrer les datas, puis un output module (sgbd, syslog, tcp/udp, file, ..) enfin via la directive route on enchaîne ces modules entre eux. Je n’ai que survolé les possibilités du soft, mais au vu de sa richesse et de sa licence GPL/LGPL je suis plutôt surpris de ne pas le trouver dans les dépôts debian/ubuntu.

Config basique fichiers de logs (*.log) -> serveur Graylog2 Linux (syslog)

Voici ma config qui fonctionne. Le serveur Windows communique avec Graylog2 sous Linux via OpenVPN. Pour aider au paramétrage j’ai lancé sur le Linux un tcpdump pour vérifier que les paquets arrivaient bien, avec la facility voulue :

tcpdump -i tap0 "udp port 514" 

Le fichier de conf nxlog.conf

## This is a sample configuration file. See the nxlog reference manual about the
## configuration options. It should be installed locally and is also available
## online at http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html
## Please set the ROOT to the folder your nxlog was installed into,
## otherwise it will not start.
define ROOT C:\Program Files\nxlog
# define ROOT C:\Program Files (x86)\nxlog
define CERTDIR %ROOT%\cert
define CONFDIR %ROOT%\conf
define LOGDIR %ROOT%\data
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
LogLevel INFO
<Extension syslog>
 Module xm_syslog
</Extension>
<Input in>
 Module im_file
 File "C:\monapp\log\\*.log" # lit tous les .log dans tous les sous répertoires !
 Exec $Message = $raw_event;
 SavePos TRUE
 Recursive TRUE
</Input>
<Processor transformer>
 Module pm_transformer
 Exec $SyslogFacilityValue = syslog_facility_value("local2");
 OutputFormat syslog_rfc3164
</Processor>
<Output out>
 Module om_udp
 Host 10.8.0.1 # IP du serveur Linux sur lequel écoute graylog2 server
   Port 514
</Output>
<Route 1>
Path in => transformer => out
</Route> 

le confort contre la liberté

[Article publié sur Linuxfr.org] source @zifro

Je viens de tomber sur APPLE, LA TYRANNIE DU COOL qui contient cette phrase :

Tim Wu, qui compare le succès de Steve Jobs à celui d’Hollywood, en soulignant que l’humanité préfère en général « la facilité et le confort » à la liberté

Je vais tenter de décortiquer cette phrase qui me parait très lumineuse, et possède plusieurs niveaux de profondeur pour nous Linuxiens.

En effet si nous sommes tous d’accord ici pour dénoncer la perte de nos libertés fondamentales lorsqu’on utilise un produit Apple, il en est pas de même pour reconnaître la faiblesse du logiciel libre qui ne le rend pas assez attrayant face aux produits Apple/Google. Pour certains le client Apple est idiot, pour d’autres il est bling bling, pour d’autres il est anti-microsoft primaire ou bien il peut être tout ça.

Cette histoire de confort me rappelle une histoire, vraie il me semble, sur un test de scientifiques effectué sur des chimpanzés. Ils fournissaient 2 moyens à ceux-ci pour obtenir des bananes. Un très complexe à base de cordes et de poulies et un autre très simple qui permet de prendre les bananes en tendant le bras à travers des barreaux légèrement électrifié. Il s’est avéré que le stress généré par la peur du courant électrique était moins important que celui généré via le système de poulies pourtant sans douleur.

Rapporté à l’être humain, cette histoire tend à démontrer qu’il préférerait le moyen le plus simple pour effectuer des tâches courantes, quelque soit les inconvénients. Donc même si ces tâches sont effectuées via des logiciels libres offrant plus de libertés, elles seront la plupart du temps plus stressante qu’un logiciel ou surtout qu’un écosystème propriétaire comme Apple ou Google plus agréable.

Si l’on admet cette réalité, d’autant plus pour des personnes dont l’informatique n’est qu’un outil qui ne les occupent qu’une infime partie de leur temps par rapport à nous, on ne devrait plus perdre du temps à pratiquer le dénigrement ou le mépris envers ces personnes, mais comment rendre les logiciels libres plus agréable.

Le cloud

C’est un système très justement dénoncé par le risque de perte de la vie privée contenue dans nos données. Il est pourtant le pilier des écosystèmes d’Apple, de Google, et prochainement de Microsoft. Cet outil permet et permettra encore plus de simplifier la synchronisation des données personnelles, des applications et des personnalisations.
Il est l’outil indispensable à l’amélioration du confort de l’utilisateur, et pourtant nous ne faisons que le dénigrer voir dénoncer la dangerosité d’un tel système en le baptisant par certains Minitel 2.0

Certains travaillent à concevoir des logiciels libres alternatifs aux outils propriétaires les plus connus basés sur le cloud, comme movim ou diaspora. D’autres comme la FSFFrance ou tuxfamily proposent d’héberger des logiciels libres. Même si ces 2 types d’initiative pourraient conjointement arriver à un début d’alternative, encore faudrait-il une équipe de techniciens pour maintenir et faire évoluer l’infrastructure. Or nous l’avons vu avec l’APINC et Tuxfamily, ce type de service basé sur le bénévolat est par définition non pérenne.

L’autre solution est l’auto-hébergement, ce qui revient à renvoyer à l’utilisateur la prise en charge des services et donc la complexité de celle-ci. Il va s’en dire que ce n’est pas une solution pour le grand public.

Solutions

Des solutions sont à mon avis nécessaire si l’on veut que le grand public ne doivent pas choisir entre son confort et sa liberté. Pourquoi l’utilisation du logiciel libre devrait nécessairement passer par une complexité ou une compréhension de l’informatique ?
Cette question est d’autant plus critique maintenant car jusqu’à il y a quelques années l’usage d’un logiciel libre comme un navigateur web ou une suite bureautique n’impliquait pas un grand effort face à la version propriétaire, hormis bien sûr celui de changer ses habitudes. Cependant avec l’intégration de plus en plus fortes de services au sein des logiciels, la différence entre logiciel propriétaire et logiciel libre est de plus en plus flagrante et ne sera pas en faveur de ces derniers.

Une solution serait qu’une Fondation du libre possédant une certaine reconnaissance de ses pairs proposent des services. En effet le dilemme du cloud est qu’il suffit qu’une entreprise exploite de données personnelles pour que cela suffise à jeter le doute sur la vie privée, que cela soit Google ou Canonical. A priori seul une Fondation ayant en son coeur une éthique, comme la FSF ou la Mozilla Fondation pourraient obtenir la légitimité de l’exploitation de données personnelles.

L’autre solution qui est une sorte de Graal, serait de concilier le P2P et les services. Il « suffirait » que des services, quel qu’ils soient, s’appuient sur une API système, laquelle fonctionnerait en P2P pour distribuer les données découpées, chiffrées et redondées. J’ai cependant bien peur qu’un tel système ne voit pas le jour avant très longtemps.

C’est pourtant à mon avis le prochain défi du logiciel libre, ne plus se contenter de proposer du logiciel, mais aussi des services si possible décentralisés et si possible non gratuit.

La gratuité

La liberté a un coût, la preuve en est que certains s’en prive en échange de confort et de simplicité. Il est à mon avis dommageable à long terme pour le libre que ce coût soit sur celui du confort d’utilisation. Le succès d’Apple montre qu’un grand nombre de personnes sont prêtes à payer très cher en monnaies, leur confort. Un autre grand nombre de personnes sont prêtes à obtenir ce confort en échange de leur vie privée, chez Facebook ou Google.
Dans les 3 cités, Apple, Facebook, Google, aucun n’a fait l’économie du confort.

Il est donc à mon avis nécessaire de diminuer fortement l’effort nécessaire à utiliser et exploiter les logiciels libres, l’usage de services liés sera pour cela de plus en plus indispensable. Une grande partie des utilisateurs seraient prêt à payer pour ces services ce qui permettrait d’une part de financer leur développement et exploitation, mais aussi que les communautés libres qui développent et supportent ces services puisse s’auto financer.

Quand je vois la part de plus en plus grande que prend l’informatique connecté à des services en ligne sur des formes aussi variées que des véhicules, des télévisions, console de jeux, téléphone, frigo, maison, etc, et que le libre ne propose aucune alternative à cela hormis dire que c’est pas bien, je suis très inquiet, certes pas à titre personnel mais pour l’avenir de tous.

Il sera je pense de plus en plus nécessaire de penser au confort, au financement et donc arriver à créer un écosystème décentralisé libre auto-financé et en terminer avec les tabous des services et de l’argent.

un petit retour des JDLL 2011

mise à jour : Je me rend compte avoir oublié de parler de la conférence sur Illyse l’association qui souhaite proposer un FAI associatif local sur Lyon et Saint Etienne. Illyse fait parti du projet d’essaimage lancé par FDN. J’ai trouvé Jean-François Mourges (que je connais ayant travaillé avec lui :) ) plutôt bon orateur et ayant semble-t-il réussi a s’entourer d’une équipe compétente , ce qui est la base de la réussite d’un projet. Cependant je m’ajoute aux requêtes qui ont été faite sur une offre VPN. En effet une offre d’un accès Internet non triple play entre 35 et 40 euros, qui comprend l’achat d’un modem ADSL et de 100 euros de frais d’installation est à mon avis un énorme frein pour pas mal de geeks. Or il serait à mon avis pragmatique de proposer en plus une offre VPN (entre 5 et 10 euros par mois par exemple) qui permettrait de financer plus rapidement l’association. Même si dans l’idéal on ne devrait pas avoir besoin d’utiliser un VPN puisque les FAI devraient respecter la neutralité des réseaux, un pragmatisme « à la Linus » en phase avec la triste réalité, permettrait, à mon avis, la réussite de ce projet.

Comme chaque année j’ai fait un tour aux JDLL le vendredi et le samedi. Il y a eu des conférences très intéressantes, notamment celle d’ Alexandre de dommelin sur puppet. J’ai déjà eu envie d’utiliser cet outil de gestion automatique des déploiements et des configurations, mais son enthousiasme m’a convaincu d’utiliser cet outil indispensable à l’industrialisation d’un SI (traçabilité, déploiement automatique, etc).

J’ai ensuite suivi les conférences sur movim et salut à toi qui sont des réseaux sociaux décentralisés basés sur XMPP. On voit qu’il y a eu beaucoup de taff derrière ces projets, et qu’ils mériteraient d’être financé. Au sujet du financement j’ai rencontré les petits gars derrière elveos qui permet de financer les développements de logiciels libre. C’est typiquement ce genre d’outil qui manque à notre écosystème depuis longtemps. Mais à mon sens ils devraient ajouter une gestion des ressources humaines en plus des ressources financières. En effet l’énorme difficulté des développeurs de logiciel libre, outre le financement, est de trouver d’autres développeurs, administrateur, graphiste, etc.

J’ai ensuite assisté à la conférence de Benjamin Bayard. Il a vraiment des talents d’orateur et de vulgarisation. Sur les problématiques aussi fondamentales telles que la neutralité des réseaux, nous mériterions qu’il touche un plus grand public plutôt que celui des geeks déjà acquis à cette cause.

Pour finir j’ai été plutôt impressionné par une démonstration d’opensuse sur le stand éponyme. L’outil OBS semble à première vue extraordinaire pour générer des paquets vers différentes distributions Linux. Mon netbook va sans doute servir de cobaye.

Peut être que l’année prochaine j’aurais assez avancé sur nodecast pour faire une petite conférence, et ainsi éviter de saouler toutes les personnes qui font l’erreur de me demander quel est mon projet :)

Quoi qu’il en soit, il me parait évident que l’avenir des prochains services libres s’annoncent décentralisé et basé sur XMPP. C’est à mon sens la meilleur voie si l’ont veut éviter l’hémorragie des utilisateurs vers des services propriétaires centralisés et ce que cela implique en terme de protection de la vie privée. Car il ne sert à rien d’utiliser des logiciels libres sur son poste de travail si les données sont stockées chez Apple, Google, Facebook, Yahoo, …

NCS : un serveur applicatif

Lors de mon dernier article sur nodecast je terminais sur la possibilité d’y intégrer un serveur web pour remplacer le serveur ruby Thin qui exposait l’API HTTP REST. C’est maintenant chose faite, la libqxt via son module QxtWeb m’a permis de mettre en œuvre assez simplement un serveur web dans un thread du serveur ncs. J’ai migré tout le projet sur github, le code du serveur est visible ici : http_api.cpp. Ce how to m’a été très utile : How to create a simple webservice using qt and libqxt

Dans la lancée j’ai également intégré un serveur XMPP grâce à QXmpp  ce qui permet au client Geekast d’effectuer des push en XMPP. Il fonctionne également dans son propre thread. Outre la rapidité de ce protocole face à HTTP, cela va permettre aux clients Geekast d’avoir une socket persistante avec le serveur ncs et donc permettre à celui-ci de faire du push vers tous les clients connectés. Les usages restent à définir mais cette possibilité ouvre un grand nombre de portes. Par exemple proposer la possibilité d’agir sur tous ses clients geekast depuis l’interface web (kill de processus, etc). L’envoi par HTTP sera toujours présent dans le client, au cas où la connexion XMPP est impossible (firewall, etc).

L’autre avancée est sur le format de donnée entre le client et le serveur, qui migre du XML vers JSON via QxtJson. Ainsi le serveur ncs qui reçoit les payload en json peut directement les transformer en bson object, format binaire de MongoDB. Plus besoin de passer par un lourd parsing du xml et des conversions vers des tableaux pour en extraire les données. La ligne suivante montre la simplicité d’une telle conversion :

bson::bo m_bo_json = mongo::fromjson(json.toStdString());

Le serveur ncs est donc maintenant autonome, Ruby est uniquement utilisé pour l’exécution du frontal web en Ruby on Rails.

Pour finir, voici un schéma du fonctionnement interne du serveur ncs.

Nodecast : backend asynchrone avec zeromq

Depuis mon dernier article sur Nodecast il y a 6 mois, de nouvelles idées ont germés qui ont données lieux à une nouvelle et sans aucun doute dernière (on y croit) réécriture du backend.

En effet dans mon dernier article je me sers d’un logiciel propriétaire pour présenter ce que je crois être l’avenir de services sur Internet via des technologies en Peer to Peer. Dans cette architecture P2P je pense que l’auto-hébergement est alors crédible car les données sont répliquées et leur accès répartie.

C’est pourquoi j’ai à nouveau réécris le backend, car dans un contexte où chaque utilisateur est encouragé à s’auto-héberger, il est nécessaire que le logiciel soit léger, simple à packager et donc avoir le moins de dépendance possible. Lorsque j’ai découvert Zeromq j’ai décidé d’implémenter avec, la gestion de la file d’attente et de répartition des jobs pour remplacer le serveur Qpid. Tous les serveurs de file comme Qpid, RabbitMQ ou Redis sont excellent dans un environnement centralisé mais sont à mon avis une contrainte s’ils sont imposés dans un environnement décentralisé ou réparti.

Zeromq me permet de migrer dans le dispatcher la gestion des files, grâce à des sockets ZMQ de type PUSH/PULL gérées dans des threads. L’usage de Zeromq est in fine plus complexe puisque plus bas niveau qu’une API fourni avec un serveur de file, mais les possibilités sont quasiment infinie, voir les différents exemples dans de nombreux langages et surtout les nombreuses spécifications de protocoles. A noter que Zeromq ne permet pas de persistance disque comme le font Qpid ou RabbitMQ, cependant une implémentation du protocole Titanic le permettrait, et il n’est sans doute pas sorcier de les ajouter en option.

A propos de la persistance des messages, tout dépend du type d’application gérée, pour un système bancaire il ne peut y avoir de perte de message bien entendu. Au contraire, il me semble avoir lu que les dev du  backend de last.fm avaient choisi une technologie sans persistance pour privilégier la performance.

Schémas

Voici le schéma de la nouvelle architecture et du dispatcher

Description

Ce schéma décrit le fonctionnement interne du processus dispatcher. Les numéros en rouge indiquent le workflow suivi par un job. Même s’il n’y a plus de serveur de file dans l’architecture nodecast, le dispatcher permet d’en conserver les propriétés grâce d’une part aux threads et aux envois non bloquant :  la directive ZMQ::NOBLOCK indique à la socket zmq de ne pas attendre de confirmation du destinataire.

  1. L’API géré par Thin (externe au processus dispatcher) réceptionne les données XML envoyées par les clients nodecast. Le serveur Thin a bindé le port 5555 local, stocke le XML dans GridFS, construit un hash et le push dans la socket ZMQ_PUSH.
  2. Le thread Zreceive est connecté sur le port 5555 via une socket ZMQ:PULL. Avec ce protocole il peut y avoir plusieurs instance du dispatcher connectés, mais un seul recevra un même job. A contrario en ZMQ PUB/SUB tous les subscribers recoivent une copie du job.
  3. Zreceive a créé un ZMQ_DEVICE. Celui-ci relie la socket ZMQ_PULL vers une socket ZMQ_PUSH. Le device transmet tout ce que reçoit la socket de PULL vers la socket de PUSH. A noter que la socket ZMQ_PUSH est ici de type ZMQ_INPROC, ce n’est donc pas une socket TCP mais une zone mémoire partagée avec une autre thread.
  4. Un thread Zdispatch est connecté en ZMQ_PULL sur la zone mémoire inproc. Il désérialize les jobs reçu dans un objet BSON puis émet un signal Qt avec la charge créée.
  5. L’objet Payload reçoit la charge dans un slot. A noter que cet objet possède à une référence vers un objet Nosql ce qui lui permet d’interroger MongoDB. Dans ce cas il est impératif que le slot Payload ne soit pas appelé alors qu’il n’a pas fini ses tâches en cours. Pour cela le QObject::connect qui relie le signal de Zdispatch avec le slot de Payload doit impérativement posséder la directive  Qt::BlockingQueuedConnection. Payload découpe la charge reçue, effectue des traitements, sérialize des objects puis emet des signaux pour chaque worker.
  6. Le thread worker_push possède un slot par signal emit par Payload. Lors de sa construction il a bindé chaque socket ZMQ_PUSH par worker. Il transmet alors la charge en mode non bloquant ZMQ_NOBLOCK.
  7. Chaque worker ZMQ_PULL sur sa socket TCP dédié. Traite puis stocke dans MongoDB.

Les cadences.

Elles rythmes le workflow, s’il n’y avait qu’une seule cadence ce backend serait synchrone. Cependant on voit très bien plusieurs.

  1. Tout d’abord le serveur Thin, qui transmet le job et retourne aussitôt une réponse au client.
  2. Ensuite le thread Zreceive, retransmet à son rythme les jobs dans une zone mémoire
  3. Le thread Zdispatch lit la zone mémoire puis faire suivre les jobs dans des signaux Qt.
  4. L’objet Payload transmet les bouts de job dans des signaux vers des slots.
  5. Le thread worker_push envoie à chaque worker sa charge
L’entrée et la sortie du dispatcher sont non bloquante. Si ce dernier plante, le serveur Thin et le worker se rendront compte de rien. De plus contrairement à un serveur classique, les sockets zeromq permettent de lancer des clients même si le serveur n’est pas lancé. Si le dispatcher tombe il pourra être relancé sans problème et les workers recevront à nouveau leur jobs.

Conclusions

L’architecture du dispatcher n’est pas encore optimisée, par exemple les positions 4, 5 et 6 pourraient fusionner. Cependant le Proof Of Concept est concluant, ce backend devrait pouvoir s’exécuter correctement sur une machine recyclée. Une dernière tâche serait de migrer le serveur Thin dans un thread en Qt afin de simplifier et optimiser encore l’architecture, ou bien d’utiliser Mongrel2 à la place de Nginx et Thin comme me le conseillait un certain Zed Shaw :)
La cible d’obtenir un backend asynchrone brokerless étant atteinte la prochaine étape est l’intégration d’un worker qui permette la synchronisation en P2P des données du backend. L’objectif est qu’une instance Nodecast se synchronise avec l’instance d’un contact de l’utilisateur. Gros travail en prespective, les solutions sont nombreuses comme telehash mais qui ne fourni pas pour l’instant d’implémentation en C/C++, ou bien la lib bitdht utilisée par entre autre par retroshare.
Bonnes vacances (ou bon courage) aux lecteurs !

aerofs , une solution de sauvegarde décentralisée

La sauvegarde est un domaine vaste et complexe qui essaye de répondre à une problématique pourtant simple, sauvegarder ses données. La difficulté qui ne saute pas forcément aux yeux de l’utilisateur lambda étant de résoudre 2 problématiques, garantir la restauration des données et garantir la confidentialité.

La restauration

La restauration dépend bien sûr du support utilisé. On est passé ces dernières années des supports physique sur bande, disque à plateaux et flash à des supports dématérialisés et hébergés sur Internet. Le principal intérêt est bien sûr de se mettre à l’abri d’une destruction ou une disparition du support physique sur des lieux non adaptés à protéger des données d’une grande valeur. L’autre avantage est d’automatiser la sauvegarde et ainsi sauvegarder plus finement l’avancée de ses travaux.

Cependant cette sauvegarde externalisée dépend elle aussi du support physique utilisé. On a supprimé les risques d’une destruction occasionnée par des locaux non adaptés (chute, vol, incendie, inondation, etc) ce qui n’est pas rien, mais quid d’un crash disque sur le serveur distant ?

Il existe d’excellentes solutions externalisées, de type Dropbox. Celle-ci utilise le cloud S3 fourni par Amazon pour stocker les données de leur utilisateur. Ce type de service est censé éviter les problématiques de gestion du stockage et de crash de disque occasionnant une perte de données. Or un récent plantage de plusieurs heures dans un datacenter d’Amazon a rendu indisponible de nombreux site web et certains auraient perdu des données, même si Dropbox n’est semble t-il pas concerné.

La confidentialité

Toujours Dropbox, ils ont récemment modifié leur CGU afin de rappeler qu’ils devaient se conformer à la législation américaine et éventuellement fournir des données de leur client sur demande de la justice. Ce type de contrainte n’est bien entendu pas spécifique à Dropbox mais à toute entreprise qui doit par définition respecter la loi de leur pays. A ce titre des entreprises qui stockent sur leur cloud des données de leur client, tel que Google, Apple, Yahoo ou Microsoft ont elles aussi cette obligation, il est bon de le rappeler.

Cela ne gênera sans doute pas ceux qui, par exemple, acceptent les caméras de surveillance partout, « du moment qu’ils n’ont rien à se reprocher », mais pour les autres il y aura sans doute une gène voir une phobie à sauvegarder ses données dans ces conditions.

Le P2P

Ces récents échec du Cloud, viennent rappeler que celui-ci ne peut être une solution pérenne ni respectueuse de la confidentialité. Ces échecs viennent rappeler que la seule architecture fiable pour les données ne peut être basée que sur la même architecture qu’Internet, le P2P. Internet est une maille composée de noeuds, car il a été intégré dès sa conception l’évidence que rien ne peut garantir définitivement l’intégrité total d’un lieu géographique ou d’un matériel. Ainsi une information atteindra sa destination selon un chemin non pas figé mais selon l’état du réseau au moment de son acheminement.

Il serait intéressant de traiter le stockage et l’accès à ses données de la même manière. A vrai dire cela existe déjà puisque le P2P répond exactement à cette problématique. Or même si celui-ci est entaché d’un usage bien souvent à des fins de contrefaçons, il n’est qu’un outil neutre.

aerofs

Pour revenir au sujet, la sauvegarde a tout intérêt à exploiter les capacités du P2P. Ainsi les données ne sont pas centralisée et elles peuvent être répliquées en de multiple endroits. La startup Air Computing Inc qui a créé le logiciel aerofs a exactement compris cela puisqu’elle fourni ce logiciel. A défaut d’avoir un équivalent libre aussi souple, j’y retrouve les avantages de Dropbox (client natif et multiplateforme), sans la centralisation qui est là optionnelle et payante au delà d’1 Go.

J’ai une instance aerofs sur quelques machines, dont un serveur dédié sur lequel est synchronisé l’ensemble des données stockées dans le logiciel. Pour résoudre la problématique de la confidentialité j’utilise l’excellent encfs qui me permet de chiffrer en userland le contenu d’un répertoire. Un simple lien Aerofs vers ce répertoire chiffré, permet de chiffrer à la volée les données reçues :   (merci à Flink pour la correction) Il suffit donc de stocker le répertoire chiffré de encfs dans Aerofs pour sauvegarder de manière répartie et sécurisée ses données.

Voici une capture de l’interface en train de synchroniser des données vers mon serveur.

Il est bien sur possible de sélectionner les répertoires à synchroniser par client, afin de ne pas stocker sur son ordinateur du boulot des données personnelles. Enfin il est possible de partager un répertoire avec d’autres utilisateurs sélectionnés.

Il existe un vote d’une demande de fonctionnalité afin de rendre l’ensemble libre : http://vote.aerofs.com/forums/67721-feature-requests/suggestions/1728653-open-source-aerofs-and-only-take-payment-for-clou?ref=title

Je pense que si aerofs n’est pas libéré, il existera un jour ou l’autre un équivalent libre, voir même un file system en P2P chiffré. Chacun stockant des morceaux de données répliquées, anonymes et chiffrées.

Pour finir je suis de plus en plus convaincu que l’avenir des applications et des données, du moins dans le Libre, utiliseront de plus en plus le P2P, comme le font Bitcoin et namecoin,  c’est tout notre intérêt et c’est le seul moyen pour lutter contre le Minitel 2.0, et contre l’hégémonie de Google qui compte bien s’étendre à toute sorte de devices : http://fr.techcrunch.com/2011/05/18/google-android-internet-des-objets/  :)