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社が青森と函館を結んでいます。しかもありがたいことに深夜便もあるので、寝ている間(ゆっくり寝ているほど長時間ではありませんが)に移動できます。

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

2016/11/30

XDMでグラフィカル・ログイン

LightDMを使うことを一時断念しXDMでログインできるように設定しておきます。この辺りの設定は1年ほど前にSONY vaioにNetBSD/i386を入れた時の実績があるので、あまり心配はしていませんでした。

"The NetBSD Guide"の"9.10. Graphical login with xdm"に従って標準的な設定をおこないます。
  1. /etc/rc.confに「xdm=YES」を追加します。
  2. ユーザのホームディレクトリに~/.xsessionを用意します。
これでxdmでグラフィカル・ログインできるようになりました。ところが一般ユーザでログインするとMATEが起動せずxdmに戻ってしまいます。ホームディレクトリにある~/.xsession~/.xinitrcへのシンボリックリンクになっていて、startxを使ったときにはMATEが起動できていたのです。

Webで調べてみたところ最後の「exec mate-session」を「exec ck-launch-session mate-session」にしなければならないようです。 この変更をおこなうとxdmでログインして無事にMATEが起動するようになりました。今のところ~/.xsessionには最低限の設定しかおこなっていません。
#!/bin/sh

# setting locale
export LC_ALL=ja_JP.UTF-8
export LANGUAGE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

# setting Input Method
#export XMODIFIERS="@im=SCIM"

# execute scim as daemon
#scim -d

# So, let's go to MATE
exec ck-launch-session mate-session
# $Id:$

2016/11/28

小技でCDの音質は改善されるもの?

最近LPレコードが復活しつつあるようです。CDが登場したのは30年以上前ですが、LPは消えたかに見えましたが愛好家の世界では生き続けていたそうです。CDは、登場した頃から言われていたことですが、LPに比べて音が薄っぺらいと評価されています。CDが登場した時代の技術水準を考えればやむを得ないところですし、人間の可聴音域や、デジタル量子化を踏まえれば、仕方のないことです。

LPは隅から隅までアナログの世界ですので、音質を向上させるためには、アナログを意識したテクニックを駆使しなければなりません。レコードの回転数の変動が音質悪化に直結しますから、回転が安定するようにターンテーブルを重くするとか、振動を避けるように設置するとか、気を使います。電気信号もアナログ技術の世界なので、ノイズが入らないようにして、アンプの周波数特性にも気を配らなければなりません。

愛好家はそこが楽しいのでしょうが、誰もがオーディオ機器にお金や時間を注ぎ込めるわけではありません。CDはLPに比べると、とても扱いが楽でした。音質がLPに比べて悪いと言われようが、圧倒的な使い勝手の良さを有していました。

それでも「出来る範囲」(←ここが重要です) で音質を改善したいものです。ちょっとした小技を駆使すると、音質が改善されると「主観的」に主張する意見がみられた記憶があります。例えば、「CDを冷やす(?)と良い」とか、「CDの周囲に緑色を塗っておけばよい」など、都市伝説のような小技を語るひとがいたように思います。

これらの小技でCDの音質が改善される理由としては、次のように理由づけていたような記憶があります。「これらの対処をすることで、CDに記録されたビット列の読み取り精度が向上するから、音質も良くなるのだ」というのです。 思わず「なるほど!」と思ってしまいそうな理屈ですが、そう簡単には納得できません。

 ひとまずCDに対処することで読み取り精度が向上することを認めるとしましょう(本当は、そこも真偽を確かめたいところではあるのですが)。CDはLPとは違うのでデジタル処理が最初に行われます。LPならレコード盤から音を拾うところが改善されれば最終的な音質もよくなるでしょう。しかしCDの場合は、読み取られたビット列が直ちにD/A変換されるわけでもないでしょう。エラー訂正やデジタル信号処理が行われたあとでD/A変換されるはずです。特にエラー訂正のことを考えれば、CDからの読み取り精度がちょっとくらい良かろうが悪かろうが、出力される信号には影響がないと思います。

電子回路の世界にとっては、デジタル信号と言っても結局はアナログ波形でしかないことは承知しています。またD/A変換が済んだ後は、LP時代と同じくスピーカーまではアナログ回路の世界であることも間違いありません。

愛好者的な立場では、際限なくお金を費やして、自分のオーディオ環境を作り上げていくことが面白くてしかたないのでしょう。それを否定する意図はありません。ただ主観的な評価ではなく客観的な判断が欲しいこと、そして費やせるお金には限りがあることを踏まえた意見が欲しいことを望んでいる気持ちがあるのです。


LightDM再考

Windows Vistaが入っているdynabook SS SX/15AのOSをNetBSD/i386に入れ換えようとしています。昔ならXにはtwmで良かったのでしょうが、さすがに地味すぎるので、MATEを使うつもりです。日本語環境は出来ていませんが、MATEが使えるところまでは確認しています。

この一ヶ月ほどはLightDMを使えるようにしようとしてきました。NetBSDのpkgsrcにはLightDMが取り込まれていません。WIPにはありますが、バージョンが古いし、いつになったら正式にpkgsrcに入ることになるのかわかりません。そこで自前でコンパイルし、これは無事に終わりました。しかし構成ファイルにどのような設定をしたらよいのか、よくわかりません。LightDMというのは、単純化して表現するとしたら(グラフィカルな)ログイン画面に過ぎないと思うのですが、それにしては設定項目が多すぎます。また「Seat」という概念も、なんのことやら見当もつきません。

Webで資料を探したり、LightDMのソースを読んでみたり、いろいろと試行錯誤すれば、結局はなんとかなるとは思います。問題は、それほど精力を傾けるべき対象なのか、ということです。しかも、今それをしなければならないのか、ということです。

LightDMは今風でカッコよいのですが、僕としては単なるログイン画面として使うだけになるでしょう。それならばxdmもあります。またコンソールでログインしてstartxするという手もあります。要するにLightDMが無くても代替策はいくらでもあるのです。

来春Windows Vistaのサポートが終了する前に、NetBSD/i386で環境を作り上げてしまわなくてはなりません。Windows Vistaで出来ていたことが全てNetBSD/i386+MATEでも出来てくれれば万々歳ですが、それを確認するには、まだまだ環境構築を進めていかなければなりません。LightDMに引っ掛かっている余裕はないのです。

とりあえず今はLightDMを脇において、NetBSD/i386の環境構築を先に進めようと思います。いずれ余裕が出来たら、LightDMを使ってみることにしましょう。

2016/11/26

大学の「グローバル化」と「出島オプション」

東京大学出版会の広報紙『UP』の2016年11月号に「留学生支援の場から見た日本の大学の国際化」(大西晶子)という文章が掲載されていました。文中では『中央公論』(第129巻第7号、2015年、pp.178-195)に掲載された「外国人教員から見た日本の大学の奇妙なグローバル化」(エドワード・ヴィッカーズ、ジェルミー・ラプリー)が参照されていました。どちらも興味深く読みました。

特に後者が言及していた日本の大学における国際化の将来は考えさせられました。3つの可能性があり、1)大成功、2)大失敗、3)出島オプションとのことです。そして最も可能性が高いのが3番目の「出島オプション」と考えているようです。

前者によると「出島」で表現することは、これまでの議論の中でもみられたそうです。江戸時代に長崎の出島にオランダ人を閉じ込めたことに基づく比喩表現ですが、わかりやすい例え話だと思いました。

後者で「出島」と表現しているのは、大学において外国出身者が阻害されている状況をあらわしているわけですが、これは大学にかぎらず企業でも同様の状況はあり得るし、同じ日本人でありながら正社員と非正規雇用者との関係においても同様の状況にあるのではないかと思います。それが顕在化していないかもしれませんが。

延々と「更新の確認」を続けるWindows VistaのWindows Update

dynabook SS SX/15AのWindows VistaのWindows Updateは延々と「更新の確認」を続けています。11月20日(日)の午後から「確認」し続けていますから、明日で一週間になります。何を確認しているのか不明ですが、プログラムのバグによる無限ループにしか見えません。

今年の春頃から遅くなり始めて、夏頃には「確認」に数日かかるようになり、秋が終わる今は「確認」が終わらなくなりました。今すぐWindows Updateを打ち切っても構わないとは思いますが、せっかくなので明日まではこのままにしておこうと思います。おそらく明日になっても同じ状況でしょう。

2016/11/22

Lisa Batiashvili演奏によるチャイコフスキー「ヴァイオリン協奏曲ニ長調作品35」

チャイコフスキー作曲「ヴァイオリン協奏曲ニ長調作品35」を聴いています。ソリストの違いにより曲の雰囲気が変わってくるところが興味深いので、CDをいろいろと買ってみて聴き比べています。

ショップの店頭で「チャイコフスキー&シベリウス:ヴァイオリン協奏曲[直輸入盤] 【CD】」を見つけました。発売日が2016年10月28日ということですから、出たばかりですね。

ソリストはLisa Batiashviliで、指揮者がDaniel Barenboimです。これまで買ったCDでは、タイトルやケースに出ているのはソリスト自身だけでした。ところがこのCDではダニエル・バレンボイムが登場しているので、それでいいのかと思わなくもありません。

演奏は、これまでに聴いてきたものとはアレンジが違い、独特です。これがソリストの発想なのか、指揮者の意向なのかわかりません。もしかするとお互いに話し合ったのかもしれません。噂に聞くところによると、ソリストと指揮者の主張が最後まで折り合わず「喧嘩別れ状態」で演奏会に臨んだ事例もあるらしいですから、曲に対する思い入れはかなりあるのでしょう。

独特のアレンジではありますが、そこが楽しいところでもあります。いろいろなソリストによる演奏を聴き比べると、それぞれの個性が際立って、また別の演奏も聴いてみたいと思うようになるのです。

2016/11/21

大阪堂島のアリラン亭「ユッケジャン鍋焼きうどん」の食べ方

大阪堂島にアリラン亭という韓国料理のお店があります。お店の関係者は韓国出身者が多いようです。お昼のランチメニューには「ユッケジャン鍋焼きうどん 」(950円)というものがあり、僕は必ずこれを注文します。かなり辛い料理で、以前は食べ終わると頭の中から汗が噴き出しているという感じでしたが、最近はそうでもないような気がします。日本人向けに味をマイルドに変えたのか、僕の味覚が辛さに慣れたのか、答えはわかりません。

韓国では食事に金属製の箸とスプーンを使うそうです。このお店でも韓国式のスプーンはありますが、お箸は日本風の割り箸です。

また、このメニューにはご飯がついてきますが、日本式のお茶碗ではなく、韓国で使う金属製の蓋つきの容器で出てきます。

さて問題はここからです。この「ユッケジャン鍋焼きうどん」をどのように食べたらよいのでしょうか。もちろん食べたいように食べれば良いというのは、その通りです。周りのお客さん(当然ほとんどが日本人)の様子を観察していると、日本の食習慣に従い、ご飯のお茶碗を持つような感じで、ご飯とスープを交互に口に運んで食べているようです。

これに対して別の方法があるのではないか、と思って僕は食べています。そしてそれこそが韓国における普通の食べ方ではないのか、とも思っています。もう何年も前にピースボートに乗船したとき、船内で親しくしていた韓国の方に教えてもらった記憶があります。その後ソウルに観光旅行で行ってきたときも同じような食べ方をしていたように思います。

実際にどうしているかというと、注文した料理が運ばれてきたら直ぐに、ご飯を全てユッケジャンの中に入れてしまい、よく混ぜて食べるという方法です。食べるときにはスプーンを主に使うので、お箸の出番はあまりありません。

こうい食べ方を日本では品がないとされていて、実行に移すのは勇気がいります。例えば吉野家で牛丼と味噌汁を注文し、丼に味噌汁を入れて混ぜて食べたら、それは無いだろうと僕も思います。しかし今から食べようとしているのは韓国料理なのです。韓国料理には韓国風の食べ方があるはずです。

この食べ方は間違っていないだろうと思っていますが、若干の後ろめたさも同時に感じていました。すると、この窮状を救ってくれる救世主があらわれたのです。大阪の千里にある国立民族学博物館で『韓国食文化読本』というのを見つけたので買ってみました。同書の19ページには「クッパプ(국밥)・・・汁(湯)に入れて食べる」という項目があり、上述した食べ方は韓国ではおかしくないことが書かれていました。

これで安心して今後も「ユッケジャン鍋焼きうどん」を食べることができそうです。

2016/11/15

『戦争と平和』

文豪トルストイによる名作『戦争と平和』は昔から気になっていました。読んでみようと思いながらも躊躇していた理由は、かなりの長編なので読むには覚悟を要しそうだというのもありますが、おおまかなストーリーの流れを知らないので、先の見えない物語を読み続けられるか心配だったのです。

有り難いことにNHK BSプレミアムで2016年9月1日に映画「戦争と平和」が放映されました。この作品は1956年に制作され、オードリー・ヘップバーンがナターシャを演じており、3時間を超える大作です。どんな映画であっても描かれているのは監督のイメージする原作のエッセンスであり、原作そのものを余すところなく語られているとは限りません。そうだとしても、トルストイの『戦争と平和』の全体像が見えてきました。この映画は2017年1月1日の午前中にも放送されるようです。

さらにNHK BSプレミアムでは2016年9月25日から全8回でBBC制作ドラマ「戦争と平和」が放送されました。映画を見て予習したおかげでストーリーの展開が分かっていたので、安心してドラマを楽しめました。各回45分で全8回なので6時間あまりの作品です。1956年の映画の2倍くらいの時間がありますが、それでもストーリー展開が早く、原作ではもっと長々と描写されているんだろうと思いました。

『戦争と平和』では、大雑把にいうと、ナポレオンがモスクワに攻め込み「冬将軍」に負けた時代のなかで、ロシア貴族の家系に属するピエール、アンドレイ、ナターシャをめぐる人間模様が表現されています。『戦争と平和』について登場人物が多すぎるので読むのが大変だということをよく言われます。作品に登場させる人物を絞り込むか増やすのかは作家の裁量です。ナポレオンのロシア遠征という大きな問題を扱っていれば、登場人物が多いのはやむを得ないでしょう。

原作を読んでみる気になったので調べてみると新潮文庫岩波文庫から出ているようです。翻訳作品でありがちですが、訳が良いとか変だとかamazonなどにコメントがついています。青空文庫にあると良かったところですが、まだ作業されていないようでした。

ナポレオンのロシア遠征はロシア人の歴史にとって大事件であり、チャイコフスキーの「序曲1812年」も有名です。この作品は、ナポレオンを追い払ったロシアが歓喜に沸き、祝砲を打ち、教会の鐘が鳴り続けるなかで演奏が終わります。普通のコンサートでは大砲も鐘も楽器を使って摸倣するだけですが、極めて稀に本物の大砲を打ったり、本当に教会の鐘を鳴らす演奏があるそうなので、さぞかし迫力があることでしょう。いちど体験してみたいものです。

2016/11/13

スター・トーク2

National Geographic Channelで2016年11月5日から「スター・トーク2」の放送が始まりました。前回とは番組進行が微妙なところで違っていますが、大筋には変更ありません。番組進行役はNeil deGrasse Tysonです。彼は事前にゲストとの対談を済ませており、その様子をビデオで紹介し、それを発端にしてスタジオに呼んだゲストとの機知に富んだ対話を繰り広げます。

スタジオのゲストは2人で、ひとりはコメディアンで男性の場合も女性の場合もあり、限られたメンバが交替で出演しているようです。もうひとりのゲストは進行役のニールの同僚などが多く、たいていは博士号を持っています。

番組は公開収録スタイルを採用しており、途中で休憩を挟みながら番組を撮影しているようです。番組自身はCMを含めて1時間弱ですが、実際の収録が何時間なのかは不明です。

バラエティー番組のようなスタイルですが、話題は低俗ではなく、考えさせられる内容です。かと言って謹直な堅い内容ではなく、これがアメリカ人気質なのか、駄洒落が飛び交いながら番組が進むので、楽しく視られます。

Neil deGrasse Tysonは、子供の頃にCarl Edward Saganと会ったことがあるという逸話を持っています。カール・セーガンというと1980年に放映された「コスモス」で有名です。2014年には「コスモス:時空と宇宙」をNeil deGrasse Tysonが制作しています。

Star Talk Radio Show with Neil Degrasse Tyson」 というのが公式Webと思います。番組収録はニューヨークのAmerican Museum of Natural Historyでおこなっているようですし、Hayden Planetarium Programsとして「StarTalk: Everything You Ever Need to Know About Space Travel, Sci-Fi, the Human Race, the Universe, and Beyond」(September 27, 2016)という情報も掲載されています。いつかは番組の収録に参加して生の雰囲気を味わいたいものです。

Windows VistaのWindows Updateが遅いのは一体何を処理しているのか?

今年の春先よりdynabook SS SX/15AのWindows VistaでWindows Updateを行うと *異常に* 時間がかかるようになりした。それでも梅雨前くらいまでは1日くらい(それでも十分長いですが)で終わっていたものが、秋頃からは3日くらいかかるようになりました。延々と「更新プログラムを確認しています」のメッセージが出たまま処理が進みません。

Webで検索すると同じような状況に遭遇している事例は多いのですが、何が問題なのかはっきりしないようですし、確実に解決できる方法も見つかっていないようです。

TOSHIBAのオフィシャルサイトに情報番号:013596として「2016年11月以降に「Windows Update」で“更新プログラムを確認しています”メッセージのまま数時間画面が切り替わらない<Windows Vista(R)>」(更新日:2016年11月10日) という対処方法が掲示されました。対応機種にはdynabook SS SX/15Aも含まれています。さっそく指示されたとおりに対処してみましたが、状況は改善されていないように思います。お馴染みの「更新プログラムを確認しています」のメッセージが出たまま、もう数時間が過ぎています。おそらく数日間このメッセージを見続けるような「嫌な」予感がしています。

Windows Vistaは来春にはサポート期限を迎える予定ですし、世間的にはVistaは失敗作(僕はそういう印象を持っていないのですが) として扱われています。Windows Updateの更新が遅くても、積極的に修正しようとする状況にはないのかもしれません。

Vistaの利用者側としては、もう見切りをつけて他のOSに移行しているのでしょう。僕もNetBSD/i386に移行しようと環境を構築中です。しかしVistaを提供しているMicrosoftは、来春までサポートすると宣言しているので、投げやりな対応とならず最後まで誠実なサポートを続けてもらいたいものです。仮にVistaのユーザがいなくなったとしても、Microsoftがサポートを投げ出す理由にはならないはずです。

2016/11/11

LightDMとLightDM GTK+ GreeterにGNU Stowを適用してみる

pkgsrcを利用せずにLightDMとLightDM GTK+ Greeterをビルドするので、インストール先は/usr/localになります。何も対処せずにインストールしても良いところですが、今後の管理を考えてGNU Stowを利用してみることにしました。stow自体はpkgsrcにあったので、既にインストールしてあります。

stowを使うために気をつける点は次のとおりです。
  1. 管理用のディレクトリとして/usr/local/stowを作っておきます。 別のディレクトリでも構いませんが、いずれにしても指定したディレクトリをconfigureprefixオプションで指定することになります。
  2. configureでは必ずprefixオプションを「--prefix=/usr/local/stow/パッケージ名」のように指定しなければなりません。
まずstow対応にしてLightDMをビルドします。
# cd lightdm-1.20.0
# env CPPFLAGS='-I/usr/pkg/include -I/usr/X11R7/include' ./configure --prefix=/usr/local/stow/lightdm-1.20.0
# end LD_LIBRARY_PATH='/usr/pkg/lib:/usr/X11R7/lib:/usr/lib' gmake
# gmake install
次に同じくstow対応でLightDM GTK+ Greeterをビルドします。
# cd lightdm-gtk-greeter-2.0.2
# env PKG_CONFIG_PATH='/usr/local/lib/pkgconfig' ./configure --prefix=/usr/local/stow/lightdm-gtk-greeter-2.0.2
# gmake
# gmake install
さていよいよstowを使ってみます。まず手始めにLightDMに適用してみました。
# cd /usr/local/stow
# stow lightdm-1.20.0
# ll ..
total 2
lrwxr-xr-x  1 root  wheel   23 Nov 11 10:34 bin -> stow/lightdm-1.20.0/bin
lrwxr-xr-x  1 root  wheel   23 Nov 11 10:34 etc -> stow/lightdm-1.20.0/etc
lrwxr-xr-x  1 root  wheel   27 Nov 11 10:34 include -> stow/lightdm-1.20.0/include
lrwxr-xr-x  1 root  wheel   23 Nov 11 10:34 lib -> stow/lightdm-1.20.0/lib
lrwxr-xr-x  1 root  wheel   27 Nov 11 10:34 libexec -> stow/lightdm-1.20.0/libexec
lrwxr-xr-x  1 root  wheel   24 Nov 11 10:34 sbin -> stow/lightdm-1.20.0/sbin
lrwxr-xr-x  1 root  wheel   25 Nov 11 10:34 share -> stow/lightdm-1.20.0/share
drwxr-xr-x  3 root  wheel  512 Nov 11 10:31 stow
シンボリックリンクが張られることにより/usr/local/binなどにファイルがあるかのように見せかけることが出来ます。それは良いのですがbinディレクトリ自身がシンボリックリンクになってしまっています。このままでは他のパッケージに含まれるファイルを置けません。

どうしてものかと思いましたが、事前にパッケージに含まれるディレクトリを作っておくことにしました。これならシンボリックリンクが張られる対象はファイルだけになるので、複数のパッケージがあっても大丈夫でしょう。

stowなんかを使うのを止めてしまうという選択肢もあると思います。GNU Stowというものが期待していたよりも相当単純な機能しか提供していないツールでしたが、同様の仕組みを自前で作ることを考えれば、それなりに利用できるでしょう。stowで管理することにしても邪魔になるわけでもありませんし、もしかすると将来的には良かったと思える時がくるかもしれません。

結局次のようにして対処しました。
# cd /usr/local
# (cd stow/lightdm-1.20.0; find . -type d) | xargs mkdir -p
# (cd stow; stow lightdm-1.20.0)
# (cd stow/lightdm-gtk-greeter-2.0.2; find . -type d) | xargs mkdir -p
# (cd stow; stow lightdm-gtk-greeter-2.0.2)
GNU Stowには類似ツールがないのでしょうか。例えばGNU screenとtmuxのように、同じような機能を持つツールが複数あるのなら、使い比べてみたいものです。

2016/11/10

LightDM GTK+ Greeter 2.0.2のビルドに必要なexo-csource

LightDM 1.20.0のビルドは成功していますが、使うためにはグリーターというものが必要になるようです。Wikipediaではいろいろなグリーターが紹介されていますが、LightDM GTK+ Greeter 2.0.2を使うことにします。

configureを実行したらbin/exo-csourceが無いと言われてしまいました。Webで調べてみるとpkgsrc/x11/xfce4-exoに含まれているようです。そこでpkgsrcからx11/xfce4-exoをビルドしたのですが、依存関係にあるパッケージも入ってきてしまいました。

pkgsrcを利用する利点のひとつが「ビルドするために必要なパッケージも同時に入れてくれる」ことなので、依存関係にあるパッケージが入るのは構いません。しかし「こんなパッケージが必要なのか?」と思うものが入ることもあるので、もうちょっと何とかならないかとは感じています。今回入ったのは以下のパッケージです。ISBN云々というパッケージが入ってくるのですが、こんなもの要るのでしょうか。
  1. p5-Business-ISBN-Data-20140910.003nb1 Data for the p5-Business-ISBN package
  2. xauth-1.0.9         X authentication utility
  3. p5-Business-ISBN-3.003 Perl5 module to work with International Standard Book Numbers (ISBNs)
  4. p5-URI-1.71nb1      Perl5 Uniform Resource Identifiers class (URI, RFC 2396)
  5. libxfce4util-4.12.1nb2 Xfce basic library
  6. xfce4-conf-4.12.0nb4 Xfce client-server configuration storage and query system
  7. libxfce4ui-4.13.0nb1 Xfce widget library
  8. xfce4-exo-0.10.7nb2 Xfce extension library
余談ですが、FreeBSDにもportsというpkgsrcに類似した仕組みがあります。こちらもpkgsrcと同じように「依存関係の謎」によりインストールされてしまうパッケージがあります。僕が特に気になっているのは「パッケージが必要とするgccやLLVM/Clangのバージョンが決め打ちになっていて、いろいろなパッケージを入れていくと、次第に複数のバージョンのコンパイラーが入ってしまう」ことです。

exo-csourceがあればconfigureが通るかと思いきや「configure: error: Package requirements (liblightdm-gobject-1 >= 1.3.5) were not met:」というエラーが出てしまいました。エラーの補足説明で「Perhaps you should add the directory containing `liblightdm-gobject-1.pc' to the PKG_CONFIG_PATH environment variable」とあるので、環境変数で指定しておけば大丈夫のようです。

最終的に以下のコマンドにより/usr/localへのインストールが出来ました。
# cd lightdm-gtk-greeter-2.0.2
# env PKG_CONFIG_PATH='/usr/local/lib/pkgconfig' ./configure
# gmake
# gmake install

2016/11/07

「報告型の課題」となるレポートを書くときの心構え

放送大学(学部でも大学院でも)では学期の途中で通信指導という名の中間レポートの提出が義務付けられています。マークシート形式の場合もありますが、せっかく学んでいるのですから記述式(字数は1,000字前後)に挑戦したいものです。

厄介なのは、どんな課題であっても何かを調べてから書き始めることになるわけですが、調べれば調べるほど深みに嵌まる気持ちに追い込まれることです。何も調べずにレポートを書くのは学問を舐めていると思いますが、そうかと言って際限なく調べればよいというものでもないと思います。何かリミッターのようなものがないと、全精力を通信指導に注ぎ込んでしまうはめになります(現実性を無視した観念論的発想としては悪くないのかもしれませんが、日常生活では他にもやることがあるのです)。

論文の書き方について語った書籍は数多くありますが、僕が気に入っているのはNHKブックス [954]として2002年に出た『論文の教室 レポートから卒論まで』(戸田山和久)です。新版が出ているそうですが、そちらは読んだことがありません。

本書の文体は独特で、四角四面な畏まった記述を期待していると、腹立たしさを感じるかもしれません。しかし僕自身はとても参考になる本だと思っています。いろいろと参考になるところが多いのですが、今回のテーマにに関わるのは以下の箇所です(110ページから引用)。
ところで、学生から提出された報告型のレポートを読んで気づくのは、キミたちが「いろいろ調べてわかったことを書くのが報告型の課題だ」と 思っているのではないかということだ。えっ。違うんですか、という声が聞こえてくる。違うだなこれが。
あまり長々と引用してもしかたないので、続きは書籍を読んでもらいたい。何の方向性もないままに資料を集めまくって、何を書いたらよいのか分からなくなり、まとまりのない報告が出来上がると語られています。

これは非常に大切な指摘だと思います。インターネットで検索をかければ、真理も法螺も含めて山のような情報にアクセスできます。なんて幸せなんだろうと思えるのは一瞬だけで、その後には苦痛が待っています。

レポートに何を書くのか何のアイディアも浮かんでいない時点では、制約を設けずに大量の情報を集めるのも悪くないでしょう。しかしインターネット上には個人が1,000年生きても読み切れないほどの情報が溢れています。闇雲に情報を収集しても行き詰まるだけです。

情報を集めてみてレポートを書く種となりそうだなと(一瞬でも) 思った事柄が出てきたら、それを育ててみるべきでしょう。もしかすると執筆途中で何度も障害に行く手を阻まれそうになるかもしれません。しかしそれを乗り越えた先に、自分のオリジナルの着想で仕上げたレポートが待っているはずです。

lightdm-1.20.0の自前pkgsrc化は後回し

LightDM 1.20.0がビルドできたので、次は自前のpkgsrc化を図るつもりでしたが、考え直して後回しにしようと思います。LightDMを使おうとしている目的は「Windows Vistaがサポート終了となるのでdynabook SS SX/15AのOSをNetBSD/i386に入れ換えること」です。現状ではMATEが動きそうだという感触をつかんだだけで、Vistaの代替環境を構築するという最終目的はまだまだ先にあります。それなのに横道にそれてpkgsrcを作ることに意識を向けてしまうのは本末転倒でしかありません。lightdmはWIPにあるので、いずれlightdm-1.20.0に追いついてくれるかもしれないし、代替環境の構築が済んで時間的な余裕ができたらpkgsrc化に着手できるかもしれません。

lightdm-1.20.0のビルドは出来たものの、気になっていることがあります。ビルド中に「ld: warning: libintl.so.1, needed by /usr/pkg/lib/libgio-2.0.so, may conflict with libintl.so.8」という警告メッセージが出ていましたが、なぜかlibintl.soが重複しているのです。
/usr/local/sbin/lightdm:
    -lgio-2.0.0 => /usr/pkg/lib/libgio-2.0.so.0
    -lgobject-2.0.0 => /usr/pkg/lib/libgobject-2.0.so.0
    -lglib-2.0.0 => /usr/pkg/lib/libglib-2.0.so.0
    -lpcre.1 => /usr/pkg/lib/libpcre.so.1
    -lgcc_s.1 => /usr/lib/libgcc_s.so.1
    -lc.12 => /usr/lib/libc.so.12
    -lintl.1 => /usr/lib/libintl.so.1
    -lpthread.1 => /usr/lib/libpthread.so.1
    -lffi.6 => /usr/pkg/lib/libffi.so.6
    -lgmodule-2.0.0 => /usr/pkg/lib/libgmodule-2.0.so.0
    -lz.1 => /usr/lib/libz.so.1
    -lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
    -lxcb.2 => /usr/X11R7/lib/libxcb.so.2
    -lXau.7 => /usr/X11R7/lib/libXau.so.7
    -lgcrypt.20 => /usr/pkg/lib/libgcrypt.so.20
    -lgpg-error.0 => /usr/pkg/lib/libgpg-error.so.0
    -lintl.8 => /usr/pkg/lib/libintl.so.8
    -lpam.4 => /usr/lib/libpam.so.4
/usr/libにあるlibintl.so.1の他に/usr/pkg/libにあるlibintl.so.8があり、どちらも参照されています。どうしてこのようなことになるのでしょうか。

気持ち悪いので対処しておこうと思いましたが、同様のバイナリが他にもあるのを確認しました。例えば/usr/pkg/bin/mate-sessionもそうです。警告メッセージが出るくらいですから望ましい状態ではないのでしょうが、もしかすると実害はないのかもしれません。これも将来的に解決する課題ということにして、当面は放置します。

昔々は(2000年以前頃)Makefileなどを変更してビルドしたものですが、今はautoconfautomakelibtoolなどが整備されconfigureを利用するのが一般的です。さらに(つい最近知ったのですが)stowというのがあるそうです。これはconfigureを用いて/usr/local以下などにインストールされたパッケージを管理できるそうです。lightdm-1.20.0に使ってみようと考えています。

2016/11/04

LightDM 1.20.0を暫定的にビルド&インストール成功

LightDM 1.20.0のビルドが出来るように暫定的な対処を続けた結果、最後までビルドできるようになり、/usr/local以下にインストールできました。細かいところは省きますが、次のような問題がありました。
  1. Shared object "libXi.so.7" not found」というエラーが出る。 
  2. No rule to make target 'liblightdm-gobject-1.deps', needed by 'all-am'. Stop.」というエラーが出る。
  3. libsystem.c:29:21: fatal error: xcb/xcb.h: No such file or directory」というエラーが出る。
  4. libsystem.c:138:1: error: conflicting types for 'setgroups'」というエラーが出る。
1番目の問題は昨日から出ているものです。GNU libtoolを使っているようなのですが、「libtool --config」で確認すると「shlibpath_var=LD_LIBRARY_PATH」になっていました。shlibpath_varはマニュアルでは「The environment variable that tells the dynamic linker where to find shared libraries. 」と説明されています。要するに環境変数LD_LIBRARY_PATHを設定しておかなければならないという事なのでしょうか。この環境変数でパスを指定したらうまくいったので、正式な対処方法は不明ですが、暫定的にこの方法で対応します。

2番目の問題はLightDMが提供するビルド方法の問題ではないかと思います。提供されるtarballにはこのファイルが含まれているのですが「make distclean」をしたときに消されてしまうのですが、消してはいけないファイルなのではないでしょうか。当面は「make distclean」した後にtarballから復活させることにします。

3番目の問題はconfigureに関わる問題のようです。このファイルは/usr/X11R7/includeにあるのですが検索対象になっていないようです。非標準ディレクトリと見做されているのでしょうか。configure実行時に指定する環境変数CPPFLAGSに追加しておくことにします。

4番目の問題はGNU拡張とNetBSD標準との差異が原因と思われます。LightDMはLINUX上で開発されたと思われますが、NetBSDなどとの移植性に注意を払っていない印象を受けます。移植性を確保するというのは難しい課題であることは認めます。ややもすると自分の開発環境で問題なければ、それで良しとしてしまいがちです。この問題に対処するため「__NetBSD__」が定義されている否かで条件コンパイルするようにして暫定的な対処をおこないました。

以上の問題を解決し、以下のコマンドでビルドが成功し、/usr/local以下へのインストールにも成功しました。次はWIPを参考にして自前のpkgsrcを作ってみようと思います。
# cd lightdm-1.20.0
# env CPPFLAGS='-I/usr/pkg/include -I/usr/X11R7/include' ./configure
# end LD_LIBRARY_PATH='/usr/pkg/lib:/usr/X11R7/lib:/usr/lib' gmake
# gmake install

2016/11/03

LightDM 1.20.0をビルドしてみる

まず最初にLightDM 1.20.0を単独でビルドできるか試してみます。これが上手くいってからpkgsrc化をおこなおうと思っています。ビルドするためにはconfigureしてからmake && make installするわけですが、この場合のインストール対象は/usr/local以下になります。いろいろな問題が発生して、ビルドヲ正常終了するところまで辿りつけません。

いきなり次のような問題が発生しました。
  1. configure: error: libgcrypt not found」というエラーが出ました。
  2. NetBSD標準の/usr/bin/makeではビルドできませんでした。
  3. liblightdm-gobject/language.cでコンパイルエラーになりました。
  4. ビルド中に「ld: warning: libintl.so.1, needed by /usr/pkg/lib/libgio-2.0.so, may conflict with libintl.so.8」という警告が出ました。
  5. Shared object "libXi.so.7" not found」というエラーが出てビルドが止まりました。

1番目の問題は、pkgsrcでインストールされるディレクトリが/usr/pkg以下になっていることが原因だと思います。見つからないと訴えているファイルは/usr/pkg/libにあるのですが検索対象になっていないのでしょう。以下のようにしてconfigureを実行することで対処しました。
 # env CPPFLAGS='-I/usr/pkg/include' ./configure

2番目の問題はconfigureで生成されたGNU make 4.1を利用することで対処しました。これはMATEをビルドする時にインストールされたものです。

3番目の問題はWIPにあるパッチを参考にして対処しました。setlocale()の引数にLC_IDENTIFICATIOが使われていますが、これはGNU拡張なのでNetBSDには入っていません。WIPのパッチではコンパイル対象から外しているだけですが、当面はこれで凌ぐとしても、きちんと直すにはどうすれば良いのでしょうか。2012年10月30日付のバグ報告「lightdm-1.4.0 fails to build on uclibc due to LC_IDENTIFICATION undeclared」(Bug #1073080)がありました。問題は把握しているようですが、何の進展もありません。
--- liblightdm-gobject/language.c.org    2016-11-03 13:12:38.000000000 +0900
+++ liblightdm-gobject/language.c    2016-11-03 13:22:49.000000000 +0900
@@ -227,10 +227,16 @@
         if (locale)
         {
             gchar *current = setlocale (LC_ALL, NULL);
+#ifdef LC_IDENTIFICATION
             setlocale (LC_IDENTIFICATION, locale);
+#endif
             setlocale (LC_MESSAGES, "");

+#ifdef _NL_IDENTIFICATION_LANGUAGE
             gchar *language_en = nl_langinfo (_NL_IDENTIFICATION_LANGUAGE);
+#else
+            gchar *language_en = NULL;
+#endif
             if (language_en && strlen (language_en) > 0)
                 priv->name = g_strdup (dgettext ("iso_639_3", language_en));

@@ -270,10 +276,16 @@
         if (locale)
         {
             gchar *current = setlocale (LC_ALL, NULL);
+#ifdef LC_IDENTIFICATION
             setlocale (LC_IDENTIFICATION, locale);
+#endif
             setlocale (LC_MESSAGES, "");

+#ifdef _NL_IDENTIFICATION_TERRITORY
             gchar *country_en = nl_langinfo (_NL_IDENTIFICATION_TERRITORY);
+#else
+            gchar *country_en = NULL;
+#endif
             if (country_en && strlen (country_en) > 0 && g_strcmp0 (country_en, "ISO") != 0)
                 priv->territory = g_strdup (dgettext ("iso_3166", country_en));

4番目の問題は何をした時に出てきたメッセージなのかを突き止めなければなりません。確かに/usr/lib/libintl.so.1/usr/pkg/lib/libintl.so.8があります。しかし何をした時に出るのかが分からないと対処のしようもありません。

5番目の問題は本来出てはいけないメッセージのような気がします。問題となっているファイルは/usr/X11R7/lib/libXi.so.7として存在しているので、特別に何も設定しなくても参照できなくてはいけない筈です。ダイナミックライブラリが見つからない時には、環境変数LD_LIBRARY_PATHを設定するとか、ファイル/etc/ld.so.confを使うというのが常套手段ですが、それは非標準ライブラリを利用したい場合の話であってlibXi.soは違うのではないでしょうか。想像するに、configureで生成されたファイルの何処かでダイナミックライブラリの検索パスを壊しているような気がします。

Xディスプレイマネージャを利用するか否か

dynabook SS SX/15AのWindows VistaをNetBSD/i386に移行するためにMATEを使うつもりです。まだ日本語環境は整っていませんが、MATE自体は動くようなので今後の見通しは悪くありません。今は試験的に利用しているだけなのでコンソールでログインしてからstartxでMATEを起動しています。問題は今後もこれでいくかどうかです。

キャラクタベースでログインしてからウィンドウ環境に移行するのでは、まるでDOS+Windows 3.1の時代を彷彿させます。個人的に使うだけなのでこれでも構わないのですが、今風のLinuxではグラフィカルにログインするので、今のMicrosoft Windowsもそうですし、同じ環境を準備しておくことにします。もし使いにくければ、外すのはすぐに出来ることです。

さてディスプレイマネージャとして何を使うことにしましょうか。NetBSD/i386のインストールでXを入れたのであればxdmが入っているはずです。これは昔からありますが、最近は使っているのを聞いたことがありません。できれば当世風のディスプレイマネージャを利用したいと思います。

Webを検索すると言及されることが多いのがSLiMとLightDMです。しかし残念ながらNetBSDのpkgsrcには見当たりません。どちらもWIPにはありますが、何時になったら正式にpkgsrcに取り込まれるか見当もつきません。

試しにLightDMをビルドしてみましたが、問題ありませんでした。しかし環境を整えるための設定方法が分からず、いろいろと自前で設定しておく必要がありそうです。また使われているのが2012年8月30日リリースの1.3.3版というのも気になります。最新は2016年10月15日リリースの1.20.0版なので、かなり更新されているし、バグも取れているのではないかと思います。

一方でSLiMは問題がありそうです。そもそもビルドできませんでした。WIPで使われているのは2008年9月25日リリースの1.3.1版で相当旧いし、SLiM自体が2013年10月2日リリースの1.3.6版を最後に更新が止まっているようです。問題がないからメンテナンスしないのかもしれませんが、事情がよく分からないので今後の利用には不安があります。

当面はLightDM 1.20.0を自前でpkgsrc化してみようと思います。そしてマシン起動後にLightDMでログインできるようにして、ユーザ環境はMATEが使えるようにしてみるつもりです。そこまで出来ればWindowsの代替に近づくでしょう。そして日本語入力環境をインストールし、FirefoxやLibreOfficeなどの主要なアプリケーションが入れば実際に使える環境に近づきます。

2016/11/01

LightDMをpkgsrc/wipからインストール

ディスプレイマネージャとしてLightDMを入れておきます。これはまだWIPなのでpkgsrc本体には取り込まれていません。現状のファイルを別途入手してpkgsrc/wip/lightdmに展開しておく必要があります。

ビルドするために依存関係にあるパッケージが幾つかあるようですが、MATEをビルドしたばかりなので追加でビルドしなければならないパッケージはありませんでした。そのためあっという間にLightDMのビルドが完了しました。

ただしwipの制約なのかPKG_PATHが設定されているとビルドが異常終了してしまいます。これは環境変数を消しておけば問題ありません。

とりあえずlightdm-1.3.3nb1がインストールされたのですが、MATEと同じく、次に何をすればよいのか見当がつきません。

MATEのスクリーンショット

pkgsrcからMATEをインストールしましたが次に何をすればよいのか分かりません。よく分からないながらも~/.xinitrcの最後にexec mate-sessionを入れれば良いみたいです。

とりあえず無事に動いてくれました。

Webで検索した記事を読んでいるとDbusとかHALが必要だと出てくるのですが、まだ設定していません。それでも構わないのか、何か設定しなければならないのか、どちらなのでしょうか。謎です。

今はキャラクタベースでログインしてからウィンドウ環境に移行していますが、Microsoft Windowsのようにウィンドウベースでログインする環境にしてみようと考えています。それが使いやすいか否かは追々考えることにして、そのような環境を準備してみようと思います。

2016/10/31

pkgsrc/meta-pkgs/mateのビルドに成功

pkgsrc/x11/mate-appletsで発生したエラーを対処することでMATEのビルドに成功しました。途中で何度かエラーが出たりしたので連続してビルドできたわけではありませんが、全体として30時間弱ほどかかったと思います。pkgsrcから入れたものは1つしかない状態で始めましたが、MATEのビルドが終わった段階でpkg_infoで見ると242個のパッケージがインストールされていました。

/usr/pkgの下にあるファイルの容量は2G弱でした。/usr/pkgsrc/packagesにはビルドされたバイナリーのパッケージがあるので次にインストールする時に使えるでしょう。このディレクトリにあるファイルは500M強でした。

x11/mate-appletsでエラーになった時のメッセージは次のようになりました。ビルド中に同様のエラーがsysutils/mate-power-managerx11/mate-session-managerでも起きました。
libtool: link: cannot find the library `/usr/pkgsrc/x11/mate-applets/work/.buildlink/lib/libintl.la' or unhandled argument `/usr/pkgsrc/x11/mate-applets/work/.buildlink/lib/libintl.la'
このエラーメッセージではファイルが見つからないと訴えています。該当するディレクトリを調べてみたら、確かにファイルはありません。このディレクトリはシンボリックリンクだらけなので、次に考えることは、シンボリックリンクで参照しようしているファイルの実体が無いのか、シンボリックリンクが生成されないのが問題なのかを判断することです。

/usr/pkg/libの下にファイルが見つかったので、シンボリックリンクが出来ていないのが悪いのでしょう。このリンクが作られるためにはどうしたら良いのか分からないのですが、x11/mate-applets/Makefileで作られているだろうと思われます。Makefileを見てもどのように変更したら良いのか見えませんでしたが、work/.buildlink/lib/libintl.laというシンボリックリンクが出来ているパッケージのMakefileを参考にして、次のような変更を加えてみました。
--- x11/mate-applets/Makefile.org    2016-10-29 20:31:36.000000000 +0900
+++ x11/mate-applets/Makefile    2016-10-28 09:39:00.000000000 +0900
@@ -40,10 +40,14 @@
 REPLACE_PYTHON+=    invest-applet/invest/mate-invest-chart
 .include "../../lang/python/application.mk"

+BROKEN_GETTEXT_DETECTION=    yes
+USE_BUILTIN.gettext=    no # force use of pkgsrc gettext-lib
+
 .include "../../x11/mate-panel/buildlink3.mk"
 .include "../../x11/mate-desktop/buildlink3.mk"
 .include "../../x11/mate-settings-daemon/buildlink3.mk"
 .include "../../misc/libmateweather/buildlink3.mk"
+.include "../../devel/gettext-lib/buildlink3.mk"
 .include "../../devel/glib2/buildlink3.mk"
 .include "../../devel/libglade/buildlink3.mk"
 .include "../../devel/libwnck/buildlink3.mk"
この変更を行うことで、シンボリックリンクもできましたし、エラーも出ずビルドできるようになりました。ビルド中にエラーがでた他のパッケージも同様の修正を加えることで、エラーが消えました。

これでMATEがインストール出来たわけですが、動かすためにはどうすれば良いのでしょう。何か依存関係にあるパッケージを立ち上げておく必要はないのでしょうか。適当にコマンドをたたけば動くかもしれませんが、そのような場当たり的な対応は避けたいと思っています。まずはドキュメントに目を通してみようと思います。

pkgsrcにあるMATEは2016年4月8日リリースのMATE 1.14が使われていました。もうすでに9月21日にMATE 1.16が出ているので、バグ修正もされているでしょうし、できれば最新版にしたいところです。ただしpkgsrcの枠組みを外れて自前でビルドしてしまうと再びpkgsrcに追従できなくなってしまうので、pkgsrcが変わるのを待とうと思っています。

2016/10/27

pkgsrc/meta-pkgs/mate

pkgsrcにある「meta-pkgs/mate」を使ってMATE一式をビルドしてみます。NetBSD/i386をインストールしたばかりの環境でパッケージが何も入っていないため、ビルド中に依存しているパッケージを再帰的に辿り次々と依存パッケージがインストールされていきました。

順調にビルドしていくかと思いましたが、途中でエラーが発生してビルドが中断してしまいました。何が問題だったのか確認しておこうと思います。ひとまず「make -i」を使ってエラーで止まらないようにして最後までビルドを終わらせました。

依存関係のパッケージを含めたビルド時間は16時間ほどでした。また依存関係にある171個のパッケージがインストールされました。

今後はビルド中に起きたエラーの原因をつきとめ、「meta-pkgs/mate」のビルドが正常終了するようにしようと思います。そしてディスプレイマネージャ(SLiMを使おうと考えていましたが問題があるようなので、LightDMにしようかと思っています。)を入れて、マシン起動後にMATEの環境が使えるようにしたいと思います。

2016/10/26

packagesでインストールするか、pkgsrcから自前でコンパイルするか

MATEをpackagesからインストールしようと思いましたが、うまくいきません。原因ははっきりしませんが、幾つか問題点があります。
  1. MATEはwipからmeta-pkgsに2016Q2で取り込まれたそうなのですが、2016Q3には置いてありませんし、7.0.1にもありません。環境変数PKG_PATHを指定しておけば良いのかもしれませんが、以下の全てを指定しておくのか、ひとつだけにしておいた方が望ましいのか、判断に困ります。
    ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/i386/7.0.1/
    ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/i386/7.0_2016Q2/
    ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/i386/7.0_2016Q3/
  2. NetBSDのミラーサイトは日本にも幾つかあります。しかしpackagesを持っているサイトが少ないし、一部しかミラーしていないサイトもあります。packagesを全部ミラーしているのはftp7.jp.NetBSD.orgだけで、ここはJAISTが管理しています。学術機関なので闇雲に利用するのは憚かられます。もしくはマスターサイトftp.NetBSD.orgを利用することになるのかもしれません。
  3. pkg_add -v mate」としてインストールを試みると次のようなエラーが出てしまいます。エラーになる理由ははっきりしませんが、今後もいろいろとインストールしていくことになるのを考えると、今のうちに基本方針をはっきりさせておいた方が良さそうです。
    pkg_add: Can't process ftp://ftp.NetBSD.org:21/pub/pkgsrc/packages/NetBSD/i386/7.0.1/All/atril*: File unavailable (e.g., file busy)
    pkg_add: Can't process ftp://ftp.NetBSD.org:21/pub/pkgsrc/packages/NetBSD/i386/7.0_2016Q3/All/atril*: File unavailable (e.g., file busy)
    pkg_add: Can't process ftp://ftp.NetBSD.org:21/pub/pkgsrc/packages/NetBSD/i386/7.0_2016Q2/All/perl*: Non-recoverable resolver failure
    pkg_add: no pkg found for 'perl>=5.0', sorry.
    pkg_add: Can't install dependency perl>=5.0
既にコンパイルされたpackagesを使わないとなると、pkgsrcから自前でコンパイルすることになります。この方が融通が利くので便利ではありますが、コンパイルできない場合に問題を追及するのが大変になる恐れがあります。1年ほど前にSONY vaioにNetBSD/i386を入れて環境を整えようとしましたが、その時はpkgsrcからコンパイルしました。しかしコンパイルエラーが出た場合は原因追及や問題解決にかなり苦労した記憶があります。

現在dynabook SS SX/15Aに外付けHDDを接続して環境を構築している目的のひとつには、来年以降におこなう予定である内蔵HDDへのNetBSD/i386環境構築のための調査があるので、このためにも自前でのコンパイルに挑戦してみようと思います。

2016/10/25

NetBSD/i386でのXの設定

dynabook SS SX/15AにUSBで繋いだHDDからNetBSD/i386 7.0.1が起動するようになったので、次にXの設定をおこないました。

まず最初に次の手順で/etc/X11/xorg.conを作成します。
  1. X -configure」を実行すると/root/xorg.conf.newが出来ます。 
  2. 念のために「X -config /root/xorg.conf.new」でXが起動することを確認します。
  3. /root/xorg.conf.new/etc/X11/xorg.confにコピーし、日本語キーボードの設定などを変更しておきます。
このあとstartxで最も初期的な環境のXが動くことを確認しました。ところがXを落としてコンソールに戻ると次のようなエラーが出ていました。
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:            Couldn't lookup keysym
>                   Symbol interpretation ignored
> Error:            Couldn't lookup keysym
>                   Symbol interpretation ignored
Errors from xkbcomp are not fatal to the X server
キーボード絡みなので日本語キーボードのための設定に何か不備があるのでしょうか。この辺りの設定はWebで事例を探して見様見真似でおこなったので不具合がある可能性は捨てきれません。

どのように設定するのがNetBSDとして推奨されるのかドキュメントを確認しておこうと思います。そしてデスクトップ環境としてMATEを、ユーザログインのためにSLiMをpkgsrcを使って入れようと考えています。そこまでいければ、Windows Vistaの代替としての環境に近づくでしょう。

2016/10/14

NetBSD/i386の無線LAN設定

NetBSDに限らず、U*IX系OSで無線LANを設定するためには以下の2つの設定が必要です。
  1. wpa_supplicantで無線LANの接続を確立する
  2. DHCPクライアント(dhclientdhcpcd)でアドレスを割り当てる
wpa_supplicantを使うには/etc/wpa_supplicant.confを準備しておかなければなりません。設定自体は親機の設定を把握していればできるはずですし、設定できていさえすれば接続するのも簡単でしょう。以前SONY vaioで設定しようと試みましたが散々苦労した挙句に結局接続できませんでした。ログを出すようにすれば大量に出力されるのですが、その時は問題解決には役立ちませんでした。

無線LANの接続が確立したらDHCPクライアントでアドレスを割り当てます。Webで事例を探すとdhclientを使っている場合が多いので、まずこちらを使ってみました。

dhclientは設定ファイルを参照することもできるようですが、ファイルを用意しておかなくてもアドレスの割り当ては出来ます。コマンドラインで試してみたら簡単にIPv4アドレスが割り当てられました。結構簡単だと思い/etc/rc.confで有効にして再起動してみたら、何故かアドレスが割り当てられていません。処理中のログを出すようにしてブートさせてみました。上手くいけば下記のような結果が得られるのですが、ブート中はDHCPDISCOVERが何度も繰り返し出ていて、処理が終わる前に打ち切られてブート処理が進んでしまっているようでした。試しに/etc/rc.d/dhclientに手を入れて最後に60秒間スリープするようにしてみたところ無事にDHCPでアドレスが割り当てられるようです。これで解決したとは言えるのですが、正式にリリースされたファイルに手を加えるのは躊躇われますし、60秒という時間にも何の根拠もないので不必要に長すぎるのも面白くありません。
Internet Systems Consortium DHCP Client 4.3.0
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on BPF/wpi0/**:**:**:**:**:**
Sending on   BPF/wpi0/**:**:**:**:**:**
Sending on   Socket/fallback
DHCPDISCOVER on wpi0 to 255.255.255.255 port 67 interval 6
DHCPREQUEST on wpi0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.1.1
DHCPACK from 192.168.1.1
bound to 192.168.1.19 -- renewal in 5624 seconds.
NetBSD/i386には何故かdhcpcdというDHCPクライアントも入っていたので、こちらを使ってみました。オプションはいろいろあるようですが普通に使う分には何も指定する必要はなく簡単です。これはブート中であってもアドレスを取得してくれるので何も問題がありませんでした。

Webで見つけた情報ですが/etc/rc.confに以下の行を入れておく必要がありました。これが無いとdhcpcdであってもうまくいかないようです。これが何をするための指定なのか把握していないので、調べておこうと思います。
critical_filesystems_local="/var /usr"

NetBSD/i386のインストール中のネットワーク設定で無線LANの設定はできない

NetBSD/i386をUSBメモリからインストールするのであればネットワークを設定せずにインストールを完了させることができます。しかし最後の「Configure the additional items as needed.」でネットワークの設定を済ませておくこともできるのですが、はたしてこれは無線LANの設定もできるのか不安だったので調べてみました。

dynabook SS SX/15Aには有線LAN(wm0)と無線LAN(wpi0)の2つのインターフェイスがあるので、設定先として無線LANのインターフェイスを選ぶことはできます。しかし「Network media type:」を「autoselect」として処理を続けてもエラーが出てしまいます。
 Status: Command failed
Command: /sbin/dhcpcd -d -n wpi0
 Hit enter to continue
-----------------------------------------------------------
dhcpcd[229]: open `/var/run/dhcpcd-wpi0.pid': Read-only file system
dhcpcd[229]: version 6.7.1 starting
dhcpcd[229]: wpi0: executing `/libexec/dhcpcd-run-hooks' PREINIT
dhcpcd[229]: wpi0: /etc/wpa_supplicant.conf does not exist
dhcpcd[229]: wpi0: not interacting with wpa_supplicant(8)
dhcpcd[229]: wpi0: executing `/libexec/dhcpcd-run-hooks' NOCARRIER
mkdir: /var/run/resolvconf: Read-only file system
Failed to create needed directory /var/run/resolvconf
mkdir: /var/run/dhcpcd: Read-only file system
/libexec/dhcpcd-hooks/50-ntp.conf: cannot create /var/run/dhcpcd/ntp.conf.wpi0: directory nonexistent
dhcpcd[229]: script_runreason: /libexec/dhcpcd-run-hooks: WEXITSTATUS 2
dhcpcd[229]: wpi0: waiting for carrier
wpi0: fatal firmware error
dhcpcd[229]: timed out
dhcpcd[229]: exited
エラーメッセージには「wpi0: /etc/wpa_supplicant.conf does not exist」 と出てきているので、もしかすると無線LANの設定もできそうな気もしますが、メニュー等には見当たりません。

インストーラでNetBSD/i386を入れたあとでも、少なくともAFTERBOOT(8)に書かれているような対処はしなければなりません。必ずしも無線LANも含めたネットワーク設定をインストーラで済ませる必要はないので、インストーラで設定するのはrootのパスワードとか時間帯の設定くらいにしておこうと思います。

2016/10/12

ついにNetBSD/i386 7.0.1の起動に成功

パッチあてたUSB-HDDをdynabook SS SX/15Aに接続して電源を入れます。まずdynabookの起動デバイスメニューが出るのでF12を押してからUSBデバイスを選択します。

次にNetBSD/i386のMBRによってパーティション選択メニューが表示されます。ここまでは以前と同じ動作です。
Fn: disk0
1: NetBSD
2: PARAGON
ここでF1を押してNetBSDを起動させてみます。ところが「ERROR ?」というメッセージが出てしまいました。またしても駄目だったかと気落ちしましたが、何気なくリターンキーを押したところ、なんとブートメニューが表示されました。
>> NetBSD/x86 BIOS Boot, Revision 5.10 (from NetBSD 7.0.1)
>> Memory: 632/3398016 k

      1. Boot normally
      2. Boot single user
      3. Disable ACPI
      4. Disable ACPI and SMP
      5. Drop to boot prompt
     
Choose an option: RETURN for default; SPECE to stop countdown
Option 1 will be chosen in 0 seconds.

Option: [1]:      
一瞬目を疑いました。気持ちが混乱して、このメニューは何だろうと思いましたが、これこそ求めていたものでした。「1. Boot normally」を選択すると素直にNetBSD/i386 7.0.1が起動してくれました。

まだOSを入れただけですから何の設定もできていません。今後はネットワークやデスクトップ環境も構成してWindows Vistaの後継として利用できる環境を整えていこうと思います。ひとまず肩の荷が下りました。

NetBSD/i386のMBRにパッチをあててみる

何度もエラーに遭遇しながら、ようやくUSB-HDDにNetBSD/i386 7.0.1をインストールできましたが起動してくれません。パーティション選択メニューが出ているところを見ると、少なくともNetBSD/i386が提供するMBRに制御は移っているようです。

NetBSD/i386のMBRのソースを読んでみることにしました。もしかすると起動しない原因が分かるかもしれません。まずNetBSDのcvswebで公開されているmbr.Sを入手します。FreeBSD/i386のmbrに比べると、条件アセンブルの指定が多いのでロジックを追いかけるときに注意する必要がありそうです。

ソースを読む時の心構えというほどのことでもありませんが、動作している状況を意識してからロジックを追うようにした方が早く内容を理解できると思います。これまでMBRの動作を見ている限りでは、次のようなロジックになっていると想像できます。
  1. パーティション選択メニューを表示する
  2. キー入力を待つ
  3. 選択されたパーティションのPBRに制御を移す
1番目の処理はラベルbootsel_menuで始まるあたりがそうだと思います。そして2番目はラベルwait_key付近がそうでしょう。そしてキー入力があったらラベルcheck_keyに飛ぶので、ここを詳しく読んでみます。
/*
 * We have a keycode, see what it means.
 * If we don't know we generate error '?' and go ask again
 */
check_key:
/*
 * F1-F10 -> boot disk 0-9. Check if the requested disk isn't above
 * the number of disks actually in the system as stored in 0:0475 by
 * the BIOS.
 * If we trust loc 475, we needn't check the upper bound on the keystroke
 * This is always sector 0, so always read using chs.
 */
    subb    $KEY_DISK1, %al
    cmpb    0x0475, %al
    jae    boot_ptn
    addb    $0x80, %al
    pop    %dx            /* dump saved drive # */
    push    %ax            /* replace with new */
#ifdef NO_CHS
    xorl    %ebp, %ebp        /* read sector number 0 */
    jmp    boot_lba
#else
    movw    $chs_zero, %si        /* chs read sector zero info */
    jmp    read_chs
#endif
入力されたスキャンコードを変換してBDA(BIOS Data Area)の0x0475の値と比較しています。何故このロジックが必要なのか不明ですが、比較結果に問題がなければラベルboot_ptnに飛び、(何かが?)問題ならラベルboot_lbaread_chsに制御が移るようです。

ここはNO_CHSの定義で条件アセンブルされていますが、どうもNO_CHSは未定義のようなのでラベルread_chsの方が使われているようです。これは従来のCHS形式でINT 13Hを呼び出すので「8GBの壁」問題を起こす可能性がありそうです。これはセクタ0を読んで制御を移す処理のようなので、PCの観察者からするとパーティション選択メニューが再表示されるように見えます。これは僕が体験したエラー情況と整合します。つまり問題はjae boot_ptnで分岐しなかったことにあると考えられます。いったい0x0475に格納されている値が何だったのか知りたいところですが、デバッグ環境が無いのでこれ以上の調査はできません。

あまり推奨できる方法ではありませんが、バイナリエディタHxDを使ってjae boot_ptnjmp boot_ptnに変更するパッチをあてて対処しようと思います。i386は条件分岐命令jaeが0x73で無条件分岐命令が0xEBなので、該当アドレスが見つかれば対応できます。NetBSD/i386の環境があればスマートに作業できると思うのですが、あまり環境が整っていないので泥臭い方法で対処しました。

HxDでセクタ0の16進ダンプを見ながらmbr.Sを参照しつつハンド逆アセンブルして該当アドレスを見つけました。アドレスが分かれば変更するのは1バイトだけなので、すぐに出来ます。こういう荒業は何が起きるか分からないので注意に注意を重ねて実行しなければなりません。今回はUSB-HDDが潰れても別に構わないので、多少心理的負担は少なくてすみました。

いよいよパッチをあてたUSB-HDDをdynabook SS SX/15Aに接続して電源を入れてみます。今度こそ上手くいって欲しいものです。ここしばらくは、上手くいって欲しいと願いながら電源を入れて、エラーがでたりすることが多かったので、だんだん疲れてきました。

An operating system wan't found.

USB-HDDのパーティションの切り方を変えて再度NetBSD/i386をインストールします。もうインストール中のエラーは起きず、最後まで綺麗に実行されます。いよいよNetBSD/i386 7.0.1がUSB-HDDから起動に成功してくれるかと期待して、dynabookの電源を入れてみました。

セクタ0にあるブートメニューが表示されるのですが、何度押しても先に進まず、再起動を求めるメッセージが出てしまいました。
Fn: disk0
1: NetBSD
2: PARAGON
Fn: disk0
1: NetBSD
2: PARAGON

Fn: disk0
1: NetBSD
2: PARAGON

An operating system wan't found.  Try disconnecting any drives that don't contain an operating system.
Press Ctrl+Alt+Del to restart
パーティションの順番を変えて挙動が変化したところを見ると「8GBの壁」問題に関係することを疑わせます。しかしブートしてくれないのは困りものです。

USB-HDDをWindows上のHxDで覗いてみました。するとブートメニュー自体はセクタ0にある(NetBSDによってインストールされた)ものですが、最後に表示されている「An operating system wan't found.」で始まるメッセージは、2番目のパーティション(NTFSでフォーマットしてある256GBの領域)が出しているようです。HxDで覗くと2番目のパーティションの2番目のセクタにあるのが確認できました。

dynabookの電源を入れると、BIOSはUSB-HDDのセクタ0を読み取り、制御を移しているのは間違いありません。ブートメニューがでていることから判断できます。ここでF1を押すとNetBSDが起動するところなのですが、なぜか制御が移らず、ブートメニューに戻ってしまうようです。NetBSDの起動時の挙動を解説した参考資料があれば、この状況を追いかける参考になりそうですが、何か無いでしょうか。

いまさら「8GBの壁」問題?

dynabook SS SX/15AにUSBで接続したHDDにNetBSD/i386 7.0.1をインストールする作業を続けています。ようやくエラーも出ず、最後までインストーラーが実行されるようになりました。インストールされたUSB-HDD以外のUSB機器を外し、電源を入れ直してUSB-HDDから起動してみます。

 画面にUSB-HDDのセクタ0(MBR)のものと思われるメニューが表示されました。
Fn: disk0
1: PARAGON
2: NetBSD
ここでファンクションキーF2を押してみると、どういうわけか内蔵HDDのWindows Vistaが起動してきました。

今度は何が問題なのでしょうか。この現象から次のことが判断できます。
  • dynabook SS SX/15Aに接続したUSB-HDDから起動できた。
  • セクタ0にあるメニューが実行できた。
確証はありませんが、もしかすると「8GBの壁」の問題なのでしょうか。使用しているUSB-HDDの容量は1TBです。先頭に確保している256GBは万が一のためのバックアップとして「Paragon Backup & Recovery 2011 (Advanced) Free」でdynabook SS SX/15Aの内蔵HDDを全て保存してあります。NetBSDは次の領域に60Gを確保してインストールしたのですが、これが良くなかったのでしょうか。

昔(と言っても、ずいぶん前になりますが) はOSをHDDの前の方に入れておかないと起動しないことがあると言われていました。いまさらこのような現象に遭遇するとも思えないので他の原因を探ったほうが良いのかもしれませんが、思い当たる原因がないので出来ることをしてみます。

USB-HDDのパーティションの切り方を変更して、先頭60GをNetBSDに、次の256Gをバックアップ用としてみました。この状態で再びNetBSD/i386 7.0.1をUSB-HDDにインストールしてみます。

installboot: Old BPB too big. use -f (may invalidate filesystem)

NetBSD/i386インストールの試行錯誤を続けています。newfsに失敗する問題が解決してインストールが先に進むと思ったら、またしてもエラーで中断されてしまいました。

「Bootblocks selection」 というメニューで「Use BIOS console」を選択したところ次のようなエラーでインストールが中断しました。
 Status: Command failed
Command: /usr/sbin/installboot -o console=pc,speed=9600 /dev/rsd0a /usr/mdec/bootxx_ffsv2
 Hit enter to continue
-------------------------------------------------------
installboot: Old BPB too big.  use -f (may invalidate filesystem)
installboot: Set bootstrap operation failed
この問題を解決するためWebを検索してみると次のような情報がありました。
  1. installboot: Old BPB too big, use -f (may invalidate file system)
  2. Wondering about the old "Installboot Old BPB is too big" issue
1番目の情報はNetBSDのメーリングリストCurrent-Usersに2015年1月15日に流れたものですが、この応答で次のような回答がなされています。
You didn't say where wd0a is located, a wrong disklabel might cause it to overlap some of your NTFS partitions. But if you are sure that you don't accidentally overwrite some innocent valid bootblock, then using installboot -f to clean the old BPB is the right thing to do.
古いBPBを綺麗にするためinstallboot -fをするのは適切だと言っています。そのアドバイスに従い、インストーラの中からシェルに落ちて、エラーで失敗したコマンドにオプション-fを加えて実行してみました。

この後改めてインストールをやり直したところ、エラーを出すことなく最後までインストーラが実行されました。