Helios: Oxide Rack을 구동하는 illumos 배포판

 (github.com/oxidecomputer)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Helios는 Oxide Rack을 구동하는 illumos 배포판이며, 이 최상위 저장소의 도구와 문서가 여러 소프트웨어 consolidation을 묶어 전체 배포판 빌드를 관리함
  • 배포판은 illumos-gate stlouis 브랜치를 핵심 OS로 사용하고, Oxide 하드웨어용 추가 요소와 일부 패키징 변환을 더한 stock illumos 패키지를 주로 제공함
  • 모든 구성 저장소가 공개된 것은 아니며, 비공개 consolidation은 OXIDE_STAFF=no gmake setup으로 클론·빌드 대상에서 제외할 수 있음
  • 자체 패키지 빌드는 최신 Helios 환경에서 rustup, gmake setup, Rust 기반 helios-build를 사용하며, 개발 중에는 shadow compiler와 일부 검사를 끄는 quick build가 가능함
  • 빌드 결과는 로컬 부트 환경에 설치하거나 pkg.depotd로 다른 테스트 시스템에 배포하거나, 설치 없이 변환된 패키지 저장소만 만들어 검사할 수 있음

Helios의 역할과 구성

  • Helios는 Oxide Rack을 구동하는 illumos 배포판임
  • 전체 배포판은 여러 소프트웨어 consolidation으로 구성되며, 이 최상위 저장소의 도구와 문서가 빌드를 주도함
  • 공개 consolidation에는 다음이 포함됨
  • 아직 공개되지 않은 consolidation도 있음
    • amd-firmware: AMD CPU 펌웨어 바이너리 블롭, 향후 공개 예정
    • chelsio-t6-roms: Chelsio T6 NIC 펌웨어 블롭, 향후 공개 예정
    • pilot: Oxide 시스템 저수준 제어 유틸리티, 향후 공개 예정
    • dmar-report: DRAM margining 보고서 생성기, 향후 공개 예정
  • 비공개 저장소 접근 권한이 없으면 OXIDE_STAFF=no gmake setup으로 아직 공개되지 않은 소프트웨어의 클론과 빌드를 건너뛸 수 있음

시작 환경과 초기 설정

  • 자체 OS 패키지를 빌드하고 설치하려는 경우를 위한 절차이며, Helios 사용만 목적이면 helios-engvm의 사전 빌드 Helios 소프트웨어 정보를 참조하는 흐름임
  • 권장 시작점은 최신 Helios가 설치된 물리 또는 가상 빌드 머신임
    • 가상 머신 설치 세부사항은 helios-engvm에 있음
    • 물리 x86 시스템용 설치 미디어 정보도 같은 저장소에 있음
  • helios-engvm 절차로 VM을 만들었다면 필요한 패키지가 이미 설치되어 있어야 함
  • ISO 설치 프로그램이나 다른 방식으로 Helios 환경을 만들었다면 pkg:/developer/illumos-tools 패키지가 필요할 수 있음
    • 설치 여부는 pkg list developer/illumos-tools로 확인함
    • 누락된 경우 pkg install로 설치함
  • 최신 Helios 패키지를 사용하는 것이 좋으며, pkg update 후 출력되는 지시를 확인해야 함
    • 업데이트가 새 boot environment를 만들었다고 알리면 reboot로 활성화한 뒤 진행함
  • Rust와 Cargo는 Rust 프로젝트의 공식 바이너리를 rustup으로 설치함
    • 공식 설치 절차에서 sh 대신 bash를 사용함
    • 예시 명령은 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

저장소 클론과 helios-build

  • Helios 머신에서 저장소를 클론한 뒤 gmake setup을 실행함
    • tools/helios-build에서 Rust 기반 helios-build 도구가 빌드됨
    • 여러 저장소가 projects/ 아래에 클론됨
  • oxidecomputer GitHub 조직의 비공개 저장소 접근 권한이 없으면 다음처럼 공개 저장소만 사용하게 할 수 있음
    • OXIDE_STAFF=no gmake setup
  • helios-build 도구는 첫 빌드에 시간이 걸릴 수 있음
  • 초기 설정 단계는 예상 프로젝트 저장소를 클론하지만, 이후 업데이트나 브랜치 전환 같은 조작은 일부 저장소에만 수행됨
    • 어떤 저장소가 자동 업데이트 대상인지는 config/projects.toml의 auto_update에서 확인함
    • 그 외 로컬 클론은 일반 Git 저장소처럼 직접 브랜치 전환과 pull을 관리해야 함

illumos 빌드 방식

  • Helios의 핵심 OS 구성요소는 illumos-gate의 stlouis 브랜치에서 옴
  • Helios 시스템에 포함되는 패키지는 대부분 stock illumos에 Oxide 하드웨어용 추가 요소와 일부 경미한 패키징 변환을 더한 형태임
  • helios-build는 illumos 빌드를 쉽게 하기 위해 빌드 설정을 관리하고 illumos 빌드 도구를 호출하는 여러 wrapper를 제공함
  • 업스트림 illumos 문서의 Building illumos는 Helios 도구가 대신 수행하는 작업 대부분을 다룸
  • 개발 중에는 다음 명령으로 quick build를 수행할 수 있음
    • ./helios-build build-illumos -q
    • quick build는 최종 통합에서 요구하는 shadow compiler와 일부 검사를 비활성화함
  • 빌드 시간은 빌드 머신의 CPU 수와 로컬 스토리지 성능에 따라 달라짐
  • 전체 빌드 로그는 크며, 예를 들어 tail -F projects/illumos/log/nightly.log로 볼 수 있음
  • 빌드가 성공하면 projects/illumos/packages/i386에 패키지 저장소가 생기며, 이후 여러 방식으로 변환·설치할 수 있음

빌드한 패키지 설치와 배포

  • 로컬 빌드 머신에 설치

    • 새로 빌드한 패키지는 ./helios-build onu -t my-be-name으로 빌드 머신에 설치할 수 있음
    • 이 명령은 illumos 패키지를 변환·설치하고, -t로 전달한 이름의 새 Boot Environment를 생성함
    • 새 boot environment는 onu에 의해 활성화되며, 사용자는 재부팅해 해당 환경으로 들어감
    • boot environment 정보는 beadm(8)을 참조함
    • 재부팅할 때는 부트 메시지를 보고 boot loader와 상호작용할 수 있도록 콘솔에 있는 것이 좋음
    • 설치 후 pkg list -Hv system/kernel에서 system/kernel 패키지가 로컬 파일 기반 on-nightly publisher와 quick build 버전 3.0.999999에서 온 것을 확인할 수 있음

  • 다른 머신에 패키지 저장소 서버로 설치

    • 빌드 머신과 별도 테스트 머신이 있으면 빌드 머신의 pkg.depotd 패키지 저장소 서버를 사용할 수 있음
    • ./helios-build onu -D는 최근 빌드의 패키지를 변환하고 패키지 서버를 시작함
    • 예시에서는 0.0.0.0:7891에서 서비스함
    • 서버는 Control-C나 다른 종료 방식까지 계속 실행됨
    • 대상 머신에서는 pkgrepo info -s http://genesis:7891로 빌드 머신 접속을 확인함
    • stock Helios 시스템은 기본적으로 중앙 저장소 https://pkg.oxide.computer/helios/3/dev/를 사용하는 helios publisher 하나를 가짐
    • 테스트 머신에서 on-nightly publisher를 추가하고 우선 검색 대상으로 설정하며, 기존 helios publisher의 sticky 규칙을 완화함
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • 상황에 따라 업데이트 전에 entire 메타 패키지를 제거해야 할 수 있음
    • lipkg brand 기반 zone이 있는 경우 특히 해당될 수 있음
    • stock illumos의 onu 도구는 이를 자동으로 수행함
    • pkg update -nv로 dry-run을 실행해 quick build 패키지로 업데이트되는지 확인함
    • 예시에서는 325개 패키지가 업데이트되고, 새 boot environment 생성과 활성화, boot archive 재빌드가 필요함
    • 버전은 stlouis 브랜치 커밋 번호 기반 stock Helios 버전에서 3.0.999999 quick build 버전으로 바뀜
    • 실제 업데이트는 pkg update -v로 수행하며, 성공하면 새 boot environment로 재부팅해야 함
    • 재부팅 후 publisher 설정은 지속됨
    • 이후에는 새 빌드, 패키지 서버 재시작, 테스트 머신의 pkg update -v 흐름을 반복할 수 있음

  • 설치 없이 패키지만 생성

    • ./helios-build onu -P는 quick build 결과 패키지를 설치하지 않고 변환만 수행함
    • 변환된 패키지 저장소는 tmp/onu/repo.redist에 생성됨
    • 이 방식은 빌드 저장소의 내용을 검사할 때 유용함
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • 패키지 파일을 보존해 여러 빌드 출력 비교, 원격 시스템 전송, 이후 설치에 사용할 수도 있음

변경 작업과 반복 빌드

  • 시스템 변경 작업은 일반적으로 quick build 이후의 깨끗한 빌드 워크스페이스에서 시작하는 것이 좋음
  • 특정 소스 파일을 바꾸고 구성요소를 다시 빌드하려면 먼저 bldenv로 빌드 환경에 들어감
    • ./helios-build bldenv -q
    • 새 대화형 셸이 시작되고 PATH와 다른 변수가 올바르게 설정됨
  • 구성요소 디렉터리로 이동해 dmake -S -m serial install 같은 명령으로 빌드·설치할 수 있음
    • 예시는 cmd/id에서 id 명령을 빌드해 proto 영역에 설치함
  • 이런 targeted incremental edit-and-recompile 방식은 짧은 사이클로 변경이 컴파일되는지 확인하는 데 적합함

  • 가장 올바르지만 느린 선택지

    • 전체 OS를 다시 빌드할 수 있음
    • 이 과정은 가능한 범위에서 올바른 결과를 보장하는 유일한 절차임
    • 증분 방식 중 설명할 수 없는 문제가 생기면 full build를 먼저 시도하는 것이 좋음
    • 명령은 ./helios-build build-illumos -q

  • 보장은 없지만 빠른 선택지

    • dmake install로 proto 영역의 바이너리를 갱신했다면 전체 빌드 없이 패키지만 다시 생성해 설치할 수 있음
    • bldenv 안에서 $SRC/pkg로 이동해 dmake install을 실행함
    • 이후 업데이트된 패키지로 패키지 저장소 서버를 시작하거나 로컬 설치를 진행함

  • 파일 시스템을 직접 다루는 선택지

    • 운영체제는 결국 파일 시스템 안의 파일들이므로, 패키징 도구 외의 방식도 가능함
    • 수정한 바이너리를 빌드 시스템에서 바로 실행하거나 scp, rsync로 테스트 시스템에 복사해 실행할 수 있음
    • 바이너리가 라이브러리나 커널 변경을 필요로 하면 동작하지 않을 수 있음
    • 새 boot environment를 만들고 그 안의 파일을 조정할 수 있음
    • boot environment는 수정, 스냅샷, 클론, 부팅이 가능한 별도 ZFS 파일 시스템임
    • beadm create, beadm mount, beadm activate를 사용할 수 있음
    • 완전히 새 디스크 이미지나 ramdisk를 만들고 VM 또는 PXE로 부팅할 수 있음
    • Helios 전용 이미지 생성 도구는 helios-engvm image 도구에 있음
    • 이 도구들은 quick build 패키지나 임의의 추가 파일을 이미지 템플릿 수정으로 포함할 수 있음
    • 기반은 업스트림 illumos/image-builder임

OS 이미지 아카이브

  • Oxide compute sled용 OS 이미지를 빌드하는 과정에서 이미지 아카이브가 생성됨
  • 이 아카이브는 boot ROM과 root file system ramdisk 이미지를 포함함
  • JSON 파일의 메타데이터도 포함하며, omicron1 brand와 같은 형식을 사용함
  • 파일 내용은 Helios와 Oxide Rack의 물리 시스템에 OS 이미지를 다운로드·설치해야 하는 Omicron 일부 사이의 committed interface임
  • Omicron 사용에 필요한 파일은 최소한 다음을 포함함
    • oxide.json: 최소 v=1 키와 OS 이미지 식별용 t=os 키가 있는 메타데이터 헤더 파일
    • image/rom: 32MiB host boot ROM 이미지
    • image/zfs.img: 임의 크기의 host root file system ramdisk 이미지
  • 엔지니어링이나 진단 목적의 추가 파일이 있을 수 있음
    • 예: bldb 또는 nanobl-rs용 unix.z 압축 커널, cpio.z 압축 boot archive
    • 서로 다른 진단 기능을 나타내는 suffix를 가진 추가 ROM 파일 배열
  • 추가 파일은 committed interface가 아니며 향후 언제든 바뀔 수 있음
  • 이미지 아카이브를 해석하는 소프트웨어는 인식하지 못한 파일을 무시해야 함

라이선스

  • 저작권은 2026 Oxide Computer Company에 있음
  • 별도 표기가 없으면 모든 구성요소는 Mozilla Public License Version 2.0으로 라이선스됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이게 공개돼서 반갑고, 로컬에 배포해 최대한 많이 배워볼 생각임
    Oxide는 기술 스택과 함께 일하는 사람들 양쪽 모두에서 거의 꿈의 회사에 가까움

    • 홈페이지를 20초쯤 훑어보고는 “온프레미스 서버 구매를 위한 수직 통합인가? 커스텀 운영체제까지? 왜 굳이 프리미엄을 내지?”라는 느낌을 받았음
      그런데 곧 “서버 운영체제가 어차피 뭘 하길래? 가상 머신만 띄우면 되는 거 아닌가? Linux가 꼭 필요한 게 아니라 Linux 가상 머신을 띄울 수 있으면 되는 거 아닌가”까지 생각이 이어짐
    • SmartOS와 비교하면 어떨지 기대됨
      개인 인프라에서 SmartOS에 꽤 많이 투자해 왔지만, Joyent 인수 이후 미래가 걱정스러웠음
      Oxide 장비를 쓸 만큼 큰 조직에서 일했다면 좋겠음. 가짜 IBM PC AT식 호환성 구조물, 엉성한 BMC와 iDRAC, 하드웨어 RAID 컨트롤러 같은 걸 만지작거리지 않아도 된다면 엄청나게 좋을 듯함
    • Oxide는 정말 일해보고 싶은 유일한 회사에 가까움
      바깥에서 보기에는 Sun과 비슷한 느낌이고, 바로 그런 회사를 꿈꿔왔음
      다만 가족을 부양해야 하는 입장에서는 급여 구조상 감당이 안 됨. 아이가 대학을 졸업하고 더 이상 큰 수입이 필요 없어지면 그때쯤 꿈을 이룰 수 있을지도 모름

  • Oxide가 제공하는 게 뭔지 5살에게 설명하듯 알려줄 수 있나? 웹사이트를 봐도 감이 안 옴
    구매해서 온프레미스에서 쓰는 하드웨어+소프트웨어인지, PaaS인지, 또 다른 클라우드 제공자인지 모르겠음

    • 이미 관련 큰 스레드가 있어서 다운보트를 받는 것 같지만, 그건 좀 불공평해 보임
      결론부터 말하면 맞음. 구매해서 온프레미스에서 쓰는 하드웨어+소프트웨어임
      기존 온프레미스 클라우드 제품 대부분과의 차별점은, 하드웨어와 소프트웨어를 함께 잘 동작하도록 설계한 단일 벤더라는 점임. 소프트웨어는 가능한 한 오픈소스로 만들고 있고, 그래서 이런 발표도 나오는 것임
      대다수 제품은 여러 벤더의 제품을 묶고 사실상 통합을 판매함. Oxide는 그런 방식이 여러 문제를 낳고, 자사 제품이 그 문제를 해결한다고 봄
      또 하나는 SKU가 두 개뿐이라는 점임. 반 랙과 풀 랙만 있고, 1U 단위로 사는 게 아니라 랙 단위로 삼
      랙 전체를 하나의 응집된 단위로 설계하면 1U 폼팩터에서는 불가능한 일을 할 수 있음. 팬 이야기를 늘 한다는 농담이 있는데 사실임. 전통적인 1U보다 큰 슬레드를 쓰기 때문에 더 큰 팬을 쓸 수 있고, 낮은 RPM으로 돌릴 수 있어 전력을 절약함
      의도한 설계 선택이지만 부수 효과도 있음. 낮은 RPM 덕분에 서버가 훨씬 조용함. 초기 잠재 고객 중에는 데모 중 “이거 켜져 있는 거 맞나요?”라고 물은 사람도 있었을 정도임
      서버를 사는 이유가 조용함 때문만은 아니겠지만, 제품을 단순 통합 작업이 아니라 전체로 다시 생각하면 생기는 재미있는 예시임
    • 온프레미스용으로 완전히 통합된 컴퓨트·스토리지 솔루션이고, 클라우드식 API로 리소스를 프로비저닝하며, 오픈소스에 대한 약속도 함께 제공함

  • Oxide 사람들이 Sun 출신이라는 건 알지만, Linux가 아닌 걸 택한 데 실제 기술적 이점이 사업 가치 제안 측면에서 있나?
    illumos가 Linux보다 기술적으로 나은 부분은 알지만, 이걸 사는 고객에게 실제로 중요한지 모르겠음
    이념이나 전통 때문에 더 많은 컴퓨터를 팔지 못하게 되는 복잡한 문제를 여는 건 아닌가 싶음
    Linux 컨테이너 워크로드를 운영하는 입장에서는, 이게 근본적으로 비-Linux라는 사실이 구매 이유가 아니라 구매를 망설일 이유가 됨. Linux 바이너리를 수정 없이 실행할 수 있다는 건 알고 있음

    • 제품에서 “참고로 안에는 illumos가 있고, 그래서 이 랙을 사야 합니다”라고 말하는 식은 아님
      고객에게 드러나는 제품 세부사항이 아니고, 대부분은 그 사실조차 모를 가능성이 큼
      고객이 신경 쓰는 건 랙이 효율적이고 안정적이며 필요에 맞는지임. 여기서 Linux 대신 illumos를 고른 건 그 가치를 효과적으로 제공하기 위한 선택임
      물론 비슷한 제품을 Linux 위에 만들 수 없다는 뜻은 아니고, 우리는 illumos가 목적에 더 맞는다고 판단했음
      이 결정은 팀과 함께 RFD[1] 형태로 내렸고, 번호는 #26이지만 현재 공개되어 있지는 않음. 진지하게 검토한 선택지는 Linux의 KVM과 illumos의 bhyve였고, 꽤 긴 문서임
      결국 하나의 길을 골라야 했고, 우리는 이 길을 택했음. 이 부분을 직접 개발하진 않지만, 지금까지 장애물이 됐다고 볼 이유는 없었고 오히려 맞는 선택일 가능성이 큼
      왜 비-Linux라는 점이 구매 반대 이유가 되는지 궁금함. 추가 설명을 해주면 좋겠음. 아, 아래 댓글을 봤음: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios는 랙의 구현 세부사항일 뿐이고, Hubris[0]처럼 사용자나 애플리케이션에 보이는 요소가 아님. 랙 사용자는 가상 머신을 프로비저닝함
      왜 다른 것이 아니라 illumos 파생을 썼는지는 첫 랙을 출하했을 때의 Q&A[1]에서 조금 다뤘고, 오늘 나중에 할 녹화 토론[2]에서도 다시 설명할 예정임
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • 임베디드나 어플라이언스 영역에서 Linux는 악몽이 되기 쉬움
      플랫폼 엔지니어들이 최신 커널, 드라이버, 핵심 라이브러리 문제를 고치느라 하루를 보내고, 실제 애플리케이션이 그 위에 의존하게 됨
      아니면 IoT 벤더 99%처럼 기본 운영체제를 절대 업데이트하지 않고, 그걸 노리는 활성 익스플로잇이 없기를 기도하는 길로 감
      그래서 중견 회사들이 CentOS 문제에 많이 울었음. 비용을 내고 완전한 RHEL 설치를 운영하지 않아도, 비교적 안정적인 플랫폼에 머물면서 보안 업데이트를 받을 수 있었기 때문임
      10년쯤마다 모든 의존성을 다시 봐야 했지만, 1~2년 업데이트 주기를 따라가는 것보다는 훨씬 쉬움. 어떤 시스템은 검증 기간만 6개월 이상이라 그 주기가 너무 짧음
      이건 거의 Linux만의 문제에 가깝고, *BSD 같은 대안들은 Linux가 주는 것 대부분을 제공하면서도 이런 지속적인 깨짐이 훨씬 적음
    • 선택지가 생기는 건 건강한 일이고, Oracle이 Sun을 산 뒤 우주가 조금 회복되는 느낌마저 듦
      Oxide 시스템을 한데 묶어낼 팀으로 이보다 나은 사람들을 상상하기 어려움
      지금은 Linux만으로 일하는 엔지니어지만, 고가치 워크로드를 돌릴 수 있는 또 하나의 강한 Unix가 있던 시절이 그리움
      Linux의 openvswitch와 Solaris의 Crossbow SDN 기능을 비교하면 언제든 Crossbow를 택하겠음
      Linux가 잘못됐다는 뜻은 아니지만, 도구들이 각자 길을 가며 복잡성을 만들고, 그 위에 더 복잡한 도구로 다시 추상화해야 하는 식이라 “마스터 플랜” 수준의 응집력이 몹시 부족함
    • 고객은 이 위에서 가상화된 운영체제를 실행함
      Azure Host OS, Bottlerocket, Flatcar 같은 것과 크게 다르지 않음
      전체 스택을 알고 있고, 커널 코드 일부는 Sun 시절부터 자기들이 갖고 있으며, 보안 평가 때문에 소스 접근을 원하는 고객에게 공개 가능하다는 점이 중요함

  • illumos를 잘 몰라서 웹페이지를 봤더니 맨 처음에 “illumos is a Unix operating system”이라고 되어 있음
    illumos는 macOS처럼 실제 Unix인가, 아니면 GNU/Linux처럼 Unix 계열 운영체제인가?

    • 실제 Unix임. Wikipedia 설명이 꽤 좋음: https://en.wikipedia.org/wiki/Illumos
      OpenSolaris 기반이고, OpenSolaris는 System V Release 4(SVR4)와 Berkeley Software Distribution(BSD)에 기반함. Illumos는 커널, 장치 드라이버, 시스템 라이브러리, 시스템 관리를 위한 유틸리티 소프트웨어로 구성됨. 이 코어는 Linux 커널이 여러 Linux 배포판의 기반이 되는 것과 비슷하게, 여러 오픈소스 Illumos 배포판의 기반이 됨
    • 아무도 Open Group의 Unix Branding 인증 테스트를 통과시키기 위해 돈을 내지 않았음
      https://www.opengroup.org/openbrand/register/
      그래서 UNIX™ 상표는 쓸 수 없음
      하지만 안에는 AT&T Unix 커널과 사용자 공간 소스가 들어 있음
      PDP-11 Unix System III: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...
      IllumOS: https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...
    • 법적으로는 NetBSD도 실제 Unix가 아님. 그 브랜드가 사람들이 생각하는 의미를 갖는 건 아님
    • Sun에서 Ian Murdock이 Project Indiana라는 이름으로 작업했던 Solaris의 오픈소스 분기였고, UNIX SVR4에서 내려옴
    • 실제 Unix임. Solaris 계열로 알고 있음

  • Oxide를 응원하지 않는 건 아니지만, 제품이 아직 너무 틈새이고 초기 단계라 실제 기업들이 한동안 이걸 살 거라고 상상하기 어려움
    지난여름 말에야 첫 고객에게 첫 랙을 출하했고, 그 고객도 Idaho National Laboratory임
    지금 이런 도박을 할 수 있는 곳은 사실상 국가 연구기관 정도로 보임

    • 작년 10월 발표 때 고객 두 곳이 언급됐음: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Oxide 고객에는 Idaho National Laboratory와 한 글로벌 금융 서비스 조직이 포함됨. Fortune 1000 기업에 대한 추가 설치도 향후 몇 달 안에 완료될 예정임
    • 존재 초기의 모든 제품이 다 이런 모습임
      다른 방식으로 출시하려고 계획한다면 출시 전부터 회사를 망친 셈임. 운 좋게 살아남는 소수도 있지만, 그게 스타트업 10개 중 9개가 실패한다는 통계에 기여함
      첫 고객군에 극도로 집중해서 캐즘을 건너야 하고, 그다음이 대중 시장임
    • 언젠가는 더 작고 저렴한 홈랩 제품도 내줬으면 좋겠음
      사람들이 배우거나 스타트업이 써보면서, 나중의 랙 판매나 채용으로 이어질 수 있음
    • 최근 상장한 기술 회사에서 일하는데, 온프레미스를 평가할 때 Oxide를 진지하게 고려했음
      아직도 “온프레미스라니… 으”라고 생각하는 사람들에게도 제안이 먹힘
      자기 하드웨어 위에서 클라우드 같은 경험을 주는 것으로 보임
      Dell만큼 싸기만 했다면 좋았을 텐데
    • 우리 회사도 검토했고 제품에는 매우 깊은 인상을 받았음
      유일한 문제는 범용 컴퓨트용으로 만들어져 있어서, 우리는 더 빠른 프로세서 옵션이 정말 필요했다는 점임

  • 문서가 명확하고 직관적으로 보이는 점이 정말 좋음. 개인적으로 illumos 커뮤니티가 역사적으로 어려움을 겪어온 영역이 문서였다고 봄
    새 소스 릴리스에서 consolidations 이야기를 보니 따뜻한 느낌이 듦. 다만 저장소 구성을 크게 오해한 게 아니라면 전통적인 gate 패러다임과는 다른 방향으로 보임
    몇 가지, 주로 도구 관련 질문이 있음. 왜 gmake인가? 나중에 dmake도 어차피 필요해 보이는데
    안내에서는 rustup을 bash로 명시해서 실행하라고 되어 있는데, 업스트림 결함인가 아니면 로컬 sh가 POSIX와 완전히 호환되지 않는 건가?
    내부 개발은 어떻게 하나? Oxide 사람들은 illumos 워크스테이션을 쓰나, 아니면 전부 가상 머신에서 개발하거나 서버에 SSH로 들어가나?
    왜 MPL인가? GPL 호환성 때문인가?

    • helios에서 직접 일하지 않아서 전부 답할 수는 없지만 일부는 답할 수 있음
      Oxide 사람들이 illumos 워크스테이션을 쓰는지, 가상 머신이나 서버 SSH로 개발하는지에 대해서는 여기 썼음: https://news.ycombinator.com/item?id=39181727
      다만 실제로 illumos를 워크스테이션에서 쓰는 사람들도 있음
      MPL에 대해서는 여기 있음: https://news.ycombinator.com/item?id=39181844
      그 댓글에서 “왜”에 대해서는 깊게 말하지 않았는데, 가능성 공간에서 좋은 절충이라고 봄. BSD보다 더 카피레프트적이지만, GPL보다는 덜 제한적임
    • 그건 업스트림 문제로 알고 있음
      대부분의 오픈소스 프로젝트처럼 거기에도 Linuxism/Bashism이 있음
    • 역사적 이유로 핵심 운영체제를 빌드할 때는 dmake를 쓰지만, 다른 consolidation에서 새 Makefile을 만들 때는 GNU make(gmake) 를 권하는 편임
      널리 사용할 수 있고, 다른 플랫폼에서도 가능하며, 더 현대적인 기능이 있음

  • 소프트웨어가 오픈소스인 건 훌륭하지만, 다른 하드웨어에 배포해서 쓸 수 있을까?
    어떤 이유로든 회사가 더 이상 Oxide 랙을 구매할 수 없게 되면 인프라를 처음부터 다시 시작해야 하나, 아니면 Oxide 하드웨어를 중심으로 계속 확장할 수 있나?

    • 우리 하드웨어 밖에서 바로 유용할 가능성은 높지 않지만, 주된 기능은 가상 머신 배포임
      구매한 Oxide 랙을 더 이상 쓰지 않기로 한다면, 가상 머신을 후속으로 선택한 인프라로 옮기면 됨

  • Linux/Mac/BSD가 아닌 커스텀 Unix에서 회사들이 어떤 워크로드를 돌리고 싶어 할지 정말 궁금함
    더 성숙한 운영체제 다양성이 생기는 건 응원하지만, 최종 사용자가 누구이고 어떤 필요를 가질지 감이 안 옴

    • Oxide 랙에서 프로비저닝하는 컴퓨트는 가상 머신임. FreeBSD에서 bhyve를 포팅했고 라이브 마이그레이션도 추가했음
      필요에 몰려 있다면 Windows Server도 부팅할 수 있을 것 같음
      Illumos를 쓴 이유는 Sun, Joyent 등에서 온 사람이 많아서 자연스러운 편향이 있는 것도 맞음
      하지만 이건 IBM 호환 x86 개인용 컴퓨터가 아니라는 꽤 설득력 있는 이유도 있음. BIOS도, UEFI도, 전통적인 BMC도 없고, 최신 x86을 쓰면서도 독점 펌웨어와 바이너리 블롭을 가능한 한 많이 제거한 것으로 보임
      각 슬레드에는 서비스 프로세서와 하드웨어 신뢰 루트가 있고, 이것이 CPU를 직접 부팅하고 AMD 트레이닝 블롭을 로드한 뒤 운영체제를 부팅함
      현재 자기들만 가진 컴퓨터를 위해 그런 변경을 Linux나 BSD에 업스트림하기는 어려울 것임. 결국 자체 다운스트림 포크를 유지해야 하고, 운영체제의 견고성에 책임질 다른 주체도 없으니, 수년간 지원하고 개발해온 운영체제를 쓰는 편이 낫다는 판단이 됨
    • 이건 제품에서 사용자에게 보이는 세부사항이 아님
      고객은 랙에서 가상 머신을 실행하지, 애플리케이션을 illumos용으로 빌드하지 않음
      목표를 달성하는 데 필요한 어떤 운영체제든 그 가상 머신 안에서 돌리게 됨
    • ZFS는 illumos에서 네이티브이고, 컨테이너화에 해당하는 기능 등도 꽤 훌륭함
      충분한 인력을 채용할 수 있다면, 클라우드의 서버들이 반드시 같은 운영체제일 필요는 없다는 주장도 설득력 있음
    • 이게 Linux가 아니라는 걸 알 일도 없을 것임
      이 운영체제 위에서 코드를 실행하는 게 아니라, 이 운영체제가 제공하는 가상 머신 위에서 코드를 실행함

  • Oxide를 처음 어떻게 알게 됐는지 궁금함
    나는 어쩌다 그들의 팟캐스트에 닿았는데, 내게는 엄청난 마케팅처럼 느껴짐. 제품을 직접 파는 것만 빼고 모든 걸 함
    각 에피소드 마지막에 짧은 피치를 넣는 것도 좋을 수 있겠음
    “컴파일러가 뭔가를 하게 만드는 데 정말 힘들었다” 같은 이야기를 하다가 옛날이야기로 빠지는 식임
    그래도 계속 이야기해줬으면 하고, 잘되길 바람

    • 원래 팟캐스트였던 On The Metal은 미리 녹음한 자기 홍보 2~3개를 지나치게 반복해서 악명 높았고, 팬이 직접 광고를 녹음해 틀어달라고 할 정도였음
      반면 Oxide and Friends는 전통적인 팟캐스트라기보다, Twitter에서 시작해 지금은 Discord에서 진행되는 라이브 “스페이스”나 그룹 콜 녹음에 가까움
      팟캐스트로만 듣기보다는 라이브로 참여할 때 가장 잘 소비되는 형식이라고 봄. 라이브로 들어보면 녹음본의 분위기를 훨씬 잘 이해하게 됨
      https://oxide.computer/podcasts/oxide-and-friends
    • 예전에 Twitter에서 @jessfraz를 팔로우하고 있어서, Oxide가 처음 발표됐을 때 거기서 알게 됨
    • Oxide가 처음 발표됐을 때 Pentagram이 브랜딩을 공개한 것을 보고 알게 됨

  • 서버 랙을 발표했을 때부터 이걸 기대했음
    만약 Oxide가 망한다면 아무도 문진이 된 장비를 원하지 않을 테니까

    • 분명히 말하자면, 그 “문진 문제”는 우리에게도 매우 중요함
      MPL은 사본이 GitHub에 공개로 올라와 있는지 여부를 따지지 않는다는 점을 기억할 필요가 있음
      변호사는 아니지만, 비고객이 코드를 열람할 수 있는지와 무관하게 고객에 대해서는 MPL상 의무가 있음
답변달기