Non, le souci n'est pas la licence (en tout cas, ça n'était pas la licence au début), le souci, c'est soit y a des limitations (genre pas le droit de toucher à la taille du code binaire sinon tu décales tout les pointeurs, pas le droit de toucher aux structures, etc, etc), soit tu es obligé de faire des grosses réécritures de la mémoire, et ton kernel est dans un sale état. En fait, quand tu vois que les devs kernels voulait retirer la possibilité de retirer les modules car c'était trop compliqué (à l'époque du 2.6, je crois), c'est bien qu'il y a quelque choses.
Donc pour mettre à jour ton kernel, tu dois "juste" changer du code, mais pour change rle code, faut le faire de tel façon que le kernel soit le même du point de vue du layout. Même si pour les failles les plus importantes, ça semble être bon d'aprés wikipedia, il semble que pour une petite partie des failles ( 12% ), il faut faire intervenir un développeur pour bidouiller la mémoire du kernel. Et bien sur, les chiffres ne parlent que de 64 failles sur 3 ans, quid des autres updates que tu voudrait aussi appliquer sans rebooter ?
Et ça, ça part du principe que tu part avec un kernel connu dont tu as le code, pas un kernel bidouillé ou avec des modules customs ou ce genre de choses. Et bien sur, chaque modif implique un patch spécifique, et chaque patch spécifique implique des tests poussés (car bon, c'est une chose de tester un soft dans un état connu contre une faille, c'est autre chose de tester un soft dans un état inconnu contre une faille et tout les emmerdes possibles, surtout face à des soucis de processeurs multiples, etc. Et tu veux pas non plus que ton update bloque le kernel trop longtemps pendant que tu fait la mise à jour, vu que le kernel est freezé le temps de magouiller tout)
Et je sais pas si tu peux enchainer les updates ksplices advitam eternam.
Donc non, en pratique, la plupart des distributions n'ont pas les ressources (en plus maintenant de plus avoir le code à jour). En pratique, Oracle n'a visiblement même pas les ressources suffisante pour faire ça sur les 2 kernels de sa distribution malgré le fait que leur distribution ne soit qu'un rebuild de l'original (ou alors, ils mentent quand ils disent qu'ils sont compatibles de façon binaire, mais Oracle peut pas jouer sur les 2 tableaux à ce niveau la). IE oracle ne propose ksplice que pour son kernel maison, celui qu'ils rebasent sur le 3.0 (vu qu'ils ont pas envie de faire des rebases peut êtrepour des questions de moyens) avec btrfs en production et supporté, voir http://www.h-online.com/open/news/item/Btrfs-ready-for-production-in-new-Oracle-Linux-kernel-1471706.html .
Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 4.
Non, le souci n'est pas la licence (en tout cas, ça n'était pas la licence au début), le souci, c'est soit y a des limitations (genre pas le droit de toucher à la taille du code binaire sinon tu décales tout les pointeurs, pas le droit de toucher aux structures, etc, etc), soit tu es obligé de faire des grosses réécritures de la mémoire, et ton kernel est dans un sale état. En fait, quand tu vois que les devs kernels voulait retirer la possibilité de retirer les modules car c'était trop compliqué (à l'époque du 2.6, je crois), c'est bien qu'il y a quelque choses.
Donc pour mettre à jour ton kernel, tu dois "juste" changer du code, mais pour change rle code, faut le faire de tel façon que le kernel soit le même du point de vue du layout. Même si pour les failles les plus importantes, ça semble être bon d'aprés wikipedia, il semble que pour une petite partie des failles ( 12% ), il faut faire intervenir un développeur pour bidouiller la mémoire du kernel. Et bien sur, les chiffres ne parlent que de 64 failles sur 3 ans, quid des autres updates que tu voudrait aussi appliquer sans rebooter ?
Et ça, ça part du principe que tu part avec un kernel connu dont tu as le code, pas un kernel bidouillé ou avec des modules customs ou ce genre de choses. Et bien sur, chaque modif implique un patch spécifique, et chaque patch spécifique implique des tests poussés (car bon, c'est une chose de tester un soft dans un état connu contre une faille, c'est autre chose de tester un soft dans un état inconnu contre une faille et tout les emmerdes possibles, surtout face à des soucis de processeurs multiples, etc. Et tu veux pas non plus que ton update bloque le kernel trop longtemps pendant que tu fait la mise à jour, vu que le kernel est freezé le temps de magouiller tout)
Et je sais pas si tu peux enchainer les updates ksplices advitam eternam.
Donc non, en pratique, la plupart des distributions n'ont pas les ressources (en plus maintenant de plus avoir le code à jour). En pratique, Oracle n'a visiblement même pas les ressources suffisante pour faire ça sur les 2 kernels de sa distribution malgré le fait que leur distribution ne soit qu'un rebuild de l'original (ou alors, ils mentent quand ils disent qu'ils sont compatibles de façon binaire, mais Oracle peut pas jouer sur les 2 tableaux à ce niveau la). IE oracle ne propose ksplice que pour son kernel maison, celui qu'ils rebasent sur le 3.0 (vu qu'ils ont pas envie de faire des rebases peut êtrepour des questions de moyens) avec btrfs en production et supporté, voir http://www.h-online.com/open/news/item/Btrfs-ready-for-production-in-new-Oracle-Linux-kernel-1471706.html .
Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.