2026/03/05 22:52

良いソフトウェアは、適切なタイミングで停止することがわかります。

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

元のHacker News記事へ ↗

要約▶

Japanese Translation:

（欠落していた点を補いつつ、明確さを保つために）**

要約

従来の

ls

コマンドは、AI‑Powered Directory Intelligence™ システムへ進化したことを告げる ASCII アートの通知を表示します。新しいユーティリティ als
が導入され、単にファイルを一覧表示するだけでなく、予測とランキングを行います。この通知は「The ls Team (now part of ALS)」によって署名されています。

初めの30日間はレガシー

ls

バイナリが機能し続けますが、その後は非推奨となり、アップデートは停止し、ディレクトリ認識機能も無効になります。ユーザーは

$ als --trial

で無料の30日トライアルを開始できます。本記事では、この変更を段階的な移行として位置づけ、長年にわたる Unix 標準を最終的に置き換えるものとしています。

この記事は、このシフトを目的・範囲・製品ビジョンというソフトウェア設計の原則と対比し、37Signals の Rework と Getting Real を引用しています。制約を受け入れ、不要な機能要求を無視し、早期リリースを行い、コアインターフェイスに焦点を当て、「いいえ」をデフォルトに設定し、必要なものだけを構築するという教訓を強調しています。著者は、ブランドの新規性のために事実上の標準を犠牲にするような急激な変更には警戒すべきと警告しています。

このバージョンでは、元のリストから重要なポイントを全て保持しつつ、移行の性質を明確化し、署名の詳細を追加しています。

本文

9時です。お気に入りの Linux ディストリビューションとパッケージを最新バージョンへアップグレードし、再起動後にマシンが完全に更新されたことを確認しました。普段通りに日常業務を進めている最中、ディレクトリの内容を

ls

で表示しようとすると、何か奇妙なことが起こります――慣れ親しんだ単調な振る舞いから外れた、予期せぬ驚きです。

$ ls

┌──────────────────────────────────────────────────────────────────────┐
│                                                                      │
│  NOTICE: The legacy utility `ls` has evolved.                        │
│                                                                      │
│         _       _                                                    │
│        / \   __| | ___                                               │
│       / _ \ / _` |/ _ \                                              │
│      / ___ \ (_| |  __/                                              │
│     /_/   \_\__,_|\___|                                              │
│                                                                      │
│              AI‑Powered Directory Intelligence™                      │
│                                                                      │
│  Hello.                                                              │
│                                                                      │
│  The classic `ls` command has reached the end of its lifecycle.      │
│  For decades it faithfully listed files.                             │
│  But listing is no longer enough.                                    │
│                                                                      │
│  The filesystem deserves to be *understood*.                         │
│                                                                      │
│  Introducing:                                                        │
│                                                                      │
│        █████╗ ██╗     ███████╗                                       │
│       ██╔══██╗██║     ██╔════╝                                       │
│       ███████║██║     ███████╗                                       │
│       ██╔══██║██║     ╚════██║                                       │
│       ██║  ██║███████╗███████║                                       │
│       ╚═╝  ╚═╝╚══════╝╚══════╝                                       │
│                                                                      │
│                       Adaptive Listing System                        │
│                                                                      │
│  `als` doesn't just show files.                                      │
│  It predicts which ones you meant.                                   │
│  It ranks them.                                                      │
│  It understands you.                                                 │
│                                                                      │
│  Your current `ls` binary will remain functional for:                │
│                                                                      │
│                        30 days                                       │
│                                                                      │
│  After this period:                                                  │
│      • `ls` will be deprecated                                       │
│      • updates will cease                                            │
│      • directory awareness will be disabled                          │
│                                                                      │
│  You can begin your transition today:                                │
│                                                                      │
│      $ als --trial                                                   │
│                                                                      │
│  (30‑day free evaluation period)                                     │
│                                                                      │
│  Thank you for participating in the future of file awareness.        │
│                                                                      │
│                         — The `ls` Team                              │
│                           (now part of ALS)                          │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

幸いにも、実際にこのような事象は起きません…
優れたソフトウェアは自らの役割を理解し、すべてをやろうとしない。何時止めるか、何を改善するかを知っているのです。

我々人間の「最大主義」な心理にとって最も直感に反する教訓は、自分のソフトウェアがどこでどんな役割を果たすべきかを学び、その上で次にやろうとしていることがその「プロダクトビジョン」に合致しているのか、単なる別のプロジェクト・ツールに過ぎないのかを判断することです。

最も古参の方々には、この種のレッスンが 37Signals（Basecamp の創業者）が執筆した Rework と Getting Real に現れています。特にプロダクト設計を学ぶ際は Getting Real をおすすめします。彼らの教訓は次のようにまとめることができます。

制約こそが強み – 小規模チーム、限られた予算、狭い範囲はより良い意思決定を迫ります。
機能要望は無視する – ユーザーの要求に応えるだけでなく、その裏にある本質的な問題を理解しよう。
早く出して頻繁にリリースする – 完璧を追い求めるより、実際に動作する半製品を素早く届けるほうが価値があります。
エピセンター設計 – 外部（ナビゲーションやフッターなど）ではなく、コアのインターフェース／相互作用から始めるべきです。
デフォルトでノーを言う – すべての機能には隠れたコストがあります：複雑さ、保守性、エッジケースなど。
自分自身のニーズに応える – 実際に必要なものを作ることで、より適切な判断が下せます。

Minio が AIStor へ、Oracle Database が Oracle AI Database へと変貌する時期において、私たちはすべてを劇的に変える必要はないということを思い出させられます。ある問題に対して de‑facto 標準となることこそが、期待されなかった新しいホットアイテムとしてブランディングするよりも価値が高いのです。

同じ日のほかのニュース

一覧に戻る →

2026/03/06 1:04

多数の管理者アカウントが侵害された後、ウィキペディアは読み取り専用モードになった。

## Japanese Translation: **概要:** 本書は、2026年2月20日から3月5日にかけて Wiki サービスに影響を与えた一連の技術的インシデントを記録しています。 - **2月20日:** 19:28 UTC に問題が確認され、19:44 UTC に修正が適用されました。23:33 UTC に監視を再開しました。 - **2月25日:** 16:40 UTC に調査が開始され、17:24 UTC に解決しました。 - **2月26日:** 16:25 UTC に修正で問題が解消され、16:58 UTC に監視を開始しました。 - **3月3日:** 10:09 UTC にデータベースサーバーの問題が検知され、10:24 UTC に修正が適用されました。10:17 UTC に監視更新が行われました。 - **3月5日:** 16:11 UTC に問題が確認され、17:09 UTC に初期修正（読み書き復旧）が実施されました。さらに編集は17:36 UTC の追加修正まで無効のままでした。18:36 UTC に監視を継続し更新しました。 3月4日、2月1–2、2月27–28、2月22–24、または2月21日はインシデントが報告されていません。インシデントは運用上の問題、性能低下、一部停止、大規模停止、およびメンテナンスカテゴリにわたります（ただし各イベントに対する具体的なカテゴリは割り当てられていません）。すべての修正後、チームは安定性を確認するために継続的監視を実施し、完全回復を宣言しました。ユーザーは一時的な読み取り専用アクセスと編集制限を経験し、継続的な Wiki 利用が必要な企業や教育グループの協力に影響を与える可能性があります。新たな症状が出現した場合に備えて、引き続き観測が行われることが示唆されています。 *この拡張版がご要望に合致する場合は、元の概要を置き換えることができます。*

2026/03/06 2:44

**「ブランドの時代」**

## 日本語訳: **要約：** スイスの時計業界は、1970年代に起こったクォーツ危機によって軌道を変えました。この危機は日本企業の競争とフランス・米ドル為替レートの急騰が引き金となり、ユニット販売数は1970年代初頭から1980年代初頭にかけて約3分の2減少しました。その結果、多くのメーカーは破綻または買収を余儀なくされました。残存した数社は純粋な技術的精密さから**ブランド主導のラグジュアリー**へとシフトしました。視覚的マイルストーンがこの転換を確固たるものにしました：パテック・フィリップの1968年「ゴールデン・エリプス」ケース、オーデム・ピゲの1972年ロイヤルオーク（ジェラルド・ゲンタ設計）、そして1976年のノーティラスはすべて技術的洗練よりも瞬時に認識できるデザインを強調しました。1984年にはパテックの広告代理店長レネ・ビッテルが「ホブナイル・カラトラバ」（3919）を提唱し、手巻き機構と独特な模様が投資銀行家の注目を集め、1987年までに売上を急増させました。メカニカル時計は**高級アクセサリー**として再登場しました。大きさと視覚的インパクトが男性の「ユーピー」（若手社会人）に富を披露するために理想的だったためです。ブランド時代は現在、オーバーサイズで独特な形状のケース、人工的希少性、および二次市場（例：パテックの時計買い戻し）の積極的管理によって定義されます。主要ブランドは階層化された製品ラインを割り当てる持株会社に統合されました。独立ブティックは、パテック・オーデム・ピゲ、ロレックスなどの数少ないフラッグシップハウスでのみ存続しています。業界がステータスシンボルに焦点を当てることで、メーカーによって管理される**資産バブルに似たビジネスモデル**が生まれました。 **教訓：** ブランド力は収益性を推進しますが、過度の依存はイノベーションを抑制するリスクがあります。次の「黄金時代」は、名声を売るだけでなく、本当に興味深い問題に取り組むことで生まれる可能性が高いです。

2026/03/02 18:26

**Linuxにおけるハードウェア・ホットプラグイベント ― 詳細解説**

## Japanese Translation: **概要：** Libusb の Linux ホットプラグシステムは、`linux_netlink.c` と `linux_udev.c` という 2 つのバックエンドに依存しています。デフォルトでは `--with-udev=yes` が設定されており、udev を無効にするとプレーンな netlink バックエンドが使用されます。カーネルデバイスイベントは Netlink プロトコル 15（`NETLINK_KOBJECT_UEVENT`）を介して到達し、ヌル終端文字列として `add@/devices/...` のようなアクション行から始まり、`ACTION=add`、`SUBSYSTEM=usb` などのキー／バリューペアが続きます。udev はこれらのメッセージを受信し解析して、カスタムパケット形式でマルチキャストグループ 2（`MONITOR_GROUP_UDEV`）に再送信します。 udev パケットは `"libudev"` というマジック文字列から始まり、ビッグエンディアンのバージョンワード `0xfeedcafe` を持ち、次にネイティブエンディアンで格納された複数フィールド（`header_sz`、`properties_off`、`properties_len`、`subsystem_hash`、`devtype_hash`、`tag_bloom_hi`、`tag_bloom_lo`）が続きます。ハッシュは `SUBSYSTEM=` と `DEVTYPE=` の値に対して MurmurHash2 を用いて計算され、2 つの Bloom フィルタワードは `TAGS=` キーから導出されたビットをエンコードします。その後パケットには元のキー／バリュー文字列と、`SO_PASSCRED` 経由で送られる Unix 認証情報（pid/uid/gid）が含まれます。カーネルメッセージはゼロ認証情報を持つため、libudev は有効な認証情報がないパケットを拒否します。プロトコルバージョンは固定で `0xfeedcafe` となっており、後方互換性や前方互換性に関する保証は文書化されていません。そのため、パケットレイアウト、フィルタリングロジック、または認証情報処理の変更は libusb と udev の両方で協調して更新を行う必要があり、ホットプラグイベントに依存するアプリケーションのデバイス検出、安定性、セキュリティに影響を与える可能性があります。