Ma vie rêvée

Ça commence à devenir une habitude mais je change de distribution une fois par an à l'occasion de la sortie des versions spring de mandriva. Cette année, c'était donc la version 2009.1 et ma foi, c'est un très bon cru. Petit résumé.

Installation

Quand on ne fait pas l'idiot et qu'on vérifie les médias d'installation, ça marche plutôt bien. J'avais initialement prévu d'utiliser le DVD free pour faire une mise à jour mais mon DVD était un peu corrompu et je me suis retrouvé avec des erreurs sur quelques paquets mineurs comme dash-static, le noyau et mkinitrd, ce qui m'a posé quelques problèmes.

Au final, j'ai téléchargé et gravé le CD dual-arch depuis la machine de mon épouse et j'ai effacé ma partition / ce qui m'a pris quelques minutes.

Comme toujours depuis quelques années, mon matériel a été directement reconnu et configuré sans aucun problème et sans option particulière.

J'ai ensuite monté l'iso de mon DVD en loopback pour installer une partie de ce que j'avais besoin. Tout ça a été plié en moins d'une heure.

Configuration

Pas grand chose à dire, j'ai une sblive et pas de gros besoins donc j'ai encore désactivé pulseaudio, il suffit de cocher une case à l'installation et c'est fait.

Tout le reste a été parfaitement détecté et configuré, à l'exception de mon bi-écran étant donné que le pilote nv ne le gère pas. J'aurais pu utiliser Nouveau prépackagé mais j'ai préféré l'installer par moi-même par la suite.

Xfce 4.6 s'est installé comme un charme, il faut juste penser à supprimer la conf dans le dossier personnel sinon ça donne de drôle de résultat.

Conclusion

Cette version est presque ennuyeuse tellement il n'y a aucun défi à l'installer ou à la configurer. A recommander sans état d'âme.

Depuis quelques semaines, le support des codecs realvideo 3.0 et 4.0 ( http://fr.wikipedia.org/wiki/RealVideo ) a été complété et activé dans ffmpeg et donc dans tous les lecteurs qui l'utilisent (donc mplayer). Il n'est donc plus nécessaire d'utiliser les codecs binaires de chez Real. Encore un maillon propriétaire de moins sur mon système :).

Mon fils a un RGO, le médecin lui a donc prescrit de l'oméprazole (Mopral*) et il faut donc trouver le moyen de lui faire ingurgiter. Voilà quelques conseils.

Il est assez fréquent de rencontrer sur les forums de discussion des intervenants s'étonnant de la quantité affolante de mémoire consommée par leur système tournant sous Linux.

La plupart du temps, cet étonnement vient d'une méconnaissance de la gestion de la mémoire par ledit système. Je vais donc tenter, assez grossièrement, d'expliquer comment ça marche. Il faut comprendre que de la mémoire inutilisé est de la mémoire inutile. C'est à dire que tant qu'il peut (c'est à dire tant qu'une application n'en a pas besoin), le système va essayer d'utiliser la mémoire pour faire quelque chose d'utile (un cache disque par exemple). Une partie de la mémoire est consommée mais reste disponible dès qu'un programme en a besoin.
Certains outils (comme top) vont par défaut afficher la mémoire consommée et par les applications et par le système, d'où l'étonnement ci-dessus.

Prenons, un exemple pour bien comprendre. Au moment où j'écris, J'ai sur ma machine 2Go de RAM physique et quelques programmes ouverts.

Voici le résultat de top :

Mem:   1997536k total,  1624688k used,   372848k free,   245772k buffers
Swap:   843372k total,        0k used,   843372k free,   501948k cached

D'après lui, 1,6Go de mémoire est occupé (arrgh), 350Mo est libre, 250Mo est dans les tampons et 500Mo est de la mémoire cache (je passe sous silence le swap qui n'est pas utilisé).

Si on fait la somme de ses valeurs, on arrive à bien plus que 2Go, ce qui est normal puisqu'en réalité, les tampons et les caches sont à déduire de la mémoire utilisée. Ce que fait automatiquement l'outil free :

             total       used       free     shared    buffers     cached
Mem:          1950       1586        364          0        240        490
-/+ buffers/cache:        856       1094

cette fois-ci la mémoire consommée est redescendue à 856Mo. Ce qui est déjà plus raisonnable mais quand même toujours important.

En réalité, la mémoire réellement consommée par les programmes n'est pas si importante. L'outil free ne prend pas en compte tous les caches existant et en particulier ceux se trouvant en espace noyau.

Pour cela, on peut utiliser l'outil slabtop (classé par consommation mémoire) :

 Active / Total Objects (% used)    : 1179886 / 1181585 (99.9%)
 Active / Total Slabs (% used)      : 131149 / 131149 (100.0%)
 Active / Total Caches (% used)     : 57 / 66 (86.4%)
 Active / Total Size (% used)       : 496560.55K / 496815.30K (99.9%)
 Minimum / Average / Maximum Object : 0.01K / 0.42K / 4.00K

 OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   

480555 480537  99%    0.75K  96111        5    384444K ext3_inode_cache
505153 505145  99%    0.20K  26587       19    106348K dentry
18669  18666  99%    0.55K   2667        7     10668K radix_tree_node
190051  90009  99%    0.10K   2309       39      9236K buffer_head
3105   3100  99%    0.77K    621        5      2484K shmem_inode_cache
37376  37282  99%    0.06K    584       64      2336K kmalloc-64
3794   3791  99%    0.55K    542        7      2168K inode_cache
7728   7703  99%    0.17K    336       23      1344K vm_area_struct
 916    912  99%    1.00K    229        4       916K kmalloc-1024
1326   1319  99%    0.59K    221        6       884K proc_inode_cache
0965  10965 100%    0.08K    215       51       860K sysfs_dir_cache
4389   4346  99%    0.19K    209       21       836K kmalloc-192
 368    344  93%    2.00K     92        4       736K kmalloc-2048
 172    167  97%    1.97K     43        4       344K task_struct
  96     93  96%    2.06K     32        3       256K sighand_cache
 286    275  96%    0.69K     26       11       208K sock_inode_cache

Ainsi, on voit que le cache des inodes (les références vers les fichiers) fait 384Mo, celui des noms de dossiers (dentry) fait 100Mo.

Il suffit alors de soustraire ces 2 valeurs pour arriver à quelques choses de plus réaliste en terme de mémoire occupée, ici autour de 380Mo.
On est bien loin des 1,6 Go initiaux, ouf ;).

Toutes ces données sont également directement disponible dans le fichier /proc/meminfo (regarder notamment la ligne Sreclaimable qui fait le total des caches récupérables dans le noyau)

Voilà, c'est fini pour cette courte explication du mythe de la consommation de mémoire avec Linux. N'hésiter pas à corriger ou compléter en commentaire, je suis loin d'être un expert sur le sujet.

PS : A noter que dans mon cas, mon pilote graphique se réserve une zone mémoire importante en RAM, sans pour autant l'utiliser constamment.
Elle n'en est pas moins considérée occupée par les différents outils et je n'ai pas trouvé comment la mettre en évidence.

Suite à un comportement très bizarre de mon hébergeur (pages persos free.fr), j'ai du me résoudre à déplacer ce blog. La nouvelle adresse est donc http://mjules.littleboboy.net/carnet.
Je vous invite à mettre à jour vos marques-pages et abonnements RSS/atom. Il y a une redirection vers le nouveau site mais il n'y a aucune garantie qu'elle persiste dans le temps :).

En attendant, un grand merci à mon nouvel hébergeur qui m'a gentiment fait une place ici :).

L'AFSSAPS vient de publier un rapport qui fait le point sur les ventes de médicaments aux officines et aux hopitaux (et donc par extension, qui parle de la consommation de ces mêmes médicaments) entre 1996 et 2006. Je l'ai juste parcouru en m'arrêtant sur quelques points précis mais il m'a semblé plutôt complet et bien organisé. Pas de révélation dedans, jsute des confirmations de choses dont on parle depuis un moment, notamment sur les gros postes de dépenses liés aux médicaments anti-génériques ou les médicaments récemment mis sur le marché (qui le sont fréquemment à des prix absolument ahurissants en regard de leur intérêt).

Ce rapport est disponible sur le site de l'AFSSAPS.

Je viens de mettre à jour mon script permettant de télécharger les vidéos dailymotion. La mise à jour concerne surtout la détection des contenus HD qui ne fonctionnait pas correctement. A priori, le h264 n'est plus utilisé et c'est on2 (vp6 pour la vidéo, mp3 pour l'audio) qui l'a remplacé.

Téléchargement

Tout comme il existe des scripts permettant de télécharger les vidéos de youtube ou metacafe, je suis tombé récemment sur un script qui fait la même chose avec dailymotion.

Dailymotion venant de modifier la façon de présenter les vidéos, j'ai complètement réécris le script pour qu'il fonctionne avec cette nouvelle version et accessoirement qu'il soit un peu plus simple à utiliser : dailymotion-dld.

L'utilisation en est assez simple :

dailymotion-dld url_de_la_page_qui_contient_le_film nom_du_fichier_destinataire

Le script fonctionne au 8 février 2008, il nécessite curl ou wget, ainsi que les outils de base de toute distribution : bash, mktemp, awk, sed et grep.

Ce script est placé dans le domaine public, vous êtes donc libre d'en faire ce que vous en voulez (oui, je sais, le vrai domaine public n'existe pas en France, si ça vous pose problème, considérez qu'il est sous licence CECILL-B).

Ce matin, j'ai enfin trouvé la force de surmonter ma pingrerie habituelle et j'ai mis à jour ma carte graphique (Geforce 5900 > 7600). Installation sans problème, Démarrage sans soucis majeur jusqu'au lancement de X et là. Scratch. X qui démarre plus. Chose assez surprenante vu qu'il démarrait plutôt bien précédemment et que mon pilote (Nouveau) gère toutes les cartes Nvidia depuis les TNT2.

Quelques investigations rapides montrent que le système de détection automatique du matériel de Mandriva (harddrake) a reconfiguré mon fichier. La config était bonne dans l'absolu mais avec un pilote qu'on récupère directement de l'arbre de développement plus un serveur X installé en parallèle du serveur de base et dans un emplacement pas très catholique, ça ne pouvait évidemment pas marcher.

Une poignée de minutes de modifications plus tard, le serveur X démarre mais l'affichage est lent comme la mort (genre pire que windows avec les pilotes VESA). Retour au fichier de conf, modification de quelques options sans résultat. Fouille minutieuse du fichier de log qui montre un message pas très normal :

(EE) EXA(0): driver's EXA version requirements (2.1) are incompatible with EXA version (2.0)

Bref, l'accélération du pilote est complètement dans les choux. Direction le chan IRC du projet Nouveau où on m'explique que c'est le même code pour mon ancienne carte et celle-ci et donc que ça ne devrait pas arriver etque ça doit être un problème de conf. Très sceptique, je vérifie tout de même et me rend compte que deux chemins de recherches des pilotes ont été inversés par rapport à l'ancienne configuration. Je les remets en place et là, TADA, tout fonctionne de nouveau avec une bonne accélération 2D (cf note).

Conclusion :

1. si vous avez une configuration différente de celle à laquelle s'attend l'outil de config, ça risque de mal se passer.
2. Ne soyez jamais trop sur de vous, et vérifiez deux fois avant de chercher un autre responsable

NOTE : Le pilote Nouveau fonctionne très bien en 2D et utilise directement le moteur 3D pour l'accélération 2D EXA. Malheureusement, l'implémentation de EXA dans les serveur X < 1.4.1 (pas encore sorti) est très lente sur certaines parties. Ce qui oblige à désactiver certaines opérations (option MigrationHeuristic "Greedy"), ça n'en reste pas moins beaucoup plus rapide que le pilote nv. Ces limitations sont corrigées dans le prochaine version du serveur X.