Pourquoi les disques durs finissent toujours par se remplir

• Même après avoir augmenté plusieurs fois la capacité de stockage, l’usage augmente lui aussi, et dans un sondage Mastodon auquel 81 personnes ont participé, environ la moitié utilisaient plus de 75 % de leur disque
• On peut l’expliquer en partie par une logique d’entropie : il existe plus de façons d’atteindre un état plein qu’un état vide, mais cela n’explique pas totalement le comportement des utilisateurs
• Le fait de remettre le rangement à plus tard jusqu’à atteindre la limite, puis de ne supprimer que le strict nécessaire, maintient les disques dans un état de saturation quasi permanente
• Les logiciels devenus lents, la dette technique accumulée, les routes encombrées et les emplois du temps surchargés montrent le même schéma : on ne réagit qu’une fois la douleur arrivée au seuil critique
• Fixer des contraintes artificielles inférieures aux ressources totales, comme on le ferait avec un budget, permet d’éviter l’optimisation prématurée tout en évitant de laisser le problème dériver jusqu’à la limite

---

Pourquoi l’espace de stockage continue de se remplir

• Le disque racine ne laisse plus que 17 Go libres sur 0,47 To disponibles, soit 3 % d’espace libre, et le disque additionnel de 12 To ne laisse plus que 140 Go, soit environ 1 %
• La capacité de stockage est passée d’environ 80 Mo dans les années 1990 à plusieurs dizaines de To, doublant à plusieurs reprises, mais reste malgré tout largement utilisée
  • Le fait qu’il existe depuis longtemps des logiciels capables de repérer les fichiers à supprimer montre aussi que ce problème persiste depuis des années
• Sur les 81 répondants au sondage Mastodon, environ la moitié utilisaient plus de 75 % de leur disque dur, ce qui montre qu’un stockage plein est plus courant qu’un stockage vide
• Comme il existe plus d’états possibles pour un disque plein que pour un disque vide, on peut proposer une interprétation fondée sur l’entropie : si l’on modifie aléatoirement son état sans tenir compte du volume stocké, on tend vers la saturation
• Mais un disque n’est pas perçu comme un problème tant qu’il peut encore stocker des données, et une fois ce point atteint, le désordre est tel qu’il devient difficile de décider quels fichiers supprimer
  • L’utilisateur ne fait le tri que juste assez pour gagner un peu de temps, puis s’arrête, de sorte que le disque revient vite à sa limite
  • Même si la capacité augmente de plusieurs ordres de grandeur, ce comportement ne change pas

Le seuil de la douleur et les contraintes artificielles

• La tendance à repousser l’action jusqu’à ce qu’un problème devienne insupportable se répète dans de nombreux domaines
  • On n’optimise pas les logiciels avant qu’ils ne deviennent trop lents, si bien qu’ils restent en général lents en permanence
  • La dette technique s’accumule jusqu’à ce que travailler sur le code devienne si pénible qu’un refactoring devienne inévitable
    • Les développeurs moins expérimentés repartent parfois carrément de zéro, ce qui rend la plupart des bases de code désordonnées
  • Les réseaux routiers ne sont étendus qu’une fois la congestion devenue difficilement supportable
  • On ne surveille pas son alimentation avant de devoir acheter un pantalon plus grand
  • Même après avoir quitté un emploi salarié à temps plein pour devenir indépendant et ne plus avoir ni obligations ni directives, l’agenda se remplit autant qu’avant, parfois davantage
• Attendre la limite rend ensuite le travail bien plus important que si l’on avait traité le problème au fil de l’eau, mais à l’inverse, l’optimisation prématurée n’est pas non plus souhaitable
• Pour équilibrer ces deux problèmes, on peut s’appuyer sur le Jevons paradox et imposer une contrainte effective plus petite que les ressources réellement disponibles, puis optimiser à l’intérieur de cette limite
  • En finances personnelles, on appelle cela un budget, mais dans d’autres domaines, le même principe est sans cesse négligé
  • Déployer un logiciel sur un Raspberry Pi, l’utiliser soi-même et l’optimiser ainsi permet de le faire tourner rapidement aussi sur un Threadripper
  • Une base de code navigable dans Vim sur un terminal 80×25 reste navigable dans un IDE moderne très puissant
• Quand les ressources et les fonctionnalités augmentent, on a l’impression de pouvoir faire davantage, mais en pratique cela peut surtout conduire à faire la même chose à un coût plus élevé

[GN⁺]

Avis sur Lobste.rs

• Quand on crée un logiciel de bureau multiplateforme, il est beaucoup plus simple de résoudre les problèmes avant d’atteindre les limites. C’est pourquoi nous avons appliqué le principe suivant : dès le premier commit Git, toujours compiler et exécuter sous Windows, Mac et Linux
  C’était une contrainte pénible, mais elle a éliminé toute une catégorie de demandes au support client. Les concurrents ne prennent souvent en charge que Mac et Linux, ou ne sortent qu’une version Windows en promettant un support UNIX ; les voir subir les questions incessantes des utilisateurs du type « Linux, c’est pour quand ? » est assez rassurant. Nous recevons encore des « le portage BSD, c’est pour quand ? », mais ça reste gérable
  • J’imagine que les personnes qui demandent un portage BSD sont aussi particulièrement nombreuses à proposer leur aide directement ; je me demande si c’est vrai
• Je suis entièrement d’accord : un logiciel déployé sur un Raspberry Pi et utilisé réellement dessus tournera vite aussi sur un Threadripper. Les optimisations bas niveau visant les CPU modernes, comme la prédiction de branchement, la latence d’accès mémoire ou l’inlining, ont été efficaces sur n’importe quel CPU sorti ces 15 à 20 dernières années
  Les instructions SIMD récentes sont intéressantes, mais je prends comme référence pour toutes les optimisations l’Intel Haswell avec AVX2 d’un MacBook Pro de 2015. Du code qui fonctionne bien dans cet environnement fonctionne tout aussi bien aujourd’hui
• Point de vue intéressant. J’utilise actuellement 97 % d’un disque de 1 To
  À chaque passage de 256 Go à 512 Go, la quantité de contenu que je stockais a augmenté elle aussi. Il y a toujours plus de dépôts à cloner, de musique à télécharger, de vidéos YouTube et de films à conserver, et les fichiers grossissent en passant du 720p au 1080p puis à la 4K. Les jeux deviennent eux aussi si énormes qu’il faut en supprimer un pour installer un autre jeu Steam. Au fond, je me demande si ce n’est pas simplement le phénomène qui consiste à remplir le panier actuel autant que possible jusqu’à en obtenir un plus grand
  • Je me demande si cloner des dépôts ici sert simplement à les conserver hors ligne ou à les mettre en favori, ou si c’est nécessaire au processus d’installation de logiciels
    Pour ma part, je mets en favori les dépôts qui me plaisent sur GitHub, Codeberg, etc. J’espère qu’un jour, comme dans le fediverse, il sera possible de partager ses étoiles entre différentes forges Git, sans devoir maintenir un compte sur GitHub, GitLab et Codeberg. J’aimerais savoir si la raison de cloner le code soi-même est de se prémunir contre la disparition d’un dépôt ou son inaccessibilité
• La partition /nix est presque toujours remplie à plus de 90 %, sauf juste après une installation entièrement neuve. Nix illustre clairement le point de vue des développeurs selon lequel, comme pour la gestion mémoire, l’espace disque est récupéré par garbage collection uniquement quand on en a besoin. Les artefacts de build intermédiaires de plusieurs versions prennent aussi énormément de place
  Le serveur multimédia, lui, ne se remplit pas, parce qu’il utilise un RAID hétérogène qui grossit lentement au fil des années : chaque fois qu’un vieux disque tombe en panne, il est remplacé par un disque plus grand à prix comparable. J’ai aussi abandonné l’idée de numériser tous les CD et DVD de la maison. Les CD audio en compression sans perte et les jeux Wii valent le coup, mais les HD-DVD ne sont absolument pas rentables
  • Les CD et DVD ne sont-ils pas déjà des supports numériques ?
• J’exécute rootfs sur tmpfs. Le disque dur destiné au stockage persistant est presque vide, mais tmpfs continue de s’encombrer de manière difficile à comprendre. Quand la RAM vient à manquer, je redémarre le système pour récupérer l’espace temporaire
  Le travail qui consiste à s’assurer que les données précieuses ne disparaissent pas — généralement en les consignant dans Nix et en les conservant dans des dossiers de projet utilisant Git — est pénible. Maintenir ce dispositif de machine à remonter le temps pendant des années a demandé un effort énorme, mais cela me semble être la seule façon de gérer une échelle et une complexité qui ne cessent d’augmenter
• Cela me fait penser à la loi de Parkinson : « le travail s’étale de façon à occuper tout le temps disponible pour son achèvement »
• On dirait que tu n’aimes pas vivre sur le fil. Une vie heureuse, c’est être occupé sans être pressé, avoir un logiciel juste assez rapide, voir l’argent et les besoins se rejoindre à mi-chemin, et garder juste ce qu’il faut d’espace libre sur son disque dur