Archéo Lex S02E01

Au départ, Archéo Lex n’était qu’un prototype (voir la première saison S01E01 et S01E02). Quatre ans après, beaucoup d’octets ont traversé les internets, Archéo Lex fait désormais partie d’un petit paysage de ce que l’on pourrait appeler la légistique numérique libre ; et si on devait en faire un TrucTech, ça pourrait être “Libre LawTech”. Aujourd’hui, l’ensemble des codes est présent sur le site archeo-lex.fr, ils sont sont mis à jour quotidiennement et ce site voit son interface simplifée. Par ces trois améliorations, Archéo Lex devient réellement utilisable par les utilisateurs autres que les geeks, et notamment par les juristes et archéologues du droit.

Lire la suite...

Plans comptables français en Open Data au format CSV et GNUCash

GNUCash est un logiciel de comptabilité parmi d’autres. Il a pour avantages d’être libre et gratuit, ainsi que de gérer la comptabilité en partie double – c-à-d la comptabilité professionnelle.

Il a pour inconvénient d’être plutôt orienté vers la comptabilité anglo-saxonne. Toutefois, en y chargeant un bon PCG français (plan comptable général), on peut l’utiliser pour y faire de la comptabilité française. Je dis PCG parce que c’est probablement le plan comptable le plus courant, mais les associations utiliseront la variante PCA (plan comptable associatif).

Lire la suite...

De la création

Il fallait un billet inaugural, le voici. L’idée mijotait depuis un bon moment quand j’ai franchi le cap : j’ai créé mon entreprise de conseil en logiciel libre. Plus exactement, cela fait six mois que j’ai doucement commencé mon activité. Aujourd’hui, ce billet fait le point sur ce début d’expérience, puis termine sur un petit cadeau libre.

Lire la suite...

De la matérialité du numérique

Avant d’aborder l’idée elle-même et pour illustrer mon propos, je vais commencer par présenter une anecdote et suivra ensuite le fond de ma pensée. Le début du billet est un peu technique (mais ça n’est pas grave si vous comprenez pas tout), la suite est plus philosophique.

Il y a quelque temps, je voulais que la musique stockée sur mon ordinateur puisse être jouée ailleurs dans mon appartement, et plus spécifiquement depuis mon petit serveur qui trône sur une étagère du salon et sur lesquel je peux brancher de bonnes enceintes, meilleures que celles de mon ordinateur. (Bien sûr, je pourrais aussi les brancher directement sur mon ordinateur, mais ça compte pas :) En résumé, je veux que la musique stockée sur mon ordinateur soit entendue là-bas. Voilà le petit serveur sur lesquel est branché des enceintes.

Lire la suite...

Genèse d’Archéo Lex

Lorsqu’il fut découvert en août 2014 via Twitter et Regards Citoyens, plusieurs furent intéressés par le concept d’Archéo Lex : « visionner facilement les codes de loi français et leur évolution », avec une traduction en language tech : « versionner sous Git en syntaxe Markdown les codes de loi français ». Je présente dans ce billet la genèse d’Archéo Lex et discuterait dans le prochain billet des évolutions futures possibles.

Lire la suite...

Archéo Lex, Pure Histoire de la Loi française, pour étudier son évolution

Est-ce que vous avez déjà eu envie de parcourir les différentes versions des lois ? ou de suivre leur évolution ? ou de rechercher de quand datait l’introduction d’une certaine notion dans la loi ? C’est cette dernière interrogation qui m’a poussé à créer la semaine dernière un outil permettant d’ordonner toutes les versions d’une loi (et les codes en particulier) dans un format pratique pour pouvoir naviguer facilement entre toutes ces versions.

Plus exactement, chaque texte législatif est un simple fichier texte rédigé en syntaxe Markdown (c’est-à-dire du texte simple avec une syntaxe spécifique surtout pour structurer les titres et les listes) et versionné sous Git, permettant d’utiliser toute la panoplie d’outils de Git pour faire des comparaisons entre versions, retrouver la première version, etc.

Vous pouvez voir le résultat sur le code qui m’a servi à tester l’outil (code que j’affectionne particulièrement :-), le code de la propriété intellectuelle :

https://github.com/Seb35/CPI

Lire la suite...

Installation de Debian 7 sur DreamPlug

Depuis trois jours, j’installe Debian 7 sur un DreamPlug. Il avait auparavant le Debian 6 d’usine fourni par Marvell, mais cela commençait à devenir vieux : sécurité de moins en moins assurée, noyau Linux 2.6, évolution des versions des logiciels, etc. À partir de Debian 7, Debian prend en charge directement les DreamPlugs, ou disons la famille des GuruPlugs. J’ai donc tenté la mise à jour qui n’a pas été de tout repos. Je retrace ci-après les grandes étapes et surtout les problèmes que j’ai rencontrés.

Ce qui suit s’applique au passage du Debian 6 customisé Marvell au Debian 7 naturel en passant par l’installeur Debian naturel, et en écrasant tout le système préexistant. Il est peut-être possible de faire une mise à jour simple avec apt-get dist-upgrade, mais il y aurait peut-être des problèmes du fait qu’il faudrait probablement mettre à jour en même temps U-Boot, le bootloader, en 2012.04 et Debian (j’ai eu des problèmes de par le passé à vouloir mettre à jour U-Boot en gardant Debian 6). Cet article tente de donner (presque) toutes les commandes qui ont été nécessaires à cette installation de Debian 7 sur DreamPlug.

Préparation

Je supposerai dans la suite que vous disposez, outre le DreamPlug, d’un autre ordinateur sous GNU/Linux relié au DreamPlug au moyen d’une connexion UART/JTAGUSB (vendue avec le DreamPlug ou à l’unité). Sur cet ordinateur, vous pouvez utiliser l’utilitaire minicom (fourni dans un paquet Debian et probablement disponible ailleurs aussi). Si vous avez un autre plug computer que le DreamPlug, ne suivez pas directement ces instructions et reportez-vous à ces autres documents. Bien sûr, il va sans dire mais ça va mieux en le disant qu’il est très souhaitable de faire une sauvegarde des données existantes du DreamPlug avant l’installation de Debian 7.

Martin Michlmayr a écrit plusieurs documents sur les plugs computers, dont les DreamPlugs qui nous intéressent, et en particulier un guide de mise à jour vers Debian 7. La première étape importante est de mettre à jour Das U-Boot, le bootloader des DreamPlugs, vers la version 2011.12-3 ou plus récente. Pour ma part, j’ai utilisé la version 2012.04.01-2 de Debian 7 en téléchargeant ce paquet et en utilisant la version spécialement compilée pour le DreamPlug (copier le bon fichier u-book.kwb sur une partition accessible à U-Boot, par exemple sur une carte SD ou une clé USB formatée en ext2, ext3 ou FAT32 -- de mémoire l’ext4 n’est pas lu par les vieilles versions de U-Boot antérieures à 2010).

Avant de se lancer dans cette mise à jour de U-Boot, j’ai également mis sur une partition accessible à U-Boot l’installeur de Debian 7 récupéré dans l’archive Debian (copier les uImage et uInitrd spécifiques au DreamPlug ; leur donner des noms spécifiques plutôt que d’écraser les fichiers existants, par exemple uImageD7 et uInitrdD7). Noter qu’une bonne pratique est de vérifier les sommes de contrôle des paquets téléchargés lorsque c’est possible pour prévenir toute corruption des paquets ; pour Debian, les sommes MD5, SHA-1 et SHA-256 sont indiquées sur la page de téléchargement et peuvent être vérifiées avec md5sum, sha1sum et sha256sum.

Mise à jour de U-Boot

Une fois le DreamPlug redémarré et observé au travers de la connexion série UART/JTAG, il faut arrêter le lancement du système en appuyant sur une touche (par défaut on a trois secondes pour ce faire). Ensuite peuvent être affichées les variables d’environnement U-Boot pour vérification :
Marvell>> print
ou
Marvell>> printenv

La variable d’environnement la plus importante est bootcmd qui est celle qui sera exécutée lors des lancements automatiques, et bootargs est également importante puisqu’elle contient les arguments qui seront passés au noyau Linux. Il est possible d’exécuter du code inscrit dans d’autres variables d’environnement U-Boot en appellant run NOM-VARIABLE ; cela permet de décomposer les instructions de démarrage en plusieurs sous-sections.

Pour lancer la mise à jour de U-Boot, il faut commencer par lancer le sous-système USB de U-Boot :
Marvell>> usb start
puis chercher la partition sur laquelle vous avez mis les fichiers u-boot.kwb et les uImageD7/uInitrdD7 de l’installeur Debian. Si vous ne savez pas, vous pouvez essayer successivement les numéros de 0 à 5 (?) dans les commandes suivantes jusqu’à trouver les fichiers :
Marvell>> ext2ls usb 0
(Si la partition est en ext2 ou ext3 ; si la partition est en FAT32, ce sera fatls et fatload dans la suite.)

Pour mettre à jour U-Boot, il faut exécuter la séquence qui suit. Bien sûr, le usb NUMÉRO est issu de l’étape précédente. Attention, en cas d’interruption au milieu, il est possible que le DreamPlug ne redémarre pas, assurez-vous qu’il n’y a pas d’orage, que le courant ne sera pas coupé, etc.
Marvell>> ext2load usb NUMÉRO 0x0800000 u-boot.kwb
Marvell>> sf probe 0
Marvell>> sf erase 0x0 0x60000
Marvell>> sf write 0x0800000 0x0 0x60000

Enfin, redémarrez le DreamPlug et arrêtez à nouveau le démarrage.
Marvell>> reset

Installation de Debian 7

Si vous avez bien mis les deux fichiers d’installation de Debian 7 uImageD7 et uInitrdD7 sur une partition accessible à U-Boot, chargez ces deux fichiers en mémoire (sinon il est encore temps de les mettre sur une clé USB à partir d’un autre ordinateur).
Marvell>> usb start
Marvell>> ext2load usb NUMÉRO 0x00800000 uImageD7
Marvell>> ext2load usb NUMÉRO 0x01100000 uInitrdD7
Marvell>> setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most
Marvell>> bootm 0x00800000 0x01100000

Ensuite, l’installeur Debian va se lancer, vous poser des questions pendant un petit quart d’heure et prendra ensuite quelques heures pour installer le système Debian 7. Je n’ai pas eu de problèmes lors de cette étape mis à part un avertissement à la fin de l’installation prévenant que le bootloader ne pouvait pas être mis à jour, mais cela peut être ignoré puisqu’on a fait la mise à jour à l’étape précédente. J’ai ensuite redémarré le système, ce qui n’était peut-être pas la meilleure idée : s’il est proposé de lancer directement le système à la suite, sautez sur l’occasion et passez au dernier titre ci-après pour compiler un noyau « sans NAND_ORION » – j’expliquerai ce que c’est.

Problème d’identification de la machine par Linux : machid

Normalement, l’installeur Debian a déposé dans le dossier /boot du système le noyau (3.2.0-4-kirkwood pour moi) et le système Debian 7 devrait normalement se charger avec la séquence suivante de U-Boot :
Marvell>> usb start
Marvell>> ext2load usb NUMÉRO 0x00800000 uImage
Marvell>> ext2load usb NUMÉRO 0x01100000 uInitrd
Marvell>> setenv bootargs 'console=ttyS0,115200 rw root=/dev/sda1 rootdelay=10 panic=10'
Marvell>> bootm 0x00800000 0x01100000

Notez que le /dev/sda1 est peut-être à remplacer si votre système racine a été installé sur une autre partition, et que les uImage et uInitrd ont peut-être d’autres noms.
Notez aussi que vous pouvez automatiser le processus de lancement en fixant une fois pour toutes la variable d’environnement bootargs et surtout bootcmd, cette dernière avec :
Marvell>> setenv bootargs 'printenv; usb start; ext2load usb NUMÉRO 0x00800000 uImage; ext2load usb NUMÉRO 0x01100000 uInitrd; bootm 0x00800000 0x01100000'
Marvell>> saveenv

En lançant ce noyau Linux Debian 7, celui-ci (le noyau Linux) répond dès le début qu’il ne reconnait pas le matériel :

Error: unrecognized/unsupported machine ID (r1 = 0x00000dde).
Available machine support:
ID (hex)        NAME
00000690        Marvell DB-88F6281-BP Development Board
00000691        Marvell RD-88F6192-NAS Development Board
00000692        Marvell RD-88F6281 Reference Board
0000078c        Marvell 88F6281 GTW GE Board
00000a76        Marvell eSATA SheevaPlug Reference Board
00000831        Marvell SheevaPlug Reference Board
00000a63        Marvell GuruPlug Reference Board
[...]
00000b1e        HP t5325 Thin Client
ffffffff        Marvell Kirkwood (Flattened Device Tree)
Please check your kernel config and/or bootloader.

Puisque j’ai recherché les causes de ceci, je vais vous en faire profiter :-) Linux s’attend à reçevoir une indication sur le type de matériel sur lequel il se trouve ; dans le cas des processeurs ARM, ces numéros sont référencés dans le fichier arch/arm/tools/mach-types du noyau Linux. Dans notre cas, le DreamPlug a le numéro hexadécimal 0xdde (=3550) (ne cherchez pas dans la liste de Linux, il n’y est pas :/ il est sur le site officiel de ARM). La version U-Boot de Debian indique donc le bon identifiant de matériel, mais Linux ne le connait pas.

L’ancienne version de U-Boot (Marvell customisée) donnait à Linux l’identifiant hexadécimal 0xa63 (=2659), le GuruPlug étant très proche du DreamPlug. C’est donc ce que nous allons faire. Pour cela, il faut configurer la variable d’environnement U-Boot machid à 0xa63 :
Marvell>> setenv machid a63
Marvell>> saveenv

Sur les forums, il est évoqué aussi la variable arcNumber mais il semble que cela était pour les (très) vieilles versions de U-Boot (d’ailleurs arcNumber n’apparaît pas dans les sources de U-Boot, contrairement à machid). L’option Flattened Device Tree est censée être une unification des configurations matérielles pour le futur, mais elle n’a pas fonctionné pour moi (le noyau ne se lance pas) et l’expérience est identique pour David Madore (que je remercie vraiment au passage car c’est lui qui m’a débloqué grâce à cette page dans les deux gros problèmes que j’ai rencontrés, avec quelques autres recherches sur le Web pour les instructions précises).

Une fois ces commandes exécutées, le démarrage de Linux se lance bien. Du moins dans mon cas pendant les 15 secondes suivantes.

Arrêt du chargement du noyau lors de l’initialisation du NAND Orion, inexistant sur DreamPlug

Le chargement du noyau Debian (3.2.0-4-kirkwood) s’arrêtait systématiquement après "console [ttyS0] enabled" dans la fonction "nand_read_byte". Plus exactement, c’est le watchdog qui retourne ce message toutes les 22 secondes. Pour être plus précis, c’est avec la fonction "orion_nand_probe" que les problèmes se posent. Voici mon log d’erreur exact :

[   11.167148] console [ttyS0] enabled
[   38.208674] BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
[   38.214621] Modules linked in:
[   38.217690]
[   38.219183] Pid: 1, comm:              swapper
[   38.223641] CPU: 0    Not tainted  (3.2.0-4-kirkwood #1 Debian 3.2.54-2)
[   38.230380] PC is at nand_read_byte+0xc/0x10
[   38.234673] LR is at nand_command+0x184/0x1c4
[   38.239051] pc : [<c0207e6c>]    lr : [<c020ace0>]    psr: 60000013
[   38.239056] sp : df82be80  ip : c020ab5c  fp : 00000000
[   38.250593] r10: 00000000  r9 : 00000000  r8 : ffffffff
[   38.255844] r7 : ffffffff  r6 : df8c4800  r5 : 000000ff  r4 : df8c4a20
[   38.262400] r3 : e08aa000  r2 : 00000081  r1 : ffffffff  r0 : 00000000
[   38.268958] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   38.276300] Control: 0005397f  Table: 00004000  DAC: 00000017
[   38.282093] [<c00137c4>] (unwind_backtrace+0x0/0xe0) from [<c0065068>] (watchdog_timer_fn+0xe0/0x134)
[   38.291361] [<c0065068>] (watchdog_timer_fn+0xe0/0x134) from [<c0043c94>] (__run_hrtimer+0x118/0x1ec)
[   38.300628] [<c0043c94>] (__run_hrtimer+0x118/0x1ec) from [<c00444bc>] (hrtimer_interrupt+0xf4/0x23c)
[   38.309903] [<c00444bc>] (hrtimer_interrupt+0xf4/0x23c) from [<c001a3a8>] (orion_timer_interrupt+0x20/0x30)
[   38.319701] [<c001a3a8>] (orion_timer_interrupt+0x20/0x30) from [<c0065958>] (handle_irq_event_percpu+0x7c/0x23c)
[   38.330015] [<c0065958>] (handle_irq_event_percpu+0x7c/0x23c) from [<c0065b40>] (handle_irq_event+0x28/0x38)
[   38.339895] [<c0065b40>] (handle_irq_event+0x28/0x38) from [<c0067d04>] (handle_level_irq+0xac/0xbc)
[   38.349077] [<c0067d04>] (handle_level_irq+0xac/0xbc) from [<c0065328>] (generic_handle_irq+0x28/0x44)
[   38.358438] [<c0065328>] (generic_handle_irq+0x28/0x44) from [<c000ee14>] (handle_IRQ+0x60/0x84)
[   38.367266] [<c000ee14>] (handle_IRQ+0x60/0x84) from [<c000db34>] (__irq_svc+0x34/0x78)
[   38.375314] [<c000db34>] (__irq_svc+0x34/0x78) from [<c0207e6c>] (nand_read_byte+0xc/0x10)
[   38.383627] [<c0207e6c>] (nand_read_byte+0xc/0x10) from [<c020ace0>] (nand_command+0x184/0x1c4)
[   38.392372] [<c020ace0>] (nand_command+0x184/0x1c4) from [<c020a150>] (nand_scan_ident+0x16c/0xa94)
[   38.401466] [<c020a150>] (nand_scan_ident+0x16c/0xa94) from [<c020be9c>] (nand_scan+0x48/0x68)
[   38.410128] [<c020be9c>] (nand_scan+0x48/0x68) from [<c040048c>] (orion_nand_probe+0x120/0x1b0)
[   38.418876] [<c040048c>] (orion_nand_probe+0x120/0x1b0) from [<c01ef9e0>] (platform_drv_probe+0x14/0x18)
[   38.428403] [<c01ef9e0>] (platform_drv_probe+0x14/0x18) from [<c01eeb10>] (driver_probe_device+0xd4/0x198)
[   38.438107] [<c01eeb10>] (driver_probe_device+0xd4/0x198) from [<c01eec34>] (__driver_attach+0x60/0x84)
[   38.447550] [<c01eec34>] (__driver_attach+0x60/0x84) from [<c01ed798>] (bus_for_each_dev+0x50/0x84)
[   38.456645] [<c01ed798>] (bus_for_each_dev+0x50/0x84) from [<c01ee40c>] (bus_add_driver+0x9c/0x218)
[   38.465740] [<c01ee40c>] (bus_add_driver+0x9c/0x218) from [<c01eeedc>] (driver_register+0xa0/0x12c)
[   38.474836] [<c01eeedc>] (driver_register+0xa0/0x12c) from [<c01efbb4>] (platform_driver_probe+0x18/0x68)
[   38.484454] [<c01efbb4>] (platform_driver_probe+0x18/0x68) from [<c00085a4>] (do_one_initcall+0x90/0x168)
[   38.494079] [<c00085a4>] (do_one_initcall+0x90/0x168) from [<c03e882c>] (kernel_init+0xbc/0x164)
[   38.502917] [<c03e882c>] (kernel_init+0xbc/0x164) from [<c000ee98>] (kernel_thread_exit+0x0/0x8)

Après recherches, et en particulier la page de David Madore, une page de forum de Fedora 17 et la discussion liée sur la liste ARM de Fedora et probablement ici aussi, il apparaît que le DreamPlug n’a pas le périphérique NAND Orion (contrairement à d’autres plug computers de la famille GuruPlug) mais le noyau essaye quand même de lire ce périphérique. Plus précisément, ce périphérique est géré par le module orion_nand du noyau. La solution évoquée pour Fedora et qui fonctionnait était de blacklister ce module. Pour Debian 7, cela ne fonctionnait pas d’après mes tests, d’autant que le module orion_nand chez Debian est un module intégré (built-in), impossible à désactiver donc. Pour Debian, ce problème correspond au bug 717470, rapporté pour les noyaux à partir de 3.9.x, et j’ai rencontré le problème également avec le noyau 2.6.x de Debian 7.

D’après David Madore, il faut compiler un noyau sans la directive de compilation CONFIG_MTD_NAND_ORION, et il apparaît que cela fonctionne effectivement pour le noyau Linux 3.2.x de Debian 7. Je détaille ci-après le mode opératoire pour compiler ce noyau fonctionnel sur DreamPlug. Je me suis permis de ne pas changer le nom du noyau (pas de « +nonand » ajouté au nom du noyau) étant donné que ce noyau est presque pareil que celui de Debian 7 à une directive de compilation (et donc réutiliser tous les autres modules) près et surtout que ça ne voulait pas compiler lorsque je changeai abi.abiname dans debian/config/defines (exception Python lors de l’exécution de make -f debian/rules source). À part ça, j’ai suivi HowToRebuildAnOfficialDebianKernelPackage sur le wiki Debian. (note : c’est la première fois que je compilai un noyau, il y a sûrement matière à mieux compiler ce noyau-ci.)

Pour éviter d’avoir à faire du cross-build depuis une autre architecture, le plus simple (qui a fonctionné pour moi) est de charger le système Debian 7 avec le noyau 2.6 de Marvell (téléchargeable ici). Redémarrer le DreamPlug et exécuter dans U-Boot :
Marvell>> usb start; ext2load usb NUMÉRO 0x00800000 uImage_dreamplug_v10_Aug-28-2012; bootm 0x00800000

Une fois connecté en root à Debian, exécutez :
$ apt-get install fakeroot build-essential devscripts quilt u-boot-tools
$ apt-get build-dep linux
$ apt-get source linux
$ cd linux-*
$ make -f debian/rules source
$ fakeroot make -f debian/rules.gen setup_armel_none_kirkwood
$ cd debian/build/build_armel_none_kirkwood
$ make menuconfig

Dans le menu de configuration du noyau qui apparaît, allez dans "Device Drivers" > "Memory Technology Device (MTD) support" > "NAND Device Support" > "NAND Flash support for Marvell Orion SoC" et désactivez cette dernière option.
$ cd ../../..
$ fakeroot make -f debian/rules.gen binary-arch_armel_none_kirkwood binary-indep DEBIAN_KERNEL_JOBS=1

Après quelques heures (et j’ai arrêté lors de la compilation des pages de manuel vu qu’elles étaient déjà présentes, et ça m’a pris entre 1 et 2 Gio), le noyau devient disponible dans le répertoire debian/linux-image-3.2.0-4-kirkwood/boot (les fichiers vmlinuz-3.2.0-4-kirkwood, System.map-3.2.0-4-kirkwood et config-3.2.0-4-kirkwood).
$ cd debian/linux-image-3.2.0-4-kirkwood

À partir de là, il faut créer le fichier initrd.img pour la version 3.2.0-4-kirkwood si vous ne l’avez pas déjà.
$ update-initramfs -u -k 3.2.0-4-kirkwood

Et enfin transformer les fichiers vmlinuz et initrd.img au format de fichier de U-Boot :
$ mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "Linux kernel 3.2.0-4-kirkwood" -d vmlinuz-3.2.0-4-kirkwood /boot/uImage-3.2.0-4+nonand-kirkwood
$ mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000 -n "Linux ramdisk 3.2.0-4-kirkwood" -d /boot/initrd.img-3.2.0-4-kirkwood /boot/uInitrd-3.2.0-4+nonand-kirkwood

Maintenant, pour charger ces noyau et ramdisk, il peut être pratique d’utiliser des liens symboliques pour les fichiers /boot/uImage et /boot/uInitrd (dans l’étape précédente, on a demandé à U-Boot de charger ces fichiers spécifiquement) (ça ne marche pas pour les partitions FAT32, il renommer explicitement les fichiers).
$ cd /boot
$ mv uImage uImage.old
$ mv uInitrd uInitrd.old
$ ln -s uImage-3.2.0-4+nonand-kirkwood uImage
$ ln -s uInitrd-3.2.0-4+nonand-kirkwood uInitrd

Maintenant, redémarrez le DreamPlug. Le système Debian 7 avec le noyau 3.2.x devrait se charger correctement (ça a été mon cas du moins). En cas de mise à jour du noyau, il faudrait également recompiler un noyau sans la directive de compilation CONFIG_MTD_NAND_ORION.

Je vais évoquer cette solution dans le bug 717470, mais je ne suis pas sûr de la résolution propre à effectuer, et cela rejoint les interrogations sur la liste de Fedora : comment faire en sorte de charger ce module orion_nand pour certains plug computers mais pas pour les DreamPlugs ? Il pourrait être utilisé la variable d’environnement machid donnée par U-Boot (0xdde = DreamPlug) mais Linux ne reconnait pas cette valeur et oblige donc à utiliser encore 0xa63 (= GuruPlug), ou alors utiliser 0xffffffff (= Marvell Kirkwood (Flattened Device Tree)) mais cela n’était pas encore fonctionnel. Si vous avez des idées ou plus d’expérience que moi, n’hésitez pas à compléter sur ce bug.

Pourquoi je ne crois pas à la privatisation du domaine public

Je n’ai pas l’habitude de poster sur ce blog, mais c’est bien pratique que d’avoir un endroit où exprimer des idées longues (i.e. pas Twitter). J’ai suivi ces derniers jours la polémique autour de la signature entre la BnF et deux partenaires privés pour la numérisation de deux fonds (70 000 ouvragres datant de 1470 à 1700 ainsi que des 200 000 vinyles). Les documents numérisés pourront être revendus par les partenaires privés et la BnF bénéficiera d’une copie à laquelle elle pourra donner accès dans ses locaux à Paris ainsi que, pour 5 % des œuvres, sur sa bibliothèque numérique Gallica. Dix ans après la numérisation, la BnF pourra utiliser comme elle veut les documents numérisés, par exemple pour les exposer sur Gallica. [Note : ces éléments sont ceux qui circulent sur le web, en particulier Actualitté.]

Rapidement, plusieurs personnes se sont prononcées contre ce partenariat (voir le blog S.I.Lex et les liens du billet, ainsi que Twitter #AccordsBnF), et une lettre a été écrite et signée par plusieurs associations (Savoirscom1, La Quadrature du Net, Framasoft, Veni Vidi Libri, Wikimédia France, etc.). Cette lettre parle entre autres de « privatisation du domaine public ». Certains, plus rares, s’opposent à cette lettre, ou ont une position plus douce.

Du haut de mes quelques connaissances en droit de la propriété intellectuelle et de la pratique amateure des licences libres, je ne comprend pas cette expression de « privatisation du domaine public », et par là même cette indignation par rapport à ce partenariat. J’expose dans la suite du billet ce pourquoi je trouve qu’on ne devrait pas utiliser une telle expression, puisqu’elle me semble factuellement fausse. Je demanderai aux libristes de ne pas (tout de suite) me considérer comme un vil capitaliste défenseur du système actuel de pooperty intellectual (je suis plutôt le contraire, mais là n’est pas la question). D’autant qu’il me semble (à moins que je rêve) que la communauté du libre existe et est tellement résiliente en partie du fait de la multiplicité des opinions.

Lire la suite...

La vie sera belle, récit d’une indignation

(Pour une lecture optimale, je conseille d’écouter en toile de fond Le rêve de Ridan.)

Indignez-vous !, ode au positivisme de Stéphane Hessel parue il y a quelques mois. Je l’ai lu il y a deux mois lors de la conférence Wikimania, à quelques mètres d’Indignés israéliens d’ailleurs. Je ne connaissais pas Stéphane Hessel mais j’ai été fortement touché en partie par les œuvres de sa vie mais surtout par ses révoltes actuelles dont il a su faire parler dans la peu-révoltée société française (même si celle-ci n’a pas franchement bougé depuis).

Depuis cette lecture, je me suis un peu renseigné sur ses critiques sur l’internet, et suis tombé en librairie (ouch! ça m’apprendra à acheter n’importe quoi) sur J’y crois pas ! d’Orimont Bolacre. Ça a été la pluie torentielle qui a fait déborder le vase.

Lire la suite...

Wikipédia et la pensée altermondialiste

Ayant commencé ce blog il y a peu (en nombre de billets), je me demande encore comment font les « blogueurs » pour trouver les sujets de leurs billets. Je commence donc celui-ci avec l’origine de son écriture, qui d’ailleurs fait partie intégrante du billet.

Étant à l’occasion sur Twitter et n’étant pas acharné, j’ai eu quelques difficultés à expliquer à mon entourage le concept de Twitter : les gens peuvent envoyer des petits messages de 140 caractères à un ensemble d’autres personnes, les messages étant généralement publics. En fait, une des raisons qui explique ma difficulté à expliquer ce qu’est Twitter est que à partir de cette idée de base, Twitter n’est que ce que les gens en font : certains racontent leur journée (intéressante ou pas), d’autres se focalisent sur un sujet, ou parlent de l’actualité avec un certain point de vue, et caetera. Un peu comme Wikipédia d’ailleurs, le but étant de contruire une encyclopédie, la rédaction étant ouverte à tous, et le résultat est que certains sujets sont très bien traités, d’autres absents ou de qualité moyenne, certains proviennent de traductions, d’autres ont un point de vue biaisé, un sujet est mieux traité dans une autre langue, et caetera.

Hier, explorant Twitter, je regarde une des listes de personnes ayant comme point commun d’être à Rennes, et je tombe sur le fil de @cbourbeillon, journaliste à Ouest-France et passionnée par l’Asie et la plongée sous-marine. Je comprends alors un des intérêts de Twitter : trouver des gens partageant des opinions ou passions communes, ce qui, je me rappelle maintenant, avait essayé de m’expliquer un ami, mais je n’avais alors pas bien compris (je pourrai rajouter ça dans mon explication de Twitter). De là, je continue sur le blog de Michèle Jullian et son billet « La très prochaine dictature universelle », à l’origine de ce billet.

C’est le premier paragraphe de Georges Bernanos qui m’a fait penser à cela : Twitter et Wikipédia s’inscrivent dans une démarche altermondialiste, dans le sens qu’ils contribuent à ouvrir les esprits en montrant aux gens qu’il leur faut penser par eux-mêmes. Il ne suffit pas de lire quelque chose sur Twitter ou Wikipédia pour être sûr que c’est « vrai » (j’ai quelques scrupules à utiliser ce mot, j’en parlerai dans un prochain billet), il faut chercher les informations originelles et informations connexes, croiser les sources et se faire une opinion, possiblement différente de l’information initiale d’ailleurs.

Lorsque Wikipédia est apparu et encore aujourd’hui, la première réaction d’une personne ne connaissant pas Wikipédia à qui on explique le concept est : « Mais tout le monde peut écrire n’importe quoi ! », et ma réaction est maintenant : « Oui. ». En ce sens, le concept de Wikipédia interpelle et choque pour quelqu’un habitué à la « pensée unique » fournie par les médias et les célébrités de ce monde, détenteurs de La vérité.

…suite au prochain billet :-)

Présentation

Bienvenue, welcome, bienvenudo, Willkommen, tervetuola!

Je me présente brièvement tout d'abord : je m’appelle Sébastien, autour des 25 années, habitant actuellement à Rennes et citoyen du monde.

Cela fait quelques mois que l’idée d’ouvrir un blog a germé, depuis que je m’implique corps et âme dans une asso dont j’aurai l’occasion de revenir, Wikimédia France, et par laquelle j’ai découvert le monde associatif.

Je comptais initialement parler essentiellement de Wikipédia, projet d’encyclopédie libre que j’ai rejoins il y a maintenant presque cinq ans, et du mouvement Wikimedia, mouvement pour la connaissance libre. Cependant, étant maintenant intéressé par le monde des assos en général (merci à Plume! et plein d’autres assos) ainsi que par les différentes problématiques altermondialistes actuelles (environnement, vie privée, diffusion de la culture, commerce et monde équitable, paix entre les peuples, éthique, anti-pub, économie sociale et solidaire…), je parlerai également de tout ça, avec ma vision qui sera parfois naïve.

Je n’aurai que l’occasion de le faire, mais je remercie toutes les assos, personnes, humains, chats, pommes, elfes et les autres qui œuvrent pour un monde dans lequel l’Être humain serait plus en accord avec ses semblables et la Nature plutôt qu’avec le profit immédiat et égoïste, tout ce monde qui me donne un peu d’espoir dans l’humanité contemporaine.

Rennes, 8 novembre 2010 (calendrier grégorien), 05h01

Lire la suite...