En gros l'enumeration faite sur ce que fait openMosix est incomplete et que si tu prends l'integralite de ce qu'il fait reellement, ben t'es assez proche de openssi.
Ben non, justement pas : avec openmosix t'as pas de gestion des IPC System V sans être obligé de refaire migrer le process sur son noeud d'origine par exemple. Et qu'on me parle de MigSHM, le patch qui fait de la mémoire partagée, en utilisant les sémaphores pour savoir si la mémoire a été modifiée, on aura vu mieux (la bonne solution, étant d'utiliser la MMU, ce que fait OpenSSI et vu qu'OpenMosix ne tourne que sur i386, qu'on me dise pas que ca le rendrait non portables sur des choses tels que les ATARI ST qui en sont dépourvus), sans compter le fait qu'il est plantogène a mourrir.
De plus OpenSSI permet aussi bien de faire la haute disponibilité que du partage de charge, et fourni de base tout ce qui est nécessaire pour faire de la redondance, ce qui n'est pas le cas d'OpenMosix. Le truc, c'est que c'est tellement bugué que pour faire de la haute disponibilité on aura vu mieux, mais pour certains types de cluster de calculs, c'est plus rentable que Mosix, et l'aspect plantogène / bug restant est moins important dans ce cas. Pour info quand même : dans le test (idiot, cf distcc) de la recompilation de kernel en parrallèle via le répartiteur de charges est plus rapide sur OpenSSI que OpenMosix.
Les 2 projets de toute évidence s'ils sont comparables, ont des objectifs différents (désolé pas trop le temps de m'étrendre la dessus) ; pour OpenMosix la fiabilité a une certaine importance, aussi tous les appels systèmes sont sur le noeud qui a lancé le process, pour OpenSSI, on ne se souvient même pas du noeud de base (aussi certains cas extrèmes peuvent créer des programmes bugués, mais cette propriété peut aussi être facilement exploitée)....
[^] # Re: GNU/Linux Magazine Hors Série : Haute disponibilité
Posté par Maxime Ritter (site web personnel) . En réponse à la dépêche GNU/Linux Magazine Hors Série : Haute disponibilité. Évalué à 2.
Le monsieur a fait un post incompréhensible, oui.
En gros l'enumeration faite sur ce que fait openMosix est incomplete et que si tu prends l'integralite de ce qu'il fait reellement, ben t'es assez proche de openssi.
Ben non, justement pas : avec openmosix t'as pas de gestion des IPC System V sans être obligé de refaire migrer le process sur son noeud d'origine par exemple. Et qu'on me parle de MigSHM, le patch qui fait de la mémoire partagée, en utilisant les sémaphores pour savoir si la mémoire a été modifiée, on aura vu mieux (la bonne solution, étant d'utiliser la MMU, ce que fait OpenSSI et vu qu'OpenMosix ne tourne que sur i386, qu'on me dise pas que ca le rendrait non portables sur des choses tels que les ATARI ST qui en sont dépourvus), sans compter le fait qu'il est plantogène a mourrir.
De plus OpenSSI permet aussi bien de faire la haute disponibilité que du partage de charge, et fourni de base tout ce qui est nécessaire pour faire de la redondance, ce qui n'est pas le cas d'OpenMosix. Le truc, c'est que c'est tellement bugué que pour faire de la haute disponibilité on aura vu mieux, mais pour certains types de cluster de calculs, c'est plus rentable que Mosix, et l'aspect plantogène / bug restant est moins important dans ce cas. Pour info quand même : dans le test (idiot, cf distcc) de la recompilation de kernel en parrallèle via le répartiteur de charges est plus rapide sur OpenSSI que OpenMosix.
Les 2 projets de toute évidence s'ils sont comparables, ont des objectifs différents (désolé pas trop le temps de m'étrendre la dessus) ; pour OpenMosix la fiabilité a une certaine importance, aussi tous les appels systèmes sont sur le noeud qui a lancé le process, pour OpenSSI, on ne se souvient même pas du noeud de base (aussi certains cas extrèmes peuvent créer des programmes bugués, mais cette propriété peut aussi être facilement exploitée)....