barmic 🦦 a écrit 5946 commentaires

  • [^] # Re: Support Wayland

    Posté par  . En réponse à la dépêche GNOME 3.34. Évalué à 7.

    Le débat reviens régulièrement. Si j'ai bien compris X11 fait ça extrêmement mal d'un point de vu efficacité (les implémentations DRI ne font plus de transparence réseau) et d'un point de vu sécurité. L'idée a était de laisser à ceux qui font ça bien le soin de le faire (VNC, rdp ou spice).

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Performances vs. SĂ©curitĂ©

    Posté par  . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 8.

    L'autre problème plus subtil est que c'est une mauvaise idée de se dire "pas besoin de programmeurs compétents pour ça, le langage s'occupe de tout".

    En même temps personne ne dit ça. Ce qui est dit c'est qu'il est déjà suffisamment complexe d'éviter le bugs pour s'outiller pour en limiter. Pour ça il est possible :

    • d'ajouter de la sĂ©mantique dans le langage pour que le compilateur puisse dĂ©terminer l'absence de classe de bugs complètes
    • d'avoir des API plus sĂ»res qui t'empĂŞche de ne pas respecter leur contrat ou qui vĂ©rifient leur contrat

    Tu as trouvé un bug médiatisé avec Ada ? Combien de bug par an arrivent à cause d'un buffer overflow ? Choses qu'on sait supprimer depuis plusieurs dizaines d'années. En tant que développeur je ne suis pas fier que l'industrie à la quelle je fais parti n'arrive pas à éradiquer ce genre de choses. Le buffer overflow c'est surtout pour du C ou C++, mais le déréférencement de valeur nulle on en a presque partout et on a même des langages qui viennent d'arriver qui continuent d'avoir ce problème ou qui se satisfont de le corriger en partie. Alors qu'on sait supprimer cette forme d'erreur.

    Quand on peut avoir un code qui prouve l'inexistence de certains bug ça vaudrait le coup qu'on arrête de faire les flemmards en se trouvant des excuses.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Le C++

    Posté par  . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 10.

    Le C++ je sais pas mais toi tu es très difficile à lire. J'ai relu plusieurs fois ton texte. Je pense avoir compris le sens général, mais je suis persuadé qu'il y a des phrases dont il manque des parties ou qui ont été refacto en cours de route. Essai de faire des phrases plus courtes tu sera plus compréhensible.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: SPAM

    Posté par  . En réponse à la dépêche Le bulletin d’automne d’ONLYOFFICE : mises à jour, nouveau partenariat et #OSSParis19. Évalué à 3.

    Perso j'arrĂŞte ici, pas possible de continuer avec autant de mauvaise foi. Je ne sais pas qui trouve tes messages pertinents, mais c'est triste.

    Ceux qui se sont intéressé aux problèmes et qui ne s'évertuent pas à faire du prosélytisme.

    Même la FSF est consciente de cela. Un code est véritablement protégé quand il utilise une licence open source et que les droits sur le code sont partagés. Zenitram le répète à longueur de journée : utiliser la GPL quand on est une entreprise permet de limiter la concurrence car un concurrent qui réutiliserais ton travail est soumis au copyleft est pas toi.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: SPAM

    Posté par  . En réponse à la dépêche Le bulletin d’automne d’ONLYOFFICE : mises à jour, nouveau partenariat et #OSSParis19. Évalué à 2.

    La licence ne s'applique pas à celui qui a les droits du code. Tu peux imaginer. Sortir des phrases de leur contexte mais non, elle ne s'applique pas à celui qui possède les droits sur le code.

    C'est bien pour ça que tu as des CLA qui existent. Elles permettent à celui qui possède les droits sur le code de changer de manière incompatible la licence du code ce qui serait impossible si la licence s'appliquait à celui qui possède les droits sur le code.

    Tu pourra trouver tout un tas de sources sur les problèmes que posent les CLA entre autre le fait de partager les droits sur le code permet d'obliger chaque détenteurs du droit sur le code à suivre la licence car il ne possède pas les droits sur tout le code.

    Le you de la licence c'est celui qui reçoit. Il est dit dès le préambule que le développeur qui choisi cette licence donne des droits pas qu'il s'engage à quoi que ce soit.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: SPAM

    Posté par  . En réponse à la dépêche Le bulletin d’automne d’ONLYOFFICE : mises à jour, nouveau partenariat et #OSSParis19. Évalué à 1.

    Comme cité dans le commentaire au quel tu répond on parle on parle au sens strictement juridique. Il n'y a pas de définition juridique de libre au sens que tu l'entends.

    Si un éditeur publie un exécutable en proclamant que c'est un logiciel libre mais sans publier le code source, tu penses vraiment que la licence ne contraint pas l'éditeur ?

    Alors « libre » n'a pas de sens juridique. S'il dit que son logiciel est sous licence GPL et qu'il ne l'est pas tu peux éventuellement le traiter de menteur, mais pas de violer la licence.

    Pour le cas présent c'est éventuellement une question de licence inapplicable. Ça n'est pas illégale. Ça ne fonctionne pas, mais ce n'est pas délictueux. Le fais de choisir une licence n'est pas contraignant.

    Je veux bien que tu montre quel passage de la GPL oblige le détenteur des droits, parce que je vais avoir du mal à te montrer l'endroit où ça n'est pas et qu'affirmer toi comme moi des choses opposées n'amène pas à grand chose.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: SPAM

    Posté par  . En réponse à la dépêche Le bulletin d’automne d’ONLYOFFICE : mises à jour, nouveau partenariat et #OSSParis19. Évalué à 2.

    D'un point de vue strictement juridique, il me semble que livrer les sources sans les build est tout Ă  fait confirme Ă  la GPL.

    Comme déjà indiqué plus haut par d'autres, c'est un mensonge malheureusement trop colporté. Ça serait bien de corriger ce poste qui semble être positivement noté…

    Il me semble que le détail que tu ne prends pas en compte. C'est que quand tu es unique détenteur des droits sur le code, tu fais bien ce que tu veux et le fais de décider les publier tes sources sous licence GPL ne te contraint pas toi. Elle s'applique à ceux qui reçoivent le code et qui n'ont d'autres droits sur celui-ci que ce tu veux bien leur donner. C'est bien pour ça qu'il est possible de faire de publier sous double licence.

    Référence nécessaire : jamais entendu parler. Des problèmes pour enlever les noms de marque, oui, ou pour se dépatouiller des différences avec upstream que Red Hat ne livre parfois pas (i.e. ils filent un gros tarball avec tous les patchs appliqués, ce qui est conforme avec la GPL), peut-être mais pouvoir builder les logiciels est indispensable.

    RH n'est pas propriétaire du code, ils n'ont donc pas le choix.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Les fichiers XCF multicalques de Gimp 2.10 ne sont toujours pas pris en charge

    Posté par  . En réponse à la dépêche GNOME 3.34. Évalué à 5.

    Si gimp n'a pas inclu ce format dans gtk ou je ne sais quelle bibliothèque généraliste qu'est-ce qui les pousserait à l'implémenter dans un translator ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Heureux

    Posté par  . En réponse au journal Elm sort en version 0.19.1. Évalué à 2.

    Quel temps selon toi prendrait-il à un développeur Junior ( un petit nouveau dans une team, sans expérience en dev fonctionnel ) pour apprendre Elm from scratch et être productif.

    Combien de temps je ne saurais dire, mais ça va assez vite. Une partie de ce que tu perds en palier initial, tu le gagne en mur que tu ne prends pas un peux plus tard.

    Par contre de mon point de vu (je ne suis pas très friand de html+css), c'est l'écosystème plus faible que chez angular qui va réduire la productivité.

    Là où avec angular les compatibilité de langages et la manière de faire du framework permettent d'encapsuler n'importe quoi dans un composant et de s'en servir sans à se soucier de l'implémentation (et donc à le combiner avec n'importe quel autre composant en principe). Avec elm on va plutôt faire ça en dehors de l'application elm et interagir avec via des envoie/réception de messages. Ça permet de continuer de garantir toutes les propriétés qu'elm veut donner à ses utilisateurs. Par contre manipuler le DOM via elm et via autre chose en même temps ne se mélange pas aussi bien. Personnellement j'ai très peu besoin de choses que je ne trouve pas en elm directement et si j'ai besoin de quelque chose d'autres je le met dans une branche bien distincte du DOM.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Heureux

    Posté par  . En réponse au journal Elm sort en version 0.19.1. Évalué à 1. Dernière modification le 23 octobre 2019 à 17:52.

    Reason n’est ni plus ni moins qu’une option dans le compilateur.

    Du coup il ne vient pas avec un framework comme elm. C'est dommage parce que c'est une grande part de ce qui fait la force d'elm je trouve. Après il peut être implémenté à coté. Mais je n'en vois aucune trace dans la page de documentation du site officiel.

    Ce que je trouve génial avec elm c'est que c'est un langage intéressant avec un framework qui se combinent parfaitement.

    Tiens c'est surprenant le lien en dessous indique que reason n'est pas fonctionnellement pur je pensais qu'Ocaml l'était.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Heureux

    Posté par  . En réponse au journal Elm sort en version 0.19.1. Évalué à 7.

    Moi je m'en sers et j'en suis très satisfait. Je n'ai effectivement jamais rencontré d'erreurs au runtime avec lui et le compilateur est très gentil. Je n'ai pas vraiment pratiqué de langages fonctionnels purs avant elm et je ne maîtrisais pas bien la syntaxe d'haskel.

    Il paraît que Facebook a une alternative dérivée d'ocaml.

    Elm vient avec un framework, mais je le rapprocherai plus de redux que de react. Dernier point important c'est qu'il n'y a pas de bibliothèque de composants directement utilisable.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Bien d'accord !

    Posté par  . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1.

    Flatpak installé a tout cassé

    Ça n'est pas possible si j'ai bien compris. Tout au plus il peut avoir quelques logiciels qui interagissent avec ce flatpak qui vont fonctionner bizarrement.

    Encore une fois, faut voir ce que vous voulez

    Moi perso je ne veux rien, je laisse les gens qui font faire. Je ne vois pas pourquoi avoir une ambition quelconque si c'était le cas au lieu de répondre à des commentaires sur un sites d'aigris je contribuerais. Ta question n'a pas de sens pour des gens qui ne sont pas aux commandes d'une distribution. Nous, quidam de linuxfr, nous pouvons vociférer autant que l'on veut ça n'a pas vocation à être « volonté de la communauté linux ».

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: moinsage?

    Posté par  . En réponse au journal Un serveur de mail complet et moderne . Évalué à 2.

    Le fait de ne pas du tout contribuer, même pas un commentaire succinct de remerciement ou une contrib au wiki, c'est quand même assez suspect […]

    Ah bon ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Atom / VSCode

    Posté par  . En réponse au journal Atom / VSCode. Évalué à 1. Dernière modification le 20 octobre 2019 à 00:57.

    C'est surprenant d'utiliser screen comme ça. Moi je préfère utiliser juste Emacs. Tant que je n'ai pas besoin de sessions persistantes (et encore je ne suis pas sûr que ça n'existe pas dans emacs), je préfère amplement tout faire via emacs. C'est plus logique et nettement mieux intégré.

    Si je ne trouve pas de sessions persistantes dans emacs, j'utiliserai screen (ou tmux) uniquement pour ça.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Bien d'accord !

    Posté par  . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1.

    Non, les gestionnaires de paquets ne sont pas des solutions Ă  l'arrache (dire ca c'est un peu insulter les devs des distributions en fait)

    Je n'insulte personne, j'affirme qu'un gestionnaire de paquets avec gestion des dépendances ça n'a rien de triviale. On revois éternellement de nouvelles personnes arriver en expliquant que ce qu'ils font c'est plus simples alors qu'ils ont surtout réimplémenter les bugs corrigés il y a longtemps chez leurs prédécesseurs. Critiquer leur travaux ce n'est pas les insulter ou alors je pourrais te répondre que ces gens qui pensent réimplémenter des gestionnaires de paquets en quelques semaines insultent leurs prédécesseurs.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Bien d'accord !

    Posté par  . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1.

    Je n'ai jamais vu de chartes des paquets d'une distribution linux. Si tu en as une sous la main, ça m'intéresse. On peut considérer la définition du logiciel libre selon Debian, mais ça me paraît assez loin de ce dont tu parle.

    Tu amalgame une techno avec son usage. FP peut travailler sans dépôt, c'est potentiellement gênant effectivement. Ça fait perdurer des usages dangereux comme on l'a déjà aujourd'hui (en particulier via curl ... | sh). Mais il donne la possibilité de faire de la distribution logiciel hors distribution linux. Tu peux voir la fondation Apache créer le sien par exemple pareil pour gnu. Les innombrables projets qui créent leur propre dépôt debian (mongo, docker, chrome,…) peuvent faire un travail plus universel et ne pas laisser sur le carreau les utilisateurs de distributions trop exotiques. Enfin ça peut être utile pour des choses comme debian-multimédia.

    La multitude de gestionnaire de paquets elle est d'abord du fait des distributions linux qui chacune se sent obligée de montrer qu'elle est différente. Ensuite là il y a une solution concerté qui a une chance et vocation à remplacer toutes les méthodes à l'arrache que l'on a aujourd'hui.

    FP ne fait pas le café, il ne fait pas revenir l'être aimé, il est juste une proposition pour passer d'une situation pourrie à un peu moins mieux.

    Et mon dieu, c'est clair qu'il n'est pas parfait…

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Bien d'accord !

    Posté par  . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 5.

    La boîte qui ne me laisse pas admin de ma machine, elle ne va pas me voir longtemps…

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Embrace, extend and extinguish

    Posté par  . En réponse au journal Atom / VSCode. Évalué à 4.

    Cette comptine ne fonctionne que pour les formats, les standards et tout ce qui revient Ă  des interactions. Tu ressemble Ă  l'existant, tu en fais plus et une dis que tu es suffisamment gros tu as la main mise sur le domaine.

    Tu ne peux pas faire ça avec un éditeur de texte.

    Surtout qu'une bonne partie de l'intelligence du truc a été volontairement architecturée pour être utilisable ailleurs et est utilisé ailleurs (par eclipse par exemple). Et ça résous un casse tête pour les créateurs de langage.

    Donc au lieu d'affirmer que les gens ont des problèmes de mémoire, je veux bien que tu nous montre que tu n'as pas de problème de compréhension de ce que tu met en lien ;)

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Ni l'un, ni l'autre

    Posté par  . En réponse au journal Atom / VSCode. Évalué à 3.

    Je ne suis pas d'accord. Je ne considère vraiment pas le web comme étant une fonctionnalité essentielle à un IDE python. C'est tellement pas essentiel que je l'utilise depuis 5 ans en version community sans frustration. J'ai essayé la version ultimate, j'en ai même une licence avec la boîte où je travaille, mais la version community me convient amplement.

    Par contre j'ai arrêté les EAP de la version 2019.4 qui n'étaient pas très stables.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Yoda ?

    Posté par  . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 0.

    J'ai pas tout compris, mais, si tu pense que le C est immunisé à ce genre de choses, il faudra en parler aux développeur du noyau linux : https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Bien d'accord !

    Posté par  . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1.

    C'est une question d'implémentation si c'est le cas (je ne sais pas, je n'utilise pas). Avec un peu de pinning, ça n'arrivera pas. Ils pourront toujours installer un paquet que tu n'a pas dans ta distribution, mais c'est justement ce qui leur est demandé.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: journaux courts

    Posté par  . En réponse au journal manque d'auto-respect des bookmarks?. Évalué à 2.

    Bref, l'avis des gens qui soumettent des liens + commentaire nous éclairera certainement.

    Le sujet d'un journal avec un lien + ton avis, c'est ton avis.
    Le sujet d'un lien ton commentaire en dessous, c'est ton lien et ton avis n'est que l'un des avis parmi tant d'autres.

    C'est très différent.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Yoda ?

    Posté par  . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 6.

    Tu met la constante à gauche pour empêcher tout risque d'affectation. C'est le fait d'écrire :

    if (12 == foo) {
    }

    au lieu de :

    if (foo == 12) {
    }

    Tout ça pour éviter un malencontreux :

    if (foo = 12) {
    }

    Qui est toujours vrai. Il y a une page wikipedia lĂ  dessus.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: limitation d'un schĂ©ma en couches vs FS intĂ©grĂ© ?

    Posté par  . En réponse au journal Stratis 1.1.0. Évalué à 2.

    La question a était envisagé par l'équipe. Dans leur document de conception, ils expliquent que la couche 0 devrait être capable de le faire. Je ne sais pas comment ils prévoient de le faire, mais ils sont conscient de cette question.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • [^] # Re: Quel est le but de Stratis ?

    Posté par  . En réponse au journal Stratis 1.1.0. Évalué à 1.

    Tu pourrais lire jusqu'au bout avant de sauter sur le bouton répondre ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll