Et voila c'est officiel Vista sera le dernier OS 32 bits de la celebre firme de Redmond. Sans vouloir etre mauvaise langue il faut avouer que je les comprends un petit peu vu que le temps qu'il leur a fallu pour developper un nouvel OS (enfin pas si nouveau mais ce sera pareil pour Vista +1), ils peuvent tabler que tous le matos 32 bits seront mort d'ici la.
La seconde raison, encore une fois pure speculation, c'est que c'est vraiment trop dur de maintenir du soft fonctionnant sur differentes architecture. C'est pour ca qu'ils abandonne les procs alpha, que le XP 64 bits etait une joyeuse rigolade. Bon ok ils reussi a faire Vista qui fonctionne sous 32 bits mais pas completement sur 64. Ah oui on me dit a l'oreille que c'est pas la faute de MS mais des drivers.
Enfin bon toujours est il que les differents unix linux/*BSD etc tournent sur des multitudes d'archi differentes mais c'est vrai ils n'ont pas la boite la plus riche du monde derriere eux. A croire que la proportion de developpeurs/commerciaux est un "chouilla" en la defaveur des premiers a Redmond :).
Journal Vista dernier OS 32 bits de Redmond
17
mai
2007
# tu peux retirer 32 bits
Posté par seginus . Évalué à 10.
[^] # Re: tu peux même ne retirer que 3
Posté par moramarth . Évalué à 2.
[^] # Re: tu peux même ne retirer que 3
Posté par B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Applications
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Au niveau Linux et des *BSD, les OS tournent mais pas toujours les applications. Il suffit de prendre OpenOffice comme exemple...
MS ayant une stratégie purement commerciale, je la comprends un peu car je ne vois pas ce que lui apporte d'avoir un Windows multi-plateforme à part avoir plus de soucis. En plus, en temps qu'Ingénieur Sytème, je dois dire que la version 64 bits de XP me fait plus ch... qu'autre chose. Par ailleurs, avec l'extension PAE des processeurs x86, on n'a plus vraiment la limite des 4Go de RAM qui devenait bloquante en 32 bits (par exemple, mes serveurs Xen tournent très bien sous Debian 32 bits avec 6 Go de RAM).
Sinon, il faut être objectif, MS sais faire un OS multi-plateforme, il suffit de voir sa version embarqué de Windows. Ici le problème est différent de celui de la machine de bureau ou du petit serveur rack et il n'y a pas une architecture qui domine depuis des années. MS est donc obligé de s'adapter comme tout le monde à l'évolution rapide des architectures embarquées.
[^] # Re: Applications
Posté par patrick_g (site web personnel) . Évalué à 5.
Un très bon argument en faveur du multi-plateformes est que cela permet de détecter beaucoup plus de bugs et donc d'améliorer a robustesse du kernel.
>>> avec l'extension PAE des processeurs x86, on n'a plus vraiment la limite des 4Go de RAM
C'est quand même un très vilain hack (fortement décrié par Linus) par rapport à une machine nativement capable de supporter beaucoup de mémoire grâce à un CPU 64 bits.
[^] # Re: Applications
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
> permet de détecter beaucoup plus de bugs et donc d'améliorer a
> robustesse du kernel.
C'est vrai. Dans le cas du PC, il y a aussi une grande variété des matériels.
Si on regarde du coté des UNIX propriétaires, on remarque que le matériel était relativement homogène.
Donc, la manière de développer ainsi que le nombre de développeur permettent a mon sens de modérer tes propos.
> C'est quand même un très vilain hack
Oui, mais dans ce cas, on ne fait pas du x86 ! Le x86 est l'architecture la plus pourri des années 80. Le Z80 et le 6502 était bien mieux.
Le x86 a su dépasser la barrière des 640Ko sans que l'utilisateur soit trop pénalisé. Avec PAE, on franchi aujourd'hui la barrière des 4Go. De toute manière, c'est la plateforme x86 qui est contrainte à mort.
Si tu veux un truc propre, tu pars sur de l'Itanium ! Malheureusement, Intel vend trop de x86 du coup, il doit y avoir 100 fois plus d'ingénieur sur les puces x86 que sur l'Itanium.
Heureusement, l'architecture ARM est passé devant la x86 depuis quelques temps.
[^] # Re: Applications
Posté par qstone . Évalué à 2.
... Sans me lancer dans une querelle de clochers, là je suis pas d'accord.
Pour prendre justement le cas de la gestion mémoire, l'architecture des x86 est ingénieusement foutue (pour les connaisseurs, je parle de celle du mode protégé des processeurs x86 32 bits depuis le 80386) : pagination de la mémoire en pages de 4Ko (avec 2 niveaux d'index), avec sécurité gérable page par page (selon niveau de privilège, accès en écriture OU en exécution), prise en compte en hard de la notion de pile, des threads (changement de contexte inclus), etc.
D'ailleurs avec tous les niveaux de sécurité offerts par le 386 (sorti en 1986), je me suis toujours demandé comment des attaques du genre "stack overflow" avaient pu exister, vu qu'on peut rendre tout étanche (un processus à l'autre, et pour un même processus, le code/les données/la pile)...
Et pour ta comparaison, je dirais que l'architecture du Zilog Z80 a beaucoup plus mal vieilli des dernières années ;o) Côté mémoire il n'a jamais proposé de mécanisme pour dépasser la barrière des 64Ko (contrairement au 8086), c'était au contrôleur mémoire de se démerder : sur les amstrad CPC (128Ko), on accédait aux 64Ko supplémentaires en échangeant une "banque" de 16Ko de mémoire standard avec une de la mémoire étendue... Ahhh c'éatit l'bon temps moi j'vous dis...
[^] # Re: Applications
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
D'ailleurs, vu comme c'est partis, on va pouvoir dire dans 15 ans que les Alpha, Sparc... ont bien moins évolué que le x86 et donc que leur architecture était plus mauvaise !
Si tu me relis, je parle de l'architecture intrinsèque à un instant donné, je ne parle jamais de la capacité des ingénieurs Intel à faire évoluer leur architecture. je dois dire que sur ce point, il sont effectivement très fort.
[^] # Re: Applications
Posté par benoar . Évalué à 3.
Et bien justement, c'est parce que l'archi x86 est mal faite et ne tient pas compte des bits de lecture/écriture/exécution comme il faut, ça a été mal implémenté. Lors de l'introduction du bit NX, tout le monde a trouvé ça bien (et ça l'est), mais c'était juste une correction de l'implémentation par Intel de leur modèle (qui à la base était bien, mais mal implémenté) pour tenir _vraiment_ compte de ce qui aurait dû être depuis le début fait comme ça. J'avais trouvé un tableau des correspondances montrant les flags théorique de chaque page, et l'accès réel qu'autorisait le CPU, ça faisait peur, i.e. ça a été implémenté avec les pieds. Le pire, c'est qu'ils ont mis beaucoup de temps à changer ça pour éviter de casser la rétro-compatibilité, et que ce bug est resté très longtemps non corrigé (en gros, 20 ans, si tu dis que le 386 est sorti en 1986, et que le bit NX est sorti il n'y a que quelques années).
[^] # Re: Applications
Posté par georgeswwbush . Évalué à 1.
- Oracle sur 2003 Server Itanium existe depuis 2 ans -> il n'existe en France que 3 ou 4 boîtes qui se sont amusées à le faire
- Oracle sur Vista, c'est pas prévu (OS pour le desktop)
[^] # Re: Applications
Posté par MiniMoi . Évalué à 3.
Il me semble que cette extension est assez lente, et qu'il reste un limite de mémoire par processus, mais peut-être que je suis dans le faux.
A mon sens la principale raison de Microsoft pour faire ceci est de passer outre cette fâcheuse limite, qui est aussi un fardeau dans la gestion des fichiers de grande taille (dans Linux il me semble que c'est assez acrobatique pour les fichiers de plus de 4Go, ça marche, mais de façon complexe sur x86).
>>Sinon, il faut être objectif, MS sais faire un OS multi-plateforme, il suffit de voir sa version embarqué de Windows
Si tu veux parler de Windows CE, ce n'est pas du tout le même noyau que NT. Les structures internes sont différentes, avec quelques surprises (impossibilité d'allouer plus de 64 Mo à un processus et nombre limité de processus).
De plus pour Windows CE il me semble que la plate-forme MIPS ayant été abandonnée, il ne reste plus qu'ARM...
Donc on a vu mieux comme OS multiplateforme...
[^] # Re: Applications
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: Applications
Posté par Sylvain Sauvage . Évalué à 5.
[^] # Re: Applications
Posté par pasBill pasGates . Évalué à 3.
C'est pas par hasard que plus les annees passent, plus le nombr de plateformes supportees par les grosses distribs(Suse, Redhat,...) baisse. Ils ont le meme probleme que Windows : est-ce que ca vaut le cout de payer x personnes a tester/supporter/... une plateforme utilisee par 1% des gens alors qu'on pourrait payer ces gens a ameliorer la qualite de la plateforme utilisee par 99% des gens, et qui donc a un retour sur investissement bien plus eleve.
[^] # Re: Applications
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Applications
Posté par WH (site web personnel) . Évalué à 2.
... ni d'Emacs.
[^] # Re: Applications
Posté par briaeros007 . Évalué à 1.
Allo ici la terre.
Un code aussi compliqué que linux ou que windows qui compile du premier jet sur n'importe quelle plateforme.
Marrant j'ai quand meme du mal a y croire.
Oui le code peut compiler (apres sans doutes quelques changement) sur un certains nombre de plateforme, mais il compile pas encore sur toutes les plateformes amha.
# ...
Posté par M . Évalué à 5.
D'un autre coté vu ce que demande vista, ce que demandera vista+1 ne sera dispo que sur des machines supportant le 64 bits ;)
[^] # Re: ...
Posté par Guillaume D. . Évalué à 8.
ok --->[]
# Rectificatif
Posté par Hervé Rilos . Évalué à 3.
Sources :
http://www.engadget.com/2007/05/17/windows-still-in-32-bit-p(...)
http://apcmag.com/6121/windows_server_gets_vista_version_iti(...)
Comme quoi, toute info en provenance de Microsoft est à prendre avec des pincettes.
[^] # Re: Rectificatif
Posté par Sylvain Sauvage . Évalué à 5.
… et une combinaison NBC…
[^] # Re: Rectificatif
Posté par inico (site web personnel) . Évalué à 3.
- nucléaire
- bacteriologique
- chimique
La combinaison anti-tout :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.