pasBill pasGates a écrit 16057 commentaires

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 …

Le port ARM etait la depuis Vista, époque ou Xbox etait deja la… : x86, Itanium, amd64, ARM, PPC

Il est tout aussi multi-architecture que Linux, faut juste voir la difference qui est que MS ne sort que ce qui est rentable, tout comme Redhat ne va pas faire une distrib Redhat pour des archis exotiques.

Pour IE, si tu regardes bien, tu as IE 32 ET 64bits, les 2 sont donnes pour la simple raison que plein de plugins sont 32bits uniquement, mais je te recommandes perso d'utiliser la version 64bit qui est plus sure.

Server 2012 abandonne Itanium tout simplement car on etait arrive a un moment ou il y avait quasiment plus de machines Itanium chez MS qu'ailleurs sur la planete, autant dire que le developpement n'en valait plus la peine, l'arret n'a rien de technique.

cmd.exe c'est 32bit et ca va le rester tout simplement car il ne pourrait pas tourner autrement.

Du tout, tu fais tourner dans les navigateurs le resultat d'une compilation par TypeScript.

Et vu que le compilateur est lui-meme ecrit en JavaScript,ben tu sais que tant que ton code final JavaScript a une chance d'etre execute, il peut etre compile, pas de probleme de disponibilite du compilateur.

Une depeche pour 4 produits majeurs du concurrent d'en face, qui ont a peu pres tous un effet sur le monde Linux/libre.

Si tu as du mal a voir le lien entre Windows 8/Server et un impact sur le monde du libre après toutes ces annees de presence sur ce site, tu as un probleme bcp plus serieux que cette depeche…

Technicien de Surface <-> balayer …

Le texte etait pourtant clair :

la longue liste de CPU qui sont, ou ont été, supportés au fil des années

Pour ce qui est du code commun, il y a encore plein de code qui est commun, mais evidemment plein de code qui a change et ete ajoute aussi. Par contre l'architecture a tres peu change elle (stacks de drivers, object/memory/… managers separes, HAL, etc… sont toujours la)

Quand tu regardes WP7, base sur WinCE et ses limitations, c'etait clairement une phase 'transitoire' pour des telephones ressemblant de plus en plus a des ordinateurs. Ca veut pas dire que le systeme marchait pas bien, il marche tres bien, mais pour le future il y avait un plafond.

Pas compris, c'est quoi le probleme ?

Je serai totalement pour faire une depeche plongeant plus profondemment dans le technique comme cela a ete demande plus bas, faut juste me creer une liste des sujets que vous voulez.

Faudra juste voir si j'arrive a la faire avant Jeudi, parce qu'apres je pars pour 3 semaines dans des trous perdus qui seront pour la plupart deconnectes du monde.

Je peux certainement aller bcp plus loin sur le technique, mais j'ai fini d'ecrire la depeche a 3h du matin et c'etait deja pas mal long, je peux certainement en faire une suivante allant plus profondemment sur les aspects techniques qui interessent, faudrait juste me dire lesquels (comme les 2 points que tu as mentionne ailleurs).

C'est aussi bien plus pratique pour l'utilisateur, c'est déjà trop d'avoir flash, silverlight et java qui peuvent s'exécuter dans le navigateur si tu ajoute dart et typescript ça deviendra infernal pour l'utilisateur

Visiblement j'ai bien compris au contraire.

si tu ajoute dart et typescript ça deviendra infernal pour l'utilisateur.

Visiblement tu n'as pas compris ce qu'est typescript. typescript genere une seule chose : du javascript, que n'importe quel browser moderne peut executer.

Typescript est la pour les developpeurs : leur permettre d'ecrire de gros softs de maniere plus robuste en rajoutant des annotations et autres elts syntaxique, mais en sortie c'est du javascript pur et dur.

J'en sais rien et personne ne le sait, ca depend du marche et de si les gens preferent pouvoir faire tourner leurs softs precedents. Si je pouvais predire le futur j'aurais deja gagne au loto 20 fois et je serais sur une plage en ce moment.