David Demelier a écrit 653 commentaires

  • [^] # Re: Et hare, alors?

    Posté par  (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 2.

    Pourquoi? Tu aimes coder pour du proprio?

    Ça c'est propre à chacun mais refuser de base des plateformes pour des opinions personnelles c'est probablement pas la bonne décision pour un langage. Drew - dont l'égo surdimensionné n'est plus à démontrer - le manifeste une nouvelle fois avec ce langage (dont c'est pas sa seule décision arrêtée).

    Swift a beau être développé par Apple il est disponible sur une panoplie de plateformes même si on utilisations sur ces dernières reste sporadique

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: V is for vapoware ?

    Posté par  (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 3.

    Ça serait dommage, V m'intéresse plus que zig qui est un poil plus complexe. Mais c'est vrai que sa documentation est assez hypoglycémique.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Est-ce que c'est pas un peu tôt?

    Posté par  (site web personnel) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 2.

    Rust n'est pas un langage "general purpose".

    Tout à fait. Mais en plus de ça à être si sécurisé il se prête plutôt mal au développement d'OS ou 1/4 du code du kernel sera dans un bloc unsafe.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: La fin de la "stabilite" des standards ?

    Posté par  (site web personnel) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 4.

    Malheureusement C# et Java restent des langages qui font “enterprisy” et toujours enseigné dans les écoles. On va avoir du mal à enterrer ces langages tant que ce modèle n'évolue pas.

    Pour certains c'est impensable de quitter ces langages juste parce que derrière il y a des grosses entreprises qui poussent au développement. C'est dommage.

    Combien de fois j'ai entendu « nous utilisons exchange parce que c'est microsoft » au lieu d'utiliser un simple postfix/opensmtpd… Je suppose que c'est parfois pareil avec les technologies, tout domaine confondu.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Je change

    Posté par  (site web personnel) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 2.

    Je meurs d'envie de savoir comment tu fais. Ici, on doit optimiser le moindre appel en mettant le moins possible de variables sur la pile d'appel pour éviter un panic. Après on a laissé les paramètres par défaut et peut-être qu'on peut “enlarge my stack” s'il faut. En tout cas on a revu notre approche en favorisant parfois les allocations dynamiques même quand on aurait aimé s'en passer.

    git is great because linus did it, mercurial is better because he didn't

  • # Je change

    Posté par  (site web personnel) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 10.

    Ah ben si c'est Microsoft qui le dit, j'arrête le C immédiatement. Après tout, sur mon ESP32-S3 j'ai pas besoin de compter le nombre d'octets que je créé sur ma pile d'appel, il a une taille de de 8096 octets, bien assez pour faire tourner n'importe quel langage à boite noire !

    À mort le C !

    git is great because linus did it, mercurial is better because he didn't

  • # Compliqué d'être sans systemd aujourd'hui

    Posté par  (site web personnel) . En réponse au journal Artix, l'archer rebelle. Évalué à 7.

    Perso je suis ni pour ni contre systemd. Il y a des choses que j'aime bien et d'autres moins.

    Par contre, même si au départ il y avait beaucoup de distributions sans systemd, on ne peut pas nier que c'est de plus en plus difficile de s'en passer. Notamment parce que certains desktops en font parfois un prérequis à tel point que beaucoup de projets sortent des composants systemd en standalone (eudev, elogind). Mais à part ça, on peut aussi remarquer que certains projets deviennent de moins en moins maintenu. Les vénérables syslog et cron par exemple, la plupart des implémentations deviennent délaissées alors les sans-systemd deviennent vraiment des citoyens de seconde zone.

    C'est dommage, pas spécialement pour les linuxiens anti-systemd mais pour les gens qui tournent sur des systèmes alternatifs comme OpenBSD, illumos et autres. Par exemple, le mode night shift de GNOME n'est pas disponible sous les non-linux parce que colord a une dépendance stricte à udev (si je me souviens bien).

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Pièces de rechange : faut pas trop rêver non plus, même si ça passe

    Posté par  (site web personnel) . En réponse au lien L'UE met le nez dans la téléphonie et ça fait rêver. Évalué à 5.

    Je suis assez d'accord, les réparations sont parfois tellement chères qu'on rentre soi même dans le consumérisme.

    Je me rappelle encore chez Renault qui m'avait fait un devis pour une réparation pour ma voiture (lui même) « vu l'âge du véhicule, c'est pas la peine ». Alors imaginez pour un téléphone qui a une durée de vie bien moindre.

    Le gros problème, c'est même pas spécialement la réparation, c'est le travail nécessaire pour y arriver. Sur mon ancien HP j'avais juste un bouton à appuyer pour changer la batterie que j'ai pu faire deux fois. Pour un téléphone il faut chauffer l'écran, le décoller, décoller la batterie, remettre de l'adhésif et enfin recoller l'écran. Tout est fait pour être beau et non pratique.

    git is great because linus did it, mercurial is better because he didn't

  • # Peu pertinent

    Posté par  (site web personnel) . En réponse au lien malloc() and free() are a bad API. Évalué à 10. Dernière modification le 01 septembre 2022 à 17:07.

    [à propos de calloc]
    It also does an overflow check for you, because why not.

    Faux, c'est spécifique aux implémentations. Rien dans la norme ne le garantit et c'est une mauvaise idée d'utiliser calloc en pensant éviter un integer-overflow.

    [à propos de realloc]
    For starters, it can’t be used with C++ objects that might want to invoke a move constructor. It also doesn’t work with C objects that have self-referential pointers such as a buffer containing a circular linked list.

    Et en même temps, en C++ tu fais pas de realloc. À part dans de rares cas où tu as besoin de faire du placement-new, tu n'es pas censé jouer avec la mémoire de manière aussi basse.

    Si tu as peur d'avoir des pointeurs invalides à cause d'un déplacement de mémoire, tu fais pas de realloc ou tu fais des pointeurs de pointeurs. Blamer realloc pour ça n'est pas pertinent. La meilleure utilisation de realloc est probablement de manipuler une donnée unique ou un tableau de types primitifs. Celui qui utilise realloc pour reallouer des structures imbriquées se tire une balle dans le pied.

    Pour moi cet article n'a pas d'intérêt et répond à des problèmes inexistants.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Comme Gemini, un standard à refaire

    Posté par  (site web personnel) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 4. Dernière modification le 29 août 2022 à 13:20.

    Et blam, tu nous parles de rajouter une couche de consommation de ressource en chiffrant systématiquement :D

    Ouais enfin entre une publicité et du chiffrement il y a une différence. Le chiffrement ça consomme pas 3Mo de Javascript contrairement à une page web illisible.

    En revanche, moi je serais assez partant pour un nouveau protocol d'échange 100% chiffré parce que recevoir mes mots de passe de mailing list et mes fiches de paies par mail ça me gonfle.

    Les mails, c'est probablement la chose la moins bien faite de l'histoire d'internet (après ftp, ok) et son utilisation encore plus. (multipart, bottom-posting, séparation des couches, etc, etc.).

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Il se prend pour la voix de la sagesse

    Posté par  (site web personnel) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 4. Dernière modification le 27 août 2022 à 08:43.

    Ce n'est pas parce que c'est une personne qui a tous les défauts du monde qu'elle a nécessairement tort. Les deux choses sont tout à fait distinctes. Si à chaque fois qu'un de ses propos ou opinions est relayé, on a le droit à « de toute façon, c'est un sale type », on est bien avancés…

    Ce n'est pas le problème, c'est de prendre sa notoriété pour acquis et essayer de forcer les gens à son opinion. Essayez d'envoyer un mail HTML à son système de mailing list et vous serrez renvoyé chez vous avec un message du genre « les messages HTML sont mauvais, blablabla, voir cesiteenquestion ».

    Pour ma part, je suis d'accord que les mails HTML sont mauvais et je suis le premier à râler quand je vois les signatures HTML de 3Mo.

    Mais pour autant, je vais pas forcer les gens à ne pas l'utiliser tout en me faisant passer pour le messager de la sagesse parce que « j'ai raison ».

    Les opinions sont propres à chacun, forcer les gens à les suivre ça devient problématique.

    git is great because linus did it, mercurial is better because he didn't

  • # Il se prend pour la voix de la sagesse

    Posté par  (site web personnel) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 6.

    Il faut arrêter de suivre ce type qui s'auto proclame la voix de la sagesse en plus d'être une vraie drama queen.

    La plupart de ses articles sont de simples projections de ses opinions personnelles en tant que conseils sur nos manière de développer. Et quand nous faisons pas comme il souhaite, il se barre. Par exemple, chez Alpine Linux il a décidé que si on arrêtait les patchs par email (car on utilisait son système de mailing list) il arrêterait de contribuer. Il réinvente des outils parce qu'il n'a pas envie d'utiliser l'existant et en plus il les propage comme une véritable peste.

    Bref, je pense que c'est une personne qui a besoin de beaucoup d'attention et le fait savoir. Ne prenez pas ses articles comme un évangile.

    git is great because linus did it, mercurial is better because he didn't

  • # Le problème c'est glibc

    Posté par  (site web personnel) . En réponse au lien Win32 est la seule ABI stable sous Linux. Évalué à 10.

    Avec musl, l'ABI est bien moins souvent cassée. C'est à glibc qu'il faut casser les pieds si on veut une ABI stable, mais moi je persiste à dire que ceux qui veulent toujours et encore une ABI stable pensent résoudre un problème qui n'existe pas. Si on change pas les comportements et qu'on nettoie pas les bibliothèque, on se retrouve avec une usine à gaz ingérable.

    Le versioning des bibliothèques résout ce problème et je me souviens dans le passé avoir du installer une version spécifique de libstdc++ (fournie avec GCC) plus ancienne (.5 ou quelque chose) pour faire tourner mon jeu préféré de l'époque : ut2004. Mais à part ça, il me fallait aussi SDL 1.2 et autres bibliothèques totalement obsolètes.

    Vouloir une ABI stable c'est se cantonner au passé, sinon il suffit que les packagers fournissent des versions plus anciennes et le problème est résolu. Rien ne t'empêche d'avoir :

    • /usr/lib/libc.so.4
    • /usr/lib/libc.so.5
    • /usr/lib/libc.so.6

    Merci le versioning, merci ELF.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: précision

    Posté par  (site web personnel) . En réponse au lien NetBSD enfin disponible sur une plateforme moderne. Évalué à 3.

    Le gros problèmes des sites web qui sont pas spécialisés. Il y en avait une bonne à la sortie de la Nintendo Switch qui disait qu'elle tourne sous Linux Free BSD

    git is great because linus did it, mercurial is better because he didn't

  • # Les non binaires

    Posté par  (site web personnel) . En réponse au journal Petites blagounettes de tout poil. Évalué à 0.

    Ah celle sur les non binaires est absolument géniale, je te la pique. Je me demande comment un non binaire réagit quand il voit bool pour la première fois.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Nope

    Posté par  (site web personnel) . En réponse au lien Java est toujours un champion. Évalué à 4.

    Lenteur excessive. Les langages interpretés c'était bien avant

    Celle-là m'a bien fait rire.

    Je ne parle pas sans connaissance de cause, je maintien des applications en Java à mon travail et je t'assure que j'ai envie de trucider l'ancien développeur qui s'est dit que ça allait être une bonne idée de faire du Java sur de la Raspberry et de la BeagleBone.

    Le simple démarrage de l'application met déjà plus de 3 secondes avant même d'arriver dans nos premières fonctions. L'application en elle même n'est pas spécialement compliquée, mais tout est lent. Dire que Java est performant est de la pure mauvaise foi ;)

    J'ai fait du Java pendant plusieurs années, je ne parle pas dans le vent. Je m'intéresse à beaucoup de langages et c'est clairement celui dont je ne comprends toujours et encore pas l'intérêt. Comme c'est sujet à débat, je t'invite à me dire ce qui te plait dans ce langage et serait fortement ravi de savoir de quoi il s'agit.

    git is great because linus did it, mercurial is better because he didn't

  • # Nope

    Posté par  (site web personnel) . En réponse au lien Java est toujours un champion. Évalué à 2.

    Je comprendrai jamais l'intérêt que porte les gens sur Java. Ce langage principalement utilisé en école et en entreprise promeut tant de choses qu'on dit « bonnes » juste par principe mais finalement n'apporte rien :

    • Abus de l'héritage. Les langages récents comme Rust et Go démontrent que l'on peut faire des projets sans orienté objet. Ce paradigme est probablement voué à disparaitre à terme, il n'apporte que peu de solutions.
    • Abus des getters/setters. Les projets en Java sont ceux qui ont définitivement le plus de boilerplate juste parce « qu'il ne faut pas modifier une variable directement, saypabien ».
    • Lenteur excessive. Les langages interpretés c'était bien avant (#boomer). On a des boites à outils pour faire du natif sans se casser la tête (merci LLVM). “Java, write once, run away”.
    • Verbosité inutile. Il y a tellement d'abus des exceptions que tu te retrouves à écrire des horreur comme private RS232 connect() throws NoSuchPortException, PortInUseException, UnsupportedCommOperationException, IOException, TooManyListenersException, Exception {
    • Overengineering à outrance. Pour faire une chose simple en Java il faut instancier une factory qui crée une interface qui crée des objets.

    java

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Fauxpensource et libriste en carton ?

    Posté par  (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 4.

    Ça va ça fait moins mal qu'un MacPro et ses roulettes à 800 balles.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Fauxpensource et libriste en carton ?

    Posté par  (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 7.

    Le faux libriste lui achète un mac et n'installe pas linux dessus.

    J'ai un MacBook, il y a macOS dessus parce que c'est ma machine du quotidien et de MAO. Par contre j'ai un Thinkpad, un Thinkcentre et une multitude de Raspberry Pi sous OpenBSD (projet auquel je donne 10€ par mois), suis-je fiché non-libriste ?

    J'espère tout de même que mes contributions à Alpine me garde toujours dans le domaine du libriste malgré ma vilaine acquisition d'un MacBook !

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Une autre vision des exceptions

    Posté par  (site web personnel) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 3. Dernière modification le 08 août 2022 à 11:21.

    Dans ce cas là ça facilite les choses, mais dans une machine à états tu serais plus ou moins bloqué si tu ne sais pas à quel moment le getc n'a pas marché et donc revenir « en arrière » ne serait pas possible.

    Les exceptions peuvent souvent aider mais ils n'apportent pas toujours la réponse à toutes les solutions.

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Juste mon point de vue

    Posté par  (site web personnel) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 4.

    On ne sait pas faire une recherche dans une collection de manière totalement safe ?

    Si, mais si l'appelant sait qu'il n'y aura jamais une liste vide c'est dommage d'avoir à le retester dans une fonction pour rien. Surtout dans un programme à forte performance comme un jeu vidéo.

    git is great because linus did it, mercurial is better because he didn't

  • # À propos des exceptions

    Posté par  (site web personnel) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 2.

    C'est vrai que la questions de l'utilisation des exceptions reste toujours à débat chez les développeurs C++. Je suis ni pour ni contre mais je dois tout de même admettre que dans les langages modernes on arrive quand même à s'en passer (Rust, Go). Je les utilisais pas mal quand je faisais du C++ mais sur certains points c'est pas toujours pratique notamment dans un bloc de code comme ceci :

    int val;
    
    try {
        val = std::stoi("foo");
    } catch (...) {
    }
    
    continue_working_with_val(val);

    Actuellement je fais que du C et j'arrive à me débrouiller sans les exceptions (on peut faire du sjlj mais c'est quand même fastidieux). Alors, allons continuer vers des langages sans exceptions ?

    git is great because linus did it, mercurial is better because he didn't

  • # Extensions GNU

    Posté par  (site web personnel) . En réponse au lien Implémentation POSIX de make, dans le domaine public. Évalué à 3.

    Ce que je comprends pas c'est qu'il supporte explicitement des extensions GNU, quel intérêt du coup ?

    git is great because linus did it, mercurial is better because he didn't

  • [^] # Re: Respect de l'ABI

    Posté par  (site web personnel) . En réponse au journal Google forke C++. Évalué à 10.

    Exactement, comme je l'avais expliqué avec le SONAME des bibliothèques dynamiques. Globalement ça marche déjà bien mais les gens voulaient pouvoir mixer davantage les versions de bibliothèques (exemple avoir x fois Qt, Gtk, SDL, etc) pour faire tourner des versions différentes des applications.

    En gros, répondre à la plainte de « je suis sous cette distro (exemple debian), j'ai la version 1.2 de la bibliothèque mais il me faudrait la version 1.9 pour compiler ton projet. ».

    Du coup, on a copié microsoft windows : on embarque dorénavant toutes les bibliothèques directement dans les flatpak/snaps.

    Le linkage statique n'est pas la solution. Cette fois ci son cauchemar n'est pas le DLL hell mais le security update hell :) (et je parle pas des soucis de licence via le linkage statique).

    Bref, si tout le monde avait correctement versionné les bibliothèques (comme gtk, qt) on aurait aucun problème à avoir une version (ou plus) sur le même système et rendre tout le monde content.

    C'est pourtant assez simple :

    • tu changes la version majeure ? tu peux casser l'API mais alors fais en sorte de pouvoir cohabiter (exemple le nom de la bibliothèque change -lsdl, -lsdl2). Mets tes entêtes dans un sous répertoire (SDL/, SDL2/).
    • tu ajoutes une fonctionnalité mineure ? pas de problème tu la mets à disposition, si elle ne casse pas l'ABI tu peux même l'installer sans avoir à recompiler aucune application.
    • tu dois faire un correctif qui en plus casse l'ABI ? c'est le cas le moins cool mais tu augmentes le numéro de version de correctif, tu changes la version du SONAME et malheureusement tu recompiles les paquets dépendants. Mais au moins, chaque application encore liée à l'ancienne version SONAME de la bibliothèque ne démarrera pas du tout.

    git is great because linus did it, mercurial is better because he didn't

  • # Respect de l'ABI

    Posté par  (site web personnel) . En réponse au journal Google forke C++. Évalué à 5.

    Je comprends pas ce drama autour du respect de l'ABI. Linux est un système où on recompile les logiciels à chaque nouvelle version de la distribution. Linux n'a pas non plus un respect de sa propre API ni ABI (pas pour rien qu'on a mis en place dkms) du coup les modules doivent être recompilés tout le temps aussi.

    D'une manière générale avec la gestion des SONAME on s'en sort bien depuis plusieurs décénnies.

    Si l'argument est « oui mais si je compile mon application propriétaire d'entreprise sur ma Red Hat 6 je veux qu'elle puisse toujours fonctionner sur ma Red Hat 9 » ce à quoi je répondrais déjà non. Si tu prends le temps de migrer ton système vers 3 version majeures de ton OS, alors tu peux prendre le temps de recompiler ton application. Je tourne notre propre dépôt de paquets Alpine Linux et je m'occupe de recompiler nos applications à chaque mise à jour majeure du système. Avec quelques scripts shell maison ma tâche est plutôt simple.

    git is great because linus did it, mercurial is better because he didn't