bbo a écrit 220 commentaires

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 !

Sauf erreur de ma part, le fichier de configuration passé directement à l'application ne va pas fonctionner dans un environnement docker sans orchestrateur car tu vas devoir soit monter un volume pour exposer le fichier de configuration à l'application, soit reconstruire ton image avec le fichier de configuration dedans.

Alors que tu peux passer un fichier de conf via --env-file qui mettra tout dans l'environnement sans lier ton conteneur à l'hôte ou devoir reconstruire ton image pour chaque environnement.

Cependant, je reconnais que le fichier est peut-être moins découvrable. Une idée de palliatif (mais c'est probablement pas parfait) : en utilisant asciidoc (que j'aime beaucoup), j'inclus dans le README les variables utilisées (car je suis bien obligé de les définir à un endroit dans mon code et que ce n'est pas une gros effort de "tagguer la région" pour que le README soit à jour, sachant qu'il faut bien, à un moment, lire un bout de doc pour déployer).

en effet, c’est ce qui m’intéresse très fort dans BSD

N'oublie pas la Slackware !

Là encore, je ne comprends pas l'argument. N'y vois pas de la mauvaise volonté de ma part mais dire que l'équipe de systemd force les distributions, ça me parait sur-estimer le pouvoir qu'ils ont vraiment. Certes, une fois que des mainteneurs décident de l'intégrer dans leur distribution, ils deviennent dépendants des choix du projet amont. Mais c'est le cas avec tous leurs amonts¹.

La comparaison est probablement maladroite de ma part mais :

• Pourquoi ça gueule moins sur la GNU libc qui pose aussi des soucis ? C'est la faute des développeurs GNU si des logiciels utilisent des fonctionnalités spécifiques à la glibc ?
• Ce sont les développeurs Bash qui ont forcé les distributions a massivement utiliser Bash, ce qui a pour conséquence de facilement faire des scripts non portables ?

Cependant, je reconnais que systemd avance vite. Et j'ai plus l'impression que c'est ça qui pose soucis dans la communauté. Ça va vite parce que des gens sont payés pour travailler dessus à temps plein. Je ne vois pas comment les alternatives non financées peuvent suivre le rythme. C'est le même type de problème qu'on peut rencontrer dans certaines associations ayant des salariés (bénévolat de quelques heures par mois ou par semaine vs 35h/semaine…).

Et donc, je me demande souvent : si une (ou plusieurs) boites finançai(en)t 3, 4 ou 5 développeurs à plein temps pour bosser sur s6, OpenRC, eudev, elogind et/ou la définition de nouvelles API Free Desktop, est-ce que les "débats" seraient moins dans la confrontation ?

Je trouve que, justement, systemd apporte une certaine homogénéité dans les couches basses d'un GNU/Linux. Je ne comprends pas pourquoi l'homogénéité c'est bien quand on parle des BSD et c'est mal quand on parle de systemd ?

Et pour les polémiques autour du risque de "mono-culture systemd" chez GNU/Linux, je me demande si le risque de "mono-culture rc.d" est aussi discutée chez FreeBSD ?

Il me semblait bien me rappeler avoir déjà vu htmx ! Devnewton avait partagé un lien également l'année dernière.