roswellを使ってMacBook AirのSBCLをバージョンアップした。
ros install sbcl/1.5.3
CL-USER> (lisp-implementation-type) "SBCL" CL-USER> (lisp-implementation-version) "1.5.3"
しなくてもいいかな、と思っていたのだけど、関数へjumpする「slime-edit-definition」で微妙にソースの場所がずれる——最新版にすれば、だいじょうぶじゃね？
正解だった。
gnuplotをupgradeしたらグラフが表示されなくなってしまった。
調べてみると、AquaTermって何？ っていっている。
ああ、これはbrewでインストールしたバイナリが「–without-aquaterm」されているんだな。というわけで、brew installで「–with-aquaterm」オプションをつけようとしたら——あれ？
できない。
brew 2.0で仕様が変更されてできなくなってしまったらしい。
なんてことだ。
しかたないのでソースをもってきて——ライブラリがupgradeされてしまっていてgnuplotを元にもどしても動かなくなってしまったのだ——「–with-aquaterm」でconfigureしたのだけど……。
有効にならない。
どうやらAquaTermは未サポートになってしまったらしい。
かわりにgnuplot_qtなるものが提供されるようになっていたのだけれど。
ところがこれだと、線分の端が丸まってしまう。
なんじゃあ？
いろいろいじってなんとか、gnuplot_qtのターミナルの設定の中に線分の端を丸めるか、どうかのオプションを見つけた。
追記：いつのまにか、 --build-bottleというオプションができていた。これでコンパイルできるのかも。
ZFSはたしか、圧縮して実際に使用するディスク量を減らすことができたはず。
その設定をしようか、と思って今の状態を調べてみると。
zfs get compression
おや、どのデータセットも圧縮する設定になっている。
どのくらい圧縮されているんだろう？
$ zfs get used,logicalused zroot zfs get used,logicalused zroot NAME PROPERTY VALUE SOURCE zroot used 7.05G - zroot logicalused 13.0G - $
半分ぐらいになっていた。
そうか。それでリストアを試してみたとき、10Gを超えていたのか。
というか、これだとディスク容量を節約するために不要なファイルを圧縮しても意味がないんだな。
ふむ。
| -No- | 時刻 | 時間 | 帆走距離 | 最高速 | 平均時速 | Ｐ％ |
|---|---|---|---|---|---|---|
| 1 | 13:40-13:59 | 19分 | 2.1km | 34.74km/h | 6.70km/h | 28.63 |
| 2 | 14:03-14:13 | 10分 | 1.4km | 31.73km/h | 8.08km/h | 16.50 |
| 3 | 14:27-14:55 | 28分 | 1.5km | 23.91km/h | 3.19km/h | 0.61 |
total 57分 5.0km 5.2km/h
まぁ、やはり一番、よく使うのはgrepなわけですよ。
テキストファイルならそれでいいんだけど、Excelファイルががっつりあったりすると泣けてくる。
Windowsのエクスプローラーから検索できるんだけど、なんか使い方がよくわからないのでストレス。だったらjavaのPOIでExcelの中身を見れるんだから——ABCLで取りこめばいいんじゃね？
で、つくってみる。
あとはslime経由でEmacsにデータを取りこんでごにょごにょする、と。
ちょっと「jinput-stream」をcloseしてないのが気になるけど、ま、いいか。
| -No- | 時刻 | 時間 | 帆走距離 | 最高速 | 平均時速 | Ｐ％ |
|---|---|---|---|---|---|---|
| 1 | 10:25-10:41 | 15分 | 1.2km | 20.47km/h | 4.67km/h | 1.22 |
| 2 | 11:15-11:41 | 26分 | 2.3km | 26.60km/h | 5.14km/h | 2.82 |
| 3 | 12:48-13:00 | 12分 | 1.3km | 28.72km/h | 6.21km/h | 2.68 |
| 4 | 13:04-13:12 | 8分 | 1.2km | 31.90km/h | 8.91km/h | 29.27 |
| 5 | 13:20-13:29 | 8分 | 1.2km | 33.85km/h | 8.62km/h | 15.96 |
| 6 | 14:01-14:11 | 10分 | 0.2km | 7.95km/h | 1.09km/h | 0.00 |
| 7 | 14:36-14:45 | 9分 | 0.9km | 19.62km/h | 5.72km/h | 3.90 |
total 90分 8.2km 5.5km/h
朝起きて行くのをやめようか、と思った。
ひさしぶりすぎてなんかストレスを感じる。それでもしぶしぶ、検見川浜へ向かう。心配は青潮だった。急に暖かくなったので発生していたらどうしよう。あれはとても臭い。富津より南下すれば、だいじょうぶなことはわかっているけれど、そこまで行く根性がない。
検見川浜の海岸通りからのぞむ海は真っ白だった。
カイトが舞っている。
朝いちから海にでているセイルは二十艇近く。浜に置かれているセイルは四点台前半。途中、5.3のセイルを抱えて駐車場へもどるセイラーとすれちがう。小さいサイズにチェンジするのだろう。
うわー、どうしよう。やはり来るんじゃなかった。
4.7をセレクトして板は浮力のない255を選んだ——ところがセッティングして浜へ道具を運ぶころには風は落ち、さすがに255では無理だった。浮力のある260をあらためて持ち出したけれど、それでも風は足りなかった。
満ち潮になったらまた、風が上がる。
駐車場のあちらこちらから聞こえてくる声を聞きながら待つ。セイルをセッティングしなおすのも面倒だったのでサイズはそのまま。朝いちから出撃して満足して帰路につく人もちらほら。
一度、上がってすぐに落ちた。出艇してはまる。あやうくブロックに流されるところだった。
沖は真っ白なんだがなぁ。
5.3でも足りない風。なら5.7か。セイルを換えたとたん、吹き出して裏目を引く予感がする。そのままでも裏目を引く予感がするけれど。
12時になってようやく風が入りだした。
みんな、走り出した。
だけどぼくは走らない。何度か、プレーニングしたけれど、ウォーターできなくてはまりかけることもしばしば。だめだ〜。身体も動かないし、セイルにパワーがなくてスカる。そもそも4.7+260の組み合わせはあかん、ということを思い出した。
そこで255をひっぱりだしたのだけど、板は海底まで沈んだ。
3時をまわったところで完全に息があがってしまった。撤退。
まぁ、思いつきでリペアした4.7は使えそうだ、ということはわかっただけでもよしとすべきか。
ただ使う機会がない、ということも判明してしまったけれど。
フルバックアップをとったのはいいけれど、これってどうやったらリストアできるんだろう？
単純にzrootに「zfs receive」で流しこめば、いいか、と思ったけれど、やってみたら「/var/log」がビジーだと怒られた。よくよく考えたらzrootの中にバックアップファイルを置いているんだからまずいよな。
いくつかのサイトを参照。
こことか、ここ。
試行錯誤してすこしわかった。
まず、LiveCD1から作業をする。
バックアップファイルは別の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 デバイス名
以上、ざっくり。
FreeBSD12のインストールメディアから可能。
三日間、CPUをぶん回したらpostgresがおかしくなった。
また、アクセスできないデータブロックが発生している。これはUbuntuのときも発生したことで、最後にはSSDがreadonlyになってしまった。前回もやはり三日目ぐらいだった。
だめか。
今回はすこしちゃんと見てみる。
zpool status -v
やはりerrorがでていた。しかもバックアップからデータをもどしてね、みたいなメッセージつき。
バックアップなんてとってねーし。
postgresのデータブロックだけではなく、ほかにもいろんなファイルが壊れている模様。
——これはだめだ。
せめてバックアップをとっていれば。すっかり頭になかった。
やはりSSDでの連続運用は無理があるのかも——というわけであらためてハードディスクを持ち出してきてFreeBSD12をインストールしなおす。
今回はある程度、設定したところでバックアップをとることにした。
ZFSのことはよくわかっていないので泥縄で学ぶ。「ZFS - スナップショットいつやるか?今でしょ!」とか、これとか、これ。フルバックアップをとったあと、「zfstools」をインストールして１時間ごとにsnapshotをとるようにする1。
しかし、これでもなお、三日でおかしくなるようだったらどうしよう。
ま、今回はバックアップがあるわけだけど。
ちなみにpkgだとzfstoolsは「/usr/local/sbin」の下にインストールされていた。
コアダンプというと、やはりUNIX系の感覚があるので嫌な感じを覚えてしまう。けれど、CommonLispだとまた、ちがうらしい。コアダンプを使うと、起動が速くなる、と。
まさか。
faslを読みこむのとそんなかわらないのでは？
Raspberry PiのFreeBSDのCLISPは起動はABCLほどではないけど、やはり時間がかかる。1、2分？ プログラムのloadをあわせたらもっとだ。ダンプしたら速くなるのか？
(ext:saveinitmem "ほげほげ")
プログラムをloadした状態をdumpして。
clisp -M ほげほげ
で、起動。
驚いた。
一瞬だった。
しかもdumpした状態から作業できる1。
すげえ——でも別に実行が速くなるわけではないのだった2。
いくつかメモ
ABCLがあまりに激遅だったので、CLISPで発生したコンパイルエラーを追うことにした。
これは真面目に見れば、すぐにわかるようなたぐいのものでたぶん、バージョンのちがいに起因するものなのだろう。簡単に直せた。
これでようやくRaspberryPi上でCommonLispが動く1。
ただしThreadは未対応——これはThread対応でコンパイルをかけると、エラーになるからで、すこし追ってみたけれど、よくわからず。どうもARM64をまだサポートしていないだけのように見えるけど——わからん。
やっと何日か前にRaspbianでつくった環境に追いついた。
CLISP1上で自分の作成したプログラムを動かそうとしてみたら使っているライブラリの中でコンパイルエラーになった。あ、あかんのか。調べてみるのも面倒だし、別のCommonLispをインストールした。ABCL2。これならjava上で動くから動くだろう。
ところがこれがむちゃくちゃ遅かった。
噂で馬鹿っ遅いということは聞いていたのだけど、普通に使えていたのでだいじょうぶだと思っていた。
これはパソコンが速かっただけらしくてRaspberryPiでは耐え切れるレベルをふり切っていた。
slimeの初動で、あまりに立ち上がらないので3ひと晩、寝てしまったほどだ。
翌朝、さすがに立ち上がっていたのだけど、調べてみると、約4時間半かかっていた。
これはあれだよね。
初だから裏でビルドしているからだよね。
だから二回目は速いはず。
……10分経過……トイレにでも行ってくるか……まだか……20分……ここまで遅いと楽しくなってくる……おっ、あとはslimeとのconnectか…… ん？…… まだ？…… まだなの？……ふぅ……やっとつながった。
——使えん4。
でもThreadは使えるんだよなぁ5。
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が落ちた。な〜ぜ〜。
でも某ライブラリでコンパイルエラー。あまりに遅いので追う気力がわいてこない……。
とりあえず、手元にある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/
とりあえず、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は外の世界につながった1。そう見えるでしょう？
そうは問屋がおろさないのが世の常で。
普通、あいだのBeelink S1がパケットを中継してくれない。
中継するようにするにはBeelink S1にgateway機能を持たせる必要がある。
rc.confに
gateway_enable="YES"
と設定。
これでBeelink S1はRaspberry PiからきたパケットをWifiへ転送してくれるようになった。
だからRaspberry Piは外の世界につながった。そう思うでしょう？
そうは問屋がはおろさないのが世の常で。
今のままだと、ルーターはBeelink S1の奥にRaspberry Piがあることを知らないので、パケットの返信がとどかない。これにたいする解決策はたぶん次のうちのいずれか。
rc.confに
firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="wlan0" natd_flags=""
と設定してBeelink S1をNATサーバにした2。
これでpkgが使える。
実際、外からBeeLink S1にはいってそこからRaspberry Piにはいることはできる。
一日かかったけれど、これは深読みしすぎて嵌ったせいで、ここのとおりやったらあっさりできた。カーネルのリビルドは必要なかった。最近はたいがい、自動でカーネルモジュールを取り込んでくれているらしい。
思いつきで買ってしまったものを無駄にしたくないというのが人情というもので。
「Raspberry Pi 3 Model B+」をどうしよう。
使い道はあるのか。
——あった。
実は現役で「Raspberry Pi 3 Model B」を使っているんだけど、それを「Raspberry Pi 3 Model B+」にリプレースしてしまえば、いいじゃないか。けっこう躊躇していたのは面倒くさいな、と思っていたからだった。環境をコピーするのが手間だなぁ……と。
ところがよくよく考えたら「B」で使っているmicroSDカードを「B+」に挿せば、いいだけの話だった。
それでリプレース完了じゃないか。
完了させた。
sshのホストキーが変わってしまってすこし手間は必要だったけれど、ちょっぴり速くなった(と思いたい)。
さて。
残された「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が使えないのは痛い1。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で接続しようとする前にローカルでログインしないといけないじゃないか。
使えん2。
あまりに魅力を感じなかったので、起動直後に接続へいくような設定を探す気にもなれなかった。
ああ、やはり「RaspberryPi B+」は積読になってしまうのか。
ためしにハードディスクに換えてみようと、Beelink S1の筐体をあけた。
SSDがものすごく熱くなっていた。
もともとBeelink S1には冷却ファンがついていないし(たぶん)、筐体の密閉度も高い。熱くなりやすい構造なのだけど、CPUの発熱のせいだけではなく、もしかすると、SSD自体がけっこう発熱していたのかもしれない。そんな熱さだった。
これはハードディスクにしたくらいでだいじょうぶ、というものじゃないな。
/sbin/sysctl hw.acpi.thermal.tz0.temperature
で、チェックしてみてもあっさり50度越えしている。
これはやはり冷却ファンをつけるしか、ないか。
というわけで装備した。
そういえば 「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/")
ふむ。だじょうぶそうだ。
RaspberryPi B+にはFreeBSD12をいれるつもりだった。
しかし、動かない。
bootすらしない(後日、全然、動くことが判明した1)。
あかんわー。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前提じゃなかったっけ。マルチに動かすために。
しまった、だめじゃないか2。
不思議なのだけど、Ubuntuだと、バックグランドで動いているpostgresはひとつのプロセスにひとつのCPUが割り当てられているようだった。実際、threadひとつのときは、システムモニタで見ると、ひとつのCPUだけががっつり使われていた——なのに、FreeBSDだとそれが、分散されているように見える。全体的にCPUが使用されている。
topコマンドで見ても時々、使うCPUが他のものに切り替わっていた。
これはLinuxとFreeBSDのちがいなのか、それとも用意されているバイナリのposrgresのコンパイルオプションのちがいなのか——。