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).
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 amonts1.
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 ?
Mais il me parait clair que la relation avec les amonts est vraiment différente chez GNU/Linux par rapport aux BSD. Vu que chaque BSD est l'amont ou embarque directement les sources dans leur dépôt pour les outils ayant un amont. ↩
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 ?
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
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.
Posté par bbo .
En réponse au journal Adieu Atom :(.
Évalué à 2.
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
Est-ce qu’il y a un moyen simple d’avoir les dernières versions de Plasma dès qu’elles sortent ?
Cette page indique que tu peux voir arriver une mise à jour majeure de Plasma par version de Fedora. En gros, si tu as une Fedora 36 avec Plasma 5.24, tu verras Plasma 5.25 arriver dans les mises à jour en cours de cycle. Par contre, une fois que Fedora 37 sort, il ne faut plus attendre de mise à jour de Plasma sur Fedora 36 même si elle est encore supportée.
Cela fait plusieurs versions que je n'utilise plus Fedora mais c'est assez cohérent avec ce dont je me souviens. Par contre, j'ai souvenir qu'il y a un certain lag entre la sortie de Plasma et l'arrivée dans les mises à jour.
Si tu veux plus rapide : openSUSE Tumbleweed (lag en heures, parfois quelques jours. Par exemple, Plasma 5.24 est arrivé dans les dépôts en une journée) et Arch (qui attend la 5.x.1de mémoire, soit une semaine après la 5.x.0)
Pour Fedora, clairement, le fait de passer par Rawhide avant prend logiquement un peu de temps. Après, c'est peut être l'occasion pour toi de participer à la validation des mises à jour en ajoutant du Karma dans Bohdi (par exemple, la mise à jour 5.24.5 pour Fedora 36)
Est-ce que les dépôts de Fedora sont aussi complets que les dépôts d’ubuntu ?
Je suppose que tu poses la question "en général" plus que spécifiquement pour les paquets KDE ? Fedora fournit des paquets -devel et des paquets -doc. Je pense donc que ça répond "oui" à ta question !
Et pour ton départ d'Ubuntu, je sais que tu as écris "entre autre" :) mais
sa politique assez agressive concernant les paquets snaps
Ce lien m'a fait penser à un livre sur les bonnes pratiques de l’éco-conception web publié par Greenit.fr et que j'avais acheté il y a 10 ans environ. Me disant que ce livre avait dû très mal vieillir, j'ai été surpris de voir qu'ils viennent de publier la 4ème édition ce mois-ci. Autre surprise : le contenu de cette nouvelle édition est disponible sur Github en Creative Commons (mais en BY-NC-ND donc non libre).
[^] # Re: Explication
Posté par bbo . En réponse au journal Douze facteurs dans ta tronche. Évalué à 6.
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-filequi 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).
[^] # Re: Je pose la question dans l'autre sens
Posté par bbo . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 6.
N'oublie pas la Slackware !
[^] # Re: Je pose la question dans l'autre sens
Posté par bbo . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 3.
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 amonts1.
La comparaison est probablement maladroite de ma part mais :
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 ?
Mais il me parait clair que la relation avec les amonts est vraiment différente chez GNU/Linux par rapport aux BSD. Vu que chaque BSD est l'amont ou embarque directement les sources dans leur dépôt pour les outils ayant un amont. ↩
[^] # Re: Je pose la question dans l'autre sens
Posté par bbo . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 10. Dernière modification le 03 novembre 2022 à 19:59.
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 ?
# Complément
Posté par bbo . En réponse au lien Migration de react vers htmx. Évalué à 6.
Il me semblait bien me rappeler avoir déjà vu htmx ! Devnewton avait partagé un lien également l'année dernière.
[^] # Re: BSL
Posté par bbo . En réponse au lien Sentry redevient privateur. Évalué à 3.
Ce que tu racontes me fait pas mal penser au Fair Code (site/mouvement que je n'ai découvert que récemment).
[^] # Re: Formats des boîtes locales
Posté par bbo . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 3.
La vraie question que je me pose : est-ce que ça sera ré-implémenté en JS ?
;-P
[^] # Re: noyage de poisson
Posté par bbo . En réponse au lien Akka devient privateur. Évalué à 5.
Au moins, on est sûr que la version libre va être bien stable pendant les 3 prochaines années ⸮
# Dans la continuité...
Posté par bbo . En réponse au lien Akka devient privateur. Évalué à 3.
Lightbend avait déjà arrêté son investissement dans Play en octobre 2021.
Ça "pivote" !
[^] # Re: Changer de langage
Posté par bbo . En réponse au lien Comment rendre les applications moins énergivores ?. Évalué à 2.
Tu vas pouvoir la refaire en Quarkus et la boucle sera bouclée :)
[^] # Re: Oui mais il a bien travaillé !
Posté par bbo . En réponse au lien le patron démissionnaire d'ATOS empoche 1.8 millions de parachute. Évalué à 10.
Vu les pertes sous le dirigeant de premier plan, faudrait essayer un patron de seconde zone pour voir !
# Petit CMS plutôt franchophone
Posté par bbo . En réponse au journal Bloguer pour pas trop cher, avec du logiciel libre et sobrement, en 2022. Évalué à 3.
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é.
[^] # Re: Lyon
Posté par bbo . En réponse à la dépêche Revue de presse de l'April pour la semaine 27 de l'année 2022. Évalué à 1.
"en terme de qualitay" tu veux dire ?
[^] # Re: +1 pour la rime
Posté par bbo . En réponse au lien Lennart ce fripon, s'en va à Redmond. Évalué à 2.
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.
[^] # Re: Ahah !
Posté par bbo . En réponse au lien Lennart ce fripon, s'en va à Redmond. Évalué à 2.
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 :
systemctl. GenreSystemCtl List-Units.Start-Service PusleAudio[^] # Re: Signal
Posté par bbo . En réponse au lien The Verge suggère 5 applis de messagerie chiffrée, aucune n'est libre. Évalué à 8. Dernière modification le 03 juillet 2022 à 16:07.
Désolé Laurent mais le titre de ton lien me chagrine. "Aucune n'est libre" alors que :
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.
[^] # Re: C'est pas dans Debian
Posté par bbo . En réponse au journal pkcon riz. Évalué à 3.
aptreste quand même cité en 1er pour une utilisation interactive en ligne de commande.aptitudeest plutôt indiqué en tant qu'interface texte.Par ailleurs, un des développeurs d'
aptest employé de Canonical.[^] # Re: Lycée à la carte
Posté par bbo . En réponse au lien 2,5% des filles choisissent le nouvel enseignement Numérique et sciences informatiques (garçons 15%). Évalué à 7. Dernière modification le 19 juin 2022 à 16:41.
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).
[^] # Re: Lycée à la carte
Posté par bbo . En réponse au lien 2,5% des filles choisissent le nouvel enseignement Numérique et sciences informatiques (garçons 15%). Évalué à 2. Dernière modification le 19 juin 2022 à 16:43.
Alors pense fort :
[^] # Re: Etape suivante : fusionner avec Delta Chat !
Posté par bbo . En réponse au lien Android : K-9 Mail va devenir Thunderbird. Évalué à 3.
Il y a un site pour expliquer la configuration "texte brut" des clients mails. Par exemple, Thunderbird !
[^] # Re: Moi qui croyait qu'il était libre
Posté par bbo . En réponse au journal Adieu Atom :(. Évalué à 2.
D'accord avec toi sur les explications possibles, sauf celle-là :
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
[^] # Re: Cabale
Posté par bbo . En réponse au lien Musk interdit le télétravail à ses salariés. Évalué à 2.
Eux, au moins, ils ont plus de 3 résidences !
[^] # Re: Les vrais ecolos sont uniquement de mon parti
Posté par bbo . En réponse au journal Les vidéos de Devoxx fr sont disponibles. Évalué à 2.
tu augmentes les taxes.
C'est encore plus KISS.
Mais je reconnais que
a l'avantage de générer du PIB
⸮
Je regrette de n'avoir pas pu passer ici hier !
--> []
[^] # Re: Changer de distribution
Posté par bbo . En réponse à la dépêche Sortie de Fedora Linux 36. Évalué à 3.
En complément de ce qui a déjà été écrit :
Cette page indique que tu peux voir arriver une mise à jour majeure de Plasma par version de Fedora. En gros, si tu as une Fedora 36 avec Plasma 5.24, tu verras Plasma 5.25 arriver dans les mises à jour en cours de cycle. Par contre, une fois que Fedora 37 sort, il ne faut plus attendre de mise à jour de Plasma sur Fedora 36 même si elle est encore supportée.
Cela fait plusieurs versions que je n'utilise plus Fedora mais c'est assez cohérent avec ce dont je me souviens. Par contre, j'ai souvenir qu'il y a un certain lag entre la sortie de Plasma et l'arrivée dans les mises à jour.
Si tu veux plus rapide : openSUSE Tumbleweed (lag en heures, parfois quelques jours. Par exemple, Plasma 5.24 est arrivé dans les dépôts en une journée) et Arch (qui attend la
5.x.1de mémoire, soit une semaine après la5.x.0)Pour Fedora, clairement, le fait de passer par Rawhide avant prend logiquement un peu de temps. Après, c'est peut être l'occasion pour toi de participer à la validation des mises à jour en ajoutant du Karma dans Bohdi (par exemple, la mise à jour 5.24.5 pour Fedora 36)
Tu peux vérifier si les logiciels que tu utilises sont disponibles dans les dépôts officiels ou dans RPMFusion.
Je suppose que tu poses la question "en général" plus que spécifiquement pour les paquets KDE ? Fedora fournit des paquets
-develet des paquets-doc. Je pense donc que ça répond "oui" à ta question !Et pour ton départ d'Ubuntu, je sais que tu as écris "entre autre" :) mais
si tu penses au Snap de Firefox, je me permets de rappeler que ça s'est fait sur demande de Mozilla ;)
# Sur le même thème
Posté par bbo . En réponse au lien Livre blanc de l'action - éco-conception numérique. Évalué à 5.
Ce lien m'a fait penser à un livre sur les bonnes pratiques de l’éco-conception web publié par Greenit.fr et que j'avais acheté il y a 10 ans environ. Me disant que ce livre avait dû très mal vieillir, j'ai été surpris de voir qu'ils viennent de publier la 4ème édition ce mois-ci. Autre surprise : le contenu de cette nouvelle édition est disponible sur Github en Creative Commons (mais en BY-NC-ND donc non libre).