Ok, j'ai dû alors me fier à une source pro-Mozilla qui a présentait cet échec un peu comme je l'ai mis ici.
La vidéo parle uniquement de cette problématique dans le monde des ordinateurs, au moment pointé. Mais je comprends l'idée pour les systèmes d’exploitation en général.

c'est pas complètement faux.. mais il y a "vendre" et "vendre". Pour firefox, mozilla le vend par son critère bienveillant.
Cette approche n'est pas fonctionnelle pour un OS grand public : évidemment qu'il faut avoir des adorateurs, un public conquis, mais si il reste de niche..

pour FFos, c'est comme pour sailfish, deux options :
-soit vendre soi-meme l'appareil, en le fabricant/commercialisant (ex sailfish  avec le jolla, ou encore kaios)
-soit en trouvant un partenariat pour le vendre, qui accepte de le distrbuer contre royalties.

y'a pas mal de petits exemples, wphone qui était sur les nokia windowsés ET sur certains HTC. Un OS non fourni sur un téléphone sera toujours marginal. Comme le dit torvalds, si google n'avait pas encouragé les fabricants à utiliser son android, linux n'existerait pas/peu sur téléphone ; avant 2012, les samsung avaient bada (ou un nom ressemblant), un os qui n'avait rien à voir avec android. C'est à partir des galaxy qu'android remplace son prédécesseur.

Mais à part quelques geeks,  qui va installer soi meme l'OS d'un téléphone? Comme pour les PC : personne. Faut s'y connaitre, les gens veulent pas apprendre..

Y'avait eu le moko, portable complètement oublié, fonctionnant sous debian, sorti... dix jours après le tout premier iphone. Il a eu un premier public, puis est tombé dans l'oubli.

Un système alternatif, surtout pour G/P, ne peut être adopté si le logiciel n'est pas fourni avec le matériel.. etquand on regarde, sur pc, combien dell en a vendu sur ubuntu.. plus cher que windows, et échantillonnesque..

Merci, crcr.
Ca ressemble quand même beaucoup à de l'obsolescence programmée voulue.

Leon.

comme la transition de x86 à x86_64, avec dès 2015 des gros logiciels (suite adobe par ex), qui ne prennent plus qu'en charge le 64, regardant de haut ceux restés sur le bas coté de la route en 32.
le noyau linux ne prends plus en charge les premiers cpu intel :
https://arstechnica.com/gadgets/2025/05/linux-to-end-support-for-1989s-hottest-chip-the-486-with-next-release/

mais oui ca donne clairement ce résultat là. On l'avait déjà vu avec les applis :
https://www.rtl.be/actu/belgique/lapplication-bancaire-de-michel-ne-fonctionne-plus-sur-son-telephone-de-2018-je/2023-04-24/article/533828
https://www.frandroid.com/marques/apple/904391_peut-on-garde-un-iphone-4s-pendant-10-ans%E2%80%89-le-materiel-fonctionne-mais-cest-complique

l'autre notion à bien cerner :
en informatique, les ordinateurs, à l'exception de marques particulières anciennes (amiga, atari, mac-ppc), se sont tous unifiées, par IBM, sur un standard : l'ibm pc. C'est ce standard qui s'est imposé sur les pc, et qui "commande" au bios (ou à l'efi), de gérer par ce biais, les différents composants matériels. En clair, n'importe quel os "compatible pc", compatible avec la génération de processeur (32, 64..), pourra fonctionner sur l'appareil. D'où la cohorte d'OS tiers, l'armée de linux, les mac "compatibles pc" (mac intel), les windows, les unix tiers (haiku, redox, et plein d'autres petits systèmes à la kolibri), pour utiliser un logiciel différent en partant d'une même base unifiée : le standard ibm/pc.

Le gros avantage : tout le monde par d'une base commune. Elle évolue (le CPU) avec le temps, les logiciels s'adaptent. Et la plupart des matériels sont compatibles, par génération, à part p-e le CPU, parfois "bloqué" sur intel ou amd..
Le gros inconvénient : ça consomme.

Maintenant, regardons de plus près le principe du mobile : il fonctionne sur de l'arm. L'ARM? des schémas de composants, d'organisation électroniques, qui sont loin d'être simples à comprendre.
Deux éléments fondamentaux :
-l'arm est un miroir inversé du monde PC. En ARM, un circuit/CM électronique est "unique", et le logiciel **DOIT** savoir à quel endroit, se trouve quel type de composant. Sinon, ça ne fonctionnera pas. C'est pour ça qu'il est très compliqué de proposer des ROM sur smartphone (ou autres appareils), parce que cela demande un lourd trvaail d'adaptation du logiciel, linux ou pas linux. Pareil dans la crèmerie d'en face chez apple : adapter Darwin/xnu/macos, à un tout petit appareil, pour donner l'iphone : des heures de R/D pour adapter le logiciel, à cet appareil là exclusivement.
-la société ARM ne fabrique rien : elle imagine, concoit, des schémas, qui devront ensuite être fabriqués sous licence par des "fondeurs", qui fabriquent des composants à destination des fabriquants de téléphone.

le plus gros incovénient de l'arm : c'est du sur mesure à tous les étages, point. Pas d'équipe pour adapter le logiciel "bas niveau" (=OS, pilotes..), pas de système.
le plus gros avantage de l'arm : ça consomme très très peu. grosses avancées en miniaturisation. Parfait pour la mobilité.

En gros, comme dans le monde PC, il peut y avoir des dizaines d'interfvenants pour fabriquer le matériel, **mais** il n'y a pas la base logicielle commune. Celle ci est à définir par les protagonistes, de manière à savoir "quel logiciel va devoir tourner dessus". Souvent, le fabricant d'un capteur optique proposera un pilote logiciel pour telle version d'android, et débrouille toi avec. Une version plus récente? Faudra passer à la caisse, on bosse pas gratos. Et comme le pilote est dédié à une version du noyau spécifiquement (c'est ultra complexe). Donc chaque maillon doit faire avec ce qu'il a a dispo, sinon négocier pour espérer un changement.

Le monde ARM, c'est un peu comme des mafieux qui essaient de se mettre d'accord sur les points de revente : y'en aura pas pour tout le monde, y'aura un peu de violence, et les acteurs d'aujourd'hui ne pourront pas être ceux de demain.

Suffit de voir le simple cas de qcomm, apple est parti en procès contre (ça a fini à l'amiable), pour le plus grand plaisir des concurrents. Et y'a énormément de verrouillage concurrentiel à tous les étages. À ça, rajouté le problématiques techniques des pilotes, des fabricants qui appliquent mille patchs en croisant les doigts...

le monde android est un enfer, apple l'a bien compris : la recette? controler de bout en bout, le plus possible, l'ensemble de la chaine.

Les fabricants android secondaires, qui pèsent peu, iront forcément dans le mur (htc a rendu l'ame, LG on en parle plus, etc..)

c'est surtout un choix de compromis, x86 est tout à fait capable de tourner à 5W avec un minimum de performance, intel et amd décident juste d'ignorer ce marché et se contentent des atom/ryzen embedded aux perfs assez basses et à l'io basique.

Intel avait essayé d'entrer dans le marché des smartphones (l'Atom a été conçu pour ça à la base), malgré leur avance technologique sur la gravure à l'époque, ils n'y étaient pas arrivés. Leurs processeurs consommaient plus pour des performances souvent moindres que les ARM concurrents.

Et il y a une raison à ça : x86 est une architecture CISC (Complex Instruction Set Computer), les instructions sont complexes et peuvent faire plusieurs choses d'un coup, là où ARM est du RISC (Reduced Instruction Set Computer) où les instructions sont plus simples.
Au tout début de l'informatique, quand on écrivait en assembleur, les architectures CISC étaient plus simples pour écrire du code et cela leur a donné un avantage pour leur adoption. De nos jours, où on écrit dans des langages haut niveau qui sont compilés, voire interprétés, ça ne change plus rien.
Par contre au niveau de la puce, la différence est présente. Les processeurs CISC ont une partie Fetch et surtout Decode bien plus complexe que les processeurs RISC, ça nécessite des transistors en plus qui prennent de la place en plus et consomment.

Depuis le premier Pentium (1995 ça remonte !) les instructions x86 sont découpées en μop (micro-ops) qui ressemblent plus à un jeu d'instructions RISC. En gros les processeurs x86 sont des processeurs RISC en interne, avec toute une couche en amont pour faire l'abstraction entre x86 et l'architecture interne. C'était nécessaire pour optimiser le traitement, notamment pour faire de l'exécution out-of-order.

rien ne les empêches d'utiliser l'UEFI et ACPI au lieu d'utiliser le devicetree avec un uboot custom, s'ils étaient de bonne foi ça ferait longtemps qu'ont aurait uefi et grub sur tout nos smartphones arm.

Ça je suis assez d'accord, si je voulais résumer tout ce que j'ai lu sur l'écosystème ARM vs x86 et pourquoi on arrive pas à avoir des images linux génériques ARM (alors qu'on y arrive pour x86), les deux obstables majeurs sont :
- l'absence d'une séquence de boot standardisée (on pourrait tout à fait avoir d'UEFI sur ARM)
- le manque de collaboration des constructeurs ARM pour intégrer les pilotes dans le kernel mainline.

côté x86, Intel et AMD contribuent énormément au développement des pilotes et du noyau, fournissent les patchs en avance, prennent les retours et font donc le nécessaire pour que leurs pilotes soient intégré au noyau mainline dans les temps.
côté ARM, les fabricants écrivent leurs pilotes, ne les soumettent pas au mainline mais fournissent à la place leur propre noyau patché aux fabricants de smartphones. Et souvent, ils ne publissement même pas le code source de leurs patchs du noyau, ce qui est en violation avec la licence GPLv2...