De mes débuts (été 1997) à l’arrivée à Arcachon et son ADSL 512 Kbps en 2002, j’ai été un grand utilisateur d’un outil qui permettait de gérer un accès aux forums de Usenet en étant déconnecté. Son nom ? Hamster.
Oui, le site pour la version française fait vieux, le code n’ayant pas bougé depuis l’année 2002. Non, je n’ai oublié aucun « 2 » dans l’année 🙂
Comme l’animal de compagnie, le logiciel récupérait les dernières modifications de vos forums usenet préféré et les stockait en local. On pouvait alors se déconnecter, répondre tranquillement, et se connecter à nouveau pour synchroniser les forums.
De nos jours, les forums Usenet ne sont plus fréquentés que par une minorité d’utilisateurs. Mon FAI actuel ne me propose même plus d’accéder à ce genre de forums, ce qui est dommage… Mais il faut dire que les réseaux (a)sociaux, les forums sur la toile, et les réseaux de micro-messages (comme Twitter et son clone libre Mastodon) ont pris le relai.
C’est dommage, car j’aimais bien cette ambiance, surtout quand j’utilisais un outil de lecture de forums Usenet un peu bizarre, Xnews.
C’est parfois douloureux d’être un vieux de la vieille sur Internet…
Salut,
Il n’y a en effet plus grand monde sur Usenet fr.*.
Ceci dit, j’ai récemment posé une question sur fr.comp.lang.python qui a réveillé deux ou trois personnes (merci à elles), puis elles se sont rendormies 😉
Je pense que c’est plutôt Reddit qui a pris le relais. Mais le français a disparu.
Et aujourd’hui en 2022, on a encore Hamster mais avec un X en plus, et qui utilise plus le rouleau de sopalin que Usenet lol
Bon OK je sors…
Petit canaillou, va ! 🙂
Salut,
Petit hors sujet : Est-ce que tu as des retours sur la mise à jour de Grub ? Se passe t’elle sans accro ? Parce que mon ordi n’a pas aimé du tout cette maj ! Pas du tout… Me renvoyant au menu de démarrage ! Je suis sous Endeavour OS/Gnome.
Heureusement saint Clonezilla veille aimablement sur mon ordinateur !
Au temps pour moi… Finalement je n’ai pas besoin de tes lumières, il eut fallu que je m’informe de mon côté pour avoir la réponse ! https://endeavouros.com/news/full-transparency-on-the-grub-issue/ Merci quand même ! 🙂
alors après analyse ,
on a trouvé le « commit » qui fout la m….. côté git savannah grub :
sur une idée de vouloir mettre la maj firmware ( fwupdt ) qui au départ est spécificité UEFI , étendre au bios sans le vérifier ( et je ne parle pas de secure ou luks et encryptage ) , le grub démarre en boucle sur les bios , et pour certains UEFI il y a erreurs et arret
https://forum.manjaro.org/t/issues-with-grub-on-the-unstable-branch/120327/32
bref , un truc codé qui n’a pas du tout été testé suffisamment ni par redhat ni par oracle ,
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=26031d3b101648352e4e427f04bf69d320088e77
je rappelle au passage que depuis estampillage 2.06 , i l y a plus de 15 mois avec les soucis de vulnérabilités qui a vu passé 317 patches , depuis l’équipe a repris à la base les fondements , mais ce n’est pas ce qu’il manque au niveau commit depuis
cela ne suffit pas à valider pour une très grande majorité de Bios / UEFI réparti dans le monde.
on peut même être très méchant sur le code montré du doigt ,
– cela ne fonctionne qu’en UEFI
– cela ne fonctionne pas en Bios
– et que se passe-til pour les démarrages types ( rayer la mention inutiles )
Bios, CSM , Legacy , secure boot , et qui pourtant il y a bien un GPT /uefi installé ( ex microsoft ) , il a la possibilité de faire la maj firmware dans cette situation ?
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=26031d3b101648352e4e427f04bf69d320088e77
j’ai de mon côté appliqué la consigne , mais le retour de efibootmgr est moche avec les caractères parasites
Je lis dans https://endeavouros.com/news/full-transparency-on-the-grub-issue/ ceci:
We were already considering moving away from grub by default and that may happen at some point in the future.
First we will wait to see what Arch decides to do moving forward and then we will make a long-term decision.
Cette réaction me paraît excessive. Il aurait suffi de ne pas sauter sur les derniers commits sans les tester suffisamment: celui-ci fait partie d’un lot datant d’il y a seulement 9 jours, selon le journal: https://git.savannah.gnu.org/cgit/grub.git/log/ d’autant que ce lot ne comporte aucun correctif de sécurité, autant que je sache (je suis abonné à la liste grub-devel).
D’autre part ce problème aurait dû être signalé ici, me semble-t-il: https://git.savannah.gnu.org/cgit/grub.git/log/
Bon, c’est juste mon avis d’observateur extérieur … En tous cas, il est hors de question d’abandonner GRUB pour Slint.
Didier ,
à la vue des dégâts que cela a générer , et que côté EndevourOs , il est bien indiqué qu’il ne le gère pas par un dépôt transitoire qui aurait pu invalider ces commits , nous avons en état :
– une « solution » de contournement
– et un retour de décision par équipe dev Grub sur ce point invalidation des commits ,
j’ose imaginer le résultat si cela est proposé sur Redhat ou fedora , cela va très rapidement se voir que cela été mal testé sur cette partie.
le seul hic , je n’ai pas vu de bugzilla pour la partir Grub, a moins que quelqu’un l’est indiqué à la liste mail grub-devel ( lien endevouros ou lien bug archlinux ref )
Stéphane,
L’historique de l’empaquetage côté Arch montre (https://github.com/archlinux/svntogit-packages/commits/packages/grub/trunk):
– Le 24 août: « bump to latest change »
– Le 26: « revert a problematic commit »
– Le 29: « drop the revert » suivi de « add an upgrade message ».
Ce message set le suivant:
To use the new features provided in this GRUB update, it is recommended to install it to the MBR or UEFI. Due to potential configuration incompatibilities, it is advised to run both, installation and generation of configuration:
$ grub-install …
$ grub-mkconfig -o /boot/grub/grub.cfg
Donc finalement côté Arch cet incident ne semble pas avoir été considéré comme un « bogue » en amont (pour l’instant du moins), ce qui explique probablement l’absence de bugzilla (et de message sur la liste grub-devel jusqu’à présent).
Les utilisateurs d’Arch savent (ou devraient savoir) que ce genre d’incident est le prix à payer pour avoir les logiciels les plus à jour et comment y faire face, ceux des distributions dérivées c’est moins sûr.
Plus généralement les consignes de mises à jour ou de réparation sont un bonne mesure… pour les utilisateurs qui les lisent et les appliquent (levez le doigt). J’ai bien écrit ceci pour ce genre de probème: https://slint.fr/doc/HandBook-WIP-15.0.html#_how_to_solve_blocking_issues mais en étant conscient de cette limitation.
c’est a mon avis plus compliqué , on est pas très loin d’un bug qui pourrait bien êtee exposé au plus grand jour si l’équipe grub continue dans ce sens …
https://bugs.archlinux.org/task/75701
voir remarques de philm , mais aussi de Dalto , pour ma part je le comprends de cette façon :
implémentation en cours fwsetup révele un probleme avec les anciens Grub / bios modèles et UEFI , il y a des choses pas bien implémentés qui font ressortir l’anomalie par fwsetup
en etat , c’est ni fiable , ni robuste , ni assez testé , équipe grub a intérêt a bien vérifier et corriger le tir , par ce que Archlinux et endevourOs ont immédiatement regardé en état les autres solutions .de démarrage ….
Personnellement, j’ai pas eu de soucis avec cette MAJ de GRUB, sur aucun de mes deux PC sous Arch. Le fait qu’ils soient anciens (2009) doit me sauver la mise, parce que je n’ai découvert l’existence de ce bug et ses conséquences fâcheuses que bien après avoir fait la MAJ et redémarré les machines.
Pas de souci chez moi après mise à jour ce matin (Arch + Plasma), aussi bien en Legacy qu’en UEFI. J’avais mis à jour ma clé USB Arch au cas où, mais tout va bien, pas de GRUB explosé en vol.
Hamster + xnews c’est ce qui a retardé longtemps mon passage sous Linux et accessoirement prolonger la vie de mon windows 98. Je ne trouvais pas l’équivalent… puis finalement le déclin de Usenet et la mort de mon PC ont facilité le passage du coté obscur, enfin vert de la force.
Réponse à Stéphane:
Tu as écrit:
c’est a mon avis plus compliqué , on est pas très loin d’un bug qui pourrait bien être exposé au plus grand jour si l’équipe grub continue dans ce sens …
Cela devrait déjà être fait! Personne parmi les commentateurs de https://bugs.archlinux.org/task/75701 pour faire une rapport ici: https://savannah.gnu.org/bugs/?group=grub ?
Tu as aussi écrit:
en état , c’est ni fiable , ni robuste , ni assez testé , équipe grub a intérêt a bien vérifier et corriger le tir, par ce que Archlinux et endevourOs ont immédiatement regardé en état les autres solutions .de démarrage ….
1) Ils ne risquent as de corriger le tir si personne ne leur signale le problème.
2) Plein de distributions utilisent d’autres logiciels. Je doute fort que cela inquiète les développeurs de GRUB.
3) Jeter le bébé avec l’eau du bain me paraît excessif. En tous cas je ne le ferai pas. J’attendrai juste que la situation se soit décantée pour décider quand et comment je ferai la prochaine mise à jour.
A ma connaissance GRUB est le seul capable de remplir toutes les conditions suivantes, nécessaires pour Slint:
1. Accéder à une partition racine cryptée avec LUKS sans partition dédiée pour /boot.
2. Produire un fichier de configuration permettant d’avoir la partition racine sur un sous-volume btrfs.
En plus GRUB communique facilement avec Dracut, que j’utilise pour associer un initrd à chaque noyau.
Bref, je connais peu de projets aussi bien gérés que GRUB, y compris des points de vue des tests, de la sécurité et de la documentation. Ma seule réserve est le délai entre deux versions, que je souhaiterai plus court.
Mais bon, à chacun de faire ses choix.
Finalement c’est : Robbie Harwood de Manjaro qui a informé les développeurs de GRUB:
https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00370.html
qui semblent être arrivés à un consensus sur la résolution: https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00375.html
Désolé d’avoir pis en otage cette entrée de ton blog Fred, au moins on a une conclusion (pas encore « commitée » mais je suppose qu’elle le sera bientôt).
Aucun problème. Le fil a été intéressant à suivre. J’ai simplement éviter le problème en ne mettant pas grub à jour. D’ailleurs, je l’avoue honteusement, la dernière mise à jour de grub remonte à la migration de mon système vers un nvme, ce qui doit faire dans les 18 mois maintenant.
correction : Phil Muller de manjaro et de mon côté j’avais prévenu Daniel Kiper , avec lien archlinux / manjaro et endevouros , car je ne suis pas inscrit sur la mailing Grub-devel
Tu as raison c’est Phil qui a prévenu sur la liste, j’avais mélangé expéditeur et destinataire. Il est probable que la version proposée par Javier Martinez Canillas: https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00374.html soit retenue, elle a en tous cas été approuvée par Robbie Harwood: https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00385.html. Après ce nihil obstat il ne reste plus qu’à attendre l’imprimatur de Daniel Kiper, je suppose.