Un peu comme les fonctions d'accélération matérielles, les extensions aux jeux d'instruction x86/AMD64, les gestionnaires d'énergie, etc.
Si le matériel reposait sur un tronc commun, pourquoi est-ce que les contributions au noyau seraient tellement chargées côté matériel?
Le matériel est le pire exemple parce que justement tu veux exploiter tout ce qui le différencie des produits équivalents.
Sinon, est-ce que RMS avait autant bloqué quand udev est passé composante de système, excluant les BSD et les distros Linux qui n'utilisaient un autre init?
Je ne m'en souviens pas!
Le but n'est pas d'éliminer le favoritisme, mais bien d'empêcher les OS non-libre de montrer un quelconque avantage.
[^] # Re: Pas choquant
Posté par Maclag . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 5.
Un peu comme les fonctions d'accélération matérielles, les extensions aux jeux d'instruction x86/AMD64, les gestionnaires d'énergie, etc.
Si le matériel reposait sur un tronc commun, pourquoi est-ce que les contributions au noyau seraient tellement chargées côté matériel?
Le matériel est le pire exemple parce que justement tu veux exploiter tout ce qui le différencie des produits équivalents.
Sinon, est-ce que RMS avait autant bloqué quand udev est passé composante de système, excluant les BSD et les distros Linux qui n'utilisaient un autre init?
Je ne m'en souviens pas!
Le but n'est pas d'éliminer le favoritisme, mais bien d'empêcher les OS non-libre de montrer un quelconque avantage.