Étiquette : geekeries

SalineOS 1.5 : un OS qui manque un peu de sel…

SalineOS, c’est un liveCD basé sur Debian GNU/Linux Squeeze avec Xfce 4.6. La version 1.5 étant sortie récemment, j’ai eu envie de la tester.

Après avoir récupéré l’image ISO en utilisant le protocole BitTorrent (en bon tipiak selon les industries aux modèles économiques obsolètes).

Ayant eu un problème au moment du premier démarrage après l’installation de l’OS dans la machine virtuelle (un bug de la version de développement de qemu ?), j’ai du me replier sur VirtualBox, en créant une image Debian 64 bits, avec 2 GiO de mémoire dédiée et 32 GiO de disque virtuel.

Une fois lancé et chargé, on arrive dans un environnement assez aquatique. L’installateur nous propose de s’occuper tout seul du disque.

Continuer la lecture de « SalineOS 1.5 : un OS qui manque un peu de sel… »

En vrac’ rapide et libre.

Un petit en vrac’ pour continuer la semaine.

Bonne journée !

FreeBSD 9.0rc1 : le BSD libre des utilisateurs très motivés ?

Dans le petit monde des BSDs libres, il y a mon « chouchou » OpenBSD, NetBSD (le passe partout), et le BSD pour utilisateurs « normaux », j’ai nommé FreeBSD. Ce dernier est à la base de PC-BSD, et de DesktopBSD. J’allais oublier le confidentiel et volant DragonflyBSD 🙂

Ayant pu lire sur distrowatch que la première RC de la version 9.0 de FreeBSD était disponible, j’ai récupéré l’ISO de la version 64 bits et j’ai lancé l’installation.

Pour des raisons pratiques, j’ai utilisé VirtualBox. Qemu aurait fait tout aussi bien l’affaire, mais j’ai remarqué des lenteurs incroyables au niveau de la lecture / écriture des systèmes de fichiers.

L’installateur est en mode texte, en anglais, mais si on se donne la peine de lire la documentation, on peut s’en sortir sans trop de problèmes.

A noter que lors de l’installation, le partitionnement du disque est automatisé, et il est clairement indiqué qu’une couche de support 32 bits est installé. Couche qu’on peut désactiver si on le désire.

Continuer la lecture de « FreeBSD 9.0rc1 : le BSD libre des utilisateurs très motivés ? »

Unity, un cul-de-sac à terme pour Canonical ?

Depuis deux versions de sa distribution Ubuntu, Canonical – qui a voulu se la jouer « cavalier seul »  – a décidé de proposer son interface nouvelle génération, Unity. Basée sur Compiz, elle fut d’abord proposée comme surcouche de Gnome 2.32, et a été adaptée pour fonctionner avec une version mixte de Gnome 3.2 (le terminal étant celui de Gnome 3.0.x par exemple).

Ce qui en a résulté une personnalisation qui nécessite de passer par CompizConfig parfois aussi pratique que la ligne de commande à coup de gsettings pour configurer certains points de gnome-Shell. Clapico propose quelques tutoriels pour personnaliser Unity. Sans oublier les articles disponibles sur ce sujet sur le-libriste.fr.

Il suffit de fouiller sur mes archives pour voir que faire fonctionner Gwibber est parfois assez acrobatique…

Dans la tradition du logiciel libre, un logiciel se doit d’être portable ; c’est à dire que les logiciels proposés doivent se compiler et fonctionner de manière indépendante en fonction de la distribution proposée.

Par exemple, modulo les patchs, c’est le même code source qui est proposé par la Document Foundation pour LibreOffice pour que celui-ci soit compilé pour une distribution à base de paquets debian, de paquets rpm, ou encore pour une archlinux ou une frugalware.

Idem pour des logiciels comme Mozilla Firefox, Chromium, etc… Ou encore pour les environnements de bureaux comme Gnome, KDE, Lxde, Xfce, etc…

Cependant, Unity est tout sauf facilement portable. Le projet qui englobe l’interface Unity, c’est Ayatana. Et le port d’Ayatana est un vrai chemin de croix.

Ce n’est pas moi qui le dit, mais un certain Devil505, un des principaux contributeurs de la distribution Frugalware Linux.

Je cite une partie de son article :

Il y a plusieurs mois, je m’étais lancé dans le projet de porter Ayatana (Unity+Indicators d’Ubuntu) sur Frugalware. Ce travail n’est pas de tout repos car il faut jongler entre les nombreux patchs d’Ubuntu. A l’époque, le projet Ayatana était encore jeune et je me disais que les patchs finiraient par être ajoutés en amont. A l’heure actuelle, les patchs sont toujours nombreux et je ne peux faire attendre le mainteneur de Gnome de Frugalware si celui-ci veut mettre à jour la dernière version de GTK+3 afin de trouver un patch compatible pour cette version par exemple. A noter que la « philosophie » de Frugalware est de patcher le moins possible. De plus unity et unity-2d ne sont pas franchement au point pour fonctionner sur une autre distribution qu’ubuntu ou l’un de ses dérivés.

Continuer la lecture de « Unity, un cul-de-sac à terme pour Canonical ? »

Encore un appeau à geek… Le test de compatibilité d’EcmaScript. Partie 2.

Deuxième partie de l’article entamé précédemment.

Commençons par le navigateur officiel de Xfce, j’ai nommé Midori.

La version 0.4.1 du navigateur obtient le même score qu’Epiphany, à savoir : 797 erreurs sur 11016 tests. Compatibilité : 92,76%

Passons maintenant à celui qui a été à une époque avec une part de marché quasi-monopolistique, je parle d’Internet Explorer. Et j’avoue avoir été plus que surpris par le résultat de celui-ci.

Dans sa version 9, il arrive à 323 erreurs sur 11016 tests. Compatibilité : 97,06%

Il se paye le luxe d’arriver à la troisième marche du podium, derrière Opera et Mozilla Firefox…

Continuer la lecture de « Encore un appeau à geek… Le test de compatibilité d’EcmaScript. Partie 2. »

Encore un appeau à geek… Le test de compatibilité d’EcmaScript. Partie 1.

EcmaScript ? C’est le nom « officiel » de javascript, langage interprété qui est à la base de nombreuses applications sur la toile. Avec HTML5, CSS3 et d’autres technologies standardisées et ouvertes, on pourrait – presque entièrement – se passer du standard de fait qu’est Adobe Flash.

Google avec Chrome a fait de la rapidité d’interprétation de ce langage son cheval de bataille, avec son célèbre test, le V8.

Cependant, même si tous les navigateurs modernes proposent désormais une vitesse d’interprétation plus que correcte de ce langage, quel est leur niveau de compabilité avec la norme EcmaScript ?

J’ai donc comparé les résultats de Chromium (17, donc Google Chrome 15 va pas tarder à faire les bonnes pages de la presse informatique), la nightly de Mozilla Firefox (actuellement en 10.0a1pre), Epiphany 3.21.

Et pour faire un bon rapport, la version 12 alpha (build 1105) du navigateur scandinave, via cette adresse : http://snapshot.opera.com/unix/alpha_12.00-1105/

Continuer la lecture de « Encore un appeau à geek… Le test de compatibilité d’EcmaScript. Partie 1. »

XSane2Tess : ou comment marier Tesseract et XSane.

Il y a plus d’un an, je parlais du logiciel « gImageReader », bien pratique pour avoir une interface « sociale » pour l’outil d’OCR Tesseract.

Cependant, le logiciel est depuis quelques temps au point mort (la dernière modification datant d’août dernier).

Et comme je suis le mainteneur du paquet sur AUR, j’ai reçu récemment un message m’informant que le logiciel ne se lançait plus du tout.

Could not load GTK modules: /usr/lib/python2.7/site-packages/poppler.so: undefined symbol: poppler_page_render_to_pixbuf_for_printing

Après quelques recherches, le bug se trouvant lié à poppler, j’ai rapporté l’information au développeur de gImageReader pour qu’un correctif soit appliqué.

Cependant, ayant parfois besoin de récupérer des textes via l’OCR (et tesseract effectuant un travail extraordinaire dans ce domaine), j’ai décidé d’adopter le paquet xsane2tess tout en le mettant à jour.

XSane2tess, c’est un petit script qui est bien pratique, et dont un guide bien pratique se trouve sur la documentation d’ubuntu-fr.

Voici les réglages à appliquer pour utiliser xsane2tess. Les captures d’écran qui suivent sont basées sur XSane 0.998.

Première étape, après avoir installé le paquet et lancé Xsane, on va dans Préférences / Configuration / OCR.

Et dans la ligne « Commande OCR », on insère :


xsane2tess -l fra

xsane2tess 01

fra étant pour le français, eng pour l’anglais, deu pour l’allemand, etc… La liste des langues supportées se trouve dans /usr/share/tessdata/.

On ferme le panneau de configuration. Ensuite, pour lancer une OCR, on choisit les options suivante : pour le type, on choisit « TEXT », on prend une numérisation en « gris » et pour la résolution, on choisit 300.

xsane2tess 02

Ensuite, on acquiert l’aperçu, on sélectionne la partie à travailler, et on clique sur Numériser. Le résultat est disponible dans le nom du fichier indiqué à coté de l’icone en forme de disquette.

C’est moins « facile » qu’avec gImageReader, mais au moins, cela fonctionne encore 😉

Une partition / n’est jamais assez vide…

La partition / en informatique, c’est sur des systèmes unix-like (linux, les BSDs), l’endroit du disque dur où se trouve les logiciels du système, tout comme la partition /home stocke les données des différents utilisateurs. Du moins pour les distributions qui proposent une partition /home dès l’installation. Et avoir une partition /home séparée m’a sauvé plus d’une fois la mise !

En partant de la machine virtuelle créée dans un précédent billet, je vais vous montrer comment gagner de la place d’une manière assez rapide, sans pour autant déstabiliser le système.

Commençons par installer localepurge (sudo pacman -S localepurge ou apt-get install localepurge sur les distributions à base de debian, pour Fedora et les autres distributions, désolé, je ne sais pas).

Sur ce plan, on peut reprendre les infos de l’article du blog Choix Libre, mais il manque un réglage pour le fichier /etc/locale.nopurge.

Continuer la lecture de « Une partition / n’est jamais assez vide… »

Et si on se faisait une Lubuntu à la sauce Archlinux ?

Lubuntu, c’est le mélange Lxde et d’Ubuntu. Aimant bien les trucs inutiles, j’ai voulu voir si je pouvais me faire un équivalent à cette nouvelle dérivée officielle d’ubuntu avec ArchLinux.

Même si le site officiel annonce que Lubuntu peut tourner avec 128 Mo, je vais être un peu plus réaliste, et utiliser une machine virtuelle avec 256 Mo de mémoire vive, 32 Go de disque, et un processeur 32 bits.

Oui, étant donné que Lxde est un environnement qualifié de léger, et dixit ses créateurs qu’on peut le faire fonctionner avec des machines datant de 1999, on va émuler une machine avec de très faibles ressources (contrairement à nos monstres de puissances qui sont parfois équipés d’octo-core, tout cela pour balancer des oiseaux dans des cochons, alors que pour envoyer Apollo 11 et ses congénères la puissance des ordinateurs était largement plus faible…)

Donc, voici les lignes de commandes que j’ai utilisé :

[fred@fredo-arch ISO à tester]$ qemu-img create -f qed disk.img 32G
Formatting 'disk.img', fmt=qed size=34359738368 cluster_size=65536 table_size=0
[fred@fredo-arch ISO à tester]$ qemu-system-i386 --enable-kvm -m 256 -k fr -soundhw all -hda disk.img -cdrom archlinux-2011.08.19-netinstall-i686.iso -boot order=cd &

Continuer la lecture de « Et si on se faisait une Lubuntu à la sauce Archlinux ? »

Allez, un test à la c** ! Voyons quel est le gestionnaire de paquets le plus véloce :)

Les gestionnaires de paquets sur les distributions gnu/linux sont principalement : rpm (yum), deb (aptitude / apt-get). Il existe d’autres gestionnaire, comme pacman (ArchLinux), pacman-g2 (Frugalware) pour ne citer que les principaux formats de paquets alternatifs au duo rpm / deb.

J’ai voulu comparer yum, aptitude et pacman. La comparaison se base sur la durée nécessaire pour installer un logiciel aussi imposant que LibreOffice.

Ce test n’a aucune valeur scientifique, j’ai juste vouloir voir la différence de vélocité des trois gestionnaires de paquets.

J’ai donc utilisé VirtualBox, avec une Fedora 16 beta à jour (gnome 3.2), une Debian Wheezy à jour (gnome 2.30.2) et une ArchLinux avec le dépot testing activé (gnome 3.2).

VirtualBox en action :)

Chaque machine virtuelle est doté de 2 Go de mémoire vive, et d’un disque virtuel 32 Go.

Pour la Fedora, j’ai du lancé Gnome-Shell à la main. Pour Archlinux – et pour une raison à déterminer – j’ai du me passer de GDM qui me gelait la machine virtuelle et lancer Gnome-Shell en utilisant le bon vieux startx 🙂

Pour la Debian Wheezy (future Debian 7.0), le hic est que LibreOffice est déjà préinstallé. J’ai donc passé un peu de temps à virer la version installée avant d’en installer un nouvel exemplaire.

On va utiliser l’ordre alphabétique, et commencer par Archlinux.

Continuer la lecture de « Allez, un test à la c** ! Voyons quel est le gestionnaire de paquets le plus véloce 🙂 »