Samuel Thibault a écrit 190 commentaires

(bien sûr, n'hésitez pas à demander toute précision)

Il me semble qu'il y a eu pas mal d'amalgames dans les discussions qui ont suivi, je vais essayer de clarifier.

Il y a une pléthore de solutions de virtualisation, et c'est _normal_ parce qu'elles ont chacune une approche différente, et du coup leurs utilisations différentes aussi:
- uml recompile simplement linux en tant que processus tout à fait ordinaire. Un des défauts est que le noyau guest est exposé à ses processus, ce qui pose des problèmes de sécurité. Il existe un patch pour ajouter au Linux hôte pour permettre à UML d'échapper à ce problème. Ça reste quand même rudement pratique pour faire du développement noyau Linux sans être administrateur système.
- qemu et vmware émulent une machine complète, on peut donc faire tourner n'importe quoi. Les performances peuvent être relativement bonnes grâce à l'utilisation de modules noyau qui permettent de laisser le code tourner en natif la plupart du temps (un while(1); ira donc aussi vite qu'en réel). Par contre, on constate un net ralentissement sur les opérations d'entrées/sorties.
- bochs émule tout et n'a pas d'accélérateur, il va donc plutôt lentement. Mais il a un très bon débogueur
- vserver ne fait pas tourner d'autre noyau, il divise "simplement" l'espace de pid des processus, ce qui permet donc de faire tourner plusieurs distributions avec le même noyau, ce qui permet d'excellentes performances (d'autant plus si l'on partage les fichiers entre les distributions), mais ce noyau étant partagé, s'il foire c'est tout qui foire.
- lguest est une solution voulue comme étant la plus simple possible pour faire de la virtualisation, mais elle est du coup limitée à Linux, et surtout, au même noyau: il n'est pas possible de faire tourner différents noyaux Linux.
- KVM utilise les fonctionnalités de virtualisation des processeurs récents (VMX, SVM, VT-D/I) pour émuler une machine complète de manière plus efficace que qemu et vmware. Pas besoin de rebooter la machine, il suffit de faire modprobe kvm et c'est parti.
- Xen utilise un hyperviseur le plus simple possible, boote ensuite un dom0 (Linux, Solaris ou NetBSD) qui s'occupe de gérer le matériel & co, puis on peut lancer des domU qui peuvent être des OS complètement différents. Si les OS lancés dans les domU sont para-virtualisés (c'est le cas de tous les Linux depuis 2.6.23), on obtient d'excellentes performances: le code s'exécute en natif, les entrées/sorties se font directement en relation avec les drivers dans dom0 (ce qui est éventuellement un tout petit peu plus lent que KVM, mais vraiment très peu). Si les OS lancés dans les domU ne sont pas para-virtualisés, il faut disposer d'une machine avec support VMX, SVM, VT-D/I. Le code s'exécute alors aussi en natif, mais dès qu'il touche au matériel, une exception est levée, et un qemu est utilisé dans dom0 pour émuler ledit matériel (il est en projet d'exécuter ce qemu directement dans un petit domU à côté du domU de l'OS, pour améliorer grandement les performances).

Bref, il y a le choix, et c'est normal: si on peut se permettre d'utiliser exactement le même Linux, lguest va bien. Sinon, il faut au moins KVM. Si on ne veut pas seulement du Linux, Xen est tout à fait logique. Oui, pour Xen il faut rebooter avec un hyperviseur, ce qui peut être embêtant. D'autres trouvent au contraire que c'est un plus: si le Linux du dom0 plante, l'hyperviseur peut éventuellement aider à savoir pourquoi, et ce genre de choses. De plus, en configurant bien, on peut avoir en quelque sorte plusieurs dom0, qui se partagent le support du matériel, des fois qu'un OS (ou même version d'OS) soit meilleur qu'un autre pour supporter telle ou telle carte PCI, et ce pour _aucun_ surcoût par rapport à la situation actuelle, et il n'y a pas besoin d'IOMMU (j'y reviens plus loin). Ce genre de scénario n'est pas du tout prévu par KVM.

> Au niveau serveur, le système vserver s'améliore petit à petit et on va arriver au final à un modèle proche de Xen à mon avis.

Techniquement, pas du tout, ce sont des approches très différentes.

Pour ce qui est des commentaires de Drepper, il faut savoir que c'est un gars qui est assez exclusivement focalisé sur les solutions Linuxo-Linux.

Pour ce qui est de l'intégration de Xen à Linux, elle a besoin de se faire de deux manières:

- domU, i.e. guest, i.e. pour faire tourner une distrib Linux en virtualisé avec un hyperviseur Xen. Ça, c'est intégré sur kernel.org depuis la version 2.6.23, les distribs n'auront plus besoin de s'en soucier.
- dom0, i.e. host, i.e. pour fournir le support d'administration & co de Xen. Ça c'est en cours, et au Xen Summit de cet automne, il en a justement été question.

> Du coup, si tu laisses un OS invité avoir accès au matériel via le BUS PCI, il est possible pour elle de prendre le contrôle de la machine physique !

Oui. Par contre, les constructeurs sont en train de développer des solutions à cela: IOMMU, qui permet d'isoler ce qu'un OS fait avec une carte.

> PPS : qu'on me parle pas de la difficulté d'integration dans le système, un developpeur NetBSD l'a fait tout seul et n'a modifié aucune partie du systeme autre que "arch/sys/xen" (minus les bugs revelés par Xen).

Tout à fait d'accord :)

> En passant, dans l'annonce Cytrix du rachat de XenSource, il y a 10 fois le mot Windows et 0 fois le mot Linux (et évidemment encore moins BSD).

> Il parait que XenSource (ou Cytrix) que se consacre maintenant quasi exclusivement à Windows.

Déjà, on dit "Citrix" ;)

Ensuite, il faut savoir que Citrix est très spécialisé dans la fourniture de solutions windows, ce n'est donc pas étonnant. Maintenant, acheter Xen permet de faire tourner ces windows (ou tout autre OS) sur du matos géré par Linux, ce n'est pas rien.

Maintenant, il est complètement faux que XenSource se consacre quasi exclusivement à Windows, même s'il est vrai que ça fait partie des demandes importantes (pas seulement de Citrix, aussi de la communauté). À noter, je ne me souviens pas avoir rencontré de gens de Microsoft au Xen Summit...

Histoire de résumer un peu la position de XenSource par rapport au libre (évoquée par Ian Pratt au Xen Summit): xen.org (hébergé par XenSource/Citrix) sert de plate-forme pour une communauté libre autour de l'hyperviseur Xen, pas seulement avec Linux, mais aussi avec Solaris, BSD, ou tout autre OS paravirtualisé (il y a des drivers libre pour windows en cours de développement)... Les corrections que XenSource fait en interne pour ses produits sont a priori reversées dans la version libre. Ensuite, chacun peut faire sa tambouille. XenSource, par exemple, produit ce qu'il faut pour une intégration en entreprise: GUI toute jolie pour lancer des domU, etc.

Personne ne l'a relevé, mais

« Il faudra alors que Red Hat et Novell trouvent un arrangement à l'amiable ou alors plus probablement qu'ils montrent que l'invention existait avant le dépôt du brevet. »

Le plus vieux WM que je connaisse implémentant les bureaux virtuels, c'est fvwm, écrit en 1993. Ça ne tient donc pas la route par rapport à un brevet déposé en 1987 et validé en 1991... Sachant les innovations dont Xerox avait fait preuve, ça ne m'étonnerait pas du tout que le brevet soit tout à fait valable en termes de dates d'invention (après, en termes de légitimité comme brevet logiciel ou pas...)

Heu, c'est en cours de soumission à IWOMP2007. Une version quasi-définitive est sur http://dept-info.labri.fr/~thibault/iwomp07.pdf

Heu, ok mais ce qu'on fait avec libgomp, on peut le faire avec n'importe quel autre runtime de compilateur OpenMP... Et via l'interface libpthread, on a déjà fait tourner avec le compilo Sun aussi.

Juste pour être sûr: tu sais qu'on a mis Marcel en-dessous de la libgomp (et ça marche plutôt bien) ?

Mmm, tu parles de MPC ? Il me semble qu'il est prévu qu'elle passe sous licence CeCILL.

Hum, c'est même applicable à l'*Europe*

(Oui, c'est bien possible que ce soit interdit aux US, alors le driver libre n'est-il légal qu'en Europe ?)

On peut faire de l'ingénieurie inverse en examinant le comportement du driver propriétaire.

D'autre part, la décompilation est *autorisée* par la loi française à des fins d'interopérabilité:

http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CE(...)
(voir notament 5.3 et 6)

Il y a bien sûr des restrictions, mais c'est applicable.

Pour ce qui est de la mauvaise qualite' des radios sur le net, c'est de la faute a` tous les acteurs d'internet: si les fournisseurs d'acce`s Internet proposaient le service multicast, les radios pourraient n'envoyer le flux qu'une fois et non pas n fois pour n auditeurs. Et inversement, les radios ne font pas l'effort d'utiliser le service multicast pour leur diffusion parce que les fournisseurs d'acce`s Internet ne le proposent pas (il n'y a gue`re que Renater qui le propose...).

Hey mais d'ailleurs, c'est documente' !
dans les sources brltty, dans Documents/README.OpenBSD
(ok c'est OpenBSD pas FreeBSD, mais c'est la me^me chose ici)

Brltty tourne sur bsd.
Mais en effet, ce qui manque, c'est les pe'riphe'riques /dev/vcs* que linux fournit pour pouvoir lire ce qui est affiche' sur la console (cat /dev/vcs1 pour voir la console 1 par exemple).
La solution est alors de patcher screen: il y a des patch fournis avec brltty. Cela permet a` brltty de lire ce que screen affiche par le screen-driver shm.
Au final, il suffira que tu lance automatiquement screen, et tout faire dedans, pour pouvoir utiliser bsd avec brltty. Apre`s, comment le faire en de'tails, je ne sais pas: je n'ai jamais essaye'. Tu peux demander a` dave@mielke.cc (le mainteneur principal de brltty) les de'tails, et surtout, demande-lui d'e'crire de la doc la`-dessus :)

Effectivement, le niveau n'est pas encore extraordinaire, même si j'ai constaté que le qcm gagne en difficultés d'années en années (on a même de la compil cette année !). Comme en plus c'est *le* concours de sélection aux olympiades internationales où la France pourrait briller, mais ne le fait pas précisément parce que prologin n'est pas encore super connu, et donc les génies de la progs ne peuvent pas y montrer leur museau... Ben il faudrait d'autant plus faire de la pub ! Bon, c'est l'épita, bon, ya des partenaires, etc... Je trouve que cela reste pour autant très discret.

Un serveur web, c'est plutôt facile à faire, tant qu'on reste basique. Là, il supporte qu'une connexion à la fois, ne supporte que les demandes GET toutes bêtes... Mais ça marche avec la plupart des browser que j'ai pu tester (sauf w3m)

> Je croyait que ce projet n'était qu'un vaporeware...

Comment ça ?! C'est pendant la hp-party du 11 novembre que j'ai finalement pensé à en faire un, je l'ai alors codé, et en quelques heures, ça marchait ! Avec Yoann, on a toujours tenu nos promesses...

Bon, le taux de transfert est toujours limité à 600o/s à peu près, quand il fait beau. On peut pas espérer bcp plus, sur une ligne à 9600 bps... Il faudrait par contre que je me décide enfin à faire mon propre gestionnaire d'interruptions !

l'adsl pour Usinagaz ? beuh.... Faudrait déjà un port série un ptit chouia plus rapide pour en profiter ! ;)

Au fait, ça marche tout autant (et même mieux) sur hp48, sauf qu'il y a bcp moins de place pour héberger les pages... Ça marchera aussi un jour sur hp39/40 quand je trouverais le temps de faire une applet

-1 car oui, on s'enlise dans le rien à voir :)

...

http://youpibouh.thefreecat.org/info/prog/4xinet.html(...)

C'est dommage, ma hp49, qui héberge un miroir de ce même site, n'a pas encore d'alimentation secteur, elle est donc rarement allumée :
http://hp4x.residence.ens-lyon.fr(...)