bbo a écrit 200 commentaires

Comme Gandhi aurait presque pu le dire :

Sois la polémique que tu veux voir dans le monde

Je ne peux que reconnaître les efforts de Lunduke pour vivre selon cet adage.

Est-ce que c'est encore plus spicy qu'il ne soit CEO de SUSE que depuis le 1er mai ? :)

1) Fournir un clone de RHEL, c'est déjà le but de Rocky et Alma (pour les 2 plus connues); Suse va se situé où ?

Ils parlent de fork et non de clone. D'après The Register, il semblerait qu'ils puissent reconstruire les SRPM mais en fournissant le kernel de SLE. Un peu comme Oracle qui fournit son UEK en lieu et place du kernel RHEL.

A voir s'il y aura un kernel RHEL aussi, ou pas (finalement, ça dépend de ce qu'ils mettent dans "compatibilité"). Malgré le surplus d'effort que cela pourrait représenter, il faut quand même noter que SUSE sait maintenir un kernel vu que c'est fait pour SLE.

2) Quid de SLE ? J'ai du mal à croire que Suse investisse dans un fork d'une distribution concurrente.

SUSE investit déjà dans RHEL. Rancher ou k3s peuvent être installés (et supportés) sur du RHEL. Uyuni peut gérer des RHEL. Par le biais de la communauté openSUSE, tu peux construire des paquets pour Fedora, CentOS, RHEL sur l'Open Build Service.

SUSE admet depuis un moment qu'il n'y a pas que du SLE chez ses clients.

En même temps, je pense que tous les clients SLE doivent bien avoir quelques RHEL qui traînent dans leur infrastructure. Je suis moins sûr que tous les clients RHEL aient des SLE qui se promènent…

4) je n'ai jamais eu de serveurs SLE sous la main, à part le dnf/zypper quelles sont les grandes différences ?

On peut ajouter :

• AppArmor par défaut (au lieu de SELinux, même si SELinux est supporté),
• YaST qui centralise des outils d'administration (facultatif, tu peux tout faire en ligne de commande si tu préfères)
• Tumbleweed/Leap n'ont pas les mêmes cycles de vie que Fedora/RHEL
• Leap utilise directement les RPM (binaires) de SLE
• Les outils spécifiques (openQA, Open Build Service)
• Des petites différences "culturelles" : Btrfs+snapper par défaut, /srv/www vs /var/www, SUSE a l'air de bien aimer Salt Stack, beaucoup d'utilisateurs KDE chez openSUSE

Il y a surtout beaucoup de similitudes (coucou systemd). D'autant que les communautés openSUSE et Fedora ont des relations très amicales.

---

A noter que SUSE et la communauté openSUSE construisent la base de la prochaine version majeure de SLE. Qui ressemblera plus à Micro OS qu'à la SLE telle qu'on la connaît maintenant.

According to Insider, McKinsey claimed that the Metaverse would bring businesses $5 trillion in value.

Cela me rassure de voir que le gouvernement français utilise massivement les services de conseillers professionnels qui savent prendre du recul sur les dernières hypes du moment.

Les organisateurs des JO cherchent 45 000 pigeons

Enfin un peu d'ambition pour fournir une implémentation à très grande échelle de la RFC 2549 !

façon commode de "découvrir d'autres utilisateurs"

Sur LinuxFR, j'ai découvert Zenitram !

avec des licences problématiques (voire pas libre?) comme Mongodb ;

Dans le catalogue, il est indiqué :

Dernière version : release-1.0 (Févr. 2012)

Donc "c'est bon", la version référencée est bien libre :)

Une base Fedora.

Je cite :

Fedora has its own version of flatpaks. These differs from the regular flatpaks mainly what source is picked to build the applications. Standard flatpaks use source code, which is then rebuilt with /app prefix, but Fedora flatpaks use rpms. This implies that only applications which are packaged as rpm can be converted into Fedora flatpaks. There is also a difference in the resulting format. Flathub uses OSTree for its flatpaks, while Fedora uses OCI.

Je comprends donc que le dépôt Flatpak de Fedora est juste un packaging différent des logiciels qui sont déjà dans les dépôts officiels de Fedora. D'où probablement le fait que ça puisse lagguer derrière Flathub.

C'est une Entreprise de taille intermédiaire (certes, une petite ETI, mais pas petite tout court, ni moyenne tout court).

Moi, je trouve que la terminologie inventée par cg, que je résumerai en MGE (Moyennement Grosse Entreprise), est bien plus disruptive qu'ETI ! Et c'est plus évolutif car on peut rajouter plein de couches : PGE (Plutôt Grosse Entreprise), VGE (Vraiment Grosse Entreprise), etc

Allez --> []

:)

D'autant plus que les ressources nécessaires pour émerger […]

Dans cette optique, je me demande quel pourcentage de ces 30 millions de dollars sera consacré à la rémunération du nouveau CEO.

Surtout que pour le Lorem, ChatGPT est bien plus efficace

Ça dépend de ce que tu regardes. Si on prend le besoin en ressources physiques, Lorem est bien meilleur.

Tu veux qu'ils se fassent un claquage?

Si seulement emacs avait déjà démarré.

Le truc pas simple, c'est de faire ça près d'une douche.

intrication qui est l'une des raisons pour lesquels ils ne veulent pas libérer le Snap Store d'ailleurs

C'est surtout l'intégration dans leur infrastructure plus que l'intégration dans le système Ubuntu qui fait qu'ils devraient faire un effort pour l'open-sourcer. Effort qu'ils ne veulent pas faire (et je suis d'accord que c'est bien dommage).

Parce que, côté système Ubuntu, ce n'est pas intriqué. Comme cela a été dit, la partie sur ton système Ubuntu est open-source.

pourquoi supprimer Firefox et Chromium de APT ?

Pour Chromium, les ressources limitées pour un navigateur n'étant pas le navigateur par défaut et non officiellement supporté (car dans universe) mais supporté quand même. Le billet de blog qui expliquait la décision est intéressant à lire.

Pour Firefox, c'est un travail à l'initiative de Mozilla. Mais je suppose que Canonical a saisi l'opportunité pour les mêmes raisons de ressources. Après, pour le moment, c'est toujours possible d'avoir Firefox en paquet deb.

Qu'est-ce qui empêche de fournir ces paquets via Snap et APT pour ceux veulent ?

Désolé, mais je trouve que t'y vas fort. Peut-être que c'est compliqué de faire un paquet Firefox toutes les 6 semaines pour toutes les versions maintenues d'Ubuntu ? Firefox et Chromium arrivent avec des contraintes sur l'outillage et les librairies qui semblent parfois compliquées à gérer pour les distributions LTS (exemple).

---

Alors que je suis d'accord sur le fond (Snap Store propriétaire : pas bien), je suis un peu irrité de voir que c'est utilisé pour laisser entendre que Canonical serait contre la liberté logicielle. Limite pire que Microsoft. Oui, il y a des trucs gênants avec Canonical qui poussent à la prudence. Mais comme toute boite privée. A côté de ça, si rien que 30% des PC actuellement sous Windows dans le monde étaient sous Ubuntu, le monde du numérique serait quand même vraiment différent.

Oui, avant d'avoir l'outil pour débattre à plusieurs millions (j'ai hâte de voir la mise en œuvre réelle de l'outil d'ailleurs. Aujourd'hui, les outils qui rassemblent autant de gens sont les réseaux sociaux), il faudrait déjà savoir débattre. Tout court. Avec ses collègues, sa famille, dans son quartier.

Par ailleurs, ce qui me gêne dans ce journal c'est l'hypothèse que seule la démocratie (au niveau d'un pays) mérite d'être sauvée devant le "confort moderne".

Je suis tout à fait d'accord qu'on peut vivre sans machine à laver, sans lave vaisselle, sans four, sans réfrigérateur, etc. Le confort moderne n'est peut-être pas indispensable mais, sans un minimum, le monde que tu décris sera surtout la démocratie directe avec ceux qui ont du temps.

Parce que proposer, discuter et voter des lois ça prend du temps et de l'énergie (intellectuelle et émotionnelle, entre autres). Énergie que tu ne vas pas mettre ailleurs. Mais quand tu dois d'abord gérer le train-train du foyer (beaucoup plus pénible donc) et le travail (qui subsistera, sous une forme ou sous une autre, dans le monde "avec seulement Internet" que tu décris mais qui sera aussi beaucoup plus pénible car, sans tout ce confort, il y aura beaucoup plus de travail physique/épuisant), le seul moyen de s'investir dans la démocratie sera :

• d'être une personne héroïque
• de ne pas avoir à gérer le foyer. Soit grâce à l'argent. Soit parce que le conjoint ou la conjointe gère (je fais effort pour ne pas diverger sur l'explosion probable des inégalités entre les sexes). Soit les 2.

Tout ça pour conclure que, je suis d'accord avec toi qu'on n'est pas tous d'accord. Dans un monde sans aucun confort, je crois que la démocratie ne se vivra pas sur Internet ni au niveau d'un pays. Elle se vivra au lavoir, pour résoudre les problèmes du quotidien.

il n'y a plus aucun obstacle matériel

Si : la vie quotidienne.

je trouve le "beaucoup" en trop

Il a mis "beaucoup" parce que lorsqu'il a survécu à Slackware, il n'a pas simplement continué sa vie, il s'est mis à aimer Slackware :)

C'est pas plutôt emacs qui vient d'intégrer F-Droid en tant que mode mineur du mode majeur Android ?

ni en argent, ni en visualisation de publicité, ni en données personnelles.

Tu as juste payé en temps :)

Bah, tu n'aimes pas SVN ?!

Pourquoi n'as-tu pas déplacé le pot de fleurs a un endroit moins gênant ?

Tu as raison, Le Monde aurait dû titrer : "Comment fonctionne Mastodon, présenté comme alternative open source à Twitter ?"

Comme ça, on aurait pu "sereinement" discuter des différences open source/libre dans le cadre d'un logiciel AGPL.

:-P

Sur le système lui-même, je préfère avoir un processus qui log par processus qui tourne.

En même temps, tu aimes et utilises runit :P

Tu as raison. Peut-être que préférer passer par --env-file plutôt que de monter un volume est une préférence personnelle de ma part.

Après, j'ai eu quelques prises de têtes sur les volumes (mapping UID/GID par exemple, mais c'était avec Podman, peut-être que c'est différent avec Docker). C'est peut-être ça qui m'a un peu échaudé et me fait préférer --env-file si j'ai le choix (et mon application supportait la conf par variable d'environnement, --env-file était donc "gratuit").

Par contre, si le choix c'est de monter un volume ou de faire évoluer l'application pour qu'elle supporte la configuration par variable d'environnement, c'est sûr que le volume est plus simple/rapide.

Je pense que la meilleure solution est d'éviter au maximum les containers.

Juste là dessus : je dirai surtout que la meilleure solution est de bien choisir ses images de base. Choisir une image de base pour ses conteneurs de prod, c'est comme choisir une distribution pour ses VM de prod.

Sur DockerHub, il y a de tout. Mais sur Distrowatch aussi.

Quand je choisis une distribution, c'est que j'ai confiance en leur capacité à publier des correctifs de qualité et rapidement. Il faut que ça soit pareil sur les images de base utilisées par mes conteneurs de prod (cf les usages décrit par Xavier Claude)

Je ne pense pas que le (vrai) problème soulevé dans ce journal soit un problème technologique.

Trop de DRY peut amener trop d'abstractions et/ou d'indirections. Et lorsqu'il faut maintenir ça des années après, tu es frappé par le principe de Douche Froide.

Je découvre à l'occasion de ton commentaire qu'il y a un principe opposé à DRY : WET. "We Enjoy Typing" : j'adore !