- ストレージ容量を何度も増やしても使用量も一緒に増え、81人が参加したMastodonのアンケートでも約半数がディスクを75%超使用していた
- 空の状態より満杯の状態に到達する方法のほうが多いというエントロピーの論理で一部は説明できるが、ユーザー行動まで完全に説明できるわけではない
- 限界に達するまで整理を先延ばしにし、当面必要な分だけ削除する行動が、ディスクを常時飽和状態にとどめる
- 遅くなったソフトウェア、積み上がった技術的負債、混雑した道路、詰め込みすぎた予定も、苦痛がしきい値に達してからようやく対応するという同じパターンを示す
- 全体のリソースより小さい人為的な制約を予算のように設定すれば、早すぎる最適化を避けつつ、問題を限界点まで放置せずに済む
ストレージ容量がずっと満杯になる理由
- ルートドライブは利用可能な0.47TBのうち17GBしか残っておらず、**空き容量は3%**で、追加で取り付けた12TBドライブも140GB、約1%しか残っていない
- ストレージ容量は1990年代の約80MBから数十TBまで何度も倍増してきたが、それでも大半は使用中のままである
- 整理すべきファイルを見つけてくれるソフトウェアが昔から存在することも、この問題が続いてきたことを示している
- Mastodonのアンケート回答者81人のうち約半数はハードドライブを75%超使用しており、ストレージが空いているより満杯に近いケースのほうが一般的だった
- 空のディスクより満杯のディスクを構成する状態のほうが多いため、保存量を考慮せず状態をランダムに変えると飽和状態へ向かうというエントロピーに基づく解釈が可能である
- しかしディスクは、これ以上保存できなくなるまで問題だと感じられず、その時点では散らかりすぎていて、すべてのファイルを削除すべきか判断するのが難しい
- ユーザーは時間を稼げる分だけ整理してやめるため、ディスクはすぐに再び限界に達する
- ストレージ容量を数桁規模で増やしても、この行動は変わらない
苦痛のしきい値と人為的な制約
- 問題が耐えられない水準に達するまで対応を先延ばしにするパターンは、さまざまな領域で繰り返される
- ソフトウェアは遅くなりすぎるまで最適化されないため、たいてい遅い状態にとどまり続ける
- 技術的負債は、コード作業が苦痛になりリファクタリングが避けられなくなるまで積み上がる
- 経験の浅い開発者は最初から作り直すことさえあり、その結果ほとんどのコードベースは雑然とする
- 道路網は、対応しきれないほど混雑してからようやく拡張される
- 食生活は、より大きなズボンを買わなければならなくなるまで管理されない
- フルタイムの仕事を辞めて自営業者になり、義務や指示がなくなっても、予定は以前と同じくらい、時にはそれ以上に忙しく埋まる
- 限界点まで待つと、進行中に少しずつ解決した場合より処理すべきことがはるかに大きくなるが、一方で早すぎる最適化も望ましくない
- この2つの問題を調整するには、Jevons paradoxを活用して、全体の利用可能リソースより小さい実質的な制約を設け、その範囲に合わせて最適化できる
- 個人の財務ではこれを予算と呼ぶが、他の分野では同じ原理が繰り返し見落とされる
- Raspberry Piにソフトウェアをデプロイして実際に使いながら最適化すれば、Threadripperでも高速に動作する
- 80×25ターミナルのVimで探索できるコードベースは、強力な現代的IDEでも探索できる
- リソースや機能が増えると、より多くのことができるように思えるが、実際には同じことをより大きなコストで行うようにしてしまうこともある
1件のコメント
Lobste.rs のコメント
苦しい制約ではあったが、顧客サポート依頼のある種のものを丸ごとなくしてくれた。競合は Mac と Linux だけをサポートしたり、Windows だけを出して UNIX 対応を約束したりしているが、ユーザーから絶えず「Linux はいつ？」と聞かれている様子を見るとほっとする。今でも「BSD への移植はいつ？」とは聞かれるが、対処できる範囲だ
最新の SIMD 命令も面白いが、あらゆる最適化の基準は 2015 年型 MacBook Pro の Intel Haswell と AVX2 に置いている。その環境でうまく動くコードは、今でも同じようにうまく動く
256GB から 512GB へと増やすたびに、保存するコンテンツも一緒に増えてきた。クローンするリポジトリ、ダウンロードする音楽、保存しておく YouTube 動画や映画は際限なく増え、720p から 1080p、4K へと移るにつれてファイルサイズも大きくなった。ゲームも、別の Steam ゲームをインストールするには 1 本消さなければならないほど肥大化している。結局のところ、今のかごには入るだけ詰め込み、もっと大きなかごが手に入るまでそうしているだけの単純な現象なのだろうか
自分は気に入ったリポジトリに GitHub や Codeberg などでスターを付けている。いつか Fediverse のように、異なる Git forge 間でもスターを共有できるようになって、GitHub、GitLab、Codeberg ごとにアカウントを維持しなくて済むようになればと思う。リポジトリが消えたりアクセス不能になったりする事態に備えて、コードを自分でクローンしているのか知りたい
/nixパーティションは、完全な再インストール直後でない限り、ほとんど常に 90% 以上 埋まっている。Nix は、メモリ管理に似て、空きが必要になったときにだけガベージコレクションでディスクを回収するという開発者の見方をよく示している。複数バージョンの中間ビルド成果物も莫大な容量を食うメディアサーバーは満杯にならないが、古いドライブが壊れるたびに、同じくらいの価格でもっと大きいドライブへ置き換えてきたので、数年かけてゆっくり大きくなる 異種 RAID を使っているからだ。家中の CD や DVD をすべてデジタル化しようという試みも諦めた。ロスレス圧縮を使う音楽 CD と Wii のゲームには価値があるが、HD-DVD はまったく割に合わない
価値のあるものが消えないよう、たいていは Nix に書き込み、Git を使うプロジェクトフォルダに保存しておく作業は面倒だ。こうしたタイムマシン的な装置を何年も維持するのに膨大な労力がかかったが、増え続ける規模と複雑さを管理する唯一の方法のようにも感じる