Journal Vista dernier OS 32 bits de Redmond

Posté par  .
Étiquettes : aucune
0
17
mai
2007
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 :).
  • # tu peux retirer 32 bits

    Posté par  . Évalué à 10.

    voilà, c'est tout
    • [^] # Re: tu peux même ne retirer que 3

      Posté par  . Évalué à 2.

      Bon ok, je ———————>> []
      • [^] # Re: tu peux même ne retirer que 3

        Posté par  . Évalué à 10.

        oui, avec tous ces nouveau bits à gérer, cela ne m'étonnerait pas que cela parte en couille au final...

        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  (site web personnel) . Évalué à 3.

    A mon avis, ce n'est Windows qui ne tourne pas mais surtout les applications. MS ne peut pas mettre un Windows sur le marché si SQL Server, Exchange, Office... ne tournent pas bien, mais aussi les applications principales des éditeurs comme Adobe, Oracle...

    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  (site web personnel) . Évalué à 5.

      >>> je ne vois pas ce que lui apporte d'avoir un Windows multi-plateforme à part avoir plus de soucis.

      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  (site web personnel) . Évalué à 3.

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

        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  . Évalué à 2.

          > Oui, mais dans ce cas, on ne fait pas du x86 ! Le x86 est l'architecture la plus pourri des années 80.

          ... 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  (site web personnel) . Évalué à 4.

            On ne peut pas comparer l'évolution des x86 avec l'évolution du Z80. Tu as vu le nombre d'ingénieur ayant travaillé sur chaque plateforme ?

            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  . Évalué à 3.

            J'arrive après la bataille, mais :
            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 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  . Évalué à 1.

      Complément d'infos concernant les éditeurs et cette remarque pertinente:
      - 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  . Évalué à 3.

      >> 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

      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  . Évalué à 3.

        Niveau OS multiplateforme, il suffit d'avoir un minimum d'histoire informatique pour se rendre compte que NT etait multi-plateforme des sa naissance (concu sur simulateur i860, puis porte sur x86, MIPS, PPC, Alpha, Sparc qui n'a pas ete release et aujourd'hui IA64 et x64) alors que Linux a ses debuts c'etait completement i386 a tous les niveaux.
        • [^] # Re: Applications

          Posté par  . Évalué à 5.

          Le propos ici est surtout que Linux/*BSD maintiennent et ajoutent (parfois aussi perdent, par manque de combattants) des architectures alors qu’un système « multi-plateforme dès sa naissance » n’en gère plus beaucoup (deux livrées) et, à (court) terme, sera totalement mono-plateforme.
          • [^] # Re: Applications

            Posté par  . Évalué à 3.

            Tout a fait, mais il faut aussi prendre en compte le reste : support, maintenance, marketing, ... qui ont un cout. L'aspect technique ce n'est un element de l'equation. Windows tout comme Linux c'est le meme code qui compile sur toutes les plateformes, aucune difference la dessus.

            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  (site web personnel) . Évalué à 3.

              Et debian est arrivé ;-) 11 architectures supportés...
            • [^] # Re: Applications

              Posté par  . Évalué à 1.

              Windows tout comme Linux c'est le meme code qui compile sur toutes les plateformes, aucune difference la dessus.

              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  . Évalué à 5.

    Vu que vista supporte encore les applis 16bit dos, l'os sera peut etre 64 bits only, mais les appli 32 bits pourront certainement encore tourné dessus.

    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  . Évalué à 8.

      Vista + 1 sera aussi le seul OS 64 bit sur des systèmes 128 bits ...
      ok --->[]
  • # Rectificatif

    Posté par  . Évalué à 3.

    Il y aurait eu un petit rectificatif de Microsoft. Seul Windows Server serait uniquement 64bits après 2008, et rien ne serait fixé pour les autres versions pour l'instant.
    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  . Évalué à 5.

      Comme quoi, toute info en provenance de Microsoft est à prendre avec des pincettes.

      … et une combinaison NBC…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.