Le 05/04/2014 à 17h 21

divide a écrit :



J’ai l’impression que tu as complètement zappé toutes les applications qui sont basés sur les performances pures, sans aucun lien avec les problématiques de sécurité





Premièrement rien n’est “sans aucun lien avec les problématiques de sécurité” : tout code disposant de droits peut être subverti. Ton innocent jeu peut être utilisé pour miner des bitcoins, pour te soutirer ta monnaie virtuelle pour les revendre à d’autres joueurs (jeu en ligne), pour télécharger et installer un malware sur la machine, pour espionner ton navigateur et récupérer tes identifiants, etc. Et puis on ne compte pas le nb d’applis critiques en termes de sécurité encore codées en C/C++ aujourd’hui sans que ce soit nécessaire.





Ensuite l’exigence en termes de performances n’est absolument pas un pb parce que :

* Aujourd’hui les performances c’est une affaire d’algos, et notamment de parallélisation, pas de trois instructions CPU en plus ou en moins (je caricature un peu, voir la suite).



* Aujourd’hui les performances c’est une affaire de GPGPU et d’archi hétérogène. Il y a un travail spécifique à y faire en termes de sécurité mais les performances sont insensibles au fait que tu utilises lua ou le C pour piloter ton GPU.



* Avec un bon compilateur il est possible d’avoir d’excellentes performances en C#, souvent supérieures à celles d’un C++ moderne avec son cortège boost/stl qui répliquent les lourdeurs du C# (parfois en pire). Ne manque vraiment que la capacité de contrôler plus finement les allocations et d’avoir des objets plus légers et sans introspection, d’où un projet comme celui de M#, sûr mais léger. Et il manquait un vrai compilateur, ce qui est en passe de correction.



* Cela restera t-il plus lourd qu’un code C très optimisé ? Oui et il faudra faire avec, ce qui ne sera pas un gros problème.







psn00ps a écrit :



Une simple boucle for avec rien que des new dedans montre que le temps de chargement des libs est non négligeable. " />

Je pense plutôt à un binaire lambda dans la nature. Sans le source, tu perds l’assurance que le binaire sera exécutable sur ta machine. (à moins qu’il ne soit dès le départ dépendant d’une librairie native, mais là c’est autre chose)





Si tu voulais dire par là que le compilateur JIT ne peut pas être rendu plus efficace, nous sommes d’accord, il faut de l’AOT.

Le 05/04/2014 à 16h 34

divide a écrit :



Curieux de savoir ce qui t’as volontairement fait passer de C++ à C# ? Je trouve le combo C++/Qt particulièrement souple et optimisé.





Premièrement c’était autour des années 2k, donc les biblios et le langage étaient très loin de là où ils sont aujourd’hui.



Et même aujourd’hui pour rien au monde je ne retrouverais ce foutu modèle de compilation par inclusion, pour rien au monde je n’échangerais mon GC contre des smart pointers (ou alors en option et sans avoir à polluer mon code avec douze annotations cryptiques), pour rien au monde je n’abandonnerais mes async-await-yield contre douze barriques de STL, pour rien au monde je n’échangerais mon introspection contre des bidouillages. Sans parler du fait que si aujourd’hui, après quinze ans d’attente, le C++ a fini par être modernisé, je ne suis pas prêt d’oublier les quinze années en question.



Enfin ajoute à cela le fait qu’à mes yeux des langages comme le C++ doivent et vont disparaître (peu ou prou) : l’état actuel de la sécurité est intolérable, nous devons admettre notre incapacité à écrire du code sûr et opter pour les outils qui permettent le plus de vérifications automatisées possibles. La seule alternative au code managé c’est la virtualisation stricte (la gourmande) à tous les étages et ça pose beaucoup plus de problèmes (GPGPU etc).









Nithril a écrit :



J’aimerais bien savoir en quoi…. Java serait plutôt à la traîne, même si Java 8 change un peu la donne





Les contraintes génériques sont beaucoup plus puissantes en Java (et la v8 a des méthodes directement dans l’interface en plus des méthodes d’extension). Le typage de Java est tout de même beaucoup trop limitatif, je ne dis pas que c’est un modèle, simplement qu’il est un peu moins naze que celui de C#. J’en ai ma claque d’écrire des “for” plutôt que des “foreach” sous prétexte de virer des tonnes d’allocations inutiles.









psn00ps a écrit :



Le concurrent n’est pas un foudre de guerre côté performances, .NET non plus jusqu’à maintenant.





C# a de bonnes performances, proches d’un code C++ 11 compilé sans optimisations. Ce qui me tue c’est de devoir bousiller mon code en faisant certaines optimisations à la main parce que le compilateur est une prune.







psn00ps a écrit :



#barbu #garage

EDIT: je vois le côté natif comme un retour en arrière.

ça empêche de prendre un binaire généré en x86 pour le mettre sur un ARM.





En même temps les serveurs de l’app store MS recevront du code IL et compileront aussi pour ARM. Et pour ta part rien ne t’empêche de continuer à compiler en IL.

Le 05/04/2014 à 07h 12

Maxim Killigan a écrit :



Combien de développeurs ont participé aux commentaires ?



Parce que, perso, du C# natif sous Linux, ça me fout une demi molle.



Et bien que fan du cpp, il est évident qu’en matière de revenus générés, c# est loin devant car tellement facile.



Et il est évident que l’attitude de Microsoft a été vers l’ouverture depuis les dernières 5 ou 6 années.



Et encore une fois: je ne suis pas un fan de MS, loin de là, mais il faut aussi ouvrir ses yeux.





Et bien écoute, en tant qu’ancien dév C++ volontairement reconverti au C# presque depuis son introduction, ça me fait plaisir de lire ça.



Bon après moi j’en suis au stade où ses limites (*) finissent par me sortir par les yeux au point que je cherche un nouveau langage mais je crois que je vais chercher longtemps avant de trouver mieux.

" />





(*) Typage trop restrictif (sur ce point C# < Java < C++ !), absence totale d’optimisations des allocations (à voir si leur compilo AOT corrige ça) qui rend l’utilisation de certaines fonctionnalités prohibitives dans certains contextes, et une certaine verbosité dans certains cas, notamment des choses typiquement fonctionelles (types imputables & co, comme en Java ou C++)

Le 04/04/2014 à 20h 30

Haemy a écrit :



Ne rêvez pas, si Microsoft fais de “l’open source” c’est qu’il y a un intérêt derrière.





Et c’est bien parce que l’open-source permet à des forces colossales de trouver leur intérêt en lui contribuant que l’open-source a prospéré. Le rôle de ces grandes entreprises contributrices, motivées par des intérêts financiers, a été déterminant dans le succès des solutions open-source. L’open-source c’est un but “altruiste” atteint en mettant à profit des acteurs non-altruistes, contraints par la valeur légale des licences, et les désirs d’indépendance et de contrôle de leurs consommateurs institutionnels.



Peu importe les intérêts des uns ou des autres, seules importent leurs contributions.

Le 04/04/2014 à 18h 11

Excellentes nouvelles et tant mieux, j’ai hâte de voir si la mayonnaise du développement multi-plateformes à la dotnet prend. Ce millésime de build aura décidément été un grand crû.

tanguy_k a écrit :



Ça vaut ce que ça vaut, mais Java est le 3e langage le plus populaire sur GitHub, C# est 9e derrière Objective-C :http://adambard.com/blog/top-github-languages-for-2013-so-far/





Github n’est représentatif que de l’open-source, le classement dans les offres d’empois internationales est très différent et c# y est souvent troisième aux côtés de Java et JS.

Le 04/04/2014 à 13h 06

Non, rien de rien, non, je ne regrette rien….

Le 03/04/2014 à 19h 13

Bylon a écrit :



Tant qu’ils continue à racketter sur le PC : çaylemal.



“Don’t be evil” dit Google à qui au contraire ça réussit plutôt bien.





Faire payer un produit qui a nécessité le travail de milliers de personnes pendant plusieurs années c’est mal ?

Mais traquer les gens du soir au matin, les profiler dans les moindres détails et les manipuler via de la publicité en contrepartie de produits gratuits c’est le bien ?



Les moutons, les loups, les porcs, etcétéra.

Le 03/04/2014 à 16h 51

Nos hommes politiques vont pouvoir continuer à troller sur Twitter (la limite de leur horizon connecté), tout en ajoutant en plus des smileys. Voilà qui va nous réconcilier avec la démocratie.

Le 03/04/2014 à 14h 20

En tant qu’utilisateur je suis ravi.



En tant que développeur je souhaite bonne chance aux mecs qui devront créer des UI capables de fonctionner aussi bien sur un écran de portable avec tactile que sur une fenêtre de taille arbitraire avec souris ou des tablettes de 3840px. J’espère qu’ils ont dans leurs nouvelles API de quoi gérer efficacement des recompositions totales de l’UI (ce qui n’est pas le cas aujourd’hui).



A mon avis ça va sérieusement handicaper le développement d’applications sur cet OS et aboutir à des applis insatisfaisantes.

Le 03/04/2014 à 13h 42

Ricard a écrit :



" /> Il a promis de faire baisser le chômage et relancer l’économie.

Moi je le crois." />





Oh ben tu peux : le chômage finira par baisser et l’économie par repartir, il n’y a rien à faire pour ça.



Il y aura toujours des pelletées de chômage et une croissance morose. Mais moins qu’en plein cœur de la plus grande crise économique mondiale depuis 1929.On reviendra aux bons vieux niveaux qui ont été les nôtres ces quatre dernières décennies, parce qu’on ne change pas une formule qui gagne.

Le 03/04/2014 à 13h 07

Ricard a écrit :



Son ennemi, c’est la finance.





A voir la LPM et sa collobration avec la NSA, je crois que son ennemi c’est nous.

Le 02/04/2014 à 19h 59

DniMam a écrit :



La plupart des éditeurs cités sont inconnus du grand public " />





Le grand public a de maigres besoins et préfère se prostituer en filant ses données personnelles et son temps de cerveau disponible contre de petites applis, ce qui rapporte mais pas tant que ça.



Le pognon est dans les entreprises.

Le 02/04/2014 à 16h 55

Anna Lefeuk a écrit :



L’arrivée de Netflix devrait permettre de remuer le marché au niveau des délais de diffusion et de la facilité d’accès pour les clients français depuis une offre à un prix accessible





Je ne pense pas : à mon avis dans sa grande sagesse notre gouvernement va attendre encore dix ans pour être bien certain qu’il ne reste aucun concurrent potentiel en France. Ainsi à l’avenir nous pourrons exclusivement consommer des productions américaines, diffusées par des sociétés américaines depuis un paradis fiscal ou un autre grâce à la magie de l’UE.



Bravo les gars, rien à redire, c’était très fort. Au moins notre gouvernement nous pond des tonnes de rapports pour nous expliquer pourquoi nous sommes dans le mur et se demander s’il faut en sortir (ce à quoi la réponse est invariablement : non, pas tout de suite).



Allez, réjouissons-nous : ébaudis par cette profusion de divertissements de haute qualité nous n’aurons pas le temps de penser à la surveillance et l’inféodation dont nous sommes l’objet.

Le 02/04/2014 à 16h 16

flagos_ a écrit :



Ce n’est pas ce qui est dit. Il y est dit: 1 code, 3 plateformes. Si le code est blindé de switchs pour supporter toutes les plateformes, ca ne marche pas. " />





Mais tu es obligé de traiter plusieurs cas, simplement c’est en idéalement fonction de la résolution (et d’autres facteurs du niveau utilisateur) et pas de la plateforme : quelle que soit la techno tu ne peux pas avoir la même UI pour du tactile format téléphone ou du fenêtré pour PC. Au mieux tu peux partager quelques éléments et les technos derrière. Au développeur de faire les UI selon ce qu’il veut supporter.



Donc je réitère : c’est seulement pour les développeurs, pour avoir moins de contraintes et partager plus facilement le code, les outils et des éléments UI entres les diverses plateformes Windows (et les autres).

Le 02/04/2014 à 14h 47

Espérons que cette cuvée sera bonne, celle de l’année dernière était extrêmement décevante. Mais je m’attends à des annonces importantes et plaisantes.

Reparateur a écrit :



ce qu’il appelle applications c’est différent d’un programme?









flagos_ a écrit :



Bref, l’interface unique, je n’y crois pas du tout.





Vous vous méprenez sur le sens de l’affirmation : c’est une conférence pour développeurs, l’unification sera au niveau technologique, pas au niveau utilisateur.







monpci a écrit :



…





Quelques corrections :

* Dotnet n’est pas du tout une machine virtuelle.

* Si MS impose un socle technologique ce ne sera pas dotnet mais quelque chose de plus primitif avec lequel dotnet sera compatible (tout en mettant en avant dotnet pour le développement), au moins en grande partie.

* A mon avis MS entend bien continuer à supporter un vrai C++ pour longtemps.

Le 01/04/2014 à 14h 32

BlackBerry veut renouveler le phénomène disruptif de l’iPhone



Et moi je voudrais un poney mais on n’a pas toujours ce qu’on veut. " />

Le 31/03/2014 à 23h 15

DahoodG4 a écrit :



Pour travailler en Allemagne je peux vous dire qu’elle a l’air ridicule la Merkel.

Lors des premières révélations de Snowden sur l’espionnage massif des citoyens, elle avait déclaré qu’au final, ce n’était pas si aussi dramatique que ça en avait l’air… .





Le nôtre a bien décidé de “collaborer” (c’est le terme officiel) et a participé au montage d’une opération “la France, meilleur nouvel ami des USA” avec photo sourire en pleine débâcle Prism. Alors certes Angela Merkel brasse de l’air au bal des faux-culs depuis un an mais c’est peut-être mieux qu’un collabo traître.



La seule certitude que j’ai c’est que personne dans l’UE n’a jamais eu le désir de s’affranchir de la surveillance de masse des ricains. Ce qui fait drôlement réfléchir.

Le 31/03/2014 à 23h 11

js2082 a écrit :



T’inquiètes pas,les deux derniers paragraphes n’étaient pas contre toi mais contre ces cons de parisiens qui prennent leur voiture pour aller au taff.





En même temps il est difficile de s’en passer pour des millions de personnes habitant en région parisienne. Et à côté de ça le chauffage au bois (pourtant 4% seulement du chauffage en France) émet à lui seul plus de particules que toutes les bagnoles réunies ou que toute l’industrie.



Tu veux résoudre le pb de la pollution ? Et bien au lieu de chercher à bannir la bagnole et autres tâches invasives et impossibles nécessitant des investissements démesurés tu cibles le chauffage au bois et le diesel. Ce sera beaucoup plus simple et efficace, avec 50% des émissions concernées.



Maintenant reste à savoir si tu as une dent contre la pollution ou contre la bagnole. ;)

Le 31/03/2014 à 17h 15

Contrôle des sources sur serveur distant avec sauvegarde sur deux sites, le tout géré par un fournisseur tierce-partie.

Je me fiche de perdre mes films de vacances et ma discothèque, pas mon travail.

Le 29/03/2014 à 09h 56

Mr.Nox a écrit :



Netflix pourrait ne pas se prendre la tete , du moins pour mettre un pied en France, en proposant leur service directement depuis les US aux français via le net.

Ils pourraient largement tâter le terrain de cette manière sans se prendre la tête avec toutes les règles archaïque de l’hexagone.





S’ils font ça la France va considérer que Netflix opère illégalement chez eux et les condamner. Si Netflix est condamné en France, alors la France peut :



* Faire saisir leurs biens et leurs recettes partout en Europe et dans tous les pays avec lesquels nous avons des accords (donc bloquer les paiements réalisés depuis les banques de ces pays vers Netflix).



* Mettre en place une censure DNS ou IP qui fera perdre à Netflix et à ses clients le marché français qui pèsera à terme 5 à 10% de leur marché publicitaire (donc résultat négatif pour l’année et perte de capitaux alors que Netflix en manque déjà par rapport à ses concurrents).



* Demander aux FAI de ralentir Netflix, comme l’a fait Comcast uax USA ou comme le fait Free avec YT. Et dans la mesure où Netflix est en concurrence avec eux ils ne vont pas se gêner avec l’excuse de la défense des intérêts nationaux sous le coude.

Le 28/03/2014 à 17h 53

thibsert a écrit :



En effet ça déménage ! Malheureusement la plupart moisissent sur place vu que les enseignants ne les utilisent pas… Enfin, à part les deux ou trois qui sont assez curieux/geeks pour essayer et trouver ça formidable.

Et je prévois le même avenir pour les tablettes scolaires, qu’elles soient e-ink ou pas.





Pour ma part je ne trouve pas que ça dééménage puisque, comme avec les étro-projecteurs en leur temps, le contraste est faible, l’effet délavé et la nécessité de baisser la lumière déprimant. Du moins c’est toujours l’effet que ça m’a fait.



Quant à les exploiter, ça c’est l’affaire du logiciel. Si tu attends que les profs se mettent à développer des applis et a fortiori des applis qui nécessiteraient des centaines d’heures de travail à un pro, bonne chance. Sans parler des API proprios de ces saletés.

Le 28/03/2014 à 13h 31

xloxlox a écrit :



pourquoi pas en couleur ? trop cher ? probleme technologique ? …y a des jeux ?





Ce n’est pas un écran, c’est un système d’encre électronique. Grand confort de lecture (équivalent papier) et super autonomie (des semaines) mais affichage statique (forte latence). Donc pas de jeux, ou alors des mots croisés et du sudoku.







xloxlox a écrit :



franchement a cette taille la je trouve que ca commence a etre bien pour lire un bouquin





Non, c’est trop grand. Crois-moi, les liseuses actuelles sont parfaites au niveau taille, au-delà c’est ennuyeux à tenir (lourd et nécessite les deux mains). Ce qu’il faudrait maintenant c’est du flexible pour une meilleure prise à une main, un contraste encore plus élevé et un poil plus de réactivité parce que l’ergonomie de l’interface n’est pas terrible. Bon et puis de la couleur.

Le 27/03/2014 à 22h 10

tanguy_k a écrit :



Pour simplifier la compilation c’est une transformation (ou une traduction).





Je te remercie mais je suis l’auteur de plusieurs compilateurs et outils de compilation j’ai donc une très vague idée de ce qu’implique la compilation.

• Quand tu transformes un langage haut niveau vers un bytecode “haut niveau” proche du langage source (CLR, JVM) => rapide
  
  
  
  
  
  • Quand tu transformes un langage haut niveau vers un langage bas niveau (de surcroît générique) => lent
    
    
    
    Non, primo l’étape la plus longue c’est toujours l’analyse. D’autant que de nos jours la plupart des compilateurs battissent leurs graphes SSA durant cette phase pour détecter des variables non-initialisées et autres joyeusetés.
    
    
    
    Ensuite en mode développement/débogage, là où la compilation doit être rapide, on n’optimise pas, donc la traduction du bytecode en assembleur est triviale.
    
    
    
    Par ailleurs tu n’as qu’à te rendre compte que ton navigateur fait cent fois pire que tout cela avec JS puisqu’il faut en plus reconstrurie un système de types et que pour autant tu n’as pas le temps de le remarquer. De même que les bytecodes Java et Dotnet sont transformés par les compilos JIT plus rapidement que tu ne peux t’en rendre compte.
    
    
    
    Enfin tu devrais te rappeler que la compilation est conduite de façon incrémentale : on ne régénère pas en temps ordinaire le projet d’un bout à l’autre, seulement les parties modifiées. Et c’est pour ça qu’au quotidien la compilation AOT est instantanée, foi d’un mec qui passe ses journées à presser F5.
    
    
    
    
    
    C’est pour ça que je te demande des chiffres pour LLVM : ils ne sont pas de l’ordre de la demi-seconde, sinon tu m’aurais déjà cloué le bec depuis longtemps.
    
    
    
    Tu n’as pas de chiffres parce qu’un compile C++ est lent pour d’autres raisons (en-têtes, templates et inclusions) et parce qu’un compilo Java compile en bytecode. Donc il n’y a aucun chiffre disponible. Et parce que de toute façon je pourrais bien perdre du temps avec des recherches google pour te trouver des chiffres que tu m’enverrais quand même balader en prétendant que la compilation AOT ma bonne dame ça prend des heures.
  
  

Le 27/03/2014 à 18h 47

tanguy_k a écrit :



Donc d’après toi LLVM compile du code en “une demi-seconde”.





Voici deux propositions parfaitement logiques :



a) Il est plus rapide de compiler un langage vers le bytecode LLVM que vers un langage assembleur spécialisé. Donc la compilation AOT vers ce bytecode serait plus rapide que ne l’est la compilation JIT aujourd’hui.



b) Il est extrêmement plus rapide de compiler un bytecode LLVM vers de l’assembleur que de parser, analyser, construire un système de types et finalement compiler vers de l’assembleur un langage comme JS. Donc la compilation JIT de ce bytecode serait plus rapide que la compilation JIT de JS.





La seule chose sur laquelle tu peux pinailler c’est que dans le (a) la compilation AOT totale est en fait comparée à une compilation JIT paresseuse. Mais les compilations AOT de Java ou dotnet vers leurs bytecode respectifs sont extrêmement rapides (de l’ordre de la demi-seconde pour de gros projets) et l’usage du bytecode LLVM n’introduit pas de difficulté supplémentaire.

Le 27/03/2014 à 17h 39

tanguy_k a écrit :



Des noms, liens, articles, chiffres… ?





Les noms tu les connais déjà : asm.js, pNaCl, midori, etc.

Le 27/03/2014 à 13h 12

tanguy_k a écrit :



On va s’arrêter la parceque parler d’une utopie (1) sortie de ton imagination





Une “utopie” sur laquelle travaillent Google, Mozilla et MS avec des solutions déjà téléchargeables aujourd’hui et soumises à divers comités de standardisation.





Parles-en à Lars Bak, ca fait 20 ans qu’il travaille sur ces sujets (VM Smalltalk, HotSpot, V8 et maintenant Dart), il t’embauchera surement.



Encore une fois tu n’as pas compris ce qu’il disait. Tu n’as pas compris que le type de bytecode dont il parlait n’était pas celui dont je parlais et que ses arguments concernant l’absence de bytecode pour Dart ne s’appliquaient pas du tout à ce dont nous parlons.





bref que des avantages et aucun inconvénients - elle est pas belle la vie la, hein ??



Effectivement, que des avantages et aucun inconvénient. Oui, la vie serait plus belle qu’avec JS ou Dart.

Le 27/03/2014 à 11h 38

L’idée de base est la même que pNaCl qui est un bytecode type assembleur (et non pas un bytecode type java). Le problème de pNaCl c’est qu’il vient avec les API de Google. Il y a aussi asm.js mais celui-ci est plus long à parser et plus volumineux. Ou peut-être le nouveau bytecode du projet Singularity de MS mais je crains qu’il soit d’un niveau trop élevé.





Et je ne dis pas que ça rend osbolète les VM & co, simplement qu’on peut construire ceux-ci par-dessus sans inconvénients, tout comme on les construit aujourd’hui au-dessus du langage assembleur.

Le 27/03/2014 à 10h 46

tanguy_k a écrit :



Tu parles de C# et Java ? VM bytecode => on tourne en rond.



Disons que tu as raison et qu’ils sont stupides de créer un langage interprété puisque l’étape de compilation c’est facile et (presque) instantanée pour le développeur…





Ce n’est pas ce que j’ai dit bon sang !



Ce que j’ai dit c’est qu’il sont stupides de créer un langage plutôt qu’un bytecode élémentaire analogue à un langage assembleur. Ce qui serait beaucoup plus léger à transporter, plus rapide à compiler par le navigateur, rétablirait le choix du langage et offrirait à tous ces langages le loisir de profiter de performances maximales ou quasi-maximales.



Le coût d’une demi-seconde par compilation pour le développeur, compensée par un démarrage plus rapide (vu que parser JS et reconstruire un système de types c’est pas gratos), me semble un très maigre prix à payer et je pense que toute personne sensée peut en convenir.

Le 27/03/2014 à 09h 55

tanguy_k a écrit :



?

Ne pas avoir d’étape de compilation c’est évidemment un (gros) plus pour le confort du développeur, sinon les langages de script n’existeraient pas.





En quoi serait-ce un gros désavantage d’attendre une demi-seconde en plus lors du déploiement et une demi-seconde en moins lors de l’exécution ?



Faut oublier le C++ et son modèle d’inclusion obsolète, la compilation d’un langage moderne en mode débug c’est extrêmement rapide et beaucoup plus rapide qu’une compilation JS JIT avec son inférence de types (même en mode paresseux).

Le 26/03/2014 à 20h 42

tanguy_k a écrit :



Donc il y a bien une étape supplémentaire… CQFD.

Et c’est loin d’être un détail, non ?





Étape en amont, sur la machine du développeur et allégeant le travail sur la machine de l’utilisateur ! Tu es en train de prétendre que la compilation est une mauvaise chose, c’est délirant.





Il faut différencier PNaCl et NaCl. PNaCl s’appuie sur le bytecode de LLVM. On est plus proche de la JVM que du langage machine/binaire.



Je différencie bien les deux et le bytecode pNaCl est beaucoup plus proche d’un langage assembleur que du bytecode java. En particulier le bytecode pNaCl se focalise sur la manipulation de données primitives via leurs adresses (lire mémoire, stocker dans mémoire) et non pas sur la manipulation d’éléments d’un système de types de haut niveau comme le bytecode java (lire membre de, instancier tel type, etc).





Ça évoluera peut être, mais je ne le crois pas.



C’est Dart qui polluera, pas asm.js.





Approche intéressante, mais je suis pas sur que ça soit le sens de l’histoire (heureusement ou malheureusement - j’ai pas d’avis) :)



Mais si c’est dans ce sens là qu’on va aller, c’est inévitable, parce qu’un écosystème de tierce-parties innove plus rapidement que les comités techniques rédigeant les standards. Demain un framework UI plus riche et plus rapide que html sortira et c’est lui qui s’imposera. Sans parler du fait que Chrome, Mozilla et d’autres voient déjà le navigateur comme un OS.



La seule question est de savoir quels seront les dénominateurs communs à moyen terme : un bytecode rapidement parsable et compilable fournissant d’excellentes performances pour tout le monde ou bien un langage de haut niveau (JS) limitant les possibilités d’optimisation de tous les autres langages ? Un accès efficace au GPU ou bien un html lourd et encombré par la rétro-compatibilité ? Autrement dit quelles dettes techniques nous traînerons-nous et combien de temps ? Parce que c’est ce que JS et html vont être : des dettes techniques.

Le 26/03/2014 à 19h 11

tanguy_k a écrit :



Rien n’est imposé, la VM Dart c’est en plus de la VM JS => choix :-)





C’est une restriction moins grande mais ça reste une restriction sévère. et puis franchement quitte à supporter deux langages autant en avoir deux franchement différents. Dart c’est vraiment le truc inutile pour moi et qui va encore complexifier inutilement les navigateurs avec tout ce que ça va poser comme problème. Je préfère cent fois que Mozilla, Opera ou Canonical n’ait pas à claquer du fric pour ce truc inutile.





J’imagine que tu veux parler de asm.js (ou tout du moins du principe d’une VM avec un bytecode).

• Malheureusement tu introduits alors une étape supplémentaire de compilation
  
  
  
  Pas du tout ! Le JS et Dart doivent aussi être parsés et compilés et ces deux opérations sont beaucoup plus complexes pour ces deux langages. Si étape supplémentaire il y a c’est en comptant la compilation faîte en amont par le développeur. C’est comme protester contre l’assembleur au motif qu’il serait plus rapide pour le CPU de traiter directement des sources C++ : absurde.
  
  
  
  
  


• De plus tu perds en perfs (j’ai pas de chiffres) entre une VM avec 1 seul langage vs VM avec bytecode (c’est pas moi qui le dit mais Lars Bak Wikipedia(computer_programmer) j’ai pas vérifié en expérimentant)
  
  
  
  Non, ce n’est pas ce qu’ils disent et ce n’est pas ce qui est expliqué dans tes liens. Ce qu’ils disent c’est qu’un langage dynamique implémenté par-dessus un bytecode optimisé pour le système de types de Java est inefficace et je suis totalement d’accord. Et tous leurs arguments contre un bytecode spécialisé du type de celui de Java, et notamment des restrictions intrinsèques, sont parfaitement valables.
  
  
  
  Mais ils ne s’appliquent pas à quelque chose de vraiment générique, beaucoup plus proche d’un langage assembleur neutre, comme l’est pNaCl ou asm.js. A ce niveau les inconvénients disparaissent presque totalement (la différence de perfs est au pire microscopique et le plus souvent nulle) alors que l’avantage de pouvoir choisir son langage est extrêmement important.
  
  
  
  Foutons Dart au feu parce que, non, ce ne sera pas gratuit, ce sera un boulet de plus dans le jardin des hordes de standards du web que doivent supporter ces titans que sont les navigateurs. Virons 90% de tout ça, virons JS, virons dart, virons html, etc (bon, pas tout de suite). Faisons du navigateur un OS aussi neutre et léger que possible. Le reste, des langages aux bibliothèques, doit être du ressort des tierce-parties.
  
  
  
  
  
  
  
  Presteus a écrit :
  
  
  
  Une techno massivement utilisée est une bonne techno que tu le veuilles ou non " />
  
  
  
  
  
  Cobol est donc le meilleur des langages ?
  
  
  
  
  
  Le Web, c’est nous, on en fait ce que l’on veut, c’est pas parce qu’aujourd’hui tu peux faire plus que tu dois impérativement le faire.
  
  
  
  Personnellement je t’assure que je n’ai aucune influence sur les standards. Et dans le web tout est codifié par des standards écrits par des acteurs aux itnérêts particuliers.

Le 26/03/2014 à 16h 54

tanguy_k a écrit :



Si on veut vraiment nettoyer le cœur de JavaScript, il faut malheureusement créer un nouveau langage => Dart





On s’en fiche de Dart. La réponse à Javascript ce n’est pas d’imposer un langage de plus. C’est de redonner la liberté du choix du langage.

Le 26/03/2014 à 13h 29

EMegamanu a écrit :



Le soucis avec le JavaScript c’est qu’il s’agit d’un langage soit interprété, soit compilé à l’exécution. Du coup parler de typage statique/dynamique me parait alambiqué (en mode mauvaise foi " />)





Il n’y a absolument rien d’alambiqué, le typage est fait dynamiquement à l’exécution et si éventuellement ce type a déjà été rencontré alors la VM peut utiliser une version pré-compilée de la fonction pour ces types précis d’arguments.





Edit : Du coup, dynamique/statique je laisse ça de côté vu que je ne saurai le définir, mais dans le cas de JavaScript c’est du Implicite/Faible. A comparer au C Explicite/Faible et au C++ Explicite/Fort.



Un typage est dynamique si certains types ne peuvent être déterminés qu’à l’exécution.



C’est le cas en javascript parce que tu peux à tout moment ajouter de nouveaux membres via par exemple myObject[myString] = ‘abc’. Puisque la valeur (et même parfois le type) de myString ne peut pas être connue à l’avance, il est impossible de connaître le type de myObject après ça. Le même problème se pose avec un tableau contenant plusieurs types selon les indices, puisque ces indices ne peuvent pas être connus à l’avance.



Bien sûr, en pratique, un compilateur peut inférer le type de certaines variables à l’avance. Sauf que d’une part l’incertitude tend à se propager rapidement (et javascript rend le boulot malaisé) et d’autre part la complexité de ces algorithmes est en O(n^3) même si c’est souvent un simple O(n^x avec x < 2) qui reste quand même très coûteux pour du JIT. Je t’invite à chercher “inclusion based pointer analysis” si le sujet t’intéresse.





Mais les deux notions statique/dynamique et fort/faible ne sont pas incompatibles :

WikipediaEn revanche la notion de typage fort/faible est, elle, subjective et ne devrait pas être utillisée. Sans doute voulais-tu dire que les comparaisons standard et quelques autres opérations en javascript sont laxistes. Ça, oui, c’est acceptable.





mais dans le cas de JavaScript c’est du Implicite/Faible. A comparer au C Explicite/Faible et au C++ Explicite/Fort.



Implicite, oui, c’est correct. Note cependant qu’on peut avoir un typage implicite et statique, c’est le cas par exemple des systèmes Hindley-Miller que l’on rencontre dans certains langages (F# par exemple).









Ujoux a écrit :



Et dire qu’il y a encore 5 ans le JS était encore très mal vu…





Mais le JS est toujours mal vu, même s’il a été nettoyé et amélioré. Si JS a du succès c’est parce que nous n’avons pas le choix.

Le 27/03/2014 à 21h 52

ceric35 a écrit :



sha256 porte sur le calcul complexe pour la constitution de la blockchain. Il pourrait être “cassé”, ça n’aurait pas une grosse conséquence sur le bitcoin qui n’aurait qu’à choisir un nouvel algo de hachage pour que les mineurs puissent s’amuser à nouveau. La sécurité porte sur ECDSA





Et ECDSA requiert l’utilisation d’un algorithme de hachage. Et devine qui on utilise en général ? SHA.





qui a été démontré sûr en 2001



Tiens, voici une liste d’algorithmes démontrés sûrs.

" />



S’il était possible de démontrer qu’un algorithme est sûr, tu ne crois pas que les choses seraient beaucoup plus simples ? Cette phrase ne veut rien dire. Tu peux prouver certaines propriétés qui, réunies, offrent des garanties sur certains aspects de la sécurité. Rien de plus. ne te laisse pas berner par ceux qui prétendent que les divines mathématiques certifient que tu peux claquer ton fric dans leur système.

Le 27/03/2014 à 19h 21

fft a écrit :



Il y a effectivement une date de “péremption” recommandée régulièrement par la NSA.





Et historiquement les algorithmes ont tous cédé bien avant leurs dates de péremption.





Maintenant affirmer que tous les algos de chiffrement ont fini par céder est un peu hatif, voir beaucoup, il n’existe plus de concours de factorisation justement parce la maturité de ces algorithmes est suffisante pour qu’il ne soit plus nécessaire de tenter de les craquer avec les moyens actuels, c’est tout simplement impossible.



Et dans les années 80 on était également sûr de la robustesse des algorithmes en place. Et aujourd’hui plus personne ne les utilise. La plupart des algos utilisés dans ces crypto-monnaies ont moins de quinze ans, certains moins de cinq ans et sont peu étudiés.



Et même si ton algo en lui-même est bon, il y a toujours des faiblesses exploitables, depuis les singularités des motifs chiffrés jusqu’aux méthodes comme les bag-of-gaussians récemment présentées (permettant de déterminer que deux messages originaux étaient proches d’après le hash final), etc. A chaque attaque de ce genre ta clé perd quelques dizaines de bits d’efficacité.



Et puis au vu du noyautage du milieu de la cryptographie par la NSA est-on seulement sûr que SHA256 a été promu pour ses réelles qualités ou plutôt parce que certains ont trouvé une faille qui les placent dans une position avantageuse ? Et je ne parle même pas du calcul quantique alors que personne ne sait vraiment où en est la NSA et ce qu’elle fait (même si, en 2014, ce n’est probablement pas un souci - en 2014).



Enfin ai-je besoin de rappeler que le grand passe-temps de la NSA ces dernières années a été de saborder les mises en œuvre (implementations) et de récupérer les clés avant qu’elles ne soient utilisées ?





Essayer de craquer un porte-monnaie de bitcoin à ce niveau de sécurité, même en mobilisant la totalité des ordinateurs de la planète pendant des décennies, n’y suffirait pas, et nous parlons de craquer le mot de passe d’ UN SEUL porte-monnaie.



Méthode Coué.





Et pourtant on utilise tous des cartes bancaires avec des codes à 4 chiffres… ;-)



La sécurité du système bancaire ne repose pas sur la cryptographie mais sur la constitution d’un système de partenaires de confiance, de surveillance et diverses précautions de nature humaine. Ainsi les seules victimes des détournements de cartes de crédit sont les mules. Pas les banques ni les personnes volées parce ces acteurs retrouvent rapidement leurs sommes du fait de l’organisation du système bancaire.

Le 27/03/2014 à 17h 33

Citan666 a écrit :



Tant que j’y suis, pour les connaisseurs, quelques questions pour ceux qui auront le temps…









matroska a écrit :



Si par ailleurs t’avais un conseil pour me lancer dedans, genre un conseil de bonne plateforme !





Pour ma part quelques petite précisions :



a) Si votre but est l’anonymat, comprenez que toutes les transactions sont publiques. Vous n’être protégés que par un pseudonyme dérivé de votre porte-monnaie. Or celui auquel vous achèterez vos bitcoins connaîtra votre véritable identitié (via votre CB), ainsi que toutes les parties auxquelles il la transmettra (autorités nationales, autorités américaines dans certains cas, partenaires commerciaux, etc). Tous ceux-là pourront donc voir vos transactions passées, présentes et futures tant que vous conserverez ce porte-monnaie. Et tout transfert vers un autre porte-monnaie sera lui aussi public.



Si vous voulez l’anonymat, minez. Oui, ça prend des jours pour miner des sommes ridicules. Puis faîtes très attention aux transactions que vous ferez et la façon dont elles pourraient vous relier à votre porte-monnaie. Comprenez qu’en reniflant le trafic réseau (ce que font la NSA et peut-être la DGSE) il est facile d’identifier une transaction bitcoin et de rattacher un porte-monnaie à votre identité, et donc de connaître toutes vos transactions passées et futures.





b) Si votre but est l’investissement, comprenez que les plateformes existantes ne sont guère fiables (l’actualité l’a montré récemment) et que garder ses bitcoins soi-même est aussi fiable que l’est la sécurité de son PC. Comprenez que les virus ciblant les crypto-porte-monnaies se multiplient rapidement et peuvent parfois détecter des fichiers effacés et que, oui, ils peuvent infiltrer votre PC sans sourciller. Comprenez que la meilleure solution est encore d’imprimer le(s) porte-monnaie(s) (paper wallet), de l’effacer (l’argent est dans le réseau, publiquement visible, votre porte-monnaie n’est qu’un “certificat de propriété”) et de mettre le papier au coffre.



Comprenez aussi que les algorithmes de chiffrement ont tous fini par céder (malgré les soi-disantes preuves mathématiques qui en fait ne prouvent que quelques propositions précises et limitées) et que ces crypto-monnaies s’appuient sur des algos qui ont environ une décennie seulement, parfois moins, alors que le chiffrement est très largement étudié depuis beaucoup plus longtemps que ça. Et que certains de ces algos avaient été peu étudiés jusqu’à présent.



Enfin soyez conscients que l’univers réglementaire est des plus hasardeux et changeant, que plusieurs pays pourraient sérieusement freiner le bitcoin à l’avenir, qu’en France vous avez une obligation légale de déclaration d’un compte à l’étranger (sauf sous un certain montant je crois), et que les USA viennent par exemple de soumettre à la TVA toutes les transactions en considérant qu’il s’agit d’un bien et non d’une monnaie.

• Quitte à investir dans un truc un peu flou tel que les crypto-monnaies, Bitcoin est-il le meilleur choix ?
  
  
  
  Ce n’est pas la plus robuste ni la meilleure sur le plan technique mais c’est celle qui a la plus forte communauté.

Le 27/03/2014 à 15h 23

FREDOM1989 a écrit :



Acheter un téléphone Nokia basique à 40€ me parait plus logique pour qui n’est pas sensible à la nostalgie.





Ce n’est pas du tout une question de nostalgie : j’ai détesté tous mes autres téléphones classiques, franchement peu pratiques. Les smartphones sont beaucoup plus agréables. Mais à choisir je préfèrerais un truc beaucoup plus simple et fonctionnel et c’est le cas du 3310.

Le 27/03/2014 à 15h 15

90 balles pour un 3310 d’occasion ?! Y a foutage de tronche quand même.



Dommage car je préfèrerais cent fois un vieux 3310 à nos smartphones actuels : batterie, longévité, fiabilité, sécurité. Pour moi ce sont les qualités essentielles

Le 27/03/2014 à 13h 43

Selon la théorie du « Clickbait », assez justement illustrée par Xkcd



Tiens, on dirait Wired.

Le 26/03/2014 à 22h 16

jrbleboss a écrit :



Cette barrière n’existe plus lorsque le GC tourne en parallèle sans stopper les threads sur lequel il travaille. Si, si, c’est possible " />





Bien sûr que c’est possible mais tu dois réintroduire une forme de synchronisation (des CAS atomiques en général) et alourdir tes assignations. Malheureusement la poudre de perlimpinpin qui permettrait de faire de la concurrence gratuitement est en rupture de stock.

Le 26/03/2014 à 15h 02

fraoch a écrit :



baah MS va pas dire le contraire…. Mais je dis pas que c’est impossible.

Je n’ai pas encore vu les articles que tu donnes, donc je m’abstiens de dire quoi que ce soit. Mais je vais aller jeter un coup d’oeil de suite





Tu ne trouveras pas de réponse dans les sources fournies mais je peux t’éclairer, sachant que je trouve pour ma part l’affirmation de MS très exagérée même si dans certaines situations ils feront effectivement mieux que le C++.





Le premier principe c’est que l’essentiel des surcoûts imputables au code managé peuvent être virés :

* Les vérifications des bornes des tableaux peuvent bien souvent être éliminées (c’est déjà le cas dans les situations les plus simples). Soit parce qu’on peut déterminer qu’elles ne seront jamais violées, soit en effectuant un seul test au début.



* La plupart des objet une vie courte se limitant à la méthode et pourraient être rendues locales, voire allouées sur la pile, en zappant le GC.





Le second principe c’est que le C++ a ses propres limites :

* Le comptage de références est réalisé au moyen d’opérations atomiques à chaque assignation qui sont coûteuses en temps CPU. A contrario un GC qui met en pause le thread n’a rien à faire lors des assignations et peut éviter tout mécanisme de synchronisation, ce qui lui permet souvent de consommer moins de CPU. Plus généralement le C++ moderne tel qu’il est utilisé en pratique est riche de motifs qui le rendent finalement aussi lourd qu’un langage managé. Le C++ moderne doit beaucoup à la qualité de ses compilateurs pour éviter ces surcoûts, or ces possibilités d’optimisation sont identiques à celles des langages managés.



* Du fait de la gestion libérale des pointeurs en C++ il faut toujours considérer qu’un emplacement mémoire peut être modifié à n’importe quel moment, ce qui empêche par exemple de conserver une valeur dans les registres. D’où le mot clé “restrict” et certaines options de compilation. Or en C# il est beaucoup plus facile pour le compilateur de déterminer qu’un emplacement mémoire n’est référencé que par telle variable locale.



* Le fait que le C++ ne compacte pas les données en mémoire ralentit l’exécution des programmes sur le long terme du fait de la fragmentation, surtout sur serveurs.

Le 26/03/2014 à 08h 54

Pour illustrer plus concrètement ses travaux sur la concurrence, quand des threads se mettent en attente passive d’un événement de synchronisation (libération d’un verrou, points de rendez-vous, wait handles, etc), c’est presque toujours avec un algo conçu par ce monsieur. Que ce soit sous un smartphone Android, un PC Windows ou le moniteur de bord d’un avion.

Le 26/03/2014 à 16h 50

Sérieusement ? Ils ont été rachetés ? Et ben… " />

Pour ma part, un produit facebook c’est niet.

Le 26/03/2014 à 15h 39

Alucard63 a écrit :



Sans tricher sur le CV non plus et je parle de CDI (perso je n’ai jamais fait de CDD, et j’en connais pas mal d’autres)." />





Oui, il y a plein de gens qui n’ont jamais été au chômage et ne sont pas concernés par ces problèmes.



Il y en a beaucoup moins qui ne le connaîtront jamais. Petite pensée à tous ces chirurgiens, métier a priori indispensable mais qui seront au chômage dans vingt ans, remplacés par des robots pour la plupart. Ou à tous ces traders bientôt remplacés pour la plupart. Ou…

Le 26/03/2014 à 15h 34

al_bebert a écrit :



ya pas que les employés qui vont partir !



si c’est NC qui rachette, je résilie l’abo adsl sfr…



et je pense pas que je soit le seul à faire la même chose !





Pour quelle raison NC a t-il si mauvaise réputation ? Leur faible upload ? A part ça je ne connais rien de leur boîte.



Pour ma part j’avoue qu’entre être fliqué à mort chez Orange et ne pas pouvoir regarder une vidéo Youtube chez Free, je ne suis pas pressé de partir. A la rigueur je me renseignerais sur OVH ou Bouygues.

Le 25/03/2014 à 10h 54

le podoclaste a écrit :



Vous allez voir, dans 10 ans, Sarko et Copé seront sur la même ligne que Taubira " />





Non, dans trois ans Sarkozy est réélu et généralise le vote électronique et étend sa surface aux maisons de retraite. Après ça la mafia des Hauts-de-Seine ne quittera plus jamais le pouvoir.







WereWindle a écrit :



très intéressant et la solution qu’il propose est très élégante (même si elle ne verra jamais le jour, hélas) " />





Interdire les écoutes des avocats ? Pitié, le problème est bien au-delà de ça.

Le 25/03/2014 à 10h 43

trash54 a écrit :



même en prenant juste 1cts par vidéo vu " /> ouai doit être florissante l’affaire





5 milliards de vidéos par mois ça ne fait que cinq à vingt millions de recettes par mois (recettes, pas bénéfices - il y a 55k affiliés à gérer derrière ainsi que les clients, et peut-être un peu de coprod), dont l’essentiel va aux producteurs de ces contenus. Une bonne PME mais rien d’extraordinaire.



Ce que rachète Disney c’est l’audience, pas le chiffre.







John Shaft a écrit :



me donne envie de le baffer dès que je le vois " />





Je ne connaissais pas, ça a l’air particulièrement stupide et criard. Exaspérant au possible, comme la quasi-totalité des vidéos parlant de jeux vidéos.



Avec Youtube, TF1 passerait presque pour une chaîne culturelle.

Le 25/03/2014 à 08h 21

Si seulement il y avait des maires pour les Français de l’étranger… Avec le vote électronique le parti pirate aurait pu atteindre les 100% de voix.















Quoique, non, la NSA les aurait sans doute devancés.

Le 24/03/2014 à 08h 41

Razorgore a écrit :



@HenryBasmati : +1

Il dit clairement que EA est une entreprise de destruction de la créativité et de l’originalité, en rangeant des développeurs/artistes dans des petits bureaux proprets avec le département RH qui va bien pour gérer tout ça.





Tout à fait, c’est pour ça que lorsque j’embauche un graphiste je le paie trois francs six sous au lance-pierres, pour m’assurer que son côté bohème dominera et l’empêchera de passer ses soirées à s’enfiler des rails de coke dans un bar à filles faciles.

Le 23/03/2014 à 20h 55

lsPCI a écrit :



, ce qui pouvait laisser entendre que lui, au moins, malgré ses casseroles, n’aurait pas laisser passer ça.





Tu as l’esprit sacrément tordu. Laisse-donc tomber la chasse aux électeurs de droite qui te fait voir des sarkozistes à chaque carrefour, ça n’a plus de sens.