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).
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).
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
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).
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.
J'ai vu qu'il y a un .o dispo dans le mail d'origine: https://www.openwall.com/lists/oss-security/2024/03/29/4 et le mail dit: "Florian Weimer first extracted the injected code in isolation, also attached, liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks!"
La backdoor était sous la forme de code binaire caché dans les données de test, donc il n'y a que le .o pour le moment. Je ne doute pas que dans quelque jours, quelqu'un va coller le dump en assembleur avec une analyse. Il y a 87 ko de code compilé, avec du code existant, donc ça doit pas être non plus trop gros.
Il y a une version dans le thread avec plus de symboles, ça peut aider pour le débogage.
pour savoir si sshd dépend de liblzma, et savoir si la vulnérabilité est potentiellement présente.
Modulo le fait que pam charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine). Et que libsystemd aussi depuis 1 mois, comme l'a souligné Lennart P sur HN à un moment.
Quand je lit les commentaires sur la sophistication de la backdoor, et le fait que l'attaquant a visé spécifiquement les paquets de distros, ainsi que d'autres libs, je pense que la cible n'était pas sshd.
Je pense que l'idée était de rajouter une backdoor pour signer des paquets rpms/debian avec une clé arbitraire. Ça expliquerait pourquoi il y a eu un souci avec sshd, car l'attaquant n'avait pas du tester ce cas de figure (vu que la dépendance est transitive via systemd, et ça ne semble être actif que via des options bien spécifiques).
mais liblzma est utilisé aussi par librpm et par dpkg. Le fait de modifier des trucs du coté des fonctions RSA me fait penser aux signatures des paquets, et ça me semble plus probable, ça laisse moins de trace.
Il y a eu des discussions ici et ici, mais je pense que c'est plus parce que Madelyn Olson s'est focalisé sur trouver un endroit ou mettre le projet (eg, la LF) pour faire collaborer les industriels (eg, AWS, Alibaba, Google, etc) alors que Drew a juste dit "fuck it, qui m'aime me suive" et il est parti sur Codeberg, un point que je trouve assez discutable.
Je suppose qu'implicitement, il y a aussi le coté un peu rugeux du dit Drew (je sais pas ce qu'il a fait, mais j'ai eu plusieurs échos).
Comme le souligne Madelyn, la LGPL ne change rien pour les boites qui proposent du Redis en tant que service hébergé, donc je trouve ça assez curieux de dire que ça ne leur convient pas.
Oui, je dit parfois que le logiciel libre est la par le surplus de productivité de certaines personnes. On a du code libre parce qu'il y a des bénévoles, on a du code libre parce qu'on a des gens payés qui sont plus productif en reprenant du code libre qu'en codant de 0 (tout les softs écrit par des admins de facs, surtout au début, mais aussi sans doute l'embarqué d'une manière général). Et la, ton exemple rentre aussi la dedans, on a du code libre par les hyperscaleurs parce qu'ils ont du coder ça de toute façon, donc autant le libérer.
Mouais, ensuite, si tu regardes la timeline de tout ça, c'est plus compliqué.
Redis le projet (2009) est plus ancien que Redis l'entreprise (ex Redis-labs) qui a été crée en 2011 sous le nom Garantia Data par 2 entrepreneurs, aucun n'étant fondateur de Redis le projet. Le créateur n'a rejoint Redis l'entreprise qu'en 2015 (après avoir quitté pivotal, si je me souviens bien), et il a quitté la boite en 2020.
AWS propose AWS Elasticache depuis… 2011 avec un support de Redis depuis septembre 2013 (et Memcached avant). Redis la boite/Redislabs/Garantia Data ont sorti leur offre plus tôt (février 2013), mais c'était pas les seuls sur le marché, vu que Myredis, qu'ils ont achetés en octobre 2013, proposait déjà le même service en 2012 en beta, et en février 2013 en GA ( cf la date de https://news.ycombinator.com/item?id=5294122 ). Donc à quelques mois prêt, tout le monde a eu la même idée (vu que Garantia Data avait aussi une offre de SaaS pour Memcached, soit la même chose qu'AWS, quelques temps après AWS).
Je veux bien dire du mal d'Amazon, mais quand Garantia Data a décidé de se renommer en Redislabs puis en Redis puis de prendre du capital risque 7 ou 8 fois d'affilés pour devenir éditeur, ils savaient qu'AWS était la depuis le début, et ils n'avaient pas trop l'excuse d'avoir fondé le projet eux même vu qu'ils ont fondé la boite puis décidé de devenir le sponsor principal pour rajouter des plugins pour leur business modéle de l'époque (aka, la marketplace) .
La boite aurait parfaitement pu être comme la plupart des boites qui font du support sur Postgresql et du consulting, mais c'est pas le choix qui a été fait, sans doute parce qu'à un moment, faut avoir du ROI.
Redis la boite a choisi de faire de l'édition son gagne pain, sans doute parce que ça rapporte plus que les autres types de gagne pain. Et quand ils ont fait ce choix, AWS et co était déjà la. Donc bon, ils ont tentés de jouer gros, et visiblement, ils n'ont pas gagner.
Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).
Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.
J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.
Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.
Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.
Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.
Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.
Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).
Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.
c'est très pratique pour mettre en place un environnement de développement qui n'affecte pas le reste du système.
À condition de lancer pip/npm/etc en root, car si tu passes par toolbox (qui est l'outil de moindre résistance), tu va partager le /home. Je suppose que ça dépend de ce que tu appelles "environnement de développement", vu que ça va des compilos aux config des éditeurs de code en passant par les libs dispos.
Après, ça signifie que certaines applications ont du mal à fonctionner.
Le fait de ne pas pouvoir facilement lancer tcpdump ou des outils bas niveau de ce genre dans un conteneur (notamment celui de toolbox) font que je pense que je repasserait sur une distro normal pour mon prochain PC.
Je peux avoir toolbox et flatpak sur une Fedora normale, donc le seul avantage, c'est le système en read-only, et j'ai pas le sentiment que ça m'apporte assez pour justifier les limitations que j'ai constaté. Je sais que je peux faire un rpm-ostree install --live, mais je sais aussi que le dev upstream voit ça comme un hack qui va contre la vision du déploiement par image. C'est assez clairement écrit dans la doc de bootc, et j'attends de voir comment tout va se mettre en place en pratique avant de repartir pour 3/4 ans avec ce genre d'OS sur mon portable pro.
Ça dépend du site, mais j'ai entendu que l'offre OVH est pas cher (genre 2€ par mois). De ce qu'on m'a raconté, ça fait l'affaire pour un site statique et je sais qu'il y a du 2FA, de l'IP v6, etc.
J'avais regardé aussi les différentes offres à base de S3 chez les différents providers cloud, mais ça coûtait vite plus cher qu'OVH, avec moins de garantie sur les coûts en cas de DDoS. Dans mon souvenir, AWS était le plus abouti et le moins cher, mais je voulais autre chose. Azure était à 20€ à cause d'un composant de reverse proxy, Digital Ocean était à 5€ minimum (voir plus), et j'ai pas réussi à piger la doc de GCP.
J'avais aussi fait des tests avec fly.io et scaleway, avec un site statique dans un binaire statique mis dans un conteneur. C'était drôle, mais j'avais finalement pas l'usage.
Les GAFAM sont de gros exemples de distorsion de concurrence.
Je pense que ça dépend des domaines. Par exemple, pour les questions d'IaaS et de cloud, il y a une concurrence entre les 3 gros et pas mal de petits acteurs. Il y a aussi des conditions qui font que ce n'est pas trivial de rentrer sur le marché à cause des investissements requis pour le capital, donc on va pas s'attendre à des miracles non plus. 3/4 gros et plein de petits, c'est aussi l'état du marché des abonnements mobiles en France et ailleurs (je pense à ça avec la fusion de 2 opérateurs en Espagne, et la position de la commission européenne pour dire "oui, ça devrait aller" vu que le numéro 4 et le 5 fusionne) pour les mêmes raisons d'avoir besoin de capital.
Je sais pas si Redis est ou a était un monopole et il a beaucoup de concurrents qui lui tiennent à minima la dragée haute et son API est vraiment simple à implémenter ce qui fait que tu peut trouver assez facilement des drop-in replacement.
Ouais, je pense que monopole n'est pas le bon terme en effet, je n'ai pas exprimé ma pensée correctement. Je pense que le terme "brique de base standard" est plus proche de ce que je voulais exprimer.
Postgresql est une brique de base car il y a beaucoup de logiciels qui s'en servent. Redis est dans la même position, je l'utilise pour pretalx, pour discourse, pour nextcloud.
Mongo etait à mon sens moins une brique de base pour moi, car j'ai jamais eu besoin de l'utiliser.
Je doute qu'AWS déploie Garnet, principalement parce c'est un projet issue de Microsoft Research, donc avec du code de chercheurs. Je suppose que soit AWS va essayer de faire comme Microsoft et partager l'argent avec Redis-la-boite (ex Redislabs), soit prendre un des forks qui tient la route et allouer des ressources dessus.
Il y a d'autres projets compatible Redis comme KeyDB, Infinispan, en plus des forks récents.
Mais c'est du coup la preuve qu'il est possible de collaborer.
Ensuite, ça pose la question de ce qui serait une collaboration "juste", mais c'est un débat bien plus compliqué. Si ton logiciel est suffisant pour la plupart des cas (comme Redis), pas grand monde ne va contribuer des correctifs ou des features.
Tu pointes que pg est un commun, mais qu'est ce qui fait qu'un logiciel soit plus un commun qu'un autre, et comment est ce qu'on mesure ça (ou plutôt, voit ça) ?
Je sais qu'il y a des efforts comme les conditions pour devenir projet chez Apache ou sur Openstack. Je sais aussi que parfois, ça coince après. Par exemple, si tu as des commiteurs de 2 entreprises et qu'une fait faillite, ça devient de facto un projet qui n'est plus dans les clous si tu as une condition de diversité. Tu as aussi le fait que même si tu fais des efforts pour devenir un commun avec des sources de contributions variés, c'est parfois impossible si le marché ne permet pas d'avoir plusieurs boites de façon saine.
Finalement, je pense qu'il y a eu pas mal d'écrit sur la question de la concurrence non faussée dans les marchés économiques, et c'est peut être quelque chose à explorer.
Comment est ce qu'on s'assure qu'un logiciel évite une forme de monopole sur sa niche comme c'est arrivé avec Redis ? Est ce qu'on veut tendre vers ça ?
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 5.
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).
[^] # Re: Le code de la backdoor?
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 3.
https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
semble donner plus d'info
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 4.
Tu veux parler de sssd ?
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 9.
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
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 3.
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.
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 3.
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).
# Réaction officiel du projet/hosteur
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 5.
https://tukaani.org/xz-backdoor/
[^] # Re: Confiance
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 4.
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.
[^] # Re: Combo glibc/systemd
Posté par Misc (site web personnel) . En réponse au journal Xz (liblzma) compromis. Évalué à 6.
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.
[^] # Re: Le code de la backdoor?
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 4.
J'ai vu qu'il y a un .o dispo dans le mail d'origine: https://www.openwall.com/lists/oss-security/2024/03/29/4 et le mail dit: "Florian Weimer first extracted the injected code in isolation, also attached, liblzma_la-crc64-fast.o, I had only looked at the whole binary. Thanks!"
La backdoor était sous la forme de code binaire caché dans les données de test, donc il n'y a que le .o pour le moment. Je ne doute pas que dans quelque jours, quelqu'un va coller le dump en assembleur avec une analyse. Il y a 87 ko de code compilé, avec du code existant, donc ça doit pas être non plus trop gros.
Il y a une version dans le thread avec plus de symboles, ça peut aider pour le débogage.
[^] # Re: Annonce chez Red Hat
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 3.
Thread sur Fedora:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IJRW6X34BBJQLAQ64G53S7XPRU35U7KN/
[^] # Re: Réaction du projet Python
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 6.
Modulo le fait que pam charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine). Et que libsystemd aussi depuis 1 mois, comme l'a souligné Lennart P sur HN à un moment.
[^] # Re: Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 9.
En effet, j'avais complètement zappé ce point (alors que je l'ai lu). Ça fait tombé mon analyse à l'eau :(
# Je pense que sshd n'était pas visé
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 6.
Quand je lit les commentaires sur la sophistication de la backdoor, et le fait que l'attaquant a visé spécifiquement les paquets de distros, ainsi que d'autres libs, je pense que la cible n'était pas sshd.
Je pense que l'idée était de rajouter une backdoor pour signer des paquets rpms/debian avec une clé arbitraire. Ça expliquerait pourquoi il y a eu un souci avec sshd, car l'attaquant n'avait pas du tester ce cas de figure (vu que la dépendance est transitive via systemd, et ça ne semble être actif que via des options bien spécifiques).
mais liblzma est utilisé aussi par librpm et par dpkg. Le fait de modifier des trucs du coté des fonctions RSA me fait penser aux signatures des paquets, et ça me semble plus probable, ça laisse moins de trace.
# Sur HN, LWN et ailleurs
Posté par Misc (site web personnel) . En réponse au lien Backdoor in upstream xz/liblzma leading to ssh server compromise. Évalué à 7.
https://news.ycombinator.com/item?id=39865810
https://lobste.rs/s/uihyvs/backdoor_upstream_xz_liblzma_leading_ssh
https://lwn.net/Articles/967180/
[^] # Re: Valkey
Posté par Misc (site web personnel) . En réponse au lien Linux Foundation Launches Open Source Valkey Community. Évalué à 4.
Il y a eu des discussions ici et ici, mais je pense que c'est plus parce que Madelyn Olson s'est focalisé sur trouver un endroit ou mettre le projet (eg, la LF) pour faire collaborer les industriels (eg, AWS, Alibaba, Google, etc) alors que Drew a juste dit "fuck it, qui m'aime me suive" et il est parti sur Codeberg, un point que je trouve assez discutable.
Je suppose qu'implicitement, il y a aussi le coté un peu rugeux du dit Drew (je sais pas ce qu'il a fait, mais j'ai eu plusieurs échos).
Comme le souligne Madelyn, la LGPL ne change rien pour les boites qui proposent du Redis en tant que service hébergé, donc je trouve ça assez curieux de dire que ça ne leur convient pas.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3. Dernière modification le 28 mars 2024 à 21:17.
Oui, je dit parfois que le logiciel libre est la par le surplus de productivité de certaines personnes. On a du code libre parce qu'il y a des bénévoles, on a du code libre parce qu'on a des gens payés qui sont plus productif en reprenant du code libre qu'en codant de 0 (tout les softs écrit par des admins de facs, surtout au début, mais aussi sans doute l'embarqué d'une manière général). Et la, ton exemple rentre aussi la dedans, on a du code libre par les hyperscaleurs parce qu'ils ont du coder ça de toute façon, donc autant le libérer.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3.
Mouais, ensuite, si tu regardes la timeline de tout ça, c'est plus compliqué.
Redis le projet (2009) est plus ancien que Redis l'entreprise (ex Redis-labs) qui a été crée en 2011 sous le nom Garantia Data par 2 entrepreneurs, aucun n'étant fondateur de Redis le projet. Le créateur n'a rejoint Redis l'entreprise qu'en 2015 (après avoir quitté pivotal, si je me souviens bien), et il a quitté la boite en 2020.
AWS propose AWS Elasticache depuis… 2011 avec un support de Redis depuis septembre 2013 (et Memcached avant). Redis la boite/Redislabs/Garantia Data ont sorti leur offre plus tôt (février 2013), mais c'était pas les seuls sur le marché, vu que Myredis, qu'ils ont achetés en octobre 2013, proposait déjà le même service en 2012 en beta, et en février 2013 en GA ( cf la date de https://news.ycombinator.com/item?id=5294122 ). Donc à quelques mois prêt, tout le monde a eu la même idée (vu que Garantia Data avait aussi une offre de SaaS pour Memcached, soit la même chose qu'AWS, quelques temps après AWS).
Je veux bien dire du mal d'Amazon, mais quand Garantia Data a décidé de se renommer en Redislabs puis en Redis puis de prendre du capital risque 7 ou 8 fois d'affilés pour devenir éditeur, ils savaient qu'AWS était la depuis le début, et ils n'avaient pas trop l'excuse d'avoir fondé le projet eux même vu qu'ils ont fondé la boite puis décidé de devenir le sponsor principal pour rajouter des plugins pour leur business modéle de l'époque (aka, la marketplace) .
La boite aurait parfaitement pu être comme la plupart des boites qui font du support sur Postgresql et du consulting, mais c'est pas le choix qui a été fait, sans doute parce qu'à un moment, faut avoir du ROI.
Redis la boite a choisi de faire de l'édition son gagne pain, sans doute parce que ça rapporte plus que les autres types de gagne pain. Et quand ils ont fait ce choix, AWS et co était déjà la. Donc bon, ils ont tentés de jouer gros, et visiblement, ils n'ont pas gagner.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 7.
Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).
Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.
J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.
Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.
Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.
Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.
Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.
Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).
Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 4.
Oui, mais du coup, pipenv et co, ça marche sans silverblue, non ?
Du coup, je pige pas quel est l'apport pour ton workflow, à part d'être sur que tu installes rien en root par erreur.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 6.
À condition de lancer pip/npm/etc en root, car si tu passes par toolbox (qui est l'outil de moindre résistance), tu va partager le /home. Je suppose que ça dépend de ce que tu appelles "environnement de développement", vu que ça va des compilos aux config des éditeurs de code en passant par les libs dispos.
Le fait de ne pas pouvoir facilement lancer tcpdump ou des outils bas niveau de ce genre dans un conteneur (notamment celui de toolbox) font que je pense que je repasserait sur une distro normal pour mon prochain PC.
Je peux avoir toolbox et flatpak sur une Fedora normale, donc le seul avantage, c'est le système en read-only, et j'ai pas le sentiment que ça m'apporte assez pour justifier les limitations que j'ai constaté. Je sais que je peux faire un rpm-ostree install --live, mais je sais aussi que le dev upstream voit ça comme un hack qui va contre la vision du déploiement par image. C'est assez clairement écrit dans la doc de bootc, et j'attends de voir comment tout va se mettre en place en pratique avant de repartir pour 3/4 ans avec ce genre d'OS sur mon portable pro.
[^] # Re: La mienne marche encore
Posté par Misc (site web personnel) . En réponse au lien Webmail + pages perso free aux non abonnés, c'est terminé. Évalué à 3.
Ça dépend du site, mais j'ai entendu que l'offre OVH est pas cher (genre 2€ par mois). De ce qu'on m'a raconté, ça fait l'affaire pour un site statique et je sais qu'il y a du 2FA, de l'IP v6, etc.
J'avais regardé aussi les différentes offres à base de S3 chez les différents providers cloud, mais ça coûtait vite plus cher qu'OVH, avec moins de garantie sur les coûts en cas de DDoS. Dans mon souvenir, AWS était le plus abouti et le moins cher, mais je voulais autre chose. Azure était à 20€ à cause d'un composant de reverse proxy, Digital Ocean était à 5€ minimum (voir plus), et j'ai pas réussi à piger la doc de GCP.
J'avais aussi fait des tests avec fly.io et scaleway, avec un site statique dans un binaire statique mis dans un conteneur. C'était drôle, mais j'avais finalement pas l'usage.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4.
Je pense que ça dépend des domaines. Par exemple, pour les questions d'IaaS et de cloud, il y a une concurrence entre les 3 gros et pas mal de petits acteurs. Il y a aussi des conditions qui font que ce n'est pas trivial de rentrer sur le marché à cause des investissements requis pour le capital, donc on va pas s'attendre à des miracles non plus. 3/4 gros et plein de petits, c'est aussi l'état du marché des abonnements mobiles en France et ailleurs (je pense à ça avec la fusion de 2 opérateurs en Espagne, et la position de la commission européenne pour dire "oui, ça devrait aller" vu que le numéro 4 et le 5 fusionne) pour les mêmes raisons d'avoir besoin de capital.
Ouais, je pense que monopole n'est pas le bon terme en effet, je n'ai pas exprimé ma pensée correctement. Je pense que le terme "brique de base standard" est plus proche de ce que je voulais exprimer.
Postgresql est une brique de base car il y a beaucoup de logiciels qui s'en servent. Redis est dans la même position, je l'utilise pour pretalx, pour discourse, pour nextcloud.
Mongo etait à mon sens moins une brique de base pour moi, car j'ai jamais eu besoin de l'utiliser.
[^] # Re: Pendant ce temps-là chez Microsoft
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4.
Je doute qu'AWS déploie Garnet, principalement parce c'est un projet issue de Microsoft Research, donc avec du code de chercheurs. Je suppose que soit AWS va essayer de faire comme Microsoft et partager l'argent avec Redis-la-boite (ex Redislabs), soit prendre un des forks qui tient la route et allouer des ressources dessus.
Il y a d'autres projets compatible Redis comme KeyDB, Infinispan, en plus des forks récents.
[^] # Re: Ah si ils l'aiment l'open source...
Posté par Misc (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4.
Mais c'est du coup la preuve qu'il est possible de collaborer.
Ensuite, ça pose la question de ce qui serait une collaboration "juste", mais c'est un débat bien plus compliqué. Si ton logiciel est suffisant pour la plupart des cas (comme Redis), pas grand monde ne va contribuer des correctifs ou des features.
Tu pointes que pg est un commun, mais qu'est ce qui fait qu'un logiciel soit plus un commun qu'un autre, et comment est ce qu'on mesure ça (ou plutôt, voit ça) ?
Je sais qu'il y a des efforts comme les conditions pour devenir projet chez Apache ou sur Openstack. Je sais aussi que parfois, ça coince après. Par exemple, si tu as des commiteurs de 2 entreprises et qu'une fait faillite, ça devient de facto un projet qui n'est plus dans les clous si tu as une condition de diversité. Tu as aussi le fait que même si tu fais des efforts pour devenir un commun avec des sources de contributions variés, c'est parfois impossible si le marché ne permet pas d'avoir plusieurs boites de façon saine.
Finalement, je pense qu'il y a eu pas mal d'écrit sur la question de la concurrence non faussée dans les marchés économiques, et c'est peut être quelque chose à explorer.
Comment est ce qu'on s'assure qu'un logiciel évite une forme de monopole sur sa niche comme c'est arrivé avec Redis ? Est ce qu'on veut tendre vers ça ?