マタイ 7:13-14

「狭い門から入りなさい。滅びに通じる門は広く、その道も広々として、そこから入る者が多い。しかし、命に通じる門はなんと狭く、その道も細いことか。それを見いだす者は少ない。」

Firefox Quantum

Webを閲覧するためにFirefoxを利用していますが、先日新しい更新が出ているという通知が出てきました。更新を適用したところFirefox 57.0になりました。Firefox Qutantumと呼ぶことになったようです。画面の構成も変わりましたし、内部的にも大きく変更されているようです。

ところが、これまで利用していたアドオンが使えなくなってしまいました。日々の作業の根幹に関わる機能なので、ちょっと困っています。

1. iMacros
2. It's All Text!
3. TiddlyWiki for Firefox

これらのアドオンがFirefox Quantumにも対応してくれるのを待つか、代替アドオンを探すことになるでしょう。

CANNAの終焉

自宅には365x24電源を落とさないで利用しているノートPCがあります。ハードウェアは昔々のGateway製でCPUはPentium III 450MHzです。旧いCPUですが、CPUの演算性能に依存するようなことはしていないので、別に不満はありませんでした。OSはFreeBSD/i386 10.3を利用しています。

ところが旧過ぎるマシンだとOSやアプリケーションを最新化できなくなってきました。例えばOSのカーネルをFreeBSD/i386 11に変更するとブート時にpanicしてしまいます。またportsでインストールしているアプリケーションを更新しようとすると、コンパイル中にSSE2が使えないというエラーが出てしまうようになってきました。そろそろマシンを更新する潮時かもしれません。ジャンクでLenovo ThinkPad Edge 530cを購入しFreeBSD/amd64の環境を構築し、FreeBSD/i386の環境を移行することにしました。

以前はportsを自前でコンパイルしていたのですが、オプションをデフォルトから変更することは滅多にないし、コンパイルする時間もかかるので、今後はコンパイル済のパッケージを使おうと思っています。FreeBSD/i386において使っていたパッケージをFreeBSD/amd64でもインストールしておきました。

ここで気になったのがemacsです。以前は自前で漢字変換が出来るようにするためCANNAオプションを有効にしていました。ところがコンパイル済のパッケージでは（予想はしていましたが） CANNAオプションが無効になっています。

emacs25-25.3_1,3
Name           : emacs25
Version        : 25.3_1,3
Installed on   : Tue Nov 14 13:27:37 2017 JST
Origin         : editors/emacs
Architecture   : FreeBSD:11:amd64
Prefix         : /usr/local
Categories     : editors ipv6
Licenses       : GPLv3+
Maintainer     : ashish@FreeBSD.org
WWW            : http://www.gnu.org/software/emacs/
Comment        : GNU editing macros
Options        :
        ACL            : on
        ALSA           : off
        CAIRO          : off
        CANNA          : off
（以下略）

CANNAオプションを有効にしてコンパイルすることも可能であることは承知しています。しかしCANNA自体が過去のものですし、Windows上で端末エミュレータを利用していることを考えれば、日本語変換はWindowsに任せても構わないような気がしています。

muleの頃からemacsではCANNAを利用してきましたが、どうやらCANNAの時代は終焉を迎えているようです。

Windows10とNetBSDの同期にforfiles.exeとcpioを使う

Windows Vistaがインストールされていたdynabook SS SX/15AをNetBSD/i386に入れ換えて使用しています。まだOSがVistaだった頃から、Windows10が入っているデスクトップPCの%HOMEPATH%\Documents以下をdynabook側にコピーして、外出先でも自宅のPCと（ほぼ同じ）ファイルが参照できるようにしていました。当時はお互いにWindows PCですから、ネットワークドライブとして繋げば、あまり苦労もせずにファイル同期が可能でした。

OSをNetBSDに置き換えたことで、Windows10側のファイルを如何にしてNetBSD側に持ってくれば良いのか方式を検討することになりました。考え方としては、Windows10側を動作主体にしてNetBSD側にファイルを送り付けるか、NetBSD側を動作主体としてWindows10側からファイルを引き込むか、いずれの方式にするか考えなければなりません。OSの標準的な機能だけを使って実現しようとすると、NetBSD側を動作主体にして、NetBSD側からWindows10側のディレクトリをリモートマウントすることで、処理を全てNetBSD側でおこなう方式にしました。

まず最初に試したのは、NetBSD側でmount_smbfsを使ってWindows10側の%HOMEPATH%\Documentsをマウントし、rsyncで同期させることでした。しかし試してみると、ネットワークが切れたり、途中で処理が固まったり（情報が出ていないので何が問題なのか分からない）、上手くいきません。

次に考えた方式は、NetBSD側でrump_smbfsを使いファイル名の文字コード変換をさせてWindows10側の%HOMEPATH%\Documentsをマウントし、 tarでファイルをコピーしてみました。ひとまず問題なく全てのファイルをコピーすることができました。しかし処理速度が異常に遅く、ほぼ24時間かかってしまいました。いくらなんでも遅すぎますし、CPUは99%程度はアイドル状態です。NetBSD側が動作の処理を主導して、Windows10側のディレクトリを検索しようという発想が良くなかったのかもしれません。

次に考えた方式では、発想を転換して、Windows10側とNetBSD側の処理を分離することにしました。Windows10側では、指定日付以降に作成されたり変更されたりしたファイルのリストを作成しておきます。そしてNetBSD側では、そのファイルを参照してファイルを転送するだけの処理にしました。

ここで問題になるのは「指定日付以降に作成されたり変更されたりしたファイルのリスト」をどのようにして作成すれば良いかということです。U*IXであればfindを使えばなんとかなるのですが、Windows10ではどうすれば良いのでしょうか。もしかするとPowerShellでロジックを組めば対応できるのかもしれませんが、PowerShellを使ったことがないので他の方法を探してみました。Webを検索したところforfiles.exeというものがあるようです。なんと指定した日付以降のファイルリストを生成することができました。何時の間にこんなコマンドがWindowsに入っていたのか知りませんでしたが、ありがたいことです。

またNetBSD側ではファイル転送をおこなうだけなので、cpを使えば良いかと思いましたが、ちょっと問題がありそうです。最初にWindows10側のファイルを全てコピーする場合には問題になりませんが、2回目以降に一部のファイルだけをコピーしようとすると転送先ファイルのディレクトリが無い可能性を想定しなければなりません。スクリプトをちょっと工夫してmkdirしてからcpするようにしても良いのですが、cpioを使ってみました。cpioの存在は昔から知っていましたが、普段はtarを利用するのでcpioを利用したことがありませんでした。アーカイブファイルを作るだけではなく、ファイル転送にも利用できるようですし、転送先にディレクトリが必要なら作ってくれるオプションもあります。

最後の方式でWindows10側（%HOMEPATH%\Documents）→NetBSD側（$HOME/Documents）にファイル同期させることが出来るようになりました。

2年前に植えた柿の樹に実がついた