Category: aarch64

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と変わらないので割愛． ↩︎

RPi5 is in charge now

約5日間に渡り，Raspberry Pi 4 Model B RAM 8GBで試験運用を続けました．

サーバー（https, samba等）としてのレスポンスは問題ありません．brute-force attackなどに対しては適度に遅いと言えるかもしれません．

GUIコンソールでFirefoxを用いてWordPressの管理や投稿・編集をするのも十分速いとは言えませんが，ストレスになるほど遅くもありません．

ということで一応の成果を見て，本来のRaspberry Pi 5 (RPi5) RAM 8GBに交代しました．

予備用にRPi5をもう一台買うべきと考えていましたが，RPi4が十分使えるので予備用の位置づけにします．来たるべきRaspberry Pi 6の発売を待ちます．

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の設定が一部前後します． ↩︎

Raspberry Pi 4しばらく登板 (3)

Raspberry Pi 4 Model B RAM 4GBでまる4日ほど運用しました．定量的なデータは何もありませんが，LAN内のクライアント1からのアクセスでは，レスポンスがSlackware ARM 32bit時よりも少し改善された感じはしました．

ただし，写真のupload時の処理時間に大差はないです2．

今回は，同じRaspberry Pi 4 Model Bですが，RAM 8GBのものに置き換えました．RAM 4GBだと定常的な運転状態でswap (ZRAM)が500MB前後になります3．8GB RAMではswapが実質的にゼロなので，差は出ると思います．

Redis Object Cacheの反応時間，最大のピークは90 ms

このRedis Object Cacheの反応時間のグラフの中央 (16:35) あたりの大きなピーク(90 ms)はハードウェア交換直後に複数のdaemonが起動したため反応時間が大きくなったと推測できます．このピークの前がRaspberry Pi 4 Model B RAM 4GB，後が同8GBです．反応時間の平均的な値は小さくなっているように見えます．

この状態でまたしばらく運用してからRaspberry Pi 5に戻します．

  1. M4 Mac mini, MacBook Air M4など． ↩︎
  2. Uploadした写真をWordPressのシステムがいくつかのサイズに作り直します．当然写真によりますがだいたい16秒前後処理時間がかかります． ↩︎
  3. ZRAMは1GBに設定しました． ↩︎

Raspberry Pi 4しばらく登板 (2)

Raspberry Pi 4 (RPi4)で運用し始めてまる2日経過しましたが，問題は特にないです．WordPressの反応もSlackware ARM (32bit)で運用していたときより速い感じがします．

Fail2Banも着実に排除するIPアドレスを増やしていってます．

また，GUIがそれなりに動くのはいいです．Firefoxが使えるので，記事を書いたり修正するのも楽です．

Slackware ARM (32bit)でもKDEが動くのですが，ちゃんと動くWebブラウザーがないのが残念なところでした．KDE自体も重かったです．

その点Raspberry Pi OSの標準であるPIXELは軽量でいいです．

RAMは4GBでちょうどいい感じです．しばらくLAN内で続けて動かしている旧サーバーはRAM 8GBで，これももったいないのでいずれ入れ替えようと思います．