Christian_B a écrit 6 commentaires

  • [^] # Re: La comm

    Posté par  . En réponse au sondage Doit‑on corriger les raccourcis de langage tels que « Linux » et « Mac » en « GNU/Linux » et « macOS » ?. Évalué à 1. Dernière modification le 27 novembre 2019 à 15:50.

    Tiens, s'ils pourraient m'expliquer comment décliner le latin en mode inclusif.

    Tant qu'à plonger allègrement dans le hors-sujet, allons au fond des choses. Le latin n'a pas besoin de mode inclusif car il a, comme beaucoup de langues, un genre neutre.

    Ces problèmes de "genre" en français et les complications peu viables du mode inclusif proviennent de l'absence du neutre en français, qui en fait une langue défectueuse (n'en déplaise aux académiciens).

  • [^] # Re: aridité technique

    Posté par  . En réponse au sondage Doit‑on corriger les raccourcis de langage tels que « Linux » et « Mac » en « GNU/Linux » et « macOS » ?. Évalué à -3.

    Ysabeau : "La seule intervention que l'on doit faire c'est, quand il y a différentes graphies dans un texte, d'uniformiser tout, par exemple initiale en capitale ou pas à Linux."
    Même pas. C'est le seul forum que je connaisse où on prétend "corriger" d'office des messages (et donc produire des faux), comme si les modérateurs étaient des rédacteurs en chef d'un journal ou d'un ouvrage collectif. C'est contraire au principe d'un forum et dans des cas moins anodins que ceux évoqués, cela pourrait même poser des problèmes de responsabilité légale.

  • [^] # Re: Certains raccourcis, oui

    Posté par  . En réponse au sondage Doit‑on corriger les raccourcis de langage tels que « Linux » et « Mac » en « GNU/Linux » et « macOS » ?. Évalué à -1.

    Je m'aperçois que mon commentaire est en partie problématique, mais je n'ai pas réussi à le corriger (-> page d'interdiction). GNU désigne en fait plusieurs choses, dont une licence (GNU GPL) utilisée par de nombreux logiciels et un ancien projet de système d'exploitation, qui n'a plus sous ce nom qu'un intérêt historique, ce que j'avais oublié.

    Mais cela ne change rien : d'accord avec ceux qui trouvent que pinailler sur la formulation des messages est sans intérêt et que vouloir imposer un vocabulaire normalisé est abusif.

  • [^] # Re: Certains raccourcis, oui

    Posté par  . En réponse au sondage Doit‑on corriger les raccourcis de langage tels que « Linux » et « Mac » en « GNU/Linux » et « macOS » ?. Évalué à -1.

    D'accord avec carabeo. Les deux questions n'auraient pas dû être posées en même temps.

    • GNU est la licence libre notoirement utilisée par Linux (noyau, nombreux composants et nombreuses applis) ainsi que d'autres logiciels sous divers systèmes. Pourquoi le répéter à chaque fois ? A ce compte là ou pourrait dire GNU/Bash, GNU/LibreOffice, etc. Lourd et inutile.

    • MacOS est en fait le nom actuel (simplifié) de Mac OS X, distingué subtilement de l'ancien Mac OS (en deux mots) selon Wikipedia. Ce n'est pas long à écrire. Qui dit Mac au lieu de MacOS ? En fait "travailler sur Mac" signifie "travailler sur un Macintosh", donc aussi le plus souvent sous MacOS sauf indication contraire.

    De toute façon corriger d'office un message qui est sous la responsabilité de son auteur me paraît discutable. Si un message n'est vraiment pas clair, il vaut mieux en faire la remarque dans une réponse. Sinon chacun s'exprime comme il veut.

  • [^] # Re: Passer à Gimp 2.10 maintenant? Correctif

    Posté par  . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 0.

    Petits correctifs :
    - Je voulais dire 32 bits par couleur, pas 32 bits par point
    - J'ai écrit Phososhop pour Photoshop

  • # Passer à Gimp 2.10 maintenant?

    Posté par  . En réponse à la dépêche GIMP 2.10.8 : Wilber Kid. Évalué à 0.

    Bonjour, Je vois que Gimp fait de grands progrès.
    Pour ma part, je me pose plusieurs questions sur l'opportunité de passer de 2.8 à 2.10 maintenant (avec Linux Mint).

    1) Flatpack : est-ce que ce système ne va pas faire démesurément grossir la partition système si de nombreuses applis l'utilisent ? Et aussi la place en mémoire dans le cas où plusieurs applis pouvaient utiliser les mêmes bibliothèques chargée une seule fois ? N'est-ce pas quasiment la fin des bibliothèques qui devraient alors être remplacées par des sous-programmes ou modules des applis ? Une bonne façon de gâcher la place disponible sous prétexte qu'il y en a de plus en plus ?

    2) Par conséquent peut-on espérer que Gimp 2.10 sera disponible par la suite en paquets Debian ? Sinon, je suis tenté de boycotter …

    3) Passer de 8 bits à 32 bits par couleur, n'est-ce pas passer du trop peu au trop ? Est-ce que les images ne seront pas 4 fois plus grosses en mémoire ? Sans compter que le système GEGL de modifications non destructives (certainement utile) prend sûrement aussi de la place. D'ailleurs ne diminue-t-il pas l'intérêt des 32 bits par point ? Cela fait un nombre extravagant de couleurs indiscernables (296 > 64 000 000 000 000 000 000 000 000 000). Le seul intérêt est d'éviter les erreurs cumulées lors de nombreuses modifications successives, mais à priori le 16 bits par couleur suffirait largement.

    4) Autre question. Est-ce que Gimp en a fini avec le système TSV de choix des couleurs. C'est le plus mauvais, pire que le TSL non pondéré. La "valeur" n'a pas grand chose à voir avec la luminosité perçue. Par exemple passer d'un bleu pur (forcément assez sombre) à blanc ne modifie pas V. :x Enfin, je ne sais pas si tous les outils l'utilisent. En tout cas les sélections (contigües ou non) par valeur sont désastreuses. Cela a-t-il changé en 2.10 ? Il faudrait une sélection par luminosité pondérée (comme Phososhop je crois).