「御名前様」は「御御御付」である

文豪として著名な夏目漱石の作品に『吾輩は猫である』があります。明治時代に書かれたので文体が古風ですが、日本語文法的には「吾輩」＝「猫」という関係が成り立っています。そう意味で標題が「御名前様」＝「御御御付」という事ではありません。しかし意識上の問題としてはイコール記号で結び付くのではないかと思います。

まず後半の「御御御付」とは「味噌汁」のことです。語源については諸説あるようですが、丁寧さを示す「御」が次第に重複していったようです。

さて前半の「御名前様」ですが、何時頃からか不明ですが、店頭などで名前を尋ねられる時に「御名前様を云々」と言われる経験をするようになりました。「名前」に「御」がついているだけでも十分に丁寧だとおもいます。ところが「御名前」という表現が当たり前になってしまうと、敬意が不足していると感じるようになったのでしょう。そこで何にでも「様」をつけておけば丁寧になるだろうという発想があるのかもしれません。

随分前のことになりますが、大学受験の際に受験会場の構内アナウンスで「受験生様」と呼びかけられた時には吃驚しました。最近では病院によっては「患者様」と呼びかけるところもあるようです。また施設でも「利用者様」のような表現をしているようです。

何にでも「様」をつければ良いというものではないだろうと（個人的には）感じているのですが、このような傾向は今後も続いていくのではないかと思います。将来は「様」だけでも足りなくて、もっと大仰な接辞がつくかもしれません。

現時点では、「御名前様」という表現はされるのですが、さすがに「御電話番号様」とか「御住所様」のような表現は出現していないようです。しかし、これも登場するのは時間の問題かもしれません。

yumの後継dnfがCentOS7.4で動作しない（CentOS7.9なら動く）

2020年12月8日にCentOSの方針転換が発表され騒ぎになっています（CentOSが開発方針を変更ーー「CentOS 8」は2021年終了、今後は「CentOS Stream」に注力）。気になりますが、発表が唐突ですし、反発も大きいので、別の方向性が示されるかもしれません。今後の動向に注意しようと思います。

それはさておき、CentOS7で使われていたコマンド「yum」は、CentOS8では「dnf」に置き換わることになっています。yumがPython3に対応できないことが理由です。CentOS7ではyumを使い続けることになっていますが、dnfをインストールすることも可能です。そこでCentOS7.4の環境にインストールしてみました。ところが実行するとエラーで動きません。

Traceback (most recent call last):

  File "/usr/bin/dnf", line 57, in <module>

    from dnf.cli import main

  File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in <module>

    import dnf.base

  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in <module>

    import libdnf.transaction

  File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in <module>

    from . import conf

  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in <module>

    _conf = swig_import_helper()

  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in swig_import_helper

    return importlib.import_module('_conf')

  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module

    __import__(name)

ImportError: No module named _conf

何が悪いのか分かりません。別の環境で試してみようと考えて、VirtualBox上にCentOS7.9を準備して、動かしてみました。すると、全く問題ありません。

CentOS7.4とCentOS7.9の中で何かが違うのでしょう。Webを検索してみたら「Centos Extras DNF incompatible with versions less than EL7.6 #827」という情報を見つけました。その解決策は次のようにすると書かれていました。

After installing/updating some related packages, resolved the "ImportError: No module named _conf" issue for me.

yum update python*

yum install dnf-data dnf-plugins-core libdnf-devel libdnf python2-dnf-plugin-migrate dnf-automatic

dnf is now working on a CentOS 7.5 box. Some packages might be unnecessary, but you have to try for yourself...

これで本当に解決するなら、それはそれで良いのですが、何故これで解決になるのか理解できません。なにしろ何が問題の原因なのか把握できていないからです。

状況を調査するため、エラー出力で指摘されているファイル「/usr/lib64/python2.7/importlib/__init__.py」にデバッグ情報を出力するロジックを加えてみました。するとCentOS7.4とCentOS7.9とでは結果が違います。

CentOS7.4では以下のようになりました。

('>>>', 'libdnf._conf')

('>>>', '_conf')

CentOS7.4では以下のようになりました。

('>>>', 'libdnf._conf')

('>>>', 'libdnf._module')

('>>>', 'libdnf._repo')

('>>>', 'libdnf._transaction')

('>>>', 'libdnf._utils')

('>>>', 'libdnf._smartcols')

更に、ファイル「/usr/lib64/python2.7/importlib/__init__.py」にデバッグ情報を出力するロジックを加えて状況を確認すると、次のことが分かりました。

1. CentOS7.4の場合、ファイル「/usr/lib64/python2.7/site-packages/libdnf/conf.py」の14行目で呼ばれたのが最初の行に相当し、2番目は16行目が呼び出し元のようです。
2. どうやら初回呼び出しで例外が起きているようですが、その詳細情報がわかりません。それを取得するロジックを加えてみると、「ImportError('/lib64/libmodulemd.so.1: undefined symbol: g_log_structured_standard'」であることがわかりました。

ちなみにファイル「/usr/lib64/python2.7/site-packages/libdnf/conf.py」の14行目とか16行目というのは、以下のようになっています。

    13          try:

    14              return importlib.import_module(mname)

    15          except ImportError:

    16              return importlib.import_module('_conf')

コマンド「ldd -r /lib64/libmodulemd.so.1」で確認しても、やはり同様のエラーになります。

undefined symbol: g_log_structured_standard     (/lib64/libmodulemd.so.1)

        linux-vdso.so.1 =>  (0x00007fffbf9b8000)

        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fa9b63d0000)

        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fa9b60be000)

        libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007fa9b5e9e000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa9b5c88000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fa9b58ba000)

        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa9b5658000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa9b543c000)

        libffi.so.6 => /lib64/libffi.so.6 (0x00007fa9b5234000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fa9b6881000)

だいぶ状況が理解出来てきたので、あらためてWebを検索すると「ローカルで動いてたpuppeteerがCentos7で動かにゃい」という情報が見つかりました。

この問題はパッケージ「glib2」を更新すれば良いようです。現状を確認してみると、CentOS7.4では「glib2.x86_64  2.50.3-3.el7  @anaconda」、CentOS7.9では「glib2.x86_64  2.56.1-7.el7  @anaconda」でした。CentOS7.4でコマンド「yum update glib2」を実行すると「glib2.x86_64  2.56.1-8.el7  @updates」になりました。

以上の処置をすませて、コマンド「dnf」を実行してみると、無事に動作してくれました。

放送大学教養学部「漢文の読み方('19)」の参考書としての『中国語の歴史』（著／大島正二）

放送大学教養学部で2020年第2学期は「漢文の読み方('19)」を受講しています。漢文を読むというと訓点の使い方の印象が強いのですが、本授業では品詞や文構造の説明が出てきます。こういう内容は、もしかすると高校の頃に習っていたのかもしれませんが、全然覚えていません。

漢文の品詞体系は、英語や日本語の文法の知識が参考になるような気がしますが、ちょっと独特だと感じます。前置詞を「介詞」とも呼ぶようですし、代詞（人称代詞、指示代詞、疑問代詞）と呼ぶことにも吃驚です。

頭を整理するために、何か参考となる書籍があるかと思って、近所の図書館に行ってみました。中国語の文法に関する書籍は見つかりましたが、現代中国語の文法と、「漢文」の文法は（全く異なるわけではないのでしょうが）同じなのでしょうか。

更に書棚を探していたら『中国語の歴史』（大島正二、ISBN978-4-469-23314-8）を見つけました。目次は次のようになっています。

1. 第1章　漢字の〈形〉のはなし
2. 第2章　漢字の〈音〉のはなし
3. 第3章　漢字の〈義〉のはなし
4. 第4章　中国語の〈文法〉のはなし

「漢字」は「形音義」を表しているとされていますし、さらに中国語文法の話題も取り扱っているので、本書は講義の参考として全体像を把握するのにピッタリである気がしています。

xfs_bmapで出力されるブロックは何処にあるのか

VirtualBox上にCentOS 7.4をインストールしています。ファイルシステムはXFSですが、LVMも使われているようです。

[root@centos74 xfs]# df -T -t xfs

Filesystem              Type 1K-blocks    Used Available Use% Mounted on

/dev/mapper/centos-root xfs   30385668 4715672  25669996  16% /

/dev/sda1               xfs    1038336  183468    854868  18% /boot

任意のファイルを作成し、コマンド「xfs_bmap」を実行すると、そのファイルの実体が置かれているブロック位置がわかりますが、これは具体的に何処なのでしょうか。

[root@centos74 xfs]# cat date.txt 

Fri Dec  4 09:54:58 JST 2020

[root@centos74 xfs]# xfs_bmap -v date.txt 

date.txt:

 EXT: FILE-OFFSET      BLOCK-RANGE        AG AG-OFFSET        TOTAL

   0: [0..7]:          30936616..30936623  2 (536104..536111)     8

コマンド「dd」を使って確認してみると、BLOCK-RANGEで表示されたのが実体のあるブロック位置という事のようです。

[root@centos74 xfs]# dd if=/dev/mapper/centos-root bs=512 count=1 skip=30936616 | strings

1+0 records in

1+0 records out

512 bytes (512 B) copied, 8.8025e-05 s, 5.8 MB/s

Fri Dec  4 09:54:58 JST 2020

ひとまず納得できましたが、LVMの論理ボリューム「centos-root」は、HDD上（VirtualBoxで実験しているので、仮想ディスクですが）にあるパーティションのひとつの中に構成されています。

[root@centos74 xfs]# fdisk -l /dev/sda

Disk /dev/sda: 34.4 GB, 34359738368 bytes, 67108864 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x000017ce

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *        2048     2099199     1048576   83  Linux

/dev/sda2         2099200    67108863    32504832   8e  Linux LVM

論理ボリューム「centos-root」から見たブロック位置は、パーティション「/dev/sda2」やHDD「/dev/sda」から見て、どのブロック位置になるのでしょうか。

LVMの構成情報はディレクトリ「/etc/lvm/backup」にあります。テキスト形式になっており、次のような情報が得られます。

# Generated by LVM2 version 2.02.171(2)-RHEL7 (2017-05-03): Mon Dec  7 10:05:56 2020

（略）

centos {

（略）

        physical_volumes {

                pv0 {

                        id = "NcNMF2-iNcr-jMVY-379Q-orOj-PHfL-DZU3BN"

                        device = "/dev/sda2"    # Hint only

（略）

                        pe_start = 2048

                        pe_count = 7935 # 30.9961 Gigabytes

                }

        }

        logical_volumes {

                swap {

                        id = "fWmF2u-VxqX-06BN-IZnx-e8FQ-NM6Y-THhGZk"

（略）

                        segment1 {

                                start_extent = 0

                                extent_count = 512      # 2 Gigabytes

（略）

                        }

                }

                root {

                        id = "qzxis0-iY72-OMfH-3psn-HV05-TDxi-c3VEF8"

（略）

                        segment1 {

                                start_extent = 0

                                extent_count = 7422     # 28.9922 Gigabytes

（略）

                        }

                }

        }

}

ここから次のことがわかります。

1. 論理ボリューム「centos-root」は、論理ボリューム「centos-swap」の後ろに置かれている。
2. 物理ボリューム「pv0」は、デバイス「/dev/sda2」の相対位置「2048」から始まる（pe_start = 2048）。

以上より次の計算をおこないます。

1. 論理ボリューム「centos-swap」は「extent_count = 512」なので、512バイトブロック単位に換算すると、4194304（= 512 * 8192）となります。
2. 物理ボリューム「pv0」は、パーティション「/dev/sda2」の先頭から2048離れた位置から始まっていることに注意が必要です。
3. 論理ボリューム「centos-root」にあるファイル「date.txt」のブロック位置「30936616」は、パーティション「/dev/sda2」から見るとブロック位置「35132968」（= 30936616 + 512 * 8192 + 2048）になるはずです。

この計算結果を確かめてみました。

[root@centos74 xfs]# dd if=/dev/sda2 bs=512 count=1 skip=35132968 | strings -tx

1+0 records in

1+0 records out

512 bytes (512 B) copied, 0.0211708 s, 24.2 kB/s

      0 Fri Dec  4 09:54:58 JST 2020

考え方は合っているようです。同じように考えれば、HDD「/dev/sda」から見たブロック位置も求められるでしょう。

「軍」に属しているのに「軍人」ではないメンバーを擁する団体

プロ野球チームのひとつである「読売ジャイアンツ」は「巨人軍」とも呼ばれています。当たり前のように耳にしますが、よく考えてみると、なぜジャイアンツだけ巨人「軍」と呼ばれているのか不思議です。「阪神タイガース」など他のチームは「○○軍」のような呼び方をしませんし、野球以外のプロスポーツも同様です。

このような疑問を抱く人は他にもいて、Webを検索したら「「巨人軍」だけなぜ「軍」が付く？ジャイアンツ誕生秘話」という記事を見つけました。要するにチームの成り立ちに由来するというのが答えのようです。

なぜ「巨人軍」と呼ばれているのか分かりましたが、ジャイアンツの所属選手は「軍人」とは呼ばれないのでしょうか。会社に所属しているのは「社員」ですし、学校の所属しているのは「学生」です。しかし「巨人軍」に所属しているのは（当然ながら）「軍人」ではないのです。

京阪のダブルデッカー

先日淀屋橋から京阪のダブルデッカーに乗車しました。京阪以外でも2階建て車両を運行している鉄道はありますが、ダブルデッカーというと京阪というイメージがあります。

カタカナで表記する「ダブルデッカー」というのは英語の「double decker」の事ですが、英語を日本語で表記する規則は微妙な例外があることに注意が必要かもしれません。

例えば「computer」をカタカナで表記する際に「コンピューター」とも「コンピュータ」とも表記します。長音「ー」は省略されることがあります。同様に「ユーザー」と「ユーザ」や、「サーバー」と「サーバ」があります。しかし常に長音を省略することができる訳でもないのが難しいところです。

さて「デッカー」は「デッカ」と表記できるのでしょうか。常識的には出来ないと思いますが、出来ない理由が存在する訳でもないと思います。もし省略できるとしたら、「ダブルデッカー」でも「ダブルデッカ」でも構わないことになるのですが、この両者が同じものとは感じられなくなります。そのポイントは、京阪が大阪に拠点を持つ鉄道会社である事にあるのではないでしょうか。

カタカナ文字で「ダブルデッカー」と「ダブルデッカ」を記述すれば、どちらでも構わない気がするかもしれません。しかし音声で聴くとしたら（音声には平仮名も片仮名もありませんから）「ダブルデッカー」と「ダブルでっか」となりかねません。

もっとも、ありがちな方言は現実には存在しないとも言われるので、語尾に「でっか」をつける方言は大阪には存在しないということになるのでしょうか。

海外書店に注文した古本は何処から届くのか

以前から洋書を購入する際に、古本でも構わないのであれば、AbeBooksを利用するようにしています。このサイトを使えば、古書店を個々にアクセスしなくても済むので、ずいぶん手間が省けます。日本にも「日本の古本屋」というサイトがあります。

今年の10月初めにAbeBooksを通じて米国の書店に注文を出しました。すぐに発送処理はされたようですが、COVID-19の影響で到着が遅くなるかもしれないと、メールで連絡が来ました。COVID-19の影響が各所に出ているのは理解できますが、どれくらい遅れるというのか見当がつきません。

注文した本は11月下旬に到着しました。約2ヶ月かかっていますが、どこで時間がかかってしまったのか、不思議です。もっと不思議なのは、注文した書店が米国なのに、到着した古本はスイスから発送されていることです。現代社会の物流は、国家の枠組みを外れて、世界規模で回っているという事なのかもしれません。

タブレットを用いた閉塞方式

昔の鉄道の仕組みを解説した文章を読むと「タブレット交換」の話題がでてきます。漠然としたイメージは持っているのですが、詳細な手順については知らないのでYouTubeで動画を見てみました。同じようなものは他にもあると思いますが、検索して偶々見つけた動画を見ました。

• 【解説付き】タブレット閉塞機,操作シーン。由利高原鉄道,矢島駅
  
• （非HD）清水沢駅でのタブレット交換
  
• タブレット閉塞機
  

率直な感想は「手順が難しい」です（慣れれば簡単なのでしょうが）。当時の技術水準を踏まえたシステムになっているのだと思いますが、とにかく人手をかけて運用されているという印象です。こんな手間をかけて閉塞をおこなっているようでは、現在の山の手線のような運行本数は確保できないでしょう。

ここで疑問が生じたのですが、タブレット交換の運用手順は、何時頃登場したのでしょう。また運用手順は最初から同様だったのでしょうか。イギリスで鉄道が誕生し、日本で明治初期に新橋横浜間で鉄道が始まった頃、閉塞はどうしていたのでしょう。おそらく数々の事故を起こした経験からシステムが出来上がっていったのではないかと思います。タブレット交換の歴史的変遷にも興味が出てきました。

ここで（馬鹿げていると思うかもしれませんが）「歴史のif」として、「もし東海道新幹線にタブレット交換閉塞方式が採用されていたら」という事を考えてみるのも一興です。真面目に考えれば荒唐無稽なのは分かりきっているので、ちょっとしたお遊びです。

駅ごとに停車していく列車ならば、駅員がタブレットを手渡しできます。しかし駅を通過する急行列車のような場合は、車両にタブレットキャッチャーが装備されています。同じような感じで、団子鼻で有名な0系新幹線の運転台の下にタブレットキャッチャーが装備されていると想像するのも「鉄道マニア」の夢物語としては悪くありません。

100分 de 名著「伊勢物語」

NHK Eテレで放送されている「100分 de 名著」で2020年11月に取り上げた作品は「伊勢物語」でした。伊勢物語というと「昔、おとこありけり。」という書き出しで有名ですが、実は作品を通読したことはなく、どのような作品なのか知りませんでした。

平安時代の作品であることは知っていました。同時代の作品としては『源氏物語』が有名なので、同じような感じなのだろうと思っていましたが、随分と様相が異なるようです。小説というよりも、和歌を主体として若干の詞書が添えられたもののようで、全体で125章段ありますが、とても短いので、表面的に読むだけなら時間はかからないでしょう。

岩波文庫から『伊勢物語』が出ているので買ってみようと思ったのですが、あいにくと近所の書店では在庫がありませんでした。その代わりに高樹のぶ子著『業平』があったので買ってみました。

『業平』は『伊勢物語』の翻刻や現代語訳ではなく、オリジナリティのある小説なので、『伊勢物語』を読むのとは違うと思いますが、また違った趣で楽しく読んでみようと思います。

NHK ＢＳ世界のドキュメンタリー「世界一豪華な刑務所の内側」

NHK BS1で深夜に「BS世界のドキュメンタリー」という番組があります。2020年11月24日に放送されたのは「世界一豪華な刑務所の内側」という作品でした。 これは2020年にイギリスの放送局が制作した作品で、ノルウェーにあるという豪華な刑務所をイギリス人が尋ねるという内容です。

刑務所というと、時代も国も違いますが、映画「ショーシャンクの空に」や「グリーンマイル」で描かれているようなものを想像します。多分世界の何処でも同じような感じでしょう。ところがノルウェーのハルデン刑務所は全然違っていて、まるでリゾートホテルのようです。

この刑務所には鉄格子が見当たりません。しかも刑務所内に音楽スタジオがあって囚人がラップ音楽の制作に励んでいます。他にも数々の設備が整っているようです。訪問したイギリス人は、信じられない、ありえない、を連発していました。

ただしノルウェーでは当たり前ということではないようで、実験的な位置づけではあるようです。

このような在りかたが妥当なのか否かは容易に判断できませんが、作品の中で刑務官が「私たちの役割は、囚人を貶めることではなく、社会復帰するのを手助けすることなのです。」と語っていた言葉は印象的でした。

Windows10 20H2に更新したら「タスクバーにピン留め」できるようになった

Windows10 20H2に更新したら、「タスクバーにピン留めする」が動くようになりました。

Windows10の最初の頃は、問題なく「タスクバーにピン留め」出来ていました。ところが、しばらく前の更新を適用したタイミングで動作しなくなり、困っていました。Webを検索すると、類似した問題を抱えている人がいて修正方法が書かれていることがありましたが、その手順をためしてみても解決できませんでした。

Windows10では「ピン留め」という動作は他にもあります。スタートメニューにも「スタートにピン留めする」というメニュー項目があります。こちらは問題なく動作していて、何故「タスクバーにピン留めする」だけが動かないのか、謎でした。

当初「タスクバーにピン留め」できていた頃には、極めて頻繁に利用するアプリケーションは「タスクバーにピン留め」しておいて、起動しやすくしていました。ところがピン留めできなくなったので、困った挙句、代替手段として「Quick Launch」を利用することで問題を回避していました。20H2に更新したことでピン留めできるようになったのは有り難いのですが、Quick Launchで起動することに慣れているので、再びピン留め方式に戻るか否か迷うところです。

Windows10を1909から20H2に更新

自宅で使用しているWindows10において、「設定」の「Windows Update」を先日確認したところ20H2への更新がアナウンスされていました。20H2はマイナーチェンジらしく、2004が適用済みならば短時間で更新が終わるそうです。しかし2004が未適用なので、更新に長時間を要する恐れがあるのは覚悟していました。

「設定」の「Windows Update」から20H2の適用を開始してからリブートがかかるまで約8時間、さらにリブート後の最終更新で約1時間かかりました。ここまで時間がかかるとは、さすがに考えていませんでした。

ともかくWindows10 20H2に更新されましたが、画面の印象が変わっている感じがします。 

Windows10 20H2が来た

Windows10の2004が結局来ませんでした。しかたないので自前で2004に上げようかと思いましたが、公式サイトでは既に20H2の配布が始まっています。ならば自前で20H2に上げてしまおうか、それとも20H2の更新が来るのを待とうか、悩んでいました。何時になったら来るのか不明な20H2を待つよりも、自前で20H2に上げようと考えていたところでした。

ところが「設定」から「Windows Update」を確認したところ、「Windows 10、バージョン20H2の機能更新プログラム」の案内が届いていました。

「20H2の更新は短時間で済む」という情報がありますが、それは2004の更新が済んでいる場合なので、1909から更新する場合は時間がかかる恐れがあります。時間がとれるタイミングをみつけて、近いうちに更新しようと思います。

Otto-bot

近所の書店に行ったら「世界のノンフィクションが面白い！！」というコーナーがあったので、興味を引いた書籍を何冊か買ってみました。その一冊が『AIにはなにができないか』（メレディス・ブルサード著、北村京子訳、ISBN978-4-86182-761-7）です。「第2章 ハロー、ワールド」ではElizaボットについて語っています。

試しにElizaボットをひとつ作ってみるといい。そうすれば、こうした定型表現の限界にすぐに気づくだろう。あなたには、どんな状況にも対応できる返答ひと揃い、用意することができるだろうか。それはとうてい無理な話だ。大半の状況に対応できる返答を考えつくことはできるかもしれないが、すべてというのは難しい。

この記述を見て、ふと思いました。既に絶滅したのかもしれませんが、日本における結婚している男性（夫）が家庭で話すのは「メシ・フロ・ネル」の3語だけと（揶揄を込めて）言われていました。それならば「Otto-bot（夫ボット）」 を作ることが可能ではないでしょうか。しかもブルサード氏が「それはとうてい無理な話だ」と書いているにもかかわらず、「どんな状況にも対応できる返答ひと揃い、用意すること」が、たったの3語で出来てしまうのです。

鼻にする

人間の頭部の諸器官を使った慣用表現があります。

「口にする」には「語る」という意味があります。

「目にする」には「見る」という意味があります。

「耳にする」には「聴く」という意味があります。

ところが「鼻にする」という表現はありませんが、なぜでしょう。

「鼻につく」とか「鼻にかける」という表現はありますが、「嗅ぐ」という意味はありませんし、どちらも良い意味ではありません。

「鼻」だけ別扱いなのは日本語だけかと思ったら、英語にも同様な側面があるようです。『"Secrets" of England』（Colin Joyce、ISBN978-4-14-035163-5）の「Chapter 7 A Sniffer's Guide to Japan」では次のような事が書かれています。

But it is rare to hear people talk about the things they have smelled.

ここでは英語に「鼻」に関わる慣用表現が無いと書いているわけではありませんが、「鼻」というのは扱われ方が違うことがわかります。 

Windows10 2004は結局来なかった（ようだ）

Windows10は、2020年10月21日より20H2版の更新が始まっているようです（「Windows 10 バージョン20H2（October 2020 Update）」製品版が登場　標準ブラウザは「Chromium Edge」に）。Microsoftのサイト「Windows 10のダウンロード」では、既に「Windows 10 October 2020 Update」に切り替わっています。結局2004版の通知は来ませんでした（それとも、通知されたのに見落としたのでしょうか）。

現時点では1909版ですが、このまま放置しているとサポート期限がきてしまいます。早急にアップデートしたいと思いますが、いったん2004版にしておくべきなのか、いきなり20H2版にするのか悩んでいます。

リリースされた順番を辿る必要はないだろうとも思うのですが、致命的なトラブルに見舞われるのは避けたいとも思います。もっとも悩んでいても事態は進展しないので、バックアップをとってから「清水の舞台から飛び降りる」気持ちで20H2版にアップデートしてみようと思います。

さしみ湯葉の保護ラップ

先日、さしみ湯葉を貰いました。普段湯葉を食べる機会はなく（随分前に食べた経験はあります）、自分で買うこともありません。貰ったものの食べ方が分かりませんでしたが、パッケージを読むと「細切りにして、わさび醤油でお召し上がりください」とあったので、その通りにしてみました。

湯葉はシート状で、二つ折りになっていました。しかし薄いので、拡げるまでも無いだろうと思い、そのまま包丁で切りました。わさび醤油で食べてみたところ、ヘルシーだし、美味しいと思いました。食べていて、あまり気になりませんでしたが、ゴワゴワした食感でしたが、湯葉ってそういうものなのかと思いました。

少し食べ進んでから、湯葉を箸でつまんだ際に、つまみ具合で湯葉が少しずれ、その時に何かビニールのようなものが巻き付いていることに気付きました。これは何だろうと思いましたが、箸で巻き取っていくと、湯葉全体を包むように巻き付いていました。もしかすると、これは湯葉を保護するためのシートで、食べる部分ではないのかもしれません。

そう気づいて、まだ食べていない湯葉も確認してみると、どれも保護シートのようなものが巻き付いており、全部取り除いたら小皿の上に山積みになりました。やはり湯葉の保護ラップだったようで、これを取り除いてから食べるべきでした。しかし既に一部は食べてしまいました。胃の中で消化されるのか、その後で体外に排出されるのか、心配になりました。

それから数日たちましたが、身体に異常は生じていないし、気がつかないうちに排出されてしまったのかもしれません。そうだったら良いのですが。

WSL2を使おうとするとVirtualBoxやVMwareが動かない

Windows10を2004にすればWSL2が使えるようになるはずですが、20H2がリリースされたのに未だに2004が利用できるようになっていません。しかし1903や1909でもWSL2が利用できるそうなので、ひとまずWSL2を利用する設定をおこなっておきました。WSLではUbuntuを利用していますが、WSL2は別の何か（OpenSUSEなど）を使おうかと考えていました。

WSL2の利用は開始していませんが、VitualBoxを使う用事があったので起動しようとしたら、エラーが出てしまいます。つい先日までは動いていたはずなのですが。それではVMwareを動かしてみたら、これも駄目でした。何が問題なのかわかりませんが、WSL2を有効にしたのが怪しいとは思います。

WSL2を有効にしたというのは、具体的には「Windowsの機能の有効化または無効化」を利用して「仮想マシンプラットフォーム」を有効にしたという事です。だから逆に、それを向こうにしました。ところが相変わらずVirtualBoxでもVMwareでもエラーが出るのです。

同様の障害に見舞われている事例は多いようで対処方法がWebを検索すると見つかります。最終的に解決でき、VirutalBoxもVMwareも動くようになりました。この時に参考になった情報は「Windows10 1903でVirtual Box上の仮想マシンが起動できない」でした。

問題となった環境は次の通りです。もしかすると新しいマシンなら問題なかったのかもしれません。

• Windows10 1909 (OS build: 18363.1139)
• Intel Core i3-3220 3.30GHz

take ～ for granted

The Japan Times Alphaの2020年10月30日号のエッセイ「Views & Visions」はJoel Tanseyさんによる「Where the grass is greener」でした。記事では日本の鉄道に驚いたことが語られています。

I'm sure that for people who grow up here, it is easy to take the world-class transportation system for granted.

The Japan Times Alphaは「英語学習者のための英字新聞」を謳っているので、記事中の一部には訳注がついています。上述した引用には「take ～ for granted ～を当たり前とみなす」と訳注がついていました。

これを見て、随分前に『DUO 3.0』を勉強していた時を思い出しました。この本のコンセプトは「日本の「いろは歌」をヒントに、現代英語の重要単語1600語と重要熟語1000語を重複なしで560本の英文に凝縮させ」たという点にあるそうです。普通の単語帳だと、見出し語ごとに例文があるので、N語掲載の単語帳にはN文の例文が載っています。ところが『DUO 3.0』は、たった「560文」に凝縮している点がセールスポイントという事になっています。それは良いと思うのですが、「いろは歌をヒントに」したというのが解せません。「いろは歌」というのは寺子屋時代の仮名手本というイメージですが、「多くの語を凝縮するための手法」という印象はないのです。

閑話休題。『DUO 3.0』には次のような文が掲載されていました。

"Let's make up, Lisa."  "Stop taking me for granted!  We're through for good this time.  I mean it!"

ドラマの一場面のような例文ですが、そこはDUOですから、この中に暗記すべき語が忍び込ませてあるのです。そのひとつが「take A for granted」（Aを当然のことと思う）です。

単語帳で勉強する事の是非が話題となるときに言及されることですが、「単語帳の例文は、現実には見かけないようなものが多い」という意見がつくことがあります。DUOの例文がそうだという訳ではありませんが、僕自身がこの例文を見た時に「（ドラマでもない現実の状況において）この表現を使うことはあるんだろうか？」と思った事は確かです。

DUOで勉強していたのは随分前の事ですが、それ以来「take A for granted」という表現を目にしたことはありませんでした（DUOで学んだ語が現実に目にしたものも数多くあり、DUOが役に立ったことは確かです）。そしてThe Japan Times Alphaのエッセイで、その表現に出合い、「やっぱり使われているんだな」と思いました。

『ナショナルジオグラフィック日本版』の2020年10月号に掲載されている「雄大な自然を足の裏に感じて」（文／ニコラス・クリストフ、写真／ザッカリー・クラマー）を読みました。米国には、国土を縦断する長距離トレイルがあるようです。

1. パシフィック・クレスト・トレイル（PCT）4,265km
2. コンチネンタル・ディバイド・トレイル（CDT）4,990km
3. アパラチアン・トレイル（AT）3,525km

大きな国だけあって、どのトレイルも吃驚するほど距離が長いです。日本で青森から鹿児島までが約2,000kmと言われますから、その2倍以上もあります。

記事の中で著者は次のように書いています。

1970年にエリック・ライバックという10代の少年が、パシフィック・クレスト・トレイルの全区間を踏破した。その挑戦に関するナショナルジオグラフィック誌の記事と、ベストセラーになった彼の著書を、私は貪り読んだ。

 

ここに書かれている「ベストセラーになった彼の著書」というのは『ハイ アドベンチャー ある青春・山岳4000キロ縦走記』の事でしょう。近所の図書館が所蔵していたので、読んでみました。

著者であるEric Rybackは、18歳の時に1970年6月10日から同年10月16日にかけて約4,000kmの全区間を踏破しています。単純計算すると1日あたり30kmくらいになります。しかし平地を歩いている訳ではなく、山岳地帯ですし、食料などの大きな荷物も背負っていて重かったと思います。全区間を踏破したこと自体も驚きますが、毎日30km以上も歩き続けた事も驚異です。さぞかし強靭な精神力の持ち主なのかと思いがちですが、書籍を読むと、苦悩もあったようですし、気分のアップダウンも激しかったようです。

書籍のなかでエリック・ライバックは次のように記しています。

モニュメント78のほとりで休息していた、内気でいつもびくびくしていたような少年は、いま3700キロ以上遠く離れたここにすわって、たちまち仲よくなったはじめての相手とオープンに、そして親しげにつき合っている。 

究極の体験は著者に大きな変化を与えたようです。 

劇場版 銀河鉄道999

2020年10月4日にBS12で「劇場版 銀河鉄道999」が放送されたので（録画しておいて）観てみました。有名な作品なので大体の内容は知っていたのですが、以前に観た記憶はないので、最初から最後まで通してみたのは初めてです。おおまかなストーリは、母親を機械伯爵に殺された少年（星野鉄郎）が機械の身体を貰えるという星に行くため、銀河超特急999号にメーテルと一緒に乗車して旅を続ける、という話だったと思います。1979年公開なので、40年ほど前の作品です。

鉄道が出てくる作品ですが、鉄道ファン向けの作品という訳ではないでしょう。しかし鉄道ファン的に鑑賞することは可能だと思います。そのような視点で考えると、まず「超特急」というのが時代を感じます。1964年に開業した東海道新幹線で「超特急ひかり号」が登場（ちなみに「こだま号」は特急です）しました。特急よりも速いのが「超特急」というイメージです。今日の東海道新幹線の主役は「のぞみ」なので、「ひかり」に過去の輝きは失われています。

また1979年頃は、鉄道を趣味とする人は「鉄道ファン」もしくは「鉄道マニア」と呼ばれていたのではないかと思います。その後「鉄道オタク」という呼び方が生まれ、さらには「鉄ちゃん」などの呼び方もされ、最近では細分化して「乗り鉄」とか「撮り鉄」のような「○○鉄」という呼び方が多くなっています。そう思うと、主人公である星野鉄郎はメーテルから「鉄郎」と呼ばれていますが、もっとカジュアルに「鉄ちゃん」と呼ばれる可能性だってあったかもしれません。そういう呼び方になると、なんだかなぁという気もしますが。

999号を牽引したのは（見かけ上だけですが）「C62」の姿をしています。現実のC62は東海道本線などの幹線で優等列車を牽引した名機です。しかしSLの代表がC62なのかと考えると、そうも言えないところがあるのではないでしょうか。「デゴイチ」の愛称で有名な「D51」の方が蒸気機関車の代表のような気もします。しかし銀河超特急999号の牽引機がD51では物語にならないとは思いますので、C62で良かったのでしょう。

VSIから新しいPAKが届いた

VSIが提供するCommunity License Programを利用してOpenVMS Alpha 8.4-2L1を利用しています。先日新しいPAKの連絡が来ました。

PAKを更新する必要のある積極的な理由はありませんでしたが、入れ換えておきました。

Active licenses on node PWS500:

------- Product ID --------    ---- Rating ----- -- Version --

Product            Producer    Units Avail Activ Version Release    Termination

ALPHA-LP           VSI             0  H     0      0.0  (none)      20-SEP-2021 

ALPHA-SYSTEM       VSI             0  A     0      0.0  (none)      20-SEP-2021 

西村義樹・野矢茂樹『言語学の教室』を読んで

放送大学で受講中の「新しい言語学('18)」の第2章で参考文献としてあげられていた『言語学の教室』を読んでみました。この本は対談形式で書かれていますが、リアルな対談ではないようです。本書には「付録――対談のひとこま」として、リアルな対談のやりとりが掲載されています。本書全体がリアルな対談だと冗長だったりするので、手を入れているということのようです。したがって、著者が書き下した文章ではないが、発言（を基にしているものの）した言葉そのものというわけでもない形式です。

それはともかくとして、全体として興味深く読み進めることが出来ました。本書には「哲学者と学ぶ認知言語学」という副題がついています。しかし本書を読んだからと言っても、「言語学」や「認知言語学」の入門にはならないでしょう。そのような分野に入門するための「入り口」ではないかと思います。

『ソシュール超入門』（ポール・ブーイサック／【訳】鷲尾 翠）を読んで

放送大学教養学部で受講している「新しい言語学('18)」の中で「近代言語学」の”父”としてソシュールについて記されています。ソシュールの名前は、これまでも目にしたことがあり、本人が書いたわけでもない『一般言語学講義』が代表作と誤解もされています。

ソシュールについて概要を押さえておこうと思い図書館に行ったら『ソシュール超入門』を見つけたので、読んでみました。「第1章 ソシュールの最終講義」から読み始めたら、なにやら日記のような時系列の記述がはじまったので面喰いましたが、そこで投げ出さず最後まで読了しました。人によって良し悪しの評価は分かれるでしょうが、「超入門」としては悪くないのではないかと思います。もっと深く知りたいのであれば、さらに類書に進めば良いと思います。入門段階で、右も左もわからないので、難解な専門用語が出てきて、読む気を失くすよりも、よほどマシだと思います。

『はじめての構造主義』（橋爪大三郎）を読んで

放送大学教養学部で 2020年度第2学期は「新しい言語学('18)」を受講することにしました。講義の第1回は、「新しい言語学と言うからにはその前の言語学がある」ということで、これまでの言語学の歴史について説明がありました。

そこで出てきたのが「構造主義」です。「構造主義」とか「ポスト構造主義」という言い方は、論文を読んでいると目にすることがあります。関係する人物としてレヴィ・ストロースの名前が挙げられますが、結局なんなのか良くわかりませんでした。

図書館で入門書を探したところ、講談社現代新書898の『はじめての構造主義』（橋爪大三郎）を見つけたので読んでみました。出版されたのは昭和63年ですから、30年以上前の書籍です。しかも以下のような記述もあり、もはや構造主義（とポスト構造主義）は過去の話にすぎないのかもしれません。

ところで最近では、「ポスト構造主義」というのが主流です。「ポスト」とは「それ以後」といういみですから、構造主義なんかにいまごろまだひっかかっているようでは、”遅れてる”もいいところでしょう。だいいちポスト構造主義でさえ、もうけっこう”古い”わけです。

古い話を今頃になって勉強する意義はともかく、本書を読んで、なんとなく構造主義の考え方や関連人物の関係が見えてきた気がします。筆者の語り口は、新書だからかもしれませんが、普通の学術書に比べれば、くだけています。わかりやすくしようという試みのひとつなのかもしれません。

本書は入門書なので、これを読んだだけで構造主義について完全な理解が得られるわけではないと思いますが、十分に「入門」の役割をはたしていると思います。さらに深く知りたいのであれば、本書を基礎に、別の書籍を読み進めていけばよいのでしょう。

pythonのargparseモジュールでコマンドラインで指定した文字列を数値に変換するロジック

Pythonを利用して簡単なツールを作成しているところです。ツールを組むにあたり、Pythonが標準的に提供しているモジュールを活用することを基本とし、同じようなロジックを自前で作らないようにしたいと考えています。この方針のもとに、コマンドライン引数を解釈するのはモジュール「argparse」 を、ログ出力にはモジュール「logging」を使用しようと思っています。

モジュール「logging」では、ログレベルの表記と数値が「16.6.2. ロギングレベル」で定められています。例えば「DEBUG」なら「10」、「WARNING」なら「30」のようになります。このようなログレベルをコマンドライン引数で指定できるようにしたいのですが、考えておく必要のある事項があります。

1. コマンドラインでは文字列（「DEBUG」など）を指定したとしても、ツール内部では対応する数値（「DEBUG」が指定されたのであれば「10」）で処理したい。
2. どの文字列がどの数値に対応しているのかという「知識」をユーザが持つ必要が無いようにしたい。

モジュール「argparse」ではメソッド「add_argument()」において「choices」を使えば、考えているような事ができると思います。しかし注意しておかなければのは、選択肢を「choices={'debug', 'warning', ...}」のように定義すれば、考えているような形でコマンドライン引数を指定することができます。ただしモジュール「argparse」のメソッド「parse_args()」の結果としては、変数に格納される値も「文字列」になってしまいます。これを対応する数値にする方法はないか考えてみました。

当初はメソッド「add_argument()」の仕組みの中で対処しようと考えていました。例えば「choices」に指定しておくのは対応する数値の方にしておき、「type=lambda s: myfunc(s)」のようにしておけば、自前の関数「myfunc()」の中で「コマンドラインで与えられた文字列を、対応する数値に変換」することができるようになります。これで意図した動作をするのですが、もしコマンドラインでオプション「-h」を指定すると表示されるヘルプメッセージでは、選択肢として「数値の列」が出てきてしまいます。この問題は「metavar」を使えば対処できます。

これで問題が全て解決したかと思いましたが、まだ問題が残っていました。もし選択肢にない文字列をコマンドラインで指定した場合、エラーメッセージ「invalid choices」が表示され、そこでは正しい選択肢として「choices=」で指定している情報が出力されます。それは「数値」であり「文字列」にはなっていません。モジュール「argparse」の実装（/usr/lib64/python3.6/argparse.py）を確認すると、以下のようになっていました。この問題はモジュールの実装に手を入れない限り解決できないようです。

def _check_value(self, action, value):

# converted value must be one of the choices (if specified)

if action.choices is not None and value not in action.choices:

args = {'value': value,

'choices': ', '.join(map(repr, action.choices))}

msg = _('invalid choice: %(value)r (choose from %(choices)s)')

raise ArgumentError(action, msg % args)

モジュール「argparse」の仕組みの中では問題を解決することはできませんので、モジュールの外で対処するしかなさそうです。その結果として以下のようなロジックにしました。これならば意図していたような動作にはなりそうです。

#!/usr/bin/python3

import argparse

import logging

def parseArgv():

        loglevel = {'debug':10,'info':20,'warning':30,'error':40,'critical':50}

        parser = argparse.ArgumentParser()

        parser.add_argument('-l', '--level',

                choices=loglevel.keys(),

                default='info',

                type=str.lower,

                help='log level not case sensitive (default: %(default)s)')

        parser.add_argument('-v', '--version',

                action='version',

                version='%(prog)s 1.0')

        args = parser.parse_args()

        args.level = loglevel[args.level]

        return args

def outputLog():

        # create logger

        logger = logging.getLogger(__name__)

        logger.setLevel(logging.DEBUG)

        # create console handler

        handler = logging.StreamHandler()

        handler.setLevel(logging.DEBUG)

        # create formatter

        formatter = logging.Formatter(

                '%(asctime)s %(name)s:%(levelname)s:%(message)s',

                datefmt='%Y/%m/%d-%H:%M:%S')

        # add formatter to handler

        handler.setFormatter(formatter)

        # add handler to logger

        logger.addHandler(handler)

        # application code

        logger.setLevel(args.level)

        logger.warning('Watch out!')

        logger.info('I told you so')

        logger.debug('often makes a very good meal of %s', 'visiting tourists')

if __name__ == "__main__":

        args = parseArgv()

        outputLog()

#[EOF]

VMware上のCentOS7でavahiを試す

DHCPでアドレスが割り当てられたマシンに対してホスト名でアクセスできるようにするためにはavahiが使えるという情報を得ました。そういうパッケージが存在することは耳にしていました。しかし、どのような設定をすれば良いのか、 何が出来て何が出来ないのか、よくわかりません。そこでVMwareでCentOS7を動かして実験してみることにしました。

設定の参考にしたのはWebで見つけた記事「 CentOS 7でmDNS(Avahi Daemon)を有効にする」です。やる事はシンプルです。設定後に念のために再起動しました。

1. yumでavahiを入れる。
2. avahi-daemonを有効にする。
3. ファイアウォールでサービス「mdns」を通す。

ここでWindows10からpingを飛ばしてみます。すると反応がありました。すばらしい。

C:\Users\FURUSAWA>ping -4 vmware.local

vmware.local [192.168.1.17]に ping を送信しています 32 バイトのデータ:

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.1.17 の ping 統計:

    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、

ラウンド トリップの概算時間 (ミリ秒):

    最小 = 0ms、最大 = 0ms、平均 = 0ms

それでは逆にCentOSからWindows10に向かってpingを投げてみましたが、うまくいきません。コマンド「avahi-resolve」ではIPアドレスが見つかっているのに、pingでは名前をわかってくれません。ファイル「/etc/nsswitch.conf」にはmDNSを見に行くように指定している（つもり）なのですが、他にも何かする事があるのでしょうか。

[root@vmware log]# avahi-resolve -n windows10.local

WINDOWS10.local  192.168.1.31

[root@vmware log]# ping -4 windows10.local

ping: windows10.local: Name or service not known

[root@vmware log]# grep '^hosts:' /etc/nsswitch.conf

hosts:        files mdns_minimal [NOTFOUND=return] dns myhostname

変体漢文とJapanese English

放送大学教養学部で2020年度第2学期は「漢文の読み方('19)」 （宮本 徹・松江 崇）を受講することにしました。そこで図書館に行き、参考になるような書籍を探し、『漢文と東アジア―訓読の文化圏』（金 文京）を借りてきました。日本語を表記するために漢字は欠かせませんし、中学高校でも漢文の授業があります。漢文を読むために訓読がありますが、よく考えると「訓読」は日本だけではなく、漢文の影響を受けた東アジアでは（訓読とは呼ばないとしても）同様のことがおこなわれたハズです。

学校で習う漢文の時間では軽く流してしまうような事柄についても、本書では実例を踏まえて詳述されており、とても興味ぶかく読了しました。

「第3章 漢文を書く／2 さまざまな漢文」の192～194頁では「変体漢文の分類」として、変体漢文が生じる理由として4つに分類されています。

1. 書き手が未熟で、規範的漢文を書くつもりが、変則的になってしまう。
2. 母国語の語法が無意識に反映される（これを日本では「和習」とか「和臭」と呼ぶようです）。
3. 母国語の語法を意識的に反映させる。
4. 漢字を表音的に用いて自国語を記述する。

変体漢文というのは規範的な漢文に対する用語です。日本人が漢文だと思っているのは古代中国語に相当しており、（本書によれば）近現代の中国語とは違うもののようです。

それはともかく、変体漢文が生じる理由は、今日において日本人が英文を書こうとしたときにも生じているのではないでしょうか。1番目の理由のように、「書き手が未熟で、規範的英文を書くつもりが、変則的になってしまう」ことを「ブロークン・イングリッシュ」と呼ばれています。2番目の理由のような「和習や和臭」のことを「Japanese English」と呼ばれていると思います。

いつの時代でも、どのような外国語でも、生じる現象は同様であるようです。

Windows10 2004はまだか

Windows10の次期アップデート「20H2」が間もなくリリースされるという情報があります（まもなく登場のWindows 10のアップデート「20H2」でこう変わる）。これは「安定性と品質を重視した「マイナーアップデート」となる。このため、新機能は細かいものばかりだ」との情報がありますが、それ以前にアップデート「2004」が届いていません。

Windows10 2004が未だに届いていないユーザは他にもいるようです。

1. 「Windows 10 Ver.2004 が配信されてこない」（2020年9月23日）
2. 「Windows 10 バージョン2004（May 2020 Update）が未だにこない件」（2020年9月30日）

アップデート「2004」が届かないままに「20H2」がリリースされた場合、未だにアップグレード「1909」のままのマシンは「2004」がスキップされるのでしょうか。それとも、まず「2004」がインストールされ、次いで「20H2」がインストールされることになるのでしょうか。

そもそもWindows10のアップデートが約半年ごとにリリースされるというのは、マイクロソフトの方針に過ぎないのです。半年ごとでなければならない理由がユーザ側にある訳ではありません。1ヵ月ごとだろうが1年ごとだろうが、マイクロソフトの方針として実現させてくれればよいことです。それなのに半年たってもリリースされないような状況が生まれるのは、いったいどうなっているんだと思います。

VT端末で使われるLK201キーボードを意識したRLoginにおけるキー配置

OpenVMS Alpha 8.4-2L1にRLoginを用いてSSH接続することが出来るようになりました。コマンドラインで普通にキー入力している分には問題になりませんが、エディタを使おうとすると多少厄介な問題があります。

OpenVMSはDEC製なので、端末もDEC製のVTシリーズが利用されます。VTシリーズで使われる標準的なキーボードLK201はファンクションキー等の配置がPCで使われているキーボードとは異なります。両者の違いをどのように吸収して配置するかを考えなければなりません。

まずLK201のファンクションキーは20個ですが、PCは12個しかありません。そこでPCのファンクションキーF1～F10を使って対応付けます。

1. PCのF1～F10を、LK201のF1～F10に対応させます。
2. PCのF1～F10を「ALT」キーと共に押した場合、LK201のF11～F20に対応させます。

LK201はテンキーの上の段の4個をPF1～PF4として扱います。このようなものはPCのキーには存在しません。そこでPCのF1～F4に割り当てることにします。これでは上述したファンクションキーと重なってしまうように思えます。しかしVTではF1～F5は特殊目的に使われているので、問題ないでしょう。

VTではF15を「Help」、F16を「Do」として扱います。エディタでも良く使われます。そこでこの2個をF11とF12に割り当てることにしました。当然ながらALTを押しながらF5やF6を押しても同等のはずです。

以上のような方針でRLoginのキー配置を変更します。デフォルトではVT52に対応させる設定が入っていますが、全て削除しました。 

TTSSH.LOGを生成する方法

Tera TermでSSH接続時の詳細情報は「TTSSH.LOG」に記録されるようです。Tera Termの設定ファイルで「TTSSH が TTSSH.LOG に記録するログのレベルを設定します。」のような記述があります。ここで疑問が生じます。そのファイル「TTSSH.LOG」は「何処に」出来るのでしょうか？ 

設定ファイルで出力先ディレクトリを指定するのでしょうか？もしそうであるなら、その指定をおこなうためのキーワードは何でしょうか？

いろいろと調べてみたら、ログファイル「TTSSH.LOG」は、実行ファイル「ttermpro.exe」のあるディレクトリに作成されるそうなのです。そのディレクトリは「C:\Program Files (x86)\teraterm」ですが、ファイルはありません。いったいどうなっているのでしょう。

もしかすると書き込み権限が悪さをしていてファイルが出来ていないのかもしれません。そこでTera Termを管理者権限で実行させてみました。すると「TTSSH.LOG」が出来ていました。やはり権限の問題なのでしょう。

管理者権限でなくてもログファイルが出来るようにするため、ディレクトリに権限を与えておきたいと思いましたが、どうしたら良いか分かりません。これは将来の課題としておきます。

Tera TermでOpenVMSにSSH接続する

Tera Term 4.105（Tera Term Secure Shell extension 2.91）でOpenVMSにSSH接続しようとしましたが、最終的に接続できませんでした。Windows10附属ssh.exeやRLoginでは接続できていますし、同じ鍵を使っているので接続できるはずだと思いますが駄目でした。

Windows10でTera Termを使っているだけでは、何が悪くて接続できないのか、さっぱり分かりません。SSHで接続しようとした際のログファイルを確認する必要があります。

• Tera Term側のログは「C:\Program Files (x86)\teraterm\TTSSH.LOG」にあります。
• OpenVMS側のログは「SYS$SYSDEVICE:[TCPIP$SSH]TCPIP$SSH_RUN.LOG」にあります。

ログを確認すると、Tera Term側から「SSH2_MSG_DISCONNECT」を送っているようです。その前後のログは以下のようになっていました。

2020-10-03 06:05:05.656Z [27016] ssh2_kex_finish: SSH2_MSG_NEWKEYS was sent. 2020-10-03 06:05:05.677Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:05.677Z [27016] SSH2_MSG_NEWKEYS was received(DH key generation is completed). 2020-10-03 06:05:05.696Z [27016] Server reports supported authentication method mask = 65580 2020-10-03 06:05:05.696Z [27016] Entering secure mode 2020-10-03 06:05:05.696Z [27016] User authentication will be shown by 0 method. 2020-10-03 06:05:05.902Z [27016] CRYPT_set_random_data: RAND_bytes call 2020-10-03 06:05:05.906Z [27016] finish_send_packet_special: built packet info: aadlen:0, enclen:32, padlen:10, datalen:52, maclen:20, mode:E&M 2020-10-03 06:05:05.906Z [27016] SSH2_MSG_SERVICE_REQUEST was sent at do_SSH2_userauth(). 2020-10-03 06:05:05.906Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:05.906Z [27016] SSH2_MSG_SERVICE_ACCEPT was received. service-name=ssh-userauth 2020-10-03 06:05:05.906Z [27016] CRYPT_set_random_data: RAND_bytes call 2020-10-03 06:05:05.916Z [27016] finish_send_packet_special: built packet info: aadlen:0, enclen:48, padlen:4, datalen:68, maclen:20, mode:E&M 2020-10-03 06:05:05.917Z [27016] SSH2_MSG_USERAUTH_REQUEST was sent do_SSH2_authrequest(). (method 0) 2020-10-03 06:05:05.927Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:05.927Z [27016] SSH2_MSG_USERAUTH_BANNER was received. 2020-10-03 06:05:05.927Z [27016] Banner len: 69, Banner message: Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1 . 2020-10-03 06:05:05.927Z [27016] Banner ltag len: 2, Banner Language Tag: en 2020-10-03 06:05:27.859Z [27016] CRYPT_set_random_data: RAND_bytes call 2020-10-03 06:05:27.859Z [27016] finish_send_packet_special: built packet info: aadlen:0, enclen:48, padlen:6, datalen:68, maclen:20, mode:E&M 2020-10-03 06:05:27.859Z [27016] SSH2_MSG_DISCONNECT was sent at SSH_notify_disconnecting(). 2020-10-03 06:05:27.876Z [27016] SSH2_MSG_IGNORE was received. 2020-10-03 06:05:27.876Z [27016] SSH2_MSG_USERAUTH_FAILURE was received.

OpenVMS側では以下のようなログを出しています。

debug( 3-OCT-2020 15:05:54.30): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=50

debug( 3-OCT-2020 15:05:54.31): SshUnixUser/SSHUNIXUSER.C:3122: ovms_pw->pw_dir:KAZ$USER:[FURUSAWA]  unix_passwd.pw_dir:/dka100/user/furusawa/ 

debug( 3-OCT-2020 15:05:54.31): Sshd2/SSHD2.C:1655: user 'furusawa' service 'ssh-connection' client_ip '192.168.1.31' client_port '53402' completed ''

debug( 3-OCT-2020 15:05:54.32): Sshd2/SSHD2.C:2108: output: publickey

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 2 to connection

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 53 to connection

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 2 to connection

debug( 3-OCT-2020 15:05:54.32): Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 51 to connection

debug( 3-OCT-2020 15:06:16.25): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=1

debug( 3-OCT-2020 15:06:16.25): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: authentication cancelled

Sat 03 15:06:16 INFORMATIONAL: Remote host disconnected: authentication cancelled

debug( 3-OCT-2020 15:06:16.25): Sshd2/SSHD2.C:760: locally_generated = FALSE

Sat 03 15:06:16 INFORMATIONAL: disconnected by application in remote: 'authentication cancelled'

Tera Termを使わなくてもRLoginならばOpenVMSにSSH接続できるので、実害はありません。この場合、Tera Term側が「SSH2_MSG_DISCONNECT was sent」となっており、OpenVMS側が「Remote host disconnected」となっているので、Tera Term側が接続を断っているように見えます。他のSSHクライアントであれば接続できているので、Tera Term側の問題であることが疑われます。

RLoginでOpenVMSにSSH接続する

RLogin 2.25.5（2020/09/25）でOpenVMSにSSHで接続する設定を行いました。

普通にSSH接続のための設定をおこなうことで無事に接続できて、それは良かったのですが、ログアウトしようとすると問題がおきました。 

ログアウトすると「ssh Receive 'CBuffer Get32Bit'」というダイアログが出てきて接続が閉じません。仕方ないのでメニューから[ファイル]>[接続を閉じる]をおこなうと「現在、接続中です。接続を閉じますか？」というダイアログが出てきます。ここで「はい」を選べば、接続は閉じますが、釈然としません。

C:\Windows\System32\OpenSSH\ssh.exeでOpenVMSにSSH接続する

C:\Windows\System32\OpenSSH\ssh.exeでOpenVMSにSSH接続しようとしたらエラーが出ました。

C:\Users\FURUSAWA\.ssh>ssh -i id_rsa furusawa@192.168.1.161

Unable to negotiate with 192.168.1.161 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

C:\Users\FURUSAWA\.ssh>

エラーメッセージを頼りにWebを検索したら「macでssh接続をしたときno matching key exchange method found. Their offer: diffie-hellman-group1-sha1と言われて接続できない」という情報が見つかりました。この記事によるとファイル「config」を作成すれば良いようです。その通りにしたところ、無事に接続できました。

C:\Users\FURUSAWA\.ssh>type config

KexAlgorithms +diffie-hellman-group1-sha1

C:\Users\FURUSAWA\.ssh>ssh -i id_rsa furusawa@192.168.1.161

 Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1

Enter passphrase for key 'id_rsa':

    Last interactive login on Saturday, 3-OCT-2020 15:20:29.27

$ logout

Connection to 192.168.1.161 closed.-2020 15:21:03.67

C:\Users\FURUSAWA\.ssh>

OpenVMS Alpha 8.4-2L1のSSH設定

OpenVMS Alpha 8.4-2L1に対してWindows10からSSH接続できました。設定する上で注意が必要な点が幾つかありました。

C:\Users\FURUSAWA\.ssh>ssh -i id_rsa furusawa@192.168.1.161

 Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1

Enter passphrase for key 'id_rsa':

    Last interactive login on Friday, 2-OCT-2020 11:03:16.17

$ logout

Connection to 192.168.1.161 closed.-2020 12:05:27.60

C:\Users\FURUSAWA\.ssh>

最も注意しておくべきなのは、TCP/IP Services for OpenVMSにおけるSSHはOpenSSHではないことです。Webを検索した場合、OpenSSHを前提とした情報が多く見つかるので、それを鵜のみにして設定作業をおこなっても、うまくいかないでしょう。設定作業の参考になったのはWebで見つけた記事「SSH public key authentication on OpenVMS」でした。

OpenVMSで使える鍵にED25519は利用できません。最近のOpenSSHではED25519が使えるので、他のサイトに入るための鍵に僕はED25519を使っています。それとは別にRSAなどで鍵を準備しなければなりません。

最近のWindows10では標準でOpenSSHが入っているようです。

C:\Users\FURUSAWA\.ssh>C:\Windows\System32\OpenSSH\ssh.exe -V

OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

これを使ってRSA鍵を作ります。このままではOpenSSH形式なので、SECSH形式に変換します。

C:\Users\FURUSAWA\.ssh>ssh-keygen

（略）

C:\Users\FURUSAWA\.ssh>ssh-keygen -f id_rsa.pub -e > id_rsa.secsh

OpenVMS側には、Windows10で作成したSECSH形式の公開鍵を置きます。ファイル名は変えなくても構いません。しかしOpenSSHでは~/.ssh/authorized_keysに公開鍵が格納されるのでファイル名を気にする必要がありませんでしたが、OpenVMSでは独立したファイルとして置かれるため、秘密鍵のあるサイトを連想しやすい名前にしておいた方が（必須ではありませんが）無難です。

$ dir/sec

Directory KAZ$USER:[FURUSAWA.SSH2]

AUTHORIZATION.;1     [FURUSAWA]                       (RWED,RWED,RE,)

FURUSAWA-WINDOWS.PUB;1

                     [FURUSAWA]                       (RWED,RWED,RE,R)

Total of 2 files.

$ type authorization.;

KEY FURUSAWA-WINDOWS.PUB

以上の設定で、Windows10からOpenVMSにSSHでログインできました。

RLoginでOpenVMSに接続した際の端末タイプの設定方法

先日インストールしたOpenVMS Alpha 8.4-2L1にRLoginで接続すると、端末タイプが「VT500相当」になります。VT500相当ではいけないという事ではありませんが、VT100などにはならないのか、そもそも任意に変更できるのか、不明でした。

$ show term

Terminal: _OPA0:      Device_Type: VT500_Series  Owner: SYSTEM

RLoginのWebサイトにある「エスケープシーケンス一覧」によると、「DA1」の応答はTermID設定によって変化すると書かれています。その「TermID設定」とは「3.6.1 ESC/CSI/DCSの設定」によれば次のように書かれています。

各種IDでは、DA1,DA2,DA3で応答する番号の初期値を設定できます。

試してみたところ、次のように変化しました。

1. TermIDを「10」とした場合「VT500_Series」になる。
2. TermIDを「9」とした場合「VT400_Series」になる。
3. TermIDを「7」か「8」とした場合「VT300_Series」になる。
4. TermIDを「5」か「6」とした場合「VT200_Series」になる。
5. TermIDを「2」か「3」か「4」とした場合「VT102」になる。
6. TermIDを「0」か「1」とした場合「VT100」になる。

OpenVMSに接続する場合、どのVT互換として利用すれば良いのかは、迷うところです。VT220などのキーボードは、IBM-PCのキーボードとは（似ていますが）重要なキー（DOキーなど）に差異があります。このハンドリングをRLoginで対応できるのかを、見極めなければならないと思います。

avahiを利用すると何が出来るようになる？

自宅にはアーキテクチャの異なるマシンが何台かあります。それらの多くは必要な時だけ電源を入れています。24×365で電源が入りっぱなしなのは、FreeBSD/amd64です。またWindows10のデスクトップPCはクライアント環境として使っており、就寝時には電源を落としています。

自宅LANには、他にもNetBSD、OpenBSD、OpenVMSや、VirtualBoxとかVMwareにインストールしたCentOSなどが接続されます。基本的にはTCP/IPの固定アドレスを割り当てるようにしていますが、DHCPを使う場合もあります。そのひとつがdynabook SS SX/15AにインストールしたNetBSD/i386です。自宅で使う場合は固定アドレスを割り当てることも可能ですが、外出先に持って行くことがあるので、その場合はDHCPを利用することになります。自宅か外出先かに依って設定を切り替えるのは面倒なので、自宅でもDHCPを使うことにしています。そうしておけば設定を切り替えずに済むからです。

ここで問題になるのが、自宅LANでDHCPを利用した際に割り当てられたアドレスが変動することです。なにしろDHCPなのですから、同じマシンに同じアドレスが割り当てられるとは限りません。それがDHCPというものなので、それはやむを得ないのですが、自宅LANにある他のマシンから接続しようとした際に、アドレスが決まっていないと、不便です。

なんとか解決方法はないものかとWebを検索していたら、avahiというものが見つかりました。技術的にはmDNSという仕組みに基づく実装のようです。僕が必要としているものよりも大掛かりで、必要のない機能も含まれていますが、概念としては求めているものです。

どのようなものなのか、ちょっと試してみようと思います。しかしavahiの想定している環境構築の概念がはっきりしません。問い合わせをおこなうデーモンが動くようですが、LAN上に一つだけ存在すればよいのか、各マシン上に各々配置する必要があるのか、全体像が見えてきません。

Webを探ると事例が見つかるのですが、「そもそもavahiとは」というような情報がみつかりません。とにかく試してみるしかないのかと思っているところです。

SSHのエージェント転送をTera TermやRLoginで実行

SSHの秘密鍵を多数の接続先に置かないで済むため、エージェント転送をおこなうにはU*IXならば次のような手順となります。

1. ssh-agentを実行しておく。
2. ssh-addで秘密鍵を登録しておく。
3. sshで接続する際にオプション「-A」を指定する。

これは接続元がU*IXの場合の手順ですが、もし接続元がWindowsなら手順はどうなるのでしょうか。

端末エミュレータとしてRLoginを使うなら、接続設定において「サーバー」>「プロトコル」で「エージェント転送を有効にする」を指定するだけです。とても簡単です。

端末エミュレータとしてTera Termを使う場合はどうでしょう。RLoginのように簡単なのかと思って、SSH認証において「エージェント転送する」を指定しましたが、これでは駄目で、以下のようなエラーが出てしまいました。

Permission denied (publickey,keyboard-interactive).

どうやらU*IXの手順で必要だったssh-agentやssh-addに相当するものが無いと駄目のようです。

1. ssh-agentに相当するのはPageantというソフトのようです。これはWinSCPに不増kしていたものを使いました。元々はPuTTYに付属するようですが、事情はよくわかりません。
2. ssh-addに相当するのはPageantに秘密鍵を登録することです。
3. Tera Termで「エージェント転送する」を指定するという行為は、オプション「-A」を指定することに相当するのでしょう。

Tera Termの挙動はU*IXでの手順とおなじですが、RLoginの方が使い勝手が良い気がします。

SSHを鍵認証する場合の鍵作成の方針とは？

SSHで鍵認証を利用する際に必要となる秘密鍵・公開鍵は、どのような方針で作成するものなのでしょうか？ssh-keygenで鍵を作成するわけですが、コマンドを打てば鍵が出来てしまいますが、それがSSH鍵認証で想定している方針に合致しているとも限らないわけです。

ssh-keygenで作成した公開鍵は、以下のような形をしています。右端にあるのはコメントでオプションで変更することができますが、デフォルトでは鍵を作成したユーザ名が入ります。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABErI+RbZ foo@bar.com

このデフォルトで与えられるコメントを考えると、鍵は「ユーザ（とホスト）」を単位に作成されるものと考えるのが基本なのかと思います。SSH鍵認証の入門レベルの説明としては、それで構わないと思います。しかし現実の環境において、多数のサーバを扱う管理者であれば、どうなってしまうのでしょうか。サーバが何十台もあったとしても、各サーバでssh-keygenを用いて鍵を作成することは可能でしょう（サーバ上に秘密鍵を置くことの是非はあるかもしれませんが）。作成された公開鍵を全サーバに配置していく作業は（できるかもしれませんが）大変です。さらに作業が大変か否かという実務的な問題だけではなく、各サーバに秘密鍵が置かれていることがセキュリティ的に妥当といえるのかという問題もあるでしょう。

このような問題はssh-agentとssh-addを利用することで解決できそうです。「エージェント転送」を使えば、クライアントマシンだけに秘密鍵を置いておけば、その他のサーバに秘密鍵を置く必要がなくなるようです。

管理者が使用しているクライアントマシンで鍵を作成しておけば、全サーバでは鍵を作成しなくて良くなるのですから、これで疑問は解消したと言えるのでしょうか。つまり鍵は「個人」を特定するものなのでしょうか。

それでは管理者が複数のマシンをクライアントとして利用している場合には、どうなるのでしょうか。鍵が「個人」を特定するのであれば、同一管理者が使用する全クライアントマシンでは、秘密鍵を使いまわすことになります。それでも構わないのかもしれませんが、そのような運用を認めると、複数の管理者で秘密鍵を使いまわすことに繋がる恐れもないとは言えません。

運用次第で何とでもなるという話ではなく、SSH鍵管理の発想とは何だったのかという事を知りたいと思います。

Tera TermでもRLoginでもOpenVMSの利用に問題はないのか

Microsoft Windows上で使う端末エミュレータは、昔からTera Termを利用していました。しかし接続先の日本語環境をUTF-8にすると、（何かの設定が悪いのだと思いますが）ちゃんと日本語が出なくなりました。そこで代わりとなる端末エミュレータを探すとRLoginに辿りつきました。それ以来、Tera Termを使うことは無く、もっぱらRLoginを利用していました。

最近OpenVMS Alpha 8.4-2L1をインストールし始めた際にも、RLoginで接続していました。コマンドライン操作をしている分にはRLoginでも別に差し支えありません。ところがスクリーンエディタを利用しようとすると、ちょっと問題が出てきました。

OpenVMSのスクリーンエディタは、VT端末のキーボード配置を期待して操作するようになっています。今日のパソコンのキーボードと似ていますが、ファンクションキーの配置など多少キー配置が異なっています。RLoginでVT端末と同一の操作をするためには、何か設定すれば良いのか、そもそも不可能なのか、よくわかりません。そこで最近は利用していなかったTera Termを使ってみました。VT端末のキーボードとの対応関係を理解しておく必要はありますが、少なくともVT端末と同等の操作をすることができます。

接続先によってTera TermとRLoginを使いわける事は避けたいと考えています。できればRLoginに統一したいのですが、そううまくいくかどうか調査してみようと思います。

OpenVMS Alpha 8.4-2L1に対してSSHでログインする方法は何か？

Digital PersonalWorkstation 500auにVSI版OpenVMS Alpha 8.4-2L1をインストールしました。この時点で次のようなプロダクトがインストールされています。

------------------------------------ ----------- ---------

PRODUCT                              KIT TYPE    STATE

------------------------------------ ----------- ---------

VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1   Full LP     Installed

VSI AXPVMS CDSA V2.4-320A            Full LP     Installed

VSI AXPVMS DECNET_OSI V8.4-D         Full LP     Installed

VSI AXPVMS DWMOTIF V1.7-F            Full LP     Installed

VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1  Full LP     Installed

VSI AXPVMS HPBINARYCHECKER V1.1-A    Full LP     Installed

VSI AXPVMS KERBEROS V3.1-152A        Full LP     Installed

VSI AXPVMS OPENVMS V8.4-2L1          Platform    Installed

VSI AXPVMS SSL V1.4-502A             Full LP     Installed

VSI AXPVMS SSL1 V1.0-2JA             Full LP     Installed

VSI AXPVMS TCPIP V5.7-13ECO5F        Full LP     Installed

VSI AXPVMS TDC_RT V2.3-1220          Full LP     Installed

VSI AXPVMS VMS V8.4-2L1              Oper System Installed

------------------------------------ ----------- ---------

13 items found

PAKは既に入れてありますが、それ以外の設定は何もしていません。ひとまず次のような設定を済ませておきました。

1. アカウント作成
2. DECnet-Plusの設定
3. バッチキューの設定
4. TCP/IP Services for OpenVMSの設定

DECnet IVとしての設定を済ませましたので（DECnetとして）リモートログインは出来るのですが、DECnetで繋がるのは自分自身だけです。TCP/IPならMicrosoft Windows10やFreeBSD/amd64などから接続できるはずなので、その設定を済ませたいと思います。TELNETなら以前に設定したことがあるので、今回はSSHで接続する環境を設定してみようと思います。しかしながら、TCP/IP Services for OpenVMSの場合、どうすれば良いのでしょう？

FreeBSDやNetBSD、またはLinuxであれば、接続したいアカウントの「~/.ssh」において、公開鍵を「authorized_keys」に追加すれば良い訳ですが、OpenVMSの場合は、どうなるのでしょう？

『TCP/IP Services for OpenVMS Guide to SSH』というマニュアルを見つけたので、目を通してみました。些細なことかもしれませんが、やはり違いがあるようです。

1. SYS$LOGINの下にある「[.SSH2]」が使われるようです。
2. RSAかDSAしか選べないようです。普段はED25519を使っているので、同じ鍵は使えないですね。

試しにSSHで接続してみましたが、うまく行きませんでした。問題の所在をつきとめて、接続できるようにしたいと思います。

CentOS7のインストールで作成されるLVM

 VMwareを利用して、CentOS7をインストールした際のデフォルトの挙動を調べてみました。

使用したのは「CentOS-7-x86_64-DVD-1708.iso」です。これはCentOS 7.4です。インストール中に選択する項目はありますが、まずはデフォルトのままにしてみます。インストール完了後、ブートしてディスクの割り当て状況を確認してみました。LVMが使われている事は承知していましたが、「/dev/mapper/centos-root」と「/dev/mapper/centos-home」が出来ていました。

もしインストール中にネットワーク設定をおこない、（例えば「myhost」のように）ホスト名を指定すると、論理ボリューム名が変わるようです。「/dev/mapper/centos_myhost-root」のようにホスト名が入るようです。

ここで気になったのは、別のところで使っているCentOS7の論理ボリューム名とは違っていたことです。そこでは「/dev/mapper/cl-root」となっています。この名前は、どのようにして付けたのでしょうか。インストール中に指定する箇所は無かったはずです。

もしやと思い、「CentOS-7-x86_64-DVD-1611.iso」を使ってインストールしてみました。これはCentOS 7.3です。やはりデフォルトのままでインストールを完了したところ、論理ボリューム名が「/dev/mapper/cl-root」のようになっていました。要するにCentOS7.3と7.4とで挙動が変わったということでしょうか。この件はリリースノートには書かれていないようです。どういう理由で変更されたのでしょうか？

VSI版OpenVMS Alpha 8.4-2L1インストールが完了

Digital PersonalWorkstation 500auにVSI版OpenVMS 8.4-2L1のインストールが完了しました。実質的には「インストール成功」だと思っているのですが、途中でエラーが出ているので、「成功」とは言わずに「完了」としておきます。

%PCSIUI-I-COMPWERR, operation completed after explicit continuation from errors

        **************************************************************

        *                                                            *

        *                        W A R N I N G                       *

        *                                                            *

        *  One or more errors were encountered during installation/  *

        *  upgrade.  The target system may not operate correctly.    *

        *                                                            *

        *  You should correct the condition that caused the error(s) *

        *  and repeat the installation/upgrade.                      *

        *                                                            *

        **************************************************************

    The installation is now complete.

先日インストールしようとしましたが、途中でエラーが出たのでインストールを中断しました。同様の問題は他でも出ているようで、VSIのフォーラムで「Error installing 8.4L1 on FreeAXP 4.0」として報告されています。そこでは次のように書かれています。

This is almost certainly a bug in the VSI OpenVMS Alpha V8.4-2L1 kit and indicates, that VSI has never tested a fresh install of this kit on an empty or non-OpenVMS system disk. The 'workaround' seems to be easy: do not abort the installation.

要するにインストール中にエラーが発生し「Terminating is strongly recommended.  Do you want to terminate? [YES]」というメッセージが出る（しかも2回も）のですが、それを無視して続行すれば良いということです。

Portion done: 0%...10%

 

%PCSI-E-OPENOUT, error opening DISK$ALPHASYS:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; a

s output

-RMS-E-FNF, file not found

%PCSI-E-OPFAILED, operation failed

Terminating is strongly recommended.  Do you want to terminate? [YES] no

 

%PCSI-E-OPENIN, error opening DISK$ALPHASYS:[VMS$COMMON.][SYSLIB]DCLTABLES.EXE; 

as input

-RMS-E-FNF, file not found

%PCSI-E-OPFAILED, operation failed

Terminating is strongly recommended.  Do you want to terminate? [YES] no

 Portion done: 20%...30%...40%...50%...60%...70%...80%...90%

%PCSI-I-PRCOUTPUT, output from subprocess follows ...

% - Execute SYS$MANAGER:TCPIP$CONFIG.COM to proceed with configuration of

%   HP TCP/IP Services for OpenVMS.

% 

 Portion done: 100%

この後は、インストーラを終了し、改めてCCLプロンプトから、インストールしたディスクを指定してブートします。ブート中にシステム・パラメータの調整が行われ、自動的に再起動されますが、無事に完了しました。

  Accounting information:

  Buffered I/O count:               3942      Peak working set size:       6736

  Direct I/O count:                 1786      Peak virtual size:         186624

  Page faults:                      4754      Mounted volumes:                0

  Charged CPU time:        0 00:00:03.97      Elapsed time:       0 00:01:10.28

 Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1

Username: system

Password: 

インストール中にVSIから提供されたVMS Software Community Licenseを入れたので、これでOSのインストールは終了です。

これまではDEC/COMPAQ/HPEのHobbyist OpenVMS Programを利用していましたが、これからはVSI版を使っていくことになります。

stage

 Japan Times Alphaの2020年8月21月号に掲載されたコラム「Odds & Ends」（James Tschudy）の話題は「stage」でした。このコラムは毎月テーマを決めていて、8月のテーマは「Japanese English」です。日本人は英語だと考えているけど、ネイティブが理解している意味から外れており、コミュニケーションの障害にもなるものです。

コラムでは、ミュージカルを観にいった女性から「It was a wonderful stage.」と言われたという逸話が語られています。日本人が使う「stage」というのは、英語ネイティブからすると理解に苦しむので、本来の使い方についてコラムで語られます。

著者は、何故日本人がミュージカルなどの演劇のことを「stage」と呼ぶのかわからないと書いています。

I wonder how the Japanese-English meaning got started.  It might have come from "stage play," but I don't have any idea.  My dictionary isn't any help either.

これは私見ですが、日本人が英語で「stage」を使ってしまうのは、日本語ではミュージカルなどを（「演劇」と呼ぶこともありますが）「舞台」と呼ぶからなのではないでしょうか。日本人に限らず、外国語を使う場合（日本人が英語を使う場合もそうですが）母語の影響は無視できません。日本人がミュージカルを鑑賞して「素晴らしい舞台だった」と感想を述べるのを、英語で「It was a wonderful stage.」と直訳してしまったからではないかと思うのですが、どうでしょうか。

VSI版OpenVMS Alpha 8.4-2L1のインストールに失敗

Digital PersonalWorkstation 500auのシリアルコンソールが使えるようになりました。またVSIから入手したOpenVMS AlphaのZIPEXEファイルを展開してISOファイルを取り出し、CDに焼いてあります。これで準備が整ったので、DEC版OpenVMS Alpha 7.2がインストールされていたマシンを、VSI版OpenVMS Alpha 8.4-2L1にアップグレードしてみました。

しかし残念ながら、アップグレードに失敗しました。まず最初は、システムディスクのファイルを残してアップグレードを試みましたが、エラーが出てしまいました。

The following product has been selected:

    VSI AXPVMS OPENVMS V8.4-2L1            Platform (product suite)

 

Configuration phase starting ...

 

You will be asked to choose options, if any, for each selected product and for

any products that may be installed to satisfy software dependency requirements.

 

%PCSI-E-UPGRADERR, existing version of product that VSI AXPVMS OPENVMS V8.4-2L1 

upgrades is incorrect

Terminating is strongly recommended.  Do you want to terminate? [YES] 

%PCSI-E-S_OPCAN, operation cancelled by request

%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

    Installation has been aborted.

システムディスクに残っているファイルが悪影響を及ぼしているかもしれないと思ったので、次にシステムディスクを初期化するようにしてインストールを試みましたが、やはり失敗しました。

Execution phase starting ...

The following products will be installed to destinations:

    VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1     DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS CDSA V2.4-320A              DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS DECNET_OSI V8.4-D           DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS DWMOTIF V1.7-F              DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1    DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS HPBINARYCHECKER V1.1-A      DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS KERBEROS V3.1-152A          DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS OPENVMS V8.4-2L1            DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS SSL V1.4-502A               DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS SSL1 V1.0-2JA               DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS TCPIP V5.7-13ECO5F          DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS TDC_RT V2.3-1220            DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS VMS V8.4-2L1                DISK$ALPHASYS:[VMS$COMMON.]

 

Portion done: 0%...10%

 

%PCSI-E-OPENOUT, error opening DISK$ALPHASYS:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; a

s output

-RMS-E-FNF, file not found

%PCSI-E-OPFAILED, operation failed

Terminating is strongly recommended.  Do you want to terminate? [YES] 

%PCSI-E-CANCEL_WIP, termination resulted in an incomplete modification to the sy

stem

%PCSI-E-S_OPCAN, operation cancelled by request

%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

    Installation has been aborted.

このエラーについては、同様の現象がVSI OpenVMS Forumやcomp.os.vmsでも報告されています。

1. Error installing 8.4L1 on FreeAXP 4.0
   
2. Problem connecting OpenVMS to linux via ssh
   

このマシンはインストール出来ることを、VSIが正式に保証しているわけではないので、うまくいかないことがあってもやむを得ないと思いますが、なんとかインストールを成功させたいと思います。

Digital PersonalWorkstation 500auのシリアルコンソールが復活した

Digital PersonalWorkstation 500auの基盤に取り付けられているCR2032を交換しましたが、何故かシリアルコンソールが出なくなってしまいました。何か表示が出るとか、ビープが鳴るなどの、何らかのアクションを起こしてくれれば、それを手掛かりに原因究明をおこなうのですが、何も出ません。このマシンにはグラフィックスボードもついており、もしかするとグラフィックス画面に何か表示が現れているのではないかとも考えられますが、（Web上でみかけた情報によると） ディスプレイやキーボードが接続されていなければ自動的にシリアルコンソールが有効になるそうです。

数年前にもシリアルコンソール出力に異常があり、その時に試行錯誤した記録を確認してみました。その時には、メモリスロットにあるメモリを、手持ちのメモリと入れ換えて様子をみたようです。そのうちになんとなく直ってしまったので、最終的に何が問題だったのかは不明なままです。今回も原因が不明（少なくともCR2032の交換が原因ではないと思う）ですが、前回同様メモリあたりから確認してみようと思います。

現状を確認すると、このマシンはメモリスロットが6本あり、2枚ずつ3組挿せるようになっています。基盤にはDIMM5、DIMM3、DIMM1と印刷されているのが見えます。メモリは次のようになっていました。

1. DIMM5：54-25092-DA x2
2. DIMM3：54-25092-DA x2
3. DIMM1：IO-DATA PC133 E133-256M

ひとまずメモリを全て取り外して電源を入れてみます。するとビープ音が鳴り異常を通知します。シリアルコンソールには何も表示がありません。

次にDIMM5に54-25092-DA x2だけを取り付けて電源を入れてみました。すると（もちろんビープは鳴りません）シリアルコンソールに表示が現れました。CR2032を交換したことで初期状態に戻ってしまったようでAlphaBIOSが起動しましたが、これはSRMに変更すれば良いだけの事です。ともかくシリアルコンソールが復活したのは大きな前進です。

今度はDIMM5にIO-DATA PC133 E133-256 x2だけを取り付けて電源を入れてみました。するとビープ音がなり、シリアルコンソールには何も表示がありません。これが問題の原因なのかもしれません。基盤を見ると、メモリスロットの側にLEDが8個あり、マシンの状態を示しているようです。上下に4個づつ配置されており、上段は「ON-ON-ON-OFF」、下段は「OFF-OFF-ON-ON」でした。

どうやらメモリに問題がありそうなので、DIMM5に54-25092-DA x2を、DIMM3に54-25092-DA x2を取り付け、DIMM1は空きのままとしました。この状態で電源を入れると、ビープも鳴らず、シリアルコンソールにも出力が現れました。CR2032を交換しているので、AlphaBIOSには戻らずSRMのままです。ちなみに、この状態でLEDを確認したら、上段は「ON-ON-ON-OFF」で、下段が「OFF-ON-OFF-OFF」でした。

これまではIO-DATAのメモリを挿したままでも問題が無かったのですが、偶々運が良かっただけだったのかもしれません。現状でもメモリは512Mあるので、問題はないでしょう。

>>>show config

Firmware

SRM Console:    V6.9-7

ARC Console:    5.67

PALcode:        VMS PALcode V1.20-14, OSF PALcode V1.22-17

SROM Version:   v5.90

Processor

DECchip (tm) 21164A-2   Pass   500 MHz  96 KBytes SCache 

2 MB BCache

PYXIS ASIC Pass 257

MEMORY

Memory Size = 512Mb

Bank      Size/Sets   Base Addr

------    ----------  ---------

   1        256Mb      00000000

   2        256Mb      10000000

BCache Size = 2Mb

Tested Memory =  512Mbytes

ともかくシリアルコンソールが復活したことで、VSI版OpenVMS Alpha 8.4-2L1を試してみることが出来るようなりました。

WebブラウザとWebアプリケーション

普段利用しているのはFirefoxです。そのOSはWindows10なので、以前ならInternet Explorer、最近なら旧EdgeとかChrome Edgeが入っているのですが、これまではFirefoxを利用してきました。

 

Webが登場してから、いろいろなブラウザが現れ、進化してきました。しかし当初から言われているのは、ブラウザによってWebアプリケーションの動きが違うという事です。昔のWebアプリケーションは、画面も機能もシンプルでした。それでもWebブラウザによって画面が崩れたりしましたが、Webアプリケーションの機能もシンプルなので、利用する側としては、それほど困りはしませんでした。

ところが最近は、Webアプリケーションの機能が深化してきたためなのか、Webブラウザによって特定の機能が動作しない事例が増えてきました。これは致命的です。

利用しているFirefoxのバージョンは80.0.1です。Firefoxの最近のバージョンでは、このブログの記事を編集する画面が、うまく動作していないのです。一方でGoogle Chrome 85.0.4183.83ならば、全く問題がありません。さらに最近気づいたのが、FirefoxだとStarbucksのリワード管理画面が開かないことです。これもGoogle Chromeなら問題ありません。これ以外にも、Firefoxでは機能しないWebサイトがあります。

 

このような現象は、Firefox自体の問題なのか、僕の設定や利用しているアドオンの影響なのか、よくわかりません。分かっていることは、Firefoxでは特定のWebサイトの機能が正常に動かないということです。

 

Webサイトを開発している側からすれば、多彩な利用者のWebブラウザ環境をフォローするのは困難でしょう。だからWebサイトが推奨するWebブラウジング環境を提示し、それで動くことを保証するのが精一杯だろうと思います。しかし利用者側にとってみれば、Webサイトが期待した環境とは異なっている場合も少なからずあります。その時に、利用者側の不具合を解決するためにWebブラウザに申告しても、必ず解決できるとは限りません。もしかすると将来のバージョンで解決するかもしれませんが、何時になるか分かりません。そうであれば、利用者が出来ることは、問題が発生するWebサイトは利用しないか、Windows10に付属する新Edgeを使うことにするか、いずれかでしょう。