C'est vraiment très intéressant cette double évolution. Entre le fait que leur labos de recherche, et leurs partenariats, communiquent plus aujourdhui (et qu'ils semblent bénéficier de plus de crédits sur des sujets plus globaux que la rentabilité à court terme pour un seul produit), et le fait qu'ils ne rechignent plus à utiliser ce qui se fait de mieux, en le disant. C'est vraiment très intéressant.
Là, finalement, il me semble comprendre qu'il pousse le bouchon du cluster plus loin, et ça -me- semble tellement logique. Regardons un projet comme Xtreem O.S ou mieux -mais plus conventionnel- Redhat HPC (ouhaou que c'est beau, ça -oups désolé) ou finalement n'importe quel fonctionnement de type cluster. Nous avons un noyau par unité de calcul, un ensemble de process de communication entre, et un noyau gestionnaire. Où l'unité de calcul est une baie dans la ferme. Là il redessine la définition d'unité de calcul.
En plus ça -me- semble beau comme solution, si on ajoute la notion d'indépendance des micro noyaux (ce sont les communications entre qui le peuvent, et l'éventuelle capacité à rester en place lorsqu'un noyau tombe), on semble s'approcher vraiment d'une certaine solidité logique. Surtout si la base reste la même que celle d'une sécurité de fonctionnement : ça doit fonctionner, toujours. Un peu comme lorsqu'on décide de doubler les commandes et tout les cables... C'est ça l'important. Le fait de coupler la puissance de calcul n'est alors qu'un bénéfice secondaire, pas l'objectif en lui même.
Maintenant reste la partie technique :-) et là mieux vaudra écouter les spécialistes du code :-) (parceque si c'est basé sur les mêmes fondations que windows, ça risque d'être drôle... )
# double évolution chez microsoft.
Posté par bubar🦥 . En réponse au journal Projet de Système d'Exploitation par Microsoft, outils libres et innovation. Évalué à 1.
Là, finalement, il me semble comprendre qu'il pousse le bouchon du cluster plus loin, et ça -me- semble tellement logique. Regardons un projet comme Xtreem O.S ou mieux -mais plus conventionnel- Redhat HPC (ouhaou que c'est beau, ça -oups désolé) ou finalement n'importe quel fonctionnement de type cluster. Nous avons un noyau par unité de calcul, un ensemble de process de communication entre, et un noyau gestionnaire. Où l'unité de calcul est une baie dans la ferme. Là il redessine la définition d'unité de calcul.
En plus ça -me- semble beau comme solution, si on ajoute la notion d'indépendance des micro noyaux (ce sont les communications entre qui le peuvent, et l'éventuelle capacité à rester en place lorsqu'un noyau tombe), on semble s'approcher vraiment d'une certaine solidité logique. Surtout si la base reste la même que celle d'une sécurité de fonctionnement : ça doit fonctionner, toujours. Un peu comme lorsqu'on décide de doubler les commandes et tout les cables... C'est ça l'important. Le fait de coupler la puissance de calcul n'est alors qu'un bénéfice secondaire, pas l'objectif en lui même.
Maintenant reste la partie technique :-) et là mieux vaudra écouter les spécialistes du code :-) (parceque si c'est basé sur les mêmes fondations que windows, ça risque d'être drôle... )