TImaniac a écrit 6420 commentaires

Faut pas déconner, y'a quand même des grosses différences entre l'hébergement "à l'ancienne" (dédié ou mutualisé) et ce que propose les offres cloud de type PaaS :

• tu as des ressources de stockage potentiellement infinies sans te soucier de la répartition "physique".
• tu peux créer dynamiquement des instances d'application
• tu as un CDN qui te permets de positionner tes instances aux 4 coins du globes, dynamiquement.
• les services de stockage (SQL ou autre) et les services de communication inter-instances sont abstraits : tu as un "service" de stockage infini sans te soucier du ou des serveurs à contacter réellement, tu as un bus de communication que t'adresse sans te soucier de son adresse physique.
• tu as, outofthebox, quelque soit la répartition : redondance, backup, loadbalancing. En cas de panne hardware, c'est transparent.
• Et surtout, tu ne paies que ce que tu consommes (temps de calcul, mem, stockage).

Et tout ça en même temps, c'est loin d'être trivial à mettre en oeuvre.

Faut arrêter 2 minutes de dire que ca existait avant : la preuve en est que l'offre "cloud" d'OVH est récente, en partie en version "alpha" et loin de ce que propose un Amazon ou un Microsoft en terme de services (cf liste précédente).

C'est marrant, l'article dit exactement l'inverse : le taux de recapture est alors forcement inférieur à 1.

Non clairement le plus gros risque, c'est une explosion chimique classique qui disperserait de grande quantité de matières radioactives.

produit peut contribuer à atteindre la fameuse "masse critique".

Une masse critique ne suffit pas, et c'est ce que semble avoir oublié/ignoré Nesterenko.

http://forums.futura-sciences.com/physique/463643-a-stade-de-fusion-un-coeur-de-reacteur-explose-contact-leau-2.html

C'est déjà arrivé, faudrait prendre un autre exemple

Oui, comme une explosion de centrale aussi d'ailleur :)

http://sciences.blog.lemonde.fr/2009/06/13/un-jeune-allemand-touche-par-une-meteorite/

Je vois qu'ils estiment que l'explosion aurait été d'une puissance de 5 à 8 Mégatonnes et aurait rendu toute l'europe inhabitable.
Je m'empresse d'aller voir la puisse de la plus grosse bombe atomique ayant explosée : 50 mégatonnes.

5 ou 8 mégatonnes auraient, selon ton expert, rendue toute l'europe invivable là où une bombe de 50 mégatonnes (soit 10 fois plus) aurait dû, par extrapolation, rendu la terre entière invivable.

Même la plus grosse bombe américaine de 12 megatonne (CastleBravo), avec des retombées graves n'a pas rayé la moitié du pacifique des zones vivables.

Clairement, ton expert semble déjà totalement à côté de la plaque sur l'impact d'une explosion d'une telle puissance. Donc franchement, sa crédibilité sur la possibilité même d'une telle explosion en prend un sacré coup.

Si c'est le même niveau de proba

Houlà t'emballe pas, j'ai aucune idée du rapport qu'il y a d'un point de vu statistique.

le coup du nuage qui s'arrête à la frontière... Même s'il ne s'est pas arrêté, aucune étude ne montre d'impact significatif sur notre santé en France.

Le but n'est pas d'être sûr à 100% : il y a toujours un risque. Il faut juste relativiser : probabilité que le risque se transforme en réalité et conséquences qui s'en suivraient, puis comparer avec les risques que posent les alternatives.

Donc j'attend ta proposition, que suggères-tu, qui remplace la totalité du parc nucléaire en terme de puissance électrique et qui ne fasse courrir aucun risque à la population ?

par exemple si Gravelines a un soucis, c'est 70 000 habitants évacués[1] dans un rayon de 10km

Mon dieu des gens évacués ! C'est grave ca ? Bof. Si c'est que ca, franchement je préfère courrir le risque d'une évacuation qui la pollution des seules sources d'énergie capable de fournir aujourd'hui l'équivalent des centrales nucléaires.

le risque imposé, et non choisi.

Oué bah oué, c'est dingue, on demande pas l'avis des 6 milliards d'humain à chaque fois qu'on construire un truc avec un impact potentiel sur leur santé/environnement.
Et puis le risque, tu peux le choisir : tu déménages. Tiens, tout à coup finalement le risque n'est plus aussi important pour justifier que tu passes à l'acte.

on ne m'a jamais demandé si j'acceptais de le subir ou non : il m'a été imposé, point. Et ça pour moi, c'est inacceptable.

Pauvre choux, fallait pas voter pour De Gaulle à l'époque hein. C'est con mais on vit en démocratie : cad dans un mode de vie communautaire où tu délègues à un gouvernement/assemblée les choix stratégiques qui te concerne directement ou non.
Et on t'impose rien : tu peux aller voir dans un autre pays où rien ne t'es imposé (ca existe ?).

Mais vas-y proposes une solution miracle qui va plaire à tout le monde et que personne ne sentira comme lui étant imposé.

Bref, en théorie les chance qu'une bombe se produise sont faible,

Oui à peu prêt aussi faible que de se prendre une asteroïde sur la gueule.

le problème est qu'on a des intérêts financiers quasiment d'un bout à l'autre de la chaîne, que l'erreur est humaine, et qu'il peut toujours arriver un truc pas prévu; comme un tsunami de 13m.

Toutafé, et l'expérience actuelle montre que les négligeances, choix techniques, médiatiques et commerciaux conduits à des centrales qui explosent, des coeurs de réacteurs qui fusionnent, des fuites radioactives, mais pas d'explosion type bombe atomique.

En tout cas quelque chose de bien moins dangereux que la simple pollution d'une centrale au charbon ou bien la rupture d'un barrage hydrolique.

> Non mineur;

Histoire de bien enfoncé le clou, le Japon vient de relever le niveau à l'échelon maximal, soit ale même que Tchnernobyl :

http://www.lemonde.fr/japon/article/2011/04/12/tokyo-eleve-au-niveau-7-l-accident-nucleaire-dans-la-centrale-de-fukushima_1506185_1492975.html#ens_id=1493262

• Il faudra m'expliquer en quoi &Exemple::Add est un pointeur foireux.

Cet exemple précis n'est pas foireux. Mais en tant que rédacteur de la méthode Print, je n'ai aucune garantie que l'appelant fasse comme toi : on peut imaginer qu'il fasse un gros cast bien crade pour obtenir un pointeur de fonction, on peut imaginer qu'il utilise même pas la fonction bind, bref c'est pas type-safe. Il peut aussi se louper pour le 2ème paramètre de bind, re big explosion.

D'où le brevet déposé : fournir un mécanisme type-safe, directement intégré dans le langage, qui empêche ce genre de problème.

• Ce n'est pas sans intérêt,

C'est sans intérêt par rapport au brevet qui nous intéresse. Nul doute que Bind a d'autres intérêts.

• Je ne vois rien d'inline dans les brevets.

http://www.google.com/patents/about?id=iT-ZAAAAEBAJ

De rien.

Ok ok, rajoute à la fin de ma phrase "80 % de consommation d'énergie électrique".
Ca ne change strictement rien à la problématique.

Par exemple d'après wikipedia, greenpeace estime à 200 000 morts, En même temps, tu comptes ce que tu veux dans les morts. Y'a les morts directes (facile) Les morts indirectes rapides (leucémie 2 ans après) Les morts indirectes lentes : genre un cancer 30 ans plus tard. Le mec est mort à 75 ans sinon il serait peut être mort à 78.

Il faudrait plutôt parler d'impact en terme de réduction de l'espérance de vie plutôt qu'en chiffre absolu.

Quelque chose me dit que la pollution des centrales au charbon et la consommation de Vodka a beaucoup plus d'impact sur l'espérance de vie en Ukraine ou en Biélorussie que Tchernobyl.

Non mineur; un grave c'est l'explosion du réacteur. Et là l'écart avec Nagasaki ou Hiroshima et du même ordre pour cet incident mineur.

Il y a une échelle officielle :
http://fr.wikipedia.org/wiki/Accident_nucl%C3%A9aire

L'ASN a placé l'accident à 6 sur les 7 échelons, soit "accident grave".

Incident mineur comme tu le suggères, c'est 2.

De ce que j'ai lu ils préconisent surtout une isolation plus radicale des maisons et autre économies d'énergie.

N'empêche, le nucléaire c'est plus de 80% de notre consommation d'énergie. Au mieux avec les "gains" évitant les consommations inutiles (isolation, etc.), tu arriveras peut-être à stabiliser la consommation, la société de consommation faisant qu'aller vers plus de consommation. Il faut donc bien résoudre ce 80% de production. Et le réseau "Sortir du nucléaire" n'a pas d'idées si ce n'est les centrales basées sur l'énergie fossile. Merci bien l'alternative.

Tes mesurettes sont certes sympathique, sans doutes à faire, mais n'auront aucun impact significatif sur l'ordre de grandeur de la production de la totalité des centrales nucléaires.

10 ou 20 ans ça me parait irréalisable; 50 ans y a déjà plus de chance. C'est pas le délai qui pose problème, c'est les solutions alternatives.

J'ai en effet pris soin de ne pas acheter au dessus d'un gisement d'uranium 235.

Suffit d'habiter dans une maison en pierre pour qu'elle soit significative, en tout cas beaucoup plus qu'en habitant à côté d'une centrale.

Si a ce sujet on pouvait réduire la circulation automobile.... Tu vois tu maîtrise pas.

Disons qu'un avions qui se crash sur une maison fera quand même moins de mort qu'une explosion de centrale. Bof, même pas sûr. Ensuite si c'est sur ta maison, t'es mort. Point. Niveau risque c'est maximal, quelque soit le nombre d'autres types qui succombe avec toi. Tu maîtrise toujours pas.

Je ne me ballade pas sur un plage pendant les orages, et lorsque je joue avec les prises, je prends bien soin de couper le disjoncteur correspondant, et j'ai un disjoncteur différentielle. Ca te va?

Non, tu as toujours le risque qu'un appareil soit mal isolé et te balance une décharge (ex: ton PC). Tu maîtrises pas. Le risque est en tout cas beaucoup plus important que tu es un accident domestique grave que d'avoir des séquelles d'un accident nucléaire.

Une centrale qui explose c'est légèrement plus que 10k Une centrale qui explose : * C'est extrêment peu probable que ce soit le coeur lui-même qui explose. Même avec un tremblement de terre exceptionnel et un tsunami exceptionnel ca n'explose pas. * S'il explose, bah tu te casses, tu restes pas comme un con à regarder le spectacle.

Bref, le risque nucléaire "grave" est pour toi très simple à maîtriser au quotidien : t'as qu'à pas habiter juste à côté. Ils cachent pas encore des réacteurs dans les boîtes aux lettres.

Une centrale nucléaire, c'est un risque plus gros que Hiroshima ou Nagasaki;

Faut arrêter de délirer. Ou alors on a pas la même notion du risque. Comparer Hiroshima et Nagazaki au plus gros problème de centrale nucléaire rencontré, cad Tchernobyl, je préfères largement courrir le risque d'habiter à 10km d'une centrale nucléaire que d'être japonais pendant la 2nde guerre mondiale.

Là heureusement on a eu qu'un incident mineur,

Non, on a eu accident grave. Et même si les effets sont largement néfastes pour l'environnement et risque de rayer une grande zone géographique pendant des dizaines d'années, c'est loin, très loin, des seuls effets immédiats d'un Hiroshima ou un Nagazaki.

pas la peine de remplacer le nucléaire par des centrale à pétrole ou charbon

C'est con, c'est la seule solution qu'a trouvé le réseau "Sortir du nucléaire" quand il a fallu trouver des solutions concrêtes et techniquement réalistes.

et le bilan qu'aurait eu une explosion de Fukushima. C'est simple, on a un exemple : c'est Tchernobyl. Et for cé de constater que toi et moi courront beaucoup plus de risque à prendre la voiture, traverser la route ou même changer une ampoule qu'en allumant notre machine à laver qui roule à l'électricité nucléaire.

Sur ce qui m'arrive chez moi, j'ai un contrôle

Tu contrôles quoi ?

La radioactivité naturelle ?

La pollution atmoshpérique qui réduit ton espérance de vie ?

Tu contrôles la possibilité qu'un avion vienne se cracher sur ta maison ?

Tu contrôles la possibilité de mourrir électrocuté ?

Tu contrôles la possibilité de chopper une méningite ?

Tu contrôles la possibilité d'ingérer un staphylocoque mortel ?

Faut arrêter, à moins de travailler dans une centrale nucléaire, tout ca est bien plus risqué pour ta santé/vie et t'as aucune maîtrise. Une centrale nucléaire, c'est facile à maîtriser : il suffit de pas habiter à moins de 10km. En cas d'accident, tu déménage, totale maîtrise.

Et ? Qui te dit qu'il n'a pas réalisé un outil qui "utilise" les 2 ? D'où l'incompatibilité ?

Il a dit un outil qui utilise GCC, pas un outil dont les sources sont compilées avec GCC.

Oui, et ensuite ? Merci, t'as mis en avant tout ce qu'apporte le brevet.

il te faut écrire :

c.Print(boost::bind(&Exemple::add, this, _1, _2));

là où moi j'écris simplement :

c.Print(add).

Différences :

• tu passes un pointeur de fonction en paramètre : un pointeur foireux et tu exploses méthode print.

• tu es obligé de passer des trucs sans intérêts que le compilateur C# déduit automatiquement : l'objet cible (this dans ton exemple) et les paramètres (on s'en cogne s'est l'appelé qui les remplis.

• t'as variante inline est beaucoup trop récente pour servir de prior-art ;)

• en l'occurence boost::bind n'apporte rien par rapport au simple typedef en C pour déclarer une signature de méthode : même inconvénients, une syntaxe toujours aussi lourde pour l'appelant et toujours aussi peut type-safe.

Changeons de méthode parcque là on va pas y arriver.
Traduit en C++ avec boost le code C# suivant (suffisament explicite je pense) :

delegate int OperationDelegate(int a, int b);

public class Console
{
  public void Print(OperationDelegate del){
    var res = del(42, 3); //appel sans crainte, del est type-safe.
    printf(res + 5);
  }
}

public class Exemple
{
  int i = 42;

  public void Test(){
    var c = new Console();
    c.Print(add);
    c.Print((a,b) => a - b); //variante avec code inline.
  }

  public int add(int a, int b){ return a + b + i; } //méthode d'instance
}

Ce n'est pas du tout la même chose : Bind est une "fonction" là où un Delegate est un "type", type qui défini une méthode (d'instance ou non).

Ok, changeons de troll et partons sur le côté type-safe de C :)

Moi j'entend par type-safe le fait de t'empêcher de faire des cast idiots justement. En C tu peux passer l'adresse une zone mémoire contenant de la donnée en tant pointeur de fonction... Une hérésie source de bugs/failles que C# ne t'autorise pas : impossible de transformer de la donnée en code exécutable, même avec un cast, et dès la compilation.

le type-safe on savait le faire (cf. C) C'est une blague j'espère ? Le C type-safe... Tu cast sans que ca pose le moindre problème au compilateur.

Bref, dans tous les cas, juger le brevet "ridicule" ne changera rien au fait que tu n'es pas trouvé d'antériorité pour un "type-safe delegation of object" tel que détaillé dans le brevet. Et puis tu n'as pris que le premier brevet cité : on est pas juriste, ni l'un ni l'autre, mais si on en revient à la discussion initiale, il est clair que des langages comme Vala ou Java implémentent des "fonctionnalités" issues de C#, et qu'à ce titre ces langages sont au moins aussi dangereux que l'implémentation C# de Mono, pour ne pas dire plus.

Effectivement le OnClickMethod se trouve dans la même classe que la ligne que je donne.

Après vérification, la différence avec ton exemple Python n'est pas la référence implicite mais dans la notion même de Delegate : c'est une signature de méthode (d'instance ou non). Forcement en Python une signature n'a aucun sens vu que y'a pas de typage fort et statique par le compilateur.
Le titre du brevet est assez explicite :

"Development system with methods for type-safe delegation of object events"

Il n'y a ce besoin de sécurité de type en Python, donc pas de notion de Delegate comme en C# ou en Vala.

Non plus, tu explicites toujours l'objet dans l'expression a.m (a est la référence explicite)

Donc ce que ce "brevet" couvre : [...]

Non, ton n'exemple n'est pas bon, et le brevet ne couvre pas les classiques pointeurs de fonction. Les "delegates" en C# pointent vers une méthode dans le contexte d'un objet particulier.

Concrêtement si je fais en C# :

button1.Click += OnClickMethod;

où OnClickMethod est une méthode d'instance (et non pas une fonction "static" ou "globale" comme ton exemple en C). Le compilateur rattache automatiquement l'instance de l'objet qui fait l'action pour former un couple instance+pointeur_methode.

Tu as voulu copier l'exemple Vala et le traduire en C, en fait il fallait plutôt que t'essai de traduire le 2ème exemple. Forcement t'aurais pas réussi sans faire une référence explicite à une structure pour simuler un objet, là où le brevet concerne justement une référencement implicite et automatique.

Après je vais pas dire que c'est une révolution ou même une invention, juste une petite évolution qui permet à C# d'avoir une façon simple de passer une méthode d'instance en tant qu'objet. (Exemple : abonnement/désabonnement à un événement).

Tu sais, Qt aussi implémente des technos Microsoft, et même des brevets Microsoft, exemple :

http://www.google.com/patents/about?id=qscSAAAAEBAJ

http://www.google.com/patents/about?id=C8CWAAAAEBAJ

http://www.google.com/patents/about?id=VsUVAAAAEBAJ

Chez Qt ca donne :

http://labs.trolltech.com/blogs/2007/02/28/new-classes-qxmlstreamreader-and-qxmlstreamwriter/

De nombreux projets écrits en C utilise libxml2, et là, paf, même techno, mêmes brevets, et ils ne s'en cachent même pas :

This API is closely modeled after the XmlTextReader and XmlReader classes of the C# language.

http://www.xmlsoft.org/xmlreader.html

En fait, le seul pas enmerdé, c'est Mono, qui implémente bien la même techno, mais en respectant le standard défini à l'ISO.

Mais chuuttt, tu le répèteras pas, je te fais confiance.

Je vois pas ce que vala pourrait violer, sauf à interdire à des gens d'écrire ...

http://linuxpatents.blogspot.com/2010/05/language-envy.html

Franchement, ça donne pas envie...

Pour un particulier on est d'accord. La cible, c'est les entreprises : 400$, c'est le tarif d'une journée d'ingénieur de base. C'est très largement rentabilisé si ca permet d'économiser une montée en compétence sur Objective-C, ou mieux, une journée d'installation d'Eclipse ;)

mais ca reste souvent "choppes ton json sur le serveur, assembles le, donne ca a manger a l'interface et si le product manager s'est lache, persiste le sur disque.".

Ca fait déjà la moitié qui est indépendant du toolkit graphique. C'est déjà ca.

le plus gros etant le fait de melanger plusieurs langages

Justement c'est l'inverse : un projet multi-OS mobile "classique" conduit à faire de l'objective-C, du Java, du C#. Mono propose un unique langage pour toutes les plateformes.

se taper un compilation des plus relou a chaque modif du core

Pas plus relou qu'avec un projet classique multi-OS mobile.

Le deuxieme inconvenient, on perd (enfin, j'imagine) la possibilite d'utiliser des api natives pourtant bien utiles.

T'imagine justement très mal : ils ont justement fait le choix de ne pas avoir une API qui soit un dénominateur commun, mais de créer des bindings pour l'intégralité des API de la plateforme cible. L'objectif est clairement de ne rien perdre en terme de fonctionnel.