PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

cpc6128 : Linotte 2.2 : vous allez aimer programmer !

lundi 7 avril 2014 à 14:42

Bonne nouvelle pour les jeunes et moins jeunes programmeurs (de 7 à 77+ ans), la version 2.2 de l’atelier de programmation du langage Linotte est disponible et téléchargeable !

Voici les nouveautés apportées :

Je vous laisse vous amuser avec cette nouvelle version et prenez autant de plaisir à programmer que j’ai eu à la concevoir !

Gravatar de cpc6128
Original post of cpc6128.Votez pour ce billet sur Planet Libre.

Tasse de Café : Internationaliser un site web avec PHP et gettext

lundi 7 avril 2014 à 11:00

Quand on développe un site web, il peut parfois être utile de le rendre disponible en plusieurs langues. Il est bien sûr possible de faire plusieurs fichiers différents pour autant de langues que l’on veut supporter, mais ce ne serait pas franchement très pratique. Heureusement, PHP nous simplifie grandement la tâche avec gettext.

Utiliser gettext avec PHP

GNU gettext, c’est une librairie disponible dans plusieurs langages et qui permet d’internationaliser des applications. Le principe est relativement simple : dans le programme, on modifie la façon de gérer les chaînes de caractères pour pouvoir dire qu’il faut internationaliser telle ou telle chaîne. Ensuite, on prépare un fichier contenant toutes les chaînes à traduire, et il n’y a plus qu’à les traduire pour que gettext sache par quoi modifier notre texte.

Comme vous vous en doutez, gettext existe en PHP, et c’est donc dans ce contexte que nous allons le voir ici. Vous allez d’ailleurs pouvoir constater que pour internationaliser une page web, il n’y a pas grand-chose à modifier.

Préparation des fichiers

Avant de voir la partie traduction et internationalisation à proprement parler, il nous faut préparer nos fichiers PHP pour dire à gettext quelles chaînes il doit traduire, dans quelle langue et surtout où chercher les fichiers de traduction.

Ce que nous allons faire ici doit être fait en tout début de fichier (c’est plus commode). Nous commençons par déclarer deux variables contenant respectivement la langue voulue et le domaine. Le domaine, c’est en quelque sorte un espace où l’on va ranger toutes les chaînes de caractères concernant une certaine catégorie. Pour de petits sites, le domaine n’a pas grand intérêt, mais imaginez de gros sites avec plein de pages et de catégories : en stockant toutes les chaînes de caractères au même endroit, on ne s’y retrouve plus, d’où l’intérêt des domaines qui permettent de mettre de l’ordre là-dedans.


$lang = 'fr_FR.utf8';
$domain = 'monsite';
?>

Jusque-là c’est plutôt simple. La variable $lang contient la langue voulue. Personnellement, j’ai pour habitude d’écrire les chaînes originales en anglais pour les traduire après, mais rien ne vous empêche de faire le contraire. Le domaine peut être n’importe quoi.

Ensuite, il faut dire à PHP quelle langue nous parlons. Cela se fait avec deux fonctions qui vont indiquer la locale utilisée (le code dans la variable $lang) :


putenv('LC_ALL=' . $lang);
setlocale(LC_ALL, $lang);
?>

Il nous faut ensuite indiquer le domaine dans lequel chercher les fichiers de traduction. Là encore, deux fonctions seront nécessaires :


bindtextdomain($domain, './lang');
textdomain($domain);
?>

La fonction bindtextdomain() demande deux arguments : le premier est le nom du domaine et le second est le chemin vers le dossier où sont situés les fichiers de traduction. Pour plus de praticité, il est recommandé de les placer dans un dossier spécifique. La fonction textdomain() quant à elle indique que l’on souhaite utiliser le domaine indiqué.

La préparation des fichiers est presque terminée. En fait, la suite changera à chaque projet : il s’agit d’indiquer quelles chaînes doivent être traduites. Pour cela, il faut légèrement modifier notre façon d’afficher ces dernières.

Plusieurs façons d’afficher une chaîne

La méthode la plus simple pour afficher un texte traduit, c’est avec la fonction gettext(), dont _() est un alias beaucoup plus utilisé. Vous pouvez donc utiliser l’une ou l’autre sans distinction (enfin faites un choix quand même, c’est plus propre) :

echo gettext('Hello World!'); ?>

echo _('Hello World!'); ?>

Mais dans certains cas, gettext() ne suffira pas. Il faut en effet par moments savoir gérer le pluriel qui ne se comporte pas toujours de la même façon selon les langues. Par exemple, si vous souhaitez afficher le nombre de commentaires, il faudra faire la distinction entre « 1 commentaire » et « 3 commentaires« . On pourrait bien évidemment faire nos propres tests pour déterminer quelle chaîne afficher, mais gettext peut faire le boulot pour nous et ainsi choisir s’il faut traduire au pluriel ou non :

printf(ngettext('%d comment', '%d comments', 2), 2); ?>

Si on utilise ici printf() plutôt qu’un simple echo, c’est pour l’argument %d qu’il propose et qui permet d’insérer un nombre, indiqué en deuxième argument. L’utilisation de ngettext() n’est par ailleurs pas très mystérieuse : on indique le texte du singulier, puis le texte du pluriel et enfin le nombre d’éléments, pour savoir si on doit utiliser la première ou la seconde forme.

Traduction !

Bien, nos fichiers sont prêts, mais pour le moment nous n’avons toujours qu’une seule langue disponible. Il est donc temps de passer à la traduction à proprement parler, et vous allez pouvoir constater que c’est probablement beaucoup plus simple que ce à quoi vous vous attendez…

Premièrement, il faut savoir que gettext ira chercher les chaînes traduites dans des fichiers *.mo. Il s’agit de fichiers binaires générés à partir de fichiers *.po. C’est dans ces fichiers *.po que tout le travail de traduction est fait : on y trouve les chaînes originales et, en-dessous, les chaînes traduites. Chaque langue aura donc son propre fichier *.po, et pour éviter de modifier un fichier de langue pour créer une autre langue, on a introduit les fichiers *.pot, qui vont servir de base à nos fichiers *.po : on y trouvera les chaînes à traduire, mais on ne les traduira jamais. Il nous faut donc maintenant créer tous ces fichiers.

xgettext

Nous avons préparé nos fichiers et nous savons donc quelles chaînes seront traduites : les fonctions sont uniques, on sait où chercher. Du coup, on se dit qu’un programme pourrait s’occuper d’aller chercher tout ça tout seul, et c’est exactement ce que fait xgettext. Ouvrez donc un terminal et lancez la commande :
xgettext index.php -o lang/monsite.pot

Bien évidemment, ça se change à souhaits : index.php est le chemin vers le fichier à traduire et après l’option -o vient un autre chemin, celui du fichier *.pot à générer. Ce fichier *.pot peut être utilisé tel quel, mais je vous recommande de le modifier légèrement (un simple éditeur de texte suffira).

Ainsi, vous y trouverez un header sous forme de gros commentaire. Ce header contient quelques passages en lettres capitales qu’il serait bon de modifier pour y voir apparaître les informations concernant votre projet. De même, la toute première chaîne contient plusieurs informations et il est utile d’y modifier le CHARSET (UTF-8 est une bonne idée).

msginit

Maintenant que nous avons notre *.pot, il faut générer autant de *.po que de langues à supporter. Pour cela, c’est assez simple, et ça passe par un autre programme : msginit, qui s’utilise comme suit.
msginit --locale=fr -i monsite.pot -o fr_FR/LC_MESSAGES/monsite.po

Je n’ai pas vraiment insisté là-dessus parce que ce n’est pas très important pour le fichier *.pot, mais le nom des fichiers a une importance : à la fin, le fichier *.mo devra posséder le nom du domaine de traduction que vous avez choisi plus haut. C’est pourquoi j’ai choisi les noms « monsite » depuis le début, il s’agissait simplement de rester cohérent.

La locale doit bien sûr être adaptée selon vos besoins. L’option -i attend, comme vous vous en doutez, le fichier *.pot sur lequel il faut se baser tandis que l’option -o est le chemin vers le fichier *.po à générer. Là, vous devriez vous demander pourquoi j’ai choisi un chemin aussi… pourri disons-le clairement.

En fait, nous n’avons pas vraiment parlé de l’endroit où gettext va chercher les fichiers. Il va bien sûr se baser sur le dossier que vous avez indiqué pendant la création du domaine (« ./lang » pour ma part). Cependant, ce dossier doit être découpé en plusieurs sous-dossiers qui représenteront autant de langues supportées. Dans ces sous-dossiers, il faudra créer un répertoire LC_MESSAGES et c’est là-dedans qu’il faudra mettre vos fichiers *.mo. Encore une fois, l’emplacement du *.po n’a pas d’importance, mais il s’agit d’être cohérent.

Petite pause

Si ce n’est pas vous qui traduisez les phrases, envoyez les fichiers *.po au traducteur et prenez donc une petite pause, car vous n’avez rien à faire en attendant.

Dans le fichier *.po, on trouve une succession de petits blocs. La plupart seront sous la forme d’un couple (msgid, msgstr). Comme vous pouvez le deviner, msgid est la chaîne à traduire et ne doit pas être modifiée. Par contre, msgstr est par défaut vide et doit donc être remplie avec la traduction de la chaîne correspondante. Et c’est tout.

Les choses se compliquent légèrement avec le pluriel si vous en avez utilisé : on trouvera msgid pour la forme singulière et msgid_plural pour la forme plurielle, les deux faisant référence aux chaînes originales. Viennent ensuite les traduction, dans le même ordre. Pas très compliqué en fait, mais si vous ne traduisez pas vous-même, pensez bien à indiquer au traducteur qu’il ne doit en aucun cas modifier les « %d » et autres tags dont vous vous servez.

D’ailleurs, en parlant de ça, une option utile de xgettext est -c : ajoutez-la et tous les commentaires situés juste au-dessus d’une chaîne à traduire apparaîtront dans le fichier *.pot (et donc dans les *.po).
xgettext index.php -o lang/monsite.pot -c
Elle peut s’avérer pratique pour prévenir les traducteurs qu’ils doivent laisser certains tags tels qu’ils sont.

msgfmt

Nous avons bientôt fini. Vous avez les fichiers *.po contenant les traductions, reste maintenant à les traduire en binaires pour que gettext puisse les utiliser. Cette opération peut être faite de façon très simple :
msgfmt monsite.po -o monsite.mo

Et c’est tout ! Normalement, vous devriez voir vos chaînes dans la langue choisie dans la variable $lang créée tout au début. Il ne vous reste plus qu’à rendre cette variable un poil plus dynamique : dans l’état, cette traduction ne sert strictement à rien si vous ne détectez pas automatiquement la langue de l’utilisateur, ou si vous ne lui laissez pas une option permettant de la choisir lui-même.

Je veux rajouter une phrase sans devoir tout recommencer

Votre site évoluera sûrement au cours du temps, en proposant toujours plus de contenu. Ainsi, vous pourriez être amené à rajouter une phrase à traduire. Sauf qu’avec ce qu’on a vu ici, vous n’avez pas d’autre choix que de tout recommencer, en reprenant la traduction depuis le début. C’est moche.

Heureusement, gettext et compagnie ont tout prévu ! Comme d’habitude, on commence avec xgettext :
xgettext -j index.php -o monsite.pot

Ici, c’est l’option -j qui change tout : elle a pour charge de ne pas écraser le contenu du fichier monsite.pot qui existe déjà et ajoutera à la suite les nouvelles chaînes. Il y a cependant un petit bémol : une chaîne modifiée apparaîtra comme nouvelle et sera donc ajoutée à la fin, tandis que l’ancienne chaîne, devenue inutile, conservera sa place.

On continue avec msginit, comme toujours :
msginit --locale=fr -i monsite.pot -o fr_FR/LC_MESSAGES/monnouveausite.po

Ici, rien ne change, excepté que je n’ai pas choisi d’écraser l’ancien fichier *.po, ce qui est très important. Contentez-vous ensuite de ne traduire que les nouvelles chaînes en laissant vides les anciennes.

Avant de formater tout ça en binaire, nous allons fusionner l’ancien fichier *.po et le nouveau : les traductions seront alors toutes au même endroit, qu’elles soient anciennes ou nouvelles.
msgmerge -o monsite.po monnouveausite.po monsite.po

L’ordre est important ici. À la sortie, j’écrase l’ancien fichier *.po : vous n’êtes pas obligés de le faire, mais il sera devenu inutile (comme le nouveau d’ailleurs).

La suite rejoint ce que vous connaissez : un coup de msgfmt et le tour est joué.

Pfiou, ce fût long, mais on aura fait le tour de tout ce dont nous avons besoin de base pour traduire un site web. Si vous avez besoin d’options supplémentaires, n’oubliez pas le manuel de chaque commande qui est assez fourni. Nous aurons d’ailleurs l’occasion de revenir sur une option de xgettext bien particulière lors d’un prochain tutoriel sur la traduction d’un plugin ou thème WordPress.

Pour finir, notez que tout ici utilise un simple éditeur de texte, mais il existe des programmes, comme poEdit par exemple, qui permettent la traduction dans un environnement fenêtré, pour ceux qui préfèrent.

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

Progi1984 : Utiliser Coveralls avec Github & Travis dans un projet PHP

lundi 7 avril 2014 à 10:30

Votre projet PHP est hébergé sur GitHub, et vous avez mis en place de l’intégration continue avec Travis-CI. Par contre, votre seul moyen actuellement de voir le taux de couverture de vos tests unitaires, c’est d’aller voir le build de Travis. Coveralls est la solution à notre problème. Ce service nous fournira un badge et un rapport des tests unitaires de notre projet.

Logo PHP

Activer son projet sur Coveralls.io

Après vous être connecté avec votre compte Github (et lui avoir donné accès à votre email), on va aller sur la page des dépôts pour autoriser Coveralls sur votre projet PHP. Après avoir activé Coveralls.io sur un dépôt, un bouton “View on Coveralls” apparaît.

Coveralls.io : autorisation sur un dépôt

En cliquant sur ce lien, Coveralls ne nous montre aucun rapport de couverture de code. Mais c’est normal vu qu’on ne l’a pas encore fait.

Utiliser Coveralls.io avec PHPUnit et Travis-CI

Il faut tout d’abord définir dans le composer.json de votre une librairie pour les développeurs :

"require-dev": {
    "satooshi/php-coveralls": "dev-master"
}

Ensuite il faut modifier le fichier .travis.yml pour y inclure certaines parties.
Tout d’abord, avant le script, on va créer un dossier pour les logs :

before_script:
  ## PHPUnit
  - mkdir -p build/logs

Dans le script, lorsque l’on va executer PHPUnit, on va lui demander de générer un rapport de couverture de type Clover :

script:
  ## PHPUnit
  - phpunit -c ./ --coverage-text --coverage-clover build/logs/clover.xml

Après le script, on va envoyer les données chez Coveralls.io :

after_script:
  ## Coveralls
  - php vendor/bin/coveralls -v

Utiliser Coveralls.io avec Atoum et Travis-CI

Pour Atoum, le principe est le même.

On utilise Composer pour installer le package

satooshi/php-coveralls
.
Dans le fichier .travis.yml, avant le script, on crée le dossier pour les logs.
La partie principale du script change. Vous devez ajouter à votre projet un fichier de configuration .atoum.php qui sera appelé par Atoum lors des tests pour générer un fichier de log clover.xml.
addDefaultReport();

  $cloverWriter = new atoum\\writers\\file('./build/logs/clover.xml');
  $cloverReport = new atoum\\reports\\asynchronous\\clover();
  $cloverReport->addWriter($cloverWriter);

  $runner->addReport($cloverReport);

?>

Dans le script, on appelle le fichier de configuration :

script:
  ## Atoum
  - php mageekguy.atoum.phar -d tests/ -c .atoum.php

Après le script, on exécute Coveralls.io pour que les données soient envoyées chez Coveralls.io.

Conclusion

Et voilà, vos données sont envoyés chez Coveralls.io.
Des rapports sont mis à votre disposition (par exemple, pour PHPTranslate) avec le pourcentage de lignes couvertes en global ou par fichier, et même les lignes couvertes, l’évolution de la couverture du code sur le projet, l’affichage de l’augmentation ou de la baisse de couverture de code pour chaque nouveau commit.
Vous pouvez aussi récupérer des badges afin d’afficher le taux de couverture de code. Par exemple, avec PHPTranslate :
Coverage Status

Cet article Utiliser Coveralls avec Github & Travis dans un projet PHP est apparu en premier sur RootsLabs.

Gravatar de Progi1984
Original post of Progi1984.Votez pour ce billet sur Planet Libre.

Antistress : Les anti-fonctionnalités

lundi 7 avril 2014 à 02:14

La liberté enchaînée, par Luciano Castelli (1990) : Tableau de femme dont les bras sont des chaînes

Pourquoi je veux vous parler des anti-fonctionnalités ? Parce que, parmi les avantages intrinsèques du logiciel libre, il y a le fait que le celui-ci vous protège des anti-fonctionnalités.

Exceptionnellement je ne vous propose pas un billet original ; au lieu de cela je vais reprendre littéralement deux très bons exposés sur le sujet, l'un de Benjamin Mako Hill que vous ne trouverez qu'au milieu de cette conférence donnée dans la langue de Shakespeare et qui alimente les deux premiers paragraphes de ce billet, l'autre de Benjamin Bayart que vous ne trouverez qu'au milieu de cette longue (et passionnante) vidéo et qui alimente le troisième et dernier paragraphe de ce billet. Or il me parait important d'attirer votre attention sur le mécanisme des anti-fonctionnalités.

De quoi s'agit-il ?

Une anti-fonctionnalité est une fonctionnalité conçue par le fabricant d'une technologie de telle façon que l'utilisateur de la technologie va la détester.

C'est le contraire d'une fonctionnalité qui fait que la technologie va faire quelque chose que vous voulez : une anti-fonctionnalité est conçue pour qu'une technologie fasse quelque chose que vous ne voulez pas qu'elle fasse.

C'est quelque chose que les utilisateurs détestent tant qu'ils seraient prêt à payer pour avoir la chance de la supprimer.

Attention : comme une fonctionnalité, une anti-fonctionnalité c'est quelque chose qui a dû être développé : ce n'est pas un bug, ce n'est pas une fonctionnalité manquante, c'est une fonctionnalité ajoutée, mais c'est une fonctionnalité négative dans le sens où ça fait faire à la technologie quelque chose que vous ne voulez pas qu'elle fasse.

Un exemple logiciel : Windows

Ex : Windows NT 4.0 et ses deux versions : Poste de travail (Workstation) et Serveur (Server)

Jaquettes des deux versions de Windows NT 4.0 : Poste de travail, et Serveur

Alors que Windows NT Server incluait une série d'applications serveur absentes dans la version NT Workstation, Microsoft soutenait que les systèmes d'exploitation eux-mêmes étaient « deux produits distincts destinés à deux types d'usages très différents ». NT Server, prétendait Microsoft, était taillé sur mesure pour être un serveur Internet, tandis que NT Workstation était tout à fait inadapté. Dans le but de bien marquer cette différence, la version NT Workstation et aussi l'accord de licence limitaient les utilisateurs à un maximum de dix connexions TCP/IP (pour Internet), tandis que la version NT Server demeurait sans limitations.

Beaucoup d'utilisateurs remarquèrent que les deux versions de Windows NT étaient très semblables. En creusant un peu la question, une analyse publiée par O'Reilly et Associés révéla que le noyau, et de fait tous les fichiers binaires de NT Workstation étaient identiques à ceux qui se trouvaient dans NT Server. L'unique différence entre les deux noyaux se trouvait dans l'information destinée à l'installation du système d'exploitation, la version serveur proposait diverses options ou drapeaux pour la marquer soit comme « Workstation » soit comme « Server ». Si la machine était identifiée comme « Workstation », cela désactivait certaines fonctionnalités et limitait le nombre possible de connexions au réseau. Il n'y avait qu'un bit d'écart entre les deux versions.

Des développeurs chez Microsoft ont réfléchi puis ont passé du temps à développer cette fonctionnalité dont le but est de limiter les possibilités du logiciel. Ils ont ensuite réalisé des tests pour s'assurer que l'utilisateur ne pourrait pas bénéficier de plus de connections.

C'est un procédé méthodique, industriel, pour rendre le logiciel moins bon qu'il ne serait sinon. La seule raison pour Microsoft de faire ça c'était de pousser les utilisateurs à acheter le produit plus onéreux s'ils voulaient s'en servir sur un serveur.

Mais c'était en 1996, et les choses sont sûrement différentes maintenant ?

Jaquettes des six versions de Windows NT 4.0 : Starter, Familiale Basique, Familiale Premium, Professionnel, Entreprise, et Intégrale

Les six versions (!) de Windows 7 se distinguent d'après la quantité de RAM que vous voulez utiliser. Ah oui, et on ne peut pas changer le papier peint avec Windows 7 Starter :

Une fonctionnalité que Microsoft avait développée et a fini par abandonner est la limitation du nombre d'applications que l'utilisateur est autorisé à faire tourner simultanément dans l'interface. Avec la version Starter, l'utilisateur était limité à trois applications.

Ainsi si vous avez ouvert le Bloc-notes, la Calculatrice et Paint, et que vous voulez lancer Internet Explorer par exemple, le système vous répond aimablement que « Pour pouvoir ouvrir une autre application, enregistrez votre travail, puis fermez l'un des programmes ouverts ».

Une équipe de développeurs a donc été mobilisée pour créer cette fonctionnalité ; si vous y réfléchissez ce n'est pas une fonctionnalité triviale à implémenter : si vous êtes un ingénieur vous devez distinguer les applications qui tournent dans l'interface des autres, vous devez intercepter la quatrième application avant qu'elle ne se lance, afficher un message d'explication à l'utilisateur...

Starter était vendu à un prix bradé et il y avait un large projet dont le but était de le rendre tellement mauvais que les utilisateurs qui en avaient les moyens paieraient à coup sûr pour abandonner cette version pour une version plus onéreuse.

Voilà ce qu'est une anti-fonctionnalité.

Maintenant imaginez que vous êtes développeur chez Microsoft et que le soir vous rentrez chez vous et racontez votre journée en vous félicitant : « aujourd'hui j'ai rendu cette version de Windows vraiment, vraiment mauvaise » !

Du côté des logiciels libres, il n'est pas impossible que quelqu'un développe une anti-fonctionnalité mais ça ne peut pas durer dans le cas d'un logiciel libre parce que le logiciel libre donne le contrôle à l'utilisateur et que les anti-fonctionnalités sont conçues pour exploiter l'utilisateur (comme dans les exemples précédents). Et quand les utilisateurs ont le contrôle ça leur donne la possibilité de choisir et la plupart des utilisateurs choisissent de ne pas être exploité. Et le résultat est que les anti-fonctionnalités ne peuvent perdurer dans le monde Libre.

La résistance aux anti-fonctionnalités est un bénéfice véritablement inhérent aux logiciels libres.

Vous pouvez dire que je chipote et qu'après tout c'est courant aujourd'hui et que c'est devenu le business model de l’industrie des logiciels.

Mais je répondrai que ce n'est pas tout à fait exact : c'est le business model de l’industrie des logiciels propriétaires, et ce n'est pas pour rien qu'on les appelle aussi des logiciels privateurs. Je voudrais juste rappeler qu'il existe une alternative, qu'il s'agit des logiciels libres et que ceux-ci sont immunisés par nature aux anti-fonctionnalités.

Pour bien vous faire comprendre qu'il s'agit d'un sujet sérieux et qu'il ne faut pas aller trop vite en estimant que « après tout c'est une situation normale », je voudrais vous donner un autre exemple qui parlera à tout le monde.

D'autres exemples

Tout d'abord citez une machine de l'ère pré-informatique qui ait pour but d'empêcher quelqu'un de faire quelque chose.

À part une serrure ou des menottes, c'est assez rare.

En informatique, vous l'avez compris, ça devient banal.

Le souci c'est qu'aujourd'hui l'informatique ne se limite plus à l'ordinateur personnel. L'informatique est partout, par exemple dans tous les objets électroniques du quotidien.

Je prends un exemple tout bête : mon lecteur de DVD.

Celui-ci commence par vous passer tout un tas de logos où quand vous faites suivant ou menu il vous dit « interdit ». Il ne vous dit pas « je sais pas faire » : VLC y arrive il n'y a pas de raison que le lecteur de DVD n'y arrive pas. Il peut le faire, mais il veut pas.

Mon lecteur de DVD à moi dans mon salon, et il me dit à moi qu'il veut pas.

C'est pas un bracelet électronique qu'on m'a mis parce que j'ai fait des bêtises, c'est mon lecteur de DVD à moi.

Quand mon marteau je lui dis de taper sur un clou il dit pas « non ». Si le tailleur de pierre part en guerre contre son marteau, c'est qu'on a raté quelque chose.

Au mieux j'ai des appareils qui me disent : « je peux pas » : la cafetière, quand je viens de l'allumer, elle ne fait pas un café tout de suite parce qu'elle chauffe et elle me dit « je peux pas », mais il y a une raison technique à cela : elle peut pas.

C'est un problème beaucoup plus sérieux qu'il n'en a l'air ; ça veut dire que cet appareil est conçu pour obéir à quelqu'un qui n'est pas moi et qui impose par ses machines sa volonté à des populations entières.

Tant que c'est pour vous forcer à regarder la pub ou vous forcer à regarder le message qui dit que le piratage c'est mal et que pour regarder le film plus vite vous auriez dû le prendre sur bittorent c'est pas très très grave comme atteinte on va dire, mais le principe est extrêmement gênant : un accessoire chez vous ne vous obéit pas.

Quand votre smartphone refuse d’installer telle application qui n'a pas été certifiée par telle entreprise, c'est un problème.

Cette mécanique de fous, c'est la mécanique des DRM, c'est celle d'un fichier qui dit : « votre ordinateur ne doit pas le lire plus de cinq fois, ou ne doit pas le lire entre 22h et 6h ».

Vous ouvrez un PDF : « interdit de l'imprimer ». Obligé de le lire sur écran. De quel droit ?

Vendre des engins qui ont comme objectif de vous contrôler, ou dont certaines fonctionnalités ont comme objectif de vous contrôler, alors que ce n'est pas la mission première de l'engin (bracelet électronique, menotte, serrure c'est fait pour. On l'a même acheté exprès : si la serrure permettait de rentrer sans les clé on ne l’aurait pas acheté). Alors que l'iPhone qui vous interdit un certain nombre d'applications, c'est pas pour ça qu'on l'a acheté. Vous n'avez pas acheté votre marteau pour qu'il refuse d'enfoncer les clous.

D'autres exemples d'anti-fonctionnalités, que vous trouvez par exemple dans les applications pour smartphone :

C'est un sujet sérieux : il devrait être interdit de vendre ce type d’appareils par lesquels les fabricants exercent un contrôle abusif sur l'utilisateur. C'est un problème de société qui devrait être traité au niveau politique.

J'espère qu'à travers l'exemple des anti-fonctionnalités j'ai réussi à illustrer une des différences fondamentales qui existe entre le logiciel privateur et le logiciel libre, à savoir qui contrôle la machine : l'utilisateur ou le concepteur.

Pour élargir le débat :

Ce sont clairement des marqueurs d'une société non démocratique.

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

Planet Libre : Brèves du Planet Libre - lundi 07, avril 2014

lundi 7 avril 2014 à 00:00

Le guide de migration de Windows XP vers Linux - La Fabrique du Web

Windows linux debian xfce


antistress : Tout est dans le titre.


Eric Schmidt on the NSA* (*translated from original bullshitese) - Boing Boing - Liens en vrac de sebsauvage

google pistage institution


antistress : "Bruce Schneier (spécialiste en crypto) met les pieds dans le plat en traduisant la langue de bois du PDG de Google"


Pourquoi le CSA sera bien pire que la Hadopi - Numerama

csa filtrage institution Web


antistress : S'il ne faut lire qu'un article sur cette réforme en cours... Les enjeux sont parfaitement définis et le futur qui se prépare ne fait pas envie.


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