教訓1
M 社の製品は、最初に他人のコンピュータで導入してから
十分熟考の上で、自分のコンピュータに入れること。
教訓2
95 は(心底)使えない。
と、<常に>肝に銘じて使うこと。
ところで、再導入した 95 は、本当になーんにも、いらない物を入れないで、ぎりぎ
りの所で使って、いらないファイルとかも、ぜーんぶ消して、で、58メガだった。
たぶん、OS自体(更に my-favorit-in95 Notepad とかも消せば)55位になるのか
な。B-free って、どのくらいになる見込みなんです? 30メガくらいで押さえられ
るのかな。まあ、Disk Format の取り方とか何処までを B-free と見なすかとかにも
、よるのだろうけど。
# Linux は、核で 2〜3メガ?
# X を入れて、100 メガ?
In "[b-free 761] Re: 仮身名" with Hidekazu SHIOZAWA / 塩澤秀和,
(05:29:44 PM +0900 in October 12,1997)
- shiozawa wrote.
|塩澤です。
|
|From: h1suzuki@Bridgew.edu (Hideaki Suzuki)
|Subject: [b-free 759] Re: 仮身名
|Date: Thu, 09 Oct 97 16:40:43 -0500
|
|> |そういうことになってくると、むしろ、
|> |仮身名は短くてもよくて、実身名は長くなるのでは?
|>
|> 仮身名は別にして、長くなる実身名、どうして?
|
|実身名を「パス」に依存させて、その中で曖昧性を排除できれば、
|短くてもいいでしょうが、そうでなくて、リンクを張りかえても
|OKな、グローバルな識別子と考えれば長くなるということ。
|仮身名があるんだったら、そっちがパス依存ですよね。
??
もう少しだけ、具体的に言ってもらえます?
まだ、ピンとこない。
|> 2 大量にリンクを持つ実身がある一方、行き止まりも多い(気がする ^^;)。
|> 例えば、20のリンクの先の実身が、2つは20リンクをもち、4つは10リンク
、
|> 4つは5リンク、6っつは3リンク、4っつはリンク無しだとすれば、次の
|> turn での検索数は、2*20+4*10+4*5+6*3 = 118 になり、20*20 = 400 より
|> だいぶ少ない。
|
|1ホップで10倍というオーダーは変わってませんぜ。
うーむ。
じゃあ、3っつまで中継地点があいていても良いと仮定すると、
最初の中継地
↓ 10個のリンク
何かの実身
↓ 10個のリンク
何かの実身
↓ 10個のリンク
次の中継地
で、10*10*10 = 1000 この実身名とマッチか。結構多いの?
でも、自分のディスクシステム内だけの検索に限る上に、検索途中で行き止まりや検
索済みの部分を指すリンクは調べないでよいとするでしょう。でも、まだ多いかなあ
。
だれか、こんなソフトを 1B でつくって、実験してもらえないだろうか。
# 自分でやれよ。(>怒? ^^;;;)
実身名をいくつか入力するところがパネル上にあって、で、開始点を仮身で放り込ん
でやると、ある深さまで、最初に指定した実身名を探してくれて、その実身名がもし
見つかったら、次の実身名をまた発見点を開始点として探してゆく。もし、最後の実
身名を持つ実身に到達できれば、仮身としてリンクを返すという奴ね。
|> 3 近いリンクは、案外重複が多い。Webとちがって自分の所のファイルシステ
ム
|> を自分の力で検索できれば十分なので(後は他に任せる)、一度検索した
|> 実身を検索から除くことで、だいぶ、道の可能性が少なくなる。
|
|根本的に、その場その場で検索範囲が動的に変わる検索は、
|あらかじめテーブルを作っておくことができる検索に比べて
|ずっと遅くなります。検索に都合のいいデータ構造の
|テーブルを作っておけないから。
|
|たとえば、
|
|> 一度調べた実身は、もう、調べない。
|
|これをどう実現するのか?
|1検索単位ごとにどういう経路をとっているかを保持して
|いかなければならない。複数の検索が同時に行なわれても
|大丈夫にできていなければならない。
えっと、「一度調べた実身は調べない」とは一検索単位内についての意味でした。す
なわち、「無限ループに陥らないように」とか「もうすでにこの実身から到達できな
いと分かっている実身名に対して、検索を省略する」とかのためね。
実際には、一つの実身名の検索途中で、実身名列の実身名を一つでも発見できるかも
同時に調べ、発見できれば、検索途中で形成しつつある「発見路」に仮身を維持して
おく(その実身からの距離と同時に)。で、もし、失敗した発見路に(同じ実身名列
の検索過程の別の実身名の検索で)再突入した場合、目的の実身名が無いのなら(も
しくは遠いのなら)、その道は「不可」ということで、再突入を諦めると。
こんなんでどうです?
まあ、すこーしだけ、文章が入り組んでる?
# 説明に絵を使いたいぜ。
# TAD 通信は、LAN からは出来ないから、使用できない。とほほ。
|> 行き止まりの道が、ある程度あると、フラットにはなりませんよ。
|> これは、実身仮身ネットワークが「一方向リンク」な為に、何かって言うと、段階
的
|> になりやすい。「bi-linked を使わなかったのは賢いなあ」と時々思う。
|
|現実的な人間の感覚としては、そうかもしれないですけど、
|システム(コンピュータのプログラム)には、
|そういうことを判断するのは大変です。
|「だいたい階層的」というこの「だいたい」の判断が。
|どこまでリンクを先読みすればいいのか。
どう言うこと?
システムに判断させる必要って?
|だったら、原則ツリーにしちゃって、ネットワークにしたかったら、
|symbolic linkでごまかせばいいんじゃないのという...
|完全にネットワークを許すか、ツリーを原則として、
|例外的にネットワーク構造に出来るようにするかの違い。
やだ!
そんなの、絶対やだ!
だって、例外的なリンクとツリーのリンクとどう区別したらよいの?
< 使う側として。
|> まあ、完全にフラットの編み目なら、検索は速そうなんだけどねぇ。行き止まりが
あ
|> るから、再帰的な検索を強いられる(道を探す場合)。
|
|リンクを「たどる」ということをしようとするから、
|再帰的になるし、個々の検索方法がad hocになるんです。
|で、面倒になるんです。
うーむ。
でもね。実身名(と言うより実身)が、ネットワークの中でのみ価値のある存在だと
すると、そういうことが必要になってしまう。
逆に、ネットワークの前に実身自体が(個別の情報で)存在し得て、ネットワークと
はそれらをぶら下げる藤棚みたいな物だと考えると、長い名前も必要になるのが理解
できるし、検索もネットワークは一切考えないでよいので、早そう。
# 「get_nlk():リンクの順次取り出し」みたいな考えね。
# そういった情報なら、本当に、ファイルはリンクを持つ必要はない気がするけど
。
# <本>見たく、各章(実身)の後に "Reference & Advance Reading" とかって、
# リンク列をいっぱい並べておけば良い気もしないでもない。?_?
|> Web は、それぞれの階層化が大して無いのに、ルートのところがフラットな網目状
に
|> なっているので、そういう問題点が顕著になるのでしょう。だって、相手の HP の
先
|> 頭からリンクを貼るのが礼儀じゃん。
|
|有名な検索エンジンたと、Webの全文字データを
|ほとんど持っているような状態なわけです。
|日本の全Web pageを集めても、文字だけなら、
|おそらくギガ単位のハードディスクに収納できると
|いわれていました(去年)。まあ、100G単位なら
|個人で会社作ってなんとかなるレベルでしょう。
|こうなってくると、リンクをたどってどうこうする
|なんてことする人がいなくなるわけです。
うーん。基本的に Web Engine と比べるのはおかしい気もしますが。
だって、検索エンジンは Yellow Book からの検索に似ていると思います。Yellow Bo
ok から、名前を探し、同じ名前から住所を探し絞り込み、で、個人情報を得るような
物。
でも、実身仮身ネットワーク上の検索って、そういった Yellow Book 的な情報はない
でしょう?
いやでも、実身のファイル名テーブルみたいなのが、各ファイルシステムにあるか。
ようするに、そういうこと何じゃないかな。
ファイルシステムの実身登録テーブルみたいなので検索をするなら、実身名は長い方
がよいかも知れない。(まあ注釈レコードを多くの場合使えばよいと思うけど。)な
ぜなら、そういったテーブル上の検索は、ちょうど、Yellow Book や Web Search En
gine みたいな検索情報だから。
でも、いっぽうで、リンクをたぐって検索をしようと考えたときは、実身名は短くて
も良いと思う。例えば、君の居所を Yellow Book なしで突き止めるような物ね。名前
やらなにやら、まず、手がかりになる物から初めて、どんどん、足取りをたぐってゆ
く。で、最終的に君の住んでいた所にたどり着くと。
そう考えてみると、大変な事だなぁ。>足取りをたどること
でも、そういった検索機能はOSで援助してくれたら、すばらしいよなぁ。
と言うことで、B-free に期待しています。:)