Pour se connecter sur un poste avec des identifiants LDAP hors connexion (avec ou sans kerberos), la solution standard depuis ~10 ans sur Linux est d'utiliser SSSD.
Tu dois juste être connecté à l'annuaire LDAP à la première connexion (pour remplir le cache), ou pour changer de mot de passe.
Cela marche très bien dans le train, ou dans n'importe quel endroit encore moins connecté.
Avant il existait des démons de cache NSS tels que nscd. Si j'en crois le tracker Debian, le module pam_ldap semble abandonné depuis ~6 ans (dernière version majeure 186 publiée en 2016, plus de site web avec les sources).
Tu te trompes d'échelle. Le top10 c'est 7,235 Pflops soit 7,2 millions de GFlops.
Considérant que les 24Gflops du GPU RPI soit en double précision (ce dont je doute), il faudrait 301459 RPI pour atteindre un Rpeak équivalent. Ça change la facture : 1,5M$ et 0,2MW hors stockage et réseau.
Et on parle de Rpeak là. Le top500 se fait sur le résultat du Linpack. Je connais pas les perfs des compilos sur le GPU RPI, mais étant donné les perfs réseau des framboises, ça m'étonnerait que tu puisse atteindre les 1% d'efficacité sur 300K boards :) Soit 72Tflops, et bien loin de la 500ème place…
Ça tombe bien parce les développeurs initiaux de modules (TACC) développent depuis plusieurs années lmod, son remplaçant bien plus performant … en Lua :)
Tu peux évidemment scripter tout cela avec n'importe quel langage de script (shell ou autre) mais il y a des outils spécialisés pour ce type d'opérations : les logiciels de gestion de config. Plusieurs examples : puppet, cfengine, ansible, salstack, etc…
Le ticket d'entrée est un peu plus lourd qu'un simple script mais au fur et à mesure qu'on ajoute des éléments à son infra, ça devient bien plus fiable et maintenable.
Les serveurs de la gamme R sont des SuperMicro renommés.
En revanche, toutes les blades (gamme B) et les gros noeuds SMP (gamme S) sont des machines avec chassis et cartes mères Bull.
En général, pour les gros clusters de calcul, Bull vend des serveurs de la gamme R pour l'infra (car peu de plus-value sur cette partie) des blades de la gamme B pour la partie calcul. Pour les petits clusters, ils proposent des serveurs de la gamme R uniquement, y compris pour la partie calcul, car c'est moins cher et c'est plus simple à intégrer dans des racks existants.
Tu as regardé si tu n'avais pas déjà un watchdog utilisable sur ta machine ? La sortie de dmesg devrait t'aider à l'identifier. C'est rare qu'il n'y ait pas, par exemple, un watchdog NMI sur les CPU x86 récents. Ces watchdogs permettent de détecter un système planté sans kernel panic, le cas des kernels panic étant gérés autrement. Bien sûr, ceci est valable en supposant que ton PC est sous Linux :)
Si par « tableaux complexes » tu entends rowspan, colspan, liste dans les cellules, etc… C'est spécifiquement la raison pour laquelle j'utilise la syntaxe asciidoc ! Avec son implémentation de référence en Python, ou son excellente alternative asciidoctor en Ruby.
Ce n'est pas du markdown (donc un HS par rapport à la dépêche) mais c'est la syntaxe la plus complète à ma connaissance.
Samuel, outre le fait que tous tes journaux sont un peu saoulants car ils ne sont que des relais des communiqués de presse de Suse, la machine Pangea de Total a été annoncée en mars 2013. Rien de moins que 18 mois de retard…
Dans ce cas, toute ton indignation ne motive-t'elle pas un don pour acheter la prestation d'un expert en sécurité pour réaliser les actions sus-citées ?
Il ne faut pas oublier que DLFP est un site qui ne génère pas d'argent, qui est maintenu simplement par de gentils bénévoles pendant leur temps libre, et tant pis pour "les pratiques habituelles de sécurité et […] la législation". Râler dans un journal sans proposer d'aide ne fera que diminuer leur précieuse motivation.
Tu te doutes bien que le format de paquet est totalement secondaire pour le choix d'une distribution pour de telles machines.
Ah bon ?
La plupart des centres de calcul privilégient les distributions supportées par les constructeurs pour leur matériel donc généralement ça se limite à du RHEL/Suse… Pour ceux qui veulent éviter de payer des licences, les issues de secours sont Centos et Scientific Linux.
Mais le format des paquets et le choix de la distrib est bien souvent simplement dicté par les contrats de support du constructeur, les critères techniques (performances, possibilité de tuning et d'intégration, etc) ne sont généralement pas pris en compte…
Quelques irréductibles (avec des compétences en interne) utilisent Debian (ou autre) mais c'est parfois un peu rock n' roll :)
Je ne pense pas que ce soit possible, Puppet n'est tout simplement pas conçu pour cela :) L'idée des outils de gestion de conf est d'avoir un référentiel central et de s'assurer qu'il est bien appliqué partout. Là, tu es en dehors du périmètre fonctionnel !
Éventuellement, tu peux demander à Puppet de ne pas remplacer le fichier sur le nœud si la prod est différente de son référentiel (voir l'attribut replace sur la ressource File). Tu peux aussi demander à Puppet de reporter le diff entre la prod et le référentiel (attribut show_diff).
Pour ton cas d'usage, tu peux aussi configurer un filebucket et réaliser des backups (avec l'attribut du même nom). Ainsi, lorsque Puppet réalise que les fichiers en production sont différents du référentiel, il réalise un backup du fichier sur le master avant de le modifier sur le nœud.
Est-ce qu'il n'y a pas une confusion entre INRA et INRIA ?
Effectivement, DIET est développé principalement par l'équipe de recherche GRAAL, notamment rattachée à l'INRIA (recherche en informatique et automatique) et non pas à l'INRA (recherche en agronomie).
Calibre (coté poste client) est quand même très loin d'un GNU/Debian qui marche bien. Le nombre de problème que l'on peut rencontrer est hallucinant car la configuration est mal foutue...
Je t'invite à tester Calibre7 qui est une mise à jour très importante pour les postes de travail. Le nombre de problèmes utilisateurs résolu est très important. Et si tu rencontres des problèmes avec Calibre, les circuits sont en place pour les remonter.
Si un serveur tombe on se retrouve avec tous les développeurs qui ne peuvent plus utiliser leur poste local, on fait donc un tour dans le couloir, mdr! Et j'en passe...
J'ai du mal à comprendre comment on peut incriminer une distribution logicielle pour un problème d'architecture SI...
Tout cela pour dire que même dans ce domaine un projet d'envergure serait nécessaire je pense.
Un certain nombre de chantiers importants autour de Calibre sont déjà bien engagés.
Nous développons une solution de poste de travail nommée Calibre, basée sur Debian, pour l'instant réservée à l'informatique scientifique, etc :
Ca ne me parait pas douteux que :
- je ne pense pas une seule seconde qu'EDF réalisera entièrement en interne une montée de version de distribution ou de noyau dans l'optique d'un déploiement sur tous les postes. C'est le boulot d'un éditeur, et c'est pour ça que les maj ne seront jamais réalisées à 100% en interne.
Nous nous basons sur les versions majeures de Debian pour caler les versions majeures de Calibre mais tout le processus de releasing est géré par une équipe interne pour déclencher les migrations de versions.
le support éditeur restera payant (je n'imagine pas ne pas prendre de support / garantie)
Pas de support éditeur externe pour ce qui est purement issu de Calibre, l'équipe de dev interne assure tout le support N3-4.
En effet, les infrastructures mutualisées, ça mutualise le matériel mais ça mutualise surtout les ingénieurs et les infrastructures. C'est en général largement sous-estimé pour ceux qui achètent des clusters dans leur coin, en pensant principalement à leur petit égo. Malheureusement, il faut pas mal de savoir faire pour maîtriser tout ça, et l'expérience d'une équipe qui tourne depuis plusieurs années est très précieuse pour garantir un certain niveau d'utilisabilité.
J'en connais un certains nombre de clusters qui ont été acheté en oubliant la clim, les installations électriques, et les gens compétents pour faire tourner tout ça. À la fin, ça fait du pognon gaspillé dans du matériel qui sert pas à grand chose.
Pour le problème du transfert des données, il est tout relatif en France. On a la chance d'avoir Renater, et c'est pas vraiment difficile de trouver une connexion réseau inter-labos qui carbure à 1Gb/s. Et dans ce cas là, c'est rarement le réseau le bottleneck.
Pour l'excuse des clusters non utilisés la nuit et pendant les vacances faute de chercheurs qui travaillent en permanence, c'est notamment pour cette raison qu'on utilise des batchs schedulers. Et il y en a qui seraient ravis de pouvoir utiliser toutes ces ressources machines en balançant des trucs automatiquement dessus quand personne ne s'en sert.
De ce que j'en sais, il a toujours été possible d'utiliser SSH sans wrapper, on perd juste des fonctionnalités d'isolation pour le partage des machines (cpuset). C'est toujours très utilisé, notamment pour le déploiement de jobs avec certaines implémentations MPI qui dépendent fortement de SSH.
C'est juste un type de job spécifique à paramétrer lors des réservations.
Plus de 12MW, ça commence à faire, en effet. AFAIK, ce sera probablement le triple des gros clusters petascales français prévus pour 2011, qui auront approximativement la même puissance de calcul théorique.
Pour la doc, ça pourrait m'intéresser, mais je voudrais être sûr de ne pas avoir d'ennui avec les gens du DoE... ;)
Et sinon, il y a des codes autre que le Linpack qui utilisent la config avec un pourcentage convenable de sa puissance théorique ?
Ah, le gros Jaguar de l'ORNL :) Il y a autant de noeuds que ça dans cette machine ?
Si il y a des infos sur l'archi de la config ça m'intéresse :) Même si j'ai peur qu'avec Cray, il y ait beaucoup de bidules propriétaires autour des CPU AMD...
Aujourd'hui, on peut déployer du Xen partout, et du KVM sur pas mal de clusters. On a même un environnement et une infrastructure en cours de déploiement pour faire ça avec des scripts de quelques lignes, sur toute la grille. Dans des horizons proches, ce sera même interfacé avec une API en web services REST, pour faire un truc qui ressemble à ce que certains appelent du «cloud computing».
Il n'y a pas 6000 noeuds sur la plate-forme, il y en a environ 1500. Mais si j'en crois ton commentaire[1], si tu bosses sur une configuration de 18688 noeuds, je suppose que c'est une BG. On est d'accord pour dire que la définition de «noeud» dans la terminologie BG n'est pas comparable à celle de la terminologie cluster x86_64 ? ;) Donc non, on ne peut pas réserver 6000 noeud BG en quelques minutes sur g5k, mais on peut réserver plus de 1000 serveurs pour après demain et installer la distrib qu'on veut dessus, avec tous les droits root et un accès à des réseaux sympathiques.
Pour être plus précis, il ne faut pas comparer grid'5000 à une grille informatique de calcul. On pourrait appeler ça un plateforme expérimentale distribuée, dédiée et reconfigurable, où l'une des formes possibles est une grille informatique de calcul ;) C'est pour cette raison que la plate-forme est notamment utilisée pour prototyper des codes de calcul de production.
Pour finir, aujourd'hui en France et AFAIK en Europe, je ne connais pas d'instrument scientifique informatique de cette échelle qui soit aussi simplement accessible ; ie. on demande un compte, on peut réserver plusieurs centaines de noeuds le lendemain. Mais je m'avance peut-être.
Si j'ai bien compris, le démon d'émulation de switch de Cloonix fonctionne un peu pareil, avec des sockets. À mon avis, ce serait intéressant de pouvoir réutiliser toutes les fonctionnalités des équipements réseaux virtuels VDE pour les utiliser dans Cloonix. En plus, ça aurait le bon goût d'être compatible avec les nouvelles versions de KVM...
Alors, pour préciser un peu ce qui est dit au-dessus, on peut écouter l'ensemble de catalogue directement sur le site web, avec un plugin propriétaire, en version basse qualité.
Il existe des plugins pour Rythmbox et Amarok pour écouter ces mêmes versions en se passant du blob.
Quand on décide de passer à la caisse (avec des $ et des frais de change), en fixant soit même le montant, on accède à une liste de liens vers différentes versions de l'album : MP3 320kbits, Ogg Vorbis, VBR/AAC, Flac, WAV sans perte. On peut télécharger la pochette haute qualité au format PDF.
Il me semble que l'ensemble du catalogue (en tout cas, pour les albums que j'ai acheté) est sous une des licences CC.
[^] # Re: Peu d'obstacle?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le poste de travail Linux : un objectif gouvernemental ?. Évalué à 10.
Pour se connecter sur un poste avec des identifiants LDAP hors connexion (avec ou sans kerberos), la solution standard depuis ~10 ans sur Linux est d'utiliser SSSD.
Tu dois juste être connecté à l'annuaire LDAP à la première connexion (pour remplir le cache), ou pour changer de mot de passe.
Cela marche très bien dans le train, ou dans n'importe quel endroit encore moins connecté.
Avant il existait des démons de cache NSS tels que
nscd. Si j'en crois le tracker Debian, le modulepam_ldapsemble abandonné depuis ~6 ans (dernière version majeure 186 publiée en 2016, plus de site web avec les sources).[^] # Re: Ou est-ce que je me plante ?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
Tu te trompes d'échelle. Le top10 c'est 7,235 Pflops soit 7,2 millions de GFlops.
Considérant que les 24Gflops du GPU RPI soit en double précision (ce dont je doute), il faudrait 301459 RPI pour atteindre un Rpeak équivalent. Ça change la facture : 1,5M$ et 0,2MW hors stockage et réseau.
Et on parle de Rpeak là. Le top500 se fait sur le résultat du Linpack. Je connais pas les perfs des compilos sur le GPU RPI, mais étant donné les perfs réseau des framboises, ça m'étonnerait que tu puisse atteindre les 1% d'efficacité sur 300K boards :) Soit 72Tflops, et bien loin de la 500ème place…
[^] # Re: modules
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Red Hat Software Collections 2.1. Évalué à 1.
Ça tombe bien parce les développeurs initiaux de
modules(TACC) développent depuis plusieurs annéeslmod, son remplaçant bien plus performant … en Lua :)https://www.tacc.utexas.edu/research-development/tacc-projects/lmod
# Gestion de config ?
Posté par Rémi PALANCHER (site web personnel) . En réponse au message automatiser installation de paquets (apt-get) et modification fichiers de confiG. Évalué à 2.
Tu peux évidemment scripter tout cela avec n'importe quel langage de script (shell ou autre) mais il y a des outils spécialisés pour ce type d'opérations : les logiciels de gestion de config. Plusieurs examples : puppet, cfengine, ansible, salstack, etc…
Le ticket d'entrée est un peu plus lourd qu'un simple script mais au fur et à mesure qu'on ajoute des éléments à son infra, ça devient bien plus fiable et maintenable.
[^] # Re: On parle de Debian ?
Posté par Rémi PALANCHER (site web personnel) . En réponse au journal Une autre entité de la défense américaine fait confiance à une société Européenne !. Évalué à 3.
Cela dépend :
En général, pour les gros clusters de calcul, Bull vend des serveurs de la gamme R pour l'infra (car peu de plus-value sur cette partie) des blades de la gamme B pour la partie calcul. Pour les petits clusters, ils proposent des serveurs de la gamme R uniquement, y compris pour la partie calcul, car c'est moins cher et c'est plus simple à intégrer dans des racks existants.
# Question bête mais ...
Posté par Rémi PALANCHER (site web personnel) . En réponse au message Mise en place d'un watchdog par microcontroleur . Évalué à 4.
Tu as regardé si tu n'avais pas déjà un watchdog utilisable sur ta machine ? La sortie de dmesg devrait t'aider à l'identifier. C'est rare qu'il n'y ait pas, par exemple, un watchdog NMI sur les CPU x86 récents. Ces watchdogs permettent de détecter un système planté sans kernel panic, le cas des kernels panic étant gérés autrement. Bien sûr, ceci est valable en supposant que ton PC est sous Linux :)
# Tu as une question ?
Posté par Rémi PALANCHER (site web personnel) . En réponse au message gestion des capabilities. Évalué à 1.
Très bien, mais quelle est ta question ? :) À moins que ce soit simplement pour partager ton expérience ?
[^] # Re: table
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche CommonMark, une syntaxe Markdown en commun et répandue. Évalué à 4.
Si par « tableaux complexes » tu entends rowspan, colspan, liste dans les cellules, etc… C'est spécifiquement la raison pour laquelle j'utilise la syntaxe asciidoc ! Avec son implémentation de référence en Python, ou son excellente alternative asciidoctor en Ruby.
Ce n'est pas du markdown (donc un HS par rapport à la dépêche) mais c'est la syntaxe la plus complète à ma connaissance.
# Ça calcule vite mais ça met du temps à communiquer
Posté par Rémi PALANCHER (site web personnel) . En réponse au journal Total s'appuie sur un super-calculateur tournant sous Linux !. Évalué à 10.
Samuel, outre le fait que tous tes journaux sont un peu saoulants car ils ne sont que des relais des communiqués de presse de Suse, la machine Pangea de Total a été annoncée en mars 2013. Rien de moins que 18 mois de retard…
[^] # Re: Yakafokon
Posté par Rémi PALANCHER (site web personnel) . En réponse au journal De l'approche ultra-légère de la sécurité sur linuxfr. Évalué à 7.
Dans ce cas, toute ton indignation ne motive-t'elle pas un don pour acheter la prestation d'un expert en sécurité pour réaliser les actions sus-citées ?
Il ne faut pas oublier que DLFP est un site qui ne génère pas d'argent, qui est maintenu simplement par de gentils bénévoles pendant leur temps libre, et tant pis pour "les pratiques habituelles de sécurité et […] la législation". Râler dans un journal sans proposer d'aide ne fera que diminuer leur précieuse motivation.
[^] # Re: distribution linux
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le Top 500 de juin 2014. Évalué à 6.
Ah bon ?
La plupart des centres de calcul privilégient les distributions supportées par les constructeurs pour leur matériel donc généralement ça se limite à du RHEL/Suse… Pour ceux qui veulent éviter de payer des licences, les issues de secours sont Centos et Scientific Linux.
Mais le format des paquets et le choix de la distrib est bien souvent simplement dicté par les contrats de support du constructeur, les critères techniques (performances, possibilité de tuning et d'intégration, etc) ne sont généralement pas pris en compte…
Quelques irréductibles (avec des compétences en interne) utilisent Debian (ou autre) mais c'est parfois un peu rock n' roll :)
# En dehors du périmètre fonctionnel
Posté par Rémi PALANCHER (site web personnel) . En réponse au message Puppet, remonter une conf du client vers le serveur ?. Évalué à 1.
Je ne pense pas que ce soit possible, Puppet n'est tout simplement pas conçu pour cela :) L'idée des outils de gestion de conf est d'avoir un référentiel central et de s'assurer qu'il est bien appliqué partout. Là, tu es en dehors du périmètre fonctionnel !
Éventuellement, tu peux demander à Puppet de ne pas remplacer le fichier sur le nœud si la prod est différente de son référentiel (voir l'attribut replace sur la ressource File). Tu peux aussi demander à Puppet de reporter le diff entre la prod et le référentiel (attribut show_diff).
Pour ton cas d'usage, tu peux aussi configurer un filebucket et réaliser des backups (avec l'attribut du même nom). Ainsi, lorsque Puppet réalise que les fichiers en production sont différents du référentiel, il réalise un backup du fichier sur le master avant de le modifier sur le nœud.
[^] # Re: Remarques
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 1. Dernière modification le 01 juin 2012 à 10:01.
Effectivement, DIET est développé principalement par l'équipe de recherche GRAAL, notamment rattachée à l'INRIA (recherche en informatique et automatique) et non pas à l'INRA (recherche en agronomie).
[^] # Re: 100% ok avec xnx
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Stratégie Open-source à EDF R&D. Évalué à 3.
Je t'invite à tester Calibre7 qui est une mise à jour très importante pour les postes de travail. Le nombre de problèmes utilisateurs résolu est très important. Et si tu rencontres des problèmes avec Calibre, les circuits sont en place pour les remonter.
J'ai du mal à comprendre comment on peut incriminer une distribution logicielle pour un problème d'architecture SI...
Un certain nombre de chantiers importants autour de Calibre sont déjà bien engagés.
[^] # Re: Politique du SI
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Stratégie Open-source à EDF R&D. Évalué à 5.
Perdu sur plusieurs points.
Nous développons une solution de poste de travail nommée Calibre, basée sur Debian, pour l'instant réservée à l'informatique scientifique, etc :
Nous nous basons sur les versions majeures de Debian pour caler les versions majeures de Calibre mais tout le processus de releasing est géré par une équipe interne pour déclencher les migrations de versions.
Pas de support éditeur externe pour ce qui est purement issu de Calibre, l'équipe de dev interne assure tout le support N3-4.
# Travailler plus, pour plus de lapsus.
Posté par Rémi PALANCHER (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 3.
Tu travailles vraiment trop /o\
[^] # Re: Benjamin Bayart reste fidèle à lui même… et Free dans tout ça
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Entretien de B. Bayart sur ecrans.fr. Évalué à 7.
Je n'ai pas vu où il disait que FDN était le premier associatif. Espérons qu'ils ne soient pas le dernier.
Avec un avis aussi tranché, tu dois pouvoir nous expliquer en quoi le dégroupage est un modèle qui pue depuis le début, non ?
[^] # Re: Taux d'utilisation ?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 4.
J'en connais un certains nombre de clusters qui ont été acheté en oubliant la clim, les installations électriques, et les gens compétents pour faire tourner tout ça. À la fin, ça fait du pognon gaspillé dans du matériel qui sert pas à grand chose.
Pour le problème du transfert des données, il est tout relatif en France. On a la chance d'avoir Renater, et c'est pas vraiment difficile de trouver une connexion réseau inter-labos qui carbure à 1Gb/s. Et dans ce cas là, c'est rarement le réseau le bottleneck.
Pour l'excuse des clusters non utilisés la nuit et pendant les vacances faute de chercheurs qui travaillent en permanence, c'est notamment pour cette raison qu'on utilise des batchs schedulers. Et il y en a qui seraient ravis de pouvoir utiliser toutes ces ressources machines en balançant des trucs automatiquement dessus quand personne ne s'en sert.
[^] # Re: Taux d'utilisation ?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 1.
C'est juste un type de job spécifique à paramétrer lors des réservations.
[^] # Re: Taux d'utilisation ?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 2.
Pour la doc, ça pourrait m'intéresser, mais je voudrais être sûr de ne pas avoir d'ennui avec les gens du DoE... ;)
Et sinon, il y a des codes autre que le Linpack qui utilisent la config avec un pourcentage convenable de sa puissance théorique ?
[^] # Re: Taux d'utilisation ?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 1.
Si il y a des infos sur l'archi de la config ça m'intéresse :) Même si j'ai peur qu'avec Cray, il y ait beaucoup de bidules propriétaires autour des CPU AMD...
[^] # Re: Taux d'utilisation ?
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Le classement Top 500 de juin 2009 est disponible. Évalué à 3.
Aujourd'hui, on peut déployer du Xen partout, et du KVM sur pas mal de clusters. On a même un environnement et une infrastructure en cours de déploiement pour faire ça avec des scripts de quelques lignes, sur toute la grille. Dans des horizons proches, ce sera même interfacé avec une API en web services REST, pour faire un truc qui ressemble à ce que certains appelent du «cloud computing».
Il n'y a pas 6000 noeuds sur la plate-forme, il y en a environ 1500. Mais si j'en crois ton commentaire[1], si tu bosses sur une configuration de 18688 noeuds, je suppose que c'est une BG. On est d'accord pour dire que la définition de «noeud» dans la terminologie BG n'est pas comparable à celle de la terminologie cluster x86_64 ? ;) Donc non, on ne peut pas réserver 6000 noeud BG en quelques minutes sur g5k, mais on peut réserver plus de 1000 serveurs pour après demain et installer la distrib qu'on veut dessus, avec tous les droits root et un accès à des réseaux sympathiques.
Pour être plus précis, il ne faut pas comparer grid'5000 à une grille informatique de calcul. On pourrait appeler ça un plateforme expérimentale distribuée, dédiée et reconfigurable, où l'une des formes possibles est une grille informatique de calcul ;) C'est pour cette raison que la plate-forme est notamment utilisée pour prototyper des codes de calcul de production.
Pour finir, aujourd'hui en France et AFAIK en Europe, je ne connais pas d'instrument scientifique informatique de cette échelle qui soit aussi simplement accessible ; ie. on demande un compte, on peut réserver plusieurs centaines de noeuds le lendemain. Mais je m'avance peut-être.
Voilà, c'était juste pour éclaircir les choses ;)
[1] https://linuxfr.org/comments/1042761,1.html
[^] # Re: La machine virtuelle par défaut est basée sur User Mode Linux
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Cloonix : création graphique de réseaux virtuels. Évalué à 3.
Si j'ai bien compris, le démon d'émulation de switch de Cloonix fonctionne un peu pareil, avec des sockets. À mon avis, ce serait intéressant de pouvoir réutiliser toutes les fonctionnalités des équipements réseaux virtuels VDE pour les utiliser dans Cloonix. En plus, ça aurait le bon goût d'être compatible avec les nouvelles versions de KVM...
[1] http://vde.sourceforge.net/
[^] # Re: corrections
Posté par Rémi PALANCHER (site web personnel) . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 4.
"Linus Torvald a plusieurs fois exprimé sont opinion à ce sujet"
"Certains types d'applications pourraient très bien se passer de la couche de communication du serveur X (téléphonie, GPS, embarqué etc)."
"ce mécanisme aux autres types de carte (ATI et Nvidia)."
En tout cas, merci pour cette belle dépêche, très intéressante quand on ne suit pas de près le développement de ce projet :)
[^] # Re: Acheter de la musique
Posté par Rémi PALANCHER (site web personnel) . En réponse au journal Amarok et Magnatune : échanges de bons procédés entre amis. Évalué à 1.
Il existe des plugins pour Rythmbox et Amarok pour écouter ces mêmes versions en se passant du blob.
Quand on décide de passer à la caisse (avec des $ et des frais de change), en fixant soit même le montant, on accède à une liste de liens vers différentes versions de l'album : MP3 320kbits, Ogg Vorbis, VBR/AAC, Flac, WAV sans perte. On peut télécharger la pochette haute qualité au format PDF.
Il me semble que l'ensemble du catalogue (en tout cas, pour les albums que j'ai acheté) est sous une des licences CC.