VentoyでVHD形式のファイルを扱う方法がよく分からない

Ventoyというものの存在を最近知りました。面白そうなので、使いこなしてみたいのですが、まだよくわからないところがあります。そのひとつが、取り扱えるファイル形式です。公式サイトには次のような記述があります。

Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files. 

 

いろいろな種類のファイル形式に対応しているんだなと思いましたが、どうも何か制約があるようです。例えばVHD形式の場合、可変長サイズには対応していないそうで、固定長でなければならないようです。さらに、VirtualBoxが使用するVDI形式でも構わないようなのですが（そういう情報を見つけました）、それが「公式の見解」なのか「それでうまくいくこともある」ということなのか、判断しかねています。

 

Ventoyには可能性を感じるものの、使いこなすには、まだまだ調査が必要だと思いました。まずはVHD形式を扱う方法については「Boot fully installed Linux OS's from .VHD or .VDI files using a Ventoy or Easy2Boot USB drive」というYouTube動画があるので、これを理解するところから始めようと思います。

Ventoyが面白そう

Webで「【上級者向け】USBメモリ1本で、いつものPC環境を丸ごと持ち出す方法」という記事を目にしました。USBにOSを入れておいて外出先で利用するというのは、これまでにも耳にするところです。Ventoyは、それと同じようなものだという言い方はできるかもしれません。しかしさらに一歩先を行っているようです。

 

公式サイトもあるようです。要するに、VentoyをインストールしたUSBを準備しておけば、そのUSBにISOファイルとかIMGファイルを入れるだけで、ブート時に選択できるようです。ISOファイルなどを入れるだけで済むというのが、簡単でいいですね。

 

面白そうなので、試してみました。VentoyをインストールするUSBは、i386とかx86_64など環境を選びません。しかし、僕が利用しようと思っているのはdynabook SS SX/15Aという32bitマシンなので、ISOファイルもi386環境用を入れておきます。ところが最近はi386環境用の提供が無くなっています。

 

もうひとつの問題は、各種OSのISOファイルはWebに溢れているのですが、Live環境用のISOファイルというのは意外に少ないことです。しかもi386用となると、さらに減少します。Live環境用ではないISOファイルをブートすると、たいていはインストーラが起動してしまうので、僕としては、あまり有難くありません。

 

今は、まだVentoyを試しに使ってみただけなので、あまり使いこんでいません。Live環境が起動できるだけでも面白いのですが、普段使いするには、ネットに繋ぐとか、ファイルを保存するとか、いろいろと考えることがあります。これから探っていこうと思います。

DroidCamは音声がデフォルトで無効になっている

私が使用しているWindows11のデスクトップPCには、WebCamがありません。先月まで使用していたWindows10のデスクトップPCも同様だったのですが、DroidCamというアプリケーションを使って、スマホをWebCamの代替としていました。

 

Windows10の頃には、DroidCam (Classic)というものを使っていました。Windows11のPCに更新したので、改めてインストールしようとしたら、Android側もWindows側も新しくなっていました。それを使ってみたのですが、画像は出るのですが、音声が相手に伝わりません。Windows10の頃、つまりClassic版では、そんなことはありませんでした。何かが悪いと思うのですが、何が悪いのか見当もつきません。少なくとも、DroideCamの公式サイトでは「Chat using "DroidCam Webcam" on your computer, including Sound and Picture.」と謳っているので、画像だけでなく、音声も使えるはずなのでしょう。

 

困ったときにはWebを検索してみるのが常套手段ですが、利用者がそれほど多くないのか、あまり情報が得られません。そこでDroidCamの公式サイトでFAQを調べてみると、次のような情報がありました。

You can enable audio transfer by ticking the 'Enable Audio' option when adding a DroidCam source. Sound will be routed to the "Droidcam Audio" microphone on your system, which can be used as an input device in other programs. 

 

どうやら音声を有効にするには設定が必要となるようです。その「DroidCam source」として、USBで接続している私のスマホの設定を確認したら「Enable Audio」のチェックボックスがONになっていませんでした。これをONにしたら、どうやら音声が使えるようになったようです。

 

結局のところ、DroidCamではデフォルトで音声が無効になっていたのが原因だったようです。無意識のうちに、音声が有効となっているのがデフォルトだろうと思い込んでいたので、苦労してしまいました。 

ルームシューズとしてのケベックネオ

今年は猛暑でしたが、11月になり寒い日が増えてきました。自宅にいると、屋内でも足が冷えるので、冬の間はルームシューズを履いています。冬は家の中ではずっと履いていますが、夏は不要です。一年中使用しているわけではないのですが、毎年買い替える必要はないものの、だんだん傷んでくるので、数年ごとに買い替えています。

 

昨年使っていたルームシューズは、傷んできて処分したので、今年は何か買っておかねばなりません。これまでは無印良品とかホームセンターなどで探していました。今年も同じようにするつもりでしたが、ふと頭をよぎったのは、WORKMANの「ケベックネオ」がルームシューズとしてつかえないだろうかということです。

 

 この製品は、もちろん屋外用ですし、氷雪耐滑性に優れていることをセールスポイントにしています。公式サイトでは「防水構造と保温性の高い万能ブーツ」としてアピールしています。屋内使用は想定していないと思いますが、屋内使用禁止というわけでもないでしょう。当然ながら、いったん屋外で使っていたものを屋内に持ち込むのは、よくないと思います。しかし、購入してから、いちども屋外で使っていないなら、土埃もついていないでしょうし、屋内で使用しても問題ないでしょう。

 

そういうわけで、ケベックネオを買ってきましたので、今年はルームシューズとしてケベックネオを使ってみようと思います。屋外で使用されることを前提に「保温性の高い」とのことですから、屋内なら暖房不要の温かさ(?)ではないかと期待しています。

「Windows FAXとスキャン」から「Windowsスキャン」へ

Windows10の頃には、ちょっとした資料をスキャンするのに「Windows FAXとスキャン」を利用していました。PCを買い替えてWindows11に更新したら、「Windows FAXとスキャン」が見当たりません。Webを検索し「[Windows 11] スキャナーで原稿をスキャンする方法を教えてください。」に書かれているとおりに操作したのですが、「オプション機能を追加する」の中に「Windows FAXとスキャン」がありませんでした。困ってしまい更に調べると「「Windows Fax and Scan」は廃止ですか？」の回答の中に次の記述がありました。ここで書かれている操作をすると、確かに「Windows FAXとスキャン」を見つけました。

Windows 11 24H2なら「設定」→「システム」→「オプション機能」から「機能を表示」をクリックし更に「使用可能な領域を表示する」をクリックすると「Windows Faxとスキャン」が見つかると思います。チェックボックスをクリックしてチェックを入れて「追加」をクリックします。追加が完了するまで閉じないでください。  

 

これで一件落着ではあるのですが、Webを検索していたら「Windows 11で失われた!? Windows Fax and Scanのインストール・使い方徹底ガイド」という情報も見つけました。実際のところ、FAX機能は必要ないので、「Windowsスキャン」に移行しても構わないのです。Microsoftとしては「Windowsスキャン」への移行を促したいようです。今回は「Windowsスキャン」をインストールすることにしました。 

ショートカットアイコンの矢印を非表示になるように設定したら、タスクバーにピン止めできなくなった

Windows11において、ショートカットアイコンの左下に現れる「矢印」が非表示なるようにレジストリを操作しました。この結果、確かに「矢印」は非表示になったのですが、副作用がありました。いまのところ気づいたのは次のような事柄ですが、他にもあるかもしれません。

1. アプリケーションをタスクバーにピン止めできない。
2. 既にタスクバーにピン止めされているアプリケーションでは、クリックすると「指定されたファイルに対してこの操作を行うプログラムが関連付けられていません」というエラーが出る。

 

上述したような副作用が出たとしても、それを回避する操作がないわけでもありませんが、よけいな手間が増えるだけかもしれません。それでも、ショートカットアイコンの「矢印」が出なくなる方を選ぶのか、操作性が悪化するよりは「矢印」が表示されるのを許容するのかの、いずれかの選択になると思います。

 

Windows10の頃にはショートカットアイコンの「矢印」を非表示にしていたので、Windows11でも非表示にしたいところです。しかし操作性に悪影響がでるのは困りものです。当面は「矢印」が表示されるのを受け入れようと思います。将来的には、何か別の方法で非表示にしたいところです。 

Windows11においてショートカットの矢印を非表示にするための2つの方法

先月のWindows10のサポート終了を期に、新しいPCを購入し、Windos11を使い始めました。Windows10の頃とは使い勝手が変わっているところがあり、戸惑いもありましたが、徐々に慣れてきました。

 

Wndows10の頃には、デスクトップ上の「ショートカット」において「矢印」が表示されないようにレジストリで設定していました。Windows11でも同様にしたいと思い、調べてみると「Windowsでショートカットのアイコンから矢印を削除する方法 」という情報を得たので、設定しました。

 

確かに「ショートカット」の「矢印」は消えたのですが、不安定で、「矢印」があった辺りが「■」が表示されてしまいます。何かのタイミングかとも思いましたが、確かに「矢印」は消えていますが、その代わりに「■」が表示されているので、どうも具合がよくありません。

 

さらに調べてみたら「Windows11のショートカットの矢印を消してみた」という別の方法もありました。こちらを試してみたところ、「矢印」が非表示になりましたし、なによりも安定しています。

 

どちらの方法もレジストリを操作するので、注意が必要です。後者の方法が安定しているので、当初の設定は元に戻しました。 

リクライニングできるシートは別料金

「WestJet、一部の機体でリクライニングシートの利用を有料化へ」という記事によると、リクライニング可能なシートに座るには別料金が必要だそうです。また記事には、次のような記述もあります。

また、「座席を固定角度にすることで、後ろの席の人がシートを倒されたことによって個人的な空間が侵されるという感覚を軽減できる」という顧客テストの結果を挙げています。

 

リクライニングでシートを倒す際、後ろの席の人に声をかけるか否かという事は随分前から論争になっています。「リクライニングできる機能を持っているのだから、声をかけずに、席を倒して何が悪い。」と主張する立場もあれば、「リクライニングする際には後ろの席にご配慮ください」とアナウンスが流れている場合もあります。

 

このような問題は飛行機だけではなく、新幹線や特急電車など、さらに高速バスなどでも発生しています。

 

私自身はリクライニングを使いません。また前の席の人が、リクライニングを使う前に、声をかけてくれても、かけなくても構いません。ただし、リクライニングシートはフルフラットになるわけではありませんが、リクライニングの最大限近くまで倒されると、ちょっと一言欲しいとは思います。 

手招きジェスチャーの国内外の違い、さらに救急車のサイレンは「ピーポー」なのか「ポーピー」なのか

文化の違いと言ってしまえばそれまでかもしれませんが、身体動作によるジェスチャーは、日本と外国とで大きく違う場合があります。いろいろあると思いますが、例えば手招きのジェスチャーです。「国が変わればジェスチャーやしぐさも変わる！日本と海外の違いを知って正しくコミュニケーションを！」には、次のような記述があります。

その他、よく聞くジェスチャーとしては、手招きの違いがあります。日本では手のひらを下にして「こっちにおいで」と手招きしますが、欧米では「あっちに行け」という意味に捉えられてしまいます。外国人に手招きしたいときは、「手のひらを上」にして手招きすればOKです。

 

確かに 日本では、手のひらを下にして、ひらひらさせるジェスチャーが「こっちにおいで」を意味します。しかしよく考えると「あっちに行け」も同様のジェスチャーではないでしょうか。よく見れば、そのジェスチャーが「こっちにおいで」と「あっちに行け」とでは、ひらひらさせる様子が微妙に異なっており、日本の風習に通じていれば見分けられるのでしょう。しかしそうでなければ、その違いはわからないと思います。その点で、外国のように、「手のひらを上」にすれば「こっちにおいで」、「手のひらを下」にすれば「あっちに行け」となるのは、間違えようがありません。

 

ここで発想を飛躍させ、救急車のサイレンについて考えてみます。「ピーポー」という音が繰り返されるもので、緊急走行中には鳴らすことが法令で定められているそうです。その法令の条文を参照していないので、見当はずれなことを言ってしまうかもしれませんが、このサイレンは「ピーポー」の繰り返しなんでしょうか。それとも実は「ポーピー」の繰り返しではないのでしょうか。

 

このようなことは、今まで考えたこともなく、誰もが当然の事として「ピーポー」というサイレンを鳴らしていると思い込んでいるので、実際に救急車がサイレンを鳴らしながら緊急走行をしているのを目撃しても、頭の中では「ピーポー」の繰り返しであると認識しているのでしょう。しかし無理やり意識を変え、これは「ポーピー」の繰り返しだと思い込めば、そういう風にも聞こえてくるのではないでしょうか。 

 

救急車サイレンは、約770Hzと約960Hzの繰り返しだそうです。おそらく仕様書にも、そのように記述されているのでしょう。しかし第1声が約770Hzで、第2声が約960Hzだとまで指定されているのでしょうか。別に記述されているはずがないと主張するものではなく、書かれていても構わないのですが、おそらく2つの周波数の音を交互に発声するとしか規定されていないのではないかと思います。どちらが第1声で、どちらが第2声なのかは、別にどちらでも気にしないのではないかと推測するのです。 

 

このようなことをクドクドと気にして何になるのかと思われるところですが、確かにその通りです。しかし意識することもなく、当然のことのように思い込んでいる「常識」が何処からきているのかを、ちょっとくらい気にするのも一興ではないでしょうか。 

Windows11でMSFS2002を動かすと「ハードウェア アクセラレーションを使用」が有効だと異常終了してしまう。

Windows10のサポート終了を期に、Windows11を動かすために新しくデスクトップPCを購入しました。これまでWindows10で使用していた各種アプリケーションなどを移行し、移行できなかったものもありますが、日々の利用にあう環境を整えました。偶にしか使用しないアプリケーションもあるので、完全に以前と同じになったわけではありませんが、大筋で移行ができたと思います。

 

Windows10のPCでは、Microsoft Flight Simulator 2002をインストールしていました。あまり熱心に遊んでいたわけではありませんが、まだまだ興味を失っていないので、新しいWindows11のPCにもインストールしておきました。

 

基本的には動くのですが、すぐに異常終了してしまいます。このような現象はWindows10ではありませんでした。そもそもMSFS2002はWindow11をサポートしていないので仕方ありません。しかし設定オプションの「ハードウェア アクセラレーションを使用」を無効に設定すると、少なくとも異常終了はしなくなりました。しかし画面表示がおかしくなり、計器類が消えたり、一部だけが表示されたりして、困った状態になるのですが、我慢するしかないでしょう。

 

異常終了してしまう状況を確認するため「イベント ビューアー」を調べたら、次のような記録が残っていました。

障害が発生したモジュール名: ucrtbase.dll、 バージョン: 10.0.26100.6899、タイム スタンプ: 0x5554c871
例外コード: 0xc0000005 

 

ucrtbase.dllというのは「Universal C RuntimeライブラリのDLL」だそうです。例外コード: 0xc0000005の方は「アクセスバイオレーション」とのことなので、結構致命的です。これを解決するために利用者側でできることは何もないでしょう。 

「今度飲みに行きましょう」

親睦を深めるためなのか、単に飲み食いが好きなだけなのか、「今度飲みに行きましょう」と言い出す人がいます。言い方を変えて「今度飯食いに行きましょう」という場合もあります。このような発言の意図を問おうというのではなく、この発言から考えられる事を書き連ねてみたいと思います。

 

発言した当人と一緒に「食事」や「飲み」に行くとは限りませんが、誰でも食事はします。食事をせずに生きていける人はいないでしょう。「飲み」に行くというのは、暗黙的に「酒」を飲むということを意味していると思いますが、「飲みに行きましょう」と言っておいて、「珈琲」を飲むとか「お茶」を飲むということにはならないと思います。そうだったら、「珈琲でも飲みましょう」とか「お茶を飲みに行きましょう」とか言うでしょう。

 

会話の中で「今度○○しに行きましょう」という発言が出たら、その「○○」は、「誰でもすること」と一般に思われている事柄だと思います。もしかすると必ずしも「誰でもすること」ではない可能性もあります。「飲みに行きましょう」というのが、まさにそうです。しかしそこに「酒を」という含意があるとしても、「飲みに行きましょう」というのは、よく使われるフレーズには違いないでしょう。こう考えると、「○○」というのは、全員必ずする訳ではないが、大多数がする（と思われる）事柄なのかもしれません。

 

さて、「大多数がする（と思われる）事柄」ならば何でもよいかというと、そうでもなさそうです。例として適切なのかどうかわかりませんが、「ゴルフ」などはどうでしょうか。ゴルフを普段からするのがメジャーかどうかわかりませんが、一定数いることはまちがいありません。そこで「今度ゴルフに行きましょう」という発言が出たら、そこには前提として互いにゴルフ好きであることが確認されている必要があって、その上で発言しないと微妙な空気になってしまいます。

 

また別の例を考えますが、「パチンコ」などはどうでしょうか。昔々に比べると「パチンコ」は流行らないのかもしれません。それでも、前提として互いにパチンコ好きであることが確認されているとしても、「今度パチンコに行きましょう」という発言にはならないような気がしますが、どうなのでしょうか。パチンコというものは、個人で勝手に遊ぶものであって、誰かと一緒にするものではないからでしょう。

 

またまた別の例を出しますが、「キャッチボール」ならどうでしょうか。前提として互いにキャッチボールは嫌いじゃないことが確認されていて、しかもキャッチボールは相手を必要とするわけですが、それでも「今度キャッチボールしましょう」という発言が出てくるかというと考えてしまいます。レアケースとして無いわけではないとも思いますが、営業現場のトークとして出てくるような発言ではないでしょう。

 

結局のところ「今度○○しに行きましょう」という「○○」には、なんでも入るわけではなく、よく入るものと、絶対入らないものがあって、そのバリエーションは文化慣習なのでしょう。日本では当たり前でも、当たり前ではない文化があるかもしれません。逆に日本では考えられないのに、それが当たり前の文化があるかもしれません。そういうことを考えてみるのも愉快ではあります。 

WSLのインストールが簡単になった

Windows11を使うため、新しいPCを購入しましたので、Windows10だった旧PCで使っていたソフトをインストールし、同様の環境を作ろうとしています。その一環として「WSL」をインストールしました。

 

10年ほど前にWSLが登場したころは、まだ開発途上だったからでもありますが、インストール手順が面倒だった記憶があります。それなのに、今回Windows11においてWSLをインストールする手順は、とても簡単でした。Windows PowerShellのコマンドラインを開き、「wsl --install」と入力するだけです。あまりに簡単すぎて拍子抜けでした。

2010年問題

Windows11を使うため、新しいPCを購入しましたので、Windows10だった旧PCで使っていたソフトをインストールし、同様の環境を作ろうとしています。その一環として「The Complete National Geographic」をインストールしました。

 

インストールしようとすると、途中でエラーが出てしまいます。この問題は、事前に「Error Message During National Geographic DVD Install」という情報を得ていました。そこでの解決策は「What a crazy trick: change the date to 2010!」、という奇妙なものでした。なぜこれが解決策になるのか不思議ですが、試しにマシンの日付を「2010年」に変更してみたら、なんとインストールが完了しました。

 

インストール出来てしまいさえすれば、マシン日付を元に戻しても問題ないので、インストールが完了したら「2025年」に戻しておきます。これでNational Geographicの（英語版ですが）創刊号以来の記事がよめるようになりました。 

自動運転の車に違反切符を切る場合

the japan times alphaの2025年10月17日号の「This Week's OMG」には「California police couldn’t give this Waymo a ticket」が掲載されています。警察が、交通違反の車を停車させて、違反切符を切ろうとしたところ、自動運転の車だったので、違反切符を交付する相手がいなかったそうです。

 

記事では、自動運転の車だからドライバーがいないので、違反切符を交付する相手がいないという側面で書かれています。しかし僕が驚いたのは、自動運転の車でも、警察から停止を命じられると、それに反応して車を止めるという点です。

 

Webを探すと「自動運転レベル」について情報が得られます。「完全自動運転（SAE レベル5）」になると、「常にシステムが全ての運転タスクを実施」するそうですが、「全ての運転タスク」とは何かが問題になると思います。障害物を避けるとか、道路を逸れないとか、信号や交通法規に従うというのは、当然だと思います。ただし、そこに「警察から停止を命じられる」という状況が含まれているのでしょうか。もし含まれているなら、凄い技術だと感心します。

 

警察が停止を命じるというのは、アメリカでどうのようにしているのか知りません。しかし日本であれば、例えばパトカーから拡声器で、「前方の車は、減速して左側に停車してください」とか言うのではないでしょうか。「完全自動運転」の車は、それを聞き取り、停止を命じられていると判断し、減速して停車しなければならないわけです。これをやってのけるというのは、簡単ではないはずなのに、例の記事の車は停車したようなのですから、これは凄いことではないでしょうか。

 

もしかするとアメリカでは、逃走を防ぐため、停止させたい車の前に先回りし、進路を塞ぐようにして、停車を命じるのかもしれません。そうだとしても、自動運転の車が「警察から停車を命じられている」という状況を認識できなければ、前方の障害を避けようとして、車線を変更し、走行を続けるかもしれませんし、加速して走行し続けるかもしれません。これは、その車が自動運転だと気づいていない警察の側からすれば、「逃走を図っている」ように見えてしまうでしょう。下手をすれば、銃撃戦が始まってしまうかもしれません。

 

日本の現状は、JAFによると「SAE自動運転レベル3の「条件付自動運転車（限定領域）」まで実車化が進んでいます」だそうです。将来は日本でも、この記事のような光景が見られるのでしょうか。

USB-PS/2変換アダプタを使ったら、電源オン直後でもキーボード入力が可能となった

新しいPCを購入し、Windows11に移行しました。これまでWindows10を使っていたので、その頃と同等の環境に移行しようとしています。最低限の移行は済ませましたが、以前と同等とするには、まだ移行作業が必要です。

 

移行作業とは別に、新しいPCに変わったことで、いろいろと使い勝手が変わっています。大きな問題もあるし、小さな問題もあります。深刻な問題もありますし、些細な問題もあります。そのひとつが、ある日に最初に電源を入れた直後に、キーボードから入力ができないことです。最初は驚いたのですが、USBポートを刺し直すと、キー入力できるようになることがわかりました。ひとまず解決策は見つかっているのですが、毎日USBポートの刺し直しをするのは、些細な作業ですが、ちょっと憂鬱です。

 

Webを検索して同様の事例を探したり、いろいろな対策を試行錯誤したりしました。最終的に、原因や理由は不明なのですが、解決しました。その経緯は次の通りです。

1. USBポートに接続したキーボードが、ある日に最初に電源を入れた直後、入力できない。
2. キーボードが接続しているUSBを刺し直すと、入力できるようになる。
3. タイミングの問題化と思い、電源を入れた直後にはマウスなら使用できるので、再起動させてみた。しかしキーボード入力ができるようにはならなかった。
4. USBポートを変えてみた。USB2のポートに刺していたのを、USB3のポートに変更してみた。しかしキーボードが入力できるようにはならなかった。
5. キーボード自体はUSBですが、たまたま手元に「USB-PS/2変換アダプタ」があったので、これを使ってPS/2キーボードのポートに刺してみた。
6. なんと、ある日の最初に電源を入れた直後でも、キーボード入力ができるようになった。

 

キーボード本体は同じなのに、USBポートではダメで、PS/2ポートならうまくいくというのが、不思議です。手元にあった変換アダプタは、使用しているキーボードを購入した際に付属していたものです。その当時から、キーボードはUSBポートに刺していましたので、不要だったので捨ててしまっても構わなかったのですが、何となく残しておきました。それが今になって役にたちました。

 

この変換アダプタについては「かつてマウスやキーボードに付属していたUSB端子をPS/2コネクタに変換するアダプターの仕組みについてMicrosoftの開発者が解説」という記事を見つけました。また「実はゲーマー向き？PS/2キーボードが見直されるかもしれない」という記事も見つけたので、PS/2ポートが見直されているのかもしれません。

自宅の柿の木が今年は豊作

10年ほど前に、ホームセンターで柿の苗木を購入し、自宅の庭に植えました。その2年後に初めて数個の柿の実がなり、それ以来、毎年秋には柿を食べるのを楽しみにしています。

 

今年は、大豊作です。夏の終わりごろから沢山の実がついていて、とても食べきれないだろうと思っていました。熟してから食べ始めても間に合わないだろうと思ったので、多少早いかなと思うころから食べ始めました。あまりにも沢山実っているので、食事ごとに2個も3個も食べ、今時点で90個も食べましたが、まだ柿の木には数十個以上も実っています。

 

そろそろ完熟して、自然に地面に落ちてしまう実も出てきました。それでも不思議なのは、一斉に完熟するわけでもないことです。完熟した実の隣には、まだ熟していない実も並んでいて、そういうものなのかと思って眺めています。

 

木の上の方に実っている柿は、脚立に上らないと手が届きません。日の当たりも良いので、完熟に近くなっているようです。それを採りにいくよりも、下の方から先に食べていこうと思います。おそらく、上にたどり着くまでに、完熟して自然に落ちてしまうのではないでしょうか。 

Windows11にはssh-addがあるようだ

Windows10のマシンを使っていたころは、LaTeXやRの処理をFreeBSD/amd64のマシンで実行させるため、リモート処理を行うスクリプトを書いて使っていました。内部ではRSHを利用してリモート側のコマンドを起動させていました。Windows10に元々RSHが入っていたのか、どこからか探してきたのか忘れてしまいましたが、少なくともWindows11にはRSHがありません。その代わりにSSHが標準で入っています。

 

RSHを利用している処理をSSHを使うように変更するのは簡単ですが、SSHにするとパスフレーズを入力しなければならなくなります。それが嫌ならRSHを使うしかないのですが、今さらWindows11用のRSHを探してくるのも、発想が時代遅れという気がしなくもありません。パスフレーズを入力する手間がかかっても、これからはSSHを使うのが良いでしょう。

 

そう思っていたところ、「Windows 11 標準機能でOK！SSH接続時にパスフレーズ入力を省略する方法」という記事を見つけました。ssh-addは、UNIX環境で使ったことはありますが、Windows11でも利用可能とは知りませんでした。記事にある手順で、「OpenSSH Authentication Agent」を開始し、ssh-addで秘密鍵を登録しておきます。この状態でSSHを利用したところ、パスフレーズを入力する必要がありませんでした。これこそ、私が求めていたものです。

 

これでRSHを使うことなく、SSHを使って、これまで使っていたスクリプトを動かすことができます。 

電源オン直後にキーボードが反応しないのはタイミングの問題ではなかった気がする

新しいPCでWindows11を使い始めていますが、ちょっと困っているのが、電源オン直後にキーボードが反応しないことです。USBを刺し直したら使えるようになるので、何とかるのですが、ちょっと不便であることには変わりありません。もしかしたら、新しいマシンが速すぎるので、キーボードの初期化が間に合わないのではないかと思いました。

 

電源をオンにして、Windows11ログインのためにパスワード入れるところではキーボードが使えませんが、マウスは問題なく動きます。そこで、マウスを使い再起動させてみました。もしPCが速すぎてキーボードの初期化が間に合わなかったのであれば、再起動させるタイミングなら時間的な余裕は十分ありそうですから、今度はキーボードが使えるのではないかと考えました。

 

試してみたのですが、結論からすると、ダメでした。やはりUSBの刺し直しが必要です。

 

いったい何が原因なのか不明なので、何か出来そうなことを試してみるしかありません。次に試してみようと思っているのは、USBポートを変えてみることです。このPCにはUSB2ポートとUSB3ポートがあります。キーボードやマウスは、USB3を使うほど高速なデバイスではないので、USB2ポートに刺していました。これをUSB3ポートに変更してみます。これでどうなるかは、明日の朝に電源を入れたときに判明するはずです。 

電源オン直後にキーボードが反応しない

新しいPCでWindows11の移行作業を進めています。まだ状況を完全には把握できていないのですが、深刻といえば深刻なのですが、当面の解決策がないわけではない問題が発生しています。

 

状況としては、次の通りです。

1. 電源オン直後にキーボードが反応しない。
2. USBケーブルを刺し直すとキーボードが使えるようになる。

 

Windows11起動直後は、ログインするユーザのパスワードを打つ必要があるのですが、キーボードが反応しないので、入力できません。しかも、例えばNumLockキーを打てば、該当するLEDが点灯または消灯するはずなのですが、何も反応がありません。最初にこの状況に遭遇した時には、（大袈裟ですが）衝撃のあまり頭が真っ白になりました。ひとまず冷静に戻って、キーボードのUSBケーブルを刺し直したら、キーボードが使えるようになりました。それ以降も、毎日最初に電源を入れた直後は、こうなります。電源を入れたままで、再起動した場合には、このような状況にはなりません。

 

ネットを検索してみると、同様の現象に遭遇した人は、いるようです。どのケースでも試行錯誤していますが、解決に至っていないようです。

• Windows10にアップグレード後、起動時にキーボードから入力できなくなった(USBを挿し直すと入力できるようになる)
• デスクトップPCのキーボードが毎回電源をつける度に反応しなくなります。
• USB抜き差ししないと認識しない現象
  

 

私が使っているキーボードは、10年ほど前にWindows8時代に購入したデスクトップPCと同時に購入した「FILCO Majestouch BLACK 黒軸・フルサイズ・かななし」です。もう販売は終わっていますが、気に入っているので、キーボードを買い替えるという解決策は採用したくありません。

 

何が問題なのか皆目見当もつかないので、どこから調べたら良いのかわかりません。素人考えですが、一日の最初に電源を入れた直後だけキーボードが反応せず、USBを刺し直すと動き出すということは、新しいPCが速すぎて、キーボードの内部初期化が終わらないうちにWindows11が立ち上がってしまうのが原因なのではないかとも考えます。電源投入直後に、一定時間のウェイトを入れられれば解決しそうな気もするのですが、そんな事はできるのでしょうか。 

Windows10からWindows11に移行しました

Microsoftが「Windows 10サポートは 2025 年 10 月 14 日に終了しました」とアナウンスしているように、今までのようにWindows10かWindows11を選ぶ時期は終わりました。私が使っているのはデスクトップPCですが、Windows8の頃に購入したものです。その後、Windows8.1を経て、Windows10にバージョンアップして使ってきました。何分にも旧いマシンですので、Windows11の要件を満たしていません。そこでWindows11の新しいデスクトップPCを購入しました。

 

デスクトップPCは、毎日朝から晩まで使用していますから、利用できない期間が長引くと何かと差し支えます。さらに、随分前から代々引き継いできたファイルが蓄積されており、日々使うアプリケーションも偶に使うものも多々あります。これらのことを考えると、Windows10の旧PCからWindows11の新PCへの移行作業は、なかなか大変そうです。

 

これまでの蓄積されたファイルは、全コピーするとしても、使用しているアプリケーションは、毎日つかうものだけを入れて、あとは徐々にインストールしていこうと思います。それでも、なんやかんやで、結構多くのアプリケーションを入れなければならないのですが。

 

また移行作業を行うにあたり、以前から活用しているTW5で細かく記録をとっていきます。これは無駄な手間をかけていると考えることもできますが、長い目で見たときに、記録があれば記憶に頼らずにすむので、メリットがあるはずです。

 

そういう訳で、移行作業を断行しました。日常的に利用する環境を整えられていませんが、90%程度の完成度なので、これなら日々の利用に問題ないでしょう。ただし利用頻度が低いアプリケーションなどが入っていないので、まだ作業は続きます。それでも、この段階にくるまでは、二日間にわたり早朝から深夜まで没頭して作業しましたが、今後はペースを緩められるでしょう。

 

旧PCは、CPUがIntel core I3、メモリが8G、ストレージはHDDで512Gでした。新PCは、CPUは同じくIntel core I3、メモリが16G、ストレージはSSDで512Gです。ほぼ同等のスペックですが、CPUがIntel core I3で変わらないとは言っても世代が違いますから、速くはなっているでしょう。またストレージがHDDからSSDに変わったので、きっと速いはずです。

 

実際に新PCを使ってみると、Webブラウジングをしている分には、若干速いかと感じる程度です。これはマシンの性能よりも、ネットワークの応答速度の方が影響するからでしょう。ただし旧PCでは、ブラウザの設定が壊れかけていた為なのか、稀に反応が相当悪くなる場合がありました。一方で新PCは、まだインストールしたばかりだからかもしれませんが、応答はとても良いと感じます。

 

マシン単体で処理されるような場合、新PCは、極めて速くなった実感があります。これまでと同じ処理をすると、旧PCでは一呼吸あったところが、新PCなら瞬時に処理が終わります。

 

これまで長きに亘りWindows10を使ってきましたが、これからはWindows11を使うことになります。基本的には同じとはいっても、タスクバーとかスタートメニューの使い勝手とか、今までとは違うところがあるので、それに慣れていく必要があると思っています。 

映画「スティング」に影響を与えた書籍

ポール・ニューマンと最近亡くなったロバート・レッドフォードが共演した映画「スティング」は、1930年代のアメリカを舞台にした娯楽作品です。時代背景や騙す手口がよくわからなくても楽しめる作品ですが、背景を知っていると、より楽しめると思います。

 

ふとしたきっかけで、この作品は、David W. Maurerによる『THE BIG CON  The Story of the Confidence Man』を参考にしているという情報を得ました。この本の訳書が山本光伸による翻訳の『詐欺師入門  騙しの天才たち：その華麗なる手口』で、光文社から1999年に発行されています。近くの図書館が所蔵していたので、読んでみました。

 

原著が何時頃に出版されたのか分かりませんが、巻末には「名著復刊に寄せて」として「あなたが手にしておられるこの本は、残念なことに長いあいだ絶版になっていたが、このたび再販されたものである」と記されています。また「第八章」の「1 一番人気の「スマック」」という個所には「ちょうどこの箇所を書いているとき（1939年11月21日）」と書かれているので、1940年代に出版されてのではないかと思います。 

 

この書籍を原著者が出版した時には、「スティング」という映画が生まれるとは思ってもいなかったでしょう。しかし巻末の「名著復刊に寄せて」の中には「ジョージ・ロイ・ヒル監督は本書に触発されて『スティング』（1973年）を制作したが」と書かれています。

 

映画「スティング」の中では、ロネガンを騙す手口として「古い手だが電信を使おう」と相談するシーンが出てきます。この手口が、まさに本書では「第三章」の「1 電信を利用した「ワイヤー」」で詳しく書いてあります。これ以外にも、本書に書かれていることが映画「スティング」の端々で使われており、本書を読んだ後で映画を見れば、さらに楽しめるでしょう。 

 

映画「スティング」に限らず、どんな映画でも、もっと言えば、映画に限らず小説でもドラマでもそれ以外でも、背景事情に通じていると、より楽しめるものです。知らなくても楽しめるのがヒットする作品だとは思いますが、知識を持っていれば、うっかりすれば見逃してしまいそうなシーンでも、ピンとくることがあるでしょう。 

先月受験したTOEICの成績がオンラインで参照できるようになった

2025年9月にTOEIC Listening & Reading Testを受験しました。もう随分前から、学習の到達度を測定し、励みにもなるかと思って、毎年受験しています。最初の頃は、500点くらいでした。それから500点台が続き、あるとき600点を超えました。その後しばらくは600点台でしたが、COVID-19の前くらいに700点を超えました。勉強を続けてきた甲斐があったと喜んだのですが、それから点が下がりだし、直近の2～3年は、600点台に逆戻りしてしまっていました。

 

英語の勉強とTOEICの勉強は、近い関係にあるとは思いますが、TOEICに限らず受験する試験というものは、ある種の割り切りが必要となる場合があると思います。要するに、英語としては必要なのかもしれないが、TOEICでは出題されない分野は、躊躇せず切り捨てるという判断が必要だという意味です。それは受験対策としては必要かもしれませんが、英語の勉強としては、ちょっと違うのではないかと考えています。

 

TOEIC受験用の問題集を使って勉強していますが、率直に言って、どんな問題集であったとしても、問題集を解くだけでTOEICの成績が上がるとは思えません。当然ですが、問題集を一回解くだけではなく、何周もするのですが、十周しようが百周しようが、それだけでTOEICの成績が良くなるとは思えないのです。何か別のアプローチが必要だと思ってはいますが、それが何かは分からないままで、手探りで模索している状態です。

 

そんなこんなでTOEICを受験しました。例年同様、最後の20問ほどは「塗り絵」でした。それでも、いつもそうですが、試験を終えた直後はハイになっているのか、きっと良い成績に違いないと根拠なく思うのです。その後で成績が届いてガッカリするというのがパターンになっています。

 

今年も同じような経過をたどりました。オンラインで成績が参照できるようになったので、確認したら、listening:405、Reading:370で、合計775点でした。これは過去最高です。過去においてListeningは420点が最高点なので、そうなれば800点弱となりますから、目標としていた800点が視野に入ってきました。

 

得点が上がるのは結構なことですが、僕自身としては「塗り絵」をしなくても良いようになるのを目標としたいと強く願っています。今回の成績発表において、「Part7の複数文書問題の正答率が悪い」とアドバイスされましたが、それはそうでしょう、「塗り絵」なんですから。当面は「塗り絵」しなくても良いレベルを目標としたいと思いますが、それが達成できた頃には、800点を超えているに違いありません。 

Windows11移行作業のためのTeraCopyとRoboCopy

Windows10のサポート終了が目前に迫ってきました。現在のマシンがWindows11の要件を満たしていないので、新しいマシンが必要になります。既に購入し、手元にあるのですが、移行作業をおこなう時間的な余裕がありません。近いうちに移行しようと思っていますが、その前に、移行作業の手順を確立しておきたいと考えています。

 

普段使いのアプリケーションをインストールするのは、ある意味で単純な機械的な作業です。むしろ気になっているのは、Windows10側にある%HOMEPATH%以下のファイルをWindows11側にコピーすればよいかという事です。ファイルが250GBほどあるので、場当たり的な方法でコピーすると、何十時間もかかってしまう恐れがあるのではないかと思います。

 

先月下旬にTeraCopyという高速にコピーできるツールを知ったので、これを利用しようと考えていました。初回は、コピーに6時間ほどかかりました。しかし2回目以降は、差分コピーとなるので、10分くらいで終わります。これで決まりだと思ったのですが、TeraCopyを使うと、コピー元で削除されているファイルがあっても、コピー先から削除されることはないようです。これが大きな問題となるかどうか不明ではあります。もしコピー元の方でファイル名を変えたりしていたら、コピー先には、ファイル名変更前と変更後の2つのファイルが残ってしまう恐れがあります。個人で使っているマシンですから、自分が注意すれば良いのですが、なんとかならないかとも思います。

 

いろいろと調べていると、Windowsに標準搭載されているRoboCopyが使えるかもしれないと思いつきました。オプションを指定すれば、コピー元とコピー先のファイルを揃えてくれるようです。試しに使ってみました。指定したオプションは、次のようなものです。

robocopy コピー元 コピー先 /MIR /R:0 /W:0 /LOG:robocopy.log /NP /NDL /XD AppData

 

TeraCopyによるコピーが済んでいる状態で、RoboCopyの実行が10分程度でした。TeraCopy並みの処理時間です。しかもコピー元で無くなっているファイルは、コピー先からも削除してくれます。これならTeraCopyよりも便利です。もしかすると、最初からTeraCopyを使わずに、RoboCopyだけでも良かったのかとも思いますが、TeraCopyはTeraCopyで、それなりに便利だとは思います。

放送大学附属図書館のOPACとディスカバリーサービス

放送大学の学生として所属していることのメリットの一つが、放送大学附属図書館を利用できることだと思っています。特に電子ブックなどを自宅から利用できるのは助かります。

 

図書館で蔵書を検索するにはOPACを利用するのが一般的ですが、放送大学附属図書館には「ディスカバリーサービス」というものもあります。両者がどう違うのか、分かるよう分からないような、スッキリしません。この「ディスカバリーサービス」「というのは、元々は「次世代OPAC」と呼ばれるサービスだったようです。Web上で「「次世代OPAC」と「ディスカバリーインタフェース」の違い」という記事を見つけました。これは2013年9月5日付なので、もう10年以上前の記事です。

 

放送大学附属図書館でディスカバリーサービスを利用すると、学内蔵書以外の文献も検索してくれるのは助かります。しかしどうやらこれは学外にある企業のサービスを利用しているようで、放送大学が独自に構築しているわけではないようです。何でもかんでも放送大学で独自にシステム構築をしなくてもよいのですが、外部サービスであるのが原因という訳でもないでしょうが、どうも使い勝手がおもわしくありません。

 

何か文献を検索し、その電子ブックが存在するか調べてみると、何件かヒットするので、いざ閲覧しようと思うと、電子ブックにアクセスできないことがあります。それが、そもそも電子ブックが存在しないのか（存在しないのに検索にヒットしたらマズいと思いますが） 、電子ブックは存在するものの放送大学との契約上の理由で閲覧させないのか（閲覧できないなら検索にヒットしないでもらいたい）、それ以外の何かの理由なのか、どうもよく分かりません。

 

いろいろと不満はあっても、便利な側面があることは間違いないので、放送大学附属図書館もディスカバリーサービスも今後とも活用していきたいと思っています。ただし活用するには、利用者個人の努力だけではなく、放送大学附属図書館側からのアクションも期待したいところです。放送大学附属図書館では「リブナビ・リブナビプラス」を提供していますが、発行時点と現時点での齟齬が見受けられます。さらに、できれば対面で、利用方法のワークショップを開いてもらえると、とても助かるのですが。 

TSUTAYAの「本コレ」アプリが使いにくくて仕方がない

自宅の近所にある本屋さんがTSUTAYA系列に入っているので、スマホにTSUTAYAアプリを入れていました。このアプリがあると、書店を登録しておけば、在庫の有無や書棚の位置などがわかるので、とても便利でした。

 

ところが、ふと気づいたら、TSUTAYAアプリが「本コレ」アプリに切り替わっていました。このような状態になったのは、本年7月にもありました。その時は、「本コレ」アプリの問題が噴出し、2025年7月24日付で「「本コレ」アプリに関するお詫びとお知らせ」という発表と共に、「本コレ」アプリがTSUTAYAアプリに戻りました。このような経緯だったにもかかわらず、再び突然「本コレ」アプリに切り替わってしまっているのは不信感があります。

 

TSUTAYAからは2025年9月27日付で「「本コレ」アプリサービス再開のお知らせ」という発表をしていたようです。再開するのは企業判断なので、何も言うことはありませんが、再開するのであれば、前回トラブルを起こした事を踏まえて、慎重に移行すべきではないかと思います。それなのに、TSUTAYAアプリが「本コレ」アプリに勝手に置き換わってしまうのは、極めて乱暴だと感じます。

 

もうすでにTSUTAYAアプリは無くなってしまいましたし、勝手に「本コレ」アプリに置き換わってしまいましたので、使ってみようとしました。するとアカウント設定を要求されました。以前のTSUTAYAアプリではアカウントを作っていた記憶はありませんが、アカウントがないと利用できないようなので仕方ありません。Googleアカウントを使うこともできるようなので、アプリ独自アカウントを作るのは躊躇われたので、Googleアカウントを使うつもりです。それは良いとして、Googleアカウントでログインしたら、そのまま何十分待っても、画面が真っ白のまま、何も起こりません。これは一体まともなアプリなのかと疑念を持ちました。

 

Google Playのレビューを見たら怨嗟の声が溢れています。

 

「本コレ」アプリが高邁な志を掲げているのは構いませんが、使い物にならないアプリをリリースするのは迷惑としか言いようがありません。

放送大学教養学部の卒業と再入学

放送大学では、年度の前半（4月～9月）を「第1学期」、後半（10月～3月）を「第2学期」と呼んでいます。一般の大学でよくあるように、入学は4月、卒業は3月と固定されているのではありません。入学も卒業を、第1学期でも第2学期でも構いません。

 

所定の単位を取得したので、2025年9月末をもって、放送大学教養学部を卒業しました。卒業したことはともかく、放送大学が一般の大学とひと味違うのは、「継続入学」という制度があることです。もしかすると放送大学以外の大学にもあるのかもしれませんが、入試で選抜される大学では、卒業後に継続入学をするという事は、あまり耳にしません。そういうわけで、2025年10月からは、継続入学することにしました。ただし条件があり、放送大学では教養学部教養学科の下に「コース」というものが6つあり、既に卒業したコースは選べないことになっています。

 

しかも、僕の場合、再入学するのは、これが初めてではありません。噂によると、放送大学が提供する6つのコースを全て卒業した猛者も存在するようです。僕も長期的な目標としては、6つのコースを卒業したいと思いますが、それは当分先のことになるでしょう。 

お墓参りの時、お線香に火をつけるのに苦労する

もう秋のお彼岸は過ぎてしまいました。いつも春と秋のお彼岸の時にはお墓参りに行くようにしています。ここで毎回苦労しているのが、お線香に火をつけることです。

 

自宅から持参したお線香を使っていますが、10数本の束に100円ライターで火をつけようとしても、屋外だと僅かな風でも火が消えてしまいます。ライターを何度も着火していると、過熱してしまうし、指も痛くなります。何か良い方法がないものかと考えて、ロウソクを使ってみることにしました。

 

ライターでロウソクに火をつけておいて、その火でお線香に着火しようと思ったのですが、思っていたほど上手くいきません。なにしろお墓の前ですから、当然屋外です。それほど強風ということもなく、微風程度なのに、ロウソクに火をつけるところで苦労しています。一瞬ロウソクに火がついたと思っても、僅かな風で火が消えてしまうのです。

 

何か他に方法はないものかと考えてみました。要するに風で火が消えてしまうのですから、何か覆いのようなものがあれば良さそうです。例えば缶飲料のスチール缶を加工してみるのはどうでしょうか。アルミ缶でも構わないかもしれませんが、印象として、スチール缶の方が丈夫そうです。そのスチール缶の上部を切断し、下部からは釘を刺しておいてロウソクを保持できるようにしておこうと思います。

 

問題はスチール缶を切断する方法です。素人細工ですから、それほど綺麗に切断できなくてもよいのです。しかし切断面を放置すると使用時にケガをしてしまうかもしれないので、それなりに加工しておきたいとは思います。それに対して、下部の釘の方は簡単そうです。釘を打ち込めばよいだけだと思うし、抜けてしまわないように接着剤で固定しておく程度で十分でしょう。

 

このようにアイディアは具体化してきましたが、問題はスチール缶の入手方法です。缶飲料のスチール缶なら、なんでも構いませんが、あまり小さいのも困りものです。また基本的に缶飲料の缶を使おうと考えているので、手で持てるサイズですから、あまり太い缶ではありません。

 

ふと100円ショップに何かないだろうか思いつきました。近所の百均に行ってみたところ、ミニサイズのスチール製灰皿というものを見つけました。蓋がついていますが、ふたを外せば僕が当初想定していたような形状になります。またありがたいことに、取っ手も付いていました。百均で販売しているものですから、それほど大きなサイズではありません。しかし僕の用途には丁度ピッタリです。これならスチール缶を自分で切断する手間もかかりません。さっそく買ってきました。

 

これを加工して、来年春のお彼岸に使ってみようと考えています。 

そろそろ「The Knight of Diamonds」を始めたい

一年前には、Windows10上で動作するPC98エミュレータでWizardry#1で遊びました。レベルも十分にあげたパーティーが出来上がったので、次はWizardry#2である「The Knight of Diamonds」をやろうと思っていましたが、もう一年が過ぎてしまいました。別に急ぐ必要もないのですが、そろそろ再開しようかと思います。

 

 前回は地下迷宮のマップをTW5を使って記録していました。今回も同様にやっていこうと思います。とりあえず地下1階のマップをTW5で準備しておきました。

 

Wizardry#2では、キャラクタをWizardry#1から移すことになっています。ひとまず移動は済ませましたが、アイテムが無くなってしまいましたし、ゴールドも減ってしまっています。このままでは地下迷宮に行けないので、まずはアイテムを買い揃えておかなければならないでしょう。

 

この調子で、少しずつ楽しんでいこうと考えています。しかしゲームの展開に慣れてきて、調子が出てくると、のめり込んでしまいそうになるくらい面白いゲームですので、ほどほどにしておくように、よくよく注意していきたいと思います。 

Windows11移行のための旧マシンから新マシンへのファイルコピーにはTeraCopyが使えそう

Microsoftから「Windows 10 サポートは 2025 年 10 月 14 日に終了します」とアナウンスされているように、そろそろWindows10のマシンからWindows11のマシンに移行しなければなりません。僕が使っているのは、昔々Windows8が使われていた頃のマシンなので、Windows11の要件を満たしていません。もしかすると無理矢理Windows11を入れることができてしまうかもしれませんが、そういう邪道なことはやめておこうと思っています。

 

現行マシンは、512GのHDDが使われており、現時点で約80%を消費しています。Windows11のためにマシンを買い替えるつもりでいますが、時代はHDDからSSDのようで、 容量は変わらず512Gで十分だろうと考えています。%USERPROFILE%以下に置かれているファイルが250G弱ほどですが、これを旧マシンから新マシンに移行する方法を考えているところです。ただし、Documents、Picturesなどのように、一括してコピーできるものはありますが、AppDataのようにコピーする必要のなさそうなものもあります。またインストールされているアプリケーションも多々あり、それらを新マシン上で個々に入れていく必要があるのではないかと思っています。 

 

新旧マシン間でファイルをコピーする方法は、いろいろとあるとは思います。ですが、なにしろ（最大で）250Gもある事を考えれば、最適な方式を選ばないと、ファイルをコピーするだけで、何日もかかってしまうかもしれません。新旧マシンともネットワークに繋いで、Windowsのエクスプローラーで必要なものをコピーしていたら、操作は簡単かもしれませんが、イライラするほど遅いのではないかと、今から戦々恐々としています。

 

高速コピーするための何かツールがないものだろうかとネットを探してみたら「TeraCopy」というものを見つけました。これを使うことを前提に、旧マシンに外付けHDDを接続して必要なファイルをコピーしておいて、その外付けHDDを新マシンに接続しなおして、ファイルを取り出そうかと考えています。試しに140G程度を外付けHDDにコピーしてみましたが、約4時間でした。これならなんとかなりそうです。

蛍光灯の終焉と今後の一般家庭における照明器具の形状

経済産業省が2025年3月31日付で「蛍光灯からLED照明への 切り替えはお済みですか？」という発表しました。2027年末で一般照明用の蛍光灯の製造・輸出入が終了するとのことです。これは使用禁止になるわけではありませんし、製造終了になったとしても市場流通在庫が残っている間は購入できるでしょう。また各家庭で使用している蛍光灯が壊れるまで、使い続けることはできるでしょう。

 

私の自宅でも蛍光灯を使用しています。台所には壁に固定されている直管蛍光灯があるのですが、つい最近点灯しなくなってしまいました。もしかして点灯管が壊れたのかと思い、買い替えて交換してみたのですが、駄目でした。これはもう蛍光灯からLED照明に変えなければならない時がきたのかもしれません。上述した経産省の情報では「器具ごと交換とランプ交換の2つの方法があります」と書かれていますが、ネットの情報では、LED照明に対応していない器具があるので、専門家に相談した方が良いとあります。

 

ひとまず近所のホームセンターに行ってみました。直管蛍光灯の形状をしているLED照明ランプはありましたが、それが使用できる器具が何であるのかは判断できないとのことでした。一方で、現状の台所で使用している壁に直付けの直管蛍光灯の器具と似た形状のLED照明器具もありました。「直管蛍光灯の形状をしているLED照明ランプ」+「そのための器具」とは組み合わせられないようだったので、「現状の台所で使用している壁に直付けの直管蛍光灯の器具と似た形状のLED照明器具」を選択しました。

 

この時点では、まだLED照明について詳しく理解していなかったので、そのLED照明器具が点灯しなくなったら、どうするのか質問してみました。LEDは従来の蛍光灯よりは壊れにくいと思いますが、壊れないわけではないでしょうし、LED方式の電球が普通に販売されているのですから、LEDが点灯しなくなった場合の交換パーツについて質問してみました。すると、器具ごと交換するしかないとの事でした。従来から家庭内で使われている照明器具は、例外はありますが、基本的に、電球であれ、直管蛍光灯でも円管蛍光灯でも、器具ごと交換しなくても、そこだけ交換できていたわけです。しかしLED照明器具は、そのような構造にはなっていないそうなので、仮に点灯しなくなったとすれば、器具ごと交換することになるそうです。

 

これまでの一般家庭の照明は、電球か蛍光灯でした。しかしフィラメント方式の電球は既にLED電球に置き換わっていると思いますが、器具の交換を伴わないので、フィラメントかLEDかの違いはありますが、今後も使い続けられていくでしょう。ところが蛍光灯は、直管でも円管でも、その形状をしているLED照明は販売されていますが、従来の器具でも使用できるとは限りません。さらに直管でも円管でも、蛍光灯の形状というのは、その蛍光ランプの点灯方式に強く依存していますから、今後LEDに移行するにあたり、直管や円管の形状をしている必要はないと思います。そうなると、一般家庭における屋内照明において、直管であれ円管であれ、蛍光灯の形状を前提にする必要は、これからは意味がなくなるでしょう。LED照明として、どのような形状が、一般家庭で普通になっていくのかは、今後の展開をみていくしかありません。

着膳

ネット上の記事を読んでいると、時に独特な表現に遭遇することがあります。例えば「着膳」という表現です。食べログに掲載されている店の口コミで使われているのを見かけました。他の場でも使われているのかもしれませんが、それがどこなのかは分かりません。もしかすると普段の会話でも使っている人がいるのかもしれませんが、それほど一般的に使われている表現でもない気がするので、周囲の人が困らないのか心配です。

 

この「着膳」というのは、お店で注文した料理がテーブルに届くことを指しているようです。口コミでは「10分で着膳」のように表現しています。気持ちはわかるのですが、ほかの表現はなかったのかと思います。伝統的には「注文した料理が運ばれてくる」と言っていたはずなので、それを使えば良いではないかと、思うところです。

 

ネット上には「８５８４「着丼」」という2022年7月20日付の記事がありました。この中では、次のように書かれています。

また、「定食」等が席に届くことは、
「着膳」
というそうです。これは『三省堂国語辞典・第八版』にもまだ載っていませんでした。
グーグル検索では（７月２０日）
「着丼」＝２５０万００００件
「着膳」＝　　９万６２００件
で、「着丼」は、ものすごく使われていますが、「着膳」は、まだそれほどではありませんでした。 

 

この記事から約3年後の2025年9月9日に検索してみたら、「着丼」は16,900,000件、「着膳」は15,100,000件でした。Googleの検索アルゴリズムが同一とも限らないので単純比較はできませんが、だいぶ増えています。しかも「着丼」と「着膳」は、ほぼ同数です。そうなると、今や「着膳」は市民権を得たということになるのでしょうか。 

 

2025年度の「NHK語学テキスト購読マラソン」はLINE応募に限定

NHKでは語学番組のテキスト購読者を対象に、毎年「NHK語学テキスト購読マラソン」を実施しています。僕自身は、「Enjoy Simple English」を聴いているので、テキストも毎月購入していました。これまでにも応募した経験がありますし、当たったこともあります。

 

2025年度も、例年同様、応募するつもりだったのですが、応募要項をよく見ると「NHKテキスト公式LINE」からの応募しかできないことになっています。LINEを使っている人が多いのだろうとは思いますが、応募を「LINE」に限定しているのは困りました。僕はLINEを利用していないのです。これの応募のためだけにLINEの利用を始めるというのも考えてしまいますし、これを機会にLINEを使っていこうという気にもなりません。

 

過去にはWEB応募が可能でしたし、記憶が定かではありませんが、葉書での応募も可能だったような気がします。葉書応募は、事務局側の手間が大変だと思うので廃止されても仕方ないと思います。しかしWEB応募なら、全く問題がないとは言いませんが、問題があるようには思えないので、なぜ廃止されたのか解せません。

 

「LINEで応募」できるようになったのは、僕自身がLINEを利用していないとしても、悪いことではありません。問題は、LINEの応募に「限定」している点です。来年度は「WEB応募」が復活してくれるのを望みます。 

JK30とJY05

ちょっと古いですが「駅ナンバリングはなぜバラバラなのか　鉄道会社の“独自ルール”が招く誤解」という記事を見つけました。今では一般的になっていますが、「駅ナンバリング」をつけるようになった理由はよくわかりません。JR東日本が2016年4月6日付で「首都圏エリアへ「駅ナンバリング」を導入します」という発表をおこなっていますが、ここでは2020年の東京オリンピックを見据えて、訪日外国人の利便性をあげています。

 

その導入目的はさておき、「駅ナンバリング」という名称は、どのようにして決定されたのでしょうか。おそらく、いろいろな議論が、どこかでなされた結果として決まったのだと思います。「駅ナンバリング」というのは、現状を確認すれば、「駅」に番号をつけているというのは、正確ではないでしょう。さきほどのJR東日本の発表資料では、「駅ナンバリング表示駅一覧」がついています。それによると、例えば「上野駅」は、次のようになっています。

• 京浜東北線・根岸線では「JK30」
• 山手線では「JY05」
• 宇都宮線・高崎線では「JU02」
• 常磐線快速では「JJ01」 

 

このように、同じ駅なのに「路線」ごとに別の番号が割り当てられています。つまり「駅」に番号を割り当てているというよりは、「路線を基準」として「駅」に番号を割り当てていることになります。そうなると「駅ナンバリング」というよりも、「路線別駅ナンバリング」と呼ぶほうが正確なのでしょうけれども、ネーミングとしては、今ひとつかもしれません。 

 

駅ナンバリングの目的は、先の記事では「「何番目の駅か」がひと目で分かるようにする」ことにあるので、厳格に「駅」ひとつずつに番号を振ってしまうと、「何番目の駅かが結局わからない」となる恐れがあります。それでは何のために番号を割り当てたのか疑問です。

 

このように考えてくると、「駅ナンバリング」という名称が、本来の目的とは微妙にずれているネーミングになっているのが問題ではないかという気がしてきました。おそらく本来の目的は、「駅」に番号を割り当てたかったのではなく、不慣れな旅行者などが目的の「駅」まで「残り何駅なのか素早く認識できる」ようにする仕組みづくりだったのでしょう。 

「Drive on Metz」の基礎調査にNotebookLMを活用

1982年にホビージャパンから出版された『ウォーゲームハンドブック』という書籍がありました。その中には、ゲームの制作過程を示すために「Drive on Metz」というミニゲームが付属していました。その後に原著もゲームも改訂され、今はPDFで入手できるようになったようです。このあたりの経緯は、Web上の記事「発見！！　ジェームズ. F・ダニガン『ウォーゲームハンドブック』と『メッツ進撃作戦』(Drive On Metz)」にあるとおりです。

 

1980年代にシミュレーションゲームが流行した頃に、AHのSquad Leaderシリーズを入手し、またSPIの第二次欧州大戦をHJが発売したものを入手しました。しかしシミュレーションゲームは、ゲームとは言いながらも、諸般の事情により、購入しただけで終わってしまっていました。

1. ゲームの対戦相手が見つからない。
2. ゲーム時間が長くなるので、遊びにくい。
3. マップが大きくて、広げる場所がない。
4. ルールが複雑だと、プレイする前の勉強が辛い。 

 

いろいろと遊ぼうとする上で障害が立ちはだかるのですが、「Drive on Metz」はミニゲームなので、上述した事柄はあまり問題になりません。対戦相手が必要なのは変わりませんが、ソロプレイでも構わないでしょう。

 

次に気になるのは、少なくとも「シミュレーション」ゲームなので、史実との整合性です。ゲームをデザインする中で、シミュレーション性を重視するか、ゲーム性を重視するかは、悩みどころのようです。もしシミュレーション性を重視するとしても、AHのSquad Leaderシリーズの各シナリオだと、予め用意されているボードを組み合わせるしかありませんから、現実の戦闘が行われた地形とは違っています。部隊の編制も、リアリティを高めようとしたら（シミュレーション性を重視したら）、とてもゲームにならないようなカウンターが必要となってしまいそうです。 結局は、AHのSquad Leaderシリーズは、シミュレーションゲームではあっても、ゲーム性を重視しており、WWIIの歩兵部隊の動きがシミュレートできる「気分になる」だけです。

 

それに比べると、「Drive on Metz」は、なにしろ現実に起こった出来事を踏まえています。マップや登場する両軍の部隊も、現実を踏まえています。ゲームした結果が現実と同じになるとは限りませんが、歴史の追体験ができる可能性は高そうです。

 

このゲームの参考情報がウィキペディアに「メスの戦い」としてありますが、ゲームに関係するのは極めて一部です。また米軍が発行した戦史がPDFで入手できますが、それを読み解くのも、骨が折れる作業です。

 

どうしたものかと考えていましたが、GoogleのNotebookLMを使ってみることにしました。ゲーム本体や米軍戦史のPDFを与えておけば、任意の質問に答えてくれます。普通のGoogle検索やGeminiでは、特定の出来事の詳細情報については答えが出ませんが、NotebookLMならば、頑張って返事をしてくれます。

 

まずは、「Drive on Metz」に登場する両軍の部隊が、ゲーム期間中に何処にいたのかをNotebookLMに問い合わせてみました。分かる範囲での回答ではあるのですが、それが史実ということになるでしょう。シミュレーションゲームは、「歴史のif」を明らかにすると言われます。史実を踏まえて、もし部隊が別の動きをしていたらという関心に答えをだしてくれるかもしれません。 

 

 

 

 

 

あ 

ドライブレコーダーの記録が残っていない（ことがある）

自分の車にドライブレコーダーをつけて10年くらいになります。ドライブレコーダーをつける目的は様々かと思いますが、僕の場合は、仮に事故を起こしたり巻き込まれた場合に状況説明の証拠になるのを期待しました。事故は咄嗟の出来事ですから、ドライブレコーダーが無ければ、記憶に頼るしかなく、客観性があるとは言えません。これが主目的なのですが、副目的として、ドライブレコーダーにGPSが搭載されていて、走行した軌跡を記録できるという点です。地元を走行している分には、あまり関係ありませんが、ちょっと知らないところを走行する場合に道に迷ってしまうことがあります。このような場合に、あとで走行軌跡を確認すれば、どこで道を誤ったのかが一目瞭然です。

 

幸いなことに、ドライブレコーダーをつけて以来、事故は起こしてもいないし巻き込まれてもいないので、ドライブレコーダーの記録を活用する状況になった経験はありません。しかし副目的である走行軌跡を確認するため、家に戻ったら必ずドライブレコーダーのメディアを抜いて、記録を確認するようにしています。すると驚いたことに、ごく稀に、一年に一度あるかないか程度で、ドライブレコーダーに走行記録が残っていないことがあるのです。家を出てから帰宅するまで全て記録されていないのではなく、途中で立ち寄ったりしてエンジンを切ったりしますから、そのどこかの部分が欠けているのです。

 

事故の加害も被害もないので、ドライブレコーダーの記録が欠けていても実害はありません。しかし運悪く事故を起こしてしまった場合、ドライブレコーダーの記録を確認したら、記録が残っていないとなると、大問題です。

 

何事にも完全無欠ということはないでしょうから、ドライブレコーダとてパーフェクトとはいかないかもしれません。しかし万が一のための備えとしてのドライブレコーダーですから、記録がないのは致命的です。仮に走行中の全記録が全く残っていないというのであれば、単純にドライブレコーダーが壊れただけなので、交換することになるでしょう。しかし偶に記録が残らないことがある（それも年に一度あるかないかという頻度）のでは、交換するのも二の足を踏んでしまいます。

 

ドライブレコーダーがあるから、事故を起こしても構わないという事では決してないので、事故を起こさず巻き込まれず、安全運転に心がけようと思います。 

勉強した事項は、全て理解し覚えて先にすすむ「べき」なのか

放送大学教養学部に所属しています。先月に単位認定試験（放送大学では期末試験のことを、このように呼びます）が終わりました。成績が出るのはまだですが、おそらく単位はとれているでしょう。次学期が始まるまでは、ちょっと気持ちの上で余裕ができます。

 

放送大学に限らず、NHKの語学コースでも何でも、何か勉強する場合、教科書を読み進める上では、（理想的には）読み終えたところまでは全て理解し、用語も覚え、疑問点を全て解消してから、先に進む「べき」なのでしょう。しかし現実には、少なくとも私自身は、理想どおりには進みません。よくわかっていないのに、教科書は先に進んでしまうとか、語学を学んでいるなら、単語も文法も覚えていないけど、テキストはどんどん進んでいってしまうとか、日常茶飯事です。挙句の果てには、理解も覚束ないのに、単位はとれてしまうこともあり、自分自身に不完全燃焼感が残ります。

 

教科書によっては、理解が不十分でも読み進めることを推奨している場合もあります。何度も読み返せば理解できるはずだとの確信があるようです。そうかと思うと、一度説明した事項は、後に残さず、理解してから、先に進むのが当然だと明言している教科書もあります。それがあるべき姿なのかもしれませんが、厳しい要求だとは思います。

 

教科書を一度読んだだけで全て理解できる人も、広い世の中には存在するのかもしれません。しかし凡人は何度も読み返して、ようやく理解できるのです。何度読み返すのかは、数十回の凡人もいれば、数百回の凡人もいて、もしかすると数万回の凡人もいるでしょう。他人と比較して我が身の不甲斐なさを思い知るよりも、自分自身が納得できるまで頑張れば良いのだろうとは思うところです。 

 

何度も読み返す事は必要だとは考えているのですが、それだけでは駄目ではないかとも思います。適切な例えではないかもしれませんが、飛行機が離陸する際に出力を大きくする様子をみていると、滑走路で停止状態の飛行機は、エンジン出力を最大にあげ、一気に離陸しますが、上空では墜落しない程度にエンジン出力を絞っているようです。これは何かを学習する際に、最初頑張れば、いつまでも頑張り続けなくてもすむという比喩のように思えます。

 

最初の段階で頑張らず、ほどほどでよいと暢気に構えていると、いつまでたっても「離陸」できないのではないでしょうか。何か勉強する意欲は大切だとしても、誰しも忙しく、その勉強だけに日々費やしていられるわけでもありません。さきほどの飛行機の例えなら、離陸しようとしている飛行機が、エンジン出力が弱く、いつまでも滑走路を走行し続けているようなものです。例え話なので現実に起こりうる問題ではありませんが、離陸できない飛行機が、滑走路の先端を走り抜けてもなお地上を走り続けているような感じでしょうか。

 

何を学ぶとしても、どんな分野であっても、学べば学ぶほどに奥は深く、どこまで行っても終わりはありません。そうであったとしても、少なくとも「離陸」してしまいさえすれば、人生の全エネルギーを投入しなくても、学び続けていけるでしょう。そこを目指したいと思います。 

匿名希望

最近は見かけない気がしますが、以前は読者投稿欄などでは「匿名希望」と書かれた投稿を目にすることがありました。本名を書く人もいたし、ニックネームのようなものを書く人もいました。しかし名前を出したくない人が結構多くいて、「匿名希望」としていたように記憶しています。

 

数年前より、The Japan Times  Weekendを購読していると、The New York Times International Editionの週末版も届くようになっているのですが、その中にThe Ethicistという読者相談のようなコラムがあります。アメリカ人ならでは悩み事や、アメリカ人の回答の仕方や発想方法が垣間見えるので、英語の勉強の素材として読んでいます。

 

ここで相談者は、ほとんどの場合「Name Withheld」となっています。どうやらこれは日本語で言うところの「匿名希望」に相当するようです。最近の日本では、ネットで相談事をする際にも、「身バレが怖い」とか「個人情報が」とか、過剰に気にしているような気がしています。同じようにアメリカ人でも名前は出したくないものなのかなと、これも時勢なのでしょうか。 

3Blue1BrownJapanの「量子コンピュータの仕組み【グローバーのアルゴリズム】」

最近はマスコミで量子コンピュータについて報じられることがあります。この量子コンピュータというのは、今日一般に使われているコンピュータとは仕組みが異なるそうなのですが、どう違うのか、よくわかりません。Webを検索したりすれば情報は集まるとは思います。しかしWeb検索というのは、ある程度分かっているけど一部分からないことがあるような場合に役立つのですが、量子コンピュータのように、全く何も分からない場合は、Webで調べれば調べるほど深みに嵌るだけという印象があります。

 

以前から興味を持ってみていた「3Blue1BrownJapan」というYouTubeチャンネルで、量子コンピュータの仕組みについて概説する動画が公開されましたので、見てみました。この番組に限らず、3Blue1BrownJapanの他の番組もそうなのですが、わかりやすく説明されているとしても、決して簡単な内容ではありません。可能であれば、視終わったあとで、番組中で気になった事柄を復習したりすれば、より理解が深まるだろうとは思うのですが、僕自身はそこまではできていません。

 

それはともかく、量子コンピュータについて、これまでは何が何やら全く分かりませんでしたが、少しは理解できた気がします。3Blue1BrownJapanでは量子コンピュータに関する番組が続くようですから、今後も期待したいと思います。 

本棚

よく本を読む人が、ついには作家になったとします。もっとも作家と言っても、次々と新作を発表する人もいれば、ほとんど発表しない人もいるでしょう。それを全て網羅して議論はできませんから、継続的に作品を出し続けている人を念頭に考えたいと思います。

 

作家になるくらいの人は、例え作家にならなかったとしても、本を読み続ける習慣を持っているはずです。本を全く読まないのに作家になるというのはナンセンスでしょう。それはともかく、本を読むとしても、全てを買っている訳ではないかもしれません。図書館で借りることもあるかもしれません。また購入した本を、全て手元に残しておくとも限りません。内心は残しておきたいと思っていても、所蔵スペースの関係で、無制限に残しておける訳でもないでしょう。

 

趣味として書籍と向き合っている限りは、手元に残している蔵書が多くても少なくても、どちらでも構わないと思います。しかし職業として作家になってしまうと、そういう訳にもいかないだろうと思います。新しい作品を執筆するためには、いろいろと関連資料を収集する必要があるでしょうし、全てとは言いませんが、できるだけ多くの資料を手元に置いておく必要があるでしょう。作家人生が長くなれば、そのような資料も膨大になってくると思います。

 

例えば司馬遼太郎は、執筆にあたり資料を膨大に収集したと言われています。今でも司馬遼太郎記念館に行くと、ちょっとした図書館のような膨大な資料が集められた書籍群が見られます。他の有名な作家がどうだったのか不明ですが、それなりに大量の書籍に囲まれているんではないかと思います。

 

ここでちょっと疑問なのが、そのような書籍は、どのような状態で管理されているんだろうかということです。関心のある書籍を次々に手元に残していたら、あっという間に本の山ができてしまいます。インテリア雑誌のグラビアを飾るような、綺麗に整理された状態にはならないような気がするのですが、実際のところどうなんでしょうか。

 

本棚に書籍を並べるというのが基本なのかもしれません。しかし書籍の大きさは様々なので、関連のある書籍を集めようとすると、本棚のスペースを有効に利用できません。反対にスペースを有効に利用しようとすると、単に書籍の大きさがおなじだと言うだけで、関連性は何もない書籍をまとめて置くことになり、そうするしかないのかもしれませんが、使いにくいと思います。

 

作家に限らず、大量の書籍の整理に頭を悩ましている人は少なくないと思います。その解決方法は、個人個人の試行錯誤の結果だと思います。自分の蔵書をどうするのかは、結局は自分自身の問題なのではありますが、他の人がどうしているのかという、苦労話やテクニカルな方法論も聞いてみたい気がします。 

土用の丑の日

2025年7月19日は、土曜日でしたが、「土用の丑の日」でした。日本では本来の由来と無関係に商業化されてしまった年間行事が少なくなく、「土用の丑の日」も「うなぎ」の販売促進活動と化しています。

 

ところが「なぜ、土用に「う」がつく食べ物がいいのか」という記事によると、「土用の丑の日」というのは本来「う」がつく食べ物を食べる日なのだそうです。そうだったのですか。全く知りませんでした。てっきり鰻重を食べる日だとばかり思っていました。

 

「う」がつく食べ物として、「うなぎ」もそうですが、「うめぼし」とか、「うり」とか、「うどん」などを食べればよいようです。しかも「うし」でも良いらしいので、だったら「うなぎ」じゃなくて「ビーフステーキ」でも食べれば、夏バテ防止に役立ちそうです。しかしビフテキは安くありませんから、だったら「牛丼」でも構わないのでしょうか。

 

土用の丑の日にウナギを食べるのは平賀源内が言い出したという説が有力です。とは言え、土用にウナギを食べれば夏バテしないというのも、多分に気持ちの問題という感じですので、うなぎ販促になるなら、誰が言い出したとしても構わないというところでしょう。

堆肥

自宅の庭でトウモロコシを育てています。家庭菜園です。本格的な農地ではないので、トウモロコシの生育に適した土壌には程遠いと思います。10年くらい前から毎年育てていますが、少しずつ場所を変えているので、土地が痩せてくるのを少しは防げているのではないかと期待しています。

 

10年くらい前にトウモロコシを初めて育てた時には、しっかりと育ってくれました。最初は調子が良かったのですが、だんだん土地が痩せてきたのか、昨年は生育が悪く、収穫もよくありませんでした。

 

土地が痩せてきたんだろうとは思うのですが、何をすれば対策になるのか、よくわかりません。土地の栄養が不足しているんだろうと思います。NHKの園芸番組を見ていると、いろいろな肥料を撒いていますが、同じようにやればよいのか、何か別の方法があるのか、それも分かりません。ホームセンターに行ってみたら、いろいろな肥料を販売していました。どれを買えば良いのか迷ったのですが、20リットルのバーク堆肥と鶏糞堆肥を買ってみました。それを自宅の庭に全部入れ、耕してから、トウモロコシを植えてみました。

 

5月下旬にトウモロコシの種を撒いたのですが、7月中旬の今は、立派に育っています。昨年はヒョロヒョロだったので、全然違います。8月になったら収穫できると思います。この調子なら、今年の収穫が楽しみです。

日本のCTANミラーサイト

普段から文書を作る際はTeXliveにあるLaTeXを使用しています。もう今はTeXliveを使いますが、昔々はASCIIのpTeXであるとか、NTTのjTeXなどを個別にインストールしていました。それに比べるとTeXliveは、使うことがあるかどうか定かではないパッケージが大量にインストールされるので、当初は抵抗がありましたが、もう慣れました。昔はディスク容量が潤沢ではなかったので、使いもしないものを置いておくのは罪であると考えていました。でも今は、そういうことを言わずに、TeXliveで環境を整えた方が、総合的に見れば、問題が起きにくい時代ということのようです。

 

TeXliveは、毎年新しいバージョンに切り替えていて、日々パッケージを更新しているのですが、ここ最近は、更新がない日が続いていました。毎日必ず更新があるとも限らないので、更新がなくても構わないのですが、それにしては更新無しの期間が長すぎるような気がしてきました。

 

更新時のメッセージを見ると、CTANミラーサイトとして「ftp.kddlabs.jp」を参照しているようです。ところが、「CTAN Sites」で日本にあるCTANミラーサイトを確認すると「ftp.kddlabs.jp」がありません。なぜ最近まで更新できていたんだろう。元々ミラーサイトではなかったのだろうか。疑問はありますが、それよりも、有効なCTANミラーサイトに切り替える設定をしなければなりません。

 

Webを検索してみたら「tlmgr option repository http://mirror.ctan.org/systems/texlive/tlnet」というコマンドで変更できるようです。変更結果を確認したければ「tlmgr option show」でわかるようです。

 

このようにしてCTANミラーサイトを変更し、改めて「tlmgr update --all」をしてみたら、多くのパッケージ更新が行われました。僕が更新はないと誤解していた間にも、やはり更新がいろいろと出ていたようです。 

「JR新幹線」という会社

旧国鉄がJRに分割された際、JR北海道からJR九州までの地域分割された旅客鉄道会社と全国をまたがるJR貨物に分けられました。その分割が良かったのか、他にも方法はなかったのか、議論はあるかと思いますが、近年のJR北海道やJR四国の窮状を考えると、決してベストではなかったと思います。

 

もうひとつ問題だと思えるのが、新幹線の扱いです。JR各社のエリアと新幹線の営業範囲が完全に重なっているという訳ではありませんが、ほぼ重なっています。しかし東海道新幹線は例外で、JR東日本やJR西日本のエリアでありながら、全てJR東海の管理下にあります。これをJR各社の管理エリアと合わせたら、新幹線の運行に支障が出るというクレームが出そうですし、現実にそうかもしれませんが、問題はそこではないと思います。

 

JR分割後の新幹線においては、並行在来線の扱いが常に問題になります。以前は第三セクターに移行することが当たり前になっていましたが、開通時期が未定となった北海道新幹線では、並行在来線を廃止するという荒業が出るようになりました。そもそも新幹線というのは、在来線の需要が逼迫しているから、「特急」に相当する列車を新幹線として建設した路線に移して、空いた線路容量を従来の鉄道で運用していくという発想だったはずです。ところが最近では、新幹線を建設すること自体が目的化していて、新幹線の営業が赤字になってしまう予測が出たり、並行在来線まで手が回らないから廃止しようとするなど、総合的な鉄道網を考えているのか甚だ疑問を感じます。

 

同一会社が、新幹線と並行在来線を所有していれば、新幹線の利用を促進するため、並行在来線の利便性を良くしたいとは思わないだろうと思います。並行在来線が便利なので、新幹線を利用する必要がありませんでしたとなってしまっては、本末転倒だからです。それならば、新幹線と並行在来線を別会社にすれば、どうでしょうか。

 

JR貨物は全国一社なので、同様に、全国の新幹線を全て営業対象とする「新幹線旅客鉄道株式会社」(通称：JR新幹線）を作り、従来から今後の新幹線を全て任せるのです。新幹線を専門とする会社なので、営業規模は大きくなると思いますし、利益も良さそうです。一方のJR各社（特にJR東海）は、新幹線が無くなり在来線だけの会社になるので、厳しい経営が予想され、「JR新幹線」なんてふざけた考えは認められないとなるでしょう。しかし新幹線と並行する在来線は競争相手となりますから、在来線の利用拡大を目指し、面白いアイディアが出てくるのではないでしょうか。

 

東海道新幹線が登場したときには、「夢の超特急」でしたが、北海道新幹線の札幌延伸や北陸新幹線の延伸問題などを見ていると、明るい未来とは感じません。 

マウスは消耗品だろうか

普段利用しているWindows10のデスクトップPCのマウスの調子が良くありません。マウスのホイールを回しても、操作した方向とは逆に動いたり、または動きがギクシャクしたりするのです。このマウスを何時から使用しているか記憶にありませんが、5年くらいは経っていると思います。それでも10年以上ではないと思います。

 

マウスが不調だった場合の対処方法を調べると、「マウスが壊れても分解して掃除すれば大体直るぞ！」のような記事が見つかります。同じような記事は他にもあり、要するに分解し、内部の埃を掃除すれば良い（だろう）ということです。

 

実際に分解してみました。PC本体のようにファンがあるわけではないので、埃がたまっているという感じではありませんでした。念のためにエアダスターで埃を吹き飛ばしてみましたが、調子が良くなった印象はありません。 

 

使用しているのは、買っても千円程度の、ごく普通のマウスです。調子が悪いのを放置して、普段のPC操作の効率が落ちるくらいなら、買い替えてしまうのが無難だと思います。つまりマウスは消耗品と考えるということです。

 

消耗品という言葉からイメージするのは、プリンタなら、印刷する用紙とかインクなどが普通です。マウスは「消耗品」っぽくありませんが、実質的には「消耗品」ということでしょうか。 

JR東日本が発表した「東日本のんびり旅パス」

2025年6月10日にJR東日本が「東日本のんびり旅パス」を発表しました。最近JRから発表されるのは、割引切符や企画切符の終了とか廃止などが多かったので、このような新たな切符が発表されるのは嬉しいことです。

 

この切符はJR東日本のエリア内に限定されますが、連続する3日間は普通列車乗り放題なので、「青春18きっぷ」の地域限定版のように思えます。3日間用の青春18きっぷが10,000円なのに対して、こちらのキップは9,000円です。JR東日本以外に行かないのであれば、3日間用の青春18きっぷを購入する必要はなくなったと言えるでしょう。

 

しかも利用期間は、2025年7月1日～同年12月26日（ただし8月10日～同月19日を除く）と長くとられています。今夏の青春18きっぷの利用期間は、2025年7月19日～同年9月9日ですから、まるで勝負になりません。ますます青春18きっぷを買う必要がなくなります。

 

一方でJR東日本には、青春18きっぷと似ている「北海道&東日本パス」というものがあります。この切符は、JR東日本の他にJR北海道も利用できますし、青春18きっぷとは異なり、青い森鉄道やIGRいわて銀河鉄道も利用できます。このため首都圏から青森に向かうために日本海側を経由する必要がないのもメリットです。しかも値上げされたとは言え、11,530円ですから、5日間用青春18きっぷの12,050円よりも安価です。それでいて連続する7日間も有効なので、JR東日本とJR北海道のエリア内を旅するのであれば、5日間用の青春18きっぷを買う理由が見当たりません。青春18きっぷが必要となるのは、JR東海以西を利用したい場合に限られるでしょう。

 

2024年冬から青春18きっぷの制度が大きく変更されて、率直に言って、使いにくくなりました。その一方でJR東日本には「東日本のんびり旅パス」や「北海道&東日本パス」があるので、「青春18きっぷ」の出番は少なく（全く？）なりそうです。

 

しかしながら同様の企画切符がJR各社から出ているわけでもありません。JR東日本には「北海道&東日本パス」がありますが、JR西日本やJR東海には「東日本&東海&西日本パス」のような企画切符はありません。元々青春18きっぷは国鉄時代に生まれたものですが、国鉄がJR各社に分割されたことで、北海道から九州までのJRを通して利用できる「青春18きっぷ」をJR各社が忌避しようとしているように見えます。新幹線とかクルーズトレインのような高級路線にはJRも熱心のようですが、全国の鉄道網を活かそうとする気はなさそうなのが残念です。

Pythonからgraphvizを使うには

graphvizというものがあります。ネットワーク構成を独自言語で記述した上でツールにかけると画像を生成してくれます。ネットワーク構成の画像を描くなら、GUIベースのお絵かきソフトを使えば、おそらく隅々まで自分好みの画像ができると思いますが、拘れば拘るほど、いくらでも時間が喰われていくことでしょう。それに対してgraphvizはネットワーク構成の論理的な構造を記述しておいて、画像を自動生成するので、気に入らない点も出てくるかもしれませんが、圧倒的に手間暇が削減できます。これはLaTeXの発想にも通じるところがあると思います。

 

graphvizを単独で使うのではなく、Pythonから利用しようとしたら、どうしたら良いのでしょうか。調べてみるとGraphvizとPyGraphvizがあるようです。Pythonからgraphvizを利用する事例を検索すると、双方とも情報が見つかります。

 

それぞれを試しに使ってみましたが、各々特徴があって、どちらかが良いとか悪いとか判断するのは難しそうです。どうしたものかと思っていたら「Python から Graphviz を使う - networkx & PyGraphviz、pydot など」という記事を見つけました。そこには次のような記述がありました。

pyGraphviz というのもあるのを知る。ロスアラモス研究所 で開発されていて、グラフ操作のための networkx と、グラフ描画のための pyGraphviz という感じのようだ。 

 

PyGraphvizとロスアラモス研究所との関係は不明ですが、PyGraphvizのサイトには「PyGraphviz provides a similar programming interface to NetworkX (https://networkx.org).」と書かれていることは確かです。

 

そもそもPythonからgraphvizを利用したいと考えたのは、NetworkXを使用してグラフ構造を出力したからなのです。そうであれば、これはもうPyGraphvizを利用するしかないのではないかという気になってきました。 

LibreOffice Calcで多すぎるシートを切り替える方法

Webで「【Excel】シートが多すぎると切り替えが煩わしい問題を解決する3つの方法」という記事を目にしました。私自身は、Microsoft Officeを使っておらず、LibreOfficeを利用しています。だからExcelのテクニックに関する記事は、LibreOffice Calcには無関係なのですが、表計算ソフトに関する参考情報として役に立つ場合もあるので、見かけたら確認するようにしています。

 

その記事では、シートが「多すぎる」場合に切り替える操作について記していますが、これはExcelの場合の話です。ExcelとCalcの操作が全く似ても似つかないというわけでもないので、同じ操作ができる場合もあるのですが、シート切り替えについては、Calcでは操作が異なるようです。

 

 シートが表示されている画面下部の左端にある矢印記号をクリックすれば、シートを切り替えられるのですが、シートが多すぎると目的のシートにたどり着くのに時間がかかります。シートが100以上もあるファイルを扱うことがあり、もう少し楽にシートを選択するほうがないだろうかと思っていました。

 

LibreOffice Calcの場合、画面上部のメニュー「シート(S)」の中にある「ナビゲート(T)」から「シートへ移動(G)...」を選ぶと出てくる画面を使うと便利な事を最近知りました。この画面には選択機能がついているので、シート数が多くても絞り込むことが出来ます。絞り込んだ結果が数シートになれば、それを選択するのは簡単です。

 

こんな便利な方法があったとは最近まで知りませんでした。今後は活用しようと思うのですが、メニューから選択する階層が深いのが難点です。これを呼び出すためのショートカットを定義できれば素早くアクセスできると思うのですが、その方法がわかりません。単に私がLibreOfficeに不慣れなので無知なだけだと思います。何かショートカットを定義する方法があるだろうと思うので、探してみようと思います。 

ネットワーク問題を解くためのPythonライブラリは何が良い？

国鉄時代からありますが、日本国内を一筆書きで乗り継ぐ片道切符を考えるという問題があります。『最長片道切符の旅』が有名ですが、これが端緒ではありません。問題を考えるだけなら、時刻表と暇な時間があれば十分ですが、現実に旅行してみようとすると資金面でも現実の時間も必要ですし、体力も必要です。

 

この問題を解くために時刻表とにらめっこするのも一興ですが、コンピュータを使って解いてみるのも楽しそうです。これはネットワーク問題ということになると思いますが、アルゴリズムを最初から自分で実装するよりも、何か既存のライブラリを使う方が、不必要に苦労せずにすむでしょう。いろいろなライブラリがあるとは思いますが、Pythonで利用できるものを考えてみようかと思います。

 

Pythonでネットワーク問題を解くためのライブラリも、いろいろあると思います。何を使っても良いのですが、有名なところでは「NetworkX」があります。また『Python計算機科学新教本』では「3章制約充足問題」や「4章グラフ問題」が参考になりそうです。他にもライブラリはいろいろありそうですが、各ライブラリを比較検討するのが目的ではないので、横道に逸れないように注意して、NetworkXを使ってみようかとも考えています。

 

いきなり日本全国の鉄道路線網を扱おうとすると大変なので、最初に北海道、四国、九州のどこかを使って、具体的な実装を試してみようかと思います。それがうまくいったら、日本全国に広げようかと思います。

 

ただし、国鉄時代とは違い、現在のJR四国は、日本国内の一筆書きの片道切符では対象から外れています。なぜなら、国鉄時代には、四国と本州の間には連絡船が東西に2航路存在していましたが、現在は岡山から四国にわたることしかできません。一筆書きのルールは同じ路線を複数回使用できないため、いったん四国に入ってしまうと出ることが出来ないのです。

 

またJR北海道が路線廃止をすすめていますし、在来線だけでは北海道と本州を移動できなくなっています。このあたりは一筆書きのルールを定義するやり方でなんとかなるでしょう。

ワンマン運転

JR東日本が2024年11月6日付のJR東日本ニュースで「首都圏主要線区でワンマン運転を実施します」という発表をしました。鉄道におけるワンマン運転というのは、これまでは地方ローカル線などで1～2両編成で運転される場合、車掌が乗務していなくても、ドア開閉などの安全確認を全て運転士が担っています。今後は首都圏でもワンマン運転を始めていこうということですが、首都圏を走るのは10両編成くらいになるし、乗降客も多いはずなので、確実に安全確認をできるような取り組みを実施することになるようです。

 

ふと考えてみると、地方ローカル線であっても昔々は車掌が乗務するのが基本だったはずで、ワンマン運転が何時頃から始まったのか記憶にありません。もっともワンマン運転というと、むしろ路線バスを思い出します。過去の路線バスでは車掌が乗務していましたが、次第にワンマンバスが当たり前になってきました。むしろ今日では車掌が乗務する路線バスは存在しないと思います。

 

さて「ワンマン」という語を辞書で引いてみると、 手元にある『明鏡国語辞典 携帯版』（初版第三刷 2005年4月1日）には次のように書かれています。

1. 人の意見・批判などには耳を貸さないで、自分の思いどおりに支配する人。
2. ひとりの、ひとりだけの。 

 上述した「ワンマン運転」や「ワンマンバス」というのは、語義の2番目の方です。語義の1番目にある方が「ワンマン」の主たる定義で、これは「ワンマン社長」のような使い方になります。

 

英語にも「one-man」というものがあるようですが、その意味は「一人だけの[で行なう] 」であり、前述した語義の2番目に相当します。しかも英語には、前述した語義の1番目の意味はないそうです。そうなると、「ワンマン」の日本語の第1番目の語義は、英語と見せかけていますが、純粋な日本語といえるでしょう。

 

「ワンマン運転」とか「ワンマンバス」というのは、運転士だけしかいない（車掌が乗務していない）ということであって、運転士が「人の意見・批判などには耳を貸さないで、自分の思い通りに支配する人」という役割ではありません。英語の本来の意味にも合致している使い方です。これに対して「ワンマン社長」のような使い方は、本来の英語にはない語義で、いわゆるJapanese Englishになると思います。どうして「ワンマン」に対して「ワンマン社長」のような使い方が出現したのか、興味があります。 

TW5において順序つきリストの途中に別の要素を挟んでも番号が継続するための方法

TiddlyWikiを利用していて気になるのが、Numbered Listsの途中で他の要素を挟むと番号が継続してくれないことです。なんとかならないかと思っていましたが、TiddlyWiki 5 Discourse discussion group for end usersで「Ordered List and Continued List Number in TiddlyWiki」という記事が流れました。

 

詳細は記事に譲りますが、要はHTML要素「ol」に対して設定を加えておけば、番号が継続してくれるようになるようです。試してみましたが、これまでは初期番号「1」に戻ってしまうところが、番号が継続してくれました。TW5で整理している情報は、個人的に利用しているだけなので、番号が継続しなくても気になるのは自分だけでした。それでも番号が初期番号に戻らないのは、ありがたいことです。

 

ただし、Numbered Listsをネストした場合には、期待した動作（番号が継続してくれる）とはならないようです。このため根本的な解決にはなりませんが、一歩前進には間違いありません。 

Windows10のFirefoxとAndroidのFirefox

日常的に使用しているWindows10ではFirefoxを使用しています。AndroidのスマホにもFirefoxを入れてみましたが、メインのブラウザとするつもりはありません。ただしFirefox同期設定をしてありますので、Windows10側のブックマークがAndoroid側で参照できるのは助かっています。

 

 Windows10のFirefoxは、139.0で、AndoroidのFirefoxは、138.0.4です。いつ頃だったのか忘れましたが、半年くらい前だったような気がしますが、Android側でブックマークを参照すると、Windows側と並び順が変わっていることに気づきました。それ以前は、Windows側とAndroid側のブックマークの並び順は同一でした。これに気づいた当初は、Android版Firefoxのバグじゃないかと思っていたので、すぐに元に戻ると思っていたのですが、今もって直っていません。どうやらAndroid版の仕様が変わってしまったようです。

 

よく確認してみると、Android版Firefoxのブックマークには、次のような選択肢があります。

• 新しい順に並べ替え
• 古い順に 並べ替え
• 名前で並べ替え（昇順）
• 名前で並べ替え（降順） 

 

一方でWindows版Firefoxのブックマークでは、次のような選択肢があります。これに加えて、昇順と降順を選べます。

• 並べ替えない
• 名前順で表示
• タグ順で表示
• URL順で表示
• 最後に表示した日時順で表示
• 追加日時順で表示
• 変更日時順で表示 

 

一見して分かるように、両者で選択肢が大きく違います。特にAndroid版には「並べ替えない」という選択肢がありません。僕はWindows側では「並べ替えない」としているのに、Android側では強制的に並べ替えられてしまいます。

 

原因は分かったのですが、当面はあきらめるしかなさそうです。将来的には、Android版に「並べ替えない」という選択肢が追加されるのを期待したいところです。 

『灯台へ』（ヴァージニア・ウルフ著、鴻巣友季子訳）

どのような経緯で知ったのか忘れてしまいましたが、新潮文庫の『灯台へ』（ヴァージニア・ウルフ）を読んでみました。登場人物はそれなりにいますが、その中の誰かが主人公というわけでもありません。小説の舞台は、ほとんど動きませんし、時代は第一次世界大戦をはさむ前後となるある日の午後と十年後のべつの日の午前でしかありません。

 

登場人物の心の動きを描写することに目的がある作品で、その物語の筋書きに何か意味が（あるのかもしれませんが）あるようには見えません。ウィキペディアでは次のように紹介しています。

マルセル・プルースト『失われた時を求めて』や、ジェームズ・ジョイス『ダブリン市民』『ユリシーズ』と同じく、現代小説作家の伝統を継承、発展しており、『灯台へ』の物語の筋は、その哲学的内観に比べあまり重要ではない。意識の流れの文学的技法を代表する例として引用される。

 

この作品をどう読むのか、他の人はどう読んだのかということが気になります。これは、どう読むのが正解なのかという意味ではありません。この作品が心の動きを描写しているとしても、現実におきた何かのドキュメンタリーではなく、作者の作品であるからには、その描写には作者の意向があるはずです。もし何も考えずに執筆したというのであれば（それは考えにくいですが）、それはそういう作者の意向であると考えられるでしょう。

 

面白い作品だったかと問われれば、そのとおりとは言えませんが、ではつまらなかったのかというと、そうではありません。読みながら、その心情に共感できたり、何か閃いたりしましたが、それを言葉であらわそうとすると、うまく表現できずに消えてしまいます。

 

またいつか読み返してみようかと思います。その時に、今度はどのような感想を持つのか、それが楽しみです。

外部環境で作成したコマプロをOpenVMSで動かす

Windows10上でsimh V3.8-1のVAX.EXEを用いて、OpenVMS VAX V7.2を動かしています。OpenVMS側で全て作業すれば問題ないはずですが、外部環境（Windows側とか、WSL環境とか）で作成したファイルをOpenVMS側に持ち込んで何かしようとすると、ひと手間かける必要があります。何をすれば良いのか分かってしまえば簡単なことなのですが、そこに至るまでは試行錯誤の連続でした。

 

ひとつの例として、外部環境で作成したOpenVMS用のコマンドプロシージャ（通称：コマプロ）をOpenVMSが動かすことを考えます。例えばFreeBSD環境で作成したコマプロがあるとしましょう。これをOpenVMS側に持ち込むには、いろいろな方法があるとは思いますが、ISOファイルを経由させます。FreeBSD側ではmkisofsを使ってISOファイルを作ります。これをsimhでデバイスにattachしておけば、OpenVMS側でマウントできます。ここで問題になるのは、ISOイメージの中にあるコマプロを直接実行しようとしてもエラーになることです。 

FreeBSDで作成したファイルなので、当然ながら、行末がLFになっています。このようなファイルをOpenVMSでは認識できないので、dir/fullで見ると「Record format:      Undefined, maximum 0 bytes, longest 0 bytes」となっています。そこで以下のコマンドで変換すればよいようです。

set file/attr=(RFM:STMLF) sample.com

 

 これを行えば、dir/fullで「Record format:      Stream_LF, maximum 0 bytes, longest 0 bytes」となるので、コマプロとして実行してもエラーになりません。

 

分かってしまえば簡単なことでしたが、ここに至るまでは苦労しました。Webで情報を検索しても、OpenVMSを利用している人が少ないためか、参考となる事例が見つかりませんでした。漠然としたアイディアとしては、FDLとかconvertなどを使うのではないかと考えたりして、かなり迷宮をさまよいました。最終的にGeminiにお伺いをたてたところ、ヒントが得られました。しかしGeminiの回答は、おそらくChatGPTもそうでしょうが、ハルシネーションのせいなのか、かなりもっともらしいものの微妙に誤りを内在しているものでした。役には立つのですが、盲目的な信頼をおくのは考えものかと思います。

 

Firefox 138では「NHKプラス」が視られる

Webで見かけた記事「「Firefox 138」のリリースノートにない日本人にとって重要な変更とは？」によると、Firefox 138では「NHKプラス」が視られるようになっているとのことです。Windows10上のFirefox 138.0.1で試してみたところ、視聴できることを確認しました。

 

 「NHKプラス」でFirefoxが対象外となったのは、2022年4月27日付「【重要なお知らせ】NHKプラスアプリでの推奨OSの変更等について」でした。このお知らせでは、NHK側としては従来よりFirefoxを推奨してはいなかったものの、視聴することはできていたと記しています。しかし、Firefoxでは視聴できなくなりました。

 

Firefoxで「NHKプラス」が視られるのは、3年ぶりです。この間Firefoxでは視聴できなかった理由を、記事では次のように記しています。

 提供していただいた情報によると、「NHKプラス」ではPicture in Pictureを実現するための一部APIが実装されているかどうかを調べ、動画のストリーミングの可否を決定しているとのこと。「Firefox」はセキュリティ上の懸念からこのAPIを実装していないため、動画の視聴ができなかったそうです。

 

「NHKプラス」としては、接続しているブラウザが「Firefox」であることを確認しているのではないようなので、今回の復活につながったのでしょう。当時は視聴不可となる理由が不明だったので、ブラウザをFirefoxではないように見せかけることができれば何とかなるのだろうかと考えたものです。しかしブラウザ名を見ていたわけではないということです。

 

NHKとしてはFirefoxを推奨環境に加えたくなさそうなのですが、ブラウザ名でFirefoxを狙い撃ちにすることはないようです。

時代劇などで「このクソじいじ」という台詞が聞かれる日がくるだろうか

大岡越前でも、暴れん坊将軍でも、水戸黄門でも何でもよいのですが、時代劇を見ていると暴れ者に襲われる庶民が登場するシーンがよくあります。そういうシーン（に限りませんが）などで、暴れ者が「このクソじじい」と罵る台詞が聞かれます。こういう台詞は、時代劇とはいえ歴史を忠実に反映している訳ではないので、今日の視聴者に馴染みのある表現になっています。もしかすると将来いつかは、「このクソじいじ」となる日が来るかもしれません。

 

まさか時代劇で「じいじ」などという台詞が現れるとは、僕自身は思っていないのですが、言葉の変化は予断を許しません。時代劇の表現が、その時代に忠実にしすぎると、 視聴者がついてこられなくなります。時代劇は、その時代を忠実に描くことも大切ですが、視聴者を楽しませることも大切なので、そのバランスをとる中で、今風の表現が出現する可能性もあるでしょう。

 

Webに「「じいじ　ばあば」に虫酸が走る？　祖父母をどう呼ぶか問題　学者が読み解く“いま”を映す家庭内の距離感」という記事がありました。「じいじ」とか「ばあば」という表現が何時頃から使われているのか判然としませんが、2000年以降ではないかとみられます。この表現を嫌う人がいます（僕もそうです）が、むしろ喜んで使う人もいます。記事では次のように書かれています。

「『じいじ　ばあば』は、『パパ　ママ』同様、密な家庭のその関係の中だけで、特別に孫や子に呼んでもらえる名前。その点が大きいのではないでしょうか」
　そして「じいじ　ばあば」を嫌う人が一定数存在する理由もそこにあると、石黒教授は言う。

祖父や祖母を表現する言葉として、「（お）じいさん／（お）ばあさん」、「（お）じいちゃん／（お）ばあちゃん」、「じじい／ばばあ」などが昔から使われてきましたが、今はそれに「じいじ／ばあば」が加えられています。しかしTVドラマでも実生活でも、人に呼び掛ける表現として、「おい、じいさん」、「おい、じいちゃん」、「おい、じじい」などは考えられますが、少なくも2025年の今では「おい、じいじ」は無いと思います。しかし将来は、当たり前になっている日が来るかもしれません。100年後ならあり得るかもしれません。もしかすると30年後にはなっているかもしれません。時代の変化は激しいので、10年後には普通に使われているかもしれません。

simhの仮想磁気テープファイルをTAR形式ファイルに変換

Microsoft Windows10上のsimh V3.8-1 VAX.EXEを用いてOpenVMS V7.2の環境を作成しています。OpenVMS側からWindows10側にファイルを持ってくる方法を考えてみました。OpenVMS側ではTU-81で磁気テープにファイルを書き出せば、実はsimhにおける仮想磁気テープファイルとしてWindows10側でアクセスできます。この方法で何でもファイルを持ってこられるわけではないと思いますが、少なくともテキストファイルならば問題ないでしょう。

 

OpenVMSがTU-81に書き込む際にはANSI X3.27で規定されたフォーマットになっているようです。ここから、最低限としてテキストファイルを取り出せればよいとします。ただし複数ファイルが格納される可能性を考慮しておきます。ファイルを一つずつ取り出しても構わないのですが、ちょっと気をきかせて、TAR形式ファイルに変換しておこうかと思います。

 

変換スクリプトはWindows10上のWSL2にインストールしてあるUbuntu環境でPythonを使用しました。いろいろと不完全ではあるのですが、仮想磁気テープファイルに格納されているファイルを取り出してTAR形式ファイルに変換するスクリプトができました。

• ANSI X3.27のヘッダ情報を解釈すれば長いファイル名にも対応できるのですが、それは見送りました。
• 当面はテキストファイルだけで良いので、それ以外のファイル形式は未対応としました。
• スクリプトで大域変数を多用していて、あまり良くないのですが、改善するのは将来の課題としました。
  

 

作成したスクリプトは、次のようになりました。Pythonでtarfileモジュールを使うと、簡単にTAR形式ファイルを作成できて、ありがたいことです。

 

#!/usr/bin/python3
import os
import sys
import tarfile

def vol1(r):
    # print("{}".format(r[:4]))
    # print("\t" "Volume Identifier[{}]".format(r[4:10]))
    # print("\t" "Accessibillity[{}]".format(r[10]))
    # print("\t" "Owner Identifier[{}]".format(r[37:51]))
    # print("\t" "Label-Standard Version[{}]".format(r[79]))
    return

def hdr1(r):
    global FileName
    global fd
    FileName = r[4:21].strip()
    fd = open(FileName,"w")
    # print("{}".format(r[:4]))
    # print("\t" "File Identificer[{}]".format(r[4:21]))
    # print("\t" "File-Set Identificer[{}]".format(r[21:27]))
    # print("\t" "File Section Number[{}]".format(r[27:31]))
    # print("\t" "File Sequence Number[{}]".format(r[31:35]))
    # print("\t" "Generation Number[{}]".format(r[35:39]))
    # print("\t" "Generation Version Number[{}]".format(r[39:41]))
    # print("\t" "Creation Date[{}]".format(r[41:47]))
    # print("\t" "Expiration Date[{}]".format(r[47:53]))
    # print("\t" "Accessibility[{}]".format(r[53]))
    # print("\t" "Block Count[{}]".format(r[54:60]))
    # print("\t" "System Code[{}]".format(r[60:73]))
    return

def hdr2(r):
    global RF
    RF = r[4]
    # print("{}".format(r[:4]))
    # print("\t" "Record Format[{}]".format(r[4]))
    # print("\t" "Block Length[{}]".format(r[5:10]))
    # print("\t" "Record Length[{}]".format(r[10:15]))
    # print("\t" "Buffer-Offset Length[{}]".format(r[50:52]))
    return

def hdr3(r):
    # print("{}".format(r[:4]))
    # print("\t" "RMS attribute[{}]".format(r[4:68]))
    return

def hdr4(r):
    # print("{}".format(r[:4]))
    # #print("\t" "Reserved[{}]".format(r[4:79]))
    # print("\t" "Filename[{}]".format(r[5:67]))
    # print("\t" "Length[{}]".format(r[67:69]))
    return

def eof1(r):
    fd.close()
    tar.add(FileName)
    os.remove(FileName)
    # print("{}".format(r[:4]))
    # print("\t" "File Identificer[{}]".format(r[4:21]))
    # print("\t" "File-Set Identificer[{}]".format(r[21:27]))
    # print("\t" "File Section Number[{}]".format(r[27:31]))
    # print("\t" "File Sequence Number[{}]".format(r[31:35]))
    # print("\t" "Generation Number[{}]".format(r[35:39]))
    # print("\t" "Generation Version Number[{}]".format(r[39:41]))
    # print("\t" "Creation Date[{}]".format(r[41:47]))
    # print("\t" "Expiration Date[{}]".format(r[47:53]))
    # print("\t" "Accessibility[{}]".format(r[53]))
    # print("\t" "Block Count[{}]".format(r[54:60]))
    # print("\t" "System Code[{}]".format(r[60:73]))
    return

def eof2(r):
    # print("{}".format(r[:4]))
    # print("\t" "Record Format[{}]".format(r[4]))
    # print("\t" "Block Length[{}]".format(r[5:10]))
    # print("\t" "Record Length[{}]".format(r[10:15]))
    # print("\t" "Buffer-Offset Length[{}]".format(r[50:52]))
    return

def eof3(r):
    # print("{}".format(r[:4]))
    return

def eof4(r):
    # print("{}".format(r[:4]))
    return

LABELS = {
    "VOL1":vol1,
    "HDR1":hdr1,
    "HDR2":hdr2,
    "HDR3":hdr3,
    "HDR4":hdr4,
    "EOF1":eof1,
    "EOF2":eof2,
    "EOF3":eof3,
    "EOF4":eof4,
}

def fixed(d):
    return

def variable(d):
    i = 0
    while i < len(d):
        try:
            l = int(d[i:i+4])
        except ValueError:
            break
        # print("{} {:04d} {:04d} {}".format(FileName, i, l, d[i+4:i+l]))
        fd.writelines(d[i+4:i+l])
        fd.write("\n")
        i = i + l

def spanned(d):
    return

RECORDS = {
    "F":fixed,
    "D":variable,
    "S":spanned,
}
RF = ""

def readrecord(f):
    global TapeMark
    len0 = int.from_bytes(f.read(4),'little')
    if len0 == 0:
        TapeMark += 1
        if TapeMark >= 2: raise EOFError
        return 0
    TapeMark = 0
    data = f.read(len0).decode()
    len1 = int.from_bytes(f.read(4),'little')

    label = data[:4]
    if label in LABELS:
        LABELS[label](data)
    else:
        #print(TapeMark, len0, data[:4], data[4:16])
        # print("DATA({})".format(len0))
        RECORDS[RF](data)

    return 0 if len0 != len1 else len0

def readblock(f):
    while True:
        if readrecord(f) == 0: break

TapeMark = 0
FileName = ""
fd = 0
tar = 0

tar = tarfile.open("tap2tar.tar.gz","w:gz")
with open(sys.argv[1],"rb") as f:
    while True:
        try:
            readblock(f)
        except EOFError:
            break
tar.close()
#[EOF]

TW5にはViewTemplateというものがあるらしい

TiddlyWikiには旧いTWCと新しいTW5があります。TWCの頃から利用しており、今はTW5を使っていますが、活用できているとは言えません。Talk TiddlyWikiという「the TiddlyWiki 5 Discourse discussion group for end users」があるので、いつも見るようにしているのですが、その質問にも議論にもついていけません。いろいろな機能があるんだなぁと思いますが、それを使いこなすことができれば、TW5の可能性がもっと拡がると思うので、勉強したいと思います。

 

そこを見ていたら、「ViewTemplate」というものがあるのを知りました。どのように利用するのかわからないので、Webを検索しながら試行錯誤してみました。なんとなく使い方が見えてきて、「$:/tags/ViewTemplate」というタグをつけてたTiddlerを作っておくと、その内容が、他の全て（または条件の合致するもの）のTiddlerにも自動的に表示されるようです。

 

どのような動作をするものなのかは判明しましたが、これを使うと助かる状況が何なのか、まだわかりません。公式サイトには「SystemTag: $:/tags/ViewTemplate」という情報がありますが、もうちょっと詳しい説明が欲しいと思います。

VirtualBox上のFreeDOSでTurboPascal

特別に何か積極的な意図があるわけではないのですが、VirtualBox上にFreeDOSをインストールしてみました。独立したMS-DOSは1993年のV6が最後ですし、PC-DOSも1998年のPC-DOS 2000が最後なので、今はFreeDOSが唯一の選択肢です。Windows10にもCMD.EXEの環境はありますが、純粋なDOSを使ったのは久しぶりです。昔々のDOSっぽいところも残っていますが、だいぶ洗練されていると感じました。

 

ここでふと思い出しましたが、確かTurbo Pascalが自由に使えるようになっていたはずです。もっと本格的なFree Pascalというものもあるようなのですが、DOS時代の思い出にひたるにはTurbo Pascalの方が楽しそうです。もっとも僕自身としては、当時Turbo Pascalを使ったことはなく、Turbo Cを使っていました。

 

ZIPファイルをダウンロードしたら、「tp302」というディレクトリの下にファイルがありました。たったこれだけ？と思ったくらいファイル数が少なかったのですが、フロッピーが当たり前だったDOS時代なら、こんなものかもしれません。展開したファイルをディレクトリごとFreeDOS環境にコピーしたのですが、なぜかTINST.COMが動きません。四苦八苦し、Webを検索したら「Turbo Pascal 3.02 を Windows 10 (64bit) / 11 にインストールしてみる」という記事が見つかりました。そこに以下の記述があり、ディレクトリを「tp3」としたら動くようになりました。

解凍すると TP302 フォルダができます。リネームして TP3 としておきます。

 

VirtualBox上のFreeDOS環境と、ホストであるWindows10の間でファイルをやりとりする必要があるのですが、どのような方法が考えられるのでしょうか。これもWebで調べてみたら、「Exchanging Files with the FreeDOS machine」という記事が見つかりました。もっとも簡単なのは「Mount the image file」という方法のようです。現在のWindowsはVHD形式の仮想ディスクをマウントできるそうなので、VirtualBox上のFreeDOSをVHD形式の仮想ディスクにインストールすれば、それをWindows10でマウントできます。

 

試してみたのですが、VHDファイルをダブルクリックしてもマウントできませんでした。またまたWebに助けを求めると「Windows 10でVHDファイルをドライブとしてマウントする」という記事がありました。この記事によると、ダブルクリックしてもマウント出来ないことがあるようで、その場合でも「コンピュータの管理」からマウントすることはできるそうです。その手順に従うと、確かにマウントできました。

もうひとつのUPと放送大学

東京大学出版会の広報誌「UP」の2025年4月号には連載「言語学バーリ・トゥード」が掲載されていました。この連載は毎回楽しく読んでいるのですが、驚くところがないわけではありません。同じように感じる人もいて、同誌の「東大教師が新入生にすすめる本」の中で、向山直佑准教授（未来ビジョン研究センター）は、次のように書いています。

『科学的エビデンスにもとづく 100歳まで健康に生きるための25のメソッド』 ルイージ・フォンタナ／寺田新訳(2022)

東大出版もこういう本をだすのか、と驚いた一冊（その後『言語学バーリ・トゥード』に接してもっと驚いた）。 

その連載には、次のような箇所がありました。

 記録係：知らない人を呼ぶのにちょうどいい言葉って、選ぶのが難しいからです。言語学者の滝浦真人も「“知らない人”という呼称のカテゴリーがない」と言ってますし。

 

ここには大学名は出ていませんが、同氏は今は放送大学教養学部人間と文化コース／大学院文化科学研究科の教授です。放送大学は、形式的には放送大学学園が運営する私立大学です。通信制であるため、テレビや新聞の大学入試報道などで取り上げられることはありません。しかし各分野で著名な人達を講師陣に揃えており、しっかり学ぼうとするとお得なのではないかと感じています。

UPと放送大学

東京大学出版会の広報誌「UP」の2025年4月号を読んでいたら、興味深い記事がありました。

 

毎年4月号は「東大教師が新入生にすすめる本」というのが巻頭を飾ります。この企画は、1988年に始まったそうで、今年で38回目だそうです。東京大学出版会の雑誌ですから、基本的に東大の新入生を念頭に置いていると思いますが、それ以外の大学の新入生でも、新入生でなくても、もっと言えば誰であっても、参考になると思います。

 

アンケートの設問は4つあり、その中で「これだけは読んでおこう―研究者の立場から」について、谷中瞳准教授（情報理工学系研究科・理学部）は、放送大学の印刷教材である『自然言語処理』を紹介していました。そこでは次のように書かれています。

 本書は自然言語処理を学びたいという方に、私がいつも最初に読むと良いとお勧めしている書籍である。

 

この科目は昨年受講しました。この科目に限りませんが、45分×15回の講義を聴くだけなら1日で終わってしまいますが、講義を理解し、派生事項にも手を伸ばそうとすれば、それなりに時間がかかると思います。そのような気持ちで、数年前に受講した「入門微分積分('16)」を学びなおしているところです。

NHKの新番組「会話が続く!リアル旅英語」が面白い、しかし…

2025年4月からEテレで放送されている「会話が続く!リアル旅英語」が面白いのですが、これは語学学習のための番組なのでしょうか。NHK出版からテキストが出版されていますし、NHK語学サイトからリンクされているので、NHKとしては「語学学習番組」のつもりだろうとは思います。

 

番組を実際に視聴してみると、何の前触れもなく、リアルな英会話シーンが映し出され、生徒役をつとめる出演者が四苦八苦しながら聴きとれた発言を書きだしています。よくある語学学習番組のように、完璧な聴き取りを求めているわけではないようです。

 

これは確かに「リアルな旅英語」だろうと思うし、ネイティブは、このような会話をしているのでしょう。そうとは思いますが、この番組の対象者を制作側がどのように考えているのか気になります。NHKが提示しているCEFRレベルは「A2～B1」ということになっています。A2とは「日常生活での身近なことがらについて、簡単なやりとりができる」ということのようです。「TOEIC® Program各テストスコアとCEFRとの対照表」によると、A2というのはTOEIC L&Rで「225～550点」に相当するようです。

 

番組において、ネイティブの発言は、聴きとれてしまえば、それほど難しいことを言っているわけではありません。しかし日本人向けに手加減しているわけではありませんし、ネイティブならば日常的に使われる表現であっても、日本人には馴染みのないものも、どんどんでてきます。まさに「リアル」な英語です。

 

このような語学番組もあるだろうと思いますが、僕自身としては「ドライ」だと感じます。しかしそれは「語学番組」としての感想で、そうではないジャンル（例えば「旅番組」）であれば、特に違和感もないと思います。

巻島 隆『飛脚は何を運んだのか―江戸街道輸送網』

近所の書店で『飛脚は何を運んだのか―江戸街道輸送網』（ちくま新書1841）を見かけましたので、買ってみました。他の新書よりもページ数が多く、読むのに時間がかかりましたが、興味深く読了しました。巻末資料も充実していますし、参考文献も豊富に掲載されているので、これを出発点として、さらに詳しく学ぶにも助かりそうです。

 

私自身の興味関心としては、「飛脚」そのものではなく、明治になって前島密によって創設された郵便制度というものを、当時の人たちは違和感なく受容できたのだろうか？という点にあります。この新書が僕の疑問を解消するための直接的な参考になるわけではありませんが、江戸時代の飛脚制度を知れば、飛脚から郵便への過渡期について何か得られるところがあるのではないかと考えました。

 

本書の「第12章 飛躍する飛脚のイメージ」の「本書まとめにかえて」に、次のようなくだりがありました。

以上、本書で見たように江戸時代における飛脚利用は、身分的に多岐に亘っている。幕府、大名家、旗本、商人、村・町名主、文人などがよく飛脚問屋・飛脚を使った。

しかし、その日暮らしの長屋住まいの庶民が使うケースはおそらく稀であったろう。肉親の危篤や、かなりの緊急性のある場合でなければ、飛脚を使うことは滅多になかった。

 

この記述を考えれば、江戸の頃から飛脚を利用していた層であれば、明治の郵便制度が始まっても、制度的な差異があっても、とくに違和感もなく利用できたのではないでしょうか。しかし江戸期に利用していなかった人々からすれば、明治になって郵便という制度が始まったとしても、直ちに受け入れられたとは思えません。

 

郵便を受け入れられないというのは、これは僕の想像ですが、制度を受け入れられないという意味ではないと思います。もちろん慣れない制度が始まったので、最初は違和感があったでしょうが、それは慣れれば済む話です。むしろ、明治新政府のお触れなどで「郵便」という制度が始まったのは知ったとしても、江戸期に飛脚を利用しなかった人達にとって、それが自分達に関係のある事だと考えなかったのではないかと思うのです。

 

2025年の今日には当たり前となっている制度は、明治になって創設されれものが少なくありません。今日では当たり前でも、当時は当たり前ではなかったわけで、当時の人々は新設された制度を態々何かに使ってみようとするほど暇ではなかったのではないでしょうか。明治新政府の側から、利用を促すような施策がとられた可能性があるかもしれません。このような過渡期に現れる事象について、知りたいと思っているのです。

pathTranslationStyle

WSLを利用する際にはWindowsターミナルを使っています。昔々のWindowsターミナルでは、エクスプローラからフォルダなどをドロップすると、Unix形式のパスに変換してくれて便利だったのですが、いつの間にかWindows形式のパスのままになっていました。形式変換には「wslpath」というコマンドがあるので、何とかなるのですが、ドロップした時に自動的に変換して欲しいと思っていました。

 

ところが、ふとしたことで、求めていた自動変換が実現していることを知りました。「pathTranslationStyle」という設定パラメータで制御できるようです。2025年2月5日付の記事「Windows Terminal Preview 1.23 Release」には、次のような記述があります。

WSL and Ubuntu lovers will love this next one! We now have a Path Translation setting that allows users to control how file paths are translated during drag-and-drop operations. This setting will also be backported to Windows Terminal 1.22!

 

 つい最近になって入った機能のようです。待ってました！という気持ちです。

WSL2とVirtualBoxが共存できた

先週後半にVirtualBoxを更新したら、WSL2が動かなくなり、復旧しようとして試行錯誤したらVirtualBoxも動かなくなってしまいました。ひとまずVirualBoxはアンインストールし、WSL2だけは動くようにしておきました。頭を冷やして、VirtualBoxとWSLを入れなおしたら、なんとか共存できているようです。

 

大雑把な手順は次の通りです。

1. まず前提として、VirtualBoxは既にアンインストールしてあります。
2. 「Windowsの機能の有効かまたは無効化」から「Linux用Windowsサブシステム」を無効にします。ここでWindows10を再起動します。
3. まずVirtualBox 7.1.8をインストールしました。念のためにWindows10を再起動しておきます。
4. ここでVirtualBox上の仮想環境を動かしたら、エラーになりませんでした。
5. 次に「Windowsの機能の有効かまたは無効化」から「Linux用Windowsサブシステム」を再び有効にします。やはりWindows10の再起動が必要です。
6. 心配なので、VirtualBox上で仮想環境を動かしてみましたが、エラーになりませんでした。
7. WSL2でUbuntuを実行してみたら、エラーにならずに動きました。

 

これで、ひとまずはWSL2もVirtualBoxもエラーにならずに動いてくれるようになりました。しかし、WSL側か、VirutalBox側で何かが更新されたら、また動かなくなるかもしれません。将来も安心というわけにはいかないかもしれません。

 

どんな環境でも絶対大丈夫とは言えませんが、動作した事例があるということは言えます。ちなみにWSLのバージョンは次の通りです。

WSL バージョン: 2.4.13.0
カーネル バージョン: 5.15.167.4-1
WSLg バージョン: 1.0.65
MSRDC バージョン: 1.2.5716
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.19045.5737

 

またVirtualBoxのバージョンは次の通りです。 

VirtualBox グラフィカルユーザーインターフェース
バージョン 7.1.8 r168469 (Qt6.5.3)

鉄道ジャーナル

先週末にはTMSが1000号を記念するという喜ばしい出来事があったばかりですが、今週は鉄道ジャーナルが最終号を迎えるという悲しい出来事がありました。TMSと同様、鉄道ジャーナルも父親が購入していて、僕自身も子供の頃から親しんでいました。鉄道ジャーナルの他にも雑誌はありますが、鉄道関係に限らず出版業界全体が苦しい状況にあるようですから、他の雑誌も継続が危ぶまれる事態になるかもしれません。

 

今後の動向はわかりませんが、鉄道に関する情報が全くなくなる事はないと思います。どういうメディアが勃興してくるのか、興味をもって見つめていきたいと思います。

TMS

鉄道模型の雑誌である「鉄道模型趣味」 （通称TMS）が2025年5月号で通巻1000号となり、記念として記事DBなどの付録DVDがつきました。この雑誌が創刊されたのは終戦直後の1947年でした。父親が鉄道が趣味で、この雑誌も自宅にあり、僕自身も子供の頃から親しんでいました。

 

雑誌名である「鉄道模型趣味」というのは、何やら不思議なネーミングです。どこかで読んだ記憶があるのですが、戦前は「鉄道模型」というと小難しく「研究に資する」とか言われるような風潮があったそうで、あえて「趣味」という語を入れることで、「鉄道を研究するために云々」というややこしい話ではないことを主張したかったようです。

 

雑誌名の由来は理解できるのですが、それをローマ字にして「Tetsudo Mokei Shumi」となり、略称「TMS」となったのは、時代のなせる業でしょうか。「Hobby of Railroad Modeling」のようになりませんでしたが、今でも「TMS」といえば、鉄道模型界をリードする存在です。

VirtualBoxの最新版を入れたら仮想環境が起動しなくなり、しかもWSL環境も動かなくなった

VirtualBox 7.1.8が出たので更新したら、仮想環境が起動しなくなってしまいました。これがVirtualBoxの不具合なのか、僕のマシン（Windows10）の問題なのか分かりませんが、原因が何であったにせよ、ともかく仮想環境が起動しません。さらに不幸なことに、WSL2環境も動かなくなりました。WSL2環境は、更新作業の直前には動作するのを確認しています。VirtualBoxの仮想環境も、最近使用して、問題ありませんでした。

 

もしかすると、再起動したら問題なく動作するのかもしれません。微かな望みをかけつつ再起動しましたが、WSL2環境もVirtualBoxの仮想環境も起動しませんでした。

 

とにかく復旧させなければならないので、VirualBoxをアンインストールしました。念のために再起動したのですが、WSL2環境は相変わらず起動しません。

 

 次に「Windowsの機能の有効化または無効化」から「Linux用Windowsサブシステム」を一旦無効にして、改めて有効にしてみました。この間、何度か再起動しています。それでもWSL2環境は起動してくれません。

 

最後にWSL2としてインストールしてある「Ubuntu」を削除し、改めてインストールし直したところ、ようやくWSL2環境でUbuntuが動作してくれました。しかし一度削除しているので、壊れる前のファイルは全て無くなってしまいましたが、WSL2環境が復活したので、これで良しとします。

 

VirtualBoxの最新版に何か不具合があったのかもしれませんが、その確証はありません。もしかすると僕の使っている環境がWindows10なのが良くないのかもしれません。今年秋にはWindows10のサポートが切れるので、それまでにはWindows11に移行しようと思っています。でも薄々感じるのですが、Windows11になっても、今回のような突発的なトラブルからは逃れられない気がします。

ETCの利用率は95%超らしい

2025年4月6日（日）に「1都6県でETC障害、通行料金を後日払いで対応　復旧のめど立たず」という記事が流れました。他社からも同様の記事が流れています。その他に、参考情報として「ETCの利用状況は95%以上ある」という記事も目にします。この根拠は、国土交通省の「ETCの利用状況」らしく、令和7年1月時点で95.3%とあります。

 

この統計だけなら、ETC利用率は、ほぼ100%に達していると判断できそうです。昨年あたりから、首都高や阪神高速などの料金所がETC専用ゲートになるという話も耳にします。例えば「首都高、2025年度に55箇所の料金所をETC専用化　計90箇所に拡大へ」という情報です。

 

しかし私の車にはETC機器が設置されていません。高速道を利用することがないからなのですが、たまに利用することがないわけではありません。しかしETC専用ゲートばかりになってしまうと、高速道路の利用から追い出されているような気になります。しかも首都高では「現金でご利用のお客さま」にあるとおり上限額（普通車で1,950円）を支払うことになるので、なおさら利用する気がなくなります。

 

ここで疑問なのが「ETC利用率」とは何なのか？です。定義は確認できませんでしたが、おそらく料金ゲートでETCを利用した割合なのでしょう。この母数は料金ゲートを通過した数であって、日本国内の車両全体ではありません。調べてみたら、国土交通省のサイトで「ETCの利用状況、導入効果等」というPDFを見つけました。この3ページには「ETC普及率」という情報が載っています。それによると、自動車保有台数7,970万台のなかでETCがセットアップされているのは3,994万台で、ETC普及率としては50%だそうです。

 

以上から、高速道路をよく利用する車においては、ほぼ全てがETC機器を設置済みだと言うことです。考えてみれば、よく高速を利用し、料金ゲートを通過しているなら、ETCにしない理由はないでしょう。その方が圧倒的に利便性が高いですから。ところがETC普及率が50%ということは、ETC機器が設置されていない車はまだまだ多いということです。私の車もその一台ということになります。そのような車だって、たまには高速を利用することがあるでしょう。もしくは高速を利用したい気持ちになることがあるでしょう。それなのに、全ての料金ゲートがETC専用になってしまうのは、拙速と感じます。

 

非ETCの料金ゲートを残しておくと、そのために担当者を配置しておかなければならないのを嫌がっているのかもしれません。それは理解できなくもありませんが、だからETC専用ゲートだけにしてしまうのは、それはそれで問題だと思います。非ETC車両でも利用できるような無人料金ゲートがあれば助かるのですが。

「FH2$W_RECATTR」の構造がわからない

simh V3.8-1のvax.exeを使ってOpenVMS  VAX V7.2を動かしています。OpenVMS側にあるファイルをWindows側に持ってくるため、simhの仮想磁気テープのファイルを使用する方法を考えています。他にも方法はあると思いますが、技術的興味から、しばらくはこの方法を追求してみようと思っています。

 

OpenVMS側で作成した磁気テープはANSI X3.27 Level 3に準拠した構造になるようです。マニュアル『Guide to OpenVMS File Applications』の「1.3.1. ANSI-Labeled Magnetic Tape」に情報があります。その「1.3.1.6.3. HDR3 Label」では「These attributes are converted from 32 bytes of binary values to 64 bytes of ASCII ...」のような記述があります。さて、この32バイトの情報は、具体的にはどのようなものなのか調べているのですが、核心の情報にたどり着けていません。

 

ODS2を操作する何かのプログラムの一部らしき箇所に「struct RECATTR」という構造体がありました。この中の要素を数えると、32バイト分ありましたので、多分これがそうなのかもしれません。しかしプログラムのソースファイルに書かれているということは、何か出典となる情報に基づいていると思われますが、それが何なのか見つからないのです。

手元に『VMS File System Internals』（ISBN 0-13-931783-X）があるので調べてみると、「Figure 2-2: Format of the Header Area」の中に「FH2$W_RECATTR (32 bytes)」という箇所を見つけました。多分これのことだろうと思うのですが、32バイトの詳細構造がわかりません。

 

同書の「2.4.1 Directory Structure」では、「The last word of the directory file's record attributes area (FAT$W_VERSIONS) is ...」のような記述があるところを見ると、何か構造があって然るべきなのですが、その構造を記した情報にたどり着けません。

 

この構造がわからなくても、OpenVMS→Windowsの情報転送には困らない感触があるので、わからないならわからないで構わないとは思います。しかし何かに書かれているのであれば、それを知りたいところです。

『平家物語』を「鱸」まで覚えた

 2023年の夏頃から『平家物語』を暗記しようとしています。覚えたから何かあるわけではありません。ただし、ただ読み流すだけよりも、言葉の一つ一つに注意が向くようになりました。

 

『平家物語』と言えば、「祇園精舎の鐘の声、諸行無常の響きあり」で始まる冒頭が有名です。『平家物語』には、話のまとまりごとに副題がついており、冒頭の箇所は「祇園精舎」です。次が「殿上闇討」で、「鱸」、「禿髪」と続きます。

 

覚え始めてから2年弱ほどですが、ようやく「鱸」まで覚えました。重要人物である平清盛がようやく登場してきました。これから覚える「禿髪」では、「驕る平家は久しからず」のエピソードが語られていくことになります。

 

『平家物語』は、まだまだ長いので、一生かかっても覚えきれないでしょう。そもそも巻一すら終わらないかもしれません。

OpenVMSのRMS attributesにおける「32 bytes of binary values」って何？

simh V3.8-1のvax.exeを使ってOpenVMS VAX V7.2の環境を整えようとしています。ひとまずOSを入れることはできています。今後の作業を考えると、OpenVMS側からWindows側にファイルを持っていく方式を考えておこうと思っています。TU-81で磁気テープを使おうと思いますが、実際には仮想環境なので、現実にはsimhの仮想磁気テープのファイルを扱うことになります。磁気テープはANSI X3.27形式が使われているようなので、その構造を理解しようと思います。

 

OpenVMSにおける磁気テープの構造は『Guide to OpenVMS File Applications』に詳しい情報があります。ここで「1.3.1.6.3. HDR3 Label」には、次のような記述があります。

The RMS attributes describe the record format of a file. These attributes are converted from 32 bytes of binary values to 64 bytes of ASCII representations of their hexadecimal equivalents for storage in the HDR3 label.

 

HDR3にはRMS attributesが格納されており、その32バイトのバイナリ値が64文字のASCII文字列として表現されているというのです。つまり1バイトが2文字ですから、いわゆる「16進ダンプ」のような見た目なのでしょう。それは良いのですが、「RMS attributes」というの何でしょうか。

 

「RMS attributesのことなら、もう既にご存知かと思いますが」と言うかのような感じです。しかし私は何のことかわからないので、調べてみなければなりません。おそらく何かのマニュアルに詳しく記述されていると思います。それを探し出そうと思います。

simhのvax.exe上で動作させるOpenVMS VAXにおける仮想磁気テープのファイル構造

simh V3.8-1のvax.exeを利用してOpenVMS VAXを動かしています。OpenVMSからWindowsにファイルを送るために、simhの仮想磁気テープのファイルを使おうと思います。OpenVMS側は、磁気テープをANSI X3.27 Level 3に準拠した構造にしているそうです。ANSI X3.27の構造には詳しくありませんが、仕様書をネットで見つけましたので、調べてみようと思います。

 

ファイル構造を調べるため、OpenVMS側でファイルをテープに格納してみて、そのファイルがWindows側でどのように見えるかを確かめてみようと思います。そのファイルの16進ダンプは、次のようになりました。

00000000  50 00 00 00 56 4F 4C 31 53 49 4D 48 20 20 20 20  P...VOL1SIMH    
00000010  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000020  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000030  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000040  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000050  20 20 20 33 50 00 00 00 50 00 00 00 48 44 52 31     3P...P...HDR1
00000060  54 45 53 54 31 2E 54 58 54 20 20 20 20 20 20 20  TEST1.TXT       
（以下略）

 

ANSI X3.27の仕様書によれば、「VOL1」とか「HDR1」というのが、規定されている構造を示す文字列のようです。それでは、その前にある「50 00 00 00」というのは何でしょうか。当初、これもANSI X3.27の規格で定められている情報かと思ったのですが、そうではなさそうです。

 

ネットで情報を探ってみると「SIMHで古代UNIXを再現(2)」を見つけました。この中に「SIMHのテープフォーマットは、SIMH Magtape Representation and Handlingに解説があります。」という記述があります。この「SIMH Magtape Representation and Handling」を確認してみると、SIMHの都合により、実データの前後に「Leading Length」と「Trailing Length」が入るようです。これが「50 00 00 00」なのでしょう。

 

ひとまず、SIMH側が挿入する情報の構造は判明しました。この段階で、仮想磁気テープのファイルをアクセスしてみるプログラムを組んでみました。これを拡張すれば、ANSI X3.27の構造を表示するプログラムになると思います。

 

 #!/usr/bin/python3

def readrecord(f):
    global TapeMark
    len0 = int.from_bytes(f.read(4),'little')
    if len0 == 0:
        TapeMark += 1
        if TapeMark >= 2: raise EOFError
        return 0
    TapeMark = 0
    data = f.read(len0)
    len1 = int.from_bytes(f.read(4),'little')

    print(TapeMark, len0, data[:4], data[4:16])

    return 0 if len0 != len1 else len0

def readblock(f):
    while True:
        if readrecord(f) == 0: break

TapeMark = 0
with open("test-tu81.tap","rb") as f:
    while True:
        try:
            readblock(f)
        except EOFError:
            break
#[EOF]

simh上のOpenVMSとWindowsとの間でのファイル交換

simh V3.8-1のvax.exeを使用してOpenVMS VAX V7.2を楽しんでいます。まだOSをインストールだけです。今後のことを考えて、いまのうちにOpenVMSとWindowsとの間でファイルを交換するための方法を考えておこうと思います。

 

普通に考えれば、最も適切なのはネットワークを利用することでしょう。TCP/IPが使えるようになれば、FTPを利用するだけのことです。もしネットワークを利用しないのであれば、往年の環境がそうであったように、何かオフラインで利用できるメディアを使うことになります。以下のようなメディアが考えられます。

• CD-ROM
• 磁気テープ
• フロッピーディスク

 

simhをWindows上で動作させており、WSLが使えるため、WSLでmkisofsを使えば、Windows上のファイルを含んだISOファイルを生成できます。そのISOファイルをsimhでattachしておけば、OpenVMSではRRD40からマウントできるので、WindowsからOpenVMSにファイルを渡せるようになるはずです。しかしCD-ROM経由では、逆方向（OpenVMSからWindows）は難しそうです。

 

磁気テープを使うというのは、いかにもクラシックなコンピュータという趣がします。simhではTU81として指定されたデバイスにファイルをattachしておけば、OpenVMS側ではINITIALIZEやMOUNTなどの操作が可能です。何か適当なファイルをCOPYすれば、simh側でattachされているファイルに書き込まれるのを確認しました。

 

問題は、Windows側でファイルを取り出す方法です。ファイルを確認してみると、ANSI X3.27形式のヘッダが付いているようです。これを解釈して、特定のファイルを取り出すには、どうしたら良いのでしょうか。もし本当にテープデバイスを持っているなら、mtコマンドが使えるかもしれません。しかしsimhが作成した単なるファイルに対してmtコマンドは使えません。

 

ANSI X3.27形式のヘッダが入っているファイルを解釈して操作できるツールというものが、存在しても不思議はないのではないかと思うのですが、ネットを探しても見つかりませんでした。何か方法がないか、探ってみようと思います。

 

最後のフロッピーディスクというのは、何ができるのか全くわかりません。そもそもOpenVMSで扱うフロッピーディスクは、FATを解釈できるのでしょうか。もしかするとODS-2だけのような気もします。仮にFATを取り扱えるとしても、それをWindows側で「仮想的なフロッピーディスク」として操作するには、どうするのか見当もつきません。

OpenVMS VAXに接続する端末エミュレータのためのキーマップ設定におけるTera TermとRLogin

simh V3.8-1のvax.exeを使ってOpenVMS VAX V7.2をインストールしました。まだOSを入れただけですが、simhではDZデバイスをTCP/IPで接続できるので、端末エミュレータからログインできるようになりました。端末エミュレータとして、昔はTera Termを利用していたのですが、ずいぶん前からRLoginに移行しています。端末エミュレータを使い分けるのは面倒なので、できればRLoginを使いたいとは思いますが、ひとまずTera TermとRLoginで使い勝手を検討します。

 

まずログインするだけであれば、Tera TermでもRLoginでも、いずれも可能でした。ただし注意が必要なのは、ログイン先がOpenVMSだということです。Tera TermもRLoginもVT端末の動作を再現しようとしており、VT端末のエスケープシーケンスにも対応しているようなのですが、キーボードの扱いがどうなっているのか、気になります。

 

そもそも、DECのVT端末でつかわれているLK201キーボードと、PCの109キーボードとでは、違う点があります。

1. ファンクションキーは、LK201では20個ありますが、109キーボードでは12個しかありません。
2. 109キーボードのテンキーにおける「+」キーは、LK201では「-」と「,」として別のキーになっています。
3. カーソルキーの上部にある6個のキーの役割が、LK201と109キーボードでは、配置が異なります。

 

Windows上で動作する端末エミュレータは、109キーボードを使いますが、VT端末として操作するためにはLK201と同等の操作ができる必要があります。このためには、上述した違いを吸収するために、キーマップ設定をおこなわなければなりません。

 

端末エミュレータで実現できるか否かを確認するまえに、どのようなキーマップ設定とするか方針を決めておきます。

1. LK201のファンクションキーは20個あり、109キーボードの12個では数が足りません。そこで、F1～F10を使うことにして、F11～F20は、Shift+(F1～F10)で実現することとします。
2. 109キーボードのF11とF12が余りますが、これはLK201のF15とF16に割り当てます。OpenVMSではF15を「Help」として、F16を「Do」として使っています。これらは使用頻度が高いので、押しやすいようにF11とF12を使います。
3. カーソルキーの上部にある6個のキーは、LK201と109キーボードで配置が異なります。例えば、「Ins」と「Del」が109キーボードでは左端にありますが、LK201では「Insert」と「Remove」は右上にあります。ここで考えるのは、109キーボードの刻印を無視してLK201の配置に合わせるのか、LK201の配置を無視して109キーボードの刻印に合わせるのかという選択です。もし日常的にLK201を利用しているのであれば、身体が配置を覚えているでしょうから、LK201の配置に合わせたほうが良いでしょう。しかしキーの刻印を参照しながら操作するのであれば109キーの刻印に合わせた方が良いことになります。私自身は、LK201を使用する機会はありませんので、109キーボードの刻印を見ながら操作することになると思うので、キーボードの刻印に合わせてエスケープシーケンスが送出されるように設定します。
4. 109キーボードのテンキーには「+」しかありませんが、LK201では「-」と「,」の2つのキーがあります。これを実現するため、テンキーの「+」は「,」に割り当てることとして、Ctrl+「+」を「-」にしました。

 

このような方針を実現できるように、端末エミュレータのキーマップ設定をおこないます。設定ができているか否かは、OpenVMSの「EVE（EDIT/EVE）」や「EDT（EDIT/EDT）」で確かめます。

 

Tera Termの場合は「KEYBOARD.CNF」というファイルに対応関係を記述するようです。EVEやEDTで確かめましたが、問題なさそうです。

 

RLoginは、設定画面を使います。Tera Termとはキーマップの考え方が違うようで、Microsoft Windowsの仮想キーコードを使って割り当てをおこなうようです。ところが、この方式だとVT端末と同等の挙動を実現できませんでした。LK201はテンキーの上部にPF1～PF4が割り当てられており、特にPF1は「GOLD」として使われます。ところが109キーボードでは「NUMLOCK」なので、例えばテンキーの「7」は、NUMLOCKの状態によって「7」だったり「Home」だったり変化します。このため仮想キーコードも「PAD7」と「HOME」となり、特に「HOME」の場合は、カーソルキー上部にある「Home」と区別することができません。

 

普段は、Tera Termではなく、RLoginを使用しているので、OpenVMSもRLoginにしたかったのですが、そうもいかないようです。OpenVMSを操作するときだけはTera Termにするしかないのかなと思います。

『時刻表大解剖』は面白い

近所の書店に『時刻表大解剖』という本があったので買ってみました。時刻表そのものや、鉄道の歴史などについて、詳しく書かれていて、とても楽しく読めました。本の帯には「JTB時刻表マスター認定試験」を実施するとあります。今年がJTB時刻表100周年なので、その記念イベントのようです。

 

近年JTBからは復刻版時刻表が幾つか発売されています。古い時刻表を出版しようとするには、それなりに手間もかかると思います。『時刻表大解剖』の11ページには、「電算写植完了」が昭和62年12月とあります。それ以降のものであっても、すぐに復刻版が出版できるわけではないと思いますが、それ以前のものであれば、なお大変でしょう。かけた手間に見合うだけの販売数が見込めるかという営業判断も必要かとは思います。そうであっても、昭和43年10月大改正（いわゆる「よんさんとう」）のような画期となるものが、戦前とか終戦直後にはないものでしょうか。そのような時刻表も復刻版を出版してくれれば、とても嬉しいです。

PlantUMLはネットワーク図も描けるのか。

何処で知ったのかは忘れてしまいましたが、PlantUMLというものを知りました。テキストで記述されたものから様々な図を生成できるようです。いわゆる「お絵描きツール」を使ってグラフィカルに作図するのではありません。例えていえば、Microsoft Wordを使うのではなく、LaTeXを利用するようなイメージです。

 

いろいろなことができるようなのですが、腰を据えて利用してみるまでには至っていません。使い方の情報を得るため、PlantUMLのQ&Aフォーラムを見るようにしています。すると「Forcing net positions in nwdiag」という質問がありました。その質問の内容はさておき、綺麗なネットワーク図が描けることに驚きました。

 

PlantUMLでは、こんなこともできるのか。使いこなせば、便利なツールになりそうです。普段使いできるように、練習してみようかと思います。

RLoginでOpenVMS VAX V7.2に繋ぐと「VT500_Series」になる理由

simh V3.8-1のvax.exeを用いてOpenVMS VAX V7.2の環境を構築し、DZデバイスを経由してRLogin V2.30.2.1を用いて接続すると「VT500_Series」として認識されます。なぜこうなるのか調べてみました。

 

RLoginの公式サイト「エスケープシーケンス一覧」の「CSI一覧」によると、「DA1」のところに以下の記述があります。この記述における「TermID」というのは、設定「制御コード」の中にある「ESC/CSI/DCS」を開き、「各種ID」の中にあります。

TermID     DECTIDのTermID設定によりレスポンスが異なる

 

デフォルトでは「10」になっています。これが「VT500_Series」に相当するようです。「9」にすれば「VT400_Series」に、「7」か「8」ならば「VT300_Series」になります。「1」なら「VT100」として認識されます。

 

OpenVMS VAX V7.2を操作するためであれば、VT200以降であれば何でも構わないだろうと思います。Tera Termは「VT300_Series」として認識されているので、それと揃えようかと思います。

simhのDZデバイスでOpenVMS VAX V7.2に接続

simh V3.8-1のvax.exeを使用してOpenVMS VAX V7.2の環境を構築しています。今のところは、OS本体を入れてだけです。今後は様々な環境構築をしていくつもりですが、そのためにも、作業しやすくするために端末環境を整えておこうと思います。

 

vax.exeから起動したままでは、OSからはLA36として認識されています。これはDEC Writer IIとして知られているもので、VT100のような端末よりも旧い、キーボードとプリンターが一体化したようなものです。当然ながらスクリーンエディタは使用できませんので、ファイルを編集するにはラインエディタを使うことになります。さすがに操作性が悪いので、なんとかしたいところです。

 simh V3.8-1のvax.exeには、DZデバイスが用意されています。これはDZV11 Terminal Multiplexerというもので、本物のVAXであれば複数の端末をぶら下げることができるはずです。simhでは「ATTACH DZ <port>」とすることで、TELNET接続を受け付けることができます。<port>は何でもよいようですが、「23」にしておけば、通常のTELNETポートになります。

 

この状態で、Tera Term V5.4.0から繋いでみました。繋ぐだけなら問題ないのですが、オプションを適切に設定する必要があります。昨今はUTF-8が主流なので、デフォルトではエンコーディングが「UTF-8」になっています。しかしこのままでは、ログイン後にエディタを起動すると、エスケープシーケンスが正しく解釈されないようです。どうやらエスケープシーケンスをUTF-8として解釈しようとして失敗しているようでした。そこでエンコーディングを「EUC」にします。これでうまくいったようです。「sh term/full」の結果は、以下のようになりました。

Terminal: _TTA0:      Device_Type: VT300_Series  Owner: SYSTEM

   Input:    9600     LFfill:  0      Width:  80      Parity: None
   Output:   9600     CRfill:  0      Page:   24

Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   No Hostsync        TTsync             Lowercase          Tab
   Wrap               Scope              No Remote          Eightbit
   Broadcast          No Readsync        No Form            Fulldup
   No Modem           No Local_echo      Autobaud           No Hangup
   No Brdcstmbx       No DMA             No Altypeahd       Set_speed
   No Commsync        Line Editing       Overstrike editing No Fallback
   No Dialup          No Secure server   No Disconnect      No Pasthru
   No Syspassword     SIXEL Graphics     Soft Characters    Printer port
   Numeric Keypad     ANSI_CRT           No Regis           No Block_mode
   Advanced_video     Edit_mode          DEC_CRT            DEC_CRT2
   DEC_CRT3           No DEC_CRT4        No DEC_CRT5        No Ansi_Color
   VMS Style Input

 

ついでにRLogin V2.30.2.1でも試してみます。こちらでもオプションを適切に変呼する必要がありました。Tera Termの経験をもとにエンコーディングを「EUC」にしてみましたが、それだけでは駄目でした。さらにエスケープシーケンス「8454」を「Reset（C1制御文字を処理する）」に変更します。当初は「Set（C1制御文字を無視する）」になっていたので、うまくいかなかったようです。「sh term/full」 の結果は、以下のようになりました。

 Terminal: _TTA1:      Device_Type: VT500_Series  Owner: _TTA1:
                                              Username: SYSTEM

   Input:    9600     LFfill:  0      Width:  80      Parity: None
   Output:   9600     CRfill:  0      Page:   24      

Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   No Hostsync        TTsync             Lowercase          Tab
   Wrap               Scope              No Remote          Eightbit
   Broadcast          No Readsync        No Form            Fulldup
   No Modem           No Local_echo      Autobaud           No Hangup
   No Brdcstmbx       No DMA             No Altypeahd       Set_speed
   No Commsync        Line Editing       Overstrike editing No Fallback
   No Dialup          No Secure server   No Disconnect      No Pasthru
   No Syspassword     SIXEL Graphics     Soft Characters    Printer port
   Numeric Keypad     ANSI_CRT           Regis              No Block_mode
   Advanced_video     Edit_mode          DEC_CRT            DEC_CRT2
   DEC_CRT3           DEC_CRT4           DEC_CRT5           Ansi_Color
   VMS Style Input

 

双方を詳しく調べたわけではありませんが、Device_Typeが、Tera TermではVT300_Seriesなのに対して、RLoginではVT500_Seriesになっています。

 

ひとまずTera TermやRLoginから接続できるようになりました。これならDEC Writer IIよりも快適になるでしょう。しかし次の難問は、キーボード自体にあります。DEC LK201は、PCのキーボードとは違いがあります。しかも、エディタを使う上で、それが影響するのです。この問題をTera TermやRLoginで如何に解決するかが、課題になります。