Re: Et toujours LA question

Ben justement : non (d'après toi, pourquoi donc RH vend le
support sur RHEL et on pas Stream?).

Je note qu'on te reconnaît à ton audace.

Mais en effet, je peux te dire pourquoi le support de mon employeur est sur RHEL et pas sur Stream, et pourquoi y a des versions stables.

Primo, c'est pour les certifications, notamment en vue de vendre au gouvernement fédéral des USA (mais pas que). Si tu veux vendre à l'armée américaine, faut que ton produit soit certifié par le NIST. Je ne connais pas le détail, mais ç'est sans doute comme les processus de certifications ISO. C'est pas forcément compatible avec la façon de faire dans le logiciel libre, et il faut donc séparer les 2. Par exemple, j'imagine qu'il y a des questions d'audit, donc d'avoir un salarié RH responsable d'avoir pris le code de la communauté (eg, un truc d'ordre legal).

Moi, je m'en fout de FIPS, et je suppose toi aussi. Mais pas certains clients, donc si les clients veulent du FIPS, il y a du FIPS. En règle général, la communauté n'en veut pas, et ne va pas se plier aux règles de certifications.

Ensuite, parce qu'il faut traduire la documentation et les logiciels, car non seulement tout le monde ne parle pas anglais, mais en plus, il y a des pays ou tu peux pas vendre au gouvernement sans ça (exemple, la loi no 94-665 du 4 août 1994 relative à l'emploi de la langue française). La traduction, ça implique aussi d'avoir une période ou les chaînes ne bougent pas, et de sortir plus tard.

Moi, je m'en fout, je parle anglais, donc je préfère ne pas attendre. Mais quand un client demande ça, tu t'adaptes.

Tertio, parce que le marketing se sert des versions stables pour faire du marketing. Envoyer des mails, présenter les fonctionnalités, inviter les clients à regarder des photos de croissants pour rappeler ce qu'on avait avant la pandémie, tout ça.

Moi, je m'en fout un peu, j'ai une boulangerie en bas de chez moi. Et la communauté du libre en général semble ne pas trop faire de marketing.

Donc il y a tout un tas d'activité d'une boite normale qui s'appuie sur l'idée d'avoir une release, mis qui sont non seulement pas important pour la plupart des utilsiateurs finaux (eg, le marketing), mais qui vont aussi rajouter de la lenteur qui ne va pas bénéficier à grand monde (FIPS et divers certifications).

Vous avez donc décidé d'utiliser les "release candidate", la
où des bugs (y compris des regrettions)

Ma foi, si tu vois un régression, n'hésite pas à montrer le bug tracker qu'on puisse en discuter sur la base des faits.

Sinon, tu es juste en train de faire du FUD a quelqu'un de visiblement mieux placé que toi sur le sujet.

sont chopés avant d'être en stable donc avec plus de bugs que
RHEL (ou Rocky Linux), en prod sans vraiment l'assumer, on a
l'impression...

Non, pour ça, j'ai des serveurs Fedora en prod, comme par exemple, une paire de firewall en HA:
$ ssh masa.rht.gluster.org -l root uname -a
Linux masa.rht.gluster.org 5.14.14-300.fc35.x86_64 #1 SMP Wed Oct 20 16:14:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Ou des reverses proxy en HA:
$ ssh proxy01.rht.gluster.org -l root uname -a
Linux proxy01.rht.gluster.org 5.14.15-300.fc35.x86_64 #1 SMP Wed Oct 27 15:53:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Mais je fait pareil avec mes serveurs perso sur mon lan:
$ ssh root@git.home uname -r
5.15.12-200.fc35.x86_64

Ou hors du lan:
$ ssh root@xmpp uname -r
5.14.17-301.fc35.x86_64

Et crois moi, j'ai aucun souci à mettre à jour ces machines vers les beta de Fedora, donc je pense que j'arrive pleinement à faire la différence entre une RC et une stable à l'usage.

Sinon, tu peux aussi aller dire à Facebook qu'ils n'assument pas, vu le slide 24.