Adrien Dorsaz a écrit 952 commentaires

Il me semble que j'ai remarqué ce même comportement également sur les entrées de suivis.

Il faudrait que le tableau de bord notifie l'auteur d'un contenu quand un nouveau fil de commentaire est crée.

Je vois que dans le tableau de bord, nous avons les sections "Vos derniers messages dans les forums" et "Vos dernières entrées dans le suivi" qui devraient recevoir le symbole de notification dans ce genre.

Je comprend tout à fait le problème de la gestion de réputation d'un serveur email. C'est un réel problème et ce même pour l'hébergement professionnel et privatif.

Comme nous avons déjà les flux RSS pour les commentaires pour chaque contenu (forum, journal, dépêche, entrée de suivi…), ça serait bien de proposer à l'auteur du contenu de s'inscrire au flux RSS.

En plus, j'ai entendu parler d'outils qui permettent de transformer un flux RSS en flux d'email (côté utilisateur) sans avoir besoin d'employer le serveur de mail de LinuxFr.

Je trouverais ça chouette d'avoir un message du genre:

Votre journal/post de forum/lien a bien été publié.

Pour suivre les commentaires, inscrivez-vous à son flux RSS

Si vous n'avez pas de lecteur RSS, vous pouvez utiliser "rss2email" pour recevoir les commentaires dans votre boîte email.

J'ai mis "rss2email" car c'est le premier nom qui m'est apparu en cherchant "rss to email open source". Il faudrait trouver l'outil/service le plus ergonomique pour les néophites des flux RSS.

Pour référence, le même genre de problème a été soulevé dans ce commentaire: https://linuxfr.org/forums/linux-debian-ubuntu/posts/pour-utilisation-d-une-cle#comment-1872522

Notamment, les réponses d'Ysabeau:

Tu noteras la réponse de Bruno Michel à la deuxième entrée de suivi et celle de Benoît Sibaud sur la troisième.

Personnellement, j'y suis favorable et je pense qu'il y a un besoin. Après je ne sais pas trop comment ça fonctionne, désolée. Je vais signaler ton commentaire à la modération afin que les administrateurs le lisent et je te suggère de répondre à cette entrée de suivi.

Merci de ta proposition.

Sinon, je ne pense pas qu'il s'agisse d'un manque de volonté, mais plus d'un manque de mains pour faire le boulot. On manque de gens pour le développement du site en fait.

Et la réponse de Benoît:

Il n'y a pas de volonté de ne pas le faire. La seule contrainte me semble être la volumétrie de courriels et les règles semi-aléatoires de certains serveurs pour accepter ou non les courriels (ie. peut-être des soucis de fiabilité et/ou un plus gros risque de classement en spammeur de notre serveur de courriel). Mais ça ne devrait pas nous décider de mettre en place de la notification par courriel (ou autre).

Quand tu "run une image" pour reprendre tes mots[…]

Hum https://docs.docker.com/engine/reference/run/

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG…]

Et quand tu lis la documentation qui est juste avant:

Docker run reference

Docker runs processes in isolated containers. A container is a process which runs on a host.

Puis, tu lis la documentation juste après:

The docker run command must specify an IMAGE to derive the container from.

Je suis d'accord que la syntaxe donne l'impression de "run une image", mais en réalité tu run un container.

Ce n'est pas de la drosophilie avancée, c'est très important pour comprendre comment Docker fonctionne et comment il faut l'utiliser.

Le principe est qu'une image devrait toujours pouvoir être complètement détruite et, quand tu la rebuild avec un Dockerfile, tu retrouves le même résultat à peu près ("à peu près", car ça dépend des commandes exécutées pendant le build).

Le container par contre utilise l'image pour exécuter une commande et il n'y a plus de garantie sur l'état du système de fichier du container.

Ça permet aussi de garder un même volume entre plusieurs démarrages de container.

Je me suis même reposé la question et c'est pour ça que j'ai voulu précisé. Je me suis dis que si moi qui utilise docker régulièrement avait mal compris d'autres pourraient mal comprendre.

Ok, cette formulation n'était pas très précise.

Le but était surtout de préciser qu'un volume "nommé" a un nom fixe, qu'il peut être facilement identifiable sur la machine hôte.

En plus, comme son nom est fixe, il peut aussi facilement être réutilisé après avoir détruit son container. Il peut aussi être lié à d'autres containers (comme proposé par Psychofox pour les backups), mais dans ce cas, il faut faire très attention aux accès concurrents aux fichiers.

Non, non, une image est juste le résultat soit de:

• la fin d'un build de fichier Dockerfile
• un commit du système de fichier d'un container

L'image peut être vu comme un snapshot d'un système de fichier en lecture seule.

Quand tu "run une image" pour reprendre tes mots, en réalité tu fais ça :

• tu copies le système de fichier de l'image pour le passer en lecture/écriture pour le container (c'est le container niveau file system)
• tu attaches les volumes éventuels définis dans la commande "run" (ils sont créés s'ils n'existent pas déjà)
• tu lies les ports TCP de l'hôte sur ceux du container (si définis)
• … et d'autres liens entre le namespace du container et l'hôte, je ne connais pas toutes les options…
• enfin, dernière étape, dans le container une commande est exécutée. Soit celle définie dans la commande "run", soit la ligne CMD du Dockerfile, soit l'ENTRYPOINT de la commande ou du Dockerfile

Pour le point "copier le système de fichier de l'image", Docker utilise des systèmes de fichiers spécialisés qui ne nécessitent pas de faire une copie réelle, comme BTRFS et OverlayFS.

Si tu supprimes ton container sans avoir fait un "commit" de son système de fichier (c'est à dire créé une image depuis un système mouvant, c'est une mauvaise idée !) ni avoir mis les données dans un volume, alors tu perds ces données.

Si tu penses "redémarrer" comme uniquement "stop" et "start", alors oui, les données sont conservées. Mais ce n'est pas le cas intéressant de Docker.

Une image Docker ne démarre jamais ;-)

Le volume est attaché au container au moment où tu créés le container.

Avec un volume nommé, tu peux le réutiliser, même après avoir détruit le container original.

De même, comme l'a dit PsychoFox plus bas, tu peux l'attacher à plusieurs container en même temps (mais attention à la concurrence d'accès aux fichiers !).

Si jamais, on peut donner des noms aux volumes et tu retrouveras le dossier avec le nom correspondant sur l'hôte.

Ça permet aussi de garder un même volume entre plusieurs démarrages de container.

Bon pour vérifier la théorie, j'ai fais un rapide exemple avec un client JavaScript: https://projects.adorsaz.ch/adrien/example-refresh-token-for-linuxfr.org/-/blob/main/src/app.js

Ce client est vraiment stupide: il récupère l'access_token et le refresh_token et, tout de suite après, il essaie de rafraîchir l'access_token et il affiche tout ça dans le log du serveur.

Un exemple d'exécution sur ma machine me donne:

GET / - - 
code found:  ff48b...
Access token response (status: 200):  {
  access_token: '255367...',
  token_type: 'Bearer',
  expires_in: 86400,
  refresh_token: '140a2c...',
  scope: 'account',
  created_at: 1635286565
}
Refresh token response (status: 200):  {
  access_token: '40dd64...',
  token_type: 'Bearer',
  expires_in: 86400,
  refresh_token: '41566c....',
  scope: 'account',
  created_at: 1635286565
}
GET /?code=ff48b... - - 

Bien sûr, j'ai retiré mes token de l'exemple, mais je t'ai laissé les 6 premiers caractères pour que tu voies qu'ils ont bien changé.

Edit: Comme tu le vois dans le code, il faut faire attention à ce que le POST sur /token utilise le format x-www-form-urlencoded et non pas du JSON directement. C'est pour ça que j'utilise l'API URLSearchParams: https://github.com/node-fetch/node-fetch#post-with-form-parameters

Comme indiqué sur la page https://linuxfr.org/developpeur , en théorie Doorkeeper te permet de rafraîchir ton access_token grâce au refresh_token récupéré à la connexion de l'utilisateur.

Voir le chapitre Renewing the access token de la documentation de Doorkeeper.

Donc, en théorie un POST sur https://linuxfr.org/api/oauth/token avec ces informations devraient suffire:

{
"client_id": "l'identifiant publique de ton client",
"client_secret": "le secret de ton client",
"redirect_uri": "l'url que ton client écoute pour la redirection",
"grant_type": "refresh_token",
"refresh_token": "Le refresh_token reçu en même temps que ton premier access_token"
}

Mais je n'ai jamais utilisé l'API donc ça me sera difficile de t'en dire plus.

Est-ce que tu utilises une bibliothèque pour gérer OAuth ?

A ma connaissance il n'y a que Apple qui est plus correct sur la casse (minuscules la où il faut) mais pas vu de confirmation sur les accents.

On parle bien de l'auteur du clavier tactile d'iOS qui ne sait pas afficher les minuscules sur les touches ?

Edit: oh, ils savent le faire depuis iOS 9 😅

Dans le même genre que Postman, j'avais trouvé Insomnia (sous licence MIT) comme client d'API REST et qui peut être étendu avec des plugins.

Par exemple, j'emploie l'extension Global Header pour ajouter une en-tête Origin pour les APIs qui vérifient CORS. En plus de celle-ci j'emploie save access token pour configurer une en-tête Authorization avec un access token récupérer d'une requête OAuth2.

très complexe

Il s'agit seulement d'empêcher de voter dans son propre fil (ou sous ses propres commentaires si tu préfères). Faire apparaître une bulle d'aide explicative est simple.

L'ergonomie de LinuxFr laisse déjà à désirer et le système de karma est difficile à expliquer en quelques lignes.

Le fait de devoir ajouter une bulle d'aide explicative montre bien que l'on est en train de complexifier encore un peu plus ce système.

je vois déjà arriver des entrées de suivi

… dans ta boule de cristal ; tu ne peux quand même pas te servir de tes dons de voyance comme argument ? :-)

Je te retourne ton argument de la boule de cristal: comment peux-tu être sûr que les gens ont de la rancœur entre eux à cause des pertinents / inutiles de l'interlocuteur direct ?

C'est impossible à savoir: d'abord les votes sont anonymes, il est donc impossible d'être sûr de l'identité de(s) personne(s) qui ont moinssés. Ensuite, il faudrait faire un sondage global pour avoir le ressenti de tout le monde.

Je ne suis pas d'accord. Cette situation arrive fréquemment, on y retrouve les mêmes personnes qui ne se supporte plus et ont du mal à ne pas se rentrer dans le lard. Les moinssages attise leur rancœur l'une envers l'autre. Réduire l'énervement des uns et des autres est utile.

Si elles se rentrent déjà souvent dans le lard, je pense qu'il vaut mieux en parler avec l'équipe de modération et / ou administration, car ils ont les outils pour faire des rappels à la bonne conduite et appliquer des sanctions aux intervenants.

C'est bien pour ça que je laissais entendre que la réelle solution est l'ajout du code de bonne conduite comme proposé sur github et l'obligation de "signature" pour faire partie de la communauté LinuxFr.

Je ne suis pas la personne qui a voté sur ton entrée de suivi (d'ailleurs, elle est repassée à 0 depuis).

Par contre, je trouve que ça rend le système très complexe pour pas grand chose au final.

Pour le côté "très complexe", je vois déjà arriver des entrées de suivi du style "Pourquoi je ne peux pas pertinenter / inutiler certains commentaires ?", "Pourquoi je ne peux pas voter pour/contre les commentaires de Z ?"…

Pour le côté "pour pas grand chose", je pense qu'un seul vote "pertinent/inutile" sur un commentaire n'a pas beaucoup d'intérêt et ne permet pas de savoir si le commentaire est réellement pertinent ou inutile.

Au final, le plus important est d'apprendre aux utilisateurs de LinuxFr de se détacher du karma et des votes qui sont là plus pour la gestion du spam que pour la gestion de la communauté.

Un des points qui peut aider est la demande de signature d'un code de conduite, comme proposé sur github.

Si tu ne sais pas ce qu'est un reverse proxy, le plus simple est vraiment d'utiliser IPv6, car il permet d'avoir une adresse IP publique par machine. Comme chaque machine a une adresse publique, pas besoin de s'embêter avec un proxy.

Si tu n'as pas de réseau IPv6 et que tu as uniquement des services en HTTP, c'est assez simple de mettre en place un Apache ou Nginx en mode reverse proxy selon le nom de domaine à atteindre.

Si tu as d'autres outils beaucoup plus générique, il faudrait utiliser un proxy plus généraliste style "proxy sur TCP ou UDP" ou des tunnels SSH, mais dans ce cas je n'ai pas de connaissance.

La seul config que j'ai eu à faire: ajouter rootdelay=10 dans la config de Grub pour la commande linux. Et ça a été nécessaire parce qu'un de mes disques était en USB et il n'était pas disponible assez vite durant le boot.

En effet les raids 5 et 6 sont indisponibles, mais il y en a d'autres sympas comme "raid 1 sur 3 disque avec au moins 3 copies deds data".

Et si tu fais, avec 3 disques, un "raid 1 standard avec 2 copies", btrfs te permet d'utiliser la place disponible "en trop" pour augmenter la capacité en bit du système de fichier.

Avec Btrfs, ce qui m'a séduit, c'est que je n'avais pas pu mettre la couche "raid" au début, car je n'avais qu'un seul disque.

Quand j'ai ajouté un deuxième disque, j'ai pu dire à Btrfs "vas-y utilise ce deuxième disque pour faire du raid 1" et il l'a mis en place sans avoir eu besoin d'interrompre mon système.

C'est quand même bien plus souple que de devoir réinstaller toute la machine lors de l'arrivée du deuxième disque.

Un autre point séduisant de Btrfs est sa gestion des sous-volumes pour remplacer des dossiers et les partitions.

Comme tu peux ajouter des quotas aux sous-volumes, tu peux retrouver le même avantage que les partitions qui évitent que certaines données ne prennent trop de place.

En plus, comme tu peux faire des snapshots instantanés des sous-volumes, tu n'as même plus besoin de rsync pour faire des backups, Btrfs le fait en live et sans attente. Je ne l'ai pas encore essayé, mais tu peux même transmettre les snapshots d'un file système btrfs à un autre grâce à btrfs send | btrfs receive.

Pour administrer sa machine, il y a encore d'autres choses sympas comme la compression automatique des fichiers possible, la copie par référence, les checksums…

Et voilà le correctif dont je parlais: Pull Request 318.

Dans ce pull request, j'ajoute également les tests que j'ai écris actuellement pour le modèle des journaux, puisque c'est eux qui m'ont aidé à trouver ce bug.

Par curiosité, j'ai cherché avec git blame la source de la ligne de code qui change la licence (cité dans l'entrée de suivi plus haut; merci à vim-fugitive pour l'aide à la navigation avec le blame).

Je m'attendais à ce que, dans toute l'histoire, un malheureux commit aie inversé la valeur de cette ligne (soit en changeant le unless en if ou quelque chose du genre).

En réalité cette ligne a toujours été écrite ainsi (cf le commit d'origin, en mars 2011), et du coup, j'étais un peu déçu.

En réfléchissant un peu, je me suis dit que, en fait, si je relis en français cette ligne, elle dit met "vrai" pour le choix de la licence CC-BY-SA si c'était le cas sur le journal. Et donc, ça supposait, que le choix par défaut de la licence était false à l'époque et que, il fallait donc bien passer à true uniquement si le journal avait la licence CC-BY-SA.

Une très rapide recherche dans les migrations SQL, m'a confirmé que, lorsque l'on a crée ce code (en mars 2011), la valeur de cc_licensed par défaut était false et qu'elle a bougé à true en décembre 2012:

linuxfr.org $ git grep cc_licensed
20090105234709_create_nodes.rb:      t.boolean :cc_licensed,    null: false, default: false
20121216160203_change_default_for_cc_licensed.rb:      t.change_default :cc_licensed, true

L'intention du code correspondait donc bien en 2011 à ce que je proposais dans le suivi, mais il n'a pas survécu au changement de valeur par défaut 1 année plus tard. Je vais proposer un correctif, maintenant que l'histoire m'a confirmé mon intuition :)

J'ai ajouté un petit texte dans le wiki :)

https://linuxfr.org/wiki/aide-edition/revisions/88

Le sommaire est crée automatiquement à partir de 5'000 caractères dans la seconde partie.

Là, LibreOffice me dit qu'il y a 2'974 caractères dans la seconde partie.

Il n'y a donc pas assez de caractères dans le rendu de la seconde partie (et non pas dans le markdown).

Merci pour l'idée du flux RSS, je n'y avais pas pensé :)

J'ai proposé le correctif sur Github.

Ça ajoute une page /comments/latest accessible par tous, car il n'y a pas d'informations spécifiques aux modérateurs et que ça permettait d'avoir un flux RSS publique.

Comme il y a environ 1500 à 2000 commentaires chaque 15 jours sur LinuxFr (donc environ 100 à 150 par jours), j'ai fais en sorte que l'on aie 50 commentaires affichés par page. Ce nombre 50 est lui-même lié au nombre d'entrées dans le flux RSS. J'espère que ça suffira pour le flux.

Les commentaires des 7 derniers jours y sont accessibles.

Hello,

Je vais essayer de reprendre un peu de temps pour le développement et je vais commencer par cette entrée.

J'aurai besoin de plus de précisions:

• à quoi pensez-vous quand vous dites les derniers commentaires sur le site ? Une limite comme les 200 derniers commentaires ou plutôt une limite comme les commentaires des 7 derniers jours ?

• je n'ai pas compris le terme pagination sur l'index ? Est-ce que c'est la profondeur de la position dans le fil de commentaire ?

Hello,

J'ai entendu parlé de "App Icon Preview": https://flathub.org/apps/details/org.gnome.design.AppIconPreview

D'après la description c'est prévu pour aider à faire des icônes pour GNOME. Peut être que ça peut t'aider ?

J'ai juste entendu parler du nom.de l'appli, je ne l'ai pas essayée moi même…

Au fait, il me semble que l'analyse de la syntaxe du code, c'est typiquement une des tâches du Langage Server Protocol proposé par VSCode. Il devrait être capable de résoudre ce genre de cas que tu as remonté.

Ça paraît un peu lourd de sortir LSP pour de la coloration syntaxique, mais finalement, quand on ouvre des codes sources (en C/C++ ou autre), on va avoir rapidement besoin de l'aide d'un mini-IDE, non ?

Comme pour les DRMs pour le streaming : s'ils n'implémentent pas, alors pas d'accès au contenu.

Ça ne sera pas que dans le navigateur, mais dans l'OS aussi, c'est ce que prévoit Windows 11 apparemment.