Virtualisation de Serveur : Linux sous Windows

Posté par  (site Web personnel) . Modéré par Amaury.
Étiquettes :
0
26
avr.
2006
Microsoft
La virtualisation de serveur est une technologie très intéressante car elle permet de faire fonctionner plusieurs instances de systèmes d'exploitation au sein d'une même machine physique. Ceci permet notamment d'offrir des hébergements "dédiés virtuel" (VDS) à un coût inférieur à un serveur dédié réel.

Des logiciels libres (Xen, UML, QEmu, OpenVZ, etc..) ou propriétaires (VMware, MS Virtual Server) permettent de construire des solutions de serveurs virtuels avec différentes fonctionnalités/contraintes. Microsoft annonce le support de Linux par MS Virtual Server 2005 R2.

Qu'en pensez-vous ? Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ? Le principe des serveurs virtuels est qu'un système hôte (Host OS) puisse héberger un ou plusieurs systèmes invités (Guest OS) en leur allouant une partie des ressources physiques de l'hôte. On peut donc avoir un hôte Linux qui héberge un invité Linux et un invité FreeBSD et/ou un invité Windows ou vice versa.

Il existe aujourd'hui environ 3 catégories de techniques/solutions de virtualisations:

Les émulateurs ou machines virtuelles (QEmu, VMWare, Bochs ou Microsoft Virtual Server)
Ces logiciels s'exécutent sur la machine hôte (généralement Windows ou Linux) et émulent une machine invitée sur laquelle on pourra installer le système invité qui croira s'installer sur une machine réelle.

Les hyperviseurs-like (Xen, UML)
Ces hyperviseurs n'ont pas nécessairement besoin d'un système hôte mais visent plutôt à offrir une couche d'abstraction matérielle la plus fine possible qui permettent d'isoler les ressources utilisées par les différents systèmes invités. Ces solutions nécessitent d'adapter/porter le système invité, ce qui empêche les systèmes propriétaires d'y être supporté facilement. Cette contrainte permet toutefois d'obtenir de meilleures performances que les émulateurs.

Les émulateurs d'OS (OpenVZ, Linux VServer ou encore les container Solaris)
Ces dernières solutions permettent à plusieurs instances du même système de partager les ressources de la même machine. On ne peut donc pas héberger un système Windows ou Linux dans un container Solaris. Toutefois, ces solutions semblent être les plus performantes et les mieux adaptés à la consolidation de serveur.

Toutes ces solutions sont très utiles et seront probablement de plus en plus présentes dans les offres d'hébergement Web ou d'autres services Internet.

Microsoft a annoncé que la version 2005 R2 de son produit MS Virtual Server supporterait des systèmes Linux . Je ne sais pas si on doit se réjouir ou non de voir certains serveurs Linux fonctionner en tant qu'invité d'un système propriétaire mais chacun se fera son opinion. Personnellement, j'aurais plutôt tendance à remettre (seulement si nécessaire) à sa place dans une fenêtre QEmu ledit système propriétaire. Mais on peut aussi y voir un signe de la nécessité de Microsoft de s'ouvrir à une demande réelle et également une tentative d'atteindre plus largement le marché des serveurs internet (Web notamment).

La question que je posais au départ attends donc vos réponses:
Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire?

Aller plus loin

  • # Ca existe déjà ...

    Posté par  . Évalué à 6.

    Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ?

    Ce genre de chose existe déjà (IBM Z/OS et Linux, il me semble également que les architectures Regata permettent de faire tourner des systèmes Linux, mais la supervision reste sous AIX. Un connaisseur pour confirmer ou rectifier mes âneries?).

    VmWare (propriétaire) permet déjà de faire tourner un Linux dans une "cage" windows.

    Pour répondre à ta question: à titre personnel je ne le ferai pas. Je n'y vois pas d'intérêt.
    • [^] # Re: Ca existe déjà ...

      Posté par  . Évalué à 5.

      Je confirme que de telles solutions existent en entreprise sur des plateformes peu communes.
      Ce genre de solution existe depuis très longtemps sur des machines que l'on appelle Mainframe.
      z/VM est l'hyperviseur vendu par IBM et permet de faire tourner différents OS (MVS, VSE, Linux S390...) en mutualisant les ressources (CPU, IO, mémoire) mise à disposition dans un environnement S/390.

      Je vous l'accorde, on ne rencontre pas ce genre de machine dans la première PME venue :)
      • [^] # Re: Ca existe déjà ...

        Posté par  . Évalué à 1.

        Je crois même me souvenir que la société Alcôve était spécialisée dans la récupération des S/390 pour cet usage. Je m'y étais interressé il y a 2 ou 3 ans. Vu le prix du matos un S/390 ne se jette pas...
    • [^] # Re: Ca existe déjà ...

      Posté par  (site Web personnel) . Évalué à 7.

      Oui bien sûr ça existe déjà mais ce qui m'a motivé à écrire l'article c'est le fait que Mircrosoft s'engage à supporter Linux dans sa solution de virtualisation, et ceci probablement en raison de la demande et de la concurrence.
      Notamment VMWare Server (http://www.vmware.com/products/server/) qui est une solution propriétaire et fonctionne à la fois sous Linux et sous Windows et est disponible gratuitement.

      Quant à IBM je ne suis pas un spécialiste mais celà fait très longtemps qu'ils maîtrisent les technologies de partitionnement système dans leur mainframevoir par exemple les LPAR de MVS (http://en.wikipedia.org/wiki/MVS) ou encore les fondements de leur système VM/CMS (http://en.wikipedia.org/wiki/VM/CMS) dans lequel VM signifie Virtual Machine. Je ne sais pas en revanche comment celà se décline dans leurs solutions zSeries/Z/OS actuelles.
      • [^] # Re: Ca existe déjà ...

        Posté par  . Évalué à 3.

        Notamment VMWare Server (http://www.vmware.com/products/server/) qui est une solution propriétaire et fonctionne à la fois sous Linux et sous Windows et est disponible gratuitement
        Il faut aussi préciser que ce server VMWare n'est pas un freeware, et que la clef d'activation finit par expirer. C'est un produit commercial payant
        • [^] # Re: Ca existe déjà ...

          Posté par  . Évalué à 5.


          #
          Q: Will VMware Server still be free when it is generally available?

          A: Yes, VMware Server will be a free product. There will not be any charge for licenses to VMware Server when it becomes generally available.


          J'interprète mal ?
          • [^] # Re: Ca existe déjà ...

            Posté par  . Évalué à 1.

            will indique un future proche et non certain ;-)
            Traduction :
            Q: Le VMWare serve sera-t'il gratuit (...)
            A: Oui VMWare sera un produit gratuit (ou libre mais j'en doute)
    • [^] # Re: Ca existe déjà ...

      Posté par  . Évalué à 3.

      Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ?

      Ce genre de chose existe déjà (IBM Z/OS et Linux, il me semble également que les architectures Regata permettent de faire tourner des systèmes Linux, mais la supervision reste sous AIX. Un connaisseu

      C'est un peu tiré par les cheveux, mais meme sur x86 c'est deja le cas :
      - L'os repose sur le bios, l'acpi, ... qui sont des logiciels proprios.
      - Les nouveaux cpu qui gèrent la virtualisation sont loin d'avoir un microcode libre...
  • # coLinux

    Posté par  . Évalué à 5.

    Tu oublies coLinux, alors que c'est certainement la meilleure solution pour faire tourner Linux sous Windows. http://www.colinux.org/
    • [^] # Re: coLinux

      Posté par  (site Web personnel) . Évalué à 2.

      Je n'ai jamais utilisé coLinux mais l'objectif est il me semble très différent, à savoir faire tourner un Linux en collaboration avec un windows. Ce que je voulais présenter sont les solutions permettant de faire fonctionner un (possiblement) grand nombre d'instances de Linux (ou d'autres systèmes d'ailleurs).

      Vu de ma fenêtre coLinux est plutôt à comparer avec un VMWare Workstation (http://www.vmware.com/products/ws/) ou Win4Lin (http://www.win4lin.com/) ou encore Wine (http://www.winehq.com/).

      C'est pour celà que je n'avais pas inclu coLinux à l'article, mais tu as raison j'aurais dû motiver cette omission.

      D'un autre côté peut-être que je me suis trompé sur les capacités de coLinux, auquel cas je suis très intéressé par me faire instruire un peu plus.
      • [^] # Re: coLinux

        Posté par  (site Web personnel) . Évalué à 7.

        Tu n'est pas limité à une seule instance de colinux.
        J'ai déjà lancé 2 colinux sur un winxp et ca fonctionnait correctement.
        Le probléme c'est que je n'ai pas pu tester longtemps, le windows hote c'est pris un 0days et je suis passé définitivement sous linux.
      • [^] # Re: coLinux

        Posté par  . Évalué à 1.

        ah non, aucun rapport avec wine ou win4lin ou cygwin.

        et le "co" était pour coopération (et coroutines), c'était une approche un peu différente des VMware, VirtualPC et compagnie qui a donné ce nom.

        http://en.wikipedia.org/wiki/Colinux va détailler ça, je mettrais un bémol sur le coté instabilité potentielle qui a été nettement réglé depuis les premiers temps héroïques.
  • # Qu'en pensez-vous ?

    Posté par  (site Web personnel) . Évalué à 4.

    >Mettriez-vous votre système libre préféré dans une cage gardée par
    >un logiciel propriétaire ?

    Ces technos me semble interessantes pour les hébergeurs.

    Et dans ce cas là je ne vois pas l'intérêt d'utilser un Linux dans un Windows. ( les hébergeurs ont beaucoup de machines )

    Pour ce genre d'utilisation chacun dans son coin:

    Des Linux dans dans Xen ( par exemple )
    Des Windows dans Microsoft Virtual Server ( par exemple )

    Cela me semble bien plus judicieux et normalement plus stable et performant.
    • [^] # Re: Qu'en pensez-vous ?

      Posté par  . Évalué à 2.

      Pas que pour les hébergeur à mon boulot, on a besoin à la fois de Microsoft (MS Offfice) et on developpe des applications Linux..

      Donc les gens ont soit deux postes, soit une émulation..
      • [^] # Re: Qu'en pensez-vous ?

        Posté par  (site Web personnel) . Évalué à 1.

        >Pas que pour les hébergeur à mon boulot, on a besoin à la fois de
        >Microsoft (MS Offfice) et on developpe des applications Linux..


        Le titre est "Virtualisation de Serveur" pas "Vitualisation de Desktop"
      • [^] # Re: Qu'en pensez-vous ?

        Posté par  . Évalué à 1.

        Dans ce cas si on peut comme moi se "contenter" de W98, Win4Lin est une très bonne solution légère et rapide (mon W98 démarre en 10 secondes sur mon petit portable (thinkpad X40) avec mandriva 2006, et j'ai même le copier coller avec Linux.
        Pour WindowsXP je déconseille Win4Lin pro, mon dernier essai malgrès kqemu: difficile -du moins pour moi qui ne programme pas- et long à installer, peu performant et encore instable, il est parti à la poubelle après une fin de semaine de bataille! et j'ai réinstallé ma vieille version avec W98.

        Par contre pour mes serveurs de cours et de travail, ils sont maintenant virtualisés des Debian sur Xen. Autre problème autre solution.
  • # Performances de UML

    Posté par  (site Web personnel) . Évalué à 7.

    En fait, il est loin d'être évident que UML soit plus performant que du Qemu (avec du kqemu en mode kernel) ou du vmware, particulièrement dans le cas de code avec beaucoup de syscalls (typiquement, quand il y a des I/O à la pelle).

    Clairement, ça reste moins performant que du Xen, cf les benchmarks (venant de l'équipe de xen certes) : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.h(...)

    Le problème est que pour pouvoir faire tourner du code non modifié, UML doit pouvoir émuler les syscalls en userland. Or pour cela, il n'y a pas énormement de solutions. En l'occurrence, UML surveille l'exécution via ptrace(). Donc à chaque syscall d'un processus guest, il va avoir un switch userland -> kernelland, le kernel s'aperçoit que y'a du ptrace(), retour en userland coté UML, UML fait disparaitre d'un coup de baguette magique le syscall original (et doit laisser probablement un syscall bidon s'exécuter, donc 2 switchs à nouveau), puis s'occupe d'émuler le syscall, ce qui signifie probablement souvent plusieurs syscalls et donc switch userland/kernelland. Et ensuite, 2 derniers switchs pour continuer l'exécution du processus guest.

    Or le problème c'est que du switch kernelland/userland, c'est extrêmement lent (un long call c'est rien à coté), d'où des perfs qui s'écroulent des qu'il y a des I/O.

    Xen, pour éviter cela, joue avec les ring 1/2 des x86 (chose qui existe sur peu d'autres processeurs, beaucoup n'ayant que 2 modes, kernel & user, contre 4 pour les x86).

    Je ne prétends pas que qemu/kernelkqemu & vmware sont systématiquement plus rapides que UML, mais juste que les perfs d'UML ne sont certainement pas à rapprocher de Xen. J'aimerais bien mettre en place qq benchmarks, mais le temps n'étant pas extensible, c'est pas gagné ...

    (et je soupçonne que CoLinux ai le même problème - mais là c'est de la pure spéculation :)
  • # Non bien sur!

    Posté par  (site Web personnel) . Évalué à 10.

    De ce que je perçois des nouveautés sur ce secteur, si Microsoft a décidé de développer le support de Linux, c'est certainement pour ne pas se laisser prendre trop de parts de marché par VMWare qui rappellons-le a sorti récemment une version gratuite (mais non libre) pour serveur.

    Il est évident que le géant de Redmond ne peut se permettre d'être absent ou acteur mineur sur un marché en pleine expension. En effet, comme d'autres l'ont mentionné, les machines virtuelles existent depuis des lustres sur les Mainframe IBM et sur le haut de gamme de Sun. La nouveauté c'est qu'avec la montée en puissance des micros et l'arrivée récente des processeurs à coeur multiples, il est devenu tout à fait rentable de développer des solutions de virtualisation pour micros. A n'en pas douter, il s'agit là d'un marché en pleine expension. Que ceux qui n'ont pas encore gouté au plaisir d'avoir plusieurs OS tournant en même temps aillent télécharger la version d'essai de VMWare. :)

    Ce qui est ici intéressant de noter c'est tout de même que Microsoft fait contre mauvaise fortune bon coeur. Après avoir tant décrié son adversaire Linux en lui taillant toutes les croupières possibles, le voilà presque obligé de lui accorder une reconnaissance en le supportant dans l'un de ses produits. C'en est presque risible..

    Sur le même sujet, une interview du créateur d'OpenVZ est parue il y a quelques jours: http://kerneltrap.org/node/6492
    Sa lecture permettra de compléter les informations techniques de cette dépêche.

    Enfin pour répondre à la question initiale, je préfèrerai mille fois faire le contraire, à savoir mettre l'OS proprio dans une cage plutôt que d'enfermer un logiciel libre...


    PS: merci pour cette dépêche fort intéressante et très bien rédigée.
    • [^] # Re: Non bien sur!

      Posté par  . Évalué à 5.

      Je suis tout à fait d'accord avec ce raisonnement.

      "je préfèrerai mille fois faire le contraire, à savoir mettre l'OS proprio dans une cage plutôt que d'enfermer un logiciel libre..."
      Idem. C'est quand même plus crédible d'un certain point de vue.

      Je pense surtout que le géant de Redmond commence à voir une réelle menace de la part de Linux et les LL en général, et essaie de garder ses parts de marché par quelques moyens que ce soit.

      Comme déjà dit plus haut, il existe déjà foule de machines virtuelles...
      • [^] # Re: Non bien sur!

        Posté par  (site Web personnel) . Évalué à 5.

        Je pense surtout que le géant de Redmond commence à voir une réelle menace de la part de Linux et les LL en général

        Je ne pense pas. Au contraire, MS montre encore une fois sa volonté d'augmenter ses parts de marché dans sur le marché des serveurs.

        N'ayant plus rien a gagner du coté desktop ... MS part donc a la conquete de nouveaux marchés.
    • [^] # Re: Non bien sur!

      Posté par  . Évalué à 4.

      hors propos mais ..

      2 fois expension dans ton post, ca n'est pas une faute de frappe.
      on écrit extension
      et expansion

      J'en profite avant qu'il n'entre dans le top 50
      http://www.google.fr/custom?cof=AH%3Acenter%3BLP%3A1%3BLW%3A(...)
    • [^] # Re: Non bien sur!

      Posté par  (site Web personnel) . Évalué à 3.

      Que ceux qui n'ont pas encore gouté au plaisir d'avoir plusieurs OS tournant en même temps aillent télécharger la version d'essai de VMWare. :)


      Il y'a même une version "freeware" sans expiration, vmplayer : http://www.vmware.com/products/player/
  • # Vista // Linux

    Posté par  . Évalué à -1.

    Mettriez-vous votre système libre préféré dans une cage gardée par un logiciel propriétaire ?
    Aurons nous le choix? Émulé Linux c'est possible! Mais émulé Vista ça va être plus dur (déjà en natif ..., sans parler des drm). À moins que QEmu explose MS Virtual Server.
    • [^] # Re: Vista // Linux

      Posté par  (site Web personnel) . Évalué à 2.

      Oui enfin on pourra installer un Vista quand il sera vraiment disponible....
      Personnellement je préfèrerais dire comme Louis Naugès,
      "Hasta la Vista!!"
      http://nauges.typepad.com/my_weblog/2006/03/hasta_la_vista_.(...)
      • [^] # Re: Vista // Linux

        Posté par  (site Web personnel) . Évalué à 5.

        Le billet de Louis Naugès est assez bon mais on trouve cette phrase :

        Changer de général n’a jamais amélioré la position stratégique d’une armée.

        Je conseillerais volontier à cette personne de se pencher sur l'histoire de l'armée d'Italie avant et après la prise de commandement de Bonaparte.
        • [^] # Re: Vista // Linux

          Posté par  . Évalué à 4.

          Merci de vos commentaires sur mon papier

          Concernant le pouvoir d'un Général, et Bonaparte en particulier, vous avez raison. Sur le terrain, Bonaparte avait une armée, probablement moins nombreuse que celle qui tente de construire Vista.
          La principale différence, et qui explique que Bonaparte pouvait, rapidement faire la différence, est qu'il n'avait pas un boulet à traîner qui s'appelle, pour Vista, 50 Millions de lignes de code en mode spaghetti !

          Louis Naugès
          Président
          Microcost
          • [^] # Re: Vista // Linux

            Posté par  . Évalué à 3.

            Arf certes les "50 Millions de lignes de code en mode spaghetti" ne sont pas gage d'un produit de bonne qualité , et de facilité de développement et de maintenance!

            Mais MS a largement demontré par le passé qu'il etait capable de vendre/diffuser des OS de qualité médiocre ( cf Win3.1, Win95,...) avec grand succes. Donc bon, meme si Vista n'a pas la qualité escomptée, son succes ne fait que tres peu de doute.
            • [^] # Re: Vista // Linux

              Posté par  (site Web personnel) . Évalué à 6.

              Son succès fait d'autant moins de doute que quand les gens achèterons leur ordi en 2007 il y aura Vista dessus. Marché captif absolu.
            • [^] # Re: Vista // Linux

              Posté par  . Évalué à 4.

              Arf certes les "50 Millions de lignes de code en mode spaghetti" ne sont pas gage d'un produit de bonne qualité , et de facilité de développement et de maintenance!

              Si seulement le code etait spaghetti... malheureusement pour tous nos chers integristes du libre qui refusent de voir la realite en face le code est propre et de qualite, comme l'ont constate la plupart des gens qui ont jete un oeil aux sources de Windows 2000 leakees sur le net.

              Donc bon, meme si Vista n'a pas la qualité escomptée, son succes ne fait que tres peu de doute.

              Ca c'est vrai, imagines donc ce que sera vu que la qualite sera la :)
              • [^] # Re: Vista // Linux

                Posté par  (site Web personnel) . Évalué à 2.


                Si seulement le code etait spaghetti... malheureusement pour tous nos chers integristes du libre qui refusent de voir la realite en face le code est propre et de qualite, comme l'ont constate la plupart des gens qui ont jete un oeil aux sources de Windows 2000 leakees sur le net.


                Constaté ? Je n'ai rien lut concernant le code source de Windows 2000 autre que c'etait dangereux de l'avoir sur son disque dur.
                Et que la plupart de gens qui pourrait nous dire si le code est propre ne peuvent pas car ils bossent sur le kernel linux, samba, wine, reactos, etc ...
                • [^] # Re: Vista // Linux

                  Posté par  . Évalué à 2.

                  Constaté ? Je n'ai rien lut concernant le code source de Windows 2000 autre que c'etait dangereux de l'avoir sur son disque dur.

                  Bah tu sais il y a toujours 2 choses : la theorie et la realite

                  Theorie : il est illegal de downloader / lire les sources de Windows 2000 leakees sur le net
                  Realite : Bcp de gens ne se sont pas gene pour enfreindre la loi et jeter un oeil aux sources

                  Et que la plupart de gens qui pourrait nous dire si le code est propre ne peuvent pas car ils bossent sur le kernel linux, samba, wine, reactos, etc ...

                  Pourquoi ? Faut bosser dans les LL pour savoir si le code est propre ? Tu crois que personne a part les devs du kernel Linux ne sait comment ecrire un kernel ?
                  • [^] # Re: Vista // Linux

                    Posté par  (site Web personnel) . Évalué à 1.

                    Entre jeter un oeil aux sources et faire un examen complet des sources il y a une grosse difference.
                    On ne peut constater quand on a fait cet examen complet.
                    Et qui peut faire un examen complet (correcte s'il faut le préciser) de ce genre de code source ?
                    Les devs des differents kernel libre et ceux qui ont une tres bonne connaissance sur le fonctionnement interne d'un O.S.
                    Mais bon, ils ne peuvent pas car Microsoft leur ferait un jolie procés à eux et aux projects auquels ils participent.
                    Et c'est valide aussi s'il ne sont pas devellopeur libre, ca se reglera seulement à coup de "cadeau" et du licenciement de la personne concerné.

                    Donc si tu me sors que des personnes externe à microsoft et qui n'ont pas un NDA avec lui on fais des "constatation" sur le code leaké, c'est que:
                    - soit c'est des script kiddie qui ne connaissent pas grande chose;
                    - soit c'est des menteurs.
                    • [^] # Re: Vista // Linux

                      Posté par  . Évalué à 3.

                      Entre jeter un oeil aux sources et faire un examen complet des sources il y a une grosse difference.
                      On ne peut constater quand on a fait cet examen complet.


                      Ah bon ? Faut lire _toutes_ les sources de l'OS pour se faire une idee ?

                      Donc en bref, lire 95% des sources du kernel Linux et voire que le code est de bonne qualite ne signifie pas que le kernel est ecrit proprement, car les 5% restants pourraient etre totalement differents et jeter l'opprobre sur le kernel entier...

                      Et qui peut faire un examen complet (correcte s'il faut le préciser) de ce genre de code source ?
                      Les devs des differents kernel libre et ceux qui ont une tres bonne connaissance sur le fonctionnement interne d'un O.S.


                      T'es au courant qu'il y a plein de gens qui ont de tres bonnes connaissances sur le fonctionnement interne d'un OS hein ?

                      Mais bon, ils ne peuvent pas car Microsoft leur ferait un jolie procés à eux et aux projects auquels ils participent.
                      Et c'est valide aussi s'il ne sont pas devellopeur libre, ca se reglera seulement à coup de "cadeau" et du licenciement de la personne concerné.


                      Faudra alors m'expliquer pourquoi tant de gens ont commente sur la qualite des sources sur le net, faut croire qu'ils n'avaient pas peur du grand mechant MS et ses avocats poursuivant inlassablement tout le monde.

                      Donc si tu me sors que des personnes externe à microsoft et qui n'ont pas un NDA avec lui on fais des "constatation" sur le code leaké, c'est que:
                      - soit c'est des script kiddie qui ne connaissent pas grande chose;
                      - soit c'est des menteurs.


                      Moi je crois surtout que tu n'as pas envie d'accepter le fait que MS peut ne pas faire que de la merde.
                      • [^] # Re: Vista // Linux

                        Posté par  (site Web personnel) . Évalué à 3.

                        Sauf qu'on n'a pas 95 % des sources du kernel.
                        Ce serait plutot 20 % et pas les couches les plus basses d'apres le commentaire ci-dessous.

                        La plupart des gens qui ont une bonne connaissance du fonctionnement interne theorique et pratique d'un O.S. ne lisent pas des sources leaké.
                        Ce serait un suicide juridique.

                        Je crois plutot que tu n'ose pas etre sincére et que tu sait tres bien que Windows est toujours instables malgrés le kernel NT.
                        Qu'un programme en userland dans un compte avec le moins de privilége possible puisse crasher la machine en se contentant de faire un printf, c'est assez révélateur sur la qualité du kernel.
                        • [^] # Re: Vista // Linux

                          Posté par  . Évalué à 2.

                          Sauf qu'on n'a pas 95 % des sources du kernel.
                          Ce serait plutot 20 % et pas les couches les plus basses d'apres le commentaire ci-dessous.


                          Ben c'est assez simple, il y a _largement_ plus de 20% du kernel de l'epoque qui a leake, les 20% tu les sors d'ou ? Tu n'en sais _absolument_ rien, tu as juste invente un chiffre a la mord moi le noeud.

                          La plupart des gens qui ont une bonne connaissance du fonctionnement interne theorique et pratique d'un O.S. ne lisent pas des sources leaké.
                          Ce serait un suicide juridique.


                          Tout a fait, disons 80% au moins ne les liront pas, ca laisse bien 20%. Tout comme une bonne partie des gens bossant sur des kernels ne liront pas le kernel Linux de peur d'etre "impregnes".

                          Je crois plutot que tu n'ose pas etre sincére et que tu sait tres bien que Windows est toujours instables malgrés le kernel NT.

                          Ah quel humour... Alors que plein de gens ici meme reconnaissent que Windows depuis Windows 2000 est tout a fait stable, que nombre de societes ont leurs serveurs critiques sous Windows, que des societes comme Stratus vendent leur systemes avec Windows dessus,...

                          Dur d'accepter la realite hein ?

                          Qu'un programme en userland dans un compte avec le moins de privilége possible puisse crasher la machine en se contentant de faire un printf, c'est assez révélateur sur la qualité du kernel.

                          Ah et maintenant une anerie sur un bug en particulier dont tu tires une remarque sur tout le systeme, comme c'est de bonne foi...
                          Mais t'as probablement raison, le kernel Linux lui il ne contient jamais de bugs, d'ailleurs tous ces oops dans le changelog sont juste la pour faire joli.
                          • [^] # Re: Vista // Linux

                            Posté par  (site Web personnel) . Évalué à -1.

                            Le chiffre ne doit pas etre loinn de la verité vu le bazar dans les sources ...

                            Sur les 20% de personne assez qualifié, combien peuvent vraiment l'etudier ? Et combien oseront le dire ?
                            Tres tres peu.
                            Et il n'y a pas de probléme pour lire le code source du kernel linux puisqu'il est sous GPL.
                            A moins de faire un copier-coller massif de partit du code, le devellopeur n'a rien à craindre.
                            Le code leaké, il y a microsoft qui attend avec ses avocats.
                            Difference enorme ...

                            Windows Nt est instable, c'est du au boulet qu'il se traine.
                            Faire appel aux anciennes API 16 bits peut faire beaucoup de mal à la stabilité du systéme.

                            Franchement, sur le bug du printf, c'est quand même assez impressionnant.
                            Les oops corrigé dans le kernel linux le sont plutot sur des API plus complexes.

                            Bon, on continue ou on s'arrette ?
                            Ca fatigue de discuter sur ce genre de sujet avec toi ...
                            • [^] # Re: Vista // Linux

                              Posté par  . Évalué à 2.

                              Sur les 20% de personne assez qualifié, combien peuvent vraiment l'etudier ? Et combien oseront le dire ?
                              Tres tres peu.


                              Ah bon ? Tu en sais quoi ? Quid des gens qui ont commente ce code en public, sur des sites web ?

                              Et il n'y a pas de probléme pour lire le code source du kernel linux puisqu'il est sous GPL.
                              A moins de faire un copier-coller massif de partit du code, le devellopeur n'a rien à craindre.
                              Le code leaké, il y a microsoft qui attend avec ses avocats.
                              Difference enorme ...


                              Quedalle, si t'es un kernel dev et tu t'amuses a lire du code sous une licence que tu ne peux pas reutiliser(code MS, ou code GPL si tu bosses sur un kernel proprio), meme probleme.

                              Windows Nt est instable, c'est du au boulet qu'il se traine.
                              Faire appel aux anciennes API 16 bits peut faire beaucoup de mal à la stabilité du systéme.


                              Tu vois, c'est la ou tu montres que tu ne comprends absolument rien et que tu parles de ce que tu ne connais pas.

                              Je t'aide, il n'y a pas _un seul_ composant 16 bits dans Windows NT. Tout ce qui est 16bits tourne dans un emulateur.
                              Bref, l'OS ne se base sur absolument _rien_ qui soit 16bits

                              Tu serais donc prie d'eviter de sortir des aneries sur cet OS que visiblement tu ne connais pas du tout.

                              Franchement, sur le bug du printf, c'est quand même assez impressionnant.
                              Les oops corrigé dans le kernel linux le sont plutot sur des API plus complexes.


                              Oui bien sur, les devs du kernel ne font jamais d'erreurs stupides c'est bien connu. D'ailleurs personne ne se rappelle de la celebre VM a Rik du kernel 2.2 hein...

                              Bon, on continue ou on s'arrette ?
                              Ca fatigue de discuter sur ce genre de sujet avec toi ...


                              Ben arretes de sortir des aneries sur un OS que visiblement tu ne connais pas du tout, et tu ne m'entendras plus...
                • [^] # Re: Vista // Linux

                  Posté par  (site Web personnel) . Évalué à 3.

                  Pour avoir pas mal étudié ce code qui se trouve facilement sur les P2P, il faut reconnaître que :

                  - Je n'ai jamais vu un code aussi bien écrit
                  - aussi clair
                  - aussi bien commenté (tu as très souvent autant de commentaires que de lignes de codes, voires plus)
                  - On sent que les types qui codent sont très fort.

                  On sent une organisation très poussée derrière.

                  A mon sens, c'est l'utopie de vouloir batir un système totalement intégré de plusieurs millions de lignes qui pèche, on voit bien que vouloir se lancer dans un truc pareil en C/C++ c'est de la folie pure, mais ils ont a peu près réussi...

                  Maintenant, une bonne partie du code est parait-il écrite en C#, PbPg nous dira peut quelle proportion (à la louche), et C# étant un langage de haut niveau, je pense que ça doit justement être mieux écrit (langage haut niveau), mieux pensé (langage objet), sans les problèmes de pointeurs que certains systèmes d'exploitations trainent encore.

                  Un OS écrit dans un langage sans pointeur, ça tournera à mon avis très bien , lentement certes (JIT), mais sans trop de bug.

                  J'aime pas Krosoft, mais faut être objectif et fair-play.

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: Vista // Linux

                    Posté par  (site Web personnel) . Évalué à 3.

                    >Maintenant, une bonne partie du code est parait-il écrite en C#, PbPg
                    >nous dira peut quelle proportion (à la louche), et C# étant un langage
                    >de haut niveau, je pense que ça doit justement être mieux écrit
                    >(langage haut niveau), mieux pensé (langage objet), sans les
                    >problèmes de pointeurs que certains systèmes d'exploitations trainent
                    >encore.

                    Alors la tu vois c'est marrant ca casse tout de suite tout ce que tu dit
                    plus haut. En quoi un langage haut niveau va forcement de pair avec
                    une meilleure ecriture du code ? Moi je suis fan de perl qui est un
                    langage de haut niveau mais alors question clareté du code s'il fallait
                    donner dess notes aux applis perl ca va du -20 au 20.

                    Ensuite les problèmes de pointeurs tu les a aussi dans ces langages de haut niveau, la différence c'est que tu fait confiance au
                    langage pour les relger pour toi ce qui dans le cas d'un OS est de la
                    folie.

                    Et enfin tu devrait te renseigner sur les fondation d'un OS multitache
                    avant de dire de telles choses. Il est totalement impossible de faire
                    avec la technologe matérielle actuelle un OS dans un langage ne
                    gérant pas les pointeurs.

                    >Un OS écrit dans un langage sans pointeur, ça tournera à mon avis
                    >très bien , lentement certes (JIT), mais sans trop de bug.

                    Bon déjà on pourrait objecter qu'addresser le materiel sans gestion
                    de pointeur c'est impossible, de même que la gestion de tout ce qui
                    est mémoire (bein oui faut bien a un momment que quelqu'un s'en
                    occupe). La gestion de la table de mapping mémoire par exemple.
                    Y a aussi la commutation de contexte kernel<->user avec toute les
                    copies que cela implique.
                    Ca fait plus de 10 ans que des langages haut niveau existent (ada, smalltalk, perl, et meme java) et pourtant personne n'a sorti un OS
                    multitache en les utilisant comme fondation, bizarre non ?
                    Encore que pour ada il y ai des projets, mais faut avouer que le
                    langage à de serieux avantages et n'est pas aussi limitant que java
                    au niveau de la mémoire.

                    Comme dit plus ceux qui donnent leur avis sur les sourcces leaké sont soit des menteurs soit n'y connaissent pas grande chose.
                    • [^] # Re: Vista // Linux

                      Posté par  . Évalué à 3.

                      Alors la tu vois c'est marrant ca casse tout de suite tout ce que tu dit
                      plus haut. En quoi un langage haut niveau va forcement de pair avec
                      une meilleure ecriture du code ? Moi je suis fan de perl qui est un
                      langage de haut niveau mais alors question clareté du code s'il fallait
                      donner dess notes aux applis perl ca va du -20 au 20.


                      Parce qu'ecrire du code clair en C est bcp plus dur qu'en C# (ou autres langages de haut niveau) du fait de la complexite du code. Pour faire la meme chose tu ecris 10'000 lignes en C, et 1000 en C#, tres vite tu te rends compte que lire 1000 lignes est plus simple que 10'000, sauf si le gars fait expres pour rendre son code illisible.

                      Ensuite les problèmes de pointeurs tu les a aussi dans ces langages de haut niveau, la différence c'est que tu fait confiance au
                      langage pour les relger pour toi ce qui dans le cas d'un OS est de la
                      folie.


                      T'es au courant qu'un OS c'est bcp plus qu'un kernel dis moi ? Il y a plein de composants user-mode dedans aussi.
                      Quand a faire confiance au langage, pourquoi serait-ce de la folie ? Il est la pour ca, et il fait tres bien son travail.

                      Et enfin tu devrait te renseigner sur les fondation d'un OS multitache
                      avant de dire de telles choses. Il est totalement impossible de faire
                      avec la technologe matérielle actuelle un OS dans un langage ne
                      gérant pas les pointeurs.


                      Si tu parles du kernel, oui, mais les millions de lignes de Windows elles sont pas toutes dans le kernel hein, le kernel c'est une petite partie dans l'ensembe. Explorer, les afficheurs d'image, etc... peuvent etre ecrit en C# (ca veut pas dire qu'ils le sont, mais ils peuvent l'etre)

                      Comme dit plus ceux qui donnent leur avis sur les sourcces leaké sont soit des menteurs soit n'y connaissent pas grande chose.

                      Moi je dirais plutot que tu as tendance a associer OS == kernel, ce qui est totalement faux, le kernel Windows c'est probablement bcp moins de 10% du systeme entier.

                      Sinon, pour en finir, je sais pas vraiment quelle pourcentage de Vista est en C#, je me suis pas amuse a faire de stats, je sais qu'il y en a ici et la, mais je sais pas combien
                      • [^] # Re: Vista // Linux

                        Posté par  . Évalué à 3.


                        Explorer, les afficheurs d'image, etc... peuvent etre ecrit en C# (ca veut pas dire qu'ils le sont, mais ils peuvent l'etre)

                        C'est bien là que se situe votre malentendu.
                        Pour un windowsien, WMA, explorer, IE, le sytème de fenêtrage font partie de l'OS. Partant de là il est possible de confier le développement de ces parties à un langage de haut niveau, exécuté sur un runtime. (Même si on a vu circuler il n'y a pas longtemps une rumeur comme quoi la devise de M$ serait plutôt: faites comme je dis mais ne faites pas comme je fais).
                        Il n'en demeure pas moins qu'un projet de M$ vise à baser l'OS/kernel sur un langage de haut niveau et plutôt que de se chamailler, les libristes feraient peut-être mieux d'explorer cette piste.
                        Allez à toi de jouer Ontologia je t'ai vu venir avec tes gros sabots ;-)
                      • [^] # Re: Vista // Linux

                        Posté par  . Évalué à 2.

                        tu as tendance a associer OS == kernel, ce qui est totalement faux

                        Là, je ne peux pas te suivre. Pour moi l'O.S. c'est le noyau, c'est ce qui permet aux applications une certaine abstraction du hard. C'est ce qui gère la mémoire, l'ordonanceur, les interruptions, ...
                        Personnellement, à mon avis, le process init ne fait pas parti de l'O.S. (sous linux, je parle) j'en veux pour preuve qu'il a été porté sous windows grace à cygwin.
                        Le problème avec windows, c'est qu'on ne sait pas trop où se situe la limite.
                        • [^] # Re: Vista // Linux

                          Posté par  . Évalué à 4.

                          Là, je ne peux pas te suivre. Pour moi l'O.S. c'est le noyau, c'est ce qui permet aux applications une certaine abstraction du hard. C'est ce qui gère la mémoire, l'ordonanceur, les interruptions, ...

                          Ben si c'etait la meme chose, pourquoi donc 2 termes differents ?

                          D'autre part, tu peux avoir 2 OS differents, utilisant le meme noyau.

                          Prends le noyau NT par exemple, si tu gardes uniquement la personality Win32 dessus, tu as le Windows que tout le monde connait.

                          Tu enleves cette personality, tu mets la personality POSIX dessus, tu as un OS quasi-Unix, et ou les softs Windows habituels ne tournent pas.

                          Le kernel tout seul, il donne les primitives de base, mais ce n'est pas lui qui definit l'OS entierement. Il y a la glibc, etc... qui comptent aussi, et sans lequel tu ne peux rien faire tourner.
                    • [^] # Re: Vista // Linux

                      Posté par  (site Web personnel) . Évalué à 5.

                      Ensuite les problèmes de pointeurs tu les a aussi dans ces langages de haut niveau, la différence c'est que tu fait confiance au
                      langage pour les relger pour toi ce qui dans le cas d'un OS est de la
                      folie.


                      L'existance d'IsaacOS prouve que ton assertion est fausse. Cet OS, très rapide a été écrit dans un langage objet à prototype sans pointeurs. Et avec les même perfs que C...

                      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Vista // Linux

            Posté par  . Évalué à 0.

            Arf certes les "50 Millions de lignes de code en mode spaghetti" ne sont pas gage d'un produit de bonne qualité , et de facilité de développement et de maintenance!

            Mais MS a largement demontré par le passé qu'il etait capable de vendre/diffuser des OS de qualité médiocre ( cf Win3.1, Win95,...) avec grand succes. Donc bon, meme si Vista n'a pas la qualité escomptée, son succes ne fait que tres peu de doute.
            • [^] # Re: Vista // Linux

              Posté par  . Évalué à 0.

              et en quoi Windows 3.1 était "de qualité médiocre" ?

              Windows 95, je ne dis pas, ils l'ont certainement mis un peu trop vite sur le marché tandis que Windows 98 ou 98 SE représente un produit nettement mieux fini. Windows ME était un autre exemple de ratage, pour encore d'autres raisons


              mais à son époque, Windows 3.1 était loin d'être ridicule. OS 2... oh, il lui fallait juste 4 Mo de ram
              • [^] # Re: Vista // Linux

                Posté par  . Évalué à 4.

                A l'epoque de Windows 3.1, il y avait OS/2 et franchement y avait pas photo.
                • [^] # Re: Vista // Linux

                  Posté par  . Évalué à 0.

                  en effet.

                  périphs pas supportés à foison, et ça a duré des années. on ne peut pas dire qu'ils manquaient de ressources, pourtant, eux.

                  4 Mo de ram mini, et elle n'était pas vendue 3 francs six sous. une appli phare de l'époque, de reconnaissance vocale (VoiceType ?) réclamait je crois 8 ou 16 Mo, enfin un chiffre risible tellement il était monstrueux

                  il n'y avait vraiment pas photo.
  • # Hurd

    Posté par  . Évalué à 2.

    Ce n'est pas pour lancer un troll idiot, mais une vrai question.

    Hurd si il tourne sur un micro noyau genre l4 ou coyotos, defini un mecanisme de capacibilite, permetant de dire telles taches on le droit d'utiliser telles ports, or la gestion du hardware passe aussi par des serveurs donc des ports.

    Hurd permet de redefinir les serveurs auth et proc , et tous ce que l'on veut.

    Donc Hurd permet une virtualisation sans pariel de chaqu'un de ces composant ou des groupe de composant pour faire tourner autant de pilote taches serveur protocole ou systeme de fichiers que l'on veux

    La question est de savoir si la virtualisation type xen a un tant soit d'interet sur le Hurd ?
    • [^] # Re: Hurd

      Posté par  . Évalué à 4.

      Xen et Hurd sont 2 choses totalement differentes(pas le meme niveau d'abstraction), donc oui, Xen a un sens pour Hurd aussi.
  • # Demande de précision

    Posté par  . Évalué à 2.

    Bonjour à tous,

    J'aimerais obtenir une précision de la part de personnes ayant déjà utilisé OpenVZ.

    Sur mon lieu de travail, nous utilisons Xen. Cela nous permet d'avoir par exemple sur une même machine physique plusieurs machines virtuelles faisant tourner un serveur HTTP sur le port standard, donc 80. Les VM étant complètement indépendantes, cela ne pose pas de problème.

    Avec OpenVZ, si je crée 2 VM hébergeants chacune un serveur HTTP, ceux-ci peuvent-ils être attachés tous deux au port 80 ?

    Si mes souvenirs sont exacts, il me semble avoir eu des problèmes avec Vserver. Je crois me rappeler que Vserver fonctionnait dans le principe comme un "super" chroot, donc avec les mêmes limitations.

    Merci pour les eventuelles informations.
    • [^] # Re: Demande de précision

      Posté par  . Évalué à 3.

      Pour OpenVZ je ne sais pas, mais si tu veux faire tourner plusieurs serveurs HTTP sur le port 80 avec vserver, ca ne pose aucun problème.

      Chaque vserver a une IP différente et il n'est en écoute que sur cette IP.
  • # Retour d'expérience et réflexions

    Posté par  . Évalué à 7.

    Dans le cadre d'un projet en fin d'année dernière, j'ai dû installer des Linux (SLES 9) sur des MS Virtual Server au-dessus de Win2003.

    Les problèmes majeurs rencontrés :
    - désynchronisation énorme des horloges (et donc dysfontionnements lourds pour toutes les applications qui en dépendent... c'est à dire beaucoup)
    - bug apparent de l'émulation SCSI

    Microsoft promet de corriger précisément ces défauts là (voir lien de l'article). Bien joué Bill.

    En revanche, sauf pour ceux qui voudraient faire tourner un seul Linux au milieu d'une horde de Windows tous exécutés sous Virtual Server, je ne vois guère l'intérêt de s'appuyer sur Win2003 + Virtual server, sauf si les versions prochaines sont vraiment très, très, très perfomantes. Est-ce probable ?

    Entre autre, en première approche, Virtual Server suppose l'installation d'IIS sur la machine hôte, et probablement de tout un tas d'autres "services". La surface d'exposition aux véroles du système hôte est donc importante. Puisque c'est un Windows sur le réseau, il va lui falloir... un anti-virus (et les problèmes qui l'accompagnent). Il va falloir mettre tout ça à jour régulièrement et, sauf à ce que Vista soit vraiment un Windows révolutionnaire, rebooter assez souvent, vérifier que certains services ne se sont pas réactivés durant l'application des services packs, etc... L'interface graphique va demeurer également, qui consomme des ressources.
    Bref ! Là où on souhaiterait un serveur de VM tournant au-dessus d'un système hôte dépouillé, pour maximiser les perfs et minimiser les interruptions de service, on se retrouve avec tout le tintouin de Windows et les peines qui l'accompagnent. Les systèmes et applications hébergés dans les VM vont en pâtir.

    Autre point : tout comme pour VmWare, il faut patcher chaque OS hébergé dans chaque VM pour qu'il se sente à l'aise dans la dite VM. Apparemment, ces "patches" ne sont pas disponibles pour les kernels en eux même, mais conçus distribution par distribution. Microsoft en propose actuellement pour des RedHat et des Suse.
    - Sont-ils compatible avec des noyaux compilés manuellement ?
    - Qu'est-ce qui est changé dans le Linux ; est-ce transparent, documenté ? Si RedHat diffuse une mise à jour critique pour le kernel de la RHEL4 et les rustines Microsoftiennes "sautent" dans chaque VM qui devient inopérante après mise à jour. En quel délai MSFT diffuse-t-il une nouvelle version de sa rustine, à quoi s'engagent-ils ?
    - Et si on veut exécuter une Debian, tester une pré-release, une autre distribution... on pleure. Idem sous VMWare à ma connaissance, d'ailleurs. Qu'en est-il avec Les autres systèmes de virtualisation ?

    Pour finir : en deux mois d'utilisation intensive de ces VM sur proc Intel, et nonobstant les problémes mentionnés tout en haut (dont un majeur), la stabilité de Virtual Server + SLES9 a été très satisfaisante (il s'agissait de prototypage, assez exigeant cependant).

Suivre le flux des commentaires

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