Blog d'un enthousiaste du logiciel libre, utilisateur de GNU/Linux et auto-hébergeant ses services Internet.
Intervention à l'Open Bioduille Camp 33 #2

Ce Samedi 15 mai (et peut-être aussi une partie du dimanche), je prends part à la Crypto-Party organisée durant l'Open Bidouille Camp 33 #2 par les membres du LabX, le Hackerspace de Bordeaux, de l'ABUL et de Giroll, les groupes d'utilisateurs de logiciels libres présents dans la région. Ce sera pour moi l'occasion de présenter les problématiques liées à la vie privée et à la sécurité dans le domaine des appareils mobiles connectés aux réseaux de téléphonie mobile.

Si vous êtes dans le coin, ce sera très certainement un moment convivial pour échanger autour du logiciel libre (une Install-Party est d'ailleurs prévue au cours de l'évènement et d'autres projets autour du libre seront présents, comme OpenStreetMap). Pour ceux que ça peut intéresser, je serai tout à fait disposé à présenter Replicant (dont je suis développeur principal). Par ailleurs, j'aurai avec moi un Goldelico GTA04, l'appareil mobile (soyons fous, appelons-le téléphone) qui succède à l'Openmoko GTA02 et je serai ravi d'en faire un démonstration, avec les derniers progrès du port de Replicant sur ce dernier!

 ✍ aucun commentaire   ➪ aucun rétrolien 
Interview à LinuxFR à propos du projet Replicant

Voici une interview donnée à LinuxFR.org qui détaille plusieurs aspects du projet Replicant et de ma contribution à celui-ci.

Peux-tu te présenter en quelques mots ? Qu'est-ce qui t'as conduit à devenir développeur au sein du projet Replicant ?

Tout juste diplômé du Baccalauréat scientifique, je suis utilisateur de logiciels libres depuis à peu près cinq ans. Replicant est d'ailleurs le premier projet d'envergure auquel je contribue comme développeur et c'est au travers de ce projet que j'ai réellement appris à programmer.

Tout a commencé avec la recherche d'un téléphone portable libre, qui m'a vite conduit au canal IRC du projet Replicant où l'on m'a conseillé l'OpenMoko GTA02, dit FreeRunner, que j'ai utilisé pendant quelques temps pour revenir à la recherche d'un autre candidat (après avoir détérioré le modem du GTA02 suite à une soudure ratée). J'ai finalement opté pour un HTC Dream, qui a été mon premier téléphone Android. Rapidement, j'ai essayé de compiler les sources de Replicant pour ajouter quelques petites modifications et finalement me rendre utile par la suite en permettant la compilation du SDK. Puisque de nombreuses tâches étaient à réaliser, je me suis essayé au vrai développement, et ça m'a plu. Grâce à l'aide précieuse du développeur principal du projet, Denis 'GNUtoo' Carikli, j'ai vite appris beaucoup sur la programmation, l'utilisation de Git, etc. Au bout d'un moment, j'ai pris les devants en portant Replicant en version 2.3 sur le Nexus S, et par la suite sur de nombreux autres appareils, pour finalement en arriver aujourd'hui à avoir beaucoup trop d'appareils, de responsabilités et de travail, mais j'apprécie toujours autant de contribuer au projet, d'autant que j'en suis le premier utilisateur quotidien.

Quels sont les enjeux du projet Replicant, et de manière plus générale du logiciel libre dans le domaine de la téléphonie portable ?

D'un point de vue général, les téléphones portables peuvent-être considérés comme le « rêve de Staline », pour reprendre l'expression de Richard Stallman. En effet, il s'agit là de dispositifs permettant un contrôle et une surveillance de l'individu comme jamais cela n'avait été possible auparavant.

La première raison est qu'il s'agit avant tout d'un outil de communication qui n'offre aucune garantie de sécurité : d'une part les communications sur le réseau GSM sont connues pour être faiblement sécurisées et d'une autre part, l’opérateur téléphonique garde trace de tous les messages et appels effectués par l'utilisateur et les transmet, automatiquement ou sur demande aux gouvernements intéressés.

Ainsi, un historique complet des communications de chaque utilisateur est présent dans une base de données qu'il ne contrôle pas. Mais ce n'est là qu'un problème parmi d'autres. Considérons maintenant la possibilité pour les opérateurs de géolocaliser les utilisateurs du réseau à tout instant : cela est possible en comparant les dates d'arrivée des signaux émis par un téléphone vers plusieurs antennes-relais, on peut déterminer sa position. De telles informations peuvent alors être collectées dans une base de données, retraçant tous les déplacements des individus transportant leurs téléphones portables avec eux. Il s'agit bien là d'une réalité puisqu'il est avéré que ceci est bel et bien en place chez certains opérateurs, particulièrement américains.

Du point de vue de l'appareil, et non plus du réseau, le composant qui gère le dialogue avec le réseau GSM, le modem, exécute du logiciel qui n'est pas libre. De fait, il n'offre aucune garantie de sécurité, en plus de bafouer la liberté de ses utilisateurs. Tout particulièrement, c'est quand le modem est connecté à d'autres dispositifs, comme le microphone, le GPS ou la mémoire, vive ou de stockage du téléphone que le problème prend de l'ampleur. Rien ne garantit que le modem ne tire profit de ces dispositifs sous la commande du réseau. Et il existe bel et bien des exemples de tels comportements, où le logiciel du modem a été altéré à distance afin d'utiliser le microphone d'un téléphone pour surveiller l'utilisateur, en convertissant le dit téléphone en dispositif d'écoute à distance et ce en utilisant une porte dérobée du logiciel du modem.

Enfin, si les logiciels exécutés sur le téléphone ne sont pas libres, le même problème se pose, puisqu'il est alors tout à fait possible que les agissements de ces logiciels soient commandés à distance ou qu'il remplissent une fonction malveillante. Là encore, il existe bel et bien des exemples concrets de tels logiciels.

Il apparaît donc de réels enjeux liés à l'utilisation de la téléphonie mobile : d'une part ceux liées à l'utilisation du réseau et qui ne peuvent-être résolus que par la mise en place d'une législation garantissant le respect de la vie privée et, d'autre part, des problèmes qui découlent du fait que les logiciels utilisés sur les téléphones ne sont pas libres. C'est donc sur ce dernier point que le logiciel libre peut apporter une solution et c'est bien dans cette optique que s'intègre le projet Replicant, qui vise à développer un système d'exploitation entièrement libre pour les téléphones portables ou smartphones. Il s'agit d'un dérivé d'Android, puisque la mouture AOSP (pour Android Open Source Project) du système est libre, même si elle ne permet pas de fonctionner réellement sur des téléphones Android sans les pilotes propriétaires nécessaires pour dialoguer avec le matériel. Le projet Replicant remplace donc ces composants propriétaires par des alternatives libres afin que le téléphone soit effectivement utilisable.

Pour autant est-ce que Replicant permet de résoudre l'ensemble des problèmes posés par la téléphonie mobile ?

Bien évidemment, utiliser un téléphone exécutant Replicant ne permet pas d'empêcher l'opérateur d’espionner ses communications ni de localiser le téléphone en temps réel : les problèmes liées à l'opérateur qui existent « naturellement » de par l'utilisation du réseau restent entiers, même avec Replicant qui n'est autre qu'un système d'exploitation. Puisque Replicant est un système entièrement libre, il assure qu'aucune fonction malveillante n'est exécutée par le système (alors que c'est le cas avec certains dérivés d'Android pré-installés sur les téléphones que vendent les opérateurs), en plus d'offrir à l'utilisateur les libertés essentielles qui définissent le logiciel libre. Cela n'est bien entendu valide que si les applications installées avec Replicant sont elles-aussi libres.

Pourtant, il reste bel et bien, dans la plupart des cas, du logiciel propriétaire qui s'exécute sur le téléphone avec Replicant : le chargeur de démarrage (bootloader en anglais) est le plus souvent propriétaire, mais il est aussi souvent signé, c'est-à-dire qu'il ne peut pas être remplacé par un logiciel libre. Il n'est donc pas possible sur les modèles concernés de démarrer son téléphone sans passer par du logiciel propriétaire. En plus du processeur principal, un téléphone portable intègre, tel un ordinateur classique, plusieurs périphériques, qui exécutent tous des programmes non-libres, que ce soit la carte WiFi ou encore le modem (ces logiciels sont parfois chargés par le processeur principal et parfois pré-installés dans le périphérique). Là encore, Replicant ne permet pas de résoudre ces problèmes, mais il existe le projet OsmocomBB qui est un programme libre s'exécutant dans le modem de certains téléphones, qui offre alors une solution aux problèmes soulevés par l'utilisation de programmes non-libres dans le modem (hélas les rares téléphones supportés sont vieux et ne sont pas encore pleinement utilisables). Quelques efforts sont à remarquer concernant les périphériques WiFi, avec la récente libération du micro-code de quelques cartes Atheros HTC.

Puisque Replicant doit faire avec des programmes non-libres qui s'exécutent sur le modem, les modèles sur lesquels Replicant est porté sont choisis (en partie) en fonction de l'isolation du modem : il faut autant que possible veiller à ce que le modem ne puisse pas accéder à la mémoire du téléphone, au GPS, au microphone, etc.

Replicant ne permet donc pas de libérer totalement certains téléphones Android, mais c'est une étape de taille vers le respect de la liberté de l'utilisateur dans la téléphonie mobile.

Quels sont les défis techniques, les objectifs déjà atteints et les évolutions du projet ?

Tout d'abord, un gros changement a eu lieu au cours des quelques dernières années, qui nous apporte un certain réconfort : il est désormais possible d'installer une version modifiée d'Android sur la plupart des téléphones Android. De nombreux constructeurs ont fait l'effort de fournir des chargeurs de démarrage (bootloaders) qui permettent à l'utilisateur d'installer un autre système tel que Replicant.

C'est déjà une belle avancée comparé à la situation des débuts d'Android. Ainsi, nous n'avons plus rencontré ce problème lors de la sélection des futurs modèles sur lesquels porter Replicant. De fait, les procédures d'installation sont largement simplifiées (plus besoin d'exploiter une faille du noyau pour gagner les privilèges root afin d'installer une version modifiée). C'est donc un ennui de moins pour nous et une accessibilité accrue pour les utilisateurs souhaitant installer Replicant.

Les critères de choix de la sélection des nouveaux modèles ont donc évolué. Nous regardons maintenant essentiellement deux aspects : le contrôle que le modem exerce sur le reste du téléphone (qui doit être le plus restreint possible) et la quantité de logiciels propriétaires qui est nécessaire pour faire fonctionner le téléphone.

Le premier point est assez difficile à évaluer puisque nous ne pouvons pas vérifier si le modem est effectivement en mesure d'accéder à des zones sensibles (GPS, audio, données, RAM), mais nous avons parfois des preuves que c'est le cas, comme pour les puces Qualcomm. Nous privilégions donc d'autres plate-formes, par exemple Exynos de Samsung, que l'on retrouve dans de nombreux téléphones de la marque, ou encore OMAP de Texas Instruments.

Concernant la quantité de logiciels propriétaires nécessaire, cela varie très largement d'un modèle à l'autre, mais pour de nombreux modèles, les éléments nécessaires au fonctionnement minimal (audio, graphiques 2D, téléphonie, etc) de l'appareil sont soit déjà libres, soit facilement remplaçables. Dans tous les cas, porter Replicant sur un nouveau téléphone n'est pas une mince affaire (qui d'ailleurs est détaillée au travers d'un guide sur le wiki du projet) et de nombreux logiciels doivent être écrits pour faire fonctionner le matériel du téléphone. C'est là que se situe l'essentiel des défis auxquels doivent faire face les développeurs.

Écrire un remplacement libre d'un composant propriétaire implique une longue procédure d'ingénierie inverse. Il s'agit le plus souvent de décoder, d'interpréter, de comprendre et d'implémenter un protocole ou une série d'instructions qui ne sont nulle part documentés. Un exemple remarquable d'un tel travail est l'écriture d'une implémentation libre du protocole utilisé par le modem des téléphones Samsung. Grâce à l'aide de nombreux développeurs (pas forcément affiliés à notre projet), nous avons pu écrire une implémentation libre de la mise en route et du protocole du modem, initialement pour le Nexus S et très vite élargie à de nombreux autres modèles (Galaxy S, Galaxy Tab, Galaxy Nexus, Galaxy S2, Galaxy S3…), ce qui explique pourquoi nous préférons porter Replicant sur des téléphones Samsung : la charge de travail est considérablement réduite puisque le protocole du modem est déjà connu et implémenté. En effet, puisque les logiciels qu'exécute le modem ne sont pas libres, le protocole utilisé pour communiquer avec le processeur principal n'est pas forcément standard ni documenté.

Avec le temps, le projet CyanogenMod a également commencé plusieurs initiatives de remplacement du code non-libre présent dans plusieurs téléphones (entre autres les Samsung), qui nous bénéficient directement. L'avantage pour eux est de pouvoir corriger les bugs ou les problèmes rencontrés avec les composants propriétaires, pas toujours conformes aux définitions des interfaces propres à Android, mais aussi de faire suivre le code sur de nouvelles versions d'Android, sans attendre les mises à jour du constructeur. Le code écrit par le projet Replicant est également parfois réutilisé dans CyanogenMod (c'est le cas des modules audio et camera du Galaxy S2) et peut à cette occasion être amélioré par les développeurs CyanogenMod : le projet Replicant bénéficie en retour des améliorations ! Ce genre de partage de code bidirectionnel enrichit alors chacun de nos projets.

Pour les évolutions très récentes du projet, nous avons pu finaliser et annoncer le programme de donations au projet Replicant via la Free Software Foundation (Fondation pour le Logiciel Libre), qui se charge de collecter et mettre à notre disposition les fonds. L'argent ainsi récolé nous permettra d'acheter de nouveaux appareils (téléphones, tablettes) mais également de contribuer aux frais de déplacement des développeurs au nombreux événements du logiciel libre, afin de pouvoir y présenter Replicant.

Pourtant, le projet a également grand besoin de nouveaux contributeurs : nous ne sommes que deux développeurs à ce jour, de moins en moins disponibles pour le projet. Alors que j'envisage très prochainement un cycle préparatoire, le second développeur du projet, Denis 'GNUtoo' Carikli doit gérer en plus d'un travail en entreprise, la contribution à de nombreux autres projets de logiciels libres essentiels, tels que Coreboot ou OsmocomBB. Si la contribution au projet Replicant vous intéresse, n'hésitez pas à nous contacter via notre canal IRC, #replicant sur irc.freenode.net ou encore via notre liste de diffusion.

L'évolution récente de la situation du logiciel libre dans la téléphonie mobile, tant au niveau logiciel que matériel constitue-t-elle un pas de plus vers la liberté ?

Plus ou moins récemment, de nombreuses évolutions ont eu lieu, d'une part avec l'apparition de nouveaux systèmes d'exploitation dits libres visant les téléphones mobiles et d'une autre part avec l'apparition de nouveau matériel, soit comme support des nouveaux systèmes libres, soit se présentant eux-mêmes comme libres ou ouverts.

Abordons tout d'abord Firefox OS : le système d'exploitation mobile de la fondation Mozilla, issu du projet Boot2Gecko, apporte une perspective technologique innovante : faire le pari des langages du web pour réaliser tout un système mobile. L'avantage résidant dans la rapidité et l'optimisation avérée de ces langages web. Bien entendu, l'ensemble du système n'est pas écrit avec les technologies du web, mais seulement la partie applications et framework. Pour faire court, les langages du web sont à Firefox OS ce que Java est à Android. Dans les deux cas, le noyau utilisé est le noyau Linux et une couche d'abstraction matérielle est nécessaire entre le noyau et le langage natif du système (langage web pour Firefox OS, Java pour Android). C'est bien entendu dans cette couche d'abstraction que réside l'implémentation et le support du matériel, qui constitue la majeure partie des composants non-libres que Replicant s'efforce de remplacer (de fait, les composants que le projet Replicant remplace ne sont pas des briques de Java mais des couches d'abstraction en C ou C++). Les développeurs de Firefox OS ont fait le choix d'utiliser les mêmes interfaces et les mêmes API qu'Android pour leur couche d'abstraction matérielle. Ceci permet en effet de porter plus facilement vers Firefox OS les téléphones Android, mais aussi de pouvoir réutiliser les composants non-libres (et donc non adaptables pour d'éventuelles interfaces spécifiques à Firefox OS) des téléphones Android. De fait, les problèmes auxquels Replicant doit faire face sur Android se retrouvent être les mêmes sur Firefox OS. Finalement, seules les parties déjà libres d'Android sont réécrites dans Firefox OS, avec les langages du web plutôt qu'en Java. L'intérêt et l'avancement vers la liberté de l'utilisateur est donc très minime. Puisque Android est mature et parfaitement utilisable, il n'y a pour nous aucun avantage fondamental à réaliser un dérivé totalement libre de Firefox OS.

Pourtant, Firefox OS a produit, en plus d'un système, un certain nombre de téléphones en partenariat avec la société espagnole Geeksphone, déjà connue pour ses téléphones Android libellés comme ouverts. Si ces nouveaux téléphones semblent eux aussi être libellés comme libres et ouverts, la réalité n'est sur les grandes lignes pas bien différente des téléphones Android : les modèles Firefox OS de Geeksphone utilisent les plate-formes de Qualcomm, réputées pour offrir un contrôle écrasant au modem sur le processeur principal. De plus, ces plate-formes demandent de nombreux composants non-libres sur le processeur principal (les couches d'abstraction matérielles) pour que Firefox OS, comme Android, fonctionne effectivement.

Le second nouveau système mobile apparu récemment est Ubuntu Touch, qui matérialise la volonté de Canonical de dériver Ubuntu sur les plate-formes mobiles. La situation est quasiment identique à Firefox OS : Ubuntu Touch utilise également les couches d'abstraction matérielles d'Android, à quelques finesses près (Ubuntu Touch est bien un système GNU/Linux et ne tient pas tout d'Android). Le problème fondamental qu'est le support du matériel reste le même, d'autant plus que, pour le moment, Ubuntu Touch ne fonctionne que sur des téléphones Android qui eux-même ne peuvent fonctionner sans un certain nombre de composants non-libres. Certains de ces modèles sont pris en charge par Replicant : il serait donc possible de voir apparaître un dérivé entièrement libre d'Ubuntu Touch basé sur les remplacements libres développés par le projet Replicant, à condition que le tout reste assez fluide et utilisable. Mais encore une fois, Android est déjà stable, utilisable et bien en place, et prendre le temps de développer un dérivé entièrement libre d'Ubuntu Touch n'apporterait pas de réel avantage sur le plan des libertés. Là encore, un projet de développement de téléphone, le Ubuntu Edge, support du système Ubuntu Touch, est en cours, au travers d'un appel à contributions de Canonical mais peu de détails sur le matériel et sa compatibilité avec le logiciel libre sont à ce jour disponibles.

D'autres systèmes mobiles, peut-être moins médiatisés ont également fait leur apparition. Après le rachat de Palm par HP, le système WebOS a été peu à peu libéré sous le nom Open WebOS, ce qui a permis le début de l'initiative WebOS-ports, qui effectue le portage de WebOS sur quelques téléphones Android. Là-encore, plusieurs blobs non-libres sont encore utilisés, mais les interfaces Android ne sont plus directement intégrées au système : c'est libhybris qui se charge de faire interface entre les modules Android et le reste du système. WebOS-ports est finalement plus dans la continuité du projet SHR, duquel de nombreux développeurs ont d'ailleurs migré, avec un système de compilation semblable. On peut donc espérer que les développeurs WebOS-ports pourront contribuer à la libération de téléphones comme c'était le cas avec SHR, même si pour l'instant les appareils Android supportés fonctionnent avec des composants non-libres.

Depuis quelques temps déjà, le projet MeeGo, initialement dérivé de Maemo et Moblin est en situation d'échec avec le départ du Nokia du projet, qui avait jusque là construit les quelques téléphones officiellement supportés par le projet (N900, N9). MeeGo demeure soutenu par la Fondation Linux et Intel, mais il semblerait que Tizen, nouveau système également soutenu par la Fondation Linux et développé par Samsung a repris le flambeau. Là encore, il existe peu (voire pas du tout) de téléphones témoins qui permettraient d'évaluer à quel point Tizen est libre et d'envisager un dérivé entièrement libre. Même si le tout semble prometteur et définitivement séparé des interfaces Android que les autres systèmes mobiles dits libres utilisent, il sera sans doute plus fructueux d'évaluer le système lorsqu'un téléphone permettant d'exécuter Tizen sera disponible, ce-qui devrait-être le cas dans le futur d'après Samsung.

Concernant le nouveau matériel particulièrement propice au logiciel libre, on peut noter le Goldelico GTA04, qui est une version améliorée et à jour de la carte de l'Openmoko GTA02 dit FreeRunner, avec un chip OMAP3, qui n'a donc pas d'accélération graphique libre, mais le reste du matériel est tout à fait compatible avec le logiciel libre (même si le firmware non-libre du WiFi doit être chargé par le processeur principal). Le téléphone est distribué sous Debian et SHR peut y être installé, ce qui est alors plus adapté à la téléphonie.

Enfin, le projet Fairphone développe un téléphone qui devrait faire tourner Android mais pour lequel peu de détails techniques sont disponibles. La particularité du Fairphone est de fournir un téléphone socialement équitable, réalisé sans conflits sociaux, de l'extraction des matières premières jusqu'à la vente mais également plus responsable (filière de recyclage) et écologique. L'esprit de transparence du projet semble très propice au logiciel libre et ses membres indiquent clairement leur préférence pour le logiciel libre dans leur produit, même si on peut s'attendre à ce que plusieurs composants non-libres soient tout de même présents.

Quel téléphone est à recommander pour utiliser Replicant avec la plus grande liberté, et d'ailleurs quel téléphone utilises-tu personnellement ?

À ce jour, la meilleure solution pour le respect de la liberté est de ne pas utiliser de téléphone portable du tout, pour les raisons explicitées plus haut. Dans les autres cas, c'est le Goldelico GTA04 qui se révèle être le meilleur candidat, mais il n'est pas encore supporté par Replicant. Les téléphones récemment supportés par le projet sont meilleurs que les anciens au niveau du respect des libertés et, compte tenu des fonctionnalités prises en charge, le meilleur candidat est à ce jour le Galaxy S2.

Pour mon utilisation personnelle, je change régulièrement de téléphone pour m'assurer de leur stabilité au quotidien, parmi les suivants : Nexus S, Galaxy S, Galaxy S2 et Galaxy S3. Ma préférence reste portée sur le Galaxy S2 puisqu'il dispose du plus de fonctionnalités supportées.

Sur quoi travaillent les développeurs en ce moment ? Quelles sont les prochaines avancées prévues ?

Très récemment, l'effort s'est concentré sur le Goldelico GTA04, dont la situation demande un travail technique de haut niveau que nous ne pouvons pas forcément fournir. De fait, ceci entraîne beaucoup de frustration et peu d'avancées réelles. De plus, certaines tâches sont simplement trop complexes à réaliser (particulièrement le protocole de certains GPS).

Globalement, les avancées des prochains mois seront essentiellement consacrées à l'amélioration de la prise en charge des téléphones sur lesquels Replicant tourne déjà, avec une amélioration des fonctionnalités de téléphonie (les appels multiples sont manquants par exemple) ou des aspects spécifiques à certains téléphones, comme la prise en charge de l'appareil photo du Galaxy S3, ou encore le GPS du Galaxy S2. Toute ceci demande beaucoup de travail d'ingénierie inverse et n'est jamais certain d'aboutir à un résultat concret.

Enfin, dernière (et inévitable) question : quelles distribution et quels environnements graphiques utilises‐tu à la maison ?

Une partie des mes ordinateurs utilise Trisquel GNU/Linux, qui est une distribution entièrement libre dérivée d'Ubuntu, mais j'ai récemment été convaincu par les efforts du projet Debian pour être reconnu comme un système entièrement libre : c'est donc ce que j'utilise sur mon ordinateur portable et serveurs. Pour ce qui est de l'environnement graphique, je suis toujours fidèle à GNOME (et GTK+) avec son interface classique (gnome-panel) qui me semble plus adaptée au développement que Gnome-Shell.

Merci pour cet entretien et tes contributions.

 ✍ aucun commentaire   ➪ aucun rétrolien 
Replicant, le système embarqué entièrement libre dérivé d'Android

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.

5.jpg

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.

android_skating.png

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.

banner.png

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.

devices.jpg

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).

 ✍ 3 commentaires   ➪ aucun rétrolien 
10 moyens de regarder YouTube sans logiciels propriétaires / 10 ways to watch YouTube without non-free software

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 : trisquel-gnash.png 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 : youtube-html5.png 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 : flvideoreplacer-screenshot-017.png 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) : Capture-paulk_aldrin__.png 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 : totem-quvi-shot.png 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 : trisquel-gnash.png 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 : youtube-html5.png 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 : flvideoreplacer-screenshot-017.png 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) : Capture-paulk_aldrin__.png 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 : totem-quvi-shot.png 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.

 ✍ 17 commentaires   ➪ un rétrolien 
Installer Jappix 0.4 sur son serveur auto-hébergé

Présentation

XMPP 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

Jappix_logo.png 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

Jappix Buttons on Top

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).

 ✍ 4 commentaires   ➪ aucun rétrolien 
Faire de sa Fedora un système 100% libre

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 :

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.

 ✍ 3 commentaires 

— page 1 de 6

Propulsé par Dotclear — Thème « PaulK »