Le 27/11/2013 à 07h 51

ff9098 a écrit :



T’as bien eu le temps de poster 15x sur cette news





Toi t’as le temps de troller. " />

Je ne vais pas écrire sur un sujet ou les sources ne sont pas totalement officielles. t’inquiète le jour ou ça sortira il y aura surement un dossier complet sur PCI que tu ne liras pas " />

Le 26/11/2013 à 12h 17

Maxouille-la-fripouille a écrit :



C’est bien ce dont j’ai peur… " />







Tu est bien naïf! Je suis prêt à parier que lors de la sortie de WP8.1 MS va nous dire subitement “ah ben non WP8.1 n’est pas compatible avec les WP8 actuels, faut racheter un tél”. " />





8.1 est une version mineure il n’y a aucune raison de casser la compatibilité. Il n’y a pas eu compatibilité de wp7 à wp8 car le système est passé de CE à NT et que la plateforme de développement était nouvelle.

En admettant que la prochaine version majeure tourne sous Midori. La plateforme applicative est la même. Win32 a duré plus de 20 ans. Ils ne vont pas changer WinRT deux ans après. Pour les drivers Midori est compatible avec les drivers Windows(source sdtimes)



Microsoft a étendu le support à trois ans donc normalement ton Windows phone devrait connaitre plusieurs mises à jours.



Enfin lors du passage de WP7 à WP8, il y avait très peu d’utilisateurs Windows phone, Microsoft n’avait rien à perdre. Mais là il y en a vraiment trop pour que microsoft n’en tienne pas compte.

Le 26/11/2013 à 11h 26

brazomyna a écrit :



Je comprends ce que tu veux dire, mais du “code managé compilé en code natif” n’est pas vraiment du code managé, puisque la définition même de la notion de code managé implique une exécution dans une machine virtuelle.



Mais je reste d’accord sur le fond: en gros, c’est une forme d’équivalent à .Net ce qu’un GCJ amélioré serait à java (*)



(*) tiens d’ailleurs, c’est pas ce que fait Google en ce moment avec ART, son remplaçant de Dalvik introduit en beta dans KitKat ?





En fait le code natif généré est type safe et memory safe . tu ne peux pas manipuler les pointeurs et donc pas de buffer overflow possible. C’est du code safe natif.

Le 26/11/2013 à 11h 21

Ne venez pas me dire que la puissance des pécé augmente, et si on peut encore gagner en performances sur les téléphones et tablettes, en ce qui concerne le pécé, la loi de Moore commence à plafonner avec la limite physique du nombre minimal d’atomes dans les jonctions de transistors.



Si on peut gagner sur le parallelisme du code. En effet on plafonne sur les frequences CPU mais le nombre de coeurs va augmenter. Midori est censé géré le many core.

Le 26/11/2013 à 11h 12

CaptainDangeax a écrit :



En tout cas, j’attends de voir ce que singularity / midori va apporter à l’écriture du noyau (ce qui communique avec le matériel physique), parce que pour écrire dans un registre, le plus proche du matériel reste l’assembleur, suivi par le C de suffisamment bas niveau. Utiliser un code managé, c’est peut-être plus facile pour développer, mais je doute des performances… Ne venez pas me dire que la puissance des pécé augmente, et si on peut encore gagner en performances sur les téléphones et tablettes, en ce qui concerne le pécé, la loi de Moore commence à plafonner avec la limite physique du nombre minimal d’atomes dans les jonctions de transistors.

C’est marrant quand j’entends parler de midori avec des applis en code managé, je pense à l’AS400, lancé en 1988…





Ce n’est pas du code managé mais du code managé compilé en code natif. Il n’y a pas de runtime. De plus l’isolation des Sip permet de faire des optimisations sur l’ensemble de l’application avec ses différentes dll. Au niveau du système il n’y a pas de context switch. les appels systèmes sont de simples routines.

De plus par mes sources j’ai appris que Midori est beaucoup plus rapide que Windows. Je vois à chaque fois cet argument comme quoi midori serait lent car il est en code safe mais c’est faux. Après libre de me croire.





1, optimiziations: single binary enables more compiler optimizing oppourtunities since the compiler/linker has the full view of whole program, can do thorough and complete static analysis, cross assemblies inlining, virtual call elimination, dead code elimination, etc.

Le 26/11/2013 à 10h 50

CaptainDangeax a écrit :



Je te propose de le mettre à jour. Wikipedia c’est collaboratif. Dire que “ceci ou cela” est faux ne fait pas avancer le schmilblick. Par contre, mettre à jour un article FAIT avancer le schmilblick.





Je n’ai pas le temps. Sinon en fait ce n’est pas faux je viens de me souvenir que M(pas M#) est aussi un langage de modelisation avec oslo. Mais ce n’est pas le même langage. Il porte le même nom.



Sinon les sources j’ai quoté une offre d’emploi plus haut qui parle de M#. et il y a cette offre sur la technical strategy incubation team(équipe de midori)





You will write code in a language like C# that has the performance characteristics of C++.

Le 26/11/2013 à 09h 17

CaptainDangeax a écrit :



M#Ce n’est apparemment pas pour tout de suite… Il est vrai également que MS a un lourd passé (passif ?) à gérer et une compatibilité à maintenir.





ton lien wikipedia est faux au niveau des informations. Il y eu des fuites sur ce langage. Ce serait un langage managé avec les performances du C++. Il n’y a pas de compilation JIT un peu comme le project N.

D’après mes sources c’est le langage principal de Midori. (Le M veut dire Midori). Ca sortira quand midori sortira.

Le langage M# est aussi conçu pour exploiter les pc many core.

Le 26/11/2013 à 09h 02

CaptainDangeax a écrit :



Ça va dans le sens de l’histoire, Linux a démontré qu’un seul noyau bien conçu peut tout faire, du smartphone au centre de calcul, du cloud au serveur web, du temps réel embarqué au routeur.

Ce qui m’inquiète plutôt, c’est que pour un paradigme “devellop once run everywhere” il faut un langage universel. Et je pense qu’un langage qui fait tout n’est bon nulle part : il n’aura pas la vitesse d’exécution d’un C compilé ou d’un assembleur, il n’aura pas la facilité d’un Python ou d’un perl, etc, etc. Et puis “un anneau langage unique pour les gouverner tous”, j’aime pas trop beaucoup ça…





A mon avis le langage M# sera obligatoire uniquement pour la programmation système. Mais Le principe de WinRT c’est d’avoir une plateforme de développement utilisable dans tous les langages. Avant WinRT il fallait écrire dans des langages .NET pour avoir un bon framework. les développeurs C++ devaient se limiter au Win32.

Avec WinRT c’est accessible dans n’importe quel langage même le c++.

Ils ont séparé la plateforme de développement du système lui même.

Je pense qu’on pourra toujours créer des applications en C++. microsoft a réinvesti pas mal dedans récemment.

Le 26/11/2013 à 06h 45

k43l a écrit :



C’est déjà le cas avec 8,1

Par exemple 8,0 prenait genre 13 - 14 go. Sur ma surface sur 64 go (sans compter qu’on a pas vraiment ça) j’ai 54 go à ma disposition.

C’est toujours pas iOS mais y’a du mieux





Oui RT 8.1 prend moins de place sur le dur. Mais Windows phone est beaucoup plus petit (dans les 2go), si Microsoft unifie même si il ajoutait certaines fonctionnalités ce serait surement meilleur que le windows RT actuel.

Le 26/11/2013 à 06h 21

Ideal a écrit :



Pour les malwares aussi y aura plus qu’un seul écosystème ?





Non quand on parle d’un seul ecosystème on parle de l’environnement WinRT. Win32 ne marchera jamais sur les smartphones par exemple. Donc non les virus windows actuels ne seront pas compatibles. Et même pour les applications Win32, elles devraient être aussi sandboxés à terme.

Le 25/11/2013 à 18h 51

arno53 a écrit :



Tu disais récemment que Midori était compatible avec les drivers Windows. Peut être que Microsoft a préféré limiter le nombre de matos supporter par WP pour justement s’assurer une transition WP8 -> Midori sans aucun problème. Du coup on peut imaginer qu’une fois midori sortie, les restrictions envers le matos mobile sauteront …





Si midori devait sortir ça changerait surement beaucoup de choses….

Le 25/11/2013 à 18h 45

yeagermach1 a écrit :



Tu peux faire des interfaces très évolué sous Metro. Ce qui ne changera pas c’est l’interface tuile du nouveau menu démarrer.



Maintenant le probleme que tu abordes, c’est l’ergonomie en fonction du support. Pour l’instant, il me semble que cela n’est pas géré mais cela le sera sans doute tres prochainement (charon ?).





Perso je penche sur ça. On aurait deux interfaces avec pas mal de point commun mais une ergonomie différente selon le support.

Le 25/11/2013 à 18h 13

The Technical Strategy incubation team is seeking an exceptional developer to build the user interface platform for next generation UI applications. Your responsibilities will include the design and implementation of core UI services such as composition, input, window management, and a controls framework for both native and HTML5 applications. All development is in M#, a C#-like language for writing asynchronous and parallel operating system components with strong guarantees of correctness.



Microsoft bosse sur une toute nouvelle interface écrite en m# sur Midori. L’interface desktop actuelle est écrite en win32. Si microsoft décidait de passer sur Midori cette interface devrait être réécrite.

Le 25/11/2013 à 18h 04

Aloyse57 a écrit :



Est-ce que RemoteFX pourrait le faire ?





le protocole RDP est la base de pas mal de technos MS. la virtualisation VDI, Menlo, Drawbridge. Ils vont surement bosser autour de cette techno.

Après j’ai entendu dire que pour midori cela va beaucoup plus loin.

Le 25/11/2013 à 17h 54

XMalek a écrit :



Vivement la fusion windows store / xbox one store avec jeu disponible sur les deux plateformes dès que tu l’achètes sur une mais malheureusement je sais je rève…





c’est pas impossible sur les premiers leaks de la xbox one en 2010 ils prévoyaient en 2015 de pouvoir jouer à terme sur n’importe quel écran en utilisant le cloud.

Le 25/11/2013 à 17h 46

Tolor a écrit :



Parce qu’il y avait une guerre entre les différents services





ou plutôt qu’ils n’étaient pas près techniquement pour unifier.

Le 25/11/2013 à 17h 45

Cet offre d’emploi sur la prochaine version majeure de Windows phone laisse entendre qu’il y aurait une toute nouvelle fondation

source





Do 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 the Operating System that serves all other feature teams?





Ce ne serait pas étonnant que Midori sorte en 2015 et serve de ciment pour unifier les Windows.

Le 20/11/2013 à 11h 42

Sagarine a écrit :



POurquoi se priver ? T’as des packs de plusieurs milliers de roms et émulateurs, en torrent " />





Perso j’achète tous mes jeux sur PC. Après j’aime bien rejouer à de vieux titres.

Pas très pratique de ressortir les vieilles consoles.

Le 20/11/2013 à 11h 37

Pc Fixe puis émulateur pour les vieux jeux. " />" />

Apparemment suis pas le seul " />

Le 19/11/2013 à 19h 36

arno53 a écrit :



Tiens j’en profite pendant que tu es là et que l’actu est assez calme ces derniers temps et si t’es pas trop occupé bien évidemment " /> :



On parle beaucoup du C# mais ces contraintes qui sont aussi imposé pour le C++ permettront elles aussi d’optimiser les programmes C++ ?





Il y a eu plusieurs offres d’emploi dont une citée dans la news de foley sur project N qui parlait d’un compilateur unifié pour le C++ et le C#. J’imagine que project N marche aussi pour le c++.







arno53 a écrit :



Y’a une différence entre le compilateur Bartok et Phoenix ? et Roselyn ?





Bartok c’est le compilateur ahead of time de recherche utilisé par singularity.

Phoenix c’est une architecture de compilateur modulaire. Bartok utilise phoenix

Et roselyn est un compilateur écrit en .net disponible sous forme de service.



News Redhawk a dit :







arno53 a écrit :



Donc la transition MSIL -> MDIL se fait dans le cloud pour WP8 (quid de Windows 8.x et RT ?)

Et Redhawk (SLR) était sensé compiler et optimiser ce MDIL pour faire du natif … Maintenant on nous parle du projet N (MRT) " /> D’apres ce que je comprends du post de h0x0d et surtout de ses différents billets Redhawk (slr) devait être utilisé par les équipes de Microsoft pour le code de l’OS (et les pilotes ?) (cf sa présence dans un dossier minwin) et les équipes orientées outils de développement l’ont fait muter (en mrt) pour être utilisable par tout le monde (cf le projet est dans un dossier win32). C’est bien ca ?







D’après ce que j’avais pu trouver le compilateur unifié était capable de fournir du code natif ou du mdil. Pour redhawk personnellement je n’ai pas beaucoup d’informations dessus. mais en effet ça a l’air de ressembler à mrt.

Par contre j’ai entendu dire que RedHawk avait été mis en test expérimental dans Windows 8(c’est en effet le cas:slr100.dll dans system32) mais qu’il serait utilisé massivement sur Windows 9

Le 19/11/2013 à 18h 04

arno53 a écrit :



Le quote c’est ce que MS appelle le ‘tree shaking’ (page 3 du thread sur channel9) ?





Oui c’est ça. C’est à mon avis une des raisons principales des bonnes performances de Midori.

Le fait qu’on ne puisse pas charger dynamiquement de code dans singularity n’aide pas seulement pour les performances avec le tree shaking. J’avais lu dans une vieille spécification que ça permettait aussi d’améliorer l’efficacité des outils d’analyse de code.

Le 19/11/2013 à 17h 38

arno53 a écrit :



Me too " />



J’étais déçu de ne pas voir la moindre info/brèves sur PCI et je mettais ca sur le dos de la nouvelle ligne éditorial … Je retire toutes mes pensées " />



Sinon le projet N a l’air fort intéressant et je trouve ca amusant de voir que Google et Microsoft proposent la même solution face au même problème " /> En effet depuis Android 4.2 on peut compiler l’application à l’installation plutôt que faire du JIT dans la machine Dalvik … Bon c’est en beta mais ca sera surement dans la version 5





Arno53 Project N n’est pas limitée à une simple compilation native. Regarde le lien que je t’ai donné plus haut.





1, optimiziations: single binary enables more compiler optimizing oppourtunities since the compiler/linker has the full view of whole program, can do thorough and complete static analysis, cross assemblies inlining, virtual call elimination, dead code elimination, etc.





De plus ça semble être une mise en production du compilateur bartok qui faisait déjà tout ça depuis des années.

Le 19/11/2013 à 16h 47

Je complète cette news sur project N Felix de channel9 a posté plusieurs informations récemment sur ce lien :

https://channel9.msdn.com/Forums/Coffeehouse/MS-working-on-a-same-compiler-for-C…

et sur son twitter:

TwitterIl a trouvé des références à project N dans la version arm de fresh paint sur RT 8.1.

Cette même version intègre le dll mrt100_app.dll. RT 8.1 intègre aussi la version pour bureau mrt100.dll. Il avait déjà trouvé par le passé des références sur ce dll. Ca semble être le minimal runtime il serait lié à redhawk.



Apparemment freshpaint sur arm aurait été compilé avec Project N. Project N ressemble sur plusieurs points au compilateur bartok. Je dirai que c’est une mise en production de ce projet. Comme bartok c’est un compilateur ahead of time qui compile le code .net directement en natif. Mais ce n’est pas tout freshpaint arm contient un seul binaire au lieu de plusieurs dll comme la précédente version. avec Bartok et singularity le chargement de code dynamique est interdit. Ca permet à bartok d’avoir une vue sur l’ensemble du code et d’effectuer toutes sortes d’optimisations poussées.



Midori et windows devraient dans le futur partager plusieurs composants communs afin de faciliter la compatibilité entre les deux os. J’imagine que les applications compilées avec Project N devraient pouvoir tourner aussi sur midori.

Le 17/11/2013 à 10h 52

jrbleboss a écrit :



" />

.





Je t’ai envoyé un MP ;)

Le 16/11/2013 à 13h 45

arno53 a écrit :



C’est techniquement possible (page 9 du pdf) mais je ne pense pas qu’il offriront cette possibilité sur arm ou alors ca serait sur une version arm PRO (sur un laptop arm par exemple) mais je vois pas trop l’Intérêt sur une tablette grand public…



Je pense qu’a termes on aura juste des version home pour arm et x86 qui ne se contenteront que des applis WinRT et une version pro avec la compatibilité Win32 x86.





C’est possible aussi que Win32 soit détourné vers des serveurs azure. Ca réglerait les problèmes de performances avec le matériel arm peu puissant et ça allégerait fortement le système en externalisant la compatibilité win32.

Perso je pense que dans un proche futur on se dirigera vers des appareils extrêmement légers et connectés qui déporteraient la puissance sur le cloud ou de gros PC familliaux.

Le 16/11/2013 à 07h 49

jrbleboss a écrit :



Je ne peux pas dire grand chose, mais ce n’est pas une chimere et les demos que j’ai vu sont impressionantes.





Tu bosses chez Microsoft?

Le 15/11/2013 à 09h 01

Lafisk a écrit :



Ok, c’est déjà donc plus rassurant alors.



Des estimations quand même sur l’arrivé de midori et autre ? je suppose que ce sera bel et bien avec Windows 9 du coup





Aux dernières nouvelles d’après foley la prochaine version majeure sortirait qu’en 2015

Le 15/11/2013 à 08h 53

Lafisk a écrit :



Espérons qu’ils nous refassent pas le coup du passage WP7 -> WP8 avec ça car la franchement, ça le ferait pas car autant commercialement parlant c’était acceptable avec WP7 vu qu’il y avait peu de client (encore que ce foutre à dos les early adopters c’est moyen) mais la avec WP8, ils en ont déjà plus …





En effet Il y a trop d’utilisateurs WP8 pour refaire la même chose. Midori est compatible avec les drivers Windows et les applications WinRT.

Le 15/11/2013 à 08h 43

metaphore54 a écrit :



Android trust le marché, reste à savoir pour combien de temps, mais à priori c’est parti pour durer des années.



Windows phone augmente peu c’est un peu dommage.



Par contre midori et tout ça sortira quand ? car pour l’instant c’est une chimère.





Vu cette offre d’emploi sur la prochaine version majeure de Windows phone je dirai bientôt

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?….



Il semble que wp9 tournera avec une nouvelle base qui sera aussi utilisé dans d’autres produits.

Le 14/11/2013 à 04h 34

arno53 a écrit :



Ouais enfin y’a pas vraiment de différence entre un bas de gamme WP d’un haut de gamme WP … La fluidité est globalement toujours là … Fluidité qui avec Android pré-4.1 n’était clairement pas au rendez vous sur le bas de gamme … On verra bien Kitkat qui est sensé amélioré les choses pour les smartphones à 512 mo de ram ..



HS

Sinon on est en train de voir que Google et Microsoft ont la même approche pour améliorer la réactivité de leur application avec Android RunTime (ART) et le projet N chez Microsoft : compilé les applications à l’installation plutot que faire du JIT … (Ca m’a fait pensé a d’autre projet de MS type Redhawk et la transition MSIL/MDIL dans le cloud pour WP par exemple " /> Charon si tu passes par là)





Ce genre de choses j’en parle depuis longtemps sur pci. Singularity et midori n’utilisent pas de runtime.La compilation JIT est interdite. Le code est compilé directement en natif. project N est surement hérité de bartok. A savoir un compilateur ahead of time .net=>code natif capable d’effectuer énormément d’optimisations dans le code dont des optimisations de code parallèle.

Project N est un des maillons de Midori

Le 10/11/2013 à 09h 03

ASSKICK a écrit :



De toutes façons si tu passes à 8.1 tu as meilleur temps de tout réinstaller clean, ne jamais faire confiance à un upgrade MS " />





Mouais il ne faut pas resté bloqué à l’époque de Windows XP. L upgrade a bien évolué depuis.

depuis vista/7 il fait une copie du dossiers programmes et utilisateurs. Il installe l’os comme une nouvelle installation puis il réinjecte les dossiers précédemment sauvegardés.

J ai upgradé 3 pc de 8 á 8.1 sans aucun souci. Un des pc était bourré de toutes sortes d’applications et tout marche niquel.

Les upgrades foireux c ‘est soit des pc déjà verrollés ou en mauvais ètat, ou un driver qui ne marcherait pas ( normalement pas le cas de 8 à 8.1). ou le disque dur qui se met à plus marcher lors de l upgrade(courant que les durs se mettent à crever lors d’une Install os et révèlent une panne à cause des quantités de données).

Le 09/11/2013 à 10h 40

J’ espère qu’elop n’obtiendra pas le poste de CEO chez Microsoft. Déjà qu’il a organisé le rachat de Nokia pour le compte de Microsoft. Super riche pour l’image de la boite…

En plus il veut revendre bing et Xbox qui ont un intérêt sur le long terme. Superbe politique court terme. J’avais averti que le remplaçant de ballmer pourrait être pire :(

Le 06/11/2013 à 12h 09

coket a écrit :



La sandbox d’un AV aussi?





Par exemple si tu lances une application dans la sandbox d’avast . Normalement il bloque l’accès au système et certaines ressources systèmes. Après je ne connais pas l’implémentation de cette fonctionnalité en détail. A moins d’exploiter une faille d’escalade de privilège dans l’antivirus ,je ne pense pas que tu puisses infecter ton pc si tu l’utilises.



Pour la sandbox de Windows 8,actuellement elle peut être contournée car on peut toujours lancer des applications Win32 qui ont tous les droits. Par contre ce n’est pas le cas de Windows RT. Julien Manici en parlait dans un précédent commentaire c’est la version de Windows la plus sécurisée du marché. Pareil pour Windows phone 8 qui est le seul os mobile à ne peut avoir été rooté. Pour faire casser la sandbox de Windows RT et WP8 (qui bloque en lecture et écriture) il faudrait exploiter une faille d’escalade de privilège dans le système et aussi casser la protection de secure boot qui protège le boot des fichiers systèmes en chaîne jusqu’aux applications WinRT.

Le 06/11/2013 à 10h 37

Spidard a écrit :



Donc si l’uac est activée, peu de risques ?





Le système de compte ne protège pas contre les virus. Microsoft a toujours dis que n’était pas une barrière de sécurité. Ca fait un moment que les virus ont évolué pour utiliser uniquement les droits utilisateurs.

La seule technologie récente qui protège réellement comme barrière c’est la sandbox dans Windows 8.

Le 06/11/2013 à 09h 45

Je changerai seulement quand je passerai en 4k donc pas avant un , deux ans. J’ai pas l’intérêt de changer pour le moment.

Le 05/11/2013 à 14h 19

fraoch a écrit :



ouais, on peut meme installer des virus " />



d’ailleurs , la xbox one qui accepte les DD externes (pre requis pour prendre ma question en consideration)

elle marche sous X86

elle marche avec windows 8 (ou assimilé)



un virus ecrit pour windows sur cette machine, il fonctionne ? ? on peut mettre avast dessus ?

va t on voir les antivirus pour consoles apparaître ?





Les applications Win32 ne sont pas compatibles sur la Xbox One. Les applications Win8 pour la Xbox One sont en WinRT. On ne sait pas encore si le store sera le même que Windows 8 ou si ce sera une variante comme avec WP8.

Par contre tous les virus windows sont écrits pour Win32 et les applications WinRT sont sandboxées. Il ne devrait donc pas y avoir de virus sur la xbox One.

Le 04/11/2013 à 11h 42

jinge a écrit :



Un nouveau sondage pour savoir qui prend quelle console? " />





Aucun intérêt il faut attendre deux ans pour avoir une idée réelle.

Sinon il y avait eu un sondage sur PCI avec Windows 7 à la sortie et personne devait y passer " />

Le 02/11/2013 à 10h 26

sepas a écrit :



Pour ceux qui disent que les consoles manquent de puissance par rapport aux PC ou que l’une est plus puissante par rapport à l’autre, je voudrais éclaircir certaines points :

• Le principe d’une console est que ses composants sont uniforme. Contrairement à un PC, le code pourra être optimisé au matériel d’une façon beaucoup plus efficace que sur un PC. Il faut donc moins de puissance à une console qu’à un PC
  
  
  


• L’OS de la console est un OS léger qui consomme bien moins, et sur lequel très peu d’applis sont installées par rapport à un PC
  
  
  


• Pour la comparaison de puissance entre les 2 consoles. Sauf à vouloir jouer à “qui à la plus grosse”, encore une fois, l’OS et les compilos vont être bien plus important que la différence minimes de matériel entre les 2 consoles
  
  
  
  Donc, se battre pour savoir qui sera la plus performante sans avoir testé en vrai, ça n’a aucun sens.
  
  
  
  
  
  +1000 la différence de performances matérielles entre la PS4 et la XBox one est minime. Tout se jouera sur les optimisations logicielles.

Le 05/11/2013 à 12h 32

Zorglob a écrit :



Il n’y a pas de raison de quoi ? Que mozilla fasse pareil avec les extensions ou que le faire avec les extensions soit assimilable à un suicide ? " />



Sinon effectivement, l’enjeu sécuritaire n’est absolument pas le même (bien que la mesure de cette news laisse de coté les LSO finalement, qui ne sont pas les moindres des problèmes)…





Les deux. Mais bon les extensions ne posent pas de problèmes particuliers ou du moins sans aucune mesure avec le fait de pouvoir exécuter du code natif dans un navigateur web.







Zorglob a écrit :



Mais je voulais simplement rappeler que les extensions sont un des fers de lance de FX - même si ça existe ailleurs - et que j’ai vu des gens (pas mal même) switcher rien que les rares extensions désactivées ou au pref mises à 0 par quelques mise à jour du navigateur.

Donc la sécurité c’est très bien et incomparable, mais l’époque est concurrentielle et Mozilla devrait toujours faire attention à ce qui garde un large panel d’utilisateurs chez eux.





C’était mon cas par exemple. Bien que je sois passé depuis sur google chrome pour les performances.Et le système d’extension de google chrome est plus souple

Le 05/11/2013 à 09h 28

Zorglob a écrit :



Par contre, si Mozilla veut se suicider et mourrir rapidement, il leur suffit de faire pareil avec les extensions.





Il n’y a pas de raison les extensions ne posent pas les mêmes problèmes de sécurité que du code natif avec les plugins. Les plugins NPAPI beaucoup l’ignorent mais c’est l’équivalent des ActiveX sur les navigateurs concurrents à IE.

Le 04/11/2013 à 14h 40

J’ai bien fait de passer sur un serveur websocket sur la version 7 de ma-config.com " />

Le 25/10/2013 à 15h 16

succubbae a écrit :



Yep, microsoft est effectivement en train de mourir !





On m’aurait menti " />

Le 18/10/2013 à 10h 39

_Nada a écrit :



Oui.



C’est aussi pour cela que je ne suis pas trop content dans mon message sur leur forum.



Depuis le temps que 8.1 est annoncé (et dispo en préversion), ils auraient quand même pu se sortir les doigts du luc afin de proposer un installeur à jour.



Bravo à eux en tous cas : se trimballer sans AV juste parce que l’éditeur, que dis-je, l’un des plus gros éditeur d’AV, n’est pas foutu de rendre compatible son programme.



Chapeau bas !





J’ai longtemps utilisé kaspersky jusqu’à je me tape des bsod qui après analyse accusait le driver filtre de kaspersky. Plus globalement je vois bien que sur mon site il y a pas mal de problèmes liés aux antivirus eux même.(kaspersky n’est pas le seul)

Du coup je me contente de security essentials,c’est sur qu’il est beaucoup moins bon mais il est plus fiable. De toute façon sur ma machine j’installe pas n’importe quoi je fais assez gaffe. Le seul virus que j’ai eu dans ma vie c’était à cause de l’ex de mon frère qui a squatté mon pc " />

Le 17/10/2013 à 11h 57

David_L a écrit :



La FAQ :





C’est disponible mais ça revient à tout réinstaller. C’est ce qui avait été dit par le passé.

Le 17/10/2013 à 11h 24

Ca a corrigé le bug avec le démarrage rapide qui marchait pas avec la RTM sur mon raid intel. " />

Le 10/10/2013 à 17h 05

arno53 a écrit :



Par contre j’imagine qu’il restera toujours la brique win32 minimal servant pour IE11 non ?





Il existe dans Windows Core(anciennement MinWin,25mo sur le dur) une serie d’api win32 basique.

WinRT a été écrit au dessus de cette base. Il n’est pas censé utiliser beaucoup de dll Win32.

il y a eu aussi normalement le même travail avec IE.

Le 10/10/2013 à 16h 43

Pom Pom Idou a écrit :



Avec Microsoft faudra s’attendre à tout, hein. " />



Tu sais combien prend une ROM Android pur jus ???



Et même avec les surcouches constructeurs en comparaison ???





D’aprèsce lien 3Go

On reste dans le même ordre de grandeur que Windows phone.

Le 10/10/2013 à 16h 31

Pom Pom Idou a écrit :



Bref, et concrètement ça donnera quoi sur le résultat final, qu’il y ai du win32 ou pas ???



Même à la grosse louche…





tu dis qu’avec l’unification Windows phone prendra du poids. J’ai pas les chiffres exacts mais c’est connu que le poids de Windows provient des nombreux dll Win32 destinés à garantir la compatibilité. Il n’y a pas d’applis bureaux(win32) sur Windows phone donc il n’est pas nécessaire de porter ces dll.

L’unification a toujours porté sur l’environnement WinRT

Le 10/10/2013 à 16h 24

Pom Pom Idou a écrit :



Ouais mais bon, on ne va pas jouer sur les mots : tu m’as parfaitement compris donc pas la peine de faire un un roman non plus hein…



Si WP fait déjà ²⁄₃ Go comme tu l’indiques, et si MS rajoute les fonctionnalités de Windows RT (boudiou), cela augmenter la taille à combien, à comparer avec ses concurrents directes, et combien il restera de place pour les utilisateurs ???





ce qui fais grossir Windows c’est Win32 et pas WinRT, Le windows phone unifié ne devrait pas trop grossir. Il ne gérera pas le passif de compatibilité Win32

Le 10/10/2013 à 15h 34

ethanfel a écrit :



Faudra aussi convaincre tout les devs PC de quitter le mode desktop. Vu les guidelines autoritaire de MS pour leur apps modernUi..



D’ailleur, le pc etant en declin, WRT etant un enorme echec, et W8 qui n’arrive pas a ce vendre, sans compter que les chiffres de WP ne sont pas très impressionnant.. tu pense vraiment que des devs AAA vont passer leur apps en modernUI pour etre compatible 3 platefomes (qui ne marchent pas) et ainsi offrir un pourcentage de leur revenu a MS ?



Y’a que MS pour croire a ça.





Je sais que Microsoft bosse sur de très gros projets. J’attends de voir ce qui va se passer.