Les éditions LTS (Long Term Support) d’Ubuntu permettent un support technique de cinq ans, que l’on peut faire grimper jusqu’à 10 ans avec l’abonnement Ubuntu Pro. Ce support peut maintenant être poussé jusqu’à 12 ans, à partir d’Ubuntu 14.04, dont le support maximal court désormais jusqu’en 2026.
L’option se nomme « Legacy Support » et son tarif est inconnu. Dans son annonce, Canonical indique en effet que les entreprises intéressées doivent prendre contact avec elle pour demander un devis.
Si l’éditeur s’adresse aux entreprises, c’est qu’une telle prolongation ne peut combler un manque que dans des cas spécifiques. Par exemple, un poste en particulier ou un serveur faisant tourner des services et applications qui ne seraient plus disponibles sur des versions ultérieures du système. Deux années supplémentaires peuvent faire la différence.
Rappelons qu’Ubuntu 24.04, nommée Noble Numbat, sortira le mois prochain. Comme tous les deux ans, il s’agira de la nouvelle mouture LTS.
Commentaires (4)
#1
Dans le cas d'un Linux, j'ai des doutes que ce soit la plus grande motivation. De mon expérience, c'est plutôt pour éviter les compatibilités cassantes de librairies / middlewares qui évoluent avec un cycle rapide sur les branches en support court contrairement au cycle long avec bugfix et security pour les LTS. Aussi pour avoir un Kernel à support étendu qui n'intègre pas de breaking changes.
Au delà de ça, j'ai très rarement vu de produit requérant une version spécifique d'une distribution Linux. Plutôt du hardware ou par exemple mon micro serveur HP avait son RAID matériel non fonctionnel sur Debian là où Ubuntu était supportée (question de pilotes qui n'étaient pas dispo sur la première je suppose, j'ai pas cherché plus loin à l'époque).
Les éditeurs fonctionnent plutôt à coup de matrice de compatibilité indiquant la liste des distribs qu'ils considèrent comme supportés (en gros : ça démarre dessus). L'autre travers est aussi de fournir du package uniquement pour certaine distrib, type installeur deb ou rpm, mais ça c'est devenu rare je trouve avec la containerisation.
Un cas par contre plus concret : la compatibilité avec les Cloud providers. De base la question ne se pose pas pour une VM classique, mais si on veut utiliser les outils du CSP pour du monitoring avancé ou de l'analyse de charge, toutes les distribs ne sont pas supportées par ces derniers.
Historique des modifications :
Posté le 26/03/2024 à 07h39
Dans le cas d'un Linux, j'ai des doutes que ce soit la plus grande motivation. De mon expérience, c'est plutôt pour éviter les compatibilités cassantes de librairies / middlewares qui évoluent avec un cycle rapide sur les branches en support court et en cycle long avec bugfix et security pour les LTS. Aussi pour avoir un Kernel à support étendu qui n'intègre pas de breaking changes.
Au delà de ça, j'ai très rarement vu de produit requérant une version spécifique d'une distribution Linux. Plutôt du hardware ou par exemple mon micro serveur HP avait son RAID matériel non fonctionnel sur Debian là où Ubuntu était supportée (question de pilotes qui n'étaient pas dispo sur la première je suppose, j'ai pas cherché plus loin à l'époque).
Les éditeurs fonctionnent plutôt à coup de matrice de compatibilité indiquant la liste des distribs qu'ils considèrent comme supportés (en gros : ça démarre dessus). L'autre travers est aussi de fournir du package uniquement pour certaine distrib, type installeur deb ou rpm, mais ça c'est devenu rare je trouve avec la containerisation.
Un cas par contre plus concret : la compatibilité avec les Cloud providers. De base la question ne se pose pas pour une VM classique, mais si on peut utiliser les outils du CSP pour du monitoring avancé ou de l'analyse de charge, toutes les distribs ne sont pas supportées par ces derniers.
Posté le 26/03/2024 à 07h39
Dans le cas d'un Linux, j'ai des doutes que ce soit la plus grande motivation. De mon expérience, c'est plutôt pour éviter les compatibilités cassantes de librairies / middlewares qui évoluent avec un cycle rapide sur les branches en support court contrairement au cycle long avec bugfix et security pour les LTS. Aussi pour avoir un Kernel à support étendu qui n'intègre pas de breaking changes.
Au delà de ça, j'ai très rarement vu de produit requérant une version spécifique d'une distribution Linux. Plutôt du hardware ou par exemple mon micro serveur HP avait son RAID matériel non fonctionnel sur Debian là où Ubuntu était supportée (question de pilotes qui n'étaient pas dispo sur la première je suppose, j'ai pas cherché plus loin à l'époque).
Les éditeurs fonctionnent plutôt à coup de matrice de compatibilité indiquant la liste des distribs qu'ils considèrent comme supportés (en gros : ça démarre dessus). L'autre travers est aussi de fournir du package uniquement pour certaine distrib, type installeur deb ou rpm, mais ça c'est devenu rare je trouve avec la containerisation.
Un cas par contre plus concret : la compatibilité avec les Cloud providers. De base la question ne se pose pas pour une VM classique, mais si on peut utiliser les outils du CSP pour du monitoring avancé ou de l'analyse de charge, toutes les distribs ne sont pas supportées par ces derniers.
#2
Devoir passer du temps à maintenir la conception matérielle et logicielle, hors des correctifs, c'est terriblement cher.
#2.1
#2.2