Un aperçu de lxde 0.5

Je me suis basé sur la machine virtuelle du précédent article pour tester lxde 0.5, le « lightweight X Desktop Environment ».

L’installation est simplissime ; il suffit de taper dans une console :

yaourt -S lxde

Le coeur de cet environnement de bureau qui repose sur openbox se charge. J’ai ensuite rajouté midori et les paquets lxde-input et lxnm pour compléter l’environnement.

Pour lancer l’environnement, j’ai simplement rajouter la ligne suivante au fichier .xinitrc disponible à la racine du compte utilisateur :

exec startlxde

Ensuite, lxde se lance avec un petit :

startx

NB : à cause d’un bogue d’openbox, il faut réduire la profondeur d’affichage à 16 bits dans le fichier /etc/X11/xorg.conf au lieu du 24 bits proposé par défaut.

J’ai enregistré une petite vidéo (saccadée, et contrairement à ce que j’avais affirmé dans l’article précédent), ce n’est pas du à la gourmandise de l’environnement de bureau, mais à un mauvais réglage du logiciel de capture vidéo 🙁

Néanmoins, cela permet de voir à quoi ressemble lxde 0.5 brut de fonderie.

Encore jeune, car certains outils sont franchement rudimentaires, mais il a du potentiel face à des environnements de bureau plus gourmand comme xfce, gnome ou encore kde.

KDE SC 4.4rc2 : premier aperçu :)

Comme jadis pour KDE 4.3 rc1, j’ai décidé de faire un petit test rapide de la future nouvelle version stable majeure de KDE. Du moins de cette 2ième candidate à la publication.

La feuille de route pour KDE SC 4.4 est disponible à cette adresse : http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule

J’ai donc installé une machine virtuelle avec une archlinux 64 bits dedans. Ben ouais, pourquoi ne pas employer une distribution linux qui est des plus proches du code original pour les logiciels ?

Donc, les habituelles lignes de commandes :


fred ~/download $ qemu-img create -f qcow2 kde44rc2.img 32G
Formatting 'kde44rc2.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0
fred ~/download $ kvm -hda kde44rc2.img -cdrom archlinux-2009.08-netinstall-x86_64.iso -boot d &

Je laisse de coté les méandres de l’installation sur archlinux qui sont par ailleurs d’une simplicité enfantine si on lit le wiki francophone.

Après l’installation, j’ai installé yaourt, hal, alsa, et enfin configuré Xorg pour pouvoir accueillir tranquillement la release candidate de KDE SC 4.4, en utilisant le dépot kde-unstable.

NB : pour installer KDE depuis le dépot kde-unstable, il faut d’abord activer le dépot testing.

Continuer la lecture de « KDE SC 4.4rc2 : premier aperçu 🙂 »

Un aperçu rapide de la SimplyMEPIS 8.5 beta 4.

Il y a une dizaine de jours environ, la 4ième béta de la SimplyMepis 8.5 est sortie. A l’origine basée sur Ubuntu, cette distribution est désormais basée sur la debian stable avec des logiciels assez récent : comme le noyau linux 2.6.32 ou encore KDE SC 4.3.4.

J’ai récupéré l’image iso en utilisant l’outil wget :

fred ~/download $ wget -c ftp://ftp.nluug.nl/pub/metalab/distributions/mepis/released/SimplyMEPIS-CD_8.4.96-b4_64.iso
–2010-01-17 09:07:59– ftp://ftp.nluug.nl/pub/metalab/distributions/mepis/released/SimplyMEPIS-CD_8.4.96-b4_64.iso
=> «SimplyMEPIS-CD_8.4.96-b4_64.iso»
Résolution de ftp.nluug.nl… 192.87.102.42, 192.87.102.43, 2001:610:1:80aa:192:87:102:43, …
Connexion vers ftp.nluug.nl|192.87.102.42|:21…connecté.
Ouverture de session en anonymous…Session établie!
==> SYST … complété. ==> PWD … complété.
==> TYPE I … complété. ==> CWD (1) /pub/metalab/distributions/mepis/released … complété.
==> SIZE SimplyMEPIS-CD_8.4.96-b4_64.iso … 728080384
==> PASV … complété. ==> RETR SimplyMEPIS-CD_8.4.96-b4_64.iso … complété.
Longueur: 728080384 (694M) (non certifiée)

100%[======================================>] 728 080 384 484K/s ds 17m 1s

2010-01-17 09:25:01 (697 KB/s) – «SimplyMEPIS-CD_8.4.96-b4_64.iso» sauvegardé [728080384]

J’ai ensuite utilisé une machine virtuelle qemu équipée avec 32 GiO de disque virtuel.


fred ~/download $ qemu-img create -f qcow2 mep.img 32G
Formatting 'mep.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0
fred ~/download $ kvm -hda mep.img -cdrom SimplyMEPIS-CD_8.4.96-b4_64.iso -boot d &

kvm est l’alias suivant dans mon .bashrc :

alias kvm='qemu --enable-kvm --soundhw es1370 -localtime -k fr -m 1536'

Mepis 8.5 beta 4 – 64 bits

Continuer la lecture de « Un aperçu rapide de la SimplyMEPIS 8.5 beta 4. »

VLOS 2.0 béta 1 : pas encore très véloce… :)

Désolé pour le jeu de mots à 0,02 €… C’était trop tentant 😉

C’est une gentoo matinée de sabayon. En clair, une méta-distribution pour être humain.

Le 7 janvier, la version 2.0 béta 1 est sortie.

NB : Je sais que certaines personnes me diront qu’une distribution à la gentoo n’a aucun intérêt dans une machine virtuelle. Très bien. Si on veut se faire la main sur une gentoo pour sa culture générale, et que l’on a pas envie de se prendre la tête avec une vraie machine, on fait comment ? C’est quand même une solution souple, qui permet de se familiariser sans trop de problème avec ce genre de distribution.

Tout comme la Sabayon Linux, elle utilise l’outil anaconda pour être installée. Enfin, il faudrait préciser qu’elle utilise funtoo comme base, funtoo étant une version dérivée de la gentoo linux, dérivée mise au point par Daniel Robbins (lui même créateur de la gentoo linux en 1999) pour améliorer la gentoo linux.

Bref, pour simplifier : VLOS = funtoo (dérivée de gentoo) + anaconda + outils de la sabayon linux.

VLOS 2.0 Beta 1

J’ai donc récupéré l’image iso de la version 2.0 béta 1 de la VLOS. Ensuite, j’ai utilisé qemu pour créer une image disque de 32 Go et lancer l’émulation.


fred ~/download $ qemu-img create -f qcow2 vlos.img 32G
Formatting 'vlos.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0
fred ~/download $ kvm -hda vlos.img -cdrom Vidalinux_2.0_beta1_amd64.iso -boot d &

Continuer la lecture de « VLOS 2.0 béta 1 : pas encore très véloce… 🙂 »

1000ième article… Et oui, déjà !

Même si le compteur d’article dépasse les 3290, il faut dire que cette explosion est due au passage à WordPress 2.6 béta, en juillet 2008. Le système des révisions multiples introduit par cette version de wordpress ayant lancé une inflation des numérotations.

1000 billets. Depuis septembre 2005, soit en gros en 53 mois, cela fait environ 18,86 billets par mois… Sacré moyenne.

Sans les logiciels libres, que ce soit bien entendu wordpress, mais aussi des distributions linux, des BSD libres, Mozilla Firefox (dont je parle sur ce blog depuis l’époque de la version 1.5 !), je n’aurais jamais pu accumuler autant de billets.

J’ai fini par me prendre de passion pour le monde toujours effervescent des distributions linux, dont j’ai pu tester, soit en utilisant qemu, soit virtualbox un bon paquet : ubuntu (et ses innombrables dérivés), de la Frugalware, de la slackware, de la Fedora, et même de la Mandriva, distribution que je ne porte pas franchement dans mon coeur.

Pour ce millième billet, je voudrais simplement remercier les personnes qui me lisent et qui déposent des commentaires.

Que vive le logiciel libre, qui est surement l’avenir du logiciel.

Et pour les personnes un peu incrédules :

1000 billets avec WordPress !

Un aperçu rapide de la Frugalware Linux 1.2pre2

La deuxième préversion de la frugalware linux 1.2 (alias locris) est sortie récemment. Pour me simplifier la tâche, j’ai récupéré l’image iso 32 bits du premier dvd. Pourquoi ?

  1. Pas de préversion en 64 bits
  2. Pas envie de télécharger la 1.1 finale en 64 bits puis de la mettre à jour en utilisant le dépot current
Frugalware 1.2 pre2 – 32 bits

Donc en utilisant Qemu 0.12.1, j’ai créé une image disque de 32 GiO puis lancé l’installation.


fred ~/download $ qemu-img create -f qcow2 frug.img 32G
fred ~/download $ kvm -hda frug.img -cdrom frugalware-1.2pre2-i686-dvd1.iso -boot d &

kvm est l’alias suivant dans mon .bashrc :


alias kvm='qemu --enable-kvm --soundhw es1370 -localtime -k fr -m 1536'

1536 MiO de mémoire ? Pile la moitié des 3 GiO de ma machine. Au démarrage, on nous annonce une distribution avec un noyau 2.6.32 (cool !).

Continuer la lecture de « Un aperçu rapide de la Frugalware Linux 1.2pre2 »

La diversité du monde linux : force ou faiblesse ?

Lisant un article de l’excellent Cyrille Borne, un paragraphe m’a sauté aux yeux. Je cite :

« Je garde ma réserve car notre Linux prétendument indestructible s’il devenait du jour au lendemain la cible de tous les bandits du monde et bien peut être qu’il se ferait méchamment « marrave ». Finalement cette situation des 1% me convient bien, j’ai quelque part l’impression d’avoir trouvé un restaurant parisien à 7 € face à la tour Eiffel où l’on mange très bien, une espèce de secret que nous partagerions entre gens de bon goût. Si du jour au lendemain on devenait trop nombreux je suis persuadé qu’on y mangerait plus mal et qu’il y aurait des gens qui gâcheraient l’ambiance, on voit déjà un peu ce phénomène quand on sait ce qu’Ubuntu a apporté à l’univers Linux, pas que de la facilité c’est bien sûr. »

Je pense que la « tranquillité » de linux est surtout basée sur une chose : sa diversité.

Je m’explique. Déjà, contrairement au monde windows, il y a une foultitude de distribution. La bible Distrowatch en compte plusieurs dizaines (pour ne pas dire plusieurs centaines). Si en crois la dernière gazette en date :

* Number of all distributions in the database: 645
* Number of all active distributions in the database: 306
* Number of dormant distributions: 49
* Number of discontinued distributions: 290
* Number of distributions on the waiting list: 197

Traduit rapidement : 645 distributions recensées, 306 actives (dont une soixantaine plus ou moins dérivées de la distribution reine actuelle, j’ai nommé Ubuntu), 49 en hibernation, 290 abandonnées, 197 attendant d’être recensées.

Et si on simplifie à l’extrême, le trait, il y a en gros 3 familles :

  • Celles basées sur du .deb
  • Celles basées sur du .rpm
  • Les autres qui regroupent aussi bien les paquets sources compilés (tar.gz, tar.xz, etc…) que des formats exotiques comme le Conary de rPath.

Donc, si une personne malintentionnée veut toujours un maximum de personnes, il faudrait que son logiciel « malin » soit disponible au moins dans 2 formats, voire plus. Il y a bien le projet autopackage, mais c’est pas franchement la joie.

Ensuite, comme 99,9% des distributions utilisent des dépots, il faudrait infecter les dits dépots, et donc contourner une série de sommes de vérifications plus ou moins puissantes (md5, sha).

Et si je me souviens, un seul cas a été recensé : celui de RedHat courant août 2008?

Il est vrai qu’il est assez ennuyeux pour un programmeur de devoir faire un paquet rpm, un paquet deb, etc… pour son logiciel. Mais cela permet d’avoir une sécurité et d’éviter qu’un sal…petit malin ne corrompe toutes les distributions.

Le vrai danger, c’est le manque de formation des utilisateurs qui utilisent root pour l’utilisation courante, mais cela est du à la conception de Windows qui jusqu’à récemment (en gros jusqu’à Vista) n’était utilisable qu’avec des droits complets sur l’ensemble de la machine.

Je ne prétends pas qu’avec la montée en puissance du logiciel libre au niveau OS de bureau la situation va devenir plus dangeureuse, mais les risques sont limités.

Avis personnel, que je partage 😉

Bretelle et ceinture : de l’intérêt d’avoir à la fois networkmanager et wicd installés.

Le dépot testing d’Archlinux est très rarement « explosif ». Sauf que récemment, une version de développement de NetworkManager est venue mettre une mouise pas possible dans les connexions. J’ai rapporté un bug (qui s’est révelé être le doublon d’un autre) dans lequel le dernier NetworkManager en date (0.7.998) bloquait entièrement Gnome 🙁

Heureusement, j’avais conservé sur mon disque l’outil Wicd dont je n’avais désactivé que l’applet d’affichage et de gestion de réseau. J’ai donc utilisé la séquence ctrl + alt + F2 pour ouvrir une console en mode texte. J’ai ensuite désactivé NetworkManager, réactivé Wicd, fermé la session. Les commandes ?

sudo /etc/rc.d/networkmanager stop
sudo /etc/rc.d/wicd start

La combinaison ctrl + alt + F7 m’ayant permis de me retrouver à nouveau en mode graphique.

Pour que la modification soit prise en compte à chaque démarrage, j’ai désactivé le daemon networkmanager en lui rajoutant un ! avant son son nom dans la ligne DAEMONS de mon /etc/rc.conf :

DAEMONS=(syslog-ng !network netfs crond hal @alsa wicd !networkmanager cpufreq @iptables avahi-daemon avahi-dnsconfd pulseaudio @cups @openntpd sensors gdm)

Bref, une manipulation qui a pris, quoi, 5 minutes 🙂

Compiler Minefield sur les distributions linux « moins grand publics » – Partie 3 – ArchLinux.

Après la Frugalware Linux et la Slackware Linux, voici le dernier volet : La ArchLinux. J’ai installé et mis à jour une ArchLinux 64 bits. J’ai installé dessus un Xfce 4.6.1 à la place d’un Gnome. Pourquoi ? Simplement que je voulais utiliser un environnement basé sur gtk2 assez léger 😉

Sur Archlinux, le problème lié au bug 104642 sur le bugzilla de Mozilla se résout facilement.

Avec une installation par défaut d’Archlinux avec Xfce (ou encore Gnome), on a la quasi-totalité des dépendances de compilation. Seul manque autoconf 2.13, mercurial et zip. En utilisant l’excellent yaourt, le problème se résout en… 2 minutes :

yaourt -S autoconf-compat mercurial zip

Installation d'autoconf 2.13 sur Archlinux

Pour gagner du temps, j’ai utilisé le paquet du code source que j’utilise dans ma machine réelle. Il faut dire que le code source pèse quelque chose comme 600 MiO décompressé.

Sinon, pour récupérer le code source en entier :

hg clone http://hg.mozilla.org/mozilla-central/ src

Le code source est localisé dans ~/fox/src

Le fichier de configuration .mozconfig utilisé est le suivant :

#
# See http://www.mozilla.org/build/ for build instructions.
#

export AUTOCONF=autoconf-2.13

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize
ac_add_options –disable-debug
ac_add_options –disable-tests

Ensuite on verifie que le code source est bien à jour :

hg --verbose pull -u

Et la compilation proprement dite :

make -f client.mk build

La compilation dure environ 90 minutes. Sur ma machine réelle, la compilation prend 25 minutes de moins, environ.

Le résultat est disponible dans le répertoire objdir-fx/dist/firefox/

Il suffit d’entrer un ./firefox & pour avoir le résultat.

Minefield sur Archlinux

Maintenant à vous d’adapter les instructions pour votre propre distribution, tant qu’elle est assez peu « grand public » 😉

Compiler Minefield sur les distributions linux « moins grand publics » – Partie 2 – Slackware Linux.

Après la Frugalware Linux, voici le deuxième volet : La Slackware Linux. J’ai installé et mis à jour une slackware64 13.0. J’ai installé une version allégée, remplaçant le KDE 4.2.x proposé par défaut par un Xfce 4.6.1.

Le point ennuyeux ? L’absence d’autoconf 2.13 qui est indispensable pour lancer la compilation du code source. Cf le bug 104642 sur le bugzilla de Mozilla.

N’ayant pas pu trouver le paquet pour autoconf 2.13 sur http://www.slackbuild.org/, j’ai été obligé de le faire compiler à la main. Pas très propre mais fonctionnel !

J’ai du rajouté le paquet libnotify (en forçant l’architecture dans le fichier de slackbuild) depuis http://www.slackbuild.org/.

Pour gagner du temps, j’ai utilisé le paquet du code source que j’utilise dans ma machine réelle. Il faut dire que le code source pèse quelque chose comme 600 MiO décompressé.

Sinon, pour récupérer le code source en entier :

hg clone http://hg.mozilla.org/mozilla-central/ src

Le code source est localisé dans ~/fox/src

Le fichier de configuration .mozconfig utilisé est le suivant :

#
# See http://www.mozilla.org/build/ for build instructions.
#

export AUTOCONF=autoconf2.13

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize
ac_add_options –disable-debug
ac_add_options –disable-tests

Ensuite on verifie que le code source est bien à jour :

hg --verbose pull -u

Et la compilation proprement dite :

make -f client.mk build

Erreur compilation de Minefield dans une Slackware 13.0 64 bits

Et impossible de dépasser la compilation du moteur javascript, la compilation s’arrête avec une histoire de cible « -pthread » introuvable. Je me suis aperçu de la présence de 2 répertoires dans /usr :

  • /usr/lib
  • /usr/lib64

J’ai tenter de rajouter le second dans le fichier /etc/ld.so.conf, mais après un redémarrage, aucun changement. J’avoue avoir « googler » mais sans grande réussite. A croire que la version de développement ne se compilera dans une Slackware Linux 13.0 64 bits 🙁

A croire que ce commentaire sur l’article précédent était un brin prémonitoire.

Dommage !