BeOSのお葬式はどこでやってるの?。
なむさん、なむさん、じょうぶつしろよ。MacOSもどき。 「ガセー、お前はすでに死んでいる!」
「何?・・・ふえっ、ビアイエっっーーーー」 >>49
ワロタ でも、一瞬分かんなかったよ。カタカナで書かれると。 FreePascalさん続きプリーズ .
>>35
>でもあまり今まで指摘されて来なかった部分なんで、詳細を教えて欲しいところ
ハッカーの間でもそうなん ? . 最も肝心な所の一つな気がするのに . MFC?
ホントにコード書いたことあんのかな?(藁 この前BeのAPIリファレンス立ち読みしてみたけど
ほんとにマルチタスク上手いっすね
新鮮な感動があった …結論としては、「>>1 は脳足りん」って事でいいのかな? 結局やめかい >27 . という事で関連事項を勝手に書くとする .
その API ( システムコールのインタフェイスと理解 ) の裏側について .
BeOSわ一つの仕事を勝手に複数のプロセス ( オブジェクト ? ) に分割する
とどこかで読んだ気がするが ,
事実だとするとそのシステムわ `` ローカルな分散システム '' に他ならない筈
( 複数プロセッサ環境に最適化されている事からも類推可能 ) .
この先ローカルでない大型分散システムの普及がより進む事わ想像に難くないが
その環境の奥の奥の最深部の更に底まで浸透して
拒絶反応を起こさずに融合する事ができるクライアントシステム
の価値が技術面からも営業面からも計り知れない程に大きい事
に異議わないだろう ( 人工生命方面や人工知能方面からわ特に ) .
そして , その透過性を
クライアント環境としての実用性を保ちつつ確保する為にわ
`` ローカルな分散システムとしての性格を持っているにも関わらず速い ,
という 奇跡のクライアントOS ''
がないと無理である事わ道理だ .
この事から導ける結論の一つ :
`` winが駄目なら最悪の場合でも 単に速いOS を自社開発すりゃいいんだろ ? ''
という安易な考えわ
分散クライアントが大活躍できる状況でオイシいとこを頂く事に
技術面からも営業面からも大失敗する ( 失敗した事に気付く事さえできない ) . だからちゃんと読んで欲しかったらデムパ度下げろって
お前はバカか? この前までエロがどーのこーの言ってたデムパの言葉なんて
説得力ねーよな(w >>59
今更で悪いんだが ,,,
君の頭の中に デムパの仕様書 があっても 俺らエスパーじゃねーしな .
>>60
みなまで言わなきゃ分からんのか ? , あれの趣旨 . マジで ? .
59の脳内デムパ仕様書と違って ,
近辺の文脈で完全補完できる事しか省いてねーぞ . しかも前方参照を極力減らしてるし .
>>58のロジックに破綻を発見できなかったとの見解の暗示 ( 半ば明示 )
に対してわ感謝する .
そういや他にもいるな , 文脈読まずに勘違いで煽る奴が .
気付いた人も黙ってたりするけど そういうのわチョトイタいぞ , 例えデムパ相手でもな . >>61
反論は堂々とageでお願いしたいものです。
BeのAPIって、一番基本部分設計してた頃
まだWin95どうかな〜って頃でしょ。
MFCじゃなくてNEXTSTEPのKitじゃないのかなぁ、影響受けてるのは。
BeもKitでしょ。
どうなんでしょうか?Seisei_Yamaguchiさんっ!! FreePascalさんはDirectDrawあたりの話を
出しておいでだったけど、Release3の頃もうありましたっけ? ウザイよデムパは、、、
って書くと反論するのは自覚してる彼だけだけど(w >>63
在ったはず。
何たってDirectDrawはWin3.1の頃から
ハードウェアDCIとして仕様策定されてきたからな。 Be 買収間近に
スラッシュドットを見て下さい
http://slashdot.jp/ Be関連スレをずっとROMしている者だが、
Seisei_Yamaguchi氏は
「は」→「わ」の変換とコテハンは譲れない一線なのか?
読みづらい文章をコテハンで書き込むのって、内容に関係なく
叩いてくれといっているようなものだと思うが。
というか、たとえ名無しでも助詞が「わ」になってるのを見ると読む気が失せるがな。 >>69
単にかまって欲しいだけだろ>デムパ
こいつはBeOSのこと2chでしか語ってないし(他で見たことない)
日本語変だし学校出ていないのでしょう。
放置が○ >>69
>読みづらい文章をコテハンで書き込むのって、内容に関係なく
>叩いてくれといっているようなものだと思うが。
それが容認されているのは戸田美智也くらいか 技術者からの >>58に対する反論 がないので自信を深めました .
あれを理解した事を控え目に主張している人が一人居る様に見えますが
あれを理解できていない人が居るとして , その主要因が その人の
日本語パーシングの問題 でなく 技術的科学的知識の問題 だとしたら ,
それを恥じる必要わないです
( 私わと言えば Cが分かりませんし , 何より ある人が言うにわデムパらしいですよ ) .
>>58
s/大失敗する/大失敗をまねく/ >>71
戸田美智也スレ読んだよ。爆笑しちまったじゃねーか >>72
君の言う「分散クライアント」案で、君が何らかの製品作って
BeOSの営業活動やれるなら、誰も何も言わないさ
だが君の文では、「分散システム」が何を意味していて、
BeOSがなぜそれに適していて、処理に都合がいいと考えられるかが
全く読み手に伝わらないから手の差し伸べようがないのよ
技術的知識以前の問題
あと、「人工生命方面や人工知能」というけどね、
ただ単に君の妄想をぶちまけているようにしか見えない。
裏づけが何もないから
某Loliの話に影響受けたという可能性もあるけど、
どのみち内容がないから妄想=デムパって言われるだけ
まあこうしてデムパがネット上で遊んでられるってのも、
日本がまだまだ豊かな証拠かな
次からは、ちゃんと学校で習った日本語で裏付けしながら書こうな >BeOSわ一つの仕事を勝手に複数のプロセス ( オブジェクト ? ) に分割する
>とどこかで読んだ気がするが ,
>事実だとするとそのシステムわ `` ローカルな分散システム '' に他ならない筈
>( 複数プロセッサ環境に最適化されている事からも類推可能 ) .
ここだけ気になった。プロセスを勝手に分割するってどういうこと?
こういうことは確信もっていわないとだめでしょ。ホントだとするならおれも
BeOS使うよ、そりゃ。システムがスレッドを自動生成なんて聞いたことないし。 >>76
ツッコミありがとうございます .
分散システムがより普及するだろう環境とは , 何の事はない , あらゆる環境です .
想像し易い具体例は大学なりの中規模サーバです .
人工生命と人工知能の件については ,
`` OSは , 単に存在するだけの各リソースに有機的関係をもたらす ''
とだけ述べれば最低限充分でしょう .
学校で習うWindowsで誰もが満足するとしたら ,
BeOSに手を出す人は居ないでしょう .
>>77
すみません , `` プロセス内のスレッドの事だったかな '' といった状況です .
識者からの指摘を希望します .
クライアントシステムからのサーバシステムへの透過性 のくだりに対しても
ツッコミを希望します . >>77
Art of BeOS Programmingでも読んでね。
http://www.sie.co.jp/mediaosJ.html
ここにもちょっと書いてあるけど。
"pervasive multithreading"は伊達じゃない。 >人工生命と人工知能の件については ,
>`` OSは , 単に存在するだけの各リソースに有機的関係をもたらす ''
>とだけ述べれば最低限充分でしょう .
意味不明 >>79
じゃぁおれBeOS使わないといけないじゃねーか!
今ならただだし入れてみるか・・・
ちなみにAtheOSって内部の構造はまるで違うんだよね? >>79
でも、MachとかのKernel level multithreadingとどうちがうの?
別にThreadをそれぞれのProcessorに割り当てるなんて
そんなにすごいことじゃないような気がするんだけど。。。
Amoebaなんかは、どのthreadやtaskがどのプロセッサで走っているかも関係ない。
そういうのが本当の分散OSっていうものなんじゃないの? >>83
79が言ってるpervasive multithreadingってなんなのか
良くわかんないからGoogleで検索したけど、分かりやすい
説明ってなかった。なんだかマーケティング用語クサイ気が
するなぁ・・・
OS、開発ツールともにタダだからコンパイラがどんな
コード生成するのか確かめるのが一番か。
ところでAmoebaってどんなインターフェイスもってるの?
そっちの方が興味あったりして。
オープンでかつCライブラリーの呪縛から逃れてるような
システムが欲しいよ。 >>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 >>85
MacOS Xのカーネルってシングルサーバーだったよね?たしか。
BeOSはマルチサーバーなんでしょうか? なんかスレが違う話題してないか?
ここってネタスレだろ? あもえばってtarでファイルシステムに書き込むだけで動くんだよね?
ファイルシステムはなにかな?ext2じゃだめだよね?
あとでやってみる。ありがとう。
その前にBeだよBe! >>80
私の事ですね .
これ
>BeOSがなぜそれに適していて、処理に都合がいいと考えられるかが
の事なら , 透過性をキーワードとして挙げてある事を指摘し忘れました . すみません .
>>62の事なら , 敵意が込められた ( らしい ) モノに積極的に応える程の律義さを
私は持っていません . あなたに応える程度には律義ですが .
とは言え62に言及すると , 私はkitを知りません .
MachがクライアントOSとして実用になり得る分散OSであるという点は
62さんの考えと矛盾しない ( だけでなく追い風となる可能性もある ) でしょうね .
>>81
ゆうき いう― 【有機】
(1)生命をもち、生活機能や生活力を備えていること。
(2)生物体のように、全体を構成している各部分が、互いに密接な統一と関連をもっていること。
(3)「有機化学」「有機化合物」「有機物」の略。⇔無機
大辞林第二版より . `` 意味不明 '' とまでおっしゃる前にこの程度は調べて頂きたい .
ただ私も , 一意解釈の余地等に問題があった事を認めはします .
fix前 : OSは , 単に存在するだけの各リソースに有機的関係をもたらす
fix後 : OSは , 有機的関係を単に存在するだけの各リソース間にもたらす >Seisei_Yamaguchiさん
なんだか怪しい響きのある分散OSって言葉の前に
スレッドとSMPの実装について他のOSに対するどういった利点があるのか、
知りたいんじゃないかな?MachだってSMPをBSDに実装するところから出てきた
ものだし。
分散OSよりもずっと簡単なCORBAやDCOMさえまともに実装したアプリケーションが
ないこの現状で分散OSとはちょっと先走りし過ぎではないかな。
それに時代はより疎結合へと向かっている。XMLのことです。
リソースが足りないと思っている人より、有り余ってると思っている人の
方が多いし、多数を相手にした技術の方がお金になる。
個人的には分散OSとかそういう低レベルの分野ってもう・・・時代遅れな
気がするんだけど。
ものすごく興味はあるんだけど商売にはなりにくいね。
なったとしてもそれは間違ってもクライアントレベルじゃないと思う。 ちなみに分散OSを実現するために今のIPプロトコルで問題ないのかな?
そっちの方が知りたい。何もわからないんで。 デムパウザイので
■□■□■□■□終了■□■□■□■□ >>92
つーかここの板、デンパとクソスレしかないからもうなくなって欲しい。
BeOSについて話したければ、ソフトウェア板でいいじゃん。 >>93
ソウダネ
というわけでデムパは無視でお願いします >>92-95
まあ , そうピリピリなさらずに .
斜め読みでもして頂けると分かるかと思いますが ,
BeOSと言うよりも分散システムの話がこの会話の主題になっています .
それに , アンチマカー派であろう ( ? ) あなた達にとって
直接的利益になりそうな事 をついでに述べると ,
この一連の話にはマカー叩きの為のかっこうの材料が満載されています .
それらを活用すればあなた達にとって憎い憎いマカー達を叩き放題ですよ .
>>91
Amoebaの場合 , IPでなくFLIPを採用しています .
http://www.sol.cs.ritsumei.ac.jp/~terazawa/zemi/amoeba.html
AmoebaでIPを使う為にはIPサーバを利用します . >>90
業界内の事情を基準に考えるのはいかがなモノでしょうか
( JAVAなりをあのMSでさえ今もなお完全制圧できていない ( 苦戦している ? ) 事
の主要因の一つとして ,
以前はPC業界の範疇になかったインターネットにMSが気付くのが遅かった事
を挙げる事が可能でしょう ) .
その線で行けば , 生体分散システムの代表格である脳 ( 細胞,ニューロン,脳内プロセス )
との連携をより直接行うバーチャルリアリティ
の関連市場を視野に入れない事もまた 営業上の失策と言えるでしょう
( それが;ニューロコンピュータ,量子コンピュータ;とセットになる可能性をも ) .
まあ一見突拍子もない話を続けるのを次回以降に譲るとして ,
>それに時代はより疎結合へと向かっている。XMLのことです。
のレベルでの結合が進んでいる事は事実でしょうが ( TADも進んでいるのか ? ) ,
その事が即ち 低レベル分散システムの衰退を意味する事の根拠になる
という事は到底ないでしょう
( Be名無しさん , あなたは `` その事が即ち '' と述べていませんが ) .
( CORBAなりを実装した ? ) Jiniなり と JAVA の組み合わせ に価値があるとするならば
( Jini機器はJAVAのオブジェクトとして振る舞う事が可能 ) , 同じ意味で ,
分散OSベースサーバ と それに対してオブジェクトの設計の相性がいいクライアントOS
の組み合わせ には価値があるという事になるでしょう
( この組み合わせの利点はそれだけではないですが ) .
仮にそうでないとしても , 分散オブジェクト技術が組み込まれたクライアント機器
がIPV6なりのもとで星の数ほど稼動する状況においては ,
それらのハブ空港 ( ハブ都市 ) としての分散OS ( 的 ? ) サーバシステムは
少なくともかなり有用でしょう . 終了はsageでネ
■□■□■□■□終了■□■□■□■□ 〃 _`__
,,-=-、、l{,_'´..._ `ヽ、、
〃. ',.´二W´- ‐-`\ \ヽ、___
_{l,'.'´ 、 ヽ ヽ ヽ彡k、ヽ\
.//`/ i l. \ 、ヽ `、 i彡}ヽ`' ´ ▲女優,アイドル、脱がしました▲
. /| / i { |l {\ {ヽ、_!..ヽ」_/} .}./ |__〉、
\l.{. l.ヾ _.ゝ_土. ゝ -'fT;;ヽ,| lテ}| ||__〉
/iヽゝヽ/{~);;:l {:..''ノ'ノノ|{ノ |_!!女優,女子高生のエッチ画像ばかりを厳選収集!スクール水着,女優,画像ばかり。
.|_|l」ヽ. ヽ ゞ‐' 、  ̄`ノレヽソ|
(.ソ.ゝ -- /' {=}ノ ◆アイドル画像秘宝館◆
(=| l へ、 /ノノ((.)). http://www.futomomo.com/netidol/idolhappy/maki/
((!)ヾヽヽ` ;.- ' ´ |'' ''"'´◆アイドラー◆
`~^``/'l ゜>\_ http://www.futomomo.com/netidol/idoler/megu/
, -‐〃"´ |___/ >- 、 ◆セーラー服◆
/ ./〃 |=/ 〃/ \ http://www.futomomo.com/netidol/sailor/miku/
/ | ||, ‐-、_,...!、/_ ,..、 .〃/ ヽ fgggght あーーーーーーーーーーーうざい
うんちくは公でやってくれーーーーー!
実力があるならここでやるなあーーーーーーー デムパはどっかいってくれ
お前の話は抽象的&妄想だ その見解は勘弁してくれよ。
ちゃんと使えてるやつに
こんなやつや
マルチブートでごねたりするやつはいないんだからさー。 JavaだよJava。もしくは.NET。
分散OSなんていつになったら実用的になるか分からない
ようなものじゃなくて、今、目の前にあるものでやろうぜ! この板もうなくなってくれ。目障りだ。
このスレとともに、この板を終了させたい。 私もそろそろ疲れてきたし , 話を戻してまとめに入ろう .
所で私に残された時間は後1024年もないだろう .
愛すべきダダこね消防な人には悪いが
今日踏み出す事ができる一歩を踏み出す事を怠る訳にはいかない . 音楽というモノがある .
それは感情や細胞や分子のレベルの互換性に立脚するコミュニケーションメソッドと言えるだろう .
それは植物にさえ通用すると言われる .
BeOSがpervasive_multithreadingによって細かいスレッドを制御できるとすると
それをアウトソースする事も夢ではない .
その透過性を武器にして前述した `` 融合 '' を実現させれば
そのシステム全体がBeOSとなる .
人工生命を応用した低レベル分散システムが感情のレベルのドライバとして機能した時
メディアOSの計り知れない本領が発揮されるだろう .
因みに , 私が先日バーチャルセックスをとりあげた意図は二つ , それと市場の要求度だ . さて第一章の結論だが , どれにしよう ? :
1. ゲイツさんに任せていては生まれる筈の広大な市場が死産となるかも知れない .
2. BeOSを生き延びさせる必要がある .
3. 私にちょっかいを出す人を含む皆さんは確かな目を持っている .
4. Javaも進化していい線まで行くかも知れない . 呆れを通り越して、お笑いの域に達しておるな >Dempa 2。
びーの未来はともかく
選択できるってことが大切。
押し付けのOS有り難がっているようじゃ情けない。
みんなと同じで安心なんて恥ずかしいよね 9. やあ皆さんお揃いで . すーぱーおなにーショー ( 満員御礼 ) が一息ついた所で差し入れ です .
ttp://artr.com/cg/kana.jpg
>>118
おっyokoteちゃん後わ任せたyo ! .
FreePascalさんいつ来るのかな . 今来ればオイシいかもyo ! . 自覚を再三促したのに、徒労だったらしい ウツダ サイナラ sage忘れて再ウツ
■□■□■□■□ THE END ■□■□■□■□ ======================
デムパは無視。
このスレッドは廃棄ということでお願いします。
====================== aperiosってx86で動くものってある?
なんか開発環境から作り直してるあたり使ってみたいんだけど。 Sonyの人がやってるからソースは出してくれないかw
BeOSなんてどんなに先進的でもソースがないんじゃな、用はねーな Linuxデハァハァ(;´Д`) シテロ! >>126 ところでさ、Beご自慢の(笑)C++ のAPIなんだけど、常識的に考えると
C++むき出しのAPIなんていうのはおっそろしくて考えられない。処理系に
よる呼び出し規約の互換性とかFragile Base Classの問題はどうなってん
の? ずっと疑問だったんで、誰か教えてちょうだい。 >>130
こんなところで聞いても時間の無駄。
あるOSのユーザーとして自己主張することしかできないやつしか
いないんだから。プログラム板で聞いた方がいいかもね。 >>130
>常識的に考えるとC++むき出しのAPIなんていうのはおっそろしくて考えられない
なんで? (反論があるわけじゃなくて純粋な質問)
>処理系による呼び出し規約の互換性
どんな問題があるのかすら知らないので教えてくれるとうれしい。
>Fragile Base Class
http://www-classic.be.com/aboutbe/benewsletter/Issue79.html#Insight
http://www.st.rim.or.jp/~osada/translation/developers/BNL_articles/Issue79-insights-j.html(日本語訳) >>130
この辺りの話は何度となく話題になっていますので、BeDevTalkあたりの
アーカイブを読んでみるとよろしいかと。 >>134
Thanks! FBC問題についてはどういう方針で臨んだのか大体わかったっす。
根本的な解決策はないから互換性は「できる限りは確保したい」てことね。
「賭け」とか「どこまでいけるかはわからない」とか、それでいいのか、て
感じだけど。
>処理系による呼び出し規約の互換性
C++は言語仕様が複雑でCなんかと比べると実装の差が処理系によってずっと
大きい(仮想関数の実現方法とか)から、特定の処理系で構築されたブラッ
クボックスのフレームワークをパブリックなAPIにするのは問題がある、と
いうことです。ただこっちの問題は解決可能だし、実質CodeWarriorしかな
いから問題じゃなかったのかもしれない。
で、C++のクラスインターフェイスをそのままAPIにすると、これらの問題を
隠しきれないのでおそろしいといったのです。普通はOSのAPIとは別にサポート
フレームワークとしてソース付きで公開するか、実装はC++にしても手続き型
の言語(Cとか)用のラッパをかませるか、どちらかでしょう。
JavaやObjective-Cみたいにダイナミックなバインディングをサポートする
言語なら問題は少ないんだけど、それよりもC++の効率を採ったということ
でしょうか。あんまり将来を見据えた設計とはいえないような。 デンパさん、どうしてますか?
マジで心配です。返事して下さい。 今はどこでデムパ飛ばしてるんだ?
おい、デムパ野郎出てこい!