2016/12/31

英文を書くための発想

英語を勉強するときに難しいのはアウトプットの訓練です。日本人が英文を組み立てる場合、英単語の知識と、英文法規則を学んでいれば、英文を作り出すことができるはずです。しかしそれだけで良いのでしょうか。英単語を英文法規則に従って並べれば英文らしきものにはなると思いますが、自然な英文になるとは限らないと思います。

例えば、日本語では修飾語が前に置かれる傾向にあるのに、英語では後に続くことが多いという発想の違いがあります。これくらいなら発想云々という事を言わなくても、英文法規則に従えば自動的に正しく英単語が並ぶはずです。

しかし英語らしい発想の仕方というものがあるようです。ジャパンタイムズ発行の「週刊ST」 (2012年4月6日号)に掲載された「English across Cultures」(本名 信行)には次のようなことが書かれています。
一つの例を挙げましょう。ある会合に出席する予定だった人が来ていなかったとします。後日、その人に尋ねるとき、日本人は「私はあの会合に行きましたが、あなたはどうして来なかったのですか」と言います。これを英語にすると、"I went to the meeting.  Why didn't you come?"となります。ところが、ネイティブスピーカーは、こういう状況では、"I was there.  Where were you?"というような言い方をします。同じ状況を、ネイティブスピーカーは動きではなく、存在としてとらえるのです。
日本語の発想を英文にしても、英文法的には間違っていないにもかかわらず、英語の発想からなる英文とは異なるようなのです。

英語に限らず、どんな言語でも、その言語を使うネイティブスピーカーの発想は言語に影響されています。つまり日本人の発想は日本語に影響されているのです。そうであるなら英文を書くためにはアメリカ人(もしくはイギリス人など)の発想を身につけなければならないというのでしょうか。

「発想を身につける」なんて必要はないという意見もあると思います。英語には全世界的に通用する「グローバル・イングリッシュ」というものがあるので、とくに何かの発想というものに依存しないのでしょう。

どんな発想で作られた英文であろうとも、その英文を受け取るのが英語ネイティブであるなら、自分たち(つまり英語ネイティブ)の発想である方が理解しやすいでしょう。結局のところ、英文を使って発信するのが英語ネイティブに受信されるのを期待しているのですから、彼らの発想に近い英文を作れるようになっておいた方が、コミュニケーションがスムースに運ぶと思います。

ただ難しいのは、その発想を身につけるには、どうしたら良いのかということです。

北海道新幹線で新青森から新函館北斗へ

北海道&東日本パスを使って北海道旅行をしています。1年前までは特急白鳥やスーパー白鳥を利用していましたが、今年からは北海道新幹線を利用することになります。利用方法などがいろいろと違っているのですが、もっとも大きな違いは、特急には自由席があったのに、新幹線は全て指定席だという点です。

北海道&東日本パスの場合は利用規約で「新青森~新函館北斗間相互発着の場合に限り、別途特定特急券」を買えば指定を取らなくても空いている席を利用できることになっています。問題は、どの席が空席なのかを調べる方法です。乗車してから全車両を歩き回って空席を探すのは効率が良くない気がします。

乗車後に車掌さんに尋ねれば教えてくれるかもしれませんが、もっと別な方法はないものでしょうか。旅行前に考えていたのは、新青森駅のみどりの窓口で尋ねてみようということでした。新青森に到着して時に、在来線改札のところにいた駅員さんに質問してみました。すると、みどりの窓口で尋ねても回答できるが、自動発券機を操作すれば空席のままになっている場所がわかると教えてくれました。

空席が多く残っている号車を調べて、指定がとられていない座席をメモしてから、乗車しました。すると指定はとられていない筈なのに既に座っている人がいる座席がありました。空席を調べるときには、空席が多く残って良そうな場所を塊として探しておいたほうが無難だと思いました。ピンポイントで空席を探すと、そこに誰かが座っていた場合に、他に座れる場所が何処にあるのか、もう探すことができなくなってしまう ので注意が必要です。

幸いにも指定がとられていなくて、かつ先客がいない席に座れたのでホッとしました。

去年までの特急でも、北海道新幹線でも、乗ってしまえば、乗車している感じはそれほど違いはありません。もちろん1列の席数が2+2席から2+3席になっているとか、速度が速いとか、細かく言えば違うのですが、些細な違いという気がします。

むしろ従来の特急はJR北海道が主体だったのに、北海道新幹線とは言っても実際には東京から出発しているのでJR東日本の色が濃くなっています。車内販売で駅弁を買いましたが、品揃えが変わっていますし、座席のポケットに入っている冊子もJR東日本のものが増えています。

在来線と違って新幹線はトンネルが多いし、それ以外でも防音壁が視界を遮るので、車外の風景を楽しむのが難しくなりました。車内アナウンスで教えてもらいましたが、新函館北斗に到着する前に函館山が見えました。

2016/12/27

MITCHELLS PLAIN 7785 CAPE TOWN SOUTH AFRICA

もう随分前のことになりましたがピースボートに乗船したことがあります。今でも昨日のことのように記憶に残っている良い思い出です。船内では別料金で「GET(Global English Training)」という英語コースを受講しました。

寄港した時には学んだことを実践するため数々のミッションが計画されていました。そのひとつとして、ケープタウンでは現地の家庭にホームステイする(一泊だけですが)という課題が与えられました。当初はホームステイ先あたり2人ずつ割り当てると聞いていましたが、実際には各家庭に1人ずつ送りこまれることになってしまいました。受け入れる家庭の都合としても部屋に余裕があるわけではないので1人ずつの方が良かったのでしょうし、送り出す側の講師陣の意向としても1人ずつなら誰にも頼れないので甘えが出ないと考えたのかもしれません。

ケープタウンから車で2時間くらいの街だったと思います。 鉄道の駅があって写真を撮りましたが、駅名とか地名が判明するような情報が写っていません。ホームステイ先は「Mitchells Plain」というコミュニティの中にありました。夕食をご馳走になったあと近所の家庭に連れて行ってもらいました。南アフリカ共和国はイギリスの影響を受けているためか、自動車は日本と同じ左側通行でした。夕暮れの中を歩いていると、そこがまるで日本にいるかのように錯覚しそうな風景だったことを覚えています。

ホームステイ先には礼状を出したので住所は知っています。ふと思いたったのでグーグルで検索してみたところ、Googleマップでポイントされた場所がありました。なんとストリートビューもあります。視界を左右に動かしてみると、ここがホストファミリーと写真を撮った場所に間違いないようです。

ケープタウンからMitchells Plainに来たとき、またケープタウンに戻るときの集合場所がホームステイ先の近所にあったような記憶があります。こういう場所は日本なら公民館とか集会場とかですが、外国なら教会がそういう場所に相当するでしょう。Googleマップで確認すると「Church of the Annunciation」という英国国教会の教会があるようです。ここもストリートビューで見られます。この教会の入り口の前でも現地の人達と写真を撮っていて、その背景に写っている様子が、ストリートビューで見る建物の様子と一致します。間違いないでしょう、ここです。

なんて凄いんだGoogle。旅先で見た風景が甦るとは思ってもいませんでした。


2016/12/21

Windows Vistaの2016年12月分Windows Updateは相変わらず終わらない

dynabook SS SX/15Aに元々インストールされていたWindows Vistaの2016年12月分Windows Updateは、今月も「更新プログラムを確認しています...」が延々と続いています。この表示が数日間出続けるのにも慣れてしまいました。今年の夏ごろまでは、異常に時間がかかったとしても待っていれば更新の確認が終わったのですが、秋以降は一週間待っても更新の確認が終わりません。

この現象はWebで話題になっているのが確認できますが、根本的な解決策は見いだせていないようです。よく見かけるのが「Windows Updateをしばらくおこなっていないために、更新が大量に溜まっているから遅いのだ」という 情報ですが、僕の場合は毎月更新をかけているので、あてはまらないと思います。

事前に一部の更新を手作業を入れておけば良いという情報もありました。そこで次の更新を個別に拾ってきて入れてみました。
  • KB3204723
  • KB3203621
  • KB3128019
  • KB3128025
この後あらためて「更新の確認」をおこないましたが、数時間たっても終わりません。

Windows Vistaのサポート期限まであと数ヶ月ですから、積極的な対応(例えば、OSをクリーンインストールしてみるとか) をする気にはなれません。そうかといって、セキュリティ更新を無視するわけにもいかないでしょう。今後は、月例リリースされた更新を手作業に入れていくのが無難なのかと思っています。

2016/12/19

dynabook SS SX/15Aの起動時にWindows Vistaの「システム修復メニュー」が出る

dynabook SS SX/15Aの内蔵HDDはWindows Vistaが入っています。来春にはNetBSD/i386に移行するつもりで作業を進めています。当面はVistaの環境を壊さないために、USB接続の外付けHDDにNetBSD/i386を入れて移行作業をおこなっており、こうすることで内蔵HDDの構成を壊さないようにしているつもりでした。

ところが、たまに内蔵HDDからWindows Vistaを起動しようとすると「システム修復メニュー」が表示されてしまいます。ここで修復させて起動させてしまえば、その後は再起動しても問題ありません。しかしUSB接続HDDからNetBSD/i386を起動すると、その後に内蔵HDDからVistaを起動させる時には「システム修復メニュー」が出るのです。

USBで接続された外部HDDに入っているNetBSD/i386からは内蔵HDDを一切アクセスしないようにしているのですが、実は何処かで何かを書き換えているのでしょうか。「システム修復メニュー」が目障りではありますが、それほど大きな問題だとは思っていません(むしろ大問題と考えていて、とても困っているのは、毎月配信されるセキュリティ更新の確認が延々と終わらないことです)。

2016/12/16

Firefoxで日本語入力が出来るようになったけど、微妙に操作性が良くない

FirefoxでiBus-Mozcの日本語入力が出来ないので、Webで調べてみたら、類似した事例が見つかりました。
これらの記事で指摘しているのは、環境変数GTK_IM_MODULEQT_IM_MODULEの設定を「ibus」から「xim」にすることです。このように設定を変更したところ、無事にFirefoxでも日本語入力ができるようになりました。ここで(これまで日本語入力ができていた)他のアプリケーションに影響が出て(日本語入力ができなくなって)しまうと困るのですが、そういうこともなく、全てのアプリケーションで日本語入力ができるようです。

これで解決と言いたいところですが、実は微妙に動作が変わりました。これまでiBus-Mozcで日本語入力ができていたアプリケーションでは、日本語変換中の変換候補のウィンドウが変換中も文字列の近くに表示されていたのですが、それが遠くに離れてしまいました。微妙に操作性が良くありません。

ひとつの方法として、上述した環境変数の設定値はibusのままにしておいて、Firefoxなど一部のアプリケーションだけ環境変数の設定をximに切り替えてアプリケーションを起動するようにすることが考えられます。操作性の拘りが強ければ、この方法が望ましいのでしょう。しかしNetBSD/i386でMATEを使って総合的な環境を構築しているうえでは、他にも粗が目立つこともあり、些細な問題であるとも感じます。現段階では日本語入力ができるようになっただけで良しとして、細部を調整するのは将来の課題としましょう。

さて今回の問題は環境変数GTK_IM_MODULEQT_IM_MODULEの設定を変えることで対処できましたが、そもそもこれらの環境変数に関する正式なドキュメントは何処にあるのでしょうか。他にもXMODIFIERSという環境変数がWebの記事では言及されることが多く、「そういうものか」と思って環境設定をおこなうことはできるのですが、できれば正式なドキュメントを参照しておきたいと考えています。

今度はFirefoxで日本語入力ができない

Firefoxで日本語入力が出来ないことに気が付きました。これはpkgsrcからコンパイルしたのでLinuxエミュレーション用バイナリではありません。ただし正確にはFirefox安定板ではなくてNightly 49.0です。

同じようにpkgsrcから入れたThunderbird(こちらも正確にはEarlybird 45.3.0)では日本語入力が可能なので、Firefoxだけの問題のように思われます。

Firefoxで日本語が入らない問題以外には目立った障害はなさそうです。Windows側で使っていたブックマークをJSONファイルで移行してみましたが問題ありませんでしたし、登録してあったサイトも閲覧できました。

日本語が入らないというのは大きな問題なので、解決できるように調査してみようと思います。

dynabook SS SX/15AのNetBSD/i386で音が出ない

dynabook SS SX/15AにNetBSD/i386をインストールし、Windows Vistaから環境を移行する作業を続けています。主要なアプリケーションが入ったので、動作確認を兼ねて、Vistaの環境で出来ていたことがNetBSD/i386でもできるか確かめてみました。

WebブラウザからNHKの「らじる★らじる」やrajiko.jpを利用しようとしたら、Adobe Flashプラグインが入っていないというエラーになってしまいました。世間的にはAdobe Flashは使わない方向のはずですが、現状で使われているサイトがあるのは仕方ありません。何か逃げ道があるのか、どうしようもないのか、調べてみようと思います。

そもそもオーディオ機能が利用できるのか確認したら、ブートログでエラーが出ていました。
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: couldn't map mmio space
Ubuntu-MATE 16.04を起動したときには次のように認識されていましたので、NetBSD/i386のGENERICカーネルにはドライバが入っていないのかもしれません。
[   45.211496] snd_hda_codec_realtek hdaudioC0D0: ALC262: SKU not ready 0x598301f0
[   45.211780] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC262: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   45.211787] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   45.211793] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
[   45.211797] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[   45.211801] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[   45.211807] snd_hda_codec_realtek hdaudioC0D0:      Internal Mic=0x19
[   45.211812] snd_hda_codec_realtek hdaudioC0D0:      Mic=0x18
[   45.281447] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[   45.281639] input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9

2016/12/15

Windowsの「ドキュメント」にあるファイルをNetBSD/i386側に転送

NetBSD/i386側からWindows10の共有フォルダをマウントできることが確認できました。そこでWindows10のアカウントFURUSAWAにある「ドキュメント」フォルダ以下を全てNetBSD/i386側に転送しておきます。

転送はNetBSD/i386上のrsyncを使います。Windows10の共有フォルダをNetBSD/i386上のディレクトリにマウントしておけば、ローカル対ローカルの転送のように見せかけることができます。

rsyncには数多くのオプションが用意されています。よく使われるオプションは決まっているのですが、念のために全てを確認していくと「--iconv」というオプションを見つけました。これは転送元と転送先でのファイル名の文字コードを変換してくれるようです。それならばrump_smbfsを使ってマウント時に文字コード変換をおこなわなくてもよくなります。mount_smbfsでファイル名の文字コードを無変換のままにマウントしておき、rsyncで転送する時点で--convオプションでファイル名の文字コードを変換させてやればよいわけです。ファイル名の文字コード変換をrump_smbfsでやるかrsyncでおこなうかは、システム構成の全体像を踏まえて決定されるべき事項です。

方式が決まったので、シェルスクリプトを作って一括転送をおこないました。ところがネットワークがおかしいのか、ハードウェアの問題なのか、よく転送が固まりました。いわゆる「刺さる」という状態で、強制的な電源断しかできなくなります。何が問題の原因なのか現時点では不明ですが、解決しておきたい問題です。

2016/12/13

NetBSD/i386でmount_smbfsを使ってみる

dynabook SS SX/15AのWindows VistaをNetBSD/i386に移行するために重要なのは、Windows10が動いているデスクトップPCにあるドキュメント以下のファイル群を同期させることです。Vistaを使っていれば、同じWindowsですから、ネットワークを介してファイル転送することは容易です。Windows10側からVistaに向かってファイルを送り出す形でファイルの同期をとっていました。

Windows VistaをNetBSD/i386に変えたら、どのような方式でファイル同期をとれば良いのか検討しなければなりません。実現の難易度は別にして、次のような方法が考えられます。
  1. NetBSD/i386にSambaをインストールして、以前と同じようにWindows10からVistaに向けてファイルを送り出す。
  2. Windows10にNFSサーバーを入れて、Windows10のディスクをNetBSD/i386からマウントする。
  3. Windows10にNFSクライアントをいれて、 NetBSD/i386のディスクをWindows10からマウントする。
  4. FTPを使って、Windows10からNetBSD/i386に向かってファイルを送り出す。
この中で最も実現しやすそうなのがSambaを利用する方法です。ただし同期させるためだけにSambaを入れるのは「牛刀をもって鶏を割く」の諺が思い浮かぶので、どうも気が進みません。

ここでNetBSD/i386にはmount_smbfsがあることに気付きました。これはWindowsで使われているSMBプロトコルでリモートファイルシステムをマウントさせるものです。これを使えば、余計なインストールが発生せず、ちょうど良い感じです。

Windows10のデスクトップPCが、WINDOWSという名前で192.168.1.99というIPアドレスだとします。この場合なら次のようなコマンド打つことになります。ここで-Nオプションを指定しておくと、接続時に必要となるパスワードを/root/.nsmbrcで指定しておくことができます。
mount_smbfs -I 192.168.1.99 -E UTF-8:CP932 -N //FURUSAWA@WINDOWS/Users /mnt
さてWindowsでは当たり前のように使われている日本語ファイル名を変換するために-E UTF-8:CP932オプションを指定したのですが、どうも変換されていないようです。マウント自体は成功しているのですが、ファイル名に含まれている日本語が化けてしまっています。ロケールをja_JP.SJISにすると問題なく読めるので、CP932からUTF-8へのコード変換が効いていないようです。

Webで調べてみると、FreeBSDでは問題ないようです。正確には、過去には問題があったけど、今は修正されているようで、今は問題なく利用できる状態になっているようです。FreeBSDとNetBSDは同じBSD系と言っても、独自の進化を遂げているので、微妙なところで使い勝手に違いがあります。

どうしたものかと頭を抱えてしまいました。ここは基本に戻って、ドキュメントをしっかり読むことから始めようと、MOUNT_SMBFS(8)を最初から最後まで読んでみました。すると最後に次のような記述がありました。
BUGS
The -E option works only if you mount with rump_smbfs(8) instead of mount_smbfs. 
要するに/sbin/mount_smbfsではなく/usr/sbin/rump_smbfsを使わなければならないのだそうです。オプション等は同じように指定できるようなので、コマンド名だけを変えて実行してみたところ、無事に日本語変換がおこなわれることを確認しました。

NetBSD/i386上でWindows10のファイルをマウントすることができることがわかりました。このようにマウントした状態で、rsyncを利用して、リモート側(Windows10) のファイルをローカル側(NetBSD/i386)に同期させようと思います。

方針は定まりましたが、NetBSD/i386のrump_smbfsは動作が不安定な印象を受けます。反応が遅いと思っていたら、マウントが切れていたりします。負荷をかけても大丈夫なのか若干心配は残りますが、頻繁に利用するつもりはないので、なんとかなるかと思います。




2016/12/08

NetBSD/i386でLinuxバイナリ版LibreOfficeの日本語変換に成功

ここしばらくNetBSD/i386のLinuxエミュレーション環境でLibreOfficeの日本語入力を可能にしようと試行錯誤を続けてきましたが、ようやく成功しました。これは大きな一歩です。このことでdynabook SS SX/15AのWindows VistaをNetBSD/i386+MATEの環境に移行できる見込みが高まりました。

まず日本語変換を出来るようにするための手順を紹介します。次に解決に至るまでの試行錯誤の一端を紹介します。
  1. NetBSD/i386のLinuxエミュレーション環境はOpenSuse 13.1のサブセットです。pkgsrcからLibreOffice5-binを入れた時にエミュレーション環境も同時にインストールされましたが、日本語変換に必要なファイルが足りなかったようです。
  2. OpenSuse 13.1用RPMを2つ追加する必要があります。適当なミラーサイトからRPMを入手し、/usr/pkg/sbin/rpm2pkgでインストールします。必要なRPMは次の2つです。
    • ibus-gtk-1.5.4-1.1.i586.rpm
    • gtk2-immodule-xim-2.24.22-2.1.i586.rpm
  3. 追加したモジュールを有効にするため、/usr/pkg/emul/linux/usr/bin/gtk-query-immodules-2.0を使って/emul/linux/usr/lib/gtk-2.0/2.10.0/immodules.cacheを更新します。
以上の処理をおこなうことで、LibreOfficeでiBus-Mozcが利用できることを確認しました。

この問題を解決するまで、試行錯誤を繰り返し、時には袋小路に入ったりしました。その全てを書いても仕方ないし、いろいろな可能性を考え、試したので、もう細かいところは覚えていません。

役にたったのは、本物のOpenSuse 13.1の環境を用意したことです。これはWindows10上のVirutualBoxを利用しました。本物のLinux上でLibreOfficeの日本語変換ができることを確認し、どの設定を変えると日本語変換が出来なくなるのかを探ろうとしました。

ここで次のような情報を見つけました。
  1. GTK+2のバージョンによってimmoduleの情報の内部記録の方法が変わったらしいこと。
  2. 環境変数GTK_IM_MODULE_FILEを使うと、このファイルの指す場所を変えられること。
NetBSD/i386を調べてみるとGTK+2のimmoduleの情報が、NetBSD/i386ネイティブ用とLinuxエミュレーション環境用の2つがあることがわかりました。
  • /usr/pkg/lib/gtk-2.0/2.10.0/immodules.cache
  • /emul/linux/usr/lib/gtk-2.0/2.10.0/immodules.cache
これらを比べてみると、Linuxエミュレーション環境用のファイルにはibusやximのエントリがありませんでした。NetBSD/i386ネイティブ用のファイルの方にはエントリが入っています。この段階で、どうやら日本語入力が出来ない原因はこれではないかと見当をつけました。

そこで環境変数GTK_IM_MODULE_FILE/usr/pkg/lib/gtk-2.0/2.10.0/immodules.cacheを指定してみたのですが、LibreOfficeが起動しなくなりました。正確には起動しようとして、落ちてしまいます。その時に、次のようなエラーが出てしまいます。
(soffice:3007): Gtk-WARNING **: /usr/lib/libelf.so.1: symbol __deregister_frame_info, version GCC_3.0 not defined in file libgcc_s.so.1 with link time reference

(soffice:3007): Gtk-WARNING **: Loading IM context type 'ibus' failed
Application Error
NetBSD/i386のLinuxエミュレーション環境というのは、なんでもかんでもLinux用の共有ライブラリを使う訳でもなくて、場合によってはNetBSD/i386ネイティブの共有ファイルもつかうようです。これを期待して環境変数を指定してみたのですが、エラーが出てしまったので、OpenSuse用のバイナリをエミュレーション環境に入れることにしたのです。それが上述した手順です。

また本物のOpenSuseでは、環境変数GTK_IM_MODULE_FILEを指定して、一時的に作成した空ファイルを指すようにしてみました。すると、Mozcが反応しなくなったのです。これはNetBSD/i386上のLinuxエミュレーション環境で動作するLibreOfficeの問題と同じです。このようにして問題となる現象が再現できた(気がした)とき、解決への確信も生まれました。

2016/12/06

「立入禁止」と“Keep Out”

事件や事故が発生すると警察が来て現場を調べるため、関係者以外が入ってくるのを防止するためロープなどで区分します。そこには「立入禁止」と掲示があります。外国のニュースなどを見ていると、英語圏では「Keep Out」と掲示されるようです(他の表現もあるようですが)。これらの意図することは同じで、要するに「関係者以外は入るな」ということです。

日本で使われる「立入禁止」というのは「(事件の発生した内部に外部から)入ることを禁止する」という意味です。英語圏の「Keep Out」というのは「(事件の発生した内部の)外側で留まり(侵入するな)」という意味でしょう。

言語文化によって、その表現に差が現れるのは、とても興味深い問題です。これらはあまりにも日常的な光景なので、意識の端にのぼることもなく通り過ぎていく情報だと思いますが、こういうことの積み重ねが文化圏の常識を形作っていきます。

異文化が接触したときに真っ先に気付くのは、相手側の発想の違いです。なぜそうなのかを問いただしたい気持ちにかられます。しかし相手側からすると当たり前すぎること(すなわち常識)なので、何故と言われても困るのです。

気を付けたいのは、どちらの発想が「正しい」のかとか、「あるべき姿なのか」などを決めることではありません。「違う」ということを知ること、「違いがあることを認める」ことが大切ではないかと思います。多様性とはそういうことでしょう。

ストーブとファンヒーターの違いは、LPとCDの違いのようなもの

冬になると暖房器具の出番になります。ストーブは燃えている炎が直に見えているので狭い場所で使うのは火事が心配です。ファンヒーターなら内部で燃焼して暖気が出てくるだけなので安心して使えます。

ストーブでもファンヒーターでも部屋を暖める機能としては同等なのに、感覚的にはストーブのほうが暖かい気がするのは何故でしょうか。個人で所有している人は珍しいと思いますが、暖炉ならば燃えている炎を直接見る事ができます。目が炎を見ているという信号を脳に送ることで、「暖かいはずだ」という感覚を脳が作り出しているわけではないとは思います。

 薪ストーブのメーカーが「ぽかぽか暖房を発生させるためには?」という情報を出しています。暖房器具の暖かさの源泉は遠赤外線ですが、ストーブなら遠赤外線が暖房機能に直接関わってきます。これに対してファンヒーターの場合は遠赤外線が器具の外に出てくる事はなく、温められた暖気が出てくるだけです。

これらの器具の違いを考えていたら、LPとCDも似たような関係にあるのではないかという気がしてきました。

LPとCDの違いというのは、記録媒体がアナログ式かディジタル式かということです。CDの場合は人間の可聴音域以外の情報をカットしてあります。これに対してLPなら可聴音域以外の情報も入っている可能性があります(それがピックアップやアンプで再現できるかどうかは別問題ですが)。

人間の可聴音域は20Hz~20kHzと言われていますが、個人差や年齢差があるので、実際にはもっと狭い範囲しか聴き取れないと思われます。しかし耳では聞こえていなくても、身体では音を検知していて、脳に信号が伝わっているとする研究があるようです。

暖気を排出することで部屋を暖めればよいとするファンヒーター(エアコンも同様でしょう) はCDのような割り切りがあり、一方でストーブは熱源が発する遠赤外線の全てを部屋中に放射するのでLPのようなものではないかと思うのです。

LibreOfficeで日本語入力できるようにするには、どうすれば良いのか?

NetBSD/i386でLinuxバイナリを使ってLibreOfficeを動かすと日本語入力ができない問題を調べていますが、なかなか手掛かりがつかめません。

「LibreOfficeで日本語入力が出来ない」と書いていますが、それはLinuxバイナリを使っているのがLibreOfficeしか今のところないからであって、それだけのことです。おそらくLinux用バイナリならばLibreOffice以外でも同様の問題を抱えていると思っていますが、確認しておいた方が良いかもしれません。

また日本語入力はibus-Mozcを使っています。これも同様に、ibus-mozcだから起きている問題ではないと思っています。ただ念のため、他のエンジンを使っても同様の現象がおきるのか、 または起きないのか、確認しておくべきかもしれません。

iBusの設定画面を開くと、エンジンとして「japanese」と「Mozc」が登録されています。これを切り替える機能は「<Super>+<Space>」というキーに割り当てられています。<Super>というのはWindowsキーのことらしいです。さて、LibreOfficeで日本語入力は出来ないのですが、エンジン切り替えは出来ることに気がつきました。つまりLibreOfficeに渡したキー入力はiBusに伝わっているということです。それならば何故Mozcにまで伝わっていないのでしょうか。

pkgsrcからlsofを入れて、調査してみることにしました。NetBSD/i386では次のような情報が得られました。このときLibreOfficeも起動しているのですが、immodulesというディレクトリにあるファイルをアクセスしていないようです。
sh         1997     root  cwd     VDIR        4,4      512 2039616 /usr/pkg/emul/linux/usr/lib/gtk-2.0/2.10.0/immodules
mate-term  6976 furusawa  txt     VREG        4,4    33519 1266968 /usr/pkg/lib/gtk-2.0/2.10.0/immodules/im-ibus.so
mate-pane  7623 furusawa  txt     VREG        4,4    33519 1266968 /usr/pkg/lib/gtk-2.0/2.10.0/immodules/im-ibus.so
さて比較のためにWindows上のVirtualBoxでUbuntu-MATEを動かしたみて、同様の情報を調べてみました。ここではLibreOfficeも現れています。
tilda     2999        furusawa  mem       REG                8,1    34840     416052 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-fcitx.so
gmain     2999 3055   furusawa  mem       REG                8,1    34840     416052 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-fcitx.so
gdbus     2999 3056   furusawa  mem       REG                8,1    34840     416052 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-fcitx.so
clock-app 3155        furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gmain     3155 3168   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gdbus     3155 3170   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
dconf\x20 3155 3256   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
mate-term 3315        furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gmain     3315 3318   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gdbus     3315 3320   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
dconf\x20 3315 3321   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
threaded- 3315 3322   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
soffice.b 3421        furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
rtl_cache 3421 3423   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
OfficeIPC 3421 3425   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gmain     3421 3426   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
gdbus     3421 3427   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
ICEConnec 3421 3429   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
Selection 3421 3430   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
threaded- 3421 3455   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
thread-po 3421 3931   furusawa  mem       REG                8,1    30744     416051 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-fcitx.so
このような状況をみると、immodulesのディレクトリにあるファイルをアクセスしていれば日本語入力が出来て(Ubuntu-MATEの場合)、アクセスしていないなら日本語入力できない(NetBSD/i386の場合)と考えられます。しかし、では何をすれば良いのか、さっぱり見えてこないので、調べてみたものの結局何の役にもたちません。なかなか手強い問題ですが、何か糸口が見つからないかと足掻くような思いです。

2016/12/05

Linux用バイナリを使ったLibreOfficeで日本語入力が効かない問題

NetBSD/i386でLinux用バイナリを利用してLibreOfficeを使おうとすると日本語入力が効きません。Webで調べてみたところ、FreeBSDのLinuxエミュレーションでも同様の現象が起きているようです。
要するにLinuxエミュレーション環境のディレクト構造にある/usr/share/localeja_JP.UTF-8がないことが原因ということのようです。確かに/emul/linux/usr/share/locale/ja_JP.UTF-8はありませんでした。

そこで「/emul/linux/usr/bin/localedef -i ja_JP -f UTF-8 ja_JP.UTF-8」を実行してみたら、次のようなエラーが出てしまいました。
character map file `UTF-8` not found: No such file or directory
cannot read character map directory `/usr/share/i18n/charmaps`: No such file or directory
FreeBSDのLinuxエミュレーションではCentOS 6相当だそうですが、NetBSDではOpenSUSE 13.1が使われています。ロケールにある情報はLinuxのディストリビューションに依存しないような気がするので、Ubuntuあたりから拾ってきて入れてみようかと思います。

MATEのメニューエディタが動かない問題

MATEのコントロール・センターにある「メニューエディタ」が動きません。アイコンをクリックしても、何のウィンドウも開きません。メニューエディタの実体は/usr/pkg/bin/mozoというらしいので、コマンドラインから動かしてみました。すると次のようなエラーが出ています。
Traceback (most recent call last):
  File "/usr/pkg/bin/mozo", line 36, in <module>
    main()
  File "/usr/pkg/bin/mozo", line 32, in main
    app = MainWindow(datadir, version, sys.argv)
  File "/usr/pkg/lib/python2.7/site-packages/Mozo/MainWindow.py", line 54, in __init__
    self.editor = MenuEditor()
  File "/usr/pkg/lib/python2.7/site-packages/Mozo/MenuEditor.py", line 36, in __init__
    self.__loadMenus()
  File "/usr/pkg/lib/python2.7/site-packages/Mozo/MenuEditor.py", line 46, in __loadMenus
    self.applications.dom = xml.dom.minidom.parseString(util.getUserMenuXml(self.applications.tree))
  File "/usr/pkg/lib/python2.7/site-packages/Mozo/util.py", line 202, in getUserMenuXml
    menu_xml += "<MergeFile type=\"parent\">" + system_file +    "</MergeFile>\n</Menu>\n"
TypeError: cannot concatenate 'str' and 'bool' objects
そしてこの現象はバグ報告があがっているようです。githubに「Mozo refuses to start if mate-applications.menu is empty.」というエントリがあります。1週間ほど前にエントリされたようですが、まだ何の反応もありません。

バグ報告が出ているなら、いずれ解決されるでしょう。

NetBSD/i386上のFirefoxとThunderbirdを入れ直し

pkgsrcからFirefoxをThunderbirdを入れましたが、勘違いをして旧いバージョンを入れてしまいました。あらためて「pkgsrcから入れることができる」最新バージョンに入れ直します。当初はpkgsrcにあるwww/firefox45mail/thunderbird38を使いましが、これが間違いのもとでした。素直にwww/firefoxmail/thunderbirdを使ってインストールしておけば問題なかったのです。

pkgsrcからインストールした場合には、1)最新バージョンと言ってもMozillaが提供する最新版より旧い、2)安定公開版ではないので何が起きるかわからず怖いという問題があります。

pkgsrcのwww/firefoxを使うと「Firefox Nightly 49.0」が入りました。mail/thunderbirdでは「Thunderbird Earlybird 45.3.0」でした。これらのバージョンは、Microsoft Windowsなら2016年9月頃にリリースされたものです。

使用に耐えないようであれば、何か別の方法を考えることにします。今思いつく解決策はLinux用のバイナリを使うことです。しかしLinux用バイナリのLibreOffice5において日本語入力が出来ないという問題が発覚しているので、おそらく同じ問題に遭遇してしまうでしょう。

ただしこの日本語入力できない問題は大問題なので、できるだけ早く解決したいと思っています。そうすればFirefoxやThunderbird(もちろんLibreOfficeも)をLinux用バイナリで利用できるようになるはずです。

2016/12/02

NetBSD/i386環境にインストールしたアプリケーションの現状と問題点

NetBSD/i386にインストールしたアプリケーションを使ってみました。思いのほか上手くいっている点もありますが、かなり深刻な問題もあります。問題が解決できれば言う事ありませんが、スッキリと解決できなくても回避策が見つかれば良しとするべきかもしれません。ともかく問題点が見つかるたびに、その問題にのめり込んでいると先に進めないので、最終目標である「Windows Vistaの代替環境をNetBSD/i386+MATEで実現する」のゴールに向かって先を急ぐことにしましょう。どうやらこの調子では、何かするたびに問題が見つかりそうですが、それは記録しておいて、必要性の高いものから順番に解決していこうと思います。

 まずFirefoxとThunderbirdを起動してみました。問題は無さそうな気がします。メニューが英語ですが日本語のサイトも問題なく見られます。L10Nというパッケージを使うと日本語メニューに切り替えられます。その手順はpkgsrcでビルドしている最中に表示されたので、メモしておきました。メニューなどが日本語になってくれるのは助かりますが、それだけのことなのかもしれません。メニューやメッセージが英語でも気にしなければ、あえてL10Nを使う必要はない気がします。

LibreOfficeは問題なく起動しました。Linuxエミュレーション環境で動作しているとは言っても、動きが遅くなるわけでもありません。これなら問題ないと思っていたら、大問題が発覚しました。Mozcで日本語入力が可能になったので、日本語を入れようとしたらキー入力がMozcと連携せずにLibreOfficeに渡されているようで、全く日本語が入りません。何か設定すれば良い問題なのか、かなり根が深い問題なのか、さっぱり見当もつきません。深刻な問題ですが、現状を把握しておいて、先に進むことにします。

日本語入力はiBus-Mozcを利用していますが、上手くいきました。キーバインドや設定項目に不慣れな個所が残っていますが、おいおい慣れていくでしょう。日本語入力をおこなうにはiBusデーモンが起動している必要があります。MATEのコントロール・センターにある「自動起動するアプリ」で次の設定を追加して、自動的にデーモンが起動するようにしました。
【名前】iBusデーモン
【コマンド】/usr/pkg/bin/ibus-daemon -d
【説明】

XDMを使ってグラフィカル・ログインが出来るようになったと思っていたのですが、うまくいったり、駄目だったりします。原因を追究したいとは思いますが、問題を把握しておいて、調査はあとにするつもりです。

MATEは動いてはいますが、問題がないわけではありません。まだ全ての問題を把握しているわけではありません。わかっているところでは「コントロール・センター」のアイコンをクリックしても動作しないものがあります。ひとつは「ネットワークプロキシ」というもので、これをクリックするとコアを吐きます(ホームディレクトリにmate-network-pro.coreが作られる)。もうひとつは「メイン・メニュー」で、アイコンをクリックしても何も起きません(実態は/usr/pkg/bin/mozoらしい)。コアは出来ていませんが、何も起動してこないので、何がどうなっているのか不明です。これが動かないとMicrosoft Windowsでいうところのスタートメニューを変更できないので、ちょっと影響が大きいと思っています。他にも、日本語化が不完全で統一感がないとか、日本語で表示されていても見え方が不自然だとか、問題はいろいろあります。

MATEが決して完全とは言えませんが、だからと言ってMATEを捨てて、LXDEとかKDE、Gnomeに乗り換えれば済む問題とも思えません。他のデスクトップ環境に乗り換えたら、解決している問題もあるかもしれませんが、また別の問題が表に出てくるので、結局は何の解決にもならないのではないかと想像しています。あれこれ目移りせずにMATEで環境を構築する方向で進むのが、遠回りに思えても、最終的には最善の道ではないかと考えています。

マンハッタンヘンジ

もう随分前のことになりますがNHK BSプレミアムの「世界で一番美しい瞬間」という番組で「希望の夕日 想いこめるとき ニューヨーク」(2014年10月23日放送)というタイトルの放送がありました。ニューヨークのマンハッタン島の道路と平行に日没が見られる日があり、その光景が美しく、イギリスにあるストーンヘンジをもじって「マンハッタンヘンジ」と呼ぶのだそうです。なんとウィキペディアにも項目があがっているくらいですから、有名なのかもしれません(僕は知りませんでしたが)。

関連ブログもいろいろと見つかります。例えば「年2回しか見られない!米ニューヨーク「マンハッタンヘンジ」が幻想的」という記事によると、5月28日と7月12~13日前後が狙い目だそうです。また1番街の42丁目交差点がベストロケーションとのことです。ニューヨークの街路は碁盤目状なので、何処でも良いのではないかとも思いますが、方角以外にもビルの立地状況とか、いろいろあるのでしょう。

さてWebで利用可能な「日の出日の入時刻方角マップ」というものを見つけました。マップ上にポイントを置くと、指定した位置における指定した日付の「日の出」と「日の入り」の方角を表示してくれるものです。日本国内で使われるのを想定しているのだと思いますが、地図上では世界中の何処にでもポイントを置くことができます。

これを使ってマンハッタン島の1番街42丁目交差点にポイントを置いたところ、2017年5月25日と2017年7月17日が(晴れてくれれば)綺麗な日没が見られそうです。

同じようなことは日本でも出来そうな気がします。道路が碁盤目状の都市というと、北海道なら札幌が良いかもしれません。北海道は、旭川や帯広などほかの都市も碁盤目状になっているところが多いのですが、ビルが適度に建っていてくれないとストーンヘンジっぽくないかもしれません。

また京都や奈良、大阪なども、道路が碁盤目になっていますが、盆地になっていると山が邪魔になって、マンハッタン島のように綺麗な日没にはならない恐れがあります。

碁盤目状の道路に拘らず、神社の鳥居とか、有名なタワーなどを狙って写真を撮るのも面白いでしょう。

どういう構図を狙うのか考えてみると、アイディアはいくらでも湧いてくるでしょう。

NetBSD/i386環境にアプリケーションを追加インストール

dynabook SS SX/15Aを使ってNetBSD/i386環境の構築で、XDM経由でログインし、MATEデスクトップが利用できるところまで辿りつきました。利用頻度の高いアプリケーションをインストールし、また日本語入力も出来るようにしておきます。ここまで出来れば、最終段階には至っていないものの、ひとやまを越えたと言えるでしょう。

まずFirefoxとThunderbirdをpkgsrcからビルドします。どちらも本体とL10Nの両方をインストールします。pkgsrcで入るFirefoxやThunderbirdは最新版という訳ではありません。Firefox45というのはWindowsなら2016年3月頃のバージョンです。Thunderbird38も同様で、Windowsでは38.7が2016年3月にリリースされています。だいたい9ヶ月くらい古いバージョンということになります。Firefoxは特にバージョンアップが速く、Windowsでは既に50.0.2がリリースされています。バグ対応もあるかと思いますが、気になるのはセキュリティ対応でバージョンが上がっていることです。OSがWindowsかNetBSDかで脆弱性の影響が若干異なるとは思いますが、それでもセキュリティ問題は気になります。

次にLibreOffice5をインストールします。pkgsrcにあるのは、バージョン4系とバージョン5系です。バージョン4系はNetBSD自前でビルドすることになりますが、バージョン5系ではSuse Linuxの環境をNetBSD内に構築してLinux用バイナリを動かすことになります。Windows側で既にLibreOffice 5.1.6.2を利用しており、また今後Linuxバイナリしかないアプリケーションを利用する予定でもあったので、Linuxエミュレーション環境を使ったLibreOfficeをインストールすることにしました。

NetBSDのpkgsrcにあるLinuxエミュレーション環境はSuseということになっています。これが他のディストリビューション(Ubuntu、Fedra、CentOSなど)とどのように違うのか、またどのくらい同じなのか、よくわかりません。/usr/pkg/emul/linux以下にLinux環境のディレクトリ構造が出来上がっているのを見ると、Windows10 Anniversary UpdateでUbuntu環境を提供するためにC:\Users\FURUSAWA\AppData\Local\lxss\rootfs以下にディレクトリ構造が出来上がっているのと同じ構図です。エミュレーション環境を実現するために必要なファイルが置かれるのは仕方ないことですが、コマンド実行、ライブラリ参照、インクルードファイル参照などにおいて、うっかり間違えないように注意が必要になると思います。

日本語入力環境を用意しておかなければなりません。以前にSONY vaio PCG-SRX3/BDにNetBSD/i386環境を作りかけていたときにiBus-Mozcを使ったので、今回も同じにします。ビルドには約12時間かかりました。まだインストールしただけで設定などは行っていませんが、以前できていたので(若干トラブるかもしれませんが)問題ないでしょう。むしろ考えておくべきなのは、Windows側のMS-IMEで登録した単語をMozcで使うための環境をどのように構築するかです。もしかするとMozcで単語を登録して、MS-IMEに追加するような事態が発生するかもしれません。このあたりのフローを検討しておかなければならないと考えています。

最後に日本語フォントを追加しておきます。NetBSD/i386の標準的なインストールを済ませただけでも日本語は出ていますが、追加したフォントが本当に必要か、やはり不要となるのかは、今後の使い方次第だとは思います。pkgsrcから追加したのは次のフォントです。
  1. fonts/efont-unicode
  2. fonts/ipafont
  3. fonts/ipaexfont
  4. fonts/ja-sazanami-ttf
  5. fonts/vlgothic-ttf

2016/12/01

急行はまなす廃止後の青函移動

毎年年末年始は格安切符(普通列車限定の切符のこと)を利用して北海道に行っています。今年もそろそろ旅程を考えようと思っているところです。今年の春に北海道新幹線が開業したため、去年まで利用していた急行はまなすが廃止されてしまいました。代替として北海道新幹線を利用するしかないのですが、旅程を組むのが難しくなりました。

急行はまなすを利用していた頃は、青森を22時過ぎに出れば、翌朝6時頃には札幌に到着できました。そこから旭川方面に行っても良いし、帯広まで当日中に辿りつくことが可能でした。

北海道新幹線なら、はやぶさ33号で新青森を22時32分に出ると、新函館北斗には23時33分に到着します。しかしはこだてライナーの終電で函館に行く以外に手はありません。翌朝は函館8時18分の長万部行きに乗ると長万部に11時20分に到着します。ここから室蘭方面を目指すなら長万部発15時26分の東室蘭行きまで4時間ほど待つしかありません。小樽方面であれば長万部発13時16分の倶知安行きがあり、乗り継げば夕方18時前には札幌に到着できるでしょう。もちろん特急に乗れば待ち時間が短くなりますが、格安切符なので特急を利用することは出来ません。

もし新青森6時32分のはやて91号を利用したとすれば、新函館北斗には7時38分に到着します。函館発8時18分の長万部行きは、新函館北斗に8時43分に着くので、乗り継ぐことは可能です。しかしその後の旅程は全く同じになります。しかも、過去に利用していた経験では、これを利用する乗客は多く、函館を出発する時点で既に満席になっています。おそらく函館北斗で乗っても座れない可能性が高いと思います。

青森から函館に向かう場合、青森に宿泊して北海道新幹線の始発に乗るか、北海道新幹線の最終便で函館に向かい宿泊するかの、どちらかになってしまいます。 函館に宿泊すると言っても、はこだてライナーの函館到着は0時5分ですし、朝の長万部行きは8時18分発ですから、あまり時間に余裕はありません。ホテルに泊まってもゆっくりできません。

ここでフェリーを使うことも視野に入れてみます。国鉄時代には青函連絡船がありました。JRになって鉄道でつながるようになってからも、「津軽海峡フェリー」と「青函フェリー」という2社が青森と函館を結んでいます。しかもありがたいことに深夜便もあるので、寝ている間(ゆっくり寝ているほど長時間ではありませんが)に移動できます。

問題は青森側も函館側もフェリー乗り場が駅から遠いことです。深夜便を利用するつもりなら公共交通は無いでしょうが、時間に余裕があれば歩いても構わないと思っています。タクシーで移動すれば楽ですが、早めに駅に着いたところで、閉まっていて入れなければ悲惨です。