Cela fait un long moment que je n'ai rien publié sur mon blog. Du coup, aujourd'hui alors que je nettoyais les commentaires indésirables laissés sur mon blog (j'ai de gros problèmes de spam et j'ai l'impression que l'antispam dotclear ne fonctionne qu'une fois sur deux), j'ai pris l'initiative d'écrire un petit billet pour faire part de mon investissement récent dans le projet Replicant.

Mon premier « smartphone » a été un Neo FreeRunner, que j'ai vaguement présenté dans un billet précédent. Pourtant, j'avais des problèmes de batterie qui se déchargeait trop vite. Armé de mon fer à souder pour CMS, j'ai entrepris d'effectuer un Autonofix, mais… sans succès : j'ai fini par endommager la puce GSM du FreeRunner. Du coup, il n'était plus utilisable comme téléphone pour tous les jours.

J'ai finalement choisi d'acheter un HTC Dream, qui tourne donc avec un noyau Linux et Android. Le problème, me direz-vous, c'est qu'Android bien que 100% libre (qu'on ne me dise pas qu'Android n'est pas totalement libre, c'est faux) nécessite des librairies et firmwares non-libres qui sont spécifiques à chaque appareil. Par exemple, pour le HTC Dream, on ne peut quasiment rien faire avec uniquement le code libre: pas d'audio, pas de GSM ni de 3G, bref rien.

Pourtant, un projet (en fait, c'est plutôt un développeur et une petite communauté autour) nommé Replicant tend à produire une version 100% libre d'Android pour le plus grand nombre de téléphones, tablettes, etc, qui fonctionnent sous Android. Et le HTC Dream est un des téléphones des mieux supportés par Replicant. Pour avoir une idée de l'état de la prise en charge des appareils pour lesquels Replicant fournit des images, vous pouvez consulter http://trac.osuosl.org/trac/replica....

Le HTC Dream est donc bien supporté par Replicant : seuls quelques éléments assez négligeables sont absents, tels que l'appareil photo ou les accéléromètres. C'est Replicant en version 2.2 (qui est basée sur CyanogenMod 6 qui est basée sur Android 2.2 FroYo) qui tourne sur le HTC Dream. Pourtant, certains points restent très négatifs, comme l'absence d'un chargeur de démarrage (un genre de BIOS pour le matériel embarqué) libre ou encore le fait que le modem a accès à la RAM principale du téléphone et à d'autres choses gênantes comme le GPS.

J'ai donc installé Replicant sur mon HTC Dream et non sans peine : pour faire tourner Android 2.2, la mémoire flash (NAND) doit-être repartitionnée pour laisser une plus grande place au système.

Après plusieurs semaines d'utilisation, j'étais déjà relativement présent sur le canal IRC #replicant sur irc.freenode.net et j'ai commencé à faire quelques petites choses pour aider un peu, vu l'énorme quantité de travail qu'il reste. Ayant toujours rêvé (et je ne dis pas de bêtises, j'ai toujours voulu le faire) compiler Android depuis le code source, j'ai téléchargé le code source de Replicant et l'ai compilé. Il y avait des erreurs de compilation, auxquelles j'ai trouvé solutions : et hop, ma première contribution au code de Replicant : corriger les erreurs de compilation ! J'ai aussi écrit des scripts pour mettre en place la liaison réseau par USB afin d'avoir internet sur l'appareil sans utilise le WiFi (qui demande un microcode non-libre). Enfin, j'ai voulu utiliser le SDK Android pour écrire des applications, mais il n'est disponible qu'en version 32 bits, alors que mon ordinateur est un 64 bits : j'ai donc modifié tout ce qu'il fallait pour à la fois pouvoir compiler Replicant sur un système 64 bits sans librairies de compatibilité ou autre mais aussi pour avoir un SDK en 64 bits (avec tous les outils qui vont avec, adb, fastboot, etc). Après quelques temps, tout cela fonctionnait (j'avais commencé à documenter la marche à suivre mais c'est vraiment un gros travail et je n'ai pas eu le courage de tout reprendre pour bien documenter), mais il restait de nombreuses erreurs de compilation du SDK, que j'ai corrigé afin d'avoir quelque chose qui fonctionne. Du coup, mes corrections ont été intégrées au code de Replicant et hop, une version 100% libre du SDK Android (sans les API non-libres de Google) !

L'étape d'après a été de regarder le code bas-niveau, tel que le code qui touche directement au hardware. Jusque-là, seul GNUtoo, le développeur principal du projet, avait apporté des améliorations à cette partie là du code (au sein du projet Replicant), pourtant la plus essentielle. Ma première contribution au code bas-niveau a été d'activer le contrôle du volume lors des appels et d'activer le support des adaptateurs permettant de brancher des jacks 3.5mm : pour des écouteurs. Passé cette étape, je suis vraiment devenu développeur Replicant et j'ai commencé à y consacrer pas mal de temps.

Depuis, j'ai apporté un certain nombre de choses à Replicant, et dernièrement, la majorité de ce que je fais pour le projet tourne autour de la prise en charge du Nexus S, le nouveau smartphone de Google. L'avancement de sa prise en charge est disponible sur http://trac.osuosl.org/trac/replica.... Heureusement, je suis entouré de personnes formidables et compétentes pour m'aider et me conseiller !

Le développement et la diffusion de Replicant dépend d'un effort communautaire et volontaire : c'est grâce à vous que le projet pourra se développer afin de permettre la réalisation d'un système Android entièrement libre pour le plus grand nombre de smartphones, tablettes et autres ! Ainsi, toute forme d'aide serait fortement appréciée, et les moyens d'aider le projet ne manquent pas :

• Aider à faire connaitre Replicant, soit sur Internet en utilisant des réseaux sociaux tels que identi.ca ou directement en parlant du projet avec des personnes qui pourrait-être intéressées
• Installer Replicant si votre appareil est supporté
• Tester ce qui fonctionne et ce qui ne fonctionne pas dans les nouvelles versions ou tester la téléphonie dans votre pays si cela n'a pas encore été fait
• Proposer des logiciels libres pour Android dans le dépôt F-Droid, l'alternative libre au Market d'Android
• Écrire de la documentation et des tutoriels quand à l'utilisation de Replicant
• Si vous êtes un développeur, nous rejoindre afin d'achever le remplacement des parties manquantes sur les périphériques que nous supportons déjà
• Si vous êtes un développeur, lancez-vous dans la tâche de faire fonctionner Replicant sur d'autres périphériques (e.g. smartphones récents, tablettes, etc)

Le meilleur moyen de commencer à s'investir dans le projet est sans doute de venir sur IRC : #replicant sur irc.freenode.net de vous présenter et de venir discuter (en anglais de préférence).

Ce billet est disponible en Français au début de l'article et en Anglais à la fin. / This post is available in French at the beginning of the article and in English at its end.

Version Française

Lorsque l'on décide d'utiliser un système d'exploitation libre, l'une des premières choses qui rebute est sans doute l'absence du lecteur Flash, et donc l'absence de possibilité de regarder les vidéos de sites de partage de vidéos tels que YouTube. Pourtant, une multitude de solutions existent. Cet article présente donc dix alternatives libres au lecteur Flash pour regarder les vidéos de YouTube :

1. Gnash : Il est possible d'utiliser le lecteur Flash libre Gnash pour visionner les vidéos de YouTube. Si vous rencontrez l'erreur « An error occurred, please try again later », reportez-vous à la documentation Fedora francophone pour résoudre le problème.
2. Firefox4 + HTML5 + WebM : Le format libre WebM est utilisé sur YouTube depuis une demande de la part de la Fondation pour le Logiciel Libre (FSF) et est supporté nativement par Firefox4, à travers la balise HTML5 <video>. Pour l'utiliser, rendez-vous sur http://www.youtube.com/html5 et cherchez/regardez vos vidéos en ajoutant &webm=1 à la fin de l'URL.
3. FlashVideoReplacer : FlashVideoReplacer est un add-on pour firefox qui récupère l'adresse de la vidéo youtube à partir de l'URL de la page et qui l'incruste dans la page, permettant ainsi de la regarder sans Flash. L'add-on est libre et est disponible ici : http://www.webgapps.org/addons/flas....
4. Greasemonkey + Viewtube/Youtube Moteado/Youtube without Flash Auto : Greasemonkey (http://www.greasespot.net/) est également un add-on libre pour firefox permettant d'exécuter des scripts javascript en plus de ceux proposés par le site visité. Dans le cas de YouTube, cela peut permettre de récupérer l'adresse de la vidéo et de l'injecter dans la page, à la manière de FlashVideoReplacer. Il faudra donc, en plus de Greasemonkey installer un script. Il en existe là aussi plusieurs, tels que ViewTube, Youtube Moteado ou encore YouTube without Flash Auto (ces scripts sont bien entendu également libres).
5. cclive (libquvi) : cclive est un logiciel permettant de télécharger des vidéos de divers sites proposant du contenu multimédia avec Flash. Il utilise la librairie libquvi, qui se charge de récupérer l'adresse de la vidéo. Son utilisation est très simple : cclive URL.
6. quvi + mplayer : La librairie libquvi propose également un binaire exécutable que l'on peut associer à un logiciel tel que mplayer pour directement lire la vidéo, mplayer se chargeant de la mise ne cache. Utilisation : quvi URL --exec "mplayer %u".
7. quvi + totem : Il est également possible d'intégrer la librairie libquvi à totem-pl-parser, composant du lecteur de vidéo de GNOME totem. En voici une vidéo de démonstration : http://download.paulk.fr/noflash/to.... Pour l'installation, il faudra recompiler totem-pl-parser avec l’argument --enable-quvi au script configure.
8. m.youtube.com : YouTube propose un site pour les appareils Android permettant de consulter les vidéos de YouTube sans Flash, au format 3GP. Ce format est lisible par des décodeurs libres. Ce site, http://m.youtube.com/ peut donc être utilisé par tous. Il suffira de cliquer sur « Regarder la vidéo » sur la page de la dite vidéo et d'ouvrir le lien avec son lecteur multimédia favori.
9. nomnom : Nomnom est une interface graphique permettant d'utiliser la librairie libquvi, mêlant un grand nombre de fonctionnalités (dont le téléchargement de vidéos YouTube).
10. youtube-dl : Youtube-dl est un autre outil en ligne de commande permettant de télécharger les vidéos de YouTube.

Voila, comme ça, on ne pourra plus dire qu'il n'y a pas d'alternatives ! Pour ma part, je vous recommande vivement d'utiliser tout ce qui touche à la librairie libquvi (dont je suis un modeste contributeur), qui supporte plus de 25 sites web différents.

English version

When you decide to use a free operating system, one of the first problems is that Flash Player is not available, so it's impossible to watch videos from video sharing websites like YouTube. Although this problem, a lot of solutions exist to watch YouTube videos. This article will list 10 alternatives to the non-free Flash Player to watch YouTube videos :

1. Gnash : It's possible to use the free Flash player Gnash to watch YouTube videos. If you have the "An error occurred, please try again later" error, check out the French Fedora documentation to solve this problem.
2. Firefox4 + HTML5 + WebM : The free (as in freedom) format WebM is now used on YouTube after a demand from the Free Software Foundation and is natively supported by Firefox4, with the <video> HTML5 element. To use it, go on http://www.youtube.com/html5 and add &webm=1 to the end of the search/watch URLs.
3. FlashVideoReplacer : FlashVideoReplacer is an add-on for Firefox that gets the address of the youtube video from the page's URL and embeds it in the page, allowing the user to watch the video without Flash. The add-on is free software and is available from here : http://www.webgapps.org/addons/flas....
4. Greasemonkey + Viewtube/Youtube Moteado/Youtube without Flash Auto : Greasemonkey (http://www.greasespot.net/) is also a free add-on for Firefox that allows the user to run javascript scripts over the scripts proposed by the visited page. In the case of YouTube, it can permit to get the address of the video and to embed it on the page, the same way as FlashVideoReplacer. So, in order to make this work, you'll need Greasemonkey plus a script to do that for YouTube. Plenty scripts exist to do that job: ViewTube, Youtube Moteado or YouTube without Flash Auto (all these scripts are free).
5. cclive (libquvi) : cclive is a tool to download videos from various video sharing websites that use Flash to display their video content. cclive uses the libquvi library, which gets the video address. cclive is very simple to use: cclive URL.
6. quvi + mplayer : The libquvi library also offers an executable binary that we can associate to a software like mplayer to directly play the video. Usage: quvi URL --exec "mplayer %u".
7. quvi + totem : It's also possible to integrate the libquvi library to totem-pl-parser, which is a component of the GNOME default video player: totem. Here is a demonstration video: http://download.paulk.fr/noflash/to... (sorry for the horrible French accent). To install it, you'll have to build totem-pl-parser with the --enable-quvi argument to the configure script.
8. m.youtube.com : YouTube has a website to offer its videos to Android devices (which don't have Flash) through 3GP videos. This format is playable by free decoders. So this site, http://m.youtube.com/ can be used by anyone. All you have to do is to click "Watch video" on the page of the video and to open the link with your favourite video player.
9. nomnom : Nomnom is a graphical interface using the libquvi library, with a lot of functionalities (including YouTube videos downloading).
10. youtube-dl : Youtube-dl is another CLI tool to download YouTube videos.

That's it, now you can't say that there is no alternative to Flash player to watch YouTube videos ! As for me, I advise you to use whatever using libquvi (I'm a modest contributor to the library), which supports more than 25 different websites.

Présentation

J'utilise déjà depuis un moment Jabber/XMPP, protocole libre permettant de faire de la messagerie instantanée. Il existe différentes implémentations libres du protocole XMPP à la fois au niveau des serveurs et des clients de connexion. Pour ma part, j'utilise le serveur Jabberd2 sur mon serveur auto-hébergé. J'utilise divers clients sur mes machines mais je souhaitais également mettre en place une interface web pour utiliser mon compte jabber directement dans mon navigateur web.

Depuis quelques temps déjà, le projet Jappix propose une telle interface web et même plus, puisque le projet tend à faire office de réseau social (tel que Movim, qui utilise lui aussi Jabber/XMPP). J'ai donc souhaité mettre en place Jappix sur mon serveur auto-hébergé.

Installation du serveur BOSH : Punjab

La première étape consiste à configurer un serveur BOSH, qui est un relai entre le serveur XMPP et l'application web (qui ne peut pas directement contacter le serveur XMPP). Sur certains serveurs Jabber, les XEP 124 et 206 (extensions du protocole XMPP décrivant la mise en place de BOSH) sont intégrées, mais sur d'autres, tels que Jabberd2 (que j'utilise), il faut utiliser un logiciel dédié à la tâche. J'ai choisi d'utiliser Punjab, écrit en python. J'utilise Debian 6.0 sur mon serveur auto-hébergé, mais il n'existe pas (encore) de paquet officiel pour punjab. Souhaitant garder mon serveur « propre », je ne souhaitais pas installer manuellement Punjab dans un recoin de la mémoire sans pouvoir le désinstaller proprement et simplement par la suite. J'ai donc opté pour la création du paquet debian de Punjab. Ce n'est pas la première fois que je me lance dans ce genre de choses, mais je tiens à préciser que je ne suis absolument pas un packager Debian chevronné et que la qualité de mon paquet reste, à mon avis, assez médiocre. Quoiqu'il en soit, il fonctionne et j'ai également ajouté à Punjab un script de démarrage : /etc/init.d/punjab. Le paquet en question peut-être téléchargé à l'adresse : http://download.paulk.fr/jappix/pun.... Il est normalement construit pour Debian 6.0. Après l'installation, il suffira de lancer punjab en exécutant la commande : /etc/init.d/punjab start.

Installation et configuration de Jappix

Maintenant que le serveur BOSH est en place, il ne reste plus qu'a installer Jappix. Il est préférable d'installer l'extension GD de php sur le serveur web et de régler la variable "suhosin.get.max_value_length" à 1000000 dans la configuration de l'extension suhosin (si elle est installée). Il faut ensuite télécharger l'archive de Jappix 0.4 disponible sur le site du projet, la décompresser dans un répertoire servi par le serveur web et y appliquer des droits permissifs (0770 par exemple). En se connectant sur l'adresse correspondant au dossier où Jappix a été décompressé, l'installation devrait se lancer. Bien que l'installation est assistée, il faudra veiller à bien cocher le paramètre « Utiliser un proxy » et à renseigner la case « Hôte BOSH » avec une valeur adaptée à partir de : http://127.0.0.1:5280/http-bind (changez 127.0.0.1 par l'hôte accueillant le serveur BOSH). Les paramètres de configuration pourront également être modifiés via le « Gestionnaire » de l'application.

Maintenant que tout est correctement configuré, Jappix devrait maintenant-être opérationnel.

Mes modifications apportées à Jappix

Mon premier avis sur Jappix : c'est beau, ça marche plutôt bien, mais il reste encore quelques détails que je souhaiterais peaufiner. Alors du coup, vu que le tout est sous licence libre, pourquoi se gêner ? Je maitrise encore à peu près la programmation en PHP et Javascript, qui sont majoritairement utilisés par jappix.

J'ai donc décidé de faire passer les boutons initialement présents en bas de la liste des contacts en haut de celle-ci : en effet, lorsque ces boutons sont en bas, les menus qui apparaissent lorsque l'on clique dépassent du bas de la page, ce qui force l'utilisateur à dérouler la page pour avoir accès au contenu des dits menus. Pas très pratique donc.

J'ai mis en ligne les fichiers concernés par ce changement : il sont présents dans l'archive http://download.paulk.fr/jappix/jap... (qu'il suffit de décompresser à la racine de Jappix, en écrasant les fichiers déjà existants).

Fedora, comme la plupart des distributions GNU/Linux, contient une part (plus ou moins importante) de composants non-libres. Il s'agit la plupart de temps de micro-code nécessaire à certains drivers pour fonctionner correctement avec le matériel. Ces composants, bien que propriétaires, sont inclus par défaut dans Fedora car ils peuvent-être cruciaux, par exemple pour un utilisateur dont la connexion à Internet passe par un chipset WiFi demandant un blob. Ces bouts de code (que l'on nomme firmwares, ou blobs) peuvent-être présents dans le système sous la forme de fichiers séparés (que l'on trouve généralement dans /lib/firmware) mais il peuvent également être inclus au noyau (sous la forme de grands tableaux de chiffres présents dans le code source).

Vous vous demandez peut-être pourquoi je pense qu'il est important de ne pas utiliser ces petites parties de code (et donc de chercher à utiliser un système 100% libre). Mon argument principal est que, ces micro-logiciels contenant certaines instructions pour communiquer avec le matériel, le fait qu'ils ne sont pas libres est une entrave délibérée à la compréhension du fonctionnement interne du matériel. Je pense que de telles entraves ne sont pas admissibles. Alors bien sûr, lorsque j'ai vraiment besoin du matériel (par exemple d'un blob pour le WiFi, si c'est le seul moyen de connexion à Internet disponible), je vais m'en servir, parce-que je pense qu'utiliser une toute petite partie de logiciel non-libre me sera plus bénéfique que de ne rien faire, mais c'est un avis personnel. De plus, si on considère que beaucoup de schémas de l'électronique du matériel que l'on utilise ne sont pas disponibles, on peut également penser qu'il s'agit d'une entrave à notre compréhension du matériel que l'on utilise et que c'est inacceptable. Pourtant, j'utilise quand-même ce matériel.

Mais bien entendu, lorsque ces blobs non-libres ne sont pas ou peu nécessaires, il est meilleur d'utiliser un système 100% libre. Mais si votre machine contient du matériel pour lequel de tels blobs sont nécessaires, il ne vous sera probablement pas bénéfique d'installer un système 100% libre.

Si vous souhaitez savoir si votre matériel sera correctement supporté sans ces composants non-libres, il vous est possible :

• de consulter la base de données h-node, qui regroupe des informations sur le support matériel des systèmes 100% libres
• d'essayer un des systèmes 100% libres, comme Trisquel, sans l'installer

Le matériel problématique sera le plus souvent : les cartes WiFi et certaines cartes graphique :

• Les cartes ATI/AMD demandent, pour la plupart, un blob pour fonctionner correctement avec le pilote libre radeon
• Les cartes nVidia ne requièrent aucun blob avec le pilote nouveau mais celui-ci est encore à un stade expérimental

Maintenant que tout ceci est dit, passons à la pratique. On va commencer par ajouter le dépôt du projet Linux-libre, contenant notamment un noyau sans blobs.

Toutes les opérations sont à effectuer sous l'utilisateur root :

# rpm --import http://linux-libre.fsfla.org/pub/linux-libre/SIGNING-KEY.linux-libre
# rpm -i http://linux-libre.fsfla.org/pub/linux-libre/freed-ora/freed-ora-release.noarch.rpm

On va ensuite recréer le cache de la liste des paquets :

# yum makecache

Le dépôt est maintenant installé et configuré. L'étape suivante consiste à lister tous les paquets non-libres installés sur le système. Le dépôt Linux-libre dispose d'un paquet entrant en conflit avec les paquets non-libres de Fedora. Pour l'installer :

# yum install freed-ora-freedom

YUM devrait échouer en listant les paquets créant le conflit. Par exemple :

--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec microcode_ctl
[…]
--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec xorg-x11-drv-ati-firmware
--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec rt73usb-firmware
[…]
--> Traitement du conflit : freed-ora-freedom-6-1.noarch entre en conflit avec alsa-firmware

Pour les supprimer, on utilise la commande :

# yum remove *-firmware microcode_ctl

Pourtant, le paquet freed-ora-freedom ne pourra toujours pas s'installer. En effet, les paquets du noyau Linux (kernel, kernel-headers) entrent eux aussi en conflit : il s'agit du noyau Linux contenant des blobs. On va donc installer la version Linux-libre, qui ne contient pas ces blobs :

# yum install kernel-libre kernel-libre-firmware perf-libre

Il faudra ensuite redémarrer la machine et booter sur le kernel-libre (en le sélectionnant dans le GRUB). On vérifie que l'on a bien démarré sur le kernel-libre (cherchez -libre dans le nom du kernel) :

$ uname -r
2.6.35.11-libre.83.fc14.i686

Si tout c'est bien déroulé et que l'ordinateur reste utilisable, on peut supprimer les paquets du kernel d'origine :

# yum remove kernel

Il faudra penser à jeter un œil au fichier /boot/grub/menu.lst pour éventuellement y corriger les erreurs et s'assurer que le kernel-libre démarrera automatiquement.

Vous pouvez maintenant installer le paquet freed-ora-freedom, qui vous garantira qu'aucun paquet non-libre ne sera réinstallé :

# yum install freed-ora-freedom

Si le paquet kernel-headers a été installé, il sera nécessaire de le replacer par kernel-libre-headers pour l'installation de freed-ora-freedom :

# yum remove  kernel-headers

Les dépendances de kernel-headers seront supprimées : gcc glibc-devel glibc-headers libtool. On va maintenant installer kernel-libre-headers et les paquets précédemment supprimés :

# yum install  kernel-libre-headers gcc glibc-devel glibc-headers libtool

Il sera maintenant possible d'installer le paquet freed-ora-freedom.

J'avais, il y a pas mal de temps ajouté à mes favoris le site Ékopédia, découvert par hasard au fil d'une recherche, en me disant qu'il faudrait que je prenne le temps de le découvrir plus en détail… Et ce jour est arrivé, pas plus tard qu'aujourd'hui.

Comme le nom du site le suggère légèrement, il s'agit d'un wiki traitant des bonnes pratiques que nous devrions adopter pour le respect de l'environnement. Le tout est disposé en plusieurs catégories principales, accessibles dans la partie en haut à droite de la page d'accueil. Au premier abord, ce wiki ne semble pas vraiment différent d'une quelconque autre source sur les bonnes pratiques liées au respect de l'environnement. Oui mais voila : il s'agit d'un wiki, le contenu est donc produit par différents contributeurs volontaires. Il est même explicitement souhaité que n'importe-qui puisse contribuer, un peu comme c'est le cas sur Wikipedia. Mais la « ressemblance » ne s'arrête pas là : alors qu'Ékopédia pourrait-être placé sous une licence assez restrictive (un bon vieux « © Tous droits réservés » par exemple), les créateurs du site ont choisi la licence libre Creative Commons BY-SA, qui garantit que le contenu sera librement utilisable, modifiable et re-distribuable avec une condition de partage sous licence identique : il s'agit du Copyleft.

On trouve donc un WIki entièrement collaboratif et sous licence libre, à l'image de Wikipedia ! Je ne peux que féliciter l'initiative. Pourtant, l'engagement d'Ékopédia ne s'arrête pas là : en naviguant sur la page dédiée à l'utilisation de l'Informatique, j'ai trouvé un lien vers la page Logiciels Libres du wiki. J'ai été plutôt surpris et me suis empressé de lire l'article. Tout est parfaitement expliqué : l'historique avec le projet GNU, la définition du logiciel libre de Stallman et, c'est avant tout le thème du WIki, ce que le logiciel libre peut apporter dans la lutte pour la défense de l'environnement. Je n'ai trouvé aucun élément à redire, tout est propre, clair et précis.

Je suis heureux de voir que de telles initiatives existent, mêlant avec brio les enjeux du numérique, au travers de la licence, du modèle de collaboratif de création du contenu et de l'engagement pour les Logiciels Libres ainsi que les enjeux environnementaux, qui restent quand-même le sujet principal d'Ékopédia. J'ai vraiment envie de dire bravo, car les personnes ayant mis ce projet en place ont bon sur toute la ligne !

Cela fait un an que je m'auto-héberge. Pourtant, il y a quelques semaines encore, mes services Internet n'étaient pas accessibles en continu, la raison étant que j'utilisais mon ordinateur « de tous les jours » pour héberger ces services.

Forcément, comme celui-ci consomme beaucoup d'énergie et fait beaucoup de bruit, il était exclu de le laisser allumé en permanence.

Avoir son serveur auto-hébergé plus souvent éteint qu'en ligne pose plusieurs problèmes :

• Le contenu mis à disposition n'est pas souvent en ligne, ce qui gêne (forcément) les visiteurs.
• Des mails peuvent-être perdus si aucun serveur secondaire n'est mis en place.
• Le site hébergé est peu recommandable (par exemple, pour l'inscription sur un Planet : il est évident que recommander un site souvent éteint en l'incluant sur le Planet n'est pas génial).

Bref, ce ne fut pas une partie de plaisir. Heureusement pour moi, un « bon samaritain » auto-hébergé m'a proposé d'utiliser son serveur comme serveur mail secondaire.

Il y a peu de temps, je me suis rendu compte que cette situation ne pouvait plus durer, parce-que le fait de ne pas avoir un serveur allumé en permanence pose beaucoup trop de problèmes à mes visiteurs, à l'heure où je souhaite que mes réalisations, telles que Neoinput, mes vidéos de démonstration du Neo FreeRunner ou encore mon dépôt Fedora se diffusent.

Du coup, comment améliorer cette situation ? Deux solutions se profilent :

• Arrêter de m'auto-héberger et utiliser, par exemple, les services d'hébergement gratuits de mon FAI.
• Acheter une machine connectée en permanence à l'Internet pour diffuser le contenu que je souhaite mettre à disposition et pour héberger mes services Internet.

Bon, évidemment, je n'ai pas vraiment envisagé la première solution, je reste convaincu de la nécessité de s'auto-héberger.

Il ne reste plus qu'à trouver une machine assez peu couteuse à l'achat et ne consommant que peu d'électricité. Heureusement pour moi, la page http://wiki.auto-hebergement.fr/dok... est bien fournie et m'a aidé à trouver la machine qui me convenait.

Lire la suite…

← billets précédents — page 1 de 6