BeOSのお葬式はどこでやってるの？。

1 ：01/07/02

なむさん、なむさん、じょうぶつしろよ。MacOSもどき。

2 ：01/07/02

1 名前：昼下がりの休息 投稿日：2001/06/26(火) 14:25
ＳＯＮＹ、ＡＰＰＬＥ、ＭＩＣＲＯＳＯＦＴ、ＮＩＫＯＮ、巨人（メーカーではないけど）
等やっぱり人気物にはアンチ派閥が出来てしまいますね。
他のメーカーでは大したことじゃないのに人気メーカーだと大事になっちゃう。
普段いい物を出しているとちょっとしたことでも目立つからでしょうね。
いい物はいいで認めて悪い物は悪いで言いと思うんだけど。
メーカーを指定して駄目って言っちゃうところが不思議？
そう思いませんか？

3 ：01/07/02

巨人（メーカーではないけど）

4 ：01/07/02

BeOSってMacOSもどきなのか？むしろMacOSが後を追っているような・・・

5 ：01/07/02

>>1
どこがモドキなの？
全然違うよ。動作の軽さとか(w

6 ：01/07/03

>>1
なにが言いたいのかよくわからない。

7 ：01/07/03

>>5
軽いだけで、それ以外に特に秀でた部分がないのが現実じゃん。

8 ：01/07/03

>>7
ちゃんと使ったことある？
いるんだよねー、伝聞だけでシッタカの奴って

9 ：01/07/03

香典は1000万円単位でお願いします。
棺おけからよみがえる可能性があります。

10 ：01/07/03

>1
あんたの自宅でやりなさい。

11 ：01/07/03

>>7
POSIX、API の C++ インターフェース、ウィンドウ API、
スレッド生成機構、ウェイトオブジェクト、SMP 対応設計、
メッセージングとその中に収められるデータの種類、
ウィンドウマネージャの切り替えによる外見変更…。
Mac でやってみ。

12 ：01/07/03

簡単だからインストールしてみたけど２、３回起動してそのままです。

13 ：01/07/03

簡単なのはインストールだけじゃないんだけどね。
日本語アプリ＆情報が少ないと日本人は敬遠するみたいね。残念。

14 ：01/07/03

BeOS5日本語版発売記念上げ

15 ：01/07/04

BeOS別に俺映像編集のセカンドマシンで使ってるけど
使い勝手良いけどなー。
まあ、たまに自分でドライバかかなきゃいけなくて
大変な時あるけどさ。
ハードウェアの仕様をみつつ
ドライバ書いたりとか出来ない奴は
推奨ハードを使えば良いし。

16 ：01/07/04

既存のOSに寄生（？）できる戦法は、初心者対策としてなかなか
良かったと思うけどな。ドライバが痛すぎる。
個人的にはMAC OSよりも全然ｶｺｲｲと思うけどな。

17 ：01/07/04

>>16
＞個人的にはMAC OSよりも全然ｶｺｲｲと思うけどな
同意。
大体Macなんかとはレスポンスの速さが全然違うよね。
後はドライバだよなあ。。
色々使いたいハードもどんどんでてくるし
15みたいにドライバ自分で書けるまで要求するってのは
やっぱり商品としてはちょっと敷居が高いよなあ。
Buzのドライバ書いた奴は本当に偉い。

18 ：01/07/05

>>11
>POSIX
POSIXアプリ使うならLinuxで十分。今やPOSIXアプリなどMacOS Xでも動く。
>API の C++ インターフェース、ウィンドウ API、
>スレッド生成機構、ウェイトオブジェクト
すべて「プログラマに対するメリット」であって、ユーザーに直接的にメリットが
あるわけではない。これらの条件によって「優れた性能を発揮するアプリ」が作り
やすい状況をめざしたはずなのに、実用レベルの（小物ユーティリティやらじゃ
なくてな）対応アプリ数のお粗末さは周知の事実。
>SMP 対応設計
これはユーザーにメリットがある部分だけど、それも処理が軽くなるという
メリットに集約される。SMP対応OSの中でBeOSはかなり高効率なOSなのは認
めるが、SMP対応そのものは別にBeOSの専売特許ではない。
>メッセージングとその中に収められるデータの種類
これもプログラマに対するメリットであって、エンドユーザーには関係のない
話。それに他にも同様の仕組みを実現したOSはある。別にBeOSだけの特色では
ない。
>ウィンドウマネージャの切り替えによる外見変更
X Window Systemならごく当たり前の機能。MacですらKaleidoScopeでとっくの
昔に実現されてるが？
つまり、「出た当時はともかく、今はすでにアドバンテージはない」ということだ。

19 ：01/07/05

＞POSIX
真似っていうから、MacOSでやってみって言ってるんでしょ。
BeOSが出た頃は、MacOSは7.6とか8.0だよ。
それに他の部分もプログラマにしかメリットがないように
思いこんでるみたいだけど、本気でそう思ってるの？

20 ：01/07/05

>>18
>つまり、「出た当時はともかく、今はすでにアドバンテージはない」ということだ。
100歩譲ってこれを事実であると仮定しても ,
このままでわ 32bitのアドレス空間なんてすぐに使い切るられるだろうし
ギガオーダなデータを VJソフトをカルく超える極限さで いぢりまくりになる時の事を考えてみ .
その時になっても 64bit_winが肥大していないとしたら救いわまだあるが
( つーかそれ言ったら ATとx86 がヤバい 気がするけど
( だからとりあえずアイテニアムなんか ? ) ) .

21 ：01/07/06

もうデムパの話なんて誰も聞かないよ

22 ：01/07/06

Macなんかと比べ物にならない位安定してるけど？
アプリがフリーズしたって、OS自体は殆ど落ちないし。
どっちが真似だとかは俺にはわからねーけど...
例え>>1の言った事が正論だったとしても俺は構わない。
でも、真似されたOSに負けてるの？ﾌﾟﾌﾟ

23 ：01/07/06

>>22
勝った負けたはともかく
やっぱ真似なんですか.....
鬱

24 ：01/07/06

BeOSはMacOSの真似ではないよ、つーか別もんだろ、どっか似てるか？

25 ：01/07/06

外面的にはマネ。
内部的にはスクラッチから書き上げられた（それが最初のウリだった）。
ＯＳの内部機構はまだまだ先進的。
でも 18 が言いたいのは市場性やシェアの事だから、何も言うべきことはないな。
Be はまだプログラマーが組んで楽しむ OS を脱していないし、それでいいと思うし。

26 ：01/07/06

外面的に真似してると言ってもショートカットキーとか
ごみ箱とか、デスクトップとかのGUIが、Windowsに較べて
Mac寄りに仕立てられているぐらいで、他の部分は真似ているとは
思えないんだけどね。どう？
まあ>>1は、表面的なことしか分からない人間っていうことですな。
しかし、こんな糞スレにマジレスしてる俺も俺だな。ｳﾂ

27 ：01/07/06

>>26
あ、モチロンそういう前提。
でも、「最初にプルダウンメニューを実装したのは…」とか言い出す奴が必ずいるからね。（ｗ
まあマネはマネと見とめておく方が波風立たんよ。
オレが興味あるのは Be と MFC との相関性だし。
やっぱ Be 版 Kylix 出てほしいな。

28 ：01/07/06

>>27
BeとMFCの相関性？
あの糞フレームワークとBeAPIの相関性って何よ

29 ：01/07/06

MFC アプリの移植をし易いように設計したんじゃないのかな、と思ってる。
API 本見て、正直「こりゃ戦略的に設計してるわ」と唸ったからね。

30 ：01/07/06

>>29
どう考えても移植し易くないだろ・・

31 ：01/07/06

オブジェクトの責任範囲が近いと思うよ。

32 ：01/07/06

つか、MFC で書かれたのを、サポートライブラリなしで X に移植しようとしてみなはれ（言語は当然 C）。
半日でやめたね。
Be はそのあたりを最初から用意してくれてるんだよ。
Kylix 作るのに Borland はとんでもねー CLX ライブラリを用意したわけだけど、Be 版 Kylix がもし出るなら、かなり軽いラッパで行けると思う。

33 ：01/07/07

>>27
新たなデムパの出現か？

34 ：01/07/07

>>33
Be ver4 が出た当時の状況でやってみりゃわかる。

35 ：01/07/07

必ずしもウソとは言えないと思われ　>>33
でもあまり今まで指摘されて来なかった部分なんで、詳細を教えて欲しいところ

36 ：01/07/08

いや、オレももうベースは Linux に移ってるから、Be への移植は仕事関係のを試しにやってみただけなんだが。
Be API 本が会社にあるんで詳細は週後半に書くけど、オレが推理する Be 開発者の思考経路は、
・MFC は C++ ベースで書ける Window システムを目指したクラス群だった。
・それまでの Window 関係の GUI は、非オブジェクト志向で OS ライブラリとリンクするか、X のようなクライアント／サーバの形式を取っていた（ハード依存部のある Mac は置いとく）。
・これがため、MFC は OS の機能として実装されたわけではなくて、あくまで描画命令への橋渡し／集約の役目に留まってしまった。
・これは（また、モチーフや GTK のような類似のものは）OS が高度な描画（やツールキットで提供される他機能）に立ち入れない事を意味する。
・また、結果としてこれらは「スレッドセーフなアプリを書くのはプログラマーの責任」として、折角のオブジェクト志向のメリットを半減させてしまった（少なくともプログラムロード時に OS がクラスの特性を判断してやるような事は不可能）。
・そこで Be は、OS を完全に C++ で書き直すことで、OS 自身が MFC レベルの機能を理解できるような設計にされた。
・結果、インターフェース自体はよくある MFC タイプのツールキットであっても、適したスレッド分けの判断や、アプリ単位ではなくクラス単位の負荷分散ができるようになった。
・ここに至って、Be 社は「既製のライブラリクラスのクラス分割に近づけてやれば、移植の手数が減る上に、既存プラットフォームで実行するよりもアプリのパフォーマンスを上げられる」と考えた…。
…と、もしここまでの推論が正しいとするなら、あとは Be の API 本といろいろな Window ライブラリを見比べてみる作業をすれば、各人なりの納得行く答えが出てくると思う。
人によってはモチーフだと言うかもしれないし、Mac の API と言う人間もいるかもしれない。でもシェア的にもコードを参考にするにも、オレには MFC しか思い浮かばない。
ちなみにオレが「Be は MS 系をモデルにしたんじゃないか」と思ったキッカケは、Be のクラスが Direct Draw の機能を盛り込んでるからなんだよね。
あと、アプリケーションクラスの存在かな（このあたりはもう一度 API 本を見なきゃハッキリせんけど）。
長々と書いたが、以上。後半部は木曜くらいに。

37 ：01/07/08

うむむ。続報期待。下げてお待ちしてます。

38 ：01/07/09

ちうか、こっちも FreePascal に統一しようか…名前。
>>37
36 で書いた説明自体も、わかってる人にしかわからん説明になっちまった。
Be の概念を説明しようとしたら、それだけで本の分量になるかもしれないなー。

39 ：01/07/12

ぬをー
今日は会社に行かなかった（いま技術アドバイザみたいな立場なんで、毎日出てるわけじゃない）…。
明日、Be の資料取って来るっす。

40 ：01/07/12

Beの資料を常時おいてる会社ってどこだ？
ＢＣ？

41 ：01/07/18

souce kousaki

42 ：01/07/18

>>40
ソースネクスト

43 ：01/07/18

sage

44 ：01/07/19

>>42
BeOSがソースネクストに買収されて
「速OS」とか言う名前で出されたらすごく悲しい

45 ：01/07/19

>>44
ﾜﾛﾀ

46 ：01/07/19

ソニーがアメリカでBeOS搭載のインタネットに特化したパソコンを
出すらしいんだけど？縦画面でさ。でもなんでBeOS？
詳細、知ってる人いたら情報希望

47 ：01/07/19

>>46
BeOSじゃなくてBeIAだって・・・

48 ：01/07/19

そうでしゅか…

49 ：01/07/19

「ガセー、お前はすでに死んでいる！」
「何？･･･ふえっ、ビアイエっっーーーー」

50 ：01/07/19

>>49
ﾜﾛﾀ　でも、一瞬分かんなかったよ。カタカナで書かれると。

51 ：01/07/23

FreePascalさん続きプリーズ .
>>35
>でもあまり今まで指摘されて来なかった部分なんで、詳細を教えて欲しいところ
ハッカーの間でもそうなん ? . 最も肝心な所の一つな気がするのに .

52 ：01/07/25

>>46
http://www.evilla.com/
Sonyはやる気あるみたいなこと言ってるけど。

53 ：01/07/25

デムパ２名うぜーよ

54 ：01/07/25

MFC?
ホントにコード書いたことあんのかな？(藁

55 ：01/07/27

この前ＢｅのAPIリファレンス立ち読みしてみたけど
ほんとにマルチタスク上手いっすね
新鮮な感動があった

56 ：01/07/27

…結論としては、「>>1 は脳足りん」って事でいいのかな？

57 ：01/07/27

>>56
あとデムパ２名も追加

58 ：01/08/02

結局やめかい >27 . という事で関連事項を勝手に書くとする .
その API ( システムコールのインタフェイスと理解 ) の裏側について .
BeOSわ一つの仕事を勝手に複数のプロセス ( オブジェクト ? ) に分割する
とどこかで読んだ気がするが ,
事実だとするとそのシステムわ `` ローカルな分散システム '' に他ならない筈
( 複数プロセッサ環境に最適化されている事からも類推可能 ) .
この先ローカルでない大型分散システムの普及がより進む事わ想像に難くないが
その環境の奥の奥の最深部の更に底まで浸透して
拒絶反応を起こさずに融合する事ができるクライアントシステム
の価値が技術面からも営業面からも計り知れない程に大きい事
に異議わないだろう ( 人工生命方面や人工知能方面からわ特に ) .
そして , その透過性を
クライアント環境としての実用性を保ちつつ確保する為にわ
`` ローカルな分散システムとしての性格を持っているにも関わらず速い ,
という 奇跡のクライアントOS ''
がないと無理である事わ道理だ .
この事から導ける結論の一つ :
`` winが駄目なら最悪の場合でも 単に速いOS を自社開発すりゃいいんだろ ? ''
という安易な考えわ
分散クライアントが大活躍できる状況でオイシいとこを頂く事に
技術面からも営業面からも大失敗する ( 失敗した事に気付く事さえできない ) .

59 ：01/08/03

だからちゃんと読んで欲しかったらデムパ度下げろって
お前はバカか？

60 ：01/08/04

この前までエロがどーのこーの言ってたデムパの言葉なんて
説得力ねーよな（w

61 ：01/08/04

>>59
今更で悪いんだが ,,,
君の頭の中に デムパの仕様書 があっても 俺らエスパーじゃねーしな .
>>60
みなまで言わなきゃ分からんのか ? , あれの趣旨 . マジで ? .
59の脳内デムパ仕様書と違って ,
近辺の文脈で完全補完できる事しか省いてねーぞ . しかも前方参照を極力減らしてるし .
>>58のロジックに破綻を発見できなかったとの見解の暗示 ( 半ば明示 )
に対してわ感謝する .
そういや他にもいるな , 文脈読まずに勘違いで煽る奴が .
気付いた人も黙ってたりするけど そういうのわﾁｮﾄｲﾀいぞ , 例えデムパ相手でもな .

62 ：01/08/04

>>61
反論は堂々とageでお願いしたいものです。
BeのAPIって、一番基本部分設計してた頃
まだWin95どうかな〜って頃でしょ。
MFCじゃなくてNEXTSTEPのKitじゃないのかなぁ、影響受けてるのは。
BeもKitでしょ。
どうなんでしょうか？Seisei_Yamaguchiさんっ！！

63 ：01/08/04

FreePascalさんはDirectDrawあたりの話を
出しておいでだったけど、Release3の頃もうありましたっけ？

64 ：01/08/04

ウザイよデムパは、、、
って書くと反論するのは自覚してる彼だけだけど（w

65 ：01/08/04

引き抜いてやった。よかった。

66 ：01/08/04

>>63
在ったはず。
何たってDirectDrawはWin3.1の頃から
ハードウェアDCIとして仕様策定されてきたからな。

67 ：01/08/04

最強のデンパを語ろうスレ、作ろうかなｗ

68 ：01/08/04

Be 買収間近に
スラッシュドットを見て下さい
http://slashdot.jp/

69 ：01/08/04

Be関連スレをずっとROMしている者だが、
Seisei_Yamaguchi氏は
「は」→「わ」の変換とコテハンは譲れない一線なのか？
読みづらい文章をコテハンで書き込むのって、内容に関係なく
叩いてくれといっているようなものだと思うが。
というか、たとえ名無しでも助詞が「わ」になってるのを見ると読む気が失せるがな。

70 ：01/08/04

>>69
単にかまって欲しいだけだろ＞デムパ
こいつはBeOSのこと2chでしか語ってないし（他で見たことない）
日本語変だし学校出ていないのでしょう。
放置が○

71 ：01/08/04

>>69
>読みづらい文章をコテハンで書き込むのって、内容に関係なく
>叩いてくれといっているようなものだと思うが。
それが容認されているのは戸田美智也くらいか

72 ：01/08/05

技術者からの >>58に対する反論 がないので自信を深めました .
あれを理解した事を控え目に主張している人が一人居る様に見えますが
あれを理解できていない人が居るとして , その主要因が その人の
日本語パーシングの問題 でなく 技術的科学的知識の問題 だとしたら ,
それを恥じる必要わないです
( 私わと言えば Cが分かりませんし , 何より ある人が言うにわデムパらしいですよ ) .
>>58
s/大失敗する/大失敗をまねく/

73 ：01/08/05

>>72
マジでデムパだ。。。

74 ：01/08/05

>>72
誰も相手にしてないと思われ

75 ：01/08/06

>>71
戸田美智也スレ読んだよ。爆笑しちまったじゃねーか

76 ：01/08/06

>>72
君の言う「分散クライアント」案で、君が何らかの製品作って
BeOSの営業活動やれるなら、誰も何も言わないさ
だが君の文では、「分散システム」が何を意味していて、
BeOSがなぜそれに適していて、処理に都合がいいと考えられるかが
全く読み手に伝わらないから手の差し伸べようがないのよ
技術的知識以前の問題
あと、「人工生命方面や人工知能」というけどね、
ただ単に君の妄想をぶちまけているようにしか見えない。
裏づけが何もないから
某Loliの話に影響受けたという可能性もあるけど、
どのみち内容がないから妄想＝デムパって言われるだけ
まあこうしてデムパがネット上で遊んでられるってのも、
日本がまだまだ豊かな証拠かな
次からは、ちゃんと学校で習った日本語で裏付けしながら書こうな

77 ：01/08/07

>BeOSわ一つの仕事を勝手に複数のプロセス ( オブジェクト ? ) に分割する
>とどこかで読んだ気がするが ,
>事実だとするとそのシステムわ `` ローカルな分散システム '' に他ならない筈
>( 複数プロセッサ環境に最適化されている事からも類推可能 ) .
ここだけ気になった。プロセスを勝手に分割するってどういうこと？
こういうことは確信もっていわないとだめでしょ。ホントだとするならおれも
BeOS使うよ、そりゃ。システムがスレッドを自動生成なんて聞いたことないし。

78 ：01/08/08

>>76
ツッコミありがとうございます .
分散システムがより普及するだろう環境とは , 何の事はない , あらゆる環境です .
想像し易い具体例は大学なりの中規模サーバです .
人工生命と人工知能の件については ,
`` OSは , 単に存在するだけの各リソースに有機的関係をもたらす ''
とだけ述べれば最低限充分でしょう .
学校で習うWindowsで誰もが満足するとしたら ,
BeOSに手を出す人は居ないでしょう .
>>77
すみません , `` プロセス内のスレッドの事だったかな '' といった状況です .
識者からの指摘を希望します .
クライアントシステムからのサーバシステムへの透過性 のくだりに対しても
ツッコミを希望します .

79 ：01/08/08

>>77
Art of BeOS Programmingでも読んでね。
http://www.sie.co.jp/mediaosJ.html
ここにもちょっと書いてあるけど。
"pervasive multithreading"は伊達じゃない。

80 ：01/08/08

都合悪い書き込みは無視ですか？＞デムパ

81 ：01/08/08

＞人工生命と人工知能の件については ,
＞`` OSは , 単に存在するだけの各リソースに有機的関係をもたらす ''
＞とだけ述べれば最低限充分でしょう .
意味不明

82 ：01/08/08

>>79
じゃぁおれBeOS使わないといけないじゃねーか！
今ならただだし入れてみるか･･･
ちなみにAtheOSって内部の構造はまるで違うんだよね？

83 ：01/08/08

>>79
でも、MachとかのKernel level multithreadingとどうちがうの？
別にThreadをそれぞれのProcessorに割り当てるなんて
そんなにすごいことじゃないような気がするんだけど。。。
Amoebaなんかは、どのthreadやtaskがどのプロセッサで走っているかも関係ない。
そういうのが本当の分散OSっていうものなんじゃないの？

84 ：01/08/08

>>83
79が言ってるpervasive multithreadingってなんなのか
良くわかんないからGoogleで検索したけど、分かりやすい
説明ってなかった。なんだかマーケティング用語クサイ気が
するなぁ･･･
OS、開発ツールともにタダだからコンパイラがどんな
コード生成するのか確かめるのが一番か。
ところでAmoebaってどんなインターフェイスもってるの？
そっちの方が興味あったりして。
オープンでかつCライブラリーの呪縛から逃れてるような
システムが欲しいよ。

85 ：01/08/08

>>84
Amoebaは、Linusと喧嘩したTanenbaumが作った分散OSです。
うーむ、Amoebaは個人ユーザ向きじゃないかも。
本当にパフォーマンスが欲しいなら、Ethernetでつながれたマシンが複数必要。
あと、Linuxの初期のころのように、サポートされているハードウェアが極端に限られている。
まだ、Linuxのようにコンシューマ向けではないから。。。
Unixのサブシステムも走るし、Xも走るみたい。
http://www.cs.vu.nl/pub/amoeba/
Machであれば、Gnu Hurdとか、MacOS Xとか、Litesとかで遊べる。
一番遊びやすいのが、AppleのMacOS Xかもしれないです。
とりあえず、買えばMachが入っている。（Macが好き嫌いは別として。）
僕はこのためだけにiBookを$1500くらいで買いました。
ただし、OS XはUIの部分が遅い...次の10.1で速くなるって言うけど。
あとは、Machのシステムコールを使って、遊ぶも良し、
自分で、いろいろUnixとか他のOSをサブシステムとして作るのも良し。
Machのネイティブなシステムコールの説明とかは以下のところにある。
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html

86 ：01/08/08

>>85
MacOS Xのカーネルってシングルサーバーだったよね？たしか。
BeOSはマルチサーバーなんでしょうか？

87 ：01/08/08

なんかスレが違う話題してないか？
ここってネタスレだろ？

88 ：01/08/08

あもえばってtarでファイルシステムに書き込むだけで動くんだよね？
ファイルシステムはなにかな？ext2じゃだめだよね？
あとでやってみる。ありがとう。
その前にBeだよBe！

89 ：01/08/09

>>80
私の事ですね .
これ
>BeOSがなぜそれに適していて、処理に都合がいいと考えられるかが
の事なら , 透過性をキーワードとして挙げてある事を指摘し忘れました . すみません .
>>62の事なら , 敵意が込められた ( らしい ) モノに積極的に応える程の律義さを
私は持っていません . あなたに応える程度には律義ですが .
とは言え62に言及すると , 私はkitを知りません .
MachがクライアントOSとして実用になり得る分散OSであるという点は
62さんの考えと矛盾しない ( だけでなく追い風となる可能性もある ) でしょうね .
>>81
ゆうき いう― 【有機】
（1）生命をもち、生活機能や生活力を備えていること。
（2）生物体のように、全体を構成している各部分が、互いに密接な統一と関連をもっていること。
（3）「有機化学」「有機化合物」「有機物」の略。⇔無機
大辞林第二版より . `` 意味不明 '' とまでおっしゃる前にこの程度は調べて頂きたい .
ただ私も , 一意解釈の余地等に問題があった事を認めはします .
fix前 : OSは , 単に存在するだけの各リソースに有機的関係をもたらす
fix後 : OSは , 有機的関係を単に存在するだけの各リソース間にもたらす

90 ：01/08/09

>Seisei_Yamaguchiさん
なんだか怪しい響きのある分散OSって言葉の前に
スレッドとSMPの実装について他のOSに対するどういった利点があるのか、
知りたいんじゃないかな？MachだってSMPをBSDに実装するところから出てきた
ものだし。
分散OSよりもずっと簡単なCORBAやDCOMさえまともに実装したアプリケーションが
ないこの現状で分散OSとはちょっと先走りし過ぎではないかな。
それに時代はより疎結合へと向かっている。XMLのことです。
リソースが足りないと思っている人より、有り余ってると思っている人の
方が多いし、多数を相手にした技術の方がお金になる。
個人的には分散OSとかそういう低レベルの分野ってもう･･･時代遅れな
気がするんだけど。
ものすごく興味はあるんだけど商売にはなりにくいね。
なったとしてもそれは間違ってもクライアントレベルじゃないと思う。

91 ：01/08/09

ちなみに分散OSを実現するために今のIPプロトコルで問題ないのかな？
そっちの方が知りたい。何もわからないんで。

92 ：01/08/09

デムパウザイので
■□■□■□■□終了■□■□■□■□

93 ：01/08/09

>>92
つーかここの板、デンパとクソスレしかないからもうなくなって欲しい。
BeOSについて話したければ、ソフトウェア板でいいじゃん。

94 ：01/08/09

>>93
ソウダネ
というわけでデムパは無視でお願いします

95 ：01/08/09

■□■□■□■□終了■□■□■□■□

96 ：01/08/10

>>92-95
まあ , そうピリピリなさらずに .
斜め読みでもして頂けると分かるかと思いますが ,
BeOSと言うよりも分散システムの話がこの会話の主題になっています .
それに , アンチマカー派であろう ( ? ) あなた達にとって
直接的利益になりそうな事 をついでに述べると ,
この一連の話にはマカー叩きの為のかっこうの材料が満載されています .
それらを活用すればあなた達にとって憎い憎いマカー達を叩き放題ですよ .
>>91
Amoebaの場合 , IPでなくFLIPを採用しています .
http://www.sol.cs.ritsumei.ac.jp/~terazawa/zemi/amoeba.html
AmoebaでIPを使う為にはIPサーバを利用します .

97 ：01/08/10

>>90
業界内の事情を基準に考えるのはいかがなモノでしょうか
( JAVAなりをあのMSでさえ今もなお完全制圧できていない ( 苦戦している ? ) 事
の主要因の一つとして ,
以前はPC業界の範疇になかったインターネットにMSが気付くのが遅かった事
を挙げる事が可能でしょう ) .
その線で行けば , 生体分散システムの代表格である脳 ( 細胞,ニューロン,脳内プロセス )
との連携をより直接行うバーチャルリアリティ
の関連市場を視野に入れない事もまた 営業上の失策と言えるでしょう
( それが;ニューロコンピュータ,量子コンピュータ;とセットになる可能性をも ) .
まあ一見突拍子もない話を続けるのを次回以降に譲るとして ,
>それに時代はより疎結合へと向かっている。XMLのことです。
のレベルでの結合が進んでいる事は事実でしょうが ( TADも進んでいるのか ? ) ,
その事が即ち 低レベル分散システムの衰退を意味する事の根拠になる
という事は到底ないでしょう
( Be名無しさん , あなたは `` その事が即ち '' と述べていませんが ) .
( CORBAなりを実装した ? ) Jiniなり と JAVA の組み合わせ に価値があるとするならば
( Jini機器はJAVAのオブジェクトとして振る舞う事が可能 ) , 同じ意味で ,
分散OSベースサーバ と それに対してオブジェクトの設計の相性がいいクライアントOS
の組み合わせ には価値があるという事になるでしょう
( この組み合わせの利点はそれだけではないですが ) .
仮にそうでないとしても , 分散オブジェクト技術が組み込まれたクライアント機器
がIPV6なりのもとで星の数ほど稼動する状況においては ,
それらのハブ空港 ( ハブ都市 ) としての分散OS ( 的 ? ) サーバシステムは
少なくともかなり有用でしょう .

98 ：01/08/10

■□■□■□■□終了■□■□■□■□

99 ：01/08/10

終了はsageでネ
■□■□■□■□終了■□■□■□■□

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

新OSを作ったら何が必要か話すスレ (102)
DOS/V時代のゲームプレイ環境保全策 (233)
お前らシステムコマンダー ってどうですか？ (107)
DOS全般を語るスレ 2 (223)
LindowsOS4.0 日本語版ってどうよ？ (342)
ＯＳ／４００最高！！ (372)
--log9.info------------------
【山形】 湯野浜 【鶴岡】 (265)
【磯ノ浦】和歌山でサーフィン【漁港】 (114)
働きながらプロサーファー (214)
cole surfboad (742)
日本の海水浴場ナンバー1＆ワースト１はどこ?? (182)
【著作権】＿サーフィンの動画＿【違反？】 (209)
ステッカーについて語りませんか？ (171)
【タトゥー】入れ墨ＳＵＲＦ【刺青】 (602)
旭ＫＩサーフ　第３章 (886)
【CA】カリフォルニアの板を語るスレ【西海岸】 (526)
刺青の入ったインストラクターってどうですか？ (173)
海まで１０分以内の住民がまたーりと集うスレ (201)
JPSAロング (617)
【サメ】ダイビングで魚に襲われた【ウミヘビ】 (316)
雲見のダイビング (383)
福岡のサーフィン事情 (332)
--log55.com------------------
【バーチャルYouTuber】深雪【ディープブリザード】 Part.5
【オプレク・ニコ生】なつか アンチスレ Part20【鼻糞食べてキレるデブ】
Nottin、元のっちんファミリー　51
【バーチャルYouTuber】猫宮ひなた　議論・考察・検証スレ #3
【二軍淫夢】緑のお茶姉貴について語るスレ4【ザッパー☆声優】
【贈与税未納疑惑＋】鋼兵（川本恒平）アンチスレPart580【なりきり・ハセカラ荒らし三昧】
【出るわ出るわの】るりまさん総合スレ☆36【RRMの19禁イラスト】
【脇毛お釜】めぐみチャンネルPart78【UUUMから省かれ奴】