Gof a écrit 2224 commentaires

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.

fait qu'il y ait pire que Dell ne signifie pas que Dell fait du bon boulot

En design, il en faut pour tout les gouts. Ce n'est ni pire ni meilleur que Dell, juste différent. Les fan de Star Trek seront ravi du look Retro-Futuriste de ce portable.

Aussi, je ne pense pas que Dell fasse du mauvais boulot.

Personellement, en 2016, je suis contant d'avoir des ports USB type A, en plus du Type C. Et je dois dire que je regrète un peu de ne pas avoir de vrai port HDMI (Mais je comprends que ce port est un peu gros pour la taille de mon portable)
Et sacrifier des ports pour un meilleur design est un choix contestable.

Il aurait fallu un clavier entier en oled. Programmable à souhait, s'adaptant à toutes les langues et aux applications.

Comme ça: https://en.wikipedia.org/wiki/Optimus_Maximus_keyboard  ?

Pour l'occasion, Helio Castro a recompilé Qt 1.45 et KDE 1.1.2 avec un compilateur récent sur une distribution moderne:
http://www.heliocastro.info/?p=291

C'est pareil dans chaque language.

En JavasSript par exemple, langage réputé plus "simple", quelqu'un pourrait essayer de savoir si un object a une propriété particulière

if (obj[prop]) doSomething();

On lui répondra que non c'est pas comme ça qu'il faut faire, il faut faire

if (typeof(obj[prop] != "undefined")
   doSomething();

Mais certains iront lui dire que il doit utiliser !== et non != et que il n'as pas besoin d'utiliser de ; en javascript parce que c'est moche. Mais d'autres diront que il faut utiliser des ; après tout car c'est plus correct et que ça évite certain problèmes.

Mais en fait ça ne marche pas si la propriété en question est héritée depuis le prototype. Donc il faut faire.

if (obj.hasOwnProperty(prop))

Mas non, c'est pas suffisant, il faut en fait faire

Object.prototype.hasOwnProperty.call(obj, prop)

Enfin ce que je veux dire c'est que les piailleurs aiment pinailler. Et que on peu faire ça avec chaque langage.
Le fait qu'il y ait des pinailleurs ne veux pas dire grand chose sur la qualité d'un langage.

Aucune ABI n'est définie pour C++.

A bon? Et ça c'est quoi alors:
https://mentorembedded.github.io/cxx-abi/abi.html

Si tu parle d'ABI qui fait partie du langage, je ne connais pas un seul langage qui a une ABI définie de la sorte. C non plus n'as pas d'ABI.
Il fût un temps ou les différent compilateurs C n'étaient eux aussi pas compatibles. (__stdcall, __cdecl, __fastcall, … ?)

"copie tous les membres sauf un"

Il pourrait y avoir une class dans une bibliothèque. Un truc du genre: (non testé)

template<typename T> class  no_copy {
   T value;
public:
   no_copy(const T&v) : value(v) {}
   no_copy(const no_copy&) : value() {} // zero-initialize
   operator T&() { return value;  }
};
// Move sementic, const correctness and operator =, *, ->, ->*,  are left as an exercise to the reader.

Et ensuite dans ta classe:

struct FooBar {
   int normalMember1;
   std::string normalMember2;
   no_copy<int> memberThatShouldNotBeCopied;
};

---

(getters/setters pour remplacer un mécanisme de permissions en lecture/écriture, par exemple).

On pourrait imaginer un read_only<T, U> dont les opérations non constantes seraient privée et qui aurait un friend U.

GCC à raison et clang à tord. Le programme est valide, c'est d'ailleurs un exemple du standard (§11.4 [class.protected])

Donc c'est un exemple de code conforme à C++98 que clang 3.8 ne peut pas compiler. (C'était l'énoncé de l'exercice)

Ce qui a changé (ou qui va changé?) c'est la CWG resolution 1873 [1]
Voir aussi [2]. Et c'est une des erreurs qui apparait fréquemment lors du port d'applications vers clang.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1873
[2] https://llvm.org/bugs/show_bug.cgi?id=6840

donne moi un bout de code répondant au 1er standard C++, c'est à dire de 1998 […] que je ne puisse pas compiler avec, par exemple, clang3.8.

export template<typename T> class Foo {};

J'admets que je triche.

Un autre exemple:

class B {
protected:
    static int j;
};
class D : public B
{ friend void fr(); };
void fr() { B::j = 5; }

En l'occurrence, c'est le CTO de ownCloud qui est chez Nextcloud. Donc celui qui était responsable des décision techniques.

En ce qui concerne le problème de l'update, c'est un problème bien connu de ownCloud qui est du à un problème d'architecture. Un effort a été fait pour résoudre le problème déjà dans ownCloud 9 je pense (upgrader depuis ownCloud 9).
Mais je ne vois pas pourquoi il y aurait une différence entre Nextcloud et ownCloud sur ce point.

Et on peut faire

#define times *[]

Comme ça on peut écrire

10. times { std::cout << "Comme en ruby" << std::endl; };

Commentaire supprimé