Je pense que c'est plus compliqué que ça. Il y a pas forcément "une blockchain", mais plusieurs.
Dans le cas d'Axa, je suppose qu'ils utilisent ça comme un outil d'execution de code en publiant le code et l'execution sur une blockchain (et donc le but est d'améliorer la confiance en disant "on a tel politique, c'est marqué ici et voici les executions en publique". C'est une approche intéressante pour la transparence, et comme c'est pas une blockchain publique, il n'y a pas le souci de la conso excessive de ressources.
mais bon, je pense que ça ne suffit pas, vu que ça a été arrêter.
Je pense que pour un petit groupe privée (exemple, les notaires e France), il y a des choses à explorer. Mais ça ne va decentralisé que d'un point de vue technique, et il faut toujours un organisme central pour gérer un peu tout le reste, donc si tu as besoin d'un consortium, la décentralisation n'est pas vraiment atteinte vu qu'il reste un point centrale.
Mais pour tout les trucs publiques (eg, publique en lecture et en écriture), c'est sans doute globalement mort, vu que tu va dépendre du fait de consommer des ressources pour protéger la blockchain (généraux byzantins, etc) et donc c'est foutu.
Ben tu dis pas quel fabricant, quel support, quel demande est ce que tu as eu ni rien.
Moi, j'ai l'expérience contraire. Donc c'est peut être une question de contrat de support (donc de coût). Peut être que c'est une question de taille du client (donc pareil, de coût).
Parce que tu pense que les fabriquants (je pense aux
fabriquants de matériel - on parle de DELL, IBM, Oracle,… - qui
supportent actuellement RH pas d'embarquer où RHEL est
inexistant) ont une intrication aussi grande ? Par exemple tu
aurait un iptables-hp qui utilise l'appel système créé par HP
qui utilise le circuit top moumout de la carte réseau HP ?
Je pige pas la question. je dit juste que décider de ne supporter que le kernel n'a aucun sens car il n'est pas un composant isolé, vu que l'userspace plus haut en dépend.
Comme je le dis plus haut, je n'arrive pas à trouver de cas où
ce que tu affirme se révèle. Dans les faits, ses constructeurs
sont supporté upstream (de leur fait ou pas) et tu marche
aussi bien avec une slackware qu'avec la RHEL.
Dans les faits, les constructeurs devraient demander de lancer des outils de diagnostiques avant un RMA. Soit un outil dans le bios/EFI (auquel cas on retire la couche avant et la distro, OSEF), soit des outils en userspace (et on revient à la question du support des distros).
Ensuite, ça n'a pas l'air d'avoir été ton expérience et je crois comprendre qu'on a du te dire "merde" à un ticket pour divers raisons lié à la distro. Je ne vais pas te contredire sur ce point mais perso, je n'ai pas eu ce souci. Et pourtant, on fait pas tourner RHEL dans mon équipe mais Centos/Fedora/Debian en fonction des demandes. On a que je sache jamais eu de tickets refusés.
Mais je suppose que c'est pas ce qui t'arrive, donc peut être que tu devrais clarifier les faits, parce que j'ai pas le sentiment de pouvoir suivre en ayant qu'une sous partie de l'histoire.
Y a aussi les paiements "anonymes" (je mets entre guillemets, parce que le gang de ransomware REvil s'est fait chopé hier et je suppose que les paiements n'étaient pas si anonyme que ça).
Bon, j'imagine que quand tu dis "utile", faut comprendre "utile à autre chose que des criminels classiques".
"Libre" je ne sais pas, mais "entièrement basé sur le minage
polluant et la spéculation sauvage", c'est l'impression que ça
me donne.
Alors, sans vouloir défendre les cryptomonnaies qui sont remplis d'arnaques, etc, je crois qu'il y a des alternatives au concept de Proof Of Work utilisé par bitcoin (le fameux "minage polluant" dont tu parles). Et pas des alternatives du style "on utilise la ram/le disque/le réseau au lieu du CPU" qui reste le même genre de minage problématique, mais tout ce qui tourne autour de "Proof of stake".
Ensuite, personne n'en parle, et j'ai pas chercher plus, donc il y a sans doute une raison (genre, ça marche pas, ou c'est pas efficace, ou on peut pas arnaquer des gens avec).
S'ils ne voulaient pas supporter 42 distributions, ils
pourraient parfaitement supporter le nombre qu'ils veulent de
noyau LTS (la dernière, les 2 dernières, les 3 dernières…) et
te dire de te débrouiller avec ton OS (éventuellement avoir
une préco pour une distrib', mais une préconisation pas un
truc qui sert à t'invalider en support).
C'est une distinction artificielle basé sur un détail purement technique, et supposer qu'il y a une frontière entre l'userspace et le noyau pour le support.
Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.
Les distributions vont faire des efforts pour que ça casse pas trop souvent (ne serais que pour les upgrades), mais si ça casse, elles vont pas dire "on va corriger pour ton kernel custom", mais "ça marche avec notre noyau, corrige le tien".
Donc l'idée d'avoir un OS séparé du noyau, c'est une illusion, tout est mis pour fonctionner ensemble, et c'est pas parce que tu estimes qu'il y a une frontière que la frontière a du sens pour un autre usage (eg, délimiter les responsabilités pour le support).
Si c'est le cas du coup c'est moins "on veut pas supporter 42
distributions" que "on ne supporte que les distributions avec
qui on a un accord financier". Mais ça revient plus ou prou au
même, faut avoir une cravate et un chéquier pour pouvoir
exister en tant que distribution.
Il y a plusieurs alternatives, comme avoir les distributions faire le support niveau 1, mais ça demande aussi un chéquier soit coté distribution. Tu peux aussi faire le support en interne, et avoir ta propre équipe kernel. Ça demande de sortir aussi le chéquier, mais ça semble être courant dans les boites de tech d'une certaine taille (cf https://danluu.com/in-house/ ).
Mais ça demande toujours de sortir le chéquier parce que visiblement, personne ne veut le faire gratuitement, et ça mérite sans doute la question de "pourquoi ?".
C'est en bossant chez un éditeur que j'ai fini par piger à quel point une partie de la communauté du libre (mais pas que) se fait des idées sur sa propre importance vis à vis des éditeurs (genre Microsoft et co, vers les années 2000).
Par exemple justement, les histoires de vente lié y a 15/20 ans sur linuxfr, c'est pas du tout pour empêcher Linux de percer comme on a pu me dire un jour.
C'est parce que les gros clients de Microsoft, c'est les vendeurs de PC, et parce que vendre un PC avec Windows, ça permet de levendre aussi avec les trucs Norton et co (et donc Norton qui va payer pour être la), donc de faire baisser les prix, donc d'être compétitif envers les autres vendeurs de PC.
Je dit pas que c'est une situation saine, loin de la, Microsoft reste en situation de monopole, même si l'industrie des intégrateurs semble s'en accommoder.
Mais c'est pas du tout le discours qu'on avait autour de ça, ou du moins, c'est pas l'explication qu'on donnait.
La, c'est pareil, il y a des mécanismes économiques en jeu qui passent assez souvent par dessus la tête des gens qui sont hors de ce bout de l'industrie, et on va croire que parce qu'on veux une chose, d'autres veulent pareil, et que ça a du sens économiquement de le faire.
Ensuite, bah, les accords d'exclusivités, ça existe. Les accords commerciaux, ça reste en général secret. Et dans le cas de Micorosoft vis à vis des fabricants, il y a clairement un déséquilibre vu qu'il y a un acteur (MS) face à une poignée, donc il est assez facile pour l'un de faire jouer la concurrence.
À minima, le logiciel libre permet d'éviter la situation, vu que n'importe quel constructeur peut à tout moment dire "on va prendre Centos/Alma/Rocky/Oracle/Suse/Ubuntu/RHEL" pour négocier avec tout les autres, et pareil du coté des éditeurs.
Et c'est aussi pour ça que je pense que l'annonce de la fin de CL 8 était une bonne chose, vu que ça a enfin fait bouger la communauté pour faire des choses. Les histoires lors de la sortie de Centos 6 (et son retard) sont connus, mais c'est que la partie immergé.
Après l'arrivée des responsables de Centos chez RH, mes collègues ont vu que la communauté a commencé à se reposer de plus en plus sur RH (exemple, lors des dojos Centos), les tentatives de faire des SIG (Software Interest Group) ont pas forcément super bien marché. Et que la communauté, c'était surtout une communauté d'utilisateurs, donc l'idée de co-création était assez étrangère pour eux.
Au moins, avec Rocky/Alma, il y a des gens motivés pour gérer l'infra, faire des présentations, etc, etc. C'est triste d'avoir du passer par un choc comme celui la, mais je sais que c'est pas faute d'avoir tenté autre chose avant.
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.
[^] # Re: Cryptomonnaie par ci par là
Posté par Misc (site web personnel) . En réponse au lien Reddit veut décentraliser les réseaux sociaux... avec de la cryptomonnaie. Évalué à 3.
Je pense que c'est plus compliqué que ça. Il y a pas forcément "une blockchain", mais plusieurs.
Dans le cas d'Axa, je suppose qu'ils utilisent ça comme un outil d'execution de code en publiant le code et l'execution sur une blockchain (et donc le but est d'améliorer la confiance en disant "on a tel politique, c'est marqué ici et voici les executions en publique". C'est une approche intéressante pour la transparence, et comme c'est pas une blockchain publique, il n'y a pas le souci de la conso excessive de ressources.
mais bon, je pense que ça ne suffit pas, vu que ça a été arrêter.
Je pense que pour un petit groupe privée (exemple, les notaires e France), il y a des choses à explorer. Mais ça ne va decentralisé que d'un point de vue technique, et il faut toujours un organisme central pour gérer un peu tout le reste, donc si tu as besoin d'un consortium, la décentralisation n'est pas vraiment atteinte vu qu'il reste un point centrale.
Mais pour tout les trucs publiques (eg, publique en lecture et en écriture), c'est sans doute globalement mort, vu que tu va dépendre du fait de consommer des ressources pour protéger la blockchain (généraux byzantins, etc) et donc c'est foutu.
[^] # 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é à 2.
Ben tu dis pas quel fabricant, quel support, quel demande est ce que tu as eu ni rien.
Moi, j'ai l'expérience contraire. Donc c'est peut être une question de contrat de support (donc de coût). Peut être que c'est une question de taille du client (donc pareil, de coût).
[^] # 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é à 2.
Je pige pas la question. je dit juste que décider de ne supporter que le kernel n'a aucun sens car il n'est pas un composant isolé, vu que l'userspace plus haut en dépend.
On voit ça par exemple sur les conteneurs, comme décrit par un de mes collègues: http://crunchtools.com/5040-2/
Dans les faits, les constructeurs devraient demander de lancer des outils de diagnostiques avant un RMA. Soit un outil dans le bios/EFI (auquel cas on retire la couche avant et la distro, OSEF), soit des outils en userspace (et on revient à la question du support des distros).
Ensuite, ça n'a pas l'air d'avoir été ton expérience et je crois comprendre qu'on a du te dire "merde" à un ticket pour divers raisons lié à la distro. Je ne vais pas te contredire sur ce point mais perso, je n'ai pas eu ce souci. Et pourtant, on fait pas tourner RHEL dans mon équipe mais Centos/Fedora/Debian en fonction des demandes. On a que je sache jamais eu de tickets refusés.
Mais je suppose que c'est pas ce qui t'arrive, donc peut être que tu devrais clarifier les faits, parce que j'ai pas le sentiment de pouvoir suivre en ayant qu'une sous partie de l'histoire.
[^] # Re: Cryptomonnaie par ci par là
Posté par Misc (site web personnel) . En réponse au lien Reddit veut décentraliser les réseaux sociaux... avec de la cryptomonnaie. Évalué à 3.
Est ce que recycler les arnaques comptent comme un cas d'usage:
https://mobile.twitter.com/Foone/status/1457749433844568066
Y a aussi les paiements "anonymes" (je mets entre guillemets, parce que le gang de ransomware REvil s'est fait chopé hier et je suppose que les paiements n'étaient pas si anonyme que ça).
Bon, j'imagine que quand tu dis "utile", faut comprendre "utile à autre chose que des criminels classiques".
[^] # Re: reddit est libre ?
Posté par Misc (site web personnel) . En réponse au lien Reddit veut décentraliser les réseaux sociaux... avec de la cryptomonnaie. Évalué à 2.
Alors, sans vouloir défendre les cryptomonnaies qui sont remplis d'arnaques, etc, je crois qu'il y a des alternatives au concept de Proof Of Work utilisé par bitcoin (le fameux "minage polluant" dont tu parles). Et pas des alternatives du style "on utilise la ram/le disque/le réseau au lieu du CPU" qui reste le même genre de minage problématique, mais tout ce qui tourne autour de "Proof of stake".
Ensuite, personne n'en parle, et j'ai pas chercher plus, donc il y a sans doute une raison (genre, ça marche pas, ou c'est pas efficace, ou on peut pas arnaquer des gens avec).
[^] # 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.
C'est une distinction artificielle basé sur un détail purement technique, et supposer qu'il y a une frontière entre l'userspace et le noyau pour le support.
Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.
Les distributions vont faire des efforts pour que ça casse pas trop souvent (ne serais que pour les upgrades), mais si ça casse, elles vont pas dire "on va corriger pour ton kernel custom", mais "ça marche avec notre noyau, corrige le tien".
Donc l'idée d'avoir un OS séparé du noyau, c'est une illusion, tout est mis pour fonctionner ensemble, et c'est pas parce que tu estimes qu'il y a une frontière que la frontière a du sens pour un autre usage (eg, délimiter les responsabilités pour le support).
Il y a plusieurs alternatives, comme avoir les distributions faire le support niveau 1, mais ça demande aussi un chéquier soit coté distribution. Tu peux aussi faire le support en interne, et avoir ta propre équipe kernel. Ça demande de sortir aussi le chéquier, mais ça semble être courant dans les boites de tech d'une certaine taille (cf https://danluu.com/in-house/ ).
Mais ça demande toujours de sortir le chéquier parce que visiblement, personne ne veut le faire gratuitement, et ça mérite sans doute la question de "pourquoi ?".
[^] # 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.
Oui, c'est 100% une question économique.
C'est en bossant chez un éditeur que j'ai fini par piger à quel point une partie de la communauté du libre (mais pas que) se fait des idées sur sa propre importance vis à vis des éditeurs (genre Microsoft et co, vers les années 2000).
Par exemple justement, les histoires de vente lié y a 15/20 ans sur linuxfr, c'est pas du tout pour empêcher Linux de percer comme on a pu me dire un jour.
C'est parce que les gros clients de Microsoft, c'est les vendeurs de PC, et parce que vendre un PC avec Windows, ça permet de levendre aussi avec les trucs Norton et co (et donc Norton qui va payer pour être la), donc de faire baisser les prix, donc d'être compétitif envers les autres vendeurs de PC.
Je dit pas que c'est une situation saine, loin de la, Microsoft reste en situation de monopole, même si l'industrie des intégrateurs semble s'en accommoder.
Mais c'est pas du tout le discours qu'on avait autour de ça, ou du moins, c'est pas l'explication qu'on donnait.
La, c'est pareil, il y a des mécanismes économiques en jeu qui passent assez souvent par dessus la tête des gens qui sont hors de ce bout de l'industrie, et on va croire que parce qu'on veux une chose, d'autres veulent pareil, et que ça a du sens économiquement de le faire.
Ensuite, bah, les accords d'exclusivités, ça existe. Les accords commerciaux, ça reste en général secret. Et dans le cas de Micorosoft vis à vis des fabricants, il y a clairement un déséquilibre vu qu'il y a un acteur (MS) face à une poignée, donc il est assez facile pour l'un de faire jouer la concurrence.
À minima, le logiciel libre permet d'éviter la situation, vu que n'importe quel constructeur peut à tout moment dire "on va prendre Centos/Alma/Rocky/Oracle/Suse/Ubuntu/RHEL" pour négocier avec tout les autres, et pareil du coté des éditeurs.
Et c'est aussi pour ça que je pense que l'annonce de la fin de CL 8 était une bonne chose, vu que ça a enfin fait bouger la communauté pour faire des choses. Les histoires lors de la sortie de Centos 6 (et son retard) sont connus, mais c'est que la partie immergé.
Après l'arrivée des responsables de Centos chez RH, mes collègues ont vu que la communauté a commencé à se reposer de plus en plus sur RH (exemple, lors des dojos Centos), les tentatives de faire des SIG (Software Interest Group) ont pas forcément super bien marché. Et que la communauté, c'était surtout une communauté d'utilisateurs, donc l'idée de co-création était assez étrangère pour eux.
Au moins, avec Rocky/Alma, il y a des gens motivés pour gérer l'infra, faire des présentations, etc, etc. C'est triste d'avoir du passer par un choc comme celui la, mais je sais que c'est pas faute d'avoir tenté autre chose avant.
[^] # 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.