TacticalWiki

InteroperabilityTactics

HomePage :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes 38.107.191.85

Interoperability Tactics


Nous sommes tous d'accord sur le fait qu'il existe dans le monde plusieurs systèmes d'exploitation de qualités diverses, et qui ont chacun leurs avantages et leurs inconvénients. Je ne suis pas là pour débattre de ces points, mais pour tenter de résoudre les problèmes découlant de la volonté d'utiliser couramment plusieurs des systèmes en question. Et faire de grandes phrases.

Le coeur du problème consiste à utiliser un programme compilé pour un système A à partir d'une machine sur laquelle tourne un système B. Le système A est alors dit virtuel, tandis que le système B est l'hôte. On dispose pour cela de plusieurs solutions.

Emulation logicielle


Les exécutables sont directement utilisés sur le système hôte via une réimplémentation des API du système virtuel. C'est le principe de Wine et de son fork commercial spécialisé dans les jeux, WineX, qui implémente DirectX. On peut également citer DOSEMU. D'autres émulateurs comme Plex86 et Usermode Linux, permettent de faire tourner un linux virtuel sur un linux réel; mais on s'écarte ici légèrement du sujet, car il s'agit de "nesting", le système hôte et le virtuel étant nécessairement les mêmes.

Cette approche est limitée a un même type de hardware : vous ne verrez pas d'implémentation de l'API MacOS sur PC, puisque les codes binaires du Macintosh et des machines Intel sont incompatibles entre eux.

Avantage principal : vitesse relativement proche de celle du système natif (puisque l'essentiel du code binaire est exécuté directement).

Emulation matérielle


Le système virtuel tourne nativement dans une machine émulée logiciellement. L'émulateur matériel prend en charge toutes les entrées / sorties vers les différents périphériques, ce qui permet par exemple d'émuler un disque dur à l'aide d'un simple fichier, ou d'associer un lecteur CD virtuel à son homologue physique. L'émulation matérielle est un excellent moyen d'isoler un programme viral pour l'étudier, ou encore de débugger un système d'exploitation. VMware et Virtual PC sont deux alternatives commerciales. Il existe bien évidemment des solutions libres telles que Bochs ou le très véloce QEmu, sérieux concurrent pour VMware à mon goût.

En particulier pour faire tourner les vieux jeux DOS, on mentionnera Dosbox, disponible sur de nombreuses plateformes, qui embarque d'origine un système compatible DOS minimal (pas besoin d'installation) et permet de monter à la volée des répertoires de l'hôte en tant que lecteurs de disques pour la machine virtuelle; très pratique pour le transfert de fichiers, mais pas question d'examiner des virii dans ces conditions...

Cette solution est généralement plus lourde en termes de consommation de ressources et d'usage CPU (puisqu'il faut traduire les instructions d'un hardware vers celui d'un autre, que ce soit dynamiquement ou statiquement). Le logiciel ne pourra jamais travailler aussi rapidement que le matériel (contemporain, bien entendu). Le procédé présente cependant une fiabilité difficile à retrouver dans des systèmes comme Wine, basés sur le reverse-engineering.

Zéro émulation


Alors comment fait-on? On garde une machine dédiée à faire tourner chaque système, le tout reste d'y accéder. La manière la plus simple reste le switch permettant de partager écran / souris / clavier entre plusieurs bécanes. Moins rudimentaire, la prise à distance par le réseau est également plus souple. Entre plusieurs plateformes UNIX, X et ses différentes implémentations (XFree86, Xouvert, Y windows...) fournissent une solution naturelle et transparente. Dans le cas de plateformes plus différentes, VNC est une excellente alternative dotée d'implémentations tout aussi excellentes (RealVNC, TightVNC).

N'oublions pas que les moyens de stockage doivent être uniformément accessibles par le réseau grâce à des protocoles comme Samba ou NFS, d'où une certaine lenteur à ce niveau, et le besoin de bien penser l'organisation de l'ensemble.

De plus, on s'aperçoit que les performances gagnées par l'exécution de code dans son environnement natif sont généralement perdues en ergonomie et en latence réseau; pour bien fonctionner, ce procédé d'interopérabilité requiert quasiment un réseau dédié. Un écran en 1024x768 affiché à un taux de 25 images par secondes utilise une bande passante brute de 18.75 Mo/s, sans compter l'overhead. On explose déjà Fast Ethernet. L'autre problème majeur réside dans l'affichage de surfaces superposées (clips vidéo, affichages accélérés...) généralement difficiles ou impossibles à capturer, car les logiciels de prise de contrôle à distance ne sont pas vraiment censés interagir avec le pilote de la carte graphique.

Conclusion


Chacune des solutions présentées trouve généralement ses limites lorsque l'on cherche à en tirer un peu trop de performances. L'émulation matérielle permet aujourd'hui d'émuler honorablement un système vieux de 8 à 10 ans. L'émulation logicielle s'en sortirait plutôt avec 4 ou 5 ans. La prise de contrôle permet d'accéder aux systèmes actuels, mais est fortement bridée par les technologies réseau.

La solution adéquate dépend, comme toujours, du problème précis que l'on se pose. Si votre souci est de faire tourner une application de gestion sous Windows XP et que vous disposez d'une machine de rab, VNC est la solution est toute trouvée. Si en revanche vous cherchez à faire tourner un ancien jeu DOS peu gourmand, mais qui nécessite un brin de réactivité, les machines virtuelles, simulateurs et autres émulateurs restent d'excellents substituts.
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]