Ah, le kéké-tuning du monde linuxien…

J’ai eu souvent l’occasion de déplorer les dérives du monde du libre et spécialement linuxien. Mais il est vrai que j’avais sous-estimé un problème de taille : le kéké-tuning. Peu importe la région où on habite, mais il y a toujours des personnes qui ne jurent que par le mauvais goût et l’outrance du kéké tuning.

Il semblerait cependant que l’Occitanie, le Grand-Est ou encore le Centre-Val-de-Loire soit plus concerné selon les informations que j’en ai eu, mais je peux me tromper.

Mais avant tout, il faut définir le kéké-tuning : c’est la volonté d’en foutre plein la vue avec des effets outranciers ou encore en rajoutant composants inutiles sur le plan fonctionnel dans son matériel.

Outre le fait que l’on se fait siphonner le portefeuille pour des barrettes de mémoires aux couleurs du genre rose bonbon phosphorescent, on consomme de la mémoire vive pour rien. Oui, je sais certaines personnes vont me dire : les machines ont maintenant X Go de mémoire (avec X supérieur ou égal à 8), c’est pas une raison pour ne pas en profiter. Si on veut. Je pensais juste que c’était mieux de laisser la mémoire aux logiciels utiles…

Continuer la lecture de « Ah, le kéké-tuning du monde linuxien… »

Pearl Linux, la seule distribution héritière de PearOS en vaut-elle la peine ?

Ah, PearOS… Toute une histoire d’amour et de haine qui a rythmé les années 2012 et 2013 sur mon humble blog. Parmi les héritières potentiels de cette distribution GNU/Linux basée sur Ubuntu et voulant cloner l’interface de MacOS-X, il ne reste plus grand monde qui soit encore en vie. Outre la TrentaOS (dont j’ai parlé dans un article de novembre 2015), il y a la Pearl Linux.

Dans mon article de novembre 2015, j’étais resté un peu sur ma faim :

[…]
Pour la PearlOS, j’avoue que je suis plus perplexe. Soit il y a un problème technique avec le site internet, soit la distribution est morte. En tout cas, au moment où je rédige ce rapide article, rien se s’affiche sur le site officiel. La seule image ISO que je peux récupérer date de décembre 2014, sur l’espace sourceforge.[…]

Depuis, la situation s’est arrangée. Si on va sur le site de la Pearl Linux, on a droit à une douzaine d’images ISO disponibles, que ce soit pour la version 1.0, 1.5, voire 2.5 de la distribution. On a droit à des versions avec Mate Desktop, Xfce, Gnome, et le Pearl Desktop Environment… Sans oublier l’inévitable image ISO pour Raspberry Pi 2.

Autant dire que c’est un énorme bazar. Pour être certain d’avoir l’image ISO la plus récente – du moins, on peut l’espérer – j’ai pris l’ISO dite Pearl OS 2.5 en 64 bits. Elle date du 19 octobre 2015.

Cerise sur le gateau mal cuit ? L’environnement est basé sur Compiz… Ne hurlez pas à l’idiotie… Il y a un environnement qui est aussi basé sur Compiz. Un certain Unity, interface graphique utilisateur d’une distribution GNU/Linux peu connue, Ubuntu 🙂

Après avoir récupéré l’image ISO, j’ai lancé VirtualBox avec un modèle ubuntu dopé : 2 Go de mémoire vive, 2 CPUs virtuels et 128 Go de disque dur.

L’image du démarrage sur le liveCD m’a fait penser au logo des boites de lessives en poudre du début des années 1980… Ouille 🙂

Continuer la lecture de « Pearl Linux, la seule distribution héritière de PearOS en vaut-elle la peine ? »

Cinnamon : l’exemple parfait des avantages et inconvénients de dépendre d’une distribution tierce pour un environnement de bureau.

Cinnamon, l’environnement de bureau qui a pris une importance croissante au fil des mois semble justement subir une crise de croissance. De plus en plus de distribution, en dehors de la Linux Mint utilise ou propose l’environnement en question : SnowLinux, CinnArch, Fedora Linux, Ubuntu, OpenSuSE, Gentoo Linux et donc Sabayon Linux, Frugalware Linux. Dixit la page de téléchargement de l’environnement.

Cependant, sa dépendance à une base Ubuntu et l’occasion manquée de pouvoir partir d’une base Debian GNU/Linux fragilise un peu la diffusion de l’environnement de bureau basé sur les technologies de Gnome Shell.

Dans un message récent, sur la liste de publipostage arch-dev-public, l’arrivée de Gnome 3.8 sur les dépots a entrainé une décision logique, bien que douloureuse pour Cinnarch (distribution basée dès le départ sur le duo Cinnamon + ArchLinux) entre autres : le retour de Cinnamon dans AUR, l’archive des logiciels tiers d’Archlinux.

Je cite le morceau important du courrier en question :

I agree about dropping cinnamon because it is impossible to work with Linux
Mint projects. They work with what they have instead of what is coming. So
now we have this gnome 3.8 problem, and then we would have gnome 3.10
problems. We can’t work with their packages.

Ce qui se traduit par :

Je suis d’accord pour l’abandon de Cinnamon car il est impossible de travailler avec les projets de Linux Mint. Ils travaillent avec ce qu’ils ont [la version de Gnome proposée par Ubuntu] pas ce qui arrive. Nous avons maintenant le problème avec Gnome 3.8, et nous aurons des problèmes avec Gnome 3.10. Nous [les développeurs d’Archlinux] ne pouvont pas travailler avec leurs paquets.

J’ai été jeté un oeil sur le dépot des paquets d’Ubuntu pour la Raring Ringtail. Au 12 avril, les paquets Gnome sont encore en partie en version 3.6.x : Nautilus est en version 3.6.3 par exemple. Idem pour Totem ou encore Brasero.

La Ubuntu 13.04 étant en béta 2 récemment, il serait étonnant d’introduire la dernière génération de Gnome fraichement sortie à moins de 2 semaines de la version finale.

Il y a donc de fortes chances pour qu’Ubuntu 13.04, base de la future version de Linux Mint, distribution référence de Cinnamon se base encore sur Gnome 3.6. Donc, potentiellement incompatible avec la dernière version officiellement stable de Gnome et de son shell. Version qui va se répandre dans les semaines qui viennent.

Et ce qui c’est passé avec ArchLinux et CinnArch, risque de se reproduire pour Fedora Linux ou encore Gentoo Linux qui ont moins de retard en terme de versions que la distribution de Canonical.

Doit-on en déduire que l’acharnement thérapeutique sur le code de Gnome 2, j’ai nommé Mate a une chance de se faire une place au soleil ? Pourquoi pas, même si j’avoue que je ne croyais pas vraiment à la pérénité du projet quand il est apparu.

Il est récemment sorti en version 1.6.0 récemment, et se porte étonnament bien. Il est vrai qu’il est moins dépendant que Cinnamon d’une quelconque distribution.

Reste à savoir cependant si le mode « Classique » de Gnome 3.8 lui fera ou pas de l’ombre.

Ci-gît un bug vicieux.

C’est la fin de l’histoire du bug vicieux qui m’empoisonnait la vie d’utilisateur de ma Frugalware Linux. Grâce à la ténacité d’Hermier, la solution a été enfin trouvée.

Pour faire rapide, si vous avez un problème de compositing avec un circuit nvidia et xorg-server 1.7.6, il faudra ajouter ceci au début de votre fichier /etc/X11/xorg.conf

Section « Module »
SubSection « extmod »
Option « omit xfree86-dga »
EndSubSection
EndSection

Et le compositing reviendra à la vie. Ouf 😉

L’histoire – en cours – d’un bug vicieux : le bug 4145 de la Frugalware Linux.

Comme toute histoire, il faut un commencement. Ce commencement, c’est le 17 mars qu’il arrive.

Ce jour là, arrive la version 1.7.6 du paquet xorg-server. Faisant la mise à jour du paquet et redémarrant ma session, je m’aperçois que compiz ne se lance plus. J’avais déjà parlé de ce problème.

Horreur, plus de fenêtres molles, de zolies animations lors de la réduction des fenêtres.

Je ferme l’icone de Fusion-Icon qui s’occupe de lancer Compiz, et je la relance en utilisant le terminal et je tombe sur un simple message d’erreur :

fred@frugalware:~$ fusion-icon &
[1] 3493
fred@frugalware:~$ * Detected Session: gnome
* Searching for installed applications...
* NVIDIA on Xorg detected, exporting: __GL_YIELD=NOTHING
* Using the GTK Interface
* Starting Compiz
... executing: compiz --replace --sm-disable --ignore-desktop-hints ccp
compiz (core) - Fatal: No damage extension

J’ouvre donc un rapport de bug, histoire de faire connaître le problème, le bug 4145.

Mon premier réflexe est de vérifier si un bug de ce style est connu, et je tombe sur quelque chose d’équivalent sur le suivi de bugs de la mandriva sur le bug 57889.

Mais le correctif proposé ne change rien.

Le seul correctif que je trouve, est plus un contournement qu’autre chose : rétrograder la version de xorg-server, en utilisant la 1.7.5 qui fonctionnait parfaitement. Et en la réinstallant, Compiz revient à la vie.

Je me dis alors que ce doit être un bug du pilote propriétaire nvidia, et je me débrouille pour empaqueter la nouvelle version, la 195.36.15. Mais aucun changement quand je repasse à la version 1.7.6 de xorg-server.

Entre temps, devil505 parle de mon problème dans son billet du 20 mars. J’ai droit par la même occasion d’être le premier lauréat du prix Cyrille de la semaine.

Le 23 mars, Hermier qui s’occupe du pilote nvidia se décide à me donner un coup de main. Et depuis 4 soirs, tout a été essayé, en essayant rester exhaustif :

  • Recréer le fichier xorg.conf avec le pilote récent et xorg-server 1.7.6
  • Désactiver xinerama et record dans le fichier xorg.conf
  • Utiliser des versions de xorg-server 1.7.6 avec des correctifs suspects
  • Empaqueter de manière officielle le dernier pilote propriétaire nvidia
  • Utiliser l’option composite de gnome
  • Recompilation de Xorg-Server aussi bien en local qu’avec l’aide de bouleetbil et d’hermier
  • Enlever le module nouveau du noyau à la sauvage
  • Mettre à jour la version de libdrm
  • Recompiler libxdamage
  • Rétrograder dri2proto

Les logs du canal irc #frugalware.fr 25 mars, du 26 mars – , et du 27 mars, liste tout ce qui a été tenté.

Maintenant, je dois avouer que je suis à court d’idées devant un tel bug, aussi vicieux

Mieux vaut en rire qu’en pleurer, au final, et j’espère que ce billet permettra d’apporter des idées nouvelles pour mettre à mort ce bug qui me facilite un brin le transit intestinal dans ma vie d’utilisateur d’informatique libre.

Un espoir serait peut-être l’arrivée de la version 1.8.0 de Xorg-server, prévue pour la fin du mois.

Qui vivra verra !