Le 05/11/2014 à 15h 17

Et surtout Vista n’etait pas si pourri que ca….

C’est lui qui a amené la base technologique de tous les windows suivants (y compris 7 qui a été adulé) . Mais bon c’était une v1. Les utilisateurs n’aiment pas les v1 " />

Le 29/10/2014 à 17h 35

J’ai vu passer plusieurs tweets il y a quelque temps sur office. Apparemment la prochaine version Modern d’office partage en très grande partie le code avec les versions Android et iOS

source

source2

Le 29/10/2014 à 14h 31

atomusk a écrit :



Au final, ça serait quoi “concrêtement” la différence avec le store Ms ?  " />" />" />



ca pourrait pas juste être une interface graphique pour se connecter au store MS ?





Je me trompe peut être mais ça a l’air d’être axé plutôt pour les entreprises que le grand public.



Ensuite ça permet d’installer des applications win32. Le store permet seulement l’installation d’applications WinRT. Même si sur Windows 10 on devrait pouvoir installer certaines applications Win32.

Sur les documents que j’ai lu sur le sujet c’est présenté comme une solution unifiée (d’ou le nom OneGet). Peut être (simple supposition) que c’est une base d’installation pour Windows 10 qui pourrait aussi être utilisée par le store??

Il faudra attendre plus d’informations sur le sujet mais ça a l’air intéressant.

Le 24/10/2014 à 14h 48

Quand je disais qu’aucun test ne pouvais être fait pour détecter le problème, je parlais de tests logiciels. Si tu as le source code c’est autre chose….

Le 24/10/2014 à 14h 38

Ah bon je ne savais pas que les constructeurs donnaient le source code de leurs drivers à Microsoft?

Ce n’est pas passé sur Linux car les gens qui intègrent les drivers au noyau Linux vérifient le code. Sans le source code tu ne peux pas empêcher ce type de problèmes.

Le 24/10/2014 à 12h 22

Oui tu peux remettre le bon vid avec un utilitaire normalement.

Par contre je pense que le nom du driver dois apparaître dans les mises à jours.

Le 24/10/2014 à 12h 12

Si le changement du vid et pid se fait au chargement du driver, le mal est déjà fait…..

Le 24/10/2014 à 11h 51

Voir mon commentaire plus haut. C’est le constructeur qui choisit ses machines de tests pas Microsoft. Le serveur Microsoft se contente de vérifier que les tests sont bien valides. Donc si le constructeur a effectué ses tests sur son propre matériel officiel les tests whql passeront.

Ensuite au risque de me répéter aucun test ne peut être fait pour détecter ce problème.

Le 24/10/2014 à 10h 10

Il doit envoyer une commande USB personnalisé qui permet de modifier cette information sur leur matériel. Seul FTDI sait le faire. Comme je l’ai expliqué au dessus c’est propre au matériel.



Ils ne vont pas exclure un contructeur sur Windows Update. Après les gens gueuleraient car il n’auraient plus de drivers. Légalement ils risquent surement d’avoir des problèmes.



Pour la publication sur Windows Update, j’apporte une précision. Les soumissions de driver HCK (WHQL) ou WLK (Windows Logo) sont nécessaires pour pouvoir publier son driver sur Windows Update. A ma connaissance il n’est pas possible de publier un driver non certifié par Windows Update.

Le 24/10/2014 à 09h 53

Non il ne teste pas les matériels. Comme je l’ai expliqué au dessus la procédure de publication des drivers est automatisé

Le 24/10/2014 à 09h 21

Pour avoir moi même valider mes propres drivers en whql c’est une procédure totalement automatisé par Microsoft. En fait tu vas lancer une série de tests sur différentes machines clientes qui dépendent de la classe du driver. Si ces tests passent un fichier de résultats signé par un certificat est crée. Ensuite par le portail développeur dédié tu envoies ce fichier. Coté serveur il y a une série de vérifications automatiques qui se lancent et Microsoft renvoit au développeur le driver signé avec le bon fichier .cat WHQL.



Pour la reprogrammation du vid , c’est propre au matériel. C’est impossible de le détecter. Et comme Sepas l’a écrit avant ils ne peuvent pas tester les drivers sur l’ensemble des matériels compatibles. je suis plutôt bien placé pour en parler.

Le 24/10/2014 à 07h 35

+1 j’ai le même problème avec ma-config.com les gens sont persuadés que je teste chaque driver alors que c’est totalement impossible " />

Le 23/10/2014 à 12h 47

Par rapport au paragraphe sur les jetons d’identifications dans un conteneur virtualisé ça ressemble fortement au fonctionnement de NGSCB 



« With Windows 10 we aim to eliminate this type of attack with an architectural solution that stores user access tokens  within a secure container running on top of Hyper-V technology. This solution prevents the tokens from being extracted from  devices even in cases where the Windows kernel itself has been compromised. »



  Source     Source2     « The Nexus may be implemented, for example, by combining a virtual-machine hypervisor with a trusted guest operating system» Source3 « Prototyped a guest-partition authorization infrastructure that integrated components from the Singularity research 

operating system, the SecPAL authorization engine, and the Hyper-V hypervisor. »



                  Source4                        

  NGSCB était un os de sécurité qui tournait séparément de Windows dans une machine virtuelle pour gérer la sécurité dans Windows.

Par la suite ils ont bossé sur un projet similaire qui se base sur un noyau Singularity et SecPal.

Le 23/10/2014 à 06h 49

+1 moi ça me fait furieusement penser au concept d’un os de sécurité comme NGSCB. Tu avais un mini OS de sécurité isolé qui gérait toute la sécurité de Windows Sur les papiers que j’avais lu c’était censé  fonctionner dans une VM séparée.

Je sais aussi qu’ils ont travaillé sur un projet similaire où l’os de sécurité était singularity.

Le 22/10/2014 à 10h 38

Davis Treadwell le vice président de la division os group a été interviewé il y a 15 jours. Il a admis que beaucoup de fonctionnalités de drawbridge et Midori ont été intégré dans Windows. A suivre d’ici quelques mois…



source



What’s happening about Microsoft’s research OS projects now they’re part of the Windows team, and now Rick Rashid – a veteran OS researcher – has moved from running Microsoft Research to be in Windows?Mostly, it’s been an organisational change, Treadwell told us. “We are integrating all of the company’s OS product engineering work into the OS Group; it was very dispersed before so having technologies like Midori and Drawbridge and all the rest of them within the OSG means we can look at those concepts and see if we can make them part of the platform and we’re looking at those.” Indeed, he said, “there’s a lot of that functionality that is now part of Windows.”

Le 20/10/2014 à 14h 17

HarmattanBlow a écrit :



Nous verrons mais, non, je ne gueule pas. Je ne suis pas dans la position de l’utilisateur exprimant son mécontentement, je suis dans celle du professionnel exprimant son scepticisme sur l’avenir d’un produit dont les résultats conditionneront le marché.





J’ai bien compris que tu étais sceptique qui est toute somme logique " />

Le 20/10/2014 à 13h 53

Non c’est bien quantum leap c’est une erreur dans la news. D’autres sites l’ont bien reporté:

source



 There’s a single app ecosystem, a single developer environment, and a single store. It’s a quantum leap.” 

Les mises à jours vers Windows devraient être gratuites ou en tout cas à bas prix. Avec la base Midori le système devrait être beaucoup plus petit sur tablettes et smartphones.



Pour le design tu te plantes totalement tout vas changer. La gueule de l’interface n’aura rien à voir avec ce que tu vois là. J’ai eu la même attitude de rejet au départ. Mais mon contact a pu apparemment voir ce que ça donnera au final. Il m’a explique qu’il n’y a quasi rien d’intégré pour le moment. Enfin bref tu gueules encore avant d’avoir mal…

Le 20/10/2014 à 12h 34

HarmattanBlow a écrit :



Peu importe XAML, c’est une question de design. Ils conservent le même design.



Non on a pas encore vu le design final c’est une alpha. Arrête de crier avant d’avoir mal. Cette alpha avait un but unique récupérer les feedback des utilisateurs.



 

Tony Prophet a été interviewé

Il parle de saut quantique pour Windows 10 tellement les modifications sont énormes.



Windows 10 is not going to be an incremental step,” Prophet promised, describing it as a “quantum step” in trying to create one platform — one ecosystem — uniting millions of embedded devices that make up the Internet-of-Things movement, from the Surface tablet to the Xbox. “We’ve seen a very dramatic shift at Microsoft in a short period of time,” observed Benioff, noting this turnover was capped off by a very significant leadership change.                               Même pour Vista , jamais un employé Microsoft n’a sorti de telles choses publiquement. Ca se retournerait contre eux si c’était faux.De plus je n’aurai jamais sorti de telles choses si ça ne m’avait pas été confirmé en interne…

Le 20/10/2014 à 11h 41

HarmattanBlow a écrit :



Le grand public ne sait même pas ce qu’est Windows 8 et les entreprises en sont encore à XP/Vista, ce n’est pas une nouvelle version de l’OS qui va inverser la tendance, on s’en cogne. D’ailleurs Vista était pourri et ça n’a pas empêche les PC équipés de Vista de se vendre comme des petits pains.



Ce que le grand public voit c’est que les machines Windows sont plus chères et, selon beaucoup, moins jolies sur les rayons (car Metro est quand même souvent laid). Ce que les entreprises voient c’est que les machines Windows sont plus chères et que de toute façon l’entreprise est en train de déporter son écosystème vers js/java. Et ce que les deux marchés vont bientôt voir c’est que les chromebooks feront tourner les applis Android.



 

Beaucoup de trolls en quelques lignes…

Les PC Vista ne sont jamais vendus comme des petits pains. Les gens sont restés sur XP vu la mauvaise pub, ou au pire réinstaller XP dessus. Arrête de réécrire l’histoire. J’étais en première ligne et j’ai très bien vu ce qui se passait à l’époque. Windows 7 a justement relancé la vente de PC.

 

Quand tu dis que ce n’est pas une nouvelle version de l’OS qui va inverser la tendance c’est justement ce qui s’est passé avec Windows 7…

Pour le look métro justement il n’y aura plus de start screen sur les PC. Et l’interface de Windows 10 va complètement changer avec la réécriture en XAML. Ce que tu vois pour le moment c’est une pre alpha. C’est amené à complètement changer.



Les entreprises se déportent sur le cloud. Microsoft explose ses chiffres avec Windows Azure.C’est amené à encore augmenter.



Pour les applications android sur chromebook je vois que tu as gueulé sur Windows 8 qui imposait une interface tactile sur PC mais que ça ne te pose pas problème si Google fait pareil.

Les applications android sont des sous applications. Le jour ou on aura un photoshop sur android je changerai d’avis.  Android ne peut pas concurrencer Windows sur le PC comme Windows 8 ne peut concurrencer android sur mobile.

Le 20/10/2014 à 11h 13

HarmattanBlow a écrit :



Les netbooks avaient mis trois ans pour atteindre 10% de pdm des notebooks quand Chrome OS a atteint 30% en deux ans. Et ce sont évidemment les tablettes, et non W7, qui ont mis fin à l’ascension des netbooks.



D’ailleurs contrairement à Chrome OS les netbooks ne se sont jamais posés en remplaçants des portables ou des ordinateurs en général, il ne s’agissait que d’un format plus petit pour les niches où l’on avait besoin d’un format très petit ou très bon marché.



Enfin ces 30% de pdm conquis ne sont pas une projection mais un fait.





Le grand public ne sait même pas ce qu’est Windows 8 et les entreprises en sont encore à XP/Vista, ce n’est pas une nouvelle version de l’OS qui va inverser la tendance, on s’en cogne. D’ailleurs Vista était pourri et ça n’a pas empêche les PC équipés de Vista de se vendre comme des petits pains.



Ce que le grand public voit c’est que les machines Windows sont plus chères et, selon beaucoup, moins jolies sur les rayons (car Metro est quand même souvent laid). Ce que les entreprises voient c’est que les machines Windows sont plus chères et que de toute façon l’entreprise est en train de déporter son écosystème vers js/java. Et ce que les deux marchés vont bientôt voir c’est que les chromebooks feront tourner les applis Android.



Au minimum MS doit rendre Windows gratuit.





Office est disponible sur OSX et iOS (et sans doute Android) et il y a de toute façon une migration importante vers les solutions bureautiques libres. Office reste non-négligeable pour MS, de même que Sharepoint et compagnie mais si c’est la seule chose par laquelle ils retiennent les entreprises sur Windows ils ne feront que nuire à leurs solutions. Enfin les entreprises vont de plus en plus vers des solutions portables et libres et migrent tout ou partie de leur écosystème. Et je rappelle que des solutions comme Wine et d’autres sont disponibles pour migrer vers d’autres OS si seulement 5% des applis posent problème.



Il me semble évident que MS cherchera à préserver ses solutions d’entreprise en les rendant accessibles depuis Android / Chrome OS plutôt que de chercher à préserver Windows au risque de nuire à ses autres solutions.





Tu as apparemment compris mon message de travers : je disais que Singularity ne représentait pas un avantage compétitif significatif pour Windows, je ne parlais pas des évolutions de Windows ces dix dernières années.





Cela fait très longtemps que tu peux acheter pour quelques milliers d’euros des fichiers contenant des dizaines ou centaines de millions de numéros de carte de crédit avec les informations sur les propriétaires. C’est parce que le réseau bancaire s’est entendu pour rendre les transactions annulables pendant N jours et maintenir des délais de carence qu’il n’y a pas plus de fraudes bancaires pas parce que les données bancaires seraient difficiles à obtenir ou leurs algorithmes inviolables. Nos ordinateurs sont des passoires depuis très longtemps sans que ça ne dérange grand monde. Quant aux données personnelles tu n’as pas besoin de les voler, l’utilisateur te les donne. Au pire tu peux là aussi acheter des fichiers tout faits ou louer les services de sociétés spécialisées.



Si un jour une “apocalypse numérique” se produit ce sera au niveau de serveurs critiques ou d’équipements répandus et critiques (avion, voiture, etc), ou ce sera une faille dans les algorithmes sous-jacents à une monnaie virtuelle ou à un système de vote électronique. Rien qui concerne le système d’exploitation de Mme Michu.





Pour chrome OS t’es mignon mais j’ai trouvé une étude sur d’amérique du nord . Chrome os c’est 0,2% du trafic web ,c’est pire que Linux. Et apparemment au niveau mondial ça atteint pas 1% des PC sur d’autres études.

 

 Pour les BSOD tu n’as apparemment pas compris mon message. Si windows 10 intègre les technos Midori tu n’auras plus de BSOD sur ce système provoqué par des erreurs logicielles. Sachant que même certaines erreurs matérielles temporaires pourront aussi être évitées. Les gens crient sur Windows depuis des dizaines d’années sur ce sujet. J’imagine que ça aura son petit effet. Surtout que ce ne sera pas le cas sur la concurrence.

Sans compter que le système de SIP n’est pas étendu aux driver mais à tout type d’extension. Fini par exemple les shell extension qui font planter l’explorateur. Quand l’extension ou le driver plantera , la cause sera très facilement repérérable. J’ai moi -même codé un analyseur de fichiers dumps kernel.  Ca ne marche pas toujours car les drivers partagent le même espace mémoire avec le noyau. 

 

Pour la sécurité en effet ça se jouera surtout sur les serveurs. Mais ça tombe bien Windows 10 devrait sortir en version serveur. de plus Midori a été vraiment pensé pour les appareils connectés. C’est évident que la sécurité est importante pour ces appareils qui rentrent complètement dans notre vie.



D’une part l’informatique est malheureusement remplie de produits qui étaient meilleurs mais ont échoué. 



C’est sur mais si le produit n’est pas meilleur c’est perdu d’avance. Ce qui me gène dans ton raisonnement c’est que google sont des dieux et quoi que Microsoft fasse ils ne réussiront pas. En l’occurrence ils se donnent vraiment tous les moyens de le faire. A voir si ils vont réussir mais tu ne peux pas les condamner d’avance.

 

Le 16/10/2014 à 16h 31

HarmattanBlow a écrit :



D’une part l’informatique est malheureusement remplie de produits qui étaient meilleurs mais ont échoué.



D’autre part les bénéfices pour les utilisateurs sont loin d’être appréciables :



* Plus de sécurité ou de performances pour le nuage par rapport aux autres modes de virtualisation, c’est le plus fort gain. Mais en pratique le surcoût actuel est déjà tombé très bas et il n’est pas dit que ça se traduise en avantage compétitif significatif pour MS.



* Plus de sécurité pour les utilisateurs et les entreprises qui n’en ont en réalité pas grand chose à faire, sinon les anciens Windows n’auraient jamais fonctionné. Quant aux gains sur les performances sur un usage typique ils seront négligeables.



* Très riches possibilités à long terme concernant la granularité de la concurrence et la distribution sur du calcul hétérogène. Oups, il y a “long terme” dans la phrase.





Plus de BSOD me dis pas que c’est rien. Vu le nombre impressionnant de messages sur ces 10 dernières années sur le sujet. Ah en fait c’étaient juste des trolls pardon " />

Pour le parallélisme on a déjà des processeurs à plusieurs coeurs qui sont pas franchement exploites. C’est pas du long terme.

 

Pour la sécurité quand tu auras eu une bonne apocalypse numérique où les gens se seront fait piquer leurs numéros de cartes bancaire et toutes leur vie privée sur smartphone on verra si les utilisateurs penseront toujours que la sécurité est accessoire. C’est déjà impressionnant ce qu’un hacker peut récupérer facilement sur un smartphone. Si rien n’est fait c’est ce qui arrivera.

Pirater un smartphone a beaucoup plus d’incidence que pirater un PC.

Le 16/10/2014 à 16h 22

Pour chrome OS, ça me fait penser aux netbooks où Microsoft était dans la même situation après Vista. Je me rappelles des commentaires à l’époque, les mêmes que les tiens qui prédisaient la chute de Microsoft. Puis Windows 7 est sorti et on sait tous les deux ce qui est arrivé avec les netbooks.

Chrome OS profite du fait que Windows 8 a fait un bide. Mais le menu démarrer est revenu (" />), il y a pour le moment plus de gens qui sont content de la preview de Windows 10 que le contraire.  Sur PC le succès est quasi assuré.

Par contre sur mobile je suis tout a fait d’accord que ça va être beaucoup plus difficile même si Midori sortait. Après sur la durée avec la stratégie d’unification ça devrait payer. Surtout que les gens sont pas près d’abandonner Windows sur PC à cause du trop grand nombre d’applications bureautiques disponibles. Dans les entreprises c’est encore plus cloisonné. Si microsoft sur le court terme garde son monopole sur le PC, Ca le permettra de s’étendre sur le long terme pour le mobile.

Le 16/10/2014 à 15h 52

HarmattanBlow a écrit :



Dix ans c’est la durée depuis laquelle on entend parler de Singularity/Midori.



Pour le reste la première partie est une provocation, la seconde une clarification. Et pour W10, disons que je m’attends à ce que Chrome OS et Android continuent de progresser en pdm.





Au diable les vagues déclarations, je demande à voir un produit.





Singularity 2003(11ans) - Midori 2008(6 ans) -  Drawbridge 2011(3 ans). Tu imagines bien qu’ils allaient pas réécrire un os en 5 ans. Ce genre de choses prend du temps 

Pour Chrome OS et Android si le travail de Midori est effectivement intégré dans Windows 10 je parierai pas la dessus. Je suis bête je crois encore que si un produit est bien meilleur il peut marcher…..



Ce n’est pas une vague déclaration c’est très clair. Pour le produit j’attends aussi de le voir. A mon avis ça se compte en mois maintenant.

Le 16/10/2014 à 15h 33

HarmattanBlow a écrit :



Personnellement je me cogne un peu de ces déclarations. De toute façon ça fait dix ans qu’ils ressassent les mêmes projets dont on ne voit jamais la couleur et le jour où ils semblent enfin avoir passé à l’action je ne suis pas sûr que Windows existera encore d’ici là.



Alors, oui, bien sûr que Windows existera encore dans cinq ans, mais Cobol et les Mainframes IBM eux aussi existent encore.



Et non ce n’est pas un troll, c’est ce que je pense réellement et c’est la frustration de quelqu’un qui pense que la plateforme Windows est meilleure et préférable à Android, IOS et OSX. Et ceux qui croient que j’ai tort pourront regarder les 30% de pdm conquis en deux ans par Chrome OS sur les notebooks aux USA et le demande des utilisateurs et des entreprises pour homogénéiser leur parc applicatif sur PC et téléphone.





Il faut savoir tu dis que windows n’existera plus d’ici là et après qu’il existera toujours dans cinq ans. Windows 10 sort l’année prochaine pas dans cinq ans ou dix ans.

Ensuite c’est la première déclaration officielle sur le sujet,de plus par une personne concernée. Ses propos sont plus que clairs.

Le 16/10/2014 à 12h 34

David Treadwell a été interviewé C’est le vice président de l’operating systems group chez Microsoft. Il a été interrogé sur Midori:



 What’s happening about Microsoft’s research OS projects now they’re part of the Windows team, and now Rick Rashid – a veteran OS researcher – has moved from running Microsoft Research to be in Windows?Mostly, it’s been an organisational change, Treadwell told us. “We are integrating all of the company’s OS product engineering work into the OS Group; it was very dispersed before so having technologies like Midori and Drawbridge and all the rest of them within the OSG means we can look at those concepts and see if we can make them part of the platform and we’re looking at those.” Indeed, he said, “there’s a lot of that functionality that is now part of Windows.” 



Apparemment plusieurs fonctionnalités de drawbridge et Midori  ont été intégrées dans Windows.  Ca confirme ce que j’ai appris en interne(hélas je peux pas en parler " />)Il existe aussi des références à un Modern Core dans le sous système Win32 de Windows 10.Maintenant la seule question qui se pose est quelles fonctionnalités ont été choisies pour être intégrées dans Windows 10?…      source

Le 15/10/2014 à 13h 20

atomusk a écrit :



Pour moi, si la théorie est possible, dans la pratique c’est prendre des risques énormes, les combinaisons de version/driver/soft installés de différentes versions ferait que pour estimer si on est dans le risque limité ou risque minimum ferait perdre un temps dingue et déclencherait des instabilités du système dans certains cas.

 Ca me rappelle les drivers qui s'installent parfaitement bien sans reboot, tout fonctionne, sans souci, par contre à la fin de l'install il te demande quand même de rebooter ...       

Et franchement avec un PC moderne, c'est pas pour le temps que prend un reboot ...      

Et oui, la question est TRES différente pour un serveur.

Pour Windows c'est sur que ça poserait problème. Pour Singularity l'un des piliers de base qui est peu énoncé est que toutes les applications et composants du systèmes intègrent un manifeste qui décrit absolument tout. Le système a une vision complète d'absolument toutes les dépendances et les ressources. J'ai pas étudié en détail mais ça va très loin. Dans les papiers ils parlent de "zero administration"     

Et l’un des but des systèmes avec Micro-Noyau est d’avoir un micro noyau très léger qui est capable de redémarrer ou récupérer n’importe quel service ou application gravitant autour. Ca implique aussi une plus grande modularité de ce qu’on trouve maintenant.  Ne pas redémarrer le système pour une mise à jour  de composants systèmes fait parti des travaux de recherche sur le sujet.

Le 15/10/2014 à 13h 00

Indication supplémentaire sur le restart manager. Il faut que l’installeur le gère. C’est le cas pour les MSI. Mais bon vu que sur Windows il n’y a jamais eu d’unification des installeurs sur Win32, n’importe quel .exe peut devenir un installeur. je pense que beaucoup d’installeurs sur le marché ne gère toujours pas le restart manager.

Le 15/10/2014 à 12h 42

levhieu a écrit :



Maintenant, ce qui existe, ce sont des programmes qui doivent tourner sans s’arrêter conçus pour prendre en compte ce genre d’évènement.





Oui il existe depuis Vista des mécanismes où le restart manager de Windows informe les applications d’une mise à jour . Il est possible de sauvegarder l’état de l’application(c’est le développeur qui doit le gérer) avant d’arrêter l’application et de recharger l’état après la mise à jour. Mais comme toujours ça dépend du bon vouloir des développeurs. Peu d’applications le gèrent.

Par contre si c’est un dll système de base qui est mis à jour je doute que ça fonctionne…

Le 15/10/2014 à 09h 24

charon.G a écrit :



Sinon Microsoft travaille aussi sur ce sujet avec DrawBridge:

 

Serialization and deserialization of running processes offer end users new functionality even if applications are never migrated to a new machine. For example, instead of closing applications for an OS reboot, the applications could be serialized to persistent storage and then restored after the reboot. 

 

source





Pour ceux qui sont allergiques à l’anglais je fais une description rapide. C’est une méthode différente de celle décrite plus haut.

Si l’os doit être redémarré drawbridge sauvegarde l’état mémoire sur le disque dur des processus. Puis il redémarre le système hôte. Au redémarrage drawbridge restaure les applications dans l’état initial avant le redémarrage.

Le 15/10/2014 à 08h 41

Sinon Microsoft travaille aussi sur ce sujet avec DrawBridge:

 

Serialization and deserialization of running processes offer end users new functionality even if applications are never migrated to a new machine. For example, instead of closing applications for an OS reboot, the applications could be serialized to persistent storage and then restored after the reboot. 

 

source

Le 15/10/2014 à 07h 41

HarmattanBlow a écrit :



On est d’accord sur le fait que le système ne communique avec le reste que par contrats, on n’est pas d’accord sur ce que ça implique pour les bibliothèques.



Prenons l’exemple du gestionnaire de fichiers. Tu as un processus gérant celui-ci et on ne peut communiquer avec lui que par contrats. Très bien. Donc l’objet File de mscorlib va encapsuler ces contrats et exposer un bel objet situé dans mscorlib.dll, laquelle sera intégrée à ton processus. Et au final tu utiliseras ton objet File comme tu l’utilises aujourd’hui sans te préoccuper de ces contrats.



gestionnaire de fichiers ?(contrats)? mscorlib.dll ?(API normale)? application.

Les deux maillons de droite seront dans un même processus.





@PCI : quand un message contient des caractères étendus comme les flèches que j’ai utilisées, en éditant un message ces caractère sont remplacés par des points d’interrogation.

EDIT : ah ben en fait ils sont complètement virés.





mscorlib n’existe pas dans singularity. les namespace comme System.IO sont dans leurs propre assembly.J’ai vérifié en regardant les fichiers projets dans le code source.

 

Sinon sur le principe je vois ce que tu veux dire. Sauf que l’assembly wrappé(system.io) n’est pas utilisé directement en tant que lib externe comme l’est kernel32.dll par exemple . Il est compilé par bartok avec les autres assemblies et le code de l’application pour créer  un binaire unique. A mon avis il est possible de la mettre à jour et de lancer plus tard une recompilation. Sauf qu’en effet on devrait se retrouver dans le  cas ou les binaires ne seraient pas mis à jour directement.

 

Par contre ces assemblies en réalité sont des juste des wrappers vers le systèmes. Comme je te l’ai explique et tu sembles être d’accord l’application communique avec le système par contrats. Sur Windows Si microsoft corrige un bug dans un dll système comme kernel32.dll,il va être obligé de fermer toutes les applications qui l’utilisent donc de rebooter car impossible. Sur Singularity 99% du temps ils ne toucheront pas à  l’assembly wrappé mais juste au code à l’intérieur du SIP système. Du coup ils ont juste à redémarrer le SIP système incriminé et ils ne touchent pas aux applications.

J’ai vu aussi dans le code que tu peux appeler directement un sip par son contrat sans passer par un assembly intermediaire.. tu dois le specifier dans le manifeste de l’application. 

Le 14/10/2014 à 19h 47

apparemment j’ai raison :)

Je t’invite a télécharger le code source de Singularity. Ouvre ce fichier \base\Libraries\System.IO\FileStream.cs.

Si tu regardes le code apparemment, ça utilise les contrats pour communiquer avec le système.

Le 14/10/2014 à 19h 27

HarmattanBlow a écrit :



D’accord je vois ce que tu veux dire : parce que les processus légers sont isolés les uns des autres ils peuvent de facto détenir des versions différentes des binaires (pas stricto sensu puisque ces biblios ont été agrégées mais peu importe). Ok.



Cela dit ce n’est pas ce que tu expliquais initialement et tu en reviens finalement au même point qu’avec un système de fichiers versionné : la version existe tant qu’on n’a pas redémarré le processus. C’était le problème qui te dérangeait au départ et qui doit être accepté pour moi sachant qu’on dispose de moyens de le contourner ou amenuiser.



Non ce n’est pas ce que je voulais dire.  Sur ce que j’ai pu lire le système de channel avec contrats est bien censé remplacé les api systèmes. Tu as en effet la possibilité  d’inclure des assemblies dans ton application. mais bartok crée un binaire unique à l’installation qui integre tous les assemblies liées.  Mais sur ce que j’ai pu lire la communication entre l’application et le système se fait uniquement par contrats. On n’ est pas d’accord sur ce point précis. Si tu as des sources qui infirment mes propos je veux bien les voir. Ce n’est pas du tout ce que j’ai pu lire et comprendre.

Au final si tu tentes de mettre à jour un dll ça concernerait soit des SIP systèmes,ces SIP et leurs dépendances internes seraient redémarrées pour la mise à jour. Il ne seraient pas nécessaire de redémarrer les applications.

Si ce sont des dll distribuées dans l’application. Ca concernerait qu’une seule application.

Le 14/10/2014 à 18h 21

galen hunt dans un ppt expliquait que c’était une sorte d’évolution des appdomain en terme de concept.

Le 14/10/2014 à 18h 08

Sauf que les sip communiquent qu’avec d autres sip. Tu peux avoir des dll dans un meme sip mais ils sont locaux au sip. Donc si tu mets á jour un sip tu peux facilement redémarrer le sip avec ses assemblies liés.il n y a plus de dynamic load library externe partagé

Le 14/10/2014 à 17h 27

HarmattanBlow a écrit :



Quand je dis que la communication IPC est fastidieuse je ne parle pas de performances : le partage de zone mémoire est interdit (sauf exception via buffer dédié) et tout doit être copié, les échanges possibles doivent être spécifiés de façon statique sous forme d’un automate à états finis pour que le système puisse prouver qu’il n’y aura pas de deadlock, etc. C’est beaucoup plus fastidieux pour le programmeur que de simplement appeler une fonction d’une DLL, c’est le coût de la sécurité. Ce qui est acceptable parce que la communication IPC est rare.

   Non, les canaux servent à la communication interprocessus, pas aux appels de méthodes dans d'autres DLL au sein d'un même processus. Heureusement ! Sauf si tu décides explicitement d'enfermer une DLL dans un processus isolé.      

EDIT : pour clarifier, je parle du format dll, du cooncept de bibliothèques je ne fais pas référence au chargement dynamique dont j'ai moi-même dit quelques messages plus haut qu'il serait interdit.

Sauf que dans ce cas les assembly sont compilés dans le même SIP lors de la phase de l’installation  ou embarqué dans l’application. Ma théorie du départ reste valable.

Le 14/10/2014 à 16h 57

HarmattanBlow a écrit :



Mais là ce serait beaucoup plus radical comme design et tu créerais un problème beaucoup plus gros : la communication inter-processus est bien plus fastidieuse et tu dois te coltiner des problèmes de compatibilité des API plus neuves ou anciennes à tous les étages. Qui plus est, non, tu n’élimines pas le problème puisque l’exécutable lui-même ne peut pas être mis à jour ainsi.

  Oui, tu aurais certaines pages utilisant une ancienne version et d'autres utilisant la nouvelle. Ca demanderait un peu de gymnastique au niveau de la communication inter-processus pour faire face à des API trop vieilles ou trop récentes mais la communication IPC est assez rare et ça n'aurait rien d'extraordinaire pour des applications conçues pour ce genre d'environnement. Au pire le dév peut s'en tirer avec un message d'erreur disant qu'il faut redémarrer l'application.      

Mais encore une fois ce genre de choses est avant tout conçu pour le serveur, voire ci-dessus.

Si tu regardes les papiers sur Singularity. Microsoft le dit clairement le mécanisme inter-processus est beaucoup plus rapide qu'un système classique(déjà débattu la dessus et tu sais pourquoi). La creation d'un SIP est aussi très peu couteux en performance(ca se rapproche d'un thread). Si ce n'était pas le cas ils n'auraient jamais pu l'utiliser pour des drivers.     

Pour les api, les seules api dans la table d’importation de l’executable sont celles pour accéder aux services du noyau.Pour communiquer avec un dll(une extension) tu utilises un système de channels spécifiés par un contrat en Sing#. Je sais qu’ils ont séparés le code du contrat. Normalement c’est beaucoup plus facile pour gérer les changements d’api. De plus les contrats permettent de bien mieux spécifier les données échangées qu’avant.



Par contre tu peux inclure des librairies internes à la compilation avec bartok qui optimisera le code(tree shaking). Au final tout le code de l’application ou extension sera dans un même SIP. La notion de “dynamic load libraries” n’existe plus sur Singularity.

Au final les SIP sont isolés en mémoire. Et vu que les extensions tournent dans leur propre SIP,il suffit juste de les arrêter le temps de la mise à jour.  

source1 source2

Le 14/10/2014 à 15h 07

HarmattanBlow a écrit :



  Je dirais plutôt que cette technique ne résout rien si tu dois mettre à jour des biblios utilisées par des composants qui ne se ferment jamais.  Mais en réalité ça résout quand même pas mal de choses, le disque est simplement un peu alourdi jusqu’au prochain reboot, le risque est surtout que ces applis ne soient pas rebootées avant longtemps et conservent leurs failles de sécurité. Mais là aussi on peut imaginer des palliatifs, comme un avertissement donné à l’utilisateur, une date limite avant reboot ou des MAJ marquées “critiques”.





C’est ce que j’expliquais si tu tentes de mettre à jour la libc par exemple. Elle ne sera jamais déchargé. On est obligé de redémarrer. Et en réalité ça ne résoud rien puisque les applications restent avec la mauvaise version en mémoire ,donc rien n’est mis à jour. Entre le reboot et ce cas c’est la même chose….

 

Ce qui serait une solution c’est un OS où tu bloques le chargement dynamique de code et tu  charges  les bibliothèques dans des SIP (software isolated process) séparées. Du coup tu es capable d’arrêter , mettre à jour et redémarrer une bibliothèque sans devoir fermer toutes les applications qui les utilisent.

Le 14/10/2014 à 14h 40

sepas a écrit :



 



L’élève ne dépassera jamais le maitre  " />





" />

Le 14/10/2014 à 14h 39

FRANCKYIV a écrit :



Evolution rapide sa serait sans moi vu les problèmes qu’il peut y avoir à la sortie d’une mise à jour.





Je continue de penser que ca posera des problèmes de compatibilité et d’updates foireux si la base reste la même. Ca tiendra peut être deux trois ans comme ça…

En attendant il existe des références à un “Modern Core” dans le sous système Win32. Mais il ne serait apparemment pas encore présent…

Le 14/10/2014 à 14h 34

levhieu a écrit :



Mise à jour d’un logiciel en cours d’utilisation: Un système de fichiers utilisant des liens plutôt qu’une table d’allocation permet sans encombre d’effacer un exécutable alors que des processus l’utilisent; le fichier ne peut plus être ouvert, mais sa disparition du disque est différée jusqu’à ce que le dernier processus qui l’utilise disparaisse.

Évidemment, si le logiciel a subi de gros changement dans son comportement et ses interfaces, on n’est pas à l’abri des (mauvaises) surprises.



Mise à jour d’un noyau sans reboot: Je me souviens d’avoir rencontré des RTOS affirmant en être capable, je n’ai plus de nom à proposer. Mais la complexité d’un tel OS porté spécifiquement sur une carte n’a rien à voir avec celle d’un OS généraliste qui se débrouille à la volée avec le matériel disponible.





Cette technique ne résoud rien si on doit mettre à jour des bibliothèques systèmes utilisées par la quasi totalité des applications. Dans ce cas sous Linux aucun processus n’est en réalité mis à jour avant de rebooter.



Edit:grilled par sepas

Le 13/10/2014 à 08h 06

Oui je vais voir avec franck ;) pour déployer aussi la mise à jour.

Le 11/10/2014 à 16h 01

JR_Ewing a écrit :



Je parlais de la version “de base”, j’ai pas d’abonnement à Office 365.





J’en avais parlé avec vincent il avait des publicités sur la version de base. Tu es peut être premium pour une autre raison. Tu peux le vérifier en te connectant sur ton compte sur le site de skype.

Le 10/10/2014 à 12h 19

JR_Ewing a écrit :



Y’en a plus de pubs sur la dernière version! " />





Il n’y a pas de publicité pour les abonnements skype premium. Tu es automatiquement premium si tu as un abonnement office 365.

Le 08/10/2014 à 12h 59

Sinon il y a ma-config.com pour les pilotes  " />

Le 04/10/2014 à 15h 02

Ravaged a écrit :



Key logger dans Windows 10



http://www.fredzone.org/windows-10-peut-enregistrer-tout-ce-que-vous-tapez-998





C’est pareil avec toutes les bétas de windows. Ce sont des données télémétriques qui sont envoyées à Microsoft sur l’usage de Windows par les utilisateurs. Ca permet de corriger des bugs et surtout d’améliorer l’ergonomie du système. C’est juste que sous Windows 10 la techno qui fait ça est beaucoup plus puissante qu’avant pour faire face aux feedback des utilisateurs. Mary jo foley a écrit une news sur azimov le nom de code de cette technologie

Le 02/10/2014 à 20h 15

moxepius a écrit :



Comme quoi…





Le problème de la base de registre est d’ordre conceptuel. Sur channel 9 à l’époque de Windows 7 ils ont interviewé les développeurs du noyau NT sur le sujet. Ils ont répondu que l’idée de base était bonne mais qu’ils regrettaient d’avoir donner l’accès à n’importe quelle application. Du coup ça devenait rapidement un beau bordel.

Dans l’environnement WinRT sur Windows ⁸⁄₁₀ tu n’as pas plus accès à tout le contenu de la base de registre. Mais chaque application a sa propre ruche sandboxée. L’application a uniquement accès à ses paramètres et ne peut pas modifier ou lire les paramètres d’une autre application.

Quand tu désinstalles l’application la ruche est supprimée, il ne reste aucune trace.



Au final on conserve les performances de la base de registre et le problème de “gros foutoir” et sécurité est réglé avec WinRT.

Le 02/10/2014 à 19h 24

arno53 a écrit :



Pour revenir sur la base de registre et les apps WinRT :

Dans le dossier sur Win8 on peut lire



J’ai du mal à comprendre si on reste sur une base de donnée unique, éparpillé en plusieurs fichiers mais ouverte en continu et où l’app ne peut modifier que ses propres clés ou si on passe sur plusieurs fichiers qui sont ouvert/fermé à chaque utilisation de l’app .. ?



Edit : JManici repond globalement à la question … Donc première supposition ^^





Il n y a pas de raison de charger en mémoire toutes les ruches de toutes les applications winrt si on les utilise pas.

La ruche doit être chargée par l’application quand tu appelles les api winrt pour les paramètres.

Le 02/10/2014 à 18h 37

Jiyuu_Hashi a écrit :



Il doit avoir la poisse ^^;

Depuis que la base de registre existe, des manips à la klon, j’en ai fait. Des suppressions arbitraires aussi, sans me soucier de quoi que ce soit, à l’époque où j’étais admin au boulot.

Je n’ai jamais réussi à planter un PC ou un serveur (et c’est pas faute d’avoir essayer… pour l’un de nos serveurs ^^;)









Jiyuu_Hashi a écrit :



Il doit avoir la poisse ^^;

Depuis que la base de registre existe, des manips à la klon, j’en ai fait. Des suppressions arbitraires aussi, sans me soucier de quoi que ce soit, à l’époque où j’étais admin au boulot.

Je n’ai jamais réussi à planter un PC ou un serveur (et c’est pas faute d’avoir essayer… pour l’un de nos serveurs ^^;)





Les rares fois oú ma bdr s’est envoyé en l’air. Sous xp,en fait c’était mon disque dur qui était en train de crever. Et une autre fois j avais de la ram defectueuse. Ca a corrompu le cache mémoire de la ruche.

Le 02/10/2014 à 18h 02

sepas a écrit :



Faudra m’expliquer comment tu as fait.

Il y a un backup que tu peux rappeler grâce au “last known configuration”

Dans ton cas, ça veut dire que tu as perdu la BDR et son backup…

Soit tu as eu plusieurs problème de corruption disques, soit tu es le mec le plus poisseux que je connaisse.

Si c’est la première solution, aucun système ne peut résister à un disque mort, si c’est la deuxième, n’importe quel autre système aurait planté aussi





+1 il y a un backup auto minimum depuis Windows 7 (C:\Windows\System32\config\RegBack)