Suivez-moi aussi sur Diaspora* ou Twitter 

Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez Github (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de Github par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.

Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par Github ont pris une place considérable dans l’ingénierie logicielle ces dernières années.

Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.

1. Points critiques

1.1 La centralisation

L’application Github appartient et est gérée par une entité unique, à savoir Github, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.

De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas Github, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on est pas « dans le coup » quand on n’utilise pas Github, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).

1.2 Un logiciel privateur

Lorsque vous interagissez avec Github, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de Github on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec Github). Et surtout un outil crucial propriétaire fourni par Github qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.

1.3 L’uniformisation

Travailler via l’interface Github est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant Github comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils Github en travaillant pour une autre société. Cette fréquence de l’utilisation de Github dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.

2. Validité des points critiques

2.1 Les critiques de la centralisation

2.1.1 Taux de disponibilité du service

Comme dit précédemment, Github est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée.  Des attaques massives par dénis de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de Github elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.

2.1.2 Blocage de la construction du Logiciel Libre par réaction en chaîne

Aujourd’hui plusieurs outils de gestion des dépendances comme npm dans le monde javascript, Bundler dans le monde Ruby ou même pip pour le monde Python sont capables d’aller chercher le code source d’une application directement depuis Github. Les projets du Logiciel Libre étant de plus en plus intriqués, dépendants les uns des autres, si l’un des composants de la chaîne de construction vient à manquer, c’est toute la chaîne qui s’arrête.

Un excellent exemple de cet état de fait est la récente affaire du npmgate (voir l’article Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre). Github peut très bien demain être mis en demeure par une entreprise de retirer du code source de son dépôt, ce qui pourrait entraîner une réaction en chaîne menant à l’impossibilité de construire de nombreux projets du Logiciel Libre, comme cela vient d’arriver à la communauté Node.js à cause de la société Npm, inc. gérant l’infrastructure de l’installeur automatisé npm.

2.2 Un peu de recul historique : SourceForge

Même si l’ampleur du phénomène n’a pas été la même, il est bon de rappeler que Github n’est pas apparu ex-nihilo et avait un prédécesseur ayant joui en son temps d’un engouement important : SourceForge.

Fortement centralisé, reposant également sur de fortes interactions avec la communauté, SourceForge est un SAAS fortement vieillissant  ces dernières années et subit une véritable hémorragie de ses utilisateurs au profit de Github. Ce qui signifie beaucoup d’ennuis pour ceux qui y sont restés. Pour le projet Gimp, il s’agit tout d’abord d’abus publicitaires trompeurs indignes, qui entraînent également le départ du projet VLC , puis l’apparition d’installeurs comprenant des adwares se faisant passer pour l’installeur officiel Windows de Gimp. Et enfin purement et simplement le piratage du compte SourceForge du projet Gimp par… les équipes de SourceForge elle-même.

Nous voyons ici des exemples récents et très concrets des pratiques dont sont capables les sociétés commerciales lorsqu’elles sont sous la pression de leurs actionnaires. D’où la nécessité de bien comprendre l’enjeu représenté par le fait de leur confier une centralisation des données et des échanges ayant de fortes conséquences sur le fonctionnement et les usages de la communauté du Logiciel Libre et opensource.

 

2.3 Les critiques relatives à utiliser un logiciel privateur

2.3.1 Une communauté, différents rapports au logiciel propriétaire

Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre et opensource, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

 

Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek,  car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.

Les pendants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser Github. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.

2.3.2 Les pertes de données et obstructions liées à l’usage d’un logiciel privateur

Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de Github elle-même, l’utilisation du gestionnaire de suivi de bugs de Github pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.

Github propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de Github  ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par Github ?

L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez Github serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez Github ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de Github.

Autre perte si Github disparaît ou devient inaccessible : le travail de revue des « push requests » (abrégées par PRs) en cours. Pour les lecteurs qui ne connaîtraient pas cette fonctionnalité de Github, il s’agit d’adresser de cloner le dépôt Github d’un projet, de modifier ce clone pour l’adapter à vos besoins, puis ensuite de proposer vos modifications au dépôt d’origine. Le propriétaire du dépôt d’origine va alors étudier les modifications qui lui ont été proposées et si elles lui conviennent les fusionner à son propre dépôt. Il s’agit donc d’une fonctionnalité très importante offerte de Github, qui propose de réaliser les différentes opérations graphiquement via son interface.

Toutefois le travail de revue des modifications proposées peut être long et il est courant d’avoir, pour un projet qui marche bien, plusieurs PRs en cours. Et il est également courant d’échanger des commentaires via ces PRs et/ou via le système de suivi de bugs propriétaires de Github dont nous avons parlé plus haut.

Le code en lui-même n’est donc pas perdu si Github devient inaccessible (quoique, voire plus bas un cas spécifique), mais le travail de revue matérialisée par les éventuels demandes et commentaires présents dans les PRs et les suivis de bugs associés l’est bien, lui. Rappelons également que Github permet de cloner des projets via son interface web propriétaire, puis d’y apporter toujours via la même interface des modifications et ensuite de générer des PRs sans télécharger aucunement le code sur son poste. Dans ce cas de figure, si Github devient indisponible, la perte du code et du travail en cours est totale.

Enfin certains utilisateurs se servent de Github entre autre comme d’une application de favoris, afin de suivre l’activité de leurs projets préférés en s’abonnant à ces projets par la fonctionnalité « Watch ».  Ce travail de réunion de données pour la veille technologique est perdu  en cas d’indisponibilité du service Github.

 

2.4 L’uniformisation

La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.

Github a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.

Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur Github avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.

Et c’est bien dommage car Github, en proposant une expérience unique et originale à ses utilisateurs, taille  à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à Github d’initier à Git les nouveaux arrivants dans le développement  à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.

3. Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?

Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.

 

L’effet Github est donc délétère au point de vue des effets qu’il entraîne : la centralisation,  l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre « Cher Github… » met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de Github d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.

Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternative et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capable de programmer devrait avoir ce réflexe. Vous n’aimez pas ce qu’offre Github ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.

Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à Github et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.

Finalement, l’utilisation de Github suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec Github. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.

Texte sous licence Creative Commons CC BY-ND 3.0 FR

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Ces derniers mois j’ai pu réaliser deux salons assez intéressants : le BIG DATA PARIS et l’IOT WORLD.
Dans la première conférence, j’ai pu voir pas mal de conférences intéressantes sur les tendances actuelles :

• streaming avec Apache Spark
• kafka
• utilisation du machine learning
• …

ainsi que les use cases :

• Maintenance prédictive : Grâce au machine learning on arrive à prévoir les pannes et intervenir avant que celle-ci se déclenche. La prochaine étape sera sans doute Minority Report….
• Stockage massif des données non structurées ( IOT, logs,…) pour utilisation (marketing) et revente.

Si on exclut les éditeurs qui fournissent des solutions « clés en main ». Toutes les briques de base sont open-source. Beau pied de nez aux éditeurs qui fustigeaient les logiciels libres il y a une dizaine d’années arguant que ce modèle n’est pas viable :).

Dans la deuxième conférence, j’ai vu voir la plateforme AWS IOT. Ça claque, Amazon vend de manière très agressive une solution tout en un, de l’objet avec des kits estampillés « AWS IOT » jusqu’à la plateforme BIGDATA permettant de traiter et d’analyser ces données.

Enfin j’ai pu avoir une perspective sur le futur du marché automobile. L’UE souhaite que les véhicules deviennent connectés à partir de 2019. L’arrivée des GAFA accélère fortement le marché. Les constructeurs automobiles souhaitent changer le business model (achat –> location) et se transformer en fournisseur de données grâce à de nombreux capteurs, une puce 3G obligatoire sur chaque véhicule et près de 150To / véhicule / an. De quoi faire le business des marchands de datacenter et des équipes marketing pendant quelques années.

Outre les points positifs purement techniques que j’ai vu lors de ces conférences, j’ai pu malheureusement noter les points suivants :

L’utilisation massive du Cloud ne garantit en rien la sécurité des données. En effet, près de 30% des données sont revendus à des tiers même si on a coché la bonne case lors de la souscription du contrat.

Un exemple Amazon AWS est soumis au Patriot / Liberty Act . Je vous laisse deviner ce qui peut arriver si Airbus lâche sur le cloud Amazon les plans de ses futurs avions sur le cloud Amazon.

Aussi, les dispositifs législatifs actuels sont sous dimensionnés pour lutter contre la réutilisation frauduleuse des données. La CNIL évolue ( les amendes vont passer de 170 K€ à 4% du CA), mais les avocats qui étaient aux conférences indiquaient que passer des contrats avec des sociétés étrangères à l’UE était un risque

Enfin, on va réussir grâce au BIG DATA à corréler d’innombrables données qui permettront dans le meilleur des cas de faire pas mal d’optimisations (ex. la ville de new york), mais aussi de connaître le comportement des gens et même de le prévoir.

Tout ça pour dire qu’on va être de plus en plus fliqué. Je m’en doutais, mais c’est dorénavant pour moi une certitude. Le « BIG BROTHER » nous attend désormais au coin de la rue. Que ça soit par les états ou pire par les sociétés. Pour illustrer mon propos, et je finirai là, je pourrais prendre pour exemple les voitures connectées. Les intervenants représentant les constructeurs indiquaient que les données étaient soit-disant anonymisées mais que les forces de l’ordre pouvaient y avoir accès et qu’il pouvaient réaliser des conseils personnalisés…. Bref, ce n’est pas anonymisé pour tout le monde

Original post of Littlewing.Votez pour ce billet sur Planet Libre.

Le 18 février dernier le tribunal administratif de Paris, après avis de la Commission d’Accès aux Documents Administratifs (CADA), a rendu une décision autorisant l’accès d’un citoyen au code source d’un logiciel administratif. Génial, non ?

Non, pas vraiment, puisque dit comme ça on n’y comprend rien ! Et pourtant ce jugement pourrait avoir un grand impact sur l’avenir du libre en France et plus généralement sur la vie de tous les citoyens. On va donc essayer d’y voir plus clair.

Res Publicum, la chose publique

Pour comprendre ce qui s’est passé le 18 février dernier, il faut que je vous parle un peu des documents administratifs en France. Un document administratif c’est tout ce que peut produire une administration publique : statistiques, rapports, analyses et même logiciels.

Si certains de ces documents sont publics dès les départ (les communiqués de presse par exemple), d’autres n’ont pas forcément vocation à être rendus publics. Et pourtant la République c’est notre bien à tous (Res Publicum, ça veut dire la chose publique), tout citoyen peut donc demander à une administration de lui communiquer un document qu’elle a produit et qui n’est pas classé secret-défense, bien entendu.

Depuis 1978 une administration a même été créée pour s’occuper de cela spécifiquement, la CADA. En réalité, cette administration ne peut rendre que des avis et joue plus un rôle de médiateur entre une administration et un citoyen, mais elle reste très utile.

Un étudiant tenace…

Revenons à notre affaire. Un étudiant en économie un peu curieux a demandé en 2014 au Ministère de l’économie et des finances (Bercy) de lui transmettre le code source du logiciel de calcul de l’impôt. Un code source, c’est en quelque sorte la recette de cuisine du logiciel, ce qui permet de comprendre comment il fonctionne

Bercy a refusé et notre étudiant a alors saisi la CADA qui a dit que selon elle le code source devait être transmis. Deuxième refus de Bercy.

Notre étudiant a alors saisi le tribunal administratif de Paris pour forcer Bercy à lui remettre le document demandé. À ce moment le ministère a compris que tout cela sentait mauvais pour lui et a préféré s’exécuter avant le jugement. Malgré tout le tribunal a rendu sa décision le 10 mars dernier et a dit que l’étudiant avait raison. Victoire !

Le code source, c’est la recette de cuisine du logiciel

Maintenant vous devez vous dire, tant mieux pour cet étudiant mais concrètement ça sert à quoi ? Et c’est vrai que dit comme ça ce n’est pas très utile. Ce n’est pas parce que le code du logiciel est connu qu’il est libre et donc vous n’aurez pas le droit de modifier ou partager librement ce code. Autrement dit, on peut lire, cuisiner, mais pas gribouiller sur la recette originale, même pour y ajouter de meilleures ingrédients. En revanche vous pourrez toujours le consulter et pourquoi pas trouver des erreurs, des améliorations possibles et les proposer à Bercy qui pourrait les intégrer à son logiciel.

Imaginez un peu que vous arriviez à faire baisser le montant de vos impôts en remarquant une erreur dans le code. Pas si inutile, finalement ! En partant de cet exemple on peut imaginer beaucoup de cas où les citoyens pourraient contribuer à améliorer l’État. Prenons un exemple… Mme Dupuis-Morizeau a du temps libre et décide donc de consulter les statistiques d’accidents de la route de sa ville, qu’elle demande à la mairie. Elle remarque alors un carrefour particulièrement meurtrier, elle se rend sur place et constate que le panneau stop est caché par un buisson. Elle avertit sa mairie qui fait couper le buisson. Et voilà comment l’accès à des statistiques administratives peut sauver de vies !

La philosophie du Libre appliquée à l’État

Le problème, vous l’avez vu, c’est que demander un document administratif peut s’avérer très compliqué et que Mme Dupuis-Morizeau n’a pas forcément tout ce temps à perdre. On se dit alors que ce serait génial que tous ces documents soient librement téléchargeables sur un site internet.

Eh bien c’est exactement ce que s’est dit la ville de New-York qui publie tous les documents qu’elle produit (ou presque) sur le site https://nycopendata.socrata.com/. Depuis que la ville a adopté cette politique, des dizaines de citoyens se sont mis au travail pour créer des projets incroyables : dresser la carte des plages anormalement polluées, coder un GPS pour les ambulances en fonction des vitesses moyennes par rue pour optimiser les trajets, etc.

Voilà les avantages concrets de la philosophie du libre lorsqu’elle est appliquée à l’État. Nous pouvons tous contribuer à un fonctionnement meilleur de l’administration, ou du moins à signaler ses défauts. Rendre les documents administratifs libres, c’est faire du citoyen le réel propriétaire de l’administration qui le sert, comme nous sommes collectivement les propriétaires des logiciels libres. Beau projet non ?

 

Trois infos pour finir et approfondir le sujet si ça vous dit :

• Le code source du logiciel de calcul de l’impôt sera rendu public le 1er avril et un hackaton est organisé sur le git de Framasoft pour fêter ça. Ça se passe par ici pour les infos.
• La décision du tribunal administratif de Paris est à lire ici (attention c’est technique).
• Pour comprendre tout ce qu’a fait la ville de New-York en rendant libres ses documents vous pouvez regarder l’excellente conférence TED sur le sujet.

L’équipe du Framablog tient à remercier chaleureusement Róka, bénévole du forum des Framacolibris, pour la proposition et la rédaction de cet article !

Original post of Framablog.Votez pour ce billet sur Planet Libre.

pour lire les épisodes précédents, suivez l'étiquette correspondante

Maintenant que nous avons vu la copie de fichiers « classique » et ses défauts, abordons une technologie qui a fait beaucoup parler d'elle — et à raison — quand elle est arrivée : Jingle.

Pour la petite histoire, Jingle est une technologie qui résulte d'un effort commun entre des membres de la XSF et une équipe chez Google qui travaillait sur un protocole de voix sur IP (VoIP). La page Wikipédia retrace succinctement l'historique. La technologie Web « WebRTC » hérite et s'inspire de ce travail.

Jingle est souvent considéré à tort comme une technologie dédiée à la visioconférence. En réalité, c'est une technologie qui permet d'établir une session Pair à Pair (P2P) et de la contrôler de manière très souple. Elle a bien été pensée à l'origine pour la visioconférence, et la XEP-0167 s'appuie dessus à cet effet, mais toute application utilisant des connexions directes (et il y en a beaucoup !) peuvent profiter de Jingle : travail collaboratif, tableau blanc, jeux, chiffrement de bout en bout (en évitant ainsi le serveur), partage d'écran, etc. Nous allons nous intéresser plus particulièrement à une de ces applications : le transfert de fichiers.

Jingle fait une séparation claire entre l'application (ici le transfert de fichier), les transports (nous allons retrouver les connexions « in-band » et « SOCKS5 » mentionnées dans le dernier article), et la gestion de session.
Les applications et les transports sont décrits dans des extensions à part : la copie de fichiers est décrite dans la XEP-0234 « Jingle File Transfert ». Vous noterez qu'elle est toujours au statut « d'expérimental » : étant une pièce majeure du futur de XMPP, le travail est long pour obtenir quelque chose de solide et souple. Pour les transports, nous allons donc réutiliser les XEP-0047 et XEP-0065 décrites dans le dernier article, mais en utilisant respectivement les XEP-0261 et XEP-0260 pour les adapter à Jingle. Il faut donc utiliser pas moins de 6 XEPs pour la copie de fichiers avec Jingle (2 d'entre elles servant à la réutilisation d'anciennes), et il est probable que d'autres viennent étendre les possibilités par la suite, en particulier des nouveaux transports (*). Cela peut sembler un peu compliqué, mais c'est ce qui permet la souplesse de Jingle.

Il est possible de modifier ou remplacer à tout moment un transport ou une application, et c'est là la grande force du protocole. Une vidéo passe mal à cause d'une connexion trop faiblarde ? On change l'application pour avoir une vidéo en qualité dégradée. Une connexion SOCKS5 est impossible à établir ? On remplace le transport par un transport « in-band ». Ce dernier cas appelé « plan de secours » (fallback en anglais) était un des problèmes mentionné dans le dernier article, l'ancienne méthode n'indiquant pas comment changer de transport.

Voyons maintenant le fonctionnement. Encore une fois je ne vais pas entrer trop dans les détails, vous pouvez lire la XEP si vous souhaitez les connaître.

Une session Jingle se décide et contrôle à travers le flux XML de XMPP, pour établir une connexion P2P le plus souvent externe (c.-à-d. en dehors du flux XMPP). Une session propose des contenus (« contents »). Un contenu est composé d'une application (transfert de fichier, Vidéo via RTP, etc) et d'un transport (« in-band », « SOCKS5 », « ICE-UDP », etc). L'intérêt principal d'avoir plusieurs contenus est qu'ils sont liés dans la session : par exemple pour une visioconférence, un contenu peut s'occuper de la vidéo, et un autre de l'audio. Si un contenu dans le même logiciel mais non directement lié à la session est utilisé (par exemple un fichier est envoyé au cours de la conversation), on préférera créer une nouvelle session Jingle en parallèle plutôt qu'ajouter un contenu.

Au moment de la création de la session, nous avons 2 entités qui communiquent : l'initiateur (« initiator ») et le destinataire (« responder »). L'initiateur propose des paramètres et/ou une information pour l'application (par exemple des « codecs » pour une vidéo, ou des informations sur le fichier à transférer) ainsi que pour le transport (pour SOCKS5 les candidats par exemple). Si le destinataire accepte la session, il négocie les paramètres en retour pour l'application (par exemple les codecs proposés qu'il connaît) ou le transport (il indique ses propres candidats dans le cas de SOCKS5).

Quand la session est acceptée, elle est considérée « active », mais il n'est pas encore possible d'échanger des données pour autant : il faut d'abord terminer la négociation et accepter un transport (dans le cas de SOCKS5 ça signifie trouver le meilleur candidat, ou changer de transport, probablement pour « in-band »). Une fois tout en place on peut échanger les données, et éventuellement faire des changements en cours d'utilisation comme expliqué plus haut, ou donner des informations (par exemple indiquer qu'un correspondant a coupé le son (« mute »), ou qu'une sonnerie est en cours). Selon les applications, des cas plus compliqués peuvent apparaître, comme changer le sens de transmission de données, rediriger une session (d'un appareil vers un autre par exemple), etc.

Un autre point important avec Jingle, c'est qu'il est possible de demander une pré-condition de sécurité dans une session, par exemple on peut exiger qu'une session soit chiffrée de bout en bout.

Voici une petite liste non exhaustive des améliorations apportées par Jingle rien que pour le transfert de fichiers :

• une vraie méthode de secours (« fallback »)
• les XEP-0260 et XEP-261 adaptent les XEP-0065 et XEP-0047 en tirant vraiment profit de Jingle. Ainsi la XEP-0260 permet au destinataire de fournir ses propres candidats, s'inspirant d'une extension jamais standardisée de l'ancienne méthode (appelée « fast-mode »). C'est une grosse avancée, car dans l'ancienne méthode le destinataire doit accepter (et réussir à joindre) les candidats de l'initiateur sinon la connexion échoue. L'échec peut arriver dans de nombreux cas, et si l'initiateur n'a pas de proxy, mais le destinataire en a un, celui du destinataire ne peut pas être utilisé.
  Dans la méthode utilisée avec Jingle, le destinataire peut proposer son proxy, ou la connexion peut s'établir si l'initiateur est injoignable (derrière un NAT par exemple), mais pas le destinataire. L'échec est beaucoup plus rare
• il est possible de fournir la somme de contrôle (« hash ») quand on le souhaite, et ainsi la calculer au fur et à mesure. Avec l'ancienne méthode c'est tout au début ou rien, ce qui risque de provoquer un ralentissement avant le transfert s'il faut faire le calcul pour un gros fichier
• avec la XEP-0234, l'initiateur peut demander un fichier au destinataire, au lieu d'uniquement pouvoir lui en proposer un
• la XEP-0234 permet aussi l'ajout de fichiers en cours de session
• le chiffrement de bout en bout est possible et prévu, bien que non encore standardisé
• « ICE-TCP » est en cours de standardisation et devrait arriver cette année (*), permettant de mieux traverser les NATs

Au final, il est quasiment impossible d'échouer un transfert de fichier via Jingle. Le principal cas que je vois est si un des serveurs a une politique interdisant un tel transfert. Cependant, la solution de secours via le flux XMPP « in-band » est gourmande en ressources et très lente, c'est pourquoi il y a du travail sur de nouveaux transports comme ICE-TCP. Ces nouveaux transports serviront à toute application basée sur Jingle : réutiliser l'existant est un des gros points forts de Jingle, et de XMPP en général.

Jingle est une excellente technologie, avec un gros potentiel. Avec PubSub, c'est probablement un des gros piliers du XMPP de demain.

J'en profite pour rappeler que ce blog vient de passer de Dotclear à Salut à Toi, autrement dit il est désormais entièrement basé sur XMPP. J'ai publié une petite série d'articles expliquant la mise en place d'un blog XMPP avec Libervia, son intégration dans une configuration Apache, l'import d'un blog Dotclear et enfin la publication de billets : à lire par ici.

Pour le prochain article, je ne suis pas décidé. Il est possible que je parle de chiffrement de bout en bout vu que c'est un domaine qui bouge en ce moment, ou que je continue sur la lancée Jingle avec les dépôts de fichiers. Cependant j'ai de moins en moins de temps libre, et je préfère consacrer le peu disponible au développement de SàT, le développement de la version bureau/mobiles promise en fin d'année dernière ayant commencé.

(*) cet article ayant été rédigé il y a plusieurs semaines, entre temps la XEP en question est sortie : XEP-0371

Original post of Goffi.Votez pour ce billet sur Planet Libre.

Après avoir conseillé un client pour l'achat d'un ordinateur portable, le voilà entre mes mains pour l'installation et la configuration du système d'exploitation. Il s'agit du récent ordinateur LDLC Saturne SK1-i3, que j'ai propulsé par une distribution Debian GNU/Linux 8 « Jessie » sous Gnome 3.

Il présente les caractéristiques suivantes :

• Processeur Intel Core i3 de dernière génération (Skylake 6100U, double cœur à 2,3 GHz et 3 Mo de cache) ;
• 4 Go de mémoire vive DDR3L ;
• Disque SSD M.2 SATA de 120 Go ;
• Emplacement libre supplémentaire pour un disque 2,5" SATA de 7 mm ;
• Dalle IPS mate de 13,3 pouces en résolution Full HD 1080p ;
• Chipset graphique Intel HD Graphics 520 ;
• Châssis aluminium ;
• Ventilation silencieuse ;
• Clavier chiclet rétro-éclairé ;
• Batterie quatre cellules de 6 300 mAh ;
• Un connecteur HDMI, un port USB 3.0 réversible type C, un port USB 3.0 et un port USB 2.0 classiques ;
• Wi-Fi AC et Bluetooth 4.0 ;
• Un lecteur de cartes mémoire SD et MMC ;
• Deux haut-parleurs stéréo ;
• Une prise combinée entrée audio et sortie casque ;
• Webcam 1 Mpx et micro intégrés ;
• Poids de 1,4 kg.

Fiche produit LDLC : www.ldlc.com/fiche/PB00204354.html

L'emballage du colis est exemplaire. Un grand carton en protège un second enroulé dans un film à grosses bulles, qui contient à son tour une valise cartonnée contenant l'ordinateur ; lequel est calé dans de la mousse rigide. Deux CD de pilotes sont fournis pour Windows 7, 8 et 10, ainsi qu'un support métallique avec vis pour ajouter un disque 2,5" supplémentaire.

L'ordinateur est fin, robuste et joli ; le châssis aluminium est une réussite. Le clavier est de bonne qualité, et son rétro-éclairage un vrai plus. Ce dernier dispose de deux niveaux d'intensité et peut également être éteint. Le large pavé tactile est agréable. On peut cliquer en le tapotant, mais le bas du pavé peut aussi être pressé pour cela. L'écran mat est plutôt chouette, le SSD d'une vivacité redoutable, le tout dans un silence absolu. Même le son n'est pas mauvais !

Néanmoins, les touches des flèches haut et bas, se partageant la place d'une seule, sont vraiment petites. Par ailleurs, il n'y a pas de diode indiquant l'état de la touche Caps Lock.

Il est nécessaire de désactiver le Secure Boot pour installer Debian. Il est également nécessaire de disposer du paquet de pilotes logiciels non-libres firmware-iwlwifi sur une clef USB afin de pouvoir utiliser le wifi dès l'installation. Il s'agit du seul paquet non-libre requis à l'usage de cet ordinateur sous GNU/Linux. Néanmoins, une fois l'installation réalisée, le support matériel n'est pas idéal. Notamment, les touches de raccourcis ne fonctionnent pas et l'écran est mal reconnu. L'ensemble des problèmes rencontrés provient du mauvais support de la plateforme Intel Skylake, récente, par le noyau Linux 3.16, plus ancien. Pour résoudre cela, il suffit d'activer les dépôts jessie-backports afin d'installer le noyau 4.4 (ainsi que le paquet firmware-iwlwifi rétro-porté). Ainsi, tout fonctionne parfaitement !

La résolution de 1080p est peut-être un peu excessive pour un écran de 13,3 pouces. Elle peut être abaissée pour plus de confort.

À noter que l'arrière du châssis semble facilement démontable pour accéder à la carte mère et ses composants.

Cet ordinateur me plaît beaucoup ! Je le garderais d'ailleurs bien pour moi...

Original post of Cyprien Pouzenc.Votez pour ce billet sur Planet Libre.