>>> Désormais, ils sont capable de faire vivre leur version seul (et ils y ont finalement plus d'intérêt que nous).
Personne ne fait ça dans l'embarqué !
Certes les gens qui font de l'embarqué ont une politique noyau assez spéciale puisqu'habituellement ils choisissent en noyau particulier (par exemple le 2.6.10) et ils l'adaptent à leur besoins particuliers pour le déployer dans leurs bidules.
Ils doivent assurer seuls le support de ce noyau modifié (ou plus souvent ils n'assurent rien du tout et se foutent complètement des trous de sécu) dans tous les bidules d'une génération donnée.
Ensuite, pour la génération suivante, ils choisissent un autre noyau (par exemple le 2.6.32) et ils recommencent le cycle.
Cette méthode est sous-optimale car toutes les modifs apportées sur le 2.6.10 doivent êtres reportées vers le 2.6.32 à grand frais (car le travail d'adaptation n'est pas trivial après tout ce temps). Ils auraient intérêt à travailler avec l'upstream pour intégrer leurs modifs dans la branche principale.
L'important ici c'est qu'aucune firme ne garde un noyau modifié ad vitam aeternam. Ils se resynchronisent tous à un moment ou a un autre tout simplement parce qu'ils n'ont pas les reins assez solides pour porter seuls un OS à bout de bras.
Google est gros mais est-ce qu'il est suffisamment gros pour garder leur fork définitivement séparé et pour continuer à le développer au même rythme effréné que la branche de Linus ?
Plus important: quel serait l'intérêt pour eux de se priver de la force de travail gratuite de tous les devs noyau du monde pour faire leur truc dans leur coin ?
[^] # Re: Appelons un fork, un fork
Posté par patrick_g (site web personnel) . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à 10.
Personne ne fait ça dans l'embarqué !
Certes les gens qui font de l'embarqué ont une politique noyau assez spéciale puisqu'habituellement ils choisissent en noyau particulier (par exemple le 2.6.10) et ils l'adaptent à leur besoins particuliers pour le déployer dans leurs bidules.
Ils doivent assurer seuls le support de ce noyau modifié (ou plus souvent ils n'assurent rien du tout et se foutent complètement des trous de sécu) dans tous les bidules d'une génération donnée.
Ensuite, pour la génération suivante, ils choisissent un autre noyau (par exemple le 2.6.32) et ils recommencent le cycle.
Cette méthode est sous-optimale car toutes les modifs apportées sur le 2.6.10 doivent êtres reportées vers le 2.6.32 à grand frais (car le travail d'adaptation n'est pas trivial après tout ce temps). Ils auraient intérêt à travailler avec l'upstream pour intégrer leurs modifs dans la branche principale.
L'important ici c'est qu'aucune firme ne garde un noyau modifié ad vitam aeternam. Ils se resynchronisent tous à un moment ou a un autre tout simplement parce qu'ils n'ont pas les reins assez solides pour porter seuls un OS à bout de bras.
Google est gros mais est-ce qu'il est suffisamment gros pour garder leur fork définitivement séparé et pour continuer à le développer au même rythme effréné que la branche de Linus ?
Plus important: quel serait l'intérêt pour eux de se priver de la force de travail gratuite de tous les devs noyau du monde pour faire leur truc dans leur coin ?