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.
Parce que tu pense que les fabriquants (je pense aux fabriquants de matériel - on parle de DELL, IBM, Oracle,... - qui supportent actuellement RH pas d'embarquer où RHEL est inexistant) ont une intrication aussi grande ? Par exemple tu aurait un iptables-hp qui utilise l'appel système créé par HP qui utilise le circuit top moumout de la carte réseau HP ?
Comme je le dis plus haut, je n'arrive pas à trouver de cas où ce que tu affirme se révèle. Dans les faits, ses constructeurs sont supporté upstream (de leur fait ou pas) et tu marche aussi bien avec une slackware qu'avec la RHEL.
[^] # Re: Fermilab & CERN, scientific linux
Posté par barmic 🦦 . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 2.
Parce que tu pense que les fabriquants (je pense aux fabriquants de matériel - on parle de DELL, IBM, Oracle,... - qui supportent actuellement RH pas d'embarquer où RHEL est inexistant) ont une intrication aussi grande ? Par exemple tu aurait un iptables-hp qui utilise l'appel système créé par HP qui utilise le circuit top moumout de la carte réseau HP ?
Comme je le dis plus haut, je n'arrive pas à trouver de cas où ce que tu affirme se révèle. Dans les faits, ses constructeurs sont supporté upstream (de leur fait ou pas) et tu marche aussi bien avec une slackware qu'avec la RHEL.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll