TechCrunch annonçais que Twitter allais abandonner complètement RoR au profit de PHP ou Java, relançant les Troll sur les performances de Ruby et Rais pour des sites à fort trafic. Evan Williams, développeur chez Twitter, infirme cette information en rappelant que Twitter utilise déjà d’autres langages, raison d’une certaine confusion.

Il faut bien se rendre compte que dans le cas d’une application à forte charge comme celle-ci, beaucoup d’aménagements ont dû être fait afin d’essayer d’en optimiser les performances. Twitter n’est pas si simple et ce n’est pas un changement de langage qui y changera quelque chose, en déplaise à tous les trolleurs et autres développeurs à l’esprit étroit qui pense qu’il y a un langage universel. Utiliser Ruby, PHP ou Java est un choix, chaque plateforme à des avantages et inconvénients, aux développeurs de trouver celui qui leur convient le mieux dans un contexte précis.

Update : Vue mon état  semi-comateux (bronchite viral, une température ayant du mal à passer en dessous de 39°C depuis deux jours) ce message de Matt Aimonetti sur la mailing-list de Rails France m’a échappé, il donne quelques éclaircissements sur le sujet. Merci à Nicolas pour avoir fait passé l’info (et moi je ne suis pas en état de ne pas dire du mal des trolleurs professionnels).

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.

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.

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.