needs a écrit 322 commentaires

  • [^] # Re: Core VS Cash

    Posté par . En réponse au journal L'arnaque bitcoin. Évalué à 1.

    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.

  • [^] # Re: Core VS Cash

    Posté par . En réponse au journal L'arnaque bitcoin. Évalué à 1. Dernière modification le 13/11/17 à 23:24.

    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.

  • [^] # Re: C'est pas cher

    Posté par . En réponse au journal L'arnaque bitcoin. Évalué à 3. Dernière modification le 13/11/17 à 08:57.

    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.

  • # Core VS Cash

    Posté par . En réponse au journal L'arnaque bitcoin. Évalué à 10. Dernière modification le 13/11/17 à 07:56.

    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.

  • [^] # Re: C'est pas cher

    Posté par . En réponse au journal L'arnaque bitcoin. Évalué à 3.

    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.

  • [^] # Re: Comportement attendu

    Posté par . En réponse au journal Compilateur trop intelligent. Évalué à 3.

    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
  • [^] # Re: Tu t'emballes

    Posté par . En réponse au journal Conséquences sociales des cryptomonnaies. Évalué à 5.

    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

  • [^] # Re: Onglets rectangulaires

    Posté par . En réponse au journal Firefox Photon: comment l'interface va redevenir ce qu'elle était. Évalué à 7.

    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 !

  • [^] # Re: Eh ben non

    Posté par . En réponse au journal Lennart a encore frappé !. Évalué à 2.

    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.

  • [^] # Re: Eh ben non

    Posté par . En réponse au journal Lennart a encore frappé !. Évalué à 4. Dernière modification le 11/03/17 à 12:16.

    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é.

  • [^] # Re: Eh ben non

    Posté par . En réponse au journal Lennart a encore frappé !. Évalué à 3.

    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.

  • [^] # Re: foobar

    Posté par . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 2.

    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. ».

  • # foobar

    Posté par . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 6. Dernière modification le 27/10/16 à 12:52.

    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.

  • [^] # Re: Héhé

    Posté par . En réponse au journal Microsoft: Powershell libéré. Évalué à 3.

    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.

  • [^] # Re: mimétisme

    Posté par . En réponse au journal Ethereum, The DAO et un petit malin sont sur un bateau.... Évalué à 3. Dernière modification le 19/06/16 à 23:41.

    À 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.

  • [^] # Re: Bug ferme chez tmux

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7. Dernière modification le 05/06/16 à 15:23.

    Tu déformes le journal en disant que "systemd est moins bon que SySVInit", il dit juste qu'une option par défaut ne lui convient pas (la belle affaire).

    Tu as mal lut mon propos, ou j'ai mal compris le tient. Je concède que systemd est meilleur que SysVInit pour les mainteneurs d'une distribution. De part les retours que tu peux lire ici même et ailleurs sur internet, systemd est à la fois apprécié et décrié par les sysadmin. De même, systemd est source de nombreux problèmes pour les développeurs et utilisateurs lambda. Il existe des alternatives tout à fait valable à SysVInit, comme minit ou runit.

    En quoi c'est le problème de systemd ? Upstart a un système pour rendre compatible avec ce que propose systemd.

    C'est le problème de systemd car avant systemd il n'y avait pas à « être compatible avec systemd », et après systemd il faut « être compatible avec systemd ». Ou dit autrement, systemd casse un système qui était stable en redéfinissant le rapport entre les programmes utilisateurs et un système d'init, de force.

    Tu peux donner des sources ? Quelles "programmes" ne fonctionnent plus en dehors de systemd ?

    GNOME, KDE, tout les programmes qui utilisent udev, avahi et probablement d'autres. Sans compter les multiples bugs (comme pour tmux) qui forcent les développeurs a intégrer un « switch systemd » dans leur code, histoire de bien marquer au fer rouge la communauté.

  • [^] # Re: Bug ferme chez tmux

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.

    Et si vraiment la communauté des utilisateurs de Linux n'en voulait pas, Devuan n'en serait toujours pas en beta alors que la première version était annoncé pour le printemps 2015.

    Les utilisateurs n'ont pas tous les compétences, le temps, la motivation de maintenir une distribution (qui plus est basée sur Debian). Encore une fois, systemd est une avancé par rapport à SysVInit du point de vu des mainteneurs. C'est une régression du point de vue des développeurs et utilisateurs lambda. Devuan n'est d'ailleurs pas une alternative à systemd, c'est un fork de Debian sans systemd.

    Encore une fois non. Dire que systemd a été poussé de force, c'est falacieux. Il n'a pas été poussé, il a été développé par Redhad. Redhat n'a pas été contraint, il en a fait le choix.

    Systemd n'a pas été développé par Redhat en premier lieu, comme l'explique Lennart¹, il s'agit d'un projet personnel. Seulement puisque Lennart est un employé de Redhat (Et Kay Sievert de Novell) il a été plus facile d'intégrer systemd à Fedora, il en parle même dans le lien donné plus haut. Donc ce n'est pas fallacieux.

    Ton programme, s'il utilise un système de logs, dbus ou udev ne dépend pas de systemd. Ces fonctionnalités sont des interfaces et systemd est une implémentation de ces interfaces.

    Il ce trouve que si, car pour le moment systemd est le seul programme qui implémente toute ces interfaces, plutôt complexes. Il faut bien voir qu'avant ces interfaces étaient toutes implémentées par des programmes plus ou moins indépendant. Petit à petit ces programmes ont été intégrés à systemd. Elle vient de là la dépendance à systemd. Il faut aussi voir que c'est bien l'équipe de systemd (ou des personnes des mêmes employeurs) qui définit à la fois le standard² et l'implémentation de référence.

    Il faut que tu m'expliques le lien entre la position de systemd sur un système et "la raison majeure de son adoption massive". Il a été adopté car il répondait à un besoin, pas parce qu'il se place à tel endroit dans la pile système.

    systemd est un deuxième élément critique du système, le premier étant le noyau. Il ce place intentionnellement entre tout programmes utilisateur et le noyau, forçant son adoption ainsi que rendant plus difficile la mise en place d'alternatives. Est-ce plus clair ?

    Au contraire, l'exemple est des plus convaincant. Dans les deux cas, on dispose d'un techno présente depuis des décennies. (…) Les choses ont énormément évoluées, les contraintes (en disque, en ram, en processeur, etc…) ne sont plus du tout les mêmes et les outils ont aussi évolués.

    C'est vague et s'applique globalement à tous les programmes informatique. Non, ce n'est définitivement pas convaincant. De plus, plus de « disque, ram, processeur, etc… » n'est pas une raison pour faire des mauvais programmes et augmenter la complexité du système.

    Et on essaie de la remplacer car, il faut le dire, une décennie en informatique, c'est une éternité.

    L'age n'est pas un argument, et non, une décennie ce n'est pas une éternité, il ne faut pas exagérer.


    ¹: Quand bien même il précise que systemd dans ses premiers jours à reçut une collaboration de Key Sievert de Novell, il en vient assez vite à parler d'inclure systemd dans Fedora. Il ne cache pas ses objectifs, qui sont très certainement aussi ceux de son employeur.

    ²: DBus est contrôlé par RedHat, udev a été développé et maintenu en partie par Kay Sievert

  • [^] # Re: Bug ferme chez tmux

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.

    Je ne prétends pas répondre à la place de Grégoire G, ce serait malvenu, mais tu exagères son propos et tu lui fais dire ce qu'il n'a pas dit.

    Mais ce n'est pas parce que Redhat n'est pas adapté à TON usage que c'est de la merde.

    Il ne prétend pas que « c'est de la merde », il préfère Debian à RedHat, sans pour autant qualifier RedHat de « merde ».

    Ben pour des serveurs, je trouve ça cool. Ca t'évite d'avoir des services non configuré qui vont être lancé automatiquement.

    Il n'a pas dit le contraire. Il mentionne juste un cas précis, et tu en a fait une généralité.

    Systemd, la source de tous les mots.

    De même, il précise qu'il trouve systemd « pénible », et tu généralises sans fondement.


    Systemd a apporté de nombreuses réponses à bon nombre de problème (il n'y a qu'à voir son adoption rapide par les distributions. Si c'était si inutile que ça, il n'y aurait pas eu tant d’engouement).

    L'adoption de systemd n'est pas le résultat d'un consensus de la communauté des utilisateurs de Linux. Les paragraphes qui suivent devrait te convaincre.

    Premièrement, il faut reconnaître que systemd est plus facile à utiliser que SysVInit pour les mainteneurs d'une distribution. Et c'est pourquoi il a été adopté, car ces sont précisément les mainteneurs qui ont le dernier mot sur les programmes par défaut d'une distribution.

    Ce ne sont pas les utilisateurs (autant sysadmin, développeurs ou personne lambda) qui ont choisi systemd. Et il ce trouve que systemd est moins bon que SysVInit du point de vue utilisateur, comme le montre ce journal et de nombreux autres avant, ici ou ailleurs sur Internet.

    Il faut aussi reconnaître que systemd à été poussé de force dans RedHat et Fedora, tout simplement car RedHat contrôle ces deux distributions. Cette migration a forcé certain programmes à être fortement dépendant de systemd, notamment car systemd est conçut comme un monolithe. Si tu dépends d'une fonctionnalités quelconque de systemd, alors tu dépends la totalité de systemd.

    Rappelons aussi que systemd contient en autres udev, un système de logs, un gestionnaire de session, et gère une partie de dbus. Ainsi les programmes qui ont besoins de telles fonctionnalités doivent inclure du code pour pouvoir fonctionner sur un nombre croissant de distributions. Et comme maintenir plusieurs version d'un même code est difficile, certain programmes sont devenu simplement dépendant de systemd.

    Un peu à la manière de pulseaudio qui ce place entre tout autre serveur son et le noyau, systemd ce place entre tout programmes utilisateurs et le noyau. C'est la raison majeure de l'adoption massive de systemd. Et c'est pourquoi le terme « forcé » est tout à fait approprié.

    C'est encore une fois un cas typique qui montre qu'une adoption massive n'est en générale pas corrélé à la qualité technique.


    Tiens, on va prendre un exemple : systemd et wayland. Systemd est sorti en 2010 et à déjà été adopté par la grande majorité des distributions. Wayland existe depuis 2008 et à encore pas mal de chemin à faire.

    Wayland n'est pas aussi mature que systemd. Le contexte n'est pas le même, les programmes ont des finalités bien différentes. Bref, c'est comparer l'incomparable, cet exemple n'est pas convaincant.

  • [^] # Re: Bug ferme chez tmux

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5.

    Redhat, et systemd appportent beaucoup de problèmes. Je suis curieux de savoir lesquels sont résolus. Sincèrement, avec systemd, la plupart de mes machines sont devenues lente à l'extinction.

    Je te seconde sur ce point avec un petit retour d’expérience personnelle. Depuis au moins 6 mois, lorsque j’éteins mon ordi (ArchLinux) il y a environ :

    • 6 chances sur 8 qu'il reste allumé avec un écran noir, le rétro éclairage toujours allumé
    • 1 chances sur 8 qu'un processus (lequel?) bloque l'extinction pendant 1m30, le délais maximum
    • 1 chances sur 8 qu'il s'éteigne convenablement en moins de 10 secondes

    J'en ai globalement rien à faire car mon ordi ayant plus de batterie, j'ai juste à débrancher le câble d'alimentation pour l'éteindre brusquement. Pour des raisons qui me sont obscure, mon ordi n'a jamais été très compatible avec les programmes de Lennart, à savoir pulseaudio, NetworkManager, journalctl et systemd.

  • [^] # Re: systemd, le nouveau Multics

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10. Dernière modification le 03/06/16 à 18:11.

    Quand je vois la simplicité d'un fichier de config systemd pour l'immense majorité des cas (limite un unit file d'un daemon simple c'est 3 lignes, le nom du service, le binaire à lancer, et l'utilisateur) et les critiques style "mais ça casse mon script d'init de 1500 lignes pour mon usine à gaz ignoble", je dirais que c'est tout le contraire.

    Il existe des systèmes d'initialisation on ne peut plus simple, comme runit, ou minit par exemple. La aussi c'est une histoire de moins de 10 lignes. Ce qui est important de comprendre, c'est que 10 lignes pour systemd et 10 lignes pour runit n'ont pas la même complexité lorsque l'on regarde le système dans son ensemble.

    Systemd, c'est pas moins dans 270 000 ligne de C¹, dont 44 000 pour la gestion des services². Le code de minit ne dépasse pas les 1700 lignes, et celui de runit, 6500 (ou 3400 lorsque l'on ne compte pas la réimplantation partielle de la lib C³). C'est sans compter le fait que systemd définit plus de 60 services et bibliothèques⁴ qui sortent complètement du champs d'un système d'init.

    Enfin systemd fait tout pour ce placer entre le noyau et un programme utilisateur. Ce qui ajoute un deuxième point critique au système, le premier étant le noyau (monolithique, lui aussi). Tout ceci montre que systemd est d'une complexité beaucoup plus grande que ce qui est nécéssaire, comme le montre les alternatives fonctionnelles. De plus cette complexité ce retrouve au cœur du système et envahit l'espace utilisateur. C'est pourquoi il est fallacieux de qualifier systemd de « simple », et présumer qu'une alternative est nécessairement complexe (« 1500 lignes »). La situation actuelle tend à montrer l'inverse, systemd étant complexe, et les alternatives en moyenne sont assez simples.


    ¹: En ne considérant que les fichiers du répertoire src.

    ²: Systemd étant un énorme monolithe, on ne peut pas séparer uniquement la partie du code qui gère les services. Ainsi, on obtient le chiffre de 44 000 lignes de code en ne comptant que le code dans src/core et src/systemctl.

    ³:runit/src $ cloc chpst.c runit-init.c runit.c runsv.c runsvchdir.c runsvctrl.c runsvdir.c runsvstat.c sv.c svlogd.c svwaitdown.c svwaitup.c utmpset.c

    ⁴:ls systemd/src | wc -l, qui donne 76. Résultat duquel il faut soustraire au moins trois fichiers, le Makefile, src/core et src/systemctl, plus une bonne demi-douzaine pour des dossiers qui ne définissent ni services, ni bibliothèques.

  • [^] # Re: Ne pas utiliser, recompiler… ou changer une option.

    Posté par . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5.

    Systemd, ou comment ne pas encourager l'écriture d'applications au comportement propre. C'est sûr, ce gars a une vision à long terme pour linux…

    Il y a une part de vérité. Si il y a un bug dans kdeinit, c'est pas dans systemd qu'il faut le corriger/le cacher.

  • # I ❤ Bernard

    Posté par . En réponse au journal « Merci Patron ! » au cinéma. Évalué à 5.

    Suite à ce journal je suis allé voir ce film pour me faire une idée, et j'ai beaucoup aimé. À la fin de la projection il y a eu une demi-heure de questions-réponses avec des membres de l'équipe (je crois), elle aussi très intéressante. Un film qui laisse le spectateur comme seul juge, au point qu'une personne a demandé à l'équipe quelle était la morale de leur film :)

  • # AlsaCréations et flexbox

    Posté par . En réponse au journal Positionnement avec css. Évalué à 10.

    AlsaCréations est un site en français connu de longue date pour la qualité de ses articles. Voici leur article sur le positionnement. Je t'invite aussi à jeter un coup d’œil aux flex-box, c'est très simple, plaisant à utiliser et résout bon nombre de problèmes de positionnement.

  • [^] # Re: Concordant

    Posté par . En réponse au journal Bitcoin va très mal ?. Évalué à 5.

    Non, je voulais bien dire déflationniste : le lundi une baguette coûte 1 Bt, le mardi elle coûte 0.9 Bt, etc. C'est de la déflation

    Bien vu, j'ai confondu.

    un Satoshi serait trop gros pour servir de monnaie (environ 0.2$)

    Un Satoshi c'est 10^{-8} BTC, alors que le milli-bitcoin c'est 10^{-3} BTC. Si le bitcoin vaut 200$, le milli-bitcoin vaut 0.2$ et le Satoshi vaut 0.000002$. Pour qu'un Satoshi corresponde à 0.2$, il faudrait que le Bitcoin s'échange à 2 000 000$, ou dit autrement dans la page linkée plus haut :

    As of August 2015, 1 US cent is worth approximately 4400 satoshi.

  • [^] # Re: Concordant

    Posté par . En réponse au journal Bitcoin va très mal ?. Évalué à -3.

    La structure du Bt (déflationnisme intrinsèque, coût réel du minage de plus en plus élevé, etc)

    Tu voulais surement dire « inflationnisme intrinsèque » ? Puisqu'il y a un nombre limité de Bitcoins, et qu'un Bitcoin peut être perdu définitivement, il y aura de l'inflation sur le long terme.

    ni pour devenir une vraie monnaie (valeur d'un Bt bien trop élevée, et subdivision du Bt trop grosse à terme).

    Il suffit d'adopter une unité adéquate, comme le mili-bitcoin, ou le bit (micro-bitcoin). Sinon en quoi la subdivision du Bitcoin trop grosse est un problème ? Elle risque d'être justement trop petite ! Par exemple un Satoshi est la plus petite division possible d'un BTC (0.00000001 BTC), si une baguette de pain coûte 1 Satoshi, tu ne peux pas descendre plus bas et donc une demi baguette coûtera autant qu'une baguette complète.