Dans mon article précédent, j’expliquais comment booter le Seagate Dockstar sur Plugbox directement sur le réseau, par TFTP et NFS.

Si cela fonctionnait effectivement, il subsistait en l’état un petit problème de performances : en effet, tout content d’avoir réussi à mettre ça en place, je ne m’étais pas aperçu que le montage NFS se faisait par défaut en NFS v2, avec des paramètres pas terribles
Gênant …

Donc voici comment passer les paramètres pour que le montage NFS se fasse en v3 (j’ai essayé en v4 et ça ne passe pas, mais j’avais eu le même problème sur PC, NFS v4 change pas mal de choses) avec des réglages un peu plus au goût du jour.

Toujours avec blparam, il faut simplement modifier cette variable :

rootpath2=<chemin local complet sur le serveur NFS de votre système de fichiers Plugbox>,v3,rsize=32768,wsize=32768,soft,tcp

Évidemment, adaptez à vos besoins et à la configuration de votre serveur NFS.
Ce sont néanmoins les réglages que je recommande afin d’obtenir de bonnes performances et une relative garantie de l’intégrité des données.

Attention, comme pour la dernière fois, avant de valider définitivement ces réglages chez vous, réglez bien bootcmd comme ceci :

bootcmd=run bootcmd3

Comme ça, si ces réglages ne fonctionnent pas chez vous (ou si vous avez fait une coquille), le boot d’après se fera sur Pogoplug ou en USB, ça évite de bricker bêtement son DS
(ce serait néanmoins réparable avec l’interface série, mais c’est embêtant)

Si le boot réseau fonctionne bien avec les nouveaux paramètres, vous pouvez le fixer définitivement :

bootcmd=run bootcmd_net

Voilà, c’est tout !

PS : ah si, un petit truc.
Un bench que j’ai fait pour comparer les performances disque du DockStar en NFSv2, NFSv3 100Mbps puis Gigabit, ainsi qu’avec une clé USB.
(pour la clé USB, chiffres de azrael24 sur HFR, merci )
Benchmark Bonnie++, pas de procédure rigoureuse et donc aucune valeur scientifique, c’est purement indicatif mais assez cohérent.

Depuis quelques jours, plusieurs forums GNU/Linux s’enflamment pour une petite bestiole toute de blanc vêtue : le Seagate Dockstar.

Je ne vais pas le présenter en détails, d’autres l’ont fait mieux que moi, je vous renvoie donc à l’excellent article du blog de Galipe.

Nerd devant l’éternel, j’ai évidemment craqué pour la chose (je vais même en recevoir un deuxième dans les prochains jours)
J’ai commencé à le bidouiller, en installant Debian dessus avec la méthode de Jeff Doozan, puis Plugbox (un fork d’Arch Linux dédié aux « plug computers » ARM).

Mais j’étais loin d’être satisfait de ces installations : en effet, elles se font avec une clé USB branchée sur le Dockstar, afin de contenir le système de fichiers.
Non seulement je trouvais un peu bête de condamner un port USB, mais la méthode était également loin d’être fiable : problèmes de « cold-boot », boot qui ne se fait pas sans qu’on sache pourquoi, un peu la galère en définitive …

Avant même de recevoir la bête, j’avais dans ma tête l’idée de la faire booter sur le réseau : c’est idéal, cette machine est constamment branchée, ça laisse tous les ports USB libres et ça ne consomme rien de plus

Aujourd’hui, excédé par un énième foirage de boot par USB, j’ai décidé de creuser.
Une méthode avait déjà été publiée pour les SheevaPlug, extrêmement semblables : http://www.plugcomputer.org/plugwiki/index.php/Setting_up_TFTP_and_NFS

L’idée est de :

• demander à uBoot (le bootloader du Dockstar) de charger un kernel Linux par TFTP
• booter ce kernel en lui demandant de démarrer sur un partage NFS

Ayant plusieurs machines bootant sur le réseau par PXE, j’avais déjà des serveurs TFTP et NFS fonctionnels pour cet usage (je ne détaillerai pas non plus de ce côté, le web est rempli de documentation là-dessus), il ne me restait plus qu’à m’y mettre pour le Dockstar.

Après quelques tâtonnements (moins que je ne pensais), voici une procédure qui fonctionne au poil.
Je n’ai pas inventé grand chose, quasiment tout vient de la méthode pour SheevaPlug que j’ai linkée au dessus.

Commençons.

Les choses peuvent dépendre d’où vous en êtes dans le bidouillage du Dockstar, mais il suffit que vous ayez un accès SSH à la bestiole pour pouvoir commencer.

Nous allons débuter par l’installation d’un uBoot correct.

Installer un bon uBoot

Cette étape est facultative si vous avez déjà installé un uBoot alternatif pour pouvoir booter sur USB, mais cet uBoot-là est normalement meilleur.
(et c’est réversible)

Suivez les explications claires et détaillées de Jeff Doozan.

Créer l’arborescence d’un système Plugbox sur le serveur NFS

J’ai choisi d’utiliser Plugbox pour une raison simple : c’est une Arch Linux pour plug-computers, et compilée pour le CPU des SheevaPlug/Dockstar

Sur votre serveur, placez-vous donc dans un répertoire vide partagé par NFS, et exécutez les commandes suivantes en root :

wget http://plugapps.com/os/PlugboxLinux-1.0.1.tar.gz
wget http://sheeva.with-linux.com/sheeva/2.6.33/sheeva-2.6.33-Modules.tar.gz
tar -xzvf PlugboxLinux-1.0.1.tar.gz # This will take a long time
wget -O boot/uImage http://sheeva.with-linux.com/sheeva/2.6.33/sheeva-2.6.33-uImage
tar -xzvf sheeva-2.6.33-Modules.tar.gz
rm PlugboxLinux-1.0.1.tar.gz
rm sheeva-2.6.33-Modules.tar.gz

Elles sont issues du guide d’installation de Plugbox, disponible ici.
Vous obtiendrez un répertoire contenant l’arborescence complète de votre système Plugbox.
Notez précisément le chemin local complet vers celui-ci.

Placer l’image du kernel sur le serveur TFTP

Cette image est le fichier /boot/uImage du système que vous venez de créer.
Copiez-la dans le répertoire partagé par votre serveur TFTP.

Configurer uBoot soigneusement

La configuration de uBoot se fait grâce à l’utilitaire blparam, que l’on peut se procurer ici sous forme d’un binaire précompilé et exécutable directement depuis un système Pogoplug (celui d’origine sur le Dockstar), Debian ou Plugbox.

Ce binaire est téléchargeable à cette adresse : http://plugapps.com/os/pogoplug/uboot/blparam

Exécutez-le depuis votre Dockstar (dans le répertoire /tmp pour ne pas avoir à écrire sur la NAND, et n’oubliez pas le petit chmod +x qui va bien), vous allez obtenir la liste des paramètres actuels de votre Dockstar.

Par contre, il peut aussi servir à modifier ces paramètres : pour cela il faut l’exécuter de cette manière :

#./blparam 'paramètre=valeur'

On peut ainsi modifier les paramètres prédéfinis, mais également en rajouter et même en supprimer (en assignant une valeur nulle au paramètre).

Voici les paramètres à rajouter/modifier :

bootcmd_net=tftpboot 0x2000000 $(image_name);setenv bootargs $(console) $(bootargs_root2) nfsroot=$(serverip):$(rootpath2) ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvNetConfig) $(mvPhoneConfig); bootm 0x2000000;
bootcmd3=setenv bootcmd run bootcmd2; saveenv; run bootcmd_net
image_name=<nom que vous avez donné à l'image kernel dans votre serveur TFTP>
bootargs_root2=root=/dev/nfs rw
serverip=<IP de votre serveur NFS/TFTP>
rootpath2=<chemin local complet jusqu'à votre système de fichiers Plugbox sur le serveur NFS : /var/blabla/... ou autre>
ipaddr=<IP que vous voulez donner à votre Dockstar>
bootargs_end=:::DB88FXX81:eth0:none
mvNetConfig=mv_net_config=(<adresse MAC du Dockstar, chaque valeur séparée par des : >,0:1:2:3),mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
arcNumber=2097
mainlineLinux=yes

Passez-les un à un via blparam.

Pour référence, voici la liste complète des paramètres du mien : http://ledek.free.fr/dl/blparam

(si vous êtes observateur, vous remarquerez que mon serveur TFTP et mon serveur NFS sont sur la même machine ; si les vôtres sont sur des machines différentes, il faudra séparer serverip en 2 paramètres distincts – pas difficile)

Enfin, nous allons passer à la dernière valeur, la plus importante : bootcmd.

Que j’explique un peu : dans les paramètres, j’ai fait en sorte de ne rien toucher d’autre, ce qui fait que pour l’instant, même avec toutes ces modifications, le Dockstar fonctionnera exactement comme avant.
Tout dépendra de ce que vous donnerez comme valeur à bootcmd.

Commencez par fixer :

bootcmd=run bootcmd3

Puis redémarrez.
Le Dockstar tentera de booter via TFTP/NFS, et si tout va bien vous pourrez vous logger sur votre nouveau système.

Mais quoi qu’il arrive, le boot suivant se fera sur la NAND, vous arriverez sur Pogoplug.
J’ai fait cela pour une raison très simple : si vous vous êtes trompé dans votre configuration et que le boot réseau échoue, cela va vous permettre de la corriger. (rebootez manuellement le Dockstar afin de revenir sur Pogoplug)
Si cela n’avait pas été le cas, il aurait été impossible de récupérer le Dockstar sans câble série.

Donc, si le boot réseau s’est bien déroulé la première fois, vous pouvez maintenant fixer définitivement le boot réseau :

bootcmd=run bootcmd_net

Désormais, le Dockstar bootera systématiquement sur le réseau avec les paramètres que vous avez fixés.

Inutile de préciser que toute cette étape est très sensible pour la santé de votre matériel, vérifiez à 2,3,4 fois que vous n’avez pas fait d’erreur.
Essayez également de comprendre ce que vous faites, une coquille de ma part est toujours possible, même si je me corrige.
Je ne pourrais être tenu responsable, blablabla…

Et maintenant,

Enjoy

Quelques liens utiles :
Le topic sur HFR, les fous du Dockstar y sont rassemblés
Les photos de mon Dockstar.
Installer Debian pour Dockstar sur clé USB, méthode de Jeff Doozan.

J’ai craqué, je me suis décidé à rooter mon téléphone

Pour plusieurs raisons :

• pouvoir utiliser les fonctions interdites sans root, par exemple la LED comme lampe de poche, les screenshots, …
• pouvoir changer de rom dans tous les sens, sans être limité à uniquement upgrader en suivant les ROMs officielles.
• et donc, pouvoir utiliser les ROMs alternatives, malheureusement pas encore très nombreuses sur Legend

Premier soucis, mon téléphone était en ROM 1.32 SFR, ensuite upgradé en 2.03 HTC.
Or, la faille permettant de rooter le Legend n’est présente que jusqu’au firmware 1.31, et avec un firmware HTC officiel, il est normalement impossible de downgrader à un firmware antérieur.

Jusqu’à il y a quelques semaines, les utilisateurs dans mon cas étaient bloqués.

Mais la situation a basculé lorsque sur le forum xda-developpers, wag3slav3 a fini par trouver un moyen de forcer le downgrade du firmware

Le principe est relativement simple (même si la mise en oeuvre est loin d’être triviale) : truquer le numéro de version du firmware, afin que l’utilitaire de flash HTC pense que le Legend ait un firmware 1.0, et autorise donc un vrai-faux upgrade vers n’importe quel firmware (dont le 1.31)

Et cela fonctionne, que l’on soit en 1.32, 2.02 ou 2.03.

Je me suis donc lancé dans la procédure décrite sur le topic, avec un succès complet :

• truquage réussi du numéro de version de mon Legend en 2.03
• flash réussi vers le vieux 1.31 HTC

Ensuite, on peut passer au root, j’ai suivi cette procédure, elle s’est terminée sans aucun problème, je me suis retrouvé avec un Legend en 1.31 avec possibilité d’accéder aux permissions root

Enfin, il ne restait plus qu’à choisir la ROM sur laquelle je voulais tourner, désormais plus aucune restriction, on peut choisir des roms quasi-stock (identiques aux officielles, mais permettant de conserver le root) ou des roms plus lourdement modifiées.

Dans un premier temps, je voulais simplement retrouver ma 2.03 tout en gardant le root et tous ses avantages, je me suis donc naturellement orienté vers la « Almost Stock Legend HTC WWE 2.03.405.3″ de pogo1975.

Après flash via le Recovery (désormais accessible), j’ai donc fini avec une ROM quasi-conforme à l’originale, à l’exception du root et de busybox pour trifouiller le shell de son Legend

Pour l’instant ça me convient très bien, en attendant de voir ce qui sortira quand HTC aura adapté Froyo sur le Legend, ainsi que les évolutions de CyanogenMod, qui n’est pas encore totalement stabilisé sur ce téléphone, mais ça avance
(dans l’absolu, c’est la ROM vers laquelle je voudrais aller)

Ça fait bien plaisir de ne plus être bridé dans l’utilisation de son matériel.
Néanmoins, attention aux problèmes de sécurité que cela engendre : autoriser une appli à tourner en root, ça lui ouvre des possibilités pas très saines, il est donc important de bien la choisir.
(par exemple opter en priorité pour des applis libres)

Je l’avais soufflé discrètement à la fin de mon dernier billet, j’ai depuis quelques semaines un mobile Android

Il s’agit d’un HTC Legend, joli petit terminal en alu unibody et tournant sous Android 2.1, agrémenté de l’interface HTC Sense.

Je n’ai pas grand chose à dire de plus, la communauté de développeurs autour de ce modèle est pour l’instant assez réduite, c’est pourquoi je ne l’ai pas encore vraiment bidouillé, je me suis contenté de le flasher avec une ROM nue de chez HTC (2.03) afin d’éliminer la personnalisation SFR.

À l’avenir, je le rooterai sûrement afin de le flasher vers une rom alternative telle que CyanogenMod, quand celle-ci sera réellement stable sur le Legend.

Mais tel quel, il me satisfait pour l’instant pleinement
(c’est notamment le pied pour contribuer à OpenStreetMap avec mes traces GPS :p)

Le seul petit soucis, c’est qu’il n’a malheureusement pas été dans le sens d’une dé-googleisation des services que j’utilise, loin de là …

Ça faisait longtemps que je connaissais ce projet de cartographie libre mais jusqu’à présent, je n’avais éprouvé ni l’envie ni l’opportunité d’y participer.

OpenStreetMap, pour schématiser très simplement, c’est un concurrent de Google Maps, mais avec des données libres (plus précisément, sous licence CC-BY-SA) qui sont produites directement par des contributeurs bénévoles (vous, moi, …) sur le même modèle que Wikipedia.

L’idée sous-jacente est que la géographie/cartographie (au même titre que la connaissance pour Wikipedia) doit appartenir à tout le monde, et non être confisquée par des sociétés détenant des fonds de carte et les monnayant pour l’utilisation que l’on peut en faire (basiquement : se déplacer sur notre planète, illustrer un parcours, un lieu).

Bref, avec un GPS sachant tracer un parcours et un logiciel multi-plateformes (JOSM, en Java), on peut soi-même se lancer à cartographier sa rue si elle est absente de la carte.
Et on peut obtenir une qualité réellement impressionnante, surpassant celle des concurrents propriétaires, en témoigne l’article récent de Framablog à propos du Zoo de Berlin.

C’est d’ailleurs cet article qui m’a décidé, voyant que mon village de cambrousse était totalement absent de la carte, disposant d’un GPS de running Garmin Forerunner 201 et me baladant par chez moi en vélo ou en footing, je me suis attelé à la tâche.

La méthode est simple, on suit un parcours avec son GPS qui enregistre le tracé, de retour à la maison, on l’importe dans JOSM et on s’en sert de calque pour créer/complèter/préciser les routes/rues/chemins que l’on a parcouru. C’est très simple, il faut juste 5 minutes pour se familiariser avec le logiciel.
Quelques jours plus tard, j’avais terminé de cartographier mon village, et la qualité est bien supérieure à celle de Google : tout est plus précis, correct, complet et correctement classifié (alors que chez Google, route, chemin, tout est mélangé).

À l’origine, seuls étaient présents la rue des Églantines et les deux plus grands axes en jaune, mais mal tracés (de simples lignes droites). À comparer avec la carte de Google Maps, beaucoup moins précise et avec beaucoup d’erreurs.

On se rend immédiatement compte de l’intérêt de faire faire ce boulot par des gens qui connaissent leur lieu d’habitation, une qualité parfaite est bien plus rapide à obtenir

De la même manière, la modification d’une route sera répercutée sur OSM beaucoup plus rapidement que sur Google Maps.

Il est à noter que la création manuelle par les contributeurs n’est pas la seule source de données géographiques pour OpenStreetMap : certains organismes publics ont mis à disposition des données (pas très précises) couvrant des territoires entier et permettant de combler les vides, c’est pour cela que même dans les coins où personne n’a contribué, on peut trouver les routes principales et les forêts par exemple.

Certes, il reste beaucoup de défauts, la carte ne peut pas encore être qualifiée de complète, dans les endroits faiblement peuplés il y a encore du travail à faire.
Mais dans les grandes villes et les endroits où quelqu’un s’est décidé à faire le boulot, on pourrait dès à présent tout à fait l’utiliser pour alimenter un système de navigation GPS.

Et à plus long terme, c’est un projet qui par nature ne peut dépérir : la géographie ne change pas, ou très peu, et le travail réalisé aujourd’hui ne sera jamais périmé par les évolutions techniques (comme cela peut être le cas pour des logiciels classiques), ce qui est cartographié aujourd’hui n’est plus à faire et restera

Donc n’hésitez pas, venez « refaire le monde », se balader tout en contribuant au libre, c’est plutôt sympa

Le seul paramètre bloquant pourra être de ne pas disposer de GPS adéquat, mais de plus en plus de smartphones sont équipés d’un récepteur GPS, et avec la petite application qui va bien (par exemple, My Tracks pour Android) on peut faire du tracking de manière très satisfaisante. (j’y reviendrais dans un futur billet, car oui, j’ai depuis peu une de ces bestioles )

Ça fait longtemps qu’ils me chauffent les oreilles.

J’ai souvent remarqué chez Phoronix, site très connu dans les milieux linuxiens, parce qu’ils ont été les premiers à vraiment parler de hardware et réaliser des benchs sous OS libres, une propension à bacler leurs articles.

Certes, on peut leur concéder plein de vertus, en premier celle de parler des OS libres avec un certain pragmatisme et tester leurs performances dans le cadre d’une utilisation réelle.
De la même manière, ils ont été les premiers à produire des comparatifs de perfs Windows/Linux/OSX, qui était une chose qu’on attendait depuis longtemps et qui permet de clouer le bec à pas mal de trolls.
(en résumé : non Linux n’est pas à la ramasse en gaming, et oui Windows offre encore de meilleures performances dans le domaine)

Cela a été permis par leur gros projet de ces dernières années : la Phoronix Test Suite : un ensemble de scripts permettant d’automatiser le lancement de benchmarks basés sur des références en matière de logiciel. (ça va de l’appli de bases de données au bench disque, en passant par les démos de jeux vidéo, …).
Au fur et à mesure de son évolution, cette suite est devenue une certaine référence dans le domaine, et a ouvert la voie à du bench massif inter-OS.

Le problème est venu de ce que Phoronix en a fait dans son approche rédactionnelle : du bench a tout va, des protocoles élaborés à la va-vite, des comparatifs inutiles.

Exemple :
Un comparatif de cartes graphiques : chouette se dira-t-on, on va enfin savoir quoi choisir, ATI ou Nvidia ?
Ben non, on n’aura droit qu’à ATI vs ATI ou Nvidia vs Nvidia. (ici, ou encore là, et bien d’autres.)

Chaque sortie de matos est l’occasion de nous infliger une dizaine de pages de résultats de leur PTS, sous forme de graphiques maronnasses illisibles.

Que leur contenu ait peu d’intérêt, c’est dommage pour eux mais passe encore.

Mais quand on se met en tête de réaliser un bench Arch Linux VS Ubuntu et de relever ceci :

With World of Padman was the first test where there is a large difference between Arch and Ubuntu. However, the reason for this is likely that Arch Linux does not use Compiz by default when an accelerated OpenGL driver is available, which is in contrast to Ubuntu. This is simply due to a difference in how each OS is by default. If Arch Linux has Compiz running or Metacity was running instead of Compiz on Ubuntu, we would have likely seen similar numbers.

On se demande ce qui leur passe par la tête : Arch n’a pas plus Compiz que Gnome ou même Xorg par défaut, pourtant pour ces derniers ils les ont bien installés.
Donc ces messieurs, relevant sciemment que leur comparatif est biaisé, continuent tout de même leurs benchs, au désavantage évident de Ubuntu, pour pouvoir tout de même poster leur super article.
Je m’interroge encore sur la signification de « by default » concernant Arch Linux, on peut soupçonner soit de l’idiotie, soit un léger foutage de gueule.

Et alors quand les compères se mettent dans la tête de réaliser un bench d’une pré-pré-pré-pré-pré-version (donc un stade qu’on pourrait qualifier de « alpha »)du kernel Linux, puis de titrer :  « The hudge disaster within the Linux 2.6.35 kernel », là plus aucun doute : ils sont abrutis.
Pas besoin d’argumenter plus, c’est éloquent.
Pour illustrer, c’est un peu comme se procurer le tout premier prototype de la prochaine Laguna au tout début de son développement, se balader sur route ouverte avec et assassiner Renault parce que leur future bagnole roule mal.

D’ailleurs je suis loin d’être le seul à le relever :
http://www.h-online.com/open/features/Kernel-Log-Linux-2-6-35-taking-shape-1012850.html
http://thread.gmane.org/gmane.linux.kernel/993003/focus=993018

Dommage, ce site était une bonne idée, mais à force de faire du remplissage, au bout d’un moment ça commence à se voir qu’on prend les gens pour des cons.

Les connaisseurs et habitués des conférences de Benjamin Bayart sont sûrement déjà tous informés et les ont déjà sûrement visionnées, mais il me paraît important de passer le mot, si cela peut donner l’envie à une seule personne et bien ce sera toujours ça de gagné.

Benjamin Bayart, donc, le trublion du Minitel 2.0, a récemment présenté une série de trois conférences au sein des locaux de Sciences Po, afin d’expliquer Internet (à un public pas nécessairement informaticien) en revenant sur ses fondements techniques, les applications que l’on peut en faire, puis d’en dégager des enjeux politiques et sociaux.

C’est utile, pédagogique, monstrueusement bien expliqué, et comme toujours avec monsieur Benjamin, on ne s’ennuie pas une seconde.
Cela vous permettra de comprendre pourquoi Internet est aujourd’hui menacé et l’importance de ne pas le prendre à la légère.

La première partie est vraiment accessible aux néophytes, et ne fera pas de mal aux experts, il est en fait important de bien visionner les trois dans l’ordre.

Pas grand chose de plus à dire, je remercie B. Bayart pour son travail et encourage très très fortement les personnes qui ne l’ont pas fait d’aller se procurer lesdites vidéos.

Elles sont disponibles par divers moyens et dans un format libre, par ici.

Les retardataires pourront commencer avec sa célèbre conférence précédente « Internet ou Minitel 2.0″, disponible là.

Voilà voilà.

Liens relatifs :
La page Wikipédia sur Benjamin Bayart

Depuis Juin dernier, je n’avais plus de machine desktop principale : en effet, suite au manque de place pour celle-ci dans notre maison en travaux et à la nécessité d’un nouveau serveur, je l’avais reconvertie en tant que nouveau serveur@home.
Cette machine ronronne toujours aussi paisiblement dans son rôle qu’elle assume très bien, et pour sûrement encore longtemps.

C’est mon vieillissant Dell Inspiron 6000 qui a donc assumé tant bien que mal ce rôle de machine de bureau pendant ces quelques mois.

Ayant terminé les travaux de mon bureau, et également économisé quelques sous, je me suis mis en quête de l’acquisition de ma nouvelle machine de guerre.
(il me fallait uniquement carte mère, CPU et RAM, j’ai gardé les restes de mon ancienne config qui étaient inutiles pour le serveur)

Le choix

Exigences :

-pas trop cher, moins de 300€ pour les 3 pièces.
-de la patate niveau CPU, parce que c’est bien agréable une machine qui torche.
-une certaine perennité (évolutivité, …)
-compatibilité Linux.
-4Go de ram minimum.

Mes contraintes budgétaires m’ont rapidement orienté vers AMD au lieu d’Intel, ce qui n’avait rien pour me déplaire, j’aime bien AMD niveau CPU (j’ai eu les 2, pas de préférence particulière) et ayant à ce moment uniquement du Intel à la maison (portable, netbook, serveur), ça me permettait de diversifier un peu.
Actuellement, en dessous de 150€, pas de débat possible, c’est AMD qui tient les rênes du rapport qualité/prix.

Un quad-core aurait été parfait, comble du bonheur, AMD en propose un à moins de 100€ : l’Athlon II X4 620.
Grosso modo c’est un Phenom II X4 sans cache L3, et cadencé à 2.6Ghz.
Validé.

La carte mère maintenant.
Je voulais un chipset AMD (surtout pas de Nvidia, en chipsets c’est à chier), de la DDR3 (autant partir sur du moderne) donc un socket AM3, un southbridge >=SB700 (le SB600 a toujours été une horreur de manière générale et en particulier sous Linux) et toutes les fonctions de base dans une carte ATX complète mais pas excessive.
J’ai donc choisi la Gigabyte GA-MA770T-UD3P, qui remplissait toutes ces exigences.

Et enfin la ram, je voulais simplement de la qualité à pas cher, ce sera de la G-Skill PC3-12800NQ en 2 barettes de 2Go.

Je passe donc commande de tout ça le 19 Janvier auprès de Materiel.net, avec 2-3 babioles en plus dans la commande.

La réception, la déception

Quelques jours plus tard, le Graal arrive chez moi en Colissimo et je m’empresse de monter tout ça.

Si tout semble bien se passer au début, je remarque des instabilités et des erreurs au Memtest.
Persuadé d’être tombé sur un kit mémoire défectueux, je renvoie ledit kit à Materiel.net, qui me l’échangent sans problème en confirmant ma version.

Nouveau kit reçu, mêmes problèmes
Les erreurs à Memtest étant désormais aléatoires …

Je contacte donc à nouveau Materiel.net.

S’ensuivent 15 jours d’échanges de mails avec le SAV, puis un retour de tout le matériel.
Au terme d’un mois commençant par plus d’une semaine de silence, suivie de diagnostics contradictoires de leur part (un coup ils me confirment que le matos a un problème, un coup que tout va bien … si ça c’est pas la définition d’un problème aléatoire …), ils me répondent finalement que le problème est inexistant chez eux et que le matériel va m’être renvoyé tel quel.

En gueulant assez fort, finalement ils décident, « à titre exceptionnel » et vu la mauvaise communication de leur part, de m’échanger le kit de barettes contre un autre, équivalent en gamme mais différent en caractéristiques : une paire de G.Skill PC3-10600 CAS7 ECO.

J’y perd en fréquence mais j’y gagne en qualité et timings, pourquoi pas.

Finalement

Je reçois donc mon matériel (nous sommes tout de même le 26 mars, soit deux mois après ma commande initiale !), avec les nouvelles barettes et remonte tout ça.

Déjà, plus de problème de mémoire
(comme quoi …)

Un seul problème récurrent continuait à m’empoisonner la vie … au boot de Arch Linux (mais également sous Ubuntu), le système faisait des sortes de « pauses », et continuait après appui d’une touche sur le clavier, problème très étrange. (et qui ne se limitait pas à ça, il entrainaît aussi le mauvais démarrage de certains services et des dysfonctionnements de ma souris)

Mon bug était en tous points similaire à celui-ci.

Après de longues investigations sous Google, j’ai déterminé qu’il était lié à un bug kernel concernant HPET et C1E dans le cadre d’une configuration AMD.
Et finalement, en désactivant C1E, plus aucun problème

C’est certes dommage de désactiver une fonction d’économie d’énergie, mais je n’avais pas vraiment le choix, et dans le cadre d’une configuration desktop, cela ne me dérange vraiment pas.

Enfin une configuration fonctionnelle … et qui pootre !

Oh que oui.

Comme à mon habitude, j’y ai bien sûr posé une petite Arch Linux x86_64 qui s’y sent très bien
En usage desktop c’est vraiment très confortable et réactif, j’apprécie vraiment cette configuration.
Pour le reste, tout fonctionne parfaitement : son, réseau, mise en veille, Powernow…

Voulant grapiller encore quelques perfs, je me suis mis en tête d’overclocker un peu le CPU, je suis arrivé à le monter de 2.6Ghz à 3.25Ghz, soit 25% d’augmentation de fréquence, en restant à la tension d’origine, ce qui me satisfait pleinement.

Le CPU reste très frais (~28 degrés en idle, jamais plus de 45 en burn) et demande très peu de ventilation, la régulation laissant le ventilateur tourner très faiblement, tout bon pour mes oreilles .

Bizarrement, mon Core 2 Duo E4400 chauffait beaucoup plus et devait être ventilé bien plus fortement.

Voici la configuration au complet :

AMD Athlon II X4 620 @ 3.25Ghz
Gigabyte GA-MA770T-UD3P
4Go G.Skill PC3-10600 CAS7 ECO
XFX Geforce 7900GS 256Mo
M-Audio Revolution 5.1
Samsung Spinpoint F1 320Go
Seasonic S12 500W
OCZ Vendetta
Antec P180

En périphériques, j’ai un bi-écran Samsung 205BW 20″ + Bluesky 17″, toujours mon clavier Apple Aluminum et ma Logitech MX Revolution.

Pour les amateurs, les infos de rigueur

[dek@grnx ~]$ uname -a
Linux grnx 2.6.33-ARCH #1 SMP PREEMPT Sun Apr 4 10:27:30 CEST 2010 x86_64 AMD Athlon(tm) II X4 620 Processor AuthenticAMD GNU/Linux

[dek@grnx ~]$ cat /proc/cpuinfo
processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 5
model name    : AMD Athlon(tm) II X4 620 Processor
stepping    : 2
cpu MHz        : 3249.826
cache size    : 512 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 5
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips    : 6502.46
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

Un petit lspci :

[dek@grnx ~]$ lspci -nn
00:00.0 Host bridge [0600]: ATI Technologies Inc RX780/RX790 Chipset Host Bridge [1002:5957]
00:02.0 PCI bridge [0604]: ATI Technologies Inc RD790 PCI to PCI bridge (external gfx0 port A) [1002:5978]
00:0a.0 PCI bridge [0604]: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port F) [1002:597f]
00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] [1002:4391]
00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 3c)
00:14.1 IDE interface [0101]: ATI Technologies Inc SB700/SB800 IDE Controller [1002:439c]
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384]
00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller [1002:4399]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map [1022:1201]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203]
00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control [1022:1204]
01:00.0 VGA compatible controller [0300]: nVidia Corporation G71 [GeForce 7900 GS] [10de:0292] (rev a1)
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)
03:06.0 Multimedia audio controller [0401]: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller [1412:1724] (rev 01)
03:0e.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024]

Le dmesg

Voilà

Nic0 a repris l’info hier sur son blog, le développement de Yaourt a repris et de fort belle manière : il a abouti à la sortie le 26 Mars d’une version 0.9.3.

Si en soi cette nouvelle n’est pas transcendante, c’est sans compter sur la grosse nouveauté de cette release : la Vitesse !

Oui je l’écris avec un grand V, car vu le gain, c’est mérité.

Je ne vais pas répéter les tenants et aboutissants, je vous renvoie au lien du blog de Nic0 pour ça, juste décrire ma rapide expérience perso : là ou depuis longtemps, la réponse de Yaourt à une requête trainait en longueur, de manière très irritante, désormais ça trace !

Tuxce et Wain ont ainsi tordu le coup des oiseaux de mauvaise augure qui voyaient Yaourt déjà mort, et réaffirmé son statut d’outil de premier plan pour Arch.

Pour cela je les remercie, je suis accro à Yaourt depuis mes débuts sous Arch, et les alternatives actuellement en cours de développement étaient bien loin d’atteindre sa qualité et sa richesse.

(cet article est aussi une manière d’annoncer que les articles devraient revenir à une fréquence plus décente, car pas d’article en 3 mois, j’ai un peu honte … et les raisons d’écrire ne manquent pas pourtant )

Allan McRae l’a annoncé hier, la création d’un nouveau port de Arch, vers rien de moins que le Hurd, le microkernel légendaire et vaporeux de RMS et ses amis

D’après l’article, il reste encore du boulot avant que ça soit bootable, encore plus avant que ça ne soit utilisable ou même utile, mais n’empêche que ça pootre très fortement, rien que pour le côté nerd/roots/l33t/barbu. (et j’ai tendance à adorer les projets fous)

Ça devrait également quelque peu stimuler l’activité autour de Hurd (toutes proportions gardées, le port Debian étant sûrement plus prolifique en termes de contribution au développement), et qui sait ?  Peut-être un jour l’aurons-nous en standard dans nos distros
(oui Noël est passé, mais on peut bien rêver, non ?)

J’en profite pour souhaiter (en retard) une très bonne heureuse année à vous tous et à vos manchots (et même à vos fenêtres, j’ai pris la résolution d’être compatissant cette année)

Autre résolution : + d’articles sur le blog cette année.  Oui, personne n’y croit, mais je vous le promets. Si si.
Dernière résolution : 1920×1200. Ha ha ha. …

Le site officiel de Arch Hurd, port de Arch Linux vers Hurd.
Le Hurd d’après Wikipedia.
La page officielle de Hurd sur le site de la FSF.
Le port de Debian vers Hurd.

PS : dernier petit cadeau, une longue interview de l’équipe de dév Arch Linux. Miam.