前々回の記事では、自宅の計算機環境を「複数世代併存」と「役割分離」で設計し、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 固有の統合スタック（Apple のドライバと省電力制御が一体化した世界）から離れるため、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 に依存 | 実質無限 |
ポイントは 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 の差分で「効いたものだけを採用する」方針に切り替えた。
2. GNOME のキーボードカスタマイズの入口を確認する（GUI と CLI）
GNOME の標準ショートカットは Settings → Keyboard（または Keyboard Shortcuts）に集約されている。まず 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 | [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 # 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 割り当て」が未完了だと判断し、次の手順に進んだ。
なお backslash と underscore の入れ替えは、この段階では成立しなかった。monitor 上では両方とも ro と出ることがあり、さらに Shift 同時押しでも別々に判定されるなど、入力レイヤ側の解釈が絡んでいる可能性が高い。ここは keyd だけで完結させず、後述の xkb / レイアウト側の確認対象としていったん棚上げした。
4. IME（IBus / Mozc）側に「F13 で ON/OFF」を設定する
keyd 側で ESC を F13 に退避した以上、IME 側が F13 を「日本語入力の ON/OFF」として扱わない限り、目的（ESC で日本語入力切替）は成立しない。ここが未設定だったので、IBus / Mozc 側で F13 を割り当てる。
再現性のために GUI の入口ではなく起動コマンドを残す。まず設定画面を開く。
1 | ibus-setup |
その後、Mozc のプロパティ（設定）を開き、キー設定で「IME の有効 / 無効（ON/OFF）」に F13 を割り当てる。設定後の検証は単純で、ターミナルやテキスト入力欄で物理 ESC（= F13）を押し、日本語入力がトグルすることを確認する。ここが通ると「物理 ESC を押すと設定が起動する」系の挙動は収束する。
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 が最も再現性が高い。これで「端末を起動する」導線（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 については問題がなかったため、いわゆる「問題が出ていないなら触らない」を維持した。動画のデコード経路は環境依存で、無効化は副作用（CPU 負荷増）を伴う。必要になったときだけ切る。
運用上の結論（この構成の最小安定点）
最終的に残った運用の骨格はシンプルである。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 に統一 | 軽さと扱いやすさ、設定の移植性 |
| ワークスペース | 9 固定 | 作業コンテキストを番号で固定 |
参考文献
- 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