X345 a écrit 580 commentaires

[…] mais simplement qu'il y a plein de facteurs qu'on n'a pas (ou pas pu) contrôlé, faute de savoir s'ils étaient importants ou non.

Honnêtement, c'est quand même un gros problème si la publication ne mentionne pas l'intégralité des paramètres importants. Une publi c'est censé tirer des conclusions de résultats expérimentaux, du style: si j'augmente le taux de A, alors le taux de B augmente. Si l'augementation du taux de B dépend du taux de A, mais aussi de la température, de l'age du capitaine et de la latitude, la publication doit le mentionner. C'est tout le propos de la science d'isoler des relations de cause à effet. Quelle est la valeur d'une expérience non reproductible ? Un jour on a mesuré ça, on dit que c'est du a tel paramètre, mais en fait si ça se trouve y'a 100 autres paramètres qui rentrent en compte. Ça n'apporte pas grand chose.

En informatique, particulièrement en système, c'est assez catastrophique. Parfois les conclusions tirées ne proviennent pas des paramètres mentionnées dans la publication, mais d'erreurs d'implémentation. Pourtant les codes source ne sont que très rarement distribués.

Un exemple assez récent, dans un papier SIGMOD 2011, des auteurs montrent qu'un algorithme très simple de jointure relationnelle (je vous épargne les détails) offre des performances équivalentes à des algorithmes plus élaborés, contrairement à ce qui était publié jusqu'ici. Sauf qu'il a été montré par la suite que leurs résultats découlaient d'un problème trivial d'implémentation… (Papier).

Faut savoir que les chercheurs sont poussés à publier, publier, publier, publier. Ils ne sont aucunement incités à vérifier leurs résultats ou mettre en doute leurs conclusions. Les journaux/conférences veulent des résultats nouveaux, de préférence dans l'air du temps, un peu hype avec un pitch bien construit. Un papier de vérification/confirmation de résultats a peu de chances d'être publié aujourd'hui. Tout ça incite les chercheurs à travailler à la va-vite, et à pas vérifier leurs résultats.

Alors que HTML est un gros hack. Si tu fait du natif, alors je vois pas l'interrêt de se restreindre au limitations du HTML qui est conçu pour faire des pages web.

Le bon gros mantra qu'on annone bêtement depuis 10 ans : « HTML c'est pas fait pour faire des applications », et que je commence franchement à avoir marre d'entendre. C'était sûrement vrai y'a 10 ans, mais plus maintenant. Faut savoir mettre à jour ses parti pris. Section 1.1 de la spécification HTML5 (Introduction, Background):

The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

C'est la deuxième phrase du document. HTML5 a été explicitement conçu pour faciliter l'écriture d'application web. Une section complète (Section 6, Web application APIs) est dédiée aux applications Web.

Alors oui, je sais c'est "un gros hack". Ah bon. C'est ça l'esprit "hack", bidouille, détournement de l'usage initial cher aux libristes/hackers ? À la base tout était un gros hack, le language C n'était qu'un gros hack pour éviter d'avoir à écrire Unix en assembleur. Linux était une bidouille d'étudiant etc. La question n'est pas de savoir si HTML est fait pour faire telle chose, mais si HTML marche pour faire telle chose. Les applications web ont plein de bonnes propriétés par rapport aux applications natives: très facilement distribuables, collaboration entre plusieurs utilisateurs facilitée etc. Tout ça fait que beaucoup de gens développent des applications web, et donc des frameworks pratiques pour développer ces applications. On peut avoir envie de réutiliser des frameworks web ou même simplement les connaissances qu'on maîtrise (HTML, CSS, JS) pour faire des applications natives. Ensuite un moteur de rendu HTML + Javascript, c'est une base facile à utiliser pour développer son propre framework d'interface graphique.

Après, ça n'empêche pas de critiquer les limitations de HTML pour faire des interfaces graphiques (ex: communication particulièrement lourde via des appels HTTP entre l'UI et le cœur de l'application, lenteur de certains widgets complexes, complexité de la pile logicielle etc.). Juste l'argument de "c'est pas fait pour ça" est irrecevable.

Par contre, ils se chargent de très vite scanner les exécutables que tu compiles (sous Windows, et avec Symantec Endpoint Protection en tous cas). C'est arrivé à un de mes collègues, l'antivirus (probablement mal luné) a subitement décidé que le code qu'il compilait produisait des virus/vers. Comique mais aussi très énervant.

Tu peux tout pareil installer sed et grep ailleurs que sous Linux. Quand à util-linux, évidemment sous xBSD, Solaris, Windows ou Haiku, ça va pas t'être très utile.

De là à aller sous entendre que c'est rarement possible d'écrire un script bash sans dépendre de util-linux, c'est un peu fort de café. coreutils je veux bien que ce soit difficile de faire sans, mais on peut justement l'installer ailleurs.

Non vraiment, bash (+coreutils +grep) est fonctionnel sur bien d'autres systèmes que Linux.

Bash parce que je n'ai que faire de porter mon script sur autre chose qu'un système à base de noyau Linux

Gni ? Bash fonctionne sur tout un tas d'autres systèmes que les Linux dont Windows et FreeBSD au moins.

Mouif enfin si une association de défense des logiciels propriétaires (qui prônerait par exemple l'importance des DRM, brevets et codes signés pour éviter le piratage) lui passait un questionnaire avec des engagements, bah elle répondrait tout aussi favorablement.

Toujours difficile d'évaluer la "sincérité" des engagements des politiques avant qu'ils n'arrivent au pouvoir mais honnêtement, je pense pas que le FN répondrait favorablement à un lobby pro-DRM etc. Leur fond de commerce c'est d'être "anti-système", s'opposer verbalement aux grosses sociétés c'est juste une manière de faire de la communication "anti-système" à peu de frais.

Marine le Pen par là, Marine le Pen par ci, à toujours parler du FN on le met nous même en position dominante. Bon, c'est vrai, la vie privée est une problématique qui concerne linuxfr donc pourquoi ne pas en parler ?

Sur le fond de l'histoire, les politiques (et pas que le FN) font… de la politique. Ils ne se privent pas de tout ce qui peut leur rapporter des "points" (des électeurs, de l'opinion publique favorable) à peu de frais. Le FN se veut "anti-système" (pour peu que ça veuille dire quelquechose), et c'était une occasion de critiquer le système. Après aller imaginer le FN finançant activement le développement du logiciel libre, ça me parait assez naïf comme vision des choses, j'ai bien peur que ce soit très très loin d'être leur priorité. Sans compter que c'est pas la cohérence que les étouffe (comme un certain nombre d'autres politiques, malheureusement). Dans les années 90, le FN pronait une politique économique libérale et apparemment maintenant, ils sont à proner une politique économique avec un contrôle fort des entreprises et des échanges. Comme quoi.

Et bien sur, la divine Marine ne lit pas elle-même numerama, elle est (comme tous les politiques) équipée d'une armée de sbires, de communicants, de conseillers en tous genres qui se chargent de lire la presse pour elle et de lui proposer des idées de sujets sur lequels réagir.

Mais, en ce qui concerne la vie privée et le logiciel libre, faut reconnaître que le FN a de manière constante (voir notamment les questions candidats.fr) une position favorable. Après je n'irai pas manger un gateau à la m**** sous prétexte qu'il y a du sucre glace dessus, si vous me permettez cette métaphore.

C'est bien un argument qui vient contredire ce qu'alenvers dit. Tu le relèves toi-même: alenvers dit que comme il n'est pas témoin de discriminations, ça ne doit pas être très courant; mon argument dit qu'il ne peut pas tirer cette conclusion. Et si je le répète, répète, répète, c'est pas pour transformer un soi-disant non-argument en argument, c'est juste qu'alenvers répète, répète, répète la même chose à longueur de commentaires sans répondre à cet argument justement.

Sur le fond du problème, j'ai tout de même linké un post de blog écrit par une femme qui relève les discriminations subies par les gameuses et plus largement par les femmes dans la communauté geek. Dans l'article on trouve: harcèlement dans les jeux vidéos en ligne, sexisme hors-du-temps dans les publicités (windev, jeux vidéos), blagues de sur les vierges d'EMACS, blagues "make me a sandwich", idée de la « fake geek girl »… J'ai également parlé des catalogues de jouets de Noel, des injonctions pour les femmes d'être belles, douces et dociles…

Donc bon, c'est quand même un peu fort de café de m'accuser de pas avoir d'arguments pour montrer que y'a des discriminations et de juste répéter la même chose.

Mais peut-être que ça n'est pas encore assez. Donc, voici encore quelques liens sur des problèmes de harcèlement à la DEFCON: (1, 2)

D'accord on avance. Le "libre arbitre", la liberté de choix. Le problème est que les individus ne se déterminent pas uniquement d'eux-mêmes, ils sont influencés par la société (j'espère que tu ne nies pas ça, mais je pense que non). En ce sens, les femmes sont influencées pour ne pas faire d'informatique. L'idée est que pour qu'elles puissent exercer pleinement leur libre arbitre, il faut compenser les préjugés/stéréotypes par des actions spécifiques pour les femmes.

En fait, le principal problème, c'est que tu penses que les femmes ne subissent pas de stéréotypes, de préjugés et de discriminations, qui viennent les empêcher de faire de l'informatique. Effectivement, partant de ce postulat de base, les actions/événements réservés au femmes sont illégitimes. Si on part du postulat inverse (les préjugés limitent l'accès des femmes à l'informatique), elles deviennent légitimes. C'est ici qu'est le désaccord.

Si on admet que les femmes sont défavorisées, ces évènements ne sont pas au détriment des garçons mais viennent compenser un déséquilibre déjà présent. Et honnêtement, tu as a vraiment l'impression que c'est plus difficile pour un garçon d'accéder à des études/postes dans l'informatique ? Là on parle d'un stage - ou de quelques autres - mais y'en a des dizaines d'autres qui sont ouverts aux garçons. Le titre du stage c'est "Girls can code", c'est assez révélateur de l'esprit, non ? Les filles sont convaincues qu'elles ne peuvent pas coder, que ce n'est pas pour elles et on veut renverser ce préjugé. Tu vois l'idée n'est pas d'empêcher les garçons d'accéder aux études d'informatique.

Pas du tout, si les filles ont besoin de cours spécifiques c'est nécessairement qu'elles sont inférieures. Et si c'est le cas à cause des stéréotypes de la société, l'organisation de ces mêmes cours renforce ces stéréotypes et par conséquent, a un effet négatif sur le but recherché.

Tu mélanges tout. Je sais pas si c'est de mauvaise foi, donc dans le doute je réponds. Ton argument semble être: le stéréotype c'est que les filles sont inférieures pour faire de l'informatique. En faisant des stages réservés aux filles, on admet ce stéréotype, donc on le renforce. Hop une petite simplification des postulats et on arrive à la conclusion érronée. Facile.

Donc la réalité est un chouia plus complexe (le diable est dans les détails, n'est-ce pas), le stéréotype c'est que l'informatique c'est pas pour les filles, que ce n'est pas leur role. On admet pas ce stéréotype, on dit qu'au contraire c'est tout à fait le role des femmes de faire de l'informatique mais que la société les décourage de faire ça. L'idée des stages c'est de compenser l'effet négatif des stéréotypes, pas de valider le fait que les femmes sont intrinsèquement inférieures aux hommes pour l'informatique, et donc qu'il faut les aider.

Je n'ai jamais entendu l'informatique c'est un truc de garçon […]

Tu es vraiment ancré dans ta position, sur d'avoir raison. Je sais plus trop quoi faire pour te convaincre. Je me tue à répéter, répéter, répéter que c'est pas parce que toi, tu ne vois pas l'impact des préjugés, que tu n'expérimentes pas les discriminations qu'elles n'existent pas. Du fait que tu es un homme, que tu fréquentes des milieux majoritairement masculins, tu as forcément une perspective particulière, qui fait que tu est moins susceptible de te rendre compte des discriminations. Ne caricature pas ma position (je te vois venir), je n'ai pas dit que tu ne pouvais pas comprendre parce que tu étais un homme blanc sexiste et raciste. Tu peux évidemment comprendre, mais ça nécessite au moins d'écouter, de remettre en cause ces certitudes, de se mettre à la place des autres.

Tu ne sembles pas près à faire ça, et à la limite, c'est ton problème. Ce qui me dérange vraiment, c'est que les réactions négatives (pas que de ta part d'ailleurs), n'encourageant pas vraiment les femmes à nous rejoindre. Ce qui me dérange aussi, c'est que tu remportes facilement l'adhésion de la communauté avec des arguments simplistes, ce qui n'est pas très dur vu que comme sur tous les sites d'informatique, on est entre hommes et donc qu'on a peut de chances d'avoir expérimenté les préjuges sexistes qui découragent les femmes à faire de l'informatique. En ce sens tu renforces les préjugés. Non, y'a pas de problème, c'est juste que l'informatique ça les intéresse pas…

J'ai vraiment l'impression de ramer à contre-courant (contre l'idée majoritaire), avec de bons arguments. Un physicien assez connu disait que c'est plus facile de désintégrer un atome qu'un préjugé, et finalement c'est assez décourageant.

Excepté qu'elles sont sur les réseaux sociaux généralement, pas dans les FPS

Ah oui, tiens pourquoi les filles ne font pas de FPS ? Parce qu'elles ne sont naturellement pas enclines à aller vers des jeux vidéos de combats ? On peut aussi noter que le monde des « gamers » est extrêmement peu accueillant pour les filles. Si tu le courage de le lire, je ne peux que te recommander de lire Sexisme chez les geeks : Pourquoi notre communauté est malade, et comment y remédier, un post de blog écrit par une "gameuse" en 2013 et qui relève des discriminations sexistes dans la communauté gamer. Personnellement, c'est un des premiers documents qui m'a fait prendre conscience des discriminations envers les femmes dans les communautés "geek", donc peut-être qu'il te permettra aussi d'en prendre conscience.

Par contre, oui, tout le monde peut le constater, les filles et les garçons n'ont pas les mêmes intérêts.

Mais on constate en effet tous que les femmes ne font pas beaucoup d'informatique ! On est d'accord sur le constat. La question c'est quelle est la cause: est-ce à cause des stéréotypes ? est-ce naturel (ie biologique) ? Ton raisonnement est que comme il n'y a pas vraiment de stéréotype qui découragent les femmes à se lancer dans l'informatique, les facteurs naturels/biologiques doivent expliquer la faible proportion de femmes. Mon argument est que les stéréotypes ont bien un impact - et encore une fois, y'a beaucoup d'études qui vont dans ce sens, même si tu ne l'as pas expérimenté personnellement.

Sélectionner deux unique mots dans une page wikipedia, au hasard "doute maladif", c'est déjà tordre l'information à sa sauce. Prétendre rapporter des choses objectivement de wikipedia alors qu'on sélectionne deux mots d'une page pour les inclure dans une question rhétorique…

La question que je pose est : a-t-il un différence statistique significative entre les garçon et les filles du même âge au point de vue du « syndrome de l'imposteur » (qui est une forme de doute maladif) ? Si ce n'est pas le cas, on ne peut pas dire que c'est un argument dans le cadre dont on parle.

La réponse est oui en ce qui concerne les métiers techniques. Y'a des études qui vont dans ce sens et tu le sais.

En résumé, foutez la paix aux gens. N'imposez pas votre vision étriquée de la société. Et bordel de merde, ne traitez pas les filles/femmes comme des débiles profondes. Elles sont pas un minorité, c'est pas un groupe qui nécessite une aide quelconque aide (elles sont pas plus cons), être une femme n'est pas un handicap

Tu répètes ça en boucle, et c'est un homme de paille. Non personne ne dit que les femmes sont handicapés. Ni même qu'elles ont besoin d'aide, parce qu'elles sont moins intelligentes. Et le but n'est pas de stéréotyper les femmes. J'ai déjà répondu à ça, et tu re-hurle la même chose. Personne ne traite les femmes comme des débiles profondes. Quant à l'accusation de bien-pensance, c'est également la négation du débat. Toi tu tu bats du côté de la verité, les autres sont des idéologues bien-pensants. Je défends ce point de vue parce que je pense que c'est la vérité.

Désolé de t'attaquer une fois de plus sur tes qualités argumentatives, mais le vocabulaire outrancier "débile profonds", "handicap", "cons", c'est rarement un gage la bonne qualité des arguments. Ça permet parfois de remporter l'adhésion des autres, et de tuer le débat, mais ça ne le fait jamais avancer. De même caricaturer la position de ces adversaires "bien-pensants", ça ne fait pas avancer le débat.

Si tu pouvais éviter de porter des accusation toutes les trois lignes ("N'imposez pas", "biens pensants", "traitez les femmes comme de des débiles profondes" etc.), on arriverait peut-être à débattre. Tu remarqueras que j'ai fait attention à ne pas dire que tu étais un horrible sexiste. Parce que c'était pas très intéressant, parce que ça n'aurait fait que caricaturer ta position, et dirigé le débat vers un échange d'invectives. Ce serait bien si tu pouvais faire de même.

Donc, pour la 17281e fois (peut-être qu'on va finir par y arriver), les femmes se dirigent moins vers l'informatique à cause des préjugés que la société inculque. Tu veux bien répondre sur ce point précis ? La société n'inculque pas de préjugés ? Si ? C'est une bonne chose ces préjugés ? Non ? Alors, on fait quoi ?

Ce que je veux c'est qu'on putain de bordel de merde qu'on arrête de stéréotyper les femmes.

Encore une technique rhétorique. Le bon vieux miroir "c'est celui qui le dit qui y est". On fait quelquechose contre le sexisme, on se fait traiter de sexiste.

Tu veux qu'on arrête de stéréotyper les femmes ? Tu argumentes vraiment qu'un stage d'informatique réservé aux femmes, c'est stéréotypant ? C'est quoi le "cliché" ? Toutes les femmes sont des informaticiennes ? Vraiment ? Si vraiment tu veux combattre les stéréotypes, faudrait surement commencer par les choses qui sont évidemment stéréotypantes: les catalogues de jouets, la presse féminine débilisante, les messages publicitaires, les injonctions sociales. Je suis pas sur qu'un stage d'informatique pour les femmes soit très stéréotypant, en comparaison au reste. Et bizarrement, c'est la seule forme de stéréotype que tu combats.

Entre les lignes, j'arrive à lire un bon argument. Faire des stages réservés aux femmes, c'est sous-tendre l'idée qu'elles ont besoin qu'on fasse quelquechose de spécial pour qu'elles fassent de l'informatique. C'est vrai, ça pose ce problème là. Je suppose que l'idée est de faire des évènements spéciaux pendant un temps, le temps que les choses s'équilibrent et qu'ensuite il n'y en aura plus besoin.

Moi aussi je suis un peu dubitatif par rapport à ce genre d'évènements. Ça a des inconvénients. Mais ce qui me tue le plus, c'est qu'à chaque fois, et littéralement à chaque fois, qu'il y a une action/un évènement en faveur des femmes dans l'informatique, ça déclenche des réactions négatives voire aggressives chez une partie des hommes. Ce genre de réactions ne fait que que dissuader les femmes de participer. Si on arrêtait de hurler à chaque action/évènement, et qu'on regardait si ça marche ? Si ça marche, tant mieux, non ?

Je suis d'accord sur le débat de fond: est-ce qu'organiser des évènements réservés aux filles est une bonne solution pour les attirer vers l'informatique ? Est-ce que ça pose d'autres problèmes ? J'ai pas d'avis tranché sur cette question et le débat est intéressant.

Mais honnêtement, le niveau des arguments que tu avances…

À quand les compartiments de bus et de trains réservés à la moitié de la population ?

Tranquille la comparaison avec l'apartheid ? C'est quoi ? Un point Mandela, une sortie d'équivalent africain du point Godwin ? Ça n'a rien à voir avec l'apartheid, il n'est pas question de réserver les meilleures places dans la société aux femmes, ni même à traiter les hommes comme une sous-classe. Il s'agit juste d'avoir des évènements qui quelques fois sont réservés aux femmes, pas de systématiquement d'exclure les hommes.

Pour moi, cela crie à tue-tête : les filles c'est vraiment trop con, elles doivent avoir un traitement particulier pour apprendre à coder.

Non, non, non et non. C'est toi qui veut entendre ça. L'idée est que la société inculque des préjugés et stéréotypes à tout le monde qui font que les femmes vont avoir moins tendance à se diriger vers l'informatique. L'idée est simplement de compenser l'effet de ces stéréotypes.

Bref, non, les filles ne sont pas moins aptes à coder

Heureux de te l'entendre dire ! Du coup, c'est bien qu'on les encourage à coder, non ?

Arrêtez d'essayer de le faire croire !

Personne ne fait ça. C'est un homme de paille, tu prêtes à tes contradicteurs un argument faible pour le réfuter facilement. La rhétorique c'est bien, les arguments, c'est mieux.

C'est dur de ramer contre la marée ici, et ça coute du karma, mais allons-y.

Tu veux dire que les filles sont plus atteintes par le doute maladif ?

Donc tu passes de "syndrome de l'imposteur", un concept relativement répandu qui veut que certaines femmes ne se sentent pas légitimes à leur poste malgré leurs diplômes et leurs réussites, à "doute maladif", qui sous-tend que celui qui dit que les femmes peuvent souffrir du "syndrome de l'imposteur" accuse en fait les femmes de souffrir d'une sorte de maladie psychiatrique. Joli glissement sémantique. Une technique rhétorique sûrement suffisante pour persuader la moule moyenne déjà acquise à ta cause, mais niveau argumentation, on peine à décoller du bas de l'échelle.

Tu veux dire que les filles s'auto-censurent plus ?

Pour la 17280e fois (mais bon, ça ne m'étonne pas qu'il faille revenir sur ce point, c'est la cause racine du désaccord), oui les filles s'auto-censurent plus. L'idée est que les préjugés inculqués par la société viennent contraindre la place des femmes dans la société: une femme doit être belle, une femme doit s'occuper des enfants, une femme doit être une bonne mère, une femme doit s'occuper d'esthétique, les mathématiques c'est un truc de garçon, les métiers techniques c'est pas un truc de fille. Ouvre un catalogue de jouets de Noël: y'a un des bébés dans les pages filles, et des jouets ordinateur ou perçeuse côté garçon. Tout ça fait que les filles vont avoir moins tendance à se diriger vers l'informatique.

Je sais que tu penses que c'est biologique, et que donc que les garçons sont biologiquement plus enclins à s'intéresser à des choses techniques, plutôt qu'à être tournés vers l'empathie. Y'a quelques études sérieuses qui vont dans ce sens. Mais même les auteurs de ces études disent que tout n'est probablement pas biologique, et qu'ils se combinent avec des facteurs sociaux. Y'a aussi toute une palanquée d'études qui montrent l'influence des facteurs sociaux.

Alors tu peux venir éructer "BULLSHIT" haut et fort, et remporter l'adhésion de la foule. Mais celui qui hurle fort n'est pas forcément celui qui a raison. Tu sembles croire que parce que tu ne les vois pas, les préjugés qui viennent limiter la place des femmes dans la société n'existent pas. Mais juste parce qu'on ne voit pas quelque chose n'indique pas qu'elle n'existe pas. Il se peut aussi qu'on ait pas la bonne perspective. J'avoue que tu es totalement ancré dans ta position (comme une partie des gens ici, semble-t-il), et il est difficile d'espérer pouvoir te convaincre.

Sur le fond de l'histoire, je ne sais pas si organiser des évènements spécifiques aux femmes est une bonne solution au problème. Mais nier que les stéréotypes n'encouragent pas vraiment les femmes à faire de l'informatique, c'est au mieux de l'aveuglement et au pire de la mauvaise foi.

Oui mais personne n'utilise une FSM toute seul, c'est pour ça que j'ai préciser + opérateur et comparateur.

Je suis pas sur que ça suffise pour faire un truc Turing complet. Doit manquer une instruction pour faire des sauts. Cela dit, ça n'enlève rien à la distinction automate d'état fini/machine de Turing.

Tu mélanges la définition d'un cpu (== vue de l'extérieur) et son architecture.
Ok la dessus.

Un cpu, c'est une boite noire dans lequel plusieurs bus rentre et sorte, et qui est capable d’exécuter des instruction. On peut imaginer que ces instructions soient dans une ROM.

C'est vraiment une définition ultra large de CPU. Donc, ça explique une partie de l'incompréhension on avait pas la même. Donc je peux faire un "CPU" qui sait juste calculer "f(x) = 4*x" et "g(x) = 5*x" avec un jeu d'instructions qui comporte deux instructions "f" "g". A l'extreme, selon ta définition, une ALU c'est un CPU.

Non!! Tu racontes n'importe quoi. L'encodeur MP4 embarqué dans l'omap4 de TI, c'est 2 ARM M0 ou 4, qui pilote 2 DSP.

Tu mélanges tout sur ce coup. J'ai pas dit qu'on pouvait pas faire un encodeur MPEG4 avec un DSP ou un CPU.
Je dis qu'on peut faire un circuit spécifique qui fait du décodage MPEG4 qui n'est pas un CPU.

Très précisément, ça http://opencores.org/project,nova c'est pas un CPU. C'est un circuit dédié au décodage MPEG4.

Oui, c'est compliqué et surement lent, mais cela ne veut pas dire que ça l'est à coup sûr.

C'est une évidence. Si on fait un CPU avec une architecture moins bonne et une fréquence divisée par 10… Les performances des CPUs implémentés dans les FPGA sont très très faibles. C'est d'ailleurs pour ça que des fabriquants mettent des cœurs ARM et un FPGA sur la même puce.

J'ai du oublier de dire, que c'est absolument n'importe quoi de croire que faire des va et vient avec le x86 pouvait avoir un intérêt

Oui, oui… Il faut tout faire sur le FPGA (on se comprend vraiment pas). Juste que le CPU implémenté sur le FPGA peut avoir des instructions qui font plus ou moins de choses. Soit on a que des instructions génériques (les cmp, add, sub, jmp, jne classiques des jeux d'instructions) (mon cas (i). Soit on fait un CPU a une seule instructions (compile) qui fait tout (mon cas (ii)). Entre les deux, on peut comme tu dis "détecter les ensembles d'instructions" utiles, les fusionner pour en faire une instruction unique qu'on ajoute à l'instruction set de notre CPU. C'est évidemment l'approche raisonnable.

Le considère gcc uniquement comme un code C. Donc, le génerateur de bitstream peut déduire facilement les ensembles d'instructions les plus utiles et les fusionner ou dupliqué pour créer un CPU de fpga ultra rapide pour gcc.

Tu peux détailler ça ? Comment je passe de (Code source de gcc) -> (bitstream) ?

Est-ce que c'est :
1. J'ai un design de CPU générique flashable dans un FPGA. Je compile gcc pour ce CPU générique. J'obtiens le code assembleur de gcc.
2. Je détecte les ensembles d'instructions redondants dans l'assembleur générique généré par gcc. (Si ça existe, on utilise quoi comme genre de logiciels ?). On les instructions dans chacun des ensembles d'instructions pour créer des macro-instructions.
3. On ajoute ces macro-instructions au design de CPU générique qui devient un CPU "optimisé".
4. On modifie le code assembleur de gcc pour qu'il utilise les macro-instructions.
5. On flashe le CPU optimisé sur le FPGA. Et on exécute la version (4) de gcc sur le CPU optimisé.

Si on sait faire ça, c'est super impressionant ! Je serais intéressé si tu as des noms de logiciels / des tutoriels ou des papiers.

Effectivement, je suis de formation informatique (et pas électronique/hardware). Je pense que c'est l'inverse pour toi, ce qui doit expliquer une partie de l'incompréhension. Après je suis une vraie catastrophe en maths (ahem…).

La différence que tu fais sur la machine de Turing/machine d'état est artificiel.

Ça non, je suis sur de mon coup. On est sur (= c'est démontré) qu'un automate d'états fini n'est pas Turing complet. Par conséquent, on ne peut pas exprimer tous les programmes informatiques comme un automate d'états fini. Par contre, c'est pas forcément hyper lié au sujet de base (mais c'est toi qui disait ça, hein).

La structure d'un cpu est assez simple : registre, mémoire, operateurs, et instruction.

Oui pour la vision globale. Mais ça c'est un CPU des années 80. Aujourd'hui c'est quand même plus complexe. Les instructions sont micro-codées, elles ne sont pas exécutées dans l'ordre, y'a un pipeline qui fait qu'en fait on les exécute par bouts, on a des architectures super-scalaires, de la prédiction de branchement etc. C'est pour ça que c'est une mauvaise idée de faire un CPU soi-même et de le mettre dans un FPGA. Sans compter les histoires de fréquence etc. (Je sais que tu sais sûrement déjà ça, mais je voulais pas qu'on donne la vision fausse qu'un CPU performant, c'est simple).

Je crois qu'on s'entend pas sur les définition de CPU. Et de "core" d'ailleurs. Je vois pas quelle définition tu leur donne.

Il me semble qu'un CPU, c'est un circuit générique, qui n'est pas optimisé pour exécuter un type de logiciel particulier. Un circuit dédié est optimisé pour exécuter un type de logiciel particulier. Surtout un CPU a un jeu d'instructions Turing complet. Un circuit dédié peut avoir un jeu d'instructions qui n'est pas Turing complet. Par exemple on peut imaginer un circuit dédié qui n'a pas d'instruction de branchement (jump).

Tu prends peut-être une définition très large de CPU au sens de "circuit qui accéde de la mémoire et exécute des instructions depuis cette mémoire". Note que même comme ça un encodeur MPEG4 impémenté dans un FPGA, c'est pas un CPU.

Ou veux-tu en venir ?

Soit on implémente toutes les opérations de GCC en logiciel (cas i) avec des instructions assembleur dans la mémoire qui sont exécutées par le CPU flashé dans le FPGA. Soit on implémente tout en matériel dans la configuration du FPGA (cas ii). Entre le deux on peut implémenter des "macro-opérations" en matériel (décomposition SSA par exemple, une partie du parcours de l'AST etc. ou la tokenisation) et d'autres en logiciel. Et on peut implémenter plus ou moins d'opérations en matériel.

J'imagines que tu pars avec une solution simple genre gros FPGA relier à une grosse mémoire, dans un slot pci express.

Oui, enfin pas forcément dans un slot PCI-Express (mais peu importe)

seulement la machine d'état est encodé dans une mémoire sous forme d'assembleur.

Un programme informatique n'est pas forcément une machine d'état. C'est plutôt assimilable à une machine de Turing (qui permet de faire beaucoup plus de chose qu'une machine d'état). En particulier, GCC n'est pas exprimable sous forme d'une machine d'état puisqu'il sait parser autre chose que des languages réguliers (Chomsky Hierarchy).

Mais cela revient pourtant très exactement à la synthèse direct vers un bitstream.

Une fois que tu as un cpu, tu peux l'optimiser à mort comme tu le veux en fonction de la tâche à faire. C'est cette optimisation qui pourra te faire gagner du temps (VLIW, multicore,…) par rapport à l'execution sur x86.

Tout dépend de ce qu'on appelle un CPU. Un "CPU optimisé à mort", ça devient plus un CPU ça devient un circuit dédié à une tache spécifique. Un GPU n'est pas un CPU. Un encodeur MPEG4 n'est pas un CPU non plus. Même si l'encodeur MPEG4, le CPU et le GPU partagent le fait qu'ils vont transiter entre différents états, qu'ils vont éventuellement exécuter des instructions, qu'ils vont tous probablement avoir une horloge etc. Un CPU c'est Turing complet, un circuit dédié pas forcément.

Ici on voudrait transformer GCC (le code source de GCC) en un circuit dédié à la compilation. On voit bien que (i) CPU + assembleur de GCC et (ii) circuit à une instruction qui fait de la compilation, ça forme les deux extrémités d'un continuum.

Je me suis peut-être mal exprimé. Je voulais dire transformer un programme C en bitstream FPGA. Je suis pas sur que la sémantique du C soit transformable en matériel.

Implémenter un CPU dans un FPGA, ça n'a quasiment aucun intérêt (mais je suis suppose que je t'apprends rien, à avoir lu tes précédents commentaires). Premièrement parce que faire une architecture aussi efficace qu'Intel c'est pas gagné. Ensuite parce que la fréquence sera très basse (de l'ordre de quelques centaines de Mhz au lieu de plusieurs Ghz sur un ASIC).

Après oui, on pourrait se diriger vers une carte avec un CPU et un FPGA et "offloader" une partie des calculs liés à la compilation sur le FPGA (ou a défaut mettre le CPU et l'accélérateur sur le même FPGA si on a une carte avec juste un CPU). J'imagine que tu parlais de ça quand tu parlais de combinaison d'opérateur. Ça nécessiterait d'aller sacrément modifier le code source de GCC au passage. Je pense que ça n'apportera aucun gain par rapport à un CPU Intel classique (voir même que ce sera beaucoup plus lent). J'ai pas l'impression qu'il y ai beaucoup d'opérations de compilation "facilement" implémentable sur un FPGA, contrairement à du décodage vidéo.

Enfin tout dépend de ce que tu veux veux faire, et j'ai l'impression que tu n'as pas forcément les idées super claires. Ce n'est pas un mal, c'est en exposant ces idées et en débattant qu'on apprend.

On ne "programme" pas vraiment un FPGA. Un FPGA c'est (en approximation à 10000 mètres d'altitude), un circuit électronique configurable. Tu peux voir ça comme un ensemble de portes logiques (des AND, des OR, des horloges, de la mémoire), dont tu peux changer le "cablage". Un sacré ensemble de portes logiques, les FPGA moyenne gamme ayant des centaines de milliers à des millions de portes. Mieux encore, tu n'as pas besoin de décrire le cablage des portes logiques fil par fil, mais tu peux faire une description plus haut niveau en VHDL ou en Verilog. On utilise ensuite un espèce de compilateur (ou synthériseur) qui tansforme le VHDL en description de cablage. Le FPGA est capable de changer de cablage tout seul. Programmer un FPGA, c'est changer son cablage interne.

Voila pour la description "physique" d'un FPGA. Alors qu'est-ce qu'on peut faire avec ce genre de bestiau ? Hé bien on peut décrire n'importe quel circuit électronique ! Une simple porte AND, par exemple. Plus complexe, on peut décrire le circuit électronique d'un radio-réveil. Ou un filtre passe-bas. Beaucoup plus complexe, on peut décrire un circuit électronique qui fait de l'encodage MPEG4.

Tu seras peut-être alors tenté de comparer un FPGA à microcontroleur (comme un Atmega, Arduino) ou a un SoC (comme le Rapsberry Pi). Après tout, je peux faire un radio-réveil, un filtre passe bas, ou encodeur MPEG4 avec un Rapsberry Pi (ou un Arduino). La différence est que dans le Rapsberry Pi ou l'Arduino, tu charges un programme qui executé. Tu ne modifies par le cablage interne (= les liens entre les portes logiques) du Rapsberry Pi.

Pour revenir un peu vers ton idée, tu voudrais faire un FPGA qui peut "exécuter" 40 instances de gcc en parallèle. gcc est un programme en C, que tu voudrais "compiler" pour le mettre dans le FPGA (en 40 exemplaires j'imagine). Or pour l'instant on ne sait pas transformer un programme C en cablage de FPGA (je suis même pas certain que ce soit théoriquement faisable). D'ailleurs si tu commences à comprendre ce qu'est un FPGA, tu dois commencer à te rendre compte de ce que ça représente, transformer un logiciel en C en une série d'instructions de cablage.

Ce qu'on commence à faire au niveau de la recherche académique (à vérifier, je suis pas vraiment au courant des dernière avancées), c'est transformer des kernels OpenCL en cablage de FPGA. Mais pour l'instant implémenter gcc dans un FPGA ça semble pas faisable.

des prets a des taux plus ou moins normaux voir carrement avantageux je ne suis pas sur que l'on puisse dire que l'europe n'a pas donner de l'argent.

Faire économiser x milliards d'euros à quelqu'un, c'est pas exactement similaire à donner x milliards d'euros à quelqu'un. Ensuite c'est pas à 2% qu'un prête à la Grèce mais plutôt à 4-5%. La Grèce n'a pas (encore ?) coûté 300 milliards d'euros à l'Europe (et encore moins 300 milliards d'euros aux contribuables européens).

Pas filé… Prêté, pour l'instant.

D'ailleurs, dans le cas de la France, il me semble qu'on a emprunté entre 0 et 1% pour reprêter à la grèce aux alentours de 4%. Certes c'est toujours mieux que les 15% qu'ils se seraient tapés sur les marchés financiers, mais tout de même. D'ailleurs, je crois qu'on gagne 400 millions annuellement avec les intérêts de la dette grecque.

D'autre part, je rappelle qu'en contre partie de ces prêts, l'Europe a exigé un ajustement budgétaire très important de la Grèce, si bien qu'entre 2008 et 2015, elle est passé d'un déficit de 12.5% à un léger excédent.

Tout ça pour dire que pour l'instant, on a rien donné à la Grèce.

En plus, dans sa présentation Aeris mentionne la RFC 7465 (Février 2015) qui recommande l'arrêt de l'utilisation de RC4.

Je cite la RFC 7465:
« These recent results are on the verge of becoming practically exploitable; currently, they require 2²⁶ sessions or 13x2³⁰ encryptions.»

« Ces résultats récents sont sur le points de devenir exploitables en pratique; actuellement ils nécessitent 2²⁶ sessions ou 13x2³⁰ chiffrements »

RC4 est en train d'être cassé ? On est justement en train de l'abandonner.
Bref, un peu facile de dire que TLS 1.2 est complètement troué parce qu'il autorise RC4.

Le problème c'est que tu es complètement caricatural et que tu jettes le bébé avec l'eau du bain.

Y'a pas (encore) d'attaque pratique contre RC4. C'est vrai que des papiers récents montrent que le niveau de sécurité de RC4 est plus bas que ce qu'on pensait (Qualys Blog - RC4 in TLS is Broken: Now What?). Reste qu'aujourd'hui dans des conditions pratiques, on sait pas déchiffrer une communication TLS chiffrée en RC4 (en tous cas au niveau de la recherche académique). Effectivement les jours de RC4 sont comptés, et ça fait d'ailleurs partie des best practices de le désactiver.

Y'a pas de sécurité parfaite et intemporelle, les protocoles évoluent en fonction des attaques qui sont publiées. Comme le disait alenvers, on essaye de trouver un point d'équilibre entre confidentialité - intégrité - disponibilité. Tu peux pas dire que TLS 1.2 est pourri parce que RC4 est dans la spec. On va sortir TLS 1.3 qui va virer RC4. Puis demain ce sera AES qui sera cassé, et on sortira TLS 1.4 qui bannira AES. Y'a quelques années une clé DSA de 1024 bits offrait un niveau de sécurité correct (et c'était la configuration par défaut de GPG), aujourd'hui ce n'est plus suffisant.

Plutot que de dire TLS est tout pourri, on essaye de faire avancer les choses ? On pourrait discuter de virer les ciphersuites RC4 dans Firefox par exemple.

Au passage, puisque j'ai justement regardé cette vidéo hier soir, ce n'est pas du tout ce que Aeris dit dans sa présentation. Son message est justement de dire que TLS offre un bon niveau de sécurité, mais pour ça, il faut que les serveurs et clients soient correctement configurés (désactiver SSLv3, les ciphersuites RC4, supporter AES128 etc.). Il montre également que certaines banques et institutions ont des configurations qui laissent vraiment à désirer.

Linux, tu l'aimes ou tu le quittes !

Tu me réponds en prenant la défense de freejeff, donc je le redis: je n'ai aucun problème avec les réactions de freejeff (et j'en ai jamais eu d'ailleurs, j'avais trouvé que la discussion à l'origine de ce journal s'était bien passée). J'ai néanmoins l'impression que tu ne t'adresses pas uniquement à moi et que tu t'inscris dans une perspective plus globale (donc ça n'enlève rien à ton message).

Tu relèves les problèmes dans le journal de sinma, et je ne peux qu'adhérer à toutes tes analyses. Ce qui m'a le plus gêné, ça a été la brutalité de certaines réactions, (et celles de freejeff sont loin d'avoir été les plus brutales). Mais je l'ai déjà dit, je ne vais pas revenir dessus indéfiniement.

Pour finir, ton commentaire me va bien comme conclusion/cloture de discussion.