Ca ma rappelle les paquets flatpak qui traînent sur le web: des jeux windows crackés qui tourne avec une version de wine fournis dans le paquet. Ou comment flatpak est devenu le vecteur de distribution de jeux piratés sous Linux :-)
Je connaissais pas du tout cette histoire. Du coup j'ai cherché après ton message, et… effectivement!
C'est quand même vachement marrant.
Comme le note le premier commentaire sur reddit: sans parler du fait de cracker des jeux, c'est quand même une grosse victoire pour flatpak (en terme d'adoption du système).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Alors "bas de gamme", c'est vite dit. C'est simplement l'une des reliures professionnelles parmi les plus répandues dans le commerce. Ensuite une fois fini, ça a vraiment l'avantage de faire pro et nickel, même si fait artisanalement (comme était le cas de cet exemplaire). Une reliure au dos collé bien faite, franchement, ça rend bien (il faut voir celle du bouquin fait par Aryeom, on croirait qu'il vient de l'imprimeur).
Alors certes, on voit toutes sortes de "reliures d'art" sur Youtube (c'est pas forcément une référence), comme tu dis. Tout le monde y va de son tuto. C'est clair que ça fait plus classe de dire qu'on fait une "reliure japonaise" qu'une "reliure collée". J'ai vu des ateliers par dizaines pour faire de la reliure japonaise et jamais pour de la reliure collée. En fait Aryeom est la première personne que j'ai rencontrée qui faisait de la reliure collée sur des livres faits-mains. Ben franchement à chaque fois que je vois le résultat, je suis épaté. C'est pratique, c'est classe, classique et simple, et ça se fait pas remarquer. Ben perso c'est tout ce que je demande à une reliure.
Le fait que ce soit plus simple et moins cher à produire, ce qui est sûrement la raison pour laquelle tu l'associes à du "bas de gamme" ne sont pour moi que des avantages additionnels, pas des inconvénients.
Je sais pas si tu as déjà vu une reliure japonaise (qui d'ailleurs — même si aussi utilisée traditionnellement au Japon — serait plutôt une reliure chinoise historiquement, mais ça fait juste plus "classe" de dire "reliure japonaise"; enfin je suppose que c'est la raison de l'emploi impropre de l'origine japonaise partout où c'est cité), mais c'est bien moins pratique (en particulier vraiment beaucoup de perte d'espace) et c'est très visible (ce qui peut être un choix design).
C'est orienté magazine pas trop épais
Bien au contraire, la reliure collée est très adaptée aux livres épais.
livre de poche (et encore…)
Ben si, la plupart des livres de poche sont avec dos collé. Pour info, je viens de sortir un recueil de plusieurs romans de Herman Hesse en version poche de ma bibliothèque. Comme attendu, il est aussi avec reliure collée et fait quasi 2000 pages.
Ah et encore une fois, perso je n'associe même pas "livre de poche" à bas de gamme, même si c'est ce que beaucoup d'éditeur essaient de donner comme image (simplement car ils veulent vendre le même livre plus cher). Il se trouve que je préfère les poches. C'est plus facile à transporter, moins lourd, moins chiant. Et la grosse couverture en dur, je m'en passe vraiment avec grand plaisir au profit d'une couverture souple (qui sera tout de même dans un papier un plus épais) plus maniable.
Ensuite c'est une question de goût (certains préféreront les gros livres avec gros caractères, etc.) mais pas si nettement de "gamme" pour moi.
Les feuilles finiront par se barrer.
Bien sûr, c'est plus facile qu'avec une reliure cousue, mais j'arrache pas non plus une feuille de mes livres de poche tous les 4 matins. Ensuite, je sais pas pour toi.
Voilà. Tout ça pour dire que je ne dis pas que tu as entièrement tort. Bien sûr que les livres aux reliures cousus sont plus solides et donc plus "pérenne" dans le temps. Mais ça n'en rend pas pour autant les reliures collées comme une technique à dédaigner (sinon ça serait pas utilisé massivement dans l'industrie du livre). Et si on devait monter en solidité vraiment, je conseillerais d'ailleurs les sections cousues puis collées (l'autre méthode de reliure très répandue, celle qu'on voit le plus souvent pour des livres à couverture dure, ou pour des manuels, etc) et pas les "reliures japonaises chinoises".
Dans tous les cas, si quelqu'un s'intéresse au sujet, faut savoir ce qu'on veut: du hype ("reliures japonaises chinoises" et autres "reliures d'art" hype) ou des reliures pratiques et qui savent se faire oublier (collée, ou cousu par section puis collé) pour relier de vrais livres qu'on veut imprimer pour soi (et pas juste faire un effet démo). Bien sûr que les techniques dites "d'art" sont cools aussi. Je dirais que c'est à utiliser si tu veux faire un livre "exotique" où le fait d'avoir une reliure bien visible est un choix design. Mais ce n'est pas mieux. Perso le fait que la reliure puisse ne pas se faire remarquer dans un livre est un choix très valable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ah effectivement je me rappelle d'un email comme ça! Désolé, je suis un peu à la ramasse sur ces trucs (j'en ai en fait plusieurs des emails similaires, des gens qui me donnent un autre angle pour obtenir des donations/subventions) parce que ça me prend tellement de temps et que ça me désespère car j'ai déjà un peu tout essayé (même la SACD). Alors j'avoue que je mets parfois cela en backlog pour privilégier mon temps de développement.
Mon idée n'était pas de pas répondre (j'essaie de répondre à tous les emails), mais de "répondre dans quelques jours", et puis j'ai oublié! Désolé!
En plus c'est sûr que si tu as un contact, c'est idiot de pas retenter!
Bon je retrouverais ton email et te répondrai!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
D'ailleurs, je m'étais inscrit sur Tipeee exprès pour ZeMarmot et j'avais vu qu'on pouvait faire des dons uniques : est-ce pareil avec Liberapay ?
Réponse simple: non.
Réponse compliqué: oui.
Explication de la réponse compliquée: c'est ce qu'a expliqué Jarvis, plus haut:
En fait avec liberapay, tu dois remplir un porte-monnaie virtuel (par exemple 10€), et après tu choisis la fréquence et le montant de ton don. Donc si tu n'as plus d'argent dans ton porte-monnaie, il n'y a plus de virement.
Ce que cela veut dire, c'est que tu peux remplir ton "porte-monnaie" avec 10€ par exemple, et faire un don récurrent de 10€. Cela videra alors ton porte-monnaie d'un coup (dès la première semaine), puis s'arrêtera là, jusqu'à ce que tu réapprovisionnes éventuellement ton compte.
D'après ce que j'ai compris, Liberapay ne tente pas de se re-servir sur ta carte et attend que tu fasses l'action explicite.
C'est aussi la façon dont Liberapay arrive à baisser les frais bancaires au passage, puisque cela incite les gens à remplir leur "porte-monnaie Liberapay" avec des plus gros montants qui seront ensuite progressivement vidés en donations hebdomadaires. Donc sur un plus gros montant, les frais fixes en particulier deviennent moins significatifs. Par exemple, je vois dans leur FAQ que les frais cartes sont de 2,106% + 0,21€. C'est sûr que si tu donnes 1€ par semaine et qu'à chaque fois, ta carte est débité (donc les frais se reproduisent toutes les semaines), ben tu as 4,2% de frais bancaires. Mais si tu as rempli ton porte-feuille une fois disons de 10€, alors les frais fixes sont minimes proportionnellement, et tu as eu des frais bancaires de ~ 2,3%.
Sur Tipeee/Patreon, comme ils ne font pas cela et qu'en plus y a des frais de plateformes, dans les faits, les frais sont en général autour de 10% de moyenne. C'est variable, car ça dépend du montant donné, du moyen de paiement du donateur, mais aussi du nombre de projet auquel chacun donne, puisque c'est le moyen utilisé par ces plateformes pour diminuer les frais fixes en débit unique avant répartition. Mais cette approximation de 10% est plutôt juste dans notre cas pour Tipeee/Patreon.
(je sais que vous préférez pour des questions de visibilité les dons récurrents, désolé)
En fait, ce n'est pas si binaire. Perso je suis partagé. J'aime bien la visibilité des plateformes par "l'appel d'air" généré. En gros, plus y a de dons visibles, plus de nouveaux sont prêts à donner. Ce n'est pas idéal, voire un peu injuste, car cela rend clairement l'arrivée des nouveaux plus difficiles (et je m'inclus dedans) car on doit finalement bien plus se prouver que ceux bien établis (le seul fait d'avoir déjà une énorme base de mécènes fait boule de neige; même si bien sûr, ce n'est pas suffisant en soi).
Mais cela ne m'empêche pas d'apprécier le fait qu'un gros don déjà génère moins de frais bancaires/plateformes, et puis pourquoi attendre en recevant le don au compte-goutte?
Ensuite y a encore l'argument courant qui est que beaucoup d'associations aiment plein de petits dons récurrents car c'est moins sujet à variation donc cela permet de plus prévoir sur du long terme. En effet recevoir de très gros dons un mois donné ne signifie pas que l'on recevra autant les mois suivants. On peut tout à fait avoir un générateur très généreux qui donne 5000€ une fois, puis l'asso reçoit quasi rien les mois suivants. Donc cette grosse donation ne serait pas significative du budget de l'association au final. Alors que si on reçoit 1€ de 5000 donateurs en récurrent, cela fait aussi 5000€ mais bien moins sujet à variation (on peut avoir un certain pourcentage de donateurs en plus ou en moins d'un mois sur l'autre, mais en général, les donations récurrentes ne varieront pas du simple au décuple) et donc dans ce cas hypothétique on pourrait en déduire une moyenne des donations d'environ 5000€ par mois. Néanmoins cela ne signifie absolument pas qu'une association préférerait ne pas avoir la donation simple pour autant. C'est simplement une variable moins prévisible, c'est tout (mais une bonne variable! Pas une mauvaise!). :-)
Conclusion: absolument inutile de s'excuser. Au contraire, c'est nous qui te remercions d'aider à faire vivre LILA et le projet ZeMarmot!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Si on veut faire des choses puissantes, y a GEGL qui est vraiment pas mal aussi.
Ce n'est pas que le moteur graphique de GIMP (librairie C), on peut aussi créer des transformations simplement en ligne de commande, et côté web par exemple, un contributeur a créé imgflo au dessus de GEGL, qui est utilisé par une entreprise (The Grid) pour du traitement d'image sur le web.
Le README dépôt de imgflo-server notamment donne une bonne idée du système, avec une API HTTP pour traiter des images par graphe, etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je pense qu'il faut voir les choses des 2 côtés de manière réaliste:
Oui, te demander de compiler GNOME directement serait idiot et irréaliste (même moi je saurais pas par où commencer pour compiler GNOME). Si quelqu'un t'a demandé cela de manière abrupte et en première réponse à un rapport de bug, alors il n'a pas été très malin.
Cependant les développeurs sont aussi des humains comme les autres, et surtout ils ne sont pas omniscients. Et des fois, sur certains bugs, on est aussi perdu que n'importe qui d'autre (au début en tous cas). Et ce d'autant plus si on n'arrive pas à reproduire le bug, ni à imaginer/comprendre sa raison. Dans ce cas, on peut espérer que si on le reproduit pas, c'est parce qu'il a été corrigé (exprès ou par chance) entre la version du rapporteur et celle du dépôt. Donc, à tout hasard, on peut se retrouver à demander au rapporteur s'il a l'opportunité de pouvoir tester sur la version du dépôt. Il y a diverses façons où cela peut être possible, et pas forcément en compilant. Par exemple certaines distributions ont des paquets de versions de développement (qui ne seront pas forcément le commit du jour, mais au moins une version plus récente). Et puis aussi le logiciel libre est plein de développeurs et quand quelqu'un rapporte un bug, on ne sait pas forcément à qui on a affaire. On peut espérer que le gars en face se trouve justement être un gars capable de compiler le logiciel, peut-être même l'a-t-il déjà fait. Ça ne coûte rien de demander.
En gros, si on t'a demandé cela, cela ne signifie pas forcément que le développeur s'attendait vraiment à ce que tu puisses le faire, mais simplement il était peut-être juste perdu lui-même et il a tenté l'improbable en te demandant, juste au cas où… Peut-être aussi ne l'a-t-il pas fait de manière très diplomate (on n'est pas tous bon diplomate, d'autant plus que beaucoup de dévs emploient aussi l'anglais en seconde langue eux-même; donc pas mal de choses peuvent se perdre dans une double traduction lang1 -> anglais -> lang2).
Ensuite y a le facteur temps: les rapports arrivent plus rapidement qu'ils ne peuvent humainement être corrigés. Donc on espère souvent que le rapporteur peut nous aider. C'est aussi ça une des puissances du logiciel libres, que tout le monde puisse apporter sa pierre. Par exemple pour la reproduction, on pourrait aussi faire l'inverse: le développeur pourrait tester l'ancienne version. Comme tu le notes toi-même, un logiciel a parfois plusieurs versions maintenues et il convient de tester au moins celles-ci. Ainsi pour GIMP, quand on me rapporte un bug sur une 2.8.x (la branche maintenue), je vais toujours d'abord tester master (version de développement), puis si je n'arrive pas à reproduire avec master, la dernière version 2.8.x (si je reproduis, cela indique alors probablement un bug corrigé depuis). Par contre pour raisons temporelles (avec git bisect, on peut tester toutes les versions mais ça prend un temps considérable, surtout pour des projets complexes et compilés, donc c'est rarement le premier choix) ou matérielles (car on n'a pas forcément les sous pour 5 ordis de développement, ou des disques de 10 To pour avoir 20 versions de chaque logiciel), on ne va pas forcément remonter plus loin dans le temps. Donc si je ne reproduis pas un bug dans la dernière version 2.8 (et n'arrive pas à deviner une raison au bug, car bien entendu il est aussi possible qu'un bug puisse exister dans certaines configurations sans pour autant que j'arrive à le reproduire dans la mienne), je conseille à la personne d'essayer de mettre à jour d'abord (seule la dernière 2.8 est maintenue, en l'occurrence la 2.8.22 à ce jour) même si je suis conscient que ce n'est pas forcément possible/aisé (si la personne dépend des paquets de sa distribution qui n'est pas à jour). Ce n'est pas de la mauvaise volonté de ma part, juste un compromis facteur temps/volume de correction, puisque le temps que je ne vais pas passer à essayer de comprendre un bug complexe, dur à reproduire, a priori mineur (surtout s'il arrive à peu de personnes puisqu'il est dur à reproduire), et peut-être même déjà corrigé (ce qui explique qu'on n'arrivait pas à le reproduire, simplement car il n'existait plus), je vais le passer à corriger 10 bugs faciles à reproduire (ce qui veut dire qu'ils arrivent à beaucoup de personnes, voire à tout le monde, donc plus grave du point de vue "volume").
Soyons clair: idéalement on aimerait que nos logiciels soient sans bugs. Sauf cas particulier de personnes vraiment de mauvaise foi et qui ne veulent pas corriger leurs bugs, si on le pouvait, on les corrigerait tous. Mais tout simplement, on est des humains nous aussi. Les développeurs ne sont pas les hackeurs de la télé qui te disent "tiens je vais hacker la NASA", et en 10 secondes, alors que sur leurs écrans on ne voit que des chiffres qui défilent et des dessins 3D qui bougent dans tous les sens, paf! C'est fait! En vrai, chaque bug mineur peut potentiellement prendre un temps fou. Tiens, j'ai posté hier (en anglais), un article sur un correctif de quelques lignes qui m'a pris 3 mois (pas à temps plein, certes! ;p) et beaucoup de prises de tête pour comprendre où se trouvait le problème, surtout que d'autres gens ne reproduisaient pas le problème!
Ensuite il existe aussi des développeurs inbuvables, parfois imbus d'eux-même et surtout désagréables. Cela arrive. De même qu'il y a aussi des cas similaires de certains rapporteurs de bugs. Il ne faut ensuite pas en faire des généralités si possible.
Il y a aussi certains dévs super sympas, mais qui manient parfois l'ironie un peu trop naturellement et cela peut être mal compris malheureusement, surtout à l'écrit. C'est à éviter mais parfois c'est juste le style de la personne. J'en connais qui sont en fait super ouverts aux bugs, vont faire de gros efforts pour tout corriger, mais parfois il arrive que sur certains rapports, ils fassent un commentaire ironique qui peut être mal compris/pris.
Je pense que les projets bénéficient beaucoup des rapports de bugs des simples utilisateurs
Sur ce point: effectivement les rapports de bug sont l'une des premières méthodes de contribution, mais ça ne veut pas dire que tous les rapports de bug sont utiles. Certains rapports de bug sont vraiment des pertes de temps, par exemple quand la personne en face est elle-même de mauvaise volonté (comme je le disais, ça peut arriver des développeurs comme des rapporteurs). Ça arrive. On peut se demander parfois pourquoi même avoir rapporté le bug si c'est pour ensuite saboter toute tentative de correction, mais je ne suis pas psy.
Parfois certaines personnes ne comprennent juste pas ce qu'on leur demande (même si c'est pas de compiler le logiciel! Un truc plus "simple" mais néanmoins technique, par exemple essayer d'avoir des traces sur un crash). On ne peut pas leur en vouloir, et on aimerait pouvoir les aider, mais au bout d'un moment, on voit bien qu'on ne peut pas. Je suis sûr qu'on en connaît tous des comme-cela. Par exemple mes parents, essayer de leur expliquer des trucs super simples (genre appuyer sur des boutons) en informatique par téléphone, c'est souvent la misère et au final, je me retrouve une ou deux semaines après à devoir montrer devant l'écran (pour qu'ils oublient une semaine plus tard encore). J'ose même pas imaginer si on leur demandait des infos de débug.
Que faire dans ce cas? Essayer indéfiniment de réexpliquer la même chose ou passer ce même temps à corriger 20 bugs majeurs rapportés par des gens qui te donnent directement les bonnes infos?
Encore une fois, ce n'est pas une critique. Comme on dit souvent ici, chacun ses domaines de compétences, et je ne veux pas insinuer que ces gens qui rapportent des bugs peu "utiles" sont "fautifs" de quelque chose. Déjà s'ils ont essayé de rapporter un bug, c'est un premier grand pas en avant et mieux que beaucoup qui ne font que se plaindre. Malheureusement ce premier pas n'est pas toujours suffisant à lui seul, et il peut arriver qu'il soit aussi même cause de beaucoup de perte de temps si la personne n'arrive pas à effectuer les pas supplémentaires. C'est triste mais c'est un fait. Je ne veux pas décourager les gens de rapporter les bugs, bien au contraire: faites ce premier pas. Au fur et à mesure, on peut espérer que même ceux qui ont eu du mal au début deviennent des rapporteurs experts par la suite. Mais il n'est pas exclus que pour en arriver là, ils aient dû faire 3 rapports de bugs inutiles d'abord.
si le projet est organisé pour les traiter.
C'est la grande problématique! Qu'est-ce qu'il faut pour traiter efficacement des bugs?!
Déjà si on pouvait automatiser la récupération de données de debug, ce serait bien. Justement parce que je me suis beaucoup posé ces questions dernièrement (m'étant rendu compte que beaucoup de bugs sont plus compliqué qu'ils ne le seraient si on avait les bonnes infos directement), j'ai récemment implémenté un système de collecte de données de debug (traces d'appels backtrace, informations de versions, etc.) automatique lors de crashs et d'erreurs critiques dans GIMP, qui encourage les gens à rapporter les bugs en quelques clics.
Ensuite même avec ça, on espère que les gens sauront toujours expliciter ce qu'ils faisaient quand le bug s'est produit, etc. Et comme je l'expliquais, c'est pas toujours donné.
Enfin la dernière chose, encore et toujours: le temps humain. On peut avoir tous les systèmes de débuggage qu'on veut, etc. si y a pas assez de développeurs avec du temps derrière, ben — je le disais — les rapports de bug arriveront plus vite qu'on peut les traiter.
C'est aussi pour cela que j'aimerais professionnaliser mon développement libre à travers le projet ZeMarmot (instant pub, si vous voulez aider, c'est par là! ;p).
Si tu n'as pas les ressources pour traiter ces bugs, alors il ne faut pas encourager les remontées (typiquement, le cas de la fenêtre qui s'ouvre, «le logiciel a planté, voulez-vous remonter le bug? Oui/Non", tu ne peux pas imaginer avoir d'autres infos utiles que celles que le système te remonte).
Ben là je ne suis pas d'accord. Comme je viens de le dire, je viens justement d'implémenter une telle fenêtre pour GIMP. Et tu as raison sur le fait qu'on n'a pas forcément les "ressources" pour tout traiter. Je le disais: les rapports de bug arrivent plus vite qu'on ne peut les corriger. Mais pour moi, ce n'est pas une raison pour se masquer les yeux. Un bug est un bug. S'il s'est produit, idéalement on doit le corriger, et on espère donc qu'il sera rapporté. Peut-être ne sera-t-il pas corrigé de manière suffisamment rapide, puisque — je le disais aussi — on fait des compromis en fonction de notre temps disponible. On estime donc des priorités, etc. Et donc ce rapport peut rester dans notre système un temps certain sans obtenir de correction. C'est triste. Mais ce n'est pas une raison suffisante pour ne pas le rapporter. C'est une vision fataliste du développement.
Ma vision est plus optimiste: certes on a pas le temps, mais peut-être l'aura-t-on un jour. Y a un "espoir". Au moins s'il est dans le système, on pourra peut-être le corriger un jour. S'il a jamais été rapporté sous prétexte "qu'on n'a pas les ressources", ben… il sera juste jamais corrigé.
On espère aussi que les rapporteurs de bug comprennent cela également et ne prennent pas ombrage si on ne peut pas corriger de suite. Encore une fois, ce n'est pas forcément de la mauvaise volonté. Et il se trouve que beaucoup de rapporteurs de bugs comprennent cela très bien et sont très compréhensifs.
Le truc, c'est qu'on s'en fout des stats. On n'est pas là pour dire qu'on a peu de bugs juste parce qu'on a peu de rapports. Ça c'est une vision d'entrepreneur qui veut vendre du vent et espère donc avoir le moins de remontée de bugs possible car cela signifie payer plus de gens pour les corriger, et potentiellement une mauvaise image. Nous on s'en fout. On fait un logiciel qu'on veut le meilleur possible et on espère tous les rapports de bug possible. On ne peut pas promettre pouvoir tout corriger, mais on essaiera.
Au passage:
les utilisateurs vont remonter beaucoup de bugs dupliqués, obsolètes, dûs aux patches de leur distribution, ou à des composants externes (bibliothèques tierces), voire remonter des comportements qui ne sont pas des bugs ou des suggestions irréalistes.
En fait ce ne sont pas forcément les rapports qui prennent le plus de temps. Déjà car il existe cette catégorie de contributeur technique non-développeur qui fait pas mal de premier tri de ce type de bugs. On en a plusieurs dans GIMP. Donc ce n'est même pas toujours du temps développeur pris (ou beaucoup moins qu'un nouveau bug réel mais mal rapporté).
Enfin voilà, globalement, malgré mon long message, je suis plutôt d'accord avec pas mal de choses que tu dis. Mais je voulais tout de même rajouter des précisions en me basant sur mon expérience dans ce que tu appelles un "gros projet" (sur la supposition que tu mets GIMP dans cette catégorie, peut-être pas) parce que je ne suis pas non plus d'accord à 100%. En espérant que mon point de vue soit intéressant tout de même. :-)
Enfin voilà. Au final, je pense pas qu'il n'y ait vraiment de point de vue du développeur ni de point de vue de l'utilisateur. Il y a simplement des humains de tous les côtés, avec leurs imperfections, et tout cela (le rapport de bug et sa gestion), c'est avant tout de la relation et communication humaine, qui peut avoir ses petits accrocs parfois, ses incompréhensions, etc. Franchement au final, il faut juste beaucoup d'empathie et ne pas voir le mal là où il n'est pas forcément. C'est pas facile, je le sais bien, parfois moi aussi je fais l'erreur! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ahah! Tu pointes un point important que je voulais mettre dans ma liste (et ai oublié!). Le site est un logiciel libre classique, donc ça nous permet de contacter les développeurs et d'avoir des réponses en effet. Bon sur ce point, ce n'est pas une évidence du Libre en fait: j'ai aussi des centaines de bugs qui n'ont jamais été répondus sur d'autres projets. C'est juste l'apanage des équipes actives; on espère donc que Liberapay le restera (pour l'instant, c'est le cas).
Pour l'instant, je n'ai fait que quelques rares rapports de bug, et les choses semblent aller dans le bon sens. Bon point en effet.
Pour pondérer un peu cependant, même les plateformes complètement proprios peuvent avoir des équipes actives. Tipeee ont une sorte de chat où on peut parler avec un référent de l'entreprise, et il m'est même arrivé de leur faire une demande de fonctionnalité qu'ils ont passée à leurs développeurs et implémentée rapidement.
Ensuite clairement c'est pas pareil. C'est pas "fait pour" ni encouragé (au début je ne pensais même pas que ma demande serait prise en compte car ce n'était pas un bug, mais clairement une fonctionnalité; j'ai essayé quand même et ça a marché!… ce qui fut une très bonne surprise). Pour l'occasion j'avais dérivé leur fenêtre de chat et l'avais donc transformée en bugtracker de fortune, vraiment parce que je suis habitué à faire des rapports de bug. D'ailleurs c'est pour cela que dans toute notre utilisation des autres plateformes, je n'ai rapporté les problèmes que rarement (mais quand même quelque fois, on se refait pas!) alors qu'en 2 mois, j'ai déjà ouvert 3 rapports de bug et ai eu 2 discussions par email pour des problèmes/questions avec Liberapay (dont une est devenu un 4ème rapport de bug). Clairement être un logiciel libre encourage à participer, relever les problèmes pour espérer des améliorations. Parce que les autres plateformes sont loin d'être parfaites, logiciellement parlant. Si y avait un bugtracker et que c'était du libre, j'y enchaînerais aussi pas mal de rapports de bugs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le projet ZeMarmot fait partie des projets sur Liberapay depuis les problèmes avec Patreon. Ce qui nous retenait avant était essentiellement qu'on est fatigué d'avoir à gérer tant de plateformes, des comptes un peu partout, de la duplication de contenu (description de projet, les "news", les "buts", etc.). Si Liberapay avait existé lorsqu'on avait commencé notre financement mi 2015, on aurait probablement même démarré uniquement avec Liberapay. On aime bien aider les outsiders, de même que ma première tentative de crowdfunding était passée par le (maintenant défunt semblerait-il) site OpenFunding.
Mais voilà, ça n'existait pas à l'époque, et plus tard, on était réticent à ajouter une autre plateforme (comme on l'a dit plusieurs fois ici quand les gens nous demandaient).
Quoiqu'il en soit, après 2 mois d'utilisation, on est vraiment très content de cette plateforme. Ce que j'apprécie surtout:
Multi-devise: pour un projet international, il me paraît normal de pouvoir accepter plusieurs devises. Bien sûr, un donateur peut toujours financer en changeant la monnaie, mais c'est un frein psychologique (en plus de produire des frais bancaires bien plus importants à cause des frais fixes, empêchant les dons de petits montants). Toutes les autres plateformes que j'ai utilisées jusque là sont à devise unique, donc ça m'obligeait souvent de rediriger les gens différemment en fonction de leur monnaie de prédilection. Liberapay évite ça!
Multi-langue: c'est encore une fois la seule plateforme que je connaisse qui permette les descriptions en plusieurs langages. Tous les autres proposent une page unique, ce qui implique soit de choisir une langue unique, soit de mettre plusieurs traductions les unes à la suite des autres dans une même page (et donc créer une page à rallonge et fouillie). La page ZeMarmot sur Liberapay propose ainsi une description en anglais, français et coréen.
Pas de news! Je pense que certains voient cela comme un manque, mais pas moi et j'espère que la "fonctionnalité" n'arrivera jamais. Comme je le disais, ce qui nous épuise, c'est la déduplication de contenu et le gaspillage d'énergie inutile. Sérieux faire nos news tous les mois en multi-langue, les adapter à la syntaxe de chaque plateforme. Il ne s'agit pas de faire juste un copier-coller: chaque plateforme a sa propre GUI, donc faut tout revérifier. Des fois même, en voulant être "intelligent", au contraire le copier-coller semble importer du HTML qui casse sur l'autre plateforme (je dis "des fois", mais en fait ça m'arrive à chaque fois)… sans parler des concepts différents. Par exemple Tipeee permet d'insérer images, galeries et vidéo au milieu de la news alors que Patreon a le concept qu'une image ou une vidéo unique sera le point principal en tête de news, commenté par du texte).
Ça ne veut pas dire qu'on ne donne aucune nouvelle aux gens et qu'ils nous financent à l'aveugle. Comme je le disais, il s'agit de duplication: tout ce qu'on dit en news sont des choses déjà disponibles par ailleurs et qu'on diffuse très régulièrement sur les réseaux sociaux, en news de notre site, en vidéo Youtube, etc. Ce n'est que de la répétition d'information (ce pourquoi c'est chiant). Les gens sont simplement responsables d'aller chercher les news eux-même sur leur support favori.
Perso ne pas avoir de news est donc pour moi une fonctionnalité majeure de Liberapay. :-D
Plus "simple", de manière général: c'est lié au point précédent. De manière générale, on sent que Liberapay propose de montrer une description assez simple de notre projet et on peut simplement rajouter les liens nécessaires pour les gens souhaitant aller plus loin. C'est beaucoup moins compliqué que les autres qui te demandent de choisir des objectifs, des paliers, des récompenses, etc. Et franchement c'est là aussi un bol d'air. J'espère que vous garderez cette simplicité. La complexité n'apporte vraiment rien à la plupart des financements récurrents (pour un gros crowdfunding unique, c'est peut-être différent).
Absence de frais (autres que bancaires): ça se passe de commentaires, bien sûr! Je pense qu'une des conséquences est que les donations semblent plus petites en moyenne, mais ça ne nous dérange pas tant que ça si on peut aussi en avoir plus. :-)
Au passage, on est bien conscient que pour que cela puisse continuer, il faut aussi donner à Liberapay, donc on donne quasiment depuis nos débuts dessus, ce qui reste quand même bien moins de frais de plateforme que sur les autres sites commerciaux. Il faudra d'ailleurs qu'on pense à monter notre don au fur et à mesure que nos propres dons progressent. :-)
Voilà, j'ai sûrement oublié des points, mais c'étaient les principaux qui font que nous apprécions notre expérience avec Liberapay à ce jour. Donc merci pour la plateforme. :-)
Ça nous aide à financer le développement de GIMP et du film ZeMarmot et c'est pas rien (même si le financement pour l'instant est pas gros, ça progresse). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai jamais parlé de Niel. D'ailleurs je suis même pas sûr si je le connaissais (je ne suis pas du tout dans le "culte de la personnalité" et encore moins à l'époque; donc je connais très peu les noms de dirigeants, même de nos jours, surtout car je m'y intéresse pas).
Donc quand je parlais de Free, je n'avais absolument pas son dirigeant en tête. Je ne fais pas l'amalgame.
Et surtout ça j'ai jamais dit:
Mais le prendre pour un modèle de vertu, même à l’époque, faut pas déconner.
Je n'ai jamais parlé de modèle de vertu, ou vertu tout court. D'ailleurs tu cites exactement ce que j'ai dit:
superbe aura de petite boîte moderne et active qui renversait les gros mammouths de l'époque.
Ça n'a rien à voir avec la vertu et je crois pas que Free ait jamais eu d'image vertueuse d'ailleurs. Leur bonne image, c'était surtout une image de "geek" (d'où les adjectifs "moderne" et "active", et non pas "vertueuse"), et c'est ça qu'on appréciait dans mes cercles de connaissance. Ils proposaient un vrai service technique, je me souviens qu'ils avaient de nouvelles fonctionnalités avant tous les autres fournisseurs, qu'ils n'essayaient pas brider leur réseau (oui car on parle beaucoup de neutralité du net de nos jours; mais de mémoire, ça a jamais vraiment été ça avec les fournisseurs historiques), etc.
C'était ça leur image. Et effectivement oui avec le recul, cela rend les scandales futurs bien moins étonnants. Ils étaient déjà dans cette optique de bulldozer: y aller à fond pour se faire leur place. Et on voit là où ça a mené.
Donc au final, oui je suis d'accord avec toi, sauf sur la partie où tu mets des mots que je n'ai pas dits/écrits dans ma bouche/mon clavier. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Et c'est une boîte bien cool.
Ensuite je les connais pas plus que ça sinon qu'un jour, ils m'ont offert une formation parce que je suis un contributeur du Libre (sympa!). Et surtout ce sont des contributeurs très importants du noyau Linux. Je me rappelle d'une version de Linux où ils avaient annoncé être les contributeurs majeurs! Et comme ils le disent dans leur communiqué, 6 mainteneurs du noyau Linux font partie de leurs employés!
Ça leur donne la qualification de boîte cool à mes yeux (sans connaître aucun de ces gens personnellement ni l'ambiance réelle au sein de la boîte, juste impression de visu extérieur). :-)
Je pense que ce qu'une société comme ça fait pour le Libre en un an doit être bien plus pour le Libre que ce que la société Free a fait dans son existence complète, et en ce sens, ils méritent bien plus le terme "Free". Mais ce n'est que mon avis de non-juge, et ça ne vaut donc rien. :p
In this complaint, FREE SAS asked, among others, the French judges to order Free Electrons and its founder Michael Opdenacker to pay the total sum of 107,000 euros on various grounds, to order Free Electrons to change name, to delete the domain name “free-electrons.com” within 15 days and to cease all use of the sign “FREE ELECTRONS” but also of the term “free” alone or with any other terms in any field in which FREE SAS is active or for any goods and services covered by its prior trademarks.
Ce que je trouve abusif, c'est tout ce qu'il y a autour la demande, payer des gros sous notamment, et surtout demander à changer de nom et à supprimer le domaine d'ici la quinzaine. C'est n'importe quoi! Quand on bosse depuis des années avec un nom et un site web (surtout pour une boîte moderne, le site est plus qu'une simple vitrine), on peut pas changer comme ça en 15 jours sauf à mettre la clé sous la porte. C'est complètement abusif comme demande, car impossible.
Ou alors le but est effectivement de leur faire mettre la clé sous la porte, et c'est vraiment malsain. Ce n'est même pas un concurrent (pas que ce soit bien d'essayer de faire mettre la clé sous la porte aux concurrents; c'est aussi vraiment pas cool, mais dans notre monde un peu malsain, c'est malheureusement compréhensible), ils ne marchent pas sur leur platebande, rien.
Je parle même pas (ah bah si j'en parle) de « to cease all use of the sign “FREE ELECTRONS” but also of the term “free” alone or with any other terms in any field ». Donc en gros, ils peuvent plus parler de "Free Software"? Un peu la base de leur business chez Free Electrons/Bootlin?! N'importe quoi. Ils sont d'autant plus à même de pouvoir employer ce terme que c'est une boîte qui communique quasi essentiellement à l'international, en anglais, comme ils le notent eux-même. Alors que Free communique en français principalement. Donc ça donne bien plus le droit à Free Electrons d'utiliser "Free", terme anglais, selon moi (encore avis de non juriste).
Enfin bon, tout cela est bien ridicule et franchement Free est tombé bien bas. Dire qu'à une époque, quand j'étais un jeunot à l'école, Free avait cette superbe aura de petite boîte moderne et active qui renversait les gros mammouths de l'époque. Maintenant c'est juste un des nouveaux mammouths qui fait pareil que les autres. Et les affaires scandaleuses les concernant se multiplient et se succèdent ces dernières années. Bien triste tout ça… ;-(
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce n'est pas tous les 6 mois malheureusement (sinon ce ne serait pas du tout un problème, car ce serait très facile à prendre en compte si justement y avait une règle). C'est plus ou moins arbitraire dans le sens où c'est annoncé par un organisme d'astronomie. Ils le font en fonction de notre décalage horaire par rapport à la rotation terrestre, mais ça reste assez arbitraire avec décision humaine: par exemple si on est décalé du temps universel de 0,5 sec, cet organisme pourrait décider d'ajouter une seconde rapidement, ou d'attendre que l'écart grandisse un peu plus. Tant qu'il reste sous 0,9 sec, c'est bon. Donc on ne peut pas prévoir ces secondes, qui doivent être annoncées.
En pratique, ça arrive plutôt toutes les quelques années. C'est pas un truc régulier. Y a d'ailleurs un historique des secondes intercalaires sur le lien que tu donnes, et on voit bien que ce n'est arrivé qu'une seule fois avec 6 mois d'intervalles, lors de la mise en place du système. Ensuite y a eu aussi pas mal de secondes rajoutées à un an d'intervalle (je me demande si la terre était particulièrement lente à ce moment là, ou simplement on avait accumulé un écart de plusieurs secondes — ce pourquoi justement ce système aurait été introduit? — et ils ont essayé de le combler en quelques années).
Mais dernièrement, ce sont des secondes avec beaucoup d'écart (j'en compte 6 dans les 20 dernières années et avec des intervalles pas du tout réguliers).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Si le prêt, le don ou la revente d'occasion peuvent légalement être interdites
Ils ne peuvent pas.
Ils peuvent interdire pour des produits entièrement numériques (logiciels, livres numériques… ce qui est le sujet de base de la discussion pour rappel, pas les œuvres avec support matériel qui n'étaient qu'une aparté), on est tout de même d'accord là-dessus? Ou alors faut développer, et on veut des références.
Parce qu'autant pour l'histoire du support physique, je conviens aisément pas bien connaître parce que j'ai rarement focalisé mes lectures légales sur ce point (et comme dit dans mon précédent commentaire, j'apprécierais un lien ou une référence de texte de loi pour compléter mes connaissances donc!)… autant pour les œuvres immatérielles, jusqu'à preuve du contraire, on se trouve 100% dans les droits d'auteur classiques, et là les ayants-droit peuvent vraiment en faire à leur tête. Déjà comme je disais plus haut, même en fait parler de "prêt", "don" et "revente" sont des abus de langage et en fait ne peuvent pas bien s'appliquer à des livres numériques qui ne sont pas des objets. On n'est jamais "propriétaire" d'un livre numérique. On nous a simplement accordé des droits sur une copie de l'œuvre, lesquels peuvent être plus ou moins étendus. C'est pas du tout pareil (usage, reproduction éventuelle, le transfert du droit pourrait permettre prêt/don/vente, etc.).
En plus c'est la norme de nos jours d'interdire "prêt", "don" et "revente" comme je l'ai montré par ex dans les termes d'usage de Kobo. Il me semble que les logiciels propriétaires qui sont entièrement achetables par licence + téléchargement interdisent aussi souvent le transfert de licence (j'en utilise plus depuis longtemps, mais par exemple, je me souviens par exemple de quelqu'un qui disait qu'une clé Steam ne peut plus être donnée une fois qu'elle a été utilisée; on ne peut la donner qu'à l'achat tant qu'on n'en a pas fait usage; quelqu'un utilisant Steam pour confirmer?).
En gros, dans le domaine du numérique, c'est entièrement au choix des ayants-droit de décider des droits accordés pour l'usage de l'œuvre (cela peut inclure le transfert de licence — c'est ce qu'on fait avec le Logiciel et l'Art Libres) et force est de constater que le choix des ayants-droits classiques interdisent en général un peu tout.
Ensuite je veux bien avoir tort (ça serait bien sur un tel sujet! On serait tous contents ici!), mais malheureusement j'en doute. Et si c'est le cas, faudra vraiment là encore de sérieuses références de texte de loi qui feraient une exception particulière du livre numérique par rapport au droit d'auteur général par exemple.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Intéressant, merci!
Y a une référence de loi à lire sur ça STP? :-)
P.S.: ceci dit, j'ai vraiment vu des textes interdisant de prêter un livre sur des pages de couverture. Mais à la réflexion, je crois que c'était lorsque je vivais en Nouvelle Zélande surtout. Je me demande si j'en ai revu en France notamment. En tous cas, j'en trouve pas dans ma biblio (mais qui n'est pas très grosse); là je vois que la sempiternelle interdiction de photocopier.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui ensuite tout est possible. La loi est rarement binaire et "évidente", car si c'était le cas, personne ferait de procès (puisqu'on en saurait le verdict avant que ça commence).
Donc il y a peut-être moyen d'aller à l'encontre certaines dérives du droit d'auteur actuel, et on ne le saura que lorsque quelqu'un aura tenté d'aller en justice et surtout gagnera. Avant cela, ce ne sont que spéculations, aux risques de chacun (donc "conseiller" sur ce type de base n'est pas forcément approprié).
Quant au caractère injuste, oui tu prêches un converti. D'autant plus injuste que les prix actuels ont été basés sur des dizaines d'années de "floutage" entre la propriété matérielle et le droit d'auteur classiques. De nos jours, ils essaient de garder les mêmes prix en enlevant le côté matériel et en ne gardant que les restrictions du droit d'auteur (celui de base sans licence, c'est à dire n'autorisant à rien). Et comme les gens ont été habitués à ce flou sémantique, ils ne se rendent pas compte qu'ils se font… "floués" pour le coup!
Franchement à l'heure actuelle, on gagne un peu en confort de lecture et en place (ce qui n'est pas rien! Encore que ça dépend des personnes; perso je préfère les livres format poche à des liseuses), mais on perd énormément sur tous les autres plans (financier, échange et relations humaines, droits sur le "produit" qui s'est transformé en "service", "patrimoine" en effet, don et diffusion d'œuvres de son vivant, etc.) avec le livre numérique. À chacun de voir si ça les vaut selon ses propres critères.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ça reste à prouver: les photocopieuses et les scanners ça existe :)
Certes. Mais photocopier une centaine de page ou plus (selon la taille du livre), ça risque de te coûter aussi cher ou presque que le livre acheté dans le commerce, sans pour autant avoir un beau livre.
Disons que les tarifs de la photocopie grand public et de l'impression professionnelle sont sans comparaison.
Mais oui sinon ça se fait, notamment pour les livres plus chers (livres techniques par exemple) et avec des services de photocopie très bon marché où ça reste quand même moins cher (si ton temps a moins de valeur que les quelques euros de gagné).
Pour le reste, tu parles de risque légal, mais je doute que la loi interdise de donner ou revendre des livres, même numériques?
La loi ne te l'interdit pas. C'est le contrat qui te lit avec l'éditeur qui peut te l'interdire (et qui de plus en plus le fait), ce qu'on appelle la licence en général en informatique.
Sur les pages de couverture de livre (papier), tu as en général toujours l'interdiction d'imprimer de nos jours. Mais je suis surpris (et dégoûté) que je vois aussi parfois des interdictions même de prêter ou donner un livre! Oui même sur les livres papier, ça arrive!
2. Digital Content. All literary works on the Service (each, “Digital Content”) are the exclusive property of the publisher or its licensors and are protected by copyright and other intellectual property laws. The download of, and access to any Digital Content is available only to Customers and is intended only for such Customers’ personal and non-commercial use. Any other use of Digital Content downloaded or accessed from the Service is strictly prohibited. Customers may not modify, transmit, publish, participate in the transfer or sale of, reproduce, create derivative works from, distribute, perform, display, or in any way exploit, any of the content of any Digital Content, in whole or in part. By downloading or otherwise accessing Digital Content from the Service, the Customer hereby acknowledges and agrees to these terms.
En gros, les livres sont uniquement pour les clients et l'usage commercial est interdit ("non-commercial use"), donc la revente. Au cas, où on voudrait faire le malin et dire qu'on revend sans marge et donc qu'y a pas d'usage "commercial", ils enfoncent le clou en indiquant explicitement qu'on ne peut transférer ou vendre un livre numérique ("Customers may not […] participate in the transfer or sale"). Tu remarques d'ailleurs le "participate in", qui est bien large pour dire que quel que soit ton rôle dans une vente, tu es en infraction avec la licence du service (pour éviter les ruses du genre "ah mais c'est le vendeur qui a fait un truc illégal en vendant, moi en tant qu'acheteur, j'ai rien à me reprocher!"… ben non!).
Ensuite techniquement, c'est simple. Même si on te l'autorisait, comment fait-on changer le watermark pour porter le nom du nouveau proprio? Autant pour nous (preuve qu'on ne l'a pas fait contrefaire) que pour le nouvel acheteur (preuve qu'il l'a bien payé)? À part si le service d'achat a aussi un service de "passage" d'ebooks… qu'il ferait d'ailleurs sûrement payer.
Au final, je rappelle que dès qu'on rentre dans le monde numérique, il n'y a plus de propriété! Quand on parle de "donner" ou "revendre", c'est un abus de langage (que j'emploie moi aussi allègrement) parce qu'on est tellement habitué aux objets matériels. Nous sommes entièrement dans le domaine de la "propriété intellectuelle", qui en l'occurrence est très mal nommée (et ce pourquoi beaucoup ne veulent plus qu'on emploie ce terme, probablement à raison). C'est essentiellement du droit d'auteur. On n'est jamais propriétaire d'un livre numérique, ce qui reviendrait à dire qu'on pourrait faire n'importe quoi avec. De même qu'on n'est jamais propriétaire d'un logiciel non plus! On nous accorde un droit dessus (droit de le lire, de l'exécuter, éventuellement d'en faire des copies et de passer les copies à d'autres, etc.). La licence donc.
Il fut un temps où pour le logiciel, la frontière était floutée, car — comme on associait le logiciel à un élément physique (des disquettes, plus tard CD ou DVD), la licence autorisait expressément la revente de celle-ci, d'où la floraison de nombreuses boutiques de jeux d'occasion notamment. De nos jours, ce n'est plus le cas, il n'y a plus d'objet physique et la plupart du temps, les licences de logiciels sont à personne unique. Il peut y avoir des variantes (un certain nombre de poste, etc.) mais globalement y a plus de droit à la "revente" (de licence). D'ailleurs de plus en plus, les licences sont à durée limitée aussi (abonnement), ce qui renforce davantage l'éloignement du modèle "propriété d'objet".
Notons qu'en fait, même les livres papiers, c'est en fait un mix de propriété matérielle classique et de droit d'auteur. La seule raison où pendant des siècles, les éditeurs n'ont pas tenté d'interdire leur revente, c'est justement à cause du côté matériel qui rend cela difficile (de la même façon que pour les logiciels avec CD d'époque). Mais comme je l'explique plus haut, de nos jours, ils commencent à essayer d'interdire des choses même pour les licences de livres papier.
Enfin je veux revenir à la loi.
Pour le reste, tu parles de risque légal, mais je doute que la loi interdise de donner ou revendre des livres, même numériques?
La loi ne te l'interdit pas.
Je disais qu'elle n'interdit pas. C'est pas tout à fait vrai. Par défaut en fait, dans le domaine du droit d'auteur, c'est même l'inverse: elle interdit tout. Tu ne peux rien faire avec une œuvre de l'esprit sans un accord explicite de l'auteur ou ses ayants-droit. Par contre, elle n'interdit presque rien aux ayants-droit en matière de ce qu'eux peuvent donner comme droit ("presque"; il y a des choses qu'on ne peut donner, par exemple ses droits moraux en France). C'est là ce que je voulais dire plus haut quand je disais que la loi n'interdit pas à donner ou revendre [une licence] de livre numérique. En fait la phrase complète est: elle ne l'interdit pas si les ayants-droit t'ont explicitement donné le droit de le faire. Comme en général, ces derniers ne donnent pas ce droit explicitement (et même au contraire interdisent explicitement, comme l'exemple de Kobo plus haut, ce qui n'était pas nécessaire en France par exemple, mais au moins a le mérite d'être doublement clair), ben dans ce sens, si, la loi te l'interdit.
Ma réponse précédente était donc un grossier raccourci pour dire que "possiblement la loi ne te l'interdit pas si l'ayant droit est d'accord".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est vrai que c'est à la fois mieux qu'un DRM, mais à la fois très critiquable car si une copie numérique se retrouve dans la nature, il n'y a qu'un pas pour l'éditeur pour supposer que c'est nous le "coupable" (sinon à quoi servirait ce watermark).
Alors autant je peux comprendre ce type de mesure pour des choses vraiment importantes, genre en rapport avec des secrets défense, ou même des secrets d'entreprises, je sais pas. Mais là, c'est juste un livre dont il est question. Le genre de trucs qu'on trimballe en général un peu partout, et qu'on peut oublier sur un banc. Alors certes, on fera plus gaffe à une liseuse électronique, mais l'idée est là: on parle d'un livre, un des trucs censés faire part de notre culture de base, etc., pas de secrets d'états. Y a 1000 façons de s'emparer des livres numériques de quelqu'un sans qu'il s'en rende compte et on va pas s'amuser à chiffrer sa bibliothèque numérique (déjà parce qu'on a pas l'habitude de surprotéger ses livres; je connais personne qui met ses livres physique dans une armoire fermée à clé… sauf peut-être la BNF pour des livres anciens et précieux, je sais pas! Aussi parce que j'espère que c'est pas ce que les éditeurs s'attendent à ce qu'on fasse et j'aimerais pas vivre dans ce monde).
Le second truc que je vois être impliqué dans ces watermarks est que les livres numériques ne doivent absolument pas être prêtés (en l'occurrence prêter == faire une copie pour un ami, la famille, etc.). Ou alors faut être 100% sûr que la personne à qui on les prête va pas s'amuser à le reprêter derrière. Ou tout simplement, même si on est sûr que la personne est 100% de confiance, c'est tout de même un ordi de plus dont les données peuvent se retrouver contrefaites (on n'a pas que des amis libristes et paranos! Y en a qui peuvent utiliser même Windows, les pauvres!). Et plus le lien avec nous s'affaiblit, plus le risque que ça se retrouve vraiment public dans la nature est grand. Et on revient au problème précédent: on se retrouve soudain "coupable" de contrefaçon.
Pour moi, ce serait acceptable seulement si le tarif descend vraiment, et pas seulement moitié prix comme dans l'exemple de ce journal. Si le livre se retrouve à 1 ou 2 €, ok. Disons que c'est du livre personne unique. Mais là, un livre à 13€ où on se retrouve craindre de le donner à lire à son meilleur pote parce qu'on en perdrait le contrôle et qu'il y a un risque légal, je trouve cela abusé.
Au moins avec les livres papiers, on achète, puis ensuite on peut se le passer entre amis, famille, etc. (certes on l'a plus après, mais souvent on s'en fiche; le plaisir de partager est plus sympa que celui de garder à tout prix un objet physique à prendre la poussière dans une bibliothèque, et qu'on relira sûrement jamais dans la plupart des cas).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En effet, tu soulignes un point intéressant pour encore améliorer l'abstraction. En fait, on ne calcule pas l'index en fonction de la valeur interdite du tout (on connaît ces index/adresses dès le début).
Les trucs barbares de type…
addr = ((c >> 1) & 1) * 256;
a = *addr;
… ne sont pas des calculs (symboliquement parlant). Ce sont juste des tests de conditions sur la valeur de bits de c (la valeur interdite), qui sont simplement faits sous la forme de calculs (parce que dans un ordi, tout est calcul en fait) et en code encore plus simplifié (mais plus long), ça revient donc à:
addr0 = 0;
addr1 = 256;
if (bit 2 de c est à 1)
_ = *addr1;
else
_ = *addr0;
Je remplace aussi le a par _, pour indiquer qu'on se fiche du résultat (syntaxe qu'on trouve dans certains langage), pour vraiment amplifier le fait que cette assignation de valeur n'est vraiment pas le point central (et n'a même aucune importance en fait).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non, je ne suis pas d'accord, c'est le fait de faire un calcul dépendant de cette valeur, de sorte que ce calcul laisse une trace dans le cache.
Oui tout à fait, et justement, ça laisse une trace sous la forme… d'un index!
if(est_dans_le_cache(adresse_1)){
C'est donc exactement mon propos. Tu t'intéresses pas du tout à ce qui est dans le cache, tu t'intéresse juste à sa voir si cet index (adresse_1 est un index) est dans le cache. L'info intéressante ici est essentiellement cet index. C'est exactement ce que fait ton code.
Tu aurais fait ce même calcul en utilisant les mêmes données (dont la valeur interdite) et l'aurait laissé dans le cache sous la forme d'une valeur, ça n'aurait servi strictement à rien (puisque le changement de valeur aurait été défait).
Donc si, on est d'accord. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben c'est surtout que je pense que la partie vraiment significative de l'attaque est le fait de transformer une valeur en index, ce qui se perdait dans ton code. :-)
Et surtout "écrire" dans le cache n'a aucune espèce d'importance. Donc pour une explication simple du problème, je pense qu'il est important que tout bout de code exemple ne fasse surtout pas d'écriture (car les gens vont s'y focaliser et croire que ce qu'ils sont en train de louper est dans cette opération d'écriture). La ruse est vraiment la lecture d'une adresse construite. On s'en fout du contenu lu, on veut juste savoir si on a lu à cet index.
Et l'erreur des constructeurs de CPU, c'est vraiment qu'ils se sont aussi focalisés sur la valeur justement, sans prendre en compte que les index aussi avaient leur importance, que c'étaient aussi des nombres et donc qu'on pouvaient finalement les utiliser pour faire passer des données en douce. :-)
C'est là toute la ruse de cette attaque et si on veut l'expliquer aux gens, c'est ce point ("transformer une valeur en index") qu'il faut appuyer et qui devrait pouvoir faire un déclic de compréhension à mon avis.
Enfin voilà. Mon but n'était pas vraiment de dire que ce que tu disais était entièrement faux. Je voulais surtout appuyer sur ce point de détail qui pour moi est le plus significatif (aussi bien pour la vulgarisation que pour l'explication détaillée et technique du problème) alors que personne ne semble vraiment l'appuyer dans toutes les explications que j'ai lues jusque là.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Un problème avec l'exécution prédictive fait qu'une donnée qui ne devrait pas pouvoir être lue se retrouve dans un cache du processeur.
En fait, l'erreur, c'est de s'accrocher à croire que le fait que la valeur interdite puisse se retrouver dans le cache a une quelconque importance. Ça n'en a aucune, d'autant plus que dès que la prédiction se révèlera fausse, toute donnée changée (cache compris) est remise à l'état initial.
Par contre, on a eu accès à la vraie valeur (lors de l'exécution prédictive), et à partir de cette valeur, on a pu construire un index pour une donnée utilisateur et cet index est légal et connu! C'est ça la ruse! On a transformée une valeur inconnue en un index connu! Et bien sûr, on a effectué une lecture à cet index qui sera notre seule donnée légale en cache.
Alors si cet index est connu, quel intérêt? En fait je me corrige: on a transformé une valeur inconnue en 2 index connus! C'est la raison pour laquelle cette attaque va lire les données bit par bit (car on obtient une réponse binaire).
Et on va simplement comparer la vitesse de lecture de ces 2 index. Note bien qu'on s'en fout toujours autant de la valeur réelle de ces 2 index. On veut juste savoir lequel est le plus rapide à lire (c'est à dire lequel est en cache), ce qui nous permet de déterminer si le bit est à 0 ou 1.
Puis on passe au bit suivant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non ce n'est pas tout à fait cela. Aux premiers abords, ta version semble plus maline que ce qu'on lit ailleurs (où ils lisent bit par bit) car tu lis un octet d'un seul coup! Mais je pense que la raison pour laquelle ce n'est pas fait est que le processeur ne met pas seulement en cache une adresse accédée, mais aussi ses voisins (pour des raisons d'efficacité; comme tu le prouves toi-même, quand on accède à une valeur, on va probablement accéder à son voisin bientôt). Par conséquent:
Et si maintenant on fait une boucle sur mon_tableau
Ben là déjà, tu as corrompu les données. En lisant un index, tu mets en cache ses voisins et donc le compte du timing n'a plus de valeur pour les données voisines.
mon_tableau[mon_octet] = mon_tableau[mon_octet] * 42; // Ou toute autre opération sur mon_tableau[mon_octet]
En fait c'est là où est ton erreur. Faire une opération sur la valeur n'a absolument aucune sorte d'intérêt ici. Cette valeur va disparaîtra de toutes façons. En fait l'opération est faite sur l'index, déjà pour placer ton cache à des index connus (quelle que soit l'adresse lue), ensuite vraisemblablement pour placer les deux valeurs à comparer à des index bien séparés pour ne pas corrompre le cache. Je n'ai effectivement pas lu d'explication claire sur ce point précis, mais cela me semble la raison évidente pour laquelle toutes les explications font cela (autrement, pourquoi se faire chier et pas simplement faire un tableau avec 2 valeurs? Ben parce qu'elles seraient trop proche et en lire une mettrait vraisemblablement la seconde en cache immédiatement donc aucun calcul de timing possible!). Donc on lit en général des trucs du genre:
int x = mon_tableau[(mon_octet & 1) * 256];
Note qu'on s'en fout de la valeur x, qui peut d'ailleurs être locale (c'est juste histoire de); de même il n'est pas besoin d'écrire dans mon_tableau. On s'en fout, ça sera annulé. On veut juste lire son contenu, ce qui le mettra en cache (et ses voisins!). Et là, en fonction que le premier bit sera 0, ou 1, on mettra en cache l'index 0 ou 256! Et ce sont des index suffisamment éloignés pour ne pas craindre que le processeur ne mettra l'un en cache car il a lu l'autre.
Donc non, ce n'est pas n'importe quelle opération qu'il faut faire, mais une opération faite pour éloigner les 2 index possibles et avoir des index connus (on ne veut surtout pas avoir à "chercher" car ça corromprait le cache et rendrait le calcul de timing inadéquat).
Bien sûr, pour lire le second bit, il faut tout refaire, et la fois suivante, construire l'index ainsi:
int x = mon_tableau[((mon_octet >> 1) & 1) * 256];
Ce qui encore une fois mettra en cache soit l'index 0 (et voisins) soit l'index 256 (et voisins).
Et ainsi de suite… En juste 8 boucles de ce code (en paramétrant le décalage), on a lu un octet complet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je trouvais juste étrange à la base de lancer une vm Windows plutôt que de d'abord tester avec Wine. Surtout dans le cas du bug en question où tu peux vérifier si tu as le même ou pas.
Dans le cas du bug en question, j'aurais installé GIMP dans Wine, j'aurais testé et… serait tombé sur le même bug que toi qui m'empêche de pouvoir aller plus loin (et j'aurais donc même pas pu tester le bout de code que je voulais tester, juste comme toi).
Puisque mon but n'est pas de tester GIMP sous Wine (on fournit une version native Linux de GIMP, donc on s'en fiche un peu de si win32 GIMP tourne bien sous Wine), je me serais pas embêté à débugger pourquoi ça marche pas à un autre endroit du code. J'aurais donc au final quand même lancé ma VM Windows et testé GIMP dedans. Donc je me serais juste rajouté plein d'étapes intermédiaires (à peine moins chiante que tester dans une VM soit dit en passant).
Et même si j'avais pu tester ce bout de code sous Wine, ça m'aurait de toutes façons rien dit sur le même code dans Win32 (puisque l'implémentation de fopen() utilisée par Wine n'est pas celle de Win32! Ça utilise à mon avis juste fopen() de Linux). Donc quel que soit le résultat, ce test aurait été inutile et aurait juste pris de mon temps; au final j'aurais dû quand même lancé une VM (ou dû attendre que quelqu'un sous Windows confirme la correction).
Je comprends pas pourquoi tu t'obstines. Wine n'est pas un émulateur et n'utilise pas de code de Windows. Tout bug spécifique à l'implémentation de l'API win32 n'est donc tout simplement pas testable dans Wine. Donc non, tu ne "peuxpasvérifier si tu as le même ou pas" dans Wine! C'est juste pas comment Wine marche.
Et en plus tu viens de faire la preuve toi-même que tester sous Wine aurait juste été de la perte de temps dans ce cas concret.
P.S.: c'est dans dernier message sur ce sujet! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Et ouais, exactement ce que je disais: Wine n'est pas Windows, c'est même pas de l'émulation Win32. Ce qui marche dans l'un ne marche pas forcément dans l'autre (et inversement, ce qui ne marche pas dans l'un peut marcher dans l'autre).
Je dirais presque qu'y aucun rapport, aucun lien, et c'est comme ça que le projet Wine l'a voulu (pour une très bonne raison d'ailleurs, ce qui fait de Wine un logiciel entièrement libre et sans binaire proprio, mais ça a un prix).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cool!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ./play.it installe vos jeux sans prise de tête. Évalué à 9.
Je connaissais pas du tout cette histoire. Du coup j'ai cherché après ton message, et… effectivement!
C'est quand même vachement marrant.
Comme le note le premier commentaire sur reddit: sans parler du fait de cracker des jeux, c'est quand même une grosse victoire pour flatpak (en terme d'adoption du système).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Reliure
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Les dernières News de ZeMarmot. Évalué à 5.
Alors "bas de gamme", c'est vite dit. C'est simplement l'une des reliures professionnelles parmi les plus répandues dans le commerce. Ensuite une fois fini, ça a vraiment l'avantage de faire pro et nickel, même si fait artisanalement (comme était le cas de cet exemplaire). Une reliure au dos collé bien faite, franchement, ça rend bien (il faut voir celle du bouquin fait par Aryeom, on croirait qu'il vient de l'imprimeur).
Alors certes, on voit toutes sortes de "reliures d'art" sur Youtube (c'est pas forcément une référence), comme tu dis. Tout le monde y va de son tuto. C'est clair que ça fait plus classe de dire qu'on fait une "reliure japonaise" qu'une "reliure collée". J'ai vu des ateliers par dizaines pour faire de la reliure japonaise et jamais pour de la reliure collée. En fait Aryeom est la première personne que j'ai rencontrée qui faisait de la reliure collée sur des livres faits-mains. Ben franchement à chaque fois que je vois le résultat, je suis épaté. C'est pratique, c'est classe, classique et simple, et ça se fait pas remarquer. Ben perso c'est tout ce que je demande à une reliure.
Le fait que ce soit plus simple et moins cher à produire, ce qui est sûrement la raison pour laquelle tu l'associes à du "bas de gamme" ne sont pour moi que des avantages additionnels, pas des inconvénients.
Je sais pas si tu as déjà vu une reliure japonaise (qui d'ailleurs — même si aussi utilisée traditionnellement au Japon — serait plutôt une reliure chinoise historiquement, mais ça fait juste plus "classe" de dire "reliure japonaise"; enfin je suppose que c'est la raison de l'emploi impropre de l'origine japonaise partout où c'est cité), mais c'est bien moins pratique (en particulier vraiment beaucoup de perte d'espace) et c'est très visible (ce qui peut être un choix design).
Bien au contraire, la reliure collée est très adaptée aux livres épais.
Ben si, la plupart des livres de poche sont avec dos collé. Pour info, je viens de sortir un recueil de plusieurs romans de Herman Hesse en version poche de ma bibliothèque. Comme attendu, il est aussi avec reliure collée et fait quasi 2000 pages.
Ah et encore une fois, perso je n'associe même pas "livre de poche" à bas de gamme, même si c'est ce que beaucoup d'éditeur essaient de donner comme image (simplement car ils veulent vendre le même livre plus cher). Il se trouve que je préfère les poches. C'est plus facile à transporter, moins lourd, moins chiant. Et la grosse couverture en dur, je m'en passe vraiment avec grand plaisir au profit d'une couverture souple (qui sera tout de même dans un papier un plus épais) plus maniable.
Ensuite c'est une question de goût (certains préféreront les gros livres avec gros caractères, etc.) mais pas si nettement de "gamme" pour moi.
Bien sûr, c'est plus facile qu'avec une reliure cousue, mais j'arrache pas non plus une feuille de mes livres de poche tous les 4 matins. Ensuite, je sais pas pour toi.
Voilà. Tout ça pour dire que je ne dis pas que tu as entièrement tort. Bien sûr que les livres aux reliures cousus sont plus solides et donc plus "pérenne" dans le temps. Mais ça n'en rend pas pour autant les reliures collées comme une technique à dédaigner (sinon ça serait pas utilisé massivement dans l'industrie du livre). Et si on devait monter en solidité vraiment, je conseillerais d'ailleurs les sections cousues puis collées (l'autre méthode de reliure très répandue, celle qu'on voit le plus souvent pour des livres à couverture dure, ou pour des manuels, etc) et pas les "reliures
japonaiseschinoises".Dans tous les cas, si quelqu'un s'intéresse au sujet, faut savoir ce qu'on veut: du hype ("reliures
japonaiseschinoises" et autres "reliures d'art" hype) ou des reliures pratiques et qui savent se faire oublier (collée, ou cousu par section puis collé) pour relier de vrais livres qu'on veut imprimer pour soi (et pas juste faire un effet démo). Bien sûr que les techniques dites "d'art" sont cools aussi. Je dirais que c'est à utiliser si tu veux faire un livre "exotique" où le fait d'avoir une reliure bien visible est un choix design. Mais ce n'est pas mieux. Perso le fait que la reliure puisse ne pas se faire remarquer dans un livre est un choix très valable.Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A voté
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Les dernières nouvelles de ZeMarmot. Évalué à 2.
Ah effectivement je me rappelle d'un email comme ça! Désolé, je suis un peu à la ramasse sur ces trucs (j'en ai en fait plusieurs des emails similaires, des gens qui me donnent un autre angle pour obtenir des donations/subventions) parce que ça me prend tellement de temps et que ça me désespère car j'ai déjà un peu tout essayé (même la SACD). Alors j'avoue que je mets parfois cela en backlog pour privilégier mon temps de développement.
Mon idée n'était pas de pas répondre (j'essaie de répondre à tous les emails), mais de "répondre dans quelques jours", et puis j'ai oublié! Désolé!
En plus c'est sûr que si tu as un contact, c'est idiot de pas retenter!
Bon je retrouverais ton email et te répondrai!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: A voté
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Les dernières nouvelles de ZeMarmot. Évalué à 7.
Coucou!
Merci!
Réponse simple: non.
Réponse compliqué: oui.
Explication de la réponse compliquée: c'est ce qu'a expliqué Jarvis, plus haut:
Ce que cela veut dire, c'est que tu peux remplir ton "porte-monnaie" avec 10€ par exemple, et faire un don récurrent de 10€. Cela videra alors ton porte-monnaie d'un coup (dès la première semaine), puis s'arrêtera là, jusqu'à ce que tu réapprovisionnes éventuellement ton compte.
D'après ce que j'ai compris, Liberapay ne tente pas de se re-servir sur ta carte et attend que tu fasses l'action explicite.
C'est aussi la façon dont Liberapay arrive à baisser les frais bancaires au passage, puisque cela incite les gens à remplir leur "porte-monnaie Liberapay" avec des plus gros montants qui seront ensuite progressivement vidés en donations hebdomadaires. Donc sur un plus gros montant, les frais fixes en particulier deviennent moins significatifs. Par exemple, je vois dans leur FAQ que les frais cartes sont de 2,106% + 0,21€. C'est sûr que si tu donnes 1€ par semaine et qu'à chaque fois, ta carte est débité (donc les frais se reproduisent toutes les semaines), ben tu as 4,2% de frais bancaires. Mais si tu as rempli ton porte-feuille une fois disons de 10€, alors les frais fixes sont minimes proportionnellement, et tu as eu des frais bancaires de ~ 2,3%.
Sur Tipeee/Patreon, comme ils ne font pas cela et qu'en plus y a des frais de plateformes, dans les faits, les frais sont en général autour de 10% de moyenne. C'est variable, car ça dépend du montant donné, du moyen de paiement du donateur, mais aussi du nombre de projet auquel chacun donne, puisque c'est le moyen utilisé par ces plateformes pour diminuer les frais fixes en débit unique avant répartition. Mais cette approximation de 10% est plutôt juste dans notre cas pour Tipeee/Patreon.
En fait, ce n'est pas si binaire. Perso je suis partagé. J'aime bien la visibilité des plateformes par "l'appel d'air" généré. En gros, plus y a de dons visibles, plus de nouveaux sont prêts à donner. Ce n'est pas idéal, voire un peu injuste, car cela rend clairement l'arrivée des nouveaux plus difficiles (et je m'inclus dedans) car on doit finalement bien plus se prouver que ceux bien établis (le seul fait d'avoir déjà une énorme base de mécènes fait boule de neige; même si bien sûr, ce n'est pas suffisant en soi).
Mais cela ne m'empêche pas d'apprécier le fait qu'un gros don déjà génère moins de frais bancaires/plateformes, et puis pourquoi attendre en recevant le don au compte-goutte?
Ensuite y a encore l'argument courant qui est que beaucoup d'associations aiment plein de petits dons récurrents car c'est moins sujet à variation donc cela permet de plus prévoir sur du long terme. En effet recevoir de très gros dons un mois donné ne signifie pas que l'on recevra autant les mois suivants. On peut tout à fait avoir un générateur très généreux qui donne 5000€ une fois, puis l'asso reçoit quasi rien les mois suivants. Donc cette grosse donation ne serait pas significative du budget de l'association au final. Alors que si on reçoit 1€ de 5000 donateurs en récurrent, cela fait aussi 5000€ mais bien moins sujet à variation (on peut avoir un certain pourcentage de donateurs en plus ou en moins d'un mois sur l'autre, mais en général, les donations récurrentes ne varieront pas du simple au décuple) et donc dans ce cas hypothétique on pourrait en déduire une moyenne des donations d'environ 5000€ par mois.
Néanmoins cela ne signifie absolument pas qu'une association préférerait ne pas avoir la donation simple pour autant. C'est simplement une variable moins prévisible, c'est tout (mais une bonne variable! Pas une mauvaise!). :-)
Conclusion: absolument inutile de s'excuser. Au contraire, c'est nous qui te remercions d'aider à faire vivre LILA et le projet ZeMarmot!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: raspberrypi ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 7.
Si on veut faire des choses puissantes, y a GEGL qui est vraiment pas mal aussi.
Ce n'est pas que le moteur graphique de GIMP (librairie C), on peut aussi créer des transformations simplement en ligne de commande, et côté web par exemple, un contributeur a créé imgflo au dessus de GEGL, qui est utilisé par une entreprise (The Grid) pour du traitement d'image sur le web.
Le README dépôt de imgflo-server notamment donne une bonne idée du système, avec une API HTTP pour traiter des images par graphe, etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Retour d'expérience
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche La deuxième année de Liberapay. Évalué à 4.
Merci pour ça! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Si j'ai bien compris...
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal LibreOffice, altération d'images intégrées :( ?. Évalué à 10.
Je pense qu'il faut voir les choses des 2 côtés de manière réaliste:
Oui, te demander de compiler GNOME directement serait idiot et irréaliste (même moi je saurais pas par où commencer pour compiler GNOME). Si quelqu'un t'a demandé cela de manière abrupte et en première réponse à un rapport de bug, alors il n'a pas été très malin.
Cependant les développeurs sont aussi des humains comme les autres, et surtout ils ne sont pas omniscients. Et des fois, sur certains bugs, on est aussi perdu que n'importe qui d'autre (au début en tous cas). Et ce d'autant plus si on n'arrive pas à reproduire le bug, ni à imaginer/comprendre sa raison. Dans ce cas, on peut espérer que si on le reproduit pas, c'est parce qu'il a été corrigé (exprès ou par chance) entre la version du rapporteur et celle du dépôt. Donc, à tout hasard, on peut se retrouver à demander au rapporteur s'il a l'opportunité de pouvoir tester sur la version du dépôt. Il y a diverses façons où cela peut être possible, et pas forcément en compilant. Par exemple certaines distributions ont des paquets de versions de développement (qui ne seront pas forcément le commit du jour, mais au moins une version plus récente). Et puis aussi le logiciel libre est plein de développeurs et quand quelqu'un rapporte un bug, on ne sait pas forcément à qui on a affaire. On peut espérer que le gars en face se trouve justement être un gars capable de compiler le logiciel, peut-être même l'a-t-il déjà fait. Ça ne coûte rien de demander.
En gros, si on t'a demandé cela, cela ne signifie pas forcément que le développeur s'attendait vraiment à ce que tu puisses le faire, mais simplement il était peut-être juste perdu lui-même et il a tenté l'improbable en te demandant, juste au cas où… Peut-être aussi ne l'a-t-il pas fait de manière très diplomate (on n'est pas tous bon diplomate, d'autant plus que beaucoup de dévs emploient aussi l'anglais en seconde langue eux-même; donc pas mal de choses peuvent se perdre dans une double traduction lang1 -> anglais -> lang2).
Ensuite y a le facteur temps: les rapports arrivent plus rapidement qu'ils ne peuvent humainement être corrigés. Donc on espère souvent que le rapporteur peut nous aider. C'est aussi ça une des puissances du logiciel libres, que tout le monde puisse apporter sa pierre. Par exemple pour la reproduction, on pourrait aussi faire l'inverse: le développeur pourrait tester l'ancienne version. Comme tu le notes toi-même, un logiciel a parfois plusieurs versions maintenues et il convient de tester au moins celles-ci. Ainsi pour GIMP, quand on me rapporte un bug sur une 2.8.x (la branche maintenue), je vais toujours d'abord tester master (version de développement), puis si je n'arrive pas à reproduire avec master, la dernière version 2.8.x (si je reproduis, cela indique alors probablement un bug corrigé depuis). Par contre pour raisons temporelles (avec
git bisect, on peut tester toutes les versions mais ça prend un temps considérable, surtout pour des projets complexes et compilés, donc c'est rarement le premier choix) ou matérielles (car on n'a pas forcément les sous pour 5 ordis de développement, ou des disques de 10 To pour avoir 20 versions de chaque logiciel), on ne va pas forcément remonter plus loin dans le temps. Donc si je ne reproduis pas un bug dans la dernière version 2.8 (et n'arrive pas à deviner une raison au bug, car bien entendu il est aussi possible qu'un bug puisse exister dans certaines configurations sans pour autant que j'arrive à le reproduire dans la mienne), je conseille à la personne d'essayer de mettre à jour d'abord (seule la dernière 2.8 est maintenue, en l'occurrence la 2.8.22 à ce jour) même si je suis conscient que ce n'est pas forcément possible/aisé (si la personne dépend des paquets de sa distribution qui n'est pas à jour). Ce n'est pas de la mauvaise volonté de ma part, juste un compromis facteur temps/volume de correction, puisque le temps que je ne vais pas passer à essayer de comprendre un bug complexe, dur à reproduire, a priori mineur (surtout s'il arrive à peu de personnes puisqu'il est dur à reproduire), et peut-être même déjà corrigé (ce qui explique qu'on n'arrivait pas à le reproduire, simplement car il n'existait plus), je vais le passer à corriger 10 bugs faciles à reproduire (ce qui veut dire qu'ils arrivent à beaucoup de personnes, voire à tout le monde, donc plus grave du point de vue "volume").Soyons clair: idéalement on aimerait que nos logiciels soient sans bugs. Sauf cas particulier de personnes vraiment de mauvaise foi et qui ne veulent pas corriger leurs bugs, si on le pouvait, on les corrigerait tous. Mais tout simplement, on est des humains nous aussi. Les développeurs ne sont pas les hackeurs de la télé qui te disent "tiens je vais hacker la NASA", et en 10 secondes, alors que sur leurs écrans on ne voit que des chiffres qui défilent et des dessins 3D qui bougent dans tous les sens, paf! C'est fait! En vrai, chaque bug mineur peut potentiellement prendre un temps fou. Tiens, j'ai posté hier (en anglais), un article sur un correctif de quelques lignes qui m'a pris 3 mois (pas à temps plein, certes! ;p) et beaucoup de prises de tête pour comprendre où se trouvait le problème, surtout que d'autres gens ne reproduisaient pas le problème!
Ensuite il existe aussi des développeurs inbuvables, parfois imbus d'eux-même et surtout désagréables. Cela arrive. De même qu'il y a aussi des cas similaires de certains rapporteurs de bugs. Il ne faut ensuite pas en faire des généralités si possible.
Il y a aussi certains dévs super sympas, mais qui manient parfois l'ironie un peu trop naturellement et cela peut être mal compris malheureusement, surtout à l'écrit. C'est à éviter mais parfois c'est juste le style de la personne. J'en connais qui sont en fait super ouverts aux bugs, vont faire de gros efforts pour tout corriger, mais parfois il arrive que sur certains rapports, ils fassent un commentaire ironique qui peut être mal compris/pris.
Sur ce point: effectivement les rapports de bug sont l'une des premières méthodes de contribution, mais ça ne veut pas dire que tous les rapports de bug sont utiles. Certains rapports de bug sont vraiment des pertes de temps, par exemple quand la personne en face est elle-même de mauvaise volonté (comme je le disais, ça peut arriver des développeurs comme des rapporteurs). Ça arrive. On peut se demander parfois pourquoi même avoir rapporté le bug si c'est pour ensuite saboter toute tentative de correction, mais je ne suis pas psy.
Parfois certaines personnes ne comprennent juste pas ce qu'on leur demande (même si c'est pas de compiler le logiciel! Un truc plus "simple" mais néanmoins technique, par exemple essayer d'avoir des traces sur un crash). On ne peut pas leur en vouloir, et on aimerait pouvoir les aider, mais au bout d'un moment, on voit bien qu'on ne peut pas. Je suis sûr qu'on en connaît tous des comme-cela. Par exemple mes parents, essayer de leur expliquer des trucs super simples (genre appuyer sur des boutons) en informatique par téléphone, c'est souvent la misère et au final, je me retrouve une ou deux semaines après à devoir montrer devant l'écran (pour qu'ils oublient une semaine plus tard encore). J'ose même pas imaginer si on leur demandait des infos de débug.
Que faire dans ce cas? Essayer indéfiniment de réexpliquer la même chose ou passer ce même temps à corriger 20 bugs majeurs rapportés par des gens qui te donnent directement les bonnes infos?
Encore une fois, ce n'est pas une critique. Comme on dit souvent ici, chacun ses domaines de compétences, et je ne veux pas insinuer que ces gens qui rapportent des bugs peu "utiles" sont "fautifs" de quelque chose. Déjà s'ils ont essayé de rapporter un bug, c'est un premier grand pas en avant et mieux que beaucoup qui ne font que se plaindre. Malheureusement ce premier pas n'est pas toujours suffisant à lui seul, et il peut arriver qu'il soit aussi même cause de beaucoup de perte de temps si la personne n'arrive pas à effectuer les pas supplémentaires. C'est triste mais c'est un fait. Je ne veux pas décourager les gens de rapporter les bugs, bien au contraire: faites ce premier pas. Au fur et à mesure, on peut espérer que même ceux qui ont eu du mal au début deviennent des rapporteurs experts par la suite. Mais il n'est pas exclus que pour en arriver là, ils aient dû faire 3 rapports de bugs inutiles d'abord.
C'est la grande problématique! Qu'est-ce qu'il faut pour traiter efficacement des bugs?!
Déjà si on pouvait automatiser la récupération de données de debug, ce serait bien. Justement parce que je me suis beaucoup posé ces questions dernièrement (m'étant rendu compte que beaucoup de bugs sont plus compliqué qu'ils ne le seraient si on avait les bonnes infos directement), j'ai récemment implémenté un système de collecte de données de debug (traces d'appels backtrace, informations de versions, etc.) automatique lors de crashs et d'erreurs critiques dans GIMP, qui encourage les gens à rapporter les bugs en quelques clics.
Ensuite même avec ça, on espère que les gens sauront toujours expliciter ce qu'ils faisaient quand le bug s'est produit, etc. Et comme je l'expliquais, c'est pas toujours donné.
Enfin la dernière chose, encore et toujours: le temps humain. On peut avoir tous les systèmes de débuggage qu'on veut, etc. si y a pas assez de développeurs avec du temps derrière, ben — je le disais — les rapports de bug arriveront plus vite qu'on peut les traiter.
C'est aussi pour cela que j'aimerais professionnaliser mon développement libre à travers le projet ZeMarmot (instant pub, si vous voulez aider, c'est par là! ;p).
Ben là je ne suis pas d'accord. Comme je viens de le dire, je viens justement d'implémenter une telle fenêtre pour GIMP. Et tu as raison sur le fait qu'on n'a pas forcément les "ressources" pour tout traiter. Je le disais: les rapports de bug arrivent plus vite qu'on ne peut les corriger. Mais pour moi, ce n'est pas une raison pour se masquer les yeux. Un bug est un bug. S'il s'est produit, idéalement on doit le corriger, et on espère donc qu'il sera rapporté. Peut-être ne sera-t-il pas corrigé de manière suffisamment rapide, puisque — je le disais aussi — on fait des compromis en fonction de notre temps disponible. On estime donc des priorités, etc. Et donc ce rapport peut rester dans notre système un temps certain sans obtenir de correction. C'est triste. Mais ce n'est pas une raison suffisante pour ne pas le rapporter. C'est une vision fataliste du développement.
Ma vision est plus optimiste: certes on a pas le temps, mais peut-être l'aura-t-on un jour. Y a un "espoir". Au moins s'il est dans le système, on pourra peut-être le corriger un jour. S'il a jamais été rapporté sous prétexte "qu'on n'a pas les ressources", ben… il sera juste jamais corrigé.
On espère aussi que les rapporteurs de bug comprennent cela également et ne prennent pas ombrage si on ne peut pas corriger de suite. Encore une fois, ce n'est pas forcément de la mauvaise volonté. Et il se trouve que beaucoup de rapporteurs de bugs comprennent cela très bien et sont très compréhensifs.
Le truc, c'est qu'on s'en fout des stats. On n'est pas là pour dire qu'on a peu de bugs juste parce qu'on a peu de rapports. Ça c'est une vision d'entrepreneur qui veut vendre du vent et espère donc avoir le moins de remontée de bugs possible car cela signifie payer plus de gens pour les corriger, et potentiellement une mauvaise image. Nous on s'en fout. On fait un logiciel qu'on veut le meilleur possible et on espère tous les rapports de bug possible. On ne peut pas promettre pouvoir tout corriger, mais on essaiera.
Au passage:
En fait ce ne sont pas forcément les rapports qui prennent le plus de temps. Déjà car il existe cette catégorie de contributeur technique non-développeur qui fait pas mal de premier tri de ce type de bugs. On en a plusieurs dans GIMP. Donc ce n'est même pas toujours du temps développeur pris (ou beaucoup moins qu'un nouveau bug réel mais mal rapporté).
Enfin voilà, globalement, malgré mon long message, je suis plutôt d'accord avec pas mal de choses que tu dis. Mais je voulais tout de même rajouter des précisions en me basant sur mon expérience dans ce que tu appelles un "gros projet" (sur la supposition que tu mets GIMP dans cette catégorie, peut-être pas) parce que je ne suis pas non plus d'accord à 100%. En espérant que mon point de vue soit intéressant tout de même. :-)
Enfin voilà. Au final, je pense pas qu'il n'y ait vraiment de point de vue du développeur ni de point de vue de l'utilisateur. Il y a simplement des humains de tous les côtés, avec leurs imperfections, et tout cela (le rapport de bug et sa gestion), c'est avant tout de la relation et communication humaine, qui peut avoir ses petits accrocs parfois, ses incompréhensions, etc. Franchement au final, il faut juste beaucoup d'empathie et ne pas voir le mal là où il n'est pas forcément. C'est pas facile, je le sais bien, parfois moi aussi je fais l'erreur! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Retour d'expérience
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche La deuxième année de Liberapay. Évalué à 5.
Ahah! Tu pointes un point important que je voulais mettre dans ma liste (et ai oublié!). Le site est un logiciel libre classique, donc ça nous permet de contacter les développeurs et d'avoir des réponses en effet. Bon sur ce point, ce n'est pas une évidence du Libre en fait: j'ai aussi des centaines de bugs qui n'ont jamais été répondus sur d'autres projets. C'est juste l'apanage des équipes actives; on espère donc que Liberapay le restera (pour l'instant, c'est le cas).
Pour l'instant, je n'ai fait que quelques rares rapports de bug, et les choses semblent aller dans le bon sens. Bon point en effet.
Pour pondérer un peu cependant, même les plateformes complètement proprios peuvent avoir des équipes actives. Tipeee ont une sorte de chat où on peut parler avec un référent de l'entreprise, et il m'est même arrivé de leur faire une demande de fonctionnalité qu'ils ont passée à leurs développeurs et implémentée rapidement.
Ensuite clairement c'est pas pareil. C'est pas "fait pour" ni encouragé (au début je ne pensais même pas que ma demande serait prise en compte car ce n'était pas un bug, mais clairement une fonctionnalité; j'ai essayé quand même et ça a marché!… ce qui fut une très bonne surprise). Pour l'occasion j'avais dérivé leur fenêtre de chat et l'avais donc transformée en bugtracker de fortune, vraiment parce que je suis habitué à faire des rapports de bug. D'ailleurs c'est pour cela que dans toute notre utilisation des autres plateformes, je n'ai rapporté les problèmes que rarement (mais quand même quelque fois, on se refait pas!) alors qu'en 2 mois, j'ai déjà ouvert 3 rapports de bug et ai eu 2 discussions par email pour des problèmes/questions avec Liberapay (dont une est devenu un 4ème rapport de bug). Clairement être un logiciel libre encourage à participer, relever les problèmes pour espérer des améliorations. Parce que les autres plateformes sont loin d'être parfaites, logiciellement parlant. Si y avait un bugtracker et que c'était du libre, j'y enchaînerais aussi pas mal de rapports de bugs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Retour d'expérience
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche La deuxième année de Liberapay. Évalué à 10.
Coucou,
Le projet ZeMarmot fait partie des projets sur Liberapay depuis les problèmes avec Patreon. Ce qui nous retenait avant était essentiellement qu'on est fatigué d'avoir à gérer tant de plateformes, des comptes un peu partout, de la duplication de contenu (description de projet, les "news", les "buts", etc.). Si Liberapay avait existé lorsqu'on avait commencé notre financement mi 2015, on aurait probablement même démarré uniquement avec Liberapay. On aime bien aider les outsiders, de même que ma première tentative de crowdfunding était passée par le (maintenant défunt semblerait-il) site OpenFunding.
Mais voilà, ça n'existait pas à l'époque, et plus tard, on était réticent à ajouter une autre plateforme (comme on l'a dit plusieurs fois ici quand les gens nous demandaient).
Quoiqu'il en soit, après 2 mois d'utilisation, on est vraiment très content de cette plateforme. Ce que j'apprécie surtout:
Multi-devise: pour un projet international, il me paraît normal de pouvoir accepter plusieurs devises. Bien sûr, un donateur peut toujours financer en changeant la monnaie, mais c'est un frein psychologique (en plus de produire des frais bancaires bien plus importants à cause des frais fixes, empêchant les dons de petits montants). Toutes les autres plateformes que j'ai utilisées jusque là sont à devise unique, donc ça m'obligeait souvent de rediriger les gens différemment en fonction de leur monnaie de prédilection. Liberapay évite ça!
Multi-langue: c'est encore une fois la seule plateforme que je connaisse qui permette les descriptions en plusieurs langages. Tous les autres proposent une page unique, ce qui implique soit de choisir une langue unique, soit de mettre plusieurs traductions les unes à la suite des autres dans une même page (et donc créer une page à rallonge et fouillie). La page ZeMarmot sur Liberapay propose ainsi une description en anglais, français et coréen.
Pas de news! Je pense que certains voient cela comme un manque, mais pas moi et j'espère que la "fonctionnalité" n'arrivera jamais. Comme je le disais, ce qui nous épuise, c'est la déduplication de contenu et le gaspillage d'énergie inutile. Sérieux faire nos news tous les mois en multi-langue, les adapter à la syntaxe de chaque plateforme. Il ne s'agit pas de faire juste un copier-coller: chaque plateforme a sa propre GUI, donc faut tout revérifier. Des fois même, en voulant être "intelligent", au contraire le copier-coller semble importer du HTML qui casse sur l'autre plateforme (je dis "des fois", mais en fait ça m'arrive à chaque fois)… sans parler des concepts différents. Par exemple Tipeee permet d'insérer images, galeries et vidéo au milieu de la news alors que Patreon a le concept qu'une image ou une vidéo unique sera le point principal en tête de news, commenté par du texte).
Ça ne veut pas dire qu'on ne donne aucune nouvelle aux gens et qu'ils nous financent à l'aveugle. Comme je le disais, il s'agit de duplication: tout ce qu'on dit en news sont des choses déjà disponibles par ailleurs et qu'on diffuse très régulièrement sur les réseaux sociaux, en news de notre site, en vidéo Youtube, etc. Ce n'est que de la répétition d'information (ce pourquoi c'est chiant). Les gens sont simplement responsables d'aller chercher les news eux-même sur leur support favori.
Perso ne pas avoir de news est donc pour moi une fonctionnalité majeure de Liberapay. :-D
Plus "simple", de manière général: c'est lié au point précédent. De manière générale, on sent que Liberapay propose de montrer une description assez simple de notre projet et on peut simplement rajouter les liens nécessaires pour les gens souhaitant aller plus loin. C'est beaucoup moins compliqué que les autres qui te demandent de choisir des objectifs, des paliers, des récompenses, etc. Et franchement c'est là aussi un bol d'air. J'espère que vous garderez cette simplicité. La complexité n'apporte vraiment rien à la plupart des financements récurrents (pour un gros crowdfunding unique, c'est peut-être différent).
Absence de frais (autres que bancaires): ça se passe de commentaires, bien sûr! Je pense qu'une des conséquences est que les donations semblent plus petites en moyenne, mais ça ne nous dérange pas tant que ça si on peut aussi en avoir plus. :-)
Au passage, on est bien conscient que pour que cela puisse continuer, il faut aussi donner à Liberapay, donc on donne quasiment depuis nos débuts dessus, ce qui reste quand même bien moins de frais de plateforme que sur les autres sites commerciaux. Il faudra d'ailleurs qu'on pense à monter notre don au fur et à mesure que nos propres dons progressent. :-)
Voilà, j'ai sûrement oublié des points, mais c'étaient les principaux qui font que nous apprécions notre expérience avec Liberapay à ce jour. Donc merci pour la plateforme. :-)
Ça nous aide à financer le développement de GIMP et du film ZeMarmot et c'est pas rien (même si le financement pour l'instant est pas gros, ça progresse). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci Free!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Free-electrons se fait attaquer en justice par Free, et change de nom. Évalué à 6.
J'ai jamais parlé de Niel. D'ailleurs je suis même pas sûr si je le connaissais (je ne suis pas du tout dans le "culte de la personnalité" et encore moins à l'époque; donc je connais très peu les noms de dirigeants, même de nos jours, surtout car je m'y intéresse pas).
Donc quand je parlais de Free, je n'avais absolument pas son dirigeant en tête. Je ne fais pas l'amalgame.
Et surtout ça j'ai jamais dit:
Je n'ai jamais parlé de modèle de vertu, ou vertu tout court. D'ailleurs tu cites exactement ce que j'ai dit:
Ça n'a rien à voir avec la vertu et je crois pas que Free ait jamais eu d'image vertueuse d'ailleurs. Leur bonne image, c'était surtout une image de "geek" (d'où les adjectifs "moderne" et "active", et non pas "vertueuse"), et c'est ça qu'on appréciait dans mes cercles de connaissance. Ils proposaient un vrai service technique, je me souviens qu'ils avaient de nouvelles fonctionnalités avant tous les autres fournisseurs, qu'ils n'essayaient pas brider leur réseau (oui car on parle beaucoup de neutralité du net de nos jours; mais de mémoire, ça a jamais vraiment été ça avec les fournisseurs historiques), etc.
C'était ça leur image. Et effectivement oui avec le recul, cela rend les scandales futurs bien moins étonnants. Ils étaient déjà dans cette optique de bulldozer: y aller à fond pour se faire leur place. Et on voit là où ça a mené.
Donc au final, oui je suis d'accord avec toi, sauf sur la partie où tu mets des mots que je n'ai pas dits/écrits dans ma bouche/mon clavier. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci Free!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Free-electrons se fait attaquer en justice par Free, et change de nom. Évalué à 10.
Et c'est une boîte bien cool.
Ensuite je les connais pas plus que ça sinon qu'un jour, ils m'ont offert une formation parce que je suis un contributeur du Libre (sympa!). Et surtout ce sont des contributeurs très importants du noyau Linux. Je me rappelle d'une version de Linux où ils avaient annoncé être les contributeurs majeurs! Et comme ils le disent dans leur communiqué, 6 mainteneurs du noyau Linux font partie de leurs employés!
Ça leur donne la qualification de boîte cool à mes yeux (sans connaître aucun de ces gens personnellement ni l'ambiance réelle au sein de la boîte, juste impression de visu extérieur). :-)
Je pense que ce qu'une société comme ça fait pour le Libre en un an doit être bien plus pour le Libre que ce que la société Free a fait dans son existence complète, et en ce sens, ils méritent bien plus le terme "Free". Mais ce n'est que mon avis de non-juge, et ça ne vaut donc rien. :p
Ce que je trouve abusif, c'est tout ce qu'il y a autour la demande, payer des gros sous notamment, et surtout demander à changer de nom et à supprimer le domaine d'ici la quinzaine. C'est n'importe quoi! Quand on bosse depuis des années avec un nom et un site web (surtout pour une boîte moderne, le site est plus qu'une simple vitrine), on peut pas changer comme ça en 15 jours sauf à mettre la clé sous la porte. C'est complètement abusif comme demande, car impossible.
Ou alors le but est effectivement de leur faire mettre la clé sous la porte, et c'est vraiment malsain. Ce n'est même pas un concurrent (pas que ce soit bien d'essayer de faire mettre la clé sous la porte aux concurrents; c'est aussi vraiment pas cool, mais dans notre monde un peu malsain, c'est malheureusement compréhensible), ils ne marchent pas sur leur platebande, rien.
Je parle même pas (ah bah si j'en parle) de « to cease all use of the sign “FREE ELECTRONS” but also of the term “free” alone or with any other terms in any field ». Donc en gros, ils peuvent plus parler de "Free Software"? Un peu la base de leur business chez Free Electrons/Bootlin?! N'importe quoi. Ils sont d'autant plus à même de pouvoir employer ce terme que c'est une boîte qui communique quasi essentiellement à l'international, en anglais, comme ils le notent eux-même. Alors que Free communique en français principalement. Donc ça donne bien plus le droit à Free Electrons d'utiliser "Free", terme anglais, selon moi (encore avis de non juriste).
Enfin bon, tout cela est bien ridicule et franchement Free est tombé bien bas. Dire qu'à une époque, quand j'étais un jeunot à l'école, Free avait cette superbe aura de petite boîte moderne et active qui renversait les gros mammouths de l'époque. Maintenant c'est juste un des nouveaux mammouths qui fait pareil que les autres. Et les affaires scandaleuses les concernant se multiplient et se succèdent ces dernières années. Bien triste tout ça… ;-(
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Nanosecondes
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal En évoquant Facebook. Évalué à 6. Dernière modification le 29 janvier 2018 à 15:35.
Ce n'est pas tous les 6 mois malheureusement (sinon ce ne serait pas du tout un problème, car ce serait très facile à prendre en compte si justement y avait une règle). C'est plus ou moins arbitraire dans le sens où c'est annoncé par un organisme d'astronomie. Ils le font en fonction de notre décalage horaire par rapport à la rotation terrestre, mais ça reste assez arbitraire avec décision humaine: par exemple si on est décalé du temps universel de 0,5 sec, cet organisme pourrait décider d'ajouter une seconde rapidement, ou d'attendre que l'écart grandisse un peu plus. Tant qu'il reste sous 0,9 sec, c'est bon. Donc on ne peut pas prévoir ces secondes, qui doivent être annoncées.
En pratique, ça arrive plutôt toutes les quelques années. C'est pas un truc régulier. Y a d'ailleurs un historique des secondes intercalaires sur le lien que tu donnes, et on voit bien que ce n'est arrivé qu'une seule fois avec 6 mois d'intervalles, lors de la mise en place du système. Ensuite y a eu aussi pas mal de secondes rajoutées à un an d'intervalle (je me demande si la terre était particulièrement lente à ce moment là, ou simplement on avait accumulé un écart de plusieurs secondes — ce pourquoi justement ce système aurait été introduit? — et ils ont essayé de le combler en quelques années).
Mais dernièrement, ce sont des secondes avec beaucoup d'écart (j'en compte 6 dans les 20 dernières années et avec des intervalles pas du tout réguliers).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Extinction du droit d'auteur
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Galère lors de l'achat d'un livre numérique. Évalué à 3.
P.P.S:
Ils peuvent interdire pour des produits entièrement numériques (logiciels, livres numériques… ce qui est le sujet de base de la discussion pour rappel, pas les œuvres avec support matériel qui n'étaient qu'une aparté), on est tout de même d'accord là-dessus? Ou alors faut développer, et on veut des références.
Parce qu'autant pour l'histoire du support physique, je conviens aisément pas bien connaître parce que j'ai rarement focalisé mes lectures légales sur ce point (et comme dit dans mon précédent commentaire, j'apprécierais un lien ou une référence de texte de loi pour compléter mes connaissances donc!)… autant pour les œuvres immatérielles, jusqu'à preuve du contraire, on se trouve 100% dans les droits d'auteur classiques, et là les ayants-droit peuvent vraiment en faire à leur tête. Déjà comme je disais plus haut, même en fait parler de "prêt", "don" et "revente" sont des abus de langage et en fait ne peuvent pas bien s'appliquer à des livres numériques qui ne sont pas des objets. On n'est jamais "propriétaire" d'un livre numérique. On nous a simplement accordé des droits sur une copie de l'œuvre, lesquels peuvent être plus ou moins étendus. C'est pas du tout pareil (usage, reproduction éventuelle, le transfert du droit pourrait permettre prêt/don/vente, etc.).
En plus c'est la norme de nos jours d'interdire "prêt", "don" et "revente" comme je l'ai montré par ex dans les termes d'usage de Kobo. Il me semble que les logiciels propriétaires qui sont entièrement achetables par licence + téléchargement interdisent aussi souvent le transfert de licence (j'en utilise plus depuis longtemps, mais par exemple, je me souviens par exemple de quelqu'un qui disait qu'une clé Steam ne peut plus être donnée une fois qu'elle a été utilisée; on ne peut la donner qu'à l'achat tant qu'on n'en a pas fait usage; quelqu'un utilisant Steam pour confirmer?).
En gros, dans le domaine du numérique, c'est entièrement au choix des ayants-droit de décider des droits accordés pour l'usage de l'œuvre (cela peut inclure le transfert de licence — c'est ce qu'on fait avec le Logiciel et l'Art Libres) et force est de constater que le choix des ayants-droits classiques interdisent en général un peu tout.
Ensuite je veux bien avoir tort (ça serait bien sur un tel sujet! On serait tous contents ici!), mais malheureusement j'en doute. Et si c'est le cas, faudra vraiment là encore de sérieuses références de texte de loi qui feraient une exception particulière du livre numérique par rapport au droit d'auteur général par exemple.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Extinction du droit d'auteur
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Galère lors de l'achat d'un livre numérique. Évalué à 2. Dernière modification le 26 janvier 2018 à 14:00.
Intéressant, merci!
Y a une référence de loi à lire sur ça STP? :-)
P.S.: ceci dit, j'ai vraiment vu des textes interdisant de prêter un livre sur des pages de couverture. Mais à la réflexion, je crois que c'était lorsque je vivais en Nouvelle Zélande surtout. Je me demande si j'en ai revu en France notamment. En tous cas, j'en trouve pas dans ma biblio (mais qui n'est pas très grosse); là je vois que la sempiternelle interdiction de photocopier.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 7switch
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Galère lors de l'achat d'un livre numérique. Évalué à 4.
Oui ensuite tout est possible. La loi est rarement binaire et "évidente", car si c'était le cas, personne ferait de procès (puisqu'on en saurait le verdict avant que ça commence).
Donc il y a peut-être moyen d'aller à l'encontre certaines dérives du droit d'auteur actuel, et on ne le saura que lorsque quelqu'un aura tenté d'aller en justice et surtout gagnera. Avant cela, ce ne sont que spéculations, aux risques de chacun (donc "conseiller" sur ce type de base n'est pas forcément approprié).
Quant au caractère injuste, oui tu prêches un converti. D'autant plus injuste que les prix actuels ont été basés sur des dizaines d'années de "floutage" entre la propriété matérielle et le droit d'auteur classiques. De nos jours, ils essaient de garder les mêmes prix en enlevant le côté matériel et en ne gardant que les restrictions du droit d'auteur (celui de base sans licence, c'est à dire n'autorisant à rien). Et comme les gens ont été habitués à ce flou sémantique, ils ne se rendent pas compte qu'ils se font… "floués" pour le coup!
Franchement à l'heure actuelle, on gagne un peu en confort de lecture et en place (ce qui n'est pas rien! Encore que ça dépend des personnes; perso je préfère les livres format poche à des liseuses), mais on perd énormément sur tous les autres plans (financier, échange et relations humaines, droits sur le "produit" qui s'est transformé en "service", "patrimoine" en effet, don et diffusion d'œuvres de son vivant, etc.) avec le livre numérique. À chacun de voir si ça les vaut selon ses propres critères.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 7switch
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Galère lors de l'achat d'un livre numérique. Évalué à 10. Dernière modification le 25 janvier 2018 à 14:00.
Certes. Mais photocopier une centaine de page ou plus (selon la taille du livre), ça risque de te coûter aussi cher ou presque que le livre acheté dans le commerce, sans pour autant avoir un beau livre.
Disons que les tarifs de la photocopie grand public et de l'impression professionnelle sont sans comparaison.
Mais oui sinon ça se fait, notamment pour les livres plus chers (livres techniques par exemple) et avec des services de photocopie très bon marché où ça reste quand même moins cher (si ton temps a moins de valeur que les quelques euros de gagné).
La loi ne te l'interdit pas. C'est le contrat qui te lit avec l'éditeur qui peut te l'interdire (et qui de plus en plus le fait), ce qu'on appelle la licence en général en informatique.
Sur les pages de couverture de livre (papier), tu as en général toujours l'interdiction d'imprimer de nos jours. Mais je suis surpris (et dégoûté) que je vois aussi parfois des interdictions même de prêter ou donner un livre! Oui même sur les livres papier, ça arrive!
Allons donc voir les termes d'usage du service de Kobo qui est cité dans ce journal (hormis le titre, les gras sont de moi):
En gros, les livres sont uniquement pour les clients et l'usage commercial est interdit ("non-commercial use"), donc la revente. Au cas, où on voudrait faire le malin et dire qu'on revend sans marge et donc qu'y a pas d'usage "commercial", ils enfoncent le clou en indiquant explicitement qu'on ne peut transférer ou vendre un livre numérique ("Customers may not […] participate in the transfer or sale"). Tu remarques d'ailleurs le "participate in", qui est bien large pour dire que quel que soit ton rôle dans une vente, tu es en infraction avec la licence du service (pour éviter les ruses du genre "ah mais c'est le vendeur qui a fait un truc illégal en vendant, moi en tant qu'acheteur, j'ai rien à me reprocher!"… ben non!).
Ensuite techniquement, c'est simple. Même si on te l'autorisait, comment fait-on changer le watermark pour porter le nom du nouveau proprio? Autant pour nous (preuve qu'on ne l'a pas fait contrefaire) que pour le nouvel acheteur (preuve qu'il l'a bien payé)? À part si le service d'achat a aussi un service de "passage" d'ebooks… qu'il ferait d'ailleurs sûrement payer.
Au final, je rappelle que dès qu'on rentre dans le monde numérique, il n'y a plus de propriété! Quand on parle de "donner" ou "revendre", c'est un abus de langage (que j'emploie moi aussi allègrement) parce qu'on est tellement habitué aux objets matériels. Nous sommes entièrement dans le domaine de la "propriété intellectuelle", qui en l'occurrence est très mal nommée (et ce pourquoi beaucoup ne veulent plus qu'on emploie ce terme, probablement à raison). C'est essentiellement du droit d'auteur. On n'est jamais propriétaire d'un livre numérique, ce qui reviendrait à dire qu'on pourrait faire n'importe quoi avec. De même qu'on n'est jamais propriétaire d'un logiciel non plus! On nous accorde un droit dessus (droit de le lire, de l'exécuter, éventuellement d'en faire des copies et de passer les copies à d'autres, etc.). La licence donc.
Il fut un temps où pour le logiciel, la frontière était floutée, car — comme on associait le logiciel à un élément physique (des disquettes, plus tard CD ou DVD), la licence autorisait expressément la revente de celle-ci, d'où la floraison de nombreuses boutiques de jeux d'occasion notamment. De nos jours, ce n'est plus le cas, il n'y a plus d'objet physique et la plupart du temps, les licences de logiciels sont à personne unique. Il peut y avoir des variantes (un certain nombre de poste, etc.) mais globalement y a plus de droit à la "revente" (de licence). D'ailleurs de plus en plus, les licences sont à durée limitée aussi (abonnement), ce qui renforce davantage l'éloignement du modèle "propriété d'objet".
Notons qu'en fait, même les livres papiers, c'est en fait un mix de propriété matérielle classique et de droit d'auteur. La seule raison où pendant des siècles, les éditeurs n'ont pas tenté d'interdire leur revente, c'est justement à cause du côté matériel qui rend cela difficile (de la même façon que pour les logiciels avec CD d'époque). Mais comme je l'explique plus haut, de nos jours, ils commencent à essayer d'interdire des choses même pour les licences de livres papier.
Enfin je veux revenir à la loi.
Je disais qu'elle n'interdit pas. C'est pas tout à fait vrai. Par défaut en fait, dans le domaine du droit d'auteur, c'est même l'inverse: elle interdit tout. Tu ne peux rien faire avec une œuvre de l'esprit sans un accord explicite de l'auteur ou ses ayants-droit. Par contre, elle n'interdit presque rien aux ayants-droit en matière de ce qu'eux peuvent donner comme droit ("presque"; il y a des choses qu'on ne peut donner, par exemple ses droits moraux en France). C'est là ce que je voulais dire plus haut quand je disais que la loi n'interdit pas à donner ou revendre [une licence] de livre numérique. En fait la phrase complète est: elle ne l'interdit pas si les ayants-droit t'ont explicitement donné le droit de le faire. Comme en général, ces derniers ne donnent pas ce droit explicitement (et même au contraire interdisent explicitement, comme l'exemple de Kobo plus haut, ce qui n'était pas nécessaire en France par exemple, mais au moins a le mérite d'être doublement clair), ben dans ce sens, si, la loi te l'interdit.
Ma réponse précédente était donc un grossier raccourci pour dire que "possiblement la loi ne te l'interdit pas si l'ayant droit est d'accord".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 7switch
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Galère lors de l'achat d'un livre numérique. Évalué à 10.
C'est vrai que c'est à la fois mieux qu'un DRM, mais à la fois très critiquable car si une copie numérique se retrouve dans la nature, il n'y a qu'un pas pour l'éditeur pour supposer que c'est nous le "coupable" (sinon à quoi servirait ce watermark).
Alors autant je peux comprendre ce type de mesure pour des choses vraiment importantes, genre en rapport avec des secrets défense, ou même des secrets d'entreprises, je sais pas. Mais là, c'est juste un livre dont il est question. Le genre de trucs qu'on trimballe en général un peu partout, et qu'on peut oublier sur un banc. Alors certes, on fera plus gaffe à une liseuse électronique, mais l'idée est là: on parle d'un livre, un des trucs censés faire part de notre culture de base, etc., pas de secrets d'états. Y a 1000 façons de s'emparer des livres numériques de quelqu'un sans qu'il s'en rende compte et on va pas s'amuser à chiffrer sa bibliothèque numérique (déjà parce qu'on a pas l'habitude de surprotéger ses livres; je connais personne qui met ses livres physique dans une armoire fermée à clé… sauf peut-être la BNF pour des livres anciens et précieux, je sais pas! Aussi parce que j'espère que c'est pas ce que les éditeurs s'attendent à ce qu'on fasse et j'aimerais pas vivre dans ce monde).
Le second truc que je vois être impliqué dans ces watermarks est que les livres numériques ne doivent absolument pas être prêtés (en l'occurrence prêter == faire une copie pour un ami, la famille, etc.). Ou alors faut être 100% sûr que la personne à qui on les prête va pas s'amuser à le reprêter derrière. Ou tout simplement, même si on est sûr que la personne est 100% de confiance, c'est tout de même un ordi de plus dont les données peuvent se retrouver contrefaites (on n'a pas que des amis libristes et paranos! Y en a qui peuvent utiliser même Windows, les pauvres!). Et plus le lien avec nous s'affaiblit, plus le risque que ça se retrouve vraiment public dans la nature est grand. Et on revient au problème précédent: on se retrouve soudain "coupable" de contrefaçon.
Pour moi, ce serait acceptable seulement si le tarif descend vraiment, et pas seulement moitié prix comme dans l'exemple de ce journal. Si le livre se retrouve à 1 ou 2 €, ok. Disons que c'est du livre personne unique. Mais là, un livre à 13€ où on se retrouve craindre de le donner à lire à son meilleur pote parce qu'on en perdrait le contrôle et qu'il y a un risque légal, je trouve cela abusé.
Au moins avec les livres papiers, on achète, puis ensuite on peut se le passer entre amis, famille, etc. (certes on l'a plus après, mais souvent on s'en fiche; le plaisir de partager est plus sympa que celui de garder à tout prix un objet physique à prendre la poussière dans une bibliothèque, et qu'on relira sûrement jamais dans la plupart des cas).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 3.
En effet, tu soulignes un point intéressant pour encore améliorer l'abstraction. En fait, on ne calcule pas l'index en fonction de la valeur interdite du tout (on connaît ces index/adresses dès le début).
Les trucs barbares de type…
… ne sont pas des calculs (symboliquement parlant). Ce sont juste des tests de conditions sur la valeur de bits de c (la valeur interdite), qui sont simplement faits sous la forme de calculs (parce que dans un ordi, tout est calcul en fait) et en code encore plus simplifié (mais plus long), ça revient donc à:
Je remplace aussi le
apar_, pour indiquer qu'on se fiche du résultat (syntaxe qu'on trouve dans certains langage), pour vraiment amplifier le fait que cette assignation de valeur n'est vraiment pas le point central (et n'a même aucune importance en fait).Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 2.
Oui tout à fait, et justement, ça laisse une trace sous la forme… d'un index!
C'est donc exactement mon propos. Tu t'intéresses pas du tout à ce qui est dans le cache, tu t'intéresse juste à sa voir si cet index (
adresse_1est un index) est dans le cache. L'info intéressante ici est essentiellement cet index. C'est exactement ce que fait ton code.Tu aurais fait ce même calcul en utilisant les mêmes données (dont la valeur interdite) et l'aurait laissé dans le cache sous la forme d'une valeur, ça n'aurait servi strictement à rien (puisque le changement de valeur aurait été défait).
Donc si, on est d'accord. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 9.
Ben c'est surtout que je pense que la partie vraiment significative de l'attaque est le fait de transformer une valeur en index, ce qui se perdait dans ton code. :-)
Et surtout "écrire" dans le cache n'a aucune espèce d'importance. Donc pour une explication simple du problème, je pense qu'il est important que tout bout de code exemple ne fasse surtout pas d'écriture (car les gens vont s'y focaliser et croire que ce qu'ils sont en train de louper est dans cette opération d'écriture). La ruse est vraiment la lecture d'une adresse construite. On s'en fout du contenu lu, on veut juste savoir si on a lu à cet index.
Et l'erreur des constructeurs de CPU, c'est vraiment qu'ils se sont aussi focalisés sur la valeur justement, sans prendre en compte que les index aussi avaient leur importance, que c'étaient aussi des nombres et donc qu'on pouvaient finalement les utiliser pour faire passer des données en douce. :-)
C'est là toute la ruse de cette attaque et si on veut l'expliquer aux gens, c'est ce point ("transformer une valeur en index") qu'il faut appuyer et qui devrait pouvoir faire un déclic de compréhension à mon avis.
Enfin voilà. Mon but n'était pas vraiment de dire que ce que tu disais était entièrement faux. Je voulais surtout appuyer sur ce point de détail qui pour moi est le plus significatif (aussi bien pour la vulgarisation que pour l'explication détaillée et technique du problème) alors que personne ne semble vraiment l'appuyer dans toutes les explications que j'ai lues jusque là.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 7.
En version simplifié!
En fait, l'erreur, c'est de s'accrocher à croire que le fait que la valeur interdite puisse se retrouver dans le cache a une quelconque importance. Ça n'en a aucune, d'autant plus que dès que la prédiction se révèlera fausse, toute donnée changée (cache compris) est remise à l'état initial.
Par contre, on a eu accès à la vraie valeur (lors de l'exécution prédictive), et à partir de cette valeur, on a pu construire un index pour une donnée utilisateur et cet index est légal et connu! C'est ça la ruse! On a transformée une valeur inconnue en un index connu! Et bien sûr, on a effectué une lecture à cet index qui sera notre seule donnée légale en cache.
Alors si cet index est connu, quel intérêt? En fait je me corrige: on a transformé une valeur inconnue en 2 index connus! C'est la raison pour laquelle cette attaque va lire les données bit par bit (car on obtient une réponse binaire).
Et on va simplement comparer la vitesse de lecture de ces 2 index. Note bien qu'on s'en fout toujours autant de la valeur réelle de ces 2 index. On veut juste savoir lequel est le plus rapide à lire (c'est à dire lequel est en cache), ce qui nous permet de déterminer si le bit est à 0 ou 1.
Puis on passe au bit suivant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 8.
Non ce n'est pas tout à fait cela. Aux premiers abords, ta version semble plus maline que ce qu'on lit ailleurs (où ils lisent bit par bit) car tu lis un octet d'un seul coup! Mais je pense que la raison pour laquelle ce n'est pas fait est que le processeur ne met pas seulement en cache une adresse accédée, mais aussi ses voisins (pour des raisons d'efficacité; comme tu le prouves toi-même, quand on accède à une valeur, on va probablement accéder à son voisin bientôt). Par conséquent:
Ben là déjà, tu as corrompu les données. En lisant un index, tu mets en cache ses voisins et donc le compte du timing n'a plus de valeur pour les données voisines.
En fait c'est là où est ton erreur. Faire une opération sur la valeur n'a absolument aucune sorte d'intérêt ici. Cette valeur va disparaîtra de toutes façons. En fait l'opération est faite sur l'index, déjà pour placer ton cache à des index connus (quelle que soit l'adresse lue), ensuite vraisemblablement pour placer les deux valeurs à comparer à des index bien séparés pour ne pas corrompre le cache. Je n'ai effectivement pas lu d'explication claire sur ce point précis, mais cela me semble la raison évidente pour laquelle toutes les explications font cela (autrement, pourquoi se faire chier et pas simplement faire un tableau avec 2 valeurs? Ben parce qu'elles seraient trop proche et en lire une mettrait vraisemblablement la seconde en cache immédiatement donc aucun calcul de timing possible!). Donc on lit en général des trucs du genre:
Note qu'on s'en fout de la valeur x, qui peut d'ailleurs être locale (c'est juste histoire de); de même il n'est pas besoin d'écrire dans
mon_tableau. On s'en fout, ça sera annulé. On veut juste lire son contenu, ce qui le mettra en cache (et ses voisins!). Et là, en fonction que le premier bit sera 0, ou 1, on mettra en cache l'index 0 ou 256! Et ce sont des index suffisamment éloignés pour ne pas craindre que le processeur ne mettra l'un en cache car il a lu l'autre.Donc non, ce n'est pas n'importe quelle opération qu'il faut faire, mais une opération faite pour éloigner les 2 index possibles et avoir des index connus (on ne veut surtout pas avoir à "chercher" car ça corromprait le cache et rendrait le calcul de timing inadéquat).
Bien sûr, pour lire le second bit, il faut tout refaire, et la fois suivante, construire l'index ainsi:
Ce qui encore une fois mettra en cache soit l'index 0 (et voisins) soit l'index 256 (et voisins).
Et ainsi de suite… En juste 8 boucles de ce code (en paramétrant le décalage), on a lu un octet complet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et ça reprend!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ZeMarmot lance un petit programme de streaming régulier !. Évalué à 4.
Aryeom est en train de faire une petite illustration pour le nouvel an en live:
https://www.youtube.com/watch?v=0F5EZ5XeC0A
C'est peut-être plus marrant et y a moins de "retraçage". :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche darktable 2.4.0. Évalué à 6.
Dans le cas du bug en question, j'aurais installé GIMP dans Wine, j'aurais testé et… serait tombé sur le même bug que toi qui m'empêche de pouvoir aller plus loin (et j'aurais donc même pas pu tester le bout de code que je voulais tester, juste comme toi).
Puisque mon but n'est pas de tester GIMP sous Wine (on fournit une version native Linux de GIMP, donc on s'en fiche un peu de si win32 GIMP tourne bien sous Wine), je me serais pas embêté à débugger pourquoi ça marche pas à un autre endroit du code. J'aurais donc au final quand même lancé ma VM Windows et testé GIMP dedans. Donc je me serais juste rajouté plein d'étapes intermédiaires (à peine moins chiante que tester dans une VM soit dit en passant).
Et même si j'avais pu tester ce bout de code sous Wine, ça m'aurait de toutes façons rien dit sur le même code dans Win32 (puisque l'implémentation de fopen() utilisée par Wine n'est pas celle de Win32! Ça utilise à mon avis juste fopen() de Linux). Donc quel que soit le résultat, ce test aurait été inutile et aurait juste pris de mon temps; au final j'aurais dû quand même lancé une VM (ou dû attendre que quelqu'un sous Windows confirme la correction).
Je comprends pas pourquoi tu t'obstines. Wine n'est pas un émulateur et n'utilise pas de code de Windows. Tout bug spécifique à l'implémentation de l'API win32 n'est donc tout simplement pas testable dans Wine. Donc non, tu ne "peux pas vérifier si tu as le même ou pas" dans Wine! C'est juste pas comment Wine marche.
Et en plus tu viens de faire la preuve toi-même que tester sous Wine aurait juste été de la perte de temps dans ce cas concret.
P.S.: c'est dans dernier message sur ce sujet! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche darktable 2.4.0. Évalué à 4.
Et ouais, exactement ce que je disais: Wine n'est pas Windows, c'est même pas de l'émulation Win32. Ce qui marche dans l'un ne marche pas forcément dans l'autre (et inversement, ce qui ne marche pas dans l'un peut marcher dans l'autre).
Je dirais presque qu'y aucun rapport, aucun lien, et c'est comme ça que le projet Wine l'a voulu (pour une très bonne raison d'ailleurs, ce qui fait de Wine un logiciel entièrement libre et sans binaire proprio, mais ça a un prix).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]