Quelques efforts mais pas trop quand même (vu que c'est un
appel d'offre avec le moins cher qui gagne). De plus, il
pourra peut-être réussi à tester/patché une debian stable,
mais il n'y a pas de garantie pour la prochaine. Alors que
pour une distribution qui est déjà supportée sur le matos,
il y a une plus grande garantie.
Surtout, le constructeur va faire quoi ?
Aller demander à chacun des fournisseurs d'aller faire des patchs sur une distro qui n'est justement pas géré par une entité commercial, à qui on va dire "on est volontaire, on fait ça sur notre temps libre, mets ça dans le BTS, on regarderas plus tard" ?
Le constructeur va avoir ni une garantie contractuelle que le travail va être fait ( ce qui est un souci si tu signes toi un contrat qui dit que ça va être fait), ni que ça va être fait dans le temps imparti. Donc les fabricants qui veulent faire des efforts vont voir les autres entités commerciales, eg, Suse, RH, Canonical en fonction de la demande (entités commerciales qui vont pas faire le taf gratos, donc le fabricant a autant passer par les mêmes en fonction de la demande des clients ).
Et il a donné le projet à ce fameux individu non nommé dans l'article vers ~2004 (cf un article récent sur le poste du dit individu en question qui a quitté le board de CentOS il y a 3 semaines), donc je ne suis pas 100% sur de voir comment l'historique apporte des garanties morales :/
CentOS ou Scientific Linux étaient basé sur RHEL qui ne
fournissait pas les recettes de construction de la
distribution, entraînant de fait la galère pour
reconstruire une équivalent de la RHEL.
Les SRPMS sont sur ftp.redhat.com depuis grosso modo toujours.
Et avec l'intégration de Centos, il y a eu un dépôt git sur git.centos.org avec tout ce qui est utilisé pour compiler RHEL.
Et avec Centos Stream, c'est encore plus transparent vu que les gens peuvent justement participer (contrairement à l'ancienne Centos, et c'est aussi une des raisons d'avoir fait le changement) .
Avec Debian, toutes les recettes sont données, et c'est
hyper facile de faire une distribution dérivée ou
augmentée.
Que je sache, Debian fourni exactement la même chose que ce que fournit RHEL ou Centos, à savoir des paquets sources.
Et dans les 2 cas, les systèmes de build sont des logiciels libres (exemple, koji & mock pour Centos/RHEL/FEdora, pbuilder, etc pour Debian).
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.
[^] # Re: Rocky pour l'embarqué et la direction
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.
Ce n'est pas les échos que j'ai eu, mais je reconnais que la source des échos est sans doute non neutre.
[^] # Re: Pensez red hat.
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 4.
Sinon, il y a aussi la boite fondé par Gregory Kurtzer, CtrlIQ.
Le site dit texto "CIQ, founded by Gregory Kurtzer, is the Official Support for Rocky Linux."
[^] # 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é à 4.
Surtout, le constructeur va faire quoi ?
Aller demander à chacun des fournisseurs d'aller faire des patchs sur une distro qui n'est justement pas géré par une entité commercial, à qui on va dire "on est volontaire, on fait ça sur notre temps libre, mets ça dans le BTS, on regarderas plus tard" ?
Le constructeur va avoir ni une garantie contractuelle que le travail va être fait ( ce qui est un souci si tu signes toi un contrat qui dit que ça va être fait), ni que ça va être fait dans le temps imparti. Donc les fabricants qui veulent faire des efforts vont voir les autres entités commerciales, eg, Suse, RH, Canonical en fonction de la demande (entités commerciales qui vont pas faire le taf gratos, donc le fabricant a autant passer par les mêmes en fonction de la demande des clients ).
[^] # Re: Rocky pour l'embarqué et la direction
Posté par Misc (site web personnel) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ?. Évalué à 5.
Sauf erreur de ma part, il a quitté CentOS pour des raisons non publiques:
https://blog.centos.org/2019/03/greg-kurtzer-centos-founder/
Et il a donné le projet à ce fameux individu non nommé dans l'article vers ~2004 (cf un article récent sur le poste du dit individu en question qui a quitté le board de CentOS il y a 3 semaines), donc je ne suis pas 100% sur de voir comment l'historique apporte des garanties morales :/
[^] # 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é à 9.
Les SRPMS sont sur ftp.redhat.com depuis grosso modo toujours.
Example: http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/x86_64/SRPMS/
Et avec l'intégration de Centos, il y a eu un dépôt git sur git.centos.org avec tout ce qui est utilisé pour compiler RHEL.
Et avec Centos Stream, c'est encore plus transparent vu que les gens peuvent justement participer (contrairement à l'ancienne Centos, et c'est aussi une des raisons d'avoir fait le changement) .
Que je sache, Debian fourni exactement la même chose que ce que fournit RHEL ou Centos, à savoir des paquets sources.
Et dans les 2 cas, les systèmes de build sont des logiciels libres (exemple, koji & mock pour Centos/RHEL/FEdora, pbuilder, etc pour Debian).
[^] # 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 par mois si tu as un compte à 3:
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.