Adrien Dorsaz a écrit 887 commentaires

Oui, tu as tout a entièrement raison.

Pour l'environnement de développement je préfèrerai pouvoir garder la possibilité de fonctionner sans TLS pour ne pas compliquer encore plus la mise en place.

Si on fait cette modification, il faut aussi en profiter pour pouvoir choisir le port d'écoute.

Cela permettrai d'utiliser un port plus grand que 1024 et donc d'exécuter l'environnement de développement sans accès root (par exemple avec podman au lieu de docker).

Ce que je ferai donc, ça serait: remplacer la variable MY_DOMAIN=dlfp.lo par quelque chose du genre BASE_URL=http://localhost:3000. De même pour la variable IMG_DOMAIN.

Il faudrait aussi répercuter ce changement pour tous les projets de services (img, epub, board…).

J'ai fait exprès de ne pas inclure un tel lien en me disant que ça nécessitait un peu plue de réflexion, car inévitablement quelqu'un va demander qu'on ajoute Matrix, Signal, etc. le temps venu.

Je comprends le soucis de pollution de l'espace sous le titre. Pour XMPP, Matrix et Mastodon, je trouve assez chouette de pouvoir trouver des comptes via les profiles d'utilisateurs de LinuxFr, parce que les trois systèmes n'ont pas d'outil de découverte d'utilisateurs je crois.

Pour Signal, je ne suis pas sûr que ce soit utile, car c'est plutôt comme Whatsapp où c'est les carnets d'adresse qui connecte les gens, non ?

Il serait peut-être temps de réfléchir à une "vraie" page profil ou au moins à un popover avec tous les liens?

Oui, je suis tout à fait d'accord, il faudrait refaire ce système pour réduire le bruit sous les titres.

Il y a juste une contrainte pour l'instant, c'est que LinuxFr a la qualité de pouvoir être consulté sans avoir besoin de moteur JavaScript. Pour éviter de faire sauter ça, j'avais fait un test qui utilisais les balises HTMLs details ouvertes par défaut et refermée par JavaScript.

Enfin, c'était un test technique et je ne sais plus jusqu'où j'avais pu aller en terme de design.

Par contre, la vrai page de profile serait peut être plus élégante et plus simple à mettre en place. Puisque, quitte à faire faire un système de popup en JavaScript, on peut très bien ajouter simplement un joli bloque de profile sur les liens /user/xxx. Merci pour la suggestion !

En attendant que ce soit fait, je mettrait quand même le texte "compte Mastodon", parce que je suis sûr que la prochaine entrée de suivi sera: "J'ai renseigné mon compte Mastodon, mais il n'est affiché nulle part" :)

publier des commits en cours sur le service img (écriture de tests en cours)

Oh, je ne savais pas qu'il y avait des travaux en cours pour ce service. Si jamais, j'ai proposé aussi un petit correctif pour changer l'avatar par défaut quand le service n'arrive pas à atteindre l'url:

https://github.com/linuxfrorg/img-LinuxFr.org/pull/1

Merci pour le patch, il a l'aire bien :)

Je pense que c'est sympa de proposer cette option, mais maintenant que j'y réfléchis, j'ai un peu soucis pour les performances:

Si je comprends bien la fonctionnalité, chaque instance de mastodon va faire une requête régulièrement sur chaque page d'utilisateur LinuxFr qui renseigne son lien de compte pour retrouver l'URL du profile mastodon.

J'avais un peu peur que la vérification soie faite très souvent par chaque instance Mastodon, mais d'après la page de documentation donnée par Florent, ce n'est fait qu'une fois lors de l'ajout de la fonctionnalité sur une instance, alors ça devrait jouer.

Ça me faisait soucis pour les performances de LinuxFr, parce que la page "compte" donne la liste des contenus crées par l'utilisateur. Et donc, potentiellement, on aurait eu une charge constamment plus élevée sur les disques car MySql aurait eu beaucoup d'accès "random".

Peut être devrait-on quand même vérifier le nombre d'accès aux liens qui commencent par "https://linuxfr.org/users/" ?

---

Après la lecture de la fonctionnalité, j'ai l'impression que le but de Mastodon aurait plutôt était de faire reposer la vérification d'identité sur la possession d'un nom de domaine:

Document-based verification and blue ticks are not possible without a central authority. However, Mastodon can cross-reference the links you put on your profile to prove that you are the real owner of those links. In case one of those links is your personal homepage that is known and trusted, it can serve as the next-best-thing to identity verification.

Je ne pense pas que l'on peut pas dire que LinuxFr soit vraiment une page personnelle connue et de confiance :)

---

Enfin, pour la fonctionnalité sur LinuxFr, je pense que l'on peut faire 2 choses en plus:

1. Ajouter un texte après l'input du formulaire pour qui dirait quelque chose comme: "Après avoir sauvé ce changement, vous pouvez utiliser le lien https://linuxfr.org/users/xxx sur votre compte Mastodon pour vérifier votre identité via LinuxFr".
2. Ajouter un lien vers le "compte Mastodon" après le nom d'utilisateur sur chacun de ses contenus (comme on a déjà (site Web personnel, adresse XMPP)), je trouverai ça coule pour découvrir des comptes.Mastodon

Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :

Si justement, avec Chocolatey il y a en plus la confiance dans le binaire généré par l'upstream.

Et l'exemple de VS Code montre justement que c'est un problème: l'upstream crée uniquement des binaires privateurs qui ajoutent des outils indésirables sur un logiciel pourtant opensource.

Chocolatey n'a aucune maitrise sur les binaires produits par Microsoft.

Alors que Debian, avec sa charte signée par tous les mainteneurs, ne fournira que ce qui est disponible en opensource. C'est pourquoi ils doivent compiler eux-mêmes les binaires pour VS Code.

Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc… qui ne sont pas curated par des mainteneurs.

De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, …), l'argument tiens encore moins.

C'est pour cette raison que je ne parlais uniquement des dépôts Debian et de ce que fournis Debian de base.

S'il manque des logiciels dans Debian, il est possible de les ajouter en respectant la charte et en participant à la communauté Debian.

Impossible avec Chocolatey vu qu'il semble qu'il n'y a aucune infrastructure pour construire et héberger les binaires.

Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?

C'est un index de liens, il n'y a pas de code source hebergé et de binaires générés par Chocolatey.

Cela existe déjà en plus : https://community.chocolatey.org/packages/vscodium

Mais c'est le projet vscodium qui fourni les binaires et non pas Chocolatey, n'est-ce pas ? Si oui, le problème est toujours là.

Avec Debian, par exemple, tu mets ta confiance uniquement dans les mainteneurs et pour moi c'est une très grande différence: le mainteneur fournit la recette pour compiler les sources et installer le binaire généré.

Il maitrise donc vraiment ce qui se passe et peut éviter, par exemple, que le binaire d'installation ajoute des logiciels tiers indésirables (télémétrie, adware, extensions de navigateurs…).

Par exemple, si tu utilises Chocolatey pour installer VS Code, alors tu auras toute la télémétrie Microsoft installée avec.

Avec Debian, la charte impose la distribution de logiciel redistribuable et donc, si un paquet VS Code existait, il serait produit avec la version open source "codium" et donc sans la télémétrie propriétaire de Microsoft ni leur marché d'extension (car inaccessible pour les binaires non fournis par Microsoft).

chocolatey

Il me semble que ce n'est pas un repository de binaires et / où sources de logiciel, mais juste un index centralisé des liens de téléchargement de chaque logiciel.

En plus du lien, il y a un script PowerShell pour "automatiser" les cliques des installateurs fournis upstream.

Si je ne me trompe pas, la situation ne s'améliore pas, car tu continues à devoir télécharger sur chaque site le binaire, mais en plus tu dois faire confiance aux scripts PowerShell de la communauté chocolatey.

.

Ah ben, voilà le lien pour les CDs renvoie vers le wiki de Debian qui dit justement que ça ne sera plus utile pour bookworm:

The Debian project has taken the decision in 2022-10 to create a new repository component non-free-firmware, and include its content on installation media for the upcoming Debian release bookworm to make things easier for our users.
The information below still applies to the oldstable and stable releases (a.k.a. buster and bullseye), but might be outdated for weekly and nightly media of testing published in the coming weeks, with the situation changing rapidly while the decision is being implemented.
Please bear with us until the situation has settled and can be documented here. And if you want to help out this transition, feel free to follow the mailing list thread.

Si j'ai bien compris les résultats du vote récent à ce sujet, l'image de base de l'installeur permettra d'installer les firmware non-free.

Je n'ai pas testé récemment l'installation de testing, mais ça pourrait expliquer pourquoi il est difficile de trouver ces images pour testing: elles devraient être inutiles :)

Tu as raison, j'ai relu la requête SQL et je me suis bien trompé dans l'interprétation de celle-ci et de la page de statistiques :)

Bon, apparemment, syncthing supporte les extended attributes depuis la version 1.22.0 (attention, il vaut mieux utiliser la version 1.22.1 qui corrige des bugs sur cette feature). À essayer donc :)

Hello,

C'est une bonne nouvelle d'avoir une alternative mulit-utilisateurs pour les services WebDAV :)

Est-ce que les "extended attributes" des fichiers sont aussi synchronisés avec ce serveur et son client ?

Ça serait utile pour synchroniser les tags des fichiers, comme discuté dans un lien récent.

Pour l'instant, j'ai un Nextcloud, mais son client et son serveur ignorent les tags :(

Il y a quelques années, j'étais vraiment enjoué et je voulais bien utiliser les tags pour essayer, mais je me suis rendu compte que, ni NextCloud, ni OwnCloud ne permettent de synchroniser les "extended attributes" des fichiers.

Or Dolphin les utilise justement pour y stocker les tags.

Du coup, comme j'ai plusieurs ordinateurs et que je compte sur mon serveur Nextcloud pour centraliser mes sauvegardes, il m'a été impossible de les utiliser.

Est-ce qu'il existe une solution cloud open-source qui synchronise aussi les tags sur le serveur ?

Si non, c'est peine perdue pour moi et mes sauvegardes :(

Hello,

64 étiquetages de liens en 2011

Ce que le code source dit, c'est que:

Il y a 64 liaisons entre des liens et des tags crées en 2011.

Cependant, je ne suis pas sûr que la statistique soit vraiment intéressante: on pourrait avoir 1 lien qui a été lié à 64 tags crées en 2011 et avoir le même résultat que si 1 tag de 2011 avait été lié à 64 liens.

C'est intéressant de voir ce résumé, merci !

Je croise juste les doigts pour que les erreurs fatales ne proviennent pas de liens mal-formés et réellement présents sur le site ;)

Ça serait possible que des pages contiennent des liens cassés: le brouteur intelligent tente de les pré-fetch pour l'utilisateur, mais ce dernier ne se rendrait même pas compte qu'il y a une erreur s'il ne visite pas le lien réellement.

Du coup, les logs apparaîtraient quand même côté serveur à cause du pré-fetch et aucun humain ne s'en rendrait compte… O_o

J'ai essayé deux solutions:

1. nettoyer les paramètres depuis le controleur (par exemple, le BookmarkController)

Apparemment, je n'ai pas réussi à réécrire les paramètres avec RoR. J'ai essayé entre autre params.permit(:order, :page) et params.extract!(:order, :page), mais le comportement n'a pas changé sur mon poste.

2. de configurer kaminari (le module qui gère les liens pour la pagination)

De ce que je comprends, kaminari ne prend pas par défaut les paramètres de la page et on doit lui dire quels paramètres utiliser (avec une option params sur la méthode pagniate()).

D'abord, apparemment, le comportement par défaut avec LinuxFr prend tous les paramètres de la page. Je n'ai pas compris pourquoi c'est l'inverse de ce que j'ai vu dans les rapports de bug.

Ensuite, j'ai essayé de configurer quand même l'option params: j'arrive à ajouter des paramètres en plus dans les liens (genre, &foo=bar), mais je n'arrive pas à en enlever.

---

Si des connaisseurs de RoR passent par là, un coup de main serait apprécié, je n'y arrive pas :(

Je ne comprends pas trop pourquoi, ça dit juste que ce n'est pas fait.

Ah oui, tu as raison, j'ai lu que les discussions sont encore en cours dans un commentaire plus bas. J'ai interprété "avec Docker Hub", mais il n'y a rien de précisé, c'est peut être juste en interne chez ngnix.

Pour pouvoir juger de la qualité des images, il faut pouvoir lire leur Dockerfile et les sources qui l'accompagnent.

Malheureusement, je trouve difficile de lire le Dockerfile directement sur Docker Hub, car il manque le contexte des fichiers sources avec.

Par exemple, celui de nginx est encore lisible, mais on ne sait pas le contenu des fichiers des entry points.

Un point qui pourrait grandement aider à juger les images serait de donner la possibilité d'afficher directement sur la page des projets Docker Hub l'URL du site du projet, celle du dépôt de sources et éventuellement celle pour rapporter des bugs.

Je trouve par exemple facilement ces 3 liens sur les modules JavaScript hébergés sur npmjs.com. Ce n'est pas obligatoire sur ce site, mais les projets renseignent ça souvent.

Je sais qu'il y a un fichier Readme où les projets peuvent mettre du lien et du texte, mais j'apprécie que le Readme présente le projet plutôt que des liens. En plus, ça permet aussi de repérer rapidement les liens puisqu'ils sont toujours au même endroit si c'est en dehors (comme sur npmjs où je sais que je trouve ces liens sur la droite).

---

Je n'ai pas de parts dans npmjs, mais j'aime bien aussi le fait de voir les quelques métriques qu'ils ajoutent au projet:

• le nombre de téléchargement hebdomadaire donne une idée sur le nombre de personnes qui se fient à se projet et l'évolution dans le temps (projet jeune, projet abandonné dont les utilisateurs partent…)
• le nombre de dépendances
• le nombre de dépendants

Les deux derniers semblent bizarre pour des images de containers, mais je pense que ça permettrait de voir quelle est la profondeur du graphe des FROM pour construire l'image.

Pour le cas de nginx, le projet fourni lui même une imange avec accès restreints: https://hub.docker.com/r/nginxinc/nginx-unprivileged#!

Malheureusement, elle ne peut pas être mise en officielle sur docker hub: https://github.com/nginxinc/docker-nginx-unprivileged/issues/19#issuecomment-479536708

Ah oui, ça ressemble bien à ça.

En déconnecté, j'ai essayé d'accéder a la page: ?page=99&test=adrien et maintenant tous les liens de sélection de la page 99 contiennent mon texte test=adrien.

Il faudrait que le serveur nettoye les paramètres de la query string avant de créer les liens à cliquer…

Ah c'est la page précédente qui modifie tous les liens de numéro de page. La bannière de cette page était celle de "framasoft la route est longue mais la voie est libre" avec juste le logp de framasoft et des pinguins. Là c'est la page 8 qui a modifié les liens du pager.

Ça s'est produit avec la bannière "libre association point info" (page 15, si jamais, mais je pense que le numéro de page n'influence pas).

Quelle bannière de soutiens est affichée quand ça vous arrive ?

Il me semble que du code malveillant peut être injecté par là. Comme la bannière est tirée au hasard, ça pourrait expliquer pourquoi ça n'arrive que de temps en temps.

Une alternative aux paquets de debian sont ceux proposés upstream.

La documentation de nodejs pour installer node avec apt propose d'utiliser les repo de nodesource: https://github.com/nodesource/distributions/blob/master/README.md

Ils ont une source list par version de Debian et par version de nodejs, c'est top :)