Le 22/04/2014 à 21h 10

Fuinril a écrit :



En superficie ou en population ? Parce qu’en superficie je dirais quatrième…. au moins





En population. Mais je ne connais pas suffisamment l’Inde pour me prononcer même si mon petit doigt me dit qu’ils nous déclasseraient.

Le 22/04/2014 à 15h 49

Oryzon a écrit :



Comme quoi l’Europe a aussi du bon.





L’UE fait une connerie, l’UE annule sa connerie, donc l’UE a du bon. J’adore.



La France, l’Allemagne, l’UK et beaucoup d’autres collaborent activement aux programmes de la NSA et ont eux-mêmes mis en place leurs propres programmes de surveillance. Ces pays forment l’UE et l’UE n’a rien fait d’utile pour empêcher ça (on peut bien trouver une ou deux timides déclarations, rapports, etc, mais comme en France et partout ailleurs : c’est le bruit de fond habituel, surtout à l’approche des élections).



L’UE, la seconde plus grande prison au monde. Bienvenue dans la tyrannie douce, nous espérons que vous appréciez vos programmes télés.

Le 22/04/2014 à 16h 00

hellmut a écrit :



ça nous donne une bonne excuse pour troller et continuer à rire aux dépens des non-sachants qui décident à notre place (et qui sont légions dans le pays).





Attention avec l’incompétence : si elle est effectivement très répandue il y a parfois quelqu’un de très compétent derrière. Le choix de mots de la LPM paraissait peut-être tordu et mal choisi mais le résultat est qu’il a légitimé la surveillance de masse sans en avoir l’air et en évitant remarquablement bien le débat public. On ne me fera jamais croire que c’était un coup du hasard six mois après la collaboration avec la NSA et la révélation des surveillances de masse de la DGSE, des programmes dont la création et le maintien furent le fruit de personnes parfaitement conscientes de ce qu’elles faisaient.



Napoléon disait qu’il ne faut jamais expliquer par la traîtrise ce qui peut être attribué à l’incompétence. C’est plein de sagesse. Mais l’incompétence a le dos très large de nos jours et je crois qu’il faut aussi apprendre à discerner la malveillance quand elle est à l’œuvre.







Koxinga22 a écrit :



J’ai ri.





Tant mieux. ;)







zempa a écrit :



Et bien, dans notre très chère république, les parlementaires peuvent demander des comptes au gouvernement.

Et c’est ce que ce monsieur fait en posant cette question. Ici, il s’agit de vérifier si le gouvernement a été conscient du pb et surtout a mis en place des mesures et si leurs mises en place été rapides.





La question ne portait pas sur la sécurité des systèmes gouvernementaux vis-à-vis de Heartbleed mais sur la sécurité de la toile. Or on peut dire ce qu’on veut des parlementaires mais d’ordinaire ils connaissent le sens des mots. Je crois que tu t’embourbes à défendre l’indéfendable. Je compatis.

Le 22/04/2014 à 09h 47

Koxinga22 a écrit :

• le format de ce genre d’intervention est volontairement ouvert au départ pour s’affiner au fil des débats
  
  
  
  
  
  Au temps pour moi, je pensais que la question avait été calibrée pour être reprise dans Les Nouvelles de Tours. Non c’était pour laisser le débat ouvert.
  
  
  
  
  
  reconnaitre que malgré tous les défauts de son intervention, c’est le mec qui a choisi de parler de ça quand tous les autres se sont murés dans le silence confortable de leur ignorance.
  
  
  
  Si parler réglait les choses, pourquoi n’arrête t-on pas de parler des problèmes qui nous collent au derrière depuis des décennies sans trouver de solutions ?! Parler pour parler n’apporter rien. Proposer apporterait quelque chose. Là le gouvernement fera une réponse bateau à une question bateau parce que c’est tout ce qu’on peut répondre.
  
  
  
  Le gouvernement n’a pas de prises sur la qualité du code, donc inutile de gaspiller de l’argent public et du temps médiatique avec ça.

Le 22/04/2014 à 09h 38

il souhaiterait connaître les mesures envisagées par le Gouvernement pour mettre en œuvre une sécurisation maximale de la toile



Je dois expliquer pourquoi cette question est stupide ? Tu penses que le gouvernement a une recette magique pour régler les failles de sécurité qui traînent dans nos logiciels ?

Le 22/04/2014 à 09h 30

Koxinga22 a écrit :



Maintenant, je taquine le monsieur sur sa connaissance approximative du numérique (comme l’immonde %$##*§! que j’assume être) mais je salue sa démarche





Tu es conscient que la parole des députés dans l’hémicycle est rationnée et leurs interventions longuement préparées à l’avance. Autrement dit qu’il n’y a absolument aucune excuse pour la stupidité de cette question, a fortiori venant d’un membre de la commission de la défense.



Son travail était justement d’être pertinent, c’est pour ça que l’état lui file 15k mensuels (en plus de son indemnité) pour organiser son équipe et sa permanence. Et toi tu salues le foutage de gueule.

Le 22/04/2014 à 08h 49

il souhaiterait connaître les mesures envisagées par le Gouvernement pour mettre en œuvre une sécurisation maximale de la toile



Et contre les chagrins d’amour, hein, que fait le gouvernement ?!



Cette bande de cons de l’UMP n’a toujours pas fini de sauter sur la moindre actu pour en faire une stupide et stérile exploitation politicienne.



Et dire que ce mec s’occupe d’ordinaire des questions de sécurité à la commission de la défense. Je ne vous dis pas à quel point on est bien barrés. Marionnette incompétente ou ingénu complice ?

Le 22/04/2014 à 14h 13

Reznor26 a écrit :



L’open-source c’est finalement un peu la prime a celui qui aura le plus de motivation, de temps ou d’argent pour un projet donné. Or, qui cumule allégrement les trois plus que tout autre ? Les géants de l’informatique propriétaire et la NSA.



" />





(don’t feed me)





Mais ce n’est pas du tout un troll, c’est un fait et il n’y a aucun problème avec ça. Je sais bien que certains ont l’image d’Épinal du libre fait par des codeurs bénévoles au fond de leur garage et motivés par la philanthropie mais ça n’est pas ça, ça ne l’a sans doute jamais été ou très peu de temps.



Le principe du libre c’est d’exploiter les intérêts particuliers de chacun en les forçant légalement à jouer selon des règles communes : même si tu n’as pas envie de jouer selon ces règles, tu te trouves contraint de le faire. Donc, oui, depuis belle lurette maintenant le libre est avant tout nourri par les intérêts particuliers de grandes sociétés. Ce qui ne le rend que plus utile puisque ces sociétés lui apportent leur immense force de frappe.



Petit bémol : dans beaucoup de cas ce n’est pas la contrainte légale de la licence qui dicte l’usage du libre mais plutôt une certaine rationalité économique (lorsque tu vends un service et non pas telle sous-brique logicielle que tu exploites - Hadoop par exemple - il est alors intéressant de la faire améliorer par d’autres) et les exigences consommateurs (les clients exigent de plus en plus souvent l’accès au code - les dévs par exemple)

Le 22/04/2014 à 11h 12

240-185 a écrit :



Un mec passe en revue le code d’OpenSSL et y trouve des choses bien peu râgoutantes : http://opensslrampage.org



Par exemple, ici :





Ce code tout entier est une grosse daube. Des pelletées de constantes magiques et de noms de variables à une lettre, il y a des claques qui se perdent. Pas étonnant qu’on y ait trouvé une faille.



Et donc si je comprends bien des centaines de gus sont désormais en train de refactoriser ça dans tous les sens ? Je me demande combien de failles vont être introduites par rapport à celles qui seront supprimées.

Le 18/04/2014 à 15h 45

sr17 a écrit :



Moi je ne me prends pas la tête, pour l’instant j’ai un Windows en dual boot pour les jeux. Mais je passe quand même 90% du temps à bosser sous Linux.





Oui mais bon… Rebooter, c’est chiant. " />

Le 18/04/2014 à 15h 04

Para-doxe a écrit :



Et ça ne sauras jamais vendu à Auchan.





Pourquoi donc ? Ça l’est dans certains pays depuis longtemps (Brésil par ex.) et aujourd’hui la grande majorité des smartphones (et tablettes ?) tournent sous un Linux (Android). Et avec la déportation des applis vers les services en lignes… Ce n’est qu’une question d’années.



En entreprise par contre (hors serveurs), Linux aura beaucoup plus de mal.

Le 18/04/2014 à 15h 02

Faith a écrit :



Pour les jeux, Steam commence à proposer un large choix sous Ubuntu !





Je suis au courant et je surveille du coin de l’oeil. ;)



Mais aux dernières nouvelles il y avait encore plein de jeux qui ne fonctionneraient pas. D’ailleurs s’ils pouvaient ajouter à Steam une visualisation des jeux compatibles parmi notre bibliothèque…

Le 18/04/2014 à 11h 19

Je crois qu’avec les dernières versions d’Ubuntu c’est la première fois que je vois un Linux joli. Joli, hein, pas un truc qui se veut joli mais manifestement dessiné par un programmeur ayant le sens esthétique d’un tuningman. Ça me fait regretter d’être dépendant de Windows pour le boulot et les jeux.

Le 18/04/2014 à 14h 54

Super, ça tombe bien, je trouvais qu’il restait encore à l’homo-sapiens contemporain quelques facultés de concentration. Voilà de quoi exterminer ce résidu revêche !

Le 18/04/2014 à 11h 15

C’est étrange : c’est un projet de loi sur la culture et ils n’annoncent pas de nouvelle taxe, contribution ou redevance en faveur des ayant-droits. Il y a anguille sous roche si vous voulez mon avis.

Le 18/04/2014 à 07h 03

Après la fermeture de tous les sites recensant des blagues sexistes j’espère que le gouvernement aura le courage de poursuivre avec les sites où des gens parlent de rouler trop vite, ceux où des gens évoquent des actes violents (“je vais lui casser la gueule s’il continue” - il faudrait qu’on leur envoie des psys en prévention aussi) et ceux où des gens boivent trop parce que ça donne une mauvaise image à la jeunesse.



Décidément la littérature de science-fiction et ses cohortes de dystopies n’ont pas fini d’inspirer ce gouvernement méprisable.

Le 17/04/2014 à 13h 35

ceric35 a écrit :



A long terme, bitcoin est une monnaie déflationniste donc, on ne perd pas en pouvoir d’achat.





Le terme en question est 2040, avant ça elle est de nature fortement inflationniste. Ton argument est donc que quoi qu’il se passe d’ici 2040 (et bien sûr tout se passera bien et rien n’aura changé), tu finiras par recouper ta mise après 2040. Je ne cesse d’admirer la confiance des investisseurs bitcoins en l’avenir !









…











…











Quant à savoir si elle est raisonnable… " />

Le 17/04/2014 à 11h 14

Chloroplaste a écrit :



Penses-tu que le Bitcoin puisse devenir une valeur refuge au même titre que l’or mais pour une niche d’épargnant ?





Je sais qu’à long terme ça ne veut rien vu la durée de vie des techniques cryptographiques. " />



A court ou moyen terme, en supposant que tu t’y prennes correctement (effaçage agressif du fichier, impression sur paper wallet et mise au coffre), il n’y a rien qui s’y oppose. Quant à savoir si ça en ferait une bonne valeur refuge, il faudrait demander l’avis d’un spécialiste du marché du bitcoin.

Le 17/04/2014 à 10h 46

Chloroplaste a écrit :



Pourquoi ne pas voir le Bitcoin comme un complément de ces dernières





Oui et je l’ai moi-même souligné. Mais pas pour les usages auxquels tu songes car ceux-ci sont généralistes et grand publics et le grand public ne doit pas mettre les mains là-dedans ou seulement via des plateformes centralisées, sans quoi ce sera la foire aux vols (ça commence).







Les applications envisageables possibles sont :

* Au début un Paypal aux frais de transaction inférieurs à Paypal mais accepté dans moins d’endroits. Si cela venait à se généraliser les sociétés de cartes de crédit et Paypal aligneraient leurs tarifs.



* Au début un service de courtage en bourse grand public aux transactions réduites. Mais là aussi les acteurs traditionnels s’aligneront si ça devient significatif.



* Service notarial ? Je n’y crois pas, ceux-ci couvrent bien plus que la simple garantie de la transaction et leurs frais propres sont finalement assez faibles (et ils pourraient s’aligner sur la partie purement garantie). Quant aux autres usages similaires à destination des professionnels (comptes bloqués & co), ceux-ci ont déjà accès de meilleurs tarifs et une meilleure sécurité que ce que Bitcoin peut proposer.



* Votes en ligne (rien de sérieux, on ne parle pas de démocratie et les votes seraient publics). Par exemple sondages en ligne ou évaluation du contenu sur une plateforme P2P. Aucune échange financier, ce serait simplement la même techno avec un vote nécessitant d’investir de la puissance de calcul pour dissuader la fraude.



* Micro-paiements, sachant que le vol du porte-monnaie sera fréquent si on passe par des smartphones et ces achats publics. Ce serait une option pour des paiements sans contact ou en un clic (pourboires, etc), de préférence en passant par un périphérique dédié ou une puce isolée dans le smartphone. Mais à mon avis les cartes de crédit ont un gros avantage sur le marché physique.



* Cartes de crédits pré-remplies jetables et périphériques faisant office de clés pour des services en ligne. Mais là encore je n’y crois pas.



* Transactions anonymes (dans la limite de ce qu’une entreprise ou un particulier peut discrètement miner et de façon autonome - sans pool - avec un porte-monnaie à usage unique).





Je suis sûr qu’il y aura des applications où ces crypto-monnaies seront excellentes. Mais elles seront finalement peu nombreuses du fait de leurs inconvénients et des alternatives existantes.

Le 17/04/2014 à 04h 20

vermi a écrit :



Oui des comptes sont vidés tous les jours, et oui ces compte sont remboursés par des assurances. Rien que le bitcoin, même dans sa forme actuelle ne puisse faire.





Non, ce n’est pas comme ça que le système fonctionne. Les banques surveillent le trafic et ceux qui veulent exploiter des numéros volés de CB ne peuvent pas voler plus de quelques milliers d’euros sans se faire caler. Avec Bitcoin chaque malware pourrait voler des milliards avant que tout le monde n’ait mis son OS et son AV à jour, bonne chance pour trouver une assurance couvrant ça.



Et ensuite quand la banque découvre le truc, ce n’est pas une assurance qui paie, c’est la mule dont le compte se voit soudain débité de tous ces milliers d’euros qui sont retournés à la banque d’origine. L’assurance ne paiera que si le mec est insolvable, mais en général les quelques milliers d’euros sont payés en saisissant ses biens.



Avec les cartes de crédit non seulement tu ne peux voler que quelques milliers d’euros au total mais en plus il te faut une abrutie de mule dont les biens seront saisis. Tout ceci n’est possible que parce qu’il existe des autorités centrales qui contrôlent a priori et ont des accords de coopération en cas de fraude. Jamais Bitcoin n’aura ça et le prix d’une assurance serait pratiquement égal au montant stocké sur ton porte-monnaie vu le niveau de sécurité de l’ordinateur de Mme Michu. La seule limite avec Bitcoin sera le traditionnel blanchiment mais de nos jours il y a des moyens très efficaces de faire ça.





Et oui la sécurité informatique fonctionne, vraiment, ce n’est pas un myth, et la DGSE n’écoute pas tout ce qu’elle veut quand elle veut.



Les conversations GSM chiffrées ? Déchiffrées par force brute sans sourciller. Les communications SSL ? La plupart ont des chiffrages obsolètes, au moins sur la poignée de mains initiale, et pour les autres il y a Heartbleed. Et je ne parle même pas de la possibilité très simple d’infecter ton PC, comme un quart des périphériques, pour simplement récupérer tes identifiants en amont et déchiffrer peinard.





Si tu le souhaites, tu peux vraiment crypter des données de manière indéchiffrable



Non, tu peux chiffrer d’une façon dont tu penses qu’elles résistera quelques décennies à la force brute. Et tu n’as pas connaissance des éventuelles failles qui pourraient raccourcir ce délai, éventuellement à un point déjà obsolète aujourd’hui.



Il est possible de chiffrer d’une façon a priori sûre mais tu n’as aucune certitude sur la force et la durée de ce chiffrement. Et l’histoire nous enseigne que passé une à trois décennies c’est mort. Toute espérance au-delà est délirante. Or celui qui saura falsifier les preuves deviendra de facto propriétaire des blocs.







Une clé privée bitcoin peut être bien mieux protégée que n’importe quel numéro de carte bleue



Un numéro de CB n’est que la première et la plus faible ligne de défense, la vraie sécurité est ailleurs, dans l’organisation administrative du système bancaire. Pour Bitcoin c’est la seule et unique ligne de défense.

Le 16/04/2014 à 18h 44

vermi a écrit :



a) Ton argument est valable pour toute monaie, les banques actuellement sont pourries de failles





Non et la preuve : il y a des fichiers de milliards de CB en circulations et il n’y a pas des milliards de compte en banque vidés. Parce que le système bancaire fonctionne ! Avec bitcoin tous ces comptes seraient intégralement vidés sans que personne n’y puisse rien. Comme je l’ai dit la sécurité du système bancaire ne repose pas sur l’informatique ou la cryptographie mais sur un système institutionnel de confiance et une lourde et suspicieuse bureaucratie.





b) Le paradis pour la NSA c’est quand ta carte bleue est gérée par une entreprise américaine genre VISA ou MasterCard. Bitcoin = galère.



C’est du même niveau pour la NSA. La différence c’est qu’avec Bitcoin tout le monde aura ce niveau d’intrusion dans ta vie privée, pas seulement la NSA ou Visa mais aussi ta femme et ton patron.





De plus, les adresses ne sont pas associées à un pseudonyme et peuvent changer très souvent. Bien plus galère qu’une CB échangée contre une carte d’identité en somme.



Ce n’est galère qu’en apparence car en réalité les algos ont vite fait de recouper les adresses associées à un même individu tandis que le reniflage réseau permet aisément à de grandes agences d’obtenir les identités réelles associées à ces comptes. Sans parler de tous ceux à qui tu fileras volontairement ton identité réelle (sans parler du fait que ton identité virtuelle est aussi ton identité, même lorsqu’elle n’est pas rattachée à un nom).





c) Comme je l’ai dit, le changement de paradigme économique est très grand, et nos outils actuels (crédit par exemple) s’adaptent mal à une monaie en quantité fixe.



Ce ne sont pas nos outils, c’est la nature humaine. L’individu n’accepte pas de voir le montant de son revenu diminuer.





d) Rien n’est jamais acquis. JAMAIS. Et pourtant, actuellement ça fonctionne, pourquoi ça ne fonctionnerait pas dans le futur ? La j’ai envie de répondre : la réponse D " />



Ça ne fonctionne pas et c’est pour ça qu’on ne fait pas reposer les choses importantes sur ça. C’est pour ça que les banques ne s’appuient pas que sur le chiffrement. Et c’est parce que ça ne fonctionne pas que la DGSE et les autres peuvent écouter l’essentiel de ce ce qu’ils veulent (et stockent le reste pour l’écouter dès qu’ils le pourront - bientôt).

Le 16/04/2014 à 18h 32

ceric35 a écrit :



Bon, c’est totalement faux (comme d’hab).





Et à part la foi, tu as des arguments ?





Je pense personnellement que LA crypto monnaie qui s’imposera n’a pas encore été inventée.



Les crypto-monnaies c’est comme le vote électronique : une très dangereuse idée. Au niveau institutionnel, entre acteurs de confiance n’ayant rien à cacher sur des systèmes très sécurisés et surveillés, voire peu menacés, ça peut être très utile. Mais au niveau grand public ce sera toujours une catastrophe car les problèmes de sécurité et de vie privée sont inhérents au concept de crypto-monnaie et insolubles.



Il y a beaucoup d’applications grand public possibles de ces protocoles de transactions publiques décentralisées sans tiers de confiance. Mais certainement pas des applications financières, électorales ou quoi que ce soit d’important. Et les applications les plus importantes sont sans lien direct avec le grand public et sans lien avec la finance.

Le 16/04/2014 à 16h 50

vermi a écrit :



Si les crypto-monaies arrivent à s’imposer, elles changeront durablement le monde, sûrement beaucoup plus que nous ne l’imaginons maintenant.





Ce serait une catastrophe pour les raisons suivantes qui, en fait, feront que ces monnaies ne s’imposeront jamais au grand public :



a) L’état actuel de la sécurité informatique est une grosse blague avec un quart des ordinateurs infectés et ce n’est pas près de changer. Si demain les gens stockent du pognon sur leurs ordinateurs ou réalisent des transactions depuis ces ordinateurs, les porte-monnaies bitcoins vont vite être vidés.



Aujourd’hui payer par Internet avec sa CB n’est pas un problème parce que les numéros de codes de CB sont très durs à exploiter du fait des protections non-informatiques du réseau bancaire : délais avant transferts, réseau de confiance des banques (lourdes accréditations & co), régulation a priori par les banques (autorités centrales manquantes avec bitcoin) via des mécanismes de détection des usages frauduleux, etc. Les victimes actuelles sont les mules volontaires, pas les banques ou les usagers (ou à la rigueur collectivement via les assurances contre les mules insolvables).



Et si aujourd’hui il y a encore peu de malwares voleurs de bitcoins c’est que les usager actuels sont souvent très avertis et les sommes globales encore faibles (atteindre 1% des détenteurs de bitcoins ne rapporterait que quelques milliers de dollars - je parie sur le fait que les gros détenteurs ne seraient pas touchés).



Bien sûr les paper wallets sont plus sécurisés. Mais ils sont aussi moins commodes et va expliquer ça à Mme Michu.





b) Un paradis pour la NSA et ces entreprises qui violent ta vie privée : toutes les transactions sont publiques et seulement protégées par un pseudonyme ! N’importe qui peut connaître l’ensemble des transactions passées et futures impliquant ton porte-monnaie. Et si un jour tu fournis à Amazon ton nom et ton adresse de livraison, alors ils sauront l’identité IRL associée à ce porte-monnaie. De même que la NSA le jour où tu feras une transaction en clair depuis ou vers une IP US. Et changer de porte-monnaie n’est pas une solution : des algorithmes permettent de les recouper et de les agréger en observant les transferts entre eux et les comportements d’achats.





c) Une monnaie avec une quantité fixe de pognon ? Une cohorte de problèmes :

* Moins de croissance car la monnaie ne peut pas grandir en même temps en même temps que la productivité, ce qui ralentit le processus d’ajustement des prix puisque personne ne veut baisser les siens (va expliquer à tes salariés que tu dois les payer moins cher chaque année).



* Même à taux zéro une dette pèse de plus en plus lourd avec le temps. Plus il y a de croissance, plus la dette augmente !



* Impossibilité d’agir en cas de crise. Qu’on soit contre certaines politiques monétaires c’est une chose. Qu’on soit contre toutes les politiques monétaires en prétendant que dans l’ensemble elles créent plus de problème qu’elles n’en résolvent c’en est une toute autre !





d) De toute façon bitcoin repose sur un mythe : celui selon lequel les méthodes cryptographiques seraient imparables et garanties par les Saintes Mathématiques. C’est un immense mensonge, les preuves mathématiques en question sont beaucoup plus restreintes que cela et dans la réalité ces algorithmes ont plutôt une espérance de vie de dix à trente ans.

Le 16/04/2014 à 13h 51

remixtech a écrit :



si demain tout le monde retire ses euros des banques, la confiance s’écroule





Non : si demain la confiance s’écroule, tout le monde retire ses euros des banques.

" />

Le 17/04/2014 à 07h 49

la société iSec, chargée de l’étude, indique ainsi que le logiciel ne contient ne semble contenir aucune porte dérobée



" />

SPlissken a écrit :

• Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.
  
  
  
  
  
  Lire un code de fond en comble est chiant. Si tu veux que ce soit fait (et par des gens compétents) il faut payer.
  
  
  
  
  
  Les tests c’est trop facile, donnez moi la preuve ! " />
  
  
  
  Tests et preuves ne se recouvrent pas en général, avoir l’un ne dispense pas d’avoir l’autre.

Le 16/04/2014 à 13h 33

(édité : il me manquait un bout de la page citée du fait d’un CDN bloqué)

Le 16/04/2014 à 10h 35

Un journaliste paraissant à l’antenne est par définition la voix de son employeur et le représente. Cela cesse t-il lorsqu’il s’exprime en public sur un autre média ?



Le cas est difficile.

Le 16/04/2014 à 08h 04

Marvellou a écrit :



C’est seulement une facilité pour le dev, ca n’améliore en rien les performances.





Si. Imagine une classe matrice que l’on utiliserait avec deux multiplications enchaînées :

M1 = A * B

M2 = M1 * C



Entre les deux multiplications les données vont inutilement revenir au CPU et ce dernier devra à son tour les renvoyer pour les besoins de la seconde multiplication. Le seul moyen aujourd’hui d’éviter ça c’est de créer un code spécial pour enchaîner deux multiplications. Impossible de conserver l’encapsulation.

Le 16/04/2014 à 02h 27

Mouais, de toute façon CUDA est spécifique à NVidia et en 2014 ça n’a d’intérêt que pour ceux qui sont prisonniers de leur code en CUDA et ceux qui ont des contrats à gros sous avec NVidia. Aujourd’hui on utilise OpenCL, point barre, les API proprios vont crever comme elles le méritent.



A chaque fois c’est pareil de toute façon : douze vendeurs débarquent avec leurs solutions exclusives qu’il veulent imposer au reste du monde contre redevance à gros sous et deux ans plus tard ça finit avec un standard (et quand même des gros sous du fait de ces brevets logiciels inutiles de m….).

ragoutoutou a écrit :



Si c’est bien fait, ça pourrait faire baisser dramatiquement la consommation mémoire de certaines applis qui doivent maintenir de multiples copies de mêmes blocs de données… Amélioration donc des moteurs de rendu et des pipelines de compression vidéo.





Pas du tout, les données seront toujours copiées par le pilote. La haute latence du bus PCIe (en microsecondes) interdit tout travail direct et de toute façon les CPU seraient mauvais avec de la VRAM et les GPU mauvais avec de la RAM.









Birto a écrit :



je suis pas un pro de la prog… mais une simple classe en CPP qui FAI passer les données de la RAM a la VRAM en vérifiant la synchro ce n’est pas bon ?

• qui alloue que la ou c’est nécessaire
  


• qui copie que quand c’est nécessaire
  
  etc etc
  
  
  
  je suppute mais c’est pas en gros ça mais directement intégré ?
  
  
  
  
  
  Si c’est ça, directement intégré. La différence c’est que aujourd’hui les données à copier étaient fournies à l’initialisation du bidule (tu lançais un programme sur un GPU en lui filant en même temps les données à traiter) et que les résultats étaient recopiés à la fin dans l’autre sens. Donc il n’y avait de toute façon pas de mécanisme pour gérer manuellement ces transferts.

Le 15/04/2014 à 15h 25

Internet c’est le mal, il faut que la DGSE nous protège.

Le 15/04/2014 à 13h 02

misterB a écrit :



mais que propose tu ?





Je n’ai pas la solution ! Mais ce n’est certainement pas de voter pour les mêmes apprentis tyrans, bordel, ça au moins ça tombe sous le sens ! Et je le fait que je n’ai pas la solution ne justifie pas de voter pour ces traîtres ou je ne sais quelle bêtise de ce genre.



De toute façon je sais au moins une chose : le seul fait qu’on ait mis en place un truc pareil montre que la démocratie ne fonctionne plus, il n’y a absolument rien à attendre du côté politique : ces mecs ont crée un putain de système totalitaire, leur faire encore confiance est complètement stupide. Que tu te fasses avoir une fois, ça arrive, mais récidiver c’est pathologique. Et tu n’arriveras jamais à les contrer par les urnes. Pas la peine de compter sur le peuple non plus : ce sont des abrutis de veaux et notre parole pèsera toujours moins lourde que celle de TF1 et ses “reportages-chocs chez les apprentis-terroristes de la banlieue”. Considère la démocratie comme une sinistre farce.



Le seul angle d’attaque que j’entrevois c’est l’angle technique : on doit créer des technos et promouvoir des protocoles qui rendront extrêmement difficiles la surveillance de masse : chiffrage à tous les étages & co pour tout le monde. Et l’avantage de cette solution c’est qu’elle ne nécessite pas de passer par une foutue démocratie inutile ; au pire certaines étapes sont verrouillées par quelques grandes entreprises complices mais dont l’intérêt commercial est heureusement plutôt de se démarquer du gouvernement. Pour le reste c’est plutôt la communauté de l’IT et celle-ci est assez peu favorable à la surveillance.



On ne peut pas réguler l’état alors castrons-le, rendons-le impuissant. C’est malheureux parce que je ne suis ni un anarchiste, ni un libéral ni une âme révolutionnaire mais la situation appelle des remises en cause radicales de nos perceptions.

Le 15/04/2014 à 12h 39

misterB a écrit :



Tu proposes quoi ?



ne pas voter, c’est bien mais venir pleurer derriere c’est inutile, agir en retour c’est mieux il me sembe" />





Mais comment veux-tu changer les choses en votant pour les mêmes que ceux qui ont mis en place ou laissé mettre en place ?! Ca n’a aucun sens ! Donc non seulement tu ne changes rien mais en plus tu leur donnes raison !





“Bon, les gars, vous avez en mis en place un système totalitaire qui aurait fait baver d’envie la Stasi mais c’est pas grave, hein, je vais quand même voter pour vous parce que le mariage gay/l’écotaxe/les mosquées/le pain au chocolat c’est super trop important/super trop mal. Et puis je crois à fond qu’après quarante ans à utiliser les mêmes méthodes elles vont finir par fonctionner et régler le chômage, et que votre mesure de 20 milliards (1% du PIB) va relancer l’économie.



Donc comme c’est trop super important ben je vote malgré le fait que vous vous torchiez avec mes droits fondamentaux cent vingt six fois par jour et qu’on soit en train de devenir un putain d’état policier avec un putain de vote électronique bidon pour déjà trois millions de français.”

Le 15/04/2014 à 11h 27

misterB a écrit :



Donc ne pas voter va changer les choses ?

Et rester le cul devant ton PC aussi " />





En t’abstenant tu ne changes rien.

En votant tu ne changes rien et tu cautionnes.



On parle de méthodes totalitaires. Cautionner est intolérable, il n’y a aucune excuse valable. On ne donne pas sa voix à ceux qui ont mis en place ou laissé mettre en place un flicage aussi incroyable. Très peu de partis sont innocents de ce crime contre le peuple.

Le 15/04/2014 à 11h 09

Un « puissant signal »



Dont se fichent éperdument la grande majorité de veaux qui servent d’électeurs.

La sécurité d’abord, hein ? Et puis moi de toute façon j’utilise pas Internet. Comment ? Ça concerne aussi le téléphone ? Nan mais ça c’est possible, ils l’auraient dit sur TF1.



Cela dit, je me moque des technophobes mais combien ici continuent à aller voter en sachant ce qui a été mis en place par ces élus (et qu’on ne me parle pas du FN, merci, on sait bien que si vous votez FN ça n’a rien à avoir avec Snowden - il n’y aurait d’ailleurs aucune raison, les conservateurs moraux ne défendent la liberté que quand ça les arrange) ?

Le 15/04/2014 à 11h 06

Rappelons enfin que la SAIF avait indiqué qu’il était hors de question pour les auteurs d’utiliser le fichier Robots.txt



Sont en lice pour le foutage de tronche d’or 2014….

Le 15/04/2014 à 10h 50

Les déçus pourront toujours découvrir ou redécouvrir “Vampire: The Masquerade - Bloodlines” du défunt Troika Games.



Cinq mile patches plus tard c’est devenu un excellent jeu. " />

Le 15/04/2014 à 08h 15

Voyons, c’est impossible : Montebourg nous a promis juré que ce rachat allait doper les investissements. Et comme maintenant il est ministre à l’économie (*), c’est dire s’il s’y connait.





(*) L’avantage avec nos hommes politiques c’est qu’ils sont tellement compétents qu’ils peuvent passer trente ans à occuper tous les postes un à un. Pas un seul sujet qui ne leur échappe en fiers capitaines de navires distribuant allègrement les ordres et fixant le cap par la force de leur seul nez - compétent, le nez.

Le 15/04/2014 à 07h 08

Simplifier ce serait supprimer complètement cette aberration qui taxe illégitimement une industrie pour en subventionner une autre.

Le 15/04/2014 à 07h 02

On murmure que le centre de données nécessaire à toutes ces normes serait plus gros que celui de Google.

Le 14/04/2014 à 09h 20

5h31k a écrit :



Combien de personne peuvent mettre une centaine d’heure de jeu pour comprendre tout les mécanismes? personnellement je connais maximum deux personnes pouvant se permettre cela.





Tu exagères, avec l’aide de leur wiki il m’a fallu une dizaine ou une quinzaine d’heures pour apprendre l’essentiel des mécanismes, y compris le commerce, le système de taxes et la bonne formation des armées. Et personnellement j’ai pu apprécier le jeu sans avoir les moyens d’y investir plus que vingt à trente heures, tout en parvenant dans ce délai à restaurer la France dans ses frontières actuelles à peu de choses près. Je reconnais volontiers ne pas avoir exploré le jeu en entier, n’avoir que peu colonisé, etc. Mais bon…

Le 14/04/2014 à 08h 32

Zyami a écrit :



Il est quand même costaud à jouer, très dur au niveau du gameplay avant de simplement pouvoir se développer mais ça reste un excellent jeu.



J’ai aucun mal à faire jouer des gens aux Civ, tous, mais Europa, ça en rebute beaucoup uniquement pour sa complexité.





Je reconnais. Entre la traduction catastrophique et ce gameplay extrêmement riche avec une interface qui n’aide pas le nouveau venu, il y a de quoi se cogner la tête. Surtout quand tu commences le jeu de cette façon.



Mais franchement, qui, en voyant l’image ci-dessus, n’aurait pas envie d’aller bouter de l’anglais hors de France et unifier tout cet immense bazar sous un beau tapis azur ? ;)

Le 14/04/2014 à 08h 19

Ce qui faisait la force d’alpha centauri c’était son histoire, qu’on découvrait au fil du jeu. Avec trois types de planètes différents, cela signifie t-il qu’il n’y a plus d’hiistoire du tout ou trois différentes ?



Au passage, pour ceux qui aiment les civs, voici une autre série ayant bien moins de succès mais qui à mon avis en mériterait davantage : europa universalis. Un cadre historique très intéressant (la Terre entière de 1444 à 1821) qui est suivi de façon distante (dans le 4 les événements ne sont pas à date fixe mais les mêmes circonstances aux mêmes périodes amènent les mêmes conséquences : une instabilité après 1750 déclenche la révolution française, etc). Entre les guerres meurtrières en Europe et la conquête d’un nouveau monde, il y a de quoi faire et le jeu est extrêmement riche, avec des parties qui peuvent durer des dizaines d’heures si vous les menez à terme. Sans parler bien sûr du background.

Le 14/04/2014 à 07h 57

Trop peu, trop tard, comme toujours avec la CNIL. En matière de données personnelles, la CNIL c’est un David à poil contre une armée de Goliaths armés de têtes nucléaires. Totalement obsolète, on pourrait la supprimer ça reviendrait presque au même.



Et puis, bon, quelle surprise d’apprendre que violer plusieurs milliards de fois par jour l’article 2 de la déclaration des droits de l’homme est illégal. Sans blague. Et merci pour la tranche de rire avec les accords internationaux, je suis sûr que ceux qui ont mis en place cette surveillance totalitaire vont s’empresser de vouloir la supprimer. Et puis on pourrait leur faire confiance, tiens, je suis sûr que si un texte de plus l’interdisait ils cesseraient enfin.

Le 11/04/2014 à 19h 55

Pour ma part je ne veux pas que des drones soient autorisés à voler au-dessus de chez moi ou à proximité de chez moi, du fait des caméras & co. Et si l’un d’entre eux pénètre chez moi je veux l’autorisation de le descendre.



RAF des drones, ce n’est pas dans mon intérêt mais dans celui de quelques boîtes comme Amazon ou Google et des accros au contrôle de la DGSE. Pour moi c’est la promesse de gagner 2€ par an contre un max de pollution visuelle et sonore et d’invasion de la vie privée en plus.

Le 10/04/2014 à 17h 31

vampire7 a écrit :



Dupliquer des données : perte de perf.





Oui, sauf dans les cas, nombreux (et de plus en plus avec la multiplication du parallélisme), où c’est plus avantageux que de partager en verrouillant tour à tour. Les structures immuables jouent un rôle de plus en plus grand et ça n’a rien à voir avec la sécurité.



Et puis au regard d’une compilation dynamique, le memcpy est rarement significatif. ;)





Et il n’y a pas de boucle dans mon exemple, seulement un saut conditionnel.



Au temps pour moi je pensais que tu parlais des vérifications aux indices, je n’avais pas vu ton branchement dans ton exemple. Sauf que ton premier exemple implique aussi des entrelacements/désentracements additionels et (si mes vieux souvenirs sont corrects) des aller-retours vers la mémoire, tandis que dans le second tout reste sagement dans les registres SSE. Je te trouve bien hâtif de mettre le problème sur le compte du branchement conditionnel.





Parce que le code est généré à l’exécution, pas à la compilation. Ou alors tu parles d’autre chose.



Et alors ? Qu’est-ce que ça change ? Tu écris ton code en fonction de la façon dont tu penses qu’il sera transformé en asm, puis tu vérifies la façon dont il a été compilé.



La seule différence c’est que pour le code managé il faudra effectivement attendre l’exécution. Et alors ? Il est de toute façon plus simple de placer ton breakpoint et d’inspecter à l’exécution en pas-à-pas que d’aller fouiner dans un logiciel séparé en retapant le nom de ta fonction.





Tu es très loin du compte…

Wikipedia : Modern microprocessors tend to have quite long pipelines so that the misprediction delay is between 10 and 20 clock cycles.



Tu me permettras d’être en désaccord avec une affirmation non-sourcée de wikipedia. ;)



Mais supposons que j’ai tort : combien de cycles a t-il fallu dans ton premier exemple pour exécuter les quelques trente instructions asm qu’il nécessite ? Pour qu’une pénalité de dix cycles en moyenne (20 cycles 50% du temps) multiplie le temps d’exécution de douze fois il faudrait donc que tu exécutes plus de trente instructions par cycle. Dans la réalité on est plutôt en-dessous d’une instruction par cycle, notamment à cause des accès mémoire.



Accessoirement je ne crois pas que le coût d’une erreur de prédiction soit liée à la longueur du pipeline, sauf si celui-ci est trop court par rapport aux besoins du code.





Mais en es-tu vraiment persuadé ? Tu as l’air d’imaginer que le code managé est la solution à tous les problèmes de sécurité. Tout comme d’autres s’imaginent qu’une “sandbox” permet à navigateur d’être sûr…



Il y a trois types de problèmes de sécurité que j’observe :

a) Les problèmes évitables avec le code managé (buffer overflow & co).

b) Les problèmes liés à l’évaluation des entrées (injection SQL, protocoles Turing-complet, etc)

c) Les problèmes externes (erreurs de l’administrateur, utilisateur qui donne son mdp, interface obscure, etc)



Le premier peut “facilement” être résolu (en sacrifiant des perfs et en réinventant nos piles logicielles). Le second peut “facilement” être résolu dans la majorité des cas (en utilisant de bons outils). Dans tous les cas le procédé est le même : créons des outils peu nombreux et de taille réduite, aussi simples que possibles, qui nous protégerons de nos erreurs.





il n’y a pas grand-monde qui veut d’un système aussi verrouillé que celui dont tu rêves : voir l’exemple du jailbreak d’iOS…



Pas grand monde à part l’ensemble des entreprises de la planète tu veux dire ?







divide a écrit :



Hop, un bench de perf sans appel pour alimenter le débat:

http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET





Malheureusement…

* Les tests comparent parfois des poires et des pommes.

* Le compilo de C# est une bouse qui ne fait quasiment aucune optimisation.

* On peut avoir un langage sûr qui soit plus léger que C# (pas de mise en cache du hash code, verrous dédiés, etc).

Le 10/04/2014 à 12h 44

vampire7 a écrit :



Si le code généré dynamiquement n’a accès à rien, il ne sert pas à grand-chose…





Les données ne seront pas partagées mais elles pourront être communiquées : autrement dit on peut dupliquer les données d’un processus à l’autre via un protocole spécifié par le processus hôte.



Pour un navigateur ça revient par exemple à fournir initialement au processus JS une copie du DOM et JS envoie alors les modifications à effectuer au parent, chacun des deux modifiant sa propre copie. Le genre de construction qui est de toute façon nécessaire pour mettre en place un rendu concurrent de l’exécution javascript.





Ces instructions n’ont rien de “particulières”



Je sais pertinemment ce que sont ces instructions et ce qui importe c’est qu’elles peuvent être rendues accessibles par des langages sûrs, tout comme elles le sont aujourd’hui par le C++ 11. On pourrait même choisir d’exposer un contrôle plus fin que ce qu’a fait C++ 11 qui, de ce que j’ai lu, semble avoir masqué les complexités.





Le premier truc qui aurait dû te sauter aux yeux, même sans la moindre analyse, c’est le “if” du premier cas : un saut conditionnel rate statistiquement une fois sur deux, et dans ce cas, à cause d’une prédiction de branchement ratée, il y a tout le pipeline du CPU à recharger.



Sauf que le coût est en fait négligeable parce que le code asm produit est optimisé pour les algos “next line” typiquement mis en oeuvre dans les CPU.



Cet algo se base sur la différence entre la position courante et la cible du branchement pour optimiser les cas tels que :

1: aller à 3 quand vrai

2: aller à “fin de boucle”

3: début du corps de boucle



Pour simplifier à partir du moment où le compilateur est conscient d’une méthode pour optimiser les boucles sur la plateforme actuelle il est automatiquement conscient d’une méthode pour optimiser les vérifications aux indices. Le seul poids significatif qui demeure est l’obligation de charger la taille.



Enfin n’oublions pas tous les cas où les vérifications aux indices sont simplement virés, comme dans l’exemple suivant où le compilateur vérifiera simplement “quantité” : “pour i de 0 à quantité faire tableau[i] = tableau[i] + 1”





Mais ça nécessite de savoir à l’avance quelles instructions seront exécutées, ce que ne permet pas le code managé.



En quoi ne le permet-il pas ? Il n’y a aucune différence avec un autre langage de programmation. D’ailleurs inspecter le code asm généré est un jeu d’enfant sous VS.





C’est plus que des optimisations. L’algorithme lui-même doit être adapté ou adaptable. Par exemple, s’il faut accéder à des tables pour les calculs, s’il faut des sauts conditionnels, ou même parfois des trucs simples comme des rotations de bits fréquentes, c’est mort.



Et tu pourras très bien faire ça dans un code sûr.





La plupart de ces instructions nécessitent des données alignées sur 128 bits.



Ce qui ne pose aucun problème dès lors qu’un type ad hoc existe. Comme en C++.





Quant à une vérification matérielle



Les tables virtuelles ne peuvent pas être modifiées par un code en espace utilisateur et mon intuition me dit qu’elles sont certainement trop longues à altérer et peut-être même trop longues à lire.





Qu’appelles-tu “vérifications des indices” ? Une vérification logicielle est impensable : tu n’obtiendrais pas un code 10 fois moins rapide mais plutôt de l’ordre de 50 ou plus.



Un branchement conditionnel raté (avec vidange du pipeline) coûte trois à quatre fois le coût d’une addition d’entiers, pas cinq cent fois. Il est donc mathématiquement impossible que la plus sommaire des boucles (dix instructions dont un branchement) soit ralentie de plus d’une dizaine de pourcents par l’ajout d’une vérification indicielle statiquement invérifiable exécutée sur une plateforme exotique où l’on ne pourrait pas optimiser la prédiction des branchements.





Comme beaucoup d’autres, je veux rester maître de ma machine et pouvoir exploiter chaque composant comme je le veux.



C’est loin d’être le cas aujourd’hui : l’assembleur est de bien plus haut niveau que les instructions du processeur et ce dernier contient un sacré bazar qui ne te sert à rien. Par ailleurs tous tes programmes s’exécutent en espace utilisateur et le moindre accès mémoire passe sous les fourches caudines de la mémoire virtuelle.





Mais heureusement, ce n’est pas près d’arriver, car ça supprimerait bon nombre de jeux qui requiert des performances maximales, un marché que Microsoft ne peut pas se permettre de perdre.

@

Et je t’assure que ces jeux peuvent parfaitement être programmés dans un langage “sûr”.





D’ailleurs, je te rappelle que la sécurité absolue n’existe pas, et .NET est loin d’être à l’abri des failles.



Et la ceinture de sécurité ne soigne pas le cancer.







vampire7 a écrit :



92 euros de l’heure ? Euh… c’est quoi ta boîte ? " />





Une boîte où ils ont eu la bonne idée de payer les charges et taxes, de louer des locaux, de payer les factures, d’embaucher des secrétaires, des commerciaux, des comptables, des juristes, des traducteurs, etc.

Le 10/04/2014 à 05h 56

vampire7 a écrit :



“Le web”, ça ne veut rien dire. Je parle des navigateurs : regarde un peu comme ça râle parce que sur certaines machines, l’interdiction de la compilation JIT empêche de concevoir des navigateurs performants sur le javascript… Ce genre de bidouille demande un travail énorme, et tout ça pourquoi ? Juste pour gagner un peu de perf.





Il n’est pas nécessaire d’interdire la génération de code à l’exécution pour avoir quelque chose de sûr : il suffit d’imposer que celui-ci soit au moins dans des pages mémoire différentes voire un processus différent avec des privilèges moindres sans partage mémoire (ou seulement via un protocole déclaré dans le binaire d’origine).



Cette interdiction pure et simple relève d’une volonté de vérification du code par le gérant de l’appstore. Mais c’est inefficace et des outils automatisés travaillant sur un bytecode de bas niveau vérifiable feraient bien mieux. De tels outils pourraient être invoqués à l’exécution.





2 fois plus lent ? Alors voilà un exemple. Cette opération est le cœur du mode d’opération XTS utilisé en cryptographie.



Les performances de ton exemple s’appuient sur des instructions particulières. Comme je l’ai dit rien n’empêche d’exposer des moyens de consommer ces instructions. Ce genre d’optimisations existerait donc toujours. En fait je ne les considère même pas comme des optimisations tant elles sont évidentes.



Ce qui serait inaccessible c’est :

* Le code directement en asm.

* Les alignements manuels de données.

* Les callbacks personnalisés pour les interruptions utilisées par le langage.

* Quelques autres bidouilles de ce genre.



Et ce qui serait imposé serait :

* Les vérifications des indices.

* L’initialisation de la mémoire.

* Un GC ou un comptage de références, ce qui veut dire 4 à 8 octets de plus par objet.





Est-ce négligeable ? Non. Mais entre ça et un code super-optimisé, je doute qu’on ait plus de 20 ou 30% de différence dans les pires cas. Est-ce négligeable ? Non. Est-ce que de tels ralentissements sur une poignée de programmes valent un environnement sécurisé ? Oui.





Quant au calcul déporté sur GPU, c’est loin d’être la solution miracle, à cause de toutes les latences nécessaires : transfert des données vers la VRAM, récupération des résultats, et les calculs eux-mêmes : tous les algorithmes ne sont pas parallélisables. Par exemple, un calcul de hash, c’est purement séquentiel.



Bien sûr, néanmoins c’est pour de plus en plus de programmes la voie à suivre. Et tout l’enjeu est justement de supprimer cette latence en virant le bus PCIe et en faisait du GPU un citoyen de première classe.





Ne sous-estime pas l’importance de la performance



Ne sur-estime pas l’importance des micro-optimisations et le coût d’un code sûr.

Le 09/04/2014 à 21h 13

divide a écrit :



Chacun ses priorités; tu as visiblement une obsession pour la sécurité





Il suffit de voir la multiplication des APT (advanced persistent threat - malwares qui demeurent des années sur des machines sans jamais être détectés), des virus rançonneurs, ou le fait que de plus en plus de gens stockent des crypto-porte-monnaies sur leur disque. Je n’aime pas la sécurité non plus mais là on fonce dans le mur et quand on voit ces proliférations de menaces d’une part, et de l’autre le fait que les agences de renseignement entrent partout comme dans du beurre et peuvent tout écouter, il y a quand même de quoi se dire que notre industrie se complait dans l’amateurisme.



Parce qu’à part quelques exceptions nous ne nous sommes jamais donné les moyens de réaliser des systèmes fiables alors même que les systèmes informatiques sont utilisés pour des tâches extrêmement critiques, depuis des plateformes gérant des milliers de milliards d’euros jusqu’à des pacemakers en passant par des systèmes de pilotage. Et si tu tiens à me soutenir que ce n’est pas si mauvais que ça, qu’il y a d’autres sécurités derrière, etc, j’ai des hordes d’exemples dans tous ces domaines pour démontrer le contraire.



Il n’y a que dans le logiciel que l’on trouve des clauses dédouanant les éditeurs de toute responsabilité pour les défauts du produit ! Mais dans certains pays les ingénieurs sont pénalement responsables à titre personnel du fruit de leur travail. Un jour un logiciel va causer un désastre de grande ampleur et les médias et les politiciens vont se rendre compte que nous sommes une industrie de guignols et nous lyncher. Entre un bogue OpenSSL visiblement utilisé pendant des années par toutes les agences de renseignement de la planète pour nous fliquer et les Toyota qui te forcent à rouler à 150km/h, pour ne citer que les deux scandales les plus récents, il va falloir combien d’exemples encore ?





Dans mon cas, passer mon code en .Net serait un peu me tirer une balle dans le pied.



Je pense que tu sous-estimes de beaucoup les performances actuelles d’une part et, de l’autre, celles qui peuvent être atteintes avec un bon compilateur. L’écart ne serait pas si grand que tu le penses (sauf si tu passes ton temps à coder en C et assembleur - pas du C++ à grands renforts de STL et de smart pointers).







sepas a écrit :



Le CPU ne coûte plus rien et on préfèrera booster un peu les machine en sécurisant son code avec du langage managé que de se cantonner à gagner le moindre pet de CPU pour une requête.





Je ne suis par d’accord avec ce raisonnement : cette logique est valable pour les serveurs, où il vaut souvent mieux acheter un serveur de plus que d’optimiser (encore que le problème est différent si tu t’appelles Google ou Amazon et que tu achètes tes serveurs par millions).



Sauf que derrière il y a bien des cas où on ne peut pas acheter plus rapide parce que ça n’existe pas, et tu te retrouves avec un goulet d’étranglement. Ca fait belle lurette que les CPU ne coûtent plus grand chose et que la puissance par coeur stagne. Pas beaucoup de nouveauté de ce côté là.



Je pense qu’on ne doit pas dire qu’il n’y aura pas de pb. Seulement qu’il sera beaucoup plus rare que certains le pensent.







vampire7 a écrit :



C’est tout le contraire : il n’y a qu’à voir la course à la performance des navigateurs web. Dès que tu regardes une vidéo, c’est pareil : le décodage des flux H264 et cie. sont des concentrés d’optimisations.





Justement, la course aux perfs dans le web ce n’est pas de la micro-optimisation mais des algos très sophistiqués et complexes pour analyser le code, typiquement le genre de choses où tu veux un langage de haut-niveau pour garder une lisibilité et maintenabilité. Quant à la vidéo, même si à tout casser c’était deux fois plus lent que ce qu’on pouvait faire dans un langage sûr (et j’en doute foutrement), elle est de plus en plus traitée sur GPU et pour ça le fait d’utiliser lua ou le C ne fait aucune différence.





On peut ajouter à ça bon nombre de jeux, et les programmes traitant de grandes quantité de données, comme les logiciels de retouche photo, le chiffrement de données (les instructions AES-NI ne sont pas là pour rien)… Sur ce dernier point, on peut voir par exemple pas mal de gens se plaindre du manque d’optimisation de TrueCrypt.



On peut très bien exposer des API pour manipuler des fonctionnalités spécifiques du matériel. Et puis aujourd’hui les plus grosses innovations matérielles nécessitent de toute façon un changement de l’OS pour être adapté avec la fusion CPU-GPU, afin que le GPU ne soit plus un citoyen de seconde classe avec tout ce que ça implique pour les perfs.

Le 07/04/2014 à 14h 53

sr17 a écrit :



En même temps, ne surestime t’on pas les problèmes de sécurité liés au code natif ?





En préambule permets-moi d’énumérer certains schémas d’attaques courants impossibles en code managé :

* Buffer overflow

* Stack overflow

* Dangling pointers

* Mémoire non-initialisée.

* Mémoire non-effacée (données confidentielles).

* Altération des binaires (en dotnet ils sont signés et vérifiés à l’exécution par la CLI)



J’en oublie sans doute. Je trouve ça joliment large.





Sur un système bien conçu, les logiciels n’ont pas latitude d’installer des malwares ni d’espionner les autres applications.



Un “système bien conçu” c’est quoi ?

a) Un système programmé par des aliens infaillibles ?

b) Un système à micro-noyau codé en quasi-totalité en langage managé ? Exactement ce à quoi tu t’opposes.





C’est encore plus vrai quand on utilise des dispositifs de sécurité du type “apparmor” avec des profils qui n’autorisent pas un logiciel à faire des choses inhabituelles par rapport à leurs fonctionnalités.



Ces systèmes de permissions sont et resteront réservés aux administrateurs, les problèmes de sécurité sont plus larges. Et ils ne sont de toute façon pas une solution magique puisqu’ils ne concernent toujours que quelques risques précis, souvent l’accès à certaines ressources (fichiers notamment).





Il y a dorénavant des mécanismes de protection au niveau des processeurs qui interdisent l’exécution des données. Ce simple fait ruine de nombreuses stratégie d’attaque contre le code natif.



Ce simple fait ruine un seul type précis d’attaque (l’injection de code), certes important, mais en interdisant aussi toute forme de génération de code à l’exécution (nécessaire pour un compilateur, un navigateur, etc), une limitation qui n’a pas à être imposée au code managé.





(3) La plupart des problèmes de sécurité en C étaient liées à l’utilisation d’anciennes fonctions (Genre strcpy) non bornées qui favorisaient les débordement de mémoire tampon. L’utilisation de fonctions modernes impliquant un bornage mémoire apporte exactement la même sécurité que dans un code managé.



Non parce que :

a) Tu ne peux pas être sûr que les programmeurs ont correctement fait leur travail et uniquement utilisé des constructions sûres (équivalentes au code managé), a contrario du code managé qui offre des garanties inviolables.



b) Au mieux tu peux utiliser des outils pour détecter les schémas les plus courants dans le code source mais ces outils ne détecteront pas tout et ne t’offrent donc aucune garantie.



c) Il y a d’autres façons que le buffer overflow pour exécuter un code malicieux (voir liste du début).





(4) Contrairement à une idée reçue, l’utilisation d’un langage de “type managé” n’implique pas pour autant la disparition des problèmes de sécurité. Il suffit de voir l’exemple de certains logiciels écrits en PHP pour le comprendre.



Personne n’a prétendu que cela immunisait contre les problèmes, seulement que ça en fait disparaître la plupart. Dois-je avoir recours à une analogie sur la ceinture de sécurité et le cancer ?





Est ce qu’un décodeur vidéo qui serait 3 fois plus lent ne serait pas un problème ?



Ce serait un moins gros problème que l’état actuel de la sécurité informatique, qui est une plaisanterie.



Je ne dis pas qu’il n’y aurait pas de problème. Je dis qu’il ne serait pas si gros et qu’il y en a un plus gros.





L’occupation CPU est justement un problème majeur pour préparer les données à traiter par les GPU.



Il serait plus exact de dire que le goulet d’étrangement est en général le retour au CPU, plutôt que l’usage CPU : le problème tient davantage à la latence du bus PCIe (en micro-secondes) et aux va-et-vients de données entre les mémoires, qu’au code CPU. C’est pourquoi OpenCL évolue vers un GPU de plus en plus indépendant, quitte à faire lui réaliser la tâche de chef d’orchestre pour laquelle il est pourtant bien moins rapide.



Si tu pensais au JV ce cas est un peu particulier et la limite aujourd’hui est bien encore le manque de parallélisme.





L’optimisation revient à la mode parce que la loi de moore, c’est fini. Il ne suffira plus d’attendre un an pour rendre acceptable un programme qui rame.



A l’heure où les problèmes de sécurité sont de plus en plus cruciaux et où nos processeurs se dirigent vers les 64 coeurs et des GPU intégrés capables de mâcher des milliers d’additions par cycle, je pense qu’il y a vraiment d’autres priorités que de promouvoir la micro-optimisation, même si très occasionnellement elle est utile.





Les programmeurs qui veulent optimiser n’utilisent pas boost ou stl.



Les programmeurs qui veulent optimiser ont, comme les autres, des contraintes de temps, de coûts et de sécurité.





Beaucoup de programmeurs le pensent parce qu’ils n’écrivent pas le type de logiciel dans lequel un problème.



Si tu savais avec quoi je me bats question performances…





Mais ce qu’ils ne réalisent souvent pas, c’est qu’ils appellent dans leurs programmes des fonctions qui exploitent des algos de “bas niveau” et qui contiennent même parfois de l’assembleur.



Ce qui explique la découverte de centaines de failles de sécurité chaque année dans nos OS.

Le 08/04/2014 à 11h 41

Octogone a écrit :



il existe un espoir que la raison l’emporte sur la folie des apprentis sorciers





Dans la mesure où le peuple s’en bat royalement, non. Nous avons découvert que nous vivions dans un totalitarisme depuis 2004 , violant plusieurs milliards de fois par jour les droits de l’homme, et tout continue comme avant, pépère, le bon peuple continue à aller voter comme si de rien n’était. Le chef de l’Etat collabora avec nos agresseurs et en remet une couche avec la LPM ? Pas de problème, on n’entendra même pas l’ombre d’un commentaire acidulé sur TF1.



Tiens, on est même en train de généraliser le vote électronique, c’est formidable, bientôt on pourra faire voter le peuple tous les quinze jours pour lui donner une illusion de pouvoir tandis que les résultats seront choisis à l’avance.



Ah ! Qu’on est bien dans ce troupeau de moutons. Au moins les pays pauvres ont pour excuse d’être trop occupés à gagner leur pitance pour se rebeller. Mais nous à part le fait d’être un milliard de connards…