Affiche déporté

• [^]Re: Affiche déporté

  Posté par brazz () le 17/08/2007 à 21:39. (lien). Évalué à 4.

  Absolument, je connais Citrix depuis le début en France (1995: J'avais pu faire des saisies de données en environnement graphique avec des modems à...28800 -époque héroîque- et c'était fluide.) et NX depuis le portage sous GPL dans la Knoppix et en fait c'est bien vrai que le seul concurrent libre de Citrix c'est bien FreeNX.
  Cela n'a rien à voir avec la virtualisation, c'est "juste" de l'affichage déporté hyper optimisé au niveau compression des modifications de ce qui est affiché à l'écran, sur la machine distante il n'y a rien de plus qu'une session X mais c'est nettement plus optimisé que ce que fait VNC par exemple. D'un autre côté VNC est portable sur n'importe quoi même un PDA ou un grille pain (là je suis moins sur...).
  Donc la comparaison et la discussion ne peuvent se faire que sur Citrix, VNC et NoMachine-FreeNX.

  • [^]Re: Affiche déporté

    Posté par kowalsky () le 18/08/2007 à 10:43. (lien). Évalué à 2.

    
    D'un autre côté VNC est portable sur n'importe quoi même un PDA ou un grille pain (là je suis moins sur...).
    

    
    
    http://www.flickr.com/photos/laughingsquid/sets/738459/
    
    http://pkgsrc.se/net/vnc
    
    Of course it runs NetBSD ! :)

    --
    You got the money, I got the soul.

    • [^]Re: Affiche déporté

      Posté par Antoine Nivard (page perso, ) le 22/08/2007 à 09:09. (lien). Évalué à 1.

      VNC n'a rien à voir avec CITRIX, il ne faut pas tout mélanger...
      
      On peut comparer CITRIX avec Free-NX, nomachine et SUN secure global desktop
      
      Avant de crier qu'il y a d'autre solution il est bon de regarder en détails les caractéristiques des produits...

Bon à savoir

• [^]Re: Bon à savoir

  Posté par rarcel (page perso, ) le 17/08/2007 à 11:58. (lien). Évalué à 1.

  Oui enfin ce n'est pas pour moi destiné au meme usage, aujourd'hui je ne me vois pas virtualiser un serveur sous kvm alors que xen à ce niveau la est relativement robuste. Par contre sur du desktop la y'a pas photo, kvm a une place a prendre

  • [^]Re: Bon à savoir

    Posté par Clément David (Jabber id, page perso, ) le 17/08/2007 à 12:27. (lien). Évalué à 3.

    Quel peux être l'intérêt de virtualiser pour le desktop?
    
    Pour le serveur c'est compréhensible, dans des mainframes ou en virtualisant chaque utilisateur, mais ces raisons ne sont pas valable pour le desktop.
    Pour moi, le seul avantage (niveau desktop) c'est en programmation et pour cibler différentes architectures et la kvm ne tiens plus la route (utilisation de VT).
    
    De plus pourquoi dans le contexte actuel de programmation, je veux dire par la l'utilisation accrue de Runtime (C#, Java), pourquoi ajouter encore une abstraction du matériel (cf dessous)?
    
    Programme -> Runtime -> OS -> Virtual. -> Architecture

    --
    C# (sans runtime) + GObject = Vala

    • [^]Re: Bon à savoir

      Posté par wismerhill (page perso, ) le 17/08/2007 à 12:51. (lien). Évalué à 10.

      Quelques exemple:
      
      - Faire tourner un windows pour un programme dont on a absolument besoin et sans équivalent (ou pour des jeux).
      - Tester un liveCD en cours de développement sans devoir redémarrer à chaque fois.
      - Tester une nouvelle distribution sans devoir en faire une installation complète sur sa machine.
      - Faire du développement kernel (dans une certaine mesure) sans risquer de tuer son système principal.

    • [^]Re: Bon à savoir

      Posté par Antoine Nivard (page perso, ) le 22/08/2007 à 09:18. (lien). Évalué à 2.

      Parce qu'il y a des personnes/boites qui codent comme des gorets en applications clients-serveurs. Donc il n'y a pas d'autres solutions que de mettre en place un affiche déporté.
      
      Je rappelle que dans toute société, l'activité qui prend plus de 50% des ressources est compta-paie-contrôle-RH (alors qu'ils représentent 10% des salariés). Ils ont des besoins spécifiques et critiques. Il n'y a pas de d'autres choix que de répondre positivement à leurs demandes....
      Et donc on se retrouve avec des logiciels spécifiques dédiés sur un ou 2 postes voir 20 postes donc la meilleur solution pour assurer un plan de reprise et une qualité de service est de gérer les serveurs et d'offrir un affichage déporté... il n'y a pas d'autre solution!

Virtualbox

• [^]Re: Virtualbox

  Posté par finss (page perso, ) le 17/08/2007 à 13:42. (lien). Évalué à 5.

  Je plussoie vigoureusement d'autant plus que VirtualBox est aussi sous licence GPL, s'installe et fonctionne simplement.

  --
  \_o< Coin ! Coin !

  • [^]Re: Virtualbox

    Posté par KiKouN (Jabber id, ) le 17/08/2007 à 13:49. (lien). Évalué à 4.

    Et permet de relancer facilement une machine virtuelle depuis Windows.
    
    Il est vrai que VirtualBox est très bien pour la virtualisation Desktop, mais ne joue pas dans la même cours que Xen.

    --
    KiKouN, Bucheron-Geek

• [^]Re: Virtualbox... issu de qemu

  Posté par Alain-Pierre Perrin () le 17/08/2007 à 14:40. (lien). Évalué à 6.

  Je me désole de ce que les efforts semblent se diluer. Xen a apporté sa pierre dans le domaine de la paravirtualisation... mais côté émulation de machines virtuelles complètes pour faire tourner l'OS sans modification, c'est la solution d'un qemu adapté qui a été retenue. Pour Virtualbox, ici encore on part sur une base de qemu qu'on peaufine et qu'on dote d'une belle interface graphique. Quant à KVM, qui, en soi, n'est qu'une extension du noyau, le seul émulateur s'appuyant dessus à ce jour c'est ? Un qemu patché... alors bien sûr le qemu "initial" profite petit à petit des évolutions de ses dérivés... mais trop lentement à mon goût. C'est sur lui qu'il faudrait travailler directement, plutôt que sur ses dérivés intégrés...

  • [^]Re: Virtualbox... issu de qemu

    Posté par geoffroy vallee () le 17/08/2007 à 18:09. (lien). Évalué à 2.

    Je suis tout a fait d'accord d'autant plus que meme en utilisant Xen avec le support hardware pour la virtualization (full-virtualization, i.e. ne pas avoir a modifier l'OS), on se retrouve... avec du code de QEMU.
    
    QEMU/Bosh sont toujours assez incontournables.

  • [^]Re: Virtualbox... issu de qemu

    Posté par Pinaraf (Jabber id, ) le 17/08/2007 à 19:32. (lien). Évalué à 8.

    Virtualbox issu de qemu... Un "peaufinage" ?? Woaw, ça c'est de l'information.
    Sources ?
    Si tu regardes les informations sur l'organisation du code source de Virtualbox ( http://virtualbox.org/wiki/Source_code_organization ), tu découvres que du code de Qemu est utilisé certes, mais à un seul endroit :
    src/recompiler/ contains a recompiler (emulator based on QEMU) for a few situations within VirtualBox. Essentially, all guest code runs natively on the hardware. The recompiler, however, steps in as a fallback when guest code disables interrupts and VirtualBox cannot determine when they will be switched back on; for single instruction execution on faults; for real-mode code (e.g. BIOS, DOS, operating system startup).
    
    En clair, qemu n'est pas du tout à la base de Virtualbox, c'est utilisé uniquement à un endroit bien précis. Tout le reste c'est fait par Virtualbox et ça n'a rien à voir avec Qemu.

    • [^]Re: Virtualbox... issu de qemu

      Posté par geoffroy vallee () le 17/08/2007 à 19:50. (lien). Évalué à 1.

      Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles, et je pense que c'est ce point qui est interessant.
      Et puis de ce que j'ai pu comprendre du code de VirtualBox (mais je n'ai regarde que rapidement) du code de QEMU est aussi utilise pour la virtualization des devices. Donc pour des choses assez critiques au final... tout comme pour le support de la "full-virtualization" avec Xen (ce qui a mon avis ne pose pas de probleme en soit : quand quelque chose est de qualite, autant le reutiliser).

      • [^]Re: Virtualbox... issu de qemu

        Posté par Pinaraf (Jabber id, ) le 17/08/2007 à 21:23. (lien). Évalué à 5.

        Correction importante : du code de Qemu et/ou bochs est réutilisé.
        Ça veut pas du tout dire la même chose.
        Virtualbox n'a pas grand chose à voir avec Qemu.
        Au passage, si tu fais un grep sur le code source de VirtualBox, c'est du copyright 2003 ou 2004. J'ai vu un fichier avec un copyright 2005. C'est du code de Qemu qui marche et qui n'a simplement pas besoin d'être modifié. Pourquoi réécrire le code qui marche quand il existe ?
        Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...

        • [^]Re: Virtualbox... issu de qemu

          Posté par galactikboulay () le 18/08/2007 à 07:15. (lien). Évalué à 2.

          
          Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...
          

          
          
          Tu as des exemples précis à ce sujet ? Excepté la partie "dyngen" qui est un gros hack de la mort (mais qui marche) je vois pas trop ce qu'on peut lui reprocher.

          • [^]Re: Virtualbox... issu de qemu

            Posté par Pinaraf (Jabber id, ) le 18/08/2007 à 11:30. (lien). Évalué à 0.

            Pourquoi devrais-je avoir des exemples ?
            Je n'ai pas regardé le code de Qemu, mais personnellement je ne contribue pas à un projet dont le code ne me plaît pas. Et un code me plaît ou non selon des critères qui me sont propres, chacun voit le code à sa façon.

            • [^]Re: Virtualbox... issu de qemu

              Posté par pasBill pasGates () le 19/08/2007 à 01:11. (lien). Évalué à 5.

              Je n'ai pas regardé le code de Qemu, mais personnellement je ne contribue pas à un projet dont le code ne me plaît pas. Et un code me plaît ou non selon des critères qui me sont propres, chacun voit le code à sa façon.
              
              Euh ouais, mais voir le code et le juger sans le voir, je sais pas, j'ai comme un probleme de comprehension...

              • [^]Re: Virtualbox... issu de qemu

                Posté par Pinaraf (Jabber id, ) le 19/08/2007 à 10:06. (lien). Évalué à 0.

                L'ai-je jugé ? Non.
                J'ai simplement donné des raisons pour lesquelles de nombreux projets pourraient être créés (et même sont créés) plutôt que de contribuer à qemu.

                • [^]Re: Virtualbox... issu de qemu

                  Posté par pasBill pasGates () le 19/08/2007 à 20:32. (lien). Évalué à 1.

                  Ben un peu quand meme, tu as dit que le code ne te plaisait pas, j'ai du mal a imaginer comment tu peux savoir qu'il ne te plait pas sans l'avoir vu.

                  • [^]Re: Virtualbox... issu de qemu

                    Posté par Pinaraf (Jabber id, ) le 19/08/2007 à 20:42. (lien). Évalué à 3.

                    Non, je n'ai pas dit qu'il ne me plaisait pas.
                    J'ai dit :
                    Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...
                    
                    On le refait en version bien diluée pour aider à la compréhension :
                    Et pour quelles raisons une personne pourrait décider de ne pas contribuer à Qemu ? Parce que le code de Qemu peut ne pas plaire à cette personne, parce que la structure de Qemu peut ne pas plaire à cette personne, parce que certains choix techniques effectués dans Qemu peuvent être à l'origine de désaccords avec d'éventuels contributeurs...

        • [^]Re: Virtualbox... issu de qemu

          Posté par geoffroy vallee () le 18/08/2007 à 13:22. (lien). Évalué à 3.

          Desole mais la tu modifies mes propos.
          
          Premierement, personnellement, je n'ai JAMAIS dis que VirtualBox etait une "simple modification" de QEMU, donc pas la peine de chercher la petite bete comma ca.
          Et puis relis bien ce que j'ai ecris : "de ce que j'ai pu comprendre __du__ code de VirtualBox (mais je n'ai regarde que rapidement), __du__ code de QEMU est aussi utilise pour la virtualization des devices" (dans ma phrase originelle il manque une virgule apres la paranthese).
          En quoi ta correction "si importante" change le sens de ce que j'ai dis? La il faut m'expliquer!
          
          Ensuite comme je l'ai dis, le code pour la virtualisation des drivers est profondement fonde sur le code de QEMU (j'ai lu le code, c'est bien mieux qu'un grep), et la virtualisation des drivers est tout de meme l'un des composants central d'une solution de virtualisation. Tu refutes ce point egalement?
          
          Je ne comprends pas non plus pourquoi tu sembles refuser absolument l'idee que VirtualBox a pu reutiliser du code de QEMU. Est-ce si important que ca? Je comprends que tu n'aimes pas QEMU (de mon cote, je n'aime pas trop KVM), mais de la a faire de la joute oratoire en deformant mes propos, je trouve que c'est un peu pousse.
          
          Pour finir, exemple pris au hasard (et ce n'est qu'un exemple) : VirtualBox-OSE-1.4.0/src/VBox/Devices/Graphics/DevVGA.cpp
          
          * This code is based on:
          *
          * QEMU VGA Emulator.
          *
          * Copyright (c) 2003 Fabrice Bellard

          • [^]Re: Virtualbox... issu de qemu

            Posté par Pinaraf (Jabber id, ) le 18/08/2007 à 13:30. (lien). Évalué à 2.

            Désolé, j'avais pas fait gaffe aux noms. C'est surtout après l'auteur de ce commentaire que j'en avais : http://linuxfr.org/comments/859230.html#859230
            (La précision concernait cette phrase : Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles)
            Dire que le code de VirtualBox pour les pilotes est profondément fondé sur le code de Qemu me semble exagéré, VirtualBox a ajouté des fonctionnalités (dans le cas du pilote graphique, y'a la possibilité de configurer la VRAM disponible, et j'ai vu dans leur bugtracker un travail effectué sur le support de la 3D, dispo uniquement avec un patch un peu "bâtard" pour Qemu (patch non intégrable dans Qemu donc))
            
            Au passage, où as-tu vu que je n'aime pas Qemu ? Je l'utilise régulièrement, probablement plus que VirtualBox (qui refusait de marcher jusqu'à peu sur mon ordinateur portable, comme VMWare ou Xen. Qemu était le seul à marcher)

            • [^]Re: Virtualbox... issu de qemu

              Posté par geoffroy vallee () le 18/08/2007 à 14:07. (lien). Évalué à 1.

              Si il y a eu confusion de personne, tout s'explique. :-)
              
              Pour ma phrase "Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles", cela reste vrai a mon avis. Par contre, je ne voulais absolument pas dire que toutes les solutions de virtualisation sont simplement une modification de QEMU. J'aurais du etre plus clair...
              Je voulais seulement dire que la majorite les solutions de virtualisation reutilise du code de QEMU pour tout ce qui est virtualisation de devices, BIOS, etc... C'est d'ailleurs pour cela que j'ai dis QEMU/Bosh car si je me souviens bien du code que j'ai pu lire, pour l'emulation du BIOS, le code vient souvent de Bosh plutot que de QEMU. Je suis sur que quelqu'un avec des connaissances plus fraiches et pointues sur le sujet peut donner plus de details sur ce point.
              
              Sinon j'ai suppose que tu n'aimes pas trop QEMU a cause de cette phrase : "Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords..."
              Mais c'est vrai que tu dis uniquement que tu n'aimes pas le code. Pas que tu n'aimes pas QEMU.
              Personnellement je prefere Xen car c'est une solution de virtualisation de type-I [1] suivant la classification de Goldberg, i.e, l'hyperviseur s'execute directement sur le hardware, en opposition avec les solutions de type-II (QEMU, KVM) ou l'hyperviseur s'execute sur l'hote. Je trouve ca plus elegant et efficace.
              
              [1] http://en.wikipedia.org/wiki/Hypervisor

              • [^]Re: Virtualbox... issu de qemu

                Posté par Pinaraf (Jabber id, ) le 18/08/2007 à 14:27. (lien). Évalué à 3.

                Sinon j'ai suppose que tu n'aimes pas trop QEMU a cause de cette phrase : "Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords..."
                Attention, je crois, vu la note de mon commentaire, que cette phrase a porté à confusion : je voulais dire par là que la contribution à un projet libre est conditionnée à un point de vue personnel, et qu'on peut souvent réinventer la roue juste par désaccord avec le projet originel.
                J'ai pas assez regardé le code de Qemu pour porter un jugement à ce sujet.
                
                Sinon, pour le BIOS, il me semble que le BIOS utilisé par Qemu et Bochs est un BIOS libre, codé spécifiquement pour les émulateurs. Pareil pour le BIOS VGA... Par contre, comme ces BIOS sont liés à une certaine organisation derrière, de nombreuses similitudes seront obligatoires entre les projets les utilisant pour la carte graphique par exemple.

• [^]Re: Virtualbox

  Posté par Antoine Nivard (page perso, ) le 22/08/2007 à 09:25. (lien). Évalué à 1.

  Je comprends bien que cela est bizarre que je ne parle pas de virtualbox.
  
  Quand je parle de virtualisation, je pense à OS serveurs et non à OS desktop. Pour ma part, XEN et VMWARE inclut des fonctionnalités de contrôles et de supervision qui n'existent pas dans VirtualBox.
  
  
  Concernant la virtualisation des OS Desktop, VirtualBox convient très bien, il n'y a aucun soucis. Tout comme la virtualisation de quelques OS serveurs, VirtualBox fait l'affaire mais sur un périmètre limité.

Xen VS VMWare ?

• [^]Re: Xen VS VMWare ?

  Posté par dark_moule () le 17/08/2007 à 18:01. (lien). Évalué à 1.

  Si j'ai bien compris tes propos, Xen permet de faire ce que tu veux. Pour cela il faut déclarer un maître du pool et y ajouter des esclaves.
  
  C'est un moyen facile et rapide de faire de la répartition de charges.

  • [^]Re: Xen VS VMWare ?

    Posté par nodens (page perso, ) le 18/08/2007 à 00:10. (lien). Évalué à 3.

    Si j'ai bien compris à mon tour, tu parles de XenEnterprise et pas de Xen tout court :)
    
    Autrement dit, la version propriétaire.
    
    Rien ne s'oppose vraiment à faire le même genre de chose avec la version GPL, vu que les fonctionnalités sont là : possibilité de faire de la migration de domaines en live à condition d'avoir un stockage partagé (et je crois que la migration live ne concerne pas encore les domU HVM, c'est à dire utilisant une virtualisation complète s'appuyant sur les extensions VT ou assimilé des processeurs récents), API permettant de controler les domU à distance... on a donc tout l'infrastructure nécessaire.
    
    Après il n'y a plus qu'à déclencher les migrations en fonction des ressources disponibles et donc à avoir une idée de où est ton domU à un instant t... une sorte de scheduler de domU sur plusieurs serveurs physique en somme.... Tiens, c'est marrant, maintenant je comprend pourquoi ils arrivent à le vendre cher (et à augmenter les prix de 300% à 750% d'une version à une autre...) ;)
    
    Bon si on veut simplement faire de la redondance et une répartition de charge "manuelle" il y a déjà tout ce qu'il faut, et il doit même y avoir des softs qui te font de jolies interfaces pour gérer tout ça comme XenMan.
    
    
    PS: si quelqu'un arrive à faire ce genre de chose avec la version libre, ou si il y a des docs quelque part, autre que des slides succints que j'ai déjà vu, alors je suis *très* intéressé, même que je dois pas être le seul ;)

    --
    Clément Hermann (nodens)
    - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
    Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
    GPG : pgp.mit.edu - 0xEBD1399D

    • [^]Re: Xen VS VMWare ?

      Posté par brazz () le 18/08/2007 à 09:47. (lien). Évalué à 3.

      En fait on a une "triplette" si l'on peut dire: Xen GPL pour le multi (particulièrement en s'appuyant sur les nouveaux processeurs dont l'architecture a d'ailleurs été conçue pour) + FreeNX pour un accès à distance transparent de 1 m à 50 000 km! + les solutions de clusterisation, tolérance aux pannes etc... En fait ce qui est un peu ralant c'est que le libre a tout ce qu'il faut pour mettre en place the big projet qui tue mais en ce moment il a tendance à se faire allègrement piller voire dépouiller.
      Pour VMWare (ESX) et tant pis si la société a réussi son introduction en bourse (d'ailleurs sur la rationalité de la bourse il y aurait à dire, on le voit en ce moment...) mais il faut voir qu'il y a depuis des années des fortes présomptions de piratage de la GPL (voir par exemple http://www.venturecake.com/the-vmware-house-of-cards/ ).
      Il y aura peut être des surprises.

    • [^]Re: Xen VS VMWare ?

      Posté par dark_moule () le 18/08/2007 à 11:35. (lien). Évalué à 2.

      Regarde du côté de :
      - http://www.enomalism.com/ et http://www.openqrm.org/
      
      selon ce que tu veux faire.
      
      Tu peux également essayer le livecd mis à disposition pour tester openqrm :
      http://freshmeat.net/projects/openqrm-live-cd/?branch_id=685(...)
      Quelques plugins ont déjà été intégrés.
      Il est très complet, trop certainement pour ce que tu veux réellement faire mais ça te donnera une idée des possibilités.
      
      Pour Xen je n'ai pas trouvé le livecd que j'ai utilisé pour faire mes tests mais je viens de voir ce projet : http://unit.aist.go.jp/itri/knoppix/xen/index-en.html
      
      Leur site est très brouillon, j'espère que leur LiveCD sera bien mieux...

      • [^]Re: Xen VS VMWare ?

        Posté par nodens (page perso, ) le 18/08/2007 à 17:18. (lien). Évalué à 2.

        D'après ce que j'avais pu voir, la version libre d'Enomalism ne permet pas de faire ce que je veux (ça implique de pouvoir gérer les migrations live, et on dirait bien que seule la version propriétaire propose ça).
        
        J'étais déjà tombé sur openQRM mais je ne sais pas pourquoi, j'avais eu l'impression que la version libre était assez limitée... en relisant les doc j'ai l'impression que je m'étais trompé, à creuser, donc.
        
        Après, quand c'est juste pour gérer des domU pour faire des machines de test ou gérer un seul serveur, xen-tool sous debian et les commandes xm restent mes outils de prédilection ;)

        --
        Clément Hermann (nodens)
        - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
        Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
        GPG : pgp.mit.edu - 0xEBD1399D

• [^]Re: Xen VS VMWare ?

  Posté par vincentxs () le 19/08/2007 à 10:25. (lien). Évalué à 2.

  XenEntreprise v4 (le dernier produit commercial de xensource) supporte le concept de pool avec un master et des slaves, mais il n'y a pas de support equivalent en opensource.
  
  Le concept de pool est avant tout de l'administration de machine du clusters et de migration de VM; Xen (l'hypervisor) n'a aucune idee des pools.
  
  Disclaimer: je travaille pour XenSource.

Grande question....

hyperviseur

• [^]Re: hyperviseur

  Posté par rsystem () le 19/08/2007 à 11:05. (lien). Évalué à 1.

  en même temps RedHat , Suse et Mandrake ont intégrés Xen (la version opensource) dans leur distribution "pro" .
  je vois mal comment la techno disparaitrait.
  je ne sais plus ou j'ai lu que XenSource allait se focaliser sur la techno de Microsoft (CodeName Viridian) et
  fournir uniquement des "3rd party tools".
  le code source de Xen dans ces dernieres version est en GPL.
  donc selon les choix fait a l'avenir par Citrix/XenSource , à mon vis un fork apparaitra.
  
  en tous cas une chose est sure, XenSource s'éloigne petit à petit du monde linux, XenCenter4 écrit en dotnet, accords de partenariat large avec microsoft, mise en place d'équipes de développement dédiées à Viridian .....
  
  Wait and see :-)

  • [^]Re: hyperviseur

    Posté par Yves-Gaël Chény (page perso, ) le 19/08/2007 à 11:17. (lien). Évalué à 1.

    Concernant les drivers pour améliorer les I/O sous windows n'oublions pas que novell développe les siens en internes mais je doute qu'ils soient GPL ou opensourcés
    
    J'ai également entendu parler d'un noyau Windows paravirtualisable qui serait fourni/vendu par microsoft dans un avenir proche.
    
    Mais ce ne sont que des bruits, quelqu'un peut confirmer ?
    
    

    --
    Happy Hacking !

Après Xen c'est au tour de ClamAV !!

• [^]Re: Après Xen c'est au tour de ClamAV !!

  Posté par Antoine Nivard (page perso, ) le 22/08/2007 à 09:06. (lien). Évalué à 3.

  Oui, il y a beaucoup de changement cet été 2007. Il faut voir cela comme que le fait que les projets OpenSource soient de véritables innovations sur un marché en pleine croissance.
  
  Si tu montes un projet OpenSource et que dans 2 ans on te propose 5 millions ¤ pour te racheter le nom et ton code tu fais quoi?
  
  C'est l'offre et la demande. Il faut arrêter avec des pseudo peurs, il n'y a pas de problème d'éthique et de conscience vu que tout est GPL et que celui qui rachète doit rassurer 1/ les développeurs 2/ les futurs acheteurs
  
  Si il y a un soucis, un fork sera crée et le marché choisira... la nature est bien faite!