Depuis quand une critique est-elle considérée comme un troll ? Non, parce qu'à ce train là un peu près n'importe quelle réponse est un troll…
Pour moi le troll est sur les mots « Internet » et « décentralisé », c'est un débat qui ne finira jamais car on a deux avis différents sur les mots, et c'est juste de la sémantique. J'avoue avoir un peu nourri ce troll malgré moi dans mes commentaires.
Bref, je respecte ton avis sur « Internet décentralisé », il ne change pas le miens, mais c'est pas ce débat qui m'intéresse.
Ce qui m'intéresse c'est d'aider à vulgariser les travaux autours de GNUnet, qui au passage parlent bien de « services décentralisés » et « d'infrastructure décentralisée » :)
Tout d'abord, merci de présenter/partager ton projet.
Voilà, maintenant je peux troller l'esprit tranquille :)
Le paquet utilise BSD Make (bmake) et BSD Owl scripts il montre donc comment utiliser cet outil pour distribuer et préparer des scripts shell complexes. Le code shell est aussi intéressant à étudier pour ceux qui veulent étudier la programmation en shell.
Pourquoi s'infliger le Bourne Shell alors qu'il existe pléthore de langages plus adéquates pour des projets de scripts « complexes » (Python, Ruby, Lua, name_your_favorite_langage,…) ? C'est le syndrome de Stockholm ?
Je trolle un peu vite car il existe un avantage indéniable : l'interpréteur est disponible sur la plupart des Linux/BSD/Unix based OS d'aujourd'hui. Mais quand je vois le niveau de soin apporté à ce projet (oui je dis que d'habitude les projets Shell c'est crade…), je me demande : est-ce la seule raison ?
Autre question, il y a deux licences dans ton source et tu ne mentionnes nulle-part la licence principale. C'est CeCILL-B ?
À vrai dire, j'ai surtout l'impression qu'il y a confusion entre Internet lui-même et les entités qui le composent. Le fait que ces entités recourent à une structure centralisée ou décentralisée en interne n'affecte en rien celle du réseau et ne lui donne pas un centre.
Tu as raison, mais ne t'arrêtes pas au troll, proposes des termes adéquates, qu'on puisse dire au gens de GNUnet de les utiliser !
Alors quel nom donnes tu à l'ensemble des services (réseau IP, mais aussi mail, messagerie, services applicatifs,…) utilisé par tout le monde tous les jours via ordinateurs, smartphone et autres. Bien que je sois capable de faire la distinction que tu expliques, moi je parle d'« Internet » avec ma famille, amis, …
Je comprend tout à fait ce que tu dis, mais tu ne proposes pas d'alternative. Et ce qui me dérange, c'est que je ne suis pas capable d'en trouver une autre que « Internet », même si je te l'accorde : c'est faux par rapport au sens initial ! C'est une dérive liée au fait que peu de gens sont capables de comprendre la nuance que tu précises, et que pour expliquer des idées de recherches on a besoin de vulgariser.
Pour la décentralisation c'est pareil, on est face à de la « vulgarisation » : ce mal essentiel à la diffusion des idées récentes issues de la recherche. Comment on doit nommer le processus qui vise à éliminer les points de centralisation des protocoles ou services qui « composent » ou « sont utilisés au dessus » d'Internet ?
Moi je veux bien troller pour troller, mais il faut comprendre que pour des travaux de recherche comme ceux de GNUnet : on doit passer au moins 50% du temps à trouver un discours vulgarisé pour expliquer les idées saugrenues qu'on essaie de creuser. Du coup on fait dans l'« à peu prés » au niveau du vocabulaire, mais si on pouvait avoir des critiques positives en retour, plutôt que du troll gratuit, ça serait encourageant :)
PS : Taurre je n'ai rien contre toi, au contraire, j'avoue que tu prends un peu pour l'ensemble du troll ambiant non constructif, dont je suis aussi parfois acteur :)
C'est compliqué, car les termes « Internet » et « décentralisé » sont flous. Personnellement je ne suis pas pour « trancher » sur ce que veulent dire l'un et l'autre, mais pour expliquer les problèmes mal compris derrière l'expression GNUnet « Internet décentralisé ».
Essayons de faire le point :
Internet
Est-ce qu'on parle du protocole IP, ce qui semble être le cas de Taurre, ou d'un réseau plus large (Cf. Internet), ce qui semble être le cas de GNUnet ?
Personnellement, je ne sais pas définir clairement Internet, mais je comprend que dans le terme « Internet décentralisé » du titre de la dépêche, on ne parle pas du protocole IP, mais d'Internet au sens Suite des protocoles Internet.
Décentralisé
Un terme qui est la plupart du temps employé en économie pour imager la séparation géographique des pouvoirs, par exemple d'une capitale vers des provinces. Il n'y a pas de définition claire de « décentralisé » en informatique à ma connaissance. Il y a quand même une idée rémanente d'éliminer le contrôle d'Internet par une ou plusieurs autorités (type routeur BGP pour les « systèmes autonomes » alias « AS », ou encore les serveurs primaires DNS).
Un truc important : dans les travaux autour de GNUnet, on modélise Internet avec plusieurs centres. Pour rester sur l'exemple du protocole IP, on a la notion de routeurs, par exemple les routeurs BGP, qui ont autorité sur les adresses IP du sous-domaine qui leur est attribué. Ces routeurs sont considérés comme des « centres », au moins pour leur sous-réseau, par les gens de GNUnet et co. Donc on a un Internet IP effectivement acentré, mais avec des sous-domaines, qui eux ont des centres. À vous de décidez (ou pas) sur le fait que cela implique un Internet centralisé ou non…
Du coup on a une notion, peu ou pas du tout explicitée, de « partiellement centralisé ». Et pour ceux qui considèrent qu'Internet est en ensemble de protocoles (dont GNUnet je pense), il ne sera considéré comme « décentralisé » que quand on pourra l'utiliser au quotidien (mail, messagerie, …etc) avec des protocoles « totalement décentralisés ».
Pour ceux qui ont tout suivi :) Là où c'est ironique : c'est que GNUnet veut proposer un Internet « totalement décentralisé » sur la base du protocole IP, qu'ils considèrent comme « partiellement centralisé ». À noter qu'il existe de multiples protocoles de routages totalement décentralisés, notamment à base de DHT ou de gossip (protocoles épidémiques). Mais même s'il ne se limite pas à ce protocole, sortir d'IP, c'est sortir d'Internet :)
En fait, un truc pas facile à appréhender dans ces travaux de recherches, c'est que « décentralisé » signifie « pair-à-pair », et est opposé à « partiellement décentralisé ».
L'aspect « centralisation » fait plutôt référence à la présence d'une autorité centrale, comme par exemple : les serveurs DNS primaires, les serveurs d’authentification dans les services de messageries.
Un protocole décentralisé serait plutôt du genre Bitcoin, où tous les services qui se basent sur son principe (Twister, NameCoin, …etc).
Attention, un truc pas facile à piger, que j'ai déjà tenté d'expliquer je me sais plus où : même XMPP et le SMTP sont « partiellement-centralisés » dans ce contexte, dans le sens, où même si on à une gestion de domaine décentralisée, chaque domaine possède toujours un ou plusieurs serveurs de référence, lesquels constituent des points de faiblesse pour le service global.
Enfin, bon il y a long à dire, mais non : ces travaux ne disent pas qu'Internet est « totalement centralisé », et non : Internet n'est pas « totalement décentralisé ».
Donc, j'ai du mal à comprendre le problème d'avoir une huile figé à 0° si tu n'as pas de chaleur à dissiper.
Si l'huile s’épaissit j'imagine qu'il y a risque de rupture de la gaine ou de la durite qui la contient. Il y a pas mal d'endroits où on peut avoir du +40ºC le jours et du négatif la nuit.
Sinon vejmarie, c'est bien : c'est culotté comme projet !
C'est un peu le compromis de tout ordinateur non ? à partir de quel seuil de dissipation thermique on gagne à dépenser de l'énergie en refroidissement (ventilo ou watercooling) ? C'est lié à plein de paramètres compliqués, par exemple jusqu'à quelle température tes nano-transitors fonctionnent bien ? Et quand on réfléchit à l'échelle d'un « datacenter », c'est même un point crucial !
Bref, c'est une question généralement très difficile, et qui je pense fait le fond de commerce de RuggedPOD (ou alors j'ai rien compris).
Je réagissait de façon (un peu) ironique à la phrase suivante :
100% of the electricity brought to RuggedPOD is used by electronic devices.
J'imagine que c'est pour dire qu'on ne perd pas d'énergie électrique en refroidissement, et qu'on optimise malgré tout la température de l'ordinateur, via du refroidissement « naturel » en mettant les ordinateurs à l'extérieur. Mais pourquoi ne pas le dire explicitement alors ?
Peut être que ça soulèverait l'épineuse question de la maîtrise de la température ?
C'est comme dire que ça marche en plein désert ou en pleine Jungle : on sent qu'ils ont réfléchis aux problèmes de chaleur, variation de température et humidité, mais on a que des belles paroles (ce qui est déjà mieux que rien), pas de chiffres !
C'est un pari marketing, mais si jamais ils ont un client sérieux qui veut faire un datacenter dans le désert (Moyen-Orient ?), il va falloir assurer avec plus que des belles paroles. Il en va de la réputation du monde du libre ! (ou pas …)
"RuggedPOD works in deserts, high humidity jungles, countryside fields, roofs, as long as you don’t expose it to direct sunlight."
Excellent !
Non pas que je critique l'utilité de monter un cloud en pleine jungle ou un plein désert (après tout, c'est là que le réseau électrique est le meilleur et le moins cher…), mais je voudrais pour chaque cas mentionné ci-dessus une photo avec coordonnées GPS certifiées.
Heuu, juste pour dire que Vulkan : ça claque comme nom !
Les noms avec open, en plus de faire peur aux moldus (si il y a « open » dans le nom, c'est la version abandonnée d'un projet commercial), c'est tellement ordinaire.
Surtout qu'il est très facile dans evilmode de surcharger Ctrl+s, Ctrl+x, …. Pour remapper ces combinaisons de touches sur les classiques "save", "cut", … si le besoin s'en fait vraiment sentir.
Logiciel libre ou pas, cela reste un détail. Ton logiciel libre pourra toujours buguer ou se faire pirater, le matériel pourra poser souci, rien ne garantira que le logiciel installé à Poitiers est le même que celui testé à Paris (on n'auditera pas le code source de chaque machine le matin du vote)
Clairement si, il faudra auditer chaque machine ou du moins permettre que ça le soit, comme on peut aujourd'hui vérifier les urnes, les bulletins, le dépouillement, …etc.
Évidemment il faut réfléchir à simplifier la procédure d'audit, mais je pense que par rapport à un dépouillement à la main, on doit pouvoir y gagner en temps et en ressource.
Et pour finir, ce qui me gène, c'est que sans logiciel libre, on a même pas le droit de savoir ce qui se passe dans la boite de vote électronique. Pour moi il y a une différence fondamentale entre pouvoir vérifier et effectivement vérifier, mais ça doit être mon caractère, je suis sûrement marginal :)
Je ne pense pas que Bitcoin soit le candidat idéal pour le vote électronique, et ce, pour deux raisons :
Ce n'est pas écologique. Le principe de Bitcoin est de fournir des preuves de travail pour éviter la falsification. L'article de Stéphane Bortzmeyer l'explique très bien : on a un compromis entre « gâcher de la ressource de calcul » et fournir un protocole sécurisé. J'imagine que personne ne serait prêt à s’asseoir sur la sécurité pour du vote électronique, donc si on se base sur Bitcoin ça sera très cher en ressources de calcul et très peu écologique.
Pourquoi en décentralisé ? Je suis un évangéliste de la décentralisation, et des protocoles basés sur Bitcoin (cf. la dépêche sur le p2p), pourtant je ne vois pas l'intérêt de décentraliser le vote électronique. Ou plutôt, ce n'est pas l'aspect primordial pour moi, l'important étant que les logiciels de vote électronique soient libres ! Personnellement, cela ne me dérange pas que mes votes soient organisés par ma commune (donc un vote semi-centralisé), mais le fait de voter sur une machine de type « boite noire » dont on ne connaît pas le code, ça me dérange vraiment.
Donc ma conclusion serait : faisons d'abord un truc simple et non décentralisé à base de Logiciel Libre, et on verra après pour le décentraliser, si possible avec autre chose que Bitcoin (sinon ça va faire chauffer les datacenters pour rien).
Je parle pas vraiment de faire de la preuve de protocole
Tout à fait, et moi je dis que faire la preuve du protocole c'est l'approche de la méthode B, qui de mon point de vue n'est pas idéale, bien que sûrement pas inutile ici :)
Le problème c'est que ce n'est pas l'objectif de la méthode B ! Si une méthode ou un langage était le meilleur dans tous les domaines de l'informatique ça se saurait. Mais non, on préfère faire des outils spécialisés car les problématiques sont aussi différentes que complexes et que si l'on veut des choses très fiables (i.e. prouvées formellement) il faut se concentrer sur des domaines précis, dans un premier temps.
Je ne pense pas que « B » ait vocation à faire de la preuve de protocole, ce qui ne signifie pas que c'est un mauvais outil, au contraire !
C'est tout le problème, tu mets le doigt dessus en plus.
Si tu réfléchis simplement au niveau IO, il te manque le contexte du protocole : tu prouves seulement qu'une réception, indépendamment des autres, se passe bien.
Si tu réfléchis au niveau du protocole (i.e. spec.) tu trouves des cas, comme celui que la faille exploite, qui mettent en jeu une séquence de requêtes plus ou moins complexe (et non une seule requête) et des individus byzantins, c'est-à-dire des individus qui pourront exploiter n'importe quelque comportement pour compromettre le système.
Le correctif se traduit évidemment par un patch au niveau du code, mais pour voir la faille il faut se placer au niveau du protocole.
Effectivement l'avantage de la méthode B est de couvrir tout le processus de réalisation (de la spec. à l'implémentation) d'un système. Cela dit, elle a ses propres limites, que je ne connais pas dans le détail et qui résident dans le nombre de fonctionnalités qu'elles propose (ce qui va se réduire au jeu d'instructions du langage d'implémentation à un moment de la méthode).
Ce dont je suis sûr, pour en avoir discuté avec un des pères de la méthode B, c'est que cette méthode ne permet pas la communication par message. En gros elle fonctionne sur un système fermé, type ligne 14 ou système bancaire clos (domaine dans lequel elle est aussi utilisée). C'est tout à fait normal, car un système distribué est plus complexe à modéliser et on ne sait pas encore faire des outils type « méthode B » qui intègrent toutes les hypothèses d'un système distribué.
Donc pour en revenir au journal, non on ne peut pas utiliser B pour SSL !
[^] # Re: Internet n'a pas de centre
Posté par vlamy (site web personnel) . En réponse à la dépêche Présentation de GNUnet - Internet décentralisé, à Rennes le 24 mars 2015. Évalué à 2.
Pour moi le troll est sur les mots « Internet » et « décentralisé », c'est un débat qui ne finira jamais car on a deux avis différents sur les mots, et c'est juste de la sémantique. J'avoue avoir un peu nourri ce troll malgré moi dans mes commentaires.
Bref, je respecte ton avis sur « Internet décentralisé », il ne change pas le miens, mais c'est pas ce débat qui m'intéresse.
Ce qui m'intéresse c'est d'aider à vulgariser les travaux autours de GNUnet, qui au passage parlent bien de « services décentralisés » et « d'infrastructure décentralisée » :)
[^] # Re: Un amoureux du Bourne Shell
Posté par vlamy (site web personnel) . En réponse au journal Assistant de projet logiciel. Évalué à 5.
Bon je suis content d'avoir posé la question parce qu'effectivement il y a des vrais arguments :)
Je vais peut être reconsidérer le shell (j'ai vu que tu avais fait un article sur les bonnes pratiques de ce langage).
Sinon… pour la licence ?
# Un amoureux du Bourne Shell
Posté par vlamy (site web personnel) . En réponse au journal Assistant de projet logiciel. Évalué à 5.
Tout d'abord, merci de présenter/partager ton projet.
Voilà, maintenant je peux troller l'esprit tranquille :)
Pourquoi s'infliger le Bourne Shell alors qu'il existe pléthore de langages plus adéquates pour des projets de scripts « complexes » (Python, Ruby, Lua, name_your_favorite_langage,…) ? C'est le syndrome de Stockholm ?
Je trolle un peu vite car il existe un avantage indéniable : l'interpréteur est disponible sur la plupart des Linux/BSD/Unix based OS d'aujourd'hui. Mais quand je vois le niveau de soin apporté à ce projet (oui je dis que d'habitude les projets Shell c'est crade…), je me demande : est-ce la seule raison ?
Autre question, il y a deux licences dans ton source et tu ne mentionnes nulle-part la licence principale. C'est CeCILL-B ?
[^] # Re: Internet n'a pas de centre
Posté par vlamy (site web personnel) . En réponse à la dépêche Présentation de GNUnet - Internet décentralisé, à Rennes le 24 mars 2015. Évalué à 3.
Tu as raison, mais ne t'arrêtes pas au troll, proposes des termes adéquates, qu'on puisse dire au gens de GNUnet de les utiliser !
Alors quel nom donnes tu à l'ensemble des services (réseau IP, mais aussi mail, messagerie, services applicatifs,…) utilisé par tout le monde tous les jours via ordinateurs, smartphone et autres. Bien que je sois capable de faire la distinction que tu expliques, moi je parle d'« Internet » avec ma famille, amis, …
Je comprend tout à fait ce que tu dis, mais tu ne proposes pas d'alternative. Et ce qui me dérange, c'est que je ne suis pas capable d'en trouver une autre que « Internet », même si je te l'accorde : c'est faux par rapport au sens initial ! C'est une dérive liée au fait que peu de gens sont capables de comprendre la nuance que tu précises, et que pour expliquer des idées de recherches on a besoin de vulgariser.
Pour la décentralisation c'est pareil, on est face à de la « vulgarisation » : ce mal essentiel à la diffusion des idées récentes issues de la recherche. Comment on doit nommer le processus qui vise à éliminer les points de centralisation des protocoles ou services qui « composent » ou « sont utilisés au dessus » d'Internet ?
Moi je veux bien troller pour troller, mais il faut comprendre que pour des travaux de recherche comme ceux de GNUnet : on doit passer au moins 50% du temps à trouver un discours vulgarisé pour expliquer les idées saugrenues qu'on essaie de creuser. Du coup on fait dans l'« à peu prés » au niveau du vocabulaire, mais si on pouvait avoir des critiques positives en retour, plutôt que du troll gratuit, ça serait encourageant :)
PS : Taurre je n'ai rien contre toi, au contraire, j'avoue que tu prends un peu pour l'ensemble du troll ambiant non constructif, dont je suis aussi parfois acteur :)
[^] # Re: Internet n'a pas de centre
Posté par vlamy (site web personnel) . En réponse à la dépêche Présentation de GNUnet - Internet décentralisé, à Rennes le 24 mars 2015. Évalué à 2.
C'est compliqué, car les termes « Internet » et « décentralisé » sont flous. Personnellement je ne suis pas pour « trancher » sur ce que veulent dire l'un et l'autre, mais pour expliquer les problèmes mal compris derrière l'expression GNUnet « Internet décentralisé ».
Essayons de faire le point :
Internet
Est-ce qu'on parle du protocole IP, ce qui semble être le cas de Taurre, ou d'un réseau plus large (Cf. Internet), ce qui semble être le cas de GNUnet ?
Personnellement, je ne sais pas définir clairement Internet, mais je comprend que dans le terme « Internet décentralisé » du titre de la dépêche, on ne parle pas du protocole IP, mais d'Internet au sens Suite des protocoles Internet.
Décentralisé
Un terme qui est la plupart du temps employé en économie pour imager la séparation géographique des pouvoirs, par exemple d'une capitale vers des provinces. Il n'y a pas de définition claire de « décentralisé » en informatique à ma connaissance. Il y a quand même une idée rémanente d'éliminer le contrôle d'Internet par une ou plusieurs autorités (type routeur BGP pour les « systèmes autonomes » alias « AS », ou encore les serveurs primaires DNS).
Un truc important : dans les travaux autour de GNUnet, on modélise Internet avec plusieurs centres. Pour rester sur l'exemple du protocole IP, on a la notion de routeurs, par exemple les routeurs BGP, qui ont autorité sur les adresses IP du sous-domaine qui leur est attribué. Ces routeurs sont considérés comme des « centres », au moins pour leur sous-réseau, par les gens de GNUnet et co. Donc on a un Internet IP effectivement acentré, mais avec des sous-domaines, qui eux ont des centres. À vous de décidez (ou pas) sur le fait que cela implique un Internet centralisé ou non…
Du coup on a une notion, peu ou pas du tout explicitée, de « partiellement centralisé ». Et pour ceux qui considèrent qu'Internet est en ensemble de protocoles (dont GNUnet je pense), il ne sera considéré comme « décentralisé » que quand on pourra l'utiliser au quotidien (mail, messagerie, …etc) avec des protocoles « totalement décentralisés ».
Pour ceux qui ont tout suivi :) Là où c'est ironique : c'est que GNUnet veut proposer un Internet « totalement décentralisé » sur la base du protocole IP, qu'ils considèrent comme « partiellement centralisé ». À noter qu'il existe de multiples protocoles de routages totalement décentralisés, notamment à base de DHT ou de gossip (protocoles épidémiques). Mais même s'il ne se limite pas à ce protocole, sortir d'IP, c'est sortir d'Internet :)
Et là c'est drôle !
[^] # Re: "Décentralisé"
Posté par vlamy (site web personnel) . En réponse à la dépêche Présentation de GNUnet - Internet décentralisé, à Rennes le 24 mars 2015. Évalué à 2.
perdu :) Même si tu as raison pour la mauvaise traduction de « Mesh Network ».
Cf. ma première réponse.
[^] # Re: Internet n'a pas de centre
Posté par vlamy (site web personnel) . En réponse à la dépêche Présentation de GNUnet - Internet décentralisé, à Rennes le 24 mars 2015. Évalué à 5.
En fait, un truc pas facile à appréhender dans ces travaux de recherches, c'est que « décentralisé » signifie « pair-à-pair », et est opposé à « partiellement décentralisé ».
L'aspect « centralisation » fait plutôt référence à la présence d'une autorité centrale, comme par exemple : les serveurs DNS primaires, les serveurs d’authentification dans les services de messageries.
Un protocole décentralisé serait plutôt du genre Bitcoin, où tous les services qui se basent sur son principe (Twister, NameCoin, …etc).
Attention, un truc pas facile à piger, que j'ai déjà tenté d'expliquer je me sais plus où : même XMPP et le SMTP sont « partiellement-centralisés » dans ce contexte, dans le sens, où même si on à une gestion de domaine décentralisée, chaque domaine possède toujours un ou plusieurs serveurs de référence, lesquels constituent des points de faiblesse pour le service global.
Enfin, bon il y a long à dire, mais non : ces travaux ne disent pas qu'Internet est « totalement centralisé », et non : Internet n'est pas « totalement décentralisé ».
[^] # Re: Prix d'appel
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 1. Dernière modification le 14 mars 2015 à 11:17.
Raté :)
Pour le coup, je rejoins la question de Nicolas Boulay : quelle est le rôle des huiles végétales en fait ?
[^] # Re: Prix d'appel
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 2.
Si l'huile s’épaissit j'imagine qu'il y a risque de rupture de la gaine ou de la durite qui la contient. Il y a pas mal d'endroits où on peut avoir du +40ºC le jours et du négatif la nuit.
Sinon vejmarie, c'est bien : c'est culotté comme projet !
[^] # Re: par soleil ?
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 2.
La classe !
[^] # Re: US international
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 4.
J'utilise Qwerty-Lafayette au quotidien, sur un qwerty us, et ça me va très bien !
Et en bonus, ça énerve le chef de projet que j'ai un mapping différent…. :(
[^] # Re: Prix d'appel
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 3.
C'est un peu le compromis de tout ordinateur non ? à partir de quel seuil de dissipation thermique on gagne à dépenser de l'énergie en refroidissement (ventilo ou watercooling) ? C'est lié à plein de paramètres compliqués, par exemple jusqu'à quelle température tes nano-transitors fonctionnent bien ? Et quand on réfléchit à l'échelle d'un « datacenter », c'est même un point crucial !
Bref, c'est une question généralement très difficile, et qui je pense fait le fond de commerce de RuggedPOD (ou alors j'ai rien compris).
Je réagissait de façon (un peu) ironique à la phrase suivante :
J'imagine que c'est pour dire qu'on ne perd pas d'énergie électrique en refroidissement, et qu'on optimise malgré tout la température de l'ordinateur, via du refroidissement « naturel » en mettant les ordinateurs à l'extérieur. Mais pourquoi ne pas le dire explicitement alors ?
Peut être que ça soulèverait l'épineuse question de la maîtrise de la température ?
C'est comme dire que ça marche en plein désert ou en pleine Jungle : on sent qu'ils ont réfléchis aux problèmes de chaleur, variation de température et humidité, mais on a que des belles paroles (ce qui est déjà mieux que rien), pas de chiffres !
C'est un pari marketing, mais si jamais ils ont un client sérieux qui veut faire un datacenter dans le désert (Moyen-Orient ?), il va falloir assurer avec plus que des belles paroles. Il en va de la réputation du monde du libre ! (ou pas …)
[^] # Re: Prix d'appel
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 4.
Et quel marketing !
Jungles et déserts fallait les oser celles-ci ! Maintenant on veut des preuves :)
0% de dissipation thermique ! Chapeau ! (mais bon, c'est pas dit qu'on peut l'utiliser sur la banquise).
Vu ici et là.
La pub par le appeau à troll, ça c'est du marketing comme j'aime :)
Continuez !
[^] # Re: par soleil ?
Posté par vlamy (site web personnel) . En réponse au journal Ou en est RuggedPOD ? Premiere VM a 1 euro annoncee. Évalué à 5.
Excellent !
Non pas que je critique l'utilité de monter un cloud en pleine jungle ou un plein désert (après tout, c'est là que le réseau électrique est le meilleur et le moins cher…), mais je voudrais pour chaque cas mentionné ci-dessus une photo avec coordonnées GPS certifiées.
# Vulkan ça défonce de l'ours en barre !
Posté par vlamy (site web personnel) . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 10.
Heuu, juste pour dire que Vulkan : ça claque comme nom !
Les noms avec open, en plus de faire peur aux moldus (si il y a « open » dans le nom, c'est la version abandonnée d'un projet commercial), c'est tellement ordinaire.
Si ! C'est important !
[^] # Re: Pêche à la dynamite
Posté par vlamy (site web personnel) . En réponse au journal La révolution autour du poignet . Évalué à 4.
Ben c'est à dire qu'avec un tel titre, qui plus est un vendredi après-midi, on s'attend à autre chose…
[^] # Re: Commentaire du jour
Posté par vlamy (site web personnel) . En réponse au journal Des prompteurs pour Emacs. Évalué à 4.
Je ne connaissais pas les advices dans emacs, ça à l'air bien ce truc !
Dans le contexte « Evil » je ne vois pas trop ce que ça apporte, mais c'est puissant comme fonctionnalité :)
[^] # Re: Ergonomics
Posté par vlamy (site web personnel) . En réponse au journal Des prompteurs pour Emacs. Évalué à 1. Dernière modification le 25 juillet 2014 à 13:58.
Le pouce OK ! pour le M-, mais pourquoi l'index? ils sont où le « s » et le « w » sur ton clavier ?
[^] # Re: Commentaire du jour
Posté par vlamy (site web personnel) . En réponse au journal Des prompteurs pour Emacs. Évalué à 2.
+1
Surtout qu'il est très facile dans evilmode de surcharger Ctrl+s, Ctrl+x, …. Pour remapper ces combinaisons de touches sur les classiques "save", "cut", … si le besoin s'en fait vraiment sentir.
[^] # Re: Priorité au logiciel libre
Posté par vlamy (site web personnel) . En réponse au journal Bitcoin : votre avis sur un article que je viens de lire sur de possibles utilisations alternatives.. Évalué à -1.
Clairement si, il faudra auditer chaque machine ou du moins permettre que ça le soit, comme on peut aujourd'hui vérifier les urnes, les bulletins, le dépouillement, …etc.
Évidemment il faut réfléchir à simplifier la procédure d'audit, mais je pense que par rapport à un dépouillement à la main, on doit pouvoir y gagner en temps et en ressource.
Et pour finir, ce qui me gène, c'est que sans logiciel libre, on a même pas le droit de savoir ce qui se passe dans la boite de vote électronique. Pour moi il y a une différence fondamentale entre pouvoir vérifier et effectivement vérifier, mais ça doit être mon caractère, je suis sûrement marginal :)
# Priorité au logiciel libre
Posté par vlamy (site web personnel) . En réponse au journal Bitcoin : votre avis sur un article que je viens de lire sur de possibles utilisations alternatives.. Évalué à 2. Dernière modification le 29 avril 2014 à 09:37.
Je ne pense pas que Bitcoin soit le candidat idéal pour le vote électronique, et ce, pour deux raisons :
Donc ma conclusion serait : faisons d'abord un truc simple et non décentralisé à base de Logiciel Libre, et on verra après pour le décentraliser, si possible avec autre chose que Bitcoin (sinon ça va faire chauffer les datacenters pour rien).
[^] # Re: On verra
Posté par vlamy (site web personnel) . En réponse à la dépêche Core Infrastructure Initiative. Évalué à 3.
Tout à fait, et moi je dis que faire la preuve du protocole c'est l'approche de la méthode B, qui de mon point de vue n'est pas idéale, bien que sûrement pas inutile ici :)
[^] # Re: On verra
Posté par vlamy (site web personnel) . En réponse à la dépêche Core Infrastructure Initiative. Évalué à 2.
Le problème c'est que ce n'est pas l'objectif de la méthode B ! Si une méthode ou un langage était le meilleur dans tous les domaines de l'informatique ça se saurait. Mais non, on préfère faire des outils spécialisés car les problématiques sont aussi différentes que complexes et que si l'on veut des choses très fiables (i.e. prouvées formellement) il faut se concentrer sur des domaines précis, dans un premier temps.
Je ne pense pas que « B » ait vocation à faire de la preuve de protocole, ce qui ne signifie pas que c'est un mauvais outil, au contraire !
[^] # Re: On verra
Posté par vlamy (site web personnel) . En réponse à la dépêche Core Infrastructure Initiative. Évalué à 1.
C'est tout le problème, tu mets le doigt dessus en plus.
Si tu réfléchis simplement au niveau IO, il te manque le contexte du protocole : tu prouves seulement qu'une réception, indépendamment des autres, se passe bien.
Si tu réfléchis au niveau du protocole (i.e. spec.) tu trouves des cas, comme celui que la faille exploite, qui mettent en jeu une séquence de requêtes plus ou moins complexe (et non une seule requête) et des individus byzantins, c'est-à-dire des individus qui pourront exploiter n'importe quelque comportement pour compromettre le système.
Le correctif se traduit évidemment par un patch au niveau du code, mais pour voir la faille il faut se placer au niveau du protocole.
[^] # Re: On verra
Posté par vlamy (site web personnel) . En réponse à la dépêche Core Infrastructure Initiative. Évalué à 5. Dernière modification le 28 avril 2014 à 09:44.
Effectivement l'avantage de la méthode B est de couvrir tout le processus de réalisation (de la spec. à l'implémentation) d'un système. Cela dit, elle a ses propres limites, que je ne connais pas dans le détail et qui résident dans le nombre de fonctionnalités qu'elles propose (ce qui va se réduire au jeu d'instructions du langage d'implémentation à un moment de la méthode).
Ce dont je suis sûr, pour en avoir discuté avec un des pères de la méthode B, c'est que cette méthode ne permet pas la communication par message. En gros elle fonctionne sur un système fermé, type ligne 14 ou système bancaire clos (domaine dans lequel elle est aussi utilisée). C'est tout à fait normal, car un système distribué est plus complexe à modéliser et on ne sait pas encore faire des outils type « méthode B » qui intègrent toutes les hypothèses d'un système distribué.
Donc pour en revenir au journal, non on ne peut pas utiliser B pour SSL !