Free Software / Libre

Entries feed - Comments feed

Last entries

Fri 02 Dec 2011

  • David Mentré
  • 7

A draft of library to handle physical units in OCaml

When writing a computer program that interact or handle with the physical word, a common need is to manipulate physical units like meter, second or km/h. Most of the time it is up to the programmer to ensure that the physical units are correctly used, even if there are rules to check them (divide only meters by meters, ...). All physicists are routinely checking their equations with those rules. Why not programmers?

So here is a draft of OCaml library to do just that: computations on physical values while ensuring physical units rules are followed (for example, you only add meters to meters, not meters to seconds). Here are the SIunits.mli and SIunits.ml files.

The use of the library are quite simple:

  • A set of functions to create values with units from simple floats. For example meter 1.0 (or simply m 1.0) creates a value containing 1 meter;
  • A set of utility functions to handle SI prefixes like kilo, to normalize a value (i.e. to remove the scaling factor) or to print it with its units. For example, to enter a length of 160 km one would write kilo (m 160.0);
  • A set of four operators, +!, -!, *! and /! to do basic computations on those values. For example, to enter a speed of 160 km/h, one would use let speed = (kilo (m 160.0)) /! (hour 1.0). To compute the distance travelled at previous speed during 120 s, one would do let distance = (normalize_si_value speed) *! (s 120.0) and the program can print 5333.333333 .m;

Internally, I have followed the proposal of "Checking SCADE Models for Correct Usage of Physical Units" paper by using a vector of 8 units: 7 base units (following those defined in the SI system) plus one power of 10 unit for the scaling factor (to handle kilo, mega or more exotic units like hour). In fact, to be really exhaustive one would need some additional units but the current code is really a draft. Then, the rule for addition or subtraction is to check that the units are identical, while for multiplication and division the units of the two numbers are added or subtracted. See the above paper for details.

There is a lot of work to transform this draft code into a real, usable and exhaustive, library:

  • Power and root operators;
  • Comparison operators;
  • Decision operators;
  • Dimensionless units;
  • Absolute or relative values;
  • More prefixes and exotic units;
  • And of course of lot of tests for above code.

Right now, I do not intend to extend the current code but if other people are interested, I could work on it and open an OCaml Forge project. If there is a need, let me know.

And now a question for the OCaml experts: would it be possible to replace the dynamic checks currently implemented in this library by static checks using OCaml type system (for example using Phantom types)? I think this is not possible: the base units are like arrays of the same size, you need a more expressive type system to express constraints on them (like Coq's Dependent types). But I would be pleased to be shown wrong. :-)

Fri 16 Sep 2011

  • David Mentré

Utilitaires Libres utiles sous Windows

Comme moi, vous êtes peut-être contraint d'utiliser un système d'exploitation Windows propriétaire au travail. Mais ce n'est pas une raison pour ne pas utiliser des petits[1] logiciels libres qui facilitent les tâches quotidiennes.

Pour ma part j'utilise :

  • Eraser pour l'effacement sécurisé : quand on efface un fichier, son contenu est toujours présent sur le disque, seul l'entrée de ce fichier dans l'index des fichiers a été supprimé (quel que soit le système d'exploitation). Ce petit utilitaire permet de réellement effacer le contenu du fichier ;
  • 7zip pour la compression / décompression de fichiers : pour manipuler toutes les archives habituelles, ZIP, GZ, TAR, etc.
  • x2go pour l'accès X distant : pour afficher le bureau graphique d'une machine Unix à distance. Il supporte la rupture de connexion réseau, il marche bien avec une connexion réseau de mauvaise qualité, il supporte un répertoire partagé entre la machine distante et la machine locale. Le seul soucis que j'ai eu a été avec le copier / coller, mais le bug a peut-être été corrigé avec les versions récentes ;
  • SpeedCruch comme calculette : enfin une calculette qui calcule et qui n'affiche pas simplement un clavier qui ne sert à rien ! On peut désactiver le clavier, régler facilement l'affichage (par exemple en multiple de 1000) ou prendre le point comme séparateur de décimal, même en français (enfin on peut utiliser le point du clavier numérique !), elle a un historique des calculs et offre une coloration syntaxique du calcul en cours. Bref, elle est très pratique. À tel point que j'en avais déjà parlé. :-)
  • KeePass pour stocker les mots de passe : cela permet de générer facilement des mots de passe aléatoires et de les stocker dans un fichier chiffré protégé par un unique mot de passe, le seul qu'on soit obligé de retenir.
  • NotePad++ comme éditeur de texte : il supporte la coloration syntaxique pour pleins de langages. Par contre, je trouve son interface un peu confuse.

Le seul programme dont je ne suis pas totalement satisfait, c'est DéKiBulle pour écouter les OGG et autres MP3. Si vous avez une meilleur suggestion, je suis preneur !

Notes

[1] J'utilise aussi Firefox et Thunderbird, mais ils sont archi-connus.

Sat 12 Mar 2011

  • David Mentré

Présentation de MapOSMatic

Le lundi 7 mars dernier, j'ai fait une présentation de MapOSMatic, un site web permettant à chacun de faire son plan de ville à partir des données d'OpenStreetMap :

  • présentation générale du site ;
  • comment nous avons fait pour faire ce logiciel ;
  • comment ça marche derrière la page web ;
  • quelques infos sur la prochaine version.

Les transparents sont maintenant disponibles, en version PDF ou les sources LaTeX.

Une remarque sur l'origine du nom, puisqu'on nous demande toujours pourquoi on a utilisé un nom pareil. ;-) MapOSMatic = « Map » pour carte en anglais + « OSM » pour OpenStreetMap + le suffixe « atic » comme dans automatique. Simple non ? :)

Wed 19 Jan 2011

  • David Mentré
  • 4

« OpenData » à Rennes, ça avance !

J'étais mardi à la Cantine Rennaise pour assister à un BarCamp OpenData à propos du concours « Rennes Métropole en accès libre ». Je ne candidate pas au concours mais comme j'ai pas mal critiqué l'actuelle licence des données « libérées » par Rennes Métropole et que j'avais eu en retour une discussion avec des acteurs du dossier[1], j'ai voulu aller aux nouvelles.

Le dossier avance ! Une nouvelle version de la licence est en préparation, dont on peut espérer un brouillon en ce début d'année. Des clauses seront supprimées, par exemple la clause qui oblige la mise à jour de son application en cas de changement de l'API. Une contrainte même pour des gens qui font des applications propriétaires, comme me le faisait remarquer un collègue. Reste à voir le résultat final, affaire à suivre ! ;-)

Sinon, soirée très sympa, où j'ai rencontré pas mal de Gulliveriens et d'anciens Gulliveriens. Sylvain a pointé très justement ces questions sur la licence dans la partie questions de l'exposé. J'ai aussi eu un très bon contact avec des responsables du service SIG de la Ville de Rennes. Ils connaissent OpenStreetMap (et même MapOSMatic !) et envisagent diverses manières d'y contribuer. Ça prendra un peu de temps (probablement en 2012) mais on devrait voir des choses intéressantes. Là aussi, une affaire à suivre !

Sinon, la date du fameux concours a été repoussée. Pourquoi ? Parce que la mise à disposition des applications développées au grand public dépend de la vitesse avec laquelle Apple valide les applications sur sa plateforme propriétaire. Vous n'y voyez pas une contradiction ? Moi si : on ne parle que de données « Libres » mais les applications développées ne sont disponibles que sur la plateforme fermée et propriétaire d'un seul constructeur. Le monde est plein de paradoxes. :-)

Notes

[1] Il y avait aussi des gens d'OpenStreetMap et de Wikipédia.

Wed 20 Oct 2010

  • David Mentré
  • 9

Pourquoi l'« ouverture » des données de Rennes Métropole est insuffisante

cube-interdiction.jpg La Ville de Rennes et Rennes Métropole ont récemment mis en place un entrepôt accessible à tous de données publiques leur appartenant. On trouve sur ce site www.data.rennes-metropole.fr des informations concernant les transports, les données de la base « Guide Vivre à Rennes » ou des informations du Système d'Information Géographique (SIG) de la Ville de Rennes et de Rennes Métropole.

Cette ouverture des données est largement mise en avant par Rennes Métropole et la Ville de Rennes, avec un concours de 50.000 € de prix, une couverture médiatique comme cet article de Télérama ou la réception d'un « prix européen e-démocratie » lors du World e.Gov Forum.

L'ambition affichée est de « permettre aux usagers, aux développeurs, aux entreprises de s’approprier et de retravailler les données mises à disposition pour créer de nouveaux services utiles au grand public. » En tant que développeur et contributeur à la communauté des logiciels et œuvres Libres, je ne ne peux qu'adhérer à cette vision des choses. Permettre à quiconque d'utiliser des données publiques et les réutiliser dans d'autres œuvres est pour moi crucial.

Donc, comme tout bon utilisateur potentiel, je me suis précipité sur les conditions d'utilisation[1]. Et là j'ai été plutôt surpris ! En particulier l'article 4, « Obligations du Réutilisateur » précise :

Conformément à l’article 12 de la Loi, le Licencié s’engage à ce que les Informations ne soient pas altérées ni leur sens dénaturé. Le Licencié veillera à respecter l'intégrité des données, et notamment à ne pas les dénaturer et/ou tronquer. L'insertion de commentaires doit être clairement distinguée du contenu du concédant.

En d'autres termes, il m'est impossible de réutiliser les données dans d'autres œuvres composites, car en les intégrant je vais très certainement « dénaturer ou tronquer » les données. Un comble pour des données soit disant « ouvertes » ! Notez bien au passage que l'article 12 de la loi n°78-753 du 17 juillet 1978 précise bien que « Sauf accord de l'administration, la réutilisation des informations publiques est soumise à la condition que ces dernières ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et la date de leur dernière mise à jour soient mentionnées. » Donc un accord de l'administration peut permettre une réutilisation plus libre des données.

Prenons un exemple concret : imaginons que je veuille ré-intégrer la « localisation des points d'apport volontaire des déchets ménagers » dans la carte libre OpenStreetMap. Cette carte est ouverte, enrichie en permanence par des volontaires à l'échelle planétaire et Rennes y est très bien cartographiée. La localisation des conteneurs à déchets y serait très utile, ce serait un geste citoyen. Et pourtant avec la licence actuelle, c'est impossible. Je devrais forcément transformer les données pour les intégrer. Et comme la carte OpenStreetMap doit pouvoir être redistribuée et modifiable par n'importe qui, il m'est impossible d'y intégrer des données ayant de telles contraintes de contrôle d'intégrité.

Ce que Rennes Métropole aurait dû faire

Le plus drôle dans cette histoire, c'est que d'autres acteurs ont tout compris. Rennes Métropole et la Ville de Rennes ne font que recopier ces acteurs, mais en faisant tout de travers par cette licence inadéquate !

L'article de Télérama est éclairant sur ce point. Outre OpenStreetMap, Antoine Mairé y cite l'exemple des villes anglo-saxones qui ont ouvertes leur données, comme l'initiative anglaise Data.gov.uk. Mais quand on regarde les conditions d'utilisation de Data.gov.uk, on y lit que la personne réutilisant les données a le droit :

de copier, publier, distribuer et transmettre les données ;

d'adapter les données ; (le point crucial !)

d'exploiter commercialement des données, en combinant par exemple ces données avec d'autres données ou en l'incluant dans votre produit ou application.

La Ville de Rennes et Rennes Métropole aurait dû utiliser une licence inspirée des licences d'œuvres libres comme Creative Common BY ou BY-SA permettant à quiconque de transformer et intégrer les données. Sans ces conditions, les données « ouvertes » de Rennes Métropole sont inutilisables dans d'autres œuvres ou programmes, à l'opposé même du but initial de permettre aux usagers de s'approprier les données.

Peut-être qu'un jour nous aurons des données réellement ouvertes, et réellement réutilisables ! En attendant, passez votre chemin, il n'y a rien à voir sur data.rennes-metropole.fr.

Notes

[1] Lisez les, elles sont courtes et plutôt lisibles.

Sat 11 Sep 2010

  • David Mentré
  • 2

Literate programming: where we are and where we should aim at

Book and paper (CC-BY) Literate programming is an old idea: Donald Knuth invented it during the 70' to write TeX, the typesetting system.[1] The main idea of literate programming is to document a computer program while writing it by intertwining pieces of code and explanation. In other words, instead of writing a program, one writes a book that documents and contains the program. Then, two programs are used to extract the (i) the compilable code and (ii) the book ready to be printed.

The main philosophy behind literate programming is that:

  • One should document his/her program;
  • By putting program documentation very close to program text, we improve significantly the ability to update the documentation when the program is changed.

Where we are

Several literate programming systems now exist. Most of them are grand-child of the original Knuth's WEB system. They can be either generic, like noweb, or specifically tailored to a programming language like OCamlWeb for OCaml. The main idea of those tools is to write a LaTeX document and put pieces of code in it. For example, I have used noweb to write demexp, a special voting system for massive direct democracy. The OCaml code of demexp can be read like a book.

The main issue with those tools is that you need to write a LaTeX document. You cannot use your preferred (or mandatory) IDE to edit the code and it is rather cumbersome to use in a Windows environment.

That's why we have developed Lp4all. LP4all is a literate programming system where documentation is put within the language comments, using a special syntax close to a Wiki one. From those special comments one can generate web pages, like those for Lp4all itself.

However I'm not using Lp4all!

I'm not using it because, in my last document at work, I needed all the power of LaTeX:

  • Advance LaTeX packages to make special figures, add hyperlinks to the generated PDF document, ...
  • Use LaTeX ability to create special counters for dedicated cross-references;
  • Ability to pretty-print a relatively confidential programming language;
  • etc.

So, on one side, I need the flexibility of Lp4all, its ability to integrate within any IDE or development environment. On the other side, I need a complex documentation system, giving to me all the tools to fine tune my documents and produce quality documents. Moreover, Lp4all is limited to a single program while I need to generate various documents from a single source.

Where we should aim at

(or at least some ideas about it ;-)

One simple solution to above dilemma would be simply to add LaTeX capabilities within Lp4all. Some tools like ocamldoc (the OCaml equivalent to JavaDoc) is following this approach, with extensions to mark parts using the LaTeX syntax. This probably the most practical approach. After all, Wikipedia is using the LaTeX syntax for mathematical formula.

However I find that this approach is not satisfying.

First of all, LaTeX is a very weak system (a package can break another package) and is very complex to use when you want to extend the system. It would be much simpler if we could have a documentation system build upon a sane language.

Moreover, to really exploit the full potential of literate programming, one needs to produce and track dependencies between several documents. For example, if I modify the specification, I need to modify some parts of the code. Inversely, if I change my code I need to know which part of the "specification" have to be updated. This tracking between pieces of code/documentation goes to test, user documentation, code documentation, test review, Q&A documents, GUI design, mathematical scripts describing an algorithm, formal models to check the software, etc. And more importantly, if I modify a piece of this code/documentation, I need a list of all document parts I need to review and possibly update, a kind of make on steroids.

A third point is that one needs more graphical interfaces: it would be easier to graphically link a piece of code to a document paragraph describing it than create a LaTeX reference and reference it later in the document. Moreover, documents nowadays use graphics extensively and we need to link pieces of code/documentation and some graphics. For example, it would be interesting to link the drawing of an automaton with the set of functions in a code implementing this automaton. And when navigating through the software, it is crucial to be able to go from a given automaton state in the graphics to the code implementing it and vice versa.

And of course, one needs a system agnostic documentation software, running on many platforms and working with all possible kind of IDE and languages.

Overall, one needs an integrated documentation system that is able to encompass all the kind of artefacts that make a software and that can be used to maintain those artefacts along the whole life of the software, from design to maintenance. And this system should be flexible enough to not constrain you to a fixed development environment, letting you chose the tools that you prefer.

An interesting proposal in that regard is Scribble, a system for writing library documentation, users guides and tutorials. Scribble allows to write LaTeX like documents, JavaDoc like documents to document libraries or WEB-like literate programming documents. However Scribble is tightly linked to the Scheme language and thus lacks the important platform independence feature.

As you see, my proposed ideas are rather general and I am very far from being able to specify the documentation software I would like to have. I know for sure that the current documentation systems are not satisfying and I hope somebody will propose one day a better system, matching the needs we have to build better software. I would prefer not to have to implement it by myself. ;-)

Notes

[1] Knuth's literate programming system was called WEB, long before the Web was invented. :-)

Tue 24 Aug 2010

  • David Mentré
  • 4

La fin du bureau ?

Un aspect social du bureau (licence CC-BY) On parle de plus en plus de la fin du bureau, du desktop, au profit d'« applications » web. Tristan Nitot se pose par exemple la question de l'avenir de Linux sur le poste de travail. Même les développeurs Gnome s'y mettent, comme Luis Villa demandant à la communauté Gnome de prendre à bras le corps le web (« to embrace the web »). Et bien sûr lil faut compter sur Google qui, de Google Chrome à Google Docs, vise à fournir tous les outils et applications pour laisser nos informations dans le nuage (c.-à-d. sur les serveurs de Google), loin de nos PC de bureau et nos portables.

Est-ce que l'avenir du PC et de ses applications est définitivement compromis ?

Certes, les applications web sont très pratiques. Gros utilisateur du webmail, j'apprécie sa disponibilité en toute situation, sur n'importe quelle machine pourvue d'un accès Internet et d'un navigateur. Et l'aspect centralisé des applications web est appréciable lorsqu'on utilise plusieurs machines, dans différents endroits. Enfin et peut-être surtout, l'aspect « social » des applications web peut être vraiment utile. Trouver la réponse à un problème technique dans un forum sur Internet est inappréciable et m'a sauvé plusieurs fois de plusieurs heures de recherches fastidieuses. Par ailleurs, les applications web sont faciles à déployer. Tout le monde à un navigateur sur son poste de travail, chez soi ou au travail. Et en tant qu'informaticien, il devient plus facile de déployer une nouvelle version de l'application.

Pour autant les applications web sont loin d'êtres parfaites et posent même de sérieux problèmes.

En premier lieu et probablement le plus important, nous perdons le contrôle sur nos données. En tant que Libriste convaincu, cela m'inquiète de laisser mes données chez Google ou Yahoo!. Je ne sais pas comment ses données personnelles sont stockées, qui peut y accéder ou même leur pérennité.

En second, les interfaces web sont très pauvres, malgré les progrès indéniables du Web 2.0 et des technologies AJAX. Google, expert et leader en ce domaine, arrive péniblement à finaliser le Glisser-Déplacer dans les dernières versions de GMail, alors que cela existe depuis des (dizaines d' ?) années sur les applications de bureau. Et quel que soit les efforts de programmation, la latence réseau sera toujours là, ralentissant l'interface au point de la rendre malcommode voire inutilisable. Sans compter que le réseau même doit être disponible en permanence, ce qui réduit d'autant la disponibilité des applications.

Alors, quel avenir pour le bureau et ses applications ? Je pense que le bureau n'est pas mort, que ce soit sur un PC de bureau, un ordinateur portable ou un téléphone portable. Par contre, les framework de développements doivent évoluer, prenant en compte dès le départ le réseau et la distribution des données. Pour reprendre un vieux slogan publicitaire de SUN, « the network is the computer » (le réseau est l'ordinateur).

Ces frameworks doivent fournir un moyen simple pour une application de stocker des données sur un ou plusieurs ordinateurs distants, de manière centralisée ou distribuée, et ce de manière sécurisée et authentifiée. Par exemple chaque utilisateur d'application devrait pouvoir facilement mettre en place un serveur pour stocker ses données ou répartir ses données entre plusieurs ordinateurs avec des protocoles Peer to Peer (P2P). La confidentialité des données doit être prise en compte dès le départ, que ce soit sur le bureau de l'ordinateur ou un serveur distant. Les frameworks doivent également fournir des API simples permettant de gérer les problèmes de latence d'un réseau sans que le programmeur soit un expert en réseau et en comprenne toutes les implications. La technologie d'appel de procédures à distance des années 80, les fameux RPC (Remote Procedure Call), encore utilisées dans les applications AJAX avec les XML RPC sont trop limités. D'autres paradigmes doivent être utilisés. Et bien sûr des API doivent être fournis pour développer facilement des applications « sociales » où l'ont peut partager facilement des données avec des autres utilisateurs sur la planète.

En bref, il va falloir inventer le meilleur des deux mondes. Mais un monde où l'utilisateur, le citoyen, garde le contrôle sur ses données. Comme le dit Philippe Meyer, « le progrès est en marche et le futur ne manque pas d'avenir ! » :-)

Correction 2010-08-24 : s/Christian/Tristan/. Merci Thomas ! ;-)

Sat 21 Aug 2010

  • David Mentré

De grands pas vers une téléphonie Libre !

Le projet OsmocomBB a pour objectif de créer une solution de téléphonie GSM (nos téléphones portables de 2e génération dit 2G) entièrement Libre, que ce soit sur le téléphone et la station de base.

Ce projet fait des progrès de jours en jours. Le dernier en date est qu'il a été possible de passer un appel de 20 minutes en utilisant uniquement des logiciels libres, tant sur le téléphone que la station de base !

Le déploiement de telles solutions est encore très loin, ne serait-ce que parce que les fréquences utilisées pour la téléphonie GSM sont soumises à des licences au coût exorbitant. Mais je trouve exaltant cette incursion du Libre dans le royaume du propriétaire et les progrès qui sont fait en si peu de temps ! Relisez le blog d'Harald Welte pour vous en convaincre.

Mon 29 Mar 2010

  • David Mentré
  • 5

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!

Thu 14 Jan 2010

  • David Mentré
  • 1

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!

page 2 / 5