Je code donc je suis

Pour ceux qui ont des problèmes lors de la signature en ligne de leur déclaration d’impôts sous Linux voici la solution.

source

Je viens de découvrir la polémique qui a animé le début du mois sur le clip Stress du groupe électro Justice par Romain Gavras.

Je dois dire que passé la vision au 1er degré qui ne peut que choquer, 3 tips sautent aux yeux à la fin. Le preneur du son qui prend feu, la caméra pétée et la phrase de fin ‘Ça te fait kiffer de filmer ça, fils de pute?’.

C’est clairement une critique du voyeurisme des médias. La caméra est tout autant un protagoniste si ce n’est l’acteur principal au regard concupiscent.

A ce propos je me souviendrai toujours d’un “reportage” diffusé en plein JT il y a bien 15 ans qui montrait une jeune fille dans un pays étranger les jambes prises sous un arbre dans une énorme flaque boueuse que les gens n’arrivaient pas à sortir et qui s’est noyée en direct … Polémique à l’époque ? non. Là ce n’était pas une fiction, information non pertinente, du voyeurisme ultra-violent pur et dur.

Alors polémiquer sur une fiction qui ose balancer un miroir aux médias TV, il y a de quoi sourire.

A lire ce commentaire très pertinent sur Rue89

Le Linutop est un très petit PC sans écran et disque dur. Il est commun de l’utiliser comme poste de travail léger, essentiellement avec un navigateur web. Il est fourni avec une clé USB avec un Linux installé et une interface XFCE.

J’ai acheté il y à quelques temps la V1 et il me semble intéressant de faire part de l’usage que j’en fais. Je ne souhaitais pas l’utiliser comme poste de travail mais aussi comme serveur léger. Il consomme très peu (moins de 5wats) ce qui permet de le laisser constamment allumé, sans soucis de bruit et d’encombrement.

Tout d’abord il est nécessaire d’installer sur un disque USB externe une distribution si on veut l’exploiter au mieux (notamment les mise à jour de l’OS et l’installation de paquets sans être limité par l’espace disque alloué à l’OS sur la clé USB). Il suffit d’un simple boot sur un live CD depuis un PC et une installation sur le DD externe. Attention si l’on souhaite également utiliser le linutop comme poste de travail il est nécessaire d’installer une distribution récente. En effet le driver AMD/Geode pour X est buggué dans les plus ancienne, il est corrigé dans la Ubuntu 8.04 par exemple.

Ensuite le Linutop peut booter sur le DD externe. J’ai eu des soucis avec un DD externe 2,5” (mais alimenté par une prise PS/2 sur un autre PC). Aucun problème avec un DD 3,5” alimenté directement au courant.

• irssi proxy
  • Le but est d’avoir un client IRC connecté en permanence sur le Linutop et de pouvoir s’y connecter depuis des clients IRC graphiques de ses autres machines. Voir une doc et ici. Bip fait aussi là même chose mais pas testé. Si vous rejoignez un nouveau canal, irssi restera connecté à celui-ci et vous les retrouverez tous à la prochaine connexion de votre client. Par contre si vous en quittez un il est nécessaire de faire un /part plutôt que fermer l’onglet. Apparemment fermer l’onglet, depuis xchat en tout cas, ne quitte pas le canal sur irssi. Autre avantage, vous pouvez configurer irssi pour qu’il vous mail un message privé si aucun client n’est connecté dessus (voir le plugin awayproxy).
• serveur MPD
  • Très pratique pour centraliser toutes ses musiques surtout si vous connectez la sortie son du Linutop sur une chaîne HiFi. De plus MPD peut gérer des playlists par utilisateur !
  • celui-ci consomme relative peu de ressources, environ 13% du CPU (450Mhz).
  • j’ai trouvé un excellent client, sonata. MPD utilise la sortie ALSA du serveur, ce qui permet en bonus de moduler la sortie son du serveur depuis sonata. Exemple lorsqu’on lance VLC sur le linutop pour regarder la TV Freebox.
  • update : J’ai oublié de préciser qu’il existe un plugin lastfm à MPD, lastfmsubmitd. Par contre il ne gère pas plusieurs comptes lastfm en fonction d’une playlist.
• TV
  • Grâce à VLC avec la Freebox TV ou si vous disposez d’un tuner TV USB. Par contre l’image ne sera pas optimale sur les chaînes qui diffusent en HD, à voir si le CPU de votre V2 améliore cela.
• bot IRC rbot
  • consomme environ 10% de la mémoire du linutop (256 Mo).
• serveur PostgreSQL
• synergy
  • Très pratique pour piloter le XFCE (à conseiller plutôt que GNOME ou KDE trop gourmands en ressources) du Linutop depuis son vrai poste de travail. Je constate par contre des latences de réponses de la souris/clavier par moment :/
• Tuxdroid
  • J’ai tenté de connecter le droid au Linutop mais le démon tuxdroid consomme beaucoup trop de ressources :/ A voir si les prochaines version n’améliorent pas cela.

Il me manque un équivalent de MPD pour centraliser des vidéos et les voir sur des postes clients. Si vous avez d’autres idées ajoutez un commentaire :)

update : il manque un client bittorrent.

beanstalkd est un serveur de file d’attente en C développé pour une application Facebook. Il existe un client Ruby mais la documentation est très succincte. Il existe bien un exemple d’usage mais ne répond pas vraiment aux questions, telles que comment obtenir un équivalent des namespaces de manière à ce que plusieurs clients puissent se connecter au serveur tout en écoutant chacun sur leur(s) file(s) et comment savoir que tel message vient de telle file. La documentation du protocole m’a permis d’y répondre.

beanstalk = Beanstalk::Pool.new(['localhost:11300'])
loop do
  job = beanstalk.reserve
  puts job.body # prints "hello" 
  job.delete
end

Le protocole de Beanstalkd parle de tube. Ces tubes correspondent à des files d’attentes. Dans cet exemple de base le client écoute par défaut sur le tube “default”. Si l’on souhaite spécifier le tube à écouter ou bien ajouter un tube il suffit de le préciser :

beanstalk.watch('montube')

Ainsi le client écoutera sur les tubes “default” et “montube”.

beanstalk.ignore('default')

Supprime l’écoute sur le tube “default”. Attention un client doit au moins écouter un tube. L’ignore doit donc être effectué après le watch.

Si l’on souhaite qu’un client puisse écouter sur plusieurs tubes, il y a de fortes chances d’avoir besoin de savoir de quel tube provient un message afin d’effectuer les bons traitements :

job.stats['tube']

Indique de quel tube provient le message reçu. Un exemple complet :

require 'rubygems'
require 'beanstalk-client'
beanstalk = Beanstalk::Pool.new(['127.0.0.1:11300'])
beanstalk.watch('foo')
beanstalk.watch('bar')
beanstalk.ignore('default')
loop do
  job = beanstalk.reserve
  job_hash = job.ybody
  case job.stats['tube']
  when "foo" 
    puts "from foo's tube : #{job_hash[:data]}" 
  when "bar" 
    puts "from bar's tube : #{job_hash[:data]}" 
  end
  job.delete 
end

Depuis un client qui souhaite empiler un message il suffit de préciser quel tube l’on vise, sinon cela sera “default” :

beanstalk.use('foo')

Exemple :

require 'rubygems'
require 'beanstalk-client'
beanstalk = Beanstalk::Pool.new(['127.0.0.1:11300'])
beanstalk.use('foo')
beanstalk.yput(:data => "good")
beanstalk.use('bar')
beanstalk.yput(:data => "bye")

Résultats :

from foo's tube : good
from bar's tube : bye

On a ainsi un usage plus intéressant que les exemples n’utilisant qu’un seul client sur un seul tube. Beanstalkd possède un grand nombre de commandes mais il est dommage qu’il ne fournisse pas pour l’instant d’option de persistance sur le disque. Pour cela sparrow peut faire l’affaire et même s’il est en Ruby, l’usage d’eventmachine peut sans doute lui faire tenir une charge raisonnable. Cependant Beanstalkd possède une communauté très active et des bibliothèques vers 4 langages (pas PHP :P mais cela ne saurait tarder).

J’ai migré ce blog vers une dedibox V2 et je note une nette amélioration en terme de réponse. La V2 propose 1Go de RAM supplémentaire mais celle-ci n’était pas mise à contribution. Je suppose donc que l’apport du Celeron joue énormément alors que le VIA C7 n’était pourtant pas en saturation. J’en conclu que la différence du cache processeur passé de 128Ko à 512ko doit entre autre jouer fortement.