C'est presque vendredi, donc je vais sauter à pied joint. DW ne mesure que l'audience de son propre site (sauf erreur de ma part). Et quand l'audience max d'une page, c'est 3000 visites par jour (parce que la distro a été annoncé dans Distro watch weekly), ça ne me parait pas super représentatif, ni ne permet de tirer grand chose.
Linuxfr, c'est ~1890 comptes utilisés y a moins de 3 mois. Le FOSDEM, c'est dans les 8000 personnes (cf la page web). Et Canonical parle de 25 millions d'utilisateurs Ubuntu en 2014.
Donc bon, ça veut juste dire que personne ne va voir la page de Gentoo sur Distrowatch, sans doute parce que Gentoo n'est pas mentionné dans les news.
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.
[^] # 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é à 3.
ça va être assez dur si c'est en virtuel:
https://fosdem.org/2022/news/2021-10-22-fosdem-online-2022/
[^] # 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.
C'est presque vendredi, donc je vais sauter à pied joint. DW ne mesure que l'audience de son propre site (sauf erreur de ma part). Et quand l'audience max d'une page, c'est 3000 visites par jour (parce que la distro a été annoncé dans Distro watch weekly), ça ne me parait pas super représentatif, ni ne permet de tirer grand chose.
Linuxfr, c'est ~1890 comptes utilisés y a moins de 3 mois. Le FOSDEM, c'est dans les 8000 personnes (cf la page web). Et Canonical parle de 25 millions d'utilisateurs Ubuntu en 2014.
Donc bon, ça veut juste dire que personne ne va voir la page de Gentoo sur Distrowatch, sans doute parce que Gentoo n'est pas mentionné dans les news.
[^] # 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.
En contribuant directement à Centos Stream, ou en proposant des paquets forkés, je suppose.
[^] # 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
:
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.