Je suis utilisateur de linux depuis plusieurs années maintenant, et depuis toujours j'ai plus ou moins bidouillé quelques sources pour les adapter à mes besoins.

Ces derniers temps, j'ai décidé d'aller plus loin, et de fournir sous forme de patch, les modifications que j'ai apporté pour 2 projets. Il s'agit de roundcubemail [1] et initng [2].

Je l'avais une fois en créant 2 plugins pour gaim, mais je m'étais un peu fait bouler lorsque j'avais traîné à modifier lesdits plugins au changement de version de gaim (qui changeait l'API des plugins à chaque numéro de version ou presque).

Outre le fait que faire une modification pour soit et la fournir sous forme de patch n'implique pas la même somme de boulot, n'avoir aucun retour positif sur sa contribution est très frustrant, et stoppe tout envie de continuer. Je crois que tout le monde ici en est conscient, c'est souvent que l'on voit des journaux sur des plaintes des développeurs du noyau (entre autres).

L'amertume étant passée, j'ai donc contribué à nouveau. Ca se passe globalement toujours de la même manière : inscription sur la ML, lecture des conduites à suivre sur le code que l'on fournit, politesse tout ça, on envoie le patch ou les sources sur la ML, et on attend.

Et cette fois-ci j'ai eu des retours ! Plutôt positif pour le 1er, plus encore pour le 2nd puisqu'il semble qu'il n'y ait plus beaucoup de contributions externes. Les devs d'initng en profitent même pour me faire un petit appel à contribution sur un autre sujet. Je dois avouer que je suis assez tenté d'y répondre favorablement.

Finalement, je regrette de ne pas avoir contribué plus tôt après la frustration rencontrée sur le projet gaim (en plus je connaissais sa réputation, m'enfin...), et je pense que je serai moins réticent maintenant sur le rejet ou l'absence de retour. De toutes façons, il y a tellement de projets libres où ils manquent des bras !

Voilà, j'espère avoir redonné un peu de courage à ceux qui ont vécu la même situation, et peut être qui sait démystifié le principe des contributions à ceux qui n'ont jamais tenté !
[1] http://www.roundcube.net
[2] http://www.initng.org/

> Lire le journal (15 commentaires, moyenne: 5,2).

Bonjour à tous,

Dans le cadre de mon projet, une problématique de contrôle de doublons, afin d'éviter
de faire plusieurs fois le travail sur un même fichier.
Ce contrôle est placé dans un composant qui doit avoir une bonne réactivité,
doit être léger et robuste ; donc avec le moins de middlewares et dépendances
externes possibles. Et s'il plante, il doit n'avoir perdu aucune info : elles doivent
donc être persistées à chaque insertion/suppression. Nous avons pensé utiliser des
bases de données embarquées.
Dans la mesure où nous utilisons Java car ce composant sera utilisé sur plusieurs
OSes différents (AIX, Linux, Windows) et que c'est plus simple que porter une base
à recompiler. Les BDs embarquées que j'ai testées sont toutes écrites en Java.
J'ai testé hsql [1], h2 [2], Derby [3],McKoi [4] et SmallSql [5].

Pour avoir des points de comparaison avec les bases que nous n'utiliserons pas à cause
de cette contrainte, j'ai aussi fait mon test avec la base de données client/serveur
utilisée sur le projet, à savoir DB2 (oui je sais çapuçaipalibre, mais çaipamoikidécide),
et une autre base embarquée écrite en C, à savoir sqlite [6]. (parce que je l'aime bien).

Le test est très simple, et n'est pas du tout complet dans le cadre d'un vrai bench.
Mais dans la mesure où je fournis le code source de ce que j'ai fait [7], vous pouvez
aisément ajouter les tests qui vont intéressent, quitte à faire un bench plus varié.
Mon but était simplement de trouver, dans notre cas précis, quelle base faisait le mieux
l'affaire. Et si j'en cause ici, c'est parce que je sais que ça peut intéresser des gens,
parce que ça cause de libre, et comme ça c'est pas perdu ! :)

Passons aux choses sérieuses.

La table possède 3 colonnes, un id entier clé primaire, un digest (sorte de signature du
fichier) en varchar(256), la date d'insertion en bigint (nombre de ms depuis 1970).
Le digest pouvait tout à fait faire l'affaire de clé primaire.
J'expliquerai plus tard pourquoi j'ai laissé un id.

Le test consiste donc à exécuter une requête de type SELECT sur cette table avec comme
critère un digest. Si aucune ligne n'est retournée, alors une nouvelle est insérée, avec
un nouvel id égal au maximum de l'id courant + 1, le digest, et la date courante en ms.
C'est tout.

Pour voir comment se comportent les bases, j'ai testé sur 1000, 10000 puis 30000 fichiers
pour avoir un panel proche de nos conditions de production.
Le test est déroulé séquentiellement sur ces fichiers.

Pour simuler une demande de travail en double, de manière aléatoire mais proche d'un
pourcentage paramétrable, un fichier est pris au hasard dans la liste, sans interférer sur
le parcours séquentiel. Ainsi, si sa demande de travail a déjà été effectuée, on est bien
dans le cas d'un doublon. Si sa demande n'a pas encore été faite, elle sera refaite par
la suite, et là on aura un doublon.

Pour le fun, j'ai aussi implémenté une pseudo BD fichier, qui est en réalité une hashmap
sérialisée à chaque insertion.

Voici mes résultats sur 1000 fichiers (ce n'est pas trié)


-------------------------------- hsql ----------------------------------
46 doublons, 1000 ajoutés, nombre de boucles :1047
temps total : 1292ms
temps moyen : 1.2340019102196753ms
-------------------------------- derby ----------------------------------
66 doublons, 1000 ajoutés, nombre de boucles :1067
temps total : 5939ms
temps moyen : 5.566073102155577ms
-------------------------------- h2 ----------------------------------
56 doublons, 1000 ajoutés, nombre de boucles :1057
temps total : 2724ms
temps moyen : 2.577105014191107ms
-------------------------------- sqlite ----------------------------------
32 doublons, 1000 ajoutés, nombre de boucles :1033
temps total : 216892ms
temps moyen : 209.96321393998065ms
-------------------------------- mckoi ----------------------------------
48 doublons, 1000 ajoutés, nombre de boucles :1049
temps total : 87115ms
temps moyen : 83.04575786463299ms
-------------------------------- db2 ----------------------------------
68 doublons, 1000 ajoutés, nombre de boucles :1069
temps total : 12558ms
temps moyen : 11.747427502338635ms
-------------------------------- smallsql ----------------------------------
64 doublons, 1000 ajoutés, nombre de boucles :1065
temps total : 14611ms
temps moyen : 13.71924882629108ms
-------------------------------- hashmap ----------------------------------
59 doublons, 1000 ajoutés, nombre de boucles :1060
temps total : 5057ms
temps moyen : 4.770754716981132ms


Toutes ces bases travaillent sur le même ensemble de fichier. Si le nombre de
boucles diffère quelque peu, c'est à cause du pourcentage variable (puisqu'utilisé
dans un calcul contenant un random).

Le temps moyen n'est pas équivalent à une opération en base, mais au temps passé
dans une boucle, donc 1 select + 1 insert (le fichier n'a pas encore été traité)
ou 1 select (le fichier a été traité). Pour les bases ne gérant pas la colonne
auto increment, il y a même dans le cas où le fichier n'a pas encore été traité
un 2e select pour déterminer la valeur de l'id.
Dans mon exemple, il y a environ 5% de doublons donc environ 5% des boucles où
on ne fait qu'1 select. (ce choix est totalement arbitraire).

J'ai été assez déçu des performances de sqlite, qui pourtant est très bon en C,
j'accuse, sans aucune preuve pourtant, son driver JDBC d'être lent. Ou plutôt
l'utilisation de code C en java avec jni ou qque chose du genre qui doit être
capable de ralentir n'importe quel code.
Et très curieusement, la map se comporte très bien ! Enfin curieusement, 1000
fichier c'est pas la mer à boire non plus.

Les autres sont assez proches, à part peut être McKoi un peu en dessous.


Voici mes résultats sur 10000 fichiers


-------------------------------- hsql ----------------------------------
492 doublons, 10000 ajoutés, nombre de boucles :10493
temps total : 5168ms
temps moyen : 0.49251882207185743ms
-------------------------------- derby ----------------------------------
534 doublons, 10000 ajoutés, nombre de boucles :10535
temps total : 59436ms
temps moyen : 5.641765543426673ms
-------------------------------- h2 ----------------------------------
541 doublons, 10000 ajoutés, nombre de boucles :10542
temps total : 8752ms
temps moyen : 0.8302029975336748ms
-------------------------------- sqlite ----------------------------------
536 doublons, 10000 ajoutés, nombre de boucles :10537
temps total : 2071959ms
temps moyen : 196.63651893328273ms
-------------------------------- mckoi ----------------------------------
491 doublons, 10000 ajoutés, nombre de boucles :10492
temps total : 741476ms
temps moyen : 70.6706061761342ms
-------------------------------- db2 ----------------------------------
532 doublons, 10000 ajoutés, nombre de boucles :10533
temps total : 96139ms
temps moyen : 9.127409095224532ms
-------------------------------- smallsql ----------------------------------
515 doublons, 10000 ajoutés, nombre de boucles :10516
temps total : 1302233ms
temps moyen : 123.83349182198555ms
-------------------------------- hashmap ----------------------------------
506 doublons, 10000 ajoutés, nombre de boucles :10507
temps total : 361610ms
temps moyen : 34.41610355001428ms


Les écarts commencent à se dessiner !
Et ceci ne concerne que les temps, je n'ai pas regardé ni la taille sur le disque, ni la place
occupée en mémoire.

Voici mes résultats sur 30000 fichiers :


-------------------------------- hsql ----------------------------------
1572 doublons, 30998 ajoutés, nombre de boucles :32571
temps total : 41200ms
temps moyen : 1.2649289245033926ms
-------------------------------- derby ----------------------------------
1653 doublons, 30998 ajoutés, nombre de boucles :32652
temps total : 262448ms
temps moyen : 8.037731226264853ms
-------------------------------- h2 ----------------------------------
1663 doublons, 30998 ajoutés, nombre de boucles :32662
temps total : 58955ms
temps moyen : 1.8050027554956831ms
-------------------------------- sqlite ----------------------------------
1643 doublons, 30998 ajoutés, nombre de boucles :32642
temps total : 5890079ms
temps moyen : 180.44479504932295ms
-------------------------------- mckoi ----------------------------------
1629 doublons, 30998 ajoutés, nombre de boucles :32628
temps total : 2286808ms
temps moyen : 70.08728699276695ms
-------------------------------- db2 ----------------------------------
1636 doublons, 30998 ajoutés, nombre de boucles :32635
temps total : 306561ms
temps moyen : 9.393626474643787ms
-------------------------------- smallsql ----------------------------------
1648 doublons, 30998 ajoutés, nombre de boucles :32647
temps total : 11981409ms
temps moyen : 366.9987747725672ms
-------------------------------- hashmap ----------------------------------
1575 doublons, 30998 ajoutés, nombre de boucles :32574
temps total : 3917683ms
temps moyen : 120.27024620863266ms


Je vous laisse apprécier les résultats.

Je tiens à préciser qu'à part l'ajout d'un index sur la colonne digest (chose que
SmallSql ne gère pas), et l'utilisation quand cela était possible d'un auto increment,
je n'ai pas du tout cherché à tuner les bases. (enfin si, McKoi un peu, mais ca n'a
rien changé).

Pour en revenir à la colonne d'auto incrémentation; elle ne concerne que les tests,
la colonne digest pouvant tout à fait faire office de clé primaire.
Dans la mesure où le composant est sensé être robuste, j'ai voulu faire des tests
sur la durée. Or je n'ai pas la possibilité de laisser l'ordinateur de test allumé
24h/24 7j/7. Donc je voulais pouvoir couper mon application et la relancer plus tard
et avoir un compteur persistant.
Pour le moment, h2 et hsql (qui sont les 2 bases que j'ai retenues), ont toutes deux
dépassées plusieurs centaines de milliers d'enregistrements, avec en moyenne 30 000
lignes en même temps. (il y a une purge régulière, conformément à nos specs).

Concernant le code source que je fournis gracieusement, mais pour la gloire qd même,
je tiens à préciser qu'il s'agit d'une version allégée de celui que j'utilise en
réalité pour mon projet. Donc le calcul de digest est devenu une fonction qui renvoie
une chaîne aléatoire, de taille fixe.
Il est possible de définir plusieurs threads qui attaquent simultanément la même base,
mais mes logs deviennent inadaptées pour calculer des temps, et par les petites expériences
que j'ai menées sur ce sujet au départ, ça n'apporte rien en terme de perf. (normal
puisqu'au final il y a bien une exécution des requêtes en série.)
Il reste sûrement qques valeurs en dur, du code en commentaire, mais bon, ca devrait
être une bonne base pour qqu'un qui souhaiterait approfondir un peu.

Dernière chose, j'ai placé le niveau d'alerte des logs à FATAL volontairement car
les temps se mesurant en ms, leur incidence est relativement importante. Essayez
par curiosité!

Donc si qqu'un à le courage ou l'envie ou les deux d'agrémenter ces tests, je serai
curieux de connaître ses résultats.

Merci de m'avoir lu !

[1] http://hsqldb.sourceforge.net/ Licence maison ? mais apparemment libre
[2] http://www.h2database.com/ Licence MPL
[3] http://incubator.apache.org/derby Licence Apache Version 2.0
[4] http://mckoi.com/database/ Licence GPL
[5] http://www.smallsql.de/ Licence LGPL
[6] http://sqlite.org Domaine public !!
[7] http://yawks.free.fr/testdb.zip
Il s'agit d'une archive d'un projet Eclipse, il doit pouvoir être importé en tant
que tel, mais je n'ai pas testé. Tous les jars nécessaires sont inclus, à l'exception
du driver jdbc de DB2 pour lequel il doit y avoir une licence proprio, donc par
précaution je ne l'ai pas inclus.

> Lire le journal (24 commentaires, moyenne: 1,6).

Bonjour cher journal,

J'étais installé depuis environ 20 ans dans un grand immeuble, quelque part près de Paris.
J'habitais un appartement d'un immeuble des années 60-70, et je n'avais eu qu'un seul prédécesseur.
Au cours de toutes ces années, j'ai eu 5 colocataires différents, j'ai subi 2 dégâts des eaux, j'ai vu la déco changer plusieurs fois...
Aujourd'hui, je dois changer de domicile. On m'a remplacé. Un modèle plus récent, plus design...
Et moi je pars à la campagne en Bourgogne, remplacer moi aussi un comparse soit plus vieux que moi, soit plus abîmé, ou même inexistant, je ne sais pas encore.

Ce que je sais c'est que j'aurai pu finir à la déchetterie de la commune, mais que grâce au réseau freecycle je vais avoir une 2nd vie au vert, je continuerai à faire couler de l'eau, on continuera à se brossera les dents, à se raser, à se percer les boutons, ..., au dessus de moi, et je ne participerai pas à cette folie consumériste de notre société actuelle.

Si freecyle est bon pour moi, freecyle est peut être bon pour vous aussi ?


http://fr.freecycle.org/

voir http://linuxfr.org/comments/749809.html#749809
(sur le journal http://linuxfr.org/~tortieh/22556.html )

> Lire le journal (14 commentaires, moyenne: 2,9).

Au mois de mai, l'Open Discussion Day [1] a convié les utilisateurs de protocoles MSN, AIM, ICQ, Yahoo! Messenger, Gadu Gadu, SKype ... à ouvrir un compte Jabber. A cette occasion, certains serveurs Jabber ont même fermé leur passerelles vers ces protocoles [2].

Depuis quelque temps, la passerelle MSN ne fonctionne plus sur le serveur jabber.fr, pour des causes matérielles. Et cela a (re)lancé la polémique sur la légitimité de celles-ci sur les serveurs francophones jabber.fr [3] et fritalk.com [4].

Les réactions sont toutefois assez étonnantes, notamment sur fritalk.com où de nombreux posteurs sont prêts à accepter la suppression de cette passerelle, même si la plupart d'entre eux affirment l'utiliser.

Cette notion de passerelle est depuis longtemps une cause de débats/troll. En effet, elles permettent de passer en douceur à Jabber, tout en pouvant continuer à discuter avec ses "anciens" contacts, le tout dans le but de les faire migrer peu à peu. Mais elles monopolisent beaucoup de ressources que ce soit en développement, maintenance, bande passante, espace disque...
Par ailleurs, à l'usage, il semblerait qu'elles soient utilisées de façon durable, voire même exlusives !

Les services de passerelles, principalement MSN, entravent le bon fonctionnement des serveurs jabber, et finalement ne servent pas à faciliter la migration.
De nombreuses idées ont été lancées sur les forums de fritalk afin d'agir face à ce problème.
Ainsi, on a vu proposer :
- la facturation de ces services
- la suppression des passerelles
- l'envoi d'un message automatique aux correspondants d'autres protocoles indiquant que l'on utilise jabber
- brider les fonctionnalités des passerelles
- ...

Même si actuellement les débats ne sont pas clos, tout cela tend à prouver que jabber devient de plus en plus indépendant, et que les passerelles ne sont définitivement pas une bonne idée pour la migration.

Et pour lancer le troll:
Il ne manque plus qu'à jabber quelques JEPs de whizz, émoticônes, vidéo ... et un client fashion les implémentant qui clignote, et le problème des passerelles sera complètement résolu ;)

[1] http://linuxfr.org/2006/05/18/20828.html
[2] http://fritalk.com/
[3] http://forum.jabberfr.org/viewforum.php?id=7
[4] http://forum.fritalk.com/read.php?2,621

> Lire le journal (47 commentaires, moyenne: 3).

En navigant un peu par hasard sur le site du LRI ( http://www.lri.fr/ ) je suis tombé sur ça :
http://liihs.irit.fr/dragice/foldndrop/

Encore une idée pour les windows manager totalement indispensable !

> Lire le journal (8 commentaires, moyenne: 4,3).

Vu sur
http://permanent.nouvelobs.com/people/20060201.OBS4626.html

où on apprend combien il est difficile d'être très trop riche.

M'enfin, il se déleste quelque peu pour les bonnes oeuvres, c'est toujours ça.

> Lire le journal (42 commentaires, moyenne: 3,4).

Bonjour,


J'ai beau faire le tour des fonctionnalités des gestionnaires de sources (SVN,CVS principalement) et des bugtrackers, jamais je n'ai vu de liaison entre les deux.

Pourtant je trouve que ca serait une fonctionnalité intéressante. Pourquoi ? Parce que je me suis rendu compte que lorsque je corrigais un bug ouvert sur le bug tracker, je mettais toujours un commentaire équivalent dans la solution avant de le fermer et dans le commentaire du "commit".

En plus ca permettrait de pouvoir retrouver la partie de code qui a été corrigée si le bug est réouvert.
Et dans ce cas on pourrait voir que :
- soit le code corrigé n'est pas bien corrigé
- soit depuis la correction, il y a eu des modifications qui ont entraîné une régression
- ...

Enfin bon, ptêt que ca soulève un tas de problématique que je vois pas, ptêt que ca existe déjà, enfin bon, c'est un peu aussi à ça que tu sers journal, à me donner ton avis éclairé, alors merci d'avance !

> Lire le journal (15 commentaires, moyenne: 2,7).

Roland Garros commence aujourd'hui, et comme chaque année depuis 20 ans, IBM en est le partenaire pour toute la gestion informatique.
Moult informations ont vu peu à peu le jour : vitesse de la balle, nombre de fautes directes, ...
Toutes ces statistiques sont stockées dans une base DB2 (IBM oblige) tournant sur un Linux ! Et le coup n'est pas isolé, Wimbledon, dont IBM est aussi le partenaire, en est déjà équipé.

Vu le nombre de statistiques par match (près de 1000) et le nombre de requêtes des visiteurs du web pendant les 2 semaines du tournoi (177 millions de pages web accédées), Linux démontre encore une fois sa stabilité et disponibilité.

La gestion d'un tel système d'information étant tellement disproportionnée dans la durée, ( pendant environ 2-3 semaines le site est très visité, le reste du temps quasiment pas), IBM a mis en oeuvre une solution technologique capable de supporter un trafic 40 fois supérieur au trafic régulier durant les pics de fréquentation ; puis de se redimensionner à l'issue du tournoi lorsqu'elle est moins sollicitée ... sans nous en dire davantage...

En attendant, les services internet offerts, sont de plus en plus complets, cette année on pourra même : suivre certains matchs avec des échanges de balles entre les joueurs point par point ainsi que leurs scores de façon simultannée. et même visionner les points de certains matchs et même changer les angles de vue.

Le déploiement nécessaire pour "seulement" 2 semaines doit être vraiment impressionnant...

> Lire le journal (6 commentaires, moyenne: 3,8).