UNIX(Mac,Windows,Linux)に対するアンチテーゼBTRON
超漢字Vスラッシュドット ジャパン | 超漢字V、10月27日発売http://slashdot.jp/article.pl?sid=06/09/20/1329204Re:実身・仮身システム (スコア:4, 興味深い)TRON (6936) のコメント: 2006年09月21日 0時33分 (#1022961)( 最新の日記: 2007年06月10日 15時42分 )> もしあの時点でスーパー301条で指名されてなくて、TRONが日本の教育市場に入り込んだとしても、どのみちDOS/V(とWindows)の黒船は迫ってきていたわけだし、ただ単に日本のパーソナルコンピューティングがTRONが普及している間だけ、まるごと遅れてただけだと思うんだよね。BTRON搭載コンピュータが普及した場合、実身仮身データ群を他のOSに持っていくのは厳しいので、それが他の系統のコンピュータの国内販売の障壁になるかと。> に世界の情勢から孤立してしまっていた可能性もあるわけで、俺としてはむしろその方がよかったんじゃないかって思うよ。これもあると言えば、あるのだけれど、逆に他の産業である様に、BTRON仕様のコンピュータが世界を席巻してた可能性ってのもありますよね。BTRONはなかなか良いコンピュータだと思うので、ある程度普及して、人的リソースやお金がつぎ込まれて、進化したBTRON仕様のOSってのは見てみたかったなと思います。今、売られているBTRON仕様のOSは進化に必要な人的リソースや資源がつぎ込まれ(つぎ込め)ないので、ファイル数の件も含めて、使い勝手が悪いとか、色々、欠点や欠陥が目立ちますからね。健ちゃんの言動 (スコア:5, 参考になる)TRON (6936) のコメント: 2006年09月21日 1時34分 (#1022995)( 最新の日記: 2007年06月10日 15時42分 )坂村健という人は今のところ、今はBTRONに注力していないので、BTRONは拡張する必要はないと言っていますが、仮に拡張ができる様な状態になると、一転して、ファイルがこれぐらい扱えるのはコンピュータとして、当然だと言い始めます。ユビキタスコンピューティングを実現するという大目標事態は変えないものの、細かい部分については、その時、進めているものや、手を組んでいる人たちに応じて、ガンガン言動を変えるので、細かい部分を気にしてはいけません。長年見てるとこの傾向があるのがわかります。ある時はマイクロソフトをたたき、今はT-Engine関連で手を組んでいるので叩きません。ユビキタスコンピューティングさえ実現できれば、わりと細かい部分はどうでも良いと思っている人の様なので、真面目な人には毛嫌いされるかなと思います。笑いが取れれば良く、空気に合わせて意見を変えるお笑い芸人と同タイプの人です。Re:実身・仮身システム (スコア:3, 参考になる)Anonymous Coward のコメント: 2006年09月21日 13時21分 (#1023262)> というか、NTTが持っていたものベースにCTRON仕様が作られたという噂もある。#違ってたらごめん。当時、一部ファミリー企業に作らせていたDIPS (Dendenkosha Information Processing System) コンピュータの閉鎖性を批判されていた電電公社は、仕様を公開した後継OS (POPSと呼ばれた)というかその仕様を急ぎ作る必要に迫られていました。この仕様を策定するにあたり時間と手間の節約と公開性の大義名分のゲットのためにTRON計画に目をつけた電電公社とTRONの名を売りたい健ちゃんの利害が一致した結果IBMがICBMに化けたわけです。なのでCTRON仕様はITRON仕様をベースに電電公社の都合にあわせたアレンジ、拡張したものになっています。健ちゃんのアイデアで作られたものというわけでもないので、TRONの功績といっても間接的なものですね。Re:フレームの元になりやすい「実身/化身」 (スコア:3, 参考になる)Raquel (27652) のコメント: 2006年09月21日 0時24分 (#1022951)実身/化身の考え方はユニークで優れている点も多いと思います。変わったアイディアに触れないと、ほとんどの人はパスでファイルの場所を指定するのが当たり前だと思い込むので、こういった概念があるのは意外と重要でしょう。すこしコンピュータに興味のある人が手を出せるところにUNIXやWindowsで当たり前の概念と異なるものががあれば目からうろこが落ちる人もいるでしょう。したがって実用的というよりは、アンチテーゼとしてあることが重要だと思っています。ファイルをパスで管理する方法は問題が山積みです。ファイル名を変えたり移動するとショートカットなどが切れるとか、開いているファイルの移動ができないとか。MacでもファイルをIDで管理する方式がありました。旧Mac OSではほぼファイルの管理はFSSpecとかFSRef、永続的な追跡が必要な場合はAliasRecordというものを使っていました。メリットを書くと長くなりますが、なかなか優れていたと思います。Mac OS XではUNIX的な発想が入ってきたのでパスもずいぶん使われますが、FSRefなどは残っています。65000ファイルの制約を打開する方法 (スコア:3, 興味深い)espy (3615) espyNO@SPAMinter7.jp のコメント: 2006年09月21日 4時49分 (#1023038)( http://slashdot.jp/~espy/journal/ | 最新の日記: 2007年07月06日 21時10分 )IDによる方式がパスでファイルを識別する方式より利点を出せるとして、そのIDのビット長を増やそうとしないのはなぜなんでしょうね。先生の発言 [atmarkit.co.jp]によると、128ビット(たかだか16byte)有れば「毎日1兆個のモノや場所にucodeを付与することを1兆年続けても足りなくなることはない」という事なのに。# ucodeのようなアイデアもある一方で、BTRONを直さないのは、単に坂村先生が忙しくて# 仕様のテコ入れにパワーを割いていないか、先生以外の人で改善した提案を強く主張する人が# いないだけなんだろうな…と推測。実身数が65536なんですが (スコア:5, 参考になる)soara (137) soaraNO@SPAMmsd.biglobe.ne.jp のコメント: 2006年09月21日 0時25分 (#1022952)( 最新の日記: 2007年06月26日 19時52分 )足りるか足りないかはどれだけ使いこなすかにかかっています。 1パーティション内に65536個の実身ができますので、複数のパーティション、もしくは USBデバイス等につっこめば、なんとかならないでもありません(そのためリンク切れの可能性はあります)。# UNIX系のファイルシステムでハードリンクが別パーティションのファイルに作れないのと同じようなもの65536個の制限は、仕様です、のひと言につきます。仕様書に16ビット分確保されるように記述されています。勝手に32ビットなりそれ以上のビット数に拡張することは、現状においては BTRON3仕様に反します。なので、超漢字(B-right/V)にその責はありません(ただし表向き)。# 昔、関係者だったけれど ID--MIYAZAKI YasushiRe:扱えるデータの数が最大で65536 (スコア:2, 興味深い)Anonymous Coward のコメント: 2006年09月21日 1時05分 (#1022980)実際、そうやって回避しているアプリもありますが…。#超漢字メールとか専用アプリでしか扱えないデータにしてしまうと、データ同士の密な参照関係を作り上げることで飛躍的に使いやすくなる実身・仮身システムの利点が失われてしまいます。BTRONのヘビーユーザーほど巨大な仮身ネットワークを作り上げているので、きつい制限となっている実身数上限の撤廃はユーザーの悲願なのです。Re:扱えるデータの数が最大で65536 (スコア:3, 参考になる)tarosuke (2403) webmaster@tarosuke.net のコメント: 2006年09月21日 13時47分 (#1023281)( http://talos-kernel.sourceforge.net/index.jp.html | 最新の日記: 2007年07月08日 5時14分 )># たしか超漢字にはシンボリックリンクに似た仕組があったような「ディレクトリまで含めて全てがハードリンクで構成されている」の方が近いと思う。んでファイル自体が実身、リンクが仮見。実身は一つのファイルだけどちょうどwebページアーカイブのように*文字列や画像など一つの文書を構成するデータは全て入ってる。なのでファイルは他のOSと比べてかなり少ない。問題なのはファイルIDそのものをユーザプロセスが触らなきゃならないメタメタな作りになっているところで、そのために拡張するのにユーザプロセスをいろいろいじらなきゃならなくなってる。カーネルだけの問題ならちょいと直せば済む話。*なのにどうしてもじらなんか入れたんだろうねぇ...。--...って思うんだけどなぁ...。