barmic 🦦 a écrit 5212 commentaires

Je vais m'arrêter là c'est la discussion manque de hauteur pour être intéressante recherche "skeuomorphisme vs flat" tu y trouvera tous les arguments pour l'un et pour l'autre et des bonnes pratiques.

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

Je ne critique pas le flat design pour son style (moche à mon goût, mais bon, c’est secondaire), mais pour le fait que ses tenants l’accompagnent presque systématiquement de la suppression des couleurs.

Moi je trouve dommage de prendre le flat design¹ comme une critique en soit et de considérer les icônes comme pouvant être jugée en soit et pas dans leur manière d'être intégrée dans un tout.

Regarde gimp par exemple:

Tu as une large part d’icônes flat et toutes de la même couleur. Il y a pas mal de raisons pour l'expliquer que ce soit dans le panneau d'outils (où ils n'ont pas respecter le fait de mettre un libellé à coté pour de bonne raison), dans les menus ou dans les boites de dialogues. L'interface se pense comme un tout et il ne me semble pas pertinent de juger des icônes hors de l'interface.

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

Simplement, par exemple, quand je cherche l’onglet de LinuxFr, je le repère immédiatement du coin de l’œil à sa couleur dominante. Pareil pour Startpage, qui a des couleurs dominantes complètement différentes. C’est beaucoup plus rapide que de détailler chaque icône, ce qui est indispensable si seule la forme diffère.

Là tu parles de couleur et pas d'être flat ou pas. Mais les favicon sont pas vraiment contrôlables et tu parle ici en multi site, ce n'est clairement pas maîtrisable de la même manière qu'un jeu d'icônes d'une application.

Beaucoup d’interfaces flat s’accompagnent d’icônes monochromes stylisées (certaines assez compréhensibles et d’autres pas).

cf: les 2 premiers commentaires du thread en cours. C'est aussi possible en non flat.

Là dessus, les anglais ne font pas comme nous[…]

C'est intéressant mais ça n'a aucun rapport. Leur sens interdit est en flat et je n'ai pas essayé mais je ne crois pas que l'excuse "j'ai du mal avec le flat design" marche devant la justice.

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

Quelque soit l'autorité que tu invoquera, les discours alarmistes sur la vaccination concluant au désastre après 6 jours du début de la vaccination sont profondément problématiques et montrent qu'après 10 mois celui qui porte de tels propos n'a pas compris qu'ajouter de la cacophonie à la cacophonie est problématique.

Tu base une partie de ton avis sur sur des "on dit" ("j'ai entendu le 31/12…").

Il va bien falloir un jour se calmer et prendre du recul sur les données que l'on a et être un peu empathique. Avoir peur d'un médicament ce n'est pas être anti-vax par exemple.

Avoir des critiques c'est bien et il en faut, mais ce n'est pas ce que l'on trouve dans le billet de blog. Il n'a de vocation que politique et n'a pas pour objectif la moindre construction.

Si seulement il pouvait copier l’organisation de la vaccination sur l’Allemagne… Quand on est nul, on peut au moins avoir l’intelligence de copier ceux qui savent faire.

Parce que toi tu sais mieux ? T'es mieux informé ? Etc La vaccination là bas je ne sais pas si elle se passe mieux ou pas (et je m'en fou), mais le s'appuie sur l'organisation fédérale du pays par exemple.

Il faut accepter que l'on ne sait pas tout et modérer son enthousiasme et sa colère avec cela, comme il faut aussi prendre du recul et considérer les propos de chaque porteur d'intérêt non pas comme parole d'evengile, mais comme une information supplémentaire.

Bref garder de l'humilité et éviter de rendre les sujets partisans (quand tu attaques directement l'intelligence de ceux qui ne décident pas ce que tu souhaites par exemple).

Je continue à lire, mais c'est mon dernier commentaire. J'ai dis le gros de mon point de vue, je ne connais pas plus la question.

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

A moins d'une semaine du début utiliser ce titre avec si peu d'info… C'est un polémiste. Il n'y a pas de raison de plus y accorder d'attention que ce que tous les autres polémistes peuvent affirmer.

Se présenter en sous-titre de son blog comme chercheur sans plus d'indication alors qu'ici il fait un signe un billet qui n'est ni scientifique, ni même du journalisme, mais uniquement de la polémique alors qu'il est engagé politiquement. C'est gonflé et loin d'être à la hauteur d'un chercheur. Il est fier d'avoir une longue liste de titres honorifiques, mais on a en vu d'autres en 2020 se targuer d'un tas de titres et affirmant des énormités. Ça n'est pas un argument.

Des arguments il y en a très peu et je te rejoins sur le coté ordurier de ce billet qui considère le consentement comme une lourdeur administrative… que dire de plus ?

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

Tu ne sais pas te repérer sans reflets ? Les icônes devraient ne pas trop s'appuyer sur les couleurs pour des questions d'accessibilité.

Le fait d'être flat ou pas ne change rien. On arrive à lire les panneaux de circulation, ça devrait mettre la puce à l'oreille.

Pour les couleurs je pense que ça peut être intéressant pour ne pas trop multiplier le nombre de couleurs et pouvoir mieux mettre en évidence autre chose avec la couleur. D'ailleurs les icônes monochromes sont souvent colorables. Le développeur peut choisir d'afficher chacune dans la couleur qu'il souhaite. Ça peut servir à donner une signification aux couleurs (rouge pour la suppression et perte d'information,
gris pour une action pas accessible,…). Encore une fois il ne faut pas s'appuyer uniquement dessus.

Ce sont des questions de goût amha.

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

Tout à fait les icônes servent à se repérer plus facilement dans l'espace et à se repérer plus vite avec l'expérience.

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

C'est triste que xmpp n'apparaisse pas dans le coin. Je n'utilise pas donc je ne pourrai pas en parler, mais sur un site qui se fait le relais d'une dépêche mensuelle sur l'actualité du protocole et dont 2 membres sont des développeurs connus du monde xmpp, ça me paraît dommage que ça ne soit pas paru évident.

On pourra d'ailleurs remarquer comment toutes les solutions présentées travaillent dans leur coin plutôt que de tenter de s'organiser autour d'un ou 2 protocoles (pas forcément fédérés).

Mon point n'est pas de culpabiliser, mais de faire remarquer que si xmpp ne paraît être évident sur linuxfr, la popularisation du protocole est encore loin.

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

HTML/CSS, avec lesquels créer un simple layout de type header, menu latéral, footer, relève de la gageure, la ou c'était censé être simple.

Alors non c'était chiant, mais ça ne l'est plus particulièrement. Ceux qui font des choses complexes pour ça :

• ne se sont pas mis à la page en CSS
• font plus que ça (gérer l'affichage sur téléphone portable par exemple)

Mais avec CSS3 (en particulier avec flex et grid) et pour ce qui est supporté par gecko, webkit et blink c'est simple. Si tu regarde ça par exemple : Full-Bleed Layout Using CSS Grid, ça ne me paraît pas être un code particulièrement compliqué et le même résultat en qt ou gtk ne sera pas particulièrement plus simple. Il faut connaître la techno oui c'est sûr.

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

Ok. Donc, les watchdog, ça sert à rien, revenons à sysVinit (parce que oui, l'intérêt majeur de systemd (et d'autres) est bien de proposer un mécanisme de watchdog logiciel). Quand ça crash, on fait un déplacement (allez, 300 bornes, c'est rien…) et on fait un rapport de bug ou on patche, en espérant qu'il n'y ait plus de freeze.
En fait, même les containers, ça sert à rien: s'il y a une faille, on fait un rapport de bugs et/ou corriger le problème.

Wow tout doux. Sans même avoir à parler d'implémentation. Comment un système peut déterminer qu'une application doit avoir une interface graphique ou non ? Comment ce dernier peut interagir avec elle ? Et enfin pour lui dire quoi ?

Si tu veux ce genre de choses il faut :

1. mettre en place une description de ce qui semble être un comportement normal ou non de ton appli
2. mettre en place un protocole pour interagir avec ton appli¹
3. décrire comment on utilise ce protocole²

Et le gain c'est éviter d'avoir à tuer toi-même un processus ? Et espérer qu'une application dont l'interface graphique est stuck ne sera pas tout aussi bloquée sur son autre interface ?

Perso, ma solution dans ces cas la, c'est d'essayer de revenir a du moins accéléré, moins performant, plus cher (en temps immédiat de dev) mais plus simple, plus maintenable et plus fiable (en gros, du KISS, qui a un réel coût).

Non de ce que tu décris tu as utilisé une solution ad-oc pour un besoin précis. Ce qui est très bien. Pousser cette rigueur pour tout le monde va être dramatiquement plus complexe :

• il faut que la solution soit généralisation, qu'elle mette tout le monde d'accord³
• il faut que ce soit implémenté dans les WM, par les bibliothèques graphiques et par les appli (gtk/qt ne peuvent pas deviner si c'est normal ou non de ne plus avoir de gui)

Tout ça pour une solution qui ne pourra pas gérer tout tes cas. Je ne vois pas ce qui pousserait une appli buguée à ne pas l'être sur une autre interface. Sachant qu'avec les signaux elle peut déjà faire pas mal de choses. Mais par contre tu complexifie encore ce qu'est une application graphique ce qui augmente les bugs potentiels.

C'est une solution de merde, clairement, mais pas trop eu le choix (compte tenu des impératifs de temps, le client était vraiment pas content d'avoir des trucs qui bugguent tout le temps, et le patron était pas fan non plus: il fallait du simple, qui juste marche).

Je n'en sais rien si c'est mal ou pas. Si ça fonctionne pourquoi ce serait si mal. Il semble que chez toi les navigateurs leaks des processus et ou ton pilote graphique/X11/les bibliothèques graphiques plantent en boucle ce n'est pas ce que j'observe. Je ne remet pas en cause ce que tu dis, mais ça ne me paraît pas la norme.

Mais quand j'ai besoin de fiabilité élevée, je met en place des solutions ad-oc et je sais qu'on ne peut pas la construire pour moi (ça ne remplirait probablement que partiellement mon besoin et tout le monde n'a pas à se plier à mes besoins).

Note: tout de même que quand je parle de remonter un bug (et en faire le suivi) ou un patch ce n'est pas une parole en l'air. Quelque soit le système c'est une étape de dernier recours. Ça ne doit pas arriver. Ce n'est pas parce que j'ai un extincteur que je m'en fou de mettre le feu.

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

Bref, je présume que du coup la gestion du processus remonte jusqu'à PID1? Ou y-a-t-il un processus avant qui récupère la parenté

C'est forcément l'init qui récupère ça.

éventuellement maintiens (je ne sais pas si c'est possible) la garantie qu'il est possible d'interagir avec la-dite application?

Ça veut dire quoi maintenir une interaction possible ? Ton programme ne veux plus réagir, on ne peut pas l'y contraindre. A lui d'avoir différentes interfaces si nécessaire (graphique, dbus, une socket unix ou tcp, un pipe nommé,…).

Honnêtement, je ne sais pas ce qu'il est possible de faire dans ce domaine, mais je me pose de plus en plus la question de la fiabilité des applications interactives: comment réagir en cas de problème (race condition, "perte" d'affichage graphique, etc)?

Tu demande comment faire pour qu'une application buguée réagisse bien ? Remonter un bug ou un patch.

Quelles solutions techniques théoriques et pratiques y a-t-il actuellement?

Balancer un signal. Si le processus a prévu un handler c'est cool sinon ça te permettra de le tuer.

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

Ou bien l'utiliser pour voir ce qui manque dans OSM ?

Hein ? Tu achète un garmin pour connaître les manques d'osm et les reporter dans osmand ? C'est farfelu et tout à fait inutile.

Personnellement, j'ai tendance à faire sans GPS, c'est plus amusant (similaires aux géo caches mais en plus utile), ça fait travailler la cognition spatiale ce qui doit être bon contre la maladie d'Alzheimer,

C'est une référence à la vieille manie "dis moi ce dont tu as besoin et je te dis ~comment~pourquoi t'en passer" ?

ça vide moins les batteries.

C'est l'inverse amha. Ce qui consomme de la batterie c'est l'affichage de la carte et tu la manipule bien plus quand tu t'en sers sans GPS (et potentiellement plus longtemps). D'autan que l'on parle de matériel qui ne sert qu'à cela donc ça n'a pas vraiment de sens.

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

Il est possible d’avoir des cartes à jour du monde entier

OSM n'est à jour que dans certains endroits au gré des contributions. Tu le vois au volume des cartes. L'Allemagne et la France sont bien cartographiées par exemple, mais ça n'est pas le cas partout. Tupeux contribuer, mais pour les endroits vraiment mal cartographiés tu connaîtra suffisamment le lieu pour ne plus avoir besoin de GPS avant d'avoir fini. Bref regardez le contenu d'OSM avant d'acheter.

Pour ceux qui seraient génés de ne pas payer un centime pour une cartographie à jour

Il est aussi possible de donner de l'argent. https://openstreetmap.assoconnect.com/billetterie/offre/61684-j-faites-un-don-a-openstreetmap-france

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

Aaaah. Je viens (peut-être?) de comprendre. En fait, tu voulais me parler de l'ordre inverse (tu vois, quand je disais que d'indiquer l'ordre clairement, c'est important!):

C'est ça ! (mais l'ordre est indiqué é_è)

Si tu dis: je multiplie par 2 toutes les valeurs, ça ne dépend pas de la plage.

C'est toi qui est passé de « je divise par 2 je multiplie par 2 en 8 bits » à «  je divise par 4 je multiplie par 4 en 9 bits ». J'ai mal compris ton premier commentaire, comme tu as commencé avec *2/2 et que tu as ensuite fait *4/4 j'ai pensé que tu avais modifié aussi les opérations en changeant de codage.

Ensuite tu as tout de même raison que dans ton cas extrême, tu perds quand même énormément de couleurs.

Yep c'est bon j'ai compris.

Enfin, il faut voir que cela reste des exemples extrêmes que tu nous sors

Tout à fait. Je suis ne mis connaît que très mal en manipulation d'image. C'est purement l'aspect mathématiques (et comprendre son fonctionnement dans la vraie vie) qui m'a titillé. Gimp 2.8 n'avait pas de problème de cet ordre c'est bien que ça n'arrive pas si souvent. Je présume que c'est ce qu'on trouve quand on laisse un paramètre de la fonction mathématiques à l'utilisateur et qu'il s'amuse à aller au bout de la plage de valeur qu'on lui donne, mais là c'est charge à l'utilisateur de correctement utiliser l'outil.

Donc ton exemple, bien qu'extrême, reste en plein dans le mille et montre bien ce qu'est l'édition raster.

Merci :)

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

P.S.: les flottants ont aussi un gros avantage qui est de pouvoir aller sous zéro et au dessus de 1.0. Puisqu'on rappelle que le min et max sont juste un choix arbitraire, les couleurs hors de cette plage sont des couleurs tout à fait valides. Simplement elles ne sont pas autorisées dans l'espace de couleur en cours ("hors gamut"). Mais il est super intéressant de pouvoir les garder jusqu'au bout parce que — qui sait — certains effets ramèneront peut-être la couleur des pixels hors-gamut à l'intérieur. Or supposons qu'on ait tronqué les couleurs plus tôt, ben là encore, on a mis plein de couleurs à la même couleur trop tôt et donc perdu énormément de précision (i.e. bandes de couleurs, etc.). Alors que si on les garde jusqu'au bout, on a une chance de garder la précision (on ne tronque qu'au moment de l'export).

Hum en flottant la précision de tes opérations mathématiques baisse beaucoup. Tu as une approximation qui est faite à chaque opération. Pour ce qui est de la plage, je comprends donc que lorsque l'on utilise les flottants on utilise une toute petite partie on utilise de [0; 1.0] pour représenter les couleurs visibles au sein d'une plage de valeur allant de -126 à 127. Ça évite le problème dont je parlais pour d'écrasement.

C'est à ça que servent les calques d'effet notamment[…]

D'acc je comprends. J'ai pas compris si ça existe dans gimp ou si ça va exister ?

Euh… je comprends pas du tout tes maths là. Bon déjà quand on fait des maths en informatique, on perd l'associativité, donc faut mettre des parenthèses (c'est à dire que (255 / 2) × 2 = 254 mais (255 × 2) / 2 = 255 en calcul entier, sans perte de précision dans cet ordre!) sinon je comprends pas là où tu veux en venir.

Euh… Le numérateur se calcul avant, il n'y a pas besoin des parenthèses avec la représentation que j'utilise.

Mais surtout, ils sortent d'où tes 128?

Excuse-moi je me suis dis après coup qu'il falait que je détail et puis j'ai validé trop vite. Je vais utiliser une représentation en ligne pour m'aligner sur ta façon et détailler. On est en 8bits donc avec des valeurs de 0 à 255.

(255 * 2) / 2 = 255 / 2

Tu ne peux pas représenter de valeur au dessus de 255 donc je présume que toutes les opérations sont toutes calculées en prenant le minimum entre la résultat et la borne haute et le maximum entre le résultat et la borne basse. Si ça n'est pas le cas c'est que l'overflow est laissé tel quel est ça donne

(255 * 2) / 2 = 254 / 2 → c'est à dire 510 mod 256

Par contre il y avait une erreur dans mon calcul ça donne dans les 2 cas 127 et pas 128.

En supposant que tu essayais de reproduire mes exemples où tu fais la division d'abord.

J'ai volontairement inversé les opérations pour dépasser la borne haute sans supposer qu'il s'agissait de la même opération que toi.

Je ne vois aucun problème particulier dans tes exemples.

Mes exemples visaient à montrer que quelque si ton gammut (si j'ai bien compris) correspond aux bornes de ta représentation toute multiplication va avoir des conséquences problématiques. Tu va overflow ton entier et tomber sur une valeur que ta représentation ne sait pas représenter (je parle bien de l'aspect mathématiques). Ça n'est pas pire en 9 qu'en 8bits. Tu as répondu à cette question en parlant plus haut du codage flottant qui n'utilise qu'une toute petite parti de l'espace pour code le gammut.

à propos, note que j'utilise 9 bits pour l'exemple car ça permet un exemple simple où tu multiplie ta plage pour 2.

Tout à fait c'est la manière de passer du 8 bits à une autre représentation qui m'a intriguée.

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

D'abord transformons nos valeurs dans le format de travail 9-bit:

Juste au cas où pour améliorer ton explication, cette transformation m'a fait tiquer au premier abord. 2 reste 2 en 8, 9, 16, 32 ou 1 millions de bits normalement. Ici les valeurs sont réparties. On pars d'une plage de [0; 256[ et on arrive à [0;512[ on multiplie par 2 pour laisser un espace entre les couleurs. Comme tu le montre il faut retraduire toutes les opérations pour ce format. J'imagine que c'est pour ça qu'avec GEGL vous travaillez exclusivement en 32bits si j'ai bien compris. Comme ça les opérations n'ont pas à être implémentée pour tous les encodages possibles de couleur.

• 
• 

Là c'est même pire que tout, on a carrément deux opérations qui auraient dû s'annuler mais qui à la place ont juste fait perdre des couleurs. Ça veut notamment dire que tous les 3 de l'image ont d'ailleurs disparu (en fait tous les nombres impairs dans cet exemple), on a vraiment perdu en précision !

J'ai l'impression que cet exemple montre surtout qu'il faudrait n'appliquer les opérations qu'au moment de l'export et utiliser une résolution des opérations "intelligente". C'est j'imagine très compliqué car les pixels ne sont souvent calculé en groupe. Donc chaque pixel devient non plus 3 valeurs, mais un système de 3 opérations qui sont perpétuellement recalculés pour l'affichage. Ça rend caduque toutes les formes d'optimisations classiques à coup de SIMD par exemple.

Par contre ça me pose une dernière question. Utiliser le codage 9bits que tu décris n'est pas exempte de problème. Si je reprend tes opérations, mais dans l'ordre inverse (et avec d'autres valeurs), sur 8 bits :

Sur 16 bits :

128 en 9bits donc 64bits en 8bits. Ici ce n'est même plus une perte de précision ça a annihilé la moitié de la plage de couleur. Pour gérer ce genre de cas de manière total il faudrait que les entiers soient représentés en taille arbitraire (ou à minima que ce soit le cas lorsque l'on détecte un overflow), mais ça casse encore toute optimisation… Pou mitiger un peu ces problèmes est-ce que la représentation 32bits utilise toute la plage ou est-ce que ça n'utilise pas qu'une partie ?

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

Que des non connaisseurs puissent se poser des questions avant une études ça ne me paraît pas choquant. C'est en se basant sur des études qui, j'espère, s'appuient sur des connaisseurs plutôt que sur des aprioris de béotiens qu'il est possible de prendre des décisions éclairées. Je ne pense pas qu'insulter l'intelligence de quelqu'un qui demande à en savoir plus soit pertinent. Oui ça demande de l'argent de s'informer.

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

Pourquoi cette obsession à vouloir me faire dire tout le contraire de ce que j'écris ? Je m'exprime probablement en marsien ?

Quand je lis :

Du coup je vois d'un mauvais œil quand c'est par le logiciel qu'on veut me faire jeter un truc qui tourne encore bien.

J'entends que tu reproche à celui qui est responsable de la partie logicielle qui ne marchera plus et c'est IdentCA qui a décidé de rendre son certificat invalide. Encore une fois je ne te reproche rien, car le logiciel ici c'est 4 acteurs : Google via android ou aosp, ton constructeur via sa surcouche, LE via ses certificats et IdentCA avec son certificat racine. Il me semble intéressant de préciser la chaine de responsabilité vu que tu la voie d'un mauvais œil.

Donc non je ne dirais pas que c'est du "marsien", juste que ça me semblait manquer cruellement de précision.

Les certificats LE pourraient même être valides une semaine ou un seul jour que ce ne serait pas de l'obsolescence programmée.

La loi française décrit l'obsolescence programmée ainsi :

Art. L. 213-4-1.-I.-L'obsolescence programmée se définit par l'ensemble des techniques par lesquelles un metteur sur le marché vise à réduire délibérément la durée de vie d'un produit pour en augmenter le taux de remplacement.

À moins de chercher à expliquer qu'un certificat n'est pas un produit ou qu'il n'y a pas de marché de certificat ça me paraît correspondre. Ça n'est pas pour autant un reproche.

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

Mais Apple a montré qu'il est possible de faire largement mieux car l'upgrade est géré.

Je trouve au contraire qu'ils ont montré que c'était compliqué. Pour faire ça ils font des optimisations qui demandent à maitriser toute l'intégration OS/matériel (comme le fait de brider pour sauver la batterie). C'est évidement empiré par le fait que chaque constructeur va plus ou moins avoir sa couche pour se dissocier de google ou se démarquer des autres.

Je trouve plutôt qu'android devrait être fait pour durer. Des mises à jour de sécurité distribuées sur play et un support de sécurité de plusieurs années. Je ne suis pas l'actualité mais de ce que je suis entrain de regarder une grande partie des nouveautés de chaque version n'est que des mises à jours logiciels.

Je ne vois pas plus de problème au fait que les gens utilisent KitKat qu'au que d'autres utilisent RHEL 6 sorti en 2011.

J'ose espérer qu'IdenTrust renouvellera pour 3 ans de plus; et je ne vois pas de problème de confiance, c'est un choix […]

La solidité de SHA1, des clefs RSA 2048bits et d'autres algos ça n'est pas une question de choix. C'est pas comme si ça faisait 15 ans qu'on parle des problèmes de SHA1… DST Root CA X3 a était édité en 2000 avec les méthodes des années 2000. Il n'est pas acceptable de continuer à l'utiliser indéfiniment.

et surtout Google et compagnie peuvent décider de refuser sur machine plus moderne si ils ont peur, bref tout est faisable.

Ça signifie créer une exception pour accepter directement ISRG root X1 sans valider son signataire, c'est sans doute possible mais si on arriver à minimiser les exceptions de ce genre (il y en a déjà en cours pour des certificats sortis des trustores, mais qui sont utilisés par des services considérés comme trop importants pour être inaccessibles). Ça participe à réduire le niveau de sécurité et les attaques sont généralement de cet ordre : on utilise différentes choses qui chacune réduit pas suffisamment le niveau, mais qui bout à bout finissent par rendre le tout fragile.

Bref, il va falloir sérieusement discuter (car les constructeurs seuls ne feront rien) développement durable si on veut éviter tous ces déchets…

Ah on va pas te proposer des téléphones au même prix s'il faut maintenir une équipe de développeurs quelques années dessus même si elle n'est pas dédiée au téléphone en question. Il faut multiplier ce genre de situations :) Jusqu'à ce qu'une solution émerge pour de bon.

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

En plus, ça pourrait réduire la confiance des systèmes dans leur gestion des certificats.

C'est fait en accord avec les auditeurs, je pense pas qu'il y ai de problème.

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

Du coup je vois d'un mauvais œil quand c'est par le logiciel qu'on veut me faire jeter un truc qui tourne encore bien.

Encore une fois ce n'est pas la faute des autorités de certifications. Des certificats ça vie et ça doit évoluer. Ça ne fais que révéler ce que ton constructeur ne fait pas.

Je ne dirai pas non plus que LE fait de l'obsolescence de leur certificat

C'est ce qu'il fait. Ça n'est ni un avis, ni un reproche de ma part. Les certificats émit par LE sont valables 3 mois. Ils le font pour de bonnes raisons, même si je ne doute pas que ça puisse être débattu.

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

Idéalement, il faudrait faire un sondage pour savoir si la chose serait bienvenue.

Un ticket c'est fait pour ça. Ça permet de connaître l'opinion des développeurs et de garder les discussions pour l'avenir (si dans l'avenir quelqu'un se repose la question, il pourra le retrouver facilement et si les arguments changent ça pourra être fait en connaissance de cause).

Le bug tracker de gimp est ici. Il y a un label featue qui me semble tout indiqué pour ça.

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

la non prise en charge d'une profondeur de couleur de 16 bits. Je sais, ça ne sert à rien et ça fait des fichiers énormes, mais lesdits photographes ne sachant pas régler l'exposition à la prise de vue, ils espèrent pouvoir rattraper les détails dans les ombres en post-traitement…

Je sais pas si 16 bits ça sert à rien mais depuis gimp 2.10 et l'intégration de GEGL il est possible de travailler en 16 ou en 32 bits (GIMP 2.10 roule au GEGL > Haute précision des couleurs). Je crois que gimp a mis du temps à y passer non pas parce que ça n'a pas d'intérêt mais parce qu'ils voulaient le faire via GEGL.

Pour l'exif je ne sais pas.

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

Hum, on attends tes contributions pour payer les sysadmins de mageia a mettre à jour des machines non critique de l'infrastructure…

Ça questionne tout de même la durée de vie des versions si elle est trop courte même pour le projet, non ?

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

C'est un bot qui génére ces commentaires sur rust ?

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