Étiquette : machine virtuelle

GhostBSD, un mois en machine virtuelle, bilan à mi-chemin.

Il y a bientôt deux semaines, on ne va pas chipoter pour deux jours près, je lançais une expérience d’avoir GhostBSD durant un mois en machine virtuelle.

L’expérience est des plus calmes. En effet, à chaque fois que je lance l’outil update station – une surcouche graphique conviviale à l’outil pkg – j’ai la même réponse : pas de mises à jour disponible. Cf la capture d’écran ci-dessous.

Même une Debian GNU/Linux stable est plus agitée que GhostBSD. Je ne m’attendais pas à des mises à jour pluri-quotidiennes, mais à un minimum d’une ou deux mises à jour par semaine.

Le système toujours autant utilisable et on ne voit pas vraiment que l’OS est différent d’une distribution GNU/Linux. Ce qui fait la force de GhostBSD, soit dit en passant.

Il me reste une grosse quinzaine de jours à tirer avec cette expérience. Peut-être qu’une grosse mise à jour finira par pointer le bout de ses octets et me fera mentir sur la tranquillité de l’utilisation.

Donc rendez-vous dans une quinzaine de jours pour le bilan final de cette expérience.

Nouvelle expérience : au tour de GhostBSD de passer sur le grill !

Cela faisait quelques temps que je voulais lancer une nouvelle expérience en machine virtuelle, n’ayant pas assez de matériel pour tenter l’expérience en dur. Cette fois, comme c’est indiqué dans le titre, c’est la GhostBSD 25.1 sorti fin février 2025 de subir mon test. À savoir être testée durant un mois dans une machine virtuelle.

L’installation a été assez longue, surtout lors du démarrage du live. L’ensemble du système a été copié en mémoire vive, et 2,8 Go à copier, ça peut devenir rapidement long et laxatif. Bref, il ne faut pas être pressé dans ce cas. L’installation en elle-même a duré environ 15 minutes. Qui a dit que l’informatique est une école de la patience déjà ? Sans oublier que VirtualBox avait tendance de passer d’un modèle FreeBSD au modèle other qui est un peu le modèle de la dernière chance. Laxatif aussi !

La première épreuve aura été de mettre à jour la base fraîchement installée. Il faut dire qu’en l’espace de deux mois, elles se sont accumulées. En effet, l’outil Update Station m’indiquait 451 mises à jour, 9 nouveaux paquets à installer et 6 paquets à réinstaller. Je suis passé par la ligne de commande, comme c’est indiqué dans le wiki de GhostBSD.

La mise à jour a pris 15 bonnes minutes avant que je puisse redémarrer l’ensemble. J’ai juste rajouté LibreOffice à l’installation de base, en utilisant l’outil Software Station. C’était le seul gros manque à l’installation. Et côté gadget, j’ai rajouté fastfetch qui m’affiche l’Ascii art de FreeBSD, ce qui est normal étant donné que GhostBSD est un FreeBSD « simplifié » avec Mate Desktop comme interface graphique.

J’ai donc enregistré une courte vidéo pour présenter rapidement l’ensemble.

L’expérience commence donc en ce 8 mai 2025 pour se terminer le 8 juin 2025… Si tout se passe bien 🙂

Un mois d’Artix Linux en machine virtuelle, quel bilan ?

Il y a un mois, je lançais l’expérience de faire fonctionner durant un mois une Artix Linux Cinnamon dans une machine virtuelle. Je rajoutais par la suite – sans le préciser dans l’article d’origine – une Artix Gnome installée en suivant la méthode exposée dans cette vidéo :

L’expérience s’est plutôt bien passée, bien que j’ai encore un peu chargée la mule en lui rajoutant AppleWin depuis le paquet que je maintiens sur AUR. J’ai dû aussi migrer manuellement le paquet SDL2 vers sdl2-compat pour éviter une recompilation un peu casse-bonbon.

Dans le billet où je faisais une étape à mi-chemin, je parlais des deux bugs que je rencontrais avec Cinnamon, dont celui du son dont le volume est à zéro à la connexion. Bug que je n’ai pas pu reproduire avec une Archlinux Cinnamon. Bizarre !

Autre point bizarre, c’est la présence de paquets absents qui me sont proposés à la suppression. Cependant, vu leurs noms, je n’y ai pas touché. Sans oublier un paquet apparemment abandonné (??) par Artix Linux, à moins que ce soit un bug de la distribution ?

Pour Artix Linux Gnome j’avais rajouté deux extensions au Gnome Shell pour avoir à peu de chose près la même expérience utilisateur générale. Comme précisé dans cet article du 29 janvier 2025 où vous trouverez tous les détails croustillants. Avec une petite capture d’écran de yay en action.

En tout cas, j’ai remarqué qu’en dehors de Xfce, LXQt et KDE, le support ne semble pas être des plus avancé. Je peux me tromper, bien entendu, mais ça donne pas envie de tester un environnement de bureau parfaitement fonctionnel sur d’autres bases.

Tout comme le support des systèmes d’init en dehors d’OpenRC. Runit est cassé pour le support de NetworkManager, et je n’ai pas eu l’envie de tester les autres systèmes d’init comme S6 ou Dinit. Pas envie de me retrouver le bec dans l’eau.

Au final, c’est un bilan mitigé. Artix est la digne descendante d’Archlinux OpenRC, mais elle m’a laissé un goût d’inachevé dans la bouche. Tout le contraire de ce que j’avais ressenti avec la Void Linux, même si je n’ai pas réussi à installer Cinnamon avec Void Linux. Bref, quand ça veut pas, ça veut pas !

Et si on lançait une nouvelle expérience ?

Je dois dire que depuis la fin de l’expérience avec Void Linux, je m’ennuyais ferme, geekement parlant.

Je me suis dit « Quelle pourrait être la prochaine expérience intéressante à lancer ? » Après avoir réfléchi un peu, je me suis dit qu’il serait intéressant de tester Artix Linux avec un environnement de bureau disponible dans la logithèque. J’étais d’abord parti sur l’idée de mettre un Gnome. Mais après des mésaventures en utilisant le la page du wiki pour tester l’installation à l’ancienne.

J’avais d’abord pris runit comme système d’init, mais devant les problèmes pour faire fonctionner NetworkManager, je me suis replié sur OpenRC. Cependant, le son ne fonctionnait pas, et gdm spammait avec des logs allant jusqu’à la saturation de l’espace disque ! J’ai bien tenté de reprendra l’image ISO de Gnome publiée en 2021 et que j’avais utilisé dans une vidéo de début 2022.

Cependant, j’ai eu des emmerdes à ne plus compter, normal avec une image ISO ayant près de 4 ans au compteur. Principalement ?

  1. Devoir installer en premier les paquets artix-keyring et archlinux-keyring
  2. Désactiver la vérification des paquets lors de l’installation à cause d’une clé gpg manquante
  3. Supprimer plusieurs paquets et forcer l’installation avec un sudo pacman -Syyu --overwrite=*. Oui, je sais c’est dégueulasse, mais c’était la seule option pour être tranquille.
  4. GDM qui ne démarre plus après la mise à jour.

Je me suis donc replié sur un autre environnement et pour varier un peu les plaisirs, j’ai pris Cinnamon avec comme init OpenRC cette fois. Le support de runit étant très limite. Et surtout l’image ISO stable est plus fraîche, ne datant que d’août 2024. Après l’installation et l’ajout des mises à jour, j’ai rajouté le paquet cinnamon-translation pour avoir l’ensemble de l’interface en français. Sans oublier Mozilla Firefox et Libreoffice. Côté AUR – étant donné qu’à l’origine Artix Linux s’appellait Archlinux OpenRC – j’ai rajouté yay, dosbox-x-sdl2-git et vice-svn.

Donc, une nouvelle expérience est lancée et son bilan sera publié – sauf imprévu – le 23 février 2025.

Un mois de Void Linux en machine virtuelle, le bilan.

Il y a un mois – à deux jours près, on va pas chipoter pour si peu – je lançais cette expérience, après avoir migré mon eeePC d’une Debian GNU/Linux unstable 32 bits vers une Void Linux 32 bits pour continuer le support technique de mon ordinosaure moderne.

Je dois dire que depuis son installation, et l’installation des paquets pour faire compiler Dosbox-X et Vice en version de développement pour les deux, j’ai été de bonnes surprises en bonnes surprises. La première bonne surprise a été la simplicité avec laquelle on peut enlever les noyaux obsolètes de son installation.

Il suffit d’entrer les commandes suivantes :


vkpurge list
sudo vkpurge rm

La première commande liste les noyaux obsolètes, la deuxième permet de les enlever. Si on utilise la valeur all, tous les noyaux listés comme obsolètes sont enlevés. Il suffit d’ajouter après le rm les références en question. La deuxième bonne surprise, c’est la facilité avec laquelle on peut enlever les paquets orphelins.

Il s’agit de la commande sudo xbps-remove -o. Par contre il faut bien vérifier si des paquets importants ne sont pas listés… Sinon, tout part en cacahuètes, donc commande à utiliser avec précaution.

Comme toute commande touchant aux paquets logiciels, soit dit en passant. L’ensemble est resté réactif, agréable à l’utilisation – runit est d’une vélocité redoutable – et je dois dire que j’ai pris du plaisir intellectuel à faire cette expérience.

J’ai du installe le paquet lightdm-gtk-greeter-settings pour avoir un avatar sur la page de connexion lightdm. Cela m’a pris deux minutes, montre en main.

Deux points noirs cependant : la vieillesse de l’image ISO d’installation (sortie en mars 2024) et le fait que Gnome soit encore en version 46, mais ça doit dépendre du temps libre de la ou des personnes qui s’occupe du port en question.

Comme disait Hannibal dans « L’Agence Tous Risques » : J’adore quand un plan se déroule sans accroc, ce qui a été le cas ici. Autant dire que tant que le 32 bits sera supporté par Void Linux, mon eeePC continuera d’être utilisable pour ce que j’attends de lui. Après, ce sera une pièce de musée ayant bien vécue 🙂

Deux expériences qui prennent fin en même temps, ça arrive.

Nous sommes donc à une poignée de jours de Noël. Les vacances de Noël sont commencées, et il est donc temps de conclure deux expériences que j’avais lancé fin novembre / début décembre. La première concerne la maintenance en vie d’une Debian GNU/Linux unstable sur un mois. J’avais déjà fait un point d’étape que je concluais ainsi :

[…]Pour le moment, je n’ai pas encore cassé ma Debian GNU/Linux unstable, ce qui prouve qu’elle est plus solide que la légende urbaine linuxienne le laisse croire 🙂

Finalement, l’installation a tenu le choc jusqu’au bout. L’ajout des deux émulateurs sans passer par l’empaquetage officiel n’a pas déstabilisé outre mesure l’ensemble. Ce qui est un très bonne nouvelle. Donc, la Debian GNU/Linux unstable que l’on installe à la main est plus stable sur le long terme qu’une Siduction. Je ne pensais pas que j’aurai écrit un jour une telle phrase. Je me doutais un peu de ce résultat, étant donné que mon eeePC a tourné durant quelques deux années sous Debian GNU/Linux unstable.

Continuer la lecture de « Deux expériences qui prennent fin en même temps, ça arrive. »

Une expérience linuxienne sur le long terme : maintenir en vie une Fedora 41…

…jusqu’à la sortie de la Fedora 42 dans 6 mois, le tout dans une machine virtuelle. J’ai envie de voir jusqu’à quand je pourrais maintenir le système installé en vie, sachant que j’ai rajouté pas mal de dépendences pour obtenir Vice – la version proposée par RPM Fusion est une version 3.6.1 qui remonte à deux ans environ – et Dosbox-X qui n’a qu’un RPM en passant par Fedora Copr. J’ai envie de conserver un système aussi proche que possible de l’existant officiel avec comme seul dépôt tiers rajouté à la main étant l’incontournable RPM Fusion.

Voici donc les paquets que j’ai rajouté pour faire compiler des versions de développement de Dosbox-X (SDL 2) et Vice. En commun :

  1. ‘development-tools’ (avec dnf group install)
  2. ‘c-development’ (avec dnf group install)

Pour Vice :

  1. compat-ffmpeg4-devel (en provenance des dépôts rpmfusion)
  2. xa
  3. texlive
  4. texinfo-tex
  5. gtk3-devel
  6. glew-devel
  7. libcurl-devel
  8. pulseaudio-libs-devel
  9. alsa-lib-devel
  10. libev-devel
  11. subversion

Continuer la lecture de « Une expérience linuxienne sur le long terme : maintenir en vie une Fedora 41… »