Skip to main content

Déçu

4 min read

Envoyé à la liste MozFr en réponse à l'annonce d'un débat public sur la Loi Renseignement.

 

Déçu.

C'est en un mot mon point de vue sur le débat d'hier soir.

Je ne blâme pas les intervenants, bien au contraire. Leur diversité et leurs différents points de vue sur la question étaient intéressants et éclairants.

Non, c'est plutôt contre tout le public que je tiens à m'exprimer. Il a fait preuve à de nombreuses reprises, à mon avis, d'un manque certain de respect envers les intervenants. Alors même que le débat n'était censé avoir lieu qu'entre les intervenants, qui avaient certainement préparé leur plaidoyers et qui avaient été choisis de sorte à établir un certain équilibre entre les points de vue, on a pu entendre d'abord les sarcasmes intentionnellement non dissimulés, et ensuite les interventions inopinées d'un public venu dans l'unique optique de mobiliser tout le monde contre cette loi et non d'en comprendre les arguments en sa faveur. Car il y en a, m'a-t-il semblé.

C'est ainsi que les intervenants se sont vus confisquer la parole, ne s'autorisant pas à gueuler plus forts que certains membres du public ayant abandonné toute forme de respect envers eux et plus généralement toute personne ayant un avis différent.

Le public n'a pas écouté, ou du moins pas entendu la présence d'arguments intéressants, comme le fait que cette loi, à côté des éléments de surveillance qu'elle légalise, permet une réelle clarification de l'organisation des services de renseignements, et s'est efforcé de cantonner le débat aux boîtes noires et à d'autres points purement techniques qui, bien que catastrophiques pour les libertés individuelles, ne sont pas les seuls points intéressants du débat.

Ce débat était une occasion de découvrir toutes les facettes de cette loi, les raisons qui y ont poussé, les revendications du syndicat de la magistrature qui s'y oppose pour des raisons extrêmements différentes des raisons techniques entendues par le public, le retour concret et pragmatique de la façon d'agir de la DST et la génèse de cette loi. C'était une occasion de se défaire de la bulle idéologique dans laquelle gravite certainement une large partie du public et qui aurait dû chercher à découvrir autre chose que les points noirs ayant fait le tour des articles qu'ils lisent et qui proviennent de la même bulle.

Il a manqué une volonté de comprendre le point de vue des différents intervenants qui s'est soldée par un manque de respect honteux à l'égard de gens ayant passé du temps à réfléchir au problème qui est loin d'être aussi simple et binaire que certains le pensent.

Et enfin, je pense que ces débordements n'auraient pas pu avoir lieu si le public n'avait pas bénéficié de la complicité déplacée d'une modératrice complètement partiale et se moquant parfois presque des intervenants, n'hésitant pas à les couper sans vergogne et abusant du peu de pouvoir que son rôle lui conférait pour prendre des décisions autoritaire sur le ton de qui découvre qu'il a cette possibilité.

J'ai donc éprouvé une certaine honte vis à vis des intervenants. Honte d'appartenir à un public aussi peu diversifié et aussi peu enclin à s'intéresser à une quelconque diversité.

En espérant ne pas être le seul à avoir vécu ce débat d'une telle façon,
Élie Michel

A docker-like container management using systemd

10 min read

This article is an overview of how you can manage docker-like containers using systemd.

As you may know, the famous container manager docker is not the only container technology. It has been originally based on LXC, though it embed additional functionalities, but it mostly provides a high level API for container management. And actually it has been made possible by a bunch of quite recent kernel features such as namespaces, control groups or union filesystems.

As I was reading the excellent series of Lennart Poettering's articles about the use of systemd for administrators, I found out that systemd is actually able to handle its own containers.

It is not so surprising actually, since systemd is close to the kernel and so provides an abstraction over a lot of its features. But anyway, I did not know it was so easy-to-use!

I present in this article the basics of systemd-nspawn, the enhanced chroot that systemd brought to us to build containers.

Our first container

Let's start with some practical example, directly inspired from one of the Poettering articles. We are going to run a simple Debian inside the most basic container.

Set up files

We use debootstrap to pull a minimal Debian on our filesystem. This command is available on most linux distributions (well, I checked for apt, yum and yaourt, using AUR).

debootstrap --arch=amd64 unstable debian-tree/

It downloads Debian unstable files in the local debian-tree directory.

NB: I use Debian as an example, but using yum or pacstrap, you can install respectively fedora or arch as easily.

Run container

Just run systemd-nspawn (eventually as root):

systemd-nspawn --directory=debian-tree/

NB: You can use -D instead of --directory=

It performs some kind of chroot and open up a shell inside the hosted system. It not only isolates local filesystem from its host, but also abstracts its interfaces. It is much more powerfull than a simple chroot.

NB: By default /bin/sh is called inside the container, but you can specify the command you want systemd to run into the container as an extra argument. In that case, arguments specified after the command are forwarded to it and not treated by systemd-nspawn.

But we just mounted the Debian filesystem actually, and no more. If you call ps, you will not see any process but the shell (even if you are root).

root@debian-tree:~# ps
  PID TTY          TIME CMD
    1 ?        00:00:00 bash
    6 ?        00:00:00 ps

The Debian OS has not really started. Before we do so, think about setting a password for your root user, you will need it later:

root@debian-trash:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

Booting container

Call systemd-nspawn with --boot option (or -b). Alternatively, you can ask systemd-nspawn to run /sbin/init:

systemd-nspawn -D debian-tree/ --boot
# or
systemd-nspawn -D debian-tree/ /sbin/init

You should see boot messages, with lines beginning with [ OK ]. Also, if you are hosting a distribution relying itself on systemd, e.g. a recent release of Debian, you would see interesting message at the early boot:

Spawning container debian-trash on /your/current/path/debian-trash.
Press ^] three times within 1s to kill container.
systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
Detected virtualization 'systemd-nspawn'.
Detected architecture 'x86-64'.

[...]

You can notice that the hosted systemd detects that it has been ran inside a systemd-nspawn container! You can use systemd-detect-virt at any time to get this information.

Also note that you can escape the container (and so kill it) by pressing ^] (Control key plus ]) three times quickly, which can be useful, especially if you forgot to set any root password.

Managing containers

Docker provides a nice API to manage your containers. While systemd is not as exhaustive, it also have an interface for it, though the machinectl command (like "machine control").

$ machinectl
MACHINE                          CONTAINER SERVICE         
debian-tree                      container nspawn          

1 machines listed.

You can get more information about one particular container using machinectl status <machine>:

$ machinectl status debian-tree
debian-tree
           Since: mar. 2015-04-07 08:46:37 CEST; 55min ago
          Leader: 24553 (systemd)
         Service: nspawn; class container
            Root: /home/system/local/debian-tree
         Address: 192.168.1.108
                  fe80::2ae3:47ff:fe04:f134
              OS: Debian GNU/Linux 8 (jessie)
            Unit: machine-debian\x2dtree.scope
                  ├─24553 /lib/systemd/systemd
                  └─system.slice
                    ├─cron.service
                    │ └─24618 /usr/sbin/cron -f
                    ├─systemd-journald.service
                    │ └─24571 /lib/systemd/systemd-journald
                    ├─console-getty.service
                    │ ├─14910 man machinectl
                    │ ├─14921 pager -s
                    │ ├─24625 /bin/login --
                    │ └─24656 -bash
                    └─rsyslog.service
                      └─24620 /usr/sbin/rsyslogd -n

NB: If you want to process machinectl status output, please consider using machinectl show instead. It has been designed with this goal in mind.

If the container's content supports it, you can use machinectl reboot, machinectl poweroff or machinectl login for example. You can still use machinectl terminate to simply kill the whole container, whatever is running inside it.

About security

It is well known that LXC containers are still not secure enough to be used as absolute jails. Actually, this is due to possible exploits of kernel weakness that are present because the introduction of containers technologies is recent. If you need full isolation, consider using solution such as [KVM].

And as you can see it using systemd-cgtop (systemd's real time cgroup visualizer), some information about the host system leaks into the guest machine:

On the guest

Path                                     Tasks   %CPU   Memory  Input/s Output/s

/                                            -  144.6     2.3G       0B    94.5K
/machine.slice                               -    1.5    30.9M        -        -
/machine.sli...e-debian\x2dtree.scope       7    1.5    12.3M        -        -
/system.slice                                -      -    71.0M        -        -

On the host

Path                                     Tasks   %CPU   Memory  Input/s Output/s

/                                            -  144.6     2.3G       0B    94.5K
/machine.slice                               -    1.5    30.9M        -        -
/machine.sli...e-debian\x2dtree.scope        7    1.5    12.3M        -        -
/system.slice                                -      -    71.0M        -        -
/system.slice/NetworkManager.service         2      -        -        -        -
/system.slice/accounts-daemon.service        1      -        -        -        -
/system.slice/avahi-daemon.service           2      -        -        -        -
/system.slice/bluetooth.service              1      -        -        -        -
/system.slice/colord.service                 1      -        -        -        -
/system.slice/dbus.service                   1      -        -        -        -
/system.slice/gdm.service                    2      -        -        -        -
/system.slice/geoclue.service                1      -        -        -        -
/system.slice/httpd.service                  7      -        -        -        -
/system.slice/ipython-notebook.service       1      -        -        -        -
/system.slice/itorch-notebook.service        2      -        -        -        -
/system.slice/polkit.service                 1      -        -        -        -
/system.slice/postgresql.service             6      -        -        -        -
/system.slice/redis.service                  1      -        -        -        -
/system.slice/rtkit-daemon.service           1      -        -        -        -
/system.slic...lice/getty@tty2.service       1      -        -        -        -

For instance, you can access from the contained system to the resources used by the host! You can also see all other machine started, since they are by default on the same cgroup slice, namely /machine.slice.

And another important point is that by default the network interface is not virtualized: the container accesses the same interface than the host (try some ip link). But the good news is that we can easily manage to isolate it. And we can even add bridges between host and guest interfaces.

Network isolation

Complete isolation

If you do not need any network connection, you can completely isolate the container from its host's network using the --private-network option:

systemd-nspwan -bD debian-tree/ --private-network

If you look at the available network interfaces, you will see only a loopback:

guest$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

And actually, this loopback itself is isolated from the host's loopback interface, so there is absolutely no communication between host and guess (wrt. the previously advertised security limitations, of course).

Adding bridges

Anyway, it is common to need the container to be able to listen on some port. For instance, the container can host some web server, or socket served service. So we need to be able to expose some interface to the container.

Providing Internet interface

The simplest solution is to provide the container with a whole network interface.

systemd-nspwan -bD debian-tree/ --network-interface=eth0

Now you can see eth0 from within the container. But the main drawback is that this interface would not be accessible from the host: it is moved from one host namespace to guest namespace.

guest$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff

Note that the host loopback cannot be moved to the guest. Also not that you could add a second --network-interface argument to use many network interfaces.

NB: As soon as you specify that you would share a network interface, it automatically hides the other one, as if --private-network was specified.

You can then create bridged or vlan interfaces in the host and provide them to the container. Fortunately, systemd-spawn comes with some options simplifying this process.

Virtual Ethernet link

You can use --network-veth to create a virtual Ethernet link between host and container.

systemd-nspwan -bD debian-tree/ --network-veth

You will see a new interface on the host machine, named ve-debian-tree like "virtual ethernet to debian-tree container" and the container will be provided a host0 interface.

In order to communicate, you must then add an IP address to these new interfaces. For instance, you could use the reserved 10.0.0.1/8 IP block:

# Add address 10.0.0.1 to ve-debian-tree interface of host system
host$ ip addr add 10.0.0.1/24 broadcast 10.0.0.255 dev ve-debian-tree
host$ ip link set dev ve-debian-tree up
# Add address 10.0.0.2 to host0 interface of guest system
guest$ ip addr add 10.0.0.2/24 broadcast 10.0.0.255 dev host0
guest$ ip link set dev host0 up

You can then check you setup using ping 10.0.0.1 and ping 10.0.0.2 on guest and host respectively.

Now that you can communicate between host and guest, you may want to forward some host external ports toward guest system and block the other ones using for instance iptables.

Mount host directory within guest system

Although unlike docker containers, a systemd-nspawn container is persistent (modifications are not forget at reboot), it can be made non-persistent using --volatile=yes and anyway it can be useful to bind some host directory to some guest directory.

You can achieve this with --bind=/my/host/directory;/my/guest/directory.

# Boot container and mount host's /home into it
systemd-nspawn -bD debian-tree --bind=/home

Note that when both host and guest path are identical, you can omit the second one.

You can also mount it as read-only, using --bind-ro. Alternatively, you can use machinectl bind.

Dealing with images

I will end this overview by speaking about images, although reading [the man page][man:systemd-nspawn] of systemd-nspawn would show you a lot more settings.

I did not investigate a lot about images but there seems to be a complete image management available.

systemd-nspawn can take as argument a container images instead of e filesystem directory, using --image (or -i). These images can be for instance simple tarballs, but also docker images, and machinectl can help you pull images with commands such as machinectl pull-tar.

So I have to look further how I can use this power, but it seems that systemd provides us with a simple but powerful containing solution that can be deeply integrated with its other units.

References

HackEns organise des conférences sur les libertés individuelles et Internet !

Cool, rejoint les utilisateurs de !

L'alarmisme de Korben

8 min read

Je réagis ici au dernier article de Kroben sur la stratégie de Samsung en matière d'objets connectés.

Globalement, je suis d'accord avec ce qui y est dit, dans le sens où je m'inquiète également des questions que posent cette sur-connexion à venir de notre quotidien. Mais ce que je trouve malheureux dans cette article, c'est son aspect exclusivement alarmiste.

Mettre en évidence un problème, c'est bien. Ça permet de sensibiliser les gens, et c'est une première étape nécessaire. Mais c'est loin d'être la seule : il y a beaucoup de questions que l'on peut se poser.

On a répondu à « Que ce passe-t-il ? » et « De quel futur sont-ce les prémisses ? ». Qu'en est-il de « Pourquoi en est-on ici ? » ou encore « Comment exploiter à notre avantage cette évolution nécessaire ? », « Que peut-on faire pour ou contre ? », « Quelles sont les différentes réactions que l'on va probablement observer ? ». Et le pluriel est important ici : Korben ne parle que de la réaction ovine probable d'une certaine majorité de gens, mais il s'adresse justement à une autre communauté : celle des hackeurs et activistes.

Il énonce ces fait dans le but de faire réagir, mais ne suggère aucune façon de réagir. C'est dommage. Je suis même attristé de voir des phrases comme celles-ci :

On ne pourra pas y échapper. Et je suis certain qu'on fera les mêmes erreurs qu'on a faites avec Facebook, Gmail, le cloud...

Et quitte à être pessimiste quant à nos chances de changer ces choses, autant relativiser les problèmes que cela pose. Je reprends certains exemples qui ne me semblent pas si dramatiques.

Si votre maison consomme trop, peut être serez-vous plus taxé par le gouvernement. Si votre bracelet connecté montre que vous pétez le feu alors que vous êtes en arrêt maladie, peut être que la SECU viendra vous contrôler.

N'est-ce pas une bonne chose que, par l'intermédiaire de « taxes carbone », l'État incite à l'entretien et au renouvellement des infrastructures du pays ? Son application en devient plus aisée car automatisée, mais l'esprit de la loi reste inchangé. Et n'est-il pas important pour la bonne marche de notre cher système de santé de faire la chasse aux abus ? Que l'on défende ou non ce système n'est pas la question, mais l'outil numérique offre un moyen de le rendre plus cohérent vis à vis de son objectif originel.

Là encore, l'article ne pose pas assez de questions. On peut se demander « Comment la fraude va-t-elle évoluer ? », car elle ne va pas disparaître comme ça. Ou encore « Quels sont les risques de mauvais emploi et d'abus de ces outils, que ce soit par les utilisateurs ou par les institutions ? », puis « Comment les éviter ? ».

Et si l'effet wow a si bien fonctionné lors de la présentation de Samsung, c'est qu'il y a tout de même des aspects souhaitables à cet avenir proposé. Une nouvelle question est donc « Comment obtenir ces mêmes aspects souhaitables sans permettre les mauvais usages crains ? ». On peut se demander « Quelle alternative proposer à ceux qui veulent ces outils ? » et donc « À quel besoin répondent ces produits ? »

Reprenons les exemples :

On peut par exemple supposer qu'une assurance santé vous fasse payer un supplément parce que vous ne faites pas assez de sport.

Est-ce que pousser les gens à faire du sport est un mal en soi ? D'autant plus que c'est une action motivée par la volonté d'améliorer la santé des gens, même si cette volonté est, elle, motivée par les considérations purement financières de boîtes privées.

Ou on peut imaginer une assurance auto qui vous fera cracher plus d'argent parce qu'avant d'avoir eu cet accrochage en voiture, vous avez regardé un film super tard la veille ce qui a joué sur votre capacité d'attention ou tout simplement parce que vous conduisez comme une brute.

Encore une fois, si on nous oblige à être assuré pour rouler, c'est justement pour éviter que les gens roulent mal. Le but profond est préventif. Il ne s'agit pas seulement de permettre d'être remboursé en cas de pépin. Donc oui, je suis pour le fait que les gens conduisant comme des brutes paient plus. Après, ils pèsent le pour et le contre et décident de conduire quand même comme des brutes s'ils le veulent, mais je ne vois pas de problème majeur au fait de vouloir influencer le choix vers une conduite calme.

Peut être que si vous restez trop longtemps sous la douche ou que vous laissez la lumière allumée quand vous n'êtes pas là, vous serez classé dans la catégorie des pollueurs-payeurs et vos impôts augmenteront...

Je ne vais pas refaire le même commentaire que pour les citations précédentes…

Plus subtile :

Ou peut être qu'on vous dira "Non, tu restes chez toi et tu prends le bus suivant car ton travail est moins important que celui des autres gens qui eux doivent arriver à l'heure".

Déjà, l'accès aux transports en commun ne peut pas être uniforme. Les lignes sont tracées par rapport à une certaines demande et certains en sont donc isolés. La position géographique est un critère, alors pourquoi pas un autre ? Ok, le risque là est de discriminer par classe sociale, et je trouve ça plus dangereux, quoi que ça reste un avis très personnel, mais ce n'est pas une nécessité.

D'autre part, j'insiste encore une fois sur le fait que les données sont un outil. Recueillir des données ne peut rien interdire. Ce peut être utilisé pour savoir si la personne fait quelque chose d'interdit, mais pas imposer de contrainte physique, ni changer la nature de ce qui est interdit. Donc si on ne pratique pas ce type de discrimination sociale aujourd'hui, il n'y a pas, a priori, de raison pour qu'on le fasse avec des objets connectés.

En fait, ces mauvais exemples desservent la cause d'origine, noyant les bons exemples.

Peut être que si vous acceptez de vous faire couper automatiquement le courant par EDF lors des pics de consommation, vous serez dans le noir mais vous aurez une réduction sur la facture.

Là c'est plus embêtant, et je suppose que c'est une référence au compteur Linky. Mais ce qui est plus embêtant n'a en fait rien à voir avec le fait d'avoir un compteur connecté. C'est la position de contrôle total dans laquelle se situe E(R)DF qui est en cause et la connexion ou non du compteur n'y change rien. Encore une fois, il serait intéressant de parler des possibles alternatives, de ce que la communauté fait de ces faits. Dans ce cas précis, je pense à CitizenWatt, compteur à la réalisation duquel je participe personnellement, mais je suppose que dans les autres cas on peut également trouver des projets allant dans le sens d'une connexion sans pour autant être accompagné par des situations d'égémonie de certains intérêts privés.

En fait, le seul réel danger mis en avant dans l'article est celui du bubbling. Il faut effectivement, je pense, faire attention à conserver une certaine diversité dans les idées auxquelles nous commes confrontés afins de se faire une opinion suffisemment objective et les mécanismes de suggestion automatique ont des effets pervers de ce point de vue. Mais ce n'est pas le fait de suggérer sur la base de données personnelles qui pose problème. C'est plutôt la façon dont sont faite les suggestions. On peut très bien imaginer un algorithme de suggestion dont le but serait justement de présenter de la façon le plus égale possible les différents point de vue, corrigeant automatiquement les tendances naturelles de l'utilisateur au bubbling.

Bref, au mieux, c'est de la démagogie maladroite ; au pire c'est un manque de combativité un peu décevant.


PS : Je ne savais pas ou le mettre, mais je trouve le climat de diabolisation assez systématique des entreprises et de l'État contestable. Je suis bien d'accord : les intérêts financiers et la centralisation, publique ou privée, posent un nombre incalculable de problèmes. Mais ce sont lesdits problèmes qu'il faut signaler, et non une de leurs causes.

Le problème vient à mon avis du système de permission proposé. Comme l'article le signale, le plus embêtant est que les développeurs piochent dans les permissions juste parce qu'elles sont là, devant eux, et que personne ne regarde s'ils en mangent. Il n'ont donc aucune raison d'avoir des scrupules.

Et si personne ne les regarde, c'est parce que les gens n'ont pas le choix : ou bien ils acceptent toutes les conditions, ou bien ils se privent de l'application. Il n'y a aucun débat, aucune possibilité de compromis.

Ce serait pourtant très simple, techniquement, d'inclure dans le système la possibilité à l'utilisateur de fournir à loisir de fausses données (position approximative, répertoire vide, etc.), lui laissant le choix de sacrifier certaines fonctionnalités de l'application au profit de sa vie priver. Ou plutôt, dans les cas cités ici, de ne rien sacrifier du tout, mais de protéger sa vie privée…

Des nouvelles de Freeder

7 min read

Initialement annoncé par Phyks suite à un état des lieux des lecteurs web de flux existant, il vit une première phase de développement assez rapide consistant à reproduire les fonctionalités de base de tout lecteur de flux qui se respecte : comprendre les formats Atom/RSS, gérer une liste de flux, lire confortablement les articles.

Les trois développeurs — Phyks, tmos et moi-même — utilisaient tous Leed, avec le thème Greeder de tmos et les premiers pas de Freeder sont donc naturellement fait en suivant Leed. Le thème par défaut alors utilisé n'est d'ailleurs autre qu'une version revisitée de Greeder par son auteur.

La répartition des tâches s'est faite assez naturellement : tmos adaptait et faisait évoluer Greeder, Phyks travaillait sur les fonctions les plus algorithmiques ou les plus fondamentales et j'organisais l'ensemble du code et réfléchissait au design du projet. Les frontières n'étaient bien sûr pas hermétiques mais c'était une bonne façon de séparer le travail.

Le projet bénéficie également dès ses débuts de la sympathie et des conseils de Marien Fressinaud, développeur de FreshRSS, nous aidant notamment dans notre recherche d'efficacité en général, point tenant particulièrement à cœur à Phyks.

Le premier objectif, chronologiquement, était d'assurer les fonctions de base afin de pouvoir utiliser Freeder au quotidien pour notre usage personnel. Cet usage personnel est en effet la principale source d'objectifs dans le projet, puisque c'est lui qui révèle les problèmes, les limitations, les manques ressentis.

Il est cependant important de noter que l'un des objectifs phares est de créer un programme accessible à un maximum de personnes, aussi bien à l'usage qu'à l'installation, notamment pour un administrateur débutant ou ne bénéficiant que d'un hébergement limité. Donc bien que le choix des fonctionnalités soient motivés par nos besoins personnels, leur mise en place doit toujours être compatible avec un maximum de configurations.

C'est pour cette raison que le projet utilise PHP et que l'on soigne la procédure d'installation pour la rendre la plus simple possible, bien que nous ne l'exécutions quasiment jamais pour nous. Wordpress est un bon exemple de ce que l'on entend par simple à installer.

C'est ainsi que dans le courant du mois de septembre, nous avons tous les trois migré définitivement vers Freeder. En fait, les deux mois de développement précédents n'ont pas été uniquement consacrés aux fonctions de base, c'est pourquoi lesdites fonctions ont été jugées finies un peu plus tard que prévu. Nous n'avons pas pu nous empêcher — et ce n'est pas une mauvaise chose, si ce n'est pour les gens qui atendent une version étiquetée 1.0 — de commencer en parallèle à penser à la suite.

Cette adoption a été suivie de peu par une stabilisation de la branche master et la migration du développement actif et potentiellement cassant sur la branche dev. À défaut de sortir une version 1.0 que l'on souhaite suffisemment complète, nous souhaitions tout de même pouvoir proposer aux gens nous suivant une version relativement stable et dont la mise à jour serait assurée proprement.

En pratique, on a tout simplement arrêté de développer quoi que ce soit d'autre que des bugs vraiment handicapants sur master. Ce n'était pas un mauvais choix, mais selon moi on ne l'a pas suffisemment suivi : on a continué de travailler exactement comme avant, mais sur la branche dev, avec pour seule conséquence que plus aucune activité ne s'affiche dans les stats de GitHub

Le développement ne s'en est pas moins arrêté, mais était cependant un peu ralenti par la reprise des cours et autres de chacun et consistait principalement à résoudre localement les problèmes que l'on trouvait ou à arrondir les coins en vue de fournir une version, sinon contenant toutes les fonctionalités que l'on ambitionne à terme pour Freeder, n'ayant pas de manque explicite, de lien mort ou autre. Bref, un truc pouvant prétendre être fini.

Une fois encore, nous avons été impatients de nous lancer dans une nouvelle voie, dans un refactoring vers une version 2 avant même d'avoir une version 1. N'ayant que peu d'utilisateurs, nous pouvons nous permettre ce genre de choix et ce serait finalement un frein inutile que de s'interdire d'en profiter.

C'est pourquoi, après avoir créé un nouveau thème alternatif à Greeder, nous travaillons désormais sur une version techniquement très nouvelle, basée sur un modèle Webapp + API.

L'API est indispensable pour pouvoir faire communiquer Freeder avec d'autres programmes. C'est loin d'être suite à une quelconque réaction à un effet de mode que l'on a choisi ce modèle : c'est encore une fois car nos usages ont montré dans le cas de d'autres programmes comme Known, pour n'en citer qu'un, que cet outil de dialogue de programme à programme s'avère très pratique !

Techniquement, nous avons troqué RainTPL, moteur de template très simple qui était jusqu'ici notre seule dépendance, pour un jeu plus étendu de bibliothèques :

  • slim, pour gérer le routage des URLs depuis PHP directement (en non via Apache) et donc les rendre plus dynamique. C'est surtout utilisé pour l'API.

  • Redbean, un ORM en PHP pour bases de données SQL. Il permet de manipuler les objets venant de la base de données directement sous la forme d'objets PHP, ce qui facilite grandement la maintenance du code, au prix de (très lègères) pertes de performances.

    Phyks l'a comparé à FluentPDO, NotORM, Propel et Doctrine. Redbeam a été choisi pour sa souplesse, sa simplicité d'utilisation et la réactivité de son auteur.

  • mf2, pour parser des flux au format h-feed et s'intégrer avec ce que développe IndieWebCamp.

  • zebra_curl, qui permet de faire des requêtes HTTP en parallèle et de manière asynchrone. Il remplace notre wrapper fait maison de cURL. Phyks a aussi testé guzzle mais l'a trouvé surdimensionné pour notre utilisation.

Note de Phyks :

Je ne suis cependant pas satisfait pleinement par zebra_cURL et ça risque d'évoluer dans le futur. L'auteur ne la maintient plus vraiment, et elle ne gère pas tout ce dont on a besoin (par exemple le fallback sur un téléchargement séquentiel, sans cURL, si celui-ci n'est pas activé sur l'hébergement considéré). Un autre grave problème qu'elle a est qu'elle ne gère pas les problèmes de CURL_FOLLOW_LOCATION avec open_basedir activé, cf http://slopjong.de/2012/03/31/curl-follow-locations-with-safe_mode-enabled-or-open_basedir-set/.

On a donc deux choix pour le futur : la forker, ou en prendre une autre. Le code de Known a l'air pas mal sur ce point, à regarder.

Ces briques sont assemblées pour déjà fournir le gros de l'API, et nous allons donc commencer à adapter le thème pour en faire une vraie webapp. Nous ne sommes cependant pas complètement fixé sur la façon de la faire. La question qui se pose en ce moment est de savoir comment servir la webapp. Une page unique contenant absolument toute l'application ? Ça permet une utilisation hors connexion, mais ça rend tout de même le premier chargement lourd. Et une webapp oblige l'usage du JS : on ne peut pas envisager de lire ses flux, même dans une version dégradée, avec links par exemple.

Voilà pour le premier point sur Freeder, je tâcherai d'en faire d'autres régulièrement !

Demander à un ami ou à Wikipedia

2 min read

Il m'arrive souvent de poser spontanément une question — qu'elle soit technique, culturelle ou je-ne-sais quoi d'autre — à un ami, ou plus généralement à un être humain, alors qu'un bon moteur de recherche me répondrait plus vite et plus sûrement.

Assez souvent, la réponse est en fait les résultats de sa propre recherche via un robot, donc ça peut donc sembler assez inutile, mais en y réfléchissant, le moteur de recherche est bien loin de remplacer l'humain dans l'accès à l'information.

Demander à une personne permet de lui indiquer ce sur quoi je suis en train de travailler sur le moment. Cela lui permet de savoir que si un jour il a des questions à ce sujet, je m'y suis intéressé et suis donc suceptible d'amener des réponses plus précises qu'un robot.

Cette personne peut également, en rencontrant par la suite une autre personne posant des questions sur le même sujet, nous mettre en relation. Alors qu'à ma connaissance même Google ne cherche pas à rapprocher les gens dont les recherches sont similaires. Ils auraient pu envisager de le faire avec Google+, mais finalement les gens utilisent ce type de réseau social comme extension de leur vie sociale réelle et non pour y rencontrer de nouvelles personnes.

Et enfin, si la personne connaît vraiment bien le domaine sur lequel porte la question, elle peut donner un exposé bien plus vivant et adapté à la personne à laquelle elle le fait que celui d'un page Wikipedia. Là encore, les robots ne le font pas, mais ils pourraient. Il serait intéressant de voir un robot qui explique de façon intéractive un sujet. Ou même un robot qui débat d'un sujet, prenant une position partiale opposée à celle qu'il sait être celle de son interlocuteur.

L'accès à l'information reste donc très humain, d'autant plus que les moteurs de recherche mênent toujours vers des textes écrits par des doigts sur un clavier. On commence cependant à voir des initiatives apparaître, comme Echo (développé par HP Labs) qui peuvent extraire les idées d'un corpus de texte, mais aussi le sentiment de leurs rédacteurs, et ça fait un certain temps que les gens s'échinent à coder des chatbots.

Google se rend petit à petit incontournable avec beaucoup de flegme : Il a besoin du reste du web pour créer du contenu, ce qu'il ne sait pas faire (contrairement à Facebook ou Twitter), mais aimerait que tout soit faisable sans sortir de chez lui…

Importance du contenu dans une interface — Gnome HIG

2 min read

Applications typically present content, whether it is images, text, messages or more complex data. It is this content that your users will be interested in, and too many controls or user interface elements will distract from the focus of their attention.

Ce point des recommandations ergonomiques de Gnome insiste sur le fait que l'élément central d'un programme est le contenu manipulé.

Si dans le cadre du design de page web il est assez clair que le point clef est le contenu, et donc le confort de « lecture » (de texte, d'image, etc.) — expliquant la mode des styles très épurés — c'est moins évident pour les programmes en général.

La force initiale de l'informatique réside dans sa capacité de calcul. A priori, rien ne dit donc qu'un programme doit être centré sur du contenu. Au contraire même, on pourrait voir le contenu comme un exemple, un simple cas particulier de ce que le programme et sa troupe d'algorithmes peuvent faire, et focaliser l'attention de l'utilisateur sur toutes les compétences générales de la machine.

Du point de vue du développeur, la généralité des algorithmes est effetcivement un point capital : ne sachant à quel contenu il sera appliqué, il doit prévoir tous les cas. Chaque fonctionnalités est une nouvelle œuvre et mérite sa place dans les rayonnages de l'interface avec l'utilisateur.

Sauf que l'utilisateur se fiche du cas général. Pour l'utilisateur, le programme est un outil. Il ne l'utilise que dans le but de traiter un certain contenu, que ce soit pour le lire, le construire, l'altérer, le dupliquer, etc. L'utilisateur peut changer de programme, mais pas changer de contenu.

Ce qu'il faut montrer à l'utlisateur, c'est en priorité ce qu'il est en train de manipuler, et non ce avec quoi il est en train de le manipuler.