Il s’agit de corriger les bugs du noyau en évitant d’en introduire d’autres avec un nouveau noyau.
Mouais...mais au fil des années de support d'une release cette stratégie devient amha de plus en plus casse-gueule. Rester sur le même noyau et rétroporter les patchs c'est assez facile les 2 ou 3 premières années (si on a une équipe de devs solide comme Red Hat). Mais au fur et à mesure le noyau vanilla diverge inexorablement (12 000 patchs tous les 3 mois quand même !!!) et le rétroportage de patchs devient de la jonglerie en monocycle sur un câble tendu au dessus des chutes du Niagara.
Je ne dis pas que les serveurs de Prod devraient tous être sous Arch...mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.
[^] # Re: Red Hat != World
Posté par patrick_g (site web personnel) . En réponse au journal Btrfs ne serait plus le futur. Évalué à 10. Dernière modification le 02 août 2017 à 22:47.
Mouais...mais au fil des années de support d'une release cette stratégie devient amha de plus en plus casse-gueule. Rester sur le même noyau et rétroporter les patchs c'est assez facile les 2 ou 3 premières années (si on a une équipe de devs solide comme Red Hat). Mais au fur et à mesure le noyau vanilla diverge inexorablement (12 000 patchs tous les 3 mois quand même !!!) et le rétroportage de patchs devient de la jonglerie en monocycle sur un câble tendu au dessus des chutes du Niagara.
Je ne dis pas que les serveurs de Prod devraient tous être sous Arch...mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.