S'ils ne voulaient pas supporter 42 distributions, ils
pourraient parfaitement supporter le nombre qu'ils veulent de
noyau LTS (la dernière, les 2 dernières, les 3 dernières...) et
te dire de te débrouiller avec ton OS (éventuellement avoir
une préco pour une distrib', mais une préconisation pas un
truc qui sert à t'invalider en support).
C'est une distinction artificielle basé sur un détail purement technique, et supposer qu'il y a une frontière entre l'userspace et le noyau pour le support.
Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.
Les distributions vont faire des efforts pour que ça casse pas trop souvent (ne serais que pour les upgrades), mais si ça casse, elles vont pas dire "on va corriger pour ton kernel custom", mais "ça marche avec notre noyau, corrige le tien".
Donc l'idée d'avoir un OS séparé du noyau, c'est une illusion, tout est mis pour fonctionner ensemble, et c'est pas parce que tu estimes qu'il y a une frontière que la frontière a du sens pour un autre usage (eg, délimiter les responsabilités pour le support).
Si c'est le cas du coup c'est moins "on veut pas supporter 42
distributions" que "on ne supporte que les distributions avec
qui on a un accord financier". Mais ça revient plus ou prou au
même, faut avoir une cravate et un chéquier pour pouvoir
exister en tant que distribution.
Il y a plusieurs alternatives, comme avoir les distributions faire le support niveau 1, mais ça demande aussi un chéquier soit coté distribution. Tu peux aussi faire le support en interne, et avoir ta propre équipe kernel. Ça demande de sortir aussi le chéquier, mais ça semble être courant dans les boites de tech d'une certaine taille (cf https://danluu.com/in-house/ ).
Mais ça demande toujours de sortir le chéquier parce que visiblement, personne ne veut le faire gratuitement, et ça mérite sans doute la question de "pourquoi ?".
[^] # Re: Fermilab & CERN, scientific linux
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 3.
C'est une distinction artificielle basé sur un détail purement technique, et supposer qu'il y a une frontière entre l'userspace et le noyau pour le support.
Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.
Les distributions vont faire des efforts pour que ça casse pas trop souvent (ne serais que pour les upgrades), mais si ça casse, elles vont pas dire "on va corriger pour ton kernel custom", mais "ça marche avec notre noyau, corrige le tien".
Donc l'idée d'avoir un OS séparé du noyau, c'est une illusion, tout est mis pour fonctionner ensemble, et c'est pas parce que tu estimes qu'il y a une frontière que la frontière a du sens pour un autre usage (eg, délimiter les responsabilités pour le support).
Il y a plusieurs alternatives, comme avoir les distributions faire le support niveau 1, mais ça demande aussi un chéquier soit coté distribution. Tu peux aussi faire le support en interne, et avoir ta propre équipe kernel. Ça demande de sortir aussi le chéquier, mais ça semble être courant dans les boites de tech d'une certaine taille (cf https://danluu.com/in-house/ ).
Mais ça demande toujours de sortir le chéquier parce que visiblement, personne ne veut le faire gratuitement, et ça mérite sans doute la question de "pourquoi ?".