la possibilité qu’un binaire compilé d’un côté ne fonctionne pas de l’autre et quand même très très mince
Le "très très mince" fait tout le boulot ici, et c'est pas exactement une réponse qui veut dire grand chose. En pratique, même avec des distros qui ne s'estiment pas "binairement compatible", ça marche:
$ ssh debian.example.org grep PRETTY_NAME= /etc/os-release ; scp debian.example.org:/bin/ls /tmp/ ; grep PRETTY_NAME= /etc/os-release ; /tmp/ls /
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
ls 100% 144KB 2.9MB/s 00:00
PRETTY_NAME="Fedora Linux 39.20240222.0 (Silverblue)"
bin boot dev etc home lib lib64 media mnt opt ostree proc root run sbin srv sys sysroot tmp usr var
Je viens de prendre le binaire de ls d'une debian, et je l'ai lancé sur Fedora, et ça marche out of the box, malgré des versions relativement différentes de tout. Alors oui, j'ai pris un binaire trivial qui bouge pas beaucoup, mais je pense qu'il y a pas énormément besoin de grand chose pour que ça marche "la plupart du temps".
Par exemple, les efforts pour faire pareil avec les wheels de python montre que tu peux faire des choses si tu te restreint niveau lib. L'usage des conteneurs (que ça soit Docker ou flatpak ou autre) sans se préoccuper du noyau sous jacent la plupart du temps montre que venir avec ses libs est largement suffisant pour une grande partie des cas.
Mais si tu veux un truc qui marche 100% du temps, c'est impossible. Par définition, RHEL n'est pas 100% binairement compatible avec elle même d'une version mineure à une autre.
Trivialement, un exploit qui permet de devenir root qui ne marche plus suite à un correctif, c'est une rupture de la compatibilité entre 2 versions de RHEL, et c'est pareil pour les correctifs de bugs.
Et c'est pas que les exploits, vu que le souci se pose aussi avec les pilotes externes du noyau, malgré la présence d'un ABI réduite plus ou moins garantie par RHEL (voir les histoires de kABI, pour Kernel ABI).
Et c'est justement le fait que le 100% est impossible, et que le "dans pas mal de cas" est trivial qui fait que je pense que ça veut rien dire. Si on définit ni ce qui doit être compatible (eg, quel classe de binaire est affectée ou pas), ni compatible avec quoi exactement (eg, quel version de RHEL, quel ABI non documentée, etc), ç'est creux.
Ça ne veut rien dire peut-être pour toi je te garantie que ça fait sens pour un tas de personnes.
L'humain va trouver du sens la ou il y en a pas. On voit des formes dans les nuages et ailleurs, toutes les civilisations ont développés des religions de façon indépendantes, et si j'en crois la fin d'un article du Monde de hier qui cite Elia Girauldon, même des personnes que les religions refusent se retrouvent à mettre en place des formes de spiritualités comme l'astrologie.
Donc oui, je suis pas étonné que des gens voient du sens la ou il y en a pas. Mais que ça fasse sens pour des gens ne veut pas dire que les gens soient capables de définir exactement, ni que ça résiste à un examen critique.
Tiens d’ailleurs, intéressant que tu parles de Fedora, qu’est-ce qui n’allait pas pour qu’elle remplisse le rôle attribué à CentOS Stream ?
Pour les mêmes raisons qu'Ubuntu n'est pas Debian (ou du moins, certaines raisons). Il y a d'une part des questions de cycles de releases (Fedora sort tout les 6 mois, RHEL mets sans doute plus de 6 mois pour décider quand sort la prochaine distro et avec quoi), mais aussi l'envie de ne pas forcer la communauté à suivre les désirs de RH avec des gros sabots, et ne pas faire un seul produit quand il y a des besoins opposés (à savoir d'un coté "avoir quelque chose qui ne bouge que lentement" et de l'autre "quelque chose qui bouge plus").
Vu que RH s'engage commercialement sur le support de RHEL, il y a un besoin légitime de dire non à certaines modifications, de contrôler les versions, etc. Et ce besoin ne passerait pas vraiment dans une distro communautaire, car la gouvernance serait satisfaisante ni pour les gens des équipes RHEL, ni pour les gens qui bossent sur Fedora. C'est pour ça qu'avant, les équipes de RHEL prenait un snapshot de Fedora, changeait des paquets, puis créait RHEL à partir de ça.
Maintenant, cette distribution qui était interne est publiée sous le nom de Centos Stream. Elle est publié avant RHEL X.0, et reste mise à jour après RHEL X.0 pour devenir RHEL X.1, X.2, X.3, etc.
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 5.
Le "très très mince" fait tout le boulot ici, et c'est pas exactement une réponse qui veut dire grand chose. En pratique, même avec des distros qui ne s'estiment pas "binairement compatible", ça marche:
Je viens de prendre le binaire de ls d'une debian, et je l'ai lancé sur Fedora, et ça marche out of the box, malgré des versions relativement différentes de tout. Alors oui, j'ai pris un binaire trivial qui bouge pas beaucoup, mais je pense qu'il y a pas énormément besoin de grand chose pour que ça marche "la plupart du temps".
Par exemple, les efforts pour faire pareil avec les wheels de python montre que tu peux faire des choses si tu te restreint niveau lib. L'usage des conteneurs (que ça soit Docker ou flatpak ou autre) sans se préoccuper du noyau sous jacent la plupart du temps montre que venir avec ses libs est largement suffisant pour une grande partie des cas.
Mais si tu veux un truc qui marche 100% du temps, c'est impossible. Par définition, RHEL n'est pas 100% binairement compatible avec elle même d'une version mineure à une autre.
Trivialement, un exploit qui permet de devenir root qui ne marche plus suite à un correctif, c'est une rupture de la compatibilité entre 2 versions de RHEL, et c'est pareil pour les correctifs de bugs.
Et c'est pas que les exploits, vu que le souci se pose aussi avec les pilotes externes du noyau, malgré la présence d'un ABI réduite plus ou moins garantie par RHEL (voir les histoires de kABI, pour Kernel ABI).
Et c'est justement le fait que le 100% est impossible, et que le "dans pas mal de cas" est trivial qui fait que je pense que ça veut rien dire. Si on définit ni ce qui doit être compatible (eg, quel classe de binaire est affectée ou pas), ni compatible avec quoi exactement (eg, quel version de RHEL, quel ABI non documentée, etc), ç'est creux.
L'humain va trouver du sens la ou il y en a pas. On voit des formes dans les nuages et ailleurs, toutes les civilisations ont développés des religions de façon indépendantes, et si j'en crois la fin d'un article du Monde de hier qui cite Elia Girauldon, même des personnes que les religions refusent se retrouvent à mettre en place des formes de spiritualités comme l'astrologie.
Donc oui, je suis pas étonné que des gens voient du sens la ou il y en a pas. Mais que ça fasse sens pour des gens ne veut pas dire que les gens soient capables de définir exactement, ni que ça résiste à un examen critique.
Pour les mêmes raisons qu'Ubuntu n'est pas Debian (ou du moins, certaines raisons). Il y a d'une part des questions de cycles de releases (Fedora sort tout les 6 mois, RHEL mets sans doute plus de 6 mois pour décider quand sort la prochaine distro et avec quoi), mais aussi l'envie de ne pas forcer la communauté à suivre les désirs de RH avec des gros sabots, et ne pas faire un seul produit quand il y a des besoins opposés (à savoir d'un coté "avoir quelque chose qui ne bouge que lentement" et de l'autre "quelque chose qui bouge plus").
Vu que RH s'engage commercialement sur le support de RHEL, il y a un besoin légitime de dire non à certaines modifications, de contrôler les versions, etc. Et ce besoin ne passerait pas vraiment dans une distro communautaire, car la gouvernance serait satisfaisante ni pour les gens des équipes RHEL, ni pour les gens qui bossent sur Fedora. C'est pour ça qu'avant, les équipes de RHEL prenait un snapshot de Fedora, changeait des paquets, puis créait RHEL à partir de ça.
Maintenant, cette distribution qui était interne est publiée sous le nom de Centos Stream. Elle est publié avant RHEL X.0, et reste mise à jour après RHEL X.0 pour devenir RHEL X.1, X.2, X.3, etc.