bbo a écrit 204 commentaires

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.

Ce que tu racontes me fait pas mal penser au Fair Code (site/mouvement que je n'ai découvert que récemment).

Il y a 3 mois, ils parlaient de le remettre mais pour l'instant ce n'est pas fait…

La vraie question que je me pose : est-ce que ça sera ré-implémenté en JS ?

;-P

Au moins, on est sûr que la version libre va être bien stable pendant les 3 prochaines années ⸮

Lightbend avait déjà arrêté son investissement dans Play en octobre 2021.

Ça "pivote" !

Tu vas pouvoir la refaire en Quarkus et la boucle sera bouclée :)

"[…] pour attirer et fidéliser des dirigeants de premier plan"

Vu les pertes sous le dirigeant de premier plan, faudrait essayer un patron de seconde zone pour voir !

A une époque, j'étais tombé sur ZwiiCMS. C'est du PHP, donc facile à héberger sur du mutualisé. Les données sont stockées dans des fichiers JSON.

La communauté semble principalement francophone et le code hébergé sur le chapril.

Note : je n'ai pas essayé.

c'est ce que l'on fait de mieux en terme de dissonance cognitive et biais cognitifs

"en terme de qualitay" tu veux dire ?

Je pense que tu devrais lire son blog avant d'affirmer qu'il ne prend pas la mesure de ses projets ou qu'il n'a pas assez de recul.

Cela me paraîtrait plus logique que Windows se fasse intégrer dans systemd-homed. Après tout, une maison a toujours plusieurs fenêtre !

Et, vu tous les pouvoirs et intentions qui sont prêtées à Poettering, j'ai hâte de voir arriver :

• le changement de casse sur systemctl. Genre SystemCtl List-Units.
• les nouveaux alias pour favoriser l'adoption. Genre Start-Service PusleAudio

Désolé Laurent mais le titre de ton lien me chagrine. "Aucune n'est libre" alors que :

• La 1ère (pas la dernière hein, la 1ère ! Devant WhatsApp !) alternative proposée est une plateforme dont les clients (Bureau, Android et iOS) et le serveur sont libres
• La 2ème alternative proposée est une plateforme dont les clients sont libres.

Après, elles sont proprio, ok. Mais y a quand même pas mal de code libre sur le podium, contrairement à ce que tu suggères dans le titre.

Dans ce fil de discussion, je trouve qu'il y a confusion entre le code et le service (et sans oublier que "Signal" est une marque en plus). Le service est bien centralisé, avec les problèmes que ça pose. Mais le code lui, est bel et bien libre. C'est pas une question d'abus de langage. Juste, c'est libre (et AGPLv3 pour le serveur Signal en plus !). La centralisation ou non d'un service n'a rien à voir avec les libertés associées au logiciel.

La prochaine étape, c'est quoi ? Que les appli desktop ne sont pas vraiment libres car c'est un bloat utilisant Electron ? Et que Mattermost sans les bridges, c'est pas libre "stricto sensu" ?

---

Je pense que "aucune n'est décentralisée" aurait été plus dans le message que tu voulais faire passer.

basé sur ubuntu, qui aux dernières nouvelles que j'en ai (qui datent) recommande toujours aptitude comme gestionnaire de paquet en ligne de commande.

apt reste quand même cité en 1er pour une utilisation interactive en ligne de commande. aptitude est plutôt indiqué en tant qu'interface texte.

Par ailleurs, un des développeurs d'apt est employé de Canonical.

Heureusement qu'il reste l'ascenseur social…!

Mais, pour des raisons de budget, il ne démarre qu'au 2ème étage. C'est dommage pour ceux qui partent du rez-de-chaussée (voir de la cave).

Alors pense fort :

Mais quand ce souvenir,
Revient me faire souffrir,
Très vite j'y pense et puis j'oublie.

Il y a un site pour expliquer la configuration "texte brut" des clients mails. Par exemple, Thunderbird !

D'accord avec toi sur les explications possibles, sauf celle-là :

Une partie des répondantes et répondants fait de la programmation à titre personnelle (par opposition au travail en entreprise avec des environnements imposés) et sur de petits projets (…qui ne nécessitent pas un éditeur qui fait IDE et café éclipse)

Car dans le sondage de l'année dernière, tu as des réponses qui ne concernent que les professionnels. Et dans ce cas, Notepad++ est toujours très bien placé (en 4ème position). Donc la programmation pour rigoler n'est pas un critère significatif pour obtenir ce bon classement.

Pour ma part, je l'utilise beaucoup sur les fichiers CSV et mon journal.txt