David Demelier a écrit 658 commentaires

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

Si tu vas par là, est-ce par principe un nouveau langage de programmation n'a pas de très fortes chances d'être inutile?

Non ce n'est pas du tout ce que j'ai dit. Je l'ai dit pour Go et je le pense aussi pour D, ce sont deux langages qui n'apportent rien de nouveau. Go fait le taf mais n'est pas élégant, il a un garbage collector, la gestion des paquets a été un foutoir monumental et le support des generics a mis une décénnie à arriver. Il y a encore d'autres raisons qui font que c'est un langage qui à mon sens inutile.

Je n'aime pas spécialement Rust personnellement, mais je ne peux pas nier qu'il favorise grandement le développement d'applications bas niveau performantes avec la robustesse en plus. Ça c'est un langage nouveau utile.

Après, c'est toujours pareil, qui ne tente rien n'a rien. Mais franchement, si on veut faire quelque chose d'utile pour la communauté, il y a peut-être mieux à faire que de créer un nouveau langage de programmation.

100% d'accord, on pourrait dire la même chose des frameworks Javascript.

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

Désolé pour ce titre trollesque, je n'aime pas ce type beaucoup trop imbu de sa personne (j'ai déjà expliqué maintes fois sur linuxfr).

Un mélange de Go et de Rust, pour moi ça n'apporte rien. Certes Rust est compliqué mais il a des avantages. Go est par contre lui inutile.

Se baser sur qbe c'est chouette, c'est simple, basique, propre mais c'est complètement expérimental. J'ai aucun projet qui compile entièrement (en utilisant cproc) pourtant je fais du C99 et C11 strictement POSIX sans aucune extension GCC. Il y a toujours une erreur quelque part (soit c'est pas supporté soit qbe part dans une boucle infinie).

Drew est quelqu'un d'assez antipathique, il n'y a qu'à le suivre sur les projets auxquels je participe (comme Alpine) ou les siens comme sway, wlroots. Quand il pense avoir raison il le fait savoir. Par conséquent pour le développement d'un langage où il est nécessaire de suivre l'avis des gens, j'ai hâte de savoir comment il va prendre en compte les remarques.

Pour moi c'est rien de plus qu'un énième projet NIH de sa part.

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

On le dit depuis le début, il faut tout externaliser sur des plateformes fermées ! Le cloud saylebien© !

Je vous laisse je dois push sur mon dépôt Mercurial self-hosted avec la même configuration depuis 2009.

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

J'espère que les performances seront enfin là, mais si c'est toujours codé en python probablement pas 🤷🏻‍♂️

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

Oui ? Je fais de la MAO sous Linux depuis 2005, jamais eu le moindre problème…

J'aimerais bien connaitre ton utilisation de la MAO. Parce que la dernière fois que j'ai voulu simplement faire tourner tuxguitar (pulseaudio) et ardour (jack) en même temps j'ai bien cru que j'allais m'arracher les cheveux. Sans compter la quantité massive de crash et erreur ardour.

Pour ce qui est des VSTs, tu es bien vite limité.

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

À côté sous linux tout est bien plus facile et cohérent, de l'installation du système à la prise en main du bureau, de l'installation des logiciels à l'ajout de nouveau périphériques, c'est finger in ze nose comparé à win10.

Oh purée tu m'as fait bien rire.

Je vais pas détailler parce que linkdd l'a déjà bien fait mais je rajoute des éléments.

• Essaye seulement de faire de la MAO sous Linux avec la pile audio cadavérique que nous avons.
• Je suis sous Linux depuis 2003 (mandrake 10), bien que ce soit stable je ne peux qu'admettre qu'il y a rien de cohérent sous Linux. Du bureau aux entrailles. Des services qui ont tous une syntaxe différente (essaye voir de faire du polkit à la main). On a maintenant du XML, du .ini, du maison et d'autres encore. Pour l'utilisation en CLI c'est pareil : bluetoothctl, nmcli, iwd, systemctl. Ça en revanche c'est bien quelque chose qu'OpenBSD a fait de cohérent.
• L'installateur anaconda mériterait sa place en enfer.
• GNOME et prise en main dans la même phrase ? J'adorerais voir un utilisateur Windows lambda passer à GNOME sans aucune aide. N'hésitez pas à faire l'expérience si vous le pouvez. Pour KDE, c'est peut-être plus facile mais c'est très riche.

Concernant Windows 11, j'avoue que plus en avance dans ses versions plus c'est incohérent (surtout graphiquement) mais ça juste marche©. À ce jour j'aurais tendance à dire “all OSes suck”. Rien est parfait mais dire que Linux est cohérent et facile c'est de la pure mauvaise foi ou un total manque de connaissance.

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

On parle de remplacer printf par puts quand il s'agit d'une chaine littérale, rien à voir avec gettext puisque c'est complètement déterminé à l'exécution.

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

Oui c'est même pour ça que lors d'un hackaton FreeBSD (si je me trompe pas) les développeurs en ont fait une petite blague.

Tout ça pour rajouter des standard --help et copyright.

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

Sauf que personne utilise c99 de POSIX. Une bonne partie des développeurs sensés activent tôt ou tard les warnings (options -W de gcc/clang) qui n'est évidemment pas couvert par POSIX et donc ton utilisation non portable. De plus, POSIX demande un compilateur C99, aujourd'hui on est bientôt à C23, ce serait dommage de rester sur des anciennes versions juste pour être 100% POSIX compliant.

Évidemment, loin de moi l'idée de dénigrer POSIX je suis moi même développeur C et embarqué privilégiant des APIs POSIX pour rester portable, mais je considère pas POSIX comme la bible non plus (POSIX make par exemple, c'est bien pour un projet à 2-3 fichiers, mais ça devient vite casse gueule sur des projets plus riches).

Pour résumer, je pense que ton argument n'est pas valable. POSIX stipule l'option -o de disponible donc quiconque voulait un nom de fichier prédictif devrait l'utiliser de toute manière.

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

J'oublie toujours à quel point on est réfractaire au changement. Surtout quand c'est aussi trivial que ça.

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

cl.exe utilise le nom du fichier, main.c devient main.exe. Donc dans notre cas main.

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

Moi j'ai aussi hâte que les compilateurs C arrêtent de créer un exécutable a.out par défaut. Surtout quand celui ci est un ELF.

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