目次
前のページ
2015-01-16 スーパーマリオとパックランドの関係性について
2015-01-20 高柳健次郎の誕生日(1899)
2015-01-20 SIMON は世界初のPCか?
2015-01-20 【追悼】森公一郎さん (LSI-C の作者)
2015-01-21 RAID NAS 、QNAP T-220 購入
2015-01-23 宮永好道 命日(1993)
2015-01-24 Macintosh の発売日(1984)
2015-01-24 QNAPにないもの
2015-01-28 芸夢狂人 誕生日(1953)
2015-01-29 「デフォルト」という言葉の意味
2015-01-29 プログラム言語における「デフォルト動作」
2015-01-31 Landiskと格闘中
2015-01-31 Landisk のデータ復旧
2015-02-09 ビル・メンズチの誕生日(1945)
2015-02-12 フィル・ジマーマン 誕生日(1954)
2015-02-14 おばあちゃんとぼくと
2015-02-14 ENIAC公開日(1946)
2015-02-17 クリストファー・レイサム・ショールズ 命日(1890)
2015-02-28 プログラム教育
2015-03-03 Winファイル共有で「別のマシン」に繋がるトラブルの解決
次のページ
このテーマで書くのは3度目。
最初は、宮本さんの誕生日の記事でした。
そこで、ネット上に書かれていたスーパーマリオの製作に至る話を引用して記事を書きました。
引用した記事の骨子は、スーパーマリオは宮本さんが「パックランド」を研究して作られたものだ、というもの。
参考文献として書籍をあげ、その書籍から引用した「真実」であるかのように書かれていました。
しかし、後でその記事が「嘘だ」と指摘があったのを知りました。
細かな証拠などを挙げていて、納得できる内容の記事だったので信じていたのだけど、嘘だと指摘していたのはゲーム業界事情にもそれなりに詳しい方。
これはちゃんと調べねば…と思ったのだけど、僕の調べた限りでは、嘘だという指摘のほうがなんだかおかしい。
細かく検証して、「嘘だ、という指摘が嘘」であることを明かす記事を書きました。
ただ、元記事に関しても「真実」として書かれている内容がかなり怪しいことも指摘。
どうも、捏造記事であることは事実のようでした。
元記事は「捏造」が入っているけど、ある程度の妥当性はある。
反論記事は全くのデタラメで、反論の体を成していない、という状況でした。
また、結局パックランドとスーパーマリオの関連性に関しては不明なままでした。
2回目の記事に対するコメントを、年末にいただいていました。
故・飯野賢治の書いた本に詳細が載っている、とのことだったので早速古本を探して入手。
ただ、年末年始は忙しくて読む暇がありませんでした。
該当部分は読んだのだけど、何か書くなら全部読破してから、と思ったので。
で、やっと読破したので引用を交えながら、この問題に決着を付けたいと思います。
まず、該当の本について。
「スーパーヒットゲーム学」というタイトルの本で、飯野賢治が他のゲームクリエイター6人にインタビューした本です。
ネット上の評判では、意味が解らないとか、飯野賢治が偉そうすぎてムカつくとか、そういう意見もあります。
これは、「ゲーム作成経験者同士」だから分かり合えるような、一般向けでない話こそ知りたい、という意図でインタビューが行われているからです。
飯野賢治は年下であるにもかかわらず友達口調で話しかけているのだけど、これも気さくに話をしてもらうための配慮の模様。
(たしかに、元々偉そうな人ではあるのですが、話題のそこかしこに「尊敬の念」はあふれているため、僕は友達口調を馴れ馴れしいとは感じませんでした)
意味が解らないことに関しては、宮本さんに対するインタビューとしては、次のような部分がありました。
(スーパーマリオに関しての話題)
飯野 ところで、土管に入って下の世界に行くというのは、あれはどういう発想ですか? めちゃくちゃ変ですよ、あのアイデアは、普通考えつかない(笑)
宮本 その前作の『マリオブラザース』の時に、困ったんだよ、最初。下に行ったときにどうやって上に上げようか。あれは本当に困った。僕、数週間ずっと困っていてね。家の帰り道に崖からドカッと土管が出ているのを見て、プラスティックの簡単な土管やけど、そうか、土管に入っていって土管から出てきたら裏で不思議なことが起こっているかもわからん。それで、土管が『マリオブラザース』のキービジュアルになった。それから、土管を描き込むならニューヨークやと。
飯野 なんでよ(笑)。
この話題、これで終わりです。「ニューヨーク」って唐突に出てきて、それに関する説明は無し。
マリオブラザースのどこら辺がニューヨークなのか、全く意味不明。
飯野賢治の「なんでよ」ってツッコミは、そこに向けられたものなのですが、答えはありません。(宮本さんがこのツッコミに応えず、話を続けたため)
ただ、ある程度知識のある人なら言っていることの意味が解るでしょう。
ニューヨークの下水には巨大な白いワニが棲んでいる。
これ、結構有名な都市伝説で、アメリカ人なら誰でも知っています。
1930年代にはすでに出回っていた伝説で、ニューヨークの下水道整備が比較的早かったこと、それが故に誰も全容を理解できていないこと、非常に繁栄した都市であるがゆえに「負の部分」の噂を人々が面白がったこと、などが話の背景にあります。
下水道には餌となるネズミもたくさんいるし、白いのは日が当たらないため、などと信憑性を高める「小道具」もあふれています。
筒井康隆も小説のネタにしていたと思うし、アメリカの映画などでもネタにされます。だから、日本人でも知っている人は多いです。
ちなみに、この都市伝説にはバリエーションが多く「下水道にロシアの潜水艦が潜んでいる」なんてものまであります。
下水道を進んで行って潜水艦をやっつけるゲーム、なんてのもある。
こういう背景を知っていると「土管ならニューヨーク」という発想が理解できます。
そして、下水道の中に増えてしまった生物を退治する、というマリオブラザースが出来上がるわけです。
ここら辺が理解できない人は「何言ってるんだかわからない」という反応になるのでしょう。
#上の部分には何の解説もなく、本当に「意味不明」になりやすいのですが、ゲーム関連の話題に関しては、この本ではたくさんの脚注がついています。
ただ、この脚注を誰がまとめたのか、間違えだらけなのね…
飯野賢治は正しい認識で話をしている感じなので、脚注を付けたのは別人でしょう。そして、ゲーム愛が足りない。
良い本なのですが、ちょっと残念な部分です。
飯野 なるほどね。でも、『スーパーマリオ』の登場は、すごく突然な感じがしたんだけど。ゲームの進化の中で突然あの世界は(笑)。
宮本 『パックランド』がありました。それまでにジャンプゲームと言うものを作ってましたでしょ。僕はナムコシンパで、ジャンプゲームをやってこないナムコにすごい敬意を払っていたんです。僕らが作っているジャンプゲームをいじってこない。ところが、『サーカスチャーリー』とか、よその会社からその手のゲームがどんどん出てきて、我が社も当然、一番最初の『ドンキーコング』のときにスクロール的なものを始めている。あの頃すでに、『スクランブル』とかはあったから、スクロール基板が欲しかった。それが、『マリオブラザース』で一応完結しましたね。しかし、でかいキャラクターのスクロールジャンプゲームとなると、うまくいかない。唯一あったのはカメを上から踏むっていうアイデアだけ。
飯野 何で突然、カメを踏もうと思うんですか(笑)。そこが変ですよ。
宮本 キャラクターが小さいと分かりにくいから、大きくなった時に踏むというジャンプゲームの実験はしてたんです。そんな時にナムコから『パックランド』が出てきた。ゲームセンターで、僕、東京に行ったときに『パックランド」が置いてあって、ナムコがジャンプゲームに手を出してくるのかと、それなら俺がやってやろうじゃないかと。それがきっかけ。
これが「パックランド」と「スーパーマリオ」の関係性を伝える核心部分。
詳しくない人のために解説しておくと、当時のゲーム業界は広がりを見せ始めた時期です。
みんなが「インベーダーゲーム」の真似をして出来上がったゲーム業界で、他社のコピーや真似をするだけでは、ライバルが多くて辛くなってきます。
そこで、アイデアを競う時代に入ります。一番突拍子もないアイデアを次々出し続けていたのは、ナムコ。ギャラクシアンはインベーダーの延長上にあるゲームでしたが、パックマンでは「食べる」、ディグダグでは「掘る」という動作でゲームを作り、マッピーでは「ドア」を武器としてしまいました。
誰も考えつかないようなものからゲームを着想する、この点でナムコは一目置かれる存在でした。
一方、任天堂は「ドンキーコング」で、ジャンプする、という動作を取り入れます。
(この書籍では、ドンキーコングが何処から着想されたかも明かされています)
このアイディアはすぐに他社にまねされることになります。
サーカスチャーリー(コナミ)は、その中でも特に売れたゲームの一つ。
でも、ナムコは真似しようとはせずに、常に「オリジナル」のアイディアを大切にしていた…
ここまでが、宮本さんが「ナムコに敬意を払っていた」と語っている理由。
ところが、ナムコは「パックランド」でジャンプアクションを作ります。
これに対し、ジャンプアクションは任天堂が始めたものだ、もっと良いものを作ってやる、というのがスーパーマリオを作るときの気持ちにあった、と語っているのです。
ただ、スーパーマリオがパックランドの真似か、というとそうではない。
パックランド以前から「横スクロールして、大きなキャラが冒険するジャンプアクション」の構想はあったと語っています。
いろいろ実験していて、アイデアの断片もあって、でもうまくまとまらなかった。
それがパックランドの影響で一気にまとまった、という形。
引用部分に「ドンキーコングのときにスクロール的なものを始めている」とあるのですが、多くの人が知っている通り、ドンキーコングはスクロールしません。
どうやら、ドンキーコングの時に「スクロールする」構想はあったけど、ハードウェアの問題で見送った、ということのようです。
「マリオブラザースで完結」というのも、スクロール「できない」という制約の中でやるのは、これで最後にしよう、という気持ちだった様子。
つまり、制約があって作れなかっただけで、かなり早い段階から「スクロールして冒険する」ゲームを考えていたようなのです。
スクランブルの話も出ていますが、あれは当時の大ヒットゲーム。同じような機能があれば…というアイデアは膨らんでいたのでしょう。
また、ジャンプアクションと横スクロールゲームのヒットがあったのだから、「パックランド」と「スーパーマリオ」が似ているのも道理。
真似したのではなく、時代の流れだった、ということになるでしょう。
ここら辺はインタビューの全体を読まないとわからないのですが、流石にすべて引用できないので、気になる人は本を入手して読んでください。
改めて、今回の記事に繋がる大元となった記事を読んでみました。
(すでに、執筆者により削除されていますが、インターネットアーカイブに保存されています)
元記事、あたかも「宮本さん自身が明らかにした事実」であるかのように書かれています。
しかし、今回読んだ本と食い違う部分が多々あります。
特に「パワーアップ」に関する部分は大幅に食い違っている。
宮本さんの思考では、スーパーマリオは最初に「大きなキャラが動く」という目標があって、それだけだと大味なゲーム展開になるので「やられると小さくなる」という形式が出来たのだそうです。
だから、ゲーム上はパワーアップに見えるけど、実際の思考過程ではパワーアップではない。
これをパックランドよりもわかりやすい「パワーアップのアイディア」を考えた、とする元記事は、明らかにおかしな内容です。
また、パックランドでは「攻撃手段が乏しい」ために踏みつけられるようにした、というのも違っている。
引用個所にあるように、パックランドを見る前から、大きいキャラで踏みつける、という攻撃方法は決まっていました。
これらの食い違いから、元記事は捏造記事だったと断じても良いかと思います。
実のところ、僕が2回目に書いた検証記事でも、おそらく捏造だという判断はしていたのですが、さらに裏付けられた形です。
宮本さんが明らかにした、という形式を取らず、外形から状況判断してこうだったのではないか…という類推記事であれば問題ないレベルだったと思うのですが、残念ながら宮本さんの名を語った時点で「嘘」と言われても仕方がない。
でも、嘘だと論じた反論記事は、すでに書いた通り反論の体を成していません。
反論記事の骨子は「スーパーマリオを作る際にパックランドが参考に出来るわけがない」という状況証拠の提示でしたから。
今回入手した本で、宮本さん自身が「パックランドが影響している」と語っています。
参考に出来るわけがない、という反論自体が、嘘です。
2つの問題記事、結局どちらも嘘でした、という結果です。
(これも前回すでにわかっていたこと)
関連ページ
スーパーマリオブラザースの発売日(1985)【日記 14/09/13】
別年同日の日記
20年 mysql で varchar を int に alter table する。
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はテレビの父、高柳健次郎の誕生日(1899)。
テレビの父、と呼ばれる通り、テレビの基礎技術を完成させた人です。
日本人ですが、この方法が世界中で使われていたのだからたいしたもの。
テレビだけでなく、光と電気の関係する産業を起こしたのも功績です。
カミオカンデ作成には欠かせない、高性能の光電子倍増管を世界で唯一生産できる浜松ホトニクスも、高柳健次郎の教え子が興した会社です。
詳しくは、命日の際に書いています。
ところで、アナログテレビ放送の時代、日本は NTSC でしたが、世界的には PAL という規格もありました。
全然違う規格なんで、テレビゲームとか作るときに大変なんだわ。
NTSC は秒60コマ。PALは秒50コマ。
1秒間に送り出せるドット数はほぼ同じで、結果としてPAL の方が解像度が高い。
静止画での美しさを取るか、動画にしたときの滑らかさを取るか、開発者の思惑が違ったのかなー、なんて思ってたのですが、これ、単に家庭用電源の交流周波数を元にしているんだそうです。
アメリカでは 60Hz 、ヨーロッパでは 50Hz。
なるほど、ただそれだけの話か。
NTSC も PAL も、それ以前の「白黒放送」との互換性を保ったままカラー化した方式です。
そして、白黒だった当時、一番簡単・安価に「周波数を作り出す方法」は電源の周波数をそのまま流用することだった、というのも理解できる話です。
#日本では地域によって周波数が違うので、発振回路が別途必要となり、安価な製品は作りにくい。
国内でしか通用しない独自技術が必要となる、というルーツはこの頃からあったのだな。
同じテーマの日記(最近の一覧)
関連ページ
森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
少し前の GIGAZINE に、世界で最初の PC として「サイモン(SIMON)」を掲げる記事が出ていました。
ツイッターでは当日中に異論を唱えたのだけど、ちゃんとまとめておきましょう。
なお、異論を唱えたと言っても、GIGAZINE の記事が誤りだというわけではありません。
これについては後述。
以下、海外でサイモンについて詳しいサイトからの情報です。
技術を紹介したページなので、翻訳ではなくて、読み解いて解説しなおしたもの。
でも、元ページの図などを一緒に見るとわかりやすいです。
サイモンは、ラジオエレクトロニクス1950年10月号の表紙を飾り、それから1年にわたって解説記事が連載された機械です。
リレー回路を使ったデジタル計算機で、紙テープを使ってプログラムを作ることができます。
実用品と言うよりは、将来のコンピューター技術者を育てるための教育用でした。
プログラムには5穴紙テープを使います。
当時はテレタイプ用として普及していました。
#テレタイプについても解説したいけど、ここでは関係ないので割愛。
まぁ、紙テープは当時の「普及した保存メディア」で、簡単に手に入ったことだけ理解できれば十分です。
5穴紙テープは、紙テープの「幅」方向に、5つの穴を開け、読み取ることができます。
この5穴を「1列」とします。1列が 5bit 、ということですね。
テープの続く限り、何列も穴を空けることができ、長いデータを保存できます。
また、テープ自体は切ったりセロテープで貼ったりして編集できます。
その意味で、長さの制限は特にありません。
計算機自体は、レジスタを 16本持ちます。CPU として見るとなかなか豪勢。
でも…メモリを持たない機械なので、これが「全メモリ」です。
レジスタは基本的に1本が 2bit です。
ただし、2bit のレジスタを2本まとめて 4bit として使えるレジスタ(IR1/IR2)が1本と、4bit のレジスタ(CR4)が1本あります。
テープにプログラムを組む場合は、5穴のうち4つを使い、それを3列で命令を表します。
(各列のつかわない1bitは、内部制御のフラグに使用します)
3列のうち、1つはデータを示します。
テープから読み込まれたデータは、常に 4bit で IR1/IR2 に入ります。
残る2列は、レジスタを表します。
1つは「送り側レジスタ」で、もう一つは「受け側レジスタ」の指定です。
先に書いたようにレジスタは16本なので、穴4つで完全に指定できます。
この「2つの指定レジスタ」間で、データのコピーが行われます。
送り側に IR1/IR2 を指定すれば、いまテープから読み込んだデータを別のレジスタに書き込むことも可能です。
SR1~SR6 は値の一時保存(Storage)用で自由に使えます。
OR1~OR3 は出力(Output)用。
CR1~CR5 は計算(Compute)専用。
OR1~OR3 は、ビットが電球に繋がっています。
計 6bit ありますが、OR3 は1個しか電球がつながっておらず、出力は5bitになります。
電球に繋がっている、ということを除けば普通のレジスタなので、読出しも可能です。
CR4 は 4bit ですので、IR1/IR2 の値を 4bit すべて書き込むことしかできません。
そして、CR4 に書き込みが行われると、CR1~CR3の数値を元に「計算」が行われます。
結果は CR5 に書きだされます。CR5 は読み出し専用で、書き込むことはできません。
CR4 に書き込む計算指示は 4bit ですが、9種類だけ作られていて、残りは未定義です。
以下、C言語風に書くと、命令はこうなっています。
算術演算:
CR1 + CR2
-CR1
キャリー付算術演算:
CR1 + CR2 + CRY
-(CR1 + CRY)
ビット演算:
CR1 & CR2
CR1 | CR2
~CR1
選択:
(CR2 > CR1) ? 1 : 0
(CR3 & 1) ? CR2 : CR1
以上の9個が全命令です。
キャリーは、算術演算・キャリー付算術演算で生じます。
これはレジスタではなく、計算回路に 1bit のフラグとして保持されています。
命令には、選択はあるけど、条件分岐はありません。それどころか、ジャンプ命令が無い。
メインメモリが無くて「紙テープ」にプログラムが書かれているのだから、ある意味当然です。
紙テープに直接書かれているプログラムが、直接「計算」を指示するのではなく、「データ移動」だけ。
計算指示は CR4 にデータを移動することで表現。
今の CPU から見るとちょっと変わったプログラム方法ですが、いまだってデータ転送がプログラムの中心で、計算は時々…だと思えば、それほど変わっているわけでもありません。
2bit の足し算しかできませんが、補数を求められるので引き算にも応用できます。
また、キャリーフラグはあるため、多倍長演算に拡張できます。
もっとも、結果出力が 5bit しかないので、結果が 0~31 に収まる計算しかできません。
紙テープには、各列 1bit づつの余りがあります。
これを使って、「プログラムの終了」を表現することができました。
でも、これはただ単に「終了」なのね。
条件が整ったら終了、とかではない。紙テープの終わりに来ても終了するのだけど、途中で明示的に打ち切れるだけ。
つまり、条件ジャンプも、条件停止もできません。データは制御できるけど、プログラムは制御できないのです。
これが何を意味するかというと、掛け算は作れても割り算は作れない、ということです。
割り算は「何回引けたか」が答えなので、「引けなくなった」という条件によって「停止」する必要がある。
ここら辺が、サイモンのプログラムの限界です。
ちなみに、後にスケッチパッドを作り、CGの世界を切り拓いたサザーランドは、幼少のころに兄と一緒にサイモンを使っていたそうです。
詳細はサザーランドの誕生日に書いたけど、彼はサイモンを改造し、割り算プログラムを作っています。
CR4 に与える命令は、4bit まで可能だけど9種類しかありませんでした。
残り7命令文、拡張の余地があります。
恐らくは、どこかに「条件停止」を追加したのでしょうね。
ジャンプ命令は無いので、「何回引いたか」を調べるために、理論上最大の長さまで命令を繰り返しておく。
(現代風に言えばループ展開です)
そして、割り算の結果が出た時点で条件停止します。
残りの命令は実行されずに終わるのだけど、それでいい。
これが、プログラムの紙テープが 2.4m にも達した理由でしょう。
複雑なプログラムを組んだから長いのではなくて、ループ展開したから長いだけ。
さて、最初に書いたように、僕はこの機械が PC だというのに異論がありますが、ギガジンの記事が誤りだとは思いません。
まず、GIGAZINE の記事は、海外記事を翻訳しただけの受け売りで、GIGAZINE の記者は記事の内容を理解できていません。
だから、GIGAZINE に誤りはない。誤りがあるとすれば元の海外記事。
この記事自体は「PCの定義」から始まっています。
なにを PC と呼ぶかは不明だけど、「定義した内容にしたがって」最初の PC を紹介する、という体裁。
ここでは、誰でも手に入るほど、入手容易で安価なデジタルコンピューターでプログラム可能なもの、とされています。
(GIGAZINE では、コンピューターを「計算機」と訳し、「デジタル計算機である」ことを定義としています。
しかし、元記事では「コンピューター」と書かれているので、ここではコンピューターとします)
ところで、計算機(カリキュレーター)と、コンピューターは違います。
カリキュレーターは、ただ計算を行うだけの機械。
カリキュレーターの中には、計算手順をプログラム可能なものもあります。
なので、プログラム可能であることはコンピューターの条件ではありません。
元々、コンピューターは計算手…計算を行う「人」を意味した言葉です。
一定の手順…アルゴリズムに従って計算を行えます。
アルゴリズムには、条件の「判断」が多数含まれます。
そうでない場合、プログラムが可能で、その手順がどんなに複雑でも、単一の「計算式」を示しているにすぎません。
カリキュレーターとコンピューターをわけるのはこの部分です。
コンピューターであれば、プログラムの「条件分岐」か、最低でも「条件停止」を持っていることが条件となります。
そして、サイモンはこうした命令を持っていないのです。
(サザーランド兄弟による「改造サイモン」には条件停止がありましたが、改造するには高度な知識が必要です。これはすでに「特殊な訓練を受けていなくても使える」という元記事の要件を満たしません。)
ただ、どこまでがカリキュレーターで、どこまでがコンピューターか、というのも人によって解釈はさまざま。
サイモンは条件分岐や条件判断は持ちませんが、条件によって値を変える命令はあります。
元記事を書いた人たちは、古いコンピューターを保存するのを目的とした人たちですから、ここまでに書いたような議論は全部了解したうえで、あえて「サイモンが最初」と書いたのだと思っています。
当ページでは、リレー式計算機はコンピューターには含めていません。
電気では動きますが、物理的動作があるために遅く、いわゆる「電子計算機」としての要件を満たさないためです。
サイモンはリレー式なので、僕としては最初とは考えません。
部品が違うだけで原理的には同じなので、含めるという考えがあったって一向に構わないのですけどね。
GIGAZINEの記事中では、PDP-8 は「高かったから選外」となっているのですが、実際には PDP-8 は安価だったが故の大ベストセラーマシンで、長年売られていたために技術の進歩に合わせてどんどん値下げされました。
当初の値段は $18,500 で確かに高価なのですが(質素な家が買える値段、だったようです)、後には 1/10 程度まで下がりました。
特に「複数台買うと値引き」もあったので、会社のと併せて2台買ってしまおう(BUY TWO, TAKE ONE HOME)、なんてキャンペーンもあったようです。
そんなこともあって、最初の「個人でもなんとか所有できるコンピューター」としては PDP-8 はギリギリの線かな、と思っています。
#もちろん、本当に「気軽に」買えるのは、値段的にもサイズ的にも Altair8800 だと思います。
実際、PDP-8 ではゲームとか音楽演奏とか、仕事ではない、個人のためのフリーソフトが沢山作られました。
後のパソコン文化を先取りしていた、と言ってもいいでしょう。
あと、個人で遊べるコンピューターとしては TX-0 推し。1台しかないプロトタイプなので、所有は無理でしたが。
(GIGAZINE の記事にも出てきませんし)
テレビゲームも多数作られています。面白くもない計算用途ではなく、面白いからコンピューターを使う、というのは「個人のための」の重要要件だと思います。
ちなみに、サザーランドはサイモンで基礎を学びましたが、TX-0 でコンピューターの可能性に目覚め、後継の TX-2 でスケッチパッドを作っています。
当時はまだコンピューターが高価な時代。お絵かきのために「個人で占有する」なんていうアイディアは、当時としては驚きを持って迎え入れられました。
スケッチパッドのアイディアを元に SmallTalk が着想され、Alto が作られます。
Alto は、GIGAZINE の記事にも出ているね。
そして、Alto が Macintosh や Windows を生み出したわけで、PC のルーツをたどると TX-0 に行きつく、と思っています。
TX-0 は「個人でコンピューターを使う」というハッカー文化を生んだ機械でもあり、「誰かが作ったプログラムのソースを入手して改造できるのが当然」なんていう、オープンソースの概念はここから生まれています。
GNU の創始者である RMS も TX-0 の作った文化を知る最後の世代です。
同じテーマの日記(最近の一覧)
関連ページ
森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
LSI-C の作者の方が一昨日亡くなった、という訃報を Twitter で読んだ。
LSI-C ならずいぶんお世話になった、と詳細を読むと、LSI-C 80 の開発者だという。森公一郎さん。
アルバイトで一緒に開発を行った、という近藤嘉雪さんが訃報を伝えていた。
僕がお世話になったのは LSI-C 86 。80 は存在すら知らなかった。
しかし、86 は 80 の後に開発されたらしい。多分改良品なのだと思う。
というわけで、きっと僕もお世話になった方なのだ、と勝手に推察して思い出話など書く。
近藤さんによれば、LSI-C 80 は、参考にするものが無い状態で開発されたらしい。
もちろん、C言語を作るのだから、C言語の仕様書(K&Rかもしれない)などはあったのだろう。
C言語を使って、動作を確認することも出来たかもしれない。
でも、gcc など、今では手に入る「C言語処理系のソース」は入手できない状況での開発。
yacc とかは使えたのかな。
これが使えるとコンパイラを作るのはずいぶん楽になる。
もっとも、yacc は UNIX のツールで、メモリはふんだんにあるのを前提としている。
そもそもが、C言語自体が広いメモリと多数のレジスタを前提としている。
8080 で動作するように、CP/M で、64K のメモリで動作するように作った、というのだからすごいと思う。
現在でも、LSI-C 80 は製品として販売されているようだ。
もちろん、CP/M 用ではない。Windows などの現代の OS 上で動作し、8080 などのコードを生成する。
現在は Ver.3 だが、Ver.2 の時点で MS-DOS 用のクロスコンパイラだったようだ。
パソコンが 16bit の時代になっても、組込み用に 8080 や Z80 は使われていた。
クロスコンパイラに需要があるのだろう。
セルフコンパイルからクロスコンパイルに移行できた、ということは、コンパイラ自体もC言語で書いていたのだろう。
8080 上でC言語をC言語で書き、セルフコンパイルする。
…いや、それは難しいか。絶対無理とは言わないけど、開発効率が悪そうだ。
16bit マシン上で、8080 のコードを生成するコンパイラを作成し、16bit 環境からクロスコンパイルできるようにして、最後にコンパイラ自体を 8080 用にコンパイルしたのかもしれない。
そして、ver.2 の時に、同じソースを 8086 用のコンパイラにかけて(LSI-C 86 だろうか)、クロスコンパイル環境とする。
そうなると、森さんが作ったソースがまだ使われているのかもしれない。
#翌日追記:CP/M 上の BDS-C で開発されていたそうです。BDS-C は、1970年代からある 8080 用のC言語実装。
詳細は最後に。
ネットで調べると使ったことのある方の話なども結構出てきて、「LSI-C 80 の生成するコード品質は異常」(に良い)だそうだ。
C言語と言う言語構造があまり 8080 向けではないのだが、それで品質の高いコードを生成するのだというからすごい。
先に書いたように、C言語で書いているのだとしたら、8080 上で動作するC言語を生成している、という時点でその品質は折り紙付きだ。
そして、ソースがCであれば、生成するコードの部分を作り変えたのが LSI-C 86 だったのではないかなぁ、と思う。
やっと LSI-C 86 の思い出話に入れた(笑)
当時はC言語は高価だった。安いものでも数万円から、信頼のある処理系なら10万円していた。
でも、LSI-C 86 は、「試食版」という名前のサブセットを、なんと無料で配布していた。
サブセットとはいっても、言語機能に特に問題はない。
テキストデータだけどマニュアルもちゃんとついてくる。
当時の MS-DOS は、8086 のメモリ管理にべったりだったので、メモリが 64K ごとに断片化していた。
C言語は本来「連続した大きなメモリ空間」を想定して作られているので、MS-DOS のCコンパイラでは「メモリモデル」という、複雑怪奇な仕組みを取り入れざるを得なかった。
コードとデータをあわせて 64K に収まるなら「タイニーモデル」。
コードとデータ、それぞれで 64K 以内、全体で 128K 以内なら「スモールモデル」。
コードは 64K 以内だけど、データが 64K 以上になるなら「ミディアムモデル」。
コードは 64K 以上だけど、データが 64K 以内になるなら「コンパクトモデル」。
コードもデータも 64K 以上なら、「ラージモデル」。
コードまたはデータが 64K 以上で、ポインタ比較などを使用する必要があるなら「ヒュージモデル」。
タイニーモデルで生成されるのが .COM ファイルで、これ以外は .EXE ファイルになる。
ヒュージの説明が必要だ。ラージとどう違うのか。
8086 では、64K 以上のアドレスが必要な場合は、2つのレジスタを足してアドレスを表現する。
もっと厳密に言えば、2つの16bit レジスタのうち、一つ(ベースと呼ぶ)は 4bit シフトしてから、もう一つ(オフセットと呼ぶ)はそのまま足す。
すると、20bit の結果が得られる。1Mバイトのアドレス空間だ。
一方、ポインタを比較しようとすると、基本的に「オフセット」をそのまま比較しようとする。
64K 以内なら、ベースは同じで、オフセットが違うだけ、のはずだからだ。
ところが、64K を超えると話がおかしくなってくる。
64K を超えたアクセスでは、ベースも頻繁に変わることになる。ポインタのインクリメント/デクリメントでいちいちベースを変えるのは面倒なので、普段はオフセットしか変えない。
しかし、いざベースを変えるときには、その時によって都合のよいベース値に変更される…
ここで、ポインタ比較が破綻することになる。
そこで、ヒュージモデルでは、ポインタを正規化する。
ベースを 16bit フルに使い、オフセットは必ず 0~15 、つまり下位 4bit しか使わないことにする。
インクリメント/デクリメントするたびに 4bit 境界のチェックが必要となり、速度は低下する。
しかし、これでアドレス比較は正しく行われるようになる。
これがヒュージモデルだ。
そもそも、MS-DOS でそんなに巨大なプログラムを作る必要がある時点で間違っている。
しかし、間違っていても必要な時はあるのだ。そんな時に、速度低下を覚悟で使うメモリモデルだ。
…さて、話を戻すと、LSI-C 86 も当然こうしたメモリモデルに対応していた。
でも、「試食版」では、スモールモデルしか使えなかった。
そして、もし生成物を配布するのであれば、対価を受け取らないこと、また LSI-C 86 試食版を使用したことを明記することが条件だった。
もっとも、普通のプログラムならスモールモデルで十分。
だって、コードとデータ併せて 128K って、その時点で 8bit 機の全メモリより大きなもの作れちゃうんだから。
当時は今のようにネット時代でもないし、多くの人は「自分のために」プログラムしているだけ。
そう考えれば、配布条件もたいした問題ではない。
だから、かなり多くの人が LSI-C 試食版のお世話になっていたはず。僕もその一人です。
と言っても、僕は X68k の人だったから、あまり MS-DOS は使ってない。
大学時代は電算機室に PC-98 がたくさん置いてあって、ある程度学生が自由に使えました。
#条件があって、講師の先生かティーチングアシスタントの大学院生、もしくは「マイコンクラブ」のメンバーが部屋にいないといけなかった。
彼らなら、何かトラブルがあった時にすぐに対処できるから。
でも、僕はそのマイコンクラブのメンバーだったから、自由に使えた。
学生が使うマシンにはハードディスクは付いてなくて、フロッピーディスク運用だったのだけど、当時は言語だってフロッピー1枚に収まることが多かった。
FORTRAN とか Pascal とか。
…でも、C言語ってライブラリが大きいから、フロッピーでの運用はちょっと辛い。
ところが、LSI-C 試食版はスモールモデルに絞ってあるから、フロッピー1枚に入るのね。
Comet の 98 移植版作ろうと思ってしばらく奮闘していたのだけど、学校で使っている時間だけだと思うように進まず、モチベーションが続かなくなってやめました (^^;
あと、Handy 98 と、HP200LX でも使っていた気がするな。
携帯機でコンパイル…というのが、実際には無駄なので、使えることに満足しただけだったように思うけど。
Windows の時代になってから、Java のプログラムをしていて「プリプロセッサが欲しい」と思って、LSI-C 試食版のプリプロセッサだけ使おうとしたこともありました。
まぁ、これは Windows のロングファイルネームに対応してなかったんで使えなかったのだけど、こういう時にすぐ思い出す程度には心に沁みついていた。
LSI-C の思い出はこの程度で、「今日は何の日」で、コンピューター関連のいろんな人の誕生日・命日などを書いている僕としては、訃報が伝えられた森公一郎さんの詳細が気になる。
名前で調べたらすぐにWEBページが見つかった。いつまで残されているかは不明だけど。
そこには、プロフィールとして次のように書かれていました。
年齢: 四つの'3'の日に生まれ、三つの'3'の日に33歳になった。牡羊座。
ディオファントスの墓碑のようです。
えーと、牡羊座は3月21日から4月20日。
3が多いのですから、3月30日か31日、または 23日が誕生日なのでしょう。
生年月日ですが、生まれ年に後二つの「3」が必要です。
1933年だとしたら、33年後は 1966 年。3がありません。
ここは、「昭和」33年でしょうね。1958年。
すると、33年後は 1991年。平成3年です。
恐らく、1958年3月23、30、または 31日生まれ。
56歳で亡くなられたのは、まだお若いです。
しかし、WEB ページを見ると人工透析を受けていることも書かれているので、恐らく腎臓の病で闘病しておられたのでしょう。
プログラマとしての偉大な先人の御冥福をお祈りします。
以降は翌日追記
LSI-Cに思い出のある方は多かったようで、想像以上に多くの方からの反響がありました。
上の記事はすでに修正していますが、当初「C言語は広いメモリと多数の32bitレジスタを前提とし…」と書いていましたが、これは勘違いです。
それ、gcc の最適化の前提条件だ。個別の実装系の話で、C言語全体の話ではありませんでした。
ちなみに、最初にC言語が作られた PDP-7 は 18bit マシン。PDP-11 は 16bit マシンです。
そのため、C言語自体は当初から特定のレジスタ幅を前提にはしていませんでした。
#とはいえ、PDP-11 のようなアーキテクチャを念頭に設計していた節はあります。
#18bit が中途半端に思える人は、TX-0の話読んでね。
TX-0 を元に PDP-1 が作られ、その後継機が PDP-4 、PDP-7 です。PDP-11 は全く別の機械。
PDP は開発順に番号が付いているので、系統がわかりにくいです。
日記に、BDS-C を使って CP/M 上で LSI-C を作ったとある、と指摘がありました。
はてなで日記を付けている、と氏のページにあったのですが、見に行った時点で非公開になっていました。
いま情報の裏を取ろうと InternetArchive を少し探しましたがどこにあるかわからず。
しかし、おそらくC言語で作ったのだろうなぁ、と思っていたのが裏付けられたので情報信じます(笑)
C言語使わずに 8080のアセンブラでいきなり書いていた、とかだと、LSI-C 86 とも、現在の LSI-C 80 とも無関係になってしまうから。
自分の思い出(LSI-C 86)につなげたかったのもありますし、氏が亡くなってもソースは受け継がれている、と思いたかったのもありました。
当初、当時のC言語は10万円位するのが普通だった、と書いていました。
TurboC や QuickC はもっと安かったよ、という指摘がありました。
うん、そうだったかも。
実は TurboC の DOS 版は購入して今でも持っています。社会人になって、Windows の時代になってから、安売りされていたのを買ったのだけどね。
安売りとはいえ、元が10万円していたら、当時の僕が手を出せないくらいの値段だったでしょう。
それでも、LSI-C 試食版が無料、というのは驚きでした。
当時の趣味プログラマーに大きな影響を与えたと思います。
「LSI-C 80 のコード品質が異常に良い」というのは言い過ぎではないか、という指摘がありました。
これはね、本文中にもあるように、実際のところは LSI-C 80 は使ったことないからわからないのよ (^^;
ただ、そう評価している人が居たからそのまま書いただけで。
各種評価ある中で、自分が思い入れがあるから「一番良い評価」を選んだのはあります。
ネットで見つかるいろんな人の話を読むと、レジスタの使い方が上手かったようです。
普通は変数はメモリに割り当てるわけですが、8080 はメモリアクセスが遅い。
そこで、一部の変数をレジスタに直接割り振るわけです。
まぁ、ここら辺のことは他のC言語でもやっていること。
興味深いのは、8080 ではレジスタごとに「使える命令」が違っていて、変数を単純にレジスタに割り振るだけでは無理が出てしまうのに、どうやっていたのかな、というところですね。
ここら辺、僕は使っていないので知らない。
そして、こちらも寄せられた情報ですが、LSI-C 80 では関数の呼び出し時に、引数をレジスタ渡しするそうです。
C言語の関数を呼び出す際は、一般的には引数をスタックに積んでから呼び出します。
でも、8080 では先に書いたようにメモリが遅いし、そもそもスタックが 16bit 単位でしかアクセスできない、という制約があります。
そのための工夫なのでしょう。
多分「品質が異常に良い」と評価していた人も、ここら辺の工夫を褒めていたのではないかな、と思います。
#引数をスタックに積んで…で、またツッコミが入りそうなので牽制。
SPARC のことはもちろん知っていますし、printf("%d %d",a++,a++) の結果が処理系依存なのも承知。
MSX にも MSX-C というものがあったのですが、実は LSI-C 80 の OEM 版なのだそうです。
情報を頂いて裏を取ったら、詳細を書いているページを見つけました。
MSX-C のバイナリをダンプすると、LSI JAPAN のコピーライト表示が埋め込まれているとか。
MSX の CPU は Z80 だと決められているにも関わらず、8080 でも実行できるコードを生成するのだとか。
MSX 用に Z80 や R800 のコードを生成するようにする、後付けの「オプティマイザ」も有志の手で開発されていたようです。
同じテーマの日記(最近の一覧)
関連ページ
森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【BDS-C使い】 LSI C-80(CP/M)のOEM変化形のMSX-Cになりますが、BDS CやHI-TEC C(CP/M)でコンパイルしたものよりMSX-Cでコンパイルしたもののほうがサイズが小さくなるので最適化がすごいのは事実だと思いますよ。計測まではしてませんが多分速度も速いでしょう。ただし、8ビットOSでコンパイルする場合はMSX-C(多分本家のLSI C-80も)ではメモリが足らずにコンパイルエラーになることが多いし、8ビットマシン実機ではコンパイル速度がものすごく遅かったです。BDS Cのほうが実用的と個人的に感じました。ただし、LSI C-80のMS-DOS版ではそれらの欠点は感じませんでした。おそらく今のWindows版のLSI CはZ80開発には最強レベルでしょうね。ただしZ80が衰退した現在となるとLSI CのWindows版は有料なのでお金を出して買う人は少ないでしょう。BDS C(CP/M)、HI-TECH C(CP/M)は無料でエミュレーターでWindowsでも動き、他にも無料のz88dk(Windows等)、SDCC(Windows等)がありますし。 (2017-04-01 19:16:32)【ななし】 JavaScriptのyaccを探していたらkmyaccが対応していると見つけて、二十数年ぶりにお名前を見て、でもウェブの更新がとまっているので心配していました。商用C言語コンパイラ実装者の末席のひとりとして、先達の業績には尊敬の念しかありません。ご冥福をお祈りいたします。 (2015-02-07 15:48:43) 【名無し】 MSX C ver 1.1 のパーサとコードジェネレータには"Copyright (C) 1985 by LSI JAPAN Co., Ltd."の文字列が埋め込まれてます。 (2015-01-24 13:14:13) 【中の人】 LSI-C86はLSI-C80を使って bootstrap していました、LSI-C80は最初はBDS-Cでbootstrapしていましたがある程度動き始めたら自身でコンパイルして最後は gcc と同様に自身で生成と言う開発を行っていました。 (2015-01-23 19:59:10) 【名無し】 >MSX-C のバイナリをダンプすると、LSI JAPAN のコピーライト表示が埋め込まれているとか。 手元のMSX-C ver 1.20pのパーサ(CF.COM)とコードジェネレータ(CG.COM)を確認してみましたがアスキーの版権表示があるのみでそのようなものは見当たりませんでした。バージョンに拠るのかもしれませんが…。 (2015-01-23 04:07:06) 【G-SHOES】 思い出深いのは,引数の引き渡しを可能な限りレジスタで行おうとしたコンパイラだったので,出来るだけ引数を少なく,短いビット長で行うように関数仕様を検討していました。16nitの引数を3つも4つも引数にすると間違いなくスタック経由になり,速度が撃オチです。そこで関数を分ける,逆に統合するなどの工夫をやっていたことを思い出します。森さんのご冥福をお祈り致します。 (2015-01-22 08:19:26) 【G-SHOES】 LSI-C80を仕事で使っていた人です。確かにいいコードを生成してくれるので信頼して使っていました。当時のZ80のCコンパイラは正直中途半端で,LSI-Cを使えば遅いCPUでも,小さいメモリでも,なんとか乗り切れた事が多く,極論するとコスト削減に貢献してくれていたということになります。 (2015-01-22 08:14:07) 【あきよし】 おぉ、多数の指摘ありがとうございます。PDP-11が16bitだったのはご指摘の通りで、勇み足でした。他の件も含め、後で記事修正しておきます。 (2015-01-21 11:14:19) 【名無し】 「LSI-C 80 の生成するコード品質は異常」(に良い)というのはちょっと大袈裟ですね。生成されるコードのサイズや実行効率的にアセンブラの代わりになる程のものではなく、当時の他のコンパイラ製品と比べてレジスタの使い方が効率的だった、くらいの説明が適当だと思います。 (2015-01-21 05:03:49) 【名無し】 >当時はC言語なんて十万円くらいするのが普通で、 10万とかいい値段がするのはLettice-CやWhitesmith-C、MS-Cなんかで、TurboCやQuickC等安価な製品も存在しました。 (2015-01-21 00:11:42) 【名無し】 >8080 上でC言語をC言語で書き、セルフコンパイルする。 …いや、それは難しいか。絶対無理とは言わないけど、開発効率が悪そうだ。 日記に「80年代の初めに、BDS-CをつかってCP/MでLSI-Cを書いていました。」と書かれてますよ。 (2015-01-21 00:07:27) 【名無し】 >そもそもが、C言語自体が広いメモリと 32bit の多数のレジスタを前提としている。 C言語の起源が16bitのPDP-7だかPDP-11だかその辺なのでその説はおかしい。 (2015-01-20 23:54:31) |
使っていたNASが壊れた。
RAID1 にしてあったのでデータは壊れてはいないと思う。
定期バックアップを取るようにしてあったのだが、ふと確認してみると取られていない。
なんか調子悪いのかな、とリセットしてみたら、そのまま起動しない。
本体がすごい熱を持っていた。
ファンレスで自然空冷だったのだが、年末の大掃除の際にうっかりすぐ上の棚に荷物を置いてしまったようだ。
#高さギリギリサイズの棚を組んであって、空冷のために棚板を網にしてあった。
直前までアクセスできていたのでハードディスクは大丈夫だろう。
基板がどこか熱でやられたのだと思う。
さて困った。
データはバックアップがあった。先に書いたように定期バックアップが動かなくなっていたが、1か月前のデータは残っていて致命的ではない。
それに、多分 NAS を分解してハードディスクを取り出し、Linux サーバーに接続すれば中身は読み出せる。
特に問題はない。
でも、NAS は日常生活に必須のものとなっている。
「起動しない」NAS は、電源ランプがピカピカ点滅している。起動中の合図だ。
もしかしたら、ディスクチェックとか動いているだけで、しばらくしたら何事もなく動き出すかもしれない。
1日待ってみた。
状況が変わらないので、速攻で新しい NAS 買った。
1日待っている間に、機種選定は終わっていた。
今まで使っていたのは、I/O DATA の LANDISK HDL2-G2.0 だった。
2008年の夏に購入したようだが、残念ながら日記には書いてなかった。
6年半使っていたのか。まぁ、十分な期間働いてくれただろう。
特に問題はなかった。機能的にも十分。
じゃぁ、後継機を買うか。6年もたつ間に、ずいぶん状況は変わっているようだ。
ライバルの BUFFALO 製品も含めて検討してみる。
…うーん。
以前は検討対象にもならなかったようなメーカーも増えている。
ここ6年で、家庭向け RAID NAS はずいぶん普及したようだ。
当初は、値段と信頼性を考えて、ハードディスクセット済みの安い普及品を買おうと思っていた。
しかし、やはり信頼性が重要な製品でもある。
少し高くても良いものを買おう。
で、QNAP の TS-220 と、WesternDigital の RED シリーズ HDD 2T を2台購入。
以前の NAS は 1T *2 だった。これでも半分くらい余っていた。
2T あれば今後5年困らないだろう。
QNAP の家庭向け RAID NAS は、 220 と 221 がある。違いは CPU 速度と搭載メモリ。
実はこのマシン、NAS とは言っているが Linux サーバだ。
CPU が速くて搭載メモリが多ければ、いろんなことができる。
だけど、うちには Linux サーバはすでに2台ある。
変にソフトを多数搭載して不安定になられても困る。
ここはファイルサーバーに徹してもらおうと思うし、そう考えると CPU 速度もメモリも小さくて良い。
TS-220 の方が1万円安くなる。
RED シリーズと言うのは、RAID に特化したハードディスクのシリーズだ。
RAID は信頼性が重要なので高信頼のディスクを…なんて売り文句にはなっているが、特に高いわけではないし、ディスクは普通のものと変わらないようだ。
しかし、RAID NAS を想定したファームウェアを搭載しているようで、特に書き込み速度が速くなるようだ。
さて、そんなわけで現在 NAS は購入し、すでに手元に届き、設定中。
箱を空けると、マニュアルは紙一枚。
1. ハードディスクを本体にインストールせよ。
2. ネットワークと電源をつなぎ、電源スイッチを押せ
3. http://start.qnap.com にアクセス!
絵を入れてあってわかりやすいが、書いてあることはこれだけ。
…ハードディスクのインストールってどうやるんだ?
まぁ、PC 自作した人ならすぐわかるレベルなのだけど、ここでいきなりつまづく人も多そうだ。
で、準備が整ったら URL にアクセス。
ドライブ数を聞かれるので 2-Bay と答え、モデル名が絞り込まれた中から TS-220 を選ぶ。
START NOW を押すと…ハードディスクインストールの方法が、図入りで懇切丁寧に説明される。
なんだよー、インストールしてから URL アクセスしろって指示してたじゃん!
…まぁいい。この後、当然のように電源スイッチを入れるまでが説明されるけど、どんどん飛ばす。
すると、ファームウェアインストールの方法を聞かれる。
WEB ブラウザでそのままインストールするか、ソフトをダウンロード・インストールして実行するか。
面倒なのでそのままインストール。
これでしばらく待たされる。
どうやら、ネットワーク上の QNAP を自動検出し、ハードディスクに OS をインストールしている模様。
Boot パーテションを作っているのだな。
この後、RAID 構成などを聞かれるが、RAID 1 しか選べない。それでいいのだけど。
ネットワークの設定なども聞かれるけど、DHCP サーバがあれば自動的に IP が割り振られているので、設定は必要ない。
もっとも、僕は NAS には固定 IP を割り振っているので変更する。
この時も、すでに割り振られたネットワーク情報を編集することになるので、手間がかからない。よく出来てる。
で、データ領域のフォーマットが始まる。
これが終わると QNAP が自動再起動し、使えるようになる。
(ここまで結構時間がかかるので、この日記を書き始めた)
再起動したら、WEB サーバーでアクセスする。
すると、ブラウザの中に KDE っぽい、というか MacOS X っぽい、というか、そういう GUI のデスクトップが表示される。
GUI の端っこに「通知」が出た。
ミラーリングを開始します。そうか、さっきの「フォーマット」は、DISK 0 に対して行っていたようだ。
再起動前に RAID 1 を選択したので、ここで初めて RAID 1 の構築が始まり、DISK 0 から DISK 1 にコピーが始まったのだ。
しかし、「通知」によって知らせるとは、OS として本格的。
買う前の事前情報だと「リモートデスクトップ」だと書いてあったので、Linux マシンの X-Window 画面を VNC かなにかで飛ばしているのかと思った。
でもそうではなかった。Javascript でそれっぽい画面を作り出すプログラム。
なーんだ、Javascript か、というなかれ。
先の通知もそうだが、なかなか本格的に出来ていて、全く違和感を感じない。本当の OS っぽく操作できるのだ。
そして、操作はリアルタイムに反映される模様。重要な変更なんかは、「更新」ボタン押さないといけないけど、これは間違えたらやり直せるようにしているから。
そして、操作できることは多岐にわたる。本当に多岐にわたる。
RAID の設定とか、NAS のネットワーク設定とか、表の USB に何かが刺さった時の動作、後ろの USB の使い道、冷却ファンの回し方…などなど。
初心者だったら目が回ってしまう。僕は初心者じゃないと思うけど、どこに何があるのかわからないで、さまようことになった。
えーと、とりあえず、バックアップしてある USB ドライブのデータを書き戻したい。
でも、そのための設定がどこにあるのかわからない。
…と、その前にネットワーク越しに見えているかどうかを確認。
あれ、ユーザー名とパスワードを聞かれる。家庭内 NAS なので、認証なしに使えるようにしたいのだけど、どこで設定するかわからない。
何かをしたくても、慣れてないとどこに何があるかわからない。
まずは機能を把握すること。
そう思って一通り見てみる。
USB にプリンタを接続し、ネットワークプリンタにしたりもできる。
自動的に Amazon S3 に特定のディレクトリを同期したりもできる。
NAS なので、SMBやAFPサーバを起動できる。まぁ当然。
FTPサーバやNFSも使える。これは LANDISK にはなかったな。
iTune サーバにもなれるし、DLNA サーバにもなれる。まぁ、NASには良くある機能。
mySQL サーバや、WEB サーバも使える。SSH でログインもできる。
アンチウィルスの設定もできる。VPN 設定も可能。
えーと、ここら辺はやっぱ、NAS というより「むき出しの Linux」な感じ。
App センター、というのがあって、ネットワーク上で公開されているアプリが入れられる。
WordPress とか、Xoops とか MediaWiki とか、簡単にインストールして使い始められる。
Python だって、Perl だって、Ruby on Rails だって、Node.js だってある。
ここら辺になると、NAS に何をやらせたいのか、という感じ。
「SuperMarioBros - Beta」というのがあった。えぇっ!?って感じ。
エミュでも動くのか、と思ってインストールしてみたら、ちゃんとブラウザ越しに Javascript で動いている。
エミュではなくてクローンだ。非常に良くできていて違和感がないのだけど、マリオが戻ると後ろ向きにスクロールする。
これは、元のゲームにはなかった動きなので、エミュではないとわかる。
…いかんいかん。しばらくマリオで遊んでしまったが、早くディスクのバックアップを書き戻さなくては。
これは結局、「バックアップマネージャ」の中の「External Backup」項目の中、というまっとうな位置にあった。
その中には「外部ドライブ」と「ワンタッチコピー」が並んでいる。
外部ドライブからコピーしたい、と思ってそちらを見ていたのが間違いだった。必要な機能は「ワンタッチコピー」の中にある。
この項目の中には、さらに「スマートインポート」「ワンタッチコピー」「外部ストレージドライブとして」という、謎の3項目が並んでいる。
ここで、「ワンタッチコピー」を、意味も解らないまま選択しなくては目的の機能が表示されなかった。
これを選ぶと表示される項目の中に「USB ドライブから NAS にバックアップする」がある。
これを選ぶと、どのディレクトリをどのディレクトリにコピーするのか設定しないといけないのだが、この方法がまたわからない。
結局、全面 USB ポートにドライブを接続し、「USB 機器が接続されました」と通知が出るのを待つのが正解だった。
通知が出てからコピー設定で「追加」ボタンを押すと、接続されたドライブのツリー構造が表示され、コピー元を選べばよい。
同じように、コピー先も選ぶ。
LANDISK とはディレクトリ構成が違うが、ここである程度吸収できるのはありがたい。
設定が全部終わったら、「適用」してから、NAS前面のボタンを2秒ほど押す。
後は自動でコピーされるのを待つだけ。結構時間がかかる。
まだまだ設定しないといけないことは多いのだけど、まずはコピーが終わるまでほおっておくのが良いだろう。
関連ページ
アプリケーションサーバとしてのQNAP【日記 15/01/23】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は宮永好道さんの命日(1993)。
Dr.パソコン、として知られた人です。
Dr.パソコン、という名前は、出演していた「パソコンサンデー」での肩書。
当時はシャープの顧問で、MZ~X68k の開発に関わっていたそうです。
それで、パソコンサンデーに出演していたのですね。
僕は当時はこのおじさんが何者であるか知らなかったのですが、東芝、シャープでコンピューターを開発し、その後も各メーカーの顧問を務め、メーカーを超えてパソコンユーザーをまとめる組織などを結成。
パソコンの普及に努めた方でした。
パソコンサンデーで BASIC を教える際の独特の語り口が思い出されます。
FOR ~ NEXT 構文を、「フォー・ネクスト」ではなく「~ネキスト」と発音するんですよね。
このことは結構思い出に残っている方も多いのじゃないでしょうか。
あの番組、春からの新生活に合わせて…進級祝いにパソコンを買ってもらったとか、一念発起して買ったとか、そういう人に合わせて春になると「1から」教え直す形になっていました。
毎年春は、パソコンはプログラムがないと動かない、という基礎から始まります。
「パソコンは、ソフトが無ければただの箱」。
この言葉、宮永さんの発案した言葉だそうです。パソコンサンデーでも良く言っていた気がする。
ただ、いまと事情が違うのは、当時はソフトなんてほとんど売ってないのね。自分で作るものでした。
そして、BASIC とは何か、画面に文字を表示する方法、計算させる方法、入力させる方法、などなどを学んでいく。
どの程度のレベルまで行くかと言えば、1年かけて、フォー・ネキストを使って複利計算させるとか、ちょっとした実用プログラムが作れる程度。
まぁ、初心者向け講座としては十分でしょう。
ここくらいまで自分で作れるようになると、プログラムが楽しくなってくる。
楽しくなって、次はどんなことを学べるのかな、と思っていると、春になって最初に戻ってしまう。
友達は、テレビ界の永久ループ、と呼んでいました。
いつまでもぐるぐる回っちゃうのね。
パソコンサンデーの合間にはシャープのパソコンのCMが入るのですが、MZ-1500のCMでは、宮永さんが登場していました。
宮永さんに似たぬいぐるみのねずみが出てきて、MZ-1500にかじりついているんだっけかな。
何ですかこれは? とMZ-1500イメージキャラクターの女性に聞かれて、「いわゆるひとつの動物実験ですよ」って。
結構シュールなCMだった気がする。つまりは、MZ-1500は病みつきになって離れがたい魅力がある、ということのようなのだけど。
シリーズでいくつかCMがあって、そのうちひとつはYouTube にありました。
宮永さんから話は離れるけど、ついでなのでパソコンサンデー話。
当時は「音声多重」という放送方式が出たばかりでしたが、パソコンサンデーでは副音声でソフトを配信していました。
その回で作成したサンプルプログラムとかだったと思う。
これも、当時を知らない人にはわからない話なのだけど、昔はパソコンのプログラムは「音」として記録していました。
Windows 95 あたりでインターネット始めた人は「モデム」って言うのがあったのを知っているんじゃないかな。
電話線を通じて、音でデータを伝えるための道具。
または、FAX 。こちらも最近見かけませんが、電話に音声として書類のデータを載せて通信する。
あれと同じ原理で、プログラムを音でデータ化して、カセットテープ(これも最近見ない)に録音しておきます。
カセットテープをダビング(コピー)すれば、プログラムもコピーできちゃう。
パソコンを使ったりしないから、プロテクトのかけようもない。
もっとも、孫コピーなんて作ると、もう音が劣化して読み込めなくなるので、それほどコピーされないのだけどね。
話がそれたけど、パソコンサンデーでは、副音声でプログラムを配信していたわけです。
今のテレビが、 [d] ボタンで、番組に関連するデータをデジタル配信しているのと同じようなことを、30年前にもうやっていたわけですよ。
#どんどん話がそれるけど、当時のパソコン雑誌にはソノシート(レコード盤)が付いているものもあった。
やっぱり、音にしてプログラムデータが収められているの。
レコードはノイズが載りやすいから、ノイズを載せないで読み込ませるためのノウハウとかもあった。
家に宮永さんの書いた本があって、宮永さんが亡くなられる直前、12月10日に刊行されたものです。
「誰もかけなかったパソコンの裏事情」。
8bit 時代から、売れたマシン、売れなかったマシン、いろんなマシンを紹介した本です。
紹介機種はそれほど多くなくて、少し物足りないのだけど、紹介した記事はそれぞれ見開き2ページで、宮永さんの評価や裏話が入っている。
本屋で見かけて、古いパソコンとか好きだから買ったら、一番最後に著者プロフィールが載っていて、宮永さんの本だと知りました。
それまで「Dr.パソコン」としては知っていても、どういう人か良く知らなかった。
でも、ここに履歴もありました。へー、そんな偉い人だったんだ、とこの時初めて知った形。
この本のプロフィールが、多分宮永さんの生涯を伝える唯一の情報なのではないかな。
Wikipedia の情報も、このプロフィールを別の言葉で書き直しただけのように見えるから。
そして僕は、このプロフィールを読んだ時に、「まだ健在なんだ」と思ったのでした。
パソコンサンデー出演時に、すでに結構年のように見えたから。
でも、これ書店で見かけて買っただけ。発売すぐに買ったわけでもない。
正確な購入日は忘れましたけど、もしかしたらもうその時には亡くなられていたかもしれない。
そうとは知らずに「まだ健在なのか」と思ったのかも。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
16年 iOSでtextのコピー・ペーストができないバグの回避
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、Macintosh (128k) が発売された日(1984)
22日にスーパーボウル(アメリカンフットボールの優勝決定戦)の中継の中で Macの発売告知のCMが流され、2日後の今日、発売となりました。
初代マックはもう、いろいろと伝説がありすぎて僕が書く必要もないくらい。
ゼロックスで研究されていた Alto を元にして、「ゼロックスが商品化するつもりがないなら、アップルがやってしまうぞ」と言ってジョブズが作り上げたもの、とよく言われる。
まぁ、本当は直接作り上げたのは Lisa というマシンで(先日暇がなくて書けなかったのだけど、1983年1月19日発売)、Mac の元となった機械だ、とされている。
でも、Lisa は Mac よりもっと Alto っぽかった。
マルチタスクで動くし、マルチウィンドウだった。
でも、Lisa は高価だった。パソコン界のポルシェ、と呼ばれた。
そして、CPU である 68000 はマルチタスクに耐えられるほど高速ではなく(それでも、当時は高速なCPUの方だったのだけど)、使い勝手は決して良いものではなかった。
この反省から、Mac は Lisa を「切り詰めた」ものとして作られた。
いや、ジョブズは Lisa が受け入れられないことを認めたくなくて、「切り詰めた」のではなくて「切り捨てた」のかもしれない。
高価だった RAM を極力減らすため、OS の一部はあらかじめ ROM に納められた。
アプリケーションのプログラムも、肥大化すれば RAM を必要としてしまう。
そこで、OS の一部である ROM の中に、よく使われる処理が収められ、それらを使うことが推奨された。
もちろん、OS というのは「よく使うルーチン」の集合体だ。
その意味では、よく使う処理が入っている、というのは当たり前に思える。
でも、そうじゃなかった。
OS はまた、汎用的な処理だけを集めるべきで、高度に専門化されたルーチンを持つべきではない。
でも、Mac の ROM には「ボタンを描く」とか「テキスト入力を行わせる」とか、「テキストエディタ」のようなものまで入っていた。
結果として、Mac のプログラムは、別の会社が作ったプログラムであっても、「どこかで見た」部品が使いまわされることになった。
これが「ソフトが違っても使い勝手が統一される」という良い作用を生む。
使い勝手の統一、という、いまでは当たり前の作法は、「メモリを切り詰めた結果」、やむなく生まれたのだ。
Lisa は 1Mバイトのメモリを搭載していた。
これがどんなに驚く容量か…当時、IBM-PC は最大でも 640K のメモリしか搭載できなかった。
現実的には、Lisa と同じ 1984 年に発売された IBM-PC/XT は、256KB しかメモリを搭載していなかった。
しかし、その 1M のメモリが Lisa を高価なものとし、全然売れないマシンにした。
Mac は、この反省からメモリが切り詰められ、128K しか搭載していなかった。
しかも、拡張性は一切ない。搭載量が 128K で、最大も 128K だ。
文字中心の IBM-PC でも、256K 。それを、グラフィカルにして 128K 。
ソフトはほとんど何も動かなかったし、Mac 上でソフトを開発することなんて、とても無理だった。
#Lisa に MacWorks というソフトを載せると、Mac 互換になったので、開発には Lisa が必須だった。
もちろん、Lisa と違って Mac はマルチタスクではない。だから、ウィンドウシステムも、あまり意味がない。
1つのソフトが画面全体を占有する、というのが Mac の作法だった。
#実は、初心者にはこれがわかりやすかった。画面がごちゃごちゃしている、というのはわかりやすくない。
後に Mac はマルチタスク・マルチウィンドウになるけど、iPhone / iOS では、シングルウィンドウに戻った。
ジョブズは、Mac を「パソコン」だとは考えていなかった節がある。
どうも、ソフトウェアのプレイヤーを作ろうとしていたようなのだ。
拡張性が無い、というのもそのための選択だったのだろう。
各家庭にあるテレビが、ユーザーの好みに合わせて、蓋をあけて拡張される…というような話はない。
どこの家でも同じ仕様のパソコンを売れば、発売されるソフトもどこの家でも動くはずだ。
プレイヤーだと考えれば、非常に正しい主張だった。
キーボードは不要だ、とも主張していた。
マウスだけあれば操作はできる。文字入力が必要なら、画面上にソフトウェアキーボードを表示すればいい。
もちろん、キーボードが必要な人もいるだろうけど、それなら「別売り」にすればいい。
しかし、Mac はキーボード付きで発売された。
もしキーボード無しなら、これはパソコンではなくて、当時としては画期的な「ソフトウェアプレイヤー」として認識されたかもしれない。
Apple II の設計者であるウォズニアックも、後に「アップルはソフト再製に特化した、ファミコンみたいなものを作るべきだった。でも、任天堂に先にやられてしまった」という趣旨のことを語っている。
当時はウォズとジョブズはすれ違い、仲は悪かったはずだけど、同じような意識を持っていたのかもしれない。
Lisa は豪華すぎて高価で売れなかった。
Mac はその反動で、切り詰めすぎ、発売してすぐに「何もできない」との評判が立つ。
発表時にたくさんの予約が入っていたが、発売してからキャンセルが相次いだらしい。
当時アップル社の研究職だったアラン・ケイは、Mac を「1リットルしかタンクのないホンダ」だと呼んだ。
素晴らしい性能を持っているはずなのに、それを動かすための「燃料」を、ほとんど入れられない。
皆が、Mac をパソコンだと捉えていた。
そして、パソコンだと考えると、あまりにも非力だった。
1984年の今日、発売されたパソコンの名前は「Apple Macintosh」だった。
でも、一般に Macintosh 128k と呼ばれる。
これは、すぐ後に「Macintosh 512k」という機械が発売されたため、区別するために初代機には「128k」と付けるようになったのだ。
メモリ容量が4倍になって、やっと Mac は普通に使える「パソコン」になった。
そして、実は Mac に非常に惚れた人物の一人に、ビル・ゲイツがいる。
ゲイツとジョブズは仲が良い。
発売前から、ジョブズは Mac をゲイツに見せ、詳細資料を提供してソフトの開発を依頼していた。
まだ発売前なので、詳細資料…OS の API 資料にはとにかく何でも書かれていた。
OS 内部で使うためのルーチンなどは一般には公開しないものだけど、そういうものの情報もあったようだ。
そして、ジョブズは「この資料を自由に使ってよいし、そうして得られた情報でいかなるプログラムを作ってよい」とメモに記してサインした。
ゲイツは、Mac に表計算を提供した。初代 Excel だ。
Excel は、それまでの VisiCalc や、Lotus 1-2-3 とは明らかに次元が違う、非常に使いやすい表計算ソフトだった。
ジョブズが Alto を見て Lisa を開発し、さらに Mac を作ったように、ゲイツも Alto をみて Windows を作っていた。
でも、初期の Windows は全然売れなかった。
当時は MS-DOS で十分だったから。
後に Windows の出来が良くなってから、Mac に酷似している、と裁判になった。
同じ Alto を真似したもの同士だから、似ているとしてもある意味当然。とはいえ、Alto には存在しなかった、ファイルをアイコンとして扱える仕組みなど、Mac に影響を受けたとしか思えない部分も多々ある。
この裁判は、最終的に、先に書いたジョブズのメモ、「得られた情報でいかなるプログラムを作ってもよい」という約束が理由で、Apple の負けとなった。
この裁判の頃、ジョブズは Apple を追い出されていて不在だった。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
QNAP 話の続き。
LANDISK にはあって、QNAP にないものが1つある。
アクティブリペア機能。
これ、地味な機能だけど6年間も LANDISK が動き続けたのはこれのおかげもあるのではないかな、と思っている。
アクティブリペアは、1週間に一度、ディスクの全セクタをチェックする機能。
どうも、I/O-DATA のオリジナルソフトらしいので詳細な動作はわからないのだけど、多分全セクタを読み込んでいるだけ。
ハードディスクは磁気で記録しているのだけど、非常に小さな領域に記録しているので、磁気はだんだんと弱まる。
2005 年ごろからは垂直磁気記録、という方式が使われていて、この方式ではそれ以前の方式に比べ、磁気が弱まることがかなり少なくなったという。
とはいっても、「あるビットが」弱まってしまう確率が格段に減ったとしても「全体の中のどこかが」弱まる確率は、容量が増えたのでそれなりに残っている。
でも、磁気っていうのはいきなりなくなるのではない。徐々に弱くなる。
ハードディスクはデジタルで記録しているけど、磁気読み取りヘッドまでデジタルに動くわけではない。
読み取りはやっぱりアナログで、これを閾値で補正してデジタルにしている。
そして、「弱まってきた」ことはわかるらしい。
ある程度弱まってきている、と感じたら、ハードディスクのファームウェアが、自動的に「読み取ったデータの書き戻し」を行う。
これだけで、同じデータなのだけど磁気情報的には新しい、磁気の強いデータとなる。
読み込んだだけでもデータが失われる確率が減るわけだけど、「アクティブリペア」では、万が一データが読み取れなかった際には、RAID 1 を組んである「もう片方のディスク」からデータを読み込んで、壊れたほうのデータを修正する。
基本的に RAID 1 は、「読もうと思ったときに、壊れていたらもう片方のディスクから読み出し、壊れたほうは修復する」ことでデータを保護している。これを積極的に行うわけだ。
僕は NAS をデータ蓄積目的で使っている。めったに読まないデータもあるし、多分前の NAS を買ったときに入れてから、6年間使わなかったようなデータもあると思う。
こういうデータは、磁気が弱まって、RAID 1 でも両方のディスクでセクタが読めない、ということだって、有りかねない。
アクティブリペアはそれを防いでくれるわけで、非常に安心できる。
でも、QNAP にはそれが無い。
うーん、RAID なのだから、ただセクタ読み込んで、データ棄てるだけでいいのかもしれない。
片方が壊れていたら、もう片方のデータを読み込んで修復、というのは RAID システムの仕事だ。
QNAP は中身が LINUX で、SSH で入ることもできる。
全セクタを読むようなプログラムも組めるかもしれない。
#と思って今確認したら、cc も gcc もないね。基本的には busybox 使っているだけだ。
あまり低レベルなプログラムは作れないかも。
で、少し考えて、S.M.A.R.T. のテスト設定が出来たので、定期的に long test を行うことにした。
long test は、名目上は「全セクタの読み込みテスト」を行うことになっている。
読み込んだだけで修復されるのであれば、これでもいいだろう。
ただし、エラーがあった場合に「もう片方のディスクから正常データを読み込んで修復」はできない。
SMART はディスク個別の問題であって、RAID とは無関係だから。
もう一つ、「アンチウィルス」を使うのもいいかもしれない。
スケジュールを組んで、raid 上の全ファイルのウィルススキャン、とかできる。
普通は、無駄とおもわれるファイル…テキストファイルとか、バックアップファイルは除外、というような設定をするのだけど、「全ファイル」のスキャンで「ドキュメントや圧縮ファイルの中まで」を指定すれば、おそらくは保存しているファイルの全セクタを読み込んでくれるのではないか。
アンチウィルスも詳細動作が不明なので何とも言えないのだけど、アクティブスキャン相当の効果があるかもしれない。
週に1回とか、月に1回でいいから、スケジュールに入れておくといいかも。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は芸夢狂人さんの誕生日(1953)。
本名は鈴木孝成さん。本名よりもペンネームの方が有名です。
「げいむきょうじん」と読まれることが多いのですが、本人の意図としては「げいむきよと」なのだそうです。
8bit パソコンの黎明期に現れ、主に PC-8001 で、次々に出来の良いゲームを発表しました。
最初は秋葉原の九十九電機から発売されていましたが、後に工学社から出ていた雑誌、I/Oの投稿に転じます。
九十九は買取だったので「売っておしまい」でしたが、I/Oは印税だったので、ずっと儲かったから、というのが理由だそうです。
ペンネームを使い始めたのは投稿し始めてから。
しかし、あまりにもハイペースで投稿し、同時に2作掲載されたりする際には、別のペンネームを使います。
PC-8001 以外で発表する際にも別のペンネームを使ったそうです。
つまり、「芸夢狂人」の作成したゲームは有名なのですが、実際に作ったものはもっと多い!
初期の PC ゲームは、すべてを一人で作り上げることが珍しくありませんでした。
「芸夢狂人」さんは、そうしたスタープログラマの先駆けでした。
今でもゲーム業界で活躍する多くのプログラマが、彼のように有名になることを夢見てゲームを作っていたのです。
しかし、芸夢狂人さんは当時医大生で医者になる勉強のために、ある時突然引退宣言を出します(1981)。
その後、当時小さな会社だったエニックスが「ゲームホビープログラムコンテスト」を開催します(1982)。
広く一般に開かれたコンテストでしたが、当時パソコン雑誌にプログラム投稿をしていた人は誘いがかかりました。
I/O からは中村光一、月刊アスキーからは、すでに「森田オセロ」で有名だった森田和郎が参加していました。
森田さんが最優秀プログラム賞、中村さんが優秀プログラム賞を受賞しています。
また、当時フリーライターをしていた堀井雄二は、このコンテストの取材に訪れ、自作のゲームを投稿します。こちらも入選。
余談になりますが、2年後に森田さんが作った「森田和郎の将棋」(1984)を遊んで、作曲家でゲーム好きの すぎやまこういち さんが感想を書いたアンケートはがきを返しています。
この縁で、堀井雄二シナリオ、中村光一プログラム、すぎやまこういち 作曲で、ドラゴンクエスト(1986)が作られるわけです。
(これに加えて、当時すでに人気漫画家だった鳥山明が画像のデザインを行った。ものすごい布陣だった。)
話を戻します。
引退宣言を出していた芸夢狂人さんは1回目のコンテストには不参加。
2回目のコンテストには参加し、見事入賞しています。
後に、エニックスの人から「自主的な参加が無かったら参加要請を出していただろう」と聞いたそうです。
エニックスとしては、パソコンゲーム界の超有名人である芸夢狂人さんがコンテストに参加していないのは画龍点睛を欠く思いだったのでしょう。
その後、エニックスのいくつかのゲームのプログラムをしていますが、その頃のゲーム作成は、すでに分業制。
全てを一人でやるのが好きだった芸夢狂人さんはこれが苦痛だったそうで、再びゲーム業界から引退します。
その後、ちゃんと医者になって開業医をやっていたようなのですが、その医院も2011年に閉院。
現在の様子は氏のホームページで伺うことができます。
…ざっと書いてみましたが、ほとんど「みんながこれで燃えた! PC-8001・PC-6001」のインタビューの要約です。
他にあまり情報が無いようで、Wikipedia の情報もほとんどこれだけだし。
僕個人の思い出を書けば、PC-8001 は周囲に持っている人が居なかったので、芸夢狂人さんのゲームは1つも遊んだことないのです。
さらに言えば、I/O も購読していなかったので、直接記事を読んだこともない。
非常に残念なことではあります。
しかし、それでも芸夢狂人、という名前は知っていました。
それほど有名だったのです。
名前のインパクトがあったからよく覚えている、というのもあるかもしれませんが(笑)
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
いつも朝食の準備をしながらFM横浜を聞いてます。
ニュースや天気予報を読み上げるアナウンサーに言葉にセンシティブな方がいて、語源とか意味にも詳しい。
DJが、これが面白くてわざとおかしな言葉遣いをして訂正されたりしてます。まぁ、これはちょっとしたお遊び。
ところが、今朝は様子が違った。
アナウンサーの方が「デフォルト」という言葉を使い、DJが意味がわからず問い直した結果、アナウンサーの方は答えられませんでした。
アナウンサーの方はなんとなく使ってしまったようで、じゃぁその意味は、となると、判って無いようでした。
そこは生放送のラジオ番組のこと。すぐに、視聴者から意味を教えるメールが多数寄せられます。
…ところが、この内容が正しくない。
いや、間違っちゃいないし、その意味では正しい。
でも、語源を押さえずに「最近のつかわれ方」に根差した使い方を教えているので、DJの方は混乱するばかり。
・パソコンの初期設定のこと
・パソコンの標準装備のこと
・パソコンの標準設定のこと
…このあたりが、メールの主な内容でした。
まぁ、間違っちゃいないけど、どうも微妙に違和感がある。
DJの人は「辞書を調べたら、パソコン用語で初期設定のことと書いてあった」とも言ってました。
そうか、そんなこと書いちゃう辞書があるのか。
…って、今調べたら Wikipedia にそう書いてありました。
「辞書」=「ウィキペディア」か。まぁ、そういえなくもないでしょう。
じゃぁ、英語ではどう書いてあるのだろう、とおもったら、Wikipedia英語版には Default の解釈として正しいことが書いてあります。
日本語版はでたらめなことが多いのですが、こんなにまるっきり違うことが書いてある記事も珍しい気がします。
ただ、英語版も「本来の言葉の意味を知ったうえで」、コンピューター用語としてはどのように使われるか、という形で書かれています。
本来の言葉を知らない人が英語版を翻訳すると、日本語版みたいにまるっきりおかしな内容になるかもしれません。
さて、デフォルトはデ・フォールトです。
「デ」は、デバグのデ。離れる、下げる、否定する、などの意味を持つ接頭語です。
フォールトは「失敗」。
テニスでサーブに失敗すると、審判が「フォールト」と宣言します。あのフォールトです。
だから、デフォルト、は字句通り捉えると「失敗回避」。
ただ、実際には失敗を回避するという意味合いではなく、本当に大切なものを守るために、やりたくないけど何かを諦める、という感じです。
フォールトが単純な「失敗」ではなくて、何もかもがダメになるような失敗なのね。
それを回避するために、目先の些細なこと(でも十分大切な事)を切り捨てるような意味合いになる。
だから、デフォルトとは「棄権」などの意味になります。
辞書を引くと「債務不履行」とあるのだけど、これもそうした意味。
さて、パソコン用語として。
もともとはプログラマーが使っていた用語で、そこから派生してパソコン一般に使われる用語になりました。
コンピューターは、1から10まで、すべてを教えてやらないと動くことができません。
でも、人間にとってはこれは大変な事。
そこで、なにかを省略する、ということができるようにします。
もちろん、省略した時にどうするか、というのも誰かが教えているのだけど、少なくとも使う人にとっては「コンピューターが善きにはからってくれた」感じになる。
たとえば、条件分岐があったとします。
プログラムって、条件分岐が非常に大事。大事っていうのは、わかりにくいという意味でもあり、プログラムのバグが出やすいところ。
たとえば、4択のクイズゲームがあったとしましょう。
ユーザーに、1 2 3 4 の数字キーを押して答えてもらう。
1 を押した場合はこの処理を、2 を押した場合はこの処理を…と 4 までの処理を作り、プログラマは「これで大丈夫」と考えます。
ところが、ユーザーはプログラマの想定外のことをする。0 を入れられてしまったとします。
この時、プログラムは間違いなく誤動作します。
あらかじめ想定していなかった入力が来たのだから。
ここで、「想定外だったら、もう一度入力からやり直させる」というようなプログラムを入れておけば問題は無くなります。
これが「デフォルトのプログラム」。
全体がダメになりそうな時に、それを回避するわけです。
プログラマーの方ならわかりますね。C言語由来の switch 文を持つ言語なら、大抵 default という「どの条件にも合わない時」のプログラムを書く方法があります。
やはりプログラムで、関数に値を渡す必要があるとします。
C言語などでは、基本的にはあらかじめ決めた数の値を、必ず渡す必要があります。そうしないとエラーになります。
でも、これが案外面倒くさい。Javascript とか、 PHP とか、perl とか、「値を渡さないと適当な値が入る」ようにしてある言語が増えました。
Javascript の場合、入る値は undefined 。「何も入ってないよ」という意味を示す値です。
PHP の場合、関数設定時に値が決められます。渡されなければあらかじめ決めた値が入るし、渡されればその値になります。
つまりこれらは、引数の数が合わない、というエラーを回避するための「デフォルト値」なのです。
コンピューターを応用した機械では、さまざまな設定を行い、その設定を記憶できる、というのが普通になりました。
しかし、何も設定していない状態で「設定が無いからおかしな動作をする」のは困ります。
購入者が、何も設定していない状態でも、それなりに動作するように、あらかじめ工場で設定をしておきます。
これが「デフォルト設定」。出荷時の初期設定です。
じゃぁ、デフォルト設定から変更したものはもう「デフォルト」ではないのか、というと、そうでもないのがややこしいところ。
設定の中には、特定機能が動作する際の「デフォルト値」を定めるようなものもありますからね。
#必ずメニューを出して聞いてくるのだが、よく使う値が設定された状態で聞いてくるので、問題なければ OK を押すだけで良い、など。
WEB ページなどで、多国語に対応している場合があります。
大抵は、ユーザーが自分で言語を選べるようになっているのですが、はじめて訪れた場合でも、大抵ユーザーの母国語で表示を行ってくれます。
これも、設定していない状態なのに適切に動いてくれる、という「デフォルト設定」の一種。
実はブラウザに対して「存在するなら日本語で表示」などの設定を入れてあって、その設定も変えられるようになっているのですが、多分多くの人はこの設定があることも知らないでしょう。
なぜなら、ブラウザもまた、「デフォルト設定」として、自動的にユーザーの母国語を要求するように設定されているからです。
じゃぁ、ブラウザは何故「母語」を知っているのか。
言語ごとにインストーラーが別れている、というのも昔はありましたが、今は大抵多言語対応で全部一緒。
なので、OS に対してユーザーの母国語を問い合わせて、初期状態を決めます。
もし、OS に聞いても判断がつかない場合の「デフォルト」は英語でしょうね。多分。
たとえば、UNIX であればユーザーの環境変数に ja_JP.UTF-8 とか入っているので、日本語が母語とわかります。
さらに、大抵のユーザーはこの環境変数を自分で設定していません。
設定しない場合、システムが決めた「デフォルト」の値が入る。
たとえば、Linux ではインストーラーが大抵早い段階で言語を聞いてきます。
インストールの説明をその言語で行うためでもあるけど、システムの「デフォルト設定」を決めるためでもある。
さらに、システムデフォルトも設定していないとどうなるか。
環境変数が設定されていない場合、UNIX では「C」が母国語となります。
つまり、これが UNIX にとっての、本当の「デフォルト」の言語。
これ、C言語の意味ね。
UNIX はC言語で作られ、C言語は UNIX の上で作られた。
だからCが母国語という意味。多分ただの冗談。
…えーと、通常のソフトは英語出力になりますが、ツールの作者が一番良いと思った言語で出力していいです。
僕だったら、たとえ多国語版を作っていたとしても、日本語で表示させる。僕にとって一番正しく使えている言葉だから。
最後の方は完全に余談ですね。
意味がかえって分かりにくくなっていそうなので、もういちどざっくりまとめましょう。
1から10まで指示しないといけないコンピューターでは、うっかり指示を忘れることも良くある。
本当なら、指示がおかしいので、コンピューターの動作はおかしくなります。
でも、それじゃ使いにくいから、「多分こういうことだろう」と、普通の人が使いそうな設定をあらかじめ決めてある。
もしかしたら、あらかじめ決めておいた設定は、やりたかったこととは違うかもしれません。
決め打ちするのは危険なことなのね。でも、まったくおかしな動作をするよりはいい。
これが「デフォルト」の考え方。
最初はプログラマ同士のスラングとして、今では一般的なスラングとしても「デフォルト」という言葉をコンピューター外で使う場合があります。
特に指定されない場合は、大抵こうなるよ、という意味合いが原義。
ただ、コンピューター外、特に英語の会話では、元の意味の「デフォルト」も使われることを忘れないでね。
全体を守るために、本当は大切な事をあえて切り捨てる、という考え方は一緒。
残念ながら棄権する、とか、借金踏み倒して夜逃げする、とかそういうこと。単に「怠ける」という意味もあるけど。
どちらにしても、この意味合いに沿っていれば、言葉遣いとして間違っている、ということもないと思います。
言葉は生きているものですから、どんどん意味が転じても構わない。
元の意味をちゃんと理解していれば、その「使用場所」が広がってもおかしな意味にはならない。
ただ、今朝のFM横浜は酷かったのよ…
視聴者からのメールで生半可な知識仕入れて、「用例」をコントのように繰り広げるのだけど、「初期設定」とか「付属品」の意味で使おうとするから、意味の解らない珍妙な会話になるの。
聞いてて恥ずかしかった。
関連ページ
ラリーウォールの誕生日(1954)【日記 13/09/27】
プログラム言語における「デフォルト動作」【日記 15/01/29】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
さっき、デフォルトの話書いたのだけど、話の腰を折りそうだったので、書いてから削除した一節がある。
そもそも、過去に書いてたよなー、って思ったら、書いてなかった。
じゃぁ改めて書くか。
というわけで、自分が書きたいから書くというだけの、どうでもいい話。
perl には、「デフォルトの動作」がある。
プログラム上、特に書かなかった場合に、勝手に言語が「こうしたいのだろう」と察知して、善きに計らってくれるの。
たとえば、一部の命令では、操作の対象を明記しないと変数 $_ を対象とする。
これが、すごく便利。
というのも、perl の先祖の一つが sed だから。
sed は「ストリームエディタ」の名前の通り、入力に対していろんな処理を施して、出力する。
常に「処理中のデータ」が処理対象なので、変数と言う概念は無い。
で、perl はまともな言語なので、いくつものデータを同時に扱える。
正規表現による置換も、どのデータに対して置換を行うのか明記しなくてはならない。
でも、明記しない場合は $_ を対象とする。
これにより、まるで sed のように処理を書くことができる。
プログラムの話なので、概念だけ書くより実例を挙げよう。
perl の代表的なプログラムに、次のようなものがある。
while(<>){print;}
これは、引数として渡されたファイル名のファイルを開き、内容を行ごとに分割しながら読み込み、その読み込んだ行を標準出力に書きだすプログラムだ。
ちなみに、引数としてファイル名がわたされなかった場合には、標準入力から読み込みを行う。
というわけで、上のプログラムは Unix コマンドである cat と同じ動きをする。
何が省略されているか、もう少し省略しないで書きこんでみよう。
while($_=<>){print $_;}
なんだか <> って命令から $_ に受け取っている。
そして、print では、$_ を書きだしている。
さっき書いたけど、いくつかの命令は、省略されたときに $_ を対象とする。
<> も print も、省略に対して $_ を使っていた、というのがここまででわかってもらえると思う。
問題は <> だ。
ファイルから行単位で受け取る、と最初に説明したのだから、<> がファイルから行単位で読み込み、受け取っているのだ、ということはわかってもらえるだろうか。
foreach $N (@ARGV) { open(FILE,$N); while($_=<FILE>){ print $_; } close(FILE); }
実はこんな感じになっている。いきなりプログラムらしくなった。
@ARGV というのは、引数として渡されたファイル名のリスト。複数渡すこともできるので、foreach で1つづつ受け取る。
open はファイルアクセスのための準備。FILE にファイルハンドルが入る。
で、<FILE> とすると、ファイルから1行を読み込むわけだ。
うん、やっと全貌が見えてきた。
…でも、じつはこれでは「ファイルが無いときに標準入力から」にはならない。
<> と書いたときは、@ARGV の内容を1つづつオープンし、読み込んでくれる。
@ARGV が無いときは標準入力を使ってくれる。
さっきは、プログラムで同等機能を実現してみたけど、そういうプログラムが省略されていたわけではない。
<> が「善きに計らって」くれていただけだ。
さらに、こんなこともできる。
@_ = <>;
さっきは、while で1行づつ読み込んでいた。
でも、 @_ = <> とすると、while なしで一気にバッファに読み込んでしまう。
@_ がバッファだ。というか、perl では @ で始まるのは配列だ。
1行づつ分解して、配列の中に順次収められている。
代入相手がスカラー変数だと、1行しか読み込めないから、1行づつ処理する。
代入相手が配列変数だと、いくつも入れることができるから、まとめて処理する。
動作が変わるのだから、本来的には命令に対して「スイッチ」みたいな引数があって、そのスイッチで動作が変わる…というのが正しいだろう。
でも、perl は文脈からそれを判断する。人間が細かな設定をしないでも、言語自体が人間のやりたいことを察知してくれるのだ。
こういうのは、「文脈依存文法」といって、人工言語ではあまり美しくないことになっている。
なぜ美しくないかと言うと、文脈に依存するということは、解釈が曖昧になりやすいからだ。
でも、perl はあえて文脈に依存する。
その依存の仕方が、プログラマーが良くやる処理と見事に一致しているため、やりたいことが簡単に出来て気持ち良い、ということになる。
ちなみに、
print @_;
とすると、もちろん配列内容を一気に書きだしてくれる。
もっと言えば、print <>; でも cat になる。
while(<>){ s/banana/apple/g; s/(subuta.*)pineapple(.*)/$1$2/g; print if(!/^$/); }
構造がシンプルとはいえ、プログラムだから改造も出来る。
上のプログラムは、最初に書いた cat のプログラムに、いろいろと処理を追加したものだ。
s/●/▲/g;
というのは、●を▲に置き変える、という意味の sed の命令だ。
perl の命令じゃなくて sed の命令。でも、先に書いたように perl は sed のプログラムをそのまま埋め込めるように設計してある。
ちなみに、本当は
$_ =~ s/●/▲/g;
と書かなくてはならない、 =~ という演算子で、左辺にある変数内容を正規表現によって書き変えるの。
さて、先ほどのプログラムの場合、banana は apple に変わる。
そして、subuta の後ろにある pineapple は取り除かれる。
#ちなみに、僕は酢豚にパイナップルが入っているのは好きだ。
subuta pinebanana buta という文字列があると、「banana」部分が apple に変わり、pineapple になる。
そして pineapple は取り除かれ subuta buta となる。
最後の print の後ろに if が書いてある。
これ、実は「if の条件が満たされたときだけ print せよ」という書き方だ。
perl では、if の後ろは必ずブロックにしなくてはならない。
たった1命令をブロックに入れるのが馬鹿らしい場合、命令の後ろに if を書けばいいことになっている。
で、条件は、やっぱり sed 風の命令だ。 /~/ で、正規表現を書いてある。
ただ、さっきの命令と違って s/ で始まらないことに注意。
これ、「正規表現と一致する」ことを確認するだけで、変数内容を書き変えない。
もちろん、$_ =~ が隠れている。$_ 以外の変数に適用したいときは、ちゃんと書いてやればよい。
というわけで、プリントの条件は /^$/ でないこと。(! は否定の意味)
これは、正規表現で「行の始まり(^)の直後に行の終了($)が来る」ことを意味する。
つまり、空行だった場合は出力しない。
デフォルト動作の話ではないのだけど、perl のエラー処理の「イディオム」は面白い。
~ or die "error";
って書くのね。
これで ~ の部分で失敗したら、プログラムを強制終了する。(die はメッセージを表示して終了する命令。)
「~するか、さもなくば死ね!」って、わかりやすいと思う。
これは、C言語でも使う人いるね。
~ || error();
とか書くと、~部分が false の時だけ error() が実行される。
先に書いた print if ~ もそうだけど、英語として読み下せるようになっているセンスがなかなかだ。
さて、perl 講座ではないので、これくらいでやめにしておく。
perl のプログラムを書くときに、かなり大胆な省略が出来ることがわかってもらえればそれでいい。
少しの例示しかしなかったけど、perl ってこんなのばかり。
省略した時には、「デフォルトの」動作をやってくれる。
この「デフォルト」の決め方がすごく上手で、ちょっと処理したいな、なんて思ったときに、さくっとプログラムが書ける。
もちろん、省略して書いたプログラムは、やりたいことは十分に満たせるけど、性能が悪かったり、かゆいところに手が届いてなかったりするかもしれない。
そういうのは後で改良することになるけど、その際にはあえて細かく書くことで、デフォルト動作をどんどん減らし、自分で書き下すことになる。
究極的には、すべてを自分で設定できるので、「簡単に使えるけど、簡単な処理しかできない」というような言語でもない。
まぁ、この「省略可能」な点こそが、perl が嫌いな人にとっては許せない部分だったりもする。
省略されると、perl の動作に堪能な人しか意味がわからないのだよね。
なんでそのプログラムが動いているのか理解できない、という状態では、自分の目的に合わせて改造したい場合も改造できない。
スクリプト言語だからプログラムのソースもすぐ見られるのに、全く手を出せない、というのはもどかしい。
perl プログラマであっても、他人のプログラムは読みたくない、という人も多い。
いや、自分のプログラムですら、1か月も経ったら読めなくなるという人もいる。
perl はやりすぎかもしれない。
でも、perl 以前は、プログラムと言うのは「厳密に書くもの」で、省略が許される、なんてなかったように思う。
今の言語では、程度の大小はあれど、省略を許すことは結構ある。
先に書いた「デフォルトの言葉の意味」の記事の方に、Javascript や PHP は引数の省略を許す、と書いた。
ただそれだけでも、昔では考えられなかったような「いい加減な」書き方を許しているんだ。
こういう省略、perl がきっかけだったのではないかな、と思う。
僕は昔 perl で CGI 組んでお金頂いていたので、それなりに perl は出来るし、人が書いたプログラムでも問題なく読む。
ただ、今は perl で仕事になることはあまりないので、使ってない。
でも大好き。センスの良い言語。気持ちの上では今も perl 使いだ。
関連ページ
ラリーウォールの誕生日(1954)【日記 13/09/27】
プログラム言語における「デフォルト動作」【日記 15/01/29】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
八方ふさがりになってきたので、一旦ここまでの経緯をまとめておこう。
少し前に、使っていた NAS が壊れた。
壊れる前の話も書かないといけないね。
NAS のデータは重要なので、定期バックアップを取るようにしていた。
バックアップ終了時には、管理者(僕)にメールが届く。
ふと気づくと最近バックアップしてない。
最後のバックアップは1か月前だった。
調子が悪いのかな、と思ってリブートしたら、起動しなかった。
これが故障の経緯。
新たな NAS は購入し、バックアップデータを書き戻した。
しかし、この1か月の間に作ったデータが、古い NAS に残っている。
このデータを救出したい。
旧 NAS の機種は、I/O データの landisk HDL2-G2.0。
2008年発売で、1.0T のディスクを2基搭載している。これを raid1 設定で使用していた。
raid1 で、それまで動いていたのだから、ディスクの損傷はないと思う。
再起動できないのだから、ハードウェアに問題がある可能性もある。
しかし、まずはディスクを取り出す。
2台はミラーされた同じもの、と考え、1台は保存。迂闊に手を付けて壊れても困る。
もう1台は、Linux マシンに接続してみる。
landisk に限らず、最近の安い NAS は中身が Linux で、ソフトウェアで raid を実現している。
ディスクには6つのパーテションがあった。
1. boot パーテション
2. root パーテション
3. swap パーテション
4. 拡張 パーテション
ここら辺は、非常に一般的な Linux のパーテションの切り方だ。
ちなみに、boot も root も、この後書く5番目のパーテションも ext3 。
2008年だと考えれば、これも標準的。
4の拡張パーテションの中には、2つの論理パーテションが入っていた。
5. log などが入っている。おそらく /var にマウントするもの
6. 最大の容量を割り振られた、おそらくデータパーテション
6 をマウントして覗いても、中身は空っぽだった。
おや、おかしい。やっぱりレイドが壊れて、データは消失、再構築されてしまったのか。
…とおもったが、df で良く見ると、およそ 1T の容量のうち、半分程度が使われている。
NAS にはデータが 500M くらい入っていた。やっぱりこれがデータ領域だ。
ファイルタイプは xfs 。
今では各種ディストリビューションの標準ファイルシステムとなりつつあるが、僕はそれほど詳しくない。
知っていることとしては、大容量データを扱うためのジャーナルファイルシステムとして新たに設計されたもので、つぎはぎだらけの ext4 なんかよりも「素性が良い」という程度だ。
でも、もちろん ext4 なんかと互換性が無い。
残念ながら僕は互換性のためにまだ ext4 を使っていて、xfs は馴染みがない。
しかしまぁ、大容量も扱えるしジャーナルだし、なにより 2008 年当時には ext4 は信頼性がなかった。
xfs を使っているのは、ある意味当然だろう。
容量は使われているのでファイルは残っていると思われる。
しかし見えないのはなんでだろう。ファイルを見せないようにロックする方法とかあるんだろうか。
ここで xfs のことを調べ、実装方法にミスがあったことを知る。
古い xfs では、ジャーナルの記録が CPU のエンディアンの影響を受けていたそうだ。
「そうならないように設計していたはずなのに、実装ミスだった」とのこと。つまりはバグだ。
現在の xfs では修正されているらしい。
違うアーキテクチャの CPU でマウントする際には、元マシンで xfs_repair してから、新たなマシンでマウントすること。
xfs_repair では、ジャーナル情報を元にファイルシステムの整合性を調べ、チェックが終わったジャーナルは破棄される。
バグがあったのはジャーナル部分だけなので、これで違う CPU でも開けるらしい。
ジャーナルだけが問題なら、ファイル名とかは見えてもいいんじゃないかな、と思うけど、どうも詳細不明。
ともかく、ファイルが見えないことは事実だし、「元マシン」で xfs_repair することも叶わない。
探すと、x86 の Linux で、エンディアンが違う xfs を開くためのパッチ、とかもあるようだ。
しかし、これらは xfs のソースプログラムにパッチを当てるもので、カーネル再構築からやらなくてはならない。
家の Linux マシンは仕事に使っている物なので、自分でカーネル再構築して不安定になると困る。
この方法は見送り。
#後日追記(2015.2.2)
この節に書いてあること、かなり間違ってました。
「ジャーナル部分にバグがあったらしい」と言っている人がいたのは事実だけど、実際にはエンディアンは「当初は気にしていなかった」というのが事実のようだ。
SGI のマシンから Linux に、まずは動くように移植され、ついでエンディアンの違いを無くすように、非常に多くのパッチが当てられ続ける。
XFS Endian bug Fix と書かれた投稿を探しただけでも、2006年ごろから 2012年ごろまで、非常にたくさんあった。
なので、元マシンで xfs_repair すればよい、という情報自体が誤り。
x86 の Linux でエンディアンが違う xfs を開くためのパッチ、ということを書いてしまったが、これも誤りで、僕がバグ Fix パッチを勘違いしただけ。
xfs_repair すると、/lost+found の中に、読めなくなったファイルが復活する、と書かれている記事もあった。
ただし、ファイル名は数字の羅列になってしまう。
これ、i-node 番号をファイル名にして、アクセスできなくなったファイルを復活させるものです。
(i-node とは、UNIX 伝統のファイル保存方法で、ファイルの実態を表す構造。
UNIX では、ファイルとファイル名は別物で、ファイルはあるのにファイル名が見当たらない、という状況にシステムが気付くと、/lost+found ディレクトリに移動される。)
ただ、先に書いたバグの中には、ファイルのデータ格納に関わるものもある。
このバグが LANDISK に残っているとすれば、「大きなファイルの場合、先頭は残ったとしても、末尾までは保証されない」と思うので、あまりお勧めできない。
データパーテションには手を出せないが、システムパーテションなどは見ることができる。
/etc/samba/smb.conf が 0byte だ。
起動しない原因はこれか? と思ったけど、情報を調べると、landisk では毎回起動時に smb.conf を自動生成するようだ。
NAS にとって重要なファイルだから、うっかり破損したりしないようにそういう仕組みにしてあるらしい。
ファイル日付を見ると壊れた頃なので、何らかの原因で生成できなかったのかもしれない。
なぜ 0byte になったのかは不明。
自動生成しているらしいが、探してみてもどこで作りだしているのか不明。
うーん、とりあえず、ダメもとで設定ファイルを作ってみようか。
この時、disk full と怒られた。
え、なんで? いくら root 領域だからって、そんなにギリギリに作ってあるわけがない。
しかし、本当に容量が使い切られている。
/var/log ディレクトリでもあふれたのかな、と思っても、そのディレクトリは無い。
ログ関係は5番目の領域に入っていたし、ちゃんとローテートされていたので問題ないのだろう。
du -s * してみる。
これで、ディレクトリごとにどの程度の容量を使っているかがわかる。
/bin なんかが大きいのは当然として、/usr が不自然に大きい。
追いかけると、/usr/share/usb2 というディレクトリがあり、この下が異常に大きかった。
そして、そこにはデータ領域のコピーがあった。(もちろんほんの一部)
どうやらこれが故障の原因。
このディレクトリは、背面 usb ポートに接続したディスクがマウントされる、マウントポイントのようだ。
定期バックアップのために接続していたディスクが、なぜかアンマウントされたのだろう。
ただし、アンマウントしてあるとはいえ、デバイスとしては接続はされている。
landisk は、デバイスがあるからバックアップを取ろうとして、データ領域の内容を /var/share/usb2 に書き込む。
しかし、そこはデバイスがなく、root ディスクのディレクトリに書き込まれただけだ。
ディスクのほぼすべてを占める領域からのコピーに、当然 root 領域はパンク、disk full になった。
そして、ディスクにデータを書き込めることを前提にしてあるソフトは多い。
これらがすべてうまく動かなくなる。
その一つが、おそらく smb.conf を作り出すためのプログラムで、データを作り出せないまま 0byte にしてしまったのだろう。
再起動に失敗するわけだ。
/var/share/usb2 の中を削除し、ディスクを NAS に戻して起動してみる。
…残念ながら動かない。
もう一度 Linux に接続して中身を見る。
/.autofsck を見つけた。
このファイル、Linux 起動時にファイルシステムのチェック(fsck)を行うためのものだ。
もしかして再起動しない原因はこれか?
再起動しないのではなく、fsck に時間がかかっているだけかもしれない。
#fsck は非常に遅い。
/.autofsck は、起動後に自動的に作られる。そして、終了時に自動的に消される。
もし正常終了しないと、残されたままになり、次回起動時に fsck が動く。
つまり、なにか異常な状態で終了したので、ファイルシステムを念のためチェックした方がいいよ、ということ。
たしか、最後の再起動時に、いつまで待っても終了しなかったので電源を抜かざるを得なかった。
だから残っているのだろう。
/.autofsck を消したディスクを NAS に戻し、起動してみる。
…だめだ。やっぱり起動できない。
fstab の第6パラメータを 0 にしてみたり、/fastboot を作ってみたり。
(いずれも、fsck をさせないための設定)
しかし、やっぱりうまくいかない。fsck が問題ではないのか。
ふときづいて、NAS から取り出したディスクのパーテションを tune2fs -l してみる。
この中に、「最後にマウントされた日付」がある。
…NAS 上では、どのパーテションもマウントされていない。
PC が起動するときは、MBR (マスターブートレコード:ディスクの第1セクタのこと)からプログラムを読み込み、実行する。
複雑なのでざっくり書くと、このプログラムが第2のプログラムを読み込んで実行し、そのプログラムがさらに OS を読み込む。
Linux の場合、boot パーテションに OS のファイルが入っている。
boot パーテションだけ分けておくのは歴史的経緯もあるが、初期の「OS 読み込みプログラム」が、HDD の冒頭付近のsectorしか読めなかったためだ。
だから、boot パーテションの OS はマウントせずに読み込まれる。
そして、OS が起動すると、root パーテションをマウントする。
root パーテションには起動に必要な設定も、必要なプログラムも入っている。これで無事に起動が出来る。
起動中に、boot パーテションもマウントされ、/boot の下に接木される。
「最後にマウントされた日付」がどうなっているのかわからないのだが、起動時に自動的にルートになるのは含まないかもしれない。
しかし、少なくとも /boot に接木する段階にまでは至っていないことがわかる。
さて、どこで止まっているのか。
なにぶん、動作が全く外から見えないので調べようがない。
landisk には、前面に3つのランプがついている。
1つは電源ランプ。あとの2つは、2台のディスクの状態を示すランプ。
ディスクの状態は、いわゆる「アクセスランプ」ではなくて、異常を伝えるための物。
普段は消灯しているけど、ディスクが動かなかったりすると赤く点灯する。
電源ランプは、通常は点灯。起動時・終了時・なんらかのお知らせがあるときなどは点滅する。
landisk が外に情報を出す手段はこれしかない。
じゃぁ、これを使ってみよう。
ここまでに、起動時に動く各種スクリプトを見ているが、どこかに制御しているらしいプログラムがあった。
…見つけた。/usr/local/bin/ledcont だ。
中を見ると perl スクリプトだった。
I/O ポートを直接叩き、LED コントローラに指示を渡しているようだ。
次に inittab を読む。
UNIX では、OS が起動するとまず init というプログラムが呼び出される。
init は inittab に従って次々とプログラムを起動し、ユーザーが利用できる状況を整える。
ただ、inittab の書き方は、UNIX でも会社によって違うし、Linux でもディストリビューションで違う。
ここまでに気づいていたが、landisk は debian だ。僕が普段使っているのは redhat 系なので、少し違う。
(ちなみに、僕は slackware 系を使っていた時代もあるので、そちらならなんとか。
Netwalker は ubuntu で debian 系なのだけど、システムハックするほど使い込んでない)
ふむ、一番最初に読み込まれるスクリプトは、/etc/init.d/rcS のようだ。
このスクリプトは、 /etc/rcS.d/ 以下のスクリプトを次々起動するための物。
そこで、rcS の冒頭で ledcont を使い、表示を「起動中」以外にしてみることにした。
これで起動してみると…
LED の表示が変わらない。ということは、inittab すら読み込まれていないのか…
というわけで、現状お手上げ状態に。
最初のプログラムすら起動しない状況って、やっぱり本体が壊れている可能性もある。
ちなみに、情報によれば MBR は 0 しか書かれていない、らしい。
一般的なパソコン向けではないので、システムの ROM にブートシーケンスを入れてあるのだろう。
だから、MBR が壊れたわけではない、と思う。
OS の起動イメージが壊れている可能性はある。
実は、boot 領域には、工場出荷時の各パーテションのイメージが、tar+gz 圧縮で入っている。
この中の起動イメージと比べてみたら違っていた。
これは、アップデートがあったので当然。
最新版のアップデートは昨年暮れに出ていて、このファイルをダウンロードしてあったが、アップデートにはなぜか失敗していた。
(ダウンロードは boot 領域内に行われ、アップデートは root 領域に行われる。
先に書いたように、root が disk full だったので失敗したようだ)
このアップデートファイル内にも OS 起動イメージがあった。
昨年末のアップデートでは起動イメージは変わらなかったようで、日付が手元の物と同じ。
diff したら、全く同じ。
つまり、起動イメージに問題は無さそう。
電源ランプは、電源を入れてから
・起動中の点滅
・一瞬だけ点灯
・再び点滅
という動きをする。
点灯するところで何か動きがあるわけだけど、最初の点灯で起動イメージを読み込んで、読み込み終わったところで「起動中」の点滅を終了、その後起動イメージを動かすと、そのプログラム内で再び点滅を始めるのではないか、と思っている。
(思っているだけで根拠はない)
このあと、なぜか root ファイルシステムのマウントに失敗し、そのため init も動き出さないのだろうな。
今後の動き。
まずは、データの保全が大事。
方針は2つあって、Raise Data Recovery for XFS というシェアウェアを使うのが一つ。
これは、Windows 上で動くソフトで、壊れた XFS からでもかなり高確率でデータを復元してくれるらしい。
landisk で使っていたディスクからでも取り出せた、というのだから、先に書いたエンディアンの違い問題も対処済みなのだろう。
シェアウェアなのだけど、21.95ユーロ=3000円程度。
フリーウェアの似たソフトの場合、復旧率が悪いというので多少の出費はやむ得ないところ。
もうひとつは、新しい NAS の外付けドライブとして無理やり突っ込んでみる方法。
新しい NAS も ARM を使っているので、エンディアンの違い問題は出ない…可能性もある。
そもそも読めない可能性だってあるし、XFS の外付けが読めたとしても、「エンディアン問題対処済み」の新たなプログラムを使っていたら、やっぱり古いバグありデータは読めないかもしれない。
さらに、SATA ディスクを USB 接続するなり、eSATA 接続するなりするためのアダプタを購入する必要もある。
…多分、先のシェアウェア代金より高くつく。
というわけで、方針はだいたい決まっているようなもの。
データ保全できれば、先に書いた「工場出荷状態への復旧」のためのファイルを試してみるのもよい。
これを行うと、多分データは消えるけど、NAS が復活するかもしれない。
関連ページ
ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】
ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】
デイビッド・パターソン 誕生日(1947)【日記 15/11/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
さっき書いた通り、Windows のシェアウェア、Raise Data Recovery for XFSを試してみた。
まずは、お金を払わないでお試し。
試すだけなら無料で出来るようになっている。
このソフト、一番重要な機能は、壊れたファイルシステムの修復だ。
工夫されたアルゴリズムで、かなり高確率でファイルを救い出せるらしい。
でも、今回の場合、どうもファイルシステムは壊れていないようだ、という確信を持っている。
Windows マシンに NAS のハードディスクをつなぎ、ソフトを起動。
ディスクドライブが見えるので、データパーテションである6番目の領域を指定して、「Explore」。
ビットエンディアンが逆の CPU である、NAS の arm で作られた XFS でも問題なく読めた。
問題無くファイルが見れた。全く壊れていない。
で、取り出せるか試す。ファイルを選んで、Copy to ボタン。
「お試し版では 512K までのファイルしか取り出せないよ」と怒られるが、別にそれでいいので続行。
作業ログが表示され、取り出せなかったファイルがどんどんリストアップされる。
どうやら、512K といいつつ、768K 未満は取り出せているらしい。
でも、そこはあまり喜ぶところではない。
さぁ、半日格闘してどうしようもなかったデータが目の前にある。
3000円程度、喜んで払おうじゃないか。
Registrationを押す。すると、日本語のページに飛ぶ。
ん? 復旧天使、というソフトの宣伝ページだ。
調べると、「復旧天使」は、Raise Data Recovery の日本語版らしい。
日本の代理店が正式に日本語化し、販売しているようで、販売価格は4000円超。
いや、僕は別に英語で構わないから、と思っても、どこでユーロ建てのお金を払えばよいのかわからない。
ネットで探し、やっと海外の送金ページを見つけ出す。
Avangate という決済会社を通じて支払うようだ。
情報を入力して、カード番号も入れて、支払いを…
あれ、カードが無効だ、と言われる。
何か入力ミスしたかな、と思って何度も試すが、カードが無効だ、と怒られて購入できない。
お金を払おうと思っているのに、一体どうなっているのか。
サーバー不調だったりするのかな、と1時間ほどおいといても改善しなかった。
もしかしたら、僕のカードが VISA の「提携カード」だから、VISA を選んでも認証できなかったのかもしれない。
しかしまぁ、購入できないのは問題がある。
PayPal 払いできたので、わざわざ PayPal のアカウント作った。
PayPal にカードを登録すると、問題なく認証を通った。
そして、PayPal で支払。利用者側にはお金はかからない(販売者側に手数料が課金される)ので、僕としては結局カードで払うのと同じ。
最初の時点でカード使えていれば、ソフト作った会社は PayPal に取られる手数料の分まで手に入れられたのにね。
で、しばしまつ。
…このソフトを使った、という人の話だと、購入して数分でライセンスキーがメールで届く、ということだった。
でも、なかなか届かない。
まず、PayPal から「支払するよ」ってメールが来た。
次に、Avangate から「支払するよ」ってメールが来た。
それからずっとたって、ソフトの開発会社から「支払われたよ」ってメールが来て、ライセンスキーが書かれていた。
10分くらいかかったかな。
これで、問題なくデータがとりだせた。
1か月分のデータだけなので、ほんの少しだけだった。
この作業自体は非常に簡単なのに、ライセンスキー入手に無駄に長い時間がかかったことになる。
ところで、「カード払いシステム復旧しないかなー」と待っていた1時間、ただ待っていただけではない。
その間に、KNOPPIX を試していた。
DVD から直接起動して使える、インストール不要の Linux ディストリビューションだ。
#気に入ったらインストールもできる
Landisk ではなく、Buffalo の LinkStation の壊れた XFS を、これでデータ取り出したという人がいる。
うーん、最近の Linux では XFS のバグが直っている、というようにも聞くし、もしかしたら、バグ有の XFS ディスクでも読み込めるような工夫があるのかもしれない。
#僕が普段使っているディストリビューションは、仕事先との互換性を考えて少し古い。
XFS のドライバがバグ有なのかもしれない、と疑ったわけだ。
ダウンロードして試してみる。
ダウンロードに 10分ほど。DVD 焼くのに 10分ほど。
その間に、子供とおやつ食べてた。
で、結論から言うとこれはダメ。
バグが直っている、というのは、エンディアンの影響が無いように改善されたというだけで、古いバグ有ディスクも読めます、ということではないのだろう。
つまり、バグあり XFS を読むには、Windows の Raise Data Recovery for XFSを使うしかない。
…なに、この UNIX のバグの後始末を、 Windows でやらなくてはならない、という状況。
個人的には、Windows はお金を払えばいろんなことが解決できる場所で、Linux は技術と時間があれば解決できる場所だと思っている。
でも、XFS のバグを修復できる技術は僕にはない。
そして、Linux コミュニティーの誰にも、この問題をどうにかしようという人間はいないのだろう。
でも、問題を認識している人はいて、お金を払ってもらいやすい Windows 用のソフトを作った。
ただそれだけのことなのだけど、なにかもやもやとしたものが残る。
「壊れた XFS の修復」とかなら高度な技術が必要だから、金をとれる Windows で、となるのも仕方ないんだ。
実際、Raise Data Recovery はそういうソフトなんだし。
でも、今回の例で言えば、ファイルシステムは壊れていなくて、ただ古い既知のバグがあるドライバで作成されただけなんだ。
この問題を Linux コミュニティがほったらかしにしている、というのがどうも Linux コミュニティの弱点に思える。
Linux があれば Windows なんていらない、と言っている Linux エバンジェリストとか、Linux ハッカーとかは、もう少しこの問題を考えないといけないと思うよ。
#この件に限らず、Linux ってそういうところばかりなのだけど。
#Linux コミュニティの中でも、現実的に Windows は必要、と考えている人は、別にそれでいいです。
実際、Windows に Raise Data Recovery があるんだから、Linux 上で同じようなソフトを作るという「車輪の再発明」はする必要ないでしょう。
次の目標:
これで、データパーテションが消えても問題なくなったので、工場出荷状態に戻して再起動できるか試したい。
でも、仕事もしなくてはならないので、いつになるかは不明。
関連ページ
ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】
ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】
デイビッド・パターソン 誕生日(1947)【日記 15/11/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【しんいち】 初めまして。 (2017-12-06 16:40:06) |
今日は、ビル・メンズチの誕生日(1945)。
モトローラで 6800 の設計に携わり、モステクノロジーで 6502 の基本設計を行い、ウェスタンデザインセンターで 65816 を設計した人です。
独特な、癖の強い設計で、ファンも多い CPU を作り続けた人。
「思想的な後継」としては現在でも ARM がありますが、設計者などは全然別ね。
実のところ、僕は 6800 をあまり知りません。
通り一遍の知識はあるけど、プログラムまではしたことが無い、という意味ね。
6800 は、PDP-11 を元に設計された、と言われている 8bit CPU です。
当時としては、PDP-11 は最高の CPU 設計。
でも、小さなマイクロチップにこれを押し込めるには、まだ時代が速すぎた。
A B 二つの 8bit アキュムレータ、X PC SP の3本あるアドレスレジスタ。そしてフラグ用に 8bit 。
これがレジスタのすべてです。
PC はプログラムカウンタなので、16bit は当然。
SP はスタックポインタ、X はインデックスでした。これらも 16bit あるので、メモリのどこでも参照できます。
設計はチームで行われ、CPU だけでなく周辺チップなども開発されています。
メンズチは、主に周辺チップの担当でした。
6800 は後に改良され、互換性のない 6809 として発売されます。
どちらかというと売れたのは 6809 の方で、6800 はそれほど売れていないはず。
6809 の方は、メンズチは関わっていません。
別の会社に移籍してしまったためです。
6502 は、この 6800 を思い切って簡素化し、値段をずっと安くした CPU です。
モトローラではなく、モステクノロジーで作成された物。
アキュムレータは A だけになりました。
PC は 16bit ですが、SP とインデックスレジスタは 8bit に縮小されました。
16bit のアドレス空間を、8bit でアクセスするのではアドレスの完全な指定ができません。
そこで、スタックは、アドレスの上位が 1 のアドレス空間に固定になりました。
256バイトしかスタックが無いことになりますが、工夫すれば乗り切れます。
インデックスレジスタを使用する際も、命令と共に上位8ビットは指定することになります。
このため、メモリ空間は 256byte ごとに区切られることになりました。
6502 では、この 256byte 単位を「ページ」と呼びます。
改めて書くと、スタックは1ページ目に固定されていることになります。
6800 を「貧弱にしただけ」では出来ることも限られてしまいます。
6502 は、大胆な方法で拡張された機能もあります。
まず、インデックスレジスタは X Y の2つになりました。
配列をコピーする際など、インデックスが2つ必要になる場合は多いです。
必要とされる機能を、ちゃんと用意したのです。
ただし、X Y の持つ機能は、微妙に異なります。
これも、利用される状況を考え、微妙に異なる機能を持たせた方が便利だからそうなっているのです。
アキュムレータは1本だけに減らされています。
アキュムレータとは「計算に使うレジスタ」なので、普通に考えると、必ず2本必要です。
6502 では、ここに設計の最大の特徴があります。
先ほど書いた「ページ」と組み合わせ、0ページ目の 256byte のメモリは、アキュムレータと組み合わせて計算しやすい命令が揃っているのです。
つまり、一見するとアキュムレータは1本ですが、実は +256 本ある、というような設計になっているのです。
6800 よりも設計が簡素化され、安くなっているにもかかわらず、機能は 6800 を上回る部分もある。
後に作られ、大人気となる Z80 と比べたって遜色ないのです。
ただし、癖が強いので使いこなすのには腕が必要です。
ウォズニアックはこの CPU を気に入り、Apple I に採用しました。
その後 Apple II でも採用され、爆発的なヒットとなったのは多くの人が知る通り。
さらに、ファミコンでも 6502 の一部機能を省略したものが使用されています。
設計はたった3人で行われ、メンズチは演算回路など、中心となる部分を作っています。
65816 は、Apple II の後継機を 16bit にしたかったアップル社の要望で設計された CPU です。
単純に 16bit CPU が欲しいのではなく、過去の 8bit 資産を完全に活かせることが重要要件でした。
モステクノロジーではなく、メンズチが設立した、ウェスタン・デザイン・センターで作成されています。
65xx シリーズで、8bit と 16bit の2つのモードを持つ。
それが 65816 の名前の由来です。
6502 では 8bit だった、アキュムレータ、スタックポインタ、インデックス X Y が、16bit に拡張されています。
やった! これで全メモリ空間を指定できる!
…のではなく、メモリ空間も 24bit に拡張されています。やっぱり 8bit 足りない。
そして、やっぱり「256byte をレジスタ代わりに使える」方式は残されています。
ただし、この 256byte はアドレス先頭に固定ではなく、新設されたレジスタで指定されたメモリから始まります。
サブルーチン内でローカル変数が欲しいときは、このアドレスを移動して、終了後に元に戻せば大丈夫。
同時に使えるメモリは相変わらず 256byte ですが、ひと手間かければ無限に増えるようになったのです。
設計は、メンズチ1人で行っています。
妹さんが雑用を手伝ったりはしたらしいけど。
そして、65816 の最大の特徴は、8bit と 16bit がモード切替だということです。
このモードは、基本的にレジスタ・メモリアクセス幅を変えるだけだと思ってください。
「16bit の拡張命令が増えた」のではなく、モードを切り替えて同じ命令を使います。
でも、そのことを除けば、基本的に機能は同じ。
これは、「16bit モードで 8bit のアクセスをする方法が無い」という意味にもなります。
読み込むときは、16bit で読み込んで、上位データを and 0 して消してしまえばよいだけ。
8bit を書き込むときは結構面倒なことになります。
でも、8bit / 16bit モードの切り替えは遅かったので、工夫した方が高速に動く。
高速にしたい場合、8bit アクセスを無くす、というのが一番良い方法でしたけど、遅くてもいいからメモリ節約したい場合もあった。
こう書くと使いにくいダメ CPU のようですが、メンズチは 6502 の時から一貫して「小さな回路規模で最大の効果」を念頭に設計しています。
命令は 8bit/16bit で共通で、データ幅だけを完全に切り替える、という設計は、この観点で見ると非常に素晴らしい割り切り方です。
256byte のゼロページアドレッシングを残しつつも、0ページの位置を変えられる、というのも、簡素ながら良く練り込まれた設計。
そもそも 6502 の設計が面倒くさくて使いにくい、という人には、65816 もダメでしょう。
その一方で、6502 の簡素な美しさが好きだという人は、65816 もきっと好きになれます。
そういう、癖の強い設計の CPU です。
先に書いたように、65816 は、16bit の Apple II を作るために設計されました。
実際に Apple II GS という名前で発売されています。
GS は Graphics and Sound の略。
Apple II 独特の、貧弱な画面とサウンドを大幅強化して、CPU も 16bit にして、OS も GUI にしたマシン。
もう Apple II じゃないじゃん、と言われそうだけど、ちゃんと互換性もある。
ちなみに、Mac 発売以降に作られていて、OS も Mac 風。
Apple II 部署と Mac 部署は仲悪かったはずだから、会社の方針で使い勝手の統一を図ったとかではなくて、「対抗心で作った」のではないかな、と思ってます。
もっとも、仲が悪かったのは Jobs のせいで、Woz は怒ってすでに会社辞めているし、Jobs も混乱の原因を取らされてクビにになった後に Apple II GS が作られているのだけど。
そして、実は ADB の採用第1号マシンです。
ADB … Apple Desktop Bus は、マウスやキーボードをコンピューターに接続するための規格。
これ以前は、周辺機器ごとに違う接続方法があり、直接コンピューターに接続するのが普通でした。
ADB では、今後機器を増やしても大丈夫な設計指針があり、デイジーチェーン(直列つなぎ)で機器を増やせたので、柔軟な周辺機器設計が可能になりました。
IBM 系の PC で、この ADB を真似しようとして後に作られたのが USB ね。
こちらも iMac が大々的に採用したことで普及したのだけど。
65816 は、6502 上位互換なのでスーパーファミコンにも搭載されています。
スーパーファミコンは、ファミコンとの互換性はありませんでしたが、開発時にはギリギリまで「上位互換」として作られていました。
その名残で、スーパーファミコンは起動するとまず 8bit モードで動作し、メモリなどもすべてファミコンとほぼ互換性を持った状態で見えるようになっています。
その後 16bit へ切り替える命令が実行されると、スーパーファミコンの全機能が利用できるようになるのです。
スーパーファミコンは画面モードとしても「ファミコン互換モード」を持っていたし、なぜ互換機路線をやめたのかは不明。
多分、将来の拡張性も考えた際に、カートリッジ形状を変えたかったのではないかとも思いますし、些細な部分で完全互換が難しくなったのかもしれません。
当初は「上位互換」として発表されたため、後に上位互換が無理だとわかっても「アダプタで対応」となりました。
ただ、この「アダプタ」は、スーパーファミコンとは独立した機械。ジョイパッドや電源アダプタなどを共有できる、というだけ。
つまり、新設計されたファミコンでした。
結局「アダプタ」という誤解を招く名称もなくなり、後に AV ファミコンとして発売になっています。
同じテーマの日記(最近の一覧)
関連ページ
【訃報】6502 の開発責任者、チャック・ぺドル【日記 19/12/28】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はフィル・ジマーマンの誕生日(1954)。
僕はこのサイトで、時々「ハッカーズ」という書籍を引き合いに出します。
その書籍を書いた「スティーブン・レビー」というルポライターが書いた別の本が「暗号化」。
この「暗号化」の中で、特に重要な人物として描かれているのが、フィル・ジマーマンです。
彼は PGP …Pretty Good Privacy を開発した人物です。
彼が小学校4年生の時、テレビで子供向けの冒険番組を放映していました。
今でもよくあることですが、そのテレビ番組の中では、スポンサーの商品が効果的に使われていました。
番組中、時々「暗号文」が表示されることがあり、その内容は「暗号解読器」を購入した子供だけが知ることが出来たのです。
ジマーマンはこの暗号解読器を持っていませんでした。
しかし、画面に表示される数字をメモし、その規則性を解き明かして、ついには自分で暗号を解読できるようになったのです。
ジマーマンはこれ以降暗号に強い興味を持ち、子供向けに書かれた「暗号の本」と出合います。
その本に載っている暗号は単純なものでしたが、暗号を基礎から解説し、いくつもの暗号化のパターンを教え、その応用で無限に暗号が作り出せることを示していました。
ジマーマンは、暗号を作れると同時に、暗号を解読する基本的な手法も身に付けました。
中学の時には、「オリジナルの暗号を作った」という友人の挑戦を受け、頻度解析…換字式暗号の基本的な解読方法を駆使して、見事に解読しています。
換字式暗号とは、文字を別の文字に交換する暗号です。
たとえば、アルファベット表に従って1文字前にずらすと、IBM が HAL になる、等と言うのが有名です。
アルファベット表では簡単に見破られるかもしれないので、この「表」自体を複雑化する場合もあります。
アルファベットではない、不思議な記号にするものもあります。
ジマーマンが中学時代に挑戦を受けた友人の暗号は、すべての文字を、独自に作成した記号に置き変えたものでした。
しかし、元の文章が「英語」であれば、文字 e の出現頻度が一番高く、続いて t a o 等が多いことが知られています。
また、文字の接続にも、t の次には h が来やすい、などの規則性があります。
ジマーマンが使った頻度解析とは、こうした「英語の規則性に注目する」方法でした。
ジマーマンは、挑戦を受ける際に、「簡単ではつまらないから、長い文章にしろよ」と、友達を逆に挑発しています。
挑発に乗った友達は、思いっきり難しくしようと、長い文章を暗号化しました。
しかし実は、長い文章ほど頻度解析がしやすく、解読のための手掛かりが多いのです。
暗号の性質を良く知っているジマーマンの作戦勝ちでした。
ジマーマンの「暗号」への興味は、いわゆる中二病をこじらせたもの。
この頃を頂点として、中学卒業の頃には興味を失います。
彼は大学に進学し、コンピューターを学びます。
ここで FORTRAN と出会い、「乱数発生器を組み合わせた換字式暗号」を独力で開発します。
換字式暗号は、変換表に基づいて文字を変換します。
このため、e は必ず同じ記号、t は必ず同じ記号…と変換されてしまうため、頻度解析で解読できます。
ジマーマンは、コンピューターの乱数を使えば、1文字ごとにこの「変換表」を交換できるため、頻度解析ができなくなると考えたのです。
ちなみに、コンピューターの乱数は「擬似乱数」にすぎません。
人間からするとでたらめな数に見えるのですが、コンピューターは純然たる計算によって数字を作り出しています。
そのため、同じ条件を指定すれば、何度でも同じ乱数を作り出します。
乱数を使って暗号を作った場合でも、同じ乱数を使って元に戻すことができるのです。
これなら、暗号として使えます。
彼は、「これは最強の暗号で、誰にも解読できない」と考えました。
しかし、すぐ後に大学の授業でこの暗号の解き方を教わることになります。
自分が考案したと思っていた暗号は、遥か昔にすでに考案されており、それを解読する方法ももう考案されていたのです。
教授はこの暗号を「非常に基本的で解読しやすい暗号」として、受講者全員が解読してくるように、宿題を出したのでした。
その後、大学卒業の直前の1977年に、ジマーマンは RSA 暗号の論文発表を知ります。
ジマーマンの知る暗号とは、鍵を使って解読するものでした。
鍵を秘密にしながら、通信したい相手にだけ鍵を教える必要がありました。
これを「秘密鍵暗号」と言いました。
秘密にしないといけないのに、共有しないといけない。
これが暗号の最大のジレンマでした。
しかし、RSA は全く新世代の暗号でした。
鍵を公開してしまっても暗号として成立するのですから。
通信者は、お互いに「秘密鍵」と「公開鍵」のペアを持ちます。
秘密鍵は自分だけが知り、絶対に他人に教えてはならないものです。
その一方、公開鍵は誰が知っても構いません。
そして、この鍵のペアの一方で暗号化したものは、他方で解読できます。
AさんがBさんに通信したいとしましょう。
通信文をAさんは自分の秘密鍵と、Bさんの公開鍵で暗号化して、Bさんに送ります。
Bさんは、Aさんの公開鍵と、自分の秘密鍵で解読します。
もし、第3者に暗号を見られても問題はありません。
なぜなら、第3者はAさんの公開鍵は知っていても、Bさんの秘密鍵は知らないからです。
ジマーマンはこの暗号にショックを受け、すぐに論文の執筆者に連絡を取ります。
この暗号はコンピューターで処理できるのか?
RSA 暗号は非常に複雑なもので、コンピューターで処理できなければ、誰にも使うことはできません。
MIT では、すでにプログラムを作成中でした。
ただし、それは非常に高価なマシン向けで、誰もが使えるようなものではありませんでした。
ジマーマンは、当時発売されたばかりの Z80 マシンで RSA を実装しようと頑張ります。
しかし、RSA 暗号はあまりにも高度な数学であり、その数式の意味すら解りませんでした。
しかし、「誰もが気軽に使えるように、この暗号をパソコンソフト化する」というのは、ジマーマンの強い思いとなりました。
当時はベトナム戦争の後。ヒッピーブームの頃です。
政府は信用ならない。政府は人々の生活を監視し、人々を裏切る。
皆がそう考える時代の空気の中で、「政府に監視されないように、誰もが暗号を使える社会を」作ることが、ジマーマンにはとても大切なことに思えたのです。
Z80 は RSA を実装するにはあまりにも非力でした。
ジマーマンは、暗号によって政府から人々を守る、という目標が難しいと悟ると、反政府活動家へと変わりました。
反政府デモを行ったり、核凍結運動を行ったり。
その過程で、2度投獄もされています。
もう、立派な政治活動家でした。
ここに、チャーリー・メリットと言う別の人が登場します。
彼はジマーマンと同じように考え、Z80 に RSA を実装することに成功しました。
そして、この暗号化ソフトを販売し始めます。
アメリカ国内にはあまり需要は無く、主に海外で売れ始めました。
そして…政府の弾圧を受けました。
アメリカの諜報局である、NSA がたびたび彼の元を訪れ、すぐにソフトの販売を中止しなくては痛い目にあうぞ、と脅し続けたのです。
ただ、この際の脅しは「海外販売を辞めろ」というものでした。
当時の NSA としては、海外での諜報活動が中心でしたから、海外で解読不能な暗号が広まることを恐れたのです。
チャーリーメリットは、海外での販売が難しくなったため、なんとか国内で使ってくれる企業は無いか、片っ端から電話をしてセールスをかけ始めます。
そして、ジマーマンが設立した会社に連絡を取り、ジマーマンと知り合うのです。
メリットの思惑とは異なり、ジマーマンの会社で暗号製品の採用はありませんでした。
しかし、二人は密接に連絡を取り合うようになり、メリットはジマーマンに RSA 暗号を実装するのに必要な数学を叩き込みます。
ジマーマンは、RSA 暗号が複雑すぎて遅いことを理解し、この遅さを克服するアイディアを持っていました。
暗号化には従来型の秘密鍵暗号を使い、RSA 暗号は、この「秘密鍵」の交換のみに使用するのです。
秘密鍵暗号の弱点は、秘密鍵の管理にありました。
通信するたびに秘密鍵をランダムに生成し、通信の後は破棄してしまえば、管理の手間はいらなくなります。
そして、秘密鍵が通信する2者以外にばれないように、この交換にのみ、速度の遅い RSA 暗号を使うのです。
そして、二人で RSA 暗号を商売にしようとしていた RSA 社… RSA 暗号の考案者たちが作った会社にまで乗り込み、会食をしています。
この会食で、ジマーマンは「RSA 暗号の特許を無償で使う」ことに承諾してもらった、と考えています。
RSA 社は特許を商売にするために設立した会社なので、無償提供などあり得ない話なのですが、彼はこの「快諾」を受けて、本格的に暗号プログラムの作成に取り掛かります。
ジマーマンは、寝る間も惜しんで暗号ソフトを作ります。
時代は Z80 から 8086 にうつり、ターゲットは IBM-PC でした。
Pretty Good Privacy と言う名前も開発中に考えていました。
これは、RSA 社の関連企業である、Public Key Partners (PKP 社)をもじったものでもあります。
#本当はもっといろいろな意味が込められていますが
この間は仕事もせず、家のローンを払う金も失いかけ、半年たってやっと完成しました。
最初はこのソフトを販売しようとしていたジマーマンは、「誰もが安心できる社会を作り出す」という使命感にかられ、シェアウェア販売にしようと考え直します。
多くの人が無料で使えるが、価値を見出してくれた人だけがお金を払う。
それこそが使命です。だからこそ、RSA 社も特許の無償使用を快諾してくれたのです。
そう思って、いよいよ完成して公開できる段階に来た、と RSA 社に連絡を取ります。
実際に完成したソフトに、特許使用の正式承諾を貰うためです。
しかし、返事は「特許の無償使用の許諾など、ありえない」という当然の物でした。
ジマーマンが思っていたのとは違います。
RSA は大企業であり、政府と同じだ。
…信用には値しない。彼の直観がそう判断させました。
この問題は、無視することにし、ソフトの完成を急ぎます。
そんな時、新たな法律が可決されました。
1991年の初頭のことです。冷戦は終わり、世界はテロとの戦い、という新たな戦争に突入していました。
その中で、通信情報の暗号化禁止が盛り込まれた法律が可決したのです。
テロを防ぐために、政府が十分な情報を得られること。それが大義名分でした。
ジマーマンはこのことを知り、慌てます。
この法律が施行されてしまえば、暗号化を行うプログラムは世に出ることができなくなり、抹殺されるでしょう。
その前に、一人でも多くの人の手元にプログラムを届け、人々が自由に「暗号通信」を出来るようにしなくてはなりません。
ジマーマンは、急いで PGP を「使える形」に仕上げ、バージョン1として配布します。
完成を急いだため、それほど使い勝手の良いソフトではありませんでした。
しかし、一人でも多くの手に届くように、シェアウェアではなく、フリーウェアとして公開します。
これは、数年間の彼の努力を無料で公開する、というだけでなく、もう一つの意味がありました。
配布も自由なのです。
2次配布、3次配布…ジマーマンの許可を取る必要などないから、とにかく一人でも多くの手元へ!
インターネットでは、この「意味」を追記して配布するものが現れました。
とにかく、法律の「暗号化禁止」条文を無意味なものにすること。
今更政府が取り締まっても手遅れだ、というところまで PGP が普及してしまえば、法律はあっても全く無意味なものとなります。
事前に法律の意味に気付かず、可決されてしまった以上は、それが最善手でした。
さもなければ、みんなは生活をのぞかれることになるのです。
政府の横暴から身を守るために、できるだけ配布に協力お願いします。
この言葉は非常に効果が大きく、どんどん転載が行われました。
そして…ジマーマンの予想をはるかに超え、海外にまで流出しました。
国内での暗号化は、先に書いた法律が施行されるまでは合法です。
しかし、すでに海外への暗号製品の輸出は、武器輸出と見做され違法でした。
ジマーマンは、このことで犯罪者になってしまいます。
さらに、RSA 社からも追訴されました。
こちらは「PGP の配布を辞める」という条件で和解しましたが、ジマーマンは「配布はしないが作り続ける」という態度を取ります。
そして、配布は数名の協力者に任せることにしたのです。
実は、PGP の登場と、それを迎えたインターネットの盛り上がりに恐れをなし、法律の提出者は「暗号を禁止する」条文を、こっそりと削除していました。
この条文は、法律の提出者の本意ではありませんでした。
FBI から「このような条項を入れてくれ」と頼まれ、あまり深く考えずに追加しただけの条文だったのです。
アメリカ国内での PGP の配布は「暗号」の面から見て特に違法ではなくなりました。
しかし、ジマーマンはすでに…海外に「武器」を輸出した疑いで犯罪者です。
彼は家を捨て、協力者の家を転々としながらプログラムを作り続けます。
そうしないと、政府と RSA 社の両方の追手から逃げられないためです。
PGP 1.0 は慌てて公開したバージョンなので、いろいろと問題もありました。
そして、逃避行の中で PGP 2.0 を完成。誰が、どこから配布したかわからないようにするため、協力者数名が、音響カプラとノートパソコンを持って公衆電話からサーバーにアップロードします。
今度は、「海外用」として、ソースコードを印刷した書籍も出版しました。
暗号を扱う「ソフトウウェア」は武器として輸出が禁止されていましたが、ソースコードを印刷した書籍を武器と見做す解釈はさすがに出来ないためです。
結局、1993 年にジマーマンは FBI の捜査対象となり、裁判所に召喚されます。
ジマーマンは反政府活動家として、堂々と戦い…1996 年に、ついに政府は訴えを取り下げます。
1999 年には「暗号は武器である」という規制も弱まり、PGP の輸出は基本的に合法となります。
この話には後日談もあるのですが…
気になる人は、「暗号化」を読んでみてね。
さて、戦いは終わった…のでしょうか?
2013 年、NSA が Google や Yahoo 、Microsoft などの「WEBメールサービス」の内容をほとんど盗聴していることが発覚し、問題となりました。
PGP は、通信文を暗号化するツールです。
メールで使用するには、暗号化してからメールにコピー&ペーストし、相手は暗号文をコピー&ペーストで解読しなくてはなりません。
しかし、これは面倒なので、多くのメールソフトが PGP の自動暗号化に対応しました。
PGP で暗号化、というオプションさえ選んでおけば、勝手に暗号化・解読してくれます。
ところが、WEB メールにはこうした機能が無いのです。
ほぼすべてのメールが、暗号化されずに流通していました。
「暗号化してはならない」という法律は無くなりましたが、ほぼすべての人が、WEB メールの便利さの前で、喜んで暗号化の権利を放棄したのです。
その後、Google は GMail を https 通信で利用できるように変更しました。
NSA の盗聴に対する「自衛策」の一環です。
この闘いはジマーマンがいち早く開始し、彼の名前が有名となっています。
しかし、まだまだ戦い続けている無名プログラマたちが多数いるのです。
同じテーマの日記(最近の一覧)
関連ページ
ジャングルウォーズ2 発売日(1993)【日記 19/03/19】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
「おばあちゃんとぼくと」という名作ソフトがある。
ソフト…あえて言うならゲームなのだろうけど、いまでいう「デジタル絵本」の最初期のものの一つだ。
Mac 用に発売されたもので、後に Windows にも移植されている。
初めて見たのは、1992年。
箱根で、デジタル美術の展示イベントがあった。
箱根中がイベント会場だったらしいのだけど、大学のサークル合宿(という名目の旅行)で行った、箱根彫刻の森美術館では、Mac を複数台並べて「アートな」ソフトや、活動を紹介していた。
その中に、「おばあちゃんとぼくと」があった。
衝撃を受けた。
これはゲームではない。特に目的は無く、絵本のお話をパソコンに読んでもらうだけだからだ。
でも、パソコンが絵本を読み上げた後、そのページの絵をゆっくり楽しむのは構わない。
それは実物の絵本だってそうだ。絵本と言うのは絵を楽しむものだ。
そして、「おばあちゃんとぼくと」には、パソコンならではの仕掛けがあった。
絵に描かれたものをクリックすると、いろいろなことが起きる。
これは絵本なのだから、それによってストーリーが変わったりすることは無い。
何のことは無い、ただの「遊び」。でも、ゲームなんていずれもただの遊びだ。
そして、遊びである以上、楽しいか楽しくないかが非常に重要な一線となる。
「おばあちゃんとぼくと」は、めっぽう楽しかった。
実は、「おばあちゃんとぼくと」以前に、Mac では似たようなゲームが出ている。
「the Manhole」(マンホール)というゲームで、もっとゲームらしいゲームだった。
でも、面白かったかというと…僕には面白いと思えなかった。
基本的には絵本だ。
ただ、クリックしたものによっては、その先の場所に移動する。
ハイパーリンクで構成された世界の中をさまよい、世界観に浸ることが主目的で、特にゴールは無い。
このゲーム、当時のゲーム賞を総なめにしていたはず。
今でも好きだという人は多い。
でも、ゲームとしては「アドベンチャーゲーム」に属するもので、道に迷ったりする。
気付かないと先に進めないような経路もあり、ひたすらクリックして進める場所を探す必要がある。
それでいて、クリックに反応する箇所はそれほど多くは無かった。
このことで、ゲームが「作業している」感を感じるものになってしまったのが、僕が楽しくないと思った理由だ。
「おばあちゃんとぼくと」は、ゲームではなくて絵本なので、道に迷うことは無い。
たった12ページしかない。
でも、少ないページ数だからこそ、クリックに反応する箇所が非常に多く、濃密な体験ができる。
そして、このクリックしたときの動きが、非常にセンスが良い。
後に、Mac が Performa シリーズ…多数のソフトを最初から付属させた廉価機種ラインナップを出した際に、「おばあちゃんとぼくと」が付属したものがあった。
僕はこの機種を選んで買い、ソフトを入手した。
Mac が欲しかったのもあるが、このソフトが付いていることは決め手の一つだったように思う。
当時は、兄の子供が3歳くらいだったので、ずいぶんとこのソフトで遊ばせてあげた。
子供と言うのは集中すると飽きずに遊んでいる。
僕も気に入ってそれなりに遊んだのだけど、大人の発想ではクリックしないポイントが相当ある、とこの時に気付いた。
さらに数年たち、兄に2人目の子供が生まれ、5歳くらいになった時に久しぶりにソフトで遊ばせたような覚えがある。
この時にも、見たことのない動作を発見した。
いや、もしかしたら見たけど忘れていただけかもしれない。
でも、覚えきれないほど動作があるので、遊ぶたびに発見があるのだ。
そういうソフトはなかなかない。
僕の長男が5歳くらいの頃、このゲームで遊ばせてあげたい、と思った。
しかしその時は Windows を使っていて、Mac はあるのだけど、子供がいるからこそ物置から引きずり出すことができなかった。
#小さな子がいると、ややこしい機械を出すのははばかられるもんです。
Windows 用の Mac エミュレータの存在もこの時に知ったのだけど、うまく動作しなかった。
さて、2年ほど前に、長男が近所の科学館で「キッドピクス」を見て面白がっていた。
家にあるから今度遊ばせてあげる、と約束したのだが、この時もまだ次女が3歳で、物置からガラクタを引きずり出すのは難しかった。
もう一度エミュレータに挑戦した。
動作はするのだけど、CD-ROM ドライブにアクセスできない。
この時も断念した。
先日、急に思い出して3度目の挑戦をした。
エミュレータも、数年の間にずいぶん進化した。
68K Mac のエミュレータ、Basilisk II というやつなのだけど、現在は JIT コンパイラを搭載し、68K のコードを x86 ネイティブに変換しながら動作する。
CD-ROM ドライブが読めない件は、どうやら 32bit Windows 用のドライバしかないことが問題だったようだ。
無いものは仕方がない。iso ファイルをマウントすれば読めるよ、と説明があるのを見つけたので、CD-ROM から iso ファイルに変換した。
今のマシンだと、CD-ROM を丸ごとファイル化しても、ハードディスクに対して誤差範囲みたいなものだ。
昔のマシンでは、なんか記憶領域がもったいなくってできなかった。
かくして「おばあちゃんとぼくと」が蘇った。懐かしい。
キッドピクスもインストールした。
えーと、他に Mac 用のゲーム持ってたかな…Puzzle Bobble 2 があった。遊べることを確認。
まぁ、わざわざエミュレータで遊ぶほど好きだったわけでもないのだけど、動くことが楽しい。
iTachoco のゲーム、結構沢山持っていたので遊びたいのだけど、これはフロッピーディスクなので読む方法が無い。残念。
かくして、いま5歳の次女に「おばあちゃんとぼくと」を遊ばせてみている。
すっごく気に入ったようで、集中して遊んでいる。
Windows の画面に、狭い Mac エミュレータのウィンドウを開き、その中央に小さく表示された画面で。
#「おばあちゃんとぼくと」は、カラーであればコンパクトマックでも動くように、小さな画面で設計されていた。
色数も 256 色。ドットも荒く見える。
今こんなソフト発売しても売れないだろうね。
でも、実際に子供はすごく面白がっている。
色数とかドットの細かさとか、面白さとは無関係だということがよくわかる。
キッドピクスも遊ばせるつもりだったけど、「おばあちゃんとぼくと」を気に入って何度も最初からやり直しているので、まだキッドピクスには進んでいない。
2019.10.28 追記
今でも入手できないか、というお問い合わせをいただいたので…
1年ほど前に、Internet Archive に動作する状態で収蔵されているため、現在 WebBrowser で遊べます。
Internet Archive は、もともとは「すぐに消えてしまいやすい」WEB ページをアーカイブする目的で設立された、アメリカの非営利団体です。
当初のサービスは Wayback Machine と言い、1996 年以降の WEB ページを積極的に収集、公開しています。
当ページでも、リンク切れなどの際にたびたびこちらにリンクをつなぎなおしています。
その後、活動範囲を広げ、コンピューター関連のありとあらゆるものをアーカイブしようとしています。
古いコンピューター雑誌とか、古いゲームとか。
こちらも、資料としてよく使います。
注意書きを一つ。
アメリカと日本では著作権に対する考え方が違っていまして、アメリカではこれは合法活動です。
しかし日本では、Internet Archive のような活動は、違法行為となる可能性があります。
…「可能性」と書いたのは、日本では、いろいろと曖昧なままでして…
まず、他者の著作物を勝手に公開することが、日本国内では違法行為です。
国内であれば、Internet Archive 自体がアウト。
とはいえ、先に書いたように、アメリカの活動で、アメリカに著者がいる著作物を公開しているので、今回の話に関しては違法ではない。(適法ではなく、「違法ではない」グレーゾーンです)
そして、閲覧者側。これもまた、グレーゾーンです。
一応、閲覧するだけの場合でも、著作権法第119条 3項では、「違法と知りつつダウンロード」した際に違法になるように条文が作られています。
ここで、ダウンロードを「録音または録画」と位置付けています。
あらかじめ録音・録画されたデータであっても、インターネットを通して、改めて手元に「残す」時点で、録音・録画行為となります。
このため、「残さない」場合や、せいぜい「一時ファイル・キャッシュが残る」程度の場合は、違法性がないと判断されます。
ただ、昨年起きた「漫画村」事件のように、現在は「WEB 上で見せてしまう」違法行為が増えたため、政府はこれに対応する法律を準備しようとしました。
WEB 上で見るだけでも違法、という位置づけにしようとしたのですね。
しかし、あまりにも影響範囲が大きすぎるということで、反対意見が相次いで表明され、法制化を断念しています。
上に書いたような「ゲーム」の場合、これらが録音・録画の範疇に入るのか、などの問題もあります。
(一応、ゲームは映画の著作物の一種として扱う、という過去の判断があるため、録画として判断することも可能です)
同じテーマの日記(最近の一覧)
関連ページ
2D-APT II 発表 (1959)【日記 19/02/25】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
別年同日の日記
16年 クリストファー・レイサム・ショールズの誕生日(1819)
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 日記に書いた通り、「おばあちゃんと僕と」自体はCD-ROMをisoフォーマットに変換したものを使用、エミュレータとしてはBasiliskIIです。エミュレータ上でのソフト使用はWin/Mac両方の周辺知識を高いレベルで要求されます。 冷たいようですが、ご自分で解決できないようであれば、あきらめたほうが良いかと思います。 (2017-03-02 11:21:57) 【あこ】 こんにちは。初めまして!検索からこのブログを見に来させていただきました!!「おばあちゃんとぼくと」、名作でしたよね!! 私もプレイしたいのですが、解凍がうまくいかず……。 宜しければ、どのソフトを使用したか……教えて頂ければ幸いです。 (2017-03-01 15:59:43) |
今日は ENIAC の公開日(1946)。
ENIAC は、戦時中の軍事機密として作成が開始されました。
そのため、完成してから公開までに時間がかかっており、公開は入念なリハーサルが行われたうえで、行われました。
ENIAC が完成したのは1945年の秋でした。
完成の報を受け、陸軍では「ENIAC の能力を見るために」当時の科学者たちを悩ませていた問題を用意します。
当時、原爆よりも強力な「水素爆弾」が考案されていたのですが、その内部状態の計算が出来ていなかったのです。
科学者たちの考えた方式で思ったような成果が出せるのかどうか、これが ENIAC に与えられた最初の計算でした。
この、非常に複雑な数式が ENIAC にプログラムされます。
プログラムが完成し、科学者・陸軍関係者が ENIAC の視察に訪れたのが1945年の12月。
結果は「考案した方式では、想定した結果にならない」でした。
これにより、水素爆弾の設計は見直されます。
ENIAC が無ければ、そのまま計画が進み、水爆の完成は遅れていたでしょう。
この頃、同時に ENIAC の完成・公開式典が計画されていました。
水爆の内部状態シミュレーションは…結果がよければ式典に使用されたのでしょうが、使わないことになりました。
公開式典では弾道計算シミュレーションの実演が行われることになり、新たなプログラムが作成されます。
しかし、このプログラムがうまく動作せず、プログラマたちは頭を悩ませます。
ENIAC のプログラマは、6人の女性でした。
6人の女性は、非常に数学の成績が優秀で、戦時中に弾道計算を行うために集められていました。
最初は、微分解析機などを使って弾道計算をすることが仕事でした。
そして、彼女たちは、ENIAC のプログラムを作ることを命じられます。
しかし、ENIAC の動作を示す資料は一切なく、あるのは複雑な回路図と、エンジニアと自由に話せる機会だけでした。
この頃、まだ ENIAC は完成しておらず、実機で試すこともできません。
そんな状態から ENIAC の動作を理解し、与えられた数式をプログラムする方法を考えなくてはならなかったのです。
ENIAC は、多数の計算回路の集合体です。
個々の回路は、掛け算だけ、足し算だけ、引き算だけ…などを行うように作られています。
プログラムは、この回路間を「結線」することで行われます。
結線により計算手順を示し、場合によっては複数の結果のうち、条件に適合したものだけを次の計算に使ったりするのです。
数式を与えられたとき、その数式を表現するために、どのような結線を行えばよいか。
これは、非常に難しい問題でした。
「結線を変えられれば自由な計算を行えるはずだ」という設計は間違えていないのですが、それがどんなに複雑なことになるかまでは考慮されていなかったのです。
彼女たちは EANIC のプログラム方法を自分たちで見つけ出し、複雑な数式もプログラムできるようになっていました。
完成後最初の計算である、水爆の内部状態遷移も彼女たちがプログラムしたものです。
しかし、それよりも簡単なはずの「弾道計算」はうまく動きませんでした。
公開式典はすでに日付が決められており、それまでにプログラムを完成させなくてはなりません。
恐らくは、世界初のデスマーチ・プロジェクトです。
彼女たちはこの問題にかかりきりで、何日も昼も夜も、何が悪いのか考え続けました。
式典の数日前、プログラマの一人である、エリザベス・ホリバートンは真夜中に目を覚まします。
何が悪いか、夢の中でひらめいたのです。
条件によって ON にならなくてはならないスイッチが、特定条件下では OFF のままでした。
これが計算を台無しにしていたのです。
#この話、デスマーチ経験のあるプログラマなら思い当たるはず。
頭を悩ませていると、夢の中にまでその問題が現れるものです。
そして、夢の中では「あたりまえ」だと思っていたことが邪魔せず、解決方法がひらめくことがあります。
そして、完成式典は 1946年の今日、2月14日に行われました。
世紀の大発明を公開する式典は非常に豪華なもので、晩餐会つきでした。
晩餐会のメニューは、ロブスターのビスキュイ(クリームスープ)、フィレミニヨンステーキ、サーモンステーキなどを含む5品だったそうです。
基調演説は、科学アカデミー会長で、原爆開発のマンハッタン計画にも一役買った、フランク・ジュウェットでした。
この完成式典は「完成」を伝えるためだけのものでした。
しかし、その衝撃は世界中に伝わり、ソ連からも「一台売ってくれ」と注文が来たそうです。
#この注文は断られました。
アメリカに敵対する国に軍事上優位な装置は渡せない…というわけでもなく、「ENIAC は量産品ではなく、1台しかない」ことが主な理由です。
ENIAC の開発資金を提供した陸軍に納入されたのは、その数か月後。
余りにも巨大なので壁に穴を空け、まとまった回路ごとに分割して運び出され、陸軍に納入されました。
ENIAC の本格的な稼働はその後。
最初の計算は、設計し直された水爆の内部状態計算でした。
ところで、この完成式典を挟んだ数か月…水爆の最初の設計が正しくない、と示した時から、陸軍に納入されるまでの期間が後に争点となります。
ENIAC の特許が申請されたのは、1947年の6月26日。
アメリカでは特許申請は「公に使用されてから1年以内」と決められていました。
申請は、公の使用とは陸軍への納入である、と考えて、期限に間に合うように行われています。
しかし、後に ENIAC の特許を無効にしようと別のコンピューター会社が起こした訴訟では、「公の使用は、最初の水爆計算の 1945年12月である」と判断されました。
つまり、ENIAC の特許は申請期限を半年も過ぎており、無効。
この裁判の中で、ABC マシンが「ENIAC に先行して作成されたコンピューターである」という主張が行われています。
(先行する類似発明があると、特許は無効となります)
ABC マシンは ENIAC とは明らかに違ううえ、完成していません。
そのため、裁判ではこの件は判断されておらず、ABC が世界最初のコンピューターだとは判断されていません。
しかし、ENIAC の特許が認められなかった = ABC が最初と認められた、と主張する書籍が後に作られ、ABC が世界初である、と誤解が広まっています。
最後に、バレンタインデーらしい話を…
ENIAC のプログラマ6名が、マニュアルもない状態でプログラムを作らなくてはならなかった、という話を途中で書きました。
彼女たちは、参考に、エンジニアと自由に話をする機会を与えられました。
恐らくは、仕事のために何度も何度も、エンジニアに質問をしたことでしょう。
そのうちに仲良くなるエンジニアがいるのは当然のことです。
全員がエンジニアと交際していました。
そして、結局3組のカップルが結婚しています。
同じテーマの日記(最近の一覧)
関連ページ
2D-APT II 発表 (1959)【日記 19/02/25】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
別年同日の日記
16年 クリストファー・レイサム・ショールズの誕生日(1819)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、クリストファー・レイサム・ショールズの命日(1890)。
PCをお使いの方は手元をご覧ください。
その、QWERTY配列キーボードを考案した人です。
実は3日前のバレンタインデーが彼の誕生日(1819)だったのですが、ENIACの公開日、という大ネタもあったので命日の紹介となりました。
彼は新聞編集者で、多数の新聞の編集長を務めています。
同時に、郵便局長・税関・土木事業局理事などの公職も歴任。
恐らくは、とても事務仕事が多かったでしょうし、とても多忙だったでしょう。
そんな中で、ペンを使って手で書くよりも早い筆記具を研究し始めます。
当初はピアノの鍵盤のような形状だったようです。
それが改良されて現在のQWERTYになっていく過程に関しては、Wikipediaを読んだ方が、僕が書くよりずっとわかりやすそうです。
1882 年には現在とほぼ同じ配列のタイプライターが完成します。
この発明はレミントン社に持ち込まれ、商品化されます。
このレミントン社、吸収合併の歴史の繰り返しもあり、簡単には説明できません。
これもWikipediaを見てもらったほうが良さそう。
レミントン社は後にレミントン・ランドとなり、ENIAC を作成したエッカートとモークリーを迎え入れ、UNIVAC I を作り出します。
世界初の商用コンピューターでした。
もちろん、このコンピューターはQWERTY配列のキーボードで操作することが可能でした。
さて、一足飛びにコンピューターの話に入る前に、タイプライターの進化をざっと書いておきましょう。
話はモールス信号の実用化まで遡ります。
当初は、通信士が通信文をモールスに変換して送信し、受信側の通信士が元の通信文に戻していました。
しかし、これでは訓練された人員が両側に必要です。
訓練なしに文字を送れるように、「文字」を直接送れるようにした「テレプリンタ」がすぐに開発されます。
ピアノ状のキーボードを使い、押したキーに対応した文字が相手側で印刷される、という仕組みでした。
タイプライターは、当初はこのキーボード配列を流用し、後には独自に使いやすいキーボードを考案して作成されたものです。
タイプライターの発明時点では、キーを押すことで直接活字が動き、紙に印字する機構になっていました。
紙に活字を叩きつける必要があるので、結構力がいります。
人差し指で押すキーと小指で押すキーでは、力が違うのでインクの濃淡があり読みづらい、等の問題もありました。
少しして、キーボードは単に「スイッチの集まり」になり、電気の力で活字を打ち付ける方式が登場します。
電動タイプライタです。
こうなると、キーボートと印刷機が目の前にある、というだけで、テレプリンターシステムと何ら変わりのないものになります。
実際、遠隔地と結ばれた電動タイプは「テレタイプ」と呼ばれ、すぐにテレプリンタを置き変え始めます。
電動タイプには、入力したキーを紙テープに記録できる機種が作られ始めます。
この紙テープを「再生」すると、先の入力と同じように印字ができます。
タイプライターでは、間にカーボン紙を挟んだ複数枚の紙を使って、同じ文章内容の「複写」を作ることができました。
とはいえ、複写するときには特に強くキーを押す必要がありましたし、せいぜい2~3枚を同時に作成するのがやっとでした。
#カーボン紙で作られるコピーを「カーボンコピー」、略して CC と呼びます。
電子メールで同時に複数人数に送る際の CC: 欄はこの意味です。
念のため書いておくと、当時はコピー機の開発以前です。
紙テープによる再生は、カーボン紙を使わずに、同じ文面のコピーを可能にしました。
これなら、何枚でも同じ文面の書類を作ることができます。
紙テープの利点はそれだけにとどまりません。
タイプライターで1ページの書類を入力していると、当然「入力ミス」も発生します。
そんな場合はホワイトで消して修正するか、そのページを最初から入力し直すしかありません。
しかし、紙テープなら「間違えたところをハサミで切り取り、糊で繋ぎ合わせる」という編集が可能なのです。
紙テープが多少ツギハギになったところで、大切な「書類」にはその跡は残りません。
これは、書類作成事務を大きく変える大発明でした。
コンピューターが登場するのは、この紙テープタイプの普及後です。
「現代的な意味で」最初のコンピューターである EDSAC では、すでにタイプライターが活用されています。
…と言っても、電動タイプライタの印字部分を出力に使用できた、というだけです。
キーボード部分は一切接続されておらず、入力機器としては使用できません。
EDSAC では電話のダイヤルが取り付けられていて、0~9の数字が入力できました。
電動タイプライタの印字部分だけとか、電話のダイヤル部分だけとか、寄せ集め感満載です。
EDSACは大学が研究のために作ったもので、それほど潤沢な予算があったわけではありません。
だから、使えそうな民生品を流用して作った、という、それだけの理由でしょう。
ところで、先にリンクした Wikipedia のQWERTY配列のページでは、EDSAC にテレタイプが接続されていて、QWERTY配列だったことが書かれています。
テレタイプがプリンタとして接続されていたのは、上に書かれている通り本当です。
しかし、キーボードは使用されていないので、QWERTYであることは無関係です。
#Wikipedia の記述は資料に基づいたものなので、資料に誤りがあるのかと思います。
#僕が勘違いしていました。記事の最後(15行くらい後)に訂正の追記を行います。
UNIVAC I がQWERTYで操作できた、というのは先に書いた通りです。
もっとも、こちらも基本的には EDSAC と同じで、紙テープの作成用と印字用、というのが中心的な使われ方。
それでも、キーボード部分が入力インターフェイスとして使えるように、UNIVAC I に接続されていたようです。
UNIVAC I は商用の、事務などにも使用されたコンピューターなので、文字の扱いも重視されていたようです。
(これ以前のコンピューターは主に科学計算用でした)
UNIVAC I 以前のすべてのコンピューターを調べたわけではありませんが、おそらくは UNIVAC I 以前にはQWERTYキーボードで操作できたコンピューターは無いのではないかと思います。
クリストファー・レイサム・ショールズがQWERTY配列を考え、レミントン社が権利を買い取り、普及させた。
そして、レミントン・ランド社になって、自社製のキーボードをコンピューターにも接続した。
どうやら、現在QWERTYキーボードがコンピューターに接続されているのは、こういう理由のようです。
2015.2.25 追記
上記、「資料に誤りがあるかと」と書いたところ、資料の著者の方から意図の説明がありました。
僕がちゃんと読み解けていなかった部分もありましたので、お詫びの上訂正し、解説します。
Wikipedia を改めて確認したところ、「インターフェイスとして用いた」という記述のみで、接続されているとは書いていませんでした。
これを読んで「EDSAC では接続はされていなかったはずだけどな」と思ってしまったのが僕の勘違いです。
EDSAC では、キーボードは接続されてはいなかったが、インターフェイスとして利用はされていた、というのが事実です。
実のところ、EDSAC に「接続された」タイプライタと同種のタイプライタが、別の用途で利用されていたこと自体は知っていました。
当初はその話も書いていたのですが、それは「EDSACの話」であり、この日記のテーマである「QWERTY」から外れすぎると考えて削除していました。
以下に詳細を書きます。
(EDSAC の話に偏ってしまいますが、不正確な記事の訂正のためですのでご了承ください)
EDSAC の命令コードは、1文字で表されます。
現代的に言えば、アセンブラのニーモニックです。
ニーモニックですから、コンピューターが理解できるバイナリコードに変換(アセンブル)しなくてはなりません。
しかし、EDSAC ではこのバイナリコードとして、テレタイプで文字をタイプした際に紙テープに記録されるコードをそのまま採用していました。
また、テレタイプで数値を入力すると、それはそのまま2進数表現となる文字コードになっていました。
1桁のみの2進数なので、BCD表記となりますが、BCDから2進表現への変換は、イニシャルオーダー(紙テープを読み込むためのプログラム)で解消されました。
つまり、アセンブリ言語で書かれたプログラムをタイプライターで紙テープにパンチすると、EDSAC で実行可能なプログラムとなったのです。
「インターフェイス」という言葉をどのような意味に捉えるかにもよりますが、これはQWERTYキーボードをインターフェイスとして利用してはいます。
ただし、紙テープの穿孔機としての利用であり、コンピューターに働きかけることはできません。
現代で考えるようなキーボード利用の方法とは、かなり性質の異なるものです。
いずれにせよ、Wikipedia の記述がおかしい、というのは僕の早合点でしたので、お詫びしたうえで訂正します。
2018.6.18
上の追記の指摘をくださった先生が、キーボードの成立過程を解説したページを作っていました。
面白いのでリンクしておきます。
同じテーマの日記(最近の一覧)
関連ページ
クリストファー・レイサム・ショールズの誕生日(1819)【日記 16/02/14】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 補足ありがとうございます。ご本人からの解説で痛み入ります。元文献を読まずに違うのではないかと書いたことは軽率でした。お詫びいたします。 一応紙テープのことは知っていたのですが、本文が長くなりすぎることを避けて書いていませんでした。 ただ、結果的に誤りを書いてしまったことになるので、本文修正いたします。 (2015-02-25 09:14:54) 【安岡孝一】 『The Preparation of Programs for an Electronic Digital Computer』(Addison-Sesley 1951)を読む限りでは、EDSACにはCreed Model 47を改造したキーボードが繋がっていたようです。ただし、電気的にではなく、もちろん紙テープを介してですけどね。 (2015-02-23 21:09:53) |
子供に Scratch を遊ばせている。
長男(10歳)は素晴らしい吸収力で、弾幕シューティングみたいな動きを作って「動きが美しい」と喜んでいた。
画面中央から自分を正確に狙った弾が飛んでくるので、ひたすら避けるだけのゲームだけど。
こういうものを簡単に作れてしまう、というのは Scratch の柔軟性の高さだと思う。
プログラムを勉強する、というと、とりあえずリファレンスマニュアルを読み始めようとする人がいる。
英語だったら、ある程度英単語を知らないと作文はできない。
リファレンスを読むのは「どんな単語があるか」を知ることになるので、まぁ、間違っているとは言わない。
でも、まずは何か目標を立てたほうがいい。
英語の学習でもそうだけど、明確な目標が無いと上達しにくい。
で、目標を立てるというと、思い描くソフトの「完成系」を夢想してしまい、そこにむかって邁進しようとする人が多いようだ。
目標が細かすぎると頓挫する。
最初に細かな「仕様」を決めると、どうしてもそのものを作りたくなって、持っている技術で「回避しよう」とか考えられなくなっちゃうから。
目標は、一言で言い表せる程度にしておくのが良い。緩い目標設定だ。
「ゼビウスみたいなシューティングを作る」とか、「綺麗な模様を描けるソフトを作る」とか、その程度。
そして、自分の知識で出来そうなことから作ってみるのがいい。
その途中で新たな知識を得たら「これで何か面白いことできないかな」って考えて機能を追加してみる。
自分の出来ることばかりやってたら上達しないよ、っていう意見ももっともだけど、プログラムってそんな単純なもんじゃない。
「これならできるだろう」と思って始めたことでも、思わぬところでつまづいて、苦労するもんだ。
それで十分勉強になるし、上達できる。
先に書いた弾幕シューティングは、非常に簡単な仕組みだ。
Scratch 2.0 には「クローン」という機能がある。
プログラムは1つしかないのに、複数の物を動かせる便利機能だ。
ちなみに、1つのプログラムで複数の物を動かす、という概念は混乱しがちなので、Scratch 1.x 系列にはこの機能は用意されていなかった。
でも、この機能無いとゲームが非常に作りにくい。
ものすごく重要な機能で、使い方を理解してしまえば非常に便利だ。
で、長男は画面の中央に適当なキャラクターを置き、常に「自機」の方を向くようにプログラムを組んだ。
Scratch では、キャラクターに「向き」がある。キャラクターの移動を「前へ」「後ろへ」「右へ」「左へ」などで指示するためだ。
そして、他のキャラクターの方に向ける、という命令があるので、「自機」に向かせるのはたった1命令で出来る。
で、一定時間ごとに「クローン」を作るようにした。
クローンは元のキャラクターと同じ位置に生み出されるが、特に指示しない限り生み出されるだけで、プログラムは動かない。
そこで「クローンされたとき」に動き始めるプログラムを組んだ。
このプログラムは、ひたすら「前へ」を繰り返すだけ。生み出されたときの方向に、ずっと動き続ける。
以上。これでおしまい。
自機はマウスで動かせるようになっているのだけど、その自機をめがけて多数の弾が飛び続ける。
まるで弾幕シューティングのような画面になる。
ちなみに、長男は弾幕シューティングなんて全く知らない。
「この命令、何かに使えないかな」と適当に組み合わせている間に面白い動きになり「みてみて、面白い」と見せに来ただけだ。
この無目的さがいい。
プログラムの「お勉強」だと、なかなかこういうことができないけど、何かに使えないかな、って考えて使ってみた機能は、確実に自分の知識となる。
独習書を買ってきて、本で原理を学んで、サンプルプログラムを真似して作ってみても、その知識は案外活用しづらい。
思えば、僕も BASIC のリファレンスマニュアルを読んでは「へー、こんな機能あるんだ」って実験しながらプログラムを覚えていったと思う。
BASIC は、プログラムを組まないでもその場で「命令の実行」が可能だった。
いわゆるダイレクトモード。命令を入力すれば、すぐに結果が返る。
これがあるから、リファレンスを見ても命令の動作詳細がわからないとか、そもそも手元にリファレンスが無いけど命令自体は記憶しているとか、そんなときに命令の動作を簡単に調べられた。
簡単な組み合わせで、狙っている目的が実行できることを確認してからプログラムに組み込んだりね。
実は、いまも Javascript や PHP のプログラムを作るときに、同じようなことをすることがある。
Scratch では、リファレンスすらいらない。
だって、使える命令は全部画面上に「ブロック」として置かれているのだもの。
それ以外の命令は使えない。
この、「命令が見えるものだけに限られている」ことに拒否反応を示す人がいる。
大抵はプログラマーだ。
本物のプログラムは、もっと多くの命令を自由に駆使することで無限の可能性が広がっているものだ、という。
この意見はわからないではない。
僕も、Scratch で仕事のプログラムを作れ、と言われたら断乎として拒否する。
出来ることが非常に限られているから、苦労することが目に見えているんだ。
でも、それは「本物のプログラマは Pascal を使わない」というのと同じことだ。
今までの自分のやり方と違うからと言って拒否しているだけ。
僕はアセンブラで低レベルなプログラムを書いて、ハードウェアの隅々までしゃぶりつくすのが好きだ。
それを仕事にしていたこともある。
でも、Scratch の非常に簡単にプログラムが書けるのも大好きだ。
多くのプログラム言語を見てきて、それぞれに違う得意分野があることを知っている。
そして、そのどれもが、本物のプログラム環境だと思う。
Scratch では、先に書いたように全命令が非常に少なくて、画面上に置かれているのでリファレンスがいらない。
BASIC と同じように、ちょっと書いて(組み合わせて)動かすことも簡単だ。
だから、リファレンスが無くても動作詳細はすぐにわかる。
そして、非常に少ない命令は、よく考えられている。
ゲームを作る、キャラクターが動き回る紙芝居を作る、タートルグラフィックで遊ぶ…など、いくつかの「子どもが興味を持ちそうな」分野において、目的を1命令、もしくは数命令の組み合わせで実現できるように練り込まれている。
でも、もし Scratch でいわゆるお勉強…基本のソートアルゴリズムとか、文字列検索のプログラムとか、モンテカルロ法で円周率を求めるプログラムを作ろうとしたら、非常に苦労するかもしれない。
Scratch は得意分野が狭い。
その代わりに、その得意分野では非常に簡単にプログラムが組めるし、その範囲内では命令の組み合わせもしやすいように工夫されている。
でも、それでいいと思う。万能の言語なんて存在しない。
汎用性が高い、と言われるC言語すら、プログラムの需要が高まった現代では、不得手な分野が非常に多いと言われる。
子供向けの学習用言語である Scratch がCよりできないことが多いからって、「そんなのダメだ」と言い出す理由は、全くない。
何か興味のあることを見つけて、その興味に従って自由に遊んでみる、ということが勉強には必要だと思う。
実は、これはプログラムに限らず、すべての勉強に言えること。
疑問を持ったら、それが知識の範疇であるならば図書館に行って調べてみる。
物理なり、幾何学なりで計算してみれば導ける問題なら計算してみる。
台所に行って実験できるものなら実験してみる。
空き箱で工作して解決出来そうなら工作してみる。
方法は問わないけど、「プログラム」もそれらと大きく変わるものでもない。
ただ、プログラムは「正解」かどうかがわかりやすい、というのが違う。
言い方を変えると、他の方法では、自分のやったことを直接的にしか知りえない。
調べたことをノートにまとめたとして、そこには自分の書いた字が残るだけ。
計算して数値を出しても、その数値が正しいかどうかはわからない。
プログラムは、自分が書くのは「プログラム」なのだけど、動かして出てくる「結果」は違うものだ。
結果が間接的に返ってくる。
ここで、エラーになったり誤動作したり、目的通りに動かないのであれば、明らかに違っているとわかる。
プログラムは他の学習方法と大きく変わるものではないけど、ただ一つ、目線を強制的に変えてくれる作用があるのだ。
そして、目線を変えることこそが、考えるときには重要だと思う。
先に書いたプログラム以外の「興味で遊ぶ」方法、自分一人で正しいかどうか判断する方法が一つあって、それは全く違う目線で確認することだ。
でも、違う目線を持つのは非常に難しい。大人になってもできない人が多いし、子供にはまず無理。
それが簡単にできる、というのがプログラムを学ぶメリットの一つだと思う。
遊びから得られるのは、知識ではなく「考える力」だ。
知識は教えることもできる。でも、考える力は教えることはできない。
「良く学び、良く遊べ」と言われるものこのためだと思う。
遊ぶというのが「元気に遊べ」ということではなくて、学んだ知識を使った遊びを考案せよ、ということね。
遊びを考案するってのは、応用できるようになるってことだからね。
これは知識を頭に入れただけでなく、己の血肉としなくてはできないこと。
そして、逆説的だけど血肉にするためには遊んでみないといけない。
長男が Scratch を楽しそうにやっているからこの日記を書き始めたのだけど、時間が来たので妹たちに交代した。
長女(7歳)はまだ自分でプログラムはできない。
でも、先日スクラッチで表示できるキャラクターの中から「魚がかわいいからこれで何か作って」というので、僕が簡単な金魚すくいゲームを作ってみせた。
「もっと魚の数増やせない?」とか、「すくい網が破けにくいようにできない?」とか言ってくるので、ヒントだけ与えて自分でやってごらん、と対応している。
まだプログラムは組めないが、どこのパラメータをどう変更すれば何が起こるのか、いろいろ試してみて喜んでいる。
「最高点を記録しておきたい」というのはなかなか難題だが、長男がヒントを出しながら一緒にプログラムを組んでいた。
我が家の実感では、7歳はまだプログラムを自由に作るのは難しいな、という感じ。
10歳なら十分だ。
実際のところ、10歳は自分でものを考えられるようになる年齢だとされている。
子供にプログラムをやらせてみたい、という人はその年齢を一つの目安にするといいだろう。
#上に書いた通り、7歳でもパラメータを改造して遊ぶくらいはできる。
次女は5歳だが、5歳はゲームのルールを理解できる年齢。
これ以前は、ジャンケン程度の簡単なものでも難しい場合がある。
#ジャンケン程度なら3歳くらいから遊べる子もいます。
ちなみに、次女のお気に入りはキッドピクス。
長男・次女のプログラムは横から見て楽しんでいるし、実は書き変えるパラメーターの位置なども、長女より早く「ココじゃない」と指摘することがある。
でも、まだプログラムにはあまり興味がないようだ。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
QNAP をしばらく前に導入したわけだけど、なんだかうまく共有できないことがあった。
おかしいなぁ、と思いながら、僕は使えていたので気にしていなかった。
でも、妻のマシンから QNAP にアクセスできない。
僕のマシンでも、ごくまれにうまく接続できないことがある。不安定。
時間がなくてなかなか追及できなかったのだけど、やっと原因がわかった。
多分レアケースで、同じようなミスをする人がそれほどいるとは思えない。
でも、そんなこともあるんだ、って例として書き記しておこう。
まず、最初に環境について。
仕事のために Linux サーバーを立ててある。
この Linux サーバーには samba が入っている。
samba っていうのは、windows のファイル共有を Linux でも使うようにするソフト。
実は、QNAP の中もこれで動いている。
一時は、ネットワーク上に2つの samba サーバーを共存させるのに何か相性問題とかあるのか、と疑ったのだけど、最終的にこれは関係なかった。
Linux サーバーは、家庭内 DNS サーバーとしての役割もある。
DNS は基本的に各マシンを登録してあるのだけど、登録していない名前でアクセスが発生した時は、Linux サーバーの IP アドレスを返すようにしてある。
仕事で WEB アプリを作ることが多く、Apache に仮想サーバー設定することが多いためだ。
適当な名前でアクセスした際、Apache がサーバー名で動作を変える。
この時、いちいち DNS 設定の変更なしに新たな仮想サーバーを作れると便利だ。
以前、I/Oデータの Landisk シリーズを NAS として使っていた。
これ、確か初期設定でサーバー名が landisk-1 となっていた。
じゃぁ、って DNS にも landisk-1 で登録した。
QNAP を導入した際、置き換えだったので同じ IP アドレスを割り振った。
同じ IP アドレスにしたのは、もし IP アドレスが変わったことで問題が出るような環境があると嫌だったから。
もっとも、QNAP と Landisk は共有ディスク名などが違ったので、IP アドレス一緒でも同じファイルパスでアクセスできなかったのだけど。
で、QNAP がホスト名を決めろ、と言ってきた時に、ここは「NAS」とした。
landisk じゃないのに landisk-1 と呼ぶのもどうかと思ったし、今後 NAS を買い替えることがあっても、NAS という名前ならそのまま使えるだろうと思ったから。
で、動かしたら動き始めた。問題ない。
Windows からネットワークを見ると、NAS というサーバーが見えている。
ところが、僕の環境ではアクセスできたのに、なぜか妻の PC からアクセスできない。
NAS を開くと、どういうわけか、Linux サーバーの方の samba に接続してしまうのだ。
これが解決できなかった。
今日、(妻がたまたま出かける用事があったので)妻のマシンを長時間借りて調査。
妻の環境でだけおかしいので、妻のマシンの設定を疑ったのだけど、それほどおかしそうなところは無い。
すぐに Linux サーバーに接続してしまうので、試しに Linux サーバーの samba を停止してみる。
すると、QNAP に接続するようになった。
ありゃ。もしかして、samba を同一ネットワークに置くとおかしくなるのか?
でも、前の Landisk だって samba だった。
なにか、ネットワーク上で同居しやすい設定とかあって、そこが微妙に違うのかな?
ここから、samba の設定お勉強タイム。
実のところ、Windows のファイル共有には詳しくないのだけど、一つだけ分かったことがある。
windows の共有の仕組みは、基本的に「何も考えないで良い」ことになっている。
でも、Linux で windows の共有に参加しようと思うと、かなり細かな設定が必要。
そして、設定を間違えても気づきにくい。
windows 側で、それなりに「おかしな設定」でも吸収してしまうようなのだ。さすが windows 、よく出来てる。
でも、おかしいものはやっぱおかしい。
エラーにならないでそれなりに動くからこそ、不具合部分が何に起因するのかなかなかわからなかったりする。
…ということを解説しているページがあって、根が深そうだと暗い気持ちになる。
Linux の samba を止めればうまくいくのだから、何か設定を間違えているのだろうなぁ。
そう思って、samba の設定ファイルをいろいろと変えてみる。
でもうまくいかず。
他にももっと何かないか…と思っていたら、samba のトラブルシューティング方法を書いた HowTo 文書を見つける。
(Linux の世界には、技術を初心者に教えるための HowTo と呼ばれるテキストが数多く残されている)
ここで初めて、体系だった方法で悪い部分を見つけ出すことができるようになった。
順次トラブルシュート手順をこなしていく。
11の手順が示される中の、8番目の手順。
Windows 側から、コマンドラインで \\NAS に接続しようとすると、そんなマシンは存在しない、と怒られた。
#\\NAS 、というのは、Windows のネットワーク共有をコマンドラインから指示するとき、NAS と名付けられたサーバーの意味。
これに対する対応方法も書いてあるのだけど、それは「NetBIOS がおかしい」ことを前提としたものだ。
どうもそうではない。NetBIOS はおかしくない。でも、何かがおかしい。
Windows は、ネットワークの一覧に NAS を表示している。でもそのマシンがどこにあるかがわからない。
認識しているマシンが認識できない、という言葉にするのもおかしな状態になっている。
いろいろ試していて、気まぐれに IP アドレス指定してみると、見えている。
じゃぁ、と思って \\landisk-1 を指定すると、これも見えている。
でも、ネットワーク一覧の中では landisk-1 は出てこない。NAS が出てくる。
えーと、つまり、ネットワーク一覧に NAS として認識されるけど、landisk-1 を指定しないとアクセスできない、と、そういうこと?
DNS に NAS を登録していなかったことを思い出し、landisk-1 の別名として登録する。
これ、後で登録しなくちゃな、と思ったまま、なんとなく動いていたから忘れていた。
これで動くようになった。
さて、一体何が起こっているのか、samba と DNS にどんな関係があるのか、情報を整理しておこう。
samba のそもそも論から入ろう。
Windows では、SMB (Server Message Block)というプロトコルでファイル共有を行う。
これを UNIX からも使用できるようにするためのソフトが、samba だ。
SMB は「ファイル共有」だけを行う。UNIX でいうと、NFS (Network File System)に当たる部分だ。
NFS の場合、ファイル共有は相手サーバーの名前を指定することで行うが、ネットワークは「名前」では接続できない。
このため、名前を IP アドレスに変換する必要が出てくる。これを名前解決と呼ぶ。
UNIX では、リゾルバと言う仕組みで名前を解決する。
リゾルバでは、ローカルファイルに書かれているデータベースか、ネットワークに存在する DNS と呼ばれるデータベースの仕組みを使って名前解決を行う。
Windows の場合、名前解決には NetBIOS という仕組みが使われる。
UNIX の DNS の場合、データを集中管理しているので仕組みが簡潔な反面、管理が結構面倒だ。
NetBIOS では、各マシンに名前を付けるだけで良い。
あとはマシン同士が勝手に、うまいことやって名前を解決してくれる。とても便利だ。
その反面、DNS よりも仕組みが複雑になる。複雑さを反映して、速度が遅かったりもする。
#Windows で「ネットワーク」を開いても、すぐに目的のマシンが表示されなかったりしたこと、ありません?
samba では、 SMB と NetBIOS を、それぞれ smbd と nmbd という二つのソフトで扱う。
smbd は、SMB プロトコルを、nmbd は、NetBIOS プロトコルを解釈する。
ファイル共有と名前解決の方法を、それぞれ持っている。
だから僕は、samba は DNS とは無縁だと思い込んでいた。
NetBIOS は設計が古く、インターネット時代に対応できていない。
普通のネットプロトコル… TCP/IP と共存できないのだ。
そこで、現在は NetBIOS over TCP/IP と呼ばれるプロトコルに移行しているらしい。
面倒なので、これも NetBIOS と呼ばれてしまう。
そして、samba のサーバー側でなく、クライアントの Windows マシンの方では、もう NetBIOS だけには頼っていない。
名前解決の方法は複数ある。これを、一番ユーザーにとって扱いやすいように、ミックスして使う。
先に UNIX では、ローカルファイルと DNS の2つの方法で名前解決する、と書いた。
Windows では、これに加えて WINS と NetBIOS を混ぜ、4つの方法で名前解決する。
#上に「DNS」と書いたのは、実際には UNIX のリゾルバ相当の意味で、ローカルファイルと DNS サーバーを適切に組み合わせる。
そのため、「ローカルファイル」は、NetBIOS 用とリゾルバ用の二つがあることになり、都合5つの名前解決方法がある。
さて、どのようにミックスするかは非常にややこしい。
しかし、基本的に速度の速い方法から順にためし、解決できなかったら次の方法を試してみる、という動作を繰り返す。
ここで、僕が家庭内 DNS の設定として、登録されない名前は Linux サーバーに向かう、としていたことが問題となる。
DNS に何を問い合わせても、とりあえず解決してしまうのだ。
そのため、NetBIOS の出番は無くなり、DNS 設定されていないが NetBIOS は認識している、という名前が正しく処理されなくなる。
これが、「ネットワーク」の一覧に出てくるホストに接続すると、別のサーバーに繋がってしまう、という現象の正体となる。
ちなみに、WINS サーバーは NetBIOS の遅さを解消する仕組み…だと思う。我が家では使っていないし、使ったことないから正確なところがわからない。
DNS みたいなものだけど、NetBIOS の仕組みを使っているので、自動的に名前を収集して設定が手間いらず、というようなものだと思う。
妻のマシンではアクセスできなくて、僕のマシンではアクセスできたとか、Linux のsamba 止めただけで、名前解決できないはずの QNAP にちゃんと接続できたとか、よくわかってない部分もある。
Windows が非常にややこしい方法で、ユーザーが何も設定しないでもつながる仕組みを作ってくれているので、トラブルが起こった場合は何が起こっているのか推察するのが難しい。
#文句を言っているのではない。問題は正しくない DNS 設定にあったのであって、Windows は悪くない。
原因を見つけるのに時間がかかったが、原因がわかれば後は簡単。
NAS を DNS に登録した。これで完全解決。
知らない名前は全部 Linux サーバーへ、という設定も、本当は良くないのだろう。
でも、開発で気軽に名前を作れるのはありがたいので、この設定は変更できない。
全く同じ問題に遭遇する人は、おそらくいないと思う。
でも、Windows の共有設定は NetBIOS で名前解決するので、DNS は関係ない、と思っている人は結構多いのではないかな。
DNS サーバーが混ざっていて、設定が絶妙だとハマることがあるよ、という情報は、ほんの一部の人にとって役立つかもしれないので、ここに記録しておく次第です。
関連ページ
Windows で、二つのネットワークにまたがる VPN 設定を行う【日記 16/12/02】
Harley-Davidson & L.A. Riders【日記 18/02/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |