Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.
De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.
Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".
Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).
D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.
Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.
Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.
Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.
C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.
Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?
Mon dieu…
C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.
J'utilise ça tous les jours et ça fonctionne plutôt bien.
Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.
L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…
Dans l'article je vois qu'effectivement Mozilla n'est pas un des navigateurs testés, mais en remontant à l'article source (eweek) je ne vois nulle part écrit 'because it's too easy'. Juste qu'il n'y a pas eu d'évolution significative coté sécurité.
Quelqu'un a une autre source pour confirmer la motivation derrière la décision des organisateurs ?
Sinon, on parle beaucoup d'IE dans les commentaires de ce journal mais ce dernier n'est plus testé non plus c'est désormais Edge qui retient l'attention.
Même constat ici avec 50GB de photos. J'ai beau être sous Gnome3, je continue d'utiliser digikam.
De là à dire que la perte de shotwell ne serait pas gênante, je ne suis pas d'accord. C'est une application assez sobre, bien dans l'esprit de Gnome : les actions de base sont faciles d'accès, et c'est l'enfer dès qu'on veut aller plus loin. Ca répond bien au besoin de beaucoup de personnes.
Etre agnostique c'est aussi se dire qu'il y a d'autres questions plus importantes dans la vie. Ou en tout cas qui t'apporteront plus si tu y trouves une réponse, genre "comment être heureux ?", "comment permettre aux autres d'être heureux ?"…
Je travaille dans une filiale d'institution financière ; environ 8,000 postes. Tout le monde a MS/Office d'installé (package par défaut), mais uniquement certains utilisateurs ont un usage vraiment avancé.
On va dire grosso modo :
1) des équipes IT, qui font tourner des macros pour simplifier la vie des équipes de support fonctionnel (environ 800),
2) quelques power users (allez, à la louche on va dire une centaine)
3) les salles des marchés (les cambistes et les vendeurs) : entre 1 et 2% des salariés
Pour 1) et 2), on peut envisager de réécrire ; il y a finalement peu de ligne de code, et généralement rien de bien compliqué.
Pour 3), j'ai beau avoir désinstallé MS/Office de chez moi il y a plusieurs années, je n'imagine pas de solution au remplacement de MS/Office. Certains produits incontournables (genre Thomson-Reuters Eikon) ne peuvent tout simplement pas fonctionner sans Excel, et la salle de marché ne peut pas travailler sans eux.
La seule solution serait d'isoler ces utilisateurs, de les laisser dans leur petite bulle. C'est déjà un peu le cas (ils sont les seuls à disposer de 6 écrans, de machines avec plus de 32 Go de RAM, etc. Mais les décisions sont prises au niveau du groupe, et d'autres filiales ont une proportion d'utilisateurs en salle de marché bien plus importante.
Et personne ne veut risquer d'avoir plusieurs "standards" bureautique dans la même entité.
D'autant qu'on est tous d'accord pour dire que Excel, c'est une tuerie en terme de performances (pour la stabilité, c'est une autre histoire). J'arrive pas à faire les même choses avec LibreOffice Calc, ou en tout cas pas autant de calculs simultanés sans constater de grosses lenteurs.
Désolé, au final mon commentaire n'a pratiquement plus rien à voir avec le fil auquel il répond, mais mon esprit vagabond fait ce qu'il veut - effet conjoint de la chaleur du sud de la France et des vacances :-).
"Comment demander à des gens de faire confiance à un truc alors qu'ils n'en maîtrisent même pas le concept de base ET qu'ils s'en rendent compte ?" - Je comprends mais les gens ne comprennent pas le système monétaire actuel.
Le fait est qu'ils ont l'impression de le comprendre, ou au moins d'en comprendre la base. Cette impression leur permet d'avoir confiance. Avec les Bitcoins, ils n'ont même pas ça, d'où une confiance moindre (voire nulle).
Rends-toi compte : il a fallu plus d'un siècle pour que les gens arrêtent de stocker leur argent dans des bas de laine planqués sous le matelas. Et là, on leur parle de crypto devise ! Le concept risque de devoir attendre quelques générations avant de se répandre…
L'exemple du venezuella est extrême mais après tout, la BCE n'a pas réussi à maintenir le taux d'inflation qu'elle devait maintenir. Certains pensent qu'il vaut mieux avoir confiance dans le marché qu'en les banques centrales.
Alors là, une source est bienvenue sur qui sont ces "certains". Le marché, c'est aussi la spéculation. Sans régulateur, c'est la foire. Et pour l'instant, je ne vois rien qui empêche la spéculation sur le Bitcoin, bien au contraire.
Et la BCE n'a certes pas réussi à maintenir le taux d'inflation, mais elle a limité les dégâts. Sans BCE, quelle aurait été la situation ?
Si tu regardes l'histoire récente, et que tu regardes le rouble par exemple, je ne suis pas d'accord. ça dépend fortement de la période que tu consultes.
Encore un contre exemple. Même le cours USD/RUB, qui a effectivement été très perturbé, n'a pas connu une volatilité aussi forte que le Bitcoin. Et pourtant, le Bitcoin n'a pas encore été confronté à une utilisation massive - ça ne laisse pas présager le meilleur…
Dans la partie "Réserve de valeur", tu expliques que tu veux pouvoir garder de l'argent de côté en ayant un bon niveau de confiance sur le fait que sa valeur ne variera pas trop d'ici à ton achat.
Et tu dis après que ça n'implique pas qu'un organisme se charge de gérer la devise ? Mais c'est exactement à ça que sert une banque centrale : à trouver des compromis entre risques déflationnistes et inflationnistes. En jouant sur les taux d'intérêt. En créant/supprimant de la monnaie. Si on enlève la banque centrale, c'est la seule loi de l'offre et de la demande qui définit la valeur de la monnaie.
Et l'histoire récente a bien montré cela : les variations BitCoins vs. devise XYZ (quel que soit XYZ) ont été bien plus importantes qu'entre n'importe quelles devises traditionnelles. Et ce malgré les crises rencontrées (et on est quand même dans une période bien agitée…). Et ce malgré l'usage encore restreint des BitCoins.
Quand le cours EUR/USD varie de 50% sur 2 ans, les marchés sont bouleversés ; le coût de la vie d'un côté et/ou de l'autre de l'Atlantique s'en ressent fortement. Or, pour le BitCoin, ce sont des variations de 400% sur quelques mois qu'on a pu voir.
Perso, l'argent pour ma maison, je vais continuer à le mettre de côté sur un compte traditionnel, quitte à mettre une petite partie en BitCoin pour respecter le principe de diversification. Bref, le BitCoin va venir en plus et ne va rien remplacer.
Pour continuer, ton exemple sur la création de la banque d'Angleterre est un contre-exemple. Les billets avaient une valeur faciale avec un cours fixe équivalent or. Il y avait un intermédiaire unique - certes, pas l'état, mais dont l'intérêt était que la valeur des billets ne soit jamais remise en doute. Quel est le parallèle avec le BitCoin ?
Par ailleurs, et c'est très important : cette correspondance billet/quantité d'or était un concept compréhensible par tous et qui inspirait confiance (ce qui ne veut pas dire qu'il méritait cette confiance, la nuance est importante) ; la crypto devise, c'est un concept moins accessible au commun des mortels. Dès que tu parles de blockchain tu as perdu 99% de ton auditoire, et pourtant c'est un des concepts indispensables pour appréhender le fonctionnement.
Comment demander à des gens de faire confiance à un truc alors qu'ils n'en maîtrisent même pas le concept de base ET qu'ils s'en rendent compte ?
A mon sens, les crypto devises ont de l'avenir, mais aujourd'hui je ne parierai pas grand chose sur le BitCoin. Il y a encore bien des aspects non techniques à gérer.
"Express" ça veut pas obligatoirement dire "lave moins bien". Pour moi (et pour mon entourage) ça voulait dire "balance de l'eau plus chaude très vite", et "sèche en chauffant très fort, quitte à abimer un peu la vaisselle sur le long terme".
C'est un peu la définition de express. Un train "express" t'emmène bien au même endroit qu'un train normal, mais en le faisant plus vite (et en consommant plus d'énergie), et pas nécessairement dans des mauvaises conditions (cf. l'orient express), juste en s'arrêtant à moins d'endroits.
Le mode "eau super chaude + cycle long + plusieurs rinçages" consomme effectivement plus que tous les autres.
Mais ma surprise tenait au fait qu'en général tu as au moins 3 modes :
1) mode "long qui lave super bien"
2) mode "économique"
3) mode "express"
Avant de me pencher sur la question, je pensais que "économique" bouffait moins d'eau et de courant que "express". Et finalement c'est l'inverse pour toutes les machines que j'ai vu.
A tel point qu'il vaut mieux lancer en "express" une machine à moitié vide que d'attendre qu'elle soit pleine et devoir lancer le mode "long qui lave super bien" voire "économique" sur certains appareils.
Alors moi, j'utilise uniquement le mode "express 30 minutes". Curieusement, en regardant les chiffres de la notice, on voit que le mode économique bouffe beaucoup plus d'eau et beaucoup plus d'électricité.
Le truc, c'est qu'avec une famille de 5 personnes, le lave-vaisselle est vite plein, donc la vaisselle n'attends jamais longtemps et n'a pas le temps de sécher, rendant le lavage plus difficile/hasardeux.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Désolé de me (ré)insérer dans cette discussion.
Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.
De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.
Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".
Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 5.
D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.
Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.
Donc oui, je l'ai déjà testé. Plusieurs fois.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 7.
Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.
C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.
Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?
Mon dieu…
C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.
[^] # Re: Sybase / SAP ASE
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
J'utilise ça tous les jours et ça fonctionne plutôt bien.
Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.
L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…
[^] # Re: Zfs vs BTRFS
Posté par Dring . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 1.
Le planificateur Windows existait déjà sous Windows 95… Et sous Windows NT 3.x. Où on avait aussi la formidable commande "at".
[^] # Re: Ceci n'est pas un troll !
Posté par Dring . En réponse au journal Iceweasel is dead!. Évalué à 7.
Dans l'article je vois qu'effectivement Mozilla n'est pas un des navigateurs testés, mais en remontant à l'article source (eweek) je ne vois nulle part écrit 'because it's too easy'. Juste qu'il n'y a pas eu d'évolution significative coté sécurité.
Quelqu'un a une autre source pour confirmer la motivation derrière la décision des organisateurs ?
Sinon, on parle beaucoup d'IE dans les commentaires de ce journal mais ce dernier n'est plus testé non plus c'est désormais Edge qui retient l'attention.
[^] # Re: Liquide
Posté par Dring . En réponse au journal Galette pomme/noisette. Évalué à 9.
Je préfère l'hydrogène, ça marchera si je prends ça comme liquide ? ;-)
Bon, sérieusement, le liquide en question doit être liquide à l'état naturel, sinon vous ne passerez pas l'hiver.
[^] # Re: Ça a l'air trop bon
Posté par Dring . En réponse au journal Galette pomme/noisette. Évalué à 10.
Je m'insurge ; du point de vue des industriels, la margarine est bien meilleure puisque la marge dégagée est supérieure !
Après, si on parle santé bien sûr…
[^] # Re: lcdlp
Posté par Dring . En réponse au journal Ian Murdock est mort :-(. Évalué à 3.
Indice : "con de mime !"
[^] # Re: shotwell
Posté par Dring . En réponse au journal Yorba ne développera plus Geary, Shotwell et California. Évalué à 5. Dernière modification le 23 novembre 2015 à 13:16.
Même constat ici avec 50GB de photos. J'ai beau être sous Gnome3, je continue d'utiliser digikam.
De là à dire que la perte de shotwell ne serait pas gênante, je ne suis pas d'accord. C'est une application assez sobre, bien dans l'esprit de Gnome : les actions de base sont faciles d'accès, et c'est l'enfer dès qu'on veut aller plus loin. Ca répond bien au besoin de beaucoup de personnes.
[^] # Re: Dieu n'existe pas
Posté par Dring . En réponse au journal Paris sous les balles. Évalué à 3.
Etre agnostique c'est aussi se dire qu'il y a d'autres questions plus importantes dans la vie. Ou en tout cas qui t'apporteront plus si tu y trouves une réponse, genre "comment être heureux ?", "comment permettre aux autres d'être heureux ?"…
[^] # Re: Design orthogonal
Posté par Dring . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 3.
Foutaises !
[^] # Re: participation en rédaction
Posté par Dring . En réponse à la dépêche Sortie du noyau Linux 4.2. Évalué à 5.
J'ai déjà des crampes d'estomac :-)
[^] # Re: Beep
Posté par Dring . En réponse au journal Concours de musique 1-bit. Évalué à 2. Dernière modification le 23 août 2015 à 15:13.
Commentaire effacé par son auteur
[^] # Re: Pourquoi libreoffice ne gère pas les macros excel ?
Posté par Dring . En réponse au journal Nantes migre vers LibreOffice. Évalué à 10.
Je travaille dans une filiale d'institution financière ; environ 8,000 postes. Tout le monde a MS/Office d'installé (package par défaut), mais uniquement certains utilisateurs ont un usage vraiment avancé.
On va dire grosso modo :
1) des équipes IT, qui font tourner des macros pour simplifier la vie des équipes de support fonctionnel (environ 800),
2) quelques power users (allez, à la louche on va dire une centaine)
3) les salles des marchés (les cambistes et les vendeurs) : entre 1 et 2% des salariés
Pour 1) et 2), on peut envisager de réécrire ; il y a finalement peu de ligne de code, et généralement rien de bien compliqué.
Pour 3), j'ai beau avoir désinstallé MS/Office de chez moi il y a plusieurs années, je n'imagine pas de solution au remplacement de MS/Office. Certains produits incontournables (genre Thomson-Reuters Eikon) ne peuvent tout simplement pas fonctionner sans Excel, et la salle de marché ne peut pas travailler sans eux.
La seule solution serait d'isoler ces utilisateurs, de les laisser dans leur petite bulle. C'est déjà un peu le cas (ils sont les seuls à disposer de 6 écrans, de machines avec plus de 32 Go de RAM, etc. Mais les décisions sont prises au niveau du groupe, et d'autres filiales ont une proportion d'utilisateurs en salle de marché bien plus importante.
Et personne ne veut risquer d'avoir plusieurs "standards" bureautique dans la même entité.
D'autant qu'on est tous d'accord pour dire que Excel, c'est une tuerie en terme de performances (pour la stabilité, c'est une autre histoire). J'arrive pas à faire les même choses avec LibreOffice Calc, ou en tout cas pas autant de calculs simultanés sans constater de grosses lenteurs.
Désolé, au final mon commentaire n'a pratiquement plus rien à voir avec le fil auquel il répond, mais mon esprit vagabond fait ce qu'il veut - effet conjoint de la chaleur du sud de la France et des vacances :-).
[^] # Re: hum
Posté par Dring . En réponse à la dépêche Envoi de spam à partir d'un serveur, comment réagir ?. Évalué à 6.
Attention, l'auteur du journal parle bien de la zone "sender", pas du "From" de l'entête de mail qui est effectivement libre.
[^] # Re: Ma réponse
Posté par Dring . En réponse au journal Que répondre quand on vous dit que Bitcoin n’est pas une vraie monnaie ?. Évalué à 7.
Pour les mécréants qui n'ont pas accès à Twitter (bloqué par le proxy de ma société), quelqu'un peut me raconter ce qui s'y passe ? Je suis intrigué.
[^] # Re: Un peu trop facile...
Posté par Dring . En réponse au journal Que répondre quand on vous dit que Bitcoin n’est pas une vraie monnaie ?. Évalué à 5.
Le fait est qu'ils ont l'impression de le comprendre, ou au moins d'en comprendre la base. Cette impression leur permet d'avoir confiance. Avec les Bitcoins, ils n'ont même pas ça, d'où une confiance moindre (voire nulle).
Rends-toi compte : il a fallu plus d'un siècle pour que les gens arrêtent de stocker leur argent dans des bas de laine planqués sous le matelas. Et là, on leur parle de crypto devise ! Le concept risque de devoir attendre quelques générations avant de se répandre…
Alors là, une source est bienvenue sur qui sont ces "certains". Le marché, c'est aussi la spéculation. Sans régulateur, c'est la foire. Et pour l'instant, je ne vois rien qui empêche la spéculation sur le Bitcoin, bien au contraire.
Et la BCE n'a certes pas réussi à maintenir le taux d'inflation, mais elle a limité les dégâts. Sans BCE, quelle aurait été la situation ?
Encore un contre exemple. Même le cours USD/RUB, qui a effectivement été très perturbé, n'a pas connu une volatilité aussi forte que le Bitcoin. Et pourtant, le Bitcoin n'a pas encore été confronté à une utilisation massive - ça ne laisse pas présager le meilleur…
USD/RUB sur 2 ans :
http://www.xe.com/fr/currencycharts/?from=USD&to=RUB&view=2Y
La courbe sur 2 ans de USD/XBT (le "pseudo" code ISO pour Bitcoin) fait nettement plus peur :
http://www.xe.com/fr/currencycharts/?from=USD&to=XBT&view=2Y
# Un peu trop facile...
Posté par Dring . En réponse au journal Que répondre quand on vous dit que Bitcoin n’est pas une vraie monnaie ?. Évalué à 10.
Déjà, je vois contradiction entre deux choses.
Dans la partie "Réserve de valeur", tu expliques que tu veux pouvoir garder de l'argent de côté en ayant un bon niveau de confiance sur le fait que sa valeur ne variera pas trop d'ici à ton achat.
Et tu dis après que ça n'implique pas qu'un organisme se charge de gérer la devise ? Mais c'est exactement à ça que sert une banque centrale : à trouver des compromis entre risques déflationnistes et inflationnistes. En jouant sur les taux d'intérêt. En créant/supprimant de la monnaie. Si on enlève la banque centrale, c'est la seule loi de l'offre et de la demande qui définit la valeur de la monnaie.
Et l'histoire récente a bien montré cela : les variations BitCoins vs. devise XYZ (quel que soit XYZ) ont été bien plus importantes qu'entre n'importe quelles devises traditionnelles. Et ce malgré les crises rencontrées (et on est quand même dans une période bien agitée…). Et ce malgré l'usage encore restreint des BitCoins.
Quand le cours EUR/USD varie de 50% sur 2 ans, les marchés sont bouleversés ; le coût de la vie d'un côté et/ou de l'autre de l'Atlantique s'en ressent fortement. Or, pour le BitCoin, ce sont des variations de 400% sur quelques mois qu'on a pu voir.
Perso, l'argent pour ma maison, je vais continuer à le mettre de côté sur un compte traditionnel, quitte à mettre une petite partie en BitCoin pour respecter le principe de diversification. Bref, le BitCoin va venir en plus et ne va rien remplacer.
Pour continuer, ton exemple sur la création de la banque d'Angleterre est un contre-exemple. Les billets avaient une valeur faciale avec un cours fixe équivalent or. Il y avait un intermédiaire unique - certes, pas l'état, mais dont l'intérêt était que la valeur des billets ne soit jamais remise en doute. Quel est le parallèle avec le BitCoin ?
Par ailleurs, et c'est très important : cette correspondance billet/quantité d'or était un concept compréhensible par tous et qui inspirait confiance (ce qui ne veut pas dire qu'il méritait cette confiance, la nuance est importante) ; la crypto devise, c'est un concept moins accessible au commun des mortels. Dès que tu parles de blockchain tu as perdu 99% de ton auditoire, et pourtant c'est un des concepts indispensables pour appréhender le fonctionnement.
Comment demander à des gens de faire confiance à un truc alors qu'ils n'en maîtrisent même pas le concept de base ET qu'ils s'en rendent compte ?
A mon sens, les crypto devises ont de l'avenir, mais aujourd'hui je ne parierai pas grand chose sur le BitCoin. Il y a encore bien des aspects non techniques à gérer.
[^] # Re: Les dealers, les [:pedobear] et les nigerians vont être contents
Posté par Dring . En réponse au journal Le réseau Tor a besoin de vous !. Évalué à 2.
Attention lecteur : humour potache et inutile !
Tu as retiré le "s" à la fin de "blanche" parce qu'on aurait pu lire "sexiste" ?
Sinon, pourquoi que les blanches ?
[^] # Re: HS lave-vaisselle
Posté par Dring . En réponse au journal Sexisme ordinaire sur Linuxfr. Évalué à 4.
"Express" ça veut pas obligatoirement dire "lave moins bien". Pour moi (et pour mon entourage) ça voulait dire "balance de l'eau plus chaude très vite", et "sèche en chauffant très fort, quitte à abimer un peu la vaisselle sur le long terme".
C'est un peu la définition de express. Un train "express" t'emmène bien au même endroit qu'un train normal, mais en le faisant plus vite (et en consommant plus d'énergie), et pas nécessairement dans des mauvaises conditions (cf. l'orient express), juste en s'arrêtant à moins d'endroits.
[^] # Re: HS lave-vaisselle
Posté par Dring . En réponse au journal Sexisme ordinaire sur Linuxfr. Évalué à 2.
Le mode "eau super chaude + cycle long + plusieurs rinçages" consomme effectivement plus que tous les autres.
Mais ma surprise tenait au fait qu'en général tu as au moins 3 modes :
1) mode "long qui lave super bien"
2) mode "économique"
3) mode "express"
Avant de me pencher sur la question, je pensais que "économique" bouffait moins d'eau et de courant que "express". Et finalement c'est l'inverse pour toutes les machines que j'ai vu.
A tel point qu'il vaut mieux lancer en "express" une machine à moitié vide que d'attendre qu'elle soit pleine et devoir lancer le mode "long qui lave super bien" voire "économique" sur certains appareils.
[^] # Re: HS lave-vaisselle
Posté par Dring . En réponse au journal Sexisme ordinaire sur Linuxfr. Évalué à 5.
Ah, enfin une discussion technique sur LinuxFR.
Alors moi, j'utilise uniquement le mode "express 30 minutes". Curieusement, en regardant les chiffres de la notice, on voit que le mode économique bouffe beaucoup plus d'eau et beaucoup plus d'électricité.
Le truc, c'est qu'avec une famille de 5 personnes, le lave-vaisselle est vite plein, donc la vaisselle n'attends jamais longtemps et n'a pas le temps de sécher, rendant le lavage plus difficile/hasardeux.
[^] # Re: Transgendérisme
Posté par Dring . En réponse au journal Sexisme ordinaire sur Linuxfr. Évalué à 4.
Pas comme inégaux. Juste différents.
…et merde, je m'étais promis de ne rien écrire de sérieux sur ce journal…