David Demelier a écrit 670 commentaires

Supposons que le programme ait besoin d'ouvrir un fichier data.txt situé dans le même répertoire que l'exécutable. Le plus simple est d'écrire :

Là où est l'exécutable et le répertoire courant sont deux choses différentes.

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

Premièrement, les distributions sont plus forcément basées sur GNU alors le terme GNU/Linux est obsolète depuis pas mal d'années.

Deuxièmement, bien que je sois assez d'accord avec toi ça reste une bonne opportunité pour lancer des applications Linux spécifique sur Windows. Sinon, on arrête aussi le développement de Wine ?

Je développe des applications spécifiques aux unices libres car je pense que POSIX devrait être supporté par tous. Mais j'avoue avoir été content de pouvoir lancer une de nos applications à mon travail car le malheureux logiciel de gestion de notre imprimante RFID ne fonctionne que sous Windows, au moins j'ai eu aucun effort de portabilité à faire.

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

Tout ce que je déteste. Les devs upstream qui tentent d'essayer d'être intelligent selon le système cible en testant des fichiers aléatoires comme /etc/debian_version, uname etc mais qui va foirer dès qu'on quitte les distributions populaires.

De plus, j'aime pas trop lancer un script sans savoir ce qu'il va faire. Va t-il polluer mon ~/. ou au contraire appeler sudo/doas pour installer des paquets à ma place ?

Au bucher tous ces curl | sh (et curl de binaires préconstruits aussi).

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

Surtout que POSIX demande qu'un système conforme ai un compilateur C99 qui a lui aussi 24 ans.

Pour ma part c'est le minimum que je demande, les systèmes qui n'ont pas C99 je ne les accepte pas et c'est tant pis (de plus MSVC supporte plutôt bien C99 maintenant). Ne pas avoir C99 c'est une pelleté de fonctionnalités en moins :

• designated initializers
• snprintf
• long long
• inline
• nombres complexes

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

Parce que ça n'apporte rien à partir du moment où une variable est bien nommée. Si un jour tu écris mapPlayers car ton type de données est une map. Ok. Tu commences à la référencer à plein d'endroits et le jour où tu changes de type tu dois renommer la variable à plein d'endroits. Oui on peut faire un rechercher remplacer mais ça reste une opération inutile d'autant plus que tu introduis des possibles merge-conflicts.

Si je lis une variable delay je me doute que ce sera probablement un nombre. Si je lis clients je me doute que ce sera probablement une collection de clients.

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

Notamment le point 9.4 et 9.5. Les FAM peuvent être risqués mais les union sont particulièrement pratiques, les interdire complètement est un peu rigide.

L'annexe E est extrêmement subjective.

• Une fonction de 500 lignes c'est beaucoup trop et j'en ai rarement vu dans des projets propres.
• E4.5, non, on ne doit pas faire des types maison en _t. C'est réservé par POSIX.
• E4.7, pitié la notation hongroise doit disparaitre.

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

Le rapport avec les logiciels libres ?

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

Je… comprends pas trop l'intérêt. Est-ce qu'un linker a vraiment besoin d'être développé sur un temps complet ? Ça reste un outil assez anecdotique.

Si encore le développeur était entrain de travailler sur un moteur de jeu, un environnement de bureau ou autre, je comprendrais la demande de financement.

Mais bon, c'est à la mode pour les bibliothèques simples.

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

Ce qui me choque le plus c'est sur mobile, la vidéo qui s'ouvre directement sans ton accord et prend 1/3 de l'écran en étant fixé relativement ainsi même en scrollant ça reste toujours en haut de ton écran.

Ensuite, tu as 3 à 4 suggestion d'autres articles entre chaque paragraphe. À quel moment ça devient lisible ?

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

La question, c'est plutôt l'avancement de la transition vers libadwaita qui crée un écosystème particulièrement hétérogène avec les applications Gtk 3/4.

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

Les smart pointers de C++ semblent plus proches de ce dernier cas ?

Je ne peux pas comparer car je connais pas assez Rust.

Les smart pointers permettent surtout :

• std::unique_ptr permet de bien marquer l'ownership d'un pointeur. Cet objet n'est pas copiable mais uniquement déplaçable. De ce fait il est impossible de faire un double-free quand on l'utilise. C'est le smart pointer le plus simple, quand il est détruit il détruit l'objet sous jacent s'il est présent
• std::shared_ptr permet d'avoir une donnée avec un reference-count. Tant qu'un shared_ptr existe et est copié plusieurs fois, le pointeur n'est pas supprimé. C'est le moyen le plus sûr de partager un pointeur à travers plusieurs parties du code. Néanmoins son utilisation doit rester occasionnelle car elle indique souvent un problème de conception.

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

Autrement dit des perfs en moins.

Ça n'a absolument aucun sens ce que tu dis. Dans tous les cas la mémoire que tu as allouée doit être désallouée. Les smart pointeurs permettent simplement de s'affranchir de faire des memory leak parce qu'on a oublié de le faire à un fil d'exécution du code. D'ailleurs un std::unique_ptr compilé avec les optimisations au max génère le même code assembleur.

Les smarts pointers permettent surtout d'éviter ce genre de problèmes avant qu'ils existent.

Foo *instance = get_my_instance_driver();

// Okay...
if (something_has_failed) {
    log("it failed");
    delete instance;
    return false;
}

do_something_that_may_throw_an_exception();
// Oups, si cette fonction a levé une exception j'ai un bon gros leak des familles.

return true;

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

Challenge accepted!

~ $ file /bin/* /usr/bin/* /sbin/* /usr/sbin/* | grep -ic perl
15
~ $ file /bin/* /usr/bin/* /sbin/* /usr/sbin/* | grep -i perl 
/usr/bin/callgrind_annotate:                   Perl script text executable
/usr/bin/callgrind_control:                    Perl script text executable
/usr/bin/cg_annotate:                          Perl script text executable
/usr/bin/cg_diff:                              Perl script text executable
/usr/bin/cloc:                                 Perl script text executable
/usr/bin/ms_print:                             Perl script text executable
/usr/bin/perl:                                 ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
/usr/bin/perl5.34.1:                           ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
/usr/bin/perldoc:                              Perl script text executable
/usr/bin/pod2html:                             Perl script text executable
/usr/bin/pod2man:                              Perl script text executable
/usr/bin/pod2text:                             Perl script text executable
/usr/bin/pod2usage:                            Perl script text executable
/usr/bin/podchecker:                           Perl script text executable
/usr/bin/streamzip:                            Perl script text executable

Par contre tous les pod* ne comptent pas puisqu'ils viennent depuis perl directement. Donc en realité sur ma machine il n'y a que cloc, valgrind et git-send-email qui sont codés en perl visiblement.

~ $ apk info -r perl
perl-5.34.1-r0 is required by:
perl-sub-quote-2.006006-r1
perl-error-0.17029-r1
cloc-1.92-r0
perl-role-tiny-2.002004-r1
perl-regexp-common-2017060201-r2
perl-class-method-modifiers-2.13-r2
perl-algorithm-diff-1.201-r0
git-perl-2.36.1-r0
perl-moo-2.005004-r1
perl-parallel-forkmanager-2.02-r3

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

Ne prenez pas mon titre comme une provocation, c'est une question légitime. Je ne connais pas beaucoup d'outils codés en Perl encore actuellement. Sur ma machine, perl est installé pour cloc et irssi.

Qui utilise encore Perl par choix et pour quoi, quel domaine ?

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

On a l'impression que d'aucuns se sentent insultés parce que l'OS propriétaire qu'ils utilisent n'est pas supporté.

Aucun rapport. Je n'utilise pas Windows et je n'ai pas de Windows chez moi, pour autant j'ai pas envie de limiter mes projets à des OS libres. Si mon projet fonctionne aussi sur Windows c'est tant mieux car ça fait une audience supplémentaire.

Pour ma part, je critique simplement le point que le projet affirme directement « Les OS non libres ne seront pas supportés » et même si je fais que de l'opensource développé sous de l'opensource, je ne veux pas me limiter à ça.

Si on veut pousser le vice encore plus loin on fait une nouvelle version d'une licence pro-opensource qui dit « attention ce logiciel n'a pas le droit de tourner sur un système non libre » ? Ça n'a aucun sens et c'est simplement un doigt levé des opinions imbue de Drew.

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

Quand j'écris un programme, je n'ai aucune envie de m'assurer qu'il puisse être compilé sur un OS privateur.

C'est ton avis mais affirmer noir sur blanc “ne sera pas supporté” pour moi c'est pas juste une non-envie de s'en occuper mais un doigt levé à quiconque le demande ou souhaite fournir le support pour.

Beaucoup de gens ne fournissent pas le support pour X ou Y système parce qu'ils n'ont ni les compétences, ni le matériel pour mais de là fermer la porte immédiatement c'est à mon sens inconcevable pour un langage.

Avant je n'avais pas de mac et pour autant j'ai jamais dit sur un quelconque de mes projets « il ne sera jamais disponible pour macOS ». Un jour une personne m'a aidé à porter mon programme pour et j'étais ravi qu'il ai pu m'aider à le faire.

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

Avec une affirmation aussi - propre à son opinion habituelle -, j'ai du mal à y croire.

“Hare does not, and will not, support any proprietary operating systems.”

Je vois mal des gens faire un portage downstream qui soit pas officialisé.

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

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

Ç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

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

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

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

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

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

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