Entretien avec Paul Kocialkowski, développeur Replicant

68
29
juil.
2013
Mobile

Nous avons la chance d'avoir quelques développeurs qui fréquentent LinuxFR.org (what else ?), dont Paul Kocialkowski (alias PaulK) qui est impliqué dans le projet Replicant, un système d'exploitation libre pour appareils mobiles, dérivé d'Android.

Rappelons que Replicant est un projet souvent cité par Richard Stallman, et qu'il est désormais possible (depuis quelques jours !) de faire des dons via la Free Software Foundation (lien direct pour les impatients ;-) pour permettre principalement aux développeurs d’acquérir les nouveaux appareils sur lesquels porter Replicant mais aussi de participer aux conférences sur le sujet.

Paul a accepté de répondre à quelques questions pour LinuxFR.org ; nous le remercions chaleureusement à la fois pour le temps consacré à cet entretien et pour son implication dans Replicant !

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.

  • # question de n00B

    Posté par . Évalué à 7.

    Un système comme Debian ne pourrait-il pas fonctionner sur un smartphone ? Si les pilotes sont là, il n'y a pas de raison non ? Si oui, pourquoi faire une n-ième distribution plutôt que d'adapter une distrib existante ?

    • [^] # Re: question de n00B

      Posté par . Évalué à 1.

      Ce n'est pas ce que Ubuntu veut faire avec Ubuntu Edge ?

      bon, ok, je -----> []

      http://lsm2013.out.airtime.pro:8000/lsm2013.ogg Ecoutez Radio RMLL !

    • [^] # Re: question de n00B

      Posté par . Évalué à 2.

      Surtout, quel est l' avantage de Android/Linux sur un GNU/Linux ? Je dirais que les applications ne sont pas une raison, surtout si on regarde au niveau de la liberté.
      Je comprendrais tout à fait commencer par une distribution qui ne soit pas tout Debian, comme Maemo l'avait fait, pour ensuite s'intégrer dans une généraliste.

      • [^] # Re: question de n00B

        Posté par (page perso) . Évalué à 6.

        Il existe bien une distribution GNU/Linux pour quelques téléphones : le projet SHR.
        Toutefois, Android a clairement une interface mieux adaptée, plus utilisable, etc.

    • [^] # Re: question de n00B

      Posté par (page perso) . Évalué à 4.

      Le N9 utilise une base debian et ça marche bien :)

  • # projet très intéressant mais...

    Posté par . Évalué à 5.

    Sans un matériel adapté, c'est à dire sans partie matérielle dont l'accès est "privateur" je ne vois pas vraiment ce projet arriver un jour sur un téléphone ou smartphone.

    Mais j'espère me tromper…

    Autre exemple :

    RaspBerry Pi n'est pas libre, mais peu cher, et tout le monde l'utilise.
    OlinuxinO est libre, mais lui n'est connu que d'une très petite minorité, donc …

    http://lsm2013.out.airtime.pro:8000/lsm2013.ogg Ecoutez Radio RMLL !

  • # C'est parfait

    Posté par . Évalué à 4.

    Manque juste la nimage

    • [^] # Les replicants rèvent-ils de licornes en origami ?

      Posté par (page perso) . Évalué à 3.

      C'est triste de te voir si moinsé… pour une fois que la nimage est dans le sujet et une haute référence culturelle ! Bon y a plus qu'à tirer une larme de mélancolie devant tant d'inculture.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

        Posté par (page perso) . Évalué à 1. Dernière modification le 30/07/13 à 13:38.

        Bon y a plus qu'à tirer une larme

        Dans la pluie, c'est encore plus classe.
        ,,,,,,,,,,,,
        ,,,ಥ‿ಥ,,,
        ,,,,,,,,,,,,

        (En bon françois on dirait plutôt «sous» la pluie, je suppose, mais dans ce contexte la traduction littérale est plus parlante)

      • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

        Posté par . Évalué à 7.

        Je doute que les gens qui moinsent les "nimages" prennent encore la peine de les regarder tant elles sont imbéciles.

        Please do not feed the trolls

        • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

          Posté par . Évalué à 3. Dernière modification le 10/08/13 à 20:08.

          Je moinse les commentaires inutiles. Un commentaire de premier niveau contenant uniquement un lien sans indication du contenu et dont j'ai des raisons de penser qu'il est sans rapport avec la dépêche, je trouve ça inutile.

          En quoi est-ce que cela fait de moi un imbécile ?

          • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

            Posté par . Évalué à 4.

            En quoi est-ce que cela fait de moi un imbécile ?

            Explication de texte :
            Ce sont les nimages qui sont (d'habitude) imbéciles, pas les gens.

            Ta question est à côté de la plaque.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

            Posté par . Évalué à 3.

            C'est pour ça que slashdot permet de classer les commentaires en "interesting", ou en "funny".
            Sinon personne ne pensera que "cela fait de toi un imbécile de moinser les commentaires dont tu as des raisons de penser (mais que tu gardes pour toi) qu'il est sans rapport avec la dépêche", car :

            "
            L'imbécile est celui qui parle toujours hors de son verre.
            - Dans quel sens ?
            - Comme ça." Il pointa l'index à pic hors de son verre, indiquant le comptoir. " Lui, il veut parler de ce qu'il y a dans son verre, mais sans savoir comment ni pourquoi, il parle en dehors. Si vous voulez, en termes communs, c'est celui qui fait des gaffes, qui demande des nouvelles de sa charmante épouse au type que sa femme vient de larguer. Je rends l'idée ?
            - Vous la rendez. J'en connais.
            - L'imbécile est fort demandé, surtout dans les occasions mondaines. Il met tout le monde dans l'embarras, mais ensuite il offre matière à commentaires. Dans sa forme positive il devient diplomate. Il parle hors de son verre quand se sont les autres qui ont fait une gaffe, il fait dévier les propos. Mais il ne nous intéresse pas, il n'est jamais créatif, c'est du rapporté, il ne vient donc pas offrir de manuscrits dans les maisons d'édition. L'imbécile ne dit pas que le chat aboie, il parle du chat quand les autres parlent du chien. Il se mêle les pinceaux dans les règles de la conversation et quand il se les mêle bien il est sublime. Je crois que c'est une race en voie d'extinction, c'est un porteur de vertus éminemment bourgeoises. Il faut un salon Verdurin, ou carrément une famille Guermantes. Vous lisez encore ces choses-là, les étudiants ?
            - Moi, oui.
            - L'imbécile c'est Mac-Mahon qui passe en revue ses officiers et en voit un, couvert de décorations de la Martinique. "Vous êtes nègre ?" lui demande-t-il. Et l'autre:" Oui mon général !" Et Mac-Mahon:" Bravo, bravo, continuez !" Et ainsi de suite. Vous me suivez ?
            "

            Continues de moinser avec entrain si cela te chante, personnellement j'utilise en général mes points pour pertinenter …

      • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

        Posté par . Évalué à 0.

        Visiblement les plusseurs ont répliqué

      • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

        Posté par . Évalué à 6.

        Être cultivé pour toi, c'est cliquer sur pertinent si quelqu'un linke une image d'une femme avec un rapport plus que vague avec le sujet d'une news ?

        • [^] # Re: Les replicants rèvent-ils de licornes en origami ?

          Posté par . Évalué à -2.

          "plus que vague" pour celui qui n'a pas cette culture, en effet.

          La fille en photo est une "Réplicante" bienveillante, dans le film "Blade runner" (lien wikipédia - je cite : « Les réplicants sont les androïdes créés et utilisés par les humains dans différents domaines, notamment militaire, mais aussi domestique » ).

  • # FDroid

    Posté par (page perso) . Évalué à 6.

    Un téléphone 100% open source suppose que les applications sont elles aussi open source.
    Pour y parvenir, Replicant inclus le gestionnaire de paquets "FDroid".

    FDroid est une communauté qui cherche, compile, catégorise les nombreuses applis libres pour Android.
    Personnellement je contribue souvent des "recettes" à FDroid.

    Je vous encourage à:
    - Installer FDroid et n'utiliser que des applications venant de FDroid, dans la mesure du possible.
    - Quand vous trouvez une application libre qui n'est pas dans FDroid, écrivez une "recette": Titre + license + description + URL github/svn/etc du code source.

    Have fun!

  • # Bel entretien qui me laisse pourtant sur ma faim

    Posté par . Évalué à 4.

    C'est amusant, j'en retiens la même chose que pour les pilotes graphiques 3D : du libre sans en être jamais totalement, et une situation qui devient de plus en plus floue et complexe.

    Le cas du bootloader signé me semble être le plus surprenant. Autant je comprends qu'un périphérique puisse ne pas avoir de pilote libre, ce qui est une situation assez analogue à celle existant sur PC, autant ne pas pouvoir démarrer le noyau/OS de mon choix sur du matériel que j'ACHETE ça me choque terriblement.

    Si j'ai bien compris il y a 2 situations concernant les périphériques des smartphones : les diaboliques ont un pilote sous la forme d'un firmware intégré au matériel, et les autres ont un pilote logiciel externe comme sur PC.

    C'est bien entendu dans cette couche d'abstraction que réside l'implémentation et le support du matériel,

    Là j'ai bondi. Ce n'est donc pas dans le noyau que se trouvent les pilotes des périphériques ? Décidément ces smartphones sont très différents des PC.

    • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

      Posté par . Évalué à 5. Dernière modification le 17/08/13 à 03:22.

      Si j'ai bien compris il y a 2 situations concernant les périphériques des smartphones : les diaboliques ont un pilote sous la forme d'un firmware intégré au matériel, et les autres ont un pilote logiciel externe comme sur PC.

      Côté vocabulaire :

      • un "firmware" est un code (on dit plutôt un "micro-code" ici) typiquement embarqué dans le périphérique ou bien chargé depuis un fichier (lors de l'initialisation du périphérique, par une opération liée au chargement du pilote, typiquement). Le chargement du micro-code depuis un fichier implique un prix de revient moindre pour le fabriquant du périphérique (une mémoire RAM revenant moins cher qu'une mémoire non volatile, il me semble, à voir).

      • un pilote de périphérique (un "driver" en anglais) est un logiciel exécuté par le système d'exploitation, pour dialoguer avec le périphérique.

      La présence d'un "firmware" intégré au matériel n'est pas un critère de catégorisation en diabolique/sain. Je l'explique ainsi :

      • il y a bien souvent besoin d'instructions (du code à exécuter) et de valeurs numériques (des constantes en programmation) pour rendre opérationnel un matériel numérique évolué. C'est le cas des matériels intégrant des processeurs et autres contrôleurs (on met souvent le préfixe micro devant ces deux mots, on pourrait envisager désormais d'utiliser nano vu l'augmentation de la finesse de gravure). Pour simplifier l'exposé, on intègre les valeurs numériques constantes dans l'expression code. On utilise volontiers l'expression "micro-code" pour parler de ce code.

      • ce besoin de code se traduit par la présence d'une mémoire non volatile (mémoire au contenu figé ou modifiable, c'est selon) accessible par le processeur du périphérique (dans le cadre d'une carte mère de PC, on parlerait du Bios, stocké dans une EEPROM ("Electricaly Erasable Programmable Read Only Memory")). En général, ce circuit intégré de mémoire non volatile est sur le même circuit imprimé que le processeur. Je suppose qu'il existe aussi carrément des processeurs intégrant directement de la mémoire non volatile, ça me semble légitime dans la perspective d'une intégration maximisée (et pour des raisons de limitation du hacking peut-être).

      • ce besoin de code est structurel, lié à l'architecture du périphérique embarquant de la logique cablée (comme le micro-processeur ou micro-contrôleur) qui exploite du logiciel, le micro-code. Une structuration différente pourrait comporter uniquement de la logique cablée (un circuit adapté spécifiquement au besoin du périphérique, n'ayant pas besoin d'un logiciel tiers). Un circuit spécialisé représente un surcoût. On préfère en général l'usage d'un processeur généraliste.

      • un tel code est potentiellement malveillant, risque largement accru s'il est non libre. Cela dépend de l'intention des concepteurs et programmeurs. On notera au passage que le processeur exploitant ce code peut lui-même être malveillant, indépendamment, ce qui renvoie à l'intérêt d'une certification de conformité du processeur par rapport à ses spécifications libres, idéalement (cf mon avis développé ici). Le champ des malveillances possibles est limité structurellement par le contexte numérique auquel s'ajoute ce périphérique. Une carte d'extension dans un PC a accès au bus mémoire et peut directement lire le contenu de la RAM par accès DMA ("direct memory access"), à l'insu du système d'exploitation, alors qu'un périphérique comme un joystick (en le supposant malveillant et évolué) ne le peut pas de cette façon, n'étant relié qu'à travers un bus USB. Pour obtenir cette fonction de lecture de la RAM pour un tel "joystick", il faudrait au moins la complicité du pilote de périphérique côté système d'exploitation.

      • si ce code est modifiable, la malveillance devient adaptative donc le risque est encore accru. Voilà : la possibilité d'une mise à jour du micro code non libre d'un périphérique implique un potentiel de malveillance important. Que ce micro-code soit embarqué dans le périphérique ou qu'il soit chargé depuis un fichier lu grâce au système d'exploitation de la machine, cela est secondaire.

      Note : j'ai lu l'opinion de Richard Stallman sur la question de la malveillance au niveau du "firmware" et je considère que nos avis concordent tout à fait. Je pense qu'il apprécierait mon exposé.

      Edit : la note de ce commentaire commence à -8, cela pourra aider à se fonder un avis sur la pertinence de mes propos, vue par la communauté active de Linuxfr.

      • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

        Posté par . Évalué à -5. Dernière modification le 17/08/13 à 03:49.

        J'ai écrit :

        Je suppose qu'il existe aussi carrément des processeurs intégrant directement de la mémoire non volatile, ça me semble légitime dans la perspective d'une intégration maximisée (et pour des raisons de limitation du hacking peut-être).

        Me revient maintenant en mémoire un micro-contrôleur de la lignée 8051 comportant une fenêtre pour insolation aux UVs pour réinitialiser la mémoire non volatile embarquée (alors à nouveau programmable, par des signaux électriques). C'était il y a 20 ans.

      • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

        Posté par . Évalué à -5.

        Correctif (à visée pédagogique) :

        Le 2e point de mon explication en 5 points est incomplet. J'aurais été bien inspiré de présenter, à la suite de l'assertion « ce besoin de code se traduit par la présence d'une mémoire non volatile », l'option que j'ai énoncée au 1er des 2 points "Côté vocabulaire", à savoir qu' « un "firmware" [peut être] un code (…) chargé depuis un fichier ».

        A propos de structuration de mon discours, je verrais bien une inversion de l'ordre des 2e et 3e points de l'explication en 5 points.

      • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

        Posté par . Évalué à 4.

        Mettre un -8 à un commentaire aussi détaillé c'est vraiment de la jalousie…

        Mon +1 étant acquis, je dois dire que ces firmwares sont de plus en plus présents dans bon nombre de périphériques aujourd'hui et que je suis inquiet de leur prolifération.

        Rendons au système d'exploitation ce qui est logiciel et au matériel ce qui est strictement matériel.

        Rien que le BIOS est source de problèmes : celui de mon vieux Toshiba "bloque" les résolutions possibles alors que sa carte graphique intel 915 GM peut monter allègrement à 1920x1080. Du coup j'ai été forcé de rentrer une résolution de 1918x1080 pour passer cette barrière stupide.

        Donc je maintiens ma classification de diabolique/sain : je hais les firmwares.

        • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

          Posté par (page perso) . Évalué à 4.

          Mettre un -8 à un commentaire aussi détaillé c'est vraiment de la jalousie…

          Vu son édit, et le personnage, on peut supposer que -8 est la note par défaut lors de la publication de son message de par un karma trop mauvais. Avec un -3 actuellement on peut au moins affirmer que 5 personnes de plus ont plusser que moinsser.

        • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

          Posté par . Évalué à 3.

          Rien que le BIOS est source de problèmes : celui de mon vieux Toshiba "bloque" les résolutions possibles alors que sa carte graphique intel 915 GM peut monter allègrement à 1920x1080. Du coup j'ai été forcé de rentrer une résolution de 1918x1080 pour passer cette barrière stupide.

          Le mien refuse de booter l'OS si je change la carte wifi. C'est bien chiant.

          splash!

          • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

            Posté par . Évalué à 4.

            Le mien refuse de booter l'OS si je change la carte wifi. C'est bien chiant.

            J'ai résolu ce problème sur un IBM X31 en enlevant la "liste blanche" du BIOS,
            sur un HP 4515s je n'ai rien pu faire,
            regarde voir ci tu peut virer la "liste blanche" du BIOS.

            Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

        • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

          Posté par . Évalué à 1.

          Rendons au système d'exploitation ce qui est logiciel et au matériel ce qui est strictement matériel.

          < mode bucolique >

          Je t'invite à t'ouvrir l'esprit avec les deux commentaires disponibles à cette heure sous la vidéo de Frédéric Jouvin (aka Stman) : « Free, Secure & Open Microprocessor Project1 ».

          Sa réponse à mon commentaire est intéressante et documentée.

          Je considère qu'on peut envisager d'exécuter du code dans un contexte (le code lui-même et le système d'exploitation) tel que le FPGA soit reprogrammable à la volée (en supposant l'usage d'un FPGA à faible latence lors d'une reconfiguration), par zones, pour optimiser l'exécution du code. Cette réflexion est vaste et sera déployée. Un lourd enjeu technique est l'adaptation de compilateurs générant du byte-code d'assez haut niveau, ayant vocation à être compilés juste à temps (JIT en anglais), pour faire l'objet d'une traduction dépendant du contexte évolutif des circuits reprogrammables (tel lourd calcul matriciel pouvant faire l'objet d'une reconfiguration d'une zone rendue disponible sur le FPGA). On peut y compris imaginer hardiment un déplacement pseudo-aléatoire du noyau de l'OS lui-même. Bon, je vais loin, c'est pour témoigner.

          1 Présentation d'un projet visant à la création collaborative d'un micro-processeur libre, gratuit, évolutif, et surtout ultra sécurisé (PMMU d'un nouveau genre) et orienté cryptographie, sur FPGA, avec son compilateur GCC modifié associé.

          • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

            Posté par . Évalué à 5.

            Là vous allez très loin question recherche de sécurité. Les FPGA n'auront jamais les performances d'un circuit intégré. Et la performance reste quand même au coeur des préoccupations d'un consommateur au moment de l'achat.

            Moi je suis juste horrifié de constater que dans le noyau linux 2.4 il n'y avait même pas - à ma connaissance - de branche "firmware", et qu'aujourd'hui je vois ça : http://packages.debian.org/sid/firmware-linux-nonfree

            Si on prend les cartes graphiques, autant je comprends qu'un fabricant puisse développer des circuits spécifiques qui lui permettront de se différencier des autres et dont il partagera le secret sous licence avec quelques éditeurs de jeux vidéos ou autres, autant tout ce qui concerne l'implémentation des standards du khronos group ou VESA on devrait avoir des pilotes libres et sans firmwares.

            • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

              Posté par . Évalué à 0.

              Les FPGA n'auront jamais les performances d'un circuit intégré. Et la performance reste quand même au coeur des préoccupations d'un consommateur au moment de l'achat.

              C'est bien pour cela que je propose l'usage d'un bytecode adapté, permettant une optimisation [quasi] à la volée du code qui s'exécute, par du JIT qui prendrait le bytecode de "haut niveau" pour — selon les décisions d'un orchestrateur d'allocation des ressources du FPGA, démarrant éventuellement l'allocation de circuits logique programmés — réaliser des taches dédiées et répétitives de façon "câblée" dans le FPGA.

              Dans une perspective de performance :

              • le code binaire basique équivalent aux bytecodes du programme à exécuter est disponible dans un fichier associé à ce programme ;
              • les patterns évolués, paramétrés, à destination du FPGA pour le reconfigurer localement et optimiser des calculs spécifiques sont disponibles en fichiers ;
              • le code binaire correspondant aux bytecodes évolués usuels — binaire éventuellement paramétré (pour subir une phase d'analyse/adaptation (en mode JIT) en fonction de critères techniques liés aux choix de l'orchestrateur d'allocation des ressources du FPGA, comme le nombre de coeurs alloués) qui a vocation à être exécuté par des patterns évolués typiques pour FPGA — est disponible en fichiers associés au programme.

              Je serais curieux de voir la "perte" réelle de performance à l'usage après maturation de l'ensemble, ainsi que le rapport puissance de calcul / coût en énergie en comparaison d'un micro-processeur traditionnel…

              Incidemment, une telle reconfiguration quasi à la volée (et/ou réalisée de façon prédictive… héhé, l'orchestrateur peut voit venir de loin certaines choses) peut augmenter d'un facteur important la difficulté de malveillance appliquée au FPGA.

              Moi je suis juste horrifié de constater que dans le noyau linux 2.4 il n'y avait même pas - à ma connaissance - de branche "firmware", et qu'aujourd'hui je vois ça : http://packages.debian.org/sid/firmware-linux-nonfree

              J'ai eu l'occasion de le découvrir et de participer à relayer l'info de l'existence d'une version entièrement libre du noyau Linux — Linux-libre — notamment disponible pour Debian (Trisquel en profite, de base).

              • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                Posté par . Évalué à -3.

                < mode ludique >

                fin d'été 2009, je présentais ce [mode ludique] où je proposais le scénario suivant, dans le cadre d'une présentation de EulerGUI :

                • j'identifie tel code sur la toile comme robuste ;
                • sans le modifier, je lui ajoute du sens (une description ''normalisée'' de ce qu'il fait, en gros) ;
                • Je partage mon ajout de sens avec la communauté en communiquant une URL ;
                • L'ensemble de ces URLs partagées, consolidées (vérification, débuggage) constitue alors une base de code réutilisable sans programmer dans un langage classique mais en exprimant des règles et en définissant un modèle de données ;
                • L'écriture d'une application peut alors se faire en langage N3 (ou équivalent), en exploitant la force de la base de code partagée mondialement.

                J'ajouterais aujourd'hui que :

                • dans ce bloc d'information ajoutant du sens, la description "normalisée" pourrait comporter un référencement du code (fruit d'une analyse automatisable et/ou humaine), le regroupant par paquets fonctionnels associés à des bytecode de "haut niveau" et référençant les patterns évolués associés, paramétrés, à destination du FPGA pour le reconfigurer localement et optimiser ces calculs spécifiques.

                • L'écriture d'une application peut alors se faire en langage N3… et finalement en LNC (Langage Naturel Contrôlé).

                En définitive, on se retrouvera peut-être un jour à programmer des FPGA en jouant avec du LNC, avec reconfiguration du FPGA orchestrée automatiquement. On pourra alors partager le code dans toutes les langues du monde, la traduction automatique de LNC étant dans l'état de l'art et arrivant à maturité un jour prochain en tant que brique libre :D

                • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                  Posté par . Évalué à -5.

                  Pour mémoire, à terme la démarche EulerGUI a vocation à aboutir à pouvoir produire du code dans plusieurs langages (avec une extension par langage et l'intégration d'une couche d'abstraction qui les chapeaute tous) à partir d'une entrée en N3, OWL, etc, LNC (en programmation déclarative, modèle et règles). Pour l'instant, c'est N3, OWL, etc. en entrée / Java en sortie. Il y a déjà des expérimentation autour du LNC (anglais) en entrée. Notons que selon les souhaits de Jean-Marc Vanel, le projet inclus le "bootsrapping" (*) du processus (pour l'instant EulerGUI est codé en Java, à terme il est prévu de produire une version de ce code en tant que {modèle et règles} (N3 / LNC / …(bijectivité au transcodage automatisable)) aboutissant au programme EulerGUI lui même modifiable en LNC :)

                  (*) Bootstrapping : the process of writing a compiler in the programming language it is intended to compile

                  • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                    Posté par . Évalué à 1.

                    Le LNC et le language N3 pour l'instant c'est un peu autant l'arlésienne que l'esperanto… ça reste hyper confidentiel, ne serait-ce que parce que la notion d'ontologie est tout de même cantonnée au milieu universitaire.

                    Ce que je constate c'est plutôt un retour aux languages basiques. J'en veux pour preuve le module Hive de Hadoop par Facebook ou le GQL par Google : comment retomber sur du bon vieux SQL92 que tout le monde comprend au lieu d'Xquery qui doit à peine franchir les portes du W3C… et je pense que le N3 c'est pareil.

                    • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                      Posté par . Évalué à -3.

                      Pour ma part je propose de reconsidérer Lisaac :)

                      [ Lisaac - une présentation à partir de son exposition web du moment ]

                      // le 18 août 2013 vers 18h40 - sur /board (texte remis en forme)

                      LiNuCe< Quand je pense que ça fait 20 ans que j'utilise des lecteur audio simples & efficient de la trempe de winamp à son époque pre-AOL, x11amp (alors un clône de winamp pour Linux) et alsaplayer, des trucs qui s'ouvre instantanément, consomme peanuts pendant qu'ils jouent de la ziques et sont discret comme doit l'être ce genre d'outil qui n'a pas vocation à être une pute tape-à-l'oeil !

                      Kazin1< le client Zino a vocation a être, au moins dans une de ses implémentations, une pute tape-à-l'oeil qui s'ouvre instantanément et consomme peanuts. Pour réaliser ça, l'idéal est de coder en Lisaac (compile vers du C en optimisant les allocations mémoire au bit près, ce que ne fait pas un programmeur C… ça donne un code un chouilla plus compact en mémoire, et un chouilla plus rapide)

                      …et avec des contrôles d'allocation qui facilitent la programmation… Avec plein d'autres avantages comme le fait qu'il est très expressif, restant proche de la machine (au sens du C (le plus proche étant l'assembleur), donc ayant la capacité de mobiliser les ressources de la machine avec une finesse élevée), purement objet, mettant en oeuvre un paradigme moderne qu'est la programmation par contrat. Lisaac ayant vocation à produire du C, il est compilable pour toute cible. Quelques détails de plus ici.

                      Lisaac sur alioth.debian.org : https://alioth.debian.org/projects/lisaac/

                      Magnifique phrase introductrice : « Lisaac stands as a Self's successor. It allows low-level programming but remains a high-level language. The ideas in Lisaac are mostly inspired by Smalltalk (all values are objects), Self (prototype-based) and Eiffel (design by contract). »

                      Page wikipédia de Lisaac : http://fr.wikipedia.org/wiki/Lisaac

                      Au paragraphe Programmation par contrat on peut lire : « Pour une meilleure fiabilité du code, des mécanismes de programmation par contrat inspirés de la Notation Z ont été ajoutés. Lisaac permet de définir des require, invariants et ensure comme en Eiffel. »

                      La nimage de rigueur : [1/8] Présentation du langage Lisaac (présentation en 8 parties, c'est la première, les suivantes sont visibles dans le bandeau latéral droit, normalement).

                    • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                      Posté par . Évalué à -3.

                      Le LNC et le language N3 pour l'instant c'est un peu autant l'arlésienne que l'esperanto… ça reste hyper confidentiel, ne serait-ce que parce que la notion d'ontologie est tout de même cantonnée au milieu universitaire.

                      La notion d'ontologie… Hmmm, je te propose cette explication clarifiante, reprise ci-après (et remise en forme) :

                      La programmation déclarative consiste à écrire du code sous forme de "modèle [ ou ontologie ] et règles", en langage naturel contrôlé ou dans un langage comme "N3" ("Notation3"), OWL, RDF (des langages typiques du web sémantique).

                      Pour le dire rapidement : le modèle est la définition des concepts d'un domaine de la connaissance, les règles expriment des articulations entre les concepts, les structurent.

                      Pour ceux qui sont motivés, je vous propose de considérer ces implications de la programmation déclarative. Notez que dans ce commentaire j'ai utilisé à l'époque l'expression "langage naturel" mais j'aurais été bien inspiré de parler de "langage naturel contrôlé". Le traitement automatisé du langage naturel contrôlé est dans l'état de l'art de l'intelligence artificielle, le langage naturel comportant trop de difficultés de langue, d'ambiguïtés, de dépendance au contexte pour l'interprétation, etc., pour permettre un traitement de qualité à l'heure actuelle.

                      • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                        Posté par . Évalué à -4. Dernière modification le 20/08/13 à 16:59.

                        Sur Wikipédia, on trouve des pages explicitant des nuances subtiles entre ontologie et modèle. Si des spécialistes pratiquants veulent rapporter leur témoignage quant à ces subtilités, bienvenue. Je considère que c'est peanuts.

                      • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                        Posté par (page perso) . Évalué à 1.

                        Ou sinon on utilise le lojban, il n'y a aucune ambiguïté dans la grammaire (ça a été démontré grâce à l'informatique), restera à définir les mots composés (le lojban permet de combiner les mots, mais on peut avoir plusieurs interprétations des ces combinaisons).

                        Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

            Posté par . Évalué à -8.

            Je nomme Replicant_B (cf ici pour la justification de ce choix) cette projection futuriste vers une évolution envisageable de Replicant avec pour cible des carte à base de FPGA pour sécuriser le matériel en optimisant l'exécution par un pseudo-code de haut niveau, traité en JIT et/ou en prédictif, arbitré par un orchestrateur d'allocation des ressources du FPGA, démarrant éventuellement l'allocation de circuits logique programmés depuis une combinaison { binaire [associé au pseudo-code + pattern évolué, paramétré, à destination du FPGA pour le reconfigurer localement] }.

            Version simplifiée de cette assertion, pour la postérité (lol) :

            Projection futuriste vers >>> Replicant_B <<<, une évolution envisageable de Replicant (distribution Androïd 100% libre, soutenue par La FSF (Free Software Foundation)) avec pour cible des carte à base de FPGA pour sécuriser le matériel …et en optimisant l'exécution sur FPGA par un pseudo-code permettant une reconfiguration dynamique du FPGA.

            • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

              Posté par . Évalué à -6.

              Pfff, lala… J'ai oublié de placer les mots LNC et Zino :/

              LNC

              Naturellement, Replicant_B sera (au moins partiellement) programmable en LNC, impliquant les avantages — liés à la traduction automatisée en toutes langues naturelles contrôlées, à terme — de contribution partagée à l'échelle planétaire des documents de conceptions (Cahier Des Charges Fonctionnelles exprimées en LNC), le code du logiciel lui-même, exprimé en tant que modèles et règles (en LNC, donc), la documentation, dans toutes les langues (contrôlées), favorisant ainsi l'audit du code informatique des rouages informationnels de la démocratie :)

              Notons qu' on peut déjà automatiser de nombreux processus, comme la transformation du code LNC exprimant le modèle et les règles vers du code JAVA ou à terme tout autre langage - y compris Lisaac - et on pourra à terme assister logiciellement (et automatiser certains aspects de) la transformation du CDCF vers le code LNC exprimant le modèle et les règles.

              pour un rapide approfondissement.

              Zino

              Bon, pour Zino, évidemment Replicant_B pourra exécuter différentes versions du client ainsi le serveur, pour l'exploiter dans différents contextes, notamment en Wifi meshé. Zino, on en parle vastement par ici (et c'est au même endroit que j'ai repris des éléments pour synthétiser le propos sur LNC ci-avant).

              Cerise dans le gâteau

              Linuxfr_Reloaded - cette future plateforme contributive dédiée à l'élaboration de contenu LNC, avec interface de saisie prédictive et recherches [et traitements] sémantiques avancés sera utilisable depuis un Replicant_B dans un contexte ainsi bien plus sécurisé :)

            • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

              Posté par . Évalué à -7.

          • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

            Posté par . Évalué à -4.

            Cette même approche est à envisager sérieusement pour la FreedomBox, en alternative au projets de type Novena qui lui est basé sur un "Freescale i.MX6 quad-core 1.5 Ghz Cortex A9" avec 4 GB SDRAM (« which can be run 100% "NDA-free" with no binary blolbs ! »), donc ne comporte certes pas de FPGA, mais qui est déjà libre au niveau :

            • du schéma structurel du circuit (avec des boites noires pour les circuits intégrés, relativement à la réalité des traitements, dont certains, pourquoi pas masqués à l'OS légitime, éventuellement malveillants) ;
            • du fichier de routage correspondant (ainsi que le schéma d'implantation des composants et autre fichier de définition des percements des trous et traversées, la liste des composants) pour définir le circuit imprimé.

            Puisse la communauté des hackers se saisir de cette rafale de quenelles :D

            • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

              Posté par . Évalué à -4.

              Hmmm, dans mon exposé ci-dessus je laissais de côté ces spécifications relatives à des extensions possibles pour Novena :

              • Mini PCI Express slot for WIFI, etc
              • UIM slot for mPCIx mobile data cards
              • Great gobs of other features to play with !

              D'ici à voir fleurir des extensions intégrant un FPGA pour prendre déjà en charge des calculs plus fortement sécurisés (pour toutes les opérations de chiffrement, par exemple), il n'y a qu'un pas… Voire une version avec un gros FPGA à faible latence de reprogrammation pour donner la pleine puissance de calcul sécurisé et optimisé (coeurs reprogrammés à la volée par l'orchestrateur d'allocation des ressources du FPGA) à cet ensemble destiné notamment à un usage en tant que FreedomBox. Dans un tel contexte, les circuits propres au Novena peuvent servir à toutes sortes de calculs, notamment sur commande de la carte d'extension sécurisée. Cette dernière peut voir ainsi le matériel hôte comme un calculateur moins sécurisé à disposition, passage obligé vers le chemin d'Internet via les ports Ethernet et autres (donc en mode parano, à considérer comme un routeur in fine possiblement malveillant, mais la carte sécurisée peut authentifier toutes ses transmissions par signature cryptographique) :D

              • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                Posté par . Évalué à -4. Dernière modification le 21/08/13 à 02:47.

                Ooups, trop tard pour éditer le post. Par soucis pédagogique, je reformule la fin (les passages reformulés sont en italique) :

                Cette dernière peut voir ainsi le matériel hôte comme un calculateur moins sécurisé à disposition, passage obligé vers le chemin d'Internet via les ports Ethernet et autres (donc en mode parano, à considérer comme (approximativement, on est pas sur Ethernet, mais sur un bus PCI Express ou autre) un équivalent fonctionnel d'un routeur in fine possiblement malveillant, mais la carte sécurisée peut authentifier toutes ses transmissions par signature cryptographique) :D

              • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                Posté par . Évalué à -4.

                J'approfondis la réflexion :

                D'ici à voir fleurir des extensions intégrant un FPGA pour prendre déjà en charge des calculs plus fortement sécurisés (pour toutes les opérations de chiffrement, par exemple), il n'y a qu'un pas…

                Dans ce contexte, nous avons donc un FPGA peu puissant, à "forte" latence de reprogrammation (moins cher), monté sur une carte d'extension. Gardons à l'esprit que le FPGA peut être malveillant, à sa façon, ainsi que le processeur du Novena.

                [ Liaison privilégiée du FPGA avec les circuits hôtes du Novena ]

                Cette liaison privilégiée du FPGA avec les circuits hôtes du Novena peut avoir des implications en matière de sécurité. En effet, je (me) cite (source), à propos de la malveillance possible ciblant un FPGA :

                Il faut considérer que la pertinence d'une action malveillante est fonction de l'intelligence déployée à partir du jeu de données recueilli. Cette intelligence, inscrite dans un logiciel ou une logique cablée, peut soit être embarquée dans le circuit cible, soit être mise en oeuvre à distance, nécessitant une communication (débit ? latence ?).

                Ici, nous avons un potentiel de fort débit et d'une très faible latence dans les échanges entre le Novena et le FPGA sur sa carte d'extension. On peut imaginer une combinaison de malveillances :

                • dans un équivalent fonctionnel d'un routeur malveillant (en entrée/sortie du FPGA), réalisant un équivalent du DPI sur ce qui rentre et sort du FPGA ;
                • plus profondément dans le FPGA : à chaque porte logique peuvent être associées des cellules mémoires non documentées et une logique cablée, permettant de lire l'état du FPGA, d'assurer des traitements automatisés pour modifier son comportement ;
                • le Novena, dans un mode malveillant, pourrait piloter la malveillance ciblant le FPGA.

                Une telle combinaison de malveillances est envisageable pour le ou les producteur(s) de ces circuits intégrés. Cette malveillance serait réalisable à l'insu du code légitime qui est exécuté par le Novena et par le FPGA. Une analyse des signaux échangés sur le port d'extension (avec un analyseur logique - un appareil comportant de multiples sondes permettant d'observer autant de signaux numériques à la fois) mettrait en évidence les signaux malveillants intercalés au milieu du trafic légitime, tout au moins tant que le mode malveillant est actif. On peut imaginer, au pire, que la malveillance, déclenchable à distance, passe inaperçue au moment de l'analyse.

                Ainsi, on comprend que le fort débit et la faible latence dans les échanges entre le FPGA et le Novena sont un facteur de risque de réduction de la sécurité, d'augmentation du potentiel de malveillance ciblant le FPGA.

                Pour limiter ce risque, je pense à des circuits contrôlant l'authenticité des signaux échangés entre les deux parties, en série sur le bus d'extension. Par exemple, le FPGA peut produire une signature PGP sur chaque donnée qu'il émet légitimement, signature vérifiée par le circuit en série sur le bus (côté carte d'extension), permettant d'assurer qu'aucune autre donnée non légitime (intercalée dans le flux légitime par des routines malveillantes cachées du FPGA) ne sort de la carte d'extension. Se pose alors la question de la confiance dans ce circuit intégré supplémentaire (lui même un petit FPGA par exemple) contrôlant l'intégrité des signatures.

                On comprend que cette sécurité additionnelle est d'autant plus censée qu'elle s'appuierait sur des composants d'origines variées, rendant plus difficile la collaboration malveillante efficace.

                Ce que j'ai décrit pour le sens { carte _'extension -> Novena } est valable dans l'autre sens, sous réserve d'intégrer également côté Novena, avant la sortie sur le port d'extension, un circuit ayant vocation à vérifier l'authenticité des trames émises par le processeur du Novena.

                Finalement, les deux circuits de contrôle d'authenticité décrits ci-avant peuvent être combinés en un seul, l'impératif étant que ce soit un passage obligé sur le bus de données de ce port d'extension. Ce circuit peut donc prendre place sur la carte d'extension. Il doit pouvoir interpréter des données spécifiques comme lui étant adressées pour réinitialiser les clés publiques des deux parties (Novena et FPGA principal de la carte d'extension) pour vérifier les signatures. Idéalement, seul le FPGA principal de la carte d'extension a le pouvoir de réinitialiser ces clés au sein du circuit de contrôle, pour limiter les risques de malveillance à ce niveau. La nouvelle clé publique gérée par le Novena (chiffrée par la clé privée désormais bientôt obsolète) doit donc transiter par ce circuit, faire l'objet de tout contrôle utile par le FPGA principal, pour être injectée par lui dans le circuit de contrôle d'authenticité.

                // Fin du paragraphe "Liaison privilégiée…"

                Enfin, on notera que si seules les opérations de chiffrement/déchiffrement sont traitées par le FPGA, cela implique une confiance dans les traitement précédents et suivants (ceux qui ont mené au fichier à chiffrer / ce qui va être fait à partir d'un fichier déchiffré), qui sont à priori menés, eux, par le processeur central du Novena. La garantie est donc sur la seule fiabilité des traitements liés au chiffrement (et tout ce qui est contrôle d'intégrité et signature numérique), ce qui laisse de la place au déploiement d'une activité malveillante, concernant les fichiers traités, au sein des circuits propres au Novena.

                Dans mon propos, je considère ensuite l'hypothèse d'un gros FPGA à faible latence :

                Voire une version avec un gros FPGA à faible latence de reprogrammation pour donner la pleine puissance de calcul sécurisé et optimisé (coeurs reprogrammés à la volée par l'orchestrateur d'allocation des ressources du FPGA) à cet ensemble destiné notamment à un usage en tant que FreedomBox.

                Ici aussi s'appliquent mes considérations développées au paragraphe "Liaison privilégiée…".

                Par contre, contrairement au cas précédent, puisqu'ici le FPGA prend en charge l'ensemble des fonctions d'une FreedomBox et pas uniquement les calculs liés au chiffrement, la garantie porte sur l'ensemble de ces traitements. Le Novena peut alors servir de ressource d'appoint, moins sécurisée.

                • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                  Posté par . Évalué à -4.

                • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                  Posté par . Évalué à -4.

                  Vous pourrez considérer inspirante l'idée d'une approche similaire à celle présentée ci-après pour diffuser un tel projet en tant que kit : "DIY : Soudure CMS : Assemblage du module GPIO Demo" (YouTube).

                  Qu'il y ait de multiples conceptions. Qu'il y ait de multiples expérimentations, déjà en simulation :)

                  Nous avons besoin de variété et d'échelle régionale pour les choix de conceptions / approvisionnement / assemblage éventuel…

                  • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                    Posté par . Évalué à -4.

                    Dans l'url précitée, la paramètre #at=169 est un artéfact non désiré (lié à un positionnement au sein de la vidéo), sans conséquence sur la validité de l'url (à toute fin utile, version épurée de l'url ici).

                  • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                    Posté par . Évalué à -6.

                    Dans l'approche proposée dans la vidéo, on comprend bien que le processus de soudure par fusion en utilisant une simple poêle ne fonctionne que pour un circuit simple face. En effet, la chaleur doit remonter par le circuit imprimé pour amener les points de soudure à la température de fusion ; il ne s'agit pas d'amener la chaleur par les boîtiers des circuits CMS, ce qui pourrait largement en endommager certains.

                    Or il y a besoin de placer au moins les boîtiers du FPGA principal, du petit FPGA de contrôle, les modules de RAM, et quelques autres modules additionnels dont quelques LEDs.

                    Étant donné la contrainte liée au processus de fusion de la soudure et dans la perspective de rassembler les composants dans le plus petit volume (et surface) possible, on pourra envisager d'exploiter deux circuits imprimés, ramenés face contre face après avoir été garnis de composants sur les faces externes, en prenant soin de les séparer par un quelconque isolant. L'usage de "traversées" (de longueur supérieure à l'usage courant), soudées, permet alors d'établir la connexion électrique entre les deux circuits imprimés, en autant de points que nécessaire.

                    Détail concernant l'isolant : je conseillerai le plastique au papier, pour parer aux conséquences fâcheuses d'un éventuel contact avec un liquide, le plastique pouvant bloquer largement l'infiltration du liquide (on pourra même envisager l'application d'un fin cordon de silicone sur le pourtour du plastique, sur les deux faces, pour garantir l'étanchéité après assemblage).

                    Notons qu'il reste envisageable d'user de soudure au fer pour de petits éléments CMS complémentaires sur la face pour l'instant non garnie de chaque plaque, selon ma description précédente. Le nombres de points de soudure à réaliser doit être limité pour permettre que la tâche soit réalisable par le plus grand nombre. Si cette approche doit être mise en oeuvre, on veillera à fournir le masque permettant de garnir les points de soudure de pâte à souder, conformément à ce qui est montré dans la vidéo. L'usage du fer ici se fait avec délicatesse sans apport de soudure supplémentaire, à priori. Dans ce contexte de circuit garni sur les deux faces, avec seulement quelques composants de petite taille (avec peu de point de soudure par composant) sur une des surfaces, l'assemblage des deux circuits imprimés pourra se faire en intercalant une entretoise à la forme voulue (au minimum un isthme de matière ayant la forme du pourtour des circuits imprimés). Dans ce cas, il faudra prévoir l'usage de "traversées" d'une longueur encore supérieure.

                    Je laisse de côté la question de la connectique entre ce circuit et son environnement.

                    • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                      Posté par . Évalué à -6.

                      je conseillerai le plastique au papier

                      Correction : "je conseillerai le plastique plutôt que le papier".

                      • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                        Posté par (page perso) . Évalué à 1.

                        Les deux sont corrects.

                        Écrit en Bépo selon l’orthographe de 1990

                        • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                          Posté par . Évalué à -5. Dernière modification le 31/08/13 à 12:56.

                          Non, une formulation correcte serait : "je conseillerai le plastique de préférence au papier".

                          Du plastique au papier, c'est comme du gâteau au chocolat, une composition bizarre.

                          • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                            Posté par (page perso) . Évalué à 0.

                            Ah non je persiste, c'est correct. Par contre je n'avais pas relevé l'ambigüité.

                            Je pense que tout le monde a compris, mais c'est toujours utile de préciser…

                            Écrit en Bépo selon l’orthographe de 1990

                            • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                              Posté par . Évalué à -6. Dernière modification le 08/09/13 à 04:23.

                              Tu te trompes et tu persistes… Grumpf !

                              Tu dois faire une confusion avec l'expression « je privilégierai le plastique au papier ». J'y avais pensé initialement, mais je voulais une formulation utilisant le verbe "conseiller".

                              De rien. Non, c'est pas grave :)

                              • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                                Posté par . Évalué à -6.

                                …j'y pense, avec l'expression en italique ci-dessus, pour le coup, il y a ambiguïté, puisque les deux expressions suivantes sont valides :

                                • je privilégierai ceci ("ceci" étant ici "le plastique au papier") ;
                                • je privilégierai ceci à cela ("ceci" étant ici "le plastique", "à" devenant "au", "cela" étant "papier").

                                Plop.

                • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                  Posté par . Évalué à -3.

                  Je reviens sur le protocole d'authentification des transmissions sur le bus de liaison entre le Novena et le FPGA principal de la carte d'extension.

                  Dans l'hypothèse ou le Novena serait malveillant, à l'insu du code légitime qu'il exécute, on peut imaginer une situation où la malveillance sache reproduire le chiffrement par la clé privée et donc introduire des données illégitimes à la volée sur le bus à destination de la carte d'extension. Nous retombons sur ce qui a déjà été exprimé : du point de vue du FPGA principal sur sa carte d'extension, le Novena est un calculateur d'appoint potentiellement malveillant.

                  Dans cette hypothèse, les données signées passent sur le bus sous le regard bienveillant du circuit de contrôle d'authenticité, on peut difficilement imaginer une suite parfaitement opérationnelle à cette malveillance :

                  • un équivalent fonctionnel d'un routeur malveillant (en entrée/sortie du FPGA) chercherait à interpréter (et soustraire du flux) les données qui lui sont destinées. Il lui faut la clé publique du Novena pour déchiffrer…
                  • pour renvoyer des données à destination du Novena, ce circuit malveillant devrait pourvoir signer les données qu'il transmet avec la clé privée connue des circuits légitimes du FPGA. Et là, bonne chance, étant donné la capacité du FPGA à reprogrammer ses circuits, pourquoi pas selon des heuristiques pseudo-aléatoires de grande variabilité pour le chiffrement (qui est, comme tout traitement numérique sur FPGA, une combinaison d'un traitement logiciel et de circuits logiques programmés), avec localisation variable de la clé privée en mémoire, pour barrer la route à une attaque profonde de ce type.
                  • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                    Posté par . Évalué à -6.

                    Me relisant, j'en profite pour éclaircir un point et en faciliter la compréhension pour les non initiés.

                    J'écris : « un équivalent fonctionnel d'un routeur malveillant (en entrée/sortie du FPGA) chercherait à interpréter (et soustraire du flux) les données qui lui sont destinées. Il lui faut la clé publique du Novena pour déchiffrer… ».

                    Comme j'ai en tête le détail de l'organigramme du chiffrement/signature et déchiffrement/vérification_de_signature avec PGP (cf l'organigramme ici et l'explication ), j'ai utilisé une formulation valide mais sans doute surprenante pour le débutant. Pour détailler : la clé publique du Novena permet de vérifier l'authenticité des données signées par la clé privée du Novena. Le processus de vérification met en oeuvre du déchiffrement — avec la clé publique du signataire —, appliqué au condensat (ou l'empreinte, ou encore le hash en anglais technique) des données signées.

                • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

                  Posté par . Évalué à -5.

                  Je complète ma réflexion.

                  J'ai envisagé le potentiel de malveillance concertée entre plusieurs fondeurs de FPGA pour amener à l'établissement d'une malveillance se déployant entre des circuits logiques malveillants, non documentés, attachés à chacun des FPGA, pour ici par exemple arriver à contourner la protection par signature cryptographiques des trames émises à destination de l'extérieur. Je considère cette malveillance extrêmement délicate (voire impossible) à obtenir du fait de la volatilité du code/architecture_des_circuits_logiques_programmés permettant le chiffrement (et l'authentification) au sein du FPGA principal, volatilité de l'adresse de stockage de la clé privée utilisée.

                  On peut imaginer limiter ce potentiel de malveillance concertée (de haut niveau) en multipliant les petits FPGA de contrôle (d'origines variées), en série sur le bus, chacun ayant vocation à contrôler les signatures et limitant ainsi le potentiel de relai ou d'injection malveillante de trames illégitimes par un ou plusieurs des FPGA de contrôle sur le bus, ou par le FPGA principal.

                  Chaque petit FPGA de contrôle supplémentaire augmente ainsi la sécurité, à supposer que l'architecture soit sérieuse par ailleurs en ce qui concerne la reprogrammation des FPGA, qui doit logiquement être sous le contrôle direct et exclusif du FPGA principal. Notons que "direct" implique idéalement une capacité à programmer chacun des FPGA de contrôle par un lien direct câblé (depuis le FPGA principal), éventuellement commuté par un circuit logique dédié pour permettre un multiplexage temporel. Par ailleurs, chaque petit FPGA supplémentaire augmente aussi légèrement la latence sur le bus. On peut imaginer des modes d'usage avec un niveau de sécurité adaptatif pour se donner la capacité de réduire la latence en limitant le nombre de FPGA de contrôle ayant un rôle actif de vérification d'authenticité.

          • [^] # Re: Bel entretien qui me laisse pourtant sur ma faim

            Posté par . Évalué à -3.

            On pourra s'appuyer sur ces ressources pour apprécier la démarche :

            Jérémie Zimmermann : "nos machines sont-elles encore réellement nos amies ?" http://lacantine.ubicast.eu/videos/21-06-2013-215359/ --- La protection de la vie privée est une liberté fondamentale particulière parce qu'elle permet de mettre en oeuvre les autres libertés (de mouvement, d'association, d'expression) sans quoi il y a tendance à l'auto-censure.

            Numendil - « Si, vous avez quelque chose à cacher. » http://lacantine.ubicast.eu/videos/21-06-2013-125516/ --- Des lois censées vous protéger aux entreprises qui rêvent de tout savoir sur vous, il devient de plus en plus compliqué de garder sa vie privée « privée ». Certains disent « Je n'ai rien à cacher ». Pourquoi et comment en sommes-nous arrivés là ? Comprenons que nous avons tous quelque chose à cacher.

            …Contrôle d'intégrité / chiffrement / authentification / anonymisation : au choix, à la carte. Parce que la liberté !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.