Gof a écrit 2210 commentaires

Le problème est que simplement augmenter la taille des blocs est un changement qui causerait un « hard fork » de la blockchain, car c'est un changement incompatible avec les règles de bitcoin. Cela signifie que les utilisateur utilisant une vielle version de bitcoin vont créer une chaine alternative. Et c'est un gros problème.

Par ailleurs, augmenter la taille des blocs n'est qu'une solution temporaire. Avoir des blocs 8 fois plus gros ? On peux faire 8 fois plus de transactions, mais la blockchain grandit 8 fois plus vite. Et 8 fois plus de transactions, ce n'est pas sufisant pour du vrai scalling; Il faut pouvoir faire plusieurs ordre de magnitude plus de transaction si bitcoin veux être compétitif avec VISA par example.

SegWit aide déjà sur le cours terme car les transactions occupent moins de place dans le bloc, donc on peux mettre 2 fois plus de transactions dans un bloc.

Sur le long terme, segwit aide car il résous un problème qui permet d'implémenter des solution de payement hors-chaine comme les ligntning network https://lightning.network/

Selon moi, lightning network est la solution qui permet à Bitcoin de passer à l'échelle. Il existe des versions beta des implémentations, mais il y a encore beaucoup de travail à fournir pour avoir un client qui a de l'allure et utilisable.

Tu es dépassé. JSON c'est mainstream. Les hipsters utilisent YAML

(D'ailleurs, les parseurs YAML (qui parsent aussi le JSON) ne semblent pas avoir été testés par l'auteur du journal.)

SSL everywhere!

SSL c'est dépassé. Il faut utiliser TLS maintenant.

Si seulement quelqu'un pouvait se présenter pour proposer un changement radical et la "vraie démocratie".

N'était-ce pas l'idée du Parti pirate, avec son système de « démocratie liquide » ?

https://fr.wikipedia.org/wiki/Démocratie_liquide

LinuxFr n’est pas l’endroit pour un cours d’introduction à la thermodynamique

Bien sûr que si ! Pourquoi pas ?

On retrouve encore des ossements et des empreintes de dinosaures disparus il y a bien plus de 65 millions d'années. Donc je pense en effet que dire que il ne restera plus de traces de l'Homme après 25000 ans me parait assez aberrant.

Non je ne suis pas certain. Je fais peut être un abus de language.

La vapeur peut exister autrement.
Le 100°C correspond à la température d'ébullition quand l'eau est pure (dans une bouteille ou un ballon, sans contact avec l'air).
Quand l'eau est en contact avec l'air, une partie se dissous dans l'air.

Par example, à 25°C, la pression de vapeur saturante de l'eau est de 3,2 kPA = 0,032 atm
(Source: https://fr.wikipedia.org/wiki/Pression_de_vapeur_saturante_de_l%27eau )
Ça veux dire en gros que 3,2% de l'air peut être de la vapeur d'eau. (C'est la maximum authorizé par les loi de la physique à cette temperature, et pression de 1 atm)

Quand on parle de l'humidité de l'air, on parle en fait du rapport entre la quantité d'eau dans l'air et cette valeur maximale. [https://fr.wikipedia.org/wiki/Humidité_relative]
Donc quand on dit que l'humidité de l'air est de 50%, ça signifie que l'air est composé de 1,6 % de vapeur d'eau.

Sauf que le commentaire auquel tu réponds précise bien "à pression normal".
Donc le graphique n'explique rien.

Ce qui ce passe c'est qu'une partie de l'eau est diluée dans l'air.
Voir aussi: https://fr.wikipedia.org/wiki/Pression_de_vapeur_saturante

Pour contredire gUI, la condensation que l'ont voit et les nuages sont en fait des goutelettes d'eau liquide en suspension. La vapeur d'eau est invisible

Intéressant, je ne savais pas qu'on pouvait breveter un ASIC prévu pour faire un algo libre.

Ça doit dépendre des pays, mais oui, un algorithme peut être breveté même si il est implémenté dans un logiciel libre pour un format ouvert. C'est d'ailleurs un gros problème. Par exemple dans le domaine des codecs (.gif, MPEG, ….). Et c'est aussi ce qui permet à Microsoft de réclamer tant d'argent au fabriquant de téléphones Android.

Dans ce cas ci, je pense, ce qui est breveté est un procédé qui optimise la manière de calculer les SHA256 des blocs de Bitcoin, de manière à créer des puces qui consomment moins.

Mais personne ne changera Bitcoin en lui même, […]
Si alternative il y a, elle viendra d'une autre cryptocurrency.

Note que techniquement, il est possible de changer de système.
Ethereum par exemple est sur le point de changer pour utiliser la Proof-of stake.

Cela peut même être fait via un soft-fork. (Un bloc est considéré comme valide si il contient à la fois une preuve de travaille comme avant, et aussi une preuve alternative, en même temps. Si la preuve alternative est calculée de la sorte qu'il y ait un nouveau bloc toute les 11 minutes (au lieu de 10), la difficulté de la preuve de travail va rapidement diminuer, et le gaspillage d'énergie sera fortement réduit)

La seul question intéressante et importante est : "qui se trouve derrière ce fork ?".

En effet c'est une question intéressante. En lisant les commentaires sur HackerNews et Reddit on peux essayer de deviner les raisons.

• Il existe un type de matériel qui utilise un algorithme breveté (AsicBoost) qui premet de miner plus efficacement. Le problème est que cet algorithme ne serait pas compatible avec SegWit. Les pocesseurs de ces machines veulent donc pouvoir continuer à miner avec, et donc supportent le fork.

• Certains utilisateur sont contre SegWit et ses applications (Lightning Networks) car ce serait prétendument s'écarter de Bitcoin tel que proposé pas Satoshi Nakamoto. Ce ne serait parrait il pas la "vision" the Satoshi.
  Ce dernier argument est un peu fragile car énoncer la "volonté de Satoshi" ressemble un peu à un argument religieux. Et s'il est vrai que le papier original ne parle pas des "payment channel" des lightning network, il parle bien de sauver de l'espace (ce que fait SegWit), et son code et ses messages de forum montre qu'il aurait en fait travaillé sur des prototypes de "payment channel" et transactions "off-chain".

• Il y a peut être une incompréhension de ce que les Lightning Network sont réellement vis-à-vis de la centralisation. Certains pense que cela nécessite de rajouter des intermédiaires de confiance ce qui irait effectivement à l'opposé de la phylosophie de bitcoin. Mais en réalité, le réseau reste totalement décentralisé, et il n'y a pas besoin de faire confiance aux autres nœuds.

Si les chinois, qui possèdent la plus grande puissance de calcul, ne soutiennent pas ce fork alors il va juste mourir comme le précédent.

"Comme le précédent" ? Quel précédent ? Le bitcoin non-forké n'est pas mort.
De plus, il n'y a pas besoin de beaucoup de puissance de calcul, tant qu'il y en ait assez pour garentir la sécurité du réseau.

J'ai moi même développé une alternative à LXR.
J'utilise clang pour analyser le code source.
Cela permet une bien meilleur prise en charge du code en C car clang connait le type de tout et peut ainsi rediriger vers le bon partie.
Par exemple si le code a quelque chose comme st->state, on sait ce que state est, quelle membre de quelle structure, alors qu'il me semble que LXR va juste donner tout les membre state de toute les structures.

Le code de Linux est aussi navigable là: https://code.woboq.org

Joli. (J'ai moi même pensé à faire ce genre de choses)

Qu'est-ce qui compile le plus vite ? gperf + le compilateur C, ou le code en C++ ?

Qu'est-ce que tu entends exactement par le fait que olaf est moins robuste ?

Pareil pour moi: https://linuxfr.org/users/gof/journaux/archlinux-07-vient-de-sortir

Mais le temps de SHA1 est davantage compté que ce qu'on pensait jusqu'alors

Euh… Non.
On connait les faiblaisse du SHA-1 depuis plus de dix ans, et les experts comptaient déjà les jours depuis lors:
https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
http://valerieaurora.org/hash.html

Contrairement à ce que dit le journal, ce n'est pas sur un serveur de test que l'opération aurait du été faite, mais sur l'autre serveur de prod.

En gros, si j'ai bien compris, il y avait deux serveur de prods, en redondance.
L'un des serveur était corrompu, et le gars à voulu supprimé la base do donnée corrompue pour y recopier celle de l'autre serveur. Le problème est que l'opération a été faite sur le mauvais serveur et que donc les base de données des deux serveurs ce sont retrouvées inutilisables.

Donc c'est pas la même chose que la différence entre test et prod, mais la différence entre deux serveur de prod.
Oui, avoir des couleurs différente pour chaque serveur peut aider. Mais quand on à l'habitude de travailler avec plein de serveur de différente couleur tout le temps, c'est pas beaucoup plus utile que le nom du serveur dans le prompt j'imagine.

Voici ma version: moins verbeuse. Pas si différent de l'example.

#include <iostream>
#include "boost/variant.hpp"
#include <boost/hana/functional/overload.hpp>
using namespace std::string_literals;


struct NombreFixé { int nombre; };
struct NombreMaximumHardware {};
struct PasDeThreading {};
struct CasParticulier {};

using PolitiqueThread = boost::variant<NombreFixé, NombreMaximumHardware, PasDeThreading, CasParticulier>;

int main()
{
    PolitiqueThread threadCount = NombreFixé{10};

    std::cout << boost::apply_visitor(boost::hana::overload(
            [] (NombreFixé f) { return "nombre fixé à "s + std::to_string(f.nombre); },
            [] (NombreMaximumHardware) { return "Fait chauffer la ferme de calcul"s; },
            [] (PasDeThreading) { return "Plutôt tranquille"s; },
            [] (CasParticulier) { return "Celui-ci je ne l'aime pas"s; }
        ), threadCount) << std::endl;
};

Résultat: http://melpon.org/wandbox/permlink/LH6QB4tOXjSYpLGz

(Note: cet exemple ne fonctionne que avec clang car GCC ne supporte pas les accents dans les nom de types)

On pourrait ajouter un constructeur à NombreFixé avec un assert pour s'assurer que la valeur est correcte.

Ton code n'utilise pas de littéral hexadécimal à virgule flottante. Tu es donc disqualifié pour le concours :-)

P.S.: Je place mon commentaire original sous licence CC0. (Mais le code est un travail dérivé du noyau linux et est donc GPL2)

tousse Y a rien eu, hier ! tousse

Ni vendredi.

Merci pour ton commentaire.
Je ne vais pas cacher que mon commentaire était un appât à troll. (Je suis déçu qu'il n'ai pas plus mordu. Peut être que les féministes ne lisent pas les dépêches parlant du C++ ?)

Je dois dire que pour moi, ce que je trouve amusant dans ma « blague », est la référence au faits précédent et au journal, et pas le « jeu de mots » lui-même.
Je ne pense que que la constante soit insultante ou choquante. (Bien que je ne mets pas ce genre de blagues dans mon propre code car je trouve ça enfantin et peu professionnel)

static const long HV_LINUX_GUEST_ID_HI = 0xB16B00B5p0;

Ah pardon, ça avait déjà été fait

Désolé pour mon humour 0xcacap1-pi

Pas facile en effet de trouver de bonnes explication en français de SFINAE. Google me donne ceci: http://h-deb.clg.qc.ca/Sujets/Divers--cplusplus/SFINAE.html
Est-ce que ça aide ?

j'ai pas mal entendu parlé de template et de métaprogrammation, mais je n'ai jamais compris ce que c'était (ni à quoi ça sert).

Le problème n'est peut être pas SFINAE, mais la métaprogrammation tout court.
Quelques liens:
http://loulou.developpez.com/tutoriels/cpp/metaprog/
http://h-deb.clg.qc.ca/Sujets/Divers--cplusplus/Metaprogrammation.html

Je suis demandeur de publications scientifiques tendant à démontrer que le fœtus n'a pas encore de conscience pouvant l'amener à ressentir des sensations (douleur physique) ou des émotions (peur) en deçà de 12 semaines.

Demandes-tu aussi des études pour démontrer que les moustiques ne peuvent rien ressentir avent de les écraser ?

La logique est: « l'électeur Green à choisi de voter pour un parti qui n'a aucune chance, c'est équivalent à s'abstenir de voter ».
Et en combinant avec « S'abstenir c'est se ranger du coté de la majorité », on obtient en effet le que ils ont indirectement voter pour Trump, le gagnant.