Renault a écrit 7419 commentaires

Mais le reste, que ce soit la libgtk3 ou le compositeur utilisé par ton gestionnaire de bureau, ça n'a rien de si particulier qui en ferait un truc à considérer comme faisant partie du « système ». Ou alors, je demande à voir quel serait le critère, pour que ça ne dérive pas selon la sensibilité du lecteur.

Le critère dans la plupart des projet atomique c'est que le système qui fonctionne en atomique est le minimum pour démarrer le système et qui soit fonctionnel pour l'utilisateur.

Mais bien sûr ça dépend des usages.

Pour un usage bureautique c'est afficher un bureau où tu peux télécharger / mettre à jour / supprimer des applications. C'est logique en même temps, si un utilisateur novice n'a pas accès à son environnement graphique il ne pourra rien faire, le système est non fonctionnel et il faut revenir à l'état précédent. Si GNOME Shell ne démarre pas car le lien mesa-GTK3 est cassé avec le pilote graphique Intel, le système n'est pas fonctionnel.

Pour un usage serveur ou conteneur, c'est le système minimal qui initialise le matériel et logiciel qui permet de démarrer l'application (ou les applications) souhaitées. Donc là pas besoin d'interface graphique dans la base du système. Le système de base sera plus léger.

En fait tu te concentres sur le critère technique alors qu'ici on se base sur "l'expérience". La notion de système dépend de l'usage que sera fait de l'ordinateur. Pour un serveur inclure GNOME Shell dans la notion de système n'a pas un grand intérêt, pour un utilisateur bureautique ça l'est. Il est donc normal qu'il y a de 'larbitraire car l'objectif est justement de s'adapter à des cas d'usages différents.

Et d'ailleurs, suffit de regarder les autres systèmes. Oui tu parles de Linux+systemd+libc = système sous Linux. Mais sous Windows, le système c'est un tout. C'est le noyau de Windows, son environnement graphique, quelques applications de base, etc. Pareil pour macOS, pour Android, iOS, etc. Et pour beaucoup d'utilisateurs je pense que le curseur de systèmes / application sera différent du tien. En fait tout est arbitraire, la question est de savoir ce qu'on veut faire fonctionnement parlant.

Se concentrer sur l'espace noyau + quelques outils autour c'est trop restrictif, tu ne fais rien avec ça.

mais pour ouvrir un truc avec Firefox il faut que je pense à le copier ou à le lier dans le répertoire « Téléchargements » parce qu'il n'a accès qu'à ça.

Ou alors tu configures les permissions du bac à sable ?

Avec l'application Flatseal par exemple tu peux prendre n'importe quelle application Flatpak et augmenter ou réduire les droits. Tu veux donner accès à tout le système de fichiers de la machine à Firefox ? Tu le peux. Uniquement le répertoire utilisateur ? Tu le peux aussi.

Et c'est justement un gros point fort. Tu utilises une application car tu en as besoin mais tu n'en as pas une confiance absolue (genre logiciel proprio pour le boulot), hop dans le bac à sable avec les paramètres que tu veux.
Ou à l'inverse, Firefox est libre mais c'est gros, ça a des bogues, des failles de sécurité, tu peux réduire au maximum les accès en fonction des besoins pour limiter les dégâts.

Et c'est très bien, c'est un atout réel.

J'ai quand même l'impression que dans ce fil tu n'as pas beaucoup expérimenté et que tu émets des critiques qui n'ont pas lieu d'être. Sans dire que c'est parfait, c'est bien plus puissant et fonctionnel que tu ne le penses.

De même pour Linux, il existe des tas de solutions pour changer le kernel en live sans redémarrer (typiquement ce qui est fait dans les serveurs cloud, les machines virtuelles ne sont pas interrompues lorsque le porteur redémarre son noyau). Il faut pour cela que les drivers soient capables de correctement sauvegarder leur état et/ou faire un reset propre. C'est exactement la même problématique pour la veille prolongée (hibernation), le noyau sauvegarde ses états sur disque et les recharge en redémarrant. Si tu supprimes la phase "boot" au passage (qui n'a rien à faire lors d'une mise à jour), tu as une mise à jour transparente pour l'utilisateur (au pire, un freeze de quelques secondes pour la récréation des zones mémoires).

Alors le live patching du noyau ça fonctionne mais pas pour tous les correctifs non plus et c'est loin d'être trivial à exploiter.

C'est vraiment conçu comme un moyen de corriger pour de grosses failles ou gros problèmes immédiatement avant de procéder à un redémarrage plus tard à un moment plus opportun comme le weekend ou la nuit par exemple.

De toute façon il faut redémarrer aussi pour la mise à jour de certains composants type systemd ou libc de temps à autres.

La course à l'uptime n'est clairement pas une bonne stratégie de sécurité de nos jours.

Ça ne prouve rien, j'ai pu avoir de la chance, mais est-ce que la différence des formats de paquets et des outils RPM / dpkg peut expliquer ça ?

Non, car ça m'est aussi arrivé d'avoir le soucis avec RPM et relancer la procédure a fonctionné.
Que tu utilises RPM ou DPKG cela ne change rien car mettre à jour un système c'est une opération +/- longue et que si ça s'interrompt au milieu tu n'as aucune garantie que ça fonctionnera bien après.

La seule solution pour n'avoir aucun problème c'est d'avoir la possibilité de faire une mise à jour de manière atomique d'une façon ou d'une autre : si ça fonctionne, tu utilises le système à jour, si ça n'est pas allé au bout, tu gardes le système tel qu'il était et tu recommences la procédure.

Et ça nécessite vraiment une distinction artificielle entre logiciels de base et logiciels supplémentaires ?

Oui.

L'objectif est d'améliorer aussi la robustesse, la sécurité et la fiabilité.
Si tu mets trop de composants dans le système de base, tester dans le détail l'intégration c'est compliqué. Plus de risques qu'il y ait des problèmes profonds qui peuvent compromettre le démarrage de la machine, processus de mises à jour plus lentes car rebaser avec des application en plus c'est lent.

L'objectif est qu'un maximum d'applications soient distribuées via Snap ou Flatpak dans ce modèle. Plus de sécurité grâce à l'isolation logicielle mais aussi plus de flexibilité car si tu souhaites avoir Firefox beta + Firefox stable en même temps sur ta machine c'est facile. Si tu veux le dernier LibreOffice également, tu ne dépends plus uniquement du cycle de ta distribution qui est une contrainte pénible pour beaucoup d'utilisateurs.

La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.

Cela paraît simple, mais en vrai ça ne fonctionne pas toujours aussi bien. Car là tu décris le cas idéal. Le cas le plus courant mais il est illusoire de croire que les soucis n'arrivent jamais.

En pratique ce que tu décris se fait déjà, mais il faut voir les problèmes qui peuvent survenir.

Que se passe-t-il si tu as une coupure de courant ou un crash au milieu des opérations ? Pour l'avoir expérimenté, ton système peut être dans un état irrécupérable car tu as des fichiers à jour, d'autres pas pour un paquet, tu as un paquet à jour mais ses dépendances (ou ce qui en dépendent) qui ne le sont pas, la BDD RPM qui est dans un état incohérent, etc.

Une mise à jour implique des scripts notamment de conversions de fichiers, de relance de services et autres et parfois pas de bol il y a un problème ou un conflit avec l'usage normal de la machine et hop pépin.

Ou tu démarres une application alors que certains fichiers sont à jour et pas les autres, ou qu'un paquet est à jour et pas sa dépendance et tu peux avoir des crashes ou bogues bizarres.

Ce n'est pas un hasard si l'industrie migre vers ce genre de conceptions. Dans l'embarqué cela se fait, sur les téléphones cela se fait, Windows le fait, GNOME Logiciels le fait, les systèmes atomiques le font, etc. C'est pour cette raison, pour couvrir correctement les cas où il y a des soucis potentiels.

Le dernière point est très intéressant, en revanche, pour les deux premiers, j'ai dû louper le moment où le fonctionnement à la Windows, où il faut redémarrer pour appliquer des mises à jour, avait commencé à être considéré un modèle.

Alors il y a des différences avec Windows en fait.

Tout d'abord c'est juste la base du système qui est concernée. Noyau, libc, systemd, etc. C'est la couche 0 du modèle d'un système atomique qui répond à ce critère. Cela ne touche pas le reste. Donc à priori ce n'est pas tous les jours que tu auras un tel changement.

D'autre part, la mise à jour fonctionne par état. En gros c'est comme "git" pour le code d'un projet, la mise à jour est juste un rebase à partir d'une branche spécifique. Le rebase se fait lorsque le système tourne normalement. Le redémarrage ne sert qu'à changer le commit de référence pour exécuter le système. En gros au redémarrage c'est quasiment instantanée, contrairement à Windows où ça prend du temps. Car la partie longue aura été faite quand l'ordinateur est utilisé normalement.

Avec ce fonctionnement, comme cela a été expliqué, l'avantage c'est que de revenir en arrière est fiable et tout aussi rapide si c'est nécessaire. Cela peut même se faire automatiquement si la machine est incapable de booter entièrement avec le nouvel état du système.

Enfin, oui l'approche de Windows reste théoriquement une bonne approche malgré tout. Des bogues qui arrivent et qui sont difficiles à corriger ou à identifier car on met à jour lorsque que le système tourne, cela arrive même sous Linux. Et si ton système crashe en pleine mise à jour pour X ou Y raisons, les problèmes peuvent vite s'accumuler. Appliquer les mises à jour quand le système est dans un environnement minimaliste réduit ces problèmes, en terme de fiabilité c'est mieux quoiqu'on en pense.

L'avantage ici c'est que la partie minimale du système nécessite une telle approche tout en restant fiable et le redémarrage reste une opération très rapide ce qui limite l'inconvénient de Windows.

Bien sûr, mais ce que je mentionne c'est qu'on n'a pas la preuve non plus que Meta sait y accéder à ces conversations.

Et qui si on en avait une preuve sérieuse, cela mériterait clairement une communication de la part de celui qui a une telle preuve sous la main.

Sauf que Whatsapp fait du chiffrement de bout en bout.

Les autres services de Facebook et Instagram ne le font pas et peuvent en effet être déchiffrés par Meta pour faire ce qu'ils veulent ce qui concerne des milliards de personnes depuis 2007 effectivement.

Ton lien ne parle pas spécifiquement de Whatsapp, si on a des preuves que Meta peut lire des conversations Whatsapp sans effort, ça mériterait une publication.

je m'interroge sur les fanfaronnade européenne la dessus, et du partage du lien vers cela qd bien même il s'agit d'un journal, dans la loi il n'y a pas écrit sauf les journaux.

Définir conversation privée alors que c'est manifestement un groupe de travail gouvernemental étranger dont la publication a été autorisée par le président des USA lui même car ce n'est pas un document classé secret défense. C'est pour ça que le journaliste américain l'a fait, car il en avait le droit, et de fait comme c'est public il n'y a aucune raison que la presse ne puisse pas relayer.

Par ailleurs comme souvent en droit, il y a des contradictions. La presse a aussi des libertés pour permettre de relayer ou de dénoncer des affaires d'intérêts publics. Pourtant cette liberté essentielle est nécessairement contraire à d'autres dispositions légales. Et cela ne pose pas un problème.

Enfin, la fuite à l'origine est purement américaine (discussions impliquant des américains, sur le territoire américains et publié par un journal américain par un journaliste américain), c'est donc le droit américain qui est d'application et pas le droit français. Le droit américain n'a pas le RGPD et le journaliste a eu l'accord officiel de le faire. Donc depuis cela n'a plus rien de privé car cela a été légalement publié. Puis je croyais que la liberté d'expression absolue était une belle valeur américaine au demeurant.

Bref, il n'y a aucune raison pour que ton commentaire soit pertinent ici. Mais étant données tes commentaires ici je me demande si cela n'est pas juste une réaction par rapport à tes convictions politiques.

Juste que répondre sur quelques requêtes qui ne respectent pas le robots.txt ne me semble pas être une bonne défense à l'heure actuelle, même si j’aimerai que ce soit le cas, et qu'on remette un peu d'ordre dans ce far west de l'entrainement des IA.

Tu parles de l'heure actuelle et je suis d'accord avec toi.

Personnellement je pensais adapter la loi pour couvrir notamment le premier point. Cela ne me semble pas insurmontable.

Après le site tu le mets bien à disposition du public, donc en quoi une requête d'un outil serait moins légitime (point de vue légal) que celle d'un autre utilisateur? Après je parle bien d'une requête, et pas d'une armée mal codée qui relis les pages encore et encore alors qu'il n'y a aucune modification dessus.

On peut attaquer l'usage plutôt que la requête en elle même.

L'objectif est de collecter de l'info pour en faire quelque chose. Un service autour d'un LLM, l'apprentissage du LLM, ou alimenter la BDD d'un moteur de recherche. On pourrait arguer que le propriétaire du serveur ne souhaite pas que le contenu certes public puisse alimenter ces services et que on devrait pouvoir respecter ce choix.

Ou de même attaquer non pas la requête individuelle qui a un coût dérisoire mais la conséquence d'un suivi agressif qui fait augmenter les coûts d'hébergement de manière significatives voire réduire les performances du système et peut s'apparenter de fait à un DDOS que le respect du souhait initial permettrait d'éviter.

La loi pourrait s'adapter autour de ça. Après tout on a bien des lois plus difficiles à gérer que ça dans le fond.

Merci pour la contribution en tout cas. :)

hash(id_compte+sel_du_site+mdp)

Autant faire un sel par compte directement, ce qui est recommandé par ailleurs. Plus besoin de l'id du compte.

Cela ne contredit pas ce que je dis au contraire.

Avec cette information c'est très facile de savoir s'il y a beaucoup d'hommes qui achètent les tenues pour leur conjointe voire toute la famille, ou juste pour eux. Et de même dans l'autre sens.

En fonction de ce qui se fait, l'entreprise peut adapter sa communication, pour consolider son marché actuel ou tenter justement d'accueillir une autre clientèle.

Cela peut avoir un intérêt marketing aussi.

Si la majorité de tes clients sont des hommes ou des femmes, ça peut être intéressants pour eux de le savoir pour adapter leur communication notamment pour attirer une plus grande diversité de clients et savoir ce qui a marché dans leur stratégie actuelle concernant leur public cible du moment.

Cela ne m'étonnerait pas que les grosses boîtes le fassent plutôt dans cette optique que pour afficher le bon texte pour ton courrier.

La croisade anti-spyphone d'aujourd'hui me fait un peu penser à celle pro-linux d'il y a 15 ou 20 ans, et qui n'a jamais mené à rien.

Qu'il y ait une croisade basée sur des arguments sérieux, je ne pense pas que ce soit un soucis.

Dans la discussion autour des téléphones, notamment par l'auteur du lien mais on le voit dans les propos tenus dans les articles et ce genre de personnes en général, il y a un mélange des genres.

Beaucoup d'arguments ne sont pas contre le smartphone mais contre l'hyper connectivité. Pour avoir connu l'ère avant les smartphones, j'ai connu des gens hyper connectés avec leur téléphone portable à l'époque. Décrocher systématiquement en toute occasion, y rester 3h pour une discussion, lire / répondre au SMS dès qu'un message a été reçu, etc.

Si le soucis est celui là pour ces personnes, se passer du smartphone peut être une solution, mais la bonne solution peut être aussi d'en avoir un mais s'en servir selon ses propres besoins et envie. Couper les notification / mode avion / mode silencieux quand on en a besoin, ne pas répondre dans la minute, etc. Beaucoup de gens savent très bien le faire avec un smartphone et peuvent bénéficier des autres fonctions quand ils le souhaitent sans se priver.

Je trouve cela embêtant de faire un amalgame des deux sujets à chaque fois. On peut refuser légitimement d'avoir un tel objet si on veut, mais utiliser des arguments un peu bancal c'est à mon sens contre productif.

Ben, je n’ai pas de thèse.

Bah si, la preuve, tu détailles son point de vue juste après.

Simplement, je pense qu’il y a une hystérie autour de la question climatique que je trouve inquiétante

Une hystérie alors que c'est clairement une menace importante qui concerne ce siècle en cours et que malgré les alertes on ne fait pas assez d'efforts pour rester à des seuils raisonnables ?

Le changement climatique est devenu l’alpha et l’omega de tout :
- ouragan = changement climatique
- pluie = changement climatique
- sécheresse = changement climatique
- séisme = changement climatique
- éruption volcanique = changement climatique

Alors je ne sais pas ce que tu lis mais la presse me semble assez prudente de même que les scientifiques à ce sujet en disant que "cet événement de cette ampleur ou à cette fréquence aurait été improbable sans réchauffement climatique". Et qu'il est difficile d'attribuer à un événement ponctuel de manière sûre une cause de toute façon.

Exemple concernant le cyclone à Mayotte : https://www.rtbf.be/article/il-n-y-a-pas-plus-de-cyclones-mais-ils-depassent-plus-souvent-250-km-h-de-vitesse-de-vents-11484084

Le Giec ne s'est pas trompé…
Ces données illustrent les conclusions du Giec, le groupe d'experts climatiques de l'ONU, selon lesquelles l'augmentation de la proportion de cyclones violents (catégorie 4 et 5) est un effet attendu du réchauffement climatique.
"Si le changement climatique est à suspecter pour ces évolutions, ne nous trompons pas, les catastrophes humanitaires générées par ces cyclones sont, elles, largement dues à la pauvreté, à la vulnérabilité et au manque de protection des populations touchées", explique Robert Vautard, climatologue et haut responsable du Giec. […]
Le cyclone Chido, qui a ravagé Mayotte en décembre, a lui-même été rendu plus puissant par le changement climatique selon une étude préliminaire britannique, qui estime que le réchauffement climatique a rendu les vents plus forts d'environ 5%, le faisant passer de la catégorie 3 à la 4.

C'est très prudent. Et ne t'inquiète pas, ce ne sont pas que els Belges qui font ça, exemple avec France Info : https://www.francetvinfo.fr/environnement/evenements-meteorologiques-extremes/cyclones-et-ouragans/cyclone-chido-a-mayotte/quelle-a-ete-l-influence-du-rechauffement-climatique-sur-le-cyclone-chido-qui-a-ravage-mayotte_6962345.html

Pareil, beaucoup de conditionnel, avec des preuves à consolider, des semble, etc. qui jonchent l'article.

Je me rappelle quand même qu’à l’été 2023, on nous annonçait qu’il faillait faire peut-être le deuil de certaine régions agricoles françaises faute de pluie, qu’il faillait s’habituer au manque d’eau. Sincèrement, ça m’a (vraiment) travaillé à l’époque (on était il est vrai dans la troisième année de manque d’eau prononcé) alors que je vis dans une région « humide », la Sarthe (les douches ont été démontées de la base de loisir de la ville pour « préserver l’eau », elles ne sont toujours pas remontées) : or, hormis cette semaine, ça fait 18 mois qu’il pleut sur une bonne moitié nord de la France.

Cela n'est pas antinomique. La période actuelle est en effet humide dans le nord de la France et en Belgique mais les années précédentes ont été assez sèches. Cela ne signifie pas que cela ne va pas continuer à s'assécher de manière globale à l'avenir dans ces régions malgré des températures parfois froides et des saisons plus humides.

De la même façon qu'il neige de moins en moins dans le Nord de la France et en Belgique ou même les montagnes françaises. Mais parfois on a des vagues de froid record et des neiges abondantes.

C'est bien de se poser des questions mais là tu reprend des arguments des climato-sceptiques assez basiques.

Et en attendant, rien sur ne serait-ce qu’un éventuel questionnement sur passer à autre chose que le capitalisme.

En tout cas remettre en cause le capitalisme ne garantie en rien que le résultat sera meilleur pour l'environnement et le climat.

Est-ce que tu sais qu’il n’y en a pas ou est-ce qu’ils n’ont pas était trouvé ?

En plus de cela, le buffer overflow n'est pas la seule cause d'erreurs de mémoire qui est d'ailleurs peut être la plus simple à éviter avec de bonnes structures de données.

Par contre des race conditions, des deadlocks, des use after free (ou double free) dans un contexte multithread, etc. c'est assez courant (notamment dans le noyau Linux par exemple) et difficile à éviter. Si Rust ne peut pas empêcher toutes ces erreurs de survenir (notamment à cause des unsafe), le risque est bien plus réduit par défaut et le débogue plus facile quand ils surviennent.

La réalité, c'est peut-être que jamais de telles responsabilités ne devraient reposer sur une personne, que ça soit un random, un dictateur bienveillant, ou un élu.

Le prérequis pour que le tirage au sort fonctionne est dans la diversité des personnes tirées au sort.
Donc il faut donner un maximum de pouvoir à l'Assemblée ainsi désignée et que l'exécutif soit responsable devant elle.

C'est assez antinomique du fonctionnement des USA sur ce point.

La justice néerlandaise a obligé MS à remettre les données aux mandataires de la banque, qui ont pu faire le nécessaire pour que les clients puissent aller voir ailleurs et que la faillite de la banque soit sans trop de conséquences. Mais nul doute que si les US n'avaient pas voulu de cette solution, la justice UE se serait vue bien embarrassée.

C'est un bras de fer, mais cela ne signifie pas que les USA ont tout pouvoir non plus. Car évidemment que MS pourrait se voir obliger par l'administration américaine de refuser de céder à la justice Européenne, mais cela peut avoir des conséquences. MS a une présence en Europe, des structure juridiques européennes, des revenus qui viennent du marché européen et évidemment un bras de fer peut pousser à des mesures de rétorsions contre les USA ou MS et pousser à terme de s'en détacher suivant où ça va.

C'est d'ailleurs peut être une tendance qui démarre avec l'hostilité manifeste de l'administration Trump envers ses alliés historiques.

De la même façon que la France peut imposer des choses à ses entreprises nationales mais les états étrangers peuvent réagir en conséquence et d'ailleurs le font.

Je pense que c'est surtout une question de définition plus qu'autre chose ici. J'ai bien précisé ce que j'entendais par fork ce que Linus n'a pas expliqué dans ce texte et selon la définition que je donne (qui me semble être la plus courante) Android n'a jamais été dans ce cas de figure.

Et je ne trouve pas la définition sous entendue par Torvalds (à savoir qu'Android avait des correctifs en dehors de la branche principale) soit très intéressante pour décrire cette situation, il y a d'autres termes plus adaptés selon moi comme branch out of tree.

Cela m'étonnerait comme Linux doit proposer justement l'API qui permet à la bibliothèque C de proposer une telle fonctionnalité.

Linux a sa propre gestion des threads via des "kthread" qui n'ont rien de standard comme de nombreuses choses dans le noyau usuellement fournis par la bibliothèque C.

Ça me semble tendu de définir le fork de cette manière, parce qu'il est quand même assez courant que les forks intègrent au fil de l'eau les corrections de bugs ou autre issus de la branche principale…

Enfin là on ne parle pas de deux projets distincts qui de temps en temps se recopient des correctifs, on parle du fait que le noyau Linux d'Android c'est toujours le noyau Linux "principal" + une collection de correctifs maison.

C'est très différent, Android tire en permanence profit de ce qui arrive dans la branche principale et n'a clairement pas les ressources pour faire évoluer le noyau de manière totalement indépendante dans leur coin.

"So, for the next few years, Android, while still a Linux, is indeed a Linux fork. In the long run, though, Torvalds is sure that Android will return to the mainstream Linux kernel. For better or worse though that may not be until 2016. Fortunately, for all end-users and almost all Android developers none of this will make any real world difference."

Mouais, c'est une branche out of tree comme on dit, comme l'a été pendant longtemps la branche Linux-rt par exemple, à mon sens ce n'est pas un fork.

Mais pour Torvalds c'était important que Android réduise l'écart avec le noyau Linux de base, car certains correctifs sont pertinents pour tout le monde, et cela simplifie la maintenance.

Donc, ça compte, ça ne compte pas comme un fork… C'est quand même pas si net. C'est un ex-fork, peut-être.

L'écart entre le Linux AOSP et Linux vanille a été fortement réduit aussi par rapport à cette époque. Mais même à l'époque le considérer comme "fork" n'a pas beaucoup de sens. Au sens git du terme c'était (et c'est toujours vrai) car ce sont des branches à part mais dans ce cas là le Linux vanille n'existe nul part car toutes les distributions ont leur propres branches +/- modifiées. D'autant plus que Android comme toutes les distros se rebasent toujours sur le noyau Linux principal, l'inverse étant faux. Le flux est donc toujours à sens unique ce qui confère le caractère "Linux officiel" qui fait référence pour tous ces projets.

Comme ce ne sont pas des projets indépendants à partir d'un point spécifique dans l'historique du code source, les considérer comme fork me semble abusif. Google ne développe pas un projet Linux indépendant du reste de l'écosystème maintenu uniquement par ses soins, s'ils voulaient remplacer le job abattu par le projet Linux officiel ils devraient recruter pas mal de monde en plus. En ce sens ils dépendent toujours des décisions de Torvalds et de ses mainteneurs.

Android, ça compte pas?

En effet, ça ne compte pas.
Déjà il faut clarifier ce dont on parle. Linux est un noyau c'est ce projet qui est édité par la Linux Foundation et maintenu par Linus Torvalds et les autres mainteneurs qui travaillent avec lui.

Android est un système d'exploitation complet qui utilise Linux et plein d'autres composants qui serait donc équivalente plutôt à Ubuntu / RHEL / Debian / Fedora, etc.

Android est vraiment différent sur plein d'aspect par rapport aux autres distributions, mais concernant le noyau lui même ce n'est pas très différent. Il y a quelques centaines / milliers de correctifs en dehors du noyau Linux "officiel" (mais c'est le cas pour toute distribution de toute façon), certains finissent dans le temps dans la branche principale, d'autres pas.

Ce n'est donc pas un fork car ils se basent toujours sur la branche principale pour fournir de nouvelles versions de leur côté, comme toute distribution Linux classique.

La taille de la base de code est peut être un chouilla impressionnante pour un candidat au fork.

C'est en effet compliqué mais pas impossible.

S'il y a vraiment consensus que Linus Torvalds gère mal le projet d'une façon ou d'une autre, un fork pourrait arriver par un accord entre les gros contributeurs qui sont des entreprises. Ou en poussant Linus Torvalds à la retraite du projet.

Perso les phrases me semblent compatibles avec mon interprétation.