Sun Microsystems 最大の滝壷

**名無しさん＠お腹いっぱい。** · 2006/02/01(水) 18:32:00

NOW IN NAIAGARA!
"Rock" on the table?

【前スレ】
Sun Microsystem 最大の遊撃
http://pc8.2ch.net/test/read.cgi/unix/1134031385/

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 14:52:36

使われずに捨てられたLinuxのCDROMは一億枚以上だな

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 14:54:06

>SunのOpen Solaris戦略は成功するか
失敗した。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 15:35:46

ま、まだ早いよ。１年は頑張ろうよ

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 15:41:41

1年でもだめだろ
成果がでるまでに3年はかかるんじゃないか

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 15:49:40

成果がでるまで生き残れよ、Sun…

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 15:49:50

おまえらががんばれよ。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 16:09:20

対応デバイスがLinuxと比べて少ないからなぁ。
ギ蟹もnevadaじゃないとだめだし。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 16:46:30

もうLinuxでええやんか

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 17:57:59

>>345
議事の前提となってる知識に問題があるね。Java について。まず、ゴスリンやジョイ等古参の
ソフト開発者（研究者）は昔の Unix 周辺の研究者と同様分散システムにずっと興味が
あったこと。JavaSpaces から JAXTA への方面ね。今だと P2P 方面、と言った方が
わかりやすいか。
それと、少なくともジョイは Unix の「C++ の改良版」のような言語での書き直しを
したい、この先はプログラミング言語を軸に進むべき、みたいなことを 1980 年代後半に
言っているということ。
分散システムの基盤として Java を位置づけていることから、Java を手放さないのは、
妙な仕様を入れられたくないのがいちばん底にある理由と思う。
セットトップボックス用の云々... という面白く脚色された小話を 100% 真に受けて
その上に根拠を置いてるのはちょっといただけない。Emacs や NeWS をやった Lisp の
大物があとさき何も考えずに Oak をやってた、と思ったら大間違いと思うね。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 19:23:58

でも、Linuxのドライバ対応には感心するよね、確かに。
あれって、Solarisにポートするのって大変なものなの？

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 19:45:10

Looking Glassはそれなりにオリジナリティを感じたが
Novellのはアレだな

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 20:57:37

SPARCオワタ
というかUNIX WorkStation自体終わった。
これからはLinuxとMac OS Xの時代。
UNIXの環境はミニコン→WS→PCと変わってきたが、
ここ数年はWSからPCの過渡期だったんだな。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 21:12:15

ttp://pc.watch.impress.co.jp/docs/2006/0208/sun.htm
既出？

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 21:26:04

>>361
Windows一色の時代の間違いだろう。UNIX陣営は腰抜けぞろいだし、
Mac OS Xなんて悪い冗談でしかないな。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 22:14:39

「パソコン」てカテゴリーは今後急速に置き去りにされる対象だよ。
末端はソフトウェア的には今よりずっと簡易なものになる。MS-Windows みたいな
応用の効かない OS は不要。あとはヘッドレスな形態の筐体で計算リソースや
メモリリソースをどう配置していくかの問題。「ホームサーバー」とかいうのも
まあそのうちに含んでいいかと。この場合も応用の効かない MS-Windows は不要。
居場所はないね。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 22:55:33

>>361
>というかUNIX WorkStation自体終わった。
>これからはLinuxとMac OS Xの時代。

MacOS Xマシンは、実態としてはUNIX Workstationだろう。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 22:55:57

>>361
Niagara2 はデスクトップ機に応用してメリット大と思われる。
科技ファームの構成要素にも有用と思われる。これから先はいわゆる RISC が有利。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:26:30

デスクトップには向かんよ。
シングルスレッド性能が重要だから。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:31:09

マルチスレッドにしたら効きそうなアプリはごろごろあるよ。マルチメディア方面特にね。
ワープロも効くんじゃね? Web ブラウザーも効くんじゃね?
逆に、シングルスレッドの性能差がすごく効くアプリって少ないと思うけど。
通常用途じゃ。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:34:06

> マルチスレッドにしたら効きそうなアプリはごろごろあるよ。
> マルチメディア方面特にね。

エンコーダ／デコーダは確かに、わりとマルチスレッド向きだね。

> ワープロも効くんじゃね? Web ブラウザーも効くんじゃね?

これは全然向かん。
top で見れば分かるけど、瞬間的にCPU能力を必要とするだけなので、
シングルスレッド性能が重要。

> 逆に、シングルスレッドの性能差がすごく効くアプリって少ないと思うけど。

甘い。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:35:23

>>344
僕はいわゆるホビーユーザーで初心者なので勘違いも甚だしいかもしれないけど、
pkgsrcをダウンロードしたらでかいし、./bootstrapしたらいきなりコンパイルして勝手にインストール始めたから
キモくて即刻消した。
BSD使ったこと無くて、solarisのパッケージみたいなのを想像していたからびっくりした。
BSDのユーザーさんって、あんな勝手にダウンロードしてコンパイルするシステム気持ち悪く無いのかな?
その後、必要だったdvdrecordのコンパイルに成功したから、もうどうでもよくなった。
やっぱりmakeして自分の好きな所にインストールするのが一番だと思ったよ。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:38:34

Solarisしか動かんデスクトップマシンなんて考えただけでも使い難そうだな。
Window$で充分だよ。
痰壷は鯖だけでいいよ。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:40:41

>>370
基本的には、/usr/pkg/ 下にしか入らないよ。一部例外はあるけど。
pkg_info -L <パッケージ名> で入ったファイルの一覧が出る。
それと、bootstrap 終わったら、後のは一般ユーザーでやる。bmake install で
コンパイル後、実際のインストール直前に root パスワード聞かれる（su が走る）。
...って、事前情報ないと確かにキモいかも。書いてなかった?

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:44:57

>>370
> あんな勝手にダウンロードしてコンパイルするシステム気持ち悪く無いのかな?
元になった FreeBSD の ports の発想からしてそうなんだけど、手作業で落としてきて
（必要ならパッチ当てて、）コンパイル、導入するのを自動化しただけのものなんだけどね。
多少知識が付けばそれぞれの作業を別々にも実行できるよ。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 23:45:01

>>369
だからヘテロジーニアスマルチコアっていうものが考えられているんだよね。
AMDに期待かなぁ...

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:03:56

>>369
> top で見れば分かるけど、瞬間的にCPU能力を必要とするだけなので、
それは今のプログラムがそいういう風に書いてあるからだと思うけどなぁ。

>> 逆に、シングルスレッドの性能差がすごく効くアプリって少ないと思うけど。
> 甘い。
実際に、オフィスワークや一般の人が家庭で使ってる用途で、Pen4 の 3.6GHz なら
快適だけど 1.8GHz だと不便で使う気もしない、なんてもんはあんまり無いと思うけど。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:04:38

>>372さん
親切な回答ありがとうございます。
でも、ほんとにビックリしました。
得体の知れない物とか入ってきたらどうするんだろう・・・・
自分は勝手にダウンロード&インストールするのはもうpprosvcで十分です。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:20:12

>>375
もしお前の思うとおりなら
世の中、ナイアガラもどきのマルチコアが
あふれているんだがな

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:21:50

>>376
んー、一応、各パッケージのディレクトリ下の distinfo にチェックサムがあって
すり替えのチェックはしてますけどね。一致しないと止まります。
自分で取ってきたい場合は、そうですねぇ、例えば FETCH_CMD=/usr/bin/false とか
/etc/mk.conf に書いておくとファイル取得にコケますから、エラー表示を見て
自分で取ってくる、という方法はあります。
慣れますけどねぇ。楽だからw
mk.conf については pkgsrc/mk/defaults/mk.conf 参照してください。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:23:19

>>377
ふっ、もうすぐそうなるさ。
それまでに Sun がどれぐらい稼げるのか、がとりあえずポイントだな。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:49:51

make fetch-list を実行すると、ダウンロードするスクリプトを
吐いてくれるから、それを実行しておいてまずダウンロードして、
中身を確認して、それから make するって手もあるけどね。

でも、distinfo の SHA1/RMD160 検査で、まあ十分だと思うけどなあ。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 00:53:16

>>379
シングルコアの性能もそこそこいいマルチコアCPUじゃないとね。
Niagaraをシングルスレッドで使うと笑っちゃうよね。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:00:33

>375 って天然物?

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:01:03

まあ今の Niagara だとそのままは難しいかもね。Niagara2 には期待。
ところで、コアあたりのスレッド数可変にしたりするのは難しいかな?

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:04:32

そのうちインテルのマルチコアでいっぱいになります。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:05:35

>>383
>コアあたりのスレッド数可変

縮退で良いなら今でも可。単にスレッド殺すだけだけど、その分パイプラインは空くよ。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:10:06

>>384
ずっと繰り返し繰り返し出てるんだけど... インテルじゃ有効利用できる OS がないよ。
つまり作ってもムダ。ざんね～ん。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:12:06

>>385
つまりそれは、FGMT 的に 300MHz 4Threads が 600MHz 2Threads になったりする、と
いうこと?

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:12:15

OS は Solaris/x86 でいいじゃん。
それより、Niagara くらいシンプルなコアだと、x86→内部RISC変換に
必要なトランジスタが馬鹿にならんことの方が問題だと思われ。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:28:41

Intel CPUのみもしくは自社x86機以外で多コア使う場合有料の
アクティベーションが必須になったりしてｗ
まぁOSそのものの普及を考えた場合は無制限にライセンス出した方がいいでしょうが
H/Wの売上とOS保守契約等々のサービス売上のバランスでどの程度
Sunが耐えられるかの方が問題かも
ただSunは全てのSunのソフトウェアはOSSにするって言ってるから
Solaris/SPARCに全てを賭けるという意気込みなんだろうなぁ

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:29:51

>>387
そのはず。明示的にオフラインにしなくても、LWP 数が少なければパイプラインに
空きが生じる訳だし、スレッド数を減らすメリットは無いと思うけどね。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:38:53

>>390
ふーん... それなら、別に「シングルスレッドだと笑うほど遅い」ってこともないんじゃないの?
300MHz 相当になるのかと思ってたよ。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:45:39

1.2GHz と言っても、OoO どころかスーパースカラーもないから、
Pentium-M 1.2GHz とかと比べると、かなり遅いと思うよ。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 01:49:16

>>391
設計上の選択で、パイプライン自体が短いし、演算ユニットもコア毎に一個だから。
その分、マルチスレッドだと超っ速だよ。電気喰わないし、熱も出ないし、サーバには最適。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 02:01:42

いいねぇ。マルチメディアエンコードやゲームとコンパイルにしか性能の出ない
非効率巨大 CPU を一般用計算機に強要するメーカーとはぜんぜん違うねぇ。
大鑑巨砲主義はひっこめてもらいたいもんだ、ほんと。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 02:06:26

Intel は SMT で突っ走ると思ってたんだけどな。その為に DEC から特許を取得したらしいのに、
結局引っ込めちゃったね。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 02:17:50

メモリレイテンシ問題は今後も悪化する一方だから、
SMT復活の目はあるんじゃないかと思ってるけどね。
Niagaraみたいなのだと、FGMTで十分だけど、OoOの
CPUではSMTにするのが自然だし。

そこで疑問なんだけど、なんでOlympusはOoOなのに
CGMTなんだろうね。SMTを設計するのが面倒だったん
かな。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 03:15:52

業界的に SMT を採用しない／出来ない理由があるのなら俺も知りたいな。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 04:30:52

よく知らんけど、POWER5あたりは、SMTだと聞いたことがあるので、
別に業界的に採用しないとかできないとかいうことはなかろう。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 04:33:24

あー、でも富士通が採用しなかったのはIntelあたりがDECから
買って持ってる特許を避けたかったから…って可能性はあるかな。

富士通とIntelって、包括的クロスライセンス契約とか結んで
ないんだっけ。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 12:47:52

>>396
別にOoOでCGMTでもいいんでは？
SMTにしてもメモリアクセスでストールしてたら一緒だし

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 14:39:25

>>399
富士通が Intel 系のチップ作ったことって、ないんじゃない?

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 15:44:49

>>400
CGMTよりSMTの方が、原理的には並列度が高くできて、
演算器を有効利用できる==速いはず。

まあ、あくまで原理的な話で、どこかにスループットが
足りないところがあるような場合、CGMTの方がかえって
マシってなこともあるかもしれんけど。

>>401
セカンドソース契約とか互換チップとか作らなくても
クロスライセンスを結ぶことはありうるよ。
たとえば富士通はMicrosoftともクロスライセンス契約
を結んでるらしい。
ttp://japan.cnet.com/news/biz/story/0,2000050156,20068643,00.htm

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 19:14:06

IBM、Powerを2倍高速にする手法を開発
ttp://www.itmedia.co.jp/news/articles/0602/07/news070.html

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 21:33:50

CELLでAIXを動かすことも視野に入れているでしょう。きっと

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 21:46:44

>>402
OoOとCGMTだけで十分に演算器が埋まるので
シングルスレッド性能が落ちるリスクを冒してまで
ＳＭＴを導入するメリットがなかったとかじゃない？

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 22:33:23

シングルスレッド性能を優先したからだと思う

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 23:43:08

>>391
感覚的にはV120を使っているような感じ。測ったワケじゃないけど。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 00:00:22

なるほど。参考になりまする。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 05:12:45

>>401
>>402
昔の186/286の時代は、セカンドソースとしてライセンス生産していた時期もあったりする。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 10:21:10

>>409
> 昔の186/286の時代は、セカンドソースとしてライセンス生産

そういえば、186って富士通のFM16βでしか見た事がないが、
あれは富士通製だったのか？

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 16:01:30

T2000 てどれくらい出荷したんだろう。T1000 もそろそろ出るんだっけ?

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 18:19:22

>>403

IBMのCPU製造能力は凄いね。
富士通も、HPもCPUの製造はIBMに委託していたよね、確か。

SunもIBMにSPARCチップを作ってもらえば、設計を変えなくとも、
この製造技術で周波数が２倍にできるはず。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 18:27:53

>>412
富士通は自社生産。
HPもPA-RISCはＩＢＭだが今後はIntel。

AMDがＩＢＭと技術提携してるので
Opteronに生かされるかも。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 19:02:00

>>410
そうかも知れない。
16βはM68Kの予定がINTEL系にセカンドソース契約の関係でなったような
(記憶が確かならの条件付きだけど)

SPARCと言えば、昔の富士通の五重塔というイメージが…あるなぁ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 19:35:41

>>411
T1000は遅れてるね。年度内は難しいかも。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 20:32:25

Niagaraって中小規模のWeb鯖 or Javaアプ鯖用途でしょ。
Xeon搭載のマシンより安くて２倍くらい速ければ購買意欲そそるけど
そじゃないと売れないと思うよ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 20:34:47

Webサーバ用途だと、Xeonの 4倍以上速いベンチマーク結果に
なってますがなにか？しかも消費電力は半分。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 20:52:01

ソースきぼん。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 21:06:23

前スレから。
SPECweb2005 で、Niagara 1CPU が、Xeon 2CPUの 2.8倍速い。
ということは、Xeon 1CPUと比べると 5.6倍速い。
消費電力は70W程度だから、Xeon×2の1/3～1/4ぐらいじゃないか？

963 ：名無しさん＠お腹いっぱい。：2005/12/08(木) 15:39:33
>>960
Niagara の性能は、
ttp://www.sun.com/servers/coolthreads/overview/details.jsp
によると、
SPECjbb2005 51540
SPECweb2005 14001
とある。

Xeon × 2 の結果は、www.spec.org によると
SPECjbb2005 24208 (Dell SC1425)
SPECweb2005 4850 (Dell PowerEdge 2850)
なので、それぞれ 2.1倍、2.8倍、Niagara の方が速いことになる

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 21:31:53

Niagara2量産の暁には

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 21:52:30

>>417
>>416 あたり言いたがり連中に知れ渡ってないのは問題があるぞ、広報!!

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 21:52:38

SAPだとniagaraは、xeonデュアルコアと同等
conroeがでると、用途によってはintelのほうが
性能の絶対値、コストパフォーマンスなどでniagaraを
上回るわけで、アイディアはよかったけど、所詮はsunとTIだったって
感じだと思う

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 21:56:21

いい加減TIと手をきって富士通に製造頼むとかすればいいのに…

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:02:29

SAP動かすならOpteronか、さもなくばUltraSPARC IV系の方でしょ。

Conroe系のコアのXeonが出ると、単体CPUではOpteronよりは速く
なりそうだけど、マルチソケットのシステムを組んだ場合には、
バスの関係でOpteronの方が、まだ速そう。

NiagaraはWebやJavaアプリケーションサーバのようなフロント
エンド系サーバに特化した作りなんだから、そういう向いた
方面で使わなきゃ。Conroeが出ても、さすがに5.6倍の差は
埋まらないでしょ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:03:14

>>422
をを、いいねぇ、苦しまぎれがんばれーw

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:03:28

TI以外に製造委託すればクロック2割アップくらい確実なのにな

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:12:56

もう少ししたら Intel が弱体化するから製造を頼もうww

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:18:32

>>416
あんた結構恥ずかしいよ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:27:16

中小のWeb鯖 or Java鯖というニッチ市場しか製品を投入できないというSunもはずかしい。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:27:37

>>422
NetBurst あきらめて方針転換後初の 64bit CPU、うまくいくといいね～
Itanium2 のなんとかって省電力機能みたいなことが起きないといいね～
なむなむ～

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:30:30

>>422
Xeon? あんな爆熱お下品 CPU といっしょにするのやめてよねプンプン!

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:35:36

>>429
そこをなんとか広告や営業が客のミステイクをさそうのさ
いつもどおり空手形連発してりゃカモれるとこもある

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:36:19

ベンチマークみたいに常時 32 thread 以上も稼動しているケースって
多いのかな。たとえば 16 thread ぐらいしか稼動しないと 1 thread の
速度が遅い分、スループットは半分になってしまうわけだよね。

ベンチマークだけを鵜呑みにするアホは居ないと思うが、あまりそう
言った指摘は無いのかな？

もちろんターゲットにしている分野では、かなり良さそうな石だけどね。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:41:26

>>429
フロントエンド用ブレードサーバは、サーバ系では一番の成長分野で
ニッチというより、もはや主戦場。IBMが儲けてるのも、この分野で
トップなのが大きい。

>>433
フロントエンドサーバの場合、大量のクライアントをさばくのが
仕事だから、全然問題ない。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:46:49

主戦場なのはその通りだけど、
Azulの様にAppliance鯖という発想が出来ないのがSunのダメなとこ。
汎用鯖マシンの時代は終ったよ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 22:47:40

Azulって面白い製品だとは思うけど、儲かってんの？

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 23:17:32

ぢゃAzulも買収して今度はミッドティアを押さえる
APLでバックエンドもイタダキ
テープも持ってるしストレージもある
すげーSun死角なしじゃんｗ

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 23:19:30

>>435
いやいや、終わったのは高クロック多トランジスタ一辺倒の時代。さよなら～w

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 23:39:51

>>437
Sunはストレージもダメなのを知らんのか。
ハイエンドはEMCでミッドレンジ以下はNetAppというのが常識ですよ。
やっとNASを出し始めた頃には時既に遅し。
ホント死角だらけですよ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 23:48:07

いやうちもAuspex→NetAppでやってるから釣ってみたんだけど…
ミッドは処理にもよるからNiagaraでも性能の出る場合があるかもしれない
特定処理専用のアクセラレータというのは個人的には非常に魅力的に映るのだが
# それなのになんで蟹厨なのって言われそうだがよｗ

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 23:55:19

カニの話はつまらん。

:
... なにが「釣ってみた」だよ笑かすな

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 00:09:21

NetAppの場合はHDDを使うシステム構成であれば、どの分野でも有効だけど
Java Appliance鯖は分野が限られるのでそれなりに売るのは難しいかもしれない。
あと各App鯖ベンダから認定を取らないといけないのもちと面倒。
最小構成が２～３千万からなので、みんな人柱待ち状態なのかもしれない。

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 00:25:14

>>441
釣られて必死だナｗ

:
...つーか、釣られて気分悪くしたならスマソ

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 01:24:07

ぎえっ、既に釣ったつもりなのか。くわばらくわばら。

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 06:10:57

Intel の x86 も将来的には今の複雑なコア＋多くの単純なコアという方向に向かうみたいで
Niagara の方向に CPU 業界全体が向かうんじゃない？

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 06:42:14

それは、Niagara の方向とはちがうやん。

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 07:45:03

>>434
>433 でエッジサーバ以外には使えないんじゃないのと言っているんだが。

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 08:18:38

>>445
逆だろ。Niagaraが業界全体と同じ方向に行ってるだけであって。

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 08:54:38

>>370
初心者なら自分が常識をもっていないことを前提にすること。読んでいて恥ず
かしいよ。

**名無しさん＠お腹いっぱい。** · 2006/02/11(土) 09:22:45

>>448
確かに今は業界全体がマルチコア・マルチスレッドに逃げてるけど、
ハードは作りやすくても、ソフトが作りにくいんだよね
OSレベルでは、中途半端に資源共用してるせいで面倒だし、
アプリケーションにしても、そもそも並列ソフトが作りにくい。