Firwen a écrit 562 commentaires

et monter le home en NFS ?

Pour être dans une organisation où le home de chaque utilisateur est mis par défaut sur un NFS-like ( AFS ). Je peux dire que la première chose que je fais est de passer en admin et de désactiver ça.

Même si ça part d'une bonne idée, pour moi le jeu n'en vaut clairement pas la chandelle.

• Lancer une simple compilation sur pNFS/AFS prends généralement 3 à 10x plus de temps que la même opération sur un disque local
• Un bon paquet d'apps ( dont Firefox, Chrome & co ) utilisent une DB sqlite stocké dans le home
  • la première latence de NFS fait freeze l'intégralité de ces applications: c'est simplement chiant.
  • Ces même apps sont trés "IO vore" et vont surcharger le serveurs pour pinnups.
• Il y a toujours le cas où l'utilisateur "BoB" va télécharger 4Go qui va saturer la bande passante du réseau.
• NFS < 4.1 a une implémentation de la sécurité plus que douteuse.
• Le jour où le serveur NFS tombe, c'est l'intégralité des postes qui tombent.

A mon humble avis, une solution basé sur un FS local synchronisé en différé est bien plus appréciable.
Ou plus simplement un dossier "partagé" monté dans le home avec un owncloud d'entreprise.

Mais bien sur Zenichou! Les vilains extrémistes qui ne supportent pas Windows.
Ou peut-être qu'ils supportent ce qui supporte POSIX proprement: ce qui veut dire un peu prés tous les OS sauf Windows ?

Car c'est pas comme si le pool allocator ( responsable du bug heartbleed ) avait été implémenté juste pour Windows qui a une version préhistorique de malloc, mais si en fait.

C'est c'est pas comme si tout le système de structures BIO_* d'OpenSSL moches, buggé et lourdingue étaient là juste pour avoir une IO abstraction layer pour les plateformes non-POSIX : mais si en fait !

C'est pas comme si la gestion des connexion asynchrones est à chier dans OpenSSL, uniquement car TOUS les OS supportent un pattern Async I/O reactor style poll(), epoll(), kqueue() Excepté Windows qui prône un pattern proactor, mais si en fait !

C'est pas comme si TOUS les OS modernes ont un support correct pour pthread SAUF Windows donc OpenSSL se trimballe encore un système de "lock callback" à implémenter en manuel ou il segfault misérablement en multi-threadé, mais en fait, c'est le cas aussi !

Tu devrais sans doute leur proposer ton savoir faire en terme de portabilité depuis ton Visual Studio puisque c'est si facile de supporter Windows.

Non,

• Du code sous GPL peut utiliser du code sous LGPL
• Du code sous LGPL ne peut pas utiliser du code sous GPL

Comme expliqué avec Brio par les Fedoratiens https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibility_Matrix

PolarSSL est trés propre, l'API est bien défini et la documentation pas mauvaise.

Le gros problème de Polar c'est le système de double licence à la legacy Qt ( Commercial & GPL ).

Je développe actuellement une lib open source sous LGPL2+ utilisant naturellement TLS/SSL , et PolarSSL est directement exclue comme dépendance car incompatible….

Bref, les threads sont nécessaires, utiles, mais il ne s'agirait pas de raconter des conneries et de prétendre qu'une approche multi-processus est caduque. Le contre-exemple par excellence est Google Chrome : il allie à la fois l'usage des processus et des threads.

Exactement.
L'approche multi-processur n'est pas caduque, l'approche processus only est caduque.
Tout simplement car chaque approche a un niveau de granularité différent, donc deux applications différentes.
D'où ma rogne d'avant contre le "avoid thread, use process" qui sert d'excuse généralement quand on a honte de son code qui n'est pas thread-safe.

Chrome est un très bon exemple, Chrome utilise un process par onglet pour limiter les problèmes de stabilité. Mais par processus, il utilise un mix de multi threading ( 4-8 threads ) pour le moteur JS, le rendu, etc… et d'event loop (libevent) pour les IO.

Les pools de process ça existe aussi, ce n'est pas réservé aux threads..

ça n'a absolument pas la flexibilité et la légerté des threads pour faire du dispatch de taches.
Si le concept de processus Léger a été inventé et est aujourd'hui si utilisé, c'est pas pour les chiens et c'est pas parce que 90% des programmeurs de cette planète sont idiots sauf toi.
Le vieux dogme "une fil d'execution par processus" est à l'heure du multi-core mort.

Le dispatch par process n'offre simplement ni la facilitié d'utilisation des threads, ni leur niveau de granularité.
Si des languages exemplaires dans le domaine du parallelismes comme Erlang redéfinissent leur propre notion de "process" ( qui sont des green threads "safe" … ) c'est pas fait pour les chiens non plus.

Et pour qui est de la dangerosité de la mémoire partagée, explique en quoi c'est un argument contre les process??

Mémoire partagée veut dire mémoire partagée, c'est à dire la "shared memory", le /dev/shm, ou les appels POSIX shm_ .
Et oui c'est un argument contre, car n'importe qui qui a déja utilisé la shm sait à quel point c'est pénible, contraignant et source d'erreurs ( deadlock entre autre ).

Et puis franchement ce genre d'argument philosophique n'a pas grande valeur du code ou un benchmark ok, sinon bof
c'est du préjugé, de l'optimisation prématurée..

Un argument philosophique sans grande valeur c'est de venir affirmer que la programmation concurrente doit se faire entièrement process based, et que ça justifie une implémentation moisie du multi-threading dans certains langages.

C'est en effet un bel exemple d'un pure argument théorique sans aucune expérience pratique.

Peut-tu expliquer pourquoi tu dis ça? Le non partage par défaut du multi-processus me parait plus sain, et si tu peux toujours utiliser la mémoire partagée si tu en as besoin..

je vais probablement me faire des ennemis à dire ça mais allons y.

Le dogme du "Evite les threads, fait du multi process : c'est safe" est selon moi, périmé depuis longtemps, et malheureusement pas encore mort et enterré.

Il y a des tas de situation où :
- la création de processus est trop coûteuse comparé aux gains de la parallélisation.
- les données sont larges:
- la copie dans chaque process n'est pas envisageable.
- la gestion de mémoire partagée est à la fois pénible et dangereuse.
- Les sections séquentielles et les sections parallèles sont petites et s'enchainent rapidement
- Je suis dans un serveur, créer X process de plus par requètes reçue est simplement pas acceptable.

Tous les pattern de parallélisation modernes actuels utilisent un système basé sur "Pool threads + dispatch task" bien plus simple à utiliser pour le programmeur et bien plus léger.

C'est le cas de Erlang avec ses "lightThread", de Go de Google avec ses goroutines, des commandes "async" de C++11, OpenMP en C/C++, de "concurrent" en Java, de Rust avec ses GreenThreads, etc.., etc…

J'ai l'impression que c'est carrément un vrai concurrent au C++ à ce niveau là aussi complexe l'un que l'autre :)

C'est clairement un concurrent à C++ dans le domaine de la prog système, des services lourds ou du HPC.

Ceci dit, je n'irai pas jusqu'a dire qu'il est aussi complexe que C++ : Rust est plus jeune et ça se voit.
Il ne souffre pas de 20 ans de compatibilité avec le C et de problème de design ( throw ? ahah )

• il y a un système de modules et non une ABI dégueulasse qui casse à chaque changement dans la vtable.
• Le système de macro de Rust ne te crache pas 5 pages d'erreurs à la première erreur de typage dans ton template contrairement à C++
• Le memory management par ref counter est intégré au language… et non intégré au template si Dieu le veut en version cx11…
• la librairie standard te fournit autre chose que ton bash et ton couteau.
• un système d'IO correcte qui ne t'oblige pas à redescendre à des appels posix ou à te pendre avec Boost:Asio.

Il y a une belle évolution et sincèrement j'en salive presque.

Humf pourquoi les informaticiens pensent qu'ils peuvent tout faire marcher à l'image de leur machine ?

Parce que globalement ils peuvent :)

La théorie de l'information se rapproche beaucoup de la "Théorie des systèmes complexes" ( http://en.wikipedia.org/wiki/Complex_systems ) qui elle s'applique trés TRES TRÉS bien aux macro systèmes comme la gestion politique d'un pays, ou d'une société, ou moins glorieux, comme la gestion financière.

On y retrouve globalement les même concepts : réductionisme, indéterminisime, systèmes distribuéS, robustesse locale ( qu'on appelle patitionnisme chez nous ), compétition ( qu'on apelle parallèlisme ), échelle temporelle et spatialle ( qu'on appelle CPU time et RAM ).

Bref, les geeks sont bons naturellement formés donc bons pour ce genre de problème. Pas très étonnant de voir que certains se lancent dans la politique ou le sociétale :)

Et sincèrement, j'ai envie de dire : tant mieux.

Je ne suis pas expert (j'ai lu ton journal et 2-3 liens dedans), mais il me semble qu'une des idées c'est que si on reste dans un débat pour-contre, on reste bloqué dans un minimum local, et que de faire des concessions permet de d'abord sortir de ce minimum local pour ensuite faire mieux que ce qu'on avait avant.

Exactement et merci, c'est trés bien formulé.

Même si ce n'est pas vendredi, je ferai bien un parallèle avec le système politique bi-parti à la française, avec un parlement binaire purement pour/contre ( cf majorité / opposition si bien expressif ) comparé à un système basé sur les concessions et les compromis avec une distribution du pouvoir à l'échelle locale, le système de confédération sur le modèle Suisse.

L'un évolue brusquement dans des directions radicalement différentes, l'autre évolue lentement mais progressivement basé sur des consensus.

Et pour être honnête, certes complètement partial, en étant français et en ayant vécu également en suisse, j'en viens à préféré le système Suisse…

 Ouai parler comme ça c'est au minimum une volonté piéger les utilisateurs.

Les méta-données c'est des données, jouer sur les mots ça ne sert à rien. D'autant qu'on sait tous que les méta-données sont souvent presque aussi importante et aident vachement lors de la cryptanalyse donc au mieux plus tu laisse de méta-données plus tu affaiblie ton chiffrement (la connaissance de l'entrée et de la sortie (la fréquence de leur communication, leur localisation nationale etc permettent par exemple d'émettre des hypothèses au sujet du format de leur numéro).

Si je te suis: Utiliser HTTPS ça sert à rien parce qu'en analysant le réseau, même avec TLS je vois que tu te connectes à ta banque ?

Les méta-données sont trés utiles pour connaitre les acteurs et leurs habitudes, mais elles ne suffisent pas à faire tomber un cryptage correcte ( AES, TwoFish, …) par cryptanalyse sur les données elle même, et fort heureusement j 'ai envie de dire

Non ce n'est pas jouer avec les mots, et oui c'est sécurisé car le contenu des conversations est sécurisé de manière correcte au lieu de se promener en clair sur le réseau SMS.
Et OUI, ça, c'est déja une belle evolution.

C'est quoi la grosse différence si tu peux passer de l'un à l'autre en moins d'une semaine ? Le fait que d'autre font pire ne fait pas de cette solution une solution sécurisée.

Le fait que tu peux passer de l'un à l'autre n’empêchera pas de voir ta liste de contactes sur pastebin.

Sinon, je suis bien d'accord que Skype, facebook Messenger, whatsapp, Viber, Line, Hangout, and co sont des services où le client se fait plumer de haut en bas ses données persos. Mais je pensais que le sujet était déja arrivé plus haut donc, voila.

Désolé pour mon ton un poil aggressif, tu as parfaitement raison sur la partie technique.
Ton article était un peu dénigrant à mon gout sur des solutions qui partent de base qu'une bonne intention : Améliorer la vie privée des communications de manière Libre et ouverte même si ce n'est pas fait de manière parfaite.

1. Donner un token aux contacts dont j'accepte les messages. Ce token, envoyé avec les messages à ma destination permettrait au messages d'etre traités prioritairement par rapport aux autres messages reçus. Les messages d'inconnus (sans token) doivent avoir une preuve de travail, ce qui limite un peu le spam.

Ton modèle est un Web of Trust avec une preuve de travail pour l'entrée initiale.

Le gros du problème se situe au niveau de l'entrée initiale. Il est trés difficile d'équilibrer un système de preuve de travail comme le fait Bitcoin. Quelqu'un disposant d'hardware spécifique ou de CG pourra sans peine Spammer un réseau car disposant d'une puissance de calcul des millions de fois supérieurs à celui d'un pauvre telephone portable.
Mais l'idée est innovante oui :)

1. Recevoir les messages par l'intermédiaire d'un serveur (comme un serveur de mail). Ce serveur pourrait filtrer les messages avec ou sans token pour transmettre en priorité à mon smartphones ceux qui ont un token.

Si tu autorise le serveur à lire/comprendre ce "token", tu ré-introduis le problème de traçabilité associé aux méta-données. Tu pourras toujours construire un graphe de contacts et de relations associés à ce dit "token".
Le système de priorité est aussi un problème pour le serveur :
Que faire des messages "low priorité" ? les stocker ? si c'est du spam, ça peut aisément prendre une place importante.

1. Ensuite, pour les nouveaux contacts, il pourrait y avoir un autre token à envoyer par l’expéditeur qui dépende de sa clé privée et de ma clé publique de telle sorte que le serveur pourrait détecter les demandes de messages répétées d'un même expéditeur sans pour autant savoir quel est l’expéditeur ni le contenu du message.

Donc tu veux une signature qui n'est pas une signature ? ça me semble un peu flou ça :)

Je prendrais plutôt le problème sous une autre approche :

• Privilégier les connexion P2P autant que possible au lieu de passer par un serveur tiers, spécialement dans le cas d'une messagerie synchrone.

• Autoriser un système de federation de serveurs non hiérarchique comme pour SMTP, XMPP ou SMS/MMS pour favoriser une administration distribuée des serveurs.

oui mais bon c'est sorti quand même et étiqueté "secure" :D

Oui c'est sécure, TextSecure n'a jamais vendu une quelconque confidentialité des méta-données.
Les données, elles, sont chiffrés proprement et hors du champs de vue du serveur et du medium de transport. Ce qui est déja nettement mieux que la plupart des solutions actuelles.

Note2: même l'auteur sait que c'est pas viable sur le long terme.

Non ce n'est pas la solution ultime et moxie le dit lui même, l'entropie des numéros de téléphone est beaucoup trop faible et ça les rend vulnérable aux attaques par dictionnaire.

Mais il y a déja une grosse différence entre stocker un hash… et stocker le carnet d’adresse complet en clair comme LINE, facebook messenger ou whatsaps qui va se retrouver copier/coller sur pastebin au premier DB leak venu.

même sans ça, le serveur a quand même les couples (hash émetteur, hash destinataire) de chaque message.

Dans le cas du layer SMS, les messages ne passent pas par le serveur qui ne connait que les lookup que tu effectues ( un seulm et unique par session en théorie )

Pour revenir au sujet initial :

Pour moi, le design de base de ces applications rendent impossible la protection des métadonnées des échanges sauf si l’on a confiance dans le serveur. Croyez-vous encore au « Don’t be evil »?

Une solution serait :

1- Utiliser un identifiant ne permettant pas de remonter facilement à l’identité réelle de l’utilisateur (ex : un numéro aléatoire)

2- Ne pas laisser le serveur connaître qui envoie le message (ex: le message ne contient que l’identifiant du destinataire en clair, le message envoyé par l’utilisateur émetteur passe par plusieurs relais avant d’arriver au serveur. On peut ainsi dire que le message est envoyé de manière anonyme. L »identité de l’émetteur est à l’intérieur du message chiffré que seul le destinataire peut déchiffrer)

C'est pas aussi simple malheureusement.

Dans ton cas 1, l'utilisation d'un numéro aléatoire sans aucune preuve d'identité implique de te rendre vulnérable au Spam, car le premier bot venu pourra générer un numéro aléatoire. La seul alternative à ma connaissance à ça est un système de proof of work à la Bitcoin, ce qui est énergivore donc incompatible avec une utilisation mobile….Un comble pour une app de messagerie.

Dans ton cas 2, ton serveur connaîtra au minimum l'identité réseau de l'acteur ( l'addresse IP ) à moins que tu utilises un système de routage en onion à la Tor, ce qui encore… est incompatible avec le mobile.
Et tu te rends également vulnérable au DDOS car n'importe quel botnet peut allègrement spammer ton serveur et le réseau entier de manière anonyme : ses messages ne sont pas identifiés, ils n'ont pas d'expéditeur, personne ne peut le filtrer.

TextSecure est bon pour la confidentialité des données, moins bon pour la confidentialité des meta-données. Je trouve un poil rabat-joie de le dénigrer sans rappeler que Skype, facebook Messenger, whatsapp, Viber, Line and co sont :
1- propriétaires
2- disposent d'une copie en clair serveur side de tous vos messages…. ou des clés pour les décrypter.

Et que comparé à ça, TextSecure c'est déja une franche évolution et sincèrement, merci à Moxie pour son boulot.

Par exemple, comment savoir avec quels contacts je peux utiliser mon « application de communication sécurisée » ? En demandant au serveur, pour chacun des numéros de mon carnet de contact, s’il correspond à utilisateur enregistré. Bingo, vous venez d’envoyer la totalité des numéros de votre carnet de contact.

Tu as pas du beaucoup te renseigner pour sortir ça.

Dans le cas de Text Secure, tu n'envoies à aucun moment ton carnet d'adresse au serveur.
Ce que tu envoie au serveur c'est un hash de ton numéro associée à ta clé publique : pair< hash(numéro de tel ), Kpub>.

Lorsque tu dois trouver si un utilisateur X utilise TextSecure, l'application fait simplement un lookup(Hash(num)) -> PubKey

il est également possible d'héberger son propre serveur, pour les cas de paranoia extrème.

Pour la remarque par rapport à Java EE: oui la tendance est à utiliser des annotations (ex: JPA, EJB), mais les fichiers XML peuvent s'avérer encore nécessaires dans certains cas bien spécifiques. Cela dit, ils ne sont pas très complexes non plus.

Exactement, comme avec Maven et son pom.xml si lisible et agréable à configurer.

C'est vendredi aprés tout.

Je suis loin d'être un fan d'XML à toute les sauces qui est à mon gout souvent un overkill pour une simple sauvegarde.

Mais les gros avantages de formats textes XML, JSON ou des formats binaires fait correctement comme protobuf ( https://developers.google.com/protocol-buffers/docs/overview ), c'est que tu peux étendre facilement ton format au fil des versions sans casser la compat ascendante et descendante à tout va.

Conclusion, j'utilise boost::serialization pour les sauvegardes de données

Boost::serialization est pas mal du tout, mais la sérialization des objets, c'est aussi loin d’être parfait en terme d'évolution.

Dés que le layout de tes objets changent un peu ( ajout de champs ou suppression ), tu es obliger de versionner tes classes pour pouvoir continuer à charger les vieux objets sérializés… Ce qui devient vite un gros bordel, disons le franchement.

Mais attendez c'est pas fini. J'ai un collègue qui a le même véhicule. Lui il a eu droit à un défaut de fonctionnement du bordel, genre tu te gares, tu descends de voiture, tu fermes la porte et là, oh… le véhicule bouge tout seul dis-donc ?! C'était un problème électronique.

j'ai déja vu le cas inverse.
Un pauvre bougre qui l'avait activé à un feu rouge sur son gros SUV flambant neuf…. et qui pouvait simplement pas l'enlever.

Et quand la voiture ne freine pas parce que le bus est squatté par la radio, on regrette ta vielle voiture low-tech.

les Bus CAN utilisés en automobile ( et aéronautique ) ont un système d'écoute de porteuse avec une priorité "par bit", autre ment dit, certaines trames identifiées avec des ID basses ( au hasard les freins….) seront toujours prioritaires en cas de conflit même si un module tiers pourrit le bus.

http://en.wikipedia.org/wiki/CAN_bus

Et fort heureusement j'ai envie de dire.

Quelles sont les entrées / sorties d'un tel programme ?

L'industrie automobile utilise massivement le bus CAN.
C'est un bus serie assez simpliste, qui fonctionne avec un système de trame courte et du CSMA avec un système de priorité plutôt bien foutu.

Ceci dit, le problème vient pas réellement du bus.

Le problème vient du fait que le soft est généralement implémenter sur Micro-controleurs, sans memory protection, sans OS, avec des drivers maisons plus ou moins tester et le tout en language C old style, bien souvent sans analyseur de code….

Là où un service mal codé va segfault et se faire relancé sur OS traditionnel. Sur un micro, il va simplement se mettre à wiper des parties complète de la mémoire :D

Désolé mais c'est pas clair:
Si j'effectue un paiement simultanément à un autre vendeur B, le vendeur A le voit quasiment instantanément?
Les 2 transactions sont donc refusées?

Deux scénarios possible dépendant du fournisseur de paiement :
- Les deux vont être détectée comme étant frauduleuses, et être bloquées jusqu’au la confirmation finale d'une des deux aprés 10 minutes.
- Les deux vont être détectée comme frauduleuse, être bloquée. l'intermédiaire de paiement va bloquer la monnaie sur une adresse tiers. Et refuser les deux paiement. Le truant se fait couillonné et c'est bien fait pour lui.

Ensuite, si le lis correctement cette page:
https://coinbase.com/docs/merchant_tools/pricing
ce n'est pas 1M par mois, mais c'est bien le premier million qui est converti et retiré.
Ce n'est sans doute pas négligeable pour bien des commerces, mais ça ne dépasse pas 1an de C.A.
Ensuite les frais sont bien de 1%, sauf si tu dépasses 1M/mois, auquel cas ils veulent bien te négocier un meilleur taux.

J'ai aucune envie de me perdre dans un débat entre le pricing des CB contre le pricing de Bitcoin, c'est stérile à mon humble avis. Les deux systèmes ont des avantages qui dépassent de loin leur frais.

Mais si tu veux avoir une idée du pricing, BitPay a une page pour ça: https://bitpay.com/pricing
Les prix affichés sont 0% avec un forfait par mois, je n'ai jamais creuser la question mais si tu veux faire un comparatif la dessus, tu es le bienvenue :)

Les cartes de crédit sont risquées mais la banque est garante du risque. Finalement j'ai plus confiance dans une transaction par CB où je peux me retourner vers la banque en cas de problème qu'un échange liquide où je ne sais pas détecter les faux billets.
Pour les bitcoins, s'il y a une faille ou s'il faut trop de temps pour valider la transaction, je n'ai plus que mes yeux pour pleurer?

Pour le client oui, pour le commerçant non.

Tu es commerçant avec une boutique en ligne, une de tes transactions a été effectuée avec une carte de crédit volée. La banque rollback la transaction et tu n'as que tes yeux pour pleurer.

La sécurité du système de carte de crédit est un système pourrie en tout point de vue depuis des années.
Et je ne parle même pas du nouveau système RFID paywave, qui est simplement une pure honte en terme de sécurité, à un point qu'ils ont même été obligé de réduire le montant maximum pouvant être processé…

On peut reprocher beaucoup de chose à Bitcoins ( deflations, anarchisme, blanchiement )… Mais sur la sûreté des transactions dans le monde numérique, beaucoup de système sont bien bien bien loin derrière.

Quand je parle de 10 secondes pour une CB, c'est pour confirmer une transaction (sinon c'est 2 secondes, et bizarre mais des fois même le Carrefour du coin demande une confirmation car doute, et toi tu dis "10 minutes", oups, je n'ai pas 10 minutes et Carrefour non plus).

10 min pour Bitcoin c'est une transaction indélébile avec confirmation de la banque. Le "chéque approvisionné" ou le virement bancaire en comparaison.

2 sec, c'est la confirmation d’émission réseau. Donc ta transaction carte de crédit…. qui peut être refusé plus tard si la carte a été volée…
Et oui, car en cas de carte volée.. la banque procède au rollback de la transaction….

Oui, bien sûr, en acceptant n'importe quel risque, c'est plus simple. C'est pas comme si les billets n'étaient jamais contrefaits et que les magasin contrôlent plutôt que de fiare confiance, et qu'une fois que les bitcoin seront à la mode en physique, il n'y aura pas de minage pour pourrir les transactions.

Argument bidon.
Apparrement tu n'as aucune idée de ce qui est nécessaire pour faire un défaut de paiement en Bitcoin par une double transaction et tu parles sans savoir.
Même en quelques secondes, c'est extrêmement facile à détecter en sondant le réseau…. C'est ce que font les solutions de paiement via Bitcoin comme BitPay pour assurer un paiement en moins de 5 secondes. Généralement bien plus rapide qu'une transaction CB par ailleurs.

C'et fou le nombre de limites dans le potentiel qu'on voit quand on creuse un peu… Il est où le vrai potentiel, sans "pas grave c'est acceptable" mis comme ça (désolé, pour moi ce n'est pas acceptable)?

La seule limite pour l'instant est celle que tu inventes :D

ca va te choquer, mais des fois il faut intervenir pour pas que ça merde.
L'impossibilité d'intervenir n'est pas moins néfaste que la possibilité de trop intervenir.

Faux et archi-faux mon cher Zenit.

Bien sur que l'intervention Étatique et nécessaire dans bien des cas.
Mais tu considère que le seul moyen d'intervention d'un état sur son économie est sa monnaie et c'est faux.
En pratique chaque état a une pléthore de moyens d'intervenir sur son économie autre que déprécier sa monnaie: les taxes, l'investissement publique, inciter la consommation, limiter la volatilité des prix, créer des plans d'état…..Tous ces moyens ont déjà été utiliser à foison par le passé et ont prouver leur efficacité.

Influencer le cours de la monnaie ( l'inflation, dépréciation … ) a déjà prouver X fois par le passé que ça ne fait que favoriser qu'une spirale inflationnistes entre économies concurrentes: la guerre des devises. Un pays dévalue sa monnaie pour relancer son énonomie, ce qui pénalise l'autre pays qui ne fait pas de même, qui le fait à son tour… etc… etc… Et ça finit généralement par causer des bien plus de maux que le problème initial que l'on tente de régler.

A ton humble avis, pourquoi certain États comme l'Allemagne sont des adversaires virulents à toute intervention monétaire ? juste une prétexte à un immobilisme profond ? Simplement parce qu'ils savent mieux que quiconque historiquement, ce que peut causer un excès d’interventionnisme, même quand c'est fait pour une "noble cause" initialement.

M’enfin, toute cette discussion me semble franchement secondaire. Bitcoin peut très bien fonctionner sans remplacer l’euro hein…

Exactement Moonz. Et c'est là une partie de l’intérêt d'une monnaie "neutre", c'est le choix.