PCに関する階層についての知識とlinuxとmacのパッケージ管理についてまとめた

Last updated at 2026-03-06Posted at 2026-03-06

Linux（Fedora）における階層構造とパッケージ管理の哲学

—— T2 MacBook × 開発環境構築の完全ガイド ——

Linuxシステムを構築する際、OSの階層構造（Layer）とパッケージの導入場所の関係を理解することは、トラブルのない快適な環境を作るための第一歩です。これまでの議論をベースに、その全体像を整理します。

1. OSの「2大空間」と keyd の特殊な役割

Linuxは大きく分けて2つの空間で構成されています。

① カーネル空間 (Kernel Space)

住人: apple-bce (T2用ドライバ), kernel-t2
役割: ハードウェアを直接制御する特権階層。
特徴: 非常に強力ですが、ここでバグが起きるとOS全体がクラッシュ（カーネルパニック）します。

② ユーザー空間 (User Space)

住人: keyd, dnf, Docker, GNOME, uv, Chrome など。
役割: 私たちが普段触るすべてのアプリやサービスが動く場所。
特徴: 互いに隔離されており、1つが落ちてもOS全体は無事です。

【深掘り】なぜ keyd は Docker にまで影響するのか？

keyd はユーザー空間に住みながら、カーネルの uinput という窓口を通じて「仮想キーボード」を生成します。

入力の根元を加工: 物理キーボードの信号を keyd が受け取り、即座に変換（例：Caps → Control）。
加工済みの水を流す: OS全体には「加工後の信号」が「本物のキーボードからの信号」として流れます。
Dockerへの波及: DockerコンテナはホストOSの入力デバイスをそのまま利用するため、keyd という「浄水器」を通った後の「きれいな水（設定済みの入力データ）」だけがコンテナの中に届くのです。

2. Dockerの階層構造：隔離と共有

Dockerは、**「ユーザー空間の中に、さらに隔離されたミニチュアのユーザー空間（コンテナ）を組み立てる」**技術です。

共有されるもの: カーネル（深層）。これにより、keyd が加工したデバイス信号などはコンテナ内でも有効になります。
隔離されるもの: ファイルシステム（浅層）。ホストOSの /usr/bin にあるツールなどは、コンテナからは見えません。

補足：Mac vs Linux パッケージ管理・完全比較ガイド

MacからFedora（Linux）へ移行する際、最も重要な「どこに何をいれるべきか」という哲学を、クリーンさの観点からまとめました。

1. パッケージ管理徹底比較表

比較項目	Mac: Homebrew	Mac: curl インストール	Linux: dnf (公式)	Linux: curl \| sh (推奨)
管理主体	ユーザー	ユーザー（バラバラ）	OSシステム (root)	ユーザー (個人)
設置場所	`/opt/homebrew`	`/usr/local/bin` など	`/usr/bin`	`~/.local/bin`
設定ファイルの場所	`~/.config` / `~/Library`	`~/.config` / `~/`	`/etc` (システム全体)	`~/.config` (自分専用)
一覧の確認方法	`brew list`	(手動で探す)	`dnf list installed`	`ls ~/.local/bin`
sudo要否	不要	必要になることが多い	必須	不要
クリーンさ	★★★★☆	★★☆☆☆ (散らばる)	★★★☆☆ (OSと混ざる)	★★★★★ (最高)
削除方法	`brew uninstall`	手動でファイルを探す	`sudo dnf remove`	フォルダを消すだけ
主な用途	一般アプリ・開発ツール	公式配布がないツール	OS基盤・インフラ	uv, volta等の開発ツール

① 設定ファイルの場所の違い

dnf (/etc): keyd などのシステム基盤は /etc という場所に設定を置きます。ここは「家の設計図」のような場所なので、編集には sudo 権限が必要です。
curl (~/.config): uv や volta などの個人ツールは、自分の部屋にある .config フォルダに設定を置きます。OSを汚さず、自分の権限だけで自由に設定変更やバックアップが可能です。

② 「一覧確認」の考え方

Linuxでの curl インストールが Mac より管理しやすいのは、インストール先が ~/.local/bin という「1箇所の決まった引き出し」に集約されるからです。brew list の代わりに、このフォルダの中身を ls で見るだけで、何を入れたか把握できます。
Macで curl インストールが嫌われる理由は、ファイルがシステム（/usr/local/binなど）に散らばり、アンインストールが困難になるからです。しかし、Linux（特に uv や volta）では以下のルールが徹底されています。
ホームディレクトリ完結: インストール先が ~/.local/bin や ~/.cargo/bin など、自分のホームディレクトリ内に限定されます。
XDG標準の遵守: 設定ファイルは ~/.config/、データは ~/.local/share/ と場所が決まっており、brew list がなくても「自分の部屋（ホームディレクトリ）を探せば何を入れたか一目でわかる」ようになっています。

2. 「クリーンさ」の定義：Mac と Linux の違い

Mac における「クリーン」

Macでは /usr/local などのシステム領域をいじらず、brew が管理する独立したフォルダ（/opt/homebrew）にすべてを閉じ込めることが「クリーン」とされます。逆に curl インストールは、どこにファイルが置かれたか分からなくなるため、敬遠されます。

Linux における「クリーン」

Linux（特にFedora）の dnf は、ファイルをOSの心臓部（/usr/bin）に直接配置します。これは「公式管理」なので安全ですが、OSのファイルと私物のツールが混ざってしまいます。

真に「クリーン」なのは、「自分のホームディレクトリ（~/）の中で完結させること」です。
現代の Linux 向け curl インストール（uv など）は、「自分の部屋の中にだけ道具を置く」仕組みになっています。

なぜ最高にクリーンなのか？:
もしそのツールが不要になったり、環境が壊れたりしても、OSには一切影響を与えず、自分のホームフォルダ内の該当ディレクトリを消すだけで「無」に戻せるからです。

3. 使い分けの鉄則（T2 Mac Fedora版）

① システム基盤：`dnf` で入れる

対象: keyd (キーボード), docker
場所: 本体は /usr/bin、設定は /etc
理由: これらは「家全体の配線（ハードウェア制御）」に関わるため、OSという工務店にしっかり管理させる。

② 開発ツール：`curl / sh` で入れる

対象: uv, volta, rustup
場所: 本体は ~/.local/bin、設定は ~/.config
理由: これらは「自分の机の道具」。OSの更新を待たず、常に最新版を自分の権限だけで安全に使い倒すため。

4. 管理のための Tips

実体を確認する: which [コマンド名]
- /usr/bin/ ＝ OS（dnf）が管理しているプロ仕様。
- /home/ユーザー名/ ＝あなた（curl）が管理している私物。
一覧を確認する: ls ~/.local/bin
- ここを見れば、自分が curl で何を入れたか一目で分かります。

なぜ Linux では `curl | sh` が好まれるのか？

Macの brew は、OS標準の環境（/usr/bin）を汚さないように独立した場所（/opt/homebrew）にインストールされるため、非常にクリーンです。

一方で、Linuxの dnf は 「OSそのものの一部」 として /usr/bin に実行ファイルを配置します。
そのため、uv や volta のような「頻繁にアップデートが必要な開発ツール」を dnf で入れてしまうと、以下の不都合が生じます。

OSの制約: uv self update をしようとしても、「システム領域を勝手に書き換えるな」とOSに拒否される。
依存の混濁: OSが安定のために保持している古いライブラリと、最新のツールが衝突するリスクがある。

結論：
Linux（Fedora）では、「システム基盤（keyd, Docker）は dnf」、「個人の開発ツール（uv, volta）は curl | sh」 と使い分けるのが、Macにおける brew 管理以上に「システムを汚さない」賢いやり方となります。

3. パッケージ管理の戦略：System-Global vs User-Global

Linuxでは「どこにインストールするか」で、ツールの自由度と安全性が決まります。

A. システム・グローバル (dnf install)

場所: /usr/bin/ (全ユーザー共通の共有スペース)
権限: sudo (root権限) が必須。
対象: keyd, docker, google-chrome
思想: 「家全体のインフラ」を整えるための工事。OS（dnf）という公式の管理者に任せるのが最も安全。

B. ユーザー・グローバル / ローカル (curl | sh)

場所: ~/.local/bin/ (自分のホームディレクトリ内)
権限: sudo 不要。
対象: uv, volta, rustup
思想: 「自分の作業机」に置く道具。OSの管理から外すことで、uv self update などで自由に最新版へ更新でき、OSのシステムを汚さない（フォルダを消すだけで掃除完了）。

比較項目	dnf (システム)	curl \| sh (ローカル)
管理主体	OS（管理者）	自分（ユーザー）
場所	`/usr/bin`	`~/.local/bin`
更新	OSの更新に依存（安定）	自分のタイミングで即座に（最新）
影響	全ユーザー	自分だけ

4. uv による魔法：ツールチェーン管理

「ローカルに最新の uv を入れる」ことは、古いバージョンを捨てることではありません。

マネージャーとしての uv: ~/.local/bin/uv にある最新版は、非常に賢い「管理人」です。
古いバージョンの保持: プロジェクトごとに「このバージョンが必要」という指定があれば、最新の uv が裏側で過去バージョンの uv や Python を自動ダウンロードし、使い分けてくれます。

これにより、**「自分の部屋には常に最新の管理人を置きつつ、仕事内容（プロジェクト）に合わせて過去のツールも自在に呼び出す」**という、最強の柔軟性が手に入ります。

5. 結論：構築のロードマップ

土台を固める (dnf):
sudo dnf install keyd でキーボードを「プロ仕様（US配列風）」に改造。これはOS全体・Docker全体の「インフラ」になる。
作業机を整える (curl):
uv を ~/.local/bin に導入。OSを汚さず、常に最新の機能を使える状態にする。
コンテナで隔離する (Docker):
プロジェクトごとのライブラリやツールは、ホストOSを汚さないように Docker コンテナの中で完結させる。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up