フルバックアップからのリストア

　フルバックアップをとったのはいいけれど、これってどうやったらリストアできるんだろう？
　単純にzrootに「zfs receive」で流しこめば、いいか、と思ったけれど、やってみたら「/var/log」がビジーだと怒られた。よくよく考えたらzrootの中にバックアップファイルを置いているんだからまずいよな。
　いくつかのサイトを参照。
　こことか、ここ。
　試行錯誤してすこしわかった。
　まず、LiveCD¹から作業をする。
　バックアップファイルは別のUSBデバイスなりに、ZFSでいれておく(別にマウントできるならUFSでもいいような気はする)

zpool import -f POOL名

　で、バックアップファイルの入ったpoolを認識させて

zfs set mountpoint=PATH名 POOL名
zfs mount zbackup

　マウント。

zfs receive -vdF zroot < バックアップファイル

　で流しこむ。
　とりあえず、zrootを認識させるためにimportする必要があった。
　強引につくりなおしてもいけるような気がする。

zpool create -f zroot デバイス名

　以上、ざっくり。

Footnotes:

¹

FreeBSD12のインストールメディアから可能。

熱暴走その後のその後

　三日間、CPUをぶん回したらpostgresがおかしくなった。
　また、アクセスできないデータブロックが発生している。これはUbuntuのときも発生したことで、最後にはSSDがreadonlyになってしまった。前回もやはり三日目ぐらいだった。
　だめか。
　今回はすこしちゃんと見てみる。

zpool status -v

　やはりerrorがでていた。しかもバックアップからデータをもどしてね、みたいなメッセージつき。
　バックアップなんてとってねーし。
　postgresのデータブロックだけではなく、ほかにもいろんなファイルが壊れている模様。
　——これはだめだ。
　せめてバックアップをとっていれば。すっかり頭になかった。

　やはりSSDでの連続運用は無理があるのかも——というわけであらためてハードディスクを持ち出してきてFreeBSD12をインストールしなおす。
　今回はある程度、設定したところでバックアップをとることにした。
　ZFSのことはよくわかっていないので泥縄で学ぶ。「ZFS - スナップショットいつやるか?今でしょ!」とか、これとか、これ。フルバックアップをとったあと、「zfstools」をインストールして１時間ごとにsnapshotをとるようにする¹。

　しかし、これでもなお、三日でおかしくなるようだったらどうしよう。
　ま、今回はバックアップがあるわけだけど。

Footnotes:

¹

ちなみにpkgだとzfstoolsは「/usr/local/sbin」の下にインストールされていた。

コアダンプ

　コアダンプというと、やはりUNIX系の感覚があるので嫌な感じを覚えてしまう。けれど、CommonLispだとまた、ちがうらしい。コアダンプを使うと、起動が速くなる、と。
　まさか。
　faslを読みこむのとそんなかわらないのでは？
　Raspberry PiのFreeBSDのCLISPは起動はABCLほどではないけど、やはり時間がかかる。1、2分？ プログラムのloadをあわせたらもっとだ。ダンプしたら速くなるのか？

(ext:saveinitmem "ほげほげ")

　プログラムをloadした状態をdumpして。

clisp -M ほげほげ

　で、起動。
　驚いた。
　一瞬だった。
　しかもdumpした状態から作業できる¹。
　すげえ——でも別に実行が速くなるわけではないのだった²。

Footnotes:

¹

もっともslimeとの接続はうまくできなかった。

²

同じことをMacのSBCLでやろうとしたけど、dumpできなかった。どうもthreadがあるとだめらしい。

FreeBSD12 on RaspberrPi 3 Model B

　いくつかメモ

1. FreeBSD12はimageをまちがわなければ、RaspberryPiで動く。
   
2. しかも64bit対応。
   
3. ただし、オンボードのWifiは認識しないので有線LANが必要。
   
4. pkgはそろっている(Emacs、PostgreSQLなど)。
   
5. CommonLisp系はABCLのみ(つまりjavaは動く)。
   
6. ただしportからCLISPがインストール可能(Threadはまだ未対応)。
   そのときはgccをあらかじめ、pkgからインストールしておくこと。
   
7. ntpを設定しておかないと時間は狂いっぱなし。
   
8. swapは設定されていないので設定する。
   
9. CPUの温度の取得は「/sbin/sysctl dev.cpu.0.temperature」
   

CLISP on RaspberryPi

　ABCLがあまりに激遅だったので、CLISPで発生したコンパイルエラーを追うことにした。
　これは真面目に見れば、すぐにわかるようなたぐいのものでたぶん、バージョンのちがいに起因するものなのだろう。簡単に直せた。
　これでようやくRaspberryPi上でCommonLispが動く¹。
　ただしThreadは未対応——これはThread対応でコンパイルをかけると、エラーになるからで、すこし追ってみたけれど、よくわからず。どうもARM64をまだサポートしていないだけのように見えるけど——わからん。

Footnotes:

¹

やっと何日か前にRaspbianでつくった環境に追いついた。

ABCL on RaspberryPi

　CLISP¹上で自分の作成したプログラムを動かそうとしてみたら使っているライブラリの中でコンパイルエラーになった。あ、あかんのか。調べてみるのも面倒だし、別のCommonLispをインストールした。ABCL²。これならjava上で動くから動くだろう。
　ところがこれがむちゃくちゃ遅かった。
　噂で馬鹿っ遅いということは聞いていたのだけど、普通に使えていたのでだいじょうぶだと思っていた。
　これはパソコンが速かっただけらしくてRaspberryPiでは耐え切れるレベルをふり切っていた。
　slimeの初動で、あまりに立ち上がらないので³ひと晩、寝てしまったほどだ。
　翌朝、さすがに立ち上がっていたのだけど、調べてみると、約4時間半かかっていた。
　これはあれだよね。
　初だから裏でビルドしているからだよね。
　だから二回目は速いはず。
　……10分経過……トイレにでも行ってくるか……まだか……20分……ここまで遅いと楽しくなってくる……おっ、あとはslimeとのconnectか…… ん？…… まだ？…… まだなの？……ふぅ……やっとつながった。
　——使えん⁴。

　でもThreadは使えるんだよなぁ⁵。

Footnotes:

¹

pkgにはなかったけれど、portコレクションにはあったのでビルドした。SBCLはだめだった。

===>  sbcl-1.5.0,1 is only for amd64 i386, while you are running aarch64.

²

CMUCLも、SBCLもインストールできなかった。SBCLなどソースをもってきてコンパイルまで試したのに。

³

横でtopコマンドで動きを見てなかったらCtrl-Cを連打していたレベル。

⁴

どこまで遅いのか、自前のプログラムをloadしてみていたらEmacsが落ちた。な〜ぜ〜。

⁵

でも某ライブラリでコンパイルエラー。あまりに遅いので追う気力がわいてこない……。

多段ssh(うまくいかなかった)

　とりあえず、手元にあるMacBook AirからRaspberryPiで何かするにはBeelink S1を踏み台にしてRaspberryPiに入る必要がある。

　たいした手間でもないし、ま、いいか、と思っていたのだけど、「ssh -Y」でいけんじゃね？
　と思って。

ssh -Y ほげほげ 'ssh -Y ほげほげ２ emacs'

　ってやったらほげほげ２のemacsをMacBook AirのＸ上に表示できた。
　すばらしい。

　調べてみると、多段sshという方法があるらしいのだけど、こちらはうまくいかなかった。何かミスっているのか、環境的にできないのか。

ssh_exchange_identification: Connection closed by remote host

　ま、「ssh -Y」はうまくいっているし。モチベーション低し。Beelink S1のsshdあたりの設定かな、とは思うのだけれど。
　さらにEmacsのtrampでもあっさりアクセスできたし。

/ssh:ほげほげ|ssh:ほげほげ２:/home/yamada/

Raspberry Piを有線LANにつなぐ

　とりあえず、FreeBSD12をRaspberry Piにインストールした。

% uname -a
FreeBSD ほげほげ 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  arm64

　スタンドアローンで触っていてはた、と手が止まる。pkgをいれるにしてもネット環境につながってない。オンボードのwifiが使えない以上、手も足もでない。
　かあさん、ぼくのあの、BUFFALO WLI-UC-GN2はどこへいってしまったんでしょうね……。
　昨今の10BASE-Tはクロスケーブルにしなくても接続可能なので有線でBeelink S1につなぐことはできる。
　そして、Beelink S1はwifiを経由して外の世界とつながっている。
　つまりこういう感じになるわけだけど。

　これでRaspberry Piは外の世界につながった¹。そう見えるでしょう？
　そうは問屋がおろさないのが世の常で。
　普通、あいだのBeelink S1がパケットを中継してくれない。
　中継するようにするにはBeelink S1にgateway機能を持たせる必要がある。
　rc.confに

gateway_enable="YES"

　と設定。
　これでBeelink S1はRaspberry PiからきたパケットをWifiへ転送してくれるようになった。
　だからRaspberry Piは外の世界につながった。そう思うでしょう？
　そうは問屋がはおろさないのが世の常で。
　今のままだと、ルーターはBeelink S1の奥にRaspberry Piがあることを知らないので、パケットの返信がとどかない。これにたいする解決策はたぶん次のうちのいずれか。

1. ルーティングテーブルの設定(ルーター、Beelink S1)
   
2. Beelink S1をプロキシサーバにする
   
3. Beelink S1をNATサーバにする
   
4. Beelink S1にブリッジを設定(ルーティングの設定も必要？)
   

　rc.confに

firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="wlan0"
natd_flags=""

　と設定してBeelink S1をNATサーバにした²。
　これでpkgが使える。

Footnotes:

¹

実際、外からBeeLink S1にはいってそこからRaspberry Piにはいることはできる。

²

一日かかったけれど、これは深読みしすぎて嵌ったせいで、ここのとおりやったらあっさりできた。カーネルのリビルドは必要なかった。最近はたいがい、自動でカーネルモジュールを取り込んでくれているらしい。

Raspberry Pi 3 Model B+その後のその後

　思いつきで買ってしまったものを無駄にしたくないというのが人情というもので。
　「Raspberry Pi 3 Model B+」をどうしよう。
　使い道はあるのか。
　——あった。
　実は現役で「Raspberry Pi 3 Model B」を使っているんだけど、それを「Raspberry Pi 3 Model B+」にリプレースしてしまえば、いいじゃないか。けっこう躊躇していたのは面倒くさいな、と思っていたからだった。環境をコピーするのが手間だなぁ……と。
　ところがよくよく考えたら「B」で使っているmicroSDカードを「B+」に挿せば、いいだけの話だった。
　それでリプレース完了じゃないか。
　完了させた。
　sshのホストキーが変わってしまってすこし手間は必要だったけれど、ちょっぴり速くなった(と思いたい)。

　さて。
　残された「Raspberry Pi 3 Model B」はどうしよう……。

Raspberry Pi 3 Model B+その後

　Raspbianもいれた。さて何をしようか。
　postgresもある。Emacsもはいっているし、SBCLもインストール済みだ。でもB+とはいえ、やはりBeelink S1にくらべれば、おそい。そのうえ、SBCLはThread未対応。マルチプロセスではメモリが１ＧしかないRaspberryPiではきびしい。
　なにしろシステムモニターを動かしているだけで半分ぐらいCPUを喰らってしまうのだから。
　まぁ、そのうち、何か思いつくかも——ってあれ？

　32bit？
　たしか、ARMv7は64bitでは？
　よくよく調べてみると、公開されているRaspbianは32bit版なのだった。
　まぁ、たしかにメモリが32bitで使い切れないほど、積まれているわけじゃないからほとんど、かわらないとは思うけど。なんか、嫌。
　やはりせっかくなんだし、64bitOSにしたいじゃないか。
　Raspbianを64bitにするのは面倒そうだった。
　試しにFreeBSDをいれてみると、こちらは64bit対応されているけれど、やはりオンボードのwifiが使えないのは痛い¹。XOrgが動くようになっているらしいのだが。早々候補から落ちてしまうことに。
　やはりLinux系しか、なさそうだった。
　Ubuntuもあるけれど、64bitはサーバだけらしい。これ、wifiを使うにはどうすれば、いいんだろう？
　ググった情報からは有線LANが前提っぽい。
　たどりついたのが。
　openSUSEというディストリビューション。
　いくつかのデスクトップ環境がバンドルされたバイナリがそれぞれ用意されている。64bit。ひとつずつ試してみる。さすがに「KDE - KDE desktop」は最初から埒外。重すぎて使えないだろう。「LXQT - LXQT desktop」は重すぎた。使えない。「E20 - Enlightenment desktop」は見た目が……。で、結局、以前、使っていたことがある「XFCE - XFCE desktop」を選択。やや重いが、wifiも使えるし、VNCの接続方法もわかった。sshで裏から入ることもできる。最悪、軽いX環境を使うことも可能のようだった。でも何か、嫌な感じ。好きじゃないな、これ。Xfce自体は好きなのだが、パッケージの管理の仕方とか。何これ。インストールされたの？ されてないの？ わからん。
　馴れかな、と我慢していると、boot直後、wifiに接続してくれてないことが判明。どうやら外へのパケットが発生したとき、はじめて接続にいく仕組みらしい。昔のPPPかよ。
　それだと、VNCで接続しようとする前にローカルでログインしないといけないじゃないか。
　使えん²。
　あまりに魅力を感じなかったので、起動直後に接続へいくような設定を探す気にもなれなかった。

　ああ、やはり「RaspberryPi B+」は積読になってしまうのか。

Footnotes:

¹

うちの環境に有線LANはない。

²

あくまでぼくの環境では。

熱暴走その後

　ためしにハードディスクに換えてみようと、Beelink S1の筐体をあけた。
　SSDがものすごく熱くなっていた。
　もともとBeelink S1には冷却ファンがついていないし(たぶん)、筐体の密閉度も高い。熱くなりやすい構造なのだけど、CPUの発熱のせいだけではなく、もしかすると、SSD自体がけっこう発熱していたのかもしれない。そんな熱さだった。
　これはハードディスクにしたくらいでだいじょうぶ、というものじゃないな。

/sbin/sysctl hw.acpi.thermal.tz0.temperature

　で、チェックしてみてもあっさり50度越えしている。
　これはやはり冷却ファンをつけるしか、ないか。
　というわけで装備した。

HyperSpecをFreeBSDで

　そういえば 「HyperSpec」もpkgにあったので。

sudo pkg install clisp-hyperspec-7.0

　で、インストール。
　インストール先は

pkg list clisp-hyperspec-7.0

　で、確認してemacsのinit.elに定義した。

(setq common-lisp-hyperspec-root "file:/usr/local/share/doc/clisp-hyperspec/HyperSpec/")

　ふむ。だじょうぶそうだ。

Raspberry Pi 3 Model B+の設定

　RaspberryPi B+にはFreeBSD12をいれるつもりだった。
　しかし、動かない。
　bootすらしない(後日、全然、動くことが判明した¹)。
　あかんわー。Ubuntuもあったけど、ちょっとかったるそうだ。というわけで、先代と同じくRaspbianをインストールした。しまった。区別がつかない。せめてケースのカラーリングぐらい別にすべきだった。
　あたりまえのように動く。あたりまえだけど。
　それにしてもこの軽いOS、RaspberryPi以外でもけっこういいかもしれない。
　と、思ったらちゃんと「Raspberry Pi Desktop」というのがあった。

　インストール後、パッケージをコツコツといれていく。
　Debianのパッケージシステム。apt。
　Emacs、postgres——SBCLもあった。1.3.7-1。EmacsのライブラリはRaspbianのパッケージからではなく、Emacs自身のパッケージシステムから。
　SBCLの環境はFreeBSDと同様、quicklispからいれる。
　ちょっととした気の迷いでaptからASDFをいれたのだけど、何かうまく動かせず——というか、SBCLには1.5.1のときのようにASDFが同梱されてなかった——、削除してまず、quicklispをいれたらいっしょについてきた。あ、そうなんだ。
　「~/.sbclrc」に(require :asdf)を追加した以外はほぼ、FreeBSDのときと同じ。
　ところが、このSBCL、threadをサポートしてなくて「make-thread」で落ちる。
　くそおっ。
　SBCLのgithubからソースをもってきてビルドする。
　手順はほぼ、INSTALLというファイルに書いていた通り。ソースからビルドする場合はあらかじめ、CommonLispが必要だという。おもしろい。ところがINSTALLを読んでいたら不吉な一文が。

Native threads. Enabled by default on x86[-64] Linux only, also
available on x86[-64] Max OS X, x86[-64] FreeBSD, x86 Solaris,
and PPC Linux.

　あかんかも。
　何度か試してみたけれど、結局、Threadをサポートした状態にできず。
　自前のプログラムはthread前提じゃなかったっけ。マルチに動かすために。
　しまった、だめじゃないか²。

Footnotes:

¹

これはこちらのミスで後日、動くことを確認した——けれど、オンボードのwifiを認識してくれず。

²

javaがあるみたいだからABCLならthreeadがサポートされるかもしれない。

CPU割り当て

　不思議なのだけど、Ubuntuだと、バックグランドで動いているpostgresはひとつのプロセスにひとつのCPUが割り当てられているようだった。実際、threadひとつのときは、システムモニタで見ると、ひとつのCPUだけががっつり使われていた——なのに、FreeBSDだとそれが、分散されているように見える。全体的にCPUが使用されている。
　topコマンドで見ても時々、使うCPUが他のものに切り替わっていた。
　これはLinuxとFreeBSDのちがいなのか、それとも用意されているバイナリのposrgresのコンパイルオプションのちがいなのか——。

Threadプログラミングはむずかしい

　Threadごとにconnectionを管理できるようにしたからだいじょうだと思っていた。たしかにThread二つまでは何ともなかった。それを四つにしたらおかしくなった。
　いきなりPREPAREがすでに使われている、とエラーになる。
　——？
　どうして二つで動いていたものが、四つだと動かなくなる？
　しかもすぐに起きることもあれば、しばらくたってから起きることもある。同じ処理をくりかえしているにもかかわらず。
　三日、考えこんだ。
　使っているライブラリも疑った。
　どうデバックすれば、いいかも思いつかない。タイミングで発生しているのはあきらかで——それを補足するのはどうすれば、いいのだろう。ソース百遍。
　三日目にしてようやく気づいた。
　threadごとに管理しているconnectionはハッシュテーブルを使っている。
　同時にこのハッシュテーブルにアクセスされたらどうなるんだろう？
　あっ、まずいかもしれない。
　ハッシュテーブルがthreadセーフなら別だが——。
　どうやれば、それがわかるのか、わからなかったのでとりあえず対処した。
　「with-lock-held」で処理を排他¹。
　それでエラーはいちおう起きなくなったように見えた。が、それは頻度が極端に減っただけで起きるときには起きる。あれ？
　これがわからない。謎だ。
　同じPREPAREがすでに使われているというエラーなのだが——たぶんthreadセーフじゃないところがまだ、どこかに残っているのだろう。あるいは使っているライブラリかもしれない。むずかしい。
　これを避ける方法にはsqlを発行しているところをハッシュテーブルのときのように排他処理をかければ、いいのだが……それだと並列処理の意味がなくなってしまう。
　threadひとつだけの場合とかわらないからだ。
　まったくthreadで動くようにしたらthreadにした意味自体がなくなってしまう、という……。
　なんて厄介な²。

Footnotes:

¹

中身はMUTEXを使っていた。

²

最終的にはエラーが起きているPREPAREを生成している関数だけを「with-lock-held」で整流化してなんとかなった。今のところ、エラーは起きていない。ただしそこで待ちがはいるため、CPUの使用率は全体として80％をこえなくなった。それでもthread一個並みになるより全然ましだけど。

Raspberry Pi 3 Model B+

　また、RaspberryPiを買ってしまった。
　別に現役のRaspberryPiがお亡くなりになったわけじゃないのだけど。
　Beelink S1が熱くなっているのでRaspberryPiの方がましかもしれない、と思ったのだ。CISCよりRISCチップの方が発熱しないという話をどこかで読んだことがある。なので。
　ところがAmazonで同じ値段だったので「Raspberry Pi 3 Model B」ではなく、「Raspberry Pi 3 Model B+」を注文してしまった。そのあと、調べてみると、「Raspberry Pi 3 Model B+」の方が消費電力は大きく——もちろんそれで発熱も大きくなるだろうし——、そもそも電源はちゃんと対応しているものが必要……。
　えっ？
　iPhoneのは使えないの？

　頭を抱えていたらもともと「B」でもiPhone用のではアンペア不足らしい。使えるのは使えるらしいが。ということは「B」のときにいっしょに買った電源はどうなんだ？ 調べてみたら3Aあって「B+」に使えることが判明した。
　使ってなかったのでこれ幸い。
　ほっとした。

　それにしてもmicroSDカード、安くなったなぁ。
　へたなハードディスクよりお得かもしれない。
　よくよく考えたらBeelink S1をMaicroSDカードから使えば、よかったんじゃね……RaspberryPiなんて必要なかったんじゃね……。

ASDF on FreeBSD

　SBCLは使えるようになったのだけど、立ち上げるときにWarningがでているのが気になってしかったなかった。しかもどうもASDFがらみ。
　英語なのでわかりませ〜ん。
　とばかりいってもいられないのでGoogle翻訳の片言日本語で読んでみた。

　なんか、ASDFがインストールされているけど、そっちは使わないよ、古かったりするからね、管理者権限があるなら削除した方がいいよ、ちなみに「~/.config/common-lisp/source-registry.conf 」は使えないよ……。

　って書いているような気がする。
　なんか、状況は一致するな。
　でもそもそもASDFを入れた覚えはないんだけど？
　ところが、調べてみたらインストールされていた。どうやらSBCLをインストールしたとき、いっしょに入ったらしい。その証拠に「pkg-delete」しようとしたら「SBCL」までいっしょに削除しようとする。
　おいおい。

　まぁ、実害はなさそうだ。
　いちおうpkgで入ったASDFをいじって見えなくしたらWarningはでなくなったし。解釈はまちがいなさそうだ。Warningは無視する方向にしよう。

　もしかしたらSBCLは独自のPATH構成にしているのかもしれない。それでSBCL対応のパッケージがいちいち、pkgに用意されているのかも。

FreeBSDでCommonLisp

　果たしてroswellにたよらずにやっていけるだろうか。
　なにはともあれ今まで何度も読み返していた「require, ASDF, quicklispを正しく使う」をふたたび、読み返す。いまいち、理解していないんだよなぁ、このあたりの話。roswellにたよってしまっていたのでなおのこと。
　とりあえず、FreeBSD環境にSBCLをインストールした。

sudo pkg install sbcl

　pkgにはほかにも「alexandria」とか、「asdf」とか、もろもろの他、SBCLのパッチがあたっているとおぼしき、バージョンもある。これを使うべきか？
　迷いつつ、SBCLをslimeで使えるように設定して。

(setq inferior-lisp-program "/usr/local/bin/sbcl --noinform")

　立ち上げてみたら「asdf」なんたらの文字が見えた。
　そうか。SBCLの中にasdfが内蔵されているのか。そういえば、ABCLもそうだった。それならpkgでASDFをインストールすることもないか。
　ところがいくらやってみても「~/.config/common-lisp/source-registry.conf 」に定義した内容がcommonlispに反映されない。試行錯誤すること数時間。
　あかんわー。
　自分のミスとは思えない。もしかしたらSBCL内蔵のASDFは「~/.config/common-lisp/source-registry.conf 」は無効になっているのかもしれない。じゃ、どうやって設定すれば、いいんだ？
　「quicklisp¹」でもってきたライブラリの場所を認識させたいんだけど²？
　つらつら考えて「~/.sbclrc」に設定した。

(asdf::initialize-source-registry
        '(:source-registry
          (:tree "~/quicklisp/dists/") :INHERIT-CONFIGURATION))

　「asdf:find-system」で設定が有効になっていることを確認。
　よし。
　でもREPLで「ql:quickload」が使えないのは不便なので「~/.sbclrc」にさらに設定を追加した。

(load #P"~/quicklisp/setup.lisp")

　あれ、これでroswellからのREPLとほぼ、同じになったんじゃね？
　すくなくともぼくが使うかぎりにおいて。

Footnotes:

¹

「quicklisp」はpkgになかったのでhttps://www.quicklisp.org/beta/からもってきて自前でインストール。

²

「~/common-lisp」の下は認識されているから自前のLispはここへ置けば、いいんだけど。

熱暴走

　CPUをぶんぶん回していると、当たり前だけど、熱くなる。
　簡単に水冷化したけれど、これは効果がなかったようで。

　もしかしたらUbuntuがおかしくなったのはそのせいかもしれない。
　昔はそんな経験はあまりしなかったような？
　そういえば、SSD換装をするようになってからのような気がする。
　ありうることだ。
　昔はハードディスクのアクセスがボトルネックになってCPUの発熱が自然と抑えられていた。そういうことかもしれない。今は抑えがなくなってCPUがまじで熱くなっているもかもしれない。
　それならやばいんじゃないか。
　普通のノートパソコンやミニパソコンでぶんぶんCPUを回すというのは。

　Beelink S1はハードディスクにすべきだろうか。
　さて。

XQuartz後日談

　XQuartzにアプリケーションを登録すると、MacBook AirからBeelink S1の「emacs -damon」を起動できる。
　これはよかった。「emacs -daemon」はXQuartzを終了させてもBeelink S1で立ち上がりつづけるからだ。Emacsが一種のサーバになる。これに接続するには「emacsclient」を使うのだけれど、「ssh -Y ほげほげ emacsclient -c」でこれはＯＫ。XQuartzにEmacsが表示される。
　実体は「emacs -daemon」なのでそれまで編集していたバッファとかがそのまま、残されている——なのだけれど、どうやらＸサーバに接続する「-c」オプションはemacsclientを終わらせてもＸサーバに接続されたままらしい。Ｘサーバ(XQuartz)を終了させると、「emacs -daemon」がcoreを吐いて落ちてしまう¹。
　これがターミナル上に表示される「-nw」オプションだと、emacsclientを終了させてもdaemonは動きつづけているし(ここまでは「-c」オプションのときと同じ)、ターミナルを終了させてもだいじょうだ(ここがちがう)。もちろんMacBook Airを終了させてもＯＫだ。
　ふむ。
　しかたないのでワンクッションいれることにした。
　「ssh -Y ほげほげ」でBeelink S1からターミナル²を立ち上げ、その中で「emacsclient -nw」を立ち上げる。これでEmacs自体はＸに接続していないのでdaemonごとお亡くなりにならないだろう。Beelink S1のターミナルならcommandキーをmetaキーと認識できる。ただしクリップボードの共有はできないけれど。
　まぁ、これはしかたないか。
　アプリケーションには次のように登録した。

ssh -Y ほげほげ lxterminal -e emacsclient -nw

　これでemacsclientまで一気に起動される。当たり前だが、起動はやたら速い。

Footnotes:

¹

coreを吐いているということはBUGかもしれない。emacs26。

²

最終的にLXTerminalを使うことにした。