• Comment sont choisies les versions du kernel de Leap ?


    La prochaine version d'openSUSE Leap, numérotée 15, pointe son nez et on sait d'ores et déjà qu'elle bénéficiera du noyau Linux en version 4.12.
    Cela pourrait en étonner plus d'un et on serait en droit de se demander pourquoi un tel choix alors que la version courante du noyau est 4.15 ou si, au court de sa vie, le noyau de Leap 15 pourra être mis à jour afin de ne pas rester avec un noyau jugé trop ancien.

    Cette question a été posée sur la liste de diffusion opensuse-factory et un des participants très informé à bien voulu prendre le temps de donner une réponse claire et complète qu'il paraît important de retransmettre. Le texte qui suit en est donc une traduction et une adaptation au format « article » libres.

    Pourquoi Leap 15 aura le noyau 4.12 au lieu de la version 4.14 (ou ultérieure) ? (par Peter Linnell)

    Il faut tout d'abord rappeler que la distribution openSUSE Leap bénéficie d'une base de code partagée avec la version professionnelle SLE (Suse Linux Enterprise), base dont le noyau fait partie. À cet égard, il faut beaucoup de temps pour que le noyau obtienne les certifications requises pour fonctionner sur les matériels des clients de Suse et avec les logiciels d'autres éditeurs professionnels. Toutes les étapes permettant une telle certification pour le noyau 4.12 auraient dû être retardées ou bien recommencées pour la version 4.14 si celle-ci avait été choisie en finalité.
    Le travail à fournir afin d'obtenir une telle certification est colossal et coûteux, il nécessite la mobilisation de nombreux ingénieurs et requiert d'avoir à disposition les différents matériels pour lesquels la distribution doit être certifiée.

    L'auteur de la réponse initiale rapporte l'exemple du processus de certification d'un serveur type « lame » et d'une armoire de stockage. Il a fallu pour cela mobiliser 3 ingénieurs durant plusieurs jours, assurer le déplacement au travers des États-Unis de 2 experts SUSE (dont l'auteur) pour un total estimé à plus de 10 000 $. Le tout pour certifier un seul type de matériel !

    Les membres de la communauté openSUSE ne sont sûrement pas tous conscients du genre de matériel pour lequel est certifiée la SLE (SUSE Linux Enterprise) (ndt: et donc le noyau de la Leap) mais il s'en trouve parmi eux de très exotiques et très chers.
    On peut citer deux exemples :

    1. Les serveurs SAP HANA qui tournent quasi exclusivement sous SLES (SUSE Linux Enterprise Server). Une image système de 32 To peut absorber jusqu'à 5 ou 6 fois ce volume de données compressées et les contenir en mémoire. Nous parlons là de 150 à 180 To de données disponibles en RAM afin de réaliser des analyses en temps réel !
    Pratiquer des tests sur ce genre de monstres nécessite d'une part des semaines d’ingénierie et d'autre part que le fabriquant mette à disposition une machine de plusieurs millions de dollars.
    https://www.hpe.com/us/en/solutions/sap-hana.html

    2. Les systèmes SGI, une entreprise rachetée par HPE. Il s'agît de systèmes NUMA (« non uniform memory architecture » ou architecture mémoire non uniforme) pouvant théoriquement gérer jusqu'à 64 To de RAM avec un seul noyau Linux.
    https://www.hpcwire.com/2016/05/11/t...life-sciences/

    En ce qui concerne les logiciels, certaines piles logicielles éditées par les fabricants peuvent prendre des semaines pour être certifiées. Les fabricants eux-mêmes peuvent réaliser des tests de résistance ou des contrôles qualité afin de s'assurer que tout est conforme. Après tout, les éditeurs de logiciels fournissent un certain niveau de garantie à leurs clients en ce qui concerne la compatibilité et la stabilité qu'ils se doivent de maintenir. Un problème dans leurs logiciels pourrait entraîner un manque à gagner considérable pour leurs clients.

    Donc, du point de vue de l'entreprise, la décision que telle version du noyau sera utilisée met en branle une machinerie complexe, requérant une grande coordination, en interne mais aussi avec les clients et partenaires. Ce genre de décision n'est donc pas pris à la légère.

    En tant que membres de la communauté openSUSE, nous avons donc de la chance de bénéficier d'une telle ingénierie. Ce sont littéralement des millions de dollars d'investissement qui, non seulement sont mis à disposition dans Leap, mais qui démontre bien la volonté affirmée de SUSE de voir openSUSE réussir et de l'intérêt que l'entreprise porte à notre communauté.

    Pour conclure, il faut rappeler, si besoin, que le noyau, bien qu'en version 4.12 bénéficiera des rétro-portages (« backports ») tout au long de sa durée de vie en vue d'apporter des correctifs et d'améliorer la prise en charge matérielle et logicielle.
    Commentaires 7 Commentaires
    1. Avatar de passionlinux
      passionlinux -
      Excellent Sogal,

      Merci car je dois bien admettre que je me posais la question du comment et pourquoi, mais il me reste une question en tête, pourquoi ne pas donner cette effort sur un kernel LTS? Oui le 4.12 est déjà obsolète et n'est plus parmi ceux qui sont encore de nos jour maintenues en amonts, alors pourquoi ne pas mettre tant d'efforts, d'argent et autre dans un kernel LTS?
    1. Avatar de sogal
      sogal -
      Il existe 2 versions LTS du kernel supérieures à l'actuel 4.4 de Leap : https://www.kernel.org/category/releases.html

      - la 4.9 : très certainement trop ancien pour la Leap 15 au moment des travaux pour cette dernière ;
      - la 4.14 : pour cette version, c'est exactement ce qu'explique la réponse retranscrite dans l'article : cette version a dû sortir (ou être déclarée comme LTS) après que les travaux de certification (et donc le choix de partir sur le kernel 4.12) aient été commencés. Attendre la sortie de la 4.14 puis attendre encore un peu quelques correctifs auraient trop retardé la sortie de la SLE et de la Leap.
    1. Avatar de bertrandbo
      bertrandbo -
      Oui le 4.12 est déjà obsolète et n'est plus parmi ceux qui sont encore de nos jour maintenues en amonts
      Obsolète me semble un peu fort. Ce n'est pas parce que ce n'est plus maintenu en amont que, d'un seul coup, cela ne marche plus. Si des gens chez SUSE assure le retroportage de sécurité (et ils ont des développeurs kernel salariés pour le faire, comme Red Hat), je ne vois pas le problème. D'autant que, encore comme Red Hat, les retroportages contiennent aussi des ajouts de pilotes sur des "Service Pack".
      Et puis, les clients sont conservateurs de toutes facons. Il y a encore des CentOS 6 qui tournent en prod. Alors que CentOS 7 est sorti il y a quoi ? 3 ans ?

      [...] pourquoi ne pas mettre tant d'efforts, d'argent et autre dans un kernel LTS?
      Mais ils le font un peu quand même :-) Le kernel 4.4 est LTS, maintenu jusqu'à début 2022. C'est le kernel de SLES 12 SP2 dont la fin de vie est en 2021... En comptant des retards éventuels sur la sortie d'un SP4, ca tombe pas trop mal tout ca. Je ne sais pas comment ils travaillent avec le projet amont, mais je trouve cette coincidence rigolote.

      Pour le 4.14, c'est juste mal tombé je pense. Il est sorti fin novembre. Hier quoi. Et de toutes facons, les SUSE (toujours comme les Red Hat) sont supportées 10 ans (voir plus en support étendu si j'ai bien compris), là où les noyaux LTS 4.9 et 4.14 sont supportés un gros 2 ans.

      Bref, t'auras à faire de la maintenance un jour ou l'autre car tu ne veux pas changer de kernel comme ca, juste parce qu'il y a une nouvelle version amont. Ajouter du code, c'est ouvrir une porte aux regressions. Et les distributions GNU/Linux d'entreprise ne peuvent pas se le permettre car on les achètent pour que "ca ne casse jamais". C'est pour ca qu'elle sont assez conservatrices sur les mises à jour et qu'elles ne changent pas de noyau si facilement (SUSE le fait lors des Services Pack, mais tu n'es obligé de l'appliquer de suite, le précédent Service Pack reste maintenu un moment). Et c'est aussi pour ca que les distributions d'entreprise ont souvent des dépôts moins remplis que des distributions communautaire : tout ce que tu as dans tes dépôts, tu le supportes 10 ans et chaque mise à jour ne doit rien casser. C'est compliqué.

      Après, je ne serai pas étonné que les ingénieurs de SUSE regardent ce qui se passe dans la LTS 4.14 et appliquent les patches en 4.12 (il n'y a peut être pas tant de différence ?).

      Ca ne m'étonne pas que les certifications soient un problème dans le flux d'intégration d'un kernel. Lorsque j'ai un problème avec un produit d'éditeur, le 1er truc qu'on me demande c'est sur quoi c'est installé et est-ce que cela a été fait suivant la procédure officielle. Si ce n'est pas le cas, direct le support va passer de "on va te régler le problème" à "c'est peut être ta faute, on va essayer de te régler le problème". Dit autrement, un client de SAP s'en fout de la distribution Linux sur laquelle son bazar est installé. Il veut juste que ca marche et que ca reste sécurisé. Si une mise à jour fait tomber son SAP parce qu'un driver a regressé (par exemple), le client va dégringoler sur SAP qui, si ca vient du Linux, dégringolera sur SUSE. Quelqu'un paie pour chaque problème. Reste à savoir qui est responsable. Et t'as pas envie qu'un changement cavalier de version du kernel (qui apporte plein de trucs hein, mais probablement pas tous utiles sur tes plateformes SAP) te foute la merde.

      Bref, la distribution d'entreprise ne réfléchit pas tout à fait pareil que la distribution communautaire.

      Un peu hors sujet, Cet article de Greg Kroah-Hartman (mainteneur des noyaux LTS) explique comment fonctionne le modèle de développement du noyau Linux. J'ai trouvé ca très intéressant même si un peu long à lire (et en anglais). Permet aussi de comprendre comment les LTS étaient et sont choisis.

      Edit: je rajoute le lien vers le mail original que Sogal a traduit.
    1. Avatar de sogal
      sogal -
      @ bertrandbo : merci pour le lien, celui dans l'article ne pointait que vers la liste de diff, j'ai corrigé.
    1. Avatar de passionlinux
      passionlinux -
      Coucou, Sogal et Bertrandbo,
      Merci pour cette explication, voila la c'est très clair et c'est top
    1. Avatar de marc-andré
      marc-andré -
      Bonjour déterrage de vieux post ! mais je suis tombé là dessus sur le wiki de btrfs or, comme Leap est par défaut avec btrfs, doit--on en conclure qu'il ne faut pas l'installer sur un ssd, mais uniquement sur hdd ? "Is Btrfs optimized for SSD? There are some optimizations for SSD drives, and you can enable them by mounting with -o ssd. As of 2.6.31-rc1, this mount option will be enabled if Btrfs is able to detect non-rotating storage. Note that before 4.14 the ssd mount option has a negative impact on usability and lifetime of modern SSDs which have a FTL (Flash Translation Layer). See the ssd section in Gotchas for more information. Note that -o ssd will not enable TRIM/discard. " https://btrfs.wiki.kernel.org/index....zed_for_SSD.3F
    1. Avatar de sogal
      sogal -
      On ne peut rien conclure de tel de cet extrait. Il n'indique en rien qu'il ne faut pas utiliser btrfs avec un disque SSD ou même que btrfs aurait des performances moindres sur SSD.
      Il indique tout simplement que l'usage de btrfs bénéficie de certaines optimisations (et il faudrait creuser lesquelles, dans quels cas d'usage) s'il est utilisé avec l'option de montage -o ssd. À compter du noyau Linux 4.14 cette option n'est plus nécessaire et peut même avoir un impact négatif sur les SSD disposant d'un FTL.
      Pour info, j'utilise btrfs depuis 2016 sur 4 machines différentes disposant de SSD (dont une avec RAID 1 SSD) sans problèmes ou crash.
  • Dons / Adhésion


    Dons
    Si vous aimez notre site web et que vous voulez participer financièrement, vous pouvez nous faire un don grâce à PayPal.


    Choisissez votre somme, et cliquez sur le bouton "donate" ci-dessous.



    Adhésion
    Si vous désirez être membre de notre association, vous pouvez aussi adhérer grâce à PayPal.


    Cliquez sur le bouton "PayPal" ci-dessous.

  • SUSECon 2017

     
    SUSEcon 2017
     
     
  • Derniers commentaires d'articles

    manchette

    openSUSE Leap 15.0 paraîtra le 25 mai prochain

    Salut ;)
    oui, j'ai utilisé zypper dup pour passer de 42.3 à 15 -> sans soucis majeur :)
    La... Voir le dernier message

    manchette le 20/06/2018 12h26
    Doctor Who

    Assemblée Générale Alionet 2018

    Les discussions se passent ici :... Voir le dernier message

    Doctor Who le 19/06/2018 13h21
    jtro

    Publication d'openSUSE Leap 15.0

    oui,ça change un peu,les raccourcis clavier de gnome shell sont conservés apparemment. Je trouve ça... Voir le dernier message

    jtro le 15/06/2018 08h43
    sogal

    Publication d'openSUSE Leap 15.0

    Si, ça correspond à GNOME 3 version Classique, adapté à la sauce SLE. C'est pas mal et pas... Voir le dernier message

    sogal le 15/06/2018 07h56