La fondation GNOME vient d’annoncer la première édition de la conférence Libre Application Summit, qui se tiendra du 19 au 23 septembre à Portland, dans l’Oregon. Cette dernière devant permettre d’accroître l’écosystème d’applications GNU/Linux en améliorant la collaboration entre le noyau Linux et les principales distributions, ainsi qu’en attirant les développeurs d’applications, aussi bien chez les indépendants que chez les gros éditeurs.

Un panel varié de participants y est attendu, que ce soit des développeurs du noyau, de distributions, des fabricants de matériel, des développeurs de pilotes de périphériques, d’applications ou de jeux vidéos (aussi bien libres que propriétaires), dans le but de pouvoir échanger plus facilement, voir quelles sont les problématiques respectives rencontrées et ce qui pourrait être fait pour y remédier (meilleure documentation, création de meilleurs outils de développement, amélioration de l’expérience, aussi bien pour les utilisateurs que pour les développeurs…).

De nombreuses conférences auront lieues, traitant aussi bien de l’écosystème (questions commerciales, juridiques, sociales, communautaires), que de la plateforme (matériel, pilotes, outils), de la distribution (collaboration entre les distributions, l’assurance qualité, l’intégration continue), ou du développement (les toolkits, X / Wayland, la sécurité, les SDK, les différents outils).

Je pense sincèrement que ce type de rencontre manquait cruellement, et il n’y plus qu’à espérer que cette première édition soit un succès, histoire de pouvoir aider à rendre notre plateforme bien plus attractive pour les développeurs, et par ricochet, les utilisateurs.

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

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

GNOME MPV, l’interface graphique en GTK+ au lecteur multimédia mpv, vient de sortir une nouvelle version. Malheureusement, il n’existe toujours pas de liste claire des différentes nouveautés, ce qui oblige à parcourir la longue liste des différents commits pour en avoir une vague idée. Et puisque ça faisait longtemps que je n’avais pas parlé de cette application, j’en ai profité pour remonter jusqu’à la version 0.6 sortie en octobre 2015.

Le gros des modifications concerne de nombreuses corrections de bugs, dont plusieurs causes de plantages, la compatibilité avec mpv ou la prise en compte des dernières possibilités offertes par GTK+. Au niveau des nouveautés directement visibles par l’utilisateur, nous retiendrons :

• l’apparition d’un nouvel onglet dans les préférences pour pouvoir ajouter facilement des scripts Lua
• l’ajout de nouvelles options telles que la possibilité de se souvenir du chemin du dernier fichier ouvert ou le fait de pouvoir lire la liste de lecture en boucle
• la possibilité de pouvoir faire plus de glisser-déposer (chargement de sous-titres, ajout de fichiers à la liste de lecture…)
• la possibilité de pouvoir sélectionner plus facilement les sous-titres ou les pistes audio et vidéo quand le média en propose plusieurs
• l’ajout d’une fenêtre des raccourcis clavier
• l’ajout d’un fichier AppData pour que l’application puisse apparaître dans les différentes logithèques
• la désactivation du bouton de contrôle du volume quand le média ne comporte aucune piste audio
• l’ajout d’une icône symbolique
• la sauvegarde de l’état du volume sonore entre deux sessions
• une meilleure prise en charge de Wayland et de MPRIS

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

A l'heure actuelle, j'écris sur ce blog, relayé par ces deux planets et parfois par le journal du hacker (jdh) pour lequel j'ai un peu contribué. Deux article récents, un premier par un contributeur du jdh et un second par un contributeur du planet-libre. pose des analyses quant à l'avenir des planets, ces sites relayant par le biais de flux rss, des articles de blog.

L'un des constats serait une baisse du nombres des blogs et des articles publiés, et donc de l'intérêt des planets. J'ai bien vu ces deux articles, et j'y avais donc réfléchi sans prendre la peine de l'écrire. Je le fais donc maintenant suite à une invitation indirecte.

Les blogs ont-ils un avenir ?

Sur l'intérêt des blogs, ça me semble essentiel. C'est ce qui fait partie de la culture Hacker, avec les wikis pour documenter ce que l'on fait. En deux mots, le terme Hacker recouvre ici toute personne ayant une activité de détournement d'objet afin de résoudre des problèmes pour lesquels ils ne sont pas destinés ainsi que la construction de l'informatique avec l'esprit du logiciel libre. Sans prétention aucune, c'est pour cela que j'ai les deux formes (blog.sciunto.org et share.sciunto.org). Le blog est en français (pour l'instant), le wiki en anglais. Ces deux formes sont complémentaires, l'un formant un carnet de bord, l'autre une documentation plus pérenne.

 L'intérêt des planets

L'intérêt d'un planet est de mettre en valeur les activités des acteurs d'un domaine. Le fait qu'il y ait plusieurs planets n'est donc que la conséquence de l'existence de divers groupes qui se chevauchent. Il reste selon moi un formidable tremplin pour communiquer. La duplication des articles pour certains lecteurs n'est selon moi pas un problème majeur. Je peux très bien suivre le planet-python mais pas le planet-debian et pour autant être intéressé par un article python appliqué à debian.

 Le relais ou la communication par les réseaux sociaux

Je ne suis pas adepte des réseaux sociaux. Les modèles de type facebook enferment les données et espionnent les activités. Je n'ai aucune idée de ce qui peut se dire sur ces réseaux. Le modèle me semble contraire à mon éthique, je n'y vais donc pas. Les modèles de type twitter sont ouverts, mais ont un ratio signal/bruit très souvent faible. De plus, mon observation me pousse à conclure que cette outil donne une illusion de visibilité : un buzz chez les convaincus, mais invisible au delà..

Le journal du hacker

Le modèle du jdh a des intérêts mais aussi des défauts selon moi. Déjà, je tiens à saluer l'initiative parce que c'est une belle façon de partager de l'information avec un outil intéressant. Par contre, je déplore la ligne éditoriale.

Trop d'articles bas de gamme sont relayés, notamment avec des sites professionnels qui ont pignon sur le web, dont les articles sont en carton : du journalisme classique se contentant de relayer de l'information avec de l'enrobage, des titres accrocheurs et une réflexion au degré zéro de la pensée.

L'autre problème est qu'il n'y a que quelques contributeurs qui publient beaucoup. La diversité n'est pas au rendez-vous et en postant des liens à tour de bras, on n'a pas une sélection d'articles qui ont ce quelque chose qui les rendent uniques. En effet, à chaque lien posté, il n'y a que rarement une justification de l'intérêt du lien. Les discussions sont par ailleurs quasi inexistantes contrairement à hacker news dont le jdh est un clone francophone libre. Donc, le jdh devient un planet bis avec, en plus, des articles moins intéressants à mes yeux. J'en suis venu à filtrer les noms de domaines pour faire une pré-sélection drastique.

Enfin, dernier point, dans jdh (journal du hacker), il y a hacker, et je vois trop peu de choses sur la bidouille d'objets physiques (contrairement à Hackaday), ce qui est bien dommage.

Vers un idéal ?

Hackaday représente selon moi un modèle de ligne éditoriale et s'il y avait quelque chose à reprendre, ce serait bien cette forme là, mais avec une meilleure répartition entre "software" et "hardware". Ils sont d'avantage dans un modèle où ce sont des lecteurs ou des rédacteurs qui viennent proposer leurs articles en plus de la veille de leurs contributeurs. Si une page est intéressante, un petit laïus avec éventuellement une photo ou vidéo est rédigé, avec parfois des liens vers des articles antérieurs publiés sur hackaday. A ma connaissance, ceci n'existe pas en français et il est évident que ça demanderait de l'énergie à construire une solution similaire.

Original post of François Boulogne.Votez pour ce billet sur Planet Libre.

Jdh : Bonjour Tarek et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Tarek : Je suis développeur depuis une quinzaine d'années et je me suis spécialisé dans le langage Python il y a un peu plus de dix ans.

Je me suis passionné pour l'open source et pour Zope en particulier et j'ai lancé un site web autour de cette techno à l'époque. Avec quelques compères du forum de Zopeur, nous avons fondé l'Afpy (Association Python Francophone).

J'ai aussi écrit trois livres sur Python dont un en Anglais.

Je bosse depuis plus de 5 ans pour Mozilla où j'anime une petite équipe qui écrit des services webs.

Jdh : Tu viens d'évoquer Zope, que les anciens de la communauté Python connaissent bien. Quand et comment as-tu commencé à coder avec Python ?

Tarek : J'ai découvert Zope et Python à peu prêt en même temps. C'est en codant des petites fonctions dans l'admin Zope que je me suis mis à Python sérieusement, il y a plus de 10 ans.

Jdh : Et tu as apparemment pris goût à Python ! Je t'ai découvert grâce à ton excellent livre "Programmation Python - syntaxe, conception et optimisation" à l'époque. Peux-tu nous en dire un peu plus sur ce qui t'a amené à passer du statut de développeur à auteur ?

Tarek : C'est simple : je suis devenu fan de Python et j'ai eu envie de le maitriser au maximum.

Et écrire un livre est la meilleure des techniques : il faut bien maitriser chaque sujet pour pouvoir l'expliquer aux autres.

Ça a été un travail intense de 9 mois. J'y ai passé toutes mes soirées :)

Jdh : Lorsque nous nous sommes connus, tu étais très impliqué dans le développement de certains modules de la bibliothèque standard de Python, en particulier je me souviens de Distutils. Qu'en est-il aujourd'hui de ton implication dans le développement de Python ?

Tarek : J'ai beaucoup travaillé sur Disutils effectivement, car le packaging dans Python souffrait de gros problèmes et personne n'avait envie de s'y coller.

Le plus gros travail a été politique : écrire des PEP (Python Enhancement Proposals) pour faire avancer les standards en mettant tout le monde d'accord, puis un peu de code. Je me suis un peu trop impliqué pendant 2 ans sur le sujet et j'ai vécu un "burnout" le jour où mon travail sur un nouvel outil (Disutils2) qui devait être intégré à la bibliothèque standard a été retiré au dernier moment. Je l'ai mal vécu haha.

Tout ce travail a quand même porté ses fruits puisque le packaging s'améliore grandement et il y a pas mal de choses qui sont issues de mon travail. Certaines parties de Disutils2 ont été recyclés dans d'autres projets aussi.

Un conseil: ne tombez pas dans le piège de comparer le packaging de Python avec ceux très récents comme npm (node) ou cabal (haskell) ou même Debian, et de dire que "le packaging est un problème résolu depuis longtemps", Python est un papy de plus de 20 ans et tout le drame du packaging est pouvoir difficilement faire table rase de l'existant, surtout dans un éco-système où cohabitent des communautés très différentes. Si vous parlez de packaging avec la communauté scientifique ou avec la communauté web, ce sont deux monde tellement différents qu'il est très dur de trouver des solutions universelles et respectueuses de l'existant.

Aujourd'hui je ne suis plus du tout impliqué dans le développement de Python. Ça prend trop de temps et d’énergie, que je préfère garder pour aller courir ou jouer de la trompette. Mon combat dans le code est maintenant à Mozilla :)

Jdh : La fondation Mozilla et ses projets passionnent les membres de notre communauté. Peux-tu un peu nous décrire quels sont tes projets techniques pour la fondation et ta façon de travailler chez Mozilla ? Lors de notre dernière rencontre tu vivais dans un petit village assez isolé des grands centres urbains.

Tarek : Je bosse pour Mozilla Corporation, qui est financée et dirigée à 100% par Mozilla Foundation, et qui a des salariés dans de nombreux pays. La Foundation en a aussi, distinctement de la Corporation.

Quand je suis arrivé il y a plus de 5 ans chez Mozilla, ma mission était simple : j'étais le premier développeur Python de l'équipe "Services" et mon job a consisté à porter Firefox Sync (alors en PHP) sous Python et mettre en place tout l'éco-système Python.

J'étais le seul européen de l'équipe, et je devais faire des réunions parfois à 2 heures du mat'. À l'époque Mozilla Corp. comptait autour de 350 salariés.

Tout a évolué et s'est structuré, et en 2016 on dépasse les 1000 employés avec beaucoup plus de monde en France (environ 45), et je suis maintenant "engineer manager" d'une équipe de Français dispatchés entre Rennes, Barcelone et Montpellier. Moi-même je suis dans un tout petit bled en Bourgogne (175 habitants).

On travaille en ce moment sur Kinto un service de stockage de données avec une API HTTP Json, écrite en Python avec Pyramid, Cornice et Cliquet. Je ne développe plus trop, je passe plus de temps dans des réunions et dans la gestion des projets Mozilla basés sur Kinto, et sur les échanges techniques avec les gens de mon équipe.

Bosser chez Mozilla est assez confortable en termes de moyens à notre disposition : on peut se rencontrer plusieurs fois par an pour faire des "work weeks", disposer de toutes les ressources nécessaires en ligne (serveurs virtuels etc).

Le seul regret de vivre à la campagne finalement est que ma connexion ADSL est mauvaise, ce qui est pénible pour les vidéoconférences.

Jdh : Peux-tu nous détailler un peu plus les projets sur lesquels tu as travaillé et travaille actuellement pour Mozilla ?

Tarek : En 6 ans de temps j'ai eu le temps de bosser sur beaucoup de projets à Mozilla.

Les plus intéressants :

• Firefox Sync : J'ai réecris le serveur PHP en Python, en utilisant Gevent
• Circus : Un gestionnaire de processus
• Cornice : une surcouche de Pyramid pour écrire des web services
• Loads : Un outil de load testing distribué

Et plus récemment, Kinto, un service de stockage JSON. Je ne développe quasiment pas dedans vu que j'ai changé de casquette (manager) mais je m'occupe de son intégration au sein de Mozilla pour nos différents besoins.

Kinto est maintenant utilisé par Firefox pour la mise à jour de données régulières. L'idée est de réussir à mettre à jour des informations importantes comme les révocations de certificats, sans avoir à attendre que la prochaine version de Firefox sorte.

Jdh : Firefox Sync est utilisé par le grand public et est donc un projet très visible. On a du mal à imaginer l'ampleur de l'investissement derrière. Peux-tu nous parler un peu des gens et de l'infrastructure derrière une fonctionnalité comme celle-ci ?

Tarek : La partie service web en Python est assez anecdotique, au départ j'étais tout seul à coder dessus. C'est quelques milliers de lignes tout au plus.

Le service web en Python, c'est l'arbre qui cache la forêt, 5% du temps de la requête. La difficulté de ce système est surtout liée à la base de données :

• la maintenance de plusieurs centaines de serveurs MySQL
• le sharding des utilisateurs sur toutes ces bases
• la gestion des migrations des utilisateurs etc

Il y a 6 ans nous étions déployés dans des datacenters et il fallait tout gérer nous-même, par exemple le remplacement des disques durs.

Aujourd'hui tout est déployé sur des services clouds comme AWS. Et c'est le cas pour Kinto : des web heads à la demande et Postgres RDS.

En terme de tests, mon équipe est fière d'avoir un coverage de 100% partout, et nous avons des batteries de tests d’intégration qui se lancent sur Travis-CI

Nous avons un environnement de staging sur lequel nous déployons les nouvelles versions, et une équipe de QA qui se charge de recetter le tout avant de nous donner le feu vert. L'équipe de Ops utilise Puppet pour tous nos déploiements.

Jdh : Kinto et Circus ont chacun plus de 1000 étoiles Github, avec un nombre de rapports de bugs importants, ce qui en fait des projets assez populaires. Comment se partage la journée type d'un développeur Mozilla ? Y'a-t-il une répartition du travail entre ce qui est fait pour la communauté directement et pour l'infrastructure Mozilla ? Les deux sont-ils confondus en permanence ?

Tarek : C'est une excellente question. Mon job principal justement, en tant que engineering manager, est de faire converger les besoins de Mozilla avec l'envie de développer des fonctionnalités qui sont utiles à une communauté plus large.

Le principe de base est que chaque grosse fonctionnalité que l'on ajoute dans les projets doit émaner d'un besoin réel dans l'un des projets internes - sans pour autant rendre le projet spécifique à Mozilla.

La signature des données dans Kinto est un bon exemple : nous devons signer toutes les données qui sont envoyées à Firefox pour éviter au cas où notre serveur Kinto serait piraté de servir des données corrompues. Ce serait par exemple la catastrophe pour les certificats SSL.

Cette fonctionnalité a été créée sous forme de plugin optionnel en se basant sur des standards ouverts et un système de configuration complet. En d'autres termes, on peut plugger cette option sur nos serveurs à Mozilla sans l'imposer aux autres utilisateurs de Kinto, mais si une autre organisation veut plugger le système de signature, elle pourra le faire !

L'équipe passe bien sûr un peu de temps sur des fonctionnalités 100% communautaires, qui ne sont pas utilisées à Mozilla - mais ce n'est pas la priorité - même si ce n'est jamais du temps perdu.

Le travail sur les bugfixes et push requests (PR) remontés par la communauté quant à lui, est en général fait rapidement : c'est un cadeau précieux qui nous est fait et il est important de ne pas laisser traîner ce travail - ne serait-ce que par respect pour la personne qui a passé du temps dessus.

Enfin, certains projets peuvent à un certain moment être moins utilisés chez nous, et peuvent continuer à vivre. Circus par exemple est moins utilisé qu'avant, et le projet est maintenu par des gens comme Yannick Péroux qui ne bosse pas à Mozilla, c'est génial ! C'est pour moi un exemple de réussite du modèle open source.

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.