Il y a environ 5 ans, durant l’été 2016, devant le nombre toujours plus important de distributions dont l’intérêt était proche de zéro, je lançais quand j’étais encore youtubeur, la série des DGLFI. J’ai depuis migré l’ensemble sur mon compte peertube.fr.

Depuis, en comptant les épisodes bilans et les épisodes réguliers, je suis arrivé le 19 juillet 2021 au 43ème épisode que vous trouverez ci-dessous.

Dans l’épisode qui faisait le bilan de la première « saison », sur 11 distributions, il en restait 8 en vie, cf la capture d’écran ci-après.

Depuis, la SwagArch et la Cubuntu nous ont quitté. Donc 6 sur les 11 de la première « saison » des DGLFI.

Pour la saison 2, allant de l’épisode 13 au 25, bien que la vidéo bilan se limitait à l’époque à l’épisode 21, à cause d’un recul trop faible pour les épisodes 22 à 24.

Sur les 9, 2 étaient mortes. Depuis, la CondresOS, la NetRunner Rolling, la RareOS nous ont quitté. Ce qui ne fait plus que 5 projets qui ont survécu.

Depuis, donc il me reste à faire le bilan des épisodes 22, 23, 24 et des épisodes 26 à 40, histoire d’avoir au minimum 3 mois de recul. Sur les 18 épisodes, le 29 étant complémentaire au 25, combien de distributions sont encore vivantes ? Faisons donc le bilan en vidéo.

Sur les 17 épisodes et donc distributions citées, il en reste 10 de vivantes dont 2 sont indexées sur distrowatch. Un bilan plutôt positif pour les projets survivants, même si l’idée que les projets redondants ne durent pas longtemps est plutôt contredite ici.

Sur les 37 épisodes et donc projets en relation, en l’espace de 5 ans, il reste 20 sur 37. Ce qui est énorme. Encore une fois, le « darwinisme logiciel » dont certaines personnes parlent est inexistant.

Je dis cela, mais je dis rien.

Allez, sans rancune et bonne fin de journée.

Fin mai 2021, je faisais un bilan de ma dé-GAFAM-isation. Ce n’était pas trop mal : agenda auto-hébergé (plus de Google Agenda) sur un Raspberry Pi 2, serveur pour héberger le blog et l’instance peertube (Youtube uniquement en tant que « spectateur »).

Je disais aussi ceci :

[…]
Le reste n’a pas bougé, même si j’envisage fortement – j’ai un serveur qui héberge le blog et qui peut me laisser entrevoir l’hébergement d’une copie de ma musique en ligne en utilisant un service comme Funkwhale.
[…]

Ce dernier point a été traité. Depuis la mi-juin 2021, j’ai une instance privée FunkWhale qui héberge mes quelques 100 Go de musique. Étant donné que j’étais encore à l’époque avec une connexion VDSL2, cela m’a pris une petite semaine pour tout envoyer. Avec la fibre ? Une après-midi aurait été suffisante je pense, même si le traitement des fichiers était un peu long.

Mais c’est fait. On dit souvent que l’informatique est l’école de la patience, c’est le cas. J’avais été franchement déçu par Youtube Music qui ne permettait de réduire l’application dédiée que si on s’abonnait auprès de Google. Autant dire que quand j’ai purgé la bibliothèque importée, j’ai senti un grand ouf de soulagement.

Voici donc un aperçu de la vue albums de mon instance Funkwhale. Vous remarquerez que j’ai caché l’adresse. Même si vous pouviez la deviner, vous ne pourriez pas y accéder. L’ami qui a mis en place l’instance l’a bien sécurisée. Sans rentrer trop dans les détails, seules certaines adresses IPs sont admises… Les miennes, ce qui est logique après tout

Si je me balade, même si ce n’est pas bien sur le plan de la sécurité ? Une connexion par VPN. Pour l’écoute ? J’utilise l’application Otter pour mon Redmi Note 7, conseillée sur le site officiel de Funkwhale. J’ai fait deux captures d’écran chez moi, je n’avais pas pensé à les faire en déplacement

La vue d’un album en cours de lecture :

La vue albums :

J’ai retrouvé ainsi la praticité assez intéressante du client Google Music, que l’on pouvait mettre en arrière plan, même si ce service dépendait du mastodonte californien.

Y aura-t-il une prochaine étape ? On verra bien

Dans un précédent article, je disais que je passais une semaine où je rapportais chaque jour – ou presque – un nouveau bug.

Le 14 juillet n’a pas été exempt d’un rapport d’un bug. Cette fois, concernant Dosbox-X et le support des modes graphiques des machines Amstrad PC1512/1640. Tout est parti d’une remarque postée par Benedikt Freisen sur les modes graphiques de l’Amstrad PC1512/1640 – dont j’ai parlé dans un article vieux geek en août 2020 – qui parlait d’une étrangeté avec un mode CGA pseudo-monochrome.

J’ai donc voulu vérifier et quand je lançais Dosbox-X avec comme option machine=amstrad, j’avais droit à un plantage en beauté.

J’ai donc rapporté le bug, et je me suis aperçu que cette régression fut introduite entre Dosbox-X 0.83.13 (sorti début mai 2021) et la version 0.83.14 (sortie en juin 2021).

Après quelques conseils pour pouvoir détecter le jour de la régression – et soyons fous – l’ajout de code responsable de celle-ci, je me suis mis à la longue recherche. Après un faux départ, j’ai décidé de prendre les choses de manière plus méthodique. J’ai pris la référence de la dernière modification de chaque jour.

Pour retrouver le code, j’ai utilisé la commande : git checkout référence

Ensuite, j’utilisais le script de compilation build, puis j’allais dans le répertoire src pour lancer le dosbox-x obtenu. Si ça plantait, je passais au jour précédent, sans nettoyer l’ensemble auparavant avec un make distclean, en réinitialisant le dépot git (pour ne pas avoir de problème de branche orpheline) avec la commande git switch -.

Une fois tout cela fait, je recommençais la même danse. En comptant 5 minutes de compilation, et 2 autres pour le test et le nettoyage, ça me permettait de tester en gros 8 jours par heure. Avec un mois de 31 jours, en espérant ne pas aller jusqu’au 1er, vous imaginez le nombre de compilations… Par chance, j’ai fini par trouver que le dernier jour fonctionnel était le 14 mai… Donc 13 jours de tests évités

Par chance, il n’y a eu que deux ajouts de code durant le 15 mai, ce qui réduit le nombre de tests à faire. Et comme je l’avais ressenti, c’était le commit 5860652 qui faisait planter Dosbox-X au démarrage.

Décidément, la semaine du 12 juillet 2021 restera pour moi la semaine à bugs de l’année 2021.

C’est en discutant avec une personne sur le réseau (a)social Mastodon que je me suis souvenu d’un site que j’avais créé et maintenu entre fin 1998 et fin 2002. Un site où je regroupais des easter eggs, des petites parodies rapidement faites sous GIMP.

À l’époque, j’étais encore en connexion RTC puis RNIS (dont le nom commercial était Numéris). Il est vrai que je me fournissais en matière sur le site « The Easter Egg Archive ».

À l’époque j’avais acheté un nom de domaine qui transitait via un hébergeur qui a disparu dans l’explosion de la bulle Internet et qui s’appelait citeweb.net.

J’avais tout codé à la main – quand ce genre d’activité était encore possible – en utilisant les frames qui ont disparu dans les années 2005-2010. Je pensais que tout le contenu était perdu à jamais, mais via l’Internet Wayback Machine, j’ai pu retomber sur des captures du site plus ou moins complète, plus ou moins utilisables.

Je me suis dit qu’il serait bien que je fasse une vidéo pour rendre un dernier hommage à toute cette époque qui remonte à plus de 20 ans. Donc acte !

Oui, ce site était à l’image de ce que l’on pouvait trouver à l’époque. Les frames lui donne un côté vintage. Sans oublier que je ne me souvenais pas de la moitié des pages que j’avais créé à l’époque pour chaque logiciel.

Une époque révolue où l’on codait tout à la main, loin des CMS qui mâchent le travail… Mais au final, je suis bien content d’avoir un WordPress qui génère à la volée les pages pour qu’elles soient affichées dans mon navigateur !

Quand Audacity 3 est sorti, un scandale est arrivé avec lui. Après son rachat par Muse Group, une télémétrie que l’on peut qualifier d’agressive a été rajoutée. Avec une politique de confidentialité assez bizarre. En effet, en recherchant des informations, je suis tombé sur cet article du Monde Informatique du 5 juillet 2021.

Je cite :

Cette politique de confidentialité interdit également aux personnes de moins de 13 ans d’utiliser le logiciel, ce qui, comme le précise FOSS Post, constitue une violation de la licence GPL utilisée par Audacity.

Il n’en fallait pas moins pour que le code source d’origine soit recopié pour être purgé de la partie télémétrie. Deux projets sont apparemment les plus vivaces : Tenacity et Sneedacity. Le premier étant la suite du fork lancé par un développeur au pseudo de Cookie Engineer, l’autre par la communauté de 4chan.

Il s’en serait suivi une campagne de harcèlement à cause du nom du logiciel, allant apparemment jusqu’à des menaces au couteau… Pour l’instant, tout ceci est à prendre avec des pincettes.

Plus d’infos sur ce bug de github et sur un fil reddit.

Pour tout dire, je ne sais pas quoi penser d’une telle déclaration. J’ai voulu voir si les deux forks en question étaient disponibles sur le grand livre de recettes qu’est AUR. Au 13 juillet, je n’ai pu trouver qu’une recette pour Tenacity. Le fork Sneedacity semblant être ignoré pour le moment.

La compilation de ce fork en cours de consolidation – et qui utilise comme base le code d’Audacity 3.0.3 ? – est assez laxative. Voici l’ordre et la liste des paquets à faire compiler.

1. python-patch-ng
2. python-node-semver
3. python-plugin-base
4. conan
5. tenacity-git

Je ne suis pas un utilisateur avancé d’Audacity, m’en servant ponctuellement. J’ai néanmoins fait une vidéo rapide pour montrer ce fork en action. Je dois dire que je ne me suis pas plongé dans les options avancées. C’est beaucoup trop tôt pour le faire, le scandale liée à la télémétrie ayant éclaté début juillet 2021.

Vous avez pu voir, il n’y a pas grand chose de différent par rapport à une version 2.x d’Audacity qui est exempte de toute surprise télémétrique. Qui de Sneedacity ou Tenacity survivra ? Difficile à dire. Mais je me souviens que dans un cas de figure comparable pour OpenOffice.org, le choix avait été vite fait. La dynamique insufflée par LibreOffice lui donnait un avantage non négligeable.

Il faudra voir d’ici la fin de l’année 2021, voire début 2022 pour savoir quel fork aura la reconnaissance des distributions GNU/Linux qui sera la cible technique à conquérir pour les deux forks.