Citrix Systems Inc. achète la société XenSource Inc.

Posté par . Modéré par Jaimé Ragnagna.
Tags : aucun
1
17
août
2007
Technologie
XenSource est l'éditeur de Xen, l'hyperviseur libre de machines virtuelles. Un accord de rachat de XenSource par Citrix a été signé par les deux parties il y a quelques jours. Cet accord est une réelle opportunité pour Citrix qui recherche des relais de croissances et des nouvelles technologies à mettre dans son portefeuille de solutions.

Citrix a les moyens techniques et financiers pour permettre à XenSource de percer dans le monde de l'entreprise d'une manière rapide et professionnelle. Le code source de Xen est en GPL donc pour l'instant rien ne change. Cependant la communauté restera vigilante pour que Citrix joue le jeu et n'abuse pas de la situation. Citrix a tout à y gagner de faire participer la communauté.

Citrix permettra à Xen d'être un challenger de poids face à VMware. La nouvelle situation a forcé VMware à communiquer auprès de ses clients. À ce jour, la solution VMware ESX VI3 est une des solutions les plus abouties du marché en terme d'administration et de fonctionnalités. VMware recherche de nouveaux moyens financiers pour gagner de l'avance par rapport à ces concurrents.
(NdM : A ce propos, VMware vient de réussir son introduction en bourse.)

Nous allons avoir deux belles solutions sur le marché dont une est OpenSource... à vous de choisir.

NdM : Xen est documenté sur XenFR.org et de nombreuses solutions de virtualisation existent en libre : QEMU, KVM, OpenVZ. De même, il existe des systèmes de bureaux à distance libre X Window System, VNC. Citrix Systems, Inc. est le leader mondial dans le domaine des infrastructures de mise à disposition des applications.
XenSource Inc. a été créé début 2005. XenSource fourni des solutions pré-packagés autour de Xen mais également le support et la maintenance autour des solutions XenSource.
  • # Affiche déporté

    Posté par . Évalué à 8.

    Par rapport aux notes des modérateurs, concernant l'affichage déporté comme CITRIX, il existe les solutions:
    - NOmachine http://www.nomachine.com/
    et
    - Sun Secure Global Desktop Software http://www.sun.com/software/products/sgd/ plus d'info sur
    http://en.wikipedia.org/wiki/Sun_Secure_Global_Desktop (ancienne techno de SCO appelée tarantella)

    voila pour l'instant
    • [^] # Re: Affiche déporté

      Posté par . É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.
  • # Bon à savoir

    Posté par (page perso) . Évalué à 6.

    http://udrepper.livejournal.com/17577.html

    KVM finira par faire sa place.
    Je l'utilise déjà tous les jours sans le moindre soucis jusqu'ici.
    C'est simple et efficace. Ca manque juste un peu d'outillage.

    http://kvm.qumranet.com/kvmwiki
    • [^] # Re: Bon à savoir

      Posté par . É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 (page perso) . É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
        • [^] # Re: Bon à savoir

          Posté par . É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 . É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

    Posté par (page perso) . Évalué à 10.

    NdM : Xen est documenté sur XenFR.org et de nombreuses solutions de virtualisation existent en libre : QEMU, KVM, OpenVZ. De même, il existe des systèmes de bureaux à distance libre X Window System, VNC.

    et n'oublions pas le très très bon virtualbox!

    http://www.virtualbox.org/
    • [^] # Re: Virtualbox

      Posté par (page perso) . Évalué à 5.

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

      \_o<

      • [^] # Re: Virtualbox

        Posté par . É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.
    • [^] # Re: Virtualbox... issu de qemu

      Posté par . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 ?

    Posté par . Évalué à 2.

    Ca commence à beaucoup bouger coté virtualisation, et au boulot on essaie souvent de nous vendre telle ou telle solution.

    Du coup, vu que c'est le sujet du jour, j'ai une p'tite question.

    VMWare, à ce que j'ai compris, permet avec leur solution d'utiliser un pool de serveur physique en tant que "ressources" pour un ou des serveurs virtuels.
    C'est notamment ce qu'ils font avec les "lames" d'IBM. Je ne suis pas au courant de tous les détails, mais il me semble avoir compris qu'on pouvait faire la même chose avec une batterie de serveurs reliés en Ethernet.

    Est-ce que Xen ( ou une quelconque solution OpenSource ) propose ce type de solution ?
    • [^] # Re: Xen VS VMWare ?

      Posté par . É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 . É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 ;)
        • [^] # Re: Xen VS VMWare ?

          Posté par . É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 . É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 . É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 ;)
    • [^] # Re: Xen VS VMWare ?

      Posté par . É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....

    Posté par . Évalué à 5.

    est-ce positif?

    Xen va t'il continuer sur sa trajectoire? Quels sont les plans de Citrix à son sujet? Les prochaines versions seront-elles libres? Le personnel de XenSource pourra t'il continuer à bosser sur Xen ou sera t'il réalloué à des tâche plus en rapport avec l'activité actuelle de Citrix? Comment cela s'intègre t'il dans la stratégie de Citrix?
  • # hyperviseur

    Posté par (page perso) . Évalué à 2.

    Si citrix ne publie pas le code de l'hyperviseur nous aurons perdu une belle techno, la meilleure actuellement à mon avis et la + souple existante.

    Espérons qu'un fork sera créé à ce moment.

    Nantes_geek

    ---------------------------------------
    www.antredugeek.fr/wiki
    irc: irc.freenode.net #xenfr
    • [^] # Re: hyperviseur

      Posté par . É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 (page perso) . É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 ?

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

    Posté par . Évalué à 1.

    Cela fait beaucoup d'assez gros projets libres qui sont rachetés en ce moment car l'antivirus libre ClamAV vient également de faire une annonce, voir:
    http://www.clamav.net/2007/08/17/sourcefire-acquires-clamav/
    Et oui donc c'est SourceFire qui achète le projet ClamAV, en espérant qui joue le jeux du libre...
    • [^] # Re: Après Xen c'est au tour de ClamAV !!

      Posté par . É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!

Suivre le flux des commentaires

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