Y a pas à dire… Il y a des semaines à bugs…

Il y a des semaines qui commencent en fanfare sur le plan informatique. Celle qui a commencé le 12 juillet est une semaine qui va être bien chargée côté bugs rapportés sur les différents projets que j’utilise au quotidien.

Aveu préliminaire : j’utilise pas mal de logiciels en version de développement, il est donc normal que je sois face à des bugs. Pour être plus clair, oui, je cherche la merde.

Tout a commencé dimanche 11 juillet dans l’après-midi. En voulant mettre en place une machine virtuelle avec EndeavourOS à l’intérieur, je m’aperçois de la présence de plantages avec LightDM. En fouillant sur l’outil de suivi de bugs d’Archlinux, je tombe sur une entrée qui colle à mon problème.

Je finis par trouver le bug correspondant sur l’outil de suivi de Xorg, et après avoir recherché le code responsable, je trouve l’ajout qui semble être responsable du merdier.

Premier bug de la semaine en voie d’avancement pour la correction. Le deuxième est plus marrant, car on pourrait parler de bug en cascade. Je m’explique.

Je suis utilisateur et mainteneur sur AUR de qemu-git, la version de développement de Qemu qui est un peu la version 100% libre de VirtualBox. Oui, je sais que les puristes vont sortir les torches et préparer le bûcher pour m’y faire cuire comme une merguez, mais c’est pour l’image.

Aux alentours du 7 juillet, j’avais rapporté un bug de compilation qui faisait que le processus s’arrêtait très tôt. Un correctif a été créé et ajouté dans un lot d’autres correctifs. Pour le moment, tout allait bien. Mais non.

Je tente donc lundi après-midi de faire compiler une nouvelle version de développement pour voir si le code ajouté est correct. C’est le cas, mais j’ai droit à un nouveau plantage plutôt tardif du processus de compilation.

J’ai donc ouvert un autre bug dans la foulée… On parie que le correctif pour ce problème fera exploser en vol une nouvelle fois la compilation ?

J’ai aussi parlé rapidement d’un bug que j’ai découvert dans la version de développement de Dosbox-X, mais je vous renvoie à l’article correspondant.

Déjà 4 bugs, et on est que mardi matin… Mais quand on aime, on ne compte pas.

Ce matin, je voulais faire compiler le code de développement de l’émulateur Vice (Commodore PET, Vic20, C64/128, Plus4) et j’ai eu droit à un autre bug de compilation.

Un cinquième bug, le quatrième que j’ai ouvert en l’espace de moins de 36 heures, rédigeant ce billet vers 10 h 00 du matin.

Sur le forum d’EndeavourOS, j’ai pris comme « surnom » sur ma fiche un humoristique « Bugman approved! ». À croire qu’en ce moment, ça me colle bien à la peau !

T-Rex 64, un Flappy Bird nouvelle génération pour le Commodore 64 ?

J’ai déjà eu l’occasion de le prouver, j’adore la rétro-informatique. La scène du Commodore 64 est plutôt vivace (quand on sait que l’ordinateur fêtera ses 40 ans en 2022, ça fait chaud au coeur…) et les développeurs ne manquent pas d’ingéniosité pour proposer des nouveautés ludiques.

Même si parfois, ce sont des hommages plus ou moins déguisés à des jeux ayant fait un carton quelques années auparavant. Dans ce domaine, il y a eu le jeu à courte durée de vie « Flappy Bird » qui devint le jeu à avoir sur son téléphone portable fin 2013 début 2014.

Devoir guider cet oiseau au QI négatif entre des tuyaux pour avoir le score le plus important possible a dû être à l’origine de pas mal de crise de colère.

En ce milieu d’année 2021, des développeurs de la scène Commodore 64 ont décidé de reprendre le principe en prenant l’easter-egg du navigateur Google Chrome / Chromium qui apparait quand on est hors connexion : le T-Rex qui s’affiche sur le fond de l’écran du navigateur.

Le jeu s’appelle « T-Rex 64 » et le principe est simple : finir chaque niveau en évitant de tomber sur un animal ou un cactus. À ce que j’ai pu voir, il y a trois niveau à finir pour le moment… Et venir déjà à bout des deux premiers vous demandera pas mal d’entraînement.

Vous avez pu le voir, le jeu est tout mignon, le principe simple à comprendre mais difficile à maitriser.

Essayez-le, vous comprendrez !

Allez, bon courage et heureux de vous avoir connu avec des nerfs à-peu-près en bon état 😀

En vrac de milieu de semaine…

Un court billet, en ce début de mois de juin plutôt chaud.

Côté informatique :

Côté culture :

Pour finir l’article, une petite vidéo de la série des distributions GNU/Linux (in)justement oubliées dédiée à la VeltOS.

Bonne fin de semaine 🙂

Vive le « vieux-connisme » en informatique ! :)

Cet article m’a été inspiré par la longue réflexion de Didier sur la peste que sont devenues les rustines en informatique. C’est le deuxième, après un consacré à une geekerie un peu chtarbée 🙂

Oui, deux articles coup sur coup, ça fait beaucoup. Mais je dois dire que la prose de Didier m’a particulièrement inspirée. Et écouter l’excellent « Dehumanizer » de Black Sabbath (deuxième époque Dio) colle parfaitement au contenu de cet article 🙂

Dans son long article, Didier pointe du doigt ce qui rend l’informatique moderne indigeste, comme l’ajout de couches les unes au dessus des autres, que ce soit .net, DirectX ou des cadriciels à la electron.

On ne parle plus de développer les logiciels en langage de bas niveau, comme l’assembleur, le C ou le C++. Programmer en assembleur sur des Ryzen ou des Core iQuelquechose ? Bon courage 🙂

Depuis des années, on a droit à des cadriciels pour simplifier le développement… Mais les dits cadriciels (frameworks en anglais) sont devenus des monstruisités en terme de taille. Si on prend electron (orienté technologies internet), on se retrouve avec le logiciel lui même qui dépasse les 160 Mo en dehors des dépendances à installer.

Avec les dependances, on arrive à quoi ? Dans les 500 Mo ? Pour mémoire, MS-Windows XP – qui a eu la plus longue durée de vie à savoir 13 ans – avait les pré-requis système suivants en ce qui concerne l’espace disque : 1,5 Go minimum, 6 recommandés.

Je sais, on parle d’un OS sorti il y a 20 ans, mais voir qu’un cadriciel seul doit peser avec ses dépendances pas loin du tiers de ce qui était nécessaire au minimum pour installer MS-Windows XP, ça fait peur !

Comme l’a si bien dit Didier et je me permets de le citer ici :

[…]
Je vous laisse méditer sur le fait qu’un ordinateur d’aujourd’hui qui a plusieurs coeurs à plusieurs Gigahertz, des mémoires et disques SSD met presque plus de temps pour arriver à l’ouverture d’un traitement de texte que je ne pouvais le faire dans les années 80.
[…]

Je n’ai pas utilisé de traitement de texte dans les années 1980, mais lancer Microsoft Word au milieu des années 1990, ça demandait une trentaine de secondes sur des 486/Pentium et des disques durs qui n’étaient pas foudre de guerre.

Par comparaison – qui vaut ce qu’elle vaut – lancer LibreOffice depuis mon nvme, c’est facilement une dizaine de secondes. Et on ne peut pas dire que la bande passante d’un nvme est du même niveau que celle d’un disque dur des années 1995 à 2000.

Continuer la lecture de « Vive le « vieux-connisme » en informatique ! 🙂 »

Relachons-nous un brin au niveau du string… OpenBSD pour des jeux vidéos, ça donne quoi ?

L’idée m’est venue en lisant l’article de Didier alias Iceman sur la peste technique que sont devenues les rustines. Oui, parfois mon cerveau fait des drôles de mélange. Est-ce lié au fait que j’écoute en même temps que je rédige cet article l’excellente compilation « Memento » du groupe Dead Can Dance ? Je n’en sais rien 🙂

Je dois dire que j’ai toujours eu un petit coup de coeur pour le plus sécurisé des BSD libres que l’on imaginerait plutôt en train de faire tourner un routeur ou un site web.

J’avais donc récupéré la dernière image ISO en date d’OpenBSD, la 6.9 au moment où je rédige cet article, puis je l’ai installé dans une machine virtuelle qemu. Cependant, à cause de bugs étranges de VirtManager, j’ai dû repasser par la ligne de commande et utiliser l’alias suivant pour entrer le maximum d’options :

alias kvm64-ob='qemu-system-x86_64 -enable-kvm -smp 4 -device ac97 -k fr -m 4096 -vga qxl'

Oui, c’est cryptique. Mais j’ai réussi à me débrouiller à installer Xfce, le passer partiellement en français en utilisant le wiki d’OpenBSD pour tous – j’avais oublié de modifier les réglages de root ! – et j’ai rajouté le duo dosbox en version 0.74-3 et Vice en version 3.5.

Les deux jeux que j’avais envie de tester ? Planet X3 (pour le côté MS-DOS) et Attack of the PETSCII Robots (pour le côté Commodore 64). Il faut dire qu’à l’origine les vidéos étaient à destination des groupes Facebook consacrés à Planet-X3 (qui est public) et à Attack of the PETSCII Robots (qui est privé par contre).

Continuer la lecture de « Relachons-nous un brin au niveau du string… OpenBSD pour des jeux vidéos, ça donne quoi ? »