Kiwix au jour le jour

Nginx or Apache, Mirrorbrain and Piwik

Kelson — Sun, 09 Dec 2012 17:36:00 +0100

At Kiwix we were impacted by a long term issue: we were unable to give practical and accurate download statistics. Our traffic partly goes to our web site and the other part goes to a storage place where all the big files (ZIM, ZIP, ...) are published. Of course, we wanted to have as much details as possible about both of them. After hacking at little bit, this problem seems now to be fixed, here is how I did it.

Audience measurement

To measure Web audience, there are two approaches:

Insert a "plugin" (dynamic image or javascript code) on each web page. Every time a web page is loaded, it stores the page name, date and details about the visitors browser in a database. This is extremely efficient and there exist many free offers on the Web to do that; but this method has two disadvantages. First, if you use free commercial tools, like Google analytics or Xiti, you actually sell the privacy of your users. Second, this approach is inefficient to measure file downloads because no web page is involved. To avoid the first one, you can install a free solution like Piwik, which is pretty neat, on your own server; this will avoid informing a third part about your visitors. Unfortunately, you cannot overcome the second problem.

Configure your web server to log everything and parse afterwards the log. There is a free software to do that: AWstats. AWstats is pretty old and not practical at all. In addition, I failed to configure it so that it merges multiple requests from an IP on one file in only one record (big files are downloaded in chunks).

Our case

We have been using Piwik for many years for our web site and we are really satisfied with it: it's practical, quick enough and maintained. Our problem is focused on http://download.kiwix.org. Our case is even a little bit worse, because, in fact, we do not really host our files. download.kiwix.org acts as master redirecting requests to mirrors. It uses a solution called Mirrorbrain. In addition to its many weaknesses, AWstats is not able to deal correctly with HTTP 301 and 302 redirections.

We have decided to put everything in Piwik, because it is better to have everything in one tool and also because this is the best one to visualise logs. We have now for both sites:

A central place to view logs
All the features of Piwik

Our solution

We have installed Piwik and inserted the mandatory piece of code on http://www.kiwix.org to track the visitors visiting our web site. This is easy and straight forward. Then we created in Piwik a second site for http://download.kiwix.org (one instance of Piwik can deal with statistics of many sites).

Later, we configured the Apache virtual host with Mirrorbrain to save logs on the hard disk and let it run for a few days.

Finally, we wrote a custom PHP script to upload the logs to Piwik, using a Piwik PHP class called PiwikTracker.php. Here are its features:

Parse all log files for a web site (also all .gz files of logrotate)
Able to start from scratch to upload all logs
Able to "follow" the log file an update in real time Piwik.
Count HTTP redirections (HTTP 301 and 302) errors as valid downloads (mandatory for Mirrorbrain)
Merge multiple similar requests to one (only one download for one content per IP in one month)
Avoid counting request for directories, md5 checksum, favicon, ...
Re-upload only new logs by two consecutive runs
Works with both Apache and Nginx
Configurable on the command line with arguments
Warning: it cannot report about the number of downloads completed.

This script is for our own purpose, but I think it's pretty simple to reuse it; it's pretty simple and you should not need to adapt it too much. Hope this was helpful!

Kiwix Compile Farm

reg — Thu, 14 Jun 2012 14:52:00 +0000

Kiwix is a special software. Special because it's difficult to define:

A Desktop software for browsing offline content with ZIM on Mac, Windows and Linux.
A Server allowing to serve ZIM content on those platforms + arm Linux.
A library of ZIM files for popular content: Wikipedias, Wikileaks, etc.
Very few developers (most of the time it's 2).
Very large (and growing) number of users.
“Small” code base (about 50,000 lines of code).

So far, all this was maintained by hand, the ZIM files are created from a complex procedure of scripts and mirror setups, the releases are created manually on all platforms, etc.

You got it, it's difficult to keep up with improving the software, fixing bugs, generating new content ZIM files, building and testing the software on all platforms.

Our first step into the right direction was getting the translations done on TranslateWiki and it got us to ship Kiwix now with 80+ languages.

Thanks to sponsorship by Wikimedia CH, we decided to first tackle the build problem as it's the most annoying.

The Problem

Kiwix releases on the following:

Mac OSX 10.6+ Intel Universal (Intel 32b, Intel64b)
Linux 32b “static“ (no dependencies)
Linux 64b static
Sugar .xo for OLPC
Windows 32b.
Armel5 (kiwix-serve only)
Source code.
Debian wheezy package 32b.
Debian wheezy package 64b.
Linux 32/64b with dependencies (used to be a PPA for Ubuntu until they removed xulrunner).

Knowing that only reg has a Mac, that the Windows setup for building Kiwix is complicated and that both Kelson and reg are using Linux, testing and distributing new versions of the code is very difficult.

This is not a unique problem ; most large multi platform softwares faces the same issue and we did nothing but imitate them: we deployed a build farm.

The Solution

The solution looks like the following schema: a bunch of Virtualbox VM, a Qemu one for arm, buildbot on all of them.

As you can see, the builbot master controls all the slaves which creates their own builds and sends them to the Web server's repository.

Buildbot

A compile farm is a set of servers ; each building a platform or target of the software. To manage those, [a large number of software|http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software\ exist.

After some research, we chose Buildbot because:

It seemed easy to install
It looked very powerful
Its documentation was clear.
It's written in Python (including the configuration file).

The deal-maker was really the tutorial on the website wich allowed us to imagine the required steps without to actually get our hands dirty.

The Python configuration file is a great feature as it allows a very flexible configuration without a dedicated syntax.

Builbot is divided into two softwares:

the master which holds the whole configuration (the only file you care about).
slaves which only needs to run the slave software (python). Those are logic-less.

Kiwix already rent a very powerful server in a data center for serving downloads. We used it to hold everything.

VirtualBox

All the build slaves (except for the arm target which is not supported by VBox) are VirtualBox Virtual Machines (VM):

512MB RAM
20GB HD
2 NIC: NAT for accessing Internet (dhcp) ; Host-only for buildbot (Fixed local IP).

OSX VM is 1GB RAM and 40GB HDD.

All the VMs were installed through VRDP (VNC-like protocol) until the network is configured and ssh access is enabled.

QEmu

QEmu was required to get an armel VM. We used aurel32's debian images.

Note: In order to ease the SSH connexion, halt and start of the VMs, we wrote a wrapper script around VirtualBox.

Configuring and running

Configuring buildbot is pretty straightforward once you know what you want to do. Configuration is composed of the following components:

Slave definitions (name, login, password)
Builders: targets composed of steps (commands) executed on a slave.
Schedulers: Triggers for when to start builders.
Status: What to do with output of builders.

The hard part is defining the builders as this is where you indicate how to retrieve source code, launch your configure script, compile, and tranfer your build somewhere else.

Take a look at ours as an example: master.cfg

We don't use any advanced feature so it's easy to understand. We chose:

fixed time daily to run our builds (at night – server time)
builds (tarball, etc) are uploaded to the server's /var/www/ for direct web access.

Buildbot handles the transfer of files between master and slave.

We can trigger builds at any time from the web interface.
We list build results on the web page and by mail in a dedicated mailing-list.
Builds are announced and controllable by the IRC bot.

Although it's simple, it takes a lot of tweaks and tests (fortunately it's easy) to get the configuration as wished, you need to have a proper and documented build mechanism for all your targets otherwise you'll probably go crazy. We completed a complete rewrite of our autotools Makefiles for all platforms before we setup buildbot. It sounds dumb but it's worth noticing.

Outcomes:

Every day, a new release for all targets available for download ; properly named with the SVN revision and the date.
Ability to fire a build at any time from the Web UI.
Kiwix to be integrated into Debian sid in the coming days (and thus in the next stable release).

Things you should know:

If you intend to reproduce, here's a few things we've learned and want to share.

Installing OSX on non-Mac hardware is tricky: you need a recent Intel CPU (support for VTx) but not too recent otherwise your OSX Install DVD won't know about it (and refuse to install).
On OSX, Apple packages (MacOSX updates, XCode) have an expiration period. If you install an XCode version 2 years (that's an example) after it's been released, the installer will fail with no useful feedback. It's due to the package's signature being too old. You can still install it by unpacking/repacking the packages.
SSH to your QEmu VM is done using a QEmu proxy so you ssh to localhost on a different port.
VRDP requires a good connexion if you intend to do a lot of configuration inside Windows (384k clearly is a pain!).
Buildbot slaves freezes frequently. Not sure why but sometimes it fails to answer to build request and stays attached doing nothing. As a workaround, we delete and recreate the buildbot slave folder daily in a cron job.
Buildbot slaves have network issues some times. We're not sure if it's related to buildbot, VBox or something else but it's frequent that the slave can't checkout the source tree or can't download our dependencies from the web.
Windows slave frequently loose connexion to the master. Might just be a Windows configuration issue.

What's Next?

Improve our wrapper script to handle VRDP access to VMs by controlling iptables.
Add SSH to the Windows slave so we can do basic tests in console.
Investigate the network/slaves problems so that it works 24/7.
Automate & build a similar platform for the creation of ZIM files so we can focus only on code thereafter.

5 ans déjà !

Kelson — Fri, 02 Sep 2011 14:57:00 +0200

Il y a cinq ans le projet Kiwix était lancé. Cela faisait déjà 6 mois à l'époque que c'était dans les cartons et après quelques tentatives de faire financer la chose par Wikimédia France, il a bien fallu se rendre à l'évidence : cela ne se ferait pas de cette manière.

Comme dit le diction On n'est jamais aussi bien servi que par soi même, je lançais donc le projet par moi même.

Où en sommes-nous aujourd'hui :

L'intérêt pour l'accès à nos contenus hors-ligne est plus grand que jamais. Kiwix et openZIM occupent une place de choix parmi les solutions techniques proposées.
Nous avons maintenant une solution tout à fait viable pour Windows, OSX et GNU/Linux avec pas mal de fonctionnalités intéressantes. Bref, nous sommes bien plus loin que nos objectifs initiaux.
Kiwix a fusionné complètement avec Moulinwiki et nous sommes désormais un peu plus nombreux à travailler sur le logiciel, même si nous sommes vraiment encore trop peu.
Nous avons une audience honorable et en croissance constante avec au dernier recensement environ 300 visiteurs uniques et 120 téléchargements du logiciel par jour.
Kiwix est soutenu par plusieurs chapters très concrètement et par la WMF, ainsi que des organisations extérieures au mouvement.

Sur quoi travaillons nous :

Nous voulons sortir la version 0.9 finale d'ici la fin de l'année et investissons beaucoup pour améliorer l'ergonomie du logiciel et sa stabilité.
On cherche en parallèle à augmenter le nombre de plateformes supportées avec plus de binaires, des packages et de nouveaux ports (pour Sugar par exemple, mais nous tentons aussi de trouver des solutions pour Android).
Nous voulons aussi absolument améliorer la version serveur http de Kiwix et développer une solution clef-en-main pour Plug computers.
Améliorer la communication et faire participer plus de gens (amélioration du site Web, meilleur communication avec l'aide de la WMF, utilisation de Translatewiki, mise en place d'un système de Feedback, …).
Développer des outils pour rendre la création de ZIM beaucoup plus simple.
Documenter et faciliter les déploiements massifs de Kiwix.

Face à tous ces challenges, il faut tous ensemble faire un effort et toutes les bonnes volontés sont le bienvenu. Pour ma part je travaillerai à partir d'octobre à temps plein sur Kiwix.

Kiwix 0.9 beta1 for Win/Mac/Linux is out!

Kelson — Fri, 22 Jul 2011 15:56:00 +0200

I have released the first beta of Kiwix 0.9. Binaries for Win32, MacOSX, Ubuntu (PPA) are available, like the source code. You may download them from Sourceforge or Kiwix Web site.

This took us almost 9 months to prepare this release... what is really a long time between two dev. releases. But a lot of things were done like:

the Mac OSX port,
the integrated content/download manager,
the new search user interface.

Behind the scene, we newly integrate:

aria2c to deal with downloads/uploads,
ctpp2 as a template engine,
pugixml as xml parser,

... and revamped the whole set of compilation scripts.

Here is the CHANGELOG:

Remove a hard coded path in kiwix-compact.sh (ID: 3135956)
Avoid the flickering during mouseover links after canceling the indexing
Under Windows, installer adds now shortcuts to all users
Force loading no plugin to avoid any problem (with libmoon for example)
Under Windows, the displayed (disk) "space required" value is now correct in the installer
kiwix-index backend argument is now an option and set as "xapian" per default
Fix regressions responsible for lower case titles in result list (ID: 3147594)
Implement the HTTP 404 error in kiwix-serve
Fix a small bug in the indexing code to avoid forgetting around 100 articles per ZIM file
Disable DNS pre-fetching for external links
New locales: Polish, Dutch
Open a ZIM file directly from the command line
Gnome and KDE integration: mime-type recognition + icon & application associations (ZIM double-click feature)
New checksum checker to be able to check ZIM file integrity
A list of ZIM files to download is dynamically downloaded in the help page if user online (ID: 3165272)
Simplification and improvement of the searchbar (no search button anymore, always available, standardized, ...)
New Find-in-text bar (like in firefox, at the bottom), to replace the dialogbox.
Result sidebar removed and replaced by a result web page "a la google"
Usage of jar files for a quicker startup
Kiwix for Mac OSX
kiwix-serve CPU usage improvement (ID: 3213104)
Update the Window title by switching the tabs
New integrated content manager/downloader
Introduction of Desktop notifications (ID: 3315162)
New way to open link in new tab with shortcuts or drag&drop (ID: 3311320)
Option to change the profile directory

The most important, we have done the mandatory work to setup a decentralized solution to spread/share content (ZIM Files). We still do not use all the power offered by the Metalink tech... but we will (we still need new mirrors, please contact us if you have one).

As a result almost all features we wanted to introduce with 0.9 are now there. We plan to use the next beta and RC releases to fix bugs (I'm sure we will also detect a few regressions) and polish the software. 0.9 Final release should be there for Christmas in the worth case.

More people than usual were involved. I want especially to thank:

Tomasz and Ryan, from the WMF, for the big support and together work,
Renaud for the OSX port,
Testers (join us) which were for the first time really involved and helped us so much with their remarks.

Content manager: challenges and solutions

Kelson — Fri, 01 Apr 2011 11:03:00 +0200

This is the translation of my previous post in French. Thx Rupert for it.

Kiwix 0.9 has now beta status and it's time to think seriously about version 1.0. The integrated management of content is Kiwix 1.0 core functionality, namely ZIM files and search indexes. Kiwix will provide a new usage experience when downloading, sharing, organizing, deleting of different content can be done without using or installing other tools. Distribution of content will benefit if we make the Kiwix users life even simpler than today. To provide such functionalities we are currently addressing the following challenges:

new content can be downloaded out of Kiwix
the software needs to be robust and fast
even if a content server fails or is disconnected, the user can continue to download and share content
the download cost need to stay low even if the volume skyrockets
downloading and sharing content must be easy, even if the LAN is cut off the internet

The architectural solution we envision to fullfill the above requirements is to combine the specific advantages of a centralized download via FTP/HTTP (for efficiency) and decentralized P2P (for ruggedness and low cost). The standard which seems to best match the requirements is Metalink. Metalink is an XML standard for defining content by using a checksum, its sources (HTTP, FTP, magnet, Bittorrent) and priority rules on these sources. Examples for such rules are the geographic location, or simply a rating system for the mirrors. The format is still fairly young, but it is being standardized by the IETF. Compared to more traditional solutions of uniquely using HTTP, FTP or P2P, the technology combines the strengths of each while eliminate the disadvantages.

To use Metalink, the following is necessary:

a server capable of generating metalink files, torrent, different HTTP and FTP mirrors, etc.
a client that can interpret the metalink files. It will need to manage all available sources, download the best and ensure sharing.

Metalink has also some existing implementations for the server called Mirrorbrain, and for the client, called Aria2. By using them we hope to keep the implementation effort low. To verify the architectural and tool choices we will make a prototype.

Lets elaborate a little bit on the server side. Mirrorbrain is a software originally developed for openSUSE, but now used by many other large projects. It is an Apache module that allows for a given file, released a bunch of checksums, one. metalink, one. torrent, a link magnet and of course the list of mirrors that have the file, taking into account the geographic location of the clients IP address. A list of tools to know what the mirror has what file is currently available, etc. When using Mirrorbrain, we can concentrate on:

synchronization of mirrors with rsync
the "Superseed" for Bittorrent
possibly a Bittorrent tracker and DHT node if you do not want (only) use the trackers / public nodes.

On the client side, Aria2 is a command line client which "understands" .metalink files and manages the rest. Aria2 is therefore able to download files, and can also share files coming originally from different sources via various protocols, at the same time. It is actively developed for several years and is very light. Via its XML-RPC interface it can be controlled out of Kiwix. Exactly this interface is most likely the largest part of the implementation work.

Finally, this leads us the the last challenge we need to address: where to get the .metalink files, and therefore the available content, from? Especially if no central server is available (e.g. in some mesh network scenarios) .metalink files need to be available on the client device. The plan is to integrate .metalink files into the XML files managing the content index of Kiwix. Such an XML file then would list at the same time contents available on local storage, as well as contents available for download. In the beginning, we want to just include some default index into Kiwix. Later on index files can be shared via the same technology developped for the contents itself.

Kiwix 1.0 : Quels enjeux ? Quelles solutions ?

Kelson — Fri, 11 Feb 2011 11:37:00 +0100

Kiwix 0.9 a à peine entamé son cycle de betas que nous commençons en parallèle à sérieusement penser la version 1.0. Deux raisons à cela : la musique s'accélère pour Kiwix et nous ne voulons surtout pas avoir la tête dans le guidon.

Kiwix 1.0 apportera comme fonctionnalité principale, la gestion intégrée des contenus (pour faire simple : fichiers ZIM et indexes de recherche). Cela signifie que le téléchargement, le partage, l'organisation, la suppression des différents contenus se fera dans Kiwix et non à l'aide de logiciels externes. Nous pensons que c'est nécessaire pour simplifier la vie de l'utilisateur, mais aussi pour favoriser la distribution des contenus.

Nous pourrions évidement implémenter et intégrer un simple téléchargement HTTP ; mais cela ne serait à notre avis pas pleinement satisfaisant. Voici les quelques défis que nous pensons nécessaires de relever :

Il faut que le téléchargement de nouveaux contenus soit simple et puisse se faire depuis Kiwix directement.
Il faut que la solution logicielle soit robuste et rapide.
Il faut que même si la plateforme de téléchargement ainsi que ses miroirs tombent (ou sont censurés), que l'utilisateur puisse continuer à télécharger/partager des contenus.
Il faut que la plateforme de téléchargement reste bon marché, même dans le cas de très nombreux téléchargements.
Il faut que les contenus soient téléchargeables et partageables facilement, même dans un réseau local coupé d'internet.

Pour réussir, nous voulons combiner les avantages particuliers du téléchargement centralisé via FTP/HTTP (pour l'efficacité) et du P2P... en particulier du P2P décentralisé (pour la robustesse et le bas cout). Pour toutes ces raisons, notre choix technologique s'est porté sur Metalink.

Metalink est une norme XML qui permet de définir un contenu (en particulier à l'aide d'une somme de contrôle), des sources (HTTP, FTP, magnet, Bittorent) et des règles de priorité sur les sources (en fonction de la location géographique par exemple, ou tout simplement avec l'aide d'un système de note pour les miroirs). Le format est assez jeune encore, mais il est en cours de normalisation par l'IETF. Les avantages de Metalink sont clairs par rapport à des solutions plus traditionnelles uniques comme HTTP, FTP ou le P2P ; cette technologie permet de combiner les points forts de chacune d'entre elles tout en élimant les désavantages.

Pour utiliser Metalink, il faut :

une solution serveur capable de générer les fichiers .metalink, .torrent, les différents miroirs HTTP et FTP, etc. et
une solution client capable d'interpréter les fichiers .metalink, de gérer toutes les sources disponibles, de télécharger au mieux ainsi que d'assurer le partage.

La solution serveur s'appelle Mirrorbrain. Mirrorbrain est un logiciel développé à l'origine pour openSUSE, mais utilisé aujourd'hui par de nombreux autres gros projets. Mirrorbrain, c'est plusieurs choses :

un module pour Apache qui permet, pour un fichier donné, de sortir tout un tas de sommes de contrôle, un .metalink, un .torrent, un lien magnet et naturellement la liste des miroirs qui disposent du fichier en tenant compte de la localisation géographique du client (localisation par IP),
une liste d'outils pour savoir quel miroir possède quel fichier, est actuellement disponible, etc.

En utilisant Mirrorbrain, il ne nous restera à gérer:

la synchronisation des miroirs avec rsync,
le "superseeder" pour Bittorrent,
éventuellement un tracker Bittorrent et noeud DHT si on ne souhaite pas (seulement) utiliser les trackers/noeuds publics.

L'introduction de Mirrorbrain devrait donc être assez vite réalisée ; dans les faits elle est déjà bien entamée.

Coté client, la meilleure solution qui nous soit accessible se nomme Aria2. Aria2 est un logiciel de téléchargement en ligne de commande qui comprend les fichiers .metalink et gère tout. Aria2 est donc capable de télécharger, et partager lorsque c'est possible, en parallèle un même fichier depuis différentes sources et en utilisant différents protocoles. Il est activement développer depuis plusieurs années et est très léger. Il dispose d'une interface XML-RPC permettant de le contrôler depuis Kiwix. Là se trouve probablement le plus gros du boulot ; Il nous faudra rapidement faire un prototype pour valider ce choix.

Le dernier point en suspend semble être alors la question de la disponibilité des fichiers .metalink ; en-effet, que faire si les fichiers .metalink sont indispensables et que le serveur central est indisponible ? Notre idée est d'intégrer les .metalink dans les fichiers XML gérant la bibliothèque de Kiwix. Un tel fichier pourrait donc indistinctement lister des contenus présents sur la mémoire de masse, comme des contenus disponibles en ligne au téléchargement.

La question ultime concernerait alors la mise à disposition des ces fichiers bibliothèque. Un début serait déjà de les livrer par défaut avec Kiwix. Dans tous les cas de figures, distribuer un fichier de quelques milliers de kilooctets est bien moins problématique que de distribuer les contenus en eux mêmes qui font plusieurs gigaoctets.

La Wikimedia Foundation soutient Kiwix

Kelson — Wed, 26 Jan 2011 12:18:00 +0100

Nous le souhaitions depuis longtemps, la Wikimedia Foundation soutient désormais officiellement Kiwix. Le blog technique de la Fondation l'avait laissé entendre quelques fois ces dernières semaines ; mais c'est grâce à un billet complet sur le sujet "Wikipedia offline" que la nouvelle a été annoncée.

Cette décision est le fruit du travail autour des futures orientations stratégiques qu'a lancé la Foundation il y a maintenant presque deux ans. Après avoir décidé que la priorité stratégique absolue était d'augmenter la taille du lectorat, la Wikimedia Foundation s'est donc logiquement intéressée aux solutions de mise à disposition hors-ligne des contenus. Kiwix a alors retenu son attention.

Cela nous réjouis naturellement beaucoup de pouvoir compter sur ce nouveau soutien. La première étape de cette collaboration a d'ors et déjà débuté : il s'agit d'un effort commun pour analyser et améliorer l'expérience utilisateur. Ce travail est prévu pour durer quelques mois et son aboutissement corrélera probablement avec la sortie finale de la version 0.9 de Kiwix.

L'autre excellente nouvelle, qui va certes un peu de soi, est que le projet OpenZIM que nous avons lancé a aussi retenu leur attention et est partie prenante des solutions choisies. Un contrat avec PediaPress a été conclu pour que très rapidement leur extension pour Mediawiki nommée "Collection" permette aussi de créer des fichiers ZIM.

Aujourd'hui, Kiwix fonctionne déjà très bien et il est maintenant aisé de faire des DVD avec des contenus issus de Wikipédia. Grâce à ce nouveau soutien, la promesse d'une distribution des contenus encore plus vaste, totalement libre et dénuée d'intérêts commerciaux sera probablement en mesure d'être tenue.

Sortie de Kiwix 0.9 alpha1, aussi pour Windows

Kelson — Tue, 18 May 2010 13:14:00 +0200

Il y a toirs semaines j'ai publié la première ébauche de Kiwix 0.9, soit la version alpha1. Nous travaillions depuis l'été 2009 sur cette nouvelle version et c'est donc le premier pas vers une finalisation de cette branche 0.9. Cette release propose déjà environ 70% de l'ensemble des fonctionnalités qui seront présentes dans la version 0.9 finale. En particulier :

Il y a maintenant une version serveur Web dénommée kiwix-serve.
Le support de Windows fête son retour, et cette fois c'est permanent.
Support des dernières améliorations de ZIM, en particulier la compressions LZMA (plus rapide, moins gourmand en ressources)
Réintroduction du système de suggestions qui fonctionne directement avec ZIM (pas besoin d'avoir un index de recherche)
Création d'un installeur pour Windows (merci Wilfredo et Moulinwiki)
Système de signets

Voici le CHANGELOG complet de Kiwix 0.9 alpha1 en anglais:

ZIM library management outside the profile
Windows support & installer
Fix the Hebrew search issue with the doublequote character (ID: 2939690)
First version of the search suggest feature (ID: 2799913)
New icon (with white background) (ID: 2981323)
New ZIM HTTP server called "kiwix-serve"
New Command line indexation tool called "kiwix-index"
Allow drag&drop over the UI to open a ZIM file
Autodection of the UI locale at the first start (GNU/Linux only)
New "Recently open" menu
New internal library of ZIM (to be able to manage many ZIM files)
New Hebrew, Portuguese, Chinese and Persian localization
New Bookmarks and Notes system (coming from Moulinwiki)
New script to compact search engines indexes in the profile called "kiwix-compact.sh" (ID: 2834599)
Translate ISO code in the language sub-menu (ID: 2834600)
New "Save Page" (in files) feature (ID: 175508)
New "Print as PDF" feature
kiwix.sh check for current path (ID: 2850487)
First result is now only loaded with a pretty good score (ID: 2845850)
"Report a bug" and "request a feature" links in the UI
Fixing issue affecting ZIM file loading with accented paths (ID: 2905488)
New feature to clean the profile at the end of the session (optional)
Redesign of the "About" Dialog box

Du point de vue du code, la situation s'est aussi largement améliorée puisque le tout compile maintenant avec les GNU autotools et que le processus est bien documenté ; en particulier pour la compilation sous Windows. Une conséquence de ceci est que l'on peut penser maintenant fournir des paquets pour GNU/Linux et du travail a déjà été fourni dans ce sens. Un paquet DEB (Debian et Ubuntu) sera désormais systématiquement fourni au téléchargement... en attendant que Kiwix soit inséré officiellement dans Debian. Un paquet RPM pour Fedora est en cours.

Reste maintenant à faire :

Recherche multi-ZIM
Gestion de multiples tabs
Support de MacOS
... et corriger les quelques bugs connus ;)

Liens :

Sortie de Kiwix 0.8

Kelson — Wed, 24 Feb 2010 12:48:00 +0100

J'ai publié Kiwix 0.8 il y a quelques jours. C'est une version mineure pour l'utilisateur car elle apporte quasiment rien de nouveau en terme de fonctionnalités ; certaines même ont été supprimées. Depuis 6 mois les versions de test se sont succédées et comme plus aucun bug n'était signalé et que je travaillais depuis longtemps sur la version 0.9, je me suis décidé à le faire maintenant. Pour terminé, cette version fonctionne uniquement sous GNU/Linux ; ce qui est tout de même handicapant pour de nombreux utilisateurs en Occident... dans d'autres pays, cela l'ai beaucoup moins.

Cependant, d'un point de vue technique, la version 0.8 est un pas important :

Tout à été réécrit de manière beaucoup plus propre et modulaire et le code a été documenté.
Kiwix se base maintenant entièrement pour les contenus sur le format ZIM dont le développement est maintenant indépendant avec la création du projet openZIM. En clair cela veut dire que n'importe qui peut faire un ZIM et Kiwix pourra le lire.
Le moteur de recherche est désormais Xapian, un moteur de recherche éprouvé et libre qui bénéficie d'un bon support et offre de très nombreuses possibilités. Kiwix offre aussi maintenant un indexer intégré, cela signifie que si vous avez des ZIM, Kiwix peut facilement les indexer et offrir la fonctionnalité de recherche sur ces nouveaux contenus. Un autre point important est que toutes les recherches sont maintenant insensibles à la casse et aux accents grâce en particulier à la librairie libunac.
Le processus de localisation est maintenant stable et il y a de plus en plus de langues supportées.

Bref, avec la version 0.5, nous avions fait la preuve de la validité du concept. Avec la version 0.8 les bases sont jetés pour faire un logiciel réellement ouvert et de qualité professionnelle.

Voici le CHANGELOG presque complet :

Small improvement by the kiwix.sh launcher (should work now under Slackware (see https://sourceforge.net/forum/message.php?msg_id=7561932)
Fix sporadic segfault by indexing (ID: 2823597)
Fix dynlib linking issue affecting at least Slackware and Fedora
Use xapian-core-1.0.14
Fix the "no icons available" issue (ID: 2830824)
Fixed toolbar icons with RTL languages
Improved toolbar UI (added icons & tooltip)
Fixed window size/position restore
Fixed address-bar not displaying TOC URLs (ID: 2806208)
Fixed anchored link not working (ID: 2806207)
High reducing of the xapian index disk usage
Improvement of the history management
Ignore now, by indexing, HTML pages with the NOINDEX meta tag
French/Spanish/German/Arabic/Italian translation of the software help
Fixed language switch menu (ID: 2822178)
New logo and artworks
Bug fix by the indexing process observer (ID: 2811642)
Add a gray version of the buttons
Able to index a ZIM by itself
First version of a software help
Add a cache strategy
Use now ZIM
Random page feature (ID: 2799134)
Fix an issue concerning URLs with local anchors (ID: 2798769)
Localisation of Xulrunner builtins (ID: 2799815)
Rewrite the buggy MD5 code
Remember the window geometry (ID: 1671235)
32 bits support for large ZIM file (ID: 2801839)
Use now Xapian

Pour rappel, telles étaient les versions précédentes de Kiwix :

v0.5 au printemps 2007
v0.7 à l'hiver 2008 (pas de support)

Comme on peut le voir le rythme des sorties n'est pas très élevé (c'est un euphémisme). Cela est en train de changer, j'ai repris en main le dev. du logiciel lui-même alors qu'auparavant je travaillais surtout sur les scripts de génération du HTML. J'ai par ailleurs de l'aide en ce moment. Par voie de conséquence, la version 0.9 est déjà très avancée et les premières versions alpha devraient sortir au mois d'avril avec en particulier le retour du support complet de Windows.

Pour plus d'informations :

Binaire statique pour x86_32 GNU/Linux
Screencast d'une alpha de 0.8
Quelques fichiers ZIM pour cette version de Kiwix
Le CHANGELOG complet
La feuille de route pour les prochaines versions
Le catalogue de bugs et de demande fonctionnalités
Comment compiler Kiwix 0.8 (beaucoup plus simple pour la version 0.9)

Avez-vous dit ZIM ?

Kelson — Tue, 26 Jan 2010 17:17:00 +0100

Il y a un an environ, deux acolytes et moi-même fondions le projet openZIM. L'objectif était la spécification d'un format de données adapté au stockage des articles issus de Wikipédia ainsi que la création d'une bibliothèque logicielle et d'outils nécessaires à la manipulation dudit format.

Nous travaillons aujourd'hui sur les dernières améliorations de ce qui sera probablement la première version officielle. Cependant, avant de détailler le projet et le format, je souhaite revenir brièvement sur les conditions de sa création.

L'une des questions qui se pose assez rapidement lorsque l'on réfléchi sur comment rendre accessible une version statique de Wikipédia est Comment vais-je stocker ces quantités importantes d'information ? Le cahier des charges, formulé de manière simplifiée, étant :

mémoire de masse nécessaire la plus réduite possible
temps d'accès les plus réduits possible

Dans les faits, rien n'existait qui satisfasse vraiment ces contraintes. Les solutions de compression actuelles étant particulièrement incapables d'offrir des temps d'accès acceptables (un dixième de seconde maximum par ressource).

Chaque initiative a donc essayé de faire au mieux (sachant que cela n'était qu'un aspect parmi d'autres) et la meilleure des approches que j'ai pu voir consistait à compresser N articles par fichier (typiquement avec Bzip2 ou LZMA) et de tenir un index dans une base de données locale indépendante (type SQLite). Ce type de solutions souffre cependant des inconvénients suivant :

avoir à gérer séparément l'index et les fichiers de contenu
compresser des contenus qui éventuellement le sont déjà (typiquement JPEG ou PNG)
ne pas offrir de bibliothèque avec API simplifiée
avoir à gérer de nombreux fichiers
ne pas être correctement documentée
gestion native des catégories (dev. en cours)
gestion des meta-tags (dev. en cours)

Telle était la situation lorsque en 2007 nous nous sommes pour la première fois rencontrés : Manuel, Tommi et moi-même. Tommi nous a alors présenté quelque chose d'intéressant : il avait programmé un lecteur libre pour le format de données ZENO qu'utilisait Directmedia (la maison d'édition qui publiait les DVDs de Wikipédia en allemand). Le format ZENO était intéressant parce que tout était dans un fichier et que l'on avait maintenant une librairie pour le décoder.

Il restait deux gros défis :

augmenter l'efficacité de la compression
écrire un outil pour créer les ZENOs

En l'espace d'un an, Tommi ayant fait cela et Directmedia ayant décidait de ne plus publier de DVD en allemand et d'abandonner ZENO ; nous nous sommes dit qu'il y avait vraiment là quelque chose à faire. Nous avons alors conçu le projet openZIM et renommé le format, qui entre temps avait beaucoup évolué, en ZIM (pour Zeno IMproved).

Aujourd'hui le format et les outils sont meilleurs que jamais :

tout tient dans un fichier
tout type de contenus peut être introduit
compression LZMA
compression paramétrable en fonction du mime-type
portable
librairie de référence extrêmement efficace
Index par titre et par URI

Nous sommes subventionnés par Wikimedia CH qui couvre nos frais de serveur ainsi que ceux occasionnés par nos rencontres. Le format ainsi que les outils continuent d'évoluer rapidement et sont de loin la meilleure solution actuelle… Ce qui est assez compréhensible finalement puisqu'il n'y a pas de véritable alternative.

La fondation Wikimedia s'est montrée intéressée pour proposer des dumps au format ZIM et nous discutons les contraintes techniques d'un tel projet. Kiwix utilise évidement ZIM et propose déjà quelques fichiers ZIM à tester. Je suis aussi convaincu que de plus en plus de projets seront en mesure de travailler avec ce format.

Le travail n'est pour autant pas terminé. Il reste en particulier à implanter quelques fonctionnalités importantes et à régler quelques points problématiques. Il nous faut aussi stabiliser le format ; en-effet, le rythme des améliorations est toujours soutenu et la rétro-compatibilité a déjà été cassée par deux fois : une chose pourtant indispensable pour une utilisation plus large.

... mais le jeux en vaut la chandelle !

Pour plus d'informations :

Lancement du blog

Kelson — Wed, 30 Dec 2009 14:11:00 +0100

Mise-à-jour : Le blog a été ajouté aujourd'hui au Planète Wikimédia francophone. Je remercie Johann pour son aide.

Depuis que je travaille sur Kiwix, et on approche des quatre ans, je m'interroge sur la nécessité de tenir un blog. Après avoir longtemps tergiversé, j'ai décidé de tenter l'aventure et de voir si cela en vaut la peine. J'espère que mes lecteurs, vous, me gratifierez au début de votre indulgence, voire de vos conseils, sachant que je suis débutant dans cet exercice.

Je pense publier ici en grande majorité des articles en français et probablement le plus souvent techniques. Je parlerai aussi évidement du projet openZIM que nous avons lancé en début d'année avec Manuel et Tommi, et qui me tient beaucoup à cœur.

Les lecteurs qui me lisent par l'entremise du planète de Wikimédia France ne doivent pour autant pas s'inquiéter : je ne les spammerai pas avec de nombreux articles loin de leur préoccupations. Les catégories et les tags sont à disposition pour permettre de satisfaire cette exigence ; au pire je m'autoriserai quelques digressions touchant la culture libre.

Pour ceux qui souhaitent suivre au plus près les développements de Kiwix :

Le site web où la page de garde est une bonne source d'informations. Les pages importantes sont pour la plupart traduites en anglais et espagnol.
Le fil de micro-blogging de identi.ca ; mais en anglais seulement et le plus souvent technique.
Le planet qui est multilingue... et encore un peu vide.
... et maintenant ce blog.