2020年1月号「日経Linux」の別冊付録は「Linuxカーネルが基礎からわかる本」です。OSのカーネルというものを題材にした雑誌記事や書籍は、人気のあるテーマのようです。この別冊付録で「本当に」カーネルが基礎からわかるのか、という疑問はおいておきます。
Linuxを扱うためにカーネルの知識が必要なのかという質問に対しては、あればあったで構わないが、必須ではない、という回答になるのではないでしょうか。Linuxに限らずOSS（Open Source Software）の世界では、不具合があったらソースを見れば問題を解決できると言われる事があります。それはそうなのかもしれませんが、そんなに簡単な話でもない気がします。
一方で、カーネルなど内部構造について知的好奇心を持つこと自体は、悪くないと考えています。その道のりは険しいかもしれませんが、挑戦してみることは良いことだと思います。
しかしカーネルばかり脚光を浴びているのは、なんとかして欲しいとも感じています。昔々のコマンドラインの時代ならいざ知らず、今はGUIが当たり前の時代になっています。CHUIの時代であれば、内部構造を知りたければカーネルに手を出せばよかったのでしょう。
GUIの時代ともなると、多様なデスクトップ環境が使われているため、基盤として「freedesktop.org」が使われています。ユーザが直接目に触れるKDEであるとかGNOMEの奥には、freedesktop.orgの機能が使われていて、これはこれで複雑に絡み合っています。そこを分かりやすく全体像を捉える情報を求めているのですが、なかなか巡り合えません。個別的な情報はWebにありますが、えてして木を見て森を見ずという状態になってしまいがちです。
カーネルの話題が頻繁に雑誌記事になるのに比べると、freedesktop.orgの話題が雑誌で特集されているのは、まず見たことがありません。
2019-12-30
2020年1月号の日経Linux（Win7→Ubuntu）
普段は購入しないのですが、「日経Linux」（2020年1月号）を買ってみました。別冊付録「Linuxカーネルが基礎からわかる本」に興味があったからです。
本誌の特集は「サポ切れWin7→Linux引っ越し完全手順」です。2020年1月14日にWindows7のサポートが終了することはマイクロソフトからのアナウンスがあるとおりです。しかしサポートが切れるか否かに関わらず、Windowsが入っていたPCをLinuxに入れ換えることを勧める記事は、よく見かけます。
記事では、以降の流れを次のように説明しています（22頁）。
考えてみたいことは、WindowsからLinuxに移行した人（および移行しようと考えている人）は、Linuxに何を求めているのかということです。Windows7はマイクロソフトの商品（だから有料）だが、Linuxはフリー（なので無料）だから、オトクに使える、と思っているだけなのでしょうか。
例えば乗用車は、 トヨタでも日産でも、はたまたホンダでもマツダでも、操作は同じだから、パソコンだってWindowsだろうがLinuxだろうが同じだろう、くらいに考えていないでしょうか。微妙に違うところはあっても、基本的に同じだろうと考えていないでしょうか。
問題となるのは、どの程度の違いであれば許容できるのか、という点だと思います。
一例として、オフィス製品としてMicrosoft Officeの代替としてLibreOfficeが候補にあがります。見た目は似ていますし、操作も似ています。しかし全く同じかというと、そうではないし、全然違うのかというと、そうでもありません。僕自身はMicrosoft Officeを使うのを止め、10年位前からLibreOfficeを使っており、特に不便は感じていません。ただし、Microsoft Officeと同じように使えることを「期待」してLibreOfficeを使うのであれば、「期待外れ」になるだろうとは考えています。LibreOfficeはMicrosoft Officeと互換性のある機能「も」ありますが、基本的には別の操作性を持ったオフィス製品です。
WindowsからLinuxへ移行することは否定しませんが、移行するなら、このような「違い」についても意識しておく必要があるだろうと思います。
本誌の特集は「サポ切れWin7→Linux引っ越し完全手順」です。2020年1月14日にWindows7のサポートが終了することはマイクロソフトからのアナウンスがあるとおりです。しかしサポートが切れるか否かに関わらず、Windowsが入っていたPCをLinuxに入れ換えることを勧める記事は、よく見かけます。
記事では、以降の流れを次のように説明しています（22頁）。
- まずはUbuntuの捜査官を確認
- PCにUbuntuをインストールする
- データを外部に退避して復元
- Office文書の引っ越し先を準備
- Windowsの定番アプリを代替する
- Linux独特の操作の作法を知る
- Windowsの便利機能を代替する
考えてみたいことは、WindowsからLinuxに移行した人（および移行しようと考えている人）は、Linuxに何を求めているのかということです。Windows7はマイクロソフトの商品（だから有料）だが、Linuxはフリー（なので無料）だから、オトクに使える、と思っているだけなのでしょうか。
例えば乗用車は、 トヨタでも日産でも、はたまたホンダでもマツダでも、操作は同じだから、パソコンだってWindowsだろうがLinuxだろうが同じだろう、くらいに考えていないでしょうか。微妙に違うところはあっても、基本的に同じだろうと考えていないでしょうか。
問題となるのは、どの程度の違いであれば許容できるのか、という点だと思います。
一例として、オフィス製品としてMicrosoft Officeの代替としてLibreOfficeが候補にあがります。見た目は似ていますし、操作も似ています。しかし全く同じかというと、そうではないし、全然違うのかというと、そうでもありません。僕自身はMicrosoft Officeを使うのを止め、10年位前からLibreOfficeを使っており、特に不便は感じていません。ただし、Microsoft Officeと同じように使えることを「期待」してLibreOfficeを使うのであれば、「期待外れ」になるだろうとは考えています。LibreOfficeはMicrosoft Officeと互換性のある機能「も」ありますが、基本的には別の操作性を持ったオフィス製品です。
WindowsからLinuxへ移行することは否定しませんが、移行するなら、このような「違い」についても意識しておく必要があるだろうと思います。
2019-12-23
元旦と氷点下
2019年も残りわずかになってきました。今日は12月23日なのでクリスマス前です。しかしクリスマスを過ぎると世間は一気に正月モードに入ることでしょう。
考えみれば、12月31日と1月1日の違いは、それ以外の日の日付が変わるのと違いがある訳ではありません。元旦が特別な「気がする」のは、多分に心の持ちようでしょう。
さて、日本では気温を摂氏「℃」で表しますが、アメリカでは華氏「℉」を使います。この変換式はF=32+(9/5)Cです。よって0℃は32℉ということになります。
日本のように気温を摂氏を使うと、「明け方の気温が氷点下（0度以下）になる」ということが、何か特別な状態に入るような気持ちになりがちかもしれませんが、気持ちの問題ではないでしょうか。確かに氷点下になるかならないかで、霜が降りるとか、水面に氷が張るなど、気象現象の違いがあるかもしれません。しかし気象台で観測した気温と、身の回りの気温は微妙に違うので、「氷点下」かどうかということに、必要以上に意識する必要もないことかと思います。
気温以外にも、長さや重さの測定単位が異なることがあります。さらに年齢の数え方も、満年齢の他に数え年というものもあります。いずれのスケールであっても、何か切りのよいところの前後で、特別な状態になると思いがちですが、心理的なものだと思います。
考えみれば、12月31日と1月1日の違いは、それ以外の日の日付が変わるのと違いがある訳ではありません。元旦が特別な「気がする」のは、多分に心の持ちようでしょう。
さて、日本では気温を摂氏「℃」で表しますが、アメリカでは華氏「℉」を使います。この変換式はF=32+(9/5)Cです。よって0℃は32℉ということになります。
日本のように気温を摂氏を使うと、「明け方の気温が氷点下（0度以下）になる」ということが、何か特別な状態に入るような気持ちになりがちかもしれませんが、気持ちの問題ではないでしょうか。確かに氷点下になるかならないかで、霜が降りるとか、水面に氷が張るなど、気象現象の違いがあるかもしれません。しかし気象台で観測した気温と、身の回りの気温は微妙に違うので、「氷点下」かどうかということに、必要以上に意識する必要もないことかと思います。
気温以外にも、長さや重さの測定単位が異なることがあります。さらに年齢の数え方も、満年齢の他に数え年というものもあります。いずれのスケールであっても、何か切りのよいところの前後で、特別な状態になると思いがちですが、心理的なものだと思います。
2019-12-22
京都国立博物館特別展「流転100年 佐竹本三十六歌仙絵と王朝の美」の図録
京都国立博物館で2019年10月12日から11月24日まで特別展「流転100年 佐竹本三十六歌仙絵と王朝の美」が催されていました。これが開催されるのを知ったのは2018年秋頃でしたが、楽しみにしていたので、時間を見つけて行ってきました。博物館や美術館に行くと、記念に図録を買うのですが、今回は終了する数日前だったので、図録の在庫が切れていました。予約を受け付けていて、12月になったら発送するとのことで、前金を支払い、発送伝票を書いてきました。
この特別展の図録は好評だったようで、京都国立博物館は販売終了をアナウンスしています（【通信販売終了】特別展図録「流転100年 佐竹本三十六歌仙絵と王朝の美」通信販売のお知らせ）。2019年12月25日まで受け付ける予定が、12月9日時点で受付を終了していますし、申し込み時期によっては発送が2020年2月頃になるとも書かれています。
12月になったら送られてくる筈の図録が待てど暮らせど到着せず、これでは来年になってしまうのかと、気を揉んでいました。それが本日（2019年12月22日）の夕方になって、宅配便で到着しました。ちょっと早いクリスマスプレゼントという感じです。
この特別展の図録は好評だったようで、京都国立博物館は販売終了をアナウンスしています（【通信販売終了】特別展図録「流転100年 佐竹本三十六歌仙絵と王朝の美」通信販売のお知らせ）。2019年12月25日まで受け付ける予定が、12月9日時点で受付を終了していますし、申し込み時期によっては発送が2020年2月頃になるとも書かれています。
12月になったら送られてくる筈の図録が待てど暮らせど到着せず、これでは来年になってしまうのかと、気を揉んでいました。それが本日（2019年12月22日）の夕方になって、宅配便で到着しました。ちょっと早いクリスマスプレゼントという感じです。
2019-12-21
Beverly A. Jackson「Colorado rumble」the Japan Times Alpha, Dec. 20, 2019
the Japan Times Alphaの2019年12月20日号に掲載されたコラム「Colorado rumble」（Beverly A. Jakson）によると、著者はコロラド州フォートコリンズに住んでいるそうです。そのコラムで次のような記述があります。
インターネットが普及する以前であれば、このような見知らぬ外国については想像をめぐらすしかありませんでした。運が良ければ、海外旅行で現地を訪れて、その風景と自分が思い描いていたイメージとの違いを愉しんだことでしょう。
しかしインターネットが普及した今日であれば、Google Mapのストリートビューを使えば、その姿を簡単に見ることができます。有り難いことでもあるし、（現地を訪れるワクワク感を失ったので）残念なことでもあります。
ともかくストリートビューで見てみました。道路の中心に線路があるのは、日本でも見かける路面電車のようでもあります。 ストリートビューでは列車が走行している姿は写っていませんが、Googleで検索すれば、走行している様子の写真を見ることも出来ます。
アメリカらしい大型の機関車（しかも三重連）が長大な貨物を引っ張っています。日本の路面電車のイメージの光景に、このような長大な貨物列車が走ってきたら、さぞ驚くでしょう。地元の人達にとっては見慣れた光景かもしれませんが、著者が驚いたように、現地を知らずに訪れたアメリカ人だって驚ろくに違いありません。
ユーチューブで動画を視ることもできますが、何時の日か現地を訪れて、この目で見たいと思います。その迫力は、きっとユーチューブでみるよりも、素晴らしい体験であることでしょう。
I noticed there were railroad tracks running down the middle of Mason Street.コラムにあるイラストでも、いかにもアメリカという感じの列車が描かれています。
インターネットが普及する以前であれば、このような見知らぬ外国については想像をめぐらすしかありませんでした。運が良ければ、海外旅行で現地を訪れて、その風景と自分が思い描いていたイメージとの違いを愉しんだことでしょう。
しかしインターネットが普及した今日であれば、Google Mapのストリートビューを使えば、その姿を簡単に見ることができます。有り難いことでもあるし、（現地を訪れるワクワク感を失ったので）残念なことでもあります。
ともかくストリートビューで見てみました。道路の中心に線路があるのは、日本でも見かける路面電車のようでもあります。 ストリートビューでは列車が走行している姿は写っていませんが、Googleで検索すれば、走行している様子の写真を見ることも出来ます。
アメリカらしい大型の機関車（しかも三重連）が長大な貨物を引っ張っています。日本の路面電車のイメージの光景に、このような長大な貨物列車が走ってきたら、さぞ驚くでしょう。地元の人達にとっては見慣れた光景かもしれませんが、著者が驚いたように、現地を知らずに訪れたアメリカ人だって驚ろくに違いありません。
ユーチューブで動画を視ることもできますが、何時の日か現地を訪れて、この目で見たいと思います。その迫力は、きっとユーチューブでみるよりも、素晴らしい体験であることでしょう。
2019-12-20
「2019年度 NHK英語テキスト購読マラソン」に当選
NHK出版から自宅に覚えのない荷物が届きました。なんだろうと思ったら「2019年度 購読マラソンプレゼント在中」とあり、9月頃に応募した「2019年度 NHK英語テキスト購読マラソン」に当選したようです。まさか当選するとは思わなかったので驚きましたが、思いがけないクリスマスプレゼントとなった気がして嬉しく思います。
最も応募したのは「I賞 英語の本」（200名）だったので、当選しやすかったかもしれません。それでも、どのくらいの応募があったのかわかりませんが、抽選倍率は高かったとは思います。
数年前からNHKラジオで語学講座を聴いています。当初は「ラジオ英会話」でした。ところが2年ほど前に講師が変わってしまいました。半年ほどは「ラジオ英会話」を聴き続けていましたが、自分には合わない感じがしたので、「遠山顕の英会話楽習」に移りました。
このようなプレゼント企画は、応募しなければ当選しないのは当然ですが、なかなか当選することはありません。もしかして本当に当選者がいるのだろうか、と思うこともあります。少なくとも当選することはある（確率は低いかもしれないが） ことが分かりました。
最も応募したのは「I賞 英語の本」（200名）だったので、当選しやすかったかもしれません。それでも、どのくらいの応募があったのかわかりませんが、抽選倍率は高かったとは思います。
数年前からNHKラジオで語学講座を聴いています。当初は「ラジオ英会話」でした。ところが2年ほど前に講師が変わってしまいました。半年ほどは「ラジオ英会話」を聴き続けていましたが、自分には合わない感じがしたので、「遠山顕の英会話楽習」に移りました。
このようなプレゼント企画は、応募しなければ当選しないのは当然ですが、なかなか当選することはありません。もしかして本当に当選者がいるのだろうか、と思うこともあります。少なくとも当選することはある（確率は低いかもしれないが） ことが分かりました。
2019-12-18
漢文風プログラミング言語「文言（wenyan-lang）」
Web上で「漢文風のプログラミング言語「文言（wenyan-lang）」がめっちゃエモいと話題に」という情報を見つけました。
GitHubにあるプロジェクトページに詳しい情報があります。漢文でプログラムを組むという発想は、よくある発想（日本語プログラミング言語というものもありますし）のように思えますが、よく考えられているように思えます。
JavaScriptとの対比表があるので、既存言語との違いがよくわかります。例えばJavaScriptで「var a = 3;」と記述する場合、この言語（文言 wenyan-lang）では「吾有一數。曰三。名之曰「甲」。」となるそうです。この調子でプログラムを組んだら、日本人には正格漢文としか見えないでしょう。
日本語風プログラミング言語には、いろいろあるようですが、例えば「なでしこ」では、「int a = 100;」を「整数a＝100」と記述するようです。あまり捻りもなく、そのまんまという感じですね。
GitHubにあるプロジェクトページに詳しい情報があります。漢文でプログラムを組むという発想は、よくある発想（日本語プログラミング言語というものもありますし）のように思えますが、よく考えられているように思えます。
JavaScriptとの対比表があるので、既存言語との違いがよくわかります。例えばJavaScriptで「var a = 3;」と記述する場合、この言語（文言 wenyan-lang）では「吾有一數。曰三。名之曰「甲」。」となるそうです。この調子でプログラムを組んだら、日本人には正格漢文としか見えないでしょう。
日本語風プログラミング言語には、いろいろあるようですが、例えば「なでしこ」では、「int a = 100;」を「整数a＝100」と記述するようです。あまり捻りもなく、そのまんまという感じですね。
Maxima、xmaxima、wxMaxima
スマホのアプリで「Maxima on Android」を知り、『スマホで数学！』という書籍が出版されていることを知りました。Maxima自体は以前から知っていましたが、それほど使いこなしている訳でもありません。数式処理ではWolframAlphaを使うことの方が多かったのですが、せっかくなので今後はMaximaを使おうかと思っています。
NetBSD/i386にもpackageにMaximaがあるので、インストールしてみました。ベースとなるMaximaは同じものですが、ユーザインタフェースが異なる3種類がインストールできました。
数式が綺麗なwxMaximaを使いたいところですが、なんだか動きが変です。最も肝心な数式を入出力するウィンドウが出ず、外枠やメニューバーばかりが表示されます。メニューは日本語化もされていて、ちゃんと動いてくれれば文句なしなのですが、これでは使いものになりません。デスクトップ環境にMATEを使っているのがマズいのでしょうか。
xmaximaは、wxMaximaのように美しい数式が表示される訳はありません。端末でmaximaを動かしているのと、見かけは変わらない感じです。ただしグラフを表示させようとすると、自動的に別ウィンドウが開くので、便利と言えば便利です。
端末でmaximaを使うよりはxmaximaの方がマシかなと思っているところです。
今回は試していませんが、Emacs上でMaximaを扱うためのimaximaというものがあるようです。Emacsの中で何でもするような使い方をしている人には向いているのかもしれませんが、僕はそうではありません。Emacsは使いますが、viも使うし、Emacsだけで何でもしたい訳ではありません。でも後日imaximaも試してみようと思います。
NetBSD/i386にもpackageにMaximaがあるので、インストールしてみました。ベースとなるMaximaは同じものですが、ユーザインタフェースが異なる3種類がインストールできました。
- 端末で使うシンプルなMaxima
- 端末版MaximaがX上で動くxmaxima
- 数式が綺麗に出るwxMaxima
数式が綺麗なwxMaximaを使いたいところですが、なんだか動きが変です。最も肝心な数式を入出力するウィンドウが出ず、外枠やメニューバーばかりが表示されます。メニューは日本語化もされていて、ちゃんと動いてくれれば文句なしなのですが、これでは使いものになりません。デスクトップ環境にMATEを使っているのがマズいのでしょうか。
xmaximaは、wxMaximaのように美しい数式が表示される訳はありません。端末でmaximaを動かしているのと、見かけは変わらない感じです。ただしグラフを表示させようとすると、自動的に別ウィンドウが開くので、便利と言えば便利です。
端末でmaximaを使うよりはxmaximaの方がマシかなと思っているところです。
今回は試していませんが、Emacs上でMaximaを扱うためのimaximaというものがあるようです。Emacsの中で何でもするような使い方をしている人には向いているのかもしれませんが、僕はそうではありません。Emacsは使いますが、viも使うし、Emacsだけで何でもしたい訳ではありません。でも後日imaximaも試してみようと思います。
2019-12-15
スマホでTiddlyWiki
長年にわたり携帯電話（ガラケー）を使っていましたが、2019年11月に一部サービスを終了するという通知が2018年11月に届きました。いろいろと検討し、2019年10月にスマホ（android）に移行しました。さすがにスマホは便利ですが、どのように使いこなすのかは試行錯誤している最中です。「スマホがあればパソコンは要らない」という人がいますが、僕としては「パソコンがあるので、スマホの必要性は高くない」という気持ちです。
パソコンでは随分前からTiddlyWikiを使っています。現在のTiddlyWikiはHTML5技術を利用しており、TW5と呼ばれています。それ以前をTiddlyWiki Classic（TWC）と対比して呼ばれています。僕はTWCの頃から使っていたので、TW5になって使い勝手が大きく変わり戸惑いましたが、今は慣れています。それでもTWCは今でも一部で利用しています。
TiddlyWikiはHTMLファイルをブラウザで開いて利用するので、Androidスマホでも利用できるのではないかと思い、試してみました。使ってみた感想としては、使えなくはないが、使いやすくはありません。スマホで利用する場合のコツのようなものがあるのかもしれません。
Androidスマホに入っていたブラウザはchromeですが、Android版Firefoxも入れてあります。双方のブラウザでTiddlyWikiを開いてみましたが、使い勝手に差があります。スマホの操作は基本的に指で画面をタッチする訳ですが、Firefoxは反応が悪い気がします。chromeの方が応答は良い気がします。
画面構成は、パソコンなら問題ないのですが、スマホだと（最近のスマホは画面が大きくなったとは言え）画面が小さく、使い勝手が良くありません。
何か情報が無いかとWebを検索してみると、次のような情報がありました。
TiddlyWikiのスマホアプリがGoogle Playから入手できるようですが、TiddlyWikiの公式サイトから入手できるTW5と何が違うのでしょうか。しかも本家のバージョンアップに追従してくれるのか気になりますが、更新が2013年になっているところを見ると、随分旧いようです。
スマホでTW5を何が何でも使いたいという訳ではありませんが、使えるものなら使ってみたいと思います。いろいろと調べてみようと考えています。
パソコンでは随分前からTiddlyWikiを使っています。現在のTiddlyWikiはHTML5技術を利用しており、TW5と呼ばれています。それ以前をTiddlyWiki Classic（TWC）と対比して呼ばれています。僕はTWCの頃から使っていたので、TW5になって使い勝手が大きく変わり戸惑いましたが、今は慣れています。それでもTWCは今でも一部で利用しています。
TiddlyWikiはHTMLファイルをブラウザで開いて利用するので、Androidスマホでも利用できるのではないかと思い、試してみました。使ってみた感想としては、使えなくはないが、使いやすくはありません。スマホで利用する場合のコツのようなものがあるのかもしれません。
Androidスマホに入っていたブラウザはchromeですが、Android版Firefoxも入れてあります。双方のブラウザでTiddlyWikiを開いてみましたが、使い勝手に差があります。スマホの操作は基本的に指で画面をタッチする訳ですが、Firefoxは反応が悪い気がします。chromeの方が応答は良い気がします。
画面構成は、パソコンなら問題ないのですが、スマホだと（最近のスマホは画面が大きくなったとは言え）画面が小さく、使い勝手が良くありません。
何か情報が無いかとWebを検索してみると、次のような情報がありました。
TiddlyWikiのスマホアプリがGoogle Playから入手できるようですが、TiddlyWikiの公式サイトから入手できるTW5と何が違うのでしょうか。しかも本家のバージョンアップに追従してくれるのか気になりますが、更新が2013年になっているところを見ると、随分旧いようです。
スマホでTW5を何が何でも使いたいという訳ではありませんが、使えるものなら使ってみたいと思います。いろいろと調べてみようと考えています。
2019-12-09
MDの今後
MarantzのCD/MDプレーヤが壊れ、MDの今後をどうするか考える必要に迫られてきました。もう長い間MDを利用してきましたが、もうMDの時代でもないでしょう。録音済みのMDが手元にあるので、再生できる環境が必要です。またカーステレオでもMDが使えるようになっているので、録音できる環境も欲しいところです。
MDプレーヤとして次のようなものを所有しています。
MZ-NE810はUSBポートがあり、PCから音楽をダウンロードすることが出来ることになっています。しかし現在のWindows10で動作するのかは確認していません。もしダウンロードができるようであれば助かるのですが、厳しいのではないかと思います（たぶん駄目？）。逆にMZ-NE810からPCにアップロードすることは出来ないハズなので、現在所有している録音済みのMDを吸い上げて、別のメディアに変換する目的には利用できません。
MZ-R50は光デジタル入力ができるので、ONKYO C7030と接続してMDに録音することができるのではないかと思っています（近日中に実験しようと思っています）。MDに録音することができれば、カーステレオで聴くためのMDを作ることができるので、助かります。MZ-R50にはアナログ出力ジャックもあるので、プリメインアンプの外部入力と繋げれば、手持ちのMDを聴くことも出来るでしょう。
MDプレーヤとして次のようなものを所有しています。
- SONY MZ-R50
- SONY MZ-NE810
MZ-NE810はUSBポートがあり、PCから音楽をダウンロードすることが出来ることになっています。しかし現在のWindows10で動作するのかは確認していません。もしダウンロードができるようであれば助かるのですが、厳しいのではないかと思います（たぶん駄目？）。逆にMZ-NE810からPCにアップロードすることは出来ないハズなので、現在所有している録音済みのMDを吸い上げて、別のメディアに変換する目的には利用できません。
MZ-R50は光デジタル入力ができるので、ONKYO C7030と接続してMDに録音することができるのではないかと思っています（近日中に実験しようと思っています）。MDに録音することができれば、カーステレオで聴くためのMDを作ることができるので、助かります。MZ-R50にはアナログ出力ジャックもあるので、プリメインアンプの外部入力と繋げれば、手持ちのMDを聴くことも出来るでしょう。
2019-12-07
ロビン・ウィルソン『四色問題』（茂木健一郎／訳）
ロビン・ウィルソン『四色問題』（茂木健一郎／訳）を図書館で借りて読んでみました。この問題は100年以上も数学者を悩ませていましたが、1970年代にコンピュータを利用して証明されたそうです。「コンピュータを利用して証明された」とはどういうことなのか気になりました。その書籍には具体的なことは、あまり書かれていませんが、関係ありそうな箇所を拾ってみました。
このように当時のコンピュータ環境が窺えます。その計算に長時間を要した（「どんな結果が出るか分からないような状況で1200時間もコンピュータを使用させてくれる研究所など、普通なら考えられない」と239頁に書かれています）ようですが、 それは当時のコンピュータの技術水準での話です。
数学上の難問をコンピュータで証明したというのが、いったいどういう意味なのか掴みかねます。さらに、その計算に何百時間も要しているという事実も、その問題の難しさを語る事情を補強する材料になっていないでしょうか。当時のコンピュータでは何百時間も要したかもしれませんが、今日のコンピュータなら数十分かもしれません（最近話題の量子コンピュータなら一瞬かもしれません）。
- 【213頁】ちなみに、デュレがこのとき利用したコンピュータはハノーファー大学のCDC1604Aで、プログラミング言語はALGOL60だった。
- 【218頁】ハーケンは、ヘーシュとデュレを助けるため、イリノイ大学のILLIAC-IVというパラレルスーパーコンピュータの使用を申請したが、コンピュータは未完成で、使える状態になっていなかった。
- 【220頁】ブルックヘブンでは、デュレは最初にALGOLのプログラムをFORTRANに書き換えなければならなかったが、（後略）
- 【239頁】彼らは、一つの配置をチェックする時間を形式的に制限して、IBM370-158コンピュータでは90分、IBM370-168コンピュータでは30分でチェックを打ち切ることにした。
このように当時のコンピュータ環境が窺えます。その計算に長時間を要した（「どんな結果が出るか分からないような状況で1200時間もコンピュータを使用させてくれる研究所など、普通なら考えられない」と239頁に書かれています）ようですが、 それは当時のコンピュータの技術水準での話です。
数学上の難問をコンピュータで証明したというのが、いったいどういう意味なのか掴みかねます。さらに、その計算に何百時間も要しているという事実も、その問題の難しさを語る事情を補強する材料になっていないでしょうか。当時のコンピュータでは何百時間も要したかもしれませんが、今日のコンピュータなら数十分かもしれません（最近話題の量子コンピュータなら一瞬かもしれません）。
Marantz CM6001が壊れた
自宅で使っているオーディオ機器はMarantzの製品を使っています。オーディオに拘りがあるわけではないので、本格的なオーディオシステムからは程遠いと思います。現在使用しているのは、PM6001（Integrated Amplifier）、ST7001（FM/AM Tuner）、CM6001（CD/MD Combination Deck）です。これらは同時に購入したものですが、購入時期は10年以上前なので既に生産は終了しています。
先日CDを聴いていたら、いきなり異音がして再生ができなくなりました。 そしてCDトレーが開かなくなってしまったので、近所の家電量販店に修理を依頼しました。しかし生産終了していて部品が入手できないということで、修理不能で戻ってきました。
CDが聴けないとオーディオシステムの体をなさないので、別会社のCDプレーヤを購入しました（最近のMarantzの製品はパネルがカーブしていて、並べると違和感があるので、昔ながらのフラットなパネルの製品にしました）。CM6001のCD機能は使えないけどMD機能は活きていると考えていました。
ところがオーディオ機器を結線してみると、CM6001のMDを再生しても音が出ません。結線を間違えたのかと思って、何度も見直しましたが、音が出ません。CM6001の表示部には再生しているトラック番号や演奏時間などの情報が現れているのですが、CM6001のモニタ用ヘッドフォン出力にヘッドフォンを繋いでも音が出ませんでした。
こんな事ってあるんだろうかと思いますが、端的に言うと「壊れた」ようです。故障の現象がCDトレーが出ないという事だったので、機械的な不具合（歯車が割れたとか、ベルトが切れたとか）かと思っていました。しかし生産終了していて製造元ではお手上げ状態ですから、廃棄する前に中を覗いてみようかと思います。昔々と違って、今の電化製品は目視して不良個所が判断できるようなことはないと思います。
先日CDを聴いていたら、いきなり異音がして再生ができなくなりました。 そしてCDトレーが開かなくなってしまったので、近所の家電量販店に修理を依頼しました。しかし生産終了していて部品が入手できないということで、修理不能で戻ってきました。
CDが聴けないとオーディオシステムの体をなさないので、別会社のCDプレーヤを購入しました（最近のMarantzの製品はパネルがカーブしていて、並べると違和感があるので、昔ながらのフラットなパネルの製品にしました）。CM6001のCD機能は使えないけどMD機能は活きていると考えていました。
ところがオーディオ機器を結線してみると、CM6001のMDを再生しても音が出ません。結線を間違えたのかと思って、何度も見直しましたが、音が出ません。CM6001の表示部には再生しているトラック番号や演奏時間などの情報が現れているのですが、CM6001のモニタ用ヘッドフォン出力にヘッドフォンを繋いでも音が出ませんでした。
こんな事ってあるんだろうかと思いますが、端的に言うと「壊れた」ようです。故障の現象がCDトレーが出ないという事だったので、機械的な不具合（歯車が割れたとか、ベルトが切れたとか）かと思っていました。しかし生産終了していて製造元ではお手上げ状態ですから、廃棄する前に中を覗いてみようかと思います。昔々と違って、今の電化製品は目視して不良個所が判断できるようなことはないと思います。
2019-12-04
エビフライの尻尾を食べる？じゃぁ桜餅は？
エビフライの尻尾を食べる人もいれば、残す人もいます。どちらにもそれなりの理由があって、自分の行為が正当だと思っていると思いますが、それを間違っていると他人が言うことはないと思います。
このように食べ残すか食べ切るかが分かれるものの一例として、焼鮭の皮があります。これについても、当然残すという人もいれば、勿論食べるという人もいます。徳川光圀が好きだった（だから、食べるのが当たり前）という逸話を持ち出す人がいますが、他人の嗜好と自分の判断は別だろうと思います。
この流れで「桜餅の葉を食べるのか」という 話題が出てきます。食べるという人もいれば、残すに決まっているという人もいます。これも個人の好みの問題で、どちらが良いとか悪いという問題ではないでしょう。
しかし桜餅がエビフライや焼鮭と違うのは、桜餅には関東風（長命寺とも）と関西風（道明寺とも）があることです。関東風桜餅は、柏餅のようだと言ってしまうと言い過ぎかもしれませんが、ヴィジュアル的には柏餅に近く、道明寺桜餅に比べれば葉も固めな気がします。
柏餅の葉を食べる人はいないでしょう（いないと言い切ってしまうのも変ですから、少ないでしょうと言うべきかもしれませんが）。それと同じ感覚で、長命寺桜餅の葉は食べない人がいるのではないかと思います。道明寺桜餅の葉はしっとりしていて、いかにも食べられそうですから、何の疑問も持たずに食べる人もいるでしょう。
「桜餅の葉を食べるのか」を話題にしていながら、思い描く「桜餅」が同じとは限らないというのは、コミュニケーションにおける重大な問題かもしれません。だからと言って、それを確認しながら会話を勧めていくのは、日常的な会話では、くどい・しつこいと思われてしまうでしょう。
このように食べ残すか食べ切るかが分かれるものの一例として、焼鮭の皮があります。これについても、当然残すという人もいれば、勿論食べるという人もいます。徳川光圀が好きだった（だから、食べるのが当たり前）という逸話を持ち出す人がいますが、他人の嗜好と自分の判断は別だろうと思います。
この流れで「桜餅の葉を食べるのか」という 話題が出てきます。食べるという人もいれば、残すに決まっているという人もいます。これも個人の好みの問題で、どちらが良いとか悪いという問題ではないでしょう。
しかし桜餅がエビフライや焼鮭と違うのは、桜餅には関東風（長命寺とも）と関西風（道明寺とも）があることです。関東風桜餅は、柏餅のようだと言ってしまうと言い過ぎかもしれませんが、ヴィジュアル的には柏餅に近く、道明寺桜餅に比べれば葉も固めな気がします。
柏餅の葉を食べる人はいないでしょう（いないと言い切ってしまうのも変ですから、少ないでしょうと言うべきかもしれませんが）。それと同じ感覚で、長命寺桜餅の葉は食べない人がいるのではないかと思います。道明寺桜餅の葉はしっとりしていて、いかにも食べられそうですから、何の疑問も持たずに食べる人もいるでしょう。
「桜餅の葉を食べるのか」を話題にしていながら、思い描く「桜餅」が同じとは限らないというのは、コミュニケーションにおける重大な問題かもしれません。だからと言って、それを確認しながら会話を勧めていくのは、日常的な会話では、くどい・しつこいと思われてしまうでしょう。
フランス消防隊の職位
今年4月にノートルダム大聖堂で火災が発生しましたが、その消火活動のドキュメンタリーがナショナルジオグラフィックチャンネルで「ノートルダム大聖堂：悲劇の大規模火災」として2019年12月1日に放送されました。
ノートルダム大聖堂が燃えているニュース映像を見ていると、2001年9月11日のニューヨークのWTCの火災の記憶が蘇ります。また2019年10月31日には沖縄の首里城が火災も思い出し、貴重な建物に大きな被害を受けるのは残念です。
さて上述したドキュメンタリーを視ていて気付いたのですが、フランス消防隊の隊員の職位は、准将、大尉、伍長などのようで、軍隊と同じであることに驚きました。よく考ええると、軍隊と同じであっていけない理由はないし、同じでも構わないとも思いますが、今まで知らなかったので驚いたことは確かです。
さらに考えると、准将、大尉、伍長などの職位が、なぜ軍隊でしか使われていないのか、という疑問が生じました。フランス消防隊がそうであるように、消防組織や警察組織でも使っても構わないはずです（使わなくても構いませんが）。
また上述したドキュメンタリーでは、上級准尉という階級も出てきました。シンプルに考えると、将校というのは、将官、佐官、尉官があり、それぞれに大中少がつくので、尉官なら大尉、中尉、少尉となるでしょう。しかしながら、どのような組織でも次第に階級が細かくなっていき、准尉とか上級のような区別があらわれてきます。准尉というのは少尉よりも下位だと思いますが、上級准尉は、ただの准尉よりは上位なのでしょう。
長い歴史を持つ組織では、上位の職位が退かずに地位に留まっていると、下位の職位が上位に昇格できず、かと言って同じ職位のままにすることも出来なくなると、「准」とか「上級」のような形容詞をつけて、形式的に職位を上昇させるのではないかと思います。
ノートルダム大聖堂が燃えているニュース映像を見ていると、2001年9月11日のニューヨークのWTCの火災の記憶が蘇ります。また2019年10月31日には沖縄の首里城が火災も思い出し、貴重な建物に大きな被害を受けるのは残念です。
さて上述したドキュメンタリーを視ていて気付いたのですが、フランス消防隊の隊員の職位は、准将、大尉、伍長などのようで、軍隊と同じであることに驚きました。よく考ええると、軍隊と同じであっていけない理由はないし、同じでも構わないとも思いますが、今まで知らなかったので驚いたことは確かです。
さらに考えると、准将、大尉、伍長などの職位が、なぜ軍隊でしか使われていないのか、という疑問が生じました。フランス消防隊がそうであるように、消防組織や警察組織でも使っても構わないはずです（使わなくても構いませんが）。
また上述したドキュメンタリーでは、上級准尉という階級も出てきました。シンプルに考えると、将校というのは、将官、佐官、尉官があり、それぞれに大中少がつくので、尉官なら大尉、中尉、少尉となるでしょう。しかしながら、どのような組織でも次第に階級が細かくなっていき、准尉とか上級のような区別があらわれてきます。准尉というのは少尉よりも下位だと思いますが、上級准尉は、ただの准尉よりは上位なのでしょう。
長い歴史を持つ組織では、上位の職位が退かずに地位に留まっていると、下位の職位が上位に昇格できず、かと言って同じ職位のままにすることも出来なくなると、「准」とか「上級」のような形容詞をつけて、形式的に職位を上昇させるのではないかと思います。
2019-11-29
ハングルフォント：baekmuk-ttf
dynabook SS SX/15AにNetBSD/i386をインストールして利用しています。GUIとしてMATEデスクトップ環境（1.22.1）を入れて、日本語環境を整えてあります。追加してハングルの入出力も出来るようにしたくて、iBus用の入力メソッド（ibus-m17n-1.3.4nb26）を入れることで、入力は出来るようになっています。
これまではGNU Emacs（26.1） で動作確認を行っていました。iBus入力メソッドを切り替えるだけで、ハングル入力ができますし、表示も出来ていましたので、環境構築はできていると思っていました。ところがNightly（67.0.4）ではハングルが表示できなかったので、これはNightly単独の問題かと思っていました。
本当にNightlyの問題なのか確認しておこうと思い、MATE端末やLibreOffice（6.2.3.2）でもハングルが表示できるか確認したところ、実は表示できないことが発覚しました。入力自体は出来ているようです。
おそらくフォントが入っていないのが原因だろうと推測しました。きっとWebを検索すればフォントが見つかるだろうとは思いましたが、何が標準的なフォントなのかは、どうやって確認すれば良いのでしょうか。つまり日本語であればIPAex明朝やゴシックを入れている訳なのですが、このように標準的なハングルのフォントの名前が分からないのです。
pkgsrcのfontsカテゴリにある各ディレクトリにあるDESCRファイルを調べてみると、どうやらBAEKMUKというの名前のフォントが一般的のように思えます。そこでpkginでインストールできるパッケージを調べると、次のようになりました。
TeX用フォントは今回無関係だと思うので、X11フォントとTrueTypeフォントのどちらかを入れれば良さそうです。どちらにしようかと思ったのですが、TrueTypeフォントの方が綺麗だろうと思い、こちらをインストールしました。これでNightlyで確認したら、無事にハングルが表示されるようになりました。
以上でハングル入出力が出来るようになって、一安心です。しかし何故Emacsでは当初から表示出来ていたのか、謎です。
これまではGNU Emacs（26.1） で動作確認を行っていました。iBus入力メソッドを切り替えるだけで、ハングル入力ができますし、表示も出来ていましたので、環境構築はできていると思っていました。ところがNightly（67.0.4）ではハングルが表示できなかったので、これはNightly単独の問題かと思っていました。
本当にNightlyの問題なのか確認しておこうと思い、MATE端末やLibreOffice（6.2.3.2）でもハングルが表示できるか確認したところ、実は表示できないことが発覚しました。入力自体は出来ているようです。
おそらくフォントが入っていないのが原因だろうと推測しました。きっとWebを検索すればフォントが見つかるだろうとは思いましたが、何が標準的なフォントなのかは、どうやって確認すれば良いのでしょうか。つまり日本語であればIPAex明朝やゴシックを入れている訳なのですが、このように標準的なハングルのフォントの名前が分からないのです。
pkgsrcのfontsカテゴリにある各ディレクトリにあるDESCRファイルを調べてみると、どうやらBAEKMUKというの名前のフォントが一般的のように思えます。そこでpkginでインストールできるパッケージを調べると、次のようになりました。
# pkgin search baekmuk
tex-baekmuk-doc-2.2 Documentation for tex-baekmuk
tex-baekmuk-2.2 Baekmuk Korean TrueType fonts
ko-baekmuk-2.1nb1 X11 fonts for KSX 1001 Korean standard (baekmuk foundry)
baekmuk-ttf-2.2nb3 = Baekmuk family Korean TrueType fonts
=: package is installed and up-to-date
<: package is installed but newer version is available
>: installed package has a greater version than available package
TeX用フォントは今回無関係だと思うので、X11フォントとTrueTypeフォントのどちらかを入れれば良さそうです。どちらにしようかと思ったのですが、TrueTypeフォントの方が綺麗だろうと思い、こちらをインストールしました。これでNightlyで確認したら、無事にハングルが表示されるようになりました。
以上でハングル入出力が出来るようになって、一安心です。しかし何故Emacsでは当初から表示出来ていたのか、謎です。
2019-11-28
世界における名前の表記方法
the Japan Times Alphaの2019年11月22日号に掲載されたTan Ying Zhen氏のエッセイ「First name or last?」では、名前における姓名の順序が話題です。欧米では名前が先に記されます。しかし東洋ではまず姓が記されるのが一般的ですが、英語などで表記する場合に、東洋風にするか欧米風にするかについては一般的な方法がないようです。
日本では、日本語表記では「姓名」の順ですが、英語などでは「名姓」の順にします。しかしそれが東洋で一般的な習慣という訳ではないようなのです。エッセイで著者は次のように書いています。
日本人は、英語で表記する場合に名前を「名姓」の順にするので、東洋では何処でも同様だろうと考えてしまうのでしょう。さらに、日本人の姓名のローマ字表記は見慣れていても、アジア各国の英語表記は見慣れていないため、先に引用したような体験を著者がすることになってしまうのでしょう。
自分の周囲で当たり前である習慣が、（世界中の）何処でも当たり前であるとは限りません。異文化体験というと大袈裟に聞こえるかもしれません。うっかりすると見過ごしてしまうような日常的な一断面からも学べることは多くあると思います。
日本では、日本語表記では「姓名」の順ですが、英語などでは「名姓」の順にします。しかしそれが東洋で一般的な習慣という訳ではないようなのです。エッセイで著者は次のように書いています。
When I worked in Japan, it took me some time to get used to this. At conferences, my name tag would be printed as "Ying Zhen Tan." Once, I wrote "Tan Ying Zhen" on my name tag and people I met started calling me "Tan Ying", or "Miss Zhen." It sometimes took me a while to respond.
日本人は、英語で表記する場合に名前を「名姓」の順にするので、東洋では何処でも同様だろうと考えてしまうのでしょう。さらに、日本人の姓名のローマ字表記は見慣れていても、アジア各国の英語表記は見慣れていないため、先に引用したような体験を著者がすることになってしまうのでしょう。
自分の周囲で当たり前である習慣が、（世界中の）何処でも当たり前であるとは限りません。異文化体験というと大袈裟に聞こえるかもしれません。うっかりすると見過ごしてしまうような日常的な一断面からも学べることは多くあると思います。
今年もHobbyist OpenVMSのPAKを入手した
自宅にあるPERSONAL WORKSTATION 500au（DECchip 21164A-2 500MHz）には、OpenVMS Hobbyist Programを利用してOpenVMS/alphaをインストールしています。個人利用ではありますが本物のOpenVMSなので、使用するにはライセンスを必要とします。
OpenVMS Hobbyistのためのライセンス（Product Authorization Key）を入手するにはWebサイトからリクエストします。その後HPEからメールでPAKが送られてきます。このPAKには有効期間が設定されており、1年間相当なので、毎年更新手続きをおこなう必要があります。
そういう訳で、今年もPAKの申請を行いました。申請は「OpenVMS Hobbyist Registration」からおこないます。申請には「Participating Chapter」というものが必要になり、僕の場合は昔々に得た資格「DECUS Japan」を使っています（Membership Numberも必要になります ）。
Webからリクエストを投げると自動返信メールが届きます。このメールはグリニッジ標準時（GMT）で10時となっていますが、日本時間なら19時（午後7時）です。
驚いたことに、30分後にはPAKが届きました。近年は処理が早いのですが、以前には数日待ってもPAKが届かないので、待った方が良いのか、催促した方が良いのか、気を揉んだこともあります。
これでPAKが手に入ったので、早々にDCL（日本語では「コマプロ」）を流そうと思います。
OpenVMS Hobbyistのためのライセンス（Product Authorization Key）を入手するにはWebサイトからリクエストします。その後HPEからメールでPAKが送られてきます。このPAKには有効期間が設定されており、1年間相当なので、毎年更新手続きをおこなう必要があります。
そういう訳で、今年もPAKの申請を行いました。申請は「OpenVMS Hobbyist Registration」からおこないます。申請には「Participating Chapter」というものが必要になり、僕の場合は昔々に得た資格「DECUS Japan」を使っています（Membership Numberも必要になります ）。
Webからリクエストを投げると自動返信メールが届きます。このメールはグリニッジ標準時（GMT）で10時となっていますが、日本時間なら19時（午後7時）です。
Date: 27 Nov 2019 10:00:13 GMT
From: no-reply@hp.com
Subject: Thank you for contacting HP
Your message is important to us. It has been forwarded to the HP OpenVMS Systems
response team. An auto-acknowledgement will be sent to you to confirm your e-ma
il address and to confirm that we have received your inquiry. If you do not rece
ive an auto-acknowledgement after 1 hour, please re-submit your inquiry and veri
fy that you've entered the correct e-mail address.
If you have submitted an inquiry that is not related to HP OpenVMS Systems, we w
ill forward your message to the appropriate organization within HP.
If you have additional feedback or inquiries, please visit our <a href"http://we
lcome.hp.com/country/us/en/wwcontact.html">Contact HP</a> page.
Thank you,
OpenVMS webmaster
驚いたことに、30分後にはPAKが届きました。近年は処理が早いのですが、以前には数日待ってもPAKが届かないので、待った方が良いのか、催促した方が良いのか、気を揉んだこともあります。
Date: Wed, 27 Nov 2019 10:28:10 GMT
From: OpenVMS Customer Lab <openvmscustomerlab@hpe.com>
Subject: RE: OpenVMS Hobbyist Registration
Hello Furusawa-san,
Please see attached for PAKs to use on your VAX or Alpha.
The attached file is a DCL command file; to load your PAKs simply execute it
（以下略）
これでPAKが手に入ったので、早々にDCL（日本語では「コマプロ」）を流そうと思います。
2019-11-24
2019Q2でMATEデスクトップ環境を更新
dynabook SS SX/15AにNetBSD/i386を入れて利用しています。最近パッケージ2019Q2を入れたら、MATEデスクトップ環境の動作が変になりました。パッケージ2019Q2は、pkginを使ってバイナリ版を入れたのですが、i386版はamd64版に比べて提供されているパッケージが少ないことが分かりました。中途半端に更新されたので、動作がおかしくなったのではないかと思います。
VirtualBoxでNetBSD/i386とpkgsrc 2019Q2の環境を作り、/usr/pkgsrc/meta-pkgs/mateを使って自前でビルドしました。依存関係にある大物パッケージはpkginでインストールさせておいて、ビルド時間の短縮を図ります。
出来上がったMATE関係パッケージを使って、dynabook SS SX/15AのNetBSD/i386のパッケージを入れ替えます。強引な方法かもしれませんが、pkg_delete -fで既存のMATE関係パッケージを強制的に削除しました。その後でpkg_addで自前でビルドしたMATE関係パッケージをインストールしました。これで、ひとまずうまくいっています。
動作しなくなっていた時計アプレットが動くようになったので、不具合が解消しました。
念のために~/.xsession-errosを確認すると、何やら共有ライブラリが見つからないというエラーが出ています。しかしこのエラーを出しているコマンドがわからないので、/usr/pkg/binだろうとあたりをつけて、lddで調べてみました。するとMATEデスクトップ関係のパッケージが引っ掛かりました。パッケージの名前がmate-で見落としていました。
現状のMATEデスクトップ環境はバージョン1.22なので、pkg_infoの出力から「1.22」が含まれるパッケージを探してみると、名前がmate-で始まっていないMATEデスクトップ環境関連パッケージがあるようなので、それらも更新しておきました。
これで2019Q1から2019Q2への更新は完了だと思います。今後も、MATEデスクトップ環境とfirefoxの更新は自前でビルドする必要がありそうです。
VirtualBoxでNetBSD/i386とpkgsrc 2019Q2の環境を作り、/usr/pkgsrc/meta-pkgs/mateを使って自前でビルドしました。依存関係にある大物パッケージはpkginでインストールさせておいて、ビルド時間の短縮を図ります。
出来上がったMATE関係パッケージを使って、dynabook SS SX/15AのNetBSD/i386のパッケージを入れ替えます。強引な方法かもしれませんが、pkg_delete -fで既存のMATE関係パッケージを強制的に削除しました。その後でpkg_addで自前でビルドしたMATE関係パッケージをインストールしました。これで、ひとまずうまくいっています。
動作しなくなっていた時計アプレットが動くようになったので、不具合が解消しました。
念のために~/.xsession-errosを確認すると、何やら共有ライブラリが見つからないというエラーが出ています。しかしこのエラーを出しているコマンドがわからないので、/usr/pkg/binだろうとあたりをつけて、lddで調べてみました。するとMATEデスクトップ関係のパッケージが引っ掛かりました。パッケージの名前がmate-で見落としていました。
現状のMATEデスクトップ環境はバージョン1.22なので、pkg_infoの出力から「1.22」が含まれるパッケージを探してみると、名前がmate-で始まっていないMATEデスクトップ環境関連パッケージがあるようなので、それらも更新しておきました。
これで2019Q1から2019Q2への更新は完了だと思います。今後も、MATEデスクトップ環境とfirefoxの更新は自前でビルドする必要がありそうです。
2019-11-23
NetBSD/i386でfirefox(nightly) 67.0.4
dynabook SS SX/15AにNetBSD/i386を入れています。最近パッケージの2019Q2にビルド済みバイナリを利用して入れ換えたところ、firefoxが起動しなくなりました。共有ライブラリのバージョンが上がり、参照先が消えたことが原因のようです。
2019Q2のビルド済みバイナリのファイルは、amd64版に比べると、i386版は抜けが多いように思います。何か理由があってこうなっているのか、ただ単に理由もなく抜けているのか、よく分かりません。自分でビルドすれば良いことではありますが、できればビルド済みのバイナリが（amd64版と同程度にi386版も）用意されていると助かります。
VirtualBox上に、新規にNetBSD/i386の環境を作り、2019Q2のpkgsrcを持ってきてビルドすれば良い訳ですが、できれば既にビルド済みのパッケージを、さらに自前でビルドするのは避けたいところです。pkginを利用してビルド済みのバイナリを事前にインストールしておきたいと思いますが、それでは一体何を入れておけば良いのか、どのように判断すれば良いのでしょうか。
まずpkgsrc/www/firefoxで依存関係を確認してみました。make show-dependsの結果は次のようになりました。
ここに現れたパッケージにも依存関係があるとは思いますが、まずはこれらのパッケージをpkginでインストールしておきます。すると/var/db/pkgin/cacheには次のようなファイルが残りました。これらが依存関係にあるファイルという事でしょう。これらを自前でビルドする手間（と時間）が省けたということになります。ただし、rust、gcc6、llvm、clangのような大物は、依存関係には現れませんでしたが、firefoxのビルドに必要なので、入れてあります。
上述したパッケージが入っていればfirefoxのビルドができるかというと、まだ不足するパッケージ残っているようです。それもpkginで入れれば良いのでしょうが、探し出すのが大変なので、firefoxのビルドの依存性解決の中でビルドされるのに任せました。その結果、/usr/pkgsrc/packages/Allには以下のパッケージが残っていました。
1 -rw-r--r-- 1 root 125 34509 Nov 19 04:48 cwrappers-20180325.tgz
2 -rw-r--r-- 1 root 125 56542 Nov 19 04:48 digest-20190127.tgz
3 -rw-r--r-- 1 root 125 44579 Nov 19 04:49 libfetch-2.38.tgz
4 -rw-r--r-- 1 root 125 686931 Nov 19 04:50 pkg_install-20190405.tgz
5 -rw-r--r-- 1 root 125 80095 Nov 19 05:02 pkgin-0.12.0.tgz
6 -rw-r--r-- 1 root 125 1723438 Nov 19 06:26 cbindgen-0.8.7.tgz
7 -rw-r--r-- 1 root 125 17732221 Nov 19 06:46 perl-5.28.2.tgz
8 -rw-r--r-- 1 root 125 224624 Nov 19 06:48 m4-1.4.18nb2.tgz
9 -rw-r--r-- 1 root 125 726508 Nov 19 06:49 bison-3.2.4.tgz
10 -rw-r--r-- 1 root 125 2811569 Nov 19 06:52 bash-5.0.7.tgz
11 -rw-r--r-- 1 root 125 281995 Nov 19 06:53 gmake-4.2.1nb1.tgz
12 -rw-r--r-- 1 root 125 518466 Nov 19 06:54 libtool-base-2.4.6nb2.tgz
13 -rw-r--r-- 1 root 125 85271 Nov 19 06:54 pkgconf-1.6.0.tgz
14 -rw-r--r-- 1 root 125 7305 Nov 19 06:54 lockf-1.tgz
15 -rw-r--r-- 1 root 125 14446 Nov 19 06:56 p5-gettext-1.07nb3.tgz
16 -rw-r--r-- 1 root 125 154496 Nov 19 06:56 help2man-1.47.10.tgz
17 -rw-r--r-- 1 root 125 912844 Nov 19 06:56 autoconf-2.69nb8.tgz
18 -rw-r--r-- 1 root 125 679228 Nov 19 06:56 automake-1.16.1.tgz
19 -rw-r--r-- 1 root 125 626226 Nov 19 06:57 libuv-1.29.1.tgz
20 -rw-r--r-- 1 root 125 340102 Nov 19 06:59 rhash-1.3.8.tgz
21 -rw-r--r-- 1 root 125 1507655 Nov 19 07:06 libunistring-0.9.10.tgz
22 -rw-r--r-- 1 root 125 217215 Nov 19 07:07 libidn2-2.0.5.tgz
23 -rw-r--r-- 1 root 125 1053813 Nov 19 07:11 curl-7.65.1.tgz
24 -rw-r--r-- 1 root 125 10942018 Nov 19 07:50 cmake-3.14.5.tgz
25 -rw-r--r-- 1 root 125 139599 Nov 19 07:51 libcares-1.15.0nb1.tgz
26 -rw-r--r-- 1 root 125 39734 Nov 19 07:51 http-parser-2.9.2.tgz
27 -rw-r--r-- 1 root 125 10391635 Nov 19 09:48 nodejs-10.16.0.tgz
28 -rw-r--r-- 1 root 125 17650 Nov 19 09:49 glib2-tools-2.60.4.tgz
29 -rw-r--r-- 1 root 125 252324 Nov 19 09:50 autoconf213-2.13nb7.tgz
30 -rw-r--r-- 1 root 125 239004 Nov 19 09:50 zip-3.0nb3.tgz
31 -rw-r--r-- 1 root 125 300789 Nov 19 09:51 docbook-xml-4.5.tgz
32 -rw-r--r-- 1 root 125 2580222 Nov 19 09:51 docbook-xsl-1.79.1nb3.tgz
33 -rw-r--r-- 1 root 125 14520 Nov 19 09:51 getopt-1.1.6.tgz
34 -rw-r--r-- 1 root 125 373503 Nov 19 09:56 libgpg-error-1.36.tgz
35 -rw-r--r-- 1 root 125 1037069 Nov 19 09:59 libgcrypt-1.8.4.tgz
36 -rw-r--r-- 1 root 125 671244 Nov 19 10:00 libxslt-1.1.33.tgz
37 -rw-r--r-- 1 root 125 410280 Nov 19 10:01 asciidoc-8.6.10nb1.tgz
38 -rw-r--r-- 1 root 125 29770 Nov 19 10:01 xmlto-0.0.28nb2.tgz
39 -rw-r--r-- 1 root 125 796779 Nov 19 10:02 nasm-2.14.02.tgz
40 -rw-r--r-- 1 root 125 1190026 Nov 19 10:03 yasm-1.3.0.tgz
41 -rw-r--r-- 1 root 125 3351 Nov 19 10:03 osabi-NetBSD-8.1.tgz
42 -rw-r--r-- 1 root 125 50414 Nov 19 10:04 x11-links-1.19.tgz
43 -rw-r--r-- 1 root 125 271650 Nov 19 10:17 gsed-4.7.tgz
44 -rw-r--r-- 1 root 125 56556277 Nov 23 12:15 firefox-67.0.4.tgz
以上でfirefox 67.0.4がビルド出来ました。依存関係にあるパッケージが入っていさえすれば、あとはビルドする時間だけの問題です（マシンの性能にも依りますが、1日弱くらいでしょう）。
2019Q2のビルド済みバイナリのファイルは、amd64版に比べると、i386版は抜けが多いように思います。何か理由があってこうなっているのか、ただ単に理由もなく抜けているのか、よく分かりません。自分でビルドすれば良いことではありますが、できればビルド済みのバイナリが（amd64版と同程度にi386版も）用意されていると助かります。
VirtualBox上に、新規にNetBSD/i386の環境を作り、2019Q2のpkgsrcを持ってきてビルドすれば良い訳ですが、できれば既にビルド済みのパッケージを、さらに自前でビルドするのは避けたいところです。pkginを利用してビルド済みのバイナリを事前にインストールしておきたいと思いますが、それでは一体何を入れておけば良いのか、どのように判断すれば良いのでしょうか。
まずpkgsrc/www/firefoxで依存関係を確認してみました。make show-dependsの結果は次のようになりました。
gcc6-libs>=6.1.0:../../lang/gcc6-libs
libffi>=3.0.11:../../devel/libffi
nspr>=4.21:../../devel/nspr
icu>=64.1:../../textproc/icu
nss>=3.43nb2:../../devel/nss
libwebp>=1.0.2:../../graphics/libwebp
libIDL>=0.8.14nb4:../../net/libIDL
ffmpeg4>=4.1nb2:../../multimedia/ffmpeg4
gtk2+>=2.24.32nb7:../../x11/gtk2
gtk3+>=3.24.1nb2:../../x11/gtk3
dbus-glib>=0.100nb1:../../sysutils/dbus-glib
desktop-file-utils>=0.10nb1:../../sysutils/desktop-file-utils
ここに現れたパッケージにも依存関係があるとは思いますが、まずはこれらのパッケージをpkginでインストールしておきます。すると/var/db/pkgin/cacheには次のようなファイルが残りました。これらが依存関係にあるファイルという事でしょう。これらを自前でビルドする手間（と時間）が省けたということになります。ただし、rust、gcc6、llvm、clangのような大物は、依存関係には現れませんでしたが、firefoxのビルドに必要なので、入れてあります。
1 -rw-r--r-- 1 root wheel 3877464 Nov 19 05:37 gcc6-libs-6.5.0nb3.tgz
2 -rw-r--r-- 1 root wheel 27832 Nov 19 05:38 libffi-3.2.1nb4.tgz
3 -rw-r--r-- 1 root wheel 249852 Nov 19 05:38 nspr-4.21.tgz
4 -rw-r--r-- 1 root wheel 29188 Nov 19 05:38 libuuid-2.32.1.tgz
5 -rw-r--r-- 1 root wheel 14996724 Nov 19 05:38 python37-3.7.3nb1.tgz
6 -rw-r--r-- 1 root wheel 16853888 Nov 19 05:38 icu-64.2nb1.tgz
7 -rw-r--r-- 1 root wheel 1806180 Nov 19 05:39 nss-3.44.1.tgz
8 -rw-r--r-- 1 root wheel 282596 Nov 19 05:39 jpeg-9cnb1.tgz
9 -rw-r--r-- 1 root wheel 72828 Nov 19 05:39 jbigkit-2.1.tgz
10 -rw-r--r-- 1 root wheel 785160 Nov 19 05:39 tiff-4.0.10nb1.tgz
11 -rw-r--r-- 1 root wheel 267004 Nov 19 05:39 png-1.6.37.tgz
12 -rw-r--r-- 1 root wheel 28592 Nov 19 05:39 giflib-5.1.4.tgz
13 -rw-r--r-- 1 root wheel 383476 Nov 19 05:39 libwebp-1.0.2.tgz
14 -rw-r--r-- 1 root wheel 667472 Nov 19 05:39 pcre-8.43.tgz
15 -rw-r--r-- 1 root wheel 2435708 Nov 19 05:39 glib2-2.60.4nb5.tgz
16 -rw-r--r-- 1 root wheel 110640 Nov 19 05:39 libIDL-0.8.14nb4.tgz
17 -rw-r--r-- 1 root wheel 103664 Nov 19 05:40 graphite2-1.3.11nb2.tgz
18 -rw-r--r-- 1 root wheel 570740 Nov 19 05:40 freetype2-2.10.0.tgz
19 -rw-r--r-- 1 root wheel 941628 Nov 19 05:40 harfbuzz-2.4.0nb3.tgz
20 -rw-r--r-- 1 root wheel 56644 Nov 19 05:40 fribidi-0.19.7.tgz
21 -rw-r--r-- 1 root wheel 106632 Nov 19 05:40 enca-1.15.tgz
22 -rw-r--r-- 1 root wheel 192220 Nov 19 05:40 libogg-1.3.3.tgz
23 -rw-r--r-- 1 root wheel 24664 Nov 19 05:40 xmlcatmgr-2.2nb1.tgz
24 -rw-r--r-- 1 root wheel 212408 Nov 19 05:40 xvidcore-1.3.3nb1.tgz
25 -rw-r--r-- 1 root wheel 567500 Nov 19 05:40 x264-devel-20190312.tgz
26 -rw-r--r-- 1 root wheel 1482168 Nov 19 05:40 libxml2-2.9.9.tgz
27 -rw-r--r-- 1 root wheel 1035252 Nov 19 05:40 libvpx-1.8.0.tgz
28 -rw-r--r-- 1 root wheel 356876 Nov 19 05:40 libvorbis-1.3.6nb1.tgz
29 -rw-r--r-- 1 root wheel 75372 Nov 19 05:40 libvdpau-1.2.tgz
30 -rw-r--r-- 1 root wheel 168696 Nov 19 05:40 libva-2.3.0.tgz
31 -rw-r--r-- 1 root wheel 245752 Nov 19 05:40 libtheora-1.1.1nb2.tgz
32 -rw-r--r-- 1 root wheel 219456 Nov 19 05:40 libbluray-1.1.2.tgz
33 -rw-r--r-- 1 root wheel 139688 Nov 19 05:40 libass-0.14.0nb2.tgz
34 -rw-r--r-- 1 root wheel 1342244 Nov 19 05:40 libaom-1.0.0nb1.tgz
35 -rw-r--r-- 1 root wheel 304936 Nov 19 05:40 lame-3.100nb1.tgz
36 -rw-r--r-- 1 root wheel 856592 Nov 19 05:40 fontconfig-2.13.1.tgz
37 -rw-r--r-- 1 root wheel 11033160 Nov 19 05:40 ffmpeg4-4.1.3nb1.tgz
38 -rw-r--r-- 1 root wheel 97924 Nov 19 05:41 lzo-2.10.tgz
39 -rw-r--r-- 1 root wheel 15788 Nov 19 05:41 cairo-gobject-1.16.0nb3.tgz
40 -rw-r--r-- 1 root wheel 500364 Nov 19 05:41 mozilla-rootcerts-1.0.20190306.tgz
41 -rw-r--r-- 1 root wheel 497256 Nov 19 05:41 shared-mime-info-1.10.tgz
42 -rw-r--r-- 1 root wheel 11088496 Nov 19 05:41 python27-2.7.16.tgz
43 -rw-r--r-- 1 root wheel 18148 Nov 19 05:41 py27-expat-2.7.16.tgz
44 -rw-r--r-- 1 root wheel 544460 Nov 19 05:41 pango-1.42.4nb5.tgz
45 -rw-r--r-- 1 root wheel 64236 Nov 19 05:41 libXft-2.3.3.tgz
46 -rw-r--r-- 1 root wheel 702828 Nov 19 05:41 gdk-pixbuf2-2.36.12.tgz
47 -rw-r--r-- 1 root wheel 1082240 Nov 19 05:41 cairo-1.16.0.tgz
48 -rw-r--r-- 1 root wheel 374672 Nov 19 05:41 atk-2.26.1.tgz
49 -rw-r--r-- 1 root wheel 8410548 Nov 19 05:41 gtk2+-2.24.32nb8.tgz
50 -rw-r--r-- 1 root wheel 18920 Nov 19 05:42 py37-expat-3.7.3.tgz
51 -rw-r--r-- 1 root wheel 23764 Nov 19 05:42 py37-cElementTree-3.7.3.tgz
52 -rw-r--r-- 1 root wheel 1092044 Nov 19 05:42 gobject-introspection-1.60.1nb1.tgz
53 -rw-r--r-- 1 root wheel 529764 Nov 19 05:42 dbus-1.12.16.tgz
54 -rw-r--r-- 1 root wheel 265524 Nov 19 05:42 at-spi2-core-2.26.2nb1.tgz
55 -rw-r--r-- 1 root wheel 402740 Nov 19 05:42 libepoxy-1.4.3nb2.tgz
56 -rw-r--r-- 1 root wheel 8936 Nov 19 05:42 hicolor-icon-theme-0.17.tgz
57 -rw-r--r-- 1 root wheel 35056 Nov 19 05:42 desktop-file-utils-0.23nb1.tgz
58 -rw-r--r-- 1 root wheel 92468 Nov 19 05:42 at-spi2-atk-2.26.1nb1.tgz
59 -rw-r--r-- 1 root wheel 13127504 Nov 19 05:42 gtk3+-3.24.8.tgz
60 -rw-r--r-- 1 root wheel 158912 Nov 19 05:42 dbus-glib-0.110.tgz
61 -rw-r--r-- 1 root wheel 266284 Nov 19 05:49 bsdtar-3.3.3.tgz
62 -rw-r--r-- 1 root wheel 152071808 Nov 19 05:51 rust-1.35.0nb1.tgz
63 -rw-r--r-- 1 root wheel 310764 Nov 19 05:59 tcsh-6.21.00.tgz
64 -rw-r--r-- 1 root wheel 206652 Nov 19 12:32 gsed-4.7.tgz
65 -rw-r--r-- 1 root wheel 56579228 Nov 19 12:32 gcc6-6.5.0nb2.tgz
66 -rw-r--r-- 1 root wheel 51488788 Nov 19 12:36 llvm-8.0.0.tgz
67 -rw-r--r-- 1 root wheel 49225872 Nov 19 12:38 clang-8.0.0.tgz
上述したパッケージが入っていればfirefoxのビルドができるかというと、まだ不足するパッケージ残っているようです。それもpkginで入れれば良いのでしょうが、探し出すのが大変なので、firefoxのビルドの依存性解決の中でビルドされるのに任せました。その結果、/usr/pkgsrc/packages/Allには以下のパッケージが残っていました。
1 -rw-r--r-- 1 root 125 34509 Nov 19 04:48 cwrappers-20180325.tgz
2 -rw-r--r-- 1 root 125 56542 Nov 19 04:48 digest-20190127.tgz
3 -rw-r--r-- 1 root 125 44579 Nov 19 04:49 libfetch-2.38.tgz
4 -rw-r--r-- 1 root 125 686931 Nov 19 04:50 pkg_install-20190405.tgz
5 -rw-r--r-- 1 root 125 80095 Nov 19 05:02 pkgin-0.12.0.tgz
6 -rw-r--r-- 1 root 125 1723438 Nov 19 06:26 cbindgen-0.8.7.tgz
7 -rw-r--r-- 1 root 125 17732221 Nov 19 06:46 perl-5.28.2.tgz
8 -rw-r--r-- 1 root 125 224624 Nov 19 06:48 m4-1.4.18nb2.tgz
9 -rw-r--r-- 1 root 125 726508 Nov 19 06:49 bison-3.2.4.tgz
10 -rw-r--r-- 1 root 125 2811569 Nov 19 06:52 bash-5.0.7.tgz
11 -rw-r--r-- 1 root 125 281995 Nov 19 06:53 gmake-4.2.1nb1.tgz
12 -rw-r--r-- 1 root 125 518466 Nov 19 06:54 libtool-base-2.4.6nb2.tgz
13 -rw-r--r-- 1 root 125 85271 Nov 19 06:54 pkgconf-1.6.0.tgz
14 -rw-r--r-- 1 root 125 7305 Nov 19 06:54 lockf-1.tgz
15 -rw-r--r-- 1 root 125 14446 Nov 19 06:56 p5-gettext-1.07nb3.tgz
16 -rw-r--r-- 1 root 125 154496 Nov 19 06:56 help2man-1.47.10.tgz
17 -rw-r--r-- 1 root 125 912844 Nov 19 06:56 autoconf-2.69nb8.tgz
18 -rw-r--r-- 1 root 125 679228 Nov 19 06:56 automake-1.16.1.tgz
19 -rw-r--r-- 1 root 125 626226 Nov 19 06:57 libuv-1.29.1.tgz
20 -rw-r--r-- 1 root 125 340102 Nov 19 06:59 rhash-1.3.8.tgz
21 -rw-r--r-- 1 root 125 1507655 Nov 19 07:06 libunistring-0.9.10.tgz
22 -rw-r--r-- 1 root 125 217215 Nov 19 07:07 libidn2-2.0.5.tgz
23 -rw-r--r-- 1 root 125 1053813 Nov 19 07:11 curl-7.65.1.tgz
24 -rw-r--r-- 1 root 125 10942018 Nov 19 07:50 cmake-3.14.5.tgz
25 -rw-r--r-- 1 root 125 139599 Nov 19 07:51 libcares-1.15.0nb1.tgz
26 -rw-r--r-- 1 root 125 39734 Nov 19 07:51 http-parser-2.9.2.tgz
27 -rw-r--r-- 1 root 125 10391635 Nov 19 09:48 nodejs-10.16.0.tgz
28 -rw-r--r-- 1 root 125 17650 Nov 19 09:49 glib2-tools-2.60.4.tgz
29 -rw-r--r-- 1 root 125 252324 Nov 19 09:50 autoconf213-2.13nb7.tgz
30 -rw-r--r-- 1 root 125 239004 Nov 19 09:50 zip-3.0nb3.tgz
31 -rw-r--r-- 1 root 125 300789 Nov 19 09:51 docbook-xml-4.5.tgz
32 -rw-r--r-- 1 root 125 2580222 Nov 19 09:51 docbook-xsl-1.79.1nb3.tgz
33 -rw-r--r-- 1 root 125 14520 Nov 19 09:51 getopt-1.1.6.tgz
34 -rw-r--r-- 1 root 125 373503 Nov 19 09:56 libgpg-error-1.36.tgz
35 -rw-r--r-- 1 root 125 1037069 Nov 19 09:59 libgcrypt-1.8.4.tgz
36 -rw-r--r-- 1 root 125 671244 Nov 19 10:00 libxslt-1.1.33.tgz
37 -rw-r--r-- 1 root 125 410280 Nov 19 10:01 asciidoc-8.6.10nb1.tgz
38 -rw-r--r-- 1 root 125 29770 Nov 19 10:01 xmlto-0.0.28nb2.tgz
39 -rw-r--r-- 1 root 125 796779 Nov 19 10:02 nasm-2.14.02.tgz
40 -rw-r--r-- 1 root 125 1190026 Nov 19 10:03 yasm-1.3.0.tgz
41 -rw-r--r-- 1 root 125 3351 Nov 19 10:03 osabi-NetBSD-8.1.tgz
42 -rw-r--r-- 1 root 125 50414 Nov 19 10:04 x11-links-1.19.tgz
43 -rw-r--r-- 1 root 125 271650 Nov 19 10:17 gsed-4.7.tgz
44 -rw-r--r-- 1 root 125 56556277 Nov 23 12:15 firefox-67.0.4.tgz
以上でfirefox 67.0.4がビルド出来ました。依存関係にあるパッケージが入っていさえすれば、あとはビルドする時間だけの問題です（マシンの性能にも依りますが、1日弱くらいでしょう）。
2019-11-21
NetBSD/i386のパッケージ2019Q2
dynabook SS SX/15AにNetBSD/i386を入れて使っています。つい先日パッケージを2019Q1から2019Q2に更新しました。更新したら、動かなくなったものがあります。気がついているのは以下の3点ですが、もしかしたら気付いていないものがあるかもしれません。
そもそも2019Q2への更新はpkginを利用しましたが、その参照先には必要なパッケージが揃っていないようです。i386版とamd64版とでは、（理由は不明ですが）準備されているパッケージの数が異なっています。
例えばMATEデスクトップ環境に関するパッケージは、amd64版では26ファイルありますが、i386版では10ファイルしかありません。i386版では16ファイル少ないわけですが、その不足するファイルがMATEデスクトップ環境を調える上で不要というわけでもありません。バイナリ版が用意されていないならば、pkgsrcから自前でビルドする必要があります。
i386版そのものが時代遅れとなりつつあるのだろうと思いますが、ビルド済みのパッケージがamd64版とi386版とで揃っていないのは不便です。なんとかならないかなと思います。
- 2019Q1の頃に自前でビルドしたfirefoxが起動しない。
- MATEの時計パネルが起動しない。
- 一般ユーザのメニューに「シャットダウン」が現れない。
そもそも2019Q2への更新はpkginを利用しましたが、その参照先には必要なパッケージが揃っていないようです。i386版とamd64版とでは、（理由は不明ですが）準備されているパッケージの数が異なっています。
例えばMATEデスクトップ環境に関するパッケージは、amd64版では26ファイルありますが、i386版では10ファイルしかありません。i386版では16ファイル少ないわけですが、その不足するファイルがMATEデスクトップ環境を調える上で不要というわけでもありません。バイナリ版が用意されていないならば、pkgsrcから自前でビルドする必要があります。
i386版そのものが時代遅れとなりつつあるのだろうと思いますが、ビルド済みのパッケージがamd64版とi386版とで揃っていないのは不便です。なんとかならないかなと思います。
2019-11-18
pkgin full-upgradeは何をしようとしているんだろうか
dynabook SS SX/15AにNetBSD/i386を入れて使用しています。パッケージの2019Q1を入れていましたが、2019Q2が出ているのでpkginで更新しようと考えています。
pkgin full-upgradeで一括して入れ換えてしまおうと思っていますが、ファイル転送でstallしてしまいます。pkginにはオプション「-d」を指定することで、ファイル転送だけをおこなうことができるようです。ところがファイル転送で頻繁にstallするので、なかなかインストールまで辿りつきません。
pkginは、更新を始める前に対象となるファイル名（.tgzファイル） を表示します。その情報を加工して、pkginを使わず、ftpコマンドでファイルをダウンロードしておくことにしました。必要なファイルが/var/db/pkgin/cacheに存在すれば、pkginとしてはインストールしてくれるようです。
それは良いのですが、更新対象となるファイルが異常に多すぎる気がします。例えば、今までTeXはインストールしていなかったのに、更新対象にしています。細かくは確認していませんが、他にも謎の更新対象があるのではないかと思います。
どうしてこういうことになるんでしょう。
pkgin full-upgradeで一括して入れ換えてしまおうと思っていますが、ファイル転送でstallしてしまいます。pkginにはオプション「-d」を指定することで、ファイル転送だけをおこなうことができるようです。ところがファイル転送で頻繁にstallするので、なかなかインストールまで辿りつきません。
pkginは、更新を始める前に対象となるファイル名（.tgzファイル） を表示します。その情報を加工して、pkginを使わず、ftpコマンドでファイルをダウンロードしておくことにしました。必要なファイルが/var/db/pkgin/cacheに存在すれば、pkginとしてはインストールしてくれるようです。
それは良いのですが、更新対象となるファイルが異常に多すぎる気がします。例えば、今までTeXはインストールしていなかったのに、更新対象にしています。細かくは確認していませんが、他にも謎の更新対象があるのではないかと思います。
どうしてこういうことになるんでしょう。
NetBSDのpkginでstallする
dynabook SS SX/15AにNetBSD/i386を入れて使用しています。以前は、OS本体もパッケージもcurrentのソースから自前でビルドしていました。しかしビルド時間がかかりすぎる（1週間以上かかります）し、それだけならまだしも、無線LANの接続が切れたり、カーネルパニックが発生したりして、何度もリブートし再開するはめに陥るので、ビルド済みのバイナリを入れるだけに方針を転換しました。
数か月前にpkgを入れた時は2019Q1だったのですが、2019Q2が出ているので、更新することにしました。pkginを使って更新することにしているので「pkgin full-upgrade」 をおこないました。更新対象のパッケージ（.tgzファイル）をダウンロードしてからインストールが始まる筈なのですが、ファイル転送中にstall状態になります。たまに発生するなら我慢もできますが、10分もしないうちに発生するので、とても困ります。
stallしてファイル転送できなかったファイルは、再度pkginを実行すると再転送しようとするのですが、そこでまたstallします。勘弁してくれという気持ちになります。しかしそのファイルを、本家またはミラーサイトからftpでダウンロードする分には、何も問題なく転送できます。うまくいって結構なことなのですが、なぜpkginではstallするのに、ftpなら問題ないのでしょうか。
ハードウェアが旧いので、あちこちにガタがきている可能性は否定できません。はっきり確認する手段がないので憶測ですが、ハードウェアが旧いことだけが原因ではないような気がします。
数か月前にpkgを入れた時は2019Q1だったのですが、2019Q2が出ているので、更新することにしました。pkginを使って更新することにしているので「pkgin full-upgrade」 をおこないました。更新対象のパッケージ（.tgzファイル）をダウンロードしてからインストールが始まる筈なのですが、ファイル転送中にstall状態になります。たまに発生するなら我慢もできますが、10分もしないうちに発生するので、とても困ります。
stallしてファイル転送できなかったファイルは、再度pkginを実行すると再転送しようとするのですが、そこでまたstallします。勘弁してくれという気持ちになります。しかしそのファイルを、本家またはミラーサイトからftpでダウンロードする分には、何も問題なく転送できます。うまくいって結構なことなのですが、なぜpkginではstallするのに、ftpなら問題ないのでしょうか。
ハードウェアが旧いので、あちこちにガタがきている可能性は否定できません。はっきり確認する手段がないので憶測ですが、ハードウェアが旧いことだけが原因ではないような気がします。
2019-11-16
FreeBSD/amd64を12.1-RELEASEに更新した
ThinkPad E530cにFreeBSD/amd64を入れています。先日12.1-RELEASEがアナウンスされたので12.0-RELEASEから更新しました。昔はソースコードを自前でビルドしていましたが、今はfreebsd-updateを使うことにしています。
手順は次の通りです。これらの作業はシングルユーザーでおこないました。リブート前に要した時間が1時間半くらい、リブート後は30分ほどで、合計して2時間くらいかかりました。
手順は次の通りです。これらの作業はシングルユーザーでおこないました。リブート前に要した時間が1時間半くらい、リブート後は30分ほどで、合計して2時間くらいかかりました。
- freebsd-update -r 12.1-RELEASE upgrade
- freebsd-update install
- リブート
- freebsd-update install
- freebsd-update install
2019-11-14
NetBSDのMATEデスクトップ環境で「シャットダウン」メニューが無くなった気がする
dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて使っています。以前はOSもpkgもカレントのソースコードを取得してきて自前でビルドしていました。しかし今年6月頃にpkgを入れ替えようとして、ハードウェアのディスク不足や不調などの原因により、かなり苦労したため、ビルド済みのバイナリを取得してインストールする方針に転換しました。
さらにOS本体もカレントのソースコードを自前でビルドしていたのを止めようと考えていたので、NetBSD 8.1の公式リリース版を使うことにしました。インストールされていたOSがNetBSD 8.1よりは微妙に新しいカレントだったので、バージョンが戻ることになりまる。トラブルが発生しないか心配だったのですが、無事にNetBSD 8.1になったようです。
普段使っているアプリケーションの動作確認をしてみましたが、問題なさそうです。
ただし1つだけ、これまでとは動きが異なる箇所があります。MATEデスクトップ環境を利用していて、メニューに「シャットダウンする」というのがあったはずなのですが、見当たりません。メニューからシャットダウンできなくても、他に方法はいくらでもあるので実害はないのですが、気になります。
MATEデスクトップ環境に限らず、今どきのデスクトップ環境はDbusやらPolicyKitやらを使っていて、問題解決のために何から手をつけたら良いのか、よく分かりません。
さらにOS本体もカレントのソースコードを自前でビルドしていたのを止めようと考えていたので、NetBSD 8.1の公式リリース版を使うことにしました。インストールされていたOSがNetBSD 8.1よりは微妙に新しいカレントだったので、バージョンが戻ることになりまる。トラブルが発生しないか心配だったのですが、無事にNetBSD 8.1になったようです。
普段使っているアプリケーションの動作確認をしてみましたが、問題なさそうです。
ただし1つだけ、これまでとは動きが異なる箇所があります。MATEデスクトップ環境を利用していて、メニューに「シャットダウンする」というのがあったはずなのですが、見当たりません。メニューからシャットダウンできなくても、他に方法はいくらでもあるので実害はないのですが、気になります。
MATEデスクトップ環境に限らず、今どきのデスクトップ環境はDbusやらPolicyKitやらを使っていて、問題解決のために何から手をつけたら良いのか、よく分かりません。
2019-11-13
「初心者マーク」と「高齢者マーク」
「初心者マーク」や「高齢者マーク」が貼られている車を見るのは日常的ですが、先日両方貼られた車を目撃しました。あまり見かけない光景です。
「初心者マーク」は「初心者運転標識」というのが正式名称で、道路交通法第71条の5で次のように定められています。免許取得後1年間は義務ですが、それ以降の規定はないため、掲示できなくなるわけではないようです。
さて「高齢者マーク」は「高齢運転者標識」というのが正式名称で、道路交通法附則第22条で次のように定められているため、当面は努力義務ということのようです。もちろん掲示しても良いわけです。
可能性の高い想定としては、その車を家族で共用していて、マークを剥がし忘れた場合でしょうか。
正確な答えは、そのような車を運転している本人に尋ねるしかないとは思います。
「初心者マーク」は「初心者運転標識」というのが正式名称で、道路交通法第71条の5で次のように定められています。免許取得後1年間は義務ですが、それ以降の規定はないため、掲示できなくなるわけではないようです。
第七十一条の五 第八十四条第三項の準中型自動車免許を受けた者で、当該準中型自動車免許を受けていた期間（当該免許の効力が停止されていた期間を除く。）が通算して一年に達しないもの（当該免許を受けた日前六月以内に準中型自動車免許を受けていたことがある者その他の者で政令で定めるもの及び同項の普通自動車免許を現に受けており、かつ、現に受けている準中型自動車免許を受けた日前に当該普通自動車免許を受けていた期間（当該免許の効力が停止されていた期間を除く。）が通算して二年以上である者を除く。）は、内閣府令で定めるところにより準中型自動車の前面及び後面に内閣府令で定める様式の標識を付けないで準中型自動車を運転してはならない。
さて「高齢者マーク」は「高齢運転者標識」というのが正式名称で、道路交通法附則第22条で次のように定められているため、当面は努力義務ということのようです。もちろん掲示しても良いわけです。
第二十二条 第七十一条の五第三項の規定は、当分の間、適用しない。この場合において、同条第四項中「七十歳以上七十五歳未満」とあるのは、「七十歳以上」とする。それでは両方とも貼られているというのは、どのような状況なのでしょうか。運転者の年齢が70歳以上（高齢者マーク）であり、かつ免許取得後1年以内（初心者マーク）なら、そうなるのかもしれませんが、あまり現実的な想定ではないでしょう。
可能性の高い想定としては、その車を家族で共用していて、マークを剥がし忘れた場合でしょうか。
正確な答えは、そのような車を運転している本人に尋ねるしかないとは思います。
2019-11-11
「Std Math Keyboard」を使わなくてもよいかもしれない
『いつでも どこでも スマホで数学』を読みながらMoA（Maxima on Android）の使い方に習熟しようと思っています。まずは「Chapter 1 Maximaの概要とインストール」の記述に従ってアプリのインストールしてみました。入力は「Std Math Keyboard」を推奨していますが、気になる点があります。書籍でも次のように書かれており、懸念が示されています。
Android9では「iWnn IME」以外にも「Gboard」が使えます。「Std Math Keyboard」なら数式で用いる記号類や英数字が入力しやすいとは思いますが、「Gboard」で数式を入力するのが使いものにならないという訳でもないような気がします。「Std Math Keyboard」が圧倒的に優位にたっているとも思えません。
今後は「Gboard」を利用することにして、「Std Math Keyboard」はアンインストールしようかと思います。
ONにすると、「すべての入力内容の収集をアプリに許可することになるがかまわないか?」という趣旨の注意書きが表示され、ちょっと同意するのをためらいます。このような注意書きは気になりますが、はたしてMoAは「Std Math Keyboard」がないと不便なのか、それとも無くても構わないのか、実際に使ってみて判断することにしました。
Android9では「iWnn IME」以外にも「Gboard」が使えます。「Std Math Keyboard」なら数式で用いる記号類や英数字が入力しやすいとは思いますが、「Gboard」で数式を入力するのが使いものにならないという訳でもないような気がします。「Std Math Keyboard」が圧倒的に優位にたっているとも思えません。
今後は「Gboard」を利用することにして、「Std Math Keyboard」はアンインストールしようかと思います。
2019-11-10
「名詞＋だ」は良くて、「形容詞＋だ」は不可なのはナゼ？
日本語の文末は敬体（です・ます調）と常体（だ・である調）があります。それらは、文の用いられる状況に応じて使い分けられますが、相互に交換できるはずです。例えば、「私は○○××です」でも良いし、「私は○○××だ」でも構わないでしょう。
何かで耳にしたのですが、「楽しい」のような形容詞では「楽しいです」とは言えても、「楽しいだ」とか「楽しいである」とは言わないのですが、これは何故でしょうか？名詞であれば「東京駅です」でも「東京駅だ」でも構わないわけです。「形容詞＋だ」が認められないのは、単に聞きなれないというだけ問題なのでしょうか。
もっとも「形容詞＋です」のような表現（「嬉しいです」とか「楽しいです」）は、印象として幼さを感じます。例えば小学生の文章「今日は遠足で楽しかったです」のような印象を受けるので、自分で使うのは避けて、別の表現を探すようにしています。
何かで耳にしたのですが、「楽しい」のような形容詞では「楽しいです」とは言えても、「楽しいだ」とか「楽しいである」とは言わないのですが、これは何故でしょうか？名詞であれば「東京駅です」でも「東京駅だ」でも構わないわけです。「形容詞＋だ」が認められないのは、単に聞きなれないというだけ問題なのでしょうか。
もっとも「形容詞＋です」のような表現（「嬉しいです」とか「楽しいです」）は、印象として幼さを感じます。例えば小学生の文章「今日は遠足で楽しかったです」のような印象を受けるので、自分で使うのは避けて、別の表現を探すようにしています。
英語のラストネームの4パターン
the japan times alphaの2019年11月8日号に掲載されている「The history of English last names -- every name tells a story!」（Kip Cates）では、英語のラストネームの由来を4パターンに分類しています。それは次の通りです。
日本人の名字は膨大だと言われています。30万種とも言われますが異論（【年末緊急発表】日本人の名字３０万種は事実か？）もあるようです。実際の数を定義するのは難しいとは思いますが、種類が多いのは間違いないでしょう。日本人の名字の由来を何パターンに分類できるのかわかりませんが、地名由来が多いのではないかと思います。
古代の姓（源平藤橘が有名ですが、4種類だけだった訳ではありません）のままでは他者との区別ができないので、自然に地名で区別するようになっていったと思われます。区別できるなら地名でなくても良いわけで、生業や官職などもあると思いますが、比率で考えれば地名由来が圧倒的ではないかと思います。
- Some are based on occupations.
- Some names refer to the places where people lived.
- Some names are based on family relationships.
- Some last names are based on personal traits.
日本人の名字は膨大だと言われています。30万種とも言われますが異論（【年末緊急発表】日本人の名字３０万種は事実か？）もあるようです。実際の数を定義するのは難しいとは思いますが、種類が多いのは間違いないでしょう。日本人の名字の由来を何パターンに分類できるのかわかりませんが、地名由来が多いのではないかと思います。
古代の姓（源平藤橘が有名ですが、4種類だけだった訳ではありません）のままでは他者との区別ができないので、自然に地名で区別するようになっていったと思われます。区別できるなら地名でなくても良いわけで、生業や官職などもあると思いますが、比率で考えれば地名由来が圧倒的ではないかと思います。
Android版Maxima
最近長年使い続けていたガラケーからAndroidのスマホに移行しました。これも時代の流れなのかと思います。人によってはスマホがあればPCは要らないとも言いますが、僕は逆にPCがあるのでスマホの利用は最小限にしておきたいです。
僕が最もスマホの利点を感じるのは、外出先でWebを参照したい場合です。ガラケーでもWebを参照できない訳ではありませんでしたが、あまり使いやすくはありませんでした。さらに最近では無料Wi-Fiの提供場所が増えてきつつあり、ありがたいと思います。スマホが登場する前から、世間ではラップトップPCやらノートPCやらを利用しようとしていましたが、手軽に利用できるとは言い難かったと思います。出先で多量の文書を書いたりするのであれば今でもノートPC以外の選択肢はないと思いますが、Webを見る程度であればスマホで十分ではないかと思います。
スマホでゲームをしたり音楽や動画を視聴したりすることは考えていないのですが、その代わりにスマホで何が出来るのかを探ろうと思っています。すると何とMaximaが使えるという情報を見つけました。
Maxima on Androidというアプリがあるようなのですが、『いつでも・どこでも・スマホで数学』（梅野 善雄）という本が森北出版から出ています。早速買ってみました。Maximaのマニュアル替わりにも使えそうです。
Maxima on Android（MoAと呼ぶらしい） では文字入力に「Std Math Keyboard」というアプリを使うのを推奨しているようです。その方が数式が入力しやすいそうなのですが、書籍の文章中にある画像を見ている限り、それほどでもなさそうな気がします。もっとも先入観では判断を誤るので、使ってみてから判断しようと思います。使いにくければ使わなければ良いだけのことです。
僕が最もスマホの利点を感じるのは、外出先でWebを参照したい場合です。ガラケーでもWebを参照できない訳ではありませんでしたが、あまり使いやすくはありませんでした。さらに最近では無料Wi-Fiの提供場所が増えてきつつあり、ありがたいと思います。スマホが登場する前から、世間ではラップトップPCやらノートPCやらを利用しようとしていましたが、手軽に利用できるとは言い難かったと思います。出先で多量の文書を書いたりするのであれば今でもノートPC以外の選択肢はないと思いますが、Webを見る程度であればスマホで十分ではないかと思います。
スマホでゲームをしたり音楽や動画を視聴したりすることは考えていないのですが、その代わりにスマホで何が出来るのかを探ろうと思っています。すると何とMaximaが使えるという情報を見つけました。
Maxima on Androidというアプリがあるようなのですが、『いつでも・どこでも・スマホで数学』（梅野 善雄）という本が森北出版から出ています。早速買ってみました。Maximaのマニュアル替わりにも使えそうです。
Maxima on Android（MoAと呼ぶらしい） では文字入力に「Std Math Keyboard」というアプリを使うのを推奨しているようです。その方が数式が入力しやすいそうなのですが、書籍の文章中にある画像を見ている限り、それほどでもなさそうな気がします。もっとも先入観では判断を誤るので、使ってみてから判断しようと思います。使いにくければ使わなければ良いだけのことです。
2019-10-28
スマホの連絡先とPC上のGoogleアカウントの連絡先
2019年11月末で利用していたガラケーの一部機能が使えなくなるとの連絡がきたので、スマホに機種変更しました。とにかく初体験なので、慣れない事ばかりです。設定は徐々にやっていけばいいのですが、少なくとも電話の受発信ができるようにしておくのは最優先です。
携帯で使っていた電話帳はmicroSDカード経由でスマホに持ち込みました。携帯の機能が旧いため、電話帳を全件保存することができず、1件ずつエクスポートしなければならなくて面倒でした。 スマホの連絡先に取り込んだ後は、Googleアカウントの連絡先と同期しようと思っています。同期させる設定は簡単ですが、Googleアカウント側で連絡先を編集すると、スマホ側の情報と齟齬が生じます。それは良いのですが、スマホ側の連絡先の表示が乱れてしまうので困ってしまいました。
結局スマホ側の連絡先の情報を全て消して、常にGoogleアカウント側の連絡先が参照されるようにして解決しました。
Googleアカウント側の連絡先をWindows10上で編集していて気付いたのですが、表示される項目（特にラベル）の見え方が、スマホ側と違います。またラベルを設定しても、スマホ側では参照できない箇所もあり、どのように使えばいいのか模索中です。
携帯で使っていた電話帳はmicroSDカード経由でスマホに持ち込みました。携帯の機能が旧いため、電話帳を全件保存することができず、1件ずつエクスポートしなければならなくて面倒でした。 スマホの連絡先に取り込んだ後は、Googleアカウントの連絡先と同期しようと思っています。同期させる設定は簡単ですが、Googleアカウント側で連絡先を編集すると、スマホ側の情報と齟齬が生じます。それは良いのですが、スマホ側の連絡先の表示が乱れてしまうので困ってしまいました。
結局スマホ側の連絡先の情報を全て消して、常にGoogleアカウント側の連絡先が参照されるようにして解決しました。
Googleアカウント側の連絡先をWindows10上で編集していて気付いたのですが、表示される項目（特にラベル）の見え方が、スマホ側と違います。またラベルを設定しても、スマホ側では参照できない箇所もあり、どのように使えばいいのか模索中です。
2019-10-17
キャロル・グラック『戦争の記憶』を読んで
Webで見かけた何かの記事で紹介されていた『戦争の記憶』（キャロル・グラック）を読んでみました。著者のCarol Gluckは日本近現代史などを専門としていますが、米国生まれです。日本近現代史を専門にしている理由は分かりません。
本書は副題に「コロンビア大学特別講義―学生との対話―」とあるように、学生の対話を活字化しているものです。「講義」と言っても、日本の大学のように学生が先生の講義を拝聴している訳ではなく、教師が学生に質問を投げかけると、学生同士が互いに議論を深めていくというスタイルです。
扱う話題は日本近現代史に関わる事柄ですが、学生側が（日本人もいるようですが）米国やアジアなど「世界中」からきています。流石に大学なので、議論で扱う内容について全く無知という事はなく、何らかの素養はあるはずです。しかし知識の深浅や、興味の対象などについて、日本人が日本近現代史について語る場合とは違った切り口からアプローチしているので、興味深いです。
「歴史的事実」という意味の歴史であれば、世界中どこでも同じはずです（とは言え、つい最近の事柄であってさえも「歴史的事実」を明らかにするのは、それほど容易ではありません）。しかし「歴史的事実」の幾つかを拾い出して再構成した「歴史の記憶」という意味の歴史では、そのような記憶が必要とされる事情が背後に潜んでいることが、本書で学べました。
本書は副題に「コロンビア大学特別講義―学生との対話―」とあるように、学生の対話を活字化しているものです。「講義」と言っても、日本の大学のように学生が先生の講義を拝聴している訳ではなく、教師が学生に質問を投げかけると、学生同士が互いに議論を深めていくというスタイルです。
扱う話題は日本近現代史に関わる事柄ですが、学生側が（日本人もいるようですが）米国やアジアなど「世界中」からきています。流石に大学なので、議論で扱う内容について全く無知という事はなく、何らかの素養はあるはずです。しかし知識の深浅や、興味の対象などについて、日本人が日本近現代史について語る場合とは違った切り口からアプローチしているので、興味深いです。
「歴史的事実」という意味の歴史であれば、世界中どこでも同じはずです（とは言え、つい最近の事柄であってさえも「歴史的事実」を明らかにするのは、それほど容易ではありません）。しかし「歴史的事実」の幾つかを拾い出して再構成した「歴史の記憶」という意味の歴史では、そのような記憶が必要とされる事情が背後に潜んでいることが、本書で学べました。
口癖
癖というのは自分では気づき難く、他人が気がつくと言われますが、口癖もそうでしょう。よく知られていることですが、話を「やっぱり、」で始める人がいます。テレビの街頭インタビューでも、何か意見を言うたびに、まず最初の一言が「やっぱり」から始まる人は、少なくありません。
こういう口癖は、気になるかと言えば、気にならなくもないのですが、それほど深刻に不快感がある訳ではありません。
これに比べると、開口一番に「いや、だから、」で始まる口癖は、もう少し強い嫌悪感があります。何かの意見を交わす場合でも、こちらの発言が終わり相手が話し始めるときに、まず「いや、だから、」と言われると、あまり良い気持ちはしません。
相手からすれば、単なる口癖に過ぎず、それほど意味がないのかもしれません。話始めるときに、ちょっと咳ばらいをするとか、（昔の大平首相のように）「えー」とか「あー」とか、何らかの音を出しているだけなのかもしれません。
ともかく、気にならない口癖と、気になる口癖は、あると思います。
こういう口癖は、気になるかと言えば、気にならなくもないのですが、それほど深刻に不快感がある訳ではありません。
これに比べると、開口一番に「いや、だから、」で始まる口癖は、もう少し強い嫌悪感があります。何かの意見を交わす場合でも、こちらの発言が終わり相手が話し始めるときに、まず「いや、だから、」と言われると、あまり良い気持ちはしません。
相手からすれば、単なる口癖に過ぎず、それほど意味がないのかもしれません。話始めるときに、ちょっと咳ばらいをするとか、（昔の大平首相のように）「えー」とか「あー」とか、何らかの音を出しているだけなのかもしれません。
ともかく、気にならない口癖と、気になる口癖は、あると思います。
2019-10-07
ネットワーク物理層における1500バイトの謎
TCP/IPの勉強をしようと思って『TCP/IP Illustrated, Volume 1』を買いました（古本ですが）。最初から順番に読んでいて、「2 Link Layer」を読み始めました。ここには「Figure 2.1 IEEE 802.2/802.3 encapsulation (RFC 1042) and Ethernet encapsulation (RFC 894)」が掲載されています。この図を見ると、IEEE構造では2バイトのlengthがあり、Ethernet構造には2バイトのtypeがあります。ここについて、本文では次のように書かれています。
混同されることがないのは「lengthで表されるデータ部の最大長が1,500である」という事実にかかっています。しかし最大長が1,500になっているのは「決め事」ではないのでしょう。どのような経緯で1,500になっているのか、気になるところです。
Fortunately none of the valid 802 length values is the same as the Ethernet type values, making the two frame formats distinguishable.これは要するに、Ethernetであればtypeに0x0800（IP datagramの場合）が入りますが、IEEEではlengthとして扱われるものの、0x0800を10進数に換算すると2,048になり最大長の1,500バイトを超えているので、現実的にはあり得ないという事だと思います。従ってtypeとlengthは異なる扱いをするフィールドでありながら、混同されることは無いという、よく考えると不思議な構造になっています。
混同されることがないのは「lengthで表されるデータ部の最大長が1,500である」という事実にかかっています。しかし最大長が1,500になっているのは「決め事」ではないのでしょう。どのような経緯で1,500になっているのか、気になるところです。
OSI参照モデルとリングプロテクション
コンピュータネットワークの勉強をすると「OSI参照モデル」の話が出てきます。物理層からアプリケーション層までの7層構造です。これは物理法則とは違うので、要するに「決め事」だと思います。今日の世界で最も普及していると思われるTCP/IPネットワークは4層で構成されています。それでもインターネットはうまくいっているようなので、7層でなければならない訳ではないと思います。しかし、あえて忠実に7層で実装したネットワークは、何があるのでしょうか。やはり7層でなければならない積極的な理由があるのでしょうか。気になります。
OSIの7層モデルを考えていたら、インテルのCPUは4レベルの「リングプロテクション」 を持っていることを思い出しました。しかし普及しているOSは、ユーザモードとカーネルモードしかないので、2レベルあれば十分な訳です。CPUを作る側として、もしかすると2レベル以上を必要とするOSが存在した場合に「インテルのCPUが選択される候補から落ちる」のを避けたかったのかもしれません。そうならば、4レベルと言わず、8レベルでも16レベルでも、もっとレベル数の多い（バームクーヘンみたいな）設計にすることも（観念的には）可能でしょうが、やたらとリングプロテクションのレベルを増やしても無駄ということでしょう。こちらも「決め事」ということなのだと思います。
OSIの7層モデルを考えていたら、インテルのCPUは4レベルの「リングプロテクション」 を持っていることを思い出しました。しかし普及しているOSは、ユーザモードとカーネルモードしかないので、2レベルあれば十分な訳です。CPUを作る側として、もしかすると2レベル以上を必要とするOSが存在した場合に「インテルのCPUが選択される候補から落ちる」のを避けたかったのかもしれません。そうならば、4レベルと言わず、8レベルでも16レベルでも、もっとレベル数の多い（バームクーヘンみたいな）設計にすることも（観念的には）可能でしょうが、やたらとリングプロテクションのレベルを増やしても無駄ということでしょう。こちらも「決め事」ということなのだと思います。
2019-10-04
Windows10 1903の不具合
自宅のデスクトップPCではWindows10を使用しています。約半年ごとに現れる更新も適用してきました。今春登場した1903もインストール出来次第インストールしようと思っていましたが、なかなか準備完了の通知が出てきません（これまではインストール準備ができましたというポップアップが出ていたので、それを待っていたのです）。遅いなと思っていたら、Webで「「Windows 10 May 2019 Update（バージョン1903）」がすべてのユーザーに対して解放」という記事を見つけました。そろそろポップアップが出るかと思ったら、一向に現れる気配がないので「設定」を見たところ、「準備が出来ています」というメッセージが出ていました。もうポップアップを出さないようになったのでしょうか？
ともかく1903をインストールできるようなので、空いている時間を見計らってインストールしました。多少時間はかかりましたが、問題なく終わりました。1903にあげてからログインして、普段の操作をしてみましたが、特に問題はなさそうでした。若干消えている設定はありましたが、許容範囲だし、今回の更新は無難に終了したと（当初は） 思いました。
1903が登場してから半年ほど過ぎているので、累積パッチがインストール準備中になっています。これを入れておこうとおもったのですが、どうやら、これをインストールしてから数々の不具合に遭遇する羽目になりました。
よく使うアプリケーションをタスクバーにピン留めしていたのですが、起動しなくなりました。この時点では軽微なトラブルかと思ったので、いったんピン留めを外して、再度ピン留めすれば良いと考えていました。ところが「タスクバーにピン留めする」というメニューは出るのに、タスクバーにアイコンが現れません。再起動しても同様です。ショートカットをドラッグして落としてみても駄目でした。
タスクバーにアプリケーションをピン留めしておかなくても、スタートメニューから起動するとか、デスクトップにショートカットを置いておくなどの対処も出来なくはありません。しかしよく使うアプリケーションだからこそ、素早く起動させようとしてタスクバーにピン留めしていたのです。もしかすると、将来のパッチで直るかもしれませんが、何時になるか分かりませんし、当面の対処方法としてQuick Launchを使うことにしました。これまでと同じように使うことができるので、これで良しとします。
さらに困ったのが「クイックリンク」が動かなくなったことです。スタートメニューにカーソルを持ってきて右クリックするか、WindowsロゴキーとXを同時に押すと、メニューが現れていたのに、これも全く動かなくなりました。これまではコマンドプロンプトを出すのに、この機能を頻繁に使っていたので、動かないとなるとスタートメニューから起動させることになりますが、厄介です。これも将来は修正されるかもしれませんが、何時のことになるでしょう。当面はQuick Launchでしのぐことになります。
気が付いているところでは、他にも妙なエラーダイアログが出てきますが、だからどうしろというんだという感想しかありません。対処法もないので、いつか直るのを待つしかなさそうです。
もしかすると気が付いていない不具合が他にも多々あるんじゃないかという気がしてきました。
ともかく1903をインストールできるようなので、空いている時間を見計らってインストールしました。多少時間はかかりましたが、問題なく終わりました。1903にあげてからログインして、普段の操作をしてみましたが、特に問題はなさそうでした。若干消えている設定はありましたが、許容範囲だし、今回の更新は無難に終了したと（当初は） 思いました。
1903が登場してから半年ほど過ぎているので、累積パッチがインストール準備中になっています。これを入れておこうとおもったのですが、どうやら、これをインストールしてから数々の不具合に遭遇する羽目になりました。
よく使うアプリケーションをタスクバーにピン留めしていたのですが、起動しなくなりました。この時点では軽微なトラブルかと思ったので、いったんピン留めを外して、再度ピン留めすれば良いと考えていました。ところが「タスクバーにピン留めする」というメニューは出るのに、タスクバーにアイコンが現れません。再起動しても同様です。ショートカットをドラッグして落としてみても駄目でした。
タスクバーにアプリケーションをピン留めしておかなくても、スタートメニューから起動するとか、デスクトップにショートカットを置いておくなどの対処も出来なくはありません。しかしよく使うアプリケーションだからこそ、素早く起動させようとしてタスクバーにピン留めしていたのです。もしかすると、将来のパッチで直るかもしれませんが、何時になるか分かりませんし、当面の対処方法としてQuick Launchを使うことにしました。これまでと同じように使うことができるので、これで良しとします。
さらに困ったのが「クイックリンク」が動かなくなったことです。スタートメニューにカーソルを持ってきて右クリックするか、WindowsロゴキーとXを同時に押すと、メニューが現れていたのに、これも全く動かなくなりました。これまではコマンドプロンプトを出すのに、この機能を頻繁に使っていたので、動かないとなるとスタートメニューから起動させることになりますが、厄介です。これも将来は修正されるかもしれませんが、何時のことになるでしょう。当面はQuick Launchでしのぐことになります。
気が付いているところでは、他にも妙なエラーダイアログが出てきますが、だからどうしろというんだという感想しかありません。対処法もないので、いつか直るのを待つしかなさそうです。
もしかすると気が付いていない不具合が他にも多々あるんじゃないかという気がしてきました。
2019-10-03
10月からスマホが値上がりした
現在はガラケーを使っていますが、今年（2019年）11月に一部機能が利用できなくなるという連絡が昨年末にありました。機能が全て利用できなくなる訳ではないようですが、問題が起きる可能性が残るので、機種変更してもらいたいようです。
これまでスマホを利用してきませんでしたが、これを機会にスマホにしようかと考えています。
これまでスマホにしてこなかった理由のひとつが、料金が高いことです。ガラケーは殆ど使っておらず、月々の支払いはとても安く済んでいます。一方でスマホにすると、これまでよりは月々の支払額がかなり高くなる恐れがあり、二の足を踏んでいました。ところが今年6月にガラケーからスマホに切り替える利用者向けの新プランが発表され、これまでのガラケーの支払額と同程度になる可能性がでてきました。
料金プランの問題が解決しそうなので、次に考えることは端末に何を選ぶかです。それほどヘビーな使い方はしないと思うので、10万以上もするような端末を選ぶ必要はありません。しかし激安な端末にするのも躊躇するところです。どうしようかと公式サイトを見ていたら、数年前にはフラッグシップモデルだったものが、新製品が出たことにより値段が下がっている端末を見つけました。同メーカのエントリモデルが3万弱なのに比べ、旧いフラッグシップモデルが3万強だったので、これに決めようと考えていました。
総務省の指導なのか、9月には契約の2年縛りがないプランが始まりました。11月までにはガラケーからスマホに切り替える必要があるので、スケジュールに余裕がありそうな10月下旬頃にはスマホに切り替えようと思っていました。
10月になり、回線と端末のセット割引が禁止されたそうで、スマホの値段が変わりました。改めて値段を確認すると、旧いフラッグシップモデルは10万弱に値上がりしていました。エントリモデルの方は相変わらず3万弱でした。ここまで価格差が拡がってしまうと、手を出せないところです。
9月中に機種変更を済ませてしまえば安く買えたのでしょうけれども、過ぎたことを悔やんでも、今更どうすることも出来ません。もしかすると再び値下がりして購入できる価格帯に入ってくるかもしれません。今後に希望をみていきたいと思います。
これまでスマホを利用してきませんでしたが、これを機会にスマホにしようかと考えています。
これまでスマホにしてこなかった理由のひとつが、料金が高いことです。ガラケーは殆ど使っておらず、月々の支払いはとても安く済んでいます。一方でスマホにすると、これまでよりは月々の支払額がかなり高くなる恐れがあり、二の足を踏んでいました。ところが今年6月にガラケーからスマホに切り替える利用者向けの新プランが発表され、これまでのガラケーの支払額と同程度になる可能性がでてきました。
料金プランの問題が解決しそうなので、次に考えることは端末に何を選ぶかです。それほどヘビーな使い方はしないと思うので、10万以上もするような端末を選ぶ必要はありません。しかし激安な端末にするのも躊躇するところです。どうしようかと公式サイトを見ていたら、数年前にはフラッグシップモデルだったものが、新製品が出たことにより値段が下がっている端末を見つけました。同メーカのエントリモデルが3万弱なのに比べ、旧いフラッグシップモデルが3万強だったので、これに決めようと考えていました。
総務省の指導なのか、9月には契約の2年縛りがないプランが始まりました。11月までにはガラケーからスマホに切り替える必要があるので、スケジュールに余裕がありそうな10月下旬頃にはスマホに切り替えようと思っていました。
10月になり、回線と端末のセット割引が禁止されたそうで、スマホの値段が変わりました。改めて値段を確認すると、旧いフラッグシップモデルは10万弱に値上がりしていました。エントリモデルの方は相変わらず3万弱でした。ここまで価格差が拡がってしまうと、手を出せないところです。
9月中に機種変更を済ませてしまえば安く買えたのでしょうけれども、過ぎたことを悔やんでも、今更どうすることも出来ません。もしかすると再び値下がりして購入できる価格帯に入ってくるかもしれません。今後に希望をみていきたいと思います。
2019-09-30
プライド≠pride
日本語では外国由来の単語をカタカナで表記しています。しかしその外来語が具体的な事物であるならいざ知らず、抽象的な概念を表している場合にはカタカナで表記される外来語が元々の国での意味と同じかどうかは分かりません。またその外来語を使って発信している側も、その外来語を受け取る側も、はたして意味を同じように認識しているでしょうか。
例えばカタカナで「プライド」と表記するのは、英単語「pride」のことです。この単語は文中で「誰々はプライドが高いから云々」のように使われます。この外来語を使う側も受け取る側も、なんだか文意がわかったような気になりますが、本当にわかっているでしょうか。
外来語「プライド」ではなく日本語で表現するなら「自尊心」という概念があてはまります。ここで「自尊心」という抽象概念が何を指しているのかという問題が派生しますが、それは別途考えることにして、ここでは踏み込まないことにします。
外来語「プライド」の日本語表現はそれだけではありません。英単語「pride」を日本語に直接的に訳語にあてはめただけでなく、外来語「プライド」として意味が派生したものとして「選民意識」という概念もあるのではないかと考えています。
「自尊心」と「選民意識」とでは、受け取る側からすれば相当ニュアンスが異なります。しかし発信側が外来語「プライド」として表現しただけでは、どのような意味で語っているか、実際のところわかりません。
普段の会話では、ここまで厳格に考える必要はないでしょう。でも曖昧さを残す余地がある表現を（もしかすると意図的に）使うのは、コミュニケーションを壊す要因になると思います。
例えばカタカナで「プライド」と表記するのは、英単語「pride」のことです。この単語は文中で「誰々はプライドが高いから云々」のように使われます。この外来語を使う側も受け取る側も、なんだか文意がわかったような気になりますが、本当にわかっているでしょうか。
外来語「プライド」ではなく日本語で表現するなら「自尊心」という概念があてはまります。ここで「自尊心」という抽象概念が何を指しているのかという問題が派生しますが、それは別途考えることにして、ここでは踏み込まないことにします。
外来語「プライド」の日本語表現はそれだけではありません。英単語「pride」を日本語に直接的に訳語にあてはめただけでなく、外来語「プライド」として意味が派生したものとして「選民意識」という概念もあるのではないかと考えています。
「自尊心」と「選民意識」とでは、受け取る側からすれば相当ニュアンスが異なります。しかし発信側が外来語「プライド」として表現しただけでは、どのような意味で語っているか、実際のところわかりません。
普段の会話では、ここまで厳格に考える必要はないでしょう。でも曖昧さを残す余地がある表現を（もしかすると意図的に）使うのは、コミュニケーションを壊す要因になると思います。
2019-09-29
第243回TOEIC公開テストを受験しました
今日が受験日でした。何かの直接的な目的があるという訳ではなく、英語能力を確認するために10年以上前から毎年この時期にTOEICを受験することにしています。
TOEICに対する批判があることは承知しています。TOEICで得点がとれても英語ができる訳ではないとか、TOEICは受験テクニックで点数がとれてしまうなどの主張があるようです。それは一理あるのかもしれませんし、そういう側面もあるでしょう。しかし英語能力が無いのに、TOEICテクニックだけで高得点を得るというのは「おとぎ話」だと思います。どんな資格試験でも、同じことでしょう。
TOEICを受験すると、いつも思うことですが、時間が圧倒的に足りません。いつも最後の20問ほどは解答する時間が無くて「塗り絵」になってしまいます。TOEICで高得点を得ることも（ある意味で）目標ではありますが、少なくとも試験時間内に全問を解答できるようになることの方が、切実な目標です。
TOEICに対する批判があることは承知しています。TOEICで得点がとれても英語ができる訳ではないとか、TOEICは受験テクニックで点数がとれてしまうなどの主張があるようです。それは一理あるのかもしれませんし、そういう側面もあるでしょう。しかし英語能力が無いのに、TOEICテクニックだけで高得点を得るというのは「おとぎ話」だと思います。どんな資格試験でも、同じことでしょう。
TOEICを受験すると、いつも思うことですが、時間が圧倒的に足りません。いつも最後の20問ほどは解答する時間が無くて「塗り絵」になってしまいます。TOEICで高得点を得ることも（ある意味で）目標ではありますが、少なくとも試験時間内に全問を解答できるようになることの方が、切実な目標です。
2019-09-24
.set NHRDRV,0x475 # Number of hard drives
『FreeBSDのブートプロセスをみる』（白崎博生、UNIX MAGAZINE COLLECTION、2006年）を追体験しながら、カーネルを勉強しています。カーネルデバッグができる環境をVirtualBoxを使って構築したので、第1回「Boot Manager」から順番に読んでいきます。
大雑把に言うとboot0は、BIOSによってディスクから読み込まれ、boot1を読んで制御を渡すのが、主な役割です。その他にも処理がありますが、歴史的な事情によりINT 13Hの呼び出し方法が違うなどであり（それだけではありませんが）、ざっと眺めておくだけにします。
しかしながら、それほど重要というほどではありませんが、気になったのは、BIOSのデータエリア0x475番地を参照している箇所です。
boot0.Sでは「.set NHRDRV,0x475 # Number of hard drives」のようにシンボルが定義されており、以下のようなコメントも入っています。
このような情報はWebを検索すると見つかったりします。しかし得てして何かの情報の孫引きだったりするので、最もオリジナルの一次情報を見つけたいところですが、それはなかなか見つかりません。そもそもBIOSにおける非公開（に準じる）情報だったりすると、オリジナルの情報にはアクセスできないことになります。せめて次善の策として、BIOSの内部構造を詳述した定評のある書籍などの記述を参照しておきたいところです。
大雑把に言うとboot0は、BIOSによってディスクから読み込まれ、boot1を読んで制御を渡すのが、主な役割です。その他にも処理がありますが、歴史的な事情によりINT 13Hの呼び出し方法が違うなどであり（それだけではありませんが）、ざっと眺めておくだけにします。
しかしながら、それほど重要というほどではありませんが、気になったのは、BIOSのデータエリア0x475番地を参照している箇所です。
boot0.Sでは「.set NHRDRV,0x475 # Number of hard drives」のようにシンボルが定義されており、以下のようなコメントも入っています。
121 * NHRDRV is the address in segment 0 where the BIOS writes the
122 * total number of hard disks in the system.
このような情報はWebを検索すると見つかったりします。しかし得てして何かの情報の孫引きだったりするので、最もオリジナルの一次情報を見つけたいところですが、それはなかなか見つかりません。そもそもBIOSにおける非公開（に準じる）情報だったりすると、オリジナルの情報にはアクセスできないことになります。せめて次善の策として、BIOSの内部構造を詳述した定評のある書籍などの記述を参照しておきたいところです。
2019-09-23
『FreeBSDのブートプロセスをみる』（白崎博生、UNIX MAGAZINE COLLECTION、2006年）を追体験しながら、カーネルを勉強することにしました。まず最初にカーネルのリモートデバッグができる環境をVirtualBoxを使って準備しました。書籍ではFreeBSD 5.1が使われていますが、今更古いバージョンを用意するのもなんなので、最新のFreeBSD 12.0を使うつもりです。記事の記述とは合わないところが出てくるかもしれませんが、それも含めて勉強です。
まずは第1回「Boot Manager」から始めます。記事ではboot0のソースがboot/i386/boot0/boot0.sと書かれていますが、stand/i386/boot0/boot0.Sに変わっていました。コメントも記事とは変わっているようですが、ロジックは変化していません。
まず最初に「自分自身を00600Hへ移動する」処理があります。レジスタを適切に設定してrepプレフィックスをつけたmovswで転送する訳ですが、ここで疑問が生じました。該当箇所は次のようになっています。
ここでSIレジスタには転送元、DIレジスタには転送先が入っています。$LOADというのは、上述したソースコードのちょっと前で「.set LOAD,0x7c00」のように定義されています。しかし$startというのはラベルとして定義されているだけです。しかもコードの最初にあるので0x0000ではないのでしょうか。どうして0x0600として扱われるのでしょうか。すくなくとも、このファイルには（コメントに0x600と書かれているだけで）なんの定義もありません。これが疑問でした。
Webを検索しても、boot0を解説している情報は幾つか見つかりますが、この疑問に答えてくれる情報がなかなか見つかりませんでした。
Webで検索を続けていると『FreeBSD Architecture Handbook』に次のような記述があることを知りました。
まずは第1回「Boot Manager」から始めます。記事ではboot0のソースがboot/i386/boot0/boot0.sと書かれていますが、stand/i386/boot0/boot0.Sに変わっていました。コメントも記事とは変わっているようですが、ロジックは変化していません。
まず最初に「自分自身を00600Hへ移動する」処理があります。レジスタを適切に設定してrepプレフィックスをつけたmovswで転送する訳ですが、ここで疑問が生じました。該当箇所は次のようになっています。
181 start: cld # String ops inc
182 xorw %ax,%ax # Zero
183 movw %ax,%es # Address
184 movw %ax,%ds # data
185 movw %ax,%ss # Set up
186 movw $LOAD,%sp # stack
187
188 /*
189 * Copy this code to the address it was linked for, 0x600 by default.
190 */
191 movw %sp,%si # Source
192 movw $start,%di # Destination
ここでSIレジスタには転送元、DIレジスタには転送先が入っています。$LOADというのは、上述したソースコードのちょっと前で「.set LOAD,0x7c00」のように定義されています。しかし$startというのはラベルとして定義されているだけです。しかもコードの最初にあるので0x0000ではないのでしょうか。どうして0x0600として扱われるのでしょうか。すくなくとも、このファイルには（コメントに0x600と書かれているだけで）なんの定義もありません。これが疑問でした。
Webを検索しても、boot0を解説している情報は幾つか見つかりますが、この疑問に答えてくれる情報がなかなか見つかりませんでした。
Webで検索を続けていると『FreeBSD Architecture Handbook』に次のような記述があることを知りました。
It is worth looking at the Makefile for boot0 (sys/boot/i386/boot0/Makefile ), as it defines some of the runtime behavior of boot0. For instance, if a terminal connected to the serial port (COM1) is used for I/O, the macro SIO must be defined (-DSIO). -DPXE enables boot through PXE by pressing F6. Additionally, the program defines a set of flags that allow further modification of its behavior. All of this is illustrated in the Makefile. For example, look at the linker directives which command the linker to start the text section at address 0x600, and to build the output file “as is” (strip out any file formatting):そしてMakefileでは以下のように記述されていると書かれています。
BOOT_BOOT0_ORG?=0x600そういうことなのか、と思いましたが、Makefileには次のような記述があるだけでした。
LDFLAGS=-e start -Ttext ${BOOT_BOOT0_ORG} \
-Wl,-N,-S,--oformat,binary
BOOT_BOOT0_ORG?= 0x600考え方は変わっていないのだと思いますが、実現方法が変わったのでしょう。今回は、そこまでは追いかけませんでした。しかしともすれば見過ごしてしまう点を追及できました。
ORG=${BOOT_BOOT0_ORG}
2019-09-22
FreeBSDのカーネルのリモートデバッグをおこなう
『FreeBSDのブートプロセスをみる』（白崎博生、UNIX MAGAZINE COLLECTION、2006年）を追体験しながら、カーネルを勉強しようと考えています。連載当時はFreeBSD 5.1でしたが、今はFreeBSD 12.0です。細かいところで記述内容と合わない点があります。まずは連載最後の17回を参考に、カーネルデバッグの環境を整えておこうと思います。
カーネルデバッガDDBが起動できるようなカーネルに入れ換える作業は、特に問題ありませんでした。
つぎはリモートデバッグの環境を準備しようと思います。書籍の記述ではVMwareを利用していますが、僕はVirtualBoxを使おうと思います。VMwareだろうが、VirtualBoxだろうが、もしくは仮想環境ではなく実機であろうが、考え方は変わらない筈です。その筈なのですが、当初うまくいかず苦労してしまいました。しかし最終的にリモートデバッグ環境ができたので、結果オーライという感じです。
もし実機を使ってリモートデバッグ環境を整えるなら、2台のマシン間をRS-232Cのヌルモデムケーブルで繋ぐことになるでしょう。仮想環境であれば、2台のゲスト環境のCOM1ポートを「仮想的」に接続されているように見せかける必要があります。それが連載記事でも紹介されている、名前付きパイプを使用する方法です。記事ではVMwareの設定としてシリアルポートを名前付きパイプとして設定しています。VirtualBoxでもシリアルポートを名前付きパイプとして設定できるので、当初この方法で2台のゲスト環境を接続するつもりでした。ところがうまくいきません。どううまくいかないかというと、リモートデバッグ環境からターゲット側への接続ができないというエラーが出てしまうのです。そもそもVirtualBoxでは無理なのかと思いましたが、Webで「Freebsd kernel remote debugging. Part1」という情報を発見しました。バージョンが書かれていませんが、成功した事例と言えるでしょう。
VirtualBoxではなくQEMUを使った事例として「FreeBSDのオンラインカーネルデバッグ with QEMU」という情報も見つけました。こちらはQEMUにしかない機能を利用しているので、同じことをVirtualBoxで実現することはできませんが、参考になります。
最終的にVirtualBoxの設定を次のようにすることでリモートデバッグ環境が出来上がりました。
上述した設定をして「ターゲット」と「デバッガ」のゲスト環境を起動します。「ターゲット」でログインプロンプトが出たら、CtrlとPrintScrキーを同時に押してカーネルデバッガに入ります。そして「gdb」コマンドを入力してリモートからの接続を待機させます。
試しにシステムコール「sys_mkdir」にブレークポイントを仕掛けてみます。そして「ターゲット」のコマンドラインでコマンド「mkdir」を実行しようとすると、ブレークポイントで停止してくれました。成功です。
カーネルデバッガDDBが起動できるようなカーネルに入れ換える作業は、特に問題ありませんでした。
つぎはリモートデバッグの環境を準備しようと思います。書籍の記述ではVMwareを利用していますが、僕はVirtualBoxを使おうと思います。VMwareだろうが、VirtualBoxだろうが、もしくは仮想環境ではなく実機であろうが、考え方は変わらない筈です。その筈なのですが、当初うまくいかず苦労してしまいました。しかし最終的にリモートデバッグ環境ができたので、結果オーライという感じです。
もし実機を使ってリモートデバッグ環境を整えるなら、2台のマシン間をRS-232Cのヌルモデムケーブルで繋ぐことになるでしょう。仮想環境であれば、2台のゲスト環境のCOM1ポートを「仮想的」に接続されているように見せかける必要があります。それが連載記事でも紹介されている、名前付きパイプを使用する方法です。記事ではVMwareの設定としてシリアルポートを名前付きパイプとして設定しています。VirtualBoxでもシリアルポートを名前付きパイプとして設定できるので、当初この方法で2台のゲスト環境を接続するつもりでした。ところがうまくいきません。どううまくいかないかというと、リモートデバッグ環境からターゲット側への接続ができないというエラーが出てしまうのです。そもそもVirtualBoxでは無理なのかと思いましたが、Webで「Freebsd kernel remote debugging. Part1」という情報を発見しました。バージョンが書かれていませんが、成功した事例と言えるでしょう。
VirtualBoxではなくQEMUを使った事例として「FreeBSDのオンラインカーネルデバッグ with QEMU」という情報も見つけました。こちらはQEMUにしかない機能を利用しているので、同じことをVirtualBoxで実現することはできませんが、参考になります。
最終的にVirtualBoxの設定を次のようにすることでリモートデバッグ環境が出来上がりました。
- 使用したVirtualBoxは「バージョン 6.0.12 r133076 (Qt5.6.2)」です。
- FreeBSDのカーネルデバッグされる側を「ターゲット」と呼ぶことにします。
- GDBでデバッグコマンドを操作する側を「デバッガ」と呼ぶことにします。
- 「ターゲット」ではVirtualBoxでシリアルポートを利用できるように設定しておきます。
- 「ポートモード」を「TCP」にします。
- 「存在するパイプ／ソケットに接続」のチェックを外します。
- 「パス／アドレス」を設定します。他のアプリケーションと衝突しなければなんでも良いでしょう。僕は「35790」にしました。
- 「デバッガ」ではシリアルポートを使わないので、有効にする必要はありません。
上述した設定をして「ターゲット」と「デバッガ」のゲスト環境を起動します。「ターゲット」でログインプロンプトが出たら、CtrlとPrintScrキーを同時に押してカーネルデバッガに入ります。そして「gdb」コマンドを入力してリモートからの接続を待機させます。
FreeBSD/amd64 (target) (ttyv0)一方「デバッガ」ではgdbを起動し、「ターゲット」に接続します。ここで接続先の指定はTCP/IPアドレスとポート番号を使用します。注意が必要なのは、TCP/IPアドレスは、「ターゲット」のゲスト環境のFreeBSDに割り当てられたアドレスではなく、ホスト環境であるWindows10のアドレスです。
login: KDB: enter: manual escape to debugger
[ thread pid 12 tid 100006 ]
Stopped at 0xffffffff80bf955b = kdb_enter+0x3b: moveq $0,0xffffffff81f7cbe8 = kdb_why
db> gdb
(ctrl-c will return control to ddb)
Switching to gdb back-end
furusawa@debugger:~ % kgdb /boot/kernel/kernelこのように「ターゲット」と「デバッガ」の接続が確立されました。これでリモートデバッグ環境が出来たことになります。
GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /boot/kernel/kernel.debug...
(kgdb) target remote 192.168.1.14:35790
Remote debugging using 192.168.1.14:35790
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /boot/kernel/intpm.ko...
warning: the debug information found in "/usr/lib/debug//boot/kernel/intpm.ko.debug" does not match "/boot/kernel/intpm.ko" (CRC mismatch).
(No debugging symbols found in /boot/kernel/intpm.ko)
Reading symbols from /boot/kernel/smbus.ko...
warning: the debug information found in "/usr/lib/debug//boot/kernel/smbus.ko.debug" does not match "/boot/kernel/smbus.ko" (CRC mismatch).
(No debugging symbols found in /boot/kernel/smbus.ko)
kdb_enter (why=0xffffffff812fae28 "break", msg=<optimized out>)
at /usr/src/sys/kern/subr_kdb.c:479
479 kdb_why = KDB_WHY_UNSET;
(kgdb)
試しにシステムコール「sys_mkdir」にブレークポイントを仕掛けてみます。そして「ターゲット」のコマンドラインでコマンド「mkdir」を実行しようとすると、ブレークポイントで停止してくれました。成功です。
(kgdb) b sys_mkdirこれでFreeBSDのカーネルをリモートデバッグするための環境が手に入りました。この環境を利用して『FreeBSDのブートプロセスをみる』を読んでいこうと思います。
Breakpoint 1 at 0xffffffff80c90614: file /usr/src/sys/kern/vfs_syscalls.c, line 3582.
(kgdb) c
Continuing.
[New Thread 100086]
[New Thread 100063]
[Switching to Thread 100086]
Thread 78 hit Breakpoint 1, sys_mkdir (td=0xfffff80003fd8580,
uap=0xfffff80003fd8940) at /usr/src/sys/kern/vfs_syscalls.c:3582
3582 return (kern_mkdirat(td, AT_FDCWD, uap->path, UIO_USERSPACE,
(kgdb) list
3577 #endif
3578 int
3579 sys_mkdir(struct thread *td, struct mkdir_args *uap)
3580 {
3581
3582 return (kern_mkdirat(td, AT_FDCWD, uap->path, UIO_USERSPACE,
3583 uap->mode));
3584 }
3585
3586 #ifndef _SYS_SYSPROTO_H_
(kgdb) c
Continuing.
2019-09-20
FreeBSDでカーネルデバッガを使ってみる
カーネルを勉強をしてみたいと以前から考えていましたが、どこから手をつければ良いのか、迷っていました。独習するとしても、何か伴走してくれるような参考書があると助かります。そこで手持ちの書籍から『FreeBSDのブートプロセスをみる』（白崎博生、ASCII、2006年）の辿った道程を追体験していきながら、カーネルになじんでいくことにしました。
この本はUNIX MAGAZINEの連載をまとめたものですが、もう15年ほど前に執筆されたので対象となるFreeBSDはバージョン5.1です。いろいろと変わったところもあるでしょうが、枝葉末節を気にしなければ、大筋は変わっていないかもしれません。それは別にどちらでもよくて、変化していても、変化していなくても、それを踏まえて、カーネルの世界を歩いていく練習をするのが目的です。
学ぶ環境はVirtualBox上に構築することにします。まずは連載最終回の第17回「カーネルデバッガ」の手順を追体験してみます。
カーネルデバッガを使えるようにする基本的は変わっていないようですが、指定できるオプションがFreeBSD 12では違いがありました。またカーネル構築手順も違っています。
カーネル定義ファイルは、記事同様に「UMKERNEL」としておきます（これはUnix MagazineのKernelという意味なのでしょう）。記事では既存のカーネル定義ファイル（GENERICなど）を変更して作成することが想定されているようですが、今回は次のようなファイルを新規に作成しました。これはFreeBSDハンドブックの「8.4. コンフィグレーションファイル」に書いてあることに倣ったものです。
ひとまず、ここまでは成功です。次はリモートデバッグに挑戦してみようと思います。すでに実験しているところです。概念は難しくないのですが、うまくいきません。記事ではVMwareを利用していますが、僕はVirtualBoxにしようと思っています。それが手強い原因とも思えませんが、なんとか解決したいと思います。
この本はUNIX MAGAZINEの連載をまとめたものですが、もう15年ほど前に執筆されたので対象となるFreeBSDはバージョン5.1です。いろいろと変わったところもあるでしょうが、枝葉末節を気にしなければ、大筋は変わっていないかもしれません。それは別にどちらでもよくて、変化していても、変化していなくても、それを踏まえて、カーネルの世界を歩いていく練習をするのが目的です。
学ぶ環境はVirtualBox上に構築することにします。まずは連載最終回の第17回「カーネルデバッガ」の手順を追体験してみます。
カーネルデバッガを使えるようにする基本的は変わっていないようですが、指定できるオプションがFreeBSD 12では違いがありました。またカーネル構築手順も違っています。
カーネル定義ファイルは、記事同様に「UMKERNEL」としておきます（これはUnix MagazineのKernelという意味なのでしょう）。記事では既存のカーネル定義ファイル（GENERICなど）を変更して作成することが想定されているようですが、今回は次のようなファイルを新規に作成しました。これはFreeBSDハンドブックの「8.4. コンフィグレーションファイル」に書いてあることに倣ったものです。
include GENERICカーネルのコンパイル方法も違っています。記事にあるのは伝統的なBSDにおけるカーネルコンパイル方法ですが、「8.5. カスタムカーネルの構築とインストール」に倣って、次のようにしました。コンパイルに1時間半ほどかかりました。
ident UMKERNEL
options DDB
options DDB_NUMSYM
options GDB
# cd /usr/srcカーネルを入れ替えたら、再起動します。記事では「DDBの呼び出し方」として5種類あると書かれていますが、このあたりも今は若干違うようです。記事にも書いてある最初の手順「キーボードのCtrlとPrtScキーを同時に押す」を実行したところ、カーネルデバッガに入ることが出来ました。
# make buildkernel KERNCONF=UMKERNEL
# make installkernel KERNCONF=UMKERNEL
ひとまず、ここまでは成功です。次はリモートデバッグに挑戦してみようと思います。すでに実験しているところです。概念は難しくないのですが、うまくいきません。記事ではVMwareを利用していますが、僕はVirtualBoxにしようと思っています。それが手強い原因とも思えませんが、なんとか解決したいと思います。
2019-09-18
OSのカーネルを理解するには？
OSのカーネルを理解したいと昔から考えていました。このように考えている人は世間に多いようで、いろいろな書籍が出ていますし、Webにも情報が溢れています。しかし、まがりなりにも最後まで到達したという情報は少なく、多くは三日坊主です。
またOSの選択も多様です。最も多いのがLinuxのカーネルを素材とする場合です。その他にはBSD系やUNIX V6などもありますが、あまり活発ではありません。
もう20年以上前の1996年10月30日に当時のネットニュースfj.os.bsd.freebsdに西村享さん（奈良先端科学技術大学院大学情報科学センター） が投稿した記事があり、参考になると思っています。その記事によると、FreeBSDのカーネルを読もうとした或る人物の投稿への返信として、次のように語っています。
さらに『4.3BSDの設計と実装』を読もうとしていることに対して、次のように語っています。（原文ママ）
閑話休題。カーネルのソースは、LinuxでもBSD系（FreeBSD、NetBSD、OpenBSD）でも容易に入手できます。どれを読むか悩むところですが、個人的にはBSD系を選ぼうと思います。NetBSDの情報が多いような気もしますが、FreeBSDにしようかと考えているところです。
カーネルは大規模ですが、全体を区分すれば、ボリューム的に大部分を占めるのはデバイスドライバではないかと思います。またファイルシステム、ネットワークスタック、ブートストラップ、システムコールなどの構成要素に分割できると思うので、一つずつ取り組んでいけば（大変だとは思いますが）無謀な取り組みでもないと思っています。
またOSの選択も多様です。最も多いのがLinuxのカーネルを素材とする場合です。その他にはBSD系やUNIX V6などもありますが、あまり活発ではありません。
もう20年以上前の1996年10月30日に当時のネットニュースfj.os.bsd.freebsdに西村享さん（奈良先端科学技術大学院大学情報科学センター） が投稿した記事があり、参考になると思っています。その記事によると、FreeBSDのカーネルを読もうとした或る人物の投稿への返信として、次のように語っています。
大学院生のソース読み輪講につきあったことがあるのですが、彼らも同じような非効率なアプローチを取りました。システムコールが呼ばれた時の制御の流れや、コンテキストスイッチとはCPUの何をどうすることかなど、超基本的な知識を咀嚼できてない状態で「生のOS」のソースコードに手を出すのは難がある（ひどく遠回りをするという意味）ように思います。
さらに『4.3BSDの設計と実装』を読もうとしていることに対して、次のように語っています。（原文ママ）
他の方も指摘されていますが、改訂版もでています。私は旧版新版どちらもお奨めしません。なぜなら、よく誤解されているようですが、入門書でないからです。以前comp.os.*なしがしだったかで、これらを評して「too dry」だとの発言を見たことがあります。私もまったくその通りだと思います。これらの本に書いてあることを理解するには、まずソースコードを読んでおくことが先決です。「UNIXカーネルの全体像を得る」 などという目的でこれらの本に取り組むとおそらく自滅するでしょう。それらは前提知識の範疇に含まれるように思います。
閑話休題。カーネルのソースは、LinuxでもBSD系（FreeBSD、NetBSD、OpenBSD）でも容易に入手できます。どれを読むか悩むところですが、個人的にはBSD系を選ぼうと思います。NetBSDの情報が多いような気もしますが、FreeBSDにしようかと考えているところです。
カーネルは大規模ですが、全体を区分すれば、ボリューム的に大部分を占めるのはデバイスドライバではないかと思います。またファイルシステム、ネットワークスタック、ブートストラップ、システムコールなどの構成要素に分割できると思うので、一つずつ取り組んでいけば（大変だとは思いますが）無謀な取り組みでもないと思っています。
TCP/IPの教科書
TCP/IPの挙動について理解したいと思い、パケットの状況をwiresharkで調査してみました。このようなツールを使えば現実の通信状況が見えるので、とても理解がすすむのですが、基礎的な理解ができていないと行き詰まってしまいます。
TCP/IPの基本について学んでおこうと思います。TCP/IPの入門書は多数出版されているものの、その多くは入門的すぎて満足できません。その中でも定評があるのが次のシリーズです。
どちらも3巻組で、第1巻がプロトコル、第2巻が実装、第3巻がアプリケーションになっています。詳しく記述されているのでページ数も多く、値段も高いです。これらのシリーズは以前から知っていたのですが、値段もネックだし、どちらを選ぶかも迷っていて、入手していませんでした。
迷っているだけでは、いつまでたっても進歩しないので、思い切って両シリーズの第1巻を買うことにしました。翻訳書だと、中古本であっても、両方合わせて1万円以上するので、さすがに躊躇します。そこで旧版の原書をabebooks経由で購入することにしました。
例えば「Internetworking with TCP/IP Volume 1 : Principles, Protocols, and Architecture」は新版もありますが、旧版なら$1でした。しかし送料は別に必要ですが、合計しても10ドル以下なので、円換算しても千円以下です。
到着まで時間がかかるのが難点です。しかし急ぐわけでもないので、ゆっくり待とうと思います。
TCP/IPの基本について学んでおこうと思います。TCP/IPの入門書は多数出版されているものの、その多くは入門的すぎて満足できません。その中でも定評があるのが次のシリーズです。
どちらも3巻組で、第1巻がプロトコル、第2巻が実装、第3巻がアプリケーションになっています。詳しく記述されているのでページ数も多く、値段も高いです。これらのシリーズは以前から知っていたのですが、値段もネックだし、どちらを選ぶかも迷っていて、入手していませんでした。
迷っているだけでは、いつまでたっても進歩しないので、思い切って両シリーズの第1巻を買うことにしました。翻訳書だと、中古本であっても、両方合わせて1万円以上するので、さすがに躊躇します。そこで旧版の原書をabebooks経由で購入することにしました。
例えば「Internetworking with TCP/IP Volume 1 : Principles, Protocols, and Architecture」は新版もありますが、旧版なら$1でした。しかし送料は別に必要ですが、合計しても10ドル以下なので、円換算しても千円以下です。
到着まで時間がかかるのが難点です。しかし急ぐわけでもないので、ゆっくり待とうと思います。
2019-08-30
VirtualBoxではkdumpが動かないのか
つい先日、VirtualBox上にCentOS7の環境を作りkdumpが動作するか確認しました。するとCentOS 7.0～7.6まで（症状が多少違うところもありますが）全て失敗したので、CentOSでkdumpが動かないものだと判断してしまいました。
しかしWeb上で見つけた情報「カーネルクラッシュダンプの基本や取り方など」によると、CentOS 7.6でkdumpが動いているようです。それならばVirtualBoxで動かないのは、CentOSの問題ではなく、VirtualBoxの問題ということになります。
試しにVMware Workstation Player上にCentOS7の環境を作って、kdumpの実験をしてみました。するとkdumpが動くのです。やはりCentOSの問題ではなく、VirtualBoxの問題だったのでしょう。しかし未だに疑問なのは、VirtualBoxでkdumpできないのは、僕だけなのか、世間一般でそうなのかという事です。VirtualBoxの既知のバグで動かないのであれば、将来のバージョンで動くようになるかもしれません。しかし、何か設定をすることでkdumpできるようにするTipsがあるのであれば、ぜひ知りたいと思います。
それにしても、何が問題なのか情報がないと、調査の糸口も掴めません。CentOSは、旧いOSのように起動時にメッセージがズラズラと出てこないので、何が悪いのか判断する情報が得られないのです。昔は起動時に長々とメッセージがコンソールに流れていましたが、一般受けしないので出さなくする傾向にあるのだと思います。
なんとか情報が得られないかと調べていたら、GRUB2のブートメニューで編集モードに入り、パラメータを変えれば良いようです。パラメータ「rhgb quiet」の指定を消せば昔のOSのように起動ログが出てくるようになります。また更に詳しい情報が必要ならパラメータ「loglevel=7 systemd.log_level=debug」を指定すれば、もっと詳しく情報が出てきます。
この指定をおこなってVirtualBoxでkdumpを起動しようとしたところ、2nd kernelの起動ログが出る前にVirtualBox自体が落ちてしまいました。そもそも2nd kernelに制御が渡っていないようです。
しかしWeb上で見つけた情報「カーネルクラッシュダンプの基本や取り方など」によると、CentOS 7.6でkdumpが動いているようです。それならばVirtualBoxで動かないのは、CentOSの問題ではなく、VirtualBoxの問題ということになります。
試しにVMware Workstation Player上にCentOS7の環境を作って、kdumpの実験をしてみました。するとkdumpが動くのです。やはりCentOSの問題ではなく、VirtualBoxの問題だったのでしょう。しかし未だに疑問なのは、VirtualBoxでkdumpできないのは、僕だけなのか、世間一般でそうなのかという事です。VirtualBoxの既知のバグで動かないのであれば、将来のバージョンで動くようになるかもしれません。しかし、何か設定をすることでkdumpできるようにするTipsがあるのであれば、ぜひ知りたいと思います。
それにしても、何が問題なのか情報がないと、調査の糸口も掴めません。CentOSは、旧いOSのように起動時にメッセージがズラズラと出てこないので、何が悪いのか判断する情報が得られないのです。昔は起動時に長々とメッセージがコンソールに流れていましたが、一般受けしないので出さなくする傾向にあるのだと思います。
なんとか情報が得られないかと調べていたら、GRUB2のブートメニューで編集モードに入り、パラメータを変えれば良いようです。パラメータ「rhgb quiet」の指定を消せば昔のOSのように起動ログが出てくるようになります。また更に詳しい情報が必要ならパラメータ「loglevel=7 systemd.log_level=debug」を指定すれば、もっと詳しく情報が出てきます。
この指定をおこなってVirtualBoxでkdumpを起動しようとしたところ、2nd kernelの起動ログが出る前にVirtualBox自体が落ちてしまいました。そもそも2nd kernelに制御が渡っていないようです。
2019-08-26
「電撃戦」と「鎖国」
岩波新書の『独ソ戦』（大木毅）を読んでいます。独ソ戦というのは歴史として知っていますが、より踏み込んだ内容については詳しく知りません。まだ読んでいる最中ですが、これまでの理解が正しいとは言えなかったことを知りましたし、最新の研究成果を反映しているので、より正確な理解ができると期待しています。
なかでも驚いたのが、以下の記述です（47頁）。
第二次世界大戦当初のドイツ軍の快進撃は「電撃戦」として解説されることが多いと思っていましたが、ドイツ軍の軍事的な原則ではなかったというなら驚きです。通俗的な歴史理解は、実は歴史的な正確な理解とは限らないという事なのでしょうか。
そこで思いだすのが、日本史で耳にする「鎖国」です。通俗的な日本史では江戸時代は「鎖国」と言われますが、歴史研究者からは「鎖国」などは無く、「海禁」と理解されるという見解も出ています。
当たり前だと思っていた歴史理解が、実はそうではないという事例は、他にもありそうです。
なかでも驚いたのが、以下の記述です（47頁）。
「電撃戦」という単語自体、第二次世界大戦前半の一連の戦役ののちに、外国のジャーナリスト、あるいはプロパガンダ当局が用いはじめたもので、軍事用語ではなかったことを解明している。
第二次世界大戦当初のドイツ軍の快進撃は「電撃戦」として解説されることが多いと思っていましたが、ドイツ軍の軍事的な原則ではなかったというなら驚きです。通俗的な歴史理解は、実は歴史的な正確な理解とは限らないという事なのでしょうか。
そこで思いだすのが、日本史で耳にする「鎖国」です。通俗的な日本史では江戸時代は「鎖国」と言われますが、歴史研究者からは「鎖国」などは無く、「海禁」と理解されるという見解も出ています。
当たり前だと思っていた歴史理解が、実はそうではないという事例は、他にもありそうです。
2019-08-23
カーネルがパニックしても再起動がかからない
Linuxにおいて、コマンドラインから意図的にカーネル・パニックを発生させる方法があります。Webを検索すれば情報はすぐに見つかると思います（例えば「sysrqキーでパニックさせる」がそうです）。Linuxであれば、Ubuntuであろうが、openSUSEであろうが、CentOSだろうが、ディストリビューションを選ばないと思っていました。ところがそうでもないようです。
発端はCentOS 7.4でした。カーネルがパニックを起こしたら自動的に再起動するような設定にした筈なのに、実際にパニックを起こしているようであるのに、再起動しないのです。その時点で、マシンへのpingは通りませんし、コンソール画面には何も映っていません。もう電源を手動で落とすしかない状態です。
実際に運用中の環境で「パニックの実験」は出来ませんから、VirtualBox上にCentOS 7.4の最低限の環境を作って試してみました。するとやはり再起動しないのです。現象は再現したと言えるのかもしれませんが、もしかすると何か手順を間違えているのかもしれません。そこで、VirutalBox上で動作するように準備しているUbuntu 18.04やopenSUSE 13.1で試してみました。するとどちらもカーネルがパニックすると再起動します。手順に誤りは無いと判断して良いでしょう。
Webには「CentOS7.0でカーネルパニックを発生させてみる」という情報があるのです。CentOS 7.0なら再起動して、CentOS 7.4では再起動しないというのも不思議な話です。そこでVirtualBox上にCentOS 7.0から7.5までの各環境を準備して、再起動されるか否かを実験してみました。その結果、驚いたことに再起動したと言えるのはCentOS 7.1だけでした。
CentOS 7.4で再起動されない現象は確認できましたが、運用上の理由から再起動して欲しいのです。システムパラメータに何か関係しそうな設定があるのかもしれないと考えてCentOS 7.3とCentOS 7.4を比較してみましたが、それらしい設定はなさそうです。
解決策が見出せないまま手詰まりかと思ったのですが、ふと「kdumpが再起動を邪魔しているのではないか」と思いつきました。カーネルがパニックするとkdumpでクラッシュダンプを取得することになるので、kdumpが居なければ再起動できるのではないかと考えたのです。そこで確認してみるとCentOS 7.0以降の全バージョンでkdumpサービスが動いていました。
コマンドラインから「systemctl stop kdump」でサービスを止めて、当初の手順でカーネル・パニックを起こしてみると、なんとCentOS7.4でも再起動しました。やはりkdumpが邪魔していたのでしょう。
発端はCentOS 7.4でした。カーネルがパニックを起こしたら自動的に再起動するような設定にした筈なのに、実際にパニックを起こしているようであるのに、再起動しないのです。その時点で、マシンへのpingは通りませんし、コンソール画面には何も映っていません。もう電源を手動で落とすしかない状態です。
実際に運用中の環境で「パニックの実験」は出来ませんから、VirtualBox上にCentOS 7.4の最低限の環境を作って試してみました。するとやはり再起動しないのです。現象は再現したと言えるのかもしれませんが、もしかすると何か手順を間違えているのかもしれません。そこで、VirutalBox上で動作するように準備しているUbuntu 18.04やopenSUSE 13.1で試してみました。するとどちらもカーネルがパニックすると再起動します。手順に誤りは無いと判断して良いでしょう。
Webには「CentOS7.0でカーネルパニックを発生させてみる」という情報があるのです。CentOS 7.0なら再起動して、CentOS 7.4では再起動しないというのも不思議な話です。そこでVirtualBox上にCentOS 7.0から7.5までの各環境を準備して、再起動されるか否かを実験してみました。その結果、驚いたことに再起動したと言えるのはCentOS 7.1だけでした。
- VirtualBoxがダイアログを出し、仮想マシンが落ちてしまう（CentOS 7.0、CentOS 7.2、CentOS 7.3）
- 画面が固まり、再起動しない（CentOS 7.4、CentOS 7.5）
CentOS 7.4で再起動されない現象は確認できましたが、運用上の理由から再起動して欲しいのです。システムパラメータに何か関係しそうな設定があるのかもしれないと考えてCentOS 7.3とCentOS 7.4を比較してみましたが、それらしい設定はなさそうです。
解決策が見出せないまま手詰まりかと思ったのですが、ふと「kdumpが再起動を邪魔しているのではないか」と思いつきました。カーネルがパニックするとkdumpでクラッシュダンプを取得することになるので、kdumpが居なければ再起動できるのではないかと考えたのです。そこで確認してみるとCentOS 7.0以降の全バージョンでkdumpサービスが動いていました。
コマンドラインから「systemctl stop kdump」でサービスを止めて、当初の手順でカーネル・パニックを起こしてみると、なんとCentOS7.4でも再起動しました。やはりkdumpが邪魔していたのでしょう。
2019-08-15
小平尚道『アメリカ強制収容所』を読んで
雑誌「ナショナルジオグラフィック（日本版）」の2018年10月号を読んでいたら（定期購読しているので毎月郵送されてきているのですが、忙しくて読む時間がとれずに溜まっています。時間をみつけて、読んでいる最中なのですが）、「強制収容された日系人」という記事がありました。話題がそれますが、この記事のタイトルがこれで正しいのか不明です。というのは、目次にあるタイトルは、先述したようになっていますが、本文にはそれらしいタイトルがなく、タイトルらしきものとして「私はアメリカ人です。戦時中の日系人強制収容が今の米国に問いかける。」とあるだけなのです。
閑話休題。第二次世界大戦中のアメリカにおける日系人強制収容については、話には聞いていましたが、詳しく知りません。1980年頃になってからアメリカ政府が誤りを認め謝罪したとの話も聞いたことがありますが、詳しく理解している訳ではありません。
まずは参考になるような書籍を読んでみようと図書館で調べてみたら『アメリカ強制収容所―戦争と日系人―』（小平尚道、1980年）というのがあったので借りてきて読んでみました。著者である小平尚道は、1912年に米国生まれの日系二世で、シアトル長老教会牧師でした。日系人として強制収容された体験者です。本書は、その体験記であり、アメリカにおける日系人強制収容の全貌を明らかにしているわけではありません。本書の序文で著者が以下のように記しているとおりです。
著者は日米開戦前の1940年夏から秋にかけて日本を訪れ、満州にも行ったことが、まず最初に記されています。本書の基調は体験談なので、その時に著者の身に何があったのか、また著者が当時の日本の状況をどのように見ていたのか、そして日米の違いをどう感じていたのか等に主眼をおいて記されています。その内容は著者の主観ですから、それを割り引いて理解する必要がありますが、その反面として著者の関心の在りかや感想を通して、当時の社会をより深く知ることができます。これはとても興味深いことで、無味乾燥な教科書の（可もなく不可もなく、と言った）淡々とした記述に比べると、説得力があると感じました。
閑話休題。第二次世界大戦中のアメリカにおける日系人強制収容については、話には聞いていましたが、詳しく知りません。1980年頃になってからアメリカ政府が誤りを認め謝罪したとの話も聞いたことがありますが、詳しく理解している訳ではありません。
まずは参考になるような書籍を読んでみようと図書館で調べてみたら『アメリカ強制収容所―戦争と日系人―』（小平尚道、1980年）というのがあったので借りてきて読んでみました。著者である小平尚道は、1912年に米国生まれの日系二世で、シアトル長老教会牧師でした。日系人として強制収容された体験者です。本書は、その体験記であり、アメリカにおける日系人強制収容の全貌を明らかにしているわけではありません。本書の序文で著者が以下のように記しているとおりです。
したがって、私の経験はミネドカ収容所に限定され、これを一般化することはできない。あくまで私個人の体験で、どこの収容所も、こうだったとは言えない。それ故、この本はアメリカ収容所の全体を画いたものでなく、その一部を録したものにすぎない。
著者は日米開戦前の1940年夏から秋にかけて日本を訪れ、満州にも行ったことが、まず最初に記されています。本書の基調は体験談なので、その時に著者の身に何があったのか、また著者が当時の日本の状況をどのように見ていたのか、そして日米の違いをどう感じていたのか等に主眼をおいて記されています。その内容は著者の主観ですから、それを割り引いて理解する必要がありますが、その反面として著者の関心の在りかや感想を通して、当時の社会をより深く知ることができます。これはとても興味深いことで、無味乾燥な教科書の（可もなく不可もなく、と言った）淡々とした記述に比べると、説得力があると感じました。
2019-08-10
映画「スティング」
NHK BSプレミアムで2019年8月15日の午後1時から映画「スティング」が放送される予定です。NHKのサイトでは、次のように紹介しています。
ギャングのボスをだまそうとする詐欺師の話だとは思っていましたが、「コメディー」とは考えていませんでした。娯楽映画だとは思うし、実録もののドキュメンタリーではないですし、観終わったときに暗い気持ちになる訳ではないので、すっきりする楽しい映画だとは思います。
しかし「コメディー」と言われると、そうなのかなぁと思います。コメディ映画に出演しているポール・ニューマンやロバート・レッドフォードは「コメディアン」という事になってしまうのでしょうか。
Ｐ・ニューマン、Ｒ・レッドフォード、Ｇ・Ｒ・ヒル監督、「明日に向って撃て！」の名トリオが、１９３０年代のシカゴを舞台に、仲間の復しゅうのため、ギャングの大親分に挑む詐欺師たちの華麗で大胆な活躍を描く傑作犯罪コメディー。（以下略）
ギャングのボスをだまそうとする詐欺師の話だとは思っていましたが、「コメディー」とは考えていませんでした。娯楽映画だとは思うし、実録もののドキュメンタリーではないですし、観終わったときに暗い気持ちになる訳ではないので、すっきりする楽しい映画だとは思います。
しかし「コメディー」と言われると、そうなのかなぁと思います。コメディ映画に出演しているポール・ニューマンやロバート・レッドフォードは「コメディアン」という事になってしまうのでしょうか。
2019-08-09
rsyncで除外指定（--exclude）の問題が解決した
dynabook SS SX/15AにNetBSD/i386を入れて利用しています。この他に、日常的に使用しているデスクトップPCがあり、それはWindow10です。Windowsのフォルダ「Documents」にあるファイルをNetBSD側にコピーしておけば、ノートPCを持って出かけた時に参照できて便利だと思うので、同期させておこうと考えています。ただしdynabookのディスク容量が厳しいので、出先では無用なファイルは同期対象から外したいと思っています。
まず同期する仕組みはrsyncを使います。Windows10上のWSLを利用すれば、U*IX系の各種ツールが利用できるため、Win32版rsyncなどを利用するよりも安心できます。rsyncを利用してファイルを同期することは、あまり苦労することもなく出来ました。
やっかいだったのが、除外対象を除いて同期させることです。rsyncで除外対象を指定するにはオプション「--exclude」を指定すればよいようなのですが、指定方法に癖があり、苦労している情報がWebには溢れています。Webで見つけた以下の情報を参考にしました。
最終的に期待する動作をするようになったのですが、うまくいかなかった原因はrsyncのオプションの指定方法ではなく、自作したシェルスクリプトの書き方の問題でした。
当初シェルスクリプトでは次のように書いていました。除外対象は今後増減する可能性がありますし、rsyncに指定するオプションは他にもあるので、それを分離したつもりでした。
まず同期する仕組みはrsyncを使います。Windows10上のWSLを利用すれば、U*IX系の各種ツールが利用できるため、Win32版rsyncなどを利用するよりも安心できます。rsyncを利用してファイルを同期することは、あまり苦労することもなく出来ました。
やっかいだったのが、除外対象を除いて同期させることです。rsyncで除外対象を指定するにはオプション「--exclude」を指定すればよいようなのですが、指定方法に癖があり、苦労している情報がWebには溢れています。Webで見つけた以下の情報を参考にしました。
最終的に期待する動作をするようになったのですが、うまくいかなかった原因はrsyncのオプションの指定方法ではなく、自作したシェルスクリプトの書き方の問題でした。
当初シェルスクリプトでは次のように書いていました。除外対象は今後増減する可能性がありますし、rsyncに指定するオプションは他にもあるので、それを分離したつもりでした。
EXC_OPTS="しかし期待した動作をしない原因は、この指定にあったようです。以下の書き方をすると、期待した動作をするようになりました。違いは、オプションの中でシングルクォートで括っているのを止めたことです。
--exclude='*.[eE][xX][eE]'
--exclude='*.[jJ][pP][gG]'
"
EXC_OPTS="この解決に至る過程で、rsyncのオプション「-vvv」を利用しました。文字「v」を増やすほど情報が増えるようです。そこに以下のような出力が現れているのが確認できます。除外対象が期待した通りに処理されていれば、このような出力になるはずです。うまく指定されていなければ、「because of pattern」という表示がなく、除外対象にしている筈なのに、なぜか同期対象とされてしまい、頭を捻ることになります。
--exclude=*.[eE][xX][eE]
--exclude=*.[jJ][pP][gG]
"
[sender] hiding file a/b/c/1.jpg because of pattern *.[jJ][pP][gG]問題の原因がわかってしまえば、至極当然なことと思えますが、解決できていないときには、五里霧中という気持ちになります。ともかく解決できて、一安心しました。
2019-08-05
Microsoft Windows 10からNetBSD/i386へのDocumentsフォルダの同期にrsyncを利用する
dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて利用しています。日常的に利用しているのはMicrosoft Windows 10のデスクトップPCです。ここにあるDocumentsフォルダをdynabook側にもコピーしておくことで、出先にdynabookを持っていた時、ファイルを参照できる環境となるようにしています。
元々はdynabookにはMicrosoft Windows Vistaが入っていたので、ファイルを同期するのは簡単でした。共有フォルダとして見えるようなっていれば、XCOPY.EXEを利用してファイルをコピーできました。
Vistaがフェーズアウトし、OSをNetBSDに入れ換えたことにより、同期する仕組みを工夫する必要が出てきました。うまい仕組みを作り上げたと思っても、動作が不安定で、なかなか満足のいくものになりませんでした。
そうこうしているうちに、Microsoft Windows 10でWSL（Windows Subsystem for Linux）が利用できるようになりました。WSLを使えば、Windows側のファイルをWSL側から参照することができます。しかも本物のLinuxディストリビューションを利用できるので、U*IX系OSとしてNetBSDとの親和性も高く、同期方式が作りやすくなります。
結局、WSL上でrsyncを使って、ローカルにあるDocumentsフォルダのファイルを、リモートにあるNetBSD上の所定のディレクトリにコピーすることにしました。試しに動かしてみると、上手くいっています。この点では成功と言えるでしょう。
ただし問題もあります。dynabook SS SX/15Aのディスクは60Gしかないので、OSやアプリケーションを入れた後で使える容量は、あまり残っていません。Windows側のDocumentsフォルダにあるものを全てコピーしてしまうと、ディスクが溢れる恐れがあります。そこで余分なファイルはコピーしないようにしたいところです。
このような要望のために、rsyncにはオプション「--exclude」が用意されており、これを使えば解決と言いたいところです。ところが指定方法が難しく、指定してみても、期待した動作をしません（要するに、コピー対象から除外したつもりなのに、コピーされてしまう）。Webを検索しても、うまくいかずに苦労している人達が溢れています。
コピーは出来ているので、ひとまず成功と言えるのですが、コピー除外がうまくいっていないので、完成しているとは言えません。なんとか問題を解決しようと思います。
元々はdynabookにはMicrosoft Windows Vistaが入っていたので、ファイルを同期するのは簡単でした。共有フォルダとして見えるようなっていれば、XCOPY.EXEを利用してファイルをコピーできました。
Vistaがフェーズアウトし、OSをNetBSDに入れ換えたことにより、同期する仕組みを工夫する必要が出てきました。うまい仕組みを作り上げたと思っても、動作が不安定で、なかなか満足のいくものになりませんでした。
そうこうしているうちに、Microsoft Windows 10でWSL（Windows Subsystem for Linux）が利用できるようになりました。WSLを使えば、Windows側のファイルをWSL側から参照することができます。しかも本物のLinuxディストリビューションを利用できるので、U*IX系OSとしてNetBSDとの親和性も高く、同期方式が作りやすくなります。
結局、WSL上でrsyncを使って、ローカルにあるDocumentsフォルダのファイルを、リモートにあるNetBSD上の所定のディレクトリにコピーすることにしました。試しに動かしてみると、上手くいっています。この点では成功と言えるでしょう。
ただし問題もあります。dynabook SS SX/15Aのディスクは60Gしかないので、OSやアプリケーションを入れた後で使える容量は、あまり残っていません。Windows側のDocumentsフォルダにあるものを全てコピーしてしまうと、ディスクが溢れる恐れがあります。そこで余分なファイルはコピーしないようにしたいところです。
このような要望のために、rsyncにはオプション「--exclude」が用意されており、これを使えば解決と言いたいところです。ところが指定方法が難しく、指定してみても、期待した動作をしません（要するに、コピー対象から除外したつもりなのに、コピーされてしまう）。Webを検索しても、うまくいかずに苦労している人達が溢れています。
コピーは出来ているので、ひとまず成功と言えるのですが、コピー除外がうまくいっていないので、完成しているとは言えません。なんとか問題を解決しようと思います。
2019-08-02
PythonにNetworkXをインストール
最長片道切符のグラフ問題を扱うために、PythonにNetworkXを導入してみました。導入するのは簡単ですが、pipを利用します。Python 3.4以降には標準で入っているという情報がありますが、FreeBSDのパッケージで入れたpython 3.6には入っていないようでした。
pipを導入するのは簡単ですが、パーミッションの都合によりrootで操作する必要があります。
グラフ構造を扱うためにNetworkXが必須かというと、そういうわけでもないと思います。しかし重み付きグラフの情報を記したファイルを読み込んでくれるヘルパー関数があるので、自前で似たようなプログラムを書くより楽ではないかと思います。
NetworkXを極めるよりも、最長片道切符のグラフ問題を解くために必要なプログラムを書けるようにするため、NetworkXの使い方を学んでいきたいと思います。
tpe530c> python3.6 -m pip list
/usr/local/bin/python3.6: No module named pip
tpe530c> uname -a
FreeBSD tpe530c 12.0-RELEASE-p8 FreeBSD 12.0-RELEASE-p8 GENERIC amd64
tpe530c> python3.6 -V
Python 3.6.9
furusawa@tpe530c> python3.6
Python 3.6.9 (default, Jul 11 2019, 01:10:39)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>>
pipを導入するのは簡単ですが、パーミッションの都合によりrootで操作する必要があります。
# curl -kL https://bootstrap.pypa.io/get-pip.py | python3.6
tpe530c> python3.6 -m pip list
Package Version
---------- -------
decorator 4.4.0
networkx 2.3
pip 19.2.1
setuptools 41.0.1
wheel 0.33.4
グラフ構造を扱うためにNetworkXが必須かというと、そういうわけでもないと思います。しかし重み付きグラフの情報を記したファイルを読み込んでくれるヘルパー関数があるので、自前で似たようなプログラムを書くより楽ではないかと思います。
NetworkXを極めるよりも、最長片道切符のグラフ問題を解くために必要なプログラムを書けるようにするため、NetworkXの使い方を学んでいきたいと思います。
2019-07-31
「65日間日本一周最長片道切符」（bit、1975年1月号）を読んで
かつて共立出版が発行していた「bit」に「65日間日本一周最長片道切符」（平野照比古、1975年1月号）という記事が掲載されていることを知り、読んでみました。国鉄が日本全国に鉄道網を持っていた時代には、このような最長距離の片道切符を考えるのが話題になっていました。最も有名なのが『最長片道切符の旅』でしょう。
記事には、最長距離片道ルートを求めるアルゴリズムが開設されていますが、概念レベルが書かれているだけなので、具体的なロジックはわかりません。文末にデータ作成作業をしてくれた人達への謝辞が書かれています。当時は今日のような路線検索サイトがある訳ではありませんから、おそらく時刻表を利用して、必要な情報を拾ってグラフ構造を作ったのでしょう。楽な作業ではないと思いますが、本文中でも「まず、駅の集合をVとする。実際には分岐点や行きどまりの駅だけを考えれば充分であることは明らかであろう。」と書かれているように、旧国鉄の全駅のデータが必要になるわけではなく、グラフ構造を作り上げるために必要な分岐駅や末端駅の名前と区間距離だけで良いわけです（それでも膨大なデータになることは違いないでしょう）。
アルゴリズムの解説では、サブブロック化に重点がおかれています。北は北海道から南は鹿児島までの旧国鉄の路線網をグラフ構造にしたとしても、現実の日本列島を考えれば、全体を一気に計算するよりも、一部分（これをブロックと呼んでいる）を計算して、最後に全体を統合すれば、最終的な計算量が削減されることが期待できます。
例えば、北海道と本州は青函連絡船を使うしかないし、九州と本州は関門トンネルを使うしかないわけです。だから、北海道内や九州内のルートを計算する場合には、それ以外の地域の事を考えなくてよいことになります。
北海道、四国、九州は、上述したようなサブブロックとして計算できますが、本州をどうするかが問題です。サブブロックに分けられそうでもあり、分けるのは困難のようでもあり、なんとかしたいところです。ブロックに分けようとする意図は、全体を闇雲に計算すると計算量が爆発し、その当時の計算機では処理が終わらなくなる恐れがあるからでしょう。当時の計算機よりも、今日のパソコンの方が性能が圧倒的に良いと思うので、もしかすると余計なサブブロックを考えなくても、計算できるかもしれません。
プログラムはFORTRANで組んだようです。その当時なら、このような計算をするならFORTANに決まっているでしょう。この記事には、それ以外（プログラムリストとか、実行時間など）の具体的なことは何も書かれていません。CiNiiで探してみたら、京都大学学術情報リポジトリに「長い片道切符について（計算機によるパズル・ゲームの研究）」というメモが「数理解析研究所講究録(1976), 263:75-76」として見ることができました。手書きなのが時代を反映しているところですが、「使用言語はFORTRANで使用計算機はFACOM 270-20(LOAD/ADD 4.8μs)での時間である」とあります。
面白そうなので、自分でもやってみたくなりました。プログラムはFORTRANでも良いのですが、今ならPythonを使ってみたいところです。グラフ構造を取り扱うためのPythonモジュールがあれば、いろいろと楽ができるでしょう。
ここで行く手に大きな問題があることに注意が必要です。1975年当時の国鉄と、2019年現在のJR各社とでは、事情が大きく変わっているのです。特に次の点が重要です。
2番目の問題は、計算量が少なくてガッカリするという程度の話にすぎませんが、1番目の問題は重大です。北海道新幹線が開通したことにより、JR北海道から切り離された道南いさりび鉄道の扱いが問題になるからです。新幹線が開業したことによりJRから切り離された路線は他にもありますし、長野新幹線の開業により横川と軽井沢の間は在来線が無くなりました。このような事情を考えると、どのような方針を採用するか考えておく必要があります。
最長片道切符のルート問題は、グラフ理論の応用問題です。ここで日本の鉄道網であるという知識を利用すると、すっきりしたグラフ理論のアルゴリズムというより、個別事情の集合という汎用性の乏しい問題に堕ちてしまいそうではあります。いずれにせよ、面白そうなので、なんとかものにしてみたいと思います。
記事には、最長距離片道ルートを求めるアルゴリズムが開設されていますが、概念レベルが書かれているだけなので、具体的なロジックはわかりません。文末にデータ作成作業をしてくれた人達への謝辞が書かれています。当時は今日のような路線検索サイトがある訳ではありませんから、おそらく時刻表を利用して、必要な情報を拾ってグラフ構造を作ったのでしょう。楽な作業ではないと思いますが、本文中でも「まず、駅の集合をVとする。実際には分岐点や行きどまりの駅だけを考えれば充分であることは明らかであろう。」と書かれているように、旧国鉄の全駅のデータが必要になるわけではなく、グラフ構造を作り上げるために必要な分岐駅や末端駅の名前と区間距離だけで良いわけです（それでも膨大なデータになることは違いないでしょう）。
アルゴリズムの解説では、サブブロック化に重点がおかれています。北は北海道から南は鹿児島までの旧国鉄の路線網をグラフ構造にしたとしても、現実の日本列島を考えれば、全体を一気に計算するよりも、一部分（これをブロックと呼んでいる）を計算して、最後に全体を統合すれば、最終的な計算量が削減されることが期待できます。
例えば、北海道と本州は青函連絡船を使うしかないし、九州と本州は関門トンネルを使うしかないわけです。だから、北海道内や九州内のルートを計算する場合には、それ以外の地域の事を考えなくてよいことになります。
北海道、四国、九州は、上述したようなサブブロックとして計算できますが、本州をどうするかが問題です。サブブロックに分けられそうでもあり、分けるのは困難のようでもあり、なんとかしたいところです。ブロックに分けようとする意図は、全体を闇雲に計算すると計算量が爆発し、その当時の計算機では処理が終わらなくなる恐れがあるからでしょう。当時の計算機よりも、今日のパソコンの方が性能が圧倒的に良いと思うので、もしかすると余計なサブブロックを考えなくても、計算できるかもしれません。
プログラムはFORTRANで組んだようです。その当時なら、このような計算をするならFORTANに決まっているでしょう。この記事には、それ以外（プログラムリストとか、実行時間など）の具体的なことは何も書かれていません。CiNiiで探してみたら、京都大学学術情報リポジトリに「長い片道切符について（計算機によるパズル・ゲームの研究）」というメモが「数理解析研究所講究録(1976), 263:75-76」として見ることができました。手書きなのが時代を反映しているところですが、「使用言語はFORTRANで使用計算機はFACOM 270-20(LOAD/ADD 4.8μs)での時間である」とあります。
面白そうなので、自分でもやってみたくなりました。プログラムはFORTRANでも良いのですが、今ならPythonを使ってみたいところです。グラフ構造を取り扱うためのPythonモジュールがあれば、いろいろと楽ができるでしょう。
ここで行く手に大きな問題があることに注意が必要です。1975年当時の国鉄と、2019年現在のJR各社とでは、事情が大きく変わっているのです。特に次の点が重要です。
- 新幹線開業にともない並行在来線がJRから切り離されている。
- 鉄道網が衰退（特にJR北海道）しており、グラフ構造で最長片道ルートを計算するというほど路線が残っていない。
2番目の問題は、計算量が少なくてガッカリするという程度の話にすぎませんが、1番目の問題は重大です。北海道新幹線が開通したことにより、JR北海道から切り離された道南いさりび鉄道の扱いが問題になるからです。新幹線が開業したことによりJRから切り離された路線は他にもありますし、長野新幹線の開業により横川と軽井沢の間は在来線が無くなりました。このような事情を考えると、どのような方針を採用するか考えておく必要があります。
- 全ての新幹線もルート検討に加える。ただし、路線の距離は、「営業キロ」なのか「実キロ」なのか、混乱しないようにすべきである。
- JRから切り離された第三セクター路線を、ルート検討に含めるか、除外するか決めておく。もし新幹線も除外し、第三セクター路線も除外するならば、北海道から本州に抜けるルートが無いということになります。
- いっそのこと全ての私鉄もルート検索の対象に含める。しかし「最長片道切符」の本来の意図は、「一枚の切符で最長距離」となることに意義があるため、ちょっとやり過ぎなのかもしれません。
最長片道切符のルート問題は、グラフ理論の応用問題です。ここで日本の鉄道網であるという知識を利用すると、すっきりしたグラフ理論のアルゴリズムというより、個別事情の集合という汎用性の乏しい問題に堕ちてしまいそうではあります。いずれにせよ、面白そうなので、なんとかものにしてみたいと思います。
2019-07-28
2019年7月28日3時31分発生三重県南東沖地震
2019年7月28日3時31分頃に三重県南東沖でM6.5の地震が発生しました。震源の深さは約420kmだそうですから、かなり深いところで起きています。
気象庁が発表した震度分布図を見ると、直観とは異なる状況が見て取れます。
まず第一に、震源が三重県南東沖なのに、愛知県では震度1程度にもかかわらず、宮城県で震度4、福島県や茨城県で震度3が観測されていることです。三重県では震度1の観測すらありません（実際には、微かな揺れを感じた人はいるのかもしれませんが）。震源に近い愛知県が震度1で、東北地方から関東地方の太平洋沿岸で強く揺れているようです。
次に、北海道の釧路町でも震度2を観測しているのに、西日本（中国、四国、九州）では、震度1の観測が全くありません。
地球の内部構造は、同心円状に揺れが伝わっていくわけではないということなのでしょう。三重県沖であれば、西日本全体を覆っているユーラシアプレートの範疇なのにもかかわらず、東日本を覆っている北アメリカプレートのエリアの方が揺れているという現象が起きているのが、興味深いところです。
気象庁が発表した震度分布図を見ると、直観とは異なる状況が見て取れます。
まず第一に、震源が三重県南東沖なのに、愛知県では震度1程度にもかかわらず、宮城県で震度4、福島県や茨城県で震度3が観測されていることです。三重県では震度1の観測すらありません（実際には、微かな揺れを感じた人はいるのかもしれませんが）。震源に近い愛知県が震度1で、東北地方から関東地方の太平洋沿岸で強く揺れているようです。
次に、北海道の釧路町でも震度2を観測しているのに、西日本（中国、四国、九州）では、震度1の観測が全くありません。
地球の内部構造は、同心円状に揺れが伝わっていくわけではないということなのでしょう。三重県沖であれば、西日本全体を覆っているユーラシアプレートの範疇なのにもかかわらず、東日本を覆っている北アメリカプレートのエリアの方が揺れているという現象が起きているのが、興味深いところです。
2019-07-27
「梅雨明け」の基準と実態
気象庁のWebに「令和元年の梅雨入りと梅雨明け（速報値）」というページがあり、「 更新日：令和元年7月25日」では東海、関東甲信、東北南部、東北北部の梅雨は明けていないことになっています。しかし梅雨前線は、とっくの昔に消えていて（素人目には、そう見えます）、数日前から最高気温が30度を超すようになっていますし、既に梅雨は明けているように見えます。四国、中国、近畿は「7月24日ごろ」に梅雨が明けていることになっているので、東海や関東甲信も梅雨明けで良いのではないかおもいますが（素人考えでは）、きっと気象庁の「梅雨明け基準」の何かを満たしていないのでしょう。
気象庁が発表する情報は、さすがに「何となく」というわけにはいかないでしょうから、何らかの基準を踏まえて発表するのでしょう。熱帯低気圧が台風になり、さらに温帯低気圧に変わる場合や、台風の大きさや強さを表現する場合は、何らかの尺度に従って発表されます。それは現実を表していると言って良いだろうと思います。これに対して、気象庁が発表する「桜の開花日」などは、地元の桜を全て見て廻るわけにはいかないでしょうから、サンプルとして指定された「特定の桜」が開花したかどうかに過ぎないはずです。代表として選ばれた桜の開花が、その地域を代表すると考えて差し支えないように選ばれているはずですが、本当に代表しているのか評価はしていない（しようがない）だろうと思います。
話を梅雨明けに戻すと、Webを検索すれば「梅雨明けの基準」と思われるものが見つかります。しかし気象庁の判断を類推しているに過ぎないので、本当に間違いない情報なのかという確実性はなさそうです。
今年の梅雨明けは何時になるのでしょう。いつ発表されるのでしょう。もしかすると「既に梅雨は明けていました」という発表になるのでしょうか。
気象庁が発表する情報は、さすがに「何となく」というわけにはいかないでしょうから、何らかの基準を踏まえて発表するのでしょう。熱帯低気圧が台風になり、さらに温帯低気圧に変わる場合や、台風の大きさや強さを表現する場合は、何らかの尺度に従って発表されます。それは現実を表していると言って良いだろうと思います。これに対して、気象庁が発表する「桜の開花日」などは、地元の桜を全て見て廻るわけにはいかないでしょうから、サンプルとして指定された「特定の桜」が開花したかどうかに過ぎないはずです。代表として選ばれた桜の開花が、その地域を代表すると考えて差し支えないように選ばれているはずですが、本当に代表しているのか評価はしていない（しようがない）だろうと思います。
話を梅雨明けに戻すと、Webを検索すれば「梅雨明けの基準」と思われるものが見つかります。しかし気象庁の判断を類推しているに過ぎないので、本当に間違いない情報なのかという確実性はなさそうです。
今年の梅雨明けは何時になるのでしょう。いつ発表されるのでしょう。もしかすると「既に梅雨は明けていました」という発表になるのでしょうか。
2019-07-26
地域の祭りと部署の宴会
Webの掲示板を見ていたら、地域外の者が地域の祭りに参加するのは非常識なのかという問いかけがありました。それに対して、そんなことはないという意見もあれば、駄目に決まっているという意見もありました。個人的には、参加者を制限する「祭り」って一体なんだろうと思いますので、地域内外を問わずに自由に参加して構わないと考えます。しかし参加しようとしたところ、地域外の者であることを理由に拒否されたという経験がある事例も少なくないようです。
この問題は、「祭り」という言葉が表している「状態」に対して、個々人の受け止め方に差異があるのが原因のひとつではないかと思います。「祭り」という言葉から連想するのは、全国的にも有名な京都の祇園祭、大阪の天神祭り、浅草の三社祭など各地にあります。これらは、当初は地域の中で小ぢんまりとして始まったのでしょうが、現在では全国的な観光行事となっているので、参加者を限定することはないでしょう。これほど大規模でなくても、祭りというのは全て地域の人達の営みから生まれており、人々の一体感を盛り上げるために来るもの拒まずとして運営されるものですから、参加者を制約するのはありえないと思います。
ここで注意しておきたいのは、「祭り」という言葉が、上述したような状況を必ずしも表現した言葉にはなっていない事例もあるという事実です。例えば、ファミレスなどの季節イベントの名前として、「春のご卒業・新入学おめでとう祭り」のように「祭り」という文字を入れてくることがあります（これは例のひとつであり、現実の何かとは関係ありません）。これは常識として「祭り」といっても、上述した「祭り」とは違うと、普通は理解しています。それは問題ではないのですが、「祭り」という言葉が、「祭り」とは違う派生した状況を表現していることは、問題を生む原因となり得るでしょう。
話が飛躍するかもしれませんが、会社が部署ごとや全社規模でおこなう「宴会」について考えてみてはどうでしょうか。新年会でも忘年会でも、送別会でも歓迎会でも構いません。全社規模で行われる「宴会」なら、社員誰でも参加できるでしょうが、部署ごとに行われる「宴会」なら、他部署の「宴会」なら、参加しようとすると断られる可能性は否定できません。このような事は当然だと思えるし、その理由も納得できるでしょう。
「祭り」という言葉が（伝統的な）祭りを意味せず、ファミレス的な「祭り」や、宴会的な「祭り」までも意味している可能性が、問題を引き起こしている気がします。「祭り」ではないものを「祭り」と呼ぶのも問題ですが、ならば「私たちが言う「祭り」とは、このようなものです」と定義すれば良いのかというと、それは違うだろうと思います。
意味の広い語彙を使うなら、その意味で表現される範囲を踏まえた行動をせざるを得ないでしょう。それを避けたいのであれば、意味の限定された語彙を選択すべきなのではないかと思います。
この問題は、「祭り」という言葉が表している「状態」に対して、個々人の受け止め方に差異があるのが原因のひとつではないかと思います。「祭り」という言葉から連想するのは、全国的にも有名な京都の祇園祭、大阪の天神祭り、浅草の三社祭など各地にあります。これらは、当初は地域の中で小ぢんまりとして始まったのでしょうが、現在では全国的な観光行事となっているので、参加者を限定することはないでしょう。これほど大規模でなくても、祭りというのは全て地域の人達の営みから生まれており、人々の一体感を盛り上げるために来るもの拒まずとして運営されるものですから、参加者を制約するのはありえないと思います。
ここで注意しておきたいのは、「祭り」という言葉が、上述したような状況を必ずしも表現した言葉にはなっていない事例もあるという事実です。例えば、ファミレスなどの季節イベントの名前として、「春のご卒業・新入学おめでとう祭り」のように「祭り」という文字を入れてくることがあります（これは例のひとつであり、現実の何かとは関係ありません）。これは常識として「祭り」といっても、上述した「祭り」とは違うと、普通は理解しています。それは問題ではないのですが、「祭り」という言葉が、「祭り」とは違う派生した状況を表現していることは、問題を生む原因となり得るでしょう。
話が飛躍するかもしれませんが、会社が部署ごとや全社規模でおこなう「宴会」について考えてみてはどうでしょうか。新年会でも忘年会でも、送別会でも歓迎会でも構いません。全社規模で行われる「宴会」なら、社員誰でも参加できるでしょうが、部署ごとに行われる「宴会」なら、他部署の「宴会」なら、参加しようとすると断られる可能性は否定できません。このような事は当然だと思えるし、その理由も納得できるでしょう。
「祭り」という言葉が（伝統的な）祭りを意味せず、ファミレス的な「祭り」や、宴会的な「祭り」までも意味している可能性が、問題を引き起こしている気がします。「祭り」ではないものを「祭り」と呼ぶのも問題ですが、ならば「私たちが言う「祭り」とは、このようなものです」と定義すれば良いのかというと、それは違うだろうと思います。
意味の広い語彙を使うなら、その意味で表現される範囲を踏まえた行動をせざるを得ないでしょう。それを避けたいのであれば、意味の限定された語彙を選択すべきなのではないかと思います。
2019-07-25
鉄道の「駅」の由来
NHKが放送している「ネーミングバラエティー日本人のおなまえっ！」で、2019年7月18日放送では「鉄道のおなまえ」でした。その中の話題のひとつとして、鉄道の「駅」というのは古代から続く「駅制」の「駅」から採用されたと紹介していました。
古代駅制というのは律令時代の話だと思っていたのに、それが明治時代になってステーションの訳語として「駅」を採用する根拠になったことに驚きました。古代の制度が明治直前まで残っていたのだろうかと思います。
そういう疑問を感じていたところで、偶然『ある明治人の記録』を読んでいたところ、興味深い記述を見つけました。柴五郎が青森から東京に出るため、地租改正調査のために東北巡回中の大蔵省役人の首席である長岡重弘の供を願いでて許されました。その件に次のような記述があります。
東京に出てきた柴五郎は、鉄道開通にも立ち会っています。
同じような事が『維新前夜』（野村兼太郎、昭和16年4月30日発行）の「鉄道開業式入場券」にも書かれています。しかしそれは『日本鉄道史』からの孫引きです。『日本鉄道史』というのは大正10年に鉄道省が発行したものだと思います。これは国立国会図書館のデジタルコレクションから見ることができます。
古代駅制というのは律令時代の話だと思っていたのに、それが明治時代になってステーションの訳語として「駅」を採用する根拠になったことに驚きました。古代の制度が明治直前まで残っていたのだろうかと思います。
そういう疑問を感じていたところで、偶然『ある明治人の記録』を読んでいたところ、興味深い記述を見つけました。柴五郎が青森から東京に出るため、地租改正調査のために東北巡回中の大蔵省役人の首席である長岡重弘の供を願いでて許されました。その件に次のような記述があります。
六月初旬なり。父上より賜りし竹行李を背負い、草鞋履き山高帽を耳までかぶりて出発す。長岡氏は牛輿に乗り、他は徒歩なり。長岡氏は心優しき人にて、幼少の余をいたわり、同氏の輿に同乗させ、あるいは駅馬に乗せなどして、実際に歩行せるは一日のうち四、五里なり。ここに「駅馬」という語が現れます。これが番組で紹介された古代駅制のことなのでしょうか。
東京に出てきた柴五郎は、鉄道開通にも立ち会っています。
九月十二日、東京―横浜間に最初の鉄道開通す。新橋停車場に造られた桟上に登りて参観す。天皇陛下、柿色の御装束を召され、同じく束帯の百官を従え、横浜より帰着の汽車より降り立ち給う。外国公使もまた列席し、荘厳華麗な式典なり。式後御浜御殿苑内開放されてさまざまなる余興あり。紅白の餅を撒き、余もこれを拾いたるを記憶す。
同じような事が『維新前夜』（野村兼太郎、昭和16年4月30日発行）の「鉄道開業式入場券」にも書かれています。しかしそれは『日本鉄道史』からの孫引きです。『日本鉄道史』というのは大正10年に鉄道省が発行したものだと思います。これは国立国会図書館のデジタルコレクションから見ることができます。
『ある明治人の記録』と『武士の娘』
Webで見かけた記事に紹介されていた『ある明治人の記録』を読んでみました。会津藩士の家に生まれた柴五郎が戊辰戦争に巻き込まれ、斗南に移住して底辺を彷徨った末に東京に出てきて陸軍幼年学校に入ります。戊辰戦争で会津が戦った頃から、陸軍幼年学校時代に西南戦争が起こり、その後の竹橋事件の頃までを本人が後年に書き記したものを、石光真人が若干の編集を加えて出版したものです。
会津藩士である柴家は、本書で「父柴佐多蔵は会津藩士、280石の御物頭」とあります。当時の著名な会津藩士というと、家老の西郷頼母が1,700石、同じく家老の家柄の山川大蔵が1,000石ということですから、武家としては中位に属しているのかと思います。柴五郎は陸軍大将にまで上り詰めたということです。戦前までの旧日本陸軍では、陸軍中将は1,200名以上もいるのに、陸軍大将となったのは134名に過ぎなかったそうです。薩長閥が階級を独占していた当時において、会津出身者としては頂点を極めたといえるでしょう。
このような華麗な経歴から逆算すると、人は勝手な想像をたくましくして、幼少の頃から神童の誉れが高かったのだろうとか、陸軍幼年学校に抜擢されて、なるべくしてなったのだろうとか、思いがちですが、本書を読むとそのような印象はまったく無く、むしろ底辺を彷徨った挙句に、運よく道が開けたという感じです。
戊辰戦争で会津藩が敗れ斗南に国替になったとき、柴五郎も親と共に斗南に移り住んだようです。斗南での生活の悲惨さは多く語り伝えられているとおりですが、柴五郎も例外ではなく、極寒の地に放り出された状態で、よくぞ生き残れたものだと思います。
生活が底辺を彷徨うようになると、知らず知らずのうちに精神が荒んでくるものです。当時は「プライド」のような横文字はなかったでしょうし、「自尊心」という言葉もなかったかもしれません。しかし「武士の子たることを忘れしか」と父に叱られたというエピソードが語られる中に、心が崩れていくのを押し留める決意が感じられます。
このようなエピソードに触れたとき、以前に呼んだことがある『武士の娘』を思い出しました。著者の杉本鉞子は越後長岡藩の家老だった家に生まれました。明治6年の生まれなので、既に長岡藩はなく（したがって家老の家でもなく）、戊辰戦争も体験していません。長岡藩は奥羽越列藩同盟の一員として戦い、会津同様に長岡城下が戦場になっています（河井継之助が有名です）。時代は明治なので「四民平等」とされていましたが、「武士の娘」としての教育を受け、その一端が本書で語られています。
柴五郎にしても、杉本鉞子にしても、武家としての誇りを失わずに生きたように思います。しかし失うまいと意地を張っているわけではないように思います。やせ我慢をしているということではないと思います。自然とそうなるのでしょう。その姿を見習いたいものだと思います。
会津藩士である柴家は、本書で「父柴佐多蔵は会津藩士、280石の御物頭」とあります。当時の著名な会津藩士というと、家老の西郷頼母が1,700石、同じく家老の家柄の山川大蔵が1,000石ということですから、武家としては中位に属しているのかと思います。柴五郎は陸軍大将にまで上り詰めたということです。戦前までの旧日本陸軍では、陸軍中将は1,200名以上もいるのに、陸軍大将となったのは134名に過ぎなかったそうです。薩長閥が階級を独占していた当時において、会津出身者としては頂点を極めたといえるでしょう。
このような華麗な経歴から逆算すると、人は勝手な想像をたくましくして、幼少の頃から神童の誉れが高かったのだろうとか、陸軍幼年学校に抜擢されて、なるべくしてなったのだろうとか、思いがちですが、本書を読むとそのような印象はまったく無く、むしろ底辺を彷徨った挙句に、運よく道が開けたという感じです。
戊辰戦争で会津藩が敗れ斗南に国替になったとき、柴五郎も親と共に斗南に移り住んだようです。斗南での生活の悲惨さは多く語り伝えられているとおりですが、柴五郎も例外ではなく、極寒の地に放り出された状態で、よくぞ生き残れたものだと思います。
生活が底辺を彷徨うようになると、知らず知らずのうちに精神が荒んでくるものです。当時は「プライド」のような横文字はなかったでしょうし、「自尊心」という言葉もなかったかもしれません。しかし「武士の子たることを忘れしか」と父に叱られたというエピソードが語られる中に、心が崩れていくのを押し留める決意が感じられます。
このようなエピソードに触れたとき、以前に呼んだことがある『武士の娘』を思い出しました。著者の杉本鉞子は越後長岡藩の家老だった家に生まれました。明治6年の生まれなので、既に長岡藩はなく（したがって家老の家でもなく）、戊辰戦争も体験していません。長岡藩は奥羽越列藩同盟の一員として戦い、会津同様に長岡城下が戦場になっています（河井継之助が有名です）。時代は明治なので「四民平等」とされていましたが、「武士の娘」としての教育を受け、その一端が本書で語られています。
柴五郎にしても、杉本鉞子にしても、武家としての誇りを失わずに生きたように思います。しかし失うまいと意地を張っているわけではないように思います。やせ我慢をしているということではないと思います。自然とそうなるのでしょう。その姿を見習いたいものだと思います。
2019-07-20
投票と宝くじ
今年は4月に統一地方選があり、7月には参院選もあり、選挙が多い年になりました。以前から言われていることですが、投票率が下がっているようです。投票することは選挙権の行使ですから、投票しないのは権利を放棄していることになります。権利を行使しないのは残念なことだと思いますが、投票を強制させるような施策を講じるのも違うだろうと思います。
投票しない理由に、「投票しても何も変わらないから」というものがあると聞きます（他にも投票しない理由はあると思いますが）。この理由の真意をもっと分析しないことには軽々しく言えないとは思いますが、ようするに「自分の投票した候補者が当選したら「あたり」で、投票して良かったと感じるが、落選したら「はずれ」で、投票なんかして（時間の）無駄だったと思う」ということなのでしょうか。
こう考えているとすると、投票するのは勇気がいるでしょう。何故なら、誰が当選するか分からないと投票できないからです（勝ち馬に乗りたいということでしょう）。一番圧倒的な候補者に投票しておけば無難なのでしょうが、そういう候補者なら「自分が投票しなくても当選するだろう」と勝手に思い込み、結局投票しないかもしれません。
もしかすると、投票するという行為を、宝くじを買うという行為のように考えているのだろうかと思います。「あたる（当選する）なら、宝くじを買いたい（投票してもよい）」が、「あたるかどうか分からないなら、無駄金を使いたくない（時間を無駄にしたくない）」と、博打を打つ感覚なのでしょうか。
投票というのは、結果も大切なのは当然ですが、支持する（しても良いかなと思える）候補者を選ぶという行為に過ぎません。それだけのことです。それをすることが現代社会にコミットすることになりますから、投票しなければ、その人物は存在しているのに「存在していないとして扱われる」という奇妙な状態を選択していることになるでしょう（意識していないかもしれませんが）。
投票（選挙権の行使）は、自分の考えだけでおこなえば良いことで、他者の意向を気にする必要はないはずです。「自分は政治をよくわかっていないから」とか、「皆さんはどうするんですか」とか、こういうことを考えているなら、考える方向がおかしいと思います。日本人は笑い話のネタにされるくらい同調性を気にする国民なのかもしれませんが、自分の投票する候補者くらい他者の意向を気にせず選べば良いのにと思います。
投票しない理由に、「投票しても何も変わらないから」というものがあると聞きます（他にも投票しない理由はあると思いますが）。この理由の真意をもっと分析しないことには軽々しく言えないとは思いますが、ようするに「自分の投票した候補者が当選したら「あたり」で、投票して良かったと感じるが、落選したら「はずれ」で、投票なんかして（時間の）無駄だったと思う」ということなのでしょうか。
こう考えているとすると、投票するのは勇気がいるでしょう。何故なら、誰が当選するか分からないと投票できないからです（勝ち馬に乗りたいということでしょう）。一番圧倒的な候補者に投票しておけば無難なのでしょうが、そういう候補者なら「自分が投票しなくても当選するだろう」と勝手に思い込み、結局投票しないかもしれません。
もしかすると、投票するという行為を、宝くじを買うという行為のように考えているのだろうかと思います。「あたる（当選する）なら、宝くじを買いたい（投票してもよい）」が、「あたるかどうか分からないなら、無駄金を使いたくない（時間を無駄にしたくない）」と、博打を打つ感覚なのでしょうか。
投票というのは、結果も大切なのは当然ですが、支持する（しても良いかなと思える）候補者を選ぶという行為に過ぎません。それだけのことです。それをすることが現代社会にコミットすることになりますから、投票しなければ、その人物は存在しているのに「存在していないとして扱われる」という奇妙な状態を選択していることになるでしょう（意識していないかもしれませんが）。
投票（選挙権の行使）は、自分の考えだけでおこなえば良いことで、他者の意向を気にする必要はないはずです。「自分は政治をよくわかっていないから」とか、「皆さんはどうするんですか」とか、こういうことを考えているなら、考える方向がおかしいと思います。日本人は笑い話のネタにされるくらい同調性を気にする国民なのかもしれませんが、自分の投票する候補者くらい他者の意向を気にせず選べば良いのにと思います。
2019-07-19
名詞に「お（御）」を付けるか否か
名詞に「お」や「御」をつけるのは「丁寧語」に区分されます。これは「敬語」を構成する「尊敬語」、「謙譲語」、「丁寧語」の一つに相当する訳ですが、異論もあります。別に敬意を表しているわけではないから「美化語」と呼ぶべきだと主張しますが、今のところ異説のひとつであって、主流にはなっていないようです。
それはともかく、「お」は和語に、「御」は漢語に付けるのが原則です。ならば外来語の扱いが気になりますが、基本的は「お」も「御」も付けないと考えています（若干の例外はありますが）。
上述したルールは原則なので、例外も勿論ありますが、「お（御）」の有無にも個人差があります。社会一般における許容範囲というものもありますが、特定の世間（業界）における習慣なども考えられ、許容度の異なる集団が接触した場合に違和感や反発が生まれるようです。
よく耳にするのが「なんでも「お」を付けておけば無難」とする考え方です。そう考えている人にとっては、「お紅茶」、「おコーヒー」、「おビール（！）」のように表現するそうなのですが、僕には違和感があります。特に「おビール」とか言われたら「ここはいったいどこなんだ」と思うでしょうが、 「お酒」という表現には違和感がありません。「おビール」と「お酒」で良し悪しが分かれるのは、社会的習慣のなせる業としか言いようがないでしょう。
「お」を付ける語と付けない語の分別は、社会における合意があるようで、微妙なところで一致していないと思われます。だから差異が出てしまうのは仕方のないことで、その違いを愉しむことがコミュニケーションの醍醐味であるのかもしれません。少なくとも、「お」の有無に目くじらを立てて、自分の基準に相手を合わせようと仕向けるのは、多様性を認める社会のあるべき姿ではないと考えます。
さらに考察を進めると、「お」が付くことで意味が変わる場合があります。例えば「受験」という語はどうでしょうか。「お受験」となる場合、「お」を付加したことによる「丁寧語（美化語）」というだけではない含意があります。誰かに対して「受験するのですか？」と尋ねた場合と、「お受験するのですか？」と尋ねた場合は、意味が変わってきます。前者であれば、誰もが経験するような高校受験や大学受験などを想像しますが、後者であれば、（エリートコースを狙っているか否かわかりませんが）私立の小学校受験（もしくは、中学校受験や、場合によっては幼稚園受験など）が言外に意味している筈です。
さらに「勉強が得意ですね」と「お勉強が得意ですね」を比べれば、前者なら誉め言葉として受け取れますが、後者だと（誉め言葉だと主張できる余地を残していますが）あてこすりと判断されてもやむを得ない側面があります。
このように「お」という語は日本の文化や社会現象を表象していると考えてよいだろうと思います。
派生的な話題となりますが、最近たまに耳にするようになった言葉として「お名前様」というものがあります。「名前」を丁寧に表現するために「お」が付いているのに、それだけでは丁寧さが表現できていないと考える人が多くなっている模様です。「なんでも「お」を付けておけば無難」とする発想の延長線上に、「なんでも「様」をつけておけば無難」とする発想が生まれてくるのでしょう。これは現代日本に限った現象ではないだろうと思います。例えば「御御御付け」という言葉があるように、丁寧さを狙って生まれた語彙が、丁寧さとしての感覚を失った際に、さらなる丁寧語が付加されるのは、昔からある現象ということでしょう。
それはともかく、「お」は和語に、「御」は漢語に付けるのが原則です。ならば外来語の扱いが気になりますが、基本的は「お」も「御」も付けないと考えています（若干の例外はありますが）。
上述したルールは原則なので、例外も勿論ありますが、「お（御）」の有無にも個人差があります。社会一般における許容範囲というものもありますが、特定の世間（業界）における習慣なども考えられ、許容度の異なる集団が接触した場合に違和感や反発が生まれるようです。
よく耳にするのが「なんでも「お」を付けておけば無難」とする考え方です。そう考えている人にとっては、「お紅茶」、「おコーヒー」、「おビール（！）」のように表現するそうなのですが、僕には違和感があります。特に「おビール」とか言われたら「ここはいったいどこなんだ」と思うでしょうが、 「お酒」という表現には違和感がありません。「おビール」と「お酒」で良し悪しが分かれるのは、社会的習慣のなせる業としか言いようがないでしょう。
「お」を付ける語と付けない語の分別は、社会における合意があるようで、微妙なところで一致していないと思われます。だから差異が出てしまうのは仕方のないことで、その違いを愉しむことがコミュニケーションの醍醐味であるのかもしれません。少なくとも、「お」の有無に目くじらを立てて、自分の基準に相手を合わせようと仕向けるのは、多様性を認める社会のあるべき姿ではないと考えます。
さらに考察を進めると、「お」が付くことで意味が変わる場合があります。例えば「受験」という語はどうでしょうか。「お受験」となる場合、「お」を付加したことによる「丁寧語（美化語）」というだけではない含意があります。誰かに対して「受験するのですか？」と尋ねた場合と、「お受験するのですか？」と尋ねた場合は、意味が変わってきます。前者であれば、誰もが経験するような高校受験や大学受験などを想像しますが、後者であれば、（エリートコースを狙っているか否かわかりませんが）私立の小学校受験（もしくは、中学校受験や、場合によっては幼稚園受験など）が言外に意味している筈です。
さらに「勉強が得意ですね」と「お勉強が得意ですね」を比べれば、前者なら誉め言葉として受け取れますが、後者だと（誉め言葉だと主張できる余地を残していますが）あてこすりと判断されてもやむを得ない側面があります。
このように「お」という語は日本の文化や社会現象を表象していると考えてよいだろうと思います。
派生的な話題となりますが、最近たまに耳にするようになった言葉として「お名前様」というものがあります。「名前」を丁寧に表現するために「お」が付いているのに、それだけでは丁寧さが表現できていないと考える人が多くなっている模様です。「なんでも「お」を付けておけば無難」とする発想の延長線上に、「なんでも「様」をつけておけば無難」とする発想が生まれてくるのでしょう。これは現代日本に限った現象ではないだろうと思います。例えば「御御御付け」という言葉があるように、丁寧さを狙って生まれた語彙が、丁寧さとしての感覚を失った際に、さらなる丁寧語が付加されるのは、昔からある現象ということでしょう。
2019-07-18
「微分方程式('17)」と検算のためのWolfram AlphaやMaxima
放送大学で今期は「微分方程式('17)」を受講しています。もうすぐ単位認定試験が行われるので、試験準備のために勉強しています。過去に受講した科目では、試験ぎりぎりになって慌てずに済むように4月から勉強しておけば良かったと（強く）思いながらも、6月末から7月になってから一夜漬けで試験勉強を済ませ、なんとなく単位を取得していました。こんな方法では身につかないと、いつも思うのですが、他にもやることがあることを言い訳にして、いつも直前に焦って試験対応をしていました。
今回は講義の進行に合わせて4月から勉強してきました。印刷教材の章末問題も解き、通信指導についている自習型問題も解いてみました。過去に受講した科目では、これらをやろうと思いながらも、手つかずのまま単位認定試験に臨んでおり、その結果として不完全燃焼感が後に残りました。その反省を踏まえて、4月から少しずつ勉強してきたわけですが、それでも微分方程式は簡単ではありません。印刷教材の内容も、あまり理解できずにいる箇所も少なくありません（特に証明）。 しかしながら、今までは微分方程式（や微積分）は五里霧中という感じでしたが、僅かに薄日が差してきたような気もしています。何事もそうかもしれませんが、勉強してみて分からなかったからと言って投げ出さず、振り落とされそうになってもしがみついていたら、僅かずつでも理解できるようになっていくのではないかと思います。スラスラできるようになれば嬉しいですが、そうでなくても一歩前進したことは間違いありません。
微積分のような理数系科目は、語学のような文系科目に比べると、正誤がはっきりしているので、考えようによっては勉強しやすいとも言えます。微積分を学んでみて、漠然とした概念レベルであれば、別に難しくはないと思います。思考方法の癖のようなものがあったとしても、概念の理解に差し障るほどではないと感じています。それでは何が難しいのかというと、実際に演習問題を解くことです。
理論を理解できているか確認するために、演習問題が用意されている教科書が多くあります。問題が解ければ、理論を理解したと判断されます。もし解けなければ、理論が分かっていないと判断されることになります。理屈の上ではそうですが、実際には問題は解けたけど、理論は理解できていないという事も少なくないのではないかと思います。仮にそうだとしても、演習問題に取り組むことは大切です。問題が解ければ、理解したという気持ちになれますし、問題を解く過程で、教科書に記述されている事柄の意味が分かってくることもあります。
演習を解いて、正解ならば良いのですが、問題なのは不正解だった場合です。よくある間違いは、不正解となった問題を放置して、他の問題に取り組むことです。出来る問題を多数こなした方が良い場合もありますが、不正解の問題について、式の展開などを見直して、間違えたポイントを納得することも大切です。
微積分（に限りませんが）に役立つ道具として「Wolfram Alpha」と「Maxima」を使ってみました。これらの存在は以前から知っていましたが、便利そうな道具らしいと考えているだけでした。どちらにも使い方のコツのようなものがあるので、自分に合った方を使えばよいと思います。今回はWolfram Alphaを多用しました。
Wolfram Alphaを使えば、問題によっては一気に答えが出てきます。便利と言えば便利ですが、自分で勉強しなくても答えが出てくるのは危険でもあります。その答えが導き出される過程を学んでいる筈なので、答えが出てきたことに喜んでいるだけでは、話になりません。しかし途中結果を確認するために使うのであれば、とても役に立ちます。自分の計算が、最終的に正答にならない場合、途中計算のどこで間違えているのかを確認することができるからです。教科書の演習問題によっては、途中結果が示されていないこともありますし、仮に途中結果が示されていたとしても、自分の計算過程とは違う場合もあります。このような場合にWolfram Alphaで計算させてみれば、自分の誤りを見つける参考になります。
Wolfram Alphaを使ってみて便利であることを実感しましたが、無料で使える範囲は制限されており、機能の制限をなくすには有償となるようです。一方でMaximaは、Wolfram Alphaに比べれば素朴な完成度に見えますが、全ての機能を無料で利用できます（自分のマシンにインストールしなければなりませんが）。Maximaが普段使いの道具となるように、使い方を練習しておこうと思います。
今回は講義の進行に合わせて4月から勉強してきました。印刷教材の章末問題も解き、通信指導についている自習型問題も解いてみました。過去に受講した科目では、これらをやろうと思いながらも、手つかずのまま単位認定試験に臨んでおり、その結果として不完全燃焼感が後に残りました。その反省を踏まえて、4月から少しずつ勉強してきたわけですが、それでも微分方程式は簡単ではありません。印刷教材の内容も、あまり理解できずにいる箇所も少なくありません（特に証明）。 しかしながら、今までは微分方程式（や微積分）は五里霧中という感じでしたが、僅かに薄日が差してきたような気もしています。何事もそうかもしれませんが、勉強してみて分からなかったからと言って投げ出さず、振り落とされそうになってもしがみついていたら、僅かずつでも理解できるようになっていくのではないかと思います。スラスラできるようになれば嬉しいですが、そうでなくても一歩前進したことは間違いありません。
微積分のような理数系科目は、語学のような文系科目に比べると、正誤がはっきりしているので、考えようによっては勉強しやすいとも言えます。微積分を学んでみて、漠然とした概念レベルであれば、別に難しくはないと思います。思考方法の癖のようなものがあったとしても、概念の理解に差し障るほどではないと感じています。それでは何が難しいのかというと、実際に演習問題を解くことです。
理論を理解できているか確認するために、演習問題が用意されている教科書が多くあります。問題が解ければ、理論を理解したと判断されます。もし解けなければ、理論が分かっていないと判断されることになります。理屈の上ではそうですが、実際には問題は解けたけど、理論は理解できていないという事も少なくないのではないかと思います。仮にそうだとしても、演習問題に取り組むことは大切です。問題が解ければ、理解したという気持ちになれますし、問題を解く過程で、教科書に記述されている事柄の意味が分かってくることもあります。
演習を解いて、正解ならば良いのですが、問題なのは不正解だった場合です。よくある間違いは、不正解となった問題を放置して、他の問題に取り組むことです。出来る問題を多数こなした方が良い場合もありますが、不正解の問題について、式の展開などを見直して、間違えたポイントを納得することも大切です。
微積分（に限りませんが）に役立つ道具として「Wolfram Alpha」と「Maxima」を使ってみました。これらの存在は以前から知っていましたが、便利そうな道具らしいと考えているだけでした。どちらにも使い方のコツのようなものがあるので、自分に合った方を使えばよいと思います。今回はWolfram Alphaを多用しました。
Wolfram Alphaを使えば、問題によっては一気に答えが出てきます。便利と言えば便利ですが、自分で勉強しなくても答えが出てくるのは危険でもあります。その答えが導き出される過程を学んでいる筈なので、答えが出てきたことに喜んでいるだけでは、話になりません。しかし途中結果を確認するために使うのであれば、とても役に立ちます。自分の計算が、最終的に正答にならない場合、途中計算のどこで間違えているのかを確認することができるからです。教科書の演習問題によっては、途中結果が示されていないこともありますし、仮に途中結果が示されていたとしても、自分の計算過程とは違う場合もあります。このような場合にWolfram Alphaで計算させてみれば、自分の誤りを見つける参考になります。
Wolfram Alphaを使ってみて便利であることを実感しましたが、無料で使える範囲は制限されており、機能の制限をなくすには有償となるようです。一方でMaximaは、Wolfram Alphaに比べれば素朴な完成度に見えますが、全ての機能を無料で利用できます（自分のマシンにインストールしなければなりませんが）。Maximaが普段使いの道具となるように、使い方を練習しておこうと思います。
2019-07-15
System panicked: kernel diagnostic assertion "(l->l_pflag & LP_INTR) == 0 || panicstr != NULL" failed: file "/usr/src/sys/kern/kern_condvar.c", line 170
dynabook SS SX/15AにNetBSD/i386を入れて利用しています。もう10年以上前のマシンなので、いろいろなところが故障していても不思議ではないとは思いますが、本当に故障しているのか、何か他に原因があるのかは見極めなければなりません。
今春あたりから、カーネルが頻繁に落ちるようになりました。酷い時は、ブート中に落ちて、再起動がかかっている最中に再度落ちて、それが何度も繰り返されます。ところが全く問題なく起動できることもあるのです。何が悪いのでしょう。何処が悪いのでしょう。
何が問題なのか突き止めていませんが、感覚的には「公共施設で無料で使えるWiFiを利用していると落ちることが多い」ような気がしてきました。自宅でも落ちることはありますが、外出先と自宅とでは頻度が全然違う感じがしています。
またクラッシュ情報を解析すると、落ちる場所は決まっています。
カーネルの不具合なのか、マシンのハードウェアが故障しているためなのか、どちらの原因なのか判断する情報がありません。なんとか探ってみようと思います。
今春あたりから、カーネルが頻繁に落ちるようになりました。酷い時は、ブート中に落ちて、再起動がかかっている最中に再度落ちて、それが何度も繰り返されます。ところが全く問題なく起動できることもあるのです。何が悪いのでしょう。何処が悪いのでしょう。
何が問題なのか突き止めていませんが、感覚的には「公共施設で無料で使えるWiFiを利用していると落ちることが多い」ような気がしてきました。自宅でも落ちることはありますが、外出先と自宅とでは頻度が全然違う感じがしています。
またクラッシュ情報を解析すると、落ちる場所は決まっています。
# crash -M netbsd.34.core -N netbsd.34
Crash version 8.99.41, image version 8.99.43.
WARNING: versions differ, you may not be able to examine this image.
System panicked: kernel diagnostic assertion "(l->l_pflag & LP_INTR) == 0 || panicstr != NULL" failed: file "/usr/src/sys/kern/kern_condvar.c", line 170
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET(0,104,c011b026,8,c06f2ad3,c1138f1d,0,104,c10a7924,dc6bdee8) at 0
_KERNEL_OPT_BEEP_ONHALT_COUNT(104,0,c10a7924,dc6bdee8,c4d142e0,c516abe8,c516abe4,dc6bdedc,c0db730e,c10a7924) at _KERNEL_OPT_BEEP_ONHALT_COUNT+0x1
vpanic(c10a7924,dc6bdee8,dc6bdf0c,c090c2a0,c10a7924,c10a788b,c115c4c4,c115c4a0,aa,c5169000) at vpanic+0x13d
kern_assert(c10a7924,c10a788b,c115c4c4,c115c4a0,aa,c5169000,c51d61c8,c5169000,c516abe4,c516abe8) at kern_assert+0x23
cv_wait(c516abe8,c516abe4,ffffffff,c00,82000008,c4d142e0,c5169000,dc6bdf94,c02cc9d8,c5169004) at cv_wait+0x1a8
wpi_stop(c5169004,1,8,82000008,2,101,dc9c6010,dc9c6010,c0921aa9,c13de400) at wpi_stop+0x80
wpi_softintr(c5169000,0,c0100400,1674000,1670010,30,c0100010,10,0,1d14020) at wpi_softintr+0x2cb
softint_dispatch(c4d14020,4,37bbaff2,a1a6dfbe,76bef7da,27b6dfdb,dc6c0ff0,dc6c0e2c,dc6c0e80,80050033) at softint_dispatch+0xc1
Bad frame pointer: 0xc4fdbe48
crash>
カーネルの不具合なのか、マシンのハードウェアが故障しているためなのか、どちらの原因なのか判断する情報がありません。なんとか探ってみようと思います。
登録:
投稿 (Atom)