David's blog

To content | To menu | To search

Tag - ocaml

Entries feed - Comments feed

Thursday, April 1 2010

Pourquoi je quitte l'expérience démocratique

demexp On m'a récemment contacté à propos de l'expérience démocratique. J'avais déjà annoncé que je quittais le projet mais j'ai fini par élaborer une réponse plus précise. Il me semble intéressant de la rendre publique, non pas pour étaler mes états d'âmes mais comme une réflexion a posteriori sur un engagement et sur un projet de logiciel Libre qui n'a pas marché (et accessoirement pour l'« histoire » du projet ;-).

Si on retourne en 2003, je venais surtout pour l'aspect informatique du projet. Faire un logiciel de débat et de vote électronique original, c'était intéressant et très motivant. Mais après plusieurs années de développement je n'ai toujours pas un logiciel utilisable et je me suis retrouvé tout seul à le faire (ou quasiment). La lassitude a fait le reste du travail. ;-)

Par ailleurs, certains choix technologiques ont limité le développement du projet (client lourd en Gtk+, pas d'interface web), même si cela était dû à des contraintes quand j'ai commencé (Ocsigen n'existait pas à l'époque). Pour d'autres choix comme utiliser le langage OCaml, ça a très certainement limité l'arrivée de nouveaux développeurs. Mais je n'en aurais pas fait autant dans des langages plus classiques comme PHP ou Python. D'ailleurs d'autres ont proposé des morceaux de logiciel, en repartant de zéro comme Jean-Marc Fauché ou Lyu Abe. Mais ces propositions ne m'ont jamais emballé.

Plus sur le fond, je m'interroge pas mal sur le sens du projet. La démocratie ne se limite pas au vote, le débat et la formation des citoyens sont tout aussi important. Après quelques années, j'ai eu l'impression qu'on se concentrait uniquement sur l'aspect vote et pas assez sur les autres aspects. Pour le dire autrement, c'était peut-être plus important de faire un serveur de listes de diffusion, un service web pour synthétiser les débats et puis finalement voter en Condorcet avec du papier et du crayon que de faire un logiciel de vote électronique. On avait dit qu'on ferait des « soirées Condorcet » dans un bar, pour mettre en œuvre de manière concrète et ludique les idées du projet : cela ne s'est jamais fait.

Pour le logiciel, je suis parti sans réellement de spécifications, quasiment par le codage. Ce n'est pas comme ça que l'on fait un bon logiciel. ;-) Évidemment, quand on a démarré, on ne savait pas trop où on allait. Maintenant je pense que j'aurais des idées plus claires.

Informatiquement parlant, l'amplitude du projet est très vaste. Cela va des bases de données aux interfaces graphiques en passant par la cryptographie ou le réseau. C'est très stimulant sur le plan intellectuel, on apprend pleins de choses mais on n'est pas forcément bon partout.

Sur un plan plus pratique et citoyen, le vote électronique est très polémique (voir par exemple ordinateurs-de-vote.org). Je suis moi même contre les machines de votes actuelles[1] ! Il est quasiment impossible de faire un logiciel de vote aussi transparent qu'une urne en plexiglas. La recherche dans le domaine des protocoles de vote avance mais il faudra encore probablement de nombreuses années avant d'avoir quelque chose d'utilisable. Et ce sera très vraisemblablement plus compliqué qu'un bulletin dans une urne.

Sur le plan plus humain, on a démarré à quatre sur le projet, puis à trois au cœur. J'ai trouvé sur le long terme que j'étais un peu seul à faire la gestion de tâches informatiques (mise à jour du serveur, répondre sur les listes, le développement, etc.), malgré le soutien de mes deux compères. Ils ont beau être les pères de l'idée, j'ai trouvé que leur implication n'y était plus.

Enfin et surtout, après plusieurs années, j'ai envie de m'attaquer à d'autres défis, dans des domaines totalement différent et cela ne se fera pas sans dégager du temps libre. J'ai donc arrếté mon implication dans des projets non « productifs ».

Voilà, c'est probablement trop long et un peu confus, mais c'est dur de résumer plusieurs années de projet en quelques mots.

Je considère toujours que la thématique du projet, la réflexion sur la démocratie et le rôle du politique, est cruciale. Peut-être juste que l'angle n'était pas le bon, je ne sais pas. Apparemment, d'autres on des idées similaires et très intéressantes.

Et l'expérience a été pour moi enrichissante. Je ne regrette rien ! :-)

Notes

[1] Vous avez dit schizophrène ? ;-)

Monday, March 29 2010

Status of OCaml packages on Ubuntu Lucid Lynx (10.04 LTS): transition to OCaml 3.11.2 finished

I don't know who are responsible for this but the OCaml packages of Ubuntu Lucid Lynx 10.04 LTS have all transitioned to OCaml 3.11.2 on main architectures (amd64 and i386). A big thank to the mysterious developer(s)! Even for secondary architectures, all packages have transitioned to 3.11.2 except 3 packages on armel: coq, ssreflect and why.

Of course, having a source OCaml package compiled with the correct version of the OCaml compiler does not make it automatically working so I encourage you to test your preferred Ubuntu OCaml packages in Lucid.

If we now compare the set of source packages available respectively on Debian Unstable and Ubuntu Lucid, the situation is not so perfect. On the 145 OCaml packages available in Unstable, 21 are not at the same stage in Lucid.

There are 5 packages simply not available in Ubuntu:

  • clang 2.6-3
  • llvm 2.6-8
  • llvm-snapshot 20100312-1
  • obrowser 1.1+dfsg-4
  • unison2.27.57 2.27.57-2

There are 11 packages that have been updated in Unstable but not upgraded in Lucid:

  • Package Unstable-version Lucid-Version
  • approx 4.2-1 4.1-1
  • camlpdf 0.5-1 0.4-4
  • coccinelle 0.2.2.deb-1 0.2.0.deb-1ubuntu2
  • graphviz 2.26.3-3 2.20.2-8ubuntu3
  • ocaml-csv 1.2.0-1 1.1.7-2
  • ocaml-ssl 0.4.4-1 0.4.3-3
  • ocaml-text 0.3-1 0.2-3
  • ocsigen 1.3.0-4 1.2.2-1
  • pgocaml 1.4-1 1.3-3
  • postgresql-ocaml 1.12.4-1 1.12.1-2
  • unison 2.32.52-1 2.27.57-2ubuntu2

And lastly there are 5 packages that had minor updates or packaging bug fix in Unstable but not in Lucid:

  • Package Unstable-version Lucid-Version
  • nurpawiki 1.2.3-4 1.2.3-3
  • frama-c 20090902+beryllium+dfsg-5 20090902+beryllium+dfsg-4
  • ocamlgraph 1.3+debian-2 1.3+debian-1
  • sks 1.1.1-2 1.1.1-1ubuntu2
  • ssreflect 1.2+dfsg-4 1.2+dfsg-3

I don't know what to do about those packages or if I can even do anything. According to Ubuntu Lucid release schedule, we are reaching Beta 2 Freeze (on April the 1st) where uploads for packages in main and restricted are held in the queue and are subject to manual approval of the release team.

Do you have any advice?

Beside that, we still have 124 OCaml source packages in good shape in Lucid!

Thursday, March 18 2010

Looking for a C software for Formal Verification

As you probably know, I'm a huge fan of Formal Methods: use appropriate Mathematics and tools to ensure a program is correct in all possible situations. In other words, bug free software... well, sort of. :-)

The interesting side of this is that tools to apply Formal Methods have improved a lot and most of them are now Free Software. I'm maintaining a list of Free Software tools for Formal Methods (it is a wiki, you can update it!).

I would like to make an experiment with Frama-C and its plugins, especially Jessie. Frama-C is a framework for static analysis of C programs developed at CEA. Combined with the Why and Alt-Ergo tools, you can prove some properties on real C code (absence of integer underflow or overflow, absence of out-of-bound accesses, absence of NULL pointer de-referencing, program's specific properties, etc.). All those tools are Free Software and are developed in OCaml. And they now are available in Debian and Ubuntu!

I made a simple experiment last year but I would like to make a more elaborated one.

Therefore, I'm looking for a piece of C code with following criteria:

  • Free Software: I'm interested in improving software for the whole humankind; ;-)
  • Pure C code, no C++. If there is some assembly, I could work around for example by re-writting corresponding C function;
  • Code of moderate size, a few thousands line at most. It could be a sub-module or subset of a bigger code;
  • Code using mostly integers and pointers, few strings (aka char *)[1];
  • Verifying some properties on this code would be "interesting". Several possible reasons: for security or safety reasons, because the code is used in an embedded platform on which modifications are difficult once in production or simply because this code is used a lot.

If you know some software that fills those criteria, let me know through a comment or at dmentre@linux-france.org!

Notes

[1] Frama-C is a bit slow to handle strings and it can become cumbersome.

Thursday, January 14 2010

Quick news: OCaml on Ubuntu Lucid and MapOSMatic

OCaml on Ubuntu Lucid

I have updated my scripts to compare Ubuntu OCaml packages to Debian ones. This time, I'm comparing Ubuntu Lucid against Debian testing, as for Lucid packages are imported from Debian testing (because Lucid is a Long Term Support release).

You'll find all the generated files here: http://bentobako.org/ubuntu-ocaml-status/raw/

MapOSMatic

As you have probably seen, we have done major improvements to MapOSMatic during Christmas, at both the web site level and the rendering level. I won't go into details, just read our initial announcement. Since then, we are continuing our improvements on maposmatic web front-end and ocitysmap back-end, with a new web site layout, translation of web site and maps in many languages (Arabic, Brazilian Portuguese, Catalan, Dutch, French, German, Italian and Russian). Many thanks to the numerous contributors!

We still have a lot of things to do or bugs to fix but the feedback is very positive and rewarding! Many thanks!

Thursday, November 19 2009

OCaml on Ubuntu: looking for a new maintainer

HELP At some point I helped keeping the OCaml packages on Ubuntu in good shape, especially for the Karmic 9.10 release.

Unfortunately, I have much less free time those days and can no longer monitor OCaml packages on Ubuntu. Is anybody willing to work on this?

The main job is to look at the Debian packages and check if they are currently available in Ubuntu, and rebuild them if necessary. When the OCaml compiler changes (fortunately not so often), one needs to trigger a rebuild of all packages and that can be a bit difficult, mainly because LaunchPad does not provide an interface to rebuild several packages, taking into account their dependencies.

Of course, I would help anybody willing to do that job (explain the needed scripts, issues I had, etc.).

Thursday, July 23 2009

Transition to OCaml 3.11.1 has started in Karmic

OCaml I previously mentioned that Ubuntu Karmic currently ships with OCaml 3.11.0 and all associated libraries and programs. While it is nice to have a coherent set of OCaml packages, it would be much better to the latest coherent set of OCaml packages in Karmic! :-) Debian initiated its own transition to 3.11.1 about 4 weeks ago and this transition is nearly finished (and took in fact only 3 weeks).

I therefore raised the issue of such a transition for Karmic. After a few questions, it has been agreed upon to start a similar transition in Karmic. Moreover Andrea Gasparini, an Ubuntu's Master Of The Universe (aka MOTU), volunteered to help me. Se we opened the first bug initiating the transition. Overall, there are 124 source packages to synchronize or recompile in 6 successive rounds.

One can monitor the status of the transition of the Ubuntu OCaml transition monitor. A comparative list of source package versions between Debian unstable and Ubuntu karmic is also available.

Thursday, June 25 2009

Transition to OCaml 3.11.1 has started in Debian

Debian The 24th of June, the Debian package for new upstream OCaml 3.11.1 has been uploaded. Thus upload marks the start of the transition to OCaml 3.11.1 in Debian Sid (aka unstable). Right now, the new package has been successfully built on most of Debian supported architectures.

Following this first round, other packages are being uploaded in successive rounds. You can follow this transition on Stéphane Glondu's dedicated OCaml transition monitor.[1]

The count-down has started. We will see how much time it will take to do this transition for the 138 source packages.

Thursday, June 18 2009

Ubuntu 9.10 will ship with OCaml 3.11.0... for now

As I recently announced on caml-list@, all OCaml packages coming from Debian were correctly compiled against OCaml 3.11.0 in Ubuntu Karmic Koala 9.10 to be released in next October. That means that current Karmic has a coherent set of OCaml packages, which I consider a worthwhile property.

Unfortunately, OCaml 3.11.1 has just been released and Debian developers are starting a transition to OCaml 3.11.1 in Debian unstable. As until the 25th of June all packages are directly imported from Debian unstable to Ubuntu Karmic, that would break various OCaml packages in Karmic, certain packages being compiled with 3.11.0 while others with 3.11.1.

Consequently, after discussion with Debian and Ubuntu developers[1], I have decided:

  1. To block the automatic import of OCaml packages from Debian to Ubuntu[2]. This blocking is currently effective. So, from now, Karmic will ship with OCaml 3.11.0 and the current package versions;
  2. To monitor transition from 3.11.0 to 3.11.1 in Debian and, if done quickly enough, to trigger a similar transition in Karmic. The Feature Freeze is set to the 27th of August so this is the absolute limit date for such a transition to end.

I am also considering providing 3.11.1 packages through Ubuntu PPA (Personal Package Archive) system. But I first need to learn how to use it. :-) But even if Karmic does not ship with 3.11.1, Karmic+1 which is LTS (Long Term Support) will have it.

If you read this blog entry and have an issue with this decision, let me know either through the comments or by sending an email at: dmentre AT linux-france.org.

Notes

[1] Several Ubuntu people were in favor of also doing such a transition in Karmic, but I cannot commit to monitor and handle it during that time period.

[2] I have been pretty conservative and blocked all OCaml based packages (because an updated package might need in up-to-date version of OCaml). We might lift this constraint a bit and allows synchronization of certain packages. Right now, I have not seen any such need. You can monitor the status of out-of-sync package in Karmic on this page.

Thursday, June 11 2009

OCaml 3.11.0 on Ubuntu Karmic Koala nearly complete

OCaml As I have previously stated, there is no OCaml developers on Ubuntu and all OCaml packages in Ubuntu are coming from Debian. So there is apparently no much work to do in order to have a large set of OCaml packages on Ubuntu. Except that there are synchronisation issues. :-)

Debian's OCaml packages are imported automatically from unstable repository a the beginning of each new development cycle of Ubuntu[1] until a Debian Import Freeze takes effect (the 25th of June according to Karmic release schedule). Once imported, packages are automatically build. But OCaml packages have a stringent need to be compiled in the right order and against the correct version of the OCaml tool chain. In case of change (e.g. going from 3.10.2 to 3.11.0) all packages should be recompiled.

Therefore, I have adapted original Debian's monitoring scripts to Ubuntu:

Ocaml transition monitor for Ubuntu

On the 124 of such OCaml packages in Ubuntu, only 3 have remaining issues:

Once done, all OCaml packages should be correctly rebuild for OCaml 3.11.0. \o/

Of course, OCaml 3.11.1 should be released Really Soon Now™ and all that work should be redone once again. "There is no such thing as a simple job".[2] ;-)

Notes

[1] One can monitor the import of new packages on page http://packages.ubuntu.com/karmic/n....

[2] Tim Daily, of Axiom's fame.

Thursday, May 28 2009

Une nouvelle application demexp en web avec web2py

Le projet d'expérience démocratique est un projet de démocratie directe à grande échelle. Il a démarré il y a quelques années déjà mais il a du mal à décoller, en particulier par manque d'un logiciel adapté. En effet le projet nécessite un logiciel de vote électronique en ligne ayant des caractéristiques bien particulière comme le vote Condorcet, une délégation possible du vote, à tout moment possibilité de changer un vote, etc. J'avais écris un serveur et un client lourd (en OCaml) pour remplir ce rôle mais les développements ont stagné pour diverses raisons : manque de motivation de ma part, trop de choses encore à faire, client lourd trop compliqué à déployer et à maintenir, langage OCaml peu connu donc je suis le seul développeur sur le projet, etc.

Hors, très récemment, une nouvelle application est apparue, programmé par Jean-Marc Fauché : une implémentation des idées de demexp en technologie web. Plutôt que de partir de mon code, Jean-Marc redémarre de zéro en langage Python, en utilisant le framework web2py.

Les caractéristiques de web2py sont intéressantes :

  • un déploiement aisé des applications : on peut télécharger une application dans un serveur existant ou récupérer une application existante à partir d'un serveur ;
  • on peut développer l'application en ligne : base de données, modèles et vues (même si à mon avis ce n'est pas forcément très utile pour de grosses applications) ;
  • les rapports d'erreurs (exceptions) sont accessibles en ligne, par l'interface d'administration ;
  • le déploiement est hyper-simple : unzip web2py_src.zip && python web2py/web2py.py ;
  • web2py est organisé autour de l'architecture modèle-vue-contrôleur et incite à utiliser ce modèle ;
  • le système de template utilise le langage Python plutôt qu'un autre langage ad hoc ;
  • un système de traductions en ligne, là aussi par l'interface d'administration ;
  • la base de donnée est vue au travers d'objets Python et toute modification des descriptions de la base est répercuté sous forme de commandes SQL de mise à jour de la base ;
  • et bien sûr un soin tout particulier apporté au framework pour faire des applications web sûres par défaut.

En bref, web2py semble la plate-forme idéale de prototypage rapide d'applications web, améliorant les idées trouvées dans d'autres frameworks comme Django ou Ruby on Rail. Pour des développements longs et importants, je ne suis pas sûr qu'il soit totalement satisfaisant, les aspects dynamiques de Python ont leurs limites (qui ne connait pas le typage fort d'OCaml ne peut pas comprendre le sens de la vie ;-). Mais il faut reconnaître a développé en quelques semaines une application qu'on peut tester et facilement déployer.

J'ai installé un dépôt Mercurial pour consulter le code de Jean-Marc. Si vous voulez tester son code, sa dernière version publiée est utilisable sur ce site temporaire : http://bentobako.org:8000/Demexp/.

En guise de conclusion, l'expérience démocratique semble redémarrer et on ne peut que s'en réjouir.

- page 1 of 2