Qu'un certain nombre de technos soient issues de Redhat est normal: étant une des entreprises qui vendent du support associé à Linux, et la principale d'entre elles, ils ont des sous pour employer des gens à travailler sur des technos, donc c'est plus facile d'avancer que pour des gens qui travaillent exclusivement sur leur temps libre, comme c'est trop fréquent dans le monde du logiciel ouvert.
* EGCS était une évolution technique indispensable sur la base de code GCC très ancienne. Sans elle, GCC aurait été plus mal en point face à l'arrivée de Clang, infrastructure bien plus moderne et qui a précipité l'ajout de la capacité de gérer des plugins (avec une API au moins aussi instable que celle de LLVM/Clang) dans GCC, ce que RMS a bloqué pendant un peu trop longtemps de peur des plugins propriétaires. J'admets ne pas connaître l'histoire d'EGCS dans tous ses détails, mais j'ai du mal à me convaincre qu'il y ait eu une volonté ouverte de vendor lock-in sur ce sujet... et puis le résultat à long terme est positif pour tous. Le fork EGCS est devenu le nouveau GCC, l'ancien a disparu.
* la diffusion des sources du kernel sans historique, là, en revanche, difficile de ne pas voir du vendor lock-in. Même si c'était pour (tenter d') emmerder en particulier Oracle, autre spécialiste de vendor lock-in, bien pire que Redhat, et même si utiliser le kernel de Redhat, à défaut d'être une garantie de sécurité (
), est surtout une garantie d'obsolescence. PaX/grsecurity fournissait à tous, et fournit toujours à ses clients, l'historique des modifs.
* PA a des avantages clairs par rapport à ALSA dans certains use cases... quand il veut bien fonctionner, j'en ai encore fait les frais récemment. Il s'est répandu des années trop tôt dans les distros, mais d'un autre côté, s'il ne l'avait pas été, les bugs n'auraient pas été trouvés et - parfois - corrigés. Mais du vendor lock-in sur PA ?
* PolicyKit et PackageKit avaient une partie standardisation d'opérations entre distros, ce qui est clairement une bonne chose. J'ai utilisé PackageKit programmatiquement au boulot. Ils se sont répandus à pas mal de distros.
* CK visait à améliorer certains use cases lui aussi, avec également un effet de standardisation d'infrastructure. Là aussi, il s'est répandu à pas mal de distros.
* systemd, en partie le successeur de PolicyKit et CK, standardise
beaucoup de choses entre distros, et a des avantages fonctionnels clairs par rapport à ce qu'il vise en particulier à remplacer: le vieux sysvinit, ses spécificités et sa duplication de travail dans chaque distro. Certaines capacités built-in de systemd nécessitent des contournements bizarres avec sysvinit. Ce n'est pas du tout pour rien que systemd s'est ainsi répandu sur la grande majorité des distros Linux, y compris Debian et dérivées (sauf les idiots de Devuan, qui ont gaspillé une énergie considérable à forker, et sont maintenant obligés d'aider Debian pour à la fois se faciliter la vie et aider les utilisateurs, cf. un article récent de LWN...). Malgré ses failles dangereuses répétées, techniquement, systemd est une chose positive pour l'écosystème Linux, en le rapprochant du modèle Windows et MacOS X: une façon standard (de fait) de réaliser la gestion des services.
Bref... à part la diffusion des sources du kernel sans historique, je ne vois pas trop de vendor lock-in dans ta liste, Godzil
Et même à supposer qu'il y ait réellement eu volonté de le faire sur tous ces points... le moins qu'on puisse dire, c'est que ça a totalement raté, puisque les autres distros ont suivi, et pas seulement parce que "oh ben Redhat le fait, alors ça va se répandre et il faut qu'on fasse pareil". Il y avait aussi des raisons techniques positives.
)
