ascendances

Plusieurs commandes permettent d’afficher une fenêtre de notification qui disparaît automatiquement. Voici quelques outils avec les fonctionnalités minimales. Chacun d’entre eux a des paramètres supplémentaires spécifiques.

Notify-send

notify-send est disponible dans le paquet libnotify-bin (dans Debian et ses dérivées) et est probablement déjà installé. La capture montre le rendu avec Gnome. La commande :

$ notify-send "ici un titre" "ici le contenu"

Zenity

zenity est basé sur GTK et permet l’affichage de différents types de fenêtre. Pour obtenir la fermeture automatique de la fenêtre, il faut ajouter un paramètre spécifique :

$ zenity --info --title="ici un titre" --text="ici un contenu" --timeout=5

Kdialog

kdialog fait partie de KDE. Le type passivepopup est une notification qui apparaît dans un coin du bureau et disparaît automatiquement :

$ kdialog --passivepopup --title "ici un titre" "ici un contenu"

Xmessage

xmessage fait partie d’outils fournis avec X11 (paquet x11-utils sous Debian et dérivées). Il doit être disponible à peu près partout mais, contrairement aux commandes citées précédemment, ne bénéficie pas de l’intégration avec le thème du bureau. En bref, ça fonctionne mais c’est moche.

$ xmessage -timeout 5 "ici un contenu"

Versions utilisées

Le rendu des captures d’écran peuvent différer selon la version des logiciels utilisés. Les captures ont été faites avec :

• Gnome 47
• KDE Plasma 5.27
• Zenity 4.0.2
• Xmessage 1.0.7

screenshots.debian.net est un service qui permet d’afficher des captures d’écran de logiciels. C’est assez pratique pour se faire une idée d’une interface par exemple. Une capture d’écran montrait déjà l’interpréteur Brainfuck beef affichant un classique
Hello Word!. Mais on peut aussi personnaliser en affichant un
Hello Debian! :

Brainfuck

Brainfuck est un langage dont l’intérêt principal est d’être difficilement compréhensible par un humain. Pas la peine de s’étendre sur ses spécificités, wikipedia le fait très bien. Il ressemble à une machine de Turing: le programme déplace un curseur dans un tableau et modifie les valeurs contenues dans les cellules du tableau.
Voici une version commentée du programme utilisé (le début est quasi-identique au hello world fourni sur la page wikipedia puisqu’on veut écrire la même chose) :

++++++++++          affecte 10 à la case 0
[                   boucle initialisant des valeurs au tableau 
   >                avance à la case 1 
   +++++++          affecte 7 à la case 1
   >                avance à la case 2
   ++++++++++       affecte 10 à la case 2 
   >                avance à la case 3
   +++              affecte 3 à la case 3
   >                avance à la case 4
   +                affecte 1 à la case 4
   >                avance à la case 5
   +++++++++++      affecte 11 à la case 5
   <<<<<            retourne à la case 0
   -                enlève 1 à la case 0
]                   jusqu'à ce que la case 0 soit = à 0

La boucle initialise le tableau en 10 itérations et son état est alors :

Case	0	1	2	3	4	5
Valeur	0	70	100	30	10	110

Suite du programme :

>++                 ajoute 2 à la case 1 (70 plus 2 = 72)
.                   imprime le caractère 'H' (72)
>+                  ajoute 1 à la case 2 (100 plus 1 = 101)
.                   imprime le caractère 'e' (101)
+++++++             ajoute 7 à la case 2 (101 plus 7 = 108)
.                   imprime le caractère 'l'  (108)
.                   imprime le caractère 'l'  (108)
+++                 ajoute 3 à la case 2 (108 plus 3 = 111)
.                   imprime le caractère 'o' (111)
>++                 ajoute 2 à la case 3 (30 plus 2 = 32)
.                   imprime le caractère ' '(espace) (32)

<<<                 revient à la case 0
++                  ajoute 2 à la case 0 (0 plus 2 = 2)
[                   une boucle
   >                avance à la case 1 
   --               enlève 4 à la case 1 (72 moins 4 = 68)
   >                avance à la case 2
   -----            enlève 10 à la case 2 (111 moins 10 = 101)
   <<               retourne à la case 0
   -                enlève 1 à la case 0
]                   jusqu'à ce que la case 0 soit = à 0

>                   va case 1
.                   affiche 'D'
>                   va case 2
.                   affiche 'e'
---                 enlève 3 à la case 2 (101 moins 3 = 98)
.                   affiche 'b'
>>>                 va case 5
-----               enlève 5 à la case 5
.                   affiche 'i'
<<<                 va case 2
-                   enlève 1 à la case 2
.                   affiche 'a'
>>>                 va case 5
+++++               ajoute 5 à la case 5
.                   affiche 'n'
<<                  va à la case 3
+                   ajoute 1 à la case 3
.                   affiche un point d'exclamation

>                   va à la case 4
.                   imprime le caractère 'nouvelle ligne' (10)

screenshots.debian.net

Une capture de l’exécution du programme est disponible pour les interpréteurs beef et hsbrainfuck sur screenshot.debian.net.
Les images disponibles sur screenshots.debian.net sont aussi réutilisées par le service packages.debian.org (par exemple packages.debian.org) et par certains gestionnaires de paquets.
Si vous avez envie d’ajouter des captures d’écran à des paquets qui n’en auraient pas (les plus courants sont déjà faits), sachez que l’affichage n’est pas direct car il y a une validation manuelle des images envoyées. Le délai reste limité à quelques jours (voire à la journée).

Lorsqu’on corrige une anomalie ou qu’on a ajoute une fonctionnalité à un logiciel ou une bibliothèque, on peut la garder pour soi ou la partager. La deuxième solution demande un peu plus d’efforts à court terme mais est préférable à long terme.

Le délai de retour d’un correctif ou d’une amélioration dépend de l’endroit où il est proposé : plus il est poussé loin et plus il va mettre de temps à revenir mais le nombre de personnes/machines bénéficiant du correctif sera plus grand.

Les différentes possibilités

Gardé pour soi

Cette méthode est absente du schéma puisqu’elle consiste à ne pas envoyer la modification à l’extérieur. C’est le plus rapide à mettre en œuvre, d’autant plus que la qualité du correctif n’est validée qu’en interne (juste soi-même ou par l’équipe intégrant la modification). Diverses façons d’arriver à ses fins sont possibles comme surcharger la signature de la méthode qui pose problème, attraper l’erreur non traitée correctement, intégrer la bibliothèque dans le code et la modifier directement (vendoring), etc.

Par contre, personne d’autre ne bénéficie du correctif et personne d’extérieur ne fera une revue de code.

Publication solitaire

La vitesse de mise au point est équivalente à la méthode précédente. Le déploiement prend un peu de temps. Elle permet de rendre la modification disponible pour les autres utilisateurs s’ils la trouvent. Ce phénomène est visible avec l’incitation au fork proposée par les forges comme Github, Gitlab, Bitbucket, etc, sans pousser la modification vers le développeur amont (via une pull request). Cette technique est utilisée lorsque des développeurs :

1. forkent un dépôt,
2. créent un commit modifiant le nouveau dépôt,
3. font dépendre leur application de ce commit (npm install git+https://alice@forge...).

Cependant, ce comportement n’est pas limité aux forges publiques : il existait déjà avant en publiant le correctif dans un article de blog, une liste de diffusion (liste non exhaustive).

Envoyé vers la distribution

La correction est envoyée dans la distribution Linux utilisée ; c’est souvent fait en incluant la modification dans un fichier, attaché à un rapport de bogue sur la distribution.

Une fois que la modification sera intégrée et qu’un nouveau paquet sera publié, l’ensemble des utilisateurs, y compris l’auteur, en bénéficieront. Cela évite de maintenir la modification de son côté lorsque de nouvelles versions du paquet seront publiées. La durée d’intégration est plus longue selon la réactivité du mainteneur du paquet et le mode de publication (version espacée ou rolling release). Bien évidemment, le bénéfice de la modification sera perdu en cas de changement de distribution.

Cette solution est nécessaire pour corriger/améliorer un élément spécifique d’un paquet de la distribution. Cela peut arriver dans deux cas :

• soit parce que c’est un paquet spécifique à la distribution (le paquet apt pour debian par exemple)
• soit parce qu’une modification du logiciel spécifique à la distribution a une influence sur la modification soumise

Envoyé vers le développeur amont

Plutôt que d’envoyer le correctif vers la distribution utilisée, il est alors envoyé directement vers le développeur du logiciel. Si le développement est hébergé sur une forge publique, cela suppose le faire un fork (comme dans le cas d’une publication solitaire), puis de faire une pull request (terme Github), merge request (terme Gitlab). Sinon, il faut regarder quelle est la forme attendue : en postant sur une liste de diffusion, ou directement vers le mainteneur, etc. Il sera nécessaire de répondre aux remarques et demandes de corrections pour que la modification soit intégrée dans le logiciel amont.

Comme dans le cas d’une intégration dans la distribution, une fois intégrée, la modification sera disponible pour tous :

• soit en réutilisant le logiciel directement via le paquet issus du langage (par exemple gem pour ruby, wheel pour python, crate pour Rust, etc.)
• soit parce que la version du logiciel sera elle aussi intégrée dans la distribution et donc obtenue dans un paquet de la distribution

Ce type de contributions sont les plus longues à revenir au contributeur mais elles permettent le déploiement le plus large (et donc la plus grande disponibilité pour soi et pour les autres).

Autres considérations

S’il n’est pas possible d’attendre le retour de la modification, la solution optimale est de faire un correctif local et un envoi vers la distribution ou vers le développeur amont (pour qu’une solution long terme soit aussi disponible automatiquement).

Pour bénéficier de l’envoi amont, il faut que le temps de retour soit inférieur au temps de changement de techno/bibliothèque. Dans un écosystème où les outils et bibliothèques sont abandonnés très rapidement, l’effort d’intégration peut être perçu comme vain puisque la personne ayant fait le développement aura peu le temps d’en profiter. D’un point de vue général, avec une majorité de personnes faisant ce calcul, cela ne fait qu’empirer le problème, avec des multitudes de fork s’ignorant mutuellement, chacun avec une fonctionnalité ou une correction différente. Javascript me semble être dans cette situation.

À propos du schéma

Le schéma a été réalisé avec Dia, installable par le paquet du même nom pour Debian et dérivées.
Fichier source .dia

TL;DR

Nom courant	Dénomination Debian	Disponibilité
x86	i386	rarement en vente après 2010
x86_64	amd64	à moins d’acheter des ordinateurs spécifiques, il n’y a plus que ça pour le grand public

Si vous venez d’acheter un ordinateur, choisissez amd64.

L’histoire, avec un grand L

Intel avait conçu une architecture 8086, améliorée successivement jusqu’au 286 (un processeur 16 bits).
Au milieu des années 80, Intel améliore cette architecture qui devient 32 bits (avec les dénominations commerciales 386 puis 486, Pentium, Pentium II, etc.), nommée i386 par Debian, communément appelée x86. Cette architecture est aussi parfois nommée ia32 pour « Intel Architecture 32 bits ». D’autres constructeurs de processeurs comme AMD ou Cyrix concevaient des processeurs compatibles. C’est donc cette même architecture (i386) qui devait être utilisée pour ces processeurs.

Puis Intel décida de faire un nouveau processeur, 64 bits, incompatible avec les x86. Associé à HP, une nouvelle gamme de processeur, Itanium, voit le jour en 2001. La dénomination Debian est donc ia64 (« Intel Architecture 64 bits »). C’est un échec commercial, dû à des performances décevantes et l’absence de compatibilité ascendante. Cette gamme sera arrêtée dans l’indifférence générale en 2013.

Parallèlement à Intel, AMD décide d’étendre le processeur x86 pour qu’il fonctionne en 64 bits tout en ayant une compatibilité 32 bits. Cette architecture est souvent appelée x86_64, parfois x64. En 2003, AMD vend l’Athlon 64, premier processeur disponible au public de cette nouvelle architecture. Debian la désigne par le terme amd64. Des accords entre AMD et Intel permettant aussi à Intel de produire cette architecture, Intel a emboîté le pas à AMD et produit aussi des processeurs compatibles amd64. C’est pourquoi les processeurs modernes Intel nécessitent cette architecture lors de l’installation d’un système Debian.

D’autres architectures moins connues voire complètement oubliées existent

Debian est installable sur de nombreuses autres architectures, mais qui ne sont pas orientées grand public. La seule exception étant peut-être ARM avec les cartes RaspberryPi (cf. wiki).

Des exemples d’autres architectures et processeurs associés : https://lists.debian.org/debian-www/2017/10/msg00125.html (à la toute fin du message)

S’il est impossible d’avoir un terminal en appuyant simultanément sur ctrl+alt+F6 , il est possible de paramétrer Grub pour démarrer Linux avec un environnement multi-utilisateur mais sans interface graphique (runlevel 3) :

Lorsque le menu de Grub s’affiche, appuyer sur e pour modifier temporairement la configuration.
Puis ajouter 3 à la fin de la ligne :
linux /boot/vmlinuz-… root=UUID=12345678-… ro quiet 3
Puis appuyer sur la/les touches indiquées par Grub pour exécuter cette entrée.

J’ai trouvé plusieurs explications indiquant d’utiliser text à la place de 3 mais ça ne fonctionne pas avec la version avec laquelle j’ai subi ce problème (2.02+dfsg1-6).

La solution vient de https://superuser.com/a/974809, possibilité 5.

…Et Grub était innocent : c’était un problème de paquets mis-à-jour mais non configurés.