Bon, j'ai deux VM sous KVM avec un Centos7 tout propre dessus. J'ai une machine physique (pour l'instant, bientôt deux) sous la même Centos7 (presque propre) avec 2To disponible. Mon objectif est d'installer HDFS sur les deux machines physiques, et Spark sur les 4 machines (dont 2 avec pratiquement aucun storage disponible, l'idée est simplement que ça serve pour le calcul).

La question maintenant, c'est : est-ce que je mets du Yarn/Mesos en dessous de tout ça, où est-ce que je lance du Hadoop+Spark sans rien d'autre ? Vu que je serai le principal utilisateur, et qu'on ne devrait pas être plus de 2 ou 3 à travailler en même temps, je ne suis pas convaincu que l'overhead (en terme de travail/déploiement) de Yarn/Mesos en vaille la peine.

Est-ce que tu peux utiliser toute cette capacité de calcul pour résoudre des rubik's cube 3x3?
C'est pas une blague!
Un rubik's cube 3x3, c'est un cube à 6 faces et 9 éléments sur chaque face (d'où le 3x3, il existe des 4x4 et +)
Chaque face peut être tournée vers la droite ou vers la gauche d'un quart de tour
- 12 mouvements de 1/4 tour
Il faut rajouter que chaque face peut faire un demi tour
- 6 mouvements de 1/2 tour
Les mouvements de 3/4 tour sont équivalent au 1/4 dans l'autre sens, pas important, les mouvements de 1 tour n'ont aucun effet.

Donc tu as 18 mouvements de base, à l'étape d'après, il y a 17 mouvements possibles, sinon tu annules ton précédent mouvement, mais tu restes à 17 mouvements possibles par la suite.

J'ai lu que n'importe quel rubik's cube 3x3 pouvait être résolu en 20-30 mouvements, ça donne un arbre de brute force de 18*17^25, c'est ça?
1.03871293422271 * 10^32

Ca fait beaucoup pour tes machines ou pas?

PetitCalgonJ'ai lu que n'importe quel rubik's cube 3x3 pouvait être résolu en 20-30 mouvements, ça donne un arbre de brute force de 18*17^25, c'est ça?
1.03871293422271 * 10^32

Ca me semble correct.

PetitCalgonCa fait beaucoup pour tes machines ou pas?

Euh, oui, tout de même Mais bon, on peut certainement coder l'état d'un Rubik's cube de façon intelligente, et avoir des classes d'équivalence notamment sur les permutations de couleurs, ce qui diminue l'espace de recherche, et permet d'élaguer l'arbre des possibilités en cas de brute force. Sur une seule machine, ça peut être très bénéfique, mais sur plusieurs machines, il faut réussir à trouver un ordre (au moins partiel) pour les "solutions", afin qu'une machine, dans une branche de possibilités, puisse aisément savoir si la combinaison à tester l'a déjà été (ou le sera) dans une autre branche (en gros, contourner le fait qu'on ne travaille pas en zone mémoire partagée).

Même en considérant 1000 machines, capable de traiter 10 combinaisons par milliseconde, ça ne fait encore qu'un million de combinaisons par seconde, soit 10^24 (si on teste tout jusque 25 coups) secondes, ou encore 32^12 millénaires Même avec une puissance de calcul colossal, ça reste inefficace. Ce nombre de possibilités est la raison pour laquelle on ne fait pas de brute force

Ah flute!
J'ai commencé un peu à m'amuser avec le rubik's cube, je sais presque le résoudre, j'arrive à placer toutes les pièces, sauf 3 arêtes.
Il y a une méthode "facile" sur le site de rubik's cube qui permet de placer chaque pièce une à une (donc pas efficace)
https://eu.rubiks.com/uploads/general_content/YCDTC_fr.pdf

Pour l'instant, je connais par cœur toutes les manipulations pour arriver à l'étape 6 (page 8), mais pas plus loin.
Et on se rend compte quand par exemple ou fait la manipulation de l'étape 6 qu'au milieu le cube semble tout mélangé, mais en continuant il retrouve un état ordonné qui va dans la bonne direction, après avoir fait les x mouvements, on a finit l'étape y, et on s'approche de la résolution.

Ce qui est compliqué, c'est qu'à un moment donné T1, on a un cube résolu à R1%, on passe par des mouvement qui baissent dramatiquement la résolution (les pièces sont hyper mélangées), mais à la fin des mouvements, on arrive à un moment T2 ou R2 > R1.

Et donc je sais pas te dire au milieu si tu vas dans la bonne direction de résolution ou pas, tu peux passer par des étapes nécessaires qui baissent la résolution de ton cube, mais qui seront bénéfiques plus tard.

De ce que je vois, le nombre de Dieu pour un Rubik's cube 3x3 est de 20 (prouvé assez récemment, 2010. Jusque là, c'était qu'une borne inférieure). Si je copie-colle :

- Les 43 252 003 274 489 856 000 positions du cube ont été réparties en 2 217 093 120 ensembles de 19 508 428 800 configurations chacune. Ceci permet à chaque sous-problème de tenir dans la mémoire d’un PC moderne.
- Le nombre d’ensemble a été réduit à 55 882 296 en utilisant des symétries et ensembles couvrants.
- Les solutions recherchées n’étaient pas les optimales pour chaque position, mais celles de 20 mouvements ou moins — étant donné que la limite inférieure était déjà à 20 depuis 1995
- Un programme (www.cube20.org/src/) permet de résoudre chaque position (donc trouver le nombre de coup minimal) en 20 secondes environ.
- La résolution d'une configuration prenant environ 20 secondes, le calcul aurait duré 35 ans avec un PC normal, mais les nombreux ordinateurs fournis par Google ont permi d'effectuer le calcul en quelques semaines seulement.

Dimanche dernier, j'étais à un festival de jeu, il y avait une compétition de Rubik's cube. C'était dingue, je ne savait pas que c'était aussi acharné, les mecs (quasi exclusivement, encore que je ne me suis pas trop attardé) se filmaient en gopro et sitôt le cube fini (après chaque tentative), ils le huilaient pour qu'il soit plus lubrifié.

Oui, j'avais souvent vu des extraits sur youtube de speed kuber qui résolvaient un rubik's cube en 5 sec environ.
Il existe des des rubik's cube de compétition qui tournent beaucoup plus vite avec beaucoup moins de frottement.

Et encore, t'as pas le bruit de 10 rubik's cubers qui en même temps dans les gradins ou autour tournent frénétiquement. On aurai cru un essaim de criquets. cracracracracracracra....

J'ai vu ça tout à l'heure, ça m'a fait penser à vous

Yes!

Désolé de recentrer le débat sur des trucs moins funcky que le rubiks cube, mais le sujet de base m'intéresse plus.
Devant gérer quelques serveurs costauds, je vais me pencher sur les diverses solutions techniques évoquées dans le titre, histoire de voir si ça me solutionnera quelques problématiques reloues.
A part kafka que je connais déjà (mais on a déjà rabbitmq à la place), les autres ne sont pour le moment que des noms pour moi... va falloir que je creuse :D