数年前から語り本系の平家物語を暗誦しようと思い、少しずつ覚えています。「祇園精舎」から始まり、「殿上闇討」、「鱸」、「禿髪」と進み、今は「吾身栄花」を覚えているところです。
ここには、「一人は、桜町の中納言重教卿の北の方にておはすべかりしが、八歳の時、約束計にて、平治の乱以後、ひきちがへられ、花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり。」という一節があります。「花山院の左大臣殿」とは藤原兼雅のことです。二男一女をもうけたようですが、「君達あまたましましけり」というほどでもないかという気がします。
平清盛には18人の子がいたようですので、ここまでいれば「ましまし」という感じはします。現代では「マシマシ」と言うとラーメンの注文のようですが、ニュアンスは同じのように思います。
10年ほど前から、メールを読むのにGNUSを使ってきました。ここ最近になって（それでも今年とか、去年とかではありませんが）、サマリー表示が「[nobody](1970-01-01 09:00)(none)」のようになっているのに気づきました。当初は、これはGNUSのバグだと考えていたので、いずれバグフィックスされるだろうと思っていました。いつまで経っても直らないので、GNUSの利用者が少ないか、開発者が少なくて、問題が発覚しないか修正されないのかと、見当はずれなことを思っていました。いい加減に業を煮やしてGeminiに相談したところ、対策を編み出してくれました。
そもそもメールを読むのに、FreeBSDを使っています。プロバイダからfetchmailでローカルに取り込み、procmailで振り分けてから、GNUSで読んでいます。Geminiに相談した結果、fetchmailやprocmailの設定誤りが発覚しました。その対処を済ませたので、もう大丈夫だろうと思っていたのですが、相変わらず、同様の現象が発生します。Geminiに言わせれば、ヘッダが大きすぎるので、GNUSの解析が途中で打ち切られてしまうのが原因だろうと推測しているようです。そうなのかもしれません。試しにヘッダを加工して、大きすぎるエントリを削除してみると、うまく解析できているようです。そうであれば、ヘッダが悪い可能性は高いと思います。
しかしメールのファイルをWindows11上のThunderbirdで読ませてみると、別に問題が発生しないので、GNUS側でなんとかならないのだろうかという気になります。Geminiに相談を持ち掛けてみたのですが、いろいろと試してみましたが、どうにも解決に至りそうにありません。
GNUSに拘るわけではありません。しかしEmacs上で動くこと、MH形式ファイルを扱えることが必要です。この条件にあうのは、GNUS、Mew、Wanderlustが候補となります。しかし、もともとはWanderlustを使っていたのです。ところが2013年3月頃、emacs24でエラーが多発するようになり、GNUSに移行したのでした。しかしGNUSでのメール送信方法がわからなかったので、メール送信にはMewを利用してきました。
GNUSを諦めるとすると、MewかWanderlustが候補です。Wanderlustの使用を止めようと思った頃にもMewにしようかと考えました。しかしMewは、メールの未読管理ができなかったのです。つまりMewの管理外、すなわちprocmailで振分けられてしまうメールを、Mewは未読か既読か認識できなくなってしまうのです。それでGNUSを選択したのでした。
2013年3月以降GNUSを使ってきて、サマリー表示が変にならなければ、このままGNUSを使い続けていたところです。しかしそういうわけにもいかなくなってきたので、懐かしのWanderlustに復帰しようかと考え始めました。
いきなり移行してしまうのも性急に過ぎると思います。まずは、現状のGNUSを使い続け、その裏ではWanderlustを試行しようと思います。そしてWanderlustでも大丈夫だと確信できたら、その時はGNUSを諦め、Wanderlustに復帰することになります。
NHKのテレビやラジオは、ネット配信が行われています。視聴できるのは、テレビ（またはラジオ）で放送されてから1週間なのです。ただし注意が必要ですが、正確に言えば、視聴できるのは「本放送」から1週間です。「再放送」は関係ありません。
例えば「100分 de 名著」の場合、本放送は「毎週月曜 午後10時25分」で、再放送は「毎週金曜 午後３時５分」です。この場合ですと、本放送が終わってから1週間は見逃し配信がありますが、再放送は見逃し配信の期間に影響しないので、再放送からカウントすると数日間しかありません。
本放送とか再放送とか言う区分は、「放送」における区分に過ぎず、「ネット配信」とは別概念なのです。当たり前かもしれませんし、この違いは著作権の扱いによるものですが、少なからず専門的な概念ともいえるのではないかと思います。テレビやラジオを視聴している人にとって、それが本放送なのか再放送なのか気にしていないと思いますが、内部の放送関係者にすれば大問題なのです。だからこそ「見逃し配信はいつまで見られますか？」という問いに対して「見逃し配信は、放送の終了から1週間視聴できます。」と答えていますが、その真意は伝わっていないかもしれません。
視聴者からすれば、放送もネット配信も同じだと思っているのでしょうけれども、現時点では違うものです。しかしそれが未来永劫そうだとも限りません。未来は変わっていることを願いたいと思います。
SIMHのPDP-11エミュレータを利用し、PDP-11/40上で動作するUNIXv6について学ぼうと考えています。まずは「m40.s」のラベル「start」から起動するプロセスを見ていこうと思います。ここではMMUが無効になっていますが、管理レジスタを設定し、MMUを有効にするための準備をおこないます。
「mov $77406,(r1)+」のような箇所でMMUのレジスタに値を設定しています。ここでR1には「KISD0」が入っており、具体的には「172300」です。これは16bitアドレスとしての表現です。PDP-11/40のメモリ管理装置である「KT11-D」では、マニュアルの「Table 3-1 PAR/PDR Address Assignments」において「772300」のように定義されています。これは18bitアドレスです。ところがSIMHのPDP-11エミュレータでは、「17772300」のような22bitアドレスで参照しなければならないようなのです。
デバッガ機能を利用してメモリを参照した例を以下に示します。このように、16bitや18bitアドレスではMMUレジスタを参照できず、22bitアドレスで参照すると、格納されている値が参照できます。
Step expired, PC: 003370 (MOV #77406,(R1)+)
sim> s
Step expired, PC: 003374 (ADD R4,R2)
sim> e R1
R1: 172302
sim> e 172300
172300: 000000
sim> e 772300
772300: 000000
sim> e 17772300
17772300: 077406
ちなみに、CPUは次のように定義しています。
sim> sh cpu
CPU, 11/40, NOFIS, idle enabled, stability wait = 20s, autoconfiguration enabled, 256KB
エミュレーションするモデルを11/70としているのであれば、22bitアドレスでも納得するところです。しかし11/40として設定しているはずなの、22bitアドレスなのは、ちょっと不可解です。ただしSIMHが、そのような挙動なのは、そうなのですから、それを受け入れるしかありません。
2026年4月14日に「Yahoo! JAPAN ID、安全性・利便性向上を目的としてログイン方法を「パスキー」に一本化へ」という発表がありました。Yahoo以外でも、ログイン時にパスキーが使えるというサイトは増えている印象です。
普段使用しているWindows11のデスクトップPCには、スマホのような生体認証デバイスがありません。どうしたら良いのかと悩んでいたら、USBポートで使える「外部セキュリティーキー」というものがあるようです。Amazonで調べると、値段が高いものも安いものもあり、何がどう違うのか分からないので、Geminiに相談してみました。安いのでも構わないだろうと判断し、TrustKeyのT110を購入しました。Geminiからバックアップ用も必要とのアドバイスを得たので、2つあります。
さっそく幾つかのサイトでログインでパスキー認証をするように設定してみましたが、うまくいっているようです。ところが、サイトによっては、使用環境が厳しいところがあり、WindowsではEdgeかChromeと明記され、Firefoxが対象外になっている場合があります。対象外でも実は大丈夫ではないかと試してみましたが、エラーになってしまいました。
EdgeかChromeなら良いとあるので、Chromeで試してみたところ、パスキーの登録先を外部セキュリティーキーにしたら、やはりエラーになってしまいました。そのサイトではエラーになった場合の対処方法として、「何度か試してみる」とか、「キャッシュをクリアする」などが書かれているので、何度か試してみましたが、全くうまくいきません。Geminiに「キャッシュをクリアする」のは有効だろうかと質問してみましたが、それでうまくいく可能性は低いとの回答を得ました。Geminiの推測によれば、サイト側で「外部セキュリティーキー」や「Firefox」を対象外としてロジックを組んでいるのではないかとことです。
できれば「外部セキュリティーキー」を使用し、「Firefox」でパスキーの登録ができるようになってもらえるとありがたいのですが。そうでないままに、「ログイン方法をパスキーに一本化」されるのは、とても困ります。
メールを読む環境はFreeBSD/amd64上に構築しています。プロバイダからfetchmailでローカルに取り込み、procmailで振分け、GNUSで読んでいます。GNUSサマリー表示が「[nobody](1970-01-01 09:00)(none)」になってしまうのは気がついていましたが、最近になってGeminiに相談して、解決に至ったと思っていました。
ところが、再び同様の現象になりました。若干違うのは、全く同様の現象のメールと、日付だけは正しく表示されるメールがあることです。再びGeminiに助けを求めました。こちらから情報を提供し、Geminiからは、あれを確認しろとか、これを設定してみろとか指示が飛びます。基本的にはGeminiの指示に従うのですが、方向性が解決から逸れているんじゃないかと思うところもあり、軌道修正を図ります。Gemini（というか生成AI一般に）との向き合い方は、一方的に妄信するのではなく、こちらも相応の技術背景を持ったうえで、対話に臨む必要があると感じます。
閑話休題。今回の問題メールは、なんとGoogleが発信元なのです。結論として、Googleが送信時に付加する「X-」で始まるヘッダに問題がありそうだということになりました。ローカルに持ってきた問題メールをエディタで編集し、「X-」のヘッダを全て削除したところ、サマリー表示が正常になるのを確認しました。
まさかGoogleが送ってきたメールなのにと思わないでもありません。Geminiに言わせれば、（本当かどうかわかりませんが）、GNUSはヘッダの解釈が厳密で、Googleが送信するメールも完璧ではないので、こういうこともあり得るとのことでした。少なくともこちらでできることはないので、Google側が何とかしてくれる（そもそも気づいているのか）のを待ちたいと思います。
TiddlyWiki 5.4.0が2026年4月21日にリリースされました。新しいバージョンがリリースされると、いつも手持ちのTW5ファイルを更新しているのですが、今回は控えようと思います。いつも利用しているTW5ファイルを更新したら不具合が出たからです。
TW5ファイルは、基本的にはWindows11上のFirefoxで利用しています。あまり凝ったことはしていませんが、「Calendar - a simple calendar macro」というプラグインを入れています。これが動かなくなりました。具体的には「<」や「>」で前後の月に移動できなくなりました。TW5.3.8なら問題なかったのです。
またNetBSD/i386 9.0上のFirefox 52.9.0では、Internal Errorが表示され、全く動きません。「TypeError: result.mqList.addEventListener is not a function」というメッセージが出ています。Firefoxのバージョンが旧いですが、NetBSD/i386で動作するFirefoxは、これしかないのです。しかもTW5.3.8では問題なかったのです。
TW5.4.0がリリースされたばかりなので、もしかすると近日中にTW5.4.1が出るかもしれません（出ないかもしれませんが）。手持ちのTW5ファイルが数多くあるのですが、更新は当面見合わせるつもりです。
