2015年01月の日記です

目次

01日 あけましておめでとうございます
05日 年越しそばの起源
05日 妻の実家へ
07日 スティーブン・ボーンの誕生日(1944)
08日 ジョン・モークリーの命日(1980)
13日 ロビン・ミルナー誕生日 (1934)
16日 スーパーマリオとパックランドの関係性について
20日 高柳健次郎の誕生日(1899)
20日 SIMON は世界初のPCか?
20日 【追悼】森公一郎さん (LSI-C の作者)
21日 RAID NAS 、QNAP T-220 購入
23日 アプリケーションサーバとしてのQNAP
23日 宮永好道 命日(1993)
24日 Macintosh の発売日(1984)
24日 QNAPにないもの
28日 芸夢狂人 誕生日(1953)
29日 「デフォルト」という言葉の意味
29日 プログラム言語における「デフォルト動作」
31日 Landiskと格闘中
31日 Landisk のデータ復旧


あけましておめでとうございます  2015-01-01 06:52:48  コンピュータ 家族

▲目次へ ⇒この記事のURL

初日の出より前に書いているから、本当は「あけまして」じゃないのだけど(笑)



最近書いていたように、子供と Scratch 始めました。

で、子供に見せるためにサンプルとして作ったのが上のゲーム。


「おとしだま」です。ダジャレかい (^^;

原型は20年くらい前、ごく初期のこのページで、正月に Java で作って公開していたゲームだったりします。



右上の緑色の旗をクリックするとゲームが始まります。

全部で100個の玉が落ちてきますから、マウスカーソルで「拾って」ください。


黄は 1点。青は 5点。紫は 20点。

合計点は左上の数字です。


100個の玉が落ちると終わりです。特にゲームオーバー表示とかありません。




Scratch は、ソースリストも含めてすべて公開することが、WEB上での「公開」の条件です。

上のプログラム、非常に短いです。


プログラム未経験者でも、興味があったら覗いてみてください



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

家族

別年同日の日記

03年 謹賀新年

03年 -70度

05年 A Happy New...

06年 あけましておめでとうございます

13年 あけましておめでとうございます

16年 あけましておめでとうございます

17年 あけましておめでとうございます


名前 内容

年越しそばの起源  2015-01-05 17:32:51  その他

▲目次へ ⇒この記事のURL

仕事始めでやっと PC 起動できました。


いろいろ書くことがあるけど、まずは大みそかにツイッターで書いたことの補足。




年末年始は子供も冬休みで PC に向かえません。

で、大晦日の日にツイッターで「年越しそば」について書いたら、ちょっと(本当にちょっと)反響がありました。


そいじゃ、詳細をここにまとめておきますかね。

「年越しそばって何なのか」という話。




大晦日になぜ年越しそばを食べるのか?


・金細工職人が仕事の後にそば粉を練って金粉を集めたことから、「金が集まるように」という願掛け。

・そばは切れやすいことから、今年の悪いことを断ち切って来年が良くなるように、という願掛け。

・年越しはもうすぐ(そば)、という言葉遊び。

・そばのように細く長く生きられるように、という長寿の願掛け。


などなど、諸説あります。

まぁ、どれもある意味正しいのでしょう。


でも、一番大切な理由は「ソバが簡単に食べられたから」だと思います。



江戸には蕎麦屋・そばの屋台が非常に多く、3800軒ほどあったという調査結果が残っています。


今の東京では、コンビニが5000軒弱


江戸は人口100万人、東京の昼間人口は1500万人

「人口当たりの数」では、蕎麦屋はコンビニよりずっと多かったのです。


ちなみに、東京の歯医者は1万軒。コンビニの倍近くあります。話には関係ないけど。




さて、なんでそんなに蕎麦屋が多いかと言えば、江戸では「外食する」ことが奨励されたため。


当時は食事を作るには火を焚く必要があります。

しかし多くの人が住んでいた長屋の一軒分は狭く、土間は十分なスペースがありません。


万が一、周囲に火が燃え移れば火事になります。

長屋が密集した江戸では失火すれば大火事になるのは必至で、「出来るだけ火を焚かない」ことが奨励されたのです。


#炊事ができない程度、暖を取ったりお湯を沸かす程度の火は使われた。



このため、江戸には多くの食べ物屋があったのですが、特に安かったソバは人気があり、たくさん店があったのです。

赤穂浪士も討ち入り前にそばを食べていますし、落語の「時そば」など、蕎麦屋を舞台とした話も多いです。



余談になるけど、「外食が当たり前だった」というの重要ね。

家で料理作れることが「家庭的」なんていうのは、ここ100年程度の話に過ぎません。


#家が密集していない江戸以外では、各家庭で料理もします。

 でも、いまよりずっと簡素だし、隣近所でおかずを交換したりもしたので、毎食毎食の料理を全部作る必要もなかった。

 「料理できる女性が家庭的」は、西洋文化の影響にすぎないよ。




話はがらりと変わります。


江戸時代は、物を購入する際に「つけ払い」にするのは珍しいことではありませんでした。

店主とある程度顔なじみになれば、つけ払いが効くようになります。


お金は、月末にまとめて払います。

普通は自分から払いに行くのですが、貧乏人が多い江戸のことですから、払いに行かないで逃げようとする人もいます。

(にもかかわらず、店はそれほど多くないため、同じ店にまた買い物に行ったりもします)


あまりつけが溜まると、店側から取り立てに来ます。

そして、年末には取り立てが厳しくなります。何事も年をまたぐ、というのを基本的に嫌う風習があったためです。



大店の使用人にとっては、大晦日の取り立ては大変な仕事でした。

のらりくらりとお金を払わないで逃げ続けてきた人に、何としてもお金を貰わねばなりません。


何人もの相手に対し、集金に回ります。

「年をまたぐ」のを嫌うのは借金している側も同じで、基本的には何とかお金を工面して払おうとするのですが、ここでも逃げようとする人もいます。

毎月末の集金よりも激しい丁々発止が繰り広げられたようです。



取り立ては、大抵日没後にも続きます。

当時は日が変わるのは「日の出」の時なので、日没後もまだ大晦日なのです。


#だから、深夜0時に「あけましておめでとう」というのも当時の感覚ではおかしい。

 「年明け」は、「夜明け」と同時です。




寒い中、やっと集金を終えて帰ってきた使用人に、大店の主人は労をねぎらって暖かいそばを出したそうです。


当時の蕎麦屋は夜遅く(と言っても、当時のことなので夜10時程度)まで営業している場合も多く、そうしたところから出前を取ることも出来ました。


これが「年越しそば」の起源。


年越しそばを食べる、というのは、やっと年内の仕事を片付け、安心して年を越せるようになった、という意味があるのです。



本来商家にしか関係なかったはずですが、一般庶民にもこの習慣が広がります。

と同時に、本来の意図を知らない人向けに、「それらしい」説明が出回り始めます。


…つまり、最初に書いた縁起担ぎなどの話です。

江戸時代にはすでにこれらの説が流布しているし、その説を信じて食べる人も多かったのだから、縁起担ぎ説が間違えているというわけでもありません。



でも、そもそも蕎麦屋が多くなかったら、「年越しだからそば食べよう」と言っても食べられなかったのが江戸庶民。

自分で料理することはできないんだからね。


うどん屋が多かったらうどんになっていただろうし、握り飯屋が多ければ握り飯になっていたでしょう。


#小麦や米は肥えた土地でないと作れないけど、蕎麦は痩せた土地でも作れます

 これが蕎麦屋が多かった理由なので、うどんや握り飯にはなり得なかっただろうけど。



年越しそばの説明としては諸説あるけど、「ソバが簡単に食べられたから」という基本は忘れてはならないと思うのです。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

その他

別年同日の日記

03年 続・C700レビュー

08年 お年玉

09年 寝ズ正月

12年 あけましておめでとうございます

12年 最近のうちの子

13年 CMSプログラム更新


名前 内容

妻の実家へ  2015-01-05 18:21:10  家族

▲目次へ ⇒この記事のURL

年末年始の家族日記をまとめておきます。

他人が読んでも面白くない話。




書いていなかったクリスマス前の話から。


今年の正月こそは、妻の実家に顔を出そう、と妻と相談していました。


もう3年前に顔を出したきり、その半年後の夏に行こうと思ったら実家の仕事が忙しくて行けず、翌年の正月は年末にメールを送ったものの、年度末の忙しさで読まれていませんでした。


昨年は妻が忙しくて行けず。今年こそ顔を出しておかないとね、と考えていました。


そんな矢先に、義兄(妻の兄)から妻に電話がかかってきます。

義母が倒れて危篤とのことでした。



夜の電話だったので、翌日実家に帰ります。

いろいろと相談もあり一泊してきましたが、峠は越えたとのこと。


ただし、意識不明のままで、年を越せるかどうかはわからない、とのことでした。




いつ訃報が来るかもわからない、と思っていましたが、何とか年は越すことができました。

1月2日、家族で妻の実家へ。


義兄は2日から仕事があったそうですが、午前中で終わったとのことで、午後4時ごろには来てくれました。


正月に親戚で集まった…と言っても、お祝いムードではありません。


当面の問題は、実家がゴミ屋敷になっていたこと。

義母は少し前から老人性痴呆の症状がみられていたそうで、物の整理がついておらず、ごみを溜めこんであったり、不要不急のものを多数買いこんであったりしたのです。


義父は家事をすべて義母に任せていたので、家事は全然できません。

義兄も義父も、痴呆症状には気づいていたそうなのですが、義兄がこまめに実家に顔を出して見守っていた、とのこと。


義母が倒れた後も、3日と開けずに実家に顔をだし、義父のために食事など用意しているとのことでした。

(妻は義父の食事を一番心配していて、レトルトや缶詰を大量に買って行きました。)



そして、ゴミ屋敷となっていた家は、義姉(義兄の伴侶)がかなり片づけてくれたようです。

妻曰く「足の踏み場もないほど」だったのが、生活導線は確保されていました。


でも、棚や引き出しの中まではまだ手が回らない状態。




妻の心配事として、包丁がすべてなまくら、というのがありました。

切れない包丁を無理に使うことは危険です。


家から砥石を持っていったので、僕が研ぎます。(中学の頃…ボーイスカウト在籍中から、刃物を研ぐのは好き)

その間に、妻は庭木の手入れ。義母は植物が好きで庭に沢山植わっていたのですが、伸び放題になっています。


子供たちはと言うと、義父が庭で面倒を見てくれました。


義母が植えた植物は食べられるものが多く、隼人瓜、白茄子、柚子が大量に実っています。

義父と一緒にこれらの収穫を楽しんでいました。

(白茄子は収穫には少し遅く、固くなりかけていましたが、すべておいしくいただきました)



包丁。非常に危機的状態。

ほぼ、刃のない鉄板です。薄い鉄板なら力で野菜くらい押し切ることができますが、そんな感じ。


普通家庭で刃物を研ぐのは中砥ですが、そんなのでは足りない。

荒砥で刃を作るところから始めます。


で、しばらくたってどれも非常に良い切れ味が復活。

一つだけ、大きく刃が欠けたままでその部分は切れないのですが、包丁が3本あったので大丈夫でしょう。



包丁研ぎが終わったので妻の様子を見に行きます。

子供たちが遊んでいる中庭とは違い、玄関側の木を剪定しています。

道路に枝が張りだしているのが一番迷惑だから、とのこと。


最初は「剪定」だったのだけど、余りにも伸び放題でどうしようもないので、枯れても仕方ないつもりでどんどん切っている、とのこと。


手伝いたいところだけど、植物知識が無いので僕は剪定は手伝えません…

どうしたものかと思い、玄関先で話をしているときに、義兄一家がやってきました。




義兄一家の子供(5歳の兄と3歳の妹)もうちの子供たち3人と庭で遊び始めます。


3歳の子もいるのでちょっと危ない。

義父一人で、収穫をしながら5人の面倒は見られません。

子守をすることにします。


妹ちゃんが、柚子を両手に持って「お母さんに見せる」と言うので家に入りますが、探しても見当たりません。

玄関先の妻に聞くと、義兄は寿司を、義姉は他に何か食べられるものを買いに行った、とのこと。


うちの子たちは庭で相変わらず遊んでいるけど、義兄の子供は「お父さんもお母さんもいない」という状態に急に不安になり始めた様子。

ご機嫌取りで一緒に遊びます。しばらく遊んでいると、義姉が帰ってきました。




時間は5時前。

義姉が「もうご飯の準備していいのかな」というので、やっちゃいましょう、と答えます。


手始めに、冷凍枝豆を自然解凍した…まだ少し凍ったものが出てきます。


子供たちは「お腹空いたー」と言いながら、これを食べ始めます。おかずのつもりだったのに。

「そういえばおやつは?」とか言い出しますが、義姉と相談の上、ご飯の前だから出さないことに決定。

(うちも義姉も、おやつを買ってきてはいました)


何か手伝いましょうか? と聞くも、ほとんど皿に載せて出すだけだそうです。

それよりは、妻の方が気になるので手伝ってあげて、と言われて玄関先へ。


…ものすごい量の木の枝が落ちていました。

かなりの量がすでにゴミ袋に詰められていますが、一角はいま剪定したばかりでまとまっていません。


じゃぁ、これをゴミ袋に詰めるのを手伝いましょう。

…とおもったら、触ると痛い。ヒイラギの枝が大量にありました。その向こうには松があります。


妻曰く、他にも野茨や薔薇など、とげのある植物ばかりだそうです。

庭先なので泥棒除けのつもりだったのだろうけど、茂りすぎて物陰を作ると逆効果。

泥棒にとっては「仕事を見られない」玄関先が好環境です。



チクチクする枝を拾いつつ、やっとヒイラギは全部片付きました。

その頃、義兄も寿司を持って帰宅。「ご飯にしましょう」と義姉に呼ばれます。


じゃぁ、もうちょっと片づけたら…と思っていたところ、妻が冷静に「やっちゃったから後片づけお願い」と言います。

何かと思ってみると、指から大量に出血している。

区切りの良いところまで早く済ませてしまおう、と仕事を焦り、のこぎりで切ってしまったそうです。


これでひと騒動。傷はそれほど大きくないのですが、血が広がって大出血に見えたので皆心配します。

僕としては、妻のこうした怪我は慣れているので冷静 (^^;;




さて、ごはん。

寿司を皆で食べながら、やっとゆっくり話をします。正月らしいひと時。


最近プログラムに興味のある義兄、うちの長男が簡単なゲームを作った、と聞いて興味を持ちます。

義兄はもともとグラフィックデザイナーですが、最近はそれだけでは仕事になりにくく、プログラムで簡単なゲームなど作れないかと考えているようです。


義兄は独学でプログラムを勉強していて、近くに相談できる相手もいないようなのでしばらくいろんな話をします。



義父は将棋がアマ三段の腕前なのですが、長男に「将棋とかやってるの?」と聞いてきます。

長男も最近将棋に興味を持って、コマの動かし方は一通り知っています。入門書を呼んで、定跡の勉強もしています。


でも、一緒に将棋が出来る相手がいないため、実戦経験がほとんどないです。


ここで、義父が将棋盤を持ってきて対局開始。

長男は本で覚えた「穴熊囲い」を作り上げて、ちょっと得意げ。


…が、すぐに崩されます。非常に強い守りでも、有段者と素人の戦いですからお話になりません。

あっという間に勝負がついて、長男は「強すぎてつまんないー」と泣き言を言います。


義父がそのまま、「その将棋盤とコマはプレゼントしよう」と、セットをくださいました。

うちには小さなマグネット将棋盤はありますが、ちゃんとしたものはありません。

(くれたものは安物で、コマはプラスチックですが、それでも「本物の将棋セット」です)


このセット、翌日から我が家で遊ばれています。

…将棋崩しで。マグネット付では遊べなかったからね。




将棋をやっている間に、妻が台所の棚の整理を始めました。

もう、どんどん捨てていくようです。同じものが複数ある、どう見ても古くてゴミのようなものが置いてある、等はゴミ箱行き。


これを見て義姉も冷蔵庫の整理を始めます。

賞味期限をあまりにも超えたものは廃棄。


台所の棚の上を妻がやろうとしていましたが、妻は背が低いので僕が変わります。

「どんどん捨てちゃっていいよ」と許可をもらったので、とにかく棚から降ろしながら、不要そうなら新品でも捨て、本当に利用価値のありそうなもののみ残します。


よくこんなに入れてあるな、というほど多くのものが棚に入っています。

食器などを入れ、空いたスペースには食品トレーなどを洗ったものを、同じサイズでそろえて重ねて詰め込んであります。


しかし、食品トレーなんて全部ゴミ。サイズをそろえてあって見事なのですが、まとめて処分します。


干支小物…その年の干支の爪楊枝入れ、とか、粗品でもらえるようなものが大量に出てきます。

あー、気持ちはわかる。立派で捨てられないよね。でも全部捨てます。


コーヒーやジュースを買ったときにもらったらしい、商品名入りグラスの数々…

箱のまま取ってあるものもあります。これ、欲しい人は欲しそうだよね。

でも、全部捨てます。


2000年記念のミレニアム漆器酒杯とか出てきました。

「西暦2000年」、とか書いてあって、竜の蒔絵が入っている。

きっと高かったんでしょう、立派な箱入りです。


でも、使わないし誰も欲しがらない。捨てます。


一人用の小さな鉄鍋が3つ、出てきました。

実家は妻が子供の頃に食堂をやっていたので、その時に使っていたもの、のようです。


こういうのって、買うと結構高いよね。でも不要です。捨てます。


本当のごみから、もしかしたら価値のあるものまで。

でも、「勿体ない」なんて言っていると生活スペースが確保できないんです。とにかくバサバサ捨てる。

3時間ほどの作業で、大きなゴミ袋10袋位がいっぱいになりました。




捨てるばかりでなく、「この家には不要だろうが、使えるから貰っておこう」というものもあります。


年末に妻が帰った際に、賞味期限を3年過ぎた、真空パックの本枯節を貰っていました。

3年過ぎたって言っても、鰹節は保存食だぜー。しかも、真空パックだから衛生的にも大丈夫。


でも、問題が一つありました。うちには鰹箱がありません。


だから、実は鰹箱を発掘したら貰おうと決めていました。

そして、発掘しました。刃は錆びついていて、箱も埃をかぶって汚くなっていましたが。


これは後でレストアして、復活しました。

古びた木箱は、サラダ油を少し付けた布でこすって油分を補ってやると、美しさを取り戻しました。


錆びた刃を取り外すのが一番の苦労でしたが、妻が執念で外しましたよ。

刃さえ外れれば、研ぎ直して復活できます。



他にも、新品の爪楊枝、ストレーナー(茹でザル)。うちの台所で使います。


漬けて何年も経つラッキョウ、梅酒、姫リンゴ酒は引き取ることにしました。

賞味期限を少し過ぎただけで未開封の食品類なども。


義母が大根の味噌漬けを作っていたようで…いつ作ったものなのかわからないし、塩味が強すぎて美味しくないのだけど、傷んではいないので引き取りました。

せっかく作っていたものを捨てるのは忍びない、という妻の判断。

塩抜きして料理に使うことにします。


あと、一抱えある大きな冬瓜がありました。

これもいただいて帰り、翌日から料理しています。食べても食べても無くならない (^^;




義兄がコップ洗いブラシ(新品が大量に買ってあった)を見つけ「これ、家で使えるんじゃない?」と言い出したとき、義姉が「持って帰ればいいけど、絶対家に入れさせないよ」と言い切ったのが見事でした(笑)


あれ、便利そうに見えるけど、結構使い道ないんだ。

義姉は片付けもまめにやってくれたようだし、いろいろ家事がわかっている人なんだな、とこの一言に感じることができました。



あとで義姉が言うには、捨てたものを義兄と義父に見つからないようにするのが一番大事、とのこと。

やっぱ、思い出があるからついつい拾い出しちゃって片付かないんだって。


妻ももちろん思い出はあるそうですが、「そんなこと言ってたら片付かない」と、どんどんゴミ袋に物を叩き込んでいきました。

…思い出を多少語りながら。



ここは、思い入れのない部外者が心を鬼にして捨てなくては、と義姉と意気投合。

とはいっても、この日のうちに捨てられたのはここまでに書いた程度なのですが。




子供たちの就寝時間もあるので午後7時には帰ろう、と思っていたのだけど、結局出発は10時前。

従妹と遊んで興奮しているけど、いつもならとっくに寝ている時間。


帰りの車の中ですぐ寝てしまいました。


義母の容態がいつまで持つかはわかりません。

いよいよの時には、いつでもすぐに駆けつけようと思っています。


しかし、親戚としてそれまで傍観しているだけでは申し訳ない。

頻繁に顔を出して手伝わねばな、と思ったのでした。


#遠いし、気軽に行ける距離ではないので2か月に一度くらいがやっとだと思うのだけど。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

別年同日の日記

03年 続・C700レビュー

08年 お年玉

09年 寝ズ正月

12年 あけましておめでとうございます

12年 最近のうちの子

13年 CMSプログラム更新


名前 内容

スティーブン・ボーンの誕生日(1944)  2015-01-07 09:56:59  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日はスティーブン・ボーン (Stephen R. Bourne) の誕生日(1944)。


誰それ、という人でも、彼の名前が付けられた Bourne Shell なら知っているはず。

…あれ? ご存じない?



Linux なんかで、コマンドを打ち込むときに使うものが「シェル」です。

/bin/sh と書いた方がわかりやすいかもしれません。


普通は、わざわざ起動しないでも、ログイン時に勝手に起動されます。

人間の入力を受け付けるプログラムが「シェル」なので、シェルが起動しないと、シェルを起動させることもできないからね。


Linux では、実際には Bourne Shell ではなく、Bourne-again Shell (bash)が使われることが普通です。

Bourne Shell が生まれ変わった (Born-again) 物で、互換性を保ったまま非常に高機能になっています。




Bourne Shell の前は、Thompson Shell が使われていたそうです。


「そうです」っていうのは、さすがにその時代は知らないから。

最初の UNIX を作成した、ケン・トンプソンが作ったシェルで、> と < で標準入出力をファイルにリダイレクトでき、| で別のプログラムに渡せる、という構文は、トンプソン・シェルが最初に定めたものです。


でも、トンプソン・シェルは、ユーザー入力を受け付けるためだけの存在で、その操作を「自動化」するようなことは考えられていませんでした。


…いや、いいんですよ。最初はコンピューターを操作するのがシェルの目的だったし、何か操作を自動化したいなら、プログラムを組むのが当たり前だった。


でも、シェルで定型的に操作するコマンドを、自動化したいという要求が高まってきたのです。



1977年に作られた Bourne Shell は、そうした要求を満たすものでした。


シェルで操作する内容をそのままテキストファイルとして書いておけば、そのまま実行できます(バッチ処理)。


また、直前のコマンドの結果により条件分岐したり、ループを作れたり、「変数」を使えたり、通常のメッセージとエラーメッセージを分離出来たり(エラーは標準出力ではなく、エラー出力を使う)、関数を定義出来たり(1984年のバージョンから)…


「操作の自動化」と言うだけではなく、十分なプログラム言語として成長しました。

スクリプト言語の元祖、と言ってもよいでしょう。




ところで、トンプソン・シェルに限界を感じて作られたのは、 Bourne Shell だけではありません。

カリフォルニア大学バークレイ校(BSD の開発元)では、C Shell というものが作られました。


Bourne Shell は ALGOL 風の表記でプログラムを行うのですが、C Shell はその名前の通り、C 風の表記を使います。

当たり前ですが、Bourne Shell との互換性はありません。


C Shell の特徴は、実はスクリプトの組み方よりも、「操作性の良さ」にあります。

コマンドラインで操作する時に便利な機能が多いのです。


過去に実行したコマンドを大量に覚えておき(ヒストリ機能)、すぐに呼び出せる、というのは C Shell が初めて実装した機能でした。

呼び出すだけでなく、正規表現により一部を書き変えて実行、ということもできます。


後に C Shell の高機能版である tc Shell でさらに便利になり、上下のカーソルキーで過去の実行履歴を呼び出し、左右のカーソルで編集できるようになりました。


そして、現在ではこの機能は Bourne-again Shell でも実装されています。

つまり、現在この機能は「C Shell の優位点」ではなくなっています。




しかし、今でも C Shell の方が優れている部分もあります。


たとえば、大量にファイルが存在していて、そのファイル名を複雑な規則で書き変えたい、という事例があったとしましょう。


C Shell でも Bourne Shell でも、コマンドラインから「すべてのファイルに繰り返し適用」という指示を出すことはできます。


しかし、Bourne Shell (および bash)では、「複雑な規則で書き変え」を指示する方法はありません。



正規表現「マッチ」は出来ますし、マッチした部分を配列に入れることもできます。

ですから、この配列を使ってさらに条件を判断し、目的を達成することは出来るのですが…

これは、ちょっとしたスクリプトプログラムを組まなくてはなりません。


C Shell なら、当たり前に出来ます。

変数の内容などに対し、「正規表現で置換する」ことができるので、「元のファイル名」を「正規表現で置換したファイル名」に書き変える、という指示が1行で書けるのです。



ただ、C Shell でも、その高機能版である tc Shell でも、シェルスクリプトを作る際に「関数」が作れません。

これがかなり致命的で、スクリプトを組むのであれば Bourne Shell の方が組みやすいのです。


僕は会社員時代には tcsh を好んで使っていました。

スクリプトが必要なら、Bourne Shell を使わずに awk や perl で組んでいました。


しかし、Linux って bash が標準であることが多いんですよね…

最初はそれでも tcsh を使っていたのですが、bash ならヒストリ機能なども問題なく使えるし、普段の操作は bash でやるようになりました。


スクリプトなども、他人に渡したりする必要があるものは bash で作ります。

そうすれば、ほぼどこでも動くことが保障されますから。



ただ、今でも先に書いたような「大量のファイル名置換」などが必要な際には、tcsh を起動します。

適材適所で使い分けている。




最後の方は完全にスティーブン・ボーンから話がそれていますが、あらゆるスクリプト言語の元祖であり、今でも UNIX 操作の基本である Bourne Shell を作った、という功績は大きいかと思います。


ちなみに、その後のボーンは、シリコングラフィックスやDEC、SUN、シスコシステムズなど、有名企業で管理職として働いていて、現在も存命です。



当日中に追記

もっと詳しく知りたい人は、IBM の公開している記事Linux におけるシェルの進化をどうぞ。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

03年 続々・C700レポート

05年 Quintuple header

07年 あけましておめでとうございます

09年 FALTIMA030 その後[レビュー・評価]

16年 Serverman SIM LTE 解約


名前 内容

ジョン・モークリーの命日(1980)  2015-01-08 11:08:27  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日はジョン・モークリーの命日(1980)。


ENIAC を作った二人のうち、一人です。主に構想担当。

詳細は誕生日の時の記事を見てね。




命日なので晩年の話を書きましょう。


モークリーは ENIAC で「世界初のコンピューター」を作ったとされ、その後世界初の商用コンピューター UNIVAC-I も作り上げ、コンピューター業界を創世しました。


しかし、晩年になって汚名を着せられ、失意のうちに生涯を閉じることになります。



その汚名とは、「ENIAC はアイディアを盗んだものだ」というもの。

はっきり書いておけば、そんなことはありません。


ENIAC は立派に彼の構想した機械であり、世界初のコンピューター…とは僕は呼んでいないのですが (^^; 後のコンピューター時代の幕開けとなった、デジタル電子計算機でした。



汚名の元となったのは、60年代末から70年代初頭にかけての裁判です。


モークリーはここで、特許論争に巻き込まれることになります。


ENIAC 開発に際し彼は「電子計算機」の非常に多くの特許を取得しました。

これはそのまま彼が後に設立した会社、「モークリー・エッカート社」の物となり、さらには資金繰りの問題から同社が身売りし、レミントン・ランド社、さらに社名変更してスぺリー・ランド社の物となっています。


これは、「スぺリー・ランド社の許可なしにはコンピューターを作れない」ということであり、ここにコンピューター業界の一角であるハネウェル社が噛みついたのです。




当時、コンピューター業界は IBM を筆頭に、8社がひしめき合っていました。


アメリカ政府としても、コンピューター業界を成長させることは、アメリカの経済発展に欠かせない、という意向を示しました。


この中で、裁判は代理戦争の様相を呈していきます。


つまり、ハネウェル社はスぺリー・ランド以外すべてのコンピューター会社と、アメリカ政府を代表する形になったのです。



ハネウェルは、とにかくコンピューターの特許を無効化するため、ありとあらゆる手段を使いました。

その一つが、「ABC マシン」を見つけ出し、掘り起こしたことでした。




ABC マシン…アタナソフ・ベリー・コンピューターは、アタナソフとベリーによって作られた、連立1次方程式を解くための専用計算機です。


ENIAC よりも早く構想されていますが、実際には完成しませんでしたし、物理的な動作個所が多く、とても「電子計算機」と呼べるものではありません。


しかし、とにかく ENIAC よりも前に作られた「電子計算機と呼べそうなもの」を掘り起こすことで、ENIAC が最初ではない、と示すことが目的でした。


最初ではないものには、特許は与えられません。


…実際のところ、これが法廷でどれほどの効果を持ったのかはわかりません。

裁判官は冷静で、これが ENIAC とは全く無関係であることを正しく認識したようです。


結局、裁判は「ENIAC の特許申請手続きに不備があった」ことを理由に、ENIAC の特許を無効として終わります。


アメリカでは、「公表から1年以内に特許書類を提出」が義務付けられています。

モークリーは、ちゃんと ENIAC の完成から1年以内に書類を提出していました。


しかし、ENIAC 開発中に、誘われて「いやいやながら」視察に来たフォン・ノイマンが、この機械のすごさに気付いて勝手に「紹介記事」を書いていました。


これが公表にあたる、と判断され、提出はこの記事から1年以上たった後だった、と結論付けられたのです。



反論しても無駄でした。

特許を無効にしろ、という圧力は政府からもかかっており、裁判官は順法精神と政府圧力の間で板挟みになっていました。


「手続きの不備を見つけて無効化」は、裁判官としても譲れない決着方法だったのです。




特許が無効化されたとはいえ、コンピューターが普及し、可能性が理解されるにつれ「世界最初のコンピューター」という ENIAC の名声はあがります。


そして、名声が上がると「それは私が作ったのだ」と主張する人が、あまりにも多く現われました。


ENIAC は、大きなプロジェクトでした。作成への参加者も数多くいます。

その中には、自分こそがプロジェクトの考案者であり、名声は自分に与えられるべきだ、と主張するものもいました。



フォン・ノイマンもそうした一人です。

彼は先に書いたように、勝手に ENIAC を世に紹介し、そのために特許を無効化してしまい、後続の EDVAC プロジェクトを引っ掻き回して進行を遅らせ、極秘資料を流出させ、そのために「同等品」である EDSAC を先に作られてしまう、という事態を引き起こした張本人です。


しかし、コンピューターはフォン・ノイマンが作った、と信じている人は多く、今のコンピューターは「ノイマン型」と総称されます。



さらに、1970年代末に「最初のコンピューター」のルーツを探る本が発行されます。


その本の中では、先に書いた法廷論争が取り上げられ、ENIAC の特許が無効とされたのは、ABC が先に作られていたからだ、とされていました。


ENIAC の特許が無効化された、というだけでもモークリーにとっては不幸な事でしたが、この本によって、モークリーは「ABC のアイディアを盗んだ」という汚名を着せられることになります。


反面、ABC は一躍脚光を浴びました。完成しなかったし、それまで全く無名の存在だったのに。


コンピューター時代を切り拓いたのは、明らかに ENIAC であり、モークリーのアイディアでした。


…ABC は「ENIAC 以前に2進法を採用していた」ことがよく言われるのですが、ENIAC は10進法で計算しているのです。


また、ABC は「計算する」ことが目的で、物理的な動作個所が多く、速度は問題視していませんでした。

ENIAC は最初から超高速計算が目的で、そのためのアイディアがふんだんに盛り込まれています。



しかし、多くの人は技術には詳しくなく、たとえ嘘であってもセンセーショナルなニュースが伝えられると、興味本位に「覚えて」しまいます。


そして、多くの人が記憶していることは、やがて「それが事実のように」語られてしまうのです。



モークリーは、死ぬまでノイマンを恨んでいました。

しかし、アタナソフについては恨んではおらず、ただ世間から誤解されていることについて涙を流したそうです。




モークリーは、エッカートというパートナーにも恵まれ、独自のアイディアでコンピューター時代を切り拓きました。


現代の先進国に暮らす多くの人が、コンピューターの存在による恩恵にあずかっているはずです。

彼は、世界中の人が幸せに暮らせる時代を作り出した、と言っても過言ではありません。


しかし、その報酬は「アイディアを盗んだ者」との汚名でした。

彼は汚名の返上を願いながらもかなわず、生涯を閉じたのです。



彼は晩年「あまりにも多くのものが失われた」と語っています。

人々が幸せに暮らせる時代を作り出した発明者としては、あまりにも寂しい晩年でした。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

17年 プログラマーの技術力


名前 内容

ロビン・ミルナー誕生日 (1934)  2015-01-13 11:03:28  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日はロビン・ミルナーの誕生日(1934)


さっき調べるまで、僕はこの人のことを全然知りませんでした。すみません。


というか、この人の業績分野に全然詳しくない。ただ、重要であることはわかります。

そこで、今回は資料首っ引きで、理解できた範囲で解説する形でお伝えします(笑)




彼は 1972年に、LCF (Logic for Computable Functions)という名前の、「自動定理証明」プログラムを作っています。

…まず、定理、って言葉を解説する必要があるでしょうね。


数学では、最初にその数学が成り立つ条件を「仮定」します。

あくまでも仮定ね。違う仮定だってあるかもしれない。


この仮定のことを「公理」と呼びます。


たとえば、「2つの点を結ぶ直線は、1つだけ存在する」というのは一般的な幾何学(ユークリッド幾何学)の公理です。

普通、図形を扱う場合にはユークリッド幾何学が使われますので、この仮定の上にすべてが成り立っています。


言い換えれば、「2つの点を結ぶ直線は1つ」というのは、必ず正しいです。


ただし、世の中には別の幾何学系と言うものもあり、その系では正しいとは言えないかもしれません。

必ず正しいというのは、あくまでも「仮定」に基づいた話ですから。



なんだか冒頭からややこしそうな話になっていますが、こうした「公理」から導かれ、「公理が正しいとするなら」という前提付で「必ず正しい」とされるものを、定理と言います。


「2つの直線が交差した時、向き合う角の角度は同じである」


というのは、ユークリッド幾何学における定理です。


先に書いたように、公理は「ユークリッド幾何学において」という条件付きで、必ず正しいです。

ですから、その公理から導かれる定理もまた、同じ条件では必ず正しいです。




あー、ややこしい数学の話になってきてしまっていますが、後の話は簡単。


公理から導かれる定理、というのは、あくまでも「絶対正しい」もののはずです。


じゃぁ、いくつかの公理を元に必ず推論できるはず。

どの公理をどのように組み合わせればよいのか、ひたすら組み合わせればいつかは正しい組み合わせに辿りつくはずなので、コンピューターにもできるはずです。


これを「やらせてみる」ためのシステムが、「自動定理証明」。

人工知能研究の一環として、今でも、よりシンプルで美しい証明を導けるシステムを目指した開発が行われています。


ロビン・ミルナーの作った LCF は、こうしたシステムのごく初期のものです。




さて、ミルナーは、LCF を作るにあたって、この「ややこしいシステム」を簡素に書けるためのプログラム言語から設計しました。


当時はプログラム言語も黎明期。科学計算向けの FORTRAN 、ビジネス計算向けの COBOL …など、目的別に違う設計の言語があるのが普通でした。


そして、彼は自動定理証明を行うシステムを書くために、「非常に複雑なシステムをすっきりと書ける」言語を設計したのです。


ここで注意すべきは、LCF 自体が「プログラム言語」である、ということです。


コンピューターに何かを行わせるような、いわゆるプログラムを書くわけではありません。

しかし、いくつかの公理と、証明すべき定理を「記述」する必要がある、という点で、LCF はプログラム言語なのです。


プログラム言語のプログラムを書くためのプログラム言語。

なんとも奇妙な関係ですが、ルミナーはこの言語に「メタ言語」という名前を付けました。


メタ、とは、何かの概念の元となる概念を意味する接頭語です。

言語の元となる言語なので、「メタ言語」…英語では Meta-Language です。


この「メタ言語」は、頭文字をとって ML と呼ばれました。



この ML がプログラム言語としてはなかなか使い勝手の良い言語で、多くの人が亜種を作りました。

しかし、あまり亜種が増えるのも困りもの。ML の「標準」を作ろう、という流れが出来上がります。


そして生み出されたのが Standard ML 。SML として知られる言語です。

この SML は「標準仕様」であり、これをもとに多くの実装が作られています。



ただ、ML の亜種がすべて SML に吸収されていったわけではない。

もう一つ、大きな亜種が育ちました。


Caml という ML の亜種があり、それに Object の機能をもたせた OCaml。

結構人気のある言語だそうです。(僕は使ったことないので伝聞調 (^^; )



SML、OCaml 共に、いわゆる「関数型言語」と呼ばれるものです。


関数型と手続型(いわゆる、普通の「プログラム言語」)の何が違うのか、というのは宗教論争になりがちなのであまり踏み込みません (^^;;




晩年には並列プログラミングの研究も行っていたそうで、こちらにも重要な功績をいくつも持っているようです。


LCF の開発、ML の開発、並列プログラミングの研究…が、彼の3大功績のようです。



こんな多くの功績がある人ですから、チューリング賞も受賞していますし、多くの大学を渡り歩き、研究所の所長や、計算機科学科の学科長なども務めています。


…にもかかわらず、博士号を持っていません!


今回、彼のことを調べていて一番驚いたのがこのこと。

研究者として大学などに雇ってもらおうと思えば、博士号を持っていることは最低条件…のはずです。一般的には。いや、日本では。



でも、彼は博士号を持っていないのに多くの大学を渡り歩きましたし、所長や学科長も務めたのです。


博士号を持つということは、指導教官が付いたということでもあり、その指導教官の紹介でより「偉い人」に紹介してもらえることを意味します。


彼は、そんな重要な「パイプ」を持っていないにも関わらず、自分で道を切り拓き続けたのです。


…つまり、それは「優秀な人間がいるのであれば、肩書などにこだわらずに地位を与える」という、本当の意味での実力主義、本当の意味での「人を見る目」を持った社会の存在を意味しています。



これ、日本の社会に一番欠けているものではないかな、と思います。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

関連ページ

ロビン・ミルナー 命日 (2010)【日記 16/03/20】

別年同日の日記

03年 日記が長いね…

11年 あけましておめでとうございます


名前 内容

スーパーマリオとパックランドの関係性について  2015-01-16 13:56:05  コンピュータ

▲目次へ ⇒この記事のURL

このテーマで書くのは3度目。


最初は、宮本さんの誕生日の記事でした。

そこで、ネット上に書かれていたスーパーマリオの製作に至る話を引用して記事を書きました。


引用した記事の骨子は、スーパーマリオは宮本さんが「パックランド」を研究して作られたものだ、というもの。

参考文献として書籍をあげ、その書籍から引用した「真実」であるかのように書かれていました。



しかし、後でその記事が「嘘だ」と指摘があったのを知りました。

細かな証拠などを挙げていて、納得できる内容の記事だったので信じていたのだけど、嘘だと指摘していたのはゲーム業界事情にもそれなりに詳しい方。


これはちゃんと調べねば…と思ったのだけど、僕の調べた限りでは、嘘だという指摘のほうがなんだかおかしい。

細かく検証して、「嘘だ、という指摘が嘘」であることを明かす記事を書きました


ただ、元記事に関しても「真実」として書かれている内容がかなり怪しいことも指摘。

どうも、捏造記事であることは事実のようでした。


元記事は「捏造」が入っているけど、ある程度の妥当性はある。

反論記事は全くのデタラメで、反論の体を成していない、という状況でした。


また、結局パックランドとスーパーマリオの関連性に関しては不明なままでした。



2回目の記事に対するコメントを、年末にいただいていました。

故・飯野賢治の書いた本に詳細が載っている、とのことだったので早速古本を探して入手。


ただ、年末年始は忙しくて読む暇がありませんでした。

該当部分は読んだのだけど、何か書くなら全部読破してから、と思ったので。



で、やっと読破したので引用を交えながら、この問題に決着を付けたいと思います。




まず、該当の本について。

スーパーヒットゲーム学」というタイトルの本で、飯野賢治が他のゲームクリエイター6人にインタビューした本です。


ネット上の評判では、意味が解らないとか、飯野賢治が偉そうすぎてムカつくとか、そういう意見もあります。


これは、「ゲーム作成経験者同士」だから分かり合えるような、一般向けでない話こそ知りたい、という意図でインタビューが行われているからです。

飯野賢治は年下であるにもかかわらず友達口調で話しかけているのだけど、これも気さくに話をしてもらうための配慮の模様。

(たしかに、元々偉そうな人ではあるのですが、話題のそこかしこに「尊敬の念」はあふれているため、僕は友達口調を馴れ馴れしいとは感じませんでした)


意味が解らないことに関しては、宮本さんに対するインタビューとしては、次のような部分がありました。

(スーパーマリオに関しての話題)


飯野 ところで、土管に入って下の世界に行くというのは、あれはどういう発想ですか? めちゃくちゃ変ですよ、あのアイデアは、普通考えつかない(笑)

宮本 その前作の『マリオブラザース』の時に、困ったんだよ、最初。下に行ったときにどうやって上に上げようか。あれは本当に困った。僕、数週間ずっと困っていてね。家の帰り道に崖からドカッと土管が出ているのを見て、プラスティックの簡単な土管やけど、そうか、土管に入っていって土管から出てきたら裏で不思議なことが起こっているかもわからん。それで、土管が『マリオブラザース』のキービジュアルになった。それから、土管を描き込むならニューヨークやと。

飯野 なんでよ(笑)。


この話題、これで終わりです。「ニューヨーク」って唐突に出てきて、それに関する説明は無し。

マリオブラザースのどこら辺がニューヨークなのか、全く意味不明。

飯野賢治の「なんでよ」ってツッコミは、そこに向けられたものなのですが、答えはありません。(宮本さんがこのツッコミに応えず、話を続けたため)


ただ、ある程度知識のある人なら言っていることの意味が解るでしょう。


ニューヨークの下水には巨大な白いワニが棲んでいる。


これ、結構有名な都市伝説で、アメリカ人なら誰でも知っています。


1930年代にはすでに出回っていた伝説で、ニューヨークの下水道整備が比較的早かったこと、それが故に誰も全容を理解できていないこと、非常に繁栄した都市であるがゆえに「負の部分」の噂を人々が面白がったこと、などが話の背景にあります。


下水道には餌となるネズミもたくさんいるし、白いのは日が当たらないため、などと信憑性を高める「小道具」もあふれています。

筒井康隆も小説のネタにしていたと思うし、アメリカの映画などでもネタにされます。だから、日本人でも知っている人は多いです。


ちなみに、この都市伝説にはバリエーションが多く「下水道にロシアの潜水艦が潜んでいる」なんてものまであります。

下水道を進んで行って潜水艦をやっつけるゲーム、なんてのもある。


こういう背景を知っていると「土管ならニューヨーク」という発想が理解できます。

そして、下水道の中に増えてしまった生物を退治する、というマリオブラザースが出来上がるわけです。


ここら辺が理解できない人は「何言ってるんだかわからない」という反応になるのでしょう。


#上の部分には何の解説もなく、本当に「意味不明」になりやすいのですが、ゲーム関連の話題に関しては、この本ではたくさんの脚注がついています。

 ただ、この脚注を誰がまとめたのか、間違えだらけなのね…

 飯野賢治は正しい認識で話をしている感じなので、脚注を付けたのは別人でしょう。そして、ゲーム愛が足りない。

 良い本なのですが、ちょっと残念な部分です。




飯野 なるほどね。でも、『スーパーマリオ』の登場は、すごく突然な感じがしたんだけど。ゲームの進化の中で突然あの世界は(笑)。

宮本 『パックランド』がありました。それまでにジャンプゲームと言うものを作ってましたでしょ。僕はナムコシンパで、ジャンプゲームをやってこないナムコにすごい敬意を払っていたんです。僕らが作っているジャンプゲームをいじってこない。ところが、『サーカスチャーリー』とか、よその会社からその手のゲームがどんどん出てきて、我が社も当然、一番最初の『ドンキーコング』のときにスクロール的なものを始めている。あの頃すでに、『スクランブル』とかはあったから、スクロール基板が欲しかった。それが、『マリオブラザース』で一応完結しましたね。しかし、でかいキャラクターのスクロールジャンプゲームとなると、うまくいかない。唯一あったのはカメを上から踏むっていうアイデアだけ。

飯野 何で突然、カメを踏もうと思うんですか(笑)。そこが変ですよ。

宮本 キャラクターが小さいと分かりにくいから、大きくなった時に踏むというジャンプゲームの実験はしてたんです。そんな時にナムコから『パックランド』が出てきた。ゲームセンターで、僕、東京に行ったときに『パックランド」が置いてあって、ナムコがジャンプゲームに手を出してくるのかと、それなら俺がやってやろうじゃないかと。それがきっかけ。


これが「パックランド」と「スーパーマリオ」の関係性を伝える核心部分。


詳しくない人のために解説しておくと、当時のゲーム業界は広がりを見せ始めた時期です。


みんなが「インベーダーゲーム」の真似をして出来上がったゲーム業界で、他社のコピーや真似をするだけでは、ライバルが多くて辛くなってきます。


そこで、アイデアを競う時代に入ります。一番突拍子もないアイデアを次々出し続けていたのは、ナムコ。ギャラクシアンはインベーダーの延長上にあるゲームでしたが、パックマンでは「食べる」、ディグダグでは「掘る」という動作でゲームを作り、マッピーでは「ドア」を武器としてしまいました。


誰も考えつかないようなものからゲームを着想する、この点でナムコは一目置かれる存在でした。


一方、任天堂は「ドンキーコング」で、ジャンプする、という動作を取り入れます。

(この書籍では、ドンキーコングが何処から着想されたかも明かされています)


このアイディアはすぐに他社にまねされることになります。

サーカスチャーリー(コナミ)は、その中でも特に売れたゲームの一つ。


でも、ナムコは真似しようとはせずに、常に「オリジナル」のアイディアを大切にしていた…

ここまでが、宮本さんが「ナムコに敬意を払っていた」と語っている理由。


ところが、ナムコは「パックランド」でジャンプアクションを作ります。

これに対し、ジャンプアクションは任天堂が始めたものだ、もっと良いものを作ってやる、というのがスーパーマリオを作るときの気持ちにあった、と語っているのです。




ただ、スーパーマリオがパックランドの真似か、というとそうではない。


パックランド以前から「横スクロールして、大きなキャラが冒険するジャンプアクション」の構想はあったと語っています。


いろいろ実験していて、アイデアの断片もあって、でもうまくまとまらなかった。

それがパックランドの影響で一気にまとまった、という形。



引用部分に「ドンキーコングのときにスクロール的なものを始めている」とあるのですが、多くの人が知っている通り、ドンキーコングはスクロールしません。


どうやら、ドンキーコングの時に「スクロールする」構想はあったけど、ハードウェアの問題で見送った、ということのようです。

「マリオブラザースで完結」というのも、スクロール「できない」という制約の中でやるのは、これで最後にしよう、という気持ちだった様子。



つまり、制約があって作れなかっただけで、かなり早い段階から「スクロールして冒険する」ゲームを考えていたようなのです。

スクランブルの話も出ていますが、あれは当時の大ヒットゲーム。同じような機能があれば…というアイデアは膨らんでいたのでしょう。


また、ジャンプアクションと横スクロールゲームのヒットがあったのだから、「パックランド」と「スーパーマリオ」が似ているのも道理。

真似したのではなく、時代の流れだった、ということになるでしょう。



ここら辺はインタビューの全体を読まないとわからないのですが、流石にすべて引用できないので、気になる人は本を入手して読んでください。




改めて、今回の記事に繋がる大元となった記事を読んでみました。

(すでに、執筆者により削除されていますが、インターネットアーカイブに保存されています)


元記事、あたかも「宮本さん自身が明らかにした事実」であるかのように書かれています。

しかし、今回読んだ本と食い違う部分が多々あります。


特に「パワーアップ」に関する部分は大幅に食い違っている。

宮本さんの思考では、スーパーマリオは最初に「大きなキャラが動く」という目標があって、それだけだと大味なゲーム展開になるので「やられると小さくなる」という形式が出来たのだそうです。


だから、ゲーム上はパワーアップに見えるけど、実際の思考過程ではパワーアップではない。

これをパックランドよりもわかりやすい「パワーアップのアイディア」を考えた、とする元記事は、明らかにおかしな内容です。


また、パックランドでは「攻撃手段が乏しい」ために踏みつけられるようにした、というのも違っている。

引用個所にあるように、パックランドを見る前から、大きいキャラで踏みつける、という攻撃方法は決まっていました。



これらの食い違いから、元記事は捏造記事だったと断じても良いかと思います。

実のところ、僕が2回目に書いた検証記事でも、おそらく捏造だという判断はしていたのですが、さらに裏付けられた形です。


宮本さんが明らかにした、という形式を取らず、外形から状況判断してこうだったのではないか…という類推記事であれば問題ないレベルだったと思うのですが、残念ながら宮本さんの名を語った時点で「嘘」と言われても仕方がない。


でも、嘘だと論じた反論記事は、すでに書いた通り反論の体を成していません。

反論記事の骨子は「スーパーマリオを作る際にパックランドが参考に出来るわけがない」という状況証拠の提示でしたから。


今回入手した本で、宮本さん自身が「パックランドが影響している」と語っています。

参考に出来るわけがない、という反論自体が、嘘です。



2つの問題記事、結局どちらも嘘でした、という結果です。

(これも前回すでにわかっていたこと)



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

アーカイブとはなにか【日記 16/12/17】

スーパーマリオブラザースの発売日(1985)【日記 14/09/13】

ゲーム開始時の主人公の位置【日記 15/04/08】

ゲーム開始時の主人公の位置【日記 15/04/08】

別年同日の日記

04年 タワーリング・インフェルノ


名前 内容

高柳健次郎の誕生日(1899)  2015-01-20 10:37:51  コンピュータ 歯車 今日は何の日

▲目次へ ⇒この記事のURL

今日はテレビの父、高柳健次郎の誕生日(1899)。


テレビの父、と呼ばれる通り、テレビの基礎技術を完成させた人です。

日本人ですが、この方法が世界中で使われていたのだからたいしたもの。


テレビだけでなく、光と電気の関係する産業を起こしたのも功績です。

カミオカンデ作成には欠かせない、高性能の光電子倍増管を世界で唯一生産できる浜松ホトニクスも、高柳健次郎の教え子が興した会社です。


詳しくは、命日の際に書いています




ところで、アナログテレビ放送の時代、日本は NTSC でしたが、世界的には PAL という規格もありました。

全然違う規格なんで、テレビゲームとか作るときに大変なんだわ。


NTSC は秒60コマ。PALは秒50コマ。

1秒間に送り出せるドット数はほぼ同じで、結果としてPAL の方が解像度が高い。


静止画での美しさを取るか、動画にしたときの滑らかさを取るか、開発者の思惑が違ったのかなー、なんて思ってたのですが、これ、単に家庭用電源の交流周波数を元にしているんだそうです。


アメリカでは 60Hz 、ヨーロッパでは 50Hz。

なるほど、ただそれだけの話か。


NTSC も PAL も、それ以前の「白黒放送」との互換性を保ったままカラー化した方式です。

そして、白黒だった当時、一番簡単・安価に「周波数を作り出す方法」は電源の周波数をそのまま流用することだった、というのも理解できる話です。


#日本では地域によって周波数が違うので、発振回路が別途必要となり、安価な製品は作りにくい。

 国内でしか通用しない独自技術が必要となる、というルーツはこの頃からあったのだな。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

歯車

今日は何の日

関連ページ

森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】

1988年のパソコン事情【日記 16/03/05】

1988年のパソコン事情【日記 16/03/05】

別年同日の日記

06年 ウッドデッキ完成

07年 人生初ギャグ?

13年 ピクミン

17年 1996年のそのほかのゲーム


名前 内容

SIMON は世界初のPCか?  2015-01-20 12:12:48  コンピュータ 歯車

▲目次へ ⇒この記事のURL

少し前の 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 の作った文化を知る最後の世代です。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

歯車

関連ページ

森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】

1988年のパソコン事情【日記 16/03/05】

1988年のパソコン事情【日記 16/03/05】

別年同日の日記

06年 ウッドデッキ完成

07年 人生初ギャグ?

13年 ピクミン

17年 1996年のそのほかのゲーム


名前 内容

【追悼】森公一郎さん (LSI-C の作者)  2015-01-20 17:46:26  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

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 のコードを生成するようにする、後付けの「オプティマイザ」も有志の手で開発されていたようです。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

関連ページ

森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】

1988年のパソコン事情【日記 16/03/05】

1988年のパソコン事情【日記 16/03/05】

別年同日の日記

06年 ウッドデッキ完成

07年 人生初ギャグ?

13年 ピクミン

17年 1996年のそのほかのゲーム


名前 内容

【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)

RAID NAS 、QNAP T-220 購入  2015-01-21 20:08:18  コンピュータ

▲目次へ ⇒この記事のURL

使っていた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秒ほど押す。

後は自動でコピーされるのを待つだけ。結構時間がかかる。




まだまだ設定しないといけないことは多いのだけど、まずはコピーが終わるまでほおっておくのが良いだろう。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

アプリケーションサーバとしてのQNAP【日記 15/01/23】

Landiskと格闘中【日記 15/01/31】

Landiskと格闘中【日記 15/01/31】

別年同日の日記

03年 うざいやつ

04年 レベルX

16年 ポール・アレン 誕生日(1953)

17年 家の10年目メンテナンス

17年 風邪ひき


名前 内容

アプリケーションサーバとしてのQNAP  2015-01-23 15:23:03  その他

▲目次へ ⇒この記事のURL

一昨日に引き続き、QNAP の話。


以前の NAS のバックアップデータから、QNAP にデータを取り込んだ。

500GB 程度のデータを取り込んで、18時間ほどかかった。


この取り込み中に、QNAP は初期の「レイド構築」を同時並行で行っている。

ハードディスクとしては、あちこちシークして遅い状態だろう。


ただ、USB 3.0 接続されたハードディスクからの転送速度は決して早くはないはず。

(スペック上はハードディスクの SATA より速いのだが、実行速度はそんなに速くない)


シークがどれほど「転送速度の遅さ」に関与したかはわからない。


ま、ほっとくだけだし、初期設定中でももう使い始められる、という話でもある。



#後日気付いた。

 TS-220 は USB 3.0 を「搭載」しているが、外部メディアからのデータ取り込みは前面 USB に機能が割り振られていて、前面 USB は 2.0 だった。

 遅いと思ったら 2.0 で転送していた、という話。多分、同時にレイド構築していたのは問題ない。




単に RAID NAS が欲しくて QNAP を選んだのだけど、データ転送させながらいろいろ見ていると、想像以上に多機能だとわかってきた。


まず、NAS としては非常に多くの転送プロトコルに対応している。


NAS って、基本は「ネットワークファイルサーバー」なので、SMB (Windows のファイル共有プロトコル)と、AFP (Mac のファイル共有プロトコル)が使えれば、一応の格好は付く。


今まで使っていた LANDISK はこの二つだけだった。

でも、QNAP は NFS (UNIX のファイル共有プロトコル)も使える。


NFS は、ファイル共有プロトコルとしては最初のものだ。AFP も SMB も、その真似をして作られた、と言ってよい。


そして、QNAP は他にもいろいろ使える。

FTP,SFTP,TFTP が使える。これらは、クライアント側に専用のソフトを必要とするファイル転送方式だ。

専用ソフトが必要だが、逆に言えばソフトさえあれば、OS レベルで対応していなくてもファイル転送できる。


WEB でもファイルのアップロード/ダウンロードができる。


ダウンロードする際は WEB ブラウザでファイル一覧を見るわけだけど、いわゆる WEB インターフェイス…非常に使いにくいものではなく、Javascript を使って作られた専用ソフトがある。

Windows の Exploler や MacOS の Finder みたいな感覚でファイルを探せる。非常に使いやすい。


そして、iSCSI も使える。

え! これには驚いた。もう、本末転倒、何が何だかわからない状況だ。


NAS っていうのは、SAN に対する皮肉から始まっている。


先に書いたが、UNIX には NFS というファイル共有方法があった。

でも、これは「起動した後」にしか使えない。起動のためにはローカルにディスクが必要だ。

さらに、通常のネットワーク線を使うので、速度もローカルのハードディスクより遅い。


これを改良したものが SAN だ。

複数のマシンでハードディスクを共有するのだけど、専用のハードウェアと、超高速のネットワークで接続する。

すると、ネットワークで共有しているディスクなのに、ローカルのディスクと同じように見える。


超高速でデータを扱えるし、そのディスクから起動だってできる。

ローカルマシンには、もはやディスクはいらない。


これが SAN (Storage Area Network)なのだけど、専用の機器を使用するために非常に高価。



これに対して、ファイルを共有するだけなら専用ハードなんていらないでしょ、と皮肉って始まったのが NAS だ。一応 Network Attached Storage の略なのだけど、SAN の逆、という意味合いの方が重要。


NAS は実際には NFS と同じようなものなのだけど、時代が進んでいろんなファイル共有プロトコルが存在するので、SMB と AFP を両方使えて、Win と Mac が仲良くできる、ということが結構重要だった。


というか、NAS が出てくる前までは、Samba と Netatalk を入れた Linux マシンでファイル共有するのが流行した。

でも、この設定凄くややこしいんだ。それをパッケージして製品として売ってしまったのが NAS 、と思っていい。



で、先に書いた iSCSI 。

これは、超高速になったイーサネットを使って SAN を構築する際に使われるプロトコル。

いわゆる「ファイル共有プロトコル」ではなくて、ディスク装置を動かすための SCSI プロトコルを、ネット対応にしたものだ。

だから、ネット越しのディスクをローカルディスクのように扱える。NAS が皮肉った SAN なのだ。


そんなわけで、QNAP は NAS でもあるけど、SAN でもある。




というわけで、QNAP が NAS としては非常に高機能であることはわかってもらえたと思う。


でも、QNAP が NAS である、というのは、機能のほんの一部でしかなかった。

僕は NAS が欲しくて性能比較をして、「手ごろな割に高性能」なので QNAP を買ったのだけど、NAS である、というのは QNAP の機能のほんの一部でしかなかった。


一昨日も書いたけど、mySQL が動いたり Apache が動いたり…というのは、僕としてはどうでもいい。

だって、Linux サーバーが欲しいなら、仕事のために常時稼働しているもの。


人によってはありがたいかもしれない。


WordPress を QNAP に入れれば、そのまま家の外に向けて公開できる。

そういう環境に憧れていても、知識がなくて構築できない人もいるだろう。


QNAP なら安価に環境構築できる。




僕が注目したのは、Linux サーバーとしてではなく、「Javascript によるアプリ配信プラットフォーム」としての機能だ。

いわゆる、アプリケーションサーバと言うやつ。


QNAP に WEB アクセスすると、Javascript で動作する独自の OS が動作し始める。

各種設定などは、この OS 上で動いている管理ソフトで行える。


LANDISK も、管理画面は WEB でアクセスできた。

でも、それは管理画面だけだった。


QNAP の OS は、管理画面じゃない。

「管理ソフトも動作する OS 」だ。


だから、ユーザー登録ができる。

管理ソフトを使う場合は Admin で入るのだけど、普段は一般ユーザーを使って使うのがいい。

家族分のユーザーを作っておこう。


OS の上では、写真管理ソフト、ビデオ管理ソフト、音楽管理ソフトなどが動作する。


これがまた、結構使いやすい。

写真を整理するだけでなくて、いくつかまとめてアルバムを作ったり、共有するか、プライベートかなどを選べる。


ここら辺で、先に書いた「ユーザー設定できる」ことが活きてくる。

ちなみに、共有する際には、さらにネットに公開することなどもできるので、写真を人に渡すのに DropBox とか使う必要もない。



ところで、実は写真管理ソフトでビデオも扱える。

じゃぁ、なんでビデオ管理ソフトがあるのかと言えば、ビデオ用に特化することで使い勝手をあげているのだ。


だから、インターフェイスなんかは統一されている。

別のソフトだから、と違う操作を覚える必要はない。


音楽管理ソフトでは、そのまま音楽を聴くこともできる。

(裏ではストリーム配信されているのだが、そんなことを気にする必要はない)

もちろん、ビデオだってみられる。




実は、メディアはちょっと特別扱いされていて、ファイルが入れられたときにすぐにバックグラウンドで整理が始まる。

写真ならサムネイルが作られる。ビデオなら解像度の変換が行われる。


これで、写真管理ソフトではサムネイルがすぐ出せるし、スマートフォンでビデオを見るときに適切な解像度で配信したりできる。


最初に設定しておく必要はあるけど、使う人が何か気にする必要は、一切ない。

普通の NAS のつもりで、データを入れるだけで良い。




さらに、こうしたアプリケーションは、App Center というアプリを使って、ネットからインストールできる。


先に「ビデオ管理ソフトがある」と書いたけど、実はデフォルト状態では入っていない。

写真管理ソフトでもビデオ管理できるから、本当に欲しい人だけが入手すればいいの。


USB のチューナーを使って、テレビ番組を撮りためるためのアプリもある。

同じアプリで再生もできるし、DLNA などで配信もできる。


ネット対応の監視カメラを使って、映像を記録し続けるアプリもある。

QNAP 買ってきたら、簡単に監視システムが構築できてしまう。


もちろん、監視って言ったって窮屈な意味合いで使わないでもいい。

庭のお花がいつ咲くか、ずっと撮影し続けたって楽しいじゃない。


サードパーティ製のアプリもあって…スーパーマリオブラザースがあったので入れてみた。

NAS だから SMB が入っている、というシャレなのかもしれない。


エミュレータかな、と思っていたのだけど、Javascript で作られたクローンだった。


Javascript なので、QNAP から WEB ブラウザに配信したら、特に QNAP 側でプログラムが動くわけではない。

無駄に負荷をかけて不安定になることもないし、いいんじゃないかな、と思いながら、すぐ消した(笑)


#デモとしては面白いけど、同じものをネットでも配信していると分かったので。完成度も、悪くないけど高くもないし。

 関係ないけど こっちのゲームの方が好み。


どんなことができるのか、興味がある人は、こちらにいけば、現在公開中のアプリが一覧できる。

機種によっても使えるソフトが違うので、全部が使えるわけではないけどね。




QNAP にインストールするアプリ、とは別に、Android や iOS にインストールし、連携できるアプリもある。


たとえば、ファイルブラウザはファイルを見るためのものだけど、ビデオを Chromecast に送ったりもできる。


家族のビデオを NAS に置いてあるのだけど、前の LANDISK では DLNA しか使えず、一覧性が悪いので事実上使い物にならなかったんだよね。

これ、便利。


QNAP から直接 Chromecast に送れる、という触れ込みのアプリもあるのだけど、今のところどう設定するのかよくわからない。

(わざわざ PC を使わないで良い、という意味で、スマホアプリから送る方が楽そうだし)



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

その他

関連ページ

監視ユーザーの問題回避【日記 16/07/14】

QNAPにないもの【日記 15/01/24】

Landiskと格闘中【日記 15/01/31】

Landiskと格闘中【日記 15/01/31】

別年同日の日記

12年 ゲームボーイの CPU

16年 iOSでtextのコピー・ペーストができないバグの回避


名前 内容

宮永好道 命日(1993)  2015-01-23 16:08:44  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は宮永好道さんの命日(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 の情報も、このプロフィールを別の言葉で書き直しただけのように見えるから。



そして僕は、このプロフィールを読んだ時に、「まだ健在なんだ」と思ったのでした。

パソコンサンデー出演時に、すでに結構年のように見えたから。


でも、これ書店で見かけて買っただけ。発売すぐに買ったわけでもない。

正確な購入日は忘れましたけど、もしかしたらもうその時には亡くなられていたかもしれない。

そうとは知らずに「まだ健在なのか」と思ったのかも。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

関連ページ

監視ユーザーの問題回避【日記 16/07/14】

QNAPにないもの【日記 15/01/24】

Landiskと格闘中【日記 15/01/31】

Landiskと格闘中【日記 15/01/31】

別年同日の日記

12年 ゲームボーイの CPU

16年 iOSでtextのコピー・ペーストができないバグの回避


名前 内容

Macintosh の発売日(1984)  2015-01-24 17:20:24  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は、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 を追い出されていて不在だった。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

03年 大嘘ぶっこいてました (^^;

03年 カツサンド

04年 給与計算


名前 内容

QNAPにないもの  2015-01-24 17:38:28  コンピュータ

▲目次へ ⇒この記事のURL

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回でいいから、スケジュールに入れておくといいかも。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

別年同日の日記

03年 大嘘ぶっこいてました (^^;

03年 カツサンド

04年 給与計算


名前 内容

芸夢狂人 誕生日(1953)  2015-01-28 11:24:48  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は芸夢狂人さんの誕生日(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 も購読していなかったので、直接記事を読んだこともない。

非常に残念なことではあります。


しかし、それでも芸夢狂人、という名前は知っていました。

それほど有名だったのです。


名前のインパクトがあったからよく覚えている、というのもあるかもしれませんが(笑)



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

04年 アンケート・その後

05年 おはなしせんせい


名前 内容

「デフォルト」という言葉の意味  2015-01-29 11:28:11  コンピュータ

▲目次へ ⇒この記事のURL

いつも朝食の準備をしながら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横浜は酷かったのよ…


視聴者からのメールで生半可な知識仕入れて、「用例」をコントのように繰り広げるのだけど、「初期設定」とか「付属品」の意味で使おうとするから、意味の解らない珍妙な会話になるの。

聞いてて恥ずかしかった。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

ラリーウォールの誕生日(1954)【日記 13/09/27】

プログラム言語における「デフォルト動作」【日記 15/01/29】

別年同日の日記

05年 外構チラシ

09年 ジョウビタキ

10年 加湿器

16年 【追悼】マービン・ミンスキー

16年 AI囲碁


名前 内容

プログラム言語における「デフォルト動作」  2015-01-29 16:46:22  コンピュータ

▲目次へ ⇒この記事のURL

さっき、デフォルトの話書いたのだけど、話の腰を折りそうだったので、書いてから削除した一節がある。


そもそも、過去に書いてたよなー、って思ったら、書いてなかった

じゃぁ改めて書くか。


というわけで、自分が書きたいから書くというだけの、どうでもいい話。




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 使いだ。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

ラリーウォールの誕生日(1954)【日記 13/09/27】

プログラム言語における「デフォルト動作」【日記 15/01/29】

別年同日の日記

05年 外構チラシ

09年 ジョウビタキ

10年 加湿器

16年 【追悼】マービン・ミンスキー

16年 AI囲碁


名前 内容

Landiskと格闘中  2015-01-31 13:23:25  コンピュータ

▲目次へ ⇒この記事のURL

八方ふさがりになってきたので、一旦ここまでの経緯をまとめておこう。


少し前に、使っていた 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 が復活するかもしれない。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】

ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】

デイビッド・パターソン 誕生日(1947)【日記 15/11/16】

Landisk のデータ復旧【日記 15/01/31】

別年同日の日記

03年 映画鑑賞

03年 アンティキュティラ

05年 ねずみの手も借りたい

10年 PS3

11年 見上げてごらん、夜の星を

13年 いろいろ書きたいなぁ

17年 【追悼】中村雅哉さん


名前 内容

Landisk のデータ復旧  2015-01-31 18:13:22  コンピュータ

▲目次へ ⇒この記事のURL

さっき書いた通り、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 上で同じようなソフトを作るという「車輪の再発明」はする必要ないでしょう。





次の目標:

これで、データパーテションが消えても問題なくなったので、工場出荷状態に戻して再起動できるか試したい。

でも、仕事もしなくてはならないので、いつになるかは不明。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】

ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】

デイビッド・パターソン 誕生日(1947)【日記 15/11/16】

Landisk のデータ復旧【日記 15/01/31】

別年同日の日記

03年 映画鑑賞

03年 アンティキュティラ

05年 ねずみの手も借りたい

10年 PS3

11年 見上げてごらん、夜の星を

13年 いろいろ書きたいなぁ

17年 【追悼】中村雅哉さん


名前 内容


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -