1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Auch nachdem die Speicherkapazität mehrfach erhöht wurde, stieg die Nutzung mit; in einer Mastodon-Umfrage mit 81 Teilnehmenden nutzte etwa die Hälfte ihre Festplatte zu mehr als 75 %
  • Das lässt sich teilweise mit einer Entropie-Logik erklären: Es gibt mehr Wege, einen vollen Zustand zu erreichen als einen leeren. Das erklärt das Nutzerverhalten jedoch nicht vollständig
  • Das Verhalten, Aufräumen bis kurz vor die Grenze aufzuschieben und dann nur so viel zu löschen, wie gerade nötig ist, hält die Festplatte dauerhaft nahe der Sättigung
  • Langsamer gewordene Software, aufgelaufene technische Schulden, verstopfte Straßen und volle Terminkalender zeigen dasselbe Muster: Reagiert wird erst, wenn der Schmerz einen Schwellenwert erreicht
  • Setzt man künstliche Beschränkungen, die kleiner sind als die insgesamt verfügbaren Ressourcen, wie ein Budget, kann man vorschnelle Optimierung vermeiden, ohne Probleme bis zur Grenze liegen zu lassen

Warum Speicherplatz ständig voll wird

  • Auf dem Root-Laufwerk sind von 0,47 TB verfügbarer Kapazität nur noch 17 GB frei, also 3 % freier Speicherplatz; auch auf dem zusätzlich installierten 12-TB-Laufwerk sind nur noch 140 GB, etwa 1 %, frei
  • Der Speicherplatz wurde seit den 1990er-Jahren von etwa 80 MB auf Dutzende TB mehrfach verdoppelt, ist aber weiterhin größtenteils belegt
    • Dass es schon lange Software gibt, die Dateien zum Aufräumen findet, zeigt ebenfalls, dass dieses Problem schon lange besteht
  • Von 81 Befragten einer Mastodon-Umfrage nutzte etwa die Hälfte ihre Festplatte zu mehr als 75 %; volle Speicher waren also häufiger als leere
  • Da es mehr Zustände gibt, die eine volle Festplatte ergeben, als solche für eine leere, ist eine entropiebasierte Deutung möglich: Wenn man Zustände ohne Rücksicht auf die gespeicherte Datenmenge zufällig verändert, bewegt man sich in Richtung Sättigung
  • Eine Festplatte wird jedoch erst dann als Problem wahrgenommen, wenn nichts mehr gespeichert werden kann; zu diesem Zeitpunkt ist sie bereits so unübersichtlich, dass schwer zu entscheiden ist, welche Dateien gelöscht werden können
    • Nutzer räumen nur so viel auf, dass sie Zeit gewinnen, und hören dann auf, sodass die Festplatte schnell wieder an ihre Grenze stößt
    • Selbst wenn die Speicherkapazität um mehrere Größenordnungen erhöht wird, ändert sich dieses Verhalten nicht

Schmerzgrenzen und künstliche Beschränkungen

  • Das Muster, eine Reaktion aufzuschieben, bis ein Problem unerträglich wird, wiederholt sich in vielen Bereichen
    • Software wird erst optimiert, wenn sie zu langsam geworden ist, und bleibt daher meist dauerhaft langsam
    • Technische Schulden häufen sich an, bis die Arbeit am Code so schmerzhaft wird, dass Refactoring unvermeidlich ist
      • Weniger erfahrene Entwickler fangen dann sogar ganz von vorn an, wodurch die meisten Codebases unordentlich werden
    • Straßennetze werden erst erweitert, wenn sie unerträglich überlastet sind
    • Die Ernährung wird erst kontrolliert, wenn eine größere Hose nötig wird
    • Selbst wenn man eine Vollzeitstelle aufgibt und sich selbstständig macht, sodass Pflichten und Anweisungen wegfallen, füllt sich der Kalender genauso stark wie vorher, manchmal sogar stärker
  • Wartet man bis zur Grenze, ist der zu bewältigende Aufwand deutlich größer, als wenn man unterwegs schrittweise gegengesteuert hätte; umgekehrt ist vorschnelle Optimierung ebenfalls nicht wünschenswert
  • Um beide Probleme auszubalancieren, kann man das Jevons-Paradoxon nutzen und eine praktische Beschränkung setzen, die kleiner ist als die insgesamt verfügbaren Ressourcen, und innerhalb dieses Rahmens optimieren
    • In der persönlichen Finanzplanung nennt man das Budget, doch in anderen Bereichen wird dasselbe Prinzip immer wieder übersehen
    • Wenn man Software auf einem Raspberry Pi bereitstellt, selbst nutzt und optimiert, läuft sie auch auf einem Threadripper schnell
    • Eine Codebase, die in Vim in einem 80×25-Terminal navigierbar ist, lässt sich auch in einer leistungsfähigen modernen IDE navigieren
  • Wenn Ressourcen und Funktionen zunehmen, scheint es, als könne man mehr erledigen; tatsächlich kann es aber auch dazu führen, dass man dieselbe Arbeit zu höheren Kosten erledigt

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare
  • Wenn man plattformübergreifende Desktop-Software entwickelt, ist es viel einfacher, Probleme zu lösen, bevor sie an ihre Grenzen stoßen. Deshalb habe ich das Prinzip angewandt, ab dem ersten Git-Commit immer unter Windows, Mac und Linux zu bauen und auszuführen
    Das war eine schmerzhafte Einschränkung, hat aber eine ganze Kategorie von Support-Anfragen beseitigt. Konkurrenten unterstützen oft nur Mac und Linux oder veröffentlichen nur für Windows und versprechen später UNIX-Support; da ist es beruhigend zu sehen, wie sie unter den ständigen Fragen der Nutzer leiden: „Wann kommt Linux?“ Die Frage „Wann kommt der BSD-Port?“ bekomme ich zwar immer noch, aber das ist in einem beherrschbaren Rahmen
    • Ich frage mich, ob die Leute, die nach einem BSD-Port fragen, auch auffallend oft anbieten, selbst mitzuhelfen
  • Ich stimme voll zu, dass Software, die man auf einem Raspberry Pi ausgerollt und selbst benutzt hat, auch auf einem Threadripper schnell läuft. Low-Level-Optimierungen für moderne CPUs wie Branch Prediction, Speicherzugriffslatenz und Inlining waren auf jeder CPU wirksam, die in den letzten 15 bis 20 Jahren erschienen ist
    Neueste SIMD-Befehle sind zwar auch interessant, aber ich nehme als Maßstab für alle Optimierungen Intel Haswell mit AVX2 auf einem MacBook Pro von 2015. Code, der dort gut läuft, läuft auch heute noch genauso gut
  • Interessante Perspektive. Ich nutze derzeit 97 % einer 1-TB-Platte
    Jedes Mal, wenn ich von 256 GB auf 512 GB erweitert habe, ist auch die Menge der gespeicherten Inhalte mitgewachsen. Es gibt immer weitere Repositories zum Klonen, Musik zum Herunterladen sowie YouTube-Videos und Filme zum Archivieren, und mit dem Wechsel von 720p zu 1080p und 4K sind auch die Dateigrößen gewachsen. Spiele werden ebenfalls immer aufgeblähter, bis man eins löschen muss, um ein anderes Steam-Spiel zu installieren. Vielleicht ist es am Ende einfach das Phänomen, dass man den aktuellen Korb so weit wie möglich füllt, bis man einen größeren bekommt
    • Ich frage mich, ob das Klonen von Repositories hier einfach nur der Offline-Aufbewahrung oder dem Bookmarking dient oder ob es für die Installation von Software nötig ist
      Ich markiere Repositories, die mir gefallen, auf GitHub oder Codeberg mit einem Stern. Ich hoffe, dass man irgendwann wie im Fediverse Sterne über verschiedene Git-Foren hinweg teilen kann, sodass man nicht für GitHub, GitLab und Codeberg jeweils ein eigenes Konto pflegen muss. Mich würde interessieren, ob du den Code direkt klonst, um für den Fall vorzusorgen, dass ein Repository verschwindet oder unzugänglich wird
  • Die /nix-Partition ist fast immer zu mehr als 90 % gefüllt, außer direkt nach einer kompletten Neuinstallation. Nix zeigt deutlich die Entwicklerperspektive, dass es ähnlich wie bei der Speicherverwaltung den Plattenplatz erst dann per Garbage Collection zurückholt, wenn man ihn wirklich braucht. Auch Zwischen-Build-Artefakte verschiedener Versionen belegen enorme Mengen an Speicher
    Mein Medienserver läuft nicht voll, weil ich ein heterogenes RAID verwende, das über Jahre langsam wächst, indem ich alte defekte Laufwerke jeweils durch größere Laufwerke zum ähnlichen Preis ersetze. Den Versuch, alle CDs und DVDs im Haus zu digitalisieren, habe ich ebenfalls aufgegeben. Audio-CDs mit verlustfreier Kompression und Wii-Spiele lohnen sich, HD-DVDs dagegen überhaupt nicht
    • Sind CDs und DVDs nicht bereits digitale Medien?
  • Ich betreibe das rootfs auf tmpfs. Die Festplatte für dauerhafte Speicherung ist fast leer, aber tmpfs vermüllt auf schwer nachvollziehbare Weise ständig. Wenn der RAM knapp wird, starte ich das System neu, um den temporären Speicher zurückzugewinnen
    Es ist mühsam, darauf zu achten, dass nichts Wertvolles verloren geht, und Dinge, die ich normalerweise in Nix festhalte oder in Projektordnern unter Git aufbewahre, zu sichern. Es hat enormen Aufwand gekostet, so eine Zeitmaschinen-Konstruktion über Jahre am Leben zu halten, aber es fühlt sich wie die einzige Möglichkeit an, ständig wachsende Größe und Komplexität zu beherrschen
  • Das erinnert mich an Parkinsons Gesetz: „Arbeit dehnt sich so aus, dass sie die gesamte für ihre Erledigung verfügbare Zeit ausfüllt“
  • Offenbar magst du es nicht, auf Kante zu leben. Ein glückliches Leben bedeutet, beschäftigt, aber nicht gehetzt zu sein; Software ist genau so schnell, wie sie sein muss; Geld und Bedürfnisse treffen sich in der Mitte; und auf der Festplatte bleibt genau die richtige Menge freien Speicherplatzes übrig