2017/01/31

TiddlyWikiを使った情報管理

TiddlyWikiというWebブラウザ上で使えるアプリケーションがあります。Wikiと呼ばれるシステムがあり、ウィキペディアでは次のように説明されています。
ウェブブラウザを利用してWebサーバ上のハイパーテキスト文書を書き換えるシステムの一種である。
これを個人利用に特化したのがTiddlyWikiだと言ってもよいと思います。JavaScriptを駆使して機能が実現されています。全ての機能と利用者が記録する情報がひとつのファイルにまとめられますので、電子的なメモ帳として手軽に利用することができます。

日本語版ウィキペディアに「TiddlyWiki」というエントリがありますが情報が更新されていないようです。最新版が2.8.1となっていますが、これは既に旧いバージョンです。最新版は5.1.13でTW5と呼ばれています。旧いバージョン2.8.1はTWC (TiddlyWiki Classic)と呼ばれるようになりました。TWCとTW5とでは、見た目も機能を大きく変わっているので、TWCを基にした情報はTW5では使えない場合が多いです。

TW5をどのように使うのかはアイディア次第です。公式ページでは次のように紹介しています。
Use it to keep your to-do list, to plan an essay or novel, or to organise your wedding. Record every thought that crosses your brain, or build a flexible and responsive website.
情報を管理するための電子的な「大学ノート」や「情報カード」のようなものと言ってもよいでしょう。

例えば何かを調査したり、記録を残すために、専用の大学ノートを用意したりすることはないでしょうか。ただ残念なことに、まめに記録していくのは意外と大変な作業です。せっかく用意したノートなのに最初の数ページしか書き込まれておらず、ほとんどが空白のままになったノートが大量に放置されていたりしないでしょうか。こういう場合にTiddlyWikiを使うと、うまく情報を管理できるかもしれません。少なくとも僕は、こういう目的のためにTiddlyWikiを利用しています。

インターネットが発達した現代は「情報の洪水」と言われます。何かを調査しようとして、検索エンジンを使うと、役に立つ(かもしれない)情報が大量に見つかります。あとで参照するためURLを記録しておきたいところですが、たいていはブラウザのブックマーク機能を使うのではないでしょうか。またPDFとしてダウンロードできる情報が見つかることもあります。あとで参照するために自分のPCに持ってきておくことも多いでしょう。さらに自分の考えや課題などをメモ書きしたファイルを作ることもあります。こうして情報が次々に蓄積されていきますが、次第に何が何処にあるのか分からなくなってきて、同じような情報を何度も探し回るはめに陥るのです。

ブックマークにしろ、自分のPCのローカルディスクに保存していあるファイルにしろ、整理するためにはフォルダを作るのが定番です。しかし、ここで問題が発生します。
  1. 情報をフォルダに分類して記録するのは、思ったほど簡単ではありません。フォルダの階層を深くするほど分類が細かくなりますが、はたしてその細分化が妥当なのか否かは、容易に判断できません。分類をキチンとすることと、情報がキチンと管理されていることは、似ているようですが、別問題にすぎません。
  2. ある情報の分類基準を複数用意したい場合が、けっこうよくあります。フォルダを使って分類基準を構成してしまうと、このような場合に困ることになります。U*IXのシンボリックリンクを使えば、ひとつの解決策ではありますが、本質的な解決が図られたわけではありません。
  3. URLはブックマークで、ファイルはフォルダで、などと複数の手段を用いて管理すると、お互いの連携を持たせるのが難しくなります。
僕は何かひとつの課題を遂行する場合にひとつのTW5ファイルを準備するようにしています。直近の例では、「dynabook SS SX/15AのWindows VistaをNetBSD/i386に移行させる作業」の管理のためにもTW5ファイルを作っています。

この移行作業に際して実行したこと、上手くいったにしろ失敗したにしろ結果の記録、今後の方針やToDo事項、Webを検索して見つけた情報、ダウンロードして保存したPDFなど、あらゆる情報をTW5でまとめるようにしています。こうしておくことで、情報の実態は自分のPCのフォルダのあちこちに分散していたり、インターネットを介して世界中に分散していたりしても、TW5を通してアクセスできています。しかも情報のアクセス経路も何通りでも用意できるので、ある情報を無理やり何かの分類基準に押し込めなくても済むので、気軽に情報を整理して、もし具合が悪ければ、また気軽に変更することができます。

TiddlyWikiというものを知ったのは10年ほど前のことですが、当初は何に使えば良いものなのかイメージが湧きませんでした。それなのにWebで導入事例を読むと「こんな素晴らしいものはない」と絶賛する文章があったりするので、何が凄いのかさっぱりわかりませんでした。長年利用してみて、まだ使ったことのない機能も多いのですが、これが無くては情報管理は出来ないという気持ちです。今となっては、やはり 「こんな素晴らしいものはない」と思っています。

pkgsrcから入れたハズのパッケージの一部が無くなっている

dynabook SS SX/15AにインストールされたいるWindows VistaをNetBSD/i386に置き換えるための作業を続けています。サウンドデバイスが認識されない問題を解決するのは難しそうなので後回しにしようと思っているので、些細な不具合が残っているものの、ほぼ移行できそうな目処はつきつつあります。

pkgsrcからパッケージを新たに追加していたところ、既にインストールしておいたパッケージの一部が無くなっていることに気付きました。網羅的に調べたわけではありませんが、firefox、emacsなどが消えています。

何故このようなことになったのか、詳しくは調べていませんが、pkgsrcでmake updateをしたのが原因のような気がしています。

去年秋頃から年末にかけてNetBSD/i386の環境構築を試みていた時に使っていたpkgsrcは2016年10月下旬頃のものでした。今年に入ってからCVSでpkgsrcを更新しています。このため一部のパッケージのバージョンがあがっているのでmake updateで更新したりしていました。make updateをおこなうと、依存関係にあると判断されたパッケージがアンインストールされていきます。ところがmake中にエラーが起きてしまうと、パッケージが消されたままの状態になってしまうようです。

何が消えたのか把握できれば個別に入れ直せるはずです。しかし気づいたらポツポツとパッケージが欠けているので、何が無くなっているのか網羅的に把握できていません。今後のことも考えると、pkgsrcから入れたパッケージの履歴を残していくようにしておかないと、また同じような状況に陥ってしまいそうです。

2017/01/27

send-prしてみました

dynabook SS SX/15Aで動かしているNetBSD/i386でhdaudio(4)が認識できない問題を調べてきましたが、手詰まりになってきたのでsend-prしました。kern/51920として受け付けられたので、何か進展があるでしょう。もしかすると何もアクションを起こしてもらえないかもしれませんが、音が鳴らなくて寂しいというだけのことです。ノートPCのWindows VistaをNetBSD/i386に置き換えることに対して大きな影響を与える事にはならないでしょう。

iomem領域を強制的にすり替えてみたものの失敗

dynabook SS SX/15AにNetBSDを入れてみたところhdaudio(4)がアタッチに失敗します。同じマシンでUbuntuを動かしてみるとアタッチできています。PCIの情報をみても、NetBSDとUbuntuとではiomemのベースアドレスに違いがあり、そういものなのか、何かがおかしいのか、判断できずにいます。

NetBSDではiomem領域がコンフリクトしているようなので、カーネルに手を入れて強制的にUbuntuの場合と同じ領域になるように(言葉は悪いですが)誤魔化してみました。

その結果、多少処理が進みましたが、謎のエラーが増え、結局アタッチできません。
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi0 vec 0
hdaudio0: High Definition Audio version 255.255
hdaudio0: OSS 15 ISS 15 BSS 31 SDO 6 64-bit
hdaudio0: timeout stopping RIRB
hdaudio0: couldn't reset because RIRB is busy
hdaudio0: device driver failed to attach
小手先の対応では駄目なようです。

2017/01/25

PCIデバイスのBARの値がNetBSD/i386とUbuntuとで異なる

dynabook SS SX/15AでNetBSD/i386を使うとサウンドデバイスが認識されない問題を調べています。OSに含まれているPCI管理ツールを使って、そもそもどのように認識されているのかを探ってみました。

まずNetBSDのpcictlを使ってみます。すると以下の情報が得られました。
000:27:0: Intel 82801GB/GR High Definition Audio Controller (mixed mode multimedia, revision 0x02)
オプションを指定して更に詳細な情報を取得してみます。気になる箇所だけを以下に抜粋します。
Base address register at 0x10
  type: 64-bit nonprefetchable memory
  base: 0x0000000000000000, not sized 
また比較するために、Ubuntulspciでも情報を取得してみると、次のようになりました。
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02)
 Subsystem: Toshiba America Info Systems NM10/ICH7 Family High Definition Audio Controller
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 27
 Region 0: Memory at d2080000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: snd_hda_intel
 Kernel modules: snd_hda_intel
両者を比べてみると、BARに入っている領域の情報が、64bitである事は一致していますが、開始アドレスが異なっています。NetBSDでは0なのに対して、Ubuntuではd2080000になっています。

デバッグ情報を見るためにextent_alloc_region()extent_print(9)を入れてみたところ、次のような出力が得られました。この関数の引数には、開始アドレス0で、サイズ0x4000が与えられています。そしてコンフリクトが発生するためエラーが返っています。要求されたのは0x0 ~0x3fffですから、既存の0x0 - 0x9dfffと衝突してしまうのでしょう。
extent `iomem' (0x0 - 0xffffffff), flags = 0x3
     0x0 - 0x9dfff
     0x100000 - 0xcf75ffff
     0xcf760000 - 0xcf760fff
     0xe0000000 - 0xe001ffff
     0xe0020000 - 0xe0407fff
     0xf00d8000 - 0xf00d8fff
     0xf00e0000 - 0xf00e0fff
     0xf00e2000 - 0xf00e2fff
     0xfed00000 - 0xfed003ff
     0xffd40000 - 0xffd7ffff
     0xffd80000 - 0xffdfffff
しかしBARで入っている情報では、64bitフラグが建っているようですし、Ubuntuのように0xd2080000が指定されれば衝突が発生することもなくなると思います。なぜNetBSDでは開始アドレスが0x0なのでしょうか。

そもそも同じハードウェアなのに、どうしてPCI情報を読み取った結果が異なるのでしょうか?

2017/01/23

hdaudio(4)がエラーを出す場所を調べてみる

dynabook SS SX/15AにインストールしたNetBSD/i386 7.0.2のhdaudio(4)でRealtek ALC262が認識されない原因を調べてみようと思います。調べてみても解決できるとは限りませんが、少なくとも何が問題なのか見えてくるでしょう。

エラーメッセージ「couldn't map mmio space」を頼りにカーネルのソースコードを探してみると、hdaudio_pci.cの中にあるhdaudio_pci_attach()しかありません。この中でpci_mapreg_map()を呼び出してエラーが返っているのでしょう。

pci_mapreg_map()/usr/src/sys/dev/pci/pci_map.cで定義されています。問題個所を絞り込んでみるとbus_space_map()がエラーを返しています。これは/usr/src/sys/arch/x86/x86/bus_space.cにありますから、さらに問題個所を絞り込んでいきます。するとbus_space_reserve()が怪しいようです。さらに中に入り込んで調べていくと/usr/src/sys/kern/subr_extent.cにあるextent_alloc_region()に辿りつきました。

このextent_alloc_region()の中でif (rp->er_end >= start)という判定を行っていますが、これに引っ掛かってエラーを返すようです。この時にrp->er_end9dfffstart0なので、条件が成立してしまうようです。

とりあえずここまでは調べましたが、これは一体なにが問題なのでしょうか。
  1. NetBSDのhdaudio(4)がRealtek ALC262に対応していないか、対応が不完全なのか。
  2. Realtek ALC262を使っているdynabook SS SX/15Aに起因する何かの問題なのか。
問題個所を突き止めるのは比較的容易ですし、その時の変数の値を見る事も簡単です。しかし本来どうあるべきなのかを考えるのは、どういう知識が必要とされるのか、現時点ではサッパリ見当もつきません。

どうすれば解決に至ることができるのか、考えてみようと思います。

dynabook SS SX/15Aのサウンドデバイスが認識されない

dynabook SS SX/15AのサウンドデバイスがNetBSD/i386 7.0.2では認識されません。ドライバはhdaudio(4)が使われるようですが、エラーが出ています。
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: couldn't map mmio space
ところがUbuntu 16.04ならば認識してくれます。
[   45.086615] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[   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
どうやらハードウェアはRealtekのALC262が使われているみたいです。Webを検索しても情報がないのですが、NetBSD 4.0で認識できているらしい「dynabookSS RX1/T7EにNetBSD4.0を入れる 」という情報を見つけました。どうやらドライバはazalia(4)のようです。

もしドライバをhdaudio(4)からazalia(4)に変えれば認識できるのであれば万々歳です、GENERICカーネルではazalia(4)をコメントで潰してありました。カーネルを作り変えて実行してみたのですが、やはり認識されません。
azalia0 at pci0 dev 27 function 0: Generic High Definition Audio Controller
azalia0: can't map device i/o space
カーネルのソースを見てみると/usr/src/sys/dev/pci/azalia_codec.cには「Realtek ALC262」という文字列が入っているので、対応しているハードウェアなのでしょう。また/usr/src/sys/dev/hdaudio/hdaudiodevsの中にもALC262という文字列がありますから、対応しているようですし、認識してくれても良さそうなものだと思うのですが、エラーになってしまいます。

2017/01/21

無線LANの設定を調整

dynabook SS SX/15Aには有線LANと無線LANのインターフェイスがありますが、基本的には無線LANを利用することにしています。これは無線なら場所を選ばずに利用できるからです。NetBSD/i386でも同様に無線LANを使って、これまでの作業をこなしてきた訳ですが、実は困った問題がありました。それは無線LANがとても不安定だったということです。

ftpでファイルを転送しようとしても、あっという間にstallするし、NFSを利用しようとしても反応が無くなるのは日常的で、pingを打ってもパケットがロストするのは当たり前という状況でした。とてもストレスがたまりました。

ちなみにNetBSDでネットワークのインターフェイスは次のように認識されています。まず有線はwm0として認識されています。
wm0 at pci1 dev 0 function 0: Intel i82573L Gigabit Ethernet (rev. 0x00)
wm0: interrupting at ioapic0 pin 16
wm0: PCI-Express bus
wm0: 64 words (8 address bits) SPI EEPROM
wm0: Ethernet address 00:15:b7:XX:YY:ZZ
そして無線LANはwpi0として認識されました。
wpi0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4222 (rev. 0x02)
wpi0: interrupting at ioapic0 pin 18
wpi0: JPN, address 00:19:d2:AA:BB:CC
wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
また無線LANの親機はcorega CG-WLRGNXです。2008年頃の製品ですが、これまで特別問題も起きていないので故障しているわけではないと考えています。

無線LANのトラブルとしてありがちなのは、親機との距離が離れているため電波が届かないか、弱くなっているのでないかという指摘です。しかし電波の強度を測定する計測器を持っていないので、確かめようがありません。

Webで情報を集めてみて、親機の設定を見直してみることにしました。またWindows VistaにはinSSIDerという評価の高いソフトをいれて状況を確認してみました。その結果、設定を変えてみたのは次の2か所です。
  1. 【ダブルチャンネル】自動設定→20MHz固定 
  2. 【チャンネル】自動設定→12
まず、これまで「ダブルチャンネル」を設定していたのは、その方が速度が出る(らしい)からです。ところがダブルチャンネルにすると複数チャンネルを使うため、かえって他の親機で使われているチャンネルとぶつかる可能性が高まり、トラブルを引き起こす原因になるとの事でした。そこでダブルチャンネルを使わないように設定しました。

またinSSIDerで確認すると、自動設定で選ばれたチャンネル6は他の親機でも使っているところでした。チャンネルの利用状況は刻々と変わると思うので固定化するのが最善とも限りませんが、ここはチャンネル12に固定することにしました。

このような設定変更をおこなって以降、きわめて快調です。ifconfigで確認すると、次のような状態でつながっているようです。
bssid 00:0a:79:xx:yy:zz chan 12
address: 00:19:d2:aa:bb:cc
media: IEEE802.11 autoselect (OFDM6 mode 11g)
2.4GHz帯のIEEE 802.11gですから決して高速ではありません。しかし個人的な考えとしては、トラブルが頻発する状態で規格レベルでは超高速であるより、規格的には低速でも安定してネットワークが利用できる方が重要であると思っています。

pkgsrcのdevel/cpuflagsを使うとエラーが出る

dynabook SS SX/15AにNetBSD/i386の環境を構築しています。pkgsrcを利用してコンパイルをおこなう場合のオプションを最適化してくれることを期待して「devel/cpuflsgs」を使ってみました。具体的には/etc/mk.confに次の行を追加します。必要なのは1行目だけらしいのですが、2行目も入れておくと御利益がありそうなので、追加しました。
.sinclude "/usr/pkg/share/mk/cpuflags.mk"
.sinclude "/usr/pkg/share/mk/optimize_gcc.mk" 
この状態でパッケージをコンパイルするとエラーが出てしまいます。詳細はconfig.logを参照せよとのことなので確認してみると次のエラーが記録されていました。
error: bad value (native) for -march= switch
cpuflagsを使うと「-mfpmath=sse -msse3 -march=native」というオプションが加えられるようです。3番目のオプションが悪いようですが、何が悪いのでしょう。

-march=nativeという指定が出来るのはgcc 4.2以降らしいのですが、NetBSD/i386のgccは4.8.4です。またmanを見てもnativeという指定が出来るように記述されています。

そうは言ってもエラーが出るものは仕方ないので回避策を考えてみます。dynabook SS SX/15AのCPUはCore Solo U1400 1.2GHzなのですが、この場合に-marchには何を指定すれば良いのでしょうか。Webを検索してみたら「Safe Cflags/Intel」という情報が見つかりました。どうやら「-march=prescott」と指定すれば良いようです。

結局/etc/mk.confには次のように書いておくことにしました。
CFLAGS+=    -mfpmath=sse -msse3 -march=prescott
.sinclude "/usr/pkg/share/mk/optimize_gcc.mk"

2017/01/19

mount_smbfsが不調→ファイアウォールを初期化したら解決

dynabook SS SX/15にNetBSD/i386の環境を構築していますが、Microsoft WindowsがインストールされているPC上のファイルを参照するためにmount_smbfsを使おうと考えています。昨年末に試してみたところ、なんとかなりそうな感触でした。

今年になって試してみたところ、マウントは出来るものの、それ以外のあらゆる操作が出来なくなっていました。何が悪いのか、NetBSD/i386側の問題なのか、それともMicrosoft Windows側の問題なのか悩みました。

試しにMicrosoft Windows側で利用しているMcAfeeパーソナルファイアウォール(Version:16.0 Build:16.0.126)を一時的に無効としてみたところ、問題の現象が解消しました。どうやらファイアウォールが悪さをしているようです。またWiresharkでパケットを確認すると、要求は届いているのに、応答が返らないようです。やはりファイアウォールがパケットを止めているのでしょう。

McAfeeのファイアウォールは、各種設定を利用者に開示するのではなく、ソフトウェア側で「よしなに」設定してくれるというコンセプトで出来ているようです。つまり詳細な設定をおこなう画面がありません。このようなコンセプトは、うまく動いている時には有り難いのですが、トラブルが発生した時には問題の原因に到達できず苦労します。まさに今回がその良い例です。

メニューにある「ポートとシステム サービス」を開いてみると、「Windowsファイル共有(NETBIOS)ポート137~139」という項目がありました。まさにこれが関係すると思われますが、すでにチェック済になっているので、おそらくポートは開いている「はず」です。

他にも設定を調べてみたり、Webで事例を探したりしましたが、解決に至りません。万策が尽きたのでメニューにある「デフォルトに戻す」というボタンを押してみました。独自の設定がほとんど無いのでデフォルトに戻しても差し支えないのですが、いろいろと設定を変えているならばデフォルトに戻すのは躊躇するかもしれません。

あらためてmount_smbfsを使ってみると、マウントできますし、その他の操作も問題ありません。先程までの苦労は何だったのかと思うくらいです。おそらくファイアウォール内部の情報がおかしくなっていたのでしょう。それらを利用者に見せないような構造になっているので、はたして何処が問題だったのかを明らかにすることはできません。

2017/01/17

XDM authorization key matches an existing client

dynabook SS SX/15Aに搭載されているWindows Vistaのサポート終了が目前に迫ってきました。去年末までに外付けHDDを利用して、NetBSD/i386やMATEなどの動作検証をおこなってきました。問題がないわけではなく、荒削りな個所がいろいろとあるのですが、移行してもなんとかなるだろうと見込んでいます。

昨年のうちにマシン起動後にxdmでログインできるように設定したのですが、何故かログインできたり、できなかったりする症状に悩まされていました。xdmはマシンを利用するときの入り口になるものです。これから個々のアプリケーションの動作検証を進めていく前に、xdmで差し障りなくログインできるようにしておこうと思います。

xdmでログインできないというのは具体的にどのような状況になるのか説明しておきます。xdmのダイアログウィンドウにユーザー名とパスワードを入力すると、MATEが起動しそうに見えるのですが、一瞬間をおいて、再びxdmに戻ってログインを求める画面になってしまうのです。なにかエラーが出ているのでしょう。ホームディレクトリの.xsession-errorsを確認すると「XDM authorization key matches an existing client」というエラーが記録されていました。

このメッセージが何を訴えているのか分からないので、Webで検索してみました。すると2014年にFreeBSDのメーリングリストに流れたメールが見つかりました。xdm-configに次の設定を追加すれば解決するそうです。
DisplayManager*authName: MIT-MAGIC-COOKIE-1
xdm-configはNetBSD/i386では/etc/X11/xdm/xdm-configです。設定を追加して様子をみると、問題は解決しているようです。ログインに失敗することは無くなった気がします。

問題が解決したのは結構なことですが、どうしてこれで問題が解決したのか理解できていないのは気持ちの悪い状態です。X関係は他にも仕組みを掴み切れていないところが多々あるので、全体像をしっかり把握しておきたいと思います。これは将来的な課題です。

2017/01/16

How difference between gaman and nintai?

I have read the essay "Sardines in a tin" written by Rebecca Quin in the Jan. 13 edition of The Japan Times ST.  She wrote that "there's this amazing sense of group gaman, I guess, a collective stoicism."  I have no idea whether Japanese people during rush hour in Tokyo have the sense of gaman or not.  But I can't stop thinking about the differences between gaman (我慢) and nintai (忍耐).

These words have almost same meanings.  They are used in the almost same situations. Strictly speaking, both words are not the same.  I can't come up with a good explanation.

2017/01/15

「高齢者の区分の提言」と「平均余命」

今年早々に日本老年医学会が「高齢者の定義 と区分に関する、日本老年学会 ・日本老年医学会 高齢者に関する定義検討ワーキングルプからの提言」を発表しました。現在は65歳以上となっている高齢者の定義を見直して65歳~74歳を准高齢者とし、「高齢者」と呼ぶのは75歳以上としてはどうかという提言です。この定義が社会に受け入れらて諸制度が変更されるのか、単なる話題で終わるのかわかりませんが、新聞の社説などにとりあげられているようです(例えば信濃毎日新聞では1月7日付で「高齢者「75歳」 安心の老後の基盤こそ」という社説を発表しています。)。

何歳から高齢者とするのかは統一した定義があるわけではありません。総務省統計局では65歳以上を高齢者として区分しています(高齢者の人口・世帯)。

ここでは65歳という年齢と平均余命(いわゆる寿命)との関係を考えてみたいと思います。参考にしたのは厚生省大臣官房統計情報部編集の『平成20年 簡易生命表』(ISSN 0911-8519)の「付録II 第1回~第20回 生命表(平均余命)」です。

0歳の平均余命は、第1回(明治24~31年)では男性42.8歳・女性44.3歳でしたが、第20回(平成17年)になると男性78.56歳・女性85.52歳にまで長くなっています。しかし注意しておきたいことは、明治期の寿命が50歳以下だったからと言っても65歳まで生きられないわけではないということです。

65歳 の平均余命を見てみると、第1回では男性10.2歳・女性11.4歳となっています。つまり75歳くらいまで生きているわけです。これが第20回では男性18.13歳・女性23.19歳ですから、79~86歳まで生存することが期待できるわけです。

ちなみに寿命が65歳を超すのは、男性が第11回(昭和35年)で 65.32歳、女性が第10回(昭和30年)で67.75歳のことです。

0歳の平均余命(寿命) と65歳の平均余命を比べてみると、寿命より長く生きていることがわかります。例えば第20回の男性の場合、0歳の平均余命は78.56歳ですが、65歳の平均余命は18.13歳なので83.13歳まで生存している訳ですから、約5年ほど寿命より長生きしています。女性の場合は、寿命自体は男性よりも長いのですが、比較した差をみると約3年ほど寿命より長いという値が出てきます。いずれにせよ男女とも65歳の平均余命は寿命よりも長い値になっています。ところが第1回では、寿命と65歳の平均余命による年齢との差は、30年強もあります。要するに0歳の平均余命は短い(50歳以下)にもかかわらず、65歳における平均余命は10年ほど残っているということです。

これは幼少期の死亡率が高いからだと言われます。それを生命表から読み取ってみます。第20回では男性において、0歳の平均余命は78.56歳、1歳の平均余命が77.79歳(つまり寿命78.79歳)、2歳の平均余命が76.83歳(つまり寿命78.83歳)、3歳の平均余命が75.85歳(つまり寿命78.85歳)、4歳の平均余命が74.87歳(つまり寿命78.87歳)、5歳の平均余命が73.88歳(つまり寿命78.88歳)、10歳の平均余命が68.93歳(つまり寿命78.93歳)です。つまり寿命はほぼ78歳で変わらないわけです。

ところがこれは第1回ではだいぶ様子が違います。おなじく男性をみると、 0歳の平均余命は42.8歳、1歳の平均余命が49.2歳(つまり寿命50.2歳)、2歳の平均余命が50.5歳(つまり寿命52.5歳)、3歳の平均余命が51.0歳(つまり寿命54.0歳)、4歳の平均余命が51.0歳(つまり寿命55.0歳)、5歳の平均余命が50.7歳(つまり寿命55.7歳)、10歳の平均余命が47.5歳(つまり寿命57.5歳)です。0歳の平均余命は42歳くらいなのに、1歳では寿命が50歳近くになっています。要するに生まれてすぐに亡くなる子供が多く、統計上の平均値を下げているということでしょう。

七五三というのは子供の成長を祝うという意義がありますが、今日ではあまり実感の伴わないかもしれません。しかし昔は無事に成長できるとは限らない時代でしたから、七五三を祝うことができたのは、とても嬉しいことだったに違いありません。

2017/01/13

NHK「ラジオ英会話」の対話で使われた文を素材に英借文を考える

NHK「ラジオ英会話」(2017年1月11日放送)で使用された対話の中で次のような文が現れました。
J: It was so nice of you to take the time to make this delicious meal for me, Olivia.
J:オリビア、こんなおいしい料理をわざわざ僕のために作ってくれて本当にありがとう。
仮にこの表現を身につけて「英借文」に活用しようとしたら、どうなるのか考えてみたいと思います。

英作文するな、英借文せよ、と度々言われますが、では具体的にどうしたら良いのか噛み砕いて説明しているのは殆ど見たことがありません。よく見かけるのは、「キチンと復習すれば」とか、「丁寧に学べば」自ずからわかるはず、という説明です。こういう抽象的な説明で英語が出来るようになるなら苦労はありません。

 日本人が英文を組み立てるとしても、まず最初は母語である日本語で(意識はしていないかもしれませんが)言いたいことを考えます。上述した例文なら、下段の日本文の方を最初に思い浮かべることになります。その次に英語表現に変換しようとして、ここで英借文が出てくるわけですが、上段の英文が導き出されることになります。もちろん別な表現の英文でも構わないのですが、それを言い出すと表現は無限に考えられることになってしまって、結局英借文の話が何処に行ったか分からなくなるので、ここでは上段の英文に辿りつくことにします。

ここで例示したような文を必要とする状況が、そもそも考えられるのでしょうか。長い人生の中で何回かはあるかもしれません。しかしピンポイントで日英の文を一対一で覚えておいたところで、活用できるシチュエーションは滅多に(もしかすると全く)訪れないに違いありません。

この例文を英借文として活用できるためには、文の構造を分析しておくことが第一歩になるでしょう。

文の後ろのほうにある「make this delicious meal for me」のところから見ていきます。「僕のために」が「for me」で、「こんなおいしい料理を作ってくれて」が「make this delicious meal」です。とくに理解に苦しむところはないでしょう。

文の中ほどにある「take the time to」は多少頭をひねります。ここは別売りテキストの中で語釈がされており「わざわざ(時間を割いて)・・・する」と説明されています。僕の手持ちの辞書(アクティブ ジーニアス英和辞典)でも「take the time to do わざわざ時間を割いて・・・する」と書いてあります。

最後に文の始めのほうの「It was so nice of you to」を見ることにします。ここについても別売りテキストでは「・・・してもらって本当にありがとう」と説明しています。手持ちの文法書(総合英語フォレスト第5版)では「第7章 不定詞」の中の「3 不定詞の副詞的用法」の「4 「判断の根拠」を表す」として次のように説明しています。
kindのような人物評価を表す形容詞が判断の根拠を表す不定詞を伴う場合(中略) <It is [was] + 形容詞 + of + 人 + to 不定詞>「~するとは<人>は・・・だ[だった]」という形にすることができる。

さらに「5 不定詞の意味上の主語と否定語の位置」では「2 意味上の主語を示す場合」の説明として次のように書かれていますが、 「人物評価を表す形容詞とともに不定詞が用いられ(中略)る場合は、to 不定詞の意味上の主語はofの後の「人」である」とあります。
不定詞の意味上の主語を示す必要がある場合は、不定詞の直前にfor ~を置き、<for ~ + to 不定詞>の形にする。
 以上の情報を総合すると和文と英文の対応が理解できるようになりました。英文を基準にして和訳するなら、テキストに出ている日本語とは微妙に表現が変わり、「僕のためにわざわざ(時間を割いて)こんなおいしい料理を作ってくれるとは君は親切だ、オリビア」となるでしょう。

テキストに掲載されている日本文も和訳した文も、どちらが良い悪いという問題ではありません。ただしここで問題にしているような「英借文」をしようとしている場合は、ちょっと話が違ってきます。

上述した説明で見てきたように、英文は幾つかの小さな塊を組み上げて出来ています。日本文から英文に「英借文」の手法で変換するには、日本語の文の中のパーツが英語の文の中の一部分にうまく当てはまるような形に持ち込まなければなりません。これが英作文において度々指摘される「和文和訳」です。例えば『[はじめる編]英作文のトレーニング』(Z会出版)では「第1章 講義編 英作文の書き方を身につける」の最初に「SKILL 1 和文和訳する」ことを指導しています。

日本語で発想した事柄を、いきなり英訳しないで、いったん英語になりそうな形の日本語に変えてから英訳するという考え方は、とても納得のいく方法です。しかし闇雲に「和文和訳」しても、いろいろな可能性が出てきてしまって、どうしたらよいのか出口が見えなくなる恐れがあるのではないでしょうか。どういう英文に持ち込むのかという「落としどころ」がないままに「和文和訳」したところで、無限の可能性の前で立ちすくむだけです。

以上に述べてきたような事柄をうまく捌けるようになれば英文を書くのがうまくなるような気がしています。

2017/01/12

Windows Vista の月例更新は相変わらず「更新を更新しています...」が終わらない

2017年1月におけるWIndows Updateの月例更新 は「Windows Vista 用セキュリティ更新プログラム (KB3216775)」だけのようです。コントロールパネルから更新の確認をおこなうと、いつまでたっても更新の確認が終わらないので、指定された番号のKBを個別にインストールすることにしました。先月は、それでうまくいきました。

ところが今月はKB3216775をダウンロードして実行させると「Windows Update スタンドアロンインストーラ」 が「更新を検索しています...」という表示を出したまま先に進みません。なんだか、もう疲れてきました。

Windows Vistaのサポートが間もなく終了するのはMicrosoftの会社としての方針ですから、それをどうこう言うつもりはありません。しかしサポート期限を迎える前から、対応が雑になっていくのは気分が良くありません。

2017/01/11

"That's why ~"と"That's because ~"

英語表現で"That's why ~."と"That's because ~."の使い分けに混乱しているので、頭の整理を兼ねて書いておきます。

Webを検索してみれば同様の情報が幾つも見つかるのですが、例えば「原因と結果と That's why ...と That's because ...」という記事があります。要するに因果関係を考えてみれば、「原因の文. That's why 結果の文.」とか「結果の文. That's because 原因の文.」のようになるわけで、とくべつ難しい話ではないと思います。しかしどうもスッと頭に入らない感じなのです。

NHK「ラジオ英会話」の2016年10月31日放送分には、次のような対話がありました。ここでは「That's because ~.」が使われています。まず「My seat won't recline.」という結果を表す表現があります。そして「yor're seated in the last row of the cabin.」という原因を示す文が来ているので、これは理解できます。
H: My seat won't recline.
FA: That's because you're seated in the last row of the cabin.
同じテキストの2016年11月7日放送分には、次のような対話もあります。こちらは「That's why ~.」が使われています。「are your cowboy boots made from alligator skin?」というのが原因の文で、「they call me Gator.」が結果の文ですね。これも理屈どおりで、別に難しくもなさそうです。
H: Okay.  Say, are your cowboy boots made from alligator skin?
G: You got it.  That's why they call me Gator.
それでは何故スッキリ理解できないのでしょうか。英語の勉強はスポーツのようなものだと言われることがありますが、それが関係しているのでしょうか。外国語を学ぶとき、理屈抜きで覚えてしまう子供を除けば、クドクドと理屈を並べて理解するのが先行します。そうして納得しないと頭の中の回路が繋がらないからですが、それだけで終わってしまっていては応用が利きません。

次に必要なのは練習でしょう。ただし練習して覚えなければいけないのは、どのような状況で「That's why ~.」と「That's because ~.」の どちらを使うか身につけることです。単純に英単語やイディオムなどを暗記することよりは、難易度が高い気がします。

2017/01/08

looking for a way to improve the skill for writing English

After years of learning English, I've finally decided to use this blog as a practice field.  I intend to use the way of 英借文.  I wrote the first sentence using an essay of The Japan TImes ST as a reference.

2017/01/06

ダブルカツ丼

函館には「ラッキーピエロ」というチェーン店があります。函館市内が多いですが近郊にもあり、17店舗あります。各種ハンバーガーがメニューに並んでいますが、ハンバーガー専門店と言ってしまうのは違和感があります。カレーとかカツ丼もメニューにあるからです。

それぞれの店舗の内装も独特なので好みの分かれるところです。

これまではハンバーガーをテイクアウトで注文することが多かったのですが、店内でカツ丼を食べてみることにしました。普通のカツ丼が500円くらいでしたが、ダブルカツ丼というのもあり1,000円弱だったので、どんなものか不明でしたがダブルカツ丼を注文してみました。

ダブルカツ丼というのは恐らくカツ丼の大盛りということだろうとは思っていましたが、注文が来た時あまりの巨大さに、驚き、かつ周りの視線が気になりました。実際には他人は人の注文のことなど気にしませんが、観光客も多い店なので珍しそうに見てくる人もいないわけではありません。視線が痛いのは覚悟しておいた方が良いかもしれません。

不通のカツ丼なら普通のドンブリだと思いますが、ダブルカツ丼の器はドンブリというようなものではありません。テレビを見ていると寺院の伝統的行事として「大茶盛式」の様子を放映していることがあります。これは大きな茶碗を使い、一人では持ち上げられず隣の人に手伝ってもらいながら喫茶する儀式ですが、そこで使われている茶碗を想像してもらえれば、中らずと雖も遠からずというところです。

ダブルカツ丼なのでトンカツはダブルですが、ご飯の量は大盛り相当ではなく普通だった気がします。お腹を空かせて行ったので、残さず食べられました。

2017/01/04

青函フェリーで函館から青森へ

北海道から本州に戻るために「青函フェリー」を利用してみました。函館と青森の間は津軽海峡フェリー株式会社が 運行する「津軽海峡フェリー」と、共栄運輸株式会社と北日本海運株式会社が共同運航する「青函フェリー」があります。どちらも毎日8往復しており、さらに深夜便もあります。フェリー乗り場が街の中心部から外れているのは仕方ないところです。ただし深夜便をうまく使えば、青森や函館で一泊してから北海道新幹線で移動するよりも、時間を有効に使えます。

今回は青函フェリーを利用しました。函館23時30分発、青森3時20分着です。鉄道と違って、乗船手続きや下船待ちなどがありますし、JR函館駅やJR青森駅などからの移動時間も考えておかなければなりません。

事前に予約を入れた際に乗船手続きを23時までに完了させるように言われていました。当日は札幌方面からJRで函館に19時15分頃に戻ってくるつもりでいました。夕食をとって、休憩しても、時間はたっぷり残っているはずでした。

地図を見ると函館市の西側の海沿いにフェリーターミナルがあるようです。JR函館駅からでも歩いても行けそうでしたが、「北海道&東日本パス」を持っているので楽をして、JR五稜郭駅から歩くことにしました。

函館20時15分頃に乗車して五稜郭駅で下車しました。駅は線路の東側にあります。駅を出て右手に行くと、角に五稜郭駅前郵便局があるので、そこを曲がり跨線橋を渡ると駅の西側に出られます。そのまま道を直進すると、国道227号線(大野国道)に出られます。

地図で確認したところでは、フェリーターミナルは国道沿いに北上したところのはずでした(実はこれが勘違いだった)。今年は積雪が全くなく、歩いても足元の心配はありませんでした。ひたすら歩いて行くと、遠目にフェリーらしき姿が見えてきました。JR五稜郭駅を出てから30分ほどしかたっていないので、思ったほど遠くなくて良かったと(安易に)考えていました。

ところが近づいてみると、そこは津軽海峡フェリーの乗船場でした。どうも青函フェリーはここではないようです。青函フェリーの乗船場を探して、さらに北上を続けることにしました。

歩き続けていると、函館市を抜けて北斗市に入ってしまいました。「函館港は北斗市にあるんだろうか?」と意味のない疑問が頭をよぎります。「新東京国際空港」が千葉県にあるような例も考えられるので、「函館港」が北斗市にあっても構わないのですが、楽観的な気分が不安に変わってきました。

さらに歩き続けていると、道南いさりび鉄道の七重浜駅の近くまで来ていました。しかも行けども行けども、周囲は暗く、海沿いを見渡してもフェリーの灯りが見えません。胸を冷やりとするようなものが通り過ぎていく気がしました。

幸いにもコンビニがあったので、念のために印刷しておいた地図を見せて、現在場所を教えてもらうと、想定していたよりも遥かに遠くまで歩いて来てしまっていることが分かりました。 急いで来た道を戻ることにしました。

ずっと北上してきた道を函館に戻って南下していると交番がありました。最近は無人の交番が増えていますが、パトカーが停まっているので誰かいそうです。「青函フェリー」の乗り場を探していると尋ねると、すぐ近くにあると教えてくれました。次の最初の信号を海側に曲がったところだそうです。先程までずっと歩いてきたのに、そんなものあったかなと思いながら、教えてもらったとおりに行ってみました。しかしそこは津軽海峡フェリーの乗り場でした。

もしかすると共同で利用しているターミナルなのかもしれないと思い、建物に入ってみましたが、青函フェリーとは無関係のようです。係員に尋ねてみると、青函フェリーのターミナルは別の場所にあると親切に教えてくれました。どうやら交番で教えてくれたのは「青森と函館を結んでいるフェリー(いわゆる青函連絡フェリー)の乗り場」だったようです。津軽海峡フェリーも「青函連絡フェリー」のひとつですが、青函フェリーとは違います。

道に迷って不必要に歩き続けていたので、この時すでに22時近くになっていました。乗船手続きの期限は23時と言われているのでまだ余裕があります。もし函館でノンビリ休憩していたら、もう間に合わなかったでしょう。危ないところでした。

いそいで道を戻ってくると青函フェリーターミナルの所在を示す看板が見つかりました。よく見ると、ここはJR五稜郭の駅を出た後で国道にぶつかった交差点でした。間抜けな話ですが、よく周りを見ていれば、不必要に遠くまで歩かなくても良かったということです。確かに青函フェリーのターミナルは、ここのそばにありました。

青函フェリーは予定通りに青森港に到着しました。

青森では雪が降っていました。降り方は強かったものの、積雪が殆どありませんでしたので、傘を差せば歩くのには不自由はありませんでした。フェリーターミナルから青森駅まで歩きました。道に迷うこともなく、順調でした。40分くらいで青森駅に到着しましたが、青森駅は夜間閉鎖されており、開くのは5時20分とのことです。

青森駅前には吉野家があるはずですが、最近は24時間営業をおこなっておらず、閉店時間帯でした。コンビニは開いていたので軽食を買い、それを食べながら青森駅の入り口前で開くのを待っていました。積雪もなく、風もない穏やかな夜だったのが幸いでした(気温は低かったのですが)。数年前に急行はまなすに乗車するため青森駅のホームに並んでいたときの記憶では、積雪も多く、強風が吹いていて、凍死するんじゃないかと覚悟したのを思うと、雲泥の差でした。