Cher journal,

je voudrais partager avec toi cette citation :

« The main reason we can't release Flash Player as open source is because there is technology in the Player that we don't own, such as the industry standard hi-def video codec, H.264. Adobe pays for that codec so video plays reliably worldwide, across browsers and OS's. »
Source : http://blogs.adobe.com/open/2010/02/following_the_open_trail(...)

Il semblerait donc que H264 et ses brevets soient un frein majeur aux Logiciels Libres. Si Adobe ne peut libérer Flash pour cette raison, il est à craindre que l'on puisse avoir les mêmes soucis avec les lecteurs multimédias. C'est également une raison supplémentaire de soutenir Mozilla, qui refuse d'implémenter un décodeur H264 dans son navigateur maison, lui préférant Theora.

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

Cher journal,

Sylvain Durif, inventeur depuis 2004, a proposé sur ce site une dépêche sur Elvita, qui a a été refusée, à mon grand regret. Il est à la recherche de personnes pouvant l'aider pour ce grand projet qu'est Elvita.

Je vous recommande la lecture de son site http://universelvita.blogspot.com/ et voici quelques extraits qui vous donneront, je l'espère, envie de participer :

« We are divine essence. Divine power is infinite.
We will establish the universal paradise. »

« Do you know that an american nuclear submarin reach french atlantic coasts from New-York in one hour thanks to a french invention ? Useless and dangerous because it means war. »

« Our aim is to bring the power of fast-teleportation in the best future in the pocket of everybody. »

« Why taking risks driving a car and going to hell when you can fly over the world surpassing mountains and obstacles at thousands times the speed of your thought going directly to paradise ? »

« The objective of our research efforts and inventions is the absolute peace and prosperity for everybody worldwide in the real and virtual worlds. »

«a secure infrastructure deployed on each continent (at least four points - ideally 10 points) : bunkers and old castles or citadels are welcome. »

« 5- H.I.P (High Invisibility Protection) : optical invisibility concept to protect terrestrian et maritime infrastructures from attemptions of destruction. »

« 3- police should be a horse-riding or biking one only inside cities »

« Elvita allows to improve radically your real life using a new type of fast-teleportation machine in a virtual and parallel world enabling global view in transparency of your best opportunities. »

« The activity will be rentable during FY2 and will generate a ROI of 10 billions dollars in 3 years and 1250 billions in 10 years. »

« Why loosing time and money when the invention surpassing Internet 6 specifications already exists ? Our set of inventions allows you to find custom solutions in real-time and to finance them directly in a second. »

PS : avez-vous remarqué que son utilisation même de blogger est très innovante, avec une page par compte ?

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

Bearstech a annoncé lors du 26C3 la mise en ligne d'Hackables-devices. C'est un site sur les devices qui peuvent être facilement (ou pas) bidouiller.

On y trouve bien sûr des OpenMokos, des Tux Droids et des Arduinos, mais aussi d'autres appareils moins connus. Par exemple, vous pouvez voir la fiche sur la caméra Elphel (ceux qui étaient aux RMLL en 2008 en ont peut-être vu une, car elle a servie à filmer quelques conférences).

J'espère que l'on pourra rapidement voir des hacks intéressants sur la page des projets.

> Lire le journal (12 commentaires, moyenne: 1,8).

Cher journal,

on est vendredi, jour des trolls, et je souhaiterai soumettre à ton approbation une petite application web que j'ai développée.

Je voulais essayer le framework Tornado [http://www.tornadoweb.org/], et j'ai donc cherché une application web tout simple qui permettrait de découvrir Tornado et ses aspects événementiels. Mon choix s'est porté sur un trollomètre, vous savez, ce truc qui sert à mesurer l'intensité des trolls.

Le trollomètre est donc en ligne sur [http://trollometre.com/] (merci bearstech pour l'hébergement), et le code est disponible sur [http://github.com/nono/Trollometre].

Comme vous pouvez le voir, l'algorithme pour donner un score à un troll est assez simpliste, mais ça donne déjà des résultats intéressants ([http://trollometre.com/static/yahoo.png] par exemple).

Bien entendu, le trollomètre a pu profiter de la base de trolls de LinuxFr.org pour se parfaire. pour le moment, la page avec le plus gros score a obtenu 222,2. Saurez-vous trouver quelle page c'est ? Ou trouver une page avec un plus gros score ?

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

Dans mon précédent journal, j'ai clairement indiqué ma préférence sur les gestionnaires de versions distribués (comme Git), par rapport aux gestionnaires de versions centralisés (comme Subversion). Je n'avais alors pas justifié ma position, mais je souhaite maintenant le faire. C'est vrai ca, pourquoi Git* m'importe ?

Un des arguments souvent rencontrés pour justifier l'intérêt de Git est la vitesse des opérations. C'est vrai que c'est agréable de pouvoir commiter instantanément. Pourtant, je travaille régulièrement avec svn, et ce manque de rapidité n'est pas quelque chose qui me gêne beaucoup. Cet argument à lui seul ne suffit pas à justifier le passage de svn à Git.

Les gestionnaires de versions distribués permettent, par définition, de commiter depuis n'importe où (dans le train, le métro, l'avion, les toilettes, etc.). Pourtant, ce genre d'utilisations reste assez marginal, et à l'exception de quelques personnes, c'est une possibilité extrêmement peu utilisée.

On peut également reprocher certaines choses à svn (comme l'impossibilité d'annuler un commit), mais ce sont des choix de design de subversion, et un autre gestionnaire centralisé pourrait les corriger.

Pour ma part, je pense que le plus grand apport de git est son aspect distribué, ce qui permet de mettre entre toutes les mains un gestionnaire de versions avec ses avantages. Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais. De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.

Prenons un exemple (fictif) : je suis un utilisateur régulier du logiciel XYZ, j'en suis content, mais je n'arrive jamais à m'y retrouver dans l'écran des options. Je décide donc d'essayer de refaire cet écran, mais comme je passe beaucoup de temps sur la tribune, il va probablement me falloir plusieurs semaines avant de pouvoir proposer un patch à l'auteur.

Premier cas : le logiciel XYZ est versionné avec subversion. Je fais donc un checkout du trunk, et je commence à travailler dessus. Au bout de deux semaines, je commence à avoir une version intéressante de cet écran, mais entre temps, le développement a continué sur le trunk, et une nouvelle option est apparue. Je décide de faire un svn up, mais malheureusement, l'inévitable se produit : un conflit sur plusieurs fichiers. Ce n'est pas très grave, j'arrive à les corriger, et je peux me remettre au travail. J'arrive enfin à un écran des options qui me convient, et juste au moment où j'allais me décider à envoyer mon patch à l'auteur, je me dis que j'essayerais bien d'intervertir 2 options. Je fais ce dernier changement, mais pas le temps de le tester, je pars en vacances. A mon retour, je me rends compte qu'intervertir ces 2 options était une mauvaise idée. Malheureusement, comme je n'ai pas pu commité mes changements, je me retrouve à devoir me rappeler ce que j'avais fait avant de partir pour pouvoir annuler ces changements. Enfin, je peux proposer mon patch à l'auteur. Ouf.

Deuxième cas : je fais un svn export du même dépôt, puis je créé un dépôt svn local pour gérer mes avancées. Je peux tranquillement travailler sur mon écran d'options. Quand j'arrive à quelque chose de convaincant, je propose un patch à l'auteur, qui le refuse, car celui-ci ne s'applique pas sur le trunk. J'essaye alors de me synchroniser avec le dépôt officiel, mais entre les nombreux conflits et le trunk qui n'arrête pas d'évoluer, je finis par abandonner :(

Maintenant, le même scénario avec Git se serait beaucoup mieux passé. J'aurais profité de tous les avantages d'un code versionné. Par exemple, j'aurais pu commiter régulièrement mes avancées, ce qui m'aurais permis de profiter de git diff, git log, etc. Si, après récupéré les mises à jour du dépôt officiel, je me serais rendu compte que résoudre les conflits est plus compliqué que prévu, je peux retourner à la révision précédente et continuer à travailler dessus (en laissant le travail de résolution des conflits pour quand j'aurais plus de temps/volonté à y consacrer). Enfin, je n'aurais rencontré aucune difficulté à annuler un des mes changements. Bref, j'aurais pu profité des avantages d'un code versionné.

Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages (faire régulièrement des tarballs de ses avancées), mais imaginer que vous vouliez vous mettre à plusieurs pour proposer une nouvelle fonctionnalité majeure pour votre logiciel préféré. Bien entendu, vous n'avez pas accès au dépôt officiel, sinon ce serait trop simple ;)

Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel. Cette branche distante est la seule façon sereine de faire des développements expérimentaux tout en continuant à se synchroniser sur la base de code officielle. Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.

* je parle de Git, mais Mercurial ou Bazaar-NG ou un autre DSCM ferait aussi l'affaire.

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

Cher journal,

voici mes réflexions sur les DSCM (Distributed Source Code Management), enfin surtout Git et Mercurial, et tant qu'à faire, j'aimerais bien avoir ton avis sur la question.

Je vais attaquer un projet pour lequel je vais utiliser un DSCM (non, je n'ai vraiment pas envie d'utiliser Subversion), et je me suis donc penché sur le sujet. D'un point de vue technique, les 2 gagnants sont Git et Mercurial. Du moins, c'est l'impression que j'en ai, et elle est partagée avec d'autres personnes avec qui j'en ai discuté. Je ne nie pas que les autres (darcs, bazaar-ng, etc.) aient des qualités, mais ils m'intéressent moins que Git et Mercurial. Coté Mercurial, je vois comme avantage le fait que je l'ai déjà utilisé (ce qui n'est pas le cas de Git) et que son utilisation est réputée plus simple. Ca ne fait pas très lourd, surtout qu'on m'a dit que Git a fait de gros progrès sur ce point avec les dernières versions.

De l'autre coté, j'ai l'impression que Git est en train de marquer des points dans la guerre des DSCM, et de venir de plus en plus populaire. Depuis les annonces de Mozilla et OpenSolaris, je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial, alors que je vois régulièrement des dépôts Git (utilisé pour du code, mais aussi pour du packaging et de la doc). Du coté des hébergeurs, même topo : Tuxfamily a récemment annoncé le support des dépôts Git, et je connais des hébergeurs spécialisés dans Git comme GitHub, mais pour Mercurial, je ne pense pas en avoir croisé.

Dans la communauté Ruby on Rails, cela me semble encore plus frappant. La manière plus ou moins officielle de distribuer des plugins est d'offrir un accès anonyme à un dépôt svn (en lecture seule, l'accès). Mais plusieurs développeurs de plugins connus utilisent Git pour développer les plugins, et synchronisent le svn juste pour les releases. Il existe également des projets visant à utiliser les plugins quand on utilise Git (comme Giston ou Git-rails). Il me semble que capistrano possède également un module pour Git. Et pour Mercurial ? je n'ai rien vu, mais alors rien de rien.

Bref, j'ai l'impression que Git est en train d'écraser la concurrence, ce qui veut dire que le développement de Git va surement avancer plus vite que celui de Mercurial, qu'on trouvera de plus en plus d'outils pour Git, et surtout, que des potentiels contributeurs auront plus de chances de connaitre Git que Mercurial. Je pense que je vais choisir Git surtout pour ce dernier point, car j'espère attirer des contributeurs dans les prochains mois et je ne voudrais que le DSCM soit le moins possible un point de bloquage.

Et vous, chers lecteurs, vous-en pensez quoi ?

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