前々回の記事では、自宅の計算機環境を複数世代併存と役割分離で設計し、iMac (2015) は macOS の寿命とサポート期限を見ながら限定用途に落としていく、という位置づけで整理した[1]。 しかしながら、macOS の EOL を現実の制約として受け止めたうえで、セキュリティ更新が止まった OS を、ブラウジングや開発の入口として使い続けるのは、運用として筋が悪いと再考した。そこで機材を捨てるのではなく、OS を入れ替えて寿命を伸ばす方向へ倒し、iMac (2015) を Debian 13 に置き換える判断をした。
目的は単なる延命ではない。Retina ディスプレイの表示品質は依然として強い価値を持つ。一方で、Debian GNU/Linux 側の安定版の更新と長期運用の思想を取り込めば、「高解像度で快適に見える GNU/Linux 開発環境」を、手元で長期に維持できる。結果として iMac (2015) は、前々回の限定用途から、Debian (GNOME + Wayland) [2]の主力 GUI 機として役割を引き上げることになった。
役割の変更
前回記事の「機材一覧」の表は、iMac (2015) を Debian に置き換えた時点で次のように更新される。表の狙いはスペックではなく、家庭内の作業導線に沿って、どの端末に何を担わせるかを固定することにある[1]。
| 機材 | OS | 想定役割 | 設計上の位置づけ |
|---|---|---|---|
| iMac (2015) | Debian 13 + GNOME (Wayland) | 高解像度 Linux 開発・ブラウジング | Retina の価値を Linux 側へ移し、長期更新できる GUI 主力機にする |
| iMac (2019) | macOS | 据え置き主力ワークステーション | 高解像度・並行作業・長時間集中の中心 |
| MacBook Pro 16-inch (2019) | macOS | 家庭内移動 GUI 機 | Retina の「見やすさ」を家庭内の任意位置へ持ち込む |
| ThinkPad X1 Carbon Gen6 | Debian 13 + Xfce4 | Unix 作業・運用・テキスト作業 | 長期維持できる Linux 基盤を作業用に切り出す |
この更新により、iMac (2015) は壊れるまで使う補助役ではなく、「EOL を跨いでも安全に更新できる OS に置き換えた上で、Retina の表示品質を活かして開発とブラウジングの入口を担う」端末になる。ここが今回の主題である。
この iMac の位置づけがどう変わったか
macOS のままの iMac 2015 は、OS 寿命が尽きており、ブラウザや開発ツールの更新が止まるリスクを抱えた「表示品質は良いが、開発の土台としては不安が残る端末」だった。Debian 13 化したことで、役割は画面が広く、入力体験が良く、更新され続ける開発機に変わった。iMac の価値は CPU や GPU の絶対性能というより、27-inch クラスの大画面と Retina 相当の高密度表示が作業の認知コストを大きく下げる点にある。そこに、Debian のアップデート可能性と再現可能な構成管理が合わさることで、主力の開発環境として成立する。
一方で、Mac 固有の統合スタックから離れるため、Linux 側の GPU ドライバやブラウザの描画経路に起因する不安定さが表面化しやすい。どのコンポーネントで不安定になり得るかを前提にして、ハードウェアアクセラレーションの切り分けと、入力系の安定化を考慮せねばならないことが課題である。
| 観点 | 移行前（macOS） | 移行後（Debian 13） |
|---|---|---|
| OS 寿命 | Apple 側の打ち切りに依存 | Debian アップグレードにて実質無限 |
| 表示品質 | 高い（Retina 相当） | 高い（HiDPI スケーリング運用） |
| 開発環境の再現性 | 個体差が出やすい | パッケージと設定で再現可能 |
| 不安定化ポイント | 比較的少ない（統合スタック） | GPU / ブラウザ / IME / 入力機器で発生し得る |
端末別の得意領域マトリクス
前々回の記事では、iMac 2015 は macOS の EOL によって主力から外れ、用途を限定して延命する枠として整理していた。しかし Debian 13 へ置き換えたことで、評価軸が OS 寿命の制約から表示品質と入力体験を含む開発環境としての総合力へ戻った。つまり iMac 2015 は EOL 回避のために退役させる端末ではなく更新が続く OS に載せ替えて再稼働させる端末になった。
この変化は、端末ごとの得意領域マトリクスにも反映される。重要なのは全部を最適にすることではなく、家庭内で複数端末を役割分割し、仕事の導線を壊さないことだ。以下は更新後の位置づけである。
| 作業領域 | iMac 2015 (Debian) | iMac 2019 (macOS) | MacBook Pro (macOS) | ThinkPad (Debian) |
|---|---|---|---|---|
| 長時間の並行作業（多数ウィンドウ） | 良 | 最適 | 良 | 不適 |
| 高解像度での閲覧（PDF、図表、動画、Web） | 良 | 最適 | 良 | 不適 |
| テキスト中心（Emacs、ターミナル） | 最適 | 最適 | 最適 | 可 |
| 運用作業（SSH、ログ、軽バッチ） | 最適 | 最適 | 最適 | 可 |
| 家庭内移動（場所を変えて作業する） | 不可 | 不可 | 可 | 最適 |
| サーバーとしての利用 | 可 | 不適 | 不適 | 可 |
| OS 利用可能期間 | 実質無限 | Apple に依存 | Apple に依存 | 実質無限 |
Debian 側は fractional scaling を用いる場合、表示品質は macOS Retina の「More Space」設定と完全に同一ではない。
ポイントは 2 つある。1 つ目は、iMac 2015 が Debian 化によって「テキスト中心」「開発・運用作業」において “十分に戦力” の位置に戻ったこと。2 つ目は iMac 2019 が引き続き「多数ウィンドウと高解像度閲覧の最適解」を担い、ThinkPad は「家庭内移動の最適解」を担うという全体設計が崩れていないことだ。EOL の恐怖で端末の役割が歪むのではなく、役割分割の設計が先にあり、OS はそれを支える手段に戻った。
なぜ Xfce4 や GNOME Flashback ではなく GNOME にしたか
今回の選択は軽さより表示品質と整合性を優先している。Xfce4 や GNOME Flashback は軽量で分かりやすい反面、HiDPI のスケーリング、Wayland[9] 前提で進化している入力周り、最近の GNOME の統合機能（ショートカット、設定 UI、ポータル連携など）との整合性が弱い場面がある。iMac 2015 を主力の開発機として使うなら、Retina 相当の表示密度を前提に、アプリ側の UI も崩れにくく、設定の置き場が明確な GNOME が最も合理的だった。
重要なのは、GNOME を選ぶ[5]こと自体ではなく、HiDPI を前提に作業の導線を固定できる点である。具体的には、ワークスペース数を 9 に固定し、ワークスペース移動とウィンドウ移動をキーボードで完結させ、端末を xfce4-terminal[24] に統一し、キー配列と日本語入力切り替えを OS レベルで揃える。ここまで揃えると、体験は macOS の統合された操作感に近づく。GNOME はそのための足場として適切だった。
Debian 13 インストール後の手順
ここからは、インストール後に実際に踏んだ「調査 → 判断 → 実施 → 検証」を、順番でそのまま残す。環境は iMac 2015、GNOME、Wayland のまま運用。Apple の Magic Keyboard / Magic Trackpad を使い、日本語入力は IBus / Mozc を前提とする。
1. GNOME Flashback 用スクリプトを GNOME に応用する
最初に手元にあったのが GNOME Flashback 向けの設定スクリプトだった。結論として、gsettings と dconf に流しているキー（org.gnome.*）は GNOME 本体でも基本的に同じため、Flashback 専用ではない。ただし「show-desktop-icons」のように、GNOME（Files / Extensions）側の実装差で無効化されているキーや、Flashback 前提のパネル設定などは影響が出る可能性がある。ここはスクリプトを盲目的に流すのではなく、gsettings writable の判定や dconf dump の差分で「効いたものだけを採用する」方針に切り替えた。
なお後日、GNOME 用のスクリプトをあらためて新規作成した。
2. GNOME のキーボードカスタマイズの入口を確認する（GUI と CLI）
GNOME の標準ショートカットは Settings → Keyboard に集約されている。まず GUI の入口を確認し、その上で再現可能な設定は gsettings / dconf のキーに落として記録する方針にした。理由は、GUI はバージョン差で文言や階層が揺れ、あとから同じ場所に辿り着けないことがあるからだ。
3. xmodmap 相当のキーリマップを Wayland で成立させる（keyd を使う）
やりたい変換は次のとおり。英数を Escape、かなを ENTER、物理 ESC を日本語入力切替、Command を ALT、ALT を Super、加えて backslash と underscore の入れ替え。
ここで最初にぶつかったのが、GNOME（Wayland）では伝統的な xmodmap の効果が薄いことだった。そこでカーネル入力レイヤで変換できる keyd を採用し、GNOME や IME より下層でキーイベントを作り替える方針に切り替えた。
まず「どのキーが何として認識されているか」を確定する必要がある。自分の環境では keyd のクライアントコマンドが見当たらない一方で、sudo keyd.rvaiya monitor は動いた。ここで英数キーを押すと hanja、かなキーを押すと hangeul と出た。押下のたびに hanja up / hanja down のように出るのは正常で、この表記が設定ファイルに書くべきキー名になる。
1 2 | sudo keyd.rvaiya list-devices sudo keyd.rvaiya monitor |
次に /etc/keyd/default.conf を編集し、keyd を有効化した。
1 2 3 | sudo editor /etc/keyd/default.conf sudo systemctl enable --now keyd sudo systemctl status keyd --no-pager |
実際の default.conf は次の骨格で作った。狙いは「物理 ESC を直接 IME に割り当てない」ことだ。物理 ESC は F13 に退避させ、IME 側で F13 を ON/OFF に割り当てる。こうすると、GNOME と IME の境界が明確になり、切り分けがしやすい。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | [main] # Map alphanumeric (hanja) key to Escape hanja = esc # Map kana (hangeul) key to ENTER hangeul = enter # Swap Command and ALT / Super (for Apple keyboards) leftmeta = leftalt leftalt = leftmeta rightmeta = rightalt rightalt = rightmeta # Always output "_" when pressing the JIS Ro key ro = S-ro # Use the physical ESC key as an IME toggle, handled via F13 instead of directly esc = f13 |
「esc = f13 にしたら物理 ESC を押すと設定が起動する」という現象が出た。これは GNOME 側（またはアプリ側）が F13 を何かのショートカットとして掴んでいるか、あるいは IME のトグルが未設定で、別の既定動作に落ちていることを示唆する。ここで「IME 側の F13 割り当て」が未完了だと判断し、次の手順に進んだ。
4. IME（IBus / Mozc）側に「F13 で ON/OFF」を設定する
keyd 側で ESC を F13 に退避した以上、IME 側が F13 を「日本語入力の ON/OFF」として扱わない限り、目的（ESC で日本語入力切替）は成立しない。ここが未設定だったので、IBus / Mozc 側で F13 を割り当てる。
再現性のために GUI の入口ではなく起動コマンドを残す。まず設定画面を開く。
1 | ibus-setup |
その後、Mozc のプロパティを開き、キー設定で「IME の有効 / 無効」に F13 を割り当てる。設定後の検証は単純で、ターミナルやテキスト入力欄で物理 ESC（= F13）を押し、日本語入力がトグルすることを確認する。ここが通ると「物理 ESC を押すと設定が起動する」系の挙動は収束する。なお起動時に IBus デーモンが起動していない場合は以下のようにする。
1 | ibus-daemon -drx |
5. Magic Keyboard / Magic Trackpad は「起動時は有線必須、起動後は Bluetooth でも可」
運用を固定した結論は「起動時に入力機器が認識されない」事故を潰すことだった。実際に起きたのは、起動後しばらくして Magic Trackpad が動作しなくなる／あるいは起動時に Bluetooth では入力が取れない、というパターンだ。ここで重要なのは、Bluetooth を完全否定することではなく、起動シーケンスに無線を持ち込まないことになる。
手順は次のように固定した。
| フェーズ | 方針 | 理由 |
|---|---|---|
| 電源投入〜ログイン画面 | 必ず有線接続 | 起動時に入力機器が見えない事故を排除する |
| ログイン後 | 必要なら Bluetooth に切替可能 | 以後はユーザーセッション内で再接続を確実に実行できる |
| 常用 | 基本は無線接続 | 過去に Magic Keyboard のバッテリー膨張があり、長時間の電池管理を避けたい |
起動後に Bluetooth を使えるようにするには、サービスが有効で、デバイスが pair / trust 済みで、connect ができる必要がある。まず bluetoothctl が使えることを確認し、Bluetooth サービスを有効化する。
1 2 3 | command -v bluetoothctl systemctl status bluetooth --no-pager sudo systemctl enable --now bluetooth |
次に bluetoothctl で手動再接続を行い、起動後に無線へ切り替えられることを検証する。入力例は次のとおり。MAC アドレスは実機に合わせて置き換える。
1 2 3 4 5 6 7 8 9 10 11 | bluetoothctl power on agent on default-agent scan on # ここで対象デバイスの MAC を控える pair XX:XX:XX:XX:XX:XX trust XX:XX:XX:XX:XX:XX connect XX:XX:XX:XX:XX:XX info XX:XX:XX:XX:XX:XX quit |
判断基準は info の出力で Connected: yes になり、実際にキー入力／ポインタが反応すること。ここが通ると「起動時は有線で確実にログインし、ログイン後は必要なら無線に切り替えられる」が再現可能になる。
6. xfce4-terminal を導入し、terminalrc を反映し、デフォルト端末を置き換える
GNOME 上でも端末は xfce4-terminal を使う方針にした。理由は、設定ファイル（terminalrc）をそのまま持ち運べて、動作が軽く、既存の運用資産があったからだ。まずインストール。
1 2 | sudo apt update sudo apt install xfce4-terminal |
次に terminalrc を反映する。xfce4-terminal は ~/.config/xfce4/terminal/terminalrc を読む。管理している terminalrc をそこへ配置し、端末を再起動して反映を確認する。
1 2 | mkdir -p ~/.config/xfce4/terminal /path/to/managed/terminalrc ~/.config/xfce4/terminal/terminalrc |
既定端末の置き換えは Debian 系では update-alternatives の x-terminal-emulator が最も再現性が高い。これで端末を起動する導線が xfce4-terminal に揃う。
1 | sudo update-alternatives --config x-terminal-emulator |
7. Firefox 利用中の黒画面を GPU ロックアップとして切り分ける
Firefox 利用中に画面が真っ暗になるが、ssh は生きており OS 自体は稼働している、という症状が出た。最初にやったのは現象が GPU 由来かどうかの確認だ。エラーだけを見るために journalctl を絞り、GPU 関連ログを抽出した。
1 2 | journalctl -b -p 3 journalctl -b | grep -i gpu |
ここで radeon の GPU lockup、ring stalled、atombios stuck、dpm resume failed などが大量に出ていることを確認した。次に、実際にどのドライバが使われているかを lspci で確定した。
1 | lspci -nnk | grep -A3 -E "VGA|Display|3D" |
8. radeon.dpm=0 を一時適用 → 効いたら恒久化する
GPU ロックアップのログに dpm 由来の失敗が含まれていたため、まず radeon.dpm=0 を試す方針にした。いきなり恒久設定にせず、GRUB の一時編集で効くかを確かめる。
GRUB 画面で起動項目を選び e を押す。linux で始まる行の末尾に radeon.dpm=0 を追加し、F10（または Ctrl + x）で起動する。ここで起動不能になった場合は再起動して元に戻せるので、一時適用で安全に検証できる。
効いた場合のみ /etc/default/grub の GRUB_CMDLINE_LINUX_DEFAULT に同じパラメーターを入れて update-grub する。
1 2 | sudo editor /etc/default/grub sudo update-grub |
9. firmware / Mesa を追加する
描画経路と周辺デバイスの不足を潰すため、次を入れた。
1 2 | sudo apt update sudo apt install firmware-linux firmware-linux-nonfree mesa-vulkan-drivers |
Wi-Fi が Broadcom 系だったため firmware-brcm80211 も追加した。これは機種依存なので、まずデバイスを確認してから入れる。
1 2 3 | lspci -nnk | grep -A3 -i network dmesg | grep -i brcm sudo apt install firmware-brcm80211 |
10. libinput-tools で入力イベントを観測する
入力が不安定なとき、まず OS にイベントが届いているかを見る。libinput-tools を入れて観測する。
1 2 3 | sudo apt install libinput-tools sudo libinput list-devices sudo libinput debug-events |
11. Firefox のハードウェアアクセラレーションと WebRender を無効化する
GPU ロックアップが疑わしい以上、ブラウザが GPU を叩く経路をまず止める。Firefox は Settings → General → Performance で「推奨のパフォーマンス設定」を外し、「ハードウェアアクセラレーションを使用する」を OFF にする。加えて about:config で gfx.webrender.all を false にした。
検証は about:support の Graphics で描画経路を確認し、同じブラウジング負荷で黒画面が再現しないこと、journalctl に GPU lockup が増えないこと。
12. Chrome も同様に GPU を切って安定化する
Chrome がガクガクして実用にならない状態になったため、Settings → System で「ハードウェア アクセラレーションが使用可能な場合は使用する」を OFF にして再起動した。検証は chrome://gpu を開き、Hardware accelerated の項目が無効化されていることを確認する。
13. 動画は問題が出ていないので触らない
一方でいかにも GPU に依存しそうな動画、たとえば VLC については問題がなかったため、問題が出ていないなら触らない。動画のデコード経路は環境依存で、無効化は副作用を伴う。必要になったときだけ切る。
14. Tracker を無効化する
Tracker（ファイル検索用のインデックス作成）が CPU と I/O を継続的に消費することがある。ファイルマネージャーや検索をほぼ使わない運用なら、削除ではなく「インデクサのみ無効化」を推奨する。GNOME 本体への副作用を避けつつ、常駐負荷をほぼゼロにできる。
1 2 3 4 5 6 7 8 | systemctl --user stop tracker-extract-3.service systemctl --user stop tracker-miner-fs-3.service systemctl --user stop tracker-miner-rss-3.service systemctl --user mask tracker-extract-3.service systemctl --user mask tracker-miner-fs-3.service systemctl --user mask tracker-miner-rss-3.service rm -rf ~/.cache/tracker3 rm -rf ~/.local/share/tracker3 |
15. 不要なサービスを停止する
デスクトップ兼サーバー用途では、印刷、Bonjour、WWAN、スマートカードなどの機能を使用しない場合、以下のサービスを停止することでバックグラウンド負荷とログノイズを削減できる。
印刷を使用しない場合
1 2 | sudo systemctl disable --now cups sudo systemctl disable --now cups-browsed |
Bonjour / 自動検出を使用しない場合
1 2 | sudo systemctl disable --now avahi-daemon sudo systemctl disable --now avahi-daemon.socket |
WWAN（モバイル回線）を使用しない場合
1 | sudo systemctl disable --now ModemManager |
スマートカードを使用しない場合
1 2 | sudo systemctl disable --now pcscd sudo systemctl disable --now pcscd.socket |
GVFS オンラインアカウント連携を使用しない場合
1 | systemctl --user mask --now gvfs-goa-volume-monitor.service |
DLNA / メディア共有を使用しない場合
1 | systemctl --user mask --now rygel.service |
GNOME Online Accounts を使用しない場合
1 2 | systemctl --user mask --now goa-daemon.service systemctl --user mask --now goa-identity-service.service |
GNOME Mail / Calendar を使用しない場合
1
2
3
systemctl --user mask --now evolution-addressbook-factory.service
systemctl --user mask --now evolution-calendar-factory.service
systemctl --user mask --now evolution-source-registry.service
1 2 3 | systemctl --user mask --now evolution-addressbook-factory.service systemctl --user mask --now evolution-calendar-factory.service systemctl --user mask --now evolution-source-registry.service |
なお、Bluetooth を入力デバイスで使用している場合、bluetooth.service は停止しない。
運用上の結論
最終的に残った運用の骨格はシンプルである。GNOME を Wayland のまま使い、Magic 系の入力は起動時は有線に固定し、キーリマップは keyd を採用し、IME は F13 をトリガにして切り替えを安定化し、ブラウザはハードウェアアクセラレーションを OFF にして GPU lockup を避ける。動画は問題が出た時だけデコードを切る。これで「Retina の表示品質を維持したまま、開発と日常利用が安定する」という狙いが達成できた。
| 項目 | 結論 | 理由 |
|---|---|---|
| デスクトップ | GNOME（Wayland のまま） | HiDPI と統合設定の整合性を優先 |
| 入力機器 | Magic は起動時は有線固定 | 無線の不安定要素を排除 |
| キーリマップ | keyd | Wayland で xmodmap 依存を避ける |
| ブラウザ | Firefox / Chrome とも GPU OFF | radeon 環境での描画不安定を回避 |
| 動画 | VLC は基本そのまま | 問題が出た時だけ HW decode を切る |
| 端末 | xfce4-terminal に統一 | 軽さと扱いやすさ、設定の移植性 |
| Tracker | 無効化 | リソースの節約、副作用の抑制 |
追記：本稿では GNOME Wayland に移行したが、後日 GNOME Flashback (Metacity) に移行した。
参考文献
- id774, 「複数世代マシンを前提とした計算機環境の設計」 (2026-02-07). https://blog.id774.net/entry/2026/02/07/3500/
- Debian（公式）. https://www.debian.org/
- Debian Installation Guide. https://www.debian.org/releases/stable/installmanual
- Debian Security. https://www.debian.org/security/
- GNOME（公式）. https://www.gnome.org/
- GNOME Help（Keyboard Shortcuts）. https://help.gnome.org/users/gnome-help/stable/keyboard-shortcuts-set.html
- GNOME dconf. https://wiki.gnome.org/Projects/dconf
- gsettings（GIO）. https://developer.gnome.org/gio/stable/gsettings-tool.html
- Wayland（公式）. https://wayland.freedesktop.org/
- X.Org（概要）. https://www.x.org/wiki/
- IBus（公式）. https://github.com/ibus/ibus
- Mozc（Japanese Input Method）. https://github.com/google/mozc
- keyd（rvaiya）. https://github.com/rvaiya/keyd
- Linux kernel radeon driver（概要）. https://www.kernel.org/doc/html/latest/gpu/radeon.html
- Linux kernel amdgpu driver（概要）. https://www.kernel.org/doc/html/latest/gpu/amdgpu.html
- Mesa 3D（公式）. https://www.mesa3d.org/
- Linux Firmware（linux-firmware）. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
- Firefox Hardware Acceleration（support）. https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-caused-hardware-acceleration
- Firefox about:config（support）. https://support.mozilla.org/en-US/kb/about-config-editor-firefox
- Chromium GPU（内部ページ）. chrome://gpu
- VLC（公式）. https://www.videolan.org/vlc/
- VLC command line（wiki）. https://wiki.videolan.org/VLC_command-line_help/
- FreeDesktop XDG MIME Apps. https://specifications.freedesktop.org/mime-apps-spec/latest/
- xfce4-terminal（Xfce）. https://docs.xfce.org/apps/terminal/start