Linux (fr)

  • Agenda du Libre pour la semaine 34 de l'année 2017 (Dépêches LinuxFR)

    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 10 événements (0 en Belgique, 9 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

    [QC Montréal] (3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres, de niveau débutant - Le lundi 21 août 2017 de 18h00 à 21h00.

    (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 et votre bonne humeur. Venez jaser sur les logiciels libres, Nous montrer vos découvertes, poser vos questions?

    [FR Reims] G.L.O.U. - Le mardi 22 août 2017 de 18h00 à 20h30.

    Le G.L.O.U. est l'occasion de boire un coup entre amis des libertés, et de discuter de tout et de rien.

    Nous vous proposons de se retrouver, pour cette deuxième période de vacances estivale, autour d'un verre, mardi 22 août 2017 à 18h00.

    Lieu : Grand comptoir de Reims à l'intérieur de la Gare de Reims centre.

    [FR Grenoble] Atelier de la Guilde - Le mardi 22 août 2017 de 19h00 à 23h00.

    GUILDE (Guilde des Utilisateurs Linux du Dauphiné) est une association loi 1901 qui s'est fixée pour objectifs de promouvoir le système Linux auprès des particuliers et des professionnels, de rassembler les utilisateurs de Linux de la région du Dauphiné.

    Nous souhaitons faire naître des projets, des initiatives et créer des groupes de travail qui bénéficieront aussi bien à Linux qu'à ses utilisateurs.

    Notre région est riche en entreprises de haute technologie, centres de recherches, universités et sociétés de services qui utilisent déjà Linux.

    Par leur biais nous avons l'opportunité de faire connaître l'une des innovations logicielles les plus marquantes de ces dix dernières années.

    [FR Chartres] OpenAtelier - Le mercredi 23 août 2017 de 20h00 à 23h59.

    L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

    Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

    Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

    [FR Toulouse] Rencontre Tetalab - Le mercredi 23 août 2017 de 21h00 à 23h00.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Cognac] Journées estivales d'initiations de 3LC - Du vendredi 25 août 2017 à 09h00 au dimanche 27 août 2017 à 17h00.

    Dernier rendez vous pour la période estivale. Sur 3 jours Vendredi 25, Samedi 26 et Dimanche 27 Aout Les bases de la programmation (à partir de 14 ans).

    • Initiation à la programmation structurée Faire un programme bash (téléchargement automatique de fichiers sur un site internet)
    • Initiation à la programmation fonctionnelle Faire un programme en C (créer une liste de mots du dictionnaire … et comprendre pourquoi il faut avoir des mots de passes fort…)
    • Initiation à la programmation orientée Objet Avec Python créer un interface graphique en quelques lignes / Avec Java gérer un tas de 52 cartes

    Si vous êtes intéressés par une de ces journées, vous pouvez vous inscrire dès maintenant en envoyant un mail à l'adresse ci dessous.

    Dès aujourd'hui vous pouvez aussi noter, la date du Samedi 28 Octobre
    Initiation à l'utilisation d'internet avec des outils libre et initiation à la Neutralité du Réseau.

    [FR Villeneuve d'Ascq] Libre à Vous - Le samedi 26 août 2017 de 09h00 à 12h00.

    Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres?

    Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.

    C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

    Entrée Libre. Tout Public.

    [FR Valenciennes] Permanence ValLibre - Le samedi 26 août 2017 de 09h30 à 12h00.

    Permanence assistance informatique.

    Dépannage petits bobos informatiques.

    Initiation à l'informatique libre.

    Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

    Si besoin particulier, la prise de rendez-vous est fortement conseillée.

    Téléphone accueil MQCV : 03 27 22 43 90

    [FR La Couronne] Permanence - accueil public - Le samedi 26 août 2017 de 10h00 à 13h00.

    Notre permanence d'accueil avec le sourire, le café et les gâteaux !

    Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

    Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

    Entrée Libre. Tout Public.

    [FR Valenciennes] Atelier (wiki) HainautPédi@ - Le samedi 26 août 2017 de 10h00 à 12h00.

    Atelier pour les contributions au wiki territorial HainautPédi@

    http://hainautpedia.vallibre.fr

    Les ateliers HainautPédi@ sont organisés pour que les contributeurs se rencontrent et fassent évoluer ensemble le contenu du wiki.

    Ces séance sont à accès libre, elles permettent également aux personnes intéressées de prendre contact avec la communauté afin d'apprendre concrètement le fonctionnement du projet.

    Lors d'un atelier, des machines sont accessibles pour compléter le wiki ou simplement expérimenter.

    Rendez-vous à l'espace numérique de la bibliothèque municipale de Valenciennes. Dernier samedi du mois.

    Lire les commentaires

  • Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ? (Dépêches LinuxFR)

    Terminal Overload est un FPS (First Person Shooter) libre multijoueurs, qui se déroule dans un univers abstrait et futuriste. C'est un successeur de Revenge Of The Cats: Ethernet, sorte de mix entre KernelPanic et Warsow avec un rendu de type filiforme qui peut rappeler Tron. Les binaires 32 bits pour Windows et Linux sont fournis ainsi que le code source à compiler.

    logo TO

    Un financement participatif (crowdfunding) avait été lancé par l'auteur de Revenge Of The Cats: Ethernet, Michael Goldener, le 6 décembre 2013 avec pour but de libérer l'ensemble du jeu dont le moteur n'était pas entièrement libre.

    Torque3D, une version moderne et libre du moteur était apparue et fût adoptée. Le but de l'appel à financement était donc de porter le jeu sur ce moteur. Le financement ayant été atteint, un fork a été créé et la version 0.1 sortie le 1 août 2014 sous le nom de Terminal Overload.

    Il utilise donc désormais le moteur Torque3D sous licence MIT (au lieu du moteur Torque Game Engine). La licence du code est la GPL-v3 et les données sont sous Creative Commons Attribution 4.0 International.

    Malheureusement, il n'y a plus d'activité depuis le 5 février 2016.
    Y aurait-il un repreneur dans la salle ?

    Lire les commentaires

  • Haiku a 16 ans (Dépêches LinuxFR)

    Le 18 août 2001, le premier message sur la liste de diffusion d’OpenBeOS était envoyé par Marcus Overhagen (« Ok, let’s start »). 16 ans plus tard, le projet est toujours là, même si les versions se font rares. Faisons donc un point annuel sur les derniers développements et ce qu'il se passe dans le projet.

    Sommaire

    Rappels sur le projet Haiku

    Haiku est un système d'exploitation pour les ordinateurs de bureau (on ne vise ni les serveurs, ni les téléphones et tablettes, pour le moment). Il fonctionne sur les plateformes x86 (32 et 64 bits) et est compatible avec BeOS (au niveau binaire pour la version 32 bits, en recompilant les applications pour la version 64 bits).

    L'objectif du projet est de continuer là ou BeOS s'est arrêté, et de fournir un système d'exploitation facile à utiliser, réactif et efficace. Et bien sûr, de permettre à tous les développeurs intéressés de se lancer dans un projet de grande envergure et de découvrir l'intérieur d'un système d'exploitation.

    Haiku est écrit principalement en C++, et tous les composants (noyau, pilotes, applications, serveur graphique, etc.) sont réalisés par la même équipe, ce qui simplifie les possibilités d'intégration entre les différents composants. Il n'est pas encore complètement compatible POSIX, mais ça avance petit à petit.

    En route pour la bêta

    La feuille de route de Haiku

    Lors de la création du projet, l'objectif pour la version 1 de Haiku était simple: « fournir un système 100 % compatible avec BeOS R5 (la dernière version officielle publiée) et qui remplace complètement ce dernier ».

    Des jalons ont été définis: la première version « alpha » ne serait publiée que lorsque le système serait suffisamment avancé et stable pour pouvoir se compiler lui-même. La première version « bêta » ne serait publiée que lorsque toutes les API de BeOS R5 seraient implémentées (même s'il restait des bugs).

    Après la première version Alpha, les objectifs de la version 1 ont été réexaminés. En effet, cette version n'est arrivée qu'en 2009, et déjà à ce moment il était clair que BeOS était un système vieillissant et que le reproduire à l'identique ne serait pas suffisant. Une consultation parmi les développeurs de Haiku ainsi que parmi les utilisateurs a donc permis d'ajouter de nombreux points à la liste des fonctions nécessaires pour la version 1 (et donc pour la version beta1, qui doit comprendre les mêmes fonctionnalités).

    Cette feuille de route élaborée dans l'enthousiasme de la sortie de la première version alpha était peut-être un peu trop ambitieuse. Cependant, la plupart des fonctionnalités prévues (support du Wifi, par exemple) sont effectivement arrivées.

    L'infrastructure de publication des paquets

    C'est le gros point bloquant pour la prochaine release.

    L'un des derniers points restant était « il doit être possible de mettre à jour le système sans tout réinstaller ». Après de longues discussions entre les développeurs et avec la communauté, la solution retenue fut de réaliser un gestionnaire de paquets, qui pourrait mettre le système à jour. Ce dernier présente quelques propriétés intéressantes, en particulier, les paquets ne sont pas extraits comme pour la plupart des systèmes existants, mais montés dans un système de fichiers virtuel. Ceci permet une installation et une désinstallation très rapide, et sans utiliser d'outils spécifiques (il suffit de copier le paquet dans le dossier /system/packages prévu à cet effet).

    Cependant, le gestionnaire de paquets est inutile si personne n'est capable de publier un dépôt de paquets et de le tenir à jour. Le projet Haiku espérait que ce serait fait par d'autres. En particulier, HaikuWare (le site sur lequel on trouvait la plupart des logiciels pour Haiku) et HaikuPorts (l'outil permettant de compiler des logiciels à partir des sources pour Haiku) auraient pu répondre à cette demande. Cependant, le responsable de HaikuWare n'a pas du tout aimé le système de gestion de paquets (jugé trop complexe pour les développeurs) et a finalement décidé de fermer son site et de cesser tout soutien à Haiku. Quant à HaikuPorts, l'outil à été mis à jour pour générer des paquets plutôt que d'installer les fichiers directement sur le système. Cependant, ce travail a été réalisé par les développeurs de Haiku et cette "intrusion" dans le développement de l'outil a fini par causer le départ du principal mainteneur de HaikuPorts. Les développeurs de Haiku se retrouvent donc seuls en charge de tout l'écosystème de logiciels.

    En dehors de ces soucis d'infrastructure, il y a également du travail pour les outils graphiques permettant de gérer les dépôts et les logiciels installés. Dans Haiku, il y a plusieurs logiciels prévus à cet effet :

    • HaikuDepot, qui est un magasin d'application un peu comme ceux que l'on trouve sur les smartphones ou Synaptic sur Debian. Il permet d'explorer la liste des logiciels avec captures d'écrans et description, ainsi que les notes et commentaires d'autres utilisateurs. En plus du dépôt de paquet, il repose sur un webservice indépendant qui se charge uniquement des métadonnées (commentaires, notes, icônes, captures d'écran) qui ne sont pas présentes dans le paquet logiciel lui-même.
    • Repositories, l'application de préférences qui permet de choisir les dépôts de logiciels que l'on veut utiliser. En plus des dépôts officiels fournis par Haiku et HaikuPorts, il existe à présent plusieurs dépôts complémentaires permettant la distribution de nombreux logiciels.
    • Enfin, SoftwareUpdater se charge de surveiller et de notifier la disponibilité de mises à jour pour le système et pour les applications.
    • Et bien sûr pkgman, l'outil en ligne de commande équivalent d'apt ou yum, est toujours présent et permet de faire tout ça sans cliquer.

    Le support du 64 bits et le passage à gcc 6

    La dernière version alpha 4 de Haiku n'était disponible que pour les machines 32 bits. A l'époque, le support du 64 bits était encore considéré expérimental et nous avions choisi de ne pas le publier dans une version officielle tout de suite.

    Cela va changer avec la version beta1, qui sera donc disponible en 32 et 64 bits. Il y a eu récemment des changements sur l'ABI 64 bits (par exemple time_t est passé de 32 à 64 bits pour prévenir le bug de l'an 2038).

    La version 32 bits de Haiku utilise gcc en versions 2.95.3 (pour la compatibilité avec BeOS) et 5.4. La version 64 bits utilise uniquement gcc 5.4. Le passage à gcc6 est en cours, mais comme souvent, cette nouvelle version de gcc apporte de nouvelles optimisations et de nouveaux warnings, qui révèlent des problèmes dans le code de Haiku. Il faut donc être prudent et prendre le temps d'investiguer chacun de ces problèmes avant de pouvoir officiellement mettre à jour la version de gcc supportée.

    HaikuArchives

    http://haikuarchives.github.io/

    L'un des problèmes de Haiku est le manque de logiciels disponibles. En principe, la compatibilité avec BeOS devrait permettre de réutiliser tous les logiciels écrits pour BeOS, mais ceux-ci ne sont plus maintenus. De plus, suite à la fermeture de HaikuWare et de BeBits (les deux principaux sites répertoriant ces logiciels), il était à craindre qu'ils soient perdus pour toujours.

    Le projet HaikuArchives répond à ce problème. Le but de ce projet est de retrouver les auteurs de logiciels pour BeOS et de les convaincre de retrouver leurs sources (c'est le plus difficile) pour les publier (en général ça ne pose pas trop de problèmes), de préférence sous une licence libre.

    Ceci permet d'effectuer au moins une maintenance minimale sur le code, en attendant que les projets soient repris par d'autres développeurs. Cela permet de suivre les petits changements dans l'API, de vérifier que les logiciels compilent toujours avec un compilateur récent et de préparer le passage au 64 bits.

    Développements dans l'année

    Le navigateur web

    Haiku utilise le moteur WebKit (partagé avec Safari et GNOME, entre autres). Le développement de ce moteur est très actif et il est difficile de suivre pour un projet qui n'a pas de développeurs affectés à plein temps pour cela.

    Aussi, Haiku utilise actuellement une version de WebKit datant de début 2016, et commence à rencontrer des problèmes pour cette raison sur certains sites web. Il est donc nécessaire de mettre à jour notre port de WebKit, et des efforts dans ce sens sont en cours.

    D'autre part, le support des protocoles HTTP, HTTPS et gopher mûrit doucement, avec encore de nombreux bugs corrigés.

    Debugger à distance

    « Debugger » est, comme son nom l'indique, le debugger fourni avec Haiku. C'est un outil indispensable pour les développeurs.

    Cependant, il s'agit d'une application graphique et assez complexe, ce qui peut se révéler problématique lorsqu'il s'agit d'investiguer des problèmes dans les composants de Haiku comme le serveur graphique app_server.

    La solution choisie est de permettre d'utiliser Debugger à distance, depuis une autre machine. Le code du debugger est donc adapté petit à petit pour permettre ce fonctionnement à travers le réseau.

    Flux médias

    Haiku propose une implémentation du « Media Kit » de BeOS, qui permet entre autre choses le décodage, la lecture et l'encodage de sons et de vidéos.

    Jusqu'à présent, ce décodage pouvait se faire uniquement à partir d'un fichier ou de données chargées en mémoire. Mais il est maintenant possible de l'utiliser avec des flux ce qui rend par exemple possible la lecture de web radios avec MediaPlayer.

    Support de l'impression

    Pouvoir imprimer des documents est indispensable sur un système de bureau comme Haiku. Bien que la gestion des imprimantes soit présente, il reste encore de nombreux problèmes à traiter avant que cela soit complètement fonctionnel.

    Les pilotes d'imprimantes utilisés sont ceux de gutenprint, qui permet d'assurer la compatibilité avec un assez grand nombre de marques et de modèles. C'est maintenant la dernière version de Gutenprint qui est utilisée pour cela.

    La version 64 bits de Haiku est capable d'imprimer aussi bien que la version 32 bits.

    Un gros nettoyage a été effectué sur les diverses fenêtres de configuration de l'imprimante et de mise en page (gestion des marges, etc), pour les simplifier et les uniformiser entre différentes applications.

    La prochaine étape est de régler tous les problèmes de rendus lors de l'impression d'un document: texte mal positionné, dégradés de couleurs qui disparaissent, par exemple.

    Le « launch daemon »

    launch_daemon est un serveur qui se charge de séquencer le démarrage et l'extinction de la machine (des opérations courantes sur une machine de bureau - surtout que Haiku ne sait pas encore se mettre en veille).

    Il remplace la procédure d'init qui était auparavant implémentée sous forme d'un simple script shell.

    Launch daemon peut lancer plusieurs services en parallèle, en réagissant à des évènements (par exemple, « tous les disques sont montés »). Il permet également de redémarrer un service automatiquement en cas de plantage, et même de mettre en attente les messages envoyés à un service qui n'est pas démarré.

    Ceci permet par exemple de ne démarrer le serveur d'impression que lorsqu'on imprime un document pour la première fois, limitant ainsi le temps de démarrage du système et l'utilisation de la mémoire vive.

    Systèmes de fichiers

    Plusieurs corrections ont été effectuées dans la gestion des systèmes de fichiers.

    BFS, le système de fichier principal de Haiku, avait encore quelques différences avec celui de BeOS, qui sont maintenant corrigées afin d'assurer une complète interopérabilité entre les deux systèmes.

    Divers petits problèmes ont été également corrigés dans le VFS (le code commun à tous les systèmes de fichiers), ainsi que dans rootfs (qui gère le système de fichier racine monté en "/"), devfs (qui gère "/dev" et les fichiers représentants les périphériques), et packagefs (qui gère le montage des paquets logiciels dans un système de fichiers virtuels). Ces corrections permettent d'avoir un meilleur comportement dans des cas inhabituels, par exemple lors d'une tentative d'ouverture en écriture d'un dossier.

    Enfin, du côté des systèmes de fichier réseau, Haiku peut maintenant se connecter à des partages SMB (en plus du NFS qui était déjà présent), permettant d'échanger facilement des fichiers avec d'autres machines présentes sur le réseau.

    Il est également possible d'utiliser le RAM disk, pour y stocker des données non persistantes qui n'ont pas besoin d'être sur un disque dur.

    Des pilotes

    Le support matériel est évidement un problème pour un projet comme Haiku qui fait le choix de ne pas utiliser un système existant. Cette année, les efforts ont porté principalement sur :

    • Le support de xHCI (USB3), qui devient indispensable sur les machines récentes où l'USB2 est en voie de disparition,
    • La mise à jour du pilote intel_extreme, qui pilote toutes les cartes graphiques Intel à partir de la GMA950,
    • Le support de l'UEFI, pour démarrer sur les machines qui n'ont pas de BIOS ; ainsi que le support complet des tables de partitions GPT qui y sont souvent associées,
    • Le support des cartes réseaux virtuelles virtio, permettant de lancer Haiku dans certaines machines virtuelles (Hyper-V, par exemple).
    • Le pilote atheros813x est à jour avec la version de FreeBSD 11. Tous les autres pilotes réseau importés de FreeBSD sont pour l'instant à jour avec la version 9 uniquement.

    Support de l'internationalisation

    Depuis le début du projet, Haiku utilisait la police de caractères DejaVu Sans pour son interface graphique. Cependant, celle-ci ne permettait pas le support de toutes les langues.

    Désormais, c'est la police de caractères Noto qui est installée par défaut, ce qui permet la prise en charge, entre autres, du japonais et du coréen, en plus des langues latines et cyrilliques.

    D'autre part, la méthode de saisie Canna, qui permet de taper du texte en japonais, est maintenant complètement fonctionnelle ; et KeymapSwitcher, qui permet de changer de disposition de clavier par une combinaison de touche, est disponible dans les dépôts de logiciels et sera probablement inclus directement dans la version bêta 1.

    Terminal

    On pourrait penser que ce n'est pas l'application la plus importante, mais les développeurs passent beaucoup de temps en face d'un shell bash.

    Le Terminal de Haiku peut enfin avoir plus de 6 onglets ouverts dans une même fenêtre.

    Plusieurs problèmes apparus avec ncurses 5.9 ont été résolus par l'implémentation de séquences d'échappement manquantes. En particulier, il est possible d'utiliser Nano avec le curseur affiché au bon endroit et tous les caractères visibles.

    Des projets autour de l'OS

    Avoir un système, c'est bien, mais avoir des applications, c'est mieux.

    Portage de Qt5

    Grace aux efforts mis en place pour la gestion des paquets, il est devenu possible de capitaliser les efforts de portage de logiciels et de maintenir en état de marche un grand nombre de bibliothèques portées.

    Cela a rendu possible la reprise du développement de Qt4, puis de Qt5 pour Haiku, ce qui permet de bénéficier de nombreuses applications.

    Bien que l'objectif final de Haiku soit de développer son propre écosystème d'applications, bien intégrées avec le reste du système, les applications Qt permettent d'avoir dès maintenant un système de bureau opérationnel avec des applications fonctionnelles.

    Le port de Qt se complète petit à petit, avec par exemple le support du glisser-déposer, et une apparence qui se rapproche autant que possible de celle des applications natives.

    L'une des applications Qt souvent utilisées est Qupzilla, un navigateur web qui permet de visiter certains sites qui ne fonctionnent pas bien avec le navigateur natif.

    LibreOffice

    Un gros manque sur Haiku est l'absence d'une suite bureautique digne de ce nom. Il existe quelques vieilles applications pour BeOS, en particulier la suite GoBe productive et le tableur Sum-It, mais ils sont loin d'être suffisants, et les sources de GoBe productive ne sont pas disponibles pour la maintenir à jour.

    En conséquence, la solution retenue est d'essayer de porter LibreOffice. C'est un gros travail, mais les premières captures d'écran semblent prometteuses.

    Présence dans les manifestations autour du logiciel libre

    Le projet Haiku reste assez peu connu. La présence dans différentes manifestations autour du logiciel libre nous permet de nous faire connaître, et d'essayer d'attirer de nouveaux développeurs.

    C'est aussi l'occasion d'aider certains projets à porter leurs applications sur Haiku lorsque cela est possible et pertinent.

    FOSDEM

    Cette année nous avons partagé un stand avec ReactOS, un projet aux objectifs similaires puisqu'il s'agit d'un système d'exploitation libre compatible avec Windows.

    https://www.haiku-os.org/blog/mmu_man/2017-02-09_back_from_fosdem/

    mmu_man a donné une conférence sur les idées que les autres bureaux devraient emprunter à Haiku.

    RMLL

    Haiku était également présent aux RMLL, avec un stand et une conférence faisant un point sur les progrès vers la prochaine version bêta de Haiku.

    https://prog2017.rmll.info/programme/cote-utilisateurs-utilisatrices-diversite-des-usages/haiku-pari-la-venue-quand-beta

    https://www.haiku-os.org/blog/mmu_man/2017-08-15_recovering_from_rmll_2017/

    Ce fut également l'occasion de porter QElectrotech vers Haiku et d'essayer de mettre à jour le portage de Pytouhou pour une version un peu plus récente.

    Capitole du Libre

    Haiku était aussi présent au Capitole du Libre, avec un stand, et deux conférences.

    https://2016.capitoledulibre.org/programme.html#ameliorer-la-portabilite-et-lintegration-dapplicat

    https://2016.capitoledulibre.org/programme.html#haiku-lorganisation-dun-projet-libre

    La fin de BeGeistert

    http://begeistert.org/

    BeGeistert était depuis 1998 une conférence autour de BeOS puis de Haiku. Organisée habituellement à Düsseldorf, elle permettait à la communauté de Haiku de se retrouver une fois par an, avec quelques présentations et un coding sprint consistant à enfermer plusieurs développeurs dans une pièce, à secouer, et à voir ce qui ressort.

    Avec un nombre de participants de plus en plus faible, et des coûts de plus en plus élevés pour la location de la salle utilisée, l'association HSA (Haiku Support Association) organisatrice de l'évènement a décidé qu'il n'était plus pertinent de maintenir BeGeistert dans ce format.

    Il n'y aura donc pas de BeGeistert en 2017, mais il y aura tout de même un coding sprint, organisé à Toulouse juste après le Capitole du Libre.

    http://pulkomandy.tk/kdc

    Participation au Google Code-in

    https://codein.withgoogle.com/archive/2016/organization/5146925732986880/

    Le Google Code-In est un programme du bureau de l'open source de Google. Il s'adresse au 13-17 ans, le but étant de leur faire découvrir le logiciel libre et l'informatique en général.

    Cela se présente sous la forme d'un concours où les participants doivent réaliser des contributions à l'un des projets de logiciels libres participants. Les tâches à réaliser peuvent être par exemple la réalisation d'une icône, d'un flyer, d'un fond d'écran, l'écriture de documentation, faire une présentation du projet, ou bien sûr écrire un peu de code pour corriger un bug.

    Haiku est l'un des 3 projets qui a participé tous les ans depuis le lancement du Code-In en 2010 (les deux autres étant KDE et Apertium). En effet, la participation à ce programme demande un gros investissement de la communauté pour accueillir efficacement des participants qui n'ont pas forcément l'habitude du fonctionnement des logiciels libres.

    Haiku a pu gagner quelques nouveaux contributeurs grâce à ce concours, mais les résultats sont surtout à long terme d'encourager la contribution aux logiciels libres en général.

    De retour dans le Google Summer of Code

    https://www.haiku-os.org/community/gsoc/2017/ideas

    Haiku participe également régulièrement au Google Summer of Code. Celui-ci se présente sous la forme d'un stage, où des étudiants sont rémunérés par Google mais encadré par les contributeurs de différents projets de logiciels libres.

    Le résultat en termes de contribution aux logiciels participants étant en principe beaucoup plus important que pour le Google Code-In, il y a beaucoup plus de projets intéressés pour participer, aussi il n'est pas possible pour tous les projets de participer tous les ans (il faut laisser de la place aux autres). Haiku n'avait donc pas participé aux éditions 2015 et 2016, mais est de retour en 2017 avec 7 étudiants contribuant entre autres à l'amélioration de la pile TCP, le support de l'écriture sur le système de fichiers btrfs, ou encore l'écriture d'une application agenda et un travail sur l'interface graphique des préférences du système.

    Le Google Summer of Code se termine à la fin du mois d'août, donc les contributions des étudiants participants sont intégrées petit à petit d'ici là, et seront probablement présentes dans la version bêta de Haiku.

    Lire les commentaires

  • kyrbeis: un outil basique de gestion de dotfiles (Journaux LinuxFR)

    Mon bien cher Nal,

    Voulant synchroniser simplement des fichiers de configuration utilisateur, j'ai tout d'abord testé quelques-uns des outils énumérés ici.

    Je voulais un outil:

    • simple d'utilisation
    • fondé sur les liens symboliques, comme dotfiles

    Je voulais aussi utiliser git (et git-crypt pour chiffrer les fichiers sensibles).
    Trouvant les outils testés trop compliqués (voir risqués), j'ai décidé d'écrire une gem ruby de quelques lignes, kyrbeis pour faire cela.

    Je me suis dit que cela pourrait aussi éventuellement vous intéresser, voilà donc comment vous pourrez l'utiliser.

    installation

    $ gem install kyrbeis
    

    utilisation

    Créez un répertoire ~/dotfiles, dans lequel vos configurations seront stockées.
    Pour ajouter un nouveau fichier de configuration, par exemple ~/.vimrc,
    créez ~/dotfiles/__vimrc dans lequel vous écrirez votre configuration vim comme d'habitude.
    Puis, en prenant soin que ~/.vimrc n'existe pas déjà (auquel cas kyrbeis ne fera rien) faites un:

    $ kyrbeis apply
    

    ce qui est équivalent à faire un ln -s ~/dotfiles/__vimrc ~/.vimrc.

    Kyrbeis supporte aussi les sous répertoires, comme ~/.config/.
    Par exemple, pour ajouter un fichier ~/.config/git/ignore, vous créerez ~/dotfiles/__config/git/ignore.

    Conclusion

    Évidemment, cet outil prend son sens combiné a git, (ainsi que git-crypt, et à un gestionnaire de mot de passe).

    Et vous, cher Nal, quelle méthode utilisez-vous pour résoudre ce problème ?

    Lire les commentaires

  • qemu + boot & root disquette (Journaux LinuxFR)

    Bonjour les moules :)

    Je cherche à faire un truc un peu tordu sous qemu-2.8 : booter une disquette vmlinux (bootdisk Slack-1.1.2 en fait) et ensuite continuer le boot sur la root-disquette sachant qu'à l'époque (~1994), il fallait éjecter puis insérer la nouvelle disquette pour monter le VFS (minixfs dans le cas de la root-disquette) ! Je crois pas que qemu sache faire ce tour de passe passe.. J'ai d'autres idées pour contourner le pb ou bien avez-vous la cli qui se prête dans qemu ? :)

    Lire les commentaires

  • Un petit bot telegram (Journaux LinuxFR)

    Bonne rentrée à tous!

    Pour fêter cela je vous propose mon premier bot telegram:
    https://storebot.me/bot/dictonbot

    Il permet soit de demander le dicton du jour (texte ou .mp3; mp3 fait avec espeak afin que cela soit une authentique voix de robot!), soit de s'y abonner et le recevoir chaque jour à midi (texte seulement). Le dicton est sensé être humoristique 😃

    J'en profite pour savoir si certains d'entre vous ont fait des bots, pour telegram ou autre, et ce que tout le monde en pense.

    Il parait que c'est le nouveau futur :*)

    Lire les commentaires

  • [Btrfs et openSUSE] Épisode 1 : sous-volumes, snapshots et rollbacks (Journaux LinuxFR)

    Sommaire

    Btrfs is hard

    « Btrfs et openSUSE » est une série de journaux sur le système de fichiers Btrfs, basée sur ma propre expérience d'utilisateur d'openSUSE. Au menu :

    • des généralités sur Btrfs
    • des noms qui pètent : sous-volumes, snapshots, rollbacks
    • du snapper
    • du grub
    • de la mise à jour incrémentale
    • des quotas
    • de la maintenance
    • des trucs spécifiques à openSUSE
    • des tentatives désespérées pour rester applicable à d'autres distributions
    • des erreurs (pas taper)
    • des bugs
    • des cris
    • des larmes
    • et bien plus ! ou bien moins

    Aujourd'hui, l'épisode 1 : sous-volumes, snapshots et rollbacks.

    Quelques définitions

    Dictionnaire

    Sous-volume

    Un sous-volume, c'est un concept qui se situe entre celui du répertoire et celui de la partition.

    D'après la FAQ du wiki Btrfs, voilà ce qu'on peut faire avec :

    • un sous-volume peut-être monté indépendamment du reste du système de fichiers ;
    • il est possible de faire un snapshot d'un sous-volume en une seule opération atomique ;
    • on peut assigner des limites de capacité à un sous-volume via des quotas ou autrement partager l'espace de stockage entre tous les sous-volumes. Ainsi les sous-volumes peuvent partager des données entre eux (à travers la déduplication et les snapshots).

    On peut aussi copier des sous-volumes d'une partition Btrfs à une autre (ce sujet aura un épisode dédié !).

    Snapshot

    Un snapshot – un instantané, un cliché – est un clone d'un et un seul sous-volume à un instant t.

    Du coup, c'est aussi un sous-volume. Avec un parent : le sous-volume original.

    Rappelez-vous l'épisode précédent : on avait dit que Btrfs se basait sur la technique du Copy-on-Write. Et bien Btrfs n'est pas seulement capable de faire des copies paresseuses de fichiers ; il est capable d'en faire pour un sous-volume entier, comprenant maints répertoires et fichiers, et ce de façon quasi-immédiate.

    Rollback

    Pour un système, un rollback est la restauration d'un état précédent de ce système.

    Dans notre contexte Btrfs, cela consiste à utiliser un instantané d'un sous-volume – un cliché pris à un instant t – à la place de ce sous-volume. Donc revenir à un état précédent de ce sous-volume.

    Une installation d'openSUSE classique

    Caméléon

    Voici les sous-volumes présents sur une openSUSE fraîchement installée. Le seul écart par rapport au partitionnement par défaut est de ne pas avoir de partition /home séparée en XFS mais simplement un sous-volume Btrfs, pour des raisons de test.

    ~# btrfs subvolume list /
    ID 257 gen 184 top level 5 path @
    ID 258 gen 971 top level 257 path @/.snapshots
    ID 259 gen 985 top level 258 path @/.snapshots/1/snapshot
    ID 260 gen 184 top level 257 path @/boot/grub2/i386-pc
    ID 261 gen 184 top level 257 path @/boot/grub2/x86_64-efi
    ID 262 gen 972 top level 257 path @/home
    ID 263 gen 184 top level 257 path @/opt
    ID 264 gen 925 top level 257 path @/srv
    ID 265 gen 984 top level 257 path @/tmp
    ID 266 gen 925 top level 257 path @/usr/local
    ID 267 gen 927 top level 257 path @/var/cache
    ID 268 gen 184 top level 257 path @/var/crash
    ID 269 gen 184 top level 257 path @/var/lib/libvirt/images
    ID 270 gen 184 top level 257 path @/var/lib/machines
    ID 271 gen 184 top level 257 path @/var/lib/mailman
    ID 272 gen 184 top level 257 path @/var/lib/mariadb
    ID 273 gen 184 top level 257 path @/var/lib/mysql
    ID 274 gen 184 top level 257 path @/var/lib/named
    ID 275 gen 184 top level 257 path @/var/lib/pgsql
    ID 276 gen 986 top level 257 path @/var/log
    ID 277 gen 184 top level 257 path @/var/opt
    ID 278 gen 986 top level 257 path @/var/spool
    ID 279 gen 984 top level 257 path @/var/tmp
    ~# cat /etc/fstab
    UUID=a2ec9936-18fe-4910-a50b-c120726264f8 swap swap defaults 0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 / btrfs relatime         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /boot/grub2/i386-pc btrfs relatime,subvol=@/boot/grub2/i386-pc         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /boot/grub2/x86_64-efi btrfs relatime,subvol=@/boot/grub2/x86_64-efi         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /home btrfs relatime,subvol=@/home         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /opt btrfs relatime,subvol=@/opt         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /srv btrfs relatime,subvol=@/srv         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /tmp btrfs relatime,subvol=@/tmp         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /usr/local btrfs relatime,subvol=@/usr/local         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/cache btrfs relatime,subvol=@/var/cache         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/crash btrfs relatime,subvol=@/var/crash         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/libvirt/images btrfs relatime,subvol=@/var/lib/libvirt/images         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/machines btrfs relatime,subvol=@/var/lib/machines         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/mailman btrfs relatime,subvol=@/var/lib/mailman         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/mariadb btrfs relatime,subvol=@/var/lib/mariadb         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/mysql btrfs relatime,subvol=@/var/lib/mysql         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/named btrfs relatime,subvol=@/var/lib/named         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/lib/pgsql btrfs relatime,subvol=@/var/lib/pgsql         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/log btrfs relatime,subvol=@/var/log         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/opt btrfs relatime,subvol=@/var/opt         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/spool btrfs relatime,subvol=@/var/spool         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /var/tmp btrfs relatime,subvol=@/var/tmp         0 0
    UUID=926a75ec-a27c-488a-aa90-ce131f6cd378 /.snapshots btrfs relatime,subvol=@/.snapshots         0 0
    ~#

    Que remarque-t-on au premier abord ? Trois choses :

    1. Il y a beaucoup de sous-volumes (!)
    2. Il y a un sous-volume @ (?)
    3. Il y a un sous-volume @/.snapshots et un autre @/.snapshots/1/snapshot (??)

    Essayons déjà de trouver des explications à ces trois points.

    Pourquoi tant de sous-volumes ?

    Minions

    Essayons de répondre à la question suivante : quels sous-volumes créer à l'installation d'une distribution GNU/Linux pour permettre de faire ensuite des snapshots pertinents du système (/) ?

    Un seul sous-volume pour / ?

    Moui, le problème c'est que, sur un système complet il y a des données assez « volatiles » ou qui sont beaucoup réécrites : fichiers temporaires, caches, VM, bases de données, logs…

    Il n'est pas franchement pertinent de conserver ces données à un instant t. En outre :

    • ces données sont peu propices à l'utilisation du CoW ;
    • ces données pourraient être exclues tout simplement pour les conserver tout au long de la vie du système ; typiquement les journaux système : c'est bien de garder la trace d'une restauration.

    Au final, faire régulièrement des instantanés d'un tel sous-volume géant entraînerait une fragmentation et une consommation de l'espace disque importante en plus de ne pas être suffisamment flexible pour exclure certaines données des restaurations du système.

    Un sous-volume par répertoire de haut niveau (/usr, /etc, …) ?

    Moui, mais dans ce cas impossible pour un snapshot de représenter un système fonctionnel. Souvenez-vous, un snapshot correspond à un seul sous-volume. Cela rend compliqué la restauration du système (il faut restaurer plusieurs sous-volumes au lieu d'un seul).

    La solution actuelle sur openSUSE

    Il s'agit simplement de multiplier les sous-volumes afin de les exclure des instantanés de /, donc :

    • exit /tmp, /var/tmp : fichiers temporaires ;
    • exit /var/cache : caches ;
    • exit /var/lib/libvirt/images, /var/lib/machines : machines virtuelles ;
    • exit /var/lib/mariadb, /var/lib/mysql, /var/lib/pgsql : bases de données ;
    • exit /var/log : on veut conserver les traces d'une restauration du système ;
    • etc.

    D'où le grand nombre de sous-volumes à l'installation. Je vous l'accorde, ce n'est pas la panacée.

    Personnellement, je trouve que c'est un peu bête de créer certains de ces sous-volumes car on ne va pas forcément les utiliser. Tous les utilisateurs ne vont pas forcément créer une base de données ni utiliser une machine virtuelle.

    Je me dis qu'on pourrait essayer de créer ces sous-volumes à l'installation de certains paquets mais ça peut devenir vite compliqué. J'ai à ce sujet le vague souvenir qu'une mise à jour de systemd m'avait créé le sous-volume /var/lib/machines.

    Par ailleurs, puisque j'ai parlé de CoW : celui-ci est carrément désactivé pour certains sous-volumes.

    ~# lsattr -d /var/lib/{mariadb,mysql,pgsql,libvirt/images}
    ----------------C-- /var/lib/mariadb
    ----------------C-- /var/lib/mysql
    ----------------C-- /var/lib/pgsql
    ----------------C-- /var/lib/libvirt/images
    ~#

    Le cas de @

    Arobase

    Je ne connais pas l'origine de ce sous-volume.

    Avant – disons en 2015, quand j'ai installé mon openSUSE Tumbleweed – on ne l'avait pas. On utilisait simplement FS_TREE, le « sous-volume » avec l'ID 5.

    Je suppose que ce FS_TREE doit être suffisamment différent des autres sous-volumes pour lui préférer @ – qui déjà présente l'avantage d'avoir un vrai nom. Un caractère, c'est mieux que zéro.

    Si vous avez des explications plus complètes sur @, n'hésitez pas à le dire dans les commentaires ;-)

    @/.snapshots et @/.snapshots/1/snapshot

    Sur openSUSE, la stratégie est de mettre tous les instantanés sous le sous-volume @/.snapshots. C'est un choix.

    Plus étrange, on remarque la présence d'un premier instantané, alors que le système vient à peine d'être installé :

    ~# btrfs suvolume list -s /
    ID 259 gen 985 top level 258 path @/.snapshots/1/snapshot
    ~#

    Mais qu'est-ce don' ?

    ~# btrfs property /.snapshots/1/snapshot
    ro=false
    label=
    ~# mount | grep "on / "
    /dev/vda2/ on / type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot)
    ~# btrfs subvolume get-default /
    ID 259 (@/.snapshots/1/snapshot)
    ~#

    En clair, ce premier snapshot :

    • est le sous-volume par défaut de / : ce n'est donc rien d'autre que notre / actuel
    • est en lecture-écriture (et c'est heureux sinon on ne pourrait rien écrire sur /)

    Pourquoi ne pas utiliser directement @ ?

    Et bien, c'est pour éviter d'oublier de nettoyer les données du sous-volume initial après une première restauration.

    En effet, les snapshots… ça prend de la place. Le fait d'avoir tout sous /.snapshots facilite le ménage. Mais on reparlera de ça plus tard.

    Manipuler des sous-volumes et des snapshots

    Création et suppression de sous-volumes

    ~# btrfs subvolume create 
    btrfs subvolume create: too few arguments
    usage: btrfs subvolume create [-i <qgroupid>] [<dest>/]<name>
    
        Create a subvolume
    
        Create a subvolume <name> in <dest>.  If <dest> is not given
        subvolume <name> will be created in the current directory.
    
        -i <qgroupid>  add the newly created subvolume to a qgroup. This
                       option can be given multiple times.
    
    ~# btrfs subvolume delete
    btrfs subvolume delete: too few arguments
    usage: btrfs subvolume delete [options] <subvolume> [<subvolume>...]
    
        Delete subvolume(s)
    
        Delete subvolumes from the filesystem. The corresponding directory
        is removed instantly but the data blocks are removed later.
        The deletion does not involve full commit by default due to
        performance reasons (as a consequence, the subvolume may appear again
        after a crash). Use one of the --commit options to wait until the
        operation is safely stored on the media.
    
        -c|--commit-after      wait for transaction commit at the end of the operation
        -C|--commit-each       wait for transaction commit after deleting each subvolume
        -v|--verbose           verbose output of operations
    
    ~#
    

    Pas grand chose à dire là-dessus.

    En pratique, je n'ai créé un sous-volume qu'une seule fois, pour rajouter /var/cache. Ce n'était pas encore un sous-volume créé à l'installation quand j'ai installé openSUSE Tumbleweed.

    Création et suppression de snapshots

    ~# btrfs subvolume snapshot 
    btrfs subvolume snapshot: too few arguments
    usage: btrfs subvolume snapshot [-r] [-i <qgroupid>] <source> <dest>|[<dest>/]<name>
    
        Create a snapshot of the subvolume
    
        Create a writable/readonly snapshot of the subvolume <source> with
        the name <name> in the <dest> directory.  If only <dest> is given,
        the subvolume will be named the basename of <source>.
    
        -r             create a readonly snapshot
        -i <qgroupid>  add the newly created snapshot to a qgroup. This
                       option can be given multiple times.
    ~#
    

    Donc pour créer un snapshot en lecture seule de mon système actuel :

    ~# mkdir -p /.snapshots/42
    ~# btrfs subvolume snapshot -r / /.snapshots/42/snapshot
    Create a readonly snapshot of '/' in '/.snapshots/42/snapshot'
    ~#

    (J'aurais pu remplacer / par /.snapshots/1/snapshot.)

    Ça va très vite :

    ~# mkdir -p /.snapshots/43
    ~# time btrfs subvolume snapshot -r /.snapshots/43/snapshot
    Create a readonly snapshot of '/' in '/.snapshots/43/snapshot'
    
    real    0m0,444s
    user    0m0,000s
    sys     0m0,019s
    ~#

    Enfin, un snapshot se supprime comme n'importe quel autre sous-volume :

    ~# btrfs subvolume delete /.snapshots/{42,43}/snapshot
    Delete subvolume (no-commit): '/.snapshots/42/snapshot'
    Delete subvolume (no-commit): '/.snapshots/43/snapshot'
    ~# rmdir /.snapshots/{42,43}
    ~#

    Restauration du système

    1814-1830

    Faire un rollback, c'est simple : c'est remplacer un sous-volume courant par une version précédente, c'est-à-dire par un instantané de ce sous-volume.

    Comment pourrait-on faire ? Ça n'a pas l'air évident au premier abord : il va falloir sans doute jouer avec le montage des sous-volumes et mv

    Je simplifie le problème : ici, ce qui m'intéresse de changer, c'est le système, c'est le sous-volume de /.
    Dans ce cas, et vu notre configuration, faire une restauration revient simplement à changer le sous-volume par défaut de /. C'est tout.

    On a déjà vu quelle était la commande pour récupérer le sous-volume par défaut :

    ~# btrfs subvolume get-default /
    ID 259 (@/.snapshots/1/snapshot)
    ~#

    Le setter n'est pas beaucoup plus compliqué :

    ~# btrfs subvolume set-default
    btrfs subvolume set-default: too few arguments
    usage: btrfs subvolume set-default <subvolid> <path>
    
        Set the default subvolume of a filesystem
    ~#

    Mais allez, c'est parti, on y va ! Faisons une restauration complète !
    On suppose que l'instantané à restaurer existe : @/.snapshots/2/snapshot.

    ~# mkdir -p /.snapshots/{3,4}
    ~# # Création d'un instantané en lecture-seule du système actuel.
    ~# btrfs suvolume snapshot -r / /.snapshots/3/snapshot
    Create a readonly snapshot of '/' in '/.snapshots/3/snapshot'
    ~#
    ~# # Création d'un instantané en lecture-écriture de l'instantané 2.
    ~# btrfs suvolume snapshot /.snapshots/2/snapshot /.snapshots/4
    Create a snapshot of '/.snapshots/2/snapshot' in '/.snapshots/4/snapshot'
    ~#
    ~# # Définition du sous-volume par défaut sur l'instantané 4.
    ~# btrfs subvolume set-default $id_snapshot_4 /
    ~#

    Et voilà ! On peut redémarrer et booter sur notre système restauré !

    Bien. Normalement à ce moment précis, il va y avoir deux catégories de personnes :

    • celles qui vont dire : « C'est trop cooool ! »
    • celles qui vont dire : « Minute, papillon : il te reste encore à modifier ta configuration de GRUB pour que ça marche ! »

    Et toutes ces personnes auront raison, en un sens. Parce que tel quel, ce qu'on a fait est suffisant sur openSUSE, mais pas forcément ailleurs. Et c'est bien embêtant.

    C'est si embêtant qu'on en parlera dans le prochain épisode !

    That's all folks!

    Liens

    Sur le wiki Btrfs :

    Sur le wiki openSUSE, la liste des sous-volumes créés par défaut.

    Lire les commentaires

  • Nouvelles de ZeMarmot, GIMP et GIMP Motion (greffon d’animation dans GIMP) (Dépêches LinuxFR)

    Un peu d’info sur les évolutions de ZeMarmot (déjà discutées sur LinuxFr.org), sur la partie logicielle et artistique.

    Ce ne sont pas forcément des nouvelles pour ceux qui suivent l’avancée du projet sur le site Studio Girin, la liste de diffusion ou les réseaux sociaux. Mais pour tous ceux qui ne nous connaissent pas beaucoup ou ne suivent pas, j'espère que cela vous plaira.

    Sommaire

    Logiciel libre

    GIMP core

    Comme d’hab’, je reste un des contributeurs majeurs de GIMP avec 171 commits en 2017 (654 en tout, faisant de moi le 5e plus gros contributeur historique à ce jour) sur la branche master, et quelques commits mineurs sur babl et GEGL. Bien sûr, je fais aussi de la revue de code régulière (qui a eu pour résultat cette année au moins 18 commits poussés de contributeurs occasionnels), des rapports de bogues, des réponses aux bogues d’autrui, du suivi, de la maintenance, etc.

    Mes récentes contributions comportent beaucoup de corrections de bogues, quelques nouvelles fonctionnalités et des détails d’implémentation. Tous ces détails font la différence, surtout maintenant qu’on se rapproche de la sortie de la 2.10. En fait, ces derniers temps, c’est même surtout la somme de tous ces petits détails que l’on améliore qui « m’excite ». Chacune de ces mini‐fonctionnalités à elle seule peut paraître insignifiante, mais toutes ensemble, je trouve vraiment GIMP 2.9/2.10 tellement plus agréable à utiliser et efficace par rapport à la 2.8, que cette version s’annonce pour moi comme une avancée majeure. N’hésitez pas à jeter un œil sur le journal de mes contributions pour avoir plus de détails.

    Nous devrions bientôt sortir une version de développement 2.9.6, ce qui vous donnera une meilleure visibilité, surtout qu’il y a vraiment eu plein de choses super excitantes entre 2.9.4 et 2.9.6 (et pas que de moi ! Nous sommes maintenant trois gros codeurs sur GIMP et les choses se mettent vraiment à bouger énormément).

    Un peu de fun avec GEGL et Android

    À côté, j’ai commencé à m’amuser avec du développement Android. En particulier, j’ai fait la compilation croisée de glib et GEGL pour Android grâce à mon outil, Crossroad (dont j’avais parlé il y a quelques années ici). Je n’ai eu qu’une seule correction à faire pour rendre GEGL compilable pour Android (un commit sur babl, la bibliothèque de conversion de pixels de GEGL).
    J’en parlerai probablement encore quand je sortirai Crossroad 0.8, la version qui permettra officiellement la compilation croisée pour toutes les plates‐formes prises en charge par Android (ARM, x86, MIPS, en 32 et 64 bits), car pour l’instant c’est fait avec la version de développement de Crossroad (mais ça marche déjà très bien ! Testé sur l’émulateur Android, mais aussi sur un vrai téléphone).

    En attendant, je me suis amusé avec une application Android qui peut appliquer diverses opérations GEGL sur une image. L’application n’a pas pour but d’être complexe pour le moment et me sert surtout à expérimenter l’usage de ces bibliothèques libres sur des machines portables. Vous pouvez tout de même jeter un œil au code, si vous voulez, c’est libre ! :-)

    Robogoat : modification d’images avec GEGL sur Android

    Très franchement je ne sais pas encore où cela me mènera. C’est beaucoup d’expérimentation et je le fais surtout parce que ça m’amuse. Certains vont tout de suite s’imaginer GIMP pour Android, j’en suis sûr. ;-)
    Après tout, une version Android de GIMP est clairement une des fonctionnalités demandées régulièrement. J’y ai pensé aussi, bien sûr (il va sans dire, ça serait cool d’avoir GIMP sur les appareils portables !), mais je ne vois absolument pas cela comme une possibilité à court ou moyen terme. GIMP pourrait sûrement être compilé pour Android, là n’est pas le problème, mais son interface n’est clairement pas pensée pour être utilisée sur de petits périphériques. Je sais qu’il y aurait beaucoup de choses à revoir et il est même fort probable qu’il puisse être bien plus intéressant de faire une nouvelle interface graphique à partir de zéro, basée sur GEGL. D’un autre côté, pour travailler sur des tablettes, il y a probablement quelque chose d’intéressant à faire.
    Ne retenez donc pas votre respiration en vous imaginant du GIMP pour Android dans un futur proche. Néanmoins, oui, c’est une possibilité très réelle à terme comme résultat de mes expériences. C’est vrai. :-)

    GIMP Motion

    Début juillet, j’ai publié mon travail en cours sur notre greffon (156 commits additionnels à ce jour, qui ne sont pas encore dans la branche master) pour ajouter la prise en charge d’animations de qualité professionnelle avec GIMP. Le code est donc visible publiquement comme branche du dépôt de GIMP. Il n’est pas intégré encore à la branche master car je considère vraiment cela comme du travail en cours, avec son lot de bogues connus et inconnus et de changements que je fais dessus régulièrement. Cela ne nous empêche pas de l’utiliser quotidiennement (enfin surtout Aryeom, bien sûr), sans pour autant le considérer comme du travail fini et donc disponible dans une version « stable » de GIMP.

    GIMP Motion en action

    Pour l’occasion, j’ai publié deux vidéos pour introduire l’utilisation de base du greffon, lequel présente deux modes : un mode storyboard (que j’appelle aussi « animation simple », car ce serait typiquement le mode classique pour les gens qui font des GIF/WebP animés avec le concept un calque = une image) et un mode animation traditionnelle pour des animations plus complexes où chaque image sera une composition de plusieurs calques. Les deux vidéos sont accompagnées d’un message explicatif qui décrit un peu mieux le contenu de la vidéo et le futur du greffon (surtout le second message) :

    En deux mots, pour ceux qui auront la flemme de lire les articles : dans l’avenir, ce greffon permettra de créer des animations composées de nombreux calques, avec animations de caméra (zooms, panoramique et inclinaison rapide, rotations…), animations d’effets (lumières, reflets, coloration, flous, déformation de caméra…). Tout effet GEGL pourrait être animé, ce qui permettra des animations avancées en quelques clics, ainsi que du motion graphics, etc.

    Une des avancées indirectes apportée à GIMP par le développement de ce greffon, c’est de rendre libgimp (la bibliothèque utilisée par les greffons pour interagir avec GIMP) enfin thread‐safe, puisque j’en ai eu besoin et j’ai donc modifié GIMP pour travailler plus aisément en multi‐thread dans des greffons (seule ma branche possède ce changement pour le moment). Ce sera donc une autre amélioration dont bénéficiera l’ensemble de l’écosystème de greffons de GIMP.

    Le film « ZeMarmot »

    Sur le processus de production d’un film d’animation, vous serez peut‐être intéressé par les articles suivants.

    De l’animatique à l’animation

    Nous avons décrit les étapes de préproduction à production, en expliquant le passage du storyboard à l’animatique puis au keyframing et enfin à l’animation, illustré par une vidéo montrant les diverses étapes côte‐à‐côte.
    De l’animatique à l’animation

    Design

    Nous avons publié un article sur le design d’arrière‐plans, en prenant le terrier de ZeMarmot comme base, à partir de nos photos de recherche sur terrain.
    Design du terrier de ZeMarmot

    Et bien plus…

    Bien sûr, il y a plus au niveau artistique, mais comme à notre habitude, nous essayons de garder un peu de mystère autour de la production pour ne pas vous gâcher le plaisir du premier visionnage. Un peu de patience… ;-)
    Nous divulguons ceci dit un peu plus à nos financeurs Patreon/Tipeee, comme récemment la première scène animée (et on peut donner les liens à ceux qui ont contribué autrement ; si c’est votre cas, envoyez juste un courriel). Mais on met des avertissements clairs « SPOILER », car même en nous soutenant, vous ne voulez pas forcément en voir trop (je sais que personnellement je n’aime pas voir de versions non finies de films, hormis si je travaille dessus).

    Financement participatif

    Comme à mon habitude, je termine mes nouvelles du projet en rappelant que ZeMarmot est entièrement financé de manière participative. Nous utilisons deux plates‐formes de financement participatif mensuel :

    Tout est géré par une association loi 1901 enregistrée en France, LILA, vous pouvez donc aussi faire des donations directement si vous le souhaitez (page de donation de LILA ; n’hésitez pas à envoyer un message en parallèle si vous donnez par ce biais, surtout si vous souhaitez préciser pourquoi vous donnez et nous indiquer votre nom), et sans frais de plate‐forme donc.

    À ce jour, le financement du projet existe, mais il ne nourrit pas grand monde, ce qui explique aussi l’évolution bien plus lente du projet que nous l’espérions. Pour tout dire, on a eu quelques baisses de moral plus d’une fois durant lesquelles on s’est demandé si c’était bien raisonnable de continuer.

    Si vous appréciez notre travail pour améliorer ou créer du logiciel libre et créer de l’art libre que tout le monde pourra télécharger et visionner, je vous appelle à nouveau pour aider notre projet. Le financement va entièrement dans ces objectifs, en salaires de production du film. Que ce soit pour améliorer les logiciels libres en général, GIMP en particulier, l’édition vidéo ou l’animation 2D libres, peut‐être même me pousser à continuer mes expérimentations de compilation croisée — certes, des objectifs annexes sans rapport direct, mais ces expérimentations sont nées de mon intérêt dans GIMP, donc de ZeMarmot — de bibliothèques libres sur diverses plates‐formes (que ce soit Android, d’autres plates‐formes embarquées, ou autres !) ou parce que vous aimez le concept ou l’histoire de notre film (une marmotte qui voyage et qui est libre), ou bien parce que vous souhaitez nous aider à professionnaliser l’art libre, ou toute autre raison qui vous plaît dans ce que nous faisons, alors vous savez comment nous aider en soutenant le projet. :-)

    Et encore une fois, merci à tous ceux qui nous ont soutenus jusque‐là ! Sans vous, ZeMarmot n’existerait pas et tous les trucs dont j’ai parlé plus haut, ainsi que dans divers autres articles, ou encore mes centaines de commits sur GIMP, etc., tout cela n’existerait pas non plus.

    Merci de ZeMarmot

    Lire les commentaires

  • Nouvelles de ZeMarmot, GIMP et GIMP Motion (plugin d'animation dans GIMP) (Dépêches LinuxFR)

    Un peu d'info sur les évolutions de ZeMarmot (déjà discuté sur LinuxFr.org), sur la partie logicielle et artistique.

    Ce ne sont pas forcément des nouvelles pour ceux qui suivent l'avancée du projet sur le site Studio Girin, la liste de diffusion ou les réseaux sociaux. Mais pour tous ceux qui ne nous connaissent pas beaucoup ou ne suivent pas, j'espère que cela vous plaira.

    Sommaire

    Logiciel Libre

    GIMP core

    Comme d'hab, je reste un des contributeurs majeurs de GIMP avec 171 commits en 2017 (654 en tout, faisant de moi le 5ème plus gros contributeur historique à ce jour) sur la branche master, et quelques commits mineurs sur babl et GEGL. Bien sûr, je fais aussi de la revue de code régulière (qui a eu pour résultat cette année au moins 18 commits poussés de contributeurs occasionnels), des rapports de bugs, des réponses aux bugs d'autrui, du suivi, de la maintenance, etc.

    Mes récentes contributions comportent beaucoup de corrections de bugs, quelques nouvelles fonctionnalités, et des détails d'implémentation. Tous ces détails font la différence, surtout maintenant qu'on se rapproche de la sortie de 2.10. En fait ces derniers temps, c'est même surtout la somme de tous ces petits détails que l'on améliore qui « m'excitent ». Chacune de ces mini-fonctionnalités à elle-seule peut paraître insignifiante, mais toutes ensemble, je trouve vraiment GIMP 2.9/2.10 tellement plus agréable à utiliser et efficace par rapport à 2.8 que cette version s'annonce pour moi comme une avancée majeure. N'hésitez pas à jeter un œil sur le log de mes contributions pour avoir plus de détails.

    Nous devrions bientôt sortir une version de développement 2.9.6, ce qui vous donnera une meilleure visibilité, surtout qu'il y a vraiment eu plein de choses super excitantes entre 2.9.4 et 2.9.6 (et pas que de moi! Nous sommes maintenant 3 gros codeurs sur GIMP et les choses se mettent vraiment à bouger énormément).

    Un peu de fun avec GEGL et Android

    À côté, j'ai commencé à m'amuser avec du développement Android. En particulier j'ai cross-compilé glib et GEGL pour Android grâce à mon outil, crossroad (dont j'avais parlé y a quelques années ici). Je n'ai eu qu'une seule correction à faire pour rendre GEGL compilable pour Android (un commit sur babl, la bibliothèque de conversion de pixels de GEGL).
    J'en parlerai probablement encore quand je sortirai Crossroad 0.8, la version qui permettra officiellement la compilation croisée pour toutes les plateformes prises en charge par Android (ARM, x86, MIPS, en 32 et 64 bits), car pour l'instant c'est fait avec la version de développement de Crossroad (mais ça marche déjà très bien! Testé sur l'émulateur Android, mais aussi sur un vrai téléphone).

    En attendant, je me suis amusé avec une application Android qui peut appliquer diverses opérations GEGL sur une image. L'application n'a pas pour but d'être complexe pour le moment et me sert surtout à expérimenter l'usage de ces bibliothèques libres sur des machines portables. Vous pouvez tout de même jeter un œil au code, si vous voulez, c'est libre! :-)

    Robogoat: modification d'images avec GEGL sur Android

    Très franchement je ne sais pas encore où cela me mènera. C'est beaucoup d'expérimentations et je le fais surtout parce que ça m'amuse. Certains vont tout de suite s'imaginer GIMP pour Android, j'en suis sûr. ;-)
    Après tout, une version Android de GIMP est clairement une des fonctionnalités demandées régulièrement. J'y ai pensé aussi, bien sûr (il va sans dire, ça serait cool d'avoir GIMP sur appareils portables!), mais je ne vois absolument pas cela comme une possibilité à court ou moyen terme. GIMP pourrait sûrement être cross-compilé pour Android, là n'est pas le problème, mais son interface n'est clairement pas pensée pour être utilisée sur de petits périphériques. Je sais qu'il y aurait beaucoup de choses à revoir et il est même fort probable qu'il puisse être bien plus intéressant de faire une nouvelle interface graphique à partir de zéro, basée sur GEGL. D'un autre côté, pour travailler sur des tablettes, il y a probablement quelque chose d'intéressant à faire.
    Ne retenez donc pas votre respiration en vous imaginant du GIMP pour Android dans un futur proche. Néanmoins oui, c'est une possibilité très réelle à terme comme résultat de mes expérimentations. C'est vrai. :-)

    GIMP Motion

    Début juillet, j'ai publié mon travail en cours sur notre plug-in (156 commits additionnels à ce jour, qui ne sont pas encore dans master) pour ajouter la prise en charge d'animation de qualité professionnelle avec GIMP. Le code est donc visible publiquement comme branche du dépôt de GIMP. Il n'est pas intégré encore à la branche master car je considère vraiment cela comme du travail en cours, avec son lot de bugs connus et inconnus et de changements que je fais dessus régulièrement. Cela ne nous empêche pas de l'utiliser quotidiennement (enfin surtout Aryeom bien sûr), sans pour autant le considérer comme du travail fini et donc disponible dans une version « stable » de GIMP.

    GIMP Motion en action

    Pour l'occasion, j'ai publié deux vidéos pour introduire l'utilisation de base du plug-in, lequel présente deux modes: un mode storyboard (que j'appelle aussi « animation simple » car ce serait typiquement le mode classique pour les gens qui font des GIF/WebP animés avec le concept un calque = une image) et un mode animation traditionnelle pour des animations plus complexes où chaque image sera une composition de plusieurs calques. Les deux vidéos sont accompagnées d'un message explicatif qui décrit un peu mieux le contenu de la vidéo et le futur du plug-in (surtout le second message) :

    En deux mots, pour ceux qui auront la flemme de lire les articles : dans l'avenir, ce plug-in permettra de créer des animations composées de nombreux calques, avec animations de caméra (zooms, panning/tilting, rotation…), animations d'effets (lumières, reflets, coloration, flous, déformation de caméra…). Tout effet GEGL pourrait être animé, ce qui permettra des animations avancées en quelques clics, ainsi que du motion graphics, etc.

    Une des avancées indirectes apportée à GIMP par le développement de ce plug-in, c'est de rendre libgimp (la bibliothèque utilisée par les plug-ins pour interagir avec GIMP) enfin thread-safe, puisque j'en ai eu besoin et ai donc patché GIMP pour travailler plus aisément en multi-thread dans des plug-ins (seule ma branche a ce changement pour le moment). Ce sera donc une autre amélioration dont bénéficiera l'ensemble de l'écosystème de plug-ins de GIMP.

    Le film « ZeMarmot »

    Sur le processus de production d'un film d'animation, vous serez peut-être intéressé par ces articles :

    De l'animatique à l'animation

    Nous avons décrit les étapes de pré-prod à production, en expliquant le passage du storyboard à l'animatique puis au keyframing et enfin à l'animation, illustré par une vidéo montrant les diverses étapes côte-à-côte.

    De l'animatique à l'animation

    Design

    Nous avons publié un article sur le design d'arrière-plans, en prenant le terrier de ZeMarmot comme base, à partir de nos photos de recherche sur terrain.

    Design du terrier de ZeMarmot

    Et bien plus…

    Bien sûr, il y a plus au niveau artistique, mais comme à notre habitude, nous essayons de garder un peu de mystère autour de la production pour ne pas vous gâcher le plaisir du premier visionnage. Un peu de patience… ;-)
    Nous divulguons ceci dit un peu plus à nos financeurs Patreon/Tipeee, comme récemment la première scène animée (et on peut donner les liens à ceux qui ont contribué autrement ; si c'est votre cas, envoyez juste un email). Mais on met de clairs warning « SPOILER » car même en nous soutenant, vous ne voulez pas forcément en voir trop (je sais que personnellement je n'aime pas voir de versions non-finies de films, hormis si je travaille dessus).

    Financement participatif

    Comme à mon habitude, je termine mes nouvelles du projet en rappelant que ZeMarmot est entièrement financé participativement. Nous utilisons deux plateformes de crowdfunding mensuel :

    Tout est géré par une association loi 1901 enregistrée en France, LILA, vous pouvez donc aussi faire des donations directement si vous le souhaitez (page de donation de LILA ; n'hésitez pas à envoyer un message en parallèle si vous donnez par ce biais, surtout si vous souhaitez préciser pourquoi vous donnez et nous donner votre nom), et sans frais de plateforme donc.

    À ce jour, le financement du projet existe, mais il ne nourrit pas grand monde, ce qui explique aussi l'évolution bien plus lente du projet que nous l'espérions. Pour tout dire, on a eu quelques baisses de moral plus d'une fois où on s'est demandés si c'était bien raisonnable de continuer.

    Si vous appréciez notre travail pour améliorer ou créer du Logiciel Libre et créer de l'Art Libre que tout le monde pourra télécharger et visionner, je vous appelle à nouveau pour aider notre projet. Le financement va entièrement dans ces objectifs, en salaires de production du film. Que ce soit pour améliorer les Logiciels Libres en général, GIMP en particulier, l'édition vidéo ou l'animation 2D Libres, peut-être même me pousser à continuer mes expérimentations de cross-compilation — certes des objectifs annexes sans rapport direct, mais ces expérimentations sont nées de mon intérêt dans GIMP, donc de ZeMarmot — de bibliothèques libres sur diverses plateformes (que ce soit Android, d'autres plateformes embarquées, ou autre!) ou parce que vous aimez le concept ou l'histoire de notre film (une marmotte qui voyage et qui est libre), ou bien parce que vous souhaitez nous aider à professionnaliser l'Art Libre… ou toute autre raison qui vous plaît dans ce que nous faisons… alors vous savez comment nous aider en soutenant le projet. :-)

    Et encore une fois, merci à tous ceux qui nous ont soutenus jusque là ! Sans vous, ZeMarmot n'existerait pas et tous les trucs dont j'ai parlé plus haut, ainsi que dans divers autres articles, ou encore mes centaines de commits sur GIMP… tout cela n'existerait pas non plus.

    Merci de ZeMarmot

    Lire les commentaires

  • Nouvelles de ZeMarmot, GIMP et GIMP Motion (plugin d'animation dans GIMP) (Journaux LinuxFR)

    Sommaire

    Salut à tous,

    Un peu d'info sur les évolutions de ZeMarmot (déjà discuté sur LinuxFr.org), sur la partie logicielle et artistique.
    Ce ne sont pas forcément des nouvelles pour ceux qui suivent l'avancée du projet sur le site Studio Girin, la liste de diffusion ou les réseaux sociaux. Pour tous ceux qui ne nous connaissent pas beaucoup ou ne suivent pas, j'espère que cela vous plaira.

    Logiciel Libre

    GIMP core

    Comme d'hab, je reste un des contributeurs majeurs de GIMP avec 171 commits en 2017 (654 en tout, faisant de moi le 5ème plus gros contributeur historique à ce jour) sur la branche master, et quelques commits mineurs sur babl et GEGL. Bien sûr, je fais aussi de la revue de code régulière (qui a eu pour résultat cette année au moins 18 commits poussés de contributeurs occasionnels), des rapports de bugs, des réponses aux bugs d'autrui, du suivi, de la maintenance, etc.

    Mes récentes contributions comportent beaucoup de corrections de bugs, quelques nouvelles fonctionnalités, et des détails d'implémentation. Tous ces détails font la différence, surtout maintenant qu'on se rapproche de la sortie de 2.10. En fait ces derniers temps, c'est même surtout la somme de tous ces petits détails que l'on améliore qui "m'excitent". Chacune de ces mini-fonctionnalités à elle-seule peut paraître insignifiante, mais toutes ensemble, je trouve vraiment GIMP 2.9/2.10 tellement plus agréable à utiliser et efficace par rapport à 2.8 que cette version s'annonce pour moi comme une avancée majeure.
    N'hésitez pas à jeter un œil sur le log de mes contributions pour avoir plus de détails.

    Nous devrions bientôt sortir une version de développement 2.9.6, ce qui vous donnera une meilleure visibilité, surtout qu'y a vraiment eu plein de choses super excitantes entre 2.9.4 et 2.9.6 (et pas que de moi! Nous sommes maintenant 3 gros codeurs sur GIMP et les choses se mettent vraiment à bouger énormément).

    Un peu de fun avec GEGL et Android

    À côté, j'ai commencé à m'amuser avec du développement Android. En particulier j'ai cross-compilé glib et GEGL pour Android grâce à mon outil, crossroad (dont j'avais parlé y a quelques années ici). Je n'ai eu qu'une seule correction à faire (un commit sur babl, la bibliothèque de conversion de pixels de GEGL) pour rendre GEGL compilable pour Android.
    J'en parlerai probablement encore quand je sortirai Crossroad 0.8, la version qui permettra officiellement la compilation croisée pour toutes les plateformes prises en charge par Android (ARM, x86, MIPS, en 32 et 64 bits), car pour l'instant c'est la version de développement de Crossroad (mais ça marche déjà très bien! Testé notamment sur l'émulateur Android mais aussi sur un vrai téléphone).

    En attendant, je me suis amusé avec une application Android qui peut appliquer diverses opérations GEGL sur une image. L'application n'a pas pour but à être complexe pour le moment et me sert surtout à expérimenter l'usage de ces bibliothèques libres sur des machines portables. Vous pouvez tout de même jeter un œil au code, si vous voulez, c'est libre! :-)
    Robogoat: modification d'images avec GEGL sur Android

    Très franchement je ne suis pas encore sûr où cela me mènera. C'est beaucoup d'expérimentations et aussi surtout je le fais parce que ça m'amuse. Certains vont tout de suite s'imaginer GIMP pour Android, j'en suis sûr. ;-)
    Après tout, une version Android de GIMP est clairement une des fonctionnalité demandées régulièrement. J'y ai pensé aussi, bien sûr (il va sans dire, ça serait cool d'avoir GIMP sur appareils portables!), mais je ne vois absolument pas cela comme une possibilité à court ou moyen terme. GIMP pourrait sûrement être cross-compilé pour Android, là n'est pas le problème, mais son interface n'est clairement pas pensée pour être utilisée sur de petits périphériques. Je sais qu'il y aurait beaucoup de choses à revoir et il est même fort probable qu'il puisse être bien plus intéressant de faire une nouvelle interface graphique à partir de zéro, basée sur GEGL. D'un autre côté, pour travailler sur des tablettes, il y a probablement quelque chose d'intéressant à faire.
    Ne retenez donc pas votre respiration en vous imaginant du GIMP pour Android dans un futur proche. Néanmoins oui, c'est une possibilité très réelle à terme comme résultat de mes expérimentations. C'est vrai. :-)

    GIMP Motion

    Début juillet, j'ai publié mon travail en cours sur notre plug-in (156 commits additionnels à ce jour, qui ne sont pas encore dans master) pour ajouter la prise en charge d'animation de qualité professionnelle avec GIMP. Le code est donc visible publiquement comme branche du dépôt de GIMP. Il n'est pas intégré encore à la branche master car je considère cela vraiment comme du travail en cours, avec son lot de bugs connus et inconnus et de changements que je fais dessus régulièrement. Cela ne nous empêche pas de l'utiliser quotidiennement (enfin surtout Aryeom bien sûr), sans pour autant le considérer comme du travail fini et donc disponible dans une version "stable" de GIMP.

    GIMP Motion en action

    Pour l'occasion, j'ai publié 2 vidéos pour introduire l'utilisation de base du plugin, lequel présente 2 modes: un mode "storyboard" (que j'appelle aussi "animation simple" car ce serait typiquement le mode classique pour les gens qui font des GIF/WebP animés avec le concept 1 calque = 1 image) et un mode "animation traditionnelle" pour des animations plus complexes où chaque image sera une composition de plusieurs calques. Les 2 vidéos sont accompagnés d'un post explicatif qui décrit un peu mieux le contenu de la vidéo et le futur du plug-in (surtout le second post):

    En deux mots, pour ceux qui auront la flemme de lire les articles, dans l'avenir, ce plug-in permettra de créer des animations composées de nombreux calques, avec animations de caméra (zooms, panning/tilting, rotation…), animations d'effets (lumières, reflets, coloration, flous, déformation de caméra…). Tout effet GEGL pourrait être animé, ce qui permettra des animations avancées en quelques clics, ainsi que du motion graphics, etc.

    Une des avancées indirectes que le développement ce plug-in va apporter à GIMP est de rendre libgimp (la bibliothèque utilisée par les plug-ins pour interagir avec GIMP) enfin thread-safe, puisque j'en ai eu besoin et ai donc patché GIMP pour travailler plus aisément en multi-thread dans des plug-ins (seule ma branche a ce changement pour le moment). Ce sera donc une autre amélioration qui bénéficiera l'ensemble de l'écosystème de plug-ins de GIMP.

    Le Film "ZeMarmot"

    Sur le processus de production d'un film d'animation, vous serez peut-être intéressé par ces articles:

    De l'animatique à l'animation

    Nous avons décrit les étapes de pré-prod à production, en expliquant le passage du storyboard à l'animatique puis au keyframing et enfin à l'animation, illustré par une vidéo montrant les diverses étapes côte-à-côte.

    De l'animatique à l'animation

    Design

    Nous avons publié un article sur le design d'arrière-plans, en prenant le terrier de ZeMarmot comme base, à partir de nos photos de recherche sur terrain.

    Design du terrier de ZeMarmot

    Et bien plus…

    Bien sûr, il y a plus au niveau artistique, mais comme à notre habitude, nous essayons de garder un peu de mystère autour de la production pour ne pas vous gâcher le plaisir du premier visionnage. Un peu de patience… ;-)
    Nous divulguons ceci dit un peu plus à nos financeurs Patreon/Tipeee (et on peut donner les liens à ceux qui ont contribué autrement; si c'est votre cas, envoyez juste un email), comme récemment la première scène animée. Mais même là, on met de clairs warning "SPOILER" car même en nous soutenant, vous ne voulez pas forcément en voir trop (je sais que personnellement je n'aime pas voir de versions non-finies de films hormis si je travaille dessus).

    Financement participatif

    Comme à mon habitude, je termine mes nouvelles du projet par le rappel que le projet ZeMarmot est entièrement financé participativement. Nous utilisons deux plateformes de crowdfunding mensuel:

    Tout est géré par une association loi 1901 enregistrée en France, LILA, vous pouvez donc aussi faire des donations directement si vous le souhaitez (» page de donation de LILA; n'hésitez pas à envoyer un message en parallèle si vous donnez par ce biais surtout si vous souhaitez préciser pourquoi vous donnez et nous donner votre nom), et sans frais de plateforme donc.

    À ce jour, le financement du projet existe, mais il ne nourrit pas grand monde, ce qui explique aussi l'évolution bien plus lente du projet que nous l'espérions. Pour tout dire, on a eu quelques baisses de moral plus d'une fois où on s'est demandés si c'était bien raisonnable de continuer.
    Si vous appréciez notre travail pour améliorer/créer du Logiciel Libre et créer de l'Art Libre que tout le monde pourra télécharger et visionner, je fais donc un nouvel appel à aider notre projet. Le financement va entièrement dans ces objectifs, en salaires de production du film. Que votre raison soit pour améliorer les Logiciels Libres en général, GIMP en particulier, l'édition vidéo ou l'animation 2D Libres, peut-être même me pousser à continuer mes expérimentations de cross-compilation — certes des objectifs annexes sans rapport direct, mais ces expérimentations sont nées de mon intérêt dans GIMP, donc de ZeMarmot — de bibliothèques libres sur diverses plateformes (que ce soit Android, d'autres plateformes embarquées, ou autre!) ou parce que vous aimez le concept ou l'histoire de notre film (une marmotte qui voyage et qui est libre), ou bien parce que vous souhaitez nous aider à professionnaliser l'Art Libre… ou toute autre raison qui vous plaît dans ce que nous faisons… alors vous savez comment nous aider en soutenant le projet. :-)

    Et encore une fois, merci à tous ceux qui nous ont soutenus jusque là! Sans vous, ZeMarmot n'existerait pas et tous les trucs dont j'ai parlé plus haut, ainsi que dans divers autres articles, ou encore mes centaines de commits sur GIMP… tout cela n'existerait pas non plus.

    Merci de ZeMarmot

    Lire les commentaires

  • GCompris sort en version 0.80 (Dépêches LinuxFR)

    Nous sommes heureux d’annoncer la publication de la nouvelle version de GCompris, le logiciel éducatif pour les enfants de deux à dix ans.

    Cette nouvelle version contient entre autres six nouvelles activités, listées dans la suite de la dépêche. GCompris propose plus de 100 activités, dont des jeux, toujours avec un objectif pédagogique. Lecture, mathématiques, sciences, géographie et découverte de l’ordinateur sont les thèmes abordés par ces activités.

    Logo Gcompris

    Nouvelles activités

    • Une activité de catégorisation d’images :
      http://gcompris.net/screenshots_qt/small/categorization.png

    • Une activité où il faut, à partir des nombres et des différentes opérations proposées, trouver un nombre donné :
      source : http://gcompris.net/screenshots_qt/small/guesscount.png

    • Un jeu où l’on doit faire en sorte que l’adversaire place la dernière boule sur une ligne, qui se joue contre l’ordinateur ou un ami :
      source : http://gcompris.net/screenshots_qt/small/bargame.png

    • Le jeu de dames en version avec l’ordinateur ou avec un ami :
      source : http://gcompris.net/screenshots_qt/small/checkers.png

    Plates‐formes prises en charge

    Comme pour la précédente version, nous prenons en charge bien évidemment GNU/Linux, pour lequel nous avons des paquets dans plusieurs distributions :

    • Arch Linux ;
    • KaOS ;
    • KDE Neon ;
    • Mageia Cauldron ;
    • OpenSUSE.

    Android est aussi pris en charge via le Play Store. Suite à l’ajout du SDK Qt dans F-Droid (https://gitlab.com/fdroid/fdroidserver/issues/202), nous espérons sortir aussi une version dessus.

    Windows est toujours pris en charge en version 32 bits et 64 bits. Nous proposons une construction expérimentale pour la version 64 bits utilisant la suite d’outils MinGW.

    Pour macOS et iOS, nous sommes en discussion avec deux contributeurs, mais nous n’avons toujours pas de paquet fonctionnel à distribuer.

    Autres changements

    Pour cette nouvelle version, on voit également arriver :

    • pour l’activité de vocabulaire, l’ajout des données pour le polonais, le suédois et l’ukrainien ;
    • de nouveaux graphismes pour plusieurs activités ;
    • la traduction du site est maintenant gérée dans l’infrastructure KDE :
      • cette version est complètement traduite en 17 langues,
      • elle est aussi traduite à plus de 85 % en 11 langues supplémentaires.

    Capture d’écran de GCompris

    Lire les commentaires

  • GCompris sort en version 0.80 (Dépêches LinuxFR)

    Nous sommes heureux d’annoncer la publication de la nouvelle version de GCompris, le logiciel éducatif pour les enfants de deux à dix ans.

    Cette nouvelle version contient entre autres six nouvelles activités, listées dans la suite de la dépêche. GCompris propose plus de 100 activités, dont des jeux, toujours avec un objectif pédagogique. Lecture, mathématiques, sciences, géographie et découverte de l'ordinateur sont les thèmes abordés par ces activités.

    Logo Gcompris

    Nouvelles activités

    • Une activité de catégorisation d'images :
      http://gcompris.net/screenshots_qt/small/categorization.png

    • Une activité où il faut à partir des nombres et des différentes opérations proposées trouver un nombre donné :
      source : http://gcompris.net/screenshots_qt/small/guesscount.png

    • Un jeu où l'on doit faire en sorte que l'adversaire place la dernière boule sur une ligne, se joue contre l’ordinateur ou un ami :
      source : http://gcompris.net/screenshots_qt/small/bargame.png

    • Le jeu de dames en version avec l’ordinateur ou avec un ami :
      source : http://gcompris.net/screenshots_qt/small/checkers.png

    Plate‐formes prises en charge

    Comme pour la précédente version, nous prenons en charge bien évidemment GNU/Linux, pour lequel nous avons des paquets dans plusieurs distributions :

    • Archlinux ;
    • KaOS ;
    • KDE Neon ;
    • Mageia Cauldron ;
    • OpenSUSE.

    Android est aussi pris en charge via le Play Store. Suite à l'ajout du SDK Qt dans f-droid (https://gitlab.com/fdroid/fdroidserver/issues/202), nous espérons sortir aussi une version dessus.

    Windows est toujours pris en charge en version 32 bits et 64 bits. Nous proposons une construction expérimentale pour la version 64 bits utilisant la suite d'outils MinGW.

    Pour Mac OS X et iOS, nous sommes en discussion avec 2 contributeurs mais n'avons toujours pas de paquet fonctionnel à distribuer.

    Autres changements

    Pour cette nouvelle version on voit également arriver :

    • pour l’activité de vocabulaire, l’ajout des données pour le polonais, le suédois et l'ukrainien ;
    • de nouveaux graphismes pour plusieurs activités ;
    • la traduction du site est maintenant gérée dans l'infrastructure KDE :
      • Cette version est complètement traduite en 17 langues ;
      • Elle est aussi traduite à plus de 85% en 11 langues supplémentaires.

    Lire les commentaires

  • Le programme de la LDAPCon 2017 est sorti! (Dépêches LinuxFR)

    Nous sommes heureux de vous annoncer la sortie du programme des conférences de la LDAPCon 2017 qui aura lieu à Bruxelles le 19 & 20 octobre prochain.

    Cette conférence internationale sur LDAP et plus largement sur les questions de gestion des identités, d’authentification et d’habilitation, est l’occasion de rencontrer les acteurs les plus importants du domaine.

    Pour en savoir plus: https://ldapcon.org/2017/conference-program/ (mots-clés: ReOpenLDAP, Sparrow, OpenLDAP, Apache Mavibot, PHP-LDAP, load balancing, replication, SSO, FusionDirectory, ForgeRock, etc.).

    De plus, la date de vente des tickets au tarif "inscription anticipée" de la LDAPCon 2017 a été étendue au 25 août; vous pouvez encore acheter votre ticket Early Bird.

    Lire les commentaires

  • Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier (Dépêches LinuxFR)

    Pour mes besoins personnels et professionnels, j'ai développé un script pour sauvegarder mes données (fichiers présents sur le disque local et bases de données MySQL) et les archiver sur Amazon S3 et Amazon Glacier.

    Il est possible de choisir la fréquence de sauvegarde (jusque toutes les heures si nécessaire), et définir une politique précise pour la purge des données. Il est ainsi possible d'avoir un comportement du type :

    • sauvegarde toutes les heures : les données sont enregistrées en local et envoyées sur Amazon S3 et Amazon Glacier ;
    • toutes les sauvegardes sont gardées en local pendant deux jours, puis on garde quatre sauvegardes par jour (une toutes les six heures) pendant cinq jours, puis une par jour pendant deux semaines, puis elles sont effacées ;
    • toutes les sauvegardes sont gardées sur Amazon S3 pendant deux semaines, puis on garde six sauvegardes par jour (une toutes les quatre heures) pendant deux semaines, puis deux par jour pendant un mois, puis elles sont effacées ;
    • toutes les données sont gardées sans limite de temps sur Amazon Glacier.

    Le choix des services cloud d'Amazon se veut pragmatique. Amazon S3 est très utilisé pour stocker des données auxquelles on veut pouvoir accéder rapidement. Amazon Glacier est très pratique pour enregistrer des données sur le long terme pour un coût très bas.

    Ce script propose une interface de configuration en ligne de commande qui se veut facile à utiliser. Les fichiers de logs se veulent aussi les plus lisibles possibles.

    Exemple de configuration :
    Configuration Arkiv

    Exemple de fichier de log :
    Log Arkiv

    Le code a été placé sous la licence MIT (licence libre permissive).

    Lire les commentaires

  • Agenda du Libre pour la semaine 33 de l'année 2017 (Dépêches LinuxFR)

    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

    [FR Chartres] OpenAtelier - Le mercredi 16 août 2017 de 20h00 à 23h59.

    L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

    Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

    Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

    [FR Toulouse] Rencontre Tetalab - Le mercredi 16 août 2017 de 21h00 à 23h00.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [QC Coteau du Lac] Émission #137 de bloguelinux - Le jeudi 17 août 2017 de 02h00 à 22h00.

    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 à 20 heures 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.

    [QC Montréal] Atelier du Libre du Club Linux Atomic - Le jeudi 17 août 2017 de 18h00 à 21h30.

    Le Club Linux Atomic
    Le Club Linux Atomic (CLA) regroupe des utilisateurs, novices comme aguerris, de systèmes d’exploitation GNU/Linux et de logiciels libres. Il a pour principal objet de mieux faire connaître l’informatique libre et d’en favoriser l’utilisation par le plus grand nombre.
    Atelier du Libre

    [QC Montréal] UP des NCS - Atelier «Libérer l'informatique» - Le vendredi 18 août 2017 de 14h00 à 15h30.

    Lors de cet atelier qui s'intitule «Libérer l'informatique», il sera question des nouvelles formes de résistance au numérique dominant, celui qui sert les intérêts du 1%.
    Mathieu Gauthier-Pilote présentera principalement les initiatives de FACiL pour promouvoir l'appropriation collective de l'informatique libre (notamment le projet Services FACiLes, la Clé FACiL, la campagne Pacte du logiciel libre, etc.) tandis que Luc Levebvre présentera les initiatives de Crypto.Québec (le podcast «Les Chiens de garde», un livre en préparation, etc.) .
    Cet atelier se déroule dans le cadre de l'Université populaire des Nouveaux Cahiers du socialisme (NCS), dont l'un des deux axes principaux cette année est «La révolution « numérique » : les enjeux pour le 99%».

    [FR Villeneuve d'Ascq] Libre à Vous - Le samedi 19 août 2017 de 09h00 à 12h00.

    Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres?

    Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.

    C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

    Entrée Libre. Tout Public.

    [FR Valenciennes] Permanence ValLibre - Le samedi 19 août 2017 de 09h30 à 12h00.

    Permanence assistance informatique.

    Dépannage petits bobos informatiques.

    Initiation à l'informatique libre.

    Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

    Si besoin particulier, la prise de rendez-vous est fortement conseillée.

    Téléphone accueil MQCV : 03 27 22 43 90

    [FR La Couronne] Permanence - accueil public - Le samedi 19 août 2017 de 10h00 à 13h00.

    Notre permanence d'accueil avec le sourire, le café et les gâteaux !

    Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

    Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

    Entrée Libre. Tout Public.

    [FR Nanterre] Lightning talks de l'Electrolab - Le samedi 19 août 2017 de 16h00 à 18h00.

    Les Lightning-Talks consistent en de courtes présentation (5 mn max + 3 mn de questions) de projets terminés, en cours, ou toujours en réflexion.

    Toutes les personnes qui sont prêtes à partager leurs idées les plus folles devant une foule en délire sont invitées

    Vous bénéficierez de retours des membres sur vos choix techniques et probablement de conseils bienvenus.

    Lire les commentaires

  • Firefox 55 est prêt pour la rentrée 2017 (Dépêches LinuxFR)

    Le 8 août dernier, Mozilla a annoncé la sortie de Firefox 55.

    Les profils utilisateurs reçoivent des mises à jour incompatibles avec les anciennes versions de Firefox, ne vous précipitez donc pas sur la mise à jour et faites d’abord une sauvegarde de votre dossier .mozilla.

    Logo Firefox

    Mozilla indique que cette nouvelle version apporte des améliorations de performance, des technologies innovantes, telles que la réalité augmentée pour le Web (WebVR), de nouvelles options d’optimisation de gestion du matériel et des processus, plus de confidentialité et des améliorations de l’expérience utilisateur. Tous les détails sont disponibles dans la suite de la dépêche.

    Sommaire

    Nouveautés générales

    Tout d’abord, des modifications sont apportées dans les profils Firefox, ce qui rend les profils à partir de Firefox 55 incompatibles avec les anciennes versions de Firefox. Avant de mettre à jour votre navigateur, faites une sauvegarde de votre profil actuel afin de pouvoir revenir sur les anciennes versions si nécessaire.

    Avec ces dernières versions (Firefox pour bureau et pour Android), Firefox améliore la confidentialité de votre vie privée par le refus d’utilisation des interfaces de géolocalisation pour les sites qui fournissent une connexion non sécurisée à leurs services.

    Une nouveauté intéressante pour les développeurs est que Firefox pour GNU/Linux peut être utilisé sans interface graphique (mode headless à activer avec le paramètre de commande éponyme). Ceci permettra par exemple d’utiliser le moteur de Firefox pour exécuter des tests d’intégration continue, même si la machine d’intégration n’a pas de serveur graphique à disposition.

    Firefox pour bureau

    La nouveauté la plus mise en avant par Mozilla est que Firefox peut utiliser les périphériques de réalité virtuelle depuis le Web grâce à l’introduction de l’API WebVR. Un site dédié est à disposition pour découvrir cela. Mozilla insiste sur cette nouveauté dans son annonce pour bien afficher son intention de continuer à être un navigateur au cœur des innovations technologiques.

    À côté de cette nouveauté, Firefox pour le bureau connaît plusieurs améliorations de son interface graphique dans cette version :

    • la barre de navigation principale a été retravaillée : Barre de navigation retravaillée
      • les suggestions de recherche sont activées par défaut pour les utilisateurs qui ne les ont pas désactivées explicitement (passage de opt-in à opt-out),
      • la recherche peut enfin y être effectuée avec un des différents moteurs configurés au lieu de l’unique moteur par défaut ;
    • les barres latérales (marque‐pages, historique, onglets synchronisés) peuvent être déplacées vers le côté droit de la fenêtre : Barre latérale à droite
    • la capture d’écran des pages est possible directement depuis le navigateur avec l’outil Firefox Screenshots. Cet outil permet de créer des captures d’écran de pages entières ou d’une partie seulement et de les enregistrer localement ou sur le cloud de Firefox. Ce nouvel outil sera activé uniquement pour une partie des utilisateurs afin de continuer les tests du service : Une capture d’écran en direct !
    • l’impression depuis le mode lecture a été simplifiée ;
    • sur Mac OS X et macOS, Firefox permet d’assigner des raccourcis personnalisés aux menus via le menu Préférences systèmeClavierRaccourcis.

    Firefox pour bureau continue de développer ses performances :

    • les sessions comportant un grand nombre d’onglets sont dorénavant restaurées instantanément ;
    • les performances peuvent être optimisées :
      • par l’activation de l’accélération matérielle, quand elle est disponible. Pour le format vidéo VP9, par exemple, il est nécessaire d’utiliser Windows 10 Anniversary Edition. L’option est désactivée si aucune accélération matérielle n’est disponible pour la configuration matérielle et logicielle de la machine,
      • par l’ajustement de la limite maximale du nombre de processus utilisés pour effectuer le rendu des pages Web (un maximum de 4 processus est recommandé, mais il peut être poussé jusqu’à 7).

    Mozilla simplifie l’installation de Firefox sur Windows :

    • l’installateur par défaut est simplifié : son exécution télécharge et installe automatiquement Firefox sans action supplémentaire par l’utilisateur ;
    • Firefox 64 bits est automatiquement installé pour les ordinateurs disposant de Windows 64 bits et d’au moins 2 Gio de mémoire vive ;
    • Les installateurs complets sont toujours disponibles pour les utilisateurs avancés.

    Le nouvel installateur de Firefox

    Quelques modifications permettent de protéger un peu mieux la confidentialité des données utilisateurs :

    • lors de la saisie d’un nom de domaine sans indication du protocole (http://, https://) dans la barre de navigation, Firefox tente d’abord la connexion avec le protocole sécurisé HTTPS au lieu de HTTP ;
    • le greffon Flash est par défaut en « cliquer pour activer » et uniquement autorisé en HTTP et HTTPS, ce changement va être lancé progressivement et ne sera pas visible par tous les utilisateurs immédiatement. Plus d’informations sur la feuille de route des greffons dans Firefox (en anglais).

    En vrac, les autres modifications apportées pour cette version :

    • Firefox pour bureau est traduit en biélorusse (be) ;
    • l’implémentation WebRTC gère maintenant les microphones stéréos ;
    • l’interface utilisateur pour les mises à jour a été modernisée pour être moins intrusive et plus alignée avec le reste du navigateur. Seuls les utilisateurs qui n’ont pas redémarré leur navigateur huit jours après le téléchargement d’une mise à jour ou ceux qui ont désactivé les mises à jour automatiques verront ce changement.

    Les développeurs ne sont pas en reste et les outils disponibles reçoivent aussi des mises à jour :

    • le moniteur réseau permet de sélectionner les colonnes à afficher ; de nouvelles colonnes apparaissent également : l’adresse IP distante, le protocole, le schéma, les cookies, les cookies créés ;
    • ce dernier fournit en plus une interface de filtre des connexions à afficher (par des filtres sur les valeurs des colonnes ou par expressions régulières) ;
    • l’en‐tête HTTP SourceMap est pris en compte pour aider le débogage des codes JavaScript « minifiés » ou générés automatiquement depuis d’autres sources].

    Comme d’habitude, pour connaître tous les changements sur les technologies invisibles de Firefox (moteur de rendu HTML, DOM, JavaScript, API, WebExtensions…), vous pouvez vous référer aux notes de versions pour développeur (en anglais).

    Firefox pour Android

    La version 55 de Firefox pour Android est la dernière qui sera installable sur Android 4.0 (sorti en 2011). Ainsi, les dernières mises à jour apportées pour Android 4.0 contiennent :

    • de nouvelles actions qui ont été ajoutées pour gérer les onglets : il est maintenant possible d’ordonner les onglets par le maintien et le déplacement d’un onglet dans la boîte à onglets ;
    • une option d’accessibilité a été ajoutée pour respecter la configuration système des polices lors de l’affichage des pages Web ;
    • pour les vidéos non visibles sur une page Web, le rendu des images ne sera plus effectué pour économiser l’énergie de la batterie. L’audio de ces vidéos, quant à lui, continuera d’être joué ;
    • Firefox pour Android est traduit en grec (el) et en lao (lo)

    Prochaines versions

    La version 56 de Firefox est prévue pour le 26 septembre, une aide dans l’espace de rédaction est bienvenue pour sortir la prochaine dépêche à temps.

    Les prochaines versions verront l’arrivée de :

    • la recherche dans l’écran Préférences, pour trouver rapidement les options de n’importe quelle catégorie ;
    • une restructuration de l’interface de Firefox en version 57. Le projet nommé Photon est déjà activé pour les utilisateurs de Firefox Nightly (la version de test de Firefox). Un débat a été lancé dans le journal de Jiehong : est‐ce que le nouveau projet Photon est un retour en arrière par rapport à l’ancien projet Australis ?

    Autour de Firefox

    Campagne de financement réussie pour Grammalecte

    Le développeur de Grammalecte pourra mettre à jour son extension Firefox grâce au succès de sa seconde campagne de financement participatif.

    Comme Mozilla a changé son fusil d’épaule pour les recommandations des technologies à utiliser pour les développeurs d’extensions (WebExtensions à la place du SDK qui remplaçait déjà XUL), Olivier devra reprendre le code de l’extension Grammalecte créée suite à son premier financement participatif pour rester compatible avec les futures versions de Mozilla Firefox.

    Pour plus d’informations, référez‐vous à la dépêche dédiée à la seconde campagne de financement de Grammalecte.

    Polémique d’utilisation de Google Analytics dans Firefox via les pages Web de Mozilla intégrées dans l’interface

    Le recours à Google Analytics dans Firefox même, sur la page des modules (about:addons), dans l’onglet Catalogue, fait polémique auprès des utilisateurs attachés au respect de leur vie privée.

    Techniquement, cette page interne à Firefox n’utilise pas directement Google Analytics, elle contient uniquement un objet XUL browser qui est l’équivalent du conteneur iframe de HTML. Cependant, le contenu de la page pointée par le conteneur pointe sur une page du site Web https://discovery.addons.mozilla.org qui, lui, recourt à Google Analytics.

    À noter, d’une part, que ce recueil de données ne semble pas pouvoir être bloqué avec la version WebExtension de uBlock Origin, d’autre part, que le navigateur Tor Browser (une version spécialisée de Firefox pour mieux protéger la vie privée) est aussi concerné.

    Un correctif conçu le 13 juillet par Mozilla pour ses sites consiste à bloquer l’envoi de données à Google lorsque le visiteur de https://addons.mozilla.org a activé la fonction « Ne pas me pister » du navigateur. Ainsi, l’activation cette fonction empêche le recueil de données, que ce soit directement sur la page Web addons.mozilla.org ou indirectement par la page about:addons de Firefox.

    Confronté à cette polémique, Mozilla a donc finalement décidé d’offrir le choix à l’utilisateur, mais selon la technique de l’opt‐out. Comme il s’agit de collecte de données à l’intérieur du navigateur, le choix de la technique de l’opt‐in aurait sans doute été plus éthique.

    De leur côté, les utilisateurs de Tor Browser ont évidemment réagi et ouovvert un rapport. La solution appliquée sera la suppression de cet onglet Catalogue dans l’interface de Tor Browser, comme c’était déjà prévu pour d’autres raisons dans ce projet.

    Vous pouvez lire le journal d’antistress pour plus de détails et de débats à ce sujet.

    Lire les commentaires

  • Loi Finances 2016 : un soulagement pour les logiciels de compta (Dépêches LinuxFR)

    Pour petit rappel la loi finances 2016, mise en application pour le 1er janvier 2018 introduit des contraintes pour les logiciels de caisse et de comptabilité (en gros, ne pas pouvoir supprimer des données) et un système d’attestation et de certification pour engager la responsabilité de quelqu’un en cas de fraude constatée avec le logiciel. Elle concerne tous les assujettis à la TVA.

    Le 15 juin dernier (oui, ça date un peu), le gouvernement a indiqué que le champ d’application de cette loi ne concernerait plus les logiciels de comptabilité, et donc uniquement les logiciels d’encaissement. Le communiqué indique également une volonté de simplifier les contraintes.

    LinuxFr.org a publié plusieurs dépêches sur le sujet grâce à la mobilisation de l’April et de la société Scil, éditrice du logiciel (libre) de caisse Pastèque.

    C’est une très bonne nouvelle pour les logiciels de comptabilité qui évite ainsi l’obligation d’être certifiés ou attestés. Ouf !

    En revanche, pas encore de détails du périmètre précis. Les nouveaux textes seront disponibles « d’ici la fin de l’année ». On espère juste que ce ne sera pas le 20 décembre.

    Le texte indique qu’il reste six mois pour se mettre en conformité. C’est donc un flou par rapport à d’autres informations qui circulent indiquant que la mise en application serait repoussée de six mois. Information pour laquelle je n’ai pas trouvé de référence officielle. Le communiqué indique bien la mise en application de la loi au 1er janvier 2018.

    Lire les commentaires

  • Sortie de GHC 8.2.1 (Dépêches LinuxFR)

    Une nouvelle version majeure du compilateur GHC pour Haskell est sortie.

    GHC

    Cette dépêche présente rapidement le langage Haskell, puis les nouveautés de la version 8.2.1 qui vient de sortir. En fin de dépêche, un exemple plus complet d’un code Haskell est présenté afin de motiver à l’usage de ce langage.

    Sommaire

    Présentation d’Haskell et de GHC

    Haskell est un langage de programmation fonctionnelle. Je vous invite à lire la dépêche de la sortie de GHC 8.0.1 qui réalise une présentation plus complète du langage.

    Une reformulation de la page de présentation du langage pourrait être la suivante :

    • Haskell est un langage statiquement typé. Chaque expression a un type qui est déterminé à la compilation et le compilateur s'assure que l'assemblage d'expressions a un sens. Ceci permet de fournir quelques garanties sur le programme, mais cela permet aussi beaucoup d'expressivité.
    • Haskell est un langage au typage inféré. Cela signifie que tous les avantages du typage statique viennent gratuitement, sans devoir écrire de déclaration complexe de type.
    • Haskell est purement fonctionnel. C'est un des langages (sans parler des langages dérivés d'Haskell ou d'un de ses ancêtres, Miranda, purement fonctionnel et à évaluation paresseuse) qui a cette propriété où, de façon simplifiée, les effets de bords apparaissent explicitement.
    • Haskell est concurrent. GHC, son compilateur le plus connu propose des primitives efficaces pour la concurrence et est capable d'exploiter tous les cœurs de calcul d'une machine.
    • Haskell est rapide : dans certains cas, on peut approcher les performances de langages comme C++
    • Haskell est paresseux, c'est un des rares langages à ma connaissance ayant cette caractéristique.
    • Haskell vient avec de nombreux paquets pour de nombreuses applications.

    À mon avis, Haskell / GHC est un outil intéressant à regarder, car il est un des rares langages « grand public » à proposer certaines fonctionnalités, comme la séparation explicite des effets de bords ou l'évaluation paresseuse. En outre, Haskell propose un système de type très puissant permettant de modéliser son domaine de travail de façon élégante. Il s'agit d'un outil capable dans beaucoup de domaines, allant du web au HPC, proposant de très bonnes performances et une sécurité accrue.

    Changements

    Comme d'habitude, de nombreux bugs et autres subtilités ont été réglés. J'ai essayé de résumer dans cette section les points que je trouve intéressants dans les notes de mise à jour.

    Mon changement préféré est que le compilateur affiche maintenant ses messages d'erreur avec de la couleur et un petit symbole montrant la zone de l'erreur.

    Performance

    Un des gros apports de cette 8.2.1 concerne la performance du compilateur qui est annoncé comme plus rapide, mais les notes de versions sont pauvres d'informations à ce sujet.

    De nombreux points visant les performances du code exécuté ont été traités, certains sont discutés dans les points suivants.

    Join points

    Les « join points » sont décrits sur le wiki et dans cette vidéo de Simon Peyton Jones : Compiling without continuations.

    Il s'agit d'une optimisation permettant de détecter plus de code sujet à être transformé en appel récursif terminal, ceci permettant une réduction non négligeable des allocations, puisqu'un appel récursif terminal se résume à peu de choses près à un saut dans le programme.

    Compact regions

    Un des gros reproches faits à la gestion de mémoire par Ramasse-miettes_(informatique) est le temps que peuvent prendre les phases de collection de mémoire. Dans le cas d'Haskell, l’implémentation choisie est en mode « Stop the world », dit autrement, tout s’arrête pendant la phase de récupération de la mémoire. Cette phase peut être longue car toute la mémoire utilisée par le processus doit être scannée pour mettre à jour la liste des objets vivants ou morts, et ceci peut introduire des pauses peu acceptables dans certains contextes temps réel.

    GHC 8.2 propose les compact regions qui sont des espaces de stockage d'objets qui ne font pas référence à d'autres objets en dehors de cet espace. Ainsi le ramasse-miettes peut ignorer cet espace pendant sa phase de parcours de la mémoire pour un gain de temps proportionnel à la quantité de mémoire qui n'a pas été parcourue.

    Point intéressant, une région compacte peut être sérialisée sur le disque de façon efficace.

    Types somme dépackés

    La représentation en mémoire d'un objet hiérarchique en Haskell dans GHC est composée de nombreuses indirections de pointeurs qui consomment de la mémoire et coûtent cher en performance du fait de l'absence de localité et d'un stress supplémentaire sur le ramasse-miettes.

    Le travail sur l'extension UnpackedSumTypes permet de représenter plus efficacement les types somme (i.e. les enums).

    Numa

    Des optimisations pour les architectures Numa (Non_Uniform_memory_Access) sont en place. Pour rappel, les architectures Numa ont des zones de la mémoire qui sont privilégiées par certains cœurs de calcul. Ainsi, il est plus efficace d'allouer la mémoire nécessaire pour un cœur dans une zone proche de celui-ci.

    Meilleure gestion du format DWARF

    Le format DWARF est utilisé par de nombreux outils de debug ou d'analyse de performance comme gdb, valgrind, perf. L'amélioration de sa gestion permet, entre autres, une meilleure prise en charge de ces outils.

    Pour information, perf est un outil qui permet de faire du profiling statistique de tout programme. Au lieu d'instrumenter le code pour compter très précisément les appels de fonctions, ce que pourrait faire un compilateur, perf se contente de regarder l'état du programme à différent instants.

    Cette méthode de profiling a de nombreux avantages. Elle ne nécessite pas de recompiler le code source pour ajouter l'instrumentation et ainsi elle ne modifie pas l'exécution du programme. Les résultats sont plus pertinents qu'une méthode avec instrumentation car celle-ci peut avoir un coût qui biaise les résultats. Elle permet aussi de lancer le profiling sur un programme qui s'exécute déjà.

    Malheureusement, GHC génère des programmes avec un modèle d’exécution bien différent de ceux des langages plus traditionnels, d'où la difficulté d'utiliser ces outils. La page du wiki GHC sur DWARF détaille ces problématiques et les améliorations réalisées dans GHC 8.2.

    BackPack

    BackPack vise à proposer un système de module plus puissant.

    On rappelle qu'en Haskell il existe une quantité impressionnante de types pouvant représenter une chaîne de caractères :

    • String, qui n'est autre qu'une liste chaînée de caractères Unicode. ([Char]). Celle-ci est déconseillée pour la gestion de vraie chaîne de caractères, du fait du coût en mémoire et des performances associées aux listes chaînées.
    • Text, qui est une représentation compacte de chaînes Unicode. Performante, elle est cependant critiquée par son choix de l'encodage interne — utf-16 — du fait du surcoût en mémoire comparé à de l'utf-8. Ce type vient en version stricte et paresseuse.
    • ByteString, qui est une représentation compacte de suite d'octets. Utilisée principalement pour les interactions binaires, elle vient en version stricte et paresseuse.
    • les Foundation String qui se veulent une alternative au Text en utilisant le codage interne en utf-8.

    Il en existe sûrement d'autres.

    Bref, c'est la jungle, car chaque type a son utilité en fonction de ses besoins en traitement correct des caractères, en traitement binaire, en évaluation paresseuse ou stricte.

    Avant BackPack, faire un module gérant les différents types de chaîne de caractères disponibles dans Haskell revenait à devoir faire autant de modules que d’implémentations à gérer… bonjour la duplication de code.

    Grâce à BackPack, les modules peuvent être paramétrés par une interface de type, permettant une implémentation générique du module. C'est très similaire aux modules paramétrés de OCaml.

    Stratégie de dérivation

    Haskell propose un mécanisme de dérivation de comportement automatique. Par exemple :

    data Vector = Vector {
        x :: Float,
        y :: Float,
        z :: Float
        } deriving (Show, Eq)

    Crée une classe Vector, représentant un triplet de flottant. La clause deriving permet au compilateur d'écrire automatiquement les fonctions d'affichage des égalités, par exemple :

    >>> v = Vector 1 2 3
    >>> v
    Vector {x = 1.0, y = 2.0, z = 3.0}
    >>> v2 = Vector 4 5 6
    >>> v == v2
    False
    >>> v == v
    True

    On peut aussi imaginer dériver automatiquement les comportements de séralisation, hash, conversion avec JSON, …

    Ce mécanisme a évolué au cours de la vie de Haskell, au départ il permettait de ne dériver que certains comportements fixes proposés par le compilateur. Puis de nouveaux comportements ont été ajoutés. Puis il est devenu possible pour un utilisateur de proposer son propre système pour dériver automatiquement des comportements. Du fait de la profusion de mécanismes de dérivation, certains cas sont devenus ambigus.

    GHC 8.2 fait un peu le ménage en proposant DerivingStrategies qui permet de choisir explicitement la stratégie à utiliser. Cet article résume le problème et démontre la solution.

    Amélioration du typage dynamique

    Haskell est un langage au typage statique, à ce titre il prend en charge bien évidemment la notion de typage dynamique par le biais du module Data.Dynamic.

    On peut encapsuler n’importe quel type dans un type Dynamic, mais pour le récupérer il faudra explicitement fournir le bon type :

    Prelude Data.Dynamic> a = toDyn "Hello"
    Prelude Data.Dynamic> b = toDyn True
    Prelude Data.Dynamic> :type a
    a :: Dynamic
    Prelude Data.Dynamic> :type b
    b :: Dynamic
    Prelude Data.Dynamic> (fromDynamic a) :: Maybe String
    Just "Hello"
    Prelude Data.Dynamic> (fromDynamic a) :: Maybe Bool
    Nothing
    Prelude Data.Dynamic> (fromDynamic b) :: Maybe String
    Nothing
    Prelude Data.Dynamic> (fromDynamic b) :: Maybe Bool
    Just True

    GHC 8.2 apporte l'implémentation du papier A reflection on types de Simon Peyton Jones, Stephanie Weirich, Richard A. Eisenberg et Dimitrios Vytiniotis, détaillé dans cette vidéo de SPJ. Ces changements ne seront pas forcément visibles pour un utilisateur final, mais ils simplifient et sécurisent l'implémentation de bibliothèques comme Dynamic en remplaçant un hack (un cast) par une opération garantie par le compilateur.

    Overloaded record fields

    La situation des record, i.e. des structures avec des champs nommés, n'est pas parfaite en Haskell.

    Depuis GHC 8.0, beaucoup de travail est fait à ce sujet, notamment avec l'arrivée des extensions :

    • DuplicateRecordField qui permet de définir dans le même module deux types avec des noms de champs égaux.
    • OverloadedLabels qui permet de définir des labels, syntaxiquement #foo qui seront surchargés en fonction du type.

    GHC 8.2 va un peu plus loin et propose la classe HasField qui permet d'extraire un champ de record de façon polymorphique, par exemple getField @"x" v permet d'extraire le champ x de v quel que soit le type de v.

    Notez que GHC 8.2 est incompatible avec le code de OverloadedLabels de GHC 8.2 et qu'il faudra adapter son code.

    Un meilleur support du polymorphisme "levity"

    Richard A. Eisenberg - Levity Polymorphism (en anglais).

    En Haskell (et dans de nombreux autres langages), il existe des objets « boxés » et des objets non « boxés ». Par exemple, un Int# est représenté par un entier machine sur 64 bits, alors qu'un Int est représenté par un pointeur de constructeur, que l'on pourrait assimiler à un tag de type, et par un Int#, tout cela pour deux fois plus de mémoire.

    Généralement, on n'utilise pas les types "non boxés" et le compilateur optimise cela comme il peut. Cependant quand les performances sont attendues, il peut être intéressant d'écrire du code sur des types non "boxés" et à un moment, il devient important de pouvoir écrire des fonctions polymorphiques travaillant aussi bien sur des types "boxés" que "non boxés".

    Exhaustivité des patterns

    Le nouveau pragma COMPLETE permet de forcer l'exhaustivité des patterns.

    Par défaut, chaque type crée aussi un pattern utilisable pour construire / déconstruire le type :

    data Point = Point Float Float deriving (Show)
    
    isOrigin (Point 0 0) = True
    isOrigin _ = False
    
    getX (Point x _) = x
    
    translate (Point x y) (dx,dy) = Point (x + dx) (y + dy)

    Il est cependant possible de créer ses propres patterns pour créer de nouvelles façons de construire / déconstruire ses types :

    {-# LANGUAGE ViewPatterns #-}
    {-# LANGUAGE PatternSynonyms #-}
    
    pattern PolarPoint r phi <- (\ (Point x y) -> (sqrt (x*x+y*y), atan2 y x)) -> (r, phi) where
        PolarPoint r phi = Point (r * cos phi) (r * sin phi

    Ici, je crée un pattern PolarPoint r phi qui représente un point en coordonnées polaires. On peut s'en servir autant pour créer que pour déconstruire :

    > PolarPoint 10 0
    Point 10.0 0.0
    > PolarPoint 10 (pi / 2)
    Point (-4.371139e-7) 10.0
    > PolarPoint r angle = Point 2 2
    > r
    2.8284271247461903
    > angle
    0.7853981633974483

    Cependant, avant GHC 8.2, le compilateur râlait sur les fonctions utilisant ce pattern :

    -- | Retourne `True` si le point est plus loin qu'un rayon de 10
    isFar :: Point -> Bool
    isFar (PolarPoint r _) = r > 10
    Polar.hs:18:1: warning: [-Wincomplete-patterns]
        Pattern match(es) are non-exhaustive
        In an equation for ‘isFar’: Patterns not matched: _
       |
    18 | isFar (PolarPoint r _) = r > 10
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    

    En effet, le compilateur ne peut pas prouver tous les cas de figure des patterns, ce qui se traduit par beaucoup de faux positifs dans lesquels les vrais positifs sont cachés, rendant cette fonctionnalité peu utilisable.

    Depuis GHC 8.2, l'utilisateur peut fournir une directive de compilation {-# COMPLETE PolarPoint #-} permettant de spécifier que le pattern PolarPoint couvre tous les cas de figure.

    L'écosystème

    Stack est un outil de gestion de dépendance pour Haskell. Il peut sous-traiter à Nix pour les dépendances non Haskell, permettant ainsi la compilation dans un environnement contrôlé. Pour faire simple, un programme Haskell peut être compilé en une seule ligne de commande stack build sans devoir se préoccuper de l'installation de dépendances.

    L'utilisation de Stackage qui fournit des snapshots de packages versionnés garantit qu'un programme compilé il y a quelques mois le sera dans les mêmes conditions.

    Stack a gagné dernièrement une nouvelle commande script qui permet d’exécuter un programme Haskell comme un script en installant les dépendances listées dans le script lui-même. Nous verrons un cas d'usage dans la section d'exemples plus loin.

    Le futur

    Haskell (et GHC) évolue constamment. Cette section liste quelques projets excitants pour l'avenir.

    Typage dépendant

    Cet article de blog détaille le travail sur les types dépendants en Haskell qui devrait arriver plus ou moins rapidement, l'auteur parlant de GHC 8.6.

    Les Types dépendants permettent d'enrichir le système de type afin de garantir plus de choses.

    Pour expliciter cela, nous allons traiter un petit problème de multiplication de matrices.

    Soit un type Matrice qui pourrait être représenté comme suit en Haskell :

    data Matrice = Matrice {
         nLignes :: Int,
         nColonnes :: Int,
         donnée :: (... structure non détaillée ...)
    }

    Le produit matriciel est une opération classique d’algèbre qui s'effectue entre deux matrices et renvoie une nouvelle matrice. Cependant il y a une contrainte entre la taille des matrices d'entrées et le résultat de la matrice de sortie. Une matrice de taille (m, n) ne peut être multipliée que par une matrice de taille (n, p) pour obtenir une matrice de taille (m, p).

    Bien souvent cette contrainte est assurée par une vérification à l’exécution :

    produitMatrice :: Matrice -> Matrice -> Matrice
    produitMatrice (Matrice m n dataA) (Matrice n' p dataB)
        | n == n' = (Matrice m p (... calcul non détaillé ...))
        | otherwise = error "Pas les bonnes tailles"

    Il est à l'heure actuelle possible en Haskell de spécifier ces tailles directement dans le type, tel que :

    data Matrice nLignes nColonnes = Matrice {
          donnée :: (... structure non détaillée ...)
       }

    Donnant ainsi le produit suivant :

    produitMatrice :: Matrice m n -> Matrice n p -> Matrice m p
    produitMatrice (Matrice dataA) (Matrice dataB) = Matrice (... calcul non détaillé ...)

    Cette approche force le compilateur à vérifier que les tailles de nos matrices sont correctes pendant la compilation, ce qui supprime totalement toute une classe d'erreur à l’exécution.

    Justin Le a rédigé une très bonne série d'articles qui traite de l'état actuel du typage dépendant en Haskell en implémentant un réseau de neurone multi couches.

    Une des limitations de cette approche est que les tailles, des réseaux de neurone ou des matrices de notre exemple, doivent être connue intégralement à la compilation, empêchant l'écriture d'un outil pouvant charger depuis le disque une matrice de taille quelconque.

    Dans la seconde partie de son article, Justin Le parle de ce problème et montre les solutions existantes pour réaliser ce type d'opérations. On peut donc écrire une fonction de chargement de matrice depuis le disque avec des tailles statiques :

    chargerMatrice :: Filename -> IO (Matrice n m)

    Je ne détaillerais pas la solution, c'est, à mon avis, lourd et rébarbatif. Le travaille sur le typage dépendant qui est en cours dans GHC vise à simplifier cela.

    Typage linéaire

    Le typage linéaire devrait arriver sous peu dans GHC. Ce travail est en grande partie réalisé par une société française, tweag.io, donc cocorico ;) On note leur publication sur les types linéaires et leur premier article de Blog expliquant le projet.

    Les types linéaires apportent à la fois un potentiel de performance et de sécurité / modélisation.

    Pour simplifier, c'est une façon de dire qu'une valeur ne sera utilisée qu'une et une seule fois. Je ne rentrerai pas dans les détails de son implémentation en Haskell puisque c'est tout nouveau et que les choses peuvent beaucoup bouger, je me contenterai de donner deux exemples de problématiques que les types linéaires peuvent résoudre.

    Sécurité et modélisation

    Cet article de Blog détaille ce point, l'exemple qui suit est similaire.

    Quand on utilise des sockets, on peut faire de nombreuses actions en fonction de l'état de la socket, qui sont résumées dans le graphe suivant:

    Non initialisée ---bind()---> En attente ----listen()---> En écoute
         \                                                     /
          \                                                   accept()
           \-----connect()----> Envoyer/Recevoir  <==========/
    

    Ici, une flèche simple représente un changement d'état de la socket. Et la flèche === représente le fait que la fonction accept retourne une nouvelle socket directement dans l'état d'envoi et de réception de message.

    À chaque état est associé une liste d'opérations possibles, par exemple recv et send ne sont possibles que dans l'état de transfert.

    On pourrait modéliser ces états par des types différents :

    data NonInitSocket = NonInitSocket Int
    data AttenteSocket = AttenteSocket Int
    data EcouteSocket = EcouteSocket Int
    
    data TransfertSocket = TransfertSocket Int

    L'Int représentant le descripteur de fichier bas niveau de la socket.

    Et à cela s'ajoute des fonctions :

    create :: IO NonInitSocket
    
    bind :: NonInitSocket -> Addr -> IO AttenteSocket
    listen :: AttenteSocket -> Int -> IO EcouteSocket
    connect :: NonInitSocket -> Addr -> IO TransfertSocket
    
    accept :: EcouteSocket -> IO TransfertSocket
    send :: TransfertSocket -> String -> IO ()
    recv :: TransfertSocket -> Int -> IO String
    closeEcoute :: EcouteSocket -> IO ()
    closeTransfert :: TransfertSocket -> IO ()

    Les IO matérialisant que chacune de ces fonctions réalise des effets de bord.

    Et là tout est beau dans le meilleur des mondes, on ne peut pas exécuter une fonction qui n'a pas de sens sur une socket qui n'est pas dans le bon état.

    Sauf que si… Observons le code suivant :

    fonctionBugée = do
       s <- create
    
       attenteSocket <- bind s anAddr
       ecouteSocket <- listen attenteSocket 3
    
       ...
    
       transfertSocket <- connect s anotherAddr

    Ici on voit qu’on se sert deux fois de s ce qui est faux puisque à ce moment le descripteur de socket qui est stocké dans s correspond à une socket en état d'écoute.

    On remarque aussi qu'on ne ferme jamais nos sockets.

    Les types linéaires peuvent ici nous sauver en refusant à la compilation le second usage de s. De même, la compilation pourrait refuser ce code qui n'utilise pas ecouteSocket ni transfertSocket, la seule façon de les utiliser étant de les fermer. Ainsi les types linéaires permettent de détecter à la compilation des mauvais usages de ressources.

    Performance

    Haskell est un langage où on maximise la non mutabilité. Ainsi on va préférer créer une nouvelle structure de données plutôt que d'en modifier une. Haskell tire profit de cette non mutabilité pour partager au maximum les parties communes entre plusieurs données.

    S'il existe des structures non mutables performantes (à lire, c'est très instructif), ce n'est pas le cas de toutes les structures. Ainsi, un vecteur n'est pas du tout adapté à la non mutabilité, car il faut recopier intégralement celui-ci en cas de modification d'une unique case.

    Une des premières choses qui vient à l'esprit c'est que si personne d'autre n'utilise la donnée, on pourrait la modifier sans scrupule. Cette information n'est cependant pas connue à la compilation et serait trop coûteuse à calculer lors de l’exécution.

    Les types linéaires permettent de garantir que notre valeur ne sera utilisée qu'une seule fois, sous peine de refuser de compiler. Cette information en main, une bibliothèque pourra proposer des fonctions optimisées avec mutation pour remplacer les fonctions qui copient. Et cela sans faire apparaître de mutation dans le code utilisateur.

    Exemple d'Haskell : le dîner des philosophes

    La fin de cette dépêche est consacrée à un exemple de résolution d'un problème en Haskell. Merci à jiehong de m'avoir soufflé l'idée de présenter la mémoire transactionnelle.

    Introduction

    Nous allons nous intéresser au problème des philosophes. Il s'agit d'un problème classique de programmation concurrente qui brille autant par son énoncé trivial que par le nombre de problématiques d’implémentation qu'il soulève.

    À une table ronde d'un restaurant italien, des philosophes discutent en mangeant. Chaque philosophe a à sa droite et sa gauche une fourchette, qu'il partage avec son voisin de droite et de gauche.

    Pour manger, un philosophe doit prendre les deux fourchettes, il pourra ensuite manger pendant un laps de temps variable, puis reposera les fourchettes. Cependant, en prenant les fourchettes, il empêche son voisin de droite et de gauche de manger.

    Le problème est donc d'ordonnancer le repas des philosophes en évitant des situations d'interblocage courantes tel que :

    • des « dead lock », où un philosophe sera en attente d'une fourchette prise par une autre philosophe lui-même en attente d'une autre fourchette. On peut imaginer une situation ou tous les philosophes sont bloqués de cette manière.
    • des « live lock », où les fourchettes changent de main en permanence, mais sans que personne ne puisse manger.

    Une solution simple à ce problème consiste en l'usage d'un verrou global. Chaque philosophe désirant manger va tenter de prendre le verrou global et une fois celui-ci verrouillé, il prendra ses deux fourchettes si et seulement si les deux sont disponibles. Cette solution est triviale à implémenter, mais ne passe pas à l'échelle, car elle séquence toutes les opérations de prise ou de dépose des fourchettes. Il faut donc employer une stratégie plus fine.

    Il existe de nombreuses solutions à ce problème, nombreuses sont complexes à implémenter, et impose une grande rigueur. Par exemple en s'assurant de ne prendre et rendre les verrous toujours dans le même ordre, on s'assure théoriquement qu'il n'y a pas d'interblocage, par exemple si un philosophe s'assure de prendre la fourchette gauche avant la droite. Mais il y a le cas du dernier philosophe de la table qui doit prendre sa fourchette droite avant la gauche, la fourchette droite étant en fait la première de la table. Bref, vous l'aurez compris, ce n'est pas trivial.

    Dans cet exemple de code Haskell, nous présenterons une solution utilisant les primitives de STM, "Software Transactional Memory", Mémoire transactionnelle logicielle. Cette technique offre de nombreux avantages, en termes de facilité de programmation et de composition du code.

    STM et Haskell

    En Haskell, nous pouvons créer une zone de mémoire modifiable par STM grâce à la fonction newTMVarIO. Cette zone contiendra ou pas une valeur. Grâce à putTMVar, nous pouvons mettre une valeur dans la zone. takeTMVar vide la zone et renvoie la valeur. Cette opération est bloquante.

    Nous pouvons représenter une fourchette par une TMVar () contenant simplement un (). On aurait pu mettre n'importe quoi dedans, la seule chose nous intéressant étant de savoir si la valeur est dedans ou pas.

    On peut composer ensemble un certain nombre d'opérations sur des TMVar et exécuter atomiquement le bloc grâce à atomically.

    Les STM divergent d'une stratégie plus classique à base de mutex par :

    • des opérations sont composables. On peut créer une action plus complexe à partir d'une ensemble de petits actions. Bien évidemment, plus l'action est complexe, plus la transaction a des chances d'échouer et de devoir recommencer.
    • les opérations atomiques ont une granularité très fine, car elles ne « verrouillent » que les variables impliquées dans la transaction. Ainsi on peut facilement imaginer modifier une structure de données en plusieurs points par plusieurs threads sans qu'il n'y ait de conflit.

    Exemple d’exécution

    Pour exécuter le programme, nous ferons appel à stack qui après installation des bibliothèques nécessaires va utiliser GHC en mode interprété, ce programme ne demandant pas de performance particulière.

    Le programme prend en paramètre le nombre de philosophes autour de la table. Chaque philosophe est nommé par une lettre. Quand celui-ci commence à manger, la console affiche une lettre majuscule, quand celui-ci s’arrête, elle affichera une lettre minuscule. Les philosophes essayent de manger pendant 30 secondes.

    Avec deux philosophes, on est en situation où seulement l'un peut manger :

    $ ./Philosopher.hs 2
    AaBbAaBbAaBbAaBbA
    

    Avec trois philosophes, seulement un peut manger

    $ ./Philosopher.hs 3
    AaBbCcAaBbCcA
    

    Avec quatre, c'est plus intéressant. Les philosophes ne peuvent manger ensemble que par groupes de 2, c’est-à-dire soit A et C, soit B et D. Ainsi, pour changer de groupe, il faut que les deux philosophes du même groupe arrêtent de manger en même temps. L’implémentation fait manger les philosophes pendant un temps aléatoire compris entre 0 et 2 secondes, et ils se reposent pendant 100 ms avant de recommencer à essayer de prendre les fourchettes. Ainsi, le moment ou les deux philosophes d'un groupe viennent de s’arrêter de manger ensemble est assez rare :

    $ ./Philosopher.hs 4
    ACcCaAcCaAcCaAcCcaBDdDdDbBdDbdACcaBDdDbB
    # ----------------| ICI
    

    Avec plusieurs philosophes, c'est bien plus drôle :

    $ ./Philosopher.hs 10
    ACEGIcgCGcCgGcaBiJjIeDgFbAiHdChIfGEgGeiEcICaAcCaAeiEIicICgGiIaAeEeEcCgGiIaAeEicICcCigH
    

    Implémentation

    Cette section détaille une solution en Haskell de ce problème. Des paragraphes d'explications s’intercalent entre les blocs de code qui peuvent être copiés collés en tant que tels dans un fichier Philosopher.hs.

    Prélude

    On commence par le Shebang décrivant interpréteur à utiliser. Ici stack. La ligne suivante liste les packages nécessaires pour ce fichier, à savoir stm pour l'usage de la mémoire transactionnelle, random pour générer des nombres aléatoires et optparse-generic pour lire la ligne de commande.

    #!/usr/bin/env stack
    -- stack script --resolver lts-9.0 --package "stm random optparse-generic"
    {-# LANGUAGE OverloadedStrings #-}

    Viennent l'import des modules nécessaires pour notre code. J'ai choisi d'importer de façon qualifier chaque fonction afin que le lecteur puisse connaitre sa provenance.

    module Main where
    
    import Control.Monad (replicateM, forever)
    import Control.Concurrent.STM (TMVar, putTMVar, takeTMVar, newTMVarIO, STM, atomically)
    import Control.Concurrent (forkIO, killThread, threadDelay, ThreadId)
    import System.Random (randomRIO)
    import Data.Char (toLower)
    import Options.Generic (getRecord)

    Fourchettes

    La gestion des fourchettes. En premier lieu, le type Fork qui représente une fourchette. Celui-ci contient un TMVar (), c’est-à-dire un conteneur STM qui peut contenir un (), c’est-à-dire « rien ». Mais on peut connaitre la présence ou l'absence de ce rien et c'est ce qui nous intéressera.

    data Fork = Fork (TMVar ())

    takeFork et releaseFork respectivement prennent et reposent une fourchette. takeFork sera bloquant. On note au type des fonctions que ces opérations s'effectuent sous le contrôle de la STM.

    -- | Prend une fourchette. Bloquant.
    takeFork :: Fork -> STM ()
    takeFork (Fork var) = takeTMVar var
    
    -- | Repose une fourchette. Non Bloquant.
    releaseFork :: Fork -> STM ()
    releaseFork (Fork var) = putTMVar var ()

    La création d'une fourchette avec mkFork implique la création d'une TMVar avec newTMVarIO :

    -- | Crée une fourchette
    mkFork :: IO Fork
    mkFork = do
      var <- newTMVarIO ()
      pure (Fork var)

    Ce morceau de code implique énormément de choses sur Haskell, nous allons nous y attarder un moment. Le type de la fonction est IO Fork, c'est une action d'entrée / sortie qui renvoie une fourchette. La première ligne réalise une action newTMVarIO () qui crée une nouvelle TMVar contenant un (). Celle-ci est stockée dans var. Il ne s'agit pas d'une égalité, mais d'une affectation, ici var est bien le résultat de l’exécution d'une action et non pas une égalité qui serait représentée avec le signe =.

    La valeur de retour de la fonction est Fork var c’est-à-dire la TMVar encapsulée dans le type Fork. Cette expression Fork var, de type Fork ne représente pas une action à effet de bord, ainsi elle ne peut pas être la valeur finale de la fonction (qui est de type IO Fork). Il faut donc encapsuler de nouveau le Fork dans une IO, est cela est fait grâce à la fonction pure.

    Ne vous en formaliser pas trop, c'est surprenant au début, mais on s'y fait vite.

    La création de n fourchettes se fait grace à la fonction replicateM qui réplique l'action mkFork et donc renvoie une liste de Fork. le M ici signifie que on réplique une action. Sinon on pourrait écrire replicate 3 True == [True, True, True] sans le M car True n'est pas une action.

    -- | `mkForks n` crée une liste de `n` `Fork` disponibles
    mkForks :: Int -> IO [Fork]
    mkForks n = replicateM n mkFork

    Philosophes

    Un philosophe est simplement une structure qui comprend un nom, sous la forme d'un Char, et deux Fork.

    -- | Un `Philosopher` est représenté par son nom et deux fourchettes
    data Philosopher = Philosopher Char Fork Fork

    La création de plusieurs philosophes, en se servant de fourchettes est la suivante :

    -- | Crée le nombre de philosophes associés aux fourchettes 
    mkPhilosophers :: [Fork] -> [Philosopher]
    mkPhilosophers forks = zipWith3 Philosopher ['A'..] forks (last forks : forks)

    Cette fonction est très concise mais complexe. Nous avons une liste de fourchettes (pour simplifier [fork0, fork1, fork2]) et nous voulons crée une liste de Philosophes chacun associé à une lettre et à deux fourchettes.

    On aimerait la liste suivante : [Philosopher 'A' fork0 fork2, Philosopher 'B' fork1 fork0, Philosopher 'C' fork2 fork1].

    Un motif apparaît, on voit qu'il s'agit de la fonction Philosopher appliquée à 3 arguments pris respectivement dans 3 listes distinctes grace à la fonction zipWith3 :

    • ['A', 'B', 'C'], que nous représentons ici avec la liste infinie ['A' .. ]
    • [fork0, fork1, fork2], c'est tout simplement forks
    • [fork2, fork0, fork1], qui est ici (last forks : forks)

    Cela fonctionne car zipWith3 ne consomme qu'en fonction de la longueur de la liste la plus courte.

    Vie d'un philosophe

    Une étape de la vie d'un philosophe est une fonction assez longue, mais peu complexe. La prise et la relâche des fourchettes est réalisée dans un bloc atomically, le reste n’étant que des attentes et un peu d'affichage.

    -- | Un `Philosopher` essaye de manger.
    runPhilosopher :: Philosopher -> IO ()
    runPhilosopher (Philosopher name forkA forkB) = do
      -- Prends les fourchettes de façon atomique, garantie par STM
      atomically $ do
        takeFork forkA
        takeFork forkB
    
      -- Affiche son nom en majuscules
      putChar name
    
      -- Mange pendant un temps aléatoire compris entre 0 et 2 secondes
      time <- randomRIO (0, 2 * 1000 * 1000)
      threadDelay time
    
      -- Affiche la fin du repas (nom en minuscule)
      putChar (toLower name)
    
      -- Repose les fourchettes de façon atomique
      atomically $ do
        releaseFork forkA
        releaseFork forkB
    
      -- Attend avant de recommencer pendant 100 ms
      threadDelay (1000 * 100)

    forkPhilosopher

    Cette fonction, pour un philosophe donné p, crée un green thread qui exécute en boucle infinie grâce à forever une étape de la vie de notre philosophe.

    forkPhilosopher :: Philosopher -> IO ThreadId
    forkPhilosopher p = forkIO (forever (runPhilosopher p))

    main

    Le main contient un peu de logique pour lire la ligne de commande et crée les philosophes.

    main :: IO ()
    main = do
      -- Lit le nombre de philosophe sur la ligne de commande
      nPhilosopher <- getRecord "Philosopher"
    
      -- Crée les fourchettes et les philosophes
      forks <- mkForks nPhilosopher
      let philosophers = mkPhilosophers forks
    
      -- Crée les threads par philosophe
      tIds <- mapM forkPhilosopher philosophers
    
      -- Attend 10 secondes et tue les threads
      threadDelay (1000 * 1000 * 10)
      mapM_ killThread tIds

    Quelques points à discuter dans cette fonction main. En premier lieu j'utilise getRecord pour lire la ligne de commande. Cette fonction, du module optparse-generic, est capable de créer toute seule une interface ligne de commande en fonction du type de retour demandé, ici un Int, en gérant automatiquement la lecture de la ligne de commande, la validation des arguments et l'affichage de l'aide si nécessaire. Cela m'a économisé 3 lignes de logique pour lire les arguments, vérifier qu'il y en avait au moins un, et le convertir en Int et afficher une erreur le cas échéant. Ce n'était pas forcement nécessaire dans ce contexte, mais cela devient extraordinaire avec une interface plus complexe impliquant des arguments optionnels, des drapeaux booléens, ou autres.

    La création des fourchettes est une opération avec effets de bord, d'où l'affectation du résultat avec <-. La création des philosophes elle ne réalise pas d'effet de bord, c'est une fonction pure, d'où l’égalité = qui signifie réellement que philosophers est sémantiquement équivalent à mkPhilosopher forks dans les lignes qui suivent. C'est un outil de compréhension de code que je trouve plaisant.

    Pour finir, la création des threads se fait avec mapM qui va applique la fonction forkPhilosopher à chaque philosophe et renvoyer l'identifiant du thread crée.

    Conclusion

    GHC 8.2 c'est sympa, il y a pleins de nouvelles fonctionnalités qui rendent heureux un développeur Haskell régulier. Mais soyons réaliste, ce n'est pas ces nouvelles fonctionnalités qui vont vous motiver à utiliser Haskell, c'est pourquoi j'ai essayé de présenter un cas concret d'utilisation du langage sur un problème assez classique d'algorithmie.

    Lire les commentaires

  • Agenda du Libre pour la semaine 32 de l’année 2017 (Dépêches LinuxFR)

    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 13 événements (0 en Belgique, 7 en France, 0 au Luxembourg, 6 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire

    [QC Montréal] DebConf17 - la conférence annuelle de Debian - Du dimanche 6 août 2017 à 09h00 au samedi 12 août 2017 à 17h00.

    DebConf est la conférence annuelle où les gens qui développent Debian et autres personnes intéressées se réunissent dans le but d'améliorer Debian.  Les DebConf précédentes ont accueilli des présentateurs et participants de partout dans le monde pour parler de Debian.  Par exemple, l'année passée, à Cape Town en Afrique du Sud, DebConf16 a vu venir du monde de 30 pays différents.
    Étant donné que le travail qui est fait sur Debian par ce monde divers est effectué en anglais, les événements DebConf ont lieu en anglais, aussi.  Cependant, pour l'Open Day, la journée portes-ouvertes qui précède DebConf17, nous encourageons les gens qui le veulent de présenter en français.
    Pour plus de renseignements par rapport à DebConf17, voir le site web à https://debconf17.debconf.org/

    [QC Montréal] Ring on! Célébrez et échangez avec l’équipe Ring! - Le mardi 8 août 2017 de 18h30 à 21h30.

    Vous êtes amicalement invité à la soirée "Ring on! Célébrez et échangez avec l’équipe Ring", ce mardi 8 août de 18 h 30 à 21 h 30 dans les locaux de Savoir-faire Linux.
    Célébrons ensemble la sortie de la première version stable de Ring "Ring 1.0 - Liberté, Égalité, Fraternité ", un logiciel de communication libre et universel, paquet GNU, soutenu par la Free Software Foundation.
    Rencontrez l’équipe Ring! Échangez, essayez et commentez cette version autour d’un cocktail dînatoire convivial. L’équipe sera ravie de recueillir vos avis et impressions sur cette nouvelle version!

    • Savoir-faire Linux, 7275, rue Saint-Urbain, Montréal
    • URL: https://framadate.org/FMX77NhhRVqW86JE
    • Mots-clés: linux, ring [FR Chartres] OpenAtelier - Le mercredi 9 août 2017 de 20h00 à 23h59. ----- L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

    Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

    Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

    [QC Montréal] Wikimania 2017 - Du mercredi 9 août 2017 à 08h00 au dimanche 13 août 2017 à 21h00.

    Wikimania est la conférence annuelle célébrant Wikipédia et ses projets frères ; trois jours de conférences, de discussions, de formations et d'ateliers. Des centaines de bénévoles et les sommités du savoir libre du monde entier se réunissent pour débattre, s’informer sur les nouvelles idées et approches, échanger et mettre en commun leurs idées.
    Les thèmes de la conférence incluent l’avancement du savoir libre, le rôle des institutions académiques et culturelles au sein du mouvement, la vie privée, les droits de l'être humain et le rôle de la technologie pour faire avancer ces objectifs. Wikimania 2017 portera également un regard plus approfondi sur le rôle du Mouvement au sein de la Francophonie, et la programmation d’événements axés sur la promotion du français et des cultures francophones au sein des projets.
    Au-delà de l'événement principal, il y a les événements connexes : le « Hackathon » où la communauté technique qui entoure les projets Wikimedia s’unit pour travailler et contribuer, et le « Sourcethon » où les vétérans et les nouveaux arrivants mettent leurs efforts en commun pour préserver et rendre disponibles des documents écrits historiques.

    [FR Toulouse] Rencontre Tetalab - Le mercredi 9 août 2017 de 21h00 à 23h00.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [QC Coteau du Lac] Émission #137 de bloguelinux - Le jeudi 10 août 2017 de 20h00 à 22h00.

    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 à 20 heures 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.

    [FR Strasbourg] Réunion mensuelle ouverte d'ARN - Le vendredi 11 août 2017 de 18h00 à 22h00.

    ARN vous accueil un vendredi par moi pendant le Stammtisch du Hackstub !

    Dans ces réunions :
    • nous accueillons des visiteur-se-s qui veulent en savoir plus sur notre démarche ou apprendre à nous connaître ;
    • nous évoquons les sujets actuels relatifs à l'association et au numérique autour de Strasbourg ;
    • nous faisons le point tous-toutes ensemble sur l'avancée des projets de l'association et des projets associatifs environnants ;
    • nous profitons de ces instants pour faire avancer les projets de l'association sous forme de groupes de travail ouverts.

    Ces réunions se concluent par un repas convivial à l'extérieur.
    Ces réunions sont ouvertes à tout le monde, membre d'ARN ou non. Pas d'inscription préalable.

    N'hésitez pas à venir échanger avec nous !

    [QC Montréal] WordCamp Montréal - Du samedi 12 août 2017 à 08h00 au dimanche 13 août 2017 à 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 à réseauter.

    Cette année, l’événement aura lieu à l’école de gestion John Molson School of Business au centre-ville de Montréal les 12 et 13 août, 2017.

    [FR Villeneuve d'Ascq] Libre à Vous - Le samedi 12 août 2017 de 09h00 à 12h00.

    Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres?

    Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.

    C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

    Entrée Libre. Tout Public.

    [FR Valenciennes] Permanence ValLibre - Le samedi 12 août 2017 de 09h30 à 12h00.

    Permanence assistance informatique.

    Dépannage petits bobos informatiques.

    Initiation à l'informatique libre.

    Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

    Si besoin particulier, la prise de rendez-vous est fortement conseillée.

    Téléphone accueil MQCV : 03 27 22 43 90

    [FR Morogues] Atelier libre - Le samedi 12 août 2017 de 10h00 à 12h00.

    Ateliers d'entraide informatique & bricolages divers

    Vous souhaitez apprendre à réparer votre ordinateur De l'aide pour installer votre premier linux 

    Vous souhaitez aller plus loin avec un ordinateur et héberger vos outils Un coup de main pour finir un montage électronique

    [FR La Couronne] Permanence - accueil public - Le samedi 12 août 2017 de 10h00 à 13h00.

    Notre permanence d'accueil avec le sourire, le café et les gâteaux !

    Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

    Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

    Entrée Libre. Tout Public.

    [QC Montréal] Réparothon INSERTECH à la Foire Écosphère - Le samedi 12 août 2017 de 13h00 à 16h00.

    La Foire Écosphère, Éco2Fest et Insertech co-organisent un Réparothon ! Apportez vos appareils défectueux à nos bénévoles. Ils vous montreront comment s’y prendre pour les réparer et les optimiser, afin de prolonger leur durée de vie et de réduire leur empreinte écologique.
    Événement gratuit, le nombre de places est limité : premier arrivé, premier servi.
    Appareils acceptés :

    Lire les commentaires

  • tsrc — un gestionnaire de dépôts git (Dépêches LinuxFR)

    Gérer du code dans plusieurs dépôts différents est toujours un peu compliqué. Chez tanker.io nous avons une petite équipe de développeurs, et chacun des membres peut être amené à coder dans plusieurs langages (C++, Go et JavaScript, principalement). Comme une grande partie du code est encore propriétaire, nous utilisons une instance GitLab hébergée dans nos locaux.

    Il existe plusieurs façons de gérer la synchronisation entre dépôts : la manière qui nous convient le mieux est d’avoir la même branche (ou le même tag) sur les dépôts concernés. Ceci nous a amené à développer notre propre outil, tsrc, qui est désormais disponible sur GitHub, sous licence BSD.

    tsrc-banner

    Pourquoi GitHub et pas GitLab ? Simplement parce que GitHub, bien que propriétaire, assure une meilleure visibilité au projet.

    Nos contraintes :

    • bonne prise en charge de Windows (ce qui exclut repo ou gws) ;
    • un seul fichier central permettant de connaître la liste précise des dépôts à cloner et leur localisation (ce qui exclut les outils comme mu-repo, ou scm.py) ;
    • d’un autre côté, nous n’avons pas vraiment besoin de gestion des dépendances entre dépôts (ce que mu-repo gère bien), parce que nous préférons avoir un dépôt par langage ;
    • pas de dépôt « maître » contenant plusieurs sous‐dépôts (ce qui exclut git-submodule et git-subrepo).

    Démonstration

    Vous pouvez vous faire une idée précise de comment fonctionne tsrc en regardant la démonstration que nous avons publiée sur asciinema.

    Installation

    tsrc est codé en Python et naturellement disponible sur Pypi.

    Il est utilisé par tous les membres de notre équipe, que ce soit sous GNU/Linux, macOS ou Windows. La version minimale requise pour tsrc est Python3.3. Notez que le support de Python 2.7 est exclu (simplement parce que Python3 est, de notre point de vue, un bien meilleur langage que Python2.7). Sur une distribution pas trop vieille (Python 3.3 étant sorti en 2012), un simple pip3 install tsrc --user fera donc l'affaire, après avoir rajouté ~/.local/bin dans votre PATH au besoin.

    Utilisation

    Clone initial

    tsrc fonctionne en utilisant un fichier « manifest » en YAML :

    repos:
      - src: foo
        url: git@gitlab.local:acme/foo
    
      - src: bar
        url: git@gitlab.local:acme/bar

    Le « manifest » en question doit être présent dans un dépôt Git. Cela fait, vous pouvez récupérer les dépôts en utilisant :

    $ tsrc init git@gitlab.local:acme/manifest

    Mise à jour des dépôts

    Vous pouvez mettre à jour tous les dépôts en utilisant :

    $ tsrc sync

    Un exemple de la sortie console :
    tsrc-sync

    Contrairement à repo, tsrc essaie par tous les moyens d’éviter la perte de données ou les effets inattendus. Par exemple, si votre branche a divergé ou que votre dépôt n’est pas « propre », tsrc préférera afficher un avertissement et vous laisser résoudre la situation par vous‐même.

    Notez que si vous n’aimez pas le fait que tsrc « cache » les commandes git, vous pouvez utiliser l’option --verbose.

    Gestion des « fusiodemandes » GitLab

    Vous pouvez créer et accepter des « fusiodemandes » (merge requests) avec tsrc push après un peu de configuration. Pour l’instant, cela ne fonctionne qu’avec GitLab (puisque c’est ce que nous utilisons en interne), mais la prise en charge de Gerrit ou GitHub n’est pas exclue.

    # Travail en cours sur ma-belle-branche
    $ tsrc push --assignee david
    # Crée une merge request assignée à David
    
    # La revue est terminée, on prévient GitLab que la branche
    # doit être fusionnée dès que l’intégration continue est passée :
    $ tsrc push --accept

    Bonus

    tsrc contient aussi quelques commandes pratiques comme tsrc log ou tsrc foreach, mais cette dépêche est déjà assez longue. ;-)

    Appel à contributions

    Les retours sous toute forme sont les bienvenus, dans les commentaires ou directement sur GitHub.

    Lire les commentaires

  • Agenda du Libre pour la semaine 31 de l’année 2017 (Dépêches LinuxFR)

    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 12 événements (0 en Belgique, 9 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

    [FR Paris] Les premiers mardis de la monnaie libre et équitable - Le mardi 1er août 2017 de 19 h à 21 h 30.

    Afin de faire vivre notre première monnaie libre, Gwan, mise en orbite depuis le 8 mars dernier, nous vous proposons des rencontres mensuelles tous les premiers mardis du mois à PARIS pour :

    1. échanger nos clés publiques G1et/ou Gtest, en vue d'accorder nos certifications en toute sécurité
    2. échanger sur nos expériences, idées ou autres propositions sur l'usage de G1
    3. aborder le domaine de la technique noeuds Duniter, Césium, Sakia, Silkaj, Yunohost, etc.

    Les premières rencontres ont eu lieu à partir de 18 Heures 30 au café Bert's situé au forum des Halles sous le cinéma, à quelques mètres de la Place carré.

    La prochaine rencontre aura lieu le 1er août prochain*, même lieu à partir de 19 heures*.

    Afin de gérer au mieux les rencontres, 2 mailings listes sont créées,

    l'une pour les inscriptions aux rencontres

    S'abonnerhttps://framalistes.org/sympa/subscribe/inscriptions_reunions_gtest_g1
    Se désabonnerhttps://framalistes.org/sympa/sigrequest/inscriptions_reunions_gtest_g1

    et l'autre, pour les échanges et discussions

    S'abonnerhttps://framalistes.org/sympa/subscribe/monnaies.gtest.g1
    Se désabonnerhttps://framalistes.org/sympa/sigrequest/monnaies.gtest.g1

    Précision ces rencontres sont LIBRES et donc largement ouvertes à tous quelque soit la géolocalisation de chacun

    A bientôt.

    site officiel : https://fr.duniter.org/

    forum : https://forum.duniter.org/

    [QC Montréal] Linux-Meetup Montréal - Le mardi 1 août 2017 de 19h00 à 22h00.

    Local de la rencontre : à confirmer
    Programmation de la rencontre
    Ce mois-ci, le thème de la soirée sera les réseaux sous Linux:  

    [FR Chartres] OpenAtelier - Le mercredi 2 août 2017 de 20h00 à 23h59.

    L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

    Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

    Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

    [FR Toulouse] Rencontre Tetalab - Le mercredi 2 août 2017 de 21h00 à 23h00.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Poitiers] Jeudi du Libre - Le jeudi 3 août 2017 de 17h30 à 20h30.

    Comme chaque premier jeudi du mois, les membres de l’APP3L se réunissent au Centre Régional d’Information Jeunesse (CRIJ).

    Et vous invitent à les rejoindre, de 17h30 à 20h30, afin d'échanger et d'en apprendre plus à propos des logiciels libres.

    Si vous le désirez, vous pouvez venir avec votre ordinateur portable ou fixe (nous prêterons écrans, claviers et souris).

    Cette permanence est l’occasion pour chacun de :

    • rencontrer d'autres utilisateurs.
    • de discuter ou de s’informer.
    • de trouver de l’aide (vous pouvez amener votre machine).
    • ou tout simplement de découvrir.

    Entrée Libre. Tout Public.

    Accès 64 rue Léon Gambetta 86000 Poitiers

    [FR Rennes] Barbecue du Libre - Le jeudi 3 août 2017 de 19h00 à 23h00.

    L'association Actux organise un barbecue du Libre le jeudi 3 août.

    Rendez-vous à 19h au parc des Gayeulles. On verra sur place si on s'installe du côté des barbecues ou devant l'étang.

    Chaque participant apporte ce qu'il souhaite manger, boire et partager.

    Entrée libre et gratuite.

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

    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

    tout nouveau projet est le bienvenu.

    [FR Villeneuve d'Ascq] Libre à Vous - Le samedi 5 août 2017 de 09h00 à 12h00.

    Vous souhaitez tester GNU/Linux sur votre ordinateur, vous recherchez un logiciel pour une fonction précise, des conseils ou de l'aide sur les logiciels libres?

    Libre à Vous est une permanence destinée à vous faciliter l'utilisation de l'informatique. Vous repartirez avec « le plein » de logiciels libres, fiables, évolutifs, performants et gratuits.

    C'est chaque samedi matin au Centre d'Infos Jeunes à la ferme Dupire, 80 rue Yves Decugis à Villeneuve d'Ascq (métro Triolo) de 9h00 à 12h00.

    Entrée Libre. Tout Public.

    [QC Montréal] Journée portes ouvertes à DebConf17 - Le samedi 5 août 2017 de 09h00 à 18h30.

    Nous sommes ravis de pouvoir announcer que l'horaire de la Journée Portes Ouvertes de la DebConf17 est maintenant disponible à https://debconf17.debconf.org/schedule/open-day/
    Comme exemples d'activités planifiées pour la journée, citons, entre autres:
    A Newbie's Newbie Guide to Debian

    [FR Valenciennes] Permanence ValLibre - Le samedi 5 août 2017 de 09h30 à 12h00.

    Permanence assistance informatique.

    Dépannage petits bobos informatiques.

    Initiation à l'informatique libre.

    Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

    Si besoin particulier, la prise de rendez-vous est fortement conseillée.

    Téléphone accueil MQCV : 03 27 22 43 90

    [FR La Couronne] Permanence - accueil public - Le samedi 5 août 2017 de 10h00 à 13h00.

    Notre permanence d'accueil avec le sourire, le café et les gâteaux !

    Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

    Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

    Entrée Libre. Tout Public.

    [QC Montréal] DebConf17 - la conférence annuelle de Debian - Du dimanche 6 août 2017 à 09h00 au samedi 12 août 2017 à 17h00.

    DebConf est la conférence annuelle où les gens qui développent Debian et autres personnes intéressées se réunissent dans le but d'améliorer Debian.  Les DebConf précédentes ont accueilli des présentateurs et participants de partout dans le monde pour parler de Debian.  Par exemple, l'année passée, à Cape Town en Afrique du Sud, DebConf16 a vu venir du monde de 30 pays différents.
    Étant donné que le travail qui est fait sur Debian par ce monde divers est effectué en anglais, les événements DebConf ont lieu en anglais, aussi.  Cependant, pour l'Open Day, la journée portes-ouvertes qui précède DebConf17, nous encourageons les gens qui le veulent de présenter en français.
    Pour plus de renseignements par rapport à DebConf17, voir le site web à https://debconf17.debconf.org/

    Lire les commentaires

  • Troops, Trolls & Troublemakers : inventaire mondial de la manipulation organisée des réseaux sociaux (Journaux LinuxFR)

    Chères toutes, chers tous,

    Vous trouverez ci-dessous un lien vers le rapport universitaire :

    Samantha Bradshaw & Philip N. Howard, “Troops, Trolls and Troublemakers: A Global Inventory of Organized Social Media Manipulation.” Samuel Woolley and Philip N. Howard, Eds. Working Paper 2017.12. Oxford, UK: Project on Computational Propaganda. 37 pp.

    http://comprop.oii.ox.ac.uk/2017/07/17/troops-trolls-and-trouble-makers-a-global-inventory-of-organized-social-media-manipulation/

    ainsi qu'un lien vers une traduction et un avant-propos en français :

    https://paris-luttes.info/troops-trolls-troublemakers-8497

    J'ai recopié ci-dessous simplement la traduction du sommaire du rapport. Ça peut être intéressant d'avoir un débat ici ( d'autant plus que je ne doute pas qu'un certain nombre de lecteurs de linuxfr.org sont en capacité de créer du contenu de toute pièce via quelques techniques bien sophistiquées https://www.youtube.com/watch?v=no_elVGGgW8 )

    /////////////////////////////////////////////

    Les troupes cybernétiques sont des équipes gouvernementales, militaires, ou de partis politiques, engagées à manipuler l’opinion publique sur les réseaux sociaux. Dans ce document de travail, nous rapportons des organisations spécifiquement créées, souvent avec de l’argent public, pour suggérer au public ce qui serait dans son propre intérêt. Nous comparons ces organisations dans 28 pays et les catégorisons en fonction des types de messages, de "valences" et de stratégies de communication utilisés. Nous cataloguons leurs formes d’organisation et évaluons leurs capacités en termes de budgets et de personnel. Ce document de travail résume les résultats du premier inventaire complet des principales organisations vouées à la manipulation des réseaux sociaux.

    Nous constatons que les cyber-troupes sont un phénomène invasif et mondial. De nombreux pays utilisent un nombre important de personnes et de ressources pour gérer et manipuler l’opinion publique en ligne, ciblant parfois le public national, ciblant parfois les publics étrangers.

    Les premiers rapports concernant la manipulation organisée des réseaux sociaux ont émergé en 2010 et, depuis 2017, il existe des détails relatif à ces organisations dans 28 pays.

    En regardant de plus prés ces 28 pays, chaque régime autoritaire procède à des campagnes de médias sociaux ciblant ses propres populations, alors que seulement quelques d’entre-eux visent des publics étrangers. En revanche, presque toutes les démocraties de cet échantillon ont organisé des campagnes de médias sociaux ciblant les publics étrangers, quand les campagnes soutenues par les partis politiques ciblent les électeurs nationaux.

    Les régimes autoritaires ne sont ni les seuls ni les meilleurs dans la manipulation organisée des réseaux sociaux. Les premiers rapports sur l’implication du gouvernement dans la manipulation de l’opinion publique compromettent aussi les gouvernements démocratiques, et les nouvelles innovations technologiques de communication politique proviennent souvent de partis politiques et surviennent lors d’élections importantes.

    Au fil du temps, nous avons constaté que le mode principal d’organisation des cyber-troupes varie entre l’intégration d’unités militaires, qui expérimentent la manipulation de l’opinion publique via les réseaux sociaux, et des entreprises en stratégie de communication qui s’engagent de façon contractuelle avec les gouvernements pour diverses campagnes conçues pour les réseaux.

    Les réseaux sociaux et la démocratie.

    Les réseaux sociaux sont devenus des plate-formes précieuses pour la vie publique. C’est le principal moyen par lequel la jeunesse, à travers le monde, développe ses identités politiques et consomme l’information. Toutefois, les plate-formes de réseaux sociaux - comme Facebook et Twitter - sont également devenues des outils de contrôle social. Beaucoup de gouvernements dépensent maintenant des ressources importantes et emploient un grand nombre de personnes pour générer du contenu, des opinions directes et s’engager auprès du public étranger et national.

    Ce document de travail jette les bases d’une compréhension des tendances mondiales de l’utilisation organisée et coordonnée des médias sociaux pour manipuler l’opinion publique. Dans cet article, nous définissons les « cyber-troupes » comme des équipes gouvernementales, militaires ou de partis politiques, qui s’engagent à manipuler l’opinion publique sur les réseaux sociaux. Comme on sait peu de choses sur les différences de capacité, d’outils et de techniques de ces pratiques dans différents pays, nous avons mené une étude transnationale et comparative des troupes cybernétiques mondiales. En examinant les opérations effectuées sur les réseaux sociaux dans 25 pays, nous avons entrepris un inventaire des dépenses budgétaires, du personnel, du comportement organisationnel et des stratégies de communication pour analyser la taille, l’ampleur et la mesure dans laquelle différents types de régimes politiques déploient des cyber-troupes pour influencer et manipuler le public en ligne.

    En janvier 2015, l’armée britannique a annoncé que sa 77e Brigade se « concentrerait sur des opérations psychologiques non létales utilisant des réseaux sociaux comme Facebook et Twitter pour combattre les ennemis en prenant le contrôle du récit à l’ère de l’information » (Solon, 2015). La tâche principale de cette unité est de façonner le comportement public par l’utilisation de « récits dynamiques » pour lutter contre la propagande politique diffusée par les organisations terroristes.

    Le Royaume-Uni n’est pas le seul à répartir ses troupes et à financer l’influence du discours politique en ligne. Bien au contraire, cela fait partie d’un phénomène plus vaste dans lequel les gouvernements se tournent vers des plates-formes Internet pour exercer une influence sur les flux d’information et les canaux de communication pour façonner l’opinion publique.

    Nous comparons et résumons ce phénomène dans les 28 pays suivants :

    Argentine, Azerbaïdjan, Australie, Bahreïn, Brésil, Chine, République tchèque, Équateur, Allemagne, Inde, Iran, Israël, Mexique, Corée du Nord, Philippines, Pologne, Russie, Arabie Saoudite, Serbie, Corée du Sud, Syrie, Taïwan, Turquie, Ukraine, Royaume-Uni, États-Unis, Venezuela et Vietnam.

    Lire les commentaires

  • [Btrfs et openSUSE] Épisode 0 : l'ex-fs du futur (Journaux LinuxFR)

    Sommaire

    Je suis…

    Indice chez vous

    … un système de fichiers, encore considéré par beaucoup comme expérimental dix ans après le début de mon développement, Red Hat m'a déprécié tout récemment, une seule distribution – openSUSE – a osé me placer comme fs par défaut mais ses utilisateurs me rejettent et me préfèrent ext4, je suis, je suis ?

    - …
    - Btrfs !

    Présenté comme ça, ça ne donne pas très envie. Mais, pas de bol, c'est pourtant ce truc qui m'intéresse en ce moment et c'est ce dont je vais vous parler maintenant.

    Voici donc l'épisode 0 de « Btrfs et openSUSE », une série de journaux sur le système de fichiers Btrfs, basée sur ma propre expérience d'utilisateur d'openSUSE. Ce qui, je vous l'accorde, n'est pas très rassurant :-) Dans cette série, il y aura :

    • des généralités sur Btrfs
    • des noms qui pètent : sous-volumes, snapshots, rollbacks
    • du snapper
    • du grub
    • de la mise à jour incrémentale
    • des quotas
    • de la maintenance
    • des trucs spécifiques à openSUSE
    • des tentatives désespérées pour rester applicable à d'autres distributions
    • des erreurs (pas taper)
    • des bugs
    • des cris
    • des larmes
    • et bien plus ! ou bien moins

    Btrfs is hard

    Btrfs : l'ex-fs du futur

    Juste pour vous résumer rapidement ce qu'est Btrfs – du moins ce que j'en comprends.

    tl;dr - Btrfs est un système de fichiers basé sur un arbre B et la technique du CoW ; il offre des fonctionnalités nouvelles (comparé à notre bon vieux ext4).

    Arbre B

    Je vous invite à lire son article sur Wikipédia. En gros, c'est simplement un arbre binaire de recherche avec des nœuds parents qui peuvent avoir plus de deux nœuds enfants.

    Voici un joli schéma.

    schéma
    (r = racine, k = clé, c = enfant)

    Je vous avais dit qu'il était beau !

    Bon, vous allez être déçu – ou pas : je ne vous en dirai pas plus. Je ne vous parlerai pas non plus de son implémentation dans Btrfs. Parce que je n'y connais rien, certes… J'ai quand même pensé à vous et j'ai mis des liens plus bas qui pourront assouvir votre soif de connaissance ;-)

    Avantage : certaines opérations - dont la vérification du système de fichiers - sont rapides.

    Inconvénient : il faut équilibrer l'arbre régulièrement (maintenance). FAQ btrfs sur l'équilibrage

    CoW : Copy-on-Write

            ______________________________
           /  ____________                \
           | < cowception >               |
           |  ------------                |
           |         \   ^__^             |
           |          \  (oo)\_______     |
           |             (__)\       )\/\ |
           |                 ||----w |    |
           |                 ||     ||    |
           \                              /
            ------------------------------
                                \   ^__^
                                 \  (oo)\_______
                                    (__)\       )\/\
                                        ||----w |
                                        ||     ||
    
    

    Qu'est-ce don' ?

    Quand on crée de nouvelles données, on les écrit sur un espace libre et on marque les métadonnées comme étant du CoW.

    Quand veut modifier les données :

    1. On voit dans les métadonnées que c'est du CoW
    2. Au lieu d'écraser directement les données qui diffèrent, on les écrit sur de l'espace libre
    3. On met à jour les métadonnées pour pointer vers les nouvelles données

    Lazy copy

    Le Copy-on-Write, c'est pratique pour faire de la copie paresseuse.

    Cela consiste à ne pas vraiment copier une donnée quand on nous le demande, mais uniquement de créer des métadonnées qui pointeront vers la donnée originale. On n'écrit une donnée que quand l'original ou la pseudo-copie commence à bouger.

    Exemple de code C++

    Exemple honteusement pompé sur Wikipédia :

    std::string x("Hello");
    std::string y = x;  // x et y utilisent le même tampon
    y += ", World!";    // maintenant y utilise un tampon différent
                        // x continue à utiliser le même buffer
    Exemple avec Btrfs

    Exemple honteusement inspiré d'un topic sur StackExchange.

    Créons un fichier x et une copie paresseuse y via cp --reflink :

    ~# yes "hello" | head -n 1000 > x
    ~# cp --reflink x y
    ~# ls -i x y
    273 x  275 y # ce sont les numéros d'inode
    ~# btrfs inspect-internal dump-tree /dev/vdc1
    []
        # Notre x
        item 4 key (273 INODE_ITEM 0) itemoff 15889 itemsize 160
            inode generation 28 transid 28 size 6000 nbytes 8192
            block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
            sequence 0 flags 0x8(none)
            atime 1502314234.215991766 (2017-08-09 23:30:34)
            ctime 1502314234.219991832 (2017-08-09 23:30:34)
            mtime 1502314234.219991832 (2017-08-09 23:30:34)
            otime 1502314234.215991766 (2017-08-09 23:30:34)
        item 5 key (273 INODE_REF 256) itemoff 15878 itemsize 11
            inode ref index 18 namelen 1 name: x
        item 6 key (273 EXTENT_DATA 0) itemoff 15825 itemsize 53
            generation 28 type 1 (regular)
            extent data disk byte 12582912 nr 8192 # les données
            extent data offset 0 nr 8192 ram 8192  # sont là
            extent compression 0 (none)
    []
        # Le y a une tête similaire
        item 16 key (275 INODE_ITEM 0) itemoff 14520 itemsize 160
            inode generation 29 transid 29 size 6000 nbytes 8192
            block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
            sequence 0 flags 0x4(none)
            atime 1502314493.220242255 (2017-08-09 23:34:53)
            ctime 1502314493.220242255 (2017-08-09 23:34:53)
            mtime 1502314493.220242255 (2017-08-09 23:34:53)
            otime 1502314493.220242255 (2017-08-09 23:34:53)
        item 17 key (275 INODE_REF 256) itemoff 14509 itemsize 11
            inode ref index 20 namelen 1 name: y
        item 18 key (275 EXTENT_DATA 0) itemoff 14456 itemsize 53
            generation 28 type 1 (regular)
            extent data disk byte 12582912 nr 8192 # oh ! c'est la même
            extent data offset 0 nr 8192 ram 8192  # chose que x !
            extent compression 0 (none)
    []
        # Un EXTENT_ITEM nous confirme qu'il y a bien partage
        item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16201 itemsize 82
            extent refs 2 gen 28 flags DATA # Cet élément compte deux références
            extent data backref root 256 objectid 273 offset 0 count 1 # 273 = x
            extent data backref root 256 objectid 275 offset 0 count 1 # 275 = y
    []
    ~#

    On voit que x et y partagent les mêmes données.

    Maintenant, modifions légèrement y (rajoutons-lui des données) :

    ~# yes "world" | head -n 1000 >> y
    ~# btrfs inspect-internal dump-tree /dev/vdc1
    []
        # On a toujours notre EXTENT_ITEM qui référence les "hello" de x et y
        item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16201 itemsize 82
            extent refs 2 gen 28 flags DATA
            extent data backref root 256 objectid 273 offset 0 count 1 # x
            extent data backref root 256 objectid 275 offset 0 count 1 # y
    []
        # On a maintenant y qui commence à faire sa vie tout seul avec ses "world"
        item 2 key (12591104 EXTENT_ITEM 8192) itemoff 16124 itemsize 53
            extent refs 1 gen 34 flags DATA
            extent data backref root 256 objectid 275 offset 4096 count 1
    []
    ~# filefrag x y
    x: 1 extent found
    y: 2 extents found
    ~#

    x et y partagent toujours les mêmes données (les "hello"), mais y a un extent en plus pour les données qui lui sont propres (les "world").

    Maintenant créons un tout nouveau contenu pour y :

    ~# yes "bonjour, je suis monsieur dupont" | head -n 1000 > y
    ~# btrfs inspect-internal dump-tree /dev/vdc1
    []
        # C'est officiel : x est maintenant tout seul
        item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16230 itemsize 53
            extent refs 1 gen 28 flags DATA
            extent data backref root 256 objectid 273 offset 0 count 1 # 273 = x
    []
        # car y est parti
        item 2 key (12627968 EXTENT_ITEM 36864) itemoff 16153 itemsize 53
            extent refs 1 gen 43 flags DATA
            extent data backref root 256 objectid 275 offset 0 count 1 # 275 = y
    []
    ~#

    Avantages & inconvénients

    Plus ou moins.

    Avantages :

    • Permettre de réaliser facilement des snapshots.
    • Éviter la duplication de données.
    • Opérations transactionnelles (la mise à jour des métadonnées est censée être atomique).

    Inconvénients :

    • Ça fragmente.

    Solutions :

    • Se reposer sur les stratégies de Btrfs pour limiter la fragmentation.
    • Défragmenter manuellement (maintenance).
    • Désactiver le CoW pour les fichiers/dossiers/sous-volumes qui reçoivent beaucoup d'écritures aléatoires.

    Fonctionnalités

    Liste au père Noël.

    Maintenant qu'on a survolé les deux grands principes sur lesquels reposent Btrfs, arbre B et CoW, intéressons-nous aux fonctionnalités offertes.

    On ne va pas se casser la tête et on va piocher directement sur le wiki du projet :

    • Stockage de fichier basé extent
    • Taille maximale par fichier : 264 octets == 16 EiB (en pratique, la limite tombe à 8 EiB à cause du VFS de Linux)
    • Stockage efficace de petits fichiers
    • Stockage indexé efficace des répertoires
    • Allocation dynamique d'inodes
    • Sous-volumes (~ systèmes de fichiers internes)
    • Instantanés en lecture seule ou en lecture-écriture
    • Sommes de contrôle sur les données et les métadonnées (crc32c)
    • Compression (zlib et LZO)
    • Prise en charge de plusieurs périphériques (RAID) :
      • File Striping (RAID 0)
      • File Mirroring (RAID 1)
      • File Striping+Mirroring (RAID 1+0)
      • Single et Dual Parity (RAID 5 et 6) : expérimental
    • Pour les SSD : TRIM/Discard et optimisations
    • Sauvegarde incrémentale
    • Défragmentation à chaud
    • Vérification du système de fichiers à froid
    • Conversion de systèmes de fichiers ext3 et ext4
    • « Périphériques graines » (seed devices). Des sortes de modèles de système de fichiers, en lecture-seule, que l'on peut copier sur d'autres systèmes de fichiers, si j'ai bien compris.
    • Prise en charge de quotas par groupes de sous-volumes (qgroup)
    • Envoi/réception de changements d'un sous-volume
    • Déduplication après écriture (la déduplication à la volée est expérimentale)

    Les sujets en gras seront abordés dans les prochains épisodes de la série. Les sujets pas en gras seront peut-être abordés, mais rien n'est moins sûr.

    J'espère que cet épisode introductif vous a plu et je vous laisse sur quelques liens.

    That's all folks!

    Liens

    • Le wiki du projet Btrfs.
    • BTRFS: The Linux B-tree Filesystem (ACM Digital Library), O. Rodeh, C. Mason, J. Bacik, ACM Transactions on Storage, Août 2013. Lien vers le texte complet disponible depuis la page personnelle de O. Rodeh.
    • B-trees, Shadowing, and Clones (ACM Digital Library), O. Rodeh, ACM Transactions on Storage, 2008. Lien vers le texte complet disponible depuis la page personnelle de O. Rodeh.

    Lire les commentaires

  • Obnam est abandonné (Journaux LinuxFR)

    Bonsoir nal,

    Je viens d’apprendre que le mainteneur d'Obnam, le logiciel de backup (et de restore), a décidé d'abandonner son logiciel. Comme raisons, il cite le fait que ça ne l'amuse plus et que le code n'est pas maintenable comme il l'aurait dû. Il pense notamment que tout devrait être réécrit mais qu'il n'en a pas le courage.

    Il annonce quand même qu'il corrigerait tous les gros bugs ou failles de sécurités qui apparaîtraient d'ici la fin de l'année mais encourage tous les utilisateurs à migrer vers une autre solution (sans en citer). Notamment, les paquets ne seront pas présent dans la prochaine version de Debian.

    Lire les commentaires

  • Le programme de la LDAPCon 2017 est sorti ! (Dépêches LinuxFR)

    Nous sommes heureux de vous annoncer la sortie du programme des conférences de la LDAPCon 2017 qui aura lieu à Bruxelles les 19 et 20 octobre prochain.

    Cette conférence internationale sur LDAP et plus largement sur les questions de gestion des identités, d’authentification et d’habilitation, est l’occasion de rencontrer les acteurs les plus importants du domaine.

    Pour en savoir plus : https://ldapcon.org/2017/conference-program/ (mots‐clés : ReOpenLDAP, Sparrow, OpenLDAP, Apache Mavibot, PHP-LDAP, load balancing, replication, SSO, FusionDirectory, ForgeRock, etc.).

    De plus, la date de vente des tickets au tarif « inscription anticipée » de la LDAPCon 2017 a été étendue au 25 août ; vous pouvez encore acheter votre ticket Early Bird.

    Lire les commentaires

23:27 comment connecter un modem usb sous Mdx...
23:40 23:27 C'est simple, regarde bien a l'arriere de ton PC, il y a
une prise USB, t'as qu'a mettre le cable USB dedans. Bon ca
c'etait pour le connecter, maintenant pour qu'il soit reconnu sous
Mdx c'est autre chose...