Un visage de chat de dessin animé avec de grands yeux larges et une couleur marron clair. Le chat sourit et tient un pinceau dans sa bouche, inspiré par l'installateur de la dernière version de GIMP, sur un fond blanc. L'image est simple et ludique.

Ubuntu : installer la dernière version de GIMP

by · Lecture: 3 minutes

GIMP reste l’un des meilleurs éditeurs d’images libres disponibles sous Linux. Il permet de retoucher des photos, créer des compositions, travailler avec des calques, convertir des images et effectuer pas mal de tâches graphiques avancées sans passer par Photoshop.

Sous Ubuntu 26.04 LTS, GIMP est disponible directement dans les dépôts officiels. Toutefois, comme souvent avec les distributions Linux, la version fournie par APT peut légèrement différer de la dernière version stable publiée par le projet GIMP.

À l’heure où j’actualise cet article, Ubuntu 26.04 propose GIMP 3.2.2-1 dans le dépôt universe, tandis que la dernière version stable officielle de GIMP est GIMP 3.2.4, publiée le 17 avril 2026. UbuntuUpdates indique la version du paquet Ubuntu 26.04, et le site officiel de GIMP indique la version stable actuelle.

Il existe donc deux méthodes propres selon votre besoin : installer GIMP depuis les dépôts Ubuntu, ou installer la dernière version stable via Flatpak.

Lire la suite

Linux et MacOS : lister tous les répertoires de plus de 500 Mo photo

Linux et MacOS : lister tous les répertoires de plus de 500 Mo

by · Lecture: 4 minutes

De temps en temps, il faut faire un peu de ménage sur son disque dur. Et, très souvent, le plus difficile n’est pas de supprimer les fichiers inutiles. Le plus difficile, c’est de trouver où ils se cachent.

Entre le dossier Downloads, les archives oubliées, les exports vidéo, les sauvegardes temporaires et les vieux projets jamais rangés, l’espace disque peut fondre très vite. Heureusement, sous Linux et macOS, une simple commande permet de repérer les répertoires les plus lourds.

Lister tous les répertoires de plus de 500 Mo

Voici la commande que j’utilise pour lister tous les dossiers de plus de 500 Mo dans le dossier Downloads, en les classant du plus gros au plus petit :

du -m ~/Downloads/* | awk '$1 > 500' | sort -nrCode language: JavaScript (javascript)

La sortie ressemble généralement à ceci :

8450    /Users/matt/Downloads/export-video
3210    /Users/matt/Downloads/archive-client
1275    /Users/matt/Downloads/site-backup
642     /Users/matt/Downloads/photosCode language: JavaScript (javascript)

En quelques secondes, vous obtenez donc une liste claire des dossiers qui méritent votre attention. C’est brutal, efficace, et ça évite de cliquer partout dans le Finder ou dans un gestionnaire de fichiers en espérant tomber sur le bon coupable.

Lire la suite

Une souris grise de dessin animé court énergiquement avec un grand sac postal beige étiqueté "MAIL" sur son épaule, l'air enthousiaste dans des gants et des chaussures jaunes. En dessous, "POSTFIX" est écrit en gras, ce qui indique une livraison rapide et non une erreur verify_cache.db ou un bogue de la base de données Berkeley.

Postfix : corriger l’erreur verify_cache.db “possible Berkeley DB bug”

by · Lecture: 4 minutes

En consultant les logs d’un serveur mail Postfix, je suis tombé sur un message qui revenait régulièrement :

close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)

À première vue, le message fait un peu peur. On lit Berkeley DB bug, on pense base de données corrompue, puis on commence à imaginer le serveur mail en train de mâcher ses propres fichiers. Bonne nouvelle : dans la plupart des cas, ce n’est pas dramatique.

Cette erreur concerne le cache de vérification d’adresses de Postfix. Lorsque Postfix utilise la vérification d’adresses, il peut stocker les résultats dans une base persistante. Ainsi, il évite de refaire les mêmes vérifications après un postfix reload ou un redémarrage du service.

Le problème survient généralement lorsque Postfix tente d’utiliser le fichier verify_cache.db, mais que la configuration de la map de vérification n’est pas assez explicite. Le démon verify essaye alors de manipuler un cache qui n’existe pas encore, ou auquel le service n’accède pas correctement via proxymap.

À quoi sert verify_cache.db dans Postfix ?

Postfix peut vérifier une adresse expéditeur ou destinataire avant d’accepter définitivement un message. Il effectue alors une sorte de test SMTP, sans livrer réellement le courrier. Le résultat de cette vérification peut ensuite être conservé en cache.

Ce cache évite de solliciter inutilement les mêmes serveurs distants. Il accélère aussi les décisions de Postfix lorsqu’une adresse a déjà été testée récemment.

La documentation Postfix indique que le paramètre address_verify_map définit la base de données persistante utilisée pour ces résultats de vérification. Sans ce paramètre, les informations de vérification sont perdues après un postfix reload ou un arrêt du service.

En clair : le fichier verify_cache.db n’est pas une boîte mail. Ce n’est pas non plus un fichier vital contenant vos messages. C’est un cache technique utilisé par Postfix pour garder en mémoire les résultats des vérifications d’adresses.

Lire la suite

Suivant →