Pour changer de la technophilie...

J'avais promis une réponse à Rémi Grossmann, suite à la publication d'un de ses billets  qui m'avait passablement énervé. Il m'aura fallu quelques temps... mais finalement, je tente de passer l'épreuve de la modération, pour publier le premier commentaire sur ce, peut être, futur grand blog politique en Suisse.

Le sens du sacrifice... tout un programme, n'est-ce pas ? Après une énième relecture, je me décide finalement à poster une réponse. Après tout, j'avais dit que je le ferais ;-) . Ça arrive juste un peu plus tard que prévu.

Le premier point abordé, ou plutôt survolé, dans la première partie de ce billet, est bien sur celui qui me dérange le plus, et de très loin. Car après tout, une arme est une arme. J'ai du mal à faire la différence entre un fusil d'assaut et une mine anti-personnelle. Vraiment.

Les deux peuvent tuer, blesser, mutiler, au choix. Le problème de la mine étant qu'elle mutile trop souvent. Donc pour faire semblant de se donner bonne conscience, les "pays qui respectent les droits de l'homme", certaines armes à caractère mutilant ne sont plus produites dans certains pays, selon les termes d'accords dont je ne connais pas le contenu exact. Par exemple, la France, pour ne pas parler que des territoires neutres, ne fabrique plus de mines anti-personnelles. Les guerres doivent être propres pour que TF1 puisse les couvrir pendant le JT de 20h.

Pourtant une arme reste une arme. Là  où les fusils et les chars que la Suisse vend vont prendre des vies, les mines les détruiraient. Je ne vois pas en quoi la mort est plus louable. Les deux sont, à mon avis, aussi grave, aussi condamnable. La mort ne fait partie du respect ni de l'homme, ni du citoyen.

Le respect des droits de l'homme passe peut être pour toi par le refus de vendre des armes à des pays en guerre. Pourtant, des nuances existent. Sur les conflits internes, par exemple. Et sur les garantie qu'en acheteur donnera de ne pas revendre le matériel à des nations ou groupuscules aux velléités moins louable que la simple protection du territoire. Tu auras du mal à me faire croire que la Suisse a les moyens de contrôler la destination finale des armements vendus. Notamment parce que des dérives semblent avoir eu lieu par le passé.

Car les armes produites en les contrées helvètes sont, finalement, vendues. Et que rien ne garantit qu'elle ne finiront pas dans les mains de terroristes/rebelles/braqueurs de banques/mafioso. Une arme, ça se vole. Un stock d'arme, ça se détourne.

Effectivement, nous parlons ici d'arguments moraux, là où tu nous opposes clairement des arguments pratiques : l'arrêt de la production d'armes serait catastrophique économiquement. Et pourtant...

Tu parles de dizaines de milliers d'emplois supprimés. Il semblerait (source à vérifier, cependant, l'article où j'ai obtenu le chiffre ne cite pas ses sources) que les opposants à l'arrêt de la vente d'arme à l'étranger, lors de la dernière votation, évaluait le nombre de ces emplois à 10 000. On change d'échelle, déjà. Mais j'admets que 10 000 vies mises à mal de cette façon, ça me trouble.

Cependant... nous parlons bien d'un pays prospère économiquement, n'est-ce pas ? Je tiens à être sûr... La Suisse, à mon avis, a tout à fait les moyens de créer la richesse d'innovation nécessaire au retour de ces 10 000 emplois. Des défis technologiques d'ampleur sont là, et doivent être soutenus. Certains ont même des dimensions morales. D'ailleurs, je pense que la structure étatique de la Suisse, par son découpage en cantons, est adaptée à l'éclosion de startups performantes, grâce à des encadrements ciblés et efficaces.

Tu opposes les objectifs moraux (ou philosophiques, les deux choses sont pourtant différents, mais admettons que je les ai plus ou moins amalgamés ici) et pratiques, économiques. Je soutiens que les défis que posent les réflexions philosophiques ou morales permettent de construire des projets ambitieux, car ils soulèvent des buts autrement plus nobles, autrement plus soutenables que la simple vénalité.

L'économie ne peut pas tout justifier. Sinon, autant vendre ses enfants au marché...

zypper est surpuissant...

Pour les gens qui ne seraient pas au courant, openSUSE 11.3 est sortie tout récemment. Et contrairement à mes habitudes, je ne l'ai pas installée de suite, ma machine personnelle étant actuellement ma machine de boulot...
Pas grave, me dis-je : j'ai voulu profiter de la bande passante phénoménale de l'école qui m'emploie en ce moment. 2 Go de mise à jour, normalement, fait en une demi-heure... donc début d'installation à 17h. Et hop, zypper dup.

À 17h50, je quitte le bureau... et la mise à jour n'était pas finie (merci latex...). Je dois donc débrancher le câble réseau, en faisant le pari :

"Zypper va y arriver..."

Arrivé chez moi, je sors la machine de sa veille... et plus de clavier. Arrêt brutal de la machine, il me manque à peu près 300 paquets, dans le lot... Donc redémarrage. Je retrouve mon clavier, mais pas d'interface graphique (KDE était pas content... étrange :-p ). Console virtuelle, deuxième zypper dup...

Au fur et à mesure de l'installation, j'ai commencé à retrouver des fonctionnalités. Après installation propre de kdm, j'ai pu accéder à un bureau, puis à firefox. Et à la fin, redémarrage... et tadam, j'y suis. Je roule sur une 11.3 toute fraîche.

Donc dans l'histoire, zypper a réussi à reprendre un upgrade (pas une simple mise à jour, hein, un upgrade) après une mise en veille ratée et un redémarrage.

Chapeau.

Reverse engineering

Je suis, en ce moment, plongé assez profondément dans l'étude des codes d'un logiciel complexe. L'objectif est d'extraire un bout de librairie pour travailler aussi bien, mais en codant moins. Je vous rassure, c'est un logiciel libre, il s'appelle BEAM. Et c'est pour inclure dans un autre logiciel libre, donc ça va ;-)

Le problème, dans ce petit exercice, c'est la taille des codes... J'ai un peu plus de 1700 classes (sans compter les classes de test, d'ailleurs), au total. Et c'est pas forcément évident de comprendre les liens entre les classes et package. Bref, il me fallait un logiciel de reverse engineering performant, pour pouvoir faire de l'UML vite et gagner du temps.

J'ai cur pouvoir compter sur ArgoUML. Et ben non. face à la taille de la tâche, ce cher logiciel me claquait dans les pattes. Il commençait par passer une bonne demi-heure à mouliner (et pourtant mon dual-core ne fait pas semblant de compter, en général... :-p ), et à la fin, il n'était plus franchement utilisable. Après, c'est peut être de ma faute, mais bon...

Du coup, changement de plan, je cherche un suppléant. Et je tombe sur BOUML. J'étais plutôt sceptique, au début, l'expérience précédente m'avait refroidie. D'autant que le logiciel, écrit en C, s'appuie sur qt3, et que c'est pas forcément très courant sur ma machine. Mais je me dégonfle pas, je le cherche dans mes dépôts. Et je l'installe, ni une ni deux.

Après un peu de prise en main, je trouve une bonne méthode pour faire l'import des classes qui m'intéressent intelligemment. Je commence par spécifier l'ensemble du jdk comme bibliothèque de base. Pas d'objections. Puis j'ajoute les dossiers contenant les sources en omettant juste les classes de test. Toujours pas d'objections. Je lance l'opération... et en cinq minutes c'était fait.

Je me retrouve donc avec un logiciel libre (j'ai du oublier de le dire avant ^_^ ) hyper efficace. Mes classes sont toutes là, liées entre elles et avec les classes du jdk. Les imports sont hyper rapides, et le logiciel sait résoudre les dépendances sur plusieurs niveaux. Tout petit bémol : au-delà d'une centaine de classes affichées simultanémént, il commence à ramer un peu... mais un diagramme de classe avec autant de monde, c'est pas super rationnel :-p

En clair, c'est un très bon logiciel. Pour les gens qui ont besoin de ce genre de choses... il vaut le coup :-)

MPD, MPC, Intel et openSUSE...

Sacré quartet évoqué dans le titre. Petits rappels. Pour les deux premiers, au moins. MPD, pour Music Player Daemon, est comme son nom l'indique une programme tournant en tâche de fond, qui permet d'émettre de la musique vers une sortie choisie. On peut même l'utiliser comme base pour faire de la diffusion par le réseau. Non, ne partez pas, c'est pas le but, ici.
Pour contrôler MPD, on peut utiliser un logiciel adéquat. certains sont graphiques, pas celui que j'utilise. L'objectif estt de libérer de la mémoire, afin d'être vraiment à l'aise en utilisant Eclipse, OpenOffice, Firefox, ArgoUML, Kate, tous avec pleins de trucs d'ouverts... Donc j'économise sur le lecteur audio. Même au niveau de l'interface. Mpc est donc fait pour moi :-).

Je vais d'abord vous montrer comment j'ai fait marcher le machin, chez moi, sur une carte son Intel. J'ai du tatonné un peu, ça m'arrivera pas deux fois ;-) . Et vous l'aurez compris, je vais présenter les manip's sur une openSUSE, avec des opérations tout à fait typiques de cette magnifique (et VERDOYANTE) distribution GNU/Linux. Pour les autres, vous pourrez aussi trouver quelques petites choses utiles à la fin. Peut être.

La partie facile : l'installation des deux logiciels. Un simple

zypper in mpc mpd

et le tour est joué, zypper est incroyable.

Pour la suite... MPD s'appuie sur une base de données où il garde les infos sur votr base de données. Il va donc falloir qu'il soit capable de trouver le fichier où est la base, et d'écrire dedans. D'ailleurs ce sera pas le seul fichier utile.

Créez un répertoire .mpd dans votre dossier personnel, et ajoutez-y des fichiers nommés database errors.log log mpd.log state tag_cache
Pour créer un fichire vide, par exemple database, faites
touch database
Ajoutez enfin un répertoire nommé playslists. Pour tous ces éléments, une petite modification s'impose encore. Placez vous dans le répertoire .mpd
cd ~/.mpd
Nous alons changer les droits sur les fichiers créés avant. mpd sera lancé par l'utilisateur mpd, qui appartient au groupe audio. Donc on modifie les droits d'accès en conséquence :
chown mpd:audio *

La suite est un peu sale. L'utilisateur et le groupe doivent avoir accès en lecture et écriture. Donc
chmod ug+rw *


Et il faut pouvoir rentrer dans le dossier. Donc
chmod a+x playlist
Et on arrête de donner des droits d'accès à tort et à travers (parceque c'est pas optimal. Mais y a mieux, et j'ai pas cherché ;-) )

La chose n'est toujours pas prête. On va devoir modifier le fichier de configurattion de MPD, qui se situe dans /etc. Avec nano pour moi, ce que vous voulez pour vous, mais il faut être root ;-) :

nano /etc/mpd.conf
vous allez modifier les valeurs suivantes :
music_directory : l'endroit où est votre musique, sur votre disque.
playlist_directory : Vous devez pointer le répertoire playlist créé précédemment. Donc a priori :
"/home/votrelogin/.mpd/playlist/"

db_file : "/home/votrelogin/.mpd/database"
log_file : "/home/votrelogin/.mpd/log"
state_file : "/home/votrelogin/.mpd/state"

J'ai laissé la variable pid par défaut, à savoir "/var/lib/mpd/mpd.pid", mais j'ai du créer le fichier qui va bien, je crois. dans le doute :
touch /var/lib/mpd/mpd.pid

user : laissez "mpd", on a fait les modifs pour ;)

Pour les utilisateurs d'une carte son Intel de type ICH9 (ou plus généralement celle qui utilisent le module snd_hda_intel), la section audio output devra ressembler à ça :

audio_output {
type "alsa"
name "Intel G45 DEVCTG"
# device "hw:0,0" # optional
format "44100:16:2" # optional
mixer_device "default" # optional
mixer_control "Master" # optional
mixer_index "0" # optional
}

Je sais, c'est étrange de virer la section device. Mais chez mois ça marche comme ça :-) .


À ce stade, la chose est prête à être lancée. Dans une console root :
mpd --create-db
rcmpd start
devrait passer sans problème. On crée ensuite la collection :
mpc update

Enfin, quelques petits trucs. J'aime bien être efficace, donc les deux scripts suivants peuvent être tout à fait pratique :

#!/bin/bash
if mpc |grep -q paused
then
mpc play
else
mpc pause
fi

ce script, que j'ai magnifiquement appelé pause, met en pause la lecture si mpc lit un fichier, et la remet en marche si mpc est en pause.

#!/bin/bash
if mpc|grep -q 'random: off'
then
mpc random on
else
mpc random off
fi
De même, ce programme (que j'ai nommé random) active ou désactive la lecture aléatoire.

Placez les deux scripts dans /home/votrelogin/bin . et rendez les exécutables avec un chmod u+x, aussi ;-) . L'avantage de les mettre dans ~/bin, c'est que vous pourrez les appeler très vite. Sous KDE, vous pourrez même utiliser le lanceur d'applications. Bref, la vie est belle :)

Enfin, j'ai aussi quelques petits alias (qui ne sont utilisables que depuis une console où vous êtes loggés en votre nom ). À mettre dans .bashrc (qui peut être créé pour l'occasion). :

alias next='mpc next'
alias stop='mpc stop'
alias play='mpc play'



Une dernière chose pour la route : mpd est un démon, il peut être lanccé automatiquement au démarrage. Pour les gens de chez suse, passez par YaST, trouvez le module qui gère les niveaux d'exécution, passez en mode expert, et cochez les cases 3 et 5 pour mpd. Prudence, cependant, si le démon est arrêté alors qu'une lecture est en cours, elle sera reprise automatiquement au démarrage suivant. Donc pour la discrétion... ;-)

Amusez-vous !

Montage automatique d'un périphérique... depuis la console.

Y a des jours où c'est pas facile... quand il s'agit de faire de l'aide sur IRC, en général, ça va, quand les gens ont un minimum de connaissance... mais parfois... et allez expliquer comment monter simplement un périphérique, avec un utilisateur qui n'est pas capable de trouver le nom du disque en question, et encore moins l'identifiant des partitions qu'il contient...

Du coup, après plus d'une heure perdue, ou presque, à essayer de glaner des infos pour lui faire faire les bonnes manip' avec mount, j'ai fini par me demander quel outil simple existait pour remplacer les gestionnaires d'évènements HAL présents dans KDE ou Gnome.

Un petit tour... sur IRC :D et je trouve une réponse satisfaisante (en moins de trente secondes, efficacité raisonnable :p )

On va utiliser un script Python, nommé halmount. Faut l'installer, d'abord, il est dans le paquet ivman :

zypper in ivman

Ensuite...

man halmount nous donne des informations utiles. Notamment si on veut, ce qui est le cas de mon utilisateur débutant, monter tous les machins présents automatiquement.

halmount

nous liste les possibilités,

halmount -a

monte toutes les choses non montées et montables automatiquement

Amusez vous !

Lancer une application graphique par SSH

Chose assez inhabituelle pour moi, j'ai deux machines qui tournent bien à disposition. Donc je peux m'amuser un peu avec... Question du jour : comment lancer une application graphique au travers de SSH, sans VNC ou autre outils de ce genre... Le but étant... euh... bon, y a pas vraiment de but. Mais je suis sur que ça peut servir.

Première chose : je pars du principe que vous savez activer sshd correctement sur la machine serveur, et ce avec ouverture du pare-feu. Pour les utilisateurs d'openSUSE, c'est assez simple : dans YaST, Pare-Feu, Services autorisés, ajouter SSH dans la zone externe. Et configurer votre interface réseau pour qu'elle soit dans la zone externe (ce qui est bien plus sûr, en passant... ;-) )

Une fois la chose faite, sshd et X11 démarrés sur le serveur, placez vous sur la machine cliente, ouvrez un terminal, et lancez la connection ssh :
ssh -X user@machine

Je pars du principe que user a les sur X11... Notez le "-X" dans la commande qui va permettre d'importer les variables relatives à l'environnement graphique.

Jusque là, ça va... Nous allons maintenant devoir autoriser les directives allant vers le serveur X à être prises en copte depuis notre machine. Supposons que notre machine s'appelle patate . À travers la connexion SSH, nous autorisons patate à lancer des commandes faisant intervenir X11 :
xhost +patate
Nous supposons ici que le serveur connaît le nom de notre machine. Si ce n'est pas le cas, utilisez une adresse IP, par exemple :
xhost +192.168.0.10
Ce n'est pas fini, cependant... les variables X11 actuelles sont relatives à la machine cliente... il va donc falloir changer un peu les choses  en corrigeant la variable DISPLAY :
export DISPLAY=:0.0
Et normalement, c'est bon... :-) pour tester, lancez xterm depuis la machine cliente :
xterm
Mieux, xdg -open marche tout à fait convenablement de cette façon :-)

Amusez vous !

Installation d'awesome pour openSUSE 11.2

En traînant sur des blogs, je suis tombé sur la page d'awesome, un bureau qui se présente comme étant un gestionnaire de fenêtres hautement configurable hautement novateur, et particulièrement adapté pour les développeurs. Comme j'aime bien me faire chi** à configurer ce genre de choses, je décide de l'installer. Coup de chance, il est dans mes dépôts, donc un
zypper in awesome
a suffi. Pour ceux qui n'ont pas cette veine, passez par ce site pour la recherche de paquets. Ou ajoutez le dépôt X11, et faites l'install avec zypper.

Et là, problème : utilisateur de KDE, je ferme ma session, me retrouve dans KDM, et pas de traces d'awesome... erf. Du coup, je fouine un peu, et je me retrouve à rajouter un fichier dans
/usr/share/kde4/apps/kdm/sessions/
C'est le répertoire où KDE va regarder, pour savoir quels sont les environnements de bureaux installés. Pour chaque bureau, un fichier .desktop. Donc on rajoute un fichier
awesome.desktop
et on met les choses suivantes dedans :
[Desktop Entry]
Encoding=UTF-8
Name=awesome
Comment=awesome
Exec=awesome
Type=XSession
TryExec=awesome
Et o ntrouve enfin awesome dans la liste des bureaux disponibles. Pour la suite (l'utilisation) reportez vous aux manuels divers. Mais je confirme : ça a l'air hautement cool :)

Amusez-vous!