2025/12/25 7:43

フェニックス：Zigでゼロから書かれたモダンなXサーバー

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

要約▶

Japanese Translation:

## Summary
Phoenixは、完全にZigで書かれた全く新しいXサーバーです。Xorgのフォークではなく、現在は既存のX11またはWaylandコンポジタ内で「ネストモード」のみで動作し、DRM/Mesa GBMを介したフルハードウェアアクセラレーションによりGLX、EGL、Vulkanグラフィックスをレンダリングできます。プロジェクトの目標は、現代のアプリケーション（レガシーGTK2アプリも含む）に必要なX11プロトコルのサブセットだけを実装し、ほとんどのフォント操作を省略し、文字列をUTF‑8にデフォルト化することで、Xorgよりも単純にすることです。

セキュリティはコアコンセプトです。Phoenixは自動プロトコルパーシングを行い、ZigのReleaseSafe境界チェックを使用し、権限プロンプトでアプリケーションを分離し、従来のXorgの振る舞いに合わせてこれらのチェックを無効化することも可能です。Xorgへの改善点としては、モニタごとのDPI処理、異なるリフレッシュレート・VRR・HDRをサポートしたマルチモニタ機能、デフォルトでティアリングを排除するビルトインコンポジタ、および低いvsync/コンポジタ遅延が計画されています。

Phoenixは、新しい機能（HDRなど）に対応するためにX11プロトコルを拡張し、RandR経由でモニタごとのプロパティを公開します。Wayland互換性は、ネイティブまたは12to11のようなブリッジを通じて計画されており、将来的にWayland専用アプリが動作できるようになります。Wayland上で動かすことは、代替Xwaylandサーバーとして機能する可能性があります。

非目標：PhoenixはXorgを完全に置き換えること、複数画面（X11スクリーン）をサポートすること、GrabServerによる排他アクセスを提供すること、エンディアンが逆転したクライアントを扱うこと、または間接GLXを実装することを目指していません。リモートレンダリングの方が効率的と考えられます。

ビルド手順は簡単です：
```bash
zig build -Doptimize=ReleaseSafe
sudo zig build install -p /usr/local -Doptimize=ReleaseSafe

依存関係にはZig 0.14.1、x11/xcb、Wayland（client/egl）、libdrm、gbm、およびOpenGL用のlibglvndが含まれます。

結果として、レガシーGTK2アプリを実行しつつ、低遅延でより安全なディスプレイスタックが得られ、開発者はモダンLinuxグラフィックススタックへの統合を容易にしながらデスクトップエコシステム全体の保守負荷を削減できます。

本文

Phoenix – 現代的なXサーバ

Phoenixは、完全にZigで書かれた全く新しいXサーバです（Xorgのフォークではありません）。
軽量・安全・ハードウェアフレンドリーを目指し、現代アプリケーション向けの代替案として設計されています。

現状

本番環境での使用は未準備。
現時点では既存のXサーバ内にネストして動作させることで、ハードウェアアクセラレーション済みの簡易GLX/EGL/Vulkanグラフィックスを描画できます。
唯一サポートされているモード：
Phoenixは「ネスト型」でのみ実行可能です。単体で動作できるレベルになるまで、ネストされた状態で利用してください。

目標

カテゴリ	目的
シンプルさ	現代アプリが必要とするX11プロトコルのサブセット（過去約20年分）だけをサポート。GTK2レガシープログラムも含む。
セキュリティ	自動プロトコルパース；Zig の `ReleaseSafe` が境界エラーを検出。アプリは隔離され、他アプリへのアクセスや修飾なしグローバルホットキーには明示的な許可が必要。Xorg 互換性のために隔離機能を無効化するオプションも用意。
モダンハードウェア対応	複数モニタ（異なるリフレッシュレート、VRR、HDR）への完全サポートと、各モニタの DPI を正しく処理。
グラフィックハンドリング	破綻のない組み込みコンポジターを備え、外部コンポジターやフルスクリーンアプリが走っている場合は自動で無効化。Xorg より低い vsync/コンポジター遅延を実現。
新規標準	RandR プロパティとしての per‑monitor DPI；HDR などの機能拡張 X11プロトコル。
Wayland 互換性	ネイティブ Wayland サポート、またはブリッジ（例：12to11）。
ネスト型ディスプレイサーバ	ハードウェアアクセラレーション付きで X11 または Wayland 上で Phoenix を実行。デバッグや開発に便利。

非目標

Xorg サーバの完全置き換え。
レガシー X11 スクリーン（複数モニタのみ）のフルサポート。
排他アクセス (
```
GrabServer
```
) – Phoenix では無効化済み。
エンディアンスワップしたクライアント/サーバ処理（必要なら再検討）。
間接／リモート GLX – 複雑すぎるため、代わりにリモートレンダリングプロキシを検討。

X11 プロトコルとの違い

領域	Phoenix の振る舞い
コアプロトコル	必要最低限のフォント操作（例：カーソurfont）だけ実装。
文字列	すべての文字列はデフォルトで UTF‑8 とみなされる；ISO Latin‑1 はサポートしない。

インストール

# ビルド＆インストール（ReleaseSafe モード）
zig build -Doptimize=ReleaseSafe
sudo zig build install -p /usr/local -Doptimize=ReleaseSafe

アンインストール

Zig にはアンインストールコマンドがないため、手動で削除してください。

sudo rm /usr/local/bin/phoenix

開発ビルド

# デバッグモード（デフォルト）
zig build   # バイナリは ./zig-out/bin/phoenix に生成

# 直接実行
zig build run

プロトコルドキュメントの生成

zig build -Dgenerate-docs=true

.txt

ファイルが

./zig-out/protocol/

内に作成されます。

依存関係

ライブラリ	用途
Zig 0.14.1	コンパイラ
x11 (xcb)	X11 上でネストモードを動かす際のバックエンド ( `-Dbackends=x11` )
wayland (client, egl)	Wayland 上でネストモードを動かす際のバックエンド ( `-Dbackends=wayland` 、未実装)
drm (libdrm, gbm)	独立型 X11 サーバ用バックエンド ( `-Dbackends=drm` 、未実装)
OpenGL (libglvnd)	GL & EGL のサポート

FAQ

Q: なぜ Wayland コンポジターを作らずに新しい X サーバを書くのか？
A: 一般的な認識と逆に、最小限で機能する X サーバの実装はフル Wayland スタックよりもシンプルなケースが多いです。X プロトコルは明確に定義されており、多くのレガシーアプリケーションが既に依存しています。

同じ日のほかのニュース

一覧に戻る →

2025/12/26 8:13

おそらく、デフォルト設定が高すぎる可能性があります。

## Japanese Translation: **（すべての重要ポイントを統合し、明確さを保つ）** --- ### 要約著者は『ロード・オブ・ザ・リング』を声に出して読むことに二か月を費やし、第1部の終わりまで達しました。文ごとに「通常の時間の3倍」を意図的に遅く読むことで、口速で読むアプローチが急ぎを防ぎ、興味を高め、理解・没入・楽しみを深めることに気づきました。トールキンのイメージとムードは、ゆっくり読んだときにのみ心に完全に広がります。彼はこの洞察を読み以外にも拡張します。食事を通常の速度の1/3または半分に遅らせると、食べ物への感謝が増し、掃除機をかけたり、メールをチェックしたり、リストを書いたりする際も急いで行うより満足度が高くなります。現代生活の無限の消費物は、高速摂取を促進し、本や食べ物、情報の完全な鑑賞を損ないます。「少ないほど良い」という格言は、過剰に早く消費するとその影響力を失います。著者は、遅らせることで味覚と好みが変わり、濃密な文学作品や自家製料理が加工品より豊かになることもあると指摘します。今日の文化的規範はTikTokクリップ、加工食品、CGI映画などの高速で光沢のある消費を優先し、深い関与を犠牲にしています。彼は読者に対して、通常速度の約1/3程度と極端に遅く消費する実験を行い、報酬が増える体験を促します。Raptitude読者向けに「アルコール・ソーシャルメディア・スナックなどを一か月間やめる」討論フォーラムを開設し、多くの人が1月に同様のイニシアチブへの関心を示しています。

2025/12/26 10:02

**MiniMax M2.1:** *実世界の複雑タスクに対応するために設計された―多言語プログラミング*

## Japanese Translation: ```markdown ## Summary MiniMaxは新しいM2.1 AI‑nativeモデルをリリースし、Rust、Java、Go、C++、Kotlin、Objective‑C、TypeScript、JavaScriptなど複数言語にわたる実世界のプログラミングとオフィス作業で明確なパフォーマンス向上を提供します。主な強みは以下の通りです： - **多言語マスタリー**：Claude Sonnet 4.5およびGemini 3 Proを上回るベンチマークスコアを持ち、マルチランゲージコーディングタスクで最高レベル。全体的にはClaude Opus 4.5に近い性能。 - **WebDev & AppDevの進化**：ネイティブAndroid/iOS開発サポート、デザイン理解と美的表現の向上、3D科学シミュレーション、高品質ビジュアライゼーションによる持続可能なワークフロー。 - **インタリーブド・シンキング**：複合指示処理が改善され、オフィス環境での使い勝手を向上。 - **トークン効率的返信**：トークン消費を削減し応答時間を短縮、コーディングワークフローの効率化。 M2.1はまたVIBEベンチマーク（Web, Simulation, Android, iOS, Backend）も導入し、平均スコア88.6でClaude Opus 4.5にほぼ匹敵し、多くのサブセットでSonnet 4.5を上回ります。 Factory、Fireworks、Cline、Kilo、RooCodeなど国際AIプラットフォームからは速度、信頼性、多言語安定性、コスト効率が高いと評価されています。モデルは2つのAPIバージョンで利用可能です：**M2.1**（フル機能）および **M2.1‑lightning**（同じ結果を持ちつつ高速推論）。どちらも自動キャッシュをサポートし、開発者体験をスムーズにします。オープンソースウェイトはHugging Faceにホストされており、MiniMaxはさらにオープンソースの提供拡大とエージェントフレームワークやコンテキスト管理ツールへのサポート拡充を計画しています。開発者と企業向けにM2.1はより効率的なコーディング支援、トークンコストの削減、および強化された多言語機能を提供し、ソフトウェア納品タイムラインの加速やAI開発エコシステムにおける運用費用の低減を可能にします。 ```

2025/12/25 22:02

Windows x86‑64 用の Python 3.15 インタプリタは、ほぼ 15 ％速くなる見込みです。

## Japanese Translation: ## Summary Ken Jinは、macOS AArch64（XCode Clang）およびWindows x86‑64（MSVC）のCPythonのターミナル呼び出しインタープリターに関する以前の実績主張を部分的に撤回したものの、測定可能な速度向上を報告しています。macOSでは約5 %、Windowsでは実験的な内部MSVCビルドで最大15–16 %の改善が確認されています。ベンチマークは、「tail‑call threaded」インタープリターが従来のcomputed‑gotoループよりも優れていることを示しています。現代のコンパイラではその差は縮小しますが、実験的なVS 2026ビルドでは幾何平均で約16 %の利得が確認されています。この改善は、短いインタープリター・ループによりコンパイラがヘルパー関数（例：`PyStackRef_CLOSE_SPECIALIZED`）をインライン化し、レジスタ圧力を減らすことから生じています。ターミナル呼び出しは、Josh HabermanのProtobufブログとHaoran XuによるClangの `__attribute__((musttail))` を使用したコピー＆パッチ手法で広まりました。XCode Clangが修正されたCPython 3.14/3.15ではmacOS上で約5 %の速度向上が示され、Python 3.15「What's New」には長いスクリプトに対して最大40 %の速度向上が記載されています。MSVCチーム（Chris Eibl、Brandt Bucher）がリリースしたVisual Studio 2026はターミナル呼び出しをサポートし、具体的な利得をもたらします：spectralnorm_tc 1.48倍速、nbody_tc 1.35倍速、bm_django_template_tc 1.18倍速、xdsl_tc 1.14倍速。速度向上はPython 3.15まで継続すると予想されます。機能がロールバックされない限り、macOSのバイナリにはターミナル呼び出しが有効化された状態で配布され、VS 2026を使用したWindowsビルドでも同様の利得が期待できます。CPythonコミュニティはさらにビルドフラグ（`--tail-call-interp`）を洗練させ、プロファイルガイド付き最適化（PGO）を統合して性能を向上させる可能性があります。 CPUバウンドのPythonワークロード（科学計算、ウェブフレームワークなど）を実行するユーザーは、わずかな速度改善に気付くかもしれません。Pythonバイナリを配布する企業はコード変更なしで高速な実行ファイルを提供でき、Visual Studioを使用するWindowsの開発者もランタイム効率の向上から恩恵を受けるでしょう。