Adrien Dorsaz a écrit 991 commentaires

C'est pas passé, mais de peu.

Il faut savoir qu'il y avait besoin de 2 majorités pour faire passer cette initiative: celle de la population et celle des cantons.

Il y 13 cantons sur 23 et 54.76% de la population qui ont refusé l'initiative. Donc aucune des 2 majorités nécessaire n'a été atteinte.

Le score de 54.76% n'est pas très serré, il me semble que ça suit les scores habituels des initiatives.

Quand l'avis du peuple suisse est demandé, il est assez rare d'avoir des scores de plus de 60% par exemple.

Je l'utilise pour partager le setup de l'environnement de développement pour mes projets.

Je trouve que le fichier de description de service assez bien et me suffit pour ce cas. Il n'y a pas besoin d'avoir la complexité de la gestion de plusieurs noeuds, des jobs, des ingress, des routes…

Debian distribue docker-compose et podman-compose, je ne crois pas qu'il y a helm et une distribution de kubernetes packagé dans Debian.

Est-ce que tu aurais un exemple de setup helm et kubrnetes pour par exemple travailler sur un projet qui a une base de données et un serveur web ?

Désolé pour la désinformation 😅

Les développeurs d'application web sont avertis depuis des années du danger de ne pas valider les saisies utilisateurs contre les injections malicieuses, les iframe ont été spécialement connues pour ça si je me souviens bien.

Et maintenant le navigateur lui même active une injection de code malicieux en faisant un copier/coller d'une source inconnue vers un iframe sans validation ni nettoyage.

La solution bancale choisie est juste de raccourcir la taille du contenu copié et inséré dans le prompt.

Apparemment les applications de LLM n'ont plus ne font pas assez de validation des saisies utilisateurs vu que l'«intelligence» artificielle ne bronche pas quand l'utilisateur demande d'envoyer son code d'autorisation à un site complètement inconnu et non lié à l'origine de l'autorisation…

À croire que toutes ces années de préventions contre les failles d'injections n'ont servies à rien.

Je comprend le problème du démarchage, mais je ne comprend pas l'utilité du bandeau qui demande plus de sources.

Il serait plus simple de laisser 2 actions à un contributeur Wikipédia qui trouve une page qui manque de sources:

1. soit il cherche et ajoute directement des sources
2. soit il supprime la page

J'ai l'impression que cette troisième option avec le bandeau qui demande de l'aide est inutile car:

1. il n'améliore pas le contenu de Wikipédia
2. il est un appel à faire du démarchage par les personnes liées au sujet, car ce sera peut être les seules à lire la page en question et voir le bandeau

La seule utilité que je vois est que la personne qui pose le bandeau peut se dédouaner d'améliorer Wikipédia alors qu'il a constaté un problème.

Je ne comprend pas l'intérêt de mettre un très grand bandeau très visible qui demande de l'aide pour améliorer la page si c'est pour avoir un retour de bâton directement avec cette remarque:

il est regrettable que vous réagissiez suite à un démarchage incorrect (https://linuxfr.org/users/vendrediouletrollsauvage/journaux/eh-reveillez-vous-linuxfr-org-est-en-train-de-se-faire-supprimer-de-wikipedia), mais ce bandeau de maintenance est pleinement justifié vu la faiblesse des sources présentées, veuillez ne pas le retirer sans lancer le débat

Si personne n'a le droit de parler de ce bandeau ailleurs que sur wikipédia car c'est du démarchage, la pose du bandeau est un peu hypocrite, non ?

Plutôt que demander de l'aide qui sera directement dénigrée, remise en doute, autant directement supprimer la page…

Finalement si un « vrai » contributeur Wikipédia trouve des sources secondaires correct plus tard, il pourra recréer la page et ce sans avoir le risque de subir des démarchages.

Voilà, j'ai mis à jour la PR pour que ça fonctionne avec le Docker et le podman de Debian Trixie. J'ai réussi à régler le problème du service d'image également.

Pour info, les versions que j'ai sur mon poste sont:

$ docker version
Client:
 Version:           26.1.5+dfsg1
 API version:       1.45
 Go version:        go1.24.4
 Git commit:        a72d7cd
 Built:             Sat May  9 11:34:09 2026
 OS/Arch:           linux/amd64
 Context:           default

Server:
 Engine:
  Version:          26.1.5+dfsg1
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.24.4
  Git commit:       411e817
  Built:            Sat May  9 11:34:09 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.24~ds1
  GitCommit:        1.7.24~ds1-6+deb13u1
 runc:
  Version:          1.1.15+ds1
  GitCommit:        1.1.15+ds1-2+b4
 docker-init:
  Version:          0.19.0
  GitCommit:

$ podman version
Client:        Podman Engine
Version:       5.4.2
API Version:   5.4.2
Go Version:    go1.24.4
Built:         Sun Dec 21 17:42:01 2025
Build Origin:  Debian
OS/Arch:       linux/amd64

J'ai préparé une PR ici: https://github.com/linuxfrorg/linuxfr.org/pull/424

Je ne l'ai pas fusionnée, parce que le service d'image ne semble pas fonctionner correctement (je n'arrive pas à inclure une image dans une dépêche).

Je n'arrive pas à utliser Docker, seulement podman. Je corrigerai ça ce soir.

Par contre, avec podman, j'arrive à faire tourner le site, les tribunes et l'espace de rédaction.

Non, non tu n'as pas besoin parce que je pense le faire ce weekend. J'ai sûrement des modifications non commitées déjà prêtes sur un de mes PCs, je reteste ce weekend et je met sur main :)

Je m'occuperais ensuite de la branche rails8.

Je n'ai pas touché récemment au code de LinuxFr, mais effectivement,le docker-compose ne fonctionnait plus facilement sur la branche main la dernière fois que je l'ai utilisé.

Sur la branche liée à la migration à Rails 8, le fichier de composition était à jour et fonctionnait l'année dernière.

Je n'ai pas mis à jour la branche main pour ne pas avoir de conflit avec la branche rails8. Comme elle n'est pas fusionnée, ça vaudrait la peine de mettre à jour main quand même.

Je peux prendre du temps ce weekend pour mettre à jour main avec ce que j'avais fait pour la branche rails8.

Il n'y a aucune garantie avec les exemples que j'ai donné ;-)

Je ne suis pas français, je n'ai jamais eu l'occasion de traiter avec ce service. En l'occurrence, je n'ai que fait reprendre l'information qui était dans la capture d'écran du journal.

Si j'ai bien suivi, ce n'est pas la suppression des messages qui ne fonctionnerait pas comme attendu, mais les messages éphémères: quand le délais d'affichage est dépassé, l'application Signal n'affiche plus le message, mais elle le conserve en base de donnée d'après cette analyse.

Hello,

Je pense plutôt que c'est les textes à côté des boutons qui ne sont pas claire, le problème aurait été le même avec des cases à coché par exemple.

Je pense que "zéro papier" n'est pas assez claire sur ce qui se passe et donc qu'une interface qui propose un état "actif" / "inactif" ne fonctionne pas sans définir ce que ça signifie. Il aurait été plus claire avec des textes plus explicites comme:

---

Vos documents

⃝ Envoyer vos avis d'impôts sur le revenu par la poste
⃝ Envoyer vos avis d'impôts locaux la poste

---

Une autre solution, serait d'utiliser des listes de choix (soit sous forme de liste, soit sous forme de case à cocher avec choix unique).

---

Vos documents

• Communication de vos avis d'impôts sur le revenu:
  ⊗ par votre espace particulier (avec notification par courriel)
  ⃝ par courrier postale (au format papier sur arbres tués, ne choisissez pas cette option, nous avons besoin de faire des économies, même si c'est moins accessible pour une partie de la population)

• Communication de vos avis d'impôts locaux:
  ⊗ par votre espace particulier (avec notification par courriel
  ⃝ par courrier postale (au format papier sur arbres tués, ne choisissez pas cette option, nous avons besoin de faire des économies, même si c'est moins accessible pour une partie de la population)

Malheureusement, ça ne suffira sûrement pas, parce que tous les logiciels installés vont changer de version.

Il faudra donc également mettre à jour à la main chacun des fichiers de configuration.

Et il faut que chaque logiciel soit capable de revenir en arrière. Ce n'est pas le cas si des procédures de mise à jour ont modifié la structure des données (par exemple par une mise à jour des schémas de base de donnée ou de structure de dossiers / fichiers).

Il y a aussi la possibilité de faire un journal ou une dépêche avec un (court) descriptif de l'événement et de donner les dates de l'année courante.

C'est plus sympa pour les lecteurs et il y a plus de visibilité que les liens (ils ne sont pas affichés par défaut dans la page d'accueil si je me souviens bien).

Merci pour la fusion. Je crois qu'il faut recompiler les CSS pour voir apparaître les modifications que j'avais faites sur tables.scss. Sans ça, les tableaux du tableau de bord ne sont pas scrollable sur les petits écrans et ils cassent la mise en page.

Hello,

Pourquoi ne pas utiliser le préfixe data- devant le nom des attributs du framework ?

D'après ce que je comprend de MDN, ce préfixe est prévu pour que les applications puissent ajouter des données supplémentaires aux balises HTML sans casser la compatibilité avec HTML.

En plus, elles sont plus facile à accéder en JavaScript grâce à la propriété .dataset. Elles sont aussi accessibles avec CSS, mais je crois que c'est le cas pour tous les attributs.

Il me semblait que ce n'était pas utilisable avec htmx, mais d'après leur documentation, il est possible d'utiliser data-htmx-* maintenant.

Edit: Je viens de voir sur le README de ton repo que la syntaxe data-mu-* est utilisable aussi. Pourquoi alors proposer par défaut d'utiliser une syntaxe non-compatible avec HTML ?

Sous Linux, tu pourrais essayer avec GNOME Web, il utilise le même moteur que Safari (Webkit).

J'ai pu reproduire sur alpha.linuxfr.org aussi. Je n'ai pas accès au code tout de suite.

J‘ai mis à jour les liens Github pour pointer vers l'organisation linuxfrorg, mais cette page n‘est pas vraiment maintenue à jour.

Par exmemple, c‘est un peu bizarre, de lister les fichiers ici, c‘est sûr que personne ne pensera à venir mettre à jour ces listes ici.

Je ne connaissais pas cette page et je n‘aurais jamais pensé à trouver ça sur le wiki!

Les commentaires étaient bon: il faudrait plutôt avoir ces informations dans le repository directement. Là, je vais déjà éditer la page pour au moins diriger les lecteurs vers le bon compte github :)

C'est vrai que c'est petit la représentation de la barrière sur une seule case.

Est-ce que tu as essayé de présenter une barrière sur 3 cases ?

Par exemple, pour l'horizontal, tu aurais d'abord le bloc de pierre de gauche dans une case, la chaîne dans la case central, puis le bloc de pierre à droite.

J'ai l'impression qu'avec le design que tu as, en vertical ça devrait bien fonctionner aussi, parce que l'on verrait le détail des maillons dans la case centrale.

Bonjour,

Veuillez plutôt utiliser le forum pour ce genre de question, le système de suivi sert à améliorer LinuxFr.org lui-même.

Il y aura peut être plus de personnes qui vous répondront ou qui pourront vous aider.

Je comprends l'idée de vouloir éviter de faire des liens vers des sites générés par IA, mais je ne vois pas comment nous pourrions savoir si un site est généré par IA ou non.

J'avais vu que Next propose une extension qui avertit que certains sites peuvent contenir des articles générés par IA (pas forcément tout le site): https://next.ink/164873/outils-next-une-extension-chrome-et-firefox-pour-etre-alerte-des-sites-genai/

On pourrait récupérer la base et "appliquer le filtre Bloom" côté serveur LinuxFr pour faire comme l'extension (je ne sais pas ce que ça implique vraiment comme code).

Mais personnellement, je pense que c'est risqué:

1. Un site peut mélanger des articles écrits par IA et d'autres écrits par de vrais auteurs
2. Il va y avoir une dérive à vouloir bannir toute sorte de sites sur d'autres critères
3. La base de Next n'est pas publique, on ne sait pas comment elle remplie et on dépend complètement de Next pour l'alimenter. C'est un peu opposé aux valeurs d'ouverture de LinuxFr.

Enfin, plutôt qu'un bannissement a priori, nous avons toujours notre équipe de modération qui peut bloquer les contenus manifestement inappropriés.

utiliser les polices par défaut (les polices prennent presque la moitié de la taille transféré…) ;

Si elles sont installées sur ton ordinateur, elles ne sont même pas téléchargées ;)

Sinon elles peuvent être gardées en cache au moins 7 jours par ton navigateur comme le serveur l'annonce si je me souviens bien.

ne pas afficher les avatars par défaut ou au moins en lazy loading ;

Je ne pense pas que l'on changera l'affichage par défaut, il y a déjà une option pour les visiteurs inscrits.

Le mode lazy loading pour les images est une bonne idée et semble facile à implémenter, je garde la suggestion ouverte pour appliquer cet attribut sur les avatars et peut être les images des contenus.

simplifier le js.

Il n'y a déjà pas beaucoup de JavaScript, mais c'est vrai que ça serait bien de pouvoir enlever notre dépendance à jQuery. Ça demandera de changer d'éditeur de contenu (qui lui aussi a besoin d'être plus moderne) et de finir notre migration vers Ruby On Rails 8.