smartctl 6.6 2017-11-05 r4594 [NetBSD 8.99.41 i386] (local build)

dynabook SS SX/15Aに入れたNetBSD/i386が不調なので、MemTest86でメモリテストを行ってみましたが、エラーは無さそうでした。次にsmartmontoolsを利用してHDDを検査してみます。

使用したバージョンは以下の通りです。 /usr/pkgsrc/sysutils/smartmontoolsで自前でビルドしました。

smartctl 6.6 2017-11-05 r4594 [NetBSD 8.99.41 i386] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

セルフテストは短時間で終わる「short」と長時間必要な「long」があります。まずは短時間で終わるテストをして、結果を確認してみます。「smartctl -t short /dev/wd0d」を実行するとセルフテストが始まります。そこで検査完了まで2分待てとメッセージが出るので、指示された時間だけ待ってから、結果を確認しました。

# smartctl -l selftest /dev/wd0d
smartctl 6.6 2017-11-05 r4594 [NetBSD 8.99.41 i386] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     18861         -

この結果を見ると、エラーは無いようです。

MemTest86でメモリを、smartmontoolsでHDDを検査してみましたが、どちらもエラーがありませんでした。しかし使っていると調子が良くないのです。なにしろ起動時にパニックして再起動してしまうのですから。障害の原因を絞り込むために、次に打つ手は何があるのでしょうか。

MemTest86 v4.3.7

今となっては旧式のdynabook SS SX/15AのOSをNetBSD/i386に入れ換えて利用しています。何分にも旧いマシンなので、ガタがきている感じです。毎日利用している訳ではありませんが、泊まりがけの外出先にもっていくこともあります。最近利用したら、起動時にパニックをおこして再起動がかかったり、ログインして使用している最中に落ちたりして、何かと不安定です。

旧いので故障があっても不思議ではありませんが、具体的に何が問題なのか把握しておきたいところです。メモリが悪いのか、ディスクが劣化しているのか、それ以外が駄目なのか調べておこうと思います。

まずメモリ検査をしてみることにしました。メモリを調べるのはMemTest86を利用するのが定番で、「PassMark Memtest86でメモリのエラーを確認する」を参考にしてテストしてみました。

公式サイトには「MemTest86 v8.1 Free Edition」がありますが、UEFI専用なのでdynabook SS SX/15Aでは起動しませんでした。同じところに「MemTest86 v4.3.7」も置いてあるので、こちらを使いました。USBからブートすると自動的にメモリ検査が始まります。メモリは4G実装してありますが、テストを1周するのに50分ほどかかりました。エラーは出なかったので、メモリは大丈夫そうです。

Webを見ていると、MemTest86によるテストを繰り返しおこなうことを推奨する情報がありますが、一方で「Memtest86で10周チェックとか意味あるのか？」のような意見もあります。もしかすると1周目ではエラーにならないのに、2周目以降でエラーになる可能性がないともいえないのでしょうが、複数回テストを繰り返したところでメモリ不具合を検出できる可能性が100%になるわけでもないと思います。複数回テストすればするほど、100%に限りなく近づいていくとは思いますが、100%になるには無限大の時間がかかるでしょう。100年間テストしても不十分かもしれません。そういう意味では、テストを1周すれば、ひとまず十分であると、割り切るのが良いのではないかと思います。

ファミレスやコンビニでよく耳にする「ファミコン言葉」

Webにある「「ファミコン言葉」の意味は? どこがおかしい?」という記事で、「ファミコン言葉」という用語を知りました。記事の中でも「ファミコンといってもゲームとは関係無く」と書かれていますが、この記事のタイトルを目にした瞬間は僕もゲームとしてのファミコンのことかと思いました。

「ファミコン言葉」というのは、記事で例示されているものを引用すれば、以下のようなものです。

• こちらランチセットになります
• 温めてよろしかったでしょうか?
• ご注文のほうは以上でしょうか
• 5,000円からお預かりします

これらは随分前から、日本語としてはおかしいとして指摘されています。『問題な日本語―どこがおかしい?何がおかしい?』で「こちらきつねうどんになりました」と指摘されたのは2004年のことです。

これだけ長く指摘され続けていながら、相変わらず使われ続けていることを考えると、もはや問題であろうがなかろうが、今後の日本語にとって無視できないのではないかと思います。日本語に限らず、言葉は文法に則り使われますが、同時に文法から逸脱していきます。それは誤用なのでしょうけれども、一般化してしまえば、それを説明できるような文法が必要になってきます。

例えば「新しい」は「あたらしい」と発音しますが、これは「あらたしい」の誤用が一般化したものであるとされます。「新しい本」では「あたらしい／ほん」と（「あたら」と）発音しますが、「新たな環境」では「あらたな／かんきょう」のように（「あらた」と）発音します。

言葉には、誤用も、方言も、流行もあるので、自分自身の感覚と合わないものがないわけではありません。どんな表現であろうと、料理にスパイスを利かせるように、表現を豊かにするために注意深く使うのであれば、許容できるものも多いと思っています。しかし、そればっかり（他の表現を使わない）というのは、嫌悪感があります。そういうものの一例として、何かというと「たく。」や「かと。」で文を閉じるのは、あまり良い印象を持っていません。

NetBSD/i386でWindows10をmount_smbfsできない

dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて利用しており、自宅のWindows10のデスクトップPCの「ドキュメント」フォルダを、「~/Documents」として同期させています。同期させる方法は、元々入っていたのはWindows Vistaだったので、その時は互いにWindowsであるために特別工夫しなくても、同期できていました。ところが現在は、Windows10のファイルを、NetBSDに持ち込むため、いろいろと考えておかないと同期できません。

まず考えるポイントは、Windows10とNetBSDのどちらをサーバーとして利用するかという点です。NetBSDはNFSサーバになれますが、Windows10にはNFSクライアントがありません。またWindows10はSMBで共有フォルダを作れますが、NetBSDからマウントするには多少工夫が必要です。

さらに同期させようとするファイル群を、Windows10側からNetBSDに送り付ける形にするのか、それともNetBSD側からWindows10に取りに行く形にするのかも考える必要があります。これは要するに同期処理に手作業を絡ませたくないからです。ファイルが数個程度なら、GUIツールを使って手作業で済ませることも可能でしょうけれども、場合によっては何百個もファイルがある可能性を考えると、極力手作業を排除して自動的に一連の処理が完了するようにしたいところです。

実は同期する処理は、出来ていた筈でした。NetBSD側からWindows10の共有フォルダをSMBFSとしてマウントし、別途用意される同期対象ファイルリストを基に、NetBSDからWindows10にファイルをとりに行くようにスクリプトを組んでありました。スマートではない面があるとしても、これで同期できている筈でした。ところが、何時から駄目になったのかは不明ですが、気がついたら、動かなくなっていました。

NetBSDでSMBFSをマウントするのは「mount_smbfs」と「rump_smbfs」があります。マウントされているファイルの文字コードの違いを吸収するためにrump_smbfsを利用していましたが、以下のようなエラーが出てしまいます。

[   6.1700090] panic: no such socket
[   6.1700090] rump kernel halting...
halted
rump_smbfs: puffs_daemon got 0 bytes

もうひとつのmount_smbfsでは、メッセージが違いますが、やはりエラーになります。

mount_smbfs: unable to open connection: syserr = Connection reset by peer
mount_smbfs: lookup 54: Connection reset by peer

何が悪いのかメッセージから読み取れません。もし接続時の認証に失敗しているのであれば、そのようなメッセージが出るので、認証絡みではない気がします。

この問題を解決したいと思っていますが、同期方式を再検討する必要がありそうです。

procmail: Unable to treat as directory "LAN/tpe530c"

日常的なメール送受信はFreeBSDで行っています。メール受信はfetchmailでプロバイダのメールボックスから取得し、procmailで夫々のフォルダに振り分けています。振り分けルールは~/.procmailrcに記述されていますが、諸々の理由により振り分けられずにinboxに落ちることがあります。その場合には、今後は振り分けられるようにするため、随時.procmailrcを更新しておくようにしています。

先日.procmailrcを書き換えたところ、誤操作で重要な設定を書き換えてしまいました。すぐに気づけば良かったのですが、気付かずにメール受信をおこなってしまいました。すると以下のようなエラーが大量にログに残り、本来振り分けられて置かれるはずのフォルダには一切メールが送られませんでした。

procmail: Unable to treat as directory "LAN/tpe530c"
procmail: Error while writing to "LAN/tpe530c"
procmail: Lock failure on "inbox/..lock"
From root@tpe530c.myhome.jp.invalid  Sat May 18 00:22:06 2019
 Subject: tpe530c.myhome.jp.invalid security updates
  Folder: inbox/1                               1217

届いている筈のメールが一切にないことで、何か問題が起きたことを認識したのですが、当初は何が起きたのか理解できませんでした。ログでは、本来置くべきディレクトリに書けないのでinboxに書き出した、というように読めます。それでinboxを確認したのですが、何も書かれていないようでした。実はこれが勘違いだったのですが、受信したメールを失ってしまったと誤解して、ショックを受けました。

落ち着いて.procmailrcの変更点を再確認しました。このような事態を予想していたわけではないのですが、CVS管理をおこなっていたため、差分（変更点）の確認が容易でした。そうすると行頭にある「MAILDIR  = $HOME/Mail」という設定を「TAILDIR」と書き換えてしまっていたことに気付きました。それが原因だとわかったので、書き直して復旧できました。

混乱したinboxは、~/Mail/inboxと~/inboxの取り違えだったのでしょう。

ホームディレクトリにあるファイルをCVS管理していますが、余計な手間をかけているだけではないかと思わなくもなかったのですが、こういう時に役立つとは思っていませんでした。このような仕掛けをしておくと、思わぬ時に役立つこともあると再認識しました。

「テレビを持っていません」の今昔

Webを視ていたら「テレビを持っていない」ことが話題になっているのを見つけました。「テレビ」を持っていないという言い回しは、単に何かを持っていない（それが偶々「テレビ」だったという）だけではない含意があると思います。

テレビが登場した直後に大宅壮一が「一億総白痴化」と論じました。ウィキペディアでは次のようにかかれています。

もともとは『週刊東京』1957年2月2日号における以下の論評が広まったものである。
テレビに至っては、紙芝居同様、否、紙芝居以下の白痴番組が毎日ずらりと列んでいる。ラジオ、テレビという最も進歩したマスコミ機関によって、『一億白痴化運動』が展開されていると言って好い。

これを踏まえて、テレビを視ないことに積極的な意義を見いだす志向が生まれたと思います。当時であれば、テレビを視なければ、本を読むとか、レコードを聴くなどすることになったでしょう。テレビは受動的な娯楽ですが、読書や音楽鑑賞は能動的な娯楽である側面を持つため、「テレビを視るのを止めて、小説を読破した」などという方が好ましく思われるという効果が期待されます。

このようなテレビ黎明期の風潮が今日でも続いているようですが、社会は変わっているのではないでしょうか。

まずテレビは地上波だけではなく、BS放送やCS放送がおこなわれるようになっています。テレビを視ているというと、民放のドラマや歌番組を視ているという意味に受け取られることがありますが、地上波の民放は見ていなくても、BSやCSでCNNやBBCとかドキュメンタリー・チャンネルを視ているかもしれないわけです。

さらに最近では、PCやスマホで動画を視るのが、一般的になってきています。場合によっては、テレビで放送された作品が動画で視られたりしますから、いうなれば「テレビは視ていない」けど「同じものを（PCやスマホ）の動画で視ている」ことができてしまいます。こうなってしまうと、「テレビを持っていない」としても、「そのような作品を視ることが出来ない」を意味しないのです。

今日においては、「テレビを持っていない」というのは、家電製品としてのテレビを所有していないというだけの意味でしかないでしょう。その発言の背後に「テレビで放送される作品に興味がない」とか「そのような作品をみたことがないし、本を読む（または音楽を聴く）ほうが好きだ」 ということを意味しません。

時代は変化しているのに、言葉が追い付いていない印象を受けます。それを意識したうえで発言するようにしたいと思います。そこを曖昧にしたままにすると「ご飯論法」のようなことも出来てしまいますから、注意しておくに越したことは無いでしょう。

「それ（学んでいる事柄）は何の役にたつ？」にどう答えればよいのか

在籍している放送大学教養学部で2019年4月からは「微分方程式('17)」を受講しています。微分方程式に限らず微積分を学ぶ意義は、一般の大学における理学部数学科であれば数学としての学問の対象でしょうし、また工学部電子工学科などであれば物理現象を記述するための道具に過ぎないのでしょう。放送大学では教養学部なので（教養としての）微分方程式という位置づけなのか否かは不明ですが、理工系学部とは位置づけが異なるのではないかと思います。

さて「微分方程式を学んでいる」と言うと、人によっては「それは何の役に立つのですか？」と訊いてくる場合があります。 もちろん「微分方程式は物理現象の記述に役立つのです」と答えることは可能なのですが、質問の意図はそういうことではないのかもしれません。（聞いてきた人によるので、全員がそうだということではありませんが）率直な言い方をすれば「それを学ぶと、どのくらいオトクなのですか？いくら儲かるのでしょうか？」ということが知りたいのかとも邪推しています。これに対しても「金融工学でも微分方程式は重要で・・・」とか応えてもよいのでしょうけれども、やはりそのような答えを求めている訳ではないのでしょう。

通俗的に「大学の勉強は（世間の）役に立たない」と主張されることがあります。経済団体などが「大学ではもっと社会に出て役に立つことを教えるべきだ」と主張していると報道されることもあります。さらに大学に限らず、高校や中学の現場でも「こんなことをして、何の役に立つんですか」と生徒から（場合によっては親からも）疑問を投げかけられているようです。

それでは「役に立つ学問」とは何でしょうか。数の計算（加減乗除や九九）とか、文字の読み書きは、どんな生き方をする場合でも必要でしょう。しかしそれ以外の科目は、はっきり言えば、それがわからなくても生きていくのに困るような事態には、それほどならないと思います。そのような話題についていけなくなるという「困難さ」は存在すると思いますが、それは「生きていくのに困るような」（直接的な）事態ではないと思います。

逆説的な言い方になりますが、「それは何の役に立つ」のかという疑問に答えるには、「それ」を学んでみないことには答えられないだろうと思います。もしくは理解できないだろうと思います。「役に立つか（否か）」を知ってから学ぶのではなく、まずは「それ」を学ぶのが先だろうと思います。

そうなると、先に学び始める訳ですから、「学んでみたけど、無駄だった」という意見が出る可能性はあるでしょう。 個人の判断のもとに、そのような結論を出すのは仕方ないだろうと思います。しかしながら、「無駄だった」よりも「無駄にしないような方向性を見つけていく」という境地に達することが出来る可能性を残しておくのも、悪くないかもしれません。そういう意味において、放送大学という教育機関に教養学部というものがあるのは、悪くないんじゃないかと感じています。

「Keep reading.」の和訳は？

The Japan Times Alphaの2019年5月3日号に掲載された「Odds & Ends」は、テーマ「Common mistakes」の第1回「You」でした。今月のテーマが「Common mistakes」ですから、「You」に関する日本人によくある間違いを正そうというのが、このエッセイの目的ではありますが、それとは違う点に着目してみたいと思います。それは「Keep reading.」です。

エッセイの中で「Keep reading.」が出てくるのは、意図するところは理解できます。要するに「大切なポイントが、この後に書かれているから、読むのを止めないで、続きを読んでね」ということでしょう。それはわかるのですが、日本語にぴったりした表現が思いつきません。どのように和訳したらピタッとはまるでしょうか。

「Keep reading.」を「先を読んでください」とか「読み進めて下さい」、「読み続けてください」などとすると、直訳っぽい感じがします。それでは駄目だということではないのですが、もう少し意図を汲んだ訳はないものでしょうか。

ちなみに、このエッセイ「Odds & Ends」では、話題がそれた時に「back to the topic」として、本来の話題に戻ってきます。この場合であれば、直訳的に「話題に戻ると」とか、意訳して「閑話休題」とできるのです。

同じようなことが「keep reading」でも何かないかと思って、探しているのです。

Wolfram Alphaで検算

以前から在籍している放送大学教養学部で、今期は「微分方程式('17)」を受講しています。ちょうど一年前は「入門微分積分('16)」を受講しており、あまり理解できたとも言えないレベルですが、残念ながら（？）単位を取得してしまいました。受講中の科目は、去年の講義を理解していることを前提として話が進む（ときおり復習的な話もありますが）ので、去年の印刷教材も読み直したり、Webで見つけた問題集を解いてみたりして、派生的な勉強もするようにしています。

いま受講中の印刷教材も、ただ読み流すだけでなく、式の導出や展開なども、自分でノートに書いてみるようにしています。あやふやな理解なままでは、印刷教材を読んでみると分かった気になっても、ノートに自分で書いてみると、理解できているところと、分かっていないところが、明らかになるので、とても勉強になります。手間はかかりますが。

自己学習するときに問題になるのが、自分でやってみた式の展開が間違っているのか、途中経過なら出来ているのか、どのようにして確かめれば良いのかということです。そこで利用しているのが「Wolfram Alpha」というWebサイトです。

有料会員として登録しなくても、十分に役に立ちます。微積分や微分方程式の計算をしてくれるので、自分の理解を深めるために活用しています。式の展開の途中経過や、部分的な微積分を確認することで、自分でやった計算の何が悪かったのか気付くことができます。

微積分に限らず数学は正誤がはっきりしているので、Wolfram Alphaのようなツールがあると、学習にとても役立つと思います。これに対して、語学のような分野では（例えば英作文）正解がひとつに決まらないので、自分の解答が間違っているのか、バリエーションとしてはあり得るのか、判断に困ることが多いのです。

FreeBSDでUSBシリアル変換アダプタを使う

（牛の箱で有名な）GatewayのノートPCでFreeBSD/i386を使っていましたが、ThinkPad E530cを使ってFreeBSD/amd64に移行しました。日々利用している最低限の機能は使えるようにしておきましたが、それ以外にも利用していた機能があります。そのひとつがシリアルポートです。

GatewayのノートPCは1990年代の製品なので、9ピンのRS-232Cポートが標準装備されています。このポートを利用してDEC製ワークステーションのシリアルコンソールとしてFreeBSDを使っていました。このためシリアルポートが今後も必要なのですが、残念ながらThinkPad E530cには（そういう旧式なインターフェイスは）装備されていません。今どきなのでUSBオンリーです。

既に販売終了された製品ですがcoregaのCG-USBRS232Rを持っていますので使用してみることにしました。結論から言うと、何の問題もなく、何の設定追加も必要とせず、利用することが出来ました。

まずUSBに挿すと、認識結果がコンソールに出ます。このときに/var/log/messagesには次のような記録が残っています。

May 10 07:24:23 tpe530c kernel: ugen0.2: <Prolific Technology Inc. USB-Serial Controller D> at usbus0
May 10 07:24:23 tpe530c kernel: uplcom0 on uhub2
May 10 07:24:23 tpe530c kernel: uplcom0: <Prolific Technology Inc. USB-Serial Controller D, class 0/0, rev 1.10/3.00, addr 1> on usbus0

そしてコマンド「tip ucom1」でシリアルポートに繋がったDEC製ワークステーションpw500auを操作することが出来ました。ここにはOpenVMS alphaが入っているので、ブートしてログインできるところまで確認しました（もちろんシャットダウンも大丈夫です）。

FreeBSD12の標準構成にはrshがない

もう20年近くも動かしてきたFreeBSD/i386から、ThinkPad e530cによるFreeBSD/amd64に移行しました。日々利用しているメール等の環境は問題なさそうなことを確認しましたが、これまで利用してきたのと同様の環境となるように、今後も設定をしていかなければなりません。

従来はWindows10の環境からrshによりFreeBSD/i386のコマンドを起動させて、諸々の作業をしていました。FreeBSD/i386側のコマンドというのはplatexやR、Maximaなどです。ちなみにWindows側で使っているrshは、以下のようなものです。

RSH for Windows (c)2010,2011 Bryan Chafy. Licensed under the GPL.

同じことをFreeBSD/amd64でもやろうと思っているので、動作を確認してみたところ、動きませんでした。調べてみると、FreeBSDでは標準構成からrshが無くなっていることを知りました（FreeBSD 12 から rsh が消える ので net/bsdrcmds）。

標準構成からは消えてもパッケージから入れれば済むのであれば、それでも構いません。入れてみて試すと、やはり動いてくれません。何かリモートログイン時にセキュリティ絡みの問題があるようなメッセージが出てきます。

そもそもFreeBSD12でrshが消えたのは、セキュリティを考えると推奨できないからだと思われます。rshよりもsshを利用すべきなのでしょう。しかしsshだと、リモートコマンドをキックするために、パスフレーズを入力する必要が出てくるのが、気に入らないところです。

Webで調べると、パスフレーズを入れない鍵を使えばよいという回避策が氾濫していますが、それも気が進みません。既にパスフレーズを持った鍵を作って利用しているので、それとの兼ね合いが気になります。また「ssh/ホストベース認証」という方法もあるようです。今回は採用を見送りましたが、この方法ならスマートかもしれません。

何が問題なのか、/var/logにある情報を見ても糸口がありません。困りましたが、ふと閃いたのが/etc/pam.d/rshの存在です。旧いバージョンのFreeBSDではrshが標準構成に含まれていましたから、PAMに関するファイルも存在していました。ところが標準構成から外れ、パッケージbsdrcmdsから入れることが出来るようになっても、/etc/pam.d/rshが復活しないのです。

安易かもしれませんが、FreeBSD10の/etc/pam.d/rshを所定のディレクトリにコピーしてみたところ、無事にrshでリモートコマンドが実行されました。

C:\Users\FURUSAWA>rsh tpe530c -l furusawa "env LANG=C date"
Tue May  7 15:33:19 JST 2019

これで一安心です。

「七人の侍」時代の風景

2019年3月21日にNHK BSプレミアムで黒澤監督の「七人の侍」が放送されました。録画しておいたのですが、4時間弱もある長い作品ですし、余裕がなかったので、視る機会がありませんでした。この連休中にようやく視ることができました。過去に一度見た記憶があるのですが、あまりよく覚えていないので、初めて見たのとほぼ同じです。

作品の時代設定は戦国末期（1586年）ですが、時代考証をしているとは言っても、描かれている風景がその当時の様子を正確に再現しているのかどうかは、実際のところよくわかりません。この作品が公開されたのは昭和29年ですから、江戸時代末期くらいの風景ならば残っていたかもしれません。しかしさすがに中世末期の風景は残っていないでしょう。中世末期から近世の頃は、今日にくらべれば時代の変化が少ないと思われるため、江戸時代末期でも戦国時代末期でも、農村や宿場町の風景はたいして違いは無いのかもしれませんが、正確に言えば、同じというわけでもないでしょう。

作品の初めで、志村喬が演じる島田勘兵衛が宿場町を歩いていく周囲の風景は、破れた塀や、瓦屋根や板葺き・茅葺きの建物が並び、過去の日本の風景を彷彿とさせます。作品の中心となる農村の様子はセットを組んだようですが、それ以外のシーンでもセットを組んでいるのか、それらしい場所を探してロケをしたのか、よくわかりません。しかし21世紀の今日では見ることができなくなった、昔の日本の姿があり、とても心を惹かれます。

radikoガジェットが復旧した

2019年4月上旬にAdobe Airが更新され、radikoガジェットから音が出なくなりました。この件については、radikoから以下のようなアナウンスが出ており、4月下旬のAdobe Airの更新で復旧したようです。

• radikoガジェットのご利用について（2019年4月11日）
• radikoガジェットのご利用について（2019年4月26日）

復旧したとの情報を得て、Adobe Airを更新してみました（radikoガジェットを起動して放置しておくと、Adobe Airが新しくなっていれば、更新を促されます）。無事に音が出るようになり、ほっとしました。

3-minute Reading With Kip: Family name problems: Fathers and sons

the japan times alphaの2019年5月3日号に掲載されていた「3-minute Reading With Kip」（Kip Cates）のタイトルは「Family name problems: Fathers and sons」でした。アメリカの小説や映画などで、「生まれた子供に父親と同じ名前をつけた」というような描写がされることがあります。あまり深く考えずに流してしまうと、そういうものかと思ってしまいますが、よく考えると不思議です。この文章でも書かれているように「However, this caused all sorts of problems.」となる筈です。

まず第一に、アメリカではファーストネームが重視されますから、同じファーストネームを持つ人物が家庭の中に二人いれば、電話がかかってきて「（例えば）Bruce, please.」とか言われたら、「Which Bruce do you mean?」となるわけです。

もっとマズイのが「Even worse was when the postman delivered the mail.」です。郵便の場合には、聞き返すことができないので、「If it was a love letter from my brother's girlfriend and I gave it to my father, 」とかなると悲惨です。

日本人の名前にはありませんが、外国人の名前にはミドルネームを持っている場合があり、上述したような場合に役立つのかもしれません。ミドルネームでなくても、何か区別できる社会システムがきっとあるのでしょう。そうでなければ、危なくて、同じ名前をつける風習はとっくの昔に廃れているはずです。

日本人の名付けにおいて、父親と全く同じ名前を子供にもつけることは無いと思いますが、名前の漢字の一部を使うことは多いかもしれません。時代をさかのぼると、一族の結束を強めるために「通字」 もありました。近世の徳川家では「家」を使う諱が多いとか、源氏の血筋を引く武家では「義」を使うことが多いとかです。

名付け方にも時代の流行があり、今日では「～衛門」とか「～兵衛」という名前は、まずないでしょう（もし子供にそのような名前をつけたら、一生恨まれるのではないでしょうか）。 「輩行名」（一郎、二郎、三郎のような名前）も少なくなっているかもしれません。その代わりに増えつつあるとおもわれるのが、俗にいう「キラキラネーム」のように、音を重視して、（見た目を重視した）漢字をあてはめた、万葉仮名かと思うような名前です。それが多数派を形成しているとまでは考えていませんが、今後は多数派となる可能性があるとは思っています。

Working Across Cultures:Lesson 21: How to prepare for business negotiations overseas

the japan times alphaで連載されている「異文化コミュニケーション講座」（Matthias Kaemper）の2019年5月3日号のタイトルは「Lesson 21: How to prepare for business negotiations overseas」でした。異文化の取引先との交渉で気を付けたい3つのポイントについて語っています。その2番目で書かれていたことに注意を惹かれました。そこだけを引用すると、次のように書かれていました。

• Countries like Japan and Germany have a very low tolerance for new and risky things.
• However, in countries like Singapore, Vietnam and the U.S., uncertainties are tolerated quite well.

日本が許容度が低い（良く言えば慎重ということでしょうか）のは、良くも悪くも日本人も重々承知していることだと思いますが、ドイツも同様だとは意外でした。一方で米国が対極にあるのは、こちらもまた良く言われていることです。

日本人が新しいビジネスを興そうとするとき、ややもすると慎重になり過ぎてタイミングを外し、石橋を叩いて渡るどころか、石橋を叩き壊してしまうと、揶揄されるところです。

その反動なのか、（アメリカみたいに）できるかどうか分からない段階でも始めてみれば良いんだよ、と言い出す人もいます。それはそうなのかもしれません。しかし「できるかどうか分からない段階」で始めてみるわけですから、「できない」かもしれないわけです。 できなくても仕方ないはずですが、なぜか非難を浴びたりするのは、なぜでしょう。「もっと、ちゃんと良く考えるべきなんだよ」とか言われたりすると、なんだか話が違うんじゃないかと思ってしまいます。

上述したのは、何か具体的な事例がある訳ではなくフィクションではありますが、意外と実例が見つかったりします。最初の発言と最後の発言が、同一人物だったりすると、もう勘弁してくれと言うところです。

「TCPは以下の方法で信頼性を保証する。」

『詳解TCP/IP Vol.1 プロトコル』（新装版第1刷、2000年、ピアソンエデュケーション）の「第17章 TCP:トランスミッション・コントロール・プロトコル」の256頁に「TCPは以下の方法で信頼性を保証する。」と書かれています。その後に、「信頼性を保証する」ための具体的な内容が列挙されていますが、ここで書こうとしているのは、そこではありません。

何時からなのか不明確ですが、「担保する」 という言葉が多用されていると感じています。同じ感覚を持つ人もいるようで、Webで次のような情報が見つかります。

• インターネットを利用して「担保する」を解く 
• 「担保する」とはどういう意味？ 

1番目の情報は大阪教育大学の「学大国文」第45号（2002年）に掲載されたものを著者自身でHTMLにして公開しているものです。2番目の情報は2007年2月2日です。違和感がもたれるようになって、もう20年くらいになるようです。

「担保する」という言い方が21世紀になって登場した新語とは考えていません。法律関係では以前から使われていた言い方だという情報を得たことがあります。また「担保する」という言い方しか考えられないような状況で使われるなら、それは問題ではありません。

気になって仕方がないのは、他の言い方（例えば「保証する」など）があり、そちらの方が適切と思われるのに、なぜか「担保する」が使われる場合です。冒頭にあげた例を使うと、今日の流行にのれば「TCPは以下の方法で 信頼性を担保する。」と書かれるところでしょう。

手持ちの辞書『明鏡国語辞典 携帯版』（初版第3刷、2005年）では、次のようになっています。

• たん-ぽ【担保】〔名〕債務者が債務を履行しない場合、その債務を弁済を確保する手段として債権者にあらかじめ提供しておくもの。
• ほ-しょう【保証】〔名・他サ変〕(1)確かであると請け合うこと。

この辞書は携帯用なので、大辞典のように詳しい記述がありません。その代わり、主として用いられる語義が掲載されていることが期待できます。そこで語義を見ていくと、「保証」の方はサ変（「保証する」のように使われる）も考慮されていますが、「担保」は単なる名詞です。日本語では大多数の名詞はサ変動詞になるので、そういう意味では「担保する」もアリなのでしょうが、辞書ではサ変は考慮に入っていません。

「担保する」という言い方が気になるのは、用語の厳選という意味での推敲が不十分ではないかと感じられるからです。「担保する」という言い方が何故にこれほど広まってきているのか分かりませんが、この言い方をすると「なんだかよくわからないけど、難しそうな言い方で、カッコ良さそう」と思われているのではないかと、邪推しています。文脈によっては、「保証する」とか「確保する」の方が適切かもしれないのに、なんでもかんでも安易に「担保する」で済ませてしまっているのではないかという、疑いを持ちます。

この問題は、いつの時代も世の中を騒がせている「日本語の誤用」とはまた違う問題ではないかと思います。「担保する」は不適切かもしれませんが、少なくとも「誤用」とまでは言えないと思います。問題は、いかなる経緯で「担保する」が広まってしまったのか、ということです。誰かが「『担保する』を使おう運動」の旗を振っているということでもないでしょうから、些細な事例ではありますが、社会の変化を考えるための重要な素材なのかもしれません。

FreeBSDのpkgに付属するperiodicスクリプト

1990年代のノートPCでFreeBSD/i386を利用しています。もう十何年も24x365の連続運転中ですが、高性能なCPUが必要になる処理はおこなっていないので、それほど困ってはいません。ただしハードウェア（特にネットワークI/F）が不調になってきており、またFreeBSDそのものがSSE2をサポートしていないCPUに対応しなくなっているようなので、そろそろ新しいマシンに交換しようと思っています。そう思い始めたのは数年前で、代替マシンとしてジャンクのThinkPad Edge E530cを入手しました。それも2年位前のことになり、スマートな移行手順を検討していました。いつまでも放置していても仕方ないので、最近になって本腰をいれることにしました。

FreeBSD/amd64は導入済みです。当初は11.0でしたが、放置しているうちに12.0が出てしまったので、バージョンアップも済んでいます。

FreeBSD/i386は日常的に使用しているマシンなので、同程度の作業ができないの差し障りがあります。最低限必要なものはpkgなどで導入しました。TeXを使っており、ちょうど2019年5月1日よりTeXlive 2019が公開されたので、近いうちに導入しようと思います。

FreeBSD/i386の頃は利用するアプリケーションをportsを使ってソースから作っていましたが、FreeBSD/amd64ではpkgでバイナリを入れるだけにしようと思います。ソースから作ればオプションを自由に変更できて、それは便利なのですが、ほとんどのアプリケーションはデフォルトのオプションを使っているだけなので、ソースから作る意義はありませんでした。

FreeBSDではpkg（移行期にはpkgngと呼ばれていたようです）が使われています。/usr/sbin/pkgの他に/usr/local/sbin/pkgもあるのが謎です。それはともかく、pkgに付属するperiodicスクリプトがあるようです。

# pkg info -l pkg | grep periodic
        /usr/local/etc/periodic/daily/411.pkg-backup
        /usr/local/etc/periodic/daily/490.status-pkg-changes
        /usr/local/etc/periodic/security/410.pkg-audit
        /usr/local/etc/periodic/security/460.pkg-checksum
        /usr/local/etc/periodic/weekly/400.status-pkg

periodicスクリプトは、挙動を変えるための設定を/etc/periodic.conf.localなどでおこなえますが、どのような設定があって、どのように変えればよいのか、説明する文書がみあたりません。所詮はシェルスクリプトなので、中を覗けばよいということなのかもしれません。

ひとつひとつのスクリプトは、それほど長くもないので、備忘のために調べてみました。全てのスクリプトがjailやchrootのための対処がされています。またpkgngの頃の設定があれば活かすようになっている箇所もありますが、全てそうなっている訳でもありませんでした。

1. /usr/local/etc/periodic/daily/411.pkg-backup
   pkgの情報をバックアップする。指定された世代分を、指定されたディレクトリに残す。
   
   1. daily_backup_pkg_enable
   2. daily_backup_pkg_dir
   3. daily_backup_pkg_count
   4. daily_backup_pkg_chroots
   5. daily_backup_pkg_jails
2. /usr/local/etc/periodic/daily/490.status-pkg-changes
   pkg infoにより、前回実行時の結果との差分を出力する。
   
   1. daily_status_pkg_changes_enable
   2. daily_status_pkg_changes_chroots
   3. daily_status_pkg_changes_jails
3. /usr/local/etc/periodic/weekly/400.status-pkg
   pkg versionを実行する。
   
   1. weekly_status_pkg_enable
   2. weekly_status_pkg_chroots
   3. weekly_status_pkg_jails
4. /usr/local/etc/periodic/security/410.pkg-audit
   pkg auditを実行する。
   
   1. daily_status_security_pkgaudit_enable
   2. daily_status_security_pkgaudit_expiry
   3. daily_status_security_pkgaudit_quiet
   4. daily_status_security_pkgaudit_chroots
   5. daily_status_security_pkgaudit_jails
5. /usr/local/etc/periodic/security/460.pkg-checksum
   pkg check -qsaを実行する。
   
   1. daily_status_security_pkg_checksum_enable
   2. daily_status_security_pkg_checksum_chroots
   3. daily_status_security_pkg_checksum_jails

「渋滞」と「グリーン車」

木曜日の夜にNHKが放送している「ネーミングバラエティー 日本人のおなまえっ！」では、2019年4月25日放送で「渋滞」や「グリーン車」の名付けにまつわる話題を取り上げていました。番組を見終えてから気がついたのですが、両者は正反対ともいえる特徴があるのではないでしょうか。

「渋滞」という言葉の本来の意味には、今日使われているような「道路の混雑」という意味合いは全くなかったと、番組中で紹介していました。当時の警察内部に限定された用語に過ぎなかったものが、ラジオ局のアナウンサが使用したことで、一般に流通するようになったようです。しかし当初は、他局のアナウンサからは非難もあり、一般に通用されていない警察内部の用語を使うとは一体どういうつもりなのかと反発があったとも放送していました。

「グリーン車」という言葉は、明治以来続いていた座席の等級制を廃したものの、グレードの違いを区別するために名付けられたと、番組中では紹介していました。当時の国鉄内部では特別車と呼んでおり、外向きには「グリーン車」と呼んでいても、国鉄内部では「特別車」とされ続けていたようです。番組中では、グリーンという言葉の持つイメージに焦点をあてていて、国鉄内部と外部で用語を使い分けていたことには、それほど注目されていませんでした。

一方では警察内部用語を一般向けに使用し（当初反発されたものの）広く流通するようになり、他方では国鉄内部用語を一般向けには使用せず（内部では使い続けたものの）外向けの用語を別に用意するという、まったく正反対の経緯を辿っていたことに、当たり前のように使っている言葉には様々な歴史があることを感じました。