En ce moment, les billets fusent à propos des DRM dans Firefox et l’idée "d’être ou ne pas être (extrémiste), telle est la question", ou encore soyons barbus et fiers de l’être (si vous sortez de coma, allez faire un tour entre-autres sur les blogs de Cyrille, Fred, Damien et antistress).
Regarder passer les balles en comptant les points est d’actualité en cette période de Roland Garros mais comme ça fait quelques années que je ne suis plus cet événement, je vais tenter une petite balle aussi (à défaut de balles neuves ou d’ace, j’espère quand même éviter le filet, encore qu’on est sur le net).

Concernant Firefox, tous les camps ont des points gagnants et, je ne sais plus où, j’ai entendu que de toutes façons, Mozilla est perdant qu’il choisisse ou pas d’implémenter les DRM.
J’ai trouvé le billet de Cyrille très pertinent et j’irai même plus loin.

Mozilla invoque le fait que s’ils ne suivent pas le mouvement, ils seront laissés de côté par les utilisateurs. Mais en fait, ils n’ont aucune marge de manœuvre, ils doivent garder à tout prix des utilisateurs pour justifier l’aumône accordée par Google qui leur a permis de se développer mais qui est leur seul moyen de subsister. Ils ne nous ont pas encore fait de chantage à l’emploi mais ça viendra peut-être. Difficile de dépendre d’un acteur tout puissant à qui il ne faut pas déplaire (d’autant qu’il n’a plus besoin de vous pour asseoir cette toute puissance). Mais c’était aussi un merveilleux moyen d’avoir des fonds sans dépendre de la générosité des utilisateurs. Bref, le business model de Mozilla n’est pas le sujet mais il risque de l’être dans un avenir plus ou moins éloigné (espérons que FirefoxOS permette un autre essor).

Sur l’aspect, soyons libristes mais pas trop quand même, je n’ai pas l’impression qu’être extrémiste puisse nuire à quelqu’un ; RMS n’a jamais nuit aux logiciels libres et c’est en partie grâce à lui si on a aujourd’hui la possibilité d’avoir des machines qui tournent sans logiciels propriétaires. Des moins acharnés que lui ont aussi permis d’intégrer des bouts de propriétaire afin de pallier aux manques ou baisses de performances (uniquement dû au fait que le matériel ou certaines technologies sont totalement fermés). De ce fait, libre à chacun soit d’avoir une machine entièrement libre (faut quand même bien choisir son matos) mais qui ne pourra pas forcément accéder à tous les contenus et avoir des performances optimales, soit de ménager la chèvre et le chou en intégrant le minimum vital tant qu’il n’y a pas d’alternative libre (personnellement, ce sont les drivers d’imprimante et flash pour pouvoir accéder correctement aux contenus multimédia). Libre aussi si je le souhaite de ne pas lésiner sur les programmes proprio si je trouve que GNU/Linux est plus polyvalent, moins troué, moins cher, plus paramétrable, plus performant, etc. que Windows et que je veux tuer des gros méchants sur Steam avec ma carte graphique nVidia et ses drivers proprio.

Maintenant, est-ce être extrémiste de blâmer Mozilla d’intégrer les DRM ?
Certains bottent en touche en disant que de toutes façons le ver était dans la pomme à partir du moment où le W3C avait donné son accord, certes.
Personnellement, je pense qu’effectivement, ils ne peuvent faire autrement mais que cela donnera lieu à une sévère désapprobation des fidèles les plus engagés (d’où forks probables).

Alors que devrait faire Mozilla ?
C’est pourtant simple : proposer une version de base sans support de DRM et un add-on permettant de les lire.
Comme ça tout le monde est content et ceux qui ont besoin des DRM pour regarder des trucs menottés (Game of Thrones semble être l’alibi ultime) pourront installer l’add-on comme moi j’installe Flash en attendant que l’HTML5 ou Gnash permettent réellement de m’en passer.
C’est un pis-aller mais cela n’empêche pas ceux qui n’en veulent pas d’avoir un système sans verrue ni ceux qui veulent en profiter de pouvoir l’utiliser (et même de changer d’avis régulièrement).
Car une implémentation d’office est une porte ouverte à d’autres blobs, que cela va occasionner une perte d’utilisateurs non négligeable (soit pour utiliser un truc vraiment libre, soit parce que tant qu’à faire autant utiliser Chrom*) et que plus jamais Mozilla ne pourra nous dire que la protection de notre vie privée est une priorité car le machin implémenté sera potentiellement probablement ouvert à la NSA (Adobe est une société américaine).

Si vous êtes d’accord avec moi, peut-être qu’il faudra convaincre Tristan de ce genre de possibilité...

Original post of alterlibriste.Votez pour ce billet sur Planet Libre.

Comme l'année dernière, je serais présent les trois prochains jours au #SSTIC (Symposium sur le Sécurité des Technologies de l'Information et de la Communication) à Rennes !

J'essaierais de live-tweeter au maximum et de publier des articles récapitulatifs pour chacune des trois journées :)

Liens directs

• Jour 1
• Jour 2
• Jour 3
• Article de fin

Pour les lecteurs du Planet-Libre, je rappelle que cet article et les suivants qui concerneront le SSTIC ne sont pas vraiment dans l'optique du libre, mais je pense qu'ils peuvent être intéressants pour avoir accès à un retour sur ce genre de manifestation.

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Dans le petit monde des DevOps, la solution de virtualisation Docker a le vent en poupe. Nous allons dans ce billet essayer de décrypter ce qui ce cache derrière ce nouvel outil et proposer un tutoriel sur l'installation et les premiers pas pour une utilisation souple et efficace.

C'est quoi donc ?

Docker est un logiciel open-source (sous licence Apache 2.0) et un service en ligne optionnel (Docker.io) permettant de gérer des conteneurs ("dockers").

Contrairement aux machines virtuelles classiques qui comprennent un système hôte ("guest OS") et les librairies/applications, les conteneurs ne contiennent, au maximum, que les applications/librairies.

Quand je dis au maximum c'est qu'une copie d'un conteneur qui ne change que la partie application ne contiendra que les différences par rapport au conteneur initial.

Le système hôte est ainsi géré directement par le Docker Engine (en vert dans le premier schéma). On a ainsi une mutualisation qui permet de lancer les conteneurs de manière très rapide: le temps de lancement d'un conteneur est presque le même que le temps de lancement des applications qu'il contient. En effet, le système d'exploitation est déjà lancé. Donc pas de phase de démarrage ni d'initialisation de cette couche. Il faut quand même avoir à l'esprit que même si l'on est pas dans une machine virtuelle, on dispose tout de même d'un environnement isolé (processus, système de fichier, ports réseau). L'utilisateur n'a qu'à se préoccuper que de ce qu'il veut virtualiser (les applications/services) et ne s'occupe pas du reste.

L'autre gros avantage de cette technologie est la portabilité. En effet, il est tout à fait possible de concevoir un conteneur sur son PC portable puis ensuite de le déployer sur son infrastructure de production physique ou virtuelle. La taille des conteneurs étant relativement réduite, on peut donc imaginer un workflow de déploiement basée sur un repo central (type Git) et des Docker Engine installés sur les machines qui font elle même tourner des conteneurs. Il n'y a pas vraiment de limite au nombre de conteneurs qu'une machine puisse faire tourner. La limite vient de l'occupation mémoire/CPU/réseau de vos applications.

Si vous avez encore des questions sur la différence entre Docker et VM, je vous conseille la lecture de cette question sur StackOverflow: "How is Docker.io different from a normal virtual-machine ?".

Installation de Docker

Note (merci à @jb_barth pour le commentaire): jusqu'à la version 0.9, Docker se basait sur la technologie LXC ("Linux Containers") du noyau Linux et ne fonctionnait donc que sur des distributions GNU/Linux avec un noyau >= 2.6.24. La dépendance stricte à LXC a sauté depuis la v0.9.0, le driver par défaut est maintenant libcontainer, une lib pur go produite par le projet pour accéder de façon propre aux APIs dispos dans le kernel. C'est ce qui a permis de supporter des noyaux aussi vieux d'ailleurs, au début c'était >= 3.8

Voici les étapes à suivre pour installer Docker sur une distribution Ubuntu 14.04 LTS. A noter, pour les miséreux développeurs sous Windows ou Mac OS, il est est toujours possible de faire tourner une VM Ubuntu (par exemple avec VirtualBox) et de suivre cette installation.

Docker est directement disponible dans les repositories d'Ubuntu, donc un simple

sudo apt-get install docker.io

suffit pour effectuer l'installation complète de Docker sur notre machine comprenant:

• le Docker Engine (ou service Docker)
• le Docker Client (permettant de discuter avec le Docker Engine)

Comme les conteneurs vont utiliser les serveurs DNS de la machine hôte, il est nécessaire de configurer les adresses des serveurs DNS dans le fichier /etc/default/docker.io (par exemple avec les serveurs OpenDNS):

$ vi /etc/default/docker.io
# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="-dns 208.67.220.220 -dns 208.67.220.222"

Pour que la configuration soit prise en compte, il faut relancer le service Docker avec la commande:

sudo service docker.io restart

Un petit ps permet de voir que le service est bien lancé:

0.0   0.1  563M 9.65M   733 root         0 S  0:00.46     0     0 /usr/bin/docker.io -d -dns 208.67.220.220 -dns 208.67.220.222

Récupération des images système

Nous allons commencer par récupérer des images qui vont servir de de bases à notre conteneur. Une liste assez conséquente d'images sont disponibles sur le site officiel du projet. Vous pouvez ainsi récupérer celle qui est le plus proche de l'environnement que vous recherché. Un moteur de recherche est disponible à l'adresse https://index.docker.io/ pour trouver des images conçues par les développeurs du projet et par des contributeurs.

On retrouve ainsi des distributions GNU/Linux minimales comme Ubuntu, CentOS, BusyBox pour ne siter que les images officiellement supportées par le projet Docker.io (il existe également des repos non officiels avec Fedora, RH, Arch...).

Petit mention spéciale pour les images BusyBox qui sont vraiment très légère (moins de 10 Mo) pour un système fonctionnel !

Même si il est possible de directement télécharger l'image au lancement du conteneur, je préfère avoir sur ma machine les images des différentes versions de l'OS que j'utilise le plus: Ubuntu.

Pour récupérer l'ensemble des images du repo Ubuntu qui contient les versio  minimale d'Ubuntu de la version 10.04 à 14.04), il faut saisir la commande suivante:

$ sudo docker.io pull ubuntu
74fe38d11401: Pulling dependent layers
316b678ddf48: Pulling dependent layers
3db9c44f4520: Pulling dependent layers
5e019ab7bf6d: Pulling dependent layers
99ec81b80c55: Pulling dependent layers
a7cf8ae4e998: Pulling dependent layers
511136ea3c5a: Download complete
e2aa6665d371: Downloading [==>                                                ] 2.027 MB/40.16 MB 6m14s

Note: le téléchargement initial des images peut prendre un peu de temps selon la vitesse de votre liaison Internet.

Il est également possible de faire de même avec les autres distributions citées ci-dessus:

$ sudo docker.io pull centos
$ sudo docker.io pull busybox

Une fois le téléchargement terminé, on peut demandé à Docker un status de son état actuel:

$ sudo docker.io info
Containers: 64
Images: 46
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 174
Execution Driver: native-0.1
Kernel Version: 3.13.0-24-generic
WARNING: No swap limit support

ainsi que la liste des images disponibles:

$ sudo docker.io images
REPOSITORY          TAG                   IMAGE ID            CREATED             VIRTUAL SIZE
busybox             buildroot-2013.08.1   352f47ad2ecf        17 hours ago        2.489 MB
busybox             ubuntu-14.04          6a95c08a9391        17 hours ago        5.609 MB
busybox             ubuntu-12.04          1720a1681f1c        17 hours ago        5.455 MB
busybox             buildroot-2014.02     f66342b343ae        17 hours ago        2.433 MB
busybox             latest                f66342b343ae        17 hours ago        2.433 MB
ubuntu              glances_develop       a483f92d9ab3        24 hours ago        556.8 MB
ubuntu              14.04_nicolargo       8574cc29575e        28 hours ago        440.8 MB
ubuntu              13.10                 5e019ab7bf6d        4 weeks ago         180 MB
ubuntu              saucy                 5e019ab7bf6d        4 weeks ago         180 MB
ubuntu              12.04                 74fe38d11401        4 weeks ago         209.6 MB
ubuntu              precise               74fe38d11401        4 weeks ago         209.6 MB
ubuntu              12.10                 a7cf8ae4e998        4 weeks ago         171.3 MB
ubuntu              quantal               a7cf8ae4e998        4 weeks ago         171.3 MB
ubuntu              14.04                 99ec81b80c55        4 weeks ago         266 MB
ubuntu              latest                99ec81b80c55        4 weeks ago         266 MB
ubuntu              trusty                99ec81b80c55        4 weeks ago         266 MB
ubuntu              13.04                 316b678ddf48        4 weeks ago         169.4 MB
ubuntu              raring                316b678ddf48        4 weeks ago         169.4 MB
ubuntu              lucid                 3db9c44f4520        5 weeks ago         183 MB
ubuntu              10.04                 3db9c44f4520        5 weeks ago         183 MB
centos              centos6               0b443ba03958        6 weeks ago         297.6 MB
centos              6.4                   539c0211cd76        14 months ago       300.6 MB
centos              latest                539c0211cd76        14 months ago       300.6 MB

Comme alternative du moteur de recherche https://index.docker.io/, il est bien sûr possible d'utiliser la ligne de commande. Par exemple pour trouver toutes les images Ubuntu disponibles sur le repo central:

sudo docker.io search ubuntu | less

A noter qu'il est tout à fait possible, si vous ne trouvez pas votre bonheur de concevoir "from scratch" votre propre image système en suivant cette documentation sur le site officiel (la procédure se base sur DebootStrap).

Création de son premier conteneur

Bon assez de préliminaires, nous allons maintenant pourvoir créer notre premier conteneur qui va se limiter à exécuter la commande 'ls' (si c'est pas du conteneur de compétition):

$ sudo docker.io run ubuntu:latest /bin/ls -alF
total 8280
drwxr-xr-x  46 root root    4096 May 28 06:50 ./
drwxr-xr-x  46 root root    4096 May 28 06:50 ../
-rw-r--r--   1 root root     102 May 28 06:50 .dockerenv
-rwx------   1 root root 8394118 May 27 15:37 .dockerinit*
drwxr-xr-x   2 root root    4096 Apr 16 20:36 bin/
drwxr-xr-x   2 root root    4096 Apr 10 22:12 boot/
drwxr-xr-x   4 root root    4096 May 28 06:50 dev/
drwxr-xr-x  64 root root    4096 May 28 06:50 etc/
drwxr-xr-x   2 root root    4096 Apr 10 22:12 home/
drwxr-xr-x  12 root root    4096 Apr 16 20:36 lib/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 lib64/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 media/
drwxr-xr-x   2 root root    4096 Apr 10 22:12 mnt/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 opt/
dr-xr-xr-x 236 root root       0 May 28 06:50 proc/
drwx------   2 root root    4096 Apr 16 20:36 root/
drwxr-xr-x   7 root root    4096 Apr 16 20:36 run/
drwxr-xr-x   2 root root    4096 Apr 24 16:17 sbin/
drwxr-xr-x   2 root root    4096 Apr 16 20:35 srv/
dr-xr-xr-x  13 root root       0 May 28 06:50 sys/
drwxrwxrwt   2 root root    4096 Apr 24 16:17 tmp/
drwxr-xr-x  11 root root    4096 Apr 16 20:35 usr/
drwxr-xr-x  14 root root    4096 Apr 16 20:36 var/

Arrêtons-nous un peu sur la commande: sudo docker.io run ubuntu:latest /bin/ls -alF

On demande donc le lancement (run) d'un conteneur basée sur la dernière version d'Ubuntu (ubuntu:latest qui est un lien vers l'image minimale de la version 14.04) qui va exécuter la commande ls (/bin/ls -alF). Comme vous pouvez le voir dans le résultat de la commande, on est dans un environnement isolé avec son propre système de fichier.

Première constatation, la vitesse d’exécution de notre environnement virtuel est vraiment impressionnante. Sur une petit commande,on peut voir que l'overhead de lancement du conteneur est négligeable:

$ time sudo docker.io run ubuntu:latest ls -alF /
...
real	0m0.331s
user	0m0.014s
sys	0m0.012s
$ time ls -alF /
...
real	0m0.007s
user	0m0.003s
sys	0m0.004s

Puis un conteneur persistant

Passons maintenant à la création d'un conteneur persistant, c'est à dire un conteneur  qui va faire tourner une tache pendant un temps indéterminé (je prends par exemple un pin infini vers le site Google).

$ sudo docker.io run -d ubuntu:latest ping www.google.fr
7404bfa4beca4ba97459c96f8d93242c4fba6ecf2c5b11d18c09acd2fce9991e

Noter le -d dans la ligne de commande pour détacher le conteneur et ainsi lui permettre de tourner en tache de fond.

En retour on obtient le numéro d'identifiant unique du conteneur qui va nous permettre de le contrôler.

On commence donc par vérifier qu'il tourne bien:

$ sudo docker.io ps
CONTAINER ID        IMAGE               COMMAND              CREATED             STATUS              PORTS               NAMES
7404bfa4beca        ubuntu:14.04        ping www.google.fr   3 minutes ago       Up 3 minutes                            mad_lumiere

On peut ainsi, l'arrêter:

sudo docker.io stop 7404bfa4beca

Le démarrer:

sudo docker.io start 7404bfa4beca

Le redémarrer (l'équivalent d'un stop/start):

sudo docker.io restart 7404bfa4beca

Lui envoyer des signaux:

sudo docker.io kill 7404bfa4beca

Ensute on supprime le conteneur avec la séquence stop/rm:

sudo docker.io stop 7404bfa4beca
sudo docker.io rm 7404bfa4beca

Un Shell dans un conteneur

Pour accéder à un shell dans le conteneur, il faut utiliser les options suivantes dans la ligne de commande:

• -t: Allocate a pseudo-tty
• -i: Keep STDIN open even if not attached

$ sudo docker.io run -i -t ubuntu:latest bash
root@bb89ed6cdd3c:/#

Structurer la création des conteneurs avec les Dockerfiles

Les Dockerfiles sont des fichiers textes décrivant les différentes étapes pour la création d'un conteneur. Idéalement, ce sont ces fichiers que vous aller gérer en configuration et que vous aller partager avec les différentes personnes utilisatrices de votre projet. Pour illustrer mes dires, je vais prendre l'exemple d'un dockerfile qui va permettre aux contributeurs du projet Glances de tester simplement la branche de développement du logiciel.

En gros, le dockfile doit:

1. utiliser un OS de base (Ubuntu 14.04 LTS)
2. installer les pré-requis système
3. télécharger la dernière version de Glances sous Github

Le dockfile glances_develop_install correspondant est alors le suivant:

# Install Glances Development branch
#
# $ sudo docker.io build -t ubuntu:glances_develop - < glances_develop_install
#
# VERSION 1.0
# Use the ubuntu base image provided by dotCloud
FROM ubuntu
MAINTAINER Nicolargo, nicolas@nicolargo.com
# Make sure the package repository is up to date
RUN apt-get -y update
# Install prerequirement
RUN apt-get install -y python-dev python-pip git lm-sensors
RUN pip install psutil bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz
# Patch for current Docker version
RUN ln -s /proc/mounts /etc/mtab
# Install Glances from the Pipy repository
RUN git clone -b develop https://github.com/nicolargo/glances.git

Voyons un peu en détail le contenu du fichier.  On commence donc par définir l'OS de base:

FROM ubuntu

On peut bien sûr utiliser l'image/tag que l'on souhaite.

Ensuite on passe aux commandes que l'on souhaite exécuter:

RUN apt-get -y update

RUN apt-get install -y python-dev python-pip git lm-sensors

RUN pip install psutil bottle batinfo https://bitbucket.org/gleb_zhulik/py3sensors/get/tip.tar.gz

RUN ln -s /proc/mounts /etc/mtab

RUN git clone -b develop https://github.com/nicolargo/glances.git

Rien de bien compliqué, il suffit de faire précéder la commande Unix par le mot clé RUN...

Il ne reste plus qu'à lancer la construction du conteneur et son exportation vers une nouvelle image (nommé ubuntu:glances_develop) à partir de la ligne de commande:

sudo docker.io build -t ubuntu:glances_develop - < glances_develop_install

ou alors directement depuis un repos (par exemple GitHub) ou vos Dockers files sont gérés en configuration:

sudo docker.io build -t ubuntu:glances_develop https://raw.githubusercontent.com/nicolargo/dockersfiles/master/glances_develop_install

On vérifie ensuite que l'image a bien été créée:

$ sudo docker.io images | grep glances
ubuntu glances_develop a483f92d9ab3 31 hours ago 556.8 MB

Puis on lance Glances depuis ce conteneur (en le metant à jour par un pull avant le lancement):

sudo docker.io run -i -t --entrypoint /bin/bash ubuntu:glances_develop -c "cd glances ; git pull origin develop ; python -m glances"

Et hop c'est magique:

Un des trucs fun avec Docker c'est que si l'on souhaite modifier un conteneur en ajoutant par exemple l'installation d'un nouveau logiciel, il suffit de modifier le Docker file puis de refaire la commande de build. L'installation ne se fera que par delta par rapport au premier conteneur.

Controler la CPU et la mémoire de ses conteneurs

Une fonction intéressante de Docker est sa capacité de contraindre un conteneur en terme de CPU et de MEM. Par exemple on peut limiter le conteneur à 512 Mo de RAM et donner un priorité moins forte en terme de CPU à ce conteneur par rapport aux autres. Il faut cependant que le hôte qu héberge Docker soit compatible avec ces options ce qui n'est pas mon cas:

$ sudo docker.io run -m 512m -i -t --entrypoint /bin/bash ubuntu:glances_develop -c "cd glances ; git pull origin develop ; python -m glances"
WARNING: Your kernel does not support swap limit capabilities. Limitation discarded.

Pour activer ces options sous Ubuntu, il faut modifier la configuration du Kernel via GRUB. Pour cela, il est nécessaire de suivre cette procédure.

Conclusion

L'approche est vraiment différente des solutions de virtualisation classiques mais si vous cherchez un outil simple pour valider vos applications Linux dans un environnement controlé alors Docker est définitivement une solution à envisager. Sa souplesse et sa légéreté en font une solution idéale à embarquer sur son PC portable ou à mettre en production sur son infrastructure.

Je vous conseille de vous plonger dans la documentation officielle qui est vraiment complète et très bien faite.

Des expériences à nous faire partager sur l'utilisation de Docker ?

Quelques références:

• https://www.docker.io/
• http://docs.docker.io/reference/commandline/cli/
• http://sametmax.com/le-deploiement-par-conteneurs-avec-docker/

Cet article Virtualisation légère avec Docker est apparu en premier sur Le blog de NicoLargo.

Original post of Nicolargo.Votez pour ce billet sur Planet Libre.

Etre en faveur du logiciel libre, militer en faveur d’un micro parti politique ou contre un projet de traité économique international, voila mes occupations du moment.

Je me sens un peu en bordure, a l’écart, par moment. Je remets souvent en question mes prises de position. Malgré mon assurance et les arguments que je déploie, je continue mon questionnement : a quoi bon tout ça ? Suis-je dans le vrai ou dans le faux ? C’est comme cela que je pourrais résumer mes doutes.

Pourquoi se prendre la tete ? Je pourrais faire du Gmail avec un pc sous Windows. Plutôt que de militer, je pourrais rester tranquillement devant la télé et me plaindre « tous pourris » et laisser passer des lois qui changeront radicalement ma vie, sans rien faire, parce que je peux me dire « qu’au final, ça ne changera rien ».

Alors dans ces moments la, je me tourne vers des sources d’informations et d’idées que j’apprécie. En l’occurrence, je suis tombé sur deux billets de blog qui ont permis de mettre les choses au clair.

Je vous conseille donc la lecture du billet Libère l’intégriste qu’il y a en toi ! de Cyrille Borne et Google, Apple, Facebook et Amazon : allez tous vous faire foutre d’Antistress.

Le billet de Cyrille est clair : il faut s’assumer comme barbus, utilisateurs de logiciels libres, proposant un modèle numerique alternatif, il faut y aller franco. Regroupons nous et allons y fièrement.

Le billet d’Antistress nous parle de la nécessité de changer nos habitudes, numériques mais aussi dans notre manière de consommer au quotidien. Pour lui, le danger qui nous guette est le monopole. Je le rejoins pleinement dans ce message.

Fuir Google permet de se protéger mais également de protéger des modèles émergents : regardez combien de start-ups ou nouvelles entreprises, Google, Facebook & co ont racheté ces dernières années. Ce sont autant d’acteurs permettant la libre-concurrence qui ont disparu, amalgamés a la nouvelle maison-mère, voir directement fermés pour certains d’entre eux !

Imaginez-vous manger la même nourriture tous les jours ?

Imaginez-vous porter les mêmes vêtements tous les jours ?

Imaginez-vous voter pour le même parti politique ?

Vous avez votre mot a dire a tous les niveaux. Si vous n’avez pas envie de vous engager en politique ou d’agir bénévolement dans une association ou un collectif, sachez que vos simples choix d’achat et de consommation sont un acte de militantisme : choisir le plus gros, c’est faire le choix du monopole. Et le monopole n’a qu’un but : se maintenir au-dessus des autres, par tous les moyens, y compris les plus radicaux (démantèlement, fermeture, destruction, achat de brevet pour interdire la concurrence…).

Entretenir le monopole, c’est restreindre son choix présent mais c’est surtout restreindre son futur en ne se donnant aucune marge de manœuvre pour changer les choses.

Etre un barbu, anti-google ou anti-microsoft, avec un discours musclé, voir virulent par moment, c’est un choix présent difficile, mais c’est pour laisser la possibilité a d’autres d’émerger plus tard car personne ne sait comment les GAFA vont évoluer.

Edit du mardi 2 juin : Google, Facebook et Amazon sont-ils en train de nous construire un monde invivable à grands coups de monopoles et d’algorithmes ? Ca n’est pas moi qui le dis, je ne serais donc pas tant parano que ca, hein. A bon entendeur, salut.

_ Damien

partager sur Diaspora*

Original post of Damien.Votez pour ce billet sur Planet Libre.

Nous avons déjà vu comment gérer des shortcodes sous WordPress pour faciliter l’insertion de certains contenus récurrents dans vos pages ou articles. Nos shortcodes utilisaient jusque-là différents attributs qui pouvaient d’ailleurs aussi être sans nom comme on l’a vu la dernière fois. Mais vous pensiez réellement qu’on avait fait le tour de l’API ? En réalité il nous faut encore voir quelques détails pour être sûrs d’avoir vu tout ce dont nous avons besoin, et c’est justement ce qu’on va faire ici.

Du contenu dans nos shortcodes

Si vous êtes familier de WordPress, vous avez sûrement déjà croisé des shortcodes comme on en crée depuis les premières parties, mais pas seulement. Car un shortcode peut posséder une autre forme que celle utilisée jusque maintenant, une forme qui rappelle un peu les balises HTML : [shortcode]contenu[/shortcode].

Plutôt que de n’utiliser qu’une forme simple comme on le fait depuis le début, on peut en effet choisir d’utiliser une forme ouvrante / fermante. Ça a plusieurs avantages et inconvénients, et il vous revient de faire la part des choses pour savoir quelle solution vous conviendra le mieux.

Quoiqu’il en soit, gérer du contenu est d’une simplicité enfantine, tellement que c’en est presque risible de l’aborder : il suffit en effet de modifier notre fonction de callback, celle qui est appelée chaque fois que WordPress trouve l’un de nos shortcodes. Cette fonction peut en effet supporter un deuxième attribut qui contiendra justement le contenu envoyé. Peut-on seulement faire plus simple ?

function transformer_hello($atts, $contenu) {
	return 'Hello World! ' . $contenu;
}
?>

Dans cet exemple tiré de la première partie, nous modifions ce qui sera affiché en concaténant simplement le contenu du shortcode à « Hello World!« . Ainsi, si l’utilisateur envoie [hello]toto[/hello], alors le shortcode affichera automatiquement « Hello World! toto« .

C’est tout ce qu’il y a à savoir sur la gestion d’un contenu dans les shortcodes. Le détail intéressant, c’est que vous pouvez bien sûr utiliser du contenu et des attributs, afin de créer un shortcode des plus puissants. Et ça c’est cool.

Plusieurs shortcodes pour une même fonction de callback

Nous arrivons ici dans une situation qui pourrait paraître plus délicate, à savoir la gestion de plusieurs shortcodes dans une seule et unique fonction de callback. C’est effectivement possible et peut être utile si plusieurs shortcodes font presque la même chose par exemple. Mais c’est très loin d’être insurmontable à gérer.

Imaginons deux shortcodes [hello] et [plop] (admirez l’imagination dans ces noms, c’est tout simplement remarquable) et faisons en sorte que ce soit la même fonction qui soit appelée :

add_shortcode('hello', 'gerer_shortcode');
add_shortcode('plop', 'gerer_shortcode');
?>

Si on ne fait rien de plus, nos deux shortcodes seront exactement les mêmes, ce qui est un peu inutile. C’est pourquoi il existe un troisième (et dernier, enfin pour l’instant) argument possible pour les fonctions de callback : le nom du shortcode.

Dans l’appel de add_shortcode(), nous n’avons rien à faire, tout change dans la fonction de callback en question, où vous devez ajouter un troisième paramètre :

function transformer_hello($atts, $contenu, $tag) {
	return 'Hello World! ' . $contenu;
}
?>

Et c’est à peu près tout en fait. Le paramètre $tag contiendra le nom du shortcode choisi par l’utilisateur et vaudra dans notre cas « hello » ou « plop« . La suite dépend donc de vous et de la différence que vous voulez donner aux shortcodes.

À noter que le WordPress Codex référence un comportement étrange lorsqu’on gère plusieurs noms. Selon cette page, si deux shortcodes utilisent la même fonction de callback et que le nom du shortcode diffère de celui de la fonction, alors l’entrée 0 de l’argument $atts vaudra la chaîne de caractère repérée par WordPress, c’est-à-dire tout le shortcode envoyé par l’utilisateur. Je n’ai cependant pas réussi à reproduire ce comportement et il semblerait donc qu’il ait été corrigé depuis. Quoiqu’il en soit, il ne vous affectera que si vous devez gérer des attributs sans nom.

Un shortcode dans un shortcode dans un shortcode…

… dans un shortcode. Vous l’aurez compris, nous allons aborder ici la question de shortcodes imbriqués, qui ne se pose que si vous gérez du contenu pour vos shortcodes. Un exemple ? Prenons deux shortcodes, dont notre bon vieux [hello] accompagné d’un shortcode [monde] qui affiche le mot « monde« . Parce que faire compliqué ne sert à rien.

Modifions notre shortcode [hello] qui ne dira plus que « Hello contenu!« , désormais, avec « contenu » remplacé par le contenu du shortcode. Notre shortcode [monde], lui, affichera simplement le mot « monde » là où il est. Je pense qu’il est inutile de vous montrer comment faire ces choses-là…

Si l’utilisateur écrit « [hello]World[/hello] [monde]« , tout va bien, nous afficherons « Hello World! monde » et c’est tout. C’est con, ça sert à rien, mais on s’en fout. Imaginons plutôt que l’utilisateur choisisse d’écrire « [hello]le [monde][/hello]« . Là, tout va mal.

WordPress ne fait qu’un seul tour pour gérer les shortcodes, et indiquer la chaîne précédente produira donc le résultat « Hello le [monde]! » : le shortcode [monde] n’a tout simplement pas été interprété !

Bien sûr, peut-être ne voudrez-vous pas qu’ils le soient justement. Mais selon les besoins, c’est un peu ennuyeux. Heureusement, WordPress a pensé à tout et nous fournit la fonction qu’il nous faut : do_shortcode().

Cette fonction s’utilise de façon très simple, en indiquant en paramètre la chaîne que WordPress doit traiter, celle où il faut éventuellement aller chercher des shortcodes. Aussi, nous pourrions l’utiliser comme ceci dans notre cas :

function hello($atts, $contenu) {
	return 'Hello ' . do_shortcode($contenu) . '!';
}
?>

Et là, tout va bien : utiliser la chaîne qui posait problème jusque maintenant produira le résultat « Hello le monde!« , exactement comme on le souhaitait.

A-t-on vraiment fait le tour ce coup-ci ?

Pas vraiment. En fait, il reste encore toute une multitude de petits détails que je n’ai pas abordé. Cependant, ce sont vraiment de tout petits détails qui ne nécessitent guère d’explications et je vous laisse donc vous débrouiller seul pour ceux-ci. Bien sûr, n’hésitez pas à laisser un commentaire si jamais vous avez des questions concernant un détail à rajouter, ou si vous avez une idée de comportement qui nécessiterait un tutoriel entier.

Avec tout ce que nous avons vu, vous êtes normalement capable de créer des shortcodes très puissants. Pensez-y un peu, l’espace d’un instant : nous pouvons créer des shortcodes simples, sans aucun paramètre à indiquer, ou nous pouvons gérer des attributs plus complexes, avec du contenu et des attributs, avec ou sans nom.

Notez pour finir que vous pouvez bien sûr mixer les shortcodes avec des boutons, nous avons déjà vu comment insérer du contenu dans les éditeurs de WordPress. D’ailleurs, pour ceux qui se posent la question, c’est exactement ce qui est fait pour WP Photo Sphere : le bouton média « Ajouter un panorama » permet de sélectionner un panorama, inséré sous forme de shortcode lui-même géré par l’API de WordPress. Comme quoi, on peut en faire des choses.

Original post of Tasse de Café.Votez pour ce billet sur Planet Libre.