Misc a écrit 6286 commentaires

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.

Clairement, vu que la majorité n'a pas son mot à dire, vu qu'elle ne code pas.

Il n'y a qu'une sous partie des gens qui savent coder (ou qui peuvent payer quelqu'un pour), et d'autant plus ceux qui sont payés pour coder qui ont une voix au chapitre.

C'est plus une dictature classique des riches en fait.

Et le 2FA c'est pour qui ? N'aurait-ohn pas pu éviter ce genre de fuite avec un 2FA ?

ça règle pas tout. Une autre attaque peut simplement le vol de cookie de session, voir de directement commander le navigateur (par exemple https://beefproject.com/ ).

Ouais, c'est pas dans le logiciel libre ou on aurait des options que la majorité n'utilisent pas. On le saurait si le kernel Linux avait 24 systèmes de fichiers :p

Ouais, j'ai aussi vu ça. Le nom de domaine appartient à ElectroLux, qui est la maison mère de AEG.

J'imagine qu'il va falloir que quelqu'un dise à ElectroLux d'uploader le code sur software heritage plutot que de faire un dépôt de code maison.

L'appareil aurait du télécharger la mise à jour en tache de
fond … et me prévenir que celle-ci serait appliquée après
utilisation ou au prochain démarrage de l'appareil, ou un truc
du genre.

Un truc comme ostree aurait pleinement du sens, oui (pour les PCs aussi en fait). Du coup, le souci, c'est pas tant les mises à jours forcés que le fait que certains fabricants ne savent pas faire de logiciels (déjà que les ingés logiciels savent pas en faire…).

Ensuite, je suppose qu'on peut pas imaginer qu'ils vont avoir de l’expérience sans expérimenter un minimum, mais que les forces économiques récompensent pas toujours l'attente.

D'après la fiche produit, il y a 24 modes de cuissons.

J'ai pas de four chez moi, mais ça me semble assez excessif.

Donc j'imagine que les 24 modes de cuissons doivent venir avec leur coût cognitif qui n'est pas trivial à implémenter du coté de l'interface classique d'un four, et que l'application qui va avec aide pour ça:
- tu as moyen de mettre plus de texte et des images
- tu peux traduire en plusieurs langues
- tu peux mettre à jour la documentation sans souci logistique

Donc je peux voir comment ça peut avoir du sens. Je suppose que pour un micro onde de base avec 1 bouton, ça ne sert à rien, mais la, on parle d'un four encastrable à 1850€ TTC (cf le site belge du fabricant), donc il y a peut être du logiciel un peu plus poussé sous le capot, et sans doute des interfaces plus complexes.

De plus, j'imagine que ça permet aussi de la télémétrie pour savoir exactement ce que les gens utilisent dans le produit afin de savoir ou faire de la R&D.

Et il y a aussi sans doute NTP pour l'heure.

Comme dit dans mon gros paté, via la curation communautaire.

Le but n'est pas d'indexer tout le web, car ça requiert des ressources quasiment impossible à avoir pour un nouvel entrant. Et il n'est pas possible de modérer tout ça sans que ça coûte cher (que ça soit en vérification, ou en temps CPU/machine learning/expertise).

En se focalise sur beaucoup moins que tout le web, on évite les soucis de l'indexation automatique (eg, quelqu'un qui rajoute de la merde), on peut avoir des interventions manuelles (retirer un site qui triche de l'index, en discutant du souci ouvertement), on peut avoir un outil qui a plus de chances de tourner sur des machines classiques (eg, pas un datacenter complet vu comme un seul ordinateur).

Alors y a sans doute des soucis que je voit pas, je ne dit pas le contraire. Par exemple, les gens vont se battre pour savoir ce qui est dans l'index du groupe ou pas, et avoir trop de groupe fait qu'on ne sait pas quel groupe choisir. Mais ce n'est pas différent de n'importe quel communauté autour d'un sujet, et on vit très bien avec des doublons de groupes.