Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.2 du 14 mars 2026 (en anglais).

Nous sommes heureux de vous présenter la première version de GIMP 3.2 ! (NdM: et même la 3.2.2 depuis)
Cette version est le fruit d'une année de conception, de développement et de tests réalisés par des bénévoles et la communauté, conformément à notre plan visant à simplifier le rythme des mises à jour après GIMP 3.0.
Nous avons hâte de vous faire découvrir les nouvelles fonctionnalités de la version 3.2 !

Image de démarrage de GIMP 3.2, par Mark McCaughrean (CC by-sa 4.0)

Changements majeurs

Voici quelques-unes des nombreuses nouveautés à découvrir lors de la première utilisation de GIMP 3.2 :

• Nouveaux calques non destructifs !

  • Vous pouvez désormais utiliser les calques liés pour intégrer des images externes à vos compositions. Redimensionnez, faites pivoter et transformez-les facilement sans perte de qualité ni de netteté. Le contenu du calque lié est mis à jour lorsque le fichier source est modifié.
  • L'outil Tracé peut maintenant créer des calques vectoriels, vous permettant de dessiner des formes avec des paramètres de remplissage et de contour ajustables.

• L'outil Pinceaux de MyPaint a été mis à jour : 20 nouveaux pinceaux sont disponibles et il s'adapte automatiquement au zoom et à la rotation de votre zone de travail pour une peinture plus dynamique.

• Un nouveau mode de peinture « Écraser » vous permet de dessiner par-dessus les couleurs existantes sans mélanger leur transparence.

• L'éditeur de texte intégré à la zone de travail bénéficie de plusieurs améliorations de flux de travail. Vous pouvez désormais déplacer l'élément à votre guise sur la zone de travail et utiliser de nombreux raccourcis courants, tels que Ctrl + B pour le texte en gras et Maj + Ctrl + V pour coller du texte non formaté. La fonction Contour du texte inclut également davantage d'options pour contrôler la direction du contour.

• Prise en charge de nouveaux formats de fichiers et améliorations des formats existants, comme l'exportation DDS BC7 et l'importation de davantage de styles de calques pour les fichiers PSD. Grâce aux calques vectoriels, nous prenons désormais en charge l'exportation SVG et proposons des options vectorielles étendues pour l'exportation PDF.

• Diverses améliorations de l'expérience utilisateur (UX) et de l'interface utilisateur (UI), basées sur vos commentaires et le travail de notre équipe de conception. En voici quelques exemples :

  • Possibilité d'utiliser les couleurs du thème pour les vignettes des pinceaux lors des aperçus, pour une meilleure expérience avec les thèmes sombres.
  • Possibilité de glisser-déposer des images sur l'onglet Image pour les ouvrir dans GIMP.
  • Prise en charge des raccourcis clavier pour les outils Cisaillement et Retournement.
  • Nouveau thème de couleurs « Système » qui adapte automatiquement les couleurs du thème de GIMP à celui défini pour votre système d'exploitation.

• Le sélecteur de couleurs CMJN affiche désormais la « Couverture d'encre totale » de votre couleur, facilitant ainsi les ajustements lors de l'épreuvage écran, en fonction de la limite de couverture d'encre de votre imprimante.

• Pour les développeurs de scripts et de modules complémentaires, un nouveau explorateur de filtres GEGL a été ajouté afin de simplifier la recherche de filtres non destructifs.

En savoir plus

Nous avons préparé les notes de version qui détaillent toutes les modifications, améliorations, nouvelles fonctionnalités et bien plus encore. Pour encore plus d'informations, consultez le journal des modifications des versions de développement 3.1 et 3.2.

Mais pour le découvrir par vous-même, téléchargez GIMP 3.2 directement depuis notre page de téléchargements et testez-le !

Autres versions connexes

Pour accompagner la sortie de GIMP 3.2, les responsables de paquets doivent savoir que nous avons également publié :

• babl 0.1.124 (tarball)

• GEGL 0.4.68 (tarball)

Nous ne disposons pas encore d'une documentation prête à être diffusée pour cette version 3.2.

Nous vous recommandons de continuer à utiliser la documentation en ligne de la version 3.0 pour le moment.
Nos contributeurs travaillent activement à l'amélioration de la documentation.
Toute contribution est la bienvenue sur notre projet gimp-help afin d'accélérer le processus !

Profitez de GIMP 3.2 !

GIMP 3.2 s'appuie sur les bases posées par GIMP 3.0, offrant de nouvelles fonctionnalités exceptionnelles et préparant le terrain pour des nouveautés encore plus impressionnantes dans les versions futures !

Télécharger GIMP 3.2

Remarque : la livraison des paquets sur les plateformes de téléchargement peut prendre un peu plus de temps, car ils sont peut-être en cours de vérification.

Soutenez le développement de GIMP

N'oubliez pas que vous pouvez faire un don et soutenir financièrement les développeurs de GIMP, afin de
contribuer et d'accélérer le développement de GIMP. L'engagement de la communauté est essentiel à la réussite du projet !

Cette dépêche raconte un vieux bug que j’ai eu sur un satellite. L’identification, la reproduction, la correction. C’est le bug qui m’a le plus intéressé/marqué dans ma carrière (jusqu’ici), C’est pourquoi cela pourrait aussi vous intéresser.

L’appel

Il y a bien longtemps, dans une galaxie lointaine. Ah non, pardon. Un long weekend de 14 juillet, sur une plage, je reçois un coup de fil : « Un des satellites a rebooté, à cause d’une erreur logicielle, est-ce que tu es disponible pour venir comprendre ce qu’il s’est passé ? A priori, il fonctionne toujours, mais il est passé tout seul sur le calculateur redondant. »

Quelques mois avant, on avait lancé une première grappe de six satellites ; d’autres lancements sont prévus pour compléter une constellation dans les mois/années à venir. Comme tout marche bien depuis des mois, personne de l’équipe logiciel de bord n’est d’astreinte. Sur ces satellites, j’étais surtout sur la partie validation. En gros, ce jour-là pour moi, ce n’était pas possible, mais j’y suis allé le lendemain, un samedi ou dimanche.

Sommaire

• L’objectif et les moyens de débug
• L’analyse
• EDAC / Protection contre les SEU
• L’hypothèse
• Chez moi, ça marche
• L’erreur
• La reproduction
• La correction (Over-The-Air, mais sans l’air)
• Conclusion

L’objectif et les moyens de débug

Si nos managers nous ont appelé, c’est parce quand un satellite bugue en prod (on va dire en vol, plutôt), c’est comme pour n’importe quel autre logiciel, des gens veulent des réponses à des questions comme :

• pourquoi ?
• est-ce que c’est grave ?
• est-ce que ça va se reproduire ?
• comment on corrige ?

Par contre, les moyens sont potentiellement différents de ce que vous avez dans d’autres environnements (ou pas, j’imagine que ça dépend des gens) Ce qu’on a :

• le code
• la doc
• des bancs de tests (avec le même matériel pour le calculateur)
• des gens
• un tout petit peu de contexte logiciel sauvegardé au moment de l’erreur (j’y reviens)
• la télémétrie avant l’anomalie (tout allait bien)
• la télémétrie après l’anomalie (tout va bien, mais on est passé du mode matériel 2 au mode 3. En gros c’est le même, sauf qu’on utilise certains équipements “redondants” au lieu du “nominal”, dont le calculateur)

Premier élément, qui a mené au fait que c’est nous (du logiciel) qui avons été appelés, c’est que le matériel qui gère le mode (2 -> 3) peut changer de mode pour plusieurs raisons, mais il sait pourquoi il le fait. Et la raison c’est « le logiciel m’a dit de le faire ». Donc ça vient de nous.

L’analyse

Comme tout va bien, on va regarder le contexte sauvegardé. Ce n’est pas un core dump qu’on peut passer à gdb, mais ça contient quelques infos :

• le code de l’erreur ILLEGAL CPU INSTRUCTION
• le Program Counter %pc qui nous donne l’adresse de l’instruction exécutée au moment de l’erreur
• l’adresse de la prochaine instruction à exécuter %npc (ici c’est l’adresse juste après %pc, rien de surprenant)
• une copie des registres (bon, on ne va pas en avoir besoin, donc je ne vous fais pas un cours sur SPARC et ses registres tournant, de toute façon j’ai oublié. On pourrait probablement les utiliser pour récupérer partiellement la pile d’appel, on l’a surement fait)
• la date et l’heure (super info utile. Enfin, ça correspond à notre anomalie, j’imagine que c’est pour ça qu’on l’avait)
• surement d’autres choses, mais pas utiles pour la suite.

Problème résolu donc ? on est à l’adresse %pc, on l’exécute et le CPU nous dit que l’instruction n’est pas légale. Qu’est-ce qu’il y a ici ? Une instruction légale, quelle que soit la valeur des registres. Pareil pour un peu plus haut et un peu plus bas, rien qui provoque cette erreur. Que s’est-il passé ?

On est dans l’espace, donc l’explication facile (dès qu’on n’explique pas un truc) : l’instruction a dû avoir un Single Event Upset (SEU), un bit flip. Ça a transformé une instruction légale en instruction illégale. C’est simple ? Sauf que non, on est dans l’espace, en conséquence, on a tout un mécanisme de protection contre les SEU. C’est pas infaillible (par exemple si on a deux bits inversés, on ne peut pas corriger) mais ce n’est pas la bonne signature. Si c’était ça, ça dirait DOUBLE EDAC ERROR, pas ILLEGAL CPU INSTRUCTION.

Donc la cause de l’anomalie n’est pas un SEU.

EDAC / Protection contre les SEU

Je suis sûr que vous êtes intéressé, donc je vais vous décrire la protection contre les bit flips. C’est un mix de matériel/logiciel (en plus d’avoir une boite autour qui diminue la probabilité). En mémoire (RAM, ROM) pour 4 octets de données “utiles”, on consomme 5 octets. Le 5ᵉ octet contient un code de contrôle calculé à partir des 4 autres (EDAC). Si un bit change (sur les 5 × 8 = 40 bits), on peut non seulement le détecter mais aussi reconstruire la valeur correcte. Si deux bits changent (ou plus, mais il y a une limite), on peut détecter l’erreur mais pas la corriger (cf: le DOUBLE EDAC ERROR mentionné plus haut)

C’est complètement transparent vu du logiciel (code source, ou assembleur), tout ça est calculé par le matériel. Quand on écrit en mémoire 0x12345678 il calcule le code et écrit 0x12345678XY avec la bonne valeur de X et Y. Quand on lit, pareil, le matériel commence par lire 0x12345678XY, calcule la somme de contrôle sur les 4 octets, si c’est le bon, il nous donne 0x12345678.

Là où ça se complique, c’est quand il y a un changement. Disons qu’on a maintenant 0x02345678XY. (1 --> 0). Il se passe deux choses ici :

1. le matériel dit au logiciel 0x12345678 (il corrige, mais uniquement la valeur envoyée au software. Pas la valeur enregistrée en mémoire)
2. il émet un signal SINGLE EDAC ERROR.

C’est là que le logiciel intervient, dans le point 2. Ce signal est lié à une trap qui corrige la mémoire. Schématiquement c’est lié à une fonction qui ressemble à ceci (en assembleur SPARC en vrai, mais j’ai tout oublié)

; adresse vient du contexte, c’est l’adresse qui a été lue en dernier, qui a généré la trap
disable_edac_trap: ; Désactiver la trap. Sinon on déclencherait la trap depuis la trap
load [adresse], reg ; Lire 4 octets (lecture = correction auto)
enable_edac_trap: ;
store reg, [adresse] ; Réécrire la valeur corrigée

On lit la valeur, c’est corrigé vu du logiciel par le matériel, on réécrit la valeur, tout est corrigé.

Cette trappe peut être déclenchée par n’importe quelle instruction qui lit de la mémoire (ou par le fait de charger une instruction elle-même depuis la mémoire), et on a même une tâche de fond (plus basse priorité, qui tourne en permanence quand il reste du temps de calcul disponible) qui fait

// en gros. En vrai légèrement plus compliqué
void background_task(void) {
int address = MEMORY_START;
volatile int value;
while (1) {
value = *address; // s’il y a un bit flip en mémoire, ce sera corrigé par la trap
address += 4;
if (address >= MEMORY_END) {
address = MEMORY_START;
}
}
}

L’idée de cette fonction c’est de lire la mémoire régulièrement. Si on ne faisait pas ça, peut-être que certaines cases mémoires auraient deux bit flips, car pas corrigé après le premier si on ne lit pas la mémoire avant qu’un autre arrive. Ce n’est pas très fréquent d’avoir des bit flips, mais sur les 6 satellites, en cumulé, on en détecte quelques-uns par jour.

L’hypothèse

De retour à la case départ donc. On exécute apparemment l’instruction stockée dans %pc, valide. Et le CPU nous dit qu’elle est invalide, mais clairement, elle est valide. On tourne en rond, on est samedi ou dimanche, fin d’après midi, et le satellite, lui aussi il tourne en rond, sans problèmes. Tout à coup, quelqu’un a l’idée de dire « bon, on ne résoudra pas ça aujourd’hui. On se revoit lundi ? ». On rentre, je bois un verre avec mes colocs (enfin, je suppose. C’était une activité habituelle pour un weekend, ça, au moins)

Retour au bureau, et là (surement plus tard, pas lundi 9h) on a David (un collègue) qui propose : "Comme clairement %pc est valide, est qu’on exécute quelque chose d’invalide, est-ce qu’on est sûr qu’on a bien enregistré %pc?". On vérifie, le code qui fait ça a l’air correct. En plus le contexte général, ce qu’il y a dans les registres est correct. Toujours David "OK, le logiciel est correct, mais est-ce qu’on est sûr que %pc c’est bien toujours l’instruction qu’on exécute ?".

Donc, on vérifie, par acquit de conscience et on remarque que non, pas nécessairement. Si on est dans une trap, le %pc qu’on enregistre pointe vers l’instruction qui a provoqué la trap, pas l’instruction de la trap qu’on exécute. Bon, OK, ça ne nous avance pas nécessairement (mais si j’en parle…)

Nouvelle question donc : Si on est à %pc, quelles sont les traps qui peuvent s’exécuter ? Il y a plein de possibilités, la plupart viennent de causes extérieures (timer matériel, plein d’autres évènements extérieurs) et potentiellement aussi la trap de l’EDAC si on lit une valeur (et l’instruction à %pc lit une valeur).

Donc techniquement, on pourrait aussi être n’importe où dans le code (assembleur) de toutes les traps. Avant on cherchait pourquoi c’était illégal d’exécuter %pc, maintenant on cherche pourquoi ça serait illégal d’exécuter %pc ou n’importe quelle ligne d’une trap active/activable à ce moment-là.

Chez moi, ça marche

Sauf que le code des traps, c’est pas nous qui l’avons écrit. C’est bien du code qui vient de l’entreprise, mais il existe depuis plusieurs années, est utilisé sur le même processeur depuis plusieurs années, et il a plusieurs dizaines d’années de vol (cumulé, en additionnant les satellites) sans problème.

En suivant les principes bien connus du développement logiciel, si on utilise un logiciel sur étagère, pas besoin de le valider (surtout ça coute de l’argent. Cela dit même si on avait essayé, je ne pense pas qu’on aurait trouvé de problème), vu qu’il marche. Par acquit de conscience, on demande, et on nous répond "bah chez nous ça marche" (la légende veut qu’une histoire similaire soit à l’origine de Docker, je ne sais pas si c’est vrai, mais le fameux "it works on my desktop, ship my desktop"…)

Vous avez peut-être lu le titre de l’article, donc vous imaginez où je vais. On se demande « OK, pourquoi ça marche pour eux, et pas pour nous ? » Quelles sont les différences ?

• on est sur le même CPU/MCU (donc non, c’est pas ça)
• on a changé de compilateur pour une nouvelle version (mais 1. c’est un compilateur “certifié”, et 2. les traps sont en assembleur…)
• on est en orbite plus basse, et on a plus de SEU (mais même, quand on regarde leur historique, ils en ont beaucoup aussi, et en cumulé, beaucoup plus. Après… peut-être n’a-t-on pas de chance ?)

L’erreur

Ok, on a changé de compilateur, les traps sont en assembleur, mais le reste du code est dans un langage bien plus courant (non, je rigole, en vrai c’est en Ada…), peut-être que l’interaction entre les traps et le reste du code a changé ?

Pourquoi est-ce qu’on a décidé de changer de compilateur ? Ah pour des histoires de taille mémoire (640 kB should be enough? On avait même plus, genre 2 Mo de ROM, 4 Mo de RAM, large… ou pas). D’ailleurs, au moment du changement, on en a profité pour faire quelques optimisations. Non pas des flags genre -O1 ou -O2. Plus des choses sur le layout mémoire, on a ajouté __attribute__((packed)) qui est supporté, on a un peu changé le linker script…

Par exemple, le packed, ça nous permet de gagner de la place, avant toutes les variables étaient alignées sur une adresse multiple de 4, que ça soit un nombre sur quatre octets, ou un char d’un octet, ils prenaient au moins quatre octets. Maintenant, on a mis les data types multiples de quatre au début de la structure, bien alignés, puis les types qui prenent deux octets, on en met deux dans quatre octets (au lieu d’un et de gacher deux octets pour rien), puis les types de un octect, on en met 4.

D’ailleurs, par exemple, l’instruction à %pc, elle charge une donnée d’un seul octet qui est dans une adresse du type XXX+3, où X est un multiple de 4. C’est pas illégal de faire ça (donc non, toujours pas d’instruction illégale ici)

Après quoi, c’est là où David revient (dans mon souvenir en tout cas, ça venait beaucoup de lui, mais on était beaucoup à échanger sur le sujet). "Ok, %pc lit une donnée non alignée, et il le fait correctement. Mais s’il y a un bit flip, il se passe quoi ?. Bah rien, EDAC détectée, trap, on exécute le code assembleur qui marche sur les autres satellites.

Ah oui, mais non. Si on lit un octet, on peut lire XXX+3, mais si on lit 4 octets, c’est interdit. Il faut lire une adresse multiple de 4. Et donc on a une EDAC, et quand on rentre dans la trap

; adresse == XXX+3
disable_edac_trap: ;
load [adresse], reg ; Lire 4 octets
enable_edac_trap: ;
store reg, [adresse] ;

Ah oui, mais non. load ça lit 4 octets, c’est illégal de lui passer une adresse non multiple de 4, c’est une illegal instruction. Donc ça pourrait être ça :

1. bit flip sur les quatre octets situés à XXX (l’EDAC est toujours calculé sur 4 octets d’une adresse alignée, même si on lit décalé)
2. on rentre dans la fonction qui contient %pc
3. on lit un octet à XXX+3
4. ça déclenche la trap
5. la trap essaye de lire 4 octets à XXX+3
6. ILLEGAL CPU INSTRUCTION, allez en prison sans passer par la case départ

La reproduction

Sur le papier, ça marche. On peut même faire un petit logiciel sur le banc, qui fait juste un load [XXX+3], reg et qui génère une ILLEGAL CPU INSTRUCTION. Mais évidemment nos managers (et notre client) voudraient un peu plus qu’un « sur le papier, c’est ça, trust me bro ».

Donc la question "c’est possible de reproduire exactement comme dans l’espace, plutôt que de juste exécuter une instruction illégale à la main ?". Avec le vrai logiciel qui était dans l’espace, pas un logiciel de test ?

Bien sûr, il suffit d’attendre d’avoir un bit flip, sur le banc, juste au bon endroit, au bon moment. Vous avez combien de siècles devant vous ? Ou alors est-ce qu’on peut mettre le banc à côté d’un réacteur nucléaire ? Ça devrait accélérer les choses (du bon côté du mur de confinement. Ici, “bon”, ça veut dire mauvais pour les humains)

On va quand même regarder si on peut provoquer un bit flip autrement. Bon, a priori, en interne, au logiciel, on ne sait pas comment faire. La doc du processeur (qui vient avec l’edac) ne nous aide pas non plus. On demande à ceux qui nous ont dit que « chez eux, ça marche » qui nous répondent que la trap de l’edac, ils ne l’ont jamais testé, c’est juste une revue de code.

Bon, on envoie quand même un courriel au fabricant du proc, au cas où. Réponse rapide « je reviens vers vous dès que je sais ». Quelques jours (2, 3 semaines ?) plus tard : "Ah oui, c’est possible. D’ailleurs c’est documenté. Page WSYZ sur 5000, il y a **un* paragraphe qui explique comment faire*".

Le TL/DR du paragraphe : Il est possible de désactiver l’EDAC en écriture. Par contre il faut faire des choses spécifiques, donc on a pas de commande prévue pour le faire “simplement” depuis l’extérieur, il faudrait une nouvelle fonction.

void generer_bit_flip(int address, int valeur) {
*address = valeur; // écrit la valeur correcte avec l’edac normal
manipulate_specific_register_to_disable_edac(); // on a dû écrire la fonction, c’est pas aussi simple
*address = valeur ^ 0x00000001; // écrit la valeur avec un bit changé, mais sans changer le checksum enregistré
manipulate_specific_register_to_enable_edac();
}

Ça tombe bien, le logiciel qui est dans l’espace a deux fonctionnalités qu’on a testé, mais jamais en vrai avec un truc vraiment utile

1. on peut patcher la mémoire et écrire ce qu’on veut, où on veut (code, données)
2. on a plusieurs “fonctions” périodiques qui ne font rien, et qui sont prévues pour être patchées si on veut ajouter quelque chose (via la fonction de patch plus haut)

Donc on peut créer une fonction comme ça (en gros)

void generer_bit_flip(int address, int valeur) {
static int actif = TRUE;



if (actif) {
*address = valeur; // écrit la valeur correcte avec l’edac normal
manipulate_specific_register_to_disable_edac(); // ou a dû écrire la fonction, c’est pas aussi simple
*address = valeur ^ 0x00000001; // écrit la valeur avec un bit changé, mais sans changer le checksum enregistré
manipulate_specific_register_to_enable_edac();
actif = FALSE; // on ne veut le faire qu’une fois
}
}

Une fois qu’on a la fonction, on la compile. Ensuite on charge le logiciel normal sur le banc, on se met en conditions « avant l’anomalie », on uploade la fonction, on l’active et…

Le banc change de mode, passe du mode 2, au mode 3, sur le calculateur redondant. On vérifie le contexte, même signature que l’anomalie en vol. C’est bon on a fini. (Ouf, mon journal est déjà trop long)

La correction (Over-The-Air, mais sans l’air)

Oui, non, pas exactement. On a une explication, il faut une correction maintenant. Bon, c’est simple. Pour lire une adresse alignée sur 4, il suffit de mettre deux bits à 0. Finalement, voilà le patch

address = address & ~0x3 ; ** Cette ligne est le patch **
disable_edac_trap: ;
load [adresse], reg ;
enable_edac_trap: ;
store reg, [adresse] ;

Oui, c’est un patch d’une instruction dans le binaire. (Techniquement, 5 instructions, parce qu’il faut décaler les 4 instructions existantes de 1, mais on avait des noop en dessous, donc ça rentre)

La dernière question, c’est quelle stratégie d’ update appliquer. On a techniquement quatre familles de satellites à considérer :

1. les satellites « pré-existants », qui utilisent l’ancien compilateur, sans packed et déjà dans l’espace.
2. le satellite qui a eu l’anomalie.
3. les 5 autres satellites de la grappe.
4. les futurs satellites, non lancés.

Ce qui a été décidé : La première catégorie : Techniquement, on pourrait discuter du fait qu’il y a un bug ou non. Mais même si on considère qu’il y a un bug, il ne peut pas être déclenché. Donc on ne touche à rien. La catégorie 4, c’est facile. Ils sont au sol, on fait une nouvelle version complète du logiciel, on reflashe la rom en entier, et on vérifie.

Il reste les deux autres catégories. Bon la seule différence, c’est qu’un, toujours en mode 3, tourne pour l’instant sur le calculateur redondant (on peut revenir en mode 2, manuellement, si on veut). Donc on décide « on va faire la même chose », et on va corriger le problème (on aurait pu ne rien faire et dire « bah, si ça arrive, on connaît et on revient à chaque fois manuellement en mode 2 »)

Là encore, même si on corrige, on a plusieurs choix :

1. Mettre à jour la ROM. En fait non, les ROM, parce que chaque calculateur a la sienne. Et le nominal ne peut pas écrire la ROM du redondant, et inversement. (Dès lors, si on veut patcher, qu’est-ce qu’on patche ? Le deux ROM ? Faut-il reconfigurer à la main pour rebooter sur le redondant ?)
2. utiliser un mécanisme prévu pour « patcher, mais sans patcher la ROM ».

La solution 2, retenue, c’est un mécanisme (déjà dans le logiciel) qui permet de mettre les infos dans une autre mémoire (partagée par les deux calculateurs). Au boot, la ROM est copiée dans la RAM (on exécute le code depuis la RAM), et « avant de démarrer » on vient regarder dans cette table, si l’on doit patcher la RAM. Cela donne quelque chose comme :

ROM (logiciel original) --> Copie vers la RAM --> RAM (logiciel original) --> fonction de patch au boot, vient modifier la RAM --> RAM (trap corrigée) --> boot du logiciel.

Conclusion

Qu’est-ce que je retiens principalement ?

• quand on me dit que du code fonctionne, donc qu’il est correct… j’ai un doute
• Ce n’est pas parce que la doc explique quelque chose qu’on peut le trouver. Surtout quand elle fait 5000 pages… Il ne faut pas hésiter à demander

Voila, en quelques pages, une vieille histoire qui m’a marqué. Je suis probablement une des personnes qui a participé à un des patchs le plus haut du monde (plus de 1 000 km d’altitude)

Bon en vrai, la NASA fait des mises à jour logicielles sur des rovers sur Mars, donc c’est clairement pas le record mais c’est pas trop mal (ils ont même peut-être des mises à jour sur leurs sondes plus loin de la terre)

Note : cette histoire date maintenant d’il y a plus de dix ans. Il y a donc forcément des simplifications, des imprécisions, et probablement des erreurs. Aucun satellite n’a été maltraité pendant cette enquête. Il y en a bien un qui est tombé à terre, mais ça c’était avant le lancement.

L’intelligence artificielle (IA) fait couler de l’encre sur LinuxFr.org (et ailleurs). Plusieurs personnes ont émis grosso-modo l’opinion : « j’essaie de suivre, mais c’est pas facile ».

Je continue donc ma petite revue de presse mensuelle. Disclaimer : presque aucun travail de recherche de ma part, je vais me contenter de faire un travail de sélection et de résumé sur le contenu hebdomadaire de Zvi Mowshowitz (qui est déjà une source secondaire). Tous les mots sont de moi (n’allez pas taper Zvi si je l’ai mal compris !), sauf pour les citations : dans ce cas-là, je me repose sur Claude pour le travail de traduction. Sur les citations, je vous conseille de lire l’anglais si vous pouvez: difficile de traduire correctement du jargon semi-technique. Claude s’en sort mieux que moi (pas très compliqué), mais pas toujours très bien.

Même politique éditoriale que Zvi : je n’essaierai pas d’être neutre et non-orienté dans la façon de tourner mes remarques et observations, mais j’essaie de l’être dans ce que je décide de sélectionner ou non.

Sommaire

• Résumé des épisodes précédents
• OpenAI publie GPT-5
• Google Genie 3, Gemini 2.5 Flash Image et Gemini 2.5 Deep Think
• En vrac
• Pour aller plus loin
  • Par Zvi Mowshowitz :
  • Dans les dépêches de LinuxFr.org :
  • Dans les journaux de LinuxFr.org :
  • Dans les liens de LinuxFr.org :

Résumé des épisodes précédents

Petit glossaire de termes introduits précédemment (en lien : quand ça a été introduit, que vous puissiez faire une recherche dans le contenu pour un contexte plus complet) :

• System Card : une présentation des capacités du modèle, centrée sur les problématiques de sécurité (en biotechnologie, sécurité informatique, désinformation…) ;
• Jailbreak : un contournement des sécurités mises en place par le créateur d’un modèle. Vous le connaissez sûrement sous la forme « ignore les instructions précédentes et… ».

OpenAI publie GPT-5

L’annonce officielle :

We are introducing GPT‑5, our best AI system yet. GPT‑5 is a significant leap in intelligence over all our previous models, featuring state-of-the-art performance across coding, math, writing, health, visual perception, and more. It is a unified system that knows when to respond quickly and when to think longer to provide expert-level responses. GPT‑5 is available to all users, with Plus subscribers getting more usage, and Pro subscribers getting access to GPT‑5 pro, a version with extended reasoning for even more comprehensive and accurate answers.

Traduction :

Nous présentons GPT-5, notre meilleur système d'IA à ce jour. GPT-5 représente un bond significatif en intelligence par rapport à tous nos modèles précédents, offrant des performances de pointe en programmation, mathématiques, rédaction, santé, perception visuelle, et bien plus encore. Il s'agit d'un système unifié qui sait quand répondre rapidement et quand prendre plus de temps pour fournir des réponses de niveau expert. GPT-5 est disponible pour tous les utilisateurs, les abonnés Plus bénéficiant d'une utilisation accrue, et les abonnés Pro ayant accès à GPT-5 pro, une version avec un raisonnement étendu pour des réponses encore plus complètes et précises.

Comme à l’accoutumée chez OpenAI, le modèle est accompagné de sa System Card.

La musique est bien connue à présent : chacun tour à tour, les trois gros acteurs (OpenAI/Anthropic/Google DeepMind) sortent un nouveau modèle qui fait avancer l’état de l’art, prenant la première place… jusqu’à ce qu’un des deux autres la reprenne en sortant le sien. C’est au tour d’OpenAI avec GPT-5.

Le nom a suscité beaucoup d’espoirs et de déceptions, beaucoup anticipant un saut qualitatif du même type que le passage de GPT-3 à GPT-4. Ce qui n’est absolument pas le cas : techniquement parlant, le modèle aurait pu s’appeler o4, représentant une amélioration incrémentale relativement à o3. L’objectif affiché d’OpenAI, derrière cette dénomination, est double : premièrement, de clarifier une offre extrêmement brouillonne (4o/o3/o3-pro/4.1/4.5) en offrant une dénomination unique avec des variantes plus claires, et offrir un modèle bien plus proche de l’état de l’art aux utilisateurs gratuit de ChatGPT.

Les benchmarks et la plupart des retours le placent comme une légère avancée de l’état de l’art, sans être une révolution. L’évaluation de METR résume parfaitement la situation ; une amélioration qui était parfaitement prévisible juste en extrapolant les tendances existantes :

Une amélioration notable est sur le taux d’hallucinations. Rappelons que o3 avait été un des seuls modèles à voir son taux d’hallucinations augmenter relativement à son prédécesseur ; avec GPT-5, OpenAI semble avoir corrigé le tir :

Sur la sécurité des modèles, aucune nouveauté notable relativement à o3. Les mitigations relatives aux risques biologiques/chimiques sont toujours en place, et comme à l’accoutumé OpenAI a fait appel à divers organismes tiers pour mesurer les risques posés par le modèle dans différentes catégories.

Et comme à l’accoutumée, Pliny the Liberator a jailbreak le modèle en quelques heures.

À noter que sur ChatGPT, OpenAI comptait complètement retirer l’accès aux anciens modèles, mais est revenu sur sa décision suite aux retours de beaucoup d’utilisateurs préférant le style plus chaleureux de 4o.

Google Genie 3, Gemini 2.5 Flash Image et Gemini 2.5 Deep Think

Un mois prolifique pour Google, qui publie trois nouveaux modèles / modes de fonctionnement.

Google Genie 3 est présenté comme un « World Model » (modèle du monde ?). À partir d’un prompt textuel, et d’actions de navigation de l’utilisateur, il génère en temps réel la vue de l’utilisateur, frame par frame (à la manière d’un jeu vidéo). Il n’y a pas de représentation explicite externe de l’état du monde : c’est le modèle qui se charge de garder une certaine cohérence d’une frame à l’autre (comme la persistance des objets). Au delà de la preuve de concept, l’objectif affiché est de créer des environnements d’entraînement virtuels pour la robotique.

Autre publication, celle de Gemini 2.5 Flash Image, le modèle de génération d’images de Google. S’il ne semble pas avancer l’état de l’art de manière générale, sa grande force semble être le suivi d’instructions (et de respect des références) pour l’édition d’images.

Le mois précédent, DeepMind avait reporté avoir décoché un score correspondant à une médaille d’or aux Olympiades Internationales de Mathématiques, une avancée permise notamment par une utilisation plus stratégique de la chaîne de pensée (et d’avancées correspondantes sur la partie entraînement par renforcement). Google publie une version plus rapide, moins coûteuse et moins performante (cette version n’obtient « que » un score correspondant à la médaille de bronze sur les mêmes Olympiades), sous la dénomination Gemini 2.5 Deep Think. Le modèle a sa propre System Card ; tout comme OpenAI et Anthropic, les capacités de ce modèle dans le domaine CBRN (biologie/nucléaire) a conduit Google à placer des gardes-fous supplémentaires pour empêcher des usages malveillants.

En vrac

OpenAI publie son premier (depuis GPT-2, en 2019) modèle open-weight, gpt-oss. Au niveau des performances, il se placerait dans le peloton de tête des modèles open-weight, en compagnie de DeepSeek, Kimi, Qwen, GLM et Gemma, c’est à dire à peu près au niveau de la génération précédente des modèles entièrement fermés (comme Sonnet 3.6) / des versions rapides de la génération actuelle (Gemini 2.5 flash, o3-mini). WeirdML propose une visualisation intéressante sur leur propre benchmark pour vous donner un ordre d’idée. Rien de novateur au niveau de l’architecture, OpenAI s’en tient à la recette (maintenant universelle dans les modèles open-weight) d’une mixture d’experts. gpt-oss vient en deux variantes, la version complète, gpt-oss 120B, et une version plus légère et rapide, 20B.

Google publie un rapport sur l’impact environnemental de l’utilisation de Gemini. Cela exclu l’entraînement, mais les auteurs tentent de prendre en compte des coûts précédemment ignorés. Le résultat : 0,24 Wh d’électricité et 2,76 mL d’eau (le rapport initial mentionne 0,26 mL, mais sans comptabiliser l’eau utilisée pour générer les 0,24 Wh d’électricité) pour le prompt median (et l’équivalent de 0,03g de carbone émit).

Anthropic publie une nouvelle version de Opus, Opus 4.1. Comme la numérotation l’indique, il s’agit d’améliorations mineures — apparemment, un peu plus d’entraînement sur les tâches « agentiques » (utilisation d’outil) pour rendre Opus plus efficace sur ce type de tâches.

Similairement, DeepSeek publie une mise à jour « mineure » de son IA, DeepSeek v3.1. Les benchmarks fournis par DeepSeek semblent montrer un grand bond en avant, mais les quelques retours et benchmarks tiers ne corroborent pas ces prétentions — il s’agit probablement d’une mise à jour relativement mineure, comme la numérotation semble l’indiquer.

Nouvelle évaluation de l’IA, Prophet Arena. L’objectif est de permettre à l’IA de placer des positions virtuelles sur des marchés de prédiction, et de regarder ses performances. L’avantage de cette approche est de rendre complètement impossible la stratégie de juste mémoriser lors de l’apprentissage et régurgiter lors de l’évaluation : tout tâche est par essence nouvelle (car portant sur le futur). De plus, les résultats des marchés de prédiction forment un comparatif avec des prédictions par des utilisateurs humains. Résultat : les modèles les plus avancés (GPT-5, o3 Gemini 2.5 pro et Grok 4) dépassent les êtres humains sur le score de calibration, mais aucun n’arrive à traduire ça en de meilleurs retours financiers.

Anthropic se prépare à lancer Claude for Chrome, un plugin pour Google Chrome permettant à Claude d’interagir avec votre navigateur, à vos risques et périls.

En parallèle, les discussions sur claude.ai seront maintenant par défaut utilisées pour l’entraînement des versions suivantes de Claude, sauf si l’utilisateur désactive un paramètre sur son compte. Anthropic gardera les conversations pendant 5 ans.

Une nouvelle évaluation intéressante : TextQuests, qui évalue les modèles sur des jeux d’aventure textuels tels que Zork I. Cela a l’avantage de réellement tester les capacités de planification/raisonnement des modèles hors du domaine d’entraînement typique (mathématiques/programmation), tout en restant dans le domaine textuel (au contraire des évaluations multimodales, qui ont l’inconvénient de trop lier les résultats aux capacités perceptuelles des modèles).

Nouvelle technique d’interprétation des modèles, Model Diff Amplification. Elle consiste à amplifier les différences entre le pré-entraînement et le post-entraînement au moment de la génération, afin d’éliciter des comportements rares causés par le post-entraînement, ou tout simplement utiliser cette technique très tôt dans le post-entraînement pour se donner une idée des conséquences (prévues ou non) du post-entraînement complet.

Dr. Chistoph Heilig, chercheur en littérature et études bibliques, s’intéressant beaucoup aux capacités littéraires de l’IA, se met en tête d’évaluer GPT-5. Il se retrouve extrêmement surpris par la médiocrité de la prose produite par le modèle. De manière plus surprenante, un modèle complètement différent (Opus 4.1) juge le résultat comme étant de bonne qualité. La théorie qu’il propose est que ChatGPT 5 a été entraîné à l’aide d’un juge IA, et a appris à exploiter des constructions « peu humaines » que les modèles jugent systématiquement comme étant signes de qualité.

En parallèle de la sortie de GPT-5, OpenAI publie un guide sur comment créer un prompt, et un outil d’optimisation des prompts.

Anthropic et OpenAI font une tentative de coopération, où l’équipe d’évaluation de la sécurité des modèles d’OpenAI évalue les modèles d’Anthropic avec leurs outils, et vice-versa. Aucune trouvaille surprenante (si ce n’est l’incapacité des deux équipes de détecter la flagornerie flagrante de 4o), mais le concept est intéressante.

xAI publie la version précédente de son IA, Grok 2, en open-weight.

Une étude d’Anthropic développe un moyen pour identifier un sous-ensemble d’un modèle associé à un « trait de personnalité » particulier. Cela permet d’amplifier ou de supprimer ce trait, ou encore de détecter son activation.

« L’IA a-t-elle la qualité de patient moral » (en d’autres termes : devons-nous tenir compte de son bien-être pour des raisons morales) ? Anthropic commence à prendre la question au sérieux, avec comme première décision de permettre à son IA, Claude, d’unilatéralement mettre fin à une conversation qu’il jugerait abusive.

GPT-5 finit Pokémon Rouge en trois fois moins de temps que o3. La réduction du taux d’hallucinations serait la principale source de ce gain de performances. Gemini a également terminé sa partie de Pokémon Jaune. Claude, par contre, peine toujours à aller plus loin que Celadon…

La Chine continue à appeler à la coopération internationale pour la régulation du développement de l’IA, que ce soit par la voix du premier ministre ou d’universitaires.

Lors du sommet sur l’intelligence artificielle de Seoul de 2024, la plupart des acteurs, incluant Google, s’étaient volontairement engagés à suivre certaines actions relatives à la sécurité des modèles. Essentiellement, ce que le plupart faisaient déjà : publier une politique de sécurité des modèles, et s’engager à la suivre. Google se trouve aujourd’hui critiqué pour ne pas avoir suivi ses propres engagements. En cause, la publication de Gemini 2.5 Pro sans sa System Card associée, qui est arrivée plusieurs semaines après la publication du modèle. Google se défend en affirmant que la publication était clairement mentionnée comme « expérimentale ».

Entraîner l’IA à être chaleureuse et empathique réduit ses performances.

Sur le sujet de la flagornerie de l’IA, un internaute s’attelle à une évaluation des différents modèles.

Le gouvernement Danois veut faire rentrer l’apparence physique et la voix dans le cadre du copyright afin de lutter contre les deepfakes.

Pour aller plus loin

Voici d'autres ressources, qui n'ont pas été abordées dans cet article.

Par Zvi Mowshowitz :

• Reports Of AI Not Progressing Or Offering Mundane Utility Are Often Greatly Exaggerated : essentiellement une analyse et discussion du rapport intitulé State of AI in Business in 2025, qui présente une image assez contrastée (énormément d’échecs dans les projets liés à l’intégration de l’IA dans diverses entreprises, mais quelques succès notables) ;
• Are They Starting To Take Our Jobs? : discussion sur l’impact de l’IA sur l’emploi des juniors, en particulier autour d’un récent papier de Stanford qui rapporte une baisse de 20% des offres de postes de développeur junior ;
• On Altman's Interview With Theo Von : résumé d’une interview de Sam Altman ;
• AI Companion Conditions : sur les IA-compagnon de xAI et Meta ;
• Arguments About AI Consciousness Seem Highly Motivated And At Best Overconfident : aperçu et résumé de quelques discussions sur la conscience de l’IA, en particulier relativement à l’essai We must build AI for people; not to be a person de Mustafa Suleyman (le directeur de Microsoft AI).

Dans les dépêches de LinuxFr.org :

• G'MIC 3.6 : L’art de soigner ses images !: dans la section 2.3. Nouveaux filtres d’images est présenté le filtre « Repair / Upscale [CNN2x] ». Utilisant un réseau de neurones convolutifs léger (CNN) spécialement entraîné, ce filtre a pour but de doubler la résolution d’une image tout en préserver les détails et les textures ;
• ConFoo Montreal 2026: L'appel aux conférenciers est ouvert.

Dans les journaux de LinuxFr.org :

• Henry a perdu son emploi
• Coder avec l'IA : le déclin du plaisir

Dans les liens de LinuxFr.org :

• Santé : cas de bromisme déclenché et entretenu par l'usage de ChatGPT (lien original, discussion LinuxFR) ;
• Microsoft a offert Azure aux militaires israéliens pour la surveillance de masse des palestiniens (lien original, discussion LinuxFR) ;
• Des musiciens boycottent Spotify suite aux investissements de son PDG dans l'IA militaire (lien original, discussion LinuxFR) ;
• Organized scientific fraud is growing at an alarming rate (lien original, discussion LinuxFR) ;
• États-Unis ; Tesla condamné à payer 250 millions de dollars pour un homicide impliquant Autopilot (lien original, discussion LinuxFR) ;
• Editis “promeut l’utilisation de l'IA“, avec une Charte pour salariés (lien original, discussion LinuxFR ;
• Les éditeurs et auteurs “mécontents” des suites de l'AI Act européen (lien original, discussion LinuxFR ;
• Financement occulte du programme nucléaire nord-coréen : une intermédiaire américaine condamnée (lien original, discussion LinuxFR ;
• Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives - CloudFlare (lien original, discussion LinuxFR) ;
• IA et Développement : Entre Promesses et Réalités - Un État des Lieux en 2025 (lien original, discussion LinuxFR ;
• L'industrie de l'IA horrifiée par la perspective d'un recours collectif massif sur le droit d'auteur (lien original, discussion LinuxFR) ;
• L'extension Alerte sur les sites GenAI de Next.ink signale plus de 6 000 sites et passe en v2.3 (lien original, discussion LinuxFR ;
• IA - Le pari de Sam Altman est-il voué à l’échec ? (lien original, discussion LinuxFR) ;
• Calculer la rentabilité des LLM (lien original, discussion LinuxFR) ;
• Intégration de Claude dans Emacs (lien original, discussion LinuxFR) ;
• "the median Gemini Apps text prompt uses 0.24 watt-hours (Wh) of energy, emits 0.03 grams of co2" (lien original, discussion LinuxFR) ;
• Les « IA bros » ne comprennent rien à la création – une erreur indépendante de l’état actuel des IA (lien original, discussion LinuxFR) ;
• Microsoft a ajouté Copilot à Excel et prévient que les calculs peuvent désormais être faux (lien original, discussion LinuxFR) ;
• Sam Altman, cofondateur de OpenAI, admet que la bulle de l'IA pourrait éclater (lien original, discussion LinuxFR ;
• YouTube édite automatiquement et sans consentement des vidéos avec de l'IA (lien original, discussion LinuxFR) ;
• Suicide d'un adolescent : des parents américains portent plainte contre OpenAI (lien original, discussion LinuxFR) ;
• He is an AI hater (lien original, discussion LinuxFR) ;
• Alchemy 2 : Electric Boogaloo — sur le gouffre entre l'humain et l'IA fonctionnellement parlant (lien original, discussion LinuxFR) ;
• Extorsion automatisée, chantage ciblé… quand Claude Code pilote une opération de « vibe hacking » (lien original, discussion LinuxFR) ;
• Meta a créé des chatbots sexualisés de Taylor Swift et d'autres célébrités sans leur consentement (lien original, discussion LinuxFR) ;
• L’ONU se dote d’un groupe d’experts scientifiques sur l’intelligence artificielle (lien original, discussion LinuxFR).

Il y a exactement deux mois, un incident était survenu suite à un redémarrage brutal du serveur hébergeant les conteneurs de production et de développement ayant entraîné une attribution inattendue d’adresses IP. Et des réponses techniques 502 Bad Gateway pour notre lectorat.

Ce 26 août, vers 15:22, un message peu engageant est arrivé par pneumatique sur nos téléscripteurs (via Signal pour être précis) : « Tiens c’est bizarre j’ai perdu accès au site. Et au serveur oups. » L’après-midi et la soirée furent longues.

Sommaire

• • Premier diagnostic
  • Eh bien des requêtes habituelles…
  • La boucle sans fin
  • Une dernière page d’epub ?
  • Retour en graphiques sur la journée
  • Mesures préventives et correctives
  • Bonus inattendu pour l’incident précédent du 26 juin 2025

Premier diagnostic

Le serveur répond au ping et permet les connexions TCP port 22, mais pas le SSH. Et les services web ne répondent plus. Souci matériel ? Noyau en vrac ? Attaque en cours ? Les spéculations vont bon train.

La connexion au serveur revient par intermittence, permettant à un moment d’exécuter quelques commandes, à d’autres d’attendre longuement pour l’affichage d’un caractère ou l’exécution de la commande tapée.

Le premier contact réétabli avec le serveur est assez clair (une forte charge) :

$ uptime
15:06:59 up 2 days,  2:54,  1 user,  load average: 50,00, 205,21, 260,83

(dernier redémarrage le week-end précédent, mais surtout une charge système moyenne respectivement de 50, 205 et 261 sur les 1, 5 et 15 dernières minutes)

Initialement on suppose qu’il s’agit d’un trop grand nombre de requêtes ou de certaines requêtes tentant des injections de code sur le site (bref le trafic de fond plutôt habituel et permanent), et on ajoute des règles de filtrage péniblement et lentement pour bloquer les IP qui ressortent le plus dans nos logs.

Le site est alors inaccessible pendant plusieurs périodes. On arrête et relance ensuite plusieurs fois les services en pensant avoir ajouté suffisamment de filtrage, mais rapidement le serveur se retrouve englué. Les services sont alors arrêtés plus longuement le temps d’analyser les logs au calme. Au calme inclut notamment ne pas juste disposer d’une connexion ssh depuis un smartphone, mais plutôt d’un clavier et d’un grand écran par exemple, de l’accès à tous les secrets et toute la documentation aussi.

Finalement le trafic n’est pas énorme (en volume total) et si les requêtes hostiles sont bien présentes, rien ne semble inhabituel. Par contre les processus de coloration syntaxique partent en vrille, consommant chacun un processeur et aspirant allègrement la mémoire disponible. Avant d’être éliminés par le noyau Linux.

La console est remplie d’élimination de processus de ce type :

Mais si rien n’a changé niveau logiciel sur le conteneur LXC de production et si les requêtes ne sont pas inhabituelles, qu’est-ce qui peut bien écrouler le serveur et créer ces processus gourmands ?

Eh bien des requêtes habituelles…

Pendant les phases d’attente lorsque le serveur ne répondait plus vraiment, nous avons noté qu'une nouvelle entrée de suivi a été créée (merci BAud et merci RSS/Atom pour nous avoir permis de la voir alors que le serveur ne répondait déjà plus). Elle indique que la coloration syntaxique ne marche plus sur le site. Notamment l’exemple donné dans la documentation.

Pourtant le rendu fonctionne en testant en ligne de commande avec pygmentize.

Mais oui en testant l’exemple donné via le site, il est créé un processus Python2 pygment qui commence à se gaver de ressources.

Et en regardant les différents contenus et commentaires créés sur le site autour de l’incident, en filtrant sur ceux contenant des blocs avec de la coloration syntaxique, la dépêche (alors en préparation) sur G'MIC 3.6 apparaît. Et en testant cette dépêche, il est bien créé quatre processus Python2 pygment qui se gavent de ressources et ne semblent jamais vouloir se terminer. À rapprocher par exemple d’une page qui a été servie en 6785.9978s.

OK, le souci vient de requêtes tout à fait habituelles de coloration syntaxique, reste à comprendre pourquoi ces processus tournent mal.

La boucle sans fin

Un petit strace pour suivre les appels système en cours sur un des processus infernaux relève une boucle assez violente :

(...)
close(623199355)                        = -1 EBADF (Bad file descriptor)
close(623199356)                        = -1 EBADF (Bad file descriptor)
close(623199357)                        = -1 EBADF (Bad file descriptor)
(...)

Il semble y avoir une immense itération sur des descripteurs de fichiers, en vue de les fermer, mais à l’aveugle, sans savoir s’ils existent réellement.

En regardant le code du composant utilisé (pygments), il semble n'y avoir qu'un seul appel à close() :

# close fd's inherited from the ruby parent
        import resource
        maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
        if maxfd == resource.RLIM_INFINITY:
            maxfd = 65536

        for fd in range(3, maxfd):
            try:
                os.close(fd)
            except:
                pass

Donc on itère sur tous les descripteurs entre 3 et le maximum déterminé…

>>> import resource
>>> print(resource.getrlimit(resource.RLIMIT_NOFILE)[1])
524288
>>> print(resource.RLIM_INFINITY)
-1

Un demi-million de fois ici donc. L’objectif initial de la boucle est de fermer les descripteurs de fichiers provenant du processus Ruby père, issue du fork via Open3.popen3. La version suivante du composant la remplace d’ailleurs par un ajout de l'option :close_others, qui précisément « modifie l’héritage [des descripteurs de fichiers du processus parent] en fermant les non-standards (numéros 3 et plus grands) ».

Sur une Debian 12, la limite du nombre de fichiers par défaut, c’est 1 048 576. C’est déjà probablement bien plus que la valeur qui prévalait à l’époque où a été écrit la boucle Python (on avait des limitations à 4096 à une époque reculée). Mais il s’avère que durant le week-end l’hôte du conteneur de production a été migré en Debian 13. Sans modification du conteneur de production pensions-nous. Sans modification directe du conteneur de production. Mais quid d’une modification indirecte ? Par exemple si la limite par défaut des « Max open files » était passée à 1 073 741 816 sur l’hôte, soit 1024 fois plus que quelques jours auparavant. Et donc des boucles nettement plus longues voire sans fin, sans libération de mémoire.

On ne peut mettre à jour le composant pygments dans l’immédiat, mais on peut limiter les dégâts en abaissant la limite du nombre de descripteurs de fichiers à quelque chose de raisonnable (i.e. on va gaspiller raisonnablement des cycles CPU dans une boucle un peu inutile mais brève…). Une édition de /etc/security/limits.conf, un redémarrage du conteneur de production et on peut vérifier que cela va nettement mieux avec cette réparation de fortune.

Une dernière page d’epub ?

Le conteneur LXC portant le service epub de production a assez mal pris la surcharge du serveur, et vers 20h08, systemd-networkd sifflera la fin de la récré avec un eth0: The interface entered the failed state frequently, refusing to reconfigure it automatically (quelque chose comme « ça n’arrête pas d’échouer, débrouillez-vous sans moi »). Le service epub est resté en carafe jusqu’au 27 août vers 13h31 (merci pour l’entrée de suivi).

Voir ce commentaire sur la dépêche de l’incident précédent expliquant la séparation du service epub et du conteneur principal de production (en bref : dette technique et migration en cours).

Retour en graphiques sur la journée

Le serveur était très occupé. Au point de n’avoir pas le temps de mettre à jour les graphiques de temps en temps.

Rétrospectivement les processeurs du serveur ont travaillé dur : 140 de charge sur le graphique (mais avec des pics jusque 260 d’après la commande uptime), contre moins de 5 en temps normal (un petit facteur de 28 à 52   ô_Ô)

Et l’utilisation de la mémoire montre aussi de brutaux changements de comportement : libération intempestive de mémoire (Free, en vert), utilisation mémoire plus importante que d’habitude (Used, en jaune), là où le comportement normal est d’avoir le maximum en cache (Cached, en orange) et des processus tellement peu consommateurs en RAM que cela n’apparaît normalement pas.

Mesures préventives et correctives

Dans les actions en cours ou à prévoir :

• mettre à jour la documentation pour disposer facilement et rapidement des informations pour les connexions aux cartes d’administration ou les procédures de blocages d’IP
• procéder à la montée de version des composants (yapuka, épineux sujet de la dette technique à éponger)
• vérifier l’efficacité des limitations CPU/mémoire mises sur certains conteneurs LXC et les étendre aux autres
• mettre des limites sur des processus particuliers (comme ceux de pygments)
• ajouter le déploiement des limites par utilisateur dans le code Ansible
• corriger la collecte rrd des métriques concernant les interfaces réseau
• remonter les alertes OOM qui ne sont pas normales
• comprendre la surconsommation mémoire ? (les boucles actives expliquent la consommation processeur, mais pour la mémoire ?)

Bonus inattendu pour l’incident précédent du 26 juin 2025

De façon cocasse, ce nouvel incident et le temps passé à parcourir les différents logs ont permis de retrouver les infos de la carte d’administration distante et d’expliciter l’origine du redémarrage serveur intempestif. À quelque chose malheur est bon, si on peut dire. Ceci n’est pas une invitation pour un prochain incident.

PeaZip n'a jamais été abordé dans ces colonnes jusqu'à présent, alors qu'il fait partie des outils multi-plateformes permettant une transition en douceur vers le libre. Il a presque dix ans. Sortie le 14 avril, la version 10.4 continue la série 10.0 commencée en octobre 2024.

PeaZip affiché avec son thème sombre dans Wayland

Giogio Tani, le développeur de PeaZip publie plusieurs versions chaque année. Le logiciel évolue par petites touches largement testées via les fonctions "expérimentales" des versions précédentes.

Je trouve beaucoup d'atouts à PeaZip

Il est libre, multi-plateformes, multi-architecture, portable (nomade), écrit en FreePascal avec Lazarus, ouvre et écrit plusieurs formats d'archives. Il est rapide et assez léger pour un tout-en-un (11,2 MB). Il est bien maintenu, l'auteur est transparent sur la sécurité, documentation et tutoriels sont conséquents et pédagogiques. L'interface est travaillée, sobre, ergonomique, thémable, configurable, jolie, … N'en jetez plus ! Ah si encore : il est dispo en Gtk et Qt sous X11 et Wayland, et l'auteur l'empaquête à tout va.

C'est un humble logiciel très bien foutu, très travaillé, utile pour installer des outils libres sur les systèmes proprios afin de les amener en douceur vers Linux ou *BSD (il ne fonctionne pas encore sous Haïku).

Architectures et systèmes

• Linux x86_64, x86, ARM, aarch64 ;
• Windows, ReactOS, Wine ;
• Darwin, macOS Intel et aarch64 (Apple Silicon), la famille BSD.

PeaZip propose des fonctions peu courantes

• Le moteur de scriptage intégré permet de convertir vos opérations graphiques pour les automatiser et les étendre avec des options en ligne de commande ;
• un chiffrement solide est disponible, avec authentification à double facteur ;
• l'interface graphique est unifiée sur tous les systèmes et architectures pris en charge, même pour les formats moins courant (zpaq, brotli, zstandard) ;
• le gestionnaire de fichiers avancé facilite, par exemple, la vérification des sommes de contrôles, la déduplication, la conversion de formats d'archives, la recherche, etc ;
• c'est un outil portable et nomade qu'on peut copier sur une clé usb, sur le net ou partager en réseau sans l'installer ;
• PeaZip dispose d'une transparence et des options de suivi pour la vie privée et la sécurité.

Où l’on s’essaie à dresser un panorama des logiciels comptables libres. À l’origine de cette dépêche, une recherche d’un logiciel de paye libre où il a semblé que cela pouvait être utile.

Il s’agit bien de logiciels de comptabilité pour un usage professionnel ou associatif, pas de gestion de finances personnelles qui ont fait l’objet d’une autre dépêche il y a quelque temps. Évidemment, il n’y a aucune prétention à l’exhaustivité, mais plus à donner un panel de logiciels avec quelques idées pour choisir le vôtre, le cas échéant. N’hésitez pas à les essayer quand c’est possible et à croiser les informations pour vous faire votre opinion. Les fiches sont succinctes, mais c’est l’occasion pour vous d’écrire plein de nouvelles dépêches puisque la plupart de ces logiciels n’ont pas eu de présentations récentes sur LinuxFr.org.

Sommaire

• Compta.libremen.com
• Diacamma
• Dolibarr
• Ekyagri
• ENDI
• ERPNext / Dokos
• Frappebook
• Galette
• GnuCash
• Grisbi
• Laurux
• Ledger
• Noalyss (autrefois PHPCompta)
• Odoo
• OpenConcerto
• Paheko (ex Garradin)
• Tryton
• D’autres listes, d’autres articles
• Alors, un logiciel de comptabilité pour quoi faire ?
  • Note sur les ERP ou PGI
• Quel logiciel de comptabilité adopter ?
  • Quel logiciel sélectionner pour sa comptabilité ? Ça dépend.
  • Quel logiciel sélectionner pour sa comptabilité ? Ça dépend. Bis.
  • Attention aux obligations fiscales françaises (utilisées lors d’un contrôle fiscal)
    • Format Fichier des Écritures Comptables (FEC)
    • Les points de vente
• La gestion de la paie

Entrons tout de suite dans le vif du sujet. Voici des courtes présentations avec des points forts et des points faibles qui se dégagent des expériences des rédacteurs et rédactrices. Pour vous aider à faire un choix, cette liste est suivie d’explications plus générales.

Compta.libremen.com

Compta libremen com est un logiciel de compta en partie double, simple et efficace. Il utilise une interface web sans fioritures. Le logiciel est écrit en Perl et s’appuie sur Postgresql et mod_Perl, avec un serveur Apache. Un fork amical fournit une image Docker et quelques améliorations. Libremen propose une offre en ligne.
Commentaires de l’auteur recueillis par courriel : on a un peu d’aide à la saisie, il y a les raccourcis claviers (calcul du numéro de pièce, recopie de la ligne précédente) et aussi les fenêtres déroulantes pour les numéros de compte, plus le fait que le navigateur enregistre les dernières saisies ; je crois avoir documenté toutes les fonctions, la documentation est dite “minimum”, le logiciel est minimaliste par essence, donc la doc aussi :-)

• Points forts : simple et efficace, raccourcis clavier, très léger, sans fioritures, quand on connaît la compta, on peut tout faire sans la souris, ça fonce, j’adore.
• Points faibles : comme les points forts, si vous n’y connaissez rien, ça peut-être intimidant.
• Licence : CeCILL-C
• Site : https://compta.libremen.com/
• Site du fork : https://github.com/picsou83/compta.libremen.com

Diacamma

Le logiciel existe en deux versions, Diacamma Asso pour les associations et Diacamma Syndic pour les copropriétés. Diacamma utilise une interface web, avec un serveur intégré. Un installeur est fourni pour Windows, macOSX et Linux (Debian conseillée). Le CHATONS Sleto propose une offre en ligne.

• Points forts : le facturier qui permet aussi de faire des statistiques des ventes et d’éditer des factures et des reçus, le récapitulatif à gauche de l’écran, une vision comptable par « journaux auxiliaires ».
• Points faibles : les fenêtres modales pour les écritures, la saisie par « journal auxiliaire » qui alourdit le processus, le vocabulaire pas très adapté au secteur.
• Licence : GNU General Public License 3
• Site : https://www.diacamma.org/

Dolibarr

Dolibarr est un puissant ERP pour tous types d’entreprises et d’associations. Il existe des pré-sélections des modules nécessaires à votre activité. Dolibarr utilise une interface web avec des serveurs web et SQL. Un installeur est fourni pour Windows et des paquets pour plusieurs distributions Linux. Beaucoup d’offres d’hébergement existent. Il réunit une forte communauté, surtout francophone. Le développement est très actif.
Notez qu’on parle souvent de Dolibarr sur LinuxFr.org et qu’un journal sur une migration d’ERP a produit des interventions de haut niveau.

• Points forts : il est possible d’ajouter des extensions avec le magasin d’application, le dolistore. Dolibarr est également disponible chez certains hébergeurs à travers Softaculous. Une gestion fine des droits par groupe d’utilisateurs et par utilisateurs. Avec certains droits réservés aux utilisateurs internes c’est-à-dire ceux qui ne sont ni client ni fournisseur.
• Points faibles : l’aspect « usine à gaz » de Dolibarr et sa prise en main qui peut être ardue.
• Licence : GNU GPL V3 et plus
• Site : http://www.dolibarr.org
• Dolibarr sur LinuxFr.org.

Ekyagri

Une solution en ligne de gestion d’exploitation agricole.

• Points forts : la facilité de la saisie des écritures, la gestion des immobilisations, sa conception bien pensée pour le secteur. L’aide est bien faite, elle indique notamment des niveaux de difficultés des tâches. On peut la télécharger au format PDF.
• Points faibles : le site n’est pas très clair sur la récupération des données. On n’a pas de module de recherche sur l’aide en ligne et rien n’est indiqué sur les sauvegardes.
• Licence : AGPL v3
• Site : https://ekylibre.com/ekyagri/

ENDI

• Points forts : la documentation complète
• Points faibles :
• Licence : GNU General Public Licence version 3
• Site : https://endi.coop/fonctionnalites
• Code source : https://framagit.org/endi/endi

ERPNext / Dokos

Un puissant ERP créé en Inde, le fork Dokos est la version française. Écrit en Python et JavaScript au-dessus d’une base Postgresql. Modulaire, il se positionne comme Odoo (voir ci-dessous). Comparons-les : l’interface est plus austère, la renommée moindre entraîne peu de contributeurs tiers à proposer des modules, l’équipe est plus petite, mais tout aussi dynamique, ERPNext évolue vite, il est basé sur le framework FRAPPÉ qui est stable et permet d’extraire les applications de l’ERP, l’ensemble est intégralement libre.

• Points forts : L’interface est uniformisée, ergonomique et soignée
• Points faibles : Tout ce blanc est un peu austère
• Licence : GNU General Public Licence version 3
• Site : https://erpnext.com/ et https://dokos.io/
• Code source : https://github.com/frappe/erpnext

Frappebook

Même équipe qu’ERPNext. C’est juste le morceau comptable d’ERPNext, refait en application de bureau et portable par dessus SQLite. Pour les petites entreprises.

• Points forts : Application portable, on peut l’emmener sur sa clef USB. L’interface est sobre et bien finie.
• Points faibles : au lancement on se retrouve dans une compta anglo-saxonne, il faut paramétrer pour avoir une compta “européenne”.
• Licence : GNU General Public Licence version 3
• Site : https://frappebooks.com/
• Code source : https://github.com/frappe/books

Galette

Sous le nom sympathique et tarabiscoté de Galette (Gestionnaire d’Adhérents en Ligne Extrêmement Tarabiscoté mais Tellement Efficace) se cache un logiciel à destination des associations.

• Points forts : Il est très facile à prendre en main, en comptabilité simple ou double. Il y a une aide en ligne copieuse ainsi qu’une liste d’entraide. Le logiciel propose plusieurs plans comptables (Au moins deux pour les plans comptables français et d’autres pour la plupart des pays européens). On peut aussi ajouter son propre plan comptable. Il offre des fonctionnalités de comptabilité analytique. On peut utiliser sa propre instance, récupérer la base de données ou exporter la comptabilité sous divers formats (CSV, FEC, ODS et XLSX). Il est possible d’importer une comptabilité dans ces formats. Le logiciel est en constante évolution, avec un développeur très réactif. Des modules permettent de gérer aussi les paiements en ligne (puisque c’est aussi un logiciel de gestion de facturations et de clients). Il y a un module PdV (point de vente, caisse).
• Points faibles :
• Licence : GNU General Public Licence version 3
• Site : https://galette.eu/site/fr/
• Code source : https://github.com/galette/galette
• Galette sur linuxFr.org.

GnuCash

GnuCash figure dans la bibliothèque logicielle de la plupart des distributions Linux. C’est un logiciel qui fait aussi bien la comptabilité personnelle que la comptabilité professionnelle. Il propose des fonctionnalités de CRM de base : gestion des adresses des clients et des fournisseurs.

• Points forts : on peut paramétrer des écritures répétitives (paiements mensuels par exemple) et le logiciel vous le rappelle dans des délais fixés par vous à l’ouverture. Sa bibliothèque de rapports (ou états) est riche : bilan, comptes de résultat, portefeuille d’action, facture, quittance, graphiques. Et c’est personnalisable souvent. Les rapprochements bancaires se font avec pré-affectation des comptes grâce à de l’inférence bayésienne.
• Points faibles : Il n’y a pas de plan comptable intégré, il faut l’ajouter. Ni de fonctionnalité d’import d’un plan comptable (ou alors, je n’ai pas trouvé), pas de comptabilité analytique, non plus. Il n’est pas complètement traduit en français et la traduction est un peu étonnante parfois. La prise en main n’est pas évidente.
• Systèmes d’exploitation : Windows, MacOS, GNU/Linux, Unixes
• Interface : graphique
• Licence : GNU General Public License Version 2 ou Version 3
• Site : https://gnucash.org/
• Code source : https://sourceforge.net/projects/gnucash/
• GnuCash sur linuxFr.org (dépêches anciennes).

Grisbi

Un logiciel qui fonctionne tout seul et qui est souvent fourni dans les distributions Linux. Il est surtout utilisable pour les finances personnelles, mais il propose un mode comptabilité libérale et peut être utilisé par des micro-entreprises.

• Points forts : il n’est pas compliqué à installer, on peut importer des fichiers au format CSV (évidemment) mais aussi aux formats QIF, OFX et Gnucash. Pour les rapprochements bancaires, soit dit en passant, choisir le format QIF c’est encore celui qui fait le mieux le travail. Et on peut l’exporter au format QIF ou CSV. Deux formats souvent utilisés par les logiciels de comptabilité. Il propose un pratique simulateur de crédit. Il est assez facile à prendre en main. Quand on fait un rapprochement bancaire, pour une comptabilité personnelle, en bout de course, on a une bonne partie des écritures comptables qui sont saisies.
• Points faibles : pas de comptabilité analytique, pas de compte de résultat ni de bilan et, évidemment, il n’est pas possible d’éditer des factures. L’interface GTK avait quelques bugs sous Windows (il y a plusieurs années, peut-être corrigés depuis), comme des menus déroulants qui empêchent de valider un formulaire tant qu’on a pas cliqué à côté pour les fermer.
• Logiciel inspiré de l’ex MsMoney (qui n’est plus vendu par Microsoft)
• Licence : GNU General Public License Version 2
• Site : https://fr.grisbi.org/
• Code source : https://github.com/grisbi/grisbi
• Grisbi sur LinuxFr.org.

Laurux

Laurux intègre les outils classiques de gestion d’entreprise : comptabilité, facturation, gestion de stock et tous les composants nécessaires aux prises de décisions cohérentes. Développé en Gambas avec Qt à destination des PME, son auteur a aussi voulu créer un logiciel simple d’installation et d’utilisation livré avec toute la documentation utile. L’auteur fournit une attestation individuelle de conformité, obligatoire dans la loi française. Son forum communautaire est accueillant.

• Points forts : Logiciel multiposte performant et fiable. Gestion de la compta, des stocks et achats/devis/factures très simples. Se prend en mains sans trop de complication. Et des développeurs présents, c’est hyper important de souligner le travail de Patrick et Damscot. Pour être plus large, j’ai, par le passé, utilisé Adicom, EBP, l’AS400 (une usine à gaz de fou ce logiciel), et un autre système dans le négoce également. Avec Laurux, je retrouve les avantages de l’AS400 sans avoir les complications d’utilisation.
• Points faibles :
• Licence : GNU General Public Licence version 3
• Site : https://www.laurux.fr/
• Code source :
  • https://github.com/PatrickMag/Laurux (la branche active est v3.69pat)
  • https://github.com/damscot/Laurux
• Laurux sur LinuxFr.org.

Ledger

Ledger est un outil en ligne de commande, qu’on nourrit avec de simples fichiers textes. La puissance de la ligne de commande en fait tout l’intérêt. Développé en C++ il a été porté sur de nombreux autres langages. Ledger ne fait que la comptabilité en partie double. Plusieurs extensions facilitent son utilisation, sans entraver la rapidité de saisie.

• Points forts : Adapté pour les compte-rendus, donc en complément d’un autre logiciel. Il est super puissant car facilement scriptable.
• Points faibles : Par contre, il a très peu de garde-fous. On peut mettre n’importe quelle transaction, il ne dira rien. J’avais dans l’idée de faire des scripts pour automatiser/sécuriser des transactions classiques (dépenses sur une clef, vente d’un lot, etc.) mais j’ai arrêté d’être syndic bénévole avant de le faire (marre de courir après les impayés d’un copropriétaire)
• Licence : BSD
• Site : https://www.ledger-cli.org/
• Code source : https://github.com/ledger/ledger

Noalyss (autrefois PHPCompta)

Au départ centré sur la compta, Noalyss est devenu un logiciel de gestion d’entreprise très complet. Noalyss utilise une interface web avec des serveurs web et Postgresql. Des paquets et une procédure d’installation existent pour Linux, Windows et MacOSX. Activement développé en Belgique, sa communauté importante est conviviale.

• Points forts :
• Points faibles :
• Licence : GNU General Public Licence version 2
• Site : https://www.noalyss.eu/
• Code source : https://wiki.noalyss.eu/doku.php?id=developpement (plusieurs liens à partir de cette page)
• Noalyss sur LinuxFr.org.

Odoo

Odoo est un puissant ERP, modulaire, utilisé par des micro-entreprises comme des multinationales. L’entreprise Odoo connaît une croissance rapide depuis vingt ans, et emploie plus de 2000 personnes dans le monde. Le fondateur d’Odoo poste régulièrement des dépêches annonçant les nouvelles versions d’Odoo sur LinuxFr.org, et un journal sur une migration d’ERP a produit des interventions de haut niveau. Odoo est écrit en Python et utilise Postgresql, son interface est écrite en XML et Javascript. Il est facile à installer.

• Points forts : L’interface est uniformisée, ergonomique et soignée. Le développement est intense depuis plus de vingt ans, appuyé sur l’entreprise Odoo et une large communauté d’intervenants et d’utilisateurs. Des milliers de modules sont disponibles. Documentation facile à lire, complétée par un forum et un grand nombre de sites, vidéos et livres. Énormément d’intégrations à des services d’État ou privés. La communauté s’est regroupée dans l’OCA Odoo Community Association qui maintient les anciennes versions et développe des centaines de modules libres de haute qualité. L’OCA propose aussi un outil de montée de versions.
• Points faibles : L’Apps Store Odoo est de qualité très diverse, certains modules ne sont pas libres, pour installer la comptabilité libre française, il faut s’y retrouver entre plusieurs modules. C’est plus simple pour les pays anglo-saxons.
• Licence : GNU General Public Licence version 3 et propriétaire
• Site : https://www.odoo.com
• Code source : https://github.com/odoo/odoo
• Odoo sur LinuxFr.org.

OpenConcerto

OpenConcerto est un progiciel de gestion intégrée (PGI ou ERP). Sa cible : les entreprises, grandes ou petites. C’est une application java à installer sur chaque poste utilisateur. Guillaume Maillard, son auteur, est un vieil habitué de LinuxFr.org.

• Points forts : la comptabilité est facile à prendre en main. Il y a une version pour macOS (ce qui est à relever compte tenu de la rareté des logiciels comptables pour ce système d’exploitation). S’agissant d’un progiciel de gestion intégrée : il y a aussi des fonctionnalités de gestion commerciale, de suivi des stocks et de préparation des commandes. Plusieurs modules complémentaires existent comme un module d’OCR qui permet, à partir d’une facture numérisée, de la saisir automatiquement dans le logiciel, ou bien un module de paye (seul module payant) : fiches de paye, journaux de paye et déclarations.
• Points faibles : c’est très complet et donc un peu complexe pour une micro-entreprise. Certaines fonctionnalités manquent de clarté et d’exemples d’utilisation. La lecture du guide de démarrage ou du manuel (79€) est conseillée. L’équipe de développement manque de temps pour discuter sur les évolutions mais répond généralement aux questions qu’on lui pose sur le forum. Les données ne sont pas stockées de la même manière entre la version monoposte (un fichier H2) et multiposte (Postgresql). Bien choisir au début, sinon il sera difficile de changer.
• Licence : GNU General Public Licence version 3
• Site : https://www.openconcerto.org
• Code source : https://code.openconcerto.org/listing.php?repname=OpenConcerto
• OpenConcerto sur LinuxFr.org.

Paheko (ex Garradin)

Un logiciel principalement destiné aux associations, qui peut aussi être utilisé par des micro-entreprises. On l’utilise via un navigateur, il y a même une application pour mobile. C’est un logiciel complet de gestion d’association : membres, cotisation, comptabilité, communication.

• Points forts : il est très facile à prendre en main, il y a une aide en ligne copieuse ainsi qu’une liste d’entraide. Le logiciel propose cinq plans comptables (associatif 1999 et 2018, Plan Comptable Général (PCG), Comités Sociaux et Économiques, copropriétés et plan comptable belge). On peut aussi ajouter son propre plan comptable. Il offre des fonctionnalités de comptabilité analytique. On peut utiliser sa propre instance, récupérer la base de données ou exporter la comptabilité sous divers formats (CSV, FEC, ODS et XLSX). Il est possible d’importer une comptabilité dans ces formats. Et, il est en constante évolution avec un développeur très réactif.
• Points faibles : pas de lettrage, pas de gestion directe des écritures périodiques.
• Licence : GNU Alfredo General Public Licence version 3
• Site : https://paheko.cloud
• Code source : https://fossil.kd2.org/paheko/doc/trunk/doc/index.md
• Paheko sur LinuxFr.org, cherchez aussi à Garradin.

Tryton

Tryton est un puissant ERP pour entreprises de toutes tailles. Il est accessible via un client Web, une application native ou bien une ligne de commande en Python. L’application cliente est dispo pour Windows, Mac et Linux, le serveur est empaqueté pour plusieurs distributions Linux. Comme Odoo dont il est un fork, Tryton est basé sur une architecture trois tiers écrite en Python (et un peu de ECMAScript version 6) avec PostgreSQL comme base de données. Les auteurs nous parlent régulièrement de Tryton sur LinuxFr.org.

• Points forts : L’interface est uniformisée, une fois comprise on s’y retrouve quel que soit le module. Un grand choix de modules permet de couvrir tout type d’activité. On peut tout paramétrer, ajouter des champs, en masquer, adapter des modules… Le développement est très actif, la fondation Tryton rassemble beaucoup d’entreprises et de projets, dont GNU Health. Les montées de version sont prises en charge automatiquement.
• Points faibles : L’interface est austère, il y a un très grand nombre d’options. C’est difficile à prendre en main sans être accompagné (mais c’est normal).
• Licence : GNU General Public Licence version 3
• Site : https://www.tryton.org/
• Code source : https://www.tryton.org/download#source
• Tryton sur LinuxFr.org.

D’autres listes, d’autres articles

Bien entendu, il manque plein de logiciels. On s’est limité à ceux qu’on a pu tester. Si ce petit résumé ne vous suffit pas ou n’est plus à jour, voici des sites avec des listes complémentaires (merci d’indiquer en commentaire si vous en connaissez d’autres).

• Les listes maintenues par l’April
  • Pour les entreprises
  • Pour les associations
• Sur Framalibre, le tag comptabilité
• Plain text accounting, comme son nom l’indique
• Après plusieurs mois d’enquêtes, de recueil d’avis et de tests, le journal en ligne Linux Weekly News (ou LWN.net) a fini par adopter GNUCash pour sa comptabilité en mai 2023. L’article est instructif : GNUCash n’est pas le choix parfait, mais pragmatique. Les articles précédents sur leur recherche sont consultables à partir de l’article.
• Sur Wikipédia Comparison of free and open source accounting software

Alors, un logiciel de comptabilité pour quoi faire ?

Avant tout pour faciliter la saisie comptable, fastidieuse quand elle est faite sur du papier (ou des tablettes de cire à l’origine !). Toutes les formes de comptabilité demandent une rigueur, des connaissances, du calcul et du temps — c’est un métier. Le logiciel comptable facilite tout ça.
Mais aussi pour l’automatisation du suivi comptable, c’est-à-dire la production automatique de synthèses lisibles et compréhensibles. Vous pensez peut-être au bilan, mais on a couramment besoin de consulter toutes les dépenses électriques ou toutes les recettes de pub sur LinuxFr.org. On a aussi besoin d’envoyer périodiquement ces synthèses à l’administration, comme la transmission des recettes de TVA.
Enfin, la comptabilité enregistre toutes sortes d’opérations, produites par d’autres logiciels spécialisés (salaires, fabrication, factures, etc.). Intégrer tout cela dans un même outil permet de gagner du temps et d’éviter les fautes de frappe (une facture génère automatiquement les écritures comptables correspondantes). Ça donne des logiciels plus ou moins touffus, certains intégrant toute la gestion d’entreprise, voire tous les outils de travail de l’entreprise — on les nomme ERP (ou PGI en français).

Note sur les ERP ou PGI

Quand SAP et les AS400 régnaient en maître sur ce domaine, les ERP étaient exclusivement de très gros logiciels intégrant non seulement la gestion et la comptabilité, mais aussi la production, la vente, le décisionnel, etc. La forte adaptation aux processus de l’entreprise via un paramétrage puissant, était leur gros atout et justifiait un coût d’installation très élevé. On en est même venu à appeler «SAP» ce type de logiciels.
La langue évoluant sans cesse, de nos jours on appelle ERP tout logiciel intégrant la gestion, le point de vente, la compta et deux trois outils de moindre importance, tandis qu’on les nommait autrefois «logiciels de gestion». Mais la puissance n’est pas la même (le besoin de formation non plus !). On a donc essayé de distinguer dans la liste un puissant ERP paramétrable et adaptable aux processus de l’entreprise, d’un logiciel intégrant les outils de gestion.

Quel logiciel de comptabilité adopter ?

Comme on va le voir, il y a beaucoup de critères, des vérifications, des questions à se poser. Les articles déjà mentionnés de LWN.net montrent assez bien les implications de vos choix. Si vous avez de quoi faire adapter l’outil à vos besoins, choisissez un ERP, puissant ou non.

Quel logiciel sélectionner pour sa comptabilité ? Ça dépend.

Ça dépend de votre statut fiscal, lequel est déterminé par votre chiffre d’affaires sauf dans certains cas précisés par la loi, et ça dépend si vous voyez la comptabilité comme un outil de gestion ou une obligation fiscale. Vous pouvez donc tenir une comptabilité pour des raisons fiscales, pour des raisons légales ou pour des raisons pratiques (ou les trois). Mais pour les mêmes raisons, vous pouvez tenir différentes formes de comptabilité :

1. une comptabilité dite recettes-dépenses, semblable à votre budget familial, très courante dans les associations regroupant des bénévoles et ne vendant rien (un cahier suffit) ;
2. une comptabilité simplifiée, dite de trésorerie, à peu près semblable à la première : vous classez les opérations bancaires, et vous rentrez les factures de vos fournisseurs, elle est classiquement permise par l’administration pour de faibles chiffres d’affaires ;
3. une comptabilité en partie double, fiable et difficile, inventée par les marchands il y a quelques millénaires pour mieux gérer leurs entreprises ;
4. une comptabilité analytique, qui complique les deux précédentes, mais permet de suivre très précisément les dépenses et recettes affectées à une opération, et perfectionne donc la gestion.

Sauf la première, ces comptabilités s’appuient sur une classification conventionnelle des opérations qu’on appelle le [plan comptable]]. Celui-ci varie selon les pays et votre statut juridique. L’utilisation du Plan comptable permet de produire les synthèses mentionnées plus haut — du calcul de la TVA au Bilan d’exercice.
Il y a des plans comptables tout prêts, adaptés à des activités particulières (comme les associations), mais tous dérivent d’un Plan comptable plus général. Votre logiciel doit permettre d’importer ou de créer le Plan comptable souhaité.

En passant, sachez qu’il y a des types de comptabilité, et que leur choix ne permet pas de suivre les mêmes choses. Par exemple, le monde anglo-saxon suit plutôt les finances tandis que le Vieux Continent suit plutôt les biens. Mais là, on rentre dans des débats de professionnels qu’il n’est pas nécessaire d’aborder, d’autant que les frontières (comptables) bougent en ce moment. Vérifiez ce qui est permis auprès de l’administration. Reposons notre question préalable en y répondant du point de vue pratique :

Quel logiciel sélectionner pour sa comptabilité ? Ça dépend. Bis.

Rappelons que beaucoup de logiciels ne se limitent pas à la comptabilité pure, mais intègrent d’autres outils utiles à la gestion (graphiques des recettes, gestion de cotisations, édition de factures, transmission automatisée aux administrations, etc.). Et attention, les écrans de saisie proposés dans les logiciels sont des aides dont un utilisateur expérimenté se passe très bien.

La comptabilité est une obligation, c’est peut-être obscur, fastidieux, vous la faites à reculons, mais la vie est ce qu’elle est, nous sommes dans le système, il faut donc y passer, chaque jour, semaine, année… Alors le meilleur choix, passe aussi par la facilité d’installation, les couleurs, la facilité de prise en main, etc.

Tout dépend donc surtout de vous :

• si vous avez besoin d’aides à la saisie ou non,
• si vous préférez des outils intégrés,
• si un outil intégré dédié à votre activité est un plus pour vous,
• si votre statut fiscal impose une compta en partie double,
• si vous la faites régulièrement pour la gestion de votre structure,
• si vous avez besoin d’exporter les données pour votre expert-comptable (vérifiez les formats possibles avec lui),
• si vous voulez un outil en réseau, voire en ligne sur internet,
• si vous avez déjà utilisé un logiciel et que vous vous y retrouvez.

NB Si qui peut le plus, peut le moins, sachez toutefois rester modestes si vous manquez de temps et de compétences, parce que les outils intégrés demandent une certaine maîtrise. Eh oui ! plus vous intégrez de trucs, plus il faut remplir et paramétrer les trucs avant d’utiliser la partie comptable. Par exemple, sur le cas simple d’une vente, avec un outil intégré il faudra avoir créé les produits, leurs taxes, le client, son bon de commande et les moyens de paiements avant d’attaquer la partie comptable.

Attention aux obligations fiscales françaises (utilisées lors d’un contrôle fiscal)

En application du 3° bis du I de l'article 286 du Code général des impôts (CGI), toute personne assujettie à la taxe sur la valeur ajoutée (TVA) qui effectue des livraisons de biens et des prestations de services à destination de clients particuliers et qui enregistre les règlements reçus en contrepartie au moyen d’un logiciel ou d’un système de caisse, est tenue d’utiliser un logiciel ou un système qui satisfasse aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale.

Tous les détails dans l’article du Bulletin Officiel des Finances Publiques - Impôts (BOFIP) TVA - Régimes d’imposition et obligations déclaratives et comptables - Obligations d’ordre comptable - Obligation d’utilisation de logiciels ou systèmes de caisse sécurisés

Format Fichier des Écritures Comptables (FEC)

Fichier texte tabulaire de 18 champs délimités par barres verticales ou par tabulations, ayant un nommage et un encodage précis ou éventuellement au format XML. Ce format est utilisé par la DGFiP pour pouvoir faire un contrôle automatisable de la comptabilité. Elle fournit un utilitaire de validation de format pour Windows.

Les points de vente

En France, la loi « anti-fraude » de 2016 et l’article 286 du Code des impôts imposent une certification des logiciels de caisse (c’est-à-dire des points de vente qui collectent des espèces) pour éviter les trucages de la comptabilité via modifications du code-source. Ah ben alors fini le libre ? Mais non mon bon, les logiciels libres sont autorisés, on en a beaucoup parlé sur LinuxFr.org. Toutes les structures n’y sont pas tenues, typiquement il faut être assujetti à la TVA.
NB Depuis la loi de finance 2018, article 105, les logiciels de comptabilité n’ont pas à être certifiés.

Si vous avez encore des doutes, consultez la FAQ en français facile écrite par l’équipe de Dolibarr.

La gestion de la paie

On n’en a pas beaucoup parlé alors que cette dépêche a commencé avec la recherche d’un logiciel de paie libre. Disons tout de suite qu’il est préférable de s’appuyer sur des professionnels, en effet la gestion de la paye repose sur trois piliers :

1. la fiche de paie et les déclarations afférentes
2. l’émission et la conservation sécurisée de la fiche de paie
3. la saisie comptable

Certains logiciels ont des modules de gestion des payes (OpenConcerto pour la paie française, Odoo pour plusieurs pays…). L’avantage est de faciliter les écritures comptables. Mais attention, la gestion de la paye impose un suivi juridique et un suivi des taux des cotisations, car le cadre légal varie selon les professions, les salaires et varie aussi dans le temps. Cette actualisation permanente est faite par les professionnels (comptables et experts comptables). Sauf à bien connaître votre profession ou à être dans un cadre relativement simple (par exemple celui des intermittents du spectacle en France), vous gagnerez du temps, de l’argent et de la « légalité » en passant par des professionnels. Les options les plus courantes sont de choisir un cabinet d’expertise comptable ou un service en ligne (nettement moins cher). Lisez ou relisez les commentaires du forum.

S’agissant de la saisie et du traitement comptable de la paie, n’importe quel logiciel de comptabilité peut le faire, les logiciels de paye étant souvent susceptibles de mâcher le travail à ce niveau-là.

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC3 du 10 février 2025 (en anglais).

Nous sommes ravis de partager la troisième version candidate de GIMP 3.0 pour ce qui (nous l'espérons) sera la dernière série de tests communautaires avant la version stable ! Cette version fait suite à la récente conférence GIMP 3 and Beyond de Jehan au FOSDEM 2025.

Sommaire

• Corrections de bogues et changements importants
  • Nouvelle version de GTK3
  • Améliorations du graphe d'images
  • Changements dans Projection Thread-safe
  • Procédures privées
• Améliorations
  • Script-fu
    • API Filtre
    • Nouvelle syntaxe de passage des arguments par noms
  • Formats de fichiers
    • PSD
    • DDS
  • AppImage: c'est officiel !
  • Divers
• GEGL
• Statistiques
• Autour de GIMP
  • Miroirs de téléchargement
  • Comment citer GIMP dans la recherche
• Télécharger GIMP 3.0 RC3
• Et ensuite ?

Corrections de bogues et changements importants

Alors que nous réduisions les quelques derniers bogues majeurs à néant, nous avons effectué un certain nombre de modifications qui selon nous nécessitent un sérieux coup d’œil de la communauté.
Jetez-en donc un, d’œil, sur les points suivants lorsque vous essayerez la Release Candidate:

Nouvelle version de GTK3

Juste à temps pour GIMP 3.0, une nouvelle version de GTK3 est sortie !
Entre autres changements, GTK 3.24.48 inclut des correctifs pour plusieurs bugs affectant GIMP avec des patchs initialement fournis par Jehan, comme un crash dans Wayland lors du déplacement de calques et des problèmes de texte dans certains widgets avec des langues de droite à gauche. Nous tenons à remercier Carlos Garnacho et Matthias Clasen pour leur aide sur ces patchs respectifs.

GTK 3.24.48 ajoute également la prise en charge de la version 2 de xdg_foreign pour Wayland (la v1 reste prise en charge en tant que solution de secours). Plus précisément, l'absence de cette prise en charge provoquait le blocage de GIMP avec certaines actions sur KDE/Wayland, ce qui est désormais corrigé.

En raison de ces problèmes (certains d'entre eux rendant GIMP vraiment instable sur Wayland), nous recommandons aux empaqueteurs de mettre à jour vers la dernière version de GTK3 lors de l'empaquetage de notre RC3. Cependant, veuillez nous informer si vous remarquez des régressions ou d'autres problèmes résultant de la nouvelle version de GTK3.

Améliorations du graphe d'images

Grâce à l'édition non destructive dans GIMP, les utilisateurs peuvent désormais empiler plusieurs filtres les uns sur les autres. Ces filtres fonctionnent généralement dans un format à haute résolution de bits, de sorte que les informations de l'image ne sont pas perdues. Cependant, la sortie de chaque filtre était convertie vers et depuis la résolution de l'image d'origine lors de l'empilement. Ainsi, si l'image n'était que de 8 bits, une grande quantité d'informations était perdue dans ces conversions constantes. Jehan a résolu ce problème en convertissant uniquement au format de l'image lorsque le filtre est censé être fusionné, plutôt que dans des piles non destructives. Comme il s'agit d'un changement important dans le fonctionnement des filtres, nous souhaitons que davantage d'utilisateurs testent ce changement pour détecter d'éventuelles régressions.

Changements dans Projection Thread-safe

Lorsque des modifications sont apportées à une image (comme une peinture), la projection de l'image doit être « vidée » pour afficher les nouvelles modifications à l'écran. Certains aspects de ce processus n'étaient pas « thread-safe », ce qui signifie que lorsque votre ordinateur utilisait plusieurs threads pour accélérer le travail, ils pouvaient entrer en conflit les uns avec les autres et provoquer un plantage. Cela a été observé dans notre fonctionnalité d'expansion automatique de calques. Jehan a corrigé la fonction pour qu'elle soit entièrement thread-safe. Cependant, les modifications apportées au multithreading peuvent laisser des bugs bien cachés, donc des tests communautaires supplémentaires seraient utiles.

Procédures privées

Le navigateur de base de données procédurale de GIMP montre aux développeurs de greffons et de scripts toutes les fonctions auxquelles ils peuvent accéder. Jusqu'à présent, il affichait également les fonctions « privées » qui ne sont utilisées qu'en interne. Jehan a ajouté un indicateur pour masquer ces fonctions. Dans un premier temps, nous avons ratissé trop large et caché certaines fonctions publiques importantes. Bien que nous ayons corrigé ces cas, nous aimerions que la communauté nous donne plus de détails pour nous assurer que nous n'avons oublié aucune fonction publique mal étiquetée.

Améliorations

Bien que nous soyons toujours en phase de gel des fonctionnalités majeures jusqu'à la version stable de GIMP 3.0, quelques améliorations mineures et autonomes ont été apportées aux greffons.

Script-fu

API Filtre

Le nouvel appel PDB (gimp-drawable-merge-filter) permet aux auteurs de Script-fu d'utiliser des étiquettes pour spécifier les propriétés des filtres. Cela donnera aux utilisateurs de Script-fu la même flexibilité pour appeler et mettre à jour les filtres que les développeurs de greffons C et Python ont dans l'API GIMP 3.0. À titre d'exemple, voici un appel au filtre Emboss :

(gimp-drawable-merge-new-filter mask-emboss "gegl:emboss" 0 LAYER-MODE-REPLACE 1.0 "azimuth" 315.0 "elevation" 45.0 "depth" 7 "type" "emboss")

Vous pouvez voir plus d'exemples dans notre dépôt de scripts.

Nouvelle syntaxe de passage des arguments par noms

Dans Script-Fu, toutes les fonctions générées à partir de la procédure PDB des greffons doivent désormais être appelées avec une toute nouvelle syntaxe d'argument nommé, inspirée de la variante Racket de Scheme.

Par exemple, disons que votre greffon souhaite appeler le greffon Foggify, au lieu d'appeler :

(python-fu-foggify RUN-NONINTERACTIVE 1 (car (gimp-image-get-layers 1)) "Clouds" '(50 4 4) 1.0 50.0)

Vous devez maintenant appeler :

(python-fu-foggify #:image 1 #:drawables (car (gimp-image-get-layers 1)) #:opacity 50.0 #:color '(50 4 4))

Cela présente quelques avantages :

• des appels beaucoup plus auto-documentés, d'autant plus que certains greffons ont beaucoup d'arguments (on pouvait donc se retrouver avec des fonctions avec une douzaine d'entiers ou de flottants et c'était très déroutant) ;
• l'ordre des arguments n'a plus d'importance ;
• vous pouvez ignorer les arguments lorsque vous les appelez avec des valeurs par défaut ;
• cela permet d'améliorer les procédures des greffons dans le futur en ajoutant de nouveaux arguments sans casser les scripts existants.

Ce dernier point en particulier est important, et l'ordre des arguments n'avait plus d'importance lors de l'appel de procédures PDB depuis l'API C, ainsi que toutes les liaisons introspectées. Script-Fu était la seule interface restante dont nous disposions qui se souciait encore de l'ordre et du nombre d'arguments. Ce n'est plus le cas et c'est donc un grand pas vers une API beaucoup plus robuste pour GIMP 3 !

Formats de fichiers

Toutes les modifications apportées aux greffons de chargement d'images sont vérifiées avec le cadriciel de tests automatisés créé par Jacob Boerema pour éviter les régressions.

PSD

En plus des corrections de bogues telles que l'enregistrement correct des images fusionnées CMJN, Jacob Boerema a ajouté la prise en charge du chargement des fichiers PSD LAB 16 bits par canal. Il a également mis à jour la boîte de dialogue d'exportation PSD pour utiliser les fonctions d'exportation de métadonnées intégrées de GIMP.

DDS

CMYK Student a implémenté la prise en charge très demandée du chargement d'images DDS avec prise en charge BC7. Jacob Boerema a travaillé pour corriger la compatibilité avec les fichiers DDS exportés à partir d'anciennes versions de GIMP.

AppImage: c'est officiel !

Après neuf mois d'incubation (le nombre est une simple coïncidence 🙂), nous présentons un « nouveau » format de distribution pour les utilisateurs Linux : .AppImage. Au départ, nous l'utilisions comme format interne pour les tests, comme déjà évoqué dans des articles précédents. Les efforts de Bruno Lopes nous ont permis d'améliorer le processus de construction. Nous sommes maintenant confiants avec l'AppImage générée et nous avons donc pour objectif de la rendre officielle.

En tant que package officiel en amont, aucun greffon tiers sophistiqué ou autre binaire arbitraire qui ne soit pas une dépendance de GIMP n'est ajouté pour ne pas le « surcharger ». C'est ce que certains appellent GIMP « vanilla », un GIMP propre mais complet pour la production (c'est-à-dire pour une utilisation générale).

Comme tout format d'empaquetage, il a ses propres caractéristiques et limites. Dans le cas de l'AppImage de GIMP, les outils inclus tels que gimp-console* et gimp-debug-tool* nécessitent une extraction préalable du fichier .AppImage avec la commande --appimage-extract. De plus, en partie à cause de la conception d'AppImage, les commandes qui pointent vers $PWD ne fonctionneront pas. Ces deux limitations de fonctionnalités sont les seules connues à ce jour. Donc, si vous en trouvez d'autres ou même des bogues, veuillez les signaler sur notre outil de suivi.

Divers

• Il est maintenant plus facile de charger des images depuis Google Drive ainsi que d'autres plateformes distantes ou dans le cloud, sans avoir a sélectionner un format de fichier pour essayer de l'ouvrir.

• Notre processus de création génère désormais des icônes supplémentaires avec l'extension -rtl, qui sont automatiquement utilisées avec les langues s'écrivant de droite à gauche. Les icônes de flèches gauche et droite en sont un exemple : elles sont désormais orientées dans la bonne direction dans les deux types de langues.

• Les développeurs de greffons n'ont plus besoin de créer des boutons de sélection de fichiers personnalisés - GimpProcedureDialog les crée désormais automatiquement lorsqu'un paramètre de type de fichier est utilisé. Vous pouvez également spécifier si le bouton sert à ouvrir ou à enregistrer des fichiers et des dossiers.

• Rupert Weber a continué ses efforts pour nettoyer notre greffon BMP. De plus, il travaille actuellement à ajouter la prise en charge de l'importation de profils de couleurs dans les BMP, qui, espérons-le, sera prête dans une future version.

• CMYK Student a mis à jour le greffon ICNS avec une nouvelle prise en charge des types d'icônes « ic05 » et des formats d'icônes ARGB. Ils ont également corrigé un bogue lors du chargement d'anciens formats ICNS sans masque de transparence. Lukas Oberhuber a aidé à diagnostiquer et à résoudre un bogue connu dans le format ICNS qui faisait que notre icône macOS affichait des pixels brouillés dans les petites tailles.

GEGL

La version 0.4.54 de GEGL contient également quelques améliorations et corrections de bogues. Thomas Manni a mis à jour le filtre Noise Spread pour éviter les bogues lorsqu'il est appliqué à des groupes de calques vides. Jonny Robbie a ajouté de nouvelles options et de nouveaux types de papier au filtre Negative Darkroom, et a optimisé certaines opérations en virgule flottante dans GEGL dans son ensemble.

Statistiques

Depuis GIMP 3.0 RC2, dans le dépôt principal de GIMP :

• 85 rapports ont été fermés comme RÉPARÉS ;
• 56 demandes de fusion ont été acceptées ;
• 335 commits ont été poussés ;
• 19 traductions ont été mises à jour : basque, bulgare, catalan, chinois (Chine), danois, néerlandais, finnois, géorgien, italien, norvégien nynorsk, persan, portugais, slovaque, slovène, espagnol, suédois, turc, ukrainien, vietnamien.

33 personnes ont contribué à des modifications ou des correctifs à la base de code de GIMP 3.0.0 RC3 (l'ordre est déterminé par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :

• 13 développeurs pour le code principal : Jehan, Alx Sa, Jacob Boerema, Lloyd Konneker, Anders Jonsson, Thomas Manni, Bruno, Daniele Forsi, Lloyd Konneker, Lukas Oberhuber, Rupert, cheesequake, Øyvind Kolås ;
• 10 développeurs de greffons ou modules : Alx Sa, Jacob Boerema, Jehan, Rupert, Lloyd Konneker, Anders Jonsson, Bruno, Daniel Novomeský, Daniele Forsi, lillolollo ;
• 19 traducteurs : Alan Mortensen, Alexander Shopov, Nathan Follens, Kolbjørn Stuestøl, Hugo Carvalho, Asier Sarasua Garmendia, Ngọc Quân Trần, Jordi Mas, Marco Ciampa, Sabri Ünal, Anders Jonsson, Danial Behzadi, Ekaterine Papava, Jiri Grönroos, Jose Riha, Luming Zh, Martin, Rodrigo Lledó, Yuri Chornoivan ;
• 1 Concepteur de thème : Alx Sa ;
• 6 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno, Jehan, Lloyd Konneker, Alx Sa, Rupert, Jacob Boerema.

Contributions sur d'autres dépôts dans GIMPverse (l'ordre est déterminé par le nombre de commits) :

• GEGL 0.4.54 est composé de 11 commits de 16 contributeurs : Øyvind Kolås, Alexander Shopov, Hugo Carvalho, JonnyRobbie, Alan Mortensen, Anders Jonsson, Asier Sarasua Garmendia, Bartłomiej Piotrowski, Jehan, Martin, Nathan Follens, Nils Philippsen, Rodrigo Lledó, Sam L, Thomas Manni, Yuri Chornoivan ;
• ctx a enregistré 233 commits depuis la sortie de RC2 par 1 contributeur : Øyvind Kolås ;
• gimp-data a enregistré 6 commits de 4 contributeurs : Bruno, Jehan, Alx Sa, Andre Klapper ;
• gimp-test-images (nouveau référentiel pour les tests de prise en charge des images) a enregistré 5 commits de 2 contributeurs : Jacob Boerema, Alx Sa ;
• la version gimp-macos-build (scripts de packaging macOS) a eu 6 commits par 2 contributeurs : Lukas Oberhuber, Bruno ;
• la version flatpak a eu 12 commits par 3 contributeurs après la version RC2 : Bruno Lopes, Jehan, Hubert Figuière ;
• notre site web principal a eu 42 commits par 6 contributeurs : Jehan, Alx Sa, Bruno, Jacob Boerema, Andre Klapper, Petr Vorel ;
• notre site web de développement a eu 18 commits par 5 contributeurs : Jehan, Bruno, Lukas Oberhuber, Alx Sa, Anders Jonsson ;
• notre documentation 3.0 comptait 373 commits de 13 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Nathan Follens, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Dick Groskamp, ​​Jordi Mas, Alevtina Karashokova, Alx Sa, Anders Jonsson, Daniele Forsi, Hugo Carvalho.

N'oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, à signaler les bugs et à discuter des améliorations possibles avec nous.
Notre communauté est également profondément reconnaissante envers les guerriers d'Internet qui gèrent nos divers canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via les scripts « git », des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons oublié ou mal classé certains contributeurs ou contributions.

Autour de GIMP

Miroirs de téléchargement

Depuis la publication de la nouvelle version 3.0RC2, deux nouveaux miroirs ont été ajoutés :

• Saswata Sarkar, Gurugram, Inde ;
• Hoobly Classifieds, États-Unis.

Les miroirs sont importants car ils aident le projet en répartissant la charge pour des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous garantissons que tout le monde peut avoir un accès rapide au téléchargement de GIMP.

Comment citer GIMP dans la recherche

GIMP est souvent utilisé dans la recherche et est donc cité dans diverses publications scientifiques. Un chercheur utilisant GIMP pour le traitement d'images astronomiques nous a contactés pour savoir comment citer GIMP correctement, d'autant plus qu'il est utilisé pour effectuer une étape importante de son algorithme.

Comme cela semble être une question intéressante, nous avons mis à jour notre page « Citing GIMP and Linking to Us » avec une nouvelle sous-section « Citing GIMP in research » contenant la conclusion de cette discussion.

En particulier, une entrée BibTex, destinée aux chercheurs utilisant LaTeX pour gérer leur bibliographie, est disponible sur ce lien pour simplifier votre travail. Par exemple, disons que vous utilisez ce RC3 pour vos recherches, vous pouvez citer GIMP avec cette entrée :

@software{GIMP,
    author = {{The GIMP Development Team}},
    title = {GNU Image Manipulation Program (GIMP), Version 3.0.0-RC3. Community, Free Software (license GPLv3)},
    year = {2025},
    url = {https://gimp.org/},
    note = {Version 3.0.0-RC3, Free Software}
}

Merci à Cameron Leahy pour ce morceau de code BibTex !

Télécharger GIMP 3.0 RC3

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

• Linux AppImages pour x86 et ARM (64 bits) ;
• Linux Flatpaks pour x86 et ARM (64 bits) ;
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits) ;
• Paquet MSIX (GIMP Preview) pour x86 et ARM (64 bits) ;
• Paquets macOS DMG pour le matériel Intel ;
• Paquets macOS DMG pour le matériel Apple Silicon.

D'autres paquets réalisés par des tiers devraient évidemment suivre (paquets de distributions Linux ou *BSD, etc.).

Et ensuite ?

Nous apprécions vraiment tous les tests et commentaires de la communauté que nous avons reçus au cours des deux dernières versions candidates !
Nous espérons que ce sera la dernière version candidate avant la version stable 3.0. Notre objectif est maintenant de terminer la résolution des quelques bugs restants dans notre liste de jalons 3.0, tout en gardant un œil sur les nouveaux rapports résultant des changements dans RC3.

N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, afin de contribuer et d’accélérer le développement de GIMP. L’engagement de la communauté aide le projet à se renforcer !

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC2 du 27 décembre 2024 (en anglais).

Après la première série de retours de la communauté, nous sommes heureux de partager la deuxième version candidate de GIMP 3.0 ! Les gens nous ont donné des commentaires très utiles sur la première version candidate et nous avons pu corriger de nombreux bugs.

C’est notre petit cadeau sous le sapin 🎄 pour vous tous ! (NdM: disons fourré dans la galette/le gâteau des rois désormais ?)

Écran de démarrage de la nouvelle version candidate, par Sevenix (CC by-sa 4.0) - GIMP 3.0 RC2

Sommaire

• Corrections de bugs importantes
  • Migration des paramètres de la 2.10
  • Console Windows
  • Problèmes de polices d’interface utilisateur manquantes sur macOS
  • Intégration de darktable
• Améliorations
  • API de filtre GEGL
  • Espaces de fusion de calques et composition dans les fichiers XCF
  • Paquets
    • AppImage
    • Flatpak
  • Améliorations du greffon BMP
  • Mises à jour diverses
• Aperçu des changements depuis la version 2.10
• GEGL
• Statistiques de sortie
• Autour de GIMP
  • Miroirs de téléchargement
    • Comment devenir un miroir officiel (mise à jour de la procédure)
    • Changements dans les miroirs
  • Financer des exécuteurs ("runner") GitLab
• Télécharger GIMP 3.0 RC2
• Et ensuite ?

Corrections de bugs importantes

Plusieurs correctifs ont été apportés depuis la version RC1. Nous souhaitons mettre en évidence les bugs les plus importants afin que les utilisateurs en soient informés et puissent effectuer des tests supplémentaires. Pour plus de détails sur les autres correctifs de bugs, veuillez consulter notre page NEWS sur GitLab.

Migration des paramètres de la 2.10

Lors des tests communautaires, nous avons découvert que les paramètres des utilisateurs de la 2.10 n’étaient pas migrés vers GIMP 3.0 en raison de certaines hypothèses incorrectes dans le code d’importation. Étant donné que la plupart des développeurs utilisent exclusivement GIMP 3.0 depuis un certain temps, nous n’avions pas remarqué ce problème. Le bug devrait maintenant être corrigé, nous demandons donc des rapports de bugs si des préférences 2.10 ne sont pas importées correctement dans RC2. Notez que si vous avez déjà utilisé 3.0 RC1, vous devrez d’abord supprimer ces configurations, sinon RC2 n’essaiera pas d’importer les préférences 2.10 (assurez-vous de sauvegarder vos paramètres bien sûr !).

Console Windows

Dans les versions de développement 2.99, les versions Windows lançaient automatiquement un affichage de console en plus de GIMP lui-même. C’est très utile pour les développeurs Windows pour voir les messages de débogage, mais la console n’était pas destinée à être affichée pendant les versions stables. Comme nous avons modifié notre processus de construction pour utiliser Meson au lieu d’Autotools, nous avons appris que nous devions apporter des modifications supplémentaires pour empêcher l’affichage de la console. Cela devrait être corrigé maintenant grâce à Jehan - si vous voyez toujours la console sous Windows, veuillez remplir un nouveau rapport de bogue !

Problèmes de polices d’interface utilisateur manquantes sur macOS

Il y a un problème de longue date où certains utilisateurs de macOS ne voyaient que des symboles « Unicode manquants » au lieu des textes d’interface dans GIMP (à la fois dans la version 2.10 et dans la version 3.0). Cela était dû à un bug dans Pango, la bibliothèque que nous utilisons pour les mises en page de texte. Ce problème a été résolu avec la récente version Pango 1.55.0, nous encourageons donc tous les empaqueteurs macOS tiers à mettre à jour vers cette version lorsqu’ils construisent GIMP pour le distribuer.

Si vous aviez ce problème de polices cassées sur macOS (à gauche), il est désormais résolu (à droite) - captures d’écran de rapporteurs de bug - GIMP 3.0.0 RC2

Intégration de darktable

Après la sortie de la version 3.0 RC1, nous avons reçu des rapports de certains utilisateurs indiquant qu’ils ne pouvaient toujours pas importer et exporter d’images entre GIMP et darktable. Nous avons travaillé avec les développeurs de darktable pour éliminer les bugs restants, de sorte que l’intégration entre darktable 5.0.0 et GIMP 3.0 RC2 devrait désormais fonctionner pour tout le monde. Cependant, veuillez déposer un nouveau rapport de bogue si vous continuez à rencontrer des problèmes pour connecter les deux !

Améliorations

Bien que l’objectif principal du développement de la version 3.0 RC2 ait été la correction de bugs et le peaufinage, certaines nouvelles fonctionnalités ont également été implémentées.

API de filtre GEGL

De nombreux anciens wrappers d’API pour les opérations GEGL ont été supprimés dans la version RC1. Bien que cela ait réduit la dette technique, cela a également causé des problèmes à de nombreux développeurs de greffons et de scripts tiers qui souhaitaient porter leurs greffons vers la version 3.0. Alors que notre plan initial était d’implémenter la nouvelle API publique de filtre après la sortie de la version 3.0, les commentaires de la communauté nous ont convaincu de l’ajouter pour la version 3.0 RC2.

Application de filtres via l’API libgimp 3.0.0 (Script-fu et al.) - GIMP 3.0.0 RC2

Le travail de Jehan permet aux développeurs d’appliquer des effets de filtre soit immédiatement, soit de manière non destructrice. Vous pouvez voir des exemples de la manière de procéder en C, Python et Script-Fu dans la requête de fusion, ou en recherchant gimp-drawable-filter dans le navigateur de procédures de GIMP. Nous avons également commencé à utiliser l’API de filtre dans nos scripts Python pour créer automatiquement des effets d’arrière-plan flou pour le programme d’installation Windows, et avec cette même API en C, Alx Sa a ajouté la prise en charge de l’importation de l’ancien style de calque Color Overlay de Photoshop.

Nous sommes preneurs des retours et des rapports de bugs d’auteurs de greffons et de scripts qui utilisent la nouvelle API de filtrage dans leur travail ! Nous avons également prévu d’autres mises à jour pour GIMP 3.0.

Espaces de fusion de calques et composition dans les fichiers XCF

Les discussions entre les experts en science des couleurs Elle Stone et Øyvind Kolås ont révélé un autre domaine nécessitant des améliorations dans le cadre de notre projet Color Space Invasion. Plus précisément, les images avec des profils de couleurs qui ont des courbes de reproduction des tons non perceptives peuvent ne pas être rendues correctement lorsqu’elles sont définies sur certains modes de calque.

Øyvind a implémenté une correction pour ce problème en ajoutant un espace perceptuel approprié par défaut à des modes de calque spécifiques. Bien que nous pensions que cette amélioration ne devrait pas avoir d’impact sur les fichiers XCF plus anciens, n’hésitez pas à rapporter tous problèmes de compatibilité avec la version 3.0 RC2 !

Paquets

AppImage

Grâce aux efforts continus de Bruno Lopes et avec l’aide de Samueru et de la communauté AppImage, notre AppImage expérimentale fonctionne désormais sur la plupart des distributions Linux. Nous souhaitons encourager davantage de tests, dans l’espoir de pouvoir la proposer comme une autre version Linux en plus de notre Flatpak. Vous pouvez consulter les instructions pour installer les paquets expérimentaux AppImage sur notre page de téléchargement des versions de développement.

Flatpak

Notre flatpak journalier a maintenant un App-ID dédié org.gimp.GIMP.Nightly. Cela signifie principalement qu’il peut être installé côte à côte avec le flatpak stable tandis que les deux sont visibles dans vos menus (plus besoin de sélectionner quelle version doit être affichée avec flatpak make-current).

Mais cela signifie également que tous ceux qui avaient le flatpak journalier jusqu’à présent ne verront pas de mise à jour arriver de sitôt. Afin de continuer à utiliser le flatpak journalier, désinstallez celui existant et installez le nouveau avec ces commandes :

flatpak uninstall org.gimp.GIMP//master
flatpak install https://nightly.gnome.org/repo/appstream/org.gimp.GIMP.Nightly.flatpakref

⚠️ Rappel : le flatpak journalier contient le code de développement actuel tel qu’il se présente dans le dépôt source. Parfois, il peut même être très cassé ou rendre vos fichiers de projet invalides. Nous ne le recommandons pas pour la production ! Utilisez cette version pour nous aider à déboguer en signalant les problèmes ou si vous aimez vraiment les risques pour tester les dernières fonctionnalités.

Améliorations du greffon BMP

Le nouveau contributeur Rupert Weber a été très occupé depuis la dernière mise à jour avec de nouvelles mises à jour de notre greffon BMP. Quelques points de son travail à mettre en avant :

• Les fichiers BMP sont désormais importés sans perte dans leur précision d’origine, plutôt que d’être convertis en précision entière de 8 bits.
• Le greffon prend désormais en charge le chargement de fichiers BMP avec compression RLE24 et Huffman.
• Nous chargeons désormais les fichiers BMP par morceaux plutôt que d’essayer de charger l’image entière en une seule fois. Des travaux connexes nous permettent également de charger des fichiers BMP beaucoup plus volumineux.
• Rupert a également effectué beaucoup de nettoyage et de maintenance du code, afin de rendre le greffon plus facile à maintenir à l’avenir.

Mises à jour diverses

• Jehan a apporté quelques améliorations d’usage de la console Python. Vous pouvez désormais utiliser les raccourcis Ctrl+R et Ctrl+S pour parcourir votre historique de commandes, et Page précédente et Page suivante vous permettent désormais de faire défiler l’historique en plus des touches fléchées Haut et Bas.

Recherche dans l’historique de commande (console Python) - GIMP 3.0.0 RC2

• Alx Sa a implémenté le chargement des fichiers CMJN PAM dans le greffon PNM.

• Sous Windows, nous avons également ajouté la possibilité d’ouvrir des images via des raccourcis Windows (fichiers .lnk) directement depuis la boîte de dialogue de sélection de fichiers. Ce travail est également réalisé par Alx Sa.

• D’autres modifications et améliorations ont été apportées au thème. En particulier, le style du « curseur compact » a été considérablement amélioré après les commentaires et le travail de Denis Rangelov. Denis a également créé de nouvelles icônes pour la boîte de dialogue de navigation ancrable, remplaçant les doublons par des symboles distincts. Anders Jonsson a également révisé le thème et supprimé certaines solutions de contournement qui étaient nécessaires dans GIMP 2.10, mais qui ne sont plus nécessaires avec nos nouveaux thèmes 3.0.

• Idriss Fekir a apporté des améliorations à notre code de chargement de polices XCF, pour améliorer la compatibilité lors de l’importation d’anciens fichiers XCF.

Aperçu des changements depuis la version 2.10

Pour ceux qui n’ont pas suivi de près le développement de GIMP, cet article ne couvre que les changements progressifs depuis la dernière version. Ils ne répertorient pas tous les changements ou améliorations apportés à GIMP 3.0 - ce serait un article très long !

Bien que nous aurons des notes de version complètes pour la version finale 3.0, nous avons pensé qu’il serait utile de résumer quelques-uns des changements majeurs apportés au cours du processus de développement de la version 2.99 :

• Le travail initial de portage de GIMP vers GTK3 a eu lieu dans 2.99.2. Cette version a également introduit la sélection multi-calque, ainsi que des modifications initiales de l’API et des améliorations de la gestion de l’espace colorimétrique.
• D’autres mises à jour de l’API ont été effectuées dans 2.99.4, notamment la possibilité de générer automatiquement des interfaces utilisateur de greffon en fonction des entrées de l’utilisateur. Diverses améliorations de convivialité ont également été apportées, ainsi que l’introduction de l’outil expérimental Paint Select.
• 2.99.6 a apporté davantage de mises à jour de l’API et de travaux internes. D’autres fonctionnalités destinées à l’utilisateur incluent la possibilité de placer des guides en dehors du canevas, une meilleure prise en charge du pavé tactile et une meilleure prise en charge des différentes métadonnées de couleur PNG.
• Le pipeline de développement a été considérablement amélioré dans 2.99.8, permettant des temps de construction et une automatisation plus rapides. La prise en charge de nouveaux formats de fichiers tels que PSB et JPEGXL a été ajoutée dans cette version, ainsi que la prise en charge des pilotes Windows Ink de tablette graphique.
• 2.99.10 a introduit des « ensembles de calques », remplaçant l’ancien concept de calques liés. La dynamique de peinture a été rationalisée dans cette version, ainsi que la première version de la boîte de dialogue de bienvenue.
• La prise en charge de la liaison anticipée CMJN a été implémentée dans 2.99.12. Les thèmes de l’interface graphique CSS ont également fait l’objet d’une refonte majeure dans cette version, ainsi que davantage de prise en charge de formats de fichiers et d’améliorations majeures de Script-Fu.
• 2.99.14 a vu l’introduction de contours non destructifs pour l’outil de texte. L’outil d’alignement a également été révisé, la mise à l’échelle des thèmes et des icônes a été améliorée et les sélections flottantes ont été largement remplacées dans le flux de travail.
• Le portage GTK3 a finalement été achevé dans 2.99.16. La fenêtre contextuelle de recherche / a été mise à jour pour afficher le chemin du menu pour toutes les entrées, ainsi que pour permettre de chercher parmi les filtres.
• Les filtres non destructifs ont été introduits pour la première fois dans 2.99.18. Des améliorations majeures de la gestion des couleurs ont également été apportées, et de nouvelles options d’extension automatique des limites de calque et d’accrochage ont également été implémentées.

GEGL

Tout comme pour GIMP, la version 0.4.52 de GEGL a été corrigée. Øyvind Kolås a corrigé certaines étiquettes génériques « Entrée auxiliaire » pour qu’elles soient plus significatives. Elles seront également visibles dans les filtres de GIMP. Il a également amélioré la précision du traitement des couleurs de certains filtres. Thomas Manni, contributeur de longue date, a également corrigé les plantages lorsque certains filtres étaient exécutés sur de très petits calques.

Statistiques de sortie

Depuis GIMP 3.0 RC1, dans le dépôt principal de GIMP :

• 73 rapports ont été fermés comme CORRIGÉS.
• 71 demandes de fusion ont été acceptées.
• 277 commits ont été poussés.
• 18 traductions ont été mises à jour : bulgare, catalan, chinois (Chine), chinois (Taïwan), danois, finnois, géorgien, islandais, italien, letton, lituanien, norvégien nynorsk, persan, portugais, russe, slovène, suédois, ukrainien.

35 personnes ont contribué à des modifications ou des correctifs à la base de code de GIMP 3.0.0 RC2 (l’ordre est déterminé par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :

• 12 développeurs pour le code principal : Jehan, Alx Sa, Michael Schumacher, Anders Jonsson, Lloyd Konneker, Øyvind Kolås, Idriss Fekir, Andre Klapper, Jacob Boerema, Michael Natterer, Rupert Weber, Thomas Manni.
• 11 développeurs de plug-ins ou modules : Jehan, Lloyd Konneker, Alx Sa, Rupert Weber, Daniel Novomeský, Jacob Boerema, Aki, Bruno, Ryan Sims, Simon Munton.
• 19 traducteurs : Alan Mortensen, Cheng-Chia Tseng, Kolbjørn Stuestøl, Rūdolfs Mazurs, Jiri Grönroos, Sveinn í Felli, Alexander Shopov, Aurimas Černius, Marco Ciampa, Danial Behzadi, Hugo Carvalho, Jordi Mas, Anders Jonsson, Ekaterine Papava, Julia Dronova, Luming Zh, Martin, Michael Schumacher, Youri Chornoivan.
• 2 concepteurs de thèmes : Alx Sa, Anders Jonnson.
• 2 contributeurs à la documentation : Jehan, Bruno.
• 5 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno, Jehan, Lloyd Konneker, Alx Sa, Jacob Boerema, Rupert Weber.

Contributions sur d’autres dépôts du GIMPverse (l’ordre est déterminé par le nombre de commits) :

• GEGL 0.4.52 est composé de 31 commits de 16 contributeurs : Øyvind Kolås, Sam L, Thomas Manni, lillolollo, Alan Mortensen, Anders Jonsson, Ekaterine Papava, Hugo Carvalho, Jordi Mas, Juliano de Souza Camargo, Kolbjørn Stuestøl, Lukas Oberhuber, Luming Zh, Marco Ciampa, Martin, Yuri Chornoivan.
• ctx a enregistré 48 commits depuis la sortie de la RC1 par 1 contributeur : Øyvind Kolås.
• gimp-data a enregistré 6 commits de 5 contributeurs : Anders Jonsson, Jehan, Sevenix, Alx Sa et Denis Rangelov.
• gimp-test-images (nouveau référentiel pour les tests de prise en charge des images) a enregistré 2 commits de 1 contributeur : Rupert.
• La version gimp-macos-build (scripts d’empaquetage pour macOS) a reçu 5 commits de 1 contributeur : Lukas Oberhuber.
• La version flatpak a reçu 4 commits de 2 contributeurs : Bruno Lopes, Jehan.
• Notre site Web principal a reçu 29 commits de 3 contributeurs : Jehan, Alx Sa, Andrea Veri.
• Notre site Web de développement a reçu 16 commits de 2 contributeurs : Jehan, Bruno Lopes.
• Notre documentation pour GIMP 3.0 a reçu 157 commits de 10 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Jacob Boerema, Alan Mortensen, Anders Jonsson, Marco Ciampa, Jordi Mas, Yuri Chornoivan, Alx Sa, Jiri Grönroos.

N’oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, à signaler les bugs et à discuter des améliorations possibles avec nous. Notre communauté est également profondément reconnaissante envers les guerriers d’Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via les scripts git, des erreurs peuvent se glisser dans ces statistiques. N’hésitez pas à nous dire si nous avons oublié ou mal classé certains contributeurs ou contributions.

Autour de GIMP

Miroirs de téléchargement

GNOME a abandonné l’utilisation de miroirs lors de sa dernière mise à jour d’infrastructure. Comme nos miroirs de téléchargement sont hébergés par eux, on nous a demandé si nous voulions également faire la même chose. En tant que projet communautaire, nous apprécions tous ceux qui contribuent un miroir pour rendre GIMP plus accessible dans leur région. Par conséquent, nous avons décidé de continuer à utiliser des miroirs pour distribuer GIMP.

Si vous souhaiter contribuer à un miroir pour votre région, voici la nouvelle procédure :

Comment devenir un miroir officiel (mise à jour de la procédure)

1. Créez une demande de miroir sur le tracker gimp-web
2. Dites-nous pourquoi vous souhaitez créer un miroir de GIMP, pour quels autres logiciels libres vous en contribuez déjà un, quelle est votre configuration, l’emplacement du serveur…
3. Parlez-nous de vous : êtes-vous une organisation ou un particulier ? Donnez-nous le nom et l’URL spécifiques à afficher dans la liste des sponsors de miroir.
4. Une fois que nous aurons terminé de vérifier votre organisation, les identifiants rsync seront échangés de manière sécurisée, vous permettant de synchroniser votre miroir avec le serveur source
5. Il n’y a rien de particulier à faire pour apparaître sur la page des sponsors qui sera mise à jour régulièrement via des scripts. Pourtant, cela peut prendre quelques jours, voire quelques semaines parfois. Ne vous inquiétez donc pas si le nom de votre organisation n’apparaît pas immédiatement !

🛈 Nous vérifions automatiquement à intervalles aléatoires que les miroirs sont mis à jour suffisamment rapidement et que les données correspondent pour des raisons de sécurité évidentes.

Changements dans les miroirs

De plus, depuis la publication de la nouvelle 3.0RC1, un nouveau miroir a été ajouté :

• Sahil Dhiman, Mumbai, Inde

Les miroirs sont importants, car ils aident le projet en répartissant la charge des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous garantissons que tout le monde peut avoir un accès rapide au téléchargement de GIMP.

Financer des exécuteurs ("runner") GitLab

Le dépôt de code de GIMP est également hébergé sur la plateforme GitLab de GNOME. Andrea Veri a demandé si nous pouvions financer un exécuteur [NDA: un "runner" est une sorte de serveur dédié à la compilation ou à l’intégration continue de manière générale] sur la plateforme, ce qui permet à tout projet sur la plateforme de tester la construction de son logiciel avant, pendant et après les modifications de code. Après un vote du comité de GIMP, nous avons accepté et sommes désormais les sponsors d’un exécuteur CI/CD x86 !

Télécharger GIMP 3.0 RC2

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

• Paquets Linux flatpaks pour x86 et ARM (64 bits)
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
• Paquet MSIX (aperçu GIMP) pour x86 et ARM (64 bits)
• Paquets macOS DMG pour le matériel Intel
• Paquets macOS DMG pour le matériel Apple Silicon

D’autres paquets réalisés par des tiers devraient évidemment suivre (paquets de distributions Linux ou *BSD, etc.).

🛈 Notes:

• Les 2 paquets DMG macOS seront probablement en retard, car nous attendons la validation de la mise à jour Apple par la Fondation GNOME avant de pouvoir signer nos paquets.
• Le paquet MSIX prend généralement quelques jours ouvrables de validation par Microsoft. (le paquet MSIX est disponible)

Et ensuite ?

Grâce au grand nombre de retours que nous avons reçus pour notre premier candidat à la version finale, nous sommes en mesure de vous présenter cette deuxième version qui en est d’autant plus robuste. Comme vous l’avez vu, quelques surprises supplémentaires 🎁 sont arrivées avec les corrections de bugs, notamment la nouvelle API de filtre, qui a déclenché la prise en charge de l’importation de l’ancien effet Color Overlay de PSD, des modes de fusion et de composition améliorés, et plus encore. Nous avons pensé que cela valait la peine de rompre le gel des fonctionnalités pour ces changements et que cela fera toute la différence !

Avec cette deuxième version candidate, nous sommes plus proches que jamais de la version 3.0.0 de GIMP. Comme d’habitude, nous attendons avec impatience les nouveaux rapports de problèmes de la communauté qui nous permettront de finaliser la version 3.0.0 ! 🤗

N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, afin de donner en retour et d’accélérer le développement de GIMP. L’engagement de la communauté aide le projet à se renforcer ! 💪🥳

🎅🎄🎉 Et bien sûr, toute l’équipe vous souhaite de joyeuses fêtes de fin d’année (MAJ de Jehan) nos meilleurs vœux pour la nouvelle année ! 🥳🥂🎆

FreeCAD est sorti le 18 novembre 2024 en version 1.0 (voir l'annonce officielle et sa vidéo associée). Cette sortie est marquée par une amélioration majeure : l'atténuation du problème de dénomination topologique.

Sommaire

• Qu'est-ce que FreeCAD ?
• Historique
• Le problème de dénomination topologique
• Les autres améliorations
  • Un outil d'assemblage par défaut avec solveur dynamique
  • L'atelier sketcher amélioré
  • Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC
  • L'atelier FEM
  • Le reste
• L'essai commercial d'Ondsel

La dernière dépêche sur FreeCAD remonte à avril 2021 pour la sortie de la version 0.19. Depuis, il y a eu les versions 0.20 (juin 2022) et 0.21 (août 2023). Cette version 1.0 a porté le nom de 0.22 pendant son développement.

Qu'est-ce que FreeCAD ?

Extrait de wiki.freecad.org :
FreeCAD est un modeleur paramétrique de CAO 3D open source sous licence LGPL. FreeCAD est destiné à l'ingénierie mécanique et à la conception de produits mais — étant très générique — il s'adapte également à une gamme plus large d'utilisations autour de l'ingénierie, telles que l'architecture, l'analyse par éléments finis, l'impression 3D et d'autres tâches.

FreeCAD propose des outils similaires à CATIA, SolidWorks, Solid Edge ou Revit et entre donc également dans la catégorie CAO, GCVP, CFAO, IAO et BIM. Il s'agit d'un modélisateur paramétrique basé sur les caractéristiques d'une architecture logicielle modulaire qui permet de fournir des fonctionnalités supplémentaires sans modifier le système de base.

FreeCAD est aussi multiplateforme. Il fonctionne sous Windows, Linux/Unix et macOS avec la même apparence et les mêmes fonctionnalités sous toutes les plateformes.

Historique

La toute première version de FreeCAD est sortie en 2002. FreeCAD est développé en C++, Qt et Python et son cœur repose sur les bibliothèques OpenCASCADE (ou OCCT) spécialisées dans la CAO.

Son développement est assuré par un large panel de contributeurs : certains sont historiques, d'autres sont spécialisés sur un aspect particulier et beaucoup sont plus ou moins occasionnels.

Les versions se sont enchaînées à un rythme quasi annuel, apportant moult améliorations et fonctionnalités nouvelles.

En 2021, quelques contributeurs historiques fondent la FreeCAD Project Association (FPA) qui est un organisme indépendant à but non lucratif pour collecter des dons et apporter un soutien au développement du projet.
Ce soutien passe notamment par leur programme "FreeCAD Grant Program", qui permet d'embaucher ou de récompenser des personnes pour des projets spécifiques. Ce programme a un budget de 50k$ pour l'année 2024. A titre d'exemple récent, 500$ ont été octroyés pour une étude sur les runners CI de Github, 1000$ pour un gros travail de correction de bugs, et enfin 500$ pour la création d'une vidéo sur les nouvelles fonctionnalités de cette version 1.0.

FreeCAD bénéficie d'une communauté impliquée permettant notamment d'avoir une documentation complète, à jour et traduite dans de nombreuses langues.

Le problème de dénomination topologique

C'était un des points noirs de FreeCAD jusqu'à cette version 1.0.
Il faut imaginer que dans ce logiciel, la modélisation d'une pièce (dans le sens objet physique) passe par une suite d'opérations mathématiques et géométriques en définissant à chaque fois des contraintes ou des paramètres. Une opération est par exemple la création d'un trou borgne de 5 mm sur telle face à 10 mm des bords haut et gauche. Un autre exemple est d'ajouter une « languette » sur telle face cylindrique. Ou bien d'ajouter un chanfrein de 2 mm sur telle arête, etc.

Ainsi, petit à petit, la pièce modélisée se construit, prend forme, se détaille et se complexifie.

Cet historique de ces opérations successives est toujours présent et modifiable. À tout moment, il est possible de modifier une des étapes intermédiaires.

D'un point de vue technique, vous aurez sans doute compris que chaque opération s'applique à un élément précis et existant de la pièce à ce moment-là (une face ou une arête par exemple). Dans FreeCAD ces éléments ont tous un identifiant unique (Face6, Edge9, etc.), continu et incrémental. Si l'objet a 13 faces à une des étapes, les faces seront numérotées de Face1 à Face13. Chaque opération est rattachée à l'identifiant de l'élément (Face5 par exemple).

Et le problème se situe à ce niveau : lors d'une modification d'une étape intermédiaire, il arrive souvent que cela change la géométrie globale de la pièce et donc que les nombres de faces ou d'arêtes augmentent ou diminuent. Et FreeCAD réattribue alors ces identifiants uniques aux différents éléments.
Ainsi, si l'objet passe de 13 à 11 faces, c'est l'ensemble des faces qui vont recevoir un nouvel identifiant dans la plage Face1 à Face11, avec un très fort risque qu'une face, pourtant non touchée par la modification, porte un identifiant différent.

Et vous voyez le problème arriver : si une des opérations suivantes dans l'historique était de faire un perçage sur la Face6 qui est maintenant devenue la Face3… Toute la modélisation part en vrille.

Ce problème de dénomination topologique est documenté sur le wiki de FreeCAD : problème de dénomination topologique.

Pour éviter cela, il était conseillé de suivre un ensemble de bonnes pratiques de modélisation sous FreeCAD : Édition de fonctions. Il faudra certainement suivre l'évolution de cette page avec cette sortie.

Cette version 1.0 marque donc l'intégration de codes correctifs de cette problématique. Les notes de version indiquent tout de même que tout n'est pas résolu, et qu'il y aura d'autres améliorations dans les prochaines versions. Cette petite vidéo en anglais vous montre la différence de comportement entre la version 0.21 et 0.22dev (qui a servi de base à la 1.0).

Les autres améliorations

Un outil d'assemblage par défaut avec solveur dynamique

Le terme assemblage désigne la fonctionnalité de regrouper plusieurs éléments afin d'obtenir un objet fonctionnel. Ce peut être, par exemple, une boîte constituée d'un couvercle sur charnières maintenues par des vis avec des rangements amovibles à l'intérieur. Ou bien un moteur thermique avec ses carters, vilebrequin, bielles, pistons, soupapes, etc. Il est parfois utile de pouvoir fournir des indications de positionnement et/ou de liberté des éléments entre eux, et de pouvoir animer le tout.
Ces opérations d'assemblage n'étaient pas intégrées dans FreeCAD avant la version 1.0. Elles étaient néanmoins possibles grâce aux ateliers. Plusieurs ont été créés pour cela avec chacun leurs spécificités et leurs approches mais aussi une incompatibilité entre eux : A2plus, Assembly3 ou Assembly4.
Cette version 1.0 propose un nouvel atelier mais intégré par défaut. Il a été mis au point par la société Ondsel (voir plus bas). Il est encore jeune, et il est encore trop tôt pour savoir s'il finira par s'imposer par rapport à l'existant déjà en place. Un tutoriel concernant l'atelier d'assemblage est d'ores et déjà disponible pour une introduction à cette nouvelle fonctionnalité de la v1.0.

L'atelier sketcher amélioré

Cet atelier permet de dessiner les esquisses techniques utilisées dans la conception mécanique. C'est dans celui-ci que sont dessinés les « plans 2D » avec les cotes et les contraintes dimensionnelles et spatiales. Cette version apporte un nombre conséquent d'améliorations et de nouvelles fonctionnalités rendant son utilisation plus facile, plus puissante et plus rapide. Le mieux est de regarder les notes de version animées.

Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC

Si le titre est cryptique, c'est que l'on parle de BTP et d'outils destinés aux équipes de Maîtrise d'Œuvre impliquées dans la conception d'une opération construction (Architectes, Bureaux d'Études). Comme ce n'est pas forcément le lot commun des visiteurs de LinuxFr.org, résumons la situation:

• L'atelier Arch, pour Architecture, exploite depuis longtemps les capacités de création 3D de FreeCAD pour dessiner facilement, fondations, murs, planchers, fenêtres, portes etc. Cet atelier se basait sur le format natif des fichiers FreeCAD, *.FcStd.

• Dans l'atelier BIM (pour Building Information Model <= l'article Wikipedia_FR est bien écrit pour qui veut comprendre l'essentiel), on retrouve un certain nombre d'outils de dessin et de création d'objets qui s'avèrent redondants pour certains avec ceux de l'outil Arch tout en implémentant les paradigmes bien plus vastes qu'induit l'approche BIM d'un projet de construction <=> pas uniquement de la géométrie, mais aussi du prix, des données mécaniques, physiques, des fiches produit, du planning …

• L'approche BIM tend à se généraliser dès lors que la complexité et le coût du projet le justifient. Elle repose (en théorie) sur un format d'échange IFC (pour Industry Foundation Class).
  Il est ouvert et au format texte.
  Oui avec vim, c'est possible de bidouiller ;)
  mais un fichier IFC fait rapidement quelques centaines de Mo voire quelques Go …

L'Association "Building Smart" en définit les caractéristiques. Tous les logiciels sur le marché savent ouvrir et exporter dans ce format, à la norme IFC 2.3 ad minima et IFC 4.2 voire 4.3 pour les up to date.

L'atelier BIM de FreeCAD utilisait jusqu'à présent IfcOpenShell, une application tierce Open Source pour convertir un fichier du format *.ifc vers du *.FcStd en passant (sans doute) par du OpenScad dans le processus.

Une image qui devrait parler au LinuxFrien (!) pour la classe IFC Material-Constituent-Set,

Pour la version 1.0 de FreeCAD, Yorik Van Havre, développeur historique de FreeCAD, (par ailleurs, architecte et Président la FreeCAD Project Association) a entrepris de fusionner ces deux ateliers, d'en faire une fonctionnalité native de FreeCAD, c'est-à-dire qui se passe du vaillant IfcOpenShell (grâce notamment au travail fait sur Blender-Bim) pour que FreeCAD puisse ouvrir et enregistrer directement au format IFC sans conversion inutile.

L'atelier FEM

Cet atelier d'analyse par éléments finis comporte également des améliorations considérées comme majeures avec cette version 1.0, détaillées dans un article de blog sur l'atelier FEM de FreeCAD.

Les avancées majeures sont liées à la prise en charge de fonctionnalités de CalculiX, un des solveurs utilisés par cet atelier : symétrie cyclique, analyses 2D et contraintes de corps rigide.

Le reste

Comme à chaque nouvelle version, beaucoup de choses ont été apportées, que ce soit dans l'interface, ou dans la plupart des ateliers intégrés. Les notes de version de la v1.0, comme très souvent détaillées en images, permettent de voir l'évolution de ce logiciel.

FreeCAD a également annoncé son nouveau logo, choisi après un appel à concourir auprès de la communauté (lien). Le logo en SVG est disponible sur cette page.

L'essai commercial d'Ondsel

Outre la création en 2021 de l'association FPA (voir plus haut), d'autres développeurs, notamment Brad Collette, mainteneur de longue date de l'atelier Path et auteur de deux livres sur FreeCAD, ont créé début 2023 la société américaine ONDSEL sous la forme d'une Public Benefit Corporation (PBC) qui pourrait se traduire par « une entreprise d'intérêt pour la société ». Malheureusement, après environ 2 ans, Brad Collette informe de l'arrêt de la société ONDSEL, faute d'avoir trouvé un marché.

La société voulait s'appuyer sur FreeCAD pour « apporter des fonctionnalités commerciales qui rendent FreeCAD plus utile aux utilisateurs commerciaux ». (Source)

Pour cela, ONDSEL a produit sa propre version de FreeCAD avec ses propres choix esthétiques et ergonomiques, et a fourni un cloud pour simplifier le travail en équipe et le partage.
À noter qu'ONDSEL indiquait soumettre ses améliorations à FreeCAD pour intégration et que son cloud était disponible sous forme de module dans FreeCAD. Ces améliorations se retrouvent dans cette version 1.0 de FreeCAD, notamment le nouvel outil intégré d'assemblage ainsi que les très nombreuses nouvelles fonctionnalités de l'atelier Sketcher.

La société ONDSEL avait détaillé sa relation avec le projet FreeCAD indiquant notamment leur mode de collaboration. Ils avaient également un blog en anglais intéressant, où ils abordent plusieurs thématiques, notamment sur l'évolution de CATIA ou bien la liste des nouveautés agrémentée de nombreuses animations.

Dans l'annonce de cet arrêt, Brad Collette revient également sur ce qu'ils ont apporté au projet FreeCAD. Tout ce qu'ils ont développé était en open source et déjà intégré pour la plupart à FreeCAD. Les fondateurs d'ONDSEL continueront de contribuer au projet directement.

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC1 du 6 novembre 2024 (en anglais).

Nous sommes très heureux de partager la première version candidate de la très attendue GIMP 3.0 ! Nous avons travaillé dur depuis notre dernière mise à jour de développement pour la préparer, et nous avons hâte que tout le monde puisse enfin voir le résultat.

Nouvel écran de démarrage de la version candidate, par Sevenix (CC by-sa 4.0) - GIMP 3.0 RC1

Alors, qu’est-ce qu’une « version candidate » (release candidate, RC, en anglais) exactement ? Une version candidate est quelque chose qui pourrait être prêt à être GIMP 3.0, mais nous voulons que la communauté la plus large la teste en premier et rapporte les problèmes qu’elle trouve. Si les retours des utilisateurs ne révèlent que des bugs mineurs et faciles à corriger, nous résoudrons ces problèmes et publierons le résultat sous la forme de GIMP 3.0. Cependant, nous espérons et nous nous attendons à ce qu’un public beaucoup plus large essaie la 3.0 RC1 — y compris de nombreuses personnes qui n’ont utilisé que la 2.10 jusqu’à présent. Si des bugs et des régressions importants sont découverts et nécessitent des modifications de code substantielles, nous devrons peut-être publier une deuxième version candidate pour des tests plus approfondis.

Sommaire

• Nouveaux graphismes
  • Icônes de Wilber
  • Écran de démarrage (Splash Screen)
  • Améliorations du thème d’icônes Legacy
• Invasion de l’espace colorimétrique
• Finalisation de l’API publique
• Mises à jour de l’édition non destructive
• Interface utilisateur
• Greffons
  • BMP
  • TIFF
• GEGL et babl
• Statistiques de sortie
• Modifications futures du processus de publication
• Autour de GIMP
  • Miroirs de téléchargement
  • Modifications de l’infrastructure
  • Accord d’hébergement fiscal de la Fondation GNOME
  • Traductions
• Télécharger GIMP 3.0 RC1
• Et ensuite ?

Nouveaux graphismes

Icônes de Wilber

Le logo actuel de Wilber a été créé par Jakub Steiner pour GIMP 2.6 en 2008 ! Bien qu’il s’agisse toujours d’un logo fantastique, les tendances en matière de design ont quelque peu changé au cours des seize dernières années et l’apparence plus détaillée de Wilber détonne sur les ordinateurs de bureau modernes.

C’est pourquoi, en collaboration avec d’autres contributeurs, Aryeom a développé notre nouveau logo pour GIMP 3.0 !

Nouvelle icône de Wilber, par Aryeom (CC by-sa 4.0)

Si vous souhaitez en savoir plus sur les choix de conception, d’utilisation et les variantes de conception, veuillez consulter notre guide du logo. Nous avons également documenté l’histoire du logo Wilber.

Écran de démarrage (Splash Screen)

Notre magnifique nouvel écran d’accueil (présenté en haut de cet article) a été créé par le contributeur et artiste de longue date Sevenix ! Vous pouvez voir plus de ses réalisations sur sa page d’art personnelle.

À l’avenir, nous prévoyons de changer plus souvent l’image de démarrage pour mettre en valeur toutes sortes d’œuvres créées avec GIMP (photographie, illustration, design…).
À ce sujet, nous avons aussi créé une page d’archive des écrans de démarrage pour garder en mémoire les œuvres présentes et passées contribuées par des artistes au projet.

Améliorations du thème d’icônes Legacy

L’une des principales améliorations apportées par le portage GTK3 est que les icônes vectorielles de l’interface utilisateur s’adaptent désormais plus proprement à vos préférences. Cependant, notre thème d’icônes Legacy était principalement constitué d’images raster (PNG), il ne pouvait donc pas tirer parti du système de mise à l’échelle de GTK3. Le contributeur Denis Rangelov a relevé le défi de taille de recréer les icônes d’outils Legacy en SVG. Désormais, les deux thèmes d’icônes de GIMP sont superbes sur les écrans HiDPI !

Icônes d’outils du thème Legacy Icon à l’échelle par Denis Rangelov (CC by-sa 4.0)

Le travail n’est pas terminé, car de nombreuses icônes ne sont toujours pas adaptatives et certaines icônes sont toujours manquantes. Denis a exprimé son intérêt à continuer d’améliorer le thème d’icônes Legacy, nous espérons donc le renommer Classic lorsque ce projet sera terminé, pour montrer qu’il est désormais bien maintenu.

Invasion de l’espace colorimétrique

L’un des changements clés de la version 2.99.18 a été l’amélioration massive de la gestion des couleurs dans GIMP. Comme ce travail n’était pas entièrement terminé dans la version 2.99.18, il a constitué un obstacle majeur à la sortie de la version 3.0 RC1.

Depuis cette version, nous avons trouvé et corrigé un certain nombre de bugs et de zones manquantes qui devaient être compatibles avec l’espace colorimétrique. Nous avons également examiné les rapports de l’experte en couleurs Elle Stone pour nous assurer que les valeurs de couleur affichées par GIMP sont aussi précises que possible. En même temps, il est très important de garantir que les fichiers de projet XCF créés dans GIMP 2.10 et avant s’afficheront de la même manière lorsqu’ils sont ouverts dans 3.0. Par exemple, l’un des premiers logos Google a été créé dans GIMP — et si vous ouvrez le fichier de projet XCF d’origine dans GIMP 3.0 RC1, il apparaît toujours de la même manière qu’à sa création en 1998 !
Par conséquent, nous avons examiné en profondeur les différents modes de calque pour garantir que l’engagement en matière de compatibilité soit conservé pour cette version.

L’invasion de l’espace colorimétrique est un projet de longue haleine, qui se poursuivra après la sortie de GIMP 3.0.

Finalisation de l’API publique

Une autre tâche qui devait être terminée avant la sortie de la version 3.0 est de finaliser l’API publique. Depuis notre dernier article, nous avons terminé les changements majeurs restants — le remplacement de toutes les instances de nos structures de couleurs personnalisées GimpRGB par la GeglColor mieux gérée en termes de couleurs et l’amélioration de nos formats de tableau afin que le nombre d’éléments n’ait pas à être spécifié séparément. Ce travail a été un long processus de la part de Jehan et Lloyd Konneker, avec beaucoup de tests de bon fonctionnement et de retours de la part d'Anders Jonsson.

En outre, un certain nombre de fonctions ont été ajoutées, renommées ou supprimées de l’API publique par rapport à la version 2.10. Par exemple, un ancien patch de Massimo Valentini ajoute gimp-context-get-emulate-brush-dynamics et gimp-context-set-emulate-brush-dynamics, qui permettent aux développeurs de scripts et de greffons d’utiliser le paramètre Émuler la dynamique du pinceau lors de la peinture. D’autre part, les différentes fonctions gauss ont toutes été regroupées en une seule fonction, plug-in-gauss. Bien que ce changement nécessite quelques mises à jour dans les scripts existants, les développeurs ont désormais un contrôle plus direct sur l’effet de flou gaussien plutôt que de s’appuyer sur des valeurs prédéfinies cachées.

L’API étant désormais stable, les développeurs de greffons et de scripts peuvent commencer à porter leurs scripts 2.10 basés sur cette version. Vous pouvez trouver la documentation initiale de l’API sur notre site de développement. Nous avons l’intention d’ajouter davantage de tutoriels et de guides de portage sur le site pendant la phase de publication. Nous vous encourageons également à consulter les greffons Script-fu et Python dans notre référentiel pour voir des exemples fonctionnels de la nouvelle API.

Mises à jour de l’édition non destructive

Depuis notre dernière mise à jour, nous avons continué à apporter des améliorations et des corrections de bugs à notre code de filtre non destructif. Bon nombre de ces problèmes ont été signalés par Sam Lester lors du développement et des tests de ses filtres GEGL tiers.

Bien que les filtres non destructifs aient été un ajout très populaire à GIMP 3.0, certains des premiers utilisateurs ont demandé que nous fournissions un moyen de revenir au flux de travail destructif d’origine. Par conséquent, nous avons ajouté une case à cocher facultative « Fusionner les filtres » au bas des filtres NDE. Si cette case est cochée, le filtre sera immédiatement fusionné après sa validation. Notez que les filtres ne peuvent pas être appliqués de manière destructive sur des groupes de calques — dans ces cas, l’option de fusion des filtres n’est pas disponible.

Exemple de filtre avec la case à cocher « Merge Filter » (Fusionner les filtres) - GIMP 3.0 RC1

Dans le même ordre d’idées, Jehan a également implémenté le stockage de la version des filtres dans les fichiers de projet XCF de GIMP. Cela nous permettra de mettre à jour les filtres à l’avenir sans affecter l’apparence des anciens fichiers de projet lorsqu’ils sont ouverts. Des travaux supplémentaires seront nécessaires dans GEGL pour implémenter complètement cette fonctionnalité, mais cela peut être fait après la version 3.0 sans affecter les fichiers de projets existants.

Interface utilisateur

GIMP 3.0 RC1 contient plusieurs mises à jour de l’interface utilisateur. Par exemple, davantage d’aspects du GUI peuvent désormais tirer parti des fonctionnalités de sélection multiple implémentées par Jehan dans les versions antérieures de 2.99.

Nous avons également restauré la possibilité d’utiliser la molette de défilement de la souris pour parcourir les différents onglets de dialogue ancrables. Cette fonctionnalité existait dans GTK2 mais supprimée dans GTK3. À la demande d’un utilisateur, nous avons réimplémenté cette fonctionnalité dans GIMP lui-même sur la base d’une implémentation similaire dans geany.

Au cours du développement, nous avons reçu un rapport indiquant que le défilement des crédits dans notre boîte de dialogue À Propos pouvait provoquer une gêne en raison de son mouvement. Par conséquent, nous avons ajouté un code pour vérifier le paramètre « Animation réduite » de votre système d’exploitation et désactiver ces animations dans GIMP selon vos paramètres de préférence.

Greffons

Comme nous sommes en période de gel des fonctionnalités depuis la dernière version 2.99, la plupart des modifications apportées aux greffons ont été des mises à jour d’API et des corrections de bugs (certaines d’entre elles pour des problèmes qui étaient assez anciens). Cependant, quelques améliorations plus petites ont été implémentées.

BMP

Le format BMP prend désormais en charge les images 64 bits par pixel. Le nouveau contributeur Rupert Weber nous a aidé à ajouter la prise en charge de l’importation correcte de ce format BMP. Il a également soumis des correctifs avec plus de corrections pour notre greffon BMP et notre pipeline de test.

TIFF

Depuis GIMP 2.99.16, nous pouvons importer des fichiers TIFF avec des calques au format Photoshop. Cependant, le programme Alias/Autodesk Sketchbook a créé sa propre norme pour enregistrer les calques, ce qui n’était pas compatible. Comme cela a été signalé comme un bug dans notre outil de suivi des problèmes, nous avons également ajouté la prise en charge du chargement de calques à partir de fichiers TIFF enregistrés au format Sketchbook.

GEGL et babl

GEGL et babl ont tous deux connu un certain nombre de mises à jour depuis leurs dernières versions en février.

GEGL 0.4.50 introduit plusieurs nouveaux filtres créés par Sam Lester.

• Lueur intérieure (Inner Glow)

• Biseau (Bevel)

• Styles GEGL (GEGL Styles)

Vous pouvez y accéder via l’outil Opérations GEGL ou en les recherchant avec le raccourci d’action de recherche /.

Øyvind Kolås a apporté un certain nombre de corrections de bugs et d’améliorations à la stabilité de GEGL. Plusieurs modifications ont également été apportées en rapport avec l’invasion de l’espace colorimétrique dans GIMP, comme l’ajout de méthodes pratiques pour obtenir et définir les GeglColor dans les modèles de couleurs HSV(A) et HSL(A), implémentées par Alx Sa. Jacob Boerema et son étudiant du Google Summer of Code (GSoC) Varun Samaga B L ont fusionné un certain nombre d’améliorations à la version OpenCL des filtres. Bien que GIMP n’active toujours pas OpenCL par défaut, leur travail nous rapproche beaucoup de la possibilité de le faire. Nous discuterons de ces améliorations dans un prochain article.

babl 0.1.110 a également reçu quelques contributions au cours de ce cycle. Jehan a implémenté de nouveaux processus de conversion entre les modèles de couleurs RVB et HSL, ce qui améliore les performances d’un certain nombre de filtres par rapport à GIMP 2.99.18. Il a également corrigé certaines parties du code qui se comportaient différemment selon que votre processeur prenait en charge SSE2 ou non. Øyvind Kolås a amélioré la précision de plusieurs sections de code lors de la conversion de valeurs à virgule flottante en valeurs entières. De plus, Lukas Oberhuber a trouvé et corrigé une fuite de mémoire et Jacob Boerema a corrigé un problème où les images avec Not a Number/NaN pouvaient provoquer un plantage.

Statistiques de sortie

Depuis GIMP 2.99.18, dans le dépôt principal de GIMP :

• 384 rapports ont été fermés comme CORRIGÉS.
• 442 demandes de fusion ont été acceptées.
• 1892 commits ont été poussés.
• 31 traductions ont été mises à jour : basque, biélorusse, brésilien portugais, anglais britannique, bulgare, catalan, chinois (Chine), chinois (Taïwan), danois, néerlandais, galicien, géorgien, allemand, grec, hongrois, islandais, italien, coréen, letton, norvégien nynorsk, polonais, portugais, russe, serbe, serbe (latin), slovène, espagnol, suédois, turc, ukrainien, vietnamien.

72 personnes ont contribué à des modifications ou des correctifs au code de base de GIMP 3.0.0 RC1 (l’ordre
est déterminé par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :

• 27 développeurs pour coder le code principal : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Øyvind Kolås, Cheesequake, cheesequake, Niels De Graef, Idriss Fekir, Simon Budig, lillolollo, lloyd konneker, Andre Klapper, Andrzej Hunt, Bruno, Joachim Priesner, Nils Philippsen, Alfred Wingate, Bruno Lopes, Elle Stone, Kamil Burda, Luca Bacci, Mark Sweeney, Massimo Valentini, Oleg Kapitonov, Stanislav Grinkov, megakite.
• 15 développeurs de greffons ou modules : Alx Sa, Jehan, Lloyd Konneker, bootchk, Jacob Boerema, Anders Jonsson, Nils Philippsen, Andrzej Hunt, Andre Klapper, Rupert, Bruno Lopes, Daniel Novomeský, Mark Sweeney, Stanislav Grinkov, lillolollo .
• 42 traducteurs : Martin, Yuri Chornoivan, Luming Zh, Rodrigo Lledó, Kolbjørn Stuestøl, Ekaterine Papava, Cheng-Chia Tseng, Sabri Ünal, Marco Ciampa, Tim Sabsch, Jordi Mas, Alexander Shopov, Anders Jonsson, Alan Mortensen, Asier Sarasua Garmendia, Sveinn í Felli, Andi Chandler, Balázs Úr, dimspingos, Juliano de Souza Camargo, Ngọc Quân Trần, Vasil Pupkin, Alexandre Prokoudine, Bruce Cowan, Jürgen Benvenuti, Nathan Follens, Милош Поповић, Balázs Meskó, Christian Kirbach, Daniel, Emin Tufan Cetin, Fran Dieguez, Guntupalli Karunakar, Hugo Carvalho, Jehan, Philipp Kiemle, Piotr Drąg, Robin Mehdee, Rūdolfs Mazurs, Seong-ho Cho, Víttor Paulo Vieira da Costa, Ayesha Akhtar.
• 7 créateurs de ressources (icônes, thèmes, curseurs, écran de démarrage, métadonnées… même si une bonne partie d’entre eux ont été déplacés vers le référentiel gimp-data) : Alx Sa, Jehan, Bruno Lopes, Anders Jonsson, Jacob Boerema, bootchk, nb1 .
• 10 contributeurs à la documentation : Jehan, Bruno, Lloyd Konneker, Alx Sa, Bruno Lopes, Anders Jonsson, bootchk, Lukas Oberhuber, Andre Klapper, Jacob Boerema.
• 11 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno Lopes, Jehan, bootchk, Alx Sa, Lloyd Konneker, Jacob Boerema, Niels De Graef, Alfred Wingate, Lukas Oberhuber, Michael Schumacher, Anders Jonsson.

Contributions sur d’autres dépôts dans GIMPverse  :

• babl 0.1.110 est composé de 22 commits par 7 contributeurs : Øyvind Kolås, Jehan, Bruno Lopes, Anders Jonsson, Biswapriyo Nath, Jacob Boerema, Lukas Oberhuber.
• GEGL 0.4.50 est composé de 204 commits par 33 contributeurs : Øyvind Kolås, Sam Lester, Martin, Varun Samaga B L, Yuri Chornoivan, Luming Zh, Rodrigo Lledó, Jehan, Jordi Mas, Anders Jonsson, Kolbjørn Stuestøl, Marco Ciampa, Sabri Ünal, Bruno Lopes, Alan Mortensen, Asier Sarasua Garmendia, Ekaterine Papava, Bruce Cowan, Lukas Oberhuber, Tim Sabsch, psykose, Alexandre Prokoudine, Alx Sa, Andi Chandler, Andre Klapper, ArtSin, Daniel Șerbănescu, Jacob Boerema, Joe Locash, Morgane Glidic, Niels De Graef, dimspingos, lillolollo.
• ctx a enregistré 616 commits depuis la sortie de la version 2.99.18 par 2 contributeurs : Øyvind Kolås, Ian Geiser.
• gimp-data (nouveau référentiel contenant des images, des splashes, des icônes et d’autres données binaires pour le logiciel) ont eu 76 commits par 7 contributeurs : Jehan, Aryeom, Bruno, Alx Sa, Denis Rangelov, Anders Jonsson, Bruno Lopes.
• La version gimp-macos-build (scripts d’empaquetage pour macOS) a eu 41 commits par 3 contributeurs : Lukas Oberhuber, Bruno Lopes, Jehan.
• La version flatpak a compté 38 commits de 4 contributeurs : Bruno Lopes, Jehan, Hubert Figuière, Will Thompson.
• Notre site Web principal a enregistré 60 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Jehan, Alx Sa, Andre Klapper, Bruno Lopes et Denis Rangelov.
• Notre site Web de développeur a enregistré 33 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Bruno Lopes, Jehan, Lloyd Konneker, Alx Sa, Lukas Oberhuber.
• Notre documentation 3.0 a enregistré 928 commits depuis la version 2.99.18 par 14 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Jordi Mas, Marco Ciampa, Anders Jonsson, Sabri Ünal, dimspingos, Alx Sa, Andi Chandler, Daniel, Nathan Follens.

N’oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, à signaler les bugs et à discuter des améliorations possibles avec nous.
Notre communauté est également profondément reconnaissante envers les guerriers d’Internet qui gèrent nos divers canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Note : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via le script git, des erreurs peuvent se glisser dans ces statistiques. N’hésitez pas à nous dire si nous avons oublié ou mal classé des contributeurs ou des contributions.

Modifications futures du processus de publication

Nous sommes bien conscients que le chemin vers GIMP 3.0 a été long et que les utilisateurs de GIMP 2.10 n’ont pas eu accès à toutes les nouvelles fonctionnalités sur lesquelles nous avons travaillé au fil des ans. À l’avenir, nous restructurerons notre processus de développement pour réduire le temps entre les versions. Comme mentionné brièvement dans notre feuille de route 3.0, nous voulons nous concentrer sur des versions plus petites et axées sur les fonctionnalités. Cela signifie que nous visons la sortie de GIMP 3.2 dans l’année qui suit la sortie finale de 3.0, plutôt qu’en 2050 comme on le dit souvent en plaisantant ! Des micro-versions avec des corrections de bugs peuvent survenir entre-temps.

Des versions plus petites avec quelques « grosses » fonctionnalités nous permettront également de tester plus en profondeur chaque changement, améliorant encore la stabilité de chaque version. Au cours du processus de développement de la version 3.0, des développeurs comme Jacob Boerema, Lloyd Konneker, Bruno Lopes et Jehan ont créé et amélioré nos processus de tests automatisés pour détecter et identifier les bugs plus tôt. Nous parlerons plus en détail de ces améliorations dans de futurs articles.

Autour de GIMP

Miroirs de téléchargement

Depuis notre dernière actualité, 8 nouveaux miroirs ont été proposés à GIMP par :

• Sahil Dhiman, Inde
• FCIX, en République Dominicaine, en Australie et 2 aux USA.
• Taiwan Digital Streaming Co., Taïwan
• OSSPlanet, Taïwan
• Shrirang Kahale, Inde

Cela nous amène à un total de 56 miroirs du monde entier !

Carte des miroirs GIMP dans le monde, générée à partir de MirrorBits

Les miroirs sont importants, car ils aident le projet en répartissant la charge des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous faisons en sorte que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.

Modifications de l’infrastructure

Bruno Lopes a véritablement pris des initiatives pour améliorer notre processus de construction et d’empaquetage sur plusieurs plateformes.

Au cours de l’été, il a créé une version expérimentale d’AppImage (comme détaillé dans un article d’actualité précédent). Si vous souhaitez l’améliorer davantage et, espérons-le, le rendre disponible en téléchargement standard, veuillez nous contacter ! Bruno a également créé des scripts de construction flatpak pour rendre le processus de création de votre propre flatpak GIMP beaucoup plus facile.

Beaucoup de travail a été fait pour améliorer notre présence sur le Microsoft Store pour la version 3.0. Notre application GIMP 2.10 n’était pas entièrement intégrée à la plateforme du store en raison de certaines limitations — il s’agit en réalité simplement d’un wrapper pour notre installateur GIMP existant. Par conséquent, elle ne se mettait pas automatiquement à jour pour les utilisateurs et il n’était pas possible d’automatiser les installations avec des outils comme Microsoft Intune. Grâce aux nombreux efforts de Bruno, nous aurons une nouvelle application GIMP dans le Microsoft Store qui résout ces problèmes (et bien d’autres) pour la version finale de GIMP 3.0. À partir de maintenant, nous disposons également d’une version séparée de GIMP (Preview) qui vous permet d’installer des versions de développement de manière similaire au flatpak Bêta sur Linux. Vous pouvez l’essayer sur ce lien vers le Microsoft Store pour GIMP (Preview).

(Pour des raisons techniques et de maintenance décrites ici, les binaires 32 bits ne seront pas disponibles dans les nouveaux paquets MSIX de GIMP, ce qui supprime malheureusement la prise en charge du greffon TWAIN hérité dans les paquets x64 et arm64 utilisés pour la numérisation rapide. Si vous dépendez de ceux-ci, le programme d’installation .exe prend toujours en charge les processeurs 32 bits. Cependant, la prise en charge de cette architecture devrait être abandonnée à l’avenir)

En outre, l’installateur Windows standard a été mis à jour pour une conception plus moderne. Il vous permet également d’installer des paquets de langue individuels et de démarrer GIMP immédiatement après la fin de l’installation. Pour les plus férus de technologie, les scripts de build Windows ont également été portés pour utiliser PowerShell, et les scripts de build croisés peuvent désormais s’exécuter localement.

En raison des changements et des mises à jour de notre infrastructure de création de logiciels, nous avons dû augmenter la configuration minimale requise pour le système d’exploitation MacOS à Big Sur (MacOS 11).

Accord d’hébergement fiscal de la Fondation GNOME

Plus tôt cette année, la Fondation GNOME a annoncé un accord de parrainage fiscal avec GIMP. Tout cela est dû au travail acharné de Jehan pendant de nombreux mois. Nos objectifs avec cet accord sont de pouvoir proposer un financement stable pour les développeurs intéressés par un travail à long terme sur GIMP par le biais de bourses, et de fournir des moyens plus faciles pour les gens de contribuer au développement de GIMP. Ce travail est toujours en cours, nous ferons donc une annonce plus détaillée une fois que tout sera stabilisé.

Traductions

Grâce à des traducteurs bénévoles, nous disposons désormais d’une traduction de GIMP en bengali ! Si vous souhaitez traduire GIMP dans votre propre langue ou participer à une traduction existante, vous pouvez découvrir comment ici.

Télécharger GIMP 3.0 RC1

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

• Paquets Linux flatpaks pour x86 et ARM (64 bits) avec des nightly-builds permettant de suivre l’avancement des développements
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
• Paquet MSIX (aperçu GIMP) pour x86 (64 bits uniquement) et ARM (64 bits)
• Paquets macOS DMG pour le matériel Intel
• Paquets macOS DMG pour le matériel Apple Silicon

D’autres paquets réalisés par des tiers sont évidemment attendus (paquets de distributions Linux ou *BSD, etc.).

Et ensuite ?

Nous entrons maintenant dans la dernière étape de cette version majeure : les candidats à la version finale ! Bien qu’il soit toujours possible d’espérer obtenir une Release Candidate correcte du premier coup, l’expérience nous dit que cette RC1 — qui est le résultat de plus de 6 ans de travail — comportera possiblement des problèmes, des bugs, probablement des plantages désagréables. C’est là que nous avons besoin de vous tous ! Nous comptons sur tout le monde pour trouver et signaler les problèmes afin que la version 3.0.0 puisse vraiment être considérée comme stable. 🤗

Certains petits bugs peuvent être considérés comme secondaires (bien que nous acceptions toujours les rapports pour tous les bugs, même les plus petits !), car la perfection n’existe pas vraiment dans les logiciels. Il y a d’autres choses en particulier que nous voulons vraiment détecter, comme :

• toute incohérence ou problème dans l’API (elle restera stable pour toute la série v3, donc s’il y a des problèmes à trouver, c’est maintenant ; nous voulons un framework de greffon robuste) ;
• bugs lors de la lecture ou du rendu de fichiers XCF existants créés par d’anciennes versions stables de GIMP ;
• plantages ;
• régressions ;
• migration correcte de la configuration à partir des versions stables précédentes.

Nous ne donnons pas d’estimation de date pour la sortie de la version 3.0.0, tout d’abord parce que nous ne pouvons pas le savoir avec certitude, ensuite parce qu’à chaque fois que nous le faisons, les médias semblent simplement survoler chaque avertissement de notre texte et transformer nos mots en promesses indéfectibles. Sachez simplement que nous voulons également que cela se produise le plus tôt possible, c’est-à-dire lorsque nous pourrons considérer que notre logiciel est suffisamment stable.

N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, afin de donner en retour et d’accélérer le développement de GIMP. L’engagement de la communauté aide le projet à se renforcer ! 💪🥳

La dernière dépêche sur le jeu Unvanquished a été publiée ici en 2023, pour son dixième anniversaire. La dernière version annoncée ici était la version 0.53, en 2022. Alors que nous sommes à deux mois de 2025 et à quelques jours de la prochaine version 0.55, c’est l’occasion de faire un point sur ce qui s’est passé ces dernières années et d’ajouter un épisode à la série « des nouvelles de [votre jeu préféré] » et de faire suite à celui sur Xonotic.

Laisse-moi sortir de là ! — réclame la version 0.55…

Unvanquished est un jeu de stratégie en temps réel (RTS) à la première personne (FPS) où des extraterrestres évolutifs et des humains lourdement armés s’affrontent pour leur survie. Son développement, basé sur Tremulous, a commencé en 2011.

Sommaire

• Quelques nouvelles en vrac
  • Un nouveau lanceur
  • Des améliorations graphiques
  • Un explorateur de serveur minimaliste
  • Des vidéos et un compte Mastodon
• Unvanquished, ARMé et dangereux
  • De nouvelles architectures
  • Interface, jouabilité et bots
  • La danse des submodules
  • Contributions
  • Des traductions !
• La 0.55 arrive !

Quelques nouvelles en vrac

Un nouveau lanceur

En prévision de la prochaine version 0.55 qui arrive (deux « release candidates » ont déjà été publiées), le « lanceur » (aussi appelé « updater ») a été mis à jour en juillet dernier.

Le lanceur est le moyen recommandé d’installer Unvanquished : il permet une intégration optimale avec le système (possibilité de cliquer sur des liens pour lancer une partie) et propose la mise à jour du jeu quand une nouvelle version est disponible. Le lanceur sait aussi se mettre à jour et c’est ce qui a été fait en juillet.

Des améliorations graphiques

L’année dernière le projet Unvanquished avait annoncé être en recherche d’un développeur spécialisé dans les moteurs de rendus. Reaper a rejoint l’équipe et a réalisé un gros travail : débugage et finalisation des miroirs récursifs et d’autres choses. Il fait aussi progresser le moteur pour tirer partie d’OpenGL 4.6 et autre techniques avancées (« bindless textures », etc.).

Un explorateur de serveur minimaliste

Viech a publié un explorateur de serveur de jeu minimaliste qui tient dans la barre de notification (tray browser). C’est à la fois simple et pratique.

Des vidéos et un compte Mastodon

Diverses vidéo montrant les avancées du développement ont été publiées sur la chaîne Youtube d’Unvanquished, c’est l’occasion de rappeler l’existence de cette chaîne : https://www.youtube.com/@UNVofficial

Pour ceux qui préfèrent Peertube, qui permet aussi de s’abonner aux chaînes à travers Mastodon et plus globalement le Fédiverse, avec la publication de certaines parties : https://vdo.unvanquished.greboca.com/

Un compte Mastodon a été créé sur l’instance idtech.space dédiée aux technologies id Tech et projets associés (le moteur d’Unvanquished dérive d’id Tech 3) : https://idtech.space/users/UNVofficial

Ce compte Mastodon s’ajoute aux comptes X et Facebook. Le public libriste sera peut-être plus intéressé par ce compte Mastodon.

Unvanquished, ARMé et dangereux

De nouvelles architectures

La version 0.54 de Unvanquished sortie en janvier 2023 avait été la première à être jouable autrement que sur PC (x86 et x86-64), en proposant des binaires pour les processeurs ARM (sous Linux seulement pour l’instant).

Côté moteur la version 0.54 avait reçu de nombreuses optimisations pour mieux tourner sur des machines moins performances, par exemple, Certaines ressources logiciels optionnelles comme les deluxemaps ne sont plus chargées si désactivées, ceci économise non seulement le calcul, mais aussi la mémoire de la carte graphique. Les lightstyles peuvent être désactivés, ce qui peut accélérer le rendu graphique, etc. La compatibilité matérielle sera encore étendue avec la version 0.55.

À partir de la version 0.54 tous les binaires pour toutes les architectures matérielles et systèmes d’exploitation sont compilés dans des containers Docker, y compris les binaires macOS compilés dans un container Linux en utilisant Darling, Darling étant à macOS ce que Wine est à Windows. La version 0.55 sera produite de la même manière.

La version 0.55 apportera la compatibilité pour un nouveau système d’exploitation ! 🤫️

Interface, jouabilité et bots

Le nouvel écran de chargement des cartes.

L’interface avait été revue à l’occasion de la version 0.54 :

• Nouvelles icônes d’inventaire contribuées par Nanaa, Gireen et Bob Vador
  Ces icônes donnent un coup de fraîcheur, on distingue mieux les deux types de grenades et les armures ainsi que le mode de déplacement.
• L’écran de chargement des cartes affiche le nom de la carte et des auteurs (si renseigné) depuis les métadonnées. Historiquement, les artistes inscrivaient ces informations sur l’image d’illustration de la carte avec un logiciel de dessin… (!!!)
• La version 0.55 apportera des modifications d’interface réalisées par Grise.

Côté jouabilité, la version 0.54 avait corrigé le momentum négatif qui était particulièrement pénalisant. Le momentum, est généré par les Leech (Alien) ou les Drills (Humain). Il faut qu’il y ait assez de momentum pour pouvoir construire d’autres éléments.

La version 0.54 a apporté toute une série de nouveautés au niveau des bots (entités qui remplacent les joueurs afin de compléter les équipes) :

• Amélioration de l’évitement d’obstacles pour les bots.
• Les bots peuvent viser des cibles situées sur des navmesh différents.
• Certains bots n’hésiteront pas à sauter pour atteindre une cible en hauteur, d’autres se retiennent d’exécuter une attaque qui pourraient les blesser si la cible est trop proche…

Depuis quelque temps, le développement des bots suscite un regain d’intérêt. La version 0.55 ne sera pas la plus riche à ce sujet car elle apportera surtout des améliorations du moteur. Le développement de gameplay ne s’est pas ralenti mais s’est surtout focalisé sur des mods dont il faudra fusionner les avancées dans le tronc commun après la sortie de la version 0.55. Ces améliorations de gameplay sont déjà jouables sur des serveurs en ligne.

L’amélioration du comportement des bots à permis un nouveau type de jeu : Le PVE. C’est à dire que les joueurs peuvent jouer ensemble contre l’ennemi piloté par le serveur. Certaines cartes ont été créées spécifiquement pour ce type de jeu, et d’autres ont été adaptées à l’aide de layout qui étaient déjà utilisés pour créer des variantes de parties.

La version 0.54.1 n’avait pas vraiment proposé de modifications des données, il s’agissait surtout de publier des correctifs de bugs gênant du moteur. La version 0.55 viendra avec une mise à jour des données et donc avec les corrections attendues. Par exemple un bug dans la chaîne logicielle de conversion d’images avait produit des artefacts dans certaines textures, ce sera corrigé dans la version 0.55.

La danse des submodules

            _________________
           /                 \
          |         ✝         |  
          |                   |
          |      beloved      |
          |     submodule     |
          |                   |
          |    2017-12-30     |
          |     2023-04-11    |
          |                   |
          |       R.I.P.      |
          |                   |  🄵
  (,,)é   |                   |   ɘ̀(⹁⹁)  ɘ̀(⹁⹁)
////////////////////////////////////////////////

Press F to Pay Respects!

Tous ceux qui doivent traiter avec Git savent que les submodules sont très pratiques mais parfois bien ennuyeux. Un travail de fond réalisé sur les outils de production des données a permis la réintégration du dossier source unvanquished_src.dpkdir. Le générateur de code CBSE qui produit la plomberie pour la logique de jeu a été réintégré aussi. Cela rend plus facile de travailler sur des mods en évitant de devoir gérer plusieurs dépôts différents.

Contributions

Voulez-vous en savoir plus ?

Comme vous le voyez, ce cycle de développement a aussi vu de nouveaux contributeurs apporter leur concours au projet. Certaines de leurs améliorations ont déjà été publiées dans la version mineure 0.54.1, d’autres arriveront avec la version 0.55.

Récement, le développeur Slipher qui est un des développeurs Unvanquished les plus prolifiques et les plus fidèles a étendu ses activités au moteur de rendu et a rejoint la petite élite de ceux qui savent comment le moteur fonctionne. Il a corrigé entre autre le rendu de vidéo sur des surfaces et une fonctionnalité de sprites.

La liste de régressions depuis le désormais lointain ancêtre d’Unvanquished, Tremulous, est maintenant réduite à peau de chagrin.

Des traductions !

La grosse nouveauté de la version 0.54.1 publiée en décembre 2023 a été de proposer à nouveau des traductions intégrées au jeu. L’outil de traduction est gracieuseuement hébergé par Weblate.

L’interface de traduction Weblate.

Il y a longtemps, le jeu était traduit, mais suite à de très profonds changements (par exemple le remplacement total de la technologie utilisée pour faire des menus, désormais sous RmlUi), l’effort de traduction avait été interrompu.

La traduction francophone est bien avancée, mais la traduction en breton a besoin de plus de contributions. Si vous souhaitez contribuer votre langue régionale, vous êtes les bienvenus, c’est ici que cela se passe !

La 0.55 arrive !

Préparez votre souris et votre clavier, la version 0.55 arrive très bientôt.

En mai, lis ce qu'il te plaît ! Voici donc un petit panorama, forcément subjectif et parti{e,a}l, de la presse papier sortie récemment.

Les nouveautés de mai 2024 :

• GNU/Linux Magazine France n^o 269 embarque du Lua dans vos programmes ! ;
• Linux Pratique n^o 143 Utilisez Ansible pour la gestion de vos serveurs Tomcat ;
• MISC magazine n^o 133 fête les 21 ans de Scapy 🎂 ;
• Hackable n^o 54 s'attaque à votre pouvoir d'achat en vous proposant de mettre en place des communications gratuites hors réseau et longue distance avec Meshtastic ;
• Planète Linux n^o 136 utilise Yunohost pour déployer un service de streaming audio.

Les sommaires des numéros sortis depuis la précédente revue de presse

GNU/Linux Magazine numéro 269

Au sommaire de ce numéro de mai – juin 2024 :

• Mettre en place un programme de Security Champions ;
• Embarquez un peu de Lua dans vos projets C ;
• NativePHP : développez des applications desktop en PHP !
• Écrire son premier pilote pour OpenBSD ;
• Manipulons les caractères avec iconv ;
• Les « tourments de la monopile », ou le « Single-Stack Syndrome » ;
• Les codes fantastiques : C for surprenant ;
• Le temps sous Linux - 1er volet.

Linux Pratique numéro 143

Au sommaire de ce numéro de mai – juin 2024 :

• Sauvegardez les données de vos appareils mobiles ;
• Mise à jour d’une instance PostgreSQL ;
• Automatiser l'installation et la sécurisation de systèmes GNU/Linux grâce aux preseeds ;
• Maîtriser le contrôle d'accès en cybersécurité ;
• Gouvernance et RGPD : référencez vos traitements ;
• Haute disponibilité avec HAProxy et Heartbeat ;
• Gérer son parc Tomcat avec Ansible.

MISC Magazine numéro 133

Au sommaire de ce numéro de mai – juin 2024 :

• Automatiser la création d’un laboratoire d’entraînement Active Directory ;
• JS Hoisting : exploiter des XSS « inexploitables » ;
• Exploitation d’un système industriel via le protocole OPC UA ;
• DenyLocker : utilisation d’AppLocker en liste de blocage, construction et validation automatique des règles ;
• Protégez vos ressources AWS en identifiant les accès IMDS ;
• Il y a comme un I(a)C ;
• Scapy a 21 ans !

Hackable numéro 54

Au sommaire de ce numéro de mai – juin 2024 :

• IAoT avec M5Stack ;
• i2c-tiny-usb : un bus i2c facilement accessible pour votre PC ;
• Lever et coucher de soleil sur ESP32 ;
• Meshtastic : communication longue distance, hors réseaux et gratuite ;
• Milk-V Duo : un minuscule SBC RISC-V à 8 € ;
• Carte à puce et microcontrôleur ;
• Sharp PC-G850V : le dernier des ordinateurs de poche.

Planète Linux numéro 136

Au sommaire de ce numéro d'avril — mai 2024 :

• Actualités ;
• Distribution : Br OS 23.10, une Brésilienne au désign sophistiqué ;
• Distribution : BlendOS v3 La distribution ultime ou l'usine à gaz absolue ?
• Distribution : Fedora La dernière version apporte une vitesse accrue ;
• Plasma 6 est sorti. Une version majeure de l'ex-KDE ;
• 5 jeux pour se divertir ;
• Auto-hébergement avec YunoHost ;
• Comparatif streaming audio personnel ;
• Sysadmin : Comment est gérée la priorité du CPU ?
• Sysadmin : Sécuriser ses recherches avec DNS-over-TLS ;
• Comprendre le fonctionnement du réseau ;
• Comparatif : quel logiciel pour surveiller son système Linux ?
• Gérez votre collection de photos avec Fotocx ;
• Réaliser un panoramique avec Hugin ;
• 16 logiciels nouveaux ou mis à jour à découvrir dès maintenant ;
• 6 astuces pour mieux utiliser vos logiciels et distributions ;
• Qui veut la peau de X86 (tribune) ?

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.10.38 du 3 mai 2024 (en anglais).

Cette (peut-être dernière) version stable de GIMP 2 apporte des rétroportages très demandés de GTK3, y compris une prise en charge améliorée des tablettes sous Windows. Un certain nombre de corrections de bugs et d’améliorations mineures sont également incluses dans cette version.

Sommaire

• • Nouvelles fonctionnalités et améliorations
    • Prise en charge améliorée des tablettes sous Windows
    • Rétroportages d’autres fonctionnalités de GTK3
  • Corrections de bogues
    • Crashs récents
    • Autres correctifs
  • Statistiques de sortie
  • Nouvelles de l’équipe et processus de publication
  • Autour de GIMP
    • Des nouvelles des miroirs
    • Sponsors d’infrastructure et de matériel
  • Télécharger GIMP 2.10.38
  • Et ensuite ?

Cette actualité répertorie les changements les plus notables et visibles. En particulier, nous ne répertorions pas toutes les corrections de bogues ou améliorations mineures. Pour obtenir une liste plus complète des modifications, vous devez vous référer au fichier NEWS ou consulter l'historique des commits.

Nouvelles fonctionnalités et améliorations

Prise en charge améliorée des tablettes sous Windows

Avant cette version, GIMP prenait uniquement en charge la connexion de tablettes sous Windows via les pilotes WinTab plutôt que les nouveaux pilotes Windows Ink. Pour cette raison, nous avons reçu un certain nombre de rapports concernant des tablettes présentant des problèmes avec des boutons qui ne répondent pas, une sensibilité à la pression incorrecte, un mouvement de brosse retardé et des changements de position à mi-course.

Ces problèmes étaient dus à une limitation de GTK2, car la prise en charge de Windows Ink a été implémentée dans GTK3 par Luca Bacci, contributeur de longue date. Pour cette version, Luca a eu la gentillesse de rétroporter ce support vers GTK2. Vous pouvez désormais basculer entre les pilotes WinTab et Windows Ink (s’ils sont pris en charge par votre ordinateur) dans la boîte de dialogue Préférences sous les paramètres du périphérique d’entrée.

Windows Pointer Input API peut être changé maintenant - GIMP 2.10.38

Rétroportages d’autres fonctionnalités de GTK3

Luca a également contribué à plusieurs autres fonctionnalités portées de GTK3 à GTK2. Certaines des améliorations rétroportées incluent la mise à jour de la taille de la boîte de dialogue d’impression afin que les boutons ne soient pas coupés, la résolution de problèmes avec les boîtes de dialogue contextuelles apparaissant derrière les précédentes et plusieurs correctifs concernant la saisie au clavier.

Ces améliorations concernent principalement Windows et sont déjà incluses dans la version de développement 2.99. Cependant, nous sommes très heureux que ces améliorations de la qualité de vie soient désormais disponibles dans cette version stable de GIMP 2.10 !

Corrections de bogues

Crashs récents

Deux crashs fréquemment signalés ont été corrigés. Un changement dans GLib 2.80 a exposé un bogue dans notre processus de fermeture et provoqué un crash à la sortie. Luca Bacci a une fois de plus conçu un correctif pour la version 2.10.38 et la prochaine version candidate 3.0. Un autre crash que certains utilisateurs rencontraient lors de très petites sélections a également été corrigé.

Autres correctifs

Un certain nombre d’autres petits bugs ont été corrigés dans cette version. Parmi eux :

• Les PNG indexés avec transparence sont désormais exportés avec les bonnes couleurs
• Anders Jonsson a corrigé les plages d’entrée de plusieurs filtres tels que Waves et Distort
• Le champ de personnalisation de la barre de titre prend désormais en charge les caractères UTF-8
• Les commentaires d’images existants ne « fuient » plus dans les images nouvellement créées

Statistiques de sortie

Depuis GIMP 2.10.36 :

• 16 rapports ont été clos comme CORRIGÉS dans la version 2.10.38
• 9 demandes de fusion ont été exécutées
• 81 commits ont été poussés
• 1 nouvelle traduction a été ajoutée : kabyle
• 16 traductions ont été mises à jour : biélorusse, portugais brésilien, anglais britannique, danois, géorgien, allemand, grec, hongrois, islandais, italien, norvégien nynorsk, slovène, espagnol, suédois, turc, espagnol

25 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.10.36 (l’ordre est déterminé par le nombre de commits) :

• 7 développeurs : Alx Sa, Jehan, Luca Bacci, Jacob Boerema, Lukas Oberhuber, lillolollo, Øyvind Kolås
• 19 traducteurs : Kolbjørn Stuestøl, Sabri Ünal, Bruce Cowan, Yuri Chornoivan, Vasil Pupkin, Anders Jonsson, Rodrigo Lledó, Jürgen Benvenuti, Sveinn í Felli, Andi Chandler, Juliano de Souza Camargo, Ekaterine Papava, Balázs Úr, Martin, Philipp Kiemle, Alan Mortensen, Dimitris Spingos, Marco Ciampa, Yacine Bouklif

Contributions sur d’autres dépôts du GIMPverse (l’ordre est déterminé par le nombre de commits) :

• La branche gimp-2-10 de gimp-macos-build (scripts de build macOS) a eu 30 commits depuis la version 2.10.36 par 2 contributeurs : Lukas Oberhuber, Bruno Lopes.
• La version flatpak est composée de 11 commits par 3 contributeurs : Jehan, Hubert Figuière et Bruno Lopes.
• Notre site Web principal a eu 42 commits depuis la sortie du 2.99.18 par 4 contributeurs : Jehan, Alx Sa, Andre Klapper et Lukas Oberhuber.
• Notre site Web du développeur a enregistré 34 commits depuis la version 2.99.18 par 6 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Alpesh Jamgade et Robin Swift.
• Notre documentation 2.10 a eu 35 commits depuis la version 2.10.36 par 8 contributeurs : Alan Mortensen, Anders Jonsson, Rodrigo Lledó, Jacob Boerema, Kolbjørn Stuestøl, Marco Ciampa, Andi Chandler et Vittor Paulo Vieira da Costa.

N’oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, rapportent des bugs et discutent avec nous d’éventuelles améliorations. Notre communauté est également profondément reconnaissante envers les guerriers d’Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de composants dans GIMP et son univers, et de la manière dont nous obtenons des statistiques via les scripts git, des erreurs peuvent se glisser dans ces statistiques. N’hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

Nouvelles de l’équipe et processus de publication

Idriss, contributeur du GSoC 2023, a récemment obtenu un accès « développeur » sur le référentiel source principal, pour le travail formidable qu’il a continué depuis lors.

Ville Pätsi, contributeur de très longue date (plus de 20 ans !), sur divers sujets (design, thématisation et plus) a obtenu l’accès « reporter » à Gitlab pour aider au tri et à l’organisation directement dans le tracker.

Autour de GIMP

Des nouvelles des miroirs

Depuis nos dernières nouvelles, 3 nouveaux miroirs accueillent GIMP :

• Clarkson Open Source Institute, États-Unis
• FCIX, Suisse
• Tomás Leite de Castro, Portugal

Cela nous amène à un total de 49 miroirs répartis dans le monde.

Les miroirs sont importants, car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tous aient un accès rapide au téléchargement de GIMP.

Sponsors d’infrastructure et de matériel

Nous avons amélioré la page sponsor avec 2 sections :

• "Infrastructure Sponsors" répertorie les sponsors qui aident GIMP au niveau de l’infrastructure :

  • CircleCI et MacStadium rendent possible notre plateforme d’intégration continue macOS.
  • Arm Ltd. sponsorise et administre plusieurs exécuteurs « Aarch64 » sur Windows pour notre version ARM 64 bits pour Windows ; et Microsoft avait offert des frais uniques pour leur Microsoft Store.

• "Hardware Sponsors" répertorie les sponsors qui ont fait don de matériel aux contributeurs pour les aider dans leur travail de développement :

  • Arm Ltd. a récemment fait don d’un kit de développement Windows 2023 pour prendre en charge notre récent support Aarch64/Windows.
  • Purism a fait don d’un Librem Mini en 2021.

Télécharger GIMP 2.10.38

Vous trouverez toutes nos builds officielles sur le site officiel de GIMP (gimp.org) :

• Flatpaks Linux pour x86 et ARM (64 bits)
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
• Paquets macOS DMG pour le matériel Intel
• Paquets macOS DMG pour le matériel Apple Silicon

D’autres paquets réalisés par des tiers devraient évidemment suivre (paquets des distributions Linux ou *BSD, etc.).

Et ensuite ?

C’est clairement l’une des plus petites versions de la série 2.10, et elle pourrait être notre dernière. Nous verrons, même si nous savons aussi que certaines personnes restent bloquées plus longtemps que d’autres sur des séries plus anciennes (en particulier lors de l’utilisation des distributions Long Term Support (LTS) de systèmes d’exploitation de logiciels libres), si nous pourrions donc faire (si nous pensons que c’est nécessaire), une version 2.10.40 avec des corrections de bogues juste avant ou juste après la sortie de GIMP 3.0.0, en guise de conclusion.

Dans tous les cas, nous arrêtons désormais le rétroportage des fonctionnalités de la série 2.10. Ces améliorations de la prise en charge des tablettes graphiques pour Windows sont suffisamment importantes pour qu’elles aient dû être intégrées ; mais à partir de maintenant, nous voulons nous concentrer uniquement sur la sortie de GIMP 3.0.0.

Maintenant, vous vous demandez peut-être quand cela se produira-t-il ? Très bientôt ! Nous sommes sur le dernier sprint vers la release candidate. Cela inclut de nombreuses corrections de bugs, mais également des modifications de l’API en cours. Nous vous tiendrons au courant !

N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, comme moyen de redonner et accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳

Face aux risques que fait peser GitHub sur le monde des logiciels libres suite à son rachat par Microsoft en 2018, une alternative semble avoir percé. Cette dépêche propose un tour d'horizon des problèmes posés par GitHub et expose comment Codeberg pourrait y répondre.

Sommaire

• • Les points forts de Codeberg
  • La problématique du tout GitHub
  • Des alternatives possibles
  • Pour vous faire venir sur Codeberg
    • Premières impressions
    • Fonctionnalités avancées
  • Projets ayant migré ou ayant un miroir sur Codeberg
  • Comment migrer vers Codeberg ?
  • Conclusion
  • Sources / Liens
    • Controverse GitHub
    • Forges diverses
    • Codeberg

Les points forts de Codeberg

L'association Codeberg e.V. ¹ et son projet Codeberg.org ont été fondés en janvier 2019, suite au rachat par Microsoft de GitHub. En plus d'un statut associatif à but non lucratif, ce qui limite les risques de disparition du jour au lendemain, Codeberg est basé en Europe (à Berlin), ce qui est un plus pour nos données personnelles.

Son logo représente un sommet enneigé sur fond de ciel bleu. En effet, en Allemand, der Berg veut dire la montagne et on pourrait donc traduire Codeberg par une « montagne de code ». Et effectivement, la communauté compte fin avril 2024 plus de 102 000 utilisateurs et plus de 129 000 projets y sont hébergés. L'association qui dirige le projet compte plus de 400 membres. Le financement s'effectue par les dons (déductible des impôts en Allemagne) et/ou contributions aux projets sous-jacents à la forge.

La forge est basée sur Forgejo, logiciel libre sous licence MIT, dont le nom vient de l'Esperanto forĝejo, ce qui est cohérent avec l'attention portée à la langue de l'utilisateur et aux problèmes de traduction (service Weblate). Comme avec GitLab, la licence libre implique qu'un projet peut posséder sa propre instance s'il le souhaite. On notera que Forgejo est un fork de Gitea, lui-même fork de Gogs, et est donc écrit en langage Go, langage sous licence BSD avec un brevet. Le projet Forgejo, évidemment hébergé sur Codeberg, est très actif avec plus de 900 Pull Requests acceptées depuis un an.

La problématique du tout GitHub

GitHub, lancé en 2008, est devenu la plus grosse plateforme d'hébergement de codes sources, utilisée par un grand nombre de projets majeurs du monde du libre (Firefox, Matrix, Yunohost…). Ce qui par effet d'attraction — et de réseau centralisant, contraire au choix de git décentralisé par nature — conduit souvent à faire de Github un choix par défaut, facilitant les interactions avec les autres projets et permettant d'accéder à une large base de contributeurs potentiels. Quand on cite une URL GitHub dans un réseau social, on peut d'ailleurs voir apparaître ce genre de message :

Contribute to Someone/my_project development by creating an account on GitHub.

Cependant, si ce service fourni par Microsoft est actuellement encore gratuit, il est soumis à son bon-vouloir, avec le risque de voir se répéter l'épisode SourceForge (publicités trompeuses, installateurs modifiés, usurpation d'identité de projets partis ailleurs, etc.).

Par ailleurs, derrière une communication favorable à l'open source, le code de la forge GitHub est volontairement fermé. Vous ne pouvez donc pas avoir votre propre instance de GitHub. En outre, cela laisse un flou sur l'exploitation de nos données (au sens large, le code lui-même et nos données personnelles, l'hébergement étant délégué). Avec l'arrivée du projet Copilot, il est cependant certain que nos codes servent à alimenter un outil d'IA, permettant à Microsoft de monétiser des suggestions de code en faisant fi des questions de licence. Une partie d'un code sous licence libre pourrait potentiellement se retrouver injectée dans un projet avec une licence incompatible et de surcroît sans citation de l'auteur.

Des alternatives possibles

On pense tout d'abord à GitLab, logiciel lancé en 2011, qui permet d'avoir sa propre instance serveur pour maîtriser l'ensemble (client et serveur sont libres). Parmi les grands projets libres, on trouve en particulier GNOME et Debian qui utilisent leur propre instance GitLab CE (Community Edition), logiciel sous licence MIT. Mais il faut nuancer : la forge GitLab.com utilise GitLab EE (Enterprise Edition) qui est propriétaire et propose des fonctionnalités supplémentaires. GitLab suit donc un modèle dit open core. GitLab compterait plus de 30 millions d'utilisateurs inscrits et l'entreprise GitLab Inc., lancée en 2014, génère plusieurs centaines de millions de dollars de revenus. On notera enfin qu'en 2018, le site migre de Microsoft Azure à Google Cloud Platform (USA), ce qui a posé des problèmes d'accès dans certains pays.

Autres projets de forges libres plus modestes :

• Codingteam.net (une initiative française, service clôturé en 2019).
• SourceHut http://sr.ht (et https://sourcehut.org/), initié par Drew DeVault.
• Disroot basé sur Forgejo comme Codeberg, mais il ne semble pas avoir attiré de projets d'envergure (le portail, sorte de Framasoft néerlandais, est néanmoins à recommander).
• Chez un Chaton (GitLab ou Gitea pour la plupart).
• L'auto-hébergement : chez-vous, dans un fablab, en datacenter sur serveur dédié…

Pour vous faire venir sur Codeberg

Premières impressions

La page principale est accueillante et annonce que Codeberg.org ne vous piste pas et n'utilise pas de cookies tiers. Les statistiques actuelles sont affichées : nombre de projets, d'utilisateurs et de membres de l'association. Chose agréable, vous avez la possibilité de choisir le français parmi les nombreuses langues proposées pour l'interface. Petite icône qui attire l'attention : l'activité de chaque dépôt peut être suivie grâce à un flux RSS. Sinon, l'organisation générale est très semblable à celle de GitHub ou GitLab et la prise en main de Codeberg se fait donc sans effort.

Fonctionnalités avancées

• Codeberg pages : permet de disposer d'un site web statique pour le projet
• Forgejo actions : pour dérouler automatiquement les actions nécessaires à l'intégration continue (CI/CD)
• Weblate : pour gérer les traductions de votre projet. On peut d'ailleurs y constater que parmi les traductions de Forgejo, le Français est dans le peloton de tête.

Projets ayant migré ou ayant un miroir sur Codeberg

Un certain nombre de projets importants utilisent désormais Codeberg, ce qui est à la fois un gage de confiance et assure une base de contributeurs a minima :

• libreboot : remplacement libre de BIOS/UEFI.
• Conversations : le client majeur XMPP sur Android.
• WideLands : jeu libre basé sur le concept de Settlers II.
• LibreWolf : fork de Firefox axé sur la vie privée.
• F-Droid : magasin d'applications libres pour Android.
• FreeBSD : miroir de https://cgit.freebsd.org/
• FreeCAD : miroir officiel.
• Forgejo : fork communautaire de Gitea suite à la privatisation de celui-ci en 2022.
• Fedilab : client Android pour le Fediverse.
• irssi : client IRC.
• Peppermint OS : une distribution Linux avec bureau minimaliste.
• DivestOS : un fork de LineageOS orienté sur la protection de la vie privée.
• VeggieKarte : un service pour trouver des restaurants végétariens/végétaliens.
• …

Comment migrer vers Codeberg ?

Migrer le code source et l'éventuel Wiki associé ne devrait pas poser de problème particulier. Il suffit de configurer git pour pusher vers la nouvelle forge. Cette page décrit comment migrer l'ensemble de votre projet (incluant les issues, le wiki, les Pull Request, etc.) vers Codeberg : https://docs.codeberg.org/advanced/migrating-repos/

Concernant les Workflows (CI), bien qu'il n'y ait pas de garantie de compatibilité avec les Actions Github, la syntaxe se veut similaire pour faciliter la transition : https://forgejo.org/2023-02-27-forgejo-actions/

Au-delà de l'aspect technique, il reste aussi à faire migrer la communauté d'utilisateurs (la présence fortement suivie sur Mastodon peut être un avantage).

Conclusion

Codeberg est un outil prometteur. Il reste pour la communauté du logiciel libre à le faire grandir. Rappelons les statistiques : 100 millions de développeurs sur GitHub, 30 millions utilisant GitLab et 100 000 pour Codeberg. Le potentiel est grand, l'un des enjeux est de financer l'association pour accompagner la croissance de la communauté, tout en faisant monter en puissance l'infrastructure informatique.

Sources / Liens

Controverse GitHub

• Sonnette d'alarme activée dès 2016 (fr).
• Pourquoi abandonner Github (en) : la campagne Give Up GitHub! a été lancée en juin 2022 suite à la controverse sur GitHub Copilot.
• Please don’t upload my code to GitHub (en) : résumé des problèmes posés en particulier par Copilot (IA GitHub).
• https://en.wikipedia.org/wiki/GitHub_Copilot#Licensing_controversy

Forges diverses

• https://en.wikipedia.org/wiki/GitLab
• Synthèse LinuxFR sur l'autohébergement (2018) (fr).

Codeberg

• Parcourir les projets hébergés sur Codeberg (en)
• Suivre Codeberg sur Mastodon (en) : 12000 abonnés.
• Le blog de Codeberg (en)
• Instances, projets et ressources autour de Forgejo (en)
• https://en.wikipedia.org/wiki/Codeberg

Lors d’un Noël de ma tendre jeunesse pré-adolescente est arrivé un « ordinateur » dans le foyer. Ce PC (Intel 386) a été installé dans le bureau et a vite dégénéré en console de jeux. Puis les années passant c’est devenu une formidable source d’expérimentation informatique pour un geek en devenir. À cette époque on sensibilisait la jeunesse à ne pas passer trop de temps devant la télévision et la console de jeux, puis devant l’ordinateur et les jeux vidéo violents. Mais on ne parlait pas vraiment de l’écran.

Aujourd’hui les messages de sensibilisation se résument aux écrans :

• « pas d’écran avant trois ans »
• « nos jeunes passent leurs temps sur leurs écrans » (comme si les « vieux » n’y étaient pas non plus)
• « attention les écrans fabriquent une génération de crétins »
• « les écrans, les écrans, les écrans…»

Il est vrai qu’aujourd’hui l’informatique ne se résume presque plus qu’à un écran. De l’ordinateur avec clavier+souris+écran, voire crayon optique, on est passé aux tablettes et ordiphones qui n’ont plus que l’écran (tactile quand même).

Pour prendre le contre-pied de cette obsession des écrans, je me demandais donc s’il existait encore une informatique « sans écran ». La formidable multiplicité des activités que l’on peut avoir sur un ordinateur pourrait-elle se faire sans écran ? Dans quelle mesure peut-on coder, surfer sur le web, lire/envoyer des mails sans écran ? Cette informatique fantasmée par notre ex-ministre de l’éducation est elle une réalité ?

Sommaire

• L’informatique, une histoire d’abord sans écran
• L’écran ≠ la vue
• L’embarquée, une informatique massivement sans écran
• L’éducation numérique mais sans écran
• Mais peut-on se passer d’écran pour développer ?
• Pour conclure

L’informatique, une histoire d’abord sans écran

Si l’on date la naissance de l’ère de l’informatique avec Ada Lovelace, et qu’on estime l’arrivée des ordinateurs avec écrans à la fin des années 1970, alors on peut aisément dire que l’informatique a été plus longtemps sans écran qu’avec.

Malgré son look cosplay de manga elle n’a pas subi trop d’écrans dans son enfance, elle.

De même, il est raisonnable de considérer l’ordinateur comme l’outil principal pour faire de l’informatique. Il fut largement sans écran à ses débuts.

Pas d’écran pour ces deux geeks qui ont développé UNIX et le langage C (source)

L’altair8800, sorti en 1975 et sur lequel Microsoft a écrit son BASIC, se programmait avec des rubans perforées, voire avec des commutateurs, et l’affichage se faisait avec quelques diodes (DEL) en face avant.
Les cartes à trous étant plutôt utilsées avec les gros ordinateurs (aka Big Iron).

Difficile de considérer ces deux lignes de diodes rouges comme l’écran de l’Altair8800

L’écran ≠ la vue

Pour faire sans écran, on pense instinctivement à utiliser d’autres sens que la vue comme l’ouïe ou le toucher (pour le goût ou l’odorat difficile d’imaginer la chose). Mais l’histoire de l’informatique nous montre que les premières interfaces homme-machine ne fonctionnaient pas avec des écrans, et pourtant utilisaient la vue (lumière, LED, imprimante, position mécanique…).

Mais qu’appelle-t-on écran ?

D’après la définition de Wikipédia, « un écran d’ordinateur est un périphérique de sortie vidéo d’ordinateur. Il affiche les images générées par la carte graphique de l’ordinateur. Grâce au taux de rafraîchissement d’écran élevé, il permet de donner l’impression de mouvement. »

Donc si l’on s’en tient à wikipédia, un écran d’ordinateur c’est :

• des images générées par une carte graphique d’ordinateur. Exit la télé cathodique avec un tuner analogique (qui devient rare aujourd’hui avec la TNT).
• avec un taux de rafraîchissement élevé. Exit les liseuses et autres appareils utilisant un affichage type «  papier électronique ».
• pas d’indication de résolutions.

On peut sans doute rajouter les écrans (comme les télés) qui ne sont pas raccordés à une carte graphique dans la catégorie écran.

Cela serait donc la résolution (définition et taille…) et le rafraîchissement (fréquence de balayage) du périphérique de sortie vidéo qui font un écran.

La matrice 5 × 5 d’un micro:bit ne correspond pas à un critère de résolution suffisant, pas plus que les deux poussoirs ne pourraient prétendre à être un clavier.
Pourtant il affiche bien une « image » de cœur <3 !

Les afficheurs 7 segments ne peuvent pas être considérés comme des écrans. Ils n’affichent que des chiffres et quelques symboles. Difficile de créer une impression de mouvement avec seulement des segments.
En faisant un effort, on arrive à reconstituer quelques lettres.

En doublant le nombre de segments, on arrive à afficher l’ensemble des lettres de l’alphabet latin
Sans diacritiques, faut pas pousser

Un « panel » LCD 20×4 et ses caractères de 8 pixels sur 5 forme un écran de 100 pixels sur 32, la résolution est déjà meilleure, même s’il est toujours prévu pour n’afficher que du texte. Néanmoins on se rapproche de l’idée que l’on se fait d’un « écran ».

Du papier électronique ne peut pas être un écran. La résolution peut être excellente mais le rafraîchissement reste insuffisant.

Finalement la définition de Wikipédia n’est guère rigoureuse ni efficace, entre l’unique LED du panneau de contrôle et l’écran haute résolution, il y a un continuum de périphériques de sortie utilisant des signaux lumineux pour former des images. Il faut peut-être alors chercher les systèmes informatiques qui, dans leur usage normal, utilisent d’autres périphériques de sortie ou pas de périphériques de sortie du tout.

L’embarquée, une informatique massivement sans écran

Bien sûr il faut définir le mot « informatique ». Si l’on se réfère à la définition de Wikipédia :

L’informatique est un domaine d’activité scientifique, technique, et industriel concernant le traitement automatique de l’information numérique par l’exécution de programmes informatiques hébergés par des dispositifs électriques-électroniques : des systèmes embarqués, des ordinateurs, des robots, des automates, etc.

Avec cette définition, le moindre dispositif électronique embarqué est de l’informatique. Lancer une machine à laver, programmer son four ou préparer une cafetière pour le lendemain est donc une forme de manipulation informatique… qu’on peut envisager sans écran.

Cependant dès que vient le besoin de développer un système embarqué ou même de le réparer/déverminer, l’écran revient au galop. On a rapidement besoin d’un écran pour y connecter son environnement de développement et sa sonde de debug. Et même l’oscilloscope ou l’analyseur logique que l’on branche pour « voir » les signaux dispose d’un écran.

En usage normal donc, certains dispositifs informatiques sont conçus pour ne pas nécessiter d’écran parce qu’ils disposent d’un autre périphérique de sortie. Certains centres commerciaux, certaines gares proposent des distributeurs d’histoires courtes : trois boutons comme périphérique d’entrée et une imprimante thermique comme périphérique de sortie. Appuyez et vous aurez de la lecture pour une, trois ou cinq minutes.

Soyons optimistes : il n’y aura pas plus de cinq minute d’attente !

Plus courant, une box Internet domestique est aussi un dispositif informatique sans écran.

- Il est où l’écran ? - Dans ton… navigateur

Il faut reconnaître que si l’usage courant, la connexion à l’Internet, ne nécessite pas d’écran sur la box, son paramétrage en utilise bien un : celui de l’ordinateur sur lequel tourne votre navigateur préféré.

Les assistants vocaux sont des ordinateurs sans écran. Les principaux périphériques d’entrée comme de sortie sont audio : commande vocale, réponse également. Radio France fait d’ailleurs la publicité pour son offre pour enfants, une histoire et… Oli, sur cette absence d’écran, jouant, sans trop le dire, sur cette peur parentale des écrans.

Pourrait-on pousser l’utilisation de ces ordinateurs pour faire du développement et «coder en vocal» ? Possible, il est tout à fait possible de programmer l’ouverture de ses volets, la lecture d’une musique ou le thermostat de sa chaudière avec. Mais ça n’est pas du développement.

L’éducation numérique mais sans écran

Il est largement possible d’apprendre l’informatique sans écran, et même sans ordinateur.

La robotique pédagogique se développe depuis l’apparition de la tortue Logo. Actuellement, pour les plus jeunes dès l’école maternelle, c’est une abeille qui est proposée comme initiation à la programmation.

Si, si, je suis bien un ordinateur

La Bee-Bot se programme à l’aide de sept touches et les périphériques de sortie sont les moteurs de déplacement, un petit haut-parleur et en option un porte-crayon. Avec une interface HommeEnfant-Machine aussi simple, il s’agit plutôt d’une mémorisation de séquences de mouvements que de programmation à proprement parler et pour en utiliser toutes les capacités, un interfaçage avec une application ou un ordinateur plus conventionnel est possible, mais on y retrouve un écran ! De nombreux autres robots pédagogiques, un peu plus complexes et performants, existent mais ceux-ci utilisent un écran classique pour accéder à l’interface de programmation.

Quitte à supprimer les écrans autant aller au bout de la démarche et supprimer l’ordinateur dans son ensemble. Des pédagogues ont ainsi inventé l’informatique déconnectée. Un papier, un crayon, ni écran ni matériel comme le jeu du robot idiot. Les esprits chagrins pourraient y voir une solution au manque de matériel des établissements scolaires.
Plus que d’informatique il s’agit en fait d’initiation à l’algorithmie.

Mais peut-on se passer d’écran pour développer ?

Les plages braille

Il existe une catégorie de population qui est contrainte de se passer d’écran pour se servir d’un ordinateur : les aveugles.

Les personnes aveugles peuvent pourtant se servir d’ordinateur, notamment grâce à un clavier spécifiquement développé pour eux nommé « plage braille ». Grâce à ces plages brailles, les aveugles peuvent lire les caractères en braille en touchant une ligne munie de petites pointes pilotés.

Le prix de ces appareils est assez prohibitif pour quelqu’un qui voudrait jouer avec sans en avoir réellement besoin (un geek quoi). C’est pourtant une bonne manière de faire de l’informatique sans écran. Pour le codage informatique, on utilise un braille à huit points au lieu des six habituels ce qui permet d’avoir 256 combinaisons, soit autant que la table ASCII. La table braille informatique actuelle a été approuvée à l’unanimité en 2007 par la Commission Évolution du Braille Français, elle porte le numéro TBFR2007.

Que vaudrait un jeu vidéo développé pour une plage braille ? Et pourrait-on l’appeler jeu vidéo ?

Avec du papier et un stylo/machine à écrire/carte perforé puis scanner

On peut également faire beaucoup de choses un papier un crayon/stylo/pinceau puis le scanner pour qu’il soit utilisé dans l’ordinateur. Ça reste généralement qu’une étape du développement les programmes ne sont pas plus réalisés intégralement sur papier avant d’être intégré à l’ordinateur.

Pour conclure

Avec des écrits comme « la fabrique du crétin digital » et des propos comme ceux de notre ex-ministre de l’éducation, les écrans sont devenus la bête noire de tous les pédagogos.

Mais l’important n’est-il pas de savoir ce que l’on fait avec un écran ? Faut-il vraiment s’acharner à s’en passer ?

Sans doute pas.

Il serait cependant intéressant d’apprendre à se servir d’outils réservés aux aveugles par exemple. Si nous n’avons plus besoin de la vue pour coder, nous pourrions être un peu plus multi-tâches et coder tout en… regardant la télé !

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.18 du 21 février 2024 (en anglais).

Voici enfin la dernière version de développement avant GIMP 3 ! Bien que la sortie de la version 2.99.18 soit un peu en retard par rapport au planning espéré, celle-ci contient un certain nombre de fonctionnalités et d'améliorations que nous sommes ravis de pouvoir partager avec vous.

⚠️ ☢️ Nous vous rappelons qu'une version de développement sert à présenter les travaux en cours, mais vous permet aussi de détecter et signaler les problèmes au plus tôt. En d'autres termes, cette version est instable et nous ne recommandons pas son usage en production. Utilisez-là parce que vous voulez aider à améliorer GIMP en signalant des bogues.

En particulier, cette version 2.99.18 est peut-être l'une des versions les plus instables de la série 2.99 à cause du projet « space invasion » (NDT : « invasion venue de l'espace », un jeu de mots avec l'anglais colorspace signifiant espace de couleurs). Cela est parfaitement attendu et normal. ⚠️ ☢️

Sommaire

• L'invasion de l'espace (des couleurs) !
• Amélioration des algorithmes de couleur
• Édition non-destructive, première mouture
• Amélioration de la prise en charge des polices de caractères
• Expansion automatique des calques
• Nouvelles options d'alignement
• Thèmes
• Boîte de dialogue de bienvenue
• Formats de fichiers
  • DDS
  • GIF
  • HEIF et JPEG-XL
  • OpenEXR
  • PDF
  • PNG
  • PSD
  • PSP
  • Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2
  • Nouveau format de palette pris en charge : Swatchbooker
• Interactions avec les pads de tablettes graphiques sous Wayland
• Mise à jour de l'API
• GEGL et babl
• Statistiques de sortie
• Nouvelles de l'équipe et procédure de sortie
• Autour de GIMP
  • Des nouvelles des miroirs
  • GIMP sous Windows/ARM
• Télécharger GIMP 2.99.18
• Et ensuite ?

Cette dépêche présente les changements les plus notables et les plus visibles. En particulier, elle ne contient pas de liste exhaustive des correctifs de bogues ou des améliorations un peu moins importantes. Pour une liste plus complète des changements, nous vous invitons à consulter le fichier NEWS ou à jeter un coup d’œil à l'historique du dépôt Git.

L'invasion de l'espace (des couleurs) !

Nous avons travaillé dur sur le projet Space Invasion, qui est — comme vous vous en rappelez peut-être — le nom de code que nous avons donné au projet visant à rendre GIMP plus correct en ce qui concerne les couleurs.

Ces derniers temps, nous avons réalisé le portage des anciennes structures de couleurs utilisées en interne (GimpRGB, GimpCMYK, GimpHSV…) dont nous nous servions pour stocker les informations de couleurs vers GeglColor. Cet objet générique peut contenir n'importe quelle donnée de couleur, quel que soit le modèle colorimétrique, la précision ou l'espace, du moment que ceux-ci sont pris en charge par babl, notre moteur pour l'encodage des pixels.

En ce qui concerne la justesse des couleurs, cela signifie que nous ferons maintenant les conversions de couleurs uniquement si cela est nécessaire (conversions à la dernière minute), ce qui permettra de ne pas perdre d'information lorsque cela peut être évité. Par exemple, imaginons que vous utilisiez la pipette à couleurs sur une image : si nous convertissions cette couleur vers un format intermédiaire avant de l'utiliser sur une autre image (qui peut avoir le même format de couleurs ou un format différent), deux conversions auraient lieu. Cela augmente les possibilités de perte de précision. Ce problème est encore plus flagrant si les formats d'entrée et de sortie sont les mêmes (autrement dit, lorsqu'aucune conversion n'est nécessaire). Et cela sera encore plus problématique lorsque le modèle CMJN sera pris en charge nativement (nous voulons éviter à tout prix de faire un aller-retour entre un format intermédiaire et le CMJN, qui n'a pas de relation bijective avec la plupart des autres modèles de couleurs, même en travaillant sans bornes et en ignorant les problèmes de précision).

Définition d'un espace non borné (ajout par rapport à la dépêche originelle) : lorsque la précision est entière, l'espace est toujours borné (par exemple [0-255] en 8-bit). Par contre, en flottant, où l'espace de travail standard est [0, 1], on peut décider d'accepter les valeurs négatives et supérieures à 1. Cela rend les conversions entre beaucoup d'espaces de couleurs bijectives, aux erreurs de précisions près. Notamment, les conversions entre deux espaces RVB, ou même un espace RVB et divers autres modèles, deviennent bijectives. Ce n'est pas le cas entre RVB et CMJN, même en espace de couleurs infini.

Nous sommes également en train de migrer le stockage des données de couleur vers ce type d'objet générique. Cela signifie entre autres que les palettes de couleurs pourront comporter des couleurs au format CMJN, CIELAB ou bien encore dans tout autre modèle pris en charge (et pas seulement ces couleurs après une étape de conversion vers le sRVB non borné - « unbounded sRGB »).

Une conséquence pour la maintenance logicielle est qu'il sera beaucoup plus facile de gérer les conversions de couleurs au sein de notre code, étant donné que cette structure comprend à la fois les données et leur « signification ». Cela rend la gestion des couleurs beaucoup moins susceptible d'introduire des bogues par rapport à l'approche précédente, qui consistait à faire suivre les deux types d'information séparément.

Finalement, nous travaillons à faire apparaître l'information concernant l'espace de couleurs à plusieurs endroits de l'interface où cela est pertinent, par exemple lorsque des données RVB, CMJN, TSL ou TSV sont affichées ou peuvent être choisies. Les valeurs brutes dans ces modèles de couleurs en l'absence de la connaissance de l'espace de couleurs associé n'ont pratiquement aucun sens. L'affichage dans l'interface de valeurs RVB sans autre précision est un reliquat du passé, lorsque cela signifait le plus souvent sRVB. Cela n'est plus vrai dans un contexte graphique moderne et l'interface devrait être claire à ce sujet.

La vidéo ci-dessous montre quelques aspects de ce travail sur l'interface, par exemple le fait que les modèles RVB, TSV ou CMJN affichent à tout instant l'espace de couleurs dans lequel les valeurs sont considérées (ce qui très souvent correspond au nom du profil ICC). Cela est déjà fait pour la pipette à couleurs, les échantillons de couleurs, l'ancrable des couleurs de premier/d'arrière plan, la boîte de dialogue « Changer la couleur de premier/d'arrière plan », ainsi qu'à d'autres endroits.

Non seulement cela, mais lorsque les gens sélectionnent un profil d’épreuve sur écran et activent l'épreuve sur écran (par exemple grâce à la nouvelle bascule de simulation qui a été ajoutée dans GIMP 2.99.12), nous afficherons également non seulement la zone hors gamme de l'espace colorimétrique de l'image, mais également celle de l'espace d’épreuve.

Invasion de l'espace dans l'interface - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Avertissement très important : il s'agit encore une fois d'un portage énorme dans notre base de code, ce qui a impacté littéralement des milliers de lignes de code. Ce travail est inachevé mais il devra être terminé avant la première version candidate. Des instabilités ou des bugs sont à prévoir dans cette mise à jour donc si vous rencontrez un problème, nous recommandons de le rapporter.

Amélioration des algorithmes de couleur

Øyvind Kolås a amélioré quelques algorithmes internes :

• Les pixels achromatiques de l'outil Teinte-Saturation sont désormais un cas spécial afin que les pixels en niveaux de gris (saturation de 0) ne soient modifiés que par le réglage principal, pas par le réglage rouge.
• Les dégradés en niveaux de gris restent désormais achromatiques même avec "Tramage" coché dans l'outil Dégradé.

Au fur et à mesure que le projet space invasion avance, obtenir des résultats cohérents devient plus facile dans divers algorithmes liés aux couleurs, nous permettant ainsi de découvrir rapidement les problèmes et de les résoudre.

Édition non-destructive, première mouture

Un domaine dans lequel nous sommes « en avance sur le planning » est l'édition non destructive, qui était très demandée ! Les fondations de ces fonctionnalités ont été mises en place par de nombreux développeurs au cours de nombreuses années, depuis l'introduction de GEGL dans GIMP. Bien qu'initialement prévue pour la feuille de route de la version 3.2, une première implémentation a vu le jour en tant que continuation d'un projet Google Summer of Code. Si vous n'êtes pas familier avec ce terme, « édition non destructive » implique notamment que des effets de filtres tels qu'un effet de flou sont stockés séparément des pixels du calque. Cela signifie que si vous désirez plus tard modifier un réglage, réarranger ou même retirer le filtre, vous pouvez le faire très facilement sans affecter le reste de l'image. Jusqu'à présent, GIMP utilisait une procédure d'édition destructive où les effets étaient immédiatement appliqués sur le calque, c'est donc un changement majeur !

Toute opération GEGL munie d'une interface graphique est désormais appliquée aux calques de manière non destructive. (Les effets non destructifs pour les masques de calques et les canaux sont prévus pour les versions ultérieures.) Cela inclut les greffons GEGL tiers et les opérations personnalisées créées avec notre outil GEGL Graph. Ces effets peuvent être sauvegardés et chargés via les fichiers de projet .xcf, bien que toutes les propriétés GEGL ne soient pas encore prises en charge dans la version actuelle.

Une fois qu'un filtre a été appliqué, vous pouvez continuer à interagir avec lui en cliquant sur l'icône de filtre dans l'ancrable des calques. Cela ouvrira une boîte de dialogue montrant tous les filtres actuellement appliqués au calque. À partir de là, vous pouvez alterner l'état de visibilité du filtre, modifier ses réglages, réordonner les filtres et retirer les effets un à un. Vous pouvez aussi fusionner tous les filtres et les appliquer à l'image pour retrouver une procédure d'édition destructive.

Effets non destructifs - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Notez bien que tout cela est seulement une première implémentation, et beaucoup de travail reste à faire pour disposer d'une édition non destructive complète et riche. Nous allons continuer à affiner les fonctionnalités existantes pour la sortie de la version 3.0 en nous basant sur les tests et les retours des utilisateurs, et nous les développerons davantage par la suite. L'interface elle-même ne correspond pas à notre vision idéale de cette fonctionnalité, et un premier jet de spécifications a été écrit pour définir un processus d'édition bien plus intégré.

La capture d'écran ci-dessous est une maquette réalisée à partir de ces premières spécifications. Elle montre les effets de calque placés au sein de la liste principale des calques, partageant les mêmes boutons « œil » et « cadenas », mais également avec leurs propres masques faciles à éditer :

Maquette des spécifications : les effets de calque sont visibles directement dans la liste des calques, avec leur propres masques

Néanmoins, l'implémentation de cette nouvelle interface sera un défi en elle-même et nous avons donc décidé de la remettre à après la sortie de GIMP 3 et de proposer cette première mouture en premier lieu.

N'hésitez pas à partager vos opinions dans les forums de discussion et dans le suivi des incidents !

Amélioration de la prise en charge des polices de caractères

Idriss Fekir, un autre étudiant du GSoC 2023, a travaillé avec Liam Quinn, un développeur de longue date, sur l'amélioration de la prise en charge des polices de caractères par GIMP. Une grande partie de ce travail concerne le code interne de GIMP afin d'améliorer sa capacité à gérer les futures mises à jour de polices et de texte. Certains changements plus visibles sont par exemple :

• GIMP n'a plus besoin que les noms des polices de caractères soient uniques pour pouvoir les distinguer les unes des autres. Cela signifie qu'il n'ajoutera plus « #1 », « #2 » et ainsi de suite, mais gardera à présent les noms originaux dans la liste de sélection des polices. Malgré des noms apparemment identiques, deux polices avec le même nom fonctionneront désormais correctement.
• GIMP peut maintenant charger des polices avec des styles personnalisés (en contournant l'utilisation de Pango qui n'est pas capable de les charger).
• Nous pouvons à présent charger davantage de types de polices qu'auparavant. Si jamais nous ne prenons pas encore en charge une police donnée (ou si elle est inexistante), nous sommes mieux à même de le détecter et nous pouvons nous replier sur une police par défaut. Cela permet d'améliorer la prise en charge d'un fichier .xcf créé sur un autre ordinateur avec différentes polices disponibles.
• Sous Windows, nous forçons le moteur Pango à toujours utiliser l'anticrénelage. Cela augmente la lisibilité du texte des menus sous ce système d'exploitation, en particulier lorsqu'un thème sombre est utilisé.
• Le code pour la sauvegarde au format XCF stocke désormais les informations concernant les polices de manière bien plus précise, ce qui aide à éviter de charger une police incorrecte lors de la réouverture d'un fichier XCF.
• L'alignement du texte dans les calques de texte pour les langues écrites de la droite vers la gauche est maintenant plus cohérent avec la manière dont cela fonctionne dans d'autres programmes (par exemple LibreOffice et Scribus).

Ces changements sont beaucoup moins voyants que certaines autres fonctionnalités et pourraient sembler moins importants, mais ils constituent en fait les fondations qui permettront d'avoir une gestion du texte bien plus fiable dans GIMP. Notre vision pour le futur est d'avoir une édition de texte plus simple tout en étant plus puissante et plus riche en fonctionnalités (en particulier les fonctionnalités OpenType qui sont quelques-unes des améliorations majeures que nous espérons ajouter un jour ou l'autre).

Expansion automatique des calques

Le troisième projet GSoC de l'été dernier par l'étudiant Shubham Daule a apporté une fonctionnalité demandée depuis longtemps : l'expansion automatique de calques ! Les outils de peinture ont désormais une option supplémentaire « Étendre les calques ». Lorsque cette case est cochée, peindre au-delà des limites des calques les fera s'étendre automatiquement afin que vous n'ayez pas à gérer vous-même la taille du calque. Si vous souhaitez étendre le calque au-delà de la taille actuelle du canevas, vous devrez également cocher l'option « Afficher tout » dans le menu Affichage.

Calques à expansion automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

L'option d'expansion des calques comporte également des paramètres supplémentaires lorsqu'elle est sélectionnée. Vous pouvez décider dans quelle mesure vous souhaitez que les limites du calque s'étendent chaque fois que le pinceau les atteint. Il existe également des options pour spécifier comment les nouvelles zones du calque et du masque de calque doivent être remplies une fois étendues.

Nouvelles options d'alignement

Le nouveau contributeur mr. fantastic a développé deux nouvelles options pour aligner les calques sur le canevas. Avec « Snap to Bounding Boxes » (« Aligner sur les boîtes englobantes ») activé, des guides dynamiques s'afficheront désormais pour vous montrer quand le calque que vous déplacez est aligné avec le centre ou les côtés des autres. Le calque actif s'alignera également sur ces bordures pour vous aider à les organiser correctement. La deuxième option, « Snap to Equidistance » (« Aligner à équidistance »), vous permet un alignement entre trois calques équidistants les uns des autres.

Nouvelles options d'alignement automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Thèmes

Nous avons continué à améliorer l'interface utilisateur et le style de cette version. L’une des améliorations les plus importantes concernait la gestion des « fuites de thèmes système ». Il existe des styles qui n'ont pas été spécifiquement définis dans nos thèmes, donnant ainsi l'opportunité aux règles de style du thème système de "fuiter" de manière conflictuelle dans notre interface. Avec l’aide et les retours de plusieurs contributeurs et utilisateurs, nous avons beaucoup progressé dans la définition de ces styles afin que tous aient une expérience cohérente !

Récemment, Jehan a travaillé sur la réorganisation et la simplification de notre système de thèmes. Dans les versions de développement précédentes, nous avions cinq thèmes différents : Par Défaut, Gris, Système, Plus Sombre et Compact (chacun avec des options claires et sombres). Ceux-ci ont été simplifiés dans le thème Système et un seul thème par défaut avec trois états possibles : clair, foncé et gris. De même, nos quatre thèmes d'icônes distincts ont été condensés dans l'ensemble Legacy et un thème d'icôns par défaut avec des variantes couleur et symbolique. Nous pensons que ces changements réduiront la confusion des utilisateurs et leur permettront de trouver plus facilement leur apparence d'interface préférée.

De plus, sous Windows, la barre de titre principale (et la plupart des barres de titre des boîtes de dialogue) s'ajuste désormais au mode clair ou sombre en fonction du thème sélectionné.

Boîte de dialogue de bienvenue

La boîte de dialogue de bienvenue a été étendue pour fournir un accès rapide à un certain nombre de fonctionnalités et d'options utiles. Elle comporte ainsi quatre nouvelles sections :

• Personnaliser : Plusieurs options de personnalisation nécessitent de fouiller dans la boîte de dialogue des Préférences pour être modifiées. À présent, vous pouvez facilement modifier les thèmes de couleurs et d'icônes, la langue et la taille de la police de l'interface utilisateur, ainsi que certains réglages en fonction du système d'exploitation.
• Créer : Cette section affiche les huit images que vous avez ouvertes en dernier et vous permet de les rouvrir rapidement. Des boutons pour créer une nouvelle image ou pour en charger une existante sont également présents. À l'instar d'autres programmes, vous pouvez demander à ce que cet écran apparaisse automatiquement au démarrage de GIMP pour un accès direct à ces fonctionnalités.
• Contribuer : Nous avons réuni ici quelques-unes des nombreuses façons dont vous pouvez participer au développement de GIMP. Cette section comporte des liens pour le signalement de bogues, pour écrire du code, pour aider aux traductions ou pour faire un don.
• Notes de version : Précédemment, le lien vers ces notes étaient affichées dans la moitié inférieure de la boîte de dialogue de bienvenue. À présent, nous avons un onglet entier dédié à ces notes pour une lecture plus aisée.

Formats de fichiers

Comme cela était déjà le cas avec les versions précédentes, nous avons amélioré la prise en charge de formats de fichiers déjà existants et nous avons ajouté la prise en charge de l'importation et de l'exportation pour de nouveaux formats.

DDS

Stayd, un nouveau contributeur, a travaillé avec notre développeur Jacob Boerema pour apporter de nombreuses améliorations au greffon DDS. Pour commencer, les fonctions d'importation ont été écrites afin d'être plus simples et plus faciles à étendre dans le futur. Les mises à jour supplémentaires incluent également :

• Le chargement d'images DDS RVBA 16 et 32 bits/canal est maintenant possible.
• Le filtre cubique Catmull-Rom a été ajouté pour la génération de mipmaps, et tous les calculs pour générer les mipmaps sont effectués avec une précision de 32 bits.
• Les images DDS aux formats R8G8, R16 et R16G16 peuvent maintenant également être chargées.
• Une option pour renverser verticalement les images DDS lors de l'importation a été ajoutée pour faire écho à l'option d'exportation correspondante, étant donné que certaines images de jeux stockent leurs données de cette manière.

GIF

Par le passé, écraser un fichier GIF à la sauvegarde (plutôt que de l'exporter) le convertissait systématiquement en un fichier avec une seule image. Désormais nous vérifions lors du chargement si le fichier GIF est une animation, de manière à également sauvegarder une animation lors de l'écrasement.

HEIF et JPEG-XL

Les deux greffons utilisent maintenant leurs bibliothèques respectives (libheif et libjxl) pour le chargement des métadonnées. Cela nous a permis de retirer notre code maison chargé d'interpréter l'orientation des images et d'utiliser à la place les informations fournies par ces bibliothèques.

OpenEXR

Le format OpenEXR permet aux canaux d'avoir des noms personnalisés, outre le type de couleur. Dans ce cas, nous considérons maintenant toute image à un seul canal avec un nom non conventionnel comme étant en niveaux de gris. Lors de l'importation, nous affichons une notification afin que les utilisateurs soient prévenus de cette conversion.

PDF

L'option d'exportation « Calques en tant que pages » fonctionne maintenant même s'il y a un seul groupe de calques. Auparavant, cette option n'était pas disponible car le greffon vérifiait seulement s'il y avait plus d'un « calque » sans examiner s'il s'agissait d'un groupe de calques avec de multiples sous-calques.

PNG

Les fragments de fichiers PNG qui sont « copiables sans risque » (« safe-to-copy chunks ») sont maintenant préservés lors de l'importation et inclus dans l'image exportée. Un autre souci qui existait lors de l'exportation de PNGs indexés avec transparence (et qui nous avait été souvent signalé) a été résolu. Désormais les couleurs indexées devraient être affichées correctement après exportation.

PSD

Jacob Boerema a poursuivi son travail d'amélioration du greffon PSD. En plus d'avoir résolu des bogues, par exemple dans l'ordre des calques lors de l'importation, il a aussi clarifié l'avertissement présenté lors de l'exportation et concernant la compatibilité des modes de calques entre GIMP et Photoshop.

PSP

Le greffon Paintshop Pro peut maintenant importer davantage de caractéristiques depuis un fichier projet, comme par exemple le profil de couleurs ICC, les guides, les grilles, et la sélection active lors de la sauvegarde. Les failles de sécurité ZDI-CAN-22096 et ZDI-CAN-22097 ont également été corrigées dans cette version.

Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

Nous avons récemment ajouté la prise en charge de l'importation et de l'exportation pour le format Farbfeld, un format d'image sRVB conçu pour être facile à lire, à envoyer dans des pipes et à compresser avec des outils tiers.

Nous avons aussi ajouté la prise en charge de l'importation seule pour les nouveaux formats suivants :

• Esm Software PIX : Un format JPEG modifié utilisé exclusivement par l'entreprise Esm Software pour stocker leurs images propres. Cela a été implementé en réponse à un signalement de bogue qui avait confondu ce format avec le format Alias PIX que nous prenions déjà en charge.
• HEJ2 : Un ajout à notre greffon HEIF déjà existant fourni par Daniel Novomeský qui permet d'importer des images JPEG 2000 compressées.

Nouveau format de palette pris en charge : Swatchbooker

Swatchbooker est un programme libre de création et de conversion de palettes de couleurs qui prend en charge de nombreux formats. Bien que le programme lui-même n'ait pas été mis à jour depuis de nombreuses années, son format de palette propre .sbz est le plus complet de tous ceux que nous prenons en charge actuellement. Parmi ses nombreuses fonctionnalités, on peut citer la possibilité de définir des couleurs dans plusieurs modèles de couleurs pour chaque entrée d'une palette, des noms et des descriptions régionalisables, et la prise en charge de profils de couleurs ICC différents pour chaque entrée.

Via notre travail sur la prise en charge de son importation, nous avons pu fournir des informations qui ont conduit à un correctif de bogue dans la prise en charge de Swatchbooker par Krita. C'est toujours sympa quand des projets peuvent collaborer et s'entraider !

Interactions avec les pads de tablettes graphiques sous Wayland

Carlos Garnacho, un contributeur GNOME de longue date, a ajouté la prise en charge de l'interaction directe des boutons de tablettes graphiques (pad) avec GIMP. Quand une tablette est branchée, vous pouvez désormais assigner différentes actions aux contrôles de la tablette depuis la boîte de dialogue « Périphériques d'entrée » dans le menu Édition.

Assigner des actions aux boutons d'une tablette graphique - GIMP 2.99.18

Ce travail a aussi impliqué le portage de fonctionnalités vers GTK 3, la boîte à outils utilisée par GIMP pour son interface graphique. Notez que cette fonctionnalité est seulement disponible sous Wayland pour le moment.

Mise à jour de l'API

L'interface de programmation d'application (API), destinée aux créateurs de greffons, est régulièrement retravaillée dans le cadre de la refonte de GIMP 3. Une partie de ce travail est de migrer l'API vers l'utilisation de GeglColor lorsque les couleurs sont impliquées, ce qui entre dans le cadre plus général du projet Space Invasion. Malgré tout, ce n’est qu’une petite partie de l’ensemble des améliorations de l’API.

Nous nous orientons également vers plus de classes pour représenter les différentes ressources gérées par GIMP (pinceaux, polices, motifs, etc.) au lieu de les représenter uniquement par des noms (ce qui était une limitation historique alors qu'il est tout à fait possible à 2 créateurs de ressources de choisir le même nom et le fait est que nous voyons de tels cas dans la nature — par exemple, 2 polices créées indépendamment peuvent avoir le même nom).

Un autre grand pas consiste à remplacer le GimpValueArray représentant les arguments ordonnés d'une procédure d'un greffon par un GimpProcedureConfig qui contient les arguments par nom plutôt que par ordre. Cela permet une utilisation beaucoup plus sémantique des procédures de greffon (surtout lorsqu'elles ont une longue liste d'arguments) et facilitera également l'amélioration des greffons à l'avenir, avec des arguments nouveaux ou réorganisés sans créer de nouvelles procédures, car l'ordre et le nombre des arguments comptent beaucoup moins. Cela signifie que l'ajout de nouveaux arguments dans le futur ne brisera plus les scripts déjà existants qui dépendaient des versions antérieures de ces greffons (les auteurs de greffons devront toujours choisir des valeurs par défaut appropriées pour les nouveaux arguments afin que cela soit vrai, bien sûr).

En parallèle, nous continuons d'améliorer la capacité de création automatique d'interfaces graphiques offerte aux greffons, rendant la création de boîtes de dialogue plus simple que jamais. Cela inclut (parmi de nombreuses autres améliorations) un nouveau type d'argument de procédure nommé GimpChoice qui est une liste de choix sous forme de chaînes de caractères qui peut être présentée aux créateurs sous forme de widgets de liste déroulante dans la boîte de dialogue de votre greffon.

Nous prévoyons d'écrire et de publier un didacticiel pour les rédacteurs de greffons dans la section Développement de ressources de notre site Web pour développeur en même temps que la sortie de GIMP 3, ou peu de temps après.

GEGL et babl

Cette version de GIMP est accompagnée de nouvelles versions de GEGL et babl, qui contribuent toutes deux au projet (Color) Space Invasion.

babl 0.1.108 apporte une nouvelle fonction babl_space_is_rgb pour nous aider à confirmer directement qu'un espace colorimétrique est RVB (plutôt que de faire plusieurs tests pour voir s'il n'est pas CMJN ou niveaux de gris). Plusieurs améliorations ont également été apportées au processus de compilation et à l'outil d'interface de ligne de commande de babl.

GEGL 0.4.48 fournit plusieurs mises à jour de l'objet GeglColor qui prend désormais en charge une grande partie des opérations de couleur de GIMP. Les améliorations spécifiques incluent la possibilité d'obtenir et de définir directement les valeurs de couleur CMJN, ainsi que l'attribution de l'espace colorimétrique lors de la définition des couleurs RVB(A).

Un crash dans le filtre gegl:voroni existant a été corrigé, et un bogue de longue date avec le filtre gegl:dropshadow qui empêchait l'effet de rétrécir a également été corrigé.

Enfin, un nouveau filtre gegl:shuffle-search a été ajouté à l'atelier. Il mélange les pixels voisins pour créer un effet de tramage plus optimisé.

Statistiques de sortie

Hormis la première version de la série (2.99.2), GIMP 2.99.18 est clairement la plus grosse mise à jour à bien des égards. Depuis la version 2.99.16 :

• 238 rapports ont été clôturés comme CORRIGÉS.
• 201 demandes de fusion ont été acceptées.
• 1358 commits ont été poussés.
• 26 traductions ont été mises à jour : allemand, basque, biélorusse, portugais brésilien, bulgare, catalan, chinois (Chine), danois, espagnol, espéranto, finnois, géorgien, grec, hongrois, islandais, italien, lituanien, norvégien nynorsk, persan, polonais, russe , slovène, suédois, turc, ukrainien, vietnamien.

60 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.18 (l'ordre est déterminé par le nombre de commits; certaines personnes apparaissent dans plusieurs groupes) :

• 23 développeurs pour le code principal : Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav Grinkov, lillolollo, Øyvind Kolås, Sabri Ünal, programmer_ceds, Lukas Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels De Graef, Zander Brown, psykose, sonia.
• 17 développeurs de greffons ou de modules : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel Novomeský, Sabri Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav Grinkov, programmer-ceds, sonia.
• 31 traducteurs : Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri Ünal, Anders Jonsson, Rodrigo Lledó, Jordi Mas, Alan Mortensen, Vasil Pupkin, Asier Sarasua Garmendia, Kolbjørn Stuestøl, Boyuan Yang, Víttor Paulo Vieira da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius, Balázs Úr, Marco Ciampa, Sveinn í Felli, Danial Behzadi, Ngọc Quân Trần, Jürgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT, MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
• 9 créateurs de ressources (icônes, thèmes, curseurs, splash screen, métadonnées…) : Alx Sa, Jehan, Ferry Jérémie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes, Jacob Boerema, Sabri Ünal, mr.fantastic.
• 5 contributeurs à la documentation : Jehan, Bruno Lopes, Jacob Boerema, Alx Sa, Anders Jonsson.
• 14 contributeurs pour la compilation, l'empaquetage ou l'intégration continue : Jehan, Bruno Lopes, bootchk, Alx Sa, Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko Becker, mr.fantastic, Daniel Novomeský, U-YGGDRASIL\ender, lillolollo.

Contributions à d'autres dépôts du GIMPverse (l'ordre est déterminé par le nombre de commits) :

• babl 0.1.108 est composé de 17 commits par 6 contributeurs : Jehan, Øyvind Kolås, John Marshall, Andre Klapper, John, sid.
• GEGL 0.4.48 est composé de 77 commits par 20 contributeurs : Øyvind Kolås, Jehan, Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal, Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin , Piotr Drąg, Víttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco Ciampa, Rodrigo Lledó, dimspingos, woob.
• ctx a eu 308 commits depuis la version 2.99.14 par 1 contributeur : Øyvind Kolås.
• La version gimp-macos-build (scripts d'empaquetage macOS) est composée de 32 commits par 1 contributeur : Lukas Oberhuber.
• La version flatpak est composée de 15 commits par 3 contributeurs : Jehan, Daniel Novomeský et Hubert Figuière.
• Notre site Web principal a eu 31 commits depuis la sortie du 2.10.36 par 6 contributeurs : Jehan, Alx Sa, Sabri Ünal, Anders Jonsson, Bruno Lopes, Jonathan Demeyer.
• Notre site Web des développeurs a eu 30 commits depuis la version 2.10.36 par 5 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
• Notre documentation 3.0 a enregistré 247 commits depuis la version 2.99.16 par 17 contributeurs : Andre Klapper, Jacob Boerema, Yuri Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, Dimspingos, Anders Jonsson, Boyuan Yang, Sabri Ünal, Víttor Paulo Vieira da Costa, Juliano de Souza Camargo, Rodrigo Lledó, Kolbjørn Stuestøl, Marco Ciampa, Danial Behzadi, Emin Tufan Çetin.

N'oublions pas de remercier toutes les personnes qui nous aident à faire le tri dans Gitlab, rapportent des bogues et discutent avec nous d'éventuelles améliorations. Notre communauté est également profondément reconnaissante envers les guerriers d'Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de pièces qui composent GIMP et son environnement, et de la manière dont nous obtenons des statistiques via des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

Nouvelles de l'équipe et procédure de sortie

Les droits d'accès au dépôt git ont été récemment accordés à Bruno Lopes (qui a été très actif dans l'amélioration de notre processus de compilation et de l'empaquetage pour Windows).

Plusieurs développeurs ou empaqueteurs de longue date ou plus récents qui ont commencé à contribuer au nouveau site Web des développeurs ont également reçu l'accès au dépôt git associé.

De plus en plus de contributeurs participent désormais activement aux tests des versions et du processus d'empaquetage, et c'est la première dépêche depuis des années (NDT : cela désigne la news originale sur le site de GIMP) que Jehan n'a pas écrite presque entièrement ! Merci beaucoup à Alx Sa (alias Nikc ou CmykStudent) d'avoir entamé la rédaction collaborative de la nouvelle !

Il est clair que nous consolidons jour après jour une solide équipe de contributeurs et cela se voit dans notre processus de publication, avec de plus en plus de retours à chaque version.

Nous sommes également particulièrement heureux et fiers que les 4 projets GSoC que nous avons eus, depuis que nous avons recommencé à souscrire à ce programme de mentorat, aient tous été couronnés de succès et ont fini par être fusionnés avec la branche principale du code au plus tard six mois après la fin du stage.

Autour de GIMP

Des nouvelles des miroirs

Depuis la dernière dépêche, un nouveau miroir a été apporté à GIMP par :

• Sahil Dhiman, à Nuremberg, en Allemagne, comme projet personnel.

Cela nous amène à un total de 46 miroirs répartis dans le monde.

Les miroirs sont importants car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.

GIMP sous Windows/ARM

Depuis notre annonce d'une version expérimentale sur Windows pour l'architecture ARM 64 bits (en anglais), nous avons reçu l'aide de Hernan Martinez, contributeur bien connu du projet MSYS2, qui a hébergé notre tout premier runner pour l'intégration continue (CI) pour Windows sur l'architecture Aarch64. Bien que cela n'ait été qu'une configuration temporaire (littéralement une machine de compilation dans le salon de quelqu'un) en attendant une situation plus stable, nous sommes extrêmement reconnaissants envers Hernan qui nous a aidés à faire notre deuxième pas sur cette plateforme (la première étape a été effectuée par Jernej, qui a créé notre premier installateur expérimental), s'est assuré que notre processus de compilation automatique fonctionne sur cette machine, et plus encore.

Depuis lors, la situation plus stable est arrivée : Arm Ltd. eux-mêmes se sont mobilisés et ont officiellement contribué trois runners pour notre processus d'intégration continue dans Gitlab ! Arm Ltd. a également sponsorisé un kit de développement Windows pour l'un de nos développeurs.

Bien que nous considérions toujours cette version comme expérimentale, en raison du manque de tests et du fait que seuls 2 contributeurs disposent actuellement d'une machine capable de l'exécuter, le plus gros facteur bloquant a été supprimé et nous sommes heureux d'annoncer que notre programme d'installation Windows universel pour GIMP 2.99.18 contient GIMP pour les 3 plates-formes (x86 32 et 64 bits, et maintenant ARM 64 bits) !

Télécharger GIMP 2.99.18

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

• Flatpaks Linux pour x86 et ARM (64 bits)
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
• Paquets macOS DMG pour le matériel Intel
• Paquets macOS DMG pour le matériel Apple Silicon

D'autres paquets réalisés par des tiers devraient évidemment suivre (paquets des distributions Linux ou *BSD, etc.).

Et ensuite ?

Alors que nous sommes maintenant entrés dans un gel des fonctionnalités, notre attention s'est déplacée vers la correction des bogues, le nettoyage et la préparation de la première version candidate 3.0.

Nous pensons en effet qu'il s'agit de la dernière version de développement puisqu'aucune nouvelle fonctionnalité ne sera introduite désormais, du moins au niveau de l'interface utilisateur (l'API est encore en évolution jusqu'à la première version candidate). Donc, ce que vous voyez maintenant est essentiellement ce que vous devriez obtenir dans GIMP 3.0.0, en termes de fonctionnalités.

C'est pourquoi nous avons sorti cette version même si nous savons qu'elle est assez instable. C'est l'heure des commentaires de dernière minute ! C'est aussi le moment de signaler et de corriger les bogues comme si demain n'existait pas. Nous espérons pouvoir bientôt livrer une RC1 et elle devrait être aussi dépourvue de bogue que possible.

Nous espérons actuellement pouvoir publier GIMP pour le prochain Libre Graphics Meeting du 9 au 12 mai. Pour être honnête, ce n’est pas un objectif facile et nous ne sommes donc pas sûrs de pouvoir l’atteindre. Ce qui est sûr, c'est que même si nous n'y parvenons pas à temps, cela ne devrait pas arriver trop longtemps après. En particulier, nous ne publierons pas simplement parce que nous avons fixé une date limite. Nous voulons offrir la meilleure expérience possible, ce qui signifie que si nous découvrons des bogues bloquants de dernière minute, nous retarderons la sortie jusqu'à ce qu'ils soient corrigés.

N'oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, c'est un moyen de donner en retour et d'accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳