2020/10/17

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

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


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

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

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


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


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

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


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


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


2020/10/09

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]

2020/10/07

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

2020/10/06

変体漢文とJapanese English

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


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


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

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

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

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

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

2020/10/05

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年ごとだろうが、マイクロソフトの方針として実現させてくれればよいことです。それなのに半年たってもリリースされないような状況が生まれるのは、いったいどうなっているんだと思います。

2020/10/03

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>


2020/10/02

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でログインできました。

2020/09/29

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とは」というような情報がみつかりません。とにかく試してみるしかないのかと思っているところです。

2020/09/27

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


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


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


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

2020/09/23

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に統一したいのですが、そううまくいくかどうか調査してみようと思います。

2020/09/22

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で接続してみましたが、うまく行きませんでした。問題の所在をつきとめて、接続できるようにしたいと思います。

2020/09/20

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とで挙動が変わったということでしょうか。この件はリリースノートには書かれていないようです。どういう理由で変更されたのでしょうか?

2020/09/12

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.」と直訳してしまったからではないかと思うのですが、どうでしょうか。

2020/09/08

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が正式に保証しているわけではないので、うまくいかないことがあってもやむを得ないと思いますが、なんとかインストールを成功させたいと思います。


2020/09/05

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を試してみることが出来るようなりました。


2020/09/04

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を使うことにするか、いずれかでしょう。

2020/09/03

PWS500auのCR2032を交換したらシリアルコンソールの出力が出なくなった

 Digital PersonalWorkstation 500auは、シリアルコンソールで利用しています。OpenVMSを利用するにはSRMにしておく必要がありますが、電源を入れるとAlphaBIOSが起動してしまいます。内部バッテリCR2032が切れてしまったのかもしれません。交換作業は難しくありません。過去(2009年頃および2014年頃)にも交換作業をしました。


新しいCR2032と交換して、電源を入れたところ、なぜかシリアルコンソールに出力が出なくなりました。このような問題が生じるとは考えていませんでした。おそらくAlphaBIOSが起動するだろうから、SRMに変更しようと思っていたのです。CR2032を交換したので、今後は電源を入れても、AlphaBIOSに戻ることは無く、SRMで起動するハズだと考えていました。事実、過去に交換した時には、そうだったのです。


シリアルコンソールに何も表示がでないと、手も足も出ません。何か故障でもしているなら、電源投入時の自己診断で、何かビープ音でも出そうなものですが、異常を知らせるような音は発していません。


このマシンは過去にもシリアルコンソールが突然出なくなる現象を起こしたことがあります。調べても問題の原因が不明で、いつの間にか現象が現れなくなっていたのですが、再発したようです。何が問題なのか不明なので、対処のしようもありません。かと言って、このままでは鉄屑になってしまうので、冷静に状況を確認しながら、解決を図ろうと思います。


VSI版OpenVMS AlphaのCDが焼けたことだし、早速インストールしてみようと思っていましたが、ひとまずお預けです。ZIPEXEの問題は解決しましたが、シリアルコンソールの問題が再発して、一難去ってまた一難という感じです。

VSI版OpenVMS Alpha 8.4-2L1のZIPEXE

VSI版OpenVMS AlphaのCommunity Licenseを取得したら、キットを提供している場所も教えてくれたので、ダウンロードしておきました。ところが拡張子が「ZIPEXE」になっています。自己解凍形式ZIPファイルだと思うので、Hobbyist OpenVMSとして入手したOpenVMS 7.3で実行してみましたが、エラーが出てしまいました。


問題が発生した時の基本的な態度は、エラーメッセージの意図するところを理解して解決を図ることです。それはそうなのですが、このアプローチでは解決までの道のりは遠そうです。別のアプローチとしては拡張子「ZIPEXE」とは何者なのか調べてみることです。このような拡張子は以前には見かけた記憶がありません。


comp.os.vmsで「ZIPEXE」というキーワード検索をしてみたら2006年8月30日付の投稿「Changes to OpenVMS Patch Kit Formats」が見つかりました。さらに投稿に対する応答の中に次のような記述を見つけました。

ZIPEXE is ZIPSFX. You can unzip it with your own UNZIP program on any platform you like (eg. you unpack the IA64 or VAX ECO on your MARVEL) and you can unpack it on the intended platform without any UNZIP.EXE (because it is part of the archive file).

ZIPEXEというのは、予想していたように自己解凍形式ZIPファイルのようですが、解凍するのは、unzipが使えさえすれば、OpenVMSでなくても良さそうです(自己解凍するなら、実行イメージとして有効なのはOpenVMS Alphaだけだと思いますが)。そこでFreeBSD/amd64 12.1上のunzipを使ってみまたところ、解凍することに成功しました。これならエラーメッセージの調査は不要です。


3つあったZIPEXEの中は、次のようになっていました。

  1. ALPHA0842L1.ZIPEXE

    Archive:  ALPHA0842L1.ZIPEXE

      Length     Date   Time    Name

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

     623616000  02-07-17 15:46   ALPHA0842L1.ISO

  2. ALPHA0842L1DOC.ZIPEXE

    Archive:  ALPHA0842L1DOC.ZIPEXE

      Length     Date   Time    Name

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

      4722688  07-19-17 11:43   AVMS842L1DOC.ISO

          540  07-19-17 11:43   AVMS842L1DOC.ISO_VNC

  3. AVMS842L1DOC.ZIPEXE

    Archive:  AVMS842L1DOC.ZIPEXE

      Length     Date   Time    Name

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

      4722688  07-19-17 11:43   AVMS842L1DOC.ISO

          540  07-19-17 11:43   AVMS842L1DOC.ISO_VNC


ここで2番目と3番目は、ファイル名が違いますが、中に入っているファイルは同一のようなので、実際には1番目と2番目だけで良いのでしょう。


次の問題は、ZIPを解凍すると出てくるISOファイルの中には何が入っているのかということです。Microsoft Windows10のエクスプローラーではISOファイルをマウント出来るそうなので、確認してみました。AVMS842L1DOC.ISOの方は、次のようになっていました。

 ドライブ E のボリューム ラベルは AVMS842L1DOC です

 ボリューム シリアル番号は 4F70-5FF6 です


 E:\ のディレクトリ


2017/01/27  02:38           575,985 VSI_OVMSALPV842L1_SPDQS.PDF

2017/01/24  02:44         1,960,883 VSI_OVMSALPV842L1_UPG.PDF

2017/06/22  03:03           599,634 VSI_OVMS_ALP842L2_NFRN.PDF

2015/05/12  00:36           454,876 VSI_OVMS_LMF_UTILITY.PDF

               4 個のファイル           3,591,378 バイト

               0 個のディレクトリ               0 バイトの空き領域

しかしALPHA0842L1.ISOをマウントしようとすると、「ファイルが壊れています」というエラーが出てしまいます。ただこれはISOファイルが壊れているという事ではないと思います。FreeBSD上で確認してみたところ、次のような結果を得ました。

ALPHA0842L1.ISO:                 Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'ALPHA0842L1 '

AVMS842L1DOC.ISO: ISO 9660 CD-ROM filesystem data 'AVMS842L1DOC'

Windows10がマウント出来るのはISO9660形式だけなのでしょう。ALPHA0842L1.ISOはOpenVMSのファイル形式「Files-11」になっているだけで、別に壊れている訳ではありません。


ALPHA0842L1.ISOをCDに焼いておかないと、インストール作業には利用できません。問題なのはWindows10のエクスプローラーでは、ISO9660形式のISOイメージしかCDに焼けないことです。どうしようかと思いましたが、PCの中に「Nero Express Essentials 12.0.20000」が入っていたので、これを使うことにしました。こちらはISO9660形式以外でもCDに書き込めるので、問題はありませんでした。


VSI版OpenVMS Alpha 8.4-2L1をインストールするためのキットが入手できたので、これをつかってDigital PersonalWorkstation 500auにインストールできるか試してみようと思います。

2020/09/01

%DCL-W-ACTIMAGE, error activating image CMA$TIS_SHR

VSIから入手したライセンスを利用するためには、VSI版OpenVMS Alpha 8.4-2を使用しなければなりません。現在はDEC版OpenVMS Alpha 7.3-1を利用しているので、アップデートするのか、それとも新規インストールするのか、方向性を考えなければなりません。


VSIからライセンスを入手した際に、VSI版OpenVMS Alphaのキットの所在も教えてもらいました。サイトにアクセスしてファイルを入手してみたのですが、拡張子が「.ZIPEXE」となっているファイルがあります。こういう拡張子のファイルはDEC時代のOpenVMSにはなかったと思います。どうやらHPE時代に登場したようです。VAX/VMS以来のセーブセットを使えば良いのではないかと思うのですが、何か問題があったのでしょうか。


この拡張子は自己解凍形式のZIP圧縮ファイルらしいのです。試しに実行しようとしたら、エラーになってしまいました。

$ run [-]avms842l1doc.zipexe

%DCL-W-ACTIMAGE, error activating image CMA$TIS_SHR

-CLI-E-IMGNAME, image file PWS500$DKA100:[SYS0.SYSCOMMON.][SYSLIB]CMA$TIS_SHR.EXE

-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image


さっそく躓いてしまいました。OpenVMSのバージョンが旧いのが原因なのでしょうか。なかなか順調には進んでくれません。

2020/08/25

Digital Persolal Workstation 500auのAlphaBIOSをSRMに変更

 先日VSIの「Community License Program」を申請してAlpha用のライセンスを入手しました。これを適用しようと思っているのは、自宅にあるDigital Personal Workstation 500auです。このマシンには従来「Hobbyist OpenVMS Program」として入手したライセンスを用いてOpenVMS Alpha V7.2を入れていましたが、VSI版OpenVMSに移行する必要があります。


準備作業のために久しぶりに電源を入れたら、ボタン電池が切れていたようで、AlphaBIOSが立ち上がってしまいました。このマシンはWindowsNTでも利用できるようになっておりAlphaBIOSが初期状態となるようですが、OpenVMSを利用する場合にはSRMに切り替える必要があります。もちろんSRMに切り替えておいたはずですが、バッテリ切れのために初期状態に戻ってしまったようです。


このマシンをWindowsNTで利用するならディスプレイやキーボードを取り付けておくところですが、OpenVMSとして使うならシリアルコンソールで十分です。ところがAlphaBIOSをSRMに変更しようとすると、ちょっと厄介なことになります。


数年前にも同じ作業をしたのでメモが残っていました。参考となる情報は「The OpenVMS Frequently Asked Questions (FAQ)」にある「14.3.7.3 How do I switch between AlphaBIOS/ARC and SRM consoles?」です。作業自体は、一度経験してみれば分かると思いますが、難しくありません。ただし注意すべきポイントが幾つかあります。

  1. シリアルコンソールであっても作業は可能ですが、画面表示でVT100エスケープシーケンスが多用されているので、それを解釈できる端末で作業する必要があります。僕はRloginを利用しました。
  2. 設定メニューを出すには「F2」などのファンクションキーを押す必要があるのですが、キーボードの「F2」を押しても遷移できません。前述したFAQにあるように、ファンクションキーの代替キーを入力する必要があります。例えば「F2」ならば「Ctrl-B」です。


これでAlphaBIOSからSRMに切り替わったのですが、電源を落とすと初期状態(ALphaBIOS)に戻ってしまうようです。ボタン電池の交換が必要なのでしょう。近いうちに交換しておこうと思います。

2020/08/22

イングリッド・バーグマン出演の1944年の映画「ガス燈」

2020年8月20日にNHK BSプレミアムで放送された映画「ガス燈」を録画しておいたので、視てみました。この作品から派生した「ガスライティング」という用語もあります。今日の状況と絡めて説明されることがあるので、その映画を視たいと思っていました。


作品の前半で語られてた伏線が最後に纏まり「THE END」を迎えます。後味の悪い結末にはならないだろうと思っていましたが、最後までハラハラしました。最後にポーラ(イングリッド・バーグマン)に対してブライアン(ジョゼフ・コットン)が語った言葉は未来への希望を抱かせます。現実もそうであることを願うばかりです。

2020/08/19

OpenVMS AlphaのVSI版ライセンス

VSIが発表した「VMS Software Community License Available」を入手してみたら、過去に「Hobbyist OpenVMS License」として入手してきたものと全然違いました。何か理由があるのだろうとは想像していましたが、念のためにメールで問い合わせてみました。


2020年8月18日15時前(日本時間)にメールを送信しましたが、正直言って、いつになったら返事が来るか不安でしたし、もしかすると返事が来ないかもしれないと思っていました。


ところがなんと、数時間後(日本時間の同日17時過ぎ)にはVSIの担当者から返事が届きました。VSIの公式サイトによればオフィスは米国マサチューセッツ州とスウェーデンにあるようです。いずれにしても日本時間とは昼夜逆転していると思いますが、それにもかかわらず素早く返信している事は好感がもてます。


ライセンスの構成が変わっているのは、VSI担当者からの返事によれば、HPEからOpenVMSの権利を引き継いだ時にライセンス体系の単純化が決められたからとの事です。僕も薄々そういう理由なのではないかと想像していました。


ライセンス体系が変化しているという事は、もはやHPEが提供していたような(もっと以前にはDECやCOMPAQが提供していたような)OpenVMS Alphaのライセンスは入手する術がないという事です。Hobbyist OpenVMSによるAlphaやVAXの旧バージョンのメディアを所有していますし、それをインストール出来るマシンも(AlphaもVAXも)持っていますが、ライセンスが無いので利用できないという事になります。


VSIがリリースしたOpenVMS Alphaに更新すれば、VSIのCommunity Licenseが利用できるのでしょう。VSI版OpenVMS Alphaが僕の所有している「Digital Personal WorkStation 500au」にインストールできるのか試してみようと思います。

2020/08/18

VSI版OpenVMS Alpha用のライセンスなのか?

VSIから送られてきた「OpenVMS Community License」には「ALPHA-SYSTEM」と「ALPHA-LP」という2つのPAKしか入っていませんでした。当初これは何だろうと思いましたが、Webを検索してみると2017年頃にVSIが発表した情報を見つけました。そこには次のような記述があります。

  • All OpenVMS & LP licenses included in Tiers
    • License PAKs
      • Alpha-System
      • Alpha-LP


OpenVMSが必要とするライセンスの仕組みは、DECが開発したものだと思いますが、それをCOMPAQもHPも踏襲してきていました。内部構造がどうなっているのかは知りませんが、プロダクトなどのライセンス管理単位で決められている名称が内部に組み込まれているのだと思います。その名称ごとに有効無効の管理や、有効期限の管理が行われていたのではないかと思います。


これまでHPEから入手してきた「OpenVMS Hobbyist License」では、システム関係とレイヤードプロダクト関係を合わせて112個のPAKが含まれていました。それが、たった2個のPAKにまとめられてしまっているので、おそらくVSI側の意向としては、ライセンス管理単位が細かすぎて不必要に手間がかかっていると感じていたのではないでしょうか。それをまとめてしまう気持ちは分からなくもありませんが、DECやCOMPAQがリリースしていたOpenVMS Alphaとの互換性が失われてしまっているのは否めないのではないでしょうか。


DEC/COMPAQ/HP時代のOpenVMSの内部にはライセンス管理名称として「ALPHA-SYSTEM」や「ALPHA-LP」は入っていないだろうと思います。昔は「OPENVMS-ALPHA-USER」とか「DW-MOTIF-UI-JAPANESE」などのように、細かく細かくライセンス名称が分かれていたので、このようなライセンス名称しか認識しないのではないかと思います。そうなると、VSIから入手した「OpenVMS Community License」を入れても認識されず、有効期限を過ぎたら「ライセンスが無効です」というようなエラーが出てしまう気がします。


VSIがリリースしたOpenVMS Alphaを使えば問題ないのだろうと思いますが、それは避けたいと考えています。なんとかならないだろうかと、とりあえずVSIに問い合わせのメールを送ってみました。返事がくるかどうかわかりませんし、たとえ返事が来たとしても、昔流儀のPAKを発行してくれることになるかもわかりません。


どういう結末を迎えるのか不明ですが、できることを探っていこうと思います。

2020/08/17

VSIからPAKが届いた、しかし・・・

VSIから2020年7月28日付で「VMS Software Community License Available」が発表されたので、2020年7月31日に「Community License Program」でPAKを申し込みました。ところが2週間ほど経っても音沙汰がなかったので、催促しようかと思っていました。


comp.os.vmsの「VSI Community License Program Update」を見ると、PAKが届いている人が現れ始めているようなので、僕のところにもそろそろ届くかもしれないと待っていたら、メール(送信日時:Sat, 15 Aug 2020 11:15:01 +0000)が届きました。

Hello Kazumi,

Thank you for your OpenVMS Community License application.

*snip*

Please click the following link to download the license PAK: 


ようやく連絡がきて安心しました。しかしダウンロードしたPAKがなんだか変です。


ダウンロードしたファイルはZIPで圧縮されています。その中にはコマンドプロシージャが入っているのは、OpenVMSなら、そういうものだろうと納得できます。しかしライセンスが「ALPHA-SYSTEM」と「ALPHA-LP」の2つだけしかありませんが、これで良いのでしょうか?これまでHPEから「OPENVMS HOBBYIST LICENSE REGISTRATION」として届いていたPAKには、以下に示すように、112種類のライセンスがありました。

$! PAKs(112) listed below include:

$!   ACMS, ACMS-REM, ACMS-RT, ACMSXP-DEV, ACMSXP-RT, ADA, ADA-PDO, ADAO-PDO, 

(以下略)


OpenVMSのライセンス管理の仕組みが不明ですが、VSIが送ってきた2つのライセンスで、HPEが発行した112のライセンスを代替できるものなのでしょうか。


もうひとつ不審なのが、有効期限が「/TERMINATION_DATE=14-JUL-2021」となっている点です。「/AUTHORIZATION=1-VSI-20200716-00021」のような情報もありますし、僕が申請した日付である2020年7月31日よりも前に準備していたファイルを間違って送ってきたのだろうかという疑いを持ちます。


問い合わせてみるのがよいかもしれません。


2020/08/14

「全粒粉」を「ぜんりゅうふん」とも読むのは何故?

 ウィキペディアで「小麦粉」を引くと、各種類の読み方が次のように書かれています。

  • 強力粉(きょうりきこ)
  • 中力粉(ちゅうりきこ)
  • 薄力粉(はくりきこ)
  • 浮き粉(うきこ)
  • 全粒粉(ぜんりゅうこ、ぜんりゅうふん)
  • グラハム粉(ぐらはむこ)
  • セモリナ粉(せもりなこ)


ここで「粉」を多くは「こ」と読みますが、「全粒粉」だけは「粉」を「ふん」とも読むようです。何故なのでしょう?


熟語には「重箱読み」とか「湯桶読み」のように、音読みや訓読みで統一されていない例外的な読み方があります。それが関係しているのかとも思いましたが、「グラハム粉」や「セモリナ粉」のように外来語と組み合わされている場合でも「粉」が「こ」と読まれていることを考えれば、読み方の問題ではないような気がします。


「全粒粉」の読み方も「ぜんりゅうこ」だけで良さそうなのに、何故「ぜんりゅうふん」も許容するのでしょうか。読み方が二通りあると誤解されることがあるので、厄介です。例えば「ぜんりゅうこ(全粒粉)の・・・」のような発言をすると、「『ぜんりゅうこ』って何ですか。もしかして『ぜんりゅうふん』の事を言っているんでしょうか。」のような対応をされる場合があるのです。

2020/08/08

VSIからライセンスが届かない

 VSIのサイトから申請した「OpenVMS Community License」が未だに送られてきません。何か申請に不手際でもあったのかと思い、再申請した方が良いのだろうかとも考えています。


comp.os.vmsの「The VSI Hobbyist program is Live!」の中にある2020年8月2日23時47分42秒の投稿には、次のように書かれています。

I got my verification link email at 12:08PM CDT on Tuesday, 28-JUL-2020 and nothing since then. So roughly 3.5 business days waiting so far. If it's a manual vetting of applications, they may have gotten quite a few to sift through

これを投稿した後でライセンスが届いたのか否かは不明です。


少なくともライセンスが届いてないのは僕だけではないようなので、もう少し待ってみようかと思います。しかしVSIのある米国にはお盆休みはないでしょうから、あと1週間くらい待っても何も応答がないようなら再申請しようと思います。

都心上空ルート

 

2020/08/02

梅雨が明けた

2020年の梅雨は例年よりも雨が多くなりました。全国各地で大雨により洪水などの災害が発生していますが、自宅の近所では幸いにも被害はありませんでした。しかし7月中は曇り空の日が多く、晴れ間は殆ど見られませんでした。気温も、梅雨寒という程ではありませんでしたが、夏前にしては肌寒く、「異常気象」だったと言えるでしょう。

ところが8月に入ると、6月末から見られなかった晴れ間が広がり、梅雨も明けました。そういえば蝉の声も聞こえないと思っていましたが、だんだん騒がしく鳴き始めたようです。

台風も発生しているようですし、夏らしくなってきました。酷暑は勘弁してほしいという気持ちもありますが、夏は暑い方が自然の営みとしては理に適っている筈です。

2020/08/01

VSIが「Community License Program」をリリースした

2020年7月末にHPEの「OpenVMS Hobbyist Registration」からPAKを申請しましたが、予想していたように、今のところPAKは送られてきていません。前回申請したPAKの有効期限が今年の年末まであるので、慌てることはないのですが、それが有効期限を過ぎてしまったら、どうしたら良いだろうかと考えていました。

comp.os.vmsを見たら「The VSI Hobbyist program is Live!」という記事が投稿されていました。VSIのサイトを確認したところ、2020年7月28日付で「VMS Software Community License Available」と発表されています。

申請フォームから必要事項を入力して送信してみました。ところがウィンドウが開いて何やら盛んにクルクル回っていますが、30分ほど待っても何も進みません。サーバが混んでいるかもしれないと思い、ひとまず画面を閉じました。これは2020年7月31日の午前7時頃です。VSIのサーバが何処にあるのか不明ですが、もしBoston近郊にあるとしたら、それは米国東部標準時間では前日の夕方くらいですから、ネットワークが混んでいる時間帯だったのかもしれません。

あらためて2020年7月31日の午後7時頃に申請してみたら、今朝は何も出てこなかった例のウィンドウに「申請を受け付けた」というような意味のメッセージが表示されました。やはりネットワークが混んでいたということなのでしょうか。

VSIがPAKを発行するために内部で何をしているのかわかりませんが、2020年8月1日夕方時点では、まだPAKは到着していません。HPEでも数日かかったことはあったので、週明けまでは待ってみますが、早く来て欲しいと祈っています。

2020/07/26

「VMS Hobbyist Licenses」は終わってしまったのか

今年3月に「VMS Hobbyist Licenses」の扱いが終了するというメールが届きました。しかし何時をもって扱いが終了するのか具体的に日付が書かれていた訳ではありませんでした。しかしcomp.os.vmsの「The Doom of VAX VMS Hobbyist Licenses?」を見ると、既に扱いが終了しているようです。

心配になったので、これまでライセンス発行を申請していたサイトから依頼をかけてみました。サイトは存在していましたし、(自動応答だと思いますが)メールも届きました。しかし数日待ってみましたが、ライセンスは届きません。過去にはライセンスが発行されるまでに数日間待たされたことがあったので、現時点で駄目だと判断するのは早すぎるかもしれませんが、ライセンスは発行されない可能性が高いだろうと思います(万が一届いたら、それはそれで有り難いことです)。

VSIのアナウンスでは、ライセンス発行を引き継ぐつもりのようです。しかし何時から発行が始まるのかは現時点では不明です。いずれにしても、ライセンス発行が行われることを待ち望んでいます。

2020/07/21

アイスマン

2020年7月18日にナショナルジオグラフィック・チャンネルで「アイスマンの真実:史上最古の殺人事件を追え!」(原題:Iceman Murder Mystery: Lost In The Ice)が放送されました。「アイスマン」というのは20世紀末にアルプス山中の氷河から発見された5000年前のミイラだそうです。これまでにも何度も報道されたり、TV番組や書籍などで取り扱われてきたようですが、寡聞にして知りませんでした。

ミイラならば世界中に存在しているし、古代エジプトのミイラは有名でしょう。しかし人工的なミイラは、その当時の権力者などが対象となっているので、当時の社会の価値観や技術水準に左右されます。それに対してアイスマンは、自然の中で偶然にミイラ化していますし、何よりも歴史上の有名人とは何の関係もない名もなき一個人であるところが、興味深いです。

現代から5000年前というと、紀元前3000年くらいです。中国の古代王朝「」だって紀元前1700年あたりですから、それよりも1000年以上も前になります。当然のことながらヨーロッパに王国のような権力者が存在していたわけでもなく、人々がどのような生活を送っていたのか、わからないことだらけでしょう。それを考えれば、ミイラと共に、身に着けていたものや道具類が同時に発見されたということは、その頃の社会を明らかにできるのではないでしょうか。

雑誌版のナショナルジオグラフィック日本語版を購読していたのですが、2011年11月号では「アイスマンを解凍せよ」という記事が掲載されていたようです。すっかり記憶から抜け落ちていますが、捨てずに残しているので、探し出して再読しようと思います。

2020/07/07

BloggerがFirefoxでは調子が悪い(Chromeなら大丈夫)

このブログはBloggerを利用しています。開設以来Firefoxを利用してきましたが、この数か月は調子が悪く、使い勝手がよくありません。

何かが変だと感じたのは、管理画面が刷新された時です。記事の中で一部のフォントを変更しようとしても変更されなくなりました。つい最近になって、記事を投稿する前のプレビュー画面が出なくなりました。

Firefoxは78.0.1を使っており、毎月のようにバージョンが上がりますから、常に最新版を利用しています。この数か月は、なんだか変だとは思っていましたが、いずれ修正されるだろう(FirefoxもしくはBloggerが)と思っていました。ところが、だんだん症状が悪化してきて、とても使いにくくなってきています。

試しにGoogle Chrome 83.0.4103.116を使ってみたところ、何の不具合もありません(この記事もChromeで書いています)。

普段はFirefoxを利用しており、Bloggerで記事を書くときだけChromeを使うのは、どうもスッキリしません。Firefoxで問題が起きるのは、Firefox側の問題なのか、Blogger側の問題なのか、よくわかりません。

Google ChromeとBloggerの相性が良いのは納得しますが、Firefoxでも問題がおきないようにして欲しいと願っています。

英語の俳句

俳句は日本語における伝統的な韻文ですが、英語で俳句を詠むこともあるようです。これはどういうことなのでしょうか。

俳句以外にも韻文はありますが、まずは俳句に限定して考えてみます。俳句としての形式がいろいろありますが、音の並びとして「五七五」になっています。これは万葉集以来に日本の韻文の伝統を踏まえているはずです。

例えば、有名な俳句「古池や蛙飛び込む水の音」の英訳は(例えば)「Old pond - frogs jumped in - sound of water」(Lafcadio Hearn (1898))があるようです。この英訳は直訳のように感じますが、それについてどうこう言おうというのではありません。

英語にも独自の韻文がある筈です。俳句において、日本語を英語に置き換えたとしても、日本語のリズム(韻文なのですから)や、言外の常識とか暗黙の了解などを、他の言語(英語など)に置き換えるのは、至難の業ではないかと思うのです。出来ない訳ではないと思いますが、容易とは思えません。

おそらく逆もそうでしょう。英語の韻文を日本語訳してみたところで、英単語の綴り上の類似さや、撥音上の相似さを、興味深く工夫して韻文にしても、日本語で同じように表現できるわけではないと思います。日本語的に韻文になったとしても、それは元の英語の韻文とは別の作品になってしまうのではないかと思います。

俳句などの英訳を否定しているのではありません。その困難さを考えているところです。

日本語の古典文学を英訳しようとする試みは数多くあります。俳句のような、極限まで表現を切り詰めたものより、『源氏物語』のような物語文学の方が、英訳しやすい(それでも難しさはのこるでしょうが)のではないかと思います。

if I were you

COVID-19の影響で新しい番組が収録できないからかと思いますが、NHKラジオ「遠山顕の英会話楽習」の2020年7月分の放送は、2019年8月分の再放送になっています。

第1週Daialog1(2020年6月29日放送)「Bugs on a House Plant!」では、次のような表現がありました。の箇所の訳文は「僕ならそれを残りの植物から離すけどね」となっています。
If I were you, I'd move it away from the rest of your plants.
文頭にある「If I were you」というのは仮定法における典型的な表現です。「(当然ながら私は、あなたではないけれども)もし私が、あなたであったなら」という意味を表現しています。

仮定法を使っているのであれば、文の後半にある「the rest of your plants」は、これで良いのでしょうか。文法的な正誤という事ではありません。前段で仮定法(私が、あなただったら)を使っているのですから、後段でも「(本当は、あなたの植物ですが)私の植物」と表現して「the rest of my plants」と表現しないのだろうかという事です。

テキストにある文でも文法的に誤りがある訳ではないし、その表現でも現実の英会話としては問題ないだろうと思います。ただ仮定法を使う(現実とは異なる状況に身を置く)のであれば、文全体を、そのような状況で統一させる方が一貫しているのかなと思いました。

2020/07/06

Windows10が起動しないので「システムの復元」をしようとしたら「ディスクにはエラーがあります」と出た

Windows10が起動しなくなり困っているという相談を受けたので、様子を見てきました。

マシンの電源を入れるとWindows10が起動せずに「自動修復」が始まるのですが、「自動修復でPCを修復できませんでした」という画面が出てしまうのです。そこで「スタートアップ修復」を行ってみると、「スタートアップ修復でPCを修復できませんでした」という画面になってしまいます。

次の手段として「システムの復元」を試してみたら、「ディスク(D:)にはエラーがあります」というダイアログボックスが出ました。そのダイアログボックスにある「ディスクのエラーを確認します」をクリックしてみたら、「このドライブではエラーが検出されませんでした。」というダイアログボックスに変わりました。ディスクにエラーがあったんじゃなかったのか?と思いました。それなのに何故エラーが検出されませんでしたというメッセージが出るのか、理解できません。

ここまで試してみても、「自動修復」も、「スタートアップ修復」も、「システムの復元」も、全部失敗してしまうのです。何かが変なのは確かですが、何かが変なので修復されないのです。

そこでコマンドプロンプトを出して「chkdsk d: /f」を実行してみました。すると不整合があったようで、幾つかのエラーが解決されました。

そこで再度「システムの復元」を試してみたところ、小一時間ほど時間はかかりましたが、過去のある時点の状態にシステムが復元されました。そして電源を入れ直してみたところ、無事にWindows10が起動できました。

やはり「ディスクにエラーがあった」のだと思います。しかし疑問なのは、GUIで「このドライブではエラーが検出されませんでした」というメッセージが出るのは何故でしょうか。ここでディスクの不整合が解消されているべきなのではないかと思うところです。

2020/06/23

TCP/IPの教科書:設計と実装

1990年代後半くらいから世界のネットワークはTCP/IPを主軸に展開されています。それ以前からTCP/IPは存在したし、今日でもTCP/IP以外のネットワーク・プロトコルは存在します。しかし現代社会では、ネットワークを専門にしていない普通の人達にとって、インターネットは欠かすことのできないインフラになっていると思います。

TCP/IPを勉強するために多くの書籍がありますが、中でも有名なのが次のシリーズでしょう。どちらも3巻シリーズとなっていて、第1巻が設計、第2巻が実装、第3巻がアプリケーションです。また和訳もありますが、原著の最新版に追いついていないし、値段も安いとは言えません。

以前から買おうと思っていましたが、和訳本は中古でも高価なので、二の足を踏んでいました。原著は英語なので、読むのに苦労しそうですが、中古なら安価に入手できます。IT関係の情報を得るためには英語は避けられません。苦手意識はあっても、取り組んでいくべきなのでしょう。

原著の中古本を買うとして、どちらのシリーズにしようか迷いました。それぞれに記述スタイルに違いはあるかもしれないし、重視するところが違っているかもしれません。しかしTCP/IPであることには変わりないので、どちらを読んでも同じような事が書いてあるだろうと予想されます。迷った挙句、中古本なら安価なので、両シリーズの第1巻(設計編)を買うことにしました。読んでみると、案の定、説明の仕方がに違いがありますが、両者を読み比べることで、理解が進むような気がします。

両シリーズとも第2巻は実装編です。TCP/IPの実装なら、FreeBSD/NetBSD/OpenBSDやLinuxのソースコードが入手可能ですから、それを見れば良いのではないかという考え方もあるでしょう。しかしカーネルのソースコードを何の予備知識もないままに見たところで、飲み込まれるだけです。そういうわけで第2巻(実装編)も中古本で入手することにしました。

第2巻は両シリーズでアプローチが大きく異なっていました。一方はBSDのNet2を参照していますし、他方はXINUの実装を参照しています。さらに説明の詳しさも大きく違います。Net2の解説は1000頁以上もありますが、XINUの解説は500頁程度です。

これで両シリーズの第1巻(設計編)と第2巻(実装編)を手に入れた訳ですが、今後は何かの折に辞書的に参照するような使い方になるのではないかと思います。

FreeBSDのpackageでPython3が重複する

自宅では中古のノートPCにFreeBSD/amd64を入れて使用しています。以前にFreeBSD/i386を使っていた頃は、アプリケーションを自前でコンパイルしていましたが、今はコンパイル済みのバイナリを入れるだけになりました。以前もそうでしたが、依存関係にあるアプリケーションは勝手にインストールしてくれるので、それが有り難かったり、困ったものだったりして、単純に嬉しいとは言い難いところです。

最近Python3が異なるマイナーバージョンで入ったことに、ふとしたことで気付きました。

> pkg info -a | grep '^python'
python27-2.7.18                Interpreted object-oriented programming language
python36-3.6.10                Interpreted object-oriented programming language
python37-3.7.7_1               Interpreted object-oriented programming language

Python3を明示的に入れた覚えはないので、何かのアプリケーションの依存関係にあって、インストールされたのだと思います。それは良いのですが、アプリケーションが期待するPython3のマイナーバージョンが決め打ちになっていたのではないかと思います。それで複数のマイナーバージョンが入ってしまったのではないかと思います。

このような現象は他にもあって、LLVMについても複数バージョンが入っているのに気付いたりします。今の時代は昔と違ってディスク容量に余裕があるので、複数バージョンが入っていても気にしなくても良いのかもしれません。

しかしながら、Python2とPython3が入っているのは許容できなくもありませんが、Python36とPython37が入っているのは、なんとかならないかと思います。

2020/06/19

ドライイースト(カメリヤ vs サフ)

昔から朝食はパンでした。過去にはスーパーで食パンを買っていましたが、約10年前にホームベーカリーを購入したので、それからは自宅で焼くようになりました。食パンさえ焼ければ十分で、しかも材料には拘りがありません。

Webで情報を探すと、小麦粉やイーストの銘柄の違いを云々する記事が見当たります。材料を変えることで、出来上がる食パン自体に違いが出るとは思います。しかし出来上がりの違いは材料の違いだけではないだろうと思っていて、いかに「厳選」された材料を取り揃えようとも、それだけで自動的に「最高」の食パンが出来上がるわけでもないのではないかと考えています。

焼きあがった食パンを食べてみれば「美味しい!」と思うかもしれませんが、それは「厳選」された材料を使っているからとは限らず、自分が手間をかけた事を知っているという心理的なバイアスの効果かもしれません。

こういう訳で(極端に言えば)材料は何でも良いと思っているのですが、COVID-19の影響により、スーパーの店頭から強力粉やドライイーストが姿を消しました。報道によると、外出自粛により自宅でパンを焼こうとする人が増えていて、売り切れるスーパーが増えているようです。いつも行っているスーパーの店頭でも、ドライイーストや強力粉が置いてある棚だけがガラガラでした。

まだ自宅に手持ち分があるので、それほど焦る必要はないのですが、この状況が何時まで続くか不明なので、長期化した場合に備えて、買える時には買っておこうかと考えていました。いつも行くスーパーで取り扱っているドライイーストが「カメリヤ」だったので、これまで長い間にわたってカメリヤを使っていました。ふと別の店でドライイーストを探して見たら「サフ」を見つけました。

サフのドライイーストは、Web記事で言及している事があるので、知ってはいましたが、現物を見たのは初めてでした。カメリヤよりは高価ですが、購入を諦めるほど高価という訳ではありません。たまには別のドライイーストを使ってみるのも興味深いかと買ってみようかとも思いましたが、いつも行くスーパーでドライイーストの供給が増えたらしくカメリヤが店頭に並ぶようになったので、結局サフは買わずじまいです。

Web記事によると、サフを使うと、食パンの膨らみが良くないことがあるとか、焼きあがった食パンがしっとりしているとか、数々の感想を読むことができます。これらは多分に主観的な表現なので、いざ自分がサフを使って食パンを焼いたとしても、カメリヤとの違いが出るか、さらに気付くかということは、なんとも言えません。

食パンの主たる材料は「小麦粉」です。他にもバターとか砂糖とか、小麦粉以外の材料が必要となりますが、ドライイーストも主役ではないだろうと思います。ドライイーストが、ただの端役なのか、主要な(?)脇役なのか、その役割の大きさは不明です。いつもと同じ廉価な強力粉を使っていながら、ドライイーストをサフに変えただけで、ほっぺたが落ちるような(!)美味しさに、劇的に変化するとも思えません。

ホームベーカリーで焼いた食パンが、美味しいか否かということは主観的に判断することになるので、Web上の記事を何百本読もうとも、結局は自分がどう感じたかということに過ぎません。自分で使ってみて、Web記事に書いてあった通りだと思うかもしれないし、そうは思わないと感じるかもしれません。

そういう訳で、手持ちの(カメリヤの)ドライイーストを使い切ったら、サフを使ってみて、自分自身で体験してみようと思います。

2020/06/10

Ganglia Monitoring Systemにおけるpythonメトリックのname属性

マシン環境をモニターするためのOSSとして「Ganglia Monitoring System」があります。標準的な構成を何も変更しないでインストールして利用しても構いませんが、独自にメトリックを作成してマシン環境を参照する事もできます。独自メトリックを自作するにはpythonを使用しますが、作成の仕方のコツを掴めば、作るのはそれほど難しくありません。

メトリックの処理はpythonで組みますが、メトリックの構成を規定するためにディスクリプタを初期化時に返す必要があります。その中には属性「name」があり、これが作成しているメトリックの名前となります。その名前規約として認められる文字長や文字種が明白に定義されている訳ではないようなので、時として問題が起きる場合があります。

名前に半角の英数字を使っているだけなら、別に問題は起きないと思います。また、記号類として、下線文字やハイフンを使う程度なら、差し支えないでしょう。

しかしながら記号類として「/」を使おうとしたら、問題が起きました。属性「name」で指定された文字列は、内部的にはRRDデータベースのファイル名として使われるようです。このために属性「name」において文字「/」が使われると、RRDデータベースのファイル名においてパス名が狂ってしまうようです。

他にも属性「name」に文字「%」が使われるのも、問題を起こす原因となり得るようです。GangliaのWebインターフェイスでは、属性「name」の情報がURLの中に現れます。その時に文字「%」があり、その文字の直後にある2文字が「16進数」を表す文字にマッチしてしまうと、URLエンコードにより別の文字として扱われてしまいます。

これ以外にも問題となる文字があるのか、もうこれだけなのかは、分かりません。しかも、今回問題となった文字が、Gangliaの内部構造の変更により、将来的には問題とならない可能性もあります。OSSはドキュメント類の不備をソースコードを参照する事で補う場合があるので、問題があれば調査して原因を突き止めることは(原理的には)可能です。しかし問題が本来どうあるべきかを知ることは容易ではないでしょう。OSSを利用する際には、そのような事も意識する必要があるのではないかと思います。

2020/06/09

Don't catch a cold.

The Japan Times Alphaで連載されているコラム「Odds & Ends」の2020年4月17日号のタイトルは「Health 3 Getting sick」でした。この中では、日本人は「Don't catch a cold.」とよく言うと書かれています。しかし英語圏ネイティブでは、このような表現をすることはなく、「Take care of yourself.」と言うのだと書かれています。さらに次のようにも書かれています。
Whenever I hear "Don't catch a cold," it reminds me of a mother talking to her small child.

コラムの著者も気付いているようですが、日本人が「Don't catch a cold.」という表現をするのは、日本語で「風邪を引かないで」とよく言うからです。日本人が日本語でそのような表現をすることは別に構わないのですが、日本人は英語で「Take care of yourself.」という表現を使うことを知らないのです。知らないから、日本語を英語に直訳したような表現になってしまうのです。その英語表現が、英語として破綻しているなら誤りに気付くところですが、英語でもそのような表現をしないわけではないようなので、単純な正誤の問題として考えることはできません。

よく笑い話になることですが、日本人は「お疲れ様です」のような表現をつかいますが、これを英語に直訳して「You must be tired.」と表現する人がいるようです(本当に居るのかどうかはわかりませんが)。この表現も英語構文的には誤りではないかもしれませんが、英語圏ネイティブが耳にすると、あまりの違和感にギョッとするようです。

日本語と英語の関係に限らず、自国語と外国語の翻訳においては、「意図の変換」をおこなう必要があるだろうと思います。

「空間」と「時間」という感性の形式

NHKで放映されている番組「100分 de 名著」の2020年6月のテーマは「カント 純粋理性批判」です。当初の予定では2020年5月に放映されるハズでしたが、COVID-19で制作が影響を受けたようで1ヵ月延期となりました。

NHK出版から出ているテキストでは、34頁に次のような記述があります。
「空間」と「時間」という感性の形式(感性にもともと備わった二つのフレーム)を抜きにして、事物を捉えることはできません。

「純粋理性批判」というのはイマヌエル・カント(1724~1804)の代表作で、難解な著作としても有名です。もっともこの書籍に限らず、哲学の書籍は、どれも難しいという印象を持つ人が多いでしょう。

話を戻して、「純粋理性批判」の解説の中で「感性の形式(空間と時間)」という説明が現れた事には驚きました。「空間と時間」というキーワードから思いつくのはアインシュタイン(1879~1955)による相対論における4次元空間(3次元空間+時間)の事です。

私たちが生きている世界は「3次元空間」なので、次元を落として「2次元空間(平面)」とか「1次元空間(直線)」を理解することは容易です。しかし次元を上げることは直観として理解できないし、図示することも不可能です。しかし相対論では「3次元空間」の次元を上げると「時間」を加えて「4次元空間」で理論を組み立てています。

カントは哲学であり、アインシュタインは物理学です。両者は時代が違いますし、学問分野も全く違うので、双方に交流があったとも思えません。そうでありながら、「空間」と「時間」を組み合わせることに自然な繋がりをみていることには、驚きを感じます。

お好み焼き(Japanese pizza)

The Japan Times on Sundayの2020年2月16日号に掲載されているエッセイ「Big in Japan by Mark Schreiber」のタイトルは「New outlets weigh whether new virus will affect Olympics」でした。その本旨から離れますが、文章の最後付近に次のような記述がありました。
127,000 tons of frozen processed foods such as okonomiyaki (Japanese pizza) and fried chicken parts (annual figures for 2018).

この文を見て気付いたのは、「お好み焼き」を「Japanese pizza」と訳していることです。

翻訳において訳語の選択は難しい問題だとは思います。世界中どこにでもあるようなものであれば、日本語で使われているある単語を英語で使われているその単語に置き換えることができるでしょう。しかし日本独自のもの(ここでは「お好み焼き」のようなもの)であれば、対応するものが英語圏に存在しないので、ローマ字(「okonomiyaki」のように)するしかないでしょう。多分それでは英語読者にとっては何のことか分からないだろうから「Japanese pizza」のように補足するのでしょう。「Japanese pizza」が適切な補足になっているかどうかは議論のあるところかもしれませんが、そのような表現で説明するという発想は新鮮でした。

2020/05/30

CANON MG3130のメンテナンス

Microsoft Windowsに繋いでいるプリンタはCANON MG3130です。購入した時期は忘れてしまいましたが、この製品は2011年モデルらしいので、もう10年弱ほど使っていると思います。本体価格に対して、インクの値段が高いのが気になっています。しかしプリンタ業界のビジネスモデルはインクで稼ぐらしいので、不満ではありますが、どうしようもありません。

それはさておき、1~2週間ほど前から印字が崩れるようになってきました。崩れる形態は様々ですが、(変な例えかもしれませんが)3D画像を専用メガネを使わずに見た時のようにブレていたり、また表の罫線がガタガタにずれてしまっていたりします。

Webを検索すると、印字調整をすると直る(ことがある)そうです。操作ガイドを参照しながら、印字調整をおこなってみましたが、全く復旧しません。そもそも印字調整用のパターン印刷自体が乱れまくっていて、これで本当に調整できるのだろうかと心配になるほどです。たまたま調子が悪かったのかもしれないと思って、何度も実行してみましたが、何度やっても駄目でした。

印刷が不良になったのは最近の出来事ですが、もう数か月前から用紙のローディングでも不調だったので、もしかすると寿命なのかもしれません。買い替える時期が来たのでしょう。それはそれでも仕方のないことですが、残念なことに最近プリンタインクを買ったばかりなのです。インクが無くなった時にすぐに印刷を継続できるようにするため、常に在庫を確保しておくようにしています。それが残っているのです。

MG3130のインクはBC-340/341ですが、大容量モデルBC-340XL/341XLを持っています。まだ開封していないので、プリンタを買い替えたら無駄になってしまいます。CANONで現在販売中のモデルでBC-340XL/341XLを利用できる製品は無いようです。

もし買い替えるとしてCANONならTS5330にしようか考えていました。1万円ちょっとで買えるようです。インクも必要になるし、想定外の出費です。なんとかMG3130を使い続ける方法はないかと、Webを検索してみました。

CANONのWebサイトでFAQを見ていたら「エンコーダーフィルムの汚れを確認し、汚れている場合は清掃してください」という情報がありました。さらに「【インクジェットプリンター】《動画》エンコーダフィルム清掃方法(MG4230/MG4130/MG3630/MG3530/MG3230/MG3130/MG2130/MX523/MX513)」で動画付きで説明されています。

そもそも「エンコーダフィルム」というのが何処の事なのかよく分からなかったのですが、動画の手順に従いクリーニングしてみました。紙コップに中性洗剤を入れた水を用意して、綿棒につけて汚れを落としてみました。購入依頼クリーニングをしたことが一度もないので、綿棒はすぐに汚れで黒くなってしまいます。綿棒を10本ほど交換しながら、綺麗になったと自己判断するまで汚れを落としました。

そして改めて印字調整シートを印刷してみたら、見違えるように綺麗な(まともな)調整シートがプリントされました。さらに印刷も試してみたら、今までの異常な印字が見違えるように普通に戻りました。クリーニングした効果があったようです。

CANONのFAQでは「プリンターはエンコーダーフィルムによりFINEカートリッジホルダーの位置を検出しています。」とも書かれています。汚れが酷かったので、印字位置が狂っていたのかもしれません。

これでプリンタを買い直す必要はなくなりました。MG3130は今後も使い続けられそうです。


2020/05/18

/usr/binを何と読む

Webを見ていたら「人によって読み方が違うことが多いテクノロジー用語、どんなものがある?」という記事をみかけました。読み方に差が生じる用語は多くあると思います。この記事にある「Linux」についても「リナックス」と読む人と「ライナックス」と読む人がいて、僕自身は「ライナックス」と読むことが多いです。

この記事を見て思い出したのが、/usr/binなどの「bin」を何と読むかです。僕は「ビン」と読みますし、そう読む人が多いようです。しかし「バイン」と読む人がいました。本人に何故そう読むか尋ねたところ、この「bin」というのは「binary」の略だと思うので、「バイナリ」を略して「バイン」と呼んでいる、と答えていました。この理屈は理解できなくもありませんが、僕自身の読み方が「ビン」から「バイン」に変える気持ちにはなりませんでした。

別な例を出せば、/etcの「etc」は何とよむでしょうか。僕は「エトセ」と読みます。何故なら「etc」は「et cetera」の略だと思うからです。これは上述した理屈と同じ発想です。だったら「bin」を「バイン」と読むように転向してもよさそうなところなのですが、そのつもりはないのです。人間の心はなんと不思議なのでしょうか。

2020/05/11

It was a Dark and Stormy Night.

NHKラジオで「遠山顕の英会話楽習」を聴くようにしています。以前は「ラジオ英会話」でしたが、数年前に講師が変わったので、こちらの番組に移ってきました。テキストも買い、スキットを暗唱できるのを目標にしています。

2020年5月の第2週Dialog 3(2020年5月11日放送)のタイトルは「It was a Dark and Stormy Night」でした。テキストでは「余りにもわざとらしい物語の出だしの例として有名」と説明されています。

日本語では「それは暗い嵐の晩だった」とテキストにはありますが、これは確か有名なコミック「ピーナッツ」でスヌーピーが作家になりきっている時によく見かける文ではないかと気づきました。このコミック以外で使われている事例は知りませんが、要するにアメリカでは定番のギャクネタということなのでしょう。

意外なところで、異なる二つの情報が繋がった、という気がします。

2020/05/07

The Feynman Lectures on Physics

物理学を学ぼうとする際の教科書として『ファインマン物理学』を勧める声が多くあります。この書籍は、原文では3巻組ですが、日本語訳では5分冊になっています。これまでにも図書館などで借りて読んだことがありますが、小説を読むわけではないので、短時間で読むことは出来ません。たいていの図書館では2週間くらいしか借りられないので、その時間ではとても足りないのです。何時でも読めるように手元におこうと考えても、けして安くはない買い物で、二の足を踏んでいました。

先日Webを見ていたら、ある記事の中で『ファインマン物理学』がWebで公開されていると書かれていました。調べてみたら「The Feynman Lectures on Physics」というサイトがあり、(もちろん原文ですが)書籍も全て読めるようになっていました。さらにファインマンの講義資料なども公開されており、とても充実しています。

ウィキペディアの「ファインマン物理学」に書かれていますが、この書籍は講義を書き起こして出来ているため、元々教科書として執筆された書籍とは成立が異なっています。厳密に言えば、これは教科書というよりも、副読本なのかもしれません。
この本はファインマンの講義のテープ起こしが元であるため、各章のまとめ、具体的な計算手順を示した例題、演習問題など一般的な物理の教科書が備えるべき要素が多く欠けており、講義の教科書や独習用としては採用しにくいといえる。

物理学に限りませんが、いかに著名な教科書であろうとも、真に理解を深めるには、テキストを読み流すだけに留まらず、実験したり、例題や演習問題を解いたり、式の導出を追いかけたりすべきだと思います。そういう事をすると、読むのにも時間がかかりますので、Webで何時でも読めるのは大変助かります。日本人としては英文なのが難点ではあります。しかし(和訳本にありがちな)変な翻訳だったり訳出が省略されていたりする事を考えれば、英文で勉強できる態度を身に着けておく方が、今後の自己の世界を拡げていくのに役立つでしょう。

2020/05/05

東京発大阪行145列車

先日書店で『日本鉄道歴史紀行』という書籍を見かけたので買ってみました。他の書籍などでは見られない写真や記事が多く、愉しみながら読んでいます。

「のんびり列車で育む旅の思い出 夜行普通・快速列車」(pp.42-43)の中に次のような記述がありました。
この大垣夜行だが、元々は明治22年から走っていた東京~神戸・大阪間の長距離普通列車が前身といえる。それが昭和43年の10月に行われた大規模ダイヤ改正(通称ヨンサントオ)で廃止される見込みだったが、この普通列車を惜しむ声が多く寄せられ、当時の国鉄総裁・石田礼助の決断で存続が決まった。

ここに書かれているような経緯や年代などが事実なのかどうか判断する材料を持っていませんが、有名な「大垣夜行」(現在の「ムーンライトながら」) が明治から続く列車の後継とは知りませんでした。

ふと思えば、最近『時刻表 完全復刻版 1964年9月号』も買っているので、明治からありヨンサントオで廃止されそうになった長距離普通列車が掲載されているかもしれないと思い、確認してみました。東京23時30分発大阪10時47分着145列車がありますので、おそらくこれがそうなのでしょう。ずいぶん時間がかかっていますが、途中で長時間停車して時間調整している訳でもなく、名古屋で9分間停車するのが最長でした。その1時間前には急行第2せっつ東京発22時30分大阪着9時30分113Mがあり、さらに前にも急行月光東京発22時大阪着8時57分17列車など多数の大阪行が運行されていました。

下り145列車に対応するのが上り144列車だと思いますが、こちらは姫路発12時58分東京着4時56分です。途中の停車時間も長く、京都で12分、米原で10分、大垣で7分、岐阜で5分、名古屋で11分、浜松で8分、静岡で5分、沼津で28分、熱海でも28分も停車しています。これだけ停車時間が長いのは東京に到着する時間を考えての事だと思いますが、それだも早朝5時前に東京に到着してしまいます。それなら姫路出発を遅らせられないのかと思いますが、そうもいかなかったのでしょう。