← 2026-10-15 の一覧へ戻るホーム
Virtual Oxide Labs：完全な Oxide ラックのシミュレーション

2026/10/15 3:21

Virtual Oxide Labs：完全な Oxide ラックのシミュレーション

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

本稿の核心となるメッセージは、Oxide Product Assurance チームが、標準ソフトウェアを一切変更せずに、Voxel という高忠実度仮想環境全体でソフトウェアスタックを厳格にテストすることで、製品化における信頼性を保証することです。この「未変更コード」への厳格な adherence（遵守）により、テスト結果は実際のハードウェア上での実世界のパフォーマンスと正確に対応します。従来のシステムや特別な「テスト用バージョン」と異なり、このアプローチでは物理プロトタイプを各チェックに必要とするのではなく、ネットワークプロトコルやセキュリティチップなどの重要なコンポーネントに対して、高度なエミュレーターを用いて検証を行います。

Voxel は illumos オペレーティングシステム上で動作し、Rust を利用して複雑なスタックをエミュレートするとともに、Propolis による仮想化や SoftNPU によるネットワークシミュレーションといったツールを採用しています。純粋な物理ベースのテストからこれらの高度な仮想手法への移行により、現在は root of trust コンポーネントに対するマイクロコントローラーのシミュレーションが可能になっています。具体的には、Voxel は Cortex-M7 と Cortex-M33 デバイスをエミュレートし、単スレッド環境内で命令、時間、割り込みをシミュレートします。時間が経過した時間を基準とするのではなく命令数を基準とした時間エミュレーションロジックを改善することで、チームはエミュレーターのばらつきにかかわらず正確な速度会計を保証し、これにより企業がハードウェア導入に自信を持ち、継続的インテグレーションパイプラインを清潔かつ効率的に保つことができます。

最近の進展では、AMD Ryzen 9 9955HX プロセッサと 96GB の RAM を搭載した Minisforum MS-A2 ミニ PC が標準的なハードウェアであっても既に 6 つの仮想サーバーを実行できることが示されており、将来的な大規模なマルチラック構成の可能性を示唆しています。最適な動作を実現するため、Voxel は MPL 2.0 ライセンスの下で利用可能であり、少なくとも 16 スレッドと 64GB の RAM を持つ Helios OS 環境が必要です。時間が経過した時間を基準とするのではなく命令数を基準とした時間エミュレーションロジックを改善することで、チームはエミュレーターのばらつきにかかわらず正確な速度会計を保証し、これにより企業がハードウェア導入に自信を持ち、継続的インテグレーションパイプラインを清潔かつ効率的に保つことができます。

※注：元の要約の 2 段落最後の部分で「時間エミュレーション」に関する記述がやや重複していました。上記の改善版では、具体的な技術詳細（命令数や CPU モデルなど）を一貫した物語に統合するとともに、最後の繰り返しを修正し、ライセンス要件で結んでいます。

本文

Oxide ラックスケール開発のための「Voxel」とは？

🛑 開発における課題と解決策

ラックスケールハードウェアのテストへの障壁

  • 入手性の低さ: 完成品は瞬く間に顧客のデータセンターへ送られ、開発チームが触れにくい。
  • 公平性と合理性: Oxide プロダクト保証チームとしては、アクセス制限を「不公平」かつ「理にかなった」と捉える。

必要な対策（重要）

以下を**「テスト用リリース」を切り出すことなく**継続的インテグレーション（CI）プロセスと統合する必要があります：

  • 🌐 多様な顧客のネットワークトポロジーの再現
  • 🎮 実際に運用中のコントロールプレーンの動作検証
  • 📦 ソフトウェア最新バージョンのテスト
  • ⚙️ 自社製ハードウェア部品（スイッチ、マイコンコントローラー等）の代表動作

🏗️ テスト環境の構築戦略

1. 「ラックレット（Racklettes）」の活用

商業販売向けの製品とは異なる小型テスト用ラック。

  • 構成: スレド 4 台、スイッチ 2 つ。
  • 特徴:
    • 本物のラックと同様の初期化・動作が可能。
    • 商業的には不採算だが、テスト用途には極めて効果的。
  • 現状保有数: 4 台（近々 8 台へ増備予定）。
  • 活用方法: ハードウェアとソフトウェア要件のあらゆる組み合わせ検証に利用。

2. シミュレーション手法（Omicron）

  • 詳細ドキュメント: 「How to Run Simulated」「The Full(er) How to Run Guide」参照。
  • 機能: コントロールプレーンの大部分を、独立して・並行して・異なるシミュレーション下で動作させる。

🎲 Voxel（Virtual OXidE Labs）とは？

概念と歴史的背景

「Voxel」とは、単一ハードウェアユニットに詰めた莫大な忠実度を持つ仮想ラボです。

  • 精神的後継者:以前の仮想ラボ「a4x2」の進化版。
  • 名前の由来: 「Volume Element（体積要素）」＋「Pixel（画素）」＝ 「Voxel」（ボキセル）。3 次元空間上の点を表す単位。
  • プライム・ディレクティブ: Bryan Cantrill の提唱通り、ハッキングや改修なしに標準の Oxide ソフトウェアを使用する。

提供可能な忠実な構成

Rust 上構築された illumos ベースの完全なエミュレーションスタック：

  • スレド仮想化: Propolis による管理。
  • ネットワーク構成:
    • Debian + FRR を用いた BGP（番号指定あり・なし）。
    • 静的ネットワークリング。
  • スイッチング: Oxide 独自のソフト NPU（SoftNPU）／ソフトウェア実装の P4 スイッチ。
  • マイコン制御: サービスプロセッサ（SP）とトラストの根元（RoT）向けのシミュレーション/エミュレーション。

小規模環境での稼働例

自宅用ミニ PC（Minisforum MS-A2: Ryzen 9 9955HX / 96GB RAM）での検証結果：

  • スレド数: 容易に 6 つ起動可能。
  • 構成モード:
    • 単一ラック形式。
    • マルチラック構成（別々の 2 ラック＋1 つの管理プレーン）。
  • 必要条件: Oxide Helios OS、高速な NVMe ドライブのみ。
    • 起動後約10 分で完全な Oxide ラックインフラストラクチャ（スイッチ含む）構築完了。

📦 イメージの作成手順

再利用可能なスナップショットを標準的プロセスで作成します。

スレドの種類

  • 通常のスレド: gimlet（第 1 世代）、現在では cosmo。
  • スクリメット（Scrimlet）: サイドカー・スイッチに接続され、スイッチゾーンを実行。

作成フロー

  1. 「スレド」名義の仮想マシンを作成。
  2. コントロールプレーン（Omicron）をインストール。
  3. 構成直前時点でスナップショットを取得（「起動準備のあるスレド」完成）。

インストール方法の選択肢

  • ソースコードから: GitHub の Omicron リポジトリをクローンし、ローカルソースを使用（開発時推奨）。
  • TUF レポジトリから: The Update Framework (TUF) と Buildomat を用い、Tufaceous でパッケージ化されたリリースを使用。

コマンド例：TUF からのイメージ作成

以下のコマンドを実行すると、スレド構成の中核要素が抽出されます。

$ pfexec ./target/debug/voxel image create --from-tuf ../5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip 5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c
[voxel] TUF source ../5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip: system version 23.0.0-0.ci+git5d176e0be7e, omicron 5d176e0be7e
[voxel] extracted 12 zones from ../5d176e0be7e5cc0d3288c1bef10005ec31f2cd7c.zip
[voxel] extracted 3 measurement corpus artifacts
[voxel] extracting host artifacts -> /export/home/helios/voxel-rawfix/target/debug/../../voxel-image/.tuf-host
[voxel] host boot image 1258295296 bytes, phase 1 rom 33554432 bytes
[voxel] extracted SP/RoT firmware -> /export/home/helios/voxel-rawfix/target/debug/../../voxel-image/.tuf-fw/ca9184058bd7

コントロールプレーンの準備完了

十分な展開・ステージングの後、VM が起動し、最終的なイメージ書き込みを行います。

[voxel] ready: voxel-cp version=unknown unpacked_artifacts=18 built=2026-09-06T21:37:58
[voxel] clearing device-instance map, halting
[voxel] flushing, up to 25s
[voxel] stopping hypervisor
[voxel] writing voxel image voxel-cp-5d176e0be7e-tuf

結果: 生成されたのはZFS スナップショットであり、後ほどラック構築に再利用可能。

🚀 起動プロセス概要

既にコントロールプレーンがインストールされている状態でラックを起動します。必要な要素：

  • "frr" イメージ: ネットワーク用 Debian VM。
  • コントロールプレーンイメージ: 上記で作成したもの。
  • voxel-init エージェント: 各仮想スレドへの割り当て管理。

主な手順と自動化

多くの複雑なステップがありますが、以下の流れで自動実行されます：

  1. 信頼材料の生成
    • sprockets PKI の形式で証明書などを発行。
  2. ファームウェアのフラッシュ
    • エミュレートされた STM32H753 および LPC55 マイコンコントローラーへ、Hubris ファームウェアをインストール。
  3. ネットワークトポロジースイート（Falcon）の起動
    • SimNet と VNIC ペアを用いてトポロジー構築。
    • スレド（g0, g1, g2 など）をステージング。
  4. Propolis VM の起動
    • 6 つのスレド起動（3 つネットワーク駆動、3 つ Oxide スレド）。
  5. voxel-init の実行
    • NAT およびアップリンクアドレスの設定。
    • アンダーレイ設定構築。
    • エミュレート起動ディスクへの M.2 パーティション配置。
    • 5 つの U.2 データディスクラベリング。
    • ホストフェーズ 2 イメージおよびインストールデータの種まき。
    • スクリメットの割り当てとアイデンティティ記憶（スイッチエネフォアサー）。
    • sled-agent の起動（コントロールプレーンの各スレド用設定層）。
    • wicketd コメッショニング API への接続によるラック初期化完了。

注意点:

  • 「エミュレートされたマイコンコントローラー」部分は、ハードウェアを別々のコードピースとして表現している点で真の再現とは異なりますが、他は完全に正しく動作します。
  • プロダクション環境のように RoT で証明書が製造時に設定されていませんが、実行時間を妨げる影響はないため、当面はこの方式で運用可能です。

⚙️ サービスプロセッサ（SP）のエミュレーション技術

従来手法の限界

  • 過去は SP の機能を返すためのスタブ構造「SpSim」を使用。
  • しかしこれはシミュレーションに過ぎず、実際のテストケースにおける忠実度は不足していた。

新たなアプローチ：sp-emu（オープンソース）

illumos および Linux（x86/ARM）向けに、実際のCortex-M7およびCortex-M33デバイスをエミュレートするツール 

sp-emu
を開発。

  • 機能:
    • シングルスレッド内で動作。
    • 「命令数」「時間」「割り込み」の 3 つを忠実に再現。
    • Hubris ファームウェアを直接フラッシュ可能。
  • 通信方法: Management Gateway Service (MGS) および IPCC を介した対話。

ハードウェアエミュレーションの工夫（重要）

シリコン上の動作を擬似的に実行するために、以下の工夫がなされています：

  1. 時間の扱い:
    • エミュレータはウォールクロックを使用せず、Hubris の 1ms SysTick をスケジューリング基準にするため、時間を「命令数」に置き換える。
  2. 例外ハンドリング:
    • Cortex-M コアでの例外発生からハンドラ開始までの間をモデル化。
    • self.exception_entry
      関数がハードウェア動作をカバーする。

代表的なコードパターン（時間処理）

if self.systick == 0 {
    self.systick = self.syst_rvr;
}
self.systick -= 1;
if self.systick == 0 {
    self.systick = self.syst_rvr;
    self.tick_events = self.tick_events.wrapping_add(1);
    if self.syst_csr & 2 != 0 && self.mode == Mode::Thread && !self.primask {
        self.exception_entry(15, bus); // SysTick exception
    }
}

プリエンプティブスケジューリングの実装

Hubris はプリエンプティブではないが、タスクのスケジューリングを実行するため、IRQ や PendSV を優先度に基づいて処理します。

if let Some(irq) = bus.next_irq() {
    if self.basepri == 0 || (bus.irq_prio(irq) as u32) < self.basepri {
        bus.clear_pending(irq);
        self.exception_entry(16 + irq as u32, bus);
        return;
    }
}
if bus.take_pendsv() {
    self.exception_entry(14, bus);
}

主ループ構造（ハートビート）

すべての機能はこの無限ループによって駆動されます。

loop {
    cpu.step(&mut bus, host.as_mut())?; // 一つの Thumb-2 命令
    cpu.maybe_tick(&mut bus);           // SysTick: 時間は命令数
    cpu.maybe_interrupt(&mut bus);      // NVIC および PendSV デリバリー
    if cpu.cycles % 4096 == 0 {
        bus.pump_eth(host.as_mut());    // MGS パケット入出力
        bus.pump_uart(host.as_mut());
    }
}

補足: 

cycles
フィールド名は存在しますが、実際のサイクル時間ではなく**「ごまかす」ための計数値**です。

💻 ユーザーエクスペリエンスと操作ツール

コネクティビティ管理 (
voxel
コマンド)

単一システムで多数のコンポーネントを動作させる場合、接続先や構成を理解しやすいよう、

voxel
はコネクティビティツールとしても機能します。

スレドへの直接ログイン例

$ pfexec ./target/debug/voxel host login g0
[voxel] ssh root@192.168.68.167  (g0 global zone)
The illumos Project     helios-3.0.23976        May 2026
root@g0:~# zoneadm list
global
oxz_switch
oxz_internal_dns_5b07f3e7-444c-462c-9633-6967e52d6a3b
...

スイッチゾーンへの接続（技術者ポート）

$ pfexec ./target/debug/voxel tp login switch0
[voxel] ssh root@192.168.68.167 -> zlogin oxz_switch  (g0 switch0)
[Connected to zone 'oxz_switch' pts/3]
Last login: Sun Sep  6 22:17:52 from fdb0:a840:2500:
The illumos Project     helios-3.0.23976        May 2026
root@oxz_switch:~# tp

管理コマンドの拡張性

  • イメージ管理（エクスポート/インポート、削除）。
  • 設定変更（ネットワークトポロジー、スレドサイズ、マルチラック構成など）。
  • 開発随伴により機能をさらに追加予定。

📥 ダウンロードと推奨環境

  • ライセンス: MPL 2.0 下の配布可能です。
  • OS 要件: Helios OS を実行する必要がある。
  • 推奨ハードウェア:
    • CPU: 16 コア以上。
    • メモリ：64GB RAM 以上。
    • ストレージ: オンボード DRAM 付き、プレミアム NVMe ドライブ。

Voxel を利用することで、本物のラックスケール機器に近い環境を低コストかつ高効率に構築・検証できます。

同じ日のほかのニュース

一覧に戻る →

2026/10/15 4:26

がん患者さんが知っておくべきこと：2026年版

## 日本語訳： 口がん（例：扁平上皮癌）と診断された人にとって最も重要な点は、疾病の深刻さが初期段階での対話（AI ツールを含む）で相対化されうる可能性があるため、適切なタイミングで高品質な医療を受けるよう執拗に努力し続けることです。個人的な経験から、術後採取した腫瘍組織で行われた検査よりも、生検組織を用いた検査を優先しないことが危険な遅れを引き起こす可能性があることが示されており、したがって患者は可能な限り総合的な遺伝子検査と上級がんセンターでの第二の意見を迅速に求めるべきです。メジャーな医療機関（例：MD Anderson）は、医師と病理科医間の強い協力関係によりより迅速かつ正確な回答を提供することが多く、US News ランキングを指針としてローカルコミュニティ病院よりも 2〜3 時間のドライブ圏内であっても訪問する価値があります。実用的な戦略には以下が含まれます： - ノートとフォローアップのための整理されたシステムを作成すること（例：予約要約や質問用の専用フォルダー）。 - NCCN ガイダンスの「標準治療」フローチャートを使用して、期待されるプロトコルを理解し、効果的にアドボケーシィを行うこと。 - 標準的な経路が停滞した際に特に Sijbrandij Foundation のようなリソースを求助すること。 外科医を選ぶ際には、年間手術件数や合併症発生率について問いかけ、同様の処置を受けた他の患者と話すことを検討すべきです。必要であれば有給休暇やホテルを使用してトップクラスのカンターにアクセスすることもできます；多くの施設は保険を受け入れています。結局のところ、これらの能動的なステップはキャンセルや保険手続きによる遅延を防ぎ、適切な標準治療を受けることを確実にします。

2026/10/15 5:48

OpenCode 2.0

## Japanese Translation: OpenCode 2.0 は、数百万人の毎日ユーザーからのフィードバックに基づいた大きなアーキテクチャ見直しであり、パフォーマンス向上、バグ修正、およびほぼあらゆるエージェント機能をサポートするように設計された全く新しい API を導入しています。主要な変更点として、すべてのインターフェース（TUI、Web、デスクトップ）を単一の中央バックグラウンドプロセス (`opencodepid`) に統合し、`@opencode/client` を使用するクライアントはこれを自動で発見できるようになりました。システムは現在、ペアリングフロー (`/pair` または `opencode pair`) を通じてスケジューリングされたタスクや外部アプリケーションとのシームレスな接続をサポートしており、ネイティブアプリの開発が進行中です。 目立つ機能の一つには、「Code Mode」(`@opencode/codemode`)があり、Node.js VM の複雑性なしにエージェントが直接スクリプトを書くことを可能にする最小限の JavaScript インタプリターを使用します。これにより、すべての MCP サーバーはデフォルトで code mode で動作します。この更新では、長時間実行されるタスクのためにバックグラウンドサブエージェントと非同期シェルコマンドを導入し、セッション中にプラグインのアップデートを行うためのホットリロードも追加されています。新しい `@opencode/sdk` を使用することで、OpenCode をサーバーまたは Durable Objects 上のライブラリとして利用できるようになります。 このアップグレードには重要なbreaking changesが含まれています：バージョン 1.x のプラグインはもはや機能せず、`tui.json` などの設定ファイルは `json` フォーマットに移動しました。最新の 1.x リリースを使用するユーザーは、2.0 に更新してこれらの変更との互換性を維持するには、最初に `opencode upgrade --major` を実行する必要があります。

2026/10/15 6:11

Jev 1.14.0 をリリースし、ドリーマー向けの試み機能を同時に提供します

## Japanese Translation: jev 1.14.0（`jev-preview` チャンネルで利用可能）は、「危険区域」API ヘッダーをゲート化した実験機能を提供します。これには、composable images（`TypeSafe-Danger-Zone-Images: true` を有効化により提供され、ただし以前の 1.13.0 ビルドに比べて多モーダル入力におけるパフォーマンス低下が報告されています）、エラーなしのバウディングボックスを返す新しい「box」検出タイプが含まれます。ユーザーはさらに、より長いコンテキスト長（`TypeSafe-Danger-Zone-Long-Context: true`）およびデバッグ用の Jaggedness レポートへの参加を選択でき、これらは特定のヘッダーを通じて利用可能です。このアップデートは 1.13.0 に基づいており、以前のパフォーマンス低下を解決すると同時に多言語サポートを拡張しています。評価については、内部インテリジェンス指標は非一貫的な推測として扱い、公式ベンチマークはデータポリシーの懸念から開示ウェイトモデルのみを対象としており、ランキングが特定のアーキテクチャにバイアスがかかっている可能性があるため、個人の実験に頼るべきです。今後、`jev-latest` 別名は 1 週間以内に 1.14.0 を採用します。企業は廃止スケジュールを監視する必要があります：バージョン 1.13.0 に対する 60 日間の警告期間に続いて、新しいリリース用の 30 日間のウィンドウを確保し、古いバージョンが廃棄される前にシステムがこれらの構造的変化に適応できるようにします。ドキュメントは docs.typesafe.ai/go/images、docs.typesafe.ai/go/box、および docs.typesafe.ai/models#context-length で利用可能です。

Virtual Oxide Labs：完全な Oxide ラックのシミュレーション | そっか～ニュース