Beaucoup (toutes ? de ROM que l'on trouve pour Android se prétendent plus rapides et plus stables. De toute celle que j'ai testé (une bonne dizaines), c'est tout de même la MoDaCo qui ment le moins. D'un point de vue fonctionnel, la couche applicative étant la même que la ROM HTC Hero d'origine, il n'y a guère de surprises. Tout fonctionne à l'identique (bluetooth, APN à 5Mp, etc.). Pour la stabilité c'est un peu la même chose puisque cette ROM tourne sous Android 1.5 pour lequel a été conçu et testé cette couche applicative. Enfin concernant les performances, elles sont sans aucun doute meilleur. Le mérite revenant en grande partie à l'utilisation du Teknologist Kernel, un noyau linux optimisé pour le Hero, qui active le CompCache. Mais malgré cela, il est possible d'obtenir encore mieux de cette petite bestiole.

Une fois les bons outils en main, le bidouillage d'un androphone est un véritable plaisir, pour peu que l'on s'y retrouve dans les multiples conversations dans la myriade de forums qui explique chacune un bout du sujet. L'objectif de ce tutoriel de regrouper les étapes qui mènent à la connaissance de ces outils avec comme but "ultime" l'installation d'un bootstrap magique qui permet de tout faire, ou presque, avec son téléphone.

Avec l'expansion pandémique (le terme est à la mode de "services" comme Google Analytics, les moyens de se prémunir des SpyWebs prennent de plus à en plus d'importance. Et si des outils comme adBlock offre une très protection locale efficace, la protection d'un réseau dans son entier ne peut se passer de privoxy, un proxy filtrant aux possibilités étonnantes et disponible sur beaucoup de systèmes de Windows à Linux en passant par AmigaOS.

Je vois déjà Dab faire des petits bons Désolé mais non, je ne migre pas vers Debian mais comme je suis régulièrement confronté à cette distribution sur des serveurs en production, j'ai souvent besoin de savoir comment passer de l'un à l'autre des deux mondes, pour ce qu'ils ont de différent. Ce qui suit est donc une simple table de conversion permettant, lorsque l'on est habitué à Mandriva, de répondre à la question "Comment on fait ... sur une Debian ?".

L'objectif est ici de mettre en place un serveur subversion comprenant la mise en place du dépôt, la configuration d'apache et le paramétrage des messages de notifications.

La synchronisation des contacts, agenda et autre PIMerie, dés lors qu'n GNU/Linux était de la partie, a de tout temps été un véritable enfer. Déjà à l'époque du Palm III c'était tout un poème pour que les deux environnements soient un tant soit peu synchrones. Aujourd'hui, que l'on se rassure, la synchronisation de cette vénérable périphérique passe à merveille, mais c'est pour du matos plus récent que ça coince. La faute à quoi ? Comme toujours à des protocoles pas ouvert que les développeurs du libre doivent comprendre, bidouiller et intégrer dans d'honorables projets comme OpenSync avec des passerelles vers synce histoire de prendre en compte les windowseries. Ça modprobe en tout sens, ça coince autant que ça peu et au final, soit les données sont en vrac de part et d'autre, soit rien ne s'est passé tout simplement.

Pourtant il existe bien un protocole ouvert et normalisé capable de synchroniser tout avec n'importe quoi, du moins en théorie. Et ce protocole miraculeux s'appelle SyncML...

Petite révolution dans la demeure, je vais encore chambouler notre architecture domestique. En effet, puisqu'aujourd'hui je travaille exclusivement dans mon garage (le vieux rêve que voilà -;), je n'ai plus le courage d'éteindre la bête de course qui me sert de poste de travail. Du coup, le petit serveur miniITX a perdu sa raison d'être et l'envie m'a pris de la virtualiser sur la grosse bête. Quoi de plus logique au fond, tant qu'à consommer des watts, autant que cela soit le plus rentable possible.

Malgré tout, virtualiser "à la KVM, XEN ou VirtualBox" ne me plaisait pas des masses. Trop lourd pour le besoin. Quant à chrooter tout cela, pas assez fiable. C'est alors qu'un ami (coucou Daniel) m'a suggéré la solution OpenVZ. Ce n'est finalement pas elle que je vais mettre ici en oeuvre mais c'est ainsi que j'ai mis le doigt sur un concept de super-chroot alliant isolation et performance.

Toujours dans l'idée de la construction de mon réseau domestique, s'est peu à peu imposé le besoin de disposer de nos fichiers locaux (documents, photos, etc.) à travers notre intranet. Cela était déjà possible en lecture simple, mais une chose en entraînant une autre, est venu la nécessité de rendre possible l'écriture sur ces partages.

Exporter un partage en NFS ou même CIFS à travers le NET n'est pas impossible mais reste un peu limite en terme de sécurité. Passer par un tunnel est une solution viable mais relativement lourde à mettre en oeuvre, surtout lorsque le poste client est un windows. C'est ainsi que la solution WebDAV c'est imposée d'elle-même.

Une machine, c'est bien connu, cela ne tombe en rade que dans la nuit ou en week-end. Dés fois, lorsque l'on a un peu de chance, c'est même les deux... Et lorsque le plantage se situe sur une Dédibox, on est un peu dans la mouise, avec Free qui considére que l'administration est une chose qui doit se passer dans des horaires de bureau... Du coup, lorsque la demande porte sur une KVM, nous n'avons plus qu'à attendre tout le week-end avec tous nos sites en carafe...

Fort heureusement il y a l'ami GNU/Linux. Avec celui-là, même si elle n'est pas forcément évidente, il y a toujours une solution de repli. Ici, il s'agit d'exploiter le système de secours de la Dedibox.

Il y a deux cas de figure (en tous cas me concernant) où il est nécessaire de convertir un PDF classique (où l'on peut sélectionner du texte) en une version où chaque page est une simple image. Il y a le cas de notre douce administration française et de ses formulaire à remplir. Il est tout de même plus agréable (pour eux, vu mon écriture de faire cela sous GIMP. Et il y a le cas où l'on ne veut pas que le document fournit à un tiers finisse en copier-coller un peu partout.