David Demelier a écrit 754 commentaires

Intéressant, par contre je me demande pourquoi les struct sont précisées par _ en début de nom, c'est moche dans le code utilisateur.

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

Comme je l'ai dit plus haut, c'est un faux problème. Personne n'arrive à faire les choses parfaitement du premier coup. Il faut des essais, et des échecs (les siens ou ceux des autres), pour en tirer des leçons et faire mieux la fois suivante

La solution parfaite n'existe pas. Meson aura des défauts et parmi ceux là j'insiste sur le fait qu'il ne devrait pas avoir à gérer les frameworks lui même.

Sauf quand les projets ont des besoins particuliers. On ne peut pas demander à chaque application de redévelopper tout ce qui était déjà fait et le réinclure. Il faut un endroit centralisé pour cela. Meson montre que comme autotools avec ses macros, il est capable de gérer les spécificités des projets. Dans le cas de GNOME, ça va être de compiler des schémas, des fichiers de ressources, de la documentation, des fichiers d'introspection. Compiler et générer, c'est le job du build system, alors pourquoi pas le centraliser là bas ? C'est un atout pour les projets souhaitant migrer.

Justement CMake possède un système de fonctions puissant, c'est pour ça que Qt5 permet de fournir par Qt directement, un ensemble de macros nécessaire pour créer des projets Qt comme : les traductions et les .ui. Ceci est fourni avec Qt, il serait tout à fait possible de le faire avec n'importe quel autre framework sans même que CMake ait une quelconque information.

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

J'ai suivi meson dès les premiers jours de sa conception, à la création du canal IRC jusqu'à aujourd'hui. Je n'aime pas ce build system.

• Comme souvent dit, c'est un nouveau build system, il y en a déjà trop (CMake, Scons, autotools, waf, gyp, premake). Ajouter un nouveau complexifie encore plus la construction des paquets. Avoir un nouveau système dit support des IDEs à attendre. Il a fallu attendre un moment avant d'avoir une intégrité complète de CMake dans Qt Creator, KDevelop, NetBeans et VS. Cela ne pourrait qu'empirer avec un nouveau système.
• Meson importe lui même les modules du monde entier (dans sa façon de voir les choses). C'est pour ça que vous avez un module Qt, GNOME, RPM, … à mon sens ce n'est pas au build système de s'intégrer avec tous les frameworks de la terre entière. Par exemple, il n'y a pas ce problème avec pkg-config, ce sont bien les développeur qui installent eux même leur .pc (ou au pire la distribution). C'est vrai que CMake a aussi encore plein de modules maison, mais la recommendation actuelle est de fournir un fichier d'export dans la bibliothèque, de la même manière que les .pc.
• CMake est très clairement le build system le plus avancé en matière de C et C++. Je l'utilise depuis 10 ans maintenant. J'ai des choses à lui reprocher mais pas tant que ça et lorsque je trouve des choses à améliorer j'envoie des correctifs.

Ceci dit, je trouve qu'un beau Makefile peut aussi parfois suffire lorsque le logiciel en question est largement portable. Je regrette juste qu'il n'y ai pas une syntaxe de Makefile puissante et standardisée.

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

Haiku a été créé en 2001. Quand tu parles du long terme, ça se positionne comment par rapport à GNU Hurd ?

Je pense que Haiku doit commencer à pouvoir s'utiliser en desktop avec du matériel pas trop exotique. Mais comme il n'y a pas de drivers bluetooth je dois dire adieu à mes souris et enceintes pour le moment /o\

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

Vu que tu es utilisateur de FreeBSD (ou, du moins, tu as été), je me demande si le bloat que tu ressens dans l'écosystème Linux se retrouve aussi dans FreeBSD au fil des versions ?

Je n'utilise plus FreeBSD sur mes portables principalement par compatibilité matérielle, je continue sur mes dédiés. J'aime énormément FreeBSD et OpenBSD. les BSD ont effectivement une vision plus simplissime de ce qu'ils écrivent (surtout chez OpenBSD). Exemple simple, j'apprécie pouvoir rajouter des périphériques bluetooth sur FreeBSD sans avoir besoin de D-Bus mais ça ne veut pas dire que tout est parfait, FreeBSD par exemple possède 3 firewalls dans son arborescence, je trouve que c'est un choix particulier. Cela dit grâce au fichier src.conf tu peux recompiler ton kernel+userland pour désactiver tout ce qui ne t'intéresse pas.

C'est assez difficile de comparer, car en tant que tel on peut faire aussi quelque chose de très léger et simple avec Linux. Il y a d'ailleurs la distribution Alpine dont je suis fortement intéressé pour une éventuelle migration. Elle se base sur Linux, musl et busybox ce qui fait quelque chose de très simple.

Si je le dis autrement : même la famille des BSD ne t'enlèves pas l'envie de réécrire un OS ?!

Non, j'aime beaucoup les BSD. Je n'ai pas grand chose à reprocher d'ailleurs. J'aimerais bien avoir OpenBSD sur mon X1 mais il y a trop de choses qui seraient compliquée pour mon utilisation personnelle (développement Android, pas de bluetooth).

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

Alors ça fait un moment qu'il est débranché, il tournait sur dwm donc ça utilise très peu de ressources. Mais avant j'étais encore sur GNOME 2 et c'était plutôt fluide. C'est une très vieille version de firefox qui est dessus donc je pense que ça doit tourner pour la plupart des sites peu gourmands (à mon avis tu oublies slack et autres).

FreeBSD est effectivement plus léger en terme de ressources mais c'est assez négligeable.

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

Oui haiku ça fait un moment que je suis, j'ai hâte de voir ce que ça va donner sur le long terme.

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

Je suis globalement d'accord avec ce qui est dit. Et je m'en rends de plus en plus compte. J'ai encore un PC avec un Pentium 4, FreeBSD 8 et seulement 512Mo de RAM et je peux m'en servir correctement.

Dans mon ancien travail, j'avais un Thinkpad X1 carbon 5 avec 8Go de RAM et pourtant combien de fois le kernel m'a tué des processus parce que j'utilisais Atom/Node/Slack/Firefox ? Je ne préfère pas compter (l'entreprise en question développe du nodejs).

Ma haine envers electron est sans fin. Je ne parviens pas à comprendre que des gens se disent et si je codais un terminal en electron ?. C'est à dire charger un environnement web complet pour un shell.

Je pourrais dire de même de la communauté npm qui ne peut s'empêcher de créer des modules pour les gens qui ne savent plus coder résultat : à chaque installation d'un quelconque paquet on télécharge la terre entière.

Pour finir, moi qui ai commencé à utiliser Linux en 2003 (avec Mandrake 9.2 et 10 avec KDE 3) je peux dire que la qualité n'est plus au rendez-vous. Maintenant il y a pas un jour sans qu'evolution se mette en erreur de synchronisation; de bugs en tout genre avec GNOME Calendar; de bugs surprenants dans GNOME Shell.

C'est bien dommage, j'ai l'impression que dorénavant on oublie la qualité. Tout est over-engineered, Red Hat ne fait que rajouter des nouvelles couches au dessus du noyau Linux rendant le système surchargé de services. Avec flatpak, ce sera pire. Et je sens que dans quelques années on finira par lancer toutes nos applications dans des dockers. Parfois j'ai envie de réécrire un OS simple basé sur la vraie philosophie UNIX ou tout serait fichier et non pas un service D-Bus (hostnamed pour exposer un hostname sur D-Bus, tu rigoles ? et non).

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

Je suis entièrement d'accord et plussoie complètement. Je chiffre tous mes portables. En revanche, j'avoue que même chez moi je laisse parfois mon ordinateur portable en veille en partant et même si GNOME verrouille ma session on perd quand même l'utilité du chiffrement. Donc ne pas oublier d'éteindre complètement avant de partir :)

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

maintenant j'habite en province et je pars au boulot en laissant la porte de chez moi ouverte :D.

Il y en a aussi hors Paris et parfois c'est plus violent. Dans les journaux j'ai déjà vu des cambriolages à mains armées. Ma marraine s'est aussi faite cambrioler dans une petite ville et les cambrioleurs ont même pris soin de … laisser une délicate attention fécale personnelle dans son jardin.

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

Ralentir la fréquence CPU pour Firefox/Chrome, mettre de fausses valeurs dans le gestionnaire de tâches pour finalement dire à l'utilisateur « Firefox consomme beaucoup et ralentit votre PC, souhaitez vous essayer Microsoft Edge plutôt ? »

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

Je pense que /e/ est un très mauvais choix de nom. Je pense surtout aux futures recherches "e OS", "e android" ou autres joyeusetés.

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

Perso ça fait un moment que je l'ai enlevé chez moi.

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

Tout à fait, quand je pense que tous les mois je reçois mon mot de passe en clair des abonnements mailman, pourtant personne s'en plaint !

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

Non Wt ne s'utilise qu'en C++ pur, il faut écrire du code C++ pour générer des interfaces. Ce que je n'aime pas trop avec ces frameworks c'est l'inclusion de code javascript maison automatiquement sans aucun contrôle dessus dans les pages générées.

J'ai testé plusieurs frameworks web en C++ dont Wt, cppcms qui est plutôt bon mais je n'ai pas trop aimé son système de templates.

Et comme Boost a rajouté un nouveau module HTTP je me suis dit que j'allais coder mon service de pastebin en C++, je l'ai terminé en environ deux jours. J'ai utilisé mstch pour génerer mes pages web et j'adore.

Seul hic, Beast n'a pas encore de parseur URL mais le développeur principal a dit que c'était prévu.

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

et à tous ceux qui utilisent CMake ou autre bidules pas foutu de gérer proprement la cross-compilation.

Tu es sérieusement entrain de dire que CMake ne gère pas proprement la cross compilation ?

Parce que -pour info-, voici les seules variables minimum à définir juste pour compiler pour android :

cmake .                                   \
    -DCMAKE_SYSTEM_NAME=Android           \
    -DCMAKE_SYSTEM_VERSION=21             \
    -DCMAKE_ANDROID_NDK=/opt/ndk-bundle

Sans compter qu'il y a d'autres exemples encore plus concis

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

Sauf que D est mort né et il sert à rien. Il n'offre rien de nouveau (pattern matching de Rust <3). En plus il a un GC et plusieurs bibliothèques standard car les développeurs ne se sont pas mis d'accord.

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

Tout le monde n'utilise pas Git, ça aurait été un petit plus de rajouter une colonne avec les SCM supportés par ces outils :-)

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

Pouvoir est un grand mot, j'ai juste utilisé Boost.Process pour lancer une commande et vérifier les sorties. Ça ressemble à :

const auto [code, out, err] = exec({ "rule-info", "0" });

BOOST_TEST(!code);
BOOST_TEST(out.size() == 7U);
BOOST_TEST(err.size() == 0U);
BOOST_TEST(out[0]  == "rule:        0");
BOOST_TEST(out[1]  == "servers:     s1 s2 ");
BOOST_TEST(out[2]  == "channels:    c1 c2 ");
BOOST_TEST(out[3]  == "plugins:     p1 p2 ");
BOOST_TEST(out[4]  == "events:      onCommand onMessage ");
BOOST_TEST(out[5]  == "action:      drop");

Où exec() est une fonction qui exécute boost::process::system, lit stdin, stderr et me renvoie un tuple avec le code de retour. C'est pas ce qu'il y a de plus convivial à écrire mais ça reste plutôt simple.

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

Raison pour laquelle Slackware laisse à l'administrateur du système la responsabilité de ces interventions manuelles plutôt qu'à une paire de mainteneurs/empaqueteurs qui n'ont pas forcément le même point de vue sur les différentes options et qui peuvent parfois faire des choix hasardeux.

Pourtant slackware est fournie en format binaire (bien qu'on puisse facilement recompiler les paquets). Donc ça veut dire qu'il y a de toute façon un choix des options quand les paquets sont construits exemples:

• vim avec support python ? avec support ruby ? avec des patches ?
• cmake avec ncurses ? avec qt ?

Autant passer par une distribution construite depuis les sources (comme Gentoo) si l'on souhaite réellement la personnalisation absolue.

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

Personnellement j'utilise Boost pour les tests unitaire et fonctionnels. Dans la plupart des cas j'arrive quasiment à tout faire.

Je sépare toujours mon application (le main en gros) du code avec une bibliothèque, ça me permet de pouvoir tester facilement le code sans recompiler chaque fichier testé.

Ensuite pour les tests fonctionnels, j'utilise Boost.Process pour vérifier que les commandes invoquées répondent bien à ce que j'attends (erreur ou sortie standard correcte). Bon, ça nécessite pas mal de code, il faudrait peut-être que je trouve un moyen simple de faire des tests plus conviviaux.

Mercurial fait un fichier déclaratif ou chaque ligne indentée avec $ signifie une commande à exécuter, j'aime bien ce principe.

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

Ce qui m'a toujours un peu dérouté dans Slackware c'est les catégories des paquets A, AP, X, …

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

Je l'ai déjà entendu par téléphone aussi.

Envoyez un mail à yamaha tiret du 6…

J'ai ri, surtout que je suis en qwerty.

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

C'est ce que je me demandais, quand on parle d'ARM je vois toujours une tonne d'émulation différentes ce qui me laisse penser que ça reste une architecture bien plus complexe.

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

Personnellement ça ne me manque pas trop l'absence de NetworkManager (si ce n'est que l'on pourra pas configurer le réseau depuis GNOME/KDE). Pour rajouter un wifi un simple :

wpa_passphrase ssid pass >> /etc/wpa_supplicant.conf
wpa_cli reconfigure

J'avais même comme ambition de créer un wrapper à dmenu pour faciliter cette tâche.

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