J'en veux pour preuve qu'on pourrait avoir la même conversation au sujet de gmail par exemple.
Non, parce que la structure du problème fait qu'un réseau fédéré comme l'e-mail se prête beaucoup mieux à la co-existence de plusieurs acteurs. Ils peuvent s'échanger des données, il n'existe pas d'authentification unique des utilisateurs (d'où les problèmes de l'e-mail, d'ailleurs), etc.
Je te laisse te renseigner sur l'histoire de la lutte contre les monopoles aux USA pour voir la violence que ça peut avoir.
Genre la violence que ça a été contre Microsoft ? LOL.
L'intérêt c'est que ça marchera aussi pour les mails, pour la vente en ligne d'Amazon,…
Les mails j'ai expliqué plus haut, la vente en ligne je ne sais pas trop quoi en penser, ça devrait être quelque-chose de difficilement « hégémonisable » mais Amazon y arrive quand même… Mais pour les réseaux sociaux par exemple, c'est comme la recherche, la tendance naturelle est à l'hégémonie d'un acteur. D'où l'impossibilité pour moi d'avoir un réseau social généraliste en démocratie : il finira hégémonique et abusif, comme l'est Facebook. Il faut l'interdire. Il ne pourra jamais y avoir de politique de modération de contenu globale qui satisfasse assez de monde, ou alors ça sera un « Meilleur des mondes » façon Huxley ou Orwell.
C'est pareil pour toutes les choses qui ont une architecture non-fédérée en général. Le modèle fédéré n'est pas seulement bon pour la diversité technique, mais pour les libertés fondamentales également.
L'idée est juste de mettre en surbrillance ou d'une couleur différente le/les résultats présents dans plusieurs moteur, pas de combiner les résultats pour en faire une liste, pas de faire un classement. Juste afficher les résultats de plusieurs moteur cote à cote. Quitte à faire des roulements pour pas surcharger
Donc tu présentes les résultats dans quel ordre ? Tu vas jusqu'à quelle profondeur pour voir les entrées similaires ? Cote à cote sur combien de colonnes ? Quels sont les moteurs « élus » ? Tu roules sur quelle période, quel critère, etc ? Toutes ces choses sont sujettes à des biais, et Google même joue dessus pour mettre ses propres produits en avant. Il n'existe pas à ma connaissance de solution réaliste à ce genre de truc.
On parle de ta proposition : le retour des webring et la disparition des moteurs de recherche
Oui, et je maintiens que c'est la bonne. Après, je ne suis pas contre des moteurs thématiques, ou centrés sur un domaine particulier. Ça pose toujours des problèmes, mais de moindre envergure qu'un moteur généraliste unique.
Si pour toutes les questions de codages je ne m'adresse que à stack overflow, et que tout le monde fait de même, developppez, ou même la partie question de linuxfr.
C'est toujours mieux qu'un moteur pour tout.
Personnellement j'essaye d'utiliser les autres moteurs, principalement ddg,
… qui utilise google, sans intérêt (à long terme).
mais il m'arrive aussi de faire des recherches sur yandex ou baidu.
Je ne connais pas leurs méthodes, c'est tant mieux s'ils crawlent eux-même, mais ça reste le problème d'un moteur hégémonique, pour une population donnée : qu'il n'y ait que yandex pour tous les russes ou que baidu pour les chinois, ça n'est pas acceptable selon moi, mais bon c'est leur problème.
Le retour des web-ring, bientôt on assistera à la résurrection des site multimania !!! Whaou que c'est sexy…
Il faut être « sexy » pour être démocratique ? Parce que quelque-chose est ancien, il est forcément « has-been » ?
Je suis d'accord, mais ta proposition fait revenir 20 ans en arrière
Je te rappelle que c'était mieux avant :-)
il vaudrait mieux implémenter dans les navigateur un système de multi-requête
Ta proposition m'a l'air irréaliste : comparer les résultats ça n'intéresse personne à part trois geeks dans leur garage. Et ton début de proposition de résolution algorithmique est bancal.
Non, j'y ai bien réfléchi, et pour moi la seule solution est d'interdire les moteurs généralistes. Je veux bien discuter si quelqu'un a une meilleure idée…
C'est remplacer l'hégémonie d'un moteur par celle de plusieurs site, empêchant ainsi l’émergence de nouveau site
J'avoue qu'on ne m'avait encore jamais sorti cet argument… outre que parler « d'hégémonie » de plusieurs sites n'a pas de sens, arguer que plusieurs puissances seraient dommageables pour la « diversité » (si j'interprète bien) insinue que la découverte de nouvelles sources serait impossible sans Google, ce qui est à mon avis faux car ce que présente ce un moteur de recherche moderne est toujours influencé par des choix arbitraire et non uniquement une sorte d'algorithme « juste ».
C'est bien la dépendance à un oracle omniscient pour effectuer toutes nos tâches que j'essaye de dénoncer ici : tu es tellement dépendant d'une unique source de recherche que tu as peur des autres modèles, et ta croyance même en l'existence d'une source soit-disant équitable pour tout le monde t'aveugle sur la réalité du pouvoir que ce modèle implique. Selon moi, il est impossible d'avoir un modèle de société démocratique avec un moteur de recherche comme celui-ci. Enfin, « moteur de recherche » c'est son nom mais c'est beaucoup plus que ça aujourd'hui, puisque c'est un moteur de prédiction de la pensée vu que chaque touche appuyée sur chaque périphérique branché à ce grand cerveau centralisé est analysée pour afficher en direct des « suggestions » que beaucoup vont suivre sans se pencher un instant sur la modification du chemin cognitif induite par ce superbe mécanisme (il faut l'avouer, c'est très balèze techniquement).
Découvrir de nouvelles sources, c'est quelque-chose qu'on fait régulièrement, puisque les sites vont et viennent, à échelle plus ou moins longue. On a une manière pratique mais non-découvrable d'y accéder, c'est le DNS, mais le Web a été conçu avec des URI formables par des humains pour une raison : pour qu'on puisse les taper et les échanger facilement. Et il peut bien sûr exister des sites que te font découvrir d'autres sites, ou qui agrègent leur contenus, ou qui sont charger de centraliser les adresses d'autres ; on a plein de moyens de découvrir de nouvelles sources. Mais qu'il existe un unique moyen d'y accéder, ayant pouvoir de vie ou de mort sur tout le reste, ça n'est pas acceptable selon moi. Même si sans lui, la découvrabilité en souffrira, mais c'est le prix à payer.
De ce que je comprends de l'histoire, on a Jonathan Lemon, un BSDiste ancien pas inconnu (auteur de kqueue), qui bosse aujourd'hui pour Facebook et qui envoie un patch de son adresse perso pour lier spécifiquement des GPU Nvidia à des cartes Ethernet Mellanox en utilisant l'infra du kernel. L'exemple d'utilisation est du Machine Learning sur GPU où les données transitent directement par la carte réseau à 200 Gbps (!) car sinon le bridge PCI-Express qui échangerait avec le CPU sature dans ce cas-là… Son truc est spécifique à son montage, et n'utilise pas l'infra de DMA inter-périphérique (p2p_dma) qui se trouve être une interface indiquée comme propageant là GPL pour tout code qui s'y lie ; coïncidence ou hasard… Il se trouve qu'en plus il dit ne pas avoir exporté les symboles de sa nouvelle API en _GPL car « c'était trop long à taper », ce qui pour une personne de sa trempe et vu le contexte (développement spécifique à Facebook, Nvidia toujours à vouloir niquer la GPL) s'est vu qualifier de trollage par Christoph Hellwig, développeur vétérant du kernel bien connu pour sa défense du Libre et de la GPL.
Le patch proposé par Hellwig que tu montres après est très intéressant, car effectivement il semble avoir été écrit pile pour contrer ce genre de code, et les datent concordent (fin juillet dernier, ce dernier patch arrivant juste après l'incident ci-dessus) : les modules type « shim » qui sont là uniquement pour faire une interface sans valeur dans le but uniquement de lier un module à licence propriétaire — chose normalement proscrite par la GPL, mais que Nvidia utilise depuis plus de 10 ans, malgré les critiques de Torvalds et d'autres — deviennent rejetés. La discussion est ici : https://lore.kernel.org/lkml/20200730061027.29472-1-hch@lst.de/
Mais est-ce vraiment le problème actuellement rencontré pour le driver Nvidia en 5.9 ?
Si vous ne souhaitez pas vous amuser à toujours courir après les mécanismes de Google pour contrer ceux qui essayent de protéger leur vie privée, vous pouvez également désactiver le Javascript et les meta refresh dans votre browser : les pages servies ainsi contiennent uniquement les liens directs.
Pour le JS vous avez plein d'extensions pour le désactiver, pour les redirections (plus précisément la balise meta refresh qui vous redirige vers une page contenant les redirections) c'est accessibility.blockautorefresh=true dans about:config. Attention, ça bloque tous les refresh utilisées sur le Web : ça vous mettra un message de blocage du refresh sur pas mal de sites, à vous de le suivre (ou pas).
En fait, Google est un peu retors, même avec les gens qui n'ont pas de JS, car même s'ils sont les pros des technos modernes de traçage, ils sont aussi quand même les pros de la rétro-compatibilité, et c'est pour ça qu'ils continuent de dominer : la page servie de base est toute basique avec des liens directs, ce qui permet à n'importe quel browser le plus ante-diluvien de continuer à fonctionner avec. Ensuite, une balise meta refresh vous redirige vers une page qui contient des liens redirigés pour comptabiliser le nombre de clics. Je suppose qu'ils sont ensuite transformés en lien directs par du JS afin que vous ayez l'impression que quand vous cliquez ça va être un lien direct. Puis au moment du clic intervient le callback qui va en faire un lien redirigé. Si c'est pas vicieux…
La dernière solution c'est d'essayer de ne pas utiliser Google, pas en choisissant un moteur alternatif car ceux-ci sont condamnés à courir derrière le leader incontesté, mais plutôt en essayant de voir comment vos « besoins de recherche » sont mieux satisfait sur des moteurs plus spécifique, comme celui de Wikipédia pour chercher un nom, openstreetmap pour chercher une localisation, n'importe quel dictionnaire en ligne pour chercher une traduction, stackoverflow pour chercher une erreur, etc. Vous verrez, vous vous en porterez mieux.
Perso, j'ai souvenir de ces redirections et d'extensions Firefox pour les contrer depuis 10 ans au moins… Ça fait très longtemps qu'il exploitent toutes les données possibles.
Bien sûr c'est un journal très subjectif et « à l'emporte pièce ». Mais une seule remarque pour faire valoir ma manière de voir, car je n'ai pas le temps de répondre à tout :
Ceux qui semblent admettre que c'est évident se sont-ils jamais demandé quelles sont les conséquences psychologiques, mentales, sociales, morales, cognitives (et j'en passe) du remplacement des contacts humains par le virtuel? Ce point aussi est aussi un chemin de débat important.
Tout à fait. Mais il est aujourd'hui impossible (de ce que j'ai constaté moi-même) d'évoquer ce genre de mise en balance avec qui que ce soit aujourd'hui, hors exceptions très rares : c'est cette difficulté que je veux soulever avec ce journal. Toute la communication de la puissance publique et des médias privés ignore complètement cela, et impose un nombre de sous-entendus malsains innombrables lors de ses « débats » et propositions. C'est ce genre de situation paradoxale (je ne trouve pas le qualificatif adéquat, ça n'est pas exactement ça), avec des non-dits fondamentaux, qui fait mal à beaucoup de gens aujourd'hui, je pense.
je parie que la plupart ne ressortent pas de cette médiatisation avec l'idée que dans une bonne moitié des pays d'europe il ne s'est rien passé d'exceptionnel cette année.
En effet. Mais soit tu psychotes à cause de cette perception biaisée, soit tu psychotes parce que seuls un pelé et deux tondus arrivent à balancer ça et à en parler, alors que le gouvernement et toutes les institutions publiques et privées te disent le contraire. Quel est ton camp, camarade ?
Après, les équipements intermédiaires peuvent se changer plus facilement, s'il faut du débit symétrique.
Non. La manière dont est déployé la FTTH fait que les lignes sont réunies par ce qu'on appelle à tort un « prisme » au niveau du Point de Mutualisation (PM), ce qui fait qu'on est obligé d'utiliser des techniques de multiplexage spécifiques et identiques pour toutes les lignes, ce qui fait que ça ne change pas une fois le matos installé : comme il n'y a qu'une seule fibre au lieu de deux pour le duplex chez les « pros », on a deux fréquences différentes pour l'up et le down, identiques pour tout le monde, avec une techno d'up moins rapide que le down car c'est les émetteurs les plus chers et il y a N clients pour 1 NRO, et en gros, c'est du TDMA un up, et en down tu chiffres en fonction du destinataire. Ça n'a rien à voir avec la fibre utilisée « dans le temps » avec Ethernet ou autre.
Juste pour info, le FTTH tel qu'il est déployé en France et ailleurs n'est pas symétrique : la fibre est souvent présentée comme permettant d'avoir un bon upload, mais les fibres symétriques sont celles qui sont dédiées à de l'Ethernet ou autre sur des réseaux spécifiques, contrairement aux différents types de PON (Passive Optical Network) utilisés pour le déploiement de la fibre en France (Free faisait du P2P au début mais a laissé tomber).
Concernant tes demandes, je suis d'accord même si pour l'IPv4 il faut laisser tomber, ça ne pourra pas marcher : autant se concentrer sur IPv6. Et je rajouterais une condition, qui est normalement implicite mais avec ce qu'on voit aujourd'hui : avoir un préfixe fixe, sinon c'est impossible de faire de l'hébergement derrière.
Posté par benoar .
En réponse au message Socket .
Évalué à 2.
il n’y a pas de chemin privilégié qui autoriserait à « court-circuiter » la pile réseau.
Ça dépend ce que tu appelles « court-circuiter » : tout ce qui est à destination d'une adresse bindée localement passe par l'interface loopback (pas seuleument 127/8 et ::1). Les perfs ne sont pas si mauvaises :
dd if=/dev/urandom bs=4k count=50k | time socat stdin unix-listen:@foo
socat unix-connect:@foo stdio > /dev/null résultat :
51200+0 enregistrements lus
51200+0 enregistrements écrits
209715200 octets (210 MB, 200 MiB) copiés, 5,37172 s, 39,0 MB/s
socat stdin unix-listen:foo 0,14s user 0,71s system 14% cpu 5,874 total versus :
dd if=/dev/urandom bs=4k count=50k | time socat stdin tcp-listen:4242
socat tcp-connect:localhost:4242 stdio > /dev/null résultat :
51200+0 enregistrements lus
51200+0 enregistrements écrits
209715200 octets (210 MB, 200 MiB) copiés, 12,1192 s, 17,3 MB/s
socat stdin tcp-listen:4242 0,09s user 0,66s system 5% cpu 12,622 total J'ai certes une vitesse divisée par deux dans le cas TCP, mais avec une utilisation CPU instantanée moindre, et au final un temps user+system similaire pour les deux cas.
À noter que l'API, en dehors de la création de socket et du bind/connect, est strictement identique : il y a juste un changement de famille et de nom à effectuer. Et l'avantage d'utiliser AF_INET(6), c'est que le nom peut aussi bien être local (avec l'optimisation que j'évoque) ou bien distant, sans rien changer au code, juste au nom auquel se connecter, ou sur lequel se binder.
L'autre avantage de ce mode de fonctionnement, c'est de s'être débarrassé de la modalité « application qui tourne (ou pas) » : on n'a pas à s'en préoccuper, on clique sur l'icône pour « y aller », et on retrouve l'appli, qu'elle tourne ou pas. Seuls quelques geeks se préoccupent de savoir si l'appli « tourne actuellement », la majorité des gens s'en foutent.
Apple est le spécialiste de la suppression des modalités : ils ont même supprimé la plus évidente (rétrospectivement) mais que personne n'avait vu ; à savoir si la machine est allumée ou pas. On ouvre le Mac ou l'iPhone, il est là à répondre, pas la peine de savoir s'il est allumé (je crois même qu'il n'y a même plus de bouton d'allumage sur les Mac récents). Ils font ça sur plein d'autres aspects, c'est vraiment fort. Ça libère le cerveau des gens, et c'est ça qu'ils aiment.
Et c'est un fan de modalité qui vous le dit ! (je ne lâcherais mon éditeur de texte modal pour rien au monde)
Voir https://arstechnica.com/gadgets/2020/03/ok-computer-the-ipad-pro-2020-review/2/
Certes il y a du GeekBench, mais aussi des benchmark de browser. En gros un iPad Pro (avec 4 cores équivalent A7x et 4 cores équivalent A5x) se situe entre un MacBook Air et un MacBook Pro (et n'a pas à rougir face à ce dernier). Ça n'est pas ridicule du tout, bien au contraire, même si une partie doit être « compensée » par le GPU, qu'intègrent ces benchmarks.
C'est amusant de voir que macOS qui est présenté comme simple et intuitif peu donner du fil à retordre à ses utilisateurs et que ni ma voisine, si ses enfants et ses petits enfants utilisateurs de macOS n'aient pu lui venir en aide.
Le menu contextuel sur touche des deux doigts est un paradigme qui existe depuis longtemps sur tous les systèmes avec tocuhpad, et qui a été inventé par Apple il me semble. S'il y a une option pour le désactiver dans MacOS, c'est que c'est considéré comme fonction avancée par Apple et peut perturber certaines personnes un peu handicapées (pas une critique contre les personne âgées, hein, ça arrive à plein de monde), mais le mettre par défaut a mon avis été très longuement étudié par Apple pour que ça soit fait aujourd'hui. Ça n'est pas pour rien qu'ils ont des souris à un seul bouton aussi.
Après, la raison que ça n'a pas été repéré plus tôt est qu'à mon avis les gens normaux ont toujours tendance à blâmer la machine, alors que les informaticiens connaissent bien le problème entre la chaise et le clavier.
Bon c'est mon interprétation. Faudrait demander à la FSF si ça rentre bien dans ce qu'ils appellent "your cost of physically performing source distribution"; moi ça me paraît raisonnable.
Je ne suis pas un juriste, mais j'ai lu et relu les GPL depuis longtemps, et je suis d'accord avec ton interprétation, comme le reste de ce que tu dis dessus dans les autres commentaires.
(je ne sais pas si mon commentaire t'es utile, mais voilà, t'es pas tout seul)
Accepter un message en disant « tout va bien » alors qu’on l’envoie direct à la poubelle, sans aucune possibilité¹ pour le destinataire d’en prendre connaissance et sans jamais avertir l’émetteur, est une violation flagrante du protocole.
Si tu savais à quel point c'est la norme (en pratique) au niveau en-dessous, sur IP, où un retour en ICMP est théoriquement obligatoire en cas de problème, blocage ou échec, et dans la norme (officielle et théorique)… J'espère que cette mauvaise pratique ne se répandra pas dans l'e-mail, ni dans IPv6 qui est légèrement plus épargné, mais c'est pas la joie non plus.
C'est une suite de microservices que tu n'as pas besoin de maintenir ni faire évoluer ni gèrer l'augmentation de charge. C'est fait pour toi.
Ça dépend à quel niveau tu veux ton service dans les nuages : je pensais que pour un service de santé nationale, on aurait voulu un truc un peu bas niveau où on maîtrise les services dessus. Ça aurait été vraiment bien d'avoir le cahier des charges pour comprendre ce qui a été demandé pour ce HDH.
Tu pourrais certainement les construire toi même hein, c'est vrai pour tout ce qu'un cloud fait, la question est si tu veux en payer le temps, le prix et l'effort d'évolution.
Oui, c'est la question, qui n'est répondue nulle-part : l'État a choisi MS principalement pour des raison de « sécurité » (genre certification, plutôt) de ce que j'ai lu. Je n'ai pas entendu parler de la nécessité de services au-dessus d'un IaaS/PaaS « classique ». D'où mon doute sur tes arguments.
Tiens, merci, je ne connaissais pas ces services : en gros, c'est du service supplémentaire intégré (ML tout-en-un, reconnaissance d'image et de voix), dont je ne vois pas trop le rapport à la base avec le service de « cloud ». Ah, si, l'intégration : le bon vieux vendor lock-in qui se pointe, subrepticement… Pourquoi mets-tu en avant ces services comme nécessaires pour les besoins dont on est en train de parler dans le journal ? Franchement, ça fait vachement à la Microsoft « ce qui est intégré dans nos produits marche mieux » (et s'ils marchent trop bien on les tuera) ; pas étonnant que tu aies l'air de bien aimer ça !
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par benoar . En réponse au journal Extension Google Direct pour Firefox. Évalué à 2.
Non, parce que la structure du problème fait qu'un réseau fédéré comme l'e-mail se prête beaucoup mieux à la co-existence de plusieurs acteurs. Ils peuvent s'échanger des données, il n'existe pas d'authentification unique des utilisateurs (d'où les problèmes de l'e-mail, d'ailleurs), etc.
Et pour ta gouverne, Mozilla — accessoirement financé en très grande partie par Google — est contre ; ironique, non ?
https://drewdevault.com/2020/10/22/Firefox-the-embarassment-of-FOSS.html
Genre la violence que ça a été contre Microsoft ? LOL.
Les mails j'ai expliqué plus haut, la vente en ligne je ne sais pas trop quoi en penser, ça devrait être quelque-chose de difficilement « hégémonisable » mais Amazon y arrive quand même… Mais pour les réseaux sociaux par exemple, c'est comme la recherche, la tendance naturelle est à l'hégémonie d'un acteur. D'où l'impossibilité pour moi d'avoir un réseau social généraliste en démocratie : il finira hégémonique et abusif, comme l'est Facebook. Il faut l'interdire. Il ne pourra jamais y avoir de politique de modération de contenu globale qui satisfasse assez de monde, ou alors ça sera un « Meilleur des mondes » façon Huxley ou Orwell.
C'est pareil pour toutes les choses qui ont une architecture non-fédérée en général. Le modèle fédéré n'est pas seulement bon pour la diversité technique, mais pour les libertés fondamentales également.
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par benoar . En réponse au journal Extension Google Direct pour Firefox. Évalué à 2. Dernière modification le 03 décembre 2020 à 22:48.
Donc tu présentes les résultats dans quel ordre ? Tu vas jusqu'à quelle profondeur pour voir les entrées similaires ? Cote à cote sur combien de colonnes ? Quels sont les moteurs « élus » ? Tu roules sur quelle période, quel critère, etc ? Toutes ces choses sont sujettes à des biais, et Google même joue dessus pour mettre ses propres produits en avant. Il n'existe pas à ma connaissance de solution réaliste à ce genre de truc.
Oui, et je maintiens que c'est la bonne. Après, je ne suis pas contre des moteurs thématiques, ou centrés sur un domaine particulier. Ça pose toujours des problèmes, mais de moindre envergure qu'un moteur généraliste unique.
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par benoar . En réponse au journal Extension Google Direct pour Firefox. Évalué à 2.
C'est toujours mieux qu'un moteur pour tout.
… qui utilise google, sans intérêt (à long terme).
Je ne connais pas leurs méthodes, c'est tant mieux s'ils crawlent eux-même, mais ça reste le problème d'un moteur hégémonique, pour une population donnée : qu'il n'y ait que yandex pour tous les russes ou que baidu pour les chinois, ça n'est pas acceptable selon moi, mais bon c'est leur problème.
Il faut être « sexy » pour être démocratique ? Parce que quelque-chose est ancien, il est forcément « has-been » ?
Je te rappelle que c'était mieux avant :-)
Ta proposition m'a l'air irréaliste : comparer les résultats ça n'intéresse personne à part trois geeks dans leur garage. Et ton début de proposition de résolution algorithmique est bancal.
Non, j'y ai bien réfléchi, et pour moi la seule solution est d'interdire les moteurs généralistes. Je veux bien discuter si quelqu'un a une meilleure idée…
[^] # Re: Autre solution : pas de JS et pas de meta refresh
Posté par benoar . En réponse au journal Extension Google Direct pour Firefox. Évalué à 6.
J'avoue qu'on ne m'avait encore jamais sorti cet argument… outre que parler « d'hégémonie » de plusieurs sites n'a pas de sens, arguer que plusieurs puissances seraient dommageables pour la « diversité » (si j'interprète bien) insinue que la découverte de nouvelles sources serait impossible sans Google, ce qui est à mon avis faux car ce que présente ce un moteur de recherche moderne est toujours influencé par des choix arbitraire et non uniquement une sorte d'algorithme « juste ».
C'est bien la dépendance à un oracle omniscient pour effectuer toutes nos tâches que j'essaye de dénoncer ici : tu es tellement dépendant d'une unique source de recherche que tu as peur des autres modèles, et ta croyance même en l'existence d'une source soit-disant équitable pour tout le monde t'aveugle sur la réalité du pouvoir que ce modèle implique. Selon moi, il est impossible d'avoir un modèle de société démocratique avec un moteur de recherche comme celui-ci. Enfin, « moteur de recherche » c'est son nom mais c'est beaucoup plus que ça aujourd'hui, puisque c'est un moteur de prédiction de la pensée vu que chaque touche appuyée sur chaque périphérique branché à ce grand cerveau centralisé est analysée pour afficher en direct des « suggestions » que beaucoup vont suivre sans se pencher un instant sur la modification du chemin cognitif induite par ce superbe mécanisme (il faut l'avouer, c'est très balèze techniquement).
Découvrir de nouvelles sources, c'est quelque-chose qu'on fait régulièrement, puisque les sites vont et viennent, à échelle plus ou moins longue. On a une manière pratique mais non-découvrable d'y accéder, c'est le DNS, mais le Web a été conçu avec des URI formables par des humains pour une raison : pour qu'on puisse les taper et les échanger facilement. Et il peut bien sûr exister des sites que te font découvrir d'autres sites, ou qui agrègent leur contenus, ou qui sont charger de centraliser les adresses d'autres ; on a plein de moyens de découvrir de nouvelles sources. Mais qu'il existe un unique moyen d'y accéder, ayant pouvoir de vie ou de mort sur tout le reste, ça n'est pas acceptable selon moi. Même si sans lui, la découvrabilité en souffrira, mais c'est le prix à payer.
[^] # Re: détails de l'histoire ?
Posté par benoar . En réponse au journal Linux & Nvidia. Évalué à 4.
De ce que je comprends de l'histoire, on a Jonathan Lemon, un BSDiste ancien pas inconnu (auteur de kqueue), qui bosse aujourd'hui pour Facebook et qui envoie un patch de son adresse perso pour lier spécifiquement des GPU Nvidia à des cartes Ethernet Mellanox en utilisant l'infra du kernel. L'exemple d'utilisation est du Machine Learning sur GPU où les données transitent directement par la carte réseau à 200 Gbps (!) car sinon le bridge PCI-Express qui échangerait avec le CPU sature dans ce cas-là… Son truc est spécifique à son montage, et n'utilise pas l'infra de DMA inter-périphérique (p2p_dma) qui se trouve être une interface indiquée comme propageant là GPL pour tout code qui s'y lie ; coïncidence ou hasard… Il se trouve qu'en plus il dit ne pas avoir exporté les symboles de sa nouvelle API en _GPL car « c'était trop long à taper », ce qui pour une personne de sa trempe et vu le contexte (développement spécifique à Facebook, Nvidia toujours à vouloir niquer la GPL) s'est vu qualifier de trollage par Christoph Hellwig, développeur vétérant du kernel bien connu pour sa défense du Libre et de la GPL.
Le patch proposé par Hellwig que tu montres après est très intéressant, car effectivement il semble avoir été écrit pile pour contrer ce genre de code, et les datent concordent (fin juillet dernier, ce dernier patch arrivant juste après l'incident ci-dessus) : les modules type « shim » qui sont là uniquement pour faire une interface sans valeur dans le but uniquement de lier un module à licence propriétaire — chose normalement proscrite par la GPL, mais que Nvidia utilise depuis plus de 10 ans, malgré les critiques de Torvalds et d'autres — deviennent rejetés. La discussion est ici :
https://lore.kernel.org/lkml/20200730061027.29472-1-hch@lst.de/
Ça semble vraiment être ça selon moi, et pourtant Nvivia a apparemment sorti un nouveau driver « compatible » avec le 5.9 :
https://forums.developer.nvidia.com/t/download-nvidia-driver-r455-for-linux-kernel-5-9/159776
En tous cas, remarque sarcastique de Greg KH sur le patch de Hellwig :
# Autre solution : pas de JS et pas de meta refresh
Posté par benoar . En réponse au journal Extension Google Direct pour Firefox. Évalué à 3.
Si vous ne souhaitez pas vous amuser à toujours courir après les mécanismes de Google pour contrer ceux qui essayent de protéger leur vie privée, vous pouvez également désactiver le Javascript et les meta refresh dans votre browser : les pages servies ainsi contiennent uniquement les liens directs.
Pour le JS vous avez plein d'extensions pour le désactiver, pour les redirections (plus précisément la balise meta refresh qui vous redirige vers une page contenant les redirections) c'est accessibility.blockautorefresh=true dans about:config. Attention, ça bloque tous les refresh utilisées sur le Web : ça vous mettra un message de blocage du refresh sur pas mal de sites, à vous de le suivre (ou pas).
En fait, Google est un peu retors, même avec les gens qui n'ont pas de JS, car même s'ils sont les pros des technos modernes de traçage, ils sont aussi quand même les pros de la rétro-compatibilité, et c'est pour ça qu'ils continuent de dominer : la page servie de base est toute basique avec des liens directs, ce qui permet à n'importe quel browser le plus ante-diluvien de continuer à fonctionner avec. Ensuite, une balise meta refresh vous redirige vers une page qui contient des liens redirigés pour comptabiliser le nombre de clics. Je suppose qu'ils sont ensuite transformés en lien directs par du JS afin que vous ayez l'impression que quand vous cliquez ça va être un lien direct. Puis au moment du clic intervient le callback qui va en faire un lien redirigé. Si c'est pas vicieux…
La dernière solution c'est d'essayer de ne pas utiliser Google, pas en choisissant un moteur alternatif car ceux-ci sont condamnés à courir derrière le leader incontesté, mais plutôt en essayant de voir comment vos « besoins de recherche » sont mieux satisfait sur des moteurs plus spécifique, comme celui de Wikipédia pour chercher un nom, openstreetmap pour chercher une localisation, n'importe quel dictionnaire en ligne pour chercher une traduction, stackoverflow pour chercher une erreur, etc. Vous verrez, vous vous en porterez mieux.
[^] # Re: déjà existant
Posté par benoar . En réponse au journal Extension Google Direct pour Firefox. Évalué à 2.
Perso, j'ai souvenir de ces redirections et d'extensions Firefox pour les contrer depuis 10 ans au moins… Ça fait très longtemps qu'il exploitent toutes les données possibles.
[^] # Re: Un peu trop simpliste comme raisonnement mais tant qu'à commenter...
Posté par benoar . En réponse au journal Numérique et confinement. Évalué à 2.
Bien sûr c'est un journal très subjectif et « à l'emporte pièce ». Mais une seule remarque pour faire valoir ma manière de voir, car je n'ai pas le temps de répondre à tout :
Tout à fait. Mais il est aujourd'hui impossible (de ce que j'ai constaté moi-même) d'évoquer ce genre de mise en balance avec qui que ce soit aujourd'hui, hors exceptions très rares : c'est cette difficulté que je veux soulever avec ce journal. Toute la communication de la puissance publique et des médias privés ignore complètement cela, et impose un nombre de sous-entendus malsains innombrables lors de ses « débats » et propositions. C'est ce genre de situation paradoxale (je ne trouve pas le qualificatif adéquat, ça n'est pas exactement ça), avec des non-dits fondamentaux, qui fait mal à beaucoup de gens aujourd'hui, je pense.
[^] # Re: Simulations
Posté par benoar . En réponse au journal Numérique et confinement. Évalué à 3.
En effet. Mais soit tu psychotes à cause de cette perception biaisée, soit tu psychotes parce que seuls un pelé et deux tondus arrivent à balancer ça et à en parler, alors que le gouvernement et toutes les institutions publiques et privées te disent le contraire. Quel est ton camp, camarade ?
[^] # Re: Le FTTH n'est *pas symétrique*
Posté par benoar . En réponse au journal Pack auto-hébergement : Lettre ouverte aux fournisseurs d'accès à Internet. Évalué à 3.
Non. La manière dont est déployé la FTTH fait que les lignes sont réunies par ce qu'on appelle à tort un « prisme » au niveau du Point de Mutualisation (PM), ce qui fait qu'on est obligé d'utiliser des techniques de multiplexage spécifiques et identiques pour toutes les lignes, ce qui fait que ça ne change pas une fois le matos installé : comme il n'y a qu'une seule fibre au lieu de deux pour le duplex chez les « pros », on a deux fréquences différentes pour l'up et le down, identiques pour tout le monde, avec une techno d'up moins rapide que le down car c'est les émetteurs les plus chers et il y a N clients pour 1 NRO, et en gros, c'est du TDMA un up, et en down tu chiffres en fonction du destinataire. Ça n'a rien à voir avec la fibre utilisée « dans le temps » avec Ethernet ou autre.
# Le FTTH n'est *pas symétrique*
Posté par benoar . En réponse au journal Pack auto-hébergement : Lettre ouverte aux fournisseurs d'accès à Internet. Évalué à 6.
Juste pour info, le FTTH tel qu'il est déployé en France et ailleurs n'est pas symétrique : la fibre est souvent présentée comme permettant d'avoir un bon upload, mais les fibres symétriques sont celles qui sont dédiées à de l'Ethernet ou autre sur des réseaux spécifiques, contrairement aux différents types de PON (Passive Optical Network) utilisés pour le déploiement de la fibre en France (Free faisait du P2P au début mais a laissé tomber).
Concernant tes demandes, je suis d'accord même si pour l'IPv4 il faut laisser tomber, ça ne pourra pas marcher : autant se concentrer sur IPv6. Et je rajouterais une condition, qui est normalement implicite mais avec ce qu'on voit aujourd'hui : avoir un préfixe fixe, sinon c'est impossible de faire de l'hébergement derrière.
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par benoar . En réponse au journal Transition ARM : Apple assistera certains projet open source . Évalué à 4.
J'ai l'impression, oui.
[^] # Re: futurologie
Posté par benoar . En réponse au journal Transition ARM : Apple assistera certains projet open source . Évalué à 3.
Ebay et leboncoin sont tes amis, mais avec le Web d'aujourd'hui, le CPU va effectivement faire la gueule.
[^] # Re: Sockets UNIX?
Posté par benoar . En réponse au message Socket . Évalué à 2.
Ça dépend ce que tu appelles « court-circuiter » : tout ce qui est à destination d'une adresse bindée localement passe par l'interface loopback (pas seuleument 127/8 et ::1). Les perfs ne sont pas si mauvaises :
dd if=/dev/urandom bs=4k count=50k | time socat stdin unix-listen:@foo
socat unix-connect:@foo stdio > /dev/null
51200+0 enregistrements lus
51200+0 enregistrements écrits
209715200 octets (210 MB, 200 MiB) copiés, 5,37172 s, 39,0 MB/s
socat stdin unix-listen:foo 0,14s user 0,71s system 14% cpu 5,874 total
dd if=/dev/urandom bs=4k count=50k | time socat stdin tcp-listen:4242
socat tcp-connect:localhost:4242 stdio > /dev/null
51200+0 enregistrements lus
51200+0 enregistrements écrits
209715200 octets (210 MB, 200 MiB) copiés, 12,1192 s, 17,3 MB/s
socat stdin tcp-listen:4242 0,09s user 0,66s system 5% cpu 12,622 total
À noter que l'API, en dehors de la création de socket et du bind/connect, est strictement identique : il y a juste un changement de famille et de nom à effectuer. Et l'avantage d'utiliser AF_INET(6), c'est que le nom peut aussi bien être local (avec l'optimisation que j'évoque) ou bien distant, sans rien changer au code, juste au nom auquel se connecter, ou sur lequel se binder.
[^] # Re: Si quelqu'un a une explication...
Posté par benoar . En réponse au journal 2020 année de Linux sur le desktop .... Évalué à 9.
L'autre avantage de ce mode de fonctionnement, c'est de s'être débarrassé de la modalité « application qui tourne (ou pas) » : on n'a pas à s'en préoccuper, on clique sur l'icône pour « y aller », et on retrouve l'appli, qu'elle tourne ou pas. Seuls quelques geeks se préoccupent de savoir si l'appli « tourne actuellement », la majorité des gens s'en foutent.
Apple est le spécialiste de la suppression des modalités : ils ont même supprimé la plus évidente (rétrospectivement) mais que personne n'avait vu ; à savoir si la machine est allumée ou pas. On ouvre le Mac ou l'iPhone, il est là à répondre, pas la peine de savoir s'il est allumé (je crois même qu'il n'y a même plus de bouton d'allumage sur les Mac récents). Ils font ça sur plein d'autres aspects, c'est vraiment fort. Ça libère le cerveau des gens, et c'est ça qu'ils aiment.
Et c'est un fan de modalité qui vous le dit ! (je ne lâcherais mon éditeur de texte modal pour rien au monde)
[^] # Re: Pas de soucis !
Posté par benoar . En réponse au journal 2020 année de Linux sur le desktop .... Évalué à 1.
Voir https://arstechnica.com/gadgets/2020/03/ok-computer-the-ipad-pro-2020-review/2/
Certes il y a du GeekBench, mais aussi des benchmark de browser. En gros un iPad Pro (avec 4 cores équivalent A7x et 4 cores équivalent A5x) se situe entre un MacBook Air et un MacBook Pro (et n'a pas à rougir face à ce dernier). Ça n'est pas ridicule du tout, bien au contraire, même si une partie doit être « compensée » par le GPU, qu'intègrent ces benchmarks.
[^] # Re: Si quelqu'un a une explication...
Posté par benoar . En réponse au journal 2020 année de Linux sur le desktop .... Évalué à 2.
Le menu contextuel sur touche des deux doigts est un paradigme qui existe depuis longtemps sur tous les systèmes avec tocuhpad, et qui a été inventé par Apple il me semble. S'il y a une option pour le désactiver dans MacOS, c'est que c'est considéré comme fonction avancée par Apple et peut perturber certaines personnes un peu handicapées (pas une critique contre les personne âgées, hein, ça arrive à plein de monde), mais le mettre par défaut a mon avis été très longuement étudié par Apple pour que ça soit fait aujourd'hui. Ça n'est pas pour rien qu'ils ont des souris à un seul bouton aussi.
Après, la raison que ça n'a pas été repéré plus tôt est qu'à mon avis les gens normaux ont toujours tendance à blâmer la machine, alors que les informaticiens connaissent bien le problème entre la chaise et le clavier.
[^] # Re: Si quelqu'un a une explication...
Posté par benoar . En réponse au journal 2020 année de Linux sur le desktop .... Évalué à 1.
C'est un bug de l'application, ça va contre les recommandations d'Apple :
https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/dock/
Ceux qui n'ont pas lu les recommandations sur l'interface utilisateur d'Apple ne comprendrons jamais pourquoi c'est la meilleure interface utilisateur qui existe, et pourquoi elle est si populaire :
https://developer.apple.com/design/human-interface-guidelines/
[^] # Re: Contenu du CD d'installation
Posté par benoar . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
Je ne suis pas un juriste, mais j'ai lu et relu les GPL depuis longtemps, et je suis d'accord avec ton interprétation, comme le reste de ce que tu dis dessus dans les autres commentaires.
(je ne sais pas si mon commentaire t'es utile, mais voilà, t'es pas tout seul)
[^] # Re: Propagande pro-nucléaire
Posté par benoar . En réponse au journal CPU Ex0042 Ceux qui nous surveillent. Évalué à 2. Dernière modification le 18 juin 2020 à 12:24.
LOL. Tu devrais aller voir les cours de Jancovici quand même (dont parle ton premier article que tu critiques).
[^] # Re: Source?
Posté par benoar . En réponse au journal Le service messagerie Microsoft Outlook.com détruit silencieusement vos e-mails. Évalué à 2.
Si tu savais à quel point c'est la norme (en pratique) au niveau en-dessous, sur IP, où un retour en ICMP est théoriquement obligatoire en cas de problème, blocage ou échec, et dans la norme (officielle et théorique)… J'espère que cette mauvaise pratique ne se répandra pas dans l'e-mail, ni dans IPv6 qui est légèrement plus épargné, mais c'est pas la joie non plus.
[^] # Re: Oui mais non
Posté par benoar . En réponse au journal De l'usage de la section Liens sur LinuxFr. Évalué à 1.
J'arrive après la bataille, mais là :
Merci, je vais l'encadrer.
GnuPG par exemple.
[^] # Re: À quoi sert l'inventaire ?
Posté par benoar . En réponse au journal creation de qrcode et code128 pour gestion de parc. Évalué à 5.
Alors toi t'as pas bossé dans des grandes structures avec une mentalité plutôt ouverte, genre étudiant ou service public.
[^] # Re: Données du grand débat public
Posté par benoar . En réponse au journal [HS] Microsoft ♥ Linux - Episode VI "AYBABTU". Évalué à 6.
Ça dépend à quel niveau tu veux ton service dans les nuages : je pensais que pour un service de santé nationale, on aurait voulu un truc un peu bas niveau où on maîtrise les services dessus. Ça aurait été vraiment bien d'avoir le cahier des charges pour comprendre ce qui a été demandé pour ce HDH.
Oui, c'est la question, qui n'est répondue nulle-part : l'État a choisi MS principalement pour des raison de « sécurité » (genre certification, plutôt) de ce que j'ai lu. Je n'ai pas entendu parler de la nécessité de services au-dessus d'un IaaS/PaaS « classique ». D'où mon doute sur tes arguments.
[^] # Re: Données du grand débat public
Posté par benoar . En réponse au journal [HS] Microsoft ♥ Linux - Episode VI "AYBABTU". Évalué à 1.
Tiens, merci, je ne connaissais pas ces services : en gros, c'est du service supplémentaire intégré (ML tout-en-un, reconnaissance d'image et de voix), dont je ne vois pas trop le rapport à la base avec le service de « cloud ». Ah, si, l'intégration : le bon vieux vendor lock-in qui se pointe, subrepticement… Pourquoi mets-tu en avant ces services comme nécessaires pour les besoins dont on est en train de parler dans le journal ? Franchement, ça fait vachement à la Microsoft « ce qui est intégré dans nos produits marche mieux » (et s'ils marchent trop bien on les tuera) ; pas étonnant que tu aies l'air de bien aimer ça !