Posté par barmic 🦦 le 18 août 2020 à 17:15. En réponse au lien Notepad++ bloqué en Chine. Évalué à  2.
Dans ce cas-là , je ne vois pas de lien de soutien entre l'utilisation du logiciel et le soutien aux idées de l'auteur.
Pourquoi est-ce qu'on entends parler de lui à chaque fois qu'il poste un tweet colérique ? C'est la popularité de son logiciel qui lui donne cette tribune. Donc oui en utilisant son logiciel tu contribue à sa tribune. Même si tu n'est pas au courant de ses positions d'ailleurs.
On peut dire la mĂŞme chose de Linus Torvalds dont on reprend tous ses coups de gueules. On parle moins de ceux de Theo De Raadt par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Posté par barmic 🦦 le 18 août 2020 à 16:51. En réponse au lien Notepad++ bloqué en Chine. Évalué à  5.
Moi je pense que c'est tout l'inverse. On l'a vu avec le débat du retrait de la blague sur l'avortement de la fonction C abort sur la mailing list de glibc. On créé de la polémique, du débat et des flamewars inutiles.
Je vois tout de même une grande différence entre tenter de pousser ses idées via son logiciel (si vous votez FN, désinstallez mon logiciel) et ce qui relève de la politique interne d'un logiciel. À partir du moment où tu collabore au sein d'un projet tu as de la politique par construction et affirmer que c'est inutile est une position politique. On ne peux pas vouloir travailler ensemble et chercher à occulter tout ce qui concerne le vivre ensemble.
Je comprends que comme ce n'est pas directement du code/test/documentation ça paraît de la perte de temps, mais c'est comme les tests, on perds plus de temps en essayant de faire diversion qu'en faisant un choix et en avançant. Même si évidement un choix peut avoir des conséquences et doit être assumé. Mais c'est aussi le cas avec des choix techniques comme quand Debian a choisi systemd et que Devuan a était créé pour l'occasion.
Posté par barmic 🦦 le 18 août 2020 à 14:12. En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  3.
Ah bien vu. Je ne l'avais pas vu comme ça.
Posté par barmic 🦦 le 18 août 2020 à 12:16. En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  -2.
Tu décris un objectif de non-neutralité. Pour rappel :
le droit des utilisateurs « d’accéder aux informations et aux contenus et de les diffuser, d’utiliser et de fournir des applications et des services et d’utiliser les équipements terminaux de leur choix, quel que soit le lieu où se trouve l’utilisateur final ou le fournisseur, et quels que soient le lieu, l’origine ou la destination de l’information, du contenu, de l’application ou du service, par l’intermédiaire de leur service d’accès à l’internet ».
C'est moi qui graisse. Tiré de l'arcep.
Je suis d'accord qu'on peut trouver des raisons de le mettre en place.
Posté par barmic 🦦 le 18 août 2020 à 10:25. En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  4.
Et c'est pas du profilage ?
Posté par barmic 🦦 le 18 août 2020 à 10:01. En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  1.
au revenu moyen des habitants du code postal associé. Parfait pour les publicités ciblées.
En même temps ça sert à quoi ce genre de trucs à part :
Posté par barmic 🦦 le 18 août 2020 à 08:58. En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  10.
C'est une bibliothèque écrite en C sous licence GPLv2
J'étais surpris et en vérifiant c'est du LGPLv2.1.
Posté par barmic 🦦 le 17 août 2020 à 09:10. En réponse au journal S'abonner par email à un site statique ?. Évalué à  2.
Je pense que c'est le plus pertinent oui[…]
Il faut pouvoir désactiver les envoies de mails par les utilisateurs. Ces solutions sont généralement faites pour servir de "forum mail" (type LKML par exemple).
Si tu envoies trop de mails avec un compte "normal" ça risque bien d'arriver.
De ce que je vois du blog de ploum ou parle ~20 mails/an, je ne sais pas combien de destinataire il espère.
Posté par barmic 🦦 le 17 août 2020 à 09:07. En réponse au journal S'abonner par email à un site statique ?. Évalué à  3.
J'oubliais, une particularité, le hook est ici sur le dépot bare[…]
Oui oui, mon exemple c'est surtout parce que si tu utilise un server git hébergé tu n'a pas le loisir d'ajouter un hook sur le serveur, il faut passer par des CI. Ce n'est pas impossible, mais c'est différent.
Je rejoins les avis du dessous pour garder les choses séparées et donc d'avoir une mailing-list à part.
La plupart des solutions de mailing présentées sont faites pour gérer des mailinglist complète qui servent à échanger (des forum en mail). Ce qui me semble gros pour un usage simple.
Posté par barmic 🦦 le 16 août 2020 à 00:51. En réponse au journal S'abonner par email à un site statique ?. Évalué à  4.
Tu veux publier via un git push, donc envoie tes mails via un git push :)
Il y a juste à gérer l'inscription. Selon le trafic tu peux gérer ça manuellement sinon ça dépend de ce que tu as comme serveur (si tu es root ou si c'est un lamp par exempl).
Posté par barmic 🦦 le 16 août 2020 à 00:27. En réponse au journal YaCy, David(s) contre Googliath. Évalué à  6.
Une partie non négligeables des sites n'envoient pas de contenu avec le html, c'est le js qui va chercher le contenu recherché dans des webservices. Au final un proxy voit passer des "trucs", mais la notion de page il ne la vois pas. Bien sûr ça reste du contenu indexable, mais dans ta recherche, tu va tomber sur du json (voir sur du js…) pas forcément très digeste, tu n'aura pas forcément le contexte qui va avec.
C'est une problématique avec la quelle on doit vivre pour les moteurs de recherche classiques (voir cette page d'explication de google).
Posté par barmic 🦦 le 15 août 2020 à 22:03. En réponse au journal YaCy, David(s) contre Googliath. Évalué à  4.
ça fonctionne pour autre chose que les pages générées côté serveur?
Posté par barmic 🦦 le 15 août 2020 à 22:01. En réponse au journal YaCy, David(s) contre Googliath. Évalué à  2.
Ce qui reste très limité et il ne connaît pas la notion de site, les recherches perdent la temporalité, la recherche n'est pas texteplain,….
Posté par barmic 🦦 le 14 août 2020 à 18:53. En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
la communauté LinuxFR ne me semble pas très accueillante
Tu m'en vois désolé.
des personnes qui lisent articles de travers.
Autant je suis d'accord qu'il y a méprise, autant je vois passer beaucoup trop de bench qui ne sont que des concours de pénis pour méfiants quand il y a à mon avis que très peu d'explications.
Une dernière fois, désolé que la discussion se soit trop envenimée.
Posté par barmic 🦦 le 14 août 2020 à 18:49. En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
C'est justement ce qui est intéressant, si je présentais l'article sans le benchmark, le reproche serait "Mais quid de la performance, est-ce que Nim joue dans la même classe que C ou C++?".
Je comprends, ça n'aurait pas était mon cas donc je ne l'ai pas vu comme ça.
Le but du bench à la base est de valider que ma librairie de parallélisme Weave scale a minima comme OpenMP.
Je comprends, c'est tellement peu dis que je ne l'ai pas intégré.
Je fournis plus d'analyse sur la partie multithreadée du bench ici https://github.com/mratsim/weave/tree/master/demos/raytracing.
Ah oui c'est plus complet :)
Le bench single-threadé est pour moi une baseline (i.e. s'il y a un écart important mon code est buggué) mais utilisée ici pour rassurer quant à la performance, les personnes familières avec Nim savent que porter 1->1 du code C ou C++ (sans inheritance) en Nim donne les mêmes performances peu ou prou quelques pourcents.
D'acc je comprends la démarche
Posté par barmic 🦦 le 14 août 2020 à 15:26. En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
L'idée est d'avoir un bench complètement compute-bound (et non pas memory-bound comme la multiplication de matrice) pour vérifier si j'ai bien un speed-up de 18x sur ma machine avec 18 coeurs.
En relisant 2 fois l'article (une fois en diagonale et une seconde fois plus attentivement), j'ai retrouvé la mention. C'est dommage de ne pas l'avoir plus mis en avant.
Posté par barmic 🦦 le 14 août 2020 à 15:21. En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
Salut,
C'est cool de venir répondre.
Quelle partie de ma démarche est mauvaise?
En fait il n'y a pas grand chose à tirer d'un benchmark qui ne donne qu'une valeur (ou un moyenne sur plusieurs lancements). Est-ce que ça vient d'un overhead initial qui est constant ? Vu comme les résultats sont proches (je suis même pas certains qu'on ne soit pas dans la variance) il est possible que le moindre changement de paramètre donne un effet dans un sens ou un autre. Du coup je ne vois pas trop qu'est-ce que l'on peut tirer de ce bench.
Le bench est juste la première partie de l'article
Tout à fait et c'est intéressant, mais le fais d'avoir mis en avant la partie bench + le titre qui a était donné ici (je sais que ce n'est pas de toi) m'a fait un peu sur-réagir. Mais je maintiens que le bench est loin de donner suffisamment d'informations (la variance des run, faire varier les entrées, voir expliquer l'enjeux du bench,…) pour être utile.
Ce que je vois surtout ici c'est une attaque sans raison "qui manque d’honnêteté", à part clarifier que tu n'as pas lu le code et que tu pars d'un biais négatif de base.
Avant de lire un livre j'en lis la préface :) Sincèrement la seconde partie m'a vraiment intéressée, c'est juste le bench qui en soit ne donne pas assez d'info que je lise ou non le code n'y changera rien.
Je suis désolé d'avoir parler d’honnêteté intellectuelle. Mes mots ont largement dépassés mes pensées.
Posté par barmic 🦦 le 14 août 2020 à 10:45. En réponse au journal YaCy, David(s) contre Googliath. Évalué à  5.
lorsque ma part de l’index atteint cette limite, je veux que mon instance arrête de crawler et se contente de servir ce qu’elle a déjà indexé
Il ne serait pas mieux de continuer à crawler et de supprimer ce qui a était le moins lu/plus vieux ? (une sorte de LRU.
Posté par barmic 🦦 le 14 août 2020 à 09:01. En réponse au journal YaCy, David(s) contre Googliath. Évalué à  4. Dernière modification le 14 août 2020 à 09:02.
On appellerait ça historique et ça pourrait être inclus dans les navigateurs !
Je te charrie :p (_Edit: pff j'ai mis trop de temps :$)
Il y a pleins de limitations que je trouve dommage dans les historiques. La dernière fois que nous en avions parlé quelqu'un avait parlé de memex qui a l'air pas mal (je ne l'ai pas vraiment essayé).
En n'ayant indexé que ce que j'ai déjà consulté, ce serait bcp plus efficace que de relancer les mastodontes comme Google.
Tu as l'historique goog… euh… wait!
Posté par barmic 🦦 le 13 août 2020 à 17:58. En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  3.
Et cela avait duré très longtemps … c'est pareil sous Linux ?
Ça dépend des paramètres que tu lui donne. Par défaut il ne fait que 3 itération et je crois qu'il utilise /dev/urandom. Donc ça va. Mais tu peux lui demander d'en faire 5435 et de partir de /dev/random. Ça doit laisser le temps d'aller se promener.
/dev/urandom
/dev/random
Posté par barmic 🦦 le 13 août 2020 à 17:51. En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  0.
Pour te simplifier la vie. J'ai répondu dans un autre commentaire à tes 6 questions. En espérant que ça fasse un peu moins mille-feuilles.
Posté par barmic 🦦 le 13 août 2020 à 17:49. En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  3.
Peux-tu copier/coller mon texte où je prétends que c'est facile à faire ?
Si comme tu le dis c'est facile à expliquer et difficile à implémenter, c'est que ça ne doit pas être aussi facile à expliquer. Le reste de ton commentaire le montre bien. On connais tous les 3~4 principes de bases (et encore on est pas tout à fait d'accord). C'est bien, mais ça pose un certains nombre de questions qui n'ont rien de triviales.
Posté par barmic 🦦 le 13 août 2020 à 17:43. En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  1.
Estimes-tu que j'ai mal compris le besoin ?
Oui clairement et tu as préférer juger ton interlocuteur que de te poser la question.
Si oui, quel était le besoin de l'auteur du post ?
Il l'a explicité.
As-tu des arguments contre la facilité à trouver que la méthode validée depuis longtemps est du hachage, et qu'il est sain de limiter le nombre de tentatives ?
C'est tellement facile à trouver que je ne vois rien de sain dans le fais de limiter le nombre de tentatives (hors cas très particulier).
As-tu des arguments sérieux contre le hachage + sel ?
Non.
As-tu des arguments sérieux contre la limitation du nombre de tentatives ?
Oui pleins (facilement contournable, ça gène plus l'utilisateur que l'attaquant, ça permet de bloquer des comptes aussi, ça n'est pas fiable,…). Ça ne fonctionne globalement pas c'est bien pour ça que personne ne s'en sert.
Posté par barmic 🦦 le 13 août 2020 à 16:49. En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  0.
Jusqu'à présent c'est toi qui distribue les qualificatifs péjoratifs à mon encontre. Chose que tu ne ferais probablement pas en présence physique.
Tu aurais envoyé :
Si tu n'as pas trouvé l'information de base en moins de 5 minutes alors tu n'as pas choisi le bon métier.
À quelqu'un que tu ne connais pas s'il était devant toi ?
Personnellement oui il m'est arrivé de dire devant quelqu'un qu'il ne devrait pas tenir de tel propos et pas forcément aussi tranquillement que là .
Posté par barmic 🦦 le 13 août 2020 à 14:42. En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  3.
humour (issue de fortune des années 1990) : /usr/earth is 98% full … delete anyone you can
humour (issue de fortune des années 1990) :
/usr/earth is 98% full … delete anyone you can
T'inquiète on a planifié un shred (c'est juste pour la blague je suis loin d'être pessimiste).
[^] # Re: Hypothèses
Posté par barmic 🦦 . En réponse au lien Notepad++ bloqué en Chine. Évalué à  2.
Pourquoi est-ce qu'on entends parler de lui à chaque fois qu'il poste un tweet colérique ? C'est la popularité de son logiciel qui lui donne cette tribune. Donc oui en utilisant son logiciel tu contribue à sa tribune. Même si tu n'est pas au courant de ses positions d'ailleurs.
On peut dire la mĂŞme chose de Linus Torvalds dont on reprend tous ses coups de gueules. On parle moins de ceux de Theo De Raadt par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Hypothèses
Posté par barmic 🦦 . En réponse au lien Notepad++ bloqué en Chine. Évalué à  5.
Je vois tout de même une grande différence entre tenter de pousser ses idées via son logiciel (si vous votez FN, désinstallez mon logiciel) et ce qui relève de la politique interne d'un logiciel. À partir du moment où tu collabore au sein d'un projet tu as de la politique par construction et affirmer que c'est inutile est une position politique. On ne peux pas vouloir travailler ensemble et chercher à occulter tout ce qui concerne le vivre ensemble.
Je comprends que comme ce n'est pas directement du code/test/documentation ça paraît de la perte de temps, mais c'est comme les tests, on perds plus de temps en essayant de faire diversion qu'en faisant un choix et en avançant. Même si évidement un choix peut avoir des conséquences et doit être assumé. Mais c'est aussi le cas avec des choix techniques comme quand Debian a choisi systemd et que Devuan a était créé pour l'occasion.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Usage
Posté par barmic 🦦 . En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  3.
Ah bien vu. Je ne l'avais pas vu comme ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Usage
Posté par barmic 🦦 . En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  -2.
Tu décris un objectif de non-neutralité. Pour rappel :
C'est moi qui graisse. Tiré de l'arcep.
Je suis d'accord qu'on peut trouver des raisons de le mettre en place.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Usage
Posté par barmic 🦦 . En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  4.
Et c'est pas du profilage ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Usage
Posté par barmic 🦦 . En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  1.
En même temps ça sert à quoi ce genre de trucs à part :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Licence
Posté par barmic 🦦 . En réponse au journal libloc, l'alternative à GeoIP/GeoLite. Évalué à  10.
J'étais surpris et en vérifiant c'est du LGPLv2.1.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: maillist
Posté par barmic 🦦 . En réponse au journal S'abonner par email à un site statique ?. Évalué à  2.
Il faut pouvoir désactiver les envoies de mails par les utilisateurs. Ces solutions sont généralement faites pour servir de "forum mail" (type LKML par exemple).
De ce que je vois du blog de ploum ou parle ~20 mails/an, je ne sais pas combien de destinataire il espère.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: git
Posté par barmic 🦦 . En réponse au journal S'abonner par email à un site statique ?. Évalué à  3.
Oui oui, mon exemple c'est surtout parce que si tu utilise un server git hébergé tu n'a pas le loisir d'ajouter un hook sur le serveur, il faut passer par des CI. Ce n'est pas impossible, mais c'est différent.
La plupart des solutions de mailing présentées sont faites pour gérer des mailinglist complète qui servent à échanger (des forum en mail). Ce qui me semble gros pour un usage simple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# git
Posté par barmic 🦦 . En réponse au journal S'abonner par email à un site statique ?. Évalué à  4.
Tu veux publier via un git push, donc envoie tes mails via un git push :)
Il y a juste à gérer l'inscription. Selon le trafic tu peux gérer ça manuellement sinon ça dépend de ce que tu as comme serveur (si tu es root ou si c'est un lamp par exempl).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moteur perso ?
Posté par barmic 🦦 . En réponse au journal YaCy, David(s) contre Googliath. Évalué à  6.
Une partie non négligeables des sites n'envoient pas de contenu avec le html, c'est le js qui va chercher le contenu recherché dans des webservices. Au final un proxy voit passer des "trucs", mais la notion de page il ne la vois pas. Bien sûr ça reste du contenu indexable, mais dans ta recherche, tu va tomber sur du json (voir sur du js…) pas forcément très digeste, tu n'aura pas forcément le contexte qui va avec.
C'est une problématique avec la quelle on doit vivre pour les moteurs de recherche classiques (voir cette page d'explication de google).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moteur perso ?
Posté par barmic 🦦 . En réponse au journal YaCy, David(s) contre Googliath. Évalué à  4.
ça fonctionne pour autre chose que les pages générées côté serveur?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moteur perso ?
Posté par barmic 🦦 . En réponse au journal YaCy, David(s) contre Googliath. Évalué à  2.
Ce qui reste très limité et il ne connaît pas la notion de site, les recherches perdent la temporalité, la recherche n'est pas texteplain,….
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aie mes yeux...
Posté par barmic 🦦 . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
Tu m'en vois désolé.
Autant je suis d'accord qu'il y a méprise, autant je vois passer beaucoup trop de bench qui ne sont que des concours de pénis pour méfiants quand il y a à mon avis que très peu d'explications.
Une dernière fois, désolé que la discussion se soit trop envenimée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aie mes yeux...
Posté par barmic 🦦 . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
Je comprends, ça n'aurait pas était mon cas donc je ne l'ai pas vu comme ça.
Je comprends, c'est tellement peu dis que je ne l'ai pas intégré.
Ah oui c'est plus complet :)
D'acc je comprends la démarche
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aie mes yeux...
Posté par barmic 🦦 . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
En relisant 2 fois l'article (une fois en diagonale et une seconde fois plus attentivement), j'ai retrouvé la mention. C'est dommage de ne pas l'avoir plus mis en avant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aie mes yeux...
Posté par barmic 🦦 . En réponse au lien Nim plus rapide que C++ sur du ray tracing. Évalué à  2.
Salut,
C'est cool de venir répondre.
En fait il n'y a pas grand chose à tirer d'un benchmark qui ne donne qu'une valeur (ou un moyenne sur plusieurs lancements). Est-ce que ça vient d'un overhead initial qui est constant ? Vu comme les résultats sont proches (je suis même pas certains qu'on ne soit pas dans la variance) il est possible que le moindre changement de paramètre donne un effet dans un sens ou un autre. Du coup je ne vois pas trop qu'est-ce que l'on peut tirer de ce bench.
Tout à fait et c'est intéressant, mais le fais d'avoir mis en avant la partie bench + le titre qui a était donné ici (je sais que ce n'est pas de toi) m'a fait un peu sur-réagir. Mais je maintiens que le bench est loin de donner suffisamment d'informations (la variance des run, faire varier les entrées, voir expliquer l'enjeux du bench,…) pour être utile.
Avant de lire un livre j'en lis la préface :)
Sincèrement la seconde partie m'a vraiment intéressée, c'est juste le bench qui en soit ne donne pas assez d'info que je lise ou non le code n'y changera rien.
Je suis désolé d'avoir parler d’honnêteté intellectuelle. Mes mots ont largement dépassés mes pensées.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Vieille expérience
Posté par barmic 🦦 . En réponse au journal YaCy, David(s) contre Googliath. Évalué à  5.
Il ne serait pas mieux de continuer à crawler et de supprimer ce qui a était le moins lu/plus vieux ? (une sorte de LRU.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Moteur perso ?
Posté par barmic 🦦 . En réponse au journal YaCy, David(s) contre Googliath. Évalué à  4. Dernière modification le 14 août 2020 à 09:02.
On appellerait ça historique et ça pourrait être inclus dans les navigateurs !
Je te charrie :p (_Edit: pff j'ai mis trop de temps :$)
Il y a pleins de limitations que je trouve dommage dans les historiques. La dernière fois que nous en avions parlé quelqu'un avait parlé de memex qui a l'air pas mal (je ne l'ai pas vraiment essayé).
Tu as l'historique goog… euh… wait!
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: une question de cout
Posté par barmic 🦦 . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  3.
Ça dépend des paramètres que tu lui donne. Par défaut il ne fait que 3 itération et je crois qu'il utilise
/dev/urandom. Donc ça va. Mais tu peux lui demander d'en faire 5435 et de partir de/dev/random. Ça doit laisser le temps d'aller se promener.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  0.
Pour te simplifier la vie. J'ai répondu dans un autre commentaire à tes 6 questions. En espérant que ça fasse un peu moins mille-feuilles.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  3.
Si comme tu le dis c'est facile à expliquer et difficile à implémenter, c'est que ça ne doit pas être aussi facile à expliquer. Le reste de ton commentaire le montre bien. On connais tous les 3~4 principes de bases (et encore on est pas tout à fait d'accord). C'est bien, mais ça pose un certains nombre de questions qui n'ont rien de triviales.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  1.
Oui clairement et tu as préférer juger ton interlocuteur que de te poser la question.
Il l'a explicité.
C'est tellement facile à trouver que je ne vois rien de sain dans le fais de limiter le nombre de tentatives (hors cas très particulier).
Non.
Oui pleins (facilement contournable, ça gène plus l'utilisateur que l'attaquant, ça permet de bloquer des comptes aussi, ça n'est pas fiable,…). Ça ne fonctionne globalement pas c'est bien pour ça que personne ne s'en sert.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les techniques de sécurités
Posté par barmic 🦦 . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  0.
Tu aurais envoyé :
À quelqu'un que tu ne connais pas s'il était devant toi ?
Personnellement oui il m'est arrivé de dire devant quelqu'un qu'il ne devrait pas tenir de tel propos et pas forcément aussi tranquillement que là .
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: une question de cout
Posté par barmic 🦦 . En réponse au journal sécurité, trop de sécurité, pas de sécurité?. Évalué à  3.
T'inquiète on a planifié un shred (c'est juste pour la blague je suis loin d'être pessimiste).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll