David Demelier a écrit 752 commentaires

Et surtout que si c'est une fonction locale à un fichier (donc static ou namespace anonyme) le compilateur met un warning si bien configuré

C:/w/src/sigi/firmware/bootloader/main.c:46:13: warning: 'flash' defined but not used [-Wunused-function]
   46 | static void flash(const void *firmware, uint32_t firmware_len) {

Pour moi c'est le moyen correct de vérifier qu'une fonction est utilisée ou non plutôt que raboter au hasard.

Autrement, le linker fait les choses bien à ne pas inclure les symbols inutilisés dès lors qu'ils sont pas tous dans le même fichier.

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

Imaginez une API qui permet de sérialiser des données binaires en fonction du type en entrée :

#include <iostream>
#include <cstdint>

void pack(uint8_t x)  { puts("uint8_t");  }
void pack(uint16_t x) { puts("uint16_t"); }
void pack(uint32_t x) { puts("uint32_t"); }
void pack(uint64_t x) { puts("uint64_t"); }
void pack(int8_t x)   { puts("int8_t");   }
void pack(int16_t x)  { puts("int16_t");  }
void pack(int32_t x)  { puts("int32_t");  }
void pack(int64_t x)  { puts("int64_t");  }
void pack(float x)    { puts("float");    }

int main() {
    pack(1);
    return 0;
}

Résultat possible :

$ ./a.out
int32_t

Du coup, si on veut sérialiser des entiers spécifiques à la suite on doit forcer un cast.

pack(static_cast<uint8_t>(10));
pack(static_cast<uint16_t>(1664));

Perso je vote pour des spécialisations de template ou des noms explicites (comme packu64 mais moins C++/template/metaprogramming friendly)

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

rit en tendinite

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

Si tu vraiment besoin de fichier temporaire utilise mktemp qui est sécurisé.

Clairement pas, c'est le meilleur moyen de faire un TOCTOU. En plus la fonction a été retiré de POSIX.

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

Microsoft est un membre platinium.

En plus de ça, même des entreprises comme Microsoft ont l'autorisation de modifier le noyau Linux, et leur modifications semblent souvent acceptées.

Et ? Parce que c'est Microsoft c'est grave ? En quoi es-tu directement impliqué que Microsoft injecte de l'argent ?

L'argent de la fondation Linux ne donne pas de pouvoirs à Microsoft, ce n'est pas parce qu'il y a de l'argent d'une entreprise x ou y qu'on ajoute des fonctionnalités aléatoires. Les modifications sont acceptées de la même manière qu'une autre entité.

J'avais aussi lu sur internet que même FreeBSD était, et est peut-être encore, financé partiellement par Microsoft.

Heureusement, moi je donne quelques euros à OpenBSD de temps à autre, ils n'ont pas autant d'argent et ont souvent eu du mal à suivre leur infrastructure. N'hésite pas à donner si tu veux que Linux, FreeBSD et autres unices libres puissent vivre davantage sans « grand méchants investisseurs ».

Des efforts semblent aussi réalisés pour se débarrasser du compilateur C de GNU: gcc, des gens, des entreprises, ou peut-être des gros actionnaires, semblent vouloir le remplacer par clang.

Il y a des vraies raisons de vouloir se débarrasser de GNU et ça n'a rien de forcément politique. La GPLv3 est ultra contraignante pour les systèmes qui n'utilisent pas une licence GPLv3 par défaut. Certaines personnes aiment les licences les plus permissives pour n'avoir aucune question à se poser. Même quand on fait un logiciel opensource dès que la GPLv3 entre dans la discussion ça crée de la confusion. On aime ou pas la GPLv3 on ne peut nier les inconvénients qu'elle ramène. Si GCC était sous MIT/ISC il est peu probable que les *BSD aient mis autant d'effort à passer à LLVM/Clang.

Le langage Rust prend lui aussi de plus en plus de place dans les programmes comme Firefox et même dans le noyau Linux d'après ce que j'avais lu sur internet. Je me demande qui est derrière le langage Rust ? Est-ce encore des multinationales ?

Il y a beaucoup de « jéluke », renseigne toi sur un sujet avant d'émettre des hypothèses infondées.

Bref ton post est rempli d'inepties et avide de connaissances.

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

Je comprends pas comment les gens peuvent perdre autant de temps sur des conneries. En quoi Godot favorise une culture plus qu'une autre ? C'est un moteur de jeu, pas un parti politique. Tu peux faire un jeu inclusif ou « woke » avec SDL, Irrlicht, Unreal, Unity ou un jeu complètement à l'opposé avec ces mêmes moteurs. Octopath Traveler 2 a beaucoup de références religieuse extrêmement explicites et même en tant qu'athée je ne crie pas au scandale.

Les gens qui se plaignent et mettent des avis négatifs sur ce genre de jeux ne sont même pas concernés par la mise en valeur de l'aspect progressiste de ces titres sans s'être aperçu que cela n'a rien de nouveau. Tomb Raider et Metroid ont un personnage principal féminin et ils ne datent pas d'hier.

Il n'y a aucune polémique Godot, il a une seule polémique et ce sont les hydrocéphales qui la créent.

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

J'ai un synology avec deux WD Red à l'intérieur. Des disques dur « spécifique NAS » et putain qu'ils sont bruyants. La première fois que j'ai copié tout mon contenu dessus on aurait cru qu'il y avait une dizaines de choses en vibrations sur le meuble. Et puis j'ai fini par m'y habituer, de toute façon une grande partie du temps les disques ne font rien et sont mis en veille par le firmware synology.

Tu peux voir ça aussi pour forcer la mise en veille des disques après une période d'inactivité. Ça fait un moment que j'ai plus fait ça manuellement mais ça se fait bien.

Une petite mousse sous le chassis peut atténuer mais attention à ce qu'elle ne soit pas conductrice et bien isolée. Maintenant j'ai aussi forcé l'arrêt de mon synology la nuit car la nuit… je dors :)

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

Au moins nous auronss des robots pour nous essuyer le cul et nous servir à boire quand nous serons enfermés sous 34° fin janvier.

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

Le problème c'est que le choix de ne pas avoir le Bureau remplit d’icônes, je considère qu'il appartient à l'utilisateur, pas au chef de projet qui développe l'interface graphique.

C'est pas au chef de projet GNOME de décider ce qu'il doit y avoir ou non sur le Bureau des utilisateurs. Si le chef de projet n'aime pas les icônes sur le Bureau, alors libre à lui de ne pas en mettre sur son Bureau à lui, mais pourquoi interdire à tous les utilisateurs GNOME de le faire ?

Mais c'est pas juste un choix, GNOME utilisait nautilus (comme explorer.exe) pour afficher les icones sur le bureau et franchement rien que le concept est tordu. Alors oui ça permet de réutiliser du code car l'alignement, l'affichage et les boutons de context sont les mêmes mais ça n'a pas spécialement de sens et ça créé une dépendance.

GNOME a sa vision des choses et ça plait ou ça déplait c'est comme ça. Mais c'est pas non plus parce que c'est un logiciel libre qu'ils doivent céder à tous les caprices. Sur windows et macOS on peut quasiment rien changer des composants du bureau et personne s'en plaint. De plus, le système d'extension de GNOME est quand même assez puissant, rien que just perfection permet beaucoup de folies.

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

Utilisateur aguéri de FreeBSD, j'ai testé dès FreeBSD 7.0. Au début ça marchait « plutôt bien ». Malgré les problèmes usuels (sur un HP à cette époque) :

• touchpad fonctionnel mais sans défilement
• luminosité non réglable via les touches
• mise en veille hasardeuse
• prise jack non fonctionnelle par défaut (mais avec quelques configuration snd_hda oui)

Puis à chaque mise à jour, un nouveau problème. Le wifi ne fonctionne plus, puis le touchpad, puis X.Org, puis le son, puis la batterie n'affiche plus son état.

FreeBSD c'est bien sur les serveurs :)

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

À trouver des imprimantes sur le réseau, ce qui est en parti déjà fait avec Avahi (plus généraliste).

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

Bien sur que SMTP est pourri. Il est fondamentalement mal conçu parce qu'il est aussi vieux qu'internet. Ce n'est pas pour rien qu'il y a autant de problèmes inhérent au service mail.

• spoofing
• spam
• open relay
• non répudiation
• chiffrement
• mitm
• multipart
• format

Ce qui implique que toutes les briques se sont posées par dessus pour pallier tous les problèmes. TLS, IMAP, POP, DMARC, DKIM, sieve, etc.

En plus tu rajoutes à ça le manque de format et tu as des mails avec des signatures de 1km en HTML parce que les gens répondent n'importe comment. Le mail tel quel ne disparaitra jamais mais c'est bien quelque chose dont je rêve

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

De toute les installation d'infrastructure que j'ai pu faire, le mail est clairement la plus horripilante. Au départ je faisais postfix, dovecot, dspam et déjà là c'était vraiment compliqué. J'ai fini par mettre opensmtpd, dovecot et rspamd et je trouve ça déjà plus simple mais faut l'avouer le mail est un des protocol les plus pourri qui soit.

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

Je valide 💯.

Plus sérieusement, je regarde plus la météo. À chaque fois il se passe l'opposé. Je vois plein soleil sur meteofrance/google/etc et je regarde par la fenêtre : méga déluge.

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

J'étais fan de KDE 3.5, époque mandrake 10 et cie. Ça remonte c'est vrai. Après je suis passé à fedora et je suis tombé dingue de GNOME 2.8. Depuis je suis presque plus que sous GNOME avec un petit passage sous dwm.

Au début j'aimais les tiling WM parce que c'est pratique en mono écran pour dev. Puis le mode de vie change surtout au niveau des laptops. On se déplace, on se branche sur des écrans externes, puis on a du hidpi puis un écran hidpi externe et un écran interne pas hidpi. Galère. Au final je suis retourné sous GNOME. J'aimais vraiment pas les premières versions de GNOME 3 mais les versions actuelles me conviennent. Avec quelques extensions (caffeine, just-perfection) au final on personnalise quand même assez. Pour ce qui est du multi écran franchement ça marche bien. Que je sois docké ou en clamshell GNOME fait tout presque parfaitement avec mon thinkpad. Aujourd'hui j'ai plus la motivation de m'embêter avec sway et autres à tout configurer à chaque profil de branchement externe.

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

Bon, il y a beaucoup de commentaires déjà mais je pose mon expérience si jamais tu prends le temps de tout lire. J'essaye de faire court :

Les ESN. Moi je n'y arrive pas. C'est toujours le même principe, on te vend des merveilles et on te dit « on est pas comme les autres » mais en fait si. Quand tu demande un salaire on te dit c'est ok puis quand tu arrives au contrat il y a 3000€ de moins parce que « le package » avec les tickets restaurant, le transport et les primes ça monte bien au total demandé. En plus j'ai découvert un nouveau phénomène. Les indemnité journalières. Maintenant les ESN proposent un salaire de base bas et pour chaque jour travaillé te donne encore une somme. Ainsi tant que tu travailles tu es plutôt bien payé puis le mois où tu prends 3 semaines de vacances tu te retrouves avec 600€ de moins. Ah et puis le côté « on a une grille de notation pour les augmentations » qui prend en compte le fait que tu viennes aux afterwork plutôt que tes capacités techniques, j'ai du mal. Mis à part ça, quand tu es chez un client tu ressens très bien que tu es externe. Entre les tarifs plus cher en cantine, les remarques à la con (je cite « tu nous coute cher ») et la pression des collègues, moi j'aime vraiment pas. Pour me sentir bien au travail j'ai besoin d'une cohésion d'équipe.

Les startups. J'en ai faite qu'une et c'était un cauchemar. Locaux terribles, des dossiers à remplir pour certifier le temps passé en développement histoire d'obtenir des subventions. Les gens bruyants et complètement immatures avec aucun avantage (ni CE, ni prime, ni intéressement). Plus jamais.

Les grosses boites. J'en ai pas fait beaucoup mais tout est procédure. Le moindre développement se caractérise par des réunions, des process, des documents à remplir avec des tableaux excel fait maison et des macros à la con pour remplir des champs. Sérieux, quelle perte de temps. Avec malchance tu tombe aussi sur des vieilles techno de type TFS, SVN ou des environnements désuets avec des façon de coder des gens qui sont aussi agés que la boite et n'ont pas évolué. Quand on est technophile et passionné comme moi, dur.

Pour conclure, rien est parfait et j'aime de moins en moins mon métier parce que je suis beaucoup trop exigeant envers moi même et les autres. Quand on cherche pas à faire autant dans la rigueur que moi ça m'énerve parce que pour moi c'est un métier de passion où on devrait être « fier » de voir et faire du beau code. Ça me rend triste de voir mes autres collègues aussi peu passionnés et s'amuser de voir que je code dans mon temps libre comme si j'étais un extraterrestre.

En tout cas je t'invite à bien réflechir à ce qui te plait et t'anime car en fonction du type d'entreprise c'est pas du tout la même façon de penser. Le modèle startup est probablement celui qui est le plus proche de mes envies car souvent démarré par des passionnés, motivés et aimant les nouvelles technos. Je suis juste déçu d'avoir pu tomber dans une toxique.

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

J'ai de la chance ni mon nom ni mon prénom n'a d'accent, par contre mon nom de rue où j'habite et mon ancienne compagne en ont.

Par exemple mon nom de rue est « rue de Sélestat ». J'ai malheureusement déjà reçu des enveloppes avec écrit, le grand classique :

rue de Sélestat

Du coup je ne m'emmerde plus, je marque Selestat. Pareil pour le prénom de mon ex compagne qui s'est retrouvé malmené sur des étiquettes liés à des activités quelconques (jeux, sorties, billets). On les enlève systématiquement.

Je te rejoins, en 2024 et dans un pays où la langue officielle est composée d'accent c'est triste de devoir se contenter de l'ASCII.

Pour un prénom comme Cédric qui passe en Cedric ça va encore car on a la prononciation de base naturelle qu'on connait par habitude juste au visuel. Mais avec des cédilles comme Francois au lieu de François me perturbe plus.

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

Non je ne pense pas que ce soit un troll, la question du NULL est légitime si on a pas la notion entre les deux. Dans les dernières versions de C++ il y a tellement de fonctionnalités qu'il est légitime de se poser ce genre de question pour un néophyte.

NULL va rester car le supprimer maintenant détruirait une grosse partie des projets C++, mais je le vois bien à terme être déclaré comme obsolète (et éventuellement supprimé à très long terme).

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

Merci ça me rassure, j'ai relu deux fois sans comprendre.

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

et les plus jeunes ne jureront que par le "noCode"

s/noCode/ChatGPT

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

De plus, je trouve les programmes en C++ beaucoup moins lisibles que ceux écrit en C. Il y a aussi le "nullptr" dont je ne vois pas l'intérêt, le "NULL" me paraît plus rapide à écrire et plus lisible car écrit en majuscules.

NULL est problématique parce que c'était 0 en C++ et un cast de void * de 0 en C. Rien que pour ça il y a problème de compatibilité.

En étant 0, il y a ambiguité dès lors qu'on a deux fonctions surchargées qui peuvent prendre soit un int soit un pointeur quelconque. Le mot clé nullptr est spécifiquement là pour les pointeurs. En plus, en C23 il y a aussi nullptr :).

Certains diront: l'avantage est la programmation objet. Mais avec l'option de GCC "-fms-extensions", on peut imbriquer les structures de la sorte:

La programmation orientée objet n'est pas la réponse à tout. Quand je vois certains projets avec 7 niveaux de hierarchie avec des fonctions virtuelles/abstraites de tous les côtés je suis bien content de pas y mettre les pieds. Comme disait Carmack, parfois la meilleure implémentation n'est qu'une fonction. En C on peut faire un peu d'orienté objet avec des pointeurs de fonction, c'est la méthode la plus courante pour implémenter des choses abstraites. Un système de fichier virtuel est clairement un des exemples les plus concret

struct vio {
    int (*open)(const char *name);
    int (*close)(int fd);
};

// plus tard dans le code
int fd = my_zfs_vio->open("foo.txt");
mu_vfs_vio->close(fd);

Donc je ne vois pas quels sont les avantages du C++ sur le C ?

Il y en a, heureusement sinon personne ne l'utiliserait. Je vais faire court.

• les namespaces : qui aime vraiment écrire gtk_tree_widget_my_super_fonction ? qui aime avoir un conflit de noms parce qu'une autre bibliothèque a un nom identique ?
• les templates : bien utilisé ils permettent de réutiliser du code sans avoir à passer par des macros dégueulasses. les devs C qui utilisent les listes chainées connaissent bien ce problème.
• la bibliothèque standard : en C, soit on réinvente la roue tout le temps soit on doit forcer / utiliser une bibliothèque externe. Quand on design un framework plus haut niveau cela peut être particulièrement chiant. Si Gtk a besoin de tableau dynamique, de listes ou autres ils vont devoir choisir une bibliothèque ou recoder les fonctions et les imposer à l'utilisateur. Ainsi on se retrouve avec une quantité astronomique de code qui fait la même chose.
• les fonctionnalités avancées : les initializer_list font parti des fonctionnalités les plus agréables. pouvoir créer un objet json comme ceci est vraiment cool json foo{"bar", baz};.

Bon la liste est longue donc je te laisse faire ton propre avis. Et parce que j'aime beaucoup le C et que je trouve que le C++ devient de plus en plus dégueu au fur et à mesure des nouvelles normes je fais aussi un exemple opposé.

• simplicité : en C on sait presque immédiatement à quoi va ressembler le binaire final et quand on fait de l'embarqué voir les symbols qui seront placés en RAM ou en flash c'est le pied. On a un controle absolu.
• simplicité 2 : implémenter un compilateur C est presque un jeu d'enfant, pour cibler une nouvelle plateforme il y a peu d'effort à faire.
• temps de compilation : il y a pas photo
• pas de boite noire : quand on instancie simplement std::string x on a aucune idée de ce qu'il risque de se passer sur l'allocation mémoire, en C on a quasiment aucune surprise.
• rigueur : les gens qui dev en C ont souvent plus de rigueur car c'est plus facile de se planter, à l'inverse à chaque fois que je vois un projet en C++ je peux voir un mélange de vieilleries et de nouveauté et ça donne pas toujours envie notamment ceux qui sont coincés en c++98 par choix.

Note, je suis dans le développement embarqué donc mon avis est un peu biaisé bien que j'ai passé une grande partie de ma vie à développer des applications en C++.

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

Les paquets upstream ne devraient pas contenir du code de distributions. Non seulement ça bride les mainteneurs car si les développeurs décident de changer leur fichier, syntaxe ou autre nommage qui leur est propre ils seront coincés jusqu'à une nouvelle version du noyau.

C'est rare que les packagers utilisent les fichiers debian/.spec et autres choses auto générées via CPack (par exemple) directement depuis les logiciels upstream. Non seulement on peut apporter des petites modifications locales pour telle ou telle distribution mais les développeurs eux même ne connaissent pas toutes les spécificités.

En bref, ça prend du temps, des ressources et des erreurs possibles en plus. Les développeurs upstream devraient laisser le packaging aux packagers. D'autant plus qu'il existe des dizaines de gestionnaires de paquets.

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

Comme beaucoup de projets existants, parce qu'il est écrit en C il a fallu qu'on trouve une raison pour le réécrire en Rust !

2:13 : tired of crash reports (il parle de geoclue).

Jamais eu aucun problème ni avec geoclue ni avec dbus. Comme à chaque fois avec Linux quand quelque chose fonctionne on le réécrit.

OSS -> Alsa / Arts / ESD
Alsa -> PulseAudio
PulseAudio -> PipeWire

Maintenant D-Bus -> busd. Hâte de voir ce que ça va donner.

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

https://sourceware.org/bugzilla/show_bug.cgi?id=12701

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

J'ai utilisé SuSE quelques temps après avoir découvert Linux sous Mandrake 10. À l'époque YAST (propriétaire en cette période IIRC) était la principale raison d'utiliser SuSE. Depuis, j'ai l'impression que cette distribution est en état de mort cérébrale.

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