beagf a écrit 763 commentaires

Et tu es bien naïf en effet.

Au niveau sécurité, tu te bats chez toi dans un terrain que tu contrôles, le cadre est définis très clairement, tu as des moyens de tester, tu peux ajuster la surface d'attaque au minimum en fermant tout ce qui n'est pas utile...

Pour un moteur de recherche la situation est différente ne te bas pas chez toi mais dans le capharnaüm qu'est le Web, où quasiment tous les sites font de l'optimisation pour être correctement classés et où la limite entre optimisation et spamdexing est très floue, et où la satisfaction de l'utilisateur est la seule mesure et elle est difficilement mesurable.

Dis toi bien qu'il y a beaucoup de monde qui bosse la dessus et qu'il n'y en a pas beaucoup qui croient à la solution miracle. Le contenu trié par les utilisateurs est une piste en grande partie abandonnée depuis longtemps, dès que l'on permet à l'utilisateur de mettre son nez quelque part les spammeurs sont les premiers arrivés. Même sur des trucs plutôt confidentiels, il suffit de regarder la liste des commandes sur yubnub.org, elle est complètement inutilisable car pourrie de spam. C'est la même chose avec les commentaires de beaucoup de blogs, avec pas mal de wiki et autres.

Dès que tu permet à l'utilisateur de donner son avis, si ça à un intérêt potentiel pour les spammeurs, ils mettent en place une troupe de bot pour biaiser le truc. Pour tous les site ou l'on peut commenter ou donner son avis sur un produit sans l'avoir acheter, la majorité des avis sont du spam.

Et c'est pas un captchas ou autre qui va les arrêter, tu retrouves derrière des acteurs du porno sur le net qui ont plein de client près les remplir pour accéder à divers sites...

Attention, ta traduction est mauvaise, il ne parle pas de « pub » mais de « spam ». Dans le cas du Web on parle d'ailleurs plutôt de « webspam » ou de « spamdexing ».

Le spamdexing regroupe les techniques utilisées pour tricher avec les algorithmes de classements des moteurs de recherche afin qu'un site Web ce retrouve artificiellement mieux classé qu'il ne le devrait sur certaines requêtes.

Dans les début des moteurs de recherche, par exemple, la principale méthodes de classement reposait sur une mesure très simple : le TF/IDF. Pour savoir si un document est bon vis-à-vis d'une requête, on regarde pour chaque mot de la requête sa fréquence dans le document par rapport à sa fréquence dans l'ensemble des pages indexées.
Si le score du TF/IDF est bon, cela veut dire que globalement les mots de la requête apparaissent plus souvent dans ce document que dans un document moyen, il est donc probablement intéressant pour l'utilisateur.

Rapidement, le gens ont compris comment marchait ce type de moteur et ils ont commencés à remplir leurs pages de mots-clés fréquemment utilisés dans les requêtes qui les intéressait. Et les résultats des moteurs de recherche ont commencé à devenir n'importe quoi.

Ce fût le début de la guerre entre spammeurs et moteurs de recherche. Les moteurs trouvent de nouvelles manières de classer les pages et de déjouer les techniques des spammeurs, pendant que les spammeurs font l'inverse. C'est le problème de l'épée et du bouclier.

La grosse amélioration apportée par Google à été la combinaison de deux scores : une mesure de pertinence tout-à-fait classique combinée à une mesure de confiance, le fameux « page-rank ». Le principe est tout simple : en général un site web ne contrôle que les liens qui sortent de chez lui, pas ceux qui pointent vers lui. Si on fait confiance à un site, on doit pouvoir faire confiance au site vers lesquels il pointe et vice-verca.

On commence donc en donnant un bon score à quelques site de confiance et un mauvais score à des spammeurs et on propage une partie de ce score vers les sites qu'ils pointent. En itérant, le système finit par ce stabiliser avec des scores de confiance pour tout le monde. (je simplifie un peu...)

Ça a bien marcher pendant un moment jusqu'à ce que les spammeurs comprennent comment contourner le truc : d'abord l'échange de liens puis « les fermes de liens ». C'est-à-dire un ensemble de site Webs comportant un très grands nombre de pages web très fortement connectées (plusieurs millions de pages) qui vont servir d'accumulateurs à page-rank.

La guerre entre les deux est permanente et contrairement à la cryptographie par exemple, il est à peu près impossible de créer un algo qui soit résistant de manière intrinsèque car on ne contrôle que l'algo pas les données, les spammeurs peuvent donc étudier l'algo et produire des site web spécialement adapté pour cet algo.

Pour avoir fait ma thèse dans le domaine je connais très bien le problème et je peut te garantir que les spammeurs suivent de très près toute la recherche qui est faite dans le domaine et sont très réactifs. Il n'est pas rare de voir apparaître de nouvelles technique de spams destinées à contrer des techniques anti-spam qui viennent d'être publiées et qui ne sont même pas encore arrivées dans les versions de production des moteurs de recherche.

Je n'aime pas ça mais ici on est vraiment dans une situation ou les algos doivent rester secrets pour le bien de l'utilisateur, c'est ce qui permet d'avoir des résultats pertinents.

Pour ce qui est des moteurs de recherche OpenSource, il ne sont tous simplement pas concernés, soient ils n'utilisent que des algos déjà publiés et donc les résultats sont pourris, soient il ne sont utilisés que par trois péquins et sont donc loin d'être une cible pour les spammeurs. Mais tu peut-être sûr que si un moteur de recherche OpenSource ce met à fournir des résultats pertinents et commence à avoir du succès, la qualité des résultats va vite chuter.

Il y a pour le moment une incompatibilité fondamentale entre OpenSource, pertinence et succès.

Oui, même les durs de la feuille comme moi ont bien compris le problème que pose la licence — trop respectueuse des libertés des utilisateurs — de GCC à certains groupements d'intérêts plus orientés « real politic » et parfois moins sourcilleux que la FSF quant aux droits de leurs constituants (les machines organiques qui correspondent aux cases de l'organigramme) et clients.

Ton ironie passe mal. Tu sembles insinuer que les licences BSD, MIT ou équivalent sont moins bien que la reine GPL qui assure plein de choses à l'utilisateur. Le problème est pourtant bien réel, la GPL ne permet de réutiliser une bibliothèque dans un projet qui n'est pas open source. Il y a de développeurs que cela ne gène pas et il y en a d'autres qui ne veulent pas imposer cette restriction à leurs utilisateurs.
Chacun son choix et tu n'as pas à le critiquer.

Car dans votre commentaire comme dans le journal, cela reste ambiguë. Un peu comme une manière de dire que le backend de gcc ne serait pas réutilisable (!) ou que gcc ne serait pas bien documenté. Le second point étant certainement une question de goût et de jugement personnel dont chacun est libre.

Ce n'est pas une question de goût où autre, le backend n'était, au moment ou LLVM à débuter, absolument pas réutilisable et ce de manière volontaire. Le changement de position de RMS et de la FSF à ce sujet est d'ailleurs sûrement en grande partie dû à LLVM.
Quand à la documentation des représentation intermédiaires, c'est à peu près la même chose. Il n'y a pas grand chose et surtout elle à été définie uniquement selon les besoins et l'architecture de GCC. Ce n'est pas une critique ici mais un choix technique.

La grosse différence est là : les représentation intermédiaire dans GCC ne sont qu'un moyen technique de faire la compilation, s'il y a avait d'autres méthode aussi efficaces ils auraient pus tout autant les choisir. Elles évoluent en fonction des besoins de GCC sans ce préoccuper du reste du monde car seul GCC les utilises, bref, c'est un truc très bien pour GCC mais absolument inutilisable pour le reste du monde.

Dans LLVM, au contraire, la représentation intermédiaire à été conçue et clairement définie de manière à être un outil de partage entre de nombreux outils. Elle est donc parfaitement définie et peut donc être facilement utilisée par n'importe qui et à été conçue de manière à couvrir le plus grand champs d'application possible, pas uniquement un seul compilateur.

L'approche de GCC à l'avantage d'avoir un truc plus adapté à un outils en particulier et que l'on peut faire évoluer facilement quand le besoin s'en fait sentir, alors que l'approche de LLVM permet de faire fonctionner ensemble de nombreux programmes sans problème mais au d'une évolution plus lente.

Il faut bien voir que les deux approches ont des objectifs différents et que dans le cas de GCC, le reste du monde s'en contre tape de savoir qu'il y a une représentation intermédiaire puisque de toute façon elle est inutilisable en dehors de GCC.

À peu près autant que la base de registre sous Windows...

Pas vraiment, les EFL ne sont pas du tout "vaporware", elles ont une API stable et documenté et sont utilisées dans pas mal de projet même professionnels.
C'est sur que ça a été long, mais c'est parce qu'ils sont repartis de zéro et qu'ils ont fais les choses proprement.

Ils savent donc ce que c'est et savent à quel point c'est dur et à quel point l'API peut bouger souvent pendant cette phase. Il ne faut pas y voir une moquerie mais plutôt une patience respectueuse et des encouragements.

Si Wayland réussi et ce stabilise, à mon avis les EFL seront très rapidement portées dessus, mais pour l'instant ils préfèrent focaliser les ressources limitées qu'ils ont sur finir ce qu'ils leur reste à faire.

Le passage du dictionnaire n'est pas un problème, il faut bien voir que la stéganographie répond à un besoin différent de la cryptographie.

La stéganographie sert à transmettre l'information de manière discrète à travers un canal publique, par exemple un article de presse, une petite annonce, un message innocent sur un forum comme celui que j'écris en ce moment. L'objectif est qu'un observateur n'ait as l'impression qu'un message est en cours de transmission.
En général, le message en question est lui même crypté à l'aide d'un véritable algorithme de cryptage, pour le cas où l'observateur réussirait quand même à voir qu'il y a un message qui circule.

Il y a clairement deux niveaux, un niveau de protection par cryptographie, puis un niveau de transmission discrète par stéganographie. Si James Bond est en territoire ennemi, il à emmener avec lui une clé USB avec tous ses logiciels et peu poster sur son blog un message innocent qui transmet en fait son rapport à M.

Et pour ceux que ce genre de trucs amuse, on c'était marré avec des collèges à faire des convertisseurs « français <-> SMS » qui faisaient de la stéganographie, et là c'est beaucoup plus marrant car il y a bien plus de libertés.

Écrire un commentaire

Quel est l'intérêt de remettre en énorme un titre qui est déjà présent en gros quelques pixels au dessus ?

Euh… Que dire ? Non, je crois que là il n'y a rien à dire.

Je vais laisser les gens se faire leur avis en lisant nos proses respectives.

Cette technique c'est pour les disques magnétiques style les disque durs, je n'ait pas entendu parler du même genre d'attaque contre les mémoires flash.

Si quelqu'un à des infos je suis intéressé.

Ton message est aussi chiant que d'habitude : du gros discours de marketeux qui ne sait absolument de quoi il parle mais qui en parle quand même.
Si cela te semble si simple, eh bien commence par te mettre au boulot et on verra ce que tu nous sort.

Voila un petit réumer de ton projet tel que tu pourrais l'utiliser plutôt que te longues diatribes imbitables :

1. J'ai une idée que je trouve super chouette
2. Il faut mettre ensemble plein de technos que je ne connais absolument pas
3. Je n'ai aucune idée du réalisme de mon délire
4. Je n'ai aucune compétences sur les domaines concernés
5. Il va falloir que vous bossiez à ma place pour tous les aspects du projet
6. Il va falloir le faire vite car je veux que ce soit finis avant-hier
7. Si vous avez lu jusque là vous êtes tombés dans mon poisson d'avril à répétition (vous avez vraiment cru que j'étais sérieux ?)

Je veux bien être gentil mais il y a des limites à la connerie.

Tant que je tiens quelqu'un qui peut répondre à mes questions stupide, j'en profite…

Si j'ai bien compris le problème là-bas c'est qu'il faut pouvoir amener de l'eau et du courant au milieu de la centrale mais que vu le niveau de radiation il n'y a pas moyen de s'en approcher. C'est donc pour ça que l'eau il la balance de relativement loin.

Le truc que je me demande c'est pourquoi il n'y a pas un tuyau de deux ou trois cent mettre qui permette justement une alimentation en cas de gros pépin ?
Je me doute bien que ce ne serais pas un bête tuyau, mais un système qui soit prévu justement pour en cas de très gros problème comme en ce moment de faire des intervention à distance ?

Ou peut etre que si, mais un concours de circonstances a fait que? Ou pas? T'en sais rien en fait, ya 3 jours tu savais probablement meme pas si le japon avait des centeales nucleaires, mais maintenant t'est visiblement un expert du sujet…

Où peut-être que non ?
Il y a plusieurs sources dans le presse qui précise bien que les protections des groupes étaient largement sous-dimmensionnées et que l'organisme international de contrôle des centrales, dont j'ai oublié le nom, l'avais clairement signalé au Japon qui n'en a pas tenu compte.

On ne connais pas et on ne connaitra sûrement jamais tous les détails mais il semble bien qu'il y ai eu un vrai problème connu et que rien n'ai été fais pour le régler.

Sauf que pour avoir installé ou vu un paquet de serveurs, ça à toujours été des serveurs achetés sans OS et qui donc n'apparaissent pas dans ton étude, c'est quand même un biais monstrueux.
Sort nous plutôt une étude sérieuse...

Je dis peut-être une connerie mais de ce que j'ai compris c'est qu'il faut refroidir un gros truc avec de l'eau. C'est-à-dire qu'il y a un gros trucs très chaud et on fait circuler de l'eau autour.
Cette eau qui sert au refroidissement chauffe et s'évapore et il faut donc amener en permanence de l'eau fraiche pour continuer de refroidir le tout.

Si on met le reservoir au dessus du truc à refroidir, par simple gravité on peut faire descendre l'eau qui entretiens le refroidissement et donc tant qu'il y a de l'eau dans le réservoir au dessus ça marche.

Ça fait penser à tous les circuits d'eau classique qu'il y a dans toutes les centrales qui fonctionnent avec des turbines. (notamment les centrales nucléaires ;-) ) Ma question est donc pourquoi ne pas profitez du fait que la vapeur qui se dégage monte et donc la diriger vers le haut du réservoir et y mettre un condensateur ?

Bien sûr ça ne fait pas tout et le système passif ne tiendras pas éternellement, mais sûrement plus longtemps.

Je suis une quiche pour ce genre de truc et je me doute que si ça marchais ils y aurait déjà pensé, mais si quelqu'un peu me dire où est le problème.

tu as a peu pres garanti que C99 deviendra non-existant sur tous les desktops et la majorite des serveurs de la planete

Soit un peu sérieux quand même…

• Sur la majorité des serveurs de la planète Micorsoft est complètement absent tout comme son compilateur ;
• Sur tous les desktops où il y a autre chose que Windows, le compilateur de Microsoft est aussi complètement absent.

Donc ça veut déjà dire que sur la très grosse majorité des serveurs on à du C99, et sur une portion non-négligeable des desktops aussi. Donc pour les applis serveurs et pour les applis qui n'ont pas vocation à être portable, il n'y a aucun problème.

Sur les desktop avec Windows, le compilateur de Microsoft est très loin d'être le seul. De mon expérience GCC est relativement peu utilisé par les entreprises mais j'en connais quelques une qui l'utilisent.
Par contre ICC est très utilisé pour ses performances. Je connais pas mal d'entreprise ou même si le développement est actuellement fais sous Visual Studio, la compilation est toujours faite par ICC. J'ai même un exemple récent d'un passage de VS à Eclipse.

Tu peut dire ce que tu veux mais Microsoft est tout sauf indispensable pour compiler du C, et virer Microsoft du comité ne changera absolument rien à la situation :

• Microsoft continuera de se contre-foutre de la norme, ils était déjà dans le comité du C99 et ne l'on jamais supporté, il n'y a rien qui laisse entendre que le résultat sera différent pour le C1X ;
• Les autres compilateurs ferons les efforts nécessaire pour introduire progressivement le support, et on pourra compiler du C moderne sur toutes les plateformes.

Dans le monde des OS on peut critiquer énormément Microsoft mais on ne peut pas l'ignorer, dans le monde des compilateurs C par contre il n'y a aucun problème à ignorer Microsoft.

Non je ne pense pas que cela soit utile.

Je ne veux pas limiter la présence du C1X mais Microsoft n'est qu'un seul compilateur parmi beaucoup d'autres et :

• ne fait actuellement aucun efforts pour supporter le standard actuel qui à plus de dix ans ;
• communique clairement sur le fait qu'ils n'ont actuellement pas envie de le supporter dans le compilateur qu'ils commercialisent ;
• ne fait publiquement état d'aucun développement concernant ce standard.

Pour moi, cela indique clairement qu'ils ne portent aucun intérêt au standard actuel bien qu'il soit disponible depuis plus de dix ans.

Les compilateur de Sun et IBM on un support complet, celui de Intel à un support quasi complet tout comme celui de AMD. Du côté du libre, GCC et PCC en supporte la majorité tandis que CLang qui est un compilateur encore très jeune à un support quasi complet (à ma connaissance il ne manque plus qu'une partie des fenv et des pragmas).
Et surtout, tous ces compilateurs on un support beaucoup plus complet que celui de Microsoft du C99, continuent de l'améliorer et communique sur le fait qu'ils ont pour objectif un support complet.

Donc Microsoft détient peut-être à peu près tout le marché du desktop, mais dans le monde des compilateurs C, ils sont plutôt la dernière roue du carosse. Tout le monde supporte où fait des effort pour le C99 sauf eux, donc à mon avis ils n'ont rien à faire dans le comité qui prépare le prochain standard tant qu'ils ne montrerons pas un minimum de volonté.

Moi ce que j'aimerais savoir c'est pourquoi Microsoft est dans le comité qui bosse sur le future standard C1X ?
Qu'est ce que Microsoft fou dans ce comité alors qu'ils n'implémentent même pas correctement le C99 ?

Le prefetch ne dépassent pas les limites de pages justement pour éviter les pages miss et les pages fault. Cela m'étonnerait que les cpu actuelles puissent allez au dela de la limite de 4ko, car pour cela il devrait avoir l'information du type de page actuel.

Relis mon commentaire et tu verra que c'est ce que je dis… Avec une grosse page tu profite bien plus du prefetch qu'avec une petite.

De plus, les prefetchs sont petits, il s'agit de lire 1 ligne ou 2 de cache en avance.

Bien sûr, si tu accèdes à l'adresse x, il va prefetcher x+1, mais quand tu vas utiliser x+1, il va prefetcher x+2. (x étant une ligne de cache)
Donc au final si tu fais un accès continus le prefetch est actif en permanence et si ton traitement sur x n'est pas trop court, les latences mémoires sont masquées.

Le problème du swap est différent. Tout est plus rapide qu'un accès disque, donc on peut se permettre des algo très intelligent.

Ce n'est pas une question d'algos intelligents ou pas, c'est juste que lorsque tu récupère des données depuis le swap ou depuis un fichier, pour ce qui est du temps de transfert que ce soit 4k ou 2Mo la différence est minime, ce qui compte c'est la latence qui est la même et bien supérieur au temps de transfert. Donc autant récupérer directement 2Mo (voir plus) et surtout stocker ce gros bloc dans une seule grosse page pour pouvoir profiter du prefetch ensuite et réduire les pages miss et cache miss.

La localité ce n'est pas que pour optimiser l'utilisation du cache, c'est aussi pour profiter au maximum du prefetch. Lorsque tu accèdes à une zone mémoire de manière continue les données arrivent en flux car il n'attend pas le read pour charger les données dans le L2. Si tes données son réparties sur plein de petites pages, ça ne marche plus.

De la même manière, tu as le prefetch au niveau du disque dur, il vaut mieux récupérer 2Mo de données contiguës d'un coup que plein de morceaux de 4Ko répartis un peu partout.

J'ai corrigé dans mon deuxième commentaire le fait que les small pages gardent un intérêt.

Pour ce qui est de la localité, c'est en effet très utile pour les codes parallèles mais ça l'est aussi pour tous les autres codes. Que tes accès soient optimisés ou pas, tu va augmenter la localité avec des pages plus grosses. Il y a eu plusieurs article sur le fait que généralement des données allouées avec un faible intervalle de temps serons utilisées avec un très faible intervalle de temps. Plus tes pages sont grosses, plus tu as de chance que ces données soient dans la même page et donc proche en mémoire.

C'est sûr qu'optimiser réellement sont code pour la localité fait gagner mais le comportement de base de beaucoup de structures de données permet d'obtenir un minimum de localité si le reste est bien géré.

Et l'argument de la localité ne s'applique pas qu'au données comme tu le dis mais aussi au code, la majorité des compilateurs optimise même la position des fonctions dans le binaire afin que les fonctions qui s'appellent entre elles soient proches. Le cache de niveau 2 est partagé avec les données ce qui demande de la localité, le cache de niveau 1 est séparé mais demande aussi de la localité.

Ca fait des années que les hugepages existent et personne n'a demandé une telle config dans le noyau, il doit y avoir une raison... Peut-être parce qu'il y a des gens qui ont fait des vrais études et mesures et constaté que ca ne changeait pas grand chose aux perfs.

C'est surtout que ça fait des années qu'utiliser des hugepage est une galère monstrueuse et que donc les gens restent sur les petites…

Mais surtout je ne veux pas l'imposer à tout le monde mais avoir le choix.

Petite correction à un post posté un peu trop vite… C'est plutôt deux demie-pages qui peuvent-être « perdues » (où fragmentées) une pour la zone de pile et une pou la zone de tas. Et pour les zones de code et de données statiques les pages de 4ko restent utiles puisque la taille de ces zones ne change généralement pas.

Quand je vois les perfs globales de Linux s'effondrer d'année en année, je me pose des questions.

Tu as des sources ou des chiffres là-dessus ? De mon expérience personnelle j'ai plus l'impression que c'est l'inverse, les perfs s'améliorent de versions en versions. Ce qui baisse ce sont les perfs des couches supérieures et le noyau n'y peut rien...

J'étais parti pour faire une longue explication sur pourquoi ce ne serais pas stupide vu le fonctionnement des gestionnaires de mémoire mais en fait il y a beaucoup plus simple :

De manière générale, la mémoire « gaspillée » est au plus égale à la taille d'une page moins un octet et en général elle est aux alentours d'une demie page. Sur mon système qui n'a rien de particulier — les programmes classiques avec un desktop, un lecteur de mail, un navigateur et quelques terminaux et éditeurs — j'ai 71 processus en cours.

Cela veut dire qu'avec des pages de 2Mo je « perd » environs 71Mo. Mais ils ne sont absolument pas perdus, c'est juste des pages qui doivent être fragmentées si il n'y a plus de mémoire.

Et au final j'aimerais même pouvoir désactiver cette fragmentation automatique car je préfère qu'il envoi dans le swap une page de 2Mo plutôt que de la fragmenter. Il faut bien voir qu'il y a d'autres intérêts au grosses page que la libération de la TLB, il y a aussi le fait qu'une application sait que toutes les données au sein d'une page sont contiguës en mémoire. Et la localité en mémoire est très importante pour avoir des latences faible dans les accès séquentiels et pour optimiser les caches.

Donc voilà, moi j'aimerais beaucoup pouvoir compiler mon noyau sans gestion des pages de 4ko. Tu fais comme tu veux avec le tien.

Sauf qu'un processus ne demande jamais un octet au système. Un processus demande des blocs à son gestionnaire de mémoire qui lui va faire des demandes au système s'il n'a pas de blocs de libre, et de base il va demander des blocs relativement gros.
Quand ton processus écris ensuite dans une zone pour la première fois le système va alloué une page sans savoir la taille du bloc que le programme compte utiliser.

Le truc c'est que tels que sont foutus la majorité des allocateurs mémoire, il est raisonnable de dire que la mémoire perdue par processus est au plus égale à la taille d'une page moins quelques octets et en moyenne égale à une demi-page. Et vu que des processus il n'y en as pas une tétra-chiée et que l'on peu toujours spliter la page en cas de besoin urgent, je pense aussi que par défaut ce serait pas plus mal d'allouer des grosse pages. (je parle de page de 2mo pas des pages de 1go…)

C'est surtout que, autant la première blague était drôle, autant la tienne ne l'était pas du tout. C'est pas une question de sujet, c'est juste que c'était un rebond raté sur une blague spontanée. En première lecture je n'avais pas vu que tu voulais faire une blague, pour moi ton commentaire était plutôt un truc incohérent, et j'ai pas vraiment chercher à voir ce que tu voulais y dire.

Tu aurais plutôt enchainé avec une des deux que tu viens de faire, je suis à peu près persuadé que les choses aurais été différentes.