Dans le précédent billet, j'ai tenté d’analyser la situation à laquelle la fondation Mozilla est actuellement confrontée.

J'en ai conclu que le rapport de force actuel, très favorable à Google, empêche la fondation à l'origine de Firefox de réaliser ses objectifs. J'ai proposé des pistes pour permettre de rééquilibrer le jeu en faveur de l'utilisateur et de l'innovation. Celles-ci dépendent de chacun de nous : utiliser et promouvoir Firefox (versions pour micro-ordinateurs ou pour ordiphones Android et Firefox OS), agir pour une action politique permettant de mettre un terme aux pratiques commerciales abusives de Google sur le marché des navigateurs.

Voilà pour ce que nous pouvons faire.

Je vais à présent m'interroger sur ce que Mozilla peut faire.

La situation ubuesque dans laquelle Mozilla se trouve aujourd'hui

D'une part, Mozilla est aujourd'hui – et de plus en plus – dans une situation de schizophrénie, et, d'autre part, certains des remèdes qu'elle envisage sont porteurs de leurs propres maux...

Une fondation schizophrène

La situation de schizophrénie dans laquelle se trouve aujourd'hui la fondation Mozilla tient à ce que le moyen actuel de sa survie participe à sa perte.

Le chiffre d'affaires consolidé déclaré de Mozilla (la fondation Mozilla et toutes les filiales) pour 2012 a été de 311 millions de dollars selon son dernier rapport annuel. Sur cette somme, 274 millions – soit tout de même 88% – proviennent de Google.

En somme, le financement de Mozilla :

• provient essentiellement de son principal concurrent, celui-là même dont les méthodes commerciales sont pour le moins contestables et dont les objectifs contreviennent dorénavant directement à ceux de Mozilla (v. le billet précédent) ;
• a pour contrepartie de contraindre Mozilla à œuvrer concrètement pour renforcer l'influence dudit concurrent.

La difficulté à se libérer d'une telle dépendance est une question fondamentale (comme je l'évoquais dans un précédent billet, il est infiniment plus difficile de sortir d'une dépendance que d'éviter d'y tomber).

Nous avons tous vécu cette situation à des degrés divers, et Framasoft en constitue un très bel exemple, avec son récent programme d'émancipation technique et financière de Google. La lecture des billets relatant ce difficile périple est tout à fait instructive :

• Framasoft lance sa campagne de soutien 2013 « moins de Google et plus de Libre » (21 nov. 2013)
• Manger la pâtée de son chien (23 janv. 2014)
• Bye bye Gmail ! (6 fév. 2014)
• Bye bye Google Groups, bonjour Framalistes ! (3 mars 2014)
• Bye Bye Google épisode 3 : les statistiques (Bonjour Piwik) (3 avr. 2014)
• Bye bye Google épisode 4 : les contenus embarqués et... la publicité ! (7 mai 2014)

Le dernier des billets cités nous apprend par ailleurs que la publicité rapportait dernièrement à Framasoft environ 7.000€ par an. Pour mesurer le poids relatif de cette recette financière, j'ai consulté le rapport moral et financier de l’association Framasoft pour l'année 2010 (je n'ai pas trouvé les suivants). Celui-ci fait état d'un budget annuel alors de 106 850€ (dont 46 550€ de dons). L'association avait alors deux salariés (comme aujourd'hui semble t-il), mais six serveurs (contre huit aujourd'hui) et pas de local (contre un aujourd'hui). La comparaison est donc très approximative. Cette réserve étant posée, on peut en déduire que la publicité représente au maximum 6-7% du budget de l'association (contre 44% pour les dons).

Par comparaison, Mozilla est infiniment plus dépendante, financièrement parlant, de Google. Peut-elle s'affranchir en tout ou partie de cette formidable dépendance ?

Des « solutions » qui soulèvent des problèmes éthiques

Face à cette dépendance problématique à Google, Mozilla étudie différents autres moyens de financement, comme la mise en place d'une commission financière sur les applications téléchargées via le Marketplace, ou l'introduction de la publicité dans le navigateur, via la page « Nouvel onglet ».

Cette dernière piste na va pas sans soulever quelques problèmes éthiques pour une fondation comme Mozilla, qui se veut porteuse d'un projet de société.

Ainsi Tolrek s'insurge à juste titre à ce sujet dans dans le numéro 3.5 du podcast Parole de Tux ! (à 40min48sec) : pour lui, la publicité est un outil d'aliénation de masse qui participe à l'épuration culturelle, et de rappeler Mozilla à ses responsabilités sociétales en citant une des phrases que Framasoft a choisies pour illustrer son site : mais ce serait l'une des plus belles opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code...

Il faut alors se demander si Mozilla est condamnée à passer éternellement d'un pacte diabolique à un autre ? N'y a t-il pas moyen pour elle de se financer sans contrevenir à ses valeurs ?

Des pistes de financement éthiques

Dans le podcast sus-cité, Philippe Scoffoni était invité pour évoquer le financement du logiciel libre. Il cite (spécialement à partir de 2h02min38sec) les différents moyens existants : de l'édition de logiciel au don, en passant par le support, la formation, la personnalisation ou l'hébergement.

La FAQ jointe au rapport annuel se montre étonnement évasive sur la possibilité pour Mozilla de tirer des revenus directement de ses partenariats autour de Firefox OS avec les opérateurs de téléphonie ou les fabricants de matériels : facture t-elle un service de personnalisation ou de support ?

Les dons et subventions concourent aux recettes de la fondation, mais faiblement (855.000$, soit 0,27%).

Soyons réalistes : ces deux pistes ne suffiront pas à remplacer la rente perçue de Google.

Il faut revenir un instant sur cette notion de « rente », qui explique peut-être la difficulté qu'a la fondation à penser des moyens de financement éthiques.

Le panorama que j'ai dressé montre, selon moi, que le modèle économique de la fondation est fondamentalement la rente.

Mozilla capitalise sur les parts de marché de son navigateur pour s'assurer des revenus, qu'il s'agisse des revenus tirés du recours au moteur de recherche embarqué dans le navigateur, du téléchargement d'applications par le Marketplace ou de l'affichage de publicités (qui peuvent prendre la forme de liens sponsorisés) dans la page « Nouvel onglet ».

Mon sentiment est que le modèle de la rente est intrinsèquement mauvais d'un point de vue éthique, dans la mesure où il est basé sur la capacité d'un fournisseur à influencer l'expérience de l'utilisateur en faveur de ses partenaires commerciaux.

C'est pourquoi je propose de revenir à la liste sus-citée, donnée par Philippe Scoffoni, des moyens de financement possibles pour le développement d'un logiciel libre. Outre les dons, sur le volume desquels la fondation a une emprise limitée, l'édition de logiciel, le support, la formation, la personnalisation ou l'hébergement restent des pistes possibles.

Personnellement, je pense que l'on doit même pouvoir aller au delà de la mise en place d'un moyen de financement qui ne nuise pas aux missions de Mozilla, et qu'il doit être possible de mettre en place un moyen de financement qui participe en outre activement à réaliser les missions de Mozilla.

La condition sine qua non serait, nous l'avons vu, de sortir du modèle de la rente.

Je propose donc que Mozilla capitalise non sur les parts de marché de ses logiciels mais sur son savoir-faire.

Mozilla pourrait ainsi ajouter une activité de développement de logiciels applicatifs libres en langage Web (et donc universels). Ses clients naturels pourraient être les institutions et administrations, tant il semble logique que les deniers publics servent à financer un bien commun, réutilisable par la communauté.

Une objection pourrait être qu'il ne faudrait pas que Mozilla phagocyte le marché de l'édition des logiciels libres. À la réflexion, cette objection ne me parait pas justifiée. D'une part les sociétés d'édition de logiciels libres sont déjà en concurrence avec des société géantes d'édition de logiciels propriétaires. D'autre part, lorsque j'évoquais la possibilité pour Mozilla de réfléchir à un moyen de financement qui ne se contenterait pas de ne pas être négatif mais qui serait positif en ce qu'il concourrait à la réalisation des missions qu'elle s'est fixées, c'est précisément ce que je propose ici : l'entrée de Mozilla sur ce marché devrait donner une visibilité et une crédibilité accrues aux société de services en logiciels libres et ainsi étendre leur marché. Ce faisant, Mozilla, en plus de s'assurer une source de revenus éthique, contribuerait d'avantage à sensibiliser aux bénéfices du logiciel libre.

Ce qui contribuerait en même temps à développer sa propre influence au delà de ses parts de marché, en ajoutant une influence politique à une influence économique.

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

NSA : Wikileaks révèle le nom du pays dont tous les appels ont été captés - Numerama

[EN] Blocking Google Chrome Installation - Riverlite

Windows 8 contient une 'porte dérobée' utilisable par l'agence américaine du renseignement NSA - Express.be

Cisco a peur pour sa réputation et le dit à Obama - Numerama

Le DRM arrive dans Firefox : décision délicate pour Mozilla - JDN Web & Tech

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

Original post of Romaine Lubrique.Votez pour ce billet sur Planet Libre.

Quand il s'agit de déployer des programmes de son cru sur un serveur GNU/Linux, on réalise généralement deux actions :

• l'écriture d'un script de démarrage et arrêt du programme
• la démon-isation du programme

Le premier point n'est pas complexe mais il peut être contraignant. Si on envisage de déployer sur Debian, Ubuntu et Fedora, il faut prévoir trois scripts différents : un pour les scripts à la saucce Sys V, un pour Upstart et un autre pour systemd. L'avantage c'est qu'on peut gérer finement les dépendances à d'autres services.

Le second point consiste à veiller à ne pas bloquer le script d'init en lançant le programme. On peut le gérer dans le code de notre programme en prévoyant deux modes de lancement de notre programme : daemon et interactif. Python, par exemple, propose la librairie daemonize pour réaliser cela. JAVA propose des outils comme JAVA Service Wrapper pour gérer le lancement et garantir l'arrêt du processus. On peut aussi le gérer de manière externe au code, de manière rustique avec un nohup, auquel cas il faut gérer l'arrêt fiable du processus en manipulant son PID.

Voici un exemple de script d'init à la sauce Debian pour un programme JAVA :

 #!/bin/sh
 ### BEGIN INIT INFO
 # Provides:          monprog
 # Required-Start:    $local_fs $remote_fs $network $syslog
 # Required-Stop:     $local_fs $remote_fs $network $syslog
 # Default-Start:     2 3 4 5
 # Default-Stop:      0 1 6
 # X-Interactive:     true
 # Short-Description: Start/stop monprog
 ### END INIT INFO

 BOOT_LOG=/var/log/monprog-boot.log
 PID_FILE=/opt/monprog/pid

 start_java () {
     nohup java -cp "/opt/monprog/lib/*" fr.yax.monprog.Main >$BOOT_LOG 2>&1 &
     echo $! > $PID_FILE
     echo "Monprog started ..."
 }

 do_start () {
     echo "Starting Monprog ..."
     if [ ! -f $PID_FILE ]; then
         start_java
     else
         PID=$(cat $PID_FILE)
         if [ -d /proc/$PID ]; then
             echo "Monprog is already running ..."
         else
             start_java
         fi
     fi
 }

 do_stop() {
     echo "Stopping Monprog ..."
     if [ -f $PID_FILE ]; then
         PID =$(cat $PID_FILE);
         kill $PID 2>/dev/null
         echo "Monprog stopped ..."
         rm -f $PID_FILE
     else
         echo "Monprog seems not running ..."
     fi
 }

 case $1 in
         start)
             do_start
         ;;
         stop)
             do_stop
         ;;
         restart)
             do_stop
             sleep 1
             do_start
         ;;
 esac

C'est perfectible. Il faudrait tenter l'arrêt avec un signal moins violent que SIGKILL de façon à l'intercepter dans le code et faire un arrêt propre. Si cette méthode ne fonctionne pas au bout de plusieurs secondes, le script d'init pourrait alors opter pour un arrêt radical.

Cette méthode fonctionne bien mais elle nécessite une connaissance système pour écrire et maintenir les scripts en fonction des déploiements cible. Si on veut donner la possibilité à un utilisateur standard (non root) de démarrer ou arrêter un programme, il faut aussi maîtriser un peu la gestion des droits UNIX (avec sudo par exemple).

Une alternative simple pour la plupart des systèmes UNIX (GNU/Linux, FreeBSD, Solaris et Mac OS X) est le programme Supervisor. C'est écrit en Python (comme la plupart des programmes de qualité ! Troll inside ) et de même que MongoDB permet au développeur de reprendre la main au DBA sur l'administration de base de donnée, Supervisor permet au développeur de reprendre un peu la main à l'admin sys sur le déploiement de ses applications.

Supervisor est fourni sur la plupart des distributions. On peut l'installer avec le système de paquet de sa distribution ou bien opter pour une installation à partir de PIP, l'installeur de programmes Python. Ce dernier permet d'obtenir la version la plus récente de Supervisor.

Supervisor est composé de deux parties :

• un service Supervisord
• un client en mode console : Supervisorctl

Le client permet d'interagir avec les programmes gérés : démarrer, stopper. Une interface RPC permet aussi de piloter Supervisord programmatiquement ; je n'ai pas encore testé cet aspect.

La configuration principale est dans un fichier supervisord.conf qui décrit la connexion du client supervisorctl (section unix_http_server), la config RPC (section rpcinterface) et le répertoire des configuration des programmes à gérer (section includes).

Voici une configuration type :

/etc/supervisor/supervisord.conf

 [unix_http_server]
 file=/var/run//supervisor.sock   ; (the path to the socket file)
 chmod=0770                       ; sockef file mode (default 0700)
 chown=root:supervisor

 [supervisord]
 logfile=/var/log/supervisor/supervisord.log
 pidfile=/var/run/supervisord.pid
 childlogdir=/var/log/supervisor

 [rpcinterface:supervisor]
 supervisor.rpcinterface_factory = supervisorrpcinterface:make_main_rpcinterface

 [supervisorctl]
 serverurl=unix:///var/run//supervisor.sock

 [include]
 files = /etc/supervisor/conf.d/*.conf

Les droits sur la socket UNIX sont important. En donnant l'accès à ROOT et au groupe supervisor, on peut facilement donner l'accès à supervisorctl en ajoutant un utilisateur dans le groupe supervisor. Attention donner l'accès à supervisorctl c'est donner le droit de stopper n'importe quel programme géré par supervisor. C'est un privilège important.

Le reste de la configuration consiste à créer des configurations additionnelles décrivant des programmes à lancer simplement :

• par défaut un programme démarre en même temps que le service donc au démarrage du serveur. C'est configurable.
• on peut définir si un programme doit être relancé automatiquement et définir sous quelle condition, par exemple en fonction du code de sortie du programme.
• on peut opter pour l'envoi d'un signal au programme afin de demander au programme de s'arrêter proprement plutôt que de forcer un arrêt brutal.
• on peut regrouper des programmes pour manipuler des groupes, faire des démarrages groupés et des arrêts groupés. C'est utile si on a beaucoup de programmes.
• au sein d'un groupe on peut définir des priorités pour ordonner le lancement des programmes du groupe.

Voici un exemple qui définit un groupe mesprogrammes composé de 2 programmes correspondant au même binaire.

/etc/supervisor/conf.d/mesprogrammes.conf

 [group:mesprogrammes]
 programs=monprog1,monprog2

 [program:monprog1]
 directory=/opt/monprogram
 command=/usr/bin/java -DrunDir=/opt/monprog -cp "lib/*" fr.yax.monprog.Main --port 1234
 stopsignal=INT
 priority=500

 [program:monprog2]
 directory=/opt/monprogram
 command=/usr/bin/java -DrunDir=/opt/monprog -cp "lib/*" fr.yax.monprog.Main --port 1235
 stopsignal=INT
 priority=501

Dans cet exemple, on envoie un signal SIGINT à monprog pour lui demander un arrêt propre. Voici un snippet de code JAVA pour intercepter le signal :

Interception d'un signal SIGINT en JAVA

 // register a shutdown hook
 Runtime.getRuntime().addShutdownHook(new Thread() {
     @Override
     public void run() {
         logger.info("Shutting down has been requested");
         stopCleanly();
     }
 });

En conclusion, Supervisor est un bon outil de gestion de programmes : fiable, facile à installer et à configurer. En complément d'un outil de déploiement comme Fabric un développeur peut facilement automatiser le déploiement de son programme sur une ou plusieurs machines cibles.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

Est ce que quelqu’un pourrait m’expliquer pourquoi tant de blogs utilisent DisquS pour gérer les commentaires à la place du système de commentaires intégré à WordPress ?

Si c’est un problème de spam, j’utilise le plugin Askimet comme anti-spam et il marche à la quasi perfection. (8’000 spams évités par mois. 99.88% de précision, gratuit jusqu’à 80’000 commentaires par mois)

Concernant la traçabilité, Askimet est un service centralisé auquel on envoie des infos personnelles : commentaire, IP, referrer, user agent . Mais DisquS est pire. Chaque commentateur est tracé sur le web entier par des cookies, voir même son compte. Et les infos refilées aux partenaires de DisquS vont jusqu’à a localisation et les pages vues.

J'aime(10)Ferme-la !(4)

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