David Demelier a écrit 670 commentaires

Au début, je me disais que c'était une arnaque au numéro surtaxé, si on rappelle, on paie un max.

Ça dépend du numéro, s'il ne commence pas par >= 081, ils ne le sont pas. Par exemple, j'ai eu plusieurs appels de 01 xx xx xx xx. Qui raccrochaient immédiatement. Par curiosité j'ai rappelé et on tombe directement sur un répondeur arnarque peu crédible qui vous dit « bonjour, je suis votre conseillère, merci de me rappeler au 08 99 xx xx xx ». Sachant que le 08 99 est le plus cher. Mais bien sûr.

Tant qu'il n'y a pas d'indicatif, ni de 08 vous pouvez rappeler sans trop de risques.

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

Le optional (si tu essaies de réimplémenter std::optional) ça se fait avec les placement new. Faire ça avec du memcpy c'est scandaleux.

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

Toi tu n'as pas encore cherché "is-array" sur npm alors :)

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

Euh… Le libre n'interdit pas de tuer, ca n'autorise pas à tuer! Cette mention explicite est pour des bugs non voulu (si ca tue sans faire exprès), pas pour des actes volontaires, sortir cet argument est d'une sacrée mauvaise foi…

Entièrement d'accord. C'est trop facile de toujours tout mettre sur le dos de l'opensource.

D'ailleurs dans l'issue github quelqu'un a posté cet article :

https://hueniverse.com/how-to-use-open-source-and-shut-the-fuck-up-at-the-same-time-d933471d59de

Ce genre de personnes ne devraient pas affirmer faire de l'opensource. J'ai l'impression qu'on voit pas tous l'opensource de la même manière. Il y a « mon projet est opensource parce que je veux bien, mais tant pis si tu n'arrives pas à t'en servir, je l'ai fait pour moi » et « c'est opensource parce que je souhaite fournir quelque chose de propre, sûr et alternatif au propriétaire et que le développement est ma passion ». Je suis bien content de faire parti de la deuxième catégorie.

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

http://openbsd.org

Plus sérieusement, je pense qu'il y a un gros décalage. Certains oublient que les logiciels libres sont en GRANDE parti développés sur le temps libres des gens. Alors que votre suite office préférée est développée par des employés et des graphistes. Donc souvent ça fait la différence.

Cela dit, il y a beaucoup d'exceptions. GNOME, c'est propre, c'est assez professionnel dans l'ensemble. Il y aussi des jeux libres de qualité (wesnoth).

Mais de là faire l'amalgame systématique a tendance à m'agacer. D'ailleurs on donne assez souvent comme excuse « c'est opensource » comme si c'était suffisant pour compenser la « mocheté » de certains projets.

Par ailleurs, j'ai une fois demandé la documentation (inexistante) d'une bibliothèque opensource dont je ne dirais pas le nom. Le développeur m'a répondu « c'est un projet opensource, c'est pas comme si vous aviez dépensé des milliers pour avoir de la documentation, regardez le fichier d'exemple ».

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

Moi j'ai utilisé Boost.Beast pour faire un petit simili pastebin.

C'est très bas niveau, à peu près comme flask en python. On gère directement les requête HTTP et les réponses. La bibliothèque est assez récente et un peu jeune mais ça fonctionne plutôt bien.

Seul problèmes :

• pas encore de parseur d'URI pour le moment (j'ai utilisé liburiparser)
• aucune fonction de découpage / désérialization des données en POST

Pour le premier, c'est dans la TODO de l'auteur. À voir quand il l'implémentera.

Pour avoir testé Wt, je n'aime pas trop le HTML généré, il est difficile de le personnaliser et nécessite pas mal de javascript. J'aime bien avoir accès total et complet au rendu généré.

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

Je ne comprends pas ton problème. Ton contrat c'est de prendre des fonctions qui prennent deux entiers en paramètre. Sauf qu'on t'envoie une fonction qui en prend que un. C'est contraire au contrat indiqué. C'est à l'appelant de se modifier.

Sinon, c'est tout à fait possible avec std::function et une lambda (avec std::bind peut-être)

int strange_apply(int (*beurk)(int))
{
    std::function<int(int, int)> f = [beurk] (int x, int) -> int {
        return beurk(x);
    };

    f(123, 456);
}

Note que le std::function n'est nécessaire que si tu souhaite stocker beurk pour l'appeler plus tard.

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

Et sinon, une raison particulière pour ne pas utiliser std::function ?

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

la phrase KDE has been deprecated peut être rapidement mal interprétée par des personnes qui survolent ce type d'informations.

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

Exact, ils ont fait pareil avec btrfs. En fait, tout ce qu'ils n'aiment pas ils le considèrent obsolète et répandent de la mésinformations.

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

J'aime bien debian dans la simplicité par contre pour avoir fait des paquets .rpm et des .deb je préfère largement le premier. J'aimerais bien une distribution légère et simple basée sur les rpm, mais ça court pas les rues, elles sont toutes ultra bloat :(

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

Et oui, c'est ça d'utiliser les technos ultra hype comme flatpak, snap, appimage ou je ne sais quel autre bloat :)

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

Moi j'aimerais bien faire du télétravail. Pas parce que je suis fainéant mais parce que ça m'éviterai de me lever à 6h30 et rentrer chez moi à 19h20. Et oui, c'est aussi ça les inconvénients aussi de vivre en périphérie d'une grande ville et de prendre les transports en commun.

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

Je confirme aussi.

Ma maman en voulait un car désirait se déplacer en vélo mais étant une ancienne grande fumeuse et peu sportive elle s'essoufflait vite avec un vélo. Elle s'est acheté un VAE qu'elle apprécie beaucoup, bon 24kg et 1000€ la bête quand même mais son autonomie, le cadran numérique, le panier soudé au guidon et le porte bagage intégrés en font un excellent vélo “utilitaire”.

Personnellement j'aimerais aussi pouvoir me rendre à mon travail en vélo, mais j'avoue que dans mon cas étant grand sportif j'aurais peur qu'avec un VAE j'ai moins envie de faire du VTT après l'habitude de l'assistance. Du coup s'il y a des sportifs qui ont un VAE et un VTT normal, j'aimerais bien avoir votre avis :)

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

Étant développeur Qt professionnellement, je me sens obligé de répondre. Qt est un grand framework, c'est vrai mais il est finement bien découpé.

Par contre, moi je fais du C++ donc je ne sais pas comment cela fonctionne avec Python.

Voici mon code d'exemple.

#include <QApplication>
#include <QLabel>

int main(int argc, char** argv)
{
        QApplication app(argc, argv);
        QLabel label("Hello World");

        label.show();

        return app.exec();
}

Le test se fait sur Linux, donc forcément profitant des bibliothèques partagées c'est pas très pertinent. Cela dit, vu qu'on parle de Qt, on va quand même mesurer la taille si on devait importer les bibliothèques.

Évidemment je note pas les autres bibliothèques (wayland, GL, libX11) puisque ce serait plus ou moins identique avec un autre framework.

• main : 16Ko (autant ne pas le compter)
• libQt5Widgets.so : 6.7Mo
• libQt5Gui.so : 5.2Mo
• libQt5Core.so : 5.1Mo

À titre de comparaison, avec Gtk on aurait ces bibliothèques à importer.

• libgtk-3 : 7.4Mo
• libgdk-3 : 1.1Mo
• libglib-2.0 : 1.2Mo
• libgio-2.0 : 1.8Mo

Plus léger effectivement, mais Qt reste largement acceptable.

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

Sauf si tu fais de l'embarqué, sauf si tu veux toucher au matériel, sauf si tu veux des contraintes temporelles fortes. Attention, le C n'est sans doute pas le seul langage à envisager mais il a toujours du sens pour ces projets.

Je ne sais pas, je connais un ami qui a développé une interface de pointage pour les cartes de transport en commun. Ils ont fait ça en Qt Quick (QML donc avec du Javascript) et D-Bus. Bien que ce soit de l'embarqué ça fonctionne très bien.

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

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