La mutation de CentOS 8, une tempête dans un verre d’eau pour 95% des linuxiens et linuxiennes ?

J’ai hésité avant d’écrire cet article, mais je dois dire que je n’ai plus qu’à me pencher pour récolter les sources qui vont alimenter cet article. Pour la plupart des Linuxiens de base, cette annonce n’aura aucune conséquence sur leur utilisation de l’OS au quotidien. Cela ne concerne – pour schématiser grossièrement – que les administrateurs de serveurs.

CentOS, c’est c’était la version communautaire de la Red Hat Enterprise Linux (RHEL) de même numérotation. Comme la RHEL, le support de 10 ans est un avantage non négligeable, surtout pour des serveurs dont on veut une disponibilité 24h/24 et tous les jours de l’année.

Comme l’a si bien dit un article du monde informatique, « Red Hat enterre CentOS Linux, ressucité en Rocky Linux » Oui, j’ai conservé la faute d’orthographe dans le titre. C’est un peu plus subtil que cela.

En gros, depuis un an, une branche dite « stream » de CentOS permettait d’avoir une préversion de la révision suivante de la RHEL. Red Hat a décidé de prendre CentOS dans sa totalité et l’orienter uniquement sur sa branche « stream » et avoir ainsi, si on peut le dire aussi simplement, une version bêta grandeur nature.

En gros, le schéma pour RedHat est désormais le suivant : RHEL (version finale), CentOS (version bêta), Fedora (version alpha). C’est de l’ultra-simplifié, mais l’idée est là.

Évidemment, comme le précise l’article du Monde Informatique, le créateur de la CentOS a décidé de « forker » CentOS pour revenir au point de départ : en faire une version communautaire de la RHEL. Le projet du nom de Rocky Linux ne propose sur son dépot github – au 14 décembre 2020 où j’écris cet article – qu’un ensemble de fichier readme. Mais le projet vient juste d’être lancé, donc restons patients 🙂

Pour les adminisrateurs systèmes qui utilisent CentOS, quelles sont les options disponibles ? Soit sortir le portefeuille et passer sur du RHEL, soit utiliser un autre « fork » de RHEL.

Certains proposeront le passage à Debian, soit. Mais outre le fait qu’il faudra réinstaller les serveurs, la durée de support d’une Debian donnée est passée de 5 à 7 ans. Il existe maintenant une version dite ELTS (pour extended LTS) payant (2040€ pour 6 mois) qui rajoute 2 années de support supplémentaires avec les 2 ans de la période classique LTS qui faisait passer le support de 3 à 5 ans.

Continuer la lecture de « La mutation de CentOS 8, une tempête dans un verre d’eau pour 95% des linuxiens et linuxiennes ? »

Vieux Geek, épisode 238 : les FPS nuls basés sur le Build Engine, première partie.

C’est un épisode divisé en deux que j’ai envie de faire ici. Si on parle du Build Engine, on pense tout de suite à des titres comme Duke Nukem 3D (janvier 1996), Blood (mai/juin 1997), Shadow Warrior (mars 1997) ou encore Redneck Rampage (avril 1997).

Les quatre titres en question se base sur une version finalisé du moteur de rendu, le Build Engine. Et ce sont des titres qui sont d’un bon niveau, même si j’ai rapidement apprécié les jeux vraiment 3D avec l’arrivée du premier Quake en 1996.

Cependant, il y a d’autres titres qui ont utilisés des versions préliminaires du moteur de rendu et qui sont graphiquement, ergonomiquement, et en terme de jouabilité des ratages complets.

Je vais donc parler de deux titres, sorti par le même développeur, Capstone Software. On va y aller par ordre chronologique de sortie en commençant par Witchaven.

Il est sorti en septembre 1995, et c’est un FPS un peu spécial. Car il reprend des éléments de jeu de roles et surtout tous les combats se font au corps à corps. Ce qui est un peu déroutant, même si l’excellent Hexen, publié en octore 1995 utilise les mêmes principes, sauf que lui, il a de la gueule ! J’en ai rapidement parlé dans l’épisode 16 de la série vieux geek.

On a droit à un scénario assez classique. On joue le role de Grondoval, un chevalier choisi par son maître, Lord Verkapheron d’aller détruire la menace du diabolique Illwhyrin, dans son antre, le royaume de Witchaven.

Continuer la lecture de « Vieux Geek, épisode 238 : les FPS nuls basés sur le Build Engine, première partie. »

Vieux Geek, épisode 237 : Mozilla Firebird, une préversion presque oubliée de Mozilla Firefox.

L’histoire du navigateur web Mozilla Firefox a été assez mouvementée durant ses deux premières années, de septembre 2002 à novembre 2004, l’époque des version 0.x.y. Si les 5 premières préversions s’appellait Mozilla Phoenix, nom qui avait du être abandonné suite à la demande du fabricant de Bios Phenix, les version 0.6.x et 0.7.x eurent pour nom, non pas Mozilla Firefox, mais Mozilla Firebird.

Les version 0.6.x et 0.7.x couvre l’année 2003 et le début de l’année 2004. Sauf erreur de ma part, la première version à s’appeller Mozilla Firefox remonte à début février 2004. Un article de Tom’s Hardware semble confirmer ce souvenir.

Mais à quoi ressemblait donc cette ancestrale version ? Je vous emmene en voyage en 2003… Ça va rappeler des bons et moins bons souvenirs à la plupart des personnes, mais c’est le prix de la nostalgie…

Évidemment, essayer d’utiliser un navigateur vieux de 17 ans sur la toile de 2020, cela tient de la gageure, voire du masochisme. Mais si vous avez envie de tester cette ancestrale version, la Fondation Mozilla conserve une archive sur leur serveur FTP.

Bonne (re)découverte 🙂

Les installateurs facilitants pour Archlinux… Mieux vaut en rire qu’en pleurer, surtout en cas de pépins…

Je dois vous raconter mes petites mésaventures matinales pour vous faire mieux comprendre le pourquoi du comment de ce billet. Mais commençons par un peu de contexte.

Hier soir, le 22 novembre, je suis allé sur le forum d’EndeavourOS et je suis tombé sur un fil concernant une modification concernant le logiciel CUPS qui est l’outil de gestion des imprimantes dans le monde linuxien.

En effet, Apple qui a maintenu durant des années le code de CUPS l’a laissé pourrir toute l’année 2020. Si on regarde au niveau des modifications de code en ce 23 novembre 2020, une seule entrée le 27 avril pour dire que CUPS 2.3.3 était sorti. Je ne sais pas pourquoi, mais ce code en train de se dessécher à l’air libre, ça me rappelle les conditions de naissance d’un certain LibreOffice.

Un fork – plus qu’utile pour une fois – a été lancé par l’organisation OpenPrinting. Sur le fil du forum d’EndeavourOS, j’ai appris qu’il fallait modifier le service pour lancer cups. En effet, on est passé du service org.cups.cupsd à cups.service. Ce qui est ennuyeux pour les installations automatisées.

Autant dire que la plupart des installateurs facilitant sont impactés jusqu’à la sortie d’une nouvelle version et si on utilise un d’entre eux actuellement, comme Anarchy, EndeavourOS, RebornOS ou encore Calam Arch Installer, c’est mal barré pour avoir le service CUPS fonctionnel au démarrage si le besoin s’en fait sentir.

J’en ai profité pour prévenir Chennux qui maintient un « fork » de mon guide d’installation pour Archlinux sur github. Ainsi qu’Anarchy pour qu’il corrige le code touché par la modification du service utilisé.

Imaginez donc la bonne surprise avec un installateur non à jour en ce qui concerne CUPS. Bienvenue dans les joies de l’administration d’une base Archlinux.

J’ai fini la parenthèse du contexte. Ce matin, je vais sur youtube et je tombe sur une vidéo promouvant Calam Arch Installer (qui ressemble étrangement à EndeavourOS sur le plan des principes utilisés). Je me suis dit que la vidéo en question tombait bien mal.

Une nouvelle fois, ce n’est pas l’installation d’une Archlinux qui est complexe, il suffit de savoir lire et d’avoir de bonnes bases en anglais. C’est la maintenance sur le long terme, et quand ce petit genre de pépin arrive, nombre de personnes qui ne se doutaient pas de la difficulté d’administrer une installation d’Archlinux bazarderont le tout.

Mais il est vrai que ce n’est que la quinzième fois que je parle de ce problème… Mais comme on dit : il n’y a pas pire sourd que la personne qui se bouche les oreilles. Sur ce, bonne journée 🙂

Vieux Geek, épisode 236 : L’Aigle d’Or, le vrai premier jeu d’aventure-exploration.

Dans un article publié le 16 novembre 2020, je parlais d’un jeu sorti sur Amstrad CPC pour un concours de développement créé en hommage à « L’Aigle d’Or » publié en 1984 par Loriciels sur Oric.

Il faut se replonger dans le contexte de l’époque. Le krach du jeu vidéo a laminé le monde des consoles de jeu. En 1984, les ordinateurs personnels 8 bits ont le vent en poupe. Il ne faut pas oublier que le Commodore 64 est vieux de 2 ans à l’époque. C’est l’année de sortie du premier Amstrad à cassette, du MO5 de Thomson pour citer quelques machines mythiques de l’époque. Il y a aussi les ordinateurs de la famille des Oric avec l’Oric 1 puis l’Atmos.

C’est sur les ordinateurs Oric que Louis-Marie Rocques se lance dans le développement d’un jeu d’aventure et d’exploration où le joueur doit trouver trois objets dans un chateau qui multiplie les pièges : un diamant bleu, un grimoire et surtout un aigle en or.

Continuer la lecture de « Vieux Geek, épisode 236 : L’Aigle d’Or, le vrai premier jeu d’aventure-exploration. »