Facile !
gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=fichier_de_sortie.pdf -dBATCH fichier_d_entree_1.pdf fichier_d_entree_2.pdf
Qui me fréquente un peu a déjà entendu parler d'un logiciel nommé Weboob, pour Web Out Of Browser. Il est donc naturel d'en parler un jour ou l'autre sur ce blog.
Concrètement, ce logiciel permet d'aller chercher des informations sur des sites Web sans utiliser un navigateur traditionnel. Dans un monde idéal, Weboob n'existerait pas et les données seraient facilement exportables sur tout site Web. Ce n'est cependant que rarement le cas, et Weboob a l'ambitieuse mission de pallier aux carences des sites Web. Cela le rend forcément très riche, car le Web regorge de fonctionnalités... Par une petite suite de billets (probablement deux, ou trois, selon l'humeur) je vais présenter tout ce dont je me sers au quotidien (dans un ordre historique d'utilisation), et ce qui me fait gagner un temps relativement important tous les jours.
C'est par boobank que j'ai commencé à utiliser (et contribuer à) Weboob. L'application permet d'aller chercher le solde de ses comptes, l'historique des opérations, les opérations à venir, et même d'exporter les données pour l'intégration à un logiciel de comptabilité. J'étais très demandeur de cette fonctionnalité pour les banques françaises, qui contrairement aux banques allemandes forcent la connexion à leur site bourré de publicités plutôt que de permettre un simple export par des protocoles bien connus. Concrètement, avec le clavier virtuel, le changement régulier obligatoire de mots de passe, le site plutôt lent, je passais un temps fou à suivre mes comptes sur la BNP. Alors qu'en deux clics c'était fait pour la Deutsche Bank.
J'ai donc été bluffé quand j'ai utilisé pour la première fois Weboob et le module de la BNP. En une commande dans le terminal je pouvais enfin vérifier que je n'étais pas dans le rouge. Ça m'a tellement plu que j'ai contribué pour la première fois aux alentours d'août 2010 avec quelques patchs pour la BNP.
Depuis, boobank n'a fait que s'améliorer. L'application permet notamment de faire des virements de compte à compte et l'export en .qif. C'est toujours plus long que de passer par aqbanking à la mode allemande, mais le bénéfice est plus qu'appréciable. Autre chose que j'ai pu apprécier lors de mon changement de banque, c'est l'agrégation des données de toutes les banques configurées. J'avais à ce moment là deux banques, et je pouvais suivre le solde des deux au même endroit.
En cerise sur le gâteau, un script existe pour faire des graphiques des comptes à travers munin. Complètement inutile, donc parfaitement indispensable.
En conclusion, Boobank est l'archétype de « Weboob ne devrait pas exister ». Si les banques françaises arrêtaient de se moquer de leurs clients en forçant des accès à travers leur site Web ou des applications spéciales pour Smartphone (et je ne parle même des options payantes à des prix scandaleux pour recevoir des « alertes »), Boobank disparaîtrait immédiatement. Des solutions existent, comme les banques allemandes le prouvent.
Vivre à Dresde, c'est vivre dans une ville au niveau du fleuve bien changeant. Ce n'est heureusement pas souvent comme en 2002, mais les variations peuvent tout de même être spectaculaires. Je ne suis pas ultra fan du site officiel (notamment car il ne publie pas un réel historique des données), et j'avais donc programmé un petit module Weboob pour suivre cette évolution, et faire des jolis graphiques comme celui-ci :
(des observateurs un peu curieux pourront détecter une anomalie en décembre, mon serveur étant en panne...).
J'ai longtemps gardé dans mon coin ce module, qui était vraiment peu configurable et écrit (trop) rapidement pour mes besoins spécifiques. J'ai cependant fini par le proposer dans Weboob, et il est présent depuis la version 0.b dans la version officielle et utilisable à travers Wetboobs. Pour savoir le niveau de l'Elbe (ou de tout autre cours d'eau en Saxe), une commande très simple est maintenant disponible :
$ wetboobs gauges Elbe
On peut aussi aller chercher l'historique d'une sonde, ou bien juste la dernière valeur connue. Bien entendu, si je l'ai fait pour la Saxe, on peut imaginer écrire le même module pour la France entière via Vigicrue. Et coupler Weboob à un petit script pour recevoir un mail en cas d'alerte de crue, c'est assez simple. Le tout en attendant que les autorités publiques allemandes et françaises commencent à publier des Données ouvertes.
Dans un autre billet... Avec notamment la récupération des articles de journaux, le téléchargement de vidéos, et bien d'autres trucs.
Aujourd'hui une pub éhontée pour un livre. Je ne connais même pas l'auteur personnellement, mais la maison d'édition me l'a envoyé gratuitement, ça prouve qu'il est bien non ?
Il s'agit de Linux embarqué. Pour une fois, ne vous attendez pas à trouver des lignes de commande, des howto ou ce genre de détails. Il s'agit bien d'un livre technique, mais dons le but est de vous faire choisir (ou pas) linux comme plateforme pour l'embarqué.
Il vous pose les bonnes questions et vous aide à y répondre. Quel modèle de développement ? Temps réel ou non ? Investissez-vous sur le long terme ? Et ce n'est qu'après avoir étudié le sujet que vous saurez s'il est judicieux de choisir linux.
Mais une fois que vous avez choisi linux, pensez-vous vraiment que cela suffise à votre succès ? Gilles Blanc vous explique comment vous préparer, ce que vous devez savoir, comment organiser le projet. Tout ce qu'il faut à l'intention du chef de projet.
Ce livre permet aux gens de faire un choix avisé, de savoir quelles sont les raisons de ce choix et comment. C'est grâce ça que vous pourrez soutenir ce choix tout au long du projet. Il permettra de transformer un projet sur l'embarqué en succès. Et il est probable que parmi ces projets un certain nombre utiliseront linux. Et comme tout le monde devrait le savoir, un projet réussi est un bien meilleur ambassadeur du libre qu'un geek dans son coin.
En conclusion, même si je ne recommanderais pas ce livre à ma grand-mère, je pense qu'il a une énorme valeur pour la progression du logiciel libre. Je le recommande à tout chef de projet ou ambassadeur du logiciel libre qui voudrait lancer un produit avec du linux embarqué.
Si vous avez aimé, il y a aussi :
Tags:livreNiveau :
Résumé : ntp.conf ; fudge
Pour vérifier le bon fonctionnement de votre démon ntp, vous êtes amené à taper la commande suivante qui liste les source de temps utilisées :
$ ntpdc -p
Cette commande met une étoile face à la source de référence utilisée pour la synchronisation. Le choix se fait entre autre en fonction du stratum de la source. Je rappelle que les serveurs NTP disposant d'une source de temps matérielle fiable (horloge atomique) ont pour stratum 1. Ceux qui se synchronisent sur eux, 2, et ainsi de suite.
Étant donné qu'il y a un grand nombre de serveurs publics de strate 2 et 3, vous devriez avoir accès à des serveurs de strate 4, ou au pire 5. Mais si le serveur a une strate plus élevée, il se peut que l'horloge choisie ne soit plus le serveur, mais l'horloge locale qui a une strate définie par défaut à 5 sur certaine distributions.
Et là c'est le drame, vous n'êtes plus synchronisés !
Pour résoudre ce problème, il y a plusieurs méthodes, se résumant toutes en la configuration des serveurs de temps :
# ntp.conf # mettre l'option prefer sur le serveur voulu serveur xxx.com prefer # réduire la strate du serveur fudge xxx.com stratum 4 # augmenter la strate de l'horloge locale # 127.127 pour les horloges non réseau # 1.0 pour l'horloge système fudge 127.127.1.0 stratum 10
Si vous avez aimé, il y a aussi :
Tags:planet-libre, planete-libre, ServeurNiveau :
Résumé : vlock; vlock -ns
Vous avez vu apparaître dans l'article sur tmux, un petit outil pour verrouiller le terminal, il s'appelle vlock.
Son unique fonctionnalité est le locker un terminal et de demander un mot de passe pour être débloqué.
Mine de rien ça lui fait quand même deux cas d'usage :
Avec la commande suivante :
$ vlock
Vous bloquez votre terminal en cours, et seul un mot de passe peut le débloquer. C'est utile essentiellement lorsque vous êtes connecté en ssh à distance sur une machine.
L'option -a permet de locker toutes les consoles locales (ctrl-alt-Fx, ou alt-Fx), en pratique il locke la console en cours et empêche d'en changer. Il faut donc déjà être sur une console locale.
Si vous êtes sur X, vous êtes aussi sur une console locale (remarquez le ctrl-F7 pour y aller). Mais le shell qui va lancer votre commande ne l'est pas, il est dans le terminal virtuel de xterm, rxvt, konsole et consorts. Pour locker toutes les consoles, il faut donc utiliser l'option -n qui ouvre une nouvelle console (avec openvt) avant de continuer avec l'option -a.
Enfin notez que l'utilisateur local a en général accès aux magic keys, et une de ces magic keys sert justement à tuer le processus en avant plan (alt-sysrq-k), par exemple pour garantir qu'il n'y a pas de keylogger. Si vous ne voulez pas vous faire tuer votre session par cette combinaison de touche vous pouvez utiliser l'option -s. C'est là qu'on voit que cette combinaison nommé SAK n'est pas si sécurisée que ça puisqu'elle peut être désactivée...
Donc je résume :
# en tant qu'utilisateur normal et seulement depuis une console texte $ vlock -a # en tant que root $ vlock -sn
Et c'est là qu'est la difficulté, en toute logique le lancement doit se faire par le processus qui dispose du terminal à un instant donné, surtout dans le cas de blocage du terminal virtuel. La bonne solution est de le lancer après un certain temps d'inactivité, et seule l'application peut savoir quand le lancer. C'est donc à vous de trouver les settings spécifiques à l'application pour le faire.
Mon article précédent indique comment faire pour tmux, malheureusement je n'ai pas trouvé de solution pour bash qui ne propose que la variable TMOUT qui termine complètement le shell.
Si vous avez aimé, il y a aussi :
Tags:Commande, planet-libre, planete-libreNiveau :
Résumé : tmux
Aujourd'hui tout le monde connaît et utilise screen. Miracle de la technologie, il permet de survivre aux déconnexions, de lancer des commandes longues sans avoir peur, de faire passer tous ses shells dans une seule connexion et on le trouve souvent associé à l'indémodable irssi.
Comme vous le savez peut-être screen n'est plus maintenu. Ayant un code un difficile à lire et à maintenir, des développeurs ont choisi lui faire un concurrent plutôt que de le reprendre.
Ce concurrent se nomme tmux. Il dispose de la plupart des fonctionnalités de screen et d'autres en plus. Comme vous le verrez, votre problème sera essentiellement de vous adapter aux nouveaux raccourcis. Pour le reste c'est tout bon.
Tmux dispose de presque toutes les fonctionnalités de screen sauf la communication par port série (rapport choucroute, toussa).
Commençons par le lancement :
# lancer un nouveau multiplexeur $ screen $ tmux # s'attacher à un multiplexeur existant $ screen -d -r $ tmux attach
Les raccourcis :
Je dois dire que ça y est je suis passé entièrement à tmux, le mélange ctrl-a ctrl-b entre screen et tmux commençait à être difficile. A propos d'adaptation, j'ai eu une seule difficulté c'est de m'habituer au nouveau scrollback. Il n'est pas possible de le faire à la souris, comme dans screen avec l'astuce du termcapinfo. Remarquez, c'est plus propre car du coup il n'y a pas de mélange des bufffer de scrollback entre les différents terminaux. Donc la méthode propre dans tmux c'est ctrl-b suivi de pgUp et là vous êtes en mode copy (qui permet entre autre le scrollback), vous pouvez alors naviguer avec pgUp, pgDown ou les touches directionnelles. Et pour Revenir au mode normal, Esc tout simplement.
Dans un prochain article nous verrons comment changer la configuration de tmux, même si les valeurs par défaut sont plutôt bonnes.
Si vous avez aimé, il y a aussi :
Tags:Commande, planet-libreNiveau :
Résumé : tmux
Comme disait un illustre au grand cœur, "Compromis, chose due !" (orthographe approximative). Voici donc mon fichier de configuration détaillé de tmux, à mettre dans ~/.tmux.conf ou /etc/tmux.conf au choix. Je n'ai pas changé beaucoup de raccourcis car je tiens à m'habituer autant que possible aux valeurs par défaut qui vont se retrouver sur mes nouveaux serveurs.
J'en profite pour ajouter un raccourci que j'ai oublié la dernière fois :
# Pour les nostalgiques de screen # comme les raccourcis ne sont pas les mêmes, j'évite #set -g prefix C-a #unbind-key C-b #bind-key a send-prefix # même hack que sur screen lorsqu'on veut profiter du scroll du terminal (xterm ...) set -g terminal-overrides 'xterm*:smcup@:rmcup@' # c'est un minimum (defaut 2000) set-option -g history-limit 100000 # lorsque j'ai encore un tmux ailleurs seule # sa fenetre active réduit la taille de ma fenetre locale setw -g aggressive-resize on # locker la session après inactivité (en s) set -g lock-after-time 3600 # pour que le lock marche sous linux (apt-get install vlock) set -g lock-command vlock # il faut choisir un derivé de screen, 256 couleurs c'est bien ! set -g default-terminal "screen-256color" # pour ceux qui n'ont pas laché la souris set -g mouse-select-pane on setw -g mode-mouse on # ca peut etre utile ... set -g status-utf8 on setw -g utf8 on # Pour etre alerté sur un changement dans une autre fenêtre setw -g monitor-activity on #set -g visual-activity on #set -g visual-bell on # numéroter a partir de 1, pratique pour l'accès direct set -g base-index 1 # repercuter le contenu de la fenetre dans la barre de titre # reference des string : man tmux (status-left) set -g set-titles on set -g set-titles-string '#H #W #T' # host window command ######### # theme # ######### # exprimez votre créativité ici ! # pour les string : man tmux (status-left) # barre un peu plus discrete set -g status-bg default set -g status-fg green setw -g window-status-current-bg default setw -g window-status-current-fg white setw -g window-status-alert-attr default setw -g window-status-alert-fg yellow set -g pane-active-border-fg green set -g pane-active-border-bg black set -g pane-border-fg white set -g pane-border-bg black set -g message-fg black set -g message-bg green # exemples de barre d'état #set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]' #set -g status-right '#[fg=green]][#[fg=white] #T #[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]' #set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]' #set -g status-right '#[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]' #set -g status-left '#[fg=green](#S) #(whoami)@#H#[default]' #set -g status-right '#[fg=yellow]#(cut -d " " -f 1-3 /proc/loadavg)#[default] #[fg=blue]%H:%M#[default]' #set -g status-right "#[fg=yellow]#(uptime | cut -d ',' -f 2-)"
Comme pour le bashrc collaboratif, je vous propose de poster en commentaires vos personnalisations, je les ajouterai.
Si vous avez aimé, il y a aussi :
Tags:Commande, planete-libre
EuroBSDcon 2011 s'est déroulé au début de ce mois d'octobre. Je viens de finir de mettre en forme mes notes sur les conférences que j'ai suivies.
On y retrouvera en particulier :
AF_INET6-only, et
ce qui doit arriver dans le futur proche dans un FreeBSD près de
chez vous ;
À noter également les slides de quelques développeurs OpenBSD :
Malheureusement les slides de Claudio Jeker sur MPLS ne sont pas en ligne.
Michael Dexter a parlé de virtualisation dans le monde BSD ( plus de documents). Son exposé avait deux grands axes : une classification des techniques de virtualisation existante, et surtout une présentation de BHyVe, un hyperviseur de type 2 (à la Xen) pour FreeBSD.
Comme ZFS c'est beau, ça rend le poil soyeux et ça permet à l'admin de
diminuer sa consommation d'aspirine, j'ai profité de mon changement de
Kimsufi pour l'installer en tout ZFS, depuis le boot. Bien sûr, une
solution aurait été de laisser l'installation sur
/ et de ne mettre
que les données sur un volume ZFS, mais c'est trop facile, ça. Et puis
on garde de l'UFS, c'est
so-XX
ième siècle
.
Pour installer en tout ZFS, il doit y avoir au moins trois solutions pour faire cette installation :
cp de notre
/ UFS vers ce volume ZFS, pointer le chargeur de
boot vers ce volume ;
On est d'accord que le premier, c'est tricher. Chez moi le vKVM perdait régulièrement la connexion, alors j'ai utilisé le boot sur le réseau (le mode rescue-pro).
Let's go.
Cette partie est largement une reprise du wiki de FreeBSD sur l'installation d'un système en ZFS.
Cependant :
Il va donc falloir ruser (un peu) pour récupérer les paquets d'installation.
On boote alors sur le rescue-pro, on a bien sûr pris soin de donner sa clef publique SSH pour ne pas avoir à attendre le mail avec les identifiants.
Je n'ai pas réussi à installer ZFS en utilisant une table de partition MBR, alors que ça a marché du premier coup avec du GPT. Il paraît que GPT est la voie du futur, alors hop.
On détruit avec
gpart destroy le partitionnement en place, et
on recrée un nouveau schéma :
gpart create -s gpt ad4 gpart add -s 64K -t freebsd-boot ad4 gpart add -s 2G -t freebsd-swap -l swap ad4 glabel label swap ad4p2 gpart add -t freebsd-zfs -l data ad4 glabel label data ad4p3 gpart show
Autre possibilité : ne pas faire de partition de swap, mais créer un volume ZFS de swap. D'après la page du Wiki FreeBSD citée plus haut, ça empêche de créer des dumps lors d'un crash. En l'absence d'autres arguments, je suis parti sur une partition de swap à part.
Récupérer les fichiers d'installation. On crée un volume en
tmpfs, et
on ignore couragement l'avertissement qui apparaît dans le
dmesg :
mkdir /root/sets mount -t tmpfs -o size=300000000 dummy /root/sets dmesg | tail => WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. cd sets ftp ftp.fr.freebsd.org cd pub/FreeBSD/releases/amd64/8.2-RELEASE !mkdir base kernels mget base/* kernels/*
Dans mon cas, j'installe juste un hôte minimal pour des jails. Pour un serveur traditionnel, vous voudrez certainement installer les autres sets, mais au pire cela se fait très bien une fois l'installation terminée.
On crée le volume ZFS :
mkdir /root/newinstall zpool create -m /root/newinstall zroot /dev/gpt/data zpool set bootfs=zroot zroot
On crée les sous-volumes ZFS :
zfs create zroot/usr zfs create zroot/var zfs list
On devrait voir
zroot monté dans
/root/newinstall,
zroot/var
dans
/root/newinstall, etc.
Encore une fois, pour un serveur complet on voudra peut-être créer
d'autres volumes ZFS pour une séparation plus fine, peut-être un
/var/log compressé ou un
/var/empty en RO… Voir l'article du
wiki de FreeBSD pour une idée de partitionnement possible.
/home
avec des quotas (voire un volume par luser) est une très bonne idée de
chose à ajouter si on prévoit d'avoir d'autres utilisateurs.
Par contre, mettre la racine (de notre serveur) dans la racine (de notre pool ZFS) n'est pas forcément une très bonne idée. Heureusement, on peut corriger cela plus tard.
On installe le monde de base plus le noyau GENERIC :
setenv DESTDIR /root/newinstall cd /root/sets cd base ; sh install.sh ; cd .. cd kernels ; sh install.sh generic ; cd .. cd /root/newinstall/boot rm -fr kernel mv GENERIC kernel chroot /root/newinstall echo /dev/label/swap none swap sw 0 0 > /etc/fstab echo 'zfs_load="YES"' > /boot/loader.conf echo 'vfs.root.mountfrom="zfs:zroot"' >> /boot/loader.conf vi /etc/rc.conf
sshd_enable="YES" ntpdate_enable="YES" ntpdate_hosts="213.186.33.99" fsck_y_enable="YES" named_enable="YES" ifconfig_nfe0="inet 198.51.100.43/24" defaultrouter="94.23.42.254" hostname="foo.example.net" zfs_enable="YES"
Mettre un mot de passe pour root (
passwd), et se créer un
utilisateur (
adduser et répondre aux questions). Noter que par
défaut
sshd refuse les connexions en tant que root, donc créer un
utilisateur mortel et le placer dans le groupe
wheel est
certainement une bonne idée.
Quitter le chroot.
On va installer le bootloader ZFS-capable. Là j'ai eu une surprise :
ZFS s'est mis à utiliser toute la RAM, ce qui est normal vue
l'installation qu'on vient de réaliser, mais au détriment de notre
partition
tmpfs, ce qui est étonnant étant donné qu'on a donné une
réservation. Donc, j'ai démonté / remonté mon pool ZFS, mon
tmpfs a
retrouvé une taille normale, et j'ai pu récupérer le bootloader pour
l'installer :
zpool export zroot zpool import zroot cp /root/newinstall/boot/pmbr /root/sets cp /root/newinstall/boot/gptzfsboot /root/sets zpool export zroot gpart bootcode -b /root/newinstall/boot/pmbr -p /root/newinstall/boot/gptzfsboot -i 1 ad4 zpool import zroot
Il est peut-être possible d'installer le bootloader sans démonter le
pool, je n'ai pas essayé. Il doit aussi certainement être possible
d'utiliser celui est dans le
/boot de l'environnement fourni par
OVH, je n'y ai pas pensé sur le moment…
Il semble que ZFS ait besoin d'un cache pour booter correctement. Je n'ai pas trouvé d'articles expliquant quelle est l'utilité du cache et ce qui se passe s'il n'est pas disponible au boot.
zpool set cachefile=/root/newinstall/boot/zfs/zpool.cache
On remet les points de montage au bon endroit :
zfs set mountpoint=legacy zroot zfs set mountpoint=/usr zroot/usr zfs set mountpoint=/var zroot/var zpool set bootfs=zroot zroot zfs unmount -a
Et là on croise les doigts et on reboote.
Ceci permet de faire plusieurs choses :
Let's roll.
On copie notre racine actuelle dans un autre volume :
zfs snapshot zroot@1 zfs send zroot@1 | zfs receive zroot/slash zfs destroy zroot@1
Même chose pour
/usr :
zfs snapshot zroot/usr@1 zfs send zroot/usr@1 | zfs receive zroot/slash/usr zfs destroy zroot/usr@1
Bien sûr, même chose pour les autres FS si vous avez partagé votre
/usr en morceaux.
Il m'a été indiqué que renommer
zroot/usr dans
zroot/slash/usr
(avec
zfs rename) est plus rapide, et surtout évite d'oublier un
volume si
/usr a été fractionné.
On indique qu'on veut booter sur
zroot/slash :
zpool set bootfs=zroot/slash vi /slash/etc/loader.conf
Et on ajuste la valeur de
vfs.root.mountfrom.
On veut aussi changer notre
/usr :
zfs set canmount=noauto zroot/usr zfs set mountpoint=/usr zroot/slash/usr
À ce moment, on a
deux volumes montés sur
/usr. Ça marche, mais
c'est un peu bancal ; on va donc rebooter de suite. Quand la machine
revient, on vérifie avec
zfs list et
mount que tout est bien
monter là où on l'attend (l'un montre la configuration des points de
montage, et l'autre montre les vrais montages). On voit que
zroot/slash a un
mountpoint qui vaut
/slash, mais est monté à
/ en vrai. Je ne sais pas à quel point ça peut être gênant.
Pour vérifier que le volume
zroot n'est plus directement utilisé, on
va le vider puis vérifier que la machine revient au reboot :
zfs set mountpoint=/whatever zroot chroot /whatever rm -fr * # oups, il y a des fichiers avec l'option schg... ^D chflags -R noschg /whatever rm -fr /whatever/* zfs set mountpoint=none zroot rmdir /whatever zfs destroy zroot/usr reboot
(Attention si vous avez d'autres volumes qui héritent leur point de
montage depuis
zroot !)
Notez que je n'ai pas déplacé
/var, qui ne sera pas concerné par les
mises à jours. C'est peut-être un choix discutable.
Ensuite, il nous reste toutes les actions habituelles d'une installation FreeBSD :
/etc/rc.conf pour activer les services que l'on veut ;
Et moultes autres activités :)
Il arrive d'avoir besoin de se servir de navigateurs avec deux panneaux pour permettre d'y voir plus clair ou de comparer deux folders. Je vais en citer ici 3 différents que j'ai l'habitude d'utiliser, deux graphiques (dont un natif sur l'environnement gnome), et un en console.
Le premier est nautilus, navigateur par défaut sur gnome. On peut ajouter un panneau par affichage > panneau supplémentaire, ou directement par F3.

Le deuxième est emelfm2, qui a la particularité d'intégrer quelques raccourcis pratique en bas (ouvrir un terminal dans le répertoire courant, exécuter en root, ...) et qui intègre également un terminal, parfois bien pratique pour chercher rapidement ce que le navigateur n'affiche pas.

Le dernier, en console, est midnight commander, qui a menu très complet, permettant très simplement de compresser des répertoires et des fichiers, de copier un fichier d'un volet vers l'autre... Attention toutefois, pour quitter, il faut taper sur F10, qui est sur gnome-terminal le raccourci "menu" (il faudra donc penser à désactiver le raccourci F10 via édition > raccourcis clavier.

zsh est très connu pour son système de complétion très poussé. Malheureusement, zsh n'est pas équipé pour gérer les conventions d'appel de tous les outils qu'on peut trouver sur nos babasses. On peut donc être amené à écrire soi-même une méthode de complétion. Ces notes ont été prises à l'occasion de l'écriture d'un fichier de complétion pour ezjail, et les exemples viennent de là.
Il y a quelques cas où on n'a presque rien à faire pour bénéficier de
la complétion sur un nouvel outil. Par exemple, si un outil utilise
les conventions GNU, zsh peut parser la sortie de
--help pour
obtenir la liste des options existantes. Il suffit pour cela d'ajouter
quelque chose comme :
compdef _gnu_generic foo
dans un fichier lu par zsh (
.zshrc conviendra), et de relancer son
shell pour pouvoir compléter les options de
foo. On a même le droit
à la documentation des options.
Un autre cas où l'on n'a presque rien à faire est lorsqu'on peut réutiliser une complétion existante. Si un outil attend comme argument uniquement des noms d'hôtes, on utilisera :
compdef _hosts foo
Maintenant, en tapant
foo <TAB>, zsh proposera des complétions
basées sur les noms d'hôtes, trouvés par
`getent hosts` ou qui sont
dans l'une des bases
ssh_known_hosts entre autres.
Dans l'exemple au-dessus,
_hosts est le nom d'une fonction zsh, dont
la définition est (sur mon système) dans
/usr/local/share/zsh/4.3.11/functions/Completion/Unix.
La documentation de zsh donne un autre exemple assez courant : le cas d'une commande qui accepte tous les fichiers qui ont une certaine extension.
compdef '_files -g "*.h"' foo
Ici,
_files est encore une fonction, définie au même endroit que
_hosts (et bon courage à celui qui voudra se plonger dans le code de
cette fonction…). La documentation de cette fonction est visible
dans le manuel de zsh, au nœud «
Completion Functions >
Utility Functions ».
Lorsqu'on a des besoins plus poussés, au hasard pour un outil tel
qu'ezjail, on va devoir coder sa propre complétion. Une complétion
n'est en soi qu'une fonction zsh qui est appelée par le shell lorsque
l'utilisateur appuie sur
TAB (ou
C-d pour afficher les
complétions).
Les fonctions de complétions sont installées par défaut dans
/usr/local/share/zsh/site-functions/ (l'emplacement exact peut
dépendre de votre OS). Par convention, le fichier dans lequel vous
allez écrire votre fonction de complétion a le même nom que la
commande concerné, avec un
_ ajouté au début.
Lors du développement d'un fichier de complétion, il sera peut-être
plus pratique de pouvoir éditer le fichier sans être
root. Dans ce
cas, il suffit de choisir un dossier local, par exemple
~/zsh. On
placera le fichier de complétion dedans, et on l'ajoute au tableau
$fpath (bien sûr, à placer avant l'appel à
compinit) :
fpath=(~/zsh $fpath)
Notons que zsh refusera de charger des fonctions (donc des définitions de complétion) si le fichier appartient à un utilisateur autre que root ou l'utilisateur courant, ou s'il est modifiable par un autre utilisateur.
Le fichier de complétion commence avec un tag spécial sur la première ligne :
#compdef ezjail-admin
C'est un commentaire, qui indique à zsh que le fichier contient une complétion, et bien sûr quelle commande est concernée.
Ensuite, on définit une fonction de complétion, et on l'appelle :
_ezjail () {
# code de complétion
}
_ezjail "$@"
Notre code, ici la fonction
_ezjail, sera appelée avec quelques
informations sur la ligne de commande qui a déjà été saisie par
l'utilisateur.
Les informations qui sont accessibles depuis le code de complétion seront les suivantes :
| Variable | Description |
|---|---|
$words
|
Les mots déjà entrés par l'utilisateur |
$CURRENT
|
L'index, dans
$words, du mot que l'utilisateur essaie de compléter (c'est
$#words sauf si l'utilisateur est revenu en arrière)
|
$curcontext
|
Une chaîne de caractères, décrivant le contexte courant |
Le contexte courant est utilisé en interne à zsh pour savoir comment
interpréter les demandes de complétions. Depuis le code de complétion,
on passera aussi
$curcontext à
zstyle pour récupérer les styles de
complétion voulus par l'utilisateur. Comme je n'utilise pas
zstyle,
je ne me suis pas beaucoup avancé dans cette direction.
Si vous avez sous les yeux le
fichier de complétion d'ezjail, vous
verrez que la fonction principale,
_ezjail, fait un petit tour de
passe-passe sur ces variables pour sauter sur la fonction
correspondant à la sous-commande déjà entrée. La plupart des outils
pourront certainement se passer d'une telle manipulation.
Pour renvoyer à zsh les complétions elles-mêmes, on va utiliser l'une
des
fonctions de complétion. La fonction
_arguments sera notre outil
principal, en particulier pour les outils qui ont des options
standards.
Si l'on prend comme exemple la complétion (un peu réorganisée) pour
ezjail-admin create:
_ezjail_cmd_create () {
_arguments -s : \
"-i[file-based jail]" \
"-x[jail exists, only update the config]" \
"-a[restore from archive]:archive:_files" \
"-c[image type]:imagetype:(bde eli zfs)" \
"-C[image parameters]:imageparams:" \
"-s[size of the jail]:jailsize:" \
":jail name:" \
":comma-separated IP addresses:"
}
Le
-s donné à
_arguments permet de dire que pour cette commande,
les options courtes peuvent être combinées, i.e.
-ix est équivalent
à
-i -x. Le texte entre crochets est affiché à côté de la
complétion, sauf si l'utilisateur a désactivé cela.
Dans l'exemple au-dessus,
-i et
-x sont des options qui
n'attendent pas d'arguments. Les autres options attendent des
arguments : on les distingue parce qu'une description de l'argument et
une méthode pour compléter cet argument sont données, avec des
:
pour séparer les champs. Dans le cas de
-a, l'argument sera complété
par la fonction
_files, qui propose des noms de fichiers comme
choix. Dans le cas de
-c, la completion se fait sur un petit nombre
de choix possibles, qui sont donnés entre parenthèses. Pour
-C, on
indique qu'on attend un mot donné par l'utilisateur, mais le shell
n'aidera pas à le compléter.
Enfin, la commande prend encore deux arguments, mais on ne sait pas
offrir d'aide pour les compléter (il n'y a rien avant le premier
:).
Il peut y avoir des cas où des options sont mutuellement exclusives.
C'est le cas pour
ezjail-admin archive : ou bien l'on archive toutes
les jails avec
-A, ou alors on donne une liste de jails.
_ezjail_cmd_archive () {
_arguments -s : \
"-a[archive name]:archive name:" \
"-d[destination directory]:destination dir:_files -/" \
"-f[archive the jail even if it is running]" \
- archiveall \
"-A[archive all jails]" \
- somejails \
"*:jail:_ezjail_stopped_jails"
}
On sépare les groupes d'options qui s'excluent avec un tag (je ne sais pas si le nom est réutilisé pour être montré à l'utilisateur dans certaines circonstances). Les options qui peuvent toujours être utilisées sont données en premier. Remarquez au passage l'astérisque pour la dernière ligne : cela permet d'indiquer qu'on peut avoir des répétitions.
_values: plus simple
Lorsqu'on a juste une liste de mots à proposer, surtout si cette liste
est générée dynamiquement, les arguments pour
_arguments ne sont pas
faciles à manipuler. Dans ce cas,
_values, qui permet de simplement
donner la liste des mots candidats à la complétion, est plus facile à
manipuler. En prenant comme exemple
_ezjail, dans le cas où on
propose les sous-commandes, on a :
_ezjail () {
local cmd
if (( CURRENT > 2)); then
# déjà un mot complet sur la ligne; sauter à la fonction
# spécifique à cette sous-commande.
else
# on complète la sous-commande
_values : \
"archive[create a backup of one or several jails]" \
"config[manage specific jails]" \
"console[attach your console to a running jail]" \
"create[installs a new jail inside ezjail\'s scope]" \
"cryptostart[start the encrypted jails]" \
"delete[removes a jail from ezjail\'s config]" \
"install[create the basejail from binary packages]" \
"list[list all jails]" \
"restart[restart a running jail]" \
"restore[create new ezjails from archived versions]" \
"start[start a jail]" \
"stop[stop a running jail]" \
"update[create or update the basejail from source]"
fi
}
compadd: pour construire les complétions au fur et à mesure
compadd est le
builtin utilisé par
_arguments,
_values et les
autres fonctions pour ajouter les candidats à la complétion. Il y a
certains cas où il est plus facile d'ajouter un à un les candidats.
C'est le cas pour lister les jails : une première version utilisait
quelque chose de la forme :
_ezjail_running_jails () {
_values : `_ezjail_list_jails running`
}
_ezjail_list_jails () {
local jailcfgs="/usr/local/etc/ezjail"
local state=$1
local j
( cd $jailcfgs && echo * ) | while read j; do
case $state in
running) [[ -f /var/run/jail_${j}.id ]] && echo $j ;;
stopped) [[ -f /var/run/jail_${j}.id ]] || echo $j ;;
*) echo $j ;;
esac
done
}
Le problème est que lorsque la sortie de
_ezjail_list_jails est
vide,
_values remonte un message d'erreur parce qu'on ne lui a donné
aucun argument. Pour corriger cela, une première solution pourrait
être de capturer la sortie de
_ezjail_list_jails dans une variable,
tester si cette variable est vide ou non, et agir en conséquence. La
deuxième solution, qui est celle que j'ai retenu, est de faire ajouter
à
_ezjail_list_jails les complétions elles-mêmes. Il faut encore
gérer à part le cas où il n'y a pas de candidats à la complétion, en
revoyant 1 dans ce cas ; mais c'est plus facile à gérer. Au passage,
la première version ne renvoyait pas 1 en l'absence de candidates…
L'implémentation ressemble à ceci :
_ezjail_running_jails () {
_ezjail_list_jails running
}
_ezjail_list_jails () {
local jailcfgs="/usr/local/etc/ezjail"
local state=$1
local ret=1
local j
for j in $jailcfgs/*(:t) ; do
case $state in
running) [[ -f /var/run/jail_${j}.id ]] && compadd $j && ret=0 ;;
stopped) [[ -f /var/run/jail_${j}.id ]] || compadd $j && ret=0 ;;
*) compadd $j && ret=0 ;;
esac
done
return $ret
}
compadd, en tant que brique de base, permet bien plus que de
simplement ajouter un candidat. Encore une fois, allez voir la
documentation pour tous les détails.
Le code de complétion est lancé à chaque fois que l'utilisateur
tapotte sa touche
TAB ou
C-d. Le code doit donc être
raisonnablement rapide.
Par ailleurs, le code de complétion s'exécute dans le shell courant de l'utilisateur. En particulier :
exit ;
std{out,err} sans faire une
horrible mixture entre le prompt, les propositions de complétion et
ce qui est affiché ;
local,
pour éviter d'écraser ou de polluer les variables du shell courant
de l'utilisateur ;
Il y a également
completion-style-guide, qui est chez moi dans
/usr/local/share/doc/zsh (
copie en ligne), qui donne des conseils.
J'ai découvert ce fichier un peu tard, et la complétion pour ezjail
ne suit pas toujours à la lettre les conseils donnés.
Bien sûr, lorsqu'on a quelque chose qui marche, on le propose au
projet en question, ou alors directement sur la liste
zsh-workers@,
pour en faire profiter les petits copains.
A User's Guide to the Z-Shell, Peter Stephenson, Chapter 6: Completion, old and new. Il y a en particulier un tutorial bien fait.
The Z Shell Manual,
20. Completion System, et en particulier
20.6 Utility Functions. Vous en avez certainement une version accessible en
local avec
info zsh (ou
C-h i m zsh depuis
emacs). Le manuel est
assez aride, je ne l'ai utilisé que comme référence.
zsh completion support for ezjail , de votre serviteur.
Récemment, j'ai eu à convertir un fichier .wav 32 bits en un fichier mp3. Habituellement j'utilise lame dans une console comme convertisseur mp3, mais avec un wav 32 bits en input ça ne semblait pas marcher :
$ lame file.wav Unsupported data format: 0x0003
Allons bon, lame va pas bien, c'est pas grave, on va faire du ogg :
$ oggenc file.wav
Omition d'un tronçon de type « JUNK » et de longueur 4042
Ouverture avec le module wav : WAV file reader
Encodage de "file.wav"
en "file.ogg"
à la qualité 3,00
[ 22,7%] [ 0m42s remaining] - ^C
Ça marche avec le ogg, pas la peine d'attendre que ce soit fini. N'empêche que j'ai toujours pas mon mp3 parce que lame ne veut pas traiter du wav 32 bits. Solution de secours : utiliser sox, packagé dans sox :
$ aptitude search sox (...) c sox - Swiss army knife of sound processing
Et maintenant passons à la conversion du wav 32 bits en wav 16 bits, à 44,1kHz :
$ sox file.wav -b 16 ~/tmp/file2.wav rate -I 44100 dither -s sox WARN dither: dither clipped 23 samples; decrease volume?
Remarquez le dernier message : le fichier son a clippé (saturé) sur 23 échantillons. On va refaire la conversion, mais cette fois-ci en diminuant le gain de 1dB :
$ sox file.wav -b 16 ~/tmp/file2.wav gain -1 rate -I 44100 dither -s $
Cette fois c'est parfait ! plus qu'à passer une couche de lame et ça marche sans souci.
L'info fait le tour des blogs sur emacs: emacs est utilisé dans Tron 2.0. Plus précisément, eshell est utilisé pour tuer la vidéo que Sam Flynn utilise pour se moquer du conseil d'administration. jtnimoy, derrière les effets spéciaux du film, donne tous les détails.
emacs était déjà visible dans The Social Network, où
Big
Brother
Zuckerberg dit qu'il est «
temps de sortir emacs pour modifier un script Perl ».
emacs est une star, vi ne peut vraiment pas en dire autant…
ezjail (sur la documentation duquel votre serviteur a pas mal travaillé ces derniers temps) est un outil d'administration des jails pour FreeBSD. Dirk Engling a ajouté il y a peu la possibilité de mettre à jour le système de base des jails en utilisant FreeBSD Update (c'est dans le CVS, pas encore dans la dernière version d'ezjail). Il est donc possible de passer son serveur FreeBSD avec ses jails d'une version à l'autre sans avoir à compiler quoi que ce soit.
Quelques petits rappels pour les malheureux Linuxiens qui ne
connaîtraient pas les
jails de FreeBSD. Les
jails de FreeBSD sont
parfois comparées à des
chroot sur stéroïdes ; maintenant que Linux
a des choses telles qu'OpenVZ ou LXC, il faudrait plutôt utiliser cela
comme comparaison.
Les
jails pour FreeBSD ont été introduites dans FreeBSD 4.0
(mars 2000) par Poul-Henning Kamp (le développeur derrière UFS2 et pas
mal de code tournant autour du stockage disque, l'auteur du
malloc(3) de FreeBSD, du cache Varnish, et l'inventeur de
l'expression
bikeshedding
). Une
jail est définie par :
/etc/rc pour lancer un FreeBSD
complet.
Depuis l'intérieur de la
jail, il est impossible de sortir du
dossier racine, contrairement à un
chroot(2). Les processus tournant
à l'intérieur de la
jail ne peuvent utiliser que les adresses IP
attribuées par l'administrateur pour se connecter ou accepter des
connexions externes.
Le dossier attribué à une jail peut être tout petit (une dizaine de fichiers, comme le décrit Bapt dans ses NANO Jails), ou contenir un système FreeBSD complet (voire un système CentOS, en utilisant la couche d'émulation de Linux).
Pour des jails contenant un système FreeBSD complet, on voit qu'il peut rapidement y avoir quelques difficultés d'administration :
ezjail propose une solution à tout cela, et notamment aux deux
premiers points en utilisant
mount_nullfs(4) (l'équivalent du
mount -o bind de Linux) pour fournir à toutes les
jails une unique
installation de FreeBSD en lecture seule ; cette installation est
appelée la
basejail. ezjail a un certain nombre d'autres
fonctionnalités, que je ne déveloperai pas ici.
Depuis l'introduction de FreeBSD Update, il est possible de mettre à jour son OS diabolique, y compris d'une version à l'autre. La procédure est décrite à chaque fois dans l'annonce de sortie, mais se résume à :
freebsd-update -r 8.2-RELEASE ;
freebsd-update install, et
rebooter sur le nouveau noyau ;
freebsd-update install ;
Comme nous l'avons dit au début, ezjail dans sa version CVS permet de mettre à jour la basejail à partir de FreeBSD Update. Le port ezjail n'a pas encore été mis à jour. J'ai un port local d'ezjail, qui installe directement à partir du CVS.
Une fois la version CVS d'ezjail installée, la mise à jour se fait tout simplement :
# ezjail-admin update -s 8.1-RELEASE -U
On notera qu'il est nécessaire de donner la version actuelle de la
basejail : FreeBSD Update utilise en temps normal
uname -r pour
connaître la version actuelle de la machine, ce qui n'est bien sûr pas
possible dans une
jail, puisque
uname va renvoyer la version
du noyau de l'hôte, et non de l'espace utilisateur de la
basejail.
Un problème :
freebsd-update(8) détecte les composants installés à
partir de deux choses : la ligne
Components dans
/etc/freebsd-update.conf, et ce qui est réellement sur le disque.
Cependant, le noyau est géré un petit peu à part, et est ajouté aux
composants à mettre à jour si
Components liste
kernel et si la
nouvelle version vient avec un nouveau noyau, même si le noyau n'est
pas installé sur la cible. Bien sûr, vouloir mettre à jour le noyau
dans une
jail ne va pas donner grand'chose… Ma solution a été de
supprimer
kernel des composants potentiellement installés. À terme,
il faudra probablement qu'ezjail lance
freebsd-update avec un
fichier de configuration à lui.
ezjail a depuis longtemps la possibilité, avec
update -p, de mettre
à jour l'arbre des
ports ; mais pour mettre à jour les
ports
eux-mêmes, rien de spécial n'est prévu. La technique habituelle,
lorsqu'on a beaucoup de machines, est de consacrer une
jail à la
compilation de
ports, et d'utiliser
pkg_create -b pour créer des
packages qu'on distribue ensuite aux autres
jails.
Choisir un projet pour se lancer dans l'agilité peut être un véritable casse-tête. Tous les projets ne sont pas de bons candidats ; il faut trouver un compromis entre taille, durée, criticité et soutien du métier (cf figure ci-dessous). Impossible ? C'est sans doute vrai. Pourtant, un de vos futurs projets peut s'approcher de cet équilibre. Mieux vaut se lancer plutôt que d'attendre éternellement le projet idéal. Voyons comment trouver le barycentre de ces critères.

Si vous choisissez un projet trop court, les sceptiques vont clamer haut et fort que Scrum ne fonctionne que pour les petits projets. À l'inverse, si vous optez pour un projet trop long, vous risquez de ne pas pouvoir montrer votre succès avant son terme. On compte 9 à 12 mois en moyenne pour un « projet traditionnel » ; où budget et deadline sont souvent dépassés. Il serait dommage de lancer un projet Scrum en annonçant le même timing qu'un projet classique et donc entouré des mêmes doutes. L'idéal est de choisir un projet de moitié plus court qu'un projet classique ; 3 ou 4 mois suffisent généralement à prouver que l'application de Scrum est concluante et le serait pour une plus longue durée.
Choisissez un projet qu'il est possible de commencer avec une seule équipe dont tous les membres sont colocalisés. Si la taille du projet vous sembler nécessiter plusieurs équipes, débutez tout de même avec une seule et limitez vous dans le nombre d'équipes, même si votre organisation a l'habitude de réaliser des projets de très grande envergure. Les soucis de coordination ne doivent pas être un frein pour ce premier projet agile.
Quand on expérimente, on a tendance à le faire sur quelque chose qui n'a pas d'importance et qui comporte peu de risques. Si les choses tournent mal, on aura perdu peu et avec de la chance personne n'aura rien remarqué. Ne cédez pas à cette tentation ! Allez à l'encontre de cela et choisissez un projet important. Si votre projet n'a pas de valeur, personne ne lui accordera d'attention au sein de votre entreprise. Et, comme la transition d'une équipe classique vers une équipe Scrum est exigeante, les protagonistes ne feront pas les efforts nécessaires si le projet n'apporte rien. Jim Highsmith, pionnier de l'agile et inventeur de « l'adaptative software Development process » nous met en garde sur ce sujet :
Ne commencez pas avec un projet pilote qui est marginal. Commencez avec un projet qui est critique pour votre société, sinon il sera trop difficile de faire tous les efforts que l'implémentation de la méthode requiert.
L'adoption de Scrum requiert un investissement total du métier. Avoir quelqu'un qui a le temps et l'envie de travailler avec l'équipe est absolument critique. Un sponsor côté métier peut aider à franchir les barrières organisationnelles et humaines inhérentes à toutes les entreprises. En cas de succès, il sera également le mieux placé pour promouvoir l'agilité en interne et pour évangéliser ses collègues, qui à leur tour seront enclins à tester l'agilité dans leurs équipes.
J'aborde ce point en dernier, mais c'est sans doute celui qui me tient le plus à cœur. Le choix de l'équipe est avec le choix du PO un des des facteurs clés de réussite. Et c'est valable pour tous les projets informatiques, agiles ou non. À l'instar d'un film, un scenario magnifique au casting désastreux ne donnera pas grand chose ; un scénario léger porté par des acteurs fabuleux lui donnera une âme. Dans notre cas, le métier va esquisser un scénario puis va l'affiner et l'adapter au fur et à mesure. Les membres de l'équipe, comme des acteurs, vont chercher à bien comprendre le scénario avant de le jouer. Ils vont être capables d'apporter leurs idées pour faire évoluer le projet dans le bon sens. Ils seront les artisans de leur propre succès.
Vous aurez donc compris l'importance du casting de l'équipe pour votre projet pilote. À ce sujet, je vous invite à lire le livre de Guillaume Bodet « Scrum en action » qui explique très bien comment repérer des profils agiles dans une équipe de projet classique.
D'après l'article de Mike Cohn : Four Attribute of the Ideal Pilot Project
La première chose au programme de ce billet, c'est apprendre à lire un log en temps réel (par exemple ici le fichier squid.log, généré par un squid et complété en continu) :
tail -f squid.log
Ça marche, mais compliquons un peu l'hypothèse de départ. On ajoute au système un logrotate qui va faire tourner le log toutes les 5 minutes (et qui va renommer squid.log en squid.log.YYYYMMDD.HHhMMmSSs). Si on continue avec notre tail précédent, toutes les cinq minutes on sera bon pour le relancer (le flux est cassé à la rotation). Heureusement, tail a une autre option, qui est plus robuste face à la suppression du fichier qu'on regarde :
tail -F squid.log
Et là c'est gagné. Maintenant, on va encore compliquer un peu et on va garder uniquement les lignes qui nous intéressent (qui contiennent le mot "motif"). Habituellement, quand on cherche une chaine de caractère dans un fichier de log en temps réel, on a tendance à grepper simplement :
tail -F squid.log | grep motif
Mais si on a face à nous une ligne qui se présente ainsi, on peut matcher des lignes qui ne vont pas forcément nous intéresser :
2011-02-21 15h54h10s motif_qui_nous_intéresse blabla blibli 2011-02-21 15h54h10s blabla motif_qui_ne_nous_intéresse_pas blibli
On a ici des lignes avec 5 colonnes séparées par des espaces, on veut uniquement grepper sur "motif" dans la troisième colonne :
tail -F squid.log | awk '$3 ~ "motif"'
Et éventuellement, si la colonne 4 ne nous intéresse vraiment pas, on peut même profiter du awk pour seulement afficher ce qui est pertinent :
tail -F squid.log | awk '$3 ~ "motif" {print $1,$2,$3,$5}'
J'en profite pour faire passer un rappel sur grep : non, on ne fait pas un cat pipe grep, un grep "motif" "fichier" suffit amplement, vous risquez de vous faire pendre ou brûler si vous osez faire ça.
Et en cadeau, un mémo sur awk : http://www.shellunix.com/awk.html
Un petit mot quand même pour décrire la vie ici, d'un point de vue très extérieur...
Déjà, KarmaLing c'est pentu... 40m de dénivelée entre ma voiture et le chalet, et 30m entre le bureau et le chalet, autant dire que ça muscle les jambes et que j'ai fait pas mal de progrès ! Niveau météo, il[...]
Les rituels
Après un peu d'acclimatation, je pense qu'il est temps de décrire un peu ce qu'on voit ici, d'un point de vue extérieur, car je me suis aperçu que je ne l'avais même pas fait... Par contre évidemment tout cela est à prendre avec des pincettes, étant donné que ce n'est pas très[...]
It finally happened!
I would like to thank all my sponsors since my starting contributing to Debian in 2006. Also, cheers to my AM, Adeodato Simó (dato). It has been quite a long NM process due to us both being quite busy with other things but all in all it has been a very pleasant experience.
Cette semaine, un petit compte rendu de la rencontre fort intéressante avec les franc-maçons, vu que la franc-maçonnerie génère quand même beaucoup d'interrogations auxquelles j'ai quelques pistes de réponses... petit aperçu pas très bien écrit :
- la franc-maçonnerie est vue par certains de[...]
With work taking most of our time lately, my girlfriend and I needed to find as many ways as possible to change our minds once we were back home. This is how we found a real enjoyable online RPG called Nodiatis.
The game has reached quite a high level of maturity. There is a large community of players and the game allows a great deal of different characters' builds ranging from the basic but very efficient warrior to the more difficult to play but, in my opinion, more interesting to play spell caster.
With as many as 26 classes and a whole load of different skills, this is one of the richest web-based online RPG we have ever played.
Ok... Even though I am extremely busy and have had very little time to do anything Debian-related lately, I guess I'll have to do this one day or another, so here it is.
I created a new GPG key which I am transitionning to and I have prepared a transition document signed by both keys.