liberforce a écrit 4730 commentaires

Il me semble qu'il y a aussi un caractère d'innovation mis en avant par la FSF. Par tu peux mettre une bibliothèque qui fait des choses basiques en GPL-3, mais en pratique ça ne sert pas à grand chose, ça freine la redistribution alors qu'il y a plein d'alternatives qui font la même chose (ou mieux) sous des licenses plus libérales (BSD, MIT). Mais après chacun décide de faire ce qu'il veut avec son code :).

Ah, c'est le truc pour forcer un réseau privé au lieu de public, c'est ça ? J'ai galéré avec leurs différentes images, si tu veux le faire au niveau graphique ça change tout le temps de place et sur l'image Win10 je ne trouvais même plus d'interface graphique pour le faire… Effectivement, sans ça tu as beau avoir le pare-feu désactivé et les serveur winrm activé, impossible de causer en winrm.

Sur les VM fournies, une commande permet de remettre à 0 la durée d'évaluation. C'est aussi plus simple quand tu as juste des tests à faire et pas besoin de demander de licence à l'IT, ces VM sont faites pour ça.

Le tempo, malheureux !

Ce genre d'appli en ligne de commande est une très bonne idée, vu que l'interaction utilisateur est de toute façon très limitée.
En revanche, GPL-3.0+ je trouve ça un peu restrictif pour un outil relativement simple. Tu dois être dans les 300 lignes de code C++, c'est à peu près dans dans ce cas là que la FSF recommande l'Apache-2.0.

Perso j'ai commencé un petit métronome en GTK+, j'ajouterai sans doute une fonction de détection des BPM, c'est effectivement très utile (mais pas de rapport avec la question de la licence, je compte recoder la fonctionnalité moi même ;-)). Pour le build system j'ai pris Meson (et apprécié la rapidité de configuration sous Windows par rapport à CMake), et pour la partie ligne de commande j'utilise en général les fonctionnalités de la glib.

J'avais testé la compatibilité Windows sous MSYS2, mais je ne connaissais pas mingw-bundledlls. Ça a l'air pas mal mais seulement adapté aux projets comme les tiens avec des dépendances purement à des bibliothèques. Ça ne résoud pas les dépendances à des ressources (configuration, icônes, thèmes). Une autre possibilité pour créer un bundle est de créer un package MSYS2 pour ton appli et de l'installer avec ses dépendances dans un préfixe spécifique. Tu n'as ensuite plus qu'à livrer le dossier en question. Je n'ai pas encore essayé en pratique mais ça se fait.

Et je ne dirai rien sur github ;). Merci d'avoir partagé ton projet :)

C'en est.

Faut pas faire du libre si on est trop susceptible. Un rappel de la licence n'est pas une lettre d'avocat. Si ton code est sur github, tu distribues tes sources puisque n'importe qui peut venir les cloner, work in progress ou pas.

Ce qui a manqué aux intervenants c'est ce morceau que j'aime dans le code of conduct de GNOME:

Assume people mean well:

Remember that decisions are often a difficult choice between competing priorities. If you disagree, please do so politely.
If something seems outrageous, check that you did not misinterpret it. Ask for clarification, but do not assume the worst.

Celui qui ouvre le bug utilise des mots forts (will, must) parce que ce sont des obligations légales. C'est sûr, il aurait pu mettre des petites fleurs et des « s'il vous plaît », mais le fond aurait été le même. La réponse en mode « je te parle pas à toi » au lieu de mots d'explications n'est pas très constructive non plus.

Personnellement, je pense que sur ce genre de conflits il faut justement expliquer qu'on est de bonne foi et rester courtois. Rompre le dialogue au moindre pépin, ça ne mène nulle part (une exception : les personnes toxiques).

Je rappelle que mon commentaire est dans le contexte du fork de GNOME 2 par MATE. Je compare à GNOME 3.0, pas à GNOME 3.26. Et non les applications n'ont pas radicalement changé à cette période, pas assez pour justifier un fork selon moi. Les applications ont un peu changé mais le gros de la transition pour elles a été le passage à GTK+ 3.

Cf. https://help.gnome.org/misc/release-notes/3.0/#rnusers.applications

Et wikipedia pour les changements de 3.0:

Introduction of GNOME Shell. A redesigned settings framework with fewer, more focused options. Topic-oriented help based on the Mallard markup language. Side-by-side window tiling. A new visual theme and default font. Adoption of GTK+ 3.0 with its improved language bindings, themes, touch, and multiplatform support. Removal of long-deprecated development APIs.

Merci pour cette info en tout cas, mais dans ce cas, Radeon X300 ça devrait être pris en compte:
https://www.x.org/wiki/RadeonFeature/#index5h2

Ce n'est pas le cas, donc même là ce n'est pas forcément fiable. Faudrait que je teste avec une Fedora tout de même.

Mon problème de GNOME Shell qui crashe et SSE2 sont sur des machines différentes.

Le but était justement de continuer à faire vivre GNOME2, donc heureusement qu'ils ont tout gardé…

Je ne vois pas en quoi a répondait au problème. Les applis n'ont pas changé de manière trancendentale entre GNOME 2 et GNOME 3. C'est GNOME Shell la réelle modification de GNOME 3. Ça ne justifiait pas selon moi un fork massif.

Ils ont réussi à porter l'intégralité de leur environnement sur GTK3 plus rapidement que Xfce, donc visiblement ils ont les ressources.

Tant mieux pour eux.

Et au pire GTK2 ne m'aurait pas empêché de dormir.

Sans GTK+ 3, pas de Wayland.

Le problème de MATE ça a été l'approche "on forke tout", là où Cinnamon prenait l'approche "on forke que ce qui est nécessaire". MATE s'est retrouvé à dupliquer tout le boulot de migration à GTK+ 3, et je ne vois rien de glorieux à ça. Un projet libre a rarement assez de ressources, donc là maintenir toute la stack GNOME à eux seuls, en étant (je pense) moins nombreux, je trouve ça au mieux contre-productif, au pire néfaste pour l'utilisateur (tout un environnement de bureau à maintenir côté bugs de sécu, je pense que ça doit être un gros boulot).

À un moment il faut bien une limite, sinon pourquoi pas protester contre tous ces bureaux qui ne marchent pas sur des 386?

TL;DR: Le problème n'est pas de ne pas fonctionner, mais ne ne pas dire à l'utilisateur pourquoi ça ne fonctionne pas.

Certes, mais tu noteras qu'il y a souvent peu de "system requirements". Ceux de GNOME Shell ne sont pas clairement explicites. De plus, sur mon autre machine (AMD Athlon XP Barton 3000+), celle qui fait tourner GNOME, j'ai aussi eu d'autres soucis. J'ai voulu ripper des CD, et sound-juicer crashait systématiquement pendant l'encodage au format FLAC. La cause ? Bien que ces processeurs sont sortis à la même période que les Pentium 4, ils n'ont pas le jeu d'instructions SSE2, et la lib l'utilisait. En la recompilant, plus de soucis, et j'ai pu continuer à utiliser la même machine encore un peu.

Mais c'est parfois un peu difficile de savoir avec quelles options les distrib sont compilées. Tu as beau avoir du i{3,4,5,6}86 dans les noms de paquets, ce n'est plus vraiment représentatif dès que tu rentres dans la catégorie des "ordinosaures". Mageia (ça ne doit pas être les seuls) fournit des paquets i586, et cet identifiant correspond aux Pentium 1. Chez Ubuntu, c'est du i386. Cet identifiant ne sert plus à rien si ce n'est indiquer que c'est du x86 sur 32 bits. Tu finis donc par avoir des crash qui pourraient être évités: on sait quel matériel tu utilises, et on connait les flags utilisés pour compiler les applis, je pense qu'il y a bien moyen de faire un diagnostic pour dire ce qui pourrait coincer, ou au moins vérifier que ça correspond au moment de l'installation des paquets. Moi je peux sortir un débogueur et analyser le problème (et encore, j'avais pas fait gaffe au code renvoyé par le segfault), mais tous les utilisateurs finaux ne sont pas informaticiens.

Je veux bien qu'on ne jette pas le matériel qui marche, mais s'attendre à ce qu'une machine de 11ans d'âge fasse tourner le dernier bureau à la mode, c'est peut-être un peu optimiste!

Mon autre machine a le même âge, et ça marche. Je ne dis pas que je prends ça pour acquis, je sais bien que ce sont de vieilles configs. Si je les garde, c'est que tant que ça fait son job, et que mes besoins sur ce genre de machine sont remplis, alors pas besoin d'autre chose.

J'ai un jour vu un reportage sur des enfants en Asie qui brûlaient au briquet les cartes mères et les "sniffaient" pour savoir comment les trier pour les recycler. Je t'assure que ça soigne de toute envie d'avoir le dernier gadget à la mode. Ça ne m'empêche pas d'avoir d'autres machines, mobiles cette fois ci, mais dans tous les cas je les fais durer le plus longtemps possible. C'est à dire jusqu'à ce qu'elles tombent en panne et que je ne puisse pas les réparer ou bien quand elles ne remplissent plus mes besoins.

Pour en revenir à GNOME, j'espérais que ça tourne, mais si ça ne tourne pas parce que la machine est trop ancienne, ça me va aussi. Ce qui était plus frustrant toutefois c'était de ne pas avoir de message d'erreur clair au lancement qui m'en informe. Le comportement de base que j'ai eu, c'est la session qui tente de se lancer et qui crashe en boucle car relancé par systemd (mais c'est peut être un problème de l'intégration dans Mageia). Je savais qu'il y a le backend logiciel llvmpipe donc je pensais avoir au moins un truc très lent et qui se lance.

Peut être que la machine ira à la casse, ou peut-être que je trouverai une meilleure carte graphique d'occase en brocante ;).
À une époque j'avais recyclé un vieux PII 400MHz avec de la RAM défectueuse achetée en brocante. Une des forces du logiciel libre ça reste pour moi d'éviter l'obsolescence de matériels qui peuvent toujours servir quand c'est possible. Et puis si tout le monde faisait tourner des bêtes de course, plus personne ne ferait attention à la surconsommation de CPU ou de mémoire :)

Je ne vois pas pourquoi ton commentaire a été jugé inutile. GNOME 3 ne tourne pas sur cetaines vieilles configurations, notamment celles avec des cartes graphiques anciennes, c'est un fait. GNOME Shell exige certaines API de rendu 3D, ou sinon il ne démarrera pas. Et personne à ma connaissance ne teste le rendu software via llvmpipe.

Exemple concret: je n'ai pas réussi à lancer GNOME 3 sur un Dell Optiplex 320 équipé d'une ATI Radeon X300.

J'ai une autre machine avec une carte ATI qui arrive à faire tourner GNOME 3, mais avec un AMD Athlon XP 3000+ avec 1,5Go de RAM, ça commence à faire juste. Je ne dis pas que MATE tournerait mieux, mais GNOME 3 trouve ses limites.

Il y avait une conférence sur le sujet au FOSDEM:
https://fosdem.org/2018/schedule/event/mozilla_eu_copyright_reform_end_floss/

Je ne l'ai pas encore regardée, donc je vous laisse vous faire votre avis.

.

Avec des fichiers liés, il se retrouve lui même à gérer l'emplacement sur le système de fichier de ses images. S'il les déplace, les liens seront cassés. Pour redistribuer, il faut donner le fichier odg + les ressources. Pour des fichiers de 380 octets, on s'amuse pas à ça. Les fichiers liés sont utiles quand tu as des insertions d'éléments très lourds, pas dans ce cas précis (ou alors juste comme solution de contournement).

Je reproduis sur LibreOffice 4.2.8.2 sur Ubuntu 14.04. Donc c'est un vieux vieux bug. J'ai extrait l'image fautive du odg d'origine en décompressant le document avec file-roller. Si je crée un nouveau document odg, que j'insère cette image, et que je sauve, l'image est tronquée. Étrangement, eye of gnome arrive à la lire, et si j'ouvre le fichier odg qui contient cette image tronquée, elle apparaît normalement. Le vrai bug est donc ancien, mais juste mis en évidence par des versions plus récentes de LibreOffice parce que l'image corrompue est remplacée par un rectangle noir.

N'oublie pas que tu as beaucoup plus d'utilisateurs que de développeurs. Il ne faut pas sous-estimer la charge de travail que représente la reproduction de bugs. Je trouve donc normal d'essayer de déléguer un peu de la complexité, maintenir un logiciel, souvent bénévolement, n'est pas de tout repos. Mais les développeurs s'adaptent en général à l'audience, et il n'est pas nécessaire d'être développeur pour ouvrir un bug.

Sur le fond, quelqu'un qui prend du temps pour te remonter un bug ou une suggestion, ça a toujours de la valeur.

Tu ne prends pas en compte le temps passé sur chaque bug à les trier, gérer les doublons, et les tester. Tout ça c'est une charge de travail non négligeable, et les projets libres sont peu nombreux à ne pas manquer de main d'œuvre. Un bug ouvert, mais sans une bonne procédure de reproduction, ça ajoute plus de charge que de bénéfice. Le bon bug et le mauvais bug quoi…

Si tu rapportes un bug sur une vieille version, le bug n'est plus forcément valide. C'est donc mieux si le rapporteur peux reproduire lui même avec une version plus récente pour être sûr que le bug est toujours d'actualité. C'est encore plus nécessaire si le problème est difficile à reproduire ou est dépendant d'un matériel quelconque. Cependant, ce n'est pas obligatoire, et de toute façon les compétences de chacun sont variables. Mais en le faisant tu augmentes les chances que ton bug soit corrigé en faisant toi même une partie de l'investigation, et c'est à mon avis vrai pour tous les projets libres.

Dans tous les cas, si tu as un bug avec une application, tu as habituellement juste cette application à recompiler, éventuellement quelques dépendances plus récentes, mais pas tout GNOME. Le projet est cependant conscient que cela peut être difficile, c'est pour cela que les runtime de flatpak doivent permettre d'avoir la bonne configuration et avoir le moins dépendances possibles à recompiler, ce qui permet d'abaisser le niveau de connaissances exigé pour contribuer.

Je me souviens d'une copine il y a 15 ans qui m'avait donné un .doc énorme. En fait elle avait collé une image bitmap non compressée dans le document, et Word avait conservé l'image telle quelle. Compresser au mieux les images de manière automatique évite ce genre de cas de figure, et contribue au fait d'avoir un document le plus petit possible. Bon, après faut pas se louper et altérer les images :p

Bien vu.

if (rBmpEx.IsTransparent())
{
    ...
}
else
{
    mpAccess = Bitmap::ScopedReadAccess(aBmp); // palette + RGB without alphachannel
    if (mpAccess)
    {
        if (ImplWriteHeader())
        {
            ImplWritepHYs(rBmpEx);
            if (mpAccess->HasPalette())
                ImplWritePalette();

            ImplWriteIDAT();
        }
        mpAccess.reset();
    }
    else
    {
        mbStatus = false;
    }
}

if (mbStatus)
{
    ImplOpenChunk(PNGCHUNK_IEND); // create an IEND chunk
}

mbStatus est initialisé à true, donc pour passer à false c'est que vraisemblablement mpAccess = Bitmap::ScopedReadAccess(aBmp); // palette + RGB without alphachannel renvoie NULL. Est-ce le RGB qui pose problème sachant qu'on est à 1 bit par pixel ?

Alors ça veut dire quoi, que tous les sites en "free-quelque chose" risquent un procès maintenant ? Bin je suis dans la merde avec freeside.fr… En gros si je créais ma boîte avec ce nom, je risque un procès ?