Dossier : OpenSource
Tous les événements non lus pour le dossier OpenSource
VLC — Émission « Libre à vous ! » du 21 septembre 2021 — Podcasts et références
LinuxFr.org : les dépêches par Frederic Couchet le 29/09/2021 à 11:10:00 - Favoriser || Lu/Non lu
Cent-quinzième émission « Libre à vous ! » de l’April. Podcast et programme :
- sujet principal : le lecteur multimédia libre VLC. Avec notre invité : Jean-Baptiste Kempf, président de VideoLAN, l’association qui gère VLC et fondateur de la société Videolabs qui crée des services autour de VLC et, plus généralement, des nouveautés autour de la vidéo. C'est une rediffusion d'un sujet diffusé le 29 octobre 2019
- chronique de Typhaine Bonnet, avocate au cabinet Dune, sur l'Open Data et la réutilisation des données publiques
- chronique de Vincent Calame, bénévole à l'April, sur le copier-coller
- lien nᵒ 1 : Radio Cause Commune
- lien nᵒ 2 : Libre à vous !
- lien nᵒ 3 : Podcast de la 115ᵉ émission
- lien nᵒ 4 : Les références pour la 115ᵉ émission et les podcasts par sujets
- lien nᵒ 5 : S'abonner au podcast
- lien nᵒ 6 : S'abonner à la lettre d'actus
Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 MHz en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.
Vous pouvez laisser un message sur le répondeur de la radio, pour réagir à l’un des sujets de l’émission ou poser une question. Le numéro du répondeur : +33 9 72 51 55 46.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Emmabuntüs DE4 basée sur Debian Bullseye
LinuxFr.org : les dépêches par Saby43 le 29/09/2021 à 11:09:00 - Favoriser || Lu/Non lu
Ce lundi 20 septembre 2021, le collectif Emmabuntüs vient d’annoncer la sortie de sa nouvelle version Emmabuntüs Debian Édition 4 1.00, basée sur la Debian 11.0 Bullseye stable, disponible en version 32 ou 64 bits et supportant les deux environnements Xfce et LXQt.
Rappelons que cette distribution est née au sein d’Emmaüs, pour faciliter le reconditionnement des ordinateurs donnés aux associations, notamment humanitaires, mais aussi pour favoriser la découverte de GNU/Linux par les débutants, tout en prolongeant la durée de vie du matériel informatique, ce qui réduit le gaspillage lié à la surconsommation de matière première.
Les nouveautés de cette dernière version sont la suppression de certains logiciels propriétaires au profit d’alternatives libres tels que DWService à la place de Teamviewer, Jami remplaçant Skype, et la suppression d’Adobe Flash devenu obsolète.
La suite de l'article vous fera découvrir le nouveau thème graphique et le nouveau logo.
- lien nᵒ 1 : Annonce de la sortie de l'EmmaDE4 1.00
- lien nᵒ 2 : « Les cahiers du débutant » version Bullseye
- lien nᵒ 3 : Le site de Juliette Taka
- lien nᵒ 4 : Interview de Juliette
- lien nᵒ 5 : Interview de Jean-Claude
- lien nᵒ 6 : Vidéo de Blabla Linux sur les clones
- lien nᵒ 7 : Présentation d’EmmaDE4 1.00 par Blabla Linux
- lien nᵒ 8 : Téléchargements
- lien nᵒ 9 : Clones OEM
- lien nᵒ 10 : Contacter Emmabuntüs
Cette version arbore le nouveau thème graphique Ice réalisé par Juliette Taka, graphiste qui a réalisé de nombreux fonds d’écran pour Debian, ainsi qu’un logo rajeuni dont le relooking a été réalisé par Jean-Claude aka JCZ, qui lui aussi a participé à des projets de fonds d’écran pour Debian.
Écran de login avec le relooking du notre logo et le nouveau thème Ice de l’EmmaDE4
Les clones OEM de cette version stable, qui permettent une installation par clonage dans le cadre d’install-parties, sont disponibles sur cette page, et Blabla Linux a réalisé une vidéo sur ce sujet.
Fenêtre d’installation de Calamares en mode classique ou OEM
Le collectif Emmabuntüs assume le choix d’embarquer un nombre important de logiciels, ce qui évite aux débutants ou aux formateurs d’avoir à les installer, comme par exemple au nord du Togo.
Salles informatiques sous Emmabuntüs au Togo, installées par YovoTogo, JUMP Lab’Orione, et Emmabuntüs en 2020
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Sortie de Fedora Linux 35 Beta
LinuxFr.org : les dépêches par Renault le 28/09/2021 à 20:25:00 - Favoriser || Lu/Non lu
En ce mardi 28 septembre, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 35.
Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 35 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.
La version finale est pour le moment fixée pour le 19 ou 26 octobre.
- lien nᵒ 1 : Site officiel du projet Fedora
- lien nᵒ 2 : Site officiel de la communauté francophone de Fedora
- lien nᵒ 3 : Torrents officiels pour télécharger les différentes éditions
- lien nᵒ 4 : Les versions avec bureaux alternatifs de Fedora (KDE, Xfce, etc.)
- lien nᵒ 5 : Les suites de productivités de Fedora (astronomie, design, etc.)
- lien nᵒ 6 : Calendrier pour Fedora 35
Sommaire
- Expérience utilisateur
- Gestion du matériel
- Internationalisation
- Administration système
- Développement
- Projet Fedora
- Tester
Expérience utilisateur
- Passage à GNOME 41 ;
- En lien avec la nouvelle fonctionnalité de GNOME concernant l'énergie, Fedora installe par défaut le paquet power-profiles-daemon pour contrôler via DBus la politique énergétique du système entre performance, équilibré ou économie d'énergie ;
- GNOME Logiciels et GNOME Initial Setup proposent une option à l'utilisateur pour activer des dépôts tiers ;
- Ajout d'un dépôt tiers nommé fedora-flathub-filter qui expose des applications Flatpaks provenant de Flathub sélectionnées par Fedora. L'installation usuelle de Flathub reste nécessaire pour accéder à l'ensemble de ses applications ;
- WirePlumber va gérer les sessions Pipewire pour l'audio dorénavant plutôt que ce que Pipewire utilise en interne ;
- Le système Fedora Kinoite devient une variante officielle. C'est l'équivalent de Fedora Silverblue avec KDE Plasma comme environnement graphique par défaut.
Gestion du matériel
- L'image Fedora Cloud prend en charge le mode hybride BIOS et UEFI pour le démarrage de la machine ;
- Les partitions chiffrées avec LUKS auront la taille du secteur défini automatiquement, suivant le matériel sous-jacent pour améliorer les performances. Jusqu'ici la taille était fixe à 512 octets par secteur, cela devrait être de 4096 octets par secteur dans la majorité des cas.
Internationalisation
- IBus est proposé à la version 1.5.25 ;
- La méthode d'entrée par défaut pour les langues indo-aryennes passe de Inscript vers Enhanced Inscript keymaps.
Administration système
- L'image de base de Fedora ne fournit plus les paquets sssd-client et util-linux pour réduire la taille des conteneurs avec Fedora ;
- L'installateur Anaconda prend en charge des fichiers de profil et non plus des fichiers de configuration de produits pour être plus générique.
- systemd-resolved prend en charge DNS over TLS (DoT) si le serveur DNS configuré par l'utilisateur supporte cette fonctionnalité. Cela ajoute une couche cryptographique aux requêtes DNS ;
- L'image Fedora Cloud utilise le système de fichiers btrfs par défaut ;
- Les mots de passe des utilisateurs dans /etc/shadow sont hashés par yescrypt par défaut ;
- La mise à jour d'un paquet ayant un service systemd au niveau utilisateur mènera à son relancement à la fin de la mise à jour. Auparavant cela n'était fait que pour systemd en tant que PID 1 au niveau système ;
- Le gestionnaire de virtualisation libvirt a un démon par module dorénavant pour plus de souplesse et de fiabilité. Le service _ libvirtd.service_ est supprimé en faveur de virtqemud.service, virtxend.service, virtlxcd.service, virtinterfaced.socket, virtnetworkd.socket, virtnodedevd.socket, virtnwfilterd.socket, virtproxyd.socket, virtsecretd.socket et virtstoraged.socket ;
- La bibliothèque Cyrus SASL passe de Berkeley DB à GDBM pour la gestion des bases de données. Les paquets concernés auront leurs bases de données automatiquement convertis via la commande :
cyrusbdb2current <sasldb path> <new_path>
- Le cache de SSSD pour les utilisateurs locaux peut être activé ou désactivé à chaud, et il n'est plus lancé par défaut dorénavant.
- Mise à jour du parefeu dynamique firewalld à la version 1.1.0 ;
- Suppression du paquet authselect-compat, de fait l'outil authconfig disparaît au profit de authselect qui est mis par défaut depuis Fedora 28 ;
- Le paquet libusb est renommé libusb-compat-0.1 et libusbx vers libusb1 ;
- Mise à jour de RPM à la version 4.17.
Développement
- La collection d'outils binutils passe à la version 2.37 ;
- La chaine de compilation GNU est mise à jour avec GCC 11, Glibc 2.34 et GDB 10.2 ;
- De même pour la suite LLVM pour leur 13e version ;
- La bibliothèque généraliste de C++, Boost, appuie sur le champignon jusqu'à la version 1.76 ;
- Node.js 16 est proposé par défaut. Les versions 14 et 12 restent disponibles dans les modules facultatives ;
- Le langage Python 3.10 est déployé pendant que Python 3.5 est entièrement retiré ;
- Le célèbre générateur de documentation en Python, Sphinx, veille sur la 4e version ;
- Le langage Perl perle vers la version 5.34 ;
- Le langage de programmation fonctionnelle et concurrente Erlang 24 est disponible ;
- Son voisin Haskell bénéficie du compilateur GHC 8.10 et de sa distribution Stackage version 18 ;
- Le langage PHP 8.0 fait son apparition ;
- L'environnement de compilation de binaires Windows, MinGW, est mis à jour ;
- La bibliothèque graphique SDL 2.0 fournira la gestion de la compatibilité avec la version 1.2, plutôt que l'installation de cette ancienne version ;
- Le paquet libmemcached utilise le code de libmemcached-awesome au lieu du projet d'origine, qui n'est plus maintenu depuis 7 ans. Le tout reste compatible au niveau API et ABI ;
- Debuginfod est utilisé par défaut pour obtenir les codes source et autres données de débogage en cas de nécessité, plutôt que de recourir à l'installation des paquets de débogage correspondant.
Projet Fedora
- Le fichier /etc/os-release renvoie le nom du système comme Fedora Linux et non Fedora. Cela met en avant la distinction entre le projet Fedora et le système lui même, qui s'appelle Fedora Linux maintenant ;
- La politique de choix du compilateur pour générer un paquet évolue pour laisser plus de latitude à l'empaqueteur. GCC ou Clang/LLVM peuvent être choisis par l'empaqueteur même si GCC est pleinement supporté ou non par le projet en question. Avant seulement GCC devait être utilisé, sauf si le projet ne gérait officiellement que Clang ;
- La politique pour les paquets de Python a été mise à jour pour favoriser le travail commun avec Python et les autres distributions ;
- Par ailleurs, moins de paquets Python vont dépendre de _ python3-setuptools_ ;
- Un nouveau paquet glibc-gconv-extra est ajouté pour prendre en charge les formats d'encodage en dehors de UTF-*, unicode, ISO-8859-1, ISO8859-15, CP1252 et ANSI_X3.110 pour gagner 8 Mio sur une image minimale, seuls ces formats sont proposés par défaut avec Glibc ;
- Les paquets seront compilés sans -ffat-lto-objects par défaut, les paquets qui en ont besoin devront l'ajouter eux même ;
- Import de la macro OpenSUSE pour définir la mémoire minimale nécessaire par constructeur du paquet durant le parallélisme :
%limit_build -m 8192
Pour éviter que les gros projets comme chromium échouent par manque de mémoire.
- Lors de la construction d'un paquet RPM, le chemin RPATH sera vérifié et pourra faire échouer la génération du paquet s'il ne respecte pas les consignes du projet Fedora ;
- Les champs Release et changelog d'un paquet RPM peuvent être autogénérés par rpmautospec.
Tester
Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.
C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.
Les tests à effectuer et les rapports sont à faire [via la page suivante]. https://blog.fedora-fr.org/renault/ J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.
Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.
Si vous avez déjà Fedora Linux 34 ou 33 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.
Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.
En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora Linux 35.
Bons tests à tous !
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
OCaml en 2021
LinuxFr.org : les dépêches par octachron le 25/09/2021 à 12:07:00 - Favoriser || Lu/Non lu
La version 4.13.0 du langage OCaml est sortie le 24 septembre 2021, sept mois après OCaml 4.12.0 sortie le 24 février 2021.
OCaml est un langage fonctionnel de la famille des langages ML (dont font partie SML et F#). Il s’agit d’un langage fonctionnel multi‐paradigme fortement typé qui permet de mélanger librement les trois paradigmes : fonctionnel, impératif et objet. La plus grande spécificité d’OCaml dans le paysage des langages fonctionnels (Haskell, Rust, F#…) est probablement son système de module : les modules d’OCaml font partie intégrante du langage, et il est par exemple possible de décrire des modules paramétrés par d’autres modules (à travers des foncteurs).
La grande nouveauté de cette année 2021 est la convergence de l’environnement d’exécution entre la version standard d’OCaml et le prototype d’OCaml multi-cœur. Cette convergence amorce une nouvelle étape dans la transition vers OCaml multi-cœur. Au-delà des progrès vers OCaml multi-cœur, cette année 2021 a vu une de nombreuses avancées pour le langage OCaml et son compilateur que ce soit en termes d’architectures supportées, de messages d’erreurs, de fonctionnalités du système de types, mais aussi des améliorations de confort pour les programmeurs que ce soit au niveau des outils de profilage, de la gestion des avertissements ou de la bibliothèque standard.
- lien nᵒ 1 : Site officiel
- lien nᵒ 2 : Manuel de référence d'OCaml
- lien nᵒ 3 : ocamlverse
- lien nᵒ 4 : Forum officiel
- lien nᵒ 5 : Changelog
Sommaire
- La route vers le multi-cœur et OCaml 5.0
- Une prise en charge étendue de RISC-V à macOS/ARM64
- De meilleurs messages d’erreurs
- Améliorations de l’expérience utilisateur
- Plus de types pour les utilisateurs experts
- Au-delà d’OCaml multi-cœur
La route vers le multi-cœur et OCaml 5.0
Une des limites de l’implémentation actuelle de l’environnement d’exécution d’OCaml est son utilisation d’un verrou global. Ce verrou empêche les applications multithreads de bénéficier du parallélisme des fils d’exécution (threads). Au cours du temps, il y a eu plusieurs tentatives d’enlever ce verrou. La dernière initiative a germé chez OCaml Labs vers 2014-2015. Pour éviter les échecs précédents, cette initiative a décidé de se concentrer sur deux points : une compatibilité descendante presque parfaite avec la version monocœur d’OCaml, et une intégration incrémentale dans la branche principale d’OCaml. Ce travail de fond a commencé à être visible dans OCaml 4.10.0. Mais il s’est notablement accéléré dans OCaml 4.12.0. Une grande partie du travail dans OCaml 4.12 et 4.13 a été consacrée à diminuer les divergences entre l’environnement d’OCaml multi-cœur et la version principale d’OCaml.
Par exemple, un des changements majeurs prévus pour OCaml multi-cœur est la gestion des pointeurs pointant en dehors de la mémoire gérée par OCaml, sans être gardés par des métadonnées (parce que, par exemple, ils ont été alloués par une bibliothèque C externe). Dans la version monocœur d’OCaml, ces pointeurs étaient gérés en gardant une trace des zones mémoires allouées par OCaml. En passant à un environnement d’exécution multi-cœur, cette stratégie devient prohibitive en coût de synchronisation. Ces pointeurs nus ne seront donc pas autorisés dans OCaml multi-cœur. Pour assurer une évolution en douceur, OCaml 4.12.0 a ajouté deux options de configuration : une option pour désactiver la gestion des pointeurs nus directement pour les audacieux ; et une version plus prudente qui rajoute un test dynamique de la présence de ces pointeurs nus. Cette dernière option est notamment utilisée pour tester toutes les bibliothèques et programmes disponibles sur Opam (le dépôt de paquets d’OCaml).
Un autre point important est la gestion de l’ordonnancement entre l’utilisateur et l’environnement d’exécution (runtime). Dans la version monocœur d’OCaml, l’environnement d’exécution reprend la main à chaque allocation. Cela lui donne l’occasion de vérifier si le Glaneur de Cellule (GC) à du travail à faire, ou s’il faut s’occuper de signaux en attente. Une conséquence est qu’il est possible d’écrire du code numérique qui n’alloue jamais et ne rend jamais la main à l’environnement d’exécution. En absence de parallélisme, ce comportement est plus une curiosité qu’autre chose. Mais pour multi-cœur OCaml, ce comportement égoïste n’est plus de mise. Dans sa conception actuelle, OCaml multi-cœur a une phase de GC en parallèle, pendant laquelle tous les fils d’exécution exécutent une passe de GC de manière synchrone. Il n’est donc pas question qu’un fil d’exécution bloque le GC de tous les autres fils. Le compilateur natif a donc été modifié dans OCaml 4.13.0 pour s’assurer qu’un fil d’exécution passe toujours la main à l’environnement d’exécution dans un temps borné.
Un élément qui commence à apparaître dans les discussions sur OCaml multi-cœur est que l’on se rapproche d’un point où il ne reste plus qu’à faire le grand saut et intégrer le runtime multi-cœur, et absorber les petites pertes de performances inévitables pour le code séquentiel.
La première version d’OCaml qui intégrera la prise en charge du multi-cœur sera OCaml 5.0. Cette nouvelle majeure commencera avec une période de transition durant laquelle la branche 4 sera maintenue activement.
Cette première version d’OCaml multi-cœur n’intègrera pas la partie la plus innovante de la proposition initiale, le système d’effet, et se contentera d’exposer une bibliothèque de domaines et quelques API de plus haut niveau, bâtis au-dessus de cette bibliothèque de domaine.
Le but est de découpler la partie runtime du développement d’OCaml multi-cœur du travail de conception sur le système d’effet qui requiert encore des efforts de conception.
Une prise en charge étendue de RISC-V à macOS/ARM64
Le compilateur OCaml gère deux modes de compilation : un mode bytecode qui fonctionne sur toute architecture où un compilateur C est disponible ; et un mode natif qui émet directement des binaires natifs. Ce mode natif est d’ailleurs le seul utilisateur du système objet d’OCaml au sein du compilateur lui-même.
Cette gestion native requiert de s’adapter aux nouvelles familles de processeurs et aux variations d’ABI suivant les systèmes d’exploitation. OCaml 4.11.0 a ainsi vu apparaître la prise en charge du RISC-V sous Linux. De manière similaire, la prise en charge pré-existante pour ARM64 a été étendue pour couvrir les conventions d’appels de macOS dans OCaml 4.12.0 .
De meilleurs messages d’erreurs
Écrire des messages d’erreurs utiles est une tâche plus difficile qu’il n’y paraît. Il peut être tentant de communiquer une erreur interne sur l’implémentation ou d’évoquer une théorie avec laquelle l’utilisateur n’est pas familier. Un autre problème assez fréquent pour les erreurs de types dans OCaml est que le vérificateur de type est optimisé pour vérifier rapidement que le code est bien typé. Avec ce mode de fonctionnement, on ne découvre parfois une erreur uniquement après qu’une série de petites erreurs nous ait mené à une situation impossible.
En bref, il reste pas mal de travail à faire pour améliorer les messages d’erreurs d’OCaml. Mais cette année 2021 a vu quelques progrès intéressants, et d’autres sont déjà intégrés ou en cours d’intégration dans la version de développement d’OCaml.
Des messages d’erreurs plus détaillés pour les foncteurs
Les foncteurs sont des fonctionnalités uniques d’OCaml. Ils permettent de décrire des modules qui dépendent d’autres modules. Par exemple, la définition d’un module Graphe
peut prendre comme argument un module Sommet
et un module Arete
:
module Graphe(Sommet:SOMMET)(Arete:ARETE) = struct ... end
Je peux ensuite instancier ce foncteur avec diverses implémentations de ARETE
et SOMMET
.
Par exemple :
module Graphe_basique = Graphe(Sommet_basique)(Arete_basique)
module Graphe_colore = Graphe(Sommet_colore)(Arete_basique)
Cette formulation en termes de foncteur permet de décrire des algorithmes de graphes indépendamment de l’implémentation des arêtes ou sommets (sont-ils nommés ? colorés ?).
Avant OCaml 4.13, les erreurs liées à ces foncteurs pouvaient être très verbeuses. Par exemple, si j’applique le foncteur Graphe
avec un argument en trop :
module G = Graphe(Etiquette)(Sommet)(Arete)
Le vérificateur de type d’OCaml se plaignait que le module Etiquette n’est pas un SOMMET
, ce qui donne un message d’erreur qui ressemble à cela :
Modules do not match:
sig type t = string end
is not included in
SOMMET
The value `label' is required but not provided
The value `create' is required but not provided
The type `label' is required but not provided
The value `equal' is required but not provided
The value `hash' is required but not provided
The value `compare' is required but not provided
Avec OCaml 4.13.0, le vérificateur de type prend de la hauteur et essaye d’identifier des erreurs de haut niveau dans les erreurs liées aux foncteurs : est-ce que l’utilisateur n’aurait pas oublié un argument ? Ajouté un argument ? Modifié quelques arguments ?
Error: The functor application is ill-typed.
These arguments:
Etiquette Sommet Arete
do not match these parameters:
functor (Sommet : SOMMET)(Arete : ARETE)} ->
1. The following extra argument is provided
Etiquette : sig type t = string end
2. Module Sommet matches the expected module type SOMMET
3. Module Arete matches the expected module type ARETE
De plus en utilisant des méthodes de diffing (comparaison, généralement utilisées dans les correcteurs orthographiques ou du fuzzy searching/recherche floue), le vérificateur de type est capable de trouver une erreur la plus probable même dans des cas complexes.
Confusion entre module et module types
Un des détails surprenants d’OCaml est que beaucoup d’objets ont leur espace de noms séparé, ce qui mène parfois à des erreurs entêtantes. Par exemple :
module type M = sig type t end
type u = M.t
Error: Unbound module M
ce message en OCaml 4.10.0 semble s’obstiner à ne pas reconnaître l’existence de M
.
Le véritable problème est que M
n’est pas un module, et donc ne définit pas de types. Depuis la version 4.12.0, le message d’erreur reconnaît qu’il s’agit d’une confusion naturelle :
Error: Unbound module M
Hint: There is a module type named M, but module types are not modules
Une explication des problèmes de régularité
Parfois, les messages d’erreurs sont évidents pour leurs auteurs, et totalement obscurs sans le bon contexte.
C’était notamment le cas d’un des messages d’erreurs concernant les types récursifs non-réguliers. Si l’enchaînement des mots précédents ne vous parle pas, il y avait de grandes chances que ce message d’erreur vous laisse pantois :
type ('a,'b) x = [ `X of ('b,'a) y ]
and ('a,'b) y = [ `Y of ('a,'b) x ]
Error: In the definition of y, type ('b, 'a) x should be ('a, 'b) x
Il commet en effet trois péchés cardinaux pour un message d’erreur : il propose un correctif faux, il ne parle pas du code visible par l’utilisateur mais du résultat d’un calcul invisible du compilateur, et il ne pointe pas vers la source de l’erreur.
Ce souci est corrigé, et OCaml 4.12.0 prend désormais le temps d’expliquer le problème :
Error: This recursive type is not regular.
The type constructor x is defined as
type ('a, 'b) x
but it is used as
('b, 'a) x
after the following expansion(s):
('b, 'a) y = [ `Y of ('b, 'a) x ]
All uses need to match the definition for the recursive type to be regular.
Le message d’erreur est long. Cependant il explique non seulement la nature du problème (un type paramétré est utilisé de façon différente au sein d’un même groupe de définition récursif) mais aussi comment le vérificateur de type a découvert l’erreur.
Améliorations de l’expérience utilisateur
Il y a aussi beaucoup d’améliorations de taille plus modeste qui sont plus difficiles à catégoriser.
Parmi celles qui ont retenu mon attention sur ces deux dernières versions, je peux citer :
Statmemprof : profiler la mémoire sur des programmes en production.
Pour des langages à glaneur de cellules (GC) comme OCaml, l’allocation et la désallocation de mémoire est un axe à la fois important et assez invisible de la performance des programmes. Il peut donc être important de surveiller le travail du GC dans un programme pour évaluer des problèmes de performances, ou s’assurer qu’il n’y ait pas de fuite de mémoire dans un serveur tournant durant des années.
Dans les versions d’OCaml antérieures à 4.12, la bibliothèque Spacetime fournissait de tels outils de surveillance en continu de la mémoire.
Cependant analyser le travail du GC peut-être extrêmement coûteux aussi bien en termes de temps que d’espace. Et il était pratiquement impossible d’utiliser Spacetime dans un environnement de production à cause de ces coûts.
Statmemprof est une réponse à ces problématiques : il s’agit d’un outil de profilage statistique de l’allocation et de la désallocation de la mémoire. En s’autorisant à n’analyser qu’une partie des allocations et des désallocations, il devient possible de contrôler le coût de cette analyse de la mémoire et de la rendre négligeable. Intégrer cette analyse dans du code en production devient alors possible. On peut même s’autoriser à ajuster le comportement du programme en fonction de sa consommation mémoire actuelle.
Des noms pour les warnings
Après 25 ans d’existence, OCaml a accumulé plusieurs dizaines d’avertissements (70 dans la version 4.13.0). Fort heureusement, la configuration de ces avertissements est souvent laissée soit au compilateur soit au système d’assemblage. Notamment, dune
, le système d’assemblage de prédilection de la plupart des paquets opam, a un choix d’avertissements assez strict par défaut.
Il reste néanmoins pratique de pouvoir modifier cette configuration pour un fichier ou une fonction spécifique. Par exemple, on peut activer le warning 27
pour juste la fonction f
avec :
let f x = () [@@warning "+27"]
Cependant, à la lecture, il n’est pas exactement évident de se rappeler l’objet de cet avertissement 27
. Cela d’autant plus lorsque l’avertissement est utilisé ponctuellement. La nouvelle mouture d’OCaml permet enfin de nommer ces avertissements :
let f x = () [@@warning "+unused-var-strict"]
Et la Stdlib s’agrandit
La bibliothèque standard voit arriver deux nouveaux modules liés aux threads :
-
Atomic
: ce module est là pour préparer en douceur la compatibilité avec le runtime multi-cœur.-
Thread.Semaphore
: ce module offre une contrepartie auMutex
qui n’a pas besoin d’être verrouillé et déverrouillé dans le même fil d’exécution.
-
et un nouveau module de structure de données :
-
Either
: il s’agit d’un module d’alternative générique (on a soit unLeft a
soit unRight b
) qui est utile lorsque nommer explicitement les deux alternatives serait pénible.
Fut un temps, la bibliothèque standard d’OCaml avait pour objectif de rester assez minimaliste. Ce choix a engendré la création d’au moins quatre bibliothèques étendant la bibliothèque standard (extlib, batteries, base, containers). Cependant depuis, OCaml 4.07 la bibliothèque standard s’est ouverte à plus d’améliorations. Néanmoins, l’évolution de la bibliothèque standard reste basée sur un principe de quasi-unanimité, son rythme d’évolution reste donc très mesuré.
Des piles d’appels plus expressives
Lorsque qu’une fonction lève une exception qui n’est pas attrapée, la pile d’appel (backtrace) contient désormais des informations sur les noms des fonctions qui se sont retrouvées sur la pile d’appel. Par exemple exécuter :
let () =
let f () =
let g () = raise Exit in
fun () -> g ()
in
f () ()
nous informe que
Raised at Backtrace_example.f.g in file "backtrace_example.ml" (inlined), line 3, characters 16-26
plutôt que le laconique
Raised at file "backtrace_example.ml" (inlined), line 3, characters 16-26
Plus de types pour les utilisateurs experts
Le système s’est aussi enrichi de fonctionnalités plus orientées vers les auteurs de bibliothèques, et les utilisateurs experts.
Des noms pour les types existentiels
Les types existentiels sont une des fonctionnalités nouvelles apportées par les Types de Données Algébriques Généralisés (GADTs). Pour faire simple, il s’agit de types qui n’existent qu’à l’intérieur d’un constructeur.
Par exemple, je peux décrire une pipeline de transformation de 'a
vers b
en plusieurs étapes :
type ('entree,'sortie) pipeline =
| Vide: ('entree,'entree) pipeline
| Etape: ('entree,'intermediaire) pipeline * ('intermediaire -> 'sortie)
-> ('entree,'sortie) pipeline
Ici le constructeur Etape
prend comme argument un pipeline de entree
vers un type intermediaire
, et une fonction de ce type intermediaire
vers le type sortie
et me donne en retour un pipeline de l’entrée vers la sortie.
Le point intéressant avec définition est que ce type intermédiaire n’est pas un type concret connu. Il s’agit d’un type inconnu dont je sais seulement qu’il est partagé par ma pipeline interne, et ma fonction de transformation.
Une bonne façon de voir comment ce type se comporte est d’implémenter une fonction envoyer
qui applique toutes les étapes de la pipeline à une entrée et obtient une sortie.
let rec envoyer: type entree sortie. (entree,sortie) pipeline -> entree -> sortie =
fun pipeline entree ->
match pipeline with
| Vide -> entree
| Etape(pipeline_interne, transformation_finale) ->
entree |> envoyer pipeline_interne |> transformation_finale
(* [x |> f] signifie [f x] *)
Ici, tout ce passe bien. Mais que se passe-t-il si j’essaye d’appliquer la transformation finale avant le reste de la pipeline ?
let rec envoyer_erronee: type entree sortie. (entree,sortie) pipeline -> entree -> sortie =
fun pipeline entree ->
match pipeline with
| Vide -> entree
| Etape(pipeline_interne, transformation_finale) ->
entree |> transformation_finale |> envoyer pipeline_interne
J’obtiens une erreur de compilation qui se plaint que le type de entree
n’est pas le bon :
Error: This expression has type entree but an expression was expected of type
$Etape_'intermediaire
Et en effet, le code est faux parce que le type entree
ne correspond pas au type attendu par la transformation finale. Le nom du type attendu $Etape_'intermediaire
est cependant assez complexe.
Il s’agit d’un nom automatiquement généré pour un type existentiel à partir de la définition de type et du constructeur qui l’a introduit. Ici le nom est assez clair, mais dans des cas complexes ces noms générés automatiquement peuvent être difficiles à déchiffrer. Une des nouveautés dans 4.13.0 est qu’il est désormais possible de nommer soi-même les types existentiels introduits dans le filtrage de motif:
let rec envoyer_erronee: type entree sortie. (entree,sortie) pipeline -> entree -> sortie =
fun pipeline entree ->
match pipeline with
| Vide -> entree
| Etape (type intermediaire)
(pipeline_interne, transformation_finale:
(entree, intermediaire) pipeline * (intermediaire -> sortie)
) ->
entree |> transformation_finale |> envoyer pipeline_interne
Cette fois-ci, le message d’erreur utilise notre nom de type :
Error: This expression has type entree but an expression was expected of type
intermediaire
Ce qui devrait réduire légèrement le temps passé à faire compiler du code utilisant fortement les GADT. Cette notation permet aussi d’obtenir facilement le type abstrait correspondant au type existentiel pour lequel il y a des applications plus élaborées.
De l’injectivité pour vos types
Les bibliothèques vont pouvoir ajouter des points d’exclamation à leurs types
type !'a vec
pour indiquer que le paramètre 'a
est vraiment utilisé dans le type et n’est pas un type fantôme.
Cela permet de débloquer certains usages avancés des GADT où il est vital de savoir si int vec
et forcément différent de float vec
.
Par exemple, avec cette annotation, le vérificateur de type sait qu’avec la définition suivante :
type _ int_or_float_vec =
| Int_vec : int vec -> int vec int_or_float_vec
| Float_vec: float vec -> float vec int_or_float_vec
lorsqu’on a une valeur de type 'a int_or_float_vec
, la variable 'a
est forcément soit int vec
soit float vec
. En d’autres mots, on ne peut jamais se procurer une valeur de type char int_or_float_vec
:
let impossible: char int_or_float_vec -> _ = function _ -> .
Sans cette annotation, le vérificateur de type ne peut éliminer la possibilité que le type 'a vec
ait été défini en tant que synonyme de char
:
type 'a vec = char
Comme pour les annotations de variances, l’injectivité est automatiquement inférée pour les types non-abstraits. Ces annotations sont donc essentiellement là pour les auteurs de bibliothèque.
Au-delà d’OCaml multi-cœur
Si l’implémentation d’OCaml multi-cœur se rapproche lentement mais inexorablement, les plans pour le futur d’OCaml ne s’arrêtent pas là.
En particulier, la gestion de la concurrence et du parallélisme sera à terme basée sur un système d’effets. La prochaine étape de ce côté sera de concevoir et déployer un système d’effets typés facile à utiliser en pratique.
Mais le développement d’OCaml 5 ne se concentrera pas uniquement sur l’aspect multi-cœur. Une des forces d’OCaml est son système de modules à la fois expressif et adapté à la compilation séparée. Cependant, cette puissance a un prix, et les usages avancés du système de modules peuvent être particulièrement lourds syntaxiquement. Un des projets en cours pour OCaml 5 est d’introduire des méthodes plus légères pour décrire des fonctions paramétrées par des modules, à travers un système de foncteurs légers et implicites.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Au cœur de l'April — Émission « Libre à vous ! » du 14 septembre 2021 — Podcasts et références
LinuxFr.org : les dépêches par Frederic Couchet le 23/09/2021 à 22:40:00 - Favoriser || Lu/Non lu
Cent-quatorzième émission « Libre à vous ! » de l’April. Podcast et programme :
- sujet principal : « Au cœur de l'April et de Libre à vous ! ». Nous avons de l'April, de certaines de nos actions, des coulisses de l'émission…
- la chronique « Le libre fait sa comm' » d'Isabella Vanni, coordinatrice vie associative et responsable projets à l'April, animatrice du groupe Sensibilisation. Isabella a échangé avec Marie Seiller de la Fête des Possibles
- la chronique « Que libérer d'autre que du logiciel » sur la rentrée d'Antanak
- lien nᵒ 1 : Radio Cause Commune
- lien nᵒ 2 : Libre à vous !
- lien nᵒ 3 : Podcast de la 114ᵉ émission
- lien nᵒ 4 : Les références pour la 114ᵉ émission et les podcasts par sujets
- lien nᵒ 5 : S'abonner au podcast
- lien nᵒ 6 : S'abonner à la lettre d'actus
Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 MHz en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.
Vous pouvez laisser un message sur le répondeur de la radio, pour réagir à l’un des sujets de l’émission ou poser une question. Le numéro du répondeur : +33 9 72 51 55 46.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Rapport Latombe — Émission « Libre à vous ! » du 7 septembre 2021 - Podcasts et références
LinuxFr.org : les dépêches par Etienne Gonnu le 21/09/2021 à 19:00:00 - Favoriser || Lu/Non lu
Cent-treizième émission « Libre à vous ! » de l’April, la première émission de cette saison 5. Podcast et programme :
- sujet principal : sujet principal : échange avec Philippe Latombe, député et auteur d'un rapport d'information sur le thème « Bâtir et promouvoir une souveraineté numérique nationale et européenne » dont une des propositions est d'imposer au sein de l’administration le recours systématique au logiciel libre. Une prise de position que l'April a saluée.
- la chronique « Pépites libres » de Jean-Christophe Becquet à propos de « Nos algorithmes », le site qui montre que l'éthique des algorithmes publics n'est pas une question binaire.
- la chronique « À cœur vaillant, la voie est libre » de Laurent et Lorette Costy sur le thème des navigateurs Internet. Une chronique intitulée : « les grands navigateurs »
Vous pouvez laisser un message sur le répondeur de la radio, pour réagir à l’un des sujets de l’émission ou poser une question. Le numéro du répondeur : +33 9 72 51 55 46.
Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 FM en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.
- lien nᵒ 1 : Radio Cause Commune
- lien nᵒ 2 : Libre à vous !
- lien nᵒ 3 : Podcast de l'émission
- lien nᵒ 4 : Les références pour l'émission et les podcasts par sujets
- lien nᵒ 5 : La transcription de l'émission
- lien nᵒ 6 : S'abonner au podcast
- lien nᵒ 7 : S'abonner à la lettre d'actus
- lien nᵒ 8 : Photos de l'émission
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Interview : Cédric Gémy, graphiste, formateur, développeur sur logiciels libres
LinuxFr.org : les dépêches par Ysabeau le 20/09/2021 à 08:34:00 - Favoriser || Lu/Non lu
En 1996, Cédric Gémy devient maître Arts plastiques et découvre (et installe) Linux. Il s’investit très tôt dans le numérique côté création et fait partie des gens qui ont porté Inkscape sur les fonts baptismaux. Il écrit, d’ailleurs, pour les éditions Eyrolles Inkscape efficace en 2009 et Scribus 1.4 en 2012. Cédric Gémy est donc tout à la fois graphiste, formateur et développeur sur les logiciels libres du domaine de l’image numérique (Gimp, Inkscape, Blender) et de l’édition (Scribus).
Au cours de cette interview, dont l’idée a été inspirée dans les commentaires de cette dépêche, il répond à des questions qui se sont posées dans des commentaires de cette autre dépêche.
- lien nᵒ 1 : Activdesign, centre de formation logiciels libres pour les métiers de la création
- lien nᵒ 2 : Activstudio, prestations de graphisme et de développement
- lien nᵒ 3 : ATI, formation universitaire à l’image de synthèse
Sommaire
- Parcours
- Position de Gimp, Krita, Inkscape et Scribus par rapport à ceux d’Adobe
- Formations sur Gimp, Krita, Inkscape et Scribus
- Blender
- Pour finir
Parcours
Quelle est votre formation initiale ?
J’ai fait des études d’art à l’Université Rennes 2. J’y ai obtenu une maîtrise en Arts plastiques en 1996. J’ai ensuite fait un master en sciences de l’éducation en 2008 pour améliorer la qualité de mes services sur l’aspect formation à Gimp, Inkscape ou Scribus, qui se développait alors.
Comment, avec une formation artistique devient-on développeur ?
C’est vraiment une vaste question. En fait, je n’ai pas vraiment l’impression d’être un réel développeur. Mon point de vue est que l’artiste doit être en mesure de créer. Pour cela, on peut se limiter à ce que fournissent des logiciels et combiner, ou alors prendre à bras-le-corps le fait qu’on puisse les adapter à ses propres besoins. Programmer, c’est intégrer l’outil informatique dans son process de création, comme les peintres d’antan cherchaient à fabriquer les plus belles couleurs à partir de matières premières.
D’un autre côté, la fin des années 1990 et le début des années 2000 a marqué l’avènement du web. Les graphistes sont apparus et l’exigence de compétences techniques « informaticiennes», par exemple en CSS. J’ai fait mon premier site web en 1998. C’était une revue artistique locale. Et je me suis éclaté à l’époque à travailler avec les artistes sur lesquels on écrivait pour tenter de créer des expériences en ligne. Avec le recul, je me dis que ce n’était pas top, mais c’était une époque géniale où on pouvait tout tester.
Qu’est-ce qui a été à l’origine de votre investissement dans les logiciels libres de la sphère graphique et visuelle ?
C’est passé par plein de choses. Les deux logiciels auxquels je me suis d’abord intéressé et auxquels j’ai contribué ont été Gimp et Blender, avec mes compétences spécifiques. Mais ma première installation d’un Linux remonte à la Redhat 5.1 achetée en boutique (et oui, on n’avait pas internet à la maison). C’était en 1996. Donc bien avant Gimp. Après avoir passé au moins deux jours à l’installer, j’y ai trouvé des tonnes d’outils de création dans de nombreux domaines. On les dirait non-aboutis, mais ce n’est pas ça qui compte, mais plutôt la capacité d’exploiter le potentiel qu’ils offrent. Ce n’est pas parce que j’utiliserai le pinceau de Picasso que j’aurai sa qualité artistique. Chaque outil nous questionne à sa façon.
Pour rappel, même un Windows avec ses quatorze ou quinze disquettes prenait des heures à installer. On l’a oublié, donc je ne voudrais pas qu’on pense que je trouve que les logiciels libres ne sont pas pratiques. D’ailleurs, je n’utilise que du libre depuis 2004.
En tant que membre fondateur d’Inkscape, pourriez-vous nous dire deux mots sur les débuts de ce fabuleux logiciel de dessin vectoriel ?
Le terme « fondateur» est peut-être un peu fort, je l’utilise parfois pour simplifier, mais inexactement. Je suis plutôt un témoin direct. En réalité, j’étais le contributeur principal à la documentation officielle de Sodipodi1. Quand certains membres de l’équipe ont voulu faire un dérivé, je me suis posé beaucoup de questions. Sodipodi a installé le SVG comme format et une ergonomie assez moderne basée sur GTK. Mais il n’y avait pas de vision à long terme.
Les discussions qui ont conduit à Inkscape parlaient d’une véritable stratégie basée sur le SVG comme format d’avenir. Elles parlaient de création de bibliothèques partageables entre logiciels, et d’implémentation de la recommandation. Cela laissait entrevoir un flux de production plus homogène. Il y avait des personnes incroyables avec des idées et une énergie débordante. Je les ai donc en quelque sorte « suivies » parce que j’étais là le jour de la naissance. Mais je me souviens de moments forts que de discussion sur le logo. Ça devait être mon côté graphiste.
Moi qui devais encore coder beaucoup d’éléments SVG à la main (eh oui ! c’était comme ça avant), j’imaginai déjà les trucs de fous que je pourrai faire :-)
Position de Gimp, Krita, Inkscape et Scribus par rapport à ceux d’Adobe
On reproche encore souvent à ces trois logiciels, notamment Gimp, Inkscape et Scribus de ne pas être suffisamment professionnels, qu’en est-il réellement ?
De mon point de vue, ce ne sont pas les logiciels qui sont professionnels, mais les personnes. Vous pouvez mettre le meilleur logiciel dans les mains de quelqu’un qui ne sait pas dessiner, je pense qu’il en fera peu de choses. Et je connais des artistes qui restent aux bons vieux pinceaux, crayons et qui font des trucs géniaux. Ça fait partie d’un discours progressiste et élitiste, mais qui témoigne de mon point de vue plutôt de la peur d’une perte de reconnaissance de ces personnes. Elles identifient leur travail à leur outil. Par conséquent, remettre en cause leur outil, c’est remettre en cause leurs compétences.
Mais on ne demande pas à l’électricien quelle est la marque de ses tournevis ! Ni aux charpentiers celle de ses scies et marteaux.
Évidemment, dans certains cas il y a des contraintes que le logiciel doit être capable de prendre en charge. Mais l’erreur que font les amateurs de produits concurrents et privateurs est d’essayer les logiciels libres comme s’ils devaient fonctionner à l’identique. Dans ce contexte, et ne prenant pas en compte les différences, ils ne voient que des défauts. Citons deux exemples.
Le fameux CMJN dans GIMP : depuis le début des années 2000, Adobe et d’autres grands acteurs du graphisme ont tenté d’imposer un flux de travail RVB. Pourquoi cela ? Parce le RVB permet une représentation plus riche de la gamme de couleurs que le CMJN. Dans ce principe, la conversion quadrichromique doit intervenir le plus tard possible dans le processus, donc au moment de l’impression. Pour arriver à cela, les profils colorimétriques ont été mis en place. Gimp les a gérés très très tôt. Le problème est donc venu des utilisateurs, qui, pour certains, n’ont pas révisé leurs pratiques. Et cela dure encore.
Deuxième exemple, j’ai lu une fois un article d’un graphiste, vers 2010 je crois, qui mentionnait avoir mis toute sa volonté à vouloir tester Inkscape et de le lire dire qu’il a tout de suite compris que ce n’était pas un logiciel professionnel parce qu’il ne pouvait pas ouvrir les fichiers EPS. Je lui ai rétorqué qu’Inkscape se voyait comme un éditeur SVG et pas un éditeur Postscript. Il m’a répondu que dans son métier, ce n’était pas possible de se passer de l’EPS. Sachant que le PDF a été créé en 1993, Adobe a officiellement abandonné Postscript à son profit en 2001.
On est souvent sur des critiques qui sont biaisées parce que les bases sont mauvaises. D’une certaine façon ce n’est pas grave, chacun est libre d’utiliser le logiciel qu’il souhaite. Celui qui décide du professionnalisme, de mon point de vue, c’est le client. Si on a fait ce qui lui correspond alors, le travail est fait. Quels que soient les moyens utilisés. Je pense que ce qu’apporte le logiciel libre, en dehors des libertés, c’est surtout un questionnement sur les outils et de notre relation à eux. Et ça, il me semble que c’est fondamental.
Quels sont les points forts de chacun de ces logiciels (indépendamment du fait que ce sont des logiciels libres) ?
C’est difficile à dire, tous les logiciels ont des points forts et des points faibles. Sans rentrer dans les détails, ils partagent un certain nombre de points communs. Par exemple, ils sont tous super-légers. Blender fait 250Mo, Inkscape ou Gimp environ pareil. Prenez un équivalent Adobe vous multipliez au moins par vingt (désolé de l’approximation, ça c’est les chiffres de 2004, je n’ai pas réutilisé depuis).
Si on prend Inkscape, on n’imagine pas le nombre de choses qu’il a implémenté avant Illustrator : par exemple, un truc bête comme les arrondis pour les rectangles, ou les dégradés éditables directement sur le canevas dès les premières versions. Mais pardon, tout cela n’est pas utile aux professionnels. Ne parlons pas des outils orientés typographies qui ont permis FontLibrary et par extension, Google Fonts. Que serait le web sans cela ! Plus récemment, le fait d’avoir un véritable éditeur CSS, c’est juste incroyable pour l’édition.
Dans Scribus, le fait d’avoir des options pour gérer automatiquement les conversions d’image, leur compression à l’export, ça aussi c’était franchement en avance. Il peut d’ailleurs ouvrir des fichiers de Publisher, d’InDesign, voire, les PDF eux-mêmes. C’est le seul que je connaisse à faire ça, même si ça reste perfectible. Tout comme la prise en charge de langue non latine… mais cela ne compte certainement pas assez vu de chez nous, mais ça permet à des quelques milliards de personnes d’écrire dans leur langue correctement.
Je n’ose même plus parler de Blender. Depuis la 2.8, tous les nouveaux disent que la nouvelle ergonomie est géniale, et qu’il a fait un bond, alors qu’en fait, quasiment rien de fondamental n’a changé à part le clic droit.
Quels sont les points faibles par rapport à ceux de la concurrence et comment cela peut-il être contourné (en admettant que cela soit nécessaire) ?
Bien sûr qu’il y a des points faibles. Une fois encore, ça dépend des logiciels, mais aussi des besoins spécifiques. Un logiciel comme Inkscape est utilisé par de nombreux corps de métiers, c’est donc bête de vouloir prendre uniquement le point de vue du graphiste, comme s’il devait être la grille d’analyse de tout.
Cependant, ce qu’on retrouve assez généralement est un manque de jusqu’au-boutisme dans la pensée des processus de production. Il manque des fois peu de choses pour réellement simplifier la vie. Ce n’est pas nécessairement un problème d’ergonomie, comme on le résume souvent, mais de vision globale d’un cas d’usage.
Ce que l’on regrette chez certains logiciels c’est aussi parfois l’impression que ça n’avance pas. Je ne parle pas d’Inkscape, ou de Blender ou d’autres qui ont un rythme rapide et des notes de version à rallonge. Gimp ou Scribus, sont les représentants de la catégorie de logiciels qui peinent. Chacun pour des raisons différentes, et peut-être à cause de leur succès, les gens imaginent qu’il y a des tonnes de contributeurs de contributrices comme il y a des tonnes d’utilisateurs et d’utilisatrices. Et c’est malheureusement loin d’être le cas. L’intérêt de cela est qu’on ne va pas vers une course à la fonction qui conduit à des logiciels lourds, gourmands en énergie, difficilement installables sur des machines qui ont plus de quatre ans.
Si on ne se voile pas la face, on trouve des solutions à tous les problèmes, c’est même une partie de la créativité qui est là-dedans. Je trouve même que c’est la partie intéressante, c’est elle qui nous fait voir les personnes avec qui nous échangeons et travaillons comme des humains avec qui nous devons nous organiser. Quels que soient les défauts qu’on puisse voir aux logiciels libres, je pense que leur valeur sociale dépasse largement leurs défauts. Ça me semble important de tout prendre en compte.
Pour quelle raison choisirait-on Gimp plutôt que Krita et inversement ?
Personnellement, j’ai été tellement habitué à Gimp que j’ai gardé ça. Je suis comme tout le monde, j’ai du mal à changer. Je le trouve toujours d’actualité parce qu’il est léger, rapide au lancement, et quand on lance le logiciel plusieurs fois par jour, on n’a pas envie d’attendre de trop. Il demande un peu plus de configuration que Krita, mais pour moi ça fait partie du boulot et de l’adaptation du logiciel à mon flux. Disons que Gimp exige d’avoir plus rapidement ce questionnement qui en gêne certains.
Krita a ma préférence pour ses calques non destructifs, et je pense qu’il est pratique pour les débutants en dessin, parce qu’il a de nombreuses brosses préconfigurées. D’une certaine façon, il ressemble plus à Photoshop, ce qui n’est pas une qualité pour moi parce que je préfère largement l’ergonomie de Gimp à celle de Photoshop (même si je regrette qu’ils aient appliqué la nouvelle organisation des icônes de boite à outils justement parce que c’était pour moi un plus de Gimp).
Je pense que les personnes qui veulent s’y essayer doivent réellement prendre le temps. Personnellement, quand je me demande si j’intègre un nouveau logiciel dans mon flux de production, je le teste pendant au moins un an, pour voir ce qu’il va apporter et trouver sa meilleure place dans mon travail. Je ne considère pas qu’on doive avoir un logiciel à tout faire (à part Emacs, mais je doute que ces modes artistiques conviennent aux graphistes, peut être plus aux artistes).
Formations sur Gimp, Krita, Inkscape et Scribus
Qui sont les personnes qui viennent pour suivre des formations à ces logiciels ? Savez-vous si elles continuent à utiliser les logiciels après la formation ?
Le public est très varié. On trouve des communicants, quelques graphistes en devenir intéressés par le libre qui souhaitent migrer, mais aussi des personnels et agents territoriaux voire de grands groupes qui en ont besoin pour des travaux divers. Inkscape, en particulier, s’adapte à de nombreux secteurs : cartes météo, plans de vols, plans de salons, affiches et flyer, logos, illustrations, préparation à la découpe laser ou vinyle, maquettes web, graphisme de jeux…
Avez-vous constaté des changements dans les demandes de formation depuis que les logiciels d’Adobe sont sur abonnement ?
En effet, quand Adobe est passé à ce système, on a eu pas mal de personnes que ça a fait réfléchir. Mais cela a surtout été le cas au début. C’est maintenant un peu retombé, je pense que les gens se sont habitués à tout payer par abonnement.
Que faut-il attendre d’une formation à Gimp, Inkscape et Scribus ? (cf à ce sujet)
Ce sont des logiciels qui ont un nom. Par conséquent, beaucoup de centres de formation les ont ajoutés à leur programme. Je retrouve d’ailleurs souvent mes vieux programmes Blender obsolètes sur d’autres sites :-)
Je trouve cela positif parce que ça permet tout de même à chacun de trouver une formation proche de chez soi. Avant, j’étais souvent contraint de faire de longs trajets pour former les gens dans toute la France parce qu’ils ne trouvaient personne. Ça renchérissait aussi le cout de la formation.
D’un autre côté, comme en témoigne Ysabeau, les centres de formation n’ont pas toujours un formateur compétent sous la main. Je me souviens une fois caractéristique où un centre m’avait demandé de venir pour former une personne. Au cours des discussions, elle me remercie. Ce n’est pas fréquent alors je lui ai demandé pourquoi. Elle m’a alors avoué qu’elle avait déjà fait une formation Scribus dans un centre. Quand elle posait une question, le formateur disait souvent que ce n’était pas possible, alors qu’elle avait déjà lu des livres sur le sujet et savait que ça l’était.
En tant que formateur et utilisateur, on ne peut tout connaître. Moi-même je n’utilise plus les produits privateurs depuis dix-sept ans, j’ai donc toujours de la peine à faire des comparaisons. Mais placer des formateurs qui vont dévaloriser les logiciels pour se protéger eux-mêmes, c’est vraiment ce qu’il y a de pire pour les logiciels libres.
Savez-vous s’il existe des formations initiales dans la sphère graphique qui intègrent Gimp, Inkscape et Scribus ?
En fait, les logiciels libres sont intégrés depuis longtemps dans divers cursus universitaires ou supérieurs. J’ai formé des géographes, biologistes, éducateurs… dans diverses régions françaises. De ce point de vue, de nombreux logiciels ont percé, et pas seulement les trois mentionnés.
Dans les formations dédiées spécifiquement aux métiers de graphisme, c’est un peu plus compliqué de trouver. La licence Colibre, à Lyon 2 dédiée aux communicants, existe depuis presque quinze ans. Elle a une longue expérience dans le domaine et de nombreux étudiants sortis de là ont adopté définitivement les logiciels libres.
Dans le privé, notre centre de formation Activdesign est spécialisé depuis 2011 dans les métiers du graphisme libre. On étend peu à peu la gamme, après avoir commencé avec le print2 (graphic design) et le web. Nous avons commencé cette rentrée avec plus de cinquante inscrits avec une forte proportion de demandes en jeux vidéos et illustrateurs.
Il y a certaines écoles qui passent peu à peu à des technologies libres, par exemple ATI à Paris 8.
J’ai été contacté récemment par un grand groupe qui a de nombreux campus conduisant à des BTS communication. Leur approche n’est généralement pas libriste, elle est avant tout économique : ils veulent se passer du coût des licences. Une fois encore, l’avantage est que ça diffusera les logiciels, mais si c’est sans prise de conscience des licences, on se retrouvera avec beaucoup de personnes consuméristes qui auront surtout des exigences et peu d’apports pour la communauté, ce qui peut être dangereux à terme.
Blender
Comment peut-on situer Blender dans la sphère professionnelle par rapport à ses équivalents ?
Personnellement, j’utilise Blender depuis qu’il est libre. J’avais financé son premier manuel, j’avais contribué et nous avions été sponsor de Cosmos Laundromat3 parce que nous avons cru en son modèle de développement. J’utilisais auparavant 3dstudio. J’ai toujours trouvé Blender supérieur en ergonomie et en capacité. De mon point de vue, la 2.8 ne change rien, il reste le meilleur. Sauf qu’on a perdu le moteur de jeu :-(
En 2018-2019, l’Afdas4 avait fait une enquête auprès des studios d’animation pour savoir quel logiciel ils utilisaient et dans quelle partie de la production. J’avais fait mon propre calcul à partir de leurs chiffres : Blender ressortait second avec un total de 75 points derrière Autodesk Maya à 85. 3ds Max était à 32. Et ça, c’était avant la 2.8.
De plus, Blender est ultra productif en particulier grâce à son utilisation importante de raccourcis clavier. Si beaucoup de gens passent à Blender parce qu’il a maintenant de belles icônes, c’est un peu louper l’essentiel.
Je pense donc qu’il est bien placé, assurément, de source « officielle» et neutre.
Pour quelles raisons (hormis le fait que c’est un logiciel libre) on utiliserait de préférence Blender dans le cadre d’un film par exemple ?
Blender a ceci de formidable qu’il couvre presque la quasi-totalité du flux de production. Vous pouvez y faire votre storyboard, l’animer, le passer en 3D, faire les rendus, un peu de post-production et le montage final. Sur certains points, d’autres logiciels seront plus performants, mais c’est le seul à presque tout faire, et à le faire bien. Même sur les tâches courantes, il possède des options intéressantes qui n’ont pas d’équivalents, mais qui vont évidemment être copiées. Il est homogène, entièrement scriptable, ce qui est essentiel dans des productions industrielles, parce que, si on doit rendre chaque scène à la main on ne s’en sort pas.
Lorsqu’on a écrit Blender pour le jeu vidéo, ou Blender pour le montage vidéo, beaucoup de gens nous ont beaucoup dit que ce n’était pas fait pour ça. Ton Roosendaal5 lui-même. Mais finalement, lorsqu’en conférence en 2019 il a annoncé qu’il comptait enlever le Video Sequencer6 et qu’il a fait un sondage immédiat dans la salle, la moitié a levé la main pour dire qu’ils l’utilisaient et voulait le garder.
Est-ce que la demande de formation suit les évolutions de Blender ?
Plus ou moins, on voit des regains d’intérêt lorsqu’il y a des évolutions ou des sorties de version, mais on est souvent sur des formations de prise en main ou de migration. En général, les personnes qui ont déjà une grande expérience de la 3D n’ont pas de difficulté à passer à Blender, elles doivent juste regagner en productivité. Et là-dessus, Blender est très fort.
Que savez-vous et que pensez-vous de l’offre en formation sur Blender ?
Elle est très disparate, mais c’est certainement la plus riche du secteur du graphisme libre. De nombreux corps de métiers utilisent la 3D, y compris dans l’ingénierie… J’ai formé par exemple des salariés de grand groupe pour des simulations d’implantation d’éolienne, des architectes ou décorateurs…
Il y a donc de nombreux centres de formation qui ont régulièrement des propositions.
La qualité des formateurs et des formatrices y semble plus fiable en général que celle qu’on va avoir sur Scribus, Krita ou Inkscape.
Pour finir
Au niveau professionnel, quels autres logiciels libres utilisez-vous, sur quel OS ? Question subsidiaire si les formations se font sur Linux, est-ce que ça pose un problème quelconque aux stagiaires ?
À Activdesign, nous n’utilisons que du libre que ce soit pour l’école ou le studio. On a notre préférence pour Debian, mais on a aussi de l’Ubuntu et du Mageia selon le support de notre matériel.
De fait, on utilise principalement les logiciels principaux, mais ça peut aussi parfois être Darktable, Digikam, Luminance HDR, PDFSam, Godot Engine, ou des outils en ligne de commande.
Les gens s’habituent à être sur du libre. Certains sont un peu perdus au début, mais en vrai une fois qu’on est dans le logiciel ça ne change pas grand-chose. Et puis, depuis que Windows utilise un lanceur textuel, finalement ça se comporte comme un Linux :-) donc, ils sont moins perdus maintenant qu’avant.
Nos étudiants en formation longue ont le choix. Ils peuvent venir avec leurs ordinateurs et rester sous Windows. On en a même un qui a fait un jeu avec Unity l’an dernier. On n’est pas fermé, et on aide chacun comme on peut à progresser dans sa voie. Mais plusieurs ont migré à Linux, ou n’utilisent que du libre avec Windows.
Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?
Personnellement, même si j’ai commencé sur une Redhat, je suis passé à Debian et ça me va bien. Je ne suis pas nécessairement à la recherche de la distribution parfaite. Debian est un bon compromis entre un bureau simple grâce à Gnome et des outils système performants avec une grande panoplie de paquets. On a juste des soucis quand on doit passer sur des ordis à carte NVIDIA ce qui arrive malheureusement avec Blender.
Dans ce cas, on passe sur d’autres comme Ubuntu ou Mageia, ou encore Librazik, mais ça fait déjà deux dérivés de Debian.
En fait, Blender et Codium7 sont mes Emacs à moi :-). Tant qu’ils tournent, tout est possible. Mais j’adore Inkscape et aussi Darktable, mais je fais peu de photo en ce moment.
Quelle question auriez-vous détesté qu’on vous pose ? (en espérant que je ne vous l’ai pas posée).
Est-ce qu’on est vraiment un professionnel quand on n’utilise pas des outils « habituels» ?
C’est la question qui m’énerve. Comme si la compétence était dans le logiciel. Personnellement, mes études artistiques m’amènent à concevoir la création comme un chemin de recherche, plutôt qu’un résultat. C’est évidemment un peu différent lorsqu’on travaille pour un client, souvent le risque est enterré très tôt. Mais je pense que les deux ne s’excluent pas. Et c’est souvent en se mettant en difficulté qu’on va trouver de nouvelles pistes. Il faut garder l’esprit d’expérimentation, pas pour se dire qu’on va révolutionner le monde, mais juste pour garder la flamme et ne pas devenir une machine humaine qui répète les mêmes tâches quotidiennement sans réfléchir.
Merci beaucoup Cédric.
-
[N.D.M.] : Sodipodi était un logiciel libre de dessin vectoriel. ↩
-
[N.D.M.] : print, dans le jargon, désignel comme on s’en doutaitl la production imprimée par rapport au numérique. ↩
-
[N.D.M.] : court-métrage d’animation néerlandais. ↩
-
[N.D.M.] : l’Afdas est un organisme français qui collecte les fonds de la formation continue. C’est, notamment, l’« opérateur de compétences » (OPCO) des secteurs de la culture, des industries créatives, des médias, de la communication, etc. Les logiciels dont il est question dans cette étude sont des logiciels de modélisation et de rendu 3D. ↩
-
[N.D.M.] : Ton Roosendal est un développeur de logiciels et producteur de film néerlandais. Il est aussi le créateur de Blender. ↩
-
[N.D.M.] : le Video Sequencer (EN) est un outil de Blender utilisé pour le travail des vidéos. ↩
-
[N.D.M.] : Codium, ou Visual Studio Codium, est un éditeur de code. ↩
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Premier coup d'œil à SailfishOS 4.2.0 (Verla)
LinuxFr.org : les dépêches par cartron le 16/09/2021 à 10:34:00 - Favoriser || Lu/Non lu
L’entreprise de téléphonie mobile finlandaise Jolla vient de mettre à la disposition des abonnés au programme « Early Access » la deuxième version de son système d'exploitation pour ordiphone SailfishOS OS 4.2.0. Regardons les nouveautés de Verla puisque c’est le nom de cette version !
Comme d'habitude, je me concentre sur les nouvelles fonctionnalités et les améliorations, et couvre également des sujets spécifiques au Sony Xperia 10 II que j'utilise au quotidien.
- lien nᵒ 1 : SailfishOS
Verla ?
D'après Wikipedia :
Verla est une ancienne usine de traitement du bois et de carton située près de Jaala, au sud-est de la Finlande. Elle est inscrite depuis 1996 sur la liste du patrimoine mondial de l'UNESCO.
Nouvelles fonctionnalités
Support « Android App »
- La connexion Wifi des apps Android a été améliorée ;
- mise à jour 10.0.0.54 des correctifs de sécurité (environ 05/2021).
D’une manière générale, j’ai trouvé que le lancement des apps Android est plus rapide qu’auparavant
Page d’accueil
Mode « Sticky » rajouté à la grille d’apps : en glissant vers le haut la grille d’applications et en la maintenant, vous pouvez la « coller » dans cette position, et ainsi lancer des applications d’une main plus facilement :
Navigateur
Barre d’outils améliorée :
- rajout de l’accès à l’historique ;
- possibilité de rajouter une page web directement à la grille d’apps.
Gestion améliorée des portails captifs Wifi.
Je trouve le navigateur dans SFOS 4.2 beaucoup plus rapide et fluide comparé même à la 4.1 - le Changelog ne mentionne pas de changement majeur, mais beaucoup de choses ont été faites « sous le capot », et utiliser le navigateur est désormais bien plus agréable
Calendrier
La vue mensuelle inclut maintenant des points colorés qui indiquent la présence d’événements du calendrier de la couleur correspondante.
Appareil photo
SailfishOS peut maintenant tirer profit des appareils avec plusieurs objectifs (comme le Xperia 10 II) :
- x1 (défaut) ;
- x2 (telezoom) ;
- x0.6 (grand angle).
Les photos ci-dessus ont été prises depuis le même endroit, et vous pouvez voir les différences entre les modes défaut / télézoom / grand angle (et vous pouvez également admirer la superbe smartwatch
PineTime).
Divers
Le mode « Partage » ouvre désormais un dialogue système, rendant l’interface plus consistante :
L’accès en SSH au téléphone via le Wifi est beaucoup plus fiable et fonctionne très bien maintenant. Avant cette mise à jour, j’avais environ 20 % de mes tentatives qui fonctionnaient, et sinon j’avais des refus de connexion - ce qui me forçait à utiliser l’Ethernet over USB).
L’écriture prédictive est maintenant disponible pour le Xperia 10 II (pour les utilisateurs ayant une licence SFOS) ! :)
Le partage de connexion pour le Xperia 10 II fonctionne (ce n’était pas le cas en 4.1)
Conclusion
Il ne s’agit pas d’une liste exhaustive des nouvelles fonctionnalités et des améliorations de Verla - se référer au changelog pour cela.
Pour être honnête, quand j’ai regardé les traductions pour SFOS 4.2, je n’attendais pas de gros changements avec cette version. Mais j’avais tort, car Verla est beaucoup plus fluide et rajoute des fonctionnalités vraiment sympa comme l’amélioration du navigateur, un App Support Android plus rapide, et enfin la saisie prédictive pour le Xperia 10 II.
Et si vous aimez regarder les vidéos de revue, Leszek a publié sa revue habituelle sur SFOS 4.2 ici.
Si vous êtes intéressé pour poursuivre la discussion, vous me trouverez (aussi) sur Twitter.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Célébrons les 18 ans des Linux-Meetup au Québec
LinuxFr.org : les dépêches par MartialBig le 15/09/2021 à 10:01:00 - Favoriser || Lu/Non lu
Le 25 septembre 2021 nous célébrons les 18 ans des Linux-Meetup au Québec.
Ce sera un samedi après-midi de 11:30 à 18:00 (heure du Québec) ou 17:30 à minuit (heure de France).
L’événement de l’an passé fut un grand succès, on a eu 12 « sponsors » et on a réussi à attirer virtuellement 80 Linuxiens (sur 120 inscriptions Eventbrite), et près de 2 500 $ à gagner répartis sur une vingtaine de cadeaux :-)
Dû à la Covid-19, on ne peut toujours pas se rencontrer physiquement pour fêter cela et la rencontre sera virtuelle sur BigBlueButton (un logiciel libre de vidéoconférence fonctionnant sous Linux+ProxMox).
Avec nos rencontres virtuelles maintenant, il n’y a plus de raison de ne pas venir faire votre tour afin de rencontrer des gens qui partagent les mêmes intérêts pour les logiciels libres que vous ;-)
Les rencontres sont ainsi disponibles partout à travers la francophonie. ;-)
- lien nᵒ 1 : Vidéo promotionnelle du CTF
- lien nᵒ 2 : Inscriptions
Nous essayons toujours d’innover afin d’attirer le plus de Linuxiens et Linuxiennes en organisant une nouvelle chasse au trésor informatique virtuelle (en anglais CTF: Capture The Flag) spécialement conçue pour les Linux-Meetup (merci Dominique Derrier). L’objectif est de s’amuser et d’apprendre Linux encore plus (afin de se sensibiliser à la sécurité sous Linux/web).
Nos conférences virtuelles utilisent 100% de logiciels libres avec BigBlueButton sous Linux et sont hébergées au Québec chez OVHcloud (sur des serveurs de la compagnie Services-Conseils Linux).
J’espère vous y voir en grand nombre afin que l’on atteigne une assistance record cette année ;-)
Note : si vous connaissez des entreprises (ou associations) qui seraient intéressées à contribuer au succès de notre événement annuel, n’hésitez-pas à les suggérer !
Martial Bigras
Organisateur des Linux-Meetup au Québec depuis 2003 (18 ans)
Commentaires : voir le flux Atom ouvrir dans le navigateur
Lu/Non lu Favoriser
Les Néerlandais peuvent choisir leurs modems et routeurs
LinuxFr.org : les dépêches par Serge Julien le 14/09/2021 à 13:26:00 - Favoriser || Lu/Non lu
Les Néerlandais (habitants des Pays-Bas, à ne pas confondre avec les Hollandais, qui habitent la Hollande, laquelle n'est qu'une des provinces desdits Pays-Bas) ont bien de la chance.
Dans une décision publiée début août, l'ACM, autorité locale de régulation des marchés, a en effet obligé les FAI à permettre à leurs clients de choisir librement le matériel pour se connecter à leurs services (modems, routeurs).
Bien qu'ayant un impact local assez relatif (les FAI toléraient déjà le choix du matériel), cette décision garantit que les clients finaux qui s'équipent avec le matériel de leur choix bénéficieront par exemple du même niveau de support que ceux qui adoptent les box généralement fournies avec les abonnements.
Cette annonce est saluée par la FSFE qui promeut ce choix à travers son initiative "Router Freedom", lancée en 2013 et qui avait déjà porté ses fruits en Allemagne. La réglementation européenne (règlement (UE) 2015/2120) qui est d'application dans ce domaine est certes supposée garantir certains droits qui vont dans ce sens, mais est parfois imprécise et surtout, n'a été que trop peu traduite dans le droit national de chaque pays.
Pour cette raison, la FSFE continue à surveiller la mise en œuvre de ce règlement, ainsi que l'application de règles de conduite complémentaires publiées par le Body of European Regulators for Electronic Communications (BEREC) :
"The FSFE welcomes BEREC's effort to provide a set of principles to determine the Network Termination Point. However, due to the unclear terms in the new Guidelines, the lack of enforcement commitment by the NRAs and abusive behavior of ISPs, the implementation of Router Freedom by 27 EU member states will be challenging. Our task at FSFE will be the compliance monitoring and the reporting of illegal practices", says Max Mehl, FSFE Programme Manager.
- lien nᵒ 1 : la publication de l'ACM (pdf)
- lien nᵒ 2 : l'annonce sur le site de la FSFE
- lien nᵒ 3 : Router Freedom (FSFE)
- lien nᵒ 4 : le règlement européen (UE) 2015/2120
- lien nᵒ 5 : les "guidelines" du BEREC (pdf)
Commentaires : voir le flux Atom ouvrir dans le navigateur