Misc a écrit 6286 commentaires

ça peut aussi être un bug que personne n'a vu avant car contourner par les IDE classiques qui font l'icone automatiquement, etc.

Dans tout les cas, ça fait parti du jeu, les devs testent dans certains cas, le code est publié et utilisé, et on s’aperçoit qu'un truc manque, qu'une supposition n'est pas connu de tout le monde.

Je pense vraiment qu'on a tendance à oublier qu'il y a des humains qui font le logiciel et qu'ils font parfois des erreurs.

Bref. Le rapport de force dans les divers métiers ne dépend
pas que de l'offre et la demande, mais aussi de la formation
de chaque partie à défendre son bout de gras. Ou de la bonne
volonté des deux parties à trouver un contrat mutuellement
profitable (ça arrive aussi même si c'est plus rare).

Mais j'ai le sentiment que les salariés dans la tech sont pas trop organisés non plus, voir un peu hostile.

Et le gouffre entre les 2 secteurs est quand même assez énorme (genre, j'ai regardé, je pense que je gagne plus qu'un restaurateur moyen, sans prendre en compte mes primes et mes stock options, et sans prendre en compte ses éventuelles dettes).

Mais peut être qu'il faut regarder un secteur avec un rapport de force plus égalitaire pour comparer. Il n'y a pas vraiment de secteur industrielle qui me vient à l'esprit. Par contre, si je regarde au niveau d'un type de profession, commercial me parait être un bon exemple. Vu que le travail d'un commercial, c'est de négocier des transactions financières et vu qu'il a une vision direct sur ce qui rentre, je pense qu'ils sont bien mieux placés pour négocier leur salaire, et ça se voit sur les rémunérations.

À contrario, les RHs et les comptables, c'est pas le même niveau, donc l'info uniquement ne suffit pas.

Est-ce que vraiment ça ne marche pas ? Qu'est-ce que le
secteur du développement a (pour que ça marche) que n'a pas
celui de la restauration (pour que ça n'y marche pas) ?

Alors je suis pas spécialiste, mais je dirais avant tout une décorrélation entre le travail fait et l'argent gagné de part la structure respective des 2 secteurs.

Quand tu es restaurateur, tu sais combien tu gagnes, et combien 1 personne va te coûter. À vue de nez, les restaurants vont avoir une poignée d'employés, et ce sont des entreprises avec des marges assez petites, avec un patron qui est en général assez impliqué dans l'entreprise vu qu'il y travaille.

Tout le secteur est comme ton restaurant, donc c'est uniforme.

Dans le développement, une part non négligeable du secteur bosse dans une entreprise beaucoup plus grande qu'un restaurant moyen, et c'est donc plus compliqué de savoir exactement combien rapporte une personne. Et contrairement à un restaurant, les clients n'ont pas la moindre idée du coût du produit (eg, le logiciel), et ne dépense pas leur argent, donc les marges peuvent être plus grande.

À partir du moment ou un commercial qui vends le logiciel peut avoir du 10% à 50% de marge de négociation avec le client, l'apport individuelle des devs à la rentrée d'argent est quand même difficile à quantifier exactement.

Donc comme c'est dur à estimer pour toi, c'est sans doute dur à estimer pour tout le reste de l'organisation. L'entreprise sait combien elle peut payer (elle a les comptes), elle sait combien paye le reste du marché (et en général, l'employé non). Mais en plus de ça, personne n'est fonciérement en train de dépenser son argent, et les entreprises sont pas forcément rentables au même niveau.

Donc tu as d'un coté des petites boites avec un marché grosso modo figé, parce que la rentabilité d'un resto, c'est quand même un truc qui n'a pas trop changé depuis longtemps.

En face, le secteur de la tech ou c'est n'importe quoi et des entreprises avec l'imprimante à billet vont embaucher du monde rien que pour le culte de la croissance et qui vont aussi impacter tout le secteur. Un marché ou tu payes un prix pour un logiciel mais pas basé sur combien ça coûte de le faire, mais combien ça t'économise, d’après les estimations du fabricant.

Alors firefox le fait déjà via nightly, et visiblement, ça n'a pas suffit.

Et je pense que Google et Cloudflare le font aussi.

Donc c'est sans doute plus la faute à pas de chance.

Sauf que faire payer les fonctionnalités, ça a un coté pervers de ne pas payer pour la maintenance.

Ça a aussi l'effet pervers de pousser à mettre des fonctionnalités qui vont pas forcément avoir du sens.

C'est dans la version 1 de la FAQ qui date de mars 2020.

C'est aussi dans la version de septembre 2020 sur archive.org, pour le cas ou il y a des doutes sur un éventuelle caviardage de l'historique du wiki.

Je rappelle aussi que l'annonce du changement de Centos 8 vers Stream date de décembre 2020, soit 9 mois après la première FAQ.

Donc à moins de supposer l'usage d'un ordinateur quantique pour voyager dans le temps (on a déjà la technologie pour dilater le temps par l'usage de slides en police taille 7, donc le reste est faisable) ou d'un complot qui implique tout le monde sauf les utilisateurs Centos, je pense pouvoir dire que c'est pas un retro pédalage.

Et ensuite, des no-no-codeurs (un cadeau d'Ulysse)

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?

On a rien mis de plus, on sait lire une FAQ.

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.

Centos Stream n'est pas Centos 8 Stream.

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.

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).

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.

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.

Bref, les espagnols (à cause de leur système de santé, pas en
si bon état que le notre ?), sont beaucoup plus vigilants.

Ou parce qu'il y a moins de désinformation, car il y a moins de thunes à se faire.

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 !

Alors, j'ai un lien pour toi.

Je sais pas si ça a marché.

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

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.

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.

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 ?