et ça, c'est sans rentrer dans les détails de ce qui est couvert exactement. Par exemple, Ubuntu mets à jour le kernel pour réduire les couts, ce qui va sans doute casser la compatibilité de l'ABI interne du kernel, ce qui est pas forcément super pour des drivers en dehors du dit kernel.
Dans mon souvenir (d'il y a longtemps), le CERN va parfois refaire des drivers de cartes réseaux pour les perfs, donc je peux comprendre qu'ils ont pas envie de faire du portage tout les 2/3 ans.
Il y a 3 RHEL, 3 Centos, 1 Ubuntu, 1 dérivé d'Ubuntu, 1 OS custom et 1 cray linux.
Si on pousse dans les 25 premiers, on retrouve de la RHEl, de la SLES, du craylinux, et "linux". De ce que j'ai vu, il y a 0 debian dans les 25 premiers (ou alors, pas sous le nom Debian).
Ça veut pas dire que Debian n'est pas valable, mais clairement, il n'y a pas que le CERN qui fait le choix de prendre RHEL ou une dérivée.
Personnellement, j'ai toujours eu l'impression qu'ils
mettaient beaucoup d'énergie à suivre RHEL et que celle-ci
aurait pu être mieux utilisé… Et les noyaux sous Debian /
RHEL… peuvent être les mêmes. À vrai dire, le code dérive des
mêmes dépôts. Mais bon, tout cela est une impression
personnelle.
Dire que le code dérive des mêmes dépots, c'est une grosse simplification.
Le code, ça se teste, ça se corrige, et ça, ça coûte des ressources. Je ne sais pas combien de personnes il y a sur ça au CERN, mais Scientific Linux, c'était 2 personnes à temps plein pour faire un dérivé de Centos, il n'y a pas non plus de quoi faire des miracles avec ça, même si ça donne une distro séparé.
Je pense que fondamentalement, il n'y avait aucun bon moment.
Le fait juste au moment de la release de RHEL/Centos 8, ça aurait sans doute fait grincer des dents autant. Le faire 1 ou 2 ans avant Centos 8, en dehors d'impliquer de voyager dans le temps, aurait aussi été vu comme une trahison. Et le faire aujourd'hui pour RHEL 9 aurait été pareil que le faire pour EL 8.
La raison donné pour le faire au moment ou ça a été annoncé, c'est parce que justement, la majorité des admins sys (comme vu par la charge sur les miroirs) n'étaient pas encore passé à EL 8.
Donc en fait, le mieux est d’avoir un juste milieu entre
stabilité et nouveauté, et dans ce cas CentOS Stream 8 a du
sens.
Mais CS8 va avoir les mêmes mises à jours que RHEL (et donc que l'ancienne Centos avant), donc l'aspect "nouveauté" est quand même assez réduit.
La raison pour Facebook d'avoir pris Stream est justement pour pouvoir envoyer des correctifs, chose qui était difficile avant (un mec de Facebook a fait un talk sur le sujet y a quelque années, et il a donné des détails dans un bar après la présentation, genre tout ce qui concerne IP v6 sur Centos 7, vu que Centos a dit "faut voir RH", et RH a dit "nous allons donner la plus grande consideration à votre demande mais pour le moment lol nope" avant que les gens de facebook aillent boire des bieres avec les bonnes personnes)
Les réactions vis à vis de CS8 m'ont fait prendre conscience qu'il y a beaucoup plus d'admins qui n'ont pas l'air d'avoir une idée claire sur le fonctionnement d'une distrib linux que je le pensais. Par fonctionnement, je parle de comment le logiciel passe de "un tarball" à "mon serveur en prod". Si il n'y a que des correctifs de bugs, qu'il y a un CI importante, et un contrôle de ce qui est mis en place ou pas, CS8 devrait n’être que RHEL avec 2 à 3 mois d'avance, et donc meilleure pour les admins (vu qu'il n'y a plus à attendre pour les bugfixes mineurs, voir que les admins peuvent y contribuer en envoyant le correctif)
À la place, j'ai le sentiment qu'il y a plus quelque chose qui ressemble à une envie d'avoir RHEL sans en avoir le budget pour, et qu'il y a une forme de rancune.
Sans doute parce que Debian ne réponds pas aux besoins du CERN.
Par exemple, acheter des clusters de matos et avoir une assurance assez forte que ça va marcher parce que tu as les mêmes patchs que la version RHEL qui est certifié.
Ou avoir un cycle de vie logiciel prévisible et un peu plus long que 2/3 ans.
Mais on peut difficilement augmenter la résolution d'un écran via le logiciel, on utilise déjà du logiciel pour les appareils photos, mais à un moment pour faire mieux, il faut plus de pixels.
Les communications radios, malgré les progrès dans le domaine des SDR, ont sans doute encore des besoins assez stricts en terme de latence, donc on peut pas facilement changer les protocoles. On commence à avoir des trucs avec des FPGA pas cher, donc ça va sans doute arriver.
Je pense qu'on peut discuter de savoir si le matériel d'il y a 10 ans serait capable de faire assez bien pour l'usage qu'on en a, bien sur.
Je peux donner l'exemple de la Nintendo Switch. La console a un CPU 4 coeurs cortex A57 à 1Ghz, 4G de ram. En face, la Xbox One X a 12G de ram et 8 coeurs AMD à 2.3 Ghz, si j'en crois Wikipedia.
Les jeux sont sans doute plus beaux sur X Box. Mais ça reste la Switch qui se vends le mieux, en partie que Nintendo n'a pas tenté de faire la course au graphisme et au photo réalisme contrairement à ses concurrents (Sony et Microsoft), et que finalement, un CPU moins rapide et moins de ram suffisent à faire des jeux plus que corrects.
Ensuite, c'est un mauvais exemple car il y a plein de soucis dans le modèle des consoles (par exemple, changer les manettes pour innover).
Mais prenons par exemple le développement logiciel. On a de nos jours des super systèmes de CI/CD, parce que c'est pas aussi cher qu'avant de compiler parce qu'on a changer le matériel. Je me souviens du cluster de 5 machines bi-proc (ou quadri-proc) chez Mandrakesoft pour compiler le rpm d'Openoffice en 6h. Et le cluster était la pour tout les paquets, donc monopoliser les ressources, c'était pas sans effet de bord.
De ce que je sais, les soignants/médecins/professionnels de santé peuvent signer sans avoir à vérifier les papiers. D'une part parce que seul les flics peuvent imposer de demander ça, parce que les erreurs arrivent, et parce que les sans papiers existent.
Mais bon, ça fait moins de vues que "la sécurité du passe sanitaire est compromise".
Ensuite, si les gens veulent plus de sécurité sur le passe sanitaire, y a sans doute moyen de rajouter plus de surveillance bien sur, mais je suis pas sur que ça soit une bonne chose.
qu'ils doivent rembourser d'ici 2068, heureusement à 0%
d'intérêts.
2068, soit sans doute 20 ans après la retraite de Moxie Marlinspike, et quand Brian Acton aura 95 ans, si il est en vie (et que la planète n'a pas brulé). Je pense que d'ici la, les choses auront changer.
Je pense que tu as raison sur le fond, mais je pense que le prêt, c'est juste un don déguisé pour éviter les impots.
La fortune de Brian Acton est estimé à 2.5 milliards. 50 millions (car le dont a été fait en 2 fois), c'est à peine l'argent que lui rapporterais un livret A sur 1 an (pour donner un ordre de grandeur). Et je suppose qu'il a sans doute des trucs plus rentable que ça.
C'est là que le projet P2P peut faire la différence, me semble
t-il ?
Je suis pas vraiment sur. Déjà, vu que les ressources alloués sur le P2P, c'est 1 personne qui bosse aussi sur Dendrite, j'ai des doutes (quand tu as moins d'un temps plein, c'est pas vraiment une priorité). Ensuite, Pinecone semble être le choix fait aprés avoir testé des choses avec yggdrasil, donc j'ai le sentiment que c'est encore pas mal dans l'experimental, et qu'il va falloir encore un peu de temps avant de voir si ça marche (parce que des réseaux mesh, y en a eu des tonnes depuis des années).
Je ne doute pas que ça arrive, mais encore une fois, faudrait sans doute plus qu'un temps partiel dessus.
Certes ce n'est pas encore fini, mais à en croire les
mises à jour hebdo sur le blog de Matrix, j'ai l'impression que
ça avance plutôt bien ?
Je me méfie un peu, j'ai le sentiment qu'il y a un effet FOSDEM. Quand le FOSDEM arrive, il y a toujours un demo d'un truc et un peu de hype, qui est préparé avant, mais ça se concrétise pas après. Par exemple, y a un blog post complet sur Cerulean, et y a plus rien depuis.
Si j'en crois les articles d'il y a un an, l'usage en P2P dépend d'une MSC proposé en 2018 qui a été remplacé ou dépend d'une MSC proposé en 2020. Bien sur, on pourrais avoir matrix en p2p en perdant le fait d'avoir plusieurs clients, mais il serait assez ironique de revenir à des limitations d'IRC sous guise de progrés.
Et naturellement, comme avec XMPP, devoir faire choisir un
serveur à ses potes est une barrière à l'entrée.
Oui, et ça va être impossible à résoudre sauf à avoir un monopole d'une façon ou d'une autre. C'est comme XMPP, les gens ralent parce qu'il faut choisir un client, mais je suis sur qu'interdire les clients alternatifs seraient pire.
Alors d'un coté, tout les protocoles d'échanges sont comme ça. SMTP, XMPP, etc.
Plus ton service héberge du monde, moins ça te coûte, vu que le trafic va rester en local, que 2 personnes sur le même serveur vont partager le stockage, que tu va mutualiser les coûts.
De l'autre, la différence entre Matrix (avec un état partagé), et SMTP/XMPP (passage de message), c'est que tes coûts au sens générique n'augmente pas de la même façon.
Dans le cas de SMTP/XMPP, ça va grimper avec ton nombre d'utilisateurs et ton usage. Si j'utilise peu, je n'ai que les coûts fixes. Si je suis sur un serveur MUC XMPP avec 1000 personnes de 1000 serveurs, l’hébergeur du salon a des coûts plus élevés que moi, mais moi, ça va. Si je suis sur une liste de diffusion avec 1000 personnes, l’hébergeur de la liste a des coûts, mais moi, ça va.
Donc ton serveur XMPP/SMTP est utilisé comme "client" vis à vis du service de distribution de messages proposé par le serveur en face (salon muc, liste de discussion), qui agit comme "fournisseur de service". Le fournisseur de serivce prends plus de ressources, car il fait plus, et tout le monde le comprends.
Dans le cas de Matrix, c'est la diversité et la croissance du réseau qui prime. Si tu va sur un salon avec 1000 personnes de 1000 serveurs différents, tu va douiller, que tu l'utilises beaucoup ou pas. Et plus le réseau grandit parce qu'il se décentralise, plus ça coûte à tout le monde. Chaque personne qui rejoint @tartampion:example.org va faire consommer des ressources chez tout les autres (vu que tout le monde va le contacter tout le temps).
Un fonctionnement ou le serveur matrix ne stocke rien en local, renvoie des données vides quand on demande et se contente d'aller voir chez les autres via l'api de backfill serait faisable (et sans doute moins coûteuse), mais fondamentalement inégalitaire (vu que d'un coup, tu va avoir des serveurs qui vont devoir payer le coût des APIs de backfill et de stockage pour une part substantiel de tout le réseau).
Si il y a le choix entre dire "je prends pas de ressources, mais je bénéficie du réseau" et "je prends des ressources, et j'ai autant de bénéfice", je suis pas sur que les incitations soient bien pensés. Mais l'état actuelle implique que tout le monde consomme plus de ressources quand la diversité du réseau augmente (ou du moins, la partie du réseau ou on participe, si le réseau triple mais que je parle à 3 personnes, ça va rien changer pour moi).
Ça me parait assez paradoxale, et en effet, je pense qu'à un moment, ça va entrainer une recentralisation chez le même fournisseur (ce qu'on voit déjà arriver en fait, vu que tout le monde héberge les choses chez New Vector/Element, vu que GNOME, KDE, Fedora, Ansible et Mozilla sont chez eux).
Est-ce que s’ils passaient leur tarif de 5$ à 1$ par mois comme
tu proposes, ils feraient 5 fois plus de clients ? Probablement
pas. Et quand bien même, ça ferait plus de frais en support et
en bande passante. Donc il faudrait au moins faire 6 fois plus
de clients.
Donc l'offre Element One à 5$, c'est l'offre à 3$ avec 3 bridge à 0.5$ en plus, sans un DNS custom.
Vu que le prix de la ram chez AWS, c'est grosso modo 6$ pour 1G (t4.nano), on peut supposer que pour 0.5$, tu as 80 mega de ram. Sur mon téléphone, whatsapp pour parler à grosso modo 2 personnes et 1 groupe utilise 81 Mo. Signal consomme 219 Mo.
J'imagine que les bridges vont pas prendre moins ou plus que les clients natifs (vu que le bridge matrix/whatsapp est en Go, le bridge matrix/signal est en python et en java et utilise un bout de postgresql), ça semble être une offre à prix coutant, voir presque à perte (parce qu'il faut payer des taxes, la facturation, etc).
C'est noble de la part de l'équipe, mais je pense que c'est pas forcément tenable sur le long terme.
Signal a été recommandé par Edward Snowden, et l'est encore
par les activistes de la vie privée à chaque fois qu'un GAFA
fait une connerie.
Signal est aussi financé par le fondateur de Whatsapp après le rachat par Facebook, et l'idée de Signal vient aussi des projets d'OpenWhisper, ou y a bien eu quelques années de R&D financée par une boite privé et du proprio et sans doute du capital risque, puis par Twitter aprés le rachat.
Parce qu'un autre truc qu'on oublie aussi, c'est qu'une messagerie pour des centaines de millions de personnes, ç'est assez coûteux en infra à un moment.
Je renvoie en toute modestie à la discussion sur Discord que j'ai vaguement lancé, notament la discussion sur combien de CHATONS on a besoin pour remplacer discord en France.
C’est précisément parce que xmpp n’a pas été capable de se
federer derrière un produit viable que Facebook et consorts ont
raflés le jackpot.
Je pense plus simplement parce que Facebook avait les utilisateurs et beaucoup plus de moyens.
Faut pas chercher midi à quartoze heures, facebook, c'est plus de 35 000 employés en 2018. C'est presque 20 fois la population active de Linuxfr sur les 3 derniers mois. Donc on peut supposer que c'est en effet plus facile pour eux de faire un client de messagerie quand ils ont l'infra en place, les devs, et pas spécialement besoin de chercher à en vivre.
Prosody, c'est sans doute moins de 5 volontaires tout comme Gajim ou Conversation. Une boite comme ProcessOne (qui fait ejabberd), ça a l'air tout petit (6 personnes visibles dans l'org github, < 10 sur societe.com).
Même whatsapp avait plus de moyens que l'écosystème XMPP, vu que c'etait une startup de 50 personnes à l'époque du rachat par Facebook, et sans doute plus depuis, et sans doute aussi 50 par la magie du financement (financement qui reste un souci récurrent du libre).
Du coup, oui, les gros acteurs raflent le jackpot. Matrix marche aussi parce qu'ils ont assez vite proposé d'avoir un Patreon, parce qu'ils ont eu des investisseurs et parce que ça a commencé par une boite de telco.
C'est le pognon qui fait que ça, pas les questions de fragmentation. En fait, la fragmentation est la parce qu'il y a pas de pognon pour réduire la fragmentation en premier lieu.
Et aussi parce que Whatsapp/FB MEssenger, etc ne cherche pas à réduire la fragmentation, vu qu'il y en a pas pour eux (walled garden, etc). Forcer tout le monde sur gajim et prosody, ça marcherais aussi pour réduire la fragmentation. Mais ça va pas plaire.
Du coup, si je comprends bien, EMS se positionne comme une offre moins cher que Beeper tout en reprenant le code de Beeper alors que Beeper utilise le code de Synapse et co (et donc se positionne comme une offre plus cher que EMS ).
Je sais pas trop quoi en penser, mais se mettre en concurrence au lieu de se mettre en coopération, ça me parait pas terrible pour l'écosystème.
À un moment, en voyant l'animosité autour de Matrix sur Hacker News (dans certains commentaires des news, mais aussi plusieurs comparaisons avec XMPP assez à charge sur Matrix, avec l'un des fondateurs qui se jette dans l'arène), je me suis demandé pourquoi la vibe était différente de mes souvenirs de l'époque d'XMPP.
Il y avait des débats sans doute (notamment sur linuxfr) donc je ne pense pas que ça soit nouveau. Et clairement, on était pas à l'époque à bout de souffle à cause de l'état du monde comme maintenant (entre la pandémie, le climat, la montée de l’extrême droite et la sortie de Windows 11), donc ça joue aussi.
Mais je ne me souviens pas de choses qui avaient l'air aussi virulente, et les discussions que j'ai vu date d'avant le début de la pandémie (genre en 2019). Du coup, je pense qu'il y a autre chose.
Par exemple, si je prends ce papier, il est extrêmement à charge vis à vis de Matrix, pour finalement des choses ou en pratique, je pense que tout le monde s'en fout (et qu'on peut pardonner). Perso, je m'attends pas à ce qu'une petite boite comme Matrix se retrouve avec une communication parfaite. Rédiger tout un article sur le sujet me parait assez disproportionné, et je me dit qu'il faut être vraiment motivé pour ça.
Et donc, peut être qu'au delà des débats techniques, il y a aussi des problématiques humaines non visibles.
Par exemple, le fait de sortir une offre concurrente de ce qui aurait pu être un partenaire (beeper), ça y contribue. Des remarques sur les serveurs publiques en "free for all" (cf la fin de mon commentaire ), ça y contribue.
Ensuite, peut être aussi que je me fait des idées, et qu'il y a rien.
Et pour répondre à la question de ploum : avec Matrix, ce qui
change c'est que ça marche, et que la promesse d'un protocole
aussi agréable à utiliser que Discord et décentralisé voire P2P
dans l'avenir, d'ores et déjà adopté par GNOME et Mozilla, est
la plus excitante dans le monde de l'internet dé-GAFAMisé
depuis très longtemps. À condition que la promesse soit tenue,
évidemment.
Mais Matrix marche parce qu'actuellement, il n'y a qu'un serveur viable qui bouge assez vite, pareil pour les clients. J'ai installé conduit, j'ai pas pu rentrer dans un certain nombre de salons car le support du protocole est incomplet. Dendrite était mieux à ce niveau, mais j'ai pas testé les fonctionnalités plus que ça, et avec 1/4 des ressources de synapse, je m'attends pas à un miracle (ni à ce que le retard disparaisse de si tôt).
Et la raison du succès de Matrix, c'est aussi le fait d'avoir un bouncer IRC gratuit plus que le protocole (et gratuit parce que sponsorisé par Element).
De plus, je pense que, fondamentalement, Matrix en temps que protocole souffre d'un probléme qui va apparaître à un moment ou à un autre. C'est un système distribué, le problème des généraux byzantins est forcement la (je peux le prouver, mais j'ai pas la place dans la marge pour ça).
Et tout comme XMPP et SMTP, tu va avoir les soucis de spam inhérent à l'ouverture d'une plateforme. Rien de ce que Matrix fait ou propose ne va être différent, et de ce que je sais, ce qui est utilisé, c'est une liste centralisé d'instance et de comptes qui pose probléme via mjolnir. C'est exactement ce qui était fait au début avec spamhaus et autre DNSBL pour le SMTP, ou sur XMPP, ou via le bot de modération irc de freenode d'il y a un bout de temps (je me souviens d'un compte assez persistant il y a 10 ans, et d'un bot irc géré par freenode).
On sait tous comment ça se passe pour le SMTP en auto hébergement à cause de ça, et d'ailleurs, Element le pointe à moitié dans l'article de blog: It's hosted by Element Matrix Services; constantly maintained to the highest standard and best practices by the experts who created Matrix - giving an infinitely better experience than the typical free-for-all of public homeservers.
Mhh, du coup, Whatsapp va voir plusieurs milliers de personnes venir d'une seul IP, avec tout le monde qui tourne dans le même émulateur, connecté en permanence et ne va pas trouver ça louche ?
Vous [...] ne devez en aucun cas, directement ou par des moyens automatisés : (f) collecter les coordonnées de nos utilisateurs ou des informations à leur sujet de manière inadmissible ou non autorisée ; (g) vendre, revendre, louer ou facturer nos Services ou des données obtenues auprès de nous ou de nos Services, d'une manière non autorisée ; (h) distribuer nos Services ou les mettre à disposition sur un réseau permettant de les utiliser sur plusieurs appareils à la fois, sauf autorisation par le biais d'outils que nous avons expressément fournis via nos Services ; (i) créer des logiciels ou des API qui fonctionnent essentiellement de la même façon que nos Services et les proposer à des tiers d'une manière non autorisée
Je suis pas juriste, mais si Element n'a pas de contrat avec Whatsapp, je pense que le service est une violation triviale des ToS.
Je peux connecter plusieurs appareils via Matrix (point H), c'est un service payant de location (point G), ça collecte des données (point F, addresse IP, etc) et le point I, bah, c'est le but du service.
C'est 5$ par utilisateur et par mois. Ton VPS peut sans doute permettre d'avoir plus qu'une personne (vu que la conso de synapse et co va être lié au nombre de salons total plus que le nombre de compte utilisateur).
Et vu la conso de ram de synapse (qui reste le plus efficace des 3 serveurs que j'ai testé),vu le coût d'avoir des clients et de facturation (frais banquaire, la compta, le support), je pige pas comment Element arrive à être rentable avec ce genre d'offre.
Je profite du débat pour poser une question aux défenseurs du
passe sanitaire : à partir de quelle couverture vaccinale la
balance avantages-inconvénients du passe devient-elle négative
? 75% ? 90% ? 100% ? 110% ?
Je suppose que tu parles pas du pass en lui même (parce que je pense que le systéme mis en place va être étendu pour d'autres vaccins, et pour l'international), mais de sa vérification dans ses modalités actuelles (plus ou moins actuelle, vu que le pass pour les grandes surfaces n'est plus requis depuis 2j mais tu as du le voir aussi dans ta boule de crystal).
Mais avant de chiffrer les inconvénients (ça fait chier les gens de faire du travail en plus, comme porter un masque), faut aussi pointer les avantages non pris en compte pour voir que ça dépend pas que de la couverture.
Primo, il y a le fait que le pass sanitaire a poussé à la vaccination par effet d'annonce. Mais l'effet d'annonce ne marche que parce que le pass a été mis en place, donc il faut le garder assez longtemps pour marquer durablement les esprits afin de pouvoir refaire ça pour une prochaine pandémie. Ensuite, bien sur, tout le monde va oublier assez vite si c'est trop court.
Ensuite, il y a le fait que le pass sanitaire a redonné de l'élan aux manifs populaires, et à donner de quoi discuter sur Linuxfr (en plus du télétravail).
Donc pour moi, il faut le garder jusqu'à avoir 30% de la population dans la rue, histoire de pimenter la campagne présidentielle.
Car si c'est pour voir encore une montée de l’extrême droite sur le thème de la sécurité (sujet dont on semble se foutre de plus en plus ), ça va, on ressort ça tout les 5 ans, et franchement, c'est même pas original, c'est juste une repompe des années 30.
Donc je pense que ta question ne prends pas en compte les vrais dimensions de la problématique.
[^] # Re: Fermilab & CERN, scientific linux
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 8. Dernière modification le 07 novembre 2021 à 22:28.
Pourtant:
https://www.redhat.com/en/about/press-releases/red-hat-powers-future-supercomputing-red-hat-enterprise-linux
Il y a sans doute des chiffres sur les déploiments d'openshift ou d'openstack mais j'ai rien trouvé de publique.
Mais si la version 3 d'openshift a été testé sur 2000 noeuds, ç'est sans doute parce que des clients ont demandés:
https://docs.openshift.com/container-platform/3.11/scaling_performance/cluster_maximums.html
Sauf que Ubuntu fait pas ça gratuitement non plus.
Ubuntu, c'est au max 10 ans si tu payes:
https://ubuntu.com/about/release-cycle
RHEL, c'est jusqu'à 13 ans si tu payes:
https://access.redhat.com/support/policy/updates/errata/
et ça, c'est sans rentrer dans les détails de ce qui est couvert exactement. Par exemple, Ubuntu mets à jour le kernel pour réduire les couts, ce qui va sans doute casser la compatibilité de l'ABI interne du kernel, ce qui est pas forcément super pour des drivers en dehors du dit kernel.
Dans mon souvenir (d'il y a longtemps), le CERN va parfois refaire des drivers de cartes réseaux pour les perfs, donc je peux comprendre qu'ils ont pas envie de faire du portage tout les 2/3 ans.
D'ailleurs, si on regarde le top 10 sur:
https://www.top500.org/lists/top500/list/2021/06/
Il y a 3 RHEL, 3 Centos, 1 Ubuntu, 1 dérivé d'Ubuntu, 1 OS custom et 1 cray linux.
Si on pousse dans les 25 premiers, on retrouve de la RHEl, de la SLES, du craylinux, et "linux". De ce que j'ai vu, il y a 0 debian dans les 25 premiers (ou alors, pas sous le nom Debian).
Ça veut pas dire que Debian n'est pas valable, mais clairement, il n'y a pas que le CERN qui fait le choix de prendre RHEL ou une dérivée.
Dire que le code dérive des mêmes dépots, c'est une grosse simplification.
Le code, ça se teste, ça se corrige, et ça, ça coûte des ressources. Je ne sais pas combien de personnes il y a sur ça au CERN, mais Scientific Linux, c'était 2 personnes à temps plein pour faire un dérivé de Centos, il n'y a pas non plus de quoi faire des miracles avec ça, même si ça donne une distro séparé.
[^] # Re: Utilisation en production
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 3.
Je pense que fondamentalement, il n'y avait aucun bon moment.
Le fait juste au moment de la release de RHEL/Centos 8, ça aurait sans doute fait grincer des dents autant. Le faire 1 ou 2 ans avant Centos 8, en dehors d'impliquer de voyager dans le temps, aurait aussi été vu comme une trahison. Et le faire aujourd'hui pour RHEL 9 aurait été pareil que le faire pour EL 8.
La raison donné pour le faire au moment ou ça a été annoncé, c'est parce que justement, la majorité des admins sys (comme vu par la charge sur les miroirs) n'étaient pas encore passé à EL 8.
[^] # Re: Utilisation en production
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 7.
Mais CS8 va avoir les mêmes mises à jours que RHEL (et donc que l'ancienne Centos avant), donc l'aspect "nouveauté" est quand même assez réduit.
La raison pour Facebook d'avoir pris Stream est justement pour pouvoir envoyer des correctifs, chose qui était difficile avant (un mec de Facebook a fait un talk sur le sujet y a quelque années, et il a donné des détails dans un bar après la présentation, genre tout ce qui concerne IP v6 sur Centos 7, vu que Centos a dit "faut voir RH", et RH a dit "nous allons donner la plus grande consideration à votre demande mais pour le moment lol nope" avant que les gens de facebook aillent boire des bieres avec les bonnes personnes)
Les réactions vis à vis de CS8 m'ont fait prendre conscience qu'il y a beaucoup plus d'admins qui n'ont pas l'air d'avoir une idée claire sur le fonctionnement d'une distrib linux que je le pensais. Par fonctionnement, je parle de comment le logiciel passe de "un tarball" à "mon serveur en prod". Si il n'y a que des correctifs de bugs, qu'il y a un CI importante, et un contrôle de ce qui est mis en place ou pas, CS8 devrait n’être que RHEL avec 2 à 3 mois d'avance, et donc meilleure pour les admins (vu qu'il n'y a plus à attendre pour les bugfixes mineurs, voir que les admins peuvent y contribuer en envoyant le correctif)
À la place, j'ai le sentiment qu'il y a plus quelque chose qui ressemble à une envie d'avoir RHEL sans en avoir le budget pour, et qu'il y a une forme de rancune.
[^] # Re: Fermilab & CERN, scientific linux
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 8.
Sans doute parce que Debian ne réponds pas aux besoins du CERN.
Par exemple, acheter des clusters de matos et avoir une assurance assez forte que ça va marcher parce que tu as les mêmes patchs que la version RHEL qui est certifié.
Ou avoir un cycle de vie logiciel prévisible et un peu plus long que 2/3 ans.
[^] # Re: Utilisation en production
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 3.
Moi, j'utilise Centos Stream 8 en production (toute les machines C8, hyperviseur, site web, DNS, etc).
Et y a pas vraiment grand chose à en dire vu que ça marche.
[^] # Re: lien pour l'étude ?
Posté par Misc (site web personnel) . En réponse au lien Netflix et YouTube sont des usines à CO2. Évalué à 10. Dernière modification le 06 novembre 2021 à 10:57.
Donc la solution, ça serait peut être de coordonner les visionnages.
Par exemple, on pourrait imaginer louer une grande salle avec des sièges, et mettre un écran de plusieurs mètres de haut.
Et on pourrait passer des accords d'exclusivité avec les studios pour avoir les films plus tôt, car ça permettrait d'inciter les gens à venir.
Chaque "salle" pourrai avoir son propre film, ce qui permet une certaine autonomie dans les horaires et les visionnages.
Je propose d'appeler ça:
Complexe intégré numérique d’écrans multi-personne autonomes
C'est un peu long, si quelqu'un a une idée d'un meilleur nom, je suis preneur.
[^] # Re: lien pour l'étude ?
Posté par Misc (site web personnel) . En réponse au lien Netflix et YouTube sont des usines à CO2. Évalué à 4.
Mais on peut difficilement augmenter la résolution d'un écran via le logiciel, on utilise déjà du logiciel pour les appareils photos, mais à un moment pour faire mieux, il faut plus de pixels.
Les communications radios, malgré les progrès dans le domaine des SDR, ont sans doute encore des besoins assez stricts en terme de latence, donc on peut pas facilement changer les protocoles. On commence à avoir des trucs avec des FPGA pas cher, donc ça va sans doute arriver.
Je pense qu'on peut discuter de savoir si le matériel d'il y a 10 ans serait capable de faire assez bien pour l'usage qu'on en a, bien sur.
Je peux donner l'exemple de la Nintendo Switch. La console a un CPU 4 coeurs cortex A57 à 1Ghz, 4G de ram. En face, la Xbox One X a 12G de ram et 8 coeurs AMD à 2.3 Ghz, si j'en crois Wikipedia.
Les jeux sont sans doute plus beaux sur X Box. Mais ça reste la Switch qui se vends le mieux, en partie que Nintendo n'a pas tenté de faire la course au graphisme et au photo réalisme contrairement à ses concurrents (Sony et Microsoft), et que finalement, un CPU moins rapide et moins de ram suffisent à faire des jeux plus que corrects.
Ensuite, c'est un mauvais exemple car il y a plein de soucis dans le modèle des consoles (par exemple, changer les manettes pour innover).
Mais prenons par exemple le développement logiciel. On a de nos jours des super systèmes de CI/CD, parce que c'est pas aussi cher qu'avant de compiler parce qu'on a changer le matériel. Je me souviens du cluster de 5 machines bi-proc (ou quadri-proc) chez Mandrakesoft pour compiler le rpm d'Openoffice en 6h. Et le cluster était la pour tout les paquets, donc monopoliser les ressources, c'était pas sans effet de bord.
De nos jours, tu en as pour (si je me trompe pas) 23 minutes sur une seule machine: https://ci.libreoffice.org/job/lo_tb_master_linux_dbg/lastSuccessfulBuild/
Le logiciel peut pas faire de miracle à ce niveau.
[^] # Re: Ça se discute
Posté par Misc (site web personnel) . En réponse au lien La France arrête d’exiger que des écouteurs soient vendus avec les smartphones. Évalué à 5.
Ou qu'il y a eu une course vers le prix le moins cher et/ou des raccourcis pour être le premier sur le marché, etc.
[^] # Re: Maître esclave
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 3.
ça devrait s'appeler Gmap dans ce cas, y a moins de lettres à changer.
[^] # Re: Comprends pas...
Posté par Misc (site web personnel) . En réponse au lien Des pass sanitaires européens au nom de Bob l’Éponge et d’Adolf Hitler :). Évalué à 2.
De ce que je sais, les soignants/médecins/professionnels de santé peuvent signer sans avoir à vérifier les papiers. D'une part parce que seul les flics peuvent imposer de demander ça, parce que les erreurs arrivent, et parce que les sans papiers existent.
Mais bon, ça fait moins de vues que "la sécurité du passe sanitaire est compromise".
Ensuite, si les gens veulent plus de sécurité sur le passe sanitaire, y a sans doute moyen de rajouter plus de surveillance bien sur, mais je suis pas sur que ça soit une bonne chose.
[^] # Re: Maître esclave
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 3.
Vu les propositions de devnewton, je suppose que l'idée est remplacer les pièces jointes par URI data:
Si quelqu'un me cherche pour financer ma startup innovante qui va révolutionner le monde du SMTP, je suis dehors.
[^] # Re: Maître esclave
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 3.
Bah, on pourrait inventer des espèces de signes pour ça, non ?
[^] # Re: Maître esclave
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 8.
Est ce que tu veux dire qu'il est temps de passer aux nombres Romdeux ?
[^] # Re: Pas trop étonnant
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 6.
2068, soit sans doute 20 ans après la retraite de Moxie Marlinspike, et quand Brian Acton aura 95 ans, si il est en vie (et que la planète n'a pas brulé). Je pense que d'ici la, les choses auront changer.
Je pense que tu as raison sur le fond, mais je pense que le prêt, c'est juste un don déguisé pour éviter les impots.
La fortune de Brian Acton est estimé à 2.5 milliards. 50 millions (car le dont a été fait en 2 fois), c'est à peine l'argent que lui rapporterais un livret A sur 1 an (pour donner un ordre de grandeur). Et je suppose qu'il a sans doute des trucs plus rentable que ça.
[^] # Re: 5, vraiment ???
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 5.
Je suis pas vraiment sur. Déjà, vu que les ressources alloués sur le P2P, c'est 1 personne qui bosse aussi sur Dendrite, j'ai des doutes (quand tu as moins d'un temps plein, c'est pas vraiment une priorité). Ensuite, Pinecone semble être le choix fait aprés avoir testé des choses avec yggdrasil, donc j'ai le sentiment que c'est encore pas mal dans l'experimental, et qu'il va falloir encore un peu de temps avant de voir si ça marche (parce que des réseaux mesh, y en a eu des tonnes depuis des années).
Je ne doute pas que ça arrive, mais encore une fois, faudrait sans doute plus qu'un temps partiel dessus.
Je me méfie un peu, j'ai le sentiment qu'il y a un effet FOSDEM. Quand le FOSDEM arrive, il y a toujours un demo d'un truc et un peu de hype, qui est préparé avant, mais ça se concrétise pas après. Par exemple, y a un blog post complet sur Cerulean, et y a plus rien depuis.
Si j'en crois les articles d'il y a un an, l'usage en P2P dépend d'une MSC proposé en 2018 qui a été remplacé ou dépend d'une MSC proposé en 2020. Bien sur, on pourrais avoir matrix en p2p en perdant le fait d'avoir plusieurs clients, mais il serait assez ironique de revenir à des limitations d'IRC sous guise de progrés.
Oui, et ça va être impossible à résoudre sauf à avoir un monopole d'une façon ou d'une autre. C'est comme XMPP, les gens ralent parce qu'il faut choisir un client, mais je suis sur qu'interdire les clients alternatifs seraient pire.
[^] # Re: 5, vraiment ???
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 5.
Alors d'un coté, tout les protocoles d'échanges sont comme ça. SMTP, XMPP, etc.
Plus ton service héberge du monde, moins ça te coûte, vu que le trafic va rester en local, que 2 personnes sur le même serveur vont partager le stockage, que tu va mutualiser les coûts.
De l'autre, la différence entre Matrix (avec un état partagé), et SMTP/XMPP (passage de message), c'est que tes coûts au sens générique n'augmente pas de la même façon.
Dans le cas de SMTP/XMPP, ça va grimper avec ton nombre d'utilisateurs et ton usage. Si j'utilise peu, je n'ai que les coûts fixes. Si je suis sur un serveur MUC XMPP avec 1000 personnes de 1000 serveurs, l’hébergeur du salon a des coûts plus élevés que moi, mais moi, ça va. Si je suis sur une liste de diffusion avec 1000 personnes, l’hébergeur de la liste a des coûts, mais moi, ça va.
Donc ton serveur XMPP/SMTP est utilisé comme "client" vis à vis du service de distribution de messages proposé par le serveur en face (salon muc, liste de discussion), qui agit comme "fournisseur de service". Le fournisseur de serivce prends plus de ressources, car il fait plus, et tout le monde le comprends.
Dans le cas de Matrix, c'est la diversité et la croissance du réseau qui prime. Si tu va sur un salon avec 1000 personnes de 1000 serveurs différents, tu va douiller, que tu l'utilises beaucoup ou pas. Et plus le réseau grandit parce qu'il se décentralise, plus ça coûte à tout le monde. Chaque personne qui rejoint @tartampion:example.org va faire consommer des ressources chez tout les autres (vu que tout le monde va le contacter tout le temps).
Un fonctionnement ou le serveur matrix ne stocke rien en local, renvoie des données vides quand on demande et se contente d'aller voir chez les autres via l'api de backfill serait faisable (et sans doute moins coûteuse), mais fondamentalement inégalitaire (vu que d'un coup, tu va avoir des serveurs qui vont devoir payer le coût des APIs de backfill et de stockage pour une part substantiel de tout le réseau).
Si il y a le choix entre dire "je prends pas de ressources, mais je bénéficie du réseau" et "je prends des ressources, et j'ai autant de bénéfice", je suis pas sur que les incitations soient bien pensés. Mais l'état actuelle implique que tout le monde consomme plus de ressources quand la diversité du réseau augmente (ou du moins, la partie du réseau ou on participe, si le réseau triple mais que je parle à 3 personnes, ça va rien changer pour moi).
Ça me parait assez paradoxale, et en effet, je pense qu'à un moment, ça va entrainer une recentralisation chez le même fournisseur (ce qu'on voit déjà arriver en fait, vu que tout le monde héberge les choses chez New Vector/Element, vu que GNOME, KDE, Fedora, Ansible et Mozilla sont chez eux).
[^] # Re: 5, vraiment ???
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 6. Dernière modification le 28 octobre 2021 à 00:13.
Sinon, c'est 0.5
:
https://element.io/blog/ems-launches-fully-managed-matrix-bridging-for-whatsapp/
Et pareil pour signal:
https://element.io/blog/ems-launches-matrix-bridging-for-signal/
Donc l'offre Element One à 5$, c'est l'offre à 3$ avec 3 bridge à 0.5$ en plus, sans un DNS custom.
Vu que le prix de la ram chez AWS, c'est grosso modo 6$ pour 1G (t4.nano), on peut supposer que pour 0.5$, tu as 80 mega de ram. Sur mon téléphone, whatsapp pour parler à grosso modo 2 personnes et 1 groupe utilise 81 Mo. Signal consomme 219 Mo.
J'imagine que les bridges vont pas prendre moins ou plus que les clients natifs (vu que le bridge matrix/whatsapp est en Go, le bridge matrix/signal est en python et en java et utilise un bout de postgresql), ça semble être une offre à prix coutant, voir presque à perte (parce qu'il faut payer des taxes, la facturation, etc).
C'est noble de la part de l'équipe, mais je pense que c'est pas forcément tenable sur le long terme.
[^] # Re: Pas trop étonnant
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 8.
Signal est aussi financé par le fondateur de Whatsapp après le rachat par Facebook, et l'idée de Signal vient aussi des projets d'OpenWhisper, ou y a bien eu quelques années de R&D financée par une boite privé et du proprio et sans doute du capital risque, puis par Twitter aprés le rachat.
Parce qu'un autre truc qu'on oublie aussi, c'est qu'une messagerie pour des centaines de millions de personnes, ç'est assez coûteux en infra à un moment.
Je renvoie en toute modestie à la discussion sur Discord que j'ai vaguement lancé, notament la discussion sur combien de CHATONS on a besoin pour remplacer discord en France.
[^] # Re: Pas trop étonnant
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 8. Dernière modification le 27 octobre 2021 à 18:45.
Je pense plus simplement parce que Facebook avait les utilisateurs et beaucoup plus de moyens.
Faut pas chercher midi à quartoze heures, facebook, c'est plus de 35 000 employés en 2018. C'est presque 20 fois la population active de Linuxfr sur les 3 derniers mois. Donc on peut supposer que c'est en effet plus facile pour eux de faire un client de messagerie quand ils ont l'infra en place, les devs, et pas spécialement besoin de chercher à en vivre.
Prosody, c'est sans doute moins de 5 volontaires tout comme Gajim ou Conversation. Une boite comme ProcessOne (qui fait ejabberd), ça a l'air tout petit (6 personnes visibles dans l'org github, < 10 sur societe.com).
Même whatsapp avait plus de moyens que l'écosystème XMPP, vu que c'etait une startup de 50 personnes à l'époque du rachat par Facebook, et sans doute plus depuis, et sans doute aussi 50 par la magie du financement (financement qui reste un souci récurrent du libre).
Du coup, oui, les gros acteurs raflent le jackpot. Matrix marche aussi parce qu'ils ont assez vite proposé d'avoir un Patreon, parce qu'ils ont eu des investisseurs et parce que ça a commencé par une boite de telco.
C'est le pognon qui fait que ça, pas les questions de fragmentation. En fait, la fragmentation est la parce qu'il y a pas de pognon pour réduire la fragmentation en premier lieu.
Et aussi parce que Whatsapp/FB MEssenger, etc ne cherche pas à réduire la fragmentation, vu qu'il y en a pas pour eux (walled garden, etc). Forcer tout le monde sur gajim et prosody, ça marcherais aussi pour réduire la fragmentation. Mais ça va pas plaire.
[^] # Re: 5, vraiment ???
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 6. Dernière modification le 27 octobre 2021 à 18:27.
Du coup, si je comprends bien, EMS se positionne comme une offre moins cher que Beeper tout en reprenant le code de Beeper alors que Beeper utilise le code de Synapse et co (et donc se positionne comme une offre plus cher que EMS ).
Je sais pas trop quoi en penser, mais se mettre en concurrence au lieu de se mettre en coopération, ça me parait pas terrible pour l'écosystème.
À un moment, en voyant l'animosité autour de Matrix sur Hacker News (dans certains commentaires des news, mais aussi plusieurs comparaisons avec XMPP assez à charge sur Matrix, avec l'un des fondateurs qui se jette dans l'arène), je me suis demandé pourquoi la vibe était différente de mes souvenirs de l'époque d'XMPP.
Il y avait des débats sans doute (notamment sur linuxfr) donc je ne pense pas que ça soit nouveau. Et clairement, on était pas à l'époque à bout de souffle à cause de l'état du monde comme maintenant (entre la pandémie, le climat, la montée de l’extrême droite et la sortie de Windows 11), donc ça joue aussi.
Mais je ne me souviens pas de choses qui avaient l'air aussi virulente, et les discussions que j'ai vu date d'avant le début de la pandémie (genre en 2019). Du coup, je pense qu'il y a autre chose.
Par exemple, si je prends ce papier, il est extrêmement à charge vis à vis de Matrix, pour finalement des choses ou en pratique, je pense que tout le monde s'en fout (et qu'on peut pardonner). Perso, je m'attends pas à ce qu'une petite boite comme Matrix se retrouve avec une communication parfaite. Rédiger tout un article sur le sujet me parait assez disproportionné, et je me dit qu'il faut être vraiment motivé pour ça.
Et donc, peut être qu'au delà des débats techniques, il y a aussi des problématiques humaines non visibles.
Par exemple, le fait de sortir une offre concurrente de ce qui aurait pu être un partenaire (beeper), ça y contribue. Des remarques sur les serveurs publiques en "free for all" (cf la fin de mon commentaire ), ça y contribue.
Ensuite, peut être aussi que je me fait des idées, et qu'il y a rien.
[^] # Re: Pas trop étonnant
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 9.
Mais Matrix marche parce qu'actuellement, il n'y a qu'un serveur viable qui bouge assez vite, pareil pour les clients. J'ai installé conduit, j'ai pas pu rentrer dans un certain nombre de salons car le support du protocole est incomplet. Dendrite était mieux à ce niveau, mais j'ai pas testé les fonctionnalités plus que ça, et avec 1/4 des ressources de synapse, je m'attends pas à un miracle (ni à ce que le retard disparaisse de si tôt).
Et la raison du succès de Matrix, c'est aussi le fait d'avoir un bouncer IRC gratuit plus que le protocole (et gratuit parce que sponsorisé par Element).
De plus, je pense que, fondamentalement, Matrix en temps que protocole souffre d'un probléme qui va apparaître à un moment ou à un autre. C'est un système distribué, le problème des généraux byzantins est forcement la (je peux le prouver, mais j'ai pas la place dans la marge pour ça).
Et tout comme XMPP et SMTP, tu va avoir les soucis de spam inhérent à l'ouverture d'une plateforme. Rien de ce que Matrix fait ou propose ne va être différent, et de ce que je sais, ce qui est utilisé, c'est une liste centralisé d'instance et de comptes qui pose probléme via mjolnir. C'est exactement ce qui était fait au début avec spamhaus et autre DNSBL pour le SMTP, ou sur XMPP, ou via le bot de modération irc de freenode d'il y a un bout de temps (je me souviens d'un compte assez persistant il y a 10 ans, et d'un bot irc géré par freenode).
On sait tous comment ça se passe pour le SMTP en auto hébergement à cause de ça, et d'ailleurs, Element le pointe à moitié dans l'article de blog:
It's hosted by Element Matrix Services; constantly maintained to the highest standard and best practices by the experts who created Matrix - giving an infinitely better experience than the typical free-for-all of public homeservers.[^] # Re: Pas trop étonnant
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 5.
Notamment https://ergo.chat/, qui a un mode bouncer integré. Ça aurait réglé tellement de souci d'avoir ça plus tôt.
[^] # Re: Accord avec Whatsapp ?
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 7.
Mhh, du coup, Whatsapp va voir plusieurs milliers de personnes venir d'une seul IP, avec tout le monde qui tourne dans le même émulateur, connecté en permanence et ne va pas trouver ça louche ?
Ensuite, si on va lire les ToS:
Je suis pas juriste, mais si Element n'a pas de contrat avec Whatsapp, je pense que le service est une violation triviale des ToS.
Je peux connecter plusieurs appareils via Matrix (point H), c'est un service payant de location (point G), ça collecte des données (point F, addresse IP, etc) et le point I, bah, c'est le but du service.
[^] # Re: 5$
Posté par Misc (site web personnel) . En réponse au journal Comme une impression de déjà vu…. Évalué à 3.
C'est 5$ par utilisateur et par mois. Ton VPS peut sans doute permettre d'avoir plus qu'une personne (vu que la conso de synapse et co va être lié au nombre de salons total plus que le nombre de compte utilisateur).
Et vu la conso de ram de synapse (qui reste le plus efficace des 3 serveurs que j'ai testé),vu le coût d'avoir des clients et de facturation (frais banquaire, la compta, le support), je pige pas comment Element arrive à être rentable avec ce genre d'offre.
[^] # Re: Le pas sanitaire
Posté par Misc (site web personnel) . En réponse au journal La Quadrature du Net fait-elle fausse route ?. Évalué à 2.
Je suppose que tu parles pas du pass en lui même (parce que je pense que le systéme mis en place va être étendu pour d'autres vaccins, et pour l'international), mais de sa vérification dans ses modalités actuelles (plus ou moins actuelle, vu que le pass pour les grandes surfaces n'est plus requis depuis 2j mais tu as du le voir aussi dans ta boule de crystal).
Mais avant de chiffrer les inconvénients (ça fait chier les gens de faire du travail en plus, comme porter un masque), faut aussi pointer les avantages non pris en compte pour voir que ça dépend pas que de la couverture.
Primo, il y a le fait que le pass sanitaire a poussé à la vaccination par effet d'annonce. Mais l'effet d'annonce ne marche que parce que le pass a été mis en place, donc il faut le garder assez longtemps pour marquer durablement les esprits afin de pouvoir refaire ça pour une prochaine pandémie. Ensuite, bien sur, tout le monde va oublier assez vite si c'est trop court.
Ensuite, il y a le fait que le pass sanitaire a redonné de l'élan aux manifs populaires, et à donner de quoi discuter sur Linuxfr (en plus du télétravail).
Donc pour moi, il faut le garder jusqu'à avoir 30% de la population dans la rue, histoire de pimenter la campagne présidentielle.
Car si c'est pour voir encore une montée de l’extrême droite sur le thème de la sécurité (sujet dont on semble se foutre de plus en plus ), ça va, on ressort ça tout les 5 ans, et franchement, c'est même pas original, c'est juste une repompe des années 30.
Donc je pense que ta question ne prends pas en compte les vrais dimensions de la problématique.