David Demelier a écrit 670 commentaires

[à 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

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

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

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

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

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

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

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.

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

Ç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

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

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

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

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

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

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

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

Moi j'adore le markdown, c'est vrai que c'est limité mais il y a souvent des extensions bien répandues. Par exemple avec mkdocs et le super thème material, on peut avoir des “admonitions” qui sont top.

!!! note
    Ceci est une petite note

Markdown ftw.

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

Pour moi déjà quand tu en arrives à devoir écrire un article pour justifier une technologie, c'est que la dite techno est mourante.

Bien évidemment tout est subjectif mais pour moi Perl est le langage dont la syntaxe est la plus horrible avec des mots clés de une à deux lettres q, qq, qx, qw, etc.

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

Microsoft, au moins jusqu'à Windows 10, mais probablement pareil pour le 11, ne fournit pas d'ISO hybride. C'est une ISO de CD à graver absolument sur DVD ou BD, ce n'est pas une table de partitions valide pour une clé USB.

Si.

J'ai réinstallé Windows 11 sur mon ordi du travail suite à un changement de SSD et j'ai aussi une fois fait temporairement un dual boot sur mon thinkpad (Windows 10) et j'ai aucun lecteur CD. Et évidemment je l'ai fait avec un simple dd.

D'ailleurs c'est écrit sur la page officielle que tu peux l'utiliser sur une clé USB.

L’image peut également être utilisée pour créer un support d’installation à l’aide d’une clé USB ou d’un DVD.

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

C'est compliqué ? Alors qu'il y a tous les autres systèmes d'exploitation et autres environnement de bureaux qui ont réussi à le faire ?

On parle d'afficher simplement des aperçus.

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

Malheureusement ce n'est pas déconnant pour des produits nouveaux pas industrialisés en masse. Dans mon entreprise, on attend des compute module 4 depuis maintenant 1 an (et ça c'est produit en masse).

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

Les gestuelle et son utilisation de l'espace sont bien conçu, c'est fluide. Manque plus que des tablettes et téléphone de qualité et on aura un vrai écosystème libre.

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

Il y a beaucoup d'applications qui sont réecrites de manières encore plus simple et avec aucune fonctionnalité :

• terminal -> console : vraiment une blague ce dernier ([troll]un jour on aura plus aucune option[/troll]).
• gedit -> texteditor : pas encore testé mais plus simple.
• gucharmap -> characters : l'interface est clairement revue et restylée.

Il faut savoir que beaucoup d'applications sont réecrites pour passer à libadwaita ce qui unifie le style. Malheureusement avec GNOME 42 il y a encore un mélange GTK brut et libadwaita ce qui fait que le bureau est totalement hétérogène, c'est dommage. Gucharmap ne respecte clairement pas les normes HIG récentes de GNOME : il y a encore une barre de menu, des boutons texte + icône, etc. Sans doute que Characters va le remplacer à termes.

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

Ce qui est fatigant c'est le nombre de développeurs qui ne comprennent pas le principe des licences. Combien de fois j'ai déjà entendu encore à l'école ou dans mes anciennes entreprises « c'est gratuit on peut l'utiliser ».

Les développeurs nouvelles générations sont mal formés. Parce qu'ils croient que c'est sur GitHub on peut faire tout et n'importe quoi.

J'aime pas la GPL personnellement, mais j'aime voir les entreprises privatrices se faire emmerder quand ils respectent pas le principe des licences.

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