Ça vient d'être annoncé (diable, j'étais même pas au courant qu'il y avait une procédure de standardisation en cours !), PDF est maintenant le standard ISO 32000.

Seule la France a voté non (j'ai toujours pas compris pourquoi). Un commentaire de Slashdot propose de renommer acrobat reader en « Freedom Bat Reader » en signe de protestation.

Je suppose qu'on peut y voir un gage de pérénité pour ce format qui avait quand même l'air totalement controlé par adobe (qui avait empêché Microsoft d'implémenter un export PDF dans Office). Est-ce que ça va changer quelque chose côté DRM et inclusion de vidéos et autres joyeusetés propriétaires et Windows-only, je suis pas certain, qui vivra verra ...

http://www.theinquirer.net/gb/inquirer/news/2007/12/05/pdf-a(...)
http://blogs.adobe.com/insidepdf/2007/12/iso_ballot_for_pdf_(...)

> Lire le journal (18 commentaires, moyenne: 2,4).

On ne présente plus git, le gestionnaire de versions écrit au départ par Linus Torvalds pour remplacer BitKeeper pour le développement du noyau Linux.

Comme l'année dernière, les développeurs lancent un sondage pour améliorer git avec le feedback des utilisateurs.

Si vous utilisez git, et si vous voulez bien consacrer quelques minutes à ce questionnaire, c'est par là que ça se passe (avant le 10 septembre):

http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3(...)

> Lire le journal (19 commentaires, moyenne: 2,4).

J'utilise depuis quelques années le gestionnaire de fenêtre ion[1]. Techniquement, j'en suis très satifsait, seulement voilà, le développeur a completement pété les plombs ces derniers temps[2]. Il change la licence, insulte les distributions qui fournissent son programme, insulte ses utilisateurs, retire l'accès à son gestionnaire de version, « pour rendre la tâche plus difficile aux forkers ». La version 3 finale devrait sortir d'ici peu, et l'auteur a annoncé qu'il comptait faire un break avec le développement après cette release.

Bref, si un fork n'apparait pas rapidement, j'ai de sérieux doutes sur la pérénité de ion. Perso, je n'ai ni le temps ni les compétences pour reprendre ce projet, et je n'ai pas l'impression qu'il y ai tellement de volontaires pour forker. Bref, le plus raisonnable pour moi serait de migrer, mais vers quoi ?

[1] http://modeemi.fi/~tuomov/ion/
[2] http://linuxfr.org/~Gniarf/24404.html

wmii

http://www.suckless.org/wiki/wmii

C'est sans doute le remplaçant le plus crédible. L'équipe de développement a l'air dynamique. L'idée fondamentale de wmii, c'est la gestion des fenêtres dynamique : quand on crée ou qu'on détruit une fenêtre, le wmii arrange les fenêtres restantes pour utiliser au mieux l'espace.

Premier problème : la robustesse. Le fichier de configuration par défaut de Debian est cassé, certains raccourcis ne marchent pas (Alt-[jkhl] pour passer d'une fenêtre à l'autre). Dans le fichier par défaut du dernier snapshot (pas le paquet Debian), c'est pire, les racourcis censés être sur Alt-quelquechose sont carrément sur quelquechose, donc je ne peux même pas tapper du texte, vu que la moitié des lettres sont mappés sur des actions du gestionnaire de fenêtre. En fait, il y a deux fichiers de configurations, wmiirc et rc.wmii, et la doc est quasi-inexistante pour savoir lequel fait quoi. Quelques dizaines de minutes plus tard, j'avais déjà un crash reproductible. Faites glisser une fenêtre vers le bord de l'écran, et boum.

Deuxième problème : c'est vraiment le fonctionnement du placement des fenêtres qui ne me plait pas. Sous ion, mon bureau est divisé en cadres, et je peux avoir plusieurs fenêtres par cadre, avec une fenêtre visible et les autres sélectionnables avec des onglets. Sous wmii, il y a une fenêtre par cadre, point. Au final, on se retrouve vite avec pleins de cadres et des petites fenêtres dedans, et moi, c'est tout l'inverse de ce que je veux : par défaut, tout en plein écran, et je splitte quand je veux.

TrsWM

http://yarick.territory.ru/trswm/

Ça ressemble beaucoup à ion, il y a l'air d'avoir de bonnes idées, mais la dernière sortie date de 2004.

larswm

http://www.lab1702.net/fnurt/larswm/

L'idée de base, c'est d'avoir en général une fenêtre qui occupe une grande partie de l'écran, et les autres petites, alignées automatiquement sur le côté. Même problème que wmii pour moi, ça n'est pas assez orienté vers le plein écran.

StumpWM

http://www.nongnu.org/stumpwm/

Plus ou moins une réécriture de ratpoison, en common-lisp. Ça m'a l'air pas mal, mais la doc est quasi-inexistante, il n'y a même pas de binaire « larswm », juste un README qui explique comment lancer larswm depuis une session common-lisp interactive. Bref, ça a l'air d'un truc intéressant pour quelqu'un qui veut mettre les mains dans le camboui, mais pour l'instant, je n'ai pas eu le courrage d'aller plus loin.


Bref, pour l'instant, je n'ai pas vraiment trouvé mon bonheur, mais la tâche n'est pas facile : évaluer plusieurs window-managers, dont chacun est peu intuitif, sans y passer des lustres, j'ai probablement râté beaucoup de choses.

Et vous, vous avez essayé ? Ceux qui sont sous ion, vous y restez, ou vous migrez ? Vers quoi ?

> Lire le journal (33 commentaires, moyenne: 2,4).

Ça faisait un moment que Mozilla cherchait à remplacer l'antique CVS. À ma connaissance, ça commence là, avec des ambitions modestes :

http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozi(...)
We don't need "the best" or the "newest", but we do need better merging, branching, and renaming support.

Mais la liste des besoins s'est allongée au fur et à mesure des discussions :

http://wiki.mozilla.org/Version_Control_System_Requirements

Visiblement, l'avantage a vite tourné aux systèmes décentralisés (branches privées, commit et autres opérations hors-ligne, ...). Exit Subversion, donc.

Un autre critère discriminant : un bon support pour Windows. Bah oui, les logiciels Mozilla sont libres, mais la majorité de ses utilisateurs (je ne sais pas pour les développeurs) sont sous Windows. Le portage de Git n'est visiblement pas encore au point (mais il progresse...), ni celui de monotone.

Là, il ne restait plus que Bazaar et Mercurial en finale. Et là, malgré les efforts de l'équipe de Bazaar au niveau performances (depuis la version 0.9, les performances sont la priorité du développement de Bazaar, avec des gains d'un facteur deux au moins sur pas mal d'opérations), Mercurial sort grand vainqueur.

http://weblogs.mozillazine.org/preed/2007/04/version_control(...)

Plus généralement, en ce moment, il y a une grande diversité dans le monde des gestionnaires de version décentralisés, et ça évolue à toute allure. GNU Arch qui avait ouvert la voie est quasi-mort. Darcs, qui a apporté pleins d'idées nouvelles à la fois sur la théorie et sur l'interface utilisateur n'a pas (encore ?) réussi à atteindre des performances acceptables sur un très gros projet. J'avais pas mal misé sur Bazaar, mais les problèmes de performances n'ont pas l'air de se résoudre aussi bien que prévu, et la pérénnité me parait bien incertaine.

J'ai l'impression que Git et Mercurial sont les deux qui s'en sortent le mieux au moins sur des gros projets : Git satisfait la communauté des développeurs Linux pour laquelle il a été créé, et a convaincu par exemple X.org. Mercurial a OpenSolaris et maintenant Mozilla.

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

Flemme de faire un article plus complet, mais [1]:


L'ODF Alliance compte cette semaine un nouveau membre de poids, à savoir le moteur Google. [...] Fondée en mars 2006, l’Alliance regroupe près de 240 partenaires avec déjà IBM, Sun Microsystems, Corel, Red Hat, Novell, Opera.

Après le traitement de texte [2] et le tableur en ligne [3] de Google, c'est plutôt une bonne nouvelle !

[1] http://www.pcinpact.com/actu/news/30059-Google-rejoint-lOpen(...)
[2] http://actu.abondance.com/2006-11/google-writely.php
[3] https://www.google.com/accounts/ServiceLogin?service=wise&am(...)

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

131 millions de visiteurs en un mois pour l'encyclopédie libre, qui devient le 7ème site le plus visité de la planète (devant apple, lycos, adobe, ...) !

C'est en tout cas ce que nous dit comscore :

http://www.pcinpact.com/actu/news/28559-694-millions-dintern(...)

Impressionnant, non ? (bon, je ne m'attarderai pas sur la première place du classement ;-).

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

Je viens de tomber sur une petite pétition contre la vente liée de logiciels avec le matériel, adressée au gouvernement :

http://www.petitiononline.com/rcktciel/petition.html

Une p'tit signature serait la bienvenue :-) !

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

Ce journal est un coup de gueule, mais je vais commencer par rappeler les épisodes précédents.

En gros, Canonical a complètement abandonné la version 1 de Bazaar malgré des promesses de maintenances, plus de six mois avant de sortir la version 2.

Il y a quelques temps, Canonical a décidé d'investir dans la gestion de versions décentralisée. À l'époque, en libre, il n'y avait grosso-modo que GNU Arch, donc ils ont travaillé dessus pour l'améliorer. Le mainteneur de l'époque ayant rejeté la quasi-totalité des patchs, ça a fini en fork, plus que légitime, ce qui a donné Bazaar.

De mon côté, je développais l'interface à GNU Arch et Bazaar pour Emacs (Xtla), et je suis finalement devenu contributeur de Bazaar. J'ai passé un certain temps sur la version 1.4, puis sur la version 1.5. Disons, entre quelques dizaines d'heures et une centaine d'heures. En fait, je suis à peu de chose près le seul contributeur de la version 1.5. Du côté de Xtla, j'ai également beaucoup travaillé sur le support de cette 1.5 et des améliorations qu'elle apportait.

En Août, Canonical annonce une décision qui avait en fait été prise en Juillet [1]:
En gros, la version 2 de Bazaar sera Bazaar-NG, une réécriture complète en Python. Mais bien sûr, Canonical n'abandonne pas Bazaar 1.x pour autant :

Canonical will continue to support Bazaar during the Bazaar-NG development process. Future releases of Bazaar after 1.5 will contain fixes (such as security) but generally will not contain improvements. Bazaar 1 will have one or two more releases sponsored by Canonical.

Jusque fin janvier dernier, la page d'accueil du wiki de Bazaar [2] disait toujours que la version 1.5 était prévue pour mi-septembre 2005.

Me basant sur cette roadmap, je passe encore un peu de temps à préparer la release. Je me prépare à faire une release de Xtla simultanée avec celle de Bazaar.

Sauf que la fameuse 1.5 n'est jamais sortie ...

Je m'était permis une relance un mois après la date prévue [3], à laquelle on m'avait répondu grosso-modo « là, on est occupés, mais on s'en occupe bientôt ». Il y avait aussi le prétexte que Bazaar 1.5 changeait le format d'archive. Euh, c'est moi qui l'ai écrit le code, je m'en serait rendu compte si j'avais touché au format d'archive, non ?

Fin janvier. Silence radio. Je me permet une nouvelle relance [4]. Là, deux employés Canonical me répondent, l'un « C'est trop tard, maintenant, tout le monde à migré vers Bazaar-NG », et l'autre « c'est trop tôt, la release n'est pas prête ». Mais bien sûr, on s'en occupe dès que possible.

On est fin février, et c'est toujours le silence radio. Enfin, ils m'ont quand même envoyé un bouc émissaire qui m'a dit qu'il comprenait ma frustration et la partageait, qu'il faisait tout son possible, tout ça, que tout le monde ne parlait que de ça dans Canonical, mais que si il insistait plus, il risquait de perdre son boulot (vous avez lu, « au bonheur des ogres » ?).

Robert Collins est le mainteneur officiel de Bazaar 1.x, il est payé par Canonical, il n'a pas touché à Bazaar 1.x depuis Août dernier, par contre, c'est l'un des contributeurs les plus actifs de Bazaar-NG. Et quand je lui fais remarquer que Bazaar 1 n'est plus maintenu, la réponse est que si, Bazaar 1.x est maintenu, puisqu'ils bossent sur Bazaar 2 !

Pour l'instant, le but semble d'être d'effacer toute trace de Bazaar 1.x et de mon boulot. Merci de ta contribution, mais là, on l'a juste foutue à la poubelle. Désolé pour la promesse. Visiblement, chez eux, les promesses, c'est comme en politique, ça n'engage que ceux qui y croient.

[1] http://permalink.gmane.org/gmane.comp.version-control.bazaar(...)
[2] http://bazaar-vcs.org/FrontPage?action=recall&rev=24
[3] https://lists.ubuntu.com/archives/bazaar/2005-October/000145(...)
[4] https://lists.ubuntu.com/archives/bazaar/2006-January/000210(...)

(le journal est déjà long, mais j'aurais aussi pu vous parler de comment ils m'ont roulé dans la farine pour la 1.4.3 ;-) )

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

Quelques chiffres (qui datent un peu) à comparer à ceux de Xiti :

http://www.estat.com/parution/parution_pano.html

Mai 2005 :
Firefox : 8,3% (alors que Xiti affirmait qu'il passait les 10% fin janvier 2005)
Remarquez le « AOL » juste derrière firefox avec 5% !

Linux : 0,7%
Mac : 2,9%

Conclusion : on n'est pas si loin des chiffres de Xiti, mais visiblement, Xiti est un peu optimiste pour le panda rouge.

> Lire le journal (11 commentaires, moyenne: 2,6).

Vous en avez rêvé, Apple va bientôt le faire: Limiter le matériel sur lequel un OS peut démarrer est rendu possible par une puce TPM, "Trusted Platform Module", et c'est cette technologie qui serait choisie par Apple pour empêcher le futur MacOS pour processeur Intel de booter sur un PC lambda.

C'est du moins ce qu'affirme cette news : http://news.com.com/Much+ado+over+Apple-Intel+developer+box/2100-10(...)

On en rajoute une couche (en Français, cette fois) : http://fr.news.yahoo.com/050808/7/4j756.html(...)
« Outre le verrouillage de Mac OS, cette puce pourrait donc également servir à la gestion de droits numériques (DRM) [bla bla bla] iTunes Music Store [bla bla bla]»

La partie sur le DRM n'a pas l'air très officielle pour l'instant (noter le conditionnel), mais visiblement, on n'est pas au bout de nos (mauvaises) surprises en ce qui concerne TPM et son application aux DRM.

(oui, ce journal est un nid à trolls ...)

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

Cher journal,

Je t'écris pour te présenter mon nouveau bébé. Il s'appelle Pinapa (Pinapa Is Not a PArser - faut pas oublier les vieilles traditions d'acronymes récursifs), sa passion dans la vie, c'est de manger du SystemC [1] et de recracher une structure abstraite. Bref, c'est l'équivalent d'un front-end de compilateur pour un langage, sauf que SystemC n'est pas vraiment un langage.

Pinapa a été développé dans le cadre de ma thèse, dans un projet commun entre Verimag [2] et STMicroelectronics [3]. On avait peur qu'il s'ennuie tout seul, alors il fait maintenant partie du projet GreenSoCs [4] et il devrait avoir d'autres copains open-sources d'ici peu.

Ce qui est intéressant, pour ceux qui ne sont pas directement intéressés par un parser SystemC mais qui ont quand même eu le courage de lire jusqu'ici, c'est de voir que l'open source fait son chemin dans le monde du hardware, ou la tradition est plus au secret qu'au partage.

Pourquoi avoir décidé de rendre Pinapa open source ? En partie parce que j'aime bien le logiciel libre, mais aussi parce que Pinapa n'est pas un composant sur lequel on peut espérer faire de l'argent, par contre, on espère récupérer des contributions pour améliorer la qualité du soft pour pas trop cher.

Ah, et si je concluais en vous donnant l'URL ?

http://greensocs.sourceforge.net/pinapa/(...)

[1] : Une bibliothèque pour C++ pour faire de la modélisation hardware, plus ou moins "standard de fait" pour la modélisation de haut niveau. http://www.systemc.org(...)
[2] : Laboratoire d'informatique Grenoblois http://www-verimag.imag.fr/(...)
[3] : http://www.st.com/(...)
[4] : Projet visant a créer une infrastructure open source autour de SystemC http://www.greensocs.com/(...)

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

Ca y est, après quelques mois de développement acharné, l'interface Emacs pour tla, le client GNU Arch "canonique" arrive en phase de gel de fonctionnalité, dernière ligne droite avant la version 1.0.

GNU Arch, c'est un très bon gestionnaire de versions. On en a déjà parlé ici : http://linuxfr.org/2004/02/29/15563.html(...) , et l'URL importante, c'est http://www.gnuarch.org/(...) (enfin, au moment ou je parle, c'est tout cassé, mais le wiki http://wiki.gnuarch.org/(...) est opérationnel, lui).

On peut comparer Xtla à PCL-CVS, pour ceux qui connaissent. On peut à peu près faire toute sa gestion des versions depuis Emacs, en particulier:

* Visualisation des changement. Intégration avec diff-mode et ediff (diff graphique dans Emacs, c'est un truc formidable pour ceux qui connaissent pas !)

* Navigateur d'archives

* Un mode pour chaque fichier en relation avec Arch (.arch-inventory, fichiers de log)

* Un mode "tree-lint" pour résoudre les problèmes (ID dupliquées, fichiers sources non ajoutés, ...) en quelques touches

* Un gestionnaire de bookmark, pratique entre autres pour visualiser les patchs des contributeurs non présents dans votre archive.

Pour plus d'info, voir la page de Xtla sur le wiki http://wiki.gnuarch.org/moin.cgi/xtla(...) et la page sur gna.org : https://gna.org/projects/xtla-el/(...) . C'est là que vous trouverez le bugtracker, de quoi s'abonner à la mailing list, le manuel en ligne.

Tout ça est bien sur disponible sur mon archive :

tla register-archive http://www-verimag.imag.fr/webdav/moy/public(...)

En tarball :

http://download.gna.org/xtla-el/xtla-0.9.tar.gz(...)

Et même en package Debian, en ajoutant dans le sources.list :

deb http://download.gna.org/xtla-el/apt/(...) unstable/

N'hésitez pas à rapporter le moindre bug, ou amélioration possible, bien entendu ! (ici pour les anglophobes, sur la mailing list pour discuter avec tous les développeurs)

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

J'ai un accès webdav HTTP ou HTTPS, au choix, qui marche sur un serveur.

J'ai un tla 1.2 qui arrive a accéder à une archive via Webdav en HTTP normal.

Quand j'essaye d'accéder à la même archive en HTTPS, il me dit

webdav error: 400 Bad Request

Et en regardant dans le source et en jouant un peu du gdb, je vois qu'il a essayé d'accéder au serveur sans webdav.

Est-ce que quelqu'un a déjà réussi à faire marcher tla avec webdav sur https ?

Des idées ?

> Lire le journal (1 commentaire, moyenne: 2).

Bon, je m'y suis collé.

J'ai la solution ultime (en toute modestie ;-) de sauvegarde sur CD-R pour des particuliers. Ca crée une session qui contient des liens symboliques vers tous les fichiers qui n'ont pas changé, et les fichiers modifiés dans leur intégralité. (Ah, du coup, c'est du RockRidge, peu de chance d'en sortir quoi que ce soit sous Windows.)

Pour l'instant, c'est un script perl + gtk2 tout pourrave, mais je vais l'améliorer, promis ... Justement, pour l'améliorer, j'ai besoin de vous, alors

* Si vous êtes un programmeur perl et/ou gtk, ça serait sympa de jetter un coup d'oeil au source, me donner quelques conseils.

* Sinon, bah, téléchargez-le (c'est tout petit), essayez-le, utilisez-le, et donnez-moi un max de feedback/bug report/....

tout est là
http://www-verimag.imag.fr/~moy/ibcd(...)

Et bien sur, sous licence GPL :-)

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

Cher journal,

Je recherche une application sous Linux qui me permette de faire des sauvegardes incrémentales (ne sauver que les fichiers qui ont été ajoutés/supprimés depuis la dernière fois), en gravant une session d'un CD à chaque fois.

Je n'ai rien trouvé sous forme d'interface graphique, mais je suis sur que quelqu'un a déjà fait un script pour ça.

Toute contribution/idée bienvenue.

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