coLinux

"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: cvkqoe$234q$2@nef.ens.fr...

Quelqu'un a essayé Cooperative Linux <URL: http://www.colinux.org/ > ? Ça
donne quoi ?

ça marche très bien. c'est stable, c'est rapide. quasi toutes les
applications tournent. ce n'est pas fait pour toto qui "voudrait apprendre
Linux en cliquant sur tous les boutons de la GUI". c'est GPL.




pour rappel, colinux fournit un noyau Linux (2.4 puis 2.6) qui tourne sous
Windows. si on lui donne un système de fichiers à manger, il se régale : ce
dernier peut être une partition native ou un bête fichier Windows contenant
une image ext2fs, trivial à backuper.

ça tourne sous Windows 2000 et au delà. on lui alloue typiquement 64 ou 128
Mo de RAM, il va tourner là-dedans, et sur du swap si on lui en donne. à
l'usage, ce dernier est souvent peu utilisé sauf si on charge vraiment la
mule. On peut faire tourner plusieurs coLinux en même temps, d'ailleurs. le
réseau marche, aussi, les diverses applications Linux peuvent causer avec le
monde extérieur (donc entre autres ssh, X, vnc, apt-get, Apache ...). ça
tourne aussi sous Linux x86 mais c'est plutot anecdotique ("concurrence" de
UML et autres).


c'est même très stable et très rapide. des monstres comme emerge, OpenOffice
et Oracle marchent dedans, emerge peut y tourner des jours. coLinux est
d'ailleurs souvent compilé dans un coLinux. comme Windows peut cacher de
grosses portions du filesystem dans son cache disque, certaines opérations
se retrouvent beaucoup plus rapide qu'en natif, ça surprend au début.


J'ai personnellement fait tourner les 3 "incarnations" de Debian, des
Gentoo, Fedora, Mandrake, Slackware, Busybox et des bidules sans nom... on
peut se reconstruire des images à l'aide de deboostrap et autres rpm --root,
et chroot marche très bien également.


Ne tournent pas ou pas directement :
* X sur la carte graphique, X exporté et VNC marchent par contre très bien
(donc Gnome/KDE aussi). Cygwin est souvent employé comme serveur X coté
Windows.
* donc exit les gros jeux de poum-poum en 3D. on peut en fait, si, on peut
exporter des applications OpenGL...
* la carte son puisque aussi absente, on peut exporter du son avec ESD ou
autre...
* des modules sont fournis avec coLinux, donc la plupart des installateurs
de distribution Linux couinent puisque les versions ne correspondent pas.
* il n'y a pas de support du framebuffer à l'heure actuelle, bien que des
bouts de code et autres "proof of concept" se promènent.
* il n'y a pas de "suspend to disk" ou de fonction permettant de mettre le
coLinux en pause à la façon d'une machine virtuelle VMWare. ça n'a peut être
pas de sens vu la technologie employée, d'ailleurs. (par contre on l'éteint
"normalement" avec halt, poweroff ou shutdown, et le programme s'arrete,
tout bêtement)


le réseau rame un peu. en fait, si on sature le pont, on peut perdre la
connectivité. on a déjà largement 1 Mo/s, tout de même, ils bossent dessus.
Il peut être délicat à configurer. On peut depuis coLinux accéder à des
fichiers sous Windows, au CD-ROM, monter d'autres disques, ou des images ISO
(ou Samba/NFS/Apache/ftp etc etc etc hébergé sous le Windows).


en terme de projet, je vais vite résumer : l'auteur Dan Aloni planchait sur
UML/win32, quand il a vu une autre voie, qui a donné coLinux. une première
annonce publique a eu lieu début 2004 (et généré une certaine incrédulité
"it's a fake" vu les résultats). sortie de la 0.6.0 en Mars puis de la 0.6.1
en Mai. des images de filesystem Debian Woody et Gentoo "prètes à utiliser"
(enfin, presque) sont proposées aussi.

ensuite grand sommeil apparent pendant plus de 6 mois, des snapshots très
utilisables sont sortis mais pas de release officielle pour SourceForge. de
nouvelles fonctionnalitées apparaissent, mais rien de transcendant. Dan
poursuit quelques autres intérêts, des développeurs viennent aider (la page
correspondante sur le site du projet est obsolète).

début Janvier, réveil brutal et sortie d'une nouvelle version "publique", la
0.6.2, destinée à donner une version récente et utilisables aux morfals de
Sourceforge. une branche 0.7 est dédiée aux nouveaux développements.

par contre, la "doc" est dans un état assez épouvantable, elle se résume en
un wiki peu organisé avec pas mal de HOWTO et trucs et astuces pour faire
marcher les distributions proposées avec ou pour configurer le réseau.

Pour rappel, coLinux ne fournit qu'un noyau, la plupart des questions posées
relèvent de questions génériques Linux ou Unix ("comment se servir de VNC")
ou d'une distribution particulière. Une base de connaissances plus qu'autre
chose, donc. En particulier, le réseau est délicat à configurer. Ca peut
prendre 30 secondes comme 30 heures dans des cas tordus.

Le support passe mieux par un canal IRC et deux MLs (users, developers).

Par rapport à VMWare, il n'y a de support du framebuffer ou "d'émulation
d'un écran", donc lancer coLinux.exe affiche une bête console "type DOS" à
l'écran, pas X dans une fenetre. Forcément, ça trouble toto qui s'attendait
à une GUI, puisqu'il faut taper des commandes et éditer des fichiers ! Dans
le même style, on ne peut pas booter sur un CD d'installation de
Mandrakelinux, à cause d'une vérification des versions des modules par
rapport au noyau (un "sanity check" de l'installateur de Mandrake, tout à
leur honneur).

Les bidouilleurs peuvent passer outre, ou reconstruire le système à coups de
RPMs : j'ai fait ça pour construire une image de Mandrake 10.0, ce n'est pas
difficile et permet de ne pas s'encombrer de paquets inutiles. On peut aussi
copier un système existant dans un filesystem, y compris des LiveCD et
autres Rescue Disk, et court-circuiter ce qui gène.



Bref, tout ça, quoi. Un bagage Unix est nécessaire, mais pas énorme, pas
besoin de recompiler le kernel. Connaitre cd, ls et savoir éditer un
fichier, oui.

Ensuite, ceux qui se demandent à quoi ça peut servir manquent d'imagination.
La réponse est la même que pour VMWare, Cygwin et compagnie. Ceux qui vont
pleurer "ouin ouin à cause de ça les gens ne vont plus vouloir migrer sous
GNU/Linux Desktop" peuvent continuer à se frotter aux arbres vu que ça fait
10 ans que ces mêmes utilisateurs de Windows n'ont pas migré : ce n'est pas
ça qui va les faire encore moins migrer.


Vieille bafouille que j'avais pondu en anglais :

http://wiki.colinux.org/cgi-bin/CoLinuxForDummies

pour les incrédules, je vais renvoyer à IBM qui a joué avec aussi :

http://www-106.ibm.com/developerworks/linux/library/l-colinux/

(Ah, Dan avait reçu une proposition d'emploi de VMWare. Il la garde sous le
coude en continuant ses études)


voila voila...

Olivier Souiry aka Gniarf.

Dans le message <cvlb9m$18nb$1@biggoron.nerim.net>,
Olivier Souiry écrivit...

le
réseau marche, aussi, les diverses applications Linux peuvent causer avec le
monde extérieur (donc entre autres ssh, X, vnc, apt-get, Apache ...).

Bonjour,

comme tu le dis plus loin, la doc étant ce qu'elle est, aurais-tu plus
d'infos pour faire fonctionner la carte 'TAP' sans devoir lui attribuer
l'adresse utilisée par mon routeur ni faire appel à un DHCP? Pour le
moment je reste scotché sur ce pb.

des monstres comme emerge

Hum...

--
Take your marks:
"Gen too three: Emerge!"

"Christophe Garault" <garault@wanadoo.fr> a écrit dans le message de news:
MPG.1c8ad6cc43ff769d9897b8@news.free.fr...

Dans le message <cvlb9m$18nb$1@biggoron.nerim.net>,
Olivier Souiry écrivit...

le réseau marche, aussi, les diverses applications Linux peuvent causer
avec le monde extérieur (donc entre autres ssh, X, vnc, apt-get, Apache
...).

Bonjour,

comme tu le dis plus loin, la doc étant ce qu'elle est, aurais-tu plus
d'infos pour faire fonctionner la carte 'TAP' sans devoir lui attribuer
l'adresse utilisée par mon routeur ni faire appel à un DHCP? Pour le
moment je reste scotché sur ce pb.

alors, il y a plusieurs façons de faire, j'ai eu la chance de tomber sur un
cas simple. si dans ta configuration, 192.168.0.1 est déja utilisé, ce qui
suit ne s'applique pas.


dans le cas de figure suivant :

j'utilise Windows 2k, je suis en ADSL avec pppoe (pour expliquer le dessin)
, j'utilise bêtement le partage de connexion de Windows 2000 fourni de base
dedans, je "partage" la connexion existante :

http://gniarf.nerim.net/colinux/network1.gif

http://gniarf.nerim.net/colinux/network2.gif


bon, la blague est que le clickodrome de Microsoft ne permet pas de choisir
à l'avance le périphérique qui recevra la connexion partagée (TAP pour
coLinux, donc), mais il viendra le demander la première fois que coLinux
sera lancé (avec <network index="0" type="tap"></network> par exemple).

La principale limite à cette solution simple et rapide du "Partage de
connexion" (et explicitement "à deux balles" car c'est sa portée) est que
Windows va systématiquement attribuer l'ip 192.168.0.1 à ce périphérique.
192.168.0.1 sera l'adresse de Windows, vu depuis coLinux (qui lui même
trônera sur une ip du genre 192.168.0.40, on lui en donne une fixe ou le
DHCP de Windows lui en donne une).

ça peut clairement entrer en conflit avec des adresses déjà existantes dans
des tas de situations, j'en conviens, on peut faire autrement mais je n'ai
pas eu à m'y frotter. d'autres personnes utilisent WinPcap, parlent de
bridging, j'ai fui en courant : le réseau niveau routages n'est pas plus que
ça ma tasse de thé, sans même parler de Windows XP dont les clickodromes
sont subtilement différents.

des monstres comme emerge

Hum...

bah, je considère qu'un "émulateur" (au sens très très large) qui tient
encore debout après avoir emergé perl, X, kde, firefox, peut être qualifié
de stable. c'est comme pouvoir faire tourner Oracle ou OpenOffice sans
qu'ils explosent, c'est un testament de stabilité.

je dirais bien des choses à propos d'applications codées et packagées avec
les pieds et qui plantent à répétition avec X en remote ou VNC, mais bref.


O. Souiry


pour la technique, FU2 sur fr.comp.os.linux.configuration