> son marché de niche ce sont des applis non optimisées HPC sur des tout petits clusters)
Je ne suis pas du tout d'accord : le HPC est la niche (quelque billion par an et une part de marche qui ne croit pas vraiment), pas l'inverse.
> des clusters HPC existants tournent sur du linux
Le HPC est tres loin de se limiter aux clusters Linux. Par exemple environ la moitie des 10 machines le plus puissantes du top500 n'executent pas Linux sur les noeuds de calcul (BlueGene -> CNK, Cray -> Catamount). C'est a mon avis une erreur de limiter le HPC aux clusters Linux, pour cela que ldans mes posts precedents j'ai pris la peine de citer ces plate-formes. Je pense d'ailleur que c'est _le_ point qui fait que l'on se soit pas totalement d'accord car ton analyse est tres pertinente et en dehors de ce point, je suis globalement d'accord avec toi.
> des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
Quand tu n'as pas de Linux, ca ne marche plus. Et il est clair que ces cas la m'interessent. Et meme si les BlueGene et les Cray vont bientot offrir du Linux sur les noeuds de calcul, vu que c'est une version de Linux "epuree", toutes ces solutions ne fonctionneront clairement pas.
> Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware
Heu la non, pas tout a fait. Personnellement je ne peux pas justifier n'importe quoi sans prouver que la degradation en terme de perf n'est pas trop importante. Et dans ce contexte, clairement la nature de l'hyperviseur est important. Avec un type-I, on peut faire un domaine hote petit (dans les solutions actuelles ce n'est pas le cas par defaut) et un hyperviseur avec un comportement predictible (pas le cas de Xen dans certains cas) pour l'execution d'applications paralleles. Je ne pense vraiment pas que tu puisse faire la meme chose avec une solution de type-II (et en fait pas non plus avec les solutions de type-II actuellement dispo!).
Dans mon cas, je ne peux justifier qu'au maximum 10% de penalite avec un vrai apport en terme de fonctionnalites. Si tu passes d'un micro-noyau a Linux + virtualisation, c'est quasiment impossible (deja le passage a Linux meme apres optimisation donne une penalite d'environ 25% dans les all-to-all avec des applications MPI lorsque l'on compare a un micro-noyau).
Et je tiens a souligner que les hyperviseurs actuels (e.g., Xen) ne sont pas des micro-noyaux (tu ne l'as pas dis mais c'est quelque chose que je vois souvent et qui est faux). A ma connaissance aucune solution actuelle est fondee sur un micro noyau (certains disent que ESX l'est mais dur de verifier). Par exemple, L4, catamount et CMK sont des micro-noyau; Xen n'en est pas un.
> Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0.
Pour le HPC sur une machine type Cray, non, impossible actuellement. Sur un cluster deja Linux je suis d'accord avec toi. Mais a nouveau ca sort du HPC strict, ca devient "HPC avec cluster Linux", ce qui je te l'accorde concerne beaucoup de gens, mais pas tout le monde. :-) Et puis meme avec Linux je demande a voir. Mes premiers tests avec KVM n'ont pas montres d'interets reels.
Je suis egalement d'accord a 200% avec ton avis sur L4 et ESX.
> Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
Egalement d'accord a 200% avec toi (ce que meme des gens faisant de l'OS oublient parfoit) mais je pousse l'analyse un poil plus loin : Linux est bien trop complexe (desole mais l'architecture de systeme de fichier, je la trouve vraiment trop complexe :-). Pour cela que je prefere "naturellement" les solutions de type-I : ca t'ouvre les portes pour mettre ce que tu veux dans les VMs mais aussi dans le domaine hote; les differents "composants" de la solution de virtualisation sont bien separes; avec une solution de type-II c'est bien plus complexe (imbrications et dependences).
> La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
Dans l'absolu je suis bien d'accord. As-tu jeter un coup d'oeil aux projets finances par la NSF autour de la virtualisation? Il y a des idees interessantes (meme si a mon avis il manque des choses parfois). L'un des projets est le suivant, impossible de remettre le main sur le deuxieme (qui est pourtant plus interessant a mon sens car fonde sur l'idee d'un framework pour le developpement de nouvelles solutions de virtualisation) : http://www.nsf.gov/news/news_summ.jsp?cntn_id=110606&org(...)
> La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux
Justement, pourquoi ne pas reprendre des microkernels existant pour mettre en oeuvre une nouvelle solution (un peu l'idee de L4) ? Bien sur ca sera tres specialise pour une plate-forme donnee (toujours le probleme des drivers) mais je pense que cette approche serait bien plus interessante.
> Cela dit, pour déterminer où ça coince, on a également besoin d'instrumentation, de familiarité avec la plateforme. Et pour cela, encore une fois, plus c'est simple mieux c'est. Encore une fois je pense que c'est un aspect sur lequel Linux+KVM est plus intéressant que Xen. Rien qu'un exemple : on peut facilement tester sans KVM en gardant le reste de l'environnement à l'identique : il suffit de lancer l'émulation avec l'option -no-kvm.
Je recupere des resultats de profiling tous les jours en ce moment en utilisant Xen et oprofile, ca marche plutot bien. Par contre, c'est sur que si tu veux debugger ta VM seule, une solution de type-II est bien meilleure (ce que j'ai deja dis auparavant).
A noter que la simplicite dont tu parles est perdue des que tu veux faire ca au sein d'un cluster de taille assez importante (d'un autre cote, une solution open-source qui apporte un bout de solution pour ca devrait bientot etre mise a disposition, permettant aux utilisateurs de passer tres simplement de VMs sur un cluster a un cluster "normal").
> D'autre part, l'instrumentation du "kernel" Xen est à ma connaissance encore très limitée, et de toutes façon il faut encore pouvoir effectuer les diagnostics en tenant compte de ce qui se passe dans Xen mais aussi dans le Dom0. Les niveaux d'encapsulation font que ça revient au même que le débuggage d'une servlet sur un serveur d'application java, et crois moi, je connais beaucoup de sysadmin qui en frémissent (même si sur ce front là il y a eu des progrès).
Non ca se fait tres bien, comme je l'ai dis, je vois des traces au quotidien et avec des scripts simples, on peut recuperer toutes les informations necessaires. Et pas besoin de modifier quoique ce soit, meme avec au sein d'un cluster.
> D'autre part, pour revenir à la problématique de l'hôte, quelque soit son type, oui, à niveau de maturité de code égal et d'effort de développement égal, plus c'est petit et simple (en nombre de LoC) mieux c'est.
Bien d'accord et encore une fois, si tu as du tout Linux, KVM ou lguest sont tres interessants (j'aime bien les idees de simplicite derriere lguest). Je ne tente pas de prouver le contraire.
> Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
Non je ne suis pas tout a fait d'accord, il est possible d'avoir un hyperviseur petit et modulaire (donc pas Xen), un hostOS petit (donc pas Linux avec les configurations associees aux solutions de virtualisation actuelles), et des VMs avec ce que l'on veut dedans. Avec Linux+KVM, tu t'eloignes tout de suite de ca (overhead de Linux par rapport a des micro-noyaus specialises).
Mais bon, je pense aussi que de toute facon, avec les solutions actuelles, des que tu passes a une plate-forme distribuee (e.g., cluster), tu te prends la tete et pas qu'un peu.
Pour conclure ton analyse est vraiment pertinente, merci pour ca (ca faisait longtemps que je n'avais pas eu une discussion interessante sur LinuxFr!). Le seul bemol que je me permets est que dans mon cas je ne me limite pas a du tout Linux. :-) Ce qui bien sur n'interessera que peu de personnes ici.
L'article de Anthoney Liguori touche un point interessant : "The most common definition of "type-1" and "type-2" seem to be that "type-1" hypervisors do not require a host Operating System", ce qui est totalement faux bien sur. Quand je parle de type-I vs. type-II et comme je le dis auparavant, je parle de la definition donnee par Goldberg avec le modele qui y est associe. Cette definition est tres claire, ne colle pas avec ce qui se dit un peu partout mais comme souvent les gens deforment une definition claire pour ensuite dire qu'elle n'a pas de sens.
D'ailleur il le dit bien : "Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine." Forcement c'est dans l'autre papier! Il cite le papier de Popek et Goldberg, pas celui de Goldberg seul (celui de sa these). C'est le papier de Goldberg qui presente la classification de maniere precise. Mais c'est une erreur commune que l'on retrouve meme dans les publications scientifiques sur le sujet.
Il dit ensuite " like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware" et c'est bien ce qui est important : le module _doit_ avoir un systeme hote pour fonctionner, initialiser la memoire et compagnie. Pour une solution de type-I, le VMM boot en premier. Du coup, si tu n'as pas besoin de drivers particulier, tu n'as pas besoin du systeme hote. C'est pourquoi lorsque tu regardes le cycle de vie d'une VM, il n'y a absolument pas besoin d'acceder au domaine hote au moins dans les premiers instants de vie de la VM. Quel interet si on ne peut utiliser de drivers? et bien tu es libre d'utiliser ce que tu veux comme domaine hote plus tard, et non pas seulement Linux (pourquoi pas un OS specialise parfaitement adapte a ta plate-forme, e.g., CNK des BlueGene). C'est completement impossible avec une solution de type-II. Bon d'accord on parle ici de recherche mais comme je l'ai dis des le debut, c'est le contexte qui m'interesse.
A noter aussi qu'il met Xen dans les micro-kernel, ce qui est faux! Ca n'est pas parce que Xen est petit (quoique sur ca aussi il y a discuter), qu'il est un micro-kernel. Un micro-kernel, c'est par exemple L4 et Xen est tres loin d'une architecture de micro-kernel (Xen a un design tres monolithique).
Donc au final, je ne suis pas d'accord avec l'analyse de Anthony Liguori qui a mon avis melange beaucoup de chose dans cet article et oublie les definitions exactes et initiales.
Pour ce qui est Wikipedia, desole je ne fie absoluement pas a Wikipedia pour ce genre de chose : des que l'on aborde des sujets pointus, bien souvent les articles sont de la vulgarisation et non pas un article de reference.
Pour ce qui est de savoir qui est le plus performant, a mon avis la question a peu de sens, il faut preciser avec quelle application et surtout quelle plateforme materielle. Et c'est bien ca que je tente de souligner : dire que les solutions de type-II sont generalement meilleures a peu de sens, comme dire que les solutions de type_i sont meilleures. Pour le HPC, les solutions de type-I _semblent_ meilleures, notamment vu les resultats de differentes equipes de recherche. A noter egalement que le HVM a priori n'ameliore pas les performances (surtout dans le cas d'une solution de Type-I initialement implementee par de la para-virtualisation). Ca simplifie les choses et ouvre des portes, c'est tout.
Ensuite et pour finir, je ne veux pas prouver que ce qui a ete dit est faux, je souhaite juste souligner que la question de la virtualisation n'est pas simple et que les conclusions demandent totalement du contexte. Je tente juste d'expliquer mon point du vue dans le contexte qui m'interesse (recherche en OS pour resumer).
PS : ce fut en tout cas une discussion agreable qui m'a permi de lire des articles/blogs que je n'avais pas lu. Toujours interessant de voir des avis differents lorsque c'est argumente, ce qui devient un peu trop rare a mon gout sur ce site. :-)
> A priori je pense pas que que le SSI soit adapté à de grosse échelles. Disons un petit cluster classique entre 128 et 512 cores avec dans les 1Go de RAM/Core.
Tout d'abord, ca ce n'est pas une grande echelle actuellement. :-) Plus serieusement je pense que ca devrait le faire si l'on a une application qui le permet. Car soyons serieux : connais-tu une application "classique" actuelle qui peut utiliser tant de core a elle toute seule ? Moi non.
L'avantage du SSI dans ce cas est comme pour le SMP : il est simple de voir ce qui se passe, il est simple de lancer des applications, il n'est pas trop dur d'ecrire une application parallele (memoire partagee tout ca tout ca) et si tu executes des applications en meme temps, les resources sont globalement utilisees de maniere transparentes.
A mon avis, tu ne peux pas ca aussi simplement avec les outils standards pour les systemes distribues (par exemple mais a mon avis, un systeme batch est loin d'etre naturel a utiliser).
Donc SVP, si tu as des elements pour dire que ca ne passe pas a cette echelle, peux-tu donner plus de details? Car vu les derniers tests que j'ai pu voir, ca me semble franchement faisable dans le cas d'utilisation que je decris plus haut.
> Une application classique serait éffectivement une application avec CPU intensif et memoire partagée. Si il n'y a que du CPU et des workers stateless, type demon httpd/dns, alors on peut en general faire du loadbalancing sur les processus. Si il n'y a que des gros besoin mémoire alors des solutions types jumbomem fonctionnent aussi. Et enfin quand on veut réellement se soucier d'écrire une application distribuée alors on utilise un middleware adéquat.
Heu mais la tu justifies le SSI!
- loadbalancing: transparent a l'utilisateur, il n'a rien a faire pour cela, le SSI place et deplace les processus entre les processeurs. Pas besoin de systeme de batch ni d'autres outils qui au final ne font qu'etendre de maniere artificielle ce que les systemes de type Unix font tres bien au sein d'un systeme unique.
- gros besoin en memoire : avec la DSM c'est possible et transparent encore une fois. La difference entre jumbomem et une DSM est vraiment minime pour ce que je sais, non?
- utiliser un middleware adequat : oui et alors? le SSI n'empeche pas ca. C'est meme une bonne idee pour avoir des performances.
Ensuite l'avantages du SSI c'est que tu as le choix : tu veux utiliser MPI pour avoir les perfs de la mort qui tue, pas de pbs; tu veux utiliser pthread qui faire un truc vite fait qui tourne sur quelques noeuds, pas de probleme; ...etc. Et bien sur que le SSI je repond pas a TOUS les besoins (aucune solution ne le fait de toute facon).
Bref, le SSI offre plein de possibilites. Pour certaines personnes, ca ne sera pas interessant, pour d'autres ca le sera. Par exemple, le SSI va tres bien avec le concept de "cluster sur ton bureau", i.e., une petite machines assez dense pour tenir sur ton bureau avec plusieurs processeurs/cores a l'interieur. Pour democratiser ce genre de machine, tu dois cacher la distribution des resoruces, le SSI est parfait pour ca.
> Je pense que votre cluster est justement fait pour jouer, donc ce qui sera intéressant ce sont les retours d'éxpérience.
Justement je t'ai deja dis dans le message precedent qu'avec des applications scientifiques "qui vont bien" (OpenMP dans mon cas), ca se passait plutot bien. L'idee dans ce cas est de remplacer les SMP vieillissant qui etaient utilises pour l'execution de ces applis par quelques noeuds (beaucoup moins chers) faisant tourner un SSI.
> Alors je comprends bien que la comparaison type1/type2 est très à la mode (surtout dans les équipes marketing), mais elle devient obsolète, un peu comme la différence RISC/CISC il y a quelques années. Les solutions actuelles sont devenues hybrides.
Au moins pour ce qui se passe actuellement au niveau recherche, je pense le contraire : la difference entre type-I et type-II a toujours beaucoup de sens et doit etre preservee car les deux approches ne repondent pas aux meme besoins. Pour justifier le type-I, il est par exemple possible d'analyser les besoins associes a l'execution des applications scientifiques et le HPC. Dans ce cas, dire que la distinction type-I et type-II est avant tout marketing est totalement deplace (je donne quelques points plus bas pour illustrer cela).
De plus tu dis que les solutions actuelles sont hybrides, je crois que c'est vraiment faux. Uniquement _quelques_ solutions sont hybrides, ou alors peux-tu me citer ces solutions SVP, car j'ai besoin d'etre eduque sur le sujet si c'est le cas.
> il n'y a pas les A/R entre l'hyperviseur et le Dom0 pour les accès au hardware. Sans compter que des fonctionnalités telles que l'overcommit de mémoire (déjà présentes dans KVM) seront difficiles à intégrer dans Xen afaik.
Pour eviter les A/R entre l'hyperviseur et le Dom0, on sait deja que la notion de "sidecore" est une solution efficace : tu places l'hyperviseur sur un core et tu executes les VMs et le domaine hote sur d'autres cores. C'est simple et tu gagnes beaucoup en performance. Tu peux te reporter aux travaux fait a GATech pour plus de details (entre autre). Ensuite pour l'overcommit de la memoire, tout d'abord je ne vois pas pourquoi tu veux faire ca (au moins dans le cadre des applications scientifiques/HPC) et ensuite la manipulation de la memoire avec une solution de type-I est tres proche du cout de la gestion memoire dans un systeme normal. J'ai fais des tests avec Xen, le cout est entre 0 et 2 %. Le probleme se situe principalement au niveau des entrees/sorties et la, le type-II n'apporte pas forcement quelque chose de plus. A chaque fois, quelque soit la techno selectionnee, il faut acceder au materiel de maniere directe depuis les VMs, avec le partage entre les VMs.
D'un autre cote, si tu vises le HPC, tu tombes sur les problemes suivant : avec une solution de virtualisation, type KVM, le domaine hote doit absoluement etre un Linux. Or si tu prends les plate-forme HPC actuelles type BlueGene ou Cray, c'est rarement le cas. Tu vas me dire que dans ce cas, la solution de type-I ne fonctionne pas plus car le domaine hote doit etre un Linux. C'est vrai mais cela devrait changer dans un avenir proche si tout va bien (plusieurs projets de recherche sur le sujet). :-) L'autre point interessant est de savoir pourquoi l'hyperviseur devrait etre un module du noyau Linux pour faire des choses simples, i.e., seulement manipuler de la memoire. L'inclusion dans le noyau impose de suivre les evolutions du noyau alors que si tu assumes que l'hyperviseur tourne directement sur le materiel, tu devrais tres peu le modifier dans le temps. Du coup, tu peux garder une architecture simple avec un hyperviseur minimal, une interface claire et simple pour les VMs et le domaine hote. Si tu regardes ce qui se fait dans KVM, on commence a etre loin de cette simplicite.
Pour conclure je vais aller dans ton sens : ce qui est actuellement disponible ne pousse pas a faire la distinction entre type-I et type-II _mais_ les projets de recherche autour de la virtualisation et du HPC notamment devrait aboutir a des solutions ou la distinction est importante.
Et au final, chaque solution a son utilite : le type-II est bien plus interessant pour le developpement et le type-I semblent plus interessant pour l'execution efficace d'applications, notamment les applications scientifiques. Mais bon la on touche clairement la recherche alors l'avenir montera peut-etre que j'ai tord.
> Ne pas gerer la tolerance aux pannes dans un environment reparti c'est faire un jouet pas un outil.
C'est bien pour ca que des le debut Kerrighed a ete architecture pour supporter simplement le checkpoint/restart d'applications et aussi l'ajout/retrai de noeuds. Gentildemon parle de quelque chose d'utilisable en production, pas d'un prototype de recherche. Le prototype de recherche de Kerrighed a deja supporte le checkpoint/restart d'applications mais ca n'etait pas utilisable en production (un jouet pour la recherche quoi).
KerLabs et ces collaborateurs tentent justement de passer de l'etat de jouet a celui d'outil. Mais comme pour tout projet, ce passage prend du temps, il faut etre patient.
> Autrement tu as des exemples d'applications reelles qui scalent sur du SSI ?
Si tu veux une reponse, je pense qu'il va te falloir etre plus precis car "applications reelles qui scalent sur du SSI", c'est un peu vague; tu as quelle echelle en tete ? qu'est ce que tu entends par application reelle ? par SSI tu sous-entends utilisant la memoire partagee ?
Un SSI c'est un ensemble de caracteristiques qui peuvent etre combinees/utilisees ou pas. Pour etre plus precis, avec SSI, tu peux utiliser la memoire partagee ou bien utiliser uniquement l'equilibrage de charge et la tolerance aux fautes, ...etc. Une application donnee "va etre interessee" par certains de ces mecanismes et pas par d'autres (ca depend toujours de l'application au final!).
Niveau plate-forme, des clusters de >1000 noeuds? non clairement ce n'est pas pour demain. Clusters de moins de 100 noeuds pour des applications standard SMP (ou legerement tuner), c'est jouable et les derniers tests semblent indiquer cela (dans le temps j'avais fais des tests avec une appli OpenMP qui allait bien, par rapport a un SMP, ca tenait la route jusque 6-8 ce qui normal pour la plupart des applis OpenMP, donc pour ce cas particulier, ca marche).
Sinon une autre solution serait de voir ce que ca donne avec les applications qui tournent sur les machines SGI, avec un reseau haute perf sous le SSI, ca devrait etre interessant.
Ensuite si ta question est de savoir si un SSI peut etre utiliser avec une application en production, a nouveau pour le moment non (enfin pas a ma connaissance). Mais les petits gars de KerLabs travaillent sur le probleme, il faut rester optimiste, je suis sur qu'ils vont bientot nous sortir une version qui va franchement tenir la route. :-)
Personnellement, je trouve que comparer Xen et KVM comme tu le fais et dire que KVM "qui a intégré le kernel 2.6.20 au nez à la barbe de Xen en Nov. 2006" n'est pas totalement honnete car :
- KVM est une solution de virtualization de Type-II suivant la classification de Goldberg [1], i.e., l'hyperviseur tourne au dessus du systeme hote (Linux en l'occurence).
- Xen est une solution de Type-I, i.e., l'hyperviseur tourne directement au dessus du materiel, le systeme hote tournant au dessus de l'hyperviseur; l'approche de type-I est generalement concideree comme offrant de meilleures performances.
Du coup il n'est pas etonnant que l'hyperviseur de KVM s'integre mieux et plus simplement dans le noyau Linux, il a ete fait pour cela des le debut. Pour Xen, le probleme se decompose en plusieurs phases : (i) interface pour les machines virtuelles (surtout si l'on souhaite utiliser la para-virtualisation); (ii) interface ente l'hyperviseur et le domaine hote (principalement pour le domaine des drivers. Il est plus honnete de comparer VMWare ESX et Xen si on veut comparer les efforts d'integration dans le noyau Linux.
Pour finir, personnellement j'apprecie de plus en plus lguest [2] : c'est bien plus petit et bien plus "propre" (ce dernier point est bien sur totalement subjectif).
Je n'ai parcouru les liens que tres rapidement mais il me semble que OpenVMS n'est pas vraiment un systeme a image unique : pas de migration de processus/thread, pas de DSM, pas de checkpoint/restart de processus..etc. Je me trompe?
Non pas que je veuille sous-entendre que Kerrighed est mieux (tout depend de ce que l'on veut faire), juste que ces deux systemes ne cherchent pas tout a fait a faire la meme chose.
Une petite precision: la Cray XT4 tourne aussi avec le noyau Linux de chez Cray (appelle Compute Node Linux, CNL : http://nccs.gov/wp-content/uploads/2007/08/wallace_paper.pdf ). Donc la XT5 n'est pas la premiere nachine Cray a faire tourner Linux, c'est la premiere a etre vendue de base avec Linux (legere nuance mais qui fait une difference pour les utilisateurs/acheteurs).
A noter egalement qu'il se passe la meme chose pour la BlueGene, un portage de Linux est en cours depuis quelques temps et il semble que les utilisateurs pourront en beneficier bientot.
En attendant la prononciation est souvent assez differente pour justifier une version americaine et anglaise. Donc pour moi la difference Anglais/Anglais versus Anglais/Americain a ici tout son sens car on parle de pronciation (en oubliant bien sur le probleme des accents locaux). Par exemple, "tomato" se prononce de facon differente en Anglais et en Americain.
"Pour l'exemple de IEEE, il n'y a que cette année que mon labo y a accès. L'abonnement coûte apparemment très cher et est limité en bande passante ou nombre d'articles téléchargés (je ne sais plus trop), donc pour éviter de dépasser le forfait et payer encore plus cher, il a été décidé de ne pas avoir directement accès aux articles, mais de les demander à la bibliothèque. Bon, c'est pas la mort, mais c'est une petite contrainte en plus."
Ma reponse est aussi un peu provocatrice, ne le prend pas personnellement. :-)
Si le labo qui est cense m'accueillir n'offre pas un acces direct aux bibliotheques ACM/IEEE, je vais voir ailleurs. D'apres moi ce sont des outils de base pour la recherche, ne pas y avoir acces c'est un peu comme si le labo ne fournissait pas un ordinateur.
Mais bon oui ca n'a rien a voir avec le probleme initial. :-)
"Attention, il y a deux choses bien différentes : d'une part les bases de données d'articles, d'autre part le projet SciWi, qui ne gère que les relectures. Il n'est donc pas question, dans SciWi, de céder ses droits sur l'article, puisque l'article n'est pas publié via SciWi.
SciWi n'est donc absolument pas incompatible avec une publication dans une revue classique, puisqu'on peut soumettre une évaluation sur n'importe quel article avec une version identifiable. C'est juste que ce n'est pas spécialement dans l'esprit."
Je ne suis pas contre ce que tu viens de dire mais je vois toujours quelques problemes/nuances :
- la majorite des conferences/journaux ont leur propre systeme de relecture (parce qu'ils veulent etre maitre de toute la procedure de publication afin d'avoir au final des articles de qualite sous copyright).
- lors d'une soumission d'article la majorite du temps il est explicitement demande que le papier ne soit pas soumis autre part. Avec l'utilisation d'un autre systeme ca ne marche plus car en competition avec le systeme des conferences/journaux puisque je ne vois pas ACM ou IEEE utilise SciWi (si ca arrivait j'en serai le premier ravi).
Donc ok, SciWi est "uniquement" un systeme pour la relecture mais ca ne change strictement rien au probleme vu que, au moins dans mon domaine, la procedure de relecture est directement associee aux conferences/journaux qui sont eux-memes geres par les organismes internationaux qui fonctionnent de maniere autonome. Donc oui la procedure de relecture n'implique pas directement le probleme du copyright mais le systeme actuel a aussi en partie ete mis en place a cause du copyright. A mon avis dire que ce sont deux problemes independants est une erreur.
"Si tu veux des approches plus classiques permettant quand même un accès libre, je te conseille de jeter un oeil à la PLoS, qui (en biologie) a atteind une réputation comparable aux meilleures revues... en une poignée d'année seulement."
Ai-je dis quelque chose de contraire? Non, j'ai simplement dis que ca n'etait pas gagne dans mon domaine et je continue a le penser. Dans mon domaine le systeme est "verouille" principalement par ACM/IEEE car on fonctionne beaucoup avec les conferences. Dans ce cas, je ne vois pas comment SciWi peut se faire une place. J'espere que l'avenir montrera que j'ai tord mais il n'empeche, la situation est parfois un peu plus complexe que ce que presente la news ou les commentaires. Je voulais juste eclaircir cela.
"En gros, il se fait bien entuber :-)"
Bon d'accord il y a un smiley, c'est du second degre mais je precise tout de meme que l'evaluation des papiers scientifiques fait partie du travail de base de chercheur. Donc oui on n'est pas paye explicitement pour le travail d'evaluation et ca me parait normal ; cela fait parti de notre travail de base, tout comme l'organisation de conferences, les collaborations avec d'autres laboratoires et universites, et l'encadrement d'etudiants.
On se fait parfois payer pour ecrire/evaluer des livres, mais c'est une autre histoire.
Pour en revenir au sujet initial, une petite precision est pour le moment manquante : dans une bonne majorite des domaines de l'informatique (cela peut differer d'un domaine a l'autre), les chercheurs soumettent leurs travaux dans les conferences/journaux du type ACM ou IEEE (question de reconnaissance, de prestige, mais egalement pour aller aux conferences et tenter de monter de nouvelles collaborations, ...etc.). Dans ce cas, le copyright est cede a ces organismes, il est legalement impossible de diffuser le papier "tel quel" (meme si beaucoup de gens le font). Une maniere classique pour pouvoir le rediffuser est de creer un rapport technique fonde sur le meme contenu (ce qui est legal).
De plus, la majorite des labos/universites ont un abonnement a ACM/IEEE, on peut donc acceder gratuitement aux publications (sinon demande a un ami chercheur qui a acces au-dit systeme ;-)).
Bref, ce qu'il faut retenir c'est qu'un papier accepte dans une conference ou un journal ACM/IEEE ne peut pas etre soumis au systeme ouvert sans une action particuliere de l'auteur ; et que les chercheurs ont besoin de soumettre a ces endroits.
Pour conclure, c'est bien d'avoir une plate-forme ouverte pour les publications scientifiques mais je vois deux gros problemes actuellement :
- ce n'est pas compatible de maniere directe avec les systemes de type ACM/IEEE,
- quelle est la valeur d'une publication acceptee dans le systeme ouvert?
Pour le second point, on retombe directement sur ce qui a ete dit precedemment : il va falloir une bonne base de chercheurs reconnus pour que le systeme marche (pas gagne, ca me semble faire un concurrence directe avec le systeme actuel). Ensuite, il faudra motiver les chercheurs pour qu'ils soumettent leurs papiers dans les conferences (type ACM/IEEE) et a la fois dans le systeme ouvert. Pas gagne quand on voit l'emploi du temps des chercheurs...
Pour finir avec un point un peu hors sujet : il est en principe facile de trouver les references des publications interessantes pour le domaine dans lequel on travaille (outils de recherche, page web des equipes de recherche, ...etc.), et si un papier n'est pas disponible, il reste toujours la solution de contacter directement l'auteur du papier. En principe les chercheurs sont toujours pret a envoyer un PDF de leur publication.
PS : Dans mon domaine, je ne paye qu'une seule chose : l'inscription et le voyage associe aux conferences (ce qui est deja pas mal), quasiment tout le reste est gratuit (mais encore une fois cela differe pour bon nombre de domaines!).
Si par aller le plus loin possible tu penses a un master puis une these, il est clair qu'il est preferable d'integrer une licence classique et non pas une licence pro. D'un autre cote si tu es bon et que tu n'en veux, tu trouveras toujours une solution pour faire ce que tu veux.
Bon courage en tout cas.
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.
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
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).
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.
Les 80% ne correspondent pas a mon experience (et comme je le vis, j'ai tendance a le croire). De plus dans ma famille (francaise) et mon cercle d'amis proches, une bonne proportion des gens sont catholiques ou musulmans mais ne vont pas forcement a l'eglise ou a la mosquee au moins une fois par mois. Je n'estime pas pour autant qu'ils sont moins religieux... le religion a une place tout aussi importante dans leur vie pour que la majorite des americains. Bref, on n'a donc clairement pas la meme definition de "religieux".
Je suis un Francais vivant aux US depuis quelques annees. Les fautes sont dues au manque de sommeil (principalement parce que je travaille pas mal sur des logiciels libres ces derniers temps :-) et a l'utilisation de plusieurs langues sur une courte periode de temps. Ce qui bien sur n'excuse pas les dites fautes ; vraiment desole que mon texte en contienne autant.
Ce qui m'a fait tiquer dans ton message c'est que tu ne precises pas que les brown bags sont utilises "sur la voie publique" et que tu as ensuite conclu que les US sont puritains. Ne penses-tu pas que c'est une raccourci un peu facile et extreme? Tout comme dans beaucoup de villes francaises, il est interdit de boire en lieu publique. Dis-tu pour autant que la France est puritaine? Est-ce un probleme de mettre une bouteille dans un sac que tu l'achetes? je ne pense pas... Bois tu en lieu publique? si oui tres certainement que tu ne respectes pas la loi de ta commune... Bref si ca peut faire plaisir a des gens que je mette mes bouteilles d'alcool dans un sac quand je les achete, ok je fais l'effort, ca fait des heureux a peu de frais et de toute facon je fais toujours ca quelque soit le pays ou je ne trouve.
De plus ca n'est pas parce que une minorite bruyante mais puissante (les puritains) fait passer des lois que tu dois te permettre de juger un pays en entier. D'autant qu'a ma connaissance, la loi sur l'alcool et les brown bags n'est pas directement lieu a un mouvement religieux, c'est a ma connaissance une loi "pour le respect de l'ordre" qui a une signification differernte ici (la notion de liberte est differente ici par rapport a la notion de liberte communement acceptee en France). Tu affirmes que c'est le cas, je suis interesse par tous pointeurs sur le sujet. L'interdiction de vendre de l'alcool le dimanche matin est par contre pour des raisons purement religieuses.
Ensuite a ma connaissane, non les gens en Californie ne sont pas plus religieux (mais peut-etre que l'on ne donne pas la meme definition au terme) qu'en France. De maniere generale de toute facon, la plupart des gens aux US se foutent de ta religion et de tes habitudes. Car contre oui comme je l'ai dis plus haut une groupe puritain existe aux US, est puissant et fait du bruit... de la a "condamner" les US dans son entier, il ne faut pas pousser.
<mode provocation>
Et puis de toute facon, en voyageant tu te rends compte que les francais sont faineants bruleurs de voitures hein... je suppose que de la meme maniere les americains sont puritains.
</mode provocation>
Pour finir tu penses ce que tu veux, tu dis ce que tu veux. Personnellement j'ai la chance de connaitre un peu les US, je precise quelques points que tu mets en valeur et qui sont "deplaces". J'avais tendance a penser la meme chose que toi avant de decouvrir les US et en passant du temps sur place je me suis rendu compte que la majorite des prejuges que j'avais n'avaient aucune realite de masse (bref que c'etaient des generalisations deplacees).
Maintenant j'arrete ici cette "conversation" qui n'a strictement rien a faire sur ce site et qui de toute facon ne va rien changer du tout.
En principe je ne reagis pas sur ce genre de remarques sur les US mais ce soir, je me jete a l'eau...
Dans les "brown bags" sont bien les sacs en papier de couleur brune, utilises pour mettre les bouteilles d'alcool certes mais egalement utilises par exemple par les petites epicieries.
Ensuite la vraie situation concernant l'alcool aux US est la suivante :
- Dans la plupart des counties (comtes en bon francais) et des etats, il est interdit de boire de l'alcool sur le voie publique ; comme dans la majorite des communes francaises. La principale difference est qu'aux US, la loi est reellement appliquee. :-)
- Dans la plupart des etats/counties, il est interdit d'avoir une bouteille d'alcool ouverte et apparente sur le voie publique. Tu fais ce que tu veux dans un lieu prive (toujours un peu comme la France).
- Il existe des counties sec (dry counties), i.e., des counties ou la vente et l'achat d'alcool est interdit. Pour anecdote le distillerie Jack Daniels est dans un county sec.
- Dans certains etats les supermarches ne peuvent pas vendre d'alcool, exception pour la biere. Pour trouver du vin ou des liqueurs il faut aller dans des "liquor shops".
- Il est interdit d'avoir une bouteille d'alcool ouverte dans les parcs naturels regionaux et federaux.
- Il est souvent interdit d'acheter de l'alcool le dimanche matin avant midi (au moins de ce que je sais dans le sud, dans la "bible belt").
Bref, comme souvent, generaliser comme tu le fais sur les US n'a pas de sens quand tu connais un peu le pays. Il y a des differences enormes entre les etats et meme entre counties. Mais je suis egalement concient que beaucoup de gens ici ont simplement une animosite naturelle contre les US (je ne dis pas que c'est ton cas, je te connais pas personnellement).
Au passage en Californie par exemple, je pense que l'on peut dire que les gens sont globalement moins puritains qu'en France.
Mes 2 cents inutiles et hors sujet (vous pouvez donc moissonner).
C'est un outil et juste un outil. Bref, comme tout outil, il y en gros 2 cas pour un cadre precis : (1) la personne sait l'utiliser correctement dans un cadre qui convient et elle devient donc plus efficace ; ou bien (2) elle ne sait pas correctement l'utiliser ou le contexte ne convient pas a l'utilisation de l'outil et dans ce cas c'est inutile.
Ca me parait aussi simple que cela...
Pour en revenir au sujet, je pense que ce genre d'outil peut-etre complementaire a ceux qui sont traditionnellement utilises pour le developpement logiciel, surtout lorsque l'on veut une vision globale d'un projet sur lequel de nombreuses personnes travaillent (dans ce cas, il est difficile de connaitre tous les composents du projet)... comme toute solution de visualisation (reference au projet de recherche sur la visualisation des donnees de grande taille, tout ca tout ca).
Si par "implémentation de MPI qui soit threadsafe ET performante" tu veux dire une mise en oeuvre de MPI qui tire profit de la memoire partagee sur les noeuds SMP, LAM-MPI et Open MPI font ca. A priori c'est vraiment thread-safe et ca marche plutot bien (j'utilise de temps en temps LAM-MPI je n'ai jamais eu de reels problemes). http://www.lam-mpi.org/ http://www.open-mpi.org/
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
Je ne suis pas du tout d'accord : le HPC est la niche (quelque billion par an et une part de marche qui ne croit pas vraiment), pas l'inverse.
> des clusters HPC existants tournent sur du linux
Le HPC est tres loin de se limiter aux clusters Linux. Par exemple environ la moitie des 10 machines le plus puissantes du top500 n'executent pas Linux sur les noeuds de calcul (BlueGene -> CNK, Cray -> Catamount). C'est a mon avis une erreur de limiter le HPC aux clusters Linux, pour cela que ldans mes posts precedents j'ai pris la peine de citer ces plate-formes. Je pense d'ailleur que c'est _le_ point qui fait que l'on se soit pas totalement d'accord car ton analyse est tres pertinente et en dehors de ce point, je suis globalement d'accord avec toi.
> des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
Quand tu n'as pas de Linux, ca ne marche plus. Et il est clair que ces cas la m'interessent. Et meme si les BlueGene et les Cray vont bientot offrir du Linux sur les noeuds de calcul, vu que c'est une version de Linux "epuree", toutes ces solutions ne fonctionneront clairement pas.
> Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware
Heu la non, pas tout a fait. Personnellement je ne peux pas justifier n'importe quoi sans prouver que la degradation en terme de perf n'est pas trop importante. Et dans ce contexte, clairement la nature de l'hyperviseur est important. Avec un type-I, on peut faire un domaine hote petit (dans les solutions actuelles ce n'est pas le cas par defaut) et un hyperviseur avec un comportement predictible (pas le cas de Xen dans certains cas) pour l'execution d'applications paralleles. Je ne pense vraiment pas que tu puisse faire la meme chose avec une solution de type-II (et en fait pas non plus avec les solutions de type-II actuellement dispo!).
Dans mon cas, je ne peux justifier qu'au maximum 10% de penalite avec un vrai apport en terme de fonctionnalites. Si tu passes d'un micro-noyau a Linux + virtualisation, c'est quasiment impossible (deja le passage a Linux meme apres optimisation donne une penalite d'environ 25% dans les all-to-all avec des applications MPI lorsque l'on compare a un micro-noyau).
Et je tiens a souligner que les hyperviseurs actuels (e.g., Xen) ne sont pas des micro-noyaux (tu ne l'as pas dis mais c'est quelque chose que je vois souvent et qui est faux). A ma connaissance aucune solution actuelle est fondee sur un micro noyau (certains disent que ESX l'est mais dur de verifier). Par exemple, L4, catamount et CMK sont des micro-noyau; Xen n'en est pas un.
> Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0.
Pour le HPC sur une machine type Cray, non, impossible actuellement. Sur un cluster deja Linux je suis d'accord avec toi. Mais a nouveau ca sort du HPC strict, ca devient "HPC avec cluster Linux", ce qui je te l'accorde concerne beaucoup de gens, mais pas tout le monde. :-) Et puis meme avec Linux je demande a voir. Mes premiers tests avec KVM n'ont pas montres d'interets reels.
Je suis egalement d'accord a 200% avec ton avis sur L4 et ESX.
> Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
Egalement d'accord a 200% avec toi (ce que meme des gens faisant de l'OS oublient parfoit) mais je pousse l'analyse un poil plus loin : Linux est bien trop complexe (desole mais l'architecture de systeme de fichier, je la trouve vraiment trop complexe :-). Pour cela que je prefere "naturellement" les solutions de type-I : ca t'ouvre les portes pour mettre ce que tu veux dans les VMs mais aussi dans le domaine hote; les differents "composants" de la solution de virtualisation sont bien separes; avec une solution de type-II c'est bien plus complexe (imbrications et dependences).
> La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
Dans l'absolu je suis bien d'accord. As-tu jeter un coup d'oeil aux projets finances par la NSF autour de la virtualisation? Il y a des idees interessantes (meme si a mon avis il manque des choses parfois). L'un des projets est le suivant, impossible de remettre le main sur le deuxieme (qui est pourtant plus interessant a mon sens car fonde sur l'idee d'un framework pour le developpement de nouvelles solutions de virtualisation) :
http://www.nsf.gov/news/news_summ.jsp?cntn_id=110606&org(...)
> La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux
Justement, pourquoi ne pas reprendre des microkernels existant pour mettre en oeuvre une nouvelle solution (un peu l'idee de L4) ? Bien sur ca sera tres specialise pour une plate-forme donnee (toujours le probleme des drivers) mais je pense que cette approche serait bien plus interessante.
> Cela dit, pour déterminer où ça coince, on a également besoin d'instrumentation, de familiarité avec la plateforme. Et pour cela, encore une fois, plus c'est simple mieux c'est. Encore une fois je pense que c'est un aspect sur lequel Linux+KVM est plus intéressant que Xen. Rien qu'un exemple : on peut facilement tester sans KVM en gardant le reste de l'environnement à l'identique : il suffit de lancer l'émulation avec l'option -no-kvm.
Je recupere des resultats de profiling tous les jours en ce moment en utilisant Xen et oprofile, ca marche plutot bien. Par contre, c'est sur que si tu veux debugger ta VM seule, une solution de type-II est bien meilleure (ce que j'ai deja dis auparavant).
A noter que la simplicite dont tu parles est perdue des que tu veux faire ca au sein d'un cluster de taille assez importante (d'un autre cote, une solution open-source qui apporte un bout de solution pour ca devrait bientot etre mise a disposition, permettant aux utilisateurs de passer tres simplement de VMs sur un cluster a un cluster "normal").
> D'autre part, l'instrumentation du "kernel" Xen est à ma connaissance encore très limitée, et de toutes façon il faut encore pouvoir effectuer les diagnostics en tenant compte de ce qui se passe dans Xen mais aussi dans le Dom0. Les niveaux d'encapsulation font que ça revient au même que le débuggage d'une servlet sur un serveur d'application java, et crois moi, je connais beaucoup de sysadmin qui en frémissent (même si sur ce front là il y a eu des progrès).
Non ca se fait tres bien, comme je l'ai dis, je vois des traces au quotidien et avec des scripts simples, on peut recuperer toutes les informations necessaires. Et pas besoin de modifier quoique ce soit, meme avec au sein d'un cluster.
> D'autre part, pour revenir à la problématique de l'hôte, quelque soit son type, oui, à niveau de maturité de code égal et d'effort de développement égal, plus c'est petit et simple (en nombre de LoC) mieux c'est.
Bien d'accord et encore une fois, si tu as du tout Linux, KVM ou lguest sont tres interessants (j'aime bien les idees de simplicite derriere lguest). Je ne tente pas de prouver le contraire.
> Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
Non je ne suis pas tout a fait d'accord, il est possible d'avoir un hyperviseur petit et modulaire (donc pas Xen), un hostOS petit (donc pas Linux avec les configurations associees aux solutions de virtualisation actuelles), et des VMs avec ce que l'on veut dedans. Avec Linux+KVM, tu t'eloignes tout de suite de ca (overhead de Linux par rapport a des micro-noyaus specialises).
Mais bon, je pense aussi que de toute facon, avec les solutions actuelles, des que tu passes a une plate-forme distribuee (e.g., cluster), tu te prends la tete et pas qu'un peu.
Pour conclure ton analyse est vraiment pertinente, merci pour ca (ca faisait longtemps que je n'avais pas eu une discussion interessante sur LinuxFr!). Le seul bemol que je me permets est que dans mon cas je ne me limite pas a du tout Linux. :-) Ce qui bien sur n'interessera que peu de personnes ici.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 2.
D'ailleur il le dit bien : "Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine." Forcement c'est dans l'autre papier! Il cite le papier de Popek et Goldberg, pas celui de Goldberg seul (celui de sa these). C'est le papier de Goldberg qui presente la classification de maniere precise. Mais c'est une erreur commune que l'on retrouve meme dans les publications scientifiques sur le sujet.
Il dit ensuite " like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware" et c'est bien ce qui est important : le module _doit_ avoir un systeme hote pour fonctionner, initialiser la memoire et compagnie. Pour une solution de type-I, le VMM boot en premier. Du coup, si tu n'as pas besoin de drivers particulier, tu n'as pas besoin du systeme hote. C'est pourquoi lorsque tu regardes le cycle de vie d'une VM, il n'y a absolument pas besoin d'acceder au domaine hote au moins dans les premiers instants de vie de la VM. Quel interet si on ne peut utiliser de drivers? et bien tu es libre d'utiliser ce que tu veux comme domaine hote plus tard, et non pas seulement Linux (pourquoi pas un OS specialise parfaitement adapte a ta plate-forme, e.g., CNK des BlueGene). C'est completement impossible avec une solution de type-II. Bon d'accord on parle ici de recherche mais comme je l'ai dis des le debut, c'est le contexte qui m'interesse.
A noter aussi qu'il met Xen dans les micro-kernel, ce qui est faux! Ca n'est pas parce que Xen est petit (quoique sur ca aussi il y a discuter), qu'il est un micro-kernel. Un micro-kernel, c'est par exemple L4 et Xen est tres loin d'une architecture de micro-kernel (Xen a un design tres monolithique).
Donc au final, je ne suis pas d'accord avec l'analyse de Anthony Liguori qui a mon avis melange beaucoup de chose dans cet article et oublie les definitions exactes et initiales.
Pour ce qui est Wikipedia, desole je ne fie absoluement pas a Wikipedia pour ce genre de chose : des que l'on aborde des sujets pointus, bien souvent les articles sont de la vulgarisation et non pas un article de reference.
Pour ce qui est de savoir qui est le plus performant, a mon avis la question a peu de sens, il faut preciser avec quelle application et surtout quelle plateforme materielle. Et c'est bien ca que je tente de souligner : dire que les solutions de type-II sont generalement meilleures a peu de sens, comme dire que les solutions de type_i sont meilleures. Pour le HPC, les solutions de type-I _semblent_ meilleures, notamment vu les resultats de differentes equipes de recherche. A noter egalement que le HVM a priori n'ameliore pas les performances (surtout dans le cas d'une solution de Type-I initialement implementee par de la para-virtualisation). Ca simplifie les choses et ouvre des portes, c'est tout.
Ensuite et pour finir, je ne veux pas prouver que ce qui a ete dit est faux, je souhaite juste souligner que la question de la virtualisation n'est pas simple et que les conclusions demandent totalement du contexte. Je tente juste d'expliquer mon point du vue dans le contexte qui m'interesse (recherche en OS pour resumer).
PS : ce fut en tout cas une discussion agreable qui m'a permi de lire des articles/blogs que je n'avais pas lu. Toujours interessant de voir des avis differents lorsque c'est argumente, ce qui devient un peu trop rare a mon gout sur ce site. :-)
[^] # Re: Robustesse?
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
Tout d'abord, ca ce n'est pas une grande echelle actuellement. :-) Plus serieusement je pense que ca devrait le faire si l'on a une application qui le permet. Car soyons serieux : connais-tu une application "classique" actuelle qui peut utiliser tant de core a elle toute seule ? Moi non.
L'avantage du SSI dans ce cas est comme pour le SMP : il est simple de voir ce qui se passe, il est simple de lancer des applications, il n'est pas trop dur d'ecrire une application parallele (memoire partagee tout ca tout ca) et si tu executes des applications en meme temps, les resources sont globalement utilisees de maniere transparentes.
A mon avis, tu ne peux pas ca aussi simplement avec les outils standards pour les systemes distribues (par exemple mais a mon avis, un systeme batch est loin d'etre naturel a utiliser).
Donc SVP, si tu as des elements pour dire que ca ne passe pas a cette echelle, peux-tu donner plus de details? Car vu les derniers tests que j'ai pu voir, ca me semble franchement faisable dans le cas d'utilisation que je decris plus haut.
> Une application classique serait éffectivement une application avec CPU intensif et memoire partagée. Si il n'y a que du CPU et des workers stateless, type demon httpd/dns, alors on peut en general faire du loadbalancing sur les processus. Si il n'y a que des gros besoin mémoire alors des solutions types jumbomem fonctionnent aussi. Et enfin quand on veut réellement se soucier d'écrire une application distribuée alors on utilise un middleware adéquat.
Heu mais la tu justifies le SSI!
- loadbalancing: transparent a l'utilisateur, il n'a rien a faire pour cela, le SSI place et deplace les processus entre les processeurs. Pas besoin de systeme de batch ni d'autres outils qui au final ne font qu'etendre de maniere artificielle ce que les systemes de type Unix font tres bien au sein d'un systeme unique.
- gros besoin en memoire : avec la DSM c'est possible et transparent encore une fois. La difference entre jumbomem et une DSM est vraiment minime pour ce que je sais, non?
- utiliser un middleware adequat : oui et alors? le SSI n'empeche pas ca. C'est meme une bonne idee pour avoir des performances.
Ensuite l'avantages du SSI c'est que tu as le choix : tu veux utiliser MPI pour avoir les perfs de la mort qui tue, pas de pbs; tu veux utiliser pthread qui faire un truc vite fait qui tourne sur quelques noeuds, pas de probleme; ...etc. Et bien sur que le SSI je repond pas a TOUS les besoins (aucune solution ne le fait de toute facon).
Bref, le SSI offre plein de possibilites. Pour certaines personnes, ca ne sera pas interessant, pour d'autres ca le sera. Par exemple, le SSI va tres bien avec le concept de "cluster sur ton bureau", i.e., une petite machines assez dense pour tenir sur ton bureau avec plusieurs processeurs/cores a l'interieur. Pour democratiser ce genre de machine, tu dois cacher la distribution des resoruces, le SSI est parfait pour ca.
> Je pense que votre cluster est justement fait pour jouer, donc ce qui sera intéressant ce sont les retours d'éxpérience.
Justement je t'ai deja dis dans le message precedent qu'avec des applications scientifiques "qui vont bien" (OpenMP dans mon cas), ca se passait plutot bien. L'idee dans ce cas est de remplacer les SMP vieillissant qui etaient utilises pour l'execution de ces applis par quelques noeuds (beaucoup moins chers) faisant tourner un SSI.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
Au moins pour ce qui se passe actuellement au niveau recherche, je pense le contraire : la difference entre type-I et type-II a toujours beaucoup de sens et doit etre preservee car les deux approches ne repondent pas aux meme besoins. Pour justifier le type-I, il est par exemple possible d'analyser les besoins associes a l'execution des applications scientifiques et le HPC. Dans ce cas, dire que la distinction type-I et type-II est avant tout marketing est totalement deplace (je donne quelques points plus bas pour illustrer cela).
De plus tu dis que les solutions actuelles sont hybrides, je crois que c'est vraiment faux. Uniquement _quelques_ solutions sont hybrides, ou alors peux-tu me citer ces solutions SVP, car j'ai besoin d'etre eduque sur le sujet si c'est le cas.
> il n'y a pas les A/R entre l'hyperviseur et le Dom0 pour les accès au hardware. Sans compter que des fonctionnalités telles que l'overcommit de mémoire (déjà présentes dans KVM) seront difficiles à intégrer dans Xen afaik.
Pour eviter les A/R entre l'hyperviseur et le Dom0, on sait deja que la notion de "sidecore" est une solution efficace : tu places l'hyperviseur sur un core et tu executes les VMs et le domaine hote sur d'autres cores. C'est simple et tu gagnes beaucoup en performance. Tu peux te reporter aux travaux fait a GATech pour plus de details (entre autre). Ensuite pour l'overcommit de la memoire, tout d'abord je ne vois pas pourquoi tu veux faire ca (au moins dans le cadre des applications scientifiques/HPC) et ensuite la manipulation de la memoire avec une solution de type-I est tres proche du cout de la gestion memoire dans un systeme normal. J'ai fais des tests avec Xen, le cout est entre 0 et 2 %. Le probleme se situe principalement au niveau des entrees/sorties et la, le type-II n'apporte pas forcement quelque chose de plus. A chaque fois, quelque soit la techno selectionnee, il faut acceder au materiel de maniere directe depuis les VMs, avec le partage entre les VMs.
D'un autre cote, si tu vises le HPC, tu tombes sur les problemes suivant : avec une solution de virtualisation, type KVM, le domaine hote doit absoluement etre un Linux. Or si tu prends les plate-forme HPC actuelles type BlueGene ou Cray, c'est rarement le cas. Tu vas me dire que dans ce cas, la solution de type-I ne fonctionne pas plus car le domaine hote doit etre un Linux. C'est vrai mais cela devrait changer dans un avenir proche si tout va bien (plusieurs projets de recherche sur le sujet). :-) L'autre point interessant est de savoir pourquoi l'hyperviseur devrait etre un module du noyau Linux pour faire des choses simples, i.e., seulement manipuler de la memoire. L'inclusion dans le noyau impose de suivre les evolutions du noyau alors que si tu assumes que l'hyperviseur tourne directement sur le materiel, tu devrais tres peu le modifier dans le temps. Du coup, tu peux garder une architecture simple avec un hyperviseur minimal, une interface claire et simple pour les VMs et le domaine hote. Si tu regardes ce qui se fait dans KVM, on commence a etre loin de cette simplicite.
Pour conclure je vais aller dans ton sens : ce qui est actuellement disponible ne pousse pas a faire la distinction entre type-I et type-II _mais_ les projets de recherche autour de la virtualisation et du HPC notamment devrait aboutir a des solutions ou la distinction est importante.
Et au final, chaque solution a son utilite : le type-II est bien plus interessant pour le developpement et le type-I semblent plus interessant pour l'execution efficace d'applications, notamment les applications scientifiques. Mais bon la on touche clairement la recherche alors l'avenir montera peut-etre que j'ai tord.
[^] # Re: Robustesse?
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
C'est bien pour ca que des le debut Kerrighed a ete architecture pour supporter simplement le checkpoint/restart d'applications et aussi l'ajout/retrai de noeuds. Gentildemon parle de quelque chose d'utilisable en production, pas d'un prototype de recherche. Le prototype de recherche de Kerrighed a deja supporte le checkpoint/restart d'applications mais ca n'etait pas utilisable en production (un jouet pour la recherche quoi).
KerLabs et ces collaborateurs tentent justement de passer de l'etat de jouet a celui d'outil. Mais comme pour tout projet, ce passage prend du temps, il faut etre patient.
> Autrement tu as des exemples d'applications reelles qui scalent sur du SSI ?
Si tu veux une reponse, je pense qu'il va te falloir etre plus precis car "applications reelles qui scalent sur du SSI", c'est un peu vague; tu as quelle echelle en tete ? qu'est ce que tu entends par application reelle ? par SSI tu sous-entends utilisant la memoire partagee ?
Un SSI c'est un ensemble de caracteristiques qui peuvent etre combinees/utilisees ou pas. Pour etre plus precis, avec SSI, tu peux utiliser la memoire partagee ou bien utiliser uniquement l'equilibrage de charge et la tolerance aux fautes, ...etc. Une application donnee "va etre interessee" par certains de ces mecanismes et pas par d'autres (ca depend toujours de l'application au final!).
Niveau plate-forme, des clusters de >1000 noeuds? non clairement ce n'est pas pour demain. Clusters de moins de 100 noeuds pour des applications standard SMP (ou legerement tuner), c'est jouable et les derniers tests semblent indiquer cela (dans le temps j'avais fais des tests avec une appli OpenMP qui allait bien, par rapport a un SMP, ca tenait la route jusque 6-8 ce qui normal pour la plupart des applis OpenMP, donc pour ce cas particulier, ca marche).
Sinon une autre solution serait de voir ce que ca donne avec les applications qui tournent sur les machines SGI, avec un reseau haute perf sous le SSI, ca devrait etre interessant.
Ensuite si ta question est de savoir si un SSI peut etre utiliser avec une application en production, a nouveau pour le moment non (enfin pas a ma connaissance). Mais les petits gars de KerLabs travaillent sur le probleme, il faut rester optimiste, je suis sur qu'ils vont bientot nous sortir une version qui va franchement tenir la route. :-)
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 2.
- KVM est une solution de virtualization de Type-II suivant la classification de Goldberg [1], i.e., l'hyperviseur tourne au dessus du systeme hote (Linux en l'occurence).
- Xen est une solution de Type-I, i.e., l'hyperviseur tourne directement au dessus du materiel, le systeme hote tournant au dessus de l'hyperviseur; l'approche de type-I est generalement concideree comme offrant de meilleures performances.
Du coup il n'est pas etonnant que l'hyperviseur de KVM s'integre mieux et plus simplement dans le noyau Linux, il a ete fait pour cela des le debut. Pour Xen, le probleme se decompose en plusieurs phases : (i) interface pour les machines virtuelles (surtout si l'on souhaite utiliser la para-virtualisation); (ii) interface ente l'hyperviseur et le domaine hote (principalement pour le domaine des drivers. Il est plus honnete de comparer VMWare ESX et Xen si on veut comparer les efforts d'integration dans le noyau Linux.
Pour finir, personnellement j'apprecie de plus en plus lguest [2] : c'est bien plus petit et bien plus "propre" (ce dernier point est bien sur totalement subjectif).
[1] ARCHITECTURE OF VIRTUAL MACHINES, R.P. Goldberg
[2] http://en.wikipedia.org/wiki/Lguest
[^] # Re: ça existe depuis 1984...
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 2.
Non pas que je veuille sous-entendre que Kerrighed est mieux (tout depend de ce que l'on veut faire), juste que ces deux systemes ne cherchent pas tout a fait a faire la meme chose.
[^] # Re: Faux
Posté par gvallee . En réponse à la dépêche Le Cray XT-5 entièrement sous Linux. Évalué à 4.
A noter egalement qu'il se passe la meme chose pour la BlueGene, un portage de Linux est en cours depuis quelques temps et il semble que les utilisateurs pourront en beneficier bientot.
[^] # Re: Ne faudrait-il pas dire plutôt...
Posté par gvallee . En réponse à la dépêche Les verbes irréguliers anglais enfin libres !. Évalué à 2.
[^] # Re: Précision
Posté par gvallee . En réponse à la dépêche Sci-Wi, projet libre pour l'évaluation scientifique. Évalué à 2.
Ma reponse est aussi un peu provocatrice, ne le prend pas personnellement. :-)
Si le labo qui est cense m'accueillir n'offre pas un acces direct aux bibliotheques ACM/IEEE, je vais voir ailleurs. D'apres moi ce sont des outils de base pour la recherche, ne pas y avoir acces c'est un peu comme si le labo ne fournissait pas un ordinateur.
Mais bon oui ca n'a rien a voir avec le probleme initial. :-)
[^] # Re: Précision
Posté par gvallee . En réponse à la dépêche Sci-Wi, projet libre pour l'évaluation scientifique. Évalué à 2.
SciWi n'est donc absolument pas incompatible avec une publication dans une revue classique, puisqu'on peut soumettre une évaluation sur n'importe quel article avec une version identifiable. C'est juste que ce n'est pas spécialement dans l'esprit."
Je ne suis pas contre ce que tu viens de dire mais je vois toujours quelques problemes/nuances :
- la majorite des conferences/journaux ont leur propre systeme de relecture (parce qu'ils veulent etre maitre de toute la procedure de publication afin d'avoir au final des articles de qualite sous copyright).
- lors d'une soumission d'article la majorite du temps il est explicitement demande que le papier ne soit pas soumis autre part. Avec l'utilisation d'un autre systeme ca ne marche plus car en competition avec le systeme des conferences/journaux puisque je ne vois pas ACM ou IEEE utilise SciWi (si ca arrivait j'en serai le premier ravi).
Donc ok, SciWi est "uniquement" un systeme pour la relecture mais ca ne change strictement rien au probleme vu que, au moins dans mon domaine, la procedure de relecture est directement associee aux conferences/journaux qui sont eux-memes geres par les organismes internationaux qui fonctionnent de maniere autonome. Donc oui la procedure de relecture n'implique pas directement le probleme du copyright mais le systeme actuel a aussi en partie ete mis en place a cause du copyright. A mon avis dire que ce sont deux problemes independants est une erreur.
"Si tu veux des approches plus classiques permettant quand même un accès libre, je te conseille de jeter un oeil à la PLoS, qui (en biologie) a atteind une réputation comparable aux meilleures revues... en une poignée d'année seulement."
Ai-je dis quelque chose de contraire? Non, j'ai simplement dis que ca n'etait pas gagne dans mon domaine et je continue a le penser. Dans mon domaine le systeme est "verouille" principalement par ACM/IEEE car on fonctionne beaucoup avec les conferences. Dans ce cas, je ne vois pas comment SciWi peut se faire une place. J'espere que l'avenir montrera que j'ai tord mais il n'empeche, la situation est parfois un peu plus complexe que ce que presente la news ou les commentaires. Je voulais juste eclaircir cela.
[^] # Re: Précision
Posté par gvallee . En réponse à la dépêche Sci-Wi, projet libre pour l'évaluation scientifique. Évalué à 4.
Bon d'accord il y a un smiley, c'est du second degre mais je precise tout de meme que l'evaluation des papiers scientifiques fait partie du travail de base de chercheur. Donc oui on n'est pas paye explicitement pour le travail d'evaluation et ca me parait normal ; cela fait parti de notre travail de base, tout comme l'organisation de conferences, les collaborations avec d'autres laboratoires et universites, et l'encadrement d'etudiants.
On se fait parfois payer pour ecrire/evaluer des livres, mais c'est une autre histoire.
Pour en revenir au sujet initial, une petite precision est pour le moment manquante : dans une bonne majorite des domaines de l'informatique (cela peut differer d'un domaine a l'autre), les chercheurs soumettent leurs travaux dans les conferences/journaux du type ACM ou IEEE (question de reconnaissance, de prestige, mais egalement pour aller aux conferences et tenter de monter de nouvelles collaborations, ...etc.). Dans ce cas, le copyright est cede a ces organismes, il est legalement impossible de diffuser le papier "tel quel" (meme si beaucoup de gens le font). Une maniere classique pour pouvoir le rediffuser est de creer un rapport technique fonde sur le meme contenu (ce qui est legal).
De plus, la majorite des labos/universites ont un abonnement a ACM/IEEE, on peut donc acceder gratuitement aux publications (sinon demande a un ami chercheur qui a acces au-dit systeme ;-)).
Bref, ce qu'il faut retenir c'est qu'un papier accepte dans une conference ou un journal ACM/IEEE ne peut pas etre soumis au systeme ouvert sans une action particuliere de l'auteur ; et que les chercheurs ont besoin de soumettre a ces endroits.
Pour conclure, c'est bien d'avoir une plate-forme ouverte pour les publications scientifiques mais je vois deux gros problemes actuellement :
- ce n'est pas compatible de maniere directe avec les systemes de type ACM/IEEE,
- quelle est la valeur d'une publication acceptee dans le systeme ouvert?
Pour le second point, on retombe directement sur ce qui a ete dit precedemment : il va falloir une bonne base de chercheurs reconnus pour que le systeme marche (pas gagne, ca me semble faire un concurrence directe avec le systeme actuel). Ensuite, il faudra motiver les chercheurs pour qu'ils soumettent leurs papiers dans les conferences (type ACM/IEEE) et a la fois dans le systeme ouvert. Pas gagne quand on voit l'emploi du temps des chercheurs...
Pour finir avec un point un peu hors sujet : il est en principe facile de trouver les references des publications interessantes pour le domaine dans lequel on travaille (outils de recherche, page web des equipes de recherche, ...etc.), et si un papier n'est pas disponible, il reste toujours la solution de contacter directement l'auteur du papier. En principe les chercheurs sont toujours pret a envoyer un PDF de leur publication.
PS : Dans mon domaine, je ne paye qu'une seule chose : l'inscription et le voyage associe aux conferences (ce qui est deja pas mal), quasiment tout le reste est gratuit (mais encore une fois cela differe pour bon nombre de domaines!).
[^] # Re: C'est ce que je cherchais
Posté par gvallee . En réponse à la dépêche Licence pro « Systèmes informatiques et logiciels » option « Systèmes intranet / Internet pour l'entreprise » à Dijon. Évalué à 5.
Bon courage en tout cas.
[^] # Re: Virtualbox... issu de qemu
Posté par gvallee . En réponse à la dépêche Citrix Systems Inc. achète la société XenSource Inc.. Évalué à 1.
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 gvallee . En réponse à la dépêche Citrix Systems Inc. achète la société XenSource Inc.. Évalué à 3.
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 gvallee . En réponse à la dépêche Citrix Systems Inc. achète la société XenSource Inc.. Évalué à 1.
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 gvallee . En réponse à la dépêche Citrix Systems Inc. achète la société XenSource Inc.. Évalué à 2.
QEMU/Bosh sont toujours assez incontournables.
[^] # Re: Regressions et mac80211
Posté par gvallee . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à -1.
Mais bon c'est une discussion sterile...
[^] # Re: Regressions et mac80211
Posté par gvallee . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 3.
[^] # Re: Regressions et mac80211
Posté par gvallee . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 4.
De plus ca n'est pas parce que une minorite bruyante mais puissante (les puritains) fait passer des lois que tu dois te permettre de juger un pays en entier. D'autant qu'a ma connaissance, la loi sur l'alcool et les brown bags n'est pas directement lieu a un mouvement religieux, c'est a ma connaissance une loi "pour le respect de l'ordre" qui a une signification differernte ici (la notion de liberte est differente ici par rapport a la notion de liberte communement acceptee en France). Tu affirmes que c'est le cas, je suis interesse par tous pointeurs sur le sujet. L'interdiction de vendre de l'alcool le dimanche matin est par contre pour des raisons purement religieuses.
Ensuite a ma connaissane, non les gens en Californie ne sont pas plus religieux (mais peut-etre que l'on ne donne pas la meme definition au terme) qu'en France. De maniere generale de toute facon, la plupart des gens aux US se foutent de ta religion et de tes habitudes. Car contre oui comme je l'ai dis plus haut une groupe puritain existe aux US, est puissant et fait du bruit... de la a "condamner" les US dans son entier, il ne faut pas pousser.
<mode provocation>
Et puis de toute facon, en voyageant tu te rends compte que les francais sont faineants bruleurs de voitures hein... je suppose que de la meme maniere les americains sont puritains.
</mode provocation>
Pour finir tu penses ce que tu veux, tu dis ce que tu veux. Personnellement j'ai la chance de connaitre un peu les US, je precise quelques points que tu mets en valeur et qui sont "deplaces". J'avais tendance a penser la meme chose que toi avant de decouvrir les US et en passant du temps sur place je me suis rendu compte que la majorite des prejuges que j'avais n'avaient aucune realite de masse (bref que c'etaient des generalisations deplacees).
Maintenant j'arrete ici cette "conversation" qui n'a strictement rien a faire sur ce site et qui de toute facon ne va rien changer du tout.
[^] # Re: Regressions et mac80211
Posté par gvallee . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 9.
Dans les "brown bags" sont bien les sacs en papier de couleur brune, utilises pour mettre les bouteilles d'alcool certes mais egalement utilises par exemple par les petites epicieries.
Ensuite la vraie situation concernant l'alcool aux US est la suivante :
- Dans la plupart des counties (comtes en bon francais) et des etats, il est interdit de boire de l'alcool sur le voie publique ; comme dans la majorite des communes francaises. La principale difference est qu'aux US, la loi est reellement appliquee. :-)
- Dans la plupart des etats/counties, il est interdit d'avoir une bouteille d'alcool ouverte et apparente sur le voie publique. Tu fais ce que tu veux dans un lieu prive (toujours un peu comme la France).
- Il existe des counties sec (dry counties), i.e., des counties ou la vente et l'achat d'alcool est interdit. Pour anecdote le distillerie Jack Daniels est dans un county sec.
- Dans certains etats les supermarches ne peuvent pas vendre d'alcool, exception pour la biere. Pour trouver du vin ou des liqueurs il faut aller dans des "liquor shops".
- Il est interdit d'avoir une bouteille d'alcool ouverte dans les parcs naturels regionaux et federaux.
- Il est souvent interdit d'acheter de l'alcool le dimanche matin avant midi (au moins de ce que je sais dans le sud, dans la "bible belt").
Bref, comme souvent, generaliser comme tu le fais sur les US n'a pas de sens quand tu connais un peu le pays. Il y a des differences enormes entre les etats et meme entre counties. Mais je suis egalement concient que beaucoup de gens ici ont simplement une animosite naturelle contre les US (je ne dis pas que c'est ton cas, je te connais pas personnellement).
Au passage en Californie par exemple, je pense que l'on peut dire que les gens sont globalement moins puritains qu'en France.
Mes 2 cents inutiles et hors sujet (vous pouvez donc moissonner).
[^] # Re: Visualisation ?
Posté par gvallee . En réponse à la dépêche Relief 1.1, visualisation 3D de projets Java. Évalué à 3.
Ca me parait aussi simple que cela...
Pour en revenir au sujet, je pense que ce genre d'outil peut-etre complementaire a ceux qui sont traditionnellement utilises pour le developpement logiciel, surtout lorsque l'on veut une vision globale d'un projet sur lequel de nombreuses personnes travaillent (dans ce cas, il est difficile de connaitre tous les composents du projet)... comme toute solution de visualisation (reference au projet de recherche sur la visualisation des donnees de grande taille, tout ca tout ca).
Mes 2 cents peu utiles,
[^] # Re: OpenMP
Posté par gvallee . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 1.
[^] # Re: OpenMP
Posté par gvallee . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 1.
En plus, la combinaison Marcel/Madeleine/MPICH reste une valeur sure (que j'avais oublie). D'ailleurs ca fait longtemps que je ne l'ai pas utilise...
[^] # Re: OpenMP
Posté par gvallee . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 2.
http://www.lam-mpi.org/
http://www.open-mpi.org/