Le 03/10/2016 à 10h 16

Pas de soucis avec le touchpad, y compris dans GDM sur Ubuntu Gnome 16.10. Pour l’UEFI, je touche du bois, c’est passé les doigts dans le nez. Pour le driver proprio, après avoir réussi à le faire tourner sur le chipset Intel, je vais pas aller plus loin, je fais plus de CUDA depuis 3 ans …

 

Le 03/10/2016 à 09h 39

Ouais c’est exactement ça que je reproche. Devoir passer des plombes à écumer 5000 forums pour connaître le support d’une machine. A la base quand le matériel d’une machine est indiqué “supporté” par le noyau, il est pas sensé y avoir des problèmes improbables.

Accessoirement :https://marclewis.com/2016/04/25/installing-ubuntu-16-04-lts-on-asus-zenbook-ux5… . Pour la 16.04. Verdict à l’essai : pas pour tout le monde apparemment, au premier reboot même le TTY n’est pas accessible.

On a aussi ça :http://unix.stackexchange.com/questions/254192/asus-zenbook-linux-install-fails qui indique que c’est OK pour 15.10. Sauf que non plus, à moins d’apprécier avoir un ventilateur à 100% en permanence.

Le 03/10/2016 à 09h 21

Remarque : la bêta de Ubuntu 16.10 a le bon goût d’utiliser la version 4.8 mais je ne sais pas sur quelle RC elle est basée. C’est la première distrib que je peux faire juste booter sur mon Zenbook Pro (et je commençais sérieusement à désespérer et à maudire Linux, seulement j’en ai besoin). Pour autant Nouveau n’arrive définitivement pas à gérer convenablement ma GTX960M et les raisons sont pas claires … obligé de booter avec nouveau.modeset=0 sinon tout bloque sans aucun message et les logs sont pas des plus éclairant.
C’est pas plus mal parce que j’en ai rien à carrer du GPU sous Nux, mais bon, c’est un peu gavant des problèmes d’installation encore aujourd’hui …

Le 21/09/2016 à 18h 45

J’allais dans l’extrême. C’est pour dire que si on a des outils capables de nous amener jusque là, on a des possibilités de faire de la validation qui en jette. Sans pour autant se faire coller le tampon EAL7 qui demande d’aller à fond dans cet investissement.  Mais le fait est qu’on a des techniques sur le plan informatique qui se rapprochent doucement d’un niveau de sûreté vraiment très élevé.

Avec la quantité de systèmes informatiques ajoutés dans la vie de tous les jours, si certains matos ne posent pas de problèmes, pour d’autres, il y en a : l’auto, mais tu l’as cité aussi le médical, etc. Et ce que j’ai pu constater, c’est que pour l’instant certains domaines qui commencent à automatiser des choses qui craignent pas mal, sont pas du tout réceptif aux outils qui pourraient les aider en validation. Voir même en ont pour ainsi dire rien à battre de la validation.

Le 21/09/2016 à 14h 59

Même sans parler de sécurité, une bonne part des constructeurs ne sont déjà pas au point sur la seule sûreté, alors d’ici qu’ils parlent de sécu, on a du chemin. C’est malheureux, mais tant qu’ils auront pas à faire face à un gros problème, ça n’évoluera pas.

Le 21/09/2016 à 14h 22

Paratyphi a écrit :

Aucun système informatique n’est sûr à 100%.


Sur quel critère ? Augmenter notre capacité à s’en rapprocher toujours plus, c’est le sujet de recherche de pas mal de labos, y compris dans l’industrie. S’en rapprocher tellement près que ça ne fasse plus grande différence, certaines industries s’y attellent et arrivent à des niveaux de sûreté très élevés, EAL7 ça commence à causer. Mais comme beaucoup d’utilisateurs ne comprennent  pas les enjeux des parties informatiques d’un système, d’autres n’en font pas une priorité (dans certaines industries, on a même des gens qui pensent que c’est le boulot d’électroniciens de s’occuper des problèmes d’informatique …).

Le 21/09/2016 à 13h 15

Hyperviseurs certifiés, tout ça.

Mais “ça sert à rien qu’on vous dit, on va quand  même pas dépenser de l’argent là dedans, c’est que des matheux qui veulent se faire mousser”.

Le 12/09/2016 à 07h 31

Non, ou alors ils ne savent pas comment fonctionne le bousin, ce dont je doute très fort.

Le 31/08/2016 à 06h 52

tazvld a écrit :

Autant avec C, ça va, le langage est très stricte et tout est bien formulé

 Euh on doit pas parler du même langage ... Sa norme est un merdier infâme et tout peut te péter dans les mains sans raison. Je bosse dans un labo dont la principale activité est de produire un soft d'analyse de code C et je ne compte même plus le nombre de notion où :      

• un comportement n’est pas spécifié (sans que ce soit mentionné) et qu’il a fallu en définir une,
  


• un comportement est spécifié à plusieurs endroits mais pas avec la même sémantique,
  


• et surtout, en nombre démentiels, on a des cas particuliers complètement tordus.*
  
  * d’ailleurs ce sont souvent eux qui créent le point 2 à cause de chevauchement de définitions où les sémantiques associées sont différentes.
   
  Il y avait un article (autour de CompCert ? je sais plus) qui avait d’ailleurs un peu trollé sur le sujet en disant que vu que de toute façon la norme C est inconsistante, on peut sans problème partir avec faux en hypothèse et faire n’importe quoi derrière, l’implication sera vraie et notre compilateur sera donc correct.
  
   C++ est à mettre dans le même panier. Il n’est pas plus ou moins bien spécifié que C. Il est juste pareil. C’est la quantité de notions existantes, et le fait que son flot d’exécution soit plus complexe (exceptions, virtualité), qui rendent son analyse plus difficile.

Le 30/08/2016 à 07h 51

What ? Une référence ne peut pas ne pas être initialisée en C++. Elle peut être invalidée, mais pas non-initialisée.  Si c’est une déclaration tu mangeras une erreur, si c’est dans une classe, ça supprime le constructeur par défaut et un constructeur qui ne l’initialise pas sera considéré comme mal-formé et déclenchera une erreur. Un pointeur peut éventuellement être non-initialisé, mais pas une référence.

Le 30/08/2016 à 07h 06

Freud a écrit :

Pour moi c’est de l’analyse de code, pas du débogage.


Aujourd’hui un debugger exécute le code pour te permettre de voir où les bugs se produisent pour que tu puisses les corriger. C’est une analyse dynamique. Les analyses statiques (qui existent depuis longtemps) permettent le même boulot mais sans exécution de code. Je ne vois pas en quoi cela ne rentre pas dans classe “dégogage”.

La différence est que les analyses dynamiques sont précises (puisque le comportement est celui exact du programme) et incomplète (ne couvrent pas tous les états du programme), alors que les analyses statiques sont (généralement) approximative (sur approximation des états du programme) et complètes (ne laisse pas passer de comportement existant). Les premières n’émettent pas de fausses alarmes, les secondes le peuvent.

Et puis finalement, on peut combiner les deux : analyses statique, détection d’une erreur, production d’un exemple d’exécution fautive. Debugger ou pas debugger ?

Le 30/08/2016 à 14h 11

Bon, même si la voiture s’en fout de la jauge de carburant quand il s’agit de faire le plein " /> .

Le 02/06/2016 à 07h 57

Tifeing a écrit :

Sinon: “Et ce afin d’éviter qu’un véhicule circule en lieu et place d’un autre véhicule”.
Je ne vois pas bien comment ça peut arriver… On décolle la plaque d’immatriculation de la voiture d’origine et on la met sur une autre ?


Oui, ou on en fait des copies, c’est pas compliqué non plus.
Et quand un véhicule avec un jeu de fausses plaques te rentre dans le cul et que le conducteur s’enfuit, tu l’as bien mauvaise parce que le véhicule correspond pas aux plaques que tu as relevé et tu ne peux pas porter plainte.

Le 09/05/2016 à 14h 07

C’est sûr que l’argent des majors et des vies humaines c’est comparable niveau valeur.

Sinon, je doute également de la fiabilité du système. Pour le coup, j’ai vu passer un commentaire sur le clignotant, et ça clairement, gros +1, parce que putain suffit de se poser à n’importe quelle intersection pour halluciner un bon coup. C’est plus facile de compter les gens qui l’utilisent que ceux qui l’utilisent pas.

Le 29/04/2016 à 13h 28

guy02 a écrit :

 Et sinon, pusique tu as l’air de t’y connaitre, c’est quoi les gros avantages du c++ 14 par rapport au 11? Je connais pas trop les dernières évolutions…


Par rapport au 11, très peu finalement, il y a certaines literalles qui ne sont plus dans experimental, les variables templates, les lambdas génériques, relâchement de certaines contraintes pour les fonctions constexpr, deduction de type pour le retour de fonction, et la correction d’un oubli pour unique_ptr. Après, c’est  très mineur. Le vrai gap c’était C++11, C++14 facilite des petits bouts qui étaient foireux.

Le véritable apport sur GCC6.1 c’est le passage du support par défaut de C++98 à C++14, mais ça n’a pas d’impact pour les gens qui utilisent déjà cette norme depuis un bail (et qui mettait simplement qu’ils utilisaient C++14 dans leurs options de compilation).

A la question template VS héritage, c’est surtout sémantique. Dans un cas il faut s’efforcer de respecter le LSP, dans l’autre pas nécessairement.

Le 29/04/2016 à 07h 57

Rapport avec la choucroute ? On parle de compiler rapidement, pas de coder rapidement.

Compiler rapidement, ça permet d’avoir plus de temps pour tester (la présence de bugs, et l’impact des optimisations qu’on produit nous même par exemple), ce qui permet justement de s’assurer que le code est pas développé avec les pieds … Qu’il contient un minimum de bug, qu’il a des performances convenables, etc. Parce qu’on produit pas un code parfait du premier coup.

Pas  mal de boîtes optimisent le time-to-market et s’en foutent de produire du soft moisi, mais ça n’a absolument rien à voir avec le besoin d’un compilateur qui produit rapidement des binaires.

Le 06/04/2016 à 08h 00

La question de “en combien de temps” et “avec quels moyens techniques” a quand même son importance, si la réponse à l’une des deux devient démesurées, le pari est plutôt bien tenu.

Le 03/02/2016 à 14h 09

HarmattanBlow a écrit :

Mais pour beaucoup de problèmes on se fiche complètement des considérations mémoire. Devoir prendre le temps d’y penser est un fardeau de plus qui accroît inutilement la complexité du développement.


Oui et non je trouve. La très vaste majorité des ressources n’ont pas besoin de considérations particulières pour ce qui est de la manière dont elles vont être libérées et ne sont référencées que depuis un unique point tout au long de leur existence.

Dans le bordel qui reste, il y a celles qui vont être organisé en un micmac qui ne bougera jamais ou presque, et il reste les cas compliqué, où là effectivement le GC nous aide pas mal.




HarmattanBlow a écrit :

 Cela
dit note que Rust n’a pas de GC.

 
My bad, il me semblait que c’était un GC débrayable au besoin mais ça c’est D.

Le 03/02/2016 à 13h 06

J’ai pas dit que c’était un super langage, j’ai dit qu’il n’était pas si difficile d’apprendre à l’utiliser si on se cantonne à ses fonctionnalités faciles d’usage qui sont en très grande partie les ajouts récents  qui ont été fait dedans (et comme je sens le troll stupide encore arriver : j’ai pas dit fonctionnalité récente, j’ai dit fonctionnalité récemment ajoutée).

Quant à Rust et Nim, seul l’avenir le dira. Tant qu’ils n’auront subi plusieurs épreuve du feu, notamment un usage intensif par de nombreux utilisateurs  (et son lot de râleurs), et les effets d’un peu de temps, on pourra difficilement en juger. Mais personnellement, j’aime pas l’idée d’avoir un GC par défaut quand on a sous la main un système de type qui peut nous permettre de nous en passer.

Le 03/02/2016 à 12h 35

Encore un traumatisé par les cours de dinosaures que les profs qui ne se mettent pas à jour sur ce langage dispensent massivement. Il est pourtant si simple d’utiliser ce langage quand on prend le problème par le bon bout.

Le 03/02/2016 à 10h 08

Crillus a écrit :

Tremblez développeurs ! car dans 10 ans un gamin de 11 ans saura faire aussi bien qu’un développeur chevronné. " />


T’inquiètes, on leur apprend le “code” pas le “développement”. Dans 10 ans, on leur montrera comment utiliser un papier et un crayon pour réfléchir avant de taper bêtement des lignes comme un glandu " /> .

Le 17/12/2015 à 08h 45

Allez … Prends une petite dose quoi … Tu verras ce sera bien …

Le 01/12/2015 à 12h 34

Avec un petit DLC payant pour pouvoir en profiter j’espère " />

Le 13/10/2015 à 13h 22

thib67 a écrit :

  Perso j’ai le cable a 100 méga et j’en suis très content, même si ça bug de temps a autre, ça me permet d’attendre sereinement la fibre qui est juste a 10m de chez moi, mais que je ne suis pas prêt d’avoir.


Il y a encore quelques jours, la fibre je la voyais dans mon appartement (depuis quelques mois), mon opérateur n’était juste pas relié au bloc (et pas envie d’aller payer le double chez un autre fournisseur), niveau frustration c’était pas mal. Bon maintenant j’y suis relié et la fibre au giga c’est pratique pour aspirer internet.

Le 22/09/2015 à 08h 28

Ton message précédent insinuait complètement que dans l’avionique on dépense plus de temps et d’argent à faire de la paperasse qu’à vérifier le bon fonctionnement des logiciels qu’on déploie, et qu’un type lambda peut le faire sans avoir de capacités particulières. C’est juste pas le cas.
 
Et ça ne change rien au fait qu’on ne rencontre quasiment jamais d’autodidactes sur de tels systèmes.

Le 21/09/2015 à 11h 03

C’est sûr, dans l’avionique on se contente d’un ou deux tests sur le logiciel, on pourrait même en faire moins que pour assurer le fonctionnement d’un site web, de toute façon les morts ne viennent pas se plaindre. Puis un logiciel d’avion c’est simple comme bonjour, pas besoin d’être bien malin pour le concevoir.

Le 18/09/2015 à 11h 33

@lyni : formation a un outil particulier sous condition de déjà connaître le contexte d’usage ? Je ne vois que ça.

Le 18/09/2015 à 11h 17

On doit pas connaître les mêmes. Quant aux outils, ils ne sont que ce qu’ils sont : des outils. Le principe justement c’est d’apprendre tout ce qui va autour indépendamment des outils. C’est marrant mais tu vois quand on fait des logiciels pour mettre dans un avion, on rencontre pas des masses d’auto-didactes.

       

En fait quand on veut des vrais assurances de fonctionnement (comprenant une analyse de risque), il y a plus beaucoup d'autodidactes.

Le 28/07/2015 à 12h 00

Ah ben quand même.

Le 01/07/2015 à 12h 51

Ce n’est pas parce que tu as (et que bien d’autres ont) dû galérer que :

• c’est normal,
  


• ça ne doit pas continuer à changer.
  
  Stagiaire ou pas, 500€ de gratification pour payer un loyer, des charges, des transports et des repas, même en dehors de la région parisienne c’est loin d’être évident.

Le 19/05/2015 à 15h 52

ErGo_404 a écrit :

Le problème c’est que dans les environnements “contraints” tu n’as pas toujours accès à un compilateur qui suit la dernière norme.

J’ai toujours eu du mal avec l’approche pédagogique “commençons par l’environnement contraint”.


ErGo_404 a écrit :

Maintenant si ce que tu dis est vrai, j’aimerais bien avoir un tuto qui couvre directement le C++ “moderne”. J’en suis effectivement resté au C++ “surcouche de C”, en sachant que le C lui même ne me convenait pas.

Le cours de @gbdivers est encore en construction mais adopte une approche moderne.

Le 19/05/2015 à 15h 29

bast73 a écrit :

Pour ce qui est du C/C++, je trouve ça assez imbuvable. Quand on compare au java/C# on en est quand même loin ! Alors certe ce n’est pas optimisé, et pas vraiment optimisable du fait de leur fonctionnement, mais c’est quand même bien plus facile à lire et plus simple à écrire. 


Autant si je suis globalement d’accord avec @HarmattanBlow sur un certain nombre de points quand à la lourdeur de C++ due  son passif. Et pas trop d’accord quant à la promotion des langages à GC par défaut. Il faut ne pas avoir codé en C++ depuis les normes 11 et 14 pour dire que C# et Java sont largement plus accessibles. Aujourd’hui en terme d’écriture et de lecture, la différence est hyper ténue et pour certaines choses la bibliothèque standard de C++ est simplement plus puissante (à noter : puissante, pas fournie).

Le 19/05/2015 à 12h 26

Dépend des cas, justement parce que les templates permettent des optimisations assez bourrinnes (l’exemple typique c’est std::sort VS qsort <- grillé par @white_tentacle xD). Sans compter qu’un code plus facile à lire c’est aussi un code plus facile à optimiser si cette facilité n’est due pas à un manque d’expressivité.

Quant à ta remarque sur la complexité d’apprentissage de C++, c’est principalement dû au fait que les enseignements de ce langage se font à la mode historique (du C avec des classes) alors que d’une part la gestion des ressources dans un langage à exception, ça se fait pas manuellement si on n’est pas maso (en C++ le RAII, ça sauve des vies) et que d’autre part, il est très facile d’écrire en C++ avec une approche moderne comme celle qu’introduisent les dernières normes.

Le 19/05/2015 à 11h 09

brokensoul a écrit :

Je suis surpris de voir c++ plus lent que c par contre


Pareil. J’aimerai bien voir la tronche du code benché (oui, benché). Je n’arrive plus à mettre la main sur le post en question mais il me semble que par exemple Ms était en réécriture de parties de Windows depuis C vers C++ pour justement gagner des performances.

Le 27/04/2015 à 08h 15

Vu samedi. Deux ou trois what-the-fuck niveau cohérence dans le film, ça peut déconcentrer si on s’y attache ne serait-ce qu’une seconde. L’un des combats est définitivement trop long d’autant qu’il n’apporte rien à l’histoire à part un peu de temps (du gros meublage, hein, faut pas se leurrer) à bourriner des bâtiments. Hawkeye est développé dans le bon sens mais pas assez, un peu décevant parce qu’à part lui et Black Widow, les avengers me laissent de marbre … (sauf Iron Man, lui il me gonfle sauf quand il troll bêtement).

Bref c’était sympa mais pas transcendant.

Le 17/04/2015 à 11h 42

js2082 a écrit :

Jamais compris l’intérêt pour ce genre de “jeux” (qui sont tout sauf des jeux).

Surtout qu’au prix où ils te vendent le jeu + les accessoires, autant s’acheter directement une vrai guitare ou une vrai basse, pour faire de la vrai musique.

1. Pourquoi ce ne serait pas des jeux ?
   


2. Avec  un kit rockband acheté dans une bande de potes, il y a moyen de jouer à plusieurs pendant des soirées entières sans problème ce qui n’est pas possible avec une seule vraie guitare.
   


3. Le but c’est de jouer, pas de faire de la vraie musique.

Le 17/04/2015 à 11h 37

Pour RockBand, s’ils font comme les précédents, tout le contenu que tu avais acheté sur une version était disponible sur toutes les suivantes. Et certains jeux (ex: Lego RockBand) s’accompagnaient de code d’export pour balancer les morceaux dans toutes les autres versions de RockBand qui serait utilisées sur la console. L’export de RockBand 1 et 2 à Rockband 3 était (de mémoire) gratuit et automatique.

Le 10/04/2015 à 12h 23

vampire7 a écrit :

Au fait, tu devrais arrêter de parler de “code concurrent” : la programmation concurrente, ça peut être aussi l’accès à une ressource système partagée à travers différents processus. […]


Oui enfin, quand on parle de code qui peut accéder à une même adresse mémoire, ça reste du code concurrent, même si le code concurrent ça inclut aussi l’accès aux ressources systèmes. C’est pas moi qui ait choisi le nom. Et comme le code multi-thread n’est pas nécessairement concurrent, j’éjecte ce terme, parce que s’il n’y a pas d’accès concurrent, le problème est facile.

 


vampire7 a écrit :

Malgré ça, je préfère quand même lire de la doc plutôt que les réflexions des grands penseurs de la programmation.


Et c’est généralement à partir de là que j’arrête de répondre. Les grands penseurs en question, ils se sont cassés le cul à transformer d’énormes passages de documentation (la norme) complètement imprécise en formalisation, en la gardant compréhensible par un humain (c’est d’ailleurs comme ça qu’ils ont trouvé pas mal de bourdes dedans). L’idée de “j’en ai rien à carrer c’est juste des scientifiques qui se font mousser, pas besoin de les écouter”, quand elle tombe, j’abandonne le dialogue.

Le 10/04/2015 à 08h 26

Bon je n’ai pas pu éditer à temps, donc mon edit :

Le modèle C++11 est plutôt bien foutu mais il y a encore quelques soucis à régler pour que le degré de confiance qu’on est sensé lui accorder soit effectivement celui qu’on a même en présence d’optimisations. En particulier, pour du code concurrent très bas niveau, où grosso modo la preuve devient plus facile et bien plus fiable que le test, on aimerait que lorsque l’on établit une preuve de correction en prenant en compte le modèle mémoire, le compilateur n’est pas susceptible de tout casser lors de la phase d’optimisation (à noter : Compcert TSO est sensé apporter ce genre de garanties pour C11, mais je ne sais pas où en est son développement).

Le 10/04/2015 à 08h 16

vampire7 a écrit :

Je ne parle pas d’une info que j’aurais vaguement lue quelque part, je parle de ce que je vois et de ce que je fais, avec un temps fou passé à regarder le code ASM produit par le compilo.


Qui a dit j’avais “vaguement” lue cette info ? Les modèles mémoire faibles, en particulier celui de C++11 et ses implications sur le parallélisme bas-niveau, c’est un sujet plutôt fertile en ce moment dans la recherche. Et les gens qui en parlent (Vafeiadis, Zappa Nardelli, Alglave …) c’est pas des glandus.
Et grosso-modo, à moins de rendre tout volatile (et bon ben adieu les performances), les cas d’erreur qui peuvent tomber une fois tous les cent milles exécution mais qui provoquent derrière de vrais bugs peuvent être produit par des optimisations qui bien que sound dans le cas d’un code séquentiel ne le sont plus dans le cas concurrent.

Evidemment, ça arrive pas tous les trois jours (enfin sauf si tu t’amuses à construire les exemples qui vont mettre la bringue dans le compilo), mais quand un code plus rapide parce qu’optimisé provoque un crash violent dans une application qui tourne H24/J7, que le bug tombe aléatoirement tous les 3 ou 4 jours dans une fonction exécutée 30k fois à la minute et que c’est dû à une optimisation trop méchante du compilo sur du code valide, tu l’as mauvaise.

Le 08/04/2015 à 12h 47

vampire7 a écrit :

Quand on sait que en -O3 (pour GCC), le compilo garde autant que possible dans les registres CPU les variables locales et écrit sans trop attendre les variables globales, il y a rarement des mauvaises surprises.
Et il y a le préfixe “volatile” si tu veux vraiment être sûr.


Non, ça ne suffit pas. Loin de là surtout si tu veux des performances (et sur de la concurrences très bas niveau, tu veux de la performance). Voir l’article récent de Vafeiadis et al. sur les optimisations de compilateurs.

Le 07/04/2015 à 14h 50

Et typiquement sur du code fortement métaprog, clang est encore en retard sur les exécutables que peut produire gcc. Par contre effectivement, il est bien plus rapide pour compiler et l’affichage des erreurs est plus clair.

Par contre comparer les performances ça devient compliqué, en présence de code concurrent très bas niveau, les compilateurs font de toute façon des optimisations qui sont unsound, donc ça devient un peu chaud de déterminer lequel produit des exécutables rapides ET corrects " /> .

Le 17/03/2015 à 16h 01

Je ne sais pas si tu faisais référence à mon premier message mais si c’est le cas, il faut arrêter de voir le mal partout. C’est juste une interrogation, on a des stats à propos du gain potentiel en espace, mais rien à propos du surcoût même léger, et ça a son importance, rien n’est gratuit.

Le 17/03/2015 à 13h 17

La question c’est “et quid de la consommation ?”. Les machines pour lesquelles est destiné ce système sont certes très limitées en espace mais aussi (et surtout) en énergie.
 
Si on ne veut pas voir la consommation exploser, il va falloir un algo diablement intelligent pour déterminer ce qui doit, ou ne doit pas, être compressé et quand (et bien entendu, cette heuristique, c’est encore de l’énergie qui va être bouffée). On a beau ne pas avoir une baisse de performances, la décompression n’est certainement pas gratuite.

Le 17/03/2015 à 14h 34

Ce sous titre.

Le 28/01/2015 à 10h 33

emacs > all.

Le 28/01/2015 à 10h 05

white_tentacle a écrit :

Oui, ça fait de la mitigation, pas de la sécurité absolue. De toute façon, la sécurité absolue, ça n’existe pas (les hyperviseurs, que ce soit kvm ou xen, ont eux aussi régulièrement des failles — je ne suis pas sûr pour celui de Microsoft, qui a fait l’objet de preuve de programme).

  L'hyperviseur en prod actuel de Microsoft n'a pas fait l'objet de preuve. Les travaux autour de la vérification d'hyperviseur chez Microsoft Research/Saarlands University (principalement par Alkassar, Cohen et Schirmer et basés sur des travaux de Starostin et Tsyban) concernent un prototype simplifié et assez éloigné de l'implémentation réelle. Les éventuels travaux pour un hyperviseur réel vérifié qui pourrait venir d'eux ne sont à l'heure actuelle pas publics.     

 Un bon exemple de micronoyau vérifié est plutôt seL4 mais est plus destiné à l'embarqué qu'à la virtualisation. Après une bonne part des concepts restent les mêmes. Aujourd'hui la vérification formelle (conformité (quasi-)parfaite à une spec) d'un logiciel de ce genre, c'est possible mais ça reste méga cher (25 PY pour les 10k loc de seL4).

Le 26/01/2015 à 09h 34

MasterCloud a écrit :

Bonjour, on fait des benchmarks sur un navigateur en développement puis on fait remarquer que faire des benchmarks sur un navigateur en développement est un peu idiot. 

Ils n’ont pas dit que c’était idiot. Ils ont dit que les résultats seront probablement très différents dans la version finale. Et finalement, c’est au contraire hyper intéressant de voir comment un logiciel évolue au fil des changements qui y sont apportés (c’est encore plus intéressant quand on a accès aux sources évidemment :) ).

Le 19/01/2015 à 15h 18

Ben non ils sont parfaits.

Le 19/01/2015 à 14h 16

Hahaha ! La réponse qui tue, j’en ai pas vu, donc ça n’existe pas.