Sauf que c'est complètement con de pousser un truc "pour tester" si les gens ne savent pas qu'il y a un changement.
Le but d'un test, c'est d'avoir des retours, et pour avoir des retours, faut que les gens soient d'accord et bossent avec toi.
Personne ne va pousser un truc en se disant "yolo, ça va peut être casser la prod". Je rappelle aussi qu'il y a des tests automatisés, donc à minima, les fonctionnalités de base sont vérifiés.
Si le but est de faire des tests, le modèle d'EPEL et de Fedora avec un dépôt "testing" et des volontaires marchent largement mieux, donc pourquoi se faire chier à faire autrement vu que ça va juste apporter des emmerdes à tout le monde ?
D'ailleurs, c'est pour ça aussi qu'il y a des structures séparées, les SIG (exemple) pour justement permettre ce genre de choses. Et les SIGs ne datent pas de Stream, il y a déjà eu ça à l'époque de Centos 7.
Donc si ça ne bénéficie à personne, si il y a explicitement une structure ailleurs documenté pour faire les tests, pourquoi quelqu'un ferait le contraire ?
Qu'avez-vous mis en place pour gérer les upgrades permanents de
version de CentOS (c'est ce que c'est en pratique)? D'après ton
commentaire ça a l'air d'être "rien", c'est être très joueur!
Qu'est-ce qui a fait le choix d'être si joueur?
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.
"Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available"
On ne le voit pas, mais j'ai surligné en flu "additional" sur mon écran :p
Donc quand le système passes de Centos 8 à Centos Stream 8, pas grand chose ne change, et il n'y a pas de migration magique vers Centos Stream 9 quand CS9 est dispo (la preuve, c'est dispo, et j'ai encore des CS8 en prod).
Et Centos Stream 8 est supporté jusqu'à la fin mai 2024, cf le site.
Ensuite, prendre Centos Stream 9 en production pour le moment (cad avant la release de RHEL final), c'est en effet autre chose. D’expérience, la bêta ne va pas avoir des changements énormes, et on a prévu d'en installer une sur un hyperviseur (parce que YOLO). Mais le matos vient juste d'être livré, donc je peux pas dire grand chose avant quelques semaines.
A titre perso, j'ai un pc qui me sert de serveur que j'ai installé avec une version beta de RHEL 7 (comme un goret en prenant la tour au bureau et en allant taper dans le miroir interne), et je me souviens pas avoir eu de souci notable à cause de ça, donc je ne pense pas que CS9 dans la phase avant la release de RHEL soit fondamentalement cassé.
Et si les gens pensent qu'il n'y a qu'un seul flux de la distro pour 8 et 9, je comprends mieux pourquoi tout le monde s'affole. J'imagine que le site web pourrait être plus clair à ce sujet.
Tout n'est qu'une question d'image ici. Stream peux avoir
toutes les qualités possibles, son image est:
Image en partie poussé aussi par les concurents. J'ai vu assez de commerciaux pour savoir qu'ils ont aucun scrupule à ce niveau la.
centos8 a été avorté en terme de support, donc manque de
confiance envers RedHAt sur le sujet après pour ce qui concerne
autre chose que RHEL, Stream en hérite automatiquement,
Centos n'avait pas de support avant (au sens support téléphonique, tout comme au sens recevoir des bugs), donc au final, si le client découvre qu'il n'avait personne à appeler, ç'est tant mieux.
c'est avant la RHEL/production dans son workflow, donc c'est
instable/qualification. Basique.
C'est un peu du bullshit comme raisonnement, vu que personne ne va mettre des Linux Mint en prod parce que c'est après Ubuntu qui est après Debian.
Et c'est bien ce que souhaite RedHat je pense, qu'on arrête
d'avoir une distribution "production" gratuite (qu'en plus lui
paie ). C'est réussit
Si RH voulait se débarrasser de Centos, il suffisait d'attendre.
Tout les clones ont fini par s’arrêter d'eux même, et Centos elle même n'était super vivace vers 2011-2013, avec une gouvernance non transparente, etc.
Par exemple, il y a eu un délai de 6 à 7 mois entre RHEL et Centos pour les versions 6.0 et 6.1 (à comparer avec le mois pour Centos 5.0 et 5.1).
En pratique, je pense que ce que Centos a fait, c'est surtout décimer les distros concurrentes de RHEL. Vu que personne n'a les moyens d'attaquer RHEL par le haut en fournissant un produit plus prestigieux et de meilleur qualité, le seul moyen de concurrencer c'est en étant moins cher ou différent.
Sauf que faire moins cher que Centos, c’est quand même tendu.
Et faire différent, c'est pas évident non plus. Oracle a tenté, ils ont pas réussi.
Donc RH avait tout à gagner à garder Centos en vie.
Et RH a encore plus à gagner à avoir des clones actifs vu que les dits clones ont réussi à faire ce que Centos n'a jamais pu faire par design, à savoir rassembler une communauté de contributeurs. Et vu que le workflow de stream est ouvert, c'est beaucoup plus naturelle d'aller collaborer sur Stream pour Almalinux et co que de partir dans leur coin.
Je dit par design car le mot d'ordre de Centos, ça a toujours été "pour les changements, c'est bugzilla.redhat.com".
Ensuite, je comprends que pour la frange de la communauté qui veut des trucs gratos, ça semble faire chier. Mais c'est sans doute la même frange qui a du paniquer avec log4j partout.
Tu veux dire que tu as migré vers l'un des sus-nommé ou vers
Stream ?
Vers Stream
Je serais intéressé d'un retour d'expérience d'une entreprise
qui utilise une rolling release en prod, chaque fois que j'ai
suggéré l'idée dans mes employeurs précédent j'ai assisté à
une grande levée de boucliée mais sans réel argument
pertinent. Il est facile de séparer OS de base et applis
critiques , de faire
pointer des environnements différents sur des snapshots
différents des repos, d'automatiser des suites de tests.
Alors vu mon employeur, le mandat de mon équipe et surtout la taille du parc et de l'équipe que je soit un bon exemple.
Mais je pense aussi qu'appeler Centos 8 une "rolling release", c'est comme dire qu'un avion est une automobile parce que ça peut se déplacer sur une route.
Centos 8 a des tests de QA automatisé, une promesse de compatibilité binaire via RHEL, et une politique de ne pas mettre à jour de façon disruptive. C'est ni Rawhide, ni Debian Unstable ou les devs vont mettre à jour sur la derniére version d'upstream, dont le but est de preparer la prochaine stable, etc.
Centos 8 stream est déjà stable (au sens figé), et la seule différence avec avant, c'est d'avoir les mises à jours de sécurité et de bugfix au fil de l'eau, donc de ne pas attendre que RHEL fasse une release, ce qui est pour moi un bonus.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie. Et vu que Centos n'a pas de support pour les versions mineurs autre que la dernière, tu es quand même obligé de mettre à jour pour la sécurité. Prendre une version mineur et appliquer les correctifs 1 par 1, c'est ni supporté, ni supportable, vu que tout est construit en visant les derniers RPMs. Ça marche sans doute plus parce que les paquets ont des modifs minimums plus que par un design particulier de la distro.
Ensuite, la ou je peux imaginer qu'une rolling release importen, c'est ce qui est hors de la distribution. Par exemple, le kernel ne garanti pas son ABI (même dans les LTS, etc), donc les gens qui dépendent de drivers externes ont sans doute peur de soucis (souci qui existe deja de base avec une mise à jour de sécurité avant, vu que l'ABI est toujours non garanti).
De même, Centos ne va tester que la distribution, si un produit proprio externe dépend d'un truc non documenté, ça peut casser. Mais pareil, ça aurait fini par casser à tout moment lors d'une mise à jour de sécurité.
Donc moi, j'ai ni l'un, ni l'autre, donc quand on m'a dit "tu vpeux avoir des bugfixes plus vite, et faire des PR plutot que d'aller faire chier les products managers/owners", j'ai dit "banco".
D'ailleurs pour plaire au LGBT+ sous representes dans cette
premiere partie, j'imagine que dans la suite, Paul va faire
des enfants avec Stilgar grace aux cuves Xolotl des Tleilaxu
plutot qu'avec Chani
Ça serait une vision assez rétrograde et conservatrice, vu que ça va continuer à positionner les personnes LGBT comme étant le résultat de la science fiction, ce qui va conforter à pas cher les dogmes de la société.
Mais vu que le héros principal hérite le pouvoir (eg, comme les rois d'antan), et que ses capacités sont aussi le résultat de la sélection par des alliances, etc, l'univers entier (dans le film) se lit facilement via un prisme essentialiste et naturalisant. Et ça, c'est sans rajouter le thème de la libération des Fremen grâce à Leto qui reste quand même la pour coloniser la planète au départ, qui va quand même pas mal conforter les gens dans l'idée que les sauvages peuvent pas se libérer eux même.
Donc je ne serais en effet pas surpris de voir ce genre de choses, vu que ça va faire s'agiter les franges les plus conservatrices pour de la pub à peu de frais.
Le seul point bloquant, c'est l'impossibilité de retirer ça aux montages pour les marchés comme la Russie, la Chine, les émirats arabes unis, etc.
Quelque chose qui serait vraiment disruptif, ça ne serait pas d'inventer une technologie sorti du chapeau qui ne fait que renforcer le status quo via un tour de passe passe, mais de mettre plus en avant des structures sociales différentes plutôt que la question de la fécondation.
Mais vu l'importance de la génétique dans l’œuvre originale, ça ne va pas arriver.
Et pour le moment, je ne crois pas avoir vu d'adaptations prévues des œuvres de la même époque, œuvres qui seraient plus disruptives à ce niveau comme The Left Hand of Darkness ou The Moon is a Harsh Mistress, toute les 2 sorties en même temps que Dune.
Ça, et malgré le fait que le film soit long, il y a quelques explications qui manquent (genre, toute la question de pourquoi il n'y a pas d'IA et des mentats, etc).
Ensuite, j'ai bien aimé le film, et je n'ai pas de souvenir précis de celui de David Lynch (mais je me souviens de Mulholland Drive et Twin Peaks, donc y a peut être une raison pour l'absence).
Mon chef voulait qu'on fasse un article de blog sur notre expérience de la migration, mais vu que y a 2 commandes donné dans la FAQ et le reste marche pareil, on a pas réussi à trouver de quoi faire un article intéressant (genre, même pas "on a pu rajouter un correctif de bug" vu qu'on a pas eu de bugs).
Je vois vraiment pas trop pourquoi partir sur les dérivés qui vont avoir les mêmes paquets, mais avec au mieux, un délai dans les correctifs de bugs, au pire, un différentiel sans la majorité des devs pour s'en occuper.
Je pense que la question n'est pas qu'on vieillit, mais plus qu'on se retrouve le cul coincé entre 2 chaises.
On fait du libre aussi par désir d'aider d'autres personnes (en partie), et donc ça va attirer des personnes qui veulent aider les autres. C'est une dynamique positive pour la communauté que d'essayer d'attirer des gens "utiles" et pas des gens qui vont envoyer chier les autres.
Il suffit de voir par exemple les réactions quand une fonctionnalité est retiré (cf les débats sur systemd, GNOME, firefox, etc).
Du coup, comme on récompense (au sens ou on va plus aimer recevoir de l'aide que de ne pas en recevoir), et que le libre auto-sélectionne des gens altruistes, on se retrouve avec une dynamique ou certains se sentent forcés d'être altruiste, même quand ç'est mauvais pour eux long terme.
Au final, c'est pas tant de l'argent pour lui qui manque que de l'argent pour que quelqu'un d'autre fasse une partie du travail. Avoir de l'argent pour lui ne va faire que l'occuper plus, mais la limite fondamental d'avoir 24h par jour est toujours la, et l'impact sur sa santé mentale aussi.
Si l’hypothèse d'une mise à jour d'un service externe (que ça soit Cloudflare ou le répartiteur de charge proposé par GCP) est vérifié, alors ça aurait fini par bloquer quelqu'un d'autre de toute façon, car d'autres personnes utilisent ces services.
Ceci dit, ça aurait pu arriver aussi sur n'importe quoi d'autre, genre l'outil qui vérifie les malwares, le système d'OCSP, ou les mises à jours de plugin.
Franchement j'arrive pas à adhérer à ça. Ça me gène. Je me
suis pas fait vacciner pour avoir un lot mais parce que c'est
une mesure de salubrité publique !
Pourquoi Mint les maintenait avant et plus maintenant?
L’écosystème change, les moyens aussi. Soit il y a eu moins de moyen (moins de sponsoring, inflation, etc), soit les ressources (eg, le temps d'ingé) sont vu comme plus utile ailleurs.
Ensuite, maintenir des patchs, ça prends du temps (donc c'est de l'argent). Et Mint, dans mon souvenir, c'etait pas franchement les champions d'envoyer les trucs upstream.
Du coup, bah, Mint gagne du temps à ne plus patché le navigateur, et gagne sans doute de l'argent si Mozilla partage l'argent avec eux.
Je pige pas trop pourquoi baver sur Mozilla à ce niveau.
Alors, je dit pas que c'est faux (j'ai vu les temps d'attentes aux urgences avant la crise, je suppose que ça n'a pu que grimper), mais je pense qu'un article anonyme sur une plateforme de blog, c'est un chouia louche sur le principe, et que ça mérite de prendre ça avec un peu de précaution.
Si l'article était à l'opposé ("je suis urgentiste, tout les gens souffrent d'avoir Twitter directement dans le cerveau grace à la 5G du vaccin"), je pense qu'on pointerais la non crédibilité du à la plateforme de la même façon. Donc je pense que c'est important d'avoir à minima la même rigueur même quand on est d'accord avec la narration de l'article.
Le reportage a l'air intéressant, et va dans mon sens sur l'hypothèse sur la route de la soie.
Ceci dit, ça dit au début que la Russie n'a pas réussi à livrer ce qu'elle a promis, et me rappelle aussi la campagne de piratages fin 2020 sur les labos.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 2.
Sauf que c'est complètement con de pousser un truc "pour tester" si les gens ne savent pas qu'il y a un changement.
Le but d'un test, c'est d'avoir des retours, et pour avoir des retours, faut que les gens soient d'accord et bossent avec toi.
Personne ne va pousser un truc en se disant "yolo, ça va peut être casser la prod". Je rappelle aussi qu'il y a des tests automatisés, donc à minima, les fonctionnalités de base sont vérifiés.
Si le but est de faire des tests, le modèle d'EPEL et de Fedora avec un dépôt "testing" et des volontaires marchent largement mieux, donc pourquoi se faire chier à faire autrement vu que ça va juste apporter des emmerdes à tout le monde ?
D'ailleurs, c'est pour ça aussi qu'il y a des structures séparées, les SIG (exemple) pour justement permettre ce genre de choses. Et les SIGs ne datent pas de Stream, il y a déjà eu ça à l'époque de Centos 7.
Donc si ça ne bénéficie à personne, si il y a explicitement une structure ailleurs documenté pour faire les tests, pourquoi quelqu'un ferait le contraire ?
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 2.
On a rien mis de plus, on sait lire une FAQ.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 4.
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).
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.
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 -aLinux 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 -aLinux 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 -r5.15.12-200.fc35.x86_64
Ou hors du lan:
$ ssh root@xmpp uname -r5.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.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 3.
En l'occurrence, il y a bien une différence entre Centos stream 8 et Centos Stream 9.
Le miroir a un répertoire 9-stream, pas "stream".
http://mirror.stream.centos.org/9-stream/
Ou "8-stream", pas "stream"
http://mirror.centos.org/centos/8-stream/
C'est aussi dans la FAQ:
"Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available"
On ne le voit pas, mais j'ai surligné en flu "additional" sur mon écran :p
Donc quand le système passes de Centos 8 à Centos Stream 8, pas grand chose ne change, et il n'y a pas de migration magique vers Centos Stream 9 quand CS9 est dispo (la preuve, c'est dispo, et j'ai encore des CS8 en prod).
Et Centos Stream 8 est supporté jusqu'à la fin mai 2024, cf le site.
Ensuite, prendre Centos Stream 9 en production pour le moment (cad avant la release de RHEL final), c'est en effet autre chose. D’expérience, la bêta ne va pas avoir des changements énormes, et on a prévu d'en installer une sur un hyperviseur (parce que YOLO). Mais le matos vient juste d'être livré, donc je peux pas dire grand chose avant quelques semaines.
A titre perso, j'ai un pc qui me sert de serveur que j'ai installé avec une version beta de RHEL 7 (comme un goret en prenant la tour au bureau et en allant taper dans le miroir interne), et je me souviens pas avoir eu de souci notable à cause de ça, donc je ne pense pas que CS9 dans la phase avant la release de RHEL soit fondamentalement cassé.
Et si les gens pensent qu'il n'y a qu'un seul flux de la distro pour 8 et 9, je comprends mieux pourquoi tout le monde s'affole. J'imagine que le site web pourrait être plus clair à ce sujet.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 5.
Image en partie poussé aussi par les concurents. J'ai vu assez de commerciaux pour savoir qu'ils ont aucun scrupule à ce niveau la.
Centos n'avait pas de support avant (au sens support téléphonique, tout comme au sens recevoir des bugs), donc au final, si le client découvre qu'il n'avait personne à appeler, ç'est tant mieux.
C'est un peu du bullshit comme raisonnement, vu que personne ne va mettre des Linux Mint en prod parce que c'est après Ubuntu qui est après Debian.
Si RH voulait se débarrasser de Centos, il suffisait d'attendre.
Tout les clones ont fini par s’arrêter d'eux même, et Centos elle même n'était super vivace vers 2011-2013, avec une gouvernance non transparente, etc.
Par exemple, il y a eu un délai de 6 à 7 mois entre RHEL et Centos pour les versions 6.0 et 6.1 (à comparer avec le mois pour Centos 5.0 et 5.1).
En pratique, je pense que ce que Centos a fait, c'est surtout décimer les distros concurrentes de RHEL. Vu que personne n'a les moyens d'attaquer RHEL par le haut en fournissant un produit plus prestigieux et de meilleur qualité, le seul moyen de concurrencer c'est en étant moins cher ou différent.
Sauf que faire moins cher que Centos, c’est quand même tendu.
Et faire différent, c'est pas évident non plus. Oracle a tenté, ils ont pas réussi.
Donc RH avait tout à gagner à garder Centos en vie.
Et RH a encore plus à gagner à avoir des clones actifs vu que les dits clones ont réussi à faire ce que Centos n'a jamais pu faire par design, à savoir rassembler une communauté de contributeurs. Et vu que le workflow de stream est ouvert, c'est beaucoup plus naturelle d'aller collaborer sur Stream pour Almalinux et co que de partir dans leur coin.
Je dit par design car le mot d'ordre de Centos, ça a toujours été "pour les changements, c'est bugzilla.redhat.com".
Ensuite, je comprends que pour la frange de la communauté qui veut des trucs gratos, ça semble faire chier. Mais c'est sans doute la même frange qui a du paniquer avec log4j partout.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 3.
Vers Stream
Alors vu mon employeur, le mandat de mon équipe et surtout la taille du parc et de l'équipe que je soit un bon exemple.
Mais je pense aussi qu'appeler Centos 8 une "rolling release", c'est comme dire qu'un avion est une automobile parce que ça peut se déplacer sur une route.
Centos 8 a des tests de QA automatisé, une promesse de compatibilité binaire via RHEL, et une politique de ne pas mettre à jour de façon disruptive. C'est ni Rawhide, ni Debian Unstable ou les devs vont mettre à jour sur la derniére version d'upstream, dont le but est de preparer la prochaine stable, etc.
Centos 8 stream est déjà stable (au sens figé), et la seule différence avec avant, c'est d'avoir les mises à jours de sécurité et de bugfix au fil de l'eau, donc de ne pas attendre que RHEL fasse une release, ce qui est pour moi un bonus.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie. Et vu que Centos n'a pas de support pour les versions mineurs autre que la dernière, tu es quand même obligé de mettre à jour pour la sécurité. Prendre une version mineur et appliquer les correctifs 1 par 1, c'est ni supporté, ni supportable, vu que tout est construit en visant les derniers RPMs. Ça marche sans doute plus parce que les paquets ont des modifs minimums plus que par un design particulier de la distro.
Ensuite, la ou je peux imaginer qu'une rolling release importen, c'est ce qui est hors de la distribution. Par exemple, le kernel ne garanti pas son ABI (même dans les LTS, etc), donc les gens qui dépendent de drivers externes ont sans doute peur de soucis (souci qui existe deja de base avec une mise à jour de sécurité avant, vu que l'ABI est toujours non garanti).
De même, Centos ne va tester que la distribution, si un produit proprio externe dépend d'un truc non documenté, ça peut casser. Mais pareil, ça aurait fini par casser à tout moment lors d'une mise à jour de sécurité.
Donc moi, j'ai ni l'un, ni l'autre, donc quand on m'a dit "tu vpeux avoir des bugfixes plus vite, et faire des PR plutot que d'aller faire chier les products managers/owners", j'ai dit "banco".
[^] # Re: Le Dune de D. Villeneuve est magnifique ...
Posté par Misc (site web personnel) . En réponse au sondage Mon adaptation de Dune préférée. Évalué à 4. Dernière modification le 14 janvier 2022 à 12:40.
Ça serait une vision assez rétrograde et conservatrice, vu que ça va continuer à positionner les personnes LGBT comme étant le résultat de la science fiction, ce qui va conforter à pas cher les dogmes de la société.
Mais vu que le héros principal hérite le pouvoir (eg, comme les rois d'antan), et que ses capacités sont aussi le résultat de la sélection par des alliances, etc, l'univers entier (dans le film) se lit facilement via un prisme essentialiste et naturalisant. Et ça, c'est sans rajouter le thème de la libération des Fremen grâce à Leto qui reste quand même la pour coloniser la planète au départ, qui va quand même pas mal conforter les gens dans l'idée que les sauvages peuvent pas se libérer eux même.
Donc je ne serais en effet pas surpris de voir ce genre de choses, vu que ça va faire s'agiter les franges les plus conservatrices pour de la pub à peu de frais.
Le seul point bloquant, c'est l'impossibilité de retirer ça aux montages pour les marchés comme la Russie, la Chine, les émirats arabes unis, etc.
Quelque chose qui serait vraiment disruptif, ça ne serait pas d'inventer une technologie sorti du chapeau qui ne fait que renforcer le status quo via un tour de passe passe, mais de mettre plus en avant des structures sociales différentes plutôt que la question de la fécondation.
Mais vu l'importance de la génétique dans l’œuvre originale, ça ne va pas arriver.
Et pour le moment, je ne crois pas avoir vu d'adaptations prévues des œuvres de la même époque, œuvres qui seraient plus disruptives à ce niveau comme The Left Hand of Darkness ou The Moon is a Harsh Mistress, toute les 2 sorties en même temps que Dune.
[^] # Re: Denis Villeneuve
Posté par Misc (site web personnel) . En réponse au sondage Mon adaptation de Dune préférée. Évalué à 2. Dernière modification le 14 janvier 2022 à 11:57.
Ça, et malgré le fait que le film soit long, il y a quelques explications qui manquent (genre, toute la question de pourquoi il n'y a pas d'IA et des mentats, etc).
Ensuite, j'ai bien aimé le film, et je n'ai pas de souvenir précis de celui de David Lynch (mais je me souviens de Mulholland Drive et Twin Peaks, donc y a peut être une raison pour l'absence).
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 6.
Y a aussi Centos Stream.
Mon chef voulait qu'on fasse un article de blog sur notre expérience de la migration, mais vu que y a 2 commandes donné dans la FAQ et le reste marche pareil, on a pas réussi à trouver de quoi faire un article intéressant (genre, même pas "on a pu rajouter un correctif de bug" vu qu'on a pas eu de bugs).
Je vois vraiment pas trop pourquoi partir sur les dérivés qui vont avoir les mêmes paquets, mais avec au mieux, un délai dans les correctifs de bugs, au pire, un différentiel sans la majorité des devs pour s'en occuper.
[^] # Re: Je pense qu'ils on vieillit :)
Posté par Misc (site web personnel) . En réponse au journal Quand les entreprises ne reversent rien aux logiciels libres. Évalué à 6.
Je pense que la question n'est pas qu'on vieillit, mais plus qu'on se retrouve le cul coincé entre 2 chaises.
On fait du libre aussi par désir d'aider d'autres personnes (en partie), et donc ça va attirer des personnes qui veulent aider les autres. C'est une dynamique positive pour la communauté que d'essayer d'attirer des gens "utiles" et pas des gens qui vont envoyer chier les autres.
Il suffit de voir par exemple les réactions quand une fonctionnalité est retiré (cf les débats sur systemd, GNOME, firefox, etc).
Du coup, comme on récompense (au sens ou on va plus aimer recevoir de l'aide que de ne pas en recevoir), et que le libre auto-sélectionne des gens altruistes, on se retrouve avec une dynamique ou certains se sentent forcés d'être altruiste, même quand ç'est mauvais pour eux long terme.
Au final, c'est pas tant de l'argent pour lui qui manque que de l'argent pour que quelqu'un d'autre fasse une partie du travail. Avoir de l'argent pour lui ne va faire que l'occuper plus, mais la limite fondamental d'avoir 24h par jour est toujours la, et l'impact sur sa santé mentale aussi.
[^] # Re: Bug report
Posté par Misc (site web personnel) . En réponse au lien Firefox en panne. Évalué à 3.
Si l’hypothèse d'une mise à jour d'un service externe (que ça soit Cloudflare ou le répartiteur de charge proposé par GCP) est vérifié, alors ça aurait fini par bloquer quelqu'un d'autre de toute façon, car d'autres personnes utilisent ces services.
[^] # Re: Bug report
Posté par Misc (site web personnel) . En réponse au lien Firefox en panne. Évalué à 4.
Ceci dit, ça aurait pu arriver aussi sur n'importe quoi d'autre, genre l'outil qui vérifie les malwares, le système d'OCSP, ou les mises à jours de plugin.
[^] # Re: publi-information
Posté par Misc (site web personnel) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 4.
Ou parce qu'il y a moins de désinformation, car il y a moins de thunes à se faire.
[^] # Re: publi-information
Posté par Misc (site web personnel) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 3.
Alors, j'ai un lien pour toi.
Je sais pas si ça a marché.
# Doublon avec la semaine dernière
Posté par Misc (site web personnel) . En réponse au lien Effet boomerang : quand les DRM sur cartouches d’impression se cognent la pénurie de composants. Évalué à 5.
Il y a déjà eu un journal (je dit ça juste par acquis de conscience, j'ai rien contre les doublons) :
https://linuxfr.org/users/colargol/liens/histoire-de-noel-canon-les-penuries-et-les-drm
[^] # Re: publi-information
Posté par Misc (site web personnel) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 2.
Je pense que la 5G dans le sang, c'est pas très dry january friendly.
Encore une manœuvre des lobbys de l'alcool.
[^] # Re: Le train pour Pau
Posté par Misc (site web personnel) . En réponse au lien Carte des gares accessibles sans correspondance. Évalué à 4.
Non, de Paris.
Dans les années 90, il y avait un train pour Pau, en partant de Gare d'Austerlitz à 13h20, avec un changement à Strasbourg.
# Le train pour Pau
Posté par Misc (site web personnel) . En réponse au lien Carte des gares accessibles sans correspondance. Évalué à 4.
C'est marrant, je regarde les trains pour Pau, et maintenant, il y a un direct, ça fait longtemps que la ligne ne passe plus par Strasbourg ?
[^] # Re: Bourdel
Posté par Misc (site web personnel) . En réponse au lien Linux Mint signe un partenariat avec Mozilla et utilise les paramètres par défaut de Firefox. Évalué à 2.
L’écosystème change, les moyens aussi. Soit il y a eu moins de moyen (moins de sponsoring, inflation, etc), soit les ressources (eg, le temps d'ingé) sont vu comme plus utile ailleurs.
[^] # Re: Bourdel
Posté par Misc (site web personnel) . En réponse au lien Linux Mint signe un partenariat avec Mozilla et utilise les paramètres par défaut de Firefox. Évalué à 6.
Ensuite, maintenir des patchs, ça prends du temps (donc c'est de l'argent). Et Mint, dans mon souvenir, c'etait pas franchement les champions d'envoyer les trucs upstream.
Du coup, bah, Mint gagne du temps à ne plus patché le navigateur, et gagne sans doute de l'argent si Mozilla partage l'argent avec eux.
Je pige pas trop pourquoi baver sur Mozilla à ce niveau.
[^] # Re: cas d'utilisation ?
Posté par Misc (site web personnel) . En réponse au lien XMPP: un pont Jabber - SMS. Évalué à 2.
J'imagine que si tu es à l'étranger avec une carte sim local, tu peux avoir intérêt à envoyer un sms en local plutôt qu'un sms vers l'étranger.
Mais oui, je suis d'accord avec toi, j'ai un forfait qui couvre les endroits ou je vais (càd chez moi, et à la ville d'à coté en ce moment :( )
# Mhh
Posté par Misc (site web personnel) . En réponse au lien [Attention, NSFW] témoignage d'un soignant en reconversion. Évalué à 1. Dernière modification le 10 janvier 2022 à 23:00.
Alors, je dit pas que c'est faux (j'ai vu les temps d'attentes aux urgences avant la crise, je suppose que ça n'a pu que grimper), mais je pense qu'un article anonyme sur une plateforme de blog, c'est un chouia louche sur le principe, et que ça mérite de prendre ça avec un peu de précaution.
Si l'article était à l'opposé ("je suis urgentiste, tout les gens souffrent d'avoir Twitter directement dans le cerveau grace à la 5G du vaccin"), je pense qu'on pointerais la non crédibilité du à la plateforme de la même façon. Donc je pense que c'est important d'avoir à minima la même rigueur même quand on est d'accord avec la narration de l'article.
[^] # Re: Spoiler alert
Posté par Misc (site web personnel) . En réponse au lien Ce tableau montre combien l’aération change tout contre Omicron - numerama. Évalué à 5.
Je crois que le terme utilisé de nos jours est "assureur".
[^] # Re: ARN vs inactivés
Posté par Misc (site web personnel) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 3.
Le reportage a l'air intéressant, et va dans mon sens sur l'hypothèse sur la route de la soie.
Ceci dit, ça dit au début que la Russie n'a pas réussi à livrer ce qu'elle a promis, et me rappelle aussi la campagne de piratages fin 2020 sur les labos.
[^] # Re: Encore merci ...
Posté par Misc (site web personnel) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 1.
C'est discutable. Si tu prends par exemple Bitcoin, c'est de la cryptographie (donc des maths) et de l'informatique (donc des maths).
Mais on peut argumenter que le but du logiciel et du papier à son origine était sans doute loin d'être apolitique.
Donc dans certains cas, la politique va influencer ce que tu recherches, et donc le résultat.
Ensuite, oui, c'est beaucoup plus dur quand les recherches sont éloignés du monde matériel.