Si je vous en reparle aujourd’hui, ce n’est pas spécialement pour annoncer que le logiciel a fortement évolué depuis la dernière fois que j’en ai parlé sur ce blog (bien que ce soit le cas) mais c’est surtout que j’ai envie de parler de la bonne expérience que je suis en train de vivre grâce au libre.

Voici donc l’histoire:

Tout a commencé avec un script bash. Ce script, que m’avait fourni un de mes professeur à l’université, affichait les informations de la commande df(1) et y apportait un graphe montrant le taux d’utilisation des disques.

J’ai trouvé l’idée très sympa mais ai également trouvé le script limité et j’ai donc souhaité y ajouter des options. Or, l’état du code m’a assez vite effrayé et j’ai donc décidé de le ré-implémenter en C, langage que j’affectionne.

Je suis vite arrivé au résultat souhaité, à savoir afficher les principales informations fournies par df(1) et y ajouter un graphe. J’en ai parlé sur un forum et j’ai remarqué que les gens étaient plutôt intéressés par le concept. Puis, prenant particulièrement mon pied dans le développement de cet outil, j’ai décidé de lui ajouter des fonctionnalités et un peu d’agrément visuel par l’apport notamment de la couleur.

Après avoir amélioré ce programme, j’en ai parlé sur le forum anglophone de la distribution Archlinux. Les personnes l’ayant testé ont vite souhaité y voir plus de fonctionnalités, que je n’ai pas tardé à implémenter et ont également relevé plusieurs bugs que je me suis empressé de corriger.

J’en suis finalement arrivé à une version que je trouvais relativement mature et je me suis dit que plutôt que de garder cet outil pour moi, j’allais en parler un petit peu afin de pouvoir en faire profiter d’autres. C’est dans cet esprit que j’ai proposé une dépêche sur linuxfr dimanche passé et qui a été publiée le 1er avril (un lecteur de linuxfr a d’ailleurs cru à un poisson d’avril :P).

J’étais très loin d’imaginer l’enthousiasme que lèverait cette dépêche! Peu après la parution de l’article, j’ai été contacté par de nombreuses personnes. L’une proposant une amélioration, l’autre relevant un bug ou encore d’autres proposant des patchs (port du code vers FreeBSD notamment).

J’ai maintenant appris que dfc(1) sera vraisemblablement intégré dans les dépôts de la future Mageia, se trouve déjà dans les ports FreeBSD et s’apprête à rejoindre les dépôts de Frugalware et peut-être même ceux de Fedora!

Sincèrement, j’étais bien loin de m’imaginer tout cela lorsque j’ai commencé à taper quelques lignes de code il y a une quinzaine de jours sur mon portable…

Je souhaitais surtout relever à travers cet article le super esprit du libre qui a permis l’amélioration de dfc(1) en raisons de nombreuses contributions d’utilisateurs sous des formes variées. Et sincèrement, je souhaite tous les remercier. Bref, pour moi c’est une expérience personnelle extrêmement positive concernant les avantages du libre!

Pourquoi? Pour le fun surtout. Enfin, pour situer un peu l’histoire, il s’agit en fait à la base d’une implémentation en C de ce que fait un script bash que m’avait gentiment fourni un de mes professeurs à l’université. J’avais souhaité y apporter quelques changements mais j’avoue avoir un peu pris peur face à l’aspect du script bash.

Au final, j’y ai ajouté pas mal d’options et plusieurs autres sont prévues. Pour voir lesquelles, il suffit de consulter la roadmap sur le site officiel. Assez écrit, voilà à quoi cela ressemble:

1
2
3
4
5

FILESYSTEM TYPE     USED (*)      FREE (-) %USED       AVAILABLE           TOTAL MOUNTED ON
/dev/sdc1  ext4     [************--------]   57%    12989202432B    29941719040B /
/dev/sda7  ext2     [****----------------]   16%       84393984B       99997696B /boot
/dev/sda3  ext4     [*************-------]   63%   138229665792B   370028589056B /home
/dev/sda5  reiserfs [**************------]   68%     4315811840B    13489512448B /var

Et les options disponibles pour la version actuelle (1.1.3):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Usage: dfc [OPTIONS(S)]
Available options:
  -a  print all fs from mtab
  -h  print this message
  -g  size in Gio
  -G  size in Go
  -k  size in Kio
  -K  size in Ko
  -m  size in Mio
  -M  size in Mo
  -n  do not print header
  -s  sum the total usage
  -t  hide filesystem type
  -v  print program version
  -w  use a wider bar

Ce qui peut donner, en combinant plusieurs options (résultat de dfc -wags):

1
2
3
4
5
6
7
8
9
10
11
12

FILESYSTEM TYPE     USED (*)                                    FREE (-) %USED AVAILABLE   TOTAL MOUNTED ON
rootfs     rootfs   [*****************************---------------------]   57%     12.1G   27.9G /
/dev       devtmpfs [--------------------------------------------------]    0%      3.8G    3.8G /dev
run        tmpfs    [*-------------------------------------------------]    0%      3.8G    3.8G /run
/dev/sdc1  ext4     [*****************************---------------------]   57%     12.1G   27.9G /
shm        tmpfs    [*-------------------------------------------------]    0%      3.8G    3.8G /dev/shm
tmpfs      tmpfs    [*-------------------------------------------------]    0%      6.0G    6.0G /tmp
/dev/sda7  ext2     [********------------------------------------------]   16%      0.1G    0.1G /boot
/dev/sda3  ext4     [********************************------------------]   63%    128.7G  344.6G /home
/dev/sda5  reiserfs [***********************************---------------]   68%      4.0G   12.6G /var
/dev/sdb1  ext4     [*************************************-------------]   73%     81.3G  297.8G /mnt/Videos
SUM:                [*********************************-----------------]   65%    255.7G  728.2G

Pour les détails concernant l’utilisation, il suffit de consulter la manpage dfc(1).

Pour les archers, j’ai crée un paquet sur AUR ici. On retrouve également le paquet sur le dépôt archlinuxfr puisque je fais maintenant partie des mainteneurs.

Je profite de l’occasion pour prévenir les quelques personnes utilisant mon dépôt rolinh qu’il sera fermé puisque les paquets se trouvant actuellement dessus vont finir sur le dépôt archlinuxfr où je continuerais de les maintenir.

Pour ceux n’étant pas utilisateurs d’Archlinux mais qui sont quand même intéressés par dfc, il est toujours possible de l’installer manuellement. Pour cela, il suffit de télécharger la dernière archive contenant les sources (ici), de la décompresser, puis, depuis le répertoire obtenu, de lancer les commandes suivantes via le terminal: make pour le construire et make install (en root) pour l’installer (par défaut, il s’installe dans /usr/local).

J’ai récemment apporté un léger changement à ce blog. Certains auront peut-être remarqué que la bulle au survol du lien vers le flux RSS affiche maintenant une information en français et que le champ de recherche en haut à droite comporte la mention “Rechercher…” et non plus “Search…”. J’avais omis ces détails lorsque j’avais déployé et traduit Octopress pour ce blog. Cependant, ce ne sont pas ici les seules modifications apportées. En effet, la recherche sur le site s’effectue maintenant par le biais de DuckDuckGo et non plus Google. Pourquoi cela? Et bien par respect pour votre vie privée. Vous n’êtes sans doutes pas sans savoir que Google est omniprésent sur le web est arrive à concentrer une quantité faramineuse de données sur vous et cela notamment via son moteur de recherche. Bref, je ne tiens pas à alimenter leur base de données de votre profil au travers de ce blog et c’est ce qui m’a poussé à effectuer ce changement. J’avais entendu parler de DuckDuckGo la première fois via LinuxFr. Dans un premier temps, j’ai simplement été intrigué puis SebSauvage est venu en remettre une couche qui a achevé de me convaincre de lui donner une chance. Cela fait donc plusieurs mois que je l’utilise et comme je l’ai trouvé convainquant, j’ai trouvé qu’il ferait un bon remplaçant à Google pour ce site.

Ceci dit, vous me direz que c’est aberrant de parler du respect de votre vie privée et de continuer d’utiliser Google Analytics. Inutile de vous dire que lui aussi va disparaitre et ce probablement au profit de Piwik. Seulement voilà, pour l’instant il ne me donne aucunes statistiques et je n’ai pas eu le temps de me pencher sur le problème afin de savoir pourquoi.

Dans un tout autre registre, j’ai mis en place un ChiliProject pour mes divers projets de programmation. Pour ceux n’étant pas au courant, ChiliProject est un fork au développement dynamique de Redmine qui se révèle être extrêmement simple à déployer (au contraire de ce dernier…). Il s’agit donc d’une plateforme complète comprenant notamment un visualiseur de dépôts (git dans mon cas), un wiki, une page de nouvelles, un bug tracker, etc. Bref, un outil vraiment complet pour gérer des projets que je vous invite à retrouver ici.

D’ailleurs, je partage cet outil avec mon ami Gilliek qui vient ce soir même de finir la version 1.0 de son projet de gestion de DVDs en mode web nommé MyDVD. Il s’agit d’une application Rails permettant de recueillir des informations à propos des films de sa DVDthèque (bandes-annonces, synopsis, etc.) et de les visionner dans un navigateur web grâce à HTML5. L’idée est donc de stocker ses films sur un ordinateur faisant office de serveur de films les rendant ainsi accessibles depuis n’importe quel appareil disposant d’un navigateur internet dans sa maison. Je précise maison car je doute que beaucoup de monde dispose d’une bande passante suffisante chez lui pour permettre le streaming sur internet. Néanmoins, ceci est bien évidemment possible si cette condition est remplie. Les prochains développement concerneront le support des langues (pour le moment, seul le français est disponible) et une fonction de recherche améliorée.

De mon côté, je profite également de ChiliProject pour ma bibliothèque de widgets pour Awesome (Precious), pour le gestionnaire de copies LinCopier qui a profité de l’occasion pour se débarrasser de SourceForge.Net et enfin pour Rubyckup, un outil de backups pour serveurs écrit en Ruby.

Après avoir un peu parcouru la toile, je suis tombé sur un script de conversion conservant ces tags et basé sur les outils faad, lame et id3v2.

Je l’ai adapté à ma sauce afin notamment de supprimer les fichiers M4A originaux une fois la conversion effectuée. Lame n’étant pas optimisé pour les processeurs multicoeurs, l’opération de conversion peut prendre un certain temps en fonction du nombre de fichiers à convertir. Bref, il faut être patient.

Le script cherchant les fichiers M4A dans le dossier courant, il est préférable de le lancer à partir du dossier contenant votre collection de fichiers musicaux.

Alors oui, c’est du bash donc moche et lent mais je l’ai utilisé pour convertir pas moins d’une centaine de morceaux et j’ai été vraiment content du résultat. Bref, je partage car ça peut toujours servir.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

#!/bin/bash
# converts m4a files to mp3
# song tags should be preserved

if ! which faad >/dev/null; then
  echo "faad executable not found." >&2;
  exit 1;
fi
if ! which lame >/dev/null; then
  echo "lame executable not found." >&2;
  exit 1;
fi
if ! which id3v2 >/dev/null; then
  echo "id3v2 executable not found." >&2;
  exit 1;
fi

echo -n "Delete m4a file(s) after conversion?(y/n) "
read yn
case $yn in
  y|yes)
      echo -e "All right $USER, m4a files will be removed."
      del=0
      ;;
  *)
      echo -e "Ok $USER, m4a files will be preserved."
      ;;
esac

echo -e "\nBe patient if you convert lots of file."

while read m4afile; do

  mp3file=$(echo "$m4afile" | sed s/\.m4a/.mp3/g)
  ARTIST=$(faad -i "$m4afile" 2>&1 | grep '^artist: ' | sed 's/^artist: //')
  TITLE=$(faad -i "$m4afile" 2>&1 | grep '^title: ' | sed 's/^title: //')
  ALBUM=$(faad -i "$m4afile" 2>&1 | grep '^album: ' | sed 's/^album: //')
  GENRE=$(faad -i "$m4afile" 2>&1 | grep '^genre: ' | sed 's/^genre: //')
  TRACKNUMBER=$(faad -i "$m4afile" 2>&1 | grep '^track: ' | sed 's/^track: //')
  DATE=$(faad -i "$m4afile" 2>&1 | grep '^date: ' | sed 's/^date: //')
  COMMENT=$(faad -i "$m4afile" 2>&1 | grep '^comment: ' | sed 's/^comment: //')
  CONGROUP=$(faad -i "$m4afile" 2>&1 | grep '^contentgroup: ' | sed 's/^contentgroup: //')
  COMPOSER=$(faad -i "$m4afile" 2>&1 | grep '^writer: ' | sed 's/^writer: //')
  PERFORMER=$(faad -i "$m4afile" 2>&1 | grep '^performer: ' | sed 's/^performer: //')
  ALBARTIST=$(faad -i "$m4afile" 2>&1 | grep '^album_artist: ' | sed 's/^album_artist: //')

  echo -en "\n$ARTIST / $ALBUM [$DATE] / $TRACKNUMBER - $TITLE"
  echo -en "\nConverting *$(basename "$m4afile")* to *$(basename "$mp3file")* ..."
  faad -q -o - "$m4afile" 2>/dev/null | lame -m j -q 0 --vbr-new -V 0 -s 44.1 - "$mp3file" 2>/dev/null

  id3v2 -t "$TITLE" -T "${TRACKNUMBER:-0}" -a "$ARTIST" -A "$ALBUM" -y "$DATE" -g "${GENRE:-12}" -c "$COMMENT" --TORY "$DATE" --IPLS "$ALBARTIST" --TCOM "$COMPOSER" --TIT1 "$CONGROUP" --TIT2 "$TITLE" --TOPE "$PERFORMER" --TPE1 "$ARTIST" --TPE2 "$ALBARTIST" --TRCK "$TRACKNUMBER" "$mp3file" 2>/dev/null

  if [[ ${del} ]]; then
      rm -v "$m4afile"
  fi

done < <(find . -iname '*.m4a' -or -iname '*.M4A')
echo -e "\nConversion complete!"

PS: j’ai trouvé un workaround pour mes soucis de coloration syntaxique. C’est pour l’instant assez moche mais mieux que rien… en attendant la résolution du bug upstream.

Presque tout le matériel est très bien reconnu par Linux dans l’ensemble mais il subsiste quelques détails: le bouton permettant d’activer/désactiver le microphone ne fonctionne pas*, le son des haut-parleurs est relativement faible et ne marche carrément pas du tout via la sortie jack de la docking station. Enfin, ne marchait pas aurais-je dû dire car pour ces deux derniers points j’ai trouvé la solution et elle est extrêmement simple à mettre en place.

Il suffit d’éditer /etc/modprobe.d/modprobe.conf et d’y ajouter cette ligne:

options snd-hda-intel model=thinkpad

Le module est ainsi chargé avec les bons paramètres et permet ainsi au son de fonctionner via le jack du dock et de gagner légèrement en volume à travers les haut-parleurs intégrés au portable. Il est à noter que cette astuce est sûrement valable pour les autres Thinkpad et adaptable à d’autres configurations.

* N’utilisant pas de microphone, je n’ai même pas cherché s’il existait une solution. De même, je n’ai jamais testé le lecteur d’empreintes digitales car je ne m’en servirais de toute façon pas.

Seulement voilà: il m’arrive d’installer des paquets depuis AUR et cela passe souvent par une compilation. Évidemment, l’ensemble d’excellents outils fournis avec Archlinux (pacman, makepkg, PKGBUILD) facilitent énormément la tâche de création de paquets mais seulement voilà, compiler sur un netbook disposant d’un faible Intel Atom N280 en guise de processeur est loin d’être une joie. Surtout lorsque l’on possède une belle machine comme la mienne pour compiler!

L’idée est donc de compiler le paquet sur mon Lenovo et de le rendre disponible pour le netbook par la suite. Seulement voilà: mon Lenovo possède une Archlinux 64-bit alors que le netbook, processeur 32-bit oblige, une Archlinux 32-bit et par conséquent les paquets ne sont pas compatibles.

La solution? Créer un paquet 32-bit depuis l’installation 64-bit. Pour cela, il faut évidemment passer par un chroot 32-bit.

Cela pourrait être un vrai chemin de croix pour certains mais en fait le travail est facilité par des outils très pratiques. Voici comment procéder dans le détail.

Il faut commencer par créer le répertoire devant contenir notre chroot. Le faire dans /opt avec un nom parlant est une bonne idée:

sudo mkdir /opt/arch32

Les outils dont nous avons besoin sont fournis dans le paquet devtools. Alors installons le:

sudo pacman -S devtools

Ceci fait, on va copier notre existant pacman.conf dans notre dossier de chroot:

sudo cp /etc/pacman.conf /opt/arch32

On va également avoir besoin du makepkg.conf. Celui-ci possèdant une configuration spécifique à l’architecture, on va prendre celui par défaut pour 32-bit fournis avec le paquet devtools:

sudo cp /usr/share/devtools/makepkg-i686.conf /opt/arch32

Ceci fait, il nous faut éditer /opt/arch32/pacman.conf afin d’être certain qu’il ne contienne pas de référence à du 64-bit. Il faut changer cette ligne:

Architecture = auto

Pour celle-là:

Architecture = i686

Il faut également être sûr que le dépôt multilib n’est pas activé ainsi que tout autre dépôt uniquement 64-bit sous peine de faire foirer le chroot.

Et c’est maintenant que s’applique la magie des beaux outils. La commande suivante va configurer le chroot et installer tout ce qu’il nous faut comme paquets afin de pouvoir en créer un:

sudo mkarchroot -C /opt/arch32/pacman.conf -M /opt/arch32/makepkg.conf /opt/arch32/root base base-devel sudo

Cela peut évidemment prendre un peu de temps en fonction de votre connection internet.

Une fois ceci fait, il faut copier le PKGBUILD du paquet que l’on veut créer quelque part dans notre chroot. Mettons que l’on veuille compiler le paquet xfwm4-tiling, disponible sur AUR, on va créer le dossier /opt/arch32/aur/xfwm4-tiling et y mettre les fichiers nécessaires dedans (PKGBUILD et éventuels autres fichiers nécessaires). Il faut ensuite se rendre dans le dossier contenant le PKGBUILD (dans notre exemple /opt/arch32/aur/xfwm4-tiling) et lancer la commande suivante:

sudo makechrootpkg -c -r /opt/arch32

Et après un petit moment: tadaaa, voilà le paquet 32-bit créé! Et oui, c’est aussi simple que ça!

Si vous comptez réutiliser votre chroot plus tard, la commande suivante suffit afin de s’assurer que notre chroot est bien à jour:

sudo mkarchroot -u /opt/arch32/root

Alors, ils ne sont pas beau les outils Archlinux?

En visitant mon blog hier ou ce matin, vous avez pu constater que les commentaires étaient gérés par disqus. Comme je l’ai expliqué, ce site est utilise maintenant Octopress et est purement statique. Par conséquent, il n’est pas possible d’interagir de manière dynamique avec le site autrement qu’en passant par des scripts.

Seulement voilà: utiliser disqus n’est pour moi pas une solution. Pourquoi?

• Je suis dépendant de disqus.com. Si le site ferme ou que le service devient payant, je suis cuit.
• Disqus est lourd: il charge beaucoup de scripts et cela rend les pages plus lentes à l’affichage. Ceci est bien dommage alors qu’un des intérêts d’avoir un site statique est justement la rapidité d’affichage.
• Disqus ne respecte pas votre vie privée. Et moi j’y tiens! En effet, grâce à la pratique extension de Firefox nommée Ghostery, j’ai fait le constat que disqus chargeait des scripts externes:
  • Quantcast: collecte des données anonymes (type de navigateur, url de référence, etc.) et partage avec des entreprises.
  • ScoreCard Research Beacon: collecte des données anonymes (type de navigateur, OS, etc.) ET des adresses IP partielles. Tout cela est bien sûr également partagé…
• Il est difficile de récupérer les commentaires de disqus. On peut les exporter sous un format XML mais il aurait été très difficile pour moi de les convertir en commentaires pour octopress le jour où j’aurais voulu m’affranchir de ce service.

Bref, suffisament de raisons pour ne pas l’utiliser!

Je tiens fortement à migrer les anciens commentaires et trouver un nouveau système (probablement concocté par mes soins) afin de les rétablir car je les apprécie; qu’ils soient une remarque, un avis, un encouragement ou une critique: ils sont tous intéressants.

Cependant, cela risque de me prendre un peu de temps: je suis en période d’examens universitaires et je n’ai pas encore une solution en tête. Je vous prie donc de m’en excuser.

Si en attendant vous tenez à me faire part d’un commentaire, d’une critique, d’une question ou autre, il faudra passer par le formulaire de contact (que je dois encore mettre en place :-P ).

Première chose à savoir pour ceux qui me suivent via le flux RSS: mon flux RSS a changé d’URL. Désormais, il faut pointer sur http://blog.rolinh.ch/atom.xml (oui, le lien se trouve toujours en haut à droite du blog).

Pourquoi avoir migré? C’est bien simple: Wordpress ne me correspondait pas du tout. J’aime bien la philosophie KISS, fortement suivie par Archlinux d’ailleurs, et Wordpress va complètement à l’encontre de cette idée. Il intègre beaucoup trop de fonctionnalités dont je me fous comme de l’an 40 et est finalement devenu un CMS complet plutôt qu’un simple moteur de blog.

Octopress est à des années lumières de la philosophie de Wordpress. Le site que vous avez maintenant sous les yeux n’est constitué que de pages statiques. Oui, cela veut dire pas de bases de données ni besoin de faire tourner php ou autre sur le serveur: le site est purement statique. Cela comporte des avantages mais également des inconvénients.

Parmi les avantages, le principal est la rapidité: l’affichage est quasiment instantané. On pourrait aussi avancer le fait que cela renforce la sécurité puisque le site n’est pour ainsi dire pas piratable.

Et pourtant, ce n’est pas pour ces raisons que j’ai choisi Octopress:

• je peux bloguer avec mon éditeur de texte favori…
• … en utilisant la syntaxe markdown
• le site se génère et déploie sur le serveur via une collection d’outils ruby
• je gère mon blog dans un dépôt git
• la coloration syntaxique du code est bien gérée (quoique je fais face à un bug spécifique à archlinux pour le moment qui m’empêche d’en profiter)
• le thème de base est très réussi

Alors évidemment, cela a aussi ses inconvénients. Le site étant entièrement statique, je ne dispose même pas d’un formulaire de contact. De même, le système de commentaires passe pas un module externe (en l’occurence disqus) et cela ne me plait pas trop. Je tâcherais tout de même de trouver une solution dès que j’aurais un peu de temps. J’espère que cela ne vous importune pas trop.

Bref, cette migration m’a quand même pris un peu de temps et certaines choses ne sont pas encore en place. Néanmoins, je suis plutôt content du nouvel aspect du blog. Je suis parti du thème de base et l’ai modifié à ma guise afin d’avoir quelque chose qui me corresponde. Pour ceux qui consultent le blog depuis un petit écran (téléphone mobile), le thème s’occupe de produire un affichage correct donc il n’y a pas de régression de ce côté là. J’ai également dû le traduire donc si vous voyez des mots qui sont encore en anglais, merci de me le signaler afin que je corrige.

Il reste encore des liens morts et autres choses dans le genre mais je vais tâcher de remédier également à ces problèmes au plus vite.

Je suis donc désolé pour les désagréments que ça peut vous causer mais il ne devrait pas trop y en avoir quand même. Et si ce foutu système de commentaires se décide à fonctionner, je serais ravi d’avoir votre avis à propos de ce changement!

PS: rhâââââ, bloguer avec $EDITOR c’est un pur bonheur quand même!

En faisant une brève recherche sur internet, on peut trouver une foule de zshrc configurés pour afficher des informations en fonction du dépôt de VCS parcouru. Certaines solutions ne gèrent qu’un VCS, d’autres plusieurs, certaines affichent les informations de manière sobre, d’autre le font de manière plus excentrique, certaines nécessitent des scripts (oui, oui, je suis tombé sur une solution qui nécessitait un script python!). Bref, on trouve de tout et il est difficile de s’y retrouver pour faire un prompte à sa sauce.

J’ai finalement découvert que zsh possède un module nommé vcs_info permettant justement de gérer les dépôts de VCS. Il s’agit d’une contribution utilisateur et toute la doc nécessaire afin de configurer cela à votre guise se trouve ici. Décidément, zsh ne cessera pas de me surprendre!

Afin d’aller un peu plus vite, je me suis basé sur ces deux articles très bien fait: mercurial info on your zsh prompt et git info in your zsh prompt. Je peaufinerais probablement un peu ma configuration dans un avenir proche mais néanmoins voici comment j’ai procédé:

• ajout de ces lignes à mon zshrc afin de ne charger que git et mercurial de vcs_info puisque de toute façon je n’utilise pas d’autres VCS dans les projets auxquels je participe:

  autoload -Uz vcs_info zstyle ':vcs_info:*' enable git hg

• personnalisation de vcs_info avec zstyle (j’ai pompé et modifié la configuration trouvée ici afin de ne pas afficher trop d’informations)

• ajout de vcs_info dans la fonction precmd
• affichage des informations dans RPS1 (pour rappel, il s’agit de la partie du prompt affichée tout à droite)

Curieux de savoir à quoi ça peut ressembler?

Dans un dépôt mercurial:

Dans un dépôt git:

N’oubliez pas que vous pouvez trouver mon zshrc dans mon dépôt de configurations. ;)

Le problème est on ne peut plus simple: comment appliquer une certaine configuration d’écran de manière automatique lorsqu’un autre écran est détecté.

Dans mon cas, j’utilise un portable et dispose d’une station d’accueil à laquelle est relié un moniteur. Lorsque je suis en déplacement,  le seul écran disponible est celui du portable lui-même (logique…) mais lorsque je suis chez moi, je dispose d’un deuxième moniteur relié en VGA à ma station d’accueil. Lors du démarrage de ma session Awesome wm, les deux écrans sont par défaut en configuration clone, ce qui m’est relativement inutile. Avant mon astuce, je lançais un petit script utilisant xrandr manuellement afin que mes deux écrans soient configurés correctement. Voilà une astuce afin d’automatiser cela.

La commande xrandr, passée sans argument, permet de connaître les écrans connecté à la machine. Exemple de sortie:

Screen 0: minimum 320 x 200, current 2880 x 1024, maximum 8192 x 8192
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1600x900       60.0*+   40.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        59.9
VGA1 connected 1280x1024+1600+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   76.0     75.0
   1152x864       75.0
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3
   640x480        72.8     75.0     66.7     60.0
   720x400        70.1

On voit donc dans mon cas que j’ai deux écrans connectés: LVDS1, qui correspond à l’écran de mon portable, et VGA1 qui correspond à l’écran externe branché en VGA. Lorsque ce dernier est connecté à mon portable, je souhaite configurer mon affichage en conséquence. Rien de plus simple: il suffit d’éditer le fichier $HOME/.xinitrc et de lui ajouter ces quelques lignes:

1
2
3
4
5

# apply dual-screen configuration when VGA is connected
xrandr | grep "VGA1 connected"
if [ $? -eq 0 ]; then
        xrandr --output LVDS1 --mode 1600x900 --pos 0x0 --rotate normal --output VGA1 --mode 1280x1024 --pos 1600x0 --rotate normal
fi

Évidemment, ceci est à adapter en fonction de votre configuration mais une fois ceci fait, la configuration spécifique lorsque les deux écrans sont connectés est automatiquement chargée lors du lancement de la session.

Bref, une des difficulté avec nginx se trouve être ce qui concerne les script CGI. Vous allez vite comprendre pourquoi.

Je voulais rendre public et accessible via une interface web mon dépôt git contenant mes configurations de programme. Naturellement, j’ai d’abord pensé à utiliser gitweb, qui est installé avec la “suite” git. Or, celui-ci étant écrit en perl ne facilite en rien les choses… Il aurait fallu utiliser un wrapper et pas mal bidouillé afin de le faire fonctionner. Ce n’est donc pas impossible mais je ne trouvais pas cela très propre. J’ai donc cherché une alternative simple à mettre en place et c’est là que je suis tombé sur gitphp.

Enfin bon, avant de publier ses dépôts sur un site web, il est intéressant de les rendre accessible en lecture pour tout le monde. Pour cela, avec git vient git-daemon. Comme son nom l’indique, il s’agit d’un daemon et il esst justement prévu pour ça. Au préalable, il ne faut pas oublier d’ouvrir le port 9418, qui est le port utilisé par défaut et éditer le git-daemon.conf (/etc/conf.d/git-daemon.conf chez Archlinux) au préalable. Chez moi, il ressemble à ceci:

# path to git repositories served
GIT_REPO="/srv/gitosis/repositories/"
# see `man git-daemon` for all available options
# $GIT_REPO will be present twice in most configs
GIT_DAEMON_ARGS="--detach --verbose --base-path=$GIT_REPO"

Comme il l’est écrit au-dessus, un man git-daemon permet dans savoir plus sur les options. Par la suite, à moins que vous ayez choisit l’option _ –export-all_, vous allez devoir rajouter un fichier spécial dans le dépôt. Celui-ci indique à git-daemon que le dépôt doit être exporté:

cd /chemin/vers/le/depot.git
touch git-daemon-export-ok

Voilà, normalement, dès à présent, vos dépôts sont clonables en lecture-seule via un:

git clone git://monserver.org/depot.git

Reste maintenant à installer gitphp et le configurer. S’agissant d’un site en php, voilà comment simplement créer un hôte virtuel avec nginx:

# gitphp
    server {
        listen 80;
        server_name git.rolinh.ch;
        root    /srv/http/rolinh/git;
        index   index.php;  
        location / {
            try_files $uri $uri/ /index.php?q=$uri&$args;
        }  
        location ~ .php$ {
            fastcgi_split_path_info ^(.+.php)(/.+)$;
            include                 fastcgi.conf;
            fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /srv/http/rolinh/git/$fastcgi_script_name;
            fastcgi_cache_valid any 1m;
            fastcgi_intercept_errors on;
        }
    }

Évidemment, il faut adapter à votre configuration et celle-ci est prévue pour fonctionner avec php-fpm (voir la doc Archlinux pour informations). Il est nécessaire que posix.so soit activé dans php donc si ce n’est pas fait, il faut éditer le php.ini en conséquence. Ensuite, il faut télécharger et décompresser gitphp dans le répertoire prévu (il est normalement disponible ici).

Ceci fait, il faut encore le configurer. Dans le dossier config se trouve le fichier de configuration de base que l’on peut modifier à sa guise. Toutes les options disponibles sont visible dans gitphp.conf.defaults.php. Il vous faudra au minimum les options suivantes:

/*
 * projectroot
 * Full directory on server where projects are located
 */
$gitphp_conf['projectroot'] = '/srv/gitosis/repositories/';
/*
 * exportedonly
 * When listing all projects in the project root,
 * (not specifying any projects manually or using a project list file)
 * set this to true to only allow repositories with the
 * special file git-daemon-export-ok (see the git-daemon man page)
 */
$gitphp_conf['exportedonly'] = true;

Si les dépôts ne s’affichent pas, vérifiez bien que l’utilisateur web a bien accès en lecture au dossier contenant les dépôts git.

Pour un exemple de tout ceci en action: http://git.rolinh.ch/.

NB: cet article est inspiré partiellement par celui-ci: http://blog.hokietux.net/?p=247 très bien fait qui explique comment configurer gitphp.

J’avais déjà un dépôt public du temps où j’utilisais mercurial et que ce site était auto-hébergé mais je n’avais pas encore pris le temps de remettre tout cela en place. C’est désormais chose faite. Pour info, l’interface web est gitphp. J’ai décidé de l’utiliser plutôt que gitweb car c’était toute une histoire pour faire fonctionner ce dernier avec nginx, mon serveur web (en raison de perl). Au final, l’interface est très similaire avec quelques plus (bulles au survol de la souris, etc.) donc je pense que je vais m’en contenter.

Je compte également remettre un peu d’ordre sur ce site et procéder aux changements suivant:

• supprimer la rubrique Apps puisque de toute façon je ne l’ai pas touchée depuis la première version de ce site il y a maintenant un peu plus d’un an
• ajouter une rubrique avec les liens vers mes différents dépôts

Si vous vous opposez  à l’un ou l’autre de ces changements, merci d’argumenter. ;)

Je tâcherais aussi de migrer ce blog sur Octopress mais je n’ai guère le temps de le faire en ce moment puisqu’il faut encore que je créé un thème, trouve une solution pour un système de commentaires, etc.

EDIT:

j’ai oublié de préciser comment cloner le dépôt alors voilà la commande nécessaire:

git clone git://rolinh.ch/dotfiles.git

D’ailleurs, j’ai également oublié de mentionner le fait que j’ai écrit un petit script qui permet de lier les fichiers de configuration sur sa machine. Le script est assez simple. En fait, il suffit de mettre dans les tableaux t_config et t_hconfig les fichiers de configuration que l’on souhaite utiliser et de lancer le script. Si un fichier de configuration existe déjà, alors il est demandé si l’on veut l’écraser par un lien symbolique qui pointe vers l’endroit du fichier de configuration dans le dépôt. Je trouve cela super pratique car comme ça, mes fichiers de configuration sont synchronisés automatiquement entre mes différents PC. De même, si on me créé un compte sur une nouvelle machine linux, je me sens tout de suite comme chez moi puisqu’il me suffit de cloner le dépôt et de lancer le script pour retrouver tous mes programmes favoris configurés comme je les aime.

Le problème est connu mais ne devrait être corrigé que dans la version 3.3 du noyau. Une des causes est due à une non-détection automatique du PCI-Express Active State Power Management (PCI-E ASPM). En attendant le noyau 3.3, on peut forcer son activation en ajoutant une option à la ligne de boot du noyau dans GRUB de sorte qu’elle ressemble à ça (pour grub-legacy):

kernel /vmlinuz-linux root=/dev/sda6 ro pcie_aspm=force

Mais ce n’est pas tout! En effet, d’autres options, qui étaient activées par défaut auparavant,  se sont vues désactivées. Ces options ne seront utiles que si vous utilisez le pilote libre Intel. C’est mon cas avec l’Intel Core i7-2620M de mon portable et son HD3000 intégrée. La raison de leur désactivation serait dues à certains bugs rencontrés parfois au niveau de l’affichage. Pour ma part, il n’en est rien et les performances semblent même être légèrement meilleures.

Les trois options sont les suivantes:

• i915.i915_enable_rc6=1 : permet au GPU de rentrer dans une phase de basse consommation énergétique lors d’inactivité
• i915.i915_enable_fbc=1 : compression du framebuffer
• i915.lvds_downclock=1 : diminution du taux de rafraîchissement de l’écran LVDS

A vous donc de jouer avec ces options afin de voir si certaines posent problème. Comme chez moi, tout semble bon, je les ai toutes activées. Ainsi, ma ligne de boot du noyau ressemble à ceci:

kernel /vmlinuz-linux root=/dev/sda6 ro pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1

Le résultat chez moi? Une autonomie qui arrive au même niveau que sous Windows! Je suis donc passé d’une autonomie d’environ 4h30 à une autonomie d’environ 7h30. C’est loin, très loin, d’être négligeable! De plus, mon CPU a perdu en moyenne 10°C pour se stabiliser aux alentour de 42°C quand il n’est pas trop sollicité.

Ceux souhaitant plus de détails peuvent aller consulter l’article de Phoronix sur lequel je me suis basé.

EDIT: un peu plus de détails est apparemment nécessaire.

Pour grub legacy (grub 1), il faut éditer le fichier /boot/menu.lst et ajouter les options à la ligne qui correspond à celle que j’ai donné en exemple.

Pour grub 2 (la dernière version de grub qui est notamment utilisée dans Ubuntu depuis la 9.10), les options peuvent s’ajouter en éditant /etc/default/grub et ajouter cette ligne à la fin:

GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=force"

Les options supplémentaires peuvent s’ajouter également. Une fois ce fichier modifié, il faut mettre à jour la configuration de grub 2 via la commande update-grub (pour les distributions Debian et dérivées comme Ubuntu et Linux Mint) ou grub-mkconfig (pour Archlinux),  à lancer en root évidemment. En revanche, je n’ai pas pu vérifier car je n’utilise pas grub 2. A noter qu’il existe un logiciel qui permettrait de faire cela graphiquement. Je vous laisse consulter la documentation d’Ubuntu-fr à propos de grub-customizer.

Le but: ajouter ceci au menu d’Awesome:

L’idée est d’utiliser consolekit et upower. Il faut donc évidemment que les paquets correspondant à ces programmes soient installé sur votre système. De plus, il faut également que l’utilisateur courant fasse partie du groupe power. La procédure consiste à créer 4 petits scripts shell qui seront appelés lors du clic sur le menu. Évidemment, on peut aussi s’arranger pour utiliser  une combinaison de touche qui appelle les scripts en complément mais je ne vais pas le détailler dans cet article.

On va commencer par créer un dossier nommé scripts dans le dossier de configuration d’Awesome (normalement ~/.config/awesome ):

cd $XDG_CONFIG_HOME/awesome && mkdir scripts && cd scripts

Ceci fait, on va maintenant y ajouter les 4 scripts en question. Celui pour l’hibernation:

echo '#!/bin/sh\ndbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Hibernate' > hibernate.sh

Celui pour le redémarrage:

echo '#!/bin/sh\ndbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart' > reboot.sh

Celui pour l’extinction:

echo '#!/bin/sh\ndbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop' > shutdown.sh

Et enfin celui pour la mise en veille:

echo '#!/bin/sh\ndbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend' > suspend.sh

Il ne faut pas oublier de rendre nos scripts exécutables:

chmod +x suspend.sh shutdown.sh hibernate.sh reboot.sh

Ceci fait, il faut éditer le rc.lua afin de le créer ce fameux menu. On va donc ajouter ceci, dans la section menu:

1
2
3
4
5
6

mysystemmenu = {
   { "shutdown", awful.util.getdir("config") .. "/scripts/shutdown.sh" },
   { "reboot", awful.util.getdir("config") .. "/scripts/reboot.sh" },
   { "suspend", awful.util.getdir("config") .. "/scripts/suspend.sh" },
   { "hibernate", awful.util.getdir("config") .. "/scripts/hibernate.sh" }
}

Et de l’ajouter dans le menu principal:

1
2
3
4
5
6

mymainmenu = awful.menu({ items = {
      { "awesome", myawesomemenu, beautiful.awesome_icon },
      { "system", mysystemmenu },
      { "open terminal", terminal },
  }
})

Au final, la section Menu devrait ressembler à quelque chose dans ce genre:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

-- Create a launcher widget and a main menu
myawesomemenu = {
   { "manual", terminal .. " -e man -P /usr/bin/vimpager awesome" },
   { "edit config", editor_cmd .. " " .. awful.util.getdir("config") .. "/rc.lua" },
   { "restart", awesome.restart },
   { "quit", awesome.quit }
}
mysystemmenu = {
   { "shutdown", awful.util.getdir("config") .. "/scripts/shutdown.sh" },
   { "reboot", awful.util.getdir("config") .. "/scripts/reboot.sh" },
   { "suspend", awful.util.getdir("config") .. "/scripts/suspend.sh" },
   { "hibernate", awful.util.getdir("config") .. "/scripts/hibernate.sh" }
}
mymainmenu = awful.menu({ items = {
      { "awesome", myawesomemenu, beautiful.awesome_icon },
      { "system", mysystemmenu },
      { "open terminal", terminal },
    }
})
mylauncher = awful.widget.launcher({ image = image(beautiful.awesome_icon),
                                     menu = mymainmenu })

C’est tout. A vous d’adapter cela comme bon vous semble. ;-)

Je vais tenter de résumer sans trop d’erreurs ce qu’il en est concernant la hiérarchie des fichiers des systèmes d’exploitation de type Unix.

Peu après le milieu des années 90, une première version de la FHS (Filesystem Hierarchy Standard) a été établie. En premier lieu nommé FSSTND (Filesystem Standard) et visant uniquement les systèmes d’exploitation Linux, le standard s’est élargit aux systèmes de type Unix lors du changement de nom. Il s’agit en fait d’une formalisation étendue de la hiérarchie traditionnelle trouvée dans BSD. La version actuelle du standard date de 2004 et peut se trouver ici.

Aujourd’hui, il est relativement bien suivit par les différentes distributions bien que l’on peut voir quelques exceptions. Je pense notamment à Debian et dérivés qui placent le serveur web dans /var/www alors qu’il devrait se trouver, comme chez Archlinux par exemple, dans /srv/http. Chez les BSD aussi on peut constater des différences. La hiérarchie de Freebsd place par exemple concrètement les home utilisateurs dans /usr/home bien qu’un lien symbolique /home existe à la racine. Il existe également des systèmes Unix-like qui ne respectent absolument pas cette hiérarchie. Je pense à Gobolinux par exemple mais ce genre de cas est plutôt marginal.

Selon FHS, /usr ne devrait pas contenir de binaires ou librairies vitales au fonctionnement du système et ce dernier devrait donc être capable de démarrer sans. Or, ce n’est plus le cas avec systemd, écrit principalement par Lennart Poettering justement, qui est utilisé par défaut dans Fedora depuis la version 15 en remplacement de upstart. Ceci me permet de revenir au sujet principal de ce billet puisque les développeurs derrière Fedora veulent déplacer TOUS les fichiers binaires dans /usr et ainsi le principe évoqué en début de paragraphe ne sera pas respecté. Le but recherché par cette manœuvre est de pouvoir facilement partager /usr, en lecture seule notamment, afin de faciliter les “snapshots”. Ceci concerne donc principalement les machines virtuelles et les clusters.

Qu’en penser? Pour ma part, je ne suis pas contre le fait que les choses changent et évoluent. En revanche, j’ai l’impression que ce changement majeur s’opère de façon unilatérale chez Fedora et cela me déplaît passablement. A quoi cela sert-il d’essayer d’établir des standards si au final on en fait sa propre sauce?

Je vais quand même résumer les principaux points que Lennart Poettering a relevés afin de clore la discussion des développeurs:

• Il est très difficile pour les développeurs de faire la distinction entre ce qui doit aller /bin et dans /sbin.
• La définition originale de sbin est devenue obsolète (le “s” tient pour binaires “statiques”).
• La séparation entre /bin et /sbin n’a rien à voir avec une question de sécurité et ne l’a d’ailleurs jamais été. Le fait de le faire dans ce but serait suivre le principe de “sécurité par l’obscurité” et cela est plutôt stupide.
• La séparation de /bin et /sbin n’est pertinente que pour $PATH et $PATH ne sert qu’à faciliter l’accès aux outils pour les utilisateurs des shells.
• Cette séparation est superflue car tous deux sont listés dans $PATH au sein de Fedora.
• Cette séparation complique les choses. On ne peut justifier cela que si elle est faite pour une bonne raison or il est préférable de privilégier la simplicité.
• Les différentes distributions Linux ne placent pas forcément les binaires aux mêmes endroits chacune et donc le regroupement serait bénéfique de ce point de vue.
• L’idée de séparer /usr et / servait principalement pour le début du lancement du système. Le système minimal se trouvant dans / était juste suffisant pour trouver tout le reste de l’OS dans /usr. Cela n’est plus d’actualité.
• C’est effectivement devenu obsolète en raison d’initrd.
• Tout avoir dans /usr simplifie radicalement les choses dans le but d’avoir une configuration en lecture seule.
• Cela rend les snapshots plus facile. En effet, dans le cas de btrfs, faire 5 snapshots de /lib, /lib64, /bin/sbin et /usr est bien moins efficace que de faire simplement un snapshot de /usr.
• Avoir une séparation claire entre les données partageables (/usr) est préférable pour les configurations réseaux notamment.
• Cela simplifie les scripts de construction (? -> “build scripts”) en amont dès lors que autoconf ne connaît pas la séparation entre / et /usr.
• Harald a fait des tests et a constaté que c’était parfaitement viable.
• Quelqu’un est d’accord de se charger de cette tâche.

Il détaille plus ces points et en conclu qu’il y est donc très favorable, surtout en raison du fait que cela rendra beaucoup de choses plus faciles. Il souligne notamment le fait que cela rendra la tâche plus facile pour les développeurs mais également pour les packageurs et les administrateurs système qui pourront bénéficier d’une atomisation des snapshots de btrfs.

Je vous ai également brièvement évoqué mon point de vue mais ce qui m’intéresserais grandement, c’est d’avoir votre avis sur le sujet. Alors, qu’en pensez-vous?

Je me suis donc mis en tête d’en assembler un. Mes critères principaux étaient donc un PC silencieux, qui fonctionne bien sous Linux, capable de lire des vidéos HD et bon marché. Ne suivant que de loin l’évolution des PC côté hardware, je me suis donc adressé à Horyax en ayant déjà une idée de ce que je souhaitais. Je vous invite d’ailleurs à aller lire son article très instructif sur les PC media center.

En partant de ses conseils (AMD E-350 et mini-ITX notamment) et en composant avec ce qui était proposé par mon revendeur habituel, j’ai abouti à cette configuration:

• Carte-mère Asus E35M1-I Deluxe. Elle comprend un APU AMD E-350 soit un processeur dual-core basse consommation couplé à un GPU Radeon HD 6310. De plus, elle bénéficie d’un refroidissement passif qui permet donc d’éviter les nuisances sonores, une carte son 7.1, du Wifi, de l’USB 2 et 3 ainsi qu’un port e-sata, possibilité d’accueillir jusqu’à 8Gb de RAM en DDR3 à 1066Mhz, SATA 3 et est en format mini-ITX soit un format compact. Bref, une très bonne base pour ce que je voulais en faire.
• Disque dur Western Digital Caviar Green de 2To.
• 2x2 Go de DDR3 1066Mhz Kingston.
• Lecteur Bluray Samsung SH-B123L.
• Boîtier Inwin Mini-ITX BP655 avec alimentation de 200W intégrée.

Alors oui, les 4Go de RAM sont totalement injustifiés. En fait, c’est simplement que cela me revenait pratiquement au même prix qu’un kit de 2Go de RAM et je m’étais dis qu’en cas de problème pour lire les Bluray sous Linux, j’allais devoir à contre-coeur y installer Windows.

Si je devais racheter une configuration HTPC, je ne reprendrais pas le même boîtier. En effet, il se révèle relativement peu compact et plutôt bruyant au niveau de l’alimentation. Je l’avais choisis en raison de son prix réduit, du fait qu’il acceptait un disque dur au format 3.5” qui permettait l’achat d’un disque de plus grande capacité à prix équivalent en 2.5” et surtout qu’il est un des rares que j’ai trouvé à accepter un lecteur Bluray au format standard. En effet, la plupart des boîtiers multimédia demandent un lecteur au format slim, plus compact, mais également beaucoup plus cher et difficile à trouver.

Pour le reste, je suis parfaitement satisfait de mon achat. La déception vient plutôt du côté des Bluray bourrés de DRM qui se retrouvent quasiment impossible à lire sous Linux…

Si on considère ce dernier point et le fait que pour qu’un media-center soit intéressant, il nécessite que toute la médiathèque se trouve sur support type disque dur du HTPC ou partage réseau j’aurais peut-être porté mon choix sur la Zbox Nano. En effet, cette solution est très intéressante car parfaitement silencieuse, compacte et bénéficie en plus d’une télécommande! Bref, réfléchissez bien à l’utilisation que vous ferez de votre media-center avant de porter votre choix définitif.

Une fois tout ce beau matériel assemblé, je me suis attelé à  installer un système qui convienne bien pour une utilisation media-center. J’ai donc choisis d’y mettre Archlinux associé à XBMC mais sachez tout de même que si vous n’êtes pas vraiment prêt à mettre les mains dans le cambouis, il existe des distributions media-center toute prête telle que la récente OpenELEC basée sur ce même XBMC (je ne l’ai en revanche pas testée).

Je ne vous présente plus Archlinux mais par contre je vais m’attarder un poil sur XBMC. Il s’agit d’un logiciel media-center multiplateforme sous licence GPL. J’ai fait le tour de tout ce qui existait sous Linux avant d’établir mon choix sur celui-ci. A mon sens, il s’agit clairement de la meilleure solution media-center actuelle: gestion multilingue, système de plugins pour en étendre les capacités, fonctionnement en stand-alone, téléchargement automatisé des informations relatives aux films et aux albums musicaux, etc.

Ce que je souhaitais du côté de l’OS, c’est qu’il puisse démarrer directement sur le media-center et que celui-ci soit contrôlable entièrement via une application smartphone, y compris l’extinction du système. Évidemment, si je vous en parle, c’est parce que j’y suis parvenu.

Je ne vais pas vous détailler l’installation d’Archlinux. Pour cela, le guide du débutant le fait très bien (mais arrêtez-vous après le reboot c’est-à-dire avant le chapitre “post-installation”). En revanche, je vais détailler le reste.

Donc, une fois l’installation d’Archlinux effectuée, vous avez redémarré et vous vous retrouvez avec un joli prompt. La première chose à faire après vous être connecté en tant que root est de configurer votre connexion internet et de mettre à jour le système (étape surtout valable si vous n’êtes pas passé par la netinstall).

Il faut ensuite créer un utilisateur standard. Appelons le Spoke ici pour références ultérieures. Pour cela, la commande adduser fait bien son boulot. Il est important à cette étape d’ajouter le nouvel utilisateur aux groupes suivants: audio, optical, storage, video, power. Vous pouvez l’ajouter à d’autres groupe, comme wheel par exemple mais cela reste optionnel. Le reste des options peut être laissé par défaut.

Par la suite, on aimerait installer une interface graphique et donc, il nous faut Xorg. A cette étape, deux choix s’offrent à vous en ce qui concerne le pilote vidéo: utiliser le pilote ATI libre ou le pilote propriétaire Catalyst. Si vous n’avez pas besoin de faire passer le son à travers l’HDMI, alors le premier choix sera le mieux indiqué. Le pilote libre s’en sort effectivement très bien si ce n’est qu’au niveau du son, ça ne passe pas encore via l’HDMI. Sinon, il faudra installer le pilote propriétaire et c’est là que les choses se compliquent.

Dans le premier cas, cela se résume à cette ligne (en root toujours) :

pacman -S xorg-server xorg-xinit xorg-utils xorg-server-utils mesa xf86-video-ati

Si vous avez besoin du pilote Catalyst, alors armez-vous de courage. Il faut savoir qu’il n’est plus supporté par la distribution et que cela amène son lot de difficultés et de possibles cassages par la suite. A l’heure actuelle, le pilote Catalyst ne fonctionne pas avec Xorg 1.11 qui est la version actuelle. Il faut donc passer par l’installation de Xorg 1.10. La bonne nouvelle est qu’il existe un dépôt créé pour cette occasion. Il faut donc éditer /etc/pacman.conf et l’ajouter:

# xorg 1.10
[xorg110]
Server = http://catalyst.apocalypsus.net/repo/xorg110/$arch

Faites bien attention à l’ajouter au-dessus de tous les autres (c’est-à-dire au dessus de [core]) afin qu’il prenne précédence. D’ailleurs, pendant que l’on est dans le pacman.conf , il faut également y ajouter le dépôt pour le pilote Catalyst:

# catalyst
[catalyst]
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch

Il faut maintenant rafraîchir les dépôts et installer Xorg ainsi que le pilote Catalyst:

pacman -Syu
pacman -S xorg110/xorg-server xorg110/xorg-server-common xorg110/xorg-server-utils catalyst catalyst-utils catalyst-hook xvba-video

catalyst-hook est optionnel mais néanmoins recommandé (il sert à reconstruire les modules lors des mises-à-jour du noyau). J’espère ne pas avoir oublié un paquet. S’il manquait quelque chose, merci de m’en faire part dans les commentaires.

Ceci fait, il nous faut ajouter quelques paquets fortement recommandés mais optionnels: un serveur ssh afin d’administrer à distance (d’autant plus utile si aucun clavier n’est branché au HTPC), consolekit, udev, udisks et upower afin de pouvoir notamment éteindre proprement la machine. Vous pouvez aussi considérer l’installation de sshfs ou autre samba afin de partager la médiathèque sur le réseau.

Il faut aussi, évidemment, installer xbmc. Le minimum en une ligne (le reste au choix):

pacman -S openssh consolekit udev udisks upower xbmc

Je mets volontairement de côté la configuration de ssh car ce n’est pas à propos dans ce billet.

Passons maintenant au login utilisateur. Il existe plusieurs façon de gérer le login automatique, notamment la méthode via inittab que je n’ai pas choisie. La raison est toute simple: je voulais pouvoir permettre, le cas échéant, la déconnexion de la session media-center afin de passer sur une session desktop conventionnelle, type Xfce, de manière pratique. En effet, il ne faut pas oublier que cette machine est un ordinateur à part entière et qu’en lui ajoutant clavier et souris, elle est plus qu’utilisable pour une utilisation desktop. Ma copine ne possédant qu’un vieillissant netbook, cela peut se révéler utile.

Par conséquent, j’ai choisis d’utiliser le gestionnaire de connexion Slim, qui permet évidemment la connexion automatique. Pour cela, on va donc l’installer et le configurer un minimum:

pacman -S slim

Il faut maintenant éditer le fichier de configuration /etc/slim.conf afin de changer ces deux lignes (il faut évidemment les décommenter):

default_user    spoke
auto_login      yes

Le démon slim doit également être ajoutée dans la liste des daemons du /etc/rc.conf afin qu’il soit lancé au démarrage. Cependant, ce n’est pas finit. Il faut encore se connecter en tant que Spoke et éditer (le créer le cas échéant)  le fichier ~/.xinitrc. afin qu’il ressemble à ceci:

exec ck-launch-session xbmc-standalone

Notez que si vous avez opté pour la méthode de connexion automatique via inittab, le xinitrc devra être identique.

Que serait un media-center sans codecs? On peut remédier à cela en une ligne (certains sont sûrement inutiles mais on est au moins parés) avec en prime ce qu’il faut pour la lecture des DVDs:

pacman -S a52dec faad2 flac libdca libdv libmad libtheora libvorbis libxv wavpack xvidcore gstreamer0.10-plugins libdvdread libdvdcss libdvdnav

Oui, je n’ai pas parlé de la lecture des Bluray… Simplement car, à mon grand regret, je n’ai pas encore trouvé de solution viable pour leur lecture. J’espère que la situation s’améliorera rapidement.

J’avais brièvement évoqué le fait de pouvoir piloter le media-center depuis son smartphone. En effet, ne possédant pas de télécommande, j’ai trouvé cette solution fort pratique. Pour informations, j’utilise l’application officielle et gratuite xmbc-remote pour Android et ma copine en utilise une non- officielle pour iPhone mais je ne me rappelle plus du nom.

J’espère n’avoir rien oublié car j’ai écrit cet article en fonction de mes souvenirs de l’installation. Merci de m’informer si vous testez ceci chez vous et que vous constater qu’il manque quelque chose!

Allez, pour le mot de la fin de ce long billet, j’aimerais signaler que je suis vraiment super content de mon installation si l’on excepte l’histoire de la lecture des Bluray. En effet, même en se faisant légèrement entendre au démarrage, le bruit de l’alimentation se fait vite oublier une fois qu’un film est en route ou que de la musique est jouée. Bref, une installation pareille, c’est vraiment le pied. :)

PS: j’ajouterai des photos de l’installation par la suite mais je n’avais pas d’appareil photo sous la main et les photos prises depuis mon HTC Desire sont de bien trop piètres qualités pour être publiées ici. Je retoucherai également cet article (ou en créerai un complémentaire) afin de le peaufiner et d’expliquer le paramétrage de XBMC (réglages permettant de contrôler xbmc depuis son smartphone, configuration d’un share samba, etc.).

Pas mal de choses ont changé depuis le début. Je suis passé d’un blog auto- hébergé avec une adresse noname à un hébergement sur serveur dédié avec un nom de domaine qui m’appartient.

Au niveau du contenu aussi on peut constater une évolution. Je publie moins qu’au début mais mes articles sont devenus bien plus personnels. Après tout, je n’ai aucun intérêt à relayer de l’info qui existe déjà partout ailleurs et, surtout, je n’ai pas le temps de suivre l’actualité et on sait tous bien que de l’info “périmée” ça n’est pas vraiment utile.

En tout cas, j’espère que vous avez du plaisir à me lire et, surtout, que mes posts se révèlent utiles et/ou intéressants.

Et n’hésitez pas à laisser un petit commentaire de temps en temps, ça fait toujours plaisir. :-)

Toujours est-il que je trouve bien plus fun d’écrire tout cela soi-même (voir notamment cet article). Je m’étais donc écrit un widget pour avoir les informations pertinentes concernant la batterie de mon portable (pourcentage de charge, status, temps restant). Or, pour le temps restant, je n’avais pas creusé bien loin et m’appuyais simplement sur acpitool au travers d’un io.popen(acpitool -b). Je suis conscient que ce n’est pas très élégant mais je trouvais cela simple.

Pourquoi je vous parle de cela? Simplement car depuis une mise-à-jour récente d’Archlinux, acpitool n’est plus fonctionnel. En effet, il s’appuie sur /proc/acpi/battery pour la collecte des informations nécessaire. Or, il s’avère que /proc/acpi/ est déprécié et a été ôté depuis le noyau 3.0.6-1 sur Archlinux. Au lieu de cela, acpitool devrait chercher les informations dans /sys/class/power_supply/.

Mon idée première a donc d’abord été de vouloir proposer un patch auprès du développeur d’acpitool étant donné que le problème est upstream. En allant récupéré les sources, j’ai constaté que les derniers changements apportés au code remontent au 13 août 2009. J’ai de plus rapidement constaté qu’un patch ne suffirait pas et que le code doit être revu dans son ensemble. Bref, fort de ce constat, j’ai décidé de récupérer cette info désormais manquante pour mon widget par moi-même.

Voici donc la version réécrite de mon widget de batterie:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

-- Battery status widget
function activebat()
  local path, perct, res, batime_h, batime_m, batime, f
  -- files we read from
  local charge_full, charge_now, current_now, present, status
  path = "/sys/class/power_supply/BAT0/"
  f = io.input(path .. "present")
  present = io.read("*number")
  f:close()
  if (present == 0) then
      return 'no'
  en
  f = io.input(path .. "status")
  status = io.read("*all")
  f:close()
  if (status == 'Full\n') then
      return '↯'
  end
  f = io.input(path .. "charge_now")
  charge_now = io.read("*number")
  f:close()
  f = io.input(path .. "charge_full")
  charge_full = io.read("*number")
  f:close()
  perct = (charge_now/charge_full) * 100
  res = string.format("%.2f", perct)
  if perct < 10 then
      res = '' .. res .. ''
  elseif   perct < 20 then
      res = '' .. res .. ''
  elseif  perct < 30 then
      res = '' .. res .. ''
  else
      res = '' .. res .. ''
  end
  if (status == 'Discharging\n') then
      status = '-'
      -- get remaining time
      f = io.input(path .. "current_now")
      current_now = io.read("*number")
      f:close()
      batime = math.floor((charge_now / current_now) * 60)
      batime_h = math.floor(batime / 60)
      batime_m = string.format("%02d", batime % 60)
      batime = ' (' .. batime_h .. "h" .. batime_m .. ')'
  else
      status = '+'
      batime = ''
  end
  res = res .. '% ' .. status .. batime
  return res
end
batinfo = widget({ type = "textbox" , name = "batinfo" })
-- Assign a hook to update info
activebat_timer = timer({timeout = 1})
activebat_timer:add_signal("timeout", function() batinfo.text = "BAT: " .. activebat() .. " |" end)
activebat_timer:start()

Bien entendu, si votre batterie n’est pas BAT0 mais BAT1 ou autre, il faudra mettre à jour cette information afin que le widget fonctionne chez vous. Au final, ça ressemble à ça:

Il faudrait encore que je prenne le temps de l’améliorer afin qu’il prenne en compte le temps restant jusqu’à charge complète de la batterie mais je ne me suis pas encore penché sur le problème. En attendant, cela sera peut-être utile à l’un d’entre vous.  ;-)

En effet, j’ai remarqué que, bien souvent, les gens ne vont pas creuser les manpages en profondeur et utilisent ssh d’une manière que j’ai envie de qualifier de “basique”.

Si vous avez un tant soit peu prêté attention à la configuration de votre sshd, vous avez sans doute changé le port par défaut (22) pour un autre (si ce n’est pas ton cas, honte à toi!). Dès lors, pour vous connecter à votre serveur, vous vous contentez peut-être de ceci:

ssh -p 12345 moi@monserveur

Ou peut-être, vous vous pensez malin et vous avez aliasé cette commande dans votre $SHELLrc. Or, il existe quelque chose de bien plus propre. Il suffit de créer un fichier “config” dans votre $HOME/.ssh et d’y mettre quelque chose de similaire à ceci:

Host monserveur
    Hostname monserveur.org
    Port 12345
    User moi

Maintenant, pour se connecter, cette commande suffit:

ssh monserveur

Évidemment, cela fonctionne également pour la commande scp. Au lieu de:

scp -P 12345 monfichier moi@monserveur:

on peut se contenter de ceci (n’oubliez pas les “:”):

scp monfichier monserveur:

Plutôt pratique non? Et vous me direz peut-être: “comment fait-on si on veut se connecter en tant qu’un autre utilisateur sur le même serveur?” Et bien simplement en ajoutant un autre “Host”:

Host monserveur-autre
    Hostname monserveur.org
    Port 12345
    User autre

Et hop:

ssh monserveur-autre

Bref, si vous avez touché à votre sshd, vous aurez également pris la peine de désactiver le login root et le login par mot de passe pour utiliser un système de paire de clés asymétriques (RSA, DSA ou ECDSA).

Pour peu que vous soyez consciencieux, vous aurez pris la peine de générer une paire de clés avec passphrase. Et là, à chaque tentative de connexion, hop, il faut rentrer la passphrase. Et bien il existe un moyen de rentrer la passphrase une fois et de ne plus s’en occuper ensuite. La plupart des gens utilisent ssh-agent pour gérer les clés. Cela fonctionne très bien mais le problème c’est qu’en ouvrant un nouveau shell, il faudra à nouveau lancer ssh- agent et lui fournir les clés et passphrases… Pas si pratique que cela finalement.

L’autre solution consiste à utiliser keychain. Keychain n’est autre qu’un petit soft qui fait office de frontend à ssh-agent et qui propose de faire tourner ssh-agent par le système au lieu de par login. Ainsi, il suffit de rentrer la passphrase au premier lancement de son shell et ensuite on n’en parle plus.

Pour utiliser keychain, il suffit de l’installer via votre gestionnaire de paquet favoris puis de rajouter une simple ligne dans votre $SHELLrc:

eval `keychain -q --eval --agents ssh id_ecdsa`

De cette manière, la passphrase pour votre clé (dans mon exemple, une ecdsa) vous sera demandée au premier lancement de votre $SHELL mais plus par la suite.

La bonne nouvelle pour les zsh users c’est qu’ils vont pouvoir utiliser la complétion sur des commandes comme celle-ci par exemple:

scp truc monserveur:<TAB>

étant donné qu’il n’y a plus de passphrase à rentrer.

Le billet humoristique (en anglais) commence ainsi:

“When Rasmus Lerdorf first put PHP together, he - quite sensibly, despite his heritage - chose not to write it in Greenlandic or Danish. Good job too - that would have been rather unpleasant to work with. He opted instead, being in Canada at the time, for the local tongue. No, not French - that bastard dialect of the Queen’s English commonly referred to as “US English””

A quoi donc ressemblerait PHP s’il avait été écrit en British english et non en US english? Je vous invite à lire l’article If PHP Were British.

Par exemple, l’auteur suggère que ce bloc standard de gestion d’une exception:

    try {
        // Code here
    } catch (Exception $e) {
        // Handle exception
        die('Message');
    }

devienne ceci:

    would_you_mind {
        // Code here
    } actually_i_do_mind (Exception £e) {
        // Politely move on
        cheerio('Message');
    }

et fournit l’explication qui explique pourquoi.