Fits on a Floppy - 小さなソフトウェアのための宣言

 (fitsonafloppy.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • ソフトウェアの肥大化とは、かつてはフロッピー1枚に収まっていたアプリが、今ではギガバイト級の保存容量と長い待ち時間を要求するようになった変化を指す
  • 1.44MBフロッピーディスクは冗談めいた制約ではなく、節度の基準であり、単一目的のツールも十分に小さく作れるという前提である
  • 小さなソフトウェアは、すばやいダウンロードと即時起動、低いメモリ・CPU使用量、長いバッテリー駆動時間、古いシステムへの対応を志向する
  • ネイティブのみを使用し、依存関係の肥大化を避け、すべてのコードが存在理由を持つべきだという原則を強調する
  • フロッピーバッジは、総ダウンロードサイズが1.44MB未満のアプリに付与され、重要なのはノスタルジーではなく、あらゆるバイトを重視する作り手の姿勢である

小さなソフトウェアの基準

  • ソフトウェアの肥大化により、かつて単一のフロッピーディスクに収まっていたアプリが、今ではギガバイト級の保存容量、長い待ち時間、過度な忍耐を要求するようになった
  • 1.44MBフロッピーディスクは冗談めいた制限ではなく、節度の基準として使われる
  • かつて事業全体を動かしていたソフトウェアがこの容量に収まっていたのなら、現代の焦点を絞った単一目的ツールも十分に小さくできる
  • 小さなソフトウェアは、すばやくダウンロードでき、すぐに起動し、不必要な読み込みを減らすことを目標とする
  • 低いメモリとCPU使用量、より長いバッテリー駆動時間、古いシステムへの対応まで含め、ユーザーのデバイスを尊重する
  • ネイティブのみを使用し、依存関係の肥大化を避け、すべてのコードが存在理由を持つべきである
  • ひとつの仕事をうまくこなすソフトウェアは、機能が集中し、バグが減り、より長く使い続けられる

測定方法と意図

  • フロッピーバッジは、総ダウンロードサイズが標準3.5インチフロッピーディスク容量である1.44MB未満のアプリに付与される
  • ディスクに表示されるサイズは、開発者の配布プラットフォームが報告したユニバーサルバイナリサイズを基準にしている
  • 実際にデバイスへダウンロードされるサイズは、プラットフォームシニング(platform thinning)によって特定ハードウェアに必要な断片だけが配信されるため、表示サイズより小さくなる場合がある
  • 重要なのはフロッピーディスク自体へのノスタルジーではなく、あらゆるバイトが重要であり、制約が創造性を生み、ソフトウェアは軽量であるべきだという作り手の姿勢にある
  • 関連する例として、39KBの受賞ゲーム YOYOZO 制作記 がリンクされている

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rsの意見
  • おおむね賛成だが、これはすでにシステムに何が入っているかで大きく変わる。Cで作った動的リンクバイナリやPythonスクリプトなら、ランタイムはほぼすべてのコンピュータにあるので簡単に収まる。
    逆に、移植性のために静的リンクをしたり、Janetのようにランタイムがあまり一般的でない言語を使うと、この基準をあっさり超えてしまう
    • その通りだと思う。対象OSにすでにあると見なせるUIツールキットのような妥当な依存先の上でネイティブアプリケーションを作るのでなければ、この容量基準を満たすのは難しい。「小さい」libcでも普通は0.5MB以上あるし、ネットワークリクエストをするならLibCURLも数百KB、BearSSLも同程度に見える。
      私のプロジェクト Decker は外部依存を減らそうと努力しているが、移植性のためにSDLとSDL_imageに依存し、同梱している。現在のApple Siliconリリースは圧縮状態で6MBで、そのうち約4.6MBがSDLとSDL_imageのdylibだ。Webビルドは、ユーザーがすでにそれなりに新しいHTML5ブラウザを持っているという前提なら0.5MB程度から始まるが、ブラウザまで含めれば依存関係は数百MBになる。
      有用なアプリケーションやライブラリの生のdeckファイルは、ランタイムがすでにあるなら数十KBで済むこともある。Love2d もSDLといくつかの組み込みコンポーネントの上に成り立つ似たような状況で、圧縮で10MB、展開後25MBだ。Love2d上ではLuaスクリプトとベクターグラフィックスだけで数十KBの有用なアプリを作れるが、やはりそれもランタイムがすでにある場合の話だ。
      開発リソースが無限ならSDL依存を避けるのは立派な目標だろうが、たいていのSDLベースのプロジェクトでは、インストーラを数MB削る代わりに、あまり人気のないOSのサポートを最初から捨てることになる可能性が高い。これを肥大化と見るかどうかは、視点によるだろう
  • ソフトウェアが大きくなるのを避けるのはよいことだが、大きなアプリケーションの大半はソフトウェア自体よりもアセットファイルのせいで大きい。ディスプレイ解像度は上がったし、以前よりもユーザー体験が重視されるようになった。
    昔はテキストだけでも妥当だったが、今ではまれだ。挙げられている動機の一覧のうち、実際の生バイナリサイズに直接結びつくのは最初のものだけで、残りはあればうれしい別個の利点に近い。
    しかもそのサイト自体、1,600バイトのマニフェストを届けるのに約200,000バイト使っている
  • フロッピー4枚以上で配布されたゲームも遊んだし、実際のセリフが全部載った100ページの紙の説明書まで付いてきた時代を経験した立場としては、そんなやり方が戻ってくる必要はまったくない
    • ゲームを3つの異なるメディアから頭の中で組み立てるなんて、ちょっと格好よく聞こえる :-) その頃いちばん好きだったゲームは何だった？
  • 見覚えがある https://fosstodon.org/@dillo/113913161923323567
    https://cdn.fosstodon.org/media_attachments/files/…
  • 子どもの頃、フロッピーでゲームをインストールして時間を費やした身としては懐かしさはあるが、これは単なる純粋なノスタルジーだ。
    今のユーザーはダウンロードが1.44MBなのか2.88MBなのか、あるいはそれより大きいのか気づかないし、実行ファイルを動かすときにも違いを体感しない
  • 「昔はフロッピー1枚に入っていたアプリが、今では数GBのストレージと数分の時間、そして過剰な忍耐を要求する」というのは誇張だ。
    フロッピー1枚のアプリケーションも存在したが、80〜90年代の本格的なソフトウェアの大半は複数枚に分けて配布されていた。たとえば Microsoft Word v2.0 on 7 disks with 2 supplemental disks、Lotus 1-2-3 on 13 floppy disks、Doomですら 4 floppy disks だった。
    フロッピー1枚に収まるという発想は、フロッピー時代ですら一般的ではなく、もっと大きいソフトウェアは複数枚で配布すればよいということを皆わかっていた
  • Linuxディストリビューションをフロッピー1枚に収められた時代を覚えている。Tom's RootBoot Diskは復旧システムとして素晴らしかった
  • ちょっと待って、すべてのバイナリに ラヴクラフトの引用を2KB入れてはいけない ってこと？
  • このスクリーンセーバーを1〜2週間使ってみたが、とても楽しい。半分は飛ぶトースター、半分は「おっ、そのディスク知ってる」という感じだ
  • 最近、家族がクイズ番組を見ていて、標準的なフロッピーにどれだけ保存できるかを問う問題が出た。23歳の子は生まれてこの方フロッピーを見たことがなく、同年代の中ではコンピュータ知識はかなりあるほうだ