alors, sur un Windows 2000 avec un AMD 1800+ et 512 Mo de RAM et bien configuré (plupart des bouffe-RAM et autres services inutiles désactivés, stabilité réglée depuis longtemps), j'ai déjà lancé des opérations lourdes dans mes images coLinux dont des emerge world qui prennent plusieurs heures en secouant le système Linux dans tous les sens. tout en utilisant le Windows par ailleurs (Opera avec 150 onglets, un serveur web pour des images à la con, client web, client irc, etc, etc). en une autre occasion, j'ai démarré Oracle dedans.
et elle survit très bien. j'estime qu'on peut dire que la stabilité et la survie du système sous coLinux dépend de celle de Windows. moi et d'autres personnes ont cité des uptime de trois jours et plus, et les arretent pour en faire des sauvegardes (un bete fichier) ou pour jouer sous Windows... d'autres ont cité des uptimes bien plus longs (utilisation "serveur") mais je n'ai pas de chiffres dessus.
je n'ai pas utilisé ReiserFS avec, uniquement ext3fs. j'alloue en général 128 Mo au sous-système colinux, mais j'utilise des clients X divers et VNC par exemple, on peut se contenter de 64 une fois l'installation terminée. l'utilisation d'un fichier de swap à coté est possible.
en terme de performances, le système de cache disque de Windows fait qu'une partie de l'image du filesystem sera cachée en RAM et qu'on aura de très bonnes surprises à ce niveau. affecter une priorité basse (au sens Windows) au coLinux suffira à laisser de bonnes performances aux applications Windows en toutes circonstances.
au niveau réseau, outre qu'il est pas forcément facile à configurer du coté Windows pour des gens qui n'y connaissent rien, en particulier pour un réseau local, il pourra constituer le goulet d'étranglement en terme de performances. les gens râlent à ce sujet sur les mailing lists, à relativiser avec les besoins qu'on a, bien sûr. un wget sur un serveur web sur la même machine (coté windows) me donne dans les 500 kb/s, de tête. donc loin d'une vraie carte réseau.
sur un système FAT32, les fichiers des filesystem coLinux sont limités à 4 Go, sur du NTFS, il n'y a pas cette limitation, il y a des images de 10 Go.
concernant le thread à coté ("numéro de version inférieur à 1.0 donc pas en production"), pas grand chose à dire de plus : utiliser une machine de test se rapprochant le plus possible de la machine de production, et tester dessus en abusant de la pauvre bête comme le dernier des gorets. parce qu'indépendement de coLinux, on peut avoir tout plein de choses à coté qui peuvent faire flancher l'ensemble, dont certains utilitaires systèmes chatouilleux, ou des gags comme le SP2 de Windows XP.
outre les versions "officielles" de coLinux qu'on peut trouver sur la page du site sur SourceForge, il y a aussi des snapshots "officieux" dont certains sont "parfaits" (rien à signaler dessus) et d'autres moins (des gens se plaignent de X ou Y dessus sur les mailing lists). j'utilise un snapshoot 0622 depuis des mois et j'en suis ravi.
bref. suivant le niveau de criticabilité du système, ça peut être envisageable. les performances réseaux peuvent être décevantes, ou pas. et avoir le nom d'une solution ne dispensera pas des efforts potentiellement laborieux pour la mettre en oeuvre si on choisit de la tester.
# stabilité et autres infos techniques
Posté par Gniarf . En réponse au message Stabilité CoLinux. Évalué à 5.
et elle survit très bien. j'estime qu'on peut dire que la stabilité et la survie du système sous coLinux dépend de celle de Windows. moi et d'autres personnes ont cité des uptime de trois jours et plus, et les arretent pour en faire des sauvegardes (un bete fichier) ou pour jouer sous Windows... d'autres ont cité des uptimes bien plus longs (utilisation "serveur") mais je n'ai pas de chiffres dessus.
je n'ai pas utilisé ReiserFS avec, uniquement ext3fs. j'alloue en général 128 Mo au sous-système colinux, mais j'utilise des clients X divers et VNC par exemple, on peut se contenter de 64 une fois l'installation terminée. l'utilisation d'un fichier de swap à coté est possible.
en terme de performances, le système de cache disque de Windows fait qu'une partie de l'image du filesystem sera cachée en RAM et qu'on aura de très bonnes surprises à ce niveau. affecter une priorité basse (au sens Windows) au coLinux suffira à laisser de bonnes performances aux applications Windows en toutes circonstances.
au niveau réseau, outre qu'il est pas forcément facile à configurer du coté Windows pour des gens qui n'y connaissent rien, en particulier pour un réseau local, il pourra constituer le goulet d'étranglement en terme de performances. les gens râlent à ce sujet sur les mailing lists, à relativiser avec les besoins qu'on a, bien sûr. un wget sur un serveur web sur la même machine (coté windows) me donne dans les 500 kb/s, de tête. donc loin d'une vraie carte réseau.
sur un système FAT32, les fichiers des filesystem coLinux sont limités à 4 Go, sur du NTFS, il n'y a pas cette limitation, il y a des images de 10 Go.
concernant le thread à coté ("numéro de version inférieur à 1.0 donc pas en production"), pas grand chose à dire de plus : utiliser une machine de test se rapprochant le plus possible de la machine de production, et tester dessus en abusant de la pauvre bête comme le dernier des gorets. parce qu'indépendement de coLinux, on peut avoir tout plein de choses à coté qui peuvent faire flancher l'ensemble, dont certains utilitaires systèmes chatouilleux, ou des gags comme le SP2 de Windows XP.
outre les versions "officielles" de coLinux qu'on peut trouver sur la page du site sur SourceForge, il y a aussi des snapshots "officieux" dont certains sont "parfaits" (rien à signaler dessus) et d'autres moins (des gens se plaignent de X ou Y dessus sur les mailing lists). j'utilise un snapshoot 0622 depuis des mois et j'en suis ravi.
bref. suivant le niveau de criticabilité du système, ça peut être envisageable. les performances réseaux peuvent être décevantes, ou pas. et avoir le nom d'une solution ne dispensera pas des efforts potentiellement laborieux pour la mettre en oeuvre si on choisit de la tester.