Misc a écrit 6318 commentaires

Donc je n'ai pas le droit de critiquer une ressource à la
qualité douteuse parce que j'ai la possibilité d'exposer mon
avis de mon côté ?

Tu viens de le faire, donc visiblement, tu peux. Tu dis qu'on en parle pas, alors que tu en parles.

Ensuite, si le propos est "Arte ne parle pas du travail domestique des hommes célibataires dans un reportage de 20 minutes", ç'est plus précis. C'est ton droit de le pointer, mais c'est aussi mon droit de trouver la remarque même un chouia égocentré.

Ah, on est déjà dans l'insulte ?

Je sais pas, j'ai insulté qui ? Parce que j'ai quand même préciser "c'est sans doute pas le propos".

Ensuite, tu es peut être pas d'accord sur le fait que dire "on parle pas assez des hommes célibataires opprimés car on ne parle que des femmes", ça ressemble aux propos des incels, mais si c'est je pense que je vais pas réussir à l'expliquer plus clairement.

Le quart restant c'est du sarcasme.

Et donc, on est censé le deviner sur la base du message ?

Le travail domestique des hommes célibataires, on en discute
pas, c'est contre l'idéologie de la femme oppressée par la
société.

dit il en discutant du sujet.

Ton site personnel semble indiquer que tu connais hugo, donc si tu veux en parler plus, je suis sur que tu as les compétences pour faire un blog en utilisant hugo. Ensuite, si personne ne s'intéresse au sujet, je suppose que la prochaine étape va être sans doute de clarifier le propos, parce que sans précision, je vais mentir, ça donne quand une vibe d'idéologie d'incel, ce qui n'est sans doute pas le propos.

Mais sinon, tu as eu bien du courage de répondre, le coup du la
défense du bourreau victime devant la bienséance étant un tel
classique…

En même temps, je pense que c'est structurel. C'est comme pour l'adhérence des thèses antivaxx par les mouvements de médecine alternative, il y a une porosité entre les deux ce qui fait qu'une partie des seconds va plus facilement accepter les premières.

Le logiciel libre, c'est pour une partie de la communauté une question de collaboration, mais pas pour tout le monde. Pour certains, c'est aussi (à tort ou à raison) un coté anti-corporation et anti-système, et liberté de faire plus ou moins ce qu'on veut (un point tellement important que c'est la moitié de "logiciel libre")

Du coup, je pense qu'il y a des gens qui vont sincèrement examiner la question des codes de conduites à l'aune de ces croyances et se dire "ça n'est pas ce que je pense que le libre doit être" et réagir à base de "on nous censure", parce qu'on a présenté le logiciel libre comme ça.

En effet bien vu. J'avais lu le mail, mais pas vu la suite (vu que c'est du top posting, j'ai supposé qu'il n'y avait rien après).

Donc si on scrolle, on voit que ce qui a été demandé, c'est d’arrêter les attaques personnelles, d’arrêter de se moquer des fautes de grammaire des gens, d’arrêter d'être passif agressif, d’arrêter de faire du chantage et d’arrêter d'être insultant, et d'autant plus qu'il est vu comme un leader de la communauté.

Et sa réponse commence par "le conseil n'existe plus donc je ne peux pas être viré" (à mettre en en parallèle avec "Debian n'existe pas" d'un autre cas), suivi de pinaillage sur la procédure qui soit n'existait pas dans le passé (donc non valable pour lui), soit n'est pas celle qu'il faut suivre (donc non valable pour lui).

Un autre point manquant, c'est qu'il était engagé pour bosser sur Thunderbird par le passé (en tant que presta, de ce que je comprends). Je ne sais pas quand la relation s'est terminé, mais du coup, ça remets aussi en perspective une part de l'histoire.

100% des cas que j'ai vu ou dont j'ai entendu parler d'une expulsion, c'était pleinement justifié. Mais en général, les détails ne sont pas publiques pour protéger la vie privée des personnes impliqués, à commencer par la personne qui s'est fait exclure. Et aussi pour protéger l'organisation.

Mozilla a une structure et des procédures, notamment une échelle des conséquences.

L'exclusion, c'est jamais le premier pas, sauf si quelque chose est très grave. Donc pour en arriver la, c'est assez souvent de la récidive, et un choix délibéré de la personne de continuer.

La, on voit qu'il lui a été demandé de prendre 3 mois de non interaction mais qu'il a continué en disant "non" et "fuck it la gouvernance". Mais il ne dit jamais ce qui a pu arriver avant.

C'est exactement le même mode opératoire que Daniel Pocock, qui a fini par forcer Debian a faire une annonce publique.

On retrouve aussi les mêmes éléments de langages sur "as a volunteer", visant à manipuler en se positionnant comme une victime (eg, parce qu'il est volontaire, il devrait avoir un passe droit, etc). Et pareil, tout comme Daniel et la FSFE, il se positionne comme étant "la voix de la communauté", et il a aussi mis les liens vers les pdf des emails sur le site pour présenter sa version, mais juste la sienne, tout en présentant un discours qui va le rendre sympathique dans le monde du libre.

Donc perso, je ferais comme Zertinam.

Moi, je pense qu'il vaut mieux prendre autre chose qu'un 10.0.0.0/8, car c'est aussi ce qu'un réseau local d'entreprise pourrait utiliser au delà d'une certaine taille.

Et c'est fâcheux dans un monde ou on a de plus en plus de VPN à cause du travail à distance.

On a (enfin, avait) régulièrement le cas au boulot, avec les hôtels qui utilisent le même range que le réseau interne, et les employées qui ne pigent pas pourquoi le VPN marche qu'à moitié (et qui ne disent pas toujours "je suis dans un hôtel").

Donc prendre un réseau avec une taille plus adapté évite ce genre de souci. Je pense que 172.16.0.0/12 ou 192.168.0.0/16 me semble plus adapté qu'un /8.

(ensuite, bien sur, IPv6, etc, etc)

Petite correction : Salt-stack utilise aussi YAML et Jinja
mais avec un paradigme un peu différent.

Je dirais plus qu'un peu différent. Salt utilise un langage de template (jinja, mais d'autres sont dispos) qui va générer du yaml (ou d'autres). Tu as le choix des armes, et tu peux faire tout en python par exemple.

À contrario, Ansible utilise du yaml avec parfois des bouts de jinja dans les chaines. C'est beaucoup plus encadré.

SSH comme transport au lieu de réinventer quelque avec toutes
les contraintes, inconvénients et avantages. Mais ce choix a
aussi ses bons et mauvais côtés qui sont connus et maîtrisés
par les admins sys et la plupart des devs…

Ansible est en parti inspiré de Taboot, qui a lui même été fait pour aider à l'usage de Func. Le département IT de RH utilisait Taboot et Func il y a 10/15 ans pour l’exécution de commandes (en plus de Puppet), et Fedora utilisait Func/Puppet avant de passer à Ansible.

Func avait son propre bus de messages, et Ansible pouvait l'utiliser via un plugin. Pour le fun, j'ai aussi écrit un plugin pour utiliser celui de Salt (vu que j'ai fait Ansible => Salt => Ansible sur un projet).

Donc le choix de ssh a sans doute été fait en prenant en compte l'expérience acquise d'avoir un bus à maintenir.

Python comme langage pour les modules …parce-que justement
c'est présent partout (y avait aussi l'alternative PERL mais
comme il faut faire des choix et que ce n'était certainement
pas connu des équipes qui ont créé l'outil, ou pas assez, en
plus d'être un peu en perte de vitesse tandis que l'autre en
gagne.)

RH, à l'époque ou Michael Dehaan y a bossé (eg, 2008/2010) était 4 à 10 fois plus petite que maintenant, et fortement orienté python. Les projets de l'époque comme Yum, Anaconda, Bodhi, Func, c’était du python.

Ensuite, on peut faire des modules en perl ou en bash. Ou des binaires directement en go si on veut. C'est juste que l'upstream ne va pas accepter le code dans le dépôt principal pour des questions de maintenance.

C'est aussi un point qui a été discuté sur les systèmes de paquets. Ce qui fait qu'on ne peux pas facilement faire de rollback avec un système classique (eg, rpm, deb), c'est les effets de bord des scripts de pre/post installation. Et même si la majorité des paquets n'ont pas ce souci, il y en a suffisament pour que ça soit impossible.

Un paquet, c'est hautement déclaratif, sauf sur ça. Et visiblement, tout le monde s'oriente vers des solutions ou le paquet d'une qu'une brique de base et ce qu'on transporte, c'est le produit final après installation et application des scripts (ostree, Nix, mais aussi dans une moindre mesure les conteneurs via l'usage de Dockerfile).

Surtout que c'est pas tant le changement que les tarifs qui vont avec.

Github, c'est 48 US$ par an pour le tarif le moins cher.
Gitlab, 228 US$ par an pour le tiers le moins cher.

Donc je comprends que ça pique.

Même l'offre de niveau plus haut de Github (Entreprise) est moins cher que Gitlab, à 210 US$ par an et par personne. Et pour ce prix la, tu as plus de minutes de CI (50 000 pour github, 10 000 pour Gitlab), sans doute plus de stockage.

Ensuite, les fonctionnalités ne sont pas les mêmes, mais je connais pas assez l'offre de Github pour comparer avec ce que propose Gitlab.

Mais python date aussi du siècle dernier.

Un truc intéressant, c'est que dans le monde des SaaS, une grande peur est de voir Amazon offrir un produit concurrent. Une peur qui se retrouve dans la tendance à faire des produits presque libres sous des licences non libres comme la Commons clauses, la SSPL, etc.

Mais que je sache, Amazon pratique en général des tarifs basés sur l'usage des ressources, pas le nombre de personnes qui accède.

Du coup, faut s'en doute pas s'étonner non plus qu'Amazon bouffe leur marché (et je dit Amazon car c'est le leader du marché, mais je pense que ça s'applique sans doute aussi aux autres géants comme GCP ou Azure).

Ou à poster sur Linuxfr :)

C'est le genre de "coup" qui pose un vrai problème de confiance
pour les utilisateurs: personnellement je remonterai pas de
projet sur ce genre de plateforme, ou alors c'est juste un
miroir.

Surtout que ça coûterais pas forcément grand chose de plutôt dire "les nouvelles orgs seront limités à partir de maintenant", surtout quand la limitation est uniquement sur le nombre d'utilisateurs (eg, sur quelque chose de marginal et d'artificiel par rapport à ce qui va coûter des ressources, eg, les minutes de CI ou le nombre de dépôts).

Et c'est d'autant plus triste que tout l'article est basé sur un double discours, pointant qu'il faut faire un changement parce qu'il y a un impact financier tout en pointant que ça ne va toucher presque personne (la mention des 2% d'utilisateurs).

Pourtant, quand on regarde les résultats, ils semblent bon. Mais quand on regarde le cours de l'action, ç'est bien tombé depuis l'introduction en bourse (91 US$ en novembre 2021, 77 US$ lors de l'IPO initial, et 50 US$ aujourd'hui).

Du coup, c'est assez curieux de leur part, et ça me fait d'autant plus douter de la viabilité à long terme. Si il y a besoin de réduire quand la boite grandit, ça va donner quoi quand la croissance va retomber.

Alors, comme j'ai posté ailleurs, il n'y a pas que les projets privés. Les projets publiques sont aussi limités, et il faut faire une demande grosso modo tout les ans pour avoir le tiers "open source".

De plus, les conditions (détaillés dans un commentaire sur HN) font que leur définition d'Open Source comprends aussi une clause plus ou moins proche de "Non Commercial" de Creative Commons.

Donc à ma connaissance c'est loin d'être voulu, peut-être un
loupé quelque part, sans savoir de qui. En tous cas on ne peut
pas dire que c'est un truc voulu de la part de Google.

Ah oui, Google était en train de nettoyer le bouton qui retire le logiciel et paf, c'est parti tout seul.

A un moment, y bien quelqu'un dont c'est le boulot d'être responsable de retirer ou pas les applications du store. Je doute que ça soit un volontaire d'un projet opensource.

Je suppose que ça dépend exactement des régles de secu strictes en question. Si on commence à faire une partie de Calvinball, il faut au moins l'annoncer.

Fondamentalement, quelque chose doit être root sur l'infra pour l'administrer. J'aime pas Jenkins non plus, c'est pour ça que j'ai pas mis ça en place, mais fondamentalement, tu as un outil qui va faire des choses en root, et à partir du moment ou l'outil que ça soit ansible, puppet ou n'importe quoi d'autres peut exécuter des commandes en root, c'est game over.

Je ne pense pas que ansible lancer par jenkins soit pire que ansible depuis le PC random d'un admin. Et si le souci est que l'admin ne doit pas faire de modif local avant de lancer, alors faut le lancer depuis une machine ou ça n'arrive pas par erreur.

Sinon, il reste aussi le mode "ansible-pull".

Ou également:

https://ara.recordsansible.org/

• l'idée qu'on lance les playbooks localement, sans pouvoir facilement suivre qui a exécuté quoi, avec quels diffs locaux…

Y a Ansible Tower pour ça, mais sinon, des gens utilisent des CI (jenkins, buildbot, woodpecker) pour lancer ansible quand il y a un commit.

Pour ma part, j'ai un script de post commit git qui analyse le commit et lance le(s) playbook(s) impactés automatiquement.

Ansible de base fait les choses simplement, ce qui implique aussi de ne pas forcer un workflow spécifique. Tu as raison de dire que déployer depuis son PC, c'est naze, mais dans ce cas, ne le fait pas, force les gens à mettre un commit git et un CI avant, fait en sorte que le déploiement soit pas depuis le PC.

C'est un mauvais langage de script parce que c'est justement pas censé être un langage de script. C'est comme dire qu'une Ferrari F50 est un mauvais véhicule pour transporter ses meubles.

Sinon, il y avait déjà des outils comme fabric ou tu prends directement python, il n'y avait pas besoin de refaire la roue. Ou pour plus moderne, Bearstech a écrit Nuka.

Limiter ce que l'outil permet est une décision consciente, que les devs n'aiment pas, mais curieusement, les devs ne se jettent pas sur les alternatives cités plus haut qui n'ont pas de limitation sur le script. C'est un peu tout le concept de "revelead preference".

Ensuite, quand à yaml par rapport à un DSL qui plairement mieux à quelqu'un, je suis sur que ça changerait rien vu que si on arrive pas à se mettre d'accord sur les languages de script, un de plus ne va rien changer. Autant dire que c'est pas trés utile comme remarque.

Par contre, ce qu'on peut regarder si on veut avoir une remarque utile, c'est l'impact de prendre yaml par rapport à un DSL custom. Par exemple, utiliser yaml permet de fairel'analyse statique de façon assez trivial. Exemple, tu peux avoir un règle de d'abord installer les paquets, et de lancer le service à la fin. Si tu as un DSL maison comme puppet/salt ou un language complet (chef, par exemple), tu dois refaire un parser. En utilisant quelque chose comme yaml/toml/xml/json, un dev normal va pouvoir le faire, pour des scripts de post commits, etc.

Quand à "ansible a besoin de code", ouais, réinventer la roue n'est pas toujours une solution. Tu peux essayer d'aller convaincre l'upstream python de mettre le support de maven dans la lib standard ceci dit.

On pourrait aussi noter qu'en prenant une solution intégré avec aucun OS comme maven, on se retrouve à devoir payer ce coût de non intégration à chaque fois. Si les paquets java avaient repris le format rpm, ou simplement pip, la question ne se poserait pas.

Donc aucun problème, suffit de suivre les consignes plutôt que
de jouer les victimes sur Twitter.

Si tu avais lu le thread jusqu'au bout, tu verrais que Jesse Vincent dit "oui, il va sans doute y avoir une demande, mais il faut corriger le process".

Si ce n'est pas le problème, il faut me l'expliquer…

Le process est pourri. Par exemple, comment tu ferais pour un client pour Twitter ou pour Github ? Ou comme quelqu'un dit dans le thread, pour OSM avec Vespucci.

Tu n'as sans doute pas le droit de donner ton propre compte dans les ToS, mais du coup, tu ne peux pas fournir les informations.

Avoir des politiques pourris et des exceptions qui coincent, ça arrive, personne ne demande la perfection du premier coup. Mais retirer une application qui est la depuis 12 ans, qui a sans doute des tas d'utilisateurs et qui, si j'en crois le "again" a déjà été restauré par Google (donc avec un historique), c'est un souci structurel, pas juste une erreur.

Google se place en tiers de confiance, ça doit se mériter, et c'est donc un devoir que d'appliquer un contre pouvoir à ce niveau pour que le système s'améliore.

C'est pas très INTELigible comme commentaire, mais j'ai quand MIPS une bonne note.

En manifestation, sans doute

Ah bah oui, avec les satelittes et les vaccins, le temps commence à faire n'importe quoi.

Je pige pas, on me dit dans un journal que les mises à jours forcés, c'est mal, mais la, on dit que laisser les gens garder des systèmes sans mises à jour, c'est mal.

Comment est ce que je dois savoir quoi penser :p ?

Si faire son pain, c'est du travail. Est ce que le manger rentre dans du travail au même sens, vu que c'est la suite logique de l'action ? Et si manger est un travail, est ce que dormir serait un travail ?

J'ai vite lu le PDF, et tu reprends la définition de Marx. Mais du coup, si je dort pour moi même, est ce que c'est de l'auto travail ?

Et du coup, qu'est ce qui n'est pas de l'auto-travail ?

C'est une vraie question, parce qu'autant je vois bien ou sa commence avec tes exemples, autant je ne voit pas trop ou ça s’arrête.