Comme certains de mes lecteurs le savent peut-être, je suis co-administrateur du serveur de courier des anciens élèves de l'École Polytechnique. Notre serveur principal pèse (par an) de l'ordre de 4 millions de mails acceptés, et un peu plus du double en sortie. Sans prétendre être des acteurs majeurs du courier électronique, nous représentons donc un volume tout à fait raisonnable.

Je vous livre dans ce billet, un bilan assez noir de la lutte contre le spam…

Read next

Here is how I have a (mostly^[1]) working flash in a 64bit browser:

1. take the rpm's (both) from ndpluginwrapper home page
2. alien -d them
3. dpkg -i nspluginwrapper*.deb
4. apt-get install linux32 ia32-libs-gtk gsfonts-x11
5. get flashplugin-nonfree_9.0.21.78.3_i386.deb from an i386 mirror
6. dpkg -i --force-architecture flashplugin-nonfree_9.0.21.78.3_i386.deb
7. dpkg -L flashplugin-nonfree|grep so | xargs rm -f
   yes it caused me some problems, so I'm not sure it's needed but it won't hurt

and then as a user (system-wide installation of the flash plugin does not work for me at all but quite well as a user) :

1. mkdir -p ~/.mozilla/plugins
2. nspluginwrapper -i /usr/lib/flashplugin-nonfree/libflashplayer.so
3. and then go to about:plugins, you should see flash appear here.

It works for many flashes here, except, as said, for the parts that link to an external content.

I've read in many places that the flashplayer 7.0 works better than the 9 one, but the method should globally not vary a lot.

Note: to make it work for konqueror I had to restrict the places where it looks for plugins to /usr/lib/firefox/plugins + /my/home/.mozilla/plugins, and as said, it crashes quite often and randomly.

Je conseille à tous de lire ces commentaires d'un mozillien, qui lui au moins était aux JDLL et sait de quoi il parle.

Il y a vraiment des gens qui prennent vite la mouche, et au vu de leur propension facile à la critique en règle générale, me donnent envie d'associer hôpital et charité dans la même phrase.

Je me doutais un peu que c'était ce qui s'était passé, ça me fait plaisir de le voir confirmé par quelqu'un:

1. de “l'autre” bord ;
2. de présent.

À propos de cet article ce torchon:

Debian se prépare à rémunérer ses développeurs clés afin de s'assurer du respect de la date de lancement de la version 4.0 de sa distribution Linux, fixée au 4 décembre prochain. Une démarche originale pour un projet de développement communautaire.

Faux, dunk tank est un projet crée dans le dos du projet, certes par des gens qui n'ont cesse de clamer leur renommée, mais ce projet n'est pas supporté par la communauté. Le DPL est en ce moment même en train de subir une motion de censure à cause de ça.

Je refuse d'ailleurs d'être associé à une telle intitiative, tant sur le fond que sur la forme.

Ce qui est présenté comme une « expérimentation » s'inscrit dans une démarche de rupture avec les habitudes de retard du groupe de développement : la seule date de sortie jamais respectée fut celle de Debian 1.3, en juin 1997.

Encore une fois, intox. Debian n'a jamais donné de dates pour sa release, cette information est montée de toute pièces. Que les cycles soient long, ça n'est pas à prouver, mais le critère de release de Debian est “when it's ready”.

Baptisé Dunc-Tank, ce projet expérimental va devoir faire ses preuves en assurant la rémunération à temps plein des développeurs Steve Langasek et Andi Barth en octobre et novembre, respectivement.

sans doute la seule information correcte.

Imaginé par le chef de projet Anthony Towns, Dunc-Tank a fait l'objet d'âpres discussions pendant près d'un mois : « ce fut assez polémique, avec à la fois des soutiens et des objections très forts », explique Anthony Towns. Néanmoins, le projet aurait déjà reçu de nombreuses promesses de dons.

en fait il s'agit de soutiens relatifs et d'objections très fortes. Mais sachant que tout ceci se passait sur debian-private@ , bien sur, pour une fois ça n'est pas de la faute du journaliste s'il est mal informé.

Reste à savoir de combien le projet Dunc-Tank a besoin pour aboutir. Optimiste, Anthony Towns estime que « l'argent pourrait même ne pas être nécessaire. Nous sommes déjà bien placé pour respecter la date de lancement. ». Réponse dans quelques mois.

Que veut dire aboutir ? Et non nous ne sommes pas bien placés du tout. Par rapport au planning le plus récent nous avons 1 mois de retard, rien que sur les bugs RC. Et je ne parle pas du débat sur les firmwares non-libres qui selon l'issue pourrait aboutir à presque 6 mois de retard.

Merci messieurs les journalistes !

Pour reprendre /.:

"Larry Sanger, first editor-in-chief of Wikipedia, plans to fork the project. In Berlin he announced the start of Citizendium — the citizen's compendium. Main differences: no anonymous editing, and experts will rule the project. Members of Wikipedia were not amused."

Wikipedia forke, et au risque d'en choquer certains, c'est une BONNE CHOSE.

Wikipedia est un projet fantastique, qui a prouvé que la création d'une encyclopédie libre est possible. C'est bien, et c'est une chose qu'il fallait réussir à faire. Mais Wikipedia c'est aussi l'encyclopédie où la plupart des articles font moins de 10 phrases, et où l'homogénéité des articles même au sein d'un même portail se fait sentir.

Les wikipedistes sont agacés ? eh bien, c'est le prix de faire du libre les amis, on peut voir le projet forker lorsque un nombre suffisamment important de gens considère que le projet va droit dans le mur. Or si le but est de concurrencer les encyclopédies payantes sur leur terrain, il va falloir passer à autre chose. Combien de fois suis-je tombé sur un article d'une qualité repoussante sur wikipedia ? Bien sur il y en a d'excellents, et c'est sans doute depuis une base de ceux-ci que le projet Citizendium^[1] va démarrer.

Mais Citizendium a la bonne méthode: les articles publiés ne doivent pas l'être automatiquement, mais à la place être relus, homogénéisés, et surtout critiqués, et non publiés tant que la matière n'est pas satisfaisante. Wikipedia est la course à la quantité (on fête le nombre d'articles régulièrement), place à la qualité.

Merci à l'équipe pour ce beau résumé:

90+3   Pénalty! Penalty pour l'Italie après un raid de Grosso côté droit ! Le problème, c'est que le défenseur de Palerme n'a pas été touché...
90+5   BUT Totti transforme en force ce pénalty imaginaire et envoie les siens en quarts de finale.
90+5   L'arbitre siffle la fin du match et l'Italie réalise un incroyable hold-up en s'imposant grâce à un pénalty imaginaire. La Squadra Azzurra est en quarts de finale, l'Australie pourra avoir des regrets.

Ça y est, madism.org est hébergé sur une dédibox, avec ma freebox pour faire backup DNS et MX secondaire.

Je vais enfin pouvoir réaliser plusieurs projets que j'avais:

• une galerie de photos online,
• gérer les emails de ma famille (c'est trop dur de me souvenir de leurs adresses à tous…) sur habouzit.net,
• avoir enfin une svn, un darcs et autres systèmes de versionnements sur une machine avec de la connectivité,
• …

Ça fait du bien \o/

Dans la série des articles sur la vie du Geek, voici ma vision des langages de programmation…

qualités du programmeur

Je vois souvent des gens (pas plus tard qu'hier, sur ce même blog) dire : si tu utilises le langage foo c'est pas surprenant que tu fasses des trucs qui plantent, utilise plutôt bar. Ce genre d'affirmation est souvent fausse. Pour faire un bon programme, il faut avant tout un bon … programmeur. Le langage n'est que l'outil que le programmeur choisira pour implémenter tel ou tel programme.

Et un bon programmeur a entre autres ces qualités :

• en toute chose de la méthode et beaucoup de rigueur ;
• de la persévérance ;
• de l'humilité ;
• de la mémoire ;
• de bons outils.

Un bon programmeur sait écrire un programme C sans memory leak, parce qu'il a appliqué rigoureusement des règles de programmation qu'il s'est crée au fil de son expérience. Un participant régulier de fr.comp.lang.c a en signature :

C is a sharp tool.

Avec C, il est facile de se tirer dans le pied. Et justement, un bon programmeur sait se servir de C, connaît ses pièges et ses forces, et ne se prend pas les pieds dans ses travers. En ce sens, je rejoins beaucoup l'esprit de ce billet de Joel Spolsky.

qualités du code

le langage

Après, bien sur, chaque programmeur a son langage de préférence, que ça soit C++, caml, C, python. Mais ces langages ne font pas le programmeur (même pas ocaml). Même si le mauvais programmeur a bien plus de chances de faire planter un programme qu'il écrit en C, plutôt qu'en ocaml, il n'en écrira pas moins du code incorrect. C'est juste que son code ne fera pas de buffer overflow ou autre faille exploitable en sécurité.

Il est clair que certains langages sont plus propice aux erreurs que d'autres. Perl par exemple, est le langage dont la syntaxe pousse à la faute. Java et tous ses outils auto-générateurs de code est le langage dont la philosophie et la culture veut qu'on fasse des sources avec un nombre de lignes de code et de platrée de trucs inutiles qui dépasse l'entendement. C++ a aussi ce défaut. Chaque langage a ses pièges, et dès qu'on tombe dedans, certes, on n'écrit pas forcément du code qui SEGFAULT, mais on écrit quand même de la merde.

rigueur de la présentation

Vous savez comment je sais si un programmeur est bon au premier abord ? je regarde (j'ai bien dit regarder et pas lire) du code qu'il a écrit. Et je regarde la cohérence de sa présentation. Un bon programmeur sait intuitivement que le plus important en programmation, est d'avoir une présentation cohérente et systématique. Parce que en programmation, ce qui n'est pas habituel, ce qui sort de l'ordinaire, c'est :

• soit un bug ;
• soit quelque chose auquel il faut toujours faire attention, et qui souvent mérite un commentaire.

Quelqu'un qui sait s'astreindre à respecter une indentation propre, un code en moins de 80 colonnes, trier ses fonctions pour minimiser le tas de forward en début de module, utilise des fonctions d'allocation systématiquement pour toutes ses structures (même si c'est une macro sur memset), etc … est une personne qui mettra 10 fois moins de temps à trouver ses bugs qu'un autre, et qui en plus en écrira sans doute moins. Et c'est souvent un bon programmeur. Le mauvais programmeur, c'est celui qui en me lisant, dit «à quoi bon» et hausse les épaules.

illustration

Je vais donner un exemple, pour illustrer de quelle finesse dans la systématisation de la présentation du code il faut descendre: C'est aussi celui qui écrit tantôt:

   for (i = 0; i < n; ++i) {

tantôt:

   for (i = 0; i <= n - 1; i++) {

a deux problèmes.

Le premier est qu'il ne sait pas se décider entre ++i et i++. Bien sur sémantiquement, dans le cas précédent, ils sont équivalents. Mais ça n'est pas une justification. Lorsque je lis la première version, mon réflexe de programmeur est de me demander “pourquoi ++i ?”. En effet, il se trouve que à mon avis (mais je ne serai pas aussi affirmatif que le reste du billet sur ce genre de choses) l'idiome est i++, à cause de formules idiomatiques du genre :

   while (…) {
       *p++ = *q++;
   }

D'autre part, le programmeur n'est pas d'accord avec lui même sur comment il présente ses intervalles de parcours. [0..n[ ou [0..n-1] ? Vous trouvez ça ridicule ? réfléchissez deux seconde à ce qu'est un buffer overflow, et on en reparle.

Bref, il existe deux présentations valables :

   for (i = 1; i <= n; i++) {

ou (et ce ou est exclusif) :

   for (i = 0; i < n; i++) {

Et si il faut sortir avec des conditions plus particulières, alors il faut les tester DANS le for, en faisant un break; si besoin.

Pourquoi tout ça ? parce que ça suit la règle de la moindre surprise. Plus le code est prévisible, moins il a de chances de contenir un bug. Si tous vos for sont for (i = 0; i < n; i++) {, pour valider cette ligne, il vous suffit de valider que n est la bonne borne, et ensuite vous pouvez vous concentrer sur le reste du code. Bref, il n'y a qu'une variable à vérifier sur la ligne. Pas toute la ligne.

La présentation systématique du code permet la lecture cursive, et fait que en regardant un code écrit il y a plus de 3 mois, on voit tout de suite quelles parties du code contiennent sa substance, et quelles parties sont de la glue administrative sans intérêt.

Conclusion

Pour moi, un bon programmeur c'est quelqu'un qui a lu ce billet et n'y a rien appris, et trouve ce que je dis d'une évidente banalité. Pas celui qui choisit C++, C ou quoi que ce soit d'autre.

(cliquer sur l'image)

Ce soir, ce que j'espère le plus, c'est que le premier qui se fera épingler et devra payer son amende de 150€^[1] soit un de leurs propres enfants.

Sur ce, je vais regarder l'épisode 5x14 de 24.

Je n'en peux plus des choix castrateurs des ergonomes de chez GTK. Le dialogue Open File de ce toolkit est une INFAMIE :

Le bandeau de boutons qui permet de naviguer dans le chemin du fichier est une bonne idée, ça évite de faire plusieurs fois ... Admettons.

Mais le reste, tient de la débilité profonde. Sur ce dialogue MERDIQUE il est impossible de saisir directement un chemin de fichier. Donc pas possible de faire un copier coller depuis son terminal favori, il faut reconstruire le chemin à la main.

Non content de cette bêtise, il est IMPOSSIBLE de rentrer simplement dans un "dotfile". Heureusement, chez KDE, les gens sont un peu plus astucieux :

Non seulement on peut facilement changer le chemin, mais en plus lorsqu'on le tape à la main, il permet de l'autocompléter. Seulement, pas de bol, lorsque je dois utiliser ethereal, je suis obligé d'utiliser ces menus pour attardés. Surtout qu'il est bien clair que ethereal n'est utilisé que par des débutants qui ne savent pas ce qu'est un disque dur ou un path.

MAIS MERDE QUOI !!!

Ce dialogue complètement débile est l'exemple typique de la raison pour laquelle je n'utilise pas firefox, qui a le mauvais goût d'utiliser ces dialogues pourris. (sans parler de tous les autres points d'ergonomie à chier de ce navigateur, dus en grande partie à GTK, à la non “configurabilité” de ses shortcuts, et au non fonctionnement des raccourcis habituels d'édition Unix dans les barres d'URL en particulier).

Oui je sais, je suis énervé, mais ce genre d'ergonomies immondes sont :

• de la perte de temps ;
• une source d'irritation sans fin ;
• la cause d'une insatisfaction générale quant à certains outils, qui empêchent de les considérer pour leurs qualités intrinsèques, tellement la présentation (et je ne parle pas de graphismes) laisse à désirer.

Je n'en peux plus de toutes ces conneries.

Aujourd'hui, aux alentours de 14h, ma freebox fraîchement reçue s'est synchronisée.

Grand moment de joie…

Accessoirement, j'ai la chance d'avoir une ligne qui (au vu des caractéristiques techniques) devrait être d'excellente qualité:

   NRA :             CHA92
   Longueur :        526 mètres
   Affaiblissement : 6 dB

Bref, ça y est, je suis à nouveau connecté au reste du monde le soir et le Week-End !!!