Ce qui est amusant, c'est de lire que FreeBSD est censé souffrir des mêmes problèmes, à tel point qu'il a forké un successeur... Au détail près, AMHA, que le projet FreeBSD reste tout de même assez dynamique, contrairement à DragonFly qui avance à une vitesse d'escargot parce que son dictateur bénévole et quasi seul développeur n'est pas superman...
Bah, je pense ne pas etre le seul a etre surpris que DragonFlyBSD tienne aussi bien le coup, je ne pensais pas qu'il arriverait a exister, en fait, malgre la haute estime en laquelle je tiens Matt Dillon.
Il faut peut-etre lui laisser du temps.
Oh mais je ne critique pas DragonFly. D'ailleurs, si on en croit leur site web, mon "quasi seul développeur" était particulièrement injuste ; il semblerait que le nombre de commiters est en train de prendre de l'ampleur, ce qui ne peut être qu'une bonne chose.
C'est simplement la manière dont le rapport Free / DragonFly est abordée qui m'a fait tiquer.
Fred -- Petite soeur de mes nuits Ca m'a manqué tout ça Quand tu sauvais la face A bien d'autres que moi Sache que je n'oublie rien mais qu'on efface A ton étoile (Noir Désir, A ton étoile)
In article <1buhizz0kzr9u.dlg@tamnavulin.lacave.local>,
F. Senault <fred@lacave.net> wrote:
Ce qui est amusant, c'est de lire que FreeBSD est censé souffrir des
mêmes problèmes, à tel point qu'il a forké un successeur... Au détail
près, AMHA, que le projet FreeBSD reste tout de même assez dynamique,
contrairement à DragonFly qui avance à une vitesse d'escargot parce que
son dictateur bénévole et quasi seul développeur n'est pas superman...
Bah, je pense ne pas etre le seul a etre surpris que DragonFlyBSD tienne
aussi bien le coup, je ne pensais pas qu'il arriverait a exister, en
fait, malgre la haute estime en laquelle je tiens Matt Dillon.
Il faut peut-etre lui laisser du temps.
Oh mais je ne critique pas DragonFly. D'ailleurs, si on en croit leur
site web, mon "quasi seul développeur" était particulièrement injuste ;
il semblerait que le nombre de commiters est en train de prendre de
l'ampleur, ce qui ne peut être qu'une bonne chose.
C'est simplement la manière dont le rapport Free / DragonFly est abordée
qui m'a fait tiquer.
Fred
--
Petite soeur de mes nuits Ca m'a manqué tout ça
Quand tu sauvais la face A bien d'autres que moi
Sache que je n'oublie rien mais qu'on efface
A ton étoile (Noir Désir, A ton étoile)
Ce qui est amusant, c'est de lire que FreeBSD est censé souffrir des mêmes problèmes, à tel point qu'il a forké un successeur... Au détail près, AMHA, que le projet FreeBSD reste tout de même assez dynamique, contrairement à DragonFly qui avance à une vitesse d'escargot parce que son dictateur bénévole et quasi seul développeur n'est pas superman...
Bah, je pense ne pas etre le seul a etre surpris que DragonFlyBSD tienne aussi bien le coup, je ne pensais pas qu'il arriverait a exister, en fait, malgre la haute estime en laquelle je tiens Matt Dillon.
Il faut peut-etre lui laisser du temps.
Oh mais je ne critique pas DragonFly. D'ailleurs, si on en croit leur site web, mon "quasi seul développeur" était particulièrement injuste ; il semblerait que le nombre de commiters est en train de prendre de l'ampleur, ce qui ne peut être qu'une bonne chose.
C'est simplement la manière dont le rapport Free / DragonFly est abordée qui m'a fait tiquer.
Fred -- Petite soeur de mes nuits Ca m'a manqué tout ça Quand tu sauvais la face A bien d'autres que moi Sache que je n'oublie rien mais qu'on efface A ton étoile (Noir Désir, A ton étoile)
manu
F. Senault wrote:
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs) pour en faire quelque chose d'utile ! :)
Utile? Tu veux te chauffer à l'informatique?
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
F. Senault <fred@lacave.net> wrote:
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes
que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs)
pour en faire quelque chose d'utile ! :)
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs) pour en faire quelque chose d'utile ! :)
Utile? Tu veux te chauffer à l'informatique?
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
manu
Marc Espie wrote:
Rappelons quand meme qu'au moins un autre enorme gros projet fonctionne de la meme facon: le projet GNU. Pour toute contribution depassant dix lignes a, au hasard, binutils, gcc, et autre coreutils, il faut signer un papier qui laisse l'integralite des droits a la FSF...
Et c'est quand même nettement plus violent que le developer agreement de la fondation NetBSD.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Marc Espie <espie@lain.home> wrote:
Rappelons quand meme qu'au moins un autre enorme gros projet fonctionne
de la meme facon: le projet GNU. Pour toute contribution depassant dix
lignes a, au hasard, binutils, gcc, et autre coreutils, il faut signer
un papier qui laisse l'integralite des droits a la FSF...
Et c'est quand même nettement plus violent que le developer agreement de
la fondation NetBSD.
Rappelons quand meme qu'au moins un autre enorme gros projet fonctionne de la meme facon: le projet GNU. Pour toute contribution depassant dix lignes a, au hasard, binutils, gcc, et autre coreutils, il faut signer un papier qui laisse l'integralite des droits a la FSF...
Et c'est quand même nettement plus violent que le developer agreement de la fondation NetBSD.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Francois Tigeot
Michel Talon wrote:
Francois Tigeot wrote:
On verra si ça se fait ou pas avec Dragonfly, mais dans la mesure où ce genre de chose existait il y a 20 ans, je ne vois pas où est le fantasme là-dedans.
Ce genre de chose existait il y a 20 ans parceque le VAX était d'une lenteur phénoménale, et qu'on cherchait tous les moyens pour tirer un peu de performance à n'importe quel coût. En ce moment toutes les machines vont être biprocs, l'an prochain quadriprocs, le Niagara a 32 procs virtuels, bref, on peut avoir toute la puissance qu'on veut pour pas cher sans aller chercher ces vieilles lunes comme le clustering - sauf dans les domaines où on a toujours besoin de la puissance ultime comme certains calculs scientifiques. Bon c'est très possible que je me trompe complètement, mais à mon avis, le but que vise Dillon, dans le contexte actuel, et avec l'accés qu'il ne peut pas avoir aux organisations assez riches pour utiliser des clusters, me semble complètement farfelu. Comme quelqu'un le remarquait, il y a déjà eu par exemple Amoeba dans cet esprit, pour quel impact? absolument nul.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Un cluster à la VAXclusters peut très bien servir pour des applications plus classique (serveurs web, bases de données, mail, ...) et surtout permettrait d'avoir une tolérance aux pannes matérielles assez phénoménale.
Si Amoeba n'a pas percé, ce n'était pas amha pour des raisons techniques; j'en retiens que la license était très restrictive lorsque le projet était en plein développement.
Pour en revenir à Dragonfly, ça m'arrangerait bien de pouvoir augmenter les performances d'un site web juste en "branchant" une machine supplémentaire dans le cluster ou avoir un service mail toujours disponible même si la moitié des serveurs sont en train de brûler dans un incendie.
Deux petits liens pour voir ce qu'il est possible de faire: http://www.drj.com/drworld/content/w4_126.htm http://www.enterpriseitplanet.com/storage/features/article.php/3396941
On verra si ça se fait ou pas avec Dragonfly, mais dans la mesure où ce
genre de chose existait il y a 20 ans, je ne vois pas où est le fantasme
là-dedans.
Ce genre de chose existait il y a 20 ans parceque le VAX était d'une lenteur
phénoménale, et qu'on cherchait tous les moyens pour tirer un peu de
performance à n'importe quel coût. En ce moment toutes les machines vont être
biprocs, l'an prochain quadriprocs, le Niagara a 32 procs virtuels, bref, on
peut avoir toute la puissance qu'on veut pour pas cher sans aller chercher ces
vieilles lunes comme le clustering - sauf dans les domaines où on a toujours
besoin de la puissance ultime comme certains calculs scientifiques. Bon c'est
très possible que je me trompe complètement, mais à mon avis, le but que vise
Dillon, dans le contexte actuel, et avec l'accés qu'il ne peut pas avoir aux
organisations assez riches pour utiliser des clusters, me semble complètement
farfelu. Comme quelqu'un le remarquait, il y a déjà eu par exemple Amoeba
dans cet esprit, pour quel impact? absolument nul.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Un cluster à la VAXclusters peut très bien servir pour des applications
plus classique (serveurs web, bases de données, mail, ...) et surtout
permettrait d'avoir une tolérance aux pannes matérielles assez
phénoménale.
Si Amoeba n'a pas percé, ce n'était pas amha pour des raisons techniques;
j'en retiens que la license était très restrictive lorsque le projet était
en plein développement.
Pour en revenir à Dragonfly, ça m'arrangerait bien de pouvoir augmenter
les performances d'un site web juste en "branchant" une machine
supplémentaire dans le cluster ou avoir un service mail toujours
disponible même si la moitié des serveurs sont en train de brûler dans un
incendie.
Deux petits liens pour voir ce qu'il est possible de faire:
http://www.drj.com/drworld/content/w4_126.htm
http://www.enterpriseitplanet.com/storage/features/article.php/3396941
On verra si ça se fait ou pas avec Dragonfly, mais dans la mesure où ce genre de chose existait il y a 20 ans, je ne vois pas où est le fantasme là-dedans.
Ce genre de chose existait il y a 20 ans parceque le VAX était d'une lenteur phénoménale, et qu'on cherchait tous les moyens pour tirer un peu de performance à n'importe quel coût. En ce moment toutes les machines vont être biprocs, l'an prochain quadriprocs, le Niagara a 32 procs virtuels, bref, on peut avoir toute la puissance qu'on veut pour pas cher sans aller chercher ces vieilles lunes comme le clustering - sauf dans les domaines où on a toujours besoin de la puissance ultime comme certains calculs scientifiques. Bon c'est très possible que je me trompe complètement, mais à mon avis, le but que vise Dillon, dans le contexte actuel, et avec l'accés qu'il ne peut pas avoir aux organisations assez riches pour utiliser des clusters, me semble complètement farfelu. Comme quelqu'un le remarquait, il y a déjà eu par exemple Amoeba dans cet esprit, pour quel impact? absolument nul.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Un cluster à la VAXclusters peut très bien servir pour des applications plus classique (serveurs web, bases de données, mail, ...) et surtout permettrait d'avoir une tolérance aux pannes matérielles assez phénoménale.
Si Amoeba n'a pas percé, ce n'était pas amha pour des raisons techniques; j'en retiens que la license était très restrictive lorsque le projet était en plein développement.
Pour en revenir à Dragonfly, ça m'arrangerait bien de pouvoir augmenter les performances d'un site web juste en "branchant" une machine supplémentaire dans le cluster ou avoir un service mail toujours disponible même si la moitié des serveurs sont en train de brûler dans un incendie.
Deux petits liens pour voir ce qu'il est possible de faire: http://www.drj.com/drworld/content/w4_126.htm http://www.enterpriseitplanet.com/storage/features/article.php/3396941
-- Francois Tigeot
talon
Emmanuel Dreyfus wrote:
Marc Espie wrote:
Rappelons quand meme qu'au moins un autre enorme gros projet fonctionne de la meme facon: le projet GNU. Pour toute contribution depassant dix lignes a, au hasard, binutils, gcc, et autre coreutils, il faut signer un papier qui laisse l'integralite des droits a la FSF...
Et c'est quand même nettement plus violent que le developer agreement de la fondation NetBSD.
Est-ce que tu crois vraiment que c'est le fond du problème soulevé par Charles Hannum pour NetBSD ou Matthew Garrett pour Debian? Le problème c'est le manque de leadership des institutions fondées sur la "démocratie", la tendance naturelle dans ces institutions à couper toutes les têtes qui dépassent, et à ce que le pouvoir aille aux plus médiocres. Tu en as des exemples partout autour de toi, regarde un certain parti politique de gauche par exemple. La fondation GNU marche grace à l'autorité de Stallmann, Linux marche grace à l'autorité de Linus, pas une société commerciale "autogérée" n'arrive à marcher, c'est la recette de la faillite assurée.
--
Michel TALON
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Marc Espie <espie@lain.home> wrote:
Rappelons quand meme qu'au moins un autre enorme gros projet fonctionne
de la meme facon: le projet GNU. Pour toute contribution depassant dix
lignes a, au hasard, binutils, gcc, et autre coreutils, il faut signer
un papier qui laisse l'integralite des droits a la FSF...
Et c'est quand même nettement plus violent que le developer agreement de
la fondation NetBSD.
Est-ce que tu crois vraiment que c'est le fond du problème soulevé par
Charles Hannum pour NetBSD ou Matthew Garrett pour Debian? Le problème c'est
le manque de leadership des institutions fondées sur la "démocratie", la
tendance naturelle dans ces institutions à couper toutes les têtes qui
dépassent, et à ce que le pouvoir aille aux plus médiocres. Tu en as des
exemples partout autour de toi, regarde un certain parti politique de gauche
par exemple. La fondation GNU marche grace à l'autorité de Stallmann, Linux
marche grace à l'autorité de Linus, pas une société commerciale "autogérée"
n'arrive à marcher, c'est la recette de la faillite assurée.
Rappelons quand meme qu'au moins un autre enorme gros projet fonctionne de la meme facon: le projet GNU. Pour toute contribution depassant dix lignes a, au hasard, binutils, gcc, et autre coreutils, il faut signer un papier qui laisse l'integralite des droits a la FSF...
Et c'est quand même nettement plus violent que le developer agreement de la fondation NetBSD.
Est-ce que tu crois vraiment que c'est le fond du problème soulevé par Charles Hannum pour NetBSD ou Matthew Garrett pour Debian? Le problème c'est le manque de leadership des institutions fondées sur la "démocratie", la tendance naturelle dans ces institutions à couper toutes les têtes qui dépassent, et à ce que le pouvoir aille aux plus médiocres. Tu en as des exemples partout autour de toi, regarde un certain parti politique de gauche par exemple. La fondation GNU marche grace à l'autorité de Stallmann, Linux marche grace à l'autorité de Linus, pas une société commerciale "autogérée" n'arrive à marcher, c'est la recette de la faillite assurée.
--
Michel TALON
talon
Francois Tigeot wrote:
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des situations où on empile le matos, utilisé à 10% pour que l'admin sys puisse faire voir qu'il en a une plus grosse que son voisin.
Un cluster à la VAXclusters peut très bien servir pour des applications plus classique (serveurs web, bases de données, mail, ...) et surtout permettrait d'avoir une tolérance aux pannes matérielles assez phénoménale.
Et pourquoi pas un mainframe tant que tu y es?
Pour en revenir à Dragonfly, ça m'arrangerait bien de pouvoir augmenter les performances d'un site web juste en "branchant" une machine supplémentaire dans le cluster ou avoir un service mail toujours
Parceque ça n'existe pas déjà les "load balancers", etc. pour ce genre d'application? Sans parler du CARP de OpenBSD et autres bidules pour pallier les pannes.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des
situations où on empile le matos, utilisé à 10% pour que l'admin sys
puisse faire voir qu'il en a une plus grosse que son voisin.
Un cluster à la VAXclusters peut très bien servir pour des applications
plus classique (serveurs web, bases de données, mail, ...) et surtout
permettrait d'avoir une tolérance aux pannes matérielles assez
phénoménale.
Et pourquoi pas un mainframe tant que tu y es?
Pour en revenir à Dragonfly, ça m'arrangerait bien de pouvoir augmenter
les performances d'un site web juste en "branchant" une machine
supplémentaire dans le cluster ou avoir un service mail toujours
Parceque ça n'existe pas déjà les "load balancers", etc. pour ce genre
d'application? Sans parler du CARP de OpenBSD et autres bidules pour pallier
les pannes.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des situations où on empile le matos, utilisé à 10% pour que l'admin sys puisse faire voir qu'il en a une plus grosse que son voisin.
Un cluster à la VAXclusters peut très bien servir pour des applications plus classique (serveurs web, bases de données, mail, ...) et surtout permettrait d'avoir une tolérance aux pannes matérielles assez phénoménale.
Et pourquoi pas un mainframe tant que tu y es?
Pour en revenir à Dragonfly, ça m'arrangerait bien de pouvoir augmenter les performances d'un site web juste en "branchant" une machine supplémentaire dans le cluster ou avoir un service mail toujours
Parceque ça n'existe pas déjà les "load balancers", etc. pour ce genre d'application? Sans parler du CARP de OpenBSD et autres bidules pour pallier les pannes.
--
Michel TALON
talon
F. Senault wrote:
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs) pour en faire quelque chose d'utile ! :)
Et bien entendu, la facture d'électricité, le bruit, le prix du mètre carré pour loger ces saloperies, tu t'asseois dessus. A l'heure actuelle, la notion de cluster n'a guère d'intérêt économique - ce qui veut dire sauf pour les institutions riches.
Fred
F. Senault <fred@lacave.net> wrote:
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes
que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs)
pour en faire quelque chose d'utile ! :)
Et bien entendu, la facture d'électricité, le bruit, le prix du mètre carré
pour loger ces saloperies, tu t'asseois dessus. A l'heure actuelle, la notion
de cluster n'a guère d'intérêt économique - ce qui veut dire sauf pour les
institutions riches.
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs) pour en faire quelque chose d'utile ! :)
Et bien entendu, la facture d'électricité, le bruit, le prix du mètre carré pour loger ces saloperies, tu t'asseois dessus. A l'heure actuelle, la notion de cluster n'a guère d'intérêt économique - ce qui veut dire sauf pour les institutions riches.
Fred
Kevin DENIS
Le 05-09-2006, Michel Talon a écrit :
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des situations où on empile le matos, utilisé à 10% pour que l'admin sys puisse faire voir qu'il en a une plus grosse que son voisin.
Et la situation ou tu as N utilisateurs qui ont besoin de faire M
calculs. Chaque calcul oscille entre l'heure et le mois. Tu peux donner une machine a chacun, ou bien te monter un cluster de machines moyennement musclees. Les users soumettent leur jobs, un scheduler utilise les ressources au mieux, et le flot de calcul se lissera au cours du temps.
Pour _le_ gros calcul qui a besoin de puissance CPU/RAM enormes, c'est une autre problematique. Et empiler le matos ne sert a rien car la latence reseau fera effondrer les performances. 1 calcul reparti sur 1 CPU sur n machines ira plus lentement que 1 calcul reparti sur n CPU sur 1 machine.
Le 05-09-2006, Michel Talon <talon@lpthe.jussieu.fr> a écrit :
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des
situations où on empile le matos, utilisé à 10% pour que l'admin sys
puisse faire voir qu'il en a une plus grosse que son voisin.
Et la situation ou tu as N utilisateurs qui ont besoin de faire M
calculs. Chaque calcul oscille entre l'heure et le mois. Tu peux donner
une machine a chacun, ou bien te monter un cluster de machines
moyennement musclees. Les users soumettent leur jobs, un scheduler
utilise les ressources au mieux, et le flot de calcul se lissera au
cours du temps.
Pour _le_ gros calcul qui a besoin de puissance CPU/RAM enormes, c'est
une autre problematique. Et empiler le matos ne sert a rien car la
latence reseau fera effondrer les performances. 1 calcul reparti sur 1
CPU sur n machines ira plus lentement que 1 calcul reparti sur n CPU
sur 1 machine.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des situations où on empile le matos, utilisé à 10% pour que l'admin sys puisse faire voir qu'il en a une plus grosse que son voisin.
Et la situation ou tu as N utilisateurs qui ont besoin de faire M
calculs. Chaque calcul oscille entre l'heure et le mois. Tu peux donner une machine a chacun, ou bien te monter un cluster de machines moyennement musclees. Les users soumettent leur jobs, un scheduler utilise les ressources au mieux, et le flot de calcul se lissera au cours du temps.
Pour _le_ gros calcul qui a besoin de puissance CPU/RAM enormes, c'est une autre problematique. Et empiler le matos ne sert a rien car la latence reseau fera effondrer les performances. 1 calcul reparti sur 1 CPU sur n machines ira plus lentement que 1 calcul reparti sur n CPU sur 1 machine.
talon
Kevin DENIS wrote:
Le 05-09-2006, Michel Talon a écrit :
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des situations où on empile le matos, utilisé à 10% pour que l'admin sys puisse faire voir qu'il en a une plus grosse que son voisin.
Et la situation ou tu as N utilisateurs qui ont besoin de faire M
calculs. Chaque calcul oscille entre l'heure et le mois. Tu peux donner une machine a chacun, ou bien te monter un cluster de machines moyennement musclees. Les users soumettent leur jobs, un scheduler utilise les ressources au mieux, et le flot de calcul se lissera au cours du temps.
On en revient au problème du calcul scientifique, que je mentionnais. Donc ça s'adreese aux labos comme le notre où on peut acheter une centaine de machines pour faire ce que tu dis. Mon expérience c'est que de parler de quelque BSD que ce soit dans ces milieux c'est comme de prononcer un gros mot. C'est Linux à 100%. D'où ma conclusion que le développement de clustering pour BSD est voué à une utilisation complètement anecdotique. Si ça peut amuser le développeur, c'est à mon avis la seule retombée que ça aura.
Pour _le_ gros calcul qui a besoin de puissance CPU/RAM enormes, c'est une autre problematique. Et empiler le matos ne sert a rien car la latence reseau fera effondrer les performances. 1 calcul reparti sur 1 CPU sur n machines ira plus lentement que 1 calcul reparti sur n CPU sur 1 machine.
Je ne te le fais pas dire et c'est exactement pour ça que je pense que le clustering à l'heure actuelle n'offre pas grand intérêt. Ca en offrait quand les processeurs étaient lents, maintenant la seule chose qui compte c'est le support SMP, pour lequel Linux et Solaris sont excellents, FreeBSD commence à ressembler à quelque chose, et le reste est inexistant. Charles Hannum a raison, un système qui n'a pas un bon SMP, des librairies de threading efficaces n'a pas d'avenir sur la machine standard. Il est possible qu'il en ait dans les systèmes embarqués, les routeurs, firewalls etc. où on utilise des monoprocesseurs et où la sécurité est importante, mais là encore Linux a raflé une grande partie du marché. Or il a fallu 5 ans à Linux pour développer le SMP, et autant à FreeBSD. Fais tes comptes, la situation n'est pas brillante.
Kevin DENIS <kevin@nowhere.invalid> wrote:
Le 05-09-2006, Michel Talon <talon@lpthe.jussieu.fr> a écrit :
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des
situations où on empile le matos, utilisé à 10% pour que l'admin sys
puisse faire voir qu'il en a une plus grosse que son voisin.
Et la situation ou tu as N utilisateurs qui ont besoin de faire M
calculs. Chaque calcul oscille entre l'heure et le mois. Tu peux donner
une machine a chacun, ou bien te monter un cluster de machines
moyennement musclees. Les users soumettent leur jobs, un scheduler
utilise les ressources au mieux, et le flot de calcul se lissera au
cours du temps.
On en revient au problème du calcul scientifique, que je mentionnais.
Donc ça s'adreese aux labos comme le notre où on peut acheter une centaine de
machines pour faire ce que tu dis. Mon expérience c'est que de parler de
quelque BSD que ce soit dans ces milieux c'est comme de prononcer un gros mot.
C'est Linux à 100%. D'où ma conclusion que le développement de clustering pour
BSD est voué à une utilisation complètement anecdotique. Si ça peut amuser le
développeur, c'est à mon avis la seule retombée que ça aura.
Pour _le_ gros calcul qui a besoin de puissance CPU/RAM enormes, c'est
une autre problematique. Et empiler le matos ne sert a rien car la
latence reseau fera effondrer les performances. 1 calcul reparti sur 1
CPU sur n machines ira plus lentement que 1 calcul reparti sur n CPU
sur 1 machine.
Je ne te le fais pas dire et c'est exactement pour ça que je pense que le
clustering à l'heure actuelle n'offre pas grand intérêt. Ca en offrait quand
les processeurs étaient lents, maintenant la seule chose qui compte c'est le
support SMP, pour lequel Linux et Solaris sont excellents, FreeBSD commence
à ressembler à quelque chose, et le reste est inexistant. Charles Hannum a
raison, un système qui n'a pas un bon SMP, des librairies de threading
efficaces n'a pas d'avenir sur la machine standard. Il est possible qu'il en
ait dans les systèmes embarqués, les routeurs, firewalls etc. où on utilise
des monoprocesseurs et où la sécurité est importante, mais là encore Linux a
raflé une grande partie du marché. Or il a fallu 5 ans à Linux pour développer
le SMP, et autant à FreeBSD. Fais tes comptes, la situation n'est pas
brillante.
Décidemment, tu ne penses toujours qu'au calcul scientifique.
Je pense à des situations où on a besoin de performances, et pas à des situations où on empile le matos, utilisé à 10% pour que l'admin sys puisse faire voir qu'il en a une plus grosse que son voisin.
Et la situation ou tu as N utilisateurs qui ont besoin de faire M
calculs. Chaque calcul oscille entre l'heure et le mois. Tu peux donner une machine a chacun, ou bien te monter un cluster de machines moyennement musclees. Les users soumettent leur jobs, un scheduler utilise les ressources au mieux, et le flot de calcul se lissera au cours du temps.
On en revient au problème du calcul scientifique, que je mentionnais. Donc ça s'adreese aux labos comme le notre où on peut acheter une centaine de machines pour faire ce que tu dis. Mon expérience c'est que de parler de quelque BSD que ce soit dans ces milieux c'est comme de prononcer un gros mot. C'est Linux à 100%. D'où ma conclusion que le développement de clustering pour BSD est voué à une utilisation complètement anecdotique. Si ça peut amuser le développeur, c'est à mon avis la seule retombée que ça aura.
Pour _le_ gros calcul qui a besoin de puissance CPU/RAM enormes, c'est une autre problematique. Et empiler le matos ne sert a rien car la latence reseau fera effondrer les performances. 1 calcul reparti sur 1 CPU sur n machines ira plus lentement que 1 calcul reparti sur n CPU sur 1 machine.
Je ne te le fais pas dire et c'est exactement pour ça que je pense que le clustering à l'heure actuelle n'offre pas grand intérêt. Ca en offrait quand les processeurs étaient lents, maintenant la seule chose qui compte c'est le support SMP, pour lequel Linux et Solaris sont excellents, FreeBSD commence à ressembler à quelque chose, et le reste est inexistant. Charles Hannum a raison, un système qui n'a pas un bon SMP, des librairies de threading efficaces n'a pas d'avenir sur la machine standard. Il est possible qu'il en ait dans les systèmes embarqués, les routeurs, firewalls etc. où on utilise des monoprocesseurs et où la sécurité est importante, mais là encore Linux a raflé une grande partie du marché. Or il a fallu 5 ans à Linux pour développer le SMP, et autant à FreeBSD. Fais tes comptes, la situation n'est pas brillante.
F. Senault
F. Senault wrote:
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs) pour en faire quelque chose d'utile ! :)
Utile? Tu veux te chauffer à l'informatique?
Ouais ! Et l'hiver, je fais tourner pour être sur de pas geler sur place !
Fred -- Born from silence, silence full of it A perfect concert my best friend So much to live for, so much to die for If only my heart had a home (Nightwish, Dead Boy's Poem)
F. Senault <fred@lacave.net> wrote:
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes
que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs)
pour en faire quelque chose d'utile ! :)
Utile? Tu veux te chauffer à l'informatique?
Ouais ! Et l'hiver, je fais tourner seti@home pour être sur de pas
geler sur place !
Fred
--
Born from silence, silence full of it
A perfect concert my best friend
So much to live for, so much to die for
If only my heart had a home (Nightwish, Dead Boy's Poem)
Ca fait super longtemps que j'ai envie de ramasser toutes les brouettes que j'ai autour de moi (au nez, 5 GHz répartis sur au moins 10 procs) pour en faire quelque chose d'utile ! :)
Utile? Tu veux te chauffer à l'informatique?
Ouais ! Et l'hiver, je fais tourner pour être sur de pas geler sur place !
Fred -- Born from silence, silence full of it A perfect concert my best friend So much to live for, so much to die for If only my heart had a home (Nightwish, Dead Boy's Poem)
