西川和久の不定期コラム

人生初のUbuntuがメイン環境へ!夏休みの工作でCore i9-12900搭載ミニPCを組む【後編】

メイン環境となったUbuntu 22.04 LTS Desktop秀丸を使わないで済むよう、geditの行番号を折り返した行もカウントする仕様に変更のため用意したbuild環境。buildはできたが、肝心の部分はgeditのコードではなくGTKの中と分かり頓挫(笑)

 以下の関連記事にあるように、前編ではCore i9-12900マシンを組み、試しでChrome OS Flexを入れ、軽くCPUの温度や冷却ファンの動作音、CPUのパフォーマンスを確認した。後編ではいよいよ本番用のOSをインストールして仕事環境を構築してみたい。

Ubuntu 22.04 LTS Desktopをインストール。24型+14型の上下マルチモニター運用

 前編の最後にChrome OS Flexを入れた後、数日そのままの状態で使っていたが意外といける。Photoshopなど画像処理系だけM1 Mac miniに残したこともあり、元々多くの業務系がChrome上だったので十分と言ったところ。

 あまりにも便利なので、Linux環境を整えだしたところで「いや違う。このOSがメインじゃない」と思い留まり、本番用のOSをインストールすることにした。

 さて、本番用のOSはWindowsではなくUbuntu 22.04 LTS Desktopを選んだ。理由はWindowsに飽きた(笑)のと、事前にThinkPad 13へ入れ、そこそこ使っていたのだが、別にmacOSがあるのなら何も困らないということが分かったためだ。もちろんWSL2経由ではなく素のままでdocker/docker-composeが使えるという最大の利点もある。

 長年、メインの環境はWindowsかmacOSだったが、Ubuntuになるのは今回が初! おそらく5〜10年前ならまだまだアプリ主体だったので無理だったと思う。しかし今はほとんどChrome上と、Visual Studio Code、そしてUnix的なコマンドで過ごしているので可能になったとも言える。

 Ubuntuのインストール自体はISOイメージをダウンロードし、USBメモリに焼いてPCを起動。ウィザードに従ってインストールと簡単なので省略。とりあえずの環境設定は以下の記事の通りコピペした。

 新規でインストールした大物アプリは「Chrome」、「Visual Studio Code」、「FileZilla」。Wine関連は「秀丸」と「WinSCP」。これでサクッと業務可能になった。

 実際触ってみると、Google Octane 2.0がM1 Mac miniの7.4万を遥かに上回る9.6万と爆速のためOffice(Google Workspace/Office Online)系も含めサイトアクセスは快適そのもの。オフラインでのOffice系は、標準でインストールされているLibreOfficeをたまに使っているが、筆者の用途では今のところ特に問題は発生していない。

自宅の仕事環境。メインモニターBenQ SW240(上)/14型モバイルモニター(下)。Magic Trackpadは左、Magic Mouseは右。右側にあるのはM1 iPad Pro 12.9とMagic Trackpad 2。見えてないがその横に第9世代Core i7搭載のMacBook Pro 16。この2つはUniversal Controlでつながっている。左側には見えていないが3rdモニターがある。肝心のASRock DeskMeet B660は、机の下なので見えない

 周辺機関連はBenQ SW240がメインモニター、サブはフルHD14型のモバイルモニターをメインの下へ少し傾けて設置。一般的な左右のマルチモニターではなく上下にしたのは、個人差もあるだろうが視線の動きが少なく、楽なのが理由だ。

 サブ側にGmail、カレンダー、Slack、Messenger、iCloud(macOSのメモと同期)、OneDriveなど業務用のタブが並んでおり、メインモニターで作業中でも即アクセスできるようになっている。メイン側は仮想デスクトップを使い、1つは原稿など通常用、ほかはプロジェクトごとにドキュメント類、Visual Studio Codeと動作確認用のChromeやTerminalが並んでいる。

 メインモニターに接続しているM1 Mac miniは、マウス/キーボードともにBluetoothにして、使わないときは机近くに片付けている。3番目のモニターにも接続しているので、ちょい使いの時は、SW240の入力を切り替えずにそのモニター上で操作する。

 また一時的にDisplayLinkを使いサブモニターに接続していたが、ドライバをここからダウンロードして問題なく動作。遅延もなく普通のディスプレイ出力と変わらない描画だった。

 操作系デバイスは、Apple Magic MouseとMagic Tackpadで、どちらも初代。キーボードも含め一番触れる部分であり、ここが妙だと作業効率が大幅に低下する。幸いどちらもmacOSで使っているかのごとく快適に動作する。しかし、Magic MouseはmacOS上より垂直スクロールが鈍く、水平スクロールがセンシティブで今一歩だ。

 またKernel Moduleが用意されており、以下のような調整も可能だ。一般的なポインタの移動速度、2本または3本指での動き、スクロールの向きなどは、設定→マウスとタッチパッドで調節できる。

sudo rmmod hid_magicmouse
sudo modprobe hid_magicmouse emulate_3button=0 scroll_acceleration=1 scroll_speed=55

 キーボードは写真から分かるようにバックライト付き(茶軸)。部屋が間接照明のみなので、ノートPCも含めバックライトがないと使いづらい。もともとmacOSで使っていたが、UbuntuへUSBで接続している。後はAudio系(Audioengine A2+)もMac miniからこちらに移した。Web会議はノートPCで行なうためカメラはない。

 Windowsに関してはM1 Mac miniの頃から2つ前のメインマシン、第10世代Core i5搭載のIntel NUCにリモートデスクトップ(RDP)接続している。

 昔はVMを使いメインOS上で動かしていたが、筆者の場合、ほぼ自宅。Windowsマシンはあり余っているので、それへRDP接続すれば事足る的な発想だ。UbuntuにはRDPサーバー/クライアントどちらも入っており、簡単にWindowsへ接続できる。

Ubuntu標準搭載のRDPクライアント。2つ前のメインマシン、第10世代Core i5搭載Intel NUCへ接続。このマシンはモニターもHIDも接続していない

 そこそこ環境が整ったところで思い出したのがスキャナ。複合機の「ブラザー MFC-J903N」を使っているのだが、たまに紙で印刷した書類にサインしてPDFで戻すというのがあるので必要。探すと標準で「ドキュメントスキャナー」アプリがあり、ネットワーク上のデバイスを自動的に検索、あっけなくスキャンできた。

自動的にネットワーク上から「ブラザー MFC-J903N」を検索

 最後はNASのマウント。通常、ファイルアプリからマウントするとSMBになるのだが、これだとなぜかファイルアプリからドラッグ&ドロップでVisual Studio Codeに落としてもファイルが開かない。

 そこでsshfsで別途マウントすることにした。以下の例だとホームディレクトリへnasというフォルダを作り、そこへマウントしている。この場合、当然NAS側でsshの設定が必要となる。

sshfs -o allow_other user@192.168.xxxx.xxxx:/share/DATA/works ~/nas

 ついでにRaspberry Pi4で動作しているWebサーバーへも同じくこの方法でマウント。SFTPせずにファイルアプリの操作だけで済むようにした。

問題点や工夫など。E/Pコア対応はひと手間必要

 さて、気になるCore i9-12900(Alder LakeのE/Pコア)対応だが、調べて見るとUbuntu 22.04 LTS標準のKernelバージョン5.15では完全に対応しておらず、Ubuntu公式によると5.16以降が必要とのこと。いきなり問題発生だ。

 幸いKernelを入れ替える方法は用意されており、「Ubuntu Mainline Kernel Installer」を使えばGUIで操作可能。インストールは以下の通り。

sudo add-apt-repository ppa:cappelikan/ppa
sudo apt update
sudo apt -y install mainline
Ubuntu Mainline Kernel Installer。E/PコアはKernelのバージョン5.16以降で対応とのこと。現在は5.19.2が入っている

 起動すると、好きなバージョンのKernelをインストールできる(再起動が必要)。当初は5.18.15を入れていたが、現在は5.19.2が入っている。

 システムモニターで確認したが、どれがEコアでどれがPコアか分からないこともあり、本当に機能しているかは不明だが、Ubuntu公式の言葉を信じることにする。

 次にしばらく使っていると何かの拍子でファンが思いっきり回り出し、CPUの温度が90℃超え。特に負荷のかかる処理をしていなかったのだが、システムモニターを見ると犯人はChrome。Chromeを落とすとこの現象は収まった。このCPU100%貼り付き問題、どうやらLinux版Chromeだけの症状らしく、Windows/macOS版では経験したことがない。

左側の山はdocker build中。この時CPUの温度は最高60℃ほど(通常は35℃前後)。Chromeの暴走が始まると100%へ貼り付いたままになり90℃を超える

 また発生したので、次はChromeのその他のツール→タスクマネージャーでどの部分か調べたところ、とある広告だった。確かにそのタスクを終了すると何事もなく動き出す。

 その後も様子を見ていると、なぜそんなにCPUを食うのか理由は不明だが、とにかくCPU使用率が高い多くは広告。仕方なく広告ブロック拡張機能を導入した。以降この現象は発生していない。結構前からあるバグらしいが、さすがに修正してほしいところ。なお、CPU温度の監視には「Hardware Sensors Indicator」をインストールしている。

 次に発生した問題はWine。おそらくLinux/Windows間の画面マッピング関係だろうが、DisplayPort側のモニターでアプリを動かすと正常、HDMI側のモニターではアプリは起動するものの、その後まったく動かなくなる。

 これもあってメインのSW240にはDisplayPort→HDMI変換ケーブルを使って接続している。サブ側は先に書いた通りChromeのみ。業務用のタブが並んでいるだけで、Wineでのアプリは使わないので大丈夫だ。参考までにDisplayLinkで接続したモニターでは問題なく動作した。

 Wine関連はもう1つ問題が発生。32bit/64bit版秀丸が何かの拍子でLinuxへの(からの)コピペができなくなる。ThinkPad 13上のUbuntu@Kernel 5.15では今のところ出ていないので、Kernelの関係かもしれない。いったん終了して起動し直せば大丈夫なのだがさすがに不便。

 筆者が秀丸を使うのは秀丸依存ではなく、単に幅半角80文字の時、折返しの行も行番号をカウント、何行書いたかパット見分からるからというだけ。そのため、macOSでは同様の機能を持つmiに乗り換えている。geditも含む一般的なエディタは折り返した行はカウントしないのでこれには対応できない(このような需要は日本語でしかも一部なので当然だが)。

 当初はほぼgeditで書き、そろそろ上がるかな的なタイミングで秀丸を使い確認していたが、今はhtml/css/Javascriptを使い原稿を読み込み、行数をカウント/表示する簡単なWebページを作って確認している(lc -w80 原稿.txtで行番号を表示するcliでもいいのだが。※lcはline countの略)。

 これでもう秀丸を使う必要はない。どうでもいい人にとってはバカバカしい話だろうが、友人のライターもChrome OS Flexで原稿を書く時、これができないとぼやいていたので、若干の需要はあるかもしれない。

 時間があればWebベースでこれに対応可能なエディタを作ってみたいところ。Javascriptを使ったエディタのライブラリがいろいろあるので、やればできそうな感じだ。

html/css/Javascriptで作った幅固定文字数で折り返した行も含めて何行かをカウントするWebサイト。エンジンは小山氏@Leptonが作成。筆者は見栄えや機能を追加しただけ。同様の問題を抱える友人のライターなどと共有している

 ちょっとしたことだがmacOSの環境に合わせたのは、Quick Lookと執筆用のフォント。前者はファインダーでファイルを選択、[Space]キーを押すとその内容を表示する機能だ。テキスト、画像、PDFはもちろん、完全ではないがOffice系のファイルも見ることができる。これ意外と便利でいつも使っているのだが、相当する機能が標準ではない。探すと「gnome-sushi」がそれだったのでインストール。

sudo apt install gnome-sushi

 これで同様に[Space]キーを押せば見れるようになった。ただ1つ残念なのは、Quick Lookはファインダーだけでなく、添付やアップロードなどでファイルを選択する時にも有効。確認できるため事前にミスを防げるのだが、このgnome-sushiはファイルアプリでしか有効にならない。

 後者は執筆やコーディング時にエディタで指定しているフォント「源真ゴシック 等幅 Normal」。ここからダウンロードしてインストールすればUbuntuでも使えるようになる。

 あと、PhotoshopはM1 Mac miniでと書いたが、例えば画像のある部分にモザイクを入れるために切り替えるのは面倒なので「Glimpse Image Editor」をインストールした。Kritaなどいろいろ画像処理アプリを試したものの、満足はしていないが結局残ったのがこれだった。

 モニターのキャリブレーションに関しては、Mac mini側からSW240をハードウェアキャリブレーションできるため、標準で入っているAdobe RGB(1998)のProfileを設定→カラーでそのまま指定している。SW240はAdobe RGB 99%だが、Ubuntu側は画像処理用ではないため若干の誤差は気にしない。もちろんサブモニター側はDisplayCALで調整済みだ。

Glimpse Image Editor。モザイク処理などM1 Mac mini側のPhotoshopを使うまでもない時に使用

爆速度は!?

 OSが違うため共通で使えるGeekbench 5の結果を、Core i9-12900、M1 Mac mini、M1 Max Mac Studio(友人に測定をお願い)で見てみたい。なお、Core i9はメモリをA1+B1からA2+B2にした時の結果となる(後者の方が明らかに速くなる)。GPUに関してはiGPUと比べるまでもないので省略(笑)。

 結果はご覧の通り。少なくともCPUに関してはシングル/マルチともに発熱や消費電力を無視すればCore i9-12900の圧勝。前編でも書いた様に「当然買い替え(買い増し)になるとこれ(M1 Mac mini)より速いことが最低条件」はクリアしたことになる。

 対Mac Studioで見ると、M1 Max(10CPU/24GPU/メモリ32GB/SSD 512GBモデルが27万8,800円)。半値の約13万円でこれだけのパフォーマンスなので筆者的には大満足。同じく前編でも書いた「GPUは映れば何でもOK、ただしCPUは爆速に限る!」を達成だ。

 逆に言えば、プラス倍の部分であのdGPUに迫るiGPU、ユニファイドメモリ、Neural Engine、Thunderbolt 4、映像/サウンド……などを考えると妥当な価格ではないだろうか。

 ケースの関係からCore i9-12900のわりにコンパクトな冷却ファン(Ainex IS-40X-V2)しか入らなかったので気になっていたCPUの温度は、通常処理で34〜40℃未満。dockerのbuildで最大60℃程度。ベンチマークテストなど高負荷が続く状態で60〜70℃。先に書いたChrome CPU 100%貼りつき問題の時だけ90℃を少し超えた。

 さすがに60℃を超えるとファンの音が若干うるさいものの、これまで実際使ってきたシーンでは上がっても瞬時なので気になったことはあまりない。それだけやってることのわりにパワーが余っているという話なのだが……。


 実は8月10日にはシステムの移行が終わっており、すでに数週間ほどUbuntu上で仕事をしている。連載で載せた「NEC Mate タイプMC<MC-C>」と「Beelink SER5 5600H」の記事もUbuntu上で秀丸もしくはgeditを使って執筆。

 その間、M1 Mac mini上のPhotoshopを使ったのは、記事の物撮りと別件の撮影。どちらもRAWなので現像後、必要な処理をした。やはりほぼPhotoshop専用機で使うと出番はかなり少ない感じだ。

 仕事ではxlsx/pptx/PDFなどが飛び交い、Slackは結構な頻度でメッセージをやり取りし、docker-compose down/up -dやgit pull/pushは日常茶飯事。Visual Studio Codeは仮想デスクトップ2つ分=2プロジェクト同時進行と、それなりに忙しい日々なのだが、先に上げたトラブル以外は特に何もなく安定動作している。再起動もKernelの入れ替え以外では行なっていない。updateもすぐ終わり仕事の邪魔をすることもない。なかなか快適な環境だ。

 今回はM1 Max Mac StudioよりCPUだけでも速く! と欲張ったのでCore i9-12900になっているが、第4世代以降程度で余ってるPCなどがあれば、WindowsでもmacOSでもない、Ubuntuを試して見てはいかがだろうか?事務職よりはエンジニア系の人にお勧めしたいOSだ。

 これで2022年夏休みの工作は無事終了。次はM3? Macに戻るのか、第14世代の最速CPUにするのか、どうなることやら……(完)。