Dépêches Linuxfr

Dépêches Linuxfr

  1. Comme ne le veut pas la tradition, pour la première fois de son histoire, darktable voit sa nouvelle version majeure 3.2, sortir quelques mois plus tôt, en plein été. Le confinement de cette année, déjà bien particulière, a entraîné un nombre record de contributions et d’améliorations sur darktable 3. Cerise sur le gâteau, une version majeure, 3.4, est toujours programmée pour Noël. 2020 sera donc la première année où l’équipe darktable aura le plaisir de vous proposer deux versions majeures.

    Avant d’entamer la lecture des nouveautés de cette version 3.2, pour ceux qui souhaitent se rafraîchir la mémoire, vous trouverez les nouveautés de darktable 3.0 (et en fin d’article la majorité des nouveautés des versions 3.0.1 et 3.0.2 ; la 3.0.2 n’apportant pas de nouveauté significative) sur l’article LinuxFr.org sorti à Noël.

    En raison de corrections de bogues de dernière minute, darktable 3.2 commencera directement en version 3.2.1.

      Sommaire

      Une interface affinée, dans les moindres détails : pour un look professionnel

      L’interface a connu un profond changement via la 3.0. L’équipe darktable a peaufiné ce travail jusque dans les moindres détails. Ainsi, darktable 3.2 vous apporte une interface et de nouveaux apports améliorant encore plus l’expérience utilisateur. Le style 3.0 se confirme et s’améliore… pour un look plus professionnel. Plusieurs développeurs ont travaillé d’arrache-pied pour vous apporter une interface soignée, à commencer par une réécriture complète de la table lumineuse qui s’accompagne également de belles améliorations de performance.

      Les améliorations de l’interface sont nombreuses, certaines seront détaillées plus bas, comme la refonte des préférences, les boutons dynamiques ou les infos-bulles, ou encore le plus gros morceau, à savoir le remaniement en profondeur de la table lumineuse.

      Ce travail sur l’interface a été l’occasion d’une restructuration complète du CSS, afin de le rendre plus clair à la lecture. Ainsi, il est plus aisé, à l’appui par ailleurs de plus de commentaires, de repérer la partie qu’on souhaite personnaliser sur l’interface. Vous pourrez d’autant mieux en saisir l’utilité en découvrant plus bas les nouvelles préférences proposées par darktable 3.2. Par ailleurs, cet important travail a permis d’aller encore plus loin dans l’objectif de rendre le plus possible l’interface personnalisable via le CSS.

      Enfin, la cohérence de l’interface entre les différents thèmes a également été drastiquement améliorée par ce travail d’optimisation du CSS. Il en est de même pour chaque élément de l’interface (exemple : les cases à cocher n’avaient pas, partout, le même aspect avant cette 3.2).

      Table lumineuse : un remaniement en profondeur sur tous les plans

      La table lumineuse est certainement la partie qui a le plus évoluée. Grâce, notamment, au travail majeur d’AlicVB (Aldric Renaudin), la table lumineuse est tout simplement plus performante. La vitesse d’affichage est notable, particulièrement via le mode table lumineuse zoomable et sur des configurations un peu plus anciennes. Le bandeau d’images bénéficie également d’une refonte et d’améliorations de performance.

      Dans cet article, pour des simplifications d’écriture, la refonte de la table lumineuse s’entend sur tous les modes liées à celle-ci, à savoir aussi bien le mode table lumineuse zoomable, le navigateur de fichier, le mode sélection ou encore l’aperçu. Toutes ces parties sont, de par cette refonte, déjà prêtes pour un usage via une résolution écran 8k.

      Aldric a également intégré de nouvelles options de surimpression des informations des vignettes, applicable indépendamment dans chacun des modes existants (table lumineuse zoomable, navigateur de fichier, sélection, aperçu et bandeau d’images). Désormais, en cliquant sur l’icône étoile en haut à droite, vous découvrirez un menu proposant ces nouvelles options d’affichage des vignettes, incluant sept modes d’affichage des informations (étoiles, icônes groupe, développement, labels couleurs, informations), dont un mode minimaliste sans distractions (« pas de surimpression »). Une option permet également d’afficher ou non les infos-bulles en survolant les vignettes. Le contenu de ces infos-bulles est personnalisable dans les préférences.
      Attention : laisser vide le champ gérant le contenu dans les préférences n’affichera rien, quelle que soit l’option sélectionnée dans le menu ci-dessous.

      Menu popover de sélection des modes de surimpression

      Les sept nouveaux modes de surimpression des vignettes, permettent d’aller, progressivement, d’un mode qui n’affiche que l’image, à un mode complet étendu. Voici un aperçu de certains modes, à commencer par une vue globale de l’interface peaufinée, en mode de surimpression n° 6 (ligne sélectionnée ci-dessus). Ce mode affiche donc en permanence certaines infos et les infos étendues (ici le nom du fichier de l’image et infos principales) au survol de la souris. À noter que les informations étendues affichées sont également paramétrables dans les préférences (onglet table lumineuse).

      Mode de surimpression permanent et étendu au survol de la souris

      Les deux premiers modes sont très proches. Par défaut, ils n’affichent aucune information autour des images. Seul le deuxième mode ajoutera l’affichage de certaines informations au survol de la souris. Voir ci-dessous :

      surimpression lors du survol souris

      Le mode le plus détaillé par défaut pour les vignettes, est le cinquième (surimpressions étendues permanentes) et ressemble à cela :

      surimpressions étendues permanentes

      Enfin, le septième et dernier mode a été particulièrement créé pour être adapté aux modes sélection et aperçu (et celui appliqué par défaut à ces modes). Ce mode permet de personnaliser la durée d’affichage, au survol par le curseur de l’image, fixé à 3s par défaut, peut être fixé à -1 pour un affichage permanent. Dans tous les cas, cet affichage ne se fait que si l’image est survolée par le curseur. Enfin, ce nouveau mode permet d’afficher le niveau de zoom de l’image dans les modes sélection et aperçu.

      Bloc de superposition en mode aperçu et sélection

      Les autres modes sont donc intermédiaires à ceux présentés ici et si vous voulez les découvrir, installez et ouvrez darktable 3.2. Rien ne vaut mieux que de les tester tous vous-même.

      Le bandeau d’images, qui peut être affiché via Ctrl + F en bas de certaines vues (chambre noire, modes sélection et aperçu, vue carte ou impression…) peut également être défini avec ces nouveaux modes d’affichage. Dans les vues où ce bandeau est affiché, c’est toujours via l’icône étoile que vous pourrez personnaliser l’affichage. Ainsi, par exemple, en chambre noire, l’icône étoile n’est utilisable que si le bandeau images est affiché et le menu n’est donc applicable que pour le bandeau. Autre exemple, en mode sélection, si le bandeau d’images est affiché, le menu « étoile » permettra donc de personnaliser, et la vue sélection, et l’affichage des vignettes du bandeau.

      À noter également que le bandeau d’images voit la visualisation de l’image sélectionnée (ou des images sélectionnées, en vue sélection), améliorée. Cet affichage était plutôt confus jusque-là. Désormais, la sélection est bien plus visible. Voyez plutôt :

      Sélection image du bandeau images

      Refonte des préférences : pour mieux s’y retrouver

      Avec l’introduction des nouvelles fonctionnalités depuis la 3.0, les préférences ont été réorganisées, augmentant le nombre d’onglets, afin d’offrir une lisibilité plus importante. Un des objectifs a par ailleurs été d’éviter les longs défilements pour accéder à une option. Ainsi, chaque onglet ne fait pas plus d’une page (sauf l’onglet pré-réglage). Chaque onglet a de plus un nom qui décrit clairement les options qui y sont paramétrables.

      Parce que des captures d’écran en parlent mieux, voici deux exemples d’onglet pour montrer cette refonte très efficace :

      Préférences darktable v3.2, onglet général

      Comme vous pouvez le voir sur cette image, de nouvelles options d’interface sont également apparues. Il est désormais possible, soit d’utiliser la police système (ou taille de police si le thème utilisé est un thème élégant), comme auparavant, soit de personnaliser la taille de la police et la mise à l’échelle pour les écrans à très haute résolution, directement depuis darktable. Une option demandée depuis un bon moment, enfin là !

      D’autres options permettant d’affiner aussi la taille de l’ensemble des éléments de l’interface, au bon vouloir de l’utilisateur. Attention à rester raisonnable sur ces options DPI, les options par défaut restent recommandées pour la majorité des utilisateurs.

      Enfin, elstoc, le développeur ayant fait cette refonte a intégré la possibilité, directement depuis les préférences, de personnaliser l’affichage de l’interface en intégrant vos propres personnalisations CSS, comme vous pouvez le voir sur la capture d’écran ci-dessus.

      Pour donner un autre exemple :

      Préférences darktable v3.2, onglet traitement

      Boutons dynamiques : selon vos actions

      Et darktable devient « vivant » !

      Une nouvelle fonction de boutons dynamiques a été intégrée, pour une meilleure expérience utilisateur. Elle est surtout visuelle mais aussi bien pratique. Mais de quoi il me parle l’auteur ici ? Eh bien, pour illustrer, rien de plus simple, ouvrez un module à droite de la table lumineuse, par exemple, images sélectionnées. Selon la position du curseur et la sélection faite (ou pas de sélection), vous verrez que certains boutons deviennent cliquables et d’autres non.

      Cette fonction active ou désactive les boutons, selon qu’ils sont utilisables ou non dans le contexte actuel.

      Un autre exemple, sélectionnez une image, ouvrez le module développement et cliquez sur copier. Tant que vous restez sur l’image sélectionnée, coller n’est pas utilisable (aucun intérêt de coller le développement d’une image sur elle-même). Sélectionnez maintenant une autre image et coller devient utilisable.

      Quelques autres détails

      Infos-bulles améliorées

      Les infos-bulles ont été améliorées. En effet, les infos-bulles ont parfois le défaut de s’afficher là où on ne veut pas. Malheureusement, ce problème ne peut pas être corrigé par l’équipe darktable puisque c’est un défaut inhérent à la bibliothèque graphique utilisée par darktable, à savoir GTK+. Pour contourner cela autant que possible, l’équipe darktable a intégré deux choses (après de longs débats) :

      • la possibilité d’afficher/masquer les infos-bulles à tout moment via un simple raccourci : Maj + T ;
      • un affichage des infos-bulles visuellement amélioré (légèrement).

      Un nouveau type d’infos-bulles fait également son apparition, utilisé principalement en chambre noire. Elles apparaissent en haut de l’image et permettent de rendre visible quelques informations essentielles comme, par exemple, le réglage d’opacité d’un masque ou encore l’ajustement d’exposition… Afficher ou désactiver les infos-bulles est également confirmé par un message via ce nouveau type d’info-bulle.

      Info-bulle

      Une nouvelle ligne de comparaison d’instantanés et la coloration de l’affichage sur image

      darktable 3.2 apporte aussi quelques améliorations visuelles sur l’image en chambre noire. La ligne de comparaison d’un instantané avec la ligne d’historique comparée est plus visible, intégrant un repère visuel de l’instantané sélectionné (une flèche avec le symbole S pour snapshot).

      Vous trouverez également une nouvelle option en bas à droite, via une icône quadrillée rouge et verte, permettant de choisir la couleur d’affichage de cette ligne d’instantanée ainsi que tout élément visuel qui s’afficherait sur l’image, comme, par exemple, les éléments de sélection de masque dessiné. Six couleurs sont disponibles (gris, rouge, vert, jaune, cyan et magenta). Il est aussi possible de modifier directement la couleur de ces éléments via le raccourci Ctrl + O (la lettre), jusqu’à la couleur adaptée. La couleur change instantanément et est confirmée via le nouveau type d’info-bulle qui s’affiche en haut de l’image.

      Voir ci-dessous un exemple de la nouvelle ligne de comparaison d’instantané en rouge et l’icône de sélection de couleur entourée en rouge.

      instantané et option couleur

      Changements mineurs sur l’interaction utilisateur

      Tous ces changements entraînent aussi quelques modifications d’usage des raccourcis. Tout d’abord, la sélection d’image via le bandeau d’images en chambre noire, change. Désormais, un simple clic permet de changer l’image à traiter (et non plus un double-clic).

      La sélection d’images dans le bandeau d’images, dans les autres vues, évolue également afin d’éviter la modification involontaire de cette sélection. Ainsi, pour ajouter d’autres images à la sélection, utiliser avec le clic, les raccourcis Ctrl et Maj selon que vous souhaitez ajouter une image, ou plusieurs. Enfin, pour faire une nouvelle sélection, commencer par sélectionner la première image via Alt + clic.

      La gestion de l’affichage des panneaux évolue. Il est désormais possible de modifier l’affichage des panneaux du haut (en-tête et barre d’infos) et de même pour le bas avec une seule combinaison de touches. Par défaut, les raccourcis de la 3.0.x sont désactivés (Maj + Ctrl + T et Maj + Ctrl + B) mais peuvent être redéfinis dans les préférences.

      Mais encore

      Plusieurs icônes ont été redessinées, des quatre icônes en haut à droite (groupe, étoile, aide et préférences) en passant par les icônes de masques. Ce travail permet un bien meilleur affichage, particulièrement sur les écrans HiDPI (haute résolution) sous Windows et donc une meilleure cohérence d’affichage selon le type d’écran (LoDPI (basse résolution) ou HiDPI (haute résolution)), quelle que soit la taille des icônes.

      Toutes les pipettes ont été retravaillées pour un comportement global et un affichage plus homogène dans toute l’interface. Ce travail ajoute également une fonctionnalité de redimensionnement des zones définies par une pipette.

      L’interface du sélectionneur de fichiers a également été revue.

      La barre de progression d’export et d’impression a été visuellement revue pour une intégration plus fine à l’interface.

      En chambre noire, le module actif est signalé par un nouvel effet visuel sur l’icône de statut et le titre du module : voir la capture d’écran de filmique v4, dans la présentation de cette nouvelle version, plus bas dans l’article.

      La liste de résultats de recherche de localisation en vue carte a enfin un aspect convenable et plus lisible.

      Toutes les barres de réglages ont été affinées : les barres sont plus fines et les curseurs de contrôle plus visibles.

      Et quelques autres petits détails un peu partout.

      Gestion du patrimoine numérique

      Éditeur de métadonnées et mots-clés évoluent

      Les évolutions ne sont pas énormes mais plus que bienvenues.

      L’éditeur de métadonnées

      Jusque-là, l’éditeur comportait cinq champs, il en compte désormais deux de plus : un champ « notes », pour ajouter des notes ; et un champ « nom de version » pour, par exemple, personnaliser le nom de différentes versions d’une même image. Ces nouveaux champs ont bien entendu été intégrés aux options d’importation. Ces options d’importation ont, par la même occasion, été harmonisées entre les possibilités d’import de darktable (et chaque champ peut directement être activé ou non à l’import).

      Tous les champs de l’éditeur sont enfin multi-lignes. Il suffit d’appuyer sur Ctrl + entrée pour ajouter une ligne à un champ (appuyer sur entrée vous amène au champ suivant en enregistrant le champ précédemment complété). De ce fait, les champs peuvent également être agrandis avec Ctrl + défilement.

      En ouvrant ce nouvel éditeur, vous constaterez également l’apparition d’une icône de préférence. Pour chaque champ de l’éditeur, vous pouvez décider de le cacher de l’éditeur ou de le rendre privé (non exportable).

      Les mots-clés

      darktable 3.2 améliore un peu plus la gestion des mots-clés. Via darktable 3.0.2, il n’était pas toujours possible d’ajouter un mot-clé à un parent existant. C’est désormais possible systématiquement en améliorant la gestion des mots-clés virtuels (non utilisés). Ces derniers s’affichent en italiques désormais.

      La création de mots-clés fonctionne maintenant sans image sélectionnée. Il est possible de créer une balise sur un nœud virtuel, d’insérer un caractère pipe | dans la balise de création. L’affichage de l’arbre montre les balises nouvellement créées.

      Mais surtout, un nettoyage important a été fait, résolvant quelques bugs. Par exemple, la mise à jour d’un mot-clé pouvait nécessiter le redémarrage de darktable pour être prise en compte ; ce n’est plus nécessaire. En bref, darktable 3.0 a initié un nouveau module mots-clés, darktable 3.2 l’affine et le finalise.

      De nouveaux filtres de collection

      Sept nouveaux filtres s’ajoutent aux nombreux déjà existants. darktable est déjà très riche en filtres sur les métadonnées des photos (données EXIF et données IPTC/XMP). En revanche, très peu de filtres existaient sur les divers événements ou traitements propres à darktable. Vous connaissiez déjà les filtres pellicule, mot-clé et copie locale. La version 3.2 ajoute maintenant les nouveaux filtres suivants : historique, module, ordre des modules, date importation, date traitement, date exportation et date impression. Voici une description rapide du rôle de ces nouveaux filtres.

      • historique - permet de sélectionner les photos développées ou les photos non développées (cela inclut les photos avec pré-réglages automatique).
      • module - permet de sélectionner les photos dont la pile de développement contient un module précis. Tous les modules utilisés au moins une fois sont présentés.
      • ordre des modules - permet de sélectionner les photos traitées avec un ordre de modules précis. Tous les ordres de modules existants sont affichés.
      • date importation - permet de sélectionner les photos importées à un horodatage précis (horodatage = date et heure). Tous les horodatages sont présentés.
      • date traitement - permet de sélectionner les photos traitées à un horodatage précis. Tous les horodatages sont présentés.
      • date exportation - permet de sélectionner les photos exportées à un horodatage précis. Tous les horodatages sont présentés.
      • date impression - permet de sélectionner les photos imprimées à un horodatage précis. Tous les horodatages sont présentés.

      De nouvelles informations sur l’image

      Le module informations de l’image affiche également de nouvelles informations. Les quatre horodatages mentionnés ci-dessus : date importation, date traitement, date exportation et date impression, ainsi qu’une nouvelle information EXIF : le biais d’exposition.

      La fenêtre du module est plus petite, mais elle est maintenant scrollable et redimensionnable avec Ctrl + défilement.

      Un nouveau module : docteur néga

      Le module actuel d’inversion de négatifs argentiques possède un défaut majeur : il fonctionne obligatoirement sur le signal non-dématricé du capteur, si le négatif a été numérisé avec un appareil photo numérique, et donc obligatoirement avant le profil de couleur d’entrée, quoi qu’il arrive. Ceci implique deux problèmes insolubles :

      1. Si le fichier numérique provient d’un vrai scanner, et qu’il est encodé avec une fonction de transfert (le « gamma »), celui-ci n’est pas annulé avant l’inversion. Suivant le type de numérisation que vous travaillez (« RAW » en 16 bits linéaire d’un scanner de film spécialisé, ou scan JPEG 8 bits encodé en gamma d’un scanner grand public), vous n’aurez pas du tout le même comportement. Notez que si la numérisation est faite à partir d’un autre appareil, le signal est linéaire, donc le problème ne se pose pas ici.
      2. On inverse la couleur avant de corriger l’espace de couleur du scanner ou de l’appareil numérique, ce qui fait que les profils de couleurs deviennent alors faux (il faudrait les inverser eux aussi), et qu’on ne peut pas soustraire proprement la déviation colorimétrique (inévitable) du capteur utilisé pour la numérisation.

      Il s’ensuit donc de fastidieuses séances de rattrapage de couleur, utilisant différents modules pour rattraper à la main ce qui aurait dû être fait automatiquement par le profil de couleur d’entrée s’il avait été appliqué au bon moment, c’est-à-dire avant l’inversion des couleurs du négatif.

      Docteur néga règle ça, et bien d’avantage, en se basant sur le système de sensitométrie Kodak Cineon, développé dans les années 1990 pour numériser les bobines de films au cinéma.

      Depuis l’avènement de la photo numérique, beaucoup de photographes argentiques aimeraient bien retrouver leurs anciennes photos dans leur flux de travail numérique. Plusieurs méthodes existent :

      • Les faire numériser par un professionnel mais, pour avoir une bonne résolution, cela coûte relativement cher.
      • Les numériser soi-même avec un scanner de films : les scanners bas de gamme ne numérisent pas à plus de 10 Mpx et généralement ne proposent que le format JPEG avec une bonne perte des possibilités de post-traitement ; les scanners haut de gamme proposent des résolutions un peu supérieures et le format Tiff en 16 bits meilleurs pour le post-traitement. Par contre, ils sont très lents pour obtenir des résolutions élevées et nécessitent d’utiliser son ordinateur : ces scanners proposent d’inverser directement les négatifs à partir de leur logiciel.

      Et pourquoi ne pas utiliser son APN avec un système de prise de vue macro pour reprographier ses négatifs argentiques et utiliser darktable pour faire ce travail ?

      Pour les besoins de l’article, un Lumix Gx8 (20 MP en RAW) avec un Leica Elmarit f:2.8 de 45mm macro a été utilisé pour digitaliser des photos argentiques : négatifs N/B et couleur et diapos N/B et couleur. Notez que :
      1. Les diapositives ne posent aucun problème de traitement avec darktable (pas besoin d’inversion).
      2. Les négatifs N/B sont relativement simples à inverser et la plupart des logiciels proposent cette inversion. Dans darktable, le module d’inversion classique est suffisant, mais docteur néga les gère également.
      3. Les négatifs couleur sont plus capricieux à cause de la couleur de base du film (orange) et de la balance des blancs. Pour les logiciels qui les gèrent, il faut un échantillon du film non exposé pour récupérer les valeurs RGB du filtre orangé pour les soustraire du négatif exposé.

      Docteur néga permet de traiter les négatifs N/B et couleur. Pour en tirer le meilleur résultat possible, il est important de garder une portion du film non-exposé autour de l’image (pour prélever le Dmin, voir plus bas) et de suivre une routine rigoureuse qui corrige la couleur en deux temps :

      1. on corrige d’abord la numérisation, c’est-à-dire les déviations colorimétriques apportées par l’appareil photo ou le scanner qui ont numérisé la pellicule,
      2. on corrige ensuite la pellicule proprement dite, c’est-à-dire les déviations colorimétriques apportées par la pellicule et par son éventuel vieillissement.

      La première étape s’effectue tôt dans le pipeline, en neutralisant la balance des blancs capteur, en ajustant l’exposition pour que l’histogramme de l’image occupe toute la plage 0–100 % sans valeurs négatives ni écrêtage, et en appliquant le profil de couleur d’entrée (ICC) du capteur utilisé.

      La deuxième étape s’effectue dans docteur néga :

      negadoctor

      Un sélecteur permet de passer au négatif N/B :

      sélecteur couleur - N/B

      En ouvrant un négatif argentique N/B :

      Ouverture N/B

      Vous n’avez qu’à cliquer sur « noir et blanc » à la place de « couleur » pour inverser le négatif, puis à régler les paramètres impérativement dans l’ordre dans lequel ils se trouvent dans l’interface :

      1. Pour le Dmin, sélectionnez avec la pipette une partie non exposée du film. Ceci récupère la densité minimale du film, correspondant aux zones où il est le plus transparent.
      2. Pour le Dmax, sélectionnez avec la pipette une zone de hautes lumières exemptée de poussières ou rayures. Ceci récupère la densité maximale du film, correspondant aux zones où il est le plus opaque.
      3. Pour le biais d’exposition du scanner, sélectionnez une zone censée être noire, ou même toute l’image. Il permet d’ajuster l’exposition du scanner de sorte que les noirs soient bien noirs.

      Inversion par défaut

      La teinte verte avant inversion, et indigo après inversion, vient de la balance des blancs de l’appareil photo, puisque la numérisation est faite en RGB. Il faudra la neutraliser avec la balance des blancs classique (avant docteur néga). Pour simuler un tirage des négatifs sur du papier à tons chauds, on peut utiliser l’onglet « corrections » de docteur néga, qui permet de teinter le tirage virtuel en utilisant les mêmes algorithmes que la balance couleur.

      Inversion tons chauds

      Quelques réglages, dans l’onglet « corrections », permettent de corriger la balance des blancs de l’émulsion ou de teinter le négatif à des fins créatives. Quelques remarques importantes :

      1. Si le film couleur a été exposé exactement à sa température couleur nominale (D50 pour un film « lumière du jour »), la correction de balance des blancs dans docteur néga devrait être inutile (les deux valeurs devraient être blanc pur), sous réserve que le capteur de numérisation ait été correctement corrigé au préalable (balance des blancs et profil d’entrée).
      2. Si le film couleur a été exposé à une température couleur différente de celle pour laquelle il a été équilibré, seule la correction de balance des blancs des hautes lumières est nécessaire. Cette correction était utilisée dans le système Kodak Cineon et simule une correction de l’émulsion au niveau du film lui-même.
      3. La dérive de couleurs des ombres est un ajout par rapport au Cineon classique, qui sert à récupérer des virages de couleur importants, notamment sur des négatifs endommagés qui ont été mal conservés. Pour l’utiliser, assurez-vous que le biais d’exposition du scan, dans l’onglet « film », soit non nul ou le réglage sera sans effet. Réglez alors la dérive de couleur des ombres en premier, en pipettant sur des noirs, puis la balance des blancs des hautes lumières en second, en pipettant dans les blancs (en suivant l’ordre de l’interface). La dérive de couleurs des ombres simule un étalonnage à la tireuse couleur à lumière additive.
      4. Les corrections de couleurs sont proposées aussi si vous travaillez des négatifs noir et blanc, pour vous permettre d’effectuer des virages de ton dans un espace logarithmique non inversé. Les mêmes algorithmes sont disponibles dans la balance couleur, mais travaillent dans un espace pseudo-linéaire et après inversion.
      5. Docteur néga utilise l’espace RVB de travail du pipeline, soit Rec 2020 linéaire par défaut. Si ceci fonctionne raisonnablement bien, l’espace de couleur réel du film n’est pas Rec 2020 et il peut être utile d’utiliser l’espace RGB réel du film pour travailler la couleur. Un développeur de Rawtherapee qui a travaillé sur un module d’inversion similaire a créé un profil de couleur RVB à partir de la sensibilité spectrale des émulsions Fuji et Kodak. Il suffit de le télécharger, de l’ajouter dans ~/.config/darktable/color/out, puis de choisir FilmNegRGB_650_550_460-elle-V4-g10.icc comme profil de travail dans le module profil de couleur d’entrée. Il n’est pas clair, à ce stade, si ce profil marche mieux en général que Rec2020 pour compenser la couleur, mais c’est une option.
      6. Des corrections de couleur définies dans un espace de travail deviendront fausses et devront être refaites si l’espace de couleur de travail est changé.

      Corrections pour obtenir les tons chauds

      L’onglet « impression » permet d’ajuster les paramètres de l’impression virtuelle en fonction du papier utilisé ou du système de reproduction. En effet, le négatif est un support transparent dont l’opacité (la densité) ne peut pas être nulle, à la fois physiquement (il suffit de regarder le film) mais aussi mathématiquement (on travaille en espace logarithmique, et le logarithme de 0 n’existe pas). C’est au moment de l’impression virtuelle qu’on recale le noir de la pellicule (le Dmin) avec la valeur RGB (0, 0, 0) afin d’ajuster l’image aux hypothèses de base du pipeline numérique.

      Le niveau de noir définit la correction de densité du noir et permet d’ancrer l’histogramme à gauche. Le grade correspond à la courbe de contraste du papier, aussi appelé dureté ou gamma (qui n’a rien à voir avec le gamma écran ou celui du profil ICC… simple). La brillance correspond à une compression des hautes lumières : 100 % signifie pas de compression ; plus on descend la valeur, plus on comprime les hautes lumières et on avale leur contraste local. Utilisé en combinaison avec l’ajustement d’exposition, ceci permet d’augmenter la luminosité générale de l’image sans écrêter les valeurs.

      Impression

      Pour le traitement d’un négatif couleur :

      docteur néga - couleur

      il suffit d’activer docteur néga (le filtre orangé va être neutralisé avec la valeur par défaut) :

      Inversion par défaut

      Et après avoir fait quelques corrections :

      Inversion corrigée

      Docteur néga est un de ces modules qui peut dérouter, car plusieurs paramètres vont avoir apparemment le même effet sur l’image finale. Par exemple, le Dmin, le biais d’exposition du scan, et la correction de densité du noir vont tous impacter la densité finale du noir, mais le Dmin travaille en linéaire avant inversion, le biais d’exposition en logarithme avant inversion, et la correction d’exposition en pseudo-gamma après inversion. Chacune de ces corrections du noir a une justification mathématique non-intuitive (liée aux fonctions utilisées, acceptant ou non des valeurs nulles) qu’une simple évaluation visuelle du résultat final ne fera pas apparaître.

      Il est donc important d’être méthodique dans l’utilisation pour éviter de perdre pied dans les nombreuses combinaisons de paramètres qui peuvent produire un résultat visuel similaire, en respectant l’ordre d’utilisation des réglages défini par l’interface (utilisez les onglets de gauche à droite, et de haut en bas). Retenez qu’on ne fait ici que simuler numériquement un processus d’impression en chambre noire, en corrigeant d’abord le scanner, puis le négatif, puis le tirage papier, en suivant la chaîne de production d’image. Chaque valeur, chaque opération, chaque étape est liée à une réalité physique mise en pratique sans forcément s’en rendre compte au laboratoire photo.

      Enfin, pour utiliser docteur néga, pensez à désactiver la courbe de base et filmique, puisqu’ils feraient doublon avec le film lui-même. Une fois toutes vos corrections de couleur effectuées, vous pourrez alors recadrer l’image pour supprimer le cadre non-exposé.

      Nouveaux flux de travail par défaut

      Le conflit de fonctionnalité entre filmique et la courbe de base, pour fournir la nécessaire transformation de tons du RVB linéaire vers le RVB écran, était jusqu’à présent géré via une option, dans les préférences, qui permettait d’activer par défaut la courbe de base, ou pas. Cependant, rien n’était disponible pour activer filmique automatiquement. C’est désormais réglé avec les flux de travail par défaut, disponibles dans les préférences à l’onglet traitement.

      Le flux « relatif à l’affichage », utilisé par défaut, active automatiquement la courbe de base et ordonne les modules dans le pipeline tels qu’ils étaient pour darktable 2.6 et précédents. À ce titre, il va appliquer la transformation non-linéaire au début du pipeline, et toute la retouche sera ensuite effectuée sur du RGB non-linéaire, comme le font la quasi-totalité des logiciels de retouche photo. Le seul mérite de ce flux de travail est qu’il correspond à ce à quoi beaucoup de photographes sont habitués, mais il va poser de nombreux problèmes de cohérence des couleurs et de crédibilité de certains filtres locaux (flou ou accentuation de netteté), notamment dans les scènes à large dynamique.

      Le flux « relatif à la scène » est pensé autour de filmique, pour offrir le même niveau de fonctionnalité que le flux « relatif à l’affichage ». Il consiste à ajouter, par défaut, +0,5 IL d’exposition (dans le module exposition), afin d’ajuster la luminosité générale et le gris moyen à une valeur similaire à celle utilisée par la plupart des JPEG retouchés par les boîtiers réflex.
      Nouveauté : le module exposition compensera également le biais d’exposition défini sur l’appareil (la correction d’EV du posemètre), couramment utilisé pour éviter l’écrêtage des hautes lumières, pour les photographes qui exposent à droite de l’histogramme. Cette fonctionnalité repose sur la lecture du champ EXIF ExposureBiasValue qui doit être correctement renseigné dans le fichier RAW par l’appareil photo pour qu’elle fonctionne. À noter : pour les RAW Fuji, il sera nécessaire d’ajouter encore +0,75 IL, soit une correction globale de +1,25 IL, pour compenser leur sous-exposition native.
      Ensuite, filmique est appliqué par défaut et ses paramètres de base tiennent compte de la correction globale d’exposition (incluant la correction de +0,5 IL du gris moyen et le biais d’exposition). Ceci permet donc d’avoir une base de travail raisonnablement proche du JPEG boîtier, directement en ouvrant le RAW dans darktable. Mais comme tout pré-réglage par défaut, il est pensé pour fonctionner correctement 80 % du temps, et des ajustements manuels additionnels seront nécessaires dans les 20 % restants ; en particulier, certains appareils appliquent une correction de +0,5 IL et d’autres de +1 IL, il est donc illusoire de chercher à satisfaire tout le monde.

      Rappelons ici que l’intérêt de filmique est d’appliquer une courbe de mappage des tonalités en fin de pipeline, permettant une retouche physiquement réaliste sur des valeurs RGB encodées linéairement auparavant, mais aussi de gérer la cohérence des couleurs à travers le mappage des tonalités, afin de préserver les teintes autant que possible et d’éviter les dépassements de gamut.

      Enfin, il est possible de n’utiliser aucun flux de travail pour désactiver tous les modules automatiques et gérer votre pipeline manuellement.

      L’option « Utiliser la courbe de base » dans les préférences est donc supprimée, et il vous faudra redéfinir manuellement le flux de travail que vous souhaitez utiliser après avoir installé darktable 3.2.

      Filmique évolue encore

      Filmique a été créé pour darktable 2.6 dans l’objectif d’améliorer la robustesse de la couleur dans des scènes à large plage dynamique, par rapport à la courbe de base. Il vise à effectuer un mappage des tonalités et du gamut entièrement paramétrable par l’utilisateur, en quelques réglages (au lieu d’une courbe à 6-12 points obtenue par rétro-ingénierie des JPEG constructeur), en s’inspirant de la sensibilité de la pellicule. Une fonctionnalité similaire existe dans tous les logiciels de traitement d’image, photo (courbe de contraste), vidéo (LUT de prévisualisation ou transformations d’affichage OpenColorIO), et rendu 3D (filmique dans Blender et OpenColorIO), car le redimensionnement de plage dynamique entre media de capture et d’affichage est une contrainte commune à tous les arts graphiques.

      Après avoir remis le nez dans des documentations de Kodak sur la sensitométrie argentique pour le module docteur néga, Aurélien a eu de nouvelles idées pour améliorer filmique RVB :

      1. Une nouvelle science de la couleur pour gérer la « désaturation » des luminances extrêmes de façon plus progressive, en évitant notamment les cassures de bleus sur les ciels contrastés. L’idée est de rendre le spectre lumineux plus « pointu » (proche d’une lumière laser monochromatique) pour « saturer » ou plus « plat » (proche de la lumière blanche) pour « désaturer ». On passe donc à une approche plus physique et métaphorique de la saturation, qui n’a plus de lien direct avec la perception colorée, mais qui a l’avantage de se contrôler de façon plus progressive.
      2. Une stratégie de désaturation différente, qui force le blanc et le noir à une saturation nulle peu importent les réglages, mais qui autorise à l’inverse à resaturer les tons moyens, afin de contre-balancer l’effet du mappage de tonalité. Rappelons que l’objectif de cette désaturation est d’effectuer un mappage de gamut basique visant à assurer que le maximum et le minimum de luminance (conventionnellement appelés blanc et noir) soient bien achromatiques (donc un blanc… non coloré). Il est, en effet, impossible de représenter une couleur saturée dont la luminance serait 0 % ou 100 %, dans aucun espace de couleur disponible. Une telle couleur serait écrêtée de façon plus ou moins aléatoire, et produirait notamment des couchers de soleil jaune urine (ce qui veut dire que le rouge est écrêté). Filmique produit donc une courbe de désaturation progressive qui assure une transition douce vers des couleurs achromatiques aux extrémités.
      3. Une reconstruction des hautes lumières basée sur l’exposition du blanc. En effet, en argentique couleur, en plus de désaturer les hautes lumières pour un mappage de gamut intégré, la chimie a tendance à flouter la transition entre les zones brûlées et les zones valides, par diffusion spatiale des espèces chimiques de la solution développante. Dans filmique v3, on manquait encore de douceur dans les transitions valide/écrêté, puisqu’il prenait en compte seulement la luminance des pixels, mais pas leur voisinage. Filmique v4 introduit donc une reconstruction des hautes lumières dans le domaine des ondelettes, donc multi-échelle, qui vise non seulement à adoucir les transitions valides/écrêté, mais aussi à essayer de récupérer les détails nets dans les canaux RVB non écrêtés (si possible), et à propager la couleur des zones voisines par diffusions successives (le processus est itératif et l’utilisateur peut régler le nombre d’itérations). L’utilisateur peut choisir les paramètres pour privilégier une reconstruction plus texturée (récupération des canaux non écrêtés) ou plus lisse (interpolation des hautes fréquences), plus colorée ou plus achromatique, et finalement plus nette (à la mode numérique) ou plus floue (comme le blooming argentique).
      4. Filmique permet d’ajouter du bruit, en utilisant différents profils statistiques (gaussien, poissonien ou uniforme), dans les hautes lumières écrêtées (voir l’onglet « options »). Ceci permet d’homogénéiser le bruit et de simuler de la texture dans les hautes lumières, afin d’éviter des hautes lumières reconstruites anormalement lisses par rapport au reste de l’image, tout ça dans le but de mieux fusionner les transitions visuelles entre hautes lumières écrêtées et reconstruites et tonalités valides. Ceci se rapproche encore du rendu de la pellicule argentique, qui présente du grain aussi dans les hautes lumières.
      5. Le réglage de gris de la scène disparaît par défaut, mais peut être optionnellement réactivé. Ceci répond à un besoin de simplification pour les utilisateurs suite à des incompréhensions de la différence entre l’exposition globale et le gris de la scène, sur le plan du résultat visuel (il n’y en a pas) et sur le plan de la chaîne de travail globale (attention, danger). La façon « canonique » d’utiliser filmique est donc d’utiliser le module exposition pour pré-ajuster l’exposition (la luminosité) générale de l’image, puis d’utiliser filmique seulement pour contraindre la plage dynamique de l’image dans la plage disponible du medium d’affichage. Dans cette configuration, la compression de plage dynamique se fait autour du gris moyen (conventionnellement fixé à 18 %), qui est la seule valeur non affectée par la transformation, préservant ainsi la luminosité globale. Ensuite, libre à vous de sortir de ces recommandations, mais il vous en coûtera une étape de plus pour achever de vous convaincre que ce n’est pas une bonne idée. Dans cette configuration, filmique n’affecte plus la luminosité générale, mais seulement la compression des luminosités extrêmes.
      6. Les réglages par défaut de filmique sont ajustés par le logiciel en fonction du biais d’exposition stocké dans les métadonnées de la photo. Ainsi, pour les photographes numériques qui ont l’habitude d’exposer à droite de l’histogramme, en forçant une correction d’exposition manuelle sur le boîtier, pour protéger les hautes lumières de l’écrêtage (ce qui est la seule bonne façon d’exposer en numérique, n’en déplaise aux puristes qui ne comprennent pas les différences technologiques entre semi-conducteur photo-électrique et ions halogénures d’argent photo sensibilisés) auront leur pipeline, relatif à la scène, réglé automatiquement pour eux (en première approximation, car filmique ne peut toujours pas deviner quelle est la valeur du gris moyen exact pour une scène donnée).

      Filmique v3 reste toujours accessible via le dernier onglet de filmique rvb. Tout comme il est possible de mettre à jour une image de filmique v3 vers v4 via le même onglet. Voici un aperçu du nouveau filmique et la sélection de la version visible via le menu science couleur :

      filmique rvb v4

      À noter : la reconstruction des hautes lumières est effectuée au moyen d’une décomposition en ondelettes par itération, ce qui induit une certaine pénalité de performance. Il est possible de désactiver complètement la reconstruction en réglant un seuil de hautes lumières très élevé, car le programme court-circuite la reconstruction si aucun pixel n’est détecté au-delà de ce seuil. Néanmoins, compte tenu de la difficulté de reconstruire des hautes lumières de façon convaincante, on peut considérer le compromis acceptable. Le réglage par défaut désactive presque cette reconstruction, améliorant les performances.

      Il est aussi possible de désactiver, dans certains cas, le module par défaut de reconstruction des hautes lumières si filmique reconstruit les hautes lumières, afin de préserver plus de détails. Pensez alors à piloter la désaturation des hautes lumières de façon à absorber les hautes lumières magenta que vous pourriez créer en désactivant ce module.

      Autres améliorations

      Cette 3.2, à l’instar de la 3.0, est riche de nouveautés et évolutions. Cet article n’a pas vocation à être exhaustif mais à présenter les évolutions principales et à vous permettre de les appréhender. Vous trouverez ci-dessous, pêle-mêle, quelques autres améliorations à connaître.

      Une meilleure gestion du pipeline de traitement de l’image

      Pour rappel, darktable 3.0 a instauré non seulement un nouvel ordre du pipeline de traitement mais également la possibilité de modifier l’ordre de ce pipeline en réordonnant les modules soi-même (fonction très avancée). De fait, certains utilisateurs se sont trouvés perdus et n’avaient pas de moyen de retrouver l’ordre par défaut de la 3.0 ou celui des versions 2.6.x et antérieures.

      Ainsi, un nouveau module permanent a été ajouté en chambre noire (en bas sur le panneau de droite) intitulé ordre des modules. Ce module permet de vérifier quel ordre du pipeline est actuellement appliqué à l’image : 3.0, originel (ordre par défaut antérieur à la 3.0) et personnalisé (ordre personnel que vous avez défini, même involontairement). Ce même module vous permet donc d’appliquer le pré-réglage 3.0 ou originel si besoin mais également d’enregistrer un ordre personnalisé. Ce sont ces ordres que vous pourrez retrouver dans les nouveaux filtres de collection présentés plus haut dans cet article.

      Améliorations de performance et importantes corrections de bugs

      Il a été remarqué que des bugs, parfois importants, sont présents dans la version 3.0.x (jusque dans la 3.0.2). Et tout particulièrement des bugs d’affichage d’images, notamment en cas de multiples instances (mais pas que). La plupart de ces bugs résultaient du nouvel ordre de traitement des images (pipeline), intégré en version 3.0. Une refonte complète du pipeline de traitement a été faite par Pascal Obry pour une gestion plus robuste du nouveau pipeline intégré en 3.0. Cette refonte rend ce dernier à la fois plus stable et plus performant.

      La détection de modification des images a été améliorée. Cela permet surtout d’éviter de recalculer l’affichage d’une image qui n’aurait pas été modifiée, par exemple en ayant été ouverte en chambre noire sans aucune modification. La modification des XMP et vignettes en est ainsi plus fiable et impactée seulement en cas de réelle modification.

      De nombreuses autres améliorations de performances ont été intégrées dans cette version 3.2, notamment dans certains modules. Ce travail est en cours puisque déjà plusieurs autres propositions d’améliorations de performances d’autres modules sont en cours pour intégration dans la future 3.4. Ainsi, la prochaine 3.4 semble se profiler sous de notables améliorations de performance.

      darktable 3.2 instaure également une option automatique (paramétrable dans les préférences) de maintenance de la base de données, permettant de conserver une base de données plus saine dans la durée.

      Enfin, avec les différentes améliorations de codes, beaucoup de parties similaires ont été unifiés, permettant par la suite une intégration plus rapide et facile de nouveaux modules ainsi qu’une bien meilleure cohérence sur les parties similaires (comme, par exemple, ce qui a été fait sur les pipettes, décrit plus haut).
      À également été ajouté des outils de tests permettant aux développeurs de tester plus aisément les nouveaux ajouts et la rétrocompatibilité et stabilité de vos traitements d’images, notamment en cas de réécriture d’un module en vue de meilleures performances.

      Et bien évidemment, de nombreux bugs ont été corrigés, faisant de cette 3.2 la version 3 la plus stable à ce jour. Et très nettement. Si vous utilisez déjà une version 3.0.x, je ne peux que vous recommander la mise à jour vers cette 3.2, ne serait-ce que pour sa stabilité supérieure.

      De nouvelles options dans les préférences

      En dehors des nouveaux flux de travail (workflows) présentés plus haut et des quelques préférences déjà présentées, vous trouverez quelques nouvelles options de préférences qui peuvent être bien utiles. Voici les principales :

      • En table lumineuse, vous pouvez trier les pellicules par numéro ou par dossier. Suite à la refonte de la table lumineuse, vous pouvez également définir les catégories de tailles (via séparateurs de catégories de tailles) différentes qui permettront notamment de définir un mode de surimpression différent selon la taille des vignettes. La taille se spécifie en pixels et la taille des vignettes s’affiche dans le menu de sélection du mode de surimpression présenté plus haut.

      • En chambre noire, il est désormais possible de réduire la résolution de la pré-visualisation, permettant de réduire la mobilisation du processeur utilisé et un gain possible de performances.
        Attention : comme indiqué dans l’info-bulle de cette option, cela peut réduire un peu la précision des masques guidés.

      • Dans l’onglet divers, des options pour gérer les raccourcis clavier en cas d’instances multiples.

      • L’onglet raccourcis voit, enfin, un champ de recherche permettant de plus rapidement trouver le raccourci que vous souhaitez personnaliser.

      Et enfin, un nouvel onglet d’options lua qui, à ce jour, ne comporte qu’une option permettant d’afficher/masquer l’installateur de scripts lua, présenté ci-dessous.

      À noter que les préférences modifiées sont enregistrées dynamiquement. La fermeture des préférences maintient donc les préférences modifiées.

      Installateur du gestionnaire de scripts Lua

      Bill Ferguson, qui s’occupe de la gestion des scripts Lua, avait fait un script Lua pour gérer (activer/désactiver) les scripts Lua beaucoup plus facile à utiliser que cette méthode : Installation scripts Lua. J’avais présenté cette nouvelle méthode : script-manager. Toutefois, l’installation du gestionnaire de scripts (script manager) Lua se faisait toujours manuellement.

      Tout ceci est désormais de l’histoire ancienne. L’auteur vient d’inclure, directement dans darktable, un installateur lua. Celui-ci peut être activé ou désactivé au premier démarrage et, si besoin, ultérieurement, dans les préférences. L’installateur télécharge les derniers scripts disponibles depuis le dépôt.

      Bien entendu, ceci n’est que pour ceux n’ayant pas déjà le script manager installé. Voici à quoi ressemble ce nouvel installateur :

      Installateur scripts lua

      Pour les non-anglophones, cet installateur vous propose simplement trois options :

      • Installer les scripts (install scripts), en incluant l’ajout du gestionnaire de scripts (script manager) dans darktable.
      • Me le rappeler plus tard (remind me later).
      • Ne plus le montrer (don’t show again).

      Une fois installé, le script manager apparaît donc à gauche sur la table lumineuse :
      script-manager

      À noter également que, malheureusement, les scripts lua ne sont pas traduisibles et sont donc intégralement en anglais.

      Un histogramme ajustable et un nouveau mode : parade RVB

      Deux nouveautés sur l’histogramme dans darktable 3.2. La première est l’ajustement en hauteur de la taille de l’histogramme. Cet ajustement se fait très simplement et de la même manière que plusieurs modules de la table lumineuse. Pointez le curseur sur l’histogramme puis Ctrl + défilement ; et ajustez sa hauteur comme vous le souhaitez.

      Un nouveau mode, parade RVB, fait son apparition et affiche des formes d’ondes qui représente les niveaux de chaque couche (rouge, vert et bleu). Ce mode permet donc de visualiser comment sont distribuées les composantes de couleur d’une partie de l’image.

      Ce mode s’affiche en sélectionnant l’affichage de l’histogramme en mode d’onde (via l’icône en haut à gauche sur l’histogramme) puis en changeant le mode d’onde via le bouton situé tout juste à droite vers ce mode Parade RVB.

      Mode parade RVB

      Ajoutez à tout cela, une réécriture importante du code de l’histogramme pour de meilleures performances.

      Masque dessiné : courber la forme gradient

      Lors de l’ajout d’un masque dessiné, il est désormais possible de courber la forme gradient (dégradé). Pour cela, pointer le curseur de la souris sur la barre du gradient et faire un défilement molette (ou pavé tactile) vers le haut ou le bas, selon la courbure souhaitée. Ctrl + défilement permet de définir l’opacité et Maj + défilement gère la dureté.

      Un historique amélioré

      Le fonctionnement de l’historique a été amélioré selon différentes remontées d’utilisateurs. Ainsi, lors de la compression de l’historique ou du chargement d’une nouvelle image, l’historique se comportera désormais de cette manière :

      • tout module actif et qui ne peut être désactivé, apparaît systématiquement en premier dans la pile historique ;
      • tout module qui est activé par défaut mais qui peut être désactivé, apparaît ensuite dans la pile historique ;
      • enfin, tous les modules activés par des préréglages ou à la suite d’un réglage de préférence (flux de travail ou netteté sélectionné dans les préférences) sont ajoutés.

      Mais encore

      • Ajout du support du format de fichier AVIF (>= 0.7). Cela requiert d’avoir la librairie libavif installée.
      • Ajout d’une option d’export en échelle de gris pour les images monochromes en TIFF.
      • L’export des masques est désormais possible sur les images au format TIFF.
      • Il est désormais possible d’utiliser plus de 500 images en vue capture, notamment pour les time-lapse.
      • L’application d’un style peut désormais aussi bien être appliqué en mode empiler (ajouté à l’historique existant de l’image) ou en mode écraser (en remplacement de l’historique existant de l’image). Ceci rend son usage cohérent avec le module développement.
      • Plusieurs styles peuvent être sélectionnés en même temps afin de pouvoir les gérer (les supprimer, exporter, etc.) plus rapidement.
      • L’orientation d’une image faite depuis la table lumineuse ne pouvait pas être annulée ou refaite. C’est désormais possible via les traditionnels raccourcis Ctrl + Z et Ctrl + Y.
      • En utilisant Ctrl + clic sur les formes de masques, il est possible de permettre la création en continue de plusieurs formes similaires.
      • Le rejet d’une image conserve en mémoire le nombre d’étoiles précédemment défini. En cas d’annulation du rejet, l’image retrouve ainsi directement le nombre d’étoiles défini.

      Cette liste n’est pas exhaustive. Quelques autres améliorations mineures peuvent être découvertes via les notes de sortie de darktable (release notes) ici : https://github.com/darktable-org/darktable/releases/tag/release-3.2.1

      Une future 3.4 en chemin

      Comme déjà précisé plus haut, une deuxième version majeure, 3.4, est prévue pour Noël. Cette version se profile déjà sous l’amélioration de performances. Elle devrait également voir l’arrivée d’un nouveau module de mixeur de canaux, plus performant, efficace et intégrant une balance des blancs moderne utilisant au choix la transformée de Bradford, l’espace CIECAT16, et munie d’une détection de balance des blancs par apprentissage machine supervisé.

      Une refonte visuelle du module retouche est également en cours ainsi que de la balance des blancs. Des discussions et propositions sont également en cours afin d’améliorer la gestion des modules en chambre noire (réorganisation des onglets, amélioration des pré-réglages, etc.).

      Et très certainement, d’autres surprises en vue.

      À propos de cet article

      Cet article a été coécrit par Nilvus, aurelienpierre, jpg54, hgmarty, jpv et Pascal Obry. Il est publié sous les termes de la licence Attribution 2.0 générique (CC BY 2.0) ou, selon, de la licence Creative Commons BY‑NC‑SA 3.0. Vous pouvez en trouver des traductions en anglais et en allemand.

      Et merci également aux lecteurs et correcteurs de passage.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • ./play.it est un logiciel libre qui automatise la construction de paquets natifs pour plusieurs familles de distributions à partir d’installateurs sans DRM pour une collection de jeux commerciaux. Les paquets ainsi générés s’installent ensuite en utilisant les outils standards fournis par la distribution (notamment APT, pacman et emerge).

      Une description plus complète est proposée par cette dépêche publiée en 2018 sur votre site préféré : ./play.it installe vos jeux sans prise de tête.

      Il s’est écoulé plus d’un an depuis la sortie de la version 2.11, qui remonte à janvier 2019, nous allons donc passer rapidement sur les ajouts de la 2.12 pour plutôt nous attarder sur les divers aspects de ./play.it qui nous ont occupé pendant tout ce temps, et dont le code lui‑même ne représente en fait qu’une petite partie.

      Sommaire

      Nouveautés de la version 2.12

      Même si nous n’allons pas en faire le cœur de cette dépêche, ce serait dommage de ne pas lister les nouveautés de cette nouvelle version.

      Comparée à nos mises à jour habituelles, celle‑ci est tout particulièrement massive, en bonne partie parce que l’intégration de nouveautés a tourné au ralenti pendant presque deux ans. On trouve donc dans cette mise à jour certaines contributions qui remontent à aussi loin que fin 2018 !

      Le journal des modifications apportées par cette version 2.12 se trouve sur notre forge, en anglais. Mais nous vous en avons préparé une traduction en français ici‑même :

      • nouvelles options :
        • --output-dir : définit le répertoire de destination des paquets générés,
        • --overwrite : remplace les paquets si ils existent déjà,
        • --icons : inclure ou non les icônes dans les paquets ;
      • modifications de la commande principale play.it :
        • retrait de $XDG_RUNTIME_DIR de la liste des chemins possibles pour le répertoire de travail temporaire,
        • évite la recherche de scripts dans des répertoires qui ne sont pas censés en contenir,
        • retrait de lʼidentification des archives par empreinte MD5 ;
      • modifications liées aux archives :
        • lors de lʼutilisation de unzip, seuls les fichiers utiles sont extraits,
        • ajout de la possibilité de passer des archives renommées,
        • ajout de la gestion des archives LHA ;
      • Modifications liées aux moteurs :
        • nouveau moteur : ResidualVM,
        • nouveau moteur : runtime Mono fourni par le système,
        • DOSBox : utilisation de $PLAYIT_DOSBOX_BINARY dans les lanceurs si cette variable est définie ;
      • modifications liées aux paquets :
        • ajout de la possibilité de définir des scripts de post‑installation et pré‑suppression par paquet via des variables dédiées,
        • Arch Linux : amélioration de la cohérence du nommage des paquets 32 bits ;
      • nouvelles fonctions internes :
        • version_target_is_older_than : vérifie si la version de la bibliothèque visée par le script courant est plus ancienne quʼune version donnée,
        • toupper : convertit les noms de fichiers dʼune arborescence en lettres capitales ;
      • nouveaux mots‑clés pour définir des dépendances :
        • libgdk_pixbuf-2.0.so.0,
        • libglib-2.0.so.0 / libgobject-2.0.so.0,
        • libmbedtls.so.12,
        • libpng16.so.16,
        • libopenal.so.1 (synonyme d’openal),
        • libSDL2-2.0.so.0 (synonyme de sdl2),
        • libturbojpeg.so.0,
        • libuv.so.1,
        • libvorbisfile.so.3 (synonyme de vorbis),
        • libz.so.1 ;
      • nettoyage et améliorations diverses :
        • réorganisation complète de tout le code lié à lʼaffichage de messages,
        • abandon des derniers chemins codés en dur, liés à la gestion des icônes et des lanceurs .desktop,
        • utilisation de valeurs par défaut différentes selon le système cible pour le chemin dʼinstallation des paquets,
        • activation forcée de lʼoption errexit lors de lʼinitialisation de la bibliothèque,
        • utilisation de dirname et basename au lieu des built‑in correspondant du shell.

      Migration du développement

      Historique

      Comme beaucoup de projets libres, le développement de ./play.it a débuté sur un coin de disque dur, ce qui a sans surprise conduit à la perte de tout historique antérieur au 30 mars 2016 (version 1.13.15) suite à une fausse manipulation sur lʼunique copie existante du code. La leçon immédiatement tirée de cette gaffe a été que ce qui nʼest pas partagé nʼest pas pérenne, et cʼest ce qui a motivé la mise en place dʼun dépôt Git public. La facilitation du travail collaboratif nʼa donc été quʼune conséquence de cette recherche de pérennité, et pas la raison originale du partage.

      Suite à ça, le développement de ./play.it a été hébergé successivement sur plusieurs forges mutualisées :

      • GitHub, quʼon ne présente plus, pas tant un choix réfléchi quʼun choix par défaut ;
      • une instance de Gogs maintenue par debian-fr.xyz, communauté dont le développeur principal de ./play.it était déjà très proche ;
      • Framagit, la fameuse instance de GitLab maintenue par Framasoft.

      Forge dédiée

      Au fil du temps, ./play.it a commencé à se diviser en plusieurs dépôts pour maintenir plus efficacement les différents aspects du projet. À ça se sont ajoutés des besoins particuliers au niveau des tests automatisés. Et, bien sûr, une furieuse envie de comprendre comment fonctionne une forge logicielle.

      Nous avons donc monté une forge sur un serveur dédié, grandement aidés de ce côté par le boulot de dingue de lʼéquipe qui maintient GitLab au sein de Debian. En retour, nous essayons à lʼoccasion de leur donner un coup de main.

      Hasard du calendrier, cette migration a eu lieu peu de temps avant lʼarticle « Déframasoftisons Internet ! » annonçant la fin programmée (mais pas pour tout de suite) de Framagit.

      Cette instance auto‑hébergée se trouvait sur un VPS loué chez Digital Ocean jusque mi‑juillet 2020, et a depuis migré sur un autre VPS loué cette fois‑ci chez Hetzner. Pour une machine virtuelle similaire et un niveau de service qui semble comparable, ce changement de prestataire permet de diviser par deux les coûts de l’hébergement de cette forge. Coût, pour rappel, payé par une personne seule, les dons financiers sont donc d’autant plus appréciés qu’ils sont très rares.

      À la grande surprise de notre administrateur système, cette dernière migration n’a pris qu’une petite poignée d’heures sans interruption de service visible par nos contributeurs.

      Accès à la forge

      Cette nouvelle forge est accessible sur forge.dotslashplay.it. Les inscriptions y sont ouvertes au public, en contrepartie nous vous demandons de ne pas en abuser, en particulier nous ne souhaitons pas héberger de projets sans rapport avec ./play.it. Des exceptions sont tout de même mises en place pour nos contributeurs réguliers, dont nous hébergeons certains projets personnels.

      Bref, si vous voulez profiter de cette forge pour héberger vos projets, le prérequis est dʼavoir fait avancer ./play.it dʼune manière ou dʼune autre.

      API

      La collection de jeux gérés grossissant sans cesse, nous avons lancé le développement d’une API publique permettant d’accéder à tout un tas d’informations liées à ./play.it.

      Cette API, qui n’est pas encore stabilisée, est simplement une interface à une base de données versionnée listant la totalités des scripts ./play.it, des archives gérées, et des jeux installables par ce biais. Des liens sont bien sûr faits entre ces éléments, ce qui permet de l’utiliser pour répondre à des requêtes du type : « Quels paquets doivent être disponibles sur mon système pour installer Cæsar Ⅲ ? » ou « Quels sont les jeux gratuits gérés via DOSBox ? ».

      À l’origine développée pour servir de support au nouveau site Web en cours de développement (on en cause un peu plus loin dans cette dépêche), cette API devrait faciliter le développement de divers outils autour de ./play.it. En particulier, celle‑ci sera utile à qui souhaiterait construire un gestionnaire de jeux vidéo complet (téléchargement, installation, lancement, etc.) utilisant ./play.it comme une de ses briques de base.

      Pour ceux qui sont curieux du côté technique, il s’agit d’une API basée sur Lumen effectuant des requêtes sur une base de données MariaDB, le tout auto‑hébergé sur une Debian Sid. Non seulement le code de l’API est versionné sur notre forge, mais aussi la structure et le contenu de la base de données, ce qui permettra à ceux qui le souhaitent de facilement en installer une version locale.

      Nouveau site Web

      Basé sur l’API que nous venons d’évoquer, un nouveau site Web est en cours de préparation et devrait à terme remplacer notreb site Web actuel basé sur DokuWiki. En effet, si l’absence de base de données et la structure en fichiers plats de DokuWiki semblait attirante quand ./play.it ne gérait encore qu’une poignée de jeux, cet avantage s’est transformé en inconvénient à mesure que la collection de jeux gérés par ./play.it a grossi.

      Nous parlerons probablement plus en détails de ce site Web lors de la prochaine dépêche pour la sortie de la version 2.13 de ./play.it, mais vous pouvez déjà jeter un œil sur une démo publique de la version en cours de développement sur notre forge.

      Si vous souhaitez donner un coup de main de ce côté, des tâches prioritaires ont été identifiées pour obtenir un nouveau site Web permettant de remplacer celui actuellement en activité. Et pour ceux qui s’intéressent à la technique, ce site Web est développé en PHP en se basant sur le cadriciel Laravel. La version en cours de développement est hébergée pour l’instant sur la même Debian Sid que l’API.

      GUI

      Une remarque assez régulière qui nous a été faite sur le projet est que, si lʼobjectif est de rendre lʼinstallation des jeux accessible à nʼimporte qui sans bagage technique particulier, devoir lancer des scripts dans le terminal reste quand même quelque chose dʼassez intimidant. Ce à quoi notre réponse a été jusque‑là que le projet nʼavait pas pour vocation à intégrer une interface graphique par lui‑même (principe KISS, encore et toujours), mais quʼil devrait, à terme, être assez facile de développer une interface graphique tierce pour se greffer dessus.
      Eh bien, il se trouve que cʼest désormais chose faite. À peu près vers le moment de parution de notre dernière dépêche, lʼun de nos contributeurs, se basant sur lʼAPI dont nous venons de parler, a développé un petit prototype qui nous a semblé suffisamment utilisable pour mériter un peu de mise en avant. :-)

      Concrètement, il sʼagit dʼun petit bout de code Python 3 (lʼIHM entièrement en shell POSIX, cʼest pour plus tard :-°), utilisant GTK 3 (et quand même un terminal VTE pour afficher le retour des commandes utilisées, mais lʼutilisateur nʼa jamais à aller taper quoi que ce soit dedans, en dehors éventuellement de son mot de passe root pour lʼinstallation des paquets). Cela a dʼailleurs permis de vérifier que, comme nous lʼavancions, ce serait assez simple, puisquʼun script de moins de 500 lignes de code (écrit rapidement en cours de week‑end) suffit à faire le travail !

      Bien entendu, ce projet d’interface graphique reste indépendant du projet principal, et maintenu dans un dépôt séparé. Il nous paraît intéressant de le mettre en avant pour faciliter lʼutilisation de ./play.it, mais ça nʼempêche absolument pas dʼautres projets du même genre de voir le jour, par exemple en se basant sur un autre langage ou sur une autre bibliothèque graphique (nous nʼavons, globalement, aucun attachement particulier à Python ni à GTK).

      Lʼutilisation de cette IHM se passe en trois étapes : tout dʼabord, une liste des jeux proposés est affichée, directement listée par notre API. Il suffit alors de choisir dans la liste (éventuellement à lʼaide de la barre de recherche) le jeu que lʼon veut installer. On passe alors sur une deuxième vue, qui affiche la liste des fichiers requis. Dans le cas où plusieurs alternatives sont possibles, lʼutilisateur choisit celle qui lʼintéresse le plus. Tous ces fichiers doivent se trouver dans un même répertoire, la barre dʼadresse en haut permettant de choisir lequel utiliser (cliquer sur le bouton dʼouverture en haut à droite permet dʼobtenir une fenêtre de navigation). Une fois que ceux‑ci sont présents (sʼils sont téléchargeables, ils seront automatiquement récupérés par le logiciel), on peut passer à la troisième étape, qui consiste simplement à regarder ./play.it faire son travail. :-) Ceci fait, un simple clic sur le bouton en bas à gauche permet un premier lancement du jeu (même si, à partir de là, celui‑ci est intégré dans votre système comme dʼhabitude, et donc il nʼy a plus besoin de passer par cet outil).

      Pour télécharger les fichiers manquants le cas échéant, lʼIHM utilise, selon ce qui est disponible sur le système, wget, curl ou aria2c (ce dernier présentant lʼavantage de gérer également les torrents), dont les retours seront affichés dans le terminal lors de la troisième phase, juste avant lʼexécution des scripts. Pour lʼélévation de droits nécessaire à lʼinstallation des paquets, sudo est préféré sʼil est présent (avec lʼoption permettant de lancer une application tierce pour demander le mot de passe, si la variable dʼenvironnement correspondante est définie, ce qui est sans doute plus convivial), sinon cʼest su qui sera utilisé.

      Naturellement, toute suggestion d'amélioration sera lue avec plaisir.

      Nouveaux jeux

      Évidemment, une dépêche comme celle‑ci ne serait pas complète sans la liste des jeux ajoutés à notre collection depuis la sortie de la version 2.11, la voici donc :

      • 7 Billion Humans
      • Agatha Christie: The ABC Murders
      • Age of Mythology Demo
      • Among the Sleep
      • Anomaly: Warzone Earth
      • Another Lost Phone: Lauraʼs Story
      • Assault Android Cactus
      • Baba Is You
      • Blade Runner
      • Bleed
      • Bleed 2
      • Blocks that matter (anciennement géré par ./play.it 1.x)
      • Butcher Demo
      • Capsized
      • Cayne
      • Cineris Somnia
      • Commandos 3: Destination Berlin
      • Diablo
      • Din’s Curse
      • Divine Divinity (anciennement géré par ./play.it 1.x)
      • Duet (anciennement géré par ./play.it 1.x)
      • Earthworm Jim
      • Edna & Harvey: The Breakout — Anniversary Edition
      • Element4l
      • Factorio — Demo
      • Finding Paradise
      • Firewatch
      • FlatOut 2
      • Forced
      • Forgotton Anne
      • Freelancer Demo
      • Frostpunk
      • Full Throttle Remastered
      • Giana Sisters: Twisted Dreams
      • Gibbous — A Cthulhu Adventure
      • Gorogoa
      • Indiana Jones and the Last Crusade
      • Into the Breach
      • Kerbal Space Program
      • LEGO Batman: The Videogame
      • Lego Harry Potter Years 1-4
      • Maniac Mansion
      • Metal Slug 3 (anciennement géré par ./play.it 1.x)
      • MIND: Path to thalamus
      • Minecraftn 4K
      • Minit
      • MonkeynIslandn4: Escape from Monkeynn Island
      • Multiwinia (anciennement géré par ./play.it 1.x)
      • Mushroom 11
      • Myst: Masterpiece Edition (anciennement géré par ./play.it 1.x)
      • Neverwinter Nights: Enhanced Edition
      • Overgrowth
      • Perimeter
      • Populous: Promised Lands (anciennement géré par ./play.it 1.x)
      • Populous 2 (anciennement géré par ./play.it 1.x)
      • Prison Architect
      • Q.U.B.E. 2
      • Quern — Undying Thoughts
      • Rayman Origins
      • Retro City Rampage (anciennement géré par ./play.it 1.x)
      • RiME
      • Satellite Reign (anciennement géré par ./play.it 1.x)
      • Star Wars: Knights of the Old Republic (anciennement géré par ./play.it 1.x)
      • Starship Titanic
      • SteamWorld Quest: Hand of Gilgamech
      • Stellaris
        • Ancient Relics Story Pack
        • Apocalypse
        • Arachnoid Portrait Pack
        • Distant Stars Story Pack
        • Federations
        • Horizon Signal
        • Humanoids Species Pack
        • Leviathans Story Pack
        • Lithoids Species Pack
        • Megacorp
        • Plantoids Species Pack
        • Synthetic Dawn Story Pack
        • Utopia
      • Strike Suit Zero
      • Sundered
      • Sunless Skies
        • Cyclopean Owl DLC
      • Symphony
      • Tangledeep
      • Tengami
      • Tetrobot and Co.
      • The Adventures of Shuggy
      • The Aquatic Adventure of the Last Human
      • The Count Lucanor
      • The First Tree
      • The Longing
      • The Pillars of the Earth
      • The Witcher (anciennement géré par ./play.it 1.x)
      • The Witcher 3: Wild Hunt
      • Tonight We Riot
      • Toren
      • Touhou Chireiden ~ Subterranean Animism — Demo
      • Touhou Hifuu Nightmare Diary ~ Violet Detector
      • Triple Triad Gold
      • Vambrace: Cold Soul
      • VVVVVV (anciennement géré par ./play.it 1.x)
      • War for the Overworld (le jeu de base était déjà géré, de nouvelles extensions ont été ajoutées) :
        • Heart of Gold
        • Seasonal Worker Skins
        • The Under Games
      • Warcraft: Orcs & Humans
      • Warhammer 40,000: Dawn of War — Winter Assault Demo
      • Warhammer 40,000: Gladius — Relics of War
      • Warlords Battlecry II (anciennement géré par ./play.it 1.x)
      • Wing Commander (anciennement géré par ./play.it 1.x)
      • Wing Commander II (anciennement géré par ./play.it 1.x)
      • Yooka Laylee
      • Zak McKracken and the Alien Mindbenders

      Si votre jeu favori n’est toujours pas inclus à la collection de ceux gérés par ./play.it, il est temps d’en faire la demande via l’espace dédié sur notre forge. Le seul critère d’acceptation est que ledit jeu existe dans une version sans gestion des droits numériques (DRM).

      Et ensuite ?

      Notre équipe est inépuisable, le boulot sur la future version 2.13 a donc déjà commencé… Quelques objectifs importants sont au programme pour cette prochaine version :

      Si vos attentes ne font pas partie de cette liste, n’hésitez pas à le signaler dans les commentaires de cette dépêche. ;)

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • Cette période estivale voit le retour en kiosque de vos magazines favoris, tout du moins la grande majorité. Et quoi de mieux que les vacances pour lire les numéros doubles et hors‑séries de l’été ? Voici donc un petit tour subjectif et parti{e,a}l de la presse papier, celle que vous pouvez encore trouver, post‑confinement, chez votre marchand de journaux.

      Image Une de Journal

      Les nouveautés de juillet et août 2020 :

      • GNU/Linux Magazine France no 239 fait de vous le plus grand manipulateur de vidéos via une IA ; U R FAKE NEWS!
      • GNU/Linux Magazine hors‑série no 109, dont le dossier est consacré à la programmation avec un moteur 3D ;
      • Planète Linux no 116 se dit que c’est encore la meilleure période pour jouer sous GNU/Linux ;
      • Hackable no 34 prépare l’hiver en plein été en « domotisant » votre chauffage ;
      • Linux Pratique no 120 résolument DevOps qui vous invite à vous tourner vers GitLab ;
      • Linux Pratique hors‑série no 47 supervise votre infrastructure ;
      • MISC magazine no 110 décrypte le Zero Trust ;
      • MISC hors‑série magazine no 21 sécurise les réseaux TCP/IP ; 
      • Ainsi que Linux Inside no 51 et son frère Linux Référence no 7 qui vous invitent à booster votre système d’exploitation, ainsi que les Linux Identity qui vous submergent d’Ubuntu.

      Quant au Virus Informatique, il a réussi sa campagne de financement participatif, lui permettant de sortir son numéro 44, que ce soit aux formats numériques (PDF et EPUB) et papier. Nous devrions avoir plus de nouvelles à la rentrée.

      Sommaire

      Les sommaires des numéros de juillet et août 2020

      Mosaïque des couvertures GLMF 239 Mosaïque des couvertures LP 120 Mosaïque des couvertures PL116 Mosaïque des couvertures MISC 110  
      Mosaïque des couvertures GLMF H‑S 109 Mosaïque des couvertures MISC H‑S 21 Mosaïque des couvertures Hackable34 Mosaïque des couvertures LP H‑S 47  

      GNU/Linux Magazine numéro 239

      Au sommaire de ce numéro de juillet et août 2020 :

      • Machine Learning sur des objets connectés avec TensorFlow Lite pour l’agriculture verticale ;
      • Meurtre à distance. Une enquête de J. S. Gramiet ;
      • Kernel & Bas niveau : les namespaces ou l’art de se démultiplier ;
      • L’exponentielle : sa vie, son œuvre ;
      • Créez une fake webcam pour modifier l’image de vos visioconférences ;
      • Évolutions de PHP et de son écosystème : impact sur la compatibilité.

      GNU/Linux Magazine hors‑série numéro 109

      Au sommaire de ce numéro de juillet et août 2020, la programmation avec un moteur 3D :

      • À nous, Markdown !
      • Hébergement privé de dépôts Git ;
      • Dossier : Programmez avec un moteur 3D :
        • À la découverte de Godot,
        • Premiers pas avec GDScript et Godot,
        • Interactions dans un environnement 3D,
        • Exporter une application Godot dans différents formats,
        • Godot pour coder des jeux, mais pas seulement !
      • Utilisez tout le potentiel de l’interface d’administration Django.

      Planète Linux numéro 116

      Au sommaire de ce numéro d’août et septembre 2020 :

      • Les meilleurs jeux Linux en 2020 ;
      • Linux Mint 20 aka Ulyana ;
      • Quelle distribution pour votre Raspberry Pi ;
      • L’apprentissage du terminal ;
      • Paquets binaires vs. paquets sources ;
      • Les bases de The GIMP ;
      • Quatre outils pour écrivains ;
      • Aller plus loin avec les processus ;
      • WSL2 et un éventuel retour à Windows en 2020.

      Linux Pratique numéro 120

      Au sommaire de ce numéro de juillet et août 2020 :

      • Gesturefy : utilisez la navigation « gestuelle » pour gagner en rapidité ;
      • Clippings : gagnez du temps avec votre presse‑papier intelligent ;
      • Communiquer en sécurité avec Jami ;
      • Crostini : débridez Chrome OS avec les applications Linux ;
      • L’authentification par mot de passe unique ;
      • Faites fonctionner plusieurs machines sur un même disque en réseau ;
      • Partagez vos fichiers volumineux facilement et de manière sécurisée avec Firefox Send ;
      • Utilisez GitLab pour la gestion globale de vos projets en équipe ;
      • Comment bien utiliser les cartes cognitives ;
      • Quelques gestes écoresponsables à adopter sur son lieu de travail et chez soi.

      Linux Pratique hors‑série numéro 47

      Au sommaire de ce numéro de juillet et août 2020 :

      • Tracez vos graphes en temps réel avec PlotJuggler ;
      • Neovim : dépoussiérez votre Vim ;
      • Dossier : Déployez votre système de supervision :
        • Introduction au dossier,
        • Installez Shinken, un outil de supervision modulaire et performant,
        • Basez votre supervision sur des logs de qualité avec Rsyslog,
        • Mettez en place une gestion efficace de vos journaux système avec Loki,
        • Collectez et exploitez les métriques de votre système avec Collectd,
        • Analysez, diagnostiquez et dépannez votre système avec Sysdig ;
      • Cluster et orchestration de conteneurs avec Docker swarm ;
      • Gérez vos contacts personnels avec Monica.

      MISC Magazine numéro 110

      Au sommaire de ce numéro de juillet et août 2020 :

      • De l’utilisation d’une bibliothèque à l’exécution d’un code arbitraire ;
      • Pré‑authentification Kerberos : de la découverte à l’exploitation offensive ;
      • Prise en main du machine learning avec Splunk ;
      • Dossier Zero Trust :
        • Introduction au dossier,
        • Introduction à Zero Trust,
        • Zero Trust : anti‑SOC, tu perds ton sang froid ?
        • Le principe de confiance minimale appliqué au Cloud Computing ;
      • Sécurité de l’implémentation standard de VXLAN ;
      • Anti‑leurrage et anti‑brouillage de GPS par réseau d’antennes ;
      • Contrôles de suivi de la conformité RGPD et d’atteinte d’objectifs définis dans la politique de protection de la vie privée.

      MISC Magazine hors‑série numéro 21

      Au sommaire de ce numéro de juillet et août 2020 :

      • Entretien avec Philippe Biondi, figure historique de la scène de la sécurité informatique francophone ;
      • Exploit : Stack Buffer Overflow ;
      • Dossier : Sécurité des réseaux TCP/IP :
        • Découverte et scan de réseaux,
        • Les enjeux de sécurité autour d’Ethernet,
        • Attaques par déni de service distribué (DDoS),
        • L’empoisonnement de cache DNS : toujours d’actualité ?
        • Sockets, paquets, captures réseau : quelques outils pour les manipuler ;
      • Rétro‑ingénierie : Méthodologie d’implémentation d’une architecture sur IDA PRO et Ghidra ;
      • Exploitations de collisions MD5.

      Hackable numéro 34

      Au sommaire de ce numéro de juillet et août 2020 :

      • Le Module du moment : afficheur matrice LED 8x32 ;
      • Pilotez de manière optimale vos afficheurs LED ;
      • Émulation d’un circuit comportant un processeur Atmel avec simavr ;
      • Domotique & Capteurs : Poêle à granulés connecté ;
      • Écran e‑paper NFC : une histoire d’exploration et de code ;
      • Développement ESP32 avec le nouveau ESP‑IDF 4.0 ;
      • Rétro‑Tech : Programmation avec le 6502 : découverte de la NES.

      Et les autres

      Vous pouvez aussi arriver à trouver en kiosque :

      • Linux Inside numéro 51 et Linux Référence numéro 7, tous deux chez le même éditeur, mais dont la forme nous laisse pour le moins dubitatif ;
      • et la cohorte des Linux Identity qui recycle ses anciens numéros avec ses habituelles déclinaisons Set (no 50 avec de vieilles Ubuntu en masse), Collection (no 46 avec de l’Ubuntu un peu plus récente et du Tails) et Starters (no 51 sur… une Ubuntu à jour : 20.04 !).

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • 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 dix événements (France : 9, Belgique : 1) est en seconde partie de dépêche.

      Sommaire

      [FR Paris] Introduction au développement web. - Le lundi 10 août 2020 de 15h00 à 19h00.

      Paris Web School présente : Introduction au développement web, le bootcamp !

      Les séances ont lieu une semaine deux, en ligne; la prochaine séance aura lieu lundi 10 août, de 15 à 19 heures.

      Les thèmes en lice sont :

      • Premiers pas dans le web : introduction au langage Html;
      • industrialiser la génération du code : le langage Php.

      Je vous invite à me faire connaitre votre choix à pariswebschool@doobee.fr !

      [FR Saint Etienne] Permanences GNU/Linux et Logiciels Libres - Le lundi 10 août 2020 de 19h00 à 23h00.

      Permanences Alolise

      Tous les lundis soir à partir de 19h00.

      Rencontrer les bénévoles, passer sous Linux, poser des questions sur le libre, les logiciels, l'hébergement…

      Pour passer votre ordinateur sous linux, nous vous invitons à nous prévenir avant votre passage.

      [FR Grenoble] Session Hack - Le mardi 11 août 2020 de 19h00 à 23h00.

      Séance du mardi soir au LOGal.

      C'est ouvert à tout le monde, vous êtes les bienvenu.e.s

       N'hésitez pas à passer nous voir pour rencontrer nos membres, découvrir leurs projets ou participer!

      [FR Nantes] Visioconférence Monnaie Libre - Le mardi 11 août 2020 de 19h30 à 21h00.

      Vous vous interrogez sur les produits que vous acheter : d'où ça vient, comment c'est fabriqué, est-ce équitable écologique?
      Vous posez vous les mêmes questions concernant la monnaie?

      Dans le cadre de la transition écologique, la monnaie joue un rôle majeur.
      La monnaie libre permet d'éviter l'accumulation, de garantir la valeur et
      de privilégier l'humain.
      Elle appartient à ses utilisateurs et non pas à une banque.
      Elle est créée par les utilisateurs et non par la dette.
      Elle participe pleinement à la phase de résilience qui va suivre les
      bouleversements économiques majeurs qui s'annoncent.
      Elle existe depuis 3 ans et ne nécessite aucun frais d'entrée ou de gestion.
      Ce n'est pas une monnaie locale bien qu'elle puisse être utilisée localement.
      Elle intègre un dividende universel attribué automatiquement chaque jour.

      C'est une autre façon de voir le revenu universel et c'est opérationnel dès aujourd'hui.

      À l'issue de la réunion vous aurez toutes les informations pour vous lancer.

      Pour rejoindre la réunion il faut suivre ce lien: Jitsi MonnaieLibreNantes    

      Pour toutes questions préalable voir forum.monnaie-libre.fr visio-conference-tout-les-mardi-soir

      La réunion commence à 19h30 mais on teste les connections à partir de 19h20. (privilégier le câble)

      Il n'y a pas vraiment de présentation, ces visioconférences sont faites pour faire connaissance (activez vos caméras), et répondre au questions, en préparation de rencontre réelles pour utiliser cette monnaie.

      Quelque vidéos de présentation sur youtube

      [BE Saint-Gilles] Info Linux - Atelier du Web - Le mercredi 12 août 2020 de 10h00 à 12h00.

      Longues vie aux Logiciels Libres !

      Article de Reporterre : "Microsoft envoie 500 millions d’ordinateurs à la poubelle"
      À lire sur : http://www.reporterre.net/spip.php?article5681

      C’est l'occasion de venir tester et essayer une distribution GNU/Linux, qui pourra remplacer facilement ce système d’exploitation Windows XP (c), avec tous les avantages lié au monde du "logiciel libre"…

      GNU/Linux et les logiciels libres : plus que des mots, venez découvrir et/ou faire installer de manière vivante ce qui va changer votre vision de l’informatique.

      Les mercredis de l’atelier du web, TOUS LES MERCREDI chaque mois (sauf les jours fériés, périodes de vacances scolaires)…

      Sauf en cas d'urgence tel que confinement
       de 10h00 à 12h00
       où : 37 rue du Fort - 1060 Saint-Gilles

      C’est l’occasion pour vous de venir découvrir l’informatique libre et gratuite.
      Principales questions, avec les logiciels libres :
      Peut-on ouvrir des fichiers Word (c), Excel(c) ou Powerpoint(c) ? Oui
      Y a-t-il un support linguistique ? Oui, il y a beaucoup de langues supportées (français, néerlandais, allemand, anglais, espagnol, italien, etc.)

      Pour information : les équivalences de logiciels tournant sur Windows(c) et GNU/Linux

      La permanence du MERCREDI est UNE ACTIVITÉ CONSACRÉE UNIQUEMENT À DE NOUVELLE INSTALLATION (sur PC portable)…
      Il est impératif avant l’installation d’une distribution Gnu/Linux d’effectuer une sauvegarde de TOUS le(s) disque(s) dur, « et QUE l’installation ait débuté avant 10h30 au plus tard ! »

      DÉSOLÉ, mais CETTE permanence de deux heures m’oblige à REFUSER TOUTES résolution de certains problèmes ou conseils techniques…
      En aucun cas une maintenance ne pourra être assurée ; le SAI (Service Après Installation), pour des conseils pratiques, mise à jour sur les distributions déjà installées, SEULES les LCP peuvent répondre à ces demandes spécifiques…

      Éventuellement le SUR RENDEZ-VOUS le JEUDI MATIN à l’atelier du web ou chez Oxfam-informatique le vendredi après-midi de 14h00 à 17h00 et réservé à ceux qui auront pris rendez-vous

      Contact : Jean-Paul Biérent (jpbxlug[arobase]gmail.com ou 0475/918.033 si absent sur le privé : 02/347.55.94 de 9h00 à 12h00 et 15h00 à 18h00.

      Une autre LCP est organisée par Oxfam-informatique. Le dernier jeudi de chaque mois de 17h30 à 20h00 "Oxfam Ixelles") 252, Chaussée d’Ixelles 1050 Ixelles (02/647.48.51)

      [FR Montrouge] OpenstreetMap réunion mensuelle - Le mercredi 12 août 2020 de 19h00 à 22h30.

      Tous les seconds jeudi du mois a lieu la rencontre mensuelle des contributeurs habitants Montrouge et alentours au Schmilblick à partir de 19h.

      Ce bar solidaire est situé au 94 avenue Henri Ginoux (station Vélib et parking vélo juste en face, bus 128 et 68 et métro Mairie de Montrouge à 4 min à pied).

      Cette rencontre permettra de discuter des projets en cours et d'envisager des projets locaux dont la coordination se déroule depuis plus d'un an sur la page Montrouge et sur la page de discussion associée.

      Comme toujours, les débutants et simples curieux sont les bienvenus.

      --

      Agenda des événements à venir : https://wiki.openstreetmap.org/wiki/Montrouge#Rencontres_locales

      Mailing-list OpenStreetMap Paris Sud : https://listes.openstreetmap.fr/wws/info/local-paris-sud (moins de 10 messages par mois)

      [FR Lyon] Hadoly: permanence du chaton Lyonnais - Le mercredi 12 août 2020 de 19h00 à 20h00.

      La permanence (mensuelle) d’Hadoly (Hébergeur Associatif Décentralisé et Ouvert à LYon), C.H.A.T.O.N.S. lyonnais, est l’occasion d’échanger avec les membres de l’asso sur les services et moyens mis à disposition des adhérents afin de se libérer des GAFAM tout en grignotant et en en buvant un coup (n’hésitez pas à apporter quelque chose).

      Nous partageons du mail, du cloud, et d’autres services, le tout basé exclusivement sur des logiciels libres avec le respect de la neutralité du net et de la vie privée.

      Et en plus l’hébergement est physiquement local!

      Adresse : 7 place Louis Chazette 69001 Lyon

      La prochaine permanence/réunion aura lieu virtuellement en visioconférence à l'adresse https://jitsi.hadoly.fr/permanence-hadoly

      Vérifiez que vous avez un micro correct et de préférence un casque ou des écouteurs pour éviter l'écho, sinon pensez à coupez votre micro (sur le site) lorsque vous ne parlez pas.

      [FR Sur la Toile] Réunion du groupe de travail Sensibilisation de l'April - Le jeudi 13 août 2020 de 17h15 à 19h30.

      Le groupe de travail Sensibilisation

      Le groupe de travail Sensibilisation de l'April a pour vocation de proposer des outils de communication permettant de sensibiliser le grand public aux logiciels libres et aux formats ouverts. Toute personne intéressée peut participer aux activités du groupe (membre de l'April ou pas).
      Plus d'informations sur le groupe Sensibilisation sur le site de l'April.

      La prochaine réunion du groupe de travail Sensibilisation aura lieu jeudi 13 août 2020, de 17 h 30 à 19 h 30 (accueil à partir de 17 h 15), en visioconférence. Il sera possible de rejoindre la réunion à tout moment. Ordre du jour: Nous continuerons à travailler sur les projets Quiz enjeux de l'informatique et Jeu du Gnou (voir plus bas).

      Pour tous les détails et vous inscrire à la réunion, rendez-vous sur le pad. Si vous prévoyez de rejoindre la réunion après 17 h 30, merci de préciser votre horaire d'arrivée en plus de votre nom/pseudo.

      Quiz enjeux de l'informatique

      C'est l'un des projets en cours du groupe de travail Sensibilisation. Les questions, du type QCM ou vrai/faux, sont au cœur de l'expérience de sensibilisation dans le Jeu du Gnou (voir ci-dessous). En même temps, elles constituent une ressource de sensibilisation à part entière et pourront être utilisées et partagées dans beaucoup de contextes différents (stands, ateliers, sites web, etc.).

      Le pad avec les questions déjà (ou presque) finalisées (à partir de la ligne 82).

      Le pad pour proposer de nouvelles questions.

      Jeu du Gnou

      Le Jeu du Gnou est l'un des projets en cours du groupe de travail Sensibilisation. Il s'agit d'un jeu de plateau coopératif et pédagogique dont le but est de sensibiliser le grand public aux enjeux de l'informatique (libertés vs servitudes, protections contre les dangers).

      On peut déjà jouer au Jeu du Gnou? Oui! Il est possible de télécharger les éléments graphiques de la version beta depuis le pad principal du jeu.

      Qu'est-ce qu'il reste à faire? Finaliser le livret accompagnant le jeu, réaliser le graphisme, rédiger de nouvelles questions.

      Comment contribuer? Tester le jeu, relire et rédiger les textes, proposer des images, sont autant d'actions possibles pour nous aider à faire avancer le projet. Sans oublier bien sûr la participation aux réunions! :-)

      Pour en savoir plus sur le Jeu du Gnou et sur comment contribuer, voir la page wiki du projet.

      [FR Mantes-la-Jolie] TSL Mantois - Le samedi 15 août 2020 de 14h00 à 18h00.

      Chaque troisième samedi du mois, l'espace culturel multimédia Le Chaplin à Mantes-la-Jolie ouvre ses portes tout l'après-midi et propose des ateliers d'émancipation numérique.
      Ça parle de logiciel libre, de protection de la vie privée, de neutralité du Net, d'auto-hébergement.

      L'entrée est libre et gratuite.

      Au programme:

      Install-party

      Venez avec votre vieil ordinateur pour lui redonner vie en installant GNU/Linux à la place de Windows.

      Café vie privée

      Posez vos questions pour découvrir différents moyens de protéger votre vie privée numérique.

      Atelier tails

      Transformez votre clef USB avec Tails, un outil facile à utiliser pour protéger sa vie privée même sur l'ordinateur de quelqu'un d'autre.

      La brique Internet

      Découvrez un petit boitier qui respecte la neutralité du Net et qui facilite l'auto-hébergement.

      [FR Paris] Apéro Parisien du Libre - Le samedi 15 août 2020 de 19h00 à 23h00.

      Tous les 15 du mois, Parinux vous convie à l'Apéro Parisien du Libre (APL). Cet événement informel et convivial réunit les personnes intéressées par le monde du Libre.

      Pour le 15 août, nous vous donnons rendez-vous au Comptoir du Poulet à partir de 19h pour échanger autour du Libre avec les bénévoles de l’association Parinux.

      Tou·te·s sont les bienvenu·e·s, qu'ils/elles soient membres ou non, que ce soit pour découvrir l'association, se renseigner sur ses activités, ou simplement partager un bon moment avec d'autres bénévoles du Libre !

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • La MétaSurface64 est un logiciel audio pour GNU/Linux. Elle reprend le concept de Metasurface d’AudioMulch et des pads matériels (comme le Novation Lauchpad ou le Presonus ATOM) qui permettent de contrôler des instruments externes ou des séquenceurs par des messages MIDI.

      La metaSurface, quant à elle, propose une fenêtre dans laquelle il est possible de choisir un pavage. Chaque pavé (polygone) dispose de ses propres paramètres (fichier audio entre autres) et il est possible d’associer une chaîne d’effets via des greffons contrôlés par OSC. Cette surface de contrôle de transformations continues du son en temps réel dispose à la fois de son propre générateur de boucles jusqu’à 64 voies et d’un moteur FX multi‑effets. Elle est destinée à la recherche et à la création d’objets audio pour la composition électroacoustique ou acousmatique.
      Ce logiciel est sous licence GPL v3. La dernière version pour GNU/Linux (et Windows) vient de sortir.

      MetaSurface64

      Chaque pavé de cette surface peut permettre de contrôler directement le gain et les greffons attachés. Il est possible également de contrôler les pistes et les greffons d’un séquenceur externe (Ardour ou Reaper). Pour ce faire, l’application utilise des modules contrôlables par OSC qui proviennent de la bibliothèque du langage FAUST qui est embarqué dans l’application. Il est également possible de disposer d’une entrée externe pour un pavé.

      DSP
      Il est proposé d’écrire et d’intégrer de nouveaux greffons en langage FAUST à la surface. Ce langage est intégré à la metaSurface via libfaust qui permet de disposer de toutes les fonctionnalités de ce langage. Vous pouvez également définir les contrôleurs pour des greffons externes incorporés à votre station audionumérique (DAW).

      Enfin, vous pouvez créer de nouveaux pavages pour votre surface. Les fichiers audio des pavés peuvent être multicanaux. La sortie de chaque pavé sur JACK se règle indépendamment et peut être monophonique ou multicanal.

      Pour installer cette application :

      git clone https://github.com/dblanchemain/metaSurface
      make metaSurface
      make install PREFIX=/usr/local
      

      Puis, pour GNU/Linux :

      ./metaSurface.sh
      

      La documentation est disponible sur blanchemain.info.

      Cette version 1.0 a été réalisée et testée sur Debian/LibraZik 2.

      Pour ce qui me concerne, je suis compositeur de musique électroacoustique et créateur de logiciels audio pour GNU/Linux, dont mcMidiPlayer, qui est un lecteur MIDI de fichiers audio multicanaux, et space3D64, qui permet la spatialisation 3D sur 64 canaux ; tout ceci est présenté sur cette page.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles ou ENI. Voici les gagnants du mois de juin 2020 :

      Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

      Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions Eyrolles et ENI.

      Bandeau LinuxFr.org

      Les livres sélectionnés :

      Logo éditions ENI   Logo éditions Eyrolles
                

      Commentaires : voir le flux Atom ouvrir dans le navigateur

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

      Bannière LinuxFr.org

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

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • Comme vous le savez si vous suivez les dépêches annuelles de Haiku, la date de naissance du projet est le 18 août 2001, avec l’envoi du premier message « Ok, let's start » sur la liste de diffusion du projet (nommé OpenBeOS à l’époque).

      C’est l’occasion de faire un point sur les principales avancées du projet dans l’année (et d’avoir un peu d’activité sur LinuxFr.org au milieu de l’été).

      Logo de Haiku

      Sommaire

      Présentation de Haiku

      Note : cette section est reprise de la dépêche de l’année dernière, les objectifs du projet n’ont pas changé depuis.

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

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

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

      Pourquoi un clone de BeOS ?

      À l’origine, Haiku est pensé pour fournir une continuité aux utilisateurs de BeOS et aux développeurs d’applications qui ne souhaitaient pas migrer vers un autre système. Dix‑huit ans plus tard, BeOS est mort et enterré, et Haiku n’a pas réussi à fournir une version stable dans les temps. La plupart des développeurs d’applications sont passés à autre chose depuis. Cependant, Haiku reste un projet pertinent aujourd’hui, car aucun système libre n’a vraiment pris la place que BeOS a libérée (dit autrement, non, ce n’est toujours pas l’année de GNU/Linux sur le bureau).

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

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

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

      La version bêta 2

      La deuxième version bêta de Haiku a été publiée avec environ six mois de retard sur la date prévue. Vous trouverez les détails dans la dépêche qui lui est dédiée. Comme cette version est encore toute récente, cette dépêche ne va pas s’attarder sur les nouveautés déjà détaillées dans l’annonce de cette version. Nous allons donc plutôt essayer de voir les travaux en cours et les perspectives pour les années à venir.

      Enfin, comme il reste encore de nombreux DVD de la bêta 1 (à prix libre), il n’est pas prévu d’en faire presser de nouveaux, d’autant plus qu’après installation de ceux‑ci le système d’exploitation peut être mis à jour vers la bêta 2.

      Participation au Google Summer of Code

      Haiku participe régulièrement au Google Summer of Code depuis 2006. Le principe est d’accueillir dans le projet des étudiants qui contribuent pendant trois mois en étant rémunérés par Google. Cela permet à ces étudiants de se concentrer à plein temps sur leur travail pour Haiku (et plus d’une centaine d’autres projets participants), en étant rémunéré par Google. Les projets participants assurent l’encadrement et sont libres du choix des sujets (Google n’a donc pas d’influence sur les développements par ce moyen, si cela vous inquiétait).

      Cette année, quatre étudiants ont été retenus pour améliorer Haiku.

      L’amélioration des paramètres des périphériques d’entrée

      Le travail sur ce sujet avait été démarré l’été dernier dans le cadre d’Outreachy. Il s’agissait dans un premier temps de regrouper dans une seule fenêtre les réglages du clavier et de la souris (qui étaient configurables auparavant dans deux applications séparées). Cet été, le travail se poursuit pour pouvoir configurer chaque périphérique de pointage différemment (par exemple, pour avoir une vitesse de pointeur différente pour un pavé tactile et une souris).

      La prise en charge des systèmes de fichiers XFS et UFS2

      Afin d’améliorer l’interopérabilité avec les autres systèmes d’exploitation, deux étudiants travaillent actuellement sur la prise en charge des systèmes de fichiers XFS et UFS2.

      UFS2 va permettre, d’une part d’accéder aux fichiers sur les partitions de FreeBSD (et probablement des autres *BSD). Il permettra aussi de construire des images disque amorçables sur les stations de travail Sun lorsque le portage de Haiku sur SPARC sera un peu plus avancé.

      XFS est un système de fichiers développé au départ par Silicon Graphics pour IRIX, les développeurs de Haiku l’utilisent souvent pour leurs installations de GNU/Linux en raison de sa meilleure prise en charge des attributs étendus de fichiers, nécessaire pour compiler Haiku.

      La réécriture de l’API réseau

      Haiku dispose d’une implémentation d’un client HTTP, mais celle‑ci est complexe à utiliser et peu performante. Un des projets du Summer of Code de cet été est une refonte de cette API encore expérimentale, pour corriger ces problèmes.

      Participation à Outreachy et au Google Code‑In

      Outreachy est un programme similaire au Google Summer of Code organisé par l’association Software Freedom Conservancy. Le but est d’encourager la participation des minorités (quelles qu’elles soient) dans les projets libres.

      Le fonctionnement est similaire à celui du Summer of Code, avec la différence importante que les projets doivent financer eux‑mêmes le paiement des participants. Haiku a participé l’été dernier, mais ne peut pas se permettre pour l’instant de renouveler la chose, en attendant de trouver un ou plusieurs sponsors qui permettraient de le faire à nouveau.

      Le Google Code-In était un concours visant les adolescents de treize à dix‑sept ans, dont le principe était de proposer des tâches à réaliser pour différents projets libres. Haiku est le seul projet à avoir participé tous les ans depuis la création du Code‑In en 2010, grâce aux efforts de Scott McCreary et d’une équipe de « mentors » s’occupant de relire et de valider le travail des participants (la plupart n’étant pas des développeurs actifs de Haiku, mais des membres de la communauté ou des anciens participants au Code‑In). Malheureusement, Google a choisi de ne pas renouveler ce programme en 2020. Différentes idées sont en cours de réflexion pour le remplacer : monter un concours similaire sans l’aide de Google, ou rejoindre d’autres évènements existants comme Hacktoberfest, par exemple.

      Des idées pour la suite

      La publication de la version bêta 2 en juin a beaucoup mobilisé les contributeurs depuis le début de l’année. L’été est assez calme pour l’instant. La rentrée sera sûrement l’occasion de discuter d’un plan d'attaque pour la version bêta 3.

      Comme après chaque publication de version, les rapports de bogues ont été nombreux. Un effort de tri a été fait depuis quelques années sur le système de suivi des bogues pour séparer les tickets « indispensables » dans la version R1 de Haiku, de ceux qui pourraient être traités plus tard. Cela laisse un peu moins de 1 130 tickets à traiter avant la version R1 au dernier décompte.

      Le travail se poursuit pour corriger ces problèmes un par un. Tous les domaines sont concernés, par exemple, en ce moment, un développeur s’occupe du « Media Kit » et des pilotes pour les cartes sons, qui sont pour l’instant plutôt capricieux (silence pendant plusieurs minutes au démarrage avant de se mettre à fonctionner, matériel non reconnu sur certaines machines, pilote qui fonctionne uniquement si la carte a été initialisée préalablement par un autre système d’exploitation…) ; tandis que plusieurs autres améliorent le serveur graphique pour accélérer l’affichage (en particulier des pages Web complexes), améliorer la mise à l’échelle pour les écrans à haute résolution, etc.

      D’autre part, on ne peut pas empêcher les développeurs de s’amuser avec des développements qui ne rentrent pas dans la feuille de route. C’est ainsi que le travail continue sur le portage de Haiku vers les architectures SPARC, ARM ou Motorola 680x0 ; ou encore les pilotes pour les cartes SD et les puces eMMC. Si ces apports ne sont plus vraiment utiles pour certains, ou pas encore pour d’autres sur des machines actuelles, ils permettent néanmoins d’améliorer le code en le factorisant par exemple, ou grâce à un meilleur alignement des données, nécessaire sur une architecture exotique mais augmentant aussi les performances sur x86.

      Avant d’arriver à une version complètement satisfaisante, il faudrait aussi s’occuper de tous les aspects concernant la gestion des imprimantes, de corriger les problèmes restants dans l’implémentation du protocole TCP, et encore bien d’autres choses. Il est probable que cela nécessite encore plusieurs versions bêta et quelques années de développement supplémentaires.

      Statistiques de contribution

      Comme c’est bien de savoir où on en est, PulkoMandy publie de temps en temps des statistiques sur les contributions au dépôt Git de Haiku et à HaikuPorts. Depuis quelques mois, l’outil utilisé pour générer ces statistiques est repostat, en remplacement de gitstats qui n’était plus maintenu et n’a jamais été migré en Python 3. Avant de pouvoir migrer, il a cependant fallu ajouter quelques fonctionnalités manquantes à repostat, et le rendre beau, en remplaçant les graphiques statiques générés avec Gnuplot par des graphes générés en JavaScript et SVG en utilisant NVD3.

      Des détails pour Haiku

      Pour Haiku, on peut constater que l’activité est stagnante depuis 2016 avec 1 300 à 1 500 commits par an. On est loin du record de 5 555 commits atteint en 2009. Cependant, chaque année ce sont plus d’une cinquantaine de contributeurs qui participent à Haiku, et depuis 2016 ce chiffre semble également augmenter, même si pour l’instant le record est toujours en 2012 avec soixante‑douze contributeurs. En 2018 et 2019, un seul contributeur a réalisé à lui seul plus d’un tiers puis plus de la moitié des commits. L’année 2020 semble pour l’instant mieux équilibrée.

      Le nombre de fichiers (un peu plus de 30 000) et de lignes de code (entre cinq et six millions) n’évoluent pas beaucoup depuis 2015 (ou il avait fortement baissé suite à la suppression de nombreuses bibliothèques tierces qui avaient été copiées dans le dépôt Git, et qui sont maintenant téléchargées lors de la compilation).

      Des détails pour HaikuPorts

      Du côté de HaikuPorts, l’activité a été importante en 2017 et 2018, juste avant la sortie de la première version bêta. Elle se maintient bien depuis, avec plus de 2 000 commits par an (plus de cinq par jour).

      Le nombre de contributeurs est assez élevé pour HaikuPorts (une soixantaine chaque année). Cependant on voit que les dix contributeurs les plus actifs sont responsables de 75 % des recettes de construction de paquet. Cela s’explique en partie par des contributions de personnes qui maintiennent des recettes pour empaqueter leurs propres logiciels, avec donc une activité assez restreinte.

      Le dépôt contient actuellement des recettes pour 2 762 logiciels et bibliothèques.

      Des moyens de communications

      Le service de journalisation echelog pour les canaux IRC de Freenode a été arrêté. Ce service avait été développé au départ pour les canaux de Haiku et lwjgl, mais était utilisé par de nombreux autres projets également. Haiku utilise désormais logbot en remplacement.

      Haiku commence à se poser la question de la migration des salons de discussion et des autres moyens de discussion. Historiquement, IRC et des listes de diffusion par courriel sont principalement utilisés. Cependant, ces outils ne sont plus aussi courants aujourd’hui et pas forcément appropriés dans toutes les situations (pas accessibles facilement avec un ordiphone, par exemple) et cela freine la participation de certains contributeurs. De plus, il manque un certain nombre de fonctionnalités (par exemple, la modération sur les listes de diffusion permettant de supprimer un message et de bloquer un fil de discussion pour empêcher des réponses inutiles), ou bien il y a du travail à faire pour les mettre en place (les journaux du canal IRC, par exemple).

      Les conditions qui semblent indispensables pour la migration font cependant qu’il n’y a pas beaucoup d’alternatives :

      • utilisation de logiciels libres avec un protocole documenté et standardisé ;
      • pas de contraintes sur les personnes qui peuvent utiliser le service (par exemple, certains services de discussion sont interdits aux moins de treize ans) ;
      • disponibilité de clients pour la plupart des systèmes, y compris Haiku (sans avoir besoin d’installer Qt ou autre grosse bibliothèque multi‑plate‑forme).

      Le candidat le plus avancé est probablement XMPP (avec le client Renga), mais cela demandera encore du temps avant d’avoir un client complet et de commencer à envisager une migration.

      En attendant, il est possible de trouver des développeurs et utilisateurs de Haiku sur divers services tels que Matrix, Telegram, Discord, BeShare (un système de clavardage et partage de fichiers en pair à pair développé pour BeOS à l’origine), ainsi que sur le forum discuss.haiku-os.org ou encore sur Reddit.

      Des ponts ont été mis en place entre IRC et Matrix, et entre IRC et BeShare. Les salons Telegram restent séparés car leur usage est un peu différent (beaucoup d’envoi d’images ou de vidéos, voire de messages vocaux) et cela serait plus dérangeant qu’autre chose sur le canal IRC.

      La situation actuelle nous empêchant d’organiser des rencontres dans la vie réelle pour probablement encore quelque temps, cette réflexion prend un peu plus d’importance en ce moment.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • Laurent est un professeur des écoles qui, selon sa propre description sur Mastodon, « geeke en Bépo sans GAFAM ». Il utilise des outils informatiques pour sa classe de CM1-CM2. On découvrira au cours de cette interview, la diversité des outils, quasiment tous libres, qu’il utilise. C’est assez impressionnant. De quoi en inspirer plus d’un ou d’une. Et, d’ailleurs, cela a fait réfléchir la DSI de la ville où il exerce. En effet, elle envisage d’équiper toutes les écoles de la ville d’outils (et d’ordinateurs) comme ceux qu’il utilise en classe.

      On ne pouvait évidemment pas interviewer un enseignant sans lui demander son vécu pendant le confinement, et notamment comment cela s’est organisé. On verra que le surcroît de travail ne lui a pas laissé trop de temps pour aller à la cueillette des fraises et que certains de ses élèves ont vraiment fait preuve d’astuce pour arriver, malgré tout, à faire et à rendre le travail requis.

      Sommaire

      Un instituteur informatisé

      Dans quelles classes enseignes‑tu ?

      Depuis l’année dernière, j’ai une classe de CM1‑CM2 de niveau vraiment très hétérogène, mon école étant située en QPV (quartier prioritaire de la politique de la ville1). Les années précédentes, j’avais des CE1‑CE2.

      Tu utilises des outils informatiques en classe, dans quel contexte ? Comment les intègres‑tu à ta pédagogie ?

      L’informatique est en effet très présente dans ma pratique de classe. J’utilise de manière assez intensive mon propre ordinateur portable sous Ubuntu 18.04 et un TBI (tableau blanc interactif) qui me sert essentiellement de vidéoprojecteur, puisque celui‑ci est d’une marque qui n’est pas compatible avec Linux (eBeam (EN)). Je projette des vidéos de Canopé, des leçons au format Impress (ODP), des exercices que je conçois, les documents que je distribue… J’ai aussi souvent recours à UN outil non libre (que RMS me pardonne !) : Plickers (EN). Il permet de voir très rapidement ce qui a été retenu en dédramatisant les évaluations et en les rendant plus ludiques. Je peux ainsi créer rapidement les groupes de besoin.

      Ces outils t’ont‑ils été imposés ?

      Non, je suis entièrement libre de mes choix, même si les DSI de la ville voyaient d’un assez mauvais œil, au début, que je n’utilise pas la vieille tour sous Windows 7 présente dans la classe.

      Est‑ce qu’ils ne sont qu’à ton seul usage ? Les élèves disposent‑ils eux‑mêmes d’outils informatiques, si oui, lesquels et où ?

      Sur tout le mur du fond de ma classe a été aménagé un grand plan de travail sur lequel sont disposés huit portables sous Ubuntu (20.04, je viens de faire les mises à jour). Comme je travaille beaucoup en ateliers, les élèves passent en moyenne deux fois vingt minutes par matinée sur un PC. J’ai un petit site sous PluXML que j’alimente chaque semaine avec des séries d’exercices créés avec LearningApps ou des liens vers des ressources extérieures (Calcul@tice, jeuxpedago.com, Matheros, Cliclire…), ce qui me permet une grande flexibilité et une granularité très fine dans l’adaptation, la différenciation et la remédiation. J’utilise également Gcompris, TuxMath et Audacity pour que les élèves enregistrent leur lecture ou leur récitation. LibreOffice Writer et Framapad font aussi partie de la panoplie d’outils que j’utilise très souvent. Et enfin, la recherche dans Firefox s’ouvre automatiquement sur la page Qwant Junior.

      Tout le travail des élèves est enregistré sur un NAS et un script Bash me permet, chaque jour, de récupérer les derniers travaux et d’archiver les anciens.

      Tu as refait dernièrement des cahiers pédagogiques. Peux‑tu nous en dire plus ? À partir de quoi étaient‑ils faits, quels logiciels as‑tu utilisés pour les concevoir ? Comment tes propositions ont‑elles été reçues par tes collègues ?

      Ces cahiers sont juste un outil de CE1‑CE2 mis à disposition par le site Lutin Bazar. Je me suis contenté d’en rédiger l’index et de le mettre en page avec BookletImposer. La nouveauté de cette année est simplement un changement de couverture, l’originale me semblant trop terne et peu attirante.

      L’ancienne et la nouvelle couverture

      J’ai donc proposé une quinzaine de variantes aux collègues qui ont choisi celle qui leur « parlait » le plus. J’ai ensuite retravaillé la version finale (qui n’est pas celle que je préférais) en tenant compte de leurs remarques et suggestions. La couverture qu’elles ont retenue a été créée exclusivement avec LibreOffice Writer, mais j’en avais également proposé qui contenaient des éléments travaillés sous GIMP (EN).

      Les propositions non retenues  Les propositions non retenues

      D’une manière générale, dans ton école est‑ce que les autres enseignants utilisent aussi des outils informatiques, sont‑ce les mêmes que les tiens ?

      Grâce à un don que m’a fait une entreprise qui renouvelait son parc informatique, j’ai pu équiper l’école de vingt‑huit postes sous Linux, dont huit dans ma propre classe. Les autres sont répartis par deux, trois ou sept dans les classes des collègues. Leur usage est très variable et couvre tout l’éventail allant de la non‑utilisation à l’usage intensif. Pour celles de mes collègues qui les utilisent, l’usage est sensiblement le même que celui que j’en fais moi‑même. Il n’y a qu’en maternelle où des outils exclusivement sous Windows sont utilisés. Pour la plupart ils sont passablement obsolètes (certains ne fonctionnent que sous XP !), mais les collègues ont leurs habitudes…

      Est‑ce que ton école, globalement, utilise prioritairement des logiciels libres ?

      Firefox et LibreOffice sont installés sur toutes les machines, y compris les postes Windows. Les vingt‑huit postes Linux, évidemment, utilisent presque exclusivement du logiciel libre. Mais c’est une problématique qui n’existait absolument pas avant mon arrivée dans l’école. L’expérience semble pourtant porter ses fruits, puisque la DSI, au vu des usages qui sont faits dans mon école, envisage désormais sérieusement d’équiper toutes les écoles de la ville de postes sous Linux.

      Est‑ce que tes collègues sont sensibilisés aux problèmes de sécurité des données ?

      Trop peu. J’ai placardé dans la salle des maîtres les affiches de la Quadrature du Net (Google filtre ta pensée, Facebook contrôle ce que tu peux lire…), ce qui a généré quelques questions… et beaucoup de fatalisme.

      Lorsque j’ai formé mes collègues à l’utilisation de SPIP, j’ai beaucoup insisté sur l’absence de collecte de données. Mes collègues semblaient tout de même très au fait de leur devoir de protection des données concernant les élèves… beaucoup plus que des leurs !

      Un instituteur confiné

      Est‑ce que, pendant la phase de confinement tu as changé ta manière d’enseigner, et pourquoi ?

      C’était inévitable. La distance et l’absence de contact avec les élèves nous ont obligés à réinventer le métier, souvent dans l’urgence, avec notre matériel personnel, nos savoirs propres, dans l’impréparation et en tenant compte des injonctions hiérarchiques contradictoires.

      Est‑ce que la charge de travail était la même ?

      Il y a eu différentes phases. La première phase a fait peser sur nous une charge mentale très forte : il fallait inventer les façons de travailler. Le stress couplé aux nouveaux modes de préparation du travail ont été particulièrement pénibles. Les corrections individuelles par SMS ou par courriel (mais aussi par le cloud) prenaient un temps incroyable et s’étalaient sur toute la journée, souvent jusqu’à plus de vingt‑deux heures.

      Pendant la deuxième phase, pour me préserver, je ne demandais plus que tout me soit rendu, mais seulement une sélection quotidienne d’exercices, généralement un de français et un de mathématiques. Mais la correction est restée une activité extrêmement chronophage. D’autant plus que je mettais en ligne chaque soir la correction de tous les exercices du jour, y compris et surtout ceux pour lesquels je n’avais pas demandé qu’on me les rende.

      Ensuite, lors de la reprise partielle, il a fallu mener de front le présentiel et le distanciel, là, la quantité de travail s’est encore accrue. Donc, non, la charge de travail n’était pas la même, elle était beaucoup plus importante.

      Tes élèves ont‑ils dû recourir plus à l’outil informatique ? Quels logiciels, applications, réseaux de communication ?

      Lors de mon arrivée dans l’école où j’enseigne, j’ai immédiatement mis en place un site Web de l’école (sous SPIP) et formé mes collègues à son utilisation. Mais celui‑ci vivotait puisque j’étais quasiment le seul à l’alimenter en y mettant les devoirs à faire, les documents que je distribuais, les poésies, les chants en audio, etc. Lors du confinement, cet outil est devenu de facto le moyen de communication privilégié, autant les parents que les élèves et les collègues se sont mis à en tirer entièrement profit. Les statistiques sont éloquentes à ce sujet.

      Les statistiques du site  Une courbe éloquente de fréquentation.

      Le courriel et le SMS (j’utilise Silence) ont également beaucoup été utilisés pendant cette période. J’ai mis en place un numéro dédié auquel les élèves pouvaient me joindre par SMS et m’envoyer leurs travaux en photo. De mon côté, j’ai trouvé l’outil qui me permettait de corriger un peu plus confortablement : scrcpy.

      Comment penses‑tu que tes élèves s’en sont « tirés ». Est‑ce que, globalement, ils ont pu continuer à suivre correctement leur scolarité ?

      Quelques élèves complétaient leur travail grâce à Adobe Reader, mais la plupart imprimaient les documents et m’envoyaient une photo du travail fini. Certains ont eu beaucoup de mérite : avec pour seul accès familial un téléphone et un forfait limité, m’envoyer chaque jour le travail fait relevait de la gageure.

      Bien sûr, il y a aussi eu quelques décrocheurs, trop à mon goût (deux sans aucune nouvelle, malgré des appels téléphoniques répétés de ma part, et quatre ne me renvoyant leur travail que très épisodiquement). Mais hormis ces quelques cas, les élèves ont dans l’ensemble « joué le jeu » et bien fait leur travail. Mais il faut bien garder à l’esprit que consigne nous était donnée de ne pas aborder de notion nouvelle. On ne peut pas dire, dès lors, que la scolarité ait été normale.

      As‑tu eu plus de contacts avec les parents ? De quelle sorte ?

      Oui, beaucoup plus. J’ai appelé les parents à de nombreuses reprises, pour prendre des nouvelles, pour remotiver, donner des conseils, pour demander qu’on me rende le travail, pour m’enquérir des difficultés rencontrées, etc. Et les échanges de courriels ou de SMS étaient quotidiens, que ce soit les envois groupés pour signaler la mise en ligne de contenu, les envois individuels pour réexpliquer un point de grammaire, pour donner la correction individualisée du travail, ou pour les communications institutionnelles (maintien ou passage dans la classe supérieure, constitution de dossier pour le collège…).

      Quel bilan pourrais‑tu tirer de cette période, notamment en ce qui concerne l’usage des outils informatiques ?

      Le site Web que j’avais mis en place s’est avéré un outil très performant et utile. Le courriel et le smartphone (dégooglisé !) ont permis de garder un contact très étroit avec les élèves et leurs familles. Cependant, aucune de ces technologies ne remplace le contact direct avec les enfants et rien ne me permet de croire que l’enseignement dispensé de cette façon soit souhaitable ou gérable à plus ou moins long terme. La technologie est un moyen et non une fin. Et dans le cas qui nous occupe, celle‑ci a montré ses limites, tant dans son utilisation que dans l’implication qu’elle requiert de la part des usagers. Nous (enseignants et élèves, parents) ne sommes ni prêts, ni formés.

      Les questions récurrentes

      Au niveau professionnel, quels logiciels libres utilises‑tu, sur quel système d’exploitation (outre ceux déjà indiqués) ?

      La machine sur laquelle je prépare ma classe et celle que j’utilise à l’école sont toutes les deux sous Ubuntu 18.04, avec une synchronisation Nextcloud hébergée par le CHATONS La mère Zaclys. Outre les logiciels déjà mentionnés plus haut, j’utilise beaucoup Firefox et Thunderbird, gImageReader, Xournal++, PDFarranger, Okular (que je préfère à Evince), ImageMagick, BookletImposer, Flameshot, Kdenlive, Wine (et une petite VirtualBox au cas où…).

      Quelle est ta distribution GNU/Linux préférée et pourquoi, quels sont tes logiciels libres préférés ?

      Je distingue deux choses : ma préférée et ma préférable. J’utilise essentiellement Ubuntu, parce que c’est solide, et j’ai besoin que ça « juste marche ». Mais KDE Neon (EN) est ma distribution préférée : je trouve Plasma très intéressant, esthétiquement très réussie, hautement configurable et, contrairement à la légende urbaine, elle sait être très légère sur les ressources.

      Firefox, Thunderbird et LibreOffice sont incontestablement mes champions, mais je dois une fière chandelle à scrcpy (EN). Enfin, j’affectionne particulièrement GIMP, Tor, Clementine et KeePassX, KDE Connect.

      Quelle question aurais‑tu adoré qu’on te pose (évidemment, tu peux y répondre) ?

      Depuis quand es‑tu utilisateur de Linux ?

      Je suis un Linux-n00b depuis 1999 !

      Quelle question aurais‑tu détesté qu’on te pose (en espérant que je ne te l’ai pas posée) ?

      Combien de temps par jour passes‑tu devant un écran ? Beaucoup trop !

      Merci beaucoup.


      1. Le QPV est un dispositif de la politique de la ville française à destination des zones socialement défavorisées. 

      Commentaires : voir le flux Atom ouvrir dans le navigateur

    • Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

      [LeMagIT] Souveraineté numérique et « Guerre Froide » technologique : l’avenir du cloud s’annonce orageux

      ✍ Philippe Ducellier, le vendredi 31 juillet 2020.

      « Pour la banque d’investissement Klecha & Co, au regard du contexte de guerre économique où l’Europe est un terrain de jeu possible pour les États‑Unis et la Chine, la cloudification massive ira de pair avec la question de la souveraineté des données et de l’indépendance technologique. »

      [Le Monde.fr] Après la crise, les communs numériques en quête de reconnaissance (¤)

      ✍ Claire Legros, le mardi 28 juillet 2020.

      « “Le retour des communs” (2/6). Pendant le confinement, les données et outils ouverts ont joué un rôle vital et prouvé leur pertinence en temps de crise. La séquence a aussi mis en lumière la nécessaire articulation entre ces communs numériques et les secteurs public et privé. »

      [Clubic.com] PeerTube, le projet d’alternative à YouTube décentralisée, avance bien !

      ✍ Benjamin Bruel, le lundi 27 juillet 2020.

      « Deux ans après le financement participatif qui avait conduit à sa naissance, PeerTube, l’alternative à YouTube française et libre, continue gentiment de rouler sa bosse. Framasoft, l’association pour le développement de logiciels libres à l’origine du projet, dévoile la version 2.3 de PeerTube. »

      Commentaires : voir le flux Atom ouvrir dans le navigateur