needs a écrit 329 commentaires

Même si ça a été abolit y’a 150 ans

Fun fact : c'est partiellement faux. L'esclavage n'est pas aboli dans les prisons américaines ! C'est pour ça que les prisonniers aux USA peuvent travailler sans recevoir la moindre compensation.

Quelques États des États-Unis garantissent une paie minimum pour les prisonniers-travailleurs, mais des États tels que la Géorgie ou le Texas, ont un seuil bas de zéro.

Le 30e amendement de la constitution des États-Unis interdit l'esclavage et la servitude non bénévole, « Excepté comme une punition pour un crime où la partie a été dûment jugée » (« except as punishment for crime whereof the party shall have been duly convicted. »).

Les prisonniers eux-mêmes comparent leurs conditions de travail à celle des esclaves

Telegram eux même induise le consommateur en erreur en stipulant dans leur FAQ que Telegram est « more secure than mass market messengers like WhatsApp and Line ». La vérité c'est que par défaut le chiffrement autorise les serveurs de Telegram à lire le message. Pour avoir le chiffrement client à client, il faut démarrer une conversation secrète.

Donc d'un point de vue strictement technique, Telegram est moins sécurisé que WhatsApp.

Je ne comprends pas pourquoi un tel succès sur Whatsapp, les alternatives sont bonnes voir meilleures

Signal et Telegram compressent moins bien les photos et les vidéos que WhatsApp. Les appels audio et vidéo dans WhatsApp on toujours fonctionné, sur Telegram et surtout Signal c'est beaucoup plus instable. De plus Telegram n'est pas chiffré par défaut.

Cela te concerne aussi, vu que tu t'acharnes à vouloir étouffer les réponses à ton commentaire. Peut-être que tu devrais simplement passer ton chemin comme tu le préconise ;)

Tu trouveras très facilement des comparaisons entre les deux versions avec une simple recherche sur ton moteur de recherche préféré.

C'est exactement ça : une histoire de contexte. Le racisme en Europe et USA n'ont pas les mêmes symboles.

J'ajouterais qu'il y a une différence majeure entre la manière dont le racisme est combattu en Europe et aux USA.

En Europe le racisme est combattu de façon universelle. Tout groupe est sujet au même racisme. On combat LE racisme.

Au USA, chaque groupe combat "son" racisme, un peu à la manière d'un lobby. La racisme anti-noir est vu comme bien différent du racisme anti-mexicain par exemple.

La encore ça permet de comprendre pas mal de chose aux récents événements BLM.

Et enfin github ne pouvait pas vraiment restreindre ce renommage uniquement aux Américains. Sinon ils auraient fait comme Blizzard, qui a par exemple une version de WOW pour la Chine qui censure des références à la mort. Mort qui est vu de façon beaucoup plus négative que dans la culture occidentale.

C'est un bug dans la fabrique d'espace-temps, rajoute de l'espace et ton problème est réglé.

Peut-être une boucle for ?

for f in *.c do
    gcc -o $(basename $f .c).o -c $f
done

Bon du coup c'est pas aussi simple car ça suppose d'avoir une fonction qui permet de changer l'extension d'un fichier, et aussi d'avoir des variables.

Un avantage : avoir une nouvelle release plus rapidement, lorsque les devs le décident, sans besoin de packagers externes au projet.

Ce qui est pas du tout un argument pour Teeworlds par exemple puisqu'ils doivent quand même maintenir des téléchargement pour ceux qui n'utilisent pas Steam. De même pour BfW j'imagine.

Un autre avantage : une intégration avec le "steam cloud" qui est bien pratique pour reprendre une partie là où on l'avait laissé sans se soucier de rien.

Steam cloud, en plus de fournir des donnée à Valve, n'est pas du tout dans l'esprit du libre, mais soit…

Alors ce fléau des jeux libre qui sorte avec Steam c'est un énorme problème. Il y a quelque année Teeworlds avait amorcé le mouvement, vous pouvez retrouver la discussion sur le forum Teeworlds ici. La promesse d'un afflue de joueur et d'un souffle d'air frais ne ce sont pas produite, et je ne suis au courant d'aucun jeux libre à qui la sortie sous Steam à profité, absolument aucun. Le seul gagnant dans l'histoire c'est Steam qui profite d'un bon coup de pub, d'une meilleur image et de la notoriété de ces jeux libre qui croient faire une bonne affaire.

Mais est-ce que la taille des blocs à elle seule justifie un hard fork ?

Quand les frais de transactions sont aux alentour de 10$ et que les transactions mettent plus d'un jour pour confirmer, oui.

Bitcoin Cash n'implémente pas segwit, qui est nécessaire pour LN. (Résout le problème de maléabilité)

Donc Bitcoin Cash est anti-LN.

Il y a bien d'autres manières de résoudre le problème de la malléabilité. Le refus de Segwit ne rend pas Bitcoin Cash anti-LN.

Bitcoin Cash n'est pas fondamentalement anti-LN, et reste ouvert à toute solution de ce type. Cependant, aucune solution n'est actuellement suffisamment mature pour être utilisée par le plus grand nombre. Alors en attendant, Bitcoin Cash reste pragmatique et augmente la taille des blocks. Là ou Bitcoin Core préfère prendre le risque d'une blockchain pleine à cracker.

En ce qui concerne les hardforks, si ils sont coordonnés et planifiés, l'expérience montre qu'il ne sont pas problématique. Ethereum hardfork régulièrement et tout ce passe assez bien. Par le passé Bitcoin a déjà eu un hardfork d'urgence quand quelqu'un avait exploité un overflow et créé des centaines de millions de bitcoins. Pas plus tard qu'aujourd'hui Bitcoin Cash a hardforké sans aucun problème.

Quoiqu'il en soit le coût de minage doit être répercuté sur le coût des transactions.

À terme oui, actuellement non. La récompense des blocks minés est encore très importante et suffit à elle seule à donner une marge assez conséquente aux mineurs. À terme, en effet, les frais de transaction seront plus ou moins dépendants du coût de minage.

D'autre part, il me semble que pour chaque détenteur d'un portefeuille de crypto-monaie il faut avoir une copie de la blockchain.

C'était le cas au début, mais ça fait quelque temps déjà que ce n'est plus necéssaire.

Enfin, le site que je cite me paraît tout à fait fiable. Même si ce ne sont que des estimations, elles sont corroborées par plusieurs autres études universitaires.

Je n'ai pas trouvé sur ce site le chiffre de 35 euros par transaction. Mais quoiqu'il en soit, le coût relatif au processus de minage ne dépend presque pas du nombre de transactions. Comme expliqué dans le commentaire précédent.

C'est quoi l'avantage pour les utilisateurs si bitcoin ne fait pas concurrence au moins au niveau tarifaire avec tous les systemes de paiement classiques?

Hola mon pauvre ami, tu touches du doigt un sujet très sensible.

Les frais de transaction actuels sont plus le résultat d'une volonté délibérée des développeurs de ralentir Bitcoin plutôt qu'une inévitable finalité. Cette décision plus que contestée est même à l'origine d'un fork : Bitcoin Cash. Alors déjà pourquoi des frais aussi élevés ?

Il se trouve que les blocks sont plein à cracker depuis 7 mois environs. Comme il manque de la place, les transactions avec le plus de frais sont acceptées en priorité. Cette congestion n'est pas vraiment une surprise car dès 2013 certains développeurs avaient exprimé leurs craintes. La proposition en vogue à l'époque était simplement d'agrandir les blocks pour qu'ils contiennent plus de transactions. Simple, facile à programmer et instantannée, c'est la voie choisie par Bitcoin Cash. Mais pourquoi les développeurs de Bitcoin ne veulent pas l'appliquer ?

Selon eux, cela entraînerai une augmentation telle de la bande passante nécessaire pour faire tourner un nœud qu'à terme Bitcoin ne s'en relèverai pas. Notons que la bande passante est effectivement le goulôt d'étranglement principal d'un nœud qui ne mine pas. Cependant, cet argument n'en est un que si l'on considère des blocks vraiment énormes, comme 128Mo. Les calculs sont un peu compliqué, notamment car ils dépendent du nombre de connexions ouvertes, nombre qui doit être suffisamment élevé pour que le réseau soit rapide, fiable et décentralisé.

L'autre raison à moitié avouée, c'est qu'une startup, Blockstream, emploie et/ou influence les principaux développeurs de Bitcoin. Cette startup actuellement travaille en autres sur une technologie basée sur la blockchain: les sidechains. Il s'agit dans les grandes lignes de créer des blockchains « annexes » qui ont chacune des propriétés différentes pour favoriser certains cas d'usage. Seulement voilà : il n'y a pratiquement aucune raisons pour les utilisateurs de Bitcoin d'utiliser autre chose que la blockchain principale si cette dernière fonctionne très bien. En faisant en sorte que la blockchain principale soit chère et lente, Blockstream est en train de construire une demande artificielle pour ses sidechains (ainsi que d'autres technologies plus ou moins similaires dîtes « de second niveau »).

Au lieu d'augmenter simplement la taille des blocks, les développeurs de Bitcoin ont opté pour une solution plus complexe : SegWit. Pour faire court elle consiste à créer un nouveau format de transaction plus compact. Ce format coexiste avec le format classique, et doit donc être manuellement adopté par chaque utilisateurs/entreprises. Cette adoption est lente et tous ne veulent pas franchir le pas, pour diverses raisons.

---

Donc on en est là, il y a cette guerre interne entre « Bitcoin Core » d'un côté et « Bitcoin Cash » de l'autre. Au cœur de cette guerre repose la question du futur de Bitcoin, ainsi que celle des frais transaction. La situation est évidemment bien plus compliquée, mais il me faudrait une journée entière rien que pour en faire un historique.

Le coût en énergie du processus de minage n'est que très peu dépendant du nombre de transactions qu'un block contient. Uniquement l'en-tête des blocks est minée, qu'il y ait 0 ou 1 milliard de transaction ne rend pas le block plus dur à miner. Alors certes, il faut tout de même que le mineur vérifie chaque transaction avant de les inclure dans le prochain block a miner. Mais cette vérification a un coût très marginal au regard de l'énergie qu'il va falloir dépenser pour miner le block.

En fait « 0 » est une valeur spéciale du point de vue du compilateur. En effet, « 0 » peut initialiser un nombre mais aussi un pointeur :

int foo = 0;
int *bar = 0;
int (*baz)() = 0;

Certaines machines ont une valeur pour les pointeurs nuls qui n'est pas forcément 0. Dans un tel cas le compilateur utilisera cette valeur en mémoire pour initialiser le pointeur. Le programmeur quand à lui ne ce préocuppe pas de cette valeur spéciale, tout le travail de conversion de 0 à la valeur réelle utilisée en mémoire par la machine est fait par le compilateur.

Notons que pour initialiser un pointeur il est aussi possible d'utiliser (void*)0. NULL en pratique peut avoir deux définitions possible :

#define NULL 0
#define NULL (void*)0

Mais la seconde définition est préférable, en effet, le code suivant est invalide si NULL vaut 0, car l'opérateur de conversion %p doit être utilisé avec un pointeur et non un entier :

printf("%p", NULL); // Erreur si NULL = 0

0 et (void*)0 sont des valeurs spéciales qui peuvent être utilisées pour initialiser tout types de pointeurs, y compris les pointeurs de fonctions :

int (*foo)() = 0;
int (*bar)() = (void*)0;
int (*baz)() = (void*)(void*)0; // Erreur

Par exemple, Bitcoin (et sans doute d'autres) sont effectivement une sorte de pyramide de Ponzi, car le premier investisseur a pu amasser plein de Bitcoins presque gratuitement, les autres c'est la guerre.

Ce n'est pas la définition d'une pyramide de Ponzi. Heureusement car pratiquement toutes les entreprises seraient des pyramides de Ponzi puisque les fondateurs ont eut les actions « presque gratuitement, les autres c'est la guerre ». « Un système de Ponzi est un montage financier frauduleux qui consiste à rémunérer les investissements des clients essentiellement par les fonds procurés par les nouveaux entrants. »¹

¹: Système de Ponzi

Essaye Tree Style Tab si tu as beaucoup d'onglets. Non seulement les onglets redeviennent rectangulaire, mais en plus ils sont organisés dans une arborescence, le tout à la verticale !

Quand on vire un truc, on commence par le désactiver à la compilation, pour ensuite le virer complètement si personne n'hurle (réellement = ça lui est utile au point qu'il va passer du temps ou payer pour), une façon très classique de tuer du code, tu ne connais pas?

La question n'est pas là : le code est toujours présent, de fait, ils devront s'en occuper tant qu'il n'aura pas disparu.

Parce qu'ils ont décidé autrement pour certaines raisons et tu remets en cause sans vraiment dire en quoi ça pose problème (à moins que tu penses que les réticents de PA soit très nombreux, mais j'ai comme un doute sur cette affirmation).

Si ce n'était pas évident pour toi : forcer Pulseaudio, ça pose problème aux personnes… qui n'utilisent pas Pulseaudio. Alors qu'il est possible techniquement de supporter plusieurs serveurs sons.

Non, tu as dis que c'était raisonnable, donc ça signifie que le coût n'est pas bien méchant, donc tu peux t'en charger, puis tu dis "ha ben non, pas le temps" donc ça démontre que tu ne crois même pas dans ce que tu dis que c'est raisonnable.

Tu me fais dire beaucoup de chose, ton imagination est débordante. Ce que je dis ne va pas plus loin que du point de vue de Mozilla, ça me semble raisonnable : le gros du code existe déjà, le diff entre les deux code montre ou sont les endroits qu'il faudrait rendre configurable, cela me semble raisonnable, ne crois-tu pas ?

Mais qu'on ne me fasse pas dire ce que je ne dis pas

Cocasse.

Et juste pour info, les paquets des repos sont maintenus par les mainteneurs de distros, donc c'est aussi leur faute […]

Tout à fait, et comprend bien que je ne cherche pas à montrer quelqu'un du doigt.

Dans ce cas, tu changes complètement l'idée (tu passes de "on ne veut plus gérer les merdes, on laisse dans les sources et démmerdez vous si vous décidez de compiler" à "on offre l'option donc on va avoir des rapports de bugs à gérer").

Le fait qu'ils laissent le code pour ALSA dans les sources va aussi les obliger à gérer les rapports de bugs pour ALSA. Je crois que le problème est surtout de rendre le choix du serveur son plus accessible.

Raisonnable? Oui, si toi tu t'engages à gérer les bugs (je parie que ce qui était raisonnable quand les autres doivent bosser devient déraisonnable quand tu dois le faire…)

Cette proposition me semble raisonnable car le code pour ALSA existe déjà, il faut ensuite permettre de pouvoir choisir quel code on veut exécuter. C'est évidemment plus facile à dire qu'à faire, mais ils ont montré qu'ils étaient capable de supporter Pulseaudio et maintenir le code d'ALSA.

Je pourrais m'en occuper mais je ne suis pas payé et je suis occupé avec d'autres projets. Si Mozilla accepte les rapports de bugs c'est aussi pour être à l'écoute de ses utilisateurs. Je ne voie pas en quoi il est aberrant, comme tu sembles le sous-entendre, de proposer cette fonctionnalité sans m'engager à en porter la responsabilité.

la décision des développeurs de Firefox d'utiliser désormais PulseAudio comme sortie audio par défaut

Notons qu'il ne s'agit pas seulement du changement du serveur son par défaut, mais de la suppression par défaut du support d'ALSA. Pour le réactiver, il faut le faire à la compilation. Il est tout à fait raisonnable de supporter ALSA et Pulseaudio et avoir une option dans about:config pour choisir celui que l'on veut utiliser.

Quel différence avec err(3) ?

Ce sont des extensions BSD¹, donc non POSIX et probablement pas très portable. Je préfère utiliser POSIX quand c'est possible.

Oui, l'un provoque un dump et pas l'autre. Si l'on veut un dump, on peut alors effectivement utiliser perror(1) puis abort(3).

Exactement, et je ne suis pas sur qu'un dump soit vraiment pertinent dans ce cas : une allocation qui échoue ce n'est pas un bug.

D'autant que : une segfault ou abort() provoque l’envoi du signal SIGSEGV (ou SIGABRT) et donc les fonctions enregistrées par atexit() ne seront pas exécutées. Le code de retour du processus sera supérieur à 128 ce qui signifie que le processus c'est terminé anormalement, etc…

---

¹: Page de manuel Linux: « Conforming to: These functions are nonstandard BSD extensions. ». La page de manuel de FreeBSD précise qu'il faut privilégier strerror() pour du code portable : « The err() and warn() families of functions are BSD extensions. As such they should not be used in truly portable code. Use strerror() or similar functions instead. ».

Je trouve que wrapper malloc() est déjà trop lourd, je préfère rester simple, surtout en C. Dans tout les programmes non interactif, j'exit() après avoir utilisé perror():

    if (!(foo = malloc(size))) {
        perror("malloc(foo)");
        exit(EXIT_FAILURE);
    }

Notez qu'il est possible d'avoir un message d'erreur un peu plus personnalisé si vous le souhaitez :

    if (!(foo = malloc(size))) {
        fprintf(stderr, "malloc(%zu): %s\n", size, strerror(errno));
        exit(EXIT_FAILURE);
    }

Mais peu importe les circonstances, intentionnellement provoquer une segfault est une très mauvaise pratique, car il est alors impossible de faire la différence entre un crash à cause de malloc() et un bug réel, d'autant qu'un crash et qu'un exit() ce n'est pas la même chose.

Dans les programmes interactif ou les bibliothèques, j'échoue toujours gracieusement. A ce propos, voici une astuce assez connue à base de goto pour nettoyer les ressources allouées dans une même fonction (les messages d'erreur sont omis) :

int fum(size_t size)
{
    void *foo, *bar, *baz;

    if (!(foo = malloc(size)))
        goto err_foo;

    if (!(bar = malloc(size)))
        goto err_bar;

    if (!(baz = malloc(size)))
        goto err_baz;

    /* ... */

    return 1;

err_baz:
    free(bar);
err_bar:
    free(foo);
err_foo:
    return 0;
}

---

Mais voici le point ou je voulais en venir : le plus possible j'essaye d'utiliser l'allocation « sur la pile »* ou statique. Cela veut dire mettre une borne haute à mes conteneurs. Combiné à sizeof() c'est une façon de faire qui est très plaisante, et très rapide de surcroît. L'utilisation de snprintf() est un vrai plaisir :

struct player {
    char name[32];
    char clan[32];
};

static void set_default_player_name(
    struct player *player, const char *firstname, const char *lastname)
{
    snprintf(player->name, sizeof(player->name), "%s.%s", firstname, lastname);
}

Un exemple pas très recommandable mais qui montre que sizeof() est très pratique :

#define IPV6_STRSIZE sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx")

Dans l'exemple qui suit, notez bien la ligne buf[] = "yyyy-mm-ddThh-mm-ssZ". Les dates au format RFC 3339 ont une taille fixe, c'est un des nombreux avantages de ce standard. Voici un excellent article sur la gestion des dates et des temps en C.

/* RFC 3339 */
static void print_zulu_time(struct tm *tm)
{
    char buf[] = "yyyy-mm-ddThh-mm-ssZ";

    if (strftime(buf, sizeof(buf), "%Y-%m-%dT%H:%M:%SZ", tm))
        puts(buf);
}

Même pour ce qui ne relève pas des chaînes de caractère j'essaye de trouver des bornes haute raisonnable :

#define MAX_PLAYERS 32
#define MAX_PACKET_DATA 1400

Au final, je me retrouve très rarement à utiliser malloc(). Uniquement dans les cas ou la taille est potentiellement trop grande pour allouer « sur la pile »* ou statique. Et lorsque je ne connaît pas à l'avance la taille de mon buffer, alors j'utilise souvent realloc()…

---

*: Techniquement, le standard C n'a pas de notion de pile, lorsque l'on dit « variable allouée sur la pile », on fait référence aux variables avec une automatique storage duration. Enfin bon, ça ne change pas grand chose.

D'expérience ce n'est pas toujours le cas. J'ai eu plusieurs fois aucun retour pour le service fcgiwrap ou fcgiwrap.socket, alors même que le service ne s'était pas lancé correctement.

À la seule différence que cette fois-ci tu as le droit de choisir ! Ici, soit tu utilises le fork, soit tu ne l'utilises pas. Chaque fork est une sorte de référendum.