▲

Fits on a Floppy - 작은 소프트웨어를 위한 선언문

 (fitsonafloppy.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • 소프트웨어 비대화는 과거 플로피 한 장에 담기던 앱이 기가바이트 저장공간과 긴 대기 시간을 요구하게 된 변화임
  • 1.44MB 플로피 디스크는 장난스러운 한계가 아니라 절제의 기준이며, 단일 목적 도구도 충분히 작게 만들 수 있다는 전제임
  • 작은 소프트웨어는 빠른 내려받기와 즉시 실행, 낮은 메모리·CPU 사용, 긴 배터리 시간, 오래된 시스템 지원을 지향함
  • 네이티브만 사용하고 의존성 비대를 피하며, 모든 코드가 존재 이유를 가져야 한다는 원칙을 강조함
  • 플로피 배지는 총 다운로드 크기가 1.44MB 미만인 앱에 붙으며, 핵심은 향수가 아니라 모든 바이트를 중시하는 제작 태도임

작은 소프트웨어의 기준

  • 소프트웨어 비대화로 과거 단일 플로피 디스크에 담기던 앱이 이제 기가바이트 저장공간, 긴 대기 시간, 과도한 인내를 요구하게 됨
  • 1.44MB 플로피 디스크는 장난스러운 제한이 아니라 절제의 기준으로 쓰임
  • 과거 전체 비즈니스를 운영하던 소프트웨어가 이 용량에 들어갔다면, 현대의 집중된 단일 목적 도구도 충분히 작게 만들 수 있음
  • 작은 소프트웨어는 빠르게 내려받고 즉시 실행되며, 불필요한 로딩을 줄이는 것을 목표로 함
  • 낮은 메모리와 CPU 사용, 더 긴 배터리 시간, 오래된 시스템 지원까지 포함해 사용자의 기기를 존중함
  • 네이티브만 사용하고 의존성 비대를 피하며, 모든 코드가 존재 이유를 가져야 함
  • 하나의 일을 잘하는 소프트웨어는 기능이 집중되고 버그가 줄며 더 오래 지속될 수 있음

측정 방식과 의도

  • 플로피 배지는 총 다운로드 크기가 표준 3.5인치 플로피 디스크 용량인 1.44MB 미만인 앱에 붙음
  • 디스크에 표시되는 크기는 개발자의 배포 플랫폼이 보고한 유니버설 바이너리 크기를 기준으로 함
  • 실제 기기에 내려받는 크기는 플랫폼 시닝(platform thinning)으로 특정 하드웨어에 필요한 조각만 전달되기 때문에 표시 크기보다 더 작을 수 있음
  • 핵심은 플로피 디스크 자체에 대한 향수가 아니라, 모든 바이트가 중요하고 제약이 창의성을 낳으며 소프트웨어가 가벼워야 한다는 제작 태도에 있음
  • 관련 예시로 39KB 크기의 수상작 게임 YOYOZO 제작기가 연결되어 있음

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Lobste.rs 의견들
  • 대체로 찬성하지만, 이미 시스템에 무엇이 깔려 있는지에 따라 크게 달라짐. C로 만든 동적 링크 바이너리나 Python 스크립트는 런타임이 거의 모든 컴퓨터에 있으니 쉽게 맞출 수 있음
    반대로 이식성을 위해 정적 링크를 하거나 Janet처럼 런타임이 덜 흔한 언어를 쓰면 이 기준을 훌쩍 넘게 됨
    • 동의하는 편임. 대상 운영체제에 이미 있다고 가정할 수 있는 UI 툴킷 같은 합리적 의존성 위에서 네이티브 애플리케이션을 만드는 게 아니라면, 이 용량 기준을 맞추기 어렵다. “작은” libc도 보통 0.5MB 이상이고, 네트워크 요청을 하려면 LibCURL도 수백 KB, BearSSL도 비슷해 보임
      내 프로젝트 Decker는 외부 의존성을 줄이려고 애쓰지만, 이식성을 위해 SDL과 SDL_image에 의존하고 함께 배포함. 현재 Apple Silicon 릴리스는 압축 상태로 6MB이고, 그중 약 4.6MB가 SDL과 SDL_image dylib임. 웹 빌드는 사용자가 이미 적당히 최신 HTML5 브라우저를 갖고 있다는 가정하에 0.5MB 정도에서 시작하지만, 브라우저까지 포함하면 의존성이 수백 MB가 됨
      유용한 애플리케이션과 라이브러리의 원시 deck 파일은 런타임이 이미 있다면 수십 KB에 그칠 수 있음. Love2d도 SDL과 여러 내장 구성요소 위에 올라가는 비슷한 상황이고, 압축 10MB, 압축 해제 25MB임. Love2d 위에서는 Lua 스크립트와 벡터 그래픽만으로 수십 KB짜리 유용한 앱을 만들 수 있지만, 역시 런타임이 이미 있을 때의 얘기임
      개발 자원이 무제한이면 SDL 의존을 피하는 게 멋진 목표겠지만, 대부분의 SDL 기반 프로젝트에서는 설치 파일 몇 MB를 줄이는 대신 덜 인기 있는 운영체제 지원을 아예 포기하게 될 가능성이 큼. 이걸 비대화로 볼지는 관점에 따라 다를 것임
  • 소프트웨어가 커지는 걸 피하는 건 좋지만, 큰 애플리케이션 대부분은 소프트웨어 자체보다 자산 파일 때문에 큼. 디스플레이 해상도가 높아졌고, 예전보다 사용자 경험에 더 신경 쓰게 됐음
    과거에는 텍스트만으로도 합리적이었지만 요즘은 드묾. 제시된 동기 목록 중 실제 원시 바이너리 크기와 직접 연결되는 건 첫 번째뿐이고, 나머지는 있으면 좋은 별개의 장점에 가깝다
    게다가 그 사이트 자체도 1,600바이트짜리 선언문을 전달하는 데 약 200,000바이트를 씀
  • 플로피 4장 이상으로 나온 게임을 해봤고, 실제 대사가 전부 담긴 100쪽짜리 종이 설명서까지 같이 오던 시절을 겪은 입장에서는, 그런 방식이 돌아올 필요는 전혀 없음
    • 게임을 세 가지 다른 매체에서 머릿속으로 조립해야 한다니 좀 멋있게 들리기도 함 :-) 그 시절에 가장 좋아했던 게임은 뭐였음?
  • 익숙하게 들림 https://fosstodon.org/@dillo/113913161923323567
    https://cdn.fosstodon.org/media_attachments/files/…
  • 어린 시절 플로피로 게임을 설치하느라 시간을 보낸 입장에서 향수는 있지만, 이건 그냥 순수한 향수임
    오늘날 사용자는 다운로드가 1.44MB인지 2.88MB인지, 혹은 그보다 큰지 알아차리지 못하고, 실행 파일을 돌릴 때도 차이를 체감하지 못함
  • “예전에는 플로피 한 장에 담기던 앱이 이제는 저장공간 몇 GB와 몇 분의 시간, 너무 많은 인내심을 요구한다”는 말은 과장임
    플로피 한 장짜리 애플리케이션도 있긴 했지만, 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였음
    플로피 한 장에 들어간다는 발상은 플로피 시대에도 일반적이지 않았고, 더 큰 소프트웨어는 여러 장으로 배포하면 된다는 걸 모두 알고 있었음
  • Linux 배포판을 플로피 한 장에 담을 수 있던 시절이 기억남. Tom's RootBoot Disk는 복구 시스템으로 훌륭했음
  • 잠깐, 모든 바이너리에 러브크래프트 인용문 2KB를 넣으면 안 된다는 얘기임?
  • 이 화면 보호기를 1~2주 써봤는데 아주 즐거움. 절반은 날아다니는 토스터, 절반은 “오, 저 디스크 알아” 하는 느낌임
  • 최근 가족이 퀴즈 쇼를 보는데 표준 플로피에 얼마나 저장할 수 있는지 묻는 문제가 나왔음. 23살인 아이는 평생 플로피를 본 적이 없었고, 또래보다 컴퓨터 지식은 훨씬 있는 편임
답변달기