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 ]
En un sens, Wine est un autre système d'exploitation, qui se trouve avoir la même API système que Win32, ainsi que les mêmes formats binaires d'exécutables, et la même organisation des fichiers. Du moins ils essaient. Mais les implémentations sont différentes (ils ne partagent pas une ligne de code, sauf peut-être par hasard pour le code que Microsoft a repris de logiciels libres; Wine n'utilise aucun binaire propriétaire de Microsoft, etc.), et les bugs seront donc différents.
Il y aura donc une classe de bugs testables (ceux notamment en rapport avec l'organisation des fichiers par exemple), mais elle est petite. La grande majorité des bugs qui n'affectent que Windows ne seront vraisemblablement pas reproduisibles. Et inversement un bug rencontré sous Wine ne signifie pas que ce bug existe sous Windows. Ce sont des systèmes distincts, malgré la ressemblance.
Tu ne peux pas donc décemment développer et tester du code Win32 avec Wine.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tu peux simplement installer GIMP 2.9.8 pour Windows. Le bug s'y trouve (l'export Webp ne marche pas avec Win32, ou en tous cas, sous Windows 10).
Bien plus simplement, tu pourrais juste faire un test avec un programme C minimal qui ouvre un fichier en "wb+". Si ça marche sous Wine, c'est que le comportement est différent qu'avec l'API Win32 de Windows 10 (ou ça ne marche pas) et le bug ne peut donc pas y être reproduit.
Et si ça marche pas, ben ça prouve rien du tout! Le fait est que Wine n'a pas vocation à utiliser le code de Windows (ils le disent eux même, c'est l'acronyme du logiciel: Wine Is Not an Emulator) et donc toute une grande majorité des bugs spécifiques à Windows et qu'on ne peut pas reproduire sous Linux (exactement ceux qui nous intéressent ici) ne seront probablement pas reproduisibles avec Wine non plus.
Et même si c'est reproduit, ça utilise quand même des implémentations systèmes différentes (par définition de ce qu'est Wine) donc c'est peut-être juste du "hasard", pas de la vraie reproduction de bug.
Enfin bon, tu peux t'amuser à tester si tu veux, si vraiment ça t'intéresse et que tu as du temps, et viens nous donner le résultat ici, mais ça ne changera pas le fait que Wine n'est pas de l'émulation de Win32. C'est une réimplémentation + redirection d'appels systèmes. Y aura donc des bugs en moins et beaucoup de bugs en plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En effet. Un jour peut-être, on aura une ferme de serveurs, un (ou des) admins, etc. et si nos admins ont pas plus urgent à faire, je serais heureux qu'on puisse leur demander de chercher et tester des alternatives.
À ce jour, on est seul et je veux vraiment pas nous rajouter du boulot. Le streaming marche. C'est pas parfait, c'est du Google, etc. Mais au moins, c'est là.
OBS a des crashs un peu ennuyeux et réguliers en effet (en plus ça freeze la session graphique, donc faut aller killer obs en terminal pour récupérer le contrôle); pour moi, c'est déjà plus un problème dont j'aimerais bien trouver la solution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Quand t'as pas le choix, Wine peut servir pour quelques tests. Mais pour une très grande classe de bugs, cela rajoutera juste beaucoup de faux positifs comme de faux négatifs.
Déjà que GIMP est à peine maintenu sous Windows, si en plus les seuls tests étaient fait sous Wine…
Notamment l'un des problèmes de Wine est que ça n'émule pas les librairies Windows mais traduit des appels systèmes en appels locaux (si possible), ou réimplémente les appels qui ne peuvent être simplement traduits. Note que je dis "problème", mais c'est un des grands atoûts aussi, notamment car ça veut dire qu'il n'y a pas besoin de licence Windows pour exécuter un logiciel Windows sous Win car il n'y a aucun binaire Windows dedans; aussi sans cela, Wine ne pourrait probablement pas être fourni dans nos distribs Linux, ou du moins pas "prêt à l'emploi", demandant aux gens de manuellement copier des fichiers Windows, ou faisant d'autres galipettes logiques avant d'être utilisable. Donc de manière générale, c'est en fait un énorme avantage de Wine dans la plupart des cas. Mais pour de l'émulation système et des tests poussés de reproductions de problèmes (surtout ceux spécifiques à Windows et qu'on ne reproduit pas sur Linux, donc exactement ce qui nous intéresse justement), ça devient bien plus problématique.
Tiens, pour l'exemple du bug corrigé y a quelques jours, on ouvrait un fichier en mode "wb+" (lecture, écriture en binaire). Ce mode marche très bien avec le fopen() de Linux. Mais on a donc découvert que pas sous Windows. Par contre, le mode "w+b" (qui est un alias de "wb+" et est donc exactement la même chose) marche parfaitement sur les 2 systèmes. Ce fut donc la correction effectuée.
Ben ce serait intéressant de tester, mais si Wine remplace simplement l'appel fopen() win32 par celui de Linux (comme j'imagine qu'il ferait, après tout cet appel système existe sur tous les OS apparemment et a la même interface), je pense que le bug disparaîtrait sous Wine (sauf si les développeurs de Wine rajoutent du code spécifique pour émuler davantage les limitations de mode dispos sur chaque système, mais y aurait vraiment peu d'avantages de faire cela).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
ce que j'appelle parfois les « utilisateurs coopérants », qui font des rapports de bugs bien faits, participent de manière constructive aux discussions […]
Je ne suis pas trop la communauté GIMP, mais les retours que j'ai vu ont l'air de dire que la masse d'utilisateurs sous Windows est plus douée pour râler quand ça ne marche pas que pour être vraiment constructif.
Il y a tout de même des rapports de bugs de gens sous Windows, donc dans le sens que tu donnes plus haut, ce sont des "utilisateurs coopérants". Mais ça va rarement au delà de ce niveau de coopération. En particulier, on a quasi aucun développeur Windows. Par périodes, y a quelques développeurs Windows qui font plus de patches que la moyenne et restent dans le coin plus que d'autres (y a un régulier qui a fait quelques patchs en 2017), mais ça reste souvent épisodique et pas de manière suffisamment active pour qu'on puisse dire que GIMP sous Windows soit vraiment stable et maintenu.
Pourtant on fait tout pour les garder! Genre on les enferme gentiment dans la cave avec du pain de qualité, de l'eau propre et un ordi sous Windows avec GIMP! Ils arrivent toujours à s'enfuir au bout d'un moment! :P
Blague à part, je pense que beaucoup plus de gens sous Windows utilisent GIMP que sous Linux (même si on a pas de stats), pourtant au final quasi personne ne développe ou teste GIMP sous Windows. Donc on a plein de bugs parfois super basiques qui traînent des mois/années dans notre gestionnaire de bugs. La plupart des développeurs de GIMP (et en particulier les plus actifs) utilisent essentiellement Linux. Parfois on corrige des bugs Windows, souvent un peu à l'aveuglette. Y a encore quelques jours, j'en ai corrigé un. Pour la petite histoire, c'était le plugin d'export WebP et quand je propose au reporteur de tester un binaire que je cross-compile, il s'étonne que personne ne teste sous Windows. Ma réponse est que ça nous étonne aussi!
Faut bien comprendre que c'est du logiciel libre, qu'on n'est sur aucun "marché" et qu'on n'a aucune obligation de tester ou développer pour Windows. Je pense que certains ne s'en rendent pas compte effectivement et nous considèrent parfois comme un "service après vente" et qu'on leur doit de corriger tous les bugs (je précise que ce n'était pas le cas de cette personne y a quelques jours, laquelle était tout à fait ok; mais parfois c'est vrai qu'on lit des réactions bizarres sur d'autres rapports de bug et c'est pas toujours très agréable).
Au final, je pense que parfois, on devient un peu blasé et qu'on a de moins en moins envie de corriger ces bugs parce qu'on aimerait bien que les gens qui sont sous Windows et veulent y voir GIMP se prennent un peu en charge. En gros, si y avait des très actifs montrant qu'ils tiennent à leur OS, on serait heureux de les aider; mais là on a parfois l'impression qu'ils attendent qu'on leur donne la becquée.
Même moi, je me rends compte que je corrige moins de bugs Windows qu'avant, même si ça m'arrive encore régulièrement (comme y a quelques jours donc), surtout que je finis souvent par lancer une VM Windows et je dois dire que ça m'amuse pas beaucoup.
Notons qu'il n'est même pas forcément besoin d'être développeur (car y a la fameuse remarque du "tout le monde ne peut pas être développeur"). Par exemple parmi nos contributeurs très très actifs, j'en compte au moins trois qui ne sont pas vraiment des développeurs. Mais ils font des recherches, parfois sortent un peu de leur zone de confort en s'essayant à des activités un peu techniques, ont appris à compiler GIMP, ils testent des patchs (pas de la revue de code, mais au moins testent que ça marche bien), ils reproduisent des bugs et font des commentaires explicatifs pour aider les développeurs, ils gèrent les rapports de bugs, cherchent et trouvent les duplicatas, ferment des rapports de bugs simples (par exemple qui ne sont pas des bugs mais des incompréhensions, des erreurs, des duplicatas ou des bugs précédemment corrigés, etc.), ils écrivent des news sur le site, etc. Ils abattent un travail monstre et par cela aident énormément notre travail de développement.
Ces personnes là aussi sont toutes principalement sous Linux (même si 2 d'entre eux utilisent parfois Windows pour le boulot et il arrive donc qu'ils aident là aussi occasionnellement mais ce n'est pas leur OS de prédilection)! Franchement même déjà avoir des gens comme cela avec OS principal Windows serait d'une aide formidable. Mais personne à ce jour ne semble être suffisamment intéressé. :-/
Pour info: c'est pas beaucoup mieux sous macOS. On a aussi quelques réguliers (en fait un surtout, je crois! Et il vient d'agrandir sa famille y a quelques mois donc les bugs macOS s'accumulent dans le gestionnaire de bugs; comme quoi ça tient à rien).
P.S.: des gens qui ne font que demander, voire exiger, et parfois de manière désagréable même, y en a aussi sous Linux. Ou bien ceux qui nous prennent pour un service client et on devrait s'estimer heureux qu'ils utilisent notre logiciel. De même que des gens super compréhensifs, reconnaissants et même qui prennent beaucoup de leur temps pour aider à débugger existent aussi sous Windows/macOS (encore aujourd'hui y a eu une personne sous macOS qui a fait plein de tests pour aider à débugger, sans être développeur lui même!). On a aussi régulièrement des patchs de contributeurs uniques (qui viennent, déposent un patch et disparaissent) pour ces plateformes. Et bien sûr chacun est libre d'utiliser son temps de la manière qu'il veut et nous n'en voulons à personne pour ne pas contribuer sur le long terme!
Je veux pas surtout pas donner l'impression que les gens sous Linux sont des bisounours et que ceux sous les OS proprios sont tous des ingrats malotrus. Soyons clair.
Je parle seulement de ratio final des développeurs actifs et de long terme (ceux qui font qu'on peut considérer un logiciel comme étant "maintenu"). Et on peut clairement dire que GIMP est très bien et activement maintenu sous Linux, alors que pour Windows ou macOS, je pense que ce serait s'avancer un peu…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui. C'est reparti maintenant. Y a pas mal de problème de stabilité avec OBS (on a plusieurs crashs depuis hier, et je dois me connecter en SSH pour killer OBS car ça fait freezer la session d'Aryeom). Si ça continue, faudra qu'on essaie de mettre à jour, puis débugger si vraiment ça le fait toujours. Mais j'espère pas avoir à en arriver là. :-/
J'ai l'impression qu'on retrace beaucoup dans cet atelier ;-)
Y a 2 choses:
(1) D'une part, c'est que, quand elle commence à animer une scène, Aryeom retrace effectivement son layout. En théorie, elle m'a dit que puisque son layout (le trait en dessous, gris à cause de la transparence mais sinon il est noir pareil en fait) est déjà assez propre, elle ne devrait pas avoir forcément à le retracer, et devrait pouvoir commencer directement. Mais en fait, à cause du changement de tablette, le trait est légèrement différent. Apparemment cette différence entre les traits est suffisante aux yeux d'Aryeom pour justifier de tout retracer.
Et surtout elle me dit qu'elle a décidé de changer de dynamique entre le moment où elle faisait le layout et celui où elle a commencé l'animation. Donc cela a aussi changé le trait.
Disons que c'est le perfectionnisme du professionnel (pareil dans tous les métiers, je pense; en tant que développeur, on fait aussi souvent des trucs chiants avant de faire les trucs intéressants, mais ces petits détails peuvent être la différence entre du bon et du mauvais code! De même pour l'animation, donc…).
(2) Même après le premier traçage, les images suivantes sont de toutes façons très proches. Il arrive de faire des copies de calque pour les modifier, mais très souvent, on n'obtiendra une animation de qualité que si on redessine de zéro en calquant sur l'image précédente (et suivante pour les inbetweens).
Au passage, Aryeom me dit qu'avec l'habitude, c'est en fait de toutes façons souvent plus simple et plus rapide de tout redessiner de zéro que d'essayer de changer le dessin de la frame précédente (car au final, même si c'est de très infimes changements, on se met à changer quasi le dessin complet, donc ça fait en fait plus de boulot de repartir d'un copier-coller.
↓ Voir plus bas pourquoi on change le dessin complet entre 2 frames quasi identiques ↓
La logique, c'est (il me semble que cet exemple, je l'ai pris d'un livre référence en matière d'animation; à moins que ce soit un animateur qui me l'a sorti la première fois, je sais plus): si tu lèves le bras, est-ce que tu as juste bougé le bras? Non. Tu as en fait bougé ton corps entier. Ton épaule se soulève, ton bassin se penche, tes jambes aussi probablement compensent (d'une certaine façon, mais je veux pas donner trop de détail: j'y connais rien en anatomie! ;p Un animateur au contraire doit étudier l'anatomie justement), etc.
"Bouger le bras", en un sens, ça n'existe pas, c'est une action impossible (arriver à bouger le bras avec le reste du corps qui resterait statique). Vous pouvez toujours essayer d'ailleurs: mettez un appareil photo sur un pied et prenez 2 photos à quelques secondes d'intervalle en essayant de lever le bras sans bouger le reste du corps, puis importez les 2 photos dans GIMP l'une au dessus de l'autre avec de la transparence pour comparer.
Donc pour en revenir à l'animation, si tu faisais un copier-coller de l'image précédente et changeais seulement le bras, ça ferait une animation bien moins réussie.
Ensuite cela peut tout à fait être un choix, soit un choix artistique (simplicité, "design" parfois, etc.), soit un choix financier (puisque ça prend bien moins de temps évidemment). Ce sous-type d'animation traditionnelle (c'est à dire image par image) où on ne redessine pas chaque frame entièrement s'appelle l'animation limitée (la page anglaise Limited Animation est bien plus explicite que la page française).
Typiquement dans une animation limitée, pour mon exemple de bras levé, tu ne changeras que le bras et le reste du corps restera statique.
Autre exemple: si tu fais un perso qui parle, dans de l'animation traditionnelle pure et dure, tu redessines entièrement le visage à chaque frame (on sait bien que selon le son, la bouche a une forme différente, mais qu'en plus comme ça fait bouger les muscles du visage différemment, le visage entier change légèrement; en outre les émotions liées au discours rentrent en jeu), ainsi que les yeux (ils sont "vivants"!) et même la tête (on parle rarement en gardant la tête statique! En général elle va bouger), et en fait même le reste du corps. Donc pareil: on bouge tout son corps quand on parle. En plus, certains sont plus expressifs que d'autres, et je parle même pas de ceux qui parlent avec les mains!
Par contre si tu fais de l'animation limitée, alors tu feras juste bouger la bouche (et probablement un peu les yeux et les sourcils, souvent même de manière exagérée pour rajouter de "l'émotion" à moindre frais et effort).
Un exemple classique d'animation traditionnelle limitée, ça sera les Simpson. Dans leur cas, c'est clairement une raison financière/temporelle (ils ont un rythme soutenu d'épisodes) et accessoirement ça appuie bien le fait que le style graphique n'est pas l'intérêt de cette série (leur point fort, c'est surtout les scénarios comiques, et bien sûr aussi la satyre de société; mais sûrement pas le graphisme).
À tel point qu'ils font régulièrement de la blague méta sur la qualité "médiocre" de leur animation (je me rappelle d'au moins une scène où ils auto-critiquaient leur animation en ajoutant des erreurs exprès mais je trouve pas de référence sur le web; ceci dit même sans ça, on voit des vraies erreurs dans plein d'épisodes! ;P) et aussi sur le fait qu'ils sous-traitent leur animation en Corée du Sud (cf. la fameuse blague du canapé sur l'esclavage des animateurs coréens, blague auto-critique qui avait fait grincer quelques dents).
Ensuite tout cela est un choix. Faire de l'animation limitée n'est pas un problème (d'ailleurs j'aime beaucoup "Les Simpson"!) et à un moment donné, on a aussi regretté d'être parti sur de l'animation trop détaillée car ça prend trop de temps. Sans faire de l'animation limitée pour autant, on aurait aussi pu se décider sur un entre-deux. Mais c'était trop tard. Changer le style d'animation, ça veut dire jeter tout le travail d'animation qui a déjà été fait.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Merci pour la mise en dépêche, je m'y attendais pas du tout, surtout que notre organisation est clairement pas encore stabilisée (notamment à part annoncer chaque début de streaming sur les réseaux sociaux, on sait pas bien encore comment organiser les horaires).
OBS ne permet pas un export en RTSP ou un truc du genre ?
que veux-tu dis exactement? Je vois bien que RTSP est un protocole de streaming, apparemment pour contrôler un serveur de streaming à distance, ce qui semble en effet correspondre aux fonctionnalités d'OBS. Mais je sais pas vraiment ce que tu entends par "un export en RTSP"?
Ensuite j'y connais rien. Aryeom a cherché/trouvé et configuré elle-même OBS et j'ai quasi rien fait dans l'histoire (bon dans le déroulement de l'action, en suivant un tuto, elle a réussi à pêter une fois son système Linux en réinstallant les drivers NVidia, et on a été obligé de réinstaller la distribution, mais hormis ce passage où j'ai aidé, elle a tout fait) donc j'y connais pas grand chose dans les technos de streaming.
En tous cas, Youtube semble utiliser RTMP, apparemment un autre protocole de streaming (pas sûr du recoupement des fonctionnalités entre RTSP et RTMP, ou même si les 2 protos servent à la même chose; comme j'ai dit, j'y connais rien).
Ensuite quand je cherche "RTSP OBS" sur le web, y a des réponses. Donc il y a l'air d'y avoir prise en charge, même si je comprends bien pas le détail du rôle de ce protocole dans le streaming.
Note que quand je dis que je comprends pas beaucoup, c'est aussi beaucoup que je cherche pas tant que ça à comprendre. J'espère surtout que ça marche sans poser trop de questions justement. ;-P
Le jour où j'essaierai de comprendre la place de chaque protocole, ce sera quand y aura un problème et que j'essaierai de débugger, voire patcher (OBS ou autre). Pour ma sanité d'esprit et mon temps libre, j'espère que ça n'arrivera jamais! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Faut qu'on trouve une manière de les diffuser sans spammer trop (car on va le faire très régulièrement).
Une méthode peut être simplement de s'inscrire au canal LILA sur Youtube car je pense qu'à chaque fois qu'un streaming débute, des notifications automatiques sont envoyés aux inscrits (à confirmer).
Sinon on peut simplement avoir des jours/horaires fixes, mais c'est pas vraiment la façon dont on aime procéder. On va trouver une solution! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Est-ce du fait de l'utilisation de Youtube? Si c'est le cas, nous avons juste ni les serveurs ni le temps/argent pour héberger nos propres serveurs de streaming. On fait déjà trop de choses et on aimerait en faire plus (d'ailleurs ceux qui financent le projet, je pense que beaucoup préfèrent que mon temps soit utilisé pour améliorer GIMP plutôt que pour mettre en place/configurer/sécuriser un serveur de streaming).
Je dis ça, on héberge déjà nos emails, un cloud, nos serveurs web… et c'est déjà 1000x trop. :-/
Si un jour, on est un gros studio avec nos propres admins, je dis pas. Bien au contraire. :-)
Mais pas aujourd'hui.
Sinon on peut voir les alternatives à Google. Un pote m'a parlé de Twitch, mais Aryeom avait déjà fait plein de tests avec Youtube, et… encore une fois, on a préféré ne pas perdre plus de temps que ça parce qu'elle avait mis pas mal d'heure à mettre en place tout son système de streaming.
Dans tous les cas, il s'agit d'un vrai streaming, si. Du bon live en direct, où on peut même poser des questions dans le chat (bon c'est plutôt moi qui répond dans 90% des cas quand je regarde entre 2 patchs; Aryeom ne regarde pas son propre streaming pendant qu'elle bosse). On a même eu quelques crashs d'OBS (le client libre pour le streaming que nous utilisons) en direct aujourd'hui, etc. ;P
C'est même pour cela que je précise bien que cela peut être un peu chiant des fois, car on voit du vrai travail fait en temps réel, sans accélération ni édition.
Ces liens plus haut sont simplement les enregistrements après-coup des streamings (que Youtube enregistre automatiquement), d'où le titre "liens d'après-streaming".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est juste une petite blague inoffensive et on parle là d'une petite image vectorielle de 130KB sur le site d'un éditeur d'image et de peinture moderne. Presque n'importe quelle image sur la page d'accueil (celles en bandeau) est plus lourde (alors qu'y en a plusieurs).
Parler de sur-armement matériel pour cette petite blagounette animée de 130kb sur le site d'un logiciel d'imagerie me paraît être un sur-armement lexical. :P
P.S.: en plus sur un site entièrement statique, qui ne pratique donc pas de surarment côté serveur!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Mais quand même, tu es parmi les plus gros contributeurs à GIMP de ces dernières années, ce n'est pas rien. […]
De plus, oui la Blender Foundation va aider essentiellement des projets concernant Blender directement. Mais c'est une vision un peu court termiste et non globale de l'écosystème. […]
Là où je veux en venir c'est que Blender est un outil non autosuffisant pour les graphistes. GIMP, Inkscape et d'autres outils sont indispensables pour une entreprise orientée dans le secteur. Améliorer GIMP peut aider à améliorer l’implantation de Blender. […]
Bref, Blender pourrait tirer un bénéfice si GIMP et d'autres logiciels pour graphistes parvenaient à s'améliorer.
Je suis d'accord avec tout ce que tu dis. Ce n'est pas moi qu'il faut convaincre. ;-)
Ceci dit, j'ai fait une recherche dans mes emails et ai aussi retrouvé une discussion avec Ton en 2015, que j'avais oubliée. Elle confirme les positions de la fondation Blender qui veut se limiter aux projets Blender, bien que Ton laissait ouvert un futur possible où aider un projet GIMP (de manière exceptionnelle) n'était pas totalement hors de question. Peut-être un jour, donc. Il disait qu'en tous cas ce n'était pas possible à l'époque avec l'état des finances. Peut-être maintenant, qui sait.
Donc comme je dis, je réessaierai sûrement dans quelques mois.
Mais dans tous les cas, comme je disais, j'ai appris à ne pas mettre trop d'espoir dans une direction particulière. Tout ce que tu me dis, je le sais, et suis d'accord, et ai tenté maintes fois. Si ça marche, tant mieux, mais faut bien savoir que les chances sont faibles car les projets ont tous leurs priorités. Tu parles de "Red Hat, Canonical ou SUSE" qui investissent dans des projets tiers sans rapport directs avec eux, mais pour un tel petit projet qui rentre dans le système (et qui d'ailleurs est souvent un projet maintenu par un employé dans son temps libre, donc ce n'est pas forcément totalement sans rapport), et qui fera pas mal parler de lui (donc effectivement fait de la pub pour le projet sponsor), combien sont refusés?
Que ce soit Blender, RedHat ou Canonical, et plein d'autres gros acteurs du Libre, j'avais tenté de les contacter, sans succès. En fait, je crois que j'ai contacté (souvent à plusieurs reprises) tous les gros et moyens projets (entreprises ou fondations) de l'écosystème Libre. J'ai même mis en page de bons dossiers complets en PDF, avec images, et liens vidéos, pour expliquer notre projet, ce qu'il en ressort pour le libre, l'intérêt pour le sponsor (en personnalisant pour chaque sponsor souvent), etc. Ça n'a à ce jour rien donné, par contre cela m'a pris un temps fou. Je ne dis pas que ça ne donnera jamais rien. Peut-être qu'un jour, à force de la contacter, une entreprise/fondation qui a refusé (ou pas répondu) plus tôt décidera de nous aider. Par exemple quand on sortira davantage du lot. Simplement j'ai appris à ne pas mettre trop d'espoir, à perdre trop de temps et à donner trop de valeur à ce type de contacts car au final, les quasi-seuls financements et aides d'autres types qu'on ait jamais réussi à obtenir, ce sont ceux qu'on n'a jamais demandés et les financements participatifs, et principalement de la part de particuliers (même si y a aussi quelques entreprises dans les sponsors du premier financement, et même quelques associations, surtout dernièrement).
Dans les faits, chaque entreprise/fondation a tout de même des objectifs et essaie de ne pas diverger trop. Ils font quelques gestes vers la communauté, mais cela reste limité. C'est d'ailleurs aussi compréhensible (surtout pour une fondation de la taille de Blender qui commence à être connue mais n'est pas non plus un acteur si gros encore qu'elle peut se permettre de trop diverger sans quelques risques, je pense).
Voilà. Ce sera ma dernière réponse sur ce sujet car y répondre aussi me prend trop de temps.
Je ne dis pas que tu as tort. Au contraire, je suis d'accord. Mais faut garder la tête sur ses épaules sur ce genre de sujet, surtout quand on est une très petite équipe (et que donc se disperser a un coût non négligeable). On a tout essayé maints et maints fois. On continuera, mais avec modération.
La vision que tu présentes du libre est un peu utopique à mon avis (et moi aussi je l'avais).
Cela étant dit, je t'invite à leur parler de nous (sur les réseaux sociaux par exemple). :-)
Je pense que si plein de gens parlaient régulièrement de ZeMarmot à Ton/Blender, un jour si je le recontacte, il se dira que oui, ZeMarmot a l'air d'être un projet avec de l'avenir (car il en aura entendu parler à maints reprises par des inconnus) et que la fondation Blender a tout à y gagner à nous aider. Sa position pourrait être beaucoup plus enthousiaste pour un projet dont il entend beaucoup parler.
Cela vaut pour RedHat, Canonical, et d'autres entreprises ou Fondations. Je pense que si 100 inconnus parlent de ZeMarmot à Ton, ce sera 100 fois plus impactant que si moi, en tant que représentant du projet, je lui en reparle 10 fois.
En fait, cela commence doucement. Plus de personnes parlent de nous maintenant sans qu'on soit de la discussion. C'est bien. Et c'est comme ça qu'on va peut-être rentrer dans le radar de ces autres gros acteurs.
Je conclurai par un conseil que je donne aux gens qui sont intéressés par le financement de projet: je crois que la meilleure qualité à avoir, c'est l'endurance (et toutes les variantes: l'obstination, la constance, persévérance…). Si tu fais quelque chose publiquement pendant des années et des années, au fur et à mesure, de plus en plus de gens te voient. De plus en plus de gens te suivent. Il n'y a pas de recette miracle. Il n'y a pas d'aide miracle non plus (que ce soit la fondation Blender ou autre). La plupart des gros projets sont nés ainsi d'ailleurs.
L'une des rares choses qui peut accélérer cela est si on a déjà beaucoup d'argent (c'est pas notre cas). Une autre chose est la chance. Mais je suis de ceux qui pensent que la chance, on se la crée soi-même (justement en étant persévérant). Donc ça boucle.
Si un jour la Fondation Blender nous aide, je saurai juste que c'est parce qu'on a su persévérer suffisamment longtemps, plus que par une rhétorique quelconque (aussi vraie soit-elle).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
en fait ta démarche c'est celle de la Blender Fondation. Ils ont pas mal de films à leur actif et Blender a évolué avec ces films. As-tu tenté (et veux-tu tenter) de collaborer avec eux dans cette démarche ?
J'ai eu à plusieurs reprises des échanges avec Ton Roosendaal, mais pas sur le sujet de la collaboration, me semble-t-il. Il est au courant de notre projet (notamment il a tweeté une fois au moins dessus). En gros, non, on n'en a jamais vraiment parlé.
Ceci dit, eux sont intéressés par Blender (c'est normal, leur fondation a été créée dans le but d'améliorer Blender, pas d'autres Logiciels Libres, ni pour l'Art Libre, à l'inverse de LILA) et je ne suis pas sûr qu'ils voient un grand intérêt (au sens de l'intérêt de la fondation) à notre film. Personnellement, probablement (le tweet de Ton disait justement que notre projet avait le bon esprit), mais pas pour la fondation. Ensuite c'est pas forcément vrai. Les films d'animation 2D modernes ont souvent un peu de soutien 3D dernièrement (par ex pour les scènes avec beaucoup de rotation, genre caméra qui tourne autour d'un perso qui court, une des grandes faiblesses de la 2D dessinée à cause de la difficulté des changements de perspective; ou pour les backgrounds de scènes, notamment de type bâtiments; etc.) et si on avait des fonds, on prévoyait de faire de même (on a des contacts Blender, cf. notre page de film par exemple qui donne un nom d'une telle personne dans "l'équipe", même si dans les faits, ça n'a jamais pu se faire à ce jour car on n'a pas de quoi payer). Peut-être qu'on pourrait tenter une collaboration, mais je pense que ce ne sera intéressant de leur proposer qu'après la sortie du pilote.
Cela pourrait être un moyen de mutualiser la logistique, le marketing et d'améliorer peut être votre financement.
Quant aux aides de type marketing, oui ils peuvent nous aider s'ils parlent de nous, bien sûr. Mais si on est pas un projet de la fondation, ils voudront probablement pas! Et en fait, je viens soudainement de me rappeler que si, je leur avais déjà demandé (je laisse quand même mon erreur précédente pour une trace du cheminement de pensée!). Il me semble que c'était pour un autre petit projet avec du Blender. Je leur avais demandé s'ils pouvaient nous faire un peu de pub. Laisser un petit post sur le site par exemple, pour aider le financement d'un "projet ami". Et on m'avait aimablement refusé car ils ne font que de la promotion des projets de la fondation même.
Note que je ne leur en veux pas, c'est compréhensible. Y a beaucoup de projets tiers, et si on se met à parler de tous les projets, déjà ça n'en finit plus, ensuite ceux dont on ne parle pas se sentiront laissés pour compte. Je pense qu'en fait, la vraie réponse, c'est qu'ils ne feraient que de la pub de projets qui sortent vraiment du lot en utilisant Blender (ce qui leur permet donc en même temps de faire de la pub pour Blender même), donc de projets déjà avec un bon succès. C'est un peu comme ça que le monde marche: on n'aide pas les petits, seuls ceux qui sont déjà grands (c'est à la fois triste et à la fois compréhensible, comme je le disais. Un peu la version réaliste du "aide toi, le ciel t'aidera").
Quoiqu'il en soit, je pense réessayer de rentrer en contact avec eux après la sortie du pilote. Il reste des possibilités, et notre pilote aiderait pour la partie "sortir du lot". Mais dans tous les cas, je ne souhaite pas "miser" sur ce type d'aide seulement. J'ai appris avec le temps que la seule aide réellement fiable, c'est soi-même qui la crée (même l'aide financière, c'est en général car on a d'abord réussi à prouver qu'on la vaut que les gens acceptent de nous financer). Il ne faut pas trop dépendre des autres et espérer des "miracles". Cela marche rarement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Et pourtant… j'ai eu plusieurs commentaires de la sorte. Y a aussi le cas de ceux qui croient que ce qu'on fait ne touche que l'animation ou le dessin et donc ne changera rien à leur utilisation (photo par exemple). Y a justement le cas un peu plus haut en commentaire de cette news.
pourquoi ne pas aussi ouvrir une source de financement en ton nom propre
J'y ai pensé, mais déjà, ce serait une sorte de mensonge. Mon travail est essentiellement collaboratif et si jamais en faisant cela, le financement du film reste bas et on décide de l'arrêter, même si on me donnait beaucoup de sous pour du dév GIMP général seulement, ben je voudrais arrêter aussi probablement. Les gens ne comprendraient pas parce que je leur aurais promis du dév général de GIMP en mon nom (et ils auraient donc raison de ne pas comprendre). Je veux pas leur mentir et donc je suis clair dès le début: on fait ZeMarmot, en conséquence de quoi on améliore GIMP énormément et continuellement. C'est ça le vrai projet.
Je fais ça parce qu'on utilise GIMP, et on a nos priorités effectives. Cela ne nous empêche pas de faire du dév général au passage, bien au contraire. C'est une conséquence évidente car le logiciel doit marcher bien globalement pour marcher bien dans notre cas d'usage. Mais ça n'empêche que je veux garder notre priorité en tête.
Pour moi, ma motivation principale de contribution à un logiciel, c'est parce que je l'utilise et rencontre un problème ou un manque. J'ai plusieurs patchs dans Blender car on avait des crashs avec certains exports de format (de mémoire); un patch dans Firefox (pour un truc que finalement je n'utilise pas; mais à l'époque c'était pour ça); des patchs dans mplayer puis mpv pour des fonctionnalités dont j'avais besoin car ce sont mes lecteurs vidéos de choix (enfin mplayer l'était, maintenant je suis passé à mpv); etc. Je patche, car j'utilise, pas juste pour me faire plaisir (même si ça me fait aussi plaisir accessoirement). C'est comme ça. GIMP et ZeMarmot, c'est donc pareil. :-)
Autre point: on a déjà 3 plateformes de financement (on en avait 2 jusqu'à y a quelques jours, mais après les problèmes de Patreon ce mois-ci, et comme plusieurs personnes nous parlaient de Liberapay, on vient d'y ouvrir un compte)!. Et franchement c'est lourd en gestion. On n'est pas une entreprise, on n'a pas de service de gestion et compta dédié. C'est nous qui faisons un peu tout (avec des bénévoles de LILA qui aident). Je préfère aussi éviter de diviser encore plus avec un financement séparé.
Finalement, dernier point: j'aime le travail d'équipe. J'aime que les gens savent qu'on bosse à plusieurs et c'est pour ça que ce qu'on fait est d'autant plus cool au final. Dans GIMP, non c'est pas moi qui code tout. On a quelques autres dévs très prolifiques (et très très bons), et j'adore aussi faire de la revue de code pour des contributions uniques de qualité. C'est aussi gratifiant d'intégrer un patch de quelqu'un d'autre que de coder moi-même quelque chose (même si mon nom n'apparaît que dans le second cas, le travail est parfois aussi important en revue de code).
Pour ZeMarmot, c'est pareil. C'est du travail d'équipe. Aryeom peut dessiner car elle a un logiciel à la hauteur car des gens comme moi le corrigent et implémentent des fonctionnalités utiles. Réciproquement je fais de bonnes corrections car Aryeom me dit que non, ça, ça va pas, etc. Il m'est arrivé plusieurs fois de jeter des heures de code d'un truc que je croyais trop cool car, quand je le montre à Aryeom, elle me démontre qu'en fait ça lui compliquera la vie (et donc à d'autres aussi); ou de changer complètement certaines implémentations après qu'elle me fait la bonne remarque que ça pourrait être beaucoup mieux comme ci ou ça (et c'était vrai!).
C'est un travail d'équipe, c'est la réalité et il ne faut pas la nier. Je veux donc faire un financement d'équipe, et pas en mon nom propre. C'est comme les groupes de musique au nom d'un unique musicien/chanteur star, j'ai toujours trouvé ça triste et pas cool (même si le musicien est peut-être exceptionnel, là n'est pas la question). Y a une équipe, faut un nom de groupe. Ben là, pareil. ZeMarmot, c'est pas juste moi. On est un groupe, et j'aime ça.
Mon rêve, ce serait qu'on passe le stade de 2 personnes. Un jour, si on a suffisamment de financement, on pourrait avoir un studio avec beaucoup d'artistes et aussi beaucoup de développeurs, et on corrigerait plein de bugs et implémenterait des fonctionnalités cools dans plein de logiciels (pas juste GIMP; on utilise Linux, et que des logiciels libres; tout ce qu'on utilise et qui ne marche pas suffisamment bien pourrait devenir une cible de contribution si on avait suffisamment de développeurs).
C'est mon petit rêve perso. Mais ça ne peut se faire que si on passe le stade d'arriver déjà à financer au moins 2 salaires (on en est encore loin!). Et donc ça ferait une équipe encore plus grande. Faire un financement pour moi seul serait donc contre-productif et dans la mauvaise direction. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Notre asso a fait un don à LiLa le mois dernier, du coup si on peut avoir une build… ;)
Cool merci.
(Je n'avais pas eu de réponse en vous envoyant un message depuis votre formulaire de contact)
Je retrouve pas cet email. Normalement je fais la revue de tous les emails reçus par l'asso et essaie d'y répondre personnellement (bien que je croule aussi sous les emails, donc des fois, il m'arrive de les remettre à plus tard, puis d'oublier de répondre).
Tu peux m'envoyer un email, par exemple à jehan chez GIMP (nom de domaine du logiciel), qui est un alias vers mon adresse principale. Et oui bien sûr, y aura pas de problème pour te donner un accès à mon build flatpak. :-)
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 ]
[^] # Re: Bravo !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche darktable 2.4.0. Évalué à 4.
En un sens, Wine est un autre système d'exploitation, qui se trouve avoir la même API système que Win32, ainsi que les mêmes formats binaires d'exécutables, et la même organisation des fichiers. Du moins ils essaient. Mais les implémentations sont différentes (ils ne partagent pas une ligne de code, sauf peut-être par hasard pour le code que Microsoft a repris de logiciels libres; Wine n'utilise aucun binaire propriétaire de Microsoft, etc.), et les bugs seront donc différents.
Il y aura donc une classe de bugs testables (ceux notamment en rapport avec l'organisation des fichiers par exemple), mais elle est petite. La grande majorité des bugs qui n'affectent que Windows ne seront vraisemblablement pas reproduisibles. Et inversement un bug rencontré sous Wine ne signifie pas que ce bug existe sous Windows. Ce sont des systèmes distincts, malgré la ressemblance.
Tu ne peux pas donc décemment développer et tester du code Win32 avec Wine.
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. Dernière modification le 30 décembre 2017 à 16:55.
Tu peux simplement installer GIMP 2.9.8 pour Windows. Le bug s'y trouve (l'export Webp ne marche pas avec Win32, ou en tous cas, sous Windows 10).
Bien plus simplement, tu pourrais juste faire un test avec un programme C minimal qui ouvre un fichier en "wb+". Si ça marche sous Wine, c'est que le comportement est différent qu'avec l'API Win32 de Windows 10 (ou ça ne marche pas) et le bug ne peut donc pas y être reproduit.
Et si ça marche pas, ben ça prouve rien du tout! Le fait est que Wine n'a pas vocation à utiliser le code de Windows (ils le disent eux même, c'est l'acronyme du logiciel: Wine Is Not an Emulator) et donc toute une grande majorité des bugs spécifiques à Windows et qu'on ne peut pas reproduire sous Linux (exactement ceux qui nous intéressent ici) ne seront probablement pas reproduisibles avec Wine non plus.
Et même si c'est reproduit, ça utilise quand même des implémentations systèmes différentes (par définition de ce qu'est Wine) donc c'est peut-être juste du "hasard", pas de la vraie reproduction de bug.
Enfin bon, tu peux t'amuser à tester si tu veux, si vraiment ça t'intéresse et que tu as du temps, et viens nous donner le résultat ici, mais ça ne changera pas le fait que Wine n'est pas de l'émulation de Win32. C'est une réimplémentation + redirection d'appels systèmes. Y aura donc des bugs en moins et beaucoup de bugs en plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Liens d'après-streaming
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 2.
En effet. Un jour peut-être, on aura une ferme de serveurs, un (ou des) admins, etc. et si nos admins ont pas plus urgent à faire, je serais heureux qu'on puisse leur demander de chercher et tester des alternatives.
À ce jour, on est seul et je veux vraiment pas nous rajouter du boulot. Le streaming marche. C'est pas parfait, c'est du Google, etc. Mais au moins, c'est là.
OBS a des crashs un peu ennuyeux et réguliers en effet (en plus ça freeze la session graphique, donc faut aller killer obs en terminal pour récupérer le contrôle); pour moi, c'est déjà plus un problème dont j'aimerais bien trouver la solution.
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é à 7.
Quand t'as pas le choix, Wine peut servir pour quelques tests. Mais pour une très grande classe de bugs, cela rajoutera juste beaucoup de faux positifs comme de faux négatifs.
Déjà que GIMP est à peine maintenu sous Windows, si en plus les seuls tests étaient fait sous Wine…
Notamment l'un des problèmes de Wine est que ça n'émule pas les librairies Windows mais traduit des appels systèmes en appels locaux (si possible), ou réimplémente les appels qui ne peuvent être simplement traduits. Note que je dis "problème", mais c'est un des grands atoûts aussi, notamment car ça veut dire qu'il n'y a pas besoin de licence Windows pour exécuter un logiciel Windows sous Win car il n'y a aucun binaire Windows dedans; aussi sans cela, Wine ne pourrait probablement pas être fourni dans nos distribs Linux, ou du moins pas "prêt à l'emploi", demandant aux gens de manuellement copier des fichiers Windows, ou faisant d'autres galipettes logiques avant d'être utilisable. Donc de manière générale, c'est en fait un énorme avantage de Wine dans la plupart des cas. Mais pour de l'émulation système et des tests poussés de reproductions de problèmes (surtout ceux spécifiques à Windows et qu'on ne reproduit pas sur Linux, donc exactement ce qui nous intéresse justement), ça devient bien plus problématique.
Tiens, pour l'exemple du bug corrigé y a quelques jours, on ouvrait un fichier en mode "wb+" (lecture, écriture en binaire). Ce mode marche très bien avec le fopen() de Linux. Mais on a donc découvert que pas sous Windows. Par contre, le mode "w+b" (qui est un alias de "wb+" et est donc exactement la même chose) marche parfaitement sur les 2 systèmes. Ce fut donc la correction effectuée.
Ben ce serait intéressant de tester, mais si Wine remplace simplement l'appel fopen() win32 par celui de Linux (comme j'imagine qu'il ferait, après tout cet appel système existe sur tous les OS apparemment et a la même interface), je pense que le bug disparaîtrait sous Wine (sauf si les développeurs de Wine rajoutent du code spécifique pour émuler davantage les limitations de mode dispos sur chaque système, mais y aurait vraiment peu d'avantages de faire cela).
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é à 10.
Il y a tout de même des rapports de bugs de gens sous Windows, donc dans le sens que tu donnes plus haut, ce sont des "utilisateurs coopérants". Mais ça va rarement au delà de ce niveau de coopération. En particulier, on a quasi aucun développeur Windows. Par périodes, y a quelques développeurs Windows qui font plus de patches que la moyenne et restent dans le coin plus que d'autres (y a un régulier qui a fait quelques patchs en 2017), mais ça reste souvent épisodique et pas de manière suffisamment active pour qu'on puisse dire que GIMP sous Windows soit vraiment stable et maintenu.
Pourtant on fait tout pour les garder! Genre on les enferme gentiment dans la cave avec du pain de qualité, de l'eau propre et un ordi sous Windows avec GIMP! Ils arrivent toujours à s'enfuir au bout d'un moment! :P
Blague à part, je pense que beaucoup plus de gens sous Windows utilisent GIMP que sous Linux (même si on a pas de stats), pourtant au final quasi personne ne développe ou teste GIMP sous Windows. Donc on a plein de bugs parfois super basiques qui traînent des mois/années dans notre gestionnaire de bugs. La plupart des développeurs de GIMP (et en particulier les plus actifs) utilisent essentiellement Linux. Parfois on corrige des bugs Windows, souvent un peu à l'aveuglette. Y a encore quelques jours, j'en ai corrigé un. Pour la petite histoire, c'était le plugin d'export WebP et quand je propose au reporteur de tester un binaire que je cross-compile, il s'étonne que personne ne teste sous Windows. Ma réponse est que ça nous étonne aussi!
Faut bien comprendre que c'est du logiciel libre, qu'on n'est sur aucun "marché" et qu'on n'a aucune obligation de tester ou développer pour Windows. Je pense que certains ne s'en rendent pas compte effectivement et nous considèrent parfois comme un "service après vente" et qu'on leur doit de corriger tous les bugs (je précise que ce n'était pas le cas de cette personne y a quelques jours, laquelle était tout à fait ok; mais parfois c'est vrai qu'on lit des réactions bizarres sur d'autres rapports de bug et c'est pas toujours très agréable).
Au final, je pense que parfois, on devient un peu blasé et qu'on a de moins en moins envie de corriger ces bugs parce qu'on aimerait bien que les gens qui sont sous Windows et veulent y voir GIMP se prennent un peu en charge. En gros, si y avait des très actifs montrant qu'ils tiennent à leur OS, on serait heureux de les aider; mais là on a parfois l'impression qu'ils attendent qu'on leur donne la becquée.
Même moi, je me rends compte que je corrige moins de bugs Windows qu'avant, même si ça m'arrive encore régulièrement (comme y a quelques jours donc), surtout que je finis souvent par lancer une VM Windows et je dois dire que ça m'amuse pas beaucoup.
Notons qu'il n'est même pas forcément besoin d'être développeur (car y a la fameuse remarque du "tout le monde ne peut pas être développeur"). Par exemple parmi nos contributeurs très très actifs, j'en compte au moins trois qui ne sont pas vraiment des développeurs. Mais ils font des recherches, parfois sortent un peu de leur zone de confort en s'essayant à des activités un peu techniques, ont appris à compiler GIMP, ils testent des patchs (pas de la revue de code, mais au moins testent que ça marche bien), ils reproduisent des bugs et font des commentaires explicatifs pour aider les développeurs, ils gèrent les rapports de bugs, cherchent et trouvent les duplicatas, ferment des rapports de bugs simples (par exemple qui ne sont pas des bugs mais des incompréhensions, des erreurs, des duplicatas ou des bugs précédemment corrigés, etc.), ils écrivent des news sur le site, etc. Ils abattent un travail monstre et par cela aident énormément notre travail de développement.
Ces personnes là aussi sont toutes principalement sous Linux (même si 2 d'entre eux utilisent parfois Windows pour le boulot et il arrive donc qu'ils aident là aussi occasionnellement mais ce n'est pas leur OS de prédilection)! Franchement même déjà avoir des gens comme cela avec OS principal Windows serait d'une aide formidable. Mais personne à ce jour ne semble être suffisamment intéressé. :-/
Pour info: c'est pas beaucoup mieux sous macOS. On a aussi quelques réguliers (en fait un surtout, je crois! Et il vient d'agrandir sa famille y a quelques mois donc les bugs macOS s'accumulent dans le gestionnaire de bugs; comme quoi ça tient à rien).
P.S.: des gens qui ne font que demander, voire exiger, et parfois de manière désagréable même, y en a aussi sous Linux. Ou bien ceux qui nous prennent pour un service client et on devrait s'estimer heureux qu'ils utilisent notre logiciel. De même que des gens super compréhensifs, reconnaissants et même qui prennent beaucoup de leur temps pour aider à débugger existent aussi sous Windows/macOS (encore aujourd'hui y a eu une personne sous macOS qui a fait plein de tests pour aider à débugger, sans être développeur lui même!). On a aussi régulièrement des patchs de contributeurs uniques (qui viennent, déposent un patch et disparaissent) pour ces plateformes. Et bien sûr chacun est libre d'utiliser son temps de la manière qu'il veut et nous n'en voulons à personne pour ne pas contribuer sur le long terme!
Je veux pas surtout pas donner l'impression que les gens sous Linux sont des bisounours et que ceux sous les OS proprios sont tous des ingrats malotrus. Soyons clair.
Je parle seulement de ratio final des développeurs actifs et de long terme (ceux qui font qu'on peut considérer un logiciel comme étant "maintenu"). Et on peut clairement dire que GIMP est très bien et activement maintenu sous Linux, alors que pour Windows ou macOS, je pense que ce serait s'avancer un peu…
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é à 10.
Salut!
Oui. C'est reparti maintenant. Y a pas mal de problème de stabilité avec OBS (on a plusieurs crashs depuis hier, et je dois me connecter en SSH pour killer OBS car ça fait freezer la session d'Aryeom). Si ça continue, faudra qu'on essaie de mettre à jour, puis débugger si vraiment ça le fait toujours. Mais j'espère pas avoir à en arriver là. :-/
Y a 2 choses:
(1) D'une part, c'est que, quand elle commence à animer une scène, Aryeom retrace effectivement son layout. En théorie, elle m'a dit que puisque son layout (le trait en dessous, gris à cause de la transparence mais sinon il est noir pareil en fait) est déjà assez propre, elle ne devrait pas avoir forcément à le retracer, et devrait pouvoir commencer directement. Mais en fait, à cause du changement de tablette, le trait est légèrement différent. Apparemment cette différence entre les traits est suffisante aux yeux d'Aryeom pour justifier de tout retracer.
Et surtout elle me dit qu'elle a décidé de changer de dynamique entre le moment où elle faisait le layout et celui où elle a commencé l'animation. Donc cela a aussi changé le trait.
Disons que c'est le perfectionnisme du professionnel (pareil dans tous les métiers, je pense; en tant que développeur, on fait aussi souvent des trucs chiants avant de faire les trucs intéressants, mais ces petits détails peuvent être la différence entre du bon et du mauvais code! De même pour l'animation, donc…).
(2) Même après le premier traçage, les images suivantes sont de toutes façons très proches. Il arrive de faire des copies de calque pour les modifier, mais très souvent, on n'obtiendra une animation de qualité que si on redessine de zéro en calquant sur l'image précédente (et suivante pour les inbetweens).
Au passage, Aryeom me dit qu'avec l'habitude, c'est en fait de toutes façons souvent plus simple et plus rapide de tout redessiner de zéro que d'essayer de changer le dessin de la frame précédente (car au final, même si c'est de très infimes changements, on se met à changer quasi le dessin complet, donc ça fait en fait plus de boulot de repartir d'un copier-coller.
↓ Voir plus bas pourquoi on change le dessin complet entre 2 frames quasi identiques ↓
La logique, c'est (il me semble que cet exemple, je l'ai pris d'un livre référence en matière d'animation; à moins que ce soit un animateur qui me l'a sorti la première fois, je sais plus): si tu lèves le bras, est-ce que tu as juste bougé le bras? Non. Tu as en fait bougé ton corps entier. Ton épaule se soulève, ton bassin se penche, tes jambes aussi probablement compensent (d'une certaine façon, mais je veux pas donner trop de détail: j'y connais rien en anatomie! ;p Un animateur au contraire doit étudier l'anatomie justement), etc.
"Bouger le bras", en un sens, ça n'existe pas, c'est une action impossible (arriver à bouger le bras avec le reste du corps qui resterait statique). Vous pouvez toujours essayer d'ailleurs: mettez un appareil photo sur un pied et prenez 2 photos à quelques secondes d'intervalle en essayant de lever le bras sans bouger le reste du corps, puis importez les 2 photos dans GIMP l'une au dessus de l'autre avec de la transparence pour comparer.
Donc pour en revenir à l'animation, si tu faisais un copier-coller de l'image précédente et changeais seulement le bras, ça ferait une animation bien moins réussie.
Ensuite cela peut tout à fait être un choix, soit un choix artistique (simplicité, "design" parfois, etc.), soit un choix financier (puisque ça prend bien moins de temps évidemment). Ce sous-type d'animation traditionnelle (c'est à dire image par image) où on ne redessine pas chaque frame entièrement s'appelle l'animation limitée (la page anglaise Limited Animation est bien plus explicite que la page française).
Typiquement dans une animation limitée, pour mon exemple de bras levé, tu ne changeras que le bras et le reste du corps restera statique.
Autre exemple: si tu fais un perso qui parle, dans de l'animation traditionnelle pure et dure, tu redessines entièrement le visage à chaque frame (on sait bien que selon le son, la bouche a une forme différente, mais qu'en plus comme ça fait bouger les muscles du visage différemment, le visage entier change légèrement; en outre les émotions liées au discours rentrent en jeu), ainsi que les yeux (ils sont "vivants"!) et même la tête (on parle rarement en gardant la tête statique! En général elle va bouger), et en fait même le reste du corps. Donc pareil: on bouge tout son corps quand on parle. En plus, certains sont plus expressifs que d'autres, et je parle même pas de ceux qui parlent avec les mains!
Par contre si tu fais de l'animation limitée, alors tu feras juste bouger la bouche (et probablement un peu les yeux et les sourcils, souvent même de manière exagérée pour rajouter de "l'émotion" à moindre frais et effort).
Un exemple classique d'animation traditionnelle limitée, ça sera les Simpson. Dans leur cas, c'est clairement une raison financière/temporelle (ils ont un rythme soutenu d'épisodes) et accessoirement ça appuie bien le fait que le style graphique n'est pas l'intérêt de cette série (leur point fort, c'est surtout les scénarios comiques, et bien sûr aussi la satyre de société; mais sûrement pas le graphisme).
À tel point qu'ils font régulièrement de la blague méta sur la qualité "médiocre" de leur animation (je me rappelle d'au moins une scène où ils auto-critiquaient leur animation en ajoutant des erreurs exprès mais je trouve pas de référence sur le web; ceci dit même sans ça, on voit des vraies erreurs dans plein d'épisodes! ;P) et aussi sur le fait qu'ils sous-traitent leur animation en Corée du Sud (cf. la fameuse blague du canapé sur l'esclavage des animateurs coréens, blague auto-critique qui avait fait grincer quelques dents).
Ensuite tout cela est un choix. Faire de l'animation limitée n'est pas un problème (d'ailleurs j'aime beaucoup "Les Simpson"!) et à un moment donné, on a aussi regretté d'être parti sur de l'animation trop détaillée car ça prend trop de temps. Sans faire de l'animation limitée pour autant, on aurait aussi pu se décider sur un entre-deux. Mais c'était trop tard. Changer le style d'animation, ça veut dire jeter tout le travail d'animation qui a déjà été fait.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# 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.
Merci pour la mise en dépêche, je m'y attendais pas du tout, surtout que notre organisation est clairement pas encore stabilisée (notamment à part annoncer chaque début de streaming sur les réseaux sociaux, on sait pas bien encore comment organiser les horaires).
Quoiqu'il en soit, pour la 3ème journée consécutive, Aryeom vient de redémarrer le flux de visionnage de son travail: https://www.youtube.com/c/LibreArtInfo/live
Bon visionnage! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Liens d'après-streaming
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 2.
Salut,
que veux-tu dis exactement? Je vois bien que RTSP est un protocole de streaming, apparemment pour contrôler un serveur de streaming à distance, ce qui semble en effet correspondre aux fonctionnalités d'OBS. Mais je sais pas vraiment ce que tu entends par "un export en RTSP"?
Ensuite j'y connais rien. Aryeom a cherché/trouvé et configuré elle-même OBS et j'ai quasi rien fait dans l'histoire (bon dans le déroulement de l'action, en suivant un tuto, elle a réussi à pêter une fois son système Linux en réinstallant les drivers NVidia, et on a été obligé de réinstaller la distribution, mais hormis ce passage où j'ai aidé, elle a tout fait) donc j'y connais pas grand chose dans les technos de streaming.
En tous cas, Youtube semble utiliser RTMP, apparemment un autre protocole de streaming (pas sûr du recoupement des fonctionnalités entre RTSP et RTMP, ou même si les 2 protos servent à la même chose; comme j'ai dit, j'y connais rien).
Ensuite quand je cherche "RTSP OBS" sur le web, y a des réponses. Donc il y a l'air d'y avoir prise en charge, même si je comprends bien pas le détail du rôle de ce protocole dans le streaming.
Note que quand je dis que je comprends pas beaucoup, c'est aussi beaucoup que je cherche pas tant que ça à comprendre. J'espère surtout que ça marche sans poser trop de questions justement. ;-P
Le jour où j'essaierai de comprendre la place de chaque protocole, ce sera quand y aura un problème et que j'essaierai de débugger, voire patcher (OBS ou autre). Pour ma sanité d'esprit et mon temps libre, j'espère que ça n'arrivera jamais! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et c'est reparti pour un tour!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 2.
Faut qu'on trouve une manière de les diffuser sans spammer trop (car on va le faire très régulièrement).
Une méthode peut être simplement de s'inscrire au canal LILA sur Youtube car je pense qu'à chaque fois qu'un streaming débute, des notifications automatiques sont envoyés aux inscrits (à confirmer).
Sinon on peut simplement avoir des jours/horaires fixes, mais c'est pas vraiment la façon dont on aime procéder. On va trouver une solution! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Liens d'après-streaming
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 6.
J'essaie de comprendre la remarque.
Est-ce du fait de l'utilisation de Youtube? Si c'est le cas, nous avons juste ni les serveurs ni le temps/argent pour héberger nos propres serveurs de streaming. On fait déjà trop de choses et on aimerait en faire plus (d'ailleurs ceux qui financent le projet, je pense que beaucoup préfèrent que mon temps soit utilisé pour améliorer GIMP plutôt que pour mettre en place/configurer/sécuriser un serveur de streaming).
Je dis ça, on héberge déjà nos emails, un cloud, nos serveurs web… et c'est déjà 1000x trop. :-/
Si un jour, on est un gros studio avec nos propres admins, je dis pas. Bien au contraire. :-)
Mais pas aujourd'hui.
Sinon on peut voir les alternatives à Google. Un pote m'a parlé de Twitch, mais Aryeom avait déjà fait plein de tests avec Youtube, et… encore une fois, on a préféré ne pas perdre plus de temps que ça parce qu'elle avait mis pas mal d'heure à mettre en place tout son système de streaming.
Dans tous les cas, il s'agit d'un vrai streaming, si. Du bon live en direct, où on peut même poser des questions dans le chat (bon c'est plutôt moi qui répond dans 90% des cas quand je regarde entre 2 patchs; Aryeom ne regarde pas son propre streaming pendant qu'elle bosse). On a même eu quelques crashs d'OBS (le client libre pour le streaming que nous utilisons) en direct aujourd'hui, etc. ;P
C'est même pour cela que je précise bien que cela peut être un peu chiant des fois, car on voit du vrai travail fait en temps réel, sans accélération ni édition.
Ces liens plus haut sont simplement les enregistrements après-coup des streamings (que Youtube enregistre automatiquement), d'où le titre "liens d'après-streaming".
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 reparti pour un tour!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 6.
Et voilà toujours le même lien! Ça a eu un peu de succès hier, alors on continue sur la lancée. ;-)
https://www.youtube.com/c/LibreArtInfo/live
Faudra qu'on voit comment mieux organiser la diffusion des streamings puisqu'on va faire ça régulièrement à partir de maintenant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Liens d'après-streaming
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal ZeMarmot lance un petit programme de streaming régulier!. Évalué à 10.
Pour info, les streamings sont sauvegardés:
(1) https://www.youtube.com/watch?v=unfKhAOZB8k
(2) https://www.youtube.com/watch?v=yZPjVTI0w8g
(3) https://www.youtube.com/watch?v=1ZbohkDZfd4
Nous essaierons d'en faire une habitude pour que les gens puissent suivre un peu le travail en cours. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Énorme!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 6.
Pour info, je viens de jeter un œil rapide et il semble que le dév de Photoflow ait fait un plug-in avec la nouvelle API de GIMP: http://photoflowblog.blogspot.fr/2017/02/the-new-photoflow-gimp-plug-in-interface.html#more
En installant ce plug-in, il sera donc possible d'utiliser Photoflow comme plug-in raw au même titre que les autres. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 10.
C'est juste une petite blague inoffensive et on parle là d'une petite image vectorielle de 130KB sur le site d'un éditeur d'image et de peinture moderne. Presque n'importe quelle image sur la page d'accueil (celles en bandeau) est plus lourde (alors qu'y en a plusieurs).
Parler de sur-armement matériel pour cette petite blagounette animée de 130kb sur le site d'un logiciel d'imagerie me paraît être un sur-armement lexical. :P
P.S.: en plus sur un site entièrement statique, qui ne pratique donc pas de surarment côté serveur!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Financement du développement seul
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 10.
Je suis d'accord avec tout ce que tu dis. Ce n'est pas moi qu'il faut convaincre. ;-)
Ceci dit, j'ai fait une recherche dans mes emails et ai aussi retrouvé une discussion avec Ton en 2015, que j'avais oubliée. Elle confirme les positions de la fondation Blender qui veut se limiter aux projets Blender, bien que Ton laissait ouvert un futur possible où aider un projet GIMP (de manière exceptionnelle) n'était pas totalement hors de question. Peut-être un jour, donc. Il disait qu'en tous cas ce n'était pas possible à l'époque avec l'état des finances. Peut-être maintenant, qui sait.
Donc comme je dis, je réessaierai sûrement dans quelques mois.
Mais dans tous les cas, comme je disais, j'ai appris à ne pas mettre trop d'espoir dans une direction particulière. Tout ce que tu me dis, je le sais, et suis d'accord, et ai tenté maintes fois. Si ça marche, tant mieux, mais faut bien savoir que les chances sont faibles car les projets ont tous leurs priorités. Tu parles de "Red Hat, Canonical ou SUSE" qui investissent dans des projets tiers sans rapport directs avec eux, mais pour un tel petit projet qui rentre dans le système (et qui d'ailleurs est souvent un projet maintenu par un employé dans son temps libre, donc ce n'est pas forcément totalement sans rapport), et qui fera pas mal parler de lui (donc effectivement fait de la pub pour le projet sponsor), combien sont refusés?
Que ce soit Blender, RedHat ou Canonical, et plein d'autres gros acteurs du Libre, j'avais tenté de les contacter, sans succès. En fait, je crois que j'ai contacté (souvent à plusieurs reprises) tous les gros et moyens projets (entreprises ou fondations) de l'écosystème Libre. J'ai même mis en page de bons dossiers complets en PDF, avec images, et liens vidéos, pour expliquer notre projet, ce qu'il en ressort pour le libre, l'intérêt pour le sponsor (en personnalisant pour chaque sponsor souvent), etc. Ça n'a à ce jour rien donné, par contre cela m'a pris un temps fou. Je ne dis pas que ça ne donnera jamais rien. Peut-être qu'un jour, à force de la contacter, une entreprise/fondation qui a refusé (ou pas répondu) plus tôt décidera de nous aider. Par exemple quand on sortira davantage du lot. Simplement j'ai appris à ne pas mettre trop d'espoir, à perdre trop de temps et à donner trop de valeur à ce type de contacts car au final, les quasi-seuls financements et aides d'autres types qu'on ait jamais réussi à obtenir, ce sont ceux qu'on n'a jamais demandés et les financements participatifs, et principalement de la part de particuliers (même si y a aussi quelques entreprises dans les sponsors du premier financement, et même quelques associations, surtout dernièrement).
Dans les faits, chaque entreprise/fondation a tout de même des objectifs et essaie de ne pas diverger trop. Ils font quelques gestes vers la communauté, mais cela reste limité. C'est d'ailleurs aussi compréhensible (surtout pour une fondation de la taille de Blender qui commence à être connue mais n'est pas non plus un acteur si gros encore qu'elle peut se permettre de trop diverger sans quelques risques, je pense).
Voilà. Ce sera ma dernière réponse sur ce sujet car y répondre aussi me prend trop de temps.
Je ne dis pas que tu as tort. Au contraire, je suis d'accord. Mais faut garder la tête sur ses épaules sur ce genre de sujet, surtout quand on est une très petite équipe (et que donc se disperser a un coût non négligeable). On a tout essayé maints et maints fois. On continuera, mais avec modération.
La vision que tu présentes du libre est un peu utopique à mon avis (et moi aussi je l'avais).
Cela étant dit, je t'invite à leur parler de nous (sur les réseaux sociaux par exemple). :-)
Je pense que si plein de gens parlaient régulièrement de ZeMarmot à Ton/Blender, un jour si je le recontacte, il se dira que oui, ZeMarmot a l'air d'être un projet avec de l'avenir (car il en aura entendu parler à maints reprises par des inconnus) et que la fondation Blender a tout à y gagner à nous aider. Sa position pourrait être beaucoup plus enthousiaste pour un projet dont il entend beaucoup parler.
Cela vaut pour RedHat, Canonical, et d'autres entreprises ou Fondations. Je pense que si 100 inconnus parlent de ZeMarmot à Ton, ce sera 100 fois plus impactant que si moi, en tant que représentant du projet, je lui en reparle 10 fois.
En fait, cela commence doucement. Plus de personnes parlent de nous maintenant sans qu'on soit de la discussion. C'est bien. Et c'est comme ça qu'on va peut-être rentrer dans le radar de ces autres gros acteurs.
Je conclurai par un conseil que je donne aux gens qui sont intéressés par le financement de projet: je crois que la meilleure qualité à avoir, c'est l'endurance (et toutes les variantes: l'obstination, la constance, persévérance…). Si tu fais quelque chose publiquement pendant des années et des années, au fur et à mesure, de plus en plus de gens te voient. De plus en plus de gens te suivent. Il n'y a pas de recette miracle. Il n'y a pas d'aide miracle non plus (que ce soit la fondation Blender ou autre). La plupart des gros projets sont nés ainsi d'ailleurs.
L'une des rares choses qui peut accélérer cela est si on a déjà beaucoup d'argent (c'est pas notre cas). Une autre chose est la chance. Mais je suis de ceux qui pensent que la chance, on se la crée soi-même (justement en étant persévérant). Donc ça boucle.
Si un jour la Fondation Blender nous aide, je saurai juste que c'est parce qu'on a su persévérer suffisamment longtemps, plus que par une rhétorique quelconque (aussi vraie soit-elle).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Financement du développement seul
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 6. Dernière modification le 16 décembre 2017 à 17:51.
J'ai eu à plusieurs reprises des échanges avec Ton Roosendaal, mais pas sur le sujet de la collaboration, me semble-t-il. Il est au courant de notre projet (notamment il a tweeté une fois au moins dessus). En gros, non, on n'en a jamais vraiment parlé.
Ceci dit, eux sont intéressés par Blender (c'est normal, leur fondation a été créée dans le but d'améliorer Blender, pas d'autres Logiciels Libres, ni pour l'Art Libre, à l'inverse de LILA) et je ne suis pas sûr qu'ils voient un grand intérêt (au sens de l'intérêt de la fondation) à notre film. Personnellement, probablement (le tweet de Ton disait justement que notre projet avait le bon esprit), mais pas pour la fondation. Ensuite c'est pas forcément vrai. Les films d'animation 2D modernes ont souvent un peu de soutien 3D dernièrement (par ex pour les scènes avec beaucoup de rotation, genre caméra qui tourne autour d'un perso qui court, une des grandes faiblesses de la 2D dessinée à cause de la difficulté des changements de perspective; ou pour les backgrounds de scènes, notamment de type bâtiments; etc.) et si on avait des fonds, on prévoyait de faire de même (on a des contacts Blender, cf. notre page de film par exemple qui donne un nom d'une telle personne dans "l'équipe", même si dans les faits, ça n'a jamais pu se faire à ce jour car on n'a pas de quoi payer). Peut-être qu'on pourrait tenter une collaboration, mais je pense que ce ne sera intéressant de leur proposer qu'après la sortie du pilote.
Quant aux aides de type marketing, oui ils peuvent nous aider s'ils parlent de nous, bien sûr. Mais si on est pas un projet de la fondation, ils voudront probablement pas! Et en fait, je viens soudainement de me rappeler que si, je leur avais déjà demandé (je laisse quand même mon erreur précédente pour une trace du cheminement de pensée!). Il me semble que c'était pour un autre petit projet avec du Blender. Je leur avais demandé s'ils pouvaient nous faire un peu de pub. Laisser un petit post sur le site par exemple, pour aider le financement d'un "projet ami". Et on m'avait aimablement refusé car ils ne font que de la promotion des projets de la fondation même.
Note que je ne leur en veux pas, c'est compréhensible. Y a beaucoup de projets tiers, et si on se met à parler de tous les projets, déjà ça n'en finit plus, ensuite ceux dont on ne parle pas se sentiront laissés pour compte. Je pense qu'en fait, la vraie réponse, c'est qu'ils ne feraient que de la pub de projets qui sortent vraiment du lot en utilisant Blender (ce qui leur permet donc en même temps de faire de la pub pour Blender même), donc de projets déjà avec un bon succès. C'est un peu comme ça que le monde marche: on n'aide pas les petits, seuls ceux qui sont déjà grands (c'est à la fois triste et à la fois compréhensible, comme je le disais. Un peu la version réaliste du "aide toi, le ciel t'aidera").
Quoiqu'il en soit, je pense réessayer de rentrer en contact avec eux après la sortie du pilote. Il reste des possibilités, et notre pilote aiderait pour la partie "sortir du lot". Mais dans tous les cas, je ne souhaite pas "miser" sur ce type d'aide seulement. J'ai appris avec le temps que la seule aide réellement fiable, c'est soi-même qui la crée (même l'aide financière, c'est en général car on a d'abord réussi à prouver qu'on la vaut que les gens acceptent de nous financer). Il ne faut pas trop dépendre des autres et espérer des "miracles". Cela marche rarement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Financement du développement seul
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 10.
Et pourtant… j'ai eu plusieurs commentaires de la sorte. Y a aussi le cas de ceux qui croient que ce qu'on fait ne touche que l'animation ou le dessin et donc ne changera rien à leur utilisation (photo par exemple). Y a justement le cas un peu plus haut en commentaire de cette news.
J'y ai pensé, mais déjà, ce serait une sorte de mensonge. Mon travail est essentiellement collaboratif et si jamais en faisant cela, le financement du film reste bas et on décide de l'arrêter, même si on me donnait beaucoup de sous pour du dév GIMP général seulement, ben je voudrais arrêter aussi probablement. Les gens ne comprendraient pas parce que je leur aurais promis du dév général de GIMP en mon nom (et ils auraient donc raison de ne pas comprendre). Je veux pas leur mentir et donc je suis clair dès le début: on fait ZeMarmot, en conséquence de quoi on améliore GIMP énormément et continuellement. C'est ça le vrai projet.
Je fais ça parce qu'on utilise GIMP, et on a nos priorités effectives. Cela ne nous empêche pas de faire du dév général au passage, bien au contraire. C'est une conséquence évidente car le logiciel doit marcher bien globalement pour marcher bien dans notre cas d'usage. Mais ça n'empêche que je veux garder notre priorité en tête.
Pour moi, ma motivation principale de contribution à un logiciel, c'est parce que je l'utilise et rencontre un problème ou un manque. J'ai plusieurs patchs dans Blender car on avait des crashs avec certains exports de format (de mémoire); un patch dans Firefox (pour un truc que finalement je n'utilise pas; mais à l'époque c'était pour ça); des patchs dans mplayer puis mpv pour des fonctionnalités dont j'avais besoin car ce sont mes lecteurs vidéos de choix (enfin mplayer l'était, maintenant je suis passé à mpv); etc. Je patche, car j'utilise, pas juste pour me faire plaisir (même si ça me fait aussi plaisir accessoirement). C'est comme ça. GIMP et ZeMarmot, c'est donc pareil. :-)
Autre point: on a déjà 3 plateformes de financement (on en avait 2 jusqu'à y a quelques jours, mais après les problèmes de Patreon ce mois-ci, et comme plusieurs personnes nous parlaient de Liberapay, on vient d'y ouvrir un compte)!. Et franchement c'est lourd en gestion. On n'est pas une entreprise, on n'a pas de service de gestion et compta dédié. C'est nous qui faisons un peu tout (avec des bénévoles de LILA qui aident). Je préfère aussi éviter de diviser encore plus avec un financement séparé.
Finalement, dernier point: j'aime le travail d'équipe. J'aime que les gens savent qu'on bosse à plusieurs et c'est pour ça que ce qu'on fait est d'autant plus cool au final. Dans GIMP, non c'est pas moi qui code tout. On a quelques autres dévs très prolifiques (et très très bons), et j'adore aussi faire de la revue de code pour des contributions uniques de qualité. C'est aussi gratifiant d'intégrer un patch de quelqu'un d'autre que de coder moi-même quelque chose (même si mon nom n'apparaît que dans le second cas, le travail est parfois aussi important en revue de code).
Pour ZeMarmot, c'est pareil. C'est du travail d'équipe. Aryeom peut dessiner car elle a un logiciel à la hauteur car des gens comme moi le corrigent et implémentent des fonctionnalités utiles. Réciproquement je fais de bonnes corrections car Aryeom me dit que non, ça, ça va pas, etc. Il m'est arrivé plusieurs fois de jeter des heures de code d'un truc que je croyais trop cool car, quand je le montre à Aryeom, elle me démontre qu'en fait ça lui compliquera la vie (et donc à d'autres aussi); ou de changer complètement certaines implémentations après qu'elle me fait la bonne remarque que ça pourrait être beaucoup mieux comme ci ou ça (et c'était vrai!).
C'est un travail d'équipe, c'est la réalité et il ne faut pas la nier. Je veux donc faire un financement d'équipe, et pas en mon nom propre. C'est comme les groupes de musique au nom d'un unique musicien/chanteur star, j'ai toujours trouvé ça triste et pas cool (même si le musicien est peut-être exceptionnel, là n'est pas la question). Y a une équipe, faut un nom de groupe. Ben là, pareil. ZeMarmot, c'est pas juste moi. On est un groupe, et j'aime ça.
Mon rêve, ce serait qu'on passe le stade de 2 personnes. Un jour, si on a suffisamment de financement, on pourrait avoir un studio avec beaucoup d'artistes et aussi beaucoup de développeurs, et on corrigerait plein de bugs et implémenterait des fonctionnalités cools dans plein de logiciels (pas juste GIMP; on utilise Linux, et que des logiciels libres; tout ce qu'on utilise et qui ne marche pas suffisamment bien pourrait devenir une cible de contribution si on avait suffisamment de développeurs).
C'est mon petit rêve perso. Mais ça ne peut se faire que si on passe le stade d'arriver déjà à financer au moins 2 salaires (on en est encore loin!). Et donc ça ferait une équipe encore plus grande. Faire un financement pour moi seul serait donc contre-productif et dans la mauvaise direction. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Une build !
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche En route vers GIMP 2.10. Évalué à 3.
Cool merci.
Je retrouve pas cet email. Normalement je fais la revue de tous les emails reçus par l'asso et essaie d'y répondre personnellement (bien que je croule aussi sous les emails, donc des fois, il m'arrive de les remettre à plus tard, puis d'oublier de répondre).
Tu peux m'envoyer un email, par exemple à jehan chez GIMP (nom de domaine du logiciel), qui est un alias vers mon adresse principale. Et oui bien sûr, y aura pas de problème pour te donner un accès à mon build flatpak. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]