L'Agenda du Libre

Les travaux d'étudiants de la promotion 1973 de l’École Normale Supérieure (Normale Sup) sont à l'origine de la production, dès 1977, d'une famille de circuits intégrés (CI) dédiés à l'affichage sur écran (à l'époque, cathodique ).

Cette dépêche est consacrée à l'un d'entre eux, l'EF9365 (ou le "365" pour les intimes), qui est stricto sensu le premier GPU (excusez-du peu !) et nous verrons pourquoi.

Les rédacteurs de cette dépêche collaborative remercient :

• Philippe Matherat, le concepteur de ce composant ! Il a eu la gentillesse de se prêter au jeu en répondant à nos questions et en apportant de nombreuses précisions et anecdotes –les citations dans la dépêche sont intégralement de sa main– ;
• PulkoMandy, pour son journal d’archéologie informatique sur la thèse de Jean Gastinel. Sans ce journal, cette dépêche n'aurait jamais vu le jour ;
• Jean-François DEL NERO, développeur de l’émulation du 365 dans Mame, pour les échanges et les apports techniques ;
• l'équipe de rédaction du magazine Sciences et Avenir, pour l'autorisation de publier des extraits de l'article "le Silicon labo de la rue d'Ulm", n° 455 (Janvier 1985).

Sources :

• lien nᵒ 1 : Le journal de PulkoMandy sur la thèse de Jean Gastinel
• lien nᵒ 2 : La thèse de 3è cycle de Philippe Matherat, 19 mai 1978
• lien nᵒ 3 : une démonstration du 365, sur un ordinateur de 1984
• lien nᵒ 4 : Les spécifications techniques
• lien nᵒ 5 : Présentation "A chip for low-cost raster-scan graphic display" au SIGGRAPH78 d'Atlanta

Sommaire

• Généalogie des puces EFxxxx
  • La génèse
  • Une question de mémoire
  • Pourquoi cette augmentation de la capacité de la RAM à cette époque ?
  • Le plastique, c'est fantastique
  • La production
    • L'histoire industrielle du fondeur
    • Dates de production
• La petite famille
  • L'EF9364, le précurseur
  • L'EF9365
  • Le NEC µPD7220 : le cousin Japonais
  • L'EF9340 et 9341
  • L'EF9345, la cheap chip
  • La suite pour ST
• Le génie de l'EF9365
  • Un vrai framebuffer
  • La décharge du CPU pour certaines tâches
    • Le tracé de lignes
    • Traitements hardware sur les caractères
      • Redimensionnement matériel (jusqu'à 16x)
      • L'effet Italique
    • Autres fonctionnalités
    • et… concrètement ?
    • Est-ce vraiment le premier GPU ?
• Et le libre dans tout ça ?
• Le 365 a-t-il fait un flop ?

Généalogie des puces EFxxxx

Un GPU est un composant informatique (une puce dédiée dans les cartes graphiques des PC ou intégrée au processeur central (CPU) de votre téléphone (soc)) initialement dédiée à l'affichage d'images.

D'abord limité à l'affichage 2D, il a rapidement pris le relais du CPU pour gérer les calculs parallèles de la 3D. Aujourd'hui, cette puissance brute sert autant au traitement vidéo qu'à des domaines bien éloignés des pixels, comme le minage de cryptomonnaies ou l'IA.

Cette bascule technologique a récemment propulsé nVidia, le principal acteur du marché, au sommet de l'économie mondiale.

Pourtant, bien avant cette folie financière et les géants américains ou asiatiques, c'est en France qu'est née cette architecture moderne.

Cette dépêche vous propose de découvrir l'histoire du 365, le premier GPU sur puce unique.

La génèse

Philippe Matherat avait résumé ainsi le contexte de cette épopée dans l'article de PulkoMandy :

Nous étions une bande de copains, élèves de l’Ecole Normale Supérieure, de la promotion 1973.

L’informatique était balbutiante, les ordinateurs étaient gigantesques (un bâtiment), très rares et très chers. Personne n’envisageait qu’ils puissent être répandus et bon marché.
Les seuls écrans connus étaient ceux de la télévision. Les terminaux informatiques étaient des machines à écrire mécaniques actionnées par des relais électromécaniques. Ces terminaux étaient reliés à des gros ordinateurs distants, par une ligne téléphonique dédiée.
La fréquence d'horloge des ordinateurs les plus puissants était 12 MHz.

Jean Gastinel était le seul de notre promotion qui connaissait un peu ce qui se passait aux Etats-Unis, grâce à son père : Noël Gastinel, qui était professeur à Grenoble et qui avait fait des voyages dans les universités américaines et chez IBM. Il avait fait équiper l’université de Grenoble d’un ordinateur IBM 360/68.
Jean Gastinel, avec Jean-Marc Frailong et Jean-Luc Richier, ont réalisé un ordinateur 12 bits, à base de circuits MSI de Texas-Instruments, dans les années 1973-1975.

Puis Jean-Gastinel s’est lancé dans la conception du circuit d’affichage alpha-numérique, qui a été commercialisé sous le nom de SFF364 puis EF9364 (le changement de nom correspond au changement de nom de la société Sescosem en EFCIS). Cette conception a fait l’objet de sa thèse de 3è cycle.

Depuis cet article, P. Matherat a détaillé :

Quand je suis entré à l’ENS en 1973, il n’y avait pas de labo d’informatique, ni d’électronique. Les disciplines (en sciences) étaient les disciplines classiques de l’université : mathématique, physique, chimie, biologie, etc. Les chercheurs et les élèves avaient accès à un "Centre de calcul", dirigé par Maurice Vallino, qui consistait en un terminal (lecteur de cartes perforée et imprimante) connecté à un ordinateur Univac de l’université d’Orsay par une ligne à 1.200 bits/s, puis plus tard équipé d’un mini-ordinateur CII Mitra 15. Nous avons eu des cours de programmation Fortran par Jacques Arsac. Nous avions aussi accès à une formation en électronique (analogique), dans un local du labo de physique, fait par F. Lenouvel.

Quand Jean Gastinel a souhaité réaliser un ordinateur, associé à J-M Frailong et J-L Richier, ils sont allés à Jussieu, à l’institut de programmation, où il y avait une équipe qui réalisait des montages électroniques, dirigée par Gérard Noguez. Puis, ils ont souhaité continuer à l’ENS, et M. Vallino leur a cédé une petite pièce annexe du Centre de calcul, ainsi qu’un petit budget annuel de 10.000 F. C’est dans cette pièce que Jean a réalisé la maquette du 364, puis j’ai continué là avec la maquette du 365.

Ce que nous appelions "maquette" était le câblage d'une émulation de la future puce à l'aide de circuits MSI existants (des centaines), afin de pouvoir tester en temps réel la conception logique. Il n'existait aucun outil de CAO. Tout était câblé à la main, sans simulation préalable, et notre principal outil était l'oscilloscope pour vérifier les signaux. Avec des fréquences de l'ordre de quelques MHz, il nous fallait un oscilloscope haut de gamme.

Une question de mémoire

Sans la capacité d'Intel à produire en masse des puces DRAM de plus en plus denses, le 365 n'aurait jamais pu exister :

À la suite du 364, j’ai pensé qu’on pouvait faire du graphique : j'ai commencé cette étude en 1976, à l'occasion de mon DEA d'informatique. Il faut bien voir que ceci n’est devenu possible que grâce aux nouvelles mémoires de 4 Kbits, car un affichage 512 x 512 à 1 bit/pixel nécessite 64 boîtiers mémoires de 4 Kbits. En fait cela ne devient raisonnable qu’avec 16 boîtiers de 16 Kbits (soit 32 K octets). Il n’était donc pas possible de faire un GPU avant ces années-là. Mon mérite a été d’avoir le flair de voir qu’une période nouvelle pouvait s’ouvrir, et que les écrans graphiques pouvaient se démocratiser.

Mais utiliser 32 K octets rien que pour l'écran paraissait délirant, à une époque où la mémoire "centrale" utilisée par le CPU pour son programme et ses données ne dépassait pas 4 ou 8 K octets. Quand à vouloir faire de la couleur avec 3 bits par pixel, là j'étais vraiment pris pour un fou. Songez qu'un adressage sur 16 bits (cas des microprocesseurs de l'époque) ne permet pas de dépasser 64 K (= 2¹⁶ ).

Notez bien que, à l'époque, la capacité de ces mémoires s'exprime en bits (non pas en octets), et par un simple « K » : ce k majuscule vaut 1 024 bits (le kibibit actuel) et non 1 000. Pour résumer et par exemple, il faut traduire 16K par 2 kio.

Pourquoi cette augmentation de la capacité de la RAM à cette époque ?

Les circuits de RAM nécessitent un très grand nombre de transistors, mais sont très répétitifs : ils coûtent donc relativement peu cher à concevoir, mais demandent une chaîne de production de semi-conducteurs de très bonne qualité. Les fabricants de semi-conducteurs Japonais sont ceux qui vont le mieux maîtriser ce type de produit, fournissant des composants de plus en plus grande capacité à des prix écrasant la concurrence américaine. Intel ne s'en remettra qu'avec de grosses difficultés. Un autre fondeur de RAM américain, Mostek, n'y survivra pas et sera revendu à Thomson-CSF, qui rentabilisera largement son investissement en exploitant les brevets ainsi rachetés.

Le plastique, c'est fantastique

En creusant le sujet de ces premières mémoires vives, on comprend qu'il y a eu une autre évolution importante : le choix du matériau pour le boîtier.

Les boîtiers des premiers CI (dont la référence est préfixée par "C" ou "D") étaient en céramique : c'était coûteux mais dans les début des années 70 seul ce matériau répondait aux besoins de dissipation thermique et d'étanchéité.
Au départ, les fabricants avaient du mal à stabiliser le plastique, car l'humidité finissait par s'infiltrer par capillarité le long des pattes en métal, provoquant la corrosion de la puce.
Pour protéger la puce, il lui a été ajouté une couche (au nitrure de silicium), dite "de passivation", qui permet le contact avec le plastique.
Plus tard dans la décennie (à partir des puces 16K soit vers 1977), la transition vers le plastique s'opère massivement, leur référence est alors préfixée par "P".
Le moulage plastique a permis de produire des puces à la chaîne à un prix dérisoire par rapport au processus artisanal du boîtier céramique multicouche.

La production

L'histoire industrielle du fondeur

• 1969 : Création de Sescosem (Société Européenne de Semiconducteurs et de Microélectronique), filiale de Thomson-CSF.  
  Selon Wikipedia : Thomson-CSF est le résultat de la fusion réalisée en 1968, du groupe électronique Thomson (filiale de Thomson-Brandt) et de la Compagnie générale de télégraphie sans fil (CSF). Leurs filiales dédiées aux circuits intégrés, respectivement SESCO et COSEM, sont donc fusionnées pour devenir SESCOSEM.
• 1976 : Sescosem devient EFCIS (Étude et Fabrication de Circuits Intégrés Spéciaux). C'est à ce moment précis que la référence change : le SFF364 devient l'EF9364.
• 1983 : Thomson-CSF réorganise ses activités. EFCIS est intégrée au sein de la branche Thomson Semiconducteurs. C'est l'époque de la grande offensive sur le marché grand public avec le Minitel et les ordinateurs (Alice, VG5000) utilisant les dérivés comme l'EF9345.
• 1987 : Thomson Semiconducteurs fusionne avec la branche composants de l'italien SGS (Société Générale Semiconduttori). Naissance de SGS-Thomson Microelectronics.
• 1998 : SGS-Thomson est renommé STMicroelectronics (ST), le nom que nous connaissons aujourd'hui : une multinationale franco-italienne de droit néerlandais.

Dates de production

Chronologiquement, Sescosem ou EFCIS ne faisaient pas de tels chips pour écrans avant que les élèves de l’ENS lui en apportent :

• En premier, Jean Gastinel a conçu le circuit alphanumérique EF9364, de 16 lignes de 64 caractères, qui est sorti vers 1977.
• Ensuite, j’ai conçu le premier chip graphique EF9365, de 512x512 pixels, qui est sorti vers 1980, avec sa variante EF9366 (balayage non-entrelacé).
• Le circuit 9367 est une variante du 9365, avec des performances augmentées.
• Les circuits du genre 9345 sont postérieurs au 9365, ils utilisent les éléments de base des circuits précédents, et ont été demandés par les concepteurs du minitel, qui sont donc des copies, variantes, des circuits conçus par les élèves de l’ENS.

La petite famille

L'EF9364, le précurseur

L'année dernière, PulkoMandy a exhumé la thèse de Jean Gastinel "Conception et intégration d'un terminal alphanumérique", qui pose avant l'heure les bases du Minitel et qui est aussi à l'origine de l'aîné de la famille : l'EF9364 est un contrôleur vidéo purement alphanumérique (affichage de 16 lignes de 64 caractères).

Cette thèse est une véritable pépite pour les férus d’archéologie informatique, on y trouve notamment tous les détails sur la réalisation du CI :

Ce composant est prévu pour réaliser un terminal passif, sans microcontrôleur. Avant son arrivée, toute la logique vidéo des terminaux était implémentée par de la logique discrète: une centaine de puces électroniques étaient nécessaires. Les autres composants d'un terminal, comme le modem et le contrôleur de clavier, bénéficiaient déjà de solutions intégrées. Ce composant rend donc possible la construction d'un terminal à très bas coût avec quelques dizaines de composants.

Il implémente tout de même des fonctionnalités de défilement de l'affichage, de déplacement du curseur, et d'effacement partiel (tout l'écran visible, la ligne courante, depuis le curseur jusqu'à la fin de la ligne). Ces fonctionnalités sont similaires à ce qui se fait sur les terminaux de l'époque (VT52 chez DEC, ADM-3A, …). Cependant, les générations suivantes de terminaux à partir du VT100 choisiront plutôt d'utiliser un microprocesseur.

La génération des caractères proprement dit est effectuée par un composant séparé appelé générateur de caractères. Il s'agit dans le cas le plus simple d'une ROM programmée avec une police bitmap de taille fixe.

Pour les nostalgiques du rendu d'affichage alphanumérique (le seul proposé par cette puce) sur un écran de l'époque, vous pouvez essayer cool-retro-term (lien qui devrait être sponsorisé par le SNOF)

L'EF9365

Second de la famille, c'est l'objet de notre dépêche : voir la section suivante qui lui est dédiée.
Nous passons souvent sous silence le EF9366, qui est très proche du 365, mais les 2 sorties sont vraiment concomitantes.

En fait, les 9365 et 9366 sont sortis en même temps, c’est moi qui avais fait la modification qui supprime l’entrelacement (pour le 9366), car le premier client (Secapa), qui avait travaillé sur la maquette de simulation du 365, ne supportait pas le clignotement de l’affichage 512x512. Pour moi, l’intérêt était d’avoir une résolution élevée, et je conseillais d’utiliser un CRT avec des phosphores plus rémanents. Mais les CRT les moins chers (TV) avaient des phosphores rapides.

Nous passons aussi sous silence le EF9367, sorti plus tard, proche du 365 mais supportant des résolutions supérieures.

Le NEC µPD7220 : le cousin Japonais

Ce composant n'est pas compatible avec la série EF9365. Cependant, il a un fonctionnement assez similaire. Commercialisé en décembre 1981, il a été développé à partir de 1979, et probablement inspiré par la présentation du travail sur le 365 au SIGGRAPH en 1978.

En plus des lignes, rectanges et textes, il peut tracer des cercles, arc de cercles et autres courbes. Il est également prévu pour s'interfacer avec un contrôleur DMA, ce qui facilite l'échange de données avec le CPU de contrôle.

Le design de NEC a également été produit par Intel, qui continuera à faire évoluer cette famille de composants. C'est donc un ancêtre des GPU Intel toujours en production aujourd'hui.

L'EF9340 et 9341

Ces deux composants sont au cœur des premiers modèles de Minitel, il s'agit d'une adaptation "low cost" et d'un retour au mode alphanumérique. Ils sont conçus en 1980-1981.

Les premiers prototypes du Minitel utilisent des circuits de chez TI (que l'on retrouvera également dans l'ordinateur Exelvision EXL100). Mais les modèles de production se tournent vers une solution "made in France". Thomson EFCIS se charge de la conception de ces circuits qui sont fournis à Alcatel pour la fabrication du Minitel.

Réponse à appel d'offre du Minitel mentionnant les circuits VIN et GEN : la visualisation est confiée à deux circuits spécialisés VIN et GEN, chargés des signaux de base de temps et de la synthèse des caractères.

Ils sont associés à un microprocesseur, faisant du Minitel un terminal "intelligent" capable de réaliser certaines fonctions en autonomie, sans avoir besoin de communiquer chaque appui de touche du clavier au serveur central.

Ils ajoutent également un mode "semi-graphique" : il ne permet pas d'afficher des pixels, mais propose des 'briques', de 2x3 éléments, pré-dessinées dans la ROM du processeur.
On économise ainsi drastiquement la RAM qui coûtait, déjà, cher…
Le prix unitaire d'une RAM Intel 2107 (de 4K, soit 512 octets) était, à sa sortie en 1974, de 50 $ => avec l'inflation cumulée et la conversion, cela représente environ 295€ de 2026.

En plus du Minitel, ces composants seront également utilisés par Philips dans les consoles Videopac Plus, ce qui sera la première étape dans la conception du VG5000 dont on reparle au chapitre suivant.

L'EF9345, la cheap chip

Le composant EF9345 regroupe dans une seule puce les fonctionnalités du générateur de caractères et du contrôleur de timing vidéo (GEN et VIN, qui étaient auparavant deux composants séparés).
Cette photo zoomable du cœur de silicium du composant (die shot) montre bien cet assemblage.
Cela a permis de réduire le coût de production du Minitel et a également été utilisé dans quelques micro-ordinateurs personnels : l’Alice chez Matra ou le VG5000 chez Philips.

Ici, la puce ne sait pas ce qu'est un pixel : elle manipule une grille de caractères (25 lignes de 40 ou 80 colonnes).

Pour afficher une lettre ou un bloc de couleur (le fameux mode mosaïque), le processeur principal envoie juste un code d'un octet en RAM. C'est une ROM interne à la puce d'affichage qui se charge ensuite de traduire cet octet en points lumineux à l'écran.

C’était une astuce pour économiser la mémoire, mais impossible de tracer une ligne fine ou de faire bouger un élément au pixel près : on est condamnés à déplacer des blocs rigides sur une grille fixe. Au mieux, certains caractères peuvent être redéfinis, pour afficher un logo ou une image simple.

La suite pour ST

Pour ST Microelectronics, l'histoire des composants graphiques continue encore quelques années après la commercialisation de la série EF936x. Bien que les composants graphiques n'ont pas eu le volume de production de la version alphanumérique (surtout portée par le Minitel), ils ont trouvé une utilisation dans l'informatique scientifique et les appareils de mesure nécessitant la visualisation de données : spectromètres, analyseurs de spectre, ainsi que des réalisations spécifiques (cartes graphiques en kit Elektor pour machines CP/M à bus S-100).

L'offre sera complétée par l'EF9369, un circuit permettant de gérer une palette de 16 couleurs parmi 4096. Ce circuit est conçu au départ pour le micro-ordinateur Thomson TO9, mais finit par rejoindre le catalogue public de EFCIS puis de SGS-Thomson.

En parallèle, SESCOSEM avait signé un contrat avec Motorola lui permettant de produire en France des composants conçus par Motorola (permettant de rassurer les acheteurs qu'il s'agissait de productions locales). SGS-Thomson se retrouve donc à produire à la fois la famille 93xx mais aussi le EF6845, le contrôleur d'écran de la famille 68xx de Motorola. Ce contrat devait comprendre toutes les futures puces de la famille 68xx conçues par Motorola, mais cela finira mal, puisque Motorola refusera de fournir les masques nécessaires à la production du processeur 68020.

En fonction des demandes de clients, de nouveaux composants sont réalisés avec des adaptations simples (changement de timings vidéo pour afficher plus de pixels) ou plus poussés. C'est le cas de la famille TS68483 (surnommé AGAC, Advanced Graphic and Alphanumeric Controller) disponible en 1987.

Il s'agit d'une version améliorée du 9365 avec:

• une interface 16 bits avec le processeur, adapté à l'utilisation avec un 68000 par exemple.
• Des fonctions supplémentaires : tracé de courbes, cercles, remplissage de zones…
• Meilleure intégration : il n'y a plus besoin d'un séquenceur et de registres à décalage externes.
• Configuration logicielle de la résolution d'écran vidéo

Ce composant trouve également une utilisation dans des systèmes militaires, pour lesquels il existe une version "durcie", plus résistante (gamme de températures acceptables par exemple).

Plus tard (en 1995-1997), c'est également ST qui fabrique les premières puces conçues par nVidia: NV1 STG2000 puis RIVA 128. Pour la première, le principe est similaire à ce qui avait été fait pour le EF9365 : ST assure la production et la commercialisation en son nom propre (on trouve donc des datasheets ne mentionnant pas du tout nVidia). Pour la seconde génération, ST ne se charge que de la fabrication, les datasheets (et les puces elle-mêmes) font apparaître les logos des deux entreprises. Malheureusement pour ST, ce partenariat n'ira pas plus loin, et les puces nVidia des générations suivantes seront produites exclusivement par TSMC.

Le génie de l'EF9365

Un vrai framebuffer

Ce composant ne se limite plus à une RAM de stockage des caractères, il dispose d'une RAM de pixels dédiée (le framebuffer) qu'il gère de manière autonome.

De ce point de vue c’est vraiment le premier chip qu’on peut qualifier de "graphique", car les autres étaient appelés "alphanumériques" ou "alpha-mosaïques".

La grosse différence entre les deux est que "graphique" suppose de pouvoir accéder à un pixel particulier, alors que les autres n’accèdent qu’à un "caractère", les pixels d’un caractère étant définis secondairement par une ROM.

Autrement dit, la RAM d’un chip graphique est une RAM de pixels (beaucoup plus grosse, par exemple 512x512), alors que dans le cas alpha-xxx c’est une RAM de caractères (16x80 par exemple).

Il faut bien voir que cette chronologie est liée à la sortie des puces mémoires de Intel : Les puces de 4 K bits ne sont apparues que vers 1974. Avant, il était impossible de faire du vrai "graphique". Il aurait été trop compliqué de stocker chaque point de l’image individuellement : en télévision, le signal vidéo était analogique, et les magnétoscopes à bande magnétique enregistraient le signal video analogique.

L'idée de stocker une image matricielle (point par point) dans une mémoire vive pour l'afficher à l'écran n'était pas nouvelle (par exemple: Evans & Sutherland Shaded Picture System qui faisait déjà du rendu 3D en 1973, premiers "frame buffers" dès 1969 chez Bell Labs, mais ce sont des solutions complexes et coûteuses). On peut également mentionner le CDP1861 de chez RCA: il s'agit d'un framebuffer mais avec une résolution de seulement 64x128 pixels (et encore, il est parfois exploité en 32x64 pixels pour économiser de la mémoire). L'EF9365 marque une rupture historique : c'est le premier processeur graphique commercialisé de manière monolithique (sur une seule puce) conçu pour piloter un framebuffer géométrique de manière autonome. Il gère non seulement le framebuffer et l'affichage à l'écran, mais aussi des fonctions de tracé de lignes et de caractères. C'est donc le premier processeur graphique à proposer une forme d'accélération matérielle sur un système à framebuffer.

L'actualisation de l'image à l'écran utilise seulement 57 % du temps (64 cycles sur 112 cycles de l'horloge externe continue).
Le temps restant est libre pour l'écriture et la mise à jour de l'image : il est possible d'écrire un point par cycle libre, ce qui donne un temps moyen de 1,3 µs par point. Dans les cas où il y a beaucoup d'informations à afficher d'un coup, il est également possible de désactiver l'affichage pendant la préparation de l'image puis de le réactiver ensuite. Malheureusement, cela ne se prête pas trop à la réalisation d'animations complexes.

La décharge du CPU pour certaines tâches

C'est ce qui définit ce composant comme le premier GPU de l'histoire : son auteur lui a câblé des registres pour prendre en charge des fonctionnalités qui déchargent le CPU (processeur central) sur des opérations graphiques !

Exemples de programmes en langage MPL qui montrent la simplicité d'utilisation

Le tracé de lignes

Le CPU peut par exemple demander à l'EF9365 de dessiner un trait d'un point A à un point B et revenir aussitôt à sa tâche. L'EF9365 prend alors le relais de manière totalement autonome. Il calcule les coordonnées intermédiaires en interne et écrit directement les pixels en RAM, à une vitesse folle pour l’époque : jusqu'à un million et demi de points par seconde, traçant une diagonale complète en moins de 700 microsecondes.

Traitements hardware sur les caractères

Auparavant, pour doubler la taille d'une police ou d'un motif, on demandait au processeur principal de recalculer tous les points. L'EF9365, lui, gère cela en toute autonomie via deux registres internes dédiés aux facteurs d'échelle : CZX (Zoom en X) et CZY (Zoom en Y).

Le processeur graphique possède un compteur de pas pour dessiner le caractère pixel par pixel à partir de sa ROM interne.
Quand le zoom est activé (par exemple à 4×), au lieu d'incrémenter l'adresse de destination dans le framebuffer à chaque pixel lu, l'EF9365 va répéter la même valeur de pixel sur la ligne 4 fois de suite en horizontal avant de passer au pixel suivant. Pour la verticale, il va répéter la même ligne complète du caractère 4 fois de suite dans la mémoire d'écran.

L'avantage : comme les zooms X et Y sont indépendants, on peut appliquer un zoom 2× en largeur et 4× en hauteur. Cela permettait de faire instantanément des effets de texte étiré, condensé ou géant sans aucun calcul pour le CPU.

L'inclinaison n'est pas stockée dans une ROM ; elle est calculée « à la volée » lors de l'écriture dans la RAM de pixels.
Pour incliner un bloc de pixels, il faut appliquer un décalage horizontal progressif à mesure que l'on monte en hauteur.
À chaque fois que le générateur passe à la ligne supérieure (Y+1) pour dessiner le caractère, il ajoute automatiquement un offset fixe (un décalage d'un pixel) sur l'axe horizontal (X).

Le caractère est littéralement « cisaillé » géométriquement pendant qu'il est écrit dans le framebuffer. On obtient un effet italique parfait et fluide, directement câblé dans le silicium.

La seule inclinaison possible est 45 degrés (voir la notice page 21).
C’est beaucoup plus simple ainsi à réaliser en hardware. Je m’étais posé la question de faire tous les angles, mais j’avais abandonné.

Autres fonctionnalités

L'EF9365 marque d'autres évolutions technologiques novatrices…

Il intègre notamment un mécanisme de masquage d'écriture par plan.
En verrouillant certains plans de la RAM, il pouvait dessiner ou effacer des éléments au pixel près sans jamais altérer le fond de l'image, jetant les bases de la gestion matérielle des calques.

Il propose un module de pointillés gérés au pixel individuel (une aubaine pour la CAO industrielle).

Son interface de bus universelle est capable de dialoguer nativement aussi bien avec un Z80 qu'un Motorola 6809.

et… concrètement ?

Jean-François Del Nero a produit une démonstration des capacités de rendu du 365 sur le Squale, un micro-ordinateur de 1984 qui exploitait ce composant.
Ci-après quelques extraits, très saccadés (export gif oblige), presque fidèles (cherchez l'intrus !) :

En plus de son travail de conservation du Squale, avec l'association MO5.com (qui tient un musée permanent du jeu vidéo à Arcueil), Jean-François Del Nero a aussi contribué à son émulation dans le projet Mame, et a notamment écrit le driver du 365.
Nous avons pu reprendre le code source de sa démo, la modifier, la recompiler, et simuler le rendu du 365 grâce à Mame. Avis aux développeurs fullstack en manque d'exotisme: ici, pas de conteneurs Docker ni de dépendances npm !

Est-ce vraiment le premier GPU ?

Nous avons retenu les quatre critères suivants pour distinguer le 365 des premiers contrôleurs d'affichage sur une seule puce, comme le Motorola 6845 ou l'Atari Antic, qui gèrent la synchronisation du flux vidéo et le rafraîchissement de l'écran, sans intervenir dans le dessin des formes.
Le processeur 365 :

1. est une puce unique (LSI/VLSI) : ce n'est pas une carte remplie de circuits TTL discrets comme sur les gros systèmes vectoriels des années 70 (Evans & Sutherland, Imlac) ;
2. déleste le CPU de tâches coûteuses en ressources : le CPU n'écrit pas les pixels un par un en VRAM. Il envoie une commande de haut niveau au 365 telle que : « trace une ligne de (X1,Y1) à (X2,Y2) », et repasse à autre chose ;
3. dispose d'un moteur d'exécution algorithmique dédié, hardware (en silicium) : il embarque en dur l'algorithme de tracé/moteur de rendu (rasterizer) ;
4. gère en toute indépendance la mémoire vidéo (Framebuffer/VRAM) : le 365 contrôle l'accès, le rafraîchissement et la modification de la VRAM de façon indépendante.

Et le libre dans tout ça ?

Quittons la technique pour nous intéresser à un autre aspect des travaux de l'équipe : la diffusion de ses travaux.

Vous pourriez être étonnés qu’un circuit produit par un industriel puisse être public, dans ses moindres détails. Je dois vous raconter une anecdote :

Notre petit groupe d’élèves de l’Ecole Normale Supérieure considérait que ses productions, financées par les pouvoirs publics, devaient profiter à tout le monde. Mais cela posait un problème à l’industriel (Thomson-CSF qui avait pour filiale la société Thomson-EFCIS), qui voulait protéger son produit par des brevets. Il a été convenu que Thomson-CSF déposerait des brevets au plus tard la veille de ma soutenance de thèse. Ainsi, les brevets pouvaient être valides car ne portaient pas sur un design public.

Ma thèse a été soutenue le 19 mai 1978, et les brevets avaient été déposés le 18 mai (US4286264, US4297694, US4311998, US4266253).
Ils décrivent aussi en détails le fonctionnement du circuit, mais dans le langage juridique spécifique des brevets.

En août de la même année, l'architecture du 365 est présentée lors de la conférence SIGGRAPH 78. La liste d'articles soumis à cette conférence permet de se faire une idée des évolutions en cours dans le monde des graphismes générés par ordinateur à l'époque. On y trouve la description d'autres systèmes matériels et logiciels, des algorithmes en 2D ("How to color in a coloring book", un algorithme de remplissage de zones délimitées par des traits) et en 3D, des discussions sur les choix d'espaces de couleurs, ainsi que des exemples de mises en application (par exemple pour les simulateurs de vol de la navette spatiale américaine).

Ensuite, EFCIS a beaucoup utilisé le dessin des masques du 365 pour sa communication car c’était le seul design qui était public.
Nous n’étions pas dans l’état d’esprit de créer une start-up autour de nos designs, dans le but de gagner de l'argent. Nous nous imaginions qu’il était possible de concevoir des circuits dans un contexte académique, en étant juste payés par nos salaires, puis de les céder à un industriel pour la suite. C’était une erreur car ça ne pouvait pas fonctionner, principalement parce que l’industriel a besoin de définir sa stratégie de ligne de produits avec ses arguments marketing.
Le contrat passé entre EFCIS et l’Ecole Normale Supérieure a servi à rémunérer l’ENS, qui s’en est servi pour créer le premier labo d’Informatique de l’ENS (le LIE), et je n’ai rien reçu personnellement. Je considérais que j’avais été payé par mon salaire d’élève de l’ENS.

Dans les années 1970, nous avions l’idée naïve que les innovations techniques entraînaient des innovations sociales au sens d’une amélioration des conditions de vie pour tous, à l’image de la bagnole qui s’était démocratisée et qui était synonyme de libération. Nous ne faisions pas de grande différence entre acteurs publics et acteurs privés, et nous avions l’impression que tout était publié, ne serait-ce que par les brevets, qui ne faisaient que protéger ceux qui avaient davantage investi. En revanche, nous étions sensibles à la question de la propriété industrielle, et nous pensions que ce qui avait été développé par des fonctionnaires était la propriété de l’état (ce qui d’ailleurs est la loi), et que les universitaires ne pouvaient que publier sans restrictions. (En tant qu'élèves de l’ENS, nous étions fonctionnaires et universitaires.)…

Le 365 a-t-il fait un flop ?

Clairement non, car l'EF9365 ne mesure pas ses performances en FLOPS (Floating-point Operations Per Second) : il ne manipule aucune virgule flottante (ni même de calculs en nombres réels).
Blague d'informaticien mise à part, le 365 a certes ouvert la voie à une longue lignée de composants, qui domine aujourd'hui l'actualité de la tech, mais il n'a pas eu le succès commercial de ses descendants, et l'expérience de la rue d'Ulm a tourné court.

En France et à l'époque, il était difficile de faire dialoguer recherche, industrie et financement public.

…Mais nous n’avions pas compris les particularités de ce secteur. D’une part, les usines qui fabriquent des circuits intégrés coûtent extrêmement cher. D’autre part ce secteur était appelé à un développement exponentiel, non anticipé : la plupart des hauts responsables de l’époque pensaient que les ordinateurs seraient achetés par 100 entreprises, voire 1000, mais ne concerneraient pas le grand public. Ensuite, le coût des développements logiciels devenait lui aussi très élevé. À l’époque les plus gros logiciels n’étaient pas très complexes. Et on n’avait pas compris la relation étroite entre les logiciels et les architectures matérielles. On n’avait pas compris non plus que de prendre un monopole sur un OS était un enjeu stratégique.

Toutes ces contraintes (et d’autres que j’oublie), que nous n’avions pas comprises, faisaient que nous pensions naïvement que nous pouvions faire un développement dans notre coin, sans nous occuper du marché, mais uniquement de la performance technique, et le publier, puis dans un second temps le proposer à un industriel qui aurait les moyens de le commercialiser. L’idée sous-jacente étant que si le design était performant alors il y aurait forcément un industriel pour le vendre. C’était une grande ignorance des contraintes industrielles et des questions de marketing.

Le cœur du problème ne résidait pas dans un manque de compétences (le génie des étudiants de l'ENS en est la preuve) mais dans l'incapacité des grands capitaines d'industrie français (notamment chez Thomson) à anticiper la révolution de l'ordinateur personnel et du logiciel. Confortés dans leur monopole, ils ont ignoré le virage que les États-Unis et le Japon prenaient à pleine vitesse :

Je pense maintenant que dans le contexte des années 1970-80 en France, il n’y avait pas vraiment de possibilité pour aller plus loin. Les deux milieux, universitaires et industriels, ne se parlaient vraiment pas. Personne en France, ni chez les gouvernants, ni chez les universitaires, ni chez les industriels, ne voyaient ce qui se préparait. Nous, à 20-25 ans, nous comprenions le retard technologique de la France, ne serait-ce qu'en lisant les docs des puces que nous achetions, mais il était nié par les plus hauts responsables. Les dirigeants de Thomson disaient : "Quand il y aura vraiment un marché pour ça, nous serons en mesure de produire".

En 1984, lors d'un voyage aux États-Unis et d'une visite au mythique Xerox PARC, le chercheur français découvre un autre monde. Un monde où l'innovation de rupture n'est pas confinée aux laboratoires, mais propulsée par le capital-risque, les pépinières d'entreprises et une compréhension systémique du couple matériel/logiciel :

À un moment, au début des années 80, nous parlions avec Gastinel de monter notre boîte. Mais nous étions incompétents pour ça, nous n’avions aucune conscience des difficultés, il n’y avait pas du tout l’esprit "start-up", le capital-risque n’existait pas, les pépinières d’entreprises n’existaient pas, nous n’avions aucune connaissance de la façon dont les boîtes pouvaient se créer et croître aux USAs, nous n’avons appris ce contexte que beaucoup plus tard.

Je suis allé aux USAs en 1984 pour la conférence Siggraph (à Minneapolis) et à cette occasion après je suis passé à Xerox-Parc où j’avais un ami français (Louis Monier, plus tard créateur de Altavista chez DEC). J’y ai découvert un monde insoupçonné chez nous, avec toutes leurs innovations depuis 20 ans, et j’ai rapporté leurs publications. Pourtant cela était connu (mais pas par nous), c’était à la base du Lisa et du Macintosh de Apple, sorti cette année-là. À Parc, j’y ai rencontré Franck Crow, un anglais, un grand nom du graphique (connu en particulier pour l’anti-aliasing) qui m’a félicité pour le 365, je n’en revenais pas. J’ai compris après qu’il avait été un reviewer pour mon article de 1978, avec un avis très favorable. En 1984, il avait connaissance du minitel, sorti peu avant, et m’a dit : "Nous aux USAs, nous n’avons pas été capables de faire ça". Il faut dire que c’était avant qu’Internet se répande, avec des possibilités infiniment supérieures. Internet existait depuis plusieurs années chez Xerox, mais ne pouvait pas se répandre dans le grand public avant l’existence des ordinateurs individuels.

Les pouvoirs publics français se sont parfois immiscés dans ces choix industriels : citons la nationalisation de Thomson-CSF en 1982 et le plan "Informatique pour tous" en 1985 (un investissement énorme, estimé à 1,8 milliard de francs, soit 600 millions d'euros rapportés à aujourd'hui). Pourtant, la théorie du ruissellement n'a pas très bien fonctionné alors avec les labos de recherche ou les pépites industrielles en devenir : en témoignent le départ d'une grande partie de la bande de copains vers les US ou l'échec du Squale, dont la production s'est limitée à quelques centaines d'unités.
La capitalisation boursière de STMicroelectronics (ex-SGS-Thomson) est, en 2026, 70 fois inférieure à celle de nVidia.

En fait je crois que en France, à cette époque, les choses ne pouvaient venir que d’en haut : le nucléaire, le concorde, le minitel. Le minitel a été réalisé par des gens du corps des mines et du corps des télécom (comme son nom l’indique). les choses ne pouvaient venir que des grands corps de l’état.
Notre activité, initiée par Jean Gastinel, était plutôt folle par sa liberté, et transgessive. Le climat à l’ENS, peu après 1968 où cette école avait été au cœur des événements, était très libre, nous avions vraiment la possibilité de faire n’importe quoi, sans contrôle. Jean avait entendu parler par son père de ce qui se passait aux USAs. Et ce qui se passait en Silicon-valley aussi était fait dans un cadre très libre lié à la contre-culture des hippies (mais ça, nous ne le savions pas).

Une anecdote : au début des années 80, nous avons développé un réseau local Ethernet (alors sur câble co-axial de gros diamètre), pour relier nos Thémis réalisées en 10 exemplaires. Et nous avons eu besoin de passer sous la rue d’Ulm pour connecter le laboratoire de biologie. C’était interdit par le monopole des télécoms. En outre, le protocole de transfert par paquets était refusé car concurrent du protocole des P&T. Il nous a fallu enfreindre la loi pour passer un câble en douce.
Tout ça a basculé peu de temps après, après l’explosion de l’usage des ordinateurs individuels et de leurs applications.

Pour être tout-à-fait honnête, et rendre à César…, je dois mentionner que notre équipe a été reconnue par le CNRS en 1982, où nous avons obtenu des postes et des crédits pour continuer. Il y a eu une croissance jusqu'à 10 personnes en 1985, mais la plupart des membres de l'équipe sont partis chez Xerox en 1986.

Avec le recul je dirais : on peut faire de grandes choses quand on est très peu nombreux, ça devient plus difficile lorsqu'il faut gérer la croissance…

Le hasard du calendrier a voulu que la publication de cette dépêche coïncide avec un anniversaire : il y a 50 ans débutait l'étude du 365, avec le DEA de P. Matherat :)
Pour celles et ceux qui s’intéresseraient à ses publications ou à la suite de ses travaux, c'est consultable ici.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Il existe deux façons de savoir combien il reste sur son compte : ouvrir vingt-six onglets de son tableur préféré, ou confier ses relevés à une application qui les enverra gentiment sur un serveur inconnu en échange d'un abonnement mensuel. Radinus propose une troisième voie, nettement moins tendance : un logiciel qui tourne sur votre machine, garde vos données sur votre disque, ne parle à personne, et ne vous demande rien. Libre sous GPL v3, écrit en Rust avec Tauri, disponible pour Linux, et gratuit — les deux à la fois, ce qui mérite qu'on s'y arrête.

NdM: il s'agit d'une réécriture d'une précédente version 1.9.3 en WinDev sous MIT. Le README dit « le dépôt est actuellement privé et sous la seule direction de son auteur » : on supposera qu'il ne s'agit pas d'accès privé ici sinon on ne verrait pas le code, mais juste du fait que l'auteur souhaite être en charge de tous les commits. Par contre la partie « sole direction of its (sic) author_ », tout en ayant une traduction en 18 langues, des commits non informatifs du type « maj1 » à « maj9 », etc. il est clair qu'il y a écriture ou assistance par une IA. Ainsi que pour le site du projet. Le projet initial date de juillet 2024 d'après le premier commit, et comme la date d'un commit n'est pas fiable, on peut vérifier le site du projet à la même époque via Archive.org (et l'absence du dépôt auparavant). Vous pourriez aussi trouver intéressantes les dépêches Logiciels libres pour la comptabilité d'entreprise (2025) et Logiciels libres de finances personnelles (2023).

• lien nᵒ 1 : Radinus
• lien nᵒ 2 : Code source Radinus

Ce qu'il fait

Plusieurs comptes bancaires, la saisie des opérations, le pointage et le rapprochement de vos relevés, l'importation des fichiers que votre banque met à disposition (OFX, CSV, tableurs), les chèques, les opérations périodiques, un budget annuel et son contrôle, six statistiques croisées, un tableau de bord et la courbe de vos soldes.

De la comptabilité domestique, faite sérieusement. Son nom vient de « radin » et sa mascotte est un écureuil en costume : le positionnement est assumé.

Libre et totalement, absolument gratuit !

Deux mots distincts, et ici les deux sont vrais.

Libre : GPL v3 ou ultérieure, sources publiques. La licence a été choisie pour que personne, pas même l'auteur, ne puisse refermer la porte plus tard.

Gratuit : pas de version amputée, pas de fonction réservée aux donateurs, pas d'abonnement, pas de compte, pas de courriel à laisser.

Et la liste de ce qu'il ne fait pas, qui vaut bien la première : aucune connexion à votre banque, aucune télémétrie, aucune publicité, aucune synchronisation. Le réseau ne sert qu'à une chose, ouvrir le site si vous cliquez dessus. Vos opérations vivent dans un fichier SQLite sur votre disque.

Sous le capot

Cœur métier et contrôleur en Rust, interface en HTML/CSS/TypeScript servie par Tauri v2. Tauri s'appuie sur WebKitGTK, le moteur déjà présent sur votre système, au lieu d'embarquer un navigateur complet : un binaire natif, pas de runtime à déployer, pas de Chromium par application.

Stockage SQLite en fichier unique, que vous pouvez copier et lire avec vos propres outils. Sauvegarde en zip avec un JSON par table. Chiffrement de la base par mot de passe si vous le souhaitez.

Pour Linux

Ubuntu 22.04, Debian 12, Fedora 36 ou plus récent.
Disponible en 18 langues (français, anglais, italien, espagnol, allemand…).

Bonne comptabilité personnelle , et pensez à pointer vos relevés.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Le sommet « Africa Forwards » des 11 et 12 mai derniers à Nairobi, a été considéré comme une réussite par Paris mais a été perçu sur place comme une réorientation de la « Françafrique », dont les objectifs restent les mêmes : l'influence et l'extractivisme. Reportage.

Depuis SPIP 4.4.18 l'utilisation des modèles est interdite par défaut dans les forums.
Si toutefois vous avez besoin d'utiliser ces modèles vous pouvez mettre la constante à false dans config/mes_options.php define('_FORUM_INTERDIRE_MODELES', false) ;

Découvrez la grande conférence annuelle des contributeurs du projet collaboratif de cartographie OpenStreetMap : State of the Map !
L'édition 2026 se déroulera pour la première fois en région parisienne, du 28 au 30 août à Champs-sur-Marne.

On vous explique tout avec Benoît Peyon, administrateur de l'association OSM France et membre du comité d'organisation.

Cet épisode est le premier d'un nouveau format (10 minutes), dédié à la présentation des conférences de l'univers du libre.

Bonne écoute !

• lien nᵒ 1 : Lien vers l'épisode
• lien nᵒ 2 : Site du State of the Map
• lien nᵒ 3 : Soutenir le podcast

Commentaires : voir le flux Atom ouvrir dans le navigateur

N. D. T. — Ceci est une traduction de la lettre d’information publiée régulièrement par l’équipe de communication de la XSF, essayant de conserver les tournures de phrase et l’esprit de l’original. Elle est réalisée et publiée conjointement sur les sites XMPP.org et LinuxFr.org selon une procédure définie.

Bienvenue dans la lettre d'information XMPP, ravi de vous retrouver ! Ce numéro couvre le mois de juin 2026.

La lettre d'information XMPP vous est proposée par l'Équipe de communication de la XSF.

Comme tout autre projet accompli par la XSF, la lettre d'information est le résultat du travail volontaire de ses membres et des personnes y contribuant. Si vous êtes satisfait des services et logiciels que vous utilisez peut-être, n'hésitez pas à dire merci ou aider ces projets.

Vous souhaitez contribuer à l'équipe de communication de la XSF ? Lisez en bas de page.

Sommaire

• Annonces de la XSF
  • XMPP Summit 29
  • Adhésions à la XSF
• Évènements XMPP
• Articles XMPP
• Nouvelles des logiciels XMPP
  • Clients et Applications XMPP
  • Serveurs XMPP
  • Bibliothèques et outils XMPP
• Extensions et spécifications
  • Extensions proposées
  • Nouvelles extensions
  • Extensions déférées
  • Extensions mises à jour
  • Dernier appel
  • Extensions stables
  • Extensions dépréciées
  • Extensions rejetées
• Partagez les nouvelles
  • Contributions et traductions de la lettre d'information
• Aidez-nous à créer la lettre d'information
• Licence

Annonces de la XSF

XMPP Summit 29

La XMPP Standards Foundation (XSF) a le plaisir d'annoncer le 29e Sommet XMPP, le premier à se dérouler entièrement en ligne ! Ce Sommet XMPP se tiendra du vendredi 4 septembre au samedi 5 septembre 2026, de 13 h à 16 h UTC ces deux jours. La XSF invite toutes les personnes intéressées par le développement des technologies XMPP à y participer à distance et discuter de tout ce qui concerne XMPP !

Adhésions à la XSF

Être membre élu de la XMPP Standards Foundation témoigne d’un engagement en faveur des normes ouvertes et d’une implication professionnelle au sein de ou avec la communauté XMPP. Votre adhésion contribue à faire de la XSF une organisation solide, ce qui est en soi précieux. Elle vous confère également un droit de vote sur les questions techniques et administratives au sein de la XSF. La procédure de candidature est simple et gratuite, et votre adhésion vous permettra également de vous impliquer plus facilement. Si vous souhaitez rejoindre la XMPP Standards Foundation en tant que membre, veuillez postuler à notre 3e appel trimestriel à candidatures avant le 16 août 2026 à 00h00 UTC.

Évènements XMPP

• Sprint XMPP à Berlin (DE / EN) : du vendredi 19 au dimanche 21 juin 2026, les développeurs ont eu de bonnes discussions, bien mangé et ont même codé ! Il y a eu du travail sur l'édition des messages dans Conversations, le partage de fichier sans état dans Dino, des corrections pour la prochaine publication de Kaidan, des améliorations OMEMO+PubSub dans Mellium, une grosse mise à jour du chiffrement du contenu des stanzas et son implémentation Slixmpp, et certaines corrections de paquets Debian. Un grand merci à @wikimediaDE de nous avoir hébergé une nouvelle fois ! Merveilleux endroit et gens sympas !

• XMPP et DI.DAY : dans le cadre du DI.DAY, une liste collaborative de salons « locaux » a été initiée. Cette liste est accessible sous forme d'une carte sur Umap OpenStreetMap ou sur Codeberg. Contributions bienvenues pour étendre la liste ou signaler des nouveaux salons sur le salon dédié mapofchannels@chat.yax.im, ou via Mastodon.

• XMPP à la PravConf 2026 : l'édition de cette année de la PravConf, une conférence sur les thèmes des logiciels et d'XMPP, est planifiée par la communauté de Prav les 4 et 5 juillet à Thiruvananthapuram en Inde. Elle sera suivie par le PravCamp les 6 et 7 juillet, un évènement sous forme de Sprint où les gens se rassemblent pour travailler ensemble sur Prav et autres sujets en lien avec XMPP. Ces 2 évènements ont lieu dans des campus étudiants et les étudiants pourront également découvrir XMPP. Apprenez en plus sur le site web.

• XMPP au FOSSY 2026 : FOSSY, la 4e conférence du "Free and Open Source Software Yearly", a publié sa liste complète des présentations sur la XMPP Track, contenant :

  • samedi 8 août, au MCLD 3038 :
    • Interopérabilité des messageries chiffrées avec des passerelles hybrides dans XMPP, par Marvin W. de 14:00 à 14:45 PDT.
    • Au-delà du chat : fournir des mini "apps" avec une belle interface utilisateur, par Stephen Paul Weber de 15:00 à 15:45 PDT.
    • "Beautiful XMPP Testing" revisité—How to Overcome the Mind-Body Duality by Staring at XML, par Phillip Davis de 16:30 à 17:15 PDT.
  • dimanche 9 août, au MCLD 3038 :
    • Quand les données deviennent lourdes : voix et vidéo pour les gros groupes, par Christopher Vollick de 10:45 à 11:30 PDT.
    • UnifiedPush - notifications Push. Décentralisé et Open Source, par Daniel Gultsch de 11:45 à 12:30 PDT.
    • Aventures lors de l'embarquement : Episode V - le serveur s'arrête, par Gideon Mayhak de 14:00 à 14:45 PDT.
    • Snikket : dans les coulisses de notre hébergement XMPP à la demande, par Matthew Wild de 15:00 à 15:45 PDT.

Articles XMPP

• Sortie de Openfire 5.1.0, par guus pour la communauté Ignite Realtime.
• Fluux Messenger 0.16.0 : chiffrement de bout en bout et Fluux Messenger 0.16.1 : corrections et améliorations pour les cas d'usage réels, par Mickaël Rémond pour le blog ProcessOne.
• 18 mois plus tard, par isadora pour le isaCloud diario-de-bordo. [PT_BR]
• Slidge v0.4.0beta "Spaces", pour le blog slidge.im.
• Movim 0.34 "Meier" est arrivé ainsi que Movim 0.31.4, par Timothée Jaussoin pour le blog Movim.
• Introduction à Tacky, un client XMPP pour le bureau construit en Tcl/Tk pour Linux et Windows avec le support moderne des appels A/V et chiffrement bout en bout OMEMO. Encore à l'état pré-alpha.
• Introduction à ffetcher, un robot XMPP qui surveille des flux RSS et Atom et poste les nouveaux articles dans un ou plusieurs salons. Il est spécialisé pour les sources du Fediverse. Le code a été généré par une IA et revu/testé par l'auteur.

Nouvelles des logiciels XMPP

Clients et Applications XMPP

• aTalk a publié les versions 6.1.0, 6.2.0 et 6.3.0 de sa messagerie sécurisée pour Android avec appels vidéo et fonctionnalités GPS. Ces versions introduisent la rétraction de message, retirent la fusion des messages multiples dans la fenêtre de chat, étendent la fonctionnalité de correction du dernier message à tous les messages envoyés et pas seulement au dernier message envoyé, supportent les traductions des messages envoyés/reçus dans les chats/salons avec l'option de traduction qui peut être activée par contact ou par salon, et apporte également des améliorations, quelques corrections mineures et beaucoup de modifications 'sous le capot'. Voir les notes de publication pour tous les détails.

• Conversations a publié sa version 2.20.1 pour Android. Cette publication ajoute les Note à moi-même comme suggestion de recherche et des corrections de bugs mineurs. Assurez-vous de consulter le journal des modifications pour tous les détails !

• Converse.js a publié sa version 14.0.0 de son client web XMPP open-source. Cette publication ajoute le support pour le chiffrement OMEMO:2 ! Elle apporte également des nouvelles méthodes pour l'API pubsub pour créér, s'abonner et se désabonner, support de la version logiciel et affichage des versions logiciels du serveur dans le profil, support d'OMEMO 2 (urn:xmpp:omemo:2) en utilisant la stanza content encryption, détecte les contacts supportant uniquement omemo:2 comme étant capable d'OMEMO, avec de nombreuses autres corrections et d'autres travaux sous le capot ! Tout ceci génère certaines incompatibilités rétroactives, donc merci de consulter directement le journal des modifications pour tous les détails !

• Fluux Messenger, a publié ses versions 0.16.0, 0.16.1 et 0.16.2 , de son client moderne XMPP multi-plateforme, pour les communautés et organisations. Ces versions ajoutent le chiffrement de bout-en-bout OpenPGP — le chiffrement des messages 1:1 avec un stockage de clé protégé par mot de passe et la sauvegarde/restauration de clé secrète, le support de OpenPGP e2ee dans la version web, la gestion des Multi-TSK (Transferable Secret Key) dans le flux de restauration des sauvegardes des comptes possédant plusieurs clés, marqueur de message non-lus sur l'avatar, rédiger des messages hors-ligne et les envoyer à la reconnexion, support des messages directs dans les salons ("chuchoter"), et bien d'autres modifications et corrections. Merci de consulter le journal des modifications intégral pour tous les détails !

• Gajim a publié sa version 2.4.7 de son application de chat XMPP gratuite et bourrée de fonctionnalités. Cette publication supporte le chiffrement OpenPGP moderne, les messages brouillons sont désormais persistants, ce qui signifie qu'après avoir redémarré Gajim, vous pouvez poursuivre là où vous vous êtes arrêté, les salons de discussion sont désormais nommés selon leurs participants si pas d'autre nom n'est donné, désactiver un compte lors de la connexion est désormais corrigé, et elle vient également avec de nombreuses petites améliorations et corrections de bugs. Merci pour toutes vos contributions !

• Movim a publié ses versions 0.34, nom de code "Meier", et 0.34.1! Ces nouveaux jalons Movim stabilisent le travail important réalisé dans les précédentes publications tout en introduisant une nouvelle expérience redesignée pour les appels de groupe (conférences). Dans cette version vous pouvez ajouter des salons dédiés à des appels de groupe dans vos Espaces ("Spaces") et explorer la nouvelle interface d'appel vidéo. Les appels en conférence, reconstruit depuis zéro, la renégotiation média, nouvel agencement et interface redesignée, nouveaux sons de notification, gestion de session, d'autres corrections et plus encore !

• Profanity a publié la version 0.18.2 de son client XMPP console. Cette publication apporte des corrections de bugs pour conserver l'écriture dans le terminal lors du passage en veille, éviter l'échange des OTR de révéler votre présence à des inconnus, et rendre muet l'erreur 'no key' pour les messages de transport de clé. Merci de consulter le journal des modifications pour tous les détails !

Serveurs XMPP

La communauté Ignite Realtime est heureuse d'annoncer la sortie d'Openfire 5.1.0. Quelques points forts de cette version : l'établissement de connexion via SASL (avec un généreux soutien de la Fondation NLnet), une série de durcissements concernant le chiffrement, la correction d'un bug de complexité O(n²) qui provoquait des démarrages de 2 heures sur de gros déploiements (seulement quelques secondes maintenant), Java 25, le nouveau support officiel de MariaDB, Firebird et CockroachDB. Vous pouvez lire le journal des changements complet pour avoir tous les détails !

Bibliothèques et outils XMPP

• go-sendxmpp, un outil pour envoyer des messages à un contact XMPP ou un MUC, inspiré par sendxmpp : la version 0.16.0 a été publiée. L'ensemble des détails dans le journal des modifications.
• go-xmpp versions 0.3.5 et 0.3.6 ont été publiées.
• jabber.el, le client XMPP pour Emacs, les versions 0.11.0 et 0.11.1 ont été publiées. L'ensemble des détails dans le journal des modifications.
• libomemo.js, une implémentation TypeScript du protocole OMEMO Multi-End Message and Object Encryption pour XMPP, les versions 1.0.0, 2.0.0, 2.0.1 et 2.0.2 ont été publiées. Cette bibliothèque supporte à la fois les versions 0.3.0, qui est supportée par la majorité des clients XMPP actuellement, et la dernière version 0.9.1 (également connue sous le nom OMEMO2 ou NEWMEMO). La liste des modifications est plus importante et contient plus de détails et informations sur les évolutions clées que ce qui peut être mentionné ici. L'ensemble des détails dans le journal des modifications !
• peertube-plugin-livechat, un greffon permettant de fournir un système de discussion pour les vidéos Peertube, les versions 14.0.3 et 14.0.4 ont été publiées. Vous pouvez lire les détails dans le journal des modifications !
• QXmpp, une bibliothèque multiplateforme client et serveur XMPP en C++, les versions 1.16.0 et 1.16.1 ont été publiées. Tous les détails dans le journal des modifications.
• slidge-whatsapp, la passerelle WhatsApp vers XMPP basée sur Slidge et whatsmeow, les versions 0.3.11 ont été publiées. Vous pouvez lire le journal des modifications intermédiaires depuis la version 0.3.11beta1 à 0.3.11 pour les détails.
• slixmpp, la blibliothèque XMPP sous licence MIT pour Python 3.7+ version 1.16.0 a été publiée. Cette version ajoute deux nouvelles XEPs ainsi que quelques changements internes. Vous pouvez lire l'annonce officielle de la version pour les détails. Incompatibilités : la méthode get_certs de la XEP-0257 est maintenant une méthode asynchrone ce qui casse la compatibilité avec les utilisations précédentes.
• strophejs, une bibliothèque JavaScript pour parler XMPP via BOSH (XEP-0124, XEP-0206) et WebSockets, la version 4.0.0 a été publiée. Vous pouvez lire l'intégralité du journal des modifications pour tous les détails.
• xmpp-dns, un outil en ligne de commande pour vérifier les enregistrements SRV XMPP, la version 0.6.3 a été publiée. Tous les détails dans le journal des modifications.
• xmpp-rs, a été publié:
  • minidom-0.19.0, une bibliothèque DOM assez spécifique à XMPP.
  • sasl-0.5.3, gère le protocole SASL.
• xmpppy, une bibliothèque Python dont le but est de fournir du scripting facile avec Jabber, la version 0.7.4 a été publiée. Tous les détails dans le journal des modifications.

Extensions et spécifications

La XMPP Standards Foundation développe des extensions à XMPP dans sa série de XEP en plus des RFC XMPP. Des développeuses, développeurs et autres personnes expertes en normes du monde entier collaborent à ces extensions, élaborant de nouvelles spécifications pour les pratiques émergentes et affinant les méthodes existantes. Proposées par n'importe qui, celles qui remportent le plus de succès finissent par être classées comme finales ou actives, selon leur type, tandis que les autres sont soigneusement archivées comme différées. Ce cycle de vie est décrit dans la XEP-0001, qui contient les définitions formelles et canoniques des types, des états et des processus. Vous pouvez en savoir plus sur le processus de normalisation ici. La communication autour des normes et des extensions se fait via la liste de diffusion des normes (archives en ligne).

Extensions proposées

Le processus de développement d'une XEP commence par la rédaction d'une idée et sa soumission à l'éditeur XMPP. Dans un délai de deux semaines, le Conseil décide d'accepter ou non cette proposition en tant que XEP expérimentale.

• Jingle User Location
  • Cette spécification définit une extension de l'application Jingle pour échanger et mettre à jour la position de l'utilisateur dans une session Jingle active en utilisant la XEP-0080 User Location payload.
• XMPP Decentralized ID (XID)
  • L'ID XMPP décentralisé (XID) est un identifiant d'entité XPMM indépendant de DNS. Cette spécification décrit comment générer, utiliser et gérer celui-ci.
• Jingle Synchronized Real-Time Text
  • Cette spécification définit l'extension d'une application Jingle pour la négociation temps réel du texte à l'intérieur de la même session de conversation que l'audio et la vidéo.

Nouvelles extensions

• Version 0.1.0 de XEP-0514 (Balisage d'Emojis)
  • Acceptée comme Expérimentale par vote du conseil le 12 mai 2026 (XEP Editor(dg))
• Version 0.1.0 de XEP-0515 (Protection contre la Dégradation de Connexion TLS)
  • Acceptée comme Expérimentale par vote du conseil (XEP Editor (dg))
• Version 0.1.0 de XEP-0516 (Identifiant XMPP Décentralisé (XID))
  • Acceptée comme Expérimentale par vote du conseil (XEP Editor (dg))
• Version 0.1.0 de XEP-0517 (Texte Synchronisé en Temps-Réel dans Jingle)
  • Acceptée comme Expérimentale par vote du conseil (XEP Editor (dg))

Extensions déférées

Si une XEP expérimentale n’est pas mise à jour pendant plus de douze mois, elle sera retirée de la catégorie Expérimentale pour être classée comme Déférée. Si une mise à jour intervient, la XEP sera replacée dans la catégorie Expérimentale.

• Pas de XEP déférée ce mois-ci.

Extensions mises à jour

• Version 1.35.5 de XEP-0045 (Discussions multi-utilisateurs)

  • Correction de l'attribut from dans les examples où le salon lui-même envoie un message
  • Corrige le champ du nom du noeud pubsub associé dans l'exemple d'information de découverte

• Version 0.5.0 de XEP-0420 (Stanza Content Encryption)

  • L'affixe de temps utilise le profile DateTime de XEP-0082
  • Les rpads longs NE DOIVENT PAS être rejetés
  • Ajout d'une taille cible minimum pour le complèment aléatoire pour renforcer la résistance face à des attaques par corrélation dans le cas de contenus courts et un rpad de longueur nulle.
  • Retrait de Implementation inutile
  • Avertissement concernant l'injection de stanzas déchiffrés
  • Clarifie la solution de repli pour le body
  • Corrige les descriptions pour s'appliquer à toutes les stanzas au lieu de seulement les messages
  • Retire le DOIT ambigu dans l'affixe de temps et clarifie la vérification des affixes
  • Exige du registrar de fournir une liste d'éléments exclusivement processé coté serveur
  • Liste les XEP dépendantes
  • Ajoute le schéma XML (syndace)

• Version 0.1.1 de XEP-0514 (Emoji Markup)

  • Retrait des références obsolètes à BoB (techmetx11)

Dernier appel

Les derniers appels sont lancés une fois que tout le monde semble satisfait de l'état actuel d'une XEP. Une fois que le Conseil a décidé que la XEP semble prête, l'Éditeur XMPP émet un dernier appel pour recueillir des commentaires. Les commentaires recueillis lors du dernier appel peuvent aider à améliorer la XEP avant de le renvoyer au Conseil pour qu'il passe à l'état Stable.

• Pas de dernier appel de XEP ce mois-ci.

Extensions stables

• Pas de XEP passant à stable ce mois.

Extensions dépréciées

• Pas de XEP dépréciée ce mois.

Extensions rejetées

• Pas de XEP rejetée ce mois.

Partagez les nouvelles

Veuillez partager cette nouvelle sur d'autres réseaux :

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Instance Lemmy (non officielle)
• Reddit (non officiel)
• Page Facebook XMPP (non officielle)

Consultez également notre flux RSS !

Vous recherchez des offres d'emploi ou souhaitez engager un consultant professionnel pour votre projet XMPP ? Consultez notre tableau d'affichage des offres d'emploi XMPP.

Contributions et traductions de la lettre d'information

Il s'agit d'un effort communautaire, et nous tenons à remercier les traductrices et traducteurs pour leur contribution.
Les bénévoles et les nouvelles langues sont les bienvenues !
Les traductions de la lettre d'information XMPP seront publiées ici (avec un certain retard) :

Contributions à la lettre d'information de ce mois-ci : emus, cal0pteryx, Gonzalo Raúl Nemmi, Ludovic Bocquet, anubis, Badri (badrihippo), XSF iTeam

Contributions à la traduction :

• Français : Adrien Bourmault (neox), anubis, seveso, impromptux, Blacknight
• Italien : Mario Sabatino, Roberto Resoli
• Portugais : Paulo

Aidez-nous à créer la lettre d'information

Cette lettre d'information XMPP est produite en collaboration avec la communauté XMPP. Chaque numéro mensuel est rédigé dans ce simple pad. À la fin de chaque mois, le contenu du pad est fusionné dans le dépôt GitHub de la XSF. Nous sommes toujours ravis d'accueillir de nouvelles personnes contributrices. N'hésitez pas à rejoindre la discussion dans notre groupe de discussion Comm-Team (MUC) et à nous aider ainsi à poursuivre cet effort communautaire. Vous avez un projet et souhaitez le faire connaître ? N'hésitez pas à partager vos actualités ou événements ici, et à les promouvoir auprès d'un large public.

Tâches que nous effectuons régulièrement :

• collecte d'actualités dans l'univers XMPP
• résumés courts d'actualités et d'événements
• résumé de la communication mensuelle sur les extensions (XEP)
• révision du projet de lettre d'information
• préparation d'images pour les médias
• traductions
• communication via les comptes des médias

Licence

Cette lettre d'information est publiée sous licence CC BY-SA.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Récemment, un nouveau service a fait son apparition sur le serveur CLUB1 : Un service de newsletter personnelle à disposition des membres.
Mais saviez-vous que c'est en fait une version améliorée d'un bout de code fait maison : celui utilisé pour la newsletter officielle de CLUB1 ?

Voici la petite histoire derrière ce service...

Newsletter origins

Lorsque l'on s'est posé la question des outils de communication pour Club1, on est vite arrivés à la conclusion que la forme newsletter (infolettre) avait un gros avantage : tout le monde a une adresse email.

De plus, comme club1 dispose de ses propres serveur email, c'était l'occasion de s'en servir.

Il existe des logiciels de newsletter, comme l'ancestral PHPList ou le spirituel ListMonk. On peut par exemple trouver des instances de ce dernier chez d'autres membres du collectif CHATONS. Mais bon, ce sont des instruments de marketing dont le vocabulaire ou l'usage forcé des statistiques, ne correspondent pas spécialement avec l'ambiance que l'on recherchait.

Une autre solution possible consiste à détourner un logiciel de mailing-list en newsletter, mais ça nous semblait pas si pratique, d'autant qu'on utilisait déjà un forum pour nos discussions.

Globalement, la plupart de ces solutions logicielles nous semblaient disproportionnées vis-à-vis de notre usage (à peine une centaine d'emails à contacter, moins de 10 fois par an). Jusqu'ici, on utilisait un fichier texte contenant les emails à copier-coller dans Thunderbird.

Finalement, on se décide d'explorer une dernière option : coder nous même un petit logiciel, un « script » comme on dit en informatique, qui fournirait un service hyper basic de newsletter.

Construction d'un outil

Voici les fonctionnalitées dont on a besoin pour notre newsletter basique :

1. stocker une liste d'emails
2. pouvoir envoyer un email à toutes les adresses de la liste
3. permettre aux gens de s'inscrire ou de se désinscrire automatiquement (sans passer par une action humaine)

Les points 1 et 2 sont assez simple à coder, ce qui est encouragant car c'est la base de toute newsletter. On (Vincent et Nicolas) entame le codage de cet outil via le langage de programmation Bash, pratique pour créer rapidement des petits outils de ce type. Voici quelques points qui font la particularité de ce projet :

• Compatibilité avec les outils POSIX
• MUI - Mail User Interface
• Détournement des fichiers .forward

Compatibilité avec les outils POSIX

Un des points de départ de ce logiciel était de stocker les adresses email d'une façon à ce qu'il soit très facile des les exporter ou modifier. On est donc partis sur un fichier brut, dont chaque nouvelle ligne contient une adresse. Ce fichier s'appelle emails et son contenu ressemble à ça :

Comme ça, si on veut modifier la liste, on peut l'ouvrir avec un éditeur de texte. Ça devient aussi très facile d'interagir avec les commandes POSIX.

Par exemple, on peut compter le nombre d'adresses inscrites avec :

wc signifie « Word Count », soit « compter les mots » et -l veut dire « lines », soit : « compte les lignes aux lieu des mots ».

MUI - Mail User Interface

Vous connaissiez peut-être déjà les GUI pour Graphical User Interface (quand on utilise un écran et une souris pour cliquer sur des boutons), ou encore les TUI pour Terminal User Interface, les interface utilisant le terminal.

Pour ce projet, nous avons fait le choix d'une MUI (Mail User Interface). Une interface de logiciel qui se fait uniquement à travers les Email. Bon, en vrai, ce terme n'existe pas vraiment. Mais c'est totalement l'idée : L'inscription, la désincription et l'envoi de newsletter peut se faire par email, sans avoir besoin d'ouvrir la moindre page Web.

Détournement des fichiers .forward

En explorant les façons un peu « à l'ancienne » d'utiliser un serveur, on était tombés sur une fonctionnalité à fort potentiel créatif : les fichiers .forward. Ces fichiers permettent de faire des transferts automatiques d'un email reçu sur sa boîte CLUB1 vers une ou plusieurs adresses. Il faut le créer dans son espace perso, et indiquer à l'intérieur une liste d'emails (ça vous rappelle quelquechose ?).

Mais le truc stylé, c'est qu'on peut combiner ce type de fichier avec les sous-adresses ! Quezako ? Une sous-adresse, c'est aussi une arcane oubliée de l'email. Ça correspond à une partie optionnelle après un caractère + et avant le fameux @ dans son addresse email. Ça peut servir à organiser ses emails entrants, par exemple, en faisant en sorte qu'ils arrivent dans un dossier spécifique (c'est le cas sur le serveur CLUB1).

Par exemple :

johanna+mozza@club1.fr est une sous-adresse de johanna@club1.fr

Le fait est que si on crée .forward+mozza, il va cette fois rediriger uniquement les emails de la sous-adresse vers une nouvelle sélection de destinataires.

Mais là où ça devient encore plus fou (et que ça va rejoindre notre sujet principal), c'est qu'au lieu de rediriger vers d'autres emails, on peut diriger l'email reçu vers un programme ! Et c'est ce que l'on va utiliser pour notre MUI.

En créant ces deux fichiers et en les redirigant chacun vers un programe qui ajoute ou retire l'email à la liste, on commence à avoir la fameuse fonctionnalitée d'inscription et de désinscription.

Ces programmes ne seront pas très complexes : ils devront identifier l'adresse d'origine, le From: et l'ajouter à la fin de notre fichier ou l'en retirer.
D'ailleurs, en parlant de fichier texte, un email, c'est en fait à peu près ça :

Voir la documentation CLUB1 pour en savoir plus sur l'usage des sous-adresses et des transferts automatiques.

Ré-écriture

Malheureusement pour les fans de Bash, à un moment, on a choisi de ré-écrire le script dans un autre langage de programmation, le Go.

C'est un truc qui peut arriver dans la vie d'un logiciel, se faire traduire dans une autre langue. Comme pour les langages humains, les langages informatique ont chacun leurs spécificités et sont plus où moins difficiles à apprendre en fonction d'où l'on vient. Une des forces de Bash est de pouvoir très vite obtenir le résultat voulu en utilisant les interface en CLI d'autres programmes. Cependant, en voulant ajouter la fonction d'envoi de la newsletter par email, il nous fallait un outil capable d'analyser les différents encodages du contenu de l'email. Malheureusement, on a pas trouvé de programme en CLI permettant de faire ça. De plus, c'est aussi un language que Nicolas apprécie et connait bien (ce qui est important !).

Si vous souhaitez étudier le code, voici les répertoires de code source :

• newsletter la version originale en Bash
• newsletter-go la version ré-écrite en Go (👈️ utilisée actuellement)

Extension aux membres de CLUB1

En fait, dès le début, on se disait que ce programme pourrait ensuite être facilement transposé en un service pour les membres de club1. La question d'un tel service avait été évoquée par des membres, souvent dans le but d'avoir une alternative à Instagram ou Facebook pour leurs communications.

Le programme comportait des parties de textes comme : « recevoir la newsletter de club1 », qu'il a fallu replacer par du texte généré en fonction des choix des membres. Un fichier de configuration permet maintenant de définir le nom de la newsletter, sa signature et la langue utilisée (anglais ou français). Ce fichier est situé dans le dossier standard ~/.config/newsletter. (~ correspond au dossier personnel)

Activation

Si l'activation de la newsletter ne peut se faire qu'à travers le terminal une fois connecté en SSH, on a essayé de rendre cette étape la plus agréable possible. Pour ça on a ajouté une commande newsletter setup qui déclenche un formulaire interactif. Cette commande se charge de créer les fichiers .forward nécessaires et va mettre à jour les fichiers de configuration. Voici à quoi ressemble le formulaire d'activation :

Inscription/désinscription

On peut s'inscrire à la newsletter d'un·e membre en contactant l'adresse ID+subscribe@club1.fr depuis l'adresse email que l'on souhaite inscrire (en remplaçant ID par l'identifiant de compte club1). Il est obligatoire de répondre à un email ensuite pour confirmer l'inscription. La désinscription se fait également par email, cette fois avec ID+unsubscribe@club1.fr. Cette dernière sera toujours indiquée dans la signature de chaque newsletter.

Envoi

L'envoi peut se faire de deux façons :

1. Par email évidement ! En envoyant un email à ID+send@club1.fr. Un email de prévisualisation sera envoyé, si on est satisfait, il faut répondre à cet email pour déclencher l'envoi final.
2. Via le terminal, une fois connecté en SSH au serveur.

newsletter send

Cette commande prend comme premier argument le titre de la newsletter, puis en second le fichier qui contient le contenu (Il est aussi possible de fournir le contenu via STDIN 🤩).

Enjeu de réputation

Envoyer plein de fois le même email à plein d'adresses sur d'autres serveurs est la pire chose que peut faire un serveur mail pour avoir une bonne réputation.

La plupart des entitées qui proposent un tel services disposent de plusieurs « adresse IP de sortie », leur permettant de rediriger les flux de mails sortant si la réputation de l'une d'elle est compromise. La réputation est généralement analysée en temps réel pour détecter la moindre baisse de réputation. Pour bien faire, il est souvent conseillé d'avoir une personne dédiée à la maintenance d'un service mail, pour ensuite contacter les autres serveurs lorsqu'une de ses IPs est blacklistée.

Tout ça pour dire que c'est totalement l'inverse de la situation de club1 : un seul serveur et pas de personne salariée pour faire ce boulot. Autant dire que notre réputation peut chuter à tout moment si le service de newsletter est utilisé n'importe comment (en gros pour envoyer du SPAM). Mais comme il n'y a pas d'inscription automatisée au serveur (il faut passer par la rencontre d'autres membres), on peut se faire confiance entre membres pour ne pas envoyer trop de bêtises !

Reste les cas des piratages de compte, donnant accès aux attaquants à l'envoi d'email, comme a pu nous le démontrer l'indicent 005. Heureusement, nous avons depuis mis en placce un quota d'envoi de 500 emails par jour (voir la discussion sur le forum à ce sujet). L'envoi de la newsletter n'est pas affecté par cette limite qui concerne uniquement les envois par SMTP.

Usage en dehors de CLUB1

Pourquoi ne pas voir plus loin et imaginer que ce code puisse servir à d'autres serveurs ? En réalité, c'est déjà le cas ! En étendant le code aux membres de club1, l'outil est en même temps devenu utilisable par tout autre entité qui voudrait l'installer sur son serveur. L'usage, ainsi que la modification du logiciel est permis par la license AGPL v3 (code source). Et pas seulement en français car la langue est paramétrable pour chaque utilisataire entre anglais et français (et il est possible d'ajouter des traductions).

Cependant, l'usage est limité aux configurations proches du serveur club1, comme les « serveurs tildes ». Ce qui est finalement très peu le cas parmi les CHATONS.

Qu'est-ce que les pixels de suivi ? Est-ce que sympa en dépose ? Et quelles sont nos obligations si nous utilisons un outil commercial de "newletter" ?

La montée des guerres est une des données majeures de notre présent. Si la concurrence entre les impérialismes aiguise les conflits mondiaux, provoquant morts et déplacements de populations, ces guerres ont des conséquences écologiques majeures. Cet article analyse les dimensions environnementales du réarmement global.

L'April fête ses 30 ans d'existence cette année. De nombreux évènements vont être organisés partout en France, Suisse et Belgique.

Ce vendredi 27 novembre, c'est Infini qui reçoit. Ce GULL (Groupe d'Utilisateurices de Logiciels Libres) breton se situe à Brest et a aussi fêté ses 30 ans en début d'année.

RDV le vendredi 27 novembre de 18h30 à 21h 30 au 186 Rue Anatole France à Brest.

Au programme : présentation de l'association par Bookynette pour les personnes qui ne la connaissent pas encore, discussions entre membres et non-membres.

À 19h30, apéritif partagé.

Informations importantes:

• Le local est accessible aux personnes à mobilité réduite
• Il y a des arceaux à vélo à proximité
• L'arrêt de bus le plus proche est : Cosmao Prétot, ligne 2B
• L'arrêt de tramway le plus proche est : Polygone

Bonsoir à toutes et à tous !

Après un démarrage « maladroit » en avril dernier (en clair on s’est pris une volée de bois vert 😂), nous avons revu drastiquement notre « copie » et nous sommes fiers de vous présenter notre nouveau site et ses nouvelles ressources.

Notre objectif reste le même : multiplier par 4 et en 4 ans l’adoption de Linux chez le particulier !

Le Libre, on en parle beaucoup tout comme la souveraineté numérique mais concrètement la route est longue, trop longue et parfois inaccessible pour des populations loin des grandes métropoles où l’on trouve désormais de nombreuses associations et collectivités qui promeuvent et qui portent assistance à la population pour faire revire leur PC et entrer dans un monde numérique plus « juste » et plus respectueux de notre vie privée et de notre planète.

Certains disent que le PC est mort, mais nous, nous le pensons pas ! Cette machine à écrire des temps modernes a du sens : le partage des savoirs et des savoir-faire, la création. De part leur essence, la plupart des distributions GNU/Linux respectent l’utilisateur, ne sont pas intrusives et permettent d’utiliser des machines devenues obsolètes aux yeux des GAFAM. D’après HOP, 55 % des PC sous Windows 10 sont directement concernés par l’incompatibilité quant à l’utilisation de Windows 11. Nous souhaitons prouver qu’une alternative existe et qu’elle n’a rien à envier aux GAFAM !

Notre modèle est basé sur une association et, OUI on parle « argent » dès la page d’accueil du site, car nous rémunérons nos linuxAngels pour leur travail qui consiste à aller chez le particulier et à effectuer une migration de Microsoft Windows vers Linux Mint qui est la distribution que nous avons choisie avec son environnement Cinnamon.

Bien évidement, nous recherchons des linuxAngels, des ami·e·s (assos, gulls, collectifs…) qui parlent de nous et qui nous aideraient à relever ce défi mais aussi des collectivités pour réaliser des projets à grande échelle, etc.

Voilà !

• lien nᵒ 1 : Linux4all.eu

Commentaires : voir le flux Atom ouvrir dans le navigateur