WinFS、紆余曲折の末開発中止 143
ストーリー by yoosee
また甦る日もあるでしょうか… 部門より
また甦る日もあるでしょうか… 部門より
L.star曰く、"
PC Watchの元麻布春男の週刊PCホットライン
によると、
Microsoftは 6月23日に
WinFS の開発中止を表明した。WinFSはSQLデータベース技術をバックエンドに広範囲な検索機能を持った次世代のファイルシステムで、当初AeroGressやXAMLと並んで、Windows Vista向けの目玉機能の一つとされていた。
しかし WinFS は割と早くから開発の遅れが指摘されており、また機能としても「本当にそんな物が必要なのか」という声も大きかった。結局「当初のVistaには含まれないがアップデートとして提供される」
「XPに対してもリリースされる」などと路線変更されることとなった。さらには開発中にGoogle Desktopに代表されるような後付の検索機能が普及するなどの状況の変化もあり、そして今回、永遠に提供されることはなくなった。
何はともあれ、開発者の方々はお疲れ様でした。そして夢をありがとう。"
こちらの記事では (スコア:4, 参考になる)
http://www.itmedia.co.jp/news/articles/0606/28/news057.html
Re:こちらの記事では (スコア:1, 興味深い)
発展的な意味合いの分割ではない事には注意。
リンクが張れてないので張っておく
http://www.itmedia.co.jp/news/articles/0606/28/news057.html [itmedia.co.jp]
未完成コードを取り込まめ、無駄にはするなという無言の圧力がかかりそう。
そんなに完成度が高いわけないし、既存プロジェクトにはつらそう。
楽しい日本語「あたかもを使って文章を作りなさい」みたいなノリだな。
MSのやりがちな手段としては、皆が忘れた頃に略称はWinFSだけど
中身がまるで違うものにして黒歴史を上書き?
#こうしてWindowsFuckingSolutionに進化した…
Re:こちらの記事では (スコア:2, おもしろおかしい)
WinFSだって?
ああ、そういえばそんなものもあたかも。
NT4のときも、2000のときも、XPのときも、当初の発表とは
似ても似つかないものができあがったわけですが、
あまりこういうことをくり返すと、上場会社としての資質を
問われたりはしないのだろうか。
一次ソースを大事にしようよ…… (スコア:4, 参考になる)
見出しが事実とはちょっと違う? (スコア:4, すばらしい洞察)
これでは「WinFSの開発が中止」という表現は単純すぎて、事実と異なる誤解を招くことになりませんか?
Re:見出しが事実とはちょっと違う? (スコア:5, すばらしい洞察)
我々が思うWinFSは「SQLベースのWindows用新型ファイルシステム」であり、それ以外のものではないはずです。
今回の言い分は
「今までやってきたことはムダじゃありませんよ?ほら、そのうち他の製品へ使い回しが効くかもしれませんし」と、言うだけのことに過ぎないんじゃないかと。
#「Is XXX dead? Yes and No.……」って、典型的な逃げの言い訳のテンプレートだよなあ。と思った。
TREE構造のファイル管理は限界 (スコア:2, 興味深い)
さて、次世代のファイルシステムはどのようになるのだろうか?
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
PicasaやGmailにはフォルダで分類するという概念はなくて、写真やスレッドにいくつもラベルを付けるだけ。ラベルで済まない部分は、強力な検索アルゴリズムでかたづけるわけです。ネット上のリソースも、デスクトップ上のデータも、すべて同じことがあてはまります。
分類下手な自分は、Treeに分類するというのがそもそも人間の本質に合ってなくて、アイテムにキーワードをいくつか付けて、そのセットで目的のアイテムを探せばいいというアイデアは昔から持ってました。で、Googleが具現化しちゃったわけですが。
Re:TREE構造のファイル管理は限界 (スコア:3, 興味深い)
tree形式の方がまぁどうにかなっていい、と思っているのですが。
ラベルを作った所で、ラベルの付け方が大まかすぎたら同じラベルのファイルたちが溢れることになりますし、
逆に細かすぎたらラベルが溢れて、ラベルのツリー構造orラベルのラベルが必要になって
結果的にtree形式と変わらなくなります。
人からファイルをもらうときにラベルの付け方が違ったときも厄介です。
それに比べてtree形式なら、ごちゃごちゃはするけど、もらったディレクトリをそのまま入れちゃえるので楽です。
ラベルとtreeの併用については反対しませんが、現段階ではラベルはtreeに変わる程のものではないかと。
1を聞いて0を知れ!
Re:TREE構造のファイル管理は限界 (スコア:1)
検索の技術を応用できそうなものなのに。
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
何時まで経ってもTREE構造から脱皮できないのでは?(拡張子やタイプ/クリエータコード、MIMEタイプの限界)
この問題を解決した一例としては、Mac OS X TigerのUTI(Uniform Type Identifiers)がある。
(Appleは、この識別機構を導入することで、仮想フォルダやメタ検索を実現している)
http://ars2.sjc.cachefly.net/images/tiger/utitree.png(UTIの階層構造)
・ユニークさ:全く新しいデータ分類機構であるUTIは、過去の過ちに拘束される
ことはない。個別のUTIはユニークであるように定義され、そのユニークさが
持続的に維持されるよう保障するシステムも備えている。
・表現力と可読性の高さ:UTIには文字列長の制限はなく、人間が読むことを想定
した平文記述も付随している(この記述は多言語ローカライズも可能である)。
・拡張性の高さ:UTIでは、管理団体(この場合はApple)の承認作業を受けると
受けないとに関わらず、新たなタイプを容易かつ安全に追加できる、十全に定義された
体系をサポートしている。
・分類上の正確さ:何らかのデータタイプ(たとえば「全ての画像」)を選択すれば、
ベンダ依存のUTIや臨時のUTIなども漏らさずに、そのデータタイプに属する対象
すべてをちゃんと捕捉できる。
・public.dataは、UTI木構造の最上位とか、唯一のルート階層とかでは全くなく、
他のUTIを継承しないUTIは、事実上すべてルートだとみなすことができる。
・個別のUTIの表現上の階層構造を、さまざまなUTI同士の実態的な階層構造から切り離している。
・UTIは複数の親UTIを多重継承することもできる。
・各UTIは他のUTIを「継承」あるいは「従属」できる。
Winでも、こういったシステムの「底辺部分」から、抜本的な改革が必要とされていて、
上辺だけ弄ったところで解決しない問題なのではないだろうか。
参照記事
http://arstechnica.com/reviews/os/macosx-10.4.ars/11
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
確かにTREE構造では対応しきれない物は多いけれど, かと言ってTREE構造に変わる汎用的な構造が無いってのが一番の問題でしょう.
例えば汎用性だけを取ってみれば, 最近のリレーショナルデータベースの様にフラットな表形式でのメタデータ管理ってのも有りだと思います. しかしユーザとしてはこれにどのような形でどんなメタデータを格納しなければならないか設計する必要が出てくるわけで, これが利用する上での大きな障害になることは明らかです. 要はエンドユーザにデータベースを設計させようってことですから.
となると, 最大公約数的には古来コンピュータとか関係なしに情報分類の構造として使われてきたTREE構造のみをエンドユーザ向けの標準的なファイルシステムとして提供する, って判断は, 間違っていないとは言えないまでも, 十分に納得はできるんですよね.
Re:TREE構造のファイル管理は限界 (スコア:1, おもしろおかしい)
#あまりにもネタなのでAC
Re:TREE構造のファイル管理は限界 (スコア:1)
Re:TREE構造のファイル管理は限界 (スコア:1)
エクスプローラと、そのフォルダツリーによる情報管理はマジ限界です。
仕事のドキュメントとかナレッジとか、○○案件の設計資料としてカテゴライズしたい、でもWindowsServer2003の技術資料としてもカテゴライズしたい!
という要求に応えてくれるのがWinFS(メタタグ+仮想フォルダ)だと思っていたのですが…。
う~む残念。
他の人はこういうときどうしてるんだろう。マジでハードリンク?
で、結局LotusNotesを相変わらず使い続けている私。
だってカテゴリを複数付けられるんだもん。
-- sun burst.
Re:TREE構造のファイル管理は限界 (スコア:1)
ディレクトリをスクリプトか何かでプログラム可能、実行可能な形式にして、
ディレクトリへのアクセス=ディレクトリの実行とするとどうなるのかなぁ、と。
Windows系の話題としては例が不適切だったりしますが、例えば、
1. LinuxなどでのRPM管理のとき、
/usr/share/rpm という実行可能ディレクトリを作っておいて、
アクセス時に動的に
/usr/share/rpm/installed
/usr/share/rpm/available
などのディレクトリを作り出す。
それらのディレクトリも実行可能ディレクトリとなっていて、
アクセス時に生成したり、ネットからダウンロードしたりできる。
2. id3やらのタグつき音楽ファイルがごちゃごちゃに入っている実行可能ディレクトリ music について、
music にアクセスするとタグデータをもとにartists ディレクトリなどが動的にできていて、
(タグつきとはいえ)ごちゃごちゃに入れているだけで、どんなソフトからでも整理されたディレクトリとして利用できる。
3. ~/dirscript/find という実行可能ディレクトリを作っておいて、
ls ~/dirscript/find/*.jpg で、ホームディレクトリやサブフォルダ内の*.jpgを全て表示
こんな感じです。
1を聞いて0を知れ!
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
ディレクトリに「見せる」という点ではCGIはそのアイデアを一般的に使っています。もっともそれはHTTPで見えるだけであってローカルでマウントできるわけではないですけど。
Re:TREE構造のファイル管理は限界 (スコア:1)
Re:TREE構造のファイル管理は限界 (スコア:1)
早速 iTunes と組み合わせて実装してみようかと思ったけど、 OSX には FUSE が無いですね……
理由をよーヌケヌケと (スコア:2, おもしろおかしい)
「こういう理由もあったのかもしれない、」なら分かる。
けど「こういう状況もあり、中止となった」と言いきるのってどこをどう空目すりゃできるんだ?
記事の元ネタが元麻布春男の週刊PCホットラインなら
わざわざ「Google Desktopに代表されるような後付の検索機能」
との違いまでしっかり説明しているわけだが。
#はいはい荒しモデ荒しモデ
思い出した (スコア:2, おもしろおかしい)
あーそうか、
Coplandのリリースができなくて辞任したアメリオ氏のように、
WinFSがリリースできないからゲイツ氏は引退するのか(違
SQL Server (スコア:2, すばらしい洞察)
油断してはならない! (スコア:1, おもしろおかしい)
#誰か銀の弾丸と十字架持って来い!
Re:まぁあたらずもはずれない (スコア:1, おもしろおかしい)
具体的にどんな物だったのか分からずじまい (スコア:1)
た、俺。おぼろげながらのイメージとしては、メタデータストアとファイルシステムがうまい具合に統合されてるって言う感じでしょうか?
今でもコンテンツ本体のファイル以外に NTFS のサブストリームにメタデータを格納している場合もあるわけですが、それの代わりなのかなぁ、くらいに考えてました。
屍体メモ [windy.cx]
Re:具体的にどんな物だったのか分からずじまい (スコア:1)
それらの関連性の情報などがDB化され、自由に呼び出せると。
けど、多分違うんだろうな。
まぁ今となってはどうでもいい話になってしまうけど。
Re:具体的にどんな物だったのか分からずじまい (スコア:1)
Re:具体的にどんな物だったのか分からずじまい (スコア:2, 興味深い)
OSに密着したデータベースAPIを作ってしまうとUIとアルゴリズムの組合せだけで全く同等機能なアプリが出来てしまう。
キモの部分を明け渡したら自社製品群(Office)の売上げにも悪影響が出る。
ネットの向う側のデータの取り扱いに妥当な融合を見出せなかった。向う側だけインデックスで持つ?
ってDataデカ過ぎるじゃん!!更新のタイミングは!?と気が付いた
かな
Re:具体的にどんな物だったのか分からずじまい (スコア:2, すばらしい洞察)
それなんてハードリンク?
Re:具体的にどんな物だったのか分からずじまい (スコア:2, 興味深い)
例えば、「ハワイ旅行に行ったときの思い出」というフォルダに、デジカメ画像データ(実体)
へのリンクや、日記テキスト(実体)へのリンクを作っておくとします。これはこれで
役に立つでしょうが、例えばこういう場合はどうしましょう。
「ああ、テキストいらない。画像だけでいい」
こういう使い方は、そのときただ一度きりかもしれません。そのためにハードリンクの入れ物の
フォルダを作るのも大変ですよね。さらに、
「そういえば今年だけじゃなくて去年もハワイ旅行いったな。このフォルダでは両方とも
見えているけど、今年の旅行の情報だけでいいや」
こんなこともやりたくなるかもしれません。
あんまり状況をウォッチしていませんでしたが、私が理解するところのWinFSでは、(誤解して
いなければ)こういうこと「も」できたはずです。(詳しい人、間違っていたら突っ込んで下さい)
UNIX系OSで、`find ./ -name "*.jpg" -print` とかズラズラ並べ、条件に合致するファイルを
一気にある作業にかける、なんてやっていましたが、同じことをWindowsでもやりたいんです…。
# アプリケーションで似たようなことやっている例はありますが、OS/ファイルシステムレベル
# でやってくれないと色々と不都合もあるわけで。
Re:具体的にどんな物だったのか分からずじまい (スコア:2, 参考になる)
#最近知ったのですが、ターミナルからもmdlsやらmdfind等のコマンドを使ってメタデータを使えるんですね。僕は、根っからのマックユーザなので使わないのですが、UNIXでシェルスクリプトを使う人には面白い機能かもしれませんね。
Re:具体的にどんな物だったのか分からずじまい (スコア:4, おもしろおかしい)
…chkdskするとディスクのエラーとして検出されちゃうだけで…。
Re:具体的にどんな物だったのか分からずじまい (スコア:3, 参考になる)
> それを作るコマンドが用意されてないだけで。
ディレクトリ単位なら、linkdコマンドがありますね。
Windows2000のリソースキットには確か入っていますが、手持ちのXPにも入っているようです。
Active DirectoryのSYSVOL共有で使われていますね。
ファイル単位ですと、XP以降のfsutilコマンドで可能になっているようです。
詳しくはこちら [atmarkit.co.jp]をどうぞ。
Re:具体的にどんな物だったのか分からずじまい (スコア:1, すばらしい洞察)
Re:具体的にどんな物だったのか分からずじまい (スコア:2, 参考になる)
うちはショートカットで間に合ってるんで使ってないんですが。
# SlashDot Light [takeash.net] やってます。
Re:具体的にどんな物だったのか分からずじまい (スコア:1)
とやったら実際にDドライブのルートにシンボリックリンクが張れたので、
どうやってるのか気になってエクスプローラでhomeを開いてみたところ、
Dドライブへのショートカットが作られてて妙に感心しました。
Re:具体的にどんな物だったのか分からずじまい (スコア:4, 参考になる)
ADO.NETは.NET Frameworkベースのデータベースアクセスライブラリですね。
.NET系のアプリではSQL Server、OracleといったDBへのアクセスにADO.NETを使用するのが一般的です。
.NET Framework 3.0(=WinFX)で通常のファイルをDBのようにトランザクション操作実装する機能がつくらしい、と記憶しているのですが、この辺の処理がWinFSの一部であれば、ADO.NETに実装されるのが順当でしょう。
WinFSのデータベースストアをSQL Serverに、WinFSのアクセスライブラリをADO.NETに分離して継承する、と考えれば自然そうです。
おいおい・・・ (スコア:1, 荒らし)
・タコの入っていないタコ焼き
・麺が入っていないラーメン
・バグが入ってないWindows
期待はずれじゃん。
ところで、WinFSって何?NTFSの後継ファイルシステム?Spotlightみたいな、高速検索の機構?それくらいもわかってないな。ほかにもそんな人いるみたい・・・だから・・・つぶれたのか。
-- gonta --
"May Macintosh be with you"
Re:おいおい・・・ (スコア:1)
それは「絵に描いた餅」といって(ry
#結局「Shorthorn」 [srad.jp]というものをリリースしてアルチン氏 [cnet.com]はMSを去るのか
ちがうよ (スコア:1)
Spotlightぽいのは、ちゃんとVistaに搭載される。
クイック検索メニューって名前なのかな? [microsoft.com]
もしくは、「動画で動作が確認できるディストロ紹介サイト [srad.jp]」で紹介されているサイトで、Vistaベータ2のデモを見ると、動いている様子も見れる。
でもどうせ、8月のWWDC [srad.jp]で、束っぽいもの [srad.jp]が登場したら、しれっと復活しちゃうんじゃないか? VistaFSとかそんな名前で。
Re:ちがうよ (スコア:2, すばらしい洞察)
そういう時は大抵、WinFSはSpotlightのように付け焼刃なものではなく、より高度な思想を持っている。只単に検索だけのものではない。というような言われ方が多かったように思う。
Spotlightは、システムワイドな検索環境やプラグインなどによる拡張性が特徴で、拡張子の新しい判別構造に至るまで改良を施したが為に実現出来た。そういった「付け焼刃ではない」側面をもっていたお陰で、副産物である仮想フォルダも実現した。
そこで、WinFS無きVistaの検索機能がある。Vistaのメタ検索機能はシステムワイドで柔軟な構造になっているのか?(これは詳細を純粋に知りたい部分)従来は仮想フォルダと言っていたはずの現検索フォルダ(検索結果を一纏めにしておく機能、仮想との違いはリアルタイム性の有無?)
これらを考えると、思想は高度で、当初の理想を実現出来たのなら素晴らしかったが、現状は「似たような」機能でお茶を濁す場面が結構出て来ているように思える。多くの人の認識では、Vistaは将来に向けた基盤の提供という面での、革新的な印象を持たれていたのだと思うが。
まあ、実際に同じ事が出来るのなら何ら問題は無いのも事実だけど、遅れても良いから、後々VistaにWinFSとして統合するような方向性でいて欲しかったかも。
Re:これって (スコア:1, おもしろおかしい)
たまにで良いので、Beagleのことを思い出してあげてください。
Re:これって (スコア:2, 参考になる)
APIになっていて、裏でCore Dataとかそういう枠組みを提供している点でしょうか。つまり単なる検索にとどまらず、MVCのモデルレイヤ全体のサポートでもあります。
アプリケーションを作るときにデータ構造とか考えるけど、そのときにCore Dataってのを使うと設計から管理、セーブ・ロード、やり直し(undo)の面倒を見てくれて、検索までサポートしてしまう、ということかと思っています。
mkinoさんのページより [mac.com]
TigerのCocoaにみるMVCの完成 - スマートなデータモデルを実現するCore Data [mycom.co.jp]
Re:これって… (スコア:2, 参考になる)
直接DBにSQLで問い合わせる事も出来ますが、全文検索用のインデックスを持っているわけではないので、GoogleDesktopのような検索はできません。Windowsのファイル内文字列検索機能よりも効率は悪くなっています。
Re:結局、中止理由はなに? (スコア:4, すばらしい洞察)
Re:結局、中止理由はなに? (スコア:3, 興味深い)
本来、カーネル中にデータベースのようにリソースを大量消費する機能を実装するというのはカーネルの安定性や性能を損なう事になりますし、いずれにせよ UI として専用のツールまたはシェル(エクスプローラ)の拡張が必要になります。
また、Google Desktop Search や Beagle [beagle-project.org] のようなツールが証明するように、ファイルを効率良く管理するだけで良ければ一般ツールで十分です。
# ReiserFS4 [namesys.com] ってリリースされてたんだな。
Re:Windowsオワタ (スコア:3, 興味深い)
アーティスト
├アルバム
└アルバム
├曲
└曲
というツリーにしたときコンピレーションをどうするかシングルをどうするか、と思い悩むのがいかに時間の浪費か、ということに気付いてしまうと、OSとしての進化が滞ったと思ってしまうわけですね。
-- sun burst.
Re:Windowsオワタ (スコア:3, 興味深い)
「タラオは人間だ」
ということは表わせても
「タラオはサザエの子供だ」
ということは表せない。
#一方RDFは2引数の述語が書ける。
WinFSはリレーショナルデーターベースを元にしているので、おそらく任意の数の引数を取る述語が書けますし、豊富なデータ型を使うこともできるのでしょう。
だからタグが悪いというわけではなくて、表現力が強すぎても扱いきれないし、タグによる分類はその辺のバランスを上手くとっていると言えます。
でも個人的にはどうもその辺の表現力の弱さが不安でいまいちタグによる分類を手放しで受け入れられないんですよね。
かといってハイパーテキスト系は(少なくとも既存のものは)コンテンツとメタデータがごっちゃにしすぎている感があるし。
#それが利点でもあるのだけど。
Re:Windowsオワタ (スコア:3, 興味深い)
あと、ブロートウェアと80/20の神話 [joelonsoftware.com]を思い出しましょう。
普段全く使わなくても、あるときとても必要となる機能が使えないものは市場から受け入れられません。
そして、上記に述べたとおり、大抵の場合市場は取捨選択ができない人たちであふれているのです。
Re:Windowsオワタ (スコア:2, 参考になる)
また、Longhorn Server では、GUI Less のインストールも可能になるなど、Microsoft としてもそういった需要はとっくに気付いているんでは?
(今から実装し始めたのでは間に合わないでしょうし、ずいぶん前から開発を始めていたんじゃないかと思いますけど)