Renault a écrit 7546 commentaires

C'est incomplet.

En effet ta Debian n'a pas tous les derniers correctifs concernant le noyau pour ces failles. Mais il en a probablement une partie.

En fait la commande citée repose sur un correctif arrivé plus tard pour décrire en détail ce qui est appliqué ou pas. Mais certains correctifs existaient avant. Mais pas tous.

De plus comme tu n'as pas la dernière version du noyau, tu devras attendre l'application de ces correctifs par Debian ou d'autres développeurs assurant la maintenance du noyau que tu utilises. Cela prend un peu de temps, d'autant que Debian n'est pas du genre à avoir une politique de mise à jour rapide.

Mais, dans ce cas, pourquoi je n'ai pas d'informations précises dans mon /proc/cpuinfo quant au CPU?

Ça y est :

bugs : cpu_meltdown spectre_v1 spectre_v2

Après cela ne signifie pas où en est la correction, mais cela liste les erreurs du matériel. Tu y as accès.

et je doute que la vulnérabilité soit testée par le noyau, à mon avis, c'est juste du bon gros hardcode pas propre, à vérifier

Ce n'est pas sale d'établir une liste du matériel concernée (avec éventuellement des jokers sur les id pour une plage complète). C'est même plus fiable et plus performant qu'un test du noyau à chaque démarrage.

Pour moi, le rôle du kernel n'est pas d'informer sur les failles du hard, mais d'en permettre l'usage (du hard, hein) de manière uniforme sans (trop) s'inquiéter de comment fonctionne le matériel (parce que je pense qu'il est quand même bon de connaître l'archi globale d'un PC, info qui n'est d'ailleurs dans aucune page de manuel de mon système, à moins que je ne sois passé à côté…).

Le but du noyau est de faire le lien entre le matériel et le logiciel. De la façon la plus exhaustive que possible. C'est aussi une sorte de machine virtuelle pour les logiciels, à priori ton shell n'a pas à se conformer aux specs du matériel mais à ceux de Linux. Linux faisant le lien entre son API et le matériel.

Donc oui le noyau doit permettre cette abstraction, mais pas que. Parfois tu as envie d'avoir accès à tous les détails de ton matériel pour en retirer certaines fonctionnalités ou plus de performances. Ou même tout simplement savoir ce qui se passe.

Ces failles ayant un impact (en terme de sécurité ou de performances), il est bon que le logiciel en dessous (et l'utilisateur) en soit conscient ou du moins puisse l'être. Je serais content aussi que le noyau me prévienne si jamais le bogue sur le calcul des flottants de la part d'Intel (pour un processeur des années 90) revienne pour que le logiciel et l'utilisateur soient capables de tirer parti de cette information.

On est pleinement dans le rôle du noyau.

En plus, les chiffres étaient rond parce que les systèmes sont conçues en assemblant des modules par basés sur des puissances de 2.

Tout à fait, c'est pourquoi globalement toute l'informatique emploient des unités en base deux : nos ordinateurs sont en général l'association de composants qui reposent eux même sur la base 2. Et pourquoi s'en est ainsi ?

Outre le fait que l'information est stockée sous forme de bits, n'oublions pas qu'en électronique il est très courant de juste recopier un motif de composants ou de fils pour les doubler, quadrupler, etc. On retrouve la base 2 dans ce procédé.

Cependant, il y a un endroit de stockage où la base 2 ne fonctionne pas : le stockage de masse magnétique. Les disquettes comme les disques durs, de par leur conception et géométrie n'ont pas ces propriétés des autres composants électroniques comme le processeur, la RAM ou la mémoire flash. C'est à cause de ces composants que le flou entre Ko et Kio ont commencé à émerger.

Le soucis est le manque de cohérence autour de ces unités. Par exemple globalement sous GNU/Linux, l'ensemble utilise les préfixe type Kio. Mais sous Windows, c'est les Ko qui sont affichés (alors qu'en interne cela utilise bien des Kio pour les calculs). Les fabricants des disques durs utilisent aussi les Ko probablement pour des raisons commerciales. Cela est trompeur, de nombreux utilisateurs ne comprennent pas pourquoi un disque dur de 1 To n'en fait en réalité que 900 Gio (suffit de voir la quantité de messages à ce sujet sur Internet).

Mais bon, le manque de cohérence ne se limite pas là. Techniquement on devrait utiliser en anglais aussi les octets au lieu des bytes. Le premier étant explicitement un regroupement de 8 bits alors que le second est le plus petit mot compréhensible pour la machine. Globalement les deux sont identiques depuis 20 ans, mais cela n'a pas toujours été le cas et techniquement, rien ne dit que cela durera éternellement. En plus d'être source d'erreur car à une majuscule près, un facteur 8 est compté ou pas (bits au lieu de bytes).

Comme je l'ai dit, l'information que les personnes malveillantes veulent est disponible quoiqu'il arrive. Tu ne vas pas les retenir longtemps en cachant les fichiers en question.

De plus, étant donnée les failles en question, je doute qu'un script kiddie puisse faire quoique ce soit. Cela demande quand même des compétences, l'outillage et de l'analyse.

Suffit donc de lire le fichier /proc/cmdline qui est accessible à tous, ou alors lire les sorties de dmesg ou de journalctl (de même, c'est accessible à tous) pour avoir cette information.

Bref, rien de très sorcier. Les exploitants des failles dont on parle sont je pense assez compétent pour être capables de récolter ces informations très rapidement.

Je trouve cela sain que l'utilisateur puisse connaître le degré de sécurité de sa machine même s'il n'a pas les possibilités de résoudre cela lui même directement. Sauf en avertissant son administrateur système préféré par exemple.

En tout cas je ne trouve pas non plus de justification qui rende cette divulgation un problème. Si ce n'est pas un problème particulier, autant l'afficher. Cela me paraît normal.

Si tu veux on peut discuter de tout le /sys ou /proc où bon nombre d'infos ne sont pas pertinents pour la quasi totalité des gens, est-ce une raison suffisante pour masquer cela ? Bof

L'utilisateur n'est pas forcément un sudouser donc oui c'est bien plus facile pour lui que de devoir chercher sur le web une liste des noyaux concernés ou pas par la faille. Surtout que l'utilisateur n'est pas forcément un expert.

Tu mets en acces libre /etc/shadow? Si non pourquoi? C'est de la securite par l'obscurite.

Sauf que l'utilisateur lambda n'a pas de moyen d'accéder aux infos de /etc/shadow en dehors de l'accès au fichier lui même.

Concernant les failles, à priori, connaître la version du noyau est suffisant. Information que tu retrouves partout : chargeur de démarrage, démarrage du noyau (ou dmesg / journalctl une fois lancée), uname -a, etc.

Bref, ajouter cette information ne fait gagner que très peu de temps à l'attaquant, et il ne va probablement gagner aucune information supplémentaire qu'avec les moyens que j'ai listé plus haut. Par contre cela simplifie grandement la visibilité de la situation pour l'administrateur et l'utilisateur de la machine.

Pas convaincu que de masquer l'information soit efficace.
Avec la version du noyau normalement tu as une bonne idée de la surface d'attaque. Un uname -a peut donc fournir l'information nécessaire.

Sans compter que la sécurité par l'obscurité n'est pas efficace de manière générale. Miser là dessus me paraît un brin cavalier.

Disons que pour Meltdown, le débit de fuite c'est jusqu'à 500KB/s, c'est-à-dire beaucoup et c'est en partie là le problème qui rend la vulnérabilité vraiment pratique.

Je le sais bien. Mais bon, le contenu dans le cache est très mouvant (pour des caches de plusieurs Mio, ce qui devient de plus en plus courant, cela est difficile de tout récupérer avant un changement important de son contenu).

Puis encore faut-il, avec un dump du cache, réussir à comprendre la signification de la donnée récoltée pour en tirer quelque chose. Loin d'être impossible, mais ce n'est pas non plus immédiat et cela réduit le risque (je pense) d'une attaque d'envergure.

Il est évident que plus tu fais attention à ta machine (système à jour, installation de moins de logiciels et provenant de sources sûres), plus le risque au sujet des failles de manière générale sera faible.

Cependant ce n'est pas suffisant, typiquement ici ce sont des failles potentiellement exploitable en utilisant que des logiciels "sûrs" type Firefox. Car beaucoup de logiciels ont de quoi interpréter du code (dans le cas du navigateur, le JavaScript est particulièrement évident) et si le code injecté est malveillant, ce n'est pas bon. De même au sujet des machines virtuelles par rapport à la machine hôte.

Concernant ces failles en particulier, si les conséquences peuvent être désastreuses, cela reste des failles assez complexes à exploiter convenablement. S'il est facile d'extraire des données du cache ou du noyau par exemple, encore faut-il réussir à obtenir (et comprendre) les données pertinentes pour l'attaquant. L'attaquant ne semble pas avoir un contrôle là dessus. Je n'ai pas l'impression qu'il soit possible d'extraire volontairement et simplement des données sensibles (données persos, mots de passe ou clé cryptographiques) sur demande.

Après je peux me tromper, je serais intéressé d'ailleurs de savoir si je fais fausse route là dessus.

Le but de ces taxes n'est pas de financer l'État mais de financer des programmes de sensibilisation, de dépistages, de soins (ou dans le cas de l'énergie, la transition énergétique et financer la recherche du domaine).

Rien n'empêche d'ailleurs pour l'État de changer sa fiscalité si jamais la transition entraîne une baisse budgétaire insoutenable.

De sûr, les fumeurs payent moins en taxe que le coût que le tabac engendre à la sécurité sociale. Pour l'alcool, n'ayant jamais étudié la question je ne me prononcerais pas.

Je pense en tout cas qu'il est plus pertinent de taxer des produits mauvais pour la santé ou de subventionner / réduire la TVA / autres pour pratiquer une activité sportive que de moduler la prime d'assurance.

Je pense que cette méthode permet d'être plus efficace pour changer de comportements (car tu sanctionnes financièrement la mauvaise habitude directement) et évite que ceux qui auront besoin d'une assurance finalement n'y souscrivent pas car trop cher.

Notons que Firefox intègre deux listes de Disconnect pour sa protection automatique contre le pistage (que l'on peut étendre bien entendu).

Cela est disponible dans la partie Sécurité et vie privée des préférences de Firefox. Depuis les extensions du type Disconnect me semblent superflues aussi.

Même en vivant au fond de l’Amazonie sans internet tu ne peux plus éviter le tracking.
Le tracking ne se limite pas aux fichiers logs des serveurs que tu visites, il y a aussi toutes la partie automate et IOT (exemple les bancontacts *1), les trucs communautaires (OpenStreetMap, Pokemon Go), les drones et satellites (petit exemple avec les drones chinois), se que les gens postent à ton propos sur les réseaux sociaux et ce même si tu leur interdis.

*1 la ville de Liège se sert du tracking des payements pour créer des maps des déplacements des consommateurs à l'intérieur de la ville

La question est : est-ce possible et souhaitable qu'aucune activité ne puisse générer du tracking ? Par exemple il semble évident dans les télécoms et le système bancaire qu'on puisse identifier qui a fait quoi et quand. Car techniquement tu n'as pas le choix (après tu peux supprimer ces données au fur et à mesure, bien entendu, mais en soit le tracking est techniquement obligatoire).

Puis le tracking a de bons côtés, la question est de son usage, de la granularité et éventuellement de l'anonymisation. Par exemple, en Belgique comme tu le soulignes, Orange a aussi fourni au gouvernement des informations sur les déplacements de ses utilisateurs de zone à zone pour un évènement donné (donc granularité au niveau de la ville, pas du bâtiment).

Ces données sont essentielles pour comprendre les flux de la population au sein des villes et des pays. Pour notamment mieux anticiper certains évènements qui rameutent du monde (ce qui demande de l'organisation) mais aussi pour dimensionner le service public (par exemple les transports aux communs) aux besoins réels. Si par exemple on observe un flux particulier le samedi en terme de trajets, peut être que la ville peut décider d'y ouvrir une ligne de bus ou autre. Sans le tracking tu seras bien moins précis et faudra faire des expérimentations coûteuses et délicates pour vérifier.

Bref, le tracking de la population a aussi des effets positifs. Mais le tout doit être fait dans un cadre qui limite les dérives possibles. De toute façon si tu ne veux pas être tracké, je pense que la meilleure solution est de se passer des solutions techniques qui en dépendent.

Ni observer un entrepôt pour savoir ce qui y est stocké, et comment y accéder de nuit sans déclencher d'alarme.

Je pense que si tu traines trop longtemps auprès d'un lieu où tu n'es pas convié pour observer la sécurité du coin, les propriétaires (que ce soit des propriétaires d'une entreprises ou d'une maison particulière) vont appeler les flics pour comportement douteux et ils vont t'interroger sur tes motivations.

Je ne vois pas l'intérêt de scanner un site quelconque sans y avoir été convié. Soit tu veux faire quelque chose d'illégal avec, soit tu veux les aider. Mais si tu veux les aider il y a un moyen simple : tu les contactes avant. Car de toute façon si tu le fais dans leur dos et qu'ils s'en aperçoivent, ils pourraient avoir peur et t'attaquer en représailles. Ils peuvent aussi ignorer tes résultats car ils ne t'auraient rien demandés ce qui t'aurait fait perdre du temps.

en cas de perte ou vol de ta carte d'identité, la personne qui l'a trouvée ou volée peut-elle s'en servir pour se connecter aux sites du service public avec ton identité ?

Faut entrer le code pin de la carte, comme pour ta carte bancaire pour l'utiliser. Et comme pour la CB, 3 échecs successifs et il faut le code PUK ou refaire la carte.

Ce n'est pas infaillible mais c'est pas mal. Et en cas de perte ou de vol tu le signales aux autorités pour l'invalider et en faire une nouvelle. Cela me semble suffisant.

techniquement, comment ça fonctionne ? si je veux m'identifier/authentifier sur le site des impôts avec ma carte d'identité à puce, est-ce qu'il me faut un équipement particulier ? (lecteur de carte, récepteur NFC ?).

Il faut un lecteur de carte et un logiciel adapté sur ton ordinateur.
Le lecteur de carte est peu cher (le mien a coûté 10€) et le site officiel de l'État propose un middleware libre (pour Windows / MacOS / Linux) et des extensions pour Firefox, Chrome, etc. Bref c'est plutôt bien géré de ce côté.

Quand tu te connectes au site des impôts donc, le plugin du navigateur va demander de saisir le code pin pour que l'authentification se fasse.

Tu parles beaucoup d'écologie sur le sujet. Bien que ce soit en soit pertinent, je trouve que tu en parles beaucoup sans mesurer réellement le sujet.

Certains (pseudo) experts vont jusqu'à chiffrer le gain d'énergie à espérer au niveau national si le fond blanc de google était remplacé par un fond plus foncé avec un contraste plus important.

Sur les écrans LCD c'est dans l'ensemble faux. Et ces écrans sont majoritaires. Cela est vrai pour les tubes cathodiques ou les écrans LED. Mais ceux-ci sont plus minoritaires bien que les écrans LED s'installent de plus en plus que ce soit pour la TV, les ordinateurs ou les téléphones portables et tablettes.

Et rien n'empêche en soi de rendre la page de Google en noir sans utiliser un site alternatif.

Ainsi Ecosia, qui renvoie les résultats google, mais en affichant ses propres publicités et qui dit qu'une partie de ses revenus publicitaires servent à planter des arbres.

Mais techniquement Google investit aussi dans des énergies renouvelables, qu'est-ce qui est le mieux ? Le plus rentable d'un point de vue efficacité / écologie ? Difficile à dire sans mesures précises des émissions et des compensations dans les deux cas.

Mais sans garantir (à ma connaissance) que les arbres plantés compensent au moins le surcout énergétique représenté par ses serveurs, qui s'ajoute au coût déjà important d'une recherche Google.

Ce qu'il faut en effet mesurer précisément.
Il ne faut pas oublier dans le coût que Google a des serveurs un peu partout dans le monde, évitant des allers-retours qui font la moitié du globe (et qui donc font consommer les équipements réseaux intermédiaires). C'est souvent moins le cas de ce genre de prestataires écolos.

J'avais d'ailleurs fait une recherche assez poussée il y a quelque temps sur le cout énergétique d'une recherche Google. Certains sites indiquent que la moindre recherche dépense autant d'énergie qu'il en faut pour faire chauffer une tasse de thé. Une thèse dont Google s'est défendu, assurant qu'il fallait 70 fois moins d'énergie que la quantité décriée. Ça reste néanmoins un impact mesurable et observable.

C'est un sujet déjà discuté ici et qui est assez complexe.
Le soucis est qu'un moteur de recherches a des coûts fixes (énergétiquement et financièrement) énormes. Que Google reçoive 100 000 ou 1 000 000 de requêtes, le gros de l'infrastructure sera le même (car il faudra parser tout le web de toute façon et avoir déjà une armée d'ordinateurs pour tenir la charge). Les requêtes supplémentaires ne vont pas significativement augmenter le coût énergétiques de Google car le plus gros est déjà pris en charge.

Donc en fait plus Google reçoit de requête, plus le coût énergétique par requête sera basse grâce à la dilution des parties fixes.

Du coup ces calculs dépendent de ce qu'ils prennent en compte, la requête elle même ou aussi toute l'infrastructure derrière (dont la partie indexage des pages mais aussi des FAI et équipements réseaux entre le client et les serveurs de Google).

En tout cas une requête = énergie d'une tasse de thé, c'est assez énorme, physiquement ça semble assez délirant.

il y a en premier lieu la rapidité, la disponibilité et la pertinence des résultats. Ce qui fait de Google le choix logique par défaut.

Tous les pays n'ont pas Google en situation d'hyper dominance. Bing et Yahoo! fonctionnent très bien et aux USA ils sont très présents. Bref, Google n'est pas forcément le choix logique, d'autres moteurs de recherches ont aussi de bons atouts.

Je pense que l'idéal serait un moteur de recherche interne (et ce serait aussi plus écolo)

En quoi ce serait plus écolo que le moteur de recherche soit interne ? Comme Google (et d'autres) parsent tout le Web, techniquement linuxfr.org sera pris en charge par Google que linuxfr l'utilise ou non. Alors que linuxfr devrait dans ce cas créer son propre index ce qui n'est pas gratuit en ressources et il faudrait démontrer que linuxfr exploite mieux son serveur (et donc l'énergie consommé par ce dernier) que Google ce qui n'est pas gagné.

Parce que si ça marche, c'est peut-être le truc qui pourrait pousser à l'ouverture de ces composants, non?

Personnellement, si je suis pour l'ouverture du matériel, je ne crois pas qu'un processeur ouvert aurait empêché nos déboires actuelles avec Spectre et Meltdown.

Déjà parce qu'un processeur (tout comme un logiciel ouvert) n'empêche pas l'existence des failles et des bogues. Ça te permet de vérifier par toi même mais cela ne devient pas magiquement 100% sûr.

De plus, nous sommes dans le monde matériel. Suivant le problème, comme ici, la solution vient par une mise à jour du matériel ce qui n'est pas gratuit ni immédiat. Bref, il faudrait probablement toujours produire et racheter du matériel neuf pour régler ce genre de soucis (sans pertes de perf).

Le libre est une bonne chose, mais ce n'est pas une réponse à tous les problèmes techniques.

Je crois que les impôts en France ont utilisé ce système quelques temps, mais ont vite laissé tomber face à la complexité et au nombre de personnes qui revenaient pleurer tous les ans qu'ils avaient perdu leur certificat.

C'est compliqué parce que c'était mal foutu, soyons honnêtes. En plus il y avait une dépendance à la dernière version de Java officielle, etc.

En Belgique par exemple toutes les cartes d'identité ont une puce numérique contenant bien entendu de quoi authentifier par clé numérique qu'une action numérique est faite par l'utilisateur. Du coup en Belgique les sites officiels sont accessibles par ce biais, ça fonctionne très bien. C'est très simple, pas très cher, pas besoins de nouveaux identifiants ou de demander quelque chose à l'État (contrairement à aujourd'hui en France où l'État t'envoie l'identifiant).

Donc l'ADN qui définit uniquement une personne… c'est vrai dans 99,99% des cas :)

Pas besoin d'aller si loin, même aujourd'hui il est possible d'avoir deux personnes totalement différentes qui vont partager le même résultat ADN.

Car en biométrie, ce n'est jamais l'entièreté du segment analysé qui est stocké et comparé (ce serait trop long, coûteux et sujet aux erreurs). Typiquement pour une emprunte oculaire ou digitale, seuls un certains nombres de points qui correspondent suffisent. Même au niveau judiciaire. Ce qui diminue grandement la fiabilité du procédé (qui reste globalement valide bien entendu, mais la probabilité que cela coince n'est pas non nulle).

De même pour l'ADN, toutes les nucléotides ne sont pas analysées puis comparées. Seules une faible portion de l'ADN l'est. De même que plus haut, tu peux avoir deux résultats d'analyse ADN qui collent alors que ce sont des personnes différentes non jumeaux monozygotes. C'est très rare, mais la probabilité n'est pas nulle.

Les jumeaux partagent la même ADN, mais pas les mêmes empreintes oculaires, digitales ou le même faciès. En général on utilise pas l'ADN pour s'identifier quotidiennement (c'est utilisé pour le milieu médical ou judiciaire au mieux).

J'avais cru comprendre que justement, c'est une approximation de ton doigt qui est pris et qu'on regarde le positionnement des différents sillons, etc.

Plus exactement, ce qui est stocké est normalement une liste de coordonnées avec une caractéristique du sillon pour une empreinte digitale (après de souvenir un capteur d'iris repose sur le même concept).

C'est-à-dire qu'on stocke "au point X,Y nous avons une caractéristique de type Z et d'orientation A", une caractéristique pouvant être un embranchement du sillon de l'empreinte, un îlot ou un autre élément particulier.

Le système est en général incapable de tout détecter à chaque mesure, donc on ne s'intéresse à la validité que d'un certain nombre de points en même temps.

Les capteurs ont beaucoup progressé sur la question, mais pour avoir travaillé dessus sur un petit projet, le capteur d'empreinte a les inconvénients suivant :

• C'est sensible à la pression (si tu presses fortement, le doigt se dilate et certaines caractéristiques disparaissent), d'où le fait qu'à la configuration on demande de repositionner le doigt et de varier la pression pour avoir un bel échantillonnage ;
• Un doigt ça se perd, par accident ;
• Si tu te coupes sur l'empreinte, ça ne fonctionnera pas le temps de la cicatrisation, si la cicatrice disparaît ;
• De même pour les brûlures ;
• Reproduire une empreinte pour les capteurs usuels est facile, idéalement il faudrait vérifier avec de la chaleur ou de la pulsation cardiaque si c'est bien un corps humain derrière l'empreinte.

Bref, aucune technologie n'est parfaite, et sans doute pas adapté à tous les usages. J'apprécie de pouvoir faire des choses administratifs de ma femme sans devoir demander son doigt pour accéder à un site surtout quand elle n'est pas avec moi.

C'est très optimiste, les fabricants de processeurs ont plutôt des projets qui prennent quatre à cinq ans de recherche et développement.

2020 c'est dans deux ans (voire trois si on considère fin 2020), c'est un objectif qui est réaliste. Et Spectre apparemment est connu des fondeurs depuis plusieurs mois (voire une demi-année).

Pour Spectre, c'est toute la mécanique d'exécution spéculative et de prédiction de branchement qui est à revoir donc on touche vraiment aux fondements des processeurs et là ce sera plutôt quatre ans (donc plutôt Zen 2 ou 3 que le prochain Zen+ chez AMD). De plus, c'est un nouveau vecteur d'attaque entier à explorer donc on va certainement trouver d'autres choses.

Mouais, je n'en suis pas si sûr.
En admettant que Spectre ne génère pas de petits (ce qui dans ce cas demandera sans doute du temps pour immuniser toute la puce), je ne crois pas que cela soit si fondamental.

Faire un nouveau processeur prend du temps, mais ce n'est pas la micro-architecture qui prend tout ce temps. Car dedans tu as la conception de la finesse de gravure, des nouvelles instructions à fournir, ajouter des nouveaux standards qui peuvent être complexes (une nouvelle norme DDR, USB ou PCIe cela n'est pas un petit travail à ajouter). Sans compter aussi toute la partie graphique ou encore de la consommation d'énergie où notamment Intel a beaucoup d'efforts à fournir.

Non pas que la question du pipeline et de la mémoire cache ne soit pas importante, mais les 4 ans de R&D pour une génération ne sont pas consacrées à ces questions en général.

Pour l'instant nous ignorons si Spectre est plutôt simple à résoudre d'un point de vue matériel ou non, et si Spectre va induire la découverte d'autres soucis similaires. 2020 ne me semble pas déconnant dans le cas simple ou normal. Ce qui est certains c'est que il ne faut rien attendre en 2018.

On aurait un boot un peu standard

Cela ne fait pas tout.

qu'on pourrait envisager bien plus facilement de basculer sur des OS alternatifs.

Pour moi l'OS alternatif n'est qu'un pis aller, je ne trouve pas que le fait qu'on puisse installer un Linux sur une machine avec Windows rende le tout au niveau garantie comme acceptable. Car la quasi totalité des utilisateurs vont conserver l'OS d'origine (éventuellement à jour mais cela en restera là).

Ce que tu cites règle qu'une partie des soucis avec nos téléphones. Et certains problèmes resteront vraisemblablement insolubles tout comme pour nos ordinateurs.

Car un téléphone c'est quand même un gros travail d'intégration logicielle et matérielle. Typiquement si tu veux un bon rendu des photos, le pilote du capteurs bas niveau doit être fait aux petits oignons et l'application qui l'exploitera utilisera bon nombres d'informations du capteur pour améliorer le rendu. Il ne suffit pas juste d'un pilote générique avec un logiciel standard pour avoir un rendu aussi bon que celui vendu par le constructeur. Et c'est ça pour de nombreux composants.

Tu peux voir ce phénomène sur PC aussi, où l'autonomie et certaines fonctionnalités ne sont disponibles que sous Windows, faute d'un support suffisant ailleurs grâce au travail fourni par le constructeur lui même.

L'autre problème persistera toujours : les logiciels grossissent et c'est un phénomène naturel. Nos machines devenant plus puissantes, ne pas l'exploiter serait un gâchis. Comment garantir donc que l'usage d'une application ou la consultation d'un site Web donné soit possible dans le futur avec la même machine ? Le garantir aurait un coût énormes car il faudrait potentiellement maintenir plusieurs versions en parallèle. À part changer de logiciels pour utiliser des alternatives moins gourmandes ou réduire la voilure dans ses usages, il n'y a pas beaucoup de solutions.

Ce phénomène existe sur PC, avec le temps à usage constant les ralentissements apparaissent. J'ai un ordinateur de 6 ans d'âge, sans changer d'usage quotidien ce n'est clairement pas la même réactivité et le matériel n'est pas en cause. Tous les logiciels ont pris de l'embonpoint et pour de bonnes raisons (il y a beaucoup de nouvelles fonctionnalités, ou la qualité du contenu visionné est plus haute en moyenne aussi). Que j'utilise Linux, Windows sur un téléphone ou un PC n'a qu'un impact marginal sur la question.

Il faut réaliser tout cela, tous ces impacts. Blâmer uniquement le constructeur de votre téléphone est une erreur, le problème vient de l'ensemble des acteurs (du fondeur des différentes puces, aux constructeurs, aux développeurs de toutes les applications et aux utilisateurs eux mêmes) et il est difficile de concilier tout le monde (d'autant que tous les développeurs et tous les utilisateurs n'ont pas les mêmes attentes).

La situation n'ira probablement mieux que le jour où les performances stagneront, pour des raisons physiques ou économiques. D'ailleurs depuis le ralentissement de l'augmentation des performances de téléphones (qui a été frénétique au début des années 2010) la situation semble s'améliorer sur ce point, un téléphone bas ou milieu de gamme est capable de tenir de plus en plus longtemps.