DietPi vient de franchir un cap symbolique avec la sortie de la version 10.0 : plus qu’un “simple” update, c’est un changement de socle qui modernise l’écosystème… au prix d’une rupture assumée.
Au programme : fin du support Debian 11, nouvelles briques “self-hosted” et un ménage nécessaire dans les apps qui n’ont pas suivi le rythme de PHP et des dépôts récents.
Une base plus saine : DietPi dit adieu à Debian 11 Bullseye
Le point le plus important est aussi le plus clivant : DietPi 10.0 abandonne Debian 11 “Bullseye” et exige désormais Debian 12 “Bookworm” (ou supérieur).
Sur le papier, c’est cohérent : Bullseye est déjà passé en phase de support long terme (LTS) avec un périmètre réduit, et sa fin de vie LTS est fixée à fin août 2026. Pour un projet qui mise sur la simplicité d’installation et un catalogue logiciel propre, rester trop longtemps sur un socle vieillissant finit par coûter cher — en maintenance, en sécurité, et en compatibilité.
Le “bon” ménage : ownCloud Infinite Scale arrive, Uptime Kuma aussi
DietPi 10.0 ne se contente pas de couper l’ancien : il ajoute aussi deux pièces très actuelles à son arsenal de serveur léger :
- ownCloud Infinite Scale remplace ownCloud 10, notamment parce que la branche “classique” ne suit plus correctement les exigences modernes (dont PHP 8.x).
- Uptime Kuma fait son entrée dans DietPi-Software : un monitoring simple et efficace pour surveiller services, sites et endpoints, sans se perdre dans des usines à gaz.
Le message est clair : DietPi veut rester une base minimale, mais parfaitement alignée avec le self-hosting moderne (cloud perso, monitoring, Docker, etc.) — et donc compatible avec les dépendances d’aujourd’hui, pas celles de 2019.
Les victimes collatérales : certains SBC deviennent “trop vieux” d’un coup
La contrepartie est brutale pour une partie du monde des single-board computers : certains modèles perdent le support, faute de noyaux et de bootloaders capables de suivre Debian 12/13.
DietPi cite notamment Sparky SBC et plusieurs NanoPi (familles M2/T2/Fire2 et M3/T3/Fire3). En cause : des kernels “vendor” trop anciens (parfois bloqués sur des branches très datées), impossibles à faire évoluer proprement vers les exigences actuelles.
Dit autrement : ce n’est pas DietPi qui “abandonne” ces cartes par confort, c’est l’absence de support mainline solide côté fabricants qui rend la maintenance intenable.
Les sorties de scène logiques : caméras legacy et vieux clouds
Dans la même logique, DietPi 10.0 retire quelques options du catalogue DietPi-Software :
- RPi Cam Web Interface (dépendances liées à l’ancienne pile caméra, maintenance au ralenti)
- Pydio 8 (incompatible PHP 8.x, migration vers Pydio Cells évoquée)
C’est une décision pragmatique : quand l’OS bouge, les apps qui refusent d’évoluer deviennent des angles morts — et DietPi préfère les remplacer plutôt que de traîner des “exceptions” qui finissent en problèmes.
Si vous êtes sur Raspberry Pi / matériel encore supporté : bonne nouvelle. Vous gagnez une base plus moderne, un catalogue mieux tenu, et moins de bricolage pour rester à jour. Si vous êtes sur un SBC à kernel antique : deux options réalistes : rester sur une branche figée, ou migrer vers un matériel mieux supporté (ou un OS alternatif si vous tenez à cette carte).
Au fond, DietPi rappelle une vérité que le hardware “maker” a parfois du mal à accepter : dans l’auto-hébergement, la longévité ne dépend pas seulement de la puissance de la puce, mais de la qualité du support logiciel.
