Catégorie : Libreries

Logiciel libre (linux et autres)

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 !

Dosbox-X ou PCEm pour les vieux jeux MS-DOS et MS-Windows 1.x à 3.x ?

Dans la cadre de ma série de billets « Vieux Geeks », j’utilise très régulièrement des jeux sous MS-DOS, voire parfois des vieux MS-Windows de la génération 1.x à 3.x. Cependant, il existe au moins deux outils qui peuvent s’avérer utile : Dosbox-X (un des meilleurs forks de Dosbox sur le plan ergonomie) et PCEm qui est plus orienté émulation de vieux PC (comme l’IBM PC 5150, le Tandy 1000 par exemple).

Dans l’épisode 83 de ma série de vidéos « C’est trolldi, c’est permis », j’avais utilisé Dosbox-X pour émuler l’environnement matériel et logiciel minimal requis pour lancer Doom… J’ai bien dit lancer, pas jouer 🙂

Je me suis demandé si les résultats obtenus étaient réalistes. J’ai donc pris PCEm et j’ai reproduit l’expérience en prenant un PC émulé avec un 386SX, 4 Mo de mémoire vie, un MS-DOS 3.3, etc… J’ai enregistré l’ensemble même si j’ai un brin galéré dans la dernière partie de la vidéo.

Ma conclusion est assez pragmatique : les deux se complètent. PCEm sera vraiment pratique si j’ai besoin d’un vieux MS-Windows ou d’utiliser un matériel émulé uniquement par PCEm, comme une carte vidéo Plantronics par exemple.

D’un autre côté, des jeux bien ennuyeux à lancer et qui demandait de créer des disquettes de démarrage pour avoir la bonne quantité de mémoire vive conventielle, de mémoire paginée (EMS) de mémoire étendue (XMS) passeront mieux avec Dosbox-X.

C’est donc souvent du « cas par cas » en fonction du logiciel à faire fonctionner. On est ici plus dans la complémentarité que dans la concurrence frontale.

Vieux Geek, épisode 279 : Bastet, le Tetris qui vous fera détester Tetris.

Je dois l’avouer, il y a deux genres que j’aime beaucoup : les FPS et les Tetris. J’ai claqué des sommes folles quand j’étais lycéen dans la borne d’arcade de la maison des jeunes d’Arcachon.

Même si cela remonte à 30 ans, j’ai encore honte d’avouer la somme faramineuse qui a été dévorée par la borne d’arcade.

Quand je suis arrivé sur Linux, j’ai recherché des clones de Tetris et je suis tombé sur l’excellent LTris que j’ai évoqué dans l’épisode 164 de la série Vieux Geek en septembre 2019.

Dans la série des clones de Tetris, il y en a un qui se distinguait de part son principe : proposer la pire pièce à chaque fois. Son petit nom « Bastet » pour « Bastard Tetris ». Et je peux vous confirmer qu’il est spécialement vicieux dans ce domaine. Je tiens à remercier SuperMarioS de l’avoir évoqué au détour d’une conversation.

C’est un jeu en ncurses qui se joue dans un terminal. Il a connu son heure de gloire du début des années 2000 jusqu’au milieu des années 2010. Le site officiel annonce comme dernière version la 0.43.1 datant de 2014.

Cependant, si on va sur le dépôt github, la dernière version date de 2017, la 0.43.2.

Mais le plus simple est de vous montrer cette purge en action.

Oui, j’ai rapidement perdu et encore j’étais au niveau de difficulté normale. C’est un Tetris qui se mérite, même si vous aurez souvent envie de l’envoyer à la corbeille.

Bonne découverte !

Que sont devenues les distributions GNU/Linux de 2016, sixième épisode, juillet 2016.

Après un mois de juin 2016 assez clément, quel va être le bilan de juillet 2016 ?

Bilan : quatre projets, tous en vie, même si la MicroLinux Desktop Environment a changé de base et que la Frugalware semble tourner au ralenti, on est donc avec un taux de survie de 100%. C’est la deuxième fois cette année, non ?

La résurrection de la NuTyX, 3 jours après sa mise à mort… Ou pourquoi le monde des distributions GNU/Linux est immature donc non fiable.

Je comptais ne pas en parler, mais la résurrection en 72 heures chrono – ou presque – de la NuTyX alors que l’annonce de la mort de celle-ci avait été annoncé sur Distrowatch, capture d’écran de l’annonce sur distrowatch à l’appui, la page ayant été effacée par l’équipe de NuTyX.

Mais par « chance » ou simplement par un flair que j’ai appris à développer, j’avais fait une capture d’écran de la dite mort. Donc voici ce qu’affichait le site avant de nous sortir maintenant une annonce technique remplies de « nouveautés » concernant le projet.

Le coup de la mise à mort de NuTyX avait déjà été faite en décembre 2012 avant qu’un bon semestre plus tard, le projet ne reparte de plus belle. Au moins, il y avait un délai qui avait été respecté… Ici, cela tient du changement d’avis comme une girouette agitée par une tornade F5 sur l’échelle de Fujita.

Avant qu’on me dise que c’est de l’attaque frontale, je ne dirai qu’une chose : quelle crédibilité accorder à un projet qui annonce sa mort le mercredi d’une semaine donnée et qui revient à la vie le dimanche suivant…

Continuer la lecture de « La résurrection de la NuTyX, 3 jours après sa mise à mort… Ou pourquoi le monde des distributions GNU/Linux est immature donc non fiable. »