Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Le système Midori de Microsoft se rapproche de sa phase commerciale

Toujours sans savoir sous quelle forme il pourrait bien apparaître

Le système Midori de Microsoft se rapproche de sa phase commerciale

Le 06 janvier 2014 à 17h18

Midori est un projet de système d’exploitation au sein de Microsoft sans aucun rapport avec Windows. Alors que l’actualité s’était faite discrète à son égard depuis un certain temps, plusieurs éléments récents laissent penser que son développement a nettement progressé et qu’il s’avance doucement vers une exploitation commerciale.

visual studio c#

L'émergence après le calme 

Midori est un nom de code abordé de nombreuses fois dans nos colonnes. Il prend sa source dans le projet Singularity d’un système d’exploitation basé sur un micronoyau et presque entièrement écrit en code managé. Durant des années, Singularity et Midori ont été abordés essentiellement comme des projets de recherche puis en phase d’incubation, cette dernière soulignant que ses concepteurs réfléchissaient déjà à une mise en pratique du travail accompli.

 

Il faut bien comprendre que si Midori devait sortir demain, il serait un produit très différent du Windows que nous connaissons. Il ne s’agit pas d’une question d’ergonomie et d’interface mais bien de base technique, sans aucun rapport avec les technologies actuelles ou encore le NT. On ne sait pas comment Microsoft pourrait commercialiser un tel produit et dans quelles directions, mais une arrivée sur les ordinateurs de tout un chacun ne semble pas en tête de liste.

Le projet a rejoint la division systèmes d'exploitation de Terry Myerson 

Selon un article de Mary Jo Foley de ZDnet, Midori se rapproche cependant un peu plus d’un produit réel. Selon deux sources, c’est tout le projet qui est maintenant géré au sein de la nouvelle division systèmes d’exploitation de Microsoft, dirigée par Terry Myerson. Le même Myerson qui donnait ces derniers mois quelques bribes d’informations sur la convergence des systèmes chez le géant.

 

Cette information est complétée par une seconde sous la forme d’un billet de blog paru le 27 décembre et rédigé par Joe Duffy, l’un des développeurs de Midori. Il y explique un aspect important du développement du système sans jamais vraiment le nommer car il aborde le langage utilisé pour ce faire : M#. Il s’agit en fait d’un groupe d’extensions pour le C# pour composer un langage système hérité de l’ancien projet Sing#.

 

Ce langage de programmation système pourrait d’ailleurs devenir open source, ce qui laisse penser qu’il jouerait un grand rôle dans le futur de la firme. Ce projet est par ailleurs lié à Roslyn, un nouveau compilateur dont nous avons parlé le mois dernier, puisque l’équipe doit l’y implémenter. Mais les questions que l’on peut se poser devant les explications de Joe Duffy concernant à la fois l’utilité de M# et la manière dont tous ces projets pourraient s’intégrer dans l’informatique d’aujourd’hui.

De l'utilité et de l'intégration dans le paysage actuel 

L’utilité de M# a justement été débattue dans les commentaires qui ont suivi. La décision de se baser sur C# est initialement expliquée dans le billet de Duffy : la réduction de la complexité, le nombre de développeurs sachant aujourd’hui l’utiliser et la nécessité de certaines notions telles que la sûreté de typage. Mais pourquoi ne pas utiliser des langages existants tels que D, Rust ou Go ? Selon Aleks Bromfield, qui a passé les quatre dernières années à développer ce langage mais qui travaille maintenant chez Google, M# reprend des éléments des uns et des autres : la sûreté et les performances de Rust, la simplicité de Go ainsi que la familiarité du D. Il explique par ailleurs que le M# peut être utilisé pour n’importe quelle application et qu’il devrait être le langage le plus bas niveau dont les développeurs pourraient avoir besoin.

 

Mais comment Midori et M# (la lettre M n’est certainement pas due au hasard) pourraient-ils s’intégrer aujourd’hui dans l’écosystème logiciel actuel puisque les bases techniques sont totalement différentes ? Il y a plusieurs aspects à la question, dont le premier concerne justement les applications existantes. Tout dépend en effet des API dont on parle : il est clair que les logiciels Win32 ne pourront pas fonctionner sur une telle nouvelle base à moins que Microsoft ne mette en place un mécanisme supplémentaire (Drawbridge ?), mais la situation est très différente dès que l’on aborde WinRT.

Des annonces sans doute à prévoir cette année 

Cet environnement, apparu avec Windows 8 et constituant la base des nouvelles applications disponibles dans le Windows Store, apparaît comme relativement autonome. Lorsque nous l’avions abordé dans notre dossier Windows 8, nous avions souligné que WinRT reposait bien sur Win32 mais avec un nombre très limité d’attaches. Nous avions également suggéré qu’il était de fait possible d’imaginer que l’on pouvait « débrancher » WinRT pour le réinstaller sur une autre base. Une notion qui semble confirmée à demi-mots par Aleks Bromfield dans un tweet.

 

Dans tous les cas, l’élément important concerne bien l’inclusion du projet Midori au sein de la division de Terry Myerson. L’une des sources de Foley lui a indiqué à ce sujet que l’équipe devait décider quels éléments de Midori pouvaient être intégrés dans la stratégie en cours. L'année 2014 pourrait finalement voir plusieurs annonces concernant le système ainsi que le M#.

Commentaires (220)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Cela dit j’argumente avec toi mais je suis d’accord sur le fond : un tel projet n’est pas gratuit en termes de performances. Même s’il restera à mon avis acceptable et présentera aussi des gains.

votre avatar



…troll…











Vincent_H a écrit :



C’est quand même un domaine que tu connais toi-même particulièrement bien <img data-src=" />





Ça ne m’amuse plus, j’ai passé l’âge. Je préfère une discussion bien argumenté, avec des liens sur l’effet tunnel, le fait que l’UAC ne sert pas à grand’chose, des questions pour que le neurone n’oublie pas que tous ces langages, compilés en langage machine ou interprétés, sont fait pour être exécuté par des CPU qui n’exécutent QUE du langage machine (le CPU Java a fait long feu) et que le problème des communications inter process ne connait que 2 solutions : le monolithique et sa soit-disant perte de sécurité, et le micro-noyau et son corrolaire, la perte de performances.


votre avatar







CaptainDangeax a écrit :



le neurone n’oublie pas que tous ces langages, compilés en langage machine ou interprétés, sont fait pour être exécuté par des CPU qui n’exécutent QUE du langage machine (le CPU Java a fait long feu) …





Juste pour être bien clair, il n’a jamais été dit que le langage en question est interprété, managé ne signifie pas forcément interprété (typiquement les pointeur intelligents de C++ sont du managing mais c’est compilé).





CaptainDangeax a écrit :



… et que le problème des communications inter process ne connait que 2 solutions : le monolithique et sa soit-disant perte de sécurité, et le micro-noyau et son corrolaire, la perte de performances.





Ce n’est pas parce qu’on ne sait pas encore faire qu’on a des preuves que c’est impossible, ni qu’il n’existe pas de meilleure solution.


votre avatar







Ksass`Peuk a écrit :



Juste pour être bien clair, il n’a jamais été dit que le langage en question est interprété, managé ne signifie pas forcément interprété (typiquement les pointeur intelligents de C++ sont du managing mais c’est compilé).



Ce n’est pas parce qu’on ne sait pas encore faire qu’on a des preuves que c’est impossible, ni qu’il n’existe pas de meilleure solution.







Citation de Wikipedia :



Dans la terminologie de Microsoft, le managed code est un code source qui s’exécute sous le contrôle de la machine virtuelle CLR, ou d’une autre machine virtuelle. Ce terme est employé par opposition au unmanaged code (code non géré), qui est exécuté directement par le processeur.

Le « managed code » permet d’améliorer la sûreté de fonctionnement d’un programme informatique, et de simplifier le travail du programmeur. Ce terme fait partie de la terminologie Microsoft, mais le même concept existe pour le langage Java.



C’est clair, le code managé s’exécute dans une machine virtuelle, qui va forcément consommer des cycles CPU, qui va forcément faire baisser les perfs. Alors je dis OK pour une application (j’écris moi-même des scripts en python, parce que le temps que je perds à l’exécution par rapport au même prog en C est largement compensé par le temps que je gagne en développant en python plutôt qu’en C) mais jamais au grand jamais il ne me viendrait à l’idée d’écrire en noyau en code managé.


votre avatar







Ksass`Peuk a écrit :



Ce n’est pas parce qu’on ne sait pas encore faire qu’on a des preuves que c’est impossible, ni qu’il n’existe pas de meilleure solution.





Je n’ai pas écrit le mot “impossible” mais en même temps, la comm de MS ne dit pas non plus “nous avons trouvé la solution miraculeuse qui résout le problème”. Non, MS essaie de nous vendre un nouveau langage (M#) plus ou moins obligatoire pour leur nouvelle architecture de micro-noyau (Midori), et je peux te parler pendant des heures de développeurs que j’ai rencontré qui se trouvent bloqués dans l’évolution de leur produit parce qu’au départ ils ont fait le mauvais choix du langage. Leur M# va ENCORE être mono plateforme comme le dotNet avant lui, dotNet tellement bien que MS l’a massivement utilisé pour le développement de son produit phare, j’ai nommé Office, oh, wait…

Quant à développer le noyau en code managé, je pourrais éventuellement être <img data-src=" /> si le spectacle ne m’était gâché par une armée de fanboys.


votre avatar







CaptainDangeax a écrit :



le problème des communications inter process ne connait que 2 solutions : le monolithique et sa soit-disant perte de sécurité, et le micro-noyau et son corrolaire, la perte de performances.





Ou la troisième sur laquelle tu refuses de te documenter.







CaptainDangeax a écrit :



dotNet tellement bien que MS l’a massivement utilisé pour le développement de son produit phare, j’ai nommé Office





S’ils n’ont pas jeté aux orties vingt années de boulot pour tout refaire sous dotnet c’est bien sûr parce que dotnet est mauvais.


votre avatar







HarmattanBlow a écrit :



Ou la troisième sur laquelle tu refuses de te documenter.





Et que tu as si bien expliqué tout le long de tes posts précédents. Si le nouveau système de MS était si bien, le service marketting et son kolossal Budget s’en serait emparé pour arroser la planète IT toute entière. Pour l’instant nous n’avons que des communications de recherche plutôt confuses.


votre avatar







CaptainDangeax a écrit :



Et que tu as si bien expliqué tout le long de tes posts précédents. Si le nouveau système de MS était si bien, le service marketting et son kolossal Budget s’en serait emparé pour arroser la planète IT toute entière. Pour l’instant nous n’avons que des communications de recherche plutôt confuses.





Ben oui parce qu’un OS ça se bricole et ça se commercialise entre 12h et 13h lors du repas. Encore que ça dépend si les sandwichs sont au thon ou au saumon, le second contient plus de DHA.


votre avatar







Sebdraluorg a écrit :



T’as pas l’impression de confondre langage managé (c# par exemple) et langage interpreté (js par exemple) ?





Je dis juste que l’un implique l’autre (managé implique interprété) par opposition au compilé, qui donne du langage machine directement exécutable par le CPU. Si ce langage machine s’exécute sur une machine virtuelle, il y a une couche logicielle qui interprète le fonctionnement jusqu’au CPU physique.





Loi de moore ? Faudrait pas oublier qu’elle n’a rien d’une loi, et qu’elle n’est absolument pas liée au silicium…



C’est parce que les américains n’ont pas de mot pour traduire “conjecture” comme dans “conjecture de fermat”



Tu passes des heures pour obtenir des optimisations de moins d’un % ? <img data-src=" />

8% c’est moins d’une génération de CPU, donc 3 fois rien !



C’est pourtant la différence entre une mise en orbite réussie et un crash à la surface d’une planète lointaine.



Si tu as un SandyBridge, mon IvyBridge me permet déjà de gommer la différence !

Dans un monde ou on fait parler des process en xml y a vraiment pas de quoi ronchonner !



Moore, ce n’est pas encore mort, ça plafonne juste un peu. Autrement, il me semble que Midori c’est un noyau. Pour moi un noyau gère des E/S, des allocations mémoire, des IPC, et pas des fichiers XML pour lesquels il existe de très bons parsers Python, un langage interprété.


votre avatar







HarmattanBlow a écrit :



Ben oui parce qu’un OS ça se bricole et ça se commercialise entre 12h et 13h lors du repas. Encore que ça dépend si les sandwichs sont au thon ou au saumon, le second contient plus de DHA.





Écoute, je dis juste que je suis sceptique. Mais compte sur moi pour le tester dès que la beta sera dispo, comme je l’ai fait pour Win7 (adopté avec Office2007 et Skyrim), win8 et 8.1 (rejetés), LinuxMint13 Cinnamon (adopté) et ChromeOS (s’il veut bien démarrer). Et s’il vaut le coup par rapport à mon Win7 qui me sert à Skyrim et Office2007, je l’adopterai. Et s’il vaut le coup par rapport à mon LinuxMint qui tourne sans reboot, sans virus avec la messagerie, mysql et une palanquée de scripts python, eh bien je porterai mes BDD sur SQL server et mes scripts python en M#. Pour l’instant, je suis juste sceptique.


votre avatar







CaptainDangeax a écrit :



Citation de Wikipedia :



mais jamais au grand jamais il ne me viendrait à l’idée d’écrire en noyau en code managé.







Ca tombe bien, personne ne t’a demandé de le faire <img data-src=" />


votre avatar







CaptainDangeax a écrit :



Quant à développer le noyau en code managé.





C’est un peu de l’esbroufe intellectuelle <img data-src=" />

Le micro-noyau sera les 2% de C/ C++/ assembleur du projet.



Juste pour lancer la machine virtuelle (bon c’est un truc meilleur) qui supprime:




  1. la segmentation et la pagination mémoire

  2. les niveaux de privilège du CPU. Tout sera dans des SIPs

  3. Le code malfaisant en C++ et autre. Il y a un truc de prévu quand même



    Et effectivement en plus de ne pas savoir où le programme va écrire, on ne va pas savoir où il sera exécuté: sur un core physique, core virtuel, GPU …



    <img data-src=" /> Je me rappelle encore du GDI32 qui sur une machine avait l’accélération mémoire et sur l’autre pas



    Tout cela me semble intéressant <img data-src=" />



    Mais:

  4. sur quelle machine pour le faire tourner? Lorsqu’on voit Android.

    C’est vrai on s’en fiche on attend les 1.5 ans de béta-test commercial pour avoir un produit mature <img data-src=" />



  5. La sécurité?

    Parce que si Microsoft se foire ce sont plus que de simples services ou logiciels à patcher. Cela va être fun <img data-src=" />



  6. Le développement dessus?

    Si c’est comme du Java Android cela promet <img data-src=" />

    Madame la machine virtuelle, il me faut un thread, je l’ai quand?

    Madame la machine virtuelle, il faut arrêter mon timer. Tu me dis quand c’est bon?

    Madame la machine virtuelle, je veux stocker des données. Est-ce que c’est bon? J’ai les accès? les droits? Oui Non?









    HarmattanBlow a écrit :



    Ben oui parce qu’un OS ça se bricole et ça se commercialise entre 12h et 13h lors du repas. Encore que ça dépend si les sandwichs sont au thon ou au saumon, le second contient plus de DHA.





    <img data-src=" /> <img data-src=" /> <img data-src=" />



    C# est sorti en 1999- 2000 (14 ans).

    Et depuis combien de temps qu’on parle des projets managés de Microsoft: Midori, Bartok, ….

    Et cela il faut attendre encore 2 ans facile.



    De toute façon depuis Vista, Microsoft avance à la vitesse d’un tortue sur le dos.

    Il faut attendre encore facile 1.5 an pour l’unification des Windows et la mort de XP et Win 32.

    Et seulement après, Microsoft pourra remplacer le noyau.


votre avatar







HarmattanBlow a écrit :



S’ils n’ont pas jeté aux orties vingt années de boulot pour tout refaire sous dotnet c’est bien sûr parce que dotnet est mauvais.





Tu as raison. Ce n’est pas comme si entre la version 2003 et 2007 ils avaient complètement ré-écrit l’interface utilisateur avec bandeaux et toute la partie faisant le lien entre le stockage des documents en mémoire vive et les formats DOCX,XLSX, etc, etc. Tiens ils n’ont pas non plus recréé de nouvelles fonctionnalités comme l’intégration au CLOUD pour la version 2013 non plus.


votre avatar

“The idea is that M# should be the lowest-level language that you’ll ever need. It sits at the very bottom of the stack. But it’s also safe and productive enough to be appropriate for writing higher-level systems, like Web services,”





Vivement <img data-src=" />

votre avatar

J’en avais parlé dans de précédents commentaires avec sr17 et harmattanblow.

Le M# est un langage derivé de c# qui est type et memory safe mais qui obtient les mêmes performances que le C++.



Joe duffy l’explique clairement. Les débats sur le sujet comparaient à l’implémentation actuelle du .NET. Mais ca ne marche pas du tout pareil. Joe duffy expose plusieurs points:



1)ce n’est pas de la compilation JIT mais un compilateur ahead of time. le codé est compilé directement en natif.



2)L’autre point débattu à l’époque c’était les mauvaises performances du garbage collector actuel. Visiblement ils ont travaillé dessus.



3)Le point majeur débattu: Avec des langages manages il y a une vérification des dépassement de tableaux par défaut pour éviter les buffer overflow. J’expliquais que ce serait largement compensé par de fortes optimisations avec le compilateur. C’est confirmé ici:





It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling.



Se renseigner aussi sur le tree shaking qui est une des optimisations importantes. Voir ici



De toute façon quand on voit le nombre de failles dans les navigateurs web par exemple ça prouve bien qu’on peut pas compter sur les développeurs pour éviter de pondre des failles.





  1. un autre aspect qui n’a pas encore été abordé par joe duffy pour le moment ,ce langage a été conçu pour la programmation many core.



    Au final M# devrait bien obtenir les performances nécessaires pour la programmation système.



    Je finirai sur le fait que joe duffy l’a annoncé clairement qu’il est arrivé au but. C’est fort probable que des milliers de développeurs vérifieront ses propos.

votre avatar







hadoken a écrit :



“The idea is that M# should be the lowest-level language that you’ll ever need. It sits at the very bottom of the stack. But it’s also safe and productive enough to be appropriate for writing higher-level systems, like Web services,”





Vivement <img data-src=" />





Il a les avantages des langages manages et les performances des langages natifs <img data-src=" />


votre avatar







charon.G a écrit :



Il a les avantages des langages manages et les performances des langages natifs <img data-src=" />







<img data-src=" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.

M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force surtout quand ça prétend être en mesure de faire du système.


votre avatar

“Lucky Williams : Lucky Williams, Expert PAKRAM sur MOS 32 H-track en bibande PADIRAK.

Topper : Padirak ?

Lucky Williams : En circuit fermé Lieutenant.

Topper : Oui bien sûr.”

<img data-src=" />

votre avatar







charon.G a écrit :



Il a les avantages des langages manages et les performances des langages natifs <img data-src=" />







Je répondrais avant de mettre un <img data-src=" /> attendons que :





charon. a écrit :



Je finirai sur le fait que joe duffy l’a annoncé clairement qu’il est arrivé au but. C’est fort probable que des milliers de développeurs vérifieront ses propos.





votre avatar







francois-battail a écrit :



<img data-src=" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.

M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force surtout quand ça prétend être en mesure de faire du système.





M comme Midori c’est un nom de code.

J’ai argumenté au dessus ce qui n’est pas ton cas . T’es surement plus intelligent que joe duffy.. Je ne pense pas que joe duffy aurait annoncé une telle chose si il n’y est pas effectivement arrivé. Comme expliqué au dessus Tout le monde vérifiera ses dires. il risque sa réputation de développeur.


votre avatar







metaphore54 a écrit :



Je répondrais avant de mettre un <img data-src=" /> attendons que :





Tu crois qu’il va salir sa réputation en annonçant des trucs faux. De toute façon même quand ça sortira certains resteront toujours dans le deni….


votre avatar







francois-battail a écrit :



<img data-src=" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.





Le gugus ne dit pas qu’il est utilisé pour le noyau, il dit que c’est le langage de référence pour l’écosystème autour de ce noyau.





M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force



Le langage parfait n’existe évidemment pas puisque sa définition revient à faire un aggrégat de compromis.

Après, ça n’empêche pas qu’il pourrait proposer une approche relativement en phase avec les évolutions récentes de l’état de l’art de ces dernières années.



Donc le plus sage serait encore d’attendre de voir ce qu’il a à proposer avant de jeter le bébé avec l’eau du bain. Perso je vois deux axes: un langage pensé d’emblée pour le multi-core (là où les langages actuels sont plutôt pensés sur un paradigme du multi-thread) et un langage managé pensé d’emblée avec très peu de compromis sur les performances, là où l’existant est souvent orienté ‘tout’ (pas managé du tout) ou ‘rien’ (très peu de compromiss en faveur des perfs).


votre avatar







francois-battail a écrit :



<img data-src=" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.

M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force surtout quand ça prétend être en mesure de faire du système.





Avant de critiquer il faut voir hein… De plus le managé peut être extrêmement puissant si la phase de compilation/optimisation est bien gérée. Sans compter que pour le coup, là c’est vraiment différent (no JIT). Et pour le GC, certes c’est quelques fois un vrai bottleneck, mais ils annoncent de gros progrès dessus.



Et mieux vaut sacrifier 2% de perfs et bénéficier de type et memory safety. Je dirais qu’au moins 80% des BSOD et un paquet de failles de sécurité viennent de leur absence.


votre avatar







brazomyna a écrit :



Le gugus ne dit pas qu’il est utilisé pour le noyau, il dit que c’est le langage de référence pour l’écosystème autour de ce noyau.

‘





Si Midori est écrit avec M# d’ou le nom. Comme dit le titre c’est un langage système. il fait pour écrire des noyaux de systèmes,des drivers ou des serveurs.


votre avatar

<img data-src=" />

M# n’est pas un langage associé à Microsoft. M# n’est jamais mentionné dans le blog de Duffy !!

(uniquement dans les commentaires de mecs qui ont fait des associations de mots)

M# est développé par une société britannique et mis en œuvre pour la réalisation de sites weben.wikipedia.org Wikipedia

votre avatar







hadoken a écrit :



Avant de critiquer il faut voir hein… De plus le managé peut être extrêmement puissant si la phase de compilation/optimisation est bien gérée. Sans compter que pour le coup, là c’est vraiment différent (no JIT). Et pour le GC, certes c’est quelques fois un vrai bottleneck, mais ils annoncent de gros progrès dessus.



Et mieux vaut sacrifier 2% de perfs et bénéficier de type et memory safety. Je dirais qu’au moins 80% des BSOD et un paquet de failles de sécurité viennent de leur absence.





Et je l’expliquais déjà à l’époque, joe duffy l’a confirmé, le compilateur effectue un maximum d’optimisations qui permettent de rattraper les pertes de perfs dues aux “bound checking”


votre avatar







charon.G a écrit :



Tu crois qu’il va salir sa réputation en annonçant des trucs faux. De toute façon même quand ça sortira certains resteront toujours dans le deni….







Je ne le connais pas, mais j’ai appris dans les annonces par les uns et les autres qu’il y a toujours un os dans le pâté, mais pourquoi je serais agréablement surpris.


votre avatar







charon.G a écrit :



Si Midori est écrit avec M# d’ou le nom. Comme dit le titre c’est un langage système. il fait pour écrire des noyaux de systèmes,des drivers ou des serveurs.





Le M# s’arrête forcément quelque part pour laisser la place à du code machine. La limite est encore floue.







charon.G a écrit :



Et je l’expliquais déjà à l’époque, joe duffy l’a confirmé, le compilateur effectue un maximum d’optimisations qui permettent de rattraper les pertes de perfs dues aux “bound checking”





Il n’y a pas que le “bound checking” qui définit les attributs d’un langage managé.







hadoken a écrit :



Et mieux vaut sacrifier 2% de perfs et bénéficier de type et memory safety. Je dirais qu’au moins 80% des BSOD et un paquet de failles de sécurité viennent de leur absence.





Je partage globalement cette vision des choses, car quelques pourcents de perfs, c’est quelques mois d’évolution de la puissance de traitement des puces. Un langage a une vision beaucoup plus long terme.



votre avatar







charon.G a écrit :



J’ai argumenté au dessus ce qui n’est pas ton cas . […]







C’est vrai. Mettre un garbage collector dans un système élimine toute application temps réel vu que ce n’est plus déterministe, ensuite un langage managé est absolument inutilisable pour du code système vu que nécessairement il faut du « code sale » pour travailler au niveau du hard. Ce « code sale » (natif) sera signé Microsoft et enlèvera toute possibilité à des développeurs tiers de développer des choses un peu tricky sans passer par un circuit de certification Microsoft.

Ça fait plus de 25 ans que je vois passer des trucs où on cherche à protéger le système du développeur, quand - comme moi - on a fait pas mal de système il est difficile de prendre ça au sérieux.


votre avatar







Arnard a écrit :



<img data-src=" />

M# n’est pas un langage associé à Microsoft. M# n’est jamais mentionné dans le blog de Duffy !!

(uniquement dans les commentaires de mecs qui ont fait des associations de mots)

M# est développé par une société britannique et mis en œuvre pour la réalisation de sites weben.wikipedia.org WikipediaCe langage n’a rien a voir avec M# qui est un projet de recherche interne a microsoft.

Le nom M# vient de cette offre d’emploi sur Midori:

careers.microsoft.com Microsoft. All development is in M#, a C#-like language for writing asynchronous and parallel operating system components with strong guarantees of correctness.



Dans les commentaires ou les tweets d’aleks j’ai oublié ça été confirmé que M# était le nom de code de ce langage.


votre avatar

Rien compris à l’article… Pas l’niveau… <img data-src=" />

votre avatar







brazomyna a écrit :



Le M# s’arrête forcément quelque part pour laisser la place à du code machine. La limite est encore floue.





Il n’y a pas que le “bound checking” qui définit les attributs d’un langage managé.





Je partage globalement cette vision des choses, car quelques pourcents de perfs, c’est quelques mois d’évolution de la puissance de traitement des puces. Un langage a une vision beaucoup plus long terme.





Midori est dérive du noyau Singularity. Le noyau est entièrement en code safe à part la HAL et le compilateur bartok intégré.

Mais il existait des projets a coté pour prouver le code natif sans bug avec boogie PL à base de preuves mathématiques.

http://www.blog.ma-config.com/index.php?post/2010/11/14/SafeOS%3A-un-OS-enti%C3%…

Le bound checking est généralement ce qui est repris le plus pour dire que les langages safes sont plus lents.


votre avatar







francois-battail a écrit :



C’est vrai. Mettre un garbage collector dans un système élimine toute application temps réel vu que ce n’est plus déterministe, ensuite un langage managé est absolument inutilisable pour du code système vu que nécessairement il faut du « code sale » pour travailler au niveau du hard. Ce « code sale » (natif) sera signé Microsoft et enlèvera toute possibilité à des développeurs tiers de développer des choses un peu tricky sans passer par un circuit de certification Microsoft.

Ça fait plus de 25 ans que je vois passer des trucs où on cherche à protéger le système du développeur, quand - comme moi - on a fait pas mal de système il est difficile de prendre ça au sérieux.





Pour le gc tu devrais lire le billet de joe duffy ils ont fait un gc deterministe.

Pour le code natif restant et le fait qu’il ne peut pas etre prouve j’ai répondu dans mon commentaire précédent.


votre avatar







francois-battail a écrit :



<img data-src=" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.

M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force surtout quand ça prétend être en mesure de faire du système.





Huhu,



Je dev en Qt sur un linux Embedded, et bien je peux te dire que 90% des classes Qt sont beaucoup plus lentes que leurs équivalentes en .NET !!! (Qt 4.8.x)



Le problème du C++ c’est ce qu’on en fait surtout, en 15 ans de taff j’ai croisé peu de dev en entreprise capables de faire mieux que le .NET. Mais il y en a, c’est certain, mais se pose alors la question du cout ! Optimiser aux petits oignons ça prend du temps, beaucoup de temps et c’est rarement justifiable en entreprise…



Le .NET offre des milliers de classes très optimisées, alors même si globalement on perd (supposition) encore 5% par rapport à l’équivalent optimisé en C++ je pense que le .NET est largement plus rentable.



A partir de Midori, la seule question à se poser sera “Mon projet va-t-il tourner seulement sur Windows”, et si oui ce sera .NET.



La philosophie n’a pas sa place en entreprise… <img data-src=" />


votre avatar







charon.G a écrit :



De toute façon quand on voit le nombre de failles dans les navigateurs web par exemple ça prouve bien qu’on peut pas compter sur les développeurs pour éviter de pondre des failles.







hum… C’est pas si simple.



Faut différencier deux types de failles:




  1. La faille du browser web qui permet d’exécuter du code arbitraire

  2. La faille de l’OS qui permet à une application d’accéder à des ressources non-autorisées (API, fichiers, interfaces…)



    Pour le premier type de faille, il est vrai que du simple “bound-checking” éviterait beaucoup d’attaques par débordement de buffer. Mais pas besoin de créer un nouvel OS pour cela (même si c’est un moyen draconien).



    Pour le second type de faille, du tree-shaking empêcherait l’appli “vérolée” d’accéder a des API qui ne sont pas utilisées/autorisées. Mais un browser web utilise/autorise l’accès au API réseau, aux fichiers, … Donc ca n’empêcherai pas l’appli “vérolée” de voler/modifier des données, par exemple.



    Enfin bon, je suis impatient de voir ce que ca peut donner… Même si je suppose que l’adoption sur PC risque d’être freinée par l’obligation de renoncer à l’éco-système existant (sauf virtualisation/émulation).


votre avatar







wapamat a écrit :



Rien compris à l’article… Pas l’niveau… <img data-src=" />





Je suppose que ton paragraphe préféré était celui là :





L’utilité de M# a justement été débattue dans les commentaires qui ont suivi. La décision de se baser sur C# est initialement expliquée dans le billet de Duffy : la réduction de la complexité, le nombre de développeurs sachant aujourd’hui l’utiliser et la nécessité de certaines notions telles que la sûreté de typage. Mais pourquoi ne pas utiliser des langages existants tels que D, Rust ou Go ? Selon Aleks Bromfield, qui a passé les quatre dernières années à développer ce langage mais qui travaille maintenant chez Google, M# reprend des éléments des uns et des autres : la sûreté et les performances de Rust, la simplicité de Go ainsi que la familiarité du D. Il explique par ailleurs que le M# peut être utilisé pour n’importe quelle application et qu’il devrait être le langage le plus bas niveau dont les développeurs pourraient avoir besoin.


votre avatar







127.0.0.1 a écrit :



hum… C’est pas si simple.



Faut différencier deux types de failles:




  1. La faille du browser web qui permet d’exécuter du code arbitraire

  2. La faille de l’OS qui permet à une application d’accéder à des ressources non-autorisées (API, fichiers, interfaces…)



    Pour le premier type de faille, il est vrai que du simple “bound-checking” éviterait beaucoup d’attaques par débordement de buffer. Mais pas besoin de créer un nouvel OS pour cela (même si c’est un moyen draconien).



    Pour le second type de faille, du tree-shaking empêcherait l’appli “vérolée” d’accéder a des API qui ne sont pas utilisées/autorisées. Mais un browser web utilise/autorise l’accès au API réseau, aux fichiers, … Donc ca n’empêcherai pas l’appli “vérolée” de voler/modifier des données, par exemple.



    Enfin bon, je suis impatient de voir ce que ca peut donner… Même si je suppose que l’adoption sur PC risque d’être freinée par l’obligation de renoncer à l’éco-système existant (sauf virtualisation/émulation).





    Effectivement le 1 sera réglé par le langage et le 2 par l’os (ce n’est plus windows le fonctionnement differe)


votre avatar







127.0.0.1 a écrit :



Enfin bon, je suis impatient de voir ce que ca peut donner… Même si je suppose que l’adoption sur PC risque d’être freinée par l’obligation de renoncer à l’éco-système existant (sauf virtualisation/émulation).







Je ne suis pas contre à condition que ce ne soit pas réservé à une version pro.


votre avatar







charon.G a écrit :



Effectivement le 1 sera réglé par le langage et le 2 par l’os (ce n’est plus windows le fonctionnement differe)







Le 2, ca nécessiterait que Midori autorise l’accès a certains fichiers/sites et pas à d’autres pour chaque application. Un peu ce que fait SELinux…


votre avatar







127.0.0.1 a écrit :



Le 2, ca nécessiterait que Midori autorise l’accès a certains fichiers/sites et pas à d’autres pour chaque application. Un peu ce que fait SELinux…





Les applications seront surement sandboxes comme WinRT. Il ne sera pas possible de faire d’escalade de privileges vu que l’os sera safe donc on ne pourra pas exploiter de faille a ce dessein.


votre avatar

En fait la news en parle,c’est que j’avais prédis à l’époque dans le dossier sur Windows 8. WinRT a été conçu pour tourner au dessus de Midori.

Pour Win32 il y a drawbridge.

votre avatar







charon.G a écrit :



Pour le gc tu devrais lire le billet de joe duffy ils ont fait un gc deterministe.







Je ne suis pas certain d’avoir lu le bon billet, mais le jour où ce sera conforme à DO-178A on aura l’occasion d’en reparler.







Sebdraluorg a écrit :



La philosophie n’a pas sa place en entreprise… <img data-src=" />







J’attends avec impatience du Midori sur des micro-contrôleurs 8 ou 16 bits… mais pour le moment le C et l’assembleur (et pas le C++) pour du système ça convient parfaitement, après utiliser une couche d’abstraction en managé pour une interface graphique et des APIs pourquoi pas mais là on est au niveau de l’applicatif.


votre avatar







francois-battail a écrit :



Je ne suis pas certain d’avoir lu le bon billet, mais le jour où ce sera conforme à DO-178A on aura l’occasion d’en reparler.







J’attends avec impatience du Midori sur des micro-contrôleurs 8 ou 16 bits… mais pour le moment le C et l’assembleur (et pas le C++) pour du système ça convient parfaitement, après utiliser une couche d’abstraction en managé pour une interface graphique et des APIs pourquoi pas mais là on est au niveau de l’applicatif.







Lifetime understanding. C++ has RAII, deterministic destruction, and efficient allocation of objects. C# and Java both coax developers into relying too heavily on the GC heap, and offers only “loose” support for deterministic destruction via IDisposable. Part of what my team does is regularly convert C# programs to this new language, and it’s not uncommon for us to encounter 30-50% time spent in GC. For servers, this kills throughput; for clients, it degrades the experience, by injecting latency into the interaction. We’ve stolen a page from C++ — in areas like rvalue references, move semantics, destruction, references / borrowing — and yet retained the necessary elements of safety, and merged them with ideas from functional languages. This allows us to aggressively stack allocate objects, deterministically destruct, and more.


votre avatar







127.0.0.1 a écrit :



hum… C’est pas si simple.



Faut différencier deux types de failles:




  1. La faille du browser web qui permet d’exécuter du code arbitraire

  2. La faille de l’OS qui permet à une application d’accéder à des ressources non-autorisées (API, fichiers, interfaces…)



    Pour le premier type de faille, il est vrai que du simple “bound-checking” éviterait beaucoup d’attaques par débordement de buffer. Mais pas besoin de créer un nouvel OS pour cela (même si c’est un moyen draconien).



    Pour le second type de faille, du tree-shaking empêcherait l’appli “vérolée” d’accéder a des API qui ne sont pas utilisées/autorisées. Mais un browser web utilise/autorise l’accès au API réseau, aux fichiers, … Donc ca n’empêcherai pas l’appli “vérolée” de voler/modifier des données, par exemple.



    Enfin bon, je suis impatient de voir ce que ca peut donner… Même si je suppose que l’adoption sur PC risque d’être freinée par l’obligation de renoncer à l’éco-système existant (sauf virtualisation/émulation).







    Difficile de comprendre ce que tu veux dire, soit le browser lui-même est vérolé auquel cas il est déjà trop tard, soit tu parles d’un site qui exploiterait une faille du browser et là c’est le boulot du sandboxing et du bound checking, qui justement sont ici renforcés.




votre avatar







charon.G a écrit :



Je pense que ce brevet de galen hunt devrait plus répondre à ta question:

http://www.freepatentsonline.com/7882317.pdf





Je te remercie, ça correspond effectivement à ce que j’avais rapporté dans mon précédent message à propos de Drawbridge : un domaine-processus en mode noyau contenant tous les processus vérifiables et un ou plusieurs domaine-processus en mode utilisateur isolés matériellement et contenant les processus invérifiables.



Par contre Drawbridge laissait aussi entendre, et c’était le point sur lequel je me posais le plus de questions, qu’ils ne réimplanteraient pas un noyau NT en mode noyau mais seulement en user-mode (fragile mais peu importe puisque le noyau est unique à un processus). Or l’annonce parle justement d’un micro-noyau. Ils semblent donc bien partis là-dessus.









charon.G a écrit :



Mais j’ai pas toutes les informations en effet la dessus. Par contre tu ne penses pas que si Microsoft sort une nouvelle plateforme de dev alors que win32 a duré plus de 20 ans, il ne va pas la jeter 3 ou 5 ans après?





Comme je disais, l’API WinRT correspond sans aucun doute à ce qui est exposé par le noyau Midori. On est d’accord là-dessus, pas de souci.



Par contre C++ CX, non, c’est seulement un moyen d’offrir aux développeurs C++ de pouvoir consommer leurs API. Pour rendre ce langage vérifiable il faudrait peu ou prou en supprimer les pointeurs (y compris dans C++ CLI), ce qui est impensable. Il faudra le faire pour C# d’ailleurs mais c’est peu problématique pour ce langage vu la place anecdotique des pointeurs.



La seule façon de maintenir les pointeurs (en C# ou C++) serait d’insérer à la compilation des vérifications de plage à chaque accès. Cela rendrait certes le processus vérifiable et utilisable dans un SIP mais au prix de performances plus faibles que dans un HIP. Aucun intérêt donc. Tant pis : C++ ne sera jamais vérifiable, il restera cantonné aux HIP et paiera une légère taxe sur les performances et la mémoire.



Ca ne veut pas dire que C++ CX sera obsolète dans cinq ans : dans cinq ans il y aura toujours des gens pour bosser en C++ et qui auront besoin de consommer les nouvelles API.







Kurian a écrit :



Que viens faire Roslyn dans l’histoire ? Juste un projet annexe ou c’est lié ?





A priori il n’y a pas de lien et il y avait de bonnes raisons pour créer Roslyn qui n’ont rien à voir avec tout ça.



Cela dit, dans la mesure où Midori interdira la réflexion il faudra ré-implémenter certaines fonctionnalités via de la génération de code à la compilation. Autant dit qu’un compilateur instrumentable et extensible sera des plus utiles.







moi1392 a écrit :



Ça a déjà beaucoup plus de sens ! Donc en clair, il n’y a PAS d’isolation.





Tout à fait : on vérifie en amont que tout le monde est honnête et du coup plus besoin de flics. Dit comme ça ça n’a pas l’air très sûr mais en fait ça l’est beaucoup plus que le système actuel.





Maintenant la question qui fache… qui maitrise le compilateur ?



Le certificateur, pas le compilateur. Le certificateur vérifie le code en bout de chaîne alors que les compilateurs ne seront pas dans l’OS et pourront être indépendants de MS, comme aujourd’hui.



Et la réponse est : les mêmes que ceux qui aujourd’hui maîtrisent la pose de clôture au sein de l’OS. Pas plus de problème qu’aujourd’hui, donc. Et puis le certificateur est lui-même simple à vérifier car très petit.


votre avatar







moi1392 a écrit :



je répète donc ma remarque, personne n’a de maitrise sur la chaine de compilation, et c’est à elle qu’il faut faire confiance pour la sécurité de l’os…

je vais le dire autrement…

“Ma maison est sure car les clés m’ont été données par l’ancien propriétaire et je n’ai aucun moyen de changer la serrure ni mettre d’alarme chez moi sans lui demander et qu’il l’installe lui même”

C’est une blague ???







Et tu laisses toute une communauté travaillé sur ta porte … Alors certes des fois ça permet d’éviter les erreurs de certains … mais ca n’empêche ta porte d’avoir des points de fragilité que personnes n’avaient vu pendant des années … Ah moins que pour toi Open Source = No failles <img data-src=" />



Là un menuisier te propose une porte sécuriser par conception … Alors certes le menuisier a peut etre fournit le double à un Etat … Mais du moment que ma porte résiste de par sa conception à tout ceux qui vont vouloir faire mumuse avec cette porte ca me va. Puis de toute façons tout la ville est corrompu (cf internet - NSA - DPI etc…) si tu veux te protéger, déconnecte toi de la ville.



On va arrêter les analogies foireuses <img data-src=" /> Si tu veux débattre sur Prism et Microsoft va sur une news qui à pour sujet la NSA … Là ta remarque est avant tout porté sur le méchant closed source … Débat mainte fois débattu qui n’a pas trop lieux d’être ici … Le closed source te donnes des boutons, tant pis reste sur un OS libre…



Ce projet n’est même pas encore officiel mais a pour but de révolutionner la façon d’écrire des OS depuis les 20⁄30 dernières années en utilisant des concepts de programmation relativement nouveaux. Restons sur ce sujet.


votre avatar



Tout à fait : on vérifie en amont que tout le monde est honnête et du coup plus besoin de flics. Dit comme ça ça n’a pas l’air très sûr mais en fait ça l’est beaucoup plus que le système actuel.



Bien résumé c’est le principe de fonctionnement de singularity et Midori <img data-src=" />

Avec Windows on laisse faire et on tente de protéger les dégats avec plein de garde fous.



Avec Singularity/midori on établit les règles du départ. Du coup pas besoin de garde fous inutiles.

votre avatar







HarmattanBlow a écrit :



Je te remercie, ça correspond effectivement à ce que j’avais rapporté dans mon précédent message à propos de Drawbridge : un domaine-processus en mode noyau contenant tous les processus vérifiables et un ou plusieurs domaine-processus en mode utilisateur isolés matériellement et contenant les processus invérifiables.



Par contre Drawbridge laissait aussi entendre, et c’était le point sur lequel je me posais le plus de questions, qu’ils ne réimplanteraient pas un noyau NT en mode noyau mais seulement en user-mode (fragile mais peu importe puisque le noyau est unique à un processus). Or l’annonce parle justement d’un micro-noyau. Ils semblent donc bien partis là-dessus.







Je sais pas si tu as vu cette video ? Ca explique un peu le fonctionnement … Pour tout le reste voir avec Charon ^^


votre avatar







arno53 a écrit :



Je sais pas si tu as vu cette video ? Ca explique un peu le fonctionnement … Pour tout le reste voir avec Charon ^^





Je te remercie mais à vrai dire je préfère de loin le papier de recherche, plus rapide à lire. ^^


votre avatar



Le certificateur, pas le compilateur. Le certificateur vérifie le code en bout de chaîne alors que les compilateurs ne seront pas dans l’OS et pourront être indépendants





Ça me parait pas si évident.

Je pense qu’on peut facilement inventer un langage dans lequel tout programme peut-être certifié (c’est d’ailleurs ce qui a été fait si j’ai bien compris, et ça existait avant cela)

Par contre, certifer le résultat d’un programme, au pif, d’un compilateur, c’est une autre histoire… qui ne doit pas être très loin de la question de la terminaison d’un programme, qui est indémontrable.

Je conçois qu’un peut facilement certifier un compilateur, mais pas le résultat de ce qu’il compile, seulement en lisant le code du compilateur.



Et là où il y a une différence d’indépendance par rapport au système actuel (qui est loin d’être parfait, on est bien d’accord) c’est que tu n’as pas la possibilité d’écrire du code qui va monitorer/manager un autre programme, car il sera invalide et te sera refusé à la compilation (quid d’un débogeur tiens, comment cela marche sur un tel système ?)

votre avatar







arno53 a écrit :



….







tu es donc d’accord avec moi toi aussi…


votre avatar







moi1392 a écrit :



Ça me parait pas si évident.





Comme je l’ai dit dans un précédent message, par “certifier” ou “vérifier” on entend uniquement que :

* Le processus n’accède qu’à sa propre mémoire et n’écrit que dans sa propre zone de données.

* Le processus n’exécute aucune des instructions interdites.



Si je ne m’abuse ces deux conditions sont suffisantes et nécessaires pour une exécution en ring 0 sans compromettre la sécurité. Or on peut mettre au point des règles (un bytecode) qui rendent toujours vérifiables ces hypothèses. Et de là créer / adapter plusieurs langages pour les rendre vérifiables.



Quant à certifier le résultat, ça n’a pas d’intérêt pour le problème posé et ce serait effectivement équivalent au problème indécidable de l’arrêt.





tu n’as pas la possibilité d’écrire du code qui va monitorer/manager un autre programme, car il sera invalide et te sera refusé à la compilation (quid d’un débogeur tiens, comment cela marche sur un tel système ?)



Mais si c’est possible. ;)

La communication inter-processus est régulée par quelques contrats que les applications peuvent déclarer et souscrire. Ceux-ci sont définis de façon rigide en définissant toutes les étapes de la conversation et les données échangées à chaque étape, et le système peut vérifier que chacun implémente correctement sa part de la communication.



Le système est même, cadeau bonus non-nécessaire, capable de détecter les deadlocks dans la conversation, les cas non-couverts où l’interférence entre plusieurs applications afin de pouvoir signaler à l’utilisateur que telle application compromettra le fonctionnement de telle autre.



Concernant le débogueur, concrètement celui-ci exposera donc un contrat lui donnant accès à toute la mémoire du souscripteur et le compilateur insèrera en mode debug une souscription à ce contrat dans l’application générée.



Tant que c’est entre adultes consentants, tout est permis. Où pour reprendre une analogie foireuse, nos gens honnêtes ont été priés de déclarer avec qui et comment ils comptaient fricoter dans la maison sans flics où tout le monde est nu. Pas très spontané mais très consentant et sans ambiguïté.


votre avatar







HarmattanBlow a écrit :



Comme je l’ai dit dans un précédent message, par “certifier” ou “vérifier” on entend uniquement que :

* Le processus n’accède qu’à sa propre mémoire et n’écrit que dans sa propre zone de données.

* Le processus n’exécute aucune des instructions interdites.



Si je ne m’abuse ces deux conditions sont suffisantes et nécessaires pour une exécution en ring 0 sans compromettre la sécurité. Or on peut mettre au point des règles (un bytecode) qui rendent toujours vérifiables ces hypothèses. Et de là créer / adapter plusieurs langages pour les rendre vérifiables.



Quant à certifier le résultat, ça n’a pas d’intérêt pour le problème posé et ce serait effectivement équivalent au problème indécidable de l’arrêt.





Mais si c’est possible. ;)

La communication inter-processus est régulée par quelques contrats que les applications peuvent déclarer et souscrire. Ceux-ci sont définis de façon rigide en définissant toutes les étapes de la conversation et les données échangées à chaque étape, et le système peut vérifier que chacun implémente correctement sa part de la communication.



Le système est même, cadeau bonus non-nécessaire, capable de détecter les deadlocks dans la conversation, les cas non-couverts où l’interférence entre plusieurs applications afin de pouvoir signaler à l’utilisateur que telle application compromettra le fonctionnement de telle autre.



Concernant le débogueur, concrètement celui-ci exposera donc un contrat lui donnant accès à toute la mémoire du souscripteur et le compilateur insèrera en mode debug une souscription à ce contrat dans l’application générée.



Tant que c’est entre adultes consentants, tout est permis.





Tu ne penses pas que cette méthode pourrait être utilisée pour gérer la compilation JIT pour les navigateurs web par exemple? Le problème c’est qu’à la base c’est interdit par singularity et Midori. Mais j’imagine bien que Microsoft avait prévu un truc pour ce problème.


votre avatar







charon.G a écrit :



Tu ne penses pas que cette méthode pourrait être utilisée pour gérer la compilation JIT pour les navigateurs web par exemple? Le problème c’est qu’à la base c’est interdit par singularity et Midori. Mais j’imagine bien que Microsoft avait prévu un truc pour ce problème.





Midori interdit la modification de l’espace de code par le processus lui-même parce que le processus ne serait plus vérifiable. Mais il y a une solution très simple : soumettre un flux TAL, vérifiable, au noyau. En effet l’ajout d’un code certifié ne peut logiquement pas compromettre la certification du code existant. Le noyau pourrait alors se charger de patcher un SIP existant ou de créer un SIP à la volée, puisque le coût de ces derniers est quasi-nul. Ce type de scénario est parfaitement envisageable.



A vrai dire les deux variantes seraient nécessaires pour un navigateur : un processus par page pour cloisonner les données des pages (superflu à vrai dire puisque le code est forcément honnête), puis un patch à la volée parce qu’il n’est pas possible de compiler entièrement le javascript faute d’informations sur le typage, celui-ci n’étant entièrement connu qu’à l’exécution. Et comme il faut partager les données mieux vaut avoir un seul SIP par page plutôt qu’un SIP par fonction !


votre avatar







HarmattanBlow a écrit :



Midori interdit la modification de l’espace de code par le processus lui-même parce que le processus ne serait plus vérifiable. Mais il y a une solution très simple : soumettre un flux TAL, vérifiable, au noyau. En effet l’ajout d’un code certifié ne peut logiquement pas compromettre la certification du code existant. Le noyau pourrait alors se charger de patcher un SIP existant ou de créer un SIP à la volée, puisque le coût de ces derniers est quasi-nul. Ce type de scénario est parfaitement envisageable.



A vrai dire les deux variantes seraient nécessaires pour un navigateur : un processus par page pour cloisonner les données, puis un patch à la volée parce qu’il n’est pas possible de compiler entièrement le javascript faute d’informations sur le typage, celui-ci n’étant entièrement connu qu’à l’exécution. Et comme il faut partager les données mieux vaut avoir un seul SIP par page plutôt qu’un SIP par fonction !





Pas con merci pour ta réponse <img data-src=" />


votre avatar

Par contre le TAL m’inquiète un peu. Aujourd’hui le bytecode dotnet contraint tous les langages dotnet à se taper le même système rigide de types. Impossible de l’enrichir sans implémenter une infrastructure complète au-dessus de l’infrastructure, avec les performances que tu imagines (il suffit de voir F#). Je trouverais dommage que Midori nous enferme ainsi dans un système de typage trop cloisonné. Pour moi c’est le gros point noir.

votre avatar

Hum … Donc si j’ai bien compris la politique associée au langage concernant la mémoire, grosso modo on a un langage qui accepte l’allocation dynamique, on va recevoir les accès à ces zones par des références (au sens C++, pas des pointeur quoi), qui sont modifiables mais uniquement par affectation d’une référence valide (pas d’arithmétique des pointeurs, c’est pas pour me déplaire).



Sur un langage full-GC (même si j’aime pas les GC), je trouve ça ok effectivement.



Cela dit si on a du très bas niveau, on veut avoir une déalloc parfaitement déterministe. C’est quoi derrière ? Du comptage de référence ? Ce serait quand même plus correct d’être plus précis niveau responsabilité si on veut très efficace, non ? (comprendre shared_ptr/unique_ptr en C++11).



Grosse interrogation pour ma part également : quid des modèles mémoire faibles ? C’est oblitéré par des barrières fortes où l’on a toujours le choix de rester borderline ? Parce que dans ce contexte, faire de la certification même avec juste de l’allocation statique c’est déjà mission impossible alors avec du dynamisme … Waow !

votre avatar







HarmattanBlow a écrit :



Par contre le TAL m’inquiète un peu. Aujourd’hui le bytecode dotnet contraint tous les langages dotnet à se taper le même système rigide de types. Impossible de l’enrichir sans implémenter une infrastructure complète au-dessus de l’infrastructure, avec les performances que tu imagines (il suffit de voir F#). Je trouverais dommage que Midori nous enferme ainsi dans un système de typage trop cloisonné. Pour moi c’est le gros point noir.





Je sais déjà que WinRT a son propre système de type, qu’il lie à celui des langages dotnet. Ce que tu me dis me fait penser à un vieux brevet je suis en train de chercher mais pour le moment je ne retrouve pas le lien.


votre avatar







Khalev a écrit :



T’as des liens vers ces brevets? Parce que jusqu’à présent quand je te lis j’ai plus l’impression de lire un fanboy sans esprit critique qui croit tout ce que lui dit le grand Microsoft que quelqu’un de vraiment raisonné.

Un peu de sources sur tes dires serait bienvenu (et permettrait de mettre tout le monde à niveau). Comme le dit HarmattanBlow, on a pas tous le temps de faire un veille exhaustive.





je pense que j’ai donné pas mal de liens et de sources sur cette news. Je te réponds juste pour te dire que j’ai retrouvé le brevet en question:

http://www.freepatentsonline.com/7673109.html



Ce brevet parle d’une techno qui sert à faire communiquer du code unsafe avec des composants haut niveau en safe code de façon sure.


votre avatar







Ksass`Peuk a écrit :



Cela dit si on a du très bas niveau, on veut avoir une déalloc parfaitement déterministe. C’est quoi derrière ? Du comptage de référence ? Ce serait quand même plus correct d’être plus précis niveau responsabilité si on veut très efficace, non ? (comprendre shared_ptr/unique_ptr en C++11).





Midori n’impose rien de ce genre : comme tu l’as dit on retire l’arithmétique de pointeurs et on garde de simples références typées à la place. Mais à aucun moment il n’est nécessaire de vérifier que la mémoire sera correctement libérée. Donc GC, ARC, ou autres. C’est un choix propre au langage.





Grosse interrogation pour ma part également : quid des modèles mémoire faibles ?



D’abord on sort à nouveau du cadre de ce que Midori doit vérifier (cf post #151) et a priori il n’y a aucune raison pour eux d’avoir à définir un modèle mémoire. Sauf pour une chose très convenue : l’atomicité des assignations de références. Mais je ne pense pas qu’il y ait une seule architecture moderne sur laquelle ce ne soit pas le cas.



Maintenant concernant M# son chef de projet, Duffy, est avant tout un spécialiste des problèmes de concurrence. Et il avait publié un billet très intéressant sur le sujet : ]Sayonara volatile



Sa position est que 99% des développeurs ne devraient pas avoir du tout à se préoccuper de ces problèmes et que les 1% restants devraient avoir un contrôle total sur celui-ci. Pas de niveau intermédiaire. Il propose une révision en conséquence de volatile, qui disparaîtrait en tant que mot-clé.











charon.G a écrit :



Je sais déjà que WinRT a son propre système de type, qu’il lie à celui des langages dotnet. Ce que tu me dis me fait penser à un vieux brevet je suis en train de chercher mais pour le moment je ne retrouve pas le lien.





Ma foi si quelque chose te revient en mémoire à ce sujet, c’est le genre de choses que je serais curieux de lire.



EDIT : merci je regarde ça.


votre avatar







Sebdraluorg a écrit :



Wep, j’ai bien lu ce que disait harmattanblow, mais visiblement quelques chose m’échappe… <img data-src=" />



J’ai pas lu le pdf du projet, mais tu dis qu’il passe de js à .Net, tu veux dire quoi au juste par .Net ?



Si tu peux aller de js vers .NET (et donc typé) il n’y a plus d’obstacle pour faire un “patch” à la volée, si ?





Par .net j’appelle le code CIL(pseudo code .net).

Faut que je relise mais une partie du code .net généré est converti en natif en compilation JIT par un runtime spécifique à l’éxécution. ce qui poserait problème.


votre avatar



Oui, je suis le premier à dire qu’il y aura une perte.



Cela dit :

* La valeur de ces micro-optimisations est souvent surévaluée, de moins en moins significative, surtout par à la parallélisation, et les humains font aujourd’hui rarement mieux que les compilateurs (la vectorisation automatique devient aujourd’hui monnaie courante).



* Il y aura des gains par ailleurs : la suppression de la mémoire virtuelle c’est un gros cadeau pour les performances.



Effectivement dans les précédents débats j’expliquais que les pertes pouvaient être compensées par d’autres points.



Joe duffy explique bien dans son post que le compilateur effectue tout un tas d’optimisations poussées.





It’s commonly claimed that with type-safety comes an inherent loss of performance. It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here





Il y en a une sur la quelle j’ai débattu sur twitter qui semblerait être aussi utilisée dans project N. C’est letree shaking:

msdn.microsoft.com Microsoftil y aussi le fait que M# devrait être conçu pour la programmation many core.

votre avatar

Le travail sur Midori aurait peut être profité à RyuJIT ou peut être le contraire: RyuJIT

C’est quand même une bonne nouvelle qu’on puisse faire du bas niveau dans un langage proche du C#, ceci ouvre de nouvelle perspective pour nous.

votre avatar

A propos du tree shaking je voudrais relever un détail. Felix qui est une des sources actives de mary jo foley a analysé freshpaint sur Windows RT 8.1. Il a trouvé des réferences à project N. Il a aussi remarqué que tout le code est désormais dans un binaire. Ce serait une spécificité avec le tree shaking. Sur Singularity la notion de librairies ou de DLL changent déjà vu que les SIP sont isolées. Une DLL sur les systèmes actuels se chargent dans l’espace mémoire du processus et de façon dynamique pour certaines.Avec Singularity une dll devrait tourner dans son propre sip ou être fusionné au code du programme.



D’après les tweets de felix il semblerait qu’au niveau binaire le programme avec toutes ses librairies forment une seule entité. Ce qui permettrait normalement de rendre le tree shaking beaucoup plus efficace.



twitter.com Twittertwitter.com Twittertwitter.com Twittertwitter.com Twittertwitter.com Twittertwitter.com Twitter

votre avatar







charon.G a écrit :



Il y en a une sur la quelle j’ai débattu sur twitter qui semblerait être aussi utilisée dans project N. C’est letree shaking:





J’avais vu que tu avais déjà mentionné ça, oui. Cela dit en termes de performances ça me semble plutôt insignifiant :



* Ça réduit la taille de l’empreinte mémoire du code d’un ou deux Mo et c’est cool sur les smartphones en 2014 mais c’est très vite anecdotique. A tous les coups ça n’accélère même pas le chargement (je parie qu’ils revérifient le code à chaque lancement par sécurité)



* Ça rend les accès au code plus souvent séquentiels mais ça restera anecdotique et le code gourmand tend déjà à rester en mémoire de toute façon.



* Théoriquement des champs en moins ça pourrait vraiment être intéressant mais en pratique 99% des types n’auront aucun champ à supprimer.



* Reste l’amincissement des tables virtuelles qui laissera quelques ko de cache en plus pour les données, et le scellage de méthodes aujourd’hui virtuelles (mais les méthodes gourmandes sont déjà scellées).



Bref, à mon avis c’est peu significatif. D’ailleurs si ça l’était on utiliserait déjà abondamment cette technique pour le code natif vu que les applications sont scellées. Pourtant personne ne le fait (même si le compilateur le fait en partie). Par exemple les dll livrées avec les jeux sont les dll d’origine plutôt que des version élaguées sur mesure pour le jeu ou fusionnées dans l’exe. En revanche ça aurait tout son sens pour JS afin de gagner de la bande passante et ainsi accélérer le chargement des sites.









charon.G a écrit :



Une DLL sur les systèmes actuels se chargent dans l’espace mémoire du processus et de façon dynamique pour certaines.Avec Singularity une dll devrait tourner dans son propre sip ou être fusionné au code du programme.





Non, s’ils faisaient ça il leur faudrait complètement réécrire les dll pour y ajouter des contrats et communiquer par message avec l’appli, ce qui serait désastreux pour les performances. On ne peut pas facilement séparer une dll pour la mettre dans son SIP.



En fait chaque application déclare à l’avance les dll qu’elle va consommer. Quand Midori charge l’application, il charge en même toutes les dll et c’est cette base de code unifiée qui est ensuite certifiée et fait l’objet d’un élagage (tree shaking / pruning).


votre avatar







HarmattanBlow a écrit :



Non, s’ils faisaient ça il leur faudrait complètement réécrire les dll pour y ajouter des contrats et communiquer par message avec l’appli, ce qui serait désastreux pour les performances. On ne peut pas facilement séparer une dll pour la mettre dans son SIP.



En fait chaque application déclare à l’avance les dll qu’elle va consommer. Quand Midori charge l’application, il charge en même toutes les dll et c’est cette base de code unifiée qui est ensuite certifiée et fait l’objet d’un élagage (tree shaking / pruning).





Oui c’est le fonctionnement actuel de singularity les dépendances sont listées dans le manifeste et les dlls sont chargées au chargement de l’application.

Cependant felix a trouvé des choses sur ce qu’il appelle le fat binary avec project N.

Wait and see….


votre avatar

Beaucoup de discussions passionnées chez les INpactiens (et tiennes). Je ramène ma fraise de vieux qui a appris l’assembleur sur 6502, 8085 et 8031. Pour moi, un CPU n’exécute QUE de l’assembleur. Alors, un code managé, compilé ou semi-compilé est d’abord traduit en assembleur. Donc, dans un driver écrit en mode managé, on mettra POKE 53281,0 pour le traduire en mov 0xd020, #0 après un décodage de l’adresse, de la donnée, et une vérification qu’on ne déborde pas dans le SIP d’à coté. Très bien, mais avec cet exemple trivial j’ai du mal à croire qu’on pourra écrire un OS 2 fois plus performant, d’autant que la loi de Moore arrive à son terme, la limite physique du nombre d’atomes dans une jonction silicium. Certes, les architectures sont de plus en plus performantes, mais où sont les CPU à 5GHz qu’Intel nous avait promis à la sortie des P4-Netburst ? Je demande à voir le prochain driver NVidia doubler les performances en étant écrit en M# au lieu de C ou ASM.

Ensuite le micro noyau. Sur le papier c’est très bien, plus sécurisé, etc, etc… Sauf que la communication inter processus écroule les performances de cette belle théorie et démontre que ce qui fonctionne le plus rapidement, c’est le noyau monolithique. C’est d’ailleurs le choix du marché, voir le TOP500 des machines les + performantes trusté par Linux, noyau monolithique. Donc, il faut choisir : performance ou sécurité.

Je continue sur la sécurité qui ne se passe pas qu’au niveau du noyau ou même au niveau du langage. La dernière fois que j’ai dû virer un vers d’une machine, c’était sur un poste Windows7, et le vers était dans C:\USERS\Prénom\APPDATA\ROAMING\ZZYYXX\VILAINVERS.EXE. Un EXE en Win32. L’UAC n’a rien fait vu que le vers n’était ni dans C:\PROGRA~1 ni dans C:\WINDOWS. Alors le plus beau langage avec le plus beau noyau ne servira à rien tant que le dossier utilisateur sera exécutable par défaut (je l’ai déjà dit et redit). Un simple NOEXEC en option de montage sur le /HOME suffit à repousser tous les vers, mais ce n’est pas du monde Windows…

Ou alors on développe tout en JAVASCRIPT sans fonction OPEN en écriture et sans appel système pour ne pas écrire de fichier, et les données restent dans le cloud.

votre avatar

Je relis mon poste et je me dis que le rêve, c’est l’OS en ROM, le dossier utilisateur en NOEXEC, et toutes les données et applicatifs dans le cloud avec abonnement.

votre avatar







CaptainDangeax a écrit :



BEnsuite le micro noyau. Sur le papier c’est très bien, plus sécurisé, etc, etc… Sauf que la communication inter processus écroule les performances de cette belle théorie et démontre que ce qui fonctionne le plus rapidement, c’est le noyau monolithique. C’est d’ailleurs le choix du marché, voir le TOP500 des machines les + performantes trusté par Linux, noyau monolithique.





C’est une idée reçue qui est fausse ;) , les travaux sur les kernels L4 portent leurs fruits progressivement. Pour avoir sous les yeux un micro-noyau expérimental qui exécute un Linux (en user-space par dessus), on est à moins de 8% de perte de performance - moyenne - (même si le portage est fait à l’arrache).

Evidemment, ça ne marche pas dans tous les cas, puisque les optimisations sont écrites en fonction de ce sur quoi tournent les programmes. Si on a passé 10 ans à optimiser pour un modèle particulier, il n’y aucune chance que sur un autre modèle ce soit plus rapide, il faut optimiser pour le nouveau modèle.

De plus dans le cas de Midori, l’ensemble des tâches certifiées s’exécutera en espace kernel, la perte de performance dûe aux IPC sera littéralement détruite.

Par ailleurs, les choix du marché ne sont pas forcément les plus pertinents, ils sont là où le plus d’argent a été investit dans le passé alors qu’on avait qu’une estimation partielle de ce qui était possible.


votre avatar







CaptainDangeax a écrit :



Donc, dans un driver écrit en mode managé, on mettra POKE 53281,0 pour le traduire en mov 0xd020, #0 après un décodage de l’adresse, de la donnée, et une vérification qu’on ne déborde pas dans le SIP d’à coté.





Perdu, tu as mal compris.




  1. La mémoire virtuelle n’est plus nécessaire.

  2. La vérification de la plage du SIP n’est pas nécessaire.



    Donc non seulement une assignation dans une application managé produira exactement les mêmes instructions qu’un code natif mais en plus il n’y a pas de table des pages à consulter !



    Tout simplement parce que le comportement du code managé est vé-ri-fiable dans le sens où on peut s’assurer en avance qu’il ne débordera jamais chez le voisin. Plus besoin de flic.





    Certes, les architectures sont de plus en plus performantes, mais où sont les CPU à 5GHz qu’Intel nous avait promis à la sortie des P4-Netburst ?



    En revanche nos GPU ont des milliers de coeurs chacun et demains nos CPU auront des dizaines de coeur. Tu ne crois pas qu’il faudrait les utiliser et que ça nécessite un modèle de conurrence flexible et vérifiable ?





    Ensuite le micro noyau. Sur le papier c’est très bien, plus sécurisé, etc, etc… Sauf que la communication inter processus écroule les performances



    Sauf qu’encore une fois tu n’as rien lu sur Singularity, sinon tu saurais que la communication inter-processus y est plus rapide puisque celle-ci obéit à un dialogue contractualisé par les deux parties et vérifiable qui leur permet de partager des buffers et d’envoyer des messages très rapidement.



    A nouveau tout découle du fait qu’avec des langages vérifiables et des processus vérifiés on peut supprimer les barrières. Sans qu’en plus, ici, dans le cas de communication IPC, on vérifie jusqu’au fait que toutes les étapes du flux de dialogue sont contractualisées et qu’il n’y aura pas de deadlock.





    L’UAC n’a rien fait vu que le vers n’était ni dans C:\PROGRA~1 ni dans C:\WINDOWS



    Si UAC n’a pas réagi c’est que le vers n’a jamais rien fait nécessitant l’intervention de l’UAC ou qu’il a trouvé un moyen d’empêcher son déclenchement.



    Dans Win8 les permissions pour les applis ModernUI sont par défaut très restreintes, donc impossible de faire quoi que ce soit de nuisible en douce sans alerter l’utilisateur. Or c’est le modèle retenu par Singularity.


votre avatar







Ksass`Peuk a écrit :



C’est une idée reçue qui est fausse ;)









…on est à moins de 8% de perte de performance - moyenne - (même si le portage est fait à l’arrache).





Loin de moi l’idée de vouloir couper les cheveux en 4 mais justement les optimisations se font à coup de % voire de pouillème de pourcent. Alors, 8% c’est juste énorme et c’est aussi ce qui contredit ton “idée reçue fausse”. L’équation est simple : communication inter process = chute des performances. C’est juste de l’info industrielle, de l’électronique bien physique si tu préfère. Le process A écrit dans une mémoire partagée, qui ne l’est pas le temps de l’écriture. Puis, il y a changement de contexte pour que le process B puisse lire cette zone mémoire, et ça prend des cycles CPU, donc du temps, avant le le process B ne puisse lire cette mémoire. Donc, certes on peut optimiser, mais il y aura toujours le changement de contexte qui n’existe pas en monolithique puisqu’en fait, toute la mémoire est partagée et donc il n’y a pas de changement de contexte consommateur de cycle. À force d’optimisation il sera possible de se rapprocher, mais en aucun cas de dépasser.



Par ailleurs, les choix du marché ne sont pas forcément les plus pertinents, ils sont là où le plus d’argent a été investit dans le passé alors qu’on avait qu’une estimation partielle de ce qui était possible.



Un exemple venant confirmer ton opinion…


votre avatar







CaptainDangeax a écrit :



Loin de moi l’idée de vouloir couper les cheveux en 4 mais justement les optimisations se font à coup de % voire de pouillème de pourcent. Alors, 8% c’est juste énorme et c’est aussi ce qui contredit ton “idée reçue fausse”.





8% avec un système posé à l’arrache par dessus. 0 optimisation, juste une redirection brutale des demandes. Les 8% sont largement bouffables par une optimisation du côté de la partie virtualisée (précision : para-virtualisation dans le cas présent).





CaptainDangeax a écrit :



L’équation est simple : communication inter process = chute des performances. C’est juste de l’info industrielle, de l’électronique bien physique si tu préfère. Le process A écrit dans une mémoire partagée, qui ne l’est pas le temps de l’écriture. Puis, il y a changement de contexte pour que le process B puisse lire cette zone mémoire, et ça prend des cycles CPU, donc du temps, avant le le process B ne puisse lire cette mémoire.





Pour ça je vais m’auto-quoter :





Ksass`Peuk a écrit :



De plus dans le cas de Midori, l’ensemble des tâches certifiées s’exécutera en espace kernel, la perte de performance dûe aux IPC sera littéralement détruite.





Et quoter @HarmattantBlow :





HarmattanBlow a écrit :



la communication inter-processus y est plus rapide puisque celle-ci obéit à un dialogue contractualisé par les deux parties et vérifiable qui leur permet de partager des buffers et d’envoyer des messages très rapidement.



votre avatar







HarmattanBlow a écrit :



Perdu, tu as mal compris.




  1. La mémoire virtuelle n’est plus nécessaire.

  2. La vérification de la plage du SIP n’est pas nécessaire.





    Perdu, ce n’est pas de la mémoire virtuelle, c’est un registre physique dans un chip. J’ai pourtant prévenu que j’étais un vieux de la vieille, tu aurais dû vérifier d’où vient cette instruction avant de parler de mémoire virtuelle. De toute façon c’est du code managé, ce sera toujours moins rapide que de l’ASM et même du C correctement compilé, puisque code managé implique une certaine dose d’interprétation.





    En revanche nos GPU ont des milliers de coeurs chacun et demains nos CPU auront des dizaines de coeur. Tu ne crois pas qu’il faudrait les utiliser et que ça nécessite un modèle de concurrence flexible et vérifiable ?



    Si c’est pour attendre des E/S en mémoire…





    Sauf qu’encore une fois tu n’as rien lu sur Singularity, sinon tu saurais que la communication inter-processus y est plus rapide puisque celle-ci obéit à un dialogue contractualisé par les deux parties et vérifiable qui leur permet de partager des buffers et d’envoyer des messages très rapidement.



    Si, j’ai lu les articles de PCI et tout ceci me semble très fumeux, pour ne pas dire plus.



    Si UAC n’a pas réagi c’est que le vers n’a jamais rien fait nécessitant l’intervention de l’UAC ou qu’il a trouvé un moyen d’empêcher son déclenchement.



    Donc l’UAC ne sert à rien, merci de nous le confirmer.



    Dans Win8 les permissions pour les applis ModernUI sont par défaut très restreintes, donc impossible de faire quoi que ce soit de nuisible en douce sans alerter l’utilisateur. Or c’est le modèle retenu par Singularity.



    …sur des dossiers utilisateurs pouvant contenir des exécutables, donc la moindre faille exploitée se traduit en l’installation d’un vers.


votre avatar







HarmattanBlow a écrit :



Sauf qu’encore une fois tu n’as rien lu sur Singularity, sinon tu saurais que la communication inter-processus y est plus rapide puisque celle-ci obéit à un dialogue contractualisé par les deux parties et vérifiable qui leur permet de partager des buffers et d’envoyer des messages très rapidement.





La seule question qui compte c’est :

est-ce que ce sera plus rapide ou moins rapide qu’en monolithique ?


votre avatar

CaptainDangeax tu te méprends sur le but de l’UAC. Microsoft a toujours dit que l’UAC n’était pas une barrière de sécurité contrairement à la sandbox des applications Windows Store.



Mark Russinovich l’avait clairement dit à l’époque de Vista. Le but de l’UAC était de forcer les développeurs à ne plus écrire d’applications qui demandent les droits administrateurs inutilement. L’UAC n’arrête pas les virus ou malwares. Par contre si les applications tournent avec des droits utilisateurs(stratégie réussie quand Windows 7 est sortie), ça diminue la portée des attaques en cas de faille, ce qui est déjà pas mal.

votre avatar







charon.G a écrit :



CaptainDangeax tu te méprends sur le but de l’UAC. Microsoft a toujours dit que l’UAC n’était pas une barrière de sécurité contrairement à la sandbox des applications Windows Store.



Mark Russinovich l’avait clairement dit à l’époque de Vista. Le but de l’UAC était de forcer les développeurs à ne plus écrire d’applications qui demandent les droits administrateurs inutilement. L’UAC n’arrête pas les virus ou malwares. Par contre si les applications tournent avec des droits utilisateurs(stratégie réussie quand Windows 7 est sortie), ça diminue la portée des attaques en cas de faille, ce qui est déjà pas mal.





source diapo 30


votre avatar







CaptainDangeax a écrit :



…





La loi de moore est lieé a la finesse de gravure qui va certes arrivé a un blocage. Ca va justement pousser les fondeurs a faire du many-core … Ca fait des années qu’on stagne a 4⁄6 coeurs, là on passera a du 12⁄24 coeurs etc … Et midori est pensé dans cette optique.



“ Sauf que la communication inter processus écroule les performances” =&gt; pas avec Midori … Relis les comm’s de Charon ou les papiers sur Singularity.



“l’histoire du vers informatique”” =&gt; les applis WinRT sont sandboxé et sont pour l’instant disponible que par le store. A termes les virus seront désinstallable en un clic. Y’a pas de Virus sur Windows RT.


votre avatar







CaptainDangeax a écrit :



Perdu, ce n’est pas de la mémoire virtuelle, c’est un registre physique dans un chip. J’ai pourtant prévenu que j’étais un vieux de la vieille, tu aurais dû vérifier d’où vient cette instruction avant de parler de mémoire virtuelle.





Poke était aussi utilisé en basic.





De toute façon c’est du code managé, ce sera toujours moins rapide que de l’ASM et même du C correctement compilé, puisque code managé implique une certaine dose d’interprétation.



Le code managé n’implique à aucun moment d’interpréter le code. Le seul surcoût du code managé c’est celui à payer pour la sécurité : vérifications aux bornes etcétéra.





Si c’est pour attendre des E/S en mémoire…



Si tu te réfères à la latence du bus PCI je parlais de coeurs intégrés au CPU. Si tu parles du fait que plus de coeurs signifie plus de cache et de bande passante avec la mémoire, oui, et alors ? Pourquoi cela introduirait-il plus de latence ?





Si, j’ai lu les articles de PCI et tout ceci me semble très fumeux, pour ne pas dire plus.



Va lire les papiers de recherche si tu veux en savoir plus. Mais manifestement tu n’avais rien compris. Les articles de PCI sont destinés à une audience large.





Donc l’UAC ne sert à rien, merci de nous le confirmer.



L’important quand on trolle, c’est d’en rajouter.







CaptainDangeax a écrit :



La seule question qui compte c’est :

est-ce que ce sera plus rapide ou moins rapide qu’en monolithique ?





Sur la communication IPC, oui, ce sera plus rapide. Beaucoup plus.

Mais ce n’est évidemment pas la seule chose qui compte, très loin de là. Pas en 2014.







arno53 a écrit :



La loi de moore est lieé a la finesse de gravure qui va certes arrivé a un blocage. Ca va justement pousser les fondeurs a faire du many-core … Ca fait des années qu’on stagne a 4⁄6 coeurs, là on passera a du 12⁄24 coeurs etc … Et midori est pensé dans cette optique.





Ca fait des décennies qu’on arrive à un blocage et qu’on le repousse donc… Et, non, la loi de Moore est indépendante de la finesse de gravure : quand on ne pourra plus miniaturiser on travaillera sur la dissipation et on empilera, et finalement on se rabattra sur un autre matériau. A mon avis on en a encore pour un moment vu ce qui est dans les labos.



Par ailleurs si la loi de Moore arrivait à un obstacle il ne serait pas possible d’ajouter plus de coeurs puisque, par définition, ceux-ci nécessitent des transistors.



Enfin si le nombre de coeurs a “stagné” (je trouve le terme fort), c’est que la demande n’allait pas dans ce sens.


votre avatar







arno53 a écrit :



“ Sauf que la communication inter processus écroule les performances” =&gt; pas avec Midori … Relis les comm’s de Charon ou les papiers sur Singularity.





C’est bien le problème, ce ne sont que des comm’s. Il faut des benchmarks, et pas des benchmarks truqués comme MS a si bien fait par le passé. En attendant, et après des dizaines d’années de promesses non tenues, je reste dubitatif et il faudra bien plus que des communications pour me convaincre, genre m’expliquer comment du code managé peut écrire plus vite en mémoire que de l’ASM, ou même du C compilé et avec un changement de contexte en prime ; parce que c’est bien beau la virtualisation, le mode protégé et tout ça, mais un ordi c’est avant tout du MATERIEL avec des mémoires PHYSIQUES et des chips avec des REGISTRES et il faut bien écrire dedans pour que ça fonctionne.





Y’a pas de Virus sur Windows RT.



J’ai parlé de vers, pas de virus. Je vais passer pour un maniaque, mais tant qu’on pourra mettre un exe dans le dossier utilisateur, le moindre vers s’installe à la moindre faille et il est impossible de développer sans faille, d’où l’intérêt d’un système bien conçu d’un point de vue architecture avant de se demander en quel langage on va coder ; parce que coder avant de spécifier c’est certifié ISO1664. Et espérer qu’un langage fortement “sécurisé” va améliorer l’architecture, c’est, comment dire, espérer que l’immeuble ne va pas s’effondrer parce qu’on mettra de l’adamantium à la place de la ferraille.


votre avatar

Actuellement Intel a une gamme de processeurs many core(TousLesDrivers fournit les drivers) en carte Pci Express je crois.



Je suis tombé sur cette news dernièrement où intel va bientôt sortir un vrai processeur manycore



A noter qu’intel a bossé en 2011 avec Microsoft sur le projet black cloud os. C’est un os dérivé de Singularity/Helios qui tourne sur leur gamme de processeurs many core.



Tout doucement on y arrive….

votre avatar







HarmattanBlow a écrit :



Poke était aussi utilisé en basic.





ça tombe bien c’en est.



Le code managé n’implique à aucun moment d’interpréter le code. Le seul surcoût du code managé c’est celui à payer pour la sécurité : vérifications aux bornes etcétéra.



Managed code -&gt; Bytecode dans une machine virtuelle. Ce n’est pas du langage machine, c’est donc de l’interprété. Donc perte de performances.





Si tu te réfères à la latence du bus PCI je parlais de coeurs intégrés au CPU. Si tu parles du fait que plus de coeurs signifie plus de cache et de bande passante avec la mémoire, oui, et alors ? Pourquoi cela introduirait-il plus de latence ?



Juste parce qu’on ne peut pas tout paralléliser et qu’il faudra toujours attendre une donnée partagée ou une E/S. Exemple : la compression en x264 plus rapide par GPU mais au prix d’une perte de qualité parce que la donnée précédente n’est pas disponible.





Va lire les papiers de recherche si tu veux en savoir plus. Mais manifestement tu n’avais rien compris. Les articles de PCI sont destinés à une audience large.



Bah non, je trouve le sujet assez fumeux comme ça : beaucoup d’affirmations et de promesses, peu de preuves…



L’important quand on trolle, c’est d’en rajouter.



C’est pas du troll, c’est l’approbation de la démonstration de l’INpactien ; c’est positif comme attitude, non ? Promettre des performances en hausse sans preuve, ça c’est du troll.



Sur la communication IPC, oui, ce sera plus rapide. Beaucoup plus.

Mais ce n’est évidemment pas la seule chose qui compte, très loin de là. Pas en 2014.



Ah bon ? La performance n’est plus importante en 2014 ? J’ai un P4HT à vendre si tu veux, il n’est performant ni en vitesse ni en consommation. <img data-src=" />

J’ai expliqué dans mes posts comment se passe une communication IPC en mémoire partagée. Alors tu affirmes, c’est bien, mais maintenant tu expliques comment faire pour aller plus vite qu’un mov adresse,donnée suivi d’un mov donnée, adresse en ASM, et en code managé s’il te plaît.





Ca fait des décennies qu’on arrive à un blocage et qu’on le repousse donc… Et, non, la loi de Moore est indépendante de la finesse de gravure : quand on ne pourra plus miniaturiser on travaillera sur la dissipation et on empilera, et finalement on se rabattra sur un autre matériau. A mon avis on en a encore pour un moment vu ce qui est dans les labos.

Par ailleurs si la loi de Moore arrivait à un obstacle il ne serait pas possible d’ajouter plus de coeurs puisque, par définition, ceux-ci nécessitent des transistors.



Tiens, lis la page sur l’effet tunnel. Même avec des atomes plus petits (carbone dans le graphène), il y a toujours des limites physiques.



Enfin si le nombre de coeurs a “stagné” (je trouve le terme fort), c’est que la demande n’allait pas dans ce sens.



Evidemment, le multi coeur ne fait pas tout (voir ci-dessus)


votre avatar



Managed code -&gt; Bytecode dans une machine virtuelle. Ce n’est pas du langage machine, c’est donc de l’interprété. Donc perte de performances.



rien que ça prouve que tu n’as rien compris au sujet. le bytecode intermédiaire est compilé en natif à l’installation. Tu n’as pas de runtime. C’est même le titre d’une présentation de james larus sur singularity





C’est pas du troll, c’est l’approbation de la démonstration de l’INpactien ; c’est positif comme attitude, non ? Promettre des performances en hausse sans preuve, ça c’est du troll.



C’est moi que tu traites de troll. J’ai des sources internes qui m’en ont parlé comme quoi Midori serait globalement deux fois plus rapide que Windows. Ce sont des benchs internes effectués par l”équipe de développeurs Midori. Effectivement je ne peux pas le prouver. Libre à toi de me croire ou pas. mais j’en fous un peu de ton opinion.



Surtout que tu me traites de trolls alors que toi pendant une période tu étais le troll numero un sur PCI. Les personnes qui étaient là doivent s’en souvenir. Moi je n’ai pas oublié. <img data-src=" />

votre avatar







CaptainDangeax a écrit :



C’est pas du troll, c’est l’approbation de la démonstration de l’INpactien ; c’est positif comme attitude, non ? Promettre des performances en hausse sans preuve, ça c’est du troll.







C’est quand même un domaine que tu connais toi-même particulièrement bien <img data-src=" />


votre avatar







CaptainDangeax a écrit :



Managed code -&gt; Bytecode dans une machine virtuelle. Ce n’est pas du langage machine, c’est donc de l’interprété. Donc perte de performances.





Perdu : dotnet est depuis le début compilé à la volée. Et dans le cas de Midori il serait pré-compilé.





Juste parce qu’on ne peut pas tout paralléliser



En effet mais pourquoi faudrait-il se concentrer sur ces scénarios en sacrifiant les autres ?





Bah non, je trouve le sujet assez fumeux comme ça : beaucoup d’affirmations et de promesses, peu de preuves…



Tu trouves fumeux un sujet dont tu ne sais rien et que tu comprends de travers d’un bout à l’autre, donc pourquoi se renseigner ? On trolle d’autant mieux qu’on demeure ignorant.





Ah bon ? La performance n’est plus importante en 2014 ? J’ai un P4HT à vendre si tu veux



D’accord mais tu me donnes tes mots de passe, tes clés et tes codes bancaires puisque la sécurité et la fiabilité ne sont pas importantes. Sans parler de la productivité plus élevée avec le code managé mais à quoi bon avoir plus de fonctionnalités à prix constant ? Et enfin question performances tu iras faire un tour du côté des serveurs faisant tourner des cohortes de VM parce que c’est le seul moyen de sécuriser.





Alors tu affirmes, c’est bien, mais maintenant tu expliques comment faire pour aller plus vite qu’un mov adresse,donnée suivi d’un mov donnée, adresse en ASM, et en code managé s’il te plaît.



En faisant exactement de la même façon, grâce aux contrats de communication vérifiables au lancement et qui permettent de lever les barrières.





Tiens, lis la page sur l’effet tunnel. Même avec des atomes plus petits (carbone dans le graphène), il y a toujours des limites physiques.



Je connais parfaitement l’effet tunnel et mon post ne prétendait pas qu’on pourrait continuer à miniaturiser à l’infini. Au contraire il faisait remarquer qu’à finesse de gravure constante on pouvait travailler sur d’autres facteurs pour accroître le nombre de transistors.





Evidemment, le multi coeur ne fait pas tout (voir ci-dessus)



C’est surtout que les piles logicielles existantes n’étaient pas scalables ou pas suffisamment.


votre avatar

Je pense qu’il faut que je précise les choses sur mes propos sur les performances. Je sens que ça va être détourné et mal interprété.



Ce sont des propos d’une de mes sources sur un papier qu’il a trouvé avec des benchmarks sur Midori. Mais il m’a juste donné une information globale. Il aurait été intéressant de savoir ce qui a été testé exactement.

Une personne plus haut a repris mes propos en expliquant que j’avais dit que M# serait deux fois plus rapide que c++. je n’ai jamais parlé du langage mais de l’OS.

De plus le résultat final peut encore changer. tout dépend comment ça va s’intégrer à Windows.



Mon propos était juste à titre informatif. Libre aux gens de me croire ou pas , je ne mens pas, je ne fais que reporter des propos.



PS: ceci dit il existe déjà un papier sur le site du MSR sur certains points qui sont testés sur Singularity comme les appels systèmes et c’est plutôt bon. Ou des tests avec la protection de ring cpu désactivé/activé et le MMU activé ou pas.

votre avatar







HarmattanBlow a écrit :



C’est tout à fait exécutable sans inférence de types, c’est même ce qui est fait à la base pour les langages à typage dynamique : chaque objet est un bête dictionnaire et pour exécuter la méthode “bidule” on recherche à chaque appel l’existence d’une clé “bidule” dans le dictionnaire de l’instance.





Tu me décris le fonctionnement d’une VM js là, pas une loi de la physique ! <img data-src=" />

Pourquoi attendrait-il le dernier moment pour aller voir dans la table des méthodes et la créer si elle n’existe pas encore ? Il pourrait très bien parser tout le script, créer toutes les méthodes nécessaires avant de commencer l’exécution…







HarmattanBlow a écrit :



Maintenant pour optimiser les navigateurs cherchent à effectivement à inférer des types. Mais que se passe t-il quand un algo assigne des paires clé/valeur à un objet dont les clés sont produites dynamiquement ? Impossible de connaître ces clés à l’avance. Donc impossible de connaître à l’avance les champs de l’objet. .





Il serait donc impossible en M# de déclarer un dico du style Dictionnary myDico; et de le remplir dynamiquement ?



votre avatar







Sebdraluorg a écrit :



Pourquoi attendrait-il le dernier moment pour aller voir dans la table des méthodes et la créer si elle n’existe pas encore ? Il pourrait très bien parser tout le script, créer toutes les méthodes nécessaires avant de commencer l’exécution…





Je crois qu’il y a un quiproquo : tu peux tout parser en avance et créer des arbres syntaxiques représentant tes méthodes, puis les compiler en utilisant des dictionnaires pour toutes tes variables.



Sauf que ce n’est pas du tout performant. Si tu veux connaître les vrais types des variables, ce n’est pas possible à la compilation pour toutes les variables puisque certaines d’entre elles se verront ajouter de nouvelles clés inconnues à la compilation, créant de facto de nouveaux types. Donc il faut exécuter pour connaître le type de certaines variables et compiler des méthodes utilisant des types précis plutôt que des dictionnaires.





Il serait donc impossible en M# de déclarer un dico du style Dictionnary myDico; et de le remplir dynamiquement ?



Mais si et j’ai du mal à comprendre le fil de ta pensée. M# n’est pas un langage dynamique et de toute façon créer un dictionnaire ne nécessite pas de générer dynamiquement du code.


votre avatar







CaptainDangeax a écrit :



De toute façon c’est du code managé, ce sera toujours moins rapide que de l’ASM et même du C correctement compilé, puisque code managé implique une certaine dose d’interprétation.

…





T’as pas l’impression de confondre langage managé (c# par exemple) et langage interpreté (js par exemple) ?







CaptainDangeax a écrit :



d’autant que la loi de Moore arrive à son terme, la limite physique du nombre d’atomes dans une jonction silicium





Loi de moore ? Faudrait pas oublier qu’elle n’a rien d’une loi, et qu’elle n’est absolument pas liée au silicium…





Loin de moi l’idée de vouloir couper les cheveux en 4 mais justement les optimisations se font à coup de % voire de pouillème de pourcent. Alors, 8% c’est juste énorme et c’est aussi ce qui contredit ton “idée reçue fausse”. L’équation est simple : communication inter process = chute des performances.



Tu passes des heures pour obtenir des optimisations de moins d’un % ? <img data-src=" />



8% c’est moins d’une génération de CPU, donc 3 fois rien !

Si tu as un SandyBridge, mon IvyBridge me permet déjà de gommer la différence !

Dans un monde ou on fait parler des process en xml y a vraiment pas de quoi ronchonner !


votre avatar







HarmattanBlow a écrit :



Je crois qu’il y a un quiproquo : tu peux tout parser en avance et créer des arbres syntaxiques représentant tes méthodes, puis les compiler en utilisant des dictionnaires pour toutes tes variables.



Sauf que ce n’est pas du tout performant. Si tu veux connaître les vrais types des variables, ce n’est pas possible à la compilation pour toutes les variables puisque certaines d’entre elles se verront ajouter de nouvelles clés inconnues à la compilation, créant de facto de nouveaux types. Donc il faut exécuter pour connaître le type de certaines variables et compiler des méthodes utilisant des types précis plutôt que des dictionnaires.





Mais si et j’ai du mal à comprendre le fil de ta pensée. M# n’est pas un langage dynamique et de toute façon créer un dictionnaire ne nécessite pas de générer dynamiquement du code.





Arf probleme de quote, je voulais dire un dico de type Dictionary(object, object)



Pour le problème de perf, ok, mais j’omettais volontairement cet aspect.

Rien que de convertir vers .NET à la volée ne me parait pas très efficace…


votre avatar







HarmattanBlow a écrit :



* La valeur de ces micro-optimisations est souvent surévaluée, de moins en moins significative, surtout par à la parallélisation, et les humains font aujourd’hui rarement mieux que les compilateurs (la vectorisation automatique devient aujourd’hui monnaie courante).







C’est globalement vrai sur l’ensemble d’un programme pour lequel le gain de l’optimisation manuel par rapport au temps passé n’en vaut vraiment pas la chandelle.



A l’inverse, au jeu de l’optimisation d’une toute petite partie de code, l’humain peut faire encore beaucoup mieux que le meilleur des compilateur dans certains cas de figure. Et pour certains logiciels dont les performances sont basées sur une petite boucle et des opérations spécifiques, cela peut parfois s’avérer très rentable.



C’est la raison pour laquelle certains programmes contiennent encore du code en assembleur sur lequel des humains ont bossé dur.



D’autant que tout n’est pas si rose du côté des compilateurs. C’est que les processeurs modernes sont très complexes et les compilateurs ont parfois du mal à tirer partie efficacement de certains instructions très spécifiques ou de certaines finesse de tel ou tel microprocesseur.



D’autres exemples, notamment en programmation parallèle montrent tout le bénéfice qu’on peut attendre d’une gestion fine de la mécanique du processeur pour (par exemple) se passer de mécanismes verrouillage “lourd” qui sont coûteux en temps.





Ca ne me semble pas significatif : on accède rarement à un élément de façon isolé. En général c’est toujours suivi par l’accès à davantage d’éléments (que ce soit aléatoire ou séquentiel), donc le cache miss ne sera que sur le premier élément.



Quant aux scénarios où ce n’est pas le cas, quels sont-ils ? Ceux où le tableau n’a qu’un élément, mais dans ce cas la ligne de cache contient à la fois l’élément et la taille. Et ceux où l’accès à l’élément est suivi de traitements lourds, si bien que cet accès est rare et donc peu significatif.





C’est pourtant bien le cas dans certains algorithmes.



En plus, ça n’est pas très compliqué : il suffit de combiner des structures nombreuses et disséminées et un accès aléatoire. Et pas besoin d’avoir des structures très volumineuses pour que le “prefetch” n’assure pas en même temps le chargement de la borne et de la donnée.



Et même dans le cas contraire, pour aussi rares qu’ils puissent paraître, les “cache miss” sont tellement coûteux qu’une bonne partie des techniques d’optimisation sur processeur modernes consistent à tout faire pour les minimiser.



Le “cache miss” est véritablement le cauchemar des architectes de processeur modernes. Le grain de sable qui conduit des millions de transistors à se tourner les pouces pendant des dizaines de cycles en attendant l’arrivée des données.



Le vrai problème, c’est que malgré tout ce que peuvent dire les uns et les autres, il est très difficile de quantifier par avance l’impact réel dans les programmes réels (par exemple, un gros SGBD).



Etant donné qu’il faudra des années pour que les éditeurs tierce partie portent leurs logiciels sur cette architecture et encore plus pour avoir les remontées, il faudra donc attendre un certain nombre d’années pour cerner véritablement les avantages et inconvénients pratiques de l’idée.









votre avatar







sr17 a écrit :



Et pour certains logiciels dont les performances sont basées sur une petite boucle et des opérations spécifiques, cela peut parfois s’avérer très rentable.





On peut toujours trouver quelques cas mais c’est beaucoup moins fréquent qu’avant : avant les performances d’un jeu dépendaient avant tout de telle petite partie du code, aujourd’hui c’est beaucoup plus souvent l’ensemble parce que les programmes ont grandi.



Et de toute façon quand l’assembleur permet d’obtenir des gains significatifs c’est soit grâce à un micro-management de la synchronisation (barrières mémoires, atomiques, etc) soit grâce à la vectorisation. Or les deux peuvent être exposés. Par exemple d’après ce qu’a écrit Duffy dans un ancien post de blog, je m’attends à ce que la plus fine granularité soit exposée concernant les barrières mémoires, en partant du principe que 1% des dévs en auront besoin et que ceux-là peuvent gérer la complexité correspondante.


votre avatar



En plus, ça n’est pas très compliqué : il suffit de combiner des structures nombreuses et disséminées et un accès aléatoire.



Tu peux toujours sortir quelques structures de données où l’on accède à un seul élément d’un tableau (ex : un dico dont l’index du tableau racine est donné par les premiers bits du hash code). Mais ça reste l’exception plutôt que la règle : en général quand on accède à un tableau c’est pour en lire de nombreux éléments et la taille reste en cache (rien à voir avec le prefetch).

votre avatar







charon.G a écrit :



Même si j’ai pas le droit d’en parler ils sont beaucoup plus avancés que tu le penses.





<img data-src=" /><img data-src=" />


votre avatar







HarmattanBlow a écrit :



Pas avec Midori. Ou alors avec du C++ modifié ou emballé dans une VM. Mais par définition Midori ne peut exécuter que du code vérifiable, ce qui n’est pas le cas du C++.





Dans un monde (vraiment) multi-threadé, il n’y a pas grand chose de vérifiable actuellement. En l’occurrence, cela ne dépend de toute façon pas vraiment du langage utilisé, mais de la modélisation. Outre ce fait, on est jamais à l’abri d’une spec fausse. Il faut également que le compilateur soit vérifié (y compris les optimisations) pour garantir que l’ensemble marche.

(Par ailleurs, un code utilisant des pointeurs intelligents simples - comprendre : pas de GC en thread séparé, ni différé dans le temps - est très efficace en terme de gestion mémoire et pas plus compliqué).

Tout ce que j’espère de ce langage c’est qu’il ne sera pas full-proprio.


votre avatar







Mr.Nox a écrit :



Voilà pourquoi j’aime pci ! Pas pour les les news Apple pu ça se tire dessus à coups de mauvaise foi bien puante mais pour les news techniques de de se genre.





Ouaip, pareil.

Merci PCI pour cet article de qualité et sur la contribution de tous les commentateurs !


votre avatar

Au début je pensais aussi la même chose qu’harmattanblow :que le c++ ne marcherait plus sur Midori. Mais j’ai pu lire des brevets et certaines lectures qui m’ont fait changé d’avis.



Microsoft mise toujours sur le c++

Le but de WinRT était de mettre au même niveau tous les langages. Avant si on codais en C++ ,on ne profitait pas des mêmes api qu’en codant en .NET



Avec WinRT le framework est uniforme pour tous les langages.

.

En effet Windows est un os first class c++ et Midori un os first class M# mais le C++ devrait subsister.



De nombreux projets sont écrits en C++. Ca reste plus simple de porter le projet sur WinRT (surtout pour les projets multi) que de complètement tout réécrire en M#



Au final seuls les développeurs systèmes devront coder en M#. mais vu les gains en terme de rapidité de développement et de fiabilité, je doute que ce soit un problème.

votre avatar







John Shaft a écrit :



Je connais un dév bi-classé Lisp/Java, tu le classes comment ? (et qui se sert encore du Lisp) <img data-src=" />





Quel que soit le sens dans lequel tu le prends: un masochiste. <img data-src=" />


votre avatar







charon.G a écrit :



Au début je pensais aussi la même chose qu’harmattanblow :que le c++ ne marcherait plus sur Midori. Mais j’ai pu lire des brevets et certaines lectures qui m’ont fait changé d’avis.





Ils n’ont pas le choix : s’ils interdisent l’utilisation des langages les plus utilisés par les devs, leur OS est mort-né. Même Apple n’a pas osé sur iOS.


votre avatar







ldesnogu a écrit :



Ils n’ont pas le choix : s’ils interdisent l’utilisation des langages les plus utilisés par les devs, leur OS est mort-né. Même Apple n’a pas osé sur iOS.





Tout a fait


votre avatar

Il existe bien le c++ CLI, ça sera peut être la même chose sur Midori.

votre avatar







Ksass`Peuk a écrit :



Dans un monde (vraiment) multi-threadé, il n’y a pas grand chose de vérifiable actuellement.





Il faut entendre “vérifiable” de façon contextuelle. Ici on appelle en substance vérifiable un code dont on est sûr qu’il ne pourra pas écrire ailleurs que dans ses propres pages mémoire de données et qu’il n’exécutera pas certaines instructions CPU. Quand ces conditions sont garanties on peut le faire tourner en ring 0 sans risques de le voir compromettre un autre processus ou le noyau, ou de violer ses privilèges d’accès.



Le processus est libre de se deadlocker et d’oublier de nettoyer sa mémoire, peu importe, ça ne fait pas partie du contrat à vérifier puisque le système sait de toute façon faire face à ces événements s’ils devaient survenir.



Une telle vérification est liée au langage. Le C++ ne peut pas être vérifié à cause de des pointeurs pseudonymes, de l’asm et peut-être d’une ou deux autres choses. Le C#, lui, peut être vérifié.







charon.G a écrit :



Au début je pensais aussi la même chose qu’harmattanblow :que le c++ ne marcherait plus sur Midori. Mais j’ai pu lire des brevets et certaines lectures qui m’ont fait changé d’avis.





Je n’ai jamais dit que le C++ ne fonctionnerait plus et je regrette mais je n’ai pas le temps de regarder des vidéos promotionnelles d’une heure ou de consulter des centaines de brevets. Je t’invite à me dire en une phrase ce dont il s’agit. Mais trouver un moyen pour faire tourner les applis traditionnelles n’a rien de sorcier, le problème c’est que ce n’est pas gratuit, qu’il s’agisse de virtualisation ou de maintien d’une archi traditionnelle avec ring3 pour ces vieilles applis.







youtpout978 a écrit :



Il existe bien le c++ CLI, ça sera peut être la même chose sur Midori.





Il peut y avoir un C++ dédié pour crées des applis Midori, comme le C++ CLI. Mais à part ça il y a aussi la question de savoir si oui ou non ils cherchent à maintenir la compatibilité avec les applis existantes. Ce qui encore une fois ne serait pas gratuit.


votre avatar







youtpout978 a écrit :



Il existe bien le c++ CLI, ça sera peut être la même chose sur Midori.





C++ cli c’est une adaptation du C++ en managé par Microsoft. C’était vu comme un langage transitoire pour passer à C# , ça n’a jamais marché.

J’ai cité un propos d’aleks bromfield plus haut qui explique bien que le modèle applicatif ne change pas. Avec WinRT on peut coder dans tous les langages. C’était le but


votre avatar

J’espère que Microsoft mènera a bien ce projet, et pourra sortir une version commerciale assez rapidement.

Pourquoi ?



Actuellement, il y a trois acteurs majeurs : Apple, Google et Microsoft.

Ce dernier serait le premier à sortir un OS “next-gen”.

Google et Apple travaillent aussi certainement sur ce type de projet, mais je pense qu’ils sont à un stade beaucoup moins avancé (Google part sur les réseaux sociaux, les robots, voitures etc.., Apple sur le prochain gadget révolutionnaire ?).



Vu les avantages supposés avec Midori, cela pourrait relancer Microsoft au premier plan avec :




  • un OS très performant : (ne me dites pas que Androïd est performant …)

  • une sécurité assurée du noyau et la fin du winrot

  • Une rétrop compatibilité assurée, peut-être avec même les très anciennes de Windows ? J’avais cru avoir lu un article qui parlait de ça (Bartok ?)



    Bref, à terme cela pourrait casser le WinDaube que tout le monde aime prononcer. Car à vrai dire, combien de personnes voient plus d’écrans bleus en comparaison du nombre de reboot/freeze de leurs téléphones/tablettes ?



votre avatar







charon.G a écrit :



Au début je pensais aussi la même chose qu’harmattanblow :que le c++ ne marcherait plus sur Midori. Mais j’ai pu lire des brevets et certaines lectures qui m’ont fait changé d’avis.





T’as des liens vers ces brevets? Parce que jusqu’à présent quand je te lis j’ai plus l’impression de lire un fanboy sans esprit critique qui croit tout ce que lui dit le grand Microsoft que quelqu’un de vraiment raisonné.

Un peu de sources sur tes dires serait bienvenu (et permettrait de mettre tout le monde à niveau). Comme le dit HarmattanBlow, on a pas tous le temps de faire un veille exhaustive.


votre avatar







HarmattanBlow a écrit :



Il faut entendre “vérifiable” de façon contextuelle. Ici on appelle en substance vérifiable un code dont on est sûr qu’il ne pourra pas écrire ailleurs que dans ses propres pages mémoire de données et qu’il n’exécutera pas certaines instructions CPU. Quand ces conditions sont garanties on peut le faire tourner en ring 0 sans risques de le voir compromettre un autre processus ou le noyau, ou de violer ses privilèges d’accès.



Le processus est libre de se deadlocker et d’oublier de nettoyer sa mémoire, peu importe, ça ne fait pas partie du contrat à vérifier puisque le système sait de toute façon faire face à ces événements s’ils devaient survenir.



Une telle vérification est liée au langage. Le C++ ne peut pas être vérifié à cause de des pointeurs pseudonymes, de l’asm et peut-être d’une ou deux autres choses. Le C#, lui, peut être vérifié.





Je n’ai jamais dit que le C++ ne fonctionnerait plus et je regrette mais je n’ai pas le temps de regarder des vidéos promotionnelles d’une heure ou de consulter des centaines de brevets. Je t’invite à me dire en une phrase ce dont il s’agit. Mais trouver un moyen pour faire tourner les applis traditionnelles n’a rien de sorcier, le problème c’est que ce n’est pas gratuit, qu’il s’agisse de virtualisation ou de maintien d’une archi traditionnelle avec ring3 pour ces vieilles applis.





Il peut y avoir un C++ dédié pour crées des applis Midori, comme le C++ CLI. Mais à part ça il y a aussi la question de savoir si oui ou non ils cherchent à maintenir la compatibilité avec les applis existantes. Ce qui encore une fois ne serait pas gratuit.





Commentaire 94:

Les applications C++ WinRT tournent dans une sandbox. La sécurité et la fiabilité est donc assurée. Les api de WinRT sont déjà type safes.



Voilà ce qui se passe si tu communiques un pointeur dans une api winRT


votre avatar







Shyfer a écrit :



Bref, à terme cela pourrait casser le WinDaube que tout le monde aime prononcer.







AMHA ce terme est surtout utilisé par des personnes de mauvaise foi… Windows est actuellement très stable. Ou du moins il ne l’est pas moins que ses concurrents. Depuis Windows 7 (j’ai quasiment sauté Vista) j’ai vu plus de kernel panic sur une distrib Linux que d’écrans bleus ou redémarrages intempestifs sous Windows…



Donc ca ne cassera pas Windaube… Certaines personnes se croient intelligentes à placer ce terme sur n’importe quel sujet traitant de près ou de loin le sujet des OS…





Et puis je pense qu’on est encore loin d’un changement radical pour l’OS desktop.


votre avatar







Khalev a écrit :



T’as des liens vers ces brevets? Parce que jusqu’à présent quand je te lis j’ai plus l’impression de lire un fanboy sans esprit critique qui croit tout ce que lui dit le grand Microsoft que quelqu’un de vraiment raisonné.

Un peu de sources sur tes dires serait bienvenu (et permettrait de mettre tout le monde à niveau). Comme le dit HarmattanBlow, on a pas tous le temps de faire un veille exhaustive.





J’ai source des tweet de gens de Midori qui l’expliquent. Tu as aussi un lien dans mon précedent commentaire.

Pour le brevet il s’agissait de faire tourner des applis natives sur un os safe en passant par un module qui vérifiaient les données communiquées. ca ressemblait fortement à WinRT.

Ce brevet je l’ai vu en 2009 ou 2010 et je ne garde pas tous les liens que je lis. Je m’en fous un peu que tu ne me crois pas. Surtout quand on me traite de fan boy pour me discréditer. <img data-src=" />


votre avatar







HarmattanBlow a écrit :



Je n’ai jamais dit que le C++ ne fonctionnerait plus et je regrette mais je n’ai pas le temps de regarder des vidéos promotionnelles d’une heure ou de consulter des centaines de brevets. Je t’invite à me dire en une phrase ce dont il s’agit. Mais trouver un moyen pour faire tourner les applis traditionnelles n’a rien de sorcier, le problème c’est que ce n’est pas gratuit, qu’il s’agisse de virtualisation ou de maintien d’une archi traditionnelle avec ring3 pour ces vieilles applis.





Il peut y avoir un C++ dédié pour crées des applis Midori, comme le C++ CLI. Mais à part ça il y a aussi la question de savoir si oui ou non ils cherchent à maintenir la compatibilité avec les applis existantes. Ce qui encore une fois ne serait pas gratuit.





Tu fais de la mauvaise foi? voilà ce que tu as ecrit:





Pas avec Midori. Ou alors avec du C++ modifié ou emballé dans une VM. Mais par définition Midori ne peut exécuter que du code vérifiable, ce qui n’est pas le cas du C++.


votre avatar

Je pense que ce brevet de galen hunt devrait plus répondre à ta question:

http://www.freepatentsonline.com/7882317.pdf



Dans ce brevet Microsoft envisage d’utiliser les ring du cpu et donc l’isolation matérielle pour avoir la délimitation kernel/user mode. La différence par rapport à Windows est que les “process” qui tournent en kernel mode sont isolés logiciellement par des SIP.

C’est une sorte de compromis entre l’isolation matérielle et logicielle et ça devrait résoudre le problème que tu as mis en valeur plus haut.

votre avatar







Kurian a écrit :



Que viens faire Roslyn dans l’histoire ? Juste un projet annexe ou c’est lié ?





quand Unix a été crée ils ont crée le langage C. Les nouveaux OS s’accompagnent généralement par des changements importants au niveau des compilateurs et des langages.



La on entend parler de roslyn ou project N et redhawk/MRT. A mon avis ça suit bien un but précis.


votre avatar

Quand vous dites SIP c’est : Session Initiation Protocol O_o ?

votre avatar







HarmattanBlow a écrit :



Il faut entendre “vérifiable” de façon contextuelle.

[…]

Le C++ ne peut pas être vérifié à cause de des pointeurs pseudonymes, de l’asm et peut-être d’une ou deux autres choses.





Mince, ma vie est un mensonge.


votre avatar







Kurian a écrit :



Quand vous dites SIP c’est : Session Initiation Protocol O_o ?





Software Isolated Process:

Ce sont les processus qui tournent sur les os Singularity/Midori. Mais les drivers tournent aussi dans des SIP.


votre avatar

Ces SIP sont cencés êtres plus performants que l’utilisation du ring 3 des processeurs c’est ça ?

votre avatar







Kurian a écrit :



Ces SIP sont cencés êtres plus performants que l’utilisation du ring 3 des processeurs c’est ça ?





Oui l’isolation matérielle est beaucoup plus coûteuse en performances.


votre avatar

question débiles en fait : a supprimer

votre avatar

L’isolation logicielle se fait au niveau du compilateur qui à la fin vérifie que le code généré soit bien vérifiable et qu’une adresse mémoire n’aille pas pointer sur un autre SIP.C’est une isolation par le langage. Harmattanblow a parlé plus haut de ce point.

votre avatar







Kurian a écrit :



question débiles en fait : a supprimer





J’ai jamais programmé en ARM mais apparemment l’équivalent existe.

Voir ici


votre avatar



Oui l’isolation matérielle est beaucoup plus coûteuse en performances.





hheeuuu ???? depuis quand ?





L’isolation logicielle se fait au niveau du compilateur qui à la fin vérifie que le code généré soit bien vérifiable et qu’une adresse mémoire n’aille pas pointer sur un autre SIP.C’est une isolation par le langage. Harmattanblow a parlé plus haut de ce point.





Ça a déjà beaucoup plus de sens ! Donc en clair, il n’y a PAS d’isolation.

Maintenant la question qui fache… qui maitrise le compilateur ?



Pärce que dans l’ère “je m’appelle nsa me faites pas chier”, ça veut dire “j’ai tour les droits, et tu n’as AUCUN moyen de controller ni vérifier quoi que ce soit, ni même de t’en proteger”



Moyen quand même comme concept…

votre avatar







moi1392 a écrit :



Ça a déjà beaucoup plus de sens ! Donc en clair, il ,‘y a PAS d’isolation.

Maintenant la question qui fache… qui maitrise le compilateur ?







Bha toi avec Roslyn et les nouvelles fonctionnalités ?


votre avatar







moi1392 a écrit :



hheeuuu ???? depuis quand ?







Ça a déjà beaucoup plus de sens ! Donc en clair, pas d’isolation.

Maintenant la question qui fache… qui maitrise le compilateur ?





Si il y en a une vu que tout ce qui tourne en kernel mode est du code vérifiable.

Pour le compilateur il n’a pas besoin d’être trusté. Bartok avant de de générer du code natif génère du Typed Assembly language(TAL) , une sorte de pseudo code assembleur vérifiable. Le compilateur est compilé du TAL de mémoire.

Je crois que ce pdf l’évoque:

http://www.cs.cornell.edu/~ross/publications/italx/Tate-PLDI10.pptx





no need to trust the compiler


votre avatar







moi1392 a écrit :



Ça a déjà beaucoup plus de sens ! Donc en clair, il n’y a PAS d’isolation.

Maintenant la question qui fache… qui maitrise le compilateur ?



Pärce que dans l’ère “je m’appelle nsa me faites pas chier”, ça veut dire “j’ai tour les droits, et tu n’as AUCUN moyen de controller ni vérifier quoi que ce soit, ni même de t’en proteger”



Moyen quand même comme concept…





<img data-src=" /> N’en change pas c’est de la bonne !!! :facepalm:


votre avatar





Si il y en a une vu que tout ce qui tourne en kernel mode est du code vérifiable.





non il n’y en pas pas vu que la compote de pomme est trop sucrée et que les avions nagent à contre courant… -_-





Pour le compilateur il est dans la trusted base. Bartok avant de de générer du code natif génère du Typed Assembly language(TAL) , une sorte de pseudo code assembleur vérifiable. Le compilateur est compilé du TAL de mémoire.





je répète donc ma remarque, personne n’a de maitrise sur la chaine de compilation, et c’est à elle qu’il faut faire confiance pour la sécurité de l’os…

je vais le dire autrement…

“Ma maison est sure car les clés m’ont été données par l’ancien propriétaire et je n’ai aucun moyen de changer la serrure ni mettre d’alarme chez moi sans lui demander et qu’il l’installe lui même”

C’est une blague ???

votre avatar



N’en change pas c’est de la bonne !!!





C’est tout ce que tu as comme argumentation pour ta réponse ??

J’en conclue que tu es d’accord avec moi ?

votre avatar







Sebdraluorg a écrit :





  1. Qui a parlé de coder un OS ?





    Pour etre plus précis dans ma réponse à l’époque du projet Singularity (et de sa présentation au TechDays 2008) les chiffres etait

    Micronoyau sûr



    • 95 % écrit en C#

    • 17 % des fichiers contient du C# unsafe

    • 5 % des fichiers contient de l’asm X86 ou du C++



votre avatar







HarmattanBlow a écrit :



puis un patch à la volée parce qu’il n’est pas possible de compiler entièrement le javascript faute d’informations sur le typage, celui-ci n’étant entièrement connu qu’à l’exécution. Et comme il faut partager les données mieux vaut avoir un seul SIP par page plutôt qu’un SIP par fonction !





Ah bon ? Certain de ça ?

S’il est exécuté c’est qu’il a été interpreté et même compilé dans le cas d’IE si je ne m’abuse…



Mais bon, dans tous les cas il suffit de remplacer le js par un js SharpéMidoriséSingularisé… <img data-src=" />



votre avatar







Sebdraluorg a écrit :



Ah bon ? Certain de ça ?

S’il est exécuté c’est qu’il a été interpreté et même compilé dans le cas d’IE si je ne m’abuse…





Au moment où le code JS essaie d’appeler la fonction Bidule avec un argument du type Truc, la VM cherche le code compilé pour la fonction Bidule avec ce type précis d’argument. Si ce code compilé n’est pas disponible, alors elle le génère puis ellle l’exécute.



C’est au moment de l’exécuter qu’on sait avec quels types une fonction est appelée et qu’on peut la compiler, puis l’exécuter. Ou, si elle a déjà été compilée pour ce type précis d’argument, l’exécuter directement.



Et, non, Truc n’est jamais déclaré en Javascript. C’est un type inféré à l’exécution par la VM. Et si tu trouves que tout ça est compliqué, ça l’est : la compilation d’un code dynamique est un des trucs les plus tordus que je connaisse. Et pourtant j’en connais.


votre avatar







arno53 a écrit :



Pour etre plus précis dans ma réponse à l’époque du projet Singularity (et de sa présentation au TechDays 2008) les chiffres etait





Euh, hier je me demandais pourquoi tu m’avais cité, je me disais que tu t’étais trompé de comm, mais vu que tu en remets une couche, j’imagine que c’est donc bien à moi que tu parles… :-)



Je sais tout ce que tu m’as dit, je répondais juste à un commentaire d’un fou furieux :



Aucun de vous n’y connais strictement rien en programmation c’est bien là le problème, et c’est pas en justifiant des âneries que n’importe qu’elle expert utilisera à vos dépends …



1- Il y a encore des gens qui doutent de l’utilité de l’assembleur pour écrire un OS ?



Alors qu’on n’avait absolument pas évoqué cet aspect dans les commentaire à ce moment là…



votre avatar







HarmattanBlow a écrit :



Au moment où le code JS essaie d’appeler la fonction Bidule avec un argument du type Truc, la VM cherche le code compilé pour la fonction Bidule avec ce type précis d’argument. Si ce code compilé n’est pas disponible, alors elle le génère puis ellle l’exécute.



C’est au moment de l’exécuter qu’on sait avec quels types une fonction est appelée et qu’on peut la compiler, puis l’exécuter. Ou, si elle a déjà été compilée pour ce type précis d’argument, l’exécuter directement.



Et, non, Truc n’est jamais déclaré en Javascript. C’est un type inféré à l’exécution par la VM.





Euh bin la simple analyse du code devrait permettre de déterminer tous les types qui vont être utilisés, il ne sont pas typés explicitement, mais c’est determinable sinon ce ne serait même pas executable….



Désolé si je me méprend sur le problème, le js ça remonte à loin pour moi et je ne me suis jamais pencher sur le fonctionnement interne..





votre avatar







Sebdraluorg a écrit :



Euh, hier je me demandais pourquoi tu m’avais cité, je me disais que tu t’étais trompé de comm, mais vu que tu en remets une couche, j’imagine que c’est donc bien à moi que tu parles… :-)



Je sais tout ce que tu m’as dit, je répondais juste à un commentaire d’un fou furieux :



Alors qu’on n’avait absolument pas évoqué cet aspect dans les commentaire à ce moment là…





Le commentaire du fou furieux tout le monde l’a vu oui <img data-src=" />



Je croyais que tu doutais du fait que Midori puisse être principalement écrit avec du code managé (M#). Toute mes confuse <img data-src=" />


votre avatar

Sinon pour le javascript il existe ce projet :

research.microsoft.com MicrosoftSPUR compile le code javascript en .net. Même si une partie utilise bartok c’est de la compilation JIT donc ça ne répond pas au problème posé avec midori.

votre avatar







arno53 a écrit :



Le commentaire du fou furieux tout le monde l’a vu oui <img data-src=" />



Je croyais que tu doutais du fait que Midori puisse être principalement écrit avec du code managé (M#). Toute mes confuse <img data-src=" />





Ok, il y avait bien confusion, ça me rassure <img data-src=" />



<img data-src=" />


votre avatar







charon.G a écrit :



Sinon pour le javascript il existe ce projet :

research.microsoft.com MicrosoftSPUR compile le code javascript en .net. Même si une partie utilise bartok c’est de la compilation JIT donc ça ne répond pas au problème posé avec midori.





Si c’est convertible en .NET, c’est de fait convertible en langage intermédiaire pour Midori non ? A ce niveau ce n’est plus qu’une formalité il me semble…


votre avatar







Sebdraluorg a écrit :



Si c’est convertible en .NET, c’est de fait convertible en langage intermédiaire pour Midori non ? A ce niveau ce n’est plus qu’une formalité il me semble…





Comme expliqué précédemment la compilation JIT n’est pas possible à la base sur Midori(enfin il doit exister une méthode mais elle n’est pas encore connue, harmattanblow a proposé quelques idées) parce que le code des SIP est scellé en mémoire à l’exécution.

Une partie du code .net généré par SPUR est crée en compilation JIT à l’exécution.


votre avatar







charon.G a écrit :



Comme expliqué précédemment la compilation JIT n’est pas possible à la base sur Midori(enfin il doit exister une méthode mais elle n’est pas encore connue, harmattanblow a proposé quelques idées) parce que le code des SIP est scellé en mémoire à l’exécution.

Une partie du code .net généré par SPUR est crée en compilation JIT à l’exécution.





Wep, j’ai bien lu ce que disait harmattanblow, mais visiblement quelques chose m’échappe… <img data-src=" />



J’ai pas lu le pdf du projet, mais tu dis qu’il passe de js à .Net, tu veux dire quoi au juste par .Net ?



Si tu peux aller de js vers .NET (et donc typé) il n’y a plus d’obstacle pour faire un “patch” à la volée, si ?


votre avatar

Quelques objections qu’on ne peut pas malheureusement pas balayer d’un revers de main parce qu’un tel système restreindra de fait l’usage de certains optimisations :



-Les performances de certains logiciels reposent sur des morceaux de code assez courts, mais écrits directement en assembleur (Video, traitement d’image, chiffrement, etc). Même si ces optimisations concernent une portion marginale du code d’une minorité de programmes, l’impact final sur l’ensemble peut ne pas être négligeable.



-Une des optimisation très utilisée avec le C++ consiste à écrire des gestionnaires de mémoire spécialisés pour chaque tâche critique. Malheureusement, aucun “garbage collector” généraliste, aussi bon soit t’il ne peut rivaliser avec de telles stratégies spécifiques.



-Le système aura l’avantage d’éliminer les “context switch”, donc de permettre un gain de performance sur du code “managé”. Mais il y a un revers de la médaille : un simple accès à un élément d’un tableau peut se traduire par deux “cache miss” au lieu d’un à cause du bornage. Or, les accès mémoires sont l’un des facteurs limitant des processeurs modernes, bien plus que le coût des “context switch”. C’est particulièrement valable dans un environnement multicore.



Ma conclusion sur la question, c’est qu’on en saura plus sur l’opportunité de cette nouvelle architecture d’OS quand les éditeurs tiers porteront leurs logiciels dessus et que se dessineront les avantages et les défauts pratiques de l’idée.

votre avatar

C’est histoire de proposer un langage rapide avec un développement qui requiert moins de temps.



Donc une histoire de pognon et de manque d’expertise aussi.



Je bosse dans une boite une le chargé de recrutement m’avait lâché le morceau : “Aujourd’hui il est devenu très difficile voir miraculeux de trouver des experts en Assembleur +15.”.



Évidement le salaire s’en ressent <img data-src=" />



Le fait d’imaginer des idées de briscard pour diviser un temps de calcul par 10, n’est apparemment pas chose commune.



Cependant M# semble atteindre un bon compromis. Reste a voir ses domaines d’applications ;)

votre avatar







Zimt a écrit :



C’est histoire de proposer un langage rapide avec un développement qui requiert moins de temps.



Donc une histoire de pognon et de manque d’expertise aussi.



Je bosse dans une boite une le chargé de recrutement m’avait lâché le morceau : “Aujourd’hui il est devenu très difficile voir miraculeux de trouver des experts en Assembleur +15.”.



Évidement le salaire s’en ressent <img data-src=" />



Le fait d’imaginer des idées de briscard pour diviser un temps de calcul par 10, n’est apparemment pas chose commune.



Cependant M# semble atteindre un bon compromis. Reste a voir ses domaines d’applications ;)







Comme dans tout domaine, l’élite est rare et se fait payer cher.



Ce qui n’empêche pas des millions de personnes d’utiliser leurs programmes parce qu’ils sont performants.









votre avatar







Sebdraluorg a écrit :



Euh bin la simple analyse du code devrait permettre de déterminer tous les types qui vont être utilisés, il ne sont pas typés explicitement, mais c’est determinable sinon ce ne serait même pas executable….





C’est tout à fait exécutable sans inférence de types, c’est même ce qui est fait à la base pour les langages à typage dynamique : chaque objet est un bête dictionnaire et pour exécuter la méthode “bidule” on recherche à chaque appel l’existence d’une clé “bidule” dans le dictionnaire de l’instance.



Maintenant pour optimiser les navigateurs cherchent à effectivement à inférer des types. Mais que se passe t-il quand un algo assigne des paires clé/valeur à un objet dont les clés sont produites dynamiquement ? Impossible de connaître ces clés à l’avance. Donc impossible de connaître à l’avance les champs de l’objet.



C’est un des nombreux problèmes de compilation à la volée de javascript. Certains types ne peuvent connus qu’à l’exécution. Et pour d’autres le coût de l’inférence statique serait tout simplement trop élevé.







sr17 a écrit :



Quelques objections qu’on ne peut pas malheureusement pas balayer d’un revers de main parce qu’un tel système restreindra de fait l’usage de certains optimisations





Oui, je suis le premier à dire qu’il y aura une perte.



Cela dit :

* La valeur de ces micro-optimisations est souvent surévaluée, de moins en moins significative, surtout par à la parallélisation, et les humains font aujourd’hui rarement mieux que les compilateurs (la vectorisation automatique devient aujourd’hui monnaie courante).



* Il y aura des gains par ailleurs : la suppression de la mémoire virtuelle c’est un gros cadeau pour les performances.





Le système aura l’avantage d’éliminer les “context switch”, donc de permettre un gain de performance sur du code “managé”.



Pourquoi seulement sur le code managé ?





Mais il y a un revers de la médaille : un simple accès à un élément d’un tableau peut se traduire par deux “cache miss” au lieu d’un à cause du bornage. Or, les accès mémoires sont l’un des facteurs limitant des processeurs modernes, bien plus que le coût des “context switch”.



Ca ne me semble pas significatif : on accède rarement à un élément de façon isolé. En général c’est toujours suivi par l’accès à davantage d’éléments (que ce soit aléatoire ou séquentiel), donc le cache miss ne sera que sur le premier élément.



Quant aux scénarios où ce n’est pas le cas, quels sont-ils ? Ceux où le tableau n’a qu’un élément, mais dans ce cas la ligne de cache contient à la fois l’élément et la taille. Et ceux où l’accès à l’élément est suivi de traitements lourds, si bien que cet accès est rare et donc peu significatif.







Zimt a écrit :



C’est histoire de proposer un langage rapide avec un développement qui requiert moins de temps.





Ca ne me semble pas tellement significatif par rapport au impératifs de sécurité et aux évolutions matérielles (many-core notamment).


votre avatar







sr17 a écrit :



-Une des optimisation très utilisée avec le C++ consiste à écrire des gestionnaires de mémoire spécialisés pour chaque tâche critique. Malheureusement, aucun “garbage collector” généraliste, aussi bon soit t’il ne peut rivaliser avec de telles stratégies spécifiques.





Apparemment, la gestion de la mémoire à travers le langage n’est pas un GC à proprement parler mais est plus proche de la RAII telle qu’on l’applique en C++, donc de ce côté, il reste à savoir si le compilo est plus friand de unique_ptr (victory) ou shared_ptr (fail).


votre avatar







Mr.Nox a écrit :



Voilà pourquoi j’aime pci ! Pas pour les les news Apple pu ça se tire dessus à coups de mauvaise foi bien puante mais pour les news techniques de de se genre.





Ca ressemble a bien des annonces que j’ai vu depuis mon enfance dans ce domaine…



L’idée n’est pas forcement mauvaise, mais ça tourne au tragicomique avec Snowden… Avoir une si belle structure safe de tout les cotés noyauté de l’intérieur…. (c’est valable pour apple aussi).


votre avatar







Mr.Nox a écrit :



Voilà pourquoi j’aime pci ! Pas pour les les news Apple pu ça se tire dessus à coups de mauvaise foi bien puante mais pour les news techniques de de se genre.





Bouef, y’a toujours un connard à boût d’argument qui te traitera de troll…



En tout cas moi j’ai investi plusieurs années d’avance dans PCI mais si la communauté continue à traiter les gens de trolls à tout bout de champ, je continuerai à me taire et je ne mettrai pas un centime de plus… <img data-src=" />


votre avatar







brazomyna a écrit :



Ce à quoi papy Cobol aurait répondu “moi d’abord !” <img data-src=" />





Juger l’âge d’un dév en se basant sur le langage qu’il utilise, tsss <img data-src=" />


votre avatar







arno53 a écrit :



Les entreprises auront toujours besoin d’un OS pour la bureautique/développement/dessin. Je vois mal Microsoft laisser ce marcher à une distrib Linux …



Windows et Win32 peuvent encore durer 10 ans mais bon le petit noyau NT aimerait bien profiter de la retraite aussi <img data-src=" />



Et Terry Myerson (vu les papiers ecrit par thurrott) a l’air d’avoir une bonne vision pour l’avenir : 1 coeur, plusieurs interface adapté … Le fait de pouvoir faire prochainement tourner des applis WinRT sur le Bureau est de bonne augure pour un Midori Desktop.



Mais les devices connecté et les serveurs seront sans doutes leur priorité en effet.





Oui Terry Myerson a l’air d’avoir une bonne vision. Wait and see…


votre avatar







wanou2 a écrit :



Je suppose que ton paragraphe préféré était celui là :







Ce remuage de couteau dans la plaie ! <img data-src=" />



<img data-src=" />


votre avatar







Latios a écrit :



<img data-src=" />



(pardon aux familles tout ça <img data-src=" />)







Je connais un dév bi-classé Lisp/Java, tu le classes comment ? (et qui se sert encore du Lisp) <img data-src=" />


votre avatar







John Shaft a écrit :



Je connais un dév bi-classé Lisp/Java, tu le classes comment ? (et qui se sert encore du Lisp) <img data-src=" />





Difficile à dire <img data-src=" />


votre avatar

A vous lire, ça va vouloir dire changement de terminale de windows phone 8 à 9. <img data-src=" />

votre avatar







charon.G a écrit :



En fait la news en parle,c’est que j’avais prédis à l’époque dans le dossier sur Windows 8. WinRT a été conçu pour tourner au dessus de Midori.

Pour Win32 il y a drawbridge.





Pas con. Et ça justifierait pas mal la prise de risque avec WinRT.


votre avatar







metaphore54 a écrit :



A vous lire, ça va vouloir dire changement de terminale de windows phone 8 à 9. <img data-src=" />







Peut etre pas dans la mesure ou Midori serait capable de faire tourner les pilotes de windows … Et quand bien même ca arriverai




  • de 1) ca serait techniquement plus justifiable (changement de noyau) que ce qui se fait chez la concurrence (Android et la MaJ a 500€ ^^)…

  • de 2) l’important ce sont surtout les applications … Et comme dit dans la News le socle WinRT est fait pour exister à la fois sur Windows et sur Midori… De ce fait les nouvelles applications cibleraient des API disponible sur les 2 platforme et non un noyau en particulier.



    Bon apres il faudrait que MS joue vraiment le jeux en faisant évoluer le socle WinRT sur NT et Midori pendant le temps de la transition (2 ans c’est largement suffisant pour un environnement smartphone/tablette) et pas comme Android où les API sont vraiment dépendante de la version …


votre avatar

Midori open source ? Ce serait un très grand progrès <img data-src=" /> et en même temps une menace pour linux <img data-src=" />



Dommage je pourrais plus dire “le proprio c’est le mal” <img data-src=" /> comme j’aime bien le faire <img data-src=" />

votre avatar

Je pense que c’est ce qu’ils commencent à faire en rapprochant RT de Windows Phone faire une api unique qui sera capable de tourner sur tout leur système, même sur midori.

Donc c’est pour ça qu’ils ont obliger les utilisateur de PC traditionnel à avoir cette interface Metro pour pousser les devs à sortir des apps dessus et à terme avoir un gros paquet d’appli à la sortie de Midori comme on a actuellement sur Win32 (pour éviter de perdre de grosse part de marcher sur le desktop)..

votre avatar







charon.G a écrit :



Le M# est un langage derivé de c# qui est type et memory safe mais qui obtient les mêmes performances que le C++.





La formulation me paraît trop audacieuse, à moins que l’on ne parle de C++ avec boost/STL (avec bounds checking dans les structures de données, smart pointers, etc). Sauf que ce n’est pas formidable et déjà loin du C.



Je ne vais pas m’avancer mais aucune magie ne permettra de s’affranchir de toutes les sources de ralentissement imposées par un code sécurisé. En revanche il est possible d’en supprimer beaucoup et de faire des gains par ailleurs avec l’architecture de Singularity. Au final je m’attends à de bonnes performances, suffisantes même pour le noyau et les pilotes, mais plutôt en recul par rapport au C.







charon.G a écrit :



un autre aspect qui n’a pas encore été abordé par joe duffy pour le moment ,ce langage a été conçu pour la programmation many core.





Il y a un peu fait allusion et son dernier papier de recherche jetait un éclairage sur ce qu’ils sont en train de faire.







francois-battail a écrit :



<img data-src=" /> code système sous un langage managé le tout avec un garbage collector ! Le C n’est pas prêt de prendre sa retraite.

M c’est pour marronnier ? Le super langage qui va tout révolutionner c’est un peu lassant à force surtout quand ça prétend être en mesure de faire du système.





Je comprends ton scepticisme mais il faut bien comprendre que ce langage et cet OS vont de pair. Si tout est vérifiable alors tout peut tourner en SIP0, et toutes les restrictions qui rendaient impossible l’usage du C++ en SIP0 disparaissent, ainsi sans doute que la mémoire virtuelle. C’est cette synergie entre le langage et l’OS qui fait la véritable ingéniosité du système. Et sans doute demain une synergie avec des CPU plus simples, débarrassés de certains mécanismes devenus inutiles.



Ça et le fait que l’écart entre C++ moderne et C# n’est pas si grand qu’on le pense et est surtout le fait du compilateur (très bon pour C++, médiocre pour C#).







brazomyna a écrit :



Le M# s’arrête forcément quelque part pour laisser la place à du code machine. La limite est encore floue.





Quelques centaines de ligne d’assembleur suffisaient dans le projet de recherche initial. Tout le reste était codé dans leur langage managé de l’époque.







charon.G a écrit :



Pour le gc tu devrais lire le billet de joe duffy ils ont fait un gc deterministe.





Non. D’abord un GC ne peut pas être déterministe par définition.



Leur compilateur est simplement capable dans certains cas de détecter qu’une instance a une portée locale afin de l’allouer sur la pile et de la libérer de façon déterministe.



Mais ça ne concerne qu’une part des allocations et ne remplace pas le GC pour les autres. Et le GC était déjà extrêmement optimisé donc on ne peut guère faire mieux. Toute la question est donc de savoir ce qui est possible dans les cas restants : resteront-ils sur un GC ou non ? Offriront-ils un autre mécanisme ? Celui-ci pourrait-il créer des fuites mémoire (type ARC) ? Mais s’ils restent sur le GC les performances de celui-ci ne peuvent sans doute pas être améliorées, à part en réduisant sa charge de travail en amont (précédent paragraphe).







John Shaft a écrit :



Ça ressemble quand même pas mal à du bla-bla pour vendre le bouzin





Ce n’est pas du blabla et c’est même une définition claire du domaine de ce langage. L’asm ne sera pas autorisé dans cet OS donc ce sera bien pour les dévs Windows le plus bas langage dont ils auront besoin, celui conçu pour écrire jusqu’aux pilotes de périphériques et pour écrire tous les pilotes. C’est la contrainte sur laquelle ils travaillent, par opposition à C# qui restera dédié à des applications de plus haut niveau.







Goldust a écrit :



1- Il y a encore des gens qui doutent de l’utilité de l’assembleur pour écrire un OS ? Ton Pipalo-Pentium tu le passes comment en mopde protégé ? <img data-src=" />





Comme dit plus haut, l’assembleur est utilisé pour créer le coeur du système lui-même, à hauteur de quelques centaines de lignes.





Y’a encore des crétins qui utilisent autre chose en C++ que des vecteurs ou des liste, pour aller se plaindre que les structures n’ont pas de bound checking ?



Au vu des bulletins de sécurité, oui, il y en a même beaucoup.







metaphore54 a écrit :



A vous lire, ça va vouloir dire changement de terminale de windows phone 8 à 9. <img data-src=" />





Ouhlà, on est sur du bien plus long terme. WP11 peut-être.


votre avatar







HarmattanBlow a écrit :



Ouhlà, on est sur du bien plus long terme. WP11 peut-être.







Après la catastrophe Longhorn (souvenez vous de la communication sur WinFS…), vu que des infos précisent sortent, vu que les briques commence à s’assembler, je pense que cela arrivera bien plus tôt que ça.


votre avatar







Nyco87 a écrit :



Après la catastrophe Longhorn (souvenez vous de la communication sur WinFS…), vu que des infos précisent sortent, vu que les briques commence à s’assembler, je pense que cela arrivera bien plus tôt que ça.





Ils n’ont pas fini d’écrire le langage avec lequel ils comptent le programmer ! Je pense que ça en dit long… Qui plus est WP9 est sans doute déjà en développement depuis un bail et WP10 aussi, en quelque sorte.



Pour l’instant je n’y vois que la confirmation que MS a validé toutes les recherches menées et amorce la réalisation de produits finis et la transition vers ceux-ci. Et puis d’abord je ne sais pas si Windows phone est le premier concerné par ces technos, même s’il le sera à terme.


votre avatar

Je ne vois pas trop ce que vient faire le DO178 et des exemples issus de l’avionique dans la conversation… On ne connait pas précisément la cible de Midori, mais on peut imaginer PC/tablettes/smartphones, pas les systèmes temps réel, et encore moins embarqués avioniques qui tombent sous le coup du DO <img data-src=" />

votre avatar







charon.G a écrit :



Ce langage n’a rien a voir avec M# qui est un projet de recherche interne a microsoft.

Le nom M# vient de cette offre d’emploi sur Midori:

careers.microsoft.com MicrosoftAh, au temps pour moi, merci pour cette précision !


votre avatar







Goldust a écrit :



<img data-src=" />

Putain, c’est affolant de lire des conneries pareilles. Aucun de vous n’y connais strictement rien en programmation c’est bien là le problème, et c’est pas en justifiant des âneries que n’importe qu’elle expert utilisera à vos dépends …



1- Il y a encore des gens qui doutent de l’utilité de l’assembleur pour écrire un OS ? Ton Pipalo-Pentium tu le passes comment en mopde protégé ? <img data-src=" />



2-Y’a encore des crétins qui utilisent autre chose en C++ que des vecteurs ou des liste, pour aller se plaindre que les structures n’ont pas de bound checking ? Et puis quelque soit le langage à partir du moment ou le compilo fait ton travail à ta place faut pas venir se plaindre des perfs, que ce soit en managé, compilé, précompilé, etc



3- En C c’est plus complique il faut tout se taper à la main mais quand on en a fait 3-4 ans sérieusement on connait -&gt; pour ça qu’on se met au C++



4- En 20 ans j’ai jamais vu un bon programmeur java faire mieux qu’un bon programmeur C++, alors pour le reste on a encore sincèrement de la marge.



5- Avant de vendres vous programmes dites moi, vous avez bien eu le temps de les TESTER <img data-src=" />? Je sais pas mais, comme ça, je me suis rarement fait avoir par un buffer overflow à près 3-4 débug <img data-src=" />, normal le cpu il fait tout pour toi… mais en assembleur :eeek:







<img data-src=" />





  1. Qui a parlé de coder un OS ?

  2. Qui a dit qu’un bon développeur consciencieux à qui on accorde le temps nécessaire pour bien faire les choses ne savait pas les faire ?



    Si t’es de mauvaise tapes sur ta femme mais vient pas nous faire ch* ! <img data-src=" />


votre avatar

Voilà pourquoi j’aime pci ! Pas pour les les news Apple pu ça se tire dessus à coups de mauvaise foi bien puante mais pour les news techniques de de se genre.

votre avatar







Sebdraluorg a écrit :



<img data-src=" />





  1. Qui a parlé de coder un OS ?

  2. Qui a dit qu’un bon développeur consciencieux à qui on accorde le temps nécessaire pour bien faire les choses ne savait pas les faire ?



    Si t’es de mauvaise tapes sur ta femme mais vient pas nous faire ch* ! <img data-src=" />







    Si, si, Midori est codé a 99% en code managé à l’exception de la base mais verifié mathématiquement comme dit par Charon (comm n°19).



    C’est justement l’interet : meilleur perf, plus de faille type buffer overflow.



    Sinon @PCI et surtout @P.A c’est normal de ne plus avoir les comm’s sur les archives ? Je pense notamment à ces news sur Singularity/Midori (ici, la, encore la et re-par ici) ? J’ai pourtant cru les avoir lu y’a une semaine ou 2 justement … Et Charon et Laere expliquait plutôt bien les principes mis en jeu … Ca serait dommage de perdre ces explications a jamais <img data-src=" />


votre avatar







arno53 a écrit :



Si, si, Midori est codé a 99% en code managé à l’exception de la base mais verifié mathématiquement comme dit par Charon (comm n°19)



Sinon @PCI et surtout @P.A c’est normal de ne plus avoir les comm’s sur les archives ? Je pense notamment à ces news sur Singularity/Midori (ici, la, encore la et re-par ici) ? J’ai pourtant cru les avoir lu y’a une semaine ou 2 justement … Et Charon et Laere expliquait plutôt bien les principes mis en jeu … Ca serait dommage de perdre ces explications a jamais <img data-src=" />





Oui j’ai vu ça les vieux commentaires ont disparu <img data-src=" />


votre avatar







Sebdraluorg a écrit :



<img data-src=" />





don’t feed, filtre <img data-src=" />


votre avatar







Goldust a écrit :



4- En 20 ans j’ai jamais vu un bon programmeur java faire mieux qu’un bon programmeur C++





<img data-src=" />



(pardon aux familles tout ça <img data-src=" />)


votre avatar







Bylon a écrit :



Les gens achètent (ou plutôt subissent l’obligation d’acheter) Windows pour deux raisons principales :

-1) L’environnement est familier, je sais le faire marcher.

-2) Je peux faire tourner ma 100aine de crapware que j’ai amassé au fil du temps.





Pour le moment, rien ne permet de dire que la target principale serait le pc de bureau.



Au contraire, la tendance actuelle lourde c’est plutôt de voir sortir l’informatique de cet environnement traditionnel (cf. développement des mobiles, objets connectés, …). On cherche de plus en plus à intégrer de l’applicatif qui se complexifie dans des objets tiers (google car, google glass, jenesaisquoi).



J’aurais donc tendance à penser que ce système est justement prévu pour défricher de nouvelles contrées. Le gros refactoring de Windows depuis Vista jusqu’a win8 étant suffisant pour assurer l’évolution du desktop traditionnel pour au moins une décénie amha.



votre avatar







Latios a écrit :



(pardon aux familles tout ça <img data-src=" />)





Juger la qualité d’un dév en se basant sur le langage qu’il utilise, effectivement, il y a de quoi s’excuser de la connerie. <img data-src=" />


votre avatar







brazomyna a écrit :



Juger la qualité d’un dév en se basant sur le langage qu’il utilise, effectivement, il y a de quoi s’excuser de la connerie. <img data-src=" />





Rohh tout de suite les grands mots <img data-src=" />


votre avatar

Sinon GNU Hurd s’en est où ? <img data-src=" />

votre avatar







brazomyna a écrit :



Pour le moment, rien ne permet de dire que la target principale serait le pc de bureau.



Au contraire, la tendance actuelle lourde c’est plutôt de voir sortir l’informatique de cet environnement traditionnel (cf. développement des mobiles, objets connectés, …). On cherche de plus en plus à intégrer de l’applicatif qui se complexifie dans des objets tiers (google car, google glass, jenesaisquoi).



J’aurais donc tendance à penser que ce système est justement prévu pour défricher de nouvelles contrées. Le gros refactoring de Windows depuis Vista jusqu’a win8 étant suffisant pour assurer l’évolution du desktop traditionnel pour au moins une décénie amha.







Je pense que Midori s’inscrira dans l’optique de 1 windows, plusieurs SKU. A court terme ca servira sans doute a Microsoft pour sa platforme Azure, ensuite ca prendra la place de Windows Phone et tablette (vu qu’office tournera sur les API WinRT) et comme tu dis les objets connectés… Les version classique et entreprise seront sans doutes les dernières à y passer grâce a Drawbridge pour la compatibilité Win32 …


votre avatar







Latios a écrit :



Sinon GNU Hurd s’en est où ? <img data-src=" />





en parlant de connerie, j’aurais bien une réponse toute faite <img data-src=" />


votre avatar







brazomyna a écrit :



Pour le moment, rien ne permet de dire que la target principale serait le pc de bureau.



Au contraire, la tendance actuelle lourde c’est plutôt de voir sortir l’informatique de cet environnement traditionnel (cf. développement des mobiles, objets connectés, …). On cherche de plus en plus à intégrer de l’applicatif qui se complexifie dans des objets tiers (google car, google glass, jenesaisquoi).



J’aurais donc tendance à penser que ce système est justement prévu pour défricher de nouvelles contrées. Le gros refactoring de Windows depuis Vista jusqu’a win8 étant suffisant pour assurer l’évolution du desktop traditionnel pour au moins une décénie amha.





Oui tout a fait, je pense que windows reste trop gros pour certains appareils mobiles ou connectés. Et le fait d’avoir des applications .net en MSIL indépendants de l’architecture. (compilation en natif à l’installation ) est intéressant.



Par contre le desktop(c’est un souhait personnel j’en sais rien), j’espère qu’il ne mourra pas ou au moins que microsoft proposera toujours une interface adaptée à la souris et aux PC sur ce nouvel os.


votre avatar







charon.G a écrit :



Oui tout a fait, je pense que windows reste trop gros pour certains appareils mobiles ou connectés. Et le fait d’avoir des applications .net en MSIL indépendants de l’architecture. (compilation en natif à l’installation ) est intéressant.



Par contre le desktop(c’est un souhait personnel j’en sais rien), j’espère qu’il ne mourra pas ou au moins que microsoft proposera toujours une interface adaptée à la souris et aux PC sur ce nouvel os.







Les entreprises auront toujours besoin d’un OS pour la bureautique/développement/dessin. Je vois mal Microsoft laisser ce marcher à une distrib Linux …



Windows et Win32 peuvent encore durer 10 ans mais bon le petit noyau NT aimerait bien profiter de la retraite aussi <img data-src=" />



Et Terry Myerson (vu les papiers ecrit par thurrott) a l’air d’avoir une bonne vision pour l’avenir : 1 coeur, plusieurs interface adapté … Le fait de pouvoir faire prochainement tourner des applis WinRT sur le Bureau est de bonne augure pour un Midori Desktop.



Mais les devices connecté et les serveurs seront sans doutes leur priorité en effet.


votre avatar







arno53 a écrit :



Windows et Win32 peuvent encore durer 10 ans mais bon le petit noyau NT aimerait bien profiter de la retraite aussi <img data-src=" />





Ce à quoi papy Cobol aurait répondu “moi d’abord !” <img data-src=" />


votre avatar







Khalev a écrit :



T’as des liens vers ces brevets? Parce que jusqu’à présent quand je te lis j’ai plus l’impression de lire un fanboy sans esprit critique qui croit tout ce que lui dit le grand Microsoft que quelqu’un de vraiment raisonné.







Je te l’accorde qu’il y a beaucoup de : “je peux pas le dire” mais en règle général ses propos sont très techniques, cohérents et argumentés.

De plus certains de ses arguments sont vérifiés quelques mois plus tard par des gens de MS.



Bref, c’est pas le profil typique du fanboy


votre avatar







charon.G a écrit :



Quand à midori il a été concu pour une nouvelle stratégie économique(celle évoquée par ray ozzie). C’est probable qu’il soit gratuit et open source.







Economiquement, c’est jouable. L’OS est gratuit pour assurer une large diffusion, ce qui poussera les constructeurs à requérir les tickets support MSDN pour l’écriture de leurs drivers qui sont actuellement développés au passe-purée (ou plus probablement au moulin à curry - les usines dév en Inde, y sont bien gentils, mais ils n’engagent pas que les plus doués…)



<img data-src=" />


votre avatar

j’ai oublié de mentionner quelque chose il semble que harmattanblow n’a pas saisi ce point.

Quand on code en C++ sur WinRT ,le code qui appelle les api doit être en C++/CX qui est un safe langage. C’est ce que j’ai expliqué au dessus les appels aux api WinRT sont type et memory safe. Ce point et la sandbox sont suffisantes pour faire marcher une application C++ au dessus de Midori. pas besoin de VM.

votre avatar







Jed08 a écrit :



Je te l’accorde qu’il y a beaucoup de : “je peux pas le dire” mais en règle général ses propos sont très techniques, cohérents et argumentés.

De plus certains de ses arguments sont vérifiés quelques mois plus tard par des gens de MS.



Bref, c’est pas le profil typique du fanboy





<img data-src=" />

d’ailleurs j”ai été un des premiers à parler de ce langage avant tout le monde. si harmattanblow est un minimum honnête intellectuellement il le confirmera.


votre avatar







charon.G a écrit :



Les applications C++ WinRT tournent dans une sandbox. La sécurité et la fiabilité est donc assurée. Les api de WinRT sont déjà type safes.





Oui mais sandbox est un terme vague. A mon avis c’est quelque chose du type Wine avec en plus une émulation logicielle de certaines fonctionnalités du CPU (comme le MMU). Ou de la virtualisation.





Voilà ce qui se passe si tu communiques un pointeur dans une api winRT



Désolé mais ça n’a rien à voir. Pour commencer le commentaire montre simplement que ne peuvent être exportées de C++ vers C# que les API satisfaisant au dénominateur commun. C’est une simple question d’interopérabilité sans lien avec la sécurité.



Ensuite les applis WinRT sont des processus comme les autres, enveloppés dans la même sandbox que n’importe quel autre processus Windows. Simplement elles ont un peu moins de privilèges par défaut (et à cela se superpose un jeu de permissions spécifiques à WinRT gérées en mode utilisateur). Mais cette sandbox est assurée par le noyau de Windows depuis les années 90 via les mécanismes dont Midori devrait justement être débarrassé (mémoire virtuelle et anneaux de protection).







charon.G a écrit :



j’ai oublié de mentionner quelque chose il semble que harmattanblow n’a pas saisi ce point.

Quand on code en C++ sur WinRT ,le code qui appelle les api doit être en C++/CX qui est un safe langage. C’est ce que j’ai expliqué au dessus les appels aux api WinRT sont type et memory safe. Ce point et la sandbox sont suffisantes pour faire marcher une application C++ au dessus de Midori. pas besoin de VM.





Non il ne l’est pas. C++ CX ne fait qu’ajouter au C++ des mécanismes pour consommer les API WinRT. Il ne retire rien de ce qui fait l’invérifiabilité du C++. Notamment les pointeurs pseudonymes sont toujours possibles.


votre avatar







charon.G a écrit :



d’ailleurs j”ai été un des premiers à parler de ce langage avant tout le monde. si harmattanblow est un minimum honnête intellectuellement il le confirmera.





Je n’apprécie guère l’insinuation et je n’ai de toute façon jamais prétendu avoir révélé quelque exclusivité que ce soit ou avoir fait partie d’une sorte d’avant-garde. Je n’ai aucune source chez MS, je ne mène aucune investigation sur leurs projets, je n’ai jamais prétendu quoi que ce soit dans ce sens et ça ne m’intéresse absolument pas. Et si tu étais sans doute parmi les premiers à en parler, je n’en ai aucun souvenir. Mais pour ma part je te laisse bien volontiers le titre d’expert des arcanes de Microsoft.



En revanche les langages, architectures OS et matérielles, et les technos de développement m’intéressent et j’apporte souvent une lecture critique et un déchiffrage sur ces aspects précis.


votre avatar







HarmattanBlow a écrit :



Oui mais sandbox est un terme vague. A mon avis c’est quelque chose du type Wine avec en plus une émulation logicielle de certaines fonctionnalités du CPU (comme le MMU). Ou de la virtualisation.





Désolé mais ça n’a rien à voir. Pour commencer le commentaire montre simplement que ne peuvent être exportées de C++ vers C# que les API satisfaisant au dénominateur commun. C’est une simple question d’interopérabilité sans lien avec la sécurité.

.





Les api de WinRT sont safe pour prévoir une portabilité future sur Midori. Tu as lu le tweet d’aleks bromfield. Il est assez clair non?







HarmattanBlow a écrit :



Ensuite les applis WinRT sont des processus comme les autres, enveloppés dans la même sandbox que n’importe quel autre processus Windows. Simplement elles ont un peu moins de privilèges par défaut (et à cela se superpose un jeu de permissions spécifiques à WinRT gérées en mode utilisateur). Mais cette sandbox est assurée par le noyau de Windows depuis les années 90 via les mécanismes dont Midori devrait justement être débarrassé (mémoire virtuelle et anneaux de protection).







tu es en train de nous expliquer que Midori ne sera pas capable de sandboxer des applications, c’est çà? <img data-src=" />







HarmattanBlow a écrit :



Non il ne l’est pas. C++ CX ne fait qu’ajouter au C++ des mécanismes pour consommer les API WinRT. Il ne retire rien de ce qui fait l’invérifiabilité du C++. Notamment les pointeurs pseudonymes sont toujours possibles.





Une application WinRT est en C++ sur son code interne et en C++/CX pour l’appel aux api. Tu ne m’as pas compris ce que j’ai dit je pense. Le code interne à l’application n’est pas vérifiable effectivement . mais vu que les appels au système le sont et que l’“appli tourne dans une sandbox ca ne posera aucun problème.


votre avatar







HarmattanBlow a écrit :



Je n’apprécie guère l’insinuation et je n’ai de toute façon jamais prétendu avoir révélé quelque exclusivité que ce soit ou avoir fait partie d’une sorte d’avant-garde. Je n’ai aucune source chez MS, je ne mène aucune investigation sur leurs projets, je n’ai jamais prétendu quoi que ce soit dans ce sens et ça ne m’intéresse absolument pas. Et si tu étais sans doute parmi les premiers à en parler, je n’en ai aucun souvenir. Mais pour ma part je te laisse bien volontiers le titre d’expert des arcanes de Microsoft.



En revanche les langages, architectures OS et matérielles, et les technos de développement m’intéressent et j’apporte souvent une lecture critique et un déchiffrage sur ces aspects précis.





Quelle mauvaise foi!! On en a débattu plein de fois sur plusieurs news.

Tu me décois <img data-src=" />


votre avatar

Vu qu’harmattanblow a des soucis de mémoire. Voilà une vieille offre d’emploi Microsoft dont nous avons débattu à l’époque:

careers.microsoft.com Microsoftou will write code in a language like C# that has the performance characteristics of C++





mais bien sur il a oublié <img data-src=" />

votre avatar

Ah ça oui, vous en avez débattu (et vous vous êtes battu <img data-src=" />) plein de fois tous les 2 de Midori <img data-src=" />

votre avatar

J’ai retrouvé ce lien interessant sur les types en c++/cx:

msdn.microsoft.com MicrosoftUIntPtr

(For internal use only.) An unsigned 64-bit value that is used as a pointer.

IntPtr

(For internal use only.) A signed 64-bit value that is used as a pointer.



Ca explique bien ce que je disais plus haut, les pointeurs peuvent être utilisés uniquement en interne dans l’application. pas dans des api sinon une exception est déclenchée.(voir le lien avant)

votre avatar







Tolor a écrit :



Ah ça oui, vous en avez débattu (et vous vous êtes battu <img data-src=" />) plein de fois tous les 2 de Midori <img data-src=" />





Merci de confirmer, Apparemment harmattanblow a certains problèmes de mémoire <img data-src=" />


votre avatar







charon.G a écrit :



Les api de WinRT sont safe pour prévoir une portabilité future sur Midori.





Les API, oui. C++ CX, non. Il n’est pas vérifiable. Il n’y a absolument aucune restriction sur les pointeurs ou les instructions utilisées, tu ne peux pas le faire tourner en ring0 car tu ne peux pas avoir la certitude que telle variable ne pointera pas vers une adresse du noyau au moment où elle sera écrite.

Tu as lu le tweet d’aleks bromfield. Il est assez clair non?



Aussi clair que la lecture des lignes de la main. Je suis (j’étais) à la recherche de détails technique, pas de promesses commerciales en 140 caractères.





tu es en train de nous expliquer que Midori ne sera pas capable de sandboxer des applications, c’est çà? <img data-src=" />



Il est impossible de le faire tel que c’était fait jusqu’à aujourd’hui. Je n’ai jamais dit que c’était impossible autrement, il y a plusieurs façons et j’en avais présenté une dans le même post.





mais vu que les appels au système le sont et que l’“appli tourne dans une sandbox ca ne posera aucun problème.



Non puisqu’il n’y a plus de sandbox avec Midori : tout tourne en ring0. La seule “sandbox” restante c’est la vérification des autorisations lors des appels aux API.



Donc il faut en recréer une pour les applis non-vérifiables puisqu’on ne peut pas les faire tourner ainsi en ring0 : elles pourraient écrire dans la zone mémoire du noyau ou d’une autre appli. La question est donc : comme refaire cette sandbox ? C’était le sens de ma question au départ.



Mais ce n’est pas grave : j’ai été revoir le projet Sandbridge et j’ai vu la réponse à ma question. Pour ces applis ils créent donc des processus en ring3 mais au lieu de ré-implémenter tout un noyau NT aux côtés de Midori ils le créent en user-mode dans le processus lui-même. Ce noyau NT est donc hautement vulnérable mais puisqu’il est spécifique à un processus et une application ce n’est pas un problème. Le coût est avant tout en mémoire et un peu en temps CPU.







charon.G a écrit :



Quelle mauvaise foi!! On en a débattu plein de fois sur plusieurs news.Tu me décois <img data-src=" />





Mais arrête de m’insulter enfin !



Je me rappelle avoir discuté de nombreuses fois avec toi de ces sujets mais je ne me rappelle pas s’ils avaient été révélés par toi ni à quel moment par rapport aux autres, c’est aussi simple que ça et il n’est pas du tout étonnant que la chronologie exacte m’échappe des années plus tard.



Et j’ai été très surpris et choqué par tes réactions tout au long de ce sujet. Je suis venu pour une discussion technique sur un sujet qui m’intéresse et je me retrouve avec des approximations et un problème d’égo sorti de nulle part.







charon.G a écrit :



Ca explique bien ce que je disais plus haut, les pointeurs peuvent être utilisés uniquement en interne dans l’application.





Mais comment sais-tu que c’est interne à l’application ? Comment sais-tu que l’adresse est bien la plage de l’appli et pas celle du noyau ? Tu ne peux pas. Aujourd’hui c’est la mémoire virtuelle qui gère ça, en levant une interruption si l’appli viole ses autorisations. Mais dans Midori, en ring 0, pas de mémoire virtuelle ! Si je fais void* x = 0 j’ai l’adresse physique 0, sans doute utilisée par le noyau, et personne n’empêche d’y écrire. Il n’y a plus aucune sécurité, c’est pour ça que le code doit être vérifiable.


votre avatar







charon.G a écrit :



J’ai retrouvé ce lien interessant sur les types en c++/cx:

msdn.microsoft.com MicrosoftCa explique bien ce que je disais plus haut, les pointeurs peuvent être utilisés uniquement en interne dans l’application. pas dans des api sinon une exception est déclenchée.(voir le lien avant)









Je m’y connais pas assez pour rentrer dans les détails de votre discussion mais sur ce point je dirait: encore heureusement.

Parce que dans le cas contraire: pourquoi créer de nouvelles API plus modernes et sécurisées si c’est pour être aussi permissif (et donc potentiellement “dangereux”) que les anciennes…

On laisse le développeur faire joujou au sein de son application mais on pose des limites dès qu’on veut en sortir, ça me parait normal.


votre avatar



Les API, oui. C++ CX, non. Il n’est pas vérifiable. Il n’y a absolument aucune restriction sur les pointeurs ou les instructions utilisées, tu ne peux pas le faire tourner en ring0 car tu ne peux pas avoir la certitude que telle variable ne pointera pas vers une adresse du noyau au moment où elle sera écrite.



faudrait que je retrouve un vieux ppt mais ils ont incorporé plusieurs mot clés pour s’aligner sur les langages managés. mais disons que la tu es d’accord pour les api.

Pour ce que tu dis sur le ring0 je suis d’accord mais regarde ceci ça va répondre en partie à ta question je pense:

careers.microsoft.com MicrosoftOur Kernel is a non-traditional design divided between a native C++ microKernel and additional managed C# operating system functionality which is injected into each independent hardware address space.





C’est ce que j’avais entendu parler il devrait y avoir un espace d’adressage mémoire indépendant pour le natif. Du coup il n’y aucun risque que l’appli native corrompt le système.

Mais j’ai pas toutes les informations en effet la dessus. Par contre tu ne penses pas que si Microsoft sort une nouvelle plateforme de dev alors que win32 a duré plus de 20 ans, il ne va pas la jeter 3 ou 5 ans après?





Mais arrête de m’insulter enfin !



Je me rappelle avoir discuté de nombreuses fois avec toi de ces sujets mais je ne me rappelle pas s’ils avaient été révélés par toi ni à quel moment par rapport aux autres, c’est aussi simple que ça et il n’est pas du tout étonnant que la chronologie exacte m’échappe des années plus tard.



Et j’ai été très surpris et choqué par tes réactions tout au long de ce sujet. Je suis venu pour une discussion technique sur un sujet qui m’intéresse et je me retrouve avec des approximations et un problème d’égo sorti de nulle part.



Ok tu as oublié pas de soucis désolé <img data-src=" />

votre avatar

Que viens faire Roslyn dans l’histoire ? Juste un projet annexe ou c’est lié ?

votre avatar







francois-battail a écrit :



Je ne suis pas certain d’avoir lu le bon billet, mais le jour où ce sera conforme à DO-178A on aura l’occasion d’en reparler.







J’attends avec impatience du Midori sur des micro-contrôleurs 8 ou 16 bits… mais pour le moment le C et l’assembleur (et pas le C++) pour du système ça convient parfaitement, après utiliser une couche d’abstraction en managé pour une interface graphique et des APIs pourquoi pas mais là on est au niveau de l’applicatif.





Euh, relis mon commentaire et tu comprendras que ta réponse n’a pas de sens <img data-src=" />



EDIT, en plus on ne fait pas les mêmes chose en C et en C++/M#, ou alors on change de métier ;-)


votre avatar







charon.G a écrit :



[…]







Merci d’avoir cité le passage sur le GC mais je le comprends comme une optimisation qui permet de déceler plus de cas ou la désallocation peut être automatique et implicite que comme un système véritablement déterministe (c’est à dire de pouvoir borner la consommation mémoire quel que soit la branche de code exécuté).

Et sinon pour le lifetime understanding il y a un vieux truc très utilisé en embarqué ça s’appelle un pool et là on est complètement déterministe.


votre avatar







Sebdraluorg a écrit :



EDIT, en plus on ne fait pas les mêmes chose en C et en C++/M#, ou alors on change de métier ;-)







Justement on est bien d’accord, je me place exclusivement dans l’optique système comme réaliser les changements de contexte, manipuler le hard, etc. Un langage managé est inutilisable en l’espèce et de plus des contraintes matérielles rendent impensables de devoir caser un framework de taille monstrueuse.


votre avatar







charon.G a écrit :



Tu crois qu’il va salir sa réputation en annonçant des trucs faux. De toute façon même quand ça sortira certains resteront toujours dans le deni….







Bin ce type de citations :





The idea is that M# should be the lowest-level language that you’ll ever need





Ça ressemble quand même pas mal à du bla-bla pour vendre le bouzin <img data-src=" />



(ou alors je traîne trop avec des gens qui ont un vrai besoin de passer par la case ASM <img data-src=" />)


votre avatar







francois-battail a écrit :



Merci d’avoir cité le passage sur le GC mais je le comprends comme une optimisation qui permet de déceler plus de cas ou la désallocation peut être automatique et implicite que comme un système véritablement déterministe (c’est à dire de pouvoir borner la consommation mémoire quel que soit la branche de code exécuté).

Et sinon pour le lifetime understanding il y a un vieux truc très utilisé en embarqué ça s’appelle un pool et là on est complètement déterministe.







This allows us to aggressively stack allocate objects, deterministically destruct, and more.



Ce que tu interprètes plutôt, il dit clairement que les destructions sont déterministes.


votre avatar







francois-battail a écrit :



Justement on est bien d’accord, je me place exclusivement dans l’optique système comme réaliser les changements de contexte, manipuler le hard, etc. Un langage managé est inutilisable en l’espèce et de plus des contraintes matérielles rendent impensables de devoir caser un framework de taille monstrueuse.





L’objectif de Windows (NT et Midori) n’a jamais été d’être embarqué dans un controller 8 bits. Bien évidemment que le C ne va pas mourir :)



En entreprise on se pose 2 questions principales pour choisir un langage de dév: 1) quelle(s) target(s) pour l’application 2) quelles compétences dans la team de dév



Et pour le 1), si la target c’est un microcontroller 8-bits où faut recoder l’intégralité des drivers pour gérer toutes les I/O, alors va pour le C ou l’ASM. Si la target c’est Windows, alors va pour .Net.


votre avatar







charon.G a écrit :



Ce que tu interprètes plutôt, il dit clairement insinue que les destructions sont pourraient être déterministes.







Il y a le mot « aggressively » qui laisse penser à une optimisation « on the edge » mais pour le moment on est en plein « vaporware » faute d’information détaillée.


votre avatar







francois-battail a écrit :



Justement on est bien d’accord, je me place exclusivement dans l’optique système comme réaliser les changements de contexte, manipuler le hard, etc. Un langage managé est inutilisable en l’espèce et de plus des contraintes matérielles rendent impensables de devoir caser un framework de taille monstrueuse.





Tu devrais plus te renseigner sur singularity. Tout tourne en ring 0. les SIP qui sont des processus(ou drivers) sont isolés entre eux. Pas de chargement dynamique de code après l’execution. Le code est scellé au runtime. Bartok le compilateur ahead of time s’assure à la compilation en verifiant le code que les sip sont bien scellés.

Du coup l’isolation est assurée par le langage et pas par le processeur. Du coup tu n’as pas de context switch. Les api systèmes sont de simples routines d’appels. Tu peux aller jeter un oeil sur le site du msr il y a plein de papiers sur le sujet.

Mais Singularity règle élégamment le problème des contextes switch sur les micro noyau modernes. Ils ont même fait des benchs. les api systèmes sont bien plus rapides que la plupart des systèmes.



Singularity et Midori ont été conçus pour le code safe.


votre avatar







francois-battail a écrit :



Il y a le mot « aggressively » qui laisse penser à une optimisation « on the edge » mais pour le moment on est en plein « vaporware » faute d’information détaillée.





J’ai des contacts au sein de Microsoft. il y a des papiers internes qui circulent sur ce système. Je sais qu’il est globalement deux fois plus rapide que Windows voir plus. je sais que tu ne me croiras pas. Mais tout ce qui a été dit ici j’en parle depuis des années sur PCI. Et ce qui a été révélé soutient mes propos précédents sur le sujet.

Mais bon quand ça sortira j’imagine que certains continueront à renier la réalité….


votre avatar







hadoken a écrit :



L’objectif de Windows (NT et Midori) n’a jamais été d’être embarqué dans un controller 8 bits. Bien évidemment que le C ne va pas mourir :)



En entreprise on se pose 2 questions principales pour choisir un langage de dév: 1) quelle(s) target(s) pour l’application 2) quelles compétences dans la team de dév



Et pour le 1), si la target c’est un microcontroller 8-bits où faut recoder l’intégralité des drivers pour gérer toutes les I/O, alors va pour le C ou l’ASM. Si la target c’est Windows, alors va pour .Net.





Tout a fait Midori est fait pour remplacer Windows pas tourner sur des micro controlleurs…..


votre avatar

<img data-src=" />

Putain, c’est affolant de lire des conneries pareilles. Aucun de vous n’y connais strictement rien en programmation c’est bien là le problème, et c’est pas en justifiant des âneries que n’importe qu’elle expert utilisera à vos dépends …



1- Il y a encore des gens qui doutent de l’utilité de l’assembleur pour écrire un OS ? Ton Pipalo-Pentium tu le passes comment en mopde protégé ? <img data-src=" />



2-Y’a encore des crétins qui utilisent autre chose en C++ que des vecteurs ou des liste, pour aller se plaindre que les structures n’ont pas de bound checking ? Et puis quelque soit le langage à partir du moment ou le compilo fait ton travail à ta place faut pas venir se plaindre des perfs, que ce soit en managé, compilé, précompilé, etc



3- En C c’est plus complique il faut tout se taper à la main mais quand on en a fait 3-4 ans sérieusement on connait -&gt; pour ça qu’on se met au C++



4- En 20 ans j’ai jamais vu un bon programmeur java faire mieux qu’un bon programmeur C++, alors pour le reste on a encore sincèrement de la marge.



5- Avant de vendres vous programmes dites moi, vous avez bien eu le temps de les TESTER <img data-src=" />? Je sais pas mais, comme ça, je me suis rarement fait avoir par un buffer overflow à près 3-4 débug <img data-src=" />, normal le cpu il fait tout pour toi… mais en assembleur :eeek:

votre avatar







francois-battail a écrit :



Il y a le mot « aggressively » qui laisse penser à une optimisation « on the edge » mais pour le moment on est en plein « vaporware » faute d’information détaillée.





un vaporware qui va sortir <img data-src=" /> , t’as lu la news?


votre avatar







charon.G a écrit :



[…]Du coup tu n’as pas de context switch. Les api systèmes sont de simples routines d’appels.[…]







C’est inexact. Tu veux dire qu’il n’y pas besoin de transition Ring 3 -&gt; Ring 0 pour des system calls et de séparation user / system. Néanmoins la commutation de contexte lors de l’ordonnancement des tâches est toujours d’actualité vu que j’imagine que c’est toujours un système préemptif et non pas coopératif.







charon.G a écrit :



[…]Je sais qu’il est globalement deux fois plus rapide que Windows voir plus. je sais que tu ne me croiras pas.[…]







Si on élimine la recopie user / système et le coût des changements de privilèges lors des system calls c’est vraisemblable, du moins pour certaines applications (typiquement un serveur qui passe son temps à faire des I/O).

Néanmoins l’approche choisie (protéger le système du développeur) semble séduisante mais n’empêche pas des erreurs de plus haut niveau (voir l’incident de l’A380 Qantas) malgré un environnement logiciel supposé être valide.


votre avatar







francois-battail a écrit :



Justement on est bien d’accord, je me place exclusivement dans l’optique système comme réaliser les changements de contexte, manipuler le hard, etc. Un langage managé est inutilisable en l’espèce et de plus des contraintes matérielles rendent impensables de devoir caser un framework de taille monstrueuse.





Non absolument pas, tout dépend de l’interface entre toi et le matériel, et aussi du matériel que tu pilotes.

Si tu dois passer la plupart de ton temps à lire/ecrire des registres et shifter des bits alors le C est certainement plus intéressant.

Mais bon, sur Windows l’abstraction matérielle est quand même assez poussée, à moins de vouloir piloter ton propre composant il y a peu de chance que tu te retrouve dans cette situation.


votre avatar







francois-battail a écrit :



C’est inexact. Tu veux dire qu’il n’y pas besoin de transition Ring 3 -&gt; Ring 0 pour des system calls et de séparation user / system. Néanmoins la commutation de contexte lors de l’ordonnancement des tâches est toujours d’actualité vu que j’imagine que c’est toujours un système préemptif et non pas coopératif.





Oui en effet désolé mal exprimé. par contre la gestion de la pagination mémoire n”utilise pas non le cpu. ce qui permet aussi de gagner en performance.


votre avatar

Les gens achètent (ou plutôt subissent l’obligation d’acheter) Windows pour deux raisons principales :

-1) L’environnement est familier, je sais le faire marcher.

-2) Je peux faire tourner ma 100aine de crapware que j’ai amassé au fil du temps.



On a bien vu avec RT ce que ça a donné !



1 et 2 ne sont plus réunis =&gt; rejet massif.



Même si l’environnement est indépendant d’un noyau, je doute donc d’un succès d’un autre kernel qui foutrait en l’air l’affirmation numéro 2.



… ou alors ils mettent Wine en plus sur Midori pour faire tourner les crapwares ! <img data-src=" />

votre avatar







HarmattanBlow a écrit :



Ils n’ont pas fini d’écrire le langage avec lequel ils comptent le programmer ! Je pense que ça en dit long… Qui plus est WP9 est sans doute déjà en développement depuis un bail et WP10 aussi, en quelque sorte.



Pour l’instant je n’y vois que la confirmation que MS a validé toutes les recherches menées et amorce la réalisation de produits finis et la transition vers ceux-ci. Et puis d’abord je ne sais pas si Windows phone est le premier concerné par ces technos, même s’il le sera à terme.





WP 7 ====&gt; WP8 changement de tel obligatoire alors que l’OS a eu moins de changement que là, donc je ne me fais pas d’illusion.


votre avatar

Je me pose une question qui peut paraitre con, pourquoi creer un nouveau language au lieu de se focaliser sur un compilateur natif C# qui aura du-coup grosso modo les memes perfs ?

votre avatar







Sebdraluorg a écrit :



Difficile de comprendre ce que tu veux dire, soit le browser lui-même est vérolé auquel cas il est déjà trop tard, soit tu parles d’un site qui exploiterait une faille du browser et là c’est le boulot du sandboxing et du bound checking, qui justement sont ici renforcés.







Justement, c’est ce que je voulais dire: dans le cas particulier du “navigateur web”, les 2 mécanismes qui évitent l’exploitation de la faille ne nécessitent pas forcément le passage à Midori.



Même si Midori force la mise en oeuvre de ces deux mécanismes, ils peuvent être implantés avec un OS de type windows/linux.


votre avatar







cendrev3 a écrit :



Je me pose une question qui peut paraitre con, pourquoi creer un nouveau language au lieu de se focaliser sur un compilateur natif C# qui aura du-coup grosso modo les memes perfs ?





D’abord Duffy n’a jamais parlé d’un langage, il a mentionné “des technologies”. Et justement MS travaille sur un compilateur ahead-of-time poussé pour C#, déjà bien abouti. Ces technologies sont donc utilisées de façon transversale et C# bénéficiera des fruits de ce travail.



Cela étant dit un nouveau langage était quand même nécessaire pour pouvoir supporter certaines constructions qui n’ont pas forcément d’intérêt en C#. Notamment tout ce qui relève de la gestion de la mémoire, dans le cas où M# utiliserait un comptage de références plutôt que le GC. Ou peut-être quelque chose de fin concernant la spécification des barrières-mémoires. Bref, tout le bas niveau.



Enfin il y a aussi des annotations dédiées au parallélisme de masse avec un support natif de l’immutabilité. Pour faire court c’est un modèle qui ressemble aux tâches de C# mais en plus léger, plus scalable et vérifiable, encourageant l’immutabilité mais sans la forcer. Mais toute cette partie-là pourrait bien se retrouver in fine dans C#.


votre avatar







metaphore54 a écrit :



WP 7 ====&gt; WP8 changement de tel obligatoire alors que l’OS a eu moins de changement que là, donc je ne me fais pas d’illusion.







Moins de changements ! <img data-src=" />

On est passé d’un noyau Windows CE (version 6.0 qui ne gérait à l’époque “que” 512Mo de RAM au maximum et était singe core only) vers un noyau Windows NT. Le changement est du même ordre de grandeur.


votre avatar







HarmattanBlow a écrit :



Ils n’ont pas fini d’écrire le langage avec lequel ils comptent le programmer ! Je pense que ça en dit long… Qui plus est WP9 est sans doute déjà en développement depuis un bail et WP10 aussi, en quelque sorte.



Pour l’instant je n’y vois que la confirmation que MS a validé toutes les recherches menées et amorce la réalisation de produits finis et la transition vers ceux-ci. Et puis d’abord je ne sais pas si Windows phone est le premier concerné par ces technos, même s’il le sera à terme.





Regarde cette offre sur la prochaine version majeur de Windows phone(visibiblement wp9):

careers.microsoft.com MicrosoftDo you ever wonder what it takes to bring-up an entire new OS foundation to life? Do you wonder what the core new features of the next major release of Windows Phone are? Do you want to have the pride of working on the foundations of an Operating System that serves all other feature teams?





Même si j’ai pas le droit d’en parler ils sont beaucoup plus avancés que tu le penses. Si ça sortait dans trois ou cinq ans crois moi joe duffy et d’autres n’auraient jamais communiqué. Ils évitent ce genre de choses depuis Vista…



M# est dérivé de langages existants comme le sing# et le c# compile aussi directement avec le compilo m# d’après joe duffy. D’après ce que je sais il marche déjà.


votre avatar



Ce n’est pas du blabla et c’est même une définition claire du domaine de ce langage. L’asm ne sera pas autorisé dans cet OS donc ce sera bien pour les dévs Windows le plus bas langage dont ils auront besoin, celui conçu pour écrire jusqu’aux pilotes de périphériques et pour écrire tous les pilotes. C’est la contrainte sur laquelle ils travaillent, par opposition à C# qui restera dédié à des applications de plus haut niveau.





Oui tout a fait, au niveau système le M# sera obligatoire pour éviter les bsod sur les pilotes entre autres et les failles de sécurités dans le système.



Par contre au niveau applicatif rien ne changera on devrait pouvoir toujours coder e C++ avec WinRT

votre avatar







Tophe a écrit :



Moins de changements ! <img data-src=" />

On est passé d’un noyau Windows CE (version 6.0 qui ne gérait à l’époque “que” 512Mo de RAM au maximum et était singe core only) vers un noyau Windows NT. Le changement est du même ordre de grandeur.





Pas vraiment car on restait sur du Windows. Là on parle de remplacer Windows même si le nom pourrait subsister pour des raisons marketing.


votre avatar







charon.G a écrit :



Il a les avantages des langages manages et les performances des langages natifs <img data-src=" />







Oui c’est présenté comme le langage parfait, on verra bien. En attendant espérons au moins que MS le libère sous une licence libre


votre avatar







metaphore54 a écrit :



WP 7 ====&gt; WP8 changement de tel obligatoire alors que l’OS a eu moins de changement que là, donc je ne me fais pas d’illusion.





Il y a eu changement hardware au passage WP7 &gt; WP8 avec le changement de noyau. Rien ne dit qu’un changement, même plus important, ait de telles conséquences.


votre avatar







metaphore54 a écrit :



WP 7 ====&gt; WP8 changement de tel obligatoire alors que l’OS a eu moins de changement que là, donc je ne me fais pas d’illusion.





D’après sdtimes qui avait écrit sur Midori, Midori peut faire tourner les drivers windows dans des services midori. Donc Microsoft pourrait assurer une compatibilité.


votre avatar







charon.G a écrit :



Par contre au niveau applicatif rien ne changera on devrait pouvoir toujours coder e C++ avec WinRT





Pas avec Midori. Ou alors avec du C++ modifié ou emballé dans une VM. Mais par définition Midori ne peut exécuter que du code vérifiable, ce qui n’est pas le cas du C++.


votre avatar







ff9098 a écrit :



Oui c’est présenté comme le langage parfait, on verra bien. En attendant espérons au moins que MS le libère sous une licence libre







My goal is to eventually open source this thing, but before we can do that we need to button up a few aspects of the language and, more importantly, move to the Roslyn code-base so the C# relationship is more elegant. Hopefully in 2014.





Microsoft est en train de changer de stratégie économique. Il y a plusieurs années ,a propos de la vision long terme de ray ozzie , il parlait d’une économie software and service pour Microsoft. J’avais expliqué sur PCI à l’époque que Windows pourrait devenir sur le long terme gratuit voir open source, on m’avais pris pour un fou.



Les dernières rumeurs sur threshold laissent entendre que terry Myerson veut rendre gratuit windows phone 8 et RT. Avec threshold le sku de base devrait se baser sur ces versions, il y a donc de fortes chances pour que ce soit aussi gratuit.



Quand à midori il a été concu pour une nouvelle stratégie économique(celle évoquée par ray ozzie). C’est probable qu’il soit gratuit et open source.


votre avatar







charon.G a écrit :



Pas vraiment car on restait sur du Windows. Là on parle de remplacer Windows même si le nom pourrait subsister pour des raisons marketing.







Non, les noyaux CE et NT n’ont strictement rien à voir. Il y a certes une compatibilité parce que l’API Win32 est utilisée dans les 2 cas pour le dev applicatif, mais côté CE, c’est un sous ensemble.

Les compilateurs ARM ne sont pas les mêmes par exemple. (chose qui a changé avec Compact 2013, qui utilise la même ABI que Windows 8)



La possibilité d’utiliser des applications Phone7 sur Phone 8 est effective grace au Compact Framework 3.9.


votre avatar







HarmattanBlow a écrit :



Pas avec Midori. Ou alors avec du C++ modifié ou emballé dans une VM. Mais par définition Midori ne peut exécuter que du code vérifiable, ce qui n’est pas le cas du C++.





regarde ce tweet de alleks bromfield qui bossait sur midori:

twitter.com Twitterou can have a more reliable system, written in a better language, that still has the same application model.



Je l’ai expliqué dans le dossier de Win8. WinRT tourne dans une sandbox native actuellement. Mais les api de winrt sont déjà type safe.

WinRT devrait pouvoir tourner sur Midori. En clair l’application c++ tournerait dans une sandbox. Les api communiquerait avec Midori vu qu’elles sont déjà safe.

Enfin drawbridge est prévu aussi pour tourner sur Midori et ce sont aussi des applications natives.


votre avatar







Tophe a écrit :



Non, les noyaux CE et NT n’ont strictement rien à voir. Il y a certes une compatibilité parce que l’API Win32 est utilisée dans les 2 cas pour le dev applicatif, mais côté CE, c’est un sous ensemble.

Les compilateurs ARM ne sont pas les mêmes par exemple. (chose qui a changé avec Compact 2013, qui utilise la même ABI que Windows 8)



La possibilité d’utiliser des applications Phone7 sur Phone 8 est effective grace au Compact Framework 3.9.





Je n’ai pas dis non plus que CE et NT sont pareils mais ils ont été tous les deux concus autour de win32. Le changement vers Midori est bien plus radical.

Après pour te donner raison le passage de wp7 vers wp8 s’est aussi accompagné d’un changement de plateforme de développement avec WinRT. WinRT est censé subsisté.


Le système Midori de Microsoft se rapproche de sa phase commerciale

  • L'émergence après le calme 

  • Le projet a rejoint la division systèmes d'exploitation de Terry Myerson 

  • De l'utilité et de l'intégration dans le paysage actuel 

  • Des annonces sans doute à prévoir cette année 

Fermer