FreeBSD 개발에 대한 1년간의 후원

 (daemonology.net)
2P by GN⁺ | ★ favorite | 댓글 1개
  • FreeBSD/EC2 유지관리와 릴리스 엔지니어링이 한 사람의 자원봉사 시간 안에서 충돌하던 상황에서, Amazon의 1년 후원이 릴리스 운영과 EC2 플랫폼 개선을 동시에 가능하게 함
  • 후원은 GitHub Sponsors를 통한 명목상 월 40시간 규모였지만 실제 작업은 평균 월 50시간이었고, EC2 이슈·릴리스 진행·기타 릴리스 엔지니어링이 대략 20/20/10시간으로 나뉨
  • 1년 동안 FreeBSD 13.4, 14.2, 13.5, 14.3 릴리스를 관리하면서 AWS Graviton의 전원 종료 신호 처리와 EC2 디바이스 핫플러그 같은 우선순위 작업도 병행함
  • 부팅 성능 회귀를 잡기 위해 2018년 이후 주간 EC2 AMI 빌드를 벤치마크했고, 루트 디스크 크기·EFI 엔트로피 시딩·ZFS 트랜잭션 그룹·IMDSv2 IPv6 변경에서 지연 원인을 찾아 수정함
  • 후원 종료 뒤에도 역할은 계속되지만, 릴리스 직전 문제를 직접 고치거나 EC2 기능 목록을 계속 전진시키기에는 투입 가능한 시간이 줄어듦

후원 전 병목과 시간 배분

  • FreeBSD/EC2 유지관리는 2010년 Amazon EC2에서 FreeBSD를 처음 부팅시킨 이후 이어졌고, 2023년 11월에는 FreeBSD 릴리스 엔지니어링 리드 역할까지 추가됨
  • Antithesis와 FreeBSD/EC2 Patreon의 소액 후원만으로는 두 역할을 감당하기 어려웠음
    • 구현할 기능 목록이 정체됨
    • 이상 현상을 발견해도 조사할 시간이 없어 미루는 일이 늘어남
    • 2024년 초에는 FreeBSD/EC2 플랫폼의 “좋은 오너” 역할을 하기 어렵다는 우려가 커짐
  • 2024년 4월 Amazon에서 예산을 가진 담당자를 찾으면서 일정·범위·절차 논의가 진행됐고, Amazon이 GitHub Sponsors를 통해 1년간 후원하기로 함
  • 후원 대상은 FreeBSD 릴리스 엔지니어링과 FreeBSD/EC2 개발을 합친 월 40시간 규모였음
    • 두 작업은 서로 의존성이 있어 하나만 후원하는 방식은 현실적이지 않다고 전달함
    • 실제 투입은 평균 월 50시간 정도로 늘어남
    • 평균적으로 EC2 전용 이슈 20시간, FreeBSD 릴리스 진행 20시간, 기타 릴리스 엔지니어링 관련 작업 10시간이었지만 월별 편차가 컸음

분기 릴리스 운영과 빌드 개선

  • 2024년 7월 발표한 FreeBSD 분기 릴리스 일정에 따라 1년 동안 4개 릴리스를 관리함
    • FreeBSD 13.4: 2024년 9월
    • FreeBSD 14.2: 2024년 12월
    • FreeBSD 13.5: 2025년 3월
    • FreeBSD 14.3: 2025년 6월 10일 릴리스 예정
  • 각 릴리스에는 코드 병합 독려, 머지 요청 승인·거부, 다른 팀과의 조율, 이미지 빌드·테스트, 공지문 작성, 릴리스 빌드 문제 수정이 포함됨
    • 일반적으로 3개 Beta, 1개 Release Candidate, 최종 Release를 빌드함
    • 대부분의 작업은 릴리스 전월, 즉 각 분기의 두 번째 달인 “Beta Month”에 몰림
    • FreeBSD 13.5는 33.5시간, FreeBSD 14.2는 79시간이 걸림
    • 안정 브랜치 후반으로 갈수록 깨지는 항목이 줄어 릴리스 작업량도 줄어드는 경향이 있음
    • FreeBSD 14.1은 추적하지 않았지만 릴리스 엔지니어링 시간이 100시간에 가까웠을 것으로 보이며, FreeBSD 15.0은 그보다 훨씬 많을 가능성이 큼
  • 일반 릴리스 엔지니어링에서는 릴리스 빌드 병렬화도 진행함
    • EC2 AMI 수가 많아지면서 실제 빌드보다 VM 이미지에 FreeBSD를 설치하는 시간이 큰 비중을 차지함
    • 릴리스 코드를 병렬화했지만 산발적인 빌드 실패가 생겼고, 전체 릴리스 빌드가 약 24시간 걸려 원인 분리가 어려웠음
    • 최종 원인은 파일 설치 전에 디렉터리를 생성해야 하는 Makefile 한 줄 누락이었음
    • 수정 뒤 릴리스 빌드는 약 22시간에서 약 13시간으로 줄었고, 빌드 시간 때문에 미루던 EC2 AMI flavour 확장도 가능해짐
  • 빌드 재현성 문제는 EC2를 활용해 정기적으로 확인하기 시작함
    • 주간 스냅샷 이미지 테스트 과정에서 EC2 인스턴스를 띄워 자신의 AMI를 빌드하게 함
    • diffoscope로 생성된 디스크 이미지와 원본 이미지를 비교함
    • 정기 테스트를 통해 여러 이슈를 발견했고, 일부는 직접 고치고 일부는 다른 개발자에게 넘김

FreeBSD/EC2의 Graviton 전원 처리와 핫플러그

  • Amazon이 FreeBSD/EC2에서 우선순위로 요청한 주요 기능은 AWS Graviton 인스턴스용 power driver와 디바이스 핫플러그였음
  • Graviton 전원 드라이버는 EC2 API가 운영체제에 종료를 알리는 경로를 처리함
    • 이 기능이 없으면 FreeBSD는 종료 신호를 무시하고, 몇 분 뒤 EC2가 타임아웃 후 가상 전원을 끊음
    • Graviton 시스템의 “전원 버튼”은 GPIO 핀이며, 세부 정보는 ACPI _AEI 객체에 들어 있음
    • ACPI에서 해당 정보를 찾아 PL061 GPIO 컨트롤러 드라이버로 구성 정보를 전달하도록 코드를 추가함
    • GPIO 핀이 assert되면 컨트롤러가 인터럽트를 생성하고, ACPI “power button” 이벤트가 발생해 시스템 종료로 이어짐
  • EC2가 제공하는 ACPI 테이블은 해당 GPIO 핀을 “Pull Up”으로 설정하라고 지정하지만, PL061 컨트롤러에는 pullup/pulldown 저항이 없음
    • Linux는 GPIO 구성 실패를 조용히 무시해 문제가 드러나지 않았음
    • FreeBSD는 구성 실패 뒤 디바이스를 비활성화했음
    • 향후 Graviton 시스템에서 EC2 버그가 수정될 것으로 보지만, 현재는 FreeBSD/EC2 AMI에 ACPI_Q_AEI_NOPULL quirk를 넣어 _AEI 객체의 GPIO PullUp 플래그를 무시함
  • 핫플러그, 특히 핫 언플러그는 여러 EC2 인스턴스 유형에서 서로 다른 문제가 겹쳐 더 많은 작업이 필요했음
    • 일부 Graviton 시스템은 PCI attach 중 가상 IRQ 예약을 누수했고, EBS 볼륨을 67회 attach/detach한 뒤 IRQ가 고갈되어 FreeBSD 커널 패닉이 발생함
      • 원인은 레거시 PCI 인터럽트 라우팅 코드였고, EC2에서 해당 코드를 끄는 부트 로더 설정을 추가함
    • 일부 Graviton 시스템은 OS가 디바이스 사용을 끝내고 eject 준비가 됐는지 판단하는 신호로 PCI 디바이스 전원 상태를 사용했음
      • 이는 EC2 버그로 판단되며, 현재는 ACPI_Q_CLEAR_PME_ON_DETACH quirk로 eject 전에 PCI 전원 관리 레지스터의 일부 비트를 바꿈
    • 최신 세대 EC2 인스턴스의 x86과 Graviton에서는 PCIe unplug 뒤 FreeBSD nvme 드라이버가 패닉을 일으킴
      • 이 문제는 nvme 드라이버 유지관리자에게 전달함
    • 일부 x86·Graviton EC2 인스턴스에서는 eject 뒤 PCI 버스에 “ghost” 디바이스가 남아 새 디바이스 attach를 막음
      • Nitro 펌웨어가 PCI 버스 관리와 PCI 디바이스 관리를 비동기로 수행해, 디바이스가 unplug됐지만 PCI 버스가 몇 ms 동안 여전히 존재한다고 보고하는 창이 있었음
      • Linux는 버스를 주기적으로 스캔해 대개 이 경쟁에서 지지만, FreeBSD는 detach 직후 PCI 버스를 즉시 다시 스캔해 ghost를 보는 경우가 많았음
      • 현재는 ACPI_Q_DELAY_BEFORE_EJECT_RESCAN quirk로 eject 신호 뒤 PCI 버스 재스캔 전 10ms 지연을 추가함
  • PCIe는 디바이스 eject 요청을 위한 “attention” 버튼을 누른 뒤 5초 지연을 요구하고, 두 번째 버튼 입력이 있으면 eject 요청을 취소함
    • EC2에는 물리 버튼을 누르는 사람이 없고 가상 버튼을 다시 누르는 메커니즘도 없어 이 지연은 불필요함
    • 부트 로더 tunable을 추가해 EC2에서 타임아웃을 0으로 설정함
  • 핫플러그 테스트 스크립트로 EC2 인스턴스를 띄운 뒤 EC2 API로 EBS 볼륨을 반복적으로 plug/unplug하고, FreeBSD가 300회 연속 attach/detach하는지 확인할 수 있게 함
    • 향후 EC2 인스턴스 유형에 사전 접근할 수 있다면 핫플러그 동작 여부를 확인하는 데 활용 가능함

부팅 성능 회귀 추적과 AMI 확장

  • Amazon의 최우선 작업 두 가지 외에도 EC2 전용 시간의 절반가량은 다른 FreeBSD/EC2 문제에 쓰임
  • 2023년 말과 2024년 초에는 FreeBSD/EC2 인스턴스가 때때로 예상보다 오래 부팅됐고, 주간 스냅샷 테스트에서 인스턴스 실행 뒤 SSH 접속 시도 전 대기 시간을 늘려야 했음
  • 성능 문제를 다루기 위해 2018년 이후 주간 EC2 AMI 빌드의 부팅 시간을 벤치마크함
    • 이 과정에서 EC2 인스턴스 1만 개 이상을 실행함
    • FreeBSD boot performance plots를 생성하기 시작함
    • 새 데이터 수집과 플롯 갱신은 주간 스냅샷 테스트 과정에 포함됨
  • 여러 부팅 지연 원인을 찾아 수정함
    • 2024년 첫 주부터 FreeBSD 부팅이 약 3배 느려졌고, 원인은 루트 디스크 크기를 5GB에서 6GB로 늘린 커밋으로 추적됨
      • Amazon 쪽 확인 결과, 루트 디스크 크기를 8GB로 늘리면 이전 수준의 성능이 복구됨
    • Graviton 2 계열에서는 커널 엔트로피 시딩 문제로 부팅이 길어짐
      • FreeBSD 커널은 보안 난수 생성을 위한 엔트로피가 부족하면 더 많은 엔트로피를 모을 때까지 부팅을 멈춤
      • EFI 부트 로더를 통해 Nitro 펌웨어에서 보안 시드를 받는 코드가 있었지만 EC2에서는 실행되지 않았고, Graviton 2에서는 2048바이트 요청이 매우 느렸음
      • 부트 메뉴 Lua 코드에 있던 요청을 적절한 부트 로더 Lua 위치로 옮겨 메뉴 비활성화 여부와 관계없이 실행되게 함
      • 64바이트 EFI 엔트로피를 받아 PBKDF2로 2048바이트 API 입력에 맞게 확장하도록 바꾸면서 FreeBSD arm64/base/UFS 부팅 시간이 약 25초에서 약 8초로 줄어듦
    • ZFS 이미지는 UFS보다 부팅이 길었고, 지연 폭은 디스크 크기가 아니라 디스크의 데이터 양에 따라 달라졌음
      • makefs가 모든 것을 단일 트랜잭션 그룹에 넣고, ZFS attach 시 최근 트랜잭션 그룹을 순회하며 검증하면서 디스크의 모든 파일 메타데이터를 읽고 처리했음
      • Mark Johnston이 파일시스템에 더 높은 트랜잭션 그룹을 기록하도록 해 단일 트랜잭션 그룹이 “최근”으로 간주되지 않게 해결함
      • ZFS 이미지 부팅 시간은 약 22초에서 약 11초로 줄어듦
    • 2024년 12월 net/aws-ec2-imdsv2-get 포트의 IPv6 지원 추가 뒤 부팅 문제가 빠르게 포착됨
      • 이 포트는 EC2 Instance MetaData Service용 명령줄 인터페이스를 제공함
      • IPv6를 먼저 시도했지만 기본 IMDS 인스턴스 구성은 IPv4-only였고, 기본 TCP 타임아웃 75초도 그대로였음
      • 수정 뒤 IPv4를 먼저 시도하고 타임아웃을 100ms로 줄임
  • FreeBSD AMI flavour도 확장함
    • 기존에는 base와 cloud-init만 있었음
    • small AMI는 debug symbol, LLDB, 32비트 라이브러리, FreeBSD 테스트, Amazon SSM Agent, AWS CLI를 제거해 디스크 사용량을 약 5GB에서 약 1GB로 줄임
    • builder AMI는 사용자가 맞춤형 FreeBSD AMI를 쉽게 만들 수 있는 FreeBSD AMI Builder AMIs를 제공함
  • 4개 AMI flavour, 2개 파일시스템, 2개 아키텍처, 3개 FreeBSD 버전 조합으로 주간 스냅샷 빌드가 늘어나면서 오래된 이미지와 관련 EBS 스냅샷을 정리함
    • FreeBSD 릴리스 엔지니어링 AWS 계정은 Amazon 후원을 받지만 누군가의 비용은 발생함
    • 셸 스크립트를 작성해 336TB의 EBS 스냅샷을 제거할 수 있었음

후원 종료 뒤 남는 작업과 제약

  • 큰 프로젝트 외에도 여러 작은 작업이 이어짐
    • 주간 스냅샷 빌드에서 발견한 빌드 깨짐 수정
    • ENA 드라이버 패치 리뷰
    • Dave Cottlehuber가 OCI Container를 빌드하고 저장소에 업로드하는 기능을 추가하도록 지원
    • bsdec2-image-upload 도구가 내부 AWS 오류를 더 부드럽게 처리하도록 개선
    • 우연히 발견한 AWS 보안 이슈 보고
  • 후원 종료 뒤에도 FreeBSD 릴리스 엔지니어링 리드와 FreeBSD/EC2 플랫폼 유지관리자 역할은 계속됨
    • FreeBSD 15.0은 12월 도착 예정
    • 2026년에는 14.4, 15.1, 14.5, 15.2가 이어질 예정
  • 투입 가능한 시간이 줄어들면서 릴리스 직전 문제를 직접 고치는 방식은 어려워짐
    • 늦게 들어오는 기능은 릴리스에 맞춰 고쳐지기보다 제거될 가능성이 커짐
    • FreeBSD 14.2부터 OCI Containers를 포함할 수 있었던 것은 후원된 시간으로 필요한 조각들이 온전하게 들어가도록 확인할 수 있었기 때문임
  • EC2 쪽은 부팅 성능 회귀 테스트가 마련되어 관련 문제를 잡아낼 가능성이 있지만, 기능 구현 목록은 추가 시간이 없으면 정체될 수 있음
    • EBS 볼륨 확장 시 파일시스템 자동 확장
    • 다중 네트워크 인터페이스와 네트워크 인터페이스 핫플러그의 자동 구성 개선
    • 롤링 “pre-patched” AMI
    • 패키지 설치와 데몬 실행 등을 위한 EC2 user-data 파일 생성 웹사이트
    • FreeBSD/Firecracker 작업 재개와 지원 플랫폼화
  • Amazon 후원은 대부분의 오픈소스 개발자가 받는 것보다 훨씬 큰 기회였고, 후원이 끝나는 아쉬움과 함께 그동안의 작업 결과에 대한 감사가 남음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 좋네요. 오늘부터 ziglang.org 다운로드 페이지에 FreeBSD를 추가해서, FreeBSD 사용자가 CI에서 자동 빌드된 master 브랜치 빌드를 받을 수 있게 됐습니다
    이제 libc 링크까지 포함해 1급 크로스 컴파일 대상으로 지원하므로 zig cc -o hello hello.c -target riscv64-freebsd 같은 것도 가능함
    C/C++ 의존성이 있으면 Zig 빌드 시스템으로 가져와 빌드할 수 있어서, 꽤 복잡한 프로젝트도 FreeBSD용으로 쉽게 크로스 컴파일할 수 있을 것 같음. 더 많은 프로젝트가 FreeBSD 지원과 CI 테스트를 추가하는 데 도움이 되길 바람

    • Zig의 크로스 컴파일은 훌륭하고, FreeBSD가 지원 대상 목록에 들어간 것도 반가움
    • Zig는 BSD 친화적 라이선스이고 FreeBSD는 이미 기본 시스템에 LLVM을 포함하니, 언젠가 Zig도 기본 시스템에 들어갈지 궁금함
      공식적으로 인정받는 C 대체재가 있으면 좋겠음

  • 여기 재미있는 대목이 꽤 있음
    “2024년 첫 주부터 FreeBSD 부팅 과정이 갑자기 약 3배 느려졌다. 커밋을 이분 탐색해 보니 원인은 루트 디스크 크기를 5GB에서 6GB로 늘린 커밋이었다. 왜 그랬을까? Amazon 지인들에게 물어보니 답은 ‘마법’과 ‘정말 알고 싶지 않을 것’ 사이 어딘가였고, 중요한 건 루트 디스크를 8GB로 늘리자 성능이 예전 수준으로 돌아왔다는 점이었다”

    • S3의 원래 객체 크기 제한은 5GB였고, 2006년에 쓴 글에도 그렇게 적혀 있음: https://aws.amazon.com/blogs/aws/amazon_s3/
      이게 관찰한 성능 절벽과 관련 있는지는 모르겠음
    • 그래도 이제는 정말 알고 싶어짐
    • 그런 문제를 이분 탐색하는 데 얼마나 걸렸을지 궁금함. 매번 이미지를 빌드하고 VM을 재부팅했을까?

  • 노트북 쪽에서도 작업이 많고, BSD Foundation이 여기에 75만 달러를 투자했다고 읽었음
    S0ix 절전 상태 같은 구현을 포함하며, 프로젝트는 여기서 볼 수 있음: https://github.com/FreeBSDFoundation/proj-laptop

    • 맞음, 많은 작업이 진행 중임. 나는 그냥 내가 하던 작업에 대해 쓴 것뿐임 ;-)

  • cperciva에게 정말 존경심이 듦
    이 모든 것과 Tarsnap을 어떻게 같이 해내는지 모르겠음

    • 어느 시점부터는 돈으로 시간을 살 수 있음. 새는 수도꼭지를 직접 고칠지 배관공을 부를지, 전기공들이 지하실 석고보드를 뜯어낸 뒤 직접 복구할지 전문가를 부를지 같은 문제임
      공정하게 말하면 여기에 쓴 시간 일부는 Tarsnap에서 빠져나온 것이지만, 생각보다 훨씬 적음

  • Amazon이 더 많이 지출하고 기여하길 기대했는데, 기본적으로 최소한의 FreeBSD 지원에만 돈을 내고 싶은 것처럼 보임
    Amazon은 FreeBSD 후원자 목록에도 없고 [1], Google은 작년에 9천 달러만 후원했으며 Apple도 없음. Microsoft는 적어도 목록에 있으니 인정할 만함. Meta/Facebook도 빠져 있음
    이 회사들은 FreeBSD와 OpenBSD를 쓰고 계속 혜택을 보고 있으니, 기본적으로 매년 후원할 거라고 기대했음
    [1] https://freebsdfoundation.org/our-donors/donors/?donationYea...

    • 물론 Amazon이 더 기여하면 좋겠지만, FreeBSD Foundation 기부자 목록에 없다고 해서 FreeBSD를 지원하지 않는다는 뜻은 아님
      예를 들어 나에게 지급한 돈은 Foundation을 거치지 않았음. 추정하자면 기업 자금으로 이루어지는 FreeBSD 개발 중 Foundation 지원 개발은 아마 10% 정도일 것임
      그 10%는 특히 “회사 X에 필요한 것”이 아니라 “FreeBSD에 필요한 것”에 집중할 수 있어 중요하지만, 여전히 작은 비중임
    • 이 얘기는 전체 그림을 보여주지 않음
      첫째, 특정 연도의 Foundation 기부 스냅샷만 보여주므로 기부 이력은 당연히 드러나지 않음
      둘째, 개발 기여도 보여주지 않음. 이런 내용은 보통 각 릴리스 노트에서 요약해 볼 수 있음 [1]
      [1] https://www.freebsd.org/releases/
    • Microsoft가 왜 후원하는지 궁금함. Hyper-V 확장은 Linux만큼 완전하지 않고, Microsoft가 지원하는 .NET 포트도 없음
      클라우드든 아니든 Microsoft 서비스가 *BSD에서 돌아가는 것도 떠오르지 않음
    • Amazon은 FAANG 중 자유·오픈소스 소프트웨어에 가장 적게 하는 편임

  • 집 게이트웨이/방화벽/DNS/DHCP 서버로 FreeBSD를 쓰고 싶었지만, 내 10GbE NIC에 드라이버가 없는 것 같아서 결국 Nix를 선택함
    오래전에 FreeBSD를 워크스테이션으로 썼고 꽤 기억에 남는 경험이었음. 아직도 꾸준히 굴러가는 걸 보니 좋음

    • 내 회사와 개인 인프라는 모두 FreeBSD를 사용함. FreeBSD에서 Intel NIC는 100% 신뢰할 수 있어서 그것만 씀
      Realtek은 드라이버를 유지보수하는 FreeBSD 엔지니어들이 열심히 노력해도 부하가 걸리면 망가지는 듯함. 불평하는 건 아니고 그들의 노력을 존중함
      이 정도는 작은 대가이고, 덜 안정적인 운영체제를 설치하지 않아도 되게 해줌

  • FreeBSD 7이나 8 즈음에는 Atheros Wi-Fi 카드 같은 것에서 FreeBSD 드라이버가 Linux보다 나았던 시절이 기억남
    2021년쯤까지 FreeBSD를 선호했지만, 서로 다른 CPU 코어가 섞인 컴퓨터가 흔해지면서 바뀌었음. 처음에는 big 코어 2개와 little 코어 4개가 있는 RockPro64를 샀고, 이후 Intel Alder Lake를 샀음
    내가 이해하기로 FreeBSD 스케줄러는 아직 이런 구성을 제대로 다루지 못해서, 시스템을 느린 코어 기준의 최저 공통분모로 끌고 가는 듯함

  • 호기심인데, FreeBSD/EC2의 주요 사용자는 누구일까?

    • 전혀 모름. 진지하게 말해, 나에게 연락하는 사용자는 전체 FreeBSD/EC2 사용자 기반의 아마 0.1% 정도임
      EC2에서 누가 FreeBSD를 쓰는지 정말 알고 싶음
    • Netflix는 엣지 장비에서만 쓰는 걸까?

  • 기업의 오픈소스 후원이 어떻게 작동하는지 매우 잘 보여주는 글임

  • FreeBSD를 쓰는 사람이 Unix 공간에서 FreeBSD가 채우는 틈새가 무엇인지 설명해 줄 수 있을까? 왜 더 단순하고 일관된 OpenBSD나 NetBSD가 아니라 FreeBSD일까?
    답이 ZFS, Nvidia 드라이버, ELF 같은 지원이라면 왜 Linux가 아닐까? GNU의 문제는 잘 알지만, Musl Void 같은 것에서도 문제가 있나?
    정말 궁금함. FreeBSD는 내게 일종의 그림자 영역처럼 존재해서, 계속 굴러가게 하는 핵심 정체성을 정확히 잡아내지 못했지만 어딘가에 있다는 건 알고 있음

    • 금융 서비스 회사에서 EC2와 자체 관리 데이터센터의 베어메탈 모두에 FreeBSD를 쓰는 일을 했음. 항상 쓰던 두 기능은 ZFS와 jail이었음
      각 서비스는 격리를 위해 자기 jail에서 실행됐고, 강력하지도 않은 서버 하나가 모든 서비스를 돌릴 수 있어 비용 효율이 엄청났음
      어느 시점에 하이브리드 구성을 위해 클라우드 마이그레이션을 했고 Linux(k8s)와 FreeBSD를 섞어 쓰자 비용이 급등했음. 데이터센터에서는 디스크를 직접 사고 교체해야 하고 화재 같은 상황에 대응해야 하며 한 나라에만 있다는 단점이 있지만, AWS는 멀티 리전과 여러 좋은 기능을 제공하고 그만큼 가격이 있음
      ZFS를 아주 많이 활용한 것은 아니지만, 운영 DB에서 테이블을 실수로 삭제했을 때 직전 ZFS 스냅샷으로 즉시 롤백해 한 번 크게 살렸음. 약간의 데이터 손실은 있었지만 해당 애플리케이션에서는 가동 시간이 더 중요해서 큰 문제가 아니었음. 백업에도 ZFS를 썼던 것으로 기억함
      운영 환경 문제 해결에 dtrace를 몇 번 사용했고, FreeBSD 서버군에 Linux를 도입하자 팀마다 자연스럽게 다른 배포판을 골라 일종의 동물원이 됐음. 서버에서 FreeBSD를 쓰면 변종이 하나뿐임
      둘 다 여전히 쓰고 좋아하지만, FreeBSD가 커널과 운영체제가 통합된 형태라는 점이 정말 마음에 듦
    • 내 경험상 FreeBSD는 OpenBSD와 NetBSD가 각각 중시하는 요소 사이에서 좋은 균형을 제공함
      역사적으로 FreeBSD는 Intel CPU를 우선했고, NetBSD는 이식성이 더 강했으며, FreeBSD도 보안이 탄탄했지만 OpenBSD는 보안에 더 집중했음
      FreeBSD의 ZFS 지원은 정말 판도를 바꿀 만함. Nvidia는 최근에야 네이티브 FreeBSD 드라이버를 제공한 것으로 알고, 오랫동안은 FreeBSD의 Linux 커널 호환 기능이 필요했음
      다시 말해 FreeBSD는 다른 BSD들이 제공하는 기능을 잘 섞으면서도, 내가 주로 쓰는 하드웨어 플랫폼에서 엄청나게 안정적이었음
    • FreeBSD는 OpenBSD가 확실히 그렇지 않은 방식으로 처리량 지향이고, NetBSD도 그렇지는 않다고 봄
      NetBSD는 이식성으로 경쟁하고 네트워크 처리량을 높게 유지하는 데 많은 시간을 쓰지는 않는 느낌임
      모든 BSD는 대체로 변화가 훨씬 적고, 장단점은 있지만 통합 대상 플랫폼으로는 더 좋다고 봄
    • FreeBSD는 라이선스 문제가 없어서 Linux보다 ZFS 지원이 더 좋음
    • FreeBSD는 OpenBSD나 NetBSD보다 사용자 기반이 훨씬 큼. 비교가 안 됨
      소프트웨어 목록도 훨씬 크고, 현대적인 데스크톱 일상 사용 운영체제로도 가능함. 다른 둘에 대해서는 그렇게 말하기 어려움
      왜 Linux가 아니냐고 하면, 나는 Linux를 원하지 않음. 기업 이해관계에 너무 짓눌려 있음
답변달기