Google Desktop est maintenant disponible sous Linux (vu sur Zorgloob), cette première version ne permet « que » l’indexation et la recherche et est disponible en paquet RPM et Debian (instructions et scripts d’installation). On peut naturellement espérer que nous les autres fonctionnalités seront également disponibles dans un proche avenir, mais il est déjà intéressant de voir que la recherche fonctionne entre autre sur les codes sources et le man. Il s’intègre également dans KDE et Gnome.

Pour Gentoo, un premier ebuild est disponible (discussion sur le forum). Après avoir ajouté l’ebuild dans le répertoire local puis téléchargé le RPM depuis le site de Google, j’ai peu sans problème créer le digest et l’installer en quelque instant. Après avoir lancé gdlinux un icone est apparu dans la barre des tâches et j’ai peu accédé au menu et à la barre de recherche sans problème. Il reste encore à faciliter l’installation du plugin pour Firefox par exemple, mais j’invite ceux qui sont intéressés par cet outil à tester l’ebuild afin d’aider à la finalisation de celui-ci.

Je sais que certain pense qu’utiliser cet outil donne trop d’informations personnelles à Googler, mais après tout c’est une question de confiance et chacun fait son choix par apport à ça. J’aime bien les outils de cette compagnie alors je les utilise.

Il était temps pour moi de mettre un peu à jour mon environnement de développement, c’est-à-dire installer ce qui me manquait, mettre à jour ce que j’avais et pour finir faire le ménage dans ce que je n’utilisais pas. Je développe principalement en Ruby et pour Ruby on Rails, mais fait également du PHP et ai parfois un script en Perl ou Python ; sans oublier le Javascript et le XHTML / CSS. Il faut ajouter à cela une base de donnée (MySQL) et quelques besoins particuliers en matière de communication réseau.

Pour rappel mon desktop professionnel est sous Linux / Gentoo et celui que j’ai chez moi sous Windows (j’apprécie pouvoir jouer à des jeux vidéo dans de bonnes conditions) ; j’essaie dans la mesure du possible d’avoir les mêmes outils sur les deux machines bien que ma console et tous les outils que j’y trouve me manque quand je suis chez moi.

Pour commencer le gestionnaire de version. Tous mes projets sont gérés avec subversion, ce logiciel est pour moi indispensable au bon déroulement du développement, premièrement pars qu’il me permet de synchroniser correctement mes deux postes de travail (bureau et domicile) quand je suis seul sur un projet et de même quand on est plusieurs (même si ce n’est qu’un développeur et un graphiste). Je n’entrerai pas dans le détail de l’utilisation d’une application de ce type qui apporte aussi bien d’autres avantages (suivi des modifications, possibilité de revenir en arrière, gestion de différentes branches de développements, …).

J’ai adopté Eclipse comme IDE car il offre des plugins qui intègrent les différents langages dont j’ai besoin. Il est agréable de ne pas changer de logiciel et donc de méthode de travail à chaque fois qu’on passe d’un projet à un autre (ou d’un système d’exploitation à un autre) et l’environnement de base est très bien foutu. J’ai bien réduis le nombre de plugins que j’utilise en installant Aptana (attention il y a actuellement deux plugins à installer : Base + Ruby & Rails). Celui-ci offre donc tout ce dont j’ai besoin pour PHP, Ruby, Rails, HTML, CSS et Javascript. A ceci il faut ajouter subclipse pour gérer mes projets sous subversion, EPIC pour l’intégration de Perl (je viens de l’installer, je n’ai donc pas plus d’avis que ça dessus) , PyDev pour Python (que j’ai déjà utilisé par le passé et que je viens d’installer à nouveau) et Mylar.

Il me faut naturellement un Navigateur web et j’utilise donc principalement Firefox. J’y ai ajouté quelques extensions qui vont bien tel que Web Developer et Firebug (j’ai enfin cherché pourquoi il ne fonctionnait pas sur ma machine et en fait il faut compiler Firefox avec le USE Flag « mozdevelop » ) ainsi que Tab Mix Plus (dont certaines options sont bien agréables) et le dictionnaire MySpell en français ;-). J’en ai d’autres, mais elles ne sont pas là pour le développement (FlashGot, Google Brower Sync, Google Gears, Google Reader Notifier, coComment).

Enfin j’ai un serveur Apache et MySQL qui tournent et PhpMyAdmin pour gérer les bases de données.

Ma machine sous Linux m’offre également une flopée d’outils bien utile que je regrette quand je suis sous Windows. Il faudrait également que je prenne parfois le temps de me tenir au courent afin d’éventuellement pouvoir adopter de nouveaux outils… Si vous avez des suggestions n’hésitez pas :-)

Une nouvelle release de la Gentoo est un peut un non évènement pour un utilisateur courent, on n’attend pas qu’elle sorte pour mettre notre machine à jour, tout au plus le changement de profil apportera quelques changements aux USE flag.

C’est surtout un nouveau liveCD qui inclura les versions récentes des logiciels courent et mettra à jour le processus d’installation. Le communiqué officiel explique qu’il aura fallu du temps pour préparer la version 2007.0 à cause d’un nombre anormale de vulnérabilité dans les paquets. « Secret Sauce » son petit nom, apporte une réécriture complète de l’installeur pour AMD64 et x86, le nouveau liveCD (et liveDVD) contient GNOME 2.16.2, KDE 3.5.5, Xfce 4.4, Mozilla Firefox 2.0.0.3, OpenOffice.org 2.1.0, et le kernel Linux 2.6.19.

Stephan Binner, développeur sur KDE et OpenSuse, viens de mettre à disposition un live cd de la version 4 de KDE. À quelques jours de la sortie d’une première version alpha, cette initiative nous permet à tous d’avoir une idée de l’avenir de notre desktop (en tout cas pour ceux, comme moi, qui utilise KDE :-)). Il reste cependant encore beaucoup de travail et des logiciels présents vont encore être remplacés par d’autres, il est donc inutile de se précipiter pour faire des bug report, attendez pour ça la version alpha officiel et les consignes à ce sujet.

Télécharger le live cd

Le temps passe est ma Gentoo s’encrasse ; à force d’installer des logiciels pour les supprimer aussi tôt après les avoir essayés on se retrouve avec un grand nombre de dépendances orphelines ; à chaque mise à jour le répertoire distfiles grossis ; on fini par avoir des slots inutiles mais dont portage ne se souciera pas.

Il est donc utile de faire le ménage de temps en temps, pour commencer ce n’est pas une mauvaise idée de jeter un œil à son fichier world et de désinstaller les logiciels dont on a pas besoin (dans le doute il vaut toujours mieux en laisser trop que pas assez) :

$ cat /var/lib/portage/world
$ emerge -Cav package-name

Pour la suite nous avons besoin de deux packages (gentoolkit et udept):

$ emerge -av app-portage/gentoolkit
$ emerge -av app-portage/udept

Maintenant le but est de retiré du fichier world les packages qui ne sont que des dépendances. Attention tout de même, si un package est noté comme dépendance d’un autre mais qu’on en a de toute façon besoin il ne faut pas l’effacer. Il n’est pas bête de faire également un backup du fichier world, on ne sait jamais. On peut également en profiter pour mettre à jour ses USE flag afin de fignoler le tout.

$ cp /var/lib/portage/world /var/lib/portage/world.bak
$ dep -pw

La commande dep va donner la liste des packages qui se trouvent dans le fichier world et qui font partie des dépendances d’autres ebuilds. Il faut maintenant effacer dans le fichiers ceux qui doivent être traiter comme des dépendances (mais laisser ceux que on désire garder même si ils sortent de la chaine de dépendance).

On peut maintenant supprimer toutes les dépendances inutiles (attention, le système peut rencontrer une certaine instabilité depuis maintenant et jusqu’à la fin des opérations qui vont suivre).

$ dep -as

La commande dep va proposer de désinstaller un certain nombre de packages, il est possible que certains ne doivent pas l’êtere, il suffit alors de les ajouter au fichier world avec la commande suivante :

$ emerge -v --noreplace package-name

Une fois qu’on est d’accord avec cette liste on peut laisser portage faire son travail (s’est ici qu’il peut arriver de supprimer des dépendances qui ne devraient pas l’être mais ceci sera réparé plus tard).

Il faut faire la même chose pour supprimer les slots inutiles :

$ dep -aP

Voilà, le ménage est fait mais il faut maintenant s’assurer que le système est complet et stable de la façon suivante :

$ emerge -uDNav world && revdep-rebuild

Ces deux commande vont recompiler des dépendances qui aurais malencontreusement été effacées, éventuellement mettre à jours les packages dont les USE flag ont changés et recompiler les binaires dont les dépendances envers des librairies auraient été brisées.

Pour terminer faire le ménage dans le répertoire distfiles avec la commande suivante :

$ eclean -d distfiles

Voici une Gentoo comme neuve, prête à repartir pour un tour.

Le projet OLpC (One Laptop per Child) viens de lancer la première série de production. C’est 1000 machine au prix unitaire de 135$ qui viennent d’être assemblé dans les usines de Quanta Computer, à Shangaï en Chine. Un prix unitaire à 100$ est prévu à l’horizon de 2008.

Design par le Fuse Project

Cette première série est destiné à tester la robustesse de la machine et ses fonctionnalités. Ce n’est plus un prototype. L’interface graphique, spécialement étudier pour cette machine est différente de se dont nous avons l’habitude mais est fortement adapté au publique cible, s’est à dire les enfants et une éventuelle utilisation trivial par des adultes.

Pour plus d’information :

• site du projet OLpC
• OLpC sur wikipédia
• Fuse Project pour le design

J’ai du créer un patch pour faciliter le déploiement de quelques modifications mineurs sur le site web d’un client par leur technicien. J’ai finalement trouvé quelques exemples de l’utilisation de diff et de patch. Je cherche ces informations à chaque fois que j’en ai besoin car je n’utilise pas cette technique très souvent.

Donc pour faire un patch il faut évidement avoir gardé une version du contenu avant les modifications, se contenu étant le répertoire old, le nouveau contenu étant le répertoire new (ces noms ont aucune importance, il faut simplement avoir ces deux répertoires). Donc nous créons le patch à partir de ceux-ci.

diff -urN ./old ./new > file.patch

-u : le format du patch est unified
-r : créer le patch récursivement
-N : Les fichiers absents sont considérés comme des fichiers vides

Nous allons le tester en faisant une copie du répertoire old vers test par exemple et y appliquer le patch de la manière suivante.

patch -p1 -d --dry-run ./test < file.patch

-p1 : afin d'ignorer le nom du premier répertoire (en effet, celui utiliser
      pour créer le patch n'est pas forcément le même que celui où il doit
      être appliqué)
-d : spécifie le répertoire où le patch doit être appliqué
--dry-run : n'applique pas réellement le patch mais retourne tout les messages
           et donc les éventuelles erreurs généré lors de son application

Si il n’y a pas d’erreur, lancer la même commande sans —dry-run puis contrôler que tout s’est bien passé avec la commande diff.

diff -urN ./new ./test

Si elle ne retourne aucune différence s’est que tout va bien.

Lors de l’application final il est conseillé de faire une copie des données pour commencer, de lancer patch d’abord avec —dry-run, et si tout se passe bien de le lancer sans après.