David Demelier a écrit 754 commentaires

J'avoue que j'osais pas trop troller devant un journal d'aide, mais du coup comme vous avez commencé :

svn is the IE6 of version control.

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

freedesktop.org is open source / open discussion software projects working on interoperability and shared technology for X Window System desktops

C'est c'la, oui.

Excellent, j'y avais jamais pensé.

Posée sur la mailing list systemd, ça doit faire une bonne bombe ça.

Cela dit, il y a des points vrais. systemd unifie les scripts pour toutes les distributions (enfin dans la mesure du possible). Et permet aussi d'unifier la configuration du système.

Je me rappelle encore sous Gentoo, /etc/conf.d, sous Debian c'est des fichiers différents, dont le /etc/network. Sous redhat on utilisait des commandes system-config-* (IIRC).

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

Je sais, mais je préférerais voir ça dans le control center.

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

https://www.freedesktop.org/wiki/Software/systemd/#spelling

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

Au moins avec Mate on peut ajuster la taille des polices.

Oui c'est vrai il existe gnome-tweak-tool. C'est tellement cool de devoir utiliser des outils externes pour régler un détail aussi simple.

Ah oui ! Même mon téléphone me permet de changer la taille de la police du système.

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

Ce qui m'étonne c'est que BSD très puriste bien souvent, adopte ZFS à la licence controversé

Tu veux dire FreeBSD.

OpenBSD n'adoptera jamais ZFS. Sur NetBSD c'est en travaux mais rien de concret en ce moment. Et Dragonfly a son propre HAMMER.

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

C'est systemd, comme tout daemon unix. sshd, httpd, ftpd, dhcpd, dhcpcd, ntpd, etc.

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

Ça y va fort au niveau des ®. Il y en a partout, même pour les applications. Je trouve pas ça très professionnel.

TrueOS®
SysAdm™
AppCafe®

Je connais PC-BSD depuis longtemps et j'en suis toujours autant sceptique. Traductions automatique de leur pages (complètement à côté de la plaque). Un des développeurs principal dénigre GNOME en conférence en disant "it sucks", pas très fairplay. Puis ils réecrivent des outils spécifiquement pour PC-BSD. Ça serait mieux de contribuer des backends pour NetworkManager, packagekit, le bluetooth plutôt que de recoder une appli tierce pas du tout intégrée au desktop.

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

Il me semble que c'est justement nécessaire d'avoir des comptes github pour travis non ? Du coup ça n'est plus une option pour moi. Par contre je vais regarder pour appveyor :)

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

Le client et le serveur sont développés sous GNU/Linux, puis empaquetés automatiquement pour MacOSX et Windows.

Est-ce que tu cross compile pour macOS ? Si oui je souhaite vraiment savoir comment tu fais :)

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

Ah ouais bien joué pour le sudo faire installer :D

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

C'est à la mode malheureusement. Surtout dans l'univers nodelol.js ou toutes les applications en http://omyapp.io.

• https://www.meteor.com/install
• https://docs.chef.io/install_omnibus.html
• https://sandstorm.io/install

Il y en a tellement encore… :)

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

J'avoue qu'avoir accès root indique une faille plutôt énorme. Il est vraiment important de faire des backups tous les jours et surtout de les dupliquer sur d'autres disques / serveurs.

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

Microsoft me surprend de + en +.

Je n'aime pas powershell mais j'apprécie le geste, sous licence MIT en plus :)

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

Si on est obligé de faire en C, il y a e4c qui n'est pas trop mal.

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

Tu as des mesures réelles ?

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

https://isocpp.org/wiki/faq/exceptions#why-exceptions

“But exceptions are expensive!” Not really. Modern C++ implementations reduce the overhead of using exceptions to a few percent (say, 3%) and that’s compared to no error handling. Writing code with error-return codes and tests is not free either. As a rule of thumb, exception handling is extremely cheap when you don’t throw an exception. It costs nothing on some implementations. All the cost is incurred when you throw an exception: that is, “normal code” is faster than code using error-return codes and tests. You incur cost only when you have an error.

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

assert c'est pour des erreurs de développement. Pas des erreurs au runtime.

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

si c'est pas très loin, utiliser une exception ne sert à rien par rapport à un code de retour ou un booléen pour gérer un truc immédiat; si c'est très loin, alors tu ne peux rien faire de vraiment très sérieux à part quitter le programme.

Donc tu préfère ce genre de code ?

int c()
{
   if (!some_failure)
       return -1;
   return 123;
}

int b()
{
    int result_c;

    if ((result_c = c()) < 0)
        return result_c;

    return result_c * 456;
}

int main()
{
    int value = b();

    if (value < 0)
        // code d'erreur, je suis obligé d'utiliser une seconde fonction pour récupérer une erreur "humaine"
        std::cout << "code d'erreur: " << value << std::endl;
    else
        std::cout << value << std::endl;
}

Plutôt que :

int c()
{
    if (a_failure)
        throw std::runtime_error("error...");

    return 123;
}

int b()
{
    return c() * 456;
}

int main()
{
    try {
        std::cout << b() << std::endl;
    } catch (const std::exception &ex) {
        std::cerr << ex.what() << std::endl;
    }
}

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

Ça, ça ne va pas changer, je déteste les exceptions en C++. Et je ne vois pas bien où je pourrais en mettre.

Bienvenue en 1989 :/

En interne, il y a quelques classes qui utilisent RAII. Maintenant, où est-ce que tu en verrais dans l'API publique ?

Je déteste vraiment avoir ce genre de code :

Music m;
if (!m.loadFromFile("foo")) {
    // gestion de l'erreur 
}

Cela signifie que toutes tes fonctions membres vont devoir vérifier que l'état de l'objet Music est bien ouvert et fonctionnel. Alors qu'un constructeur qui throw rend tout simplement impossible d'utiliser l'objet. Certains vont dire que c'est une hérésie de lever une exception dans un constructeur, mais c'est tout simplement la bonne méthode.

Avec un constructeur qui throw je sais que mon objet sera valide tout au long de sa vie.

Music m("foo.ogg");

// Par buffer (vector, array), etc
Music m(buffer.begin(), buffer.end());

// Stream?
std::istream customstream
Music m(customstream);

J'ai regardé rapidement ton projet, pour le ResourcesManager, tu pourrais retourner des std::unique_ptr plutôt que des pointeurs bruts. Ça marquera complètement l'ownership et tu pourras toujours retourner un std::unique_ptr null si l'objet n'est pas trouvé :)

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

Moui, la SFML 2.0 est une grosse réecriture il me semble, autant tout casser et passer à du moderne :)

Son changelog était assez marrant d'ailleurs.

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

Très bon choix pour SDL.

Je n'aime pas la SFML pour plusieurs raisons :

1. Le développeur utilise du C++ d'un autre âge, pas d'exception, pas de RAII, pas de C++11. Portabilité ? Non merci, C++11 a déjà 5 ans.

2. J'ai eu un souci de rendu sur FreeBSD (sur Windows ça fonctionnait), tout ce que l'auteur a su me répondre était "aucune idée".

3. Je suis l'auteur du support du joystick dans SFML, lorsque j'ai proposé le patch, j'ai bien précisé qu'il s'agissait de FreeBSD mais l'auteur a vraiment voulu merger le code avec Linux. Heureusement après plusieurs mails, il a finalement bien voulu ne pas mélanger le code FreeBSD et Linux.

Hâte de voir ton framework du coup :)

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

Bah alors il a gagné depuis l'apparition de Visual Studio Code, au moins.

En même temps ce n'est rien d'autre qu'un fork de atom alors bon :)

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

Je ne sais pas pourquoi tu préfixes toutes tes structures par un _. En C++ c'est même réservé par la norme, je ne sais pas ce qu'il en est C.

Mais aussi, je trouve ça moche.

Sinon dans l'ensemble je trouve que le code est propre et bien documenté.

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

Wine etait en licence MIT avant de subir l'abus d'une societe qui a forke et ferme le code, rendu payant le logiciel et fait pleins de correctifs (et le tout parfaitement legalement). Wine est finalement passe en GPL pour ces raisons (et aussi parce que beaucoup de contributeurs se rendaient compte qu'il travaillait presque directement pour l'autre entreprise qui cherry pickait tous les nouveaux fixes de Wine).

Effectivement pour le coup je pense que c'est bien pour Wine. Je n'ai rien contre la GPL lorsqu'il s'agit de frontends (exécutables finaux).

Cela protège largement le logiciel et c'est très bien comme ça.

C'est plutôt pour les bibliothèques, j'ai toujours pesté et fuis celles sous licence GPL. Je comprends pas l'intérêt de forcer un utilisateur de ta bibliothèque à faire du code open-source uniquement. C'est là que je trouve que la vision est vraiment orientée fanatique. Heureusement un bon nombre de personnes choisissent néanmoins la LGPL qui est bien mieux pour les bibliothèques.

Tiled (mapeditor.org) est bien fait pour ça. Son exécutable est sous GPL ce qui contraint tous les changements à être libre aussi et sa bibliothèque est sous LGPL. Au moins, normalement tout le monde est content :)

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