Mais au fur et à mesure le noyau vanilla diverge inexorablement
C'est pour ça que seuls les patchs critiques sont rétroportés.
Vraiment, c'est exactement ce qu'on demande à RedHat, et pas pour rien que c'est lui qui est utilisé en professionnel dans les grosses boites (je mets de côté le professionnel qui aime bidouiller et/ou a des trucs court terme) : ne rien casser sans qu'on le décide nous-même (en passant à la version suivante).
mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.
Ben si, car on n'a pas du tout envie de fixer un bug qui apparait à cause d'une update de noyau ou autre.
A noter que "10 ans", c'est pour un logiciel X à nous dans une version Y qu'on ne touche pas et qu'on ne veut pas une nouvelle fonctionnalité (on veut que le logiciel marche toujours tout en étant protégé niveau OS, sans avoir peur lors d'une MAJ de l'OS), ça ne veut pas dire qu'on n'a pas un nouveau noyau pour les nouveaux projets. A noter qu'avec RedHat, c'est plutôt 5 ans, les autres années servent aux fix critiques et pas plus (plus de MAJ des logiciels).
Bref, ce qui est critiqué est exactement ce pour quoi elle est utilisée : nous laisser libre de choisir quand on casse la compatibilité en upgradant de version, sinon nous assurer la maintenance sur la vielle version. Et ça marche tellement bien qu'en pratique on est passé de cycle de nouvelles versions tous les 2 ans (RHEL jusqu'à la 5) à plutôt 3-4 ans (RHEL 7 a déjà 3 ans et toujours pas de 8 en ligne de mire, faut croire qu'il n'y a pas encore besoin de casser la compatibilité pour des fonctionnalités hypes, ils ont même réussi à y mettre HTTP2 sans casser les ABI)
Edit : grillé par WhiteCat, ça m'apprendra à ne pas actualiser la page au réveil :), on est bien synchro sur la réaction.
[^] # Re: Red Hat != World
Posté par Zenitram (site web personnel) . En réponse au journal Btrfs ne serait plus le futur. Évalué à 6. Dernière modification le 03 août 2017 à 08:22.
C'est pour ça que seuls les patchs critiques sont rétroportés.
Vraiment, c'est exactement ce qu'on demande à RedHat, et pas pour rien que c'est lui qui est utilisé en professionnel dans les grosses boites (je mets de côté le professionnel qui aime bidouiller et/ou a des trucs court terme) : ne rien casser sans qu'on le décide nous-même (en passant à la version suivante).
Ben si, car on n'a pas du tout envie de fixer un bug qui apparait à cause d'une update de noyau ou autre.
A noter que "10 ans", c'est pour un logiciel X à nous dans une version Y qu'on ne touche pas et qu'on ne veut pas une nouvelle fonctionnalité (on veut que le logiciel marche toujours tout en étant protégé niveau OS, sans avoir peur lors d'une MAJ de l'OS), ça ne veut pas dire qu'on n'a pas un nouveau noyau pour les nouveaux projets. A noter qu'avec RedHat, c'est plutôt 5 ans, les autres années servent aux fix critiques et pas plus (plus de MAJ des logiciels).
Bref, ce qui est critiqué est exactement ce pour quoi elle est utilisée : nous laisser libre de choisir quand on casse la compatibilité en upgradant de version, sinon nous assurer la maintenance sur la vielle version. Et ça marche tellement bien qu'en pratique on est passé de cycle de nouvelles versions tous les 2 ans (RHEL jusqu'à la 5) à plutôt 3-4 ans (RHEL 7 a déjà 3 ans et toujours pas de 8 en ligne de mire, faut croire qu'il n'y a pas encore besoin de casser la compatibilité pour des fonctionnalités hypes, ils ont même réussi à y mettre HTTP2 sans casser les ABI)
Edit : grillé par WhiteCat, ça m'apprendra à ne pas actualiser la page au réveil :), on est bien synchro sur la réaction.