NetBSD/i386で公衆無線LANに接続

dynabook SS SX/15AにインストールしたNetBSD/i386の無線LANを使うために自宅など wpa_supplicantを使っています。SSIDとパスフレーズを記録しておけば、マシンをブートした時点で接続してくれます（ただし接続に失敗することも、よくあるので、これはこれで原因を調査して解決したいと思っていますが、将来的な課題です）。

ところが公衆無線LAN（公衆Wi-Fiとも呼ばれます） の場合、接続するためのSSIDしか公表されていないことがあります（パスフレーズを必要としない）。この場合の手順としては、指定されたSSIDに接続した後でブラウザを開くと利用規約に同意を求められ、その後利用が可能となるのが一般的です。例えばJALのサクララウンジがそうですし、スターバックスもそのようです。

この方式を用いる場合もwpa_supplicantで対応できる（「NetBSDでwpa_supplicantを使ってWEPでWi-Fi接続する場合 」）ようなのですが、うまくいきません。次の手順ならば接続できることは確認しました。

1. /etc/rc.d/wpa_supplicant stop
2. ifconfig 無線LANインターフェイス ssid 指定されたSSID -nwkey 

この方法で成功することもありますが、何度か失敗を繰り返すこともあります。スッキリと解決した訳ではないのですが、当面はなんとかなっています。もっと綺麗な解決策があるか調べたいと思っています。

「Japanese English」の和訳の一つの事例

放送大学教養学部で「英語の軌跡をたどる旅（'13）－The Adventure of Englishを読む－」を受講しています。この講義ではMelvyn Braggの『The Adventure of English: The Biography of a Language』（英語の冒険：ある言語の一生）の一部が使われています。

邦訳で「23英語の植民地化」においては「日本人は独特の日本語英語の形態を生み出した。」（340頁）とあります。ここに現れる「日本語英語」というのは、原文をあたっている訳ではないのですが、「Japanese English」を訳したものでしょう。

「Japanese English」の意図するところは、日本人が使う母語（日本語）の影響を受けた英語（表現）ということだと思います。例えば英辞郎だと「日本語訛りの［日本人風の］英語」としています。

日本人の英語を語るとき「Japanese English」という表現はよく出てくると思われます。実際に上述した文献でも出てきています。その時に英辞郎のような訳出でも構わない場合もあるでしょうけど、もっと簡潔に表現したい場合もあると思います。先の例では「日本語英語」としています。特に定まった訳語というのは無いようなので、これ以外にも様々な表現が使われます。

話は飛びますが「Japanese American」は「日系アメリカ人」という訳語が定着しています。「日本人アメリカ人」と訳されることは（ほぼ）無いでしょう。これを考えると「Japanese English」にも何か定訳が欲しいところです。

マタイ 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年前に植えた柿の樹に実がついた