トップページ⇒unix
1001コメント272KB

Sun Microsystem 最大の遊撃

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2005/12/08(木) 17:43:05
今更「オープンソース」とか言い出したり、
　…でも「OpenSolaris-Closed-Bins」って一体…（´Д`;）

今更「Ultra20」とか言い出したり、
　…でも「"Ultra"SPARCではなくOpteron」って一体…（´Д`;）

Fujitsu製造のSPARC64V,
AMD製造のOpteron,
TI製造のNiagara(UltraSPARC T1)などと矢継ぎ早にCPUを模索しているが、
これは縦読みで、製品群が"FAT"になる暗示か？w

【前スレ】
Sun Microsystems 最後から二番目の真実
http://pc8.2ch.net/test/read.cgi/unix/1127872934/
0453名無しさん＠お腹いっぱい。2006/01/10(火) 17:55:33
>>449
静電容量を大きくするのにコストがかかる。
0454名無しさん＠お腹いっぱい。2006/01/10(火) 19:07:47
そんなところにはコストはかからんでしょ。
0455名無しさん＠お腹いっぱい。2006/01/10(火) 21:31:10
製造コストが減るし、
静電容量を確保するための技術開発も不要になる。

http://pcweb.mycom.co.jp/articles/2005/12/08/iedm2/

Infineonは30fF
Samsungは25fF
0456名無しさん＠お腹いっぱい。2006/01/10(火) 23:14:00
> そんなところにはコストはかからんでしょ。
半導体の話になると、頓珍漢な事を言い出す奴が多いな。
大気圏外ネタとか。
0457名無しさん＠お腹いっぱい。2006/01/10(火) 23:37:24
【エラー】メモリを語ろう【大気圏】
でも立ててそっちでやってくれ
0458名無しさん＠お腹いっぱい。2006/01/11(水) 00:27:38
セル容量はチップ面積(==コスト)に直結する。
放射線はパッケージの材料から出る。高純度の材料は高い。
0459名無しさん＠お腹いっぱい。2006/01/11(水) 01:04:38
>>456
意地でも ECC 必須の結論に誘導したいヤツが 1 名だろ?
それもトンチンカンな状況説明で。
0460名無しさん＠お腹いっぱい。2006/01/11(水) 04:56:23
>>459
「備えあれば憂いなし」ではあるけどな。
0461名無しさん＠お腹いっぱい。2006/01/11(水) 07:42:34
損部レ炉、損部レ炉〜
0462名無しさん＠お腹いっぱい。2006/01/11(水) 12:48:33
>>460
過剰な備えは懐が憂うよ！
0463名無しさん＠お腹いっぱい。2006/01/11(水) 14:24:00
いつでもrebootｵｹな環境ならECCは過剰かもな。
信頼性という言葉が出る環境でRAMまわりにECCも無い
ようでは話にならん。
0464名無しさん＠お腹いっぱい。2006/01/11(水) 15:33:11
スレ違いだけどちょうど今月の Design Wave に宇宙衛星の品質保証の記事あるよ
http://www.cqpub.co.jp/dwm/Contents/dwm0099i.htm
0465名無しさん＠お腹いっぱい。2006/01/12(木) 02:15:50
ECCが不要だとは言わないよ。

ECCの目的は、
第一にメモリにエラーが発生していないことを確認できるようにすること
(EC機能がなければ、エラーが発生しているかどうか、チェックする術がありません。)
第二に万が一エラーが発生していた場合に、リカバリできるようにすること

頻繁に化けるメモリでもECC使えば安全に使えるというのは間違い。
0466名無しさん＠お腹いっぱい。2006/01/13(金) 15:57:37
なんかネタ出してん
0467名無しさん＠お腹いっぱい。2006/01/13(金) 16:46:43
FedoraがSunのJava推奨してないのは何故？
0468名無しさん＠お腹いっぱい。2006/01/13(金) 18:46:55
プロプライエタリだからでしょ。
0469名無しさん＠お腹いっぱい。2006/01/13(金) 19:20:28
それだけの理由？
0470名無しさん＠お腹いっぱい。2006/01/13(金) 20:44:29
Red HatがIBMと仲良しだからだろ
0471名無しさん＠お腹いっぱい。2006/01/14(土) 17:20:32
ビノッド コースラ写ってるw ビートルズ赤盤青盤かよ!w
0472名無しさん＠お腹いっぱい。2006/01/14(土) 17:59:06
サンの創業メンバーが再会--アップルとの秘話も明らかに

http://japan.cnet.com/news/biz/story/0,2000050156,20094390,00.htm

結構面白い。
0473名無しさん＠お腹いっぱい。2006/01/14(土) 22:14:20
IntelMacになればx86なOpenSolarisが動く

の？
0474名無しさん＠お腹いっぱい。2006/01/14(土) 22:22:15
マクはビッグエンディアンじゃないの？

大口顧客がいまだにSunのSparcマシンを手放さないのも
過去のバイナリデータがSparcマシンじゃないと（簡単に）読めないから
その過去のバイナリーデータをLinuxで活用する為に
専用のソフトをリトルエンディアンに書き直して
ちゃんと動く様にするのはあまりにもコストがかかりすぎる
それよりはSparcマシンを保守維持する方が安上がり

とかの事情もあるしね
0475名無しさん＠お腹いっぱい。2006/01/14(土) 22:33:17
エンディアンネスの修正なんて嵩が知れている。
それと、BE/LE は個別の CPU の仕様だから OS は関係無い。
0476名無しさん＠お腹いっぱい。2006/01/14(土) 22:41:00
> それと、BE/LE は個別の CPU の仕様だから OS は関係無い。

そうとも言い切れん。
VMS/OpenVMS は Little Endian だけだし、
HP-UX は Big Endian だけだし (Itaでも Big Endian)、
Windows は Little Endian だけ (おかげで POWER を
Little Endian モードで動かすとか、SPARC に Little Endian
モードを加えるといったことまで)。

もちろん bi-endian な OS も沢山あるけどね。

> エンディアンネスの修正なんて嵩が知れている。

ひとつひとつの修正は簡単だけど、ソフトウェア資産が多いと
嵩が知れていると断言できるほど少ない量でもないよ。
0477名無しさん＠お腹いっぱい。2006/01/14(土) 22:51:59
そりゃ単一アーキの OS はそうでしょう。Itanium が Bi Endian なのは知らなかった。
SunOS はエンディアン依存していないし、Darwin もエンディアン非依存だよ。
0478名無しさん＠お腹いっぱい。2006/01/14(土) 23:21:47
SunOSがエンディアンに依存してないってどういう意味？
確かSPARC V9の%pstateあたりにエンディアン指定ビットがあったと思うけど、
あれを切り替えて動かすことが出来るの？
0479名無しさん＠お腹いっぱい。2006/01/14(土) 23:26:18
SPARC/x86両対応ってことでしょ
0480名無しさん＠お腹いっぱい。2006/01/14(土) 23:41:15
誰が作ったんだかわからないプログラムが
大量にビッグエンディアンバイナリをはき出して
そのバイナリはやはり誰が作ったんだかわからなプログラムで解析されて
あのたがたの生活を支えているのかもしれない
0481名無しさん＠お腹いっぱい。2006/01/14(土) 23:44:14
>>474
ユーザーデータのエンディアンは CPU がなんだろうとアプリで意識せなあかんがな。
「マクは」って何指して言ってるのか知らんがあんたが心配しているようなコストは
ないと思うよ。
0482名無しさん＠お腹いっぱい。2006/01/15(日) 00:25:29
>>474
あと、その言い方だと構造体のパディングもだろうな。そりゃ手抜き過ぎだよ。
コンパイラのオプション変えただけで変わったりする。そこまでベンダーの面倒見の範囲には
入らん。
0483名無しさん＠お腹いっぱい。2006/01/15(日) 01:25:49
いや、そこまでベンダーが面倒みてるからこそ、現在の
Wintel の繁栄があるんだと思うけどね。

Mac は忠誠心の強いユーザが多いから、なんとかなるのかも。
普通、そんなに忠誠心とかないから、エンディアン変更する
だけで、他のベンダーの草狩り場になりかねんような。
0484名無しさん＠お腹いっぱい。2006/01/15(日) 01:29:58
いつの時代の話やねん。MS-DOS?
0485名無しさん＠お腹いっぱい。2006/01/15(日) 01:37:01
そういう話（風説）自体が FUD なんだよな。マルチプラットフォームなアプリなんで
今ではそこらじゅうにあるだろ? そんな話持ち出すんなら文字コードとかパス記法とか
リソースフォークだの考えないといけないことは他にもいろいろあるよ。
で、それを解決した実例がそこらじゅうにソースコードでごろごろあるじゃん。
0486名無しさん＠お腹いっぱい。2006/01/15(日) 01:50:09
そういうのはゴロゴロあるが、そうじゃないのもゴロゴロあるのでは？

最近は RDB+Javaアプリケーションサーバ+Webって開発ばかりだから、
そうじゃないのは、かなり減ってきてるとは思うけどね。

ちょっと前に作られた、C/C++ アプリってのがヤバげ。
gdbm や Berkeley DB を使ってるのも、データの中身がバイナリだと
ヤバい。
0487名無しさん＠お腹いっぱい。2006/01/15(日) 02:09:00
NeXT step が x86 に対応したとき、
エンディアンを吸収するクラスが作られなかった？

名前は確か、NSStream。


0488名無しさん＠お腹いっぱい。2006/01/15(日) 02:11:39
XDR とか。古い話だ。1980 年代の話題。
0489名無しさん＠お腹いっぱい。2006/01/15(日) 02:35:52
おまいらｵｯｻﾝ
0490名無しさん＠お腹いっぱい。2006/01/15(日) 02:55:14
知らんのなら勉強しとけ。あと htonl とかな。ネットワークやったことあるやつなら
ジョーシキなんだが。
0491名無しさん＠お腹いっぱい。2006/01/15(日) 03:12:14
>>472
「Apple にユーザーインタフェースの統合を持ちかけたとき」って、いつごろだろ。
OpenStep のことで、ひょっとして NeXT と勘違いしてる?
0492名無しさん＠お腹いっぱい。2006/01/15(日) 03:49:01
以下の２つが混乱。
・同じバイナリデータをlittle/big endianのCPU上で扱う
・コンパイルしなおせば別のendian上で動く。データのendianも代わる
0493名無しさん＠お腹いっぱい。2006/01/15(日) 06:50:37
>>472
昔のミニコンとワークステーションの関係は
今のRISCサーバーとPCサーバーの関係みたい
SUNもDECのようにつぶれるのか？

＞DECは、Sunが初期に狙いを定めていた一番の競合相手で、
＞Sunが成功を収めたおかげでDECがその犠牲になった。
＞「VAX 750は、80Mバイトのディスクドライブと2Mバイトのメモリを搭載し、
＞1秒間に100万回の計算が可能だった」とJoyは述べ、
＞さらに「Andyの設計したマシンは標準的な部品を使っていたので、
＞(Motorola) 68010プロセッサを搭載した時には、10分1の価格で
＞同じ処理性能を持つマシンを実現できた。
＞あれは本当に革命的だった」（Joy）
0494名無しさん＠お腹いっぱい。2006/01/15(日) 07:01:34
SunとAppleは合併すれば相乗効果が高いと思う。

得意分野も補完関係にあるし、ともにコンピュータ専業の老舗で
Microsoftから多額の和解金を勝ち取ったwという共通点もあって
企業統合は無理なく出来るだろう。

そして、今こそ家庭向けNC(NetworkComputer)構想の復活だ！
0495名無しさん＠お腹いっぱい。2006/01/15(日) 07:55:24
しかし、AppleはIntelと組んでいるので、
いまさらAMDと組んでいるSunと組んで、
ワークステーションを共通ハードにする
なんてこともできない。
0496名無しさん＠お腹いっぱい。2006/01/15(日) 09:16:24
Intel と AMD なんてソフト屋からすればどちらでも同じなわけだが
0497名無しさん＠お腹いっぱい。2006/01/15(日) 09:40:01
>>491
OPENSTEPは、AppleやIBMも参加する計画があったよ。

0498名無しさん＠お腹いっぱい。2006/01/15(日) 09:41:44
>>495
IntelMacではOpenFirmwareを辞めるという噂があったがどうなったんだろ?
0499名無しさん＠お腹いっぱい。2006/01/15(日) 09:53:25
>>498
辞めたよ
0500名無しさん＠お腹いっぱい。2006/01/15(日) 11:03:47
forceが動かなきゃ嫌だ
0501名無しさん＠お腹いっぱい。2006/01/15(日) 11:09:59
ってことはbios搭載のただのPC-AT互換機か？
0502名無しさん＠お腹いっぱい。2006/01/15(日) 11:19:52
forceはjediじゃないと使えないから民生品に載せるのは無理かつ無謀かつ無意味。
0503名無しさん＠お腹いっぱい。2006/01/15(日) 11:23:57
>>501
EFI
0504名無しさん＠お腹いっぱい。2006/01/15(日) 12:04:06
>>496
ハードベンダのSunにとっては、重要なことですよ。
0505名無しさん＠お腹いっぱい。2006/01/15(日) 12:37:44
force ? forth?
0506名無しさん＠お腹いっぱい。2006/01/15(日) 15:38:34
>>500, 502
綴り分からないならフォースって書いとけばよかったのに・・・・よくないか
0507名無しさん＠お腹いっぱい。2006/01/15(日) 15:39:35
ネタにマジレスは無粋なり。
0508名無しさん＠お腹いっぱい。2006/01/15(日) 16:40:11
...
0509名無しさん＠お腹いっぱい。2006/01/15(日) 17:34:21
マジにネタレス
0510名無しさん＠お腹いっぱい。2006/01/15(日) 20:46:45
ｶｯｺ(・∀・)ｲｲ!!
0511名無しさん＠お腹いっぱい。2006/01/15(日) 22:13:27
>>493
なんでこんな短絡バカが多いのか。PC の方がデキ悪いしもう消えかけだろ。
BIOS が退場して EFI からビルトイン NIC と SAS が制御できるんならまるっきり
1980 年代のワークステーションなんだよ。死んだのは PC だ。
0512名無しさん＠お腹いっぱい。2006/01/15(日) 22:30:10
>>494
船頭が多いと船が山に登るからな。Sun 側はともかくとして、ハゲは自分がタイショウじゃ
ないとやってけない性分だろ。自分でよくわかってると思うな。
0513名無しさん＠お腹いっぱい。2006/01/15(日) 22:45:57
クソ BIOS の退場は確定した。実質引導渡すのが Apple になりそうなのが興味深いが。
ここで EFI の出鼻をくじければ IEEE 1275 OpenFirmware にもチャンスがある。
0514名無しさん＠お腹いっぱい。2006/01/15(日) 22:51:46
SunでOBPというとハードウェアのチェックぐらいにしか使えない印象があるけど
BIOSでハードウェアのチェックっていうと最近流行りのBIOS built inのmemtest86ぐらいだもんな
0515名無しさん＠お腹いっぱい。2006/01/15(日) 22:57:52
>>511-513
もっと熱く語ってくれ
0516名無しさん＠お腹いっぱい。2006/01/15(日) 23:12:52
あの座談、Appleに逃げられた感が漂ってるのが笑えるんだが…
0517名無しさん＠お腹いっぱい。2006/01/15(日) 23:29:13
GUI については Apple とくっつくより XEROX からあぶれた連中をかき集めるべきだったな。
XEROX から Apple へ行った連中も引き抜けばよかった。けどハゲは要らんだろ。
ま、当時の Sun にはそんなカネないだろうけど。
0518名無しさん＠お腹いっぱい。2006/01/15(日) 23:52:37
UIが提唱したOPENLOOKはXEROXと組んでなかった？
当時のMacのGUIより優れてたと思うけどな

それにSUNが開発したGUIのNeWSはX Windowの普及で出荷されず
機能を縮小してX Windowに対応したOpenWindowが出たと本で読んだ
X Windowが普及しなければUNIXのGUIはもっとマシになってたかもね
0519名無しさん＠お腹いっぱい。2006/01/16(月) 00:01:28
> それにSUNが開発したGUIのNeWSはX Windowの普及で出荷されず

確かNeWSを開発したのは、JavaのGoslingだったような？
で、結局Xとくっつけて、X11/NeWSとして出てきたような気がする。
Xも動き、NeWSも動きで、いいじゃん？ってなもので。
そんで、NeWSはDisplay Postscriptかを使用してたので、PostScriptを
そのまま画面に表示できた。
0520名無しさん＠お腹いっぱい。2006/01/16(月) 00:04:10
Network extensible Window Systemはちゃんと出たぞ。
OpenWindowの一部。Postscriptベースの拡張。

Suntoolを出す→X Window Systemに負ける。
OpenWindowを出す→CDEに負け、Sunの標準デスクトップがCDEに。
Xを拡張したNeWSを出す→Adobe Display PostscriptにPostscript部で負けて撤退。

TNT(The NeWS Toolkit)は撤退と同時にオープンソースにしたな。
0521名無しさん＠お腹いっぱい。2006/01/16(月) 00:05:25
座談読むと、アップルのスカリーだっけか、ジョブズを追い出した、
あの人って、全然ジョークつうじなそうね。

で、ベクトルシャイムってバリバリのエンジニアって思ってたけど、
サンを立ち上げる前に学生の身でありながら、年収５０００万も
自分の仕事で儲けてたなんて、逆にビジネスの才の方がある人なのね。
0522名無しさん＠お腹いっぱい。2006/01/16(月) 00:05:26
> Display Postscript
これってどういう機能なの？
Postscriptのインタプリタがどっかに内蔵されてるの”
0523名無しさん＠お腹いっぱい。2006/01/16(月) 00:09:13
>>522

JavaみたいにPostscriptのインタプリターエンジンが入っていて、
実行時に解釈してイメージに変換し、表示してた。

Postscriptを中間言語に使うことで、画面表示と印刷イメージとを
一致させていた。

ような覚えがある...（昔のことだけど..）
0524名無しさん＠お腹いっぱい。2006/01/16(月) 00:09:40
>>519
そう。ゴスリンがやってた。その後NeWSご破算になって、Oakやり始めた。
0525名無しさん＠お腹いっぱい。2006/01/16(月) 00:11:28
Goslingって、こういうの好きなんだろうね。
インタプリターを搭載したモノが。

Gosling Emacs (Lispエンジン)、NeWS (Postscriptエンジン)、
Java (JVM)って結局ルーツが一緒だもんね。

0526名無しさん＠お腹いっぱい。2006/01/16(月) 00:12:31
Display Postscriptを最初に搭載したシステムがNeXT
0527名無しさん＠お腹いっぱい。2006/01/16(月) 00:15:13
>>522
そ。Windows systemのコアにPostscriptのインタープリタがある。
しかも拡張されていてforkしたりできるからwindow systemのサーバ内で、
複数のプロセス@DPが並行動作できる。

で、TNTってPostscriptで書かれたオブジェクト指向のtoolkitがあった。
オブジェクト=PostscriptのディクショナリというObjective-C的なもの。

自分は時計やbiffをPostscript&TNTで書いていた。

しかしAdobeが独自にDisplay Postscriptを発表したので失速。
0528名無しさん＠お腹いっぱい。2006/01/16(月) 00:17:00
>>526
後継はOPENSTEP→GNUSTEP
そしてMac OS Xですなあ。
0529名無しさん＠お腹いっぱい。2006/01/16(月) 00:20:05
>>523 >>527
なるほどよく分かりました
PostScriptのファイルを持ってきて
インタプリタに食わせるプログラムをしないとダメなのね
0530名無しさん＠お腹いっぱい。2006/01/16(月) 00:22:02
>>527

確か、その後でDisplay PostscriptをX11にいれて出したよ。
Postscriptの解釈で色々と違いがあったらしい。

PostscriptはAdobeがもってたからね。
0531名無しさん＠お腹いっぱい。2006/01/16(月) 00:23:24
>>529

とうよりは、Postscriptを直接食わせて、
画面に表示できるというメリットがついてたって感じ。

普通のコーディング(Xviewとか、Widgetとか)もできたと思う。
0532名無しさん＠お腹いっぱい。2006/01/16(月) 00:25:22
今でも X の起動スプラッシュに DPS って出て来るよ。
0533名無しさん＠お腹いっぱい。2006/01/16(月) 00:26:32
UNIX LikeなOSで一番優れたGUIを実現したOSがMacOS Xということでいいですか？
0534名無しさん＠お腹いっぱい。2006/01/16(月) 00:27:02
>>532

DPSになってからは、APIはAdobeのそれを
使うようになったので、Postscriptを表示するには、
そっち経由でやる必要があったと思う。

まだAPIはそのまま入っているんじゃないかなぁ？
必ず互換は維持するので。
0535名無しさん＠お腹いっぱい。2006/01/16(月) 00:28:16
>>530
そう。
ただしAdobe Display Postscript(のAPI)は、外の世界がObjective-Cだから、
事実上Display Postscript放棄になったね。SunはC bindingを作らなかった。

正直SunのNeWSの方が野心的で、デザインも優れたいたと思った。
ただ他人のふんどしだからね。

今はJava抑えているけどね。
0536名無しさん＠お腹いっぱい。2006/01/16(月) 00:29:03
>>534
OPENSTEPだわね。
0537名無しさん＠お腹いっぱい。2006/01/16(月) 00:29:09
> 一番優れたGUI

たぶんGUIって人によるんじゃない？
商用だとMacかもしれんけど、Xがそもそもポリシーを分離したのは、
そこにあるのかも？（忘れたから違うかも）

こだわりのある人はたぶん自分で作ると思うよね、Xの世界だと。


0538名無しさん＠お腹いっぱい。2006/01/16(月) 00:31:30
>>535

DPSを使ったイメージソフトを作った覚えがあるので、
たぶんCから　DPSを呼び出せるはずだと思うけど？
0539名無しさん＠お腹いっぱい。2006/01/16(月) 00:35:44
>>529
Postscriptの印刷中間表現としたの在り方を強く意識しているようですが、
Postscriptはプログラミング言語でもあるので、
サブルーチンを登録したり、拡張機能でプロセス動かしたりできるわけです。
つまりwindow systemにJava RMIみたいことが出来るようになりました。
0540名無しさん＠お腹いっぱい。2006/01/16(月) 00:44:40
>>538
OLITにNeWS用の機能があったはずだけど、
それの下部レイヤーをDPSに書き換えたあまり推奨されてない互換機能じゃなかったかなあ。
そういわれてみると、この辺は良く覚えてないな。
TNTなくなってガックリきちゃったんで(w
0541名無しさん＠お腹いっぱい。2006/01/16(月) 00:47:07
>>539
図形表示以外にうまい使い方があったんですか
何で流行らなかったか(または廃れてしまったのか)疑問です
0542名無しさん＠お腹いっぱい。2006/01/16(月) 01:34:05
>>541
ここの文字列をエディタに貼って.psでテキストファイルとして保存し、lprかgvに食わせてみて下さい
http://web.archive.org/web/20050313232234/www2.is.titech.ac.jp/~sadayosi/lab/h-takasi/ops.html
0543名無しさん＠お腹いっぱい。2006/01/16(月) 02:04:07
>>541
ビットマップ形式とか、もっと単純な描画システムと
比べて、はるかに複雑で重いから
DPSだと、文字ひとつ表示するのに、ベジェ曲線のデータを
元に演算して、それをピクセライズしてってしなきゃいけない
0544名無しさん＠お腹いっぱい。2006/01/16(月) 02:04:32
>>542
喰わせてみました
白黒のタイル状の床に浮いている玉が2つ表示されました
こんな短いコードでこんなことができるんですね
ビックリしました
0545名無しさん＠お腹いっぱい。2006/01/16(月) 02:06:42
>>544
今のマシンは速いからすぐ表示できるけど、当時のマシンだと
糞重い処理なんだよ
だから流行らなかった
0546名無しさん＠お腹いっぱい。2006/01/16(月) 02:08:04
>>543
たしかにめちゃくちゃ重いです
まるで3D画像のプレレンダーをしている感覚です
Solaris10をAthlon64で使っててマシンパワーはそこそこあるはずなのに
これ昔のSPARCだったら死ねますね
0547名無しさん＠お腹いっぱい。2006/01/16(月) 02:12:49
>>543
温故知新でなんとかならんもんでしょうか
VRMLなんかも今のパワフルなマシンならサクサク動くだろうから
もっと流行ればいいのになと思いますが
駄目っぽそうですものね
ひょっとしたら重いから夢があったのかも

今晩はいろいろ教えていただいてありがとうございました
少し休みます
またきますのでよろしくお願いします
0548名無しさん＠お腹いっぱい。2006/01/16(月) 02:13:49
>>547は>>545あてのメッセージです
すいません
0549名無しさん＠お腹いっぱい。2006/01/16(月) 02:31:33
gmwくれ
0550名無しさん＠お腹いっぱい。2006/01/16(月) 09:44:58
>547
MacOS X には DPS(Display PostScript) ではないけど
Display PDF が採用されとるよ
0551名無しさん＠お腹いっぱい。2006/01/16(月) 11:30:52
ま、設計が美しくても、その時その時の計算機の能力に合ってないと
誰も使わないので廃れてしまうという良い例でしたな。＞DPS

>>550
あれはあれで重いけどね。WindowsだとPentiumIII 1GHzもあればかなり
さくさく動くけど、G4 1GHzでMac OS Xは重い。
研究ならともかく、実用システムを作る以上は、今そこにある計算機で
現実的な速度で動くものを作らなきゃダメだよな。Goslingがどうも昔から
いまひとつパッとしないのは、その辺の意識に問題があるからだと思う。
0552名無しさん＠お腹いっぱい。2006/01/16(月) 12:22:01
JavaはJITやら動的コンパイルやらで、普通のコンパイラ言語(C++)よりも
早くなっているけどね。
0553名無しさん＠お腹いっぱい。2006/01/16(月) 12:26:19
Java信者乙。
サーバとして動くソフトウェアならともかく、クライアントで使うには
初動が遅いのが最大の問題なのよ。
■ このスレッドは過去ログ倉庫に格納されています