Un petit post pour vous faire découvrir un groupe de metal progressif/symphonique hongrois qui m'a particulièrement plu sur Jamendo récemment : Obsidian Shell.

Une voix féminine excellente, de bon gros riffs de guitare, de la double-pédale à foison et des sonorités électroniques qui rappellent un peu Blackstar Halo et parfois Nightwish, voilà qui rentre très précisément dans la catégorie de metal que j'apprécie tout particulièrement.

Quatre albums au compteur (et on espère d'autres en préparation) et une qualité qui se retrouve assez rarement sur une plateforme comme Jamendo (bon, même si je n'ai pas tout écouté, loin de là) Obsidian Shell est un groupe que vous devez écouter, au moins pour vous faire une idée.

Je vous recommande particulièrement l'album Angelic Asylum qui accompagnera avec merveille vos activités quotidiennes ( ^^ ) avec ses rythmes énergiques, ses sonorités éléctroniques et la voix de la chanteuse, douce et dégageant pourtant une certaine puissance qui décidément équilibre chaque piste avec bonheur. Certaines chansons sont en anglais, d'autres en hongrois (seule Starfall dans cet album) mais chacune apporte son caractère et sa fraîcheur aux titres.

En passant, n'hésitez pas à récupérer le lien RSS disponible dans la colonne de droite pour rester au courant ce qui se passe ici (promis, ça ne polluera pas vos flux, je ne poste qu'une à deux fois par mois ^^)

Si vous avez raté le début :

Usul II : le retour du fils de la vengeance (1ère partie)

Usul II : le retour du fils de la vengeance (2ème partie)

La migration matérielle était à présent terminée et le rodage se passait bien. Si bien que la machine a retrouvé deux jours plus tard son coin du placard (non sans un petit coup d'aspirateur au préalable). J'ai continué néanmoins à corriger ou adapter petit à petit la configuration logicielle suite à la montée en version de Debian.

Suite et fin de la série sur Usul II...

Ajustements et corrections : autofs à la rescousse

Le point qui me chagrinait le plus est qu'à chaque reboot depuis le passage à Wheezy, les montages réseaux (CIFS) définis jusque-là dans /etc/fstab bloquaient la séquence de boot car, apparemment, le réseau n'était pas encore disponible à ce moment-là. La seule manière de poursuivre le chargement était de presser S pour sauter le montage, puis une fois arrivé au shell, remonter les partages concernés avec un

# mount -a

Après une bonne phase de recherche sur le web, j'ai réalisé que ce que je faisais jusque-là fonctionnait plus par erreur qu'autre chose !

En effet, il est plutôt :

1. optimiste de penser que les partages réseaux définis dans /etc/fstab seront toujours accessibles au boot de la machine (si le NAS est éteint par exemple),

2. téméraire de les monter au boot sachant que si une erreur se produit (car, par exemple au hasard, le réseau n'est pas encore actif) c'est la séquence de boot entière qui sera suspendue jusqu'à l'action de l'utilisateur.

Les pistes que j'ai trouvées pour ce genre de cas m'ont dirigé vers autofs.

Autofs est un daemon qui va surveiller certains dossiers préalablement configurés et qui, à la première tentative d'accès, va monter de manière transparente la partition ou le partage réseau associé. Pour l'application à l'origine de ce premier accès, elle verra donc immédiatement le contenu de la cible du montage, même si celui-ci était démonté l'instant d'avant. Cela peut bien sûr occasionner un petit délai lors de l'accès déclenchant le montage, mais sans influer sur le déroulement de l'application.

Il ne s'agissait pas de la seule option possible pour ce cas de figure mais cela me semblait être la plus proche de ce que j'avais jusque-là, sachant que je ne tenais pas à dépendre d'un système basé sur FUSE par exemple.

Pour information, sur les distributions plus récentes utilisant de base systemd comme Archlinux (que j'utilise aussi quotidiennement), il est possible d'utiliser directement /etc/fstab en ajoutant simplement l'option "x-systemd.automount" pour arriver au même résultat. Si Systemd suscite encore aujourd'hui beaucoup de critiques négatives (de la part de passéistes intégristes barbus diront les mauvaises langues), j'avoue que certaines fonctionnalités intégrées sont parfois fort pratiques !

Mais revenons à Debian et son antique sysvinit. Un package éponyme est évidemment disponible pour autofs, on l'installera par la commande

# apt-get install autofs

Ceci installe évidemment le script de démarrage /etc/init.d/autofs qu'il ne faudra pas hésiter à utiliser pour appliquer les changements de configuration ultérieurs.

Le fichier principal est situé au chemin /etc/auto.master dans lequel toutes les lignes sont initialement commentées.

Je rajoute la ligne suivante pour mon cas :

/media/autofs/feydakin          /etc/autofs.d/feydakin.smb      --ghost

puis je crée le fichier /etc/autofs.d/feydakin.smb dans lequel je rajoute une ligne par montage souhaité selon le format suivant :

<nom_partage> <options_montage> :<cible>

Par exemple pour ma mp3thèque je saisirai :

music -fstype=cifs,credentials=/root/.samba/feydakin.cred,file_mode=0660,dir_mode=0770,uid=0,gid=1006 ://192.168.1.200/music

NOTE : il n'y a pas de retours à la ligne dans cette section, mais ma colonne n'est pas assez large pour l'afficher en entier)

Qu'est-ce que cela signifie en clair ? Je vais détailler.

Dans le premier fichier "maître" tout d'abord :

1. Je souhaite monter tous les partages définis dans le fichier /etc/autofs.d/feydakin.smb dans le dossier /media/autofs/feydakin (créé préalablement).

2. Feydakin est le nom de mon NAS, je regroupe ainsi tous les partages le concernant dans un fichier dédié afin de faciliter la maintenance que je nomme "feydakin.smb" par pur choix personnel. Le nom du fichier est le nom de la machine distante, l'extension m'indique le protocole utilisé pour ces montages. J'aurais pu lui donner le nom "coincoin.pouet" cela aurait fonctionné de la même manière, tout simplement car ce n'est pas ici que nous définissons les caractérisques de montage, seulement le dossier parent qui va accueillir les points de montage.

3. L'option "--ghost" en fin de ligne force autofs à créer un dossier correspondant à tous les points de montage même si ceux-ci ne sont pas encore montés. Par exemple au boot de la machine le dossier /media/autofs/feydakin/music sera automatiqement créé, mais sera vide. C'est assez pratique pour ne pas avoir de chemins invalides tant que les montages ne sont pas en place ce qui évite les erreurs potentielles.

Dans le second fichier à présent :

1. Je défini un montage nommé "music" qui donnera son nom au dossier créé à la racine commune pour les montages de ce fichier : /media/autofs/feydakin (défini dans le premier fichier)

2. Je spécifie les options de montage, c'est-à-dire essentiellement un copier-coller des options qui étaient jusque là dans /etc/fstab, en préfixant simplement par "-fstype=cifs," qui remplace le "smbfs" de fstab. Je ne détaille pas plus les options suivantes, un petit

$ man mount.cifs

vous en dira plus.

3. Enfin, j'indique où se trouve la cible du montage que je viens de définir. La notation est spécifique au protocole. Pour du SMBFS/CIFS j'aurai donc //192.168.1.200/music pour accéder au partage "music" situé sur la machine à l'adresse "192.168.1.200". Il faut cependant penser à préfixer ce chemin par deux-points ":".

4. Si j'ai d'autres partages, je n'ai qu'à les ajouter sur une nouvelle ligne en utilisant toujours le même format en 3 "colonnes". Et ainsi de suite.

That's all folks!

Je n'oublie pas de commenter les lignes correspondantes dans le fichier /etc/fstab, puis je reboote.

Et cette fois je n'ai plus aucune erreur ! Je tente immédiatement un :

$ ls /media/autofs/feydakin/music

et après une courte attente (liée au montage automatique par autofs en arrière-plan), le contenu du partage "music" du NAS s'affiche bien avec les bonnes permissions, exactement comme il s'affichait auparavant quand il était monté via fstab.

Dovecot-cot-socket

Petit souci supplémentaire dont je ne me suis pas aperçu immédiatement après la montée en version : Postfix semblait ne plus pouvoir envoyer de mails. En fait le problème n'était pas tant au niveau du MTA que du MDA, en l'occurrence Dovecot, dont la configuration avait largement évolué entre la version fournie avec Squeeze (1.2.x) et celle avec Wheezy (2.1.x). Mes fichiers de configuration ne correspondaient plus et les directives qu'ils contenaient ne s'appliquaient plus.

Il faut savoir que l'évolution entre ces versions ne touche pas seulement au format de certaines directives, mais également à leur répartition dans les fichiers de configuration. Auparavant par défaut rassemblées dans un unique fichier de 3Km de haut au chemin /etc/dovecot/dovecot.conf, elles sont maintenant éclatées, réparties par fonctionnalités dans des fichiers aux noms explicites situés dans le dossier /etc/dovecot/conf.d (comme c'est de plus en plus l'usage sur Debian).

Ce qu'il m'a fallu principalement reporter ce sont les directives de mise à disposition de l'authentification par socket, permettant à Postfix de déléguer l'authentification à Dovecot.

Mon fichier /etc/dovecot/dovecont.conf en version 1.x avait la section suivante aux alentours de la ligne 1140 (rien que ça...) :

...
socket listen {
        # Client for postfix SASL 
        client { 
            path = /var/spool/postfix/private/dovecot-auth 
            mode = 0660 
            user = postfix 
            group = postfix 
        }
    }
...

J'ai reporté cette section dans le fichier de configuration correspondant dans la version 2.x, c'est à dire /etc/dovecot/conf.d/10-master.conf :

service auth {
  [...]
  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/dovecot-auth {
    mode = 0660
    user = postfix
    group = postfix
  }
  [...]
}

La section générale "service auth" était déjà présente. J'ai simplement ajouté/décommenté la sous-section "unix_listener" que j'ai adaptée. Les "[...]" signalent que d'autres sous-sections sont présentes et sont à laisser telles quelles.

Un petit

# /etc/init.d/dovecot restart
# /etc/init.d/postfix restart

suivi d'un :

# ls -l /var/spool/postfix/private/dovecot-auth
srw-rw---- 1 postfix postfix 0 janv.  8 13:59 /var/spool/postfix/private/dovecot-auth

pour vérifier que le socket a bien été créé. Et c'est bon, on peut à nouveau envoyer des zimèles depuis l'extérieur de la machine !

Watchdog

Tout allait pour le mieux (et cette section ne serait pas là si j'avais moins tardé à publier ce post) quand soudain, courant décembre, mon serveur chéri s'est subitement mis à ne plus répondre.

Plus d'accès SSH, plus aucune réponse d'Apache ni de Webmin, rien de rien. J'ai alors branché un moniteur et un clavier sur la tour pour tenter d'en savoir plus sur l'état de la machine, mais le moniteur est resté désespérément en veille malgré mes appuis sur différentes touches.

J'ai dû me résoudre au fait que je faisais face à un crash (du genre plutôt méchant).

J'ai rebooté puis j'ai immédiatement consulté les logs et graphes de charge : chou blanc. Aucun indice ne permettait de comprendre ce qu'il s'était passé. S'il y a bien une chose pire qu'un crash complet de Linux, c'est être incapable d'en déceler l'origine.

J'ai espéré que ce cas resterait exceptionnel et considéré que cela pouvait arriver aux meilleurs (on se rassure comme on peut). Mais je ne tenais pas à ce que, s'il devait se reproduire, je sois obligé d'intervenir manuellement sur la machine, tout simplement car d'après la loi de Murphy, au moment où cela se produira je serai loin, et j'aurai un besoin urgent de la machine et ses services.

La solution ici était de confier la vie de la machine à un watchdog.

Je résume rapidement le principe du watchdog (ou "chien de garde" en françois du sud) : un composant matériel (bien) ou logiciel (moins bien) décrémente régulièrement un compteur initialement à N jusqu'à 0. Lorsque 0 est atteint, la machine est rebootée, de manière "soft" ou de manière "hard".

Afin d'éviter le reboot lorsque 0 est atteint, un processus du système est chargé de réinitialiser régulièrement le compteur à N. Tant que ce processus arrive à réinitialiser le compteur, c'est que - a priori - le système n'est pas planté (au moins le noyau donne régulièrement la main à ce processus qui peut faire son travail, ce qui est une bonne évaluation de "pas planté").

Si le système plante (ou est considéré planté^(*)) le processus ne réinitialisera plus le compteur. Le watchdog décrémentera lui toujours le compteur et arrivé à 0, il rebootera la machine.

Ça, c'est la version avec un watchdog matériel, mais ni tous les PC ni tous les CPU ne disposent nécessairement d'un watchdog matériel, c'est à dire indépendant des processus exécutés par le CPU. Je ne détaillerai pas ce cas ici mais il existe donc une "émulation" du watchdog sous Linux appelée "softdog" qui, au lieu de rebooter brusquement (mais efficacement) la machine, ordonne au noyau d'effectuer un reboot. Mais vous l'aurez compris : si le noyau lui-même est planté, cela ne sera d'aucun secours...

La première chose à faire dans ce cas de figure est de vérifier si la machine ou le CPU dispose d'un watchdog matériel. Pour cela, on peut utiliser la commande simple suivante :

$ ls -l /dev/watchdog
crw------- 1 root root 10, 130 déc.  21 13:18 /dev/watchdog

Le fichier spécial existe, ce qui signifie très probablement qu'un watchdog est présent et reconnu par le noyau. Pour s'en assurer on peut utiliser la deuxième commande suivante :

$ dmesg | grep -iE "(wdt|watchdog)
[    5.434643] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07
[    5.434926] iTCO_wdt: Found a NM10 TCO device (Version=2, TCOBASE=0x0460)
[    5.435133] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

Là on en est sûr : un watchdog existe (ici c'est celui inclus dans le chipset NM10 d'Intel, Atom oblige) et est utilisable. On apprend aussi que son "timeout" est de 30 secondes (troisième ligne), c'est au bout de ce temps qu'il reboote la machine si rien n'a réinitialisé le compteur. On apprend aussi que c'est le pilote noyau "iTCO_wdt" qui est chargé de sa gestion (voir la liste complète des pilotes et de leur options ici).

Il ne reste plus qu'à activer et configurer le daemon watchdog de Linux. Pour cela, rien de plus simple :

# nano /etc/watchdog.conf

et décommenter la ligne :

watchdog-device = /dev/watchdog

Puis pour activer le daemon au boot :

# nano /etc/default/watchdog

et décommenter/passer la valeur à 1 :

run_watchdog=1

On peut aussi en profiter pour vérifier que le pilote trouvé un précédemment est bien celui noté sur la ligne :

watchdog_module="iTCO_wdt"

On lance enfin le daemon :

# /etc/init.d/watchdog start

Pour tester : on va simuler un crash en empêchant le daemon de réinitialiser le compteur. Si on arrête "proprement" le dameon, le watchdog ne rebootera pas la machine car actuellement celui-ci est configuré en "nowayout=0" (c.f. résultat de la deuxième commande), c'est-à-dire qu'il reste possible de fermer le fichier /dev/watchdog de manière à ce que le watchodg comprenne qu'il doive arrêter son travail, et donc ne pas rebooter la machine. C'est ce qui se passe si on arrête le daemon en utilisant le script dans /etc/init.d.

Une manière de procéder est comme suivant (source) :

# touch /forcefsck
# sync
# pkill -9 watchdog
# for n in $(seq 1 60); do echo $n; sleep 1; sync; done

J'ajouterai personnellement que j'ai préféré aussi stopper proprement les principaux daemons (notamment Subsonic, MPD, Samba, ...) avant de les jouer.

L'effet est très simple : on force une vérification des disques au prochain reboot (parce que l'arrêt aura été brutal), on force l'écriture sur disque des données en attente, puis on tue le processus du daemon watchdog (donc pas de fermeture propre du fichier). On attend ensuite le reboot automatique pendant 60 secondes en forçant l'écriture des données sur disque toutes les secondes afin d'éviter au maximum les corruptions.

Et au bout de 30 secondes (chez moi) : boum ! Le PC reboote automatiquement, signalant le succès de l'opération. Je peux à présent ressortir de chez moi sans craindre de ne plus accéder à mon serveur à cause d'un crash (qui ne s'est pas encore reproduit par ailleurs).

(*) Mon utilisation ici est la plus simple qui soit, mais il est possible de configurer le daemon pour qu'il considère la machine comme "plantée" selon différents critères : ping d'une machine, charge moyenne, mémoire libre, température, etc. Consulter le fichier /etc/watchdog.conf pour en savoir plus.

Comme beaucoup de personnes ayant connu les années 90 (voire 80), j'ai encore des traces de ce qui représentait alors le summum de la technologie grand public de l'époque : j'ai nommé le caméscope-analogique-aux-couleurs-qui-bavent. Ces traces sont présentes chez moi sous la forme de cassettes VHS. Malgré la faiblesse de ce support, ce qu'elles renferment tient pourtant de l'inestimable : des souvenirs de vacances, d'anniversaires, de Noëls en famille, ...

C'est pourquoi j'ai pris la décision on m'a fortement incité à prendre la décision de numériser toutes ces bandes avant qu'elle ne disparaissent irrémédiablement, elles ou leur lecteur associé (appelé "magnétoscope", j'en avais parlé là de manière pas du tout ironique).

Cela faisait déjà pas mal d'années que je ne m'étais plus tenu au courant de ce qui se faisait en terme de capture vidéo sur PC, j'avais seulement des souvenirs assez flous du début des années 2000 où le matériel était clairement limitant : cartes dédiées hors de prix, pilotes et logiciels associés partiellement instables, débits d'écriture liliputiens, espace de stockage ultra-limité (les disques aux prix accessibles ne dépassaient pas les 40 Go), puissance CPU imposant de lancer les tâches de transcodage la nuit...

Tout ça pour finalement se rendre compte que les paramètres définis n'étaient finalement pas bons et qu'il fallait attendre la nuit suivante pour relancer le processus ! (dans un autre cas, le PC avait simplement planté lamentablement sous la charge)

C'est donc avec une légère crainte provenant du fond des âges que j'ai commencé mes recherches concernant l'acquisition du matériel adéquat pour numériser la poignée de cassettes qui se tenaient sur mon bureau. Même si les données que je devais extraire n'avaient pas de prix, j'avais placé une limite haute de budget à 80€, en espérant plutôt trouver un compromis à 50€ car il s'agirait certainement d'une opération unique que je n'aurais ensuite plus à refaire (ça et la période de Noël qui dit aussi grosses dépenses à côté).

Après une séance de lèche-vitrine sur les principales boutiques en ligne et la lecture de quelques comparatifs, mon choix s'est porté sur l'adapteur "USB-Live 2" d'Hauppauge, que j'ai trouvé à 40€ sur LDLC.

Comme son nom l'indique, il s'agit d'une "carte" externe, compatible USB 2.0 - point important : cela peut être clairement limitant si on traite de la vidéo HD, mais n'est pas mon cas - disposant de 3 connecteurs RCA (dits "cinch") et d'un connecteur S-Video. Je n'avais aucune assurance concernant sa compatibilité avec Linux mais son prix était clairement intéressant, donc même si mon objectif était de réaliser les captures sous Linux, j'étais prêt à y renoncer en dernier recours.

Les premiers tests

N'étant pas chez moi pour les fêtes, j'ai tout d'abord testé l'appareil sur un PC équipé de Windows XP. Après l'installation de la partie analogique (un magnétoscope Schneider 65DV20, pour information), les éternelles installations de pilotes suivies par les non moins éternels redémarrages, j'ai pu faire l'amère constatation que... je n'avais pas les bon câbles.

En effet, même si j'avais prévu l'adaptateur Péritel/RCA et les câbles Composite, aucun signal ne semblait arriver à la carte. En cherchant un peu, j'ai réalisé qu'il me fallait un adaptateur d'un type différent : celui que j'avais ne fonctionnait que dans le sens Composite -> Péritel et non l'inverse. Or ici la Péritel était branchée en sortie du magnétoscope, et le signal sortait par les prises RCA. (je n'ai pas poussé plus loin mes investigations, donc si quelqu'un tient à me corriger, qu'il n'hésite pas)

En faisant quelques courses le lendemain, j'ai évidemment fait un tour du côté HIFI d'un Géant Casino afin de voir si par hasard je pouvais éviter la commande en ligne. Bien m'en a pris car j'ai trouvé un adaptateur Philips correspondant avec un câble de 1,5m pour à peine 8€. Si tout allait bien, je restais encore dans mon budget ! :)

Pour information, je n'ai pas la référence exacte mais il s'agit d'un câble équipé 3 prises RCA d'un côté (2 audio + 1 vidéo) et d'une Péritel de l'autre. Un bouton sur la Péritel permet de choisir le sens du flux : IN ou OUT. Ici c'est OUT qui m'intéresse.

Sous Windows...

De retour sous Windows, les tests ont été plus concluants. "Plus" oui, mais pas totalement. J'arrivais enfin à obtenir le signal sur le logiciel WinTV fourni avec la carte, mais celui-ci était brouillé, un peu comme... s'il n'était pas décodé en SECAM. Ah, le bonheur de ces formats antiques ! Grr...

J'ai dû chercher une bonne paire d'heures avant de me rendre compte que ce que je prenais pour la fenêtre de modification du format de lecture (NTSC, PAL, SECAM, etc.) n'était en fait que la fenêtre de configuration générale du dispositif de capture, et que la liste permettait seulement de consulter les formats supportés (je résume, mais c'est à peu près aussi bête). Pour changer le standard de codage à la volée au cours de la capture, il suffisait de... changer de chaîne.

La carte est en effet vue comme un tuner, et changer de chaîne permet de passer d'un standard à un autre, ce qui, lorsqu'on a trouvé le bon, donne immédiatement une image claire (enfin, pour autant qu'on puisse considérer ce type d'image analogique comme "clair", mais c'est une autre histoire).

J'ai immédiatement tenté la capture de la première cassette.

Trois heures plus tard (la durée de la cassette...), le logiciel WinTV avait généré un fichier TS de 8 Go environ contenant deux flux : un flux vidéo encodé en MPEG-2 et un flux audio encodé en MPGA (appelé "MP2"), ce qui est je crois le format des DVD. Le tout était évidemment désentrelacé, et la synchronisation vidéo/audio parfaite d'un bout à l'autre.

Un très bon point.

Puis sous Linux...

Maintenant que je m'étais assuré que le montage fonctionnait sous Windows, je pouvais faire le test sous Linux. Ayant sur moi mon vaillant PC portable de 2009 tournant sous Archlinux, j'ai branché la carte USB et commencé mes recherches sur le grand Nain Ternet. Les premiers résultats étaient moyennement encourageant : le wiki de LinuxTV indiquait qu'un noyau récent supportait "probablement" cette carte, mais un autre paragraphe était moins enthousiaste.

Pour tester cela semblait simple : brancher la carte et lancer xawtv.

# pacman -Sy xawtv
$ xawtv

Et effectivement, j'ai branché la carte sur un port USB libre, installé et lancé xawtv, et miracle : l'image apparut correctement dans le petit cadre !

Bon, impossible de l'agrandir sous peine de perdre la moitié de l'affichage - remplacé par une bande verte - mais qu'à cela ne tienne ce n'était pas pour du visionnage en plein écran que je souhaitais utiliser la carte mais pour de la capture vers un fichier. J'étais sur la bonne piste.

Première étape : la capture

De retour dans mon atelier chez moi, sur mon fidèle Freeseed bi-core équipé lui aussi d'Archlinux, j'ai cherché comment enregistrer le flux de la manière la plus brute possible, même si cela devait signifier de créer des fichiers de 10 à 20 Go par heure. Mon objectif était dans un premier temps de créer des enregistrements simples que je pourrais retravailler et transcoder après coup.

J'ai tout d'abord regardé du côté de VLC, véritable boîte à outil vidéo multi-plateforme.

Seulement, à mon grand désespoir, si j'arrivais bien à obtenir l'image en utilisant la configuration prédéfinie "TV (analogique)", le son lui manquait, et l'erreur suivante apparaissait :

Évidemment qu'il n'y a aucun fichier à cet emplacement, mais ce n'est pas ce que je te demande, banane !

Après une rapide recherche infructueuse pour déterminer d'où pouvait bien provenir le fait que VLC essaye d'ouvrir le périphérique audio comme un fichier dans le dossier courant, je me suis finalement tourné vers mplayer et son acolyte mencoder. J'ai trouvé des exemples de commandes permettant a priori de faire ce que je voulais, alors je les ai essayées.

L'enregistrement serait fait dans un conteneur AVI, en utilisant le codec vidéo MJPEG et le codec audio PCM (ce qui est connu comme le format "wave" sous Windows). Il s'agit d'un des fomats les plus simples et les plus "bruts" : la vidéo est mise sous forme d'images JPG indépendantes (il y a donc une compression mais sur chacune des images, pas sur le flux), et le son est conservé sous forme d'onde échantillonnée, donc sans aucune compression.

Puis j'ai testé.

Longuement.

Laborieusement.

Le premier test m'a donné une vidéo en accéléré alors que le son était au rythme normal. J'ai alors ajouté les paramètres "-noskip" et "-mc 0" pour conserver les frames. Le résultat semblait bon, alors j'ai lancé la capture d'une seconde cassette de trois heures.

Lors d'un visionnage attentif de la vidéo générée, j'ai réalisé qu'après une heure environ le son était en retard par rapport à l'image, et que ce retard se creusait progressivement pour atteindre les 4 à 5 secondes en fin de fichier. Inacceptable.

(2 jours plus tard...)

Après moult essais à base de combinaisons de paramètres obscurs, filtres vidéo ("harddup", "softskip" et autres), incantations magiques et tentatives d'envoûtement (en dernier recours) qui n'ont jamais corrigé ce rogntudju de décalage entre le son et l'image, j'ai décidé de me reconcentrer sur VLC. Mes recherches montraient clairement que lorsqu'un problème n'était pas résoluble par mencoder, il fallait tenter VLC (et réciproquement).

Le problème du périphérique de son évoqué plus haut a été "simplement" résolu en préfixant la valeur proposée dans la liste "hw:2,0" par "alsa://". Les joies du son sous Linux où OSS, Alsa, Pulse et les autres s'ébattent joyeusement dans une mare de caca.

Voici finalement la boîte de dialogue avec la configuration fonctionnelle, celle affichant, dès l'appui sur le bouton "Lire" l'image provenant de la carte d'acquisition et le son associé :

Ce qui est intéressant c'est que si je souhaitais, disons par exemple, créer un petit script pour enregistrer le flux via VLC, je n'ai qu'à prendre les options de lecture qui apparaissent en cochant "Afficher plus d'options".

La commande pour simplement lancer la lecture dans VLC va donc se traduire par :

$ vlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300

Ça, c'est pour lire. Moi je veux enregistrer. La commande complète serait donc celle-ci :

$ cvlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300 \
:sout=#transcode{vcodec=mjpg,acodec=mpga,vb=1024,ab=160}:standard{access=file,dst=out.mpg}

Ce qui signifie :

• Utiliser la version "console" de VLC (pas d'interface graphique, donc pas de suivi de la vidéo. Utiliser "vlc" à la place de "clvc" pour retouver l'interface)
• Lire la vidéo sur le périphérique V4L /dev/video0
• Lire le son sur le périphérique ALSA hw:2,0 (à adapter selon la configuration matérielle, etc.)
• Utiliser le standard de codage SECAM L/C (ce que xawtv me sélectionnait automatiquement plutôt que "SECAM L", je n'ai pas trouvé ce qui différenciait les deux)
• Transcoder la vidéo en utilisant le codec MJPEG (pareil qu'avec mencoder) avec un bitrate de 1024k
• Transcoder le son en utlisant le codec MPGA (MP2) avec un bitrate de 160k
• Écrire le tout dans un fichier "out.mpg", qui, d'après l'extension, sera un conteneur MPEG-PS (sinon on peut forcer le muxer en utilisant le paramètre "mux=...").

Pour connaître les codecs et muxers utilisables, voir cette page :

https://wiki.videolan.org/Codec

MAIS.

J'obtenais encore une fois un décalage entre le son et l'image : cette fois-ci le son était en avance. Grr de grr.

Il a fallu que je change le codec vidéo et passer par du MPEG-1 (toujours avec du MP2 en audio) pour enfin obtenir une vidéo synchronisée de bout en bout !

Ma commande "finale" est donc :

$ vlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300 \
:sout=#transcode{vcodec=mp1v,acodec=mpga,vb=1024,ab=160}:standard{access=file,dst=out.mpg}

J'ai pu ainsi numériser tranquillement toutes les cassettes restantes, et créer des fichiers MPG propres que je pouvais ensuite transcoder et compresser à loisir dans un second temps. Pour information, à la fin de cette première phase on obtient des fichiers pesant 6 à 7 Go par heure, ce qui est très acceptable AMHA.

Afin de conserver la trace de ces commandes et pouvoir les adapter et les réutiliser au besoin, j'ai créé un script Bash auto-explicatif très simple disponible ici :

http://pastebin.com/kXCw2qUN

Pour l'utiliser :

$ record_vlc.sh [<duree>]

Où <duree> est la durée de l'enregistrement à créer, en secondes (optionnelle).

Ne pas oublier de configurer correctement les variables VIDEO_DEV et SOUND_DEV en début de script.

Deuxième étape : redécoupage et transcodage

Là je vais résumer par flemme, mais ce fut encore perte de temps et compagnie, car en plus de vouloir transcoder les films bruts dans un format un peu plus économe en terme d'occupation sur le disque, je souhaitais recouper le film : supprimer les quelques secondes initiales, et souvent les nombreuses minutes à la fin (ayant lancé la commande pour numériser la totalité de la cassette, même si parfois seule une partie était réellement utilisée).

J'ai réessayé mencoder, qui normalement est fait pour cela. Mais j'obtenais de nouvelles désynchronisations dans les vidéos résultantes, ou (selon le codec testé) des corruptions dans le son. OK je passe au suivant.

VLC m'a donné peu ou prou la même chose, avec au final un résultat décevant. Impossible notamment de bien recouper le film à partir d'un point jusqu'à un autre.

Puis je suis passé à ffmpeg. Et enfin, ce fut le bon ! Je pouvais redécouper correctement les morceaux qui m'intéressaient et encoder la vidéo dans un format un peu plus efficace : MPEG-4 (avec le son en MP3), le tout enrobé dans du bon MKV.

Voici donc la commande utilisée pour ce faire :

$ ffmpeg -i in.mpg \
-c:v mpeg4 -b:v 6000k -c:a mp3 -b:a 160k \
out.mkv

J'ai également créé un script Bash auto-explicatif permettant de configurer le transcodage. Il est disponible ici :

http://pastebin.com/BTJdyTbN

Pour l'utiliser :

$ transcode_ffmpeg.sh <fichier> [<debut> <fin>]

Où <debut> est la position à partir de laquelle commencer la conversion du film d'origine et <fin> la position de fin. Les deux paramètres peuvent être spécifiés en secondes ou au fomat **hh:mm:ss[.xxx]** (grâce à ffmpeg qui accepte les deux).

J'obtiens ainsi des fichiers dont la taille a été divisée par un peu plus de 2 (exemple : 9,7Go après conversion par ffmpeg pour 21,8Go après l'enregistrement "brut" par VLC). La différence de qualité est elle imperceptible (pour moi).

Voilà c'est tout. J'espère encore une fois ne pas avoir dit trop de c... bêtises, et que le récit de mes péripéties pourra être utile à quelqu'un souhaitant aussi mettre en lieu sûr ses précieux souvenirs analogiques des années 80 et 90. Si j'en juge par le peu d'informations utilisables (et à jour) que j'ai pu dénicher sur la Toile, je pense que oui.

Je délaisse un moment les octets, CPU, Watts, codes sources, NAS, adresses IP et autres scripts chers à tout geek qui se respecte, pour tenter de vous faire découvrir quelques perles musicales qui me tiennent à coeur ces derniers temps.

Voici la troisième édition des Sons en Vrac, avec au menu de la soul, du jazz, du rock, du trip-hop et bien sûr du métal. Bonne écoute !

Beth Hart

Découverte il y a plus d'un an avec un enregistrement live sur Oüi FM (ci-dessous), j'ai été subjugué et emporté par la puissance et le timbre de sa voix.

Beth Hart est une chanteuse américaine de rock/blues/soul qui officie depuis la fin des années 90 et sort depuis régulièrement de nouveaux albums. Son style, sans être d'une originalité extrême, est reconnaissable principalement à sa voix, encore une fois.

Les quatre albums que j'écoute régulièrement sont les suivants :

• Screamin' For My Supper (1997)
• Leave The Light On (2003)
• 37 Days (2007)
• My California (2010)

De la bonne musique américaine, où l'on perçoit les différentes influences culturelles qui s'entremêlent et qui personnellement projette dans mes yeux de petit Européen des images de grands espaces et d'american way of life comme on n'en fait plus.

Seth MacFarlane

On reste aux USA mais on change totalement de registre avec un monsieur que beaucoup connaissent pour être l'auteur de ces séries héritières des Simpsons des premiers jours, politiquement incorrectes et délirantes, j'ai nommé Family Guy, American Dad et maintenant The Cleveland Show (dans une moindre mesure cependant).

Qui n'a jamais réécouté deux fois ces scènes dignes de comédies musicales des années 50 ? Moi je n'ai pas résisté en tout cas. Et quand on sait que c'est Mr MacFarlane lui-même qui fait la voix des principaux personnages et lui qui chante toutes les chansons, on ne peut que lui reconnaître un indéniable talent et pardonner à ses séries certains gags pipi-caca (il paraît que ça gêne des gens, moi j'adore).

Seth nous offre dans son album Music Is Better Than Words une reprise de titres de swing et jazz des années 40 à 60 dans le pur style Sinatra-esque accompagné d'une orchestration sans faille qui nous replonge instantanément dans un univers de chaleur en noir et blanc.

Heifervescent

Découvert sur Jamendo il y a un peu plus d'un an, c'est encore aujourd'hui avec bonheur que j'écoute ce petit groupe indé britannique qui nous offre dans ses cinq albums une pop-rock rafraîchissante et énergique, aux sonorités originales et acidulées.

Les trois albums sont disponibles en intégralité sur Jamendo et en téléchargement gratuit :

• Pondlife Fiasco (2009)
• The Glue Factory (2010)
• Further Adventures in Monkeyland (2011)

Pour les plus récents par contre :

• Little Egg (2012)
• Wake Up Sheepyhead (2013)

certaines pistes ont été otées et ne sont disponibles que par des voies bassement commerciales (les auteurs réclamant paraît-il de pouvoir vivre de leur travail).

Je ne peux que vous conseiller une petite écoute rapide sur Jamendo, et si le son vous plaît, de télécharger (pour les gratuits) et d'acheter leur discographie.

Tab & Anitek - Sights & Sounds

Toujours sur Jamendo, une petit "album" de trip-hop/ambient qui s'écoute aussi facilement pour se détendre, pour bosser toute la journée ou pour accompagner une soirée (arrosée ou non).

Je n'ai pas encore écouté le reste de la discographie d'Anitek mais si le reste est du même acabit j'adhère à 200%.

Paradise Lost

Là j'attaque du lourd, du groupe de metal britannique qui vient de fêter ses 25 ans - rien que ça - avec sa horde de fans poilus (j'imagine hein) et qui a débuté dans le registre sombre du doom/death, pour créer ce qui deviendra le gothic, et prendre ensuite un "virage" vers ce que Wikipédia n'hésite pas à appeler de la cold wave et redescendre à nouveau vers du gothic-metal plus "léger" et carrément excellent, avant de finalement revenir dans les derniers albums vers ses origines plus "dark".

Listons d'abord les (nombreux !) albums :

• Lost Paradise (1990)
• Gothic (1991)
• Shades of God (1992)
• Icon (1993)
• Draconian Times (1995)
• One Second (1997)
• Host (1999)
• Believe In Nothing (2001)
• Symbol Of Life (2002)
• Paradise Lost (2005)
• In Requiem (2007)
• Faith Divides Us Death Unites Us (2009)
• Tragic Idol (2012)

Je l'avoue de suite : je ne suis pas fan des premiers albums jusqu'à One Second. Trop death pour moi.

J'ai en fait d'abord découvert l'album de pop (!) Host qui m'a franchement plu avec ses mélodies accrocheuses et ses sonorités électro à la Depeche Mode (mais sans l'impression désagréable de déjà-entendu). Les métalleux purs et durs renient j'en suis sûr volontiers cet opus trop radio-like.

Mais ce n'était qu'une entrée en bouche, et One Second est arrivé. Et là, la claque. Des teintes d'électro, mais moins que sur Host, une base metal indéniable mais des arrangements complexes, pour un tout finalement agréablement abordable et surtout carrément pêchu !

J'ai poursuivi sur la lancée avec Believe In Nothing et Symbol Of Life, les deux autres membres du trio qui constitue mes références actuelles pour ce groupe. Puis je suis passé aux suivants que j'apprécie finalement à chaque écoute un peu plus. Une fois mon oreille éduquée, j'ai même tenté une réécoute des premiers albums, mais il n'y a guère que Draconian Times qui peut pour le moment flatter mon tympan.

Tout ça pour en arriver à me demander comment le metal fait pour passer sous le radar des média traditionnels pour que des perles dans ce genre me soient restées cachées aussi longtemps. Mais pinaise la découverte en vaut le coup !

Blackstar Halo

Découvert fin 2011 (déjà !) en regardant la vidéo du Winland Tour de MaSu (séquence), j'ai immédiatement accroché au son de ce groupe de metal finlandais. Seul un album (Illuminated) est pour le moment disponible mais le groupe nous assure qu'un second est en préparation.

Quoi dire de plus ? C'est du metal progressif tendance mélodique, qui rappelle parfois un peu MaSu... sans le SID-side évidemment !

Si vous accrochez, je vous conseille également d'écouter l'album My Last Prayer de Downfall qui n'est autre... que le même groupe avant que celui-ci ne change de nom ! Un peu moins travaillé, on voit sans peine que le groupe a progressé depuis 2002, que ce soit au niveau chant que dans les arrangements.

Battle Beast

Voici venu le temps... non pas des rires et des chants, mais du metal kitsch ! Oui dit comme ça évidemment ça ne donne pas trop envie. Imaginez seulement qu'un groupe de heavy metal des années 80 atterrisse par quelque hasard à notre époque en ayant sauté toutes les évolutions que le genre a connu en plus de 20 ans... et essaye tant bien que mal de les rattraper !

Résultat : bam, Battle Beast.

Un groupe venu de Finlande (comme c'est étonnant), formé en 2008, que j'ai découvert sur Tracks l'an dernier et qui, passé la première impression "Whouah c'que c'est kitsch !", m'a sérieusement donnée envie d'écouter l'album entier pour m'en faire une idée plus... complète.

Et c'est kitsch. Si si faut l'avouer. Mais c'est du kitsch travaillé, énergique, avec son côté heavy metal de papa et ses paroles qui nous dévoilent un monde dur, froid et robotique et... ouais ok et ça va pas très loin. On n'est pas chez un Nightwish, mais l'ensemble est assez flatteur, avec des gros riffs de guitares bien francs et des synthés en choeurs derrière. Ce qui tranche peut-être un peu, c'est la voix. Car c'est une métalleuse aux commandes, pour le premier comme pour le second album (même si c'est pas la même).

Si la chanteuse du premier album me convainquait niveau puissance mais moins niveau timbre, celle du deuxième m'emballe carrément plus quand elle montre l'étendu de ses capacités vocales (voir un bon exemple dans la vidéo ci-dessous). Oui j'ai bien dit capacités vocales, arrêtez de mater.

C'est tout pour cette fois, mais une quatrième édition n'est pas exclue !

La première partie est disponible ici !

Déballage, assemblage... et lamentage

C'est finalement le kit PicoPSU qui est arrivé des zuhessa en premier, suivi de près par le colis contenant la carte mère (et processeur), la RAM et le boîtier (la faute à une livraison en point relais un peu à la traîne).

Concernant le PicoPSU, le kit arrive avec un câble secteur doté d'une prise US. Ah oui, normal.

Mais je dois bien avoir dans mon bordel armoire de matos un câble avec prise européenne d'un côté et une prise Mickey de l'autre (rapport à la forme de la prise femelle sur le transfo).

*farfouille*

Cool en voilà un. Ah mais le transfo est-il adapté au 220V d'ici ? Consultation de l'étiquette collé dessus et croisage de doigts : oui c'est bon, ouf. Bon, c'est un signe du destin : il ne peut plus rien nous arriver d'affreux maintenant.

Passons à la partie plus classique et rassurante : les autres composants.

La carte mère sort de son blister étincelante et chatoyante à la lumière du soleil d'une matinée dominicale (en fait c'était un début de soirée pluvieux de semaine, mais ça rend moins bien la magie de l'instant je trouve).

Je réalise ensuite que le boîtier est plus grand que ce que je n'avais imaginé. Ah oui c'est gros 20 litres. Une rapide inspection confirme toutefois les propos de l'article de Canard PC : c'est beau et fonctionnel, presque trop pour le prix.

J'installe précautionneusement la carte mère sur ses supports et les disques dans les racks derrière le ventilateur en façade, puis je branche le tout. La barrette de RAM, dans le slot... heu, ben 1, soyons logique. Je passe ensuite au PicoPSU, dont la prise ATX contient le transformateur DC-DC final délivrant le 3,3V pour le CPU et 5V pour les disques (le 12V arrivant directement du transfo 220V externe).

Heu. Tiens donc.

Mais mais. Il me manque 4 pins là !

Ce modèle de PicoPSU fournit en fait une prise ATX 20 broches, alors que la carte mère en a 24 ! (les modèles plus puissants fournissant eux une 24 pins)

Bon réfléchissons. Ça rentre bien d'un côté, ce qui est normal car je me rappelle qu'il y a quelques années les alimentations commençaient à fournir une prise ATX en deux parties 20+4 qu'on collait lors de l'enfichage, de manière à être utilisables même avec des cartes mères n'utilisant que l'ancienne prise de 20 broches, ce qui m'est parfois arrivé.

Si ça rentre, c'est que c'est compatible, admettons. Donc si j'appuie sur le bouton Power... ça devrait marcher ? Hum bon, enfilons cette combinaison hazmat, chaussons nos lunettes de soudure et bouchons nous les oreilles... j'appuie...
  
Et ça fait...

Rien.

Enfin si, les ventilateurs tournent, et plusieurs bips sortent du buzzer. Mais rien de plus.

D'accord, ces bips signifient qu'il y a un problème. Ça doit vraiment pas lui plaire d'avoir que 20 broches alimentées, et il me le fait savoir.

J'envisage quelques secondes la galère si je dois renvoyer le kit PicoPSU et abandonne immédiatement cette option en calculant les frais de port nécessaires.

Je cherche alors l'utilité des 4 pins supplémentaires et les réponses que je trouve indiquent qu'ils permettent de mieux répartir la puissance sur les rails 12V.

Puissance ?

Non mais j'ai pas des GeForce Titan en SLI avec un Pentium 4 overclocké là, j'ai un pauvre Atom avec GPU intégré ! Y'a pas de puissance à répartir, y'a même pas de quoi assommer une mouche ! Mais comment être sûr de ne pas faire de c... bêtise ?

Il m'a fallu poster la question sur le forum de CPC pour remettre mes idées en ordre et reprendre l'ensemble des informations dont je disposais pour exposer mon cas (finalement resté sans réponse), ce qui m'a permis de réaliser un magnifique facepalm avec triple axel et quadruple lutz mention RTFM historique.

* pleure *

Suite à cela, je passe les détails (si si) mais il a bien dû se passer une journée avant qu'après d'intenses recherches je ne trouve la signification des bips (parce qu'elle n'était pas mentionnée dans le manuel papier ÇA SERAIT TROP SIMPLE) et constate qu'il s'agit apparemment... d'un problème de RAM.

Un éclair de génie me traverse alors l'esprit (ça fait mal quand même) et un vague souvenir me revient alors à propos de la nécessité de mettre la barrette sur le second connecteur. Après vérification c'était en commentaire sur la fiche produit de la carte mère, que j'avais pourtant lue et relue. *double facepalm*

Je m'exécute et tente à nouveau l'appui fatidique sur le bouton Power, cette fois sans combinaison hazmat, faut pas déconner.

Ô miracle ! Ça démarre !

Booting, please wait...

Avant de tenter quoi que ce soit sur l'installation aux petits oignons que je me suis mijotée pendant trois ans, je décide :

• d'un : de faire un backup avec Clonezilla (ça coûte pas cher, merci le NAS);
• de deux : de restaurer cette image sur un disque vierge seul branché sur la nouvelle carte mère afin de tester le bon fonctionnement du changement de configuration sans toucher au disque d'origine.

Mauvaise surprise : ça ne boote pas. GRUB ne s'affiche pas après le POST ce qui me plonge donc dans un grand désarroi.

Je décide d'aller dans le Setup du BIOS pour voir si une petite phase de configuration additionnelle ne serait pas nécessaire. Ah, en fait il ne s'agit pas d'un BIOS mais d'un UEFI.

Enfin Léon, soyons modernes.

Bon là j'avoue ne pas me souvenir de ce que j'ai pu faire pour résoudre cette erreur. Sûrement activer la compatibilité BIOS, ou mettre le firmware à jour, ou même simplement réordonner les périphériques de boot, je ne sais plus.

Toujours est-il que finalement le GRUB s'est bien affiché et j'ai pu constater avec effarement que Linux n'était absolument pas dérangé par le changement de configuration matérielle. J'avais quand même pris garde à ne pas brancher le câble réseau afin d'éviter les conflits et les interactions avec les autres machines du réseau (eh oui, il s'agissait alors d'un clone parfait d'une "autre" machine).

J'ai quand même dû modifier deux-trois choses ici et là, certains périphériques ayant malgré tout changé. La carte réseau étaient notamment vues comme une nouvelle interface et a donc pris l'identifiant "eth2" (mais j'avais déjà eu le cas lorsque sur Usul I j'avais ajouté la carte réseau PCI-Express Gigabit Intel qui avait pris l'identifiant "eth1"). À part ça tout semblait fonctionner.

J'ai finalement branché les disques définitifs, refait les mêmes opérations validées précédemment, et j'ai lancé le "rodage" : laisser la machine tourner un jour ou deux afin de m'assurer de la stabilité de l'ensemble.

Coup d'oeil au compteur

Avant même de commencer à remettre les doigts sur le terminal, il me fallait connaître enfin si un des objectifs de cette nouvelle configuration était rempli : abaisser encore la consommation électrique par rapport à Usul I.

Je dégaine donc mon Conserve Insight de Belkin et relève la consommation observée à la prise. Victoire ! Pas écrasante mais quand même : 28W environ en idle. Cela fait donc 5W gagnés, soit 15% de moins qu'Usul I. Pas énorme mais difficile de faire mieux. Je pourrais gagner le double si je retirais un des deux disques durs (ça consomme pas mal à cette échelle ces petites bêtes !).

Le principal est que cette nouvelle plateforme matérielle soit "mieux" que l'ancienne, c'est-à-dire que le ratio puissance/consommation soit bien supérieur à ce qu'il était. De ce côté-là, c'est clairement gagné. La mesure de la puissance brute sera peut-être effectuée ultérieurement au moyen de mon benchmark maison basé sur sysbench.

Mise à niveau de Debian

Lorsque j'avais monté Usul I en 2010, mon choix de distribution s'était logiquement porté sur Debian, pour la stabilité et ma bonne connaissance de l'environnement. J'avais choisi la version "unstable", qui allait devenir la version stable quelques semaines plus tard : Squeeze (version 6).

Trois ans plus tard, Squeeze était devenue la "oldstable" et sa remplaçante se nommait Wheezy. C'était l'occasion où jamais de monter en version mon installation et profiter de paquets tout frais contenant des logiciels à jour (hum, ou presque, on parle de Debian hein).

Cela tombait bien, car le changement de matériel avait eu un petit effet que je n'avais pas remarqué immédiatement : les capteurs de températures et des ventilateurs n'étaient pas reconnus par le kernel, trop vieux pour eux ! Pour une machine qui reste au fond d'un placard 24h/24 il est quand même préférable d'avoir des alertes programmées sur ces informations ! La montée en version s'avérait donc nécessaire.

Pour avoir connu plusieurs déboires sur des montées en version d'Ubuntu par le passé, je décide de préparer le terrain minutieusement, en commençant par lire les instructions fournies par le site Debian (la menace du triple facepalm n'étant pas loin). Celui-ci précise un mode opératoire détaillé dans les notes de publication qui commence par la nécessité de sauvegarder la configuration complète du système, c'est-à-dire principalement /etc.

En ce qui me concerne, j'ai un job cron qui se charge d'archiver sur le NAS le contenu de ce répertoire toutes les nuits, donc pas de souci à ce niveau.

Comme la mise à niveau implique principalement l'utilisation du (ou des) gestionnaires de paquets, il est ensuite fortement conseillé de nettoyer la base de données des paquets et ses dépôts.

Fort judicieux ! Surtout que depuis quelques mois, sérieusement limité par les versions obsolètes de nombreux logiciels, j'ai bidouillé peu à peu mes dépôts et mes directives de mises à jour pour profiter de quelques paquets normalement inaccessibles à ma version de Debian, ce qui me cause régulièrement quelques galères avec les mises à jour.

Je passe donc au moins une heure à remettre tout à plat, quitte à supprimer quelques logiciels (notamment Deluge) que je note quand même dans un coin histoire de ne pas oublier de les réinstaller une fois la mise à niveau effectuée. Les instructions données sont faites pour être claires mais j'avoue cependant ne pas comprendre la totalité des commandes à lancer, n'étant pas un spécialiste de la gestion des paquets. Enfin bon, j'arrive quand même à obtenir un environnement qui semble suffisamment stable pour lancer la mise à niveau vers Wheezy. Au pire j'ai toujours l'image de la partition système que je peux restaurer si jamais quelque chose se passe mal.

Je démarre la mise à jour, et jette un oeil régulièrement à l'avancée du téléchargement des centaines de mégaoctets qui arrivent des serveurs miroirs...

Un bon moment plus tard, j'obtiens un prompt m'indiquant que la procédure est terminée. L'instant crucial du reboot est arrivé.

Et il passe ! Sans heurt majeur, hormis le fait que j'ai dû appuyer sur S(kip) pour passer le montage de partages réseaux mentionnés dans /etc/fstab lors du boot. Hum, bizarre.

La plupart des services se lancent sans aucun problème, et mes applications PHP et Java sont de retour sur des versions de plateformes presque récentes ! Je passe notamment d'un PHP 5.2 vieillissant à la série 5.3.

Le noyau Linux prend aussi un coup de jeune en passant de la série 2.6.32 à la 3.2. PostgreSQL - le SGBD que j'ai choisi pour cette machine au détriment d'un classique MySQL - change de version majeure de la 8.4 à la 9.1. Pour celui-ci par contre mise à niveau n'est pas totalement automatique et j'ai suivi les instructions (finalement très simples) disponible par exemple ici pour migrer mes données d'un moteur vers un autre. Il s'agit simplement de faire un dump, d'arrêter le daemon, de basculer le moteur et sa configuration puis de le redémarrer, et enfin restaurer le dump. Rien d'impossible sur une machine locale. Sur un serveur de prod par contre ce serait un poil plus délicat !

Reste à voir à présent le résultat du rodage et les configurations supplémentaires qu'il faudra immanquablement effectuer... dans la troisième et dernière partie !

Arte reste vraiment une chaîne extraterrestre dans le paysage audiovisuel français. Nombreux sont ceux qui sont d'accord avec cette affirmation pour de mauvaises raisons, et voient encore celle-ci comme peuplée de reportages sur la seconde guerre mondiale sous-titrés en jaune et de films en noir et blanc dont ils ne sauraient préciser l'origine (Europe de l'Est certainement).

Pour moi Arte est la seule chaîne qui s'autorise le mélange entre découvertes culturelles et une certaine liberté de ton, sans tomber dans les travers de ses concurrentes (mais le sont-elles vraiment ?).

Je suis depuis de nombreuses années l'émission Tracks qui pour moi reste une source de prédilection pour la découverte de nouveaux groupes de musique et de passions et modes de vie dits "alternatifs".

Et voici quelques semaines, Arte et la Générale de Production se sont mises à produire une émission courte hebdomadaire sur un sujet qui me passionne : l'univers geek et sa ses cultures. Je suis loin d'être adepte de toutes ses branches (il y en a tant !) mais certaines - l'informatique en premier bien évidemment - représentent une part importante de ma vie. Chacun son hobby, chacun ses passions.

Voici donc BiTS, tous les mercredis, disponible sur Youtube en accès libre. Six numéros au compteur, et on espère que cela ne fera qu'augmenter. L'émission en elle-même ne dure que dix minutes, mais de (très) nombreux bonus sur la chaîne viennent compléter chaque épisode.

Les trois premiers numéros qui vous mettront - je l'espère - l'eau à la bouche sont ci-dessous.

Ne manquez pas également :

• Le site (bourré de coins et recoins !)
• La playlist BiTS sur la chaîne Youtube d'Arte
• Le compte Twitter @BiTSmagazine
• Le flux RSS de la playlist (merci @ellouis)

Et la suite est ici !

Vous n'êtes pas sans savoir que j'élève depuis bientôt trois ans dans mon placard une bête modeste mais ma foi fort pratique : un home server nommé Usul. Elle est d'ailleurs régulièrement citée dans ce blog pour être de toutes mes bidouilles et représenter une part importante du panel des services que je me constitue afin de profiter de tout ce que l'informatique moderne (et libre, de préférence) peut nous offrir.

Crise de la quarantaine, 2CV et comparaisons douteuses

Pour ses trois ans, je souhaitais faire quelque chose de spécial. C'est vrai, trois ans c'est important, ça doit bien faire quarante ans en âge humain.

C'est l'âge des remises en question, où l'on jette un oeil derrière soi pour regarder ce que l'on a accompli, où l'on espère que la deuxième moitié de la vie ne sera pas trop dure avec nous, que nous pourrons encore profiter de celle-ci.

Même si notre processeur nous demande parfois de ralentir le rythme, même si notre mémoire nous fait parfois défaut – surtout la nuit quand tous les crons de mises à jour s'empilent et qu'on se réveille le lendemain avec un mal de swap –, on se dit qu'on se moque bien de tous ces jeunes PC, de leurs cores hyperthreadés et de leurs gigaoctets de RAM, car nous, nous n'avons jamais failli. Nous avons été là et nous avons bien servi, sans ventirad ni artifices.

Alors bien sûr, quelques douleurs s'installent pernicieusement au fil du temps. Si cette génération a évité le fléau du mal de DOS qui a touché tant d'anciens, celui des OS existe encore.

Un jour on soulève un paquet un peu lourd pour l'installer, on ne suit pas les instructions, et des fichiers corrompus se retrouvent dans notre système, le ralentissant lentement. Au début on ne s'en rend pas compte. Puis les petits problème s'accumulent, et quand enfin on fait un check-up, on ne peut que constater la perte de nos aptitude.

Mais point de fatalisme dans le diagnostic. Après tout, tant que nos composants sont intacts, que les électrons circulent dans nos circuits et que l'on ne reboote pas tous les matins, on peut s'estimer heureux et apprécier de voir le soleil se lever tous les jours (derrière la porte du placard qui nous protège de la poussière).

Oui je parle toujours du PC, suivez un peu.

Quelque chose de spécial pour ses trois ans donc. Quand j'ai acheté cette machine en 2010 c'était déjà une antiquité malgré son plastique rutilant.

Un peu comme acheter une 2CV neuve aujourd'hui : elle pourra toujours vous conduire d'un point A à un point B mais faire 800 Km d'autoroute dans la journée va sérieusement compliquer les choses (loin de moi l'idée de me moquer des 2CV, j'adore cette voiture). Avec son Atom 230 de toute première génération, son giga de RAM et son chipset réseau Ethernet 100, il n'était pas étonnant que des opérations telles que du transcodage et du multi-processus important avec des applications Java, le tout avec une sollicitation réseau parfois forte, ressemblent aux 800 Km d'autoroute en 2CV !

C'est la raison pour laquelle j'ai presque immédiatement ajouté des jantes alu et un spoiler... je veux dire, un giga de RAM supplémentaire et une carte réseau gigabit pour parer au pics de charge.

Cette configuraion s'est révélée suffisante dans la plupart des situations pendant trois ans, et lorsque je voyais que certains programmes amenaient l'aiguille dans le rouge, dans le meilleur des cas je pouvais paramétrer les ressources allouées et limiter la casse. Sinon je me faisais une raison et supprimais simplement le programme en question (ce fut notamment le cas de Yacy et Freenet).

C'était loin d'être idéal évidemment, mais je m'en contentais.

Et là, c'est le drame

Puis vint le moment où je réalisai que je passais plus de temps à monitorer la charge système et déshabiller Pierre pour habiller Paul - comprendre : retirer des ressources à un programme pour les donner à un autre (Pierre et Paul sont de très bons amis mais je n'oserais jamais en déshabiller un pour habiller l'autre) - qu'à simplement faire avec ce serveur ce que j'avais justement apprécié de faire les premiers temps : l'oublier. Savourer le "juste marche". J'ai alors commencé à consulter LDLC, Materiel.net et consorts, juste pour me "faire une idée", "m'amuser", mais certainement pas pour acheter...

Et merde.

Oui je suis faible. Mais dans ma faiblitude (copyleft), j'ai quand même bien pesé le pour et le contre, hésité et retardé le passage à la caisse de plusieurs jours, afin de m'assurer de concocter la configuration la plus adaptée à mon besoin. Il était notamment indispensable que celle-ci soit au moins aussi économe en énergie que l'actuelle, voire plus économe encore. Il fallait aussi qu'elle accepte 4 Go de RAM, un des points faibles que je souhaitais améliorer. Et bien sûr, serveur oblige, il fallait qu'elle dispose d'une interface Ethernet gigabit.

La carte mère et le processeur

Après une recherche plus longue que je n'aurais pu le penser de prime abord (à croire que personne ne monte ce genre de configuration de nos jours), je suis finalement tombé sur une carte mère Asrock mini-ITX modèle AD2550-ITX qui répondait complètement à mes exigences. Celle-ci est équipée d'un processeur Atom D2550 dual-core avec hyper-threading, directement soudé dessus comme c'est d'usage pour ce type de CPU.

Le comparatif des caractéristiques fourni par Intel laisse apercevoir quelques évolutions bienvenues entre mon ancienne configuration et la nouvelle : tout d'abord on change d'architecture, de Diamondville à Cedarview. Cela se traduit par le changement du type de RAM : de DDR2-533 vers DDR3-1066. Ensuite, on gagne un core physique, soit deux cores logiques puisque le CPU supporte l'hyper-threading. La fréquence gagne 260 MHz, mais je ne m'attends pas à ressentir de grosses différences à ce niveau. Par contre le cache L2 double pour passer de 512 Ko à 1 Mo, ce qui entraîne par contre généralement une augmentation significative des performances.

Et ensuite ? Ensuite pas grand chose à vrai dire.

Les deux CPU supportent le jeu d'instructions 64-bit (heureusement !), et aucun des deux ne supporte de technologies de virtualisation (dommage). Le GPU intégré du D2550 (PowerVR SGX545) est certainement plus véloce que celui de son ancêtre mais pour une machine qui n'aura aucun écran... l'intérêt est plus que limité.

La carte mère de son côté possède un chipset Ethernet "gigabit" intégré (à la différence d'une de ses déclinaisons plus low-cost) même si je ne pense pas obtenir des performances extrêmes avec lui. Le prix est un peu au dessus de ce que j'aurais souhaité, mais bon.

À présent que le coeur de la bête est choisi, passons maintenant à ce qui va tenir les composants ensemble...

Le boîtier

Le panel de choix est ici plus vaste et on retrouve quantité de boîtiers plus designs les uns que les autres, à tous les prix. Je décide d'abord de consulter la Bible des geeks : Canard PC Hardware, CPCH pour les intimes.

J'ai justement souvenir qu'un comparatif de mini-PC avait été publié il y a quelques numéros. Bingo : c'est le n°15.

Le dossier, bien que très intéressant (comme toujours), ne présente que des boîtiers extrêmement compacts ne proposant qu'une unique baie 3,5", plus adaptés à héberger un mediacenter qu'un serveur. Nombreux sont ceux qui disposent d'une baie pour lecteur optique (totalement inutile dans mon cas) et tous imposent un agencement interne au poil de cul de mouche tellement l'espace y est compté.

Et surtout, aucun ne permet d'installer une alimentation ATX classique. C'est bien dommage car il est crucial pour moi de ne pas dépendre de formats exotiques qui ne sont pas adaptables à une tour classique et qui ne seront peut-être plus supportés dans quelques années. Il est aussi bien appréciable de pouvoir prendre un composant sur une machine pour le mettre sur une autre au besoin.

C'est finalement dans la section "Test" de ce même numéro que je trouve ce qui semble bien être mon petit Graal du moment : le boîtier Elite 120 Advanced de Cooler Master. Un prix annoncé de 45 € - donc parfaitement dans mon budget - et une note de 9/10, rien que ça !

En y regardant de plus près il s'agit d'un boîtier de 20 litres (donc bien plus volumineux que les mini-PC du dossier, qui ne dépassaient pas les 8 litres) disposant de 4 baies 3,5" (compatibles 2,5" au moyen d'adaptateurs fournis), d'un gros ventilateur de 12 cm en façade, et d'un support pour une alimentation ATX classique. Petit bonus : le cable management est bien pensé et de nombreux points d'ancrage sont disséminés à divers endroits. Parfait compromis ! J'en prends treize à la douzaine.

L'alimentation

Restait à trouver l'alimentation qui allait heu... alimenter tout ça. Connaissant la consommation de la configuration actuelle, et celle approximative des composants que j'étais en train de choisir, je savais qu'Usul II n'allait pas réclamer plus de 40W à la prise. Il fallait donc trouver une alimentation adaptée à cette consommation minimaliste.

Je ne m'appesantirai ici pas plus sur ce qu'implique cette contrainte mais sachez seulement qu'une alimentation ATX - même certifiée 80+ - ne peut assurer un rendement correct à 10% de charge. Si on considère toujours les 40W envisagés, sachant que c'est une limite plutôt haute pour la configuration, il faudrait une alimentation de 200W certifiée 80+ pour espérer obtenir ces 80% d'efficacité. On se heurte ici à un problème délicat : plus aucun constructeur ne propose d'alimentation au format standard ATX dans cette gamme de puissance. Le minimum sera plutôt de 300W, et si en plus on veut un modèle de bonne qualité testé par Canard PC, la liste se réduit à peau de chagrin.

Usul  I dispose d'un transformateur externe du type même que l'on retrouve  sur les portables car il était vendu déjà monté, avec un boîtier et une  carte mère spécifiques au modèle (photo de droite).

Là par contre je monte une configuration de zéro, donc impossible d'envisager la réutilisation du transfo existant : la carte mère Asrock que j'ai choisie exige le branchement d'un câble sur son port ATX pour fonctionner.

Mais je me rappelle alors qu'un nouveau type d'alimentation de faible puissance avait justement été testé par Canard PC (toujours eux !) et avait reçu un avis plus qu'élogieux : le PicoPSU. Tiens, c'est d'ailleurs à la fin du dossier sur les mini-PC dans ce même numéro !

Ils y annoncent un rendement de 88% à 60W, un ripple très bas, et bien sûr la compatibilité avec toutes les cartes mères ATX. Seul problème évoqué et que j'ai rapidement pu constater moi-même : la disponibilité en France : quasi-nulle.

Après hésitation sur des sites allemands et anglais, c'est finalement sur le site américain de Mini-Box (qui semble d'ailleurs être le constructeur du PicoPSU) que j'ai commencé à lorgner. J'ai opté pour le kit "PicoPSU-80 + Adaptateur 60W" à 35 $.
Et la livraison en France ? 36 $. Bim. Ramené en Euros, le total passe néanmoins à  54 € environ, ce qui représente un prix moyen pour une alimentation classique hors frais de port. Je tente donc le coup.

Le reste

Pour la RAM, j'ai simplement choisi la barrette de marque la moins chère en SO-DIMM DDR3, en 4 Go évidemment puisque le but était notamment d'augmenter sa capacité par rapport à Usul I. Mon choix s'est donc porté sur une barrette Crucial premier prix, toujours vendue par LDLC (autant grouper pour éviter les frais de port à rallonge) et prévue pour... Mac.

Gné ?

Oui ben c'est une barrette SO-DIMM de DDR3 quoi, qu'elle soit pour Mac ou non je ne vois pas le rapport. Bref.

Pour les disques dur, je vais réutiliser ceux qui équipent déjà mon serveur, et mon objectif ici sera bien entendu de ne pas avoir tout à réinstaller. Mais avec Debian, je pars confiant.

Tout est prêt, je lance les commandes sur les deux boutiques pour un montant total d'environ 200€ (raisonnable non ?) et guette le facteur...

La configuration attendue tiendra-t-elle ses promesses ? Debian acceptera-t-elle le transfert vers une nouvelle plateforme matérielle ? La couche d'ozone sera-t-elle sauvée grâce à la réduction de la consommation énergétique engendrée ? Brooke avouera-t-elle à Bill qu'elle l'aime quand bien même elle porte l'enfant de Sharon qui est sa nièce par alliance ?

Toutes ces réponses et bien d'autres, dans la prochaine partie de cette saga épique !

EDIT : Voir la deuxième partie ici !

Bien marrant, et assez réussi je dois dire ! (en profane que je suis)

Je pense que je vais me mettre au Kitty Metal, ça a l'air trop bien !

Source : http://cheezburger.com/53761281

>> Aller directement au téléchargement <<

Il y a quelques temps, j'ai réalisé que certains de mes dossiers contenaient parfois de nombreux exemplaires du même fichier. Jusque-là rien d'étonnant. Mais après un rapide nettoyage manuel, j'ai aussi réalisé que cela me prenait pas mal de place et que la méthode manuelle d'élimination était assez laborieuse !

Oui, rien d'étonnant non plus en fait.

Toujours est-il que même en achetant régulièrement de nouveaux disques, il est contre-productif d'entasser des centaires de doublons numériques de ses fichiers.

Je me suis mis alors à chercher un logiciel - libre, et multi-plateforme - qui permettait de parcourir des dossiers en détectant les doublons dans leur contenu. Chose importante, je souhaitais également que l'affichage permette de déterminer rapidement quel est LE fichier à conserver, et de supprimer tous les autres. Utilisant régulièrement la recherche de doublon de XnView ou d'autres logiciels similaires, je savais au moins ce que je ne voulais pas : quelque chose se voulant simple mais se révélant trop laborieux à utiliser.

Et surtout : la présence de cases à cocher serait rédhibitoire, ni plus ni moins. Il n'y a rien de pire que de devoir cocher un par un tous les fichiers que l'on souhaite supprimer.

Avec des contraintes aussi fortes mes recherches se sont forcément soldées par des échecs. Je me suis alors dit qu'il ne devait pas être très compliqué d'implémenter ce concept moi-même.

J'avais partiellement raison : implémenter le concept n'était effectivement pas complexe. Mais coder l'interface qui va autour s'est révélé largement plus casse-tête. Enfin, l'optimisation - de l'empreinte mémoire notamment - est également une part importante à laquelle je n'avais pas initialement pensé, et qui est pourtant indispensable (ce dernier point est d'ailleurs largement incomplet au stade actuel).

Le concept

Ma vision était de présenter les résultats sous forme d'arbre dont les branches seraient la hiérarchie des dossiers, les "feuilles" seraient les fichiers et les "sous-feuilles" les doublons de celui-ci. Un menu contextuel permettrait ainsi de supprimer en deux clics tous les doublons.

Au fil du développement, j'ai finalement opté pour un double-arbre dont les sélections seraient synchronisées de la manière suivante : en cliquant sur une sous-feuille (un doublon) dans un arbre, l'autre développerait automatiquement la branche dont ce doublon serait la feuille (le fichier de base).

Pour comprendre cela, il faut noter que les fichiers dans les arbres apparaissent plusieurs fois : une fois en tant que fichier "de base" (feuille) et ensuite autant de fois que le fichier n'a de doublons, en tant que sous-feuille de chacun d'eux.

Cas d'utilisation principal

Prenons un exemple simple : dans un même répertoire R deux fichiers A et B, et trois "doublons" A1, A2, et B1. Inutile de dire ici qui est le doublon de qui.

Le noeud représentant le répertoire R aura ainsi 5 enfants : A, B, A1, A2 et B1.

• La feuille A aura pour enfants A1 et A2.
• La feuille B aura pour enfant B1
• La feuille A1 aura pour enfants A et A2
• La feuille A2 aura pour enfants A et A1
• La feuille B1 aura pour enfant B

(l'ordre alphabétique de rigueur n'est pas respecté dans cet exemple)

Ce cas est volontairement simpliste. Dans la réalité il peut arriver que plusieurs milliers de fichiers apparaissent dans l'arbre. On obtient alors un arbre excessivement haut, et donc très difficile à parcourir.

Le but d'avoir ici deux arbres synchronisés permet de sélectionner dans le premier le fichier "doublon" (sous-feuille) que l'on souhaite conserver, ce qui sélectionne dans le second ce même fichier mais en tant que fichier "de base" (feuille). Le menu contextuel permet ensuite de supprimer l'ensemble des doublons supplémentaires en deux clics.

En reprenant l'exemple précédent, supposons que je parcoure l'arbre (supposément très haut) et analyse les doublons du fichier A. Je souhaite ne conserver que le fichier A2, et donc supprimer A et A1.

• Je clique donc sur la quatrième ligne [1].
• Le second arbre réagit instantanément à cette action et sélectionne la ligne 5 [2] (hormis celle-ci toutes les autres branches sont réduites pour faciliter la lisibilité).
• Un clic-droit sur cette ligne affiche ensuite un menu-contextuel me permettant de supprimer tous les doublons de A2 [3].
• Ceci fait, les deux arbres sont mis à jour et les branches associées à ces fichiers disparaissent.

L'intérêt de ce fonctionnement pour moi est qu'il m'est plus facile (et surtout plus rapide) de vérifier l'emplacement d'un fichier dans un arbre que dans un libellé contenant le chemin complet (du type "/chemin/vers/mon/dossier/contenant/mon/fichier/A".

Chaque nom de dossier se détache mieux, ce qui est pratique lorsqu'on a des noms de dossiers proches ("/chemin/vers/mon/dossier1/contenant/mon/fichier/A1").

Si cela n'était pas suffisamment clair, je précise que cette fonctionnalité répond à mes besoins particuliers. Mais je pense que ceux-ci ne sont pas non plus originaux au point de n'intéresser personne d'autre.

JDuplicateFinder

Pour mon développement j'ai utilisé Java et sa bibliothèque Swing, seul langage que je maîtrise suffisamment pour ne pas bloquer inutilement sur de bêtes aspects d'implémentation.

J'ai réutilisé le plugin WindowBuilder pour Eclipse afin de mettre en place rapidement les éléments de l'interface utilisateur. Je reste assez bluffé par les possibilités de ce module en terme de layouting WYSIWYG. Bien sûr, tout ne peut pas être réglé avec du D&D et des listes déroulantes, j'ai donc dû compléter certains points directement dans le code.

Fonctionnalités

Les principales fonctionnalités disponibles dans cette version 1.0 sont les suivantes :

• Recherche de doublons dans 1 à N dossiers sources
• Trois comparateurs disponibles combinables :
  • Taille de fichier
  • Digest (MD5, SHA1, etc.; taille du chunk utilisé configurable, 512 Kio par défaut)
  • Date de fichier (création ou modification)
• Définition de filtres d'exclusion sur les noms ou chemins de fichiers
• Affichage des détails des fichiers sur simple clic (nom, chemin, taille, mimetype, dates de création et modification)

Mis à part le comparateur "Digest" pour qui deux fichiers ne peuvent être que totalement similaires ou totalement différents, il est possible de définir des "marges" en octets, kibioctets, ou pourcentage pour la taille, ou en secondes, minutes, heures ou jours pour la date.

Chaque doublon trouvé possèdera donc un "score" de similiarité (sur 100) qui sera d'autant plus faible qu'il sera proche de la limite inférieure ou supérieure définies par cette marge.

Ce score est visible en préfixe dans les sous-feuilles de l'arbre, mais une icône de couleur permet également d'identifier rapidement les doublons les plus pertinents pour un fichier donné.

Chaque comparateur possède également un "poids" qui va influencer le score de comparaison des fichiers si plusieurs comparateurs sont actifs pour une même recherche. Ce score devient alors la moyenne pondérée des similarités détectées par les comparateurs.

Téléchargement

Le résultat est un JAR dont l'archive est téléchargable ici :

jduplicatefinder-1.0.zip (1,78 Mo)

Et le code source disponible sur Github :

https://github.com/nanawel/jduplicatefinder

Je n'ai pour l'instant pas pris la peine de rédiger un manuel de 300 pages pour expliquer son utilisation, mais celle-ci reste en grande partie assez intuitive :)

À noter que s'il n'est pas (encore) possible de préparamétrer les comparateurs et autres options de configuration au lancement, il est néanmoins possible de passer au JAR la liste des dossiers cibles.

Pour cela, on utilisera la syntaxe suivante :

    $ java -jar jduplicatefinder.jar "/home/user" "/tmp/folder"

sous Linux, ou

    > java -jar jduplicatefinder.jar "C:\\" "D:\\Games"

sous Windows (attention dans ce cas à bien doubler les backslashs ou à utiliser des slashs à la place).

Si la mémoire allouée par défaut ne suffisait pas (message d'erreur "Java heap space" ou autre au cours de la recherche), il est possible d'augmenter celle-ci depuis la ligne de commande :

    $ java -jar -Xmx512m jduplicatefinder.jar

pour autoriser jusqu'à 512 Mo dans cet exemple. La bonne application de ce paramètre est visible en bas à droite de la fenêtre.

J'ai effectué pas mal de tests et je considère cette version suffisamment stable pour la mettre à disposition.

Je ne peux cependant pas fournir de garanties si par malheur cela invoque les démons des Enfers, ouvre un trou noir dans votre salon ou simplement endommage certaines de vos données ! (j'ai néanmoins plus d'assurance sur ce dernier point, avouez que c'est plutôt rassurant quand même)

Si vous trouvez un bug ou avez des suggestions d'améliorations, utilisez le bugtracker mis à disposition sur Github.

Bon dédoublonage !