source: Framablog
Quelques-unes des participations de Framasoft au programme :
http://schedule2013.rmll.info/programme/cultures-et-arts-libres/cultures-et-arts-libres-6/
Crédit : Simon Gee Giraudot (Creative Commons By-Sa)
Bonjour Céline, peux-tu nous expliquer comment tu en es venue à
utiliser le système d’exploitation Free BSD ? Tu l’as attrapé tout d’un
coup ou bien c’est l’effet d’une lente incubation ?
Je suis arrivée sur FreeBSD un peu par hasard. En fait, quand j’ai décidé de passer à Linux (en 1999, je sais ça remonte), j’ai testé plusieurs distributions dont La Lycoris Desktop LX, Debian et Ubuntu 6.06. J’ai utilisé Ubuntu et Debian en parallèle pendant énormément de temps jusqu’à ce que je décide de tester OpenBSD (réputé pour sa sécurité) pour l’utiliser sur un serveur de développement. À cause de l’absence de Java et comme je suis développeuse C/Java, j’ai éprouvé de la frustration de ne pas pouvoir tout faire sur ma machine nouvellement acquise. J’ai donc cherché une alternative la plus proche possible : FreeBSD s’est avéré être mon choix final. Une installation sans fioriture, simple et qui n’installait que ce dont j’avais besoin sur mon serveur (seul ArchLinux m’avait satisfaite au même degré jusque-là), je ne demandais rien de plus. Donc pour en revenir à l’usage de ce système d’exploitation, c’est bien l’effet d’une incubation d’une bonne dizaine d’années.
Bon c’est bien joli FreeBSD mais son installation et son usage réclament un certain niveau de compétence technique, non ? est-ce que tu le conseillerais vraiment à des usagers qui comme moi choisissent Ubuntu parce que c’est la distribution la plus abordable ? Il n’existe pas une version plus simple avec une interface graphique qui simplifie la vie ?
C’est vrai que quand on arrive sur FreeBSD, il ne faut pas avoir peur de la console. C’est pareil pour certaines distributions Linux, il faut s’armer de patience, lire la documentation (très bien réalisée) et parfois galérer dans les pages man. L’installation ne se fait pas en quelques clics, une fois l’installation finie, on ne dispose vraiment que des outils de base. Mais c’est ce que j’adore sur OpenBSD et FreeBSD (bon et aussi ArchLinux), c’est que je sais ce qu’il y a sur mon poste, ce qui démarre quand j’allume mon ordinateur, alors qu’au fil de temps je trouve que le fonctionnement des distributions Linux, pour se rendre facile d’accès au grand public, devient de plus en plus opaque. Il suffit de taper un petit ps aux sur Ubuntu pour voir tout ce qui peut tourner (des fois pour rien)… Pour ce qui est d’une version plus facile d’accès, j’ai entendu parler de PC-BSD qui a justement pour objectif de rendre FreeBSD accessible à tous : installation aisée en quelques clics, KDE est fourni en bureau par défaut… Je testerai peut-être un jour sur un autre PC ou avec VirtualBox ;-)
Tu en fais un usage dans ta vie professionnelle ou bien c’est choix de passionnée pour ton usage personnel ?
Dans ma vie professionnelle, je travaille sur RedHat, Debian et Solaris, hélas pas encore de FreeBSD en vue, mais ça viendra ! ;-)
Merci, je te laisse le soin de présenter l’article…
Il y a de cela 20 ans, le 19 juin 1993, David Greenman, Jordan Hubbard et Rod Grimes annonçaient la création d’un nouveau logiciel basé sur le code source de BSD (Berkeley Software Distribution, voyez cette page Wikipédia) : FreeBSD était né. Peu connu du grand public, ce système d’exploitation est pourtant utilisé partout : en tant que solution d’hébergement pour des sociétés telles que Yahoo!, ou comme solution de sécurité pour la mise en place de firewall. Deux systèmes d’exploitation reposent sur son noyau : FreeNAS et MacOS. FreeNAS est une solution libre grand public pour héberger du contenu à travers un réseau, tandis que MacOS est le système d’exploitation propriétaire que nous connaissons tous au moins de nom. Pour fêter ce cap des 20 ans, voici un petit article qui vous fera découvrir une partie du monde BSD.
— Céline
Le système d’exploitation open source FreeBSD vient de fêter son vingtième anniversaire.
FreeBSD a vu au fil des années sa popularité auprès du grand public diminuer alors que le noyau Linux et les nombreuses distributions qui l’utilisent ont connu un développement rapide. Cependant, FreeBSD a eu 20 ans le 19 juin et continue de faire fonctionner des infrastructures réseaux vitales.
FreeBSD a introduit de nombreuses innovations qui ont été adoptées par certaines distributions Linux. Par exemple, la collection de ports FreeBSD, qui compile des logiciels à partir du code source plutôt qu’à partir de binaires pré-assemblés, a été copiée par Gentoo Linux pour son système Portage.
FreeBSD est également connu pour avoir l’une des piles réseau les plus robustes. Il est fréquemment utilisé par les chercheurs et les industriels comme base pour la simulation et les systèmes de production. Monowall et Pfsense sont des distributions populaires basées sur FreeBSD destinées à être utilisées sur des périphériques réseaux qui embarquent tous les types de fonctionnalités, des firewalls aux réseaux privés virtuels en passant par les liaisons ADSL, sur un système facile à utiliser.
Alors que FreeBSD n’est pas la seule variante libre et largement distribuée de BSD Unix, il est différent de OpenBSD qui essaie d’être le système d’exploitation le plus sécurisé et de NetBSD qui tente de fonctionner sur n’importe quel appareil possédant un microprocesseur. Il est devenu la référence pour une utilisation générale de BSD.
Cependant, FreeBSD n’est pas que réseau et démons, puisque durant ces dernières années les distributions de bureau BSD Unix reposant sur FreeBSD sont apparues, notamment avec PC-BSD qui est la plus célèbre.
FreeBSD, grâce à ses performances et sa licence, est utilisé par des sociétés commerciales comme Citrix, Netapp et Juniper.
Ces dernières années, même la communauté Linux a commencé à reprendre des parties de FreeBSD, avec Debian qui propose une version de sa distribution utilisant le kernel FreeBSD. Malgré la blague récurrente sur le fait que BSD soit mort ou non, étant donné son support à l’industrie, il est probable qu’il continuera son combat dans les décennies à venir.
Ce n’est pas la première fois que la Gendarmerie Nationale mérite un coup de chapeau des libristes, souvenez-vous de la migration massive vers Ubuntu.
Source :
Crédit : Simon Gee Giraudot (Creative Commons By-Sa)
Qu’il s’agisse de son code ou de son utilisation, la faiblesse de la documentation d’un logiciel libre est souvent montrée du doigt.
Voici, selon Andy Lester, 13 défauts ou lacunes communément rencontrés, qui sont autant d’écueils que l’on peut contourner avec un minimum d’efforts aujourd’hui pour gagner demain un temps précieux.
13 Things People Hate about Your Open Source Docs
Andy Lester - 10 janvier 2013 - SmartBear Blog
(Traduction : Lamessen, calou, Shanx, sinma, Asta + anonymes)
La plupart des développeurs open source aiment penser à la qualité du logiciel qu’ils développent, mais la qualité de la documentation est souvent laissée de côté. Il est rare de voir vanter la documentation d’un projet, et pourtant elle a un impact direct sur sa réussite. Sans une bonne documentation, les utilisateurs n’utiliseront pas votre projet, ou ils n’y prendront pas de plaisir. Les utilisateurs comblés sont ceux qui diffusent des infos à propos de votre projet – ce qu’ils ne font qu’après avoir compris comment il fonctionne. Et ils apprennent cela à partir de la documentation du projet.
Malgré tout, de trop nombreux projets ont une documentation décevante. Et cela peut être décevant de plusieurs manières.
Les exemples que je donne ci-dessous sont purement arbitraires, je ne veux pas cibler un projet en particulier. Ce sont seulement ceux que j’ai utilisés récemment, cela ne veut pas dire qu’ils représentent les pires atrocités. Chaque projet a commis au moins quelques-uns de ces péchés. Que vous soyez utilisateur ou développeur, à vous d’évaluer à quel point votre logiciel préféré est ou non coupable, et comment vous pouvez aider à y remédier le cas échéant.
Le README/LISEZ-MOI est la première impression que les utilisateurs potentiels ont de votre projet. Si le projet est sur GitHub, le README/LISEZ-MOI est automatiquement affiché sur la page d’accueil du projet. Si vous l’avez mal rédigé, ils peuvent ne jamais revenir.
Vous voulez capter l’attention du lecteur et l’encourager à continuer la découverte de votre projet ? Le README/LISEZ-MOI devrait alors au moins expliquer :
Tout cela doit pouvoir être compris par quelqu’un qui n’a jamais entendu parler de votre projet, et peut-être même jamais imaginé un projet pouvant s’en rapprocher. Si le projet possède un module calculant la distance de Levenshtein, ne partez pas du principe que n’importe qui lisant votre README/LISEZ-MOI sait ce que c’est. Expliquez que la distance de Levenshtein est utilisée pour comparer deux chaînes de caractères, et ajoutez quelques renvois vers des explications plus poussées pour celui qui aimerait approfondir le sujet.
Ne décrivez pas votre projet par rapport à un autre projet, comme « NumberDoodle est comme BongoCalc, mais meilleur ! » Ça n’est d’aucune aide pour quelqu’un qui n’a jamais entendu parlé de BongoCalc.
Bien que je n’ai pas lu d’études à ce sujet, je serais prêt à parier que 90% des recherches de documentation sont faites avec Google et un navigateur sur Internet. La documentation de votre projet doit être en ligne, et disponible. Partant de là, il serait embarrassant que la documentation de mon propre projet, ack, ne soit pas disponible à l’endroit où la majorité des gens vont la chercher. Mon hypothèse est basée sur ma propre expérience, à savoir que si je veux connaître le fonctionnement d’un outil en ligne de commande, je vais vérifier sa page man.
Comment je m’en suis aperçu ? Les utilisateurs m’écrivaient pour me poser des questions dont les réponses se trouvaient dans la FAQ. Ce qui m’a ennuyé : ils ne lisaient pas ma FAQ. Il se trouve qu’ils avaient cherché sur le site internet, mais je n’avais pas mis la FAQ à cet endroit. C’est une erreur facile à faire. Je suis proche du projet et je n’ai jamais eu besoin d’utiliser moi-même la FAQ, je n’avais donc pas remarqué qu’elle n’était pas présente en ligne. Beaucoup de problèmes sont dus à ce piège : les auteurs ne se mettent pas à la place des utilisateurs.
Le revers de ce problème est d’avoir la documentation disponible uniquement en ligne. Certains projets ne distribuent pas la documentation avec les livrables du projet, ou incluent une version médiocre de la documentation.
Le moteur de recherche Solr, par exemple, a un excellent wiki qui sert à la documentation du projet. Malheureusement, la documentation liée au téléchargement comporte 2200 pages de Javadoc d’API auto-générées. Au final, la seule documentation pour l’utilisateur est une unique page de tutoriel.
Le langage PHP n’est distribué avec aucune documentation. Si vous voulez la documentation, vous devez aller sur une page séparée pour les obtenir. Pire, seule la documentation du cœur est disponible au téléchargement, sans les annotations utiles des utilisateurs (voir « Ne pas accepter les remarques des utilisateurs » plus bas), et ce n’est pas le même format facile à parcourir que celui qui est disponible en ligne.
Les projets open source ne peuvent pas supposer que les utilisateurs ont accès à Internet quand ils ont besoin de la documentation. Le mode avion existe toujours. De toute façon, vous ne souhaitez pas que l’utilisateur dépende uniquement du fait que votre site web est disponible ou non. Au moins à deux reprises durant les derniers mois, le wiki de Solr était indisponible au beau milieu de ma journée de travail alors que je recherchais des informations sur un problème de configuration épineux.
Un projet qui fait les choses bien est Perl et son dépôt de module CPAN. La documentation pour chaque module est disponible soit à search.cpan.org ou metacpan.org dans un format hypertexte facile à lire. Pour la consultation hors-ligne, la documentation de chaque module est intégrée dans le code lui-même, et quand le module est installé sur le système d’un utilisateur, la documentation locale est créée sous forme de pages man. Les utilisateurs peuvent aussi utiliser « perldoc Module::Name » pour obtenir la documentation depuis le shell. En ligne ou hors-ligne : c’est votre choix.
Ce problème est généralement une erreur des paquageurs, pas des auteurs du projet. Par exemple, sur Ubuntu Linux, la documentation du langage Perl est séparée, ce sont des paquets optionnels pour le langage lui-même. L’utilisateur doit savoir qu’il doit explicitement installer la documentation de la même façon que le langage principal ou il n’y aura pas accès quand il en aura besoin. Ce compromis de quelques mégabites d’espace disque au détriment de la documentation à portée de main de l’utilisateur dessert tout le monde.
Il n’y a pas de meilleur moyen d’obtenir l’attention potentielle d’un utilisateur, ou d’illustrer un usage correct, qu’avec des captures d’écran judicieuses. Une image vaut mieux qu’un long discours, c’est encore plus important sur Internet parce que vous ne pouvez obtenir d’un lecteur de lire plus de quelques centaines de mots en tout.
Les captures d’écran accompagnant le texte sont inestimables pour guider l’utilisateur voulant faire les choses au mieux. Une capture d’écran lui permet de comparer visuellement ses résultats à ceux de la documentation et va le rassurer d’avoir exécutée la tâche correctement ou l’aidera à trouver facilement ce qui ne va pas.
Il est de plus en plus commun de trouver des vidéos sur le site internet d’un projet pour en donner un aperçu, et c’est génial. Tout autant que le fait d’avoir une vidéo pour chaque étape d’un processus complexe. Le projet Plone, par exemple, a un site entier dédié aux tutoriels vidéos. Cependant, les vidéos ne peuvent pas remplacer les captures d’écran. Un utilisateur veut voir rapidement l’allure des captures d’écran sans s’arrêter devant une vidéo. Les vidéos n’apparaissent également pas dans une recherche Google Image, à l’inverse des captures d’écran.
Pour les projets basés sur du code, l’analogue des captures d’écran sont de bons et solides exemples du code en action. Ces exemples ne devraient pas être abstraits, mais directement issus du monde réel. Ne créez pas d’exemples bateaux plein de « nom de la démo ici » et lorem ipsum. Prenez le temps de créer des exemples signifiants avec une histoire d’utilisateur qui représente la façon dont votre logiciel résout un problème.
Il y a de bonnes raisons de vous embêter avec des problèmes de maths en classe. Ils permettent d’appliquer ce que vous avez appris.
Disons que j’ai écrit un module d’un robot Web, et que j’explique la méthode follow_link. Je pourrais montrer la définition de la méthode ainsi :
$mech->follow_link( text_regex => $regex_object, n => $link_index );
Mais admirez à quel point cela devient évident en ajoutant de la réalité dans l’exemple.
# Suit le 2e lien où la chaîne de caractères « download » apparait
$mech->follow_link( text_regex => qr/download/, n => 2 );
Les noms des variables $regex_object et $link_index sont maintenant compréhensibles par le lecteur.
Bien entendu, vos exemples ne doivent pas être aussi brefs. Comme Rich Bowen du projet Apache le souligne, « Un exemple correct, fonctionnel, testé et commenté l’emporte sur une page de prose, à chaque fois. »
Montrez autant que possible. L’espace n’est pas cher. Créez une section dédiée aux exemples dans la documentation, ou même un livre de cuisine. Demandez aux utilisateurs d’envoyer du code qui fonctionne, et publiez leurs meilleurs exemples.
Vous avez les hyperliens. Utilisez-les.
Ne pensez pas, parce que quelque chose est expliquée dans une certaine partie de la documentation, que le lecteur a déjà lu cette partie, ou bien qu’il sait où elle se trouve. Ne vous contentez pas de signaler que cette partie du code manipule des objets frobbitz. Expliquez brièvement lors du premier usage de ce terme ce qu’est un objet frobbitz, ou donnez le lien vers la section du manuel l’expliquant. Encore mieux, faites les deux !
Il arrive trop souvent que l’écriture de la documentation soit rédigée à partir du point de vue de son auteur, alors que es nouveaux utilisateurs ont besoin de documentation d’introduction pour les aider.
L’introduction devrait être une page séparée de la documentation, idéalement avec des exemples qui permettent à l’utilisateur de réussir quelques manipulations avec le logiciel. Pensez à l’excitation que vous ressentez quand vous commencez à jouer avec un nouveau logiciel et qu’il vous permet de faire quelque chose de cool. Faites que ça arrive aux nouveaux utilisateurs également.
Par exemple, un package graphique pourrait présenter une série de captures d’écran qui montrent comment ajouter des données dans un fichier, comment faire intervenir le grapheur, et ensuite montrer les graphes obtenus. Une bibliothèque de codes pourrait montrer quelques exemples d’appels à la bibliothèque, et montrer le résultat obtenu. Pensez simplicité. Offrez une victoire facile. Le texte devrait introduire les termes aux endroits appropriés, avec des liens vers une documentation plus détaillée sur le long terme.
Un document de démarrage séparé donne à l’utilisateur une compréhension rapide du logiciel. Il garde aussi les explications d’introduction en dehors de la partie principale de votre documentation.
Les développeurs doivent écouter les utilisateurs de la documentation. La chose évidente est d’écouter les suggestions et requêtes des personne qui utilisent activement votre logiciel. Quand un utilisateur prend le temps d’écrire un mail ou de poster quelque chose comme « ça aurait pu m’aider à mieux installer le programme s’il y avait eu une explication ou des liens au sujet des pilotes de la base de données », prenez ce message au sérieux. Pour chaque utilisateur vous envoyant un mail pour un problème, vous devez vous attendre à ce que dix utilisateurs silencieux aient le même problème.
Il est important d’écouter les problèmes des utilisateurs et d’en chercher les causes. S’ils ont souvent des problèmes pour effectuer des mises à jour groupées de bases de données, la première chose à faire est d’ajouter une question à la FAQ (vous avez bien une FAQ, n’est-ce pas ?) qui traite de ces questions-là. Cependant, la question peut aussi indiquer que la section traitant des mises à jour de base de données n’est pas assez claire. Ou peut-être qu’il n’y a pas de référence à cette section depuis la vue d’ensemble introductive du document, avec pour conséquence que vos utilisateurs ne pensent jamais à lire le reste du manuel.
En plus d’aider plus de gens à découvrir à quel point votre projet est utile, ça diminuera aussi la frustration de la communauté déjà existante. Si votre liste de diffusion, forum ou canal IRC est remplie de personnes qui posent toutes les mêmes questions idiotes (ou pas si idiotes) au point que tout le monde devient lassé d’y répondre, sachez reconnaître que ce sont des questions récurrents pour la FAQ, et mettre les réponses à un endroit facile à trouver aidera tout le monde à se concentrer sur des choses plus amusantes.
Gardez aussi un œil sur les questions des forums externes. Consultez les sites comme StackOverflow régulièrement, et placez une Google Alert sur votre nom de projet pour être maintenu au courant des discussions concernant votre projet sur Internet.
Si votre projet a une base d’utilisateur assez grande, il peut être judicieux d’incorporer les commentaires des utilisateurs directement dans la documentation. Le meilleur exemple que j’ai pu voir est celui donné par PHP. Chaque page de la documentation permet aux utilisateurs authentifiés d’ajouter des commentaires sur la page, aidant ainsi à clarifier certains points ou ajoutant des exemples qui ne sont pas dans la documentation principale. L’équipe PHP laisse aussi le choix au lecteur de lire la doc avec ou sans les commentaires des autres utilisateurs.
Aussi pratique cela soit-il, cela nécessite de la maintenance. Les commentaires doivent être éliminés de temps en temps pour éviter la prolifération. Par exemple, la page de la documentation PHP sur comment lancer PHP depuis la ligne de commande inclut 43 commentaires d’utilisateurs qui remontent à 2001. Les commentaires écrasent la documentation principale. Les commentaires devraient être archivés ou supprimés, tout en incluant les points les plus importants dans la documentation principale.
Un wiki est également une bonne approche. Cependant, si votre wiki ne permet pas à l’utilisateur de télécharger toutes les pages en une seule grosse archive (cs. point n°3 ci-dessus), alors vos utilisateurs sont à la merci de votre connexion internet et du serveur hébergeant le projet.
Au minimum, chaque projet de logiciel nécessite une liste de fonctionnalités et une page de captures d’écran pour permettre au potentiel utilisateur intéressé de savoir pourquoi il devrait l’essayer. Aidez l’utilisateur, comparant les différents paquets à utiliser, à voir pourquoi cela vaut la peine de prendre le temps de le télécharger et de l’installer.
Les images sont un bon moyen de faire cela. Votre projet devrait avoir une page « Captures d’écran » qui montre des exemples de l’outil en action (cf. point n°5 ci-dessus). Si votre projet se résume uniquement à du code, comme une librairie, alors il devrait y avoir une page d’exemples montrant ce code utilisant le projet.
Trop souvent, les auteurs de logiciels utilisent des systèmes de documentation automatisés pour faire leur travail. Ce système automatisé rend les choses plus facile à maintenir, mais il ne supprime pas la nécessité d’un travail d’écriture humain.
Le pire des cas concerne le changelog, qui n’est rien de plus qu’un dump des messages de commit du système de gestion de version, mais sans un résumé qui l’explique. Un changelog devrait lister les nouvelles fonctionnalités, les problèmes résolus et les incompatibilités potentielles. Sa cible est l’utilisateur final. Un log de commit est pratique et simple à générer pour les personnes travaillant sur le projet, mais ce n’est pas ce dont l’utilisateur a besoin.
Jetez un œil à cette page de la documentation de Solarium, une interface PHP pour le moteur de recherche Solr. Tout d’abord, l’avertisemment prend la moitié supérieure de l’écran, ne donnant aucune information au lecteur. Ensuite, il n’y a vraiment rien de véritablement descriptif sur la page que la liste des noms de fonctions. Il n’y a aucune explication sur les différentes méthodes, ni de liens indiquant où trouver l’explication. Les pages générées automatiquement sont jolies, et elles pourraient ressembler à de la documentation, mais elles n’en sont pas.
L’attitude du type RTFM (Read The Freaking Manual) est mauvaise pour votre projet et votre documentation.
C’est le summum de l’arrogance que de croire que tous les problèmes qui ont trait au fait que quelqu’un ne sache pas utiliser votre logiciel sont de la faute de l’utilisateur.
Même s’il est probablement vrai que les utilisateurs peuvent trouver leurs réponses dans votre documentation mais ne le font pas, il est stupide de penser que c’est la faute de l’utilisateur. Peut-être votre documentation est-elle mal écrite, ou difficile à lire, ou présente mal à l’écran. Peut-être avez-vous besoin d’améliorer la section « Mise en route » (lien #8 ci-dessus) qui explique ce que le logiciel a pour but de faire. Peut-être que certaines parties d’information nécessitent d’être répétées à de multiples endroits de la documentation.
N’oubliez pas que les nouveaux utilisateurs de votre logiciel peuvent arriver sur votre projet sans rien n’en savoir. Votre documentation doit faire de son mieux pour s’assurer que cette ignorance soit facilement résolue.
Je suis sûr que vous avez déjà eu affaire à quelques-uns de ces problèmes listés ci-dessous, et peut-être que pour d’autres vous n’y avez pas pensé. Faites-nous connaître les problèmes que vous avez rencontrés dans les commentaires ci-dessous, sachant qu’il ne s’agit pas de pointer du doigt certains projets en particulier.
Surtout, j’espère que si vous reconnaissez un problème dans la documentation de vos projets, vous prendrez la peine d’améliorer la situation. Heureusement, améliorer la documentation est une manière idéale de faire participer les nouveaux arrivants dans votre projet. On me demande souvent : « Comment puis-je commencer dans l’open source », et je recommande des améliorations dans la documentation comme une bonne manière de commencer.
Faites-en sorte que ce soit aussi facile que possible, pour les novices comme les plus anciens, de savoir où il est nécessaire de travailler la documentation. Créez une liste des tâches, par exemple dans votre système de suivi des bogues, qui explique ce qui a besoin d’être amélioré. Soyez précis dans ce que sont vos besoins. Ne vous contentez pas de dire que vous avez besoin d’exemples, sans plus de précision. Créez des tâches spécifiques, comme « ajoutez un code d’exemple sur le fonctionnement de la tâche X », « ajouter une capture d’écran du générateur de rapports » ou « ajouter des informations de dépendances au fichier README/LISEZ-MOI ». Les contributeurs souhaitent aider mais trop souvent ils ne savent pas par où commencer.
La documentation n’est pas la partie la plus glamour d’un projet open source, et pour la plupart d’entre nous ce n’est pas amusant. Mais sans une bonne documentation, les utilisateurs ne sont pas servis comme ils pourraient l’être, et votre projet en souffrira sur le long terme.
Crédit photo : Rosalux Stiftung (Creative Commons By)
Le 1er juillet prochain (J-4, donc !), Google Reader fermera ses portes.
Lancé en 2005, ce service permettait aux utilisateurs d’organiser et de lire des flux d’actualités (appelés « flux RSS ») issus de multiples sites en un seul endroit.
Plusieurs dizaines (centaines ?) de milliers d’utilisateurs se retrouvent donc « victimes » de cette fermeture annoncée il y a trois mois. Cela nous amène à nous poser deux questions :
De nombreuses applications libres permettant de lire des flux RSS ont vu leur développement s’accélérer ces derniers mois. Certaines nous ont semblé être d’excellentes alternatives à Google Reader. Mais comment les faire connaitre au grand public ? Comment inciter les utilisateurs a tester et valider une solution libre, plutôt que de foncer tête baissée dans la gueule grande ouverte d’un autre service privé ? Feedly, Digg, Yahoo!, et même … AOL (!) sont sur les rangs pour exploiter vos données sous forme de publicité classique ou de revente à des tiers. Pour au final fermer le service dans quelques mois ?
À sa modeste échelle, Framasoft annonce donc la mise en place de Framanews, un service de lecture de flux RSS basé sur le logiciel libre Tiny Tiny RSS. Il ne s’agit pas ici d’en faire un « concurrent » de Google Reader, qui ne résoudrait pas la question de la centralisation des données, mais bien de proposer à tout un chacun de pouvoir évaluer une alternative libre et gratuite, sans publicité, sans exploitation de vos données personnelles et que vous pouvez vous-même installer (pour une académie, un centre de recherche, etc.).
Notez bien que le projet est en bêta, que les inscriptions s’ouvrent peu à peu (afin de nous permettre de dimensionner l’infrastructure technique), et que nous prévoyons d’améliorer la documentation sur l’installation[2].
Pour vous faire patienter, nous vous proposons ici une interview de Luc, le sympathique et dynamique bénévole[3] qui est en charge de la mise en place de ce service.
Bonjour Luc, peux-tu te présenter ?
Bonjour. Mmh, c’est toujours dur de se présenter, mais je vais tenter quand même. Je suis un geek libriste de pas loin de 30 ans, grand fan des manchots, du Dr Who, de livres (romans, bds), du nombre 42 et des vannes pourries. On me connaît parfois sous le pseudo Sky sur le grand Ternet mais c’est plutôt rare (en dehors de LinuxFr ou de framalang, je ne sors pas beaucoup de mon lecteur de flux RSS)
Mon parcours fut assez mouvementé : 2 facs, 3 DUT, 1 Licence, clerc d’huissier, assistant de sénateur et maintenant administrateur systèmes et réseaux dans l’équipe Lothaire de l’Université de Lorraine… C’est moi qui ai appris à Jean-Claude Van Damme à faire le grand écart :)
Mon premier contact (sans le savoir) avec les logiciels libres date de l’époque où Free envoyait un cd contenant divers logiciels dont un truc qui s’appelait “Suite Mozilla” si je me souviens bien. Quand est sortie la première version de Firefox, j’y ai tout de suite adhéré, mais je n’étais pas encore prêt. C’est en 2005 qu’un ami d’enfance m’a dit « Essaye Linux, c’est vachement bien ! », ce qui m’a poussé à acheter un magazine contenant un cd d’installation d’OpenSuse. Là-dessus mon ami m’a dit « Pff, mais prends donc une Debian, ça déchire[4] ! ». Et là c’était fini, j’étais pris au piège et je n’ai plus quitté Debian, ni tout ce qui a rapport au libre. 3 ans plus tard, j’entrais en DUT d’info. Encore 5 ans de plus et j’organisais les Journées Perl 2013 (qui ont eu lieu à Nancy les 14 et 15 juin dernier).
Je fais actuellement partie de Lorraine Data Network, FAI associatif issu de l’essaimage de FDN qui milite pour un Internet Libre Décentralisé et Neutre en encourageant les gens à héberger eux-même leurs services, ou tout du moins à le faire chez des personnes de confiance… un peu comme quand Framasoft propose Framadate, Framapad, Framacalc et tous les autres Framaservices, non ? ;)
Tu t’es proposé pour mettre en place et animer le projet Framanews. Mais qu’est-ce donc que Framanews ?
Framanews est un lecteur de flux RSS en ligne. Un flux RSS est un fichier contenant les articles du site du flux dans un format normalisé qui permet d’afficher ces articles dans un lecteur, sans tout l’« emballage » du site. Cela permet de suivre l’actualité du site en question, sans y aller, ou parfois d’avoir juste un résumé des articles, ce qui permet de choisir si ça vaut le coup d’aller faire un tour sur le site. Si un certain nombre de médias du Web parlent de la fin du flux RSS car dépassé par Twitter, Google+ et consorts, je trouve qu’au contraire, c’est un excellent moyen de choisir ses sources d’informations plutôt que se laisser enfermer dans un bulle constituée de « on sait mieux que toi ce qu’il te faut ». Je ne suis certainement pas le seul à penser ainsi, vu le tollé qu’a soulevé l’annonce de la fermeture de Google Reader et le nombre de lecteurs de flux libres qu’on a vu (re)surgir ça et là : Kriss Feed, Miniflux, Leed, etc. Et surtout Tiny Tiny RSS (ttrss pour les intimes) qui a vu son développement repartir de plus belle et qui sert de base à Framanews.
J’ai légèrement forké Tiny Tiny Rss pour le franciser au maximum (mais il y a encore des bouts de texte qui m’ont échappé), certains textes comme les emails ne passant pas par le module d’internationalisation.
Mais Framanews, c’est aussi un projet « éducatif », pour (re)faire découvrir les flux RSS et présenter une alternative aux sites propriévateurs (merge de propriétaire et privateur, pour dérouter les trolls) comme (bientôt feu) Google Reader, Feedly et consorts. Le pourquoi du flux RSS, les spécificités de ttrss (interface mobile, partage de flux…), un mode d’emploi, tout ça est expliqué sur la page d’accueil du projet (surtout dans la FAQ).
Pourquoi avoir choisi ce projet-là, dans tous les framacartons[5] possibles ?
Parce que j’aime les flux RSS et que je suis un peu opportuniste : je me suis dit que la fermeture de GReader était une bonne occasion de prêcher la bonne parole du Libre. Aussi parce que je connais plutôt pas mal ttrss pour l’avoir installé pendant longtemps sur mon serveur. Je me sers de Framanews maintenant, pour voir les problèmes tout de suite et être encore plus motivé à les résoudre : vos problèmes sont aussi mes problèmes, soyez sûrs que je m’en occupe ;)
Ah ! Non ! C’est un peu court jeune homme !
On pouvait dire… oh ! Dieu ! … bien des choses en somme…
En variant le ton, —par exemple, tenez :
Agressif : « moi, monsieur, si j’avais un tel etherpad,
Il faudrait sur le champ que je le mette à jour[6] ! »
Amical : « mais il n’y a pas de css framasoft :
laissez-moi donc vous faire un boilerplate ! »
Et puis, il faut bien commencer quelque part :D
Techniquement, la mise en place a été plutôt difficile, peux-tu nous en dire plus sur les coulisses de ce projet ?
Oulà ! Alors, en ce moment, le ttrss tourne sur un des serveurs de Framasoft qui héberge d’autres services, avec la base de données sur un autre serveur, qui sert aussi à faire tourner le script de mise à jour des flux. Je n’avais au départ que le serveur Framasoft pour jouer. J’ai utilisé une base MySQL puisqu’elle était déjà installée dessus, mais avec l’ouverture progressive de la bêta, j’ai vu que ça n’allait plus du tout. Le serveur souffrait de surcharge, et pourtant c’est une bête de course. J’ai donc tuné la base MySQL, mais les problèmes sont revenus quelques jours après. J’ai ensuite tenté quelques essais infructueux de conversion des données MySQL au format PostgreSQL pour une migration en douceur, mais j’ai dû me résoudre à demander à nos courageux testeurs de migrer eux-mêmes leurs comptes, à coup d’export des flux et des préférences. Après quelques jours de répit, de divers essais de réglage des paramètres du script de mise à jours, le serveur était de nouveau en surcharge. C’est Nassim Kacha - un ami lui aussi sysadmin qui s’occupe de pas mal de base de données au boulot - qui m’a montré que la surcharge était due à des accès disques trop lents. Framasoft m’a donc fourni un nouveau jouet : un vps (Serveur Privé Virtuel) avec un disque en SSD. Tout allait bien jusqu’à ce que certains utilisateurs abusent un peu du nombre de flux : plus de 5% du total de flux pour UN utilisateur (représentant 0,5% du nombre d’utilisateurs)…
Dallas, à côté de la saga Framanews, c’est Martine à la plage !
Donc, pour l’instant, le service reste en “beta” ? Quelles sont les limitations ?
Malheureusement, oui. Suite au dernier épisode (trop de flux pour certains utilisateurs), nous avons décidé de limiter le nombre de flux par personnes (je suis en train d’écrire un système de quota de flux pour ttrss). Le système de cache de ttrss a été un peu modifié pour garder le cache plus longtemps (ce qui réduit la vitesse de mise à jour) et on ouvre les inscriptions au compte-goutte, pour nous permettre d’augmenter les capacités de la plateforme au fur et à mesure. Je n’ai pas envie que tout s’écroule de nouveau ! Une fois que j’aurais dimensionné correctement les besoins (un serveur = xxx utilisateurs), je vais tenter de transformer notre petite base de données en un cluster PostgreSQL, on repart pour des tests et on pourra enfin ouvrir les vannes en grand ! (ou pas)
Ceci dit, tant qu’on est en beta, je ne m’interdis pas de loucher vers d’autres applications de lecture de flux RSS en ligne qui pourraient mieux tenir la charge.
Si tout se passe bien au niveau technique, la prochaine limitation risque d’être le nombre de serveurs que Framasoft pourra louer. Rappelons-le, Framasoft est une association qui ne vit que par les dons de ses sympathisants. C’est pourquoi je vous invite à faire un petit tour sur http://soutenir.framasoft.org (je l’avais dit que j’étais opportuniste ! Hop, pub :D).
Au bout du compte, pourquoi utiliser Framanews plutôt que Feedly, Netvibes ou autre ?
C’te bonne blague ! Parce que c’est libre, tiens !
Mais aussi parce que Framasoft — et donc par définition Framanews aussi — cherche à libérer les internautes, en leur faisant découvrir des services qu’ils peuvent installer eux-mêmes, dans leur placard, sur leur serveur dédié, chez un hébergeur mutualisé associatif, sur un raspberry collé au dos de leur chat… De plus, nous respectons votre vie privée : la seule information dont on se sert, c’est votre adresse mail pour vous tenir au courant des évolutions du services et autres maintenances, et juste pour ça. Je pourrais aussi parler de la qualité de ttrss, de sa fonctionnalité qui permet de partager les articles que l’on aime sur un flux public[7], du superbe plugin que j’ai développé de mes blanches mains pour faciliter la navigation dans les flux (ok, c’est juste un fork d’un autre plugin)…
Je pense que la meilleure raison d’adopter Framanews, c’est de l’essayer et de comparer :)
Comment vois-tu l’avenir de ce projet ?
Moi et les autres membres de Framasoft sur une plage de sable blanc avec suffisamment d’argent pour racheter Google. Ah c’est pas payant ? Zut alors !
Je verrais bien un espace de partage des flux publics[8] des framanewseurs, un compteur des instances de ttrss que les gens auront montées parce qu’on leur en a donné envie…
Un petit mot pour la fin ?
Internet n’est pas compliqué, Internet est ce que vous en faites.
Rappel des principaux liens :
Crédit photo : Danny Sullivan (Creative Commons By)
[1] ou tout autre intermédiaire, Framasoft compris.
[2] Les utilisateurs sous Windows souhaitant tester le logiciel en standalone (sur leur poste de travail plutôt qu’en ligne) peuvent même télécharger notre WebApp TT-RSS, mise à jour pour l’occasion.
[3] S’il avait su dans quoi il mettait les doigts, il ne serait peut-être pas venu, d’ailleurs…
[4] Et c’est bien vrai !
[5] Les Framacartons ?! http://lite.framapad.org/p/framatools
[6] Oui, la mise à jour sur le champ a pris du retard à cause de Framanews, je sais, je sais.
[7] Twitter, c’est tellement 2012 !
[8] un flux public Framanews a une URL unique et tarabiscotée. Il faut que la personne vous la communique, sinon vous ne la trouverez jamais ! Par bonheur, les raccourcisseurs d’URLs existent, ce qui donne par exemple pour mon flux public : http://fiat-tux.fr/sh/LucPublRSS