pasBill pasGates a écrit 16169 commentaires

Voir un divorce en direct me fait toujours perdre une larme…

Que personne ne va utiliser ? Permets moi d'en douter…

Au hasard rien qu'a travers le fait que toutes les apps Metro utilisant le controle WebView vont utiliser le moteur d'IE Metro.

Pas besoin de ca, tu sais bien que tous les employes de MS sont des agents de la CIA et qu'on a des backdoors sur chaque ligne de code et meme dans les commentaires !

D'autre part j'ai peu que cela illustre une fois de plus la prise de pouvoir des vendeurs de systèmes d'exploitation : après les magasins d'applications (qui imposent déjà un système de liste blanche inadmissible pour les applications et contenus), voilà que Microsoft ose la liste blanche des sites Web. WTF !!!!

a) Flash est le seul plugin permis, aucun autre plugin ne peut tourner dans IE Metro, meme Silverlight ne peut pas tourner dans IE Metro, et cela pour des raisons de securite (plein de failles passent par ces plugins) tout simplement car c'est un plugin utilise par plein de sites importants
b) Seule une liste tres specifique est permise, pour raisons de securite, peu de chance que CNN.com pose un element flash dangereux, alors qu'un site aleatoire par contre…

Jamais je ne l'aurai cru possible…

+1

Itanium est mort comme explique plus haut, je pense que le magasin du coin vend plus de PCs en un mois que HP vend d'Itaniums en un an, donc on a decide de ne pas sortir Windows 8 / 2012 pour Itanium.

Je ne ferai tout simplement pas de commentaires sur PPC.

Ca existe, ca s'appelle UDF et c'est dans Windows depuis quelque annees deja…

Pour générer son sous-système SUA Posix, windows n'utilise pas l'API win32. Si je n'en dit pas une grosse ( c'est carrément possible), il utilise d'autres api notamment la Native Api. Le problème quand on commence à toucher à ce genre d'api, c'est le manque de documentation… à tort ou à raison, une partie de cette api n'est pas documentée. Je suppose que cette api n'est pas stable avec le changement de version, et c'est cette argument qui est utilisé pour ne pas la documenter entièrement?

Ce qu'il faut comprendre c'est que SUA ne peut pas utiliser Win32. Win32 est un sous-systeme au meme titre que SUA. Les 2 tournent en parrallele, pas l'un dans l'autre. Les APIs que les sous-systemes utilisent sont effectivement les APIs de NT (NTdll.dll) qui ne sont pas grand chose d'autre que des wrappers sur les systemcalls du noyau. Ces APIs ne sont senses etre utilises que par le systeme car ils sont effectivement sujets a changement (et cela arrive). SUA appelle Nt directement tout simplement parce que SUA faisait partie du systeme.

Des soucis de sécurités sont trouvés régulièrement dans windows, comme dans tous projets libres, et dans windows, comme dans certains projets libres, leur façon de les gérer est souvent merdique, lente. Ils sont publiés seulement par la pression des utilisateur qui comparent avec la transparence des façons de faire des autres, sinon tu pourrais toujours de toucher la nouille pour avoir des infos…

Ca serait bien que tu evites de raconter n'importe quoi quand meme… Tu n'as absolument RIEN pour baser cette affirmation.

Et je te suggeres de reflechir a 2 fois a ce que tu reponds, parce que l'equipe qui s'occupe des patchs de securite chez MS, c'est la mienne, tu auras du mal a passer la moindre anerie a travers mon filtre.

Je crois que la reponse est : J'en ai aucune idee :+)

J'ai rien remarque personellement, mais vu la sensibilite de ma vue ca ne veut pas dire grand chose.

À vous d'annoncer vos priorités, c'est vrai qu'écouter ses utilisateurs n'est pas non plus votre fort (alors que l'informatique devrait être au service de tous, ou du maximum possible, suffit d'avoir des gens motivés).

C'est justement tout le contraire, on ecoute nos utilisateurs. L'enorme majorite d'entre eux se fiche totalement du support ext4 / btrfs. Seul 1% de la planete utilise ext4/btrfs, et ces gens la ne sont en bonne partie pas des utilisateurs de Windows.

Moi j'attends que tu m'expliques en quoi le support de ces FS serait plus prioritaire qu'une meilleure duree sur batterie, une securite renforcee, une utilisation simplifiee du browser, etc… pour les utilisateurs Windows. Qu'est ce que ca amene ? Leur permettre de faire un double boot Linux / Windows facilement ? Ca aiderait combien de gens ? Quasiment personne, meme pas 1%.

Interoperabilite avec quoi ? Ce ne sont pas des standards, ce sont juste des formats comme d'autres. On la met ou la barre de ce qu'on supporte ? On devrait supporter les filesystemes Amiga et BSD aussi ? Les formats d'image XBM aussi ?

Faut etre realiste, tu demandes un truc qui ne servirait meme pas a 1% de la population, au niveau des priorites c'est vraiment en bas de l'echelle.

Ben les drivers Hyper-V pour Linux je connais pas trop donc ca me serait difficile d'ecrire un truc correct.
Pour ext4 et btrfs de base, le jour ou ce sera populaire ca se fera surement, mais aujourd'hui ca servirait a qui ? Quasiment personne. Personne ne met des serveurs en double boot, et les desktops avec ext4 / btrfs sont une infime minorite.

Oh je peux imaginer que ce ne soit pas parfait, si on faisait tout tout juste ca se saurait :+)

Euh si ca marche, je viens de le faire sur ma machine pour tester :
- Tu clique droit sur les entetes de colonne, choisis les colonnes supplementaires que tu veux
- Tu vas dans Tools -> Folder Options, tu choisis "apply view to all folders" et ca marche

Pour les "librairies" ca pourrait etre different par contre.

Euh là je ne pige pas bien, pour migrer à chaud entre 2 machines il faut bien que les données soient accessibles sur les 2 machines !

Tout a fait, le truc a comprendre est que les donnees sont migrees a chaud, pendant que la VM tourne et qu'au bout d'un moment la bascule s'opere.

Autre chose, savez vous si windows server intègre l'équivalent de tmem/frontswap/cleancache, car maintenant que c'est officiellement stabilisé dans le noyau 3.6, c'est à mon avis le truc magique : on peut dimensionner ses vm au plus juste en mémoire, et ainsi s'assurer qu'elles tiendront toutes sur un Dom0 en cas de failover, et en fonctionnement normal, elles utilisent toute la mémoire libre de l'hyperviseur, aussi bien pour le pseudo-swap(frontswap) que pour le cache disque(cleancache) !

Hyper-V a "dynamic memory" depuis Server 2008 R2 SP1 qui permet d'allouer plus de RAM que physiquement present, et le systeme s'occupe de bouger la RAM entre les VMs. selon les besoins, c'est de ca que tu parles ?

Au niveau fonctionnel peut-etre, mais au niveau securite on a elimine le probleme.

ReFS supporte la compression et le chiffrement, mais au niveau du volume entier seulement, plutot que fichier par fichier.

NTFS n'est pas pret de disparaitre lui, FAT32 j'en sais rien, pas de tout de suite en tout cas.

Euh si ca a toujours ete possible… juste pas de maniere 'visible' pour le pekin moyen.

Tu passes le nom / chemin du fichier en mode 'canonique' aux API (c'est a dire que tu passes directement a travers toute l'interpretation faite par Win32 en ajoutant \\?\ au debut ) et tu peux acceder a des chemins allant jusqu'a 32768 caracteres, soit le maximum supporte par NTFS.

J'ai l'impression, mais peut être que je me trompe, que le noyau Windows compile sur plusieurs architectures mais que toute la couche utilisateurs est différente alors que sous GNU/Linux, en gros l'idée est de recompiler l'ensemble des mêmes paquets sur les différentes architectures. Bref, de ne pas spécialiser la couche utilisateur à tel ou tel domaine.

Tu te trompes…

1) Je vois pas le probleme des extensions de fichier, c'est quoi ? kournikova.jpg.exe ? Ce probleme a ete elimine il y a deja un petit moment
2) Tu devrais t'assurer que ton Windows est a jour, ca fait un petit moment qu'on a change ce comportement.

Oui bon on se comprend :)

Je sais tres bien qu'approcher quoi que ce soit au sujet de MS au niveau 'politique' va finir en une depeche avec 500 commentaires, tous mes posts a -4, -5, Albert qui va faire une syncope et moi qui vais perdre mon temps, donc bon…

Je sais pertinemment qu'il y a les versions 32 et 64 bits de IE mais lorsque tu le lances, tu as par défaut la version 32bits et je suis persuadé que très peu d'utilisateurs savent qu'ils ont une version 64 bits sur leur PC.

Certainement, mais tu n'amenes pas une techno comme ca quand il y a tout un tas d'elements existants. Si le plugin faisant des bruits de pet a chaque click dans IE ne marche plus car 32bit uniquement, ton petit frere retournera a IE32bit de toute facon. On fait donc cela par etape, et la 1ere etape est de pousser les editeurs a passer leurs plugins en 64bit.

On s'est tous aussi que le développement s'appuie sur les architectures matérielles sous jacente. Cela a été dis dans un autre post ici il me semble. Voir le coup de gueule de Linus concernant le port ARM il y a quelques mois. Certaines fonctionnalité tirent partie des nouvelles instructions les CPU, il y eu il y a longtemps la MMU pour la mémoire (avec un port Linux sans MMU), il y a maintenant tout ce qui concerne la virtualisation qui n'est pas du tout au même niveau sur tous les CPU. N'étant pas spécialiste, je ne sais pas qu'elle est l'influence exacte de ce genre de contrainte dans le design d'un OS.

NT a depuis sa naissance le concept de HAL (Hardware Abstraction Layer) qui se situe comme couche entre le materiel et le noyau pour gerer les differences au niveau du materiel. C'est en tres grosse partie la dedans que le port ARM a eu lieu: ajouter le support pour les SoC differents, timers et controlleurs d'interruption specifiques a la plateforme, etc… et aussi un peu de boulot dans les pieces genre le memory manager.

Le reste du code au dessus c'est a 99% du C et C++ standard avec les APIs deja 'prepares' depuis longtemps pour supporter des tailles de pointeur differentes, etc… Il y a un peu de boulot supplementaire pour certaines parties pour optimiser le code en fonction de l'architecture (ecrire du code de maniere differentes sur des archis differentes peut ameliorer les perfs) et il faut evidemment avoir un compilateur ARM et ecrire les drivers pour le hardware specifique aux systemes ARM mais voila, c'est a peu pres tout.

Au niveau du developpement, vu la taille de la division on a une structure hierarchique :
- Un depot "Main" d'ou sortent les versions 'officielles' de la division Windows pour toutes les plateformes.
- Chaque sous-groupe (networking, shell, hyper-v, …) a sa branche, ou ils font leurs trucs, et quand ca atteint une qualite decente, ils integrent dans "Main"
- Chaque sous-groupe a aussi des sous branches pour leur differentes parties (TCP/IP, firewall, … pour networking par exemple)

Le code dans chacun de ces depots est evidemment le meme pour toutes les plateformes (ARM, x86, amd64) avec les #ifdef et autres trucs qu'il faut et chaque depot sort les 3 plateformes et les 3 OS (phone, server, client), sauf pour les couches tres hautes qui sont differentes entre le phone et le client(genre Explorer.exe, Media Player, …)

Il y a tous ceux qui utiliseront le "modern desktop" de Windows 8, vu que celui-ci interdit les plugins, on l'a mis en 64bit par defaut.

C'est toute la partie 'experience utilisateur' : si les plugins des gens ne marchent plus, ils pesteront et reviendront a la version 32bit de toute facon. Resultat on met la version 64bit, on pousse les editeurs de plugins importants a passer en 64bits, et une fois que la masse critique sera atteinte, on bascule a 64bit par defaut.

Oui mais bon, si moi je fais dans le subjectif, on sait tous comment ca va finir …