Helios: Oxide Rackを動かすillumosディストリビューション

 (github.com/oxidecomputer)
1 ポイント 投稿者 GN⁺ 2024-01-30 | 1件のコメント | WhatsAppで共有
  • 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が可能
  • ビルド結果はローカルのboot environmentにインストールすることも、pkg.depotdで別のテストシステムへ配布することも、インストールせず変換済みパッケージリポジトリだけを作って確認することもできる

Heliosの役割と構成

  • HeliosはOxide Rackを動かすillumosディストリビューション
  • ディストリビューション全体は複数のソフトウェアconsolidationで構成され、この最上位リポジトリのツールとドキュメントがビルドを主導する
  • 公開されているconsolidationには次が含まれる
  • まだ公開されていないconsolidationもある
    • amd-firmware: AMD CPUファームウェアのバイナリblob、今後公開予定
    • chelsio-t6-roms: Chelsio T6 NICファームウェアblob、今後公開予定
    • 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が1つある
    • テストマシンでは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領域のバイナリを更新したなら、OS全体を再ビルドせずにパッケージだけ再生成してインストールできる
    • 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の一部との間でコミットされたインターフェースになっている
  • 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でライセンスされる

関連記事

1件のコメント

 
GN⁺ 2024-01-30
Hacker News のコメント

  • これが公開されてうれしい。ローカルにデプロイして、できるだけ多くを学んでみるつもり
    Oxideは、技術スタックとそこで働く人たちの両面で、ほとんど夢の会社に近い

    • ホームページを20秒ほど眺めて、「オンプレミスサーバー購入のための垂直統合なのか？カスタムOSまで？なぜわざわざプレミアムを払うのか？」という印象を受けた
      でもすぐに「サーバーOSはそもそも何をするんだ？仮想マシンを立ち上げるだけでいいのでは？必要なのはLinuxそのものではなく、Linux仮想マシンを動かせることではないのか」と考えがつながった
    • SmartOSと比べてどうなのか楽しみ
      個人インフラではSmartOSにかなり投資してきたが、Joyent買収後の将来が心配だった
      Oxideの機器を使うほど大きな組織で働いていたらよかったのに。偽物のIBM PC AT的な互換性の構造物、ひどいBMCやiDRAC、ハードウェアRAIDコントローラーのようなものをいじらずに済むなら、ものすごく良さそう
    • Oxideは、本当に働いてみたいほぼ唯一の会社
      外から見る限りではSunに似た雰囲気で、まさにそういう会社を夢見てきた
      ただ、家族を養う立場では給与体系的に厳しい。子どもが大学を卒業して、もう大きな収入が必要なくなった頃には、その夢を叶えられるかもしれない

  • Oxideが提供しているものを、5歳児に説明するように教えてもらえる？ウェブサイトを見てもピンとこない
    購入してオンプレミスで使うハードウェア＋ソフトウェアなのか、PaaSなのか、また別のクラウドプロバイダーなのか分からない

    • すでに関連する大きなスレッドがあるのでダウンボートされているようだけど、それは少し不公平に見える
      結論から言うと、その通り。購入してオンプレミスで使うハードウェア＋ソフトウェアだ
      既存のオンプレミスクラウド製品の大半との違いは、ハードウェアとソフトウェアがうまく連携するように設計した単一ベンダーだという点。ソフトウェアは可能な限りオープンソースにしており、だからこそこうした発表も出てくる
      ほとんどの製品は複数ベンダーの製品を束ね、実質的にインテグレーションを売っている。Oxideはその方式がさまざまな問題を生み、自社製品がそれを解決すると見ている
      もう1つはSKUが2つしかない点。ハーフラックとフルラックだけで、1U単位で買うのではなくラック単位で買う
      ラック全体を1つのまとまった単位として設計すると、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% のように、ベース OS を絶対に更新せず、それを狙う実用中のエクスプロイトが存在しないことを祈る道を選ぶ
      だから中堅企業は 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についてよく知らなかったのでWebページを見たところ、冒頭に「illumos is a Unix operating system」と書かれている
    illumosはmacOSのような本物のUnixなのか、それともGNU/LinuxのようなUnix系OSなのか？

    • 本物の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月の発表では顧客2社が言及されていた: 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 がある
    • 歴史的な理由から中核OSをビルドするときはdmakeを使うが、別のconsolidationで新しいMakefileを作るときは GNU make(gmake) を勧めることが多い
      広く利用でき、他のプラットフォームでも使え、より現代的な機能がある

  • ソフトウェアがオープンソースなのは素晴らしいが、ほかのハードウェアにデプロイして使えるのだろうか？
    何らかの理由で会社がこれ以上 Oxide ラックを購入できなくなった場合、インフラをゼロからやり直す必要があるのか、それとも Oxide ハードウェアを中心に拡張を続けられるのか？

    • 私たちのハードウェア以外ですぐに役立つ可能性は高くないが、主な機能は仮想マシンのデプロイである
      購入した Oxide ラックをもう使わないことにしたなら、仮想マシンを次に選んだインフラへ移せばよい

  • Linux/Mac/BSD ではないカスタム Unix で、企業がどんなワークロードを動かしたいと思うのか本当に気になる
    より成熟した OS の多様性が生まれるのは応援したいが、エンドユーザーが誰で、どんなニーズを持つのか想像がつかない

    • Oxide ラックでプロビジョニングするコンピュートは仮想マシンである。FreeBSD から bhyve を移植し、ライブマイグレーションも追加した
      必要に迫られれば Windows Server もブートできると思う
      Illumos を使った理由は、Sun や Joyent など出身の人が多く、自然なバイアスがあるのも確かである
      しかし、これは IBM 互換 x86 パーソナルコンピューターではない、というかなり説得力のある理由もある。BIOS も UEFI も従来型の BMC もなく、最新の x86 を使いながらも、プロプライエタリなファームウェアやバイナリブロブを可能な限り取り除いているように見える
      各スレッドにはサービスプロセッサとハードウェアの信頼の起点があり、それが CPU を直接ブートし、AMD のトレーニングブロブをロードしたうえで OS をブートする
      現時点で自分たちだけが持っているコンピューターのために、そうした変更を Linux や BSD にアップストリームするのは難しいだろう。結局は独自のダウンストリームフォークを維持する必要があり、OS の堅牢性に責任を持つ別の主体もいないため、何年もサポートし開発してきた OS を使うほうがよい、という判断になる
    • これは製品上、ユーザーに見える詳細ではない
      顧客はラック上で仮想マシンを実行するのであって、アプリケーションを illumos 向けにビルドするわけではない
      目的を達成するのに必要な任意の OS を、その仮想マシンの中で動かすことになる
    • ZFS は illumos でネイティブであり、コンテナ化に相当する機能などもかなり優れている
      十分な人材を採用できるなら、クラウドのサーバーが必ずしも同じ OS である必要はない、という主張にも説得力がある
    • これが Linux ではないと気づくこともないだろう
      この OS の上でコードを実行するのではなく、この OS が提供する仮想マシンの上でコードを実行するのだから

  • 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 上の義務がある