Agrégateur de flux

G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! »

Linux France - il y a 11 heures 2 min

L’équipe IMAGE du GREYC est heureuse de pouvoir fêter avec vous les 10 années d'existence du logiciel G’MIC, son cadriciel libre (sous licence CeCILL), générique et extensible pour le traitement des images.
Le GREYC est un laboratoire de recherche publique en sciences du numérique, situé à Caen en Normandie, et chapeauté par trois tutelles : le CNRS (UMR 6072), l’Université de Caen, et l’ENSICAEN.


G’MIC-Qt, l’interface utilisateur principale du projet libre G’MIC.

Cet anniversaire décennal nous donne l'occasion rêvée, d'une part, d'annoncer la sortie d'une nouvelle version de ce logiciel libre (numérotée 2.3.4), et d'autre part, de partager avec vous (comme à notre habitude) un résumé des dernières fonctionnalités notables ajoutées depuis la dernière dépêche sur G'MIC, publiée sur LinuxFr.org en février 2018.

Sommaire

N. D. A. : Cliquez sur les images de la dépêche pour en visualiser des versions à meilleure résolution.

1. Retour sur dix années de développement

G’MIC est un logiciel multi‐plate‐forme (GNU/Linux, macOS, Windows…) fournissant différentes interfaces utilisateur pour la manipulation de données images génériques, à savoir des images ou des séquences d’images hyperspectrales 2D ou 3D à valeurs flottantes (incluant donc les images couleur « classiques »). Plus de 1000 opérateurs différents de traitement d’images sont inclus, nombre extensible à l'envi puisque les utilisateurs peuvent ajouter leurs propres fonctionnalités via l’utilisation d'un langage de script intégré.

C'est fin juillet 2008, que les premières lignes de G'MIC sont rédigées (en C++).
À l'époque, j'étais le principal développeur impliqué dans CImg, une bibliothèque C++ open-source légère pour le traitement d'images, et je réalisais le constat suivant :

  • L'objectif initial de CImg, qui était de proposer une bibliothèque « minimale » de fonctionnalités pour aider les développeurs C++ à élaborer des algorithmes autour du traitement d'images, était globalement atteint : La plupart des algorithmes que je considérais comme « essentiels » en traitement d'images y étaient intégrés. CImg était initialement conçue comme devant rester légère, et je ne souhaitais donc pas y inclure ad vitam æternam de nouveaux algorithmes, qui seraient trop lourds ou trop spécifiques et qui trahiraient le concept initial de la bibliothèque.
  • Cette satisfaction faisait néanmoins place à une certaine déception. Quel dommage de n'avoir pu toucher qu'un public finalement assez restreint, possédant à la fois des connaissances en C++ et en traitement d'images ! Une des évolutions naturelles du projet, consistant à créer des bindings de CImg pour d'autres langages de programmation, ne m'ouvrait pas de perspectives très réjouissantes, du point de vue de l'intérêt que j'y trouvais en développement informatique. Sans compter que ces bindings potentiels ne concernerait là encore qu'un public ayant une expertise en développement.

Mon envie prenait donc progressivement forme : il fallait proposer un moyen d'utiliser les fonctionnalités de traitement d'images de CImg pour les non-programmeurs. Et pourquoi pas, dans un premier temps, en élaborant un outil utilisable en ligne de commande (à la façon du fameux convert de ImageMagick) ? Une première tentative, en juin 2008 (inrcast, qui avait été présentée dans ce journal LinuxFr), se révéla infructueuse mais me permit de mieux cerner les spécificités que se devait de posséder ce genre d'outils, pour traiter confortablement des images en ligne de commande.
Il m'apparut en particulier que la concision et la cohérence de la syntaxe commandant l'outil devaient être les deux piliers principaux sur lesquels il fallait se reposer. Ces aspects sont ceux qui m'ont demandé le plus d'efforts en recherche et développement (les fonctionnalités de traitement d'images proprement dites étant déjà implémentées dans CImg). En fin de compte, cela m'amènera bien plus loin que ce qui était prévu initialement, puisque G'MIC se dotera successivement d'un interpréteur de son propre langage de script, puis d'un compilateur JIT pour l'évaluation d'expressions mathématiques et d'algorithmes de traitement d'images travaillant au niveau pixel.

Fin juillet 2008, je me mettais donc au travail avec les idées (presque) claires, et étais heureux d'annoncer ici même, quelques jours plus tard, la sortie d'une première ébauche de G'MIC. Le projet était officiellement en marche !


Fig. 1.1 : Logo du projet G’MIC, cadriciel libre pour le traitement d’images, et sa mignonne petite mascotte « Gmicky » (illustrée par David Revoy).

Quelques mois plus tard, en janvier 2009, enrichi par mon expérience précédente de développement du logiciel GREYCstoration (outil libre pour le débruitage et l'interpolation non-linéaire d'images, dont un greffon existait pour GIMP), et dans l'espoir de toucher un public encore plus large, je diffusais une version de G'MIC se déclinant sous forme d'un greffon GTK pour GIMP.
Cette étape s'est avérée déterminante pour le projet G'MIC, le faisant passer de hautement confidentiel à doucement populaire :), comme l'illustre le saut significatif visible dans les statistiques de téléchargements mensuels de l'époque, présentés ci-dessous (le projet était alors hébergé sur Sourceforge).


Fig.1.2 : Statistiques de téléchargement mensuels de G’MIC, entre juillet 2008 et mai 2009 (arrivée du greffon pour GIMP en janvier 2009).

Cet intérêt soudain pour le greffon de la part d'utilisateurs différents de GIMP (photographes, illustrateurs, et autres artistes en tout genre…) fût en effet une vraie rampe de lancement pour le projet, avec l'apparition rapide de contributions et suggestions extérieures diverses et variées (pour le code, la gestion des forums, des pages web, l'écriture de tutoriels, la réalisation de vidéos…). L'effet communautaire bénéfique du logiciel libre, souvent idéalisé, survenait finalement assez rapidement ! Avec aussi pour conséquence d'amener certains utilisateurs-développeurs à s'intéresser plus en détail au fonctionnement de l'interface originelle en ligne de commande et à son langage de script associé (qui n'intéressait pas grand monde jusque-là, il faut bien l'avouer !). De là, plusieurs d'entre eux franchirent le pas et commencèrent à élaborer et implémenter de nouveaux filtres de traitement d'images en langage G'MIC, intégrés progressivement au greffon pour GIMP (aujourd'hui, ces contributions représentent quasiment la moitié des filtres disponibles dans le greffon).

En parallèle, les apports importants et répétés de Sébastien Fourey, collègue de l'équipe IMAGE du GREYC (et développeur C++ chevronné s'il en est) ont permis d'améliorer significativement le confort d'utilisation de G'MIC. Sébastien est en effet à l'origine du développement des interfaces graphiques principales du projet, à savoir :

  • Le service web G'MIC Online (qui a plus tard été ré-organisé par le service « développement » du GREYC).
  • Le logiciel libre ZArt, une interface graphique, basé sur la bibliothèque Qt, pour l'application de filtres G'MIC sur des séquences vidéos (provenant de fichiers ou de flux de caméras numériques).
  • Et surtout, Sébastien s'est attaqué, fin 2016, à la ré-écriture complète du greffon G'MIC pour GIMP sous une forme plus générique, dénommée G'MIC-Qt. Ce composant, basé également sur la bibliothèque Qt (comme son nom l'indique), se présente sous la forme d'un greffon unique qui fonctionne de manière équivalente sous GIMP et Krita, deux des logiciels libres de référence pour la retouche photographique et la peinture numérique. G'MIC-Qt a aujourd'hui complètement supplanté le greffon GTK d'origine grâce à ses nombreuses fonctionnalités : moteur de recherche de filtres intégré, meilleure prévisualisation, interactivité supérieure, etc. C'est aujourd'hui l'interface la plus aboutie et la plus utilisée du projet G'MIC, et nous espérons d'ailleurs pouvoir la décliner dans le futur pour d'autres logiciels hôtes (contactez-nous si vous êtes intéressés à ce sujet !).


Fig.1.3 : Différentes interfaces graphiques du projet G'MIC, développées par Sébastien Fourey: G'MIC-Qt, G'MIC Online et ZArt.

L'idée de cette dépêche n'étant pas de rentrer trop en détails dans l'historique du projet, affirmons simplement que l'on n'a pas vraiment eu le temps de s'ennuyer ces dix dernières années !
Aujourd'hui, Sébastien et moi-même sommes les deux mainteneurs principaux du projet G'MIC (Sébastien, majoritairement pour ce qui concerne les aspects « interface », et moi-même pour le développement et l'amélioration des filtres et du cœur de calcul), ceci, en complément de notre activité professionnelle principale (la recherche et l'enseignement/encadrement).

Avouons-le, gérer un projet libre comme G'MIC prend un temps considérable, malgré sa taille modeste ( ≈ 120klocs). Mais l'objectif de départ a été atteint : des milliers d'utilisateurs non-programmeurs ont l'occasion d'utiliser librement et aisément nos algorithmes de traitement d'images, et ce, dans de nombreux domaines différents : retouche photographique, illustration et peinture numérique, traitement vidéo, illustration scientifique, génération procédurale, glitch art….
La barre des 3.5 millions de téléchargements totaux a été dépassée l'an dernier, avec une moyenne actuelle d'environ 400 téléchargements journaliers effectués depuis le site officiel (chiffres en baisse constante depuis quelques années car G'MIC est de plus en plus téléchargé et installé via des sources alternatives extérieures).
Il est parfois difficile de garder un rythme soutenu de développement et la motivation qui doit aller avec, mais on s'accroche, en repensant aux utilisateurs heureux qui partagent de temps à autre leur enthousiasme pour ce projet !

On ne peut évidemment pas nommer tous les particuliers, contributeurs à G'MIC, que l'on souhaiterait remercier, et avec qui on s'est régalé à échanger durant ces dix années, mais le cœur y est ! Remercions également le laboratoire GREYC et l'institut INS2I du CNRS qui affichent un fort soutien à ce projet libre. Un grand merci également à l'équipe de LinuxFr.org qui n'a pas rechigné à relire et publier nos propositions régulières de dépêches sur G'MIC ;).

Mais cessons de ressasser de vieux souvenirs, et passons maintenant aux choses sérieuses : les nouveautés apparues depuis la dernière version majeure 2.2 !

2. Illumination automatique de dessins colorisés en aplats

G'MIC s'est récemment doté d'un filtre assez étonnant, nommé « Illuminate 2D shape », dont l'objectif est d'ajouter automatiquement des zones d'illumination et des ombres propres sur des dessins 2D colorisés en aplats, pour leur donner un aspect 3D.

Dans un premier temps, l'utilisateur fournit un objet à illuminer, sous la forme d'une image sur fond transparent (typiquement un dessin de personnage, ou d'animal). En analysant la forme et le contenu de l'image, G'MIC tente alors d'en déduire une carte d'élévations 3D concordante (« bumpmap »). La carte d'élévations obtenue est évidemment non-exacte, puisqu'un dessin 2D colorisé en aplats ne contient pas d'informations franchement explicites sur sa structure 3D associée ! À partir des élévations 3D estimées, il est aisé d'en déduire une carte de normales (« normalmap ») qui est utilisée dans un second temps pour générer un calque d'illumination associé au dessin (suivant un modèle d'ombrage de Phong).


Fig. 2.1 : Le filtre « Illuminate 2D shape » de G'MIC en action, pour ombrer un dessin de scarabée (résultat d'ombrage à droite).

Ce nouveau filtre est très flexible et permet à l'utilisateur d'avoir un contrôle assez fin sur les paramètres d'éclairage (position et type de rendu de la source lumineuse), et d'estimation des élévations 3D. Par ailleurs, le filtre laisse à l'artiste le loisir de retravailler le calque d'illumination généré, ou même directement les cartes d'élévations et de normales 3D estimées. La figure ci-dessous illustre le processus dans son ensemble : à partir de l'image de scarabée colorisé en aplats (en haut à gauche), le filtre estime de manière complètement automatique une carte de normales 3D associée (en haut à droite), ce qui lui permet de générer des rendus d'illumination du dessin (ligne du bas, avec deux styles de rendus différents : lisse et quantifié).


Fig. 2.2 : Le fonctionnement du filtre « Illuminate 2D shape » de G'MIC passe par l'estimation d'une carte de normales 3D pour générer l'illumination automatique d'un dessin.

Malgré la difficulté inhérente au problème de conversion d'une image 2D en informations d'élévations 3D, l'algorithme utilisé s'avère étonnamment efficace dans pas mal de cas, l'estimation de la carte d'élévations 3D obtenue étant suffisamment cohérente pour générer automatiquement des illuminations de dessin 2D plausibles, comme illustré par les deux exemples ci-dessous, obtenus en quelques clics seulement !



Fig. 2.3 : Deux exemples d'illuminations complètement automatiques de dessins 2D, générés par G'MIC.

Il arrive, bien sûr, que la carte d'élévations 3D estimée ne corresponde pas tout à fait à ce que l'on pourrait souhaiter. Qu'à cela ne tienne, le filtre permet à l'utilisateur de fournir des « guides », sous la forme d'un calque additionnel composé de traits colorés, donnant des informations plus précises à l'algorithme sur la structure du dessin à analyser. La figure ci-dessous illustre l'utilité de ces guides pour un exemple d'illumination d'un dessin d'une main (en haut à gauche) : l'illumination obtenue de manière complètement automatique (en haut à droite) ne prend pas en compte les informations de lignes de la main. Inclure ces quelques lignes dans un calque additionnel de « guides » (en rouge, en bas à gauche) permet d'aider l'algorithme à illuminer le dessin de manière plus satisfaisante.


Fig. 2.4 : Utilisation d'un calque de « guides » pour améliorer le rendu d'illumination automatique généré par G'MIC.

Si on analyse plus précisément les différences obtenues entre les cartes d'élévations 3D estimées avec et sans « guides » (illustrées ci-dessous sous forme d'objets 3D symétrisés), il n'y a pas photo : On passe d'une grosse moufle boudinée à une estimation 3D de main nettement plus détaillée !


Fig. 2.5 : Élévations 3D estimées pour le dessin précédent de la main, avec et sans utilisation de « guides ».

Notons pour finir que ce filtre dispose également d'un mode de pré-visualisation interactif, permettant à l'utilisateur de faire bouger la source lumineuse (à la souris) et d'avoir un aperçu du dessin illuminé en temps réel. En modifiant les paramètres de position de la source lumineuse, il est ainsi possible d'obtenir le type d'animations ci-dessous en très peu de temps, qui donne une idée assez précise de la structure 3D estimée par l'algorithme à partir du dessin d'origine.

Fig. 2.6 : Modification de la position de la source lumineuse et rendus d'illumination associés, calculés de manière automatique par G'MIC.

Une vidéo montrant les différentes possibilités d'édition de l'illumination permises par ce filtre est visible ici. Espérons que cette nouvelle fonctionnalité de G'MIC permette aux artistes d'accélérer l'étape d'illumination et d'ombrage de leurs futurs dessins !

3. Projection stéréographique

Dans un tout autre genre, nous avons également ajouté à G'MIC un filtre implémentant la projection stéréographique, très précisément nommé « Stereographic projection ». Ce type de projection cartographique permet de projeter des données images définies sur une sphère, sur un plan. Il faut savoir que c'est la projection usuelle utilisée pour générer des images de « mini-planètes » à partir de panoramas équirectangulaires, comme celui illustré sur la figure ci-dessous.


Fig. 3.1 : Exemple de panorama équirectangulaire (réalisé par Alexandre Duret-Lutz).

Si, sur ce panorama, on lance le greffon G'MIC, et que l'on sélectionne le filtre « Stereographic projection », on obtient :


Fig. 3.2 : Le filtre « Stereographic projection » de G'MIC en action dans le greffon pour GIMP ou Krita.

Le filtre permet des réglages précis du centre de projection, de l'angle de rotation, et du rayon de la sphère considérée, tout ça de manière interactive directement sur la fenêtre de prévisualisation (nous y reviendrons par la suite). En quelques clics, et après application du filtre, nous obtenons la « mini-planète » désirée :


Fig. 3.3 : « Mini-planète » obtenue après projection stéréographique.

Il est d'ailleurs cocasse de constater qu'en inversant simplement l'axe vertical des images, on transforme une « mini-planète » en un « maxi-tunnel » !


Fig. 3.4 : « Maxi-tunnel » obtenu par inversion de l'axe vertical puis projection stéréographique.

Là encore, nous avons réalisé cette petite vidéo qui montre ce filtre en conditions réelles d'utilisation. À noter que G'MIC possédait déjà un filtre similaire (dénommé « Sphere »), qui pouvait être utilisé pour la création de « mini-planètes », mais avec un type de projection moins bien adapté que la projection stéréographique, qu'il est maintenant possible d'utiliser.

4 Toujours plus de possibilités pour la manipulation des couleurs

Triturer les couleurs des images est une occupation récurrente chez les photographes et les illustrateurs, et G'MIC possèdait déjà plusieurs dizaines de filtres destinés à cette unique activité, regroupés dans une catégorie dédiée (à savoir « Colors/ », pour faire original !). Cette catégorie s'étoffe encore, avec deux nouveaux filtres fraîchement apparus :

  • Le filtre « CLUT from after-before layers » cherche à modéliser la transformation colorimétrique qui a été effectuée entre deux images (que l'on possède). Supposons par exemple que nous ayons la paire d'images suivante :


Fig. 4.1 : Paire d'images où une transformation colorimétrique inconnue a été appliquée sur l'image du haut, pour obtenir celle du bas.

Problème : on ne se rappelle plus du tout comment on a fait pour passer de l'image originale à l'image modifiée, mais on voudrait absolument ré-appliquer le même processus sur une autre image. Hé bien, plus de soucis, appelons G'MIC à la rescousse ! Le filtre en question va chercher à modéliser au mieux la modification des couleurs sous la forme d'une HaldCLUT, qui se trouve être une façon classique de représenter une transformation colorimétrique quelconque.


Fig. 4.2 : Le filtre modélise la transformation colorimétrique entre deux images sous forme d'une HaldCLUT.

La HaldCLUT générée par le filtre va pouvoir être sauvée et ré-appliquée sur d'autres images, avec la propriété désirée que l'application de cette HaldCLUT sur l'image originale redonne bien l'image modèle cible dont on s'est servi pour que le filtre apprenne la transformation couleur produite.
À partir de là, nous sommes capables d'appliquer une modification de couleurs équivalente, sur n'importe quelle autre image :


Fig. 4.3 : La transformation colorimétrique estimée sous forme de HaldCLUT est ré-appliquée sur une autre image.

Ce filtre permet donc in fine de créer des HaldCLUT « par l'exemple », et pourrait donc intéresser de nombreux photographes (notamment ceux qui diffusent des compilations de fichiers HaldCLUT, librement ou non!).

  • Un deuxième filtre de manipulation de couleurs, nommé « Mixer [PCA] » a été aussi récemment intégré à G'MIC. Il agit comme un classique mixeur de canaux couleurs, mais plutôt que de travailler dans un espace couleur prédéfini à l'avance (comme sRGB, HSV, Lab…), il agit sur l'espace couleur « naturel » de l'image d'entrée, obtenue par analyse en composante principale (ACP) de ses couleurs RGB. Ainsi à chaque image sera associé un espace couleur différent. Par exemple, si nous prenons l'image « lion » ci-dessous, et que l'on regarde la distribution de ses couleurs dans le cube RGB (image de droite), on s'aperçoit que l'axe principal de variation des couleurs est définie par une droite allant du orange foncé au beige clair (axe symbolisé par la flèche rouge sur la figure).


Fig. 4.4 : Distribution des couleurs de l'image « lion » dans le cube RGB, et axes principaux associés (colorisés en rouge, vert et bleu).

L'axe de variation secondaire quant à lui (flèche verte) va du bleu jusqu'à l'orange, et l'axe tertiaire (flèche bleue) du vert au rose. Ce sont ces axes de variations (plutôt que les axes RGB) qui vont donc définir la base de couleurs utilisée dans ce filtre de mixage de canaux.


Fig. 4.5 : Le filtre « Mixer [PCA] » est un mixeur de canaux agissant sur les axes de variations de couleurs « naturels » de l'image.

Il serait malhonnête d'affirmer qu'il soit toujours meilleur de considérer la base couleur obtenue par ACP pour le mixage des canaux, et ce nouveau filtre n'a évidemment pas vocation à être le mixeur « ultime » qui remplacerait tous les autres. Il a simplement le mérite d'exister et de proposer une alternative aux outils usuels de mixage de canaux couleurs, alternative dont les résultats se sont avérés effectivement intéressants sur plusieurs images de tests utilisés lors du développement de ce filtre. Cela ne coûte rien d'essayer en tout cas…

5. Méli-mélo de filtres

Cette section présente pêle-mêle quelques autres nouveaux filtres et améliorations diverses qui ont été intégrés récemment à G'MIC et qui méritent qu'on les mentionne, sans s'y attarder outre mesure.

  • Le filtre « Local processing » permet d'appliquer un processus de normalisation ou d'égalisation de couleurs sur des voisinages locaux d'images (avec éventuellement du recouvrement entre voisinages). C'est un filtre supplémentaire permettant de faire ressortir des détails dans des photographies initialement sur ou sous-exposées, mais qui peut parfois créer des « halos » disgracieux.


Fig. 5.1 : Le filtre « Local processing » permet de rehausser les détails dans des photographies sur ou sous-exposées.

  • Vous trouvez que vous n'avez pas assez de modes de fusion de calques à votre disposition dans GIMP ou Krita ? Vous rêvez de pouvoir définir votre propre formule de fusion ? Alors le filtre « Blend [standard] » est fait pour vous ! Ce filtre, déjà existant auparavant, s'enrichit de la fonctionnalité « Custom formula » qui permet à l'utilisateur de spécifier sa propre formule mathématique de fusion de calque. Toutes les fantaisies deviennent possibles !


Fig. 5.2 : Le filtre « Blend [standard] » permet maintenant de définir ses propres formules mathématiques de fusion de calque.

  • Signalons aussi la ré-implémentation complète du sympathique filtre « Sketch », qui existait depuis plusieurs années, mais qui pouvait s'avérer un peu lent sur de grosses images. La nouvelle implémentation est beaucoup plus rapide, tirant notamment parti du calcul multi-cœurs quand c'est possible.


Fig. 5.3 : Le filtre « Sketch » a été ré-implémenté et exploite maintenant tous les cœurs de calcul disponibles.

  • Un gros travail de ré-implémentation a été également réalisé sur le filtre « Mandelbrot - Julia sets », puisque l'interface de navigation a été entièrement repensée, rendant l'exploration de l'ensemble de Mandelbrot bien plus confortable (comme l'illustre cette vidéo). De nouvelle options pour le choix des couleurs sont également apparues.


Fig. 5.4 : Le filtre « Mandelbrot - Julia sets » et sa nouvelle interface de navigation dans l'espace complexe.

  • Par ailleurs, le filtre « Polygonize [Delaunay] » qui génère des rendus polygonisées d'images couleurs se dote d'un nouveau mode de rendu, utilisant des couleurs interpolées linéairement dans les triangles de Delaunay produits.


Fig. 5.5 : Les différents modes de rendu du filtre « Polygonize [Delaunay] ».

6. Autres faits marquants du projet 6.1. Améliorations de l'interface du greffon

Bien sûr, les nouveautés dans G'MIC ne concernent pas seulement les filtres de traitement d'images proprement dits ! Un travail considérable a été par exemple réalisé sur l'interface graphique du greffon G'MIC-Qt, en particulier :

  • Les filtres du greffon ont désormais la possibilité de spécifier un nouveau type de paramètre point(), qui se matérialise sous la forme d'un petit disque coloré que l'on peut manipuler directement à la souris au-dessus de la fenêtre de pré-visualisation. En pratique, cela permet de rendre cette fenêtre de pré-visualisation interactive, et ce n'est pas rien ! De nombreux filtres utilisent maintenant cette capacité, ce qui les rend beaucoup plus agréables et intuitifs à utiliser (voir cette vidéo pour quelques exemples). L'animation ci-dessous montre par exemple comment ces points interactifs sont utilisés dans le nouveau filtre « Stereographic projection », que nous avons décrit précédemment.


Fig. 6.1 : La fenêtre de pré-visualisation du greffon G'MIC-Qt s'enrichit de nouvelles possibilités d'interactions pour l'utilisateur.

  • L'introduction de cette fonctionnalité a de ce fait permis d'améliorer les modes de division de prévisualisation (« split preview »), utilisés par un grand nombre de filtres pour afficher côte à côte les images « avant / après » lors de la prévisualisation d'un filtre dans le greffon. Il est maintenant possible de déplacer la zone frontière des images « avant / après », comme illustré par l'animation ci-dessous. Deux nouveaux modes de division, en damier, ont d'ailleurs été ajoutés à cette occasion.


Fig. 6.2 : Les modes de division de la pré-visualisation possèdent maintenant une frontière « avant / après » déplaçable.

Plein d'autres petites améliorations ont été faites dans le code du greffon : une prise en charge du dernier GIMP 2.10, de la version Qt 5.11, une meilleure gestion des messages d'erreurs s'affichant dans la fenêtre de pré-visualisation, un design général plus épuré, et tout un tas de petites choses par forcément visibles mais participant néanmoins au confort de l'utilisateur (un système de cache d'images pour la fenêtre de prévisualisation par exemple). Bref, que du bon !

6.2 Perfectionnement du cœur du logiciel

De nouvelles améliorations ont également été apportées dans les couches internes de G'MIC :

  • La « bibliothèque standard » du langage de script G'MIC évolue, avec l'apparition de nouvelles commandes pour le calcul des fonctions hyperboliques inverses (acohs, asinh et atanh), ainsi que de la commande tsp (travelling salesman problem) qui estime une solution « acceptable » au problème bien connu du voyageur du commerce, et ceci pour un nuage de points de dimension et de taille quelconque.


Fig. 6.3 : Estimation du circuit le plus court entre plusieurs centaines de points 2D, par la commande tsp de G'MIC.


Fig. 6.4 : Estimation du circuit le plus court entre plusieurs couleurs du cube RGB (en 3D donc), grâce à la commande tsp de G'MIC.

  • L'interface de démonstration, se lançant lorsque l'on invoque gmic sans arguments à partir de la ligne de commande, a également été refaite en repartant de zéro.


Fig. 6.5 : La nouvelle interface de démonstration de gmic, l'outil en ligne de commande de G'MIC.

  • Le compilateur JIT d'expressions mathématiques intégré n'est pas non plus en reste, et s'enrichit de nouvelles fonctions permettant de tracer des polygones (fonction polygon()) ou des ellipses (fonction ellipse()) dans des images. Ces expressions mathématiques peuvent en réalité définir de véritables petits programmes (possédant des variables locales, des fonctions utilisateurs et des structures de contrôle). On peut ainsi générer des images synthétiques facilement, avec de simples lignes de commande, comme le montrent les deux exemples ci-dessous.
$ gmic 400,400,1,3 eval "for (k = 0, k<300, ++k, polygon(3,u([vector10(0),[w,h,w,h,w,h,0.5,255,255,255])))"

Résultat :

Fig. 6.6 : Utilisation de la nouvelle fonction polygon() du compilateur JIT de G'MIC, pour générer une image synthétique aléatoire.

$ gmic 400,400,1,3 eval "for (k=0, k<20, ++k, ellipse(w/2,h/2,w/2,w/8,k*360/20,0.1,255))"

Résultat :

Fig. 6.7 : Utilisation de la nouvelle fonction ellipse() du compilateur JIT de G'MIC, pour générer une image synthétique florale.

  • Notons également une meilleure gestion des valeurs NaN lors des calculs réalisés par le cœur du logiciel, ce qui permet à G'MIC d'avoir un comportement cohérent même lorsqu'on le compile avec l'optimisation -ffast-math. Ainsi, G'MIC est maintenant compilable sans soucis avec le niveau d'optimisation maximal -Ofast du compilateur g++, alors que nous étions restreints dans le passé à utiliser « seulement » -O3. L'amélioration en vitesse de calcul se fait clairement ressentir pour certains filtres !
6.3 Supports de diffusion

Pas mal de changements ont aussi eu lieu sur les supports de diffusion utilisés par le projet :

  • Tout d'abord, les pages web du projet (qui en passant utilisent maintenant des connexions sécurisées https par défaut) s'enrichissent d'une nouvelle galerie d'images. Cette galerie montre à la fois des résultats d'application de différents opérateurs de traitement d'images disponibles dans G'MIC, mais aussi la façon de les reproduire (à partir de la ligne de commande). Notons d'ailleurs que ces pages de galerie sont générées automatiquement par un script G'MIC dédié à cette tâche, ce qui nous assure que la syntaxe donnée pour chaque exemple est exacte.


Fig. 6.8 : La nouvelle page de galerie d'images du site web de G'MIC.

Cette galerie est découpée en plusieurs sections, suivant le type de traitements effectué (Artistique, Noir & Blanc, Déformation, Filtrage, etc.). La dernière section « Code sample » est personnellement celle que je trouve la plus amusante, puisqu'elle présente de petites séquences d'images (sous forme de GIF animés qui bouclent) entièrement générées par des scripts courts en langage G'MIC. Une façon un tout petit peu exotique d'utiliser G'MIC, mais qui montre son potentiel pour l'art génératif.



Fig. 6.9 : Deux exemples d'animations GIF générées par des scripts en langage G'MIC, visibles dans la galerie d'images.

  • Et puis, nous avons déménagé le dépôt source git principal du projet vers Framagit, en gardant néanmoins un miroir synchronisé sur Gihub au même emplacement qu'auparavant (pour profiter en particulier du fait que de nombreux développeurs sont présents sur Github et peuvent plus facilement forker et nous faire des rapports de bug sur cette plateforme).
7. Conclusions et perspectives

Voilà ! Notre tour des nouveautés (des six derniers mois d'activité) du projet G’MIC s'achève enfin.

On est heureux d'avoir pu vivre dix belles années d'émotions informatiques avec la naissance et l'évolution de ce projet libre, et de pouvoir partager à notre manière, avec tous les utilisateurs, des techniques de traitements d'images avancées. On espère surtout repartir de plus belle pour de nombreuses années ! Les soutiens se font de plus en plus présents autour de nous, donc on se dit que ça doit pouvoir se faire (à ce propos, si vous voulez contribuer au projet de quelque manière que ce soit, vous êtes les bienvenus !).
Notons que l'année prochaine, on fêtera également les 20 ans d'existence de CImg, la bibliothèque C++ de traitement d'images qui est directement à l'origine du projet G'MIC (et qui elle, est née en novembre 1999, ça ne nous rajeunit pas ma bonne dame…). Preuve s'il en est que l'intérêt du logiciel libre, c'est qu'il s'inscrit dans la durée !

Et en attendant la prochaine dépêche sur G'MIC, n'hésitez pas à tester ce logiciel, à jouer et triturer vos images de la manière la plus libre et créative possible !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Développement web frontend en Haskell, Elm et Purescript

Linux France - Dimanche 19 Août

Actuellement, le développement web côté-client (frontend) est très souvent réalisé en JavaScript ou dans des langages dérivés comme TypeScript. Il existe cependant d'autres outils intéressants, basés sur des langages de programmation fonctionnelle, qui permettent notamment d'éviter de nombreuses erreurs lors de l'exécution sur le navigateur.

L'objectif de cette dépêche est de rappeler quelques généralités sur le développement web frontend, et de présenter les outils Elm, Purescript, Miso et Reflex, à partir d'un exemple d'application (galerie d'images fournie via une API web).

Attention : ceci n'est pas d'une étude rigoureuse et avancée mais juste un petit retour de petite expérience.

Voir également le dépôt de code de l'exemple et une présentation en vidéo.

    Sommaire Généralités sur le web frontend Page web, application web, application native

    Historiquement, les pages web se contentaient d'afficher un contenu statique et de proposer des liens vers d'autres pages. Des éléments dynamiques sont ensuite progressivement apparus : animations, formulaires avec vérifications de saisies… si bien, qu'aujourd'hui, de nombreuses pages web sont de véritables interfaces utilisateurs, comparables aux logiciels classiques installés sur le système. On appelle ce genre de pages des applications web (exécutées par un navigateur web), à distinguer des applications natives (exécutées par le système d'exploitation).

    D'un point de vue utilisateur, les applications web et les applitions natives sont de plus en plus proches. Par exemple, on trouve des applition web de traitement de texte (frama-pad, google-docs) qui possèdent une bonne part des fonctionnalités de leurs équivalents natifs (libreoffice, msoffice).

    D'un point de vue développeur, les technologies utilisées sont historiquement très différentes. Les applications natives utilisent généralement des langages comme Java, C#, Swift et leurs frameworks associés. Les applications web utilisent les technologies issues du web HTML/CSS/JavaScript et dépendent quasi-systématiquement d'un accès réseau via des websockets, requêtes AJAX ou autres. Cependant, on note une convergence web/natif également à ce niveau, notamment avec l'apparition du framework Electron, qui permet d'utiliser des technologies web pour développer des applications natives. De même, des architectures logicielles comme le Modèle-Vue-Contrôleur, très courant en natif, a été repris dans de nombreux frameworks web.

    Les langages pour le web frontend

    Le langage des applis web est sans conteste le JavaScript. C'est un langage assez controversé mais qui a tout de même des avantages indéniables, surtout depuis les récentes normes (ES2015…) : flexibilité, expressivité, compilateurs Just-In-Time performants, intégration dans les navigateurs…

    Cependant, JavaScript permet facilement de faire des erreurs qui se produiront à l'exécution finale de l'application, les fameuses runtime errors. Pour éviter ces erreurs, on utilise souvent des outils comme des analyseurs statiques, debuggers ou tests unitaires. Une autre solution consiste à utiliser des frameworks (Angular, React…), des bibliothèques (Immutable, Redux…) voire des langages dérivés (TypeScript…) qui réduisent les sources d'erreurs possibles.

    Les langages fonctionnels pour le web frontend

    En fait, une bonne partie des solutions proposées pour rendre le développement en JavaScript plus robuste existe déjà naturellement dans des langages fonctionnels comme Haskell : immuabilité, fonctions pures, typage statique fort… Certains développeurs se sont donc naturellement inspirés des langages fonctionnels pour proposer des technos web frontend garantissant l'absence d'erreurs au runtime.

    L'idée de ces technos est de fournir un écosystème complet (langage fonctionnel, compilateur, bibliothèques…) adapté au web et produisant du code JavaScript exécutable par un navigateur. Parmi ces technos, on trouve Elm et Purescript, qui proposent des langages inspirés d'Haskell. Il est également possible d'utiliser directement le langage Haskell (éventuellement avec des bibliothèques comme Miso ou Reflex) et le compilateur Ghcjs pour produire du code JavaScript. Enfin, il existe des outils dans d'autres langages fonctionnels comme ClojureScript, Ocsigen (OCaml)…

    Les concepts de MVC, FRP, Virtual-DOM

    Ces trois concepts sont généralement au cœur des technos web frontend fonctionnelles. Ils sont également assez fréquents dans l'écosystème JavaScript classique.

    Le MVC (Model-View-Controler) est une architecture de code qui permet d'organiser une application en trois parties : le modèle (données « métier » à manipuler), la vue (affichage présenté à l'utilisateur) et le contrôleur (mise à jour de l'application en fonction des événements). Généralement, un MVC gére les événements de façon asynchrone et unidirectionnelle : les événements de la vue sont passés au contrôleur, qui modifie le modèle puis lance un rafraichissement de la vue…

    crédit : Ossi Hanhinen

    Le FRP (Functional Reactive Programming) est le principe de base des frameworks fonctionnels, sur lequel est implémenté le MVC. Le FRP permet d'implémenter le comportement dynamique des interfaces utilisateur. Il traite les flux d'événements au cours du temps et transmet ces flux entre les différents composants de l'application, le tout de façon fonctionnelle (sans effet de bord).

    crédit : André Staltz

    Enfin, un concept essentiel aux applications web est le DOM virtuel. Le DOM (Document-Object-Model) décrit la structure d'une page web, donc de l'application, dans le navigateur. Au cours de son exécution, une appli web a besoin de manipuler le DOM, pour récupérer des données ou pour modifier l'affichage. Or, manipuler directement le DOM est coûteux et résulte en une application peu réactive. Pour améliorer les performances, les frameworks web utilisent un système de cache, le DOM virtuel, qui regroupe des modifications et ainsi minimise les accès au DOM.

    crédit : Naukri Engineering

    Un exemple de base

    Pour illustrer les outils de web frontend fonctionnel, imaginons qu'on veuille implémenter une appli client-serveur de recherche et d'affichage d'images d'animaux. Le serveur fournit les images en HTTP à l'URL /img/<nom-du-fichier>. Il fournit également une API JSON à l'URL /api/animals <prefix> auquel il répond par la liste des animaux de sa base de données dont le type correspond au préfixe donné en paramètre. Chaque élément de la liste retournée contient le type de l'animal et le nom du fichier image (accessible via l'URL /img). Si aucun préfixe n'est donné, le serveur retourne la liste complète.

    L'appli web client à réaliser contient simplement une zone de texte permettant de saisir le préfixe. Il envoie des requêtes AJAX au serveur pour récupérer les animaux correspondant puis affiche les images correspondantes après les avoir également demandées au serveur.

    Ci-dessous une image du client implémenté en Purescript. L'ensemble du code est disponible sur ce dépôt git.

    Elm

    Elm est un environnement complet de développement web frontend fonctionnel. Il fournit un langage fonctionnel (inspiré d'Haskell mais en beaucoup plus simple), un compilateur Elm vers JavaScript et des bibliothèques. Elm est basé sur un DOM virtuel performant et permet de développer des applis web selon une architecture MVC.

    Ci-dessous une implémentation en Elm de l'application d'exemple (note pour les développeurs Elm : désolé pour le non-respect des règles de formatage de code Elm mais j'ai subi des pressions de la part de la ligue de protection des molettes de souris). Ce code suit un schéma MVC et un style fonctionnel très classique. On définit un type Animal, avec ses fonctions de décodage de données JSON, ainsi que le modèle de l'application, c'est-à-dire simplement la liste des Animal à afficher.

    Au niveau du contrôleur, le type Msg définit les événements qui peuvent se produire. L'événement MsgInput modélise une action de l'utilisateur sur la zone de texte et l'événement MsgAnimals un message du serveur transmettant les Animal en réponse à une requête à l'API. Ces événements sont gérés dans la fonction update : MsgInput ne change pas le modèle mais lance une requête à l'API via la fonction queryAnimals, MsgAnimals met à jour le modèle avec les données Animal reçues.

    Enfin, la fonction view indique comment construire la vue de l'appli, à partir du modèle : un titre h1, une zone de texte input puis un div pour chaque Animal du modèle.

    module Main exposing (..) import Html exposing (..) import Html.Attributes exposing (height, href, src, width) import Html.Events exposing (onClick, onInput) import Http import Json.Decode as JD main : Program Never Model Msg main = Html.program { init = init , view = view , update = update , subscriptions = subscriptions } -- Model type alias Animal = { animalType : String , animalImage : String } decodeAnimal : JD.Decoder Animal decodeAnimal = JD.map2 Animal (JD.field "animalType" JD.string) (JD.field "animalImage" JD.string) decodeAnimalList : JD.Decoder (List Animal) decodeAnimalList = JD.list decodeAnimal type alias Model = { modelAnimals : List Animal } init : ( Model, Cmd Msg ) init = ( Model [], queryAnimals "" ) -- Controler subscriptions : Model -> Sub Msg subscriptions _ = Sub.none type Msg = MsgInput String | MsgAnimals (Result Http.Error (List Animal)) update : Msg -> Model -> ( Model, Cmd Msg ) update msg model = case msg of MsgInput animalType -> ( model, queryAnimals animalType ) MsgAnimals (Ok Model animals) -> ( Model animals, Cmd.none ) MsgAnimals (Err _) -> ( Model [], Cmd.none ) queryAnimals : String -> Cmd Msg queryAnimals txt = let url = "http://localhost:3000/api/animals/" ++ txt in Http.send MsgAnimals (Http.get url decodeAnimalList) -- View view model = span [] [ h1 [] [ text "Animals (Elm)" ] , p [] [ input [ onInput MsgInput ] [] ] , span [] (List.map (\a -> div [] [ p [] [ text a.animalType ] , img [ src ("http://localhost:3000/img/" ++ a.animalImage) , height 240 , width 320 ] [] ] ) model.modelAnimals ) ]

    Elm a l'avantage d'être particulièrement simple à utiliser. Les applis développées suivent toujours un MVC bien définis et les messages du compilateur sont particulièrement clairs. Le code JavaScript produit est léger et performant. Parmi les inconvénients, on peut noter que Elm est limité au schéma MVC qui, bien que très répandu, ne sera peut-être pas adapté à toutes les applications.

    Purescript

    Purescript est également un environnement complet (langage, compilateur, bibliothèques) mais plus général que Elm. En effet, son langage est plus proche d'Haskell et plus puissant (il supporte notamment les classes de type). De plus, Purescript propose différentes architecture de code, dont MVC. Enfin, Purescript peut être également utilisé pour le développement côté serveur.

    Ci-dessous une implémentation en Purescript de l’application d’exemple, utilisant la bibliothèque Halogen (FRP + DOM virtuel). Ce code est très proche du code Elm. Pour le modèle, on définit également un type Animals, avec les fonctions de décodage JSON, et un type Model. Pour le contrôleur, on définit un type Query qui permet de gérer la requête AJAX et sa réponse, via la fonction eval. Enfin, la vue suit le même schéma que l'implémentation en Elm.

    module Main where import Control.Monad.Aff (Aff) import Control.Monad.Eff (Eff) import Data.Argonaut ((.?), class DecodeJson, decodeJson, Json) import Data.Either (Either(..)) import Data.Maybe (Maybe(..)) import Data.Traversable (traverse) import Halogen as H import Halogen.Aff as HA import Halogen.HTML as HH import Halogen.HTML.Events as HE import Halogen.HTML.Properties as HP import Halogen.VDom.Driver (runUI) import Network.HTTP.Affjax as AX import Prelude main :: Eff (HA.HalogenEffects (ajax :: AX.AJAX)) Unit main = HA.runHalogenAff do body <- HA.awaitBody io <- runUI ui unit body io.query $ H.action $ QueryAnimals "" ui :: forall eff. H.Component HH.HTML Query Unit Void (Aff (ajax :: AX.AJAX | eff)) ui = H.component { initialState: const initialState , render , eval , receiver: const Nothing } -- Model newtype Animal = Animal { animalType :: String , animalImage :: String } instance decodeJsonBlogPost :: DecodeJson Animal where decodeJson json = do obj <- decodeJson json animalType <- obj .? "animalType" animalImage <- obj .? "animalImage" pure $ Animal { animalType, animalImage } decodeAnimalArray :: Json -> Either String (Array Animal) decodeAnimalArray json = decodeJson json >>= traverse decodeJson type Model = { modelAnimals :: Array Animal } initialState :: Model initialState = { modelAnimals: [] } -- Controler data Query a = QueryAnimals String a eval :: forall eff. Query ~> H.ComponentDSL Model Query Void (Aff (ajax :: AX.AJAX | eff)) eval (QueryAnimals animal_type next) = do H.modify (_ { modelAnimals = [] }) response <- H.liftAff $ AX.get ("http://localhost:3000/api/animals/" <> animal_type) let animals = case decodeAnimalArray response.response of Left _ -> [] Right ra -> ra H.modify (_ { modelAnimals = animals }) pure next -- View render :: Model -> H.ComponentHTML Query render m = HH.span [] [ HH.h1 [] [ HH.text "Animals (Purescript)" ] , HH.p [] [ HH.input [ HE.onValueInput (HE.input QueryAnimals) ] ] , HH.span [] (map (\ (Animal {animalType, animalImage}) -> HH.div [] [ HH.p [] [ HH.text animalType ] , HH.img [ HP.src ("http://localhost:3000/img/" <> animalImage) , HP.width 320 , HP.height 240 ] ] ) m.modelAnimals) ]

    Purescript a l'avantage d'être plus puissant et plus général que Elm. En contrepartie, il est moins simple à utiliser. Son environnement est également plus compliqué à utiliser : il faut gérer les dépendances Purescript avec bower, les dépendances nodejs avec npm et la compilation avec pulp.

    Haskell/Miso

    Miso est une bibliothèque Haskell pour développer des applis web frontend. Miso permet de coder une appli MVC + DOM virtuel et de la compiler en JavaScript grâce à Ghcjs.

    Ci-dessous une implémentation en Haskell + Miso de l’application d’exemple. Ce code est très similaire à l'implémentation en Elm. Miso annonce d'ailleurs explicitement s'inspirer de Elm.

    {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} import Data.Aeson (FromJSON, decodeStrict) import Data.Maybe (fromMaybe) import Data.Monoid ((<>)) import Data.Text (Text) import GHC.Generics (Generic) import JavaScript.Web.XMLHttpRequest (Request(..), RequestData(..), Method(..), contents, xhrByteString) import Miso import Miso.String (MisoString, toMisoString, fromMisoString, pack) main :: IO () main = startApp App { model = Model [] , update = updateModel , view = viewModel , subs = [] , events = defaultEvents , initialAction = GetAnimals "" , mountPoint = Nothing } -- Model data Animal = Animal { animalType :: Text , animalImage :: Text } deriving (Eq, Generic, Show) instance FromJSON Animal data Model = Model { modelAnimals :: [Animal] } deriving (Eq, Show) -- Controler data Action = GetAnimals MisoString | SetAnimals [Animal] | NoOp deriving (Show, Eq) updateModel :: Action -> Model -> Effect Action Model updateModel (GetAnimals str) m = m <# (SetAnimals <$> queryAnimals str) updateModel (SetAnimals animals) m = noEff m { modelAnimals = animals } updateModel NoOp m = noEff m queryAnimals :: MisoString -> IO [Animal] queryAnimals str = do let uri = pack $ "http://localhost:3000/api/animals/" ++ fromMisoString str req = Request GET uri Nothing [] False NoData Just cont <- contents <$> xhrByteString req return $ fromMaybe [] $ decodeStrict cont -- View viewModel :: Model -> View Action viewModel (Model animals) = span_ [] [ h1_ [] [ text "Animals (Miso)" ] , p_ [] [ input_ [ onInput GetAnimals ] ] , span_ [] $ map fmtAnimal animals ] fmtAnimal :: Animal -> View Action fmtAnimal animal = div_ [] [ p_ [] [ text $ toMisoString $ animalType animal ] , img_ [ src_ $ toMisoString $ "http://localhost:3000/img/" <> animalImage animal , width_ "320" , height_ "240" ] ]

    Pour un développeur Haskell, Miso est une bibliothèque intéressante, car elle permet d'implémenter des applis simples « à la Elm » tout en restant dans l'écosystème Haskell. En revanche, son environnement est moins mature : les outils Ghcjs + Miso + Nix ne sont pas complètement triviaux à mettre en place et les temps d'installation d'installation et de compilation plus longs.

    Haskell/Reflex

    Reflex est une bibliothèque Haskell de FRP générique. Elle est complétée par des projets associés : reflex-dom (DOM virtuel), reflex-platform (système de compilation multi-plateforme)… Une application Reflex peut être compilée avec Ghc ou avec Ghcjs et ainsi produire des applications web ou natives (PC ou mobile).

    Ci-dessous une implémentation en Haskell + Reflex de l’application d’exemple. Contrairement aux implémentations précédentes, ce code ne suit pas une architecture MVC mais gère explicitement les éléments graphiques et leurs flux d'événements. Il est tout à fait possible d'organiser le code selon un MVC mais ceci est à la charge du programmeur.

    {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Aeson (FromJSON) import Data.Default (def) import Data.Maybe (fromJust) import Data.Monoid ((<>)) import Data.Text (Text) import GHC.Generics (Generic) import Prelude import Reflex (holdDyn) import Reflex.Dom import Reflex.Dom.Xhr (decodeXhrResponse, performRequestAsync, XhrRequest(..)) main :: IO () main = mainWidget ui -- Model data Animal = Animal { animalType :: Text , animalImage :: Text } deriving (Eq, Generic, Show) instance FromJSON Animal -- View / Controler ui :: MonadWidget t m => m () ui = do el "h1" $ text "Animals (Reflex)" myInput <- el "p" $ textInput def evStart <- getPostBuild let evs = [ () <$ _textInput_input myInput , evStart ] let evCode = tagPromptlyDyn (value myInput) (leftmost evs) evResponse <- performRequestAsync $ queryAnimals <$> evCode let evResult = fromJust . decodeXhrResponse <$> evResponse dynAnimals :: (Dynamic t [Animal]) <- holdDyn [] evResult _ <- el "span" $ simpleList dynAnimals displayAnimal return () queryAnimals :: Text -> XhrRequest () queryAnimals code = XhrRequest "GET" ("http://localhost:3000/api/animals/" <> code) def displayAnimal :: MonadWidget t m => Dynamic t Animal -> m () displayAnimal dynAnimal = do let imgSrc = (<>) "http://localhost:3000/img/" . animalImage <$> dynAnimal let imgAttrs0 = ("width" =: "320") <> ("height" =: "240") let imgAttrs = ((<>) imgAttrs0) . (=:) "src" <$> imgSrc el "div" $ do el "p" $ dynText $ animalType <$> dynAnimal elDynAttr "img" imgAttrs $ dynText imgSrc

    Reflex est un projet assez ambitieux, censé permettre de développer tout type d'interfaces utilisateur et pour de nombreuses plateformes différentes. Il a l'avantage d'utiliser le langage Haskell. En revanche, il est assez compliqué à prendre en main. Programmer directement en FRP nécessite un vrai apprentissage ainsi qu'une bonne compréhension des foncteurs, applicatives et monades. Enfin, il faut structurer son code soigneusement mais soi-même.

    Conclusion

    Elm, Purescript, Miso et Reflex permettent de développer des applis web tout en profitant des avantages de la programmation fonctionnelle. Ces outils facilitent effectivement la validation de code et le refactoring, et réduisent voire suppriment les erreurs au runtime.

    Le principal inconvénient réside dans le choix parmi ces outils, qui nécessite de faire un compromis entre simplicité et flexibilité. Elm et Purescript sont de bonnes options pour du web « pur et dur ». Miso et Reflex sont plutôt à réserver à des développeurs Haskell expérimentés.

    Enfin, en dehors d'Haskell, il peut être intéressant de considérer d'autres outils comme ClojureScript, Ocsigen…

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Agenda du Libre pour la semaine 34 de l'année 2018

    Linux France - Dimanche 19 Août

    Calendrier web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 9 événements (2 en Belgique, 5 en France, 0 au Luxembourg, 2 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire [CA-QC Montréal] (3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres deMontréal - Le lundi 20 août 2018 de 14h00 à 17h00.

    (3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres, de niveau débutant qui tiendra sa rencontre régulière mensuelle tout les 3ième lundi de chaque mois.

    Amener vos portables,téléphone intelligent et tablette et votre bonne humeur. Venez jaser sur les logiciels libres, Nous montrer vos découvertes, poser vos questions

    [FR Paris] Certification PGP et CAcert - Le mercredi 22 août 2018 de 19h00 à 20h00.

    Vous souhaitez renouveler votre certificat CAcert Augmenter son niveau de confiance Augmenter le niveau de confiance de votre clé publique PGP

    Venez rencontrer des certificateurs autour d'un verre

    En pratique

    Pour votre clef PGP, préparez

    • deux documents d'identité français parmi la carte nationale d'identité, le passeport, la carte d'identité militaire, le permis de conduire, …
    • un petit papier imprimé avec l'identifiant et l'empreinte de votre clef, en autant d'exemplaires que vous espérez rencontrer de gentils autres porteurs de clefs.

    Pour votre certificat CAcert, préparez

    • deux documents d'identité français parmi la carte nationale d'identité, le passeport, la carte d'identité militaire, le permis de conduire
    • des formulaires d'accréditation imprimés, pré-remplis avec vos coordonnées en cliquant ici, ou vierges en cliquant là. Deux exemplaires pour chaque accréditation un pour vous, un pour le gentil accréditeur.

    Tous les détails sur le wiki de CAcert et Meetup

    [FR Toulouse] Rencontres Tetalab - Le mercredi 22 août 2018 de 20h30 à 23h30.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Paris] Soirée de Contribution au Libre - Le jeudi 23 août 2018 de 19h30 à 22h00.

    Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.

    Nous nous réunissons donc tous les dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).

    Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

    En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

    Pour obtenir le code d'entrée de la porte cochère, envoyez un mail au responsable.

    On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

    Regazouillez sur Twitter - Wiki des soirées

    Programme non exhaustif

    • Fedora (sa traduction)
    • Parinux, ses bugs et son infrastructure
    • April, … y a toujours quelque chose à faire
    • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
    • Schema racktables, son code
    • Agenda du Libre, mise à jour et amélioration du code
    • Ubuntu-Fr, son orga, ses événements
    • En vente libre, maintenance et commandes
    • Open street map, une fois par mois
    • Linux-Fr sait faire
    • en vente libre

    tout nouveau projet est le bienvenu.

    [CA-QC Coteau du Lac] Émission #158 de bloguelinux - Le jeudi 23 août 2018 de 20h00 à 21h00.

    bloguelinux.ca est un blogue québécois offrant la diffusion d'un podcast qui traite des logiciels libres, du système d'exploitation Linux et de la technologie en général il y a un processeur, il y a un système d'exploitation, c'est certain que ça nous intéresse

    bloguelinux.ca est enregistré le jeudi à 20h00 toutes les deux semaines.

    Vous pouvez nous écouter en direct lors des enregistrements à l'adresse http://live.bloguelinux.ca ou directement sur notre site à http://www.bloguelinux.ca en cliquant sur la radio dans le panneau de gauche du site.

    Vous pouvez rejoindre nos conversations avec Telegram en vous abonnant au groupe BlogueLinux en suivant le lien suivant https://t.me/joinchat/ArPfnBHCcui2t_CY6qAPAg et dans notre salle de chat en vous connectant sur les serveurs de freenode.net dans la salle #bloguelinux.

    Si vous n'avez pas de client IRC, vous pouvez utiliser l'adresse http://webchat.freenode.net

    AVERTISSEMENT Ce podcast peut contenir du langage inapproprié ou vulgaire et peut ne pas convenir à tout le monde.

    Animateurs Patrick et Sandrine

    [FR Cognac] Initiation à la programmation et à la robotique - Du vendredi 24 août 2018 à 09h00 au dimanche 26 août 2018 à 16h00. Atelier sur inscription en nous envoyant un message à contact@logicielslibrescognac.org

    Programme

    Initiation à la programmation structurée Faire un programme bash ( téléchargement automatique de fichiers sur un site internet ) Cette journée est très intéressante pour commencer simplement la programmation.

    Courte initiation à la programmation fonctionnelle et orientée Objet Faire un programme en C et C++ ( créer une liste de mots du dictionnaire … et comprendre pourquoi il faut avoir des mots de passes fort…).

    Initiation à arduino (programmation et cablage) pour la création d'un petit robothttp://logicielslibrescognac.org/contact.php

    [FR Rennes] Permanence Gulliver - Le samedi 25 août 2018 de 14h00 à 18h00.

    Venez vous renseigner pour diffuser largement vos œuvres.

    Sinon venez installer Linux ou des logiciels libres.

    Venez nombreux.

    [BE Saint Gilles] Gnu/Linux Install party - Le dimanche 26 août 2018 de 10h00 à 18h00.

    L’une des grandes qualités des logiciels libres, c’est qu’on peut librement les copier, les installer, les tester

    Une Linux Install Party est une réunion où tout un chacun peut

    • venir copier, échanger, se faire assister dans l'installation de logiciels libres
    • partager des connaissances, des configurations, faire circuler des informations…
    • faire connaissance avec une culture du Libre.

    Chaque quatrième dimanche du mois, nous organisons une Install Party à l’atelier multimedia de l’asbl fij

    Le comité asbl BxLUG 2018

    [BE Bruxelles] Educode.be 2018 - Du dimanche 26 août 2018 à 18h00 au mercredi 29 août 2018 à 20h00.

     Educode.be est une conférence internationale educode sur l'enseignement et le numérique.

    L'idée est que si nous voulons que nos concitoyens soient demain capables de gérer leurs environnements numériques, il faut aujourd'hui informer, former et faire réfléchir les enseignants, les directions et les décideurs politiques qui le plus souvent sont autodidactes. 

    Les présidents d'honneur sont Bernard Rentier, ancien recteur de l'université de liège et Yves Poullet, ancien recteur de l'université de Namur.

    La conférence commence par un cocktail d'accueil dimanche 26 août à 18h00 dans la salle de marbre de l'académie royale.

    Elle commence réellement lundi 27 à 9h00 dans la salle Henri Le Bœuf de Bozar.

    le programme est quasi fait.

    Il sera visible sur http://educode.be/programme.

    La dernière conférence de la journée sera de Thomas Pesquet, astronaute français qui a emporté des expériences de sciences utilisant des ordinateurs préparées par des lycéens français et sélectionnées par ESA.  

    Toute la journée, il y aura une exposition de groupes d'enfants et de moins jeunes qui font des choses amusantes et intéressantes avec du numérique en classe ou en dehors des classes.

    Puis nous profitons de la plus belle salle de concert bruxelloise pour faire un concert symphonique d'amateurs avertis avec des chœurs d'enfants et d'adultes pour célébrer la paix et marquer le 90e anniversaire du pacte de Paris ou pacte Brian-Kellog signé le 27 août 1928 et trop vite oublié.

    Quel meilleur symbole pour marquer la paix que d'associer la musique et les langages de programmation, toutes langues universelles.

    Mardi 28, de 9h00 à 17h00, nous organisons 60 à 80 ateliers pratiques sur des sujets très variés, depuis des usages de logiciels de composition musicale ou d'aide à la version latine jusqu'à la mise en forme d'enregistrements vidéo avec smartphone ou l'apprentissage de la programmation avec ou sans ordinateur en passant par des ateliers sur les méthodes agile et scrum adaptées à l'enseignement ou des ateliers expérimentaux de physique et chimie avec ordinateurs et smartphones.

    En fin de journée, la fin du congrès pour la majorité des enseignants, nous allons prendre un buffet convivial autour des iguanodons de l'institut d'histoire naturelle.

    Mercredi 29 de 9h00 à 18h00 à l'académie royale à nouveau, nous réfléchissons durant la journée aux expériences positives partout, échangeons sur celles-ci en mode congrès scientifique. 

    Nous avons le soutien de nombreux partenaires, toutes les universités francophones, deux flamandes, de nombreuses associations, l'unesco, l'institut de formation en cours de carrière qui permet que les professeurs viennent en formation officielle, IBM, cap gemini, la plupart des ministres mais pas encore de garantie pour celui de l'enseignement obligatoire bizarrement. 

    Bien sûr, pour faire la conférence comme nous en rêvons, votre soutien tant moral que financier serait très important.

    Il manque encore des sous (nous sommes aussi occupés à essayer d'obtenir la possibilité que les dons soient défiscalisés si cela vous intéresse) 

    L'affiche actuelle dans http://esi.link/educode-affiche-fr-02

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Dark Moon : une distribution GNU/Cygwin portable pour Windows

    Linux France - Jeudi 16 Août

    Dark-Moon est un émulateur de terminal Open Source développé par Mehdi Boutayeb Ferkatou et édité par MBK logiciel dans sa version UWP sur le Microsoft Store.

    Dark Moon est à ce jour la seule distribution GNU/Cygwin disponible sur le Microsoft Store et sur le site de l'éditeur.

    Sommaire Présentation

    Dark Moon est un ensemble de logiciels libres basé sur Cygwin rendu portable permettant l'exécution de commandes POSIX dans le but d'émuler un environnement Unix sur plateforme Windows X64.

    Dark-Moon permet de créer des scripts et des programmes utilisant les commandes grâce à une grande collection d'outils GNU et Open Source intégrée dans le terminal.

    Embarquer une collection d'API POSIX sous la forme d'un exécutable nous permet d'envisager une informatique hyper-transportable pour les émulateurs et distributions GNU/Cygwin, il suffit alors de trouver du courant et un processeur hôte pour exécuter l'application, ce qui aurait était auparavant impossible avant la naissance de Dark Moon.

    L'objectif technique recherché est de fournir un environnement de développement ainsi qu'un émulateur Unix cloisonnés dans un exécutable apportant une mobilité au logiciel, permettant d'exécuter l'application sur n'importe quel système Windows.

    Idée générale

    Dark Moon est autonome, ce qui le distingue d'autres distributions équivalentes.

    Il est possible d'exécuter des commandes Shell et Bash ainsi que de créer et exécuter des scripts sur la console.

    L'application est également un outil de développement notamment en offrant aux utilisateurs un environnement de développement libre tel que GCC.

    Cette distribution est également un outil Unix complet, personnalisable et offrant une mobilité ne demandant pas d'installation préalable. Elle est née en vue de fournir aux utilisateurs des possibilités étendues en complément de l'interpréteur de commande Windows.

    Il est possible de manipuler des fichiers ainsi que la ruche de registre sans déposer aucune empreinte sur l'ordinateur hôte afin d’éviter d'apporter des modifications durables à un poste utilisé temporairement.

    L'émulateur a fait l’objet d’une ouverture au public du code source, le logiciel libre est sous licence GNU GPL, il n’y a donc pas de restriction d’utilisation et de modification du logiciel tant que les conditions de la licence sont respectées.

    En comparaison d'autres distributions Cygwin et Linux, l'application ne requiert aucun composant externe, les fichiers étant cloisonnés dans l'exécutable même, permettant un emploi à partir d'un stockage amovible comme une clé USB.

    Différentes bibliothèques ont été incluses notamment MinGW qui travaille avec des composants Windows comme la bibliothèque MSVCRT liée à Microsoft Visual C++.

    Busybox est intégré pour l'implémentation d'un grand nombre des commandes par ailleurs, il est également possible d'utiliser un agent d'authentification OpenSSH.

    Le code source ainsi que les fichiers compilés ont été emballés dans l'exécutable pour respecter le concept de portabilité (il suffit de l'extraire avec 7zip pour avoir accès aux fichiers sources).

    Liste des commandes actuellement disponibles Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Syntaxe

    Avec les applets de commandes mis à disposition, il est possible de créer des scripts aisément comme présenté ci-dessous :

    #Mon premier script function() { local variableLocal="function 1" echo "$variableLocal" echo "Nombres de paramètres : $#" echo $1 echo $2 } function "Hello" "World"

    Pour lancer le script, placez vous dans le dossier contenant le script (obligatoire) :

    cd C:\Users\[Userprofile]\Documents\script-Shell

    faites un chmod :

    chmod 700 MonPremierScript

    Exécutez le:
    shell
    Nombres de paramètres : 2
    Hello
    World

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    FlOpEDT : un nouveau logiciel libre de gestion des emplois du temps!

    Linux France - Mardi 14 Août

    Toutes celles et ceux qui ont travaillé dans un lycée ou une université savent à quel point la gestion des emplois du temps est un sac de noeuds. La personne responsable s'arrache les cheveux pour tenter de fabriquer quelque chose qui satisfasse tout le monde … et ne réussit jamais!

    Alors avec quelques enseignants de l'IUT de Blagnac on a développé FlOpEDT. C'est un logiciel libre qui génèreles emplois du temps tout seul et permet aux utilisateurs de saisir leurs disponibilités et d'apporter des modifications en ligne et en toute autonomie.
    Toutes les briques de FlOpEDT sont OpenSource, et lui-même est en licence AGPL v3.

    Facile à utiliser et plein de liberté !

    Les utilisateurs se connectent et saisissent leurs préférences à l'aide d'une interface intuitive : un "sens interdit" pour les indisponibilités, une couleur explicite pour les préférences.

    Ensuite l'emploi du temps est généré automatiquement en quelques minutes en respectant contraintes et préférences. L'emploi du temps est alors accessible à tous, et il est possible pour tout utilisateur de le modifier.

    Cette partie est celle qui étonne : on nous dit souvent que si tout le monde peut faire des modifications ce sera la pagaille. Notre expérience confirme l'inverse : cela génère du confort pour tout le monde, et tout le monde a à cœur de prendre soin de cette liberté nouvelle (pas de coups de fils à passer, pas de mails gênés…). Évidemment, l'application empêche toute modification qui ne respecterait pas les règles fixées collectivement

    FlOpEDT est aussi doté d'un outil de synchronisation avec iCal (pour les agenda en ligne) ainsi que d'un outil de synchronisation avec des bases de données extérieures.

    Plus précisément, FlOpEDT se divise en deux parties essentielles :

    • une application web, développée dans le framework Django (Python3), s'appuyant sur une base de données postgreSQL ;
    • un outil de création de l'emploi du temps, qui passe par la définition d'un système d'équations linéaires (à l'aide de PuLP) et sa résolution.

    FlOpEDT n'en est qu'à sa version 0, et il n’est pour l’instant pas extrêmement générique : l'adaptation aux contours précis de votre établissement demanderait pour l’instant du travail. Mais ce temps investi permettrait d'en gagner ensuite beaucoup, et vous participeriez au développement d’un logiciel à terme utile à toutes et tous. Alors n'hésitez pas à nous contacter si vous voulez le tenter, votre proposition ne fera pas flop

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Movim, mode d'emploi - Première partie : l'architecture

    Linux France - Lundi 13 Août

    Je travaille maintenant depuis presque 10 ans sur Movim et je n'ai jamais réellement eu l'opportunité d'expliquer comment le projet fonctionne. Prenons un peu le temps de mettre tout ça par écrit !

    Cette présentation sera divisée en plusieurs articles. Je vais commencer par présenter le projet de façon globale avant d'aller progressivement vers son fonctionnement interne et ses détails techniques.

    Sommaire

    J'utilise les plateformes sociales depuis pas mal d'années maintenant et je suis toujours surpris de voir que malgré les milliards de dollars investis par les géants du Web elles fonctionnent toutes plus ou moins selon la même architecture.

    Même avec toutes les technologies qui sont apparues ces dernières années les choses se présentent toujours plus ou moins de la même façon : vous publiez du contenu via des requêtes Ajax (ou au travers d'un Websocket), c'est sauvegardé dans une base de données et vos contacts vont périodiquement envoyer une requête au serveur pour voir si il y a quelque chose de nouveau à afficher.

    C'est au final assez facile à construire et si vous souhaitez le faire vous-même il existe de nombreux frameworks qui offrent tous les outils nécessaires pour réaliser cette architecture aisément (typiquement Laravel, Ruby on Rails, Django, Symfony ou Zend, connectés à une base de données SQL, une API REST, une jolie interface et hop vous avez un réseau social).

    Mais pourquoi donc devoir attendre pour récupérer les publications des autres contacts ?

    Nous avons depuis des décennies maintenant des technologies de messagerie instantanée qui nous permettent d'envoyer, en temps réel, tout autour du globe, du contenu sans le moindre souci. Pourquoi ne pouvons-nous pas faire de même avec les réseaux sociaux ?

    Et c'est ici que réside l'idée de base du projet Movim.

    Créons un réseau social temps-réel

    Donc, l'une des erreurs à éviter quand le projet a démarré, c'était de réinventer la roue. Vous verrez que Movim est principalement composé de technologies basiques et déjà éprouvées.

    Pour fabriquer un réseau social fonctionnant en temps réel, il me fallait transférer du contenu instantanément sur le réseau. Il devait donc être transporté au sein d'un système "connecté" et donc construit sur des sockets (contrairement aux systèmes construits sur des requêtes).

    Cela exclut déjà toutes les récentes technologies sociales standardisées par le W3C (bye bye ActivityPub et WebSub), ces dernières étant construites sur HTTP. Loin de moi l'idée de remettre en question ces standards, ce sont des solutions sérieuses et parfaitement valides, mais pas pour les besoins de Movim.

    Je cherchais donc un protocole qui soit :

    • temps réel ;
    • standard (avec des RFC sérieuses) ;
    • et si possible déjà éprouvé et largement déployé.

    Cela nous amène donc à XMPP (je ne vais pas expliquer en détail comment le protocole est construit, vous pouvez trouver plus d'informations sur la page Wikipedia et sur le site officiel de la fondation).

    Dans la pratique, XMPP nous offre quelques précieux avantages :

    • C'est un protocole temps-réel (super !), les données sont échangées dans le format XML (oui, je vous vois déjà venir, vous les défenseurs du JSON ! Mais gardons de côté ce différend pour plus tard ;) ) sous forme de paquets (appelés "stanzas" dans le cas présent) envoyés en TCP et chiffrés avec TLS.

    • XMPP offre un framework très simple et générique qui comprend de (très !) nombreuses extensions que l'on peut combiner afin de développer la solution désirée. Voici pour l'exemple celles utilisées pour construire Movim. Et parce qu'XMPP est basé sur XML, il est très facile de l'étendre au moyen d'espaces de noms (namespaces) existants. Prenez Atom, ajoutez-y Pubsub, et voilà, vous obtenez un système de publication de contenu complet, temps réel, pour vos articles avec pièces jointes, bien défini et tout à fait spécifié.

    • Vous pouvez faire bien plus que de simples choses sociales avec XMPP. Pas besoin de composer avec dix autres protocoles, XMPP offre déjà tout pour faire du chat et des chatrooms, de la vidéoconférence, des solutions de publication-abonnement et beaucoup d'autres choses. Et cela offre l'avantage de conserver un code assez concis puisqu'il n'y a qu'un unique protocole dans le backend.

    • XMPP est fédéré et utilise un réseau un peu similaire à celui du courrier électronique. Les comptes sont créés sur les serveurs (c'est pourquoi les identifiants sont également similaires : nomutilisateur@serveur.tld). Les clients se connectent ensuite à ces serveurs XMPP. En plus de ça, vous pouvez avoir plusieurs clients connectés, en même temps, à votre compte et ils seront tous synchronisés en temps réel :)

    • Il y a déjà une grande communauté, avec des serveurs sérieux qui peuvent gérer des millions de connexions simultanément sans aucun problème (ejabberd <3).

    C'est aussi un gros avantage pour Movim. Je n'ai pas à m'occuper de tous les problèmes de réseau. C'est « juste » un client simple et stupide qui se connecte aux serveurs XMPP, en obtient du contenu et leur en envoie.

    Si vous comparez cette solution avec d'autres solutions de réseau fédéré telles que Mastodon ou Diaspora, il y a là une grande différence : pour Movim, les comptes sont sur un serveur distinct. Je n'ai donc pas besoin de créer une autre API pour communiquer avec Movim. Tout le monde peut échanger avec Movim en implémentant simplement XMPP (et il y a déjà beaucoup de bibliothèques et de solutions dans la nature pour le faire).

    Ok, nous avons choisi le protocole, maintenant nous devons construire le backend.

    Un peu d'histoire

    J'ai créé Movim en 2008 afin d'apprendre à programmer et essayer de construire par la même occasion une plateforme sociale sur laquelle j'aimerais échanger avec mes proches. Ayant choisi d'apprendre le langage PHP par la même occasion j'ai tout naturellement choisi celui-ci pour commencer les travaux.

    Avec les connaissances acquises au cours de mes études, l'aide d'un ami (Etenil si tu me lis) et de ce que j'ai pu apprendre de façon autodidacte j'ai progressivement amélioré Movim et rajouté les nombreuses fonctionnalités qui me paraissaient intéressantes pour construire une plateforme sociale digne de ce nom.

    Puis au cours de l'été 2014 j'ai décidé d'entièrement réécrire le cœur de Movim afin d'en faire une plateforme entièrement temps réel. En effet, jusqu'ici le projet était construit sur une "émulation" de temps réel construite au dessus de HTTP via les connections XMPP (en utilisant l'extension BOSH).

    Ces changements apportèrent également une importante réécriture de l'architecture interne et d'une refonte de l'interface utilisateur.

    À cette période un nouveau framework commençait à faire parler de lui au sein de la communauté. ReactPHP permettait en effet de construire très facilement des architectures entièrement en temps réel en PHP et offrait tout ce que je recherchais pour cette réécriture.

    Un démon, quelques tuyaux et voilà !

    ReactPHP est un ensemble d'outils s'interconnectant entre eux et permettant de créer toutes sortes d'architectures fonctionnant entièrement en temps réel.

    J'utilise à ce jour les modules suivants :

    • react/event-loop le cœur de React, s'occupant de la gestion de toutes les entrées/sorties ;
    • react/dns un résolveur DNS asynchrone ;
    • react/promise-timer pour exécuter périodiquement des évènements ;
    • react/socket pour se connecter à XMPP en utilisant des sockets TCP (avec une couche de chiffrement TLS par dessus) ;
    • react/child-process pour lancer et gérer des sous-processus ;
    • react/stream afin de connecter toutes ces choses ensemble ;
    • react/zmq une bibliothèque ZeroMQ pour pouvoir gérer efficacement les communications au sein de Movim.

    Il m'a fallu ensuite quelques mois de recherche avant de trouver une architecture stable, qui n'a que peu changé par la suite.

    Rentrons un peu dans les détails.

    Toute la structure de Movim est prise en charge par un démon central (qui s'appelle daemon.php, c'est fou!). Ce démon s'occupe de tous les websockets des navigateurs des utilisateurs (mobiles et bureau) et lance un sous-processus pour chaque utilisateur connecté. Finalement il se comporte comme un routeur tout bête qui transfère les messages entre les websocket des utilisateurs et leurs processus respectifs

    Cette architecture offre plusieurs avantages :

    • les sessions utilisateur sont isolées et n'influent pas sur les performances les unes des autres ;
    • elles peuvent être controlées plus facilement (tuer une session ne supprimera pas les autres) ;
    • le démon principal est minimal (il agit comme un simple routeur).

    Cela présente néanmoins un inconvénient : la consommation de mémoire est supérieure. Le code est chargé plusieurs fois entre les différents sous processus. Il faut compter environ 10 à 20Mb par utilisateur connecté. La situation s'est bien améliorée depuis les dernières versions puisque la consommation mémoire de Movim lui-même a été réduite en retirant des dépendances et en mettant à jour PHP (PHP 7.0+). La consommation mémoire reste un point d'amélioration pour les versions à venir puisqu'elle pourrait devenir un goulot d'étranglement. Le backend peut facilement supporter des milliers de connexions simultanées mais la mémoire vive manquera bien avant d'y arriver.

    Chacun des ces sous processus se connecte au serveur XMPP de l'utilisateur puis prend en charge toutes ses communications. Il se connecte aussi à la base de données SQL commune qui fait office de cache pour chaque compte et permet l'échange de données entre eux (via la découverte de resources publiques par exemple)

    Pour finir, ces processus gèrent aussi tout ce qui est relatif au frontend, mais cette partie sera expliquée plus en détail dans un article à venir.

    Optimisations

    Certaines optimisations ont été faites pour améliorer les performances globales de cette architecture.
    En voici les trois principales, celles qui je pense, ont eu le plus grand impact sur le projet.

    Parseur de flux XML

    Une connexion XMPP peut être ramenée à un flux XML bidirectionnel. Le client envoie des requêtes XML (appelées stanzas) et parse (analyse lexicalement) les requêtes entrantes. Le point important ici est que les requêtes entrantes font partie d'un seul et même "document" XML. À l'origine, Movim détectait chacune de ces stanzas et les parsait séparément.

    Le parseur a donc été remanié pour travailler en flux (voir Analyseur syntaxique XML). Cela permet à Movim de préparer les stanzas entrantes et de lancer les événements qui leur sont relatifs dès que les premières balises XML sont reçus dans le socket.

    Ce petit changement a vraiment amélioré les performances XMPP globales du projet. En particulier pendant la phase de connexion puisque Movim peut maintenant traiter plusieurs milliers de stanzas en quelques secondes.

    Hello ZeroMQ !

    Les communications entre le démon principal et les sous-processus (qu'on appelle "linkers" dans Movim) sont à l'origine de simples stdin/stout. Cela a créé des problèmes de buffer et de performance et j'ai finalement choisi d'utiliser un outil spécifique à la tâche : ZeroMQ.

    À chaque fois que le démon principal invoque un linker pour un utilisateur, il crée deux flux IPC dédiés (un pour les messages entrants et un pour les messages sortants) puis gère tout ce qui les traverse.

    Cela m'a permis d'éviter la création de certains buffers dédiés au transit de messages et ainsi d'améliorer les performances globales, en particulier pour la partie interface utilisateur.

    ZeroMQ est aussi très léger et est déjà disponible et packagé sur la majeure partie des distributions GNU/Linux.

    De Modl à Eloquent

    Movim dépendait au début d'un ORM spécifiquement créé pour le projet (Modl). La version qui arrive (0.14) utilisera la bibliothèque reconnue Eloquent (utilisée par le framework Laravel).

    Ce changement m'a permis d'utiliser des fonctionnalités comme le eager loading et le lazy loading, mais aussi d'écrire des migrations proprement et d'optimiser certaines requêtes.

    Plus d'informations dans l'article dédié.

    Ce que j'ai appris

    Après toutes ces années à travailler sur ce project temps-réel, je peux maintenant tirer certaines conclusions sur les choix et changements que j'ai réalisés :

    • PHP n'est pas un problème la plupart du temps : PHP est rapide, vraiment rapide. La plupart des optimisations que j'ai obtenues étaient liées à la façon dont je gérais les flux et leur contenu ainsi qu'aux requêtes dans la BDD. Passer à PHP7 puis aux versions suivantes a un peu amélioré les performances, mais le gain a été négligeable par rapport à ce qui a découlé des autres changements réalisés dans le code ;
    • Chercher le goulot d'étranglement : quand on travaille en temps-réel, même si certaines parties sont gérées par des promesses et autres systèmes asynchrones, il y a toujours du code synchrone et donc bloquant. Il faut s'assurer que ce code n'est pas "trop lent". Dans Movim par exemple, les requêtes BDD sont toujours considérées comme bloquantes (c'est une autre optimisation qui pourrait être apportée…) ce qui fait qu'une requête qui prend 200ms à être déclenchée va retarder l'exécution du reste du code de 200ms ;
    • Tester en "conditions réelles". Je pensais que Movim était rapide jusqu'au moment où j'ai vu des utilisateurs galérer avec (Nik, si tu me lis…). Certains utilisateurs de Movim avaient beaucoup plus de salons de discussion et avaient souscrit à beaucoup plus de flux que prévu, ce qui a créé de gros ralentissements, en particulier pendant la phase de connexion. Grâce à quelques optimisations bien pensées (et parfois très simples), les choses sont revenues à la normale.
    • Et peut être la plus importante de toutes : Keep It Simple!

    J'ai l'impression que beaucoup de projets accordent trop d'importance au principe DRY (Don't Repeat Yourself).
    Parfois il n'est pas nécessaire d'importer une bibliothèque entière, écrire une fonction qui correspond exactement à la situation peut faire l'affaire. Il est préférable de garder aussi peu de dépendances que possible.

    Questionnez-vous sur ce dont votre projet a besoin pour fonctionner. Est-ce que tout est vraiment indispensable?

    Et pour finir, n'ayez pas peur d'un grand ménage de printemps de temps en temps (j'ai passé 50 heures à remplacer Modl par Eloquent) pour simplifier et nettoyer votre code si nécessaire.

    Du coup, Movim est rapide?

    Movim est rapide. Dans certains cas, Movim est même plus rapide que certains clients XMPP natifs comme Pidgin ou Gajim.
    Movim est aussi plus rapide que certaines autres plateformes de chat, de par son backend, mais aussi grâce à la façon dont son frontend est mis en œuvre. J'en reparlerai dans un prochain article.

    Sur mon compte (400 contacts, 50 salons de discussion) s'authentifier et obtenir une interface réactive ne prend qu'une poignée de secondes, surtout sachant que les données viennent d'un serveur tiers (votre serveur XMPP) et sont re-synchronisées pour certaines lorsque vous vous connectez.

    Si vous voulez voir le résultat par vous même, faites un tour sur le site officiel ;)

    That's all folks!

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Agenda du Libre pour la semaine 33 de l'année 2018

    Linux France - Dimanche 12 Août

    Calendrier web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 7 événements (0 en Belgique, 6 en France, 0 au Luxembourg, 1 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire [FR Toulouse] Rencontres Tetalab - Le mercredi 15 août 2018 de 20h30 à 23h30.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Montpellier] Aprilapéro - Le jeudi 16 août 2018 de 18h45 à 19h30.

    Un apéro April consiste à se réunir physiquement afin de se rencontrer, de faire plus ample connaissance, d’échanger, de partager un verre et de quoi manger mais aussi de discuter sur l’actualité et les actions de l’April.

    Un apéro April est ouvert à toute personne qui souhaite venir, membre de l’April ou pas. N’hésitez pas à venir nous rencontrer.

    Régulièrement Montpel’libre relaie et soutient les actions de L’April. De nombreux Apriliens ont par ailleurs rejoints les rangs de Montpel’libre, sans doute lors d’Apéro April, d’AprilCamp ou des Rencontres Mondiales du Logiciel Libre qui ont eu lieu à Montpellier.

    Nous vous invitons donc à venir nous rejoindre dans une ambiance conviviale, à partager cet apéro, chacun porte quelque chose, boissons, grignotages… et on partage.

    Au programme des discussions

    • démarche et étapes pour la mise en conformité au RGPD des outils de l’April
    • discussions libres
    • échanges d’idées
    • faire un bilan des événements passés
    • faire des perspectives pour les actions futures
    • tout simplement, passer un moment convivial

    Entrée libre et gratuite sur inscription.

    Les Aprilapéro Montpellier ont lieu le 3e jeudi de chaque mois

    • Jeudi 21 septembre 2017 de 18h18 à 20h20
    • Jeudi 19 octobre 2017 de 18h18 à 20h20
    • Jeudi 16 novembre 2017 de 18h18 à 20h20
    • Jeudi 21 décembre 2017 de 18h18 à 20h20
    • Jeudi 18 janvier 2018 de 18h18 à 20h20
    • Jeudi 15 février 2018 de 18h18 à 20h20
    • Jeudi 15 mars 2018 de 18h18 à 20h20
    • Jeudi 19 avril 2018 de 18h18 à 20h20
    • Jeudi 17 mai 2018 de 18h30 à 19h30
    • Jeudi 21 juin 2018 de 18h30 à 19h30
    • Jeudi 19 juillet 2018 de 18h30 à 19h30
    • Jeudi 16 août 2018 de 18h30 à 19h30

    Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, l’April et Montpel’libre.

    Jeudi 16 août 2018 de 18h45 à 19h30 (3e jeudi de chaque mois)
    Do Tank au 2, rue du Pavillon, 34000 Montpellier

    [FR Montpellier] FSFEapéro - Le jeudi 16 août 2018 de 19h30 à 20h15.

    Afin de se rencontrer, d’échanger et de faire plus ample connaissance, lance de nouvelles rencontres surnommées les FSFEapéros. C’est l’occasion pour les neurones de toute part de se réunir physiquement pour discuter, échanger et partager un verre et de quoi grignoter.

    Les FSFEapéros auront lieu tous les 3e jeudis de chaque mois. Ils sont l’occasion de discussions informelles d’une part et de discussions plus sérieuses sur les différents thèmes d’importance et les différentes actions et campagnes en cours.

    Tout le monde est invité et peut venir aux FSFEapéros, qu’on soit contributeur de longue date, simple intéressé-e par les sujets que défend la Free Software Foundation Europe, ou nouvel-le arrivant-e cherchant à participer davantage. N’hésitez pas à amener vos amis et à leur faire découvrir La FSFE et Montpel’libre.

    Peuvent être aussi abordées des questions sur Les exégètes amateurs ou Open Law.

    Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, la FSFE et Montpel’libre.

    Jeudi 16 août 2018 de 19h30 à 20h15 (3e jeudi de chaque mois)
    Do Tank au 2, rue du Pavillon, 34000 Montpellier

    [FR Montpellier] Quadrapéro - Le jeudi 16 août 2018 de 20h15 à 21h00.

    Afin de se rencontrer, d’échanger et de faire plus ample connaissance, lance de nouvelles rencontres surnommées les Quadrapéros. C’est l’occasion pour les neurones de toute part de se réunir physiquement pour discuter, échanger et partager un verre et de quoi grignoter.

    Les Quadrapéros auront lieu tous les 3e jeudis de chaque mois. Ils sont l’occasion de discussions informelles d’une part et de discussions plus sérieuses sur les différents thèmes d’importance et les différentes actions et campagnes en cours.

    Tout le monde est invité aux Quadrapéros, qu’on soit contributeur de longue date, simple intéressé-e par les sujets que défend la Quadrature, ou nouvel-le arrivant-e cherchant à participer davantage. N’hésitez pas à amener vos amis et à leur faire découvrir La Quadrature et Montpel’libre.

    Peuvent être aussi abordées des questions sur Les exégètes amateurs ou Open Law.

    • Action de groupe contre les GAFAM

    Cet événement vous est proposé dans le cadre du partenariat qui lie le Club de la Presse, la Quadrature et Montpel’libre.

    Jeudi 16 août 2018 de 20h15 à 21h00 (3e jeudi de chaque mois)
    Do Tank au 2, rue du Pavillon, 34000 Montpellier

    [FR Metz] Permanence été 2018 - Le samedi 18 août 2018 de 14h00 à 18h00.

    Il s'agit d'une permanence de l'association Graoulug Groupe d'Utilisateurs Linux et Logiciels libres de Metz et environs.

    [FR Metz] Install-Party GNU/Linux - Le samedi 18 août 2018 de 14h00 à 18h00.

    L'association Graoulug organise une Install-Party GNU/Linux.

    Si vous voulez installer GNU/Linux sur votre ordinateur, amenez-le.

    Les membres de l'association vous aiderons à y installer la distribution GNU/Linux de votre choix (Ubuntu, Linux Mint…).

    Vous pourrez aussi apprendre à installer des application libres sur votre smartphone, avec F-Droid.

    [CA-QC Montréal] Vidéo Femmes journée Wiki à la Cinémathèque québécoise - Le samedi 18 août 2018 de 13h00 à 18h00.

    Activité gratuite et ouverte à tous

    HORAIRE DE L'ÉVÉNEMENT
    13 h à 15 h
    (Salle Fernand Seguin) : L'aventure Vidéo Femmes (discussions et projections)
    15 h à 18 h (Bar Salon) : 4 à 6 Wiki (partage de connaissance)

    **L'aventure Vidéo Femmes
    **Cette séance contribuera à enrichir l’histoire d’un collectif de réalisatrices féministes encore méconnues. Il s’agit du centre d’artistes, Vidéo Femmes, fondé en 1973 à Québec, par trois pionnières de la vidéo d’intervention sociale Hélène Roy, Helen Doyle et Nicole Giguère. Vidéo Femmes est à l’initiative d’une production d’environ 400 films et d’un grand réseau de distribution d’œuvres vidéographiques.

    Nous commencerons cet atelier par une présentation du collectif, en présence de plusieurs cinéastes. À travers différents témoignages et extraits de films, nous vous inviterons à découvrir la richesse de ce corpus protéiforme. Autour de thématiques liées au Mouvement de libération des femmes dans les années 1970, Vidéo Femmes est aujourd’hui une ressource incontournable pour documenter et compléter l’histoire du cinéma québécois.

    4 à 6 Wiki
    Après un après-midi de projections et discussions autour de Vidéo Femmes, nous vous invitons à un 4 à 6 complètement Wiki au bar-salon
    Ce mois-ci, nous troquons notre traditionnelle soirée Wiki mensuelle pour un 4 à 6 collaboratif et informel durant lequel nous nous concentrerons sur le partage des connaissances autour de Vidéo Femmes et des réalisatrices qui y sont associées. Ces petits moments Wiki vous permettent de participer au partage des connaissances et à la création d’un commun de savoir. Rejoignez cette communauté grandissante et partagez votre savoir avec le monde

    Formation et contribution libre aux projets Wikipédia, Wikidata et Wikimédia Commons.
    Tout le monde est bienvenu, que vous soyez simplement curieux d'en savoir plus sur les projets Wikimédia ou sur le cinéma, débutant ou contributeur averti, professionnel, étudiant ou amateur, passionné ou non de cinéma

    *Des ordinateurs seront disponibles sur place, mais il est conseillé d'apporter votre propre ordinateur

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Les journaux LinuxFr.org les mieux notés du mois de juillet 2018

    Linux France - Lundi 6 Août

    LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

    Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux-ci s'appellent des journaux. Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois de de juillet passé.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Haiku a 17 ans

    Linux France - Lundi 6 Août

    Les années passent, et Haiku est toujours là !

    Le projet, inspiré du système d'exploitation BeOS, a démarré le 18 août 2001, avec le fameux message "So, let's start." (« bon, allons-y ») sur sa liste de discussion. Alors nommé OpenBeOS, le projet avait été créé peu après l'annonce du retrait de Be du marché des ordinateurs de bureau.

    Cet anniversaire est l'occasion de faire le point sur les progrès de Haiku cette année (en l'absence de nouvelle version publiée depuis la version alpha 4 en 2012, il faut bien trouver un prétexte pour donner des nouvelles de temps en temps).

    Sommaire Présentation de Haiku

    Pour ceux qui n'auraient jamais entendu parler de Haiku, il s'agit d'un système d'exploitation pour les ordinateurs personnels (par opposition, d'une part aux serveurs, d'autre part aux smartphones, tablettes, et autres systèmes embarqués). Il est une réécriture de BeOS, un système propriétaire abandonné en 2001.

    D'un point de vue technique, ses particularités sont une base de code presque intégralement en C++ (oui, même le noyau) et généralement reconnue pour sa clarté et sa lisibilité (oui, même si c'est du C++), son approche de la programmation très multi-thread (chaque fenêtre ouverte par une application a son propre thread, par exemple), et la présence d'une API complète et cohérente pour faciliter le travail des développeurs d'applications.

    D'un point de vue utilisateur, l'objectif est d'avoir un système facile à utiliser et à appréhender (pas de surprise ou de comportements inattendus), réactif, tout en restant flexible et capable de faire ce qu'on attend de lui.

    Pourquoi un clone de BeOS ?

    À l'origine, Haiku est pensé pour fournir une continuité aux utilisateurs de BeOS et aux développeurs d'applications qui ne souhaitaient pas migrer vers un autre système.

    Cependant, 17 ans plus tard, BeOS est mort et enterré, et Haiku n'a pas réussi à fournir une version stable dans les temps. La plupart des développeurs d'applications sont passés à autre chose depuis. Cet objectif initial n'a donc pas été atteint en temps utile.

    Cependant, Haiku reste un projet pertinent aujourd'hui, car aucun système libre n'a vraiment pris la place que BeOS a libéré (dit autrement, non, ce n'est toujours pas l'année de Linux sur le Desktop).

    Le maintien de la compatibilité avec BeOS garde également un intérêt, pas pour les utilisateurs mais pour l'organisation du projet :

    • elle permet de garder un objectif à peu près raisonnable en vue, c'est-à-dire qu'on peut rejeter les propositions de nouvelles fonctionnalités en disant « ce n'était pas dans BeOS  » ;
    • elle permet de comparer l'implémentation des API avec celle de BeOS, pour décider si un problème vient d'une application ou d'un problème d'implémentation côté Haiku ;
    • elle permet enfin d'expérimenter les difficultés à maintenir pendant plus de 15 ans la compatibilité de l'ABI, et à réfléchir à la meilleure façon de procéder pour assurer la compatibilité entre les futures versions de Haiku.

    Cependant les désavantages (utilisation de gcc2, impossibilité d'implémenter certaines choses ou de résoudre certains problèmes de sécurité qui nécessiteraient de changer l'API) se font de plus en plus pressants, c'est pourquoi il existe maintenant une version 64 bits de Haiku qui peut s'affranchir de certaines de ces contraintes.

    Toujours pas de version bêta

    La dernière version publiée par Haiku est la version R1 alpha 4.1, qui date de novembre 2012. De très nombreux progrès ont été faits depuis, et en particulier un gros chantier sur l'infrastructure d'hébergement du projet permettant de mettre en place un dépôt de paquets pour tous les utilisateurs (ce sera l'une des grosses nouveautés de la prochaine version R1 bêta 1).

    Si on avait su que cela prendrait autant de temps, on se serait probablement organisé autrement, afin de pouvoir publier quelques versions alphas supplémentaires et faire patienter les gens. Pour l'instant, il vaut vraiment mieux télécharger un « nightly build » pour essayer Haiku.

    Nouveautés de l'année Corrections de bugs

    Il y en a beaucoup trop pour les détailler. Haiku est de plus en plus stable. Le portage d'applications venues d'autres systèmes, et la mise en place de machines fonctionnant sous Haiku pour la compilation des paquets présents dans les dépôts a permis (même si ce n'était pas le but initial) de tester le système de façon beaucoup plus intense. De nombreux problèmes difficiles à reproduire ont ainsi pu être plus facilement identifiés, puis résolus.

    La compatibilité POSIX s'améliore, le noyau fait de plus en plus de vérifications pour éviter les "panics" lors d'appels systèmes avec des paramètres invalides.

    Un bug mérite une mention spéciale, la méthode Split() permettant de découper une chaîne de caractères à l'endroit où elle contient un séparateur ne fonctionnait pas correctement. Il est surprenant que ce problème n'ait jamais été détecté auparavant.

    Nous avons également corrigé plusieurs problèmes d'alignement de la pile (dans le thread principal, les handlers de signaux, et dans le noyau) qui empêchaient l'utilisation fiable d'instructions SSE2. Le problème a été mis en évidence au départ dans le navigateur web, il a donc fallu creuser assez loin dans le système pour le corriger!

    Infrastructure

    Le vénérable serveur "baron", qui hébergeait l'ensemble des services de Haiku (bugtracker, dépôts git, site web…) depuis fin 2009 est en train d'être mis à la retraite.

    Il est remplacé par "maui", un serveur plus récent, qui utilise des conteneurs docker plutôt que des machines virtuelles pour isoler les différents services.

    C'est une opportunité pour revoir entièrement la façon de gérer le serveur. Baron était administré principalement par une personne qui faisait les changements directement. Mais avec le temps, de plus en plus de services ont été mis en place et il devenait trop difficile pour une seule personne de tout suivre. Le nouveau serveur est configuré à partir de dockerfiles qui peuvent donc être relus et modifiés par plusieurs personnes.

    D'autre part, un gros changement est le déploiement de Gerrit pour la revue de code. Précédemment, les contributeurs attachaient des correctifs dans leurs rapports de bugs et la revue était faite à partir de ces fichiers, ce qui est assez peu pratique. Gerrit permet de faire une revue plus facilement, et il est donc également utilisé par les développeurs (qui pourraient directement envoyer leurs changements sur la branche principale du dépôt Git) pour obtenir une relecture de leurs changements.

    En ce qui concerne l'hébergement des dépôts de logiciels, nous avons enfin tout mis en place pour compiler automatiquement les logiciels à partir de recettes fournies par le projet haikuports. Un système de miroirs est en train de se mettre en place, avec pour l'instant deux serveurs situés aux États-Unis et en Nouvelle-Zélande (en plus du serveur principal situé en Allemagne).

    Les paquets binaires sont donc rapidement disponibles dans HaikuDepot (le gestionnaire de paquets de Haiku) dès la publication des recettes permettant de les construire.

    Pilotes de périphériques

    Comme pour n'importe quel système d'exploitation, un point délicat est de pouvoir fonctionner correctement sur le plus d'ordinateurs possibles. Cela passe par l'écriture de pilotes pour tous les périphériques.

    C'est donc une partie de Haiku qui est assez active et il serait difficile de recenser précisément tous les changements intervenus dans l'année. Mentionnons quand même le support des boutons « étendus » pour les touchpads Synaptics et un début de support de leur « clickpad »; la possibilité d'utiliser une imprimante connectée sur un port série; des évolutions sur les pilotes graphiques Intel et Radeon pour prendre en charge plus de versions du matériel; et de petites améliorations sur le pilote de cartes son hda (qui est utilisé sur tous les ordinateurs à base de chipset Intel).

    Mise à jour des pilotes réseau

    Pour gagner du temps, Haiku réutilise les pilotes développés pour FreeBSD via une couche de compatibilité.

    Jusqu'à l'année dernière, les pilotes de FreeBSD 9 étaient utilisés, mais aujourd'hui nous utilisons ceux de FreeBSD 11. Cela augmente le nombre de cartes réseau prises en charge et corrige de nombreux problèmes d'instabilité de la connexion.

    D'autre part, un gros travail a été fait sur la pile TCP pour compléter l'implémentation de diverses RFCs permettant d'obtenir de meilleures performances.

    Support de l'USB3

    Le pilot xHCI est maintenant fonctionnel sur la plupart des machines, même s'il ne fonctionne pas encore parfaitement. Cela devenait nécessaire, car de plus en plus d'ordinateurs ne proposent plus du tout de ports USB2.

    Pilotes virtio

    Les pilotes virtio sont maintenant pleinement fonctionnels. Virtio est un bus utilisé par des machines virtuelles pour remplacer certains périphériques et éviter d'émuler un matériel réel. En utilisant une interface simplifiée, l'écriture des drivers est facilitée et les performances sont meilleures.

    Haiku peut maintenant utiliser les cartes réseaux, la mémoire "ballon" (RAM qui peut être redimensionnée en fonction des besoins de l'hôte et des machines émulées), et le stockage de masse sur virtio.

    Mise à jour du navigateur web

    Le navigateur fourni avec Haiku est basé sur un port de WebKit. Nous avions l'an dernier un an et demi de retard sur la version upstream de WebKit. Nous avons rattrapé une partie de ce retard puisque nous utilisons aujourd'hui une version datant de janvier 2018.

    Ceci permet d'accéder à des sites web modernes, même si de nombreux problèmes subsistent au niveau du rendu ainsi que de l'implémentation du protocole HTTP (moins simple qu'il n'y paraît à mettre en œuvre correctement).

    En attendant, les navigateurs Qupzilla et Otter browser, en Qt, permettent de visiter certains sites que WebPositive, le navigateur natif, ne parvient pas encore à traiter.

    Media kit

    Le Media Kit prend en charge tous les aspects multimédia (audio et vidéo, principalement) dans Haiku. Il permet aux applications d'exposer des nœuds qui sont connectés dans un graphe, un peu à la façon de Jack ou GStreamer sous Linux.

    Ajout du BMediaClient

    L'écriture de nœuds média demande beaucoup de travail répétitif et inutilement complexe. Une nouvelle classe BMediaClient a donc été introduite qui propose de prendre en charge la plupart de cet effort et donc de proposer une interface plus simple à aborder aux développeurs.

    Passage à ffmpeg 4

    Haiku utilisait encore pour sa version gcc2 une version 0.10 de ffmpeg, car il était impossible de compiler des versions plus récentes. Cela empêchait l'utilisation des API modernes de ffmpeg et commençait à poser problème pour le support de formats de fichiers récents.

    La solution mise en place consiste à compiler ffmpeg avec gcc7, mais à faire l'édition de lien de façon compatible avec gcc2. Pour l'instant, cela semble fonctionner dans ce cas précis. Nous allons donc pouvoir moderniser le plugin de décodage audio et vidéo basé sur ffmpeg, qui traite dans Haiku la plupart des formats de fichiers.

    Gestion du mode hybride 32/64 bits

    La version 64 bits de Haiku ne peut actuellement pas exécuter d'applications 32 bits. Il est probable que la version 32 bits soit un jour complètement abandonnée, mais pour cela il faudra proposer une solution pour que les utilisateurs puissent migrer vers la version 64 bits en conservant leurs applications.

    La gestion de l'exécution des applications 32 bits sur un noyau 64 bits est donc un des chantiers en cours. Cela pose un certain nombre de problèmes au niveau de l'interface entre le noyau et l'espace utilisateur, les appels systèmes devant traiter les données dans le bon format selon l'application utilisée.

    La première étape déjà franchie est l'intégration de SMAP et SMEP, qui permettent de s'assurer que le noyau n'accède pas par erreur aux données en espace utilisateur (la protection dans l'autre sens étant déjà assurée par la MMU). On a pu grâce à cette vérification clairement identifier tous les endroits ou de tels accès sont effectués, ce qui permettra de repérer facilement s'il est nécessaire ou pas de faire une conversion 32 <=> 64 bits. De plus, on gagne en sécurité puisqu'il sera plus compliqué pour une application d'utiliser un appel système de façon détournée pour lire ou écrire dans la mémoire du noyau.

    Passage à GCC 7

    Haiku dans sa version 32-bit est fourni avec deux compilateurs, une version 2.95.3 de gcc qui permet d'assurer la compatibilité binaire avec BeOS, et un gcc plus récent permettant de compiler les applications modernes (la version 64-bit de Haiku n'assure pas pour l'instant de compatibilité, et donc fournit uniquement une version moderne de gcc).

    L'année dernière, la version « moderne » utilisée était gcc 5.4. Nous utilisons maintenant la version 7.3. La migration a été l'occasion de corriger quelques bugs dans Haiku qui l'empêchaient de démarrer avec les nouvelles optimisations proposées par gcc.

    Le travail est déjà en cours pour le passage à gcc8, qui lève de nouveaux warnings (une grande partie de Haiku est bien entendu compilée avec le flag -Werror, donc les warnings ne sont pas admis).

    Le retour de Cosmoe

    Cosmoe est un projet consistant à porter l'userland de Haiku sur un noyau Linux ou BSD. Il n'a jamais abouti à quelque chose de fonctionnel, mais plusieurs développeurs (impliqués dans Haiku ou pas) ont repris le projet de temps en temps pour y faire quelques mises à jour.

    Cette fois, le projet a été repris par Dario Casuolinovo alias Barrett, qui a travaillé sur Caya (notre client de messagerie instantanée) et sur le Media Kit de Haiku. Son travail sur le Media Kit l'a convaincu que le noyau utilisé dans Haiku n'était plus pertinent aujourd'hui et qu'il valait mieux l'abandonner pour quelque chose d'autre. Nous verrons si Cosmoe arrive à percer cette fois-ci.

    Les membres du projet Haiku pensent que leur noyau reste pertinent (pour diverses raisons, en particulier le fait qu'il est écrit en C++ et qu'il offre une ABI stable pour les pilotes de périphériques) mais sont heureux de voir émerger d'autres projets inspirés par BeOS.

    LibreOffice pour Haiku

    Ça y est ! après plusieurs tentatives (quand on a commencé, le projet s'appelait encore OpenOffice…), nous avons enfin une version de LibreOffice pour Haiku.

    Cela a été rendu possible par le gros travail chez LibreOffice pour simplifier leur système de compilation, et également par le système de paquets de Haiku qui a permis de capitaliser et de mutualiser le portage des dépendances de LibreOffice.

    Bien qu'une grande partie des efforts a été faite pour avoir une version native, c'est finalement l'apparition d'un backend Qt dans LibreOffice qui a permis d'avoir une version fonctionnelle le plus rapidement.

    La disponibilité d'une suite bureautique moderne est un point important, d'une part parce qu'on peut maintenant présenter Haiku sérieusement comme un système utilisable pour faire un peu de bureautique et de navigation web, et d'autre part parce que LibreOffice remplace GoBe Productive, l'une des dernières applications BeOS non libres et encore utilisées (la prochaine sur la liste est Sync Modular - avis aux volontaires). On peut donc commencer à envisager plus sereinement l'abandon de la compatibilité binaire avec BeOS.

    D'autres langages de programmation

    Le langage Rust est à la mode, il était donc indispensable d'avoir une version pour Haiku et c'est maintenant chose faite. Rust 1.28 contient tous les correctifs nécessaires pour compiler directement sur Haiku, sans modifications.

    Mentionnons aussi une version de Swift qui est arrivée cette année, le support de Fortran disponible par défaut dans gcc, et des progrès pour avoir une version de freepascal complètement opérationnelle. Ceci bien sûr en plus de tous les langages qui fonctionnaient déjà très bien auparavant: Python 2 et 3, Lua, Perl, C, C++, et de nombreux autres.

    Java et Go ont été disponibles quelque temps, mais ont disparu des dépôts lors de l'automatisation des builds. L'ancien paquet pour Java 7 fonctionne, la version de Java 8 disponible plante au démarrage, et il n'y a pas encore eu de tentative pour les versions suivantes. Du côté de Go, une version assez ancienne était fonctionnelle, mais il est maintenant impossible de la compiler, car les sources référencent des dépôts hébergés par code.google.com, maintenant fermé. Avis aux volontaires pour remettre tout ça en route.

    Enfin, il semble utile de présenter yab, un fork de yabasic qui permet de développer des applications graphiques pour Haiku. Il n'était plus vraiment maintenu, mais quelques développeurs l'utilisant se sont un peu mis au C++ pour faire les évolutions nécessaires. Il est maintenant disponible dans les dépôts, l'interpréteur étant distribué sous forme d'une bibliothèque partagée qui peut être utilisée par tous les programmes écrits en yab.

    Support de l'UEFI

    Il est maintenant possible d'installer Haiku sur une machine UEFI. Actuellement ce n'est pas intégré dans les « nightly builds » générés par nos buildbots, il s'agit d'une image séparée contenant uniquement un chargeur de démarrage UEFI. Plus tard, ce sera intégré aux images « anyboot » (qui disposent également d'un MBR pour démarrer depuis une clé USB, et d'un chargeur « el torrito » pour démarrer quand elles sont gravées sur un CD).

    Améliorations de l'interface utilisateur

    Là encore, beaucoup trop de changements pour tous les lister, mais les applications fournies avec Haiku ont vu de nombreux petits changements. Cela va du comportement des menus ouverts trop près du bord de l'écran, à une meilleure prise en charge des écrans haute définition (il suffit de choisir une taille de police de caractères appropriée, le reste de l'interface doit s'adapter en fonction).

    Launch Daemon

    Le Launch Daemon est chargé de l'exécution des services, et du séquençage du démarrage et de l'arrêt du système.

    Les évolutions cette année portent sur la gestion des logs, une réécriture de la procédure d'arrêt pour éviter d'éteindre la machine avant que l'utilisateur ait pu enregistrer tous les changements dans des applications ouvertes (dans certains cas tordus). Il reste néanmoins bien plus léger que systemd.

    Évènements et conférences

    Comme chaque année, Haiku était présent au FOSDEM, au Capitole du Libre, aux JDLL et aux RMLL. L'occasion de donner plusieurs conférences, de rencontrer les développeurs d'autres projets et d'en profiter pour porter quelques logiciels vers Haiku avec l'aide des contributeurs principaux (mentionnons cette année Poezio, Dead Ascend, ou encore le Godot Engine, qui avait déjà un portage mais non maintenu). Nous avons également pu constater l'incompatibilité de Haiku avec les machines Purism Librem, sans avoir le temps de se pencher de plus près sur la question, malheureusement.

    La conférence BeGeistert, qui regroupe depuis très longtemps les utilisateurs et développeurs de Haiku (et de BeOS et Zeta), a pris une pause cette année, l'équipe organisatrice n'ayant plus la motivation pour s'en occuper étant donné le peu de personnes présentes.

    Le projet Haiku mettait à profit cette conférence pour organiser un « coding sprint », qui consiste à mettre le plus grand nombre possible de développeurs dans une salle de réunion pendant 5 jours avec un stock approprié de sodas, et une cantine et des lits à disposition. Le coding sprint étant un moyen étonnamment efficace de faire avancer les choses, nous avons décidé de le maintenir, et de l'organiser cette année juste après le Capitole du Libre, à Toulouse. Le changement de lieu a été plutôt apprécié par les développeurs présents, qui ont pu en particulier travailler sur le portage de LibreOffice, des corrections de bugs dans le navigateur web, l'amélioration de l'application HaikuDepot (le gestionnaire de paquets graphique) pour régler divers problèmes de performance et faire quelques améliorations cosmétiques, ou encore ajouter le réglage de la luminosité de l'écran sur les PC portables utilisant un chipset vidéo Intel.

    Bonne nouvelle, après cette année sans BeGeistert, l'évènement sera de retour en octobre prochain. Nous retournerons en Allemagne mais nous quitterons Düsseldorf, dont l'auberge de jeunesse qui nous a souvent accueilli n'offre plus des tarifs accessibles pour le budget de HSA (l'association qui finance l'évènement). Le format retenu est un évènement sur 4 jours, le détail sera décidé par la suite, sans doute un intermédiaire entre une conférence (avec quelques présentations) et un coding sprint.

    GCI et GSoC

    Haiku candidate tous les ans au Google Code-In et au Google Summer of code.

    Google Summer of Code

    Il s'agit d'un programme organisé par Google dont le principe est de payer des étudiants pour qu'ils puissent travailler à plein temps sur des projets libres. Les membres de chaque projet s'occupent de l'encadrement, et ont toute liberté dans les sujets proposés.

    Haiku a accueilli 3 étudiants cette année, travaillant sur le système de fichiers XFS (mais cela n'a pas donné grand-chose), un pilote pour les périphériques SDHCI (lecteurs de cartes SD sur de nombreuses plateformes ARM et certains laptops x86), et un client graphique pour Git intégré dans le Tracker (largement inspiré de TortoiseGit sous Windows). Les deux derniers projets sont en bonne voie.

    Google Code-In

    Code-In, quant à lui, cible les enfants de 13 à 17 ans, le but étant de leur faire découvrir le logiciel libre et plus généralement le développement de logiciels.

    Il s'agit d'un concours où les participants doivent compléter différentes tâches assez simples proposées par un projet libre. Chaque projet choisit ensuite deux gagnants qui pourront passer une semaine à San Francisco, assister à des conférences de personnes travaillant chez Google, et obtenir de nombreux stickers, T-Shirts, et autres goodies.

    Haiku participe tous les ans depuis la création du Google Code-In en 2010. Cela nécessite un investissement important de toute la communauté autour du projet, en effet il n'est pas facile de gérer l'arrivée massive des participants sur les canaux IRC et listes de diffusion du projet. Cependant, l'habitude est prise et l'organisation est un peu meilleure chaque année.

    Les tâches proposées sont diverses, on trouve des choses techniques (par exemple porter et packager un logiciel pour Haiku), graphiques (concevoir un autocollant à distribuer lors des conférences ou un poster présentant Haiku), de la documentation, ou encore du test (trouver des bugs dans un logiciel, écrire un plan de test, vérifier si des bugs reportés dans le passé sont toujours présents), et enfin une catégorie « outreach » (par exemple, préparer une présentation sur Haiku et la présenter à d'autres élèves, ou encore faire une vidéo présentant une fonctionnalité particulière).

    L'intérêt principal de ces deux programmes est l'accueil de nouveaux contributeurs et l'amélioration de la diversité de notre équipe, en effet la communication de Google et des différents projets participants permet de faire découvrir Haiku à des personnes qui ne seraient pas autrement venues contribuer.

    On ne compte plus vraiment sur ces projets pour faire avancer les choses directement : le temps nécessaire pour l'encadrement dépasse largement le temps qu'un développeur expérimenté aurait utilisé pour faire le travail directement. Cependant l'expérience est intéressante et nous permet aussi d'améliorer notre documentation et notre façon de travailler pour être plus accueillants aux nouveaux contributeurs.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Le Jet Propulsion Laboratory de la NASA publie les plans du rover Curiosity sur GitHub

    Linux France - Dimanche 5 Août

    Le Jet Propulsion Laboratory de la NASA (avec CalTech), qui a construit l'astromobile/le rover Curiosity pour explorer la planète Mars, a publié sur GitHub les plans d'une version réduite et abordable de ce véhicule sous licence Apache v2.

    Vous pouvez donc l'étudier, le construire ou l'améliorer !

    Le cerveau utilisé est un RaspBerry Pi. Vous pouvez le contrôler via une application Android.

    NdM. : ce rover est une version réduite (36cm, 11kg, 17cm/s) de Curiosity (2,7m, 899kg et 4 cm/s sur Mars). Il est conçu pour pouvoir être réalisé avec des composants du commerce. La publication a été réalisée pour « inspirer la future génération des scientifiques, ingénieurs et roboticiens pour nous aider à explorer et découvrir notre système solaire (et au-delà !) ». L'utilisation de la licence Apache v2 semble contredite par les critères supplémentaires suivant : être âgé de plus de 18 ans, décharge de responsabilité et pas d'utilisation commerciale. Le JPL explique par ailleurs avoir produit précédemment une version réduite de Curiosity à des fins éducatives (un mini-rover baptisé ROV-E), pour les classes, musées et événements scolaires. Et face au succès, ils ont décidé de produire un modèle inspirant et réalisable pour moins de 2500 USD (environ 2160 EUR).

    (crédit NASA/JPL-Caltech)

    (crédit NASA/JPL-Caltech)

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    20 ans de LinuxFr.org : entretiens avec les visiteurs (6)

    Linux France - Dimanche 5 Août

    Le 28 juin 2018, le site LinuxFr.org fêtait ses 20 ans. L’équipe du site a réalisé des entretiens par courriel avec des visiteurs (et contributeurs) réguliers du site. Les réponses sont publiées par lot de 5 répondants, et dans ce dernier lot (Adrien Dorsaz, JPEC, Christophe Chapuis, Anthony Jaguenaud et dzecniv), les répondants sont interviewés pour la première fois.

    Les questions de chaque entretien sont les suivantes :

    • Quand et comment avez‐vous connu LinuxFr.org ?
    • Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?
    • Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?
    • Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?
    • Contribuez‐vous à des projets libres, et si oui, lesquels ?
    • Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?
    • À votre avis, à quoi ressemblera LinuxFr.org dans 20 ans ? Le Libre dans 20 ans ?
    • Quel serait l’environnement / la configuration de vos rêves ?
    • Autre chose à rajouter ?

    Quand et comment avez‐vous connu LinuxFr.org ?

    Adrien Dorsaz (compte créé en 2010) : Je pense que j'ai connu LinuxFr.org vers 2008-2009, sous mon pseudo Trim, lorsque j'ai commencé à côtoyer l'association Swisslinux.org et, en particulier, eggman qui m'a fait découvrir l'ambiance du site :)

    JPEC (compte créé en 2010) : Je ne me rappelle plus comment j'ai découvert ce site (surement google ou un lien sur un forum) en quelle année j'ai créé mon compte sur DLFP mais ma première dépêche date de 2010… Je me souviens qu'à l'époque je lisais attentivement des épisodes sur le noyau par Patrick_g.

    Christophe Chapuis (compte créé en 2001) : C'était il y a bien longtemps, vers 2000-2001, peut-être via Google Altavista. Depuis, LinuxFr.org m'a permis de découvrir et d'apprendre énormément autour du logiciel libre.

    Anthony Jaguenaud (compte créé en 2002) : Vers 1999 quand j’ai commencé à travailler. En cherchant de l’information sur GNU/Linux.

    dzecniv (compte créé en 2013) : Ouh, je ne sais plus, probablement vers la fin de mes études, donc il y a 4/5 ans (allez 6), car je crois avoir déjà regretté de ne pas avoir lu linuxfr plus tôt. Pendant un moment je ne comprenais pas grand-chose à ce qu'il s'y disait, puis j'ai dû programmer, puis j'y ai pris goût, et je suis devenu un régulier… et un contributeur.

    Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?

    Adrien Dorsaz : Je suis les flux RSS des liens, forums, journaux et dépêches. J'utilise mon FreshRSS, donc via mon mobile ou d'autres périphériques et je l'ai programmé pour récupérer les nouvelles 3 fois par jour pour les transports et me laisser en paix le weekend. Je lis surtout les journaux et dépêches sur un peu tous les sujets (exceptés ceux liés à la politique française étant Suisse). Ceux qui me plaisent le plus sont ceux qui sont un peu techniques et me font découvrir de nouveaux domaines, surtout sur les sujets du développement logiciel, de Mozilla et de GNOME.

    JPEC : Je consulte le site quotidiennement principalement lors des « pauses » au boulot ou sur mon mobile. Je lis principalement les dépêches et les journaux et lorsque que le titre m'interpelle les forums. Je commente rarement.

    Christophe Chapuis : J'utilise un navigateur, quotidiennement, pour regarder les nouveaux contenus, ou les nouveaux commentaires sur un sujet qui m'intéresse. Je lis principalement les dépêches et les journaux, et je commence à m'habituer aux liens. J'aime parcourir les commentaires, qui sont (malgré les quelques trolls) d'une qualité au-dessus du lot sur Internet 2.0. J'utilise aussi la tribune - j'ai jamais réussi à m'en détacher.

    Anthony Jaguenaud : Mon utilisation n’a pas vraiment changé. Juste qu’aujourd’hui, je suis les flux RSS. J’ouvre tous les journaux et toutes les dépêches. Je recharge chaque article tous les jours, une à deux fois, pour voir les commentaires. Sur certains sujets polémiques, je peux prendre 100 commentaires d’un coup, ce que je ne peux pas traiter ;-) Concernant les liens, je ne les lis pas vraiment. Des fois, je vois un titre accrocheur, je l’ouvre. S’il y a des commentaires, je les lis et en fonction, j’ouvre le lien. Sans commentaires, j’ai une chance sur deux d’ouvrir le lien.
    Je ne sais pas si ça apporte quelque chose par rapport aux journaux bookmark. Peut-être moins de commentaires.

    dzecniv: Je suis abonné au flux RSS des dépêches et des journaux. Je contribue à certains wikis et forums, mais plus spécialisés ou plus tournés vers les linuxiens débutants que ceux de linuxfr. J'adore les articles qui présentent des technos (langages de programmation, logiciels, protocoles…) peu usitées et qui te font ouvrir des yeux ébahis. Et ça arrive toujours !

    Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?

    Adrien Dorsaz : L'écriture de la dépêche Protéger sa vie privée avec l'IPv6 est un très bon souvenir : d'une nouvelle des développeurs de Network Manager, j'ai découvert des détails sur l'IPv6 par rapport à IPv4, j'ai pu partager mes découvertes et quelques commentaires.

    JPEC : Je n'ai pas d'exemple précis à donner, mais il y a régulièrement des dépêches intéressantes (sur des sujets techniques ou pas).

    Christophe Chapuis : J'ai toujours apprécié les dépêches sur les noyaux Linux: c'est une mine d'or ! Et non, ce n'était pas mieux avant : la qualité de LinuxFr.org a su rester d'une belle constance au fil des ans.

    (pas de réponse de Anthony Jaguenaud à cette question)

    dzecniv: L'article "Le bitcoin va-t-il détruire la planète ?", contrepoint à un article ridicule, a été jubilatoire. Bravo encore à l'auteur. Je m'étais fendu d'un commentaire sur le journal du hacker, j'ai agi quoi :p mais là chapeau. Et puis, j'ai eu une période intense où j'ai voulu parler de plusieurs projets qui n'étaient pas ou peu relayés ici (Emacs, Guix, Gitlab, projets qui décentralisent internet©, j'oublie), donc forcément plus tard je demande à un tel s'il connaît telle techno et comme il répond « je l'ai lu sur linuxfr » je suis satisfait :]

    Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?

    Adrien Dorsaz : Il faudrait moderniser l'infrastructure, avec un accès depuis l'Internet « moderne » IPv6 ! J'aimerais bien que les utilisateurs ne se gênent pas à utiliser les journaux pour nous faire découvrir leurs intérêts. N'hésitez pas à faire des journaux courts, le sujet pourra intéresser quelqu'un ou ouvrir un débat :)

    JPEC : Je suis d'accord avec reynum sur la pertinence de l'ajout d'une section dédiée aux tutoriels.

    Christophe Chapuis : Difficile à dire, je suis assez content de l'aspect actuel du site: léger, fonctionnel, clair. L'essentiel (le contenu) est bien mis en avant. Alors, peut-être rajouter un "+/-" en plus de « pertinent/inutile », pour voir, mais c'est un détail je pense.

    (pas de réponse de Anthony Jaguenaud à cette question)

    dzecniv: J'aimerais un suivi plus facile des commentaires, pouvoir être notifié de réponses à son commentaire notamment. Je compare avec Reddit. Dans la même veine un tableau de bord plus complet, me permettant de voir tout mon contenu, voire d'en garder en marques page et de me créer une liste de liens. Une prévisualisation de ses écrits, plus pratique lorsqu'elle existe. Revoir et mettre en avant le wiki ?

    Contribuez‐vous à des projets libres, et si oui, lesquels ?

    Adrien Dorsaz: actuellement, je m'amuse à faire un client XMPP pubsub et je suis les RFC de Let's Encrypt pour maintenir à jour mon client ACME. J'aimerais retrouver du temps pour réinstaller LinuxFr.org sur mon PC et participer aux futures transformations prévues.

    JPEC : En ce moment non par manque de temps… Par contre, je bricole un prototype de gcoin qui pourrait être publié à terme.

    Christophe Chapuis : Je contribue au projet LuneOS depuis quelques années : c'est vaste, varié, et j'apprends beaucoup en m'amusant.

    Anthony Jaguenaud : Le temps me manque toujours pour contribuer vraiment. Je forme mes enfants à la problématique, les initie quand ils le souhaitent, les guide vers le libre sans les forcer. C’est ma contribution pour le libre du futur.

    dzecniv: Oui, surtout les miens :) gitlab, github, notamment Abelujo, un logiciel libre de gestion de librairies (recherche bibliographique de livres avec code-barre, de DVDs, etc), et plein de trucs dans Common Lisp depuis un an (car c'est génial et ça va me résoudre plein de limitations de Python et Django), notamment de la doc dans le CL Cookbook.

    Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?

    Adrien Dorsaz : Les projets qui me motivent le plus pour l'instant sont le serveur XMPP ejabberd et le client Movim. Je trouve franchement très intéressant le standard XMPP, il est plutôt simple (oui, XML est verbeux, mais il est facile à utiliser), souple et se modernise en continue (merci aux WebSockets et à pubsub !).

    (pas de réponse de JPEC à cette question)

    Christophe Chapuis : Je trouve le projet Anbox très intéressant, j'espère qu'il aura un bel avenir !

    (pas de réponse de Anthony Jaguenaud à cette question)

    dzecniv: Sans hésitation, le travail en cours sur Weblocks, un framework web pour écrire des applications dynamiques sans une ligne de javascript, dans un bon environnement, avec un langage stable et un REPL excellent. Weblocks est basé sur des widgets mis à jours côté serveur et rafraîchis côté client, disons React mais server-side, pour employer un gros mot. Voyez donc le nouveau quickstart.

    À votre avis, à quoi ressemblera LinuxFr.org dans 20 ans ? Le Libre dans 20 ans ?

    Adrien Dorsaz : Wow, je ne suis pas sûr que LinuxFr.org va survivre au bug de l'an 2038, comme à l'époque où mon entourage avait peur du « bug de l'an 2000 » :D LinuxFr.org continuera à être un point de rencontre des utilisateurs francophones de logiciels libres. Le libre continuera toujours d'exister : il y a aura toujours des utilisateurs heureux de pouvoir utiliser ses logiciels comme bon lui semble et quelques-uns qui seront eux-mêmes développeurs/artiste/traducteur/documentaliste/… avec du talent :)

    JPEC : Je pense que dans 20 ans LinuxFr.org aura le look d'un site des années 2020 :) Blague à part, je pense que le matériel va se complexifier et qu'il sera difficile de le faire fonctionner avec du logiciel libre (par exemple, si on regarde les ordiphones ou les tablettes actuelles, c'est quasi impossible à faire fonctionner avec du libre). Par contre, il restera toujours des gens passionnés qui s'investiront afin de proposer des solutions ouvertes.

    Christophe Chapuis : Peut-être y accèdera-t-on via IPv6 ;-) ? Je ne sais pas… Mais LinuxFr.org répond à un besoin, et y répond de manière élégante. Pour le Libre, je pense qu'un virage à ne pas manquer est le domaine de l'embarqué : on va vers plus d'objets connectés, mais ces objets sont actuellement très fermés. Leur cycle de vie et leur interopérabilité dépendent du bon vouloir du constructeur. J'espère que le Libre saura convaincre, à la fois en entreprise et chez les particuliers.

    (pas de réponse de Anthony Jaguenaud à cette question)

    dzecniv: Vu la tendance, il y aura beaucoup de libre d'entreprise, pour des solutions complexes ou dans les nuages qui nous feront quand même perdre en autonomie. Le discours critique sera similaire (« certes, une puce intracutanée est pratique, mais… »). La monnaie libre G1 aura 300 millions d'utilisateurs, sortant des millions de personnes de la pauvreté et permettant aux plus motivé.es de vivre facilement sans salariat et de se consacrer à leurs projets.

    Quel serait l’environnement / la configuration de vos rêves ?

    Adrien Dorsaz : retrouver une mini-machine à la taille du Eee PC 900, toujours aussi évolutif et réparable (batterie non-soudée, disque SSD remplaçable, mémoire vive accessible…), mais avec du matériel assez récent pour faire tourner un navigateur web et un IDE correctement ! Tout ceci avec un GNOME 3 sous Debian évidemment :D

    JPEC : un écran, un clavier BÉPO, un trackball, un dock et un ordiphone < 5" qui tourne sous Debian stable pour le socle et la dernière version de GNOME pour la couche utilisateur.

    Christophe Chapuis : Le meilleur environnement, pour moi, est celui qui se fait oublier. C'est un subtil équilibre entre flexibilité, efficacité, ergnonomie et stabilité. Pour l'instant XFCE me convient bien !

    (pas de réponse de Anthony Jaguenaud à cette question)

    dzecniv: Un environnement modifiable à la volée et totalement scriptable. Donc il y aura du Lisp forcément, avec ou sans Emacs, mais avec GNU Guix.

    Autre chose à rajouter ?

    Christophe Chapuis : \_o< !

    Anthony Jaguenaud : Un grand merci à l’équipe qui prend le temps de faire vivre ce site.

    dzecniv: Merci aux bénévoles de LinuxFr.org !

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Agenda du Libre pour la semaine 32 de l'année 2018

    Linux France - Samedi 4 Août

    Calendrier web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 9 événements (0 en Belgique, 6 en France, 0 au Luxembourg, 3 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire [CA-QC Montréal] Linux-Meetup Montréal - Le mardi 7 août 2018 de 19h00 à 22h00.

    Local de la rencontre à confirmer

    Programmation de la rencontre

    ATTENTION Le conférencier invité n'a pas encore été choisi. Si vous connaissez des compagnies œuvrant dans le logiciel libre, n'hésitez pas à m'envoyez un message.

    Ce mois-ci, nous aurons plusieurs petites présentations éclairs ("lightning talks") reliées à Linux et aux logiciels libres.

    Avis aux intéressés, envoyez-moi un courriel si vous voulez présenter quelques choses. Sinon, ce sera des présentations éclairs improvisées avec les gens présents.

    Par la suite, si le temps le permet, on fera une discussion de groupe sur un thème déterminé par les gens présents … discussions libres et ouvertes

    Lieu
    Le Linux-Meetup aura lieu à l'École de Technologie Supérieure de 19:00 à 22:00.

    Extras

    Pour ceux voulant réseauter avec les autres avant, il y aura un souper de 17:30 à18:45 (Resto-pub Le 100 génies de l'ÉTS au pavillon B).

    Nous invitons tous les amateurs de logiciels libres (peu importe la plate-forme) à venir discuter. C'est vraiment une excellente occasion de socialiser et de faire connaissance avec d'autres qui partagent les mêmes intérêts.

    La rencontre est gratuite et ouverte à tous (de débutants à experts) et rassemble des gens de diverses professions gestionnaires, professeurs, administrateurs de systèmes, ingénieurs, programmeurs, retraités, étudiants, etc.

    Les Linux-Meetup se déroulent simultanément à travers le monde tous les premiers mardis du mois ainsi que dans plusieurs régions du Québec.

    Vous pouvez confirmer votre présence sur un ou plusieurs réseaux sociaux afin de promouvoir l'événement Google+, Linkedin, Facebook, Twitter et Meetup

    Au plaisir de vous rencontrer

    Martial

    P.S.: Pour le transport en commun Station de métro Bonaventure

    [FR Caen] Atelier Inkscape, niveau avancé - Le mercredi 8 août 2018 de 17h00 à 19h00.

    L'association Artifaille organise un atelier de dessin vectoriel avec Inkscape – Avancé.

    Une approche plus avancée du dessin vectoriel pour des utilisateurs déjà initiés. Il s’agira ici d’aborder des techniques avancées sur des exemples concrets. Notamment reconstruire ou s’inspirer de logos existants (graphiques ou textes), détourer ou styliser à partir d’une référence photo, créer des objets en 2D ou un décor.

    Les sujets suivants seront abordés et mis en pratique par les participants

    • Copie et clone
    • Chemins (conversions, opérations booléennes, édition des nœuds)
    • Outils main libre et Bézier
    • Découpe et masque
    • Texte
    • Assistance (guides, grille, magnétisme…)

    Pré-requis connaître et avoir utilisé les techniques de base du logiciel (navigation, sélection, déplacement et déformation d’objets, création de formes simples, couleurs de fond et contour, empilement des objets…). Venir avec son PC et Inkscape pré-installé (www.inkscape.org), une souris avec molette vivement conseillée.

    Réservé aux adhérents Artifaille.
    Sauf "Ateliers prix libres" et permanences Artifaille (bien sûr), le premier atelier est gratuit avec une nouvelle adhésion anuelle.
    Lieu Maison des Solidarités, 51 Quai de Juillet, à Caen
    Pour toute question contact@artifaille.fr ou sur laissez-nous votre message sur le répondeur du

    [FR Nantes] Apéro Monnaie Libre - Le mercredi 8 août 2018 de 19h00 à 21h30.

    Tous les deuxièmes mercredi du mois, venez la découvrir la Monnaie Libre, durant lesquelles des membres vous présenterons les différentes facettes de cette belle innovation.

    Les Apéros Monnaie Libre sont l’occasion de nous rencontrer entre membres et futurs membres de la monnaie libre Ğ1.

    Que vous soyez totalement débutant ou utilisateur confirmé, tout le monde est bienvenue aux apéros monnaie libre

    • Présentation en Question/Réponse, de ce qu’est la Monnaie Libre Ḡ1 (pour ceux qui ne connaissent pas ou peu) &

    • Assistance création/utilisation de porte-feuille Ğ1 sous Césium.

    Mais c’est quoi la Ğ1 C’est le nom de la 1ère et seule monnaie libre existante à ce jour, une monnaie co-créée par tous les humains qui l’utilisent, c’est un revenu de base par création monétaire. Plus de détail ici http://nayya.org/ Si vous souhaitez de l’assistance pour créer ou utiliser votre compte Ğ1, nous vous recommandons d’apporter votre appareil (téléphone, tablette, pc portable).

    Ǧmarché Ces apéros sont aussi un moment privilégié pour demander ou proposer des biens et services en Ğ1

    [FR Toulouse] Université de Nuit d'été - Du mercredi 8 août 2018 à 19h00 au dimanche 12 août 2018 à 17h00.

    8-12 août 2018{::}  * La châleur et l'ennui vous accable Vous n'avez nulle part ou aller ce mois d'aoüt Ou vous êtes tout simplement curieux
    * Vous êtes invité à venir participer a la première édition de l'Université de Nuit d'Été du Tetalab, du mecredi 8 au dimanche 12 août 2018.
    * Les activités débuteront chaque soir vers 20h quand la température commence à devenir supportable, et se dérouleront jusqu'à entre 00h00 et 02h00.

     * Au programme
    *  Ateliers/cours d'initiation ou plus avancés

     *  langages informatiques, logiciels, électronique, soudure…
    *  moteurs de jeux videos 
    *  graphisme et création 3D

     *  Une "Game Jam"
    * conception d'un jeu vidéo en 48h, de A a Z, en solo ou en équipe.

      Restitution le dimanche en fin d'après-midi. *  Soutien à des projets DIY

      - les participants sont invités à venir échanger autour de problématiques rencontrées dans leurs projets DIY.  * la bienveillance, le sourire et faire des trucs qui font briller les yeux

      Mix'Art Myrys, 12 rue Ferdinand Lassalle, 31200 Toulouse

    [FR Toulouse] Rencontres Tetalab - Le mercredi 8 août 2018 de 20h30 à 23h30.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [CA-QC Coteau du Lac] Émission #157 de bloguelinux - Le jeudi 9 août 2018 de 20h00 à 21h00.

    bloguelinux.ca est un blogue québécois offrant la diffusion d'un podcast qui traite des logiciels libres, du système d'exploitation Linux et de la technologie en général il y a un processeur, il y a un système d'exploitation, c'est certain que ça nous intéresse

    bloguelinux.ca est enregistré le jeudi à 20h00 toutes les deux semaines.

    Vous pouvez nous écouter en direct lors des enregistrements à l'adresse http://live.bloguelinux.ca ou directement sur notre site à http://www.bloguelinux.ca en cliquant sur la radio dans le panneau de gauche du site.

    Vous pouvez rejoindre nos conversations avec Telegram en vous abonnant au groupe BlogueLinux en suivant le lien suivant https://t.me/joinchat/ArPfnBHCcui2t_CY6qAPAg et dans notre salle de chat en vous connectant sur les serveurs de freenode.net dans la salle #bloguelinux.

    Si vous n'avez pas de client IRC, vous pouvez utiliser l'adresse http://webchat.freenode.net

    AVERTISSEMENT Ce podcast peut contenir du langage inapproprié ou vulgaire et peut ne pas convenir à tout le monde.

    Animateurs Patrick et Sandrine

    [FR Orbey] Café informatique - Le samedi 11 août 2018 de 10h00 à 11h00.

    Venez partager moment d’échange et de pratique autour des outils numériques animé par Ma Vallée Numérique au salon de thé Chocolat'thé.

    • Apprendre à s’en servir et s’en protéger
    • Découvrir les logiciels libres
    • Échanger nos connaissances

    Tous les deux premiers samedis du mois, permanence de 10h00 à 11h00.

    Pour un meilleur accueil, inscrivez-vous en ligne.
    Dates et inscription sur le site.

    [FR Rennes] Permanence Gulliver - Le samedi 11 août 2018 de 14h00 à 18h00.

    Venez vous renseigner pour diffuser largement vous œuvres.

    Sinon venez installer Linux ou des logiciels libres.

    Venez nombreux.

    [CA-QC Montréal] WordCamp Montréal 2018 - Du samedi 11 août 2018 à 08h00 au dimanche 12 août 2018 à 17h00.

    WordCamp Montréal est une conférence de deux jours à propos de WordPress, la plateforme de blogue et le système de gestion de contenu le plus populaire au monde. Développeurs, designers, professionnels du Web et blogueurs se rassembleront pour assister à des présentations et des ateliers au sujet de WordPress et pour réseauter.

    Pour notre 10 anniversaire, l’événement aura lieu à l’école de gestion John Molson School of Business au centre-ville de Montréal les 11 et 12 août, 2018.

    Pour consulter la programmation complète de l'événement

    https://2018-fr.montreal.wordcamp.org/programme/

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Sortie d'OpenMW 0.44

    Linux France - Vendredi 3 Août

    L'équipe d'OpenMW est très fière d'annoncer la sortie de la version 0.44.0 de son moteur libre permettant de jouer à Morrowind, avec quelques fonctionnalités en plus et beaucoup de bugs en moins.

    Sommaire

    Déjà évoqué sur LinuxFr.org, OpenMW est non seulement une ré-implémentation libre du moteur du jeu de rôle The Elder Scrolls III: Morrowind, un des meilleurs JDR (Jeu de Rôle, RPG) au monde, mais aussi un éditeur permettant de créer du contenu pour ce nouveau moteur. Pour jouer à Morrowind, il vous faudra une version originale du jeu de laquelle on extraira les données, disponible à un prix complètement raisonnable sur Good Old Games par exemple.

    La version 0.44.0, sortie le week-end dernier corrige une petite centaine de bugs, et ajoute quelques améliorations en terme d’accessibilité. La précédente dépêche sur LinuxFr.org au sujet d'OpenMW datant de près de 3 ans, celle-ci va déborder un peu du cadre de la nouvelle mouture, et s'étaler sur quelques changements et nouveautés intéressantes de ces dernières années.

    Friandises pour les yeux

    Depuis le basculement, il y a trois ans (déjà) vers OpenSceneGraph comme moteur 3D, les ombres en temps réel ne sont plus supportées, mais ne devraient pas tarder à revenir, vraisemblablement dans la prochaine version. La bonne nouvelle, c'est que les ombres ne sont pas les seules fonctionnalités graphiques ajoutées par le projet : le support de l'affichage des terrains distants, permettant d'afficher la carte du jeu à perte de vue ou presque, des particules plus belles ou encore, la pluie et la neige troublant la surface de l'eau :

    Ou encore, la possibilité de jouer avec des shaders, pour ajouter un brouillard :


    Ou, comme dans les jeux modernes, le support du bump mapping :

    Objectifs et directions

    Suite au rachat de Github par Microsoft, le projet en a profité pour se chamailler en interne déplacer une partie de son infrastructure sur Gitlab : le Redmine vieillissant qui servait de bug tracker a également migré là-bas, et le wiki est en train de l'être. Pour ceux et celles qui préfèrent utiliser github, pas de panique, il est synchronisé avec Gitlab.

    Au sujet de ce qu'il va arriver après la sacro-sainte 1.0, notre BDLF a passé une quantité de temps faramineuse à écrire un document de 80 pages sur la direction envisagée pour le futur, à moyen et long terme du projet : doit-on améliorer le langage de script existant, ou proposer du lua et implémenter un transpileur ? Comment étendre le format des sauvegardes afin de pouvoir y fourrer plus de choses ? Comment remplacer les valeurs codées en dur dans le code, afin de rendre le moteur plus flexible ? Une chouette lecture pour un dimanche pluvieux donc.

    Bien que les modifications apportées par OpenMW par rapport à l'original soient mineures, il y aura toujours des puristes pour râler que c'était mieux avant™. C'est pourquoi le lanceur possède maintenant un onglet dédié aux préférences avancées, pour permettre à tout le monde de choisir :

    Comme dans tout projet (et plus particulièrement, en matière de jeux vidéo), OpenMW compte son nombre de bugs idiots et amusants, qui sont petit à petit corrigés, ne laissant que le souvenir d'avoir connu tel ou tel bug, et de pouvoir passer pour un vieux con sur IRC. Par exemple, avant la version 0.43.0, les PNJ oubliaient de remonter à la surface pour respirer quand ils étaient sous l'eau. Ou encore, la pluie qui parfois tombait à l'envers, de bas en haut ; les PNJ qui oubliaient d'attaquer le joueur, les statistiques qui passaient dans les négatifs, les créatures volantes soumises au pathgrid, …

    Nouvelles fonctionalités

    Le but de la version 1.0 est une compatibilité totale avec Morrowind (sauf pour les bugs aberrants évidement), les nouveautés significatives arriveront après, mais ça n’empêche pas des fonctionnalités mineures de se glisser dans OpenMW de temps à autre !

    Accessibilité

    Parmi les ajouts de fonctionnalités mineures, comme évoqués plus haut dans la dépêche, on peut citer pas mal de corrections ou d'améliorations en matière d’accessibilité et d'ergonomie : les menus du jeu peuvent maintenant être entièrement parcourus au clavier, les ingrédients s'entassent mieux dans l'inventaire, un tas d'infobulles (optionnelles) ont été ajoutées, que ce soit pour savoir si ce set d'alchimie qui vous fait de l'œil appartient à quelqu'un, ou si vous pouvez le faire tomber dans votre poche sans risque, l'affichage des dégâts des projectiles, le taux de succès des enchantements, … Il est possible d'utiliser à la fois un clavier et une souris, ainsi qu'une manette.

    L'interface n'est pas en reste, puisqu’elle est maintenant d'une densité adaptable: plus besoin de s'user les yeux quand on joue sur un écran avec une grosse résolution pour trier ses potions.

    Ces changements peuvent sembler mineurs, mais ils changent complétement la donne pour les personnes handicapées. Imaginez jouer à un jeu à la souris quand vous avez les mains qui tremblent…

    Ces petites choses en plus, et d'autres en moins…

    Avec l'emergence de grosses modifications du jeu original, comme Sword of Perithia ou arktwend, il a été nécessaire de changer pas mal de suppositions codées en dur dans le moteur de Morrowind, comme la taille de la carte ou de la mini-map, qui étaient invariablement boguées par ces mastodontes.

    Les sauvegardes, auparavant limitée à 255, ne le sont plus, et sont maintenant triées par personnage, au lieu d'être entassées dans une gigantesque liste horrible à faire défiler, et présentent des miniatures, qui permettent plus facilement de retrouver la sauvegarde qu'on cherche.

    La partie audio du jeu a été améliorée, supportant l'ensemble des formats acceptés par FFmpeg, et les filtres d'effets, comme l'écho dans les grottes, ou quand notre personnage est sous l'eau sont maintenant bien moins ratés plus immersifs.

    Il est courant d'amasser un tas de sortilèges dans le jeu, est c'est la pagaille pour s'y retrouver. C'est pourquoi une barre de recherche a été ajoutée, fini de devoir passer trois heures à chercher sa boule de feu en plein combat dans un donjon

    Ajouts massifs

    Ça n'est pas parce que les modifications importantes ne seront pas intégrées avant la version 1.0 que des contributeurs ne s'amusent pas à en implémenter, comme la possibilité de récupération de projectiles plantés dans des surfaces, ce qui n'existe absolument pas dans le jeu original :

    Ou encore des carquois (avec le bon nombre de flèches), qui eux aussi, à la base, ne sont pas présents :

    Il y a également une pull-request massive ajoutant plusieurs milliers de lignes de code et des dépendances, afin d'améliorer drastiquement le pathfinding, à coup d'autogénération, produisant au passage de belles visualisations:

    Une des choses que j'aime beaucoup dans Morrowind, c'est qu'il s'agit un formidable RPG qui se joue tout seul : pas d'autres joueurs (si ce n'est les PNJ) pour faire n'importe quoi et casser l'immersion, ou me voler mon trésor. Il était donc évident que quelqu'un allait investir son temps libre dans le seul et unique (si.) but de me gâcher mon plaisir, en forkant le projet, et en implémentant une version multijoueur de Morrowind, qui fonctionne !

    Support des "mods"

    Mais redevenons sérieux et oublions cette magie noire pour évoquer avec nostalgie le support des mods dans Morrowind, dont la communauté est loin d'être morte, avec des sites comme wiwiland et ses centaines de mods francophones ou encore nexusmod et ses plus de 5000 mods disponibles. Évidement, OpenMW a vocation à être compatible avec l'ensemble d'entre eux, et les bugs de ce coté-ci se font plutôt rares.

    Une des améliorations hautement appréciées d'OpenMW est qu'il permet d'installer chaque mod dans un dossier séparé, permettant de facilement le supprimer au besoin. Auparavant, il fallait consciencieusement noter quel mod installait quel fichier, et garder des copies des fichiers qui pouvaient être écrasés lors de l'installation, pour les restorer lors de la suppression. Comme il est courant de jouer avec une bonne centaine de mods, leur gestion était une question épineuse qui est maintenant résolue.

    Pour l'annecdote, les versions traduites du jeu le sont un peu trop, les traducteurs ayant fait du zèle, ils ne se sont pas contentés de traduire dialogues et sous-titres, mais également certains identifiants de lieux, objets, personnages, … rendant parfois les mods incompatibles entre les différentes traductions.

    Originellement, la création de mods s'effectue via le construction set, le même outil qui a servi à créer Morrowind, qui est livré avec le jeu. Il est donc normal qu'OpenMW le réimplémente également, surtout que le BDFL précédemment évoqué était également contributeur à l'ambitieux projet Ultima IX: Redemption
    , une suite spirituelle à Ultima, sur le moteur de Morrowind, malheureusement abandonné aujourd’hui.

    L'OpenCS n'est pas encore capable de remplacer complètement le construction set, mais les choses avancent, et la communauté des moddeurs s'y intéresse de plus en plus. Comme les fous furieux personnes derrière le titanesque projet Tamriel Rebuilt ont fait un tas de retours sur son utilisabilité, les fonctionnalités manquantes, et les corrections/améliorations à lui apporter, pour corriger certaines tares du construction set original.

    Par exemple, l'application de textures était une opération pénible, qui est maintenant simplissime, vu qu'il est possible de les appliquer sous forme de brosse : imaginez pouvoir ajouter du sable sur la plage fraîchement créée, simplement en baladant le curseur de la souris dessus, comme si vous étiez en train de la peigner.

    La compilation des scripts est plus stricte, et détecte un plus grand nombre de soucis et mauvaises pratiques que la version originale laisse passer sans rien dire.

    Conclusion

    OpenMW est un projet qui poursuit son bonhomme de chemin vers une comptabilité totale de Morrowind et une réimplémentation de son éditeur, depuis près de 10 ans, et tend de plus en plus vers sa version 1.0.

    Disponible et empaqueté pour de multiples OS, avec une communauté accueillante et active derrière lui, il permet déjà aux joueurs et joueuses de profiter confortablement de ce formidable jeu vidéo, et compte bien continuer sur cette voie !

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Présentation de The Log File Navigator

    Linux France - Jeudi 2 Août

    The Log File Navigator, ou lnav en plus court, est un outil en ligne de commande pour afficher des journaux, sous licence BSD. Par rapport aux classiques cat, grep, less, il propose quelques fonctionnalités supplémentaires :

    • il offre de la coloration syntaxique ;
    • il permet d'afficher plusieurs journaux en même temps, les lignes étant triées en fonction de la date et heure à laquelle l'événement est survenu (c'est pratique pour corréler des informations entre plusieurs processus) ;
    • il offre différents modes d'affichage.

    Lnav est un outil en ligne de commande qui permet de consulter des fichiers de journaux et de naviguer dedans, le tout dans un terminal. Il sait reconnaitre différents formats de journaux (syslog, Common Web Access Log qui est utilisé par Apache et Nginx, strace, Java logs, etc.). Cela lui permet de proposer de la coloration syntaxique sur les éléments reconnus et de trier par date d'événements les différentes lignes des journaux.

    Il sait ouvrir des fichiers compressés (gzip et bzip2 notamment) et suivre un journal actif (à la façon d'un tail -f). Il est également possible d'utiliser des filtres (pour ignorer certains messages à la grep -v) et de réaliser des recherches pour mettre en avant une expression. À noter : il est possible d'utiliser <TAB> lorsque l'on saisit une expression pour avoir une auto-complétion en fonction du contenu des journaux. Les raccourcis clavier sont classiques (par exemple, g pour aller au début du fichier et G pour aller à la fin ou encore / pour lancer une recherche, comme dans less notamment).

    A priori, il serait aussi possible de jouer avec les journaux via des requêtes SQL. Un système de sessions permet également de conserver certaines informations d'une exécution à l'autre (les filtres par exemple). Enfin, petit plus, la barre à droite permet de voir rapidement à quels endroits du ou des fichiers il y a eu des lignes d'erreurs ou des lignes qui correspondent à la recherche en cours.

    Au final, il est appréciable de pouvoir utiliser lnav en retrouvant la plupart des réflexes que issus des outils plus classiques, mais avec la coloration syntaxique en plus. Pouvoir corréler simplement des informations provenant de plusieurs fichiers est également très pratique. Pour les fonctionnalités plus avancées, ça viendra peut-être plus tard.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Quelques petits changements sur le site

    Linux France - Jeudi 2 Août

    Si vous êtes un lecteur régulier et attentif, vous avez peut-être remarqué quelques petits changements sur le site ces dernières semaines. J'ai touché à la CSS principale du site et, comme je suis plutôt un développeur back-end, c'est possible qu'il y ait quelques effets de bord non voulus. L'idée était de reprendre en main la feuille de style principale (qui n'avait pas été écrite par moi mais par 2PetitsVerres dans le cadre d'un concours pour créer un nouveau style au site fin 2010 / début 2011) et de commencer à mettre en place le travail de mjourdan.

    Travail technique
    • Découpage de la feuille de style en plusieurs fichiers pour mieux s'y retrouver ;
    • ajout de la bibliothèque normalize.css qui permet d'effacer certaines différences dans les feuilles de style par défaut des différents navigateurs ;
    • utilisation de box-sizing: border-box; par défaut ;
    • suppression de tous les anciens préfixes CSS et utilisation d'une bibliothèque pour ajouter automatiquement des préfixes CSS pour les propriétés qui le nécessitent ;
    • utilisation de prettier pour formater les fichiers de la feuille de style principale, et de stylelint pour détecter des erreurs.
    Nouvelles icônes pour les boutons

    Nous utilisons maintenant de jolies icônes au format SVG pour agrémenter les boutons sur le site. Elles proviennent de la collection Feather, sous licence MIT. L'avantage d'utiliser du SVG par rapport aux anciennes icônes au format PNG est double : ça pèse moins lourd et permet donc de charger la page plus rapidement, mais surtout, le rendu est plus propre pour les utilisateurs qui ont un niveau de zoom différent de celui par défaut.

    Page « À propos »

    La page « À propos » a été ajouté selon une proposition de mjourdan. Elle permet de présenter le site aux nouveaux visiteurs et les encourager à s'inscrire. Elle met également à l'honneur des vrais gens qui font vivre le site.

    Changements sur la page d'accueil

    En haut de la page d'accueil, la première dépêche est un contenu sélectionné par l'équipe de modération et qui reste pendant quelques jours en Une du site. Il est ressorti de l'enquête que cette dépêche qui ne change pas souvent pouvait être vue comme une absence de nouveaux contenus sur le site et prêter à confusion. Nous adoptons un nouveau style pour cette dépêche, ce qui devrait permettre de mieux la distinguer des autres contenus.

    Nous avons également ajouté en bas de page un texte court pour encourager tout le monde à participer. Nul besoin d'être un expert pour ça, tout le monde peut apporter sa pierre à l'édifice !

    Et d'autres choses Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    GIMP 2.10.4 : on garde le rythme !

    Linux France - Mercredi 1 Août

    La troisième version de GIMP 2.10 est sortie début juillet et, conformément à notre nouvelle politique de sortie, non seulement elle contient énormément de corrections de bogues (trop pour que nous puissions les compter !), mais aussi de nouvelles fonctionnalités, telles qu’une rotation par rapport à une ligne d’horizon, ou le l’étiquetage des polices de caractères !

    Sommaire Rotation par rapport à une ligne d’horizon

    Un besoin commun est celui de rendre une ligne bien horizontale dans une photographie. Typiquement, vous prenez une photo avec un horizon bien visible et souhaitez vous assurer que cet horizon soit horizontal.

    Cela est désormais possible dans GIMP grâce à un bouton dans les options de l’outil de mesure, lequel réaligne la photo par rapport à la ligne en cours.
    Pour la petite histoire : cette fonctionnalité a été intégrée suite à la demande répétée de Luk, libriste de toujours, pour lequel j’ai finalement donné un peu de temps. :-)

    Chargement asynchrone des polices de caractères

    Alors que GIMP sous GNU/Linux se lance aussi vite que l’éclair (ou presque !), il s’agissait en particulier d’un problème pour GIMP sous Windows et macOS : le chargement des polices de caractères par fontconfig rendait le démarrage de GIMP lent comme un escargot asthmatique lors du premier lancement ou lorsque de nouvelles polices étaient installées. Dans les cas les plus extrêmes, on recevait des rapports de plusieurs minutes d’attente pour les personnes installant des centaines de polices (ce qui n’est pas forcément si exceptionnel dans le monde des designers graphiques, une des cibles du logiciel).

    Les polices ne bloquent donc plus le chargement du démarrage ! En revanche, on ne peut pas utiliser toute fonction nécessitant des polices (comme l’outil texte) tant que le chargement n’est pas terminé en arrière‐plan.

    Étiquetage des polices de caractères

    Il est désormais possible d’étiqueter (« taguer ») les polices de caractères, de la même manière que les brosses, motifs et dégradés. Cela fait partie de nos améliorations en cours pour rendre la gestion des ressources plus agréable (même si on a encore beaucoup de boulot !).

    Mise à jour du tableau de bord

    Le tableau de bord introduit dans GIMP 2.10.0 a connu quelques améliorations, notamment en affichant des données sur la mémoire physique utilisée et disponible.

    Amélioration de la prise en charge du format PSD

    Même si la prise en charge du format PSD d’Adobe a énormément progressé avec GIMP 2.10.0, GIMP ne le prend toujours pas encore en charge à 100 %, notamment à cause de certaines fonctionnalités manquantes.

    Néanmoins, le format PSD peut aussi contenir une version pré‐composée du rendu final si le fichier a été sauvegardé avec l’option « Maximize Compatibility ». Il est désormais possible de charger dans GIMP cette version pré‐composée, ce qui permet de pouvoir charger l’image exactement comme attendue.
    Cela n’améliore pas le cas d’usage d’échange de fichiers de travail si vous souhaitez continuer un travail commencé dans Photoshop (en récupérant tous les calques, etc.). En revanche, c’est une grande avancée pour le cas d’usage où vous souhaitez seulement ouvrir et utiliser directement la version finale (au cas où un designer peu doué vous envoie un PSD comme version finale unique).
    Pour cela, choisissez le nouveau format « Image Photoshop (fusionnée) ».

    Autour du développement Nouvelles des paquets

    Cela ne concerne pas vraiment les systèmes GNU/Linux de prédilection sur ce site, mais parlons un peu de macOS ! Nous n’avions plus de paquet pour ce système d’exploitation depuis GIMP 2.10.0. Certains semblaient même croire que GIMP ne prenait plus en charge ces systèmes (comme je l’ai découvert lorsqu’on m’a interviewé sur le podcast Late Night Linux). Ce n’est pas le cas ! GIMP compile encore bien pour macOS, et d’ailleurs plusieurs personnes fournissaient déjà un paquet tiers.

    La raison pour laquelle nous n’en avions pas était simplement l’absence de nos contributeurs macOS habituels (et le faible nombre de ceux‐ci, puisque c’était plus ou moins un nombre unitaire !).
    Heureusement, un nouveau contributeur a fait son apparition et, contrairement aux autres propositions, il s’agit de quelqu’un qui accepte de travailler en équipe (ceci étant un problème, car comme je le disais, d’autres font déjà des paquets tiers, mais peu sont ceux qui essaient de s’adapter au travail en équipe).

    Je profite de cette nouvelle pour rappeler que GIMP pour Windows et macOS n’a quasiment aucun contributeur ! Si — malgré le fait que nous soyons sur LinuxFr.org — vous souhaitez voir GIMP s’améliorer sur ces plates‐formes, nous apprécierions vraiment que les intéressés contribuent du code.

    Nous rappelons qu’aucun des contributeurs récurrents actuels n’utilise ces systèmes d’exploitation, et si nous corrigeons parfois des bogues pour lesdites plates‐formes, ce n’est que par gentillesse ou parfois par ennui. Par exemple, je suis celui qui a finalement pris de mon temps pour implémenter le chargement asynchrone des polices au démarrage (puis Ell a pris la relève et a énormément amélioré au‐dessus de mon travail), alors même que je n’ai jamais vécu ce problème moi‐même ! Cela restait pourtant un des plus vieux sujets de plainte pour Windows (et même macOS dans une moindre mesure) avec probablement des dizaines de rapports, et ce depuis des années (peut‐être depuis toujours). C’était cependant assez simple à implémenter ; pourtant à part des plaintes, personne n’a jamais essayé de corriger. Je trouve cela triste. Des bogues simples (mais clairement très embêtants, voire bloquants !) comme cela, il y en a des dizaines dans GIMP sur ces systèmes propriétaires. Il serait extrêmement facile pour un programmeur avec un minimum d’expérience de rendre GIMP plus agréable dessus. À bon entendeur !

    Activité florissante et retour d’expérience des gens !

    L’activité de GIMP est vraiment saine et prospère, avec en moyenne (depuis la dernière version GIMP 2.10.2) : 22 commits par jour sur la branche principale (master) de développement et 7 commits par jour sur la branche gimp-2-10 (série GIMP 2.10.x, qui reçoit toutes les corrections de bogues et des fonctionnalités diverses en rétro‐portage).

    De manière intéressante, nous avons des retours (sur les réseaux sociaux) de gens qui croient en un renouveau de GIMP. Or, cela fait des années que l’activité de développement est si intense (ce n’était cependant pas le cas, effectivement, il y a six ans, quand j’ai commencé à contribuer) ! Clairement, la sortie de GIMP 2.10, mais surtout les sorties successives avec notre nouvelle politique de fonctionnalités, font des merveilles. :-)

    Une autre conséquence agréable que j’ai remarquée est l’attitude positive des gens. Pendant des années, on recevait énormément de critiques très virulentes et mauvaises. Et je dois dire que personnellement ce fut très dur de faire face à la méchanceté de certains. Ce n’est pas étonnant que la dépression guette beaucoup de développeurs de logiciels libres. Il m’est arrivé à plusieurs reprises de ne plus avoir la force de contribuer pendant plusieurs jours (et de me poser des questions sur pourquoi je faisais du Libre) après trop d’insultes reçues.
    Dorénavant je remarque que la tendance s’est inversée. Je vois moins de remarques méchantes (ou peut‐être sont‐elles dorénavant totalement noyées derrière les louanges !) et beaucoup de gens qui nous remercient.

    Cela devient à nouveau agréable de contribuer au logiciel libre et nous met de bonne humeur ! :-)

    Retour de « gimp-data-extras » et « Alpha-to-Logo »

    GIMP est déjà livré par défaut avec énormément de greffons, brosses, scripts et autres données. Parfois, il nous arrive d’en supprimer certains car nous estimons leur qualité insuffisante, ou bien parce qu’ils dupliquent une fonction faite par un autre script plus moderne, etc.

    Néanmoins, nous sommes conscients que certaines personnes souhaitent continuer à utiliser telle ou telle donnée pour une raison ou une autre (ne serait‐ce que pour garder exactement le même rendu d’une utilisation à l’autre ou pour la compatibilité de vieux scripts, etc.). C’était par exemple le cas du vieux script Alpha-to-Logo qui avait été retiré de GIMP 2.10 à cause de sa qualité médiocre. Or, il avait clairement son public puisqu’il nous a été beaucoup demandé depuis. Plutôt que réintégrer un script dont nous ne sommes pas satisfait, ce script fait donc son retour dans le paquet gimp-data-extras 2.0.4, que vous pouvez télécharger.

    Le futur de GIMP et notre financement participatif

    Le développement de GIMP bat vraiment son plein et nous annonçons régulièrement les nouveautés ou améliorations à venir sur les réseaux sociaux (par exemple ZeMarmot ou GIMP sur Twitter ; oui je sais, ce n’est pas du réseau libre !).

    Entre la prise en charge des calques de texte vertical, divers filtres de plus en plus évolués, des améliorations conséquentes de réactivité de GIMP (plus de calculs asynchrones, du MIP mapping, des discussions sur du cache plus intelligent de rendu, etc.) et bien plus, on est extrêmement heureux à l’association LILA, studio d’animation à but non lucratif qui produit le film libre ZeMarmot, d’être partie intégrante, et même moteur, de ce renouveau.
    Pour que cela puisse continuer, notre association finance ce projet collaborativement. Voici un petit aperçu de nos projets à moyen terme :

    Financement collaboratif de la gestion des extensions dans GIMP

    Récemment, nous avons un peu fait la promotion de mon développement en cours pour de la gestion avancée d’extension : chercher, installer, mettre à jour et désinstaller des extensions de développeurs tiers en quelques clics.

    Rien de révolutionnaire techniquement, on connaît tous cela, par exemple, dans tout navigateur Web moderne ou beaucoup d’autres logiciels. GIMP, de son côté, avait des extensions mais aucun serveur de dépôt pour développeurs tiers, ni aucun système de gestion. Je travaille à changer cela. Cela pourra faire son apparition, si possible, dès une sortie de GIMP 2.10.x.

    Vous pouvez lire mon article détaillé pour en savoir plus.

    GIMP pour l’animation

    Bien sûr, je continue à travailler sur notre greffon d’animation, même si malheureusement le temps a énormément manqué ces derniers mois.

    Mais pour l’animation, il n’y a pas que cela qui nous pose problème. Améliorer GIMP avec des fichiers très gros, de dizaines voire centaines de calques est un enjeu important pour nous. Les rendus doivent aussi être le plus rapide possible pour un travail efficace. Permettre la multi‐sélection de calques pour une gestion efficace de fichiers complexes est aussi un projet sur lequel je travaille.

    Et ainsi de suite. Ce que nous développons dans GIMP est en fait bien moins spécifique que ce que certains semblent penser, et est extrêmement utile, voire primordial, pour la plupart des professionnels ou amateurs éclairés.

    GIMP 3 : un nouveau monde

    En parallèle, je travaille beaucoup sur GIMP 3, dont les possibilités sont excitantes. Déjà, je suis celui qui travaille sur la prise en charge des écrans haute densité (j’étais déjà celui qui avait apporté une prise en charge « minimale » dans GIMP 2.10, même s’il faut bien comprendre que celle‐ci n’est qu’une succession de bidouilles, puisque GTK+ 2 n’a pas de prise en charge native).

    Je travaille aussi sur l’amélioration de la peinture numérique, une meilleure prise en charge des tablettes graphiques et de certaines de leurs fonctionnalités plus avancées, ainsi que de meilleures configurations par défaut.

    Je prévois aussi de travailler sur la prise en charge du « toucher » dans GIMP, par exemple pour la rotation du canevas, le zoom ou le panning avec la gestuelle.

    Du code maintenu

    J’ai une liste de choses que je souhaite faire si grande que je ne vais pas continuer à vous la lister. Mais, surtout, ce que nous apportons est la professionnalisation de GIMP. Nous avons commencé à contribuer car il était instable et inadéquat pour du travail professionnel. De nos jours, il est extrêmement stable et adéquat. Nous l’utilisons donc maintenant quotidiennement dans un contexte professionnel et surtout nous le maintenons. Ce n’est pas du lâcher de fonctionnalité pour ensuite laisser des bénévoles avec peu de temps gérer les bogues et les plantages. À l’inverse même, la maintenance, la correction de bogues, la gestion des tickets et les revues de code me prennent plus de temps que le développement de nouveau code.

    En fait, mon rêve à moyen terme serait que notre financement puisse grandir suffisamment pour engager davantage d’artistes ainsi que d’autres développeurs (pour non seulement travailler sur GIMP, mais aussi Blender, Inkscape, KDEnlive, Synfig, ou qu’importe le logiciel libre que nous utilisions à un moment donné).

    Vous souhaitez financer notre travail pour améliorer le logiciel libre en créant des films libres ? Nous vous attendons sur ces plates‐formes :

    • Tipeee, pour financer en euros ;
    • Patreon, pour financer en dollars des États‐Unis.

    Alternativement, notre page de donation indique comment donner sur Paypal, ou par donation en virement bancaire à l’association LILA (en revanche, Liberapay est en pause et il vaut donc mieux l’éviter pour le moment, même s’il est toujours dans la liste).

    Merci !

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    20 ans de LinuxFr.org : entretiens avec les visiteurs (5)

    Linux France - Mercredi 1 Août

    Le 28 juin 2018, le site LinuxFr.org fêtait ses 20 ans. L’équipe du site a réalisé des entretiens par courriel avec des visiteurs (et contributeurs) réguliers du site. Les réponses sont publiées par lot de 5 répondants, et dans ce nouveau lot (reynum, M4rotte, devnewton, serge-ss-paille et vejmarie), les répondants sont interviewés pour la première fois.

    Les questions de chaque entretien sont les suivantes :

    • Quand et comment avez‐vous connu LinuxFr.org ?
    • Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?
    • Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?
    • Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?
    • Contribuez‐vous à des projets libres, et si oui, lesquels ?
    • Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?
    • À votre avis, à quoi ressemblera LinuxFr.org dans 20 ans ? Le Libre dans 20 ans ?
    • Quel serait l’environnement / la configuration de vos rêves ?
    • Autre chose à rajouter ?

    Quand et comment avez‐vous connu LinuxFr.org ?

    reynum (compte créé en 2010) : Je ne sais plus quand exactement j'ai découvert LinuxFr.org ; je crois que le nom était DLFP mais, en tout cas, j'ai commencé à y aller régulièrement vers 2010 en lisant les dépêches Noyau de patrick_g<.

    M4rotte (compte créé en 2002) : Comment, ça je ne m’en rappelle plus, peut-être via un moteur de recherche… Premier journal fin 2002 : 15 ans plus tard je travaille dans une entreprise qui utilise une majorité de logiciels libres.

    devnewton (compte créé en 2010) : j'ai connu LinuxFr.org au début des années 2000, je cherchais de l'aide pour installer je ne sais plus quelle distribution, peut-être Debian ou Slackware je ne me souviens plus.
    À l'époque je n'avais pas de connexion Internet à la maison, je téléchargeais les articles depuis un poste de mon école pour pouvoir les lire le soir. Je privilégiais les sites avec peu d'images et beaucoup de texte pour que ça tienne sur une disquette !
    J'ai mis environ 10 ans avant d'arrêter le mode lecture seule, créer un compte et publier mon premier nourjal pour annoncer la démo de Newton Adventure.

    serge-ss-paille (compte créé en 2008) : Aucune idée ! Premier journal posté il y a 6 ans, ça c'est sûr, donc… avant ? Probablement lors de ma découverte tardive de Linux, en école d'ingé, grâce à un sympatique membre du Resel.

    vejmarie (compte créé en 2009) : oula bonne question. Il y a probablement longtemps, j'utilise GNU/Linux depuis 1996 je dirais (oups me voilà vieux) et suis son actualité sur divers sites, dont LinuxFr.org !

    Quelle est votre utilisation du site, en termes de fréquence, de méthode de consultation (navigateur, flux Atom/RSS, mobile, etc.) ? Quels sont les contenus (dépêches, journaux, sondages, forums, wiki, liens) que vous lisez ? Ceux que vous préférez ?

    reynum : Dans toutes mes sessions Firefox sur les différents ordi que j'utilise j'ai au moins un onglet journaux et un dépêches, j'y vais quasi quotidiennement en semaine, c'est ma veille techno en somme. À une époque je le lisais par RSS mais être privé des commentaires qui sont souvent très intéressants (parfois même plus que le contenu) m'a fait revenir sur le site.

    M4rotte : Les journaux et les forums. Je lis les dépêches, mais j’y commente moins, je ne souhaite pas forcément y mettre des commentaires peu pertinents ou hors-sujets, vu que c’est la partie la plus visible du site, la vitrine en quelque sorte. Dans les journaux je peux me permettre d’être plus libre, et disons-le, de dire des conneries parfois.

    devnewton : J'utilise tous les jours l'incubateur d'excellence de LinuxFr.org via mon coincoin jb3 pour suivre l'actualité ou demander l'aide des meta-experts. Je regarde aussi les journaux, les dépêches et depuis peu les liens quotidiennement. Je participe aux sondages de temps en temps. Je contribue un tout petit peu au wiki sur tout ce qui touche à la moulosphère. Je n'utilise presque jamais les forums.
    La tribune est vraiment ma section préférée : je trouve l'expression le site à côté de la tribune plus pertinente que jamais.

    serge-ss-paille : J'ai tenté un temps le flux RSS, mais j'aime venir picorer en manuel, donc dès qu'il y a une petite envie de moule, hop, je sais que sur LinuxFr.org la marée est souvent basse. Je lis principalement les journaux, il y règne une bonne humeur potache et le niveau technique est chouette. Celui des blagues aussi d'ailleurs. Je dirais Journaux > Dépêches > liens > forums

    vejmarie : Je suis assez occupé nous dirons (chef d'entreprise, c'est assez chronophage), je dirais que je visite le site une fois par mois, en consultant principalement les journaux via navigateur. Je ne participe que très très rarement aux commentaires, mais apprécie lire leurs contenus et le partage d'opinion qui en découlent. Je voyage beaucoup et il m'arrive de « grabber » le site avant un long vol…

    Quel est votre meilleur souvenir sur LinuxFr.org (avec un lien, si possible) ? Pensez‐vous que c’était mieux avant ?

    reynum : Je n'ai pas de particulièrement bon souvenir si ce n'est mon premier journal bien noté et ma récente première dépêche (qui m'a valu un cadeau).
    Je ne sais pas si c'était mieux avant car sur LinuxFr.org « c'était mieux à vent »

    M4rotte : Pas de souvenir de ce genre mais LinuxFr.org c’est toujours aussi bien.

    devnewton : Mes meilleurs souvenirs datent de la période où je développais Newton Adventure: je faisais des journaux voire des dépêches régulièrement pour avoir des retours. Les échanges, même trollesques, étaient toujours intéressants.
    Je ne trouve pas que c'était mieux avant : la refonte en Ruby a fait du bien au site et il y a toujours ce mélange de techniques, de cinéma, de recettes de cuisine et de nécrologies qui est l’âme du site.
    Le plus important est que le meilleur est à venir. Grâce à IPOT, je sais que j'aurai d'excellents souvenirs de la refonte en Java, de la sortie de gcoincoin et de la mort de Charles Bronson.

    serge-ss-paille : Je suis plutôt jeune sur le site, je ne tiens pas de calendrier de l'avent. Meilleurs moments : le concours de jeux de mots informatiques, j'étais tout fou ! Dans un autre registre, quand j'ai vu mon thème beamer pacman (celui du premier journal) utilisé dans une conf. Je me suis dit, ah oui c'est ça LinuxFr.org, une communauté de joyeux drilles dispersée dans la francophonie.

    vejmarie : Même opinion que M4rotte LinuxFr.org c'est toujours super !

    Qu’aimeriez‐vous trouver sur LinuxFr.org qui n’y figure pas ? Quel type de contenu ou de fonctionnalités rêveriez‐vous de voir arriver ?

    reynum : Souvent je me dis qu'une section dédiée tutoriels (pas le wiki que je trouve peu adapté) serait un plus, compte tenu de la forte technicité de nombreux lecteurs/contributeurs.
    L'hébergement local des images serait pas mal cela éviterait qu'elles soient supprimées des sites sur lesquels on les dépose, créant du coup des pages amputés d'une partie de leur contenu.

    (pas de réponse de M4rotte à cette question)

    devnewton : J'aimerais lire plus de contenus dédiés aux arts numériques sur LinuxFr.org : graphisme 2D/3D, musique assistée par ordinateur, montage vidéo… Pas seulement sur les logiciels, mais aussi sur les techniques ou les projets d'art libre, peut-être en lien avec opengameart ?

    serge-ss-paille : J'aime bien les journaux techniques, je suis sûr que plus de gens pourraient se lancer et partager leurs découvertes et leurs expériences.

    (pas de réponse de vejmarie à cette question)

    Contribuez‐vous à des projets libres, et si oui, lesquels ?

    (pas de réponse de reynum à cette question)

    M4rotte : Non, plus depuis un moment. Mais les quelques scripts que je développe dans le cadre de mon travail ainsi que mes « bricolages à visée didactique » (quelques projets personnels encore au stade alpha) sont libres.

    devnewton : Oui, les miens :-)

    serge-ss-paille : principalement aux miens, et des rapports de bugs, parfois avec un patch, de temps en temps. Au taf j'ai la chance de pouvoir contribuer à LLVM.

    vejmarie : Principalement FreeCAD, et linuxboot

    Si vous deviez mettre un coup de projecteur sur un ou plusieurs projets libres, lesquels citeriez‐vous ?

    (pas de réponse de reynum à cette question)

    (pas de réponse de M4rotte à cette question)

    devnewton : Ça n'est pas très gentil, ça doit faire mal !
    Quoi qu'un bon coup sur la Mofo serait utile pour lui rappeler que si Firefox est formidable, il ne faut pas le pourrir avec des DRM et des publicités.
    Plus sérieusement, celui qui mérite de l'attention, c'est Delta Chat : l'idée de faire une messagerie instantanée réellement interopérable en se basant sur les emails, même si techniquement c'est moins propre qu'un nouveau protocole, permettrait d'avoir tout le monde et pas seulement un nième sous sous sous ensemble des gens. Vivement une implémentation dans Roundcube ou Thunderbird!

    serge-ss-paille : (La blague de devnewton m'a fait rire). Pour les amateurs de combinaison moulante, je suis fan du peu connu latex-make. Et pour la vie de tous les jours, deux projets pas ultra révolutionnaires ni particulièrement récents mais qui font juste le taf et bien leur taf : pal et devtodo.

    vejmarie : Aussi bizarre que cela puisse paraitre je prendrai le projet Open Compute, même si ce n'est pas un projet logiciel, l'Open Hardware est le parfait complément des logiciels libres qui peuvent lui apporter beaucoup.

    À votre avis, à quoi ressemblera LinuxFr.org dans 20 ans ? Le Libre dans 20 ans ?

    (pas de réponse de reynum à cette question)

    (pas de réponse de M4rotte à cette question)

    devnewton : Dans 20 ans LinuxFr.org sera un site rencontre alternatif suite au rachat par Microsoft.
    Ce dernier aura aussi profondément changé le libre en releasant Windows sous GPL et en adoptant Gnome 3 comme GUI.

    serge-ss-paille : Dans 20 ans j'aurai la peau toute fripée et LinuxFr.org sera toujours consultable depuis lynx, c'est beau. Et comme beaucoup de belles idées, le libre ce sera professionnalisé pour devenir une industrie, mais l'esprit du libre vivra dans des petits groupes dont LinuxFr.org fera partie :-)

    vejmarie : oula dans 20 ans j’espère être à la retraite et pourquoi pas être un gros contributeur au site. Le libre va perdurer et probablement rentrer dans des domaines insoupçonnés avec une bonne association avec du hardwarematériel.

    Quel serait l’environnement / la configuration de vos rêves ?

    (pas de réponse de reynum à cette question)

    (pas de réponse de M4rotte à cette question)

    devnewton : XFCE / un PC, un clavier, une souris

    serge-ss-paille : un croisement entre enlightenment et awesome. Ce serait éblouissant et génial.

    (pas de réponse de vejmarie à cette question)

    Autre chose à rajouter ?

    devnewton :

    serge-ss-paille :

    v = i = e = lambda coin : coin @v @i @v @e def LinuxFr(): return 'Eviv gro.rFxuniL' Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    De la lecture offerte par le groupe Transcriptions de l'April pour vos vacances

    Linux France - Mardi 31 Juillet

    Le groupe Transcriptions de l'association April s'est fixé comme mission de transformer en version texte des enregistrements audio et vidéo concernant le logiciel libre et les libertés numériques en général.

    La version texte de ces fichiers audio et vidéo permet :

    • d’augmenter leur indexation sur les moteurs de recherche ;
    • d’améliorer leur accessibilité aux personnes porteuses de handicaps ;
    • de retrouver les propos exacts des intervenants, les utiliser sans trahir leur pensée en citant fidèlement la source ;
    • enfin de permettre à chacun et chacune de « lire » ces conférences, émissions de radio, etc.

    Pour cette période de vacances ce sont environ 40 heures d'enregistrements divers qui ont été transcrites et publiées depuis le mois de janvier 2018, qui vous sont offertes et qui, nous le souhaitons, feront partie de vos lectures d'été.

    Et puis, n'hésitez pas à rejoindre notre groupe et à participer !

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Revue de presse de l'April pour la semaine 30 de l'année 2018

    Linux France - Mardi 31 Juillet

    La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

    Sommaire

    [ZDNet France] De Linux à Windows: une partie de l'Allemagne bascule

    Par David Meyer, le jeudi 26 juillet 2018. Extrait:

    Après être passé en 2006 de Solaris à Linux, le land allemand de Basse-Saxe veut à présent migrer 13.000 postes de travail d'OpenSuse vers Windows, vraisemblablement Windows 10. Justification avancée: la standardisation des OS.

    Lien vers l'article original: https://www.zdnet.fr/actualites/de-linux-a-windows-une-partie-de-l-allemagne-bascule-39871733.htm

    Et aussi:

    [Next INpact] Le gouvernement lance des «états généraux des nouvelles régulations numériques»

    Par Xavier Berne, le jeudi 26 juillet 2018. Extrait:

    Le gouvernement vient d'annoncer le lancement d’une série de consultations destinées à mûrir la position de la France en matière de régulation du numérique (sous les angles économiques, sociétaux, etc.). Ces «états généraux» sont censés aboutir «début 2019».

    Lien vers l'article original: https://www.nextinpact.com/news/106898-le-gouvernement-lance-etats-generaux-nouvelles-regulations-numeriques.htm

    [Podcast Journal] Contre le monopole des GAFAM, le logiciel libre

    Par la rédaction, le mardi 24 juillet 2018. Extrait:

    Google, Apple, Facebook, Amazon, Microsoft sont souvent épinglés pour leur utilisation de nos données personnelles ou encore sur les bénéfices énormes qu'ils font dans les pays sans y reverser d'impôts. Difficile pourtant de lutter contre leur omniprésence sur le web et dans le monde de l'informatique. L'utilisation de logiciels libres apparaît peu à peu comme leur meilleure alternative.

    Lien vers l'article original: https://www.podcastjournal.net/Contre-le-monopole-des-GAFAM-le-logiciel-libre_a25566.html

    [ZDNet France] LibreOffice sur le Microsoft Store: The Document Foundation dénonce

    Par la rédaction, le mardi 24 juillet 2018. Extrait:

    La suite bureautique libre sur la plate-forme logicielle de Windows 10? Pendant quelques jours un tiers à utilisé ce stratagème pour faire payer les internautes. Sans que The Document Foundation n'approuve l'initiative.

    Lien vers l'article original: https://www.zdnet.fr/actualites/libreoffice-sur-le-microsoft-store-the-document-foundation-denonce-39871641.htm

    [Developpez.com] Explosion des prix de Google Maps: le département de Maine-et-Loire abandonne Google

    Par Michael Guilloux, le lundi 23 juillet 2018. Extrait:

    Début mai, Google a annoncé une refonte complète de son offre cartographique à destination des professionnels. Ces changements, qui impliquent de renseigner obligatoirement un code de carte bleue, se traduisent par une explosion des prix pour les usages professionnels avec une réduction drastique du volume d’affichages gratuits autorisés.

    Lien vers l'article original: https://www.developpez.com/actu/215961/Explosion-des-prix-de-Google-Maps-le-departement-de-Maine-et-Loire-abandonne-Google-pour-OpenStreetMaps-un-service-de-cartographie-open-source

    Et aussi:

    [ZDNet France] PeerTube: l'hébergement libre de vidéos est sur les rails

    Par Thierry Noisette, le lundi 23 juillet 2018. Extrait:

    Soutenu par Framasoft, PeerTube a réussi haut la main son appel à crowdfunding. Cet hébergement de vidéo décentralisé devrait se doter dans quelques mois de fonctionnalités améliorées.

    Lien vers l'article original: https://www.zdnet.fr/blogs/l-esprit-libre/peertube-l-hebergement-libre-de-videos-est-sur-les-rails-39871579.htm

    [Miroir Mag] Six clichés qui vous empêchent de vous mettre au logiciel libre

    Par la rédaction, le lundi 23 juillet 2018. Extrait:

    Encore mal connus, les logiciels libres continuent de faire peur aux utilisateurs. Doutes sur la fiabilité, nécessité de compétences techniques, habitude des autres systèmes… Autant de freins à leur généralisation. Pourtant, ces logiciels que chacun est libre d’utiliser, modifier ou partager pourraient amener de nombreux bienfaits, s’ils étaient utilisés de manière globale.

    Lien vers l'article original: https://www.miroir-mag.fr/technologie/six-cliches-qui-vous-empechent-de-vous-mettre-au-logiciel-libre

    [zonebourse] Le DevOps – la prise de pouvoir de l’Open Source

    Par Jan Gabriel, le lundi 23 juillet 2018. Extrait:

    S'il y a un débat public sur le fait qu'un outil puisse ou ne puisse pas être un «outil DevOps», nous pouvons néanmoins constater que les thèmes phares du DevOps - Agilité, Automatisation, Collaboration - se recoupent fort bien avec ceux du mouvement Open Source.

    Lien vers l'article original: https://www.zonebourse.com/ITS-GROUP-5096/actualite/ITS-Le-DevOps-ndash-la-prise-de-pouvoir-de-l-rsquo-Open-Source--26978275/

    [Libération] Contre Google, cherchez encore

    Par Christophe Alix, le dimanche 22 juillet 2018. Extrait:

    Au regard de la surface financière acquise par Google, l’amende que vient de lui infliger l’Union européenne, pour record qu’elle soit, a tout d’une goutte d’eau dans un océan de dollars. Que représentent en effet 4,3 milliards d’euros au regard d’une capitalisation boursière qui dépasse les 700 milliards d’euros et d’une trésorerie qui avoisine les 100 milliards ?

    Lien vers l'article original: http://www.liberation.fr/france/2018/07/22/contre-google-cherchez-encore_1668138

    Et aussi:

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Elixir, Phoenix et Membrane

    Linux France - Lundi 30 Juillet

    Elixir est un langage de programmation dont la version 1.7 vient de sortir. Il est notamment utilisé par 2 frameworks : Phoenix pour le web et Membrane Framework pour le streaming multimédia. Ces 3 projets sont présentés dans la seconde partie de la dépêche.

    Elixir

    Elixir est un langage de programmation fonctionnel et dynamique. Il s'appuie sur la machine virtuelle d'Erlang, avec une syntaxe inspirée de Ruby et pas mal de bonnes idées prises d'autres langages (les docstrings de Python par exemple).

    Elixir profite de la machine virtuelle d'Erlang, connue pour ses aspects distribués, résistants aux erreurs et sa faible latence. En particulier, il reprend les processus légers (l'équivalent des goroutines de Go) :

    current_process = self() # Crée un nouveau processus léger d'Elixir spawn_link(fn -> send current_process, {:msg, "hello world"} end) # Attend jusqu'à la réception d'un message receive do {:msg, contents} -> IO.puts contents end

    Un autre point fort d'Elixir est son outillage, avec notamment mix, l'outil de build, hex, le gestionnaire de packages, et iex, la console interactive. ExUnit, le framework de test, profite des macros d'Elixir, qui permettent d'écrire des DSL, pour avoir des tests concis avec des rapports d'erreur compréhensibles :

    defmodule SampleTest do use ExUnit.Case, async: true test "test the truth" do assert "fox jumps over the lazy dog" == "brown fox jumps over the dog" end end

    Phoenix

    Phoenix est un framework web, l'équivalent de Ruby on Rails pour Elixir. Par rapport à Rails, il a abandonné le côté magique tout en ayant quand même réussi à garder le sentiment de productivité que l'on peut avoir en développant avec. En particulier, Ecto, la bibliothèque de persistance des données, est souvent vue comme plus solide qu'ActiveRecord. Enfin, Phoenix bénéficie d'Elixir et de la plateforme Erlang : ses temps de réponses pour des pages avec peu d'interactions avec la base de données sont généralement sous la milliseconde, là où on est plutôt à quelques dizaines de millisecondes avec Rails.

    Membrane Framework

    Membrane Framework sert à construire des applications côté serveur pour les flux multimédia. Il met l'accent sur la fiabilité et la concurrence, et ce n'est donc pas très étonnant qu'il soit développé en Elixir (avec un peu de C toutefois).

    Membrane Framework se compare à gstreamer. D'après les dires de leurs développeurs, ils ne cherchent pas à couvrir tous les cas et formats que gstreamer peut couvrir et préfèrent se concentrer sur la qualité.

    NdA : j'ai déjà utilisé un peu Elixir et Phoenix, mais je ne fais que relayer des informations lues sur le site officiel de Membrane Framework car le projet me semble intéressant. Si des lecteurs ont un avis plus éclairé, je les encourage à le faire partager dans les commentaires.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Pages

    S'abonner à Association Linux Azur agrégateur