Bonjour à tous,
Depuis quelques temps, je fatigue à la simple idée de mettre en prod le code scientifique que nous (l'équipe à laquelle j'appartiens) développons...
Je suis maintenant certain que nos clients se concertent dans notre dos pour nous présenter l'hétérogénéité la plus indescriptible de plateformes Unix (si, si, j'en suis sûr).
Et comme se sont des gentils clients, bein on s'écrase et on compile, recompile, valide, revalide, etc...
Tout ça pour dire, que je m'intéresse à la distribution via coLinux, c'est à dire en distribuant des images de serveurs linux virtuels embarquant notre code. Les conséquences en vrac:
- fini la validation / compilation sur 50 plateformes et versions d'OS
- fini les prises de têtes infinies pour avoir un code (f95) portable sur tous les compilateurs possibles (même si cela présente un intérêt pour le nettoyage du code)
- fini les notices d'installation de 300 pages pour répondre à toutes les questions incroyable qu'un cerveau d'admin unix peut se poser au lieu de faire le simple "tar zxvf" qu'on lui prescrit (petit troll de printemps ;o)
- limitation de la perte de puissance due à l'émulation (par rapport à qEmu ou VMWare par ex.)
- augmentation du nombre de processeurs disponibles (toutes les machines bureautique windows > 2K sont éligibles pour héberger un serveur virtuel)
- annulation des risques de conflits entre différents codes, puisque seul notre code est installé sur l'image virtuelle
- sauvegarde des versions anciennes des codes immédiate : archivage de l'image virtuelle
- gestion ri-gou-reu-se des droits des utilisateurs du code (fini les chmod -R 777 sur le rep d'install "pour que ça tourne")
- notre vie risquerai de devenir ennuyeuse de simplicité...
- limitation des investissements nécessaire pour nos clients (du genre pSeries à 50 k¤ pour 4 malheureux processeurs)
- création très rapide de l'image pour chaque version du code (merci apt-get)
Enfin bref, pas mal d'avantages pour cette solution. Mais comme je ne suis qu'en phase de faisabilité, je me pose quelques questions:
1. Qu'en est il des contraintes juridiques pour diffuser une image linux (GPL) embarquant notre code (proprio) ?
Y a t il des précautions particulières à respecter, des impossibilités juridiques, ou que sais-je encore ?
2. Quelqu'un a t il déjà fait ce genre de choses industriellement pour un code scientifique ?
j'ai juste trouvé ça pour l'instant:
- un papier IBM: http://www-128.ibm.com/developerworks/linux/library/l-colinu(...)
- une société: http://www.rocketcalc.com/vct/
- le projet HARPY: http://www2.informatik.uni-jena.de/~ckauhaus/2005/harpy.pdf
Juste pour le curieux, j'ai adapté une image linux (basé sur une ubuntu 5.10) installé mon code et paramétré un windows en NAT+Port Forwarding en quelques heures ! C'est déconcertant de facilité, et l'intégration dans windows sous forme de service est vraiement pratique.
# Quid des plateformes supportés ?
Posté par Geo Vah . Évalué à 2.
Pourquoi en faire une image coLinux si c'est pour etre dispo uniquement sur ces plateformes ? i386+win ou linux, c'est très réduits ?
[^] # Re: Quid des plateformes supportés ?
Posté par yaya . Évalué à 1.
En fait, j'utilise la puissance résiduelle des machines bureautique windows pour faire du calcul. Ca permet de multiplier le nombre de CPU disponibles pour le calcul sans coût supplémentaire.
C'est très intéressant notamment pour faire du calcul paramétrique distribué.
[^] # Re: Quid des plateformes supportés ?
Posté par Geo Vah . Évalué à 1.
Ma remarque faisait suite à :
Donc clair que si tu n'as que du i386 sur windows ou linux...
Cependant, fais attention à des bugs qui pourrait etre trouvé dans coLinux chez tes clients... Attends toi à p-e de la maintenance et à participer à ce projet...
[^] # Re: Quid des plateformes supportés ?
Posté par Gniarf . Évalué à 1.
un plantage "normal" de colinux est récupérable sans problème si l'image est en ext3fs, un plantage (BSOD ou redémarrage) de Windows peut corrompre l'image colinux si elle était ouverte. il faut prévoir de quoi la remplacer à distance, son état pourra être déterminé par les logs que l'application t'enverra.
on peut rendre coLinux discret en utilisant les services pour le démarrer, au démarrage du Windows ou à distance, sans qu'apparaisse aucune fenêtre moche. en lui donnant une priorité plus faible que les autres applications Windows ("below normal" aka "inférieure à la normale"), l'utilisateur n'est absolument pas géné dans son utilisation de Windows même pour des applications intensives (comportement constaté avec emerge et compilations sous Gentoo)
ensuite coLinux a un petit problème de performance niveau réseau, mais niveau stabilité et performances générales (cpu, accès fichiers), aucun problème.
# Euh ?
Posté par Gavroche LeGnou . Évalué à -1.
Mais , pourquoi vous faites pas du Java ?
{ / troll }
# reponse
Posté par Anonyme . Évalué à 0.
bon pour eviter que des boulets te dise :ON veut les sources vu que c'est sous linux.
lit plusieurs fois la GPL, (c'est lisible) et fait un fiche explicative de ce que contient ton CD. Linux =GPL Monlogiciel=Licensespecifique, avec un exemple: oracle est disponible sous linux, et non vous ne pouvez pas avoir les sources d'oracle, Maya est disponible sous linux la non plus pas de sources de Maya, archicad est disponible sous linux, la non plus pas de source. Mon logiciel en F95 est disponible sous linux, pas de source disponible. Ce n'est pas obligatoire. Par contre voici un CD avec les sources de linux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.