Environnement, sécurité et open-source
Trois sujets connectés

Page en construction ! (à l'origine il s'agissait essentiellement d'une collection de liens à usage personnel, progressivement mise en forme. Le texte est toujours mal écrit à mon goût (en particulier, je n'ai pas encore complètement clarifié à quel public je m'adressais... il y a à la fois de la vulgarisation et des éléments un peu techniques sur les systèmes Linux embarqués donc a minima il faut un petit bagage technique en informatique/télécoms :). Tout ça sera retravaillé un jour quand je trouverai le temps, mais d'ici là ma prose vise surtout à donner le minimum d'enrobage et de contexte pour encourager à aller cliquer sur les liens / voir les vidéos et s'informer un maximum !)

IT et environnement...

TL;DR

Mais le pétrole n'est pas la seule ressource existant en quantité finie, c'est notamment également le cas de nombreux métaux : la presse parle parfois des "terres rares", mais le problème est plus vaste (voir l'excellent livre de Philippe Bihouix sur le sujet, mais aussi les vidéos de conférence d'Aurore Stephant ci-dessous, cet article de vulgarisation de Science et Vie © et ce post de Matthieu Auzanneau). Même si en théorie les métaux se recyclent à l'infini, P.Bihouix explique très bien dans son livre qu'en général plus un objet est complexe, plus ses constituants sont difficiles à recycler (e.g. composants/matériaux/atomes impossibles à séparer aisément, ce qui s'apparente à un usage dispersif : de la même manière que l'on ne sait pas récupérer efficacement le métal dans les peintures métallisées ou les dentifrices, il est difficile de désimbriquer les atomes dans un composant électronique. Au mieux arrive t-on à mettre au point des procédés - souvent polluants - permettant de récupérer un ou deux métaux de grande valeur tels que l'or, sans possibilité de refondre ou récupérer chacun des éléments comme c'est le cas avec des produits "low-tech" => par construction, un objet high-tech est souvent peu recyclable, et le réparer ou prolonger sa durée de vie est en général plus efficace sur le plan environnemental que recycler/refabriquer avec de fortes pertes en matériaux et énergie.

Bref, je suis de ceux qui pensent que 1°/ si l'industrie IT souhaite durer, elle serait avisée d'anticiper un monde qui change avec en particulier une disponibilité en pétrole et en divers métaux qui diminue (dans un monde interdépendant : moins de pétrole signifie aussi moins de minage et moins de transports, etc.), et 2°/ les soucis qui nous attendent impliquent ce que j'appelle les "flux amont" (ressources) et les "flux aval" (pollution / changement climatique), ce dernier étant davantage évoqué par les médias mais pas toujours traité à sa juste valeur (e.g. en se limitant souvent la consommation des appareils et non ce qu'a nécessité leur fabrication). Même si cette page référence des vidéos et de la littérature qui s'intéressent au problème de manière globale, je me focaliserai ici essentiellement sur ce qui constitue ma spécialité, à savoir l'IT et les télécoms.

Les rapports du Shift Project sur la sobriété numérique et la vidéo en ligne constituent un excellent point de départ pour tenter de quantifier l'impact environnemental (énergie/CO2/ressources) du numérique. Voir par exemple aussi cette page de GreenIT et l'excellente cette autre page. Deux remarques importantes :

• Les débats se focalisent souvent sur la consommation d'électricité liée à l'utilisation des appareils. Or "l'énergie grise" nécessaire à la fabrication des machines électroniques domine souvent d'assez loin celle de son utilisation durant tout son cycle de vie (c'est particulièrement vrai pour les terminaux et appareils grand-public, un peu moins vrai (et moins documenté) sur les appareils "lourds" e.g. data-centers et stations de base télécoms). Voir notamment ce rapport et celui-ci
• Pour une même quantité d'énergie considérée pour la fabrication/utilisation d'un appareil, le mix énergétique du pays où la fabrication est localisée est évidemment structurant (par exemple : la fabrication d'un ordinateur en Chine (où l'électricité est très carbonée) représente environ 500kg de CO2. Un data-center dans l'Oregon ou en Chine sera également beaucoup plus émissif pour une même quantité de kWh que s'il est localisé en France ou en Suède...)

=> Quelques conclusions simples : il serait souhaitable de

• produire les terminaux et implanter les data-centers autant que possible dans des pays où l'électricité est décarbonée et taxer (progressivement mais significativement) l'importation de produits fabriqués dans les pays où l'énergie est fortement carbonée
• limiter l'usage de la vidéo (en particulier éviter 4K/8K autant que possible) pour diminuer la pression sur les data-centers et sur l'obsolescence des terminaux
• prendre conscience que "chaque petit geste compte" n'est pas suffisant : chaque GRAND geste compte !
• surtout : prolonger autant que possible la durée de vie de nos machines ! ce qui implique
• De pouvoir les réparer sur le plan matériel (facilité de démontage, possibilité d'acheter des pièces détachées...)
• De pouvoir assurer leur maintenance logicielle à long terme (y compris mises à jour de sécurité, même lorsque le fabricant les abandonne). L'open-source - si la machine n'est pas verrouillée par le fabricant - est une partie de la solution (e.g. LineageOS pour les smartphones, OpenWRT pour les routeurs, Linux pour les PCs...)

Faire durer nos terminaux plus longtemps : aspects logiciels & sécurité

• Les terminaux (smartphones, produits IoT, etc) sont de petits ordinateurs qui font tourner du logiciel. Ce dernier peut être sujet à des bugs et failles de sécurité, et il est essentiel de pouvoir les mettre à jour (au moins pour corriger ces failles) : des bugs et failles de sécurité sont découverts tous les jours : un appareil qui n'est plus mis à jour doit être considéré comme vulnérable et ne devrait théoriquement plus être utilisé. Et inversement : s'il est souhaitable de faire durer autant que possible les terminaux (pour des raisons liées à l'environnement, à l'épuisement de ressources naturelles, ou au changement climatique), alors il est essentiel de ne pas négliger cet aspect logiciel, car même en ignorant la question des failles de sécurité, un terminal dont le système n'est plus mis à jour ne pourra pas indéfiniment continuer à fonctionner à l'identique (par exemple parce que les évolutions de certaines services obligent l'usager à mettre à jour son application mais que cette dernière ne supporte que les OS récents. Autre exemple : les certificats SSL dovent pouvoir être mis à jour périodiquement notamment du fait de leur date de péremption)
• Comme évoqué dans l'excellent post de Stéphane Bortzmeyer sur le RFC 8240 (qui explique très bien les problématiques de mises-à-jour à long terme), "Les vendeurs de logiciel ne sont pas un service public : ils peuvent décider d'arrêter de fournir un service pour des produits qui ne les intéressent plus (ou qui fait concurrence à un produit plus récent, qui offre une meilleure marge). Ou bien ils peuvent tout simplement faire faillite. Que faire face à cet échec du capitalisme à gérer les produits qu'il met sur le marché ?" : le logiciel libre peut être une partie de la solution (par exemple la page suivante décrit les manipulations nécessaires concernant l'installation de LineageOS sur smartphone en remplacement du firmware fourni par le fabricant), à plusieurs conditions
• Le fabricant doit respecter la licence GPL et notamment publier le code-source du kernel Linux/Android (comme il y est normalement tenu, à l'exception des iPhones/iOS et Blackberry/QNX). Cela implique que l'OEM mais aussi le fournisseur de chipset soit collaboratif pour encourager et ne pas entraver les développements open-source (AMD et Intel sont plutôt bons élèves, de même que NXP. Qualcomm déjà moins, et Mediatek encore moins. Pire encore, les fabricants de composants et OEM chinois comme Allwinner/Rockchip/AmLogic ne partagent que rarement leur code-source et s'illustrent souvent par des violations de la GPL). Les machines de type PC disposent d'une couche d'abstraction bas-niveau (BIOS/UEFI/ACPI) et peuvent de ce fait aisément fonctionner avec un kernel générique et disposer d'un support logiciel quasi illimité de sorte qu'il n'est pas difficile de faire fonctionner des machines plus de 10 ou 15 ans (même si le fabricant et/ou Microsoft en cessent le support, de très nombreuses machines fonctionnent très bien sur une variante légère de Linux). En revanche dans le monde des machines non-PC (processeurs MIPS/ARM, smartphones, routeurs, IoT, etc.) le support à long terme par les fabricants comme par la communauté open-source est techniquement plus compliqué en l'état (voir plus bas pour les détails : dans de nombreux cas, le système d'exploitation est spécifique à la carte-mère, à moins de mettre en place un mécanisme d'abstraction comme Device-tree et/ou EBBR et/ou Treble. C'est la raison pour laquelle il n'est pas possible d'installer un "android générique" sur un smartphone de la même manière qu'on démarre un système Windows ou Linux générique sur un PC...)
• Une autre condition - essentielle - est que le produit ne soit pas verrouillé par le fabricant (de plus en plus de machines ont un bootloader qui n'accepte de démarrer qu'un firmware signé par le fabricant, sans possibilité de déverrouillage ni de gestion des clés par l'utilisateur. Par ailleurs, même dans les cas où le bootloader est déverrouillable, effectuer cette opération peut entrainer des régressions délibérées (e.g. désactivation des DRM comme Widevine)) : il peut y avoir là une contradiction entre l'exigence de verrouillage souhaité par des administrations (par exemple pour garantir le respect de la réglementation radio vis à vis des SDR embarquées dans le produit. Voir les débats autour de [1] et [2], [3] et [4], voir aussi l'avis de la FSF Europe sur la directive RE-D) et celle de la faisaibilité du support par la communauté opensource afin de poursuivre les indispensables mises-à-jour de sécurité à long terme même après abandon du fabricant...
• Avoir la liberté de compiler et flasher un système alternatif (e.g. système open-source tel que LineageOS ou /e/ ou OpenWRT ou Replicant) est également le seul moyen de contrôler sa machine et notamment de s'assurer de l'absence de logiciel espion introduit par le fabricant
• Plus généralement, les pratiques actuelles en développement logiciel sont bien peu durables (voir cet article et celui-ci et ce petit livre). Pourtant, ceux qui ont connu l'essor de l'informatique savent ce qu'il est possible de faire avec peu de ressources hardware (On a oublié et on sous-estime souvent ce qu'on peut faire avec seulement 64 Ko, voire avec encore nettement moins ! Roberto Di Cosmo écrivait déjà en 1998 "(...) sans se demander pourquoi un ordinateur bien plus puissant que celui qui a servi à envoyer des hommes sur la lune, et à les ramener vivants, n'est pas en mesure de manipuler correctement un document d'une centaine de pages quand il est équipé par ce Microsoft Office (...)")
• Conclusions : à défaut d'avoir un support illimité dans le temps par les fabricants, au moins faudrait-il encourager l'open-source i.e. forcer les fabricants à (au moins lorsqu'un produit arrive en fin de vie/support)
  • Respecter la licence GPL (e.g. fournir les sources du noyau. Cela pourrait faire partie de la certification CE)
  • Fournir un moyen de déverrouiller le bootloader (e.g. fastboot oem unlock) et idéalement flasher ses propres clés de secure-boot
  • Idéalement, fournir les sources des drivers et du bootloader (et permettre de reflasher ce dernier)
  • Idéalement, intégrer sur le PCB une petite flash NOR (ou dédier un espace dans la flash NAND/eMMC) pour stocker le bootloader mais aussi le device-tree et tout le nécessaire pour rendre le démarrage des machines non-x86 plus générique (comme dans le monde PC)

Mises-à-jour et cybersécurité

Vis à vis des failles exploitables par un attaquant "lambda" :

L'intérêt et l'importance des mises-à-jour système est souvent sous-estimée par le grand public : généralement les usagers en voient l'aspect visible (ajout de nouvelles fonctionnalités, obligation d'avoir un système à jour pour continuer d'installer ou d'utiliser certaines applications telles que Netflix ou Whatsapp...) et parfois les usagers sont même réticents à les appliquer (perception d'obsolescence programmée / ralentissement intentionnel du système par les fabricants, "if it ain't broken, don't fix it !"). Pourtant les mises-à-jour sont un aspect essentiel de la sécurité de ses machines et du contrôle de ses données : une machine qui ne reçoit plus de mises-à-jour est une machine qui devient rapidement vulnérable car des bugs exploitables en failles de sécurité sont découverts tous les jours (les articles suivants de Christophe Blaess {article1, article2, article3} décrivent par exemple le principe de l'exploitation de bugs de type "débordement de buffer" (et d'autres), qui constituent notamment des défauts fréquents dans les grosses bases de code écrites dans des langages comme le C/C++. Le MITRE possède une base de données des "common vulnerabilities and exposure" (CVE) qui recense que les failles de sécurité connues dans des logiciels fortement répandus. Quelques exemples célèbres (arbitrairement choisis parmi des milliers) sous Linux sont les attaques GHOST, ShellShock et Heartbleed (les médias ont également beaucoup parlé de la faille Log4j). Dans le cas de Android, il existe aussi des failles célèbres comme celle de la bibliothèque media StageFright (qui permet à un attaquant de prendre le contrôle d'une machine vulnérable par exemple en envoyant un MMS particulier forgé pour l'occasion pour déclencher le bug, et il est possible d'effacer ses traces dans la foulées de sorte que l'attaque reste inaperçue). Le malware Mirai en constitue un autre exemple dans le monde des routeurs. N.B. en dehors du code, la configuration joue aussi un rôle : il existe par exemple des milliers de machines connectées à internet aisément exploitables car mal configurées e.g. avec des identifiants basiques...

Conclusion : le processus de mise à jour (correction des bugs et failles de sécurité sur le long terme) est essentiel dans le cycle de vie d'un produit. L'excellent post de Stéphane Bortzmeyer sur le RFC 8240 décrit de manière très complète et didactique l'étendue du problème des mises-à-jour dans le cas de l'IoT. Lecture vivement conseillée ! Le site web androidvulnerabilities.org illustre également bien la fragmentation d'Android et le nombre de produits non-sécurisés en circulation. Toute machine non mise à jour doit être considérée comme vulnérable et ne devrait théoriquement plus être utilisée !.

Vis à vis des backdoors intentionnellement insérées par le fabricant :

Le firmware d'origine peut contenir des fonctionnalités malveillantes (voir aussi ici. On n'est plus sur une problématique d'environnement (et par ailleurs on ne peut pas compter sur les mises-à-jour dans ce cas), mais sur ce sujet aussi, l'open-source peut aider considérablement à réduire la surface d'attaque, tout en restant imparfait en l'absence d'indépendance technologique (fabricants de composants/drivers européens).

• Les machines de type PC sont relativement ouvertes vis à vis d'un changement du système d'exploitation principal dans la mesure où il est possible d'installer un système alternatif open-source tel que Linux/BSD, néanmoins des attaques/backdoors peuvent exister sur le BIOS/UEFI/ACPI. Le projet Coreboot améliore un peu la donne mais peu de gens savent par exemple que tout PC plus récent que 2008 intègre un microcontrôleur (management engine) co-localisé avec le processeur principal, exécutant du code tenu secret par Intel/AMD, signé, non désactivable et ayant accès à la totalité de la RAM et des interfaces réseau de manière indépendante du processeur principal (même lorsque ce dernier fonctionne sous un système ouvert comme Linux ou FreeBSD)).
• Dans le monde du mobile, la situation est encore plus délicate. Tout d'abord, tout smartphone Android utilisant les Google Services Framework (i.e. avec Google Play) donne un accès complet et illimité à Google sur sa machine et ses données. Ensuite, même en flashant un système ouvert exempt du Google Service Framework (tel que /e/ ou LineageOS), il n'existe pas de smartphone raisonnablement fonctionnel sans les drivers du fabricant (Qualcomm/Mediatek/...), ces derniers étant toujours closed-source et pouvant également renfermer des backdoors (même s'il est nettement plus compliqué de loger et activer une backdoor dans ces composants que dans le système principal donc on peut encore espérer que ces composants logiciels en soient exempts)

Bref, il est bon de garder en tête que supprimer le risque théorique d'avoir sur son smartphone un spyware de la NSA ou de son équivalent chinois restera quasi-insoluble tant qu'on n'aura pas d'indépendance technologique européenne sur le design et la fabrication des composants utilisés dans les appareils grand public. Cela dit il est infiniment plus aisé de loger et d'activer une backdoor silencieuse dans l'OS ou le Google Service Framework que dans les drivers/firmwares bas-niveau, et j'estime donc que la majorité du risque est évitée en flashant un système open-source tel que LineageOS+microg / Grapheneos / Calyxos sur son appareil Android (ou OpenWRT sur son routeur, ou n'importe quelle distribution Linux ou BSD sur son PC...), ce qui permet également souvent de prolonger sa durée de vie comme on l'a vu plus haut du fait de la durée de toute façon limitée du support fabricant.

Difficultés de mises-à-jour pour des machines non-PC (smartphones, IoT...)

• Les machines autres que x86 n'ont pas de couche d'abstraction telles que BIOS/UEFI/ACPI (qui rend possible de démarrer le même système Linux ou Windows quel que soit le PC...) => l'OS ou le kernel doit être spécialement adapté à chaque SoC et à chaque carte-mère ! (ce qui fait qu'il n'existe pas un unique linux générique ou un unique android générique à installer sur tous les smartphones du monde...). Ceci rend la maintenance à long terme techniquement compliquée (car la fragmentation fait que peu de personnes s'impliquent sur une même machine, et que de nombreuses machines un peu anciennes sont abandonnées sans mises à jour là où un PC vieux de 15 ans pourra toujours faire fonctionner une distribution Linux récente et à jour). Découpler Android en une partie kernel+drivers (fournie par le fabricant) et une partie OS (mise à jour par Google ou par la communauté open-source) via une HAL mieux définie et le Projet Treble permet d'améliorer les choses et d'éviter les failles de type Stagefright, mais n'évite pas les failles de sécurité dans le noyau ou les drivers si ces derniers ne sont pas mis à jour. Disposer d'un kernel aussi générique que possible associé à un device-tree (ou mieux : de quelque chose d'analogue au BIOS/UEFI/ACPI e.g. via EBBR stocké sur une petite flash NOR qui coûterait quelques centimes et occuperait quelques mm² sur le PCB) est sensiblement meilleur.
• Le fabricant doit avoir fourni le code-source du noyau et autres éléments sous licence GPL (de nombreux fabricants ne s'y conforment pas. En particulier les petits fabricants basés à Shenzhen et utilisant des SoCs chinois ou Taiwanais tels que Unisoc/Mediatek/Allwinner/Rockchip/AmLogic...). Le fabricant de SoC (Qualcomm/MTK) doit aussi avoir autant que possible intégré les spécificités de son SoC dans le kernel Linux mainstream, se baser sur un device-tree plutôt que sur des board-files, etc. Les pratiques diffèrent énormément selon les fabricants, rendant impossible la génération d'un arbre source "android générique".
• Le fabricant ne doit pas verrouiller le bootloader (ce qui de plus est parfois exigé par les administrations/régulateurs pour éviter que des tiers ne jouent avec les paramètres radio et ne génèrent volontairement ou involontairement des brouillages préjudiciables. Voir aussi l'avis de la FSFe sur la directive RE-D à ce sujet...)

Faire durer nos terminaux plus longtemps : aspects matériels

(=> tout ce qui est à côté de "we have the right" devrait être rendu obligatoire afin de rendre les produits un peu plus réparables. En particulier : la fourniture de documentation techniques et de pièces détachées pendant au moins 5 ans devrait être garantie. Il pourrait être utile de standardiser et modulariser autant que possible les composants (e.g. batteries / carte-mères à un format génériques pour être interchangeables), même si c'est au prix de smartphones un peu plus gros et un peu moins beaux. Aujourd'hui seul le fabricant Fairphone semble s'en préoccuper. Dans la pratique, acheter un téléphone "flagship" d'occasion peut également faire l'affaire si ce dernier est correctement conçu pour être réparé et s'il a été diffusé en des millions d'exemplaires, rendant envisageable l'achat de pièces détachées sur le marché de l'occasion. Mais cela reste hasardeux et en pratique des smartphones de plus de 5 ans sont difficiles à réparer faute de pouvoir trouver les pièces détachées nécessaires). l'accès à la documentation et aux outils matériels permettant de "débricker" / reflasher un smartphone dont le bootloader est HS devrait également être facilité.

Tirer parti de nos machines : logiciels pour faciliter le travail à distance et éviter les réunions internationales

D'une manière générale, même si le numérique permet d'éviter certains postes d'émission (économie du partage, blablacar, jitsi, etc), sur son ensemble il ne permet que rarement d'équilibrer la consommation de ressources nécessaire à la fabrication des machines et des data-centers (sans parler du fait que les usages tels que le commerce en ligne / Amazon contribuent globalement à l'augmentation de la production et du nombre de camions sur les routes même si les entrepôt sont moins visibles que des hypermarchés physiques). Cependant, dès lors que la majorité de la population est déjà équipée en ordinateurs/smartphones et en particulier si on parvient à prolonger leur durée de vie, alors il serait dommage de se priver de ce que le numérique peut apporter...

En l'occurence, la "réunionnite internationale" (tous secteurs confondus) est un vecteur important d'émissions CO2 et de consommation de kérosène (même si comme pour tout sujet, il faut évaluer la balance bénéfice-risque au cas par cas. Un sommet sur le climat mérite sûrement quelques billets d'avion...). Pour donner un exemple et un ordre de grandeur : le 3GPP représente probablement plus de 2000 délégués (tous groupes confondus) qui se réunissent tous les 2 mois quelque part dans le monde ! Certaines négociations gagnent effectivement en efficacité lors d'une réunion face-à-face (notamment car la communication non-verbale et/ou des discussions informelles peuvent jouer un rôle clé) donc il n'est pas question ici de les abolir à court terme, mais dans un monde où il y aura de toute façon de moins en moins de pétrole et où le changement climatique devient une menace sérieuse, il va bien falloir faire avec moins de vols ! Je reste personnellement persuadé que la mise en place d'outils adaptés est un volet essentiel pour permettre de diminuer significativement le nombre de réunions. Or très souvent, les outils de rédaction collaborative se limitent à Microsoft Word (+ marques de révisions) et au mieux un outil tel que Jitsi (ou Webex/Gotomeetings/Zoom/YouNameIt) pour les réunions à distance, et ces conditions sont souvent sous-optimales par rapport à des réunions en présentiel. Pourtant, pour donner un contrepoint et un autre ordre de grandeur : les développeurs du noyau Linux ce sont également plus de 1000 personnes qui collaborent à distance, mais qui se réunissent au mieux une fois par an car ils ont développé les bons outils (j'admets que ce n'est pas comparable car le sujet est supposé essentiellement technique et assez peu politique, mais le parallèle est intéressant). Gitlab est également un bon exemple d'une relativement grosse société s'étant structurée depuis le début en full-remote et ayant documenté les bonnes pratiques ayant permis d'y parvenir

Cette section essaiera d'explorer des outils (notamment open-source) existants pour faciliter le travail à distance, et d'évaluer ce qui manque pour l'encourager.

Pour aller plus loin

Pétrole-carbone-climat : quelques messages-clés

• La lecture du livre "l'énergie durable, pas que du vent !" (pdf disponible gratuitement sous licence CC) est très vivement conseillée pour fixer les ordres de grandeurs quand on parle d'énergie
• Les questions liées au "flux avals" de notre activité industrielle (pollution, changement climatique) sont désormais raisonnablement médiatisées. En revanche, la question des éventuelles limites sur les "flux amont" (ressources naturelles, énergétiques et metalliques) ne sont que rarement abordées. Pourtant "Celui qui croit à une croissance exponentielle infinie dans un monde fini est soit un fou, soit un économiste"
• Il existe un lien de corrélation très clair entre PIB et volume de pétrole consommé (indépendamment du prix). Corrélation ne veut bien sûr pas forcément dire causalité, néanmoins sur ce sujet complexe la lecture de ce résumé d'une vingtaine de pages est très vivement recommandée. Voir aussi cette page et celle-ci, qui expliquent le sujet de manière très claire, en distinguant ressources renouvelables et non-renouvelables (notons au passage que le discours autour du "jour de dépassement" cher aux médias ne concerne que les ressources renouvelables)
• Stricto-sensu l'énergie d'un système isolé reste constante mais son entropie augmente (ce qui caractérise l'irréversibilité). Nicholas Georgescu-Roegen a écrit de manière très éloquente : « Chaque fois que nous produisons une voiture, nous détruisons irrévocablement une quantité de basse entropie qui, autrement pourrait être utilisée pour fabriquer une charrue ou une bêche. Autrement dit, chaque fois que nous produisons une voiture, nous le faisons au prix d’une baisse du nombre de vies humaines à venir. Il se peut que le développement économique fondé sur l’abondance industrielle soit un bienfait pour nous et pour ceux qui pourront en bénéficier dans un proche avenir: il n’en est pas moins opposé à l’intérêt de l’espèce humaine dans son ensemble, si du moins son intérêt est de durer autant que le permet sa dot de basse entropie. »

Quelques liens supplémentaires

• Questions d'environnement et de ressources
• Le Manifeste pour décarboner l'Europe du Shift Project
• Un article de Science et Vie sur l'épuisement des ressources naturelles/minières non-renouvelables, et un livre de Philippe Bihouix sur cette même thématique chez EDP Sciences
• Rapport de Yves Cochet (institut Momentum)
• Livre de Dennis Meadows (et synthèse du rapport du "club de Rome")
• Post de Matthieu Auzanneau sur le livre de François Roddier "thermodynamique de l'évolution"
• Dossier "peak oil" de Matthieu Auzanneau
• Une présentation de l'ASPO
• Questions d'IT
• Rapport "Réduire la consommation énergétique du numérique"
• Liens sur le "droit à réparation" récemment élaboré par la Commission Européenne 1, 2, 3, 4, 5
• Livre "Android internals" par Jonathan Levin (excellente référence pour en comprendre le fonctionnement sous-jacent)
• booting-without-of.txt et stable-api-nonsense.rst : explique certains principes du démarrage d'un kernel linux sur des machines non x86, ainsi que le refus des développeurs noyau de s'engager sur des API internes stables (ce qui faciliterait pourtant l'interfaçage avec des composants logiciels/drivers propriétaires non maintenus)
• https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf
• Coreboot et OSresearch/HEADS
• Livre "BIOS Disassembly ninjutsu uncovered"
• Posts 1 et 2 sur les OS Mobiles sur Linuxfr
• https://www.bortzmeyer.org/5g.html