Misc a écrit 5868 commentaires

"massive", quand on parle d'un exemple documenté, c'est quand même très provoc comme titre.

En fait, c'est même pire, vu que l'exemple détaillé, c'est f-droid, qui n'a pas accepté le code, et qu'il n'y a rien qui parle de "bullying" pour XZ (juste que le dev principal prends des pauses de temps en temps).

Je trouve ça assez dangereux cette tendance que je vois au moins sur le fediverse à créer un crime de lèse majesté envers les devs. Par exemple, quand le dev de curl a dit qu'il a perdu du temps parce que quelqu'un a utilisé chatgpt pour faire un rapport de bug incorrect, c'est tout de suite devenu "oula, chatgpt va pourrir totalement le libre en surchargeant les mainteneurs".

Et justement faire du scandale quand quelqu'un demande un truc de façon incorrect, ça me semble juste pourri, au lieu de reconnaître que même dans le libre, il y a un concept comme la relation client (vu qu'à partir du moment ou tu fournis quelque chose,ça existe). Mais bon, reconnaître qu'il y a plus que les devs qui comptent, ça serait trop une révolution, et à la place, on flatte l'égo pour continuer à les faire bosser gratos.

Mais le board d'Almalinux semble plus indépendant que celui de la RESF, et travaille pour découpler les 2 depuis le début. Le patron de CloudLinux n'est plus le chef du board, même si il est encore présent comme invité, et comme trésorier, une tache chiante mais importante. Si on regarde le board maintenant, on est plus dans la situation de 2021 avec une majorité venant de CloudLinux.

Et comme tu dis, CloudLinux est une boite qui marchait avant ce qui retire à mon avis la pression qui existe sur CIQ. De plus, vu qu'Almalinux s'autorise des modifications vis à vis de RHEL, il y a de la place pour avoir une communauté de contributeurs (ce qui toujours manqué à Centos, vu que la réponse était "on touche pas, faut aller voir RH").

Bon, je me réponds à moi même, vu que je me suis trompé.

1) CIQ est passé de 77 à 100 personnes en ~1 an. Donc elle est encore en croissance d'aprés le seul chiffre qu'on peut voir facilement, le nombre d'employés approximatif sur Linkedin.

2) CIQ a eu un round de financement de 10 millions via SUSE il y a 1 an.

Du coup, ça rends d'autant plus curieux le fait de ne pas avoir choisi d'avoir du capital risque, car si la boite est encore en croissance (+25% de personnel), mais passe par ses concurrents pour se financer, c'est une manœuvre assez surprenante.

On va voir si CIQ trouve du capital dans les mois qui suivent ou pas.

Ça prouve une chose: Rocky Linux est une distribution qui compte et comptera à l’avenir,

Pour l'avenir, j'ai perso un peu de doute, car ça semble la moins bien lotie sur le marché.

Pour commencer, le dit marché est assez encombré. Il y a SUSE, Oracle EL, Alma, RHEL et Centos Stream. On peut séparer ça en plusieurs groupes:
- les distros qui ont pas trop besoin de faire d'argent, comme Alma et Centos Stream. Aussi longtemps que quelqu'un paye/contribue, elles ont des chances d'être la.
- les distros qui sont la pour faire de l'argent, mais sans trop de pression . OEL, RHEL, Suse rentre la dedans.

et finalement Rocky, qui est ni dans l'un, ni dans l'autre.

Rocky est largement financé par CIQ (c'est un peu le sujet du lien). Il n'y a rien de mal à ça, les autres sont globalement dans le même bateau. Par contre, la différence, c'est que CIQ a besoin de faire des thunes, vu qu'ils ont des investisseurs et ~100 employés.

Si je suppose le coût d'un employé à 100k $ par an pour la boite (ce qui me semble relativement bas pour les US, mais je prends ça pour donner un ordre de grandeur, et parce que 100k est un chiffre rond plus facile à calculer pour mon petit cerveau), les dépenses de CIQ sont au minimum de l'ordre de 10 millions par an pour les salaires (100 employés d'aprés Linkedin). Donc l'apport de capital propose au maximum ~2.5 ans de financement avant de devoir être à l'équilibre. Le dernier deal en série A a été fait en mai 2022. Normalement, si tu es une startup en pleine croissance, après 1 an, tu refais un round (soit série A à nouveau, soit série B, il y a une différence, mais je suppose que ça change pas grand chose en pratique) pour soutenir la dite croissance.

Par exemple, Gitlab a fait sa série A en 2015, la série B en 2016. Mongodb a fait 1 round de financement par an en 2010/2012. Pareil pour redis (sous le nom de l'époque). Le rythme est relativement bien établi de ce que j'ai vu.

La, CIQ n'a rien fait (pour le moment et que je sache). Soit les investisseurs estiment qu'il n'y a plus de croissance possible (ce qui expliquerais que le nombre d'employé n'augmente plus, vu que c'était aussi 100 y a quelques temps quand j'ai regardé)), soit il y a des conditions macroéconomiques qui rendent ça plus compliqués. Dans les 2 cas, ça serait signe qu'il faut arriver à l'équilibre à moyen terme.

Si les investisseurs avaient besoin de pousser à la rentabilité, on le verrait, par exemple, des projets libres passeraient sous licence proprio à la pelle, avec des limitations sur les trucs gratuits, etc.

On le verrais aussi avec CIQ, qui tenterait le même genre de maneuvre que Redis/Hashicorp.

Donc je pense que je suis assez confident dans mon analyse sur le besoin de rentabilité de CIQ à court/moyen terme. Sauf que le souci, c'est qu'ils sont coincés avec une offre de valeur qui est d'être une RHEL discount face à des distros qui sont moins cher et/ou mieux financés pour le long terme, et dans tout les cas, avec moins de pression.

Ça ne veut pas dire que CIQ va mourir demain ou après demain, Canonical l'a montré, tu peux survivre longtemps sans être à l'équilibre. Mais bon, de tout le lot, c'est quand même Rocky Linux qui semble le plus à risque car son sponsor principal semble l'être.

Faut aussi voir ce que les gens appellent IA (vu que de nos jours, la majorité veulent dire "un truc comme chatgpt", voir parfois "les IA génératives en général", mais tu va rarement parler de l'IA au sens que ça a depuis les années 60 et après.

Genre, l'IA dans Halflife, ça sert :p

C'est pas terrible, mais parfois, c'est ça ou revenir 2 ans plus tard en étant devenu capable de lire :/

Ensuite, y a une discussion sur le fait d'avoir le site qui le fait une fois, ou le lectorat qui le fait plus d'une fois.

Et en général, je trouve qu'en effet, les traductions automatiques de documentation (GCP par exemple) sonnent souvent fausses et formulaique, je repasse toujours en anglais.

Perso, je trouve en général pas ça super drôle. Je suis content que depuis la pandémie, on fait vachement moins souvent ce genre de blagues, mais je ne pense pas que je soit devenu plus grognon qu'avant.

Depuis que c'est devenu une fête commerciale, c'est moins bien :p

En fait, vu qu'on sait que ça tombe le premier avril, on est moins souvent surpris, et à l'époque des fausses news, je trouve que ça devient finalement pas super.

On peut surtout se demander pourquoi les builds de projets simples sont aussi compliqués.

Sans doute parce que les projets ne sont pas aussi simples que tu semble le postuler. XZ est une lib, une CLI, des tests, une codebase qui a plusieurs parties en assembleur sur divers plateformes matériel, avec une version spécifique pour l'embarqué.

C'est pas exactement un lib avec uniquement 2 fonctions.

maintenant, comme l'a dit Linus, talk is cheap, donc je suis sur que xz attends tes patchs pour montrer comment faire mieux.

C'est marrant, parce que je me dit "tiens, j'ai du poster dans ce fil de commentaire", et en effet, je soulignais déjà le risque de remplacer les tarballs:
(cf https://linuxfr.org/nodes/111615/comments/1697357 )

Je note aussi que le compte qui a posté le thread n'a plus jamais posté depuis 7 ans, donc ça colle aussi avec les discussions en cours sur l'épuisement des bénévoles, et aussi sur les gens qui débarquent de nulle part.

Meilleur poisson d'avril pour le moment

Si tu cherches des montres avec un écran e-ink, alors watchy est faite pour toi.

Faut dire que la dernière fois qu'il s'est occupé de la restauration, ça s'est pas super bien fini.

Et c'est pour ça qu'il y a aussi Pâques juste après, car Jésus est revenu après nous avoir tous sauvé ?

Je ne le crois pas. La majorité des projets sont globalement la même chose, je ne crois pas qu'il soit nécessaire de lancer doom dans son système de build. Réinventer un build pour chaque bibliothèque est un échec d'ingénieure.

La majorité, oui, mais je pense que tôt ou tard, tu va tomber sur un cas non géré, et la question de comment gérer ça se pose. Par exemple, si tu veux rajouter le support d'un nouvel outil pour transformer la doc. À partir de la, soit tu as tout dans le core de ton outil (et ça explose de complexité), soit tu as des plugins. Et si tu as des plugins, alors tu ouvres la porte à des dérives (comme tu dit, M4 peut muter le systeme de build, mais c'est le but, sinon ton systéme de build est figé et ça pose d'autres soucis).

Bien sur, tu peux aussi dire merde, mais en général, tu n'es pas populaire quand tu fait ça.

Je pense qu'un bon DSL serait mieux que du shell a tout bout de champ, mais on a des tonnes d'outils de build dans le logiciel libre, et on tombe toujours dans les mêmes travers, donc peut être qu'il faut se demander pourquoi.

C'est vrai, je ne sais pas à quel point c'est utilisé dans debian, la plupart des paquets ne devraient pas en avoir besoin du tout (dès maintenant) et pour les autres cartographier les cas (ajout de modules dans le noyau, ajout d'une police,…) pourrait réduire à peau de chagrin les cas où c'est utile.

Debian ne me parait pas le bon exemple, vu que la communauté à tendance à parfois chercher à corriger des fichiers de configs, etc. Sur un serveur que j'ai depuis longtemps, je compte 716 scripts:

 $ ls /var/lib/dpkg/info/*.post* | wc -l
716

Je sais que des gens de Fedora ont bossé pour convertir beaucoup de script à des trucs automatiques (les fameux file triggers), pour par exemple lancer ldconfig quand tu installes une lib, faire ce qu'il faut avec systemd quand tu installes un service, etc.

Et je pense que dpkg supporte ça aussi, mais j'ai plus fait de paquet rpm et debian depuis longtemps.

Et aussi longtemps qu'on voudra avoir des upgrades de paquets sans perte de données, on va devoir utiliser des scripts (exemple, upgrade de postgresql).

Ensuite, si un jour, on veut passer à des déploiements via des images ostree et/ou des conteneurs, il va bien falloir se débarrasser des scripts en question, car ça ne rentre pas dans le workflow.

Non pour ssh dont le but est quand même de lancer des processus arbitraires avec des permissions arbitraires, oui pour xz, mais c'était pas le vecteur d'attaque principale.

Pour moi tu as besoin que chaque brique ai une vocation spécifique de la quelle elle ne peut pas sortir. Ça réduit considérablement ton scope et rend l'analyse bien plus simple.

Le souci, c'est que compiler un logiciel, c'est fondamentalement de l’exécution d'un script qui lance des commandes. Tu devoir lancer des commandes arbitraires pour divers étapes, donc il y a toujours un risque que ça soit un peu open bar.

Avoir un fonctionnement déclaratif est parfait pour ça. Je suis intimement convaincu que l'énorme majorité des projets pourraient utiliser un paradigme déclaratif pour leur build, mais soit n'ont pas le bon état d'esprit soit ont une forme d'ego pensent que leur projet a une spécificité.

Je suis d'accord qu'on peut faire mieux, mais tu as le risque de multiplier les DSL si tu limites trop, ce qui est déjà aussi un probléme, on a un DSL pour le Makefile, un DSL pour générer le fichier configure, basé sur un autre DSL via M4, le tout qui produit un script avec des idiomes spécifique pour être portable.

Et encore une fois, il faut voir comment il y a eu une levée de bouclier quand on est passé d'un mode script (sysVinit) à un mode déclaratif (systemd) pour l'init, avec des gens défendant l'écriture de shell scripts. Je suis assez pro-systemd et pro-déclaratif, mais je ne pense pas que la dite levée de bouclier était une question d'ego ou d'état d'esprit. C'est pareil pour les gestionnaires de paquets pour distro, sauf erreur de ma part, y en a aucun qui n'a de possibilité de faire des scripts.

Et un dernier souci, c'est à mon avis la difficulté à imposer une norme dans certaines écosystèmes comme le C. C'est en effet bien mieux dans Rust ou Go, mais même la, tu as des échappatoires comme le build.rs (et rien en Go, que je sache).

Je blamerais pas le fait d'avoir 25 langages, mais plus d'avoir du partir sur le shell comme socle commun (et un shell portable sur X OS différents, comprendre, un peu dégeu). Au final, y a que un DSL basé sur m4 et le shell, non ?

Comme tout le monde, je fait du shell de façon régulière, mais faut quand même reconnaître que ça devient assez vite cryptique et qu'on a pas trop le choix (au contraire de perl, où on peut faire cryptique, mais où on peut aussi éviter ça).

https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b

semble donner plus d'info

je trouve ennuyeux que les systèmes d'authentification utilisent des bibliothèques dynamiques (i.e. PAM) au lieu d'avoir un daemon qui file les descripteurs de fichiers via AF_UNIX comme le font plan9 ou OpenBSD (enfin, c'est ce que j'ai compris).

Tu veux parler de sssd ?

Mais autoconf est complexe parce que ça supporte des tonnes d'OS obscure, et un des reproches fait à systemd, c'était justement de ne pas tout supporter, donc faudrait savoir :p

pas sur ma Fedora Silverblue (sauf si je m'y prends mal):
$ rpm -e --test xz-libs-5.4.4-1.fc39.x86_64 2>&1 | grep -i seli
$

Par contre, c'est utilisé par libxml2, donc techniquement, n'importe quoi qui parse du XML serait accessible à la backdoor.

Perso, j'avais plus en tête les compromissions des paquets de distros, qui sont signés par les distros, donc c'est un peu plus compliqué que "compromettre un dépôt et signer". Par exemple, sur Fedora, la clé de signature est dans un HSM.

Mon cas, c'est celui d'un attaquant capable de faire un MITM et qui va attendre la mise à jour de la cible, puis rajouter son paquet avec une signature qui marche tout le temps, vu que lzma a backdooré le processus de signature pour dire "ça roule ma poule" (ou directement exécuter du code qui vient depuis le fichier lzma).

https://tukaani.org/xz-backdoor/

Mais dans le cas de AD, c'est sans doute juste la complexité organisationnel des entreprises qui se retrouvent dans le fouillis de l'annuaire. C'est rien de nouveau, ni rien d'étonnant, et je ne pense pas qu'on puisse blâmer que Microsoft pour ça. Quand pour des raisons X ou Y, tu te retrouves avec 250 filiales, des gens qui bougent entre elles, etc, forcément, ça devient un peu le bordel.

Mais lzma est aussi utilisé pour les gestionnaires de paquets. Si le souci n'avait pas été sur ssh, une attaque valable aurait pu être faite sur dpkg et rpm, des outils qui 1) exécute du code venu de dehors 2) en root.