← 2026-05-27 の一覧へ戻るホーム
予兆的な再会

2026/05/26 14:57

予兆的な再会

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

元のHacker News記事へ ↗
要約▶

Japanese Translation:

学術的な集会で、著者は同世代の多くが大型言語モデル（LLM）による知識労働の人間的側面の喪失に対して広く不安を抱いているのに対し、以前の高齢世代が直面した恐怖とは対照的だと指摘した。この感情は、ウェスリアン大学の工学プロジェクトのために構築され、後にブラウン大学 CS の卒業生アダム・レビエンタールによってメンテナンスされた 1992 年のネットワーク接続型テトリス「BattleTris」の復活という具体的な成功と鮮明な対比を形成していた。長年にわたり、グリッド構成を変更する特定の武器を含むこのレガシーコードベースは、元の 32 ビット Solaris ビルドに影響を与えたことのない現代システム上でクラッシュに見舞われていた。最近、「スパイ」兵器によって開始された試合では、バッファ過負荷によりスタックのスマッushing の検出エラーが発生した：

sendBoard
関数は 4 バイト（
sizeof(int)
）しか割り当てていないが、8 バイト（
sizeof(unsigned long)
）を書き込み、結果として現代の 64 ビット Linux システム上で 1114 バイトの過負荷を引き起こしていた。

多くの専門家の圈で現在恐れている LLM クロードを使用することで、チームは割り当てと書き込み操作間のこの特定の不一致を特定した。これらの AI の洞察に基づいたターゲットされた修正を適用することで、彼らはゲームを成功裏に移植し再構築し、20 年間クラッシュせずにもう一度元の著者たちにプレイさせることができた。この成功は、LLM が歴史的なデジタルアーティファクトの保存において脅威ではなく有益なパートナーであることを示す強力な証拠であり、現在の不安を引き起こすその技術自体が、複雑なレガシーシステムのデバッグを効果的に支援し、古いプロジェクトの継続的な関連性を確保することを可能にすることを明らかにしている。

本文

AI と人類の未来：卒業 30 周年と「バトルトライス」への旅路

1. 卒業 30 周年記念式典から読み取った未来への懸念

最近開催された自身の卒業 30 周年記念式典で、同世代（60 代半ば〜70 歳前半）の間には明確な傾向が浮き彫りになりました。

  • AI への根深い不安: 最も顕著だったのは、人工知能（AI）が私たちが生きる未来や、子孫たちの未来にもたらす影響に対する強い懸念です。
  • 2026 年の特別さ: 多くの世代は大学時代から現在までの 30 年間を振り返りながら「懐かしさと将来への不安」を併せ抱いてきました（例：1968 年卒業で徴兵猶予が失われ、戦争に従軍する可能性があった母親の話など）。
  • 現在の不安の強度: 2026 年という年は特別なのか判断しにくいですが、今日における未来に対する不安感は以前とは比較にならないほど極めて強いのが事実です。
  • 同期（'96 グループ）との対話: 大規模言語モデル（LLM）が知識を伴う業務に与える影響や、それに伴う将来への不安を中心に議論が巡り続けました。

2. 懐古熱狂と「BattleTris」の再生

一方、特定の層には過去に対する特異な懐古情熱も見られました。その中心にありましたのが、私が開発したゲーム「BattleTris（バトルトライス）」です。

  • 発想の起源（1992 年）:
    • 友人らとランダル・クック氏の『Wesleyan Tetris（悪人テトリス）』を気に入り、「対戦型テトリス」を作りたいと考えました。
    • コンピュータが生活を手助けするのではなく、ネットワーク上の相手が困難な状況を作り出すゲームとして構想しました。
  • 開発過程:
    • 1993 年夏：Null-modem ケーブルで PC2 台を接続し、「BattleTris」の初期版を作成。地下室での開発中に U2 の『Zooropa』を楽しみました。
    • 1994 年初頭：ソフトウェア工学のグループ最終プロジェクトとして本格化。大規模デモでは数十人の参加者が熱狂的に遊んでおり、しかしバグ多発でした。
    • 翌年の誕生日にはルームメイトと「負けるように設計されたゲーム」を楽しみましたが、卒業後は開発を一時休止しました。
  • Sun での復活と進化:
    • 卒業後 Sun に就職。ゲームは機能的に保存され、後輩学生らによって人気を得ました。
    • 2001 年：Adam（現在の Adam Ahrens）により大会を開催し、Sun 内で活動を開始。Solaris x86 や現代的な X/Windows でも動作するように移植されました。
  • 開発者との恋愛編:
    • 私のパートナーはゲームに熱心になり、Matt Ahrens 氏らと激しい対戦を繰り広げました。
    • 2001 年秋の終わりに相手が「ゲームクラッシュ」を引き起こし勝利しましたが、開発者がショックで沈黙しました（実際には相手勝てた）。
    • その出来事が契機となり、2002 年にプロポーズを成功させ、現在に至る長い結婚生活と三人の子供という奇跡的な結びつきが生まれました。

3. 現代の再生と AI によるバグ修正

近年、開発者たちの高齢化や新しい OS（Linux, Mac）への対応などにより、「BattleTris」を動かすのは困難な課題となりました。しかし、AI の活用で決定的な転換点が生じました。

  • 困難な状況:
    • 10 年近く前に作られたゲームのバグ除去、Linux/Mac への移植などが必要でした。
    • 移植作業は退屈かつ不確実であり、進捗が見えにくい課題です（目標が近づいても遠ざかることもある）。
  • Claude の活躍:
    • Adam がタスクに解放した後、Claude に Linux への移植を任せました。
    • 驚くほど短期間でスプラッシュスクリーンを動作させることに成功しました。
    • 私の 
      .Xresources
      ファイルの設定検出など、細かなデバッグも支援してくれました。
  • 感動的な対戦:
    • 20 年来初の BattleTris 対決に挑むことができました。
    • 数分間の戦闘は熱狂的でしたが、最終的にクラッシュしました（*** stack smashing detected ***）。
  • バグの発見と解決:
    • コードを Claude に解析させると、以下の根本的な不整合が見つかりました： 
      • sendBoard
        関数が 
        sizeof(int)
        (4 バイト) を基準にスタックバッファを割り当てていましたが、書き込み時に 
        BTNET_PUTLONG
        (64 ビット Linux では 8 バイト) を使用していました。
      • これによりスタックオーバーフローが発生し、クラッシュしていたのです（32 ビットの Solaris 時代にはこの問題は起きません）。
    • 修正: クラッシュを引き起こす特定の武器（スパイ用武器）も同時にバグの原因として特定され、修正が適用されました。
    • 結果として、ゲームは正常に完了し、Adam が勝利しました。

4. レクイエム：テクノロジーと人間性の対比

深夜までゲームを続け、写真撮影やアルコールを交えての楽しい一夜でした。これは「完璧な卒業式」と呼べる瞬間となりました。

  • Claude の実力:
    • 我々の多大なる手助けなしにこの移植は成し得なかったでしょう（先行する 2020 年代における AI 依存の高さが示されています）。
    • しかし、作業自体は退屈かつ時間がかかるため、人間が行いませんでした。
  • 教訓:
    • LLM は単なる強力なツールです。手続きの支配者ではなく、使い手によって制御される存在でありましょう。
    • 技術的変化により去りゆくものもあるでしょうが、多くの「BattleTris」のような経験が我々の集団的な未来にも訪れるはずです。
  • 結論:
    • 私たちは心配して未来を AI に委ねる必要はありません。自分たちにとって何事かを造る理由を思い出させてくれる delightsfully 人間による瞬間こそが重要なのです。

BattleTris のコードについては、すでに公開していますので、是非試してみましょう！

同じ日のほかのニュース

一覧に戻る →

2026/05/26 5:41

いくつかの興味深い現代風ピクセルフォント

## Japanese Translation: Vercel による Geist Pixel は、新しさ重視のベクトルフォントから、プロフェッショナルな生産環境に適合した堅牢で機能的なタイポグラフィシステムへの転換を象徴する。アンドリュー・グリーソン氏の Analog Mono（低基準線問題を解決）、ジョセフ・ファチュラ氏の Two Slice（読みやすい 2 ピクセル高のベクトルフォント）、および古谷由美氏の Coral Pixels（ノスタルジックなサブピクセルレンダリングによるフレアを包含）など、過去のデザインは特定の美的特徴や歴史的真似に焦点を合わせていたのに対し、Geist Pixel は重要な生産上の課題に取り組む。ビューポート間での一貫したスケーリングを保証し、対立するタイポグラフィ指標を解決するとともに、文字形式以外の領域（キアニング、メタデータ、追加のグリフ、垂直指標など）において「目に見えない本業」として多大な努力を投入している。ユーザー体験を劣化させる可能性のあるリスクの高い新奇品ではなく、Geist Pixel は広範なタイポグラフィエコシステムにおける信頼性の高いシステムツールおよび拡張機能として振る舞う。この進化は、現代的インターフェースに必要な本質的なタイポグラフィ的堅牢性を保ちながら、画面上で本物らしいテクスチャを維持することを可能にする新たな業界標準を確立する。 ## Text to translate: Improved summary: Geist Pixel by Vercel marks a shift from novelty vector fonts to a rigorous, functional typography system built for professional production. Unlike earlier designs—such as Andrew Gleeson’s Analog Mono (fixing low baseline issues), Joseph Fatula’s Two Slice (a 2‑pixel tall readable vector font), and Kumiko Yoshida’s Coral Pixels (incorporating nostalgic subpixel rendering fringing)—which focus on specific aesthetic quirks or historical replication, Geist Pixel addresses critical production challenges. It ensures consistent scaling across viewports, resolves conflicting typographic metrics, and includes significant “invisible hard work” beyond letterforms in areas like kerning, metadata, extra glyphs, and vertical metrics. Rather than being a risky novelty that can degrade user experience, Geist Pixel acts as a reliable system tool and extension within a broader typographic ecosystem. This evolution establishes a new industry standard where pixel fonts maintain authentic visual texture while preserving the essential typographic rigor required for modern interfaces.

2026/05/23 2:17

Adobe と Microsoft を飛び越えてGitで管理する書籍製作パイプラインを作成しました

## 日本語訳: 著者は、新規の形式付けをソフトウェア工学上のタスクとして扱い、Adobe InDesign などの高価なライセンスに依存する脆弱な専用ファイルから、オープンでプレーンテキスト形式のアートファクトへの移行を行うことで、自己出版の自動化を目指している。以前は Microsoft Word と Adobe InDesign を用いて印刷物を制作しており、Calibre を使って Kindle 版への変換を試みても品質が不足していた上、LibreOffice のアップデートにもかかわらず高品質なタイポグラフィを達成できていなかった。今回の移行では LaTeX と自作の Python スクリプトを採用し、電子書籍版および印刷版双方で高品質なテキストを提供すると同時に、Adobe InDesign などの高額ライセンスへの依存度を低減させている。 最も重要な点として、Standard Ebooks のガイドラインを採用することで、厳格なスタイルマニュアルとコマンドラインツールが不可欠な「リンター」として機能し、コードの品質を自動的に検証してデジタル上のエラーを未然に防ぐ。最終出版である『サルデーニャ公（Prince of Savoy）』により、Git を用いたバージョン管理に基づく開発へのピボットが完了した。今後、プロジェクトでは汎用的なスクリプトを活用し、Open Document XML をそのままクリーンな XHTML と LaTeX にマッピングする手法を採用する。この方法は、著者にとって持続可能で再現可能なアプローチを提供し、脆弱なバイナリ形式を意味論的データ構造に置き換えることで、高価なソフトウェアへの依存関係を持たずに長期的な互換性を促進する。

2026/05/25 14:05

C 配列の型は奇妙です

## Japanese Translation: C 言語の中核となる区別は、配列が関数呼び出し中にポインタに退化するメカニズムにあります。通常、これは重要なサイズ情報を失うことを意味しますが、`sizeof` 演算子や `&` オペレーターと組み合わせて使用される場合を除きます。関数の引数において、あらゆる配列型は自動的にポインタとして解釈され、サイズ指定子は破棄され、その結果 `sizeof(arr)` は `sizeof(T)` を返します。標準的な慣行では、配列名はその最初の要素へのポインタ（`&arr[0]`）と扱われますが、`sizeof` および `&` のようなオペレーターは元の配列の身元を保持します。特定の実行長が強制されているより短い配列を渡す場合（例：`char buf[static 8]`）、サイズ指定子は呼び出し時にコンパイラの最適化にのみ有用であるため、未定義の動作を引き起こします。これらのリスクを軽減するために、開発者は単なるポインタではなく「配列へのポインタ型（`T (*)[n]`）」を使用して、関数呼び出し中に長さ情報を保持するようにする事ができます。関数は配列と同様にポインタに退化しますが、関数名を解除参照する（`*fn`）ことで、関数シンボルを直接使用せずに直接呼出しを行うことができます。配列は `&arr[0]` によって退化するのに対し、関数は自動的に宣言位置へのアドレスに変換されます（`&fn` は `fn` と同等です）。両者とも、`&` オペレーターへの引数として渡された場合、退化しません。高度な解決策としては、「ワイドポインタ」を使用する事があり、これは構造体のように動作し、全サイズなどの追加データを格納することで、コンパイラが関数の境界を越えて長さを追跡できるようにします。これは C++ の `std::vector` に準じるものであり、サイズ指定のない型整合性を維持します。GDB などのツールは、アドレス表現に `@` オペレーターを使用し、メモリアドレスに長さを付与することで、場所表現を配列に変換します（例：`*ptr@2`）。配列を単純なポインタの退化ではなく、値ベースの構造体として捉えるというコンセプトを採用する事により、複雑なシステムにおけるコードの安全性とメンタルモデルを著しく向上させる事が可能です。