Bah, à moins d’être une assoc ou une PME sans le sou, pourquoi tu ne pourrais pas payer pour avoir du support à long terme ?
Je parle du projet qui fournit la distrib. Si Centos était maintenu par une petite entreprise qui souffre en raison du covid, je serais plus compréhensif sur l'abandon subit du support. Dans le cas de Redhat qui de toute façon produit les sources pour sa distrib, maintient le tooling, ce n'est pas vraiment excusable.
sans mise à jour pendant 10 ans
Il est mis à jour d'un point de vue sécurité. Pour une entreprise qui fournit un logiciel et veut fournir du support, c'est intéressant de pouvoir supporter des distrib qui ne varie quasi pas pendant 10 ans. Et l'existence de centos permet de ne pas imposer à ses clients une distrib coûteuse, d'autant plus si le support de la distrib est plus cher que l'appli elle-même.
Du reste il existe de nombreux types de fonctionnement d'entreprise mais dans tous les cas la séparation des responsabilités est toujours un point compliqué. Les sysadmins voudraient pouvoir mettre à jour et rebooter les serveurs quand ils veulent, les gestionnaires d'applications voudraient que rien ne change sans leur accord. C'est un point en partie résolu avec l'usage des solutions de containers, de distribs types atomiques, de séparation des packages OS et applis mais tous les types d'organisations/applications ne le supportent bien et une distrib à support long terme comme ubuntu LTS, RHEL ou Centos permet aux sysadmins de dire : regardez, on vous fournit ce serveur et pendant 10 ans on garde cet accord que chaque premier jeudi du mois on peut mettre à jour vos noeuds #1 de vos cluster serveurs et le rebooter à 3h du matin et les noeuds #2 le jeudi suivant. Le gestionnaire d'appli est content, il n'a pas à tout tester pour chaque version de noyau/librairies x ou y comme il devrait le faire sur un Rolling Release et il n'est pas obligé de migrer de serveur tous les 2-3 ans parce que la distro ne sera plus supporter.
Quand tu gères 10 serveurs dans ton coin, c'est pas la mer à boire de migrer tous les 2 ans. Quand tu en as 1000-2000 t'es content si tu peux étaler les différentes campagnes de migrations entre les n équipes/clients tiers.
[^] # Re: L'art et la manière
Posté par Psychofox (Mastodon) . En réponse au lien CentOS Project shifts focus to CentOS Stream. Évalué à 8.
Je parle du projet qui fournit la distrib. Si Centos était maintenu par une petite entreprise qui souffre en raison du covid, je serais plus compréhensif sur l'abandon subit du support. Dans le cas de Redhat qui de toute façon produit les sources pour sa distrib, maintient le tooling, ce n'est pas vraiment excusable.
Il est mis à jour d'un point de vue sécurité. Pour une entreprise qui fournit un logiciel et veut fournir du support, c'est intéressant de pouvoir supporter des distrib qui ne varie quasi pas pendant 10 ans. Et l'existence de centos permet de ne pas imposer à ses clients une distrib coûteuse, d'autant plus si le support de la distrib est plus cher que l'appli elle-même.
Du reste il existe de nombreux types de fonctionnement d'entreprise mais dans tous les cas la séparation des responsabilités est toujours un point compliqué. Les sysadmins voudraient pouvoir mettre à jour et rebooter les serveurs quand ils veulent, les gestionnaires d'applications voudraient que rien ne change sans leur accord. C'est un point en partie résolu avec l'usage des solutions de containers, de distribs types atomiques, de séparation des packages OS et applis mais tous les types d'organisations/applications ne le supportent bien et une distrib à support long terme comme ubuntu LTS, RHEL ou Centos permet aux sysadmins de dire : regardez, on vous fournit ce serveur et pendant 10 ans on garde cet accord que chaque premier jeudi du mois on peut mettre à jour vos noeuds #1 de vos cluster serveurs et le rebooter à 3h du matin et les noeuds #2 le jeudi suivant. Le gestionnaire d'appli est content, il n'a pas à tout tester pour chaque version de noyau/librairies x ou y comme il devrait le faire sur un Rolling Release et il n'est pas obligé de migrer de serveur tous les 2-3 ans parce que la distro ne sera plus supporter.
Quand tu gères 10 serveurs dans ton coin, c'est pas la mer à boire de migrer tous les 2 ans. Quand tu en as 1000-2000 t'es content si tu peux étaler les différentes campagnes de migrations entre les n équipes/clients tiers.