← 2025-12-30 の一覧へ戻るホーム
**GOGが元創業者によって買収される** - PCゲームのデジタル配信プラットフォーム「GOG」は、元共同創業者によって買収されることを発表しました。 - この取引は会社のルーツに立ち返るものであり、DRM‑free（著作権管理が不要）ゲームへの注力を強化する見込みです。

2025/12/30 1:43

**GOGが元創業者によって買収される** - PCゲームのデジタル配信プラットフォーム「GOG」は、元共同創業者によって買収されることを発表しました。 - この取引は会社のルーツに立ち返るものであり、DRM‑free（著作権管理が不要）ゲームへの注力を強化する見込みです。

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

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Michał Kiciński – CD PROJEKT の共同創設者であり GOG のオリジナル共同創設者でもある彼は、GOG を CD PROJEKT から購入し、同社が「ゲームを永遠に生かす」ミッションに専念する独立企業として残ることを保証しました。
新しい所有権の下で DRM フリーアクセスは中心的な位置を保ちます：ライブラリはあなた自身のもののままで、オフラインインストーラも利用可能であり、データの所有権も GOG に留まります。ユーザーアカウント、任意の GOG GALAXY 機能、および寄付（これらは引き続き GOG 内の保存作業を資金提供します）は変更されません。
GOG と CD PROJEKT の関係は維持されます：現在および今後の CD PROJEKT RED タイトルはすべて GOG でホストされ続けます。CD PROJEKT は高品質な RPG の開発に専念でき、GOG はクラシックを保存し、優れたゲームを称え、将来のレトロスタイルタイトルを形作り続けます。
2026 年の計画されたイニシアチブには、より野心的な救出ミッションとコミュニティエンパワーメントプログラムが含まれますが、新しい所有権の下でデータ共有やアカウント管理ポリシーに変更は期待されません。

本文

GOGチームからのお知らせ

本日、CD PROJEKT と GOG の共同創業者であるマイカル・キシンスキー（Michał Kiciński）が、CD PROJEKT から GOG を取得しました。

なぜ GOG とマイカル・キシンスキーが結びつくのか

  • 私たちは、私たちを形作ったゲームは生き続ける価値があると考えています。
    見つけやすく、購入しやすく、ダウンロードして永遠にプレイできるようにしたいのです。
  • 時間が経つにつれて、複雑な権利関係・互換性の欠如・ビルドの消失・ノスタルジックな夜がトラブルシューティングへと変わってしまいます。
  • それは「今日プレイしている」(ゲームが生きている) と 「いつかプレイするだろう」(ゲームが死んでしまう) の違いです。

“GOG は自由、独立、そして真のコントロールを意味します。” – マイカル

  • GOG は常に強固な価値観と明確な原則に基づいて構築されてきました。
  • 2007 年、マルチン・イヴィンスキー（Marcin Iwiński）とマイカル・キシンスキーは、クラシックゲームを再びプレイヤーの手元へ届けること、そして一度購入したゲームが真に永遠に自分のものになるよう保証することを目指しました。
  • この哲学は、強制クライアントや閉鎖型エコシステムが支配する現在の市場で、今まで以上に重要です。

新たな章

  • クラシック作品の保存にさらに注力し、今日の傑作を称えつつ、明日のクラシック—実際のレトロ精神を持つ新作ゲームも含めて—を形づくります。

あなたへの影響

  1. DRM‑free が中心 – ライブラリはあなた自身のもの。アクセス方法やオフラインインストーラ、所有感は変わりません。
  2. データは GOG に残る – マイカルや他者とデータを共有することはありません。
  3. GOG Galaxy は任意。
  4. CD PROJEKT との関係継続 – CD PROJEKT RED のゲームは GOG 上で利用可能で、今後のタイトルも同様にローンチされます。
  5. Patron サポートは GOG 内で管理 – Patreon や保存プログラムからの資金は 2026–27 年の救済ミッションに使用されます（詳細は追って発表）。
  6. 独立性を維持 – GOG は倫理的で非掠奪的、長期にわたるプラットフォーム構築を継続し、インディ開発者も支援します。
  7. コミュニティの声を強化 – 2026 年に向けて新しいイニシアチブが計画されています。

FAQ

質問回答
何が起きているのか？マイカル・キシンスキーが GOG を取得しました。会社は独立したままで、ミッション Make Games Live Forever は変わりません。
GOG の立場は？この買収により、GOG が持つユニークな価値—長期的なサポートと自由・独立・コントロール・長寿命へのコミットメント—が加速します。
マイカルは何故これを行うのか？強制クライアントや閉鎖型エコシステムが進む市場で、GOG のオリジナル哲学を守り発展させるためです。
CD PROJEKT はなぜ売却するのか？CD PROJEKT は最高品質の RPG 開発に専念できるようにしつつ、GOG に強力な支援を提供します。
ミッションは変わるのか？いいえ—Make Games Live Forever はそのままです。
DRM‑free は依然中心なのか？はい、以前よりも重要性が増しています。
アカウントに影響はあるのか？何も変わりません。GOG アカウントとして継続します。
GOG は財務的に不安定か？いいえ、安定しておりミッションへの関心が高まっています。
チップや Patron の寄付はマイカルと共有されるのか？いいえ—GOG 内で保存作業に使用します。
ライブラリはどうなるのか？変わりません。ゲームが delisted されたとしても、ライブラリはあなたのものです。
オフラインインストーラはダウンロードできるのか？はい。
データはマイカルや他者に共有されるのか？いいえ—GOG がデータを管理します。
CD PROJEKT RED のゲームは GOG に残るのか？はい、現在および今後のタイトルも利用可能です。

ご支援いただきありがとうございます。この重要な変化を実感してくださっている皆様に心から感謝いたします。
新しいアップデートがリリースされ次第、お知らせいたします。その間、詳細な回答は FAQ をぜひご覧ください。

同じ日のほかのニュース

一覧に戻る →

2025/12/30 6:46

USPS（米国郵便公社）が切手印日付システムの変更を発表しました。

## Japanese Translation: > **概要：** > USPSは最終規則（FR Doc. 2025‑20740）を発行し、国内郵便マニュアルに「セクション 608.11 —『切手印と郵便保有』」を追加しました。この規則では、切手印の定義が正式に示され、該当する印記がリストアップされています。切手印は印付け日でUSPSがその物件を保有していることを確認しますが、必ずしもアイテムの最初の受理日と同一ではありません。USPSは通常業務で全ての郵便に切手印を貼らないため、切手印が欠落していても、その物件が未処理だったとは限りません。機械による自動切手印は、施設内で最初に行われた自動処理操作の日付（「date of the first automated processing operation」）を表示し、投函日ではなく、地域輸送最適化（RTO）や路線ベースのサービス基準により受理日より遅くなることがあります。切手印は小売ユニットからの輸送後やカレンダー日がまたがる場合に付けられることが多いため、郵送日を示す信頼できる指標ではありません。同一日の切手印を確保するには、小売窓口で手動（ローカル）切手印を依頼できます。小売窓口で料金を支払うと「Postage Validation Imprint（PVI）」が付与され、受理日が記録されます。また、郵便証明書、登録メール、または認定メールは提示日を裏付ける領収書として機能します。この規則の影響は税務申告において重要です。IRC §7502 は、文書が期限までに物理的に届けられなかった場合に、提出の適時性を判断する際に切手印の日付を使用しています。

2025/12/30 1:07

**Zig における静的割り当て** Zig のコンパイル時メモリ管理を使えば、実行時ではなくコンパイル時にストレージを確保できます。データ構造のサイズが事前に分かっている場合やヒープ割り当てを避けたいときに便利です。 ### 重要概念 - **コンパイル時定数** `const` や `comptime` の値を使い、コンパイラがコンパイル中に評価できるサイズを記述します。 - **固定長配列** リテラルサイズで配列を宣言します。 ```zig const buf = [_]u8{0} ** 128; // 128 バイト、すべてゼロ初期化 ``` - **静的フィールドを持つ構造体** 固定長配列やその他コンパイル時に決まる型を含む構造体を定義します。 ### 例 ```zig const std = @import("std"); // 静的サイズのバッファを持つ構造体 pub const Message = struct { id: u32, payload: [256]u8, // 256 バイト、コンパイル時に確保 }; // 静的割り当てを使う関数 fn process(msg: *Message) void { // ヒープ割り当ては不要；msg はスタック上またはグローバルに存在 std.debug.print("ID: {d}\n", .{msg.id}); } pub fn main() !void { var msg = Message{ .id = 42, .payload = [_]u8{0} ** 256, // すべてのバイトをゼロで初期化 }; process(&msg); } ``` ### 利点 - **決定的なメモリ使用量** – サイズはコンパイル時に分かる - **実行時割り当てオーバーヘッドがゼロ** – ヒープアロケータ呼び出しなし - **安全性** – コンパイラが境界と寿命を検証できる ### 使うべき場面 - 固定長バッファ（例：ネットワークパケット、ファイルヘッダー） - 短時間しか存続しない小規模補助データ構造 - 性能や決定的な動作が重要な状況 --- コンパイル時定数・固定配列・構造体定義を活用することで、Zig は最小限のボイラープレートで最大の安全性を保ちつつメモリを静的に割り当てることができます。

## Japanese Translation: > **概要：** > このプロジェクトは、Zigで書かれた軽量Redis互換のキー/バリューサーバー「kv」を構築し、最小限のコマンドセットで本番環境に適した設計を目指しています。コアデザインでは起動時にすべてのメモリを確保することで、実行中にダイナミックヒープを使用せず、レイテンシスパイクやユース・アフター・フリー（use‑after‑free）バグを回避します。接続は`io_uring`で非同期に処理され、システムは3つのプール（Connection、受信バッファプール、送信バッファプール）を事前確保し、デフォルトでは約1000件までの同時接続数をサポートします。各接続は設定パラメータから派生した固定サイズの受信/送信バッファを使用します。 > コマンド解析はRedisのRESPプロトコルのサブセットに従い、Zigの`std.heap.FixedBufferAllocator`を用いてゼロコピーで解析し、各リクエスト後にアロケータをリセットします。バッファサイズは`list_length_max`と`val_size_max`に依存します。 > ストレージは未管理型の`StringHashMapUnmanaged(Value)`を使用し、初期化時に`ensureTotalCapacity`で容量を確保します。キーと値は共有`ByteArrayPool`に格納され、マップはポインタのみを保持します。削除操作では墓石（tombstone）が残り、墓石数が増えると再ハッシュが必要になる場合があります。 > 設定構造体(`Config`)は `connections_max`、`key_count`、`key_size_max`、`val_size_max`、`list_length_max` などのフィールドを公開し、派生アロケーションで接続ごとのバッファサイズを決定します。デフォルト設定（総計約748 MB、2048エントリ）では `val_size_max` または `list_length_max` を倍増すると、割り当て量が約2.8 GBに上昇する可能性があります。 > 今後の作業としては、カスタム静的コンテキストマップ実装の改善、より良いメモリ利用を実現する代替アロケータの探索、境界検査（fuzz）テストの追加による限界確認、および墓石再ハッシュ処理への対応が挙げられます。

2025/12/27 20:30

**フレームグラフ 対 ツリーマップ 対 サンバースト（2017）**

## Japanese Translation: **概要：** Flame グラフ（SVG）はディスク使用量を高レベルで明確に示します。たとえば、Linux 4.9‑rc5 では `drivers` ディレクトリが全容量の50％以上を占め、`drivers/net` サブディレクトリは約15％です。Tree マップ（macOS の GrandPerspective、Linux の Baobab）は非常に大きなファイルを素早く検出できますが、高レベルのラベルが欠けています；Baobab のツリー表示では各ディレクトリの横にミニバーグラフが表示されます。Sunburst（Baobab の極座標図）は視覚的に印象的ですが、角度で大きさを判断するため長さや面積よりも誤解しやすいです。他のツール―`ncdu` の ASCII バーと `du -hs * | sort -hr` ―はテキストベースで迅速なサマリーを提供しますが、同時に一階層のみ表示されます。 提案されたユーティリティは、これら三つの可視化（Flame グラフ（デフォルト）、Tree マップ、Sunburst）すべてを組み合わせるものです。Flame グラフは読みやすさ・印刷性・最小スペース使用量が優れているため、多数のサンプルファイルシステムでテストした後にデフォルトとして採用されます。このアプローチは、ディスク使用量を簡潔かつ印刷可能なスナップショットとして提供し、ユーザーや開発者がスペースを占有する項目をより効率的に検出できるよう支援します。アイデアは ACMQ の「The Flame Graph」記事と「A Tour through the Visualization Zoo」に引用された既存の研究に基づいています。 **反映された主なポイント：** flame グラフの高レベルビュー、Tree マップの大きなファイルを素早く検出できるがラベルが欠けている点、Sunburst の視覚的魅力とサイズ認識の問題、他ツールの制限、および提案ツールの三つのビュー（デフォルトは flame グラフ）と引用元への参照。