Trivialement, le fait qu'AXA ai décidé d'arreter le programme montre qu'un arret est possible. Le fait qu'AXA est pu mettre en place le programme en premier lieu montre qu'une création de code est aussi possible. Et vu que patcher, c'est arret + creation, bah, c'est possible de patcher.
Attention, je dit pas que c'est pratique, que c'est rapide, ni rien. J'ai bien conscience que c'est comme dire "on pouvait faire du cloud dans les années 90, il suffisait juste d'une armée d'admin sys pour faire les installations à la demande de distro linux à la main". C'est parce que c'est théoriquement possible que c'est pratiquement faisable (même si le fait d'avoir finalement automatisé suffisament tout montre que c'est faisable de faire du cloud).
Sauf erreur de ma part, les clients ne vont pas directement sur la blockchain d'AXA et doivent donc passer par AXA. Donc AXA est parfaitement capable de dire "maintenant, le nouveau contrat est ici", ce qui régle la question de la mise à jour. Et dire "on a un souci, on va faire à la main", ce qui régle la question de l'arrêt manuel.
Ensuite, c'est dans un cas particulier, et clairement, dans le cas d'une blockchain public ouvert à tous style ethereum ou tout le monde peut aller executer les contrats, etc, c'est un gros souci.
Ça veut dire que les offres "grand public" sont largement
sous-évaluées pour gagner le marché (par exemple), où qu'ils
gagnent vraiment sur autre chose ?
Le support. Quand j'appelle Orange, j'ai quelqu'un qui va comprendre ce que je dit sans suivre un scénario dans un pays ou les gens sont payés moins et dans des conditions de travail sans doute pourri.
J'ai papoté réseau et télétravail avec le technicien lors de mon dernier appel pour me plaindre du changement de prefixe d'ip v6, sans sentir qu'il etait préssurisé pour raccrocher ni rien.
Ensuite, j'ai aussi eu avant des gens qui confondent "ip fixe" et ip v6 au téléphone, donc c'est pas magique d'avoir le support pro.
Mais il y a sans doute aussi une partie du cout qui est la pour avoir un matelas et cacher le fait qu'il y a moins de pro que de particuliers, donc moins d'économie d'echelle. Ou simplement des assurances divers et variés coté Orange.
Oui, mais on pourrait dire pareil de n'importe quel cas d'automatisation.
C'est un point à prendre en compte bien sur (et je pense que c'est aussi pour découvrir ça que Axa a tenté quelque chose). Mais si quelqu'un dit "on devrait pas automatiser tel truc parce que tu peux avoir des bugs", et qu'on l'écoute, on serait encore en train de tous commander via le catalogue de la Redoute.
C'est pas forcément mature, mais je pense pas que ça va devenir mature sans essayer de mettre en "production".
Oui, mais c'est différent de dire "ça va, c'est pas si pire que ça" sans rien changer (c'est quand même nier l'évidence), et de pointer que théoriquement, les choses pourraient être autrement.
Ethereum veut passer à du Proof of stake depuis avril, mais visiblement, ça n'arrive pas du jour au lendemain, et je ne sais pas pourquoi. Et bon, si les gens font n'imp sans détruire la planète, ça me dérange beaucoup moins.
Ok, oui, mais du coup, ça n'a aucun sens vu que la question de l'ilo ne dépend même pas de l'état du serveur.
Le support niveau 1 a juste l'air d'être mauvais (ça arrive, mais bon, pareil, question de cout). Mais c'est vrai que c'est pas ce que j'avais en tête quand tu as dit "support".
De souvenir, toutes les transactions sont publiques et tu as du
genre l'information : le compte X a donné Y bitcoins au compte
Z.
Oui, sauf certaines (genre monero) qui vont essayer de faire des choses plus discrètes avec des preuves à zero connaissances. Mais je sais pas ce que les gangs demandent, ni ce qui peut être converti en monnaie sonnante.
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.
[^] # 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é à 2.
Trivialement, le fait qu'AXA ai décidé d'arreter le programme montre qu'un arret est possible. Le fait qu'AXA est pu mettre en place le programme en premier lieu montre qu'une création de code est aussi possible. Et vu que patcher, c'est arret + creation, bah, c'est possible de patcher.
Attention, je dit pas que c'est pratique, que c'est rapide, ni rien. J'ai bien conscience que c'est comme dire "on pouvait faire du cloud dans les années 90, il suffisait juste d'une armée d'admin sys pour faire les installations à la demande de distro linux à la main". C'est parce que c'est théoriquement possible que c'est pratiquement faisable (même si le fait d'avoir finalement automatisé suffisament tout montre que c'est faisable de faire du cloud).
Sauf erreur de ma part, les clients ne vont pas directement sur la blockchain d'AXA et doivent donc passer par AXA. Donc AXA est parfaitement capable de dire "maintenant, le nouveau contrat est ici", ce qui régle la question de la mise à jour. Et dire "on a un souci, on va faire à la main", ce qui régle la question de l'arrêt manuel.
Ensuite, c'est dans un cas particulier, et clairement, dans le cas d'une blockchain public ouvert à tous style ethereum ou tout le monde peut aller executer les contrats, etc, c'est un gros souci.
[^] # Re: Éligible !
Posté par Misc (site web personnel) . En réponse au lien La première ligne FTTH FDN est fonctionnelle depuis septembre !. Évalué à 4.
Le support. Quand j'appelle Orange, j'ai quelqu'un qui va comprendre ce que je dit sans suivre un scénario dans un pays ou les gens sont payés moins et dans des conditions de travail sans doute pourri.
J'ai papoté réseau et télétravail avec le technicien lors de mon dernier appel pour me plaindre du changement de prefixe d'ip v6, sans sentir qu'il etait préssurisé pour raccrocher ni rien.
Ensuite, j'ai aussi eu avant des gens qui confondent "ip fixe" et ip v6 au téléphone, donc c'est pas magique d'avoir le support pro.
Mais il y a sans doute aussi une partie du cout qui est la pour avoir un matelas et cacher le fait qu'il y a moins de pro que de particuliers, donc moins d'économie d'echelle. Ou simplement des assurances divers et variés coté Orange.
[^] # Re: Éligible !
Posté par Misc (site web personnel) . En réponse au lien La première ligne FTTH FDN est fonctionnelle depuis septembre !. Évalué à 6. Dernière modification le 09 novembre 2021 à 21:13.
C'est le tarif d'une ligne pro chez Orange, j'ai grosso modo ça (~56.4€ TTC par mois avec location de la livebox).
Donc je trouve ça plutôt pas mal.
[^] # 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é à 2.
Oui, mais on pourrait dire pareil de n'importe quel cas d'automatisation.
C'est un point à prendre en compte bien sur (et je pense que c'est aussi pour découvrir ça que Axa a tenté quelque chose). Mais si quelqu'un dit "on devrait pas automatiser tel truc parce que tu peux avoir des bugs", et qu'on l'écoute, on serait encore en train de tous commander via le catalogue de la Redoute.
C'est pas forcément mature, mais je pense pas que ça va devenir mature sans essayer de mettre en "production".
[^] # 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.
Oui, mais c'est différent de dire "ça va, c'est pas si pire que ça" sans rien changer (c'est quand même nier l'évidence), et de pointer que théoriquement, les choses pourraient être autrement.
Ethereum veut passer à du Proof of stake depuis avril, mais visiblement, ça n'arrive pas du jour au lendemain, et je ne sais pas pourquoi. Et bon, si les gens font n'imp sans détruire la planète, ça me dérange beaucoup moins.
[^] # 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.
Ok, oui, mais du coup, ça n'a aucun sens vu que la question de l'ilo ne dépend même pas de l'état du serveur.
Le support niveau 1 a juste l'air d'être mauvais (ça arrive, mais bon, pareil, question de cout). Mais c'est vrai que c'est pas ce que j'avais en tête quand tu as dit "support".
[^] # 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é à 2. Dernière modification le 09 novembre 2021 à 17:11.
Oui, sauf certaines (genre monero) qui vont essayer de faire des choses plus discrètes avec des preuves à zero connaissances. Mais je sais pas ce que les gangs demandent, ni ce qui peut être converti en monnaie sonnante.
[^] # 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.