David Demelier a écrit 754 commentaires

Aaaah oui bien vu ! Du coup tout s'explique :)

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

J'avais vu cette fonctionnalité il y a longtemps, mais je ne comprends toujours pas pourquoi elle a été intégrée avec un double underscore.

Toutes les instructions du préprocesseurs n'en comportaient pas : #define #if #else #endif #elif #pragma #undef #__has_include // WTF??

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

Alors ça c'est vraiment un moyen de résoudre des bugs subtiles car beaucoup de débutants ne savent pas que l'ordre est non-défini.

Surtout que la plupart des livres que j'ai lu n'en parlaient pas.

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

J'utilise systemd depuis au moins 3 ans, aucun problème que tu as cité.

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

Je ne peux que plussoir :)

Systemd sur un serveur, quelle idée :)

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

Depuis le temps que je suis sur Linux, c'est une des seules distributions que j'ai jamais testé. Faudrait que je regarde si j'ai encore un DVD vierge pour graver l'ISO ou une clé USB assez grande.

Ah mince on est pas encore vendredi…

En vrai, je ne connais pas beaucoup emacs, j'ai testé que quelques minutes il y a très longtemps et il m'avait l'air un peu plus simple à prendre en main que vim. Mais bon, je suis resté sur vim… N'aimant pas RMS, je n'ai jamais vraiment porté + d'intérêt à ce logiciel.

Je trouve que leur retrait de fonctionnalité est +/- compréhensible. Ça fait tâche d'avoir une fonctionnalité sur un OS non libre mais pas sur Linux. On a l'impression qu'emacs est mieux sous mac que Linux. Mais en contrepartie, je trouve ça hypocrite qu'emacs tourne sur Windows.

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

Chez moi ça marche®.

Je me souviens il y a longtemps que j'avais des problèmes avec PA sur FreeBSD, qui était installé à cause de GNOME IIRC.

Mais là, tout marche (sur Linux en tout cas), je peux mettre un casque bluetooth depuis GNOME, passer en HDMI, changer le son pour une application et aucun bug.

En plus grâce à PA, j'ai différents volumes entre mon casque et les haut parleurs de mon PC. Ce qui par exemple, me laisse possible de mettre le son des hauts parleurs assez bas pour éviter de gêner les gens autour de moi si je débranche mon casque par mégarde.

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

Je n'arrive pas à me déplacer, je suppose que tu l'as principalement développé pour les clavier azerty ?

Car j'ai du mal à me déplacer avec mes touches wasd/zqsd qui ne sont pas du tout au même endroit qu'un azerty :p

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

Je n'utilise plus flash depuis pas mal d'années et le seul site qui est problématique pour moi c'est deezer. J'espère qu'ils vont passer sur HTML 5 un jour.

Je vois déjà les gens dire "passe à spotify" oui pourquoi pas mais j'ai deezer gratuit avec orange :p

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

Ah oui, j'avais lu le journal une première fois et répondu le lendemain. J'aurais du dormir + du coup :D

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

Pour ma part quand je faisais encore du C, j'écrivais souvent une fonction xmalloc qui faisait un exit() après avoir écrit un message d'erreur.

Évidemment, si malloc ne fonctionne pas, mon message d'erreur a peut-être un risque de ne pas être affiché non plus, car lui aussi a peut-être besoin d'allocation dans la fonction printf. D'ailleurs j'avais vu une fonction dans GCC qui stockait une chaîne fixe et qui faisait appel à write(2) directement pour éviter ce problème.

Comme décrit dans plusieurs commentaires au dessus, cela dépend vraiment du contexte. Je code des applications assez basiques, donc ce n'est pas grave si elles se terminent parce qu'il n'y a plus de mémoire. Du coup je codais ceci :

void *xmalloc(size_t size)
{
    void *ptr = malloc(size);

    if (ptr == NULL)
        err(1, "malloc");

    return ptr;
}

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

Du coup comme tu as dit que tu faisais du C++11, je me permet de commenter deux trois choses :

• std::istringstream i (source_string.c_str());
  • Pas besoin de .c_str()
• Pourquoi utiliser une chaîne C dans le main ? (ligne 119)

Mis à part ça, code moderne :)

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

Ce qui m'intrique, c'est la volonté d'avoir implémenté le driver NVMe from scratch alors que FreeBSD en a un. Je me demande s'il y a des raisons à cela ?

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

Le problème avec Debian c'est qu'il faut accepter d'avoir des applications vieilles pendant environ 2-3 ans avant d'avoir une grosse mise à jour.

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

Alala pourquoi avoir acheté une nvidia :(

Malheureusement si ça ne fonctionne pas avec je ne vois pas de solution, à part rajouter nomodeset en permanence dans le grub (ou systemd-boot).

Peut-être tu pourrais tester avec une version plus récente de xf86-video-nouveau ?

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

L'au delà est fan de NRJ alors ;)

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

D'accord, merci pour la réponse. Je vais désactiver le micro interne de l'écran tant que j'en aurai pas besoin et je verrai si ça arrive à nouveau :)

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

Petite question, pourquoi préfixer certaines options par un _ ? :)

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

Je suis assez déçu si c'est bel et bien le cas.

On vient de me donner une imprimante HP, j'osais pas spécialement acheter une imprimante car je connais peu le support sous linux (à part que canon pue, en ayant eu 2).

Et avec hplip, tout marche out-of-the-box. Scanner et impression. J'ai pas encore acheté de cartouches car j'imprime un papier environ tous les 4 mois (on est en 2016 ! imprimer c'est mal).

Du coup quand elle sera plus fonctionnelle, faudra que je trouve aussi une alternative.

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

Je confirme, ne jamais acheter de canon.

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

Et bien si ça ne compile pas, tu envoies un bug report. Ça c'est la faute du développeur et il n'aura pas à l'ignorer ;)

Personnellement, je m'assure que mon application compile sur Linux, FreeBSD et Windows (vs et mingw).

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

Le .tar.gz c'est clairement le plus connu. En terme de compression je pense qu'il est un peu à la ramasse. Je vois (et j'utilise) beaucoup de .tar.xz en ce moment.

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

J'adore le softwaves !

Bon, vous vous doutez du quel j'ai mis en 1er :)

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

C’est quoi que tu détestes ? Avoir un dossier « packaging » qui ne te sert à rien, quand tu fais un git clone… ? C’est si génant que ça ?

Premièrement, pour les mêmes points cités plus haut, je ne suis pas sûr que les packagers des distributions vont utiliser tes modèles pour leur paquets. Si ça se trouve, la distribution X a décidé de changer d'emplacement pour installer de la doc, manque de bol t'es pas au courant, ton .spec/debian/PKGBUILD/whatever est obsolète et invalide. Le packager va créer le sien pour éviter ce genre d'obsolescence.

Aussi, si tu n'as pas sous la main toutes les distributions que tu maintiens dans ton application, tu ne peux pas tester tes fichiers de construction de paquets et garantir leur bon fonctionnement. Résultat : l'utilisateur ou packager qui s'en sert voit que ça fonctionne pas. Ça va l'agacer, il va se plaindre (ou envoyer un bugreport) et ça va faire du boulot de maintenance pour toi. Alors qu'au départ, si tu délègues complètement cette tâche, tu n'as aucun souci.

Less is more, comme dit. Tu imagines si tu maintiens 50 distributions dans ton dépôt ? J'ose pas imaginer le bordel.

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

Personnellement, je te conseille de ne pas te poser de questions. Fournis ton application en code source avec les fichiers qui vont bien (LICENSE, README, INSTALL, etc).

Ce n'est pas à toi de t'occuper de générer un paquet pour les trillions de distribution qui existent.

1. Tu n'arriveras jamais à le garder à jour par rapport à la distribution ciblée,
2. Fournir un paquet c'est bien, mais dans le dépôt officiel c'est mieux. J'imagine pas la galère si tu devais avoir accès aux dépôts de toutes les distributions,
3. Ne pollue pas ton application avec des fichiers de construction pour chaque distribution. Je déteste voir un répertoire debian, des fichiers .spec et autres trucs dans un code source. En plus, qui dit que ton .spec sera compatible fedora, suse, openmandriva ?

Comme tu l'as dit, flatpak semble l'alternative la plus viable, et c'est la seule qui doit être maintenue par l'auteur du logiciel. À voir si ça va vraiment marcher.

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