Linuxfr.org
Fedora a 20 ans : coup d'oeil dans le rétro avec Renault
Le projet Fedora a fêté le 6 novembre 2023 ses 20 ans. C'est en effet via cette annonce publique de la sortie de la dénommée Fedora Core 1 qui marque le coup d'envoi de cette histoire.
Continuité de la distribution Red Hat Linux en prenant un aspect communautaire, elle aura su au gré du temps s'imposer comme une distribution généraliste majeure de l'écosystème Linux. Au fil des années, de nombreuses technologies incorporées et testées en premier lieu dans la distribution ont su se généraliser au reste des distributions.
Profitons de cet anniversaire pour faire une rétrospective de l'évolution de la distribution mais aussi un rappel d'où nous partions il y a 20 ans. Cela permettra d'envisager aussi ce que nous réserve l'avenir, et qui sait faire un nouveau point d'étape dans 20 ans ?
- lien nᵒ 1 : Le site officiel du projet fedora
- lien nᵒ 2 : Site officiel de la communauté francophone de Fedora
- lien nᵒ 3 : Historique du site Fedora-fr
Le commencement de la distribution Fedora nécessite de revenir un peu avant la sortie de Fedora Core 1, en 2002. À ce moment là, l'entreprise Red Hat maintenait deux distributions : Red Hat Enterprise Linux et Red Hat Linux. La première existe toujours et est le produit phare de l'entreprise, à savoir une distribution centrée sur les besoins professionnels et les usages avancés tels que les serveurs ou les stations de travail pro en vendant des licences et du support. La seconde était plutôt destinée au particulier pour avoir une distribution à utiliser à la maison comme il pouvait acheter en magasin une Mandrake ou un Windows XP en ce temps là sur CD.
Dans les deux cas, si les distributions sont libres avec le code source accessible, le développement n'est pas communautaire et Red Hat ne propose dans ses dépôts que les paquets qu'elle maintient.
Warren Togami a eu comme projet universitaire de proposer un dépôt communautaire et complémentaire pour ces distributions. L'objectif était de compléter les logiciels manquants dans les dépôts avec une bonne qualité d'intégration tout en permettant à d'autres personnes de l'aider dans cette tâche.
Le projet prend le nom fedora.us en référence au modèle de chapeau iconique du logo de Red Hat. Et il prend rapidement de l'essor.
Les ressources n'étant pas infinies, Red Hat souhaite se désengager de Red Hat Linux qui n'est pas assez rentable et propose de chapeauter le projet Fedora en adoptant un développement communautaire, et en s'en servant comme base pour sa distribution phare RHEL tout en donnant des ressources matérielles et humaines pour aider le projet Fedora dans sa tâche. En un sens, le projet Fedora et Red Hat Linux fusionnent. Au début cependant Red Hat maintenait le dépôt Core (d'où le nom de Fedora Core) tandis que les personnes extérieures pouvaient gérer de manière autonome le dépôt Extra.
C'est ainsi que fin 2003, Fedora Core 1 est publiée en se basant sur Red Hat Linux 9. Red Hat Linux n'aura plus de mises à jour dès mi-2004 marquant la fin de cette distribution.
Fedora Core 1Si on fait l'expérience d'installer une Fedora Core 1, le ressenti est assez déroutant. Outre la nostalgie de ces interfaces finalement classiques mais un peu désuètes avec des graphismes très simples voire austères, nous ne sommes pour autant pas déboussolés tant les fondamentaux sont là. Le système est cependant bien plus réactif qu'à l'époque tant les performances ont progressé depuis.
En effet, la Fedora Core 1 nécessitait au minimum :
- un processeur 400 MHz Pentium II pour un usage graphique
- l'espace disque requis pouvait aller de 500 Mio au minimum à 5 Gio pour installer l'ensemble des paquets
- et niveau mémoire 256 Mio étaient recommandées pour un usage graphique.
Il ne manque que le doux bruit du disque dur qui gratte ou celui des courants qui dirigent les faisceaux d'électrons dans les tubes cathodiques avec ce grésillement caractéristique pour afficher un économiseur d'écran ou encore les fréquences pour établir les connexions via un modem 56k pour retrouver cette ambiance du début des années 2000.
Mais si au premier abord, rien n'a changé, en réalité tout est différent. Au moins dès ce moment là, l'architecture x86_64 était proposée mais c'était vraiment le balbutiement. En effet, le premier processeur grand public compatible, le Athlon 64, était sorti seulement deux mois plus tôt. L'architecture phare c'était x86 avec sa variante générique mais ancienne i386. Et autant dire avec ces machines sans accélération des instructions de virtualisation, il n'était pas vraiment envisageable de tester Fedora Core par ce biais là.
Reprenons, à ce moment là les Live CD de Fedora Core n'existaient pas encore officiellement. Pour la tester il fallait donc l'installer. Installer Fedora Core demandait au choix de télécharger l'image DVD de 3,7 Gio ou plusieurs images CD. L'installation par USB était un concept en ce temps là. Cela peut paraître superflu, mais quand Internet n'était pas aussi généralisé ou avec un débit très lent, avoir la logithèque au complet dès le départ était un atout important. Acheter un magazine juste pour avoir un CD d'installation était courant pour s'épargner ces temps de téléchargement interminables, et le coût associé parfois.
D'ailleurs, dès l'écran d'installation cet aspect saute aux yeux car nous pouvions littéralement choisir les paquets à installer au moment de l'installation, et insérer si nécessaire les CD complémentaires pour compléter le processus.
L'interface d'anaconda, le logiciel d'installation, était très linéaire avec beaucoup de questions qui font sourire aujourd'hui. Comme le choix du modèle de souris notamment pour connaître le nombre de boutons et la présence éventuelle de la molette, le choix du modèle d'écran pour connaître la résolution et la fréquence. Possibilité de synchroniser le temps par NTP mais il faut remplir le champ du serveur NTP soi même. Le compte administrateur et le compte utilisateur principal étaient bien distincts.
Une fois l'installation finie, on pouvait profiter du démarrage graphique avec l'outil rhgb (Red Hat Graphical Boot) qui est toujours un nom qu'on peut voir dans les arguments du noyau aujourd'hui chez Fedora Linux. C'était visuellement sympathique, avec cette possibilité de voir la console du lancement des services tout en gardant une interface graphique autour.
L'écran de connexion GDM se lance, il faut saisir le nom du compte qu'on souhaite lancer. Il n'y a pas de liste des comptes disponibles. Et enfin, l'interface GNOME se lance. Cependant même si c'est un GNOME 2, c'était au début un GNOME 2.4 avec un visuel proche de KDE avec une grande barre principale en bas, sans une bar en haut de l'écran qui était son mode canonique caractéristique. Le menu principal était accessible à travers l’icône du chapeau rouge de Red Hat, qui restera là pour les 4 premières versions de la distribution.
Niveau utilitaires, si certains noms sont familiers comme GIMP, la plupart des utilitaires GNOME, d'autres ont bien changé. Firefox n'existait pas, c'était son ancêtre la suite Mozilla qui était à la barre. Qui malheureusement ne gère pas les protocoles TLS récents ce qui rend impossible son usage sur le web moderne ou presque. Le courriel passait de fait par le même outil au lieu de Thunderbird bien qu'Evolution fut déjà disponible. La messagerie instantanée était proposée par l'ancêtre de Pidgin : Gaim en prenant en charge beaucoup de protocoles de cette époque dont le leader du marché en France qu'était MSN. Pour la suite bureautique c'était OpenOffice.org, le prédécesseur de LibreOffice, qui était présent.
Les outils systèmes étaient aussi très différents. DNF n'était même pas encore un rêve, la gestion des paquets passait par YUM qui était particulièrement lent et peu fiable. Le nombre de fois que la gestion des dépendances aboutissait à casser le système était fréquent, surtout avec l'usage de dépôts alternatifs pas toujours bien gérés. La configuration du système ne reposait pas uniquement sur GNOME mais sur des interfaces individuels conçus par Red Hat nommés system-config-*. C'était relativement peu flexible, il fallait souvent redémarrer la machine ou les services à la main pour appliquer des changements, le mot de passe superutilisateur était souvent requis, le réseau n'était pas géré par NetworkManager, la gestion du réseau n'était pas aussi dynamique qu'aujourd'hui en particulier pour les connexions sans fil, de même que l'intégration système via l'interface dbus. Imprimer était aussi vite laborieux pour installer l'imprimante et avoir le bon pilote, quand il existait. De même pour la numérisation des documents avec XSane.
Le démarrage était géré par des scripts init SysV classiques, systemd n'étant pas là de même que tous ses outils qui gravitent autour. Le noyau Linux lui même était un 2.4.22, la seule version de Fedora pré-2.6 qui fut une évolution majeure du noyau.
Le partitionnement standard était basé le système de fichiers ext3. Btrfs et ext4 n'existaient pas encore. Les volumes logiques par défaut n'apparaîtront également qu'un peu plus tard.
Les restrictions légales aussi rendait impossible la lecture de fichiers musicaux MP3 sans dépôts tiers. Et les limitations de l'époque empêchaient la lecture du son par plusieurs applications en même temps.
Cependant les bases étaient là, l'interface dans les canons de l'époque ce que beaucoup d'environnements de bureau maintiennent aujourd'hui par ailleurs comme Xfce ou MATE. Le thème Bluecurve accuse de l'âge mais l'intégration graphique globale était bonne sur l'ensemble des composants et sur tous les éléments de la chaine dont lors du démarrage de la machine.
20 ans d'évolution progressive visibles…Après la sortie de Fedora Core 1, les changements sont arrivés petit à petit jusqu'à aboutir à nos systèmes modernes. Parfois un peu dans la souffrance le temps d'effectuer ces transitions.
Dès la 2e version, Fedora Core change de serveur d'affichage XFree86 pour X.org car la licence du projet avait changé pour devenir non libre. SELinux était aussi proposé avant d'être activé par défaut dans la 3e version. Cela reste encore une distinction de Fedora à ce jour dans l'écosystème en dehors d'Android, bien que Ubuntu par exemple a privilégié une alternative AppArmor depuis. La 3e version apporte la mise à disposition du dépôt extra évoqué plus haut, et le navigateur Web par défaut devient Firefox.
Après la Fedora Core 4 qui se démarque par un fond d'écran identique à son prédécesseur ce qui constitue un cas unique à ce jour, Fedora Core 5 marque un rupture par un thème graphique très poussé à base de bulle. Il met en avant le nouveau logo de Fedora qui restera en place pendant de nombreuses années. Et Fedora Core 6 continuera dans cette lancée avec un nouveau thème dédié et surtout l'arrivée de la technologie AIGLX pour proposer l'accélération graphique aux environnements de bureaux. Cela marqua le début de la mode pour les bureaux avec des bureaux virtuels sous forme de face d'un cube, les fenêtres gélatineuses, et autres effets visuels qu'on pouvait personnaliser via Compiz et Beryl.
L'année 2007 sera assez riche. Le mois de mai est marqué par la sortie de Fedora 7 qui abandonne son qualificatif Core grâce à la fusion des dépôts core et extra qui deviennent le dépôt fedora encore utilisé aujourd'hui comme base du système.
Mais Fedora 7 propose aussi un thème iconique signé Diana Fong, qui sera sans doute le dernier thème aussi personnalisé dans la distribution. Fedora 7 propose aussi un Live CD installable ce qui change complètement la manière d'installer et de tester le système. Dans le même temps, l'outil preupgrade est proposé pour faire des mise à niveau par Internet plutôt que de passer par la mise à niveau via les CD (ou une réinstallation). Dans les deux cas la fiabilité de l'opération restait assez aléatoire.
Au cours de l'année 2007, le projet Fedora Legacy jette l'éponge, c'était une initiative communautaire pour allonger la durée de support des versions de Fedora au delà de la moyenne de 13 mois. Cependant c'était gourmand en ressources et il y avait peu de volontaires. Il faut dire que les utilisateurs de Fedora sont plus attirés par les nouveautés que par l'utilisation prolongée d'une vieille version.
Fin de l'année en novembre, Fedora 8 sort en introduisant NetworkManager pour la gestion du réseau et PulseAudio pour le son. Ce dernier changement s'était fait très tôt et a nécessité beaucoup de versions avant d'avoir une gestion du son stable, notamment à cause de pilotes inadaptés et des changements profonds dans le système qui ont été nécessaires. De manière plus anecdotique les fonds d'écran changeaient aussi toutes les heures, principe concerné aujourd'hui pour avoir une variation de teinte en fonction de la luminosité extérieure supposée.
Mais cela ne s'arrête pas là, Fedora 9 migre de SysV à upstart pour la gestion des services au démarrage, technologie signée Canonical qui servira de tremplin à systemd par la suite car il en corrigera ses limitations. PackageKit fait aussi son entrée pour avoir un gestionnaire de paquets universel, capable d'être une surcouche à Yum, Apt et consorts, technologie toujours au cœur de GNOME Logiciels à ce jour. C'est également lui qui vous propose d'installer le paquet qui fourni la commande que vous venez de saisir si elle n'était pas présente dans votre système. C'est aussi cette version qui propose KDE 4.0, une nouvelle version de rupture qui en appellera d'autres pour cet environnement de bureau mais là aussi avec une fiabilité délicate à ses débuts.
Fedora 10 marque le remplacement de rhgb par plymouth pour l'affichage de l'écran de démarrage, ce composant n'ayant pas bougé depuis. Le système de fichiers ext4 est aussi utilisé par défaut en remplacement de ext3.
Fedora 11 a introduit en avant première après une intense campagne de tests le pilote Nvidia libre nouveau permettant d'exploiter le modesetting du noyau et améliorant grandement l'expérience utilisateur des possesseurs d'une carte graphique de la marque.
Fedora 12 introduit l'outil abrt pour détecter les crash et générer des rapports de bogues automatiquement à partir de ceux-ci, un outil important pour la progression de la qualité du projet Fedora. L'architecture x86 nécessite aussi la variante i686 pour améliorer les performances au détriment de la prise en charge des processeurs plus anciens.
C'est à ce moment là que les dépôts tiers Livna, Dribble et Freshrpms fusionnent pour former le dépôt RPMFusion. Ce dépôt est toujours la référence communautaire pour obtenir des paquets non libres ou ceux soumis aux brevets logiciels comme les codecs multimédia et des logiciels tels que VLC.
Quelques années plus tard, en mai 2011, Fedora 15 remplace Openoffice.org par LibreOffice. Tandis que GNOME 3 devient la nouvelle interface de référence en ayant un style plus moderne et épuré. systemd remplace également upstart pour la gestion des services du système. Il faudra attendre cependant Fedora 17 pour que tous les services reposent sur des unités systemd. Cette version introduit également un nouveau pare feu dynamique firewalld qui est toujours utilisé. Les répertoires systèmes fusionnent pour que /bin et /lib redirigent vers /usr.
Fedora 18 a remplacé l'outil preupgrade par FedUP qui marque un bond en avant dans la fiabilité du processus de mise à niveau du système même si c'était encore perfectible. Fedora 20 introduit la prise en charge de l'architecture ARM.
L'année 2013 fut une autre année charnière pour le projet Fedora. Devant le manque de vision le projet se met en pause pendant 1 an pour réfléchir à son avenir. C'est le projet Fedora.next. Cela donnera lieu à l'adoption des produits Workstation, Server et Cloud / Atomic qui perdurent de nos jours, avec un focus sur l'expérience utilisateur qui a été beaucoup relaté ces dernières années.
La réflexion sur le modèle de distribution des logiciels donnera lieu aux dépôts modulaires et aux variantes immuables de la distribution tels que Fedora Silverblue.
Cette année marque aussi la naissance officielle du Fedora Magazine qui publie une actualité synthétique et instructive du projet Fedora, en langue anglaise uniquement.
Fedora 21, première version sortie après cette période de réflexion met en place les nouveaux produits. Et de manière symbolique les versions de Fedora ne portent plus de nom, auparavant chaque version avait un nom unique qui devait avoir un lien (même ténu) avec le nom de la version précédente.
Fedora 22 marque la fin de l'ère de yum et de FedUp pour reposer sur dnf comme gestionnaire de paquets par défaut. Il était plus rapide, plus fiable et capable de gérer la mise à niveau lui même via un plugin.
En novembre 2016, Fedora 25 propose Wayland pour l'affichage dans l'environnement GNOME par défaut après une expérimentation dans GDM dans la version précédente. Si l'adoption de Wayland n'a pas été un long fleuve tranquille, le chemin parcouru reste important et les progrès visibles. Cette même année l'outil multiplateforme Fedora Media Writer est proposé pour facilement créer une clé USB bootable avec Fedora dessus.
Devant l'amélioration continue de la fiabilité, depuis Fedora 27 il n'y a plus de versions alpha. La version 28 abandonne le compte super utilisateur distinct par l'usage natif de sudo.
Fedora 29 concrétise un peu les objectifs de Fedora.next énoncés quelques années plus tôt par l'arrivée des dépôts modulaires qui n'auront tenu que 5 ans. Mais c'est surtout la première version de Fedora Silverblue qui annonce un début de série pour les distributions et variantes immuables en dehors des conteneurs.
À partir de Fedora 31, l'architecture x86 historique n'est plus prise en charge. 15 ans plus tôt c'était pourtant l'image de référence de la distribution.
Il faudra attendre Fedora 33 pour que btrfs devienne le système de fichier par défaut et de fait l'abandon des volumes logiques comme méthode de partitionnement privilégié car c'est directement fourni par btrfs. Par ailleurs zram compresse la RAM pour augmenter la quantité de mémoire virtuelle au lieu d'une partition swap dédiée comme c'était l'usage.
Fedora 34 permet à Pipewire de remplacer PulseAudio pour la gestion du son, avec une transition plus en douceur cette fois-ci. Le logo de la distribution change une nouvelle fois. Et Fedora Linux 35 adopte le nom actuel de la distribution.
… et 20 ans d'évolution en coulisseLa distribution elle même n'est pas la seule à avoir connu des changements en 20 ans. La communauté et l'infrastructure pour gérer ce projet ont aussi évolué.
En terme d'infrastructure, créer une distribution nécessite de gérer la traduction, le code source des paquets RPM à générer et des outils autour, la génération de ces paquets RPM, il faut des moyens de communication entre les contributeurs mais aussi entre utilisateurs, et divers services internes ou site web pour afficher les informations pertinentes.
Par exemple la traduction a débuté avec l'outil Transifex, avant de passer à Zanata puis à Weblate. Pour le code source cela a commencé avec Trac à l'ère où le gestionnaire de version SVN régnait en maître avant de passer à une solution maison nommée pagure pour tirer profit de git pour finir chez gitlab. Les forums officiels sont arrivés tardivement et sont passés de Ask à Discourse.
Les outils de développement ont significativement évolué même s'ils n'ont pas forcément changé en cours de route comme Bugzilla pour rapporter les bogues ou Koji pour construire les paquets ou encore les listes de diffusion avec Mailman / Hypperkitty pour les échanges de courriels entre développeurs. Des outils ont été ajouté en court de route comme fedmsg pour permettre la communication et la notification entre les différentes applications de l'infrastructure du projet Fedora. Ou encore Anitya qui permet d'être notifié si un projet libre a une nouvelle version publiée qui pourrait de fait justifier de mettre à jour un paquet dans Fedora. Et tant d'autres.
Niveau organisation décisionnelle les changements n'ont pas été très importants, si ce n'est la création d'un organisme dédié à la remontée communautaires des idées, la centralisation des activités de communication notamment des ambassadeurs avec la Fedora Ambassadors Steering Committee devenue depuis Mindshare en étendant son champ d'application.
Au fil des années malgré sa stratégie intacte d'introduire des changements importants en avance sur son temps, la qualité du projet Fedora s'est considérablement améliorée. Il était courant avant de considérer qu'il fallait attendre quelques semaines / mois avant de mettre à niveau son système, le temps d'essuyer les plâtres. Aujourd'hui ce temps est révolu, si les problèmes surviennent parfois, le système reste globalement stable et ce même pour les versions en développement. Avant 2010 utiliser Fedora Rawhide était par exemple un défi en soi, aujourd'hui cela ne l'est plus.
Ce travail résulte d'une maturité de l'écosystème du Logiciel Libre, les briques de base changent moins souvent. Les logiciels sont de manière générale plus testés et mieux finis et Fedora n'y fait pas exception. L'équipe d'assurance qualité de la distribution a aussi pris en ressources et responsabilités pour parvenir à ce résultat. Les outils développés dans ce but comme la notation des mise à jour avec un karma, la création de suite de tests pour de nombreux paquets ou l'outil abrt, et des pratiques telles que les journées de tests y contribuent également. Cela permet à Fedora aujourd'hui de poursuivre sa mission sans dissuader les gens de s'en servir au quotidien ce qui est important dans ce but.
Une communauté francophone quasiment aussi ancienneLa communauté francophone aussi va sur ses 20 ans. Le 24 mai 2004 naissait le site Fedora-fr pour proposer un forum et une documentation en langue française sur base de de l'outil Xoops.
Une page dédiée permet de voir l'évolution de l'équipe de la charte graphique au fil du temps. Après quelques années la plateforme a migré vers eZ publish pour la page d'accueil et FluxBB pour le forum. Tandis que depuis cette année c'est une base Wordpress et Flarum qui ont pris le relai. Le travail de maintenance se poursuit. Le serveur a longtemps été un serveur dédié chez l'hébergeur Ikoula, dont le dénommé Zod, pour finir sur un serveur virtuel chez l'hébergeur Scalway.
Pendant très longtemps le projet Fedora était très centrée sur l'anglais : les sites officiels n'étaient pas toujours traduits, le wiki pas multilingue, les forums officiels sont arrivés tardivement et restent majoritairement focalisés sur l'anglais, le Fedora magazine reste non traduit. D'où la nécessité rapidement d'avoir une communauté francophone avec son propre espace et indépendant du projet Fedora en tant qu'organisation.
Pour mieux gérer les ressources et responsabilités autour du site Fedora-fr, l'association Fedora-fr est fondée le 17/04/2007 à Charleville-Mézière. L'association ensuite se renommera en Borsalinux-fr suite à un accord signé avec Red Hat à ce sujet, le droit américain le nécessitant. L'association sera également déplacée à Paris pour faciliter sa gestion.
La communauté francophone a souvent été reconnue comme dynamique avec de bonnes initiatives et des membres compétents. Le point d'orgue a été l'organisation de la FUDCON (Fedora Users and Developers Conference) à Paris en 2012.
Et après ?L'aventure du projet Fedora ne s'arrête pas là.
Si les technologies de rupture sont moins fréquentes qu'à ses débuts, il y a de nombreux challenges à relever. Par exemple les variantes immuables gagnent en popularité et utilisabilité. L'objectif reste de se diriger vers ce modèle à terme, est-ce que Fedora sautera le pas en abandonnant Fedora Workstation pour Silverblue ?
Le modèle de distribution des paquets peut aussi évoluer. Le projet Fedora investit beaucoup la question de la génération de paquets Flatpak à partir des RPM. Et si demain la plupart des logiciels étaient distribués par ces Flatpak plutôt que les classiques fichiers RPM ?
La chaine de démarrage souffre aussi de nombreuses limitations liées à l'historique de l’architecture x86. Il semble clair que l'avenir de la prise en charge du BIOS est sombre et que ce n'est plus qu'une question d'années avant d'assister à son abandon. La prise en charge d'UEFI seulement permettra de simplifier cette partie du système et d'envisager d'autres manière de démarrer le système comme avec systemd-boot au lieu de GRUB avec les fonctionnalités qu'il peut fournir dans ce contexte, ou encore le noyau unifié ce qui a été évoqué lors des dernières versions de Fedora. Mais cela signifierait probablement la fin de la prise en charge de nombreuses vieilles machines.
Et sans doute bien d'autres choses qui dépendront aussi des évolutions de l'informatique en général et dans le Logiciel Libre en particulier.
Et vous, quels souvenirs avez-vous de ces 20 années avec Fedora ?
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Agenda du Libre pour la semaine 1 de l'année 2024
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 16 événements (France: 15, Québec: 1) est en seconde partie de dépêche.
- lien nᵒ 1 : April
- lien nᵒ 2 : Agenda du Libre
- lien nᵒ 3 : Carte des événements
- lien nᵒ 4 : Proposer un événement
- lien nᵒ 5 : Annuaire des organisations
- lien nᵒ 6 : Agenda de la semaine précédente
- lien nᵒ 7 : Agenda du Libre Québec
-
- [FR Grenoble] L’Atelier de Bidouille (ABIL) - Le lundi 1 janvier 2024 de 19h00 à 21h00.
- [FR Lyon] Soirée Pizza - Le mardi 2 janvier 2024 de 18h00 à 22h00.
- [FR Le Mans] Permanence du mercredi - Le mercredi 3 janvier 2024 de 12h30 à 17h00.
- [FR Beauvais] Sensibilisation et partage autour du Libre - Le mercredi 3 janvier 2024 de 18h00 à 20h00.
- [CA-QC Montréal] Linux-Meetup au Québec - Le mercredi 3 janvier 2024 de 18h30 à 21h30.
- [FR Angers] Rencontre mensuelle OpenStreetMap - Le jeudi 4 janvier 2024 de 18h15 à 18h15.
- [FR Rennes] Apéro du Libre - Actux - Le jeudi 4 janvier 2024 de 19h00 à 22h00.
- [FR Chambery] Forum ALPINUX - Le jeudi 4 janvier 2024 de 20h00 à 22h00.
- [FR Quimperlé] Point info GNU/Linux - Le vendredi 5 janvier 2024 de 13h30 à 17h30.
- [FR Milly-sur-Thérain] Sensibilisation et partage autour du Libre - Le vendredi 5 janvier 2024 de 17h00 à 19h00.
- [FR Vanves] Portes ouvertes - Installations - Dépannages - Le samedi 6 janvier 2024 de 09h30 à 18h00.
- [FR Wintzenheim] Réunion du Club Linux - Le samedi 6 janvier 2024 de 13h00 à 19h00.
- [FR Le Mans] Permanence mensuelle du samedi - Le samedi 6 janvier 2024 de 14h00 à 18h00.
- [FR Paris] Premier Samedi du Libre - Le samedi 6 janvier 2024 de 14h00 à 18h00.
- [FR Nantes] Permanence Linux-Nantes - Le samedi 6 janvier 2024 de 15h00 à 18h00.
- [FR Quimper] Rencontres Linuxiennes - Le samedi 6 janvier 2024 de 16h00 à 18h00.
L’Atelier de Bidouille Informatique Libre (ABIL) est ouvert à toutes les personnes qui n’arrivent pas à résoudre des problèmes avec leur ordinateur :
- trouver et installer un logiciel
- utiliser et/ou apprendre à utiliser un logiciel
- réinstaller ou installer un système d’exploitation
- monter un ordinateur
- réparer un ordinateur
- créer et/ou mettre à jour un site oueb
- … ou d’autres choses sur un ordinateur
L’atelier permet de résoudre son problème en compagnie de bénévoles et des participants qui ne sont ni expert·e·s en informatique, ni réparateur·rice·s, mais qui ont l’habitude de la « bidouille » et seront là pour vous aider à trouver l’information là où elle se trouve (si elle existe).
Pendant les ateliers, l’ABIL met à disposition du matériel : postes de travail, unités centrales à remonter ou installer, écrans, claviers, souris, pièces détachées, connexion Internet…
Attention, l’ABIL ne met à disposition que des systèmes d’exploitation et des logiciels libres. Si vous souhaitez résoudre un problème sur un système ou logiciel non-libre, apportez votre machine pour participer à l’atelier, muni des licences du système d’exploitation et/ou des logiciels concernés.
- Centre de loisirs enfance et famille, 2 rue Henri Ding, Grenoble, Auvergne-Rhône-Alpes, France
- http://www.abil-grenoble.org
- abil, atelier, bidouille, logiciel
Venez discuter avec nous d’informatique, d’écologie, de solidarité ou de logiciel libre, autour d’un verre ou d’une part de pizza.
Ambiance sympathique et détendue.
Tous les mardis.
- Lalis, 7 place Louis Chazette, Lyon, Auvergne-Rhône-Alpes, France
- https://lalis.fr
- rencontre, recyclage, upcycling, linux, mageia, vie-privée, lalis
Assistance technique et démonstration concernant les logiciels libres.
Attention, réservez votre place par contact (at) linuxmaine (point) org
Planning des réservations consultable ici.
- Centre social, salle 220, 2ᵉ étage, pôle associatif Coluche, 31 allée Claude Debussy, Le Mans, Pays de la Loire, France
- https://linuxmaine.org
- linuxmaine, gnu-linux, demonstration, assistance, permanence, logiciels-libres
Chaque mercredi soir, l’association propose une rencontre pour partager des connaissances, des savoir-faire, des questions autour de l’utilisation des logiciels libres, que ce soit à propos du système d’exploitation Linux, d’applications libres ou des services en ligne libres.
C’est l’occasion aussi de mettre en avant l’action des associations fédératrices telles que l’April ou Framasoft, dont nous sommes adhérents et dont nous soutenons les initiatives avec grande reconnaissance.
- Ecospace, 136 rue de la Mie au Roy, Beauvais, Hauts-de-France, France
- https://www.oisux.org
- oisux, logiciels-libres, framasoft, atelier, rencontre
Local de la rencontre : École de Technologie Supérieure A-????
Rencontre virtuelle : https://bbb3.services-conseils-linux.org/Linux-Meetup
18:30 à 19:00 Installation et tests de l’environnement hybride (tests de son et vidéo)
Programmation de la rencontre (de 19:00 à 21:30)
- Présentation de… (Prénom Nom)
- Présentation éclair « Lightning talk » sur les logiciels/Linux
- Période d’échange de trucs et astuces sous Linux (tous)
Lieu
Rencontre virtuelle : https://bbb3.services-conseils-linux.org/Linux-Meetup
Extras
Pendant le « happy hour » virtuel BYOB « Bring your own Beer » (de 17:30 à 18:30), il y aura une discussion virtuelle afin de pouvoir discuter de logiciels libres avec vos amis… que vous n’avez pas vus depuis le confinement ;-)
Profitez-en pour arriver plus tôt afin de vérifier votre audio/vidéo avec BigBlueButton qui ne requiert aucune installation de logiciel puisqu’il fonctionne directement dans votre navigateur avec HTML5 (Chromium, Chrome, Firefox recommandé).
Nous invitons tous les amateurs de logiciels libres (peu importe la plate-forme) à venir discuter. C’est vraiment une excellente occasion de socialiser et de faire connaissance avec d’autres qui partagent les mêmes intérêts.
La rencontre est gratuite et ouverte à tous (de débutants à experts) et rassemble des gens de diverses professions: gestionnaires, professeurs, administrateurs de systèmes, ingénieurs, programmeurs, retraités, étudiants, etc.
Les Linux-Meetup se déroulent simultanément à travers le monde tous les premiers mardis du mois ainsi que dans plusieurs régions du Québec.
Au plaisir de vous rencontrer !
Martial
P.S. : Pour le transport en commun: Station de métro Bonaventure
- École de Technologie Supérieure et virtuel, ÉTS - Pavillon A, 1100, rue Notre-Dame Ouest, Montréal, Montréal, Québec
- https://www.meetup.com/fr-FR/Linux-Montreal
- linux-meetup-montréal
Déjà fan d’OpenStreetMap ou envie de découvrir cette cartographie libre, de contribuer à l’enrichissement de la cartographie locale angevine, de mettre à jour des données qui vous tiennent à cœur (pistes cyclables, environnement, facilitation des parcours PMR, bâti, etc.)?
Les cartographes bénévoles angevins se rencontrent les premiers jeudis de chaque mois pour échanger des astuces, faire découvrir les outils disponibles (sur ordiphone ou PC) et organiser des actions collectives.
Vous n’y connaissez rien ? Pas grave, on vous apprendra autour d’une pression, d’un thé ou d’un jus de fruit !
- L’Arrière Train, 3 rue de Frémur, Angers, Pays de la Loire, France
- https://wiki.openstreetmap.org/wiki/Angers
- openstreetmap, osm, cartographie, rencontre-mensuelle, openstreetmap-angers
Actux organise un nouvel apéro du libre au Papier Timbré.
Les Apéros du Libre sont des rencontres conviviales autour d’un verre, pour discuter et échanger entre utilisateurs et curieux de logiciels et culture libres.
L’entrée est gratuite et ouverte aux membres et non membres d’Actux. Les consommations sont à la charge des participants.
- Le Papier Timbré, 39 rue de Dinan, Rennes, Bretagne, France
- http://actux.eu.org/AperoDuLibre/AperoDuLibre
- actux, apero, apero-du-libre, logiciels-libres, culture-libre
Tous les 1ᵉʳ et 3ᵉ jeudis du mois, Alpinux organise des rencontres à la Dynamo de Chambéry.
À ces occasions une présentation est proposée.
C’est aussi l’occasion d’échanger sur des projets, des problèmes rencontrés…
Comme toujours covoiturage possible.
- La Dynamo - salle l’alternateur, 24 avenue Daniel Rops, Chambery, Auvergne-Rhône-Alpes, France
- https://alpinux.org
- alpinux, forum, logiciels-libre, linux-mint, atelier
Médiathèque de Quimperlé, place Saint Michel, pas d’inscription, entrée libre !
Mickaël, Johann, Pierre, et Yves vous accueillent.
Conseils, aide et infos pratiques GNU/Linux et Logiciels Libres.
Curieux ? Déjà utilisateur ? Expert ? Pour résoudre vos problèmes, vous êtes le bienvenu !
N’hésitez pas à venir avec votre PC si vous voulez une installation de GNU/Linux ou de venir avec votre périphérique récalcitrant (imprimante, scanner…) si possible.
Médiathèque de Quimperlé Tél: 02.98.35.17.30
- Médiathèque de Quimperlé, place Saint Michel, Quimperlé, Bretagne, France
- https://libreaquimperle.blogspot.fr/p/point-info-linux.html
- dépannage, entraide, gnu-linux, logiciels-libres, mediatheque-de-quimperle, point-info, libre-a-quimperle, linux, libre-à-quimperlé
Le premier vendredi de chaque mois, l’association OISUX propose une rencontre pour partager des connaissances, des savoir-faire, des questions autour de l’utilisation des logiciels libres, que ce soit à propos du système d’exploitation Linux, des applications libres ou des services en ligne libres
C’est l’occasion aussi de mettre en avant l’action des associations fédératrices telles que l’April ou Framasoft, dont nous sommes adhérents et dont nous soutenons les initiatives avec grande reconnaissance.
L’atelier aura lieu dans les locaux de la mairie.
- Mairie, rue de Dieppe, Milly-sur-Thérain, Hauts-de-France, France
- https://www.oisux.org
- oisux, rencontre, atelier, logiciels-libres
Le premier samedi de chaque mois (sauf août et septembre), de 9h30 à 18h, nous organisons une journée porte ouverte pour présenter notre association et son but.
Lors de cette journée vous êtes invités à venir nous rencontrer pour découvrir toutes les possibilités des logiciels libres.
Venez avec vos questions, vos souhaits, vos matériels, nous verrons ensemble comment y répondre.
Nous acceptons le don de matériel informatique et de smartphone, de préférence avec leur alimentation / chargeur.
Le Wiki pour aider à passer au Libre: https://wiki.llv.asso.fr/doku.php
- Espace Danton, rue Jean Jaurès, Vanves, Île-de-France, France
- http://llv.asso.fr
- linux, installation, dépannage, don-de-matériels, install-party, gnu-linux, logiciels-libres, impression3d, llv, le-libre-vanvéen, wiki
Rencontre du Club Linux de la MJC du Cheval Blanc qui se réunit toutes les 3 semaines et accueille toutes les personnes qui souhaitent découvrir ou approfondir Linux et les Logiciels Libres. Aucune compétence n’est demandée.
Pendant ces rencontres, informelles,
- nous accueillons celles et ceux qui cherchent une réponse ou souhaitent découvrir Linux et les Logiciels Libres,
- nous installons Linux sur des ordinateurs, la plupart des fois en "dual boot"(*), ce qui permet de conserver l’ancien système (par exemple Windows) et d’utiliser quand même Linux, en choisissant au démarrage,
- nous partageons nos recherches (nos difficultés aussi) et nos découvertes, les nouveautés.
Le Club Linux est également impliqué dans une démarche de libération des GAFAM (Google Apple Facebook Amazon Microsoft) et de promotion de solutions libres comme, entre autres, Wikipedia, OpenStreetMap, les Framatrucs (*), les C.H.A.T.O.N.S (*) et beaucoup d’autres.
(*): mais on vous expliquera
- MJC du Cheval Blanc, 1 faubourg des Vosges, Wintzenheim, Grand Est, France
- https://mjc-chevalblanc.fr/-club-linux-.html
- club-linux, logiciels-libres, linux, gnu-linux, réunion, mjc-du-cheval-blanc
Assistance technique et démonstration concernant les logiciels libres.
Attention, réservez votre place par contact (at) linuxmaine.org
Planning des réservations consultable ici.
- Centre social, salle 220, 2ème étage, pôle associatif Coluche, 31 allée Claude Debussy, Le Mans, Pays de la Loire, France
- https://linuxmaine.org
- linuxmaine, gnu-linux, demonstration, assistance, permanence, logiciels-libres
Toutes les informations sont sur https://premier-samedi.org
Plan des salles: https://premier-samedi.org/IMG/png/plancarrnum.png
Venez aider ou vous faire aider à installer et paramétrer des logiciels libres et toute distribution GNU/Linux ou Android avec les associations d'utilisateurs de Fedora, Mageia, Ubuntu, Debian pour GNU/Linux ; et Replicant, LineageOS, f-droid pour Android, sur netbook, portable, tour, PC/Mac, ou smartphone, éventuellement à côté de votre système actuel. Idem si vous avez des difficultés avec GNU/Linux, un périphérique, un logiciel libre, ou avec des logiciels libres sous Android.
- Déjeuner à partir de 12h30 à la pizzeria Le Verona, 25 avenue Corentin Cariou
- Salle Classe Numérique 14h-18h : install party GNU/Linux toutes distributions + atelier auto-hébergement et Brique Internet avec Franciliens.net
- Salle LivingLab : wikipermanence Wikimedia France
- Salle Atelier : atelier Blender 3D du BUG Blender User Group Paris
Apéro/dîner dans un lieu à déterminer sur place
Cité des sciences et de l’industrie; Carrefour Numérique niveau -1, 30 avenue Corentin Cariou, Paris, Île-de-France, France
https://parinux.org/Premier-Samedi-du-Libre-du-6-janvier-2024
parinux, psl, install-party, logiciels-libres, gnu-linux, premier-samedi-du-libre
Linux-Nantes tient à vous informer de sa prochaine permanence.
Nous vous proposons: de vous aider dans le choix des logiciels libres, de vous aider à installer Linux sur votre ordinateur ou votre portable, de vous informer sur l’utilisation de votre version de Linux et de résoudre les problèmes rencontrés.
Pour plus d’informations sur l’association voir notre site https://www.linux-nantes.org.
- B17, 17 rue Paul Bellamy, Nantes, Pays de la Loire, France
- https://www.linux-nantes.org
- linux-nantes, gnu, linux, logiciels-libres, permanence
Se faire aider ou aider à installer, paramétrer, réparer un ordi sous Linux, pour tout le monde mais en particulier aux bénéficiaires de la redistribution gratuite d’ordinateurs sous Linux faite par le Centre des Abeilles.
- Centre des Abeilles, 4 rue Sergent le Flao, Quimper, Bretagne, France
- https://linuxquimper.org
- linux, linux-quimper, redistribution, recyclage, gnu-linux, logiciels-libres, rencontre
Commentaires : voir le flux Atom ouvrir dans le navigateur
Revue de presse de l’April pour la semaine 51 de l’année 2023
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.
- [Républik IT Le Média] Achats numériques: naissance de la Canut
- [InformatiqueNews.fr] L'open source au service d'un environnement IT plus durable?
- [Clubic.com] Vous êtes francophone et voulez participer à l'essor de l'open source? Mozilla a besoin de votre voix
- [cio-online.com] L'Open Source s'est immiscé dans la quasi-totalité de l'économie française
- lien nᵒ 1 : April
- lien nᵒ 2 : Revue de presse de l'April
- lien nᵒ 3 : Revue de presse de la semaine précédente
- lien nᵒ 4 :
Petites brèves : conférences, jeu, docs, culture, sécurité, plein de cadeaux de fin d'année
À défaut d’avoir une dépêche dédiée à chaque sujet, voici des infos en vrac :
- les captations vidéos des conférences de l’édition 2023 des Journées du Logiciel Libre de Lyon ! seront disponibles via Peertube et Mastodon. Et rappelons que Les JdLL ont besoin d’un nouveau lieu pour l’édition 2024.
- Superflu Riteurnz (dépêche) est désormais, comme promis, un jeu 100 % sous licence libre. Et vous pouvez soutenir financièrement le développement et la libération.
- de la pédagogie sur le fonctionnement des réseaux 1, 2, 3 (CC By NC SA 4.0)
- le Chaos Communication Congress 37C3 a lieu du 27 au 30 décembre 2023 : ça parle de trains hackés en Pologne, de smuggling SMTP mais aussi de Rust, de microbiote, de vote électronique, de téléphone à cadrans et de plein d’autres choses dans une longue liste à la Prévert
- vous avez déjà vu un géo-histo-gramme ?
- Framasoft a bien bossé sur la nouvelle interface de l’annuaire de logiciels libres FramaLibre
- 116 paquets malveillants détectés dans le dépôt PyPi
Commentaires : voir le flux Atom ouvrir dans le navigateur
Agenda du Libre pour la semaine 52 de l'année 2023
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 8 événements (France: 8) est en seconde partie de dépêche.
- lien nᵒ 1 : April
- lien nᵒ 2 : Agenda du Libre
- lien nᵒ 3 : Carte des événements
- lien nᵒ 4 : Proposer un événement
- lien nᵒ 5 : Annuaire des organisations
- lien nᵒ 6 : Agenda de la semaine précédente
- lien nᵒ 7 : Agenda du Libre Québec
-
- [FR Grenoble] L'Atelier de Bidouille (ABIL) - Le lundi 25 décembre 2023 de 19h00 à 21h00.
- [FR Lyon] Soirée Pizza - Le mardi 26 décembre 2023 de 18h00 à 22h00.
- [FR Beauvais] Sensibilisation et partage autour du Libre - Le mercredi 27 décembre 2023 de 18h00 à 20h00.
- [FR Cysoing] Mercredis Linux - Le mercredi 27 décembre 2023 de 19h30 à 23h30.
- [FR Annecy] Réunion hebdomadaire Logiciel Libre AGU3L - Le vendredi 29 décembre 2023 de 20h00 à 23h59.
- [FR Villeneuve d’Ascq] Ateliers « Libre à vous » - Le samedi 30 décembre 2023 de 09h00 à 12h00.
- [FR Ramonville Saint-Agne] Les ateliers du CULTe - Le samedi 30 décembre 2023 de 14h00 à 18h00.
- [FR Quimper] Rencontres Linuxiennes - Le samedi 30 décembre 2023 de 16h00 à 18h00.
L’Atelier de Bidouille Informatique Libre (ABIL) est ouvert à tous·tes les personnes qui n’arrivent pas à résoudre des problèmes avec leur ordinateur:
- trouver et installer un logiciel
- utiliser et/ou apprendre à utiliser un logiciel
- réinstaller ou installer un système d’exploitation
- monter un ordinateur
- réparer un ordinateur
- créer et/ou mettre à jour un site oueb
- … ou d’autres choses sur un ordinateur
L’atelier permet de résoudre son problème en compagnie de bénévoles et des participants qui ne sont ni expert·e·s en informatique, ni réparateur·rice·s, mais qui ont l’habitude de la « bidouille » et seront là pour vous aider à trouver l’information là où elle se trouve (si elle existe).
Pendant les ateliers, l’ABIL met à disposition du matériel: postes de travail, unités centrales à remonter ou installer, écrans, claviers, souris, pièces détachées, connexion Internet…
Attention, l’ABIL ne met à disposition que des systèmes d’exploitation et des logiciels libres. Si vous souhaitez résoudre un problème sur un système ou logiciel non-libre, apportez votre machine pour participer à l’atelier, muni des licences du système d’exploitation et/ou des logiciels concernés.
- Centre de loisirs enfance et famille, 2 rue Henri Ding, Grenoble, Auvergne-Rhône-Alpes, France
- http://www.abil-grenoble.org
- abil, atelier, bidouille, logiciel
Venez discuter avec nous d’informatique, d’écologie, de solidarité ou de logiciels libre, autour d’un verre ou d’une part de Pizza.
Ambiance sympathique et détendue.
Tous les mardis.
- Lalis, 7 place Louis Chazette, Lyon, Auvergne-Rhône-Alpes, France
- https://lalis.fr
- rencontre, recyclage, upcycling, linux, mageia, vie-privée, lalis
Chaque mercredi soir, l’association propose une rencontre pour partager des connaissances, des savoir-faire, des questions autour de l’utilisation des logiciels libres, que ce soit à propos du système d’exploitation Linux, des applications libres ou des services en ligne libres.
C’est l’occasion aussi de mettre en avant l’action des associations fédératrices telles que l’April ou Framasoft, dont nous sommes adhérents et dont nous soutenons les initiatives avec grande reconnaissance.
- Ecospace, 136 rue de la Mie au Roy, Beauvais, Hauts-de-France, France
- https://www.oisux.org
- oisux, logiciels-libres, framasoft, atelier, rencontre
L’Association Club Linux Nord Pas-de-Calais organise chaque mois une permanence Logiciels Libres ouverte à tous, membre de l’association ou non, débutant ou expert, curieux ou passionné.
Durant cette permanence, vous pourrez trouver des réponses aux questions que vous vous posez au sujet du Logiciel Libre, ainsi que de l’aide pour résoudre vos problèmes d’installation, de configuration et d’utilisation de Logiciels Libres.
N’hésitez pas à apporter votre ordinateur, afin que les autres participants puissent vous aider.
Dans une salle équipée d’un tableau blanc et d’un vidéoprojecteur, se dérouleront fréquemment des ateliers, des initiations, des discussions, des tests, des démonstrations, de l’entraide abordant le logiciel libre et de la dégustation de bières.
Cette permanence a lieu à l’EPN (Espace Public Numérique), 311 rue Salvador Allende à Cysoing.
- Espace public numérique, 311 rue Salvador Allende, Cysoing, Hauts-de-France, France
- http://clx.asso.fr
- clx, permanence, linux, gnu-linux, logiciels-libres
L’AGU3L Logiciel Libre à Annecy votre association se réunit tous les vendredis à 20h00
⚠️ Vérifiez sur le site avant de vous déplacer, y a un bandeau qui confirme la tenue de la réunion.
Le programme de la réunion, s’il y en a un, est sur notre site.
L'installation et la distribution de paquets Python (2/4)
Cette dépêche est la deuxième d’une série de quatre sur le packaging en Python :
- L’histoire du packaging Python
- Tour de l’écosystème actuel
- Le casse-tête du code compilé
- La structure de la communauté en question
Je vais donc proposer un aperçu plus ou moins complet des différents outils, et de ce qu’ils font ou ne font pas, en essayant de les comparer. Mais je parlerai aussi des fichiers de configuration, des dépôts où les paquets sont publiés, des manières d’installer Python lui-même, et de l’interaction de tout ceci avec les distributions Linux. En revanche, je laisse de côté pour l’instant les paquets écrits en C, C++ ou Rust et la complexité qu’ils apportent.
- lien nᵒ 1 : Guide officiel du packaging Python
- lien nᵒ 2 : Liste de projets (sur ce même guide)
- Pip
- Les environnements virtuels : venv, virtualenv, pipx
- L’invocation d’un build backend : build
- Le transfert sur PyPI : twine
- La configuration d’un projet : le fichier pyproject.toml
- Les build backends pour code Python pur
- La gestion des versions de Python : pyenv
- Un outil de test et d’automatisation : tox
- Interlude : vous avez dit lock file?
- Un gestionnaire de lock file : pip-tools
- Les outils « tout-en-un »
- La création d’exécutables indépendants et installeurs : PyInstaller, cx_freeze, briefcase, PyOxidizer (etc.)
- Conda, un univers parallèle
- Petite comparaison des résolveurs de dépendances
- Conclusion et avis personnels
Commençons par un outil dont à peu près tout utilisateur de Python a entendu parler : pip.
PipL’installeur de paquets pip est un outil fondamental et omniprésent. Son nom est un acronyme récursif signifiant « Pip Installs Packages ». Il permet d’installer un paquet depuis le PyPI, mais aussi depuis une copie locale du code source, ou encore depuis un dépôt Git. Il dispose, bien sûr, d’un résolveur de dépendances pour trouver des versions à installer qui soient compatibles entre elles. Il possède aussi un certain nombre de fonctionnalités standard pour un gestionnaire de paquets, comme désinstaller un paquet, lister les paquets installés, etc.
S’il y a un outil de packaging quasi universel, c’est bien pip. Par exemple, la page de chaque paquet sur PyPI (exemple) affiche une commande pour l’installer, à savoir pip install <paquet>. Quand la documentation d’un paquet donne des instructions d’installation, elles utilisent généralement pip.
De plus, la distribution officielle de Python permet de boostraper très simplement pip avec la commande python -m ensurepip. Cela rend pip très facile à installer, et lui donne un caractère officiel, soutenu par les développeurs de Python, caractère que n’ont pas la plupart des autres outils que je vais mentionner.
Même les autres outils qui installent aussi des paquets depuis le PyPI (comme pipx, Hatch, tox, etc.) le font presque tous en utilisant, en interne, pip (sauf Poetry qui est un peu à part).
Dans l’univers parallèle de Conda et Anaconda, les utilisateurs sont souvent obligés d’utiliser pip dans un environnement Conda parce qu’un paquet donné n’est pas disponible au format Conda (ce qui crée, d’ailleurs, des problèmes de compatibilité, mais c’est un autre sujet).
Les dangers de pip sous LinuxMalheureusement, sous Linux spécifiquement, l’interface en ligne de commande de pip a longtemps été un moyen très facile de se tirer une balle dans le pied. En effet, la commande simple
pip install <paquet>tentait d’installer le paquet au niveau du système, de manière visible pour tous les utilisateurs de la machine (typiquement dans /usr/lib/pythonX.Y/site-packages/). Bien sûr, il faut des permissions pour cela. Que fait Monsieur Toutlemonde quand il voit « permission denied error » ? Élémentaire, mon cher Watson :
sudo pip install <paquet>Or, sous Linux, installer des paquets avec pip au niveau du système, c’est mal. Je répète : c’est MAL. Ou plutôt, c’est valable dans 0,1% des cas et dangereux dans 99,9% des cas.
J’insiste : ne faites JAMAIS sudo pip install ou sudo pip uninstall. (Sauf si vous savez parfaitement ce que vous faites et que vous avez scrupuleusement vérifié qu’il n’y a aucun conflit.)
Le souci ? Les distributions Linux contiennent, elles aussi, des paquets écrits en Python, qui sont installés au même endroit que celui dans lequel installe la commande sudo pip install. Pip peut donc écraser un paquet installé par le système avec une version différente du même paquet, potentiellement incompatible avec le reste, ce qui peut avoir des conséquences catastrophiques. Il suffit de penser que DNF, le gestionnaire de paquets de Fedora, est écrit en Python, pour avoir une idée des dégâts potentiels !
Aujourd’hui, heureusement, la commande pip install <paquet> (sans sudo), au lieu d’échouer avec une erreur de permissions, installe par défaut dans un emplacement spécifique à l’utilisateur, typiquement ~/.local/lib/pythonX.Y/site-packages/ (ce qui devait auparavant se faire avec pip install --user <paquet>, l’option --user restant disponible si on veut être explicite). De plus, pip émet un avertissement sous Linux lorsqu’exécuté avec les droits root (source). Ainsi, pip install <paquet> est devenu beaucoup moins dangereux.
Attention, j’ai bien dit moins dangereux… mais dangereux quand même ! Pourquoi, s’il n’efface plus les paquets du système ? Parce que si un paquet est installé à la fois par le système, et par pip au niveau de l’utilisateur, la version de pip va prendre le dessus, car le dossier utilisateur a priorité sur le dossier système. Le résultat est que le conflit, en réalité, persiste : il reste possible de casser un paquet système en installant une version incompatible avec pip au niveau utilisateur. Seulement, c’est beaucoup plus facile à corriger (il suffit d’un rm -rf ~/.local/lib/pythonX.Y/site-packages/*, alors qu’un conflit dans le dossier système peut être quasi irréparable).
La seule option qui soit sans danger est de ne jamais rien installer en dehors d’un environnement virtuel (voir plus bas pour les instructions).
Pour finir, la PEP 668 a créé un mécanisme pour qu’une distribution Linux puisse marquer les dossiers de paquets Python qu’elle contrôle. Pip refuse (par défaut) de modifier ces dossiers et affiche un avertissement qui mentionne les environnements virtuels. Debian (à partir de Debian Bookworm), Ubuntu (à partir d’Ubuntu Lunar) et d’autres distributions Linux, ont choisi de mettre en place cette protection. Donc, désormais, sudo ou pas, pip install en dehors d’un environnement virtuel donne une erreur (on peut forcer l’opération avec l’option --break-system-packages).
En revanche, Fedora n’a pas implémenté la protection, espérant réussir à créer un dossier pour pip qui soit au niveau système mais séparé du dossier de la distribution Linux, pour que pip install soit complètement sûr et qu’il n’y ait pas besoin de cette protection. Je recommande la présentation de Miro Hrončok à la conférence PyCon polonaise en janvier 2023, qui explique le casse-tête dans les menus détails. Petite citation en avant-goût : « The fix is quite trivial when you design it, and it only strikes back when you actually try to do it ».
Pip est un outil de bas niveauPip a une autre chausse-trappe qui est surprenant quand on est habitué au gestionnaire de paquets d’une distribution Linux. Petite illustration :
$ python -m venv my-venv/ # crée un environnement isolé vide pour la démonstration $ source my-venv/bin/activate # active l’environnement $ pip install myst-parser [...] Successfully installed MarkupSafe-2.1.3 Pygments-2.16.1 alabaster-0.7.13 [...] [...] $ pip install mdformat-deflist [...] Installing collected packages: markdown-it-py, mdit-py-plugins, mdformat, mdformat-deflist [...] ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. myst-parser 2.0.0 requires markdown-it-py~=3.0, but you have markdown-it-py 2.2.0 which is incompatible. myst-parser 2.0.0 requires mdit-py-plugins~=0.4, but you have mdit-py-plugins 0.3.5 which is incompatible. Successfully installed markdown-it-py-2.2.0 mdformat-0.7.17 mdformat-deflist-0.1.2 mdit-py-plugins-0.3.5 [...] $ echo $? 0Comme on peut le voir, la résolution des dépendances par pip ne prend pas en compte les paquets déjà installés dans l’environnement. Autrement dit, pour installer un paquet X, pip va simplement regarder quelles sont les dépendances de X (y compris les dépendances transitives), trouver un ensemble de versions qui soient compatibles entre elles, et les installer. Pip ne vérifie pas que les versions des paquets sont aussi compatibles avec ceux qui sont déjà installés. Ou plutôt, il les vérifie, mais seulement après avoir fait l’installation, à un moment où le mal est déjà fait, et uniquement pour afficher un avertissement. Dans l’exemple ci-dessus, on installe d’abord myst-parser, dont la dernière version dépend de markdown-it-py version 3.x, puis on installe mdformat-deflist, qui dépend de markdown-it-py version 1.x ou 2.x. En installant mdformat-deflist, Pip installe aussi, comme dépendance, markdown-it-py 2.x, ce qui casse le myst-parser installé précédemment.
Ceci n’est naturellement pas du goût de tout le monde (je me rappelle d’ailleurs d’une enquête utilisateur faite par les développeurs de Pip il y a quelques années, où ils posaient la question de savoir ce que Pip devait faire dans cette situation). La morale est que pip est surtout un outil conçu pour créer un environnement virtuel où se trouvent toutes les dépendances dont on a besoin, pas pour s’en servir comme de apt ou dnf, en installant et désinstallant manuellement des dépendances. Et surtout, que pip install X; pip install Y n’est absolument pas équivalent à pip install X Y, et c’est la seconde forme qui est correcte.
Les environnements virtuels : venv, virtualenv, pipxLes environnements virtuels permettent de travailler avec des ensembles de paquets différents, installés de façon indépendante entre eux. L’outil d’origine pour les créer est virtualenv. Néanmoins, le plus utilisé aujourd’hui est venv, qui est une version réduite de virtualenv intégrée à la bibliothèque standard. Malheureusement, venv est plus lent et n’a pas toutes les fonctionnalités de virtualenv, qui reste donc utilisé également…
Pour créer un environnement virtuel (avec venv), on exécute :
python -m venv nom-de-l-environnementCela crée un dossier nom-de-l-environnement/. Chaque environnement est donc stocké dans un dossier. À l’intérieur de ce dossier se trouve notamment un sous-dossier bin/ avec des exécutables :
un exécutable python, qui ouvre un interpréteur Python ayant accès aux paquets de l’environnement virtuel (et, par défaut, seulement eux),
un exécutable pip, qui installe les paquets à l’intérieur de l’environnement.
De plus, pour simplifier l’utilisation dans un shell, on peut « activer » l’environnement, avec une commande qui dépend du shell. Par exemple, sous les shells UNIX classiques (bash, zsh), on exécute
source nom-de-l-environnement/bin/activateCette commande modifie la variable PATH pour y ajouter nom-de-l-environnement/bin/ afin que (par exemple) la commande python invoque nom-de-l-environnement/bin/python.
Malgré cela, les environnements virtuels restent un niveau de confort en dessous du Python du système, puisqu’il faut activer un environnement avant de s’en servir, ou écrire à chaque fois le chemin dossier-environnement/bin/. Bien sûr, il faut aussi mémoriser les commandes, et puis c’est si facile de faire pip install dans l’environnement global (non virtuel). Donc, beaucoup n’y prêtent malheureusement pas attention et installent au niveau global, ce qui cause des conflits de dépendances (c’est maintenant refusé par défaut sous Debian et dérivés, comme je l’expliquais dans la section précédente, mais c’est toujours majoritaire sous macOS et Windows).
C’est aussi pour rendre plus pratiques les environnements virtuels qu’existent pléthore d’outils qui les créent et/ou activent pour vous. Je termine avec l’un de ces outils, lié à la fois à pip et aux environnements virtuels, j’ai nommé pipx. À première vue, pipx a une interface qui ressemble à celle de pip, avec par exemple des sous-commandes pipx install, pipx uninstall et pipx list. Mais, à la différence de pip, qui installe un paquet dans un environnement déjà créé, pipx va, pour chaque paquet installé, créer un nouvel environnement virtuel dédié. Pipx est principalement destiné à installer des outils dont l’interface est en ligne de commande, pas sous forme d’un module importable en Python. Pipx utilise pip, pour ne pas trop réinventer la roue quand même. Au final,
$ pipx install pycowsayrevient à quelque chose comme
$ python -m venv ~/.local/pipx/pycowsay/ $ ~/.local/pipx/pycowsay/bin/pip install pycowsay $ ln -s ~/.local/pipx/pycowsay/bin/pycowsay ~/.local/bin/pycowsayPour résumer, pipx permet d’installer des outils en ligne de commande, de manière isolée, qui n’interfèrent pas avec le système ou entre eux, sans avoir à gérer les environnements virtuels soi-même.
L’invocation d’un build backend : buildPour déposer son projet sur PyPI, il faut d’abord obtenir deux fichiers : une sdist (source distribution), qui est essentiellement une archive .tar.gz du code avec des métadonnées ajoutées, et un paquet installable au format wheel, d’extension .whl. L’outil build sert à générer ces deux fichiers. Il s’invoque comme ceci, dans le dossier du code source :
python -m buildPetit exemple dans le dépôt de Sphinx (l’outil de documentation le plus répandu dans le monde Python) :
$ python -m build * Creating venv isolated environment... * Installing packages in isolated environment... (flit_core>=3.7) * Getting build dependencies for sdist... * Building sdist... * Building wheel from sdist * Creating venv isolated environment... * Installing packages in isolated environment... (flit_core>=3.7) * Getting build dependencies for wheel... * Building wheel... Successfully built sphinx-7.3.0.tar.gz and sphinx-7.3.0-py3-none-any.whl $ ls dist/ sphinx-7.3.0-py3-none-any.whl sphinx-7.3.0.tar.gzComme on peut le comprendre, build est un outil très simple. L’essentiel de sa documentation tient en une courte page. Il crée un environnement virtuel pour installer le build backend, en l’occurrence Flit, puis se contente d’invoquer celui-ci.
Le transfert sur PyPI : twineÀ l’image de build, twine est un outil fort simple qui remplit une seule fonction et la remplit bien : déposer la sdist et le wheel sur PyPI (ou un autre dépôt de paquets). En continuant l’exemple précédent, on écrirait :
twine upload dist/*Après avoir fourni un login et mot de passe, le projet est publié, il peut être installé avec pip, et possède sa page https://pypi.org/project/nom-du-projet.
La configuration d’un projet : le fichier pyproject.tomlpyproject.toml est le fichier de configuration adopté par à peu près tous les outils de packaging, ainsi que de nombreux outils qui ne sont pas liés au packaging (par exemple les linters comme Ruff, les auto-formateurs comme Black ou le même Ruff, etc.). Il est écrit dans le langage de configuration TOML. On a besoin d’un pyproject.toml pour n’importe quel projet publié sur PyPI, et même, souvent, pour les projets qui ne sont pas distribués sur PyPI (comme pour configurer Ruff).
Dans ce fichier se trouvent trois sections possibles — des « tables », en jargon TOML. La table [build-system] détermine le build backend du projet (je reviens plus bas sur le choix du build backend). La table [project] contient les informations de base, comme le nom du projet, la version, les dépendances, etc. Quant à la table [tool], elle est utilisée via des sous-tables [tool.<nom de l'outil>] : tout outil peut lire de la configuration dans sa sous-table dédiée. Rien n’est standardisé par des spécifications PyPA dans la table [tool], chaque outil y fait ce qu’il veut.
Avant qu’on me dise que pyproject.toml est mal documenté, ce qui a pu être vrai, je précise que des efforts ont été faits à ce niveau dans les dernières semaines, par moi et d’autres, ce qui donne un guide du pyproject.toml normalement complet et compréhensible, ainsi qu’une explication sur ce qui est déprécié ou non concernant setup.py et un guide sur la migration de setup.py vers pyproject.toml. Tout ceci réside sur packaging.python.org, qui est un site officiel de la PyPA rassemblant des tutoriels, guides et spécifications techniques.
Les build backends pour code Python purLe build backend est chargé de générer les sdists et les wheels que l’on peut ensuite mettre sur PyPI avec twine ou autre. Il est spécifié dans le fichier pyproject.toml. Par exemple, pour utiliser Flit, la configuration est :
[build-system] requires = ["flit_core>=3.7"] build-backend = "flit_core.buildapi"requires est la liste des dépendances (des paquets sur PyPI), et build-backend est le nom d’un module (qui doit suivre une interface standardisée).
Il peut sembler étrange qu’il faille, même pour un projet simple, choisir son build backend. Passons donc en revue les critères de choix : de quoi est responsable le build backend ?
D’abord, il doit traduire les métadonnées du projet. En effet, dans les sdists et wheels, les métadonnées sont encodées dans un format un peu étrange, à base de MIME, qui est conservé au lieu d’un format plus moderne comme TOML ou JSON, pour des raisons de compatibilité. La plupart des build backends se contentent de prendre les valeurs dans la table [project] du pyproject.toml et de les copier directement sous la bonne forme, mais setuptools permet aussi de configurer les métadonnées via setup.py ou setup.cfg, également pour préserver la compatibilité, et il y a aussi des build backends comme Poetry qui n’ont pas adopté la table [project] (j’y reviens dans la section sur Poetry).
De plus, les build backends ont souvent des façons de calculer dynamiquement certaines métadonnées, typiquement la version, qui peut être lue depuis un attribut __version__, ou déterminée à partir du dernier tag Git.
C’est aussi le build backend qui décide des fichiers du projet à inclure ou exclure dans la sdist et le wheel. En particulier, on trouve généralement des options qui permettent d’inclure des fichiers autres que .py dans le wheel (c’est le wheel qui détermine ce qui est installé au final, alors que la sdist peut aussi contenir les tests etc.). Cela peut servir, par exemple, aux paquets qui doivent être distribués avec des icônes, des données en JSON, des templates Django…
Enfin, s’il y a des extensions en C, C++, Rust ou autre, le build backend est chargé de les compiler.
Il existe aujourd’hui de nombreux build backends. Beaucoup sont spécifiques à un type d’extensions compilées, ils sont présentés dans la troisième dépêche. Voici les build backends principaux pour du code Python pur.
setuptoolsC’est le build backend historique. Il reste très largement utilisé.
Avant qu’arrive pyproject.toml, il n’y avait qu’un build backend, setuptools, et il était configuré soit par le setup.py, soit par un fichier en syntaxe INI, nommé setup.cfg (qui est l’ancêtre de pyproject.toml). Ainsi, il existe aujourd’hui trois manières différentes de configurer setuptools, à savoir setup.py, setup.cfg et pyproject.toml. On rencontre les trois dans les projets existants. La façon recommandée aujourd’hui est pyproject.toml pour tout ce qui est statique, sachant que setup.py, qui est écrit en Python, peut toujours servir s’il y a besoin de configuration programmable.
Aujourd’hui, setuptools ne se veut plus qu’un build backend, mais historiquement, en tant que descendant de distutils, il a beaucoup de fonctionnalités, désormais dépréciées, pour installer des paquets ou autres. On peut se faire une idée de l’ampleur des évolutions qui ont secoué le packaging au fil des années en parcourant l’abondante documentation des fonctionnalités obsolètes, notamment cette page, celle-ci ou encore celle-là.
FlitFlit est l’exact opposé de setuptools. C’est le build backend qui vise à être le plus simple et minimal possible. Il n’y a pratiquement pas de configuration autre que la configuration standardisée des métadonnées dans la table [project] du pyproject.toml.
Flit se veut volontairement inflexible (« opinionated »), pour qu’il n’y ait pas de choix à faire. Avec Flit, un projet appelé nom-projet doit obligatoirement fournir un module et un seul, soit nom_projet.py, soit nom_project/. De même, il est possible d’inclure des fichiers autres que .py, mais ils doivent obligatoirement se trouver tous dans un dossier dédié au même niveau que le pyproject.toml.
Flit dispose aussi d’une interface en ligne de commande minimale, avec des commandes flit build (équivalent de python -m build), flit publish (équivalent de twine upload), flit install (équivalent de pip install .), et flit init (qui initialise un projet).
HatchlingHatchling est le build backend associé à Hatch, un outil tout-en-un dont il sera question plus loin.
Contrairement à setuptools, il est plutôt facile d’utilisation, et il fait plus souvent ce qu’on veut par défaut. Contrairement à Flit, il offre aussi des options de configuration plus avancées (comme pour inclure plusieurs modules dans un paquet), ainsi que la possibilité d’écrire des plugins.
PDM-BackendDe même que hatchling est associé à Hatch, PDM-Backend est associé à PDM. Je n'en ai pas d'expérience, mais à lire sa documentation, il me semble plus ou moins équivalent en fonctionnalités à hatchling, avec des options un peu moins fines.
Poetry-coreComme les deux précédents, Poetry-core est associé à un outil plus vaste, à savoir Poetry.
Par rapport à hatchling et PDM-backend, il est moins sophistiqué (il ne permet pas de lire la version depuis un attribut dans le code ou depuis un tag Git).
La gestion des versions de Python : pyenvL’une des difficultés du packaging Python est que l’interpréteur Python lui-même n’est généralement pas compilé upstream et téléchargé depuis le site officiel, du moins pas sous Linux (c’est davantage le cas sous Windows, et plus ou moins le cas sous macOS). L’interpréteur est plutôt fourni de l’extérieur, à savoir, sous Linux, par le gestionnaire de paquets de la distribution, ou bien, sous macOS, par XCode, Homebrew ou MacPorts. Cela peut aussi être un Python compilé à partir du code source sur la machine de l’utilisateur.
Ce modèle est différent d’autres langages comme Rust, par exemple. Pour installer Rust, la plupart des gens utilisent Rustup, un script qui télécharge des exécutables statiques compilés upstream (le fameux curl | bash tant décrié…).
Le but de pyenv est de simplifier la gestion des versions de Python. On exécute, par exemple, pyenv install 3.10.2 pour installer Python 3.10.2. Comme pyenv va compiler le code source, il faut quand même installer soi-même les dépendances (avec leurs en-têtes C).
Un outil de test et d’automatisation : toxÀ partir du moment où un projet grossit, il devient souvent utile d’avoir de petits scripts qui automatisent des tâches courantes, comme exécuter les tests, mettre à jour tel fichier à partir de tel autre, ou encore compiler des catalogues de traduction en format MO à partir des fichiers PO. Il devient également nécessaire de tester le projet sur différentes versions de Python, ou encore avec différentes versions des dépendances.
Tout cela est le rôle de tox. Il se configure avec un fichier tox.ini. Voici un exemple tiré de Pygments:
[tox] envlist = py [testenv] description = run tests with pytest (you can pass extra arguments for pytest, e.g., "tox -- --update-goldens") deps = pytest >= 7.0 pytest-cov pytest-randomly wcag-contrast-ratio commands = pytest {posargs} use_develop = TrueOn peut avoir plusieurs sections [testenv:xxx] qui définissent des environnements virtuels. Chaque environnement est créé avec une version de Python ainsi qu’une certaine liste de dépendances, et peut déclarer des commandes à exécuter. Ces commandes ne passent pas par un shell, ce qui garantit que le tox.ini reste portable.
Interlude : vous avez dit lock file?Pour faire simple, un lock file est un fichier qui décrit de manière exacte un environnement de sorte qu’il puisse être reproduit. Prenons un exemple. Imaginons une application Web déployée sur plusieurs serveurs, qui a besoin de la bibliothèque requests. Elle va déclarer cette dépendance dans sa configuration. Éventuellement, elle fixera une borne sur la version (par exemple requests>=2.31), pour être sûre d’avoir une version compatible. Mais le paquet requests a lui-même des dépendances. On souhaiterait que l’environnement soit vraiment reproductible — que des serveurs différents n’aient pas des versions différentes des dépendances, même si les environnements sont installés à des moments différents, entre lesquels des dépendances publient des nouvelles versions. Sinon, on risque des bugs difficiles à comprendre qui ne se manifestent que sur l’un des serveurs.
La même problématique se pose pour développer une application à plusieurs. Sauf si l’application doit être distribuée dans des environnements variés (par exemple empaquetée par des distributions Linux), il ne vaut pas la peine de s’embarrasser de versions différentes des dépendances. Il est plus simple de fixer toutes les versions pour tout le monde.
Dans la vraie vie, une application peut avoir des centaines de dépendances, dont quelques-unes directes et les autres indirectes. Il devient très fastidieux de maintenir à la main une liste des versions exactes de chaque dépendance.
Avec un lock file, on s’assure de geler un ensemble de versions de tous les paquets qui sera le même pour tous les contributeurs, et pour tous les déploiements d’une application. On sépare, d’un côté, la déclaration des dépendances directes minimales supposées compatibles avec l’application, écrite à la main, et de l’autre côté, la déclaration des versions exactes de toutes les dépendances, générée automatiquement. Concrètement, à partir de la contrainte requests>=2.31, un générateur de lock file pourrait écrire un lock file qui fixe les versions certifi==2023.11.17, charset-normalizer==3.3.2, idna==3.4, requests==2.31.0, urllib3==2.1.0. À la prochaine mise à jour du lock file, certaines de ces versions pourraient passer à des versions plus récentes publiées entre-temps.
Le concept de lock file est en revanche beaucoup plus discutable pour une bibliothèque (par opposition à une application), étant donné qu’une bibliothèque est faite pour être utilisée dans d’autres projets, et que si un projet a besoin des bibliothèques A et B, où A demande requests==2.31.0 alors que B demande requests==2.30.0, il n’y a aucun moyen de satisfaire les dépendances. Pour cette raison, une bibliothèque doit essayer de minimiser les contraintes sur ses dépendances, ce qui est fondamentalement opposé à l’idée d’un lock file.
Il existe plusieurs outils qui permettent de générer et d’utiliser un lock file. Malheureusement, l’un des plus gros problèmes actuels du packaging Python est le manque criant, sinon d’un outil, d’un format de lock file standardisé. Il y a eu une tentative avec la PEP 665, rejetée par manque de consensus (mais avant qu’on soupire qu’il suffisait de se mettre d’accord : il y a de vraies questions techniques qui se posent, notamment sur l’adoption d’un standard qui ne permet pas de faire tout ce que font certains outils existants, qui risquerait de fragmenter encore plus au lieu d’aider).
Un gestionnaire de lock file : pip-toolspip-tools est un outil assez simple pour générer et utiliser un lock file. Il se compose de deux parties, pip-compile et pip-sync.
La commande pip-compile, prend un ensemble de déclarations de dépendances, soit dans un pyproject.toml, soit dans un fichier spécial requirements.in. Elle génère un fichier requirements.txt qui peut être installé par pip.
Quant à la commande pip-sync, c’est simplement un raccourci pour installer les dépendances du requirements.txt.
Les locks files sont donc des fichiers requirements.txt, un format pas si bien défini puisqu’un requirements.txt est en fait essentiellement une série d’arguments et d’options en ligne de commande à passer à pip.
Les outils « tout-en-un »Face à la prolifération d’outils à installer et mémoriser, certains ont essayé de créer une expérience plus cohérente avec des outils unifiés. Malheureusement, ce serait trop simple s’ils s’étaient accordés sur un projet commun…
PoetryPoetry est un outil un peu à part qui fait à peu près tout par lui-même.
Poetry se destine aux développeurs de bibliothèques et d’applications. Toutefois, en pratique, il est plutôt orienté vers les applications.
La configuration se fait entièrement dans le fichier pyproject.toml. Poetry s’utilise toujours avec son build backend Poetry-core, donc la partie [build-system] du pyproject.toml est configurée comme ceci :
[build-system] requires = ["poetry-core"] build-backend = "poetry.core.masonry.api"En revanche, contrairement à la plupart des autres build backends, Poetry n’accepte pas la configuration dans la table [project]. À la place, il faut écrire les métadonnées sur le projet (nom, version, mainteneurs, etc.) dans la table [tool.poetry], dans un format différent du format standard.
La particularité de Poetry qui le rend à part est d’être centré profondément sur le concept de lock file, d’insister fortement sur le Semantic Versioning, et d’avoir son propre résolveur de dépendances. Poetry n’installe jamais rien dans l’environnement virtuel du projet avant d’avoir généré un lock file qui trace les versions installées. Sa configuration a aussi des raccourcis typiques du semantic versioning, comme la syntaxe nom_du_paquet = "^3.4", qui dans la table [project] s’écrirait plutôt "nom_du_paquet >= 3.4, < 4.
(Ironiquement, les versions de Poetry lui-même ne suivent pas le Semantic Versioning.)
Je ne vais pas présenter les commandes de Poetry une par une car cette dépêche est déjà bien trop longue. Je renvoie à la documentation. Disons simplement qu’un projet géré avec Poetry se passe de pip, de build, de twine, de venv et de pip-tools.
PDMJe l’avoue, je connais mal PDM. D’après ce que j’en ai compris, il est assez semblable à Poetry dans son interface, mais suit tout de même plus les standards, en mettant sa configuration dans la table [project], et en utilisant le résolveur de dépendances de pip. (Je parlerai tout de même, dans la quatrième dépêche, de la motivation à l’origine du développement de PDM, qui cache toute une histoire. Pour ceux qui ont compris, oui, c’est bien résumé par un nombre qui est multiple de 97.)
HatchHatch est plus récent que Poetry et PDM. (Il n’est pas encore au niveau de Poetry en termes de popularité, mais loin devant PDM.) Il est encore en développement rapide.
Comparé à Poetry et PDM, il ne gère pas, pour l’instant, les lock files. (Ici aussi, il y a une histoire intéressante : l’auteur a d’abord voulu attendre que les discussions de standardisation aboutissent à un format commun, mais vu l’absence de progrès, il a fait savoir récemment qu’il allait implémenter un format non standardisé, comme Poetry et PDM le font déjà.)
En contrepartie, Hatch gère aussi les versions de Python. Il est capable d’installer ou de désinstaller une version très simplement, sachant que, contrairement à pyenv, il ne compile pas sur la machine de l’utilisateur mais télécharge des versions précompilées (beaucoup plus rapide, et aucune dépendance à installer soi-même). Il a aussi une commande fmt pour reformater le projet (plutôt que de définir soi-même un environnement pour cela dans Poetry ou PDM), et il est prévu qu’il gagne bientôt des commandes comme hatch test et hatch doc également.
De plus, dans Poetry, lorsque l’on déclare, par exemple, un environnement pour compiler la documentation, avec une dépendance sur sphinx >= 7, cette dépendance est résolue en même temps que les dépendances principales du projet. Donc, si votre générateur de documentation demande une certaine version, mettons, de Jinja2 (ou n’importe quel autre paquet), vous êtes forcé d’utiliser la même version pour votre propre projet, même si l’environnement pour exécuter votre projet n’a rien à voir avec l’environnement pour générer sa documentation. C’est la même chose avec PDM. Je trouve cette limitation assez frustrante, et Hatch n’a pas ce défaut.
La création d’exécutables indépendants et installeurs : PyInstaller, cx_freeze, briefcase, PyOxidizer (etc.)Distribuer son projet sur PyPI est bien beau, mais pour installer un paquet du PyPI, il faut d’abord avoir Python et savoir se servir d’un terminal pour lancer pip. Quid de la distribution d’une application graphique à des gens qui n’ont aucune connaissance technique ?
Pour cela, il existe une pléthore d’outils qui créent des installeurs, contenant à la fois Python, une application, ses dépendances, une icône d’application, et en bref, tout ce qu’il faut pour satisfaire les utilisateurs qui n’y comprennent rien et réclament juste une « application normale » avec un « installeur normal », un appli-setup.exe ou Appli.dmg. Les plus connus sont PyInstaller et py2exe. Plus récemment est aussi apparu briefcase.
Il y a aussi d’autres outils qui ne vont pas jusqu’à créer un installeur graphique, mais se contentent d’un exécutable qui peut être lancé en ligne de commande. Ce sont notamment cx_freeze et PyOxidizer, mais il y en a bien d’autres.
Malheureusement, toute cette classe d’usages est l’un des gros points faibles de l’écosystème actuel. PyInstaller, par exemple, est fondé sur des principes assez douteux qui datent d’une époque où le packaging était beaucoup moins évolué qu’aujourd’hui (voir notamment ce commentaire). Pour faire simple, PyInstaller détecte les import dans le code pour trouver les fichiers à inclure dans l’application, au lieu d’inclure toutes les dépendances déclarées par les mainteneurs. Il semble que briefcase soit meilleur de ce point de vue.
De manière plus générale, embarquer un interpréteur Python est techniquement compliqué, notamment à cause de l’interaction avec des bibliothèques système (comme OpenSSL), et chacun de ces projets résout ces difficultés d’une manière différente qui a ses propres limitations.
Conda, un univers parallèleComme expliqué dans la première dépêche sur l’historique du packaging, Conda est un outil entièrement indépendant de tout le reste. Il ne peut pas installer de paquets du PyPI, son format de paquet est différent, ses environnements virtuels sont différents. Il est développé par une entreprise, Anaconda Inc (mais publié sous une licence libre). Et surtout, bien que chacun puisse publier des paquets sur anaconda.org, il reste principalement utilisé à travers des dépôts de paquets comprenant plusieurs milliers de paquets, qui sont gérés non pas par les auteurs du code concerné, mais par des mainteneurs propres au dépôt de paquets, à la manière d’une distribution Linux, ou de Homebrew et MacPorts sous macOS. En pratique, les deux dépôts principaux sont Anaconda, qui est maintenu par Anaconda Inc, et conda-forge, maintenu par une communauté de volontaires.
Quelques outils gravitent autour de Conda (mais beaucoup moins que les outils compatibles PyPI, car Conda est plus unifié). Je pense notamment à Condax, qui est à Conda ce que pipx est à pip. Il y a aussi conda-lock pour les lock files.
Grâce à son modèle, Conda permet une distribution très fiable des extensions C et C++, ce qui constitue son atout principal. Un inconvénient majeur est le manque de compatibilité avec PyPI, qui reste la source unique pour la plupart des paquets, Conda n’ayant que les plus populaires.
Petite comparaison des résolveurs de dépendancesLes résolveurs de dépendances sont des composants invisibles, mais absolument cruciaux des systèmes de packaging. Un résolveur de dépendances prend un ensemble de paquets, et de contraintes sur ces paquets, de la forme « l’utilisateur demande le paquet A version X.Y au minimum et version Z.T au maximum », ou « le paquet A version X.Y dépend du paquet B version Z.T au minimum et U.V au maximum ». Il est chargé de déterminer un ensemble de versions compatibles, si possible récentes.
Cela paraît simple, et pourtant, le problème de la résolution de dépendances est NP-complet (c’est facile à démontrer), ce qui signifie que, sauf à prouver fausse l'hypothèse du temps exponentiel (et si vous le faites, vous deviendrez célèbre et couronné de gloire et du prix Turing), il n’existe pas d’algorithme pour le résoudre qui ait une complexité meilleure qu’exponentielle. Les algorithmes utilisés en pratique se fondent soit sur des heuristiques, soit sur une traduction en problème SAT et appel d’un SAT-solveur. Le bon résolveur est celui qui réussira à résoudre efficacement les cas rencontrés en pratique. Pour revenir à Python, il y a aujourd’hui trois résolveurs de dépendances principaux pour les paquets Python.
Le premier est celui de pip, qui est implémenté dans resolvelib. Il utilise des heuristiques relativement simples. Historiquement, il s’est construit sur une contrainte forte : jusqu’à récemment (PEP 658), il n’y avait aucun moyen sur PyPI de télécharger seulement les métadonnées d’un paquet sans télécharger le paquet entier. Donc, il n’était pas possible d’obtenir tout le graphe de dépendances entier avant de commencer la résolution, car cela aurait nécessité de télécharger le code entier de toutes les versions de chaque dépendance. Or, il n’y a aucun solveur SAT existant (à ma connaissance) qui permette de modifier incrémentalement le problème. Par conséquent, pip était de toute façon forcé d’adopter une stratégie ad-hoc. La contrainte a été levée, mais l’algorithme est resté.
Le deuxième résolveur est celui de Conda. (En fait, le résolveur est en train de changer, mais l’ancien et le nouveau sont similaires sur le principe.) Contrairement à pip, Conda télécharge à l’avance un fichier qui donne les dépendances de chaque version de chaque paquet, ce qui lui permet de traduire le problème de résolution entier en problème SAT et d’appliquer un solveur SAT.
Enfin, le troisième résolveur fait partie de Poetry. Si j’ai bien compris ceci, il utilise l’algorithme PubGrub, qui ne traduit pas le problème en SAT, mais le résout plutôt avec une méthode inspirée de certains solveurs SAT.
En pratique, dans mon expérience, le solveur de pip se montre rapide la plupart du temps (sauf dans les cas vraiment complexes avec beaucoup de dépendances et de contraintes).
Toujours dans mon expérience, la résolution de dépendances dans Conda est en revanche franchement lente. À sa décharge, je soupçonne que le résolveur lui-même n’est pas spécialement lent (voire, plus rapide que celui de pip ? je ne sais pas), mais comme Conda a pour principe de ne prendre quasiment rien dans le système, en ayant des paquets comme wget, freetype, libxcb, pcre2, etc. etc. etc., certains paquets ont un nombre absolument effrayant de dépendances. Par exemple, il y a quelque temps, j’ai eu à demander à conda-lock un environnement satisfaisant les contraintes suivantes :
- pyqt=5.15.9 - sip=6.7.11 - pyqt-builder=1.15.2 - cmake=3.26.4 - openjpeg=2.5.0 - jpeg=9e - compilers=1.6.0 - boost-cpp - setuptools=68.0.0 - wheelSur mon ordinateur, il faut environ 7 minutes pour que Conda calcule l’environnement résultant — j’insiste sur le fait que rien n’est installé, ce temps est passé uniquement dans le résolveur de dépendances. Le lock file créé contient environ 250 dépendances (!).
À titre illustratif : « Conda has gotten better by taking more shortcuts and guessing things (I haven't had a 25+ hour solve in a while) » — Henry Schreiner
Quant au résolveur de Poetry, même si je n’ai jamais utilisé sérieusement Poetry, je crois savoir que sa lenteur est l’une des objections les plus fréquentes à cet outil. Voir par exemple ce bug avec 335
Transformer une photo en BD avec le filtre Comicbook de G'MIC
Cette dépêche vous explique comment transformer une photo en style BD (genre Tintin, Mickey ou Spirou) grâce au filtre Comicbook de G'MIC. Remarquez que ça reste très approximatif. Il y a même moyen de transformer un film en dessin animé ! Ces images d’exemples sont faites avec les paramètres par défaut. Vous trouverez d’autres exemples sur Gimpchat.com. Il y a aussi une vidéo sur YouTube.
G'MIC est un logiciel (greffon ou plugin) open-source de traitement d’image numérique. Il possède plus de 500 filtres variés, répartis en une vingtaine de catégories. Tous les filtres sont appliqués avec les données pixels en float32 ce qui évite généralement les désagréments dus à la perte de précision.
- lien nᵒ 1 : G’MIC 3.2.5 : 15 ans de développement pour du traitement d’images libre et reproductible
- Installation de G'MIC
- Les paramètres
Pour commencer, il vous faut G'MIC. Il se trouve inclus dans Krita. Pour GIMP, vous devez l’installer. Il est possible de l’inclure aussi dans Photoshop ou paint.net. Vous trouverez, sur le net, beaucoup de tutoriels pour vous aider à l’installer.
Après avoir ouvert votre photo dans votre logiciel de dessin (Krita, GIMP ou même Photoshop ou paint.net), lancez le plugin G'MIC. Dans Krita et GIMP, il se trouve dans le menu "Filtre" (Je ne sais pas pour Photoshop et paint.net).
Tapez « Comic » dans la case de recherche. Vous y êtes. Si vous ne voyez pas le filtre, essayez de faire ctrl-R dans la fenêtre de G'MIC (cela charge les derniers filtres G'MIC).
Les paramètresSi on est pressé, on peut déjà obtenir un bon résultat en se contentant d'appuyer sur OK sans régler aucun paramètre (= mode rapide/auto). L'explication des paramètres ne sert donc que si on veut améliorer le résultat.
Vous pouvez parfois vous contenter des paramètres par défaut, mais je vais vous expliquer ici la signification des différents paramètres. Les paramètres sont en anglais.
SimplificationCe paramètre permet d’avoir un résultat avec moins de détails, plus schématique.
- None : Aucune.
- Light : Légère. Il s’agit de la simplification la plus légère.
- Light Antialias : Anticrénelage léger. Si vous voulez adoucir un peu les traits de la photo avant de la transformer en BD. Remarque : pour adoucir les traits finaux, il existe un autre réglage. i- Strong Antialias : Anticrénelage fort. Idem, mais attention, l’image peut être assez déformée (les traits sont étirés). Mais cela peut quand même donner un résultat intéressant. Ça me donne l’impression que les directions sont très marquées.
- Median : il s’agit d’une simplification moins forte que « Strong antialias ». Les traits ne sont pas étirés. On perd quelques détails.
- Iuwt : quand vous avez des répétitions serrées (je n’arrive pas à le dire mieux) par exemple de l’herbe, une surface granuleuse où tous les grains sont très contrastés, ce choix permet d’en faire une surface uniforme.
- Thin Brush : idem que « Iuwt », plus ou moins fort que lui selon la photo.
- Mean Curvature : c’est une simplification très forte, mais contrairement à « Strong Antialias », les traits ne sont pas étirés. Ça me donne l’impression que les directions sont toutes équivalentes et que c’est moins anguleux.
Ce paramètre permet de faire une simplification rapide. Si vous voulez un meilleur résultat, il peut être intéressant de pré-traiter l’image manuellement.
For Edges : Pour les traits Flattening for Edge (bilateral) : Aplatissement pour les traitsIl s’agit d’un aplatissement de l’image avant la détection des traits. Cet aplatissement consiste en un filtre « bilatéral » qui fabrique des zones de couleurs presque uniforme.
Si ce paramètre est trop petit, vous risquez d’avoir trop de petits traits parasites.
S’il est trop grand, vous risquez d’avoir des traits délimitant des nuances de couleur.
- Diff. of Gauss. : Différence entre deux flous gaussiens. À mon avis, c’est ce choix qui donne le meilleur résultat.
- Diff. of BoxBlur : Différence entre deux box blur. Cette méthode fabrique des traits très fins.
- Diff. of Median : Différence entre deux flous médians. Cette méthode donne des traits un peu étrange (je trouve).
- Lightness : Luminosité. Les traits tiendront compte plus fortement de certaines différences de couleur.
- MaxRGB : Maximum des canaux rouge, vert, bleu. Les traits tiendront compte plus fortement des différences de couleur. À mon avis, c’est généralement le meilleur choix.
- MinRGB : Minimum des canaux rouge, vert, bleu. Les traits tiendront compte plus fortement des différences de luminosité.
L’épaisseur n’est pas proportionnelle à la taille de l’image. Si l’image est très grande, les traits seront proportionnellement très fins. Généralement, je réduis d’abord l’image à une taille d’au plus 600px environ (largeur ou hauteur).
Line Strength : Dose de traitsVoulez-vous plus ou moins de traits sur votre résultat ?
Line Antialias : Anticrénelage des traitsPour éviter le crénelage des traits, mettez ce paramètre à au moins 15. Notez que, au-delà de 15, je ne vois pas d’amélioration sensible : utilisez alors le paramètre « Final Antialias ».
Add Colors : Ajouter des couleursSi ce paramètre est décoché, le résultat ne contient que les traits. Ça peut être utile si vous voulez colorier vous-même.
Dans ce cas, tous les autres paramètres de cette section sont sans effet.
Beaucoup de bandes dessinées ont des couleurs très saturées. Ce paramètre permet de s’en approcher.
Luminosity Increase : Augmentation de luminositéIl est généralement utile d’augmenter la luminosité car des traits noirs sont ajoutés et cela assombrit l’ensemble de l’image. Notez que l’augmentation de luminosité n’agit pas sur les traits noirs qui restent bien noirs !
Final Flattening (bilateral) : Aplatissement finalLes bandes dessinées ont souvent des zones de couleurs uniformes. Ce paramètre applique un filtre bilatéral sur le résultat final. C’est lui qui fabrique le mieux des zones de couleurs presque uniformes. On voudra en général mettre une grande valeur pour ce paramètre.
Color Effect : Effet de couleur- None : Aucun effet
- Deep Black : Noir profond. Les tons presque noirs deviennent tout à fait noirs. Cela donne un plus grand contraste à l’image.
- Local Contrast Enhancement : Amélioration du contraste local. Cela permet d’avoir une image moins terne.
- Colorful : Uniquement de la couleur. C’est un gros effet : tous les tons un peu grisâtres deviennent colorés (sauf les gris purs)
Ce paramètre effectue un genre de postérisation
- Rainbow : Arc-en-ciel. Tous les tons sont transformés en blanc, noir, magenta ou une des couleurs de l'arc-en-ciel.
- Hard Rainbow : Arc-en-ciel par palier. Tous les tons sont transformés en blanc, noir, magenta, rouge, jaune, vert, bleu, cyan.
- Posterize Softly : Postériser avec douceur. Cela permet de réduire le nombre de couleurs (à 32) et de lisser un peu les traits de l’image.
- Super Flat : Super plat. Cela permet de réduire le nombre de couleurs (à 8) et de corriger la luminosité.
Pour ces effets, le filtre « Lineart » donne souvent un meilleur résultat.
- No. L’image reste en couleur.
- Soft Threshold : Seuil approximatif. Seulement les traits noirs avec un peu de gris.
- Threshold with Soft Antialias : Seuil avec antialias fort. Noir et blanc avec trait très adouci.
- Lines and Black : Trait et aplats noirs. Uniquement les traits en noir et des aplats noirs pour les zones très sombres, pas de gris, pas d’antialias.
- None : Aucun effet.
- Groove : Rainure. Les traits semblent creusés dans l’image.
- Bump : Gonflage. Les zones délimitées par les traits et par les parties noires semblent gonflées. Je trouve que ça ressemble à des jouets plastiques.
- None : Aucun effet
- Dream : Comme dans un rêve.
- Past : Comme une vieille image.
- Sketch of Future : Esquisse du futur. C’est comme l’idée qu’on peut se faire du futur : on n’en voit que les très grandes lignes.
Parfois, l’image finale présente certains traits en escalier. Pour résoudre cela, essayez d’abord « Simple » et si ce n’est pas suffisant « Double ».
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Revue de presse de l’April pour la semaine 50 de l’année 2023
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.
- [Numerama] L'open source en IA gagne du terrain face aux modèles propriétaires
- [Libération] Quatre choses à savoir sur le «fédivers» dont parle Threads, le nouveau réseau social de Meta
- [Silicon] Les logiciels libres entrés au SILL en cette fin 2023
- [ZDNet France] «Ada & Zangemann», un beau livre jeunesse sur les logiciels libres
- [Silicon] Open source: LXD change à son tour de licence
- [404 Media] Polish Hackers Repaired Trains the Manufacturer Artificially Bricked. Now The Train Company Is Threatening Them
- lien nᵒ 1 : April
- lien nᵒ 2 : Revue de presse de l'April
- lien nᵒ 3 : Revue de presse de la semaine précédente
- lien nᵒ 4 :
Projets libres ! Episode 13 : L'histoire de Peertube
Treizième et dernier épisode de l'année 2023 pour le podcast Projets Libres !
Cette fois-ci nous parlons de Peertube. Après la publication de la version 6 et l'annonce de feuille de route de la version 7, nous recevons Pouhiou et Booteille de Framasoft.
- lien nᵒ 1 : Le podcast sur l'histoire et le futur de Peertube
- lien nᵒ 2 : S'abonner au podcast
- lien nᵒ 3 : Le site de Peertube
- lien nᵒ 4 : L'annonce de la version 6
Dans ce long entretien nous abordons les thèmes suivants :
- Une présentation de Framasoft ;
- La genèse du projet Peertube ;
- Ses modes de financement ;
- La force de développement et l’animation de la commaunté ;
- Peertube et le Fediverse ;
- Le rapport aux créateurs de contenu ;
- La feuille de route.
Un grand bravo à toute l'équipe pour toutes ces années de dev et le résultat !
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Au café libre — « Libre à vous ! » du 12 décembre 2023 — Podcasts et références
Cent quatre-vingt-quatorzième émission « Libre à vous ! » de l’April. Podcast et programme :
- sujet principal : Au Café libre (actualités chaudes, ton relax)
- débat autour de l’actualité du logiciel libre
- chronique d’Antanak sur « Comment rendre l’intelligence artificielle plus inclusive ? »
- chronique de Vincent Calame « Semences, une histoire politique : partie 4 »
- lien nᵒ 1 : Radio Cause Commune
- lien nᵒ 2 : Libre à vous !
- lien nᵒ 3 : Podcast de la 194ᵉ émission
- lien nᵒ 4 : Les références pour la 194ᵉ é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 nous laisser un message sur le répondeur de la radio : pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur : +33 9 72 51 55 46.
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Le manuel de reconditionnement d’Emmabuntüs
Fort de son expérience en la matière, le collectif Emmabuntüs vient de publier un petit manuel (licence CC By SA) destiné aux personnes qui passent un temps certain à reconditionner les ordinateurs.
Le but de ce manuel est de présenter les différentes étapes à suivre pour reconditionner le matériel informatique et en particulier les unités centrales, en essayant de rationaliser les efforts des intervenants afin d’être le plus efficace possible.
Cela passe par le choix du matériel à reconditionner, un premier état des lieux de celui-ci, puis par l’installation du nouveau système d’exploitation, suivi des tests du système lui-même et de ses périphériques et enfin le nettoyage tant intérieur qu’extérieur.
- lien nᵒ 1 : Le manuel de reconditionnement
- lien nᵒ 2 : Clonage grâce à la clé de réemploi
- lien nᵒ 3 : Page de la clé de réemploi Emmabuntüs
En guise de contre-exemple, ci-dessous un ordinosaure pour lequel Linux ne peut plus grand-chose :
À noter que lorsque vous avez plus de cinq ordinateurs à reconditionner, le collectif recommande d’utiliser la méthode du clonage, grâce notamment à sa clé de réemploi, plutôt qu’une installation classique très chronophage à la longue, même en utilisant Calamares.
Et n’hésitez pas éventuellement à nous proposer vos propres idées d’amélioration de ce manuel.
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Agenda du Libre pour la semaine 51 de l'année 2023
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 21 événements (France: 20, internet: 1) est en seconde partie de dépêche.
- lien nᵒ 1 : April
- lien nᵒ 2 : Agenda du Libre
- lien nᵒ 3 : Carte des événements
- lien nᵒ 4 : Proposer un événement
- lien nᵒ 5 : Annuaire des organisations
- lien nᵒ 6 : Agenda de la semaine précédente
- lien nᵒ 7 : Agenda du Libre Québec
-
- [FR Grenoble] L'Atelier de Bidouille (ABIL) - Le lundi 18 décembre 2023 de 19h00 à 21h00.
- [internet] Émission «Libre à vous!» - Le mardi 19 décembre 2023 de 15h30 à 17h00.
- [FR Lyon] Soirée Pizza - Le mardi 19 décembre 2023 de 18h00 à 22h00.
- [FR Lyon] OpenStreetMap, rencontre mensuelle - Le mardi 19 décembre 2023 de 18h30 à 20h00.
- [FR Saint-Étienne] OpenStreetMap, rencontre Saint-Étienne et sud Loire - Le mardi 19 décembre 2023 de 19h00 à 21h00.
- [FR Grenoble] Install Party + Rencontre FairPhone - Le mardi 19 décembre 2023 de 19h00 à 21h00.
- [FR Le Mans] Permanence du mercredi - Le mercredi 20 décembre 2023 de 12h30 à 17h00.
- [FR Nantes] Repair Café + Install Party - Le mercredi 20 décembre 2023 de 15h00 à 18h30.
- [FR Beauvais] Sensibilisation et partage autour du Libre - Le mercredi 20 décembre 2023 de 18h00 à 20h00.
- [FR Grenoble] Tuppervim - Le mercredi 20 décembre 2023 de 19h00 à 23h00.
- [FR Moncheaux] Mercredis Linux - Le mercredi 20 décembre 2023 de 19h30 à 23h30.
- [FR Lille] Pop Café : Atelier Wikipedia - Le jeudi 21 décembre 2023 de 18h00 à 20h00.
- [FR Toulouse] Événement Monnaie Libre Ğ1 (june) - Le jeudi 21 décembre 2023 de 18h30 à 22h00.
- [FR Lyon] Jeudi du graphisme - Le jeudi 21 décembre 2023 de 19h00 à 21h00.
- [FR Lyon] Lightning Talks de Noël
La mission logiciels libres (DINUM) propose 4 prix BlueHats de 10000€ pour soutenir des mainteneurs
La mission logiciels libres de la Direction interministérielle du numérique est née en 2021. Elle encourage les administrations à utiliser des logiciels libres, à publier et à mutualiser leurs codes sources et elle anime la communauté #BlueHats
Libération du jeu Blupimania
Blupimania est un jeu réalisé en 1994 par la société suisse Epsitec SA. Il met en scène un petit personnage jaune nommé Blupi dans un jeu de puzzles en 3D isométrique.
Accroché à un ballon, Blupi sort d’un trou. Malheureusement, son ballon s’envole. Perdu dans son monde, Blupi avance, tourne à gauche ou à droite et effectue diverses actions de sa propre initiative, sans que vous puissiez prévoir son comportement. Le but du jeu consiste à l’aider à retrouver un ballon, afin qu’il puisse repartir vers l’énigme suivante.
Le jeu comprend plus de 120 énigmes de quatre niveaux de difficulté. Il faut avoir résolu une énigme pour passer à la suivante. En revanche, il est toujours possible de changer de niveau.
Chaque niveau comporte deux modes de jeu. Il y a le mode sans antenne où vous devez vous occuper d’un ou plusieurs Blupi autonomes, en agissant sur le décor pour influencer le déroulement du jeu, par exemple poser une barrière pour empêcher Blupi de tomber dans un trou. Et il y a le mode où Blupi a une antenne, et c’est vous qui le télécommandez. D’autres Blupi autonomes peuvent aussi évoluer, et vous devez les aider, car tant que chaque Blupi n’a pas trouvé un ballon, l’énigme n’est pas résolue. Pour les aider, vous devez toujours modifier le monde environnant. Par exemple, pour poser une barrière, il faut amener le Blupi télécommandé devant l’emplacement choisi.
- lien nᵒ 1 : Blupi.org
- lien nᵒ 2 : Blupimania
- lien nᵒ 3 : Dépôt GitHub de Blupimania
Un peu plus de 6 ans après Planète Blupi, Blupimania est désormais librement téléchargeable (GPLv3+ pour code et éléments artistiques) pour toutes les plates-formes majeures (GNU/Linux, Apple macOS et Microsoft Windows).
Peut être que le nom Blupi vous dit quelque chose ?En 2017, la libération du jeu Planète Blupi a été annoncée sur LinuxFr.org. Je vous présentais le jeu et je vous racontais la petite histoire de ce personnage et de ses différentes parutions dans des jeux allant de 1988 (Toto à la maison) jusqu’à 2003 (pour Blupimania 2). J’expliquais également que depuis longtemps, je souhaitais réaliser moi-même les portages des jeux pour les différents systèmes d’exploitation. Planète Blupi est alors le premier de ce que j’espérais être une longue série.
La réalité a fait qu’il ne m’a pas été possible de consacrer tout le temps que j’imaginais à ces portages. Dans le premier article, je parle de Blupimania, qui fait partie des « anciens » jeux et le fait que son auteur, Daniel Roux, avait tout simplement perdu les codes sources. Je n’avais plus beaucoup d’espoir pendant plusieurs années. Puis un jour, Daniel débarque au bureau avec un vieux CD-R (de 1997) qui semblait prometteur et qu’il avait retrouvé un peu par hasard en faisant du rangement. Il ne savait pas trop ce qu’il y avait encore dessus. Il me l’a confié au cas où des données intéressantes pouvaient encore s’y trouver. C’était alors en 2019 et je venais de devenir papa pour la seconde fois. J’ai finalement pu attaquer les travaux fin 2021 pour enfin avoir une version publiable en novembre 2023.
BlupimaniaLe jeu a été créé à l’origine pour les micro-ordinateurs Smaky. Il pouvait fonctionner en différents modes selon les possibilités matériels du Smaky (monochrome, couleurs, avec ou sans bruitage).
Il existe aussi une version DOS, mais (à cette époque) je n’ai pas pu mettre la main sur son code source. La version Smaky n’avait pas grand-chose à envier à la version DOS. Il faut savoir que pour DOS, il était question d’un portage qui ajoutait deux fonctionnalités par rapport à la version Smaky. D’abord, on y trouvait des traductions pour l’allemand et l’anglais (le Smaky étant complètement francophone) et la seconde fonctionnalité était l’ajout de musiques pendant les phases de jeu (à ne pas confondre avec les jingles qui peuvent être désactivés dans la version Smaky avec la case à cocher musiques). Le Smaky ne permettait pas de mixer les sons ; on ne pouvait y jouer qu’un son à la fois, ce qui empêchait d’avoir du bruitage en même temps qu’une musique de fond. La photo ci-dessous représente un Smaky 100 monochrome.
Tout comme dans le cas de Planète Blupi, j’ai utilisé la bibliothèque SDL2 (que je connais plutôt bien) pour effectuer ce portage. Il y a eu des modifications fondamentales et tout n’a pas été des plus simple. J’ai écrit un journal dans lequel je raconte tous les déboires et les réussites que j’ai connus tout au long de l’adaptation. Au moment où j’écris ces lignes, ce journal n’est pas encore public.
Je vous invite à vous rendre sur le site Blupi.org pour trouvez Blupimania (ainsi que les autres jeux). Blupimania est disponible sous la forme d’une AppImage pour GNU/Linux, d’un DMG pour Apple macOS et d’un installateur NSIS pour la version Microsoft Windows. Pour les nostalgiques de l’époque du Smaky 100 et de son écran phosphorescent vert, un clin d’œil vous est destiné dans les options du jeu.
Il y aura certainement dans le futur quelques mises à jour pour combler les quelques bugs restants. A propos de la mise à disposition de Blupimania via des distributions Linux, le jeu va (comme c’est le cas depuis longtemps avec Planète Blupi) intégrer prochainement Debian et ses dérivées (Merci à OdyX). Il y a des chances aussi de le voir apparaître chez Slackware sous l’impulsion d'Yth (s’il passe par ici).
Et la suiteCette fois je ne vais faire aucun plan. Dans l’ancien article je disais attaquer prochainement Speedy Blupi 1 et 2 ainsi qu’une version haute définition pour Planète Blupi. Je n’ai rien fait de tout cela (en réalité j’ai bien attaqué une version haute résolution de Planète Blupi mais j’ai décidé d’arrêter ces travaux).
J’ai longtemps reçu des messages de fans des jeux Speedy Blupi (Speedy Eggbert) qui me réclament le code source ou tout simplement une réédition mieux adaptée aux systèmes actuels. Je leur ai adressé une lettre (via le compte X/Twitter de BlupiGames) pour expliquer ce qu’il en est.
Je verrais bien où le vent me mènera…
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Projet de loi SREN - « Libre à vous ! » du 7 novembre 2023 - Podcasts et références
Cent quatre-vingt-dixième émission « Libre à vous ! » de l’April. Podcast et programme :
- sujet principal : le projet de loi « sécuriser et réguler l'espace numérique », ou SREN. Discussion suite au vote à l'Assemblée nationale avec La Quadrature du Net, Mozilla France et Act Up, des associations qui se sont mobilisées sur ce texte.
- Une nouvelle « Pépite libre » de Jean-Christophe Becquet, sur Lichess, un site de jeux d'échecs libre.
- La chronique de Vincent Calame « Lectures buissonnières » : « Semences, une histoire politique, partie 3 »
Navré de cette communication tardive sur LinuxFr.org.
Rendez‐vous en direct chaque mardi de 15h30 à 17h 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 nous laisser un message sur le répondeur de la radio : pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur : +33 9 72 51 55 46.
- 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
Commentaires : voir le flux Atom ouvrir dans le navigateur
Le pas si grand livre des recettes de LinuxFr.org
Pour le 25 décembre 2023, ses vingt-cinq ans et répondre à une demande émise dans un journal, LinuxFr.org vous offre un recueil, pas forcément exhaustif, des recettes de cuisine qui figurent sur le site sous la forme d’un fichier PDF à télécharger. Il devrait pouvoir vous aider à concocter vos menus de fins d’années, si vous n’êtes pas trop traditionalistes. Son titre est dans le titre (de la dépêche, cela va de soit).
Astuce : lisez jusqu’à la fin, il y a un genre de cadeau dans le cadeau.
- lien nᵒ 1 : Télécharger le PDF hybride du recueil
- lien nᵒ 2 : Récupérer le PDF seul
- lien nᵒ 3 : Des boissons et des recettes libre
- Une histoire de cuisine
- Un portrait du linuxfrien ou de la linuxfrienne type sous le prisme du recueil
- La petite cuisine de la fabrication du livre
- Des choix « éditoriaux »
- Bonus
À travers les trente-cinq recettes que comporte ce recueil, c’est un genre de toute petite histoire de LinuxFr.org qui se dessine.
Lesdites recettes de cuisine ont été offertes au lectorat de LinuxFr.org sous forme de journaux, principalement, mais aussi dans les commentaires ou les forums. Il y a bien une dépêche du 24 aout 2012 sur Des boissons et des recettes libres, mais elle ne délivre pas de recettes de cuisine, seulement un panorama du sujet en 2012. Dépêche qui n’a, semble-t-il, pas déclenché des vocations de postage de recettes de cuisine sur le site, car il faudra attendre le mois de mai 2013 pour en voir réapparaître. Un certain nombre des liens de la dépêche se sont transformés en 404 depuis. Mais ça reste une bonne base.
La première recette du livre date du 22 octobre 2002, elle propose un gâteau (sucré) aux courgettes, la toute dernière du livre, en date du 14 décembre 2023 : celle de la mousse au chocolat.
Les années qui ont été le plus fertiles en recettes sont les années 2013, principalement grâce à devnewton (quatre recettes publiées de juin à août) et Pierre Tramonton qui publie trois recettes en mai, juin et juillet (et plus aucune après) et 2021, la recette de tartiflette de Krunch ayant entraîné nombre de réponses et de recettes diverses. Les toutes dernières recettes, les seules de 2023, sont celles du tiramisu et de la mousse au chocolat du même Krunch. Curieusement l’année 2020, fertile en confinements divers, n’a pas été source d’inspiration culinaire sur LinuxFr.org : aucune recette recensée dans le livre. Et pourtant, cela laissait du temps pour des confits en tous genres.
Et, ça ne figure pas dans le recueil de recettes, mais celles et ceux qui préfèrent le bricolage à la cuisine, pourront « hacker » leur machine à pain et faire du pain avec les recettes du Pas très grand livre des recettes du site LinuxFr.org.
Un portrait du linuxfrien ou de la linuxfrienne type sous le prisme du recueilOn peut s’amuser à dresser un portrait-type et culinaire du linuxfrien ou de la linuxfrienne vu à travers le biais de ce livre de cuisine. On constate ainsi que le lectorat de LinuxFr.org n’est pas très carnivore, seulement deux recettes revendiquent dans leur titre d’être à base d’un produit carné : le poulet Mole et le pain perdu au chorizo de devnewton. Le linuxfrien ou la linuxfrienne n’est absolument pas piscivore, ni même saladivore, et est très peu porté sur la boisson (une seule recette, de bière, par devnewton, encore lui).
En fait le linuxfrien ou la linuxfrienne est plus porté sur les nourritures à haute teneur en calories à base de fromage ou de pommes de terre ou des deux : aligot, tartiflette (une seule recette d’ailleurs), gratin dauphinois, truffade, etc. Mais surtout, au vu de ce recueil, le lectorat privilégierait les plats sucrés, plus dans le style tarte et gâteau que dans le style salade de fruits : treize recettes sur les trente-cinq que comporte le recueil. À cela s’ajoutent les recettes de pâtes à pain ou à crêpes.
Le lectorat du site n’est pas très novateur en matière de cuisine : la plupart des recettes sont très classiques, hormis, peut-être, la galette pomme/noisette de Denis Dordoigne ou encore le gâteau aux courgettes de Jaimé Ragnagna. Il n’est pas très fan de cuisine « exotique », à part, devinez-qui ? devnewton, encore lui, avec ses mantous et son poulet Mole.
La petite cuisine de la fabrication du livreAprès avoir récupéré les contenus, le texte a été retravaillé avec Writer de LibreOffice. L’optique étant de pouvoir l’utiliser en version papier, comme en version électronique. Le texte des recettes n’a pas été modifié et la présentation du texte a respecté les versions originales globalement. Les titres de recettes ont pu être modifiés : aucun intérêt, par exemple, d’avoir quarante-deux mille fois le mot « recette » dans leurs noms. C’est un livre de recettes de cuisine, on le sait dès le début. Les illustrations n’ont pas été reprises : il y en a très peu, et certaines sont surtout sous forme de 404.
Il est proposé en deux versions de PDF : hybride (avec le fichier ODT d’origine embarqué) ou non. Non que ça fasse une grosse différence, ce qui alourdit le fichier, l’ODT pèse 229 Ko, c’est surtout le poids des polices, les PDF 1,4 et 1,1 Mio. Le pas très grand livre des recettes du site LinuxFR.org est composé en Ysabeau, une typographie dont la réputation de chouette caractère est bien établie et en Fust et Schöffer pour la lettrine de l’introduction.
Les recettes sont classées par ordre alphabétique d’auteurice et, à l’intérieur, par ordre alphabétique de recettes. Ce qui met en valeur lesdits auteurs et autrices. Par ailleurs, les recettes comportent un, ou des, pictogramme qui indiquent dans quelle catégorie elles sont classées. On retrouve la liste recettes par catégories à la fin du livre ainsi que une liste alphabétique avec les liens en clair au regard des noms des recettes et une liste chronologique.
Les pictogrammes et l’illustration de couverture ont été dessinés avec Inkscape.
Des choix « éditoriaux »Pourquoi seulement du PDF et pas de l’EPUB ? Pourquoi pas une version imprimée achetable sur un site d’impression à la demande ?
Un livre de cuisine c’est, avant tout un objet qui va dans un environnement assez dangereux pour un fragile dispositif électronique. Ça doit pouvoir être feuilleté facilement, supporter quelques projections éventuelles (même si ce n’est pas conseillé, évidemment) et ne pas tomber en rade de batterie au cours de la recette. Bref, ça rend l’EPUB peu intéressant et ça aurait nécessité un travail supplémentaire. Exit l’EPUB. Définitivement ? Hé bien non et c’est une des raisons pour lesquelles il y a deux versions de PDF, le PDF « normal » et la version hybride qui embarque le fichier ODT, donc les sources du document. Vous trouverez les fichiers SVG des images sur OpenClipart (en). Avec ça vous pouvez faire ce que vous voulez.
Pourquoi pas une version imprimée ? Indépendamment du fait que ça aurait demandé un certain travail de mise en forme pour un livre plus petit qu’un format A4. Est-ce que ça vaut le coût pour combien de personnes ? Sachant que soit LinuxFr.org se faisait une marge, forcément petite dessus, soit n’en faisait aucune. Dans le premier cas, il faut un montant minimum pour être payé donc aucun intérêt mais une certaine complication1 et, dans le second, l’imprimer vous-même au format A4 et le relier sous pochette plastique dans un classeur vous coûtera sans doute moins cher. Exit donc le dépôt sur un site d’impression à la demande.
Et, bien évidemment, il est sous licence Creative Common, By – SA, c’est écrit dans l’introduction du livre.
BonusSi vous avez dans l’idée de faire des pâtes de fruits, des truffes en chocolat ou je ne sais quelle autre friandise à offrir à Noël (ou le reste de l’année) mais ne savez pas comment les présenter, vous pourrez trouver un patron de ballotin à faire vous-même au format SVG ou ODG. Ce peut être une occasion de faire participer les enfants trop petits pour faire la cuisine en les faisant décorer la boite qui peut servir aussi pour des petits cadeaux.
Si vous cherchez une recette de truffes au chocolat en voici une pour environ dix truffes moyennes. Ça tiendra dans le ballotin.
Ingrédients
- 125 g de chocolat fin
- 3 cuillères à soupe d’eau
- 75 g de beurre en noisettes
- 1 jaune d’œuf
- 1 ou 2 cuillères à soupe de sucre glace
- cacao.
Préparation
Faire fondre à feu très doux le chocolat avec l’eau, bien remuer. Quand il est fondu, rajouter le beurre sans cesser de remuer et hors du feu. Puis rajouter le jaune d’œuf et le sucre glace en remuant toujours. La pâte est encore assez molle et tiède. Verser le chocolat dans une terrine et le mettre à refroidir au réfrigérateur deux ou trois heures. Pour faire la truffe : rouler une boule de pâte dans le cacao. Tenir au froid une nuit.
Bon appétit et bonne fin d’année.
-
D’ailleurs je n’ai même pas évoqué la question avec le reste de la modération. ↩
Commentaires : voir le flux Atom ouvrir dans le navigateur
Les lauréats des Acteurs du Libre 2023 révéles à Open Source Experience #OSXP2023
À l'occasion d'Open Source Experience 2023 la semaine dernière, les lauréats de l’édition 2023 du concours des Acteurs du libre ont été révéles pendant la cérémonie du 6 décembre.
Organisé pour la 7e fois, les Acteurs du Libre est devenu un rendez-vous incontournable de l’écosystème open source français et européen. Il vise à récompenser les entreprises et entrepreneurs ainsi que les projets innovants et associations qui contribuent par leurs actions au développement économiquement viable du logiciel Libre et de l’Open Source.
Six prix ont été décernés, dans les catégories suivantes:
- Prix du service public engagé : Parc national des Écrins en collaboration avec Makina Corpus
- Prix de la meilleure stratégie Open Source : CS Group
- Prix pour un numérique ouvert et éthique : Biblibre
- Prix du développement commercial : Gatling Corp
- Prix européen (en collaboration avec l’APELL) : Nextcloud
- Prix spécial du jury : Kotzilla
Retrouvez les détails concernant les attributions en seconde partie de dépêche.
- lien nᵒ 1 : Site des Acteurs du Libre
- lien nᵒ 2 : Site du CNLL
- lien nᵒ 3 : Page du communiqué
Prix du service public engagé : ce prix est remis au Parc national des Écrins, établissement public d’État et espace naturel protégé situé entre les Hautes-Alpes et l’Isère. Acteur de l’open source de longue date, le parc est récompensé notamment pour sa collaboration de long terme avec Makina Corpus pour développer Geotrek. Devenu après 10 ans de collaboration une suite logicielle très complète pour la gestion et la valorisation des activités de pleine nature, Geotrek bénéficie d’une communauté d’utilisateurs de plus de 150 structures (publiques pour la plupart).
Prix de la meilleure stratégie Open Source : CS Group, ETI spécialisée dans la conception et l’intégration de systèmes critiques reçoit le prix de la meilleure stratégie pour la maturité de sa démarche et son engagement dans l’open source, concrétisés notamment par la mise en place dès 2013 et la pérennité d’un OSPO aux missions très larges. Le jury a ailleurs noté les efforts réalisés sur la gouvernance interne de l’open source, la transversalité de l’OSPO et l’intégration dans la stratégie globale du groupe.
Prix pour un numérique ouvert et éthique : ce prix est décerné à Biblibre, SARL offrant aux bibliothèques et centres de documentation un accompagnement dans le déploiement de logiciels métiers sous licence libre. Porteuse d’un ADN open source dès sa création, Biblibre porte les valeurs de l’open source et souhaite contribuer à la construction d’un numérique ouvert. L’entreprise participe par ailleurs activement à la vie communautaire et organise elle même régulièrement des événements type Hackfest.
Prix du développement commercial : Gatling Corp (solution de tests de charge pour applications web, API et microservices) obtient le prix du développement commercial pour sa forte croissance et son ambition commerciale démontrée par une large palette de clients et de bonnes performances à l’international. Malgré son jeune âge, l’entreprise a su mettre en place les moyens nécessaires à la réalisation de son plan ambitieux.
Prix européen (en collaboration avec l’APELL) : le prix européen est décerné à Nextcloud, plateforme collaborative et site d’hébergement de fichiers, pour la clarté de sa vision et pour sa forte croissance (prévisions de +60% de revenu pour cette année et +50% du nombre d’employés). Nextcloud apporte par ailleurs un témoignage de cohabitation fructueuse entre une entreprise commerciale en croissance organique et une communauté open source (100% du code est open source), les deux parties évoluant conjointement.
Prix spécial du jury : le prix spécial du jury 2023 revient à Kotzilla, société mainteneur du framework Koin et spécialiste en accompagnement sur les architectures logicielles basées sur Kotlin. Jeune startup prometteuse créée en 2022 et qui compte maintenant 8 employés, Kotzilla a été récompensée par le jury en particulier pour la popularité internationale de son produit, pour son modèle et sa stratégie commerciale claire.
Les vainqueurs ont été désignés par un jury composé à la fois de personnalités de l'écosystème open source, d’entreprises membres des associations régionales du CNLL, représentants d’administrations et de lauréats de l’édition précédente. Ce jury est modifié chaque année.
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Revue de presse de l’April pour la semaine 49 de l’année 2023
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.
- [ZDNet France] Tribune: l'Europe s'appuie sur l'open source via les fondations, par Pierre-Yves Gibello (OW2)
- [Next] Un roman graphique explique les logiciels libres aux enfants
- [ZDNet France] Communautés des logiciels libres: 50 % de chances de survie à 4 ans
- [ZDNet France] OpenStack: quand l'open source propulse le cloud souverain
- lien nᵒ 1 : April
- lien nᵒ 2 : Revue de presse de l'April
- lien nᵒ 3 : Revue de presse de la semaine précédente
- lien nᵒ 4 :
Ada & Zangemann : retour sur une bonne impression
C’est l’histoire d’un livre découvert au boulot et d’une première dépêche écrite dans un train traversant l’Europe. Et c’est aussi l’histoire d’un ouvrage illustré Ada & Zangemann - Un conte sur les logiciels, le skateboard et la glace à la framboise, écrit par Matthias Kirschner (président de la FSFE) et illustré par Sandra Brandstätter, pour promouvoir notamment le logiciel libre avec pédagogie auprès des enfants (de 6 à 106 ans).
Et cette histoire évolue : nouvelles traductions, nouvelles versions imprimées notamment en français, nouveaux éloges, etc.
- lien nᵒ 1 : FSFE Ada & Zangemann - A tale of software, skateboards, and raspberry ice cream (386
- lien nᵒ 2 : Version française imprimée chez C&F Éditions
- lien nᵒ 3 : Dépôt Git des textes, illustrations et traductions
Les évolutions :
- deux traductions supplémentaires sont disponibles, en catalan et danois, portant le total à 8 langues disponibles
- deux versions imprimées supplémentaires, en italien (par StreetLib ou Lulu.com) et surtout, par notre lectorat francophone, en français aux éditions C&F, ISBN 978-2-37662-075-4 (depuis le 1er décembre 2023) (annoncée par deux journaux d’Alexis Kauffmann 1 et 2 ; Alexis dont le rôle dans l’existence de la version française est explicité dans la première dépêche, et que je m’empresse de citer : ce livre est 4x libre :
- son histoire parle de libre (et, sans vouloir spoiler, ça parle aussi d’exercice citoyen de la démocratie)
- sa licence est libre : la Creative Commons By-SA
- sa traduction a été réalisée collaborativement par une centaine d’élèves qui se sont coordonnés sur les outils libres de La Digitale
- sa chaîne d’édition est libre : HTML, CSS, JavaScript Paged.js + typographie libre Luciole
- la liste des éloges du lectorat s’est allongée et les premières en français ont été ajoutées. Sans compter celles d’Alexis et moi sur Linuxfr.org, une émission de France Culture, des retours de Frédéric Couchet (délégué général de l’April), et Stéphane Bortzmeyer, ou bien encore #adaZangemann sur Mastodon, ou lors de OSXP 2023
- la version française a été soutenue par le ministère français de l’Éducation nationale notamment pour que tout le monde puisse accéder librement aux versions numériques du livre le jour de sa sortie.
- cette nouvelle dépêche est encore écrite lors d’une traversée de l’Europe en train, il y a une certaine continuité.
Citant de nouveau Alexis : Si le livre vous a plu, n’hésitez pas à en parler autour de vous et à en commander des versions papiers pour vous ou vos proches (à l’approche de Noël !). Cela permettra également de témoigner que le modèle « payant/papier gratuit/numérique » est viable économiquement et de convaincre d’autres éditeurs de l’adopter à l’avenir. et pour cette édition française, Matthias Kirschner a décidé de reverser tous les droits d’auteur issus des ventes du livre en version papier à la Free Software Foundation Europe.
Télécharger ce contenu au format EPUBCommentaires : voir le flux Atom ouvrir dans le navigateur
Retrouvez la communauté francophone Drupal au Drupalcamp Rennes en mars 2024
Drupal est un système de gestion de contenu (CMS) libre et open-source publié sous la licence publique générale GNU. Drupal permet la création et l'entretien de sites Web.
Drupalcamp Rennes 2024 : l’association Drupal France et Francophonie tiendra son prochain Drupalcamp, le onzième, à la Maison des Associations de Rennes les 28, 29 et 30 mars 2024.
Tout comme en 2019 à Paris, le Drupalcamp Rennes 2024 est un évènement qui se déroule sur 3 jours. Pour 2024, nous avons organisé l’événement en fin de semaine, pour deux journées de conférences les jeudi et vendredi. La journée du samedi est réservée à la contribution.
Vous pouvez proposer votre conférence jusqu'au 17 janvier 2024. Voir l'appel à conférence.
- lien nᵒ 1 : Le site du Drupalcamp Rennes
- lien nᵒ 2 : Le site de l'association Drupal France et francophonie
- lien nᵒ 3 : Proposez votre conférence jusqu'au 17 janvier 2024
Des moments d’ateliers et micro-formation sont également au programme, pour faire de cet évènement une réussite d’un point de vue communauté autour du projet Open Source Drupal.
Comme en 2017, lors du Drupalcamp Lannion, nous organiserons un moment dédié à la traduction de Drupal en langue bretonne.
Le Drupalcamp Rennes c’est la rencontre de la communauté francophone autour du logiciel libre Drupal. Ouvert à toutes et tous, les rencontres, conférences et ateliers permettent d’adresser à un public toujours plus large des sujets et thématiques diversifiées.
Notre objectif principal est de rendre la création de sites plus simple et la gestion des contenus plus intuitive pour tous. Comme de fédérer les utilisateurs et professionnels qui utilisent Drupal au quotidien.
Du simple curieux au développeur expert, tous ceux qui s’intéressent à Drupal et aux logiciels libres pourront participer à cette manifestation rythmée par :
- des conférences (jeudi 28 et vendredi 29 mars), données par des professionnels reconnus et des membres de la communauté Drupal au cours desquels des thématiques nouvelles seront explorées,
- des sessions de découverte étayées par des démonstrations à l’intention d’un public plus néophyte,
- un créneau dédié à l’initiation pour que les curieux puissent se lancer dans la création de leur premier site (jeudi 28 mars), et un autre dédié à la contribution “qu’est-ce c’est ? comment ça marche ? je commence par quoi ?”
- des sprints et ateliers (vendredi 29 mars après-midi et samedi 30 mars toute la journée), efforts communs représentatifs de l’esprit open source, dans lesquels chacun peut apporter sa contribution pour améliorer Drupal,
- un moment dédié à la contribution de la traduction de Drupal en langue bretonne,
- des moments de réseautage et de convivialité avec, notamment, la très attendue soirée communautaire !
- Maison des associations, 6 cours des alliés, 35000 Rennes
- https://rennes2024.drupalcamp.fr
- Contact : drupalcamp@drupal.fr
Commentaires : voir le flux Atom ouvrir dans le navigateur