【企業】アップル、Jaguar、Pantherの次はv10.4 “Tiger.”【05/06】
124 ：寅さん、おそらく牛にも載る新機能のやさしい説明：
【828】
【氏名】 名称未設定
【日付】 04/05/07 03:49 ID:Uu6GBwQ2
【宛先】
>>821-824
ちょっとまて、メタデータ統合データベース・ファイルシステムって
最初に完全実装したのはBeOSのBFSだぞ。あれ開発してBFSの本も書いた
ドミニク・ジャンパオロはBeの前はAppleにいて、Sybilっつうプロジェクトの
中でプレBFS的な実装をやってた（プロジェクトは死亡）。彼は今Appleに
戻って、まさにHFS+にメタデータ統合する仕事をしてる。
その分野のオリジネイターであるエンジニアが元の出身企業に戻って、その
会社で揺籃期を経たコンセプトを実装してるわけで、これを「windowsの
パクリ」って言われちゃかなわんぞい。
あとドミニクは現状で公開されてるLonghornのDB統合の仕様を筋悪だって
言ってた。今のままの仕様だと、特にDBの整合性コレクション処理のときに
とんでもないことになる可能性があるって。実際LonghornのDBFSは
その後「やっぱ計画縮小、最初はデスクトップだけにしときますわ」って
ことになったね。開発工数の問題だって説明されてたけど、どうなのかな。
【氏名】 名称未設定
【日付】 04/05/07 03:49 ID:Uu6GBwQ2
【宛先】
>>821-824
ちょっとまて、メタデータ統合データベース・ファイルシステムって
最初に完全実装したのはBeOSのBFSだぞ。あれ開発してBFSの本も書いた
ドミニク・ジャンパオロはBeの前はAppleにいて、Sybilっつうプロジェクトの
中でプレBFS的な実装をやってた（プロジェクトは死亡）。彼は今Appleに
戻って、まさにHFS+にメタデータ統合する仕事をしてる。
その分野のオリジネイターであるエンジニアが元の出身企業に戻って、その
会社で揺籃期を経たコンセプトを実装してるわけで、これを「windowsの
パクリ」って言われちゃかなわんぞい。
あとドミニクは現状で公開されてるLonghornのDB統合の仕様を筋悪だって
言ってた。今のままの仕様だと、特にDBの整合性コレクション処理のときに
とんでもないことになる可能性があるって。実際LonghornのDBFSは
その後「やっぱ計画縮小、最初はデスクトップだけにしときますわ」って
ことになったね。開発工数の問題だって説明されてたけど、どうなのかな。
|
|
|
125 ：寅さん、おそらく牛にも載る新機能のやさしい説明：04/05/07 15:51 ID:Lnjr19pv
【829】
【氏名】 つづき
【日付】 04/05/07 04:16 ID:Uu6GBwQ2
【宛先】
この分野の実装上の可能性や問題点に関してはDominic一人がほぼ
探究し尽くしてしまったところがあるんだよね。彼は特にパフォーマンス
チューニングとエラーコレクションを重要視する人だったので、実用上
トラブル要因になりそうな要素はBFSの段階でほぼ潰してあった。あの
時代にジャーナリングとかも普通にやってたしね。ファイルシステム
研究の人たちにとっては、汲めども尽きぬ豊かなリソースだと思う。
悪訳で有名だが、一応本人が書いたFS本は邦訳が出てる。いわゆるドミニク本。
BeOS:ファイルシステム―実践ファイルシステム構築
http://www.amazon.co.jp/exec/obidos/ASIN/4274078876/
タダで読みたきゃ英語版pdfがDominicのサイトにあるよ。
http://www.nobius.org/〜dbg/
【氏名】 つづき
【日付】 04/05/07 04:16 ID:Uu6GBwQ2
【宛先】
この分野の実装上の可能性や問題点に関してはDominic一人がほぼ
探究し尽くしてしまったところがあるんだよね。彼は特にパフォーマンス
チューニングとエラーコレクションを重要視する人だったので、実用上
トラブル要因になりそうな要素はBFSの段階でほぼ潰してあった。あの
時代にジャーナリングとかも普通にやってたしね。ファイルシステム
研究の人たちにとっては、汲めども尽きぬ豊かなリソースだと思う。
悪訳で有名だが、一応本人が書いたFS本は邦訳が出てる。いわゆるドミニク本。
BeOS:ファイルシステム―実践ファイルシステム構築
http://www.amazon.co.jp/exec/obidos/ASIN/4274078876/
タダで読みたきゃ英語版pdfがDominicのサイトにあるよ。
http://www.nobius.org/〜dbg/
126 ：寅さん、おそらく牛にも載る新機能のやさしい説明 ：04/05/07 16:00 ID:Lnjr19pv
【831】
【氏名】 名称未設定
【日付】 04/05/07 09:33 ID:Uu6GBwQ2
【宛先】
対抗意識っつうのはどっちもどっちだからねぇ。MSもAquaにLuna
ぶつけたり、Longhornデモでウィンドウひらひらさせたりやっとった。
漏れは、コモディティOSの世界では良い工夫はどんどんパクり合って
標準化するべきだと思ってるのだけど、UIの見てくれの模倣には
あまし生産性がない。もっと本質的なところをパクり合えばいいのに。
DB統合FSは、どちらがオリジナルだろうと、どちらがパクろうと、
コンピューティングの世界をより良いものにしてくれるはずだから、
単純にうれしい。BFSが垣間見せてくれた世界は、世のヲタどもを
完全にノックアウトしたからなぁ。BeOS自体は死んでるのに、BFSは
OpenBFSに受け継がれたり、SkyOSの標準ファイルシステムに採用
されたりして、未だに進化を続けてるし。
【氏名】 名称未設定
【日付】 04/05/07 09:33 ID:Uu6GBwQ2
【宛先】
対抗意識っつうのはどっちもどっちだからねぇ。MSもAquaにLuna
ぶつけたり、Longhornデモでウィンドウひらひらさせたりやっとった。
漏れは、コモディティOSの世界では良い工夫はどんどんパクり合って
標準化するべきだと思ってるのだけど、UIの見てくれの模倣には
あまし生産性がない。もっと本質的なところをパクり合えばいいのに。
DB統合FSは、どちらがオリジナルだろうと、どちらがパクろうと、
コンピューティングの世界をより良いものにしてくれるはずだから、
単純にうれしい。BFSが垣間見せてくれた世界は、世のヲタどもを
完全にノックアウトしたからなぁ。BeOS自体は死んでるのに、BFSは
OpenBFSに受け継がれたり、SkyOSの標準ファイルシステムに採用
されたりして、未だに進化を続けてるし。
127 ：寅さん、おそらく牛にも載る新機能のやさしい説明：04/05/07 16:06 ID:qd54XKS4
【834】
【氏名】 名称未設定
【日付】 04/05/07 10:53 ID:Uu6GBwQ2
【宛先】
>>833
ようするにファイルにクリエータやファイルタイプやラベルみたいな属性を
無限につけられるわけだね。んでファイルシステム自体がその属性見つつ
DB的に動作するので、やろうと思えば「ディレクトリベースの管理」とい
う旧世代のファイルマネジメントのパラダイムを完全に脱却できる。
今まではデータって自分で整理してたでしょ。たとえば「進捗状況報告書」
というwordファイルは文書フォルダ→仕事フォルダ→進行中のプロジェクト
フォルダ→○○プロジェクトフォルダ、というところに自分で保存しといて、
後で「あれどこやったっけ」という時はディレクトリをたどりながら
探すわけだ。でもこれだと、全プロジェクトの進捗状況報告書をまとめて
一望はできないよね（これ、階層型ディレクトリの根本的問題）。あるいは
仕事と趣味の両方で進行中のプロジェクトに関わってるwordファイルを
全部開く、とかも難しい。どうしてもってことになると、結局sherlockか
他の検索ユーティリティを使っていちいち探すことになる。遅いし面倒。
んだったら、ファイルに対してインデックスつけちゃえばいいじゃん、
てのがDB統合FSの基本思想。ファイル自体に「仕事」「進行中」「○○
プロジェクト」「word文書」…って属性をどんどん足していけば、
それぞれの属性を検索クエリーに使えばいつでも当該文書が出てくる。
当然、複数の属性を使ってクロス検索したり、検索クエリーを保存して
itunesのスマートプレイリスト的に使うこともできる。こうなると
「ファイルを手動で分類・秩序化する」という操作にはほとんど意味が
なくなる。ファイル自体に「分類されるのに充分な属性の数々」を
あらかじめ持たせておいて、実際の抽出はコンピュータがやればいい。
ファイルは単階層のディレクトリにまとめて放り込んじゃえばOK。
【氏名】 名称未設定
【日付】 04/05/07 10:53 ID:Uu6GBwQ2
【宛先】
>>833
ようするにファイルにクリエータやファイルタイプやラベルみたいな属性を
無限につけられるわけだね。んでファイルシステム自体がその属性見つつ
DB的に動作するので、やろうと思えば「ディレクトリベースの管理」とい
う旧世代のファイルマネジメントのパラダイムを完全に脱却できる。
今まではデータって自分で整理してたでしょ。たとえば「進捗状況報告書」
というwordファイルは文書フォルダ→仕事フォルダ→進行中のプロジェクト
フォルダ→○○プロジェクトフォルダ、というところに自分で保存しといて、
後で「あれどこやったっけ」という時はディレクトリをたどりながら
探すわけだ。でもこれだと、全プロジェクトの進捗状況報告書をまとめて
一望はできないよね（これ、階層型ディレクトリの根本的問題）。あるいは
仕事と趣味の両方で進行中のプロジェクトに関わってるwordファイルを
全部開く、とかも難しい。どうしてもってことになると、結局sherlockか
他の検索ユーティリティを使っていちいち探すことになる。遅いし面倒。
んだったら、ファイルに対してインデックスつけちゃえばいいじゃん、
てのがDB統合FSの基本思想。ファイル自体に「仕事」「進行中」「○○
プロジェクト」「word文書」…って属性をどんどん足していけば、
それぞれの属性を検索クエリーに使えばいつでも当該文書が出てくる。
当然、複数の属性を使ってクロス検索したり、検索クエリーを保存して
itunesのスマートプレイリスト的に使うこともできる。こうなると
「ファイルを手動で分類・秩序化する」という操作にはほとんど意味が
なくなる。ファイル自体に「分類されるのに充分な属性の数々」を
あらかじめ持たせておいて、実際の抽出はコンピュータがやればいい。
ファイルは単階層のディレクトリにまとめて放り込んじゃえばOK。
128 ：寅さん、おそらく牛にも載る新機能のやさしい説明 ：04/05/07 16:07 ID:qd54XKS4
【835】
【氏名】 名称未設定
【日付】 04/05/07 10:54 ID:Uu6GBwQ2
【宛先】 sage
人間のやってた繁雑な仕事をコンピュータにやらせて（エージェント化）
人間が楽する、というのはコンピューティングの基本なのにも関わらず、
ファイル管理に関しては何でか人間がフロッピー時代の管理パラダイムに
合わせてファイルを自主管理「させられてた」。でも、個人でハンドリング
するファイルが100件500件程度ならいいけど、それを超えちゃうと
記憶と分類っていう人間の能力に依存してファイルを管理するのはもう
無理なんだよね。だからいずれはDB統合はやらなきゃいけなかった、と
みんな思ってはいた。アイディアとしても、別にBFSが最初だったわけ
じゃない。ただジャーナリングとかの周辺技術を作り込んで、極めて
実用的な実装に仕上げたのがドミニクのBFS。だから結構尊敬されてるし、
今も採用されてたりする。
Macにこのパラダイムを持ってくる前哨戦はiTunesだったんだよね。
あれって実際のmp3ファイルがどこにあって、どう整理されてるかを全然
気にしないでもフツーに使えるし、目的のファイルを自由自在に操作
できるし、スマートプレイリストみたいな動的抽出検索もできるでしょ。
あれはID3タグを使ってやってるわけだけど、ああいう感じのことを
全アプリでできるようにする、というのが、DBベースFSの、とりあえずの
出発点。
【氏名】 名称未設定
【日付】 04/05/07 10:54 ID:Uu6GBwQ2
【宛先】 sage
人間のやってた繁雑な仕事をコンピュータにやらせて（エージェント化）
人間が楽する、というのはコンピューティングの基本なのにも関わらず、
ファイル管理に関しては何でか人間がフロッピー時代の管理パラダイムに
合わせてファイルを自主管理「させられてた」。でも、個人でハンドリング
するファイルが100件500件程度ならいいけど、それを超えちゃうと
記憶と分類っていう人間の能力に依存してファイルを管理するのはもう
無理なんだよね。だからいずれはDB統合はやらなきゃいけなかった、と
みんな思ってはいた。アイディアとしても、別にBFSが最初だったわけ
じゃない。ただジャーナリングとかの周辺技術を作り込んで、極めて
実用的な実装に仕上げたのがドミニクのBFS。だから結構尊敬されてるし、
今も採用されてたりする。
Macにこのパラダイムを持ってくる前哨戦はiTunesだったんだよね。
あれって実際のmp3ファイルがどこにあって、どう整理されてるかを全然
気にしないでもフツーに使えるし、目的のファイルを自由自在に操作
できるし、スマートプレイリストみたいな動的抽出検索もできるでしょ。
あれはID3タグを使ってやってるわけだけど、ああいう感じのことを
全アプリでできるようにする、というのが、DBベースFSの、とりあえずの
出発点。