David Demelier a écrit 670 commentaires

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

Pour les 4 derniers points cité dans mon précédent message.

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

Affirmation péremptoire qui ne demande qu'à être explicité, même si le trolldi est passé…

Affirmation de quelqu'un qui a utilisé FreeBSD plusieurs années sur plusieurs laptops différents avec comme constats :

• L'ACPI est toujours aussi mal supporté. Plusieurs fois le status de la batterie ne se faisait plus mettre à jour, aucun moyen de savoir à combien de % je suis sur la batterie.
• Bis, la mise en veille marche une fois sur cinq.
• Après une mise à jour, impossible de refaire fonctionner mon touchpad correctement.
• Autonomie de la batterie largement en deça de Linux.
• Si vous avez besoin de faire quelques trucs autres que la bureautique basique, vous êtes vite coincé. Exemple : le développement Android est très compliqué sous FreeBSD.
• Le support du bluetooth est dérisoire.
• Wayland ? pas encore.
• Carte graphique dernière génération ? Bonne chance, ou utilise -CURRENT.

Note, pour avoir une fois testé OpenBSD, j'ai été surpris car tout l'ACPI fonctionnait correctement. De la mise en veille à l'hibernation. OpenBSD a eu la bonne idée de développeur leur propre pile ACPI, j'espère qu'un jour la fondation FreeBSD sponsorisera la même idée :)

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

La PS Vita aussi :)

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

Les flavors, c'est de lui. Il est juste un peu membre de l'équipe portmgr soit dit en passant ;)

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

Moi sur un serveur dédié depuis plus de 10 ans. J'ai par ailleurs contribué plusieurs ports. En serveur c'est vraiment top (ZFS, jails, système ultra flexible, beauté, simplicité, etc.)

Par contre je déconseille largement en desktop (encore moins en laptop).

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

GitHub n'est pas pauvre. N'oubliez pas qu'il y a aussi des entreprises et particuliers qui payent pour des dépôts privés.

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

C'est pas une philosophie: comme ajouter une dépendance demande un travail long et chiant, on préfère réinventer la roue :-)

Désolé mais je ne vois pas le rapport et je pense que tu n'as pas compris. Dans des projets node.js on utilise npm qui va installer les dépendances externes directement dans le dépôt de l'application alors que la tradition dans les applications C et C++ c'est d'utiliser celles installées par le gestionnaire de paquet de la distribution (donc de les garder externes).

J'ai pourtant bien précisé « qu'on intègre plus rarement une bibliothèque externe directement dans son code ».

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

Aucun n'est véritablement portable, ça n'est pas très amusant d'utiliser docker sous windows et MacOS par exemple. Sur BSD je ne sais même pas comment s'est distribué.

Oui je sais bien, mais tu installes un sur ton serveur qui te plait et tu reste avec :-)

Ah oui, mais le mainteneur a une Debian stable, alors que moi je suis sur Fedora donc on utilise pas les même versions de bibliothèques… Ton logiciel doit passer les versions de bibliothèques en même temps que tu fais tes mises à jours d'OS ?

Dans mon cas, les bibliothèques que j'utilise ne sont pas du genre à casser la compatibilité d'une version mineure à l'autre (c'est d'ailleurs un critère de choix). J'utilise Boost principalement, Qt 5 ou parfois SDL 2. Et SDL 2 je sais que ça va rester pendant encore un moment (combien il y a d'années entre SDL 1 et SDL 2 ? tellement que les distributions fournissent les deux côte à côte) donc pour le moment je ne peux pas dire que j'ai eu des problèmes de compatibilité de version. Mon seul gros problème c'est la version des compilateurs sur les distributions car j'utilise déjà beaucoup de fonctionnalités du C++17 et je sais que ça va être compliqué pour les utilisateurs de debian, mais bon si je dois commencer à me restreindre pour des distributions je ne pourrai jamais coder en C++17. Il faut dire que la philosophie des développeur C ou C++ est largement différente de npm (pour ne citer que celui ci) justement parce que la retro compatibilité est bien plus forte et qu'on intègre plus rarement une bibliothèque externe directement dans son code alors que dans npm on peut se le permettre bien plus.

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

Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes

C'est sûr que la libc change vraiment souvent… Sinon il y a des chroot/mock/containeur pour tester des build dans des environnement propres.

Comment tu fais pour expliquer à tes contributeurs la liste de tes dépendances qu'ils utilise nix, debian, redhat ou gentoo ?

Je leur dis « Boost, CMake, Qt5, libzip » enfin bref, le nom upstream de mon composant, à eux de trouver le nom dans leur gestionnaire de paquet (qui est souvent assez identique).

Comment tu t'assure que tes dépendances ont bien les bonnes options de compilation ?

La plupart des distributions compilent avec les valeur par défaut d'upstream, j'ai jamais eu de souci à ce niveau là. Puis les bibliothèque externes que j'ai utilisées jusque là n'ont pas d'options par défaut que les distibutions changent par ci par là.

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