NixOS 〜理想は高いが現実はきびしい〜

NixOSを試し初めて数日経ちます.インストールしてみた環境は,

  1. M4 Mac mini: macOS + UTM1
  2. Core i7実機
  3. Core i7: Manjaro (Linux) + KVM/QEMU

この中で一番サクサク動くのは,1のM4 Mac mini + UTMです.Aarch64だとあれはだめ,これはだめ,という制約は今のところないです.

NixOSを選んだ理由の一つには,昔Slackwareで標準デスクトップに選ばれたことのあるEnlightenmentが選べるということもあります.よく覚えていないのですが,何かキラキラした印象が残っていて,また使ってみたいと思いました.

最初はGNOMEを利用したBudgieというデスクトップにしました.これまで使用したことがない感じなので選びました.アプリケーションの起動は,MacではCommandキーを押してドックとアプリケーションの一覧を表示して行います.あまりそういうスタイルにはなじみがないのですが,だからいいのかなと思いました.

しばらくしてわかってきた頃に,Enlightnmentに切り替えを敢行しました.普通のLinux distroであればCUIやGUIのパッケージマネージャーで行うわけですが,/etc/nixos/configure.nixという設定ファイルをエディターで書き換えます.そこがNixOSの一番の特徴です.そして,

nixos-rebuild switch

というコマンドをroot権限で実行すると,必要なパッケージの追加やデフォルト設定が行われて,rebootすると新しいデスクトップ環境で動きます.

最初のBudgieからKDE Plasmaは問題なく行きました.しかし,期待のEnlightnmentはエラーが出てしまい,切り替えることができませんでした.ネットで調べるとPythonのモジュールの何かの依存性に問題があってしばらくこの状態が続いているようです.

ManjaroでKDE Plasma, DebianでもKDE PlasmaなのでNixOSでもKDE Plasmaにしたままでは何の面白みもないので,そこでKDE PlasmaからBudgieに戻しましたが,マウスポインターが半透明のグレーの正方形(スクリーンショット画像のFirefoxのアイコンの上のグレーの正方形)になって,どういう状況でも変わらず,非常に使いにくくなってしまいました.

ドックのFIrefoxのアイコンの上にあるグレーの正方形がマウスポインターの化けた姿

また,ブートローダーのinstall, updateに何か制約があるのか,3のCore i7のKDE/QEMU環境ではうまく起動しくれません.

一つの設定ファイルの書き換えでシステムを大きく組み替える,という高い理想のシステムを大胆な仕組みで実現しようとしていて,そこは大いに評価したいですが,実用的にはなかなか厳しいかなと思います.

Core i7 の実マシンはある程度「評価」してまたDebianに戻します.

  1. MacBook Air M4 + UTMでもインストールしましたが,本質的にはM4 Mac miniと変わらないので割愛. ↩︎

UTMでManjaro ARM

何とか動かしたいと思い,普通のアプローチではうまくいかないのでネット検索したら手順を詳細に紹介されている記事を見つけました.

この記事の表題にあるように,普通にManjaro ARMのGeneric-EFIイメージを使ってUTMで起動させると,初回の設定モードは動くのですが,設定を終えてリブートすると起動してくれないのです1

最新のUTM2と最新のManjaro ARM Genericのイメージファイルで上記記事のとおりに手順を踏むと3,初回の設定ができて,リブートもできます.またLinux (Kernel)とLinux-api-headersをupdateから除外してupdateもかけられますが,筆者の場合そこでエラーが出てしまいました.

仮にこれでうまく動くようになってもKernelのupdateが通常のお手軽な手順ではできないのが残念です.

ということで,こちらでは投了です.

Apple SiliconのMac上でUTMを使ってKDE Plasma Desktopを動かしたいのであればDebian ARM64が一番いいと思います.

いちおう記念撮影.

たぶん,もう少しいじって消します.箱庭遊びなんで😓

  1. 筆者のケースではフリーズではなく,EFIのshellが起動する. ↩︎
  2. 4.7.5 ↩︎
  3. UTMの設定が一部前後します. ↩︎

プチフリーズはたぶん解決してない (2)

プチフリーズというか,Core Spotlight daemonとPagesが連携してMetadataフォルダーを肥大化させる件について,今回Geminiに聞いてみました.

そうしたら,もう1人役者がいるそうで,それはiCloudです.iCloudがPagesのファイルの編集履歴を保存することとCore Spotlight daemonの連携にバグがあって無限にインデックスを作るようです.

iCloudにApple製アプリのファイルを保存するのは具合が良いのですが,この際他の場所に置いてみることにしました.

問題になっているM4 Mac miniのローカルSSDにおいても良いのですが,Google Driveに置いた方が他のMacから編集するのに楽なのでそうしました.

まだ数時間しか経っていないので,Metadataフォルダー内のCore Spotlightのフォルサイズは130MBと常識的な範囲内です.

前回のぬか喜びを反省して,1週間くらいはこのままで運用しようと思います.

プチフリーズはたぶん解決してない

解決した,と思いましたがどうやらぬか喜びでした.昨夜,M4 Mac miniのCore Spotlightのフォルダーのサイズを見たら26GBありました.まだプチフリーズは発症していませんでしたが,その前提となるCore Spotlightのフォルダーの肥大は解決していませんでした.ということで,たぶんプチフリーズについても解決していません.

今後もしばらくは,Core Spotlightのフォルダーのサイズをときどき見て,肥大してきたら削除してリブートという運用を続けます.

プチフリーズ解決

昨年の8月に購入したM4 Mac miniでは,購入後2か月くらいしてからプチフリーズが頻発するようになりました.

など,その原因を追ってきましたが,どうやらCore SpotlightとPagesが無限にインデックスを作成することが原因である可能性が高いと結論づけました.

数日前に,Pagesの新しいバージョン1がApp Storeにあるのでダウンロードしました2.これらは,既存のPagesなどを置き換えず,新規にインストールされ,アプリケーションフォルダー内にPagesなどが2つずつ並ぶという奇妙な状況になりました.どこかに古いアプリを消しても問題ないと表示されたので削除しました.

そして新しいPagesの使用を開始して数日経ちましたが,Core Spotlightの総量は100MBあまりで,従前のPagesを使っていた頃のように数GB〜数十GBに膨れる気配はありません.Core SpotlightとPagesが連携して悪さしているうちのPages側が改良されためと思われます.

Core SpotlightとPagesが無限にインデックスを作り出し,リソースを占有することでプチフリーズが起こっていたのですがその原因がなくなったので,プチフリーズが起こることもないでしょう.

これで一安心です.これだけのためにmacOSを気に入らないTahoeにupgradeする必要がなくなり満足です.

  1. 15.1. ↩︎
  2. Numbers, Keynoteも. ↩︎