Misc a écrit 5840 commentaires

Je suppose que l'UE a aussi des processes que n'ont pas les gens sur leur temps libre. Il faut bien voir qu'il y a la plateforme (Mastodon, Peertube), mais sans doute aussi les backups, des audits, l'intégration avec l'existant (vu que le contenu est le même que sur les autres réseaux sociaux), la formation pour les équipes de communication, etc.

Il est possible aussi que le projet soit à l'origine d'une personne, et que cette personne soit parti.

L'EDPS (le DPA des institutions européenes) avait lancer 2 pilotes dans le fedivers via un serveur mastodon sous le nom EU Voice ( https://social.network.europa.eu/ ) et un serveur peertube sous le nom EU Video ( https://tube.network.europa.eu/ ). Les pilotes devaient durer 1 an, ils ont tenus un an de plus.

Les 2 services vont s’arrêter le 18 mai 2024. L'annonce dit "on a montré qu'on pouvait le faire, mais on a pas les ressources pour maintenir ça". Si je traduit ça en langage moins diplomatique, c'est sans doute une question de maintenance système (donc faire les mises à jours logiciels) par rapport aux nombre de visites.

Par exemple, si je compare la chaîne peertube avec la chaîne Youtube d'une agence au pif, il y a pas exactement foule qui va sur la version peertube. On va me dire qu'il y a pas foule non plus sur l'autre, mais quand même 4 fois plus sur certaines vidéos.

Donc bon, je suis un peu triste, car j'étais abonné à plusieurs flux, notamment celui de la CJUE. Mais à coté, ça ne m'étonne pas, le flux de la FRA (Fundenmtal Rights Agency) est cassé depuis plus de 6 mois, et personne n'a réparé quand j'ai signalé (mais on a accepter mon signalement).

C'est intéressant parce que ç'est un texte qu'on a tendance à oublier, mais il faut aussi reconnaître que ça a tendance à être mal défini, notamment sur la question de l’intérêt supérieur de l'enfant.

Par exemple, la droite sénatoriale française en ce moment cherche à interdire les traitements pour les mineurs trans. Pour moi, ça contredit l'article 2 qui dit "Les Etats parties s'engagent à assurer à l'enfant la protection et les soins nécessaires à son bien-être", et je me base sur les études sur le sujet, comme "La prise en charge des enfants, adolescentes et adolescents transgenres en France : controverses récentes et enjeux éthiques", avec 27 études citées à un moment du paragraphe 2 qui montrent le bien fondé du traitement (lien que j'ai trouvé sur WP).

Mais quand on regarde l'origine du discours de la droite, on retrouve les 3 mêmes psychanalystes qui font du bruit depuis 3 ans (je simplifie grandement, il y a aussi la Russie et la droite américaine), et on voit qu'elles se positionnent aussi dans la défense des enfants comme l'explique Eric Fassin quand il dit: "In parallel with the defense of women in the name of feminism, anti-trans attacks soon started focusing on the protection of minors" (suivi des 3 pages d'argumentaires).

Donc bon, ça montre bien que le concept de "droit supérieur de l'enfant", ça s’accommode à toute les sauces si on peut dire tout et son contraire.

Autre exemple, la Manif pour tous (nouvellement renommée en Syndicat de la famille) avait aussi utilisé l'intérêt supérieur de l'enfant dans ses discours comme on le voit sur les affiches de l'époque notamment celle du 2 février 2014 pour s'opposer à l'adoption par les couples non hétéros (et à la PMA/GPA).

Car c'est bien connu, l’intérêt supérieur de l'enfant, c'est de rester à la DASS plutôt qu'avoir une famille un peu différente, malgré les études montrant que ça ne pose pas de problèmes. Ou de ne pas naître.

Et bon, je ne le pointe pas en détail parce que ça serait trop facile, mais le cliché de "Think of the children" est quand même aussi fondé sur ça, et pareil, ça sert pour tout.

L'idée est bonne, mais l’exécution par le grand public est quand même bien trop souvent foireuse, et c'est pas quelque chose qu'on voit avec les autres grand principes du même genre (qui pourtant se contredisent allégrement dans pas mal de cas).

Du coup, tu as des batailles philosophiques, juridiques, informatiques, etc., et tout le monde pense être dans son bon droit.

Je serais beaucoup moins généreux. La question est surtout "quel contrôle doit avoir l'état via son appareil judiciaire sur la communication politique". Et c'est une question curieusement compliquée, car d'un coté, une communication politique, c'est pas censé être un passe droit complet (on peut voir les nombreuses condamnations de Zemmour ou Le Pen, par exemple). Mais de l'autre, la non-ingérence de l'état, c'est aussi un principe à respecter (voir les lois récemment passé en Géorgie (le pays en Europe, pas celui des USA).

Donc y a un compromis, un truc que la plupart des ingés sont censés comprendre sauf quand le cerveau est débranché.

mais je trouve assez surprenant qu'on puisse être amenés à penser qu'il est naturel de n'être joignable que par des correspondants identifiés.

Perso, ça me surprends pas, non. Je pourrais mettre un pâté sur les liens entre certains idées du libre, les courants libertariens US, etc, mais ç'est un peu trop pour le début de la semaine.

Et d'ailleurs, c'est bien connu, on a jamais eu de massacre avant l'invention des ordinateurs. Les Hutus avaient tous des ipads avec un tableur excel pour savoir qui tuer, les catholiques se sont coordonnées via un CRM en 1572, etc, etc.

Je trouve ça quand même assez problématique la tendance à passer de "recevoir un email du PS" à trucs du genre "ça va être comme la Reichskristallnacht" sans contextualisation ou quoi que ce soit. C'est un vachement populiste et manipulatoire comme rhétorique.

Sauf erreur, il n'est pas possible de récupérer la liste des entrées DNS d'un domaine. Il faut déjà connaître le nom de machine pour obtenir l'ip.

Ça dépends, tu peux pas choper le DNS, mais tu peux regarder la liste des certificats publiques. Donc par exemple, tu peux voir si tu as mis un serveur smtps, un site web (avec une appli de ton choix), etc.

Ou un cas comme celui la:

https://www.lemonde.fr/pixels/article/2024/04/17/comment-sandworm-les-hackeurs-d-elite-de-l-armee-russe-ont-pirate-un-moulin-francais-en-pensant-attaquer-un-barrage_6228320_4408996.html

une règle élémentaire voudrait que l'on arrête tous le SI en cas de doute d'une intrusion, qu'elle soit d'importance minime ou très importante

et ça se conjugue comment avec la règle de "on ne touche pas pour l'analyse des systèmes" car éteindre les machines, ok, mais ça efface aussi parfois des traces, donc la règle n'est pas si élémentaire que ça.

Certes, c'est un abus de langage d'en parler au singulier.

Bref, des gens qui se lancent des fions au lieu de coder :)

Pourtant, je pense que ce qui fait que la communauté autour du logiciel libre réussit, c'est la communauté plus que le logiciel. Ce dernier n'existe pas sans la communauté, donc c'est crucial de s'assurer que la communauté va bien. Une personnalité qui clashe trop va avoir un effet délétère qui s'accumule sur le long terme.

Je ne suis pas sûr de ce que tu appelles une socket abstraite, je n'ai pas souvenir avoir vu cette notion avant?

C'est ma traduction des termes utilisés dans man unix(7), mais je suppose que c'est moins clair si je précise pas "une socket unix abstraite", par opposition aux sockets qui peuvent être réseau, etc. De ce que je comprends, un socket unix abstrait, c'est juste un socket avec un nom, mais qui n'est pas sur le FS.

Le seul exemple que j'ai trouvé, c'est dans calibre (je crois). Avec lsof, ç'est comme une socket unix, mais le nom commence par @.

C'est par opposition aux "pathname" socket, qui sauf erreur de ma part, sont visibles sur le FS. C'est une fonction spécifique à Linux, donc c'est peut être peu utilisé.

Et pour rappel, même si je me doute que tu le sais, avoir un système de fichiers ne nécessite pas d'avoir un périphérique de stockage local, typiquement NFS et les ramdisk sont très utiles pour ça

Bien sur, mais ça arrive aussi après le montage du réseau, et tu peux imaginer que le montage passe par un ou plusieurs demons (genre, un VPN, dhcp, etc, tout les trucs pour se faire des noeuds au cerveau), demons qui ont besoin de de faire un notify, donc d'avoir un socket/pipe/etc.

Je suis quand même peu convaincu par l'idée que créer un pipe par daemon serait lourd

Pour des opérations normales, ça passerais. Par contre, si tu veux lancer des milliers de services (genre, des VPS comme le faisait Pantheon, un des sponsors de systemd à l'époque), ça peut rajouter de la charge inutilement (ne serait que pour faire une boucle sur tout les FD avec select par exemple, même si je suppose que le kernel a peut être des optims à ce niveau).

D'un autre côté, je ne vois pas comment exécuter un programme sur un FS sans supporter de FS au préalable,

Tu peux exécuter un programme sur un FS en lecture seule, alors que je suis pas sur que tu puisses créer un pipe/socket nommé sans un endroit ou écrire (donc avant le montage de /tmp ou /run).

Ceci dit, c'est sans doute improbable que ça soit ça.

Pareil pour un socket si ma mémoire est bonne. Les pipes ne sont pas forcément nommés, mais un pipe non nommé serait plus intrusif.

Dans mon souvenir (mais rien ne semble aller dans mon sens sur stackoverflow ou la doc), plusieurs clients qui écrivent sur un pipe peuvent interférer les uns avec les autres (vu qu'il n'y a qu'un seul FD pour lire pour tous. Donc ça voudrait dire ouvrir 1 pipe par process pour être sur de ne pas avoir de race condition, et ça me semble sous optimal pour la scalabilité.

Alors qu'avec une socket en mode datagram, tu n'as pas le souci vu que le kernel s'occupe de séparer les messages par client et tu as le pid en plus (et donc, tu peux chercher le pid dans le cgroup pour savoir quel service est ready).

Après réflexion, c'est sûrement la raison, plus que mon histoire de montage en RO sans /tmp/ ou /run/.

Mais ceci dit, tu peux aussi passer par une socket abstraite (sous Linux) qui n'est pas sur le disque, et donc la passer via une variable d’environnement, donc même si c'est pas la raison, ç'est peut être un bonus.

Mais sur les 150, combien n'utilisent que sd_notify et pas le reste (comme les api pour journald etc) ?

Par exemple, je suis sur que syslog-ng utilise des fonctions lié à journald, ne serait que pour lire le dit journal.

De même, rust-libsystemd ou python-systemd doivent exposer libsystemd pour les programmes qui les utilisent, donc devrait être retiré de la liste.

Même si je pense pas que ça va changer grand chose (car même 50 duplication, c'est pas cool), je pense qu'il faut quand même relativiser cette liste.

Je pense qu'un pipe, ça implique aussi d'avoir quelque chose pour écrire le fichier, donc ne serait utilisable qu'à partir d'un certain moment du boot, et c'était peut être une contrainte à éviter ?

Une solution serait de faire une macro C qui est dans un .h.

Comme ça, pas de lien avec la lib de systemd au runtime, pas de souci de logistique sur 50 libs, pas de changement énorme coté systemd.

Si j'ai bien compris ce commentaire sur Github, systemd ne réduit pas ses dépendances, mais les charge dynamiquement avec dlopen au moment où elles sont nécessaires.

Mais dans le cas de sshd, ou il n'y a pas besoin d'autre chose que d'écrire sur un socket pour l'intégration avec systemd (chose qui pourrait être fait via une macro dans un .h), ça va réduire la surface d'attaque.

Si ensuite tu as une fonction qui demande à écrire ou à lire du xz, que ça vienne via systemd ou autrement, tu as besoin de la lib. Tu peux te poser la question de savoir si l'écriture/lecture de xz est requise, mais ç'est indépendant de systemd.

ça paraît légitime d'espérer que Microsoft y mette un peu du sien.

Bien sur, mais est ce que ffmpeg a la structure pour ça ?

Car sortir de l'argent dans une grande boite, c'est aussi un marathon en soit. Mon employeur, qu'on peut difficilement accuser de ne pas contribuer, ou de ne pas connaître le logiciel libre, n'est pas capable de payer pour ce genre de maintenance autrement qu'en embauchant une personne à temps plein pour ça. C'est un peu une solution lourde qui ne passe pas à l'échelle.

Par exemple, on ne peut pas mettre des thunes dans un Patreon, un Github sponsor ou un Open Collective pour divers raisons juridiques et fiscales. Même quelque chose comme "choper un consultant" va être compliqué.

Et bon, pour Microsoft, je rappelle qu'ils sponsorisent Github. Certes, ça n'impacte pas ffmpeg directement, mais on passe assez rapidement sous le tapis le pognon qu'ils mettent dedans et dont beaucoup de libristes bénéficient. Sauf que commencer à dire ça, ça devient vite tendu pour savoir "qui mérite quoi".

le terme "enshittification" a le mérite de remplir cette fonction.

Mais comme tu dis, les concepts existent depuis toujours en droit de la concurrence US (vu que c'est ce dont on parle). Sortir un nouveau terme ne permet pas de connecter le concept à son histoire. Et on voit clairement que le terme est soit mal compris, soit appliqué de façon qui ne correspond pas à ton analyse.

Par exemple, dans l'article de Ploum, l'auteur connecte le terme d'enshitification aux choix de couleur dans les films (on est quand même assez loin de la non concurrence que tu énonces), ou aux scénarios. Il précise même à la fin qu'il y a "pas grand chose à faire", sous entendu "presque pas de responsabilité". Il n'y a pas d'appel à boycott, d'appel à demander aux autorités de la concurence, pas de s'organiser en assoce de consommateur.

Par contre, l'article précise bien que "Prendre conscience de cette merdification, la nommer est une étape importante". On peut donc voir que ce que Doctorow (et Ploum via la traduction) est important et que discuter du concept aussi. C'est marrant comme l'importance des actes est aligné exactement avec les intérêts des 2 personnes qui suggèrent quoi faire.

On noteras aussi que l'analyse ne connecte pas le terme aux pratiques monopolitiques du passé, vu que l'article détaille des pratiques modernes du monde de la finance.

Et si on regarde les commentaires sur Linuxfr, on voit aussi que l'audience est assez critique sur le coté "ç'était mieux avant" du terme, ce qui montre aussi qu'il y a la perception qu'il est déconnecté de l'histoire, et que c'est peut être ça qu'il faut faire plutôt que de réduire l'idée à un terme mal défini mais de taille idéal pour devenir viral.

Ben, c'est même pire: avec la décentralisation, il est difficile de pointer sur toutes les instances qu'un document joue délibérément sur l'affect, la persuasion, au lieu d'être objectif et convainquant.

Je pense que la décentralisation n'y est pour rien, vu que même sur X/FB/insta, ton audience est fracturé, chacun a une vue différente de son flux, et l'audience n'est pas sur de voir ton contenu.

C'est centralisé à un niveau technique, mais individualisé à un niveau pratique. Le fediverse masque ça un peu, mais pas spécialement beaucoup.

Et c'est une conséquence de ce que tu énonces sur la massification de la communication, vu qu'il y a trop de contenu produit pour ne pas le filtrer lourdement.

? Par exemple, la sensation que tu ne peux pas contacter les devs. Tu trouves ça attendu (voire normal) d'avoir une backdoor dans le logiciel s'il est proprio ?

Tu peux étendre ça à plus que les logiciels proprios, ç'est pareil pour les SaaS. Mais la différence est qu'avec un logiciel proprio (ou une SaaS), c'est qu'il y a de facto une relation marchande assumée la plupart du temps (sauf pour les trucs gratos), et que même si les éditeurs cherchent à évacuer leur responsabilité comme tout le monde, il y a divers lois qui s'appliquent, et je ne crois pas que l'idée que le client puisse aller se faire voir soit fondatrice dans la relation en question, quoi qu'on puisse croire. Donc au moins les choses sont clairs. Je préfère le logiciel libre, mais pour la liberté qu'il me procure et que je suis en mesure d'utiliser, pas pour d'autres raisons.

Ensuite, en pratique, je suppose qu'on paye rarement assez pour un logiciel proprio pour que ça change grand chose. Mais après avoir eu des soucis avec divers services clients, j'ai décidé de payer ma connec internet 62€ (ligne pro) et pas 40€, j'ai décidé de boycotter Ryan Air et les low costs pour prendre Air France, etc.

Et non, je m'attendrais pas à avoir une backdoor non plus dans un logiciel proprio dûment procuré (cad, pas sur un site de warez), même si la question de ce qui est une backdoor reste ouverte. Je fait parti de la minorité qui pense que si une carte iDrac n'est pas une backdoor, alors Intel AMT non plus.

Je t'avoue ne pas compris le sens de cette phrase. Dédouaner les gens de quoi ? Remettre la responsabilité où ?

Bah, quand Cory Doctorow parle de "enshitification", il nomme un phénomène où une entreprise va filer quelque chose gratos et/ou à bas prix, puis une fois qu'il y a assez de monde, ça devient moins bien pour les utilisateurs.

Sauf que dire ça, c'est dédouaner les utilisateurs d'avoir collectivement choisi de tuer la concurrence en prenant le même truc (eg, l'offre de l'entreprise qui se retrouve en position forte sur le marché) et d'avoir collectivement pris le truc le moins cher. Ça positionne aussi implicitement l'utilisateur comme un client qui est roi, vu que tout doit aller dans son sens.

C'est une position assez égocentrique qui positionne un méchant simple et unique (genre "le capitalisme"), et c'est pas étonnant que ça résonne, vu que ça flatte l'utilisateur en le plaçant comme quelqu'un qui n'a rien fait de mal malgré le fait qu'il est un rouage essentiel du système décrit.

Et donc en tant que rouage, je pense que les utilisateurs ont leur part de responsabilité dans les choix qui sont fait (notamment le choix de dépendre des offres gratos propulsé par les investisseurs en VC).

Mais ça n'invalide pas pour autant un autre attendu tacite du dev qui est de lui parler avec un minimum d'empathie.

Bien sur, mais pas parce qu'il est dev, mais parce qu'il est humain. Qu'on te parle avec empathie n'est pas quelque chose que tu achètes avec du code que tu mets à disposition de façon gratos.

Quand un quelqu'un de Microsoft dit: "

Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help

Ça me semble poli, ça me semble pas manquer d'empathie. La personne semble en galère et ne connaît pas le logiciel libre, ça arrive. Pourtant, y a quand même Korben qui fait tout un paté, et la pauvre personne va peut être avoir des emmerdes, voir se faire virer (sans doute pas, mais bon).

Ou est l'empathie à ce niveau la ? En quoi on se dit que parce que Microsoft est une grosse boite, alors on peut se foutre de la gueule des employés pour faire le buzz (et donc de l'argent) ?

Je trouve le contenu de l'article "intéressant".

Il est écrit par Matthew Hodgson, mais l'article parle d'Element sans préciser que l'auteur est PDG et fondateur de la boite, presque comme si c'était une entité dont il n'est pas responsable. Il explique que les gouvernements ne veulent pas payer pour la maintenance, mais l'article dit que l'OTAN et d'autres utilisent Matrix, et ne dit pas qu'ils payent Element pour ça aussi (ce qui est un peu malhonnête à mon sens).

Alors on va me dire "on ne sait pas", mais vu qu'ils sont listé sur la page de la boite dans un carrousel de logo, je suppose que c'est des clients. Si ensuite, Element mets les logos pour dire "L'OTAN utilise Matrix" sans préciser "mais pas avec nous", c'est malhonnête d'une autre façon, car ça entretient la confusion entre Element (la boite) et Matrix (le protocole et la fondation), et c'est pas terrible. Et ça fait croire qu'ils ont ont des clients qu'ils n'ont pas, qui serait aussi un peu trompeur.

Et si le souci est qu'il y a trop de fonctionnalité sur Matrix pour être maintenable (comme l'indique le mème collé dans l'article), peut être qu'il faut se poser la question de qui payent des gens pour coder des choses qui prennent trop de temps de maintenance. Je suis sur que Github peut donner des stats, et je suis sur qu'on peut trouver quel entreprise à ce plan diabolique de rajouter des fonctionnalités pour que ça prenne trop de ressources pour être maintenu.

Mais au delà des critiques sur le fond, je trouve aussi la forme assez problématique.

J'irais même dire que c'est un peu indécent qu'une boite de ~120 personnes (d’après Linkedin) avec des clients gouvernementaux et divers bouts de l'armée US vienne profiter d'une affaire qui implique un volontaire non payé pour faire un pitch sur "les gouvernements devraient nous filer des thunes sans conditions pour la maintenance de notre produit principale" (car oui, la maintenance, c'est sur le code de Synapse et des clients, qui n'est plus dans la fondation, pas sur les specs qui n'ont pas besoin de bouger).

C'est la même boite a rapatrié le code dans son org github après avoir changé la licence de BSD vers AGPL avec un CLA (dans le but de vendre des exceptions à la licence, et dans le but de faire chier des concurrents comme on lit entre les lignes ).

C'est bien de dire "faut investir dans l'infra" et "les plus gros projets ont besoin de plus de thunes".

Mais je trouve rien sur un don à Debian alors qu'ils ont facile 30 VM avec juste pour l'infra du projet (cf le post mortem de 2019. Je ne trouve rien en donation à la PSF, qui est aussi responsable d'un gros projet dont Synapse et le reste du code dépend.

Je précise que je demande pas de donner car si les finances ne sont pas terribles, ça serait contre productif, mais je note quand même la contradiction de faire le choix d'offrir une infra gratos (aka, matrix.org) pour des questions de croissance du réseau, dee prêcher dans le fait de financer les briques de base, puis d'être dans une boite qui fait le contraire.

Si Element n'arrive pas à être à l'équilibre (car c'est finalement le propos), c'est peut être aussi à cause des choix fait par la direction, comme "rajouter une tonne de features à toute vitesse" pour rattraper les concurrents comme Discord, Slack (avec comme effet négatif d'avoir 0 clients alternatifs capable de suivre), "coder 2 serveurs en même temps" (car le premier était dans un sale état à l'époque) ou "faire des offres à des prix presque coûtant" (et donc ne pas être à l'équilibre, ou encaissé l'inflation). Pas uniquement parce que les gouvernements ne veulent pas payer en période de disette économique.

Parmi d'autres soucis, j'ai vu que Element n'était pas vraiment prêt pour la vente à des entreprises de taille substantielle (comprendre avec des juristes et des process lourds) vu qu'il a fallu 1 an pour avoir le contrat avec Fedora via mon employeur il y a ~2 ans.

J'ai aussi vu en posant bêtement la question de l'application des ToS de Discord et Slack pour les bridges que visiblement, ce genre de choses n'avaient jamais été envisagé, donc qu'il y avait 0 juriste. Je rappelle que les ToS de Slack interdisent l'usage des API pour faire de la concurence, ou faire un produit similaire et d'autres trucs. J'ai posé la question à un évangéliste à la fin de sa présentation, il a tourné son regard un peu paniqué vers la DG qui était dans la salle, DG qui a dit (dans mon souvenir) "c'est vrai, on devrait se pencher sur ça".

C'était en novembre 2022, soit 5 ans après la création de la boite, et presque 10 ans après le lancement du projet. Ok c'est une boite de tech, mais je suis aussi tech, et j'ai lu les ToS, et personne n'a jamais fait la remarque avant ?

Tout ça pour dire que le post de blog me laisse un arrière goût désagréable.

Que la licence dise "on garantit rien" ne change rien au fait que pour tout le monde, quelque chose existe (et je vais pondre un pâté car je suis en congé ce vendredi, je sais que mes fans se posent la question).

Quand j'utilise un logiciel libre, je m'attends par exemple à ce que personne ne rajoute de backdoor ou de fonction qui efface un fichier au pif à chaque lancement. Pour moi, ça fait parti du contrat social du logiciel libre. Je m'attends pas à ce qu'on me fournisse un logiciel défectueux à dessein, et c'est d'ailleurs pour ça que tout le monde est choqué par la backdoor xz.

Si il y avait vraiment 0 garantie et que tout le monde était d'accord avec ça, alors personne de cohérent ne penserait qu'il y a un souci avec ce qui est arrivé avec XZ, car personne n'estimerais avoir la moindre espérance d'avoir la garantie que le code est non malicieux.

Que je sache, personne n'a amené l'argument, ce qui prouve pour moi que pour la grande majorité, on a des attentes, à savoir "pas de backdoors" parmi tant d'autres. Alors certes, il y a une différence entre "0 responsabilité" et "responsable de tout", mais mon point, c'est qu'on est pas dans le "0 responsabilité". On peut discuter des nuances ensuite, mais c'est pas du tout ce qui est discuté via l'article de 404media et le reste du monde (eg, pas juste nous deux ou le débat intellectuelle sur linuxfr).

De la même façon on a beau dire "c'est autorisé par la license BSD", beaucoup de gens sont choqués par les agissements de Redis, etc. Ils ont le droit de le faire, mais ça n’empêche pas de trouver ça plus ou moins immoral et/ou malhonnête par rapports aux attentes et à ce fameux contrat social du logiciel libre.

De même, c'est quoi un bug tracker si ce n'est qu'un moyen d'avoir une relation entre des gens qui utilisent le logiciel avec des remarques, et les gens qui font le logiciel? En quoi est ce que c'est pas "un concept comme une relation client" ?

Bien sur, c'est pas une relation financière la plupart du temps, c'est pour ça que j'ai dit "comme une relation client", et pas "une relation client". Mais il y a clairement une relation, aç ressemble à ce que tu va avoir dans une boite, avec un dialogue, avec l'idée qu'un des deux parties fournit quelque chose pour l'autre. Mais comme c'est pas financier, on estime que tout le reste doit passer à la trappe aussi, alors que non. Si tu te dit "je m'en fout, je vais insulter les gens qui m'envoient des bugs", tu va assez vite te faire excommunier de la communauté, ce qui prouve qu'il y a un contrat social, et des attentes.

Et je dit "relation" et pas "échange", car en général, ça va que dans un sens. mais j'ai bien conscience que le terme est pas le plus adapté, et qu'il faut peut être inventé un mot pour ça. Mais je suis pas un spécialiste du divertissement comme Cory Doctorow, donc je ne vais pas inventer des mots pour dédouaner les gens (car bon, le mot enshittification, ça sert surtout à ça, à dire que les plateformes changent leur truc gratos, sans examiner les conditions économiques ou remettre la responsabilité des utilisateurs, surtout dans des outils avec des effets réseaux comme discord).

Et finalement, il ne suffit pas d'écrire un truc pour qu'un tribunal l'accepte, les clauses non applicables existent partout. Il y a des pays avec ou ce qui est dans le contrat est plus important (ex: les USA, avec des décisions comme Lochner v. New York ), mais même la, y a des limites.

Pour donner un exemple plus contemporain, Broadcom a le droit de changer ses prix. Ça empêche pas d'avoir des associations qui demandent à l'Europe d'aller regarder ça, ce qui traduit quand même l'idée que pour une bonne part des DSI, il y a une forme de responsabilité de Broadcom de ne pas quadrupler ses prix, quoi que le contrat puisse dire (cf ce lien.

Et puis finalement, est ce que mettre en avant ce genre de clause, c'est aussi du pain béni pour les critiques du logiciel libre, qui vont pouvoir dire que les devs opensource sont irresponsables ?

Car bon, soit les gens ont une responsabilité, soit ils en ont pas. Quand tu en as pas, y a un mot en français pour ça, c'est irresponsable:

"Qui n’a pas à répondre de ses actes."

La communauté veut du logiciel libre partout, parce que ça nous donne plus de pouvoir en tant que devs, mais en même temps, on veut aussi avoir 0 responsabilité. C'est aussi le cœur des discussions sur ce journal.

"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.