Pour faire comme tout le monde et surtout car ca fait plaisir, je vous annonce que Fedora a 5 ans ! Vive Fedora, vive sa communauté, son chan IRC et surtout, vive Linux ! Bon anniversaire ! ... et vivement la suite ... !... Lire Fedora a 5 ans !

Alors que tout le monde parle de Google Chrome et des ses failles, et vu que je ne peux pas tester Google Chrome sur Linux car il n'est toujours pas disponible, j'ai décidé d'essayer le moteur utilisé (Webkit) par Google Chrome sur mon navigateur web préféré : Epiphany !

Préparation

Il faut tout d'abord désinstaller la version actuelle d'Epiphany pour la remplacer par la version utilisant Webkit.

yum remove epiphany

Installation

Ensuite en fonction de notre système nous allons télécharger le paquet pour Fedora 9.
Pour les systèmes 32 bits :

wget http://mirror.yandex.ru/fedora/tigro/9/i386/epiphany-webkit-2.22.1.1-1.fc9.2.i386.rpm

Pour les systèmes 64 bits:

wget http://mirror.yandex.ru/fedora/tigro/9/x86_64/epiphany-webkit-2.22.1.1-1.fc9.2.x86_64.rpm

Utilisons yum maintenant pour installer ce paquet:

yum localinstall -y --nogpgcheck epiphany-webkit-2.22.1.1-1.fc9.2.*.rpm

Utilisation

Et voilà notre Epiphany avec Webkit utilisable.
Ce qu'on peut remarquer c'est la vitesse d'affichage des pages et aussi la rapidité de démarrage de l'application, mais je vous laisse vous faire votre propre opinion !

Alors qu'en pensez-vous?

La version GNU de java pose actuellement différent problèmes lors de l'interprétage d'un script java utilisant AWT/swing sous un environnement UNIX. En effet, il existe un problème dans la gestion des events qui a été notifié il y a déjà quelques temps. Dans le cadre de mes cours à l'IUT, nous avons (enfin) commencé à utiliser AWT et très... Lire OpenJDK : une alternative à la version GNU de java

J'avais présenté dans un billet précédent le logiciel Itaka et avait fait la demande de revue sur le bugzilla. Ce paquet a été approuvé (merci kwizart) et se trouve désormais disponible dans rawhide, F9 et F8 (dépôt stable). Pour l'installer, il suffit donc de taper :

# yum install itaka

Fabien (eponyme)

Proposition d'un RPM pour le logiciel printoxx.

J'avais présenté FotoWall dans un ancien billet. Printoxx est très proche de ce logiciel (en moins bien pour le moment il faut l'avouer).
Ce logiciel permet de monter un "pêle-mêle" de photos, et d'en imprimer le résultat. En revanche il ne permet pas l'export vers un format image, mais simplement de sauvegarder le layout. Il est possible de faire pivoter les images et les titrer. Rien de bien exceptionnel, mais plutôt sympa. Evidemment si on l'essaie après FotoWall, on est un peu décu.

Ce logiciel n'étant pas présent dans les dépôts, je l'ai packagé et ai fait la demande de revue sur le bugzilla (voir bug #460838). En attendant, voici le RPM pour Fedora 9 (arch i386!) :

D'abord installer ma clé GPG (si elle n'est pas déja installée)  :

# rpm --import http://nicoleau.fabien.free.fr/rpms/RPM-GPG-KEY-NicoleauFabien

Ensuite télécharger et installer le RPM :

$ wget http://nicoleau.fabien.free.fr/rpms/fc9.i386/printoxx-1.2-1.fc9.i386.rpm
# yum install printoxx-1.2-1.fc9.i386.rpm

Les retours sont les bienvenus.

Fabien (eponyme)

Samedi j'étais à Leroy Merlin pour faire quelques courses, à la caisse j'ai eu l'agréable surprise de voir que les caisses étaient powered par notre ami Tux.

Ok l'info ne date pas d'hier, mais ca fait toujours bizarre la première fois que l'on s'en rend compte (et puis j'ai jamais cherché à savoir si elles l'étaient avant, en Tunisie il n'y a pas de Leroy Merlin ;)" class="smiley ).

Au passage une photo de la caisse en question :

Et un grand merci à A. de m'avoir laissé photographier sa caisse ^^

Le libre vaincra !

Samedi j'étais à Leroy Merlin pour faire quelques courses, à la caisse j'ai eu l'agréable surprise de voir que les caisses étaient powered par notre ami Tux.

Ok l'info ne date pas d'hier, mais ca fait toujours bizarre la première fois que l'on s'en rend compte (et puis j'ai jamais cherché à savoir si elles l'étaient avant, en Tunisie il n'y a pas de Leroy Merlin ;)" class="smiley ).

Au passage une photo de la caisse en question : Et un grand merci à A. de m'avoir laissé photographier sa caisse ^^

Le libre vaincra !

motion est un logiciel libre de surveillance vidéo automatisé. Il vous permet de lancer votre web-cam à distance (/etc/init.d/motion) et de la consulter via une url du type http://chez_moi:8180.

Le site de motion propose un RPM pour Fedora 7 ainsi qu'un SPEC sur lequel je me suis basé pour construire des RPMs adaptés à Fedora 8 et 9.

Le site Pingdom à publié un article dernièrement faisant un état des lieux sur la popularité de Linux à travers le monde. Pour obtenir ces résultats, ils se sont tout simplement basés sur les statistiques de recherches sur certains mot clés (Linux, Ubuntu, Fedora, Mandriva ….), fournit par le moteur Google.

Ils ont pu ensuite générer une cartographie mondiale, qui permet de voir quels sont les pays où ce système dexploitation est le plus populaire. Et les résultats sont plutôt inattendus.

En effet, on remarque que les 3 pays ou Linux est très demandé sont l'Inde, Cuba et la Russie, suivit de près par la République Tchèque et l'Indonésie.

Personnellement, je m'attendais à de meilleures résultats pour l'Europe par exemple, où certains logiciels libres on la côte (ex: Firefox) par rapport à d'autre pays dans le monde.

S'il y a bien une chose que j'apprécie sur Debian, c'est la façon dont ils ont packagé Apache. En effet, sous Debian, les fichiers vhost sont déposés dans /etc/apache2/site-available (bon, apache2 vs httpd c'est discutable…) et pour activer un vhost il suffit de faire un lien vers le fichier dans le répertoire /etc/apache2/site-enabled.

Pour cela, les packagers ont crée 2 scripts a2ensite (activation) et a2dissite (désactivation). Sur les serveurs que je gère, à base de RHEL tout comme à base de Fedora, j'ai pris l'habitude de travailler de la même façon. J'ai alors porté les 2 scripts cité plus haut pour ces environnements. J'en ai aussi profité pour les modifier et en améliorer quelque peu la lisibilité (les goûts et les couleurs...).

Comme en ce moment je suis clairement dans une politique de packaging, je me suis fait un petit rpm qui va me permettre de reporter facilement ces 2 scripts sur mes nouveaux serveurs et aussi de créer les 2 répertoires site-(enabled|disabled). Si vous aussi vous appréciez les a2scripts de Debian ainsi que cette façon de travailler, je vous les mets à disposition (annexes).

Je pense aussi très prochainement intégrer mon script new_site dans ce RPMs donc affaire à suivre…

Remarque : Le RPMs pour propager des scripts et des configurations sur des serveurs c'est quand même le top ! Un rpm –qa et j'ai la version du script en place.

J'ai récemment entrepris de migrer les backups de Borsalino & spb-box, les 2 serveurs que j'administre, sur une nouvelle solution de sauvegarde. En effet, jusqu'à présent j'utilisais l'option mirror de lftp qui est limitée tant en performances qu'en sécurité.

N'ayant pas de machine sous la main pour monter un serveur BackupPC, j'ai reporté mon choix sur l'utilitaire backup-manager qui permet de faire des sauvegardes incrémentielles en local et de les envoyer par FTP ou SSH. backup-manager ne disposant pas de RPMs, la première étape a donc été de construire les RPMs pour mes différentes machines (make install c'est caca !).

Les RPMs fonctionnant parfaitement, ce sont eux que je vous propose en annexe et que j'ai soumis à une demande de revue afin qu'ils soient intégrés (je l'espère du moins) à Fedora.

Merci à Trashy et RemiFedora ainssi qu'à tout ceux qui sont là sur #fedora-devel-fr@freenode.net pour aider à la création de RPMs...

Bonjour à tous !

Je pars demain de bonheur pour m'installer en bretagne ce qui fait que je serai absent du web pour une certaine durée, au moins jusqu'à rétablissement de ma connexion.

Je ne posterai donc plus de billets, ni ne serai joignable sur le forum, irc etc. Mais si vous avez quelque chose à dire il reste toujours l'option du commentaire sur ce billet ;-)" class="smiley

Bonjour à tous !

Je pars demain de bonheur pour m'installer en bretagne ce qui fait que je serai absent du web pour une certaine durée, au moins jusqu'à rétablissement de ma connexion.

Je ne posterai donc plus de billets, ni ne serai joignable sur le forum, irc etc. Mais si vous avez quelque chose à dire il reste toujours l'option du commentaire sur ce billet ;-)" class="smiley

Le problème des sauvegardes est toujours délicat sur un serveur, et il est très important d'y apporter une grande attention afin de ne pas avoir la désagréable surprise de perdre des données importantes.

Avec un serveur de bases de données, il faut s'assurer de faire un dump minimum quotidien des données, jusqu'à maintenant j'avais un script de ma conception pour réaliser ce dump, mais je viens de découvrir la disponibilité d'un autre script bien plus avantageux : Automatic Mysql Backup.

En téléchargeant ce automysqlbackup, j'ai enfin trouvé le script idéal pour faire une sauvegarde de mes bases de données.

Automysqlbackup va nous permettre :

• Dump des différentes bases dans des fichiers séparés et dans un seul et même fichier (plus facile pour restaurer tout d'un coup).
• Compression des fichiers sauvegardés afin d'économiser l'espace disque utilisé.
• Génération de rapport de sauvegarde par email.
• Possibilité de joindre le backup dans l'email (réservé au sauvegarde de base peu volumineuse).
• ...

La personnalisation du script est très facile et son installation rapide.

Aussi certains de mes utilisateurs souhaitaient avoir un dump quotidien de leur base de données disponible via FTP afin de faciliter leur propre sauvegarde ou encore de ne pas avoir à le générer via un outil externe ( ex : PhpMyAdmin), jai donc crée un petit script qui doit s'exécuter à la suite de Automysqlbackup et qui va permettre de mettre à disposition des utilisateurs de mon serveur un dump quotidien archivé avec une rétention de 7 jours directement accessible depuis leur compte FTP.

Voici le script :

#!/bin/bash
#copie les dumps des bases mysql dans les home de chaque user

#test si existence répertoire de dump (exclusion de rep avec grep -v)
for i in $(ls /home |grep -v backup |grep -v celine |grep -v nepasdumper)
do
if ! [ -d /home/$i/dumps ]
then
#on cree les repertoires non existant
mkdir -p /home/$i/dumps
echo "creation du repertoire /home/$i/dumps"
echo ""
else
#on copie les dumps du daily
rsync -avz --delete /home/backup/mysql/daily/$i/* /home/$i/dumps
fi
done

Bien sûr ce script est à personnaliser en fonction de votre architecture, mais bon mes utilisateurs sont contents et moi aussi :)" class="smiley

A+

Récemment j'ai décidé de tester le pilote libre Nouveau pour cartes nvidia, j'ai eu la mauvaise surprise de voir qu'au démarrage l'affichage semblait se faire en 16 bits, la configuration de Xorg ainsi que les fichiers de log indiquaient pourtant que l'affichage se faisait bien avec une profondeur de couleurs de 24 bits. L'affichage avec le pilote nvidia est normal.

Après recherche, voici le pourquoi du comment de ce problème épineux.

En fait c'est une personne du chan #nouveau qui m'a livré la réponse. Le problème ne vient ni de la carte graphique, ni de nouveau, ni de Xorg mais du moniteur.

J'ai un portable avec écran LCD 15,4" format 16/10 (1280x800), dans les faits, avec le pilote forceware l'affichage se faisait très bien et il n'y avait aucun défaut d'affichage de couleurs, pourtant mon écran n'est capable d'afficher que 18bits ce qui fait que par un procédé logiciel l'affichage était corrigé pour la profondeur de 24bits, ce procédé est nommé diphtering.

Sur les conseils avisé de cette personne du chan j'ai donc activé l'option FPDither à TRUE dans mon xorg.conf :

Option      "FPDither" "TRUE"

Au redémarrage de X l'image m'apparaissait quasi normale, je dis bien quasi car il restait comme un léger bruit dans les zones ayant un dégradé par exemple, ceci est du au fait que le dithering des pilotes nouveau et nv (c'est le même) n'est pas aussi efficace que celui des pilotes nvidia, et évidemment ceux ci étant en source fermées la seule manière d'arriver à un résultat identique est le reverse engineering, c'est long, difficile et requiert des compétences que je n'ai personnelement pas :/

Alors pourquoi l'affichage était "normal" sous nvidia ? Ceux ci activent leur dithering par défaut, tout simplement.

Voilà donc, une petite explication d'un problème qui m'a pri la tête et mon temps, si vous avez le même, ne cherchez plus, votre moniteur n'est simplement pas capable d'afficher les 24bits de couleurs, activez l'option FPDither pour améliorer la qualité d'affichage ou restez avec les pilotes nvidia ;)" class="smiley

PS : Pour ceux qui se demandent pourquoi la profondeur de couleur la plus haute proposée sous Linux est de 24bits alors que Windows nous habitue à du 32bits une seule réponse : les 8bits de transparence (l'alpha) ne sont pas comptabilisés par Xorg tandis que sous Windows ca l'est, plus par marketing que par recherche de l'éxactitude technique.

Récemment j'ai décidé de tester le pilote libre Nouveau pour cartes nvidia, j'ai eu la mauvaise surprise de voir qu'au démarrage l'affichage semblait se faire en 16 bits, la configuration de Xorg ainsi que les fichiers de log indiquaient pourtant que l'affichage se faisait bien avec une profondeur de couleurs de 24 bits. L'affichage avec le pilote nvidia est normal.

Après recherche, voici le pourquoi du comment de ce problème épineux.

En fait c'est une personne du chan #nouveau qui m'a livré la réponse. Le problème ne vient ni de la carte graphique, ni de nouveau, ni de Xorg mais du moniteur.

J'ai un portable avec écran LCD 15,4" format 16/10 (1280x800), dans les faits, avec le pilote forceware l'affichage se faisait très bien et il n'y avait aucun défaut d'affichage de couleurs, pourtant mon écran n'est capable d'afficher que 18bits ce qui fait que par un procédé logiciel l'affichage était corrigé pour la profondeur de 24bits, ce procédé est nommé diphtering.

Sur les conseils avisé de cette personne du chan j'ai donc activé l'option FPDither à TRUE dans mon xorg.conf :

Option      "FPDither" "TRUE"

Au redémarrage de X l'image m'apparaissait quasi normale, je dis bien quasi car il restait comme un léger bruit dans les zones ayant un dégradé par exemple, ceci est du au fait que le dithering des pilotes nouveau et nv (c'est le même) n'est pas aussi efficace que celui des pilotes nvidia, et évidemment ceux ci étant en source fermées la seule manière d'arriver à un résultat identique est le reverse engineering, c'est long, difficile et requiert des compétences que je n'ai personnelement pas :/

Alors pourquoi l'affichage était "normal" sous nvidia ? Ceux ci activent leur dithering par défaut, tout simplement.

Voilà donc, une petite explication d'un problème qui m'a pri la tête et mon temps, si vous avez le même, ne cherchez plus, votre moniteur n'est simplement pas capable d'afficher les 24bits de couleurs, activez l'option FPDither pour améliorer la qualité d'affichage ou restez avec les pilotes nvidia ;)" class="smiley

PS : Pour ceux qui se demandent pourquoi la profondeur de couleur la plus haute proposée sous Linux est de 24bits alors que Windows nous habitue à du 32bits une seule réponse : les 8bits de transparence (l'alpha) ne sont pas comptabilisés par Xorg tandis que sous Windows ca l'est, plus par marketing que par recherche de l'éxactitude technique.

Après quelques jours passés à jouer avec KDE 4.1 (voir ce billet) le bug de KGoldRunner a malheureusement vite été rejoint par d'autres :-(" class="smiley

On nottera surtout un gros bug sensé avoir été corrigé dans les versions de développement mais qui est toujours bien là : http://bugs.kde.org/show_bug.cgi?id=167826 pour faire court, les processus des applications KDE ne se terminent pas une fois l'application quittée. J'ai remarqué ça en ouvrant le moniteur système de KDE, la charge était grande, la mémoire occupée atteignait 1.4 Go et le processeur était utilisé à 50% (soit un des deux coeurs à 100). Il y avait en tout 22 Konquerors et 109 kio_http d'ouverts, accumulés durant les quelques jours d'uptime.

Ce bug est censé être réglé dans la prochainte 4.1.1, soit dans un mois :-(.

Autre problème, de nombreux bugs d'affichage avec le pilote propriétaire nvidia, mais la ce n'est pas KDE le responsable mais bien nvidia, leurs forcewares gèrent très mal la 2D. D'ailleurs, effets de bureau activés avec Kwin et OpenGL, Kwin consommait 33% de CPU.

Et bien sur la zone de notification dont les icones n'ont plus de fond transparent ainsi que l'installateur de plasmoides pas vraiment au point...

Bien sur j'ai rapport les bugs qui ne l'étaient pas déjà mais ca reste quand même une belle déception, cette première et très attendue version majeure de la branche 4.x.x après la 4.0, critiquée pour ses défauts de jeunesse, était censée régler nombre des problèmes éxistants, certes elle en règle mais en apporte également son lot. Le bilan est donc mitigé mais je me demande toujours comment personne ne s'était rendu compte du bug de la kdelib censé avoir été résolue, en attendant le backport du correctif surveillez bien votre consommation mémoire.

Merci à Desintegr du chan #fedora-fr pour m'avoir apporté nombre de précisions sur ces bugs ;-)" class="smiley

Après quelques jours passés à jouer avec KDE 4.1 (voir ce billet) le bug de KGoldRunner a malheureusement vite été rejoint par d'autres :-(" class="smiley

On nottera surtout un gros bug sensé avoir été corrigé dans les versions de développement mais qui est toujours bien là : http://bugs.kde.org/show_bug.cgi?id=167826 pour faire court, les processus des applications KDE ne se terminent pas une fois l'application quittée. J'ai remarqué ça en ouvrant le moniteur système de KDE, la charge était grande, la mémoire occupée atteignait 1.4 Go et le processeur était utilisé à 50% (soit un des deux coeurs à 100). Il y avait en tout 22 Konquerors et 109 kio_http d'ouverts, accumulés durant les quelques jours d'uptime.

Ce bug est censé être réglé dans la prochainte 4.1.1, soit dans un mois :-(.

Autre problème, de nombreux bugs d'affichage avec le pilote propriétaire nvidia, mais la ce n'est pas KDE le responsable mais bien nvidia, leurs forcewares gèrent très mal la 2D. D'ailleurs, effets de bureau activés avec Kwin et OpenGL, Kwin consommait 33% de CPU.

Et bien sur la zone de notification dont les icones n'ont plus de fond transparent ainsi que l'installateur de plasmoides pas vraiment au point...

Bien sur j'ai rapport les bugs qui ne l'étaient pas déjà mais ca reste quand même une belle déception, cette première et très attendue version majeure de la branche 4.x.x après la 4.0, critiquée pour ses défauts de jeunesse, était censée régler nombre des problèmes éxistants, certes elle en règle mais en apporte également son lot. Le bilan est donc mitigé mais je me demande toujours comment personne ne s'était rendu compte du bug de la kdelib censé avoir été résolu, en attendant le backport du correctif surveillez bien votre consommation mémoire.

Merci à Desintegr du chan #fedora-fr pour m'avoir apporté nombre de précisions sur ces bugs ;-)" class="smiley

J'avais présenté dans un précédent billet le logiciel fotoxx et en avait demandé la revue sur le bugzilla.

Ce paquet a été approuvé est est désormais disponnible dans le dépôt stable, installable donc via la commande :

# yum install fotoxx

Fabien (eponyme)

J'avais présenté dans un précédent billet le logiciel fotowall avait demandé la revue sur le bugzilla.

Ce paquet a été approuvé est est désormais disponnible dans le dépôt stable, installable donc via la commande :

# yum install fotowall

Fabien (eponyme)