Renault a écrit 7255 commentaires

cela a permis une certaine 'auto' discipline et d'avancer malgré des divergences, personnes n'osaient affronter directement Linus ou s’intégrer dans le processus Linux en disant je suis le meilleur du monde laissez moi faire. enfin ! il y en a qui ont essayé ils ont eux des problèmes.

Je pense qu'on peut faire preuve d'autorité et calmer l'ardeur des gens sans aller dans une telle extrémité. Car de toute façon l'intégration d'un commit doit passer par des personnes très compétentes. Donc ne t'en fais pas, ils ont les arguments techniques pour refuser ou faire modifier le travail d'autrui.

Car de l'autre côté, Linus Torvalds a été jusque là un frein pour de nombreux contributeurs qui n'aiment pas le conflit inutile (qui aime ça après tout) et qui se sentent assez intelligents pour améliorer leur travail sans recevoir un flot d'insultes.

Ses remarques sur Intel, qui d'autre à par lui aurait pu leur dire la vérité, franchement intel qui répond : non il n'y a pas de probleme, et du coup cela ne sera pas corrigé.
personne a par lui a osé répondre à Intel, et j’entends par 'personne' des personnes moral ou physique ayant autorité dans le monde informatique.

Je pense qu'il faut dissocier deux choses.
Quand Linus attaque Intel, il attaque une personne morale. La cible étant plutôt floue, l'impact est moindre que quand tu réponds à une personne seule qui défend son commit.

De plus, je pense qu'on peut utiliser des arguments pour mettre Intel en défaut sans devoir recourir à des termes vulgaires. C'est l'abnégation de Torvalds qui a fait avancer le sujet (mais pas que), pas ses mots grossiers.

qui d'autre que lui aurait pu imposer de réécrire la pile USB, de supprimer le big kernel lock ? Nous serions tombé dans un processus comme dans les grosses boites : a tortillé du cul pour chier droit. hein et le passage a GIT, qui l'a oublié ?

Et tout ça ça a marché car il a utilisé des termes comme "merde" un peu partout ou parce qu'il a su justifier ces choix ?

Je pense qu'il faut arrêter de croire que d'être grossier permet d'être efficace. Et techniquement obtenir le meilleur. J'ai eu de bons managers techniques au travail, ils avaient de l'autorité et du caractère mais ce n'est pas pour autant que les débats techniques se finissaient à coup de mots grossiers, d'attaques personnelles et d'autres bêtises du genre.

En général quand on critiquait Linus, ce n'est pas à cause de ses positions fermes, ou de ne pas être lisse. Son soucis est de mélanger allègrement attaque personnel sur fond de débat technique sans justification. Et son vocabulaire n'est pas terrible pour quelqu'un qui gère un projets ayant des milliers de contributeurs et ayant une utilisation dans l'industrie sans précédent. Linux se professionnalise, Linus doit suivre ce mouvement aussi.

Donc je ne sais pas il semble malgre tout assez important pour eux…

Je n'ai pas dit que Linus ne servait à rien et n'est pas important.
Son travail est malgré tout utile, il soulève des points pertinents et a une bonne vision de certaines parties du noyau. Il a un savoir faire.

Mais son départ n'est pas si catastrophique non plus, il est remplaçable techniquement et c'est tant mieux. Sinon Linux devrait mourir avec lui ce qui n'est jamais souhaitable dans un projet.

Je pense que pour l'histoire du sommet sur le noyau, cela montre surtout que Linus est une icône du projet, tout comme RMS l'est pour la FSF / GNU, ou Guido pour Python. Faire un sommet avec lui c'est donc une plu value dans le sens où je pense que beaucoup de gens viennent pour le voir en vrai et parce que malgré tout son poste faisait de lui un élément central du processus de développement.

Avec les éléments que l'on a il n'y a aucune raison de penser que le départ de Linus que ce soit temporaire ou non ait un impact si significatif dans la suite du développement.

Le "savoir vivre" est une notion ancrée dans une norme culturelle qui standardise les interactions humaines… Il y a autant de savoirs-vivre que de cultures différentes et chercher à inscrire nos interactions dans une norme figée est particulièrement rétrograde (« bon sens », « politesse », « galanterie ») et mène généralement à peu de respect et de compréhension.

Définition selon le Larousse du savoir vivre :

Connaissance et pratique des règles de la politesse, des usages du monde.

Je ne crois pas que cela soit aussi négatif que ce que tu prétends.
Disons que dans le cadre du développement du noyau, la notion de galanterie et des us et coutume importe peu. Ce qui compte c'est la politesse.

Je ne connais pas de culture où l'insulte et rabaisser l'autre soit une pratique encouragée. De même pour déployer les mots vulgaires à tout bout de champ. Au contraire. Disons que les cultures asiatiques par exemple ont une approche différente de la politesse (et de ce qui est acceptable ou pas) qu'un européen ou américain. Mais on ne demande pas à Linus d'être parfait et lisse. Le problème est que ttrop régulièrement, même pour la culture occidentale qu'il connaît il va trop loin par rapport à ce qui est attendu de discussions techniques et professionnelles.

L'empathie, au sens commun du terme, ne désigne pas forcément la capacité à ressentir soi-même exactement ce que ressent l'autre personne (seulEs les profs de français savent que « empathie » veut dire « souffrir avec »). Comme nous le rappelle le wiktionnaire: « dans les sciences humaines, attitude envers autrui caractérisée par un effort de compréhension intellectuelle de l’autre ».

Le Larousse n'est pas d'accord avec la définition du wikitionnaire, qui est :

Faculté intuitive de se mettre à la place d'autrui, de percevoir ce qu'il ressent.

Qui rejoint plutôt ma définition, la notion de faire l'effort sans parvenir à percevoir le ressenti d'autrui n'est pas mis en avant. Suivant cette définition de l'empathie (qui est également celle que je mettais en avant dans mon message précédent) avoir de l'empathie n'est aps requis pour dialoguer sereinement avec les autres. Il faut juste éviter d'être désagréable, vulgaire et insultant.

Après suivant ta définition, je suis d'accord avec toi, car c'est exactement ce que je voulais dire avec mon message précédent : faire un effort pour l'autre même si on ne comprend pas forcément sa pensée. En étant poli à cet égard.

Je constate qu'après cette annonce il y a beaucoup de réactions étranges qui selon moi montrent une faible connaissance de comment le noyau fonctionne.

Ce n'est pas parce que Linus s'en va, quelques temps ou définitivement, que cela va s'effondrer. Linus est juste un super mainteneur, il intègre les correctifs que ses mainteneurs lui soumettent. Il ne relisait réellement que les commits dont c'était dans son champ de compétences ou d'intérêts comme l'architecture x86, la mémoire, VFS, etc. La plupart des pilotes ou modifications liées au réseau n'étaient absoluement pas relu par lui même.

C'est l'avantage de la gestion à la Linus, tout ne reposait pas sur un seul homme mais sur une équipe complète. Il fait une grande confiance à ses mainteneurs pour ne pas refaire tout le travail derrière. Le seul risque était l'éventuel guerre de succession mais Greg ayant été désigné et étant un homme de confiance, cela évitera tout soucis de ce genre.

Cela fait quelques temps que la question du comportement de Linus revenait comme un élément problématique. Dans un monde où les contributions ne viennent pas que des USA et d'Europe (donc des cultures différentes) et où la question d'intégrer de nouveaux contributeurs d'horizons diverses se pose. Je trouve salutaire qu'une remise en cause se fasse enfin. Car contrairement à ce que certains pensent, ce n'est pas le vocabulaire fleuri de Linus qui rend Linux si attrayant / efficace techniquement, ce sont les développeurs autour de lui. Il peut garder sa pertinence d'évaluation tout en respectant le code de conduite.

Après est-ce que Linus a vraiment intégré tout cela ? Je n'en suis pas convaincu. Étant donné le calendrier et les discussions qui ont eu lieu, je pense que son entourage ont insisté pour avoir un changement de son côté. Et que la pause sert à digérer cette décision et à se remettre en question car il n'a pas encore tout accepté d'un coup.

Mais Linus l'avait dit dans sa biographie il y a donc 20 ans maintenant. L'avantage de la licence libre pour Linux c'est que si la gouvernance de Linus ne plaît pas ou plus, on peut forker et lui retirer de fait son autorité sur le projet. Qu'il n'est pas indispensable en somme. Cette décision met en lumière ce précepte.

Je ne pense pas que l'empathie soit nécessaire. Du savoir vivre élémentaire suffirait.
L'empathie signifierait que tu peux ressentir ce que ressent la personne en face. Parfois même avec toute la bonne volonté du monde, tu ne comprends pas ce que ressent le gars en face et il est difficile de situer dans ce cas la limite de ce qui est une communication franche et correcte mais mal interprété par la personne en face à une mauvaise communication.

Linus n'était pas à la frontière, il était largement au delà de ce qui est habituellement attendu d'une conversation technique. On peut exprimer son désaccord ou des faits factuels sans s'insulter ou employer un langage fleuri. Que de temps en temps cela dérape est humain mais il est clair qu'avec Linus cela était un peu trop régulier. Et pas besoin d'empathie pour agir ainsi, cela s'appelle le savoir vivre.

L'adoption du vocabulaire maître/esclave dans le noyau n'est pas uniquement un choix de la part des développeurs.

Par exemple, le protocole SPI utilise la terminologie maître/esclave pour exprimer sa topologie et son fonctionnement. Et tous les documents des périphériques utilisant ce protocole utilisent cette terminologie également.

Donc le noyau l'utilise également, ce qui simplifie le travail car le noyau et la documentation des périphériques utilisent les mêmes termes. Cela évite les confusions parfois trop nombreuses quand on utilise des termes génériques comme host/device.

On peut après renommer, techniquement rien ne l'en empêche, mais le choix des termes s'imposent aussi par l'implémentation de ressources externes au projet. S'écarter de ces termes a un impact potentiel sur la lisibilité ou la compréhension du code.

De façon certaine, ce n'est pas Linus qui a décidé et qui a validé l'usage de tous ces termes dans le noyau. Linus (même après son courriel d'hier) travaille sur d'autres aspects.

Sauf qu'en vrai beaucoup de petites / nouvelles architectures reposent sur des solutions maisons. Car contribuer à GCC ou LLVM c'est un savoir faire qu'ils n'ont souvent pas et c'est assez complexe car le code est gros avec un gros historique.

Du coup tu te retrouves avec des petits compilateurs C (d'ailleurs rarement compatible avec la norme du C mais avec un sous ensemble). Bien avant que les gros compilateurs multi-langages en tirent parti. Et entre temps cela a permis de porter des applications en C et d'en écrire avant que le moindre code C++ puisse être portée.

Par contre, j'arrive à imaginer que le C soit remplacé au fil de l'eau par des langages spécialisés sur de nombreux domaines, et dans d'étranges éons, sur tous.

Je pense qu'il y a toujours un domaine où le C sera difficile à remplacer même pour un langage dédié : langage d'assembleur plus haut niveau (ou abstrait).

Car le C a un avantage indéniable sur le sujet qui le rend toujours aussi attractif dans le milieu et que son éventuel remplaçant devrait conserver (et donc en faire un C à peine modifié). Le C est en effet un langage très simple (mais difficile à maitriser). Peu de mots clés, abstraction très légère, norme peu contraignante laissant de grandes libertés aux compilateurs et aux OS sur ses cas limites. Tout cela permet en C d'être facile à porter sur une nouvelle architecture matérielle. Et la taille de sa norme (environ 800 pages contre le double pour le C++) est également un atout en ce sens.

Pour bénéficier de cet avantage, son remplaçant devrait être aussi concis et simple à mettre en oeuvre. Et je doute que cela permette l'émergence d'un langage suffisament intéressant pour le remplacer.

J'ajoute que Linus Torvalds a une biographie officielle et que le terme Linux en tant qu'acronyme n'est jamais mentionné alors que l'origine du nom est bien abordé.

C'est très clairement une fausse signification. Linux est juste un jeu de mot qui allie Unix et Linus dans un même terme. Il ne faut pas chercher autre chose.

Pour la petite histoire c'est le sysadmin de l'université qui a choisit le nom (sans demander son avis à Linus Torvald).

Dans sa bio il précise qu'il avait envisagé ce nom mais ne voulait pas en être l'auteur pour ne pas paraître mégalo. Il l'a adopté quand cela a été proposé par une tierce personne.

Ça dépend du médecin.

J'ai déjà demandé des arrêts maladies où il n'a clairement pas passé le temps nécessaire pour déterminer si c'était fondé ou non. En gros tu exposes le problème, il voit avec toi le nombre de jours à priori nécessaire, fait le papier et tchao.

J'en ai profité pour changer de médecin aussi. Mais bref, avec l'attitude de certains médecins, pas très difficile d'abuser un peu.

Après je ne pense pas que ce soit si répandue que cela.

Dans tous les cas ce n'est pas un problème de ressources humaines, c'est un problème de pratique frauduleuse de la médecine et d'escroquerie à la sécurité sociale. Le droit du travail ne doit pas prendre en charge ces hors-sujets. La personne à licencier ici, ce n'est pas le salarié mais le faux médecin.

Que le médecin soit puni c'est évident. Mais tu ne crois pas que le salarié qui cherche à éviter de bosser en utilisant un faux prétexte médical pour cela ne mérite aucune sanction ?

Je veux dire, le médecin est le complice de cet abus, c'est le patient (et donc l'employé) qui sont la cause de cet abus.

Pourtant l'orientation politique du syndicat est tout aussi important que la composition de ses membres. Comme un parti politique.

Sinon tu vas être membre d'un syndicat, où tu trouves les gens sympas (cool) mais dont tu n'approuves pas forcément les méthodes (blocage, séquestration, grève ou acceptation systématique) ou les idées qu'ils souhaitent défendre (trop miser sur le salarié / patronat sans chercher l'équilibre raisonnable par exemple).

Pour moi cela coince d'aller là dedans. Il faut quand même une adhésion aux idéaux et méthodes d'action du syndicat pour le rejoindre sinon l'intérêt est faible (il ne défendrait pars forcément ce que tu souhaites obtenir). Et honnêtement il est assez difficile en France de trouver un compromis idéologique dans le milieu syndical. De mon point de vue.

C'est plus facile pour une entreprise de ce comporter de façon "sale" avec l’employé que le contraire. En effet, je pense que c'est plus facile pour une entreprise de gérer une affaire aux prud’hommes que pour une personne seule (ceci dit je n'ai jamais eu a subir ça donc je me trompe peut être ).

Tout dépend de la taille de la structure.
C'est certain qu'une multinationale peut gérer la chose assez aisément par rapport à un salarié seul. Notons que malgré tout il est recommandé de faire appel à un avocat (via ton syndicat éventuellement ?) et d'éviter de se défendre soi même.

Mais pour une PME d'une dizaine d'employés, c'est une autre paire de manche. La boîte n'a pas les finances et le temps de gérer cela.

Pour cela que je suis mitigé quand on entend les discours sur les vilains patrons qui ont un pouvoir immense, etc. Dans la réalité seule une partie des entreprises peuvent vraiment agir de la sorte. Car ils ont l'argent, le recul et le temps disponible pour cela. Pour une petite structure le rapport de force n'est pas si évident et cela concerne la majorité des entreprises en France. Pour beaucoup de patrons le licenciement est un acte lourd, qu'ils n'aiment pas utiliser. Ce sont aussi des humains derrière, qui ont de l'empathie (quand tu connais un employé depuis longtemps, s'en séparer n'est pas un acte anodin en terme d'émotions), un vécu, du temps et une trésorerie pas infinie.

Faut savoir faire la part des choses, arrêter de considérer que les patrons ou les entreprises sont une entité uniforme et qu'ils ont tout pouvoir sur tout alors que l'employé nada. Et trouver l'équilibre n'est pas si évident pour couvrir l'ensemble des situations.

Ils vont jusqu'à dénier la réalité du pouvoir exhorbitant de l'employeur de détruire le gagne-pain d'un employé. Et si il/elle n'a pas su "rebondir" (en moins d'une semaine, hein !) c'est un peu sa faute aussi quoi, hein.

Personne ne dénie que le pouvoir de licencier est fort. Mais le qualifier d’exorbitant me semble exagéré. Déjà car cela signifierait que si un employé ne convient pas pour n'importe quelle raison, pas moyen de s'en séparer. Ce qui est je pense un problème.

De plus, il est toujours amusant de constater qu'on qualifie toujours le pouvoir du patron d’exorbitant sans jamais évoquer le cas opposé. L'employé a aussi du pouvoir de nuisance. Il peut se barrer et mettre l'entreprise dans l'embarras.

Je trouve que sur ce point l'équilibre est plutôt correct. L'employé a le droit de partir, sans se justifier moyennant un préavis raisonnable. L'employeur peut licencier mais uniquement dans certains cas bien définis et avec indemnité sauf circonstances exceptionnelles. Ce qui limite grandement le côté exorbitant du dit pouvoir.

Car c'est connu qu'un patron qui souhaiterait se débarrasser d'un employé mais ne peut pas le faire c'est génial comme ambiance aussi.

Une LRAR et 10 minutes d’entretien, c'est ce que tu estime être le blindage épais d'un salarié ?

Car c'est bien connu qu'un employeur peut licencier n'importe qui avec n'importe quel motif… Si le contenu de la LRAR et de l'entretien ne sont pas fondés, tu contestes la décision en justice (comme pour n'importe quel contentieux). Le droit est quand même en faveur du salarié, c'est loin d'être aisé pour licencier quelqu'un même quand c'est fondé.

L'employé lui peut partir sans justification par contre quand il veut. Avec seulement le préavis de 3 mois à respecter.

Mouais, quand tu sors ce genre de phrases cela fait baisser quand même grandement ta crédibilité.

Comme Zenitram ou dit plus haut, ce genre de propos (en plus de leurs actions illégitimes parfois) provenant des syndicats me rebutent grandement à les rejoindre. Comment leur faire confiance s'ils agissent ou mentent ainsi ?

Note : je ne suis pas de l'organisation.

D'autant plus que la plupart des infos sont en Anglais, donc pas accessible clairement à tous.

Comme les conférences sont en anglais uniquement, n'afficher les informations qu'en anglais semble normal.

C'est une suite de présentations autour des outils Libres et de leur ergonomie si j'ai bien compris??? Cela doit surement s'inscrire dans "Linux Presentation Day"

Pas du tout.

C'est vraiment une conférence de développeurs / contributeurs à propos du noyau Linux et des systèmes embarqués employant du Logiciel Libre.

Les conférences sont plutôt pour les professionnelles, le grand public, les décideurs de projets, …?

Conférences par et pour des développeurs à priori, les sujets abordés sont trop techniques pour le grand public ou le décideur.

Des stands seront présents ou seulement des conférences?

Que des conférences à priori.

Embarqué ne signifie pas que tu as une puissance CPU minimale (ou même générale comme une RAM faiblarde). Cela signifie que tu peux rencontrer des contraintes très particuliers :

• Interface homme / machine limité voire absente ;
• Alimentation électrique ou accès à Internet très intermittent ;
• Contraintes temps réelles fortes ;
• Grande variétés de capteurs ou d'entrées / sorties ;
• Lien logiciel / matériel très poussé pour l'application.

Typiquement il me paraîtrait absurde de considérer que le la machine faisant la conduite autonome d'une voiture ne soit pas considéré comme un système embarqué alors que pourtant le matériel utilisé est plus puissant que bon nombre de PCs en circulation. Mais les contraintes évoquées plus haut rend son développement assez différent que ce qui se fait pour un logiciel traditionnel sur PC.

Bref, les systèmes embarqués avec une faible puissance matérielle ne sont qu'une partie du domaine en question.

C'est pas tellement lié en fait. Le device tree ne liste que les devices qui ne sont pas découvrables, donc sur des bus mémoires, i2c, spi, etc. Pour USB et PCIe, le seul truc qui est listé est le contrôleur. Tout comme ACPI.

Bien sûr, mais les cartes ARM du moins au début recouraient bien moins au PCIe et USB, préférant les bus non découvrables à la place. Alors que la plupart des composants dans le PC finissent par passer par ces bus à un moment ou un autre.

Cela change beaucoup sur la manière de prendre en charge le matériel.

C'est vrai, mais on pourrait utiliser exactement le même argument pour le BIOS / UEFI et les tables ACPI passées au kernel: il faut bien que quelqu'un les écrive pour les parties non-découvrables. Du coup, je vois pas trop où c'est un point fort.

Dans un cas c'est fourni par le constructeur lui même, dans l'autre c'est souvent au développeur de l'ajouter de son côté que ce soit au sein du noyau lui mee ou du chargeur de démarrage.

Si, en fait. Tout ce qui est listé dans le SoC et a un status = "okay" peut être utilisé. Si c'est effectivement le cas reste à charge de l'OS, mais tout est censé être utilisable.

Je sais ce qu'est un device tree, j'en écris régulièrement.
Justement je mentionnais qu'en l'absence de device tree, c'est à dire si tu essayes de démarrer ton noyau avec juste ce qui est fourni de base par le constructeur de la carte, bah tu ne booteras pas ou en mode très dégradé. Car le constructeur ne te fourni pas en dur le device tree qui va bien, tu dois l'ajouter toi même quelque part.

Alors que quand je monte mon PC, je n'ai rien à faire. Je démarre mon noyau sans besoin d'ajouter une description du matériel avec mon système. Car cette découverte est faite et fourni automatiquement à mon système.

La "découverte" du DT en lui même est effectivement le seule avantage du BIOS / UEFI sur le DT.

Cette différence paraît faible mais elle est en fait fondamentale ! C'est cette différence qui est la source de tous les mots et qui rend le device tree obligatoire. Et qui complique la conception d'une image ARM universelle.

J'aurais tendance à dire que non, mais dans ce cas là, le bootloader sur ARM ne fait pas partie de l'OS non plus. Il commence au kernel, qui lui n'a pas à se soucier de la partie decouverte, on lui passe le DT en argument.

L'OS au sens strict du terme se réfère en effet au système noyau + espace utilisateur quelque soit l'architecture. Mais il me semble pertinent de considérer le chargeur de démarrage dedans. Après tout Fedora, Windows ou macOS ont leur propre chargeur de démarrage qui est géré comme n'importe quel logiciel. Et d'autant plus que nous avons dans un cas (pour PC) un chargeur de démarrage universel (il fonctionne pour à peu ès n'importe quel PC sans soucis) et de l'autre nous avons un chargeur de démarrage (que ce soit U-boot ou autre) qui doit être particulier pour l'initialisation de base et sélectionner le bon device tree à envoyer au noyau.

Tu te méprends sur ce qu'est la découverte de périphérique.

Le BIOS / UEFI permet d'initialiser le système sans devoir le décrire, le tout automatiquement. Tout simplement en utilisant des bus matériels permettant la découverte comme l'USB, PCIe, etc. et grâce au fait que certaines choses dans l'architecture PC sont standardisés.

C'est ce qui rend possible le fait d'avoir un OS unique qui peut booter (sur PC) sur à peu près n'importe quelle configuration de carte graphique, RAM, cartes réseaux, etc.

Le device tree est quant à lui statique. C'est un humain qui va décrire dans le noyau les adresses, les bus et les pilotes à employer pour chaque carte ARM. Si tu fais une carte ARM un peu différente, tu devras écrire un nouveau device tree (éventuellement par surcharge) pour exprimer cette différence. Le noyau comme le SoC n'ont aucune idée sinon de ce qui doit être initialisé ou pas.

Le device tree permet une plus grande souplesse :

• Grâce à la surcharge, c'est facile de définir un SoC et ensuite les cartes mères qui se basent dessus sans trop se répéter ;
• Possibilité de le mettre à jour indépendamment du noyau ;
• Possibilité de partager un device tree avec différents OS ou chargeurs de démarrage (cas de U-boot et Linux) ;
• Si les cartes mères permettent (via des GPIO par exemple) de dire quelle carte mère tu utilises, tu peux facilement charger le device tree correspondant à la bonne carte. C'est cela qui autorise une image unique pour plusieurs cartes, le chargeur de démarrage peut sélectionner la bonne description du matériel en fonction d'un élément discriminant.

Mais ce dernier point n'a pas la force, robustesse et flexibilité d'un BIOS ou UEFI. Si la carte mère ne fournit rient pour choisir le bon device tree, tu es bien emmerdé.

L'Arcep aurait peut être dû forcer à mettre fin à l'itinérance Orange pour Free, ça aurait peut être été mieux …

La fin de cette itinérance est déjà en cours, et va durer par phases jusqu'en 2020.

Tu as une source pour dire ça ? Il me semblait avoir lu des études qui montraient le contraire : la majorité des gens ont installé 0 application sur les 12 derniers mois.

Sur le bureau je veux bien le croire, en général tu en as quelques unes seulement.
Sur mobile j'ai du mal à le croire, tous ceux que je connaissent (qui ne sont pas des technophiles) avec un smartphones installent / désinstallent régulièrement des applications. Dont des jeux.

Ce sont de très mauvais exemples, ces applications sont pré-installées sur les téléphones, il n'y a pas besoin de les installer pour les utiliser.

Peu importe, ils installent des applications pour tout. Wikipédia, Facebook, le magasin préféré (Amazon, Ikea, Auchan, Carrefour, etc.), Netflix, le site d'actu (Le Monde, Le Figaro, 20 minutes, NextINpact, etc.), l'application de la banque, du réseau de transport du coin voire national comme SNCF et j'en passe.

Pourtant ce que je te liste existe en version Web et souvent avec une interface mobile semblable à celle de l'application.

Le navigateur est bien moins utilisé sur mobile que sur les ordinateurs de bureau à cause de cela.

peu de gens se motivent à installer ton application native alors que cliquer sur un lien même madame michu sait faire

Ça va, les gens savent installer une application native quand ils veulent.
Je pourrais même te dire qu'avec les téléphones portables ils préfèrent installer une application native que d'utiliser le site web du service correspondant (tu crois que les gens consultent gmail ou Youtube depuis leur navigateur sur téléphone ?).

ton projet perso, tu le code et le maintiens sur Windows, MacOS, Linux, Android et iOS ou tu fais une version web

Car tu crois qu'un site web universellement compatible cela est aussi facile à faire que de pondre une application multiplateforme ?

Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.

L'API du web (ou l'écosystème de ses frameworks) est aussi très changeant, c'est un monde qui évolue vite contrairement à celui de l'OS. Donc niveau maintenance ce n'est pas une mince affaire que de gérer une application Web.