2026/08/06 1:50

Celld: セルフホスト分散型耐久オブジェクト

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

要約▶

Japanese Translation:

Celld は、ユーザーがローカルに Cloudflare Workers および Durable Objects をセルフホストすることを可能にするオープンソースのデーモンであり、集約制御プレーンをピアツーピアアーキテクチャで置き換えます。各 Durable Object は、ユーザー所有の S3 互換バケット内に格納される独立した SQLite データベースとして機能し、ノードはこの共有ストレージを介してのみ協調を行うことで、複雑なコンセンサスサービスなしに動作します。すべてのノードは V8 エンジンを内蔵しており、Wrangler バンドルを効率的に実行します。アイドル状態のセルは自動的にハイバネーションし、リソース使用量を最小化します。インストールには検証済みのバイナリのダウンロード（

esbuild

が PATH に存在することを必要とする）を含み、リリース間の原子スイッチングは

~/.local/lib/celld/releases

で管理され、Linux x86-64 および ARM64 向けの Docker イメージは

ghcr.io/denoland/celld

で利用可能です。デプロイメントでは

celld deploy

を使用し、同じ S3 バケットをターゲットとし、非 AWS ストレージ用の構成可能なエンドポイントおよびリージョンをサポートします。セキュリティはデフォルトで堅牢であり、明示的に許可されていない限りパブリック IP は拒絶され、ピアリクエストはフラートシークレットを介して HMAC 認証および再プレイ保護が適用され、通信には暗号化されたオーバーレイ（例：WireGuard）またはプライベートネットワークが必要です。ユーザーは

celld diagnose

を使用してクラスターを監視でき、

CELLD_MAX_RESIDENT_CELLS

などの環境変数でロードシェーディングを構成し、

cargo

を使用してソースからビルドできます。Pull Requests は現時点では無効化されていますが、コントリビューションはマイネーターへ git フォーマットパッチアタッチメントとして提出可能です。このシステムは、組織に自社のハードウェア上でエッジロジックをホストすることを可能にし、コスト削減を実現しつつ、厳格なクロックバウンディング措置を通じて再プレイ攻撃およびタイミング問題に対する高いセキュリティとパフォーマンスを保証します。

本文

Celld: セルフホスト分散型 Durable Objects

Celld は、ユーザーご自身の環境上で動作し、Cloudflare Workers および Durable Objects を実行するためのオープンソース・デーモンです。このアーキテクチャにより、自己管理型の分散システムを構築することが可能になります。

主な特徴

セルフホスト化: Cloudflare Workers と Durable Objects をご自身のサーバーで動作させることができます。
独立したデータベース: 各オブジェクトは独立した SQLite データベースとして機能し、名称によってアドレス指定されます。
S3 互換ストレージ活用: データは S3 互換バケットにレプリケートされ、ここが**「真の単一情報源（Source of Truth）」**となります。
コンセンサス不要: ノード間の調整は S3 バケットのみを介して行われ、コントロールプレーンや複雑なコンセンサス機構は不要です。
設計段階での課題排除: アプリケーションが本質的にシャーディングされるため、共有データベースに伴う競合処理や大規模障害の影響範囲限定といった課題が事前に回避されます。
リソース効率: アイドル状態のセルは休眠され、ほぼゼロリソースでの動作を実現します。

仕組みについて

Celld の内部動作とデータ同期の詳細です。

実行環境: 各 Celld ノードには V8 が埋め込まれ、Wrangler のバンドルを実行します。
共有情報源: fleets（ノード群）は、デプロイ情報やセルの状態、および小規模な所有権レコードを含む S3 互換バケット を共有しています。
単一所有権保証: オブジェクトストレージの「読み書き同時更新（CAS）」を利用して、メンバーシッププロトコルやコンセンサスを使わずに、常に一つのノードだけがセルを所有し続けることが保証されます。
動的リカバリ: セルが移動または起動した際、新しい所有者は当該 SQLite データベースを復元して実行を再開します。
ノードの入れ替え: バケットこそが真の情報源であり、ノード自体は交換可能です。

インストール

Celld のバイナリをダウンロードし、

gh attestation verify

コマンドで出所（Provenance）を検証できます。

インストール手順

curl -fsSL https://celld.dev/install.sh | sh

PATH 設定: インストーラーからの指示に従い、
```
~/.local/bin
```
を
```
PATH
```
に追加してください。
必要なツール:
```
celld deploy
```
を使用する場合、PATH 上に
```
esbuild
```
が必須です（静的アセットみのプロジェクトでは不要）。
バージョン管理: インストーラーは検証済みのリリースを
```
~/.local/lib/celld/releases
```
に保持し、原子操作により現在のポインタを切り替えます。

アンインストール

curl -fsSL https://celld.dev/uninstall.sh | sh

コンテナ運用

Docker イメージを使用する際の設定方法です（Linux x86-64 および ARM64 対応）。

バージョン確認

docker run --rm ghcr.io/denoland/celld --version

永続化と AWS クレデンシャル設定

ローカル状態を永続化し、AWS クレデンシャル環境変数を渡して実行するコマンド例：

docker volume create celld-state
docker run --rm \
  --network host \
  -e AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY \
  -e AWS_SESSION_TOKEN \
  -e CELLD_WATCH=/var/lib/celld/state \
  -v celld-state:/var/lib/celld \
  ghcr.io/denoland/celld \
  --bucket s3://my-cells-bucket \
  --endpoint https://ACCOUNT.r2.cloudflarestorage.com \
  --region auto \
  --listen 0.0.0.0:8080 \
  --advertise node-a.internal:8080

注意点:

AWS S3 を使用する場合:
```
--endpoint
```
および
```
--region
```
オプションは省略してください。
ロードバランサー背後: ロードバランサーの背後で動作させる場合は、ピアが到達可能な個別の
```
--advertise
```
指定を行う必要があります。

実行方法

Celld は標準的な AWS クレデンシャルチェーンを利用します。

デプロイと起動

S3 互換バケットへのデプロイとセルの起動：

celld deploy . \
  --bucket s3://my-cells-bucket

セルを実行するコマンド例：

celld \
  --bucket s3://my-cells-bucket \
  --listen 0.0.0.0:8080 \
  --advertise 10.0.0.12:8080

オプション指定: 別の S3 互換サービスの場合は
```
--endpoint
```
、推測できない場合は
```
--region
```
を追加してください。
ノード群構造: 一つのアプリケーションを走査する「one fleet」が一つの単位となり、各ノードは
```
deploy/current.json
```
から最新の成功したデプロイロードを読み込みます。
ヘルプ表示: 詳細なオプションは
```
celld --help
```
をご参照ください。

デプロイオブジェクトとビルド

デプロイオブジェクトには
```
crates/celld/protocol.rs
```
に文書化された型を使用します。
```
celld deploy
```
は PATH 上の esbuild から Worker コードをビルドし、冷たいプライド済みの静的アセットや専用アセットを含む Wrangler コンフィグサブセットを受け付け、それらを直接書き込みます。
認証機構: アカウントサービスや加入サービスは存在しません。各ノードはバケットのリースから所有者とピアを発見します。

セキュリティ設定（重要）

TLS 終端: ピア間の HTTP 通信では TLS が終端されません。暗号化オーバーレイ（WireGuard、Tailscale など）上または信頼されたプライベートネットワーク上にすべての広告（advertise）アドレスを配置してください。
公開 IP の制限:明示的に
```
--unsafe-public-advertise
```
オプションがない場合、文字列の公開 IP アドレスは拒否されます。
セキュリティプロトコル: すべてのピアリクエストは、HMAC 認証済み、時計制約付き、および fleet シークレットを用いた再送保護が施されています。
アクセス権限: バケットへのアクセスやクレデンシャルは、fleet アドミニストレーター権限と同様に扱う必要があります。

Fleet の運用

ヘルスチェックとプレッシャー管理の設定例です。

診断コマンド

celld diagnose --bucket s3://my-cells-bucket

レポート機能で検出される項目:

期限切れのレコード
Malformed（変形）したアドレスまたは安全でない広告アドレス
到達不能なピア
非互換なプロトコル
ノードごとの現在セル数、WebSocket 接続数、RSS メモリ使用量、CPU 使用率、ファイル記述子数、プレッシャー状態

対象を制限する場合:

--peer NODE_ID

プレッシャー Shedding（負荷制御）

ロードされたノードのセル数のしきい値を設定します。安全なデフォルトはオプトインです。

CELLD_MAX_RESIDENT_CELLS=1000 \
CELLD_RESIDENT_LOW_WATER=800 \
celld --bucket s3://my-cells-bucket --listen 0.0.0.0:8080 \
  --advertise node-a.internal:8080

追加のトリガー（Linux）:

```
CELLD_MAX_RSS_MB
```
：メモリのトリガー
```
CELLD_MAX_CPU_PERCENT
```
：CPU のトリガー

動作:

プレッシャーがかかると、celld は耐久性のあるレプリケーションを行い、最も最近使用されていないアイドルセルをフェンスします。
これらのセルは「所有者なし」として公開されますが、エポックリセットは行いません。
低しきい値に達するまで、新しい所有者なしのセルを取得することを拒否します。
スペア（予備ノード）には割り当てられず、通常のトラフィックで解放されたセルを取得します。
アクティブな作業中やホスト WebSocket が活着しているセルは shedding の対象外となります。

ソースコードからビルド

cargo build --locked
cargo test --locked
cargo clippy --all-targets --locked -- -D warnings

ワークスペース: Celld ランタイムをビルドします。
プロトコル実装: オブジェクトストレージプロトコルは
```
crates/celld/protocol.rs
```
に実装されています。
テスト:
```
examples/
```
下にある小規模な Wrangler プロジェクトが、サポートされている Worker および Durable Objects のインターフェースを実行テストしています。

互換性テスト: ランタイムと互換性レイヤーは進化中です。スタンドアロンのエンジンスモークテストをカバーしており、各リリース前に Workers/Durable Objects リファレンス動作への適合性及び、故障注入下での分散プロトコルの決定論的シミュレーションが実行されます。

貢献について

現状: プルリクエストの受け付けは停止されています。

理由: コーディングエージェントによる大規模で文脈不足の変更は、メンテナンス者の時間を節約するよりもコストが高くなるためです。
期待される貢献: Thoughtful な貢献をお待ちしております。コードを理解し、パッチに焦点を保ち、レビューに要する時間への配慮をお願いします。
送信先: git フォーマットのパッチ添付ファイルを
```
ry@deno.com
```
宛てに送信してください。

コントリビューターライセンス契約（CLA）

メールによるパッチ送付により、以下の権利が証明・譲渡されます：

提出権およびパッチの全権利を Deno Land Inc. に譲渡する証明
権利が譲渡できない場合は、Deno Land Inc. に対して、使用・修正・結合・再ライセンス・再配布・公開のための以下の条件でのライセンス付与：
- 恒久的で不可取り消し
- 世界的かつロイヤリティフリー
- 転譲およびサブライセンシング可能
- （帰属表示の有無に関わらず）

ライセンス

Apache-2.0

注意: パブリックな Fleet を運用する前に、制限事項およびセキュリティページを必ずご確認ください。

同じ日のほかのニュース

一覧に戻る →

2026/08/06 3:52

Zed デルタ DB

## Japanese Translation: DeltaDB は、すべてのコード変更を生成した特定のエージェント会話を密接に連携させることで、進行中の作業を記録する次世代のバージョン管理システムです。従来のコミットおよびプッシュサイクルを必要とするシステムとは異なり、DeltaDB ではワークツリーをバーチャライズ化することで、開発履歴のどの時点においても、エージェントがタスクを実行している最中であっても自由なオンデマンドブランチングを実現します。本システムは各操作に安定したアイデンティティを付与し、コードの経時的な進化を高精度に追跡可能としています。最も重要なのは、すべての変更が元の会話に明示的に結び付けられており、ユーザーは任意のロジックを形作ったメッセージを瞬時に追跡したり、チャットログから影響を受けたファイルへナビゲートしたりできることです。これにより、アクティブなスレッド内でのリアルタイムコラボレーションをサポートし、摩擦を排除します。その結果、チームメンバーは進行中のエージェントタスクに参加して実行中のエージェントと対話し、変更が生じるにつれて注釈を追加し、新たなブランチを容易に作成することが可能になります。このアプローチは、すべての利害関係者にコード変更の背後にある根拠が見える化されることにより、AI 支援開発における透明性と説明責任を高めると同時に、レビューヤーや注釈付け者が堅牢なコミットサイクルを待ったりワークフローを中断したりすることなくライブプロジェクトにシームレスに統合できることを可能にします。

2026/08/06 1:19

発見のループ

## Japanese Translation: Discovery Loop は、最先端 AI と莫大な計算能力を活用して反復的な実験ループを完全に自動化し、科学的進歩の変革を目指しています。Jeff Dean、Sanjay Ghemawat、Quoc Le、Oriol Vinyals など、AI および分散システムの分野で最も引用されている研究者の一部を代表する先駆者們が率い、Google Search、TensorFlow、AlphaFold、Gemini などの重要インフラの背後で数十年にわたる協力を有しています。彼らのビジョンは、少量で精悍なチームが並行して数千もの実験を同時に提案し、実行し、そこから学習することを可能にし、従来の大規模チームよりもはるかに高い研究品質を達成しつつイテレーション時間を大幅に圧縮することです。当初は自身の技術スタックの最適化を行っていましたが、Discovery Loop は次に機械学習を超えて、より広範な科学と工学の領域へと展開する計画を立てています。この自動発見インフラをスケールさせることで、より良い医薬品の開発、ヘルスケア情報学の進歩、太陽エネルギーの価格低廉化、安全な水のアクセス確保、サイバー空間の保護、科学的発見のためのツールの設計といった重要な世界的課題に取り組んでいます。結局のところ、同社は機械学習および工学タスク向けの完全自動化システムを通じて、無数の分野でイノベーションを加速させ、人類が迅速な進歩を遂げられることを目的とした世界規模のソリューションを提供することを目指しています。

2026/08/06 4:50

AndroidからLinuxへのスマートフォン乗り換えを決意しました

## Japanese Translation: 2026 年 8 月 2 日、著者は Google の Android プラットフォームの方向性に日益の不満を抱き、主にプライバシー保護とジェスチャー操作に優れた Linux ベースのオペレーティングシステムである SailfishOS に主たる Android スマートフォンを切り替えることを決断した。具体的には、AI 機能の必須化、深いカスタマイズを妨げるロックされたデバイスツリー、ユーザーの自由を制限するアプリストアポリシーといった不満があった。Fairphone 4 (AOSP) から移行する過程において著者は SailfishOS で重大な障害に直面した。これらには、古くなったシステムライブラリ (Python および glibc)、Waydroid などのコンテナアプリとの互換性の破損、GPS サポートの問題、そして品質の低いコミュニティ製アプリケーション（コードが不適切な WhatsApp クライアントを含む）が含まれる。Ubuntu Touch も検討されたものの、アプリエコシステムの悪さ、Bitwarden に影響する通知/クリップボード同期の問題、平均的なネイティブアプリ、VIVO ユーザーによる電話番号のブロック機能の欠如という理由で却下された。その結果として著者は 2 台の端末を用いたハイブリッド構成を維持している：現在の Fairphone は重要な Android 固有サービス（ノルウェーおよびブラジルにおいて必要な銀行検証ソフトウェア、ブラジルにおける Uber などのセキュリティアプリ）へのアクセスのためにホットスポットとして機能する一方、新しい SailfishOS デバイスは代替 OS の実験に使われている。今後の計画には、この旅路を文書化し、ノルウェーへ戻った際により良いハードウェアサポートを受けられる Jolla Phone 2 を購入することを含み、プライバシーに注力する代替手段と不可欠なプロプライエタリアプリの世界的必要性との間にある持続的なギャップを浮き彫りにするものである。著者はこの構成に加えて Galaxy A17 をバックアップ用スマートフォンとしても使用している。