Sun Microsystem 最大の夜長

**名無しさん＠お腹いっぱい。** · 2006/10/01(日) 14:44:01

日々肌寒くなるも、その先に本格的な冬がじわじわと忍び寄る
秋の頃合…。

そんな季節感の経営状態だが、秋こそ、秋刀魚イクラの季節！

【前スレ】
Sun Microsystems 最大のリストラ
http://pc8.2ch.net/test/read.cgi/unix/1149485579/

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 13:41:24

いや、実際数字に出始めてるんですが。不良債権処理始めたころの
にっぽんこくの銀行とは大違いでw

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 15:53:15

>>387 SPARCstorageArrayの頃から、Sunのストレージは設計が変で、ユーザの
評価を得られずに来た。T3もパートナーグループなどと言う訳の分からん仕組み
を採用したものだから、後継のT4も泣かず飛ばず。ドットヒルの3510FCに食われ
る情けなさだ。NAS市場への参入も中途半端だったので、ストレージの分野では
注目を浴びることは全く無かった。売り上げの数字がでかいので、一見すると
ストレージがんばっているじゃんと勘違いする向きも多いが、単にSunのサーバと
セットで売れただけで、ストレージを評価して購入したものではない。
StorageTek買収で、彼らの資産をうまく生かして展開していくのかなと期待
していたのだが、ロードマップを見る限り、Tape以外生かすつもり無いみたいね。
同様に買収した製品でSAM-FSやQFSと言う良い製品があるんだけど、こちらも
死んだようなもの。Sunって本当に商売下手。
Sunのサーバとストレージ、Tapeライブラリを買ってくれたら、SAM-FSもQFSも
超格安でバンドルしますくらいの手を打って欲しいものだ。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 16:38:13

Sun Fire15K買ってくれたら、もれなくストレージ（hitachiOEMのやつ）付いてきますってのはやってたな。

**名無しさん＠お腹いっぱい。** · 2006/11/04(土) 21:27:05

> SPARCstorageArrayの頃から、Sunのストレージは設計が変で、ユーザの

なぁーに、かえって免疫がつく。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 00:31:19

マルチスレッドを今より簡単に扱えるようになる時代はやってくるのかね。

コンパイラによる並列化はあまり期待できない、設計は面倒、デバッグは大変だし、
開発者にとってはシングルスレッドの処理が速くなるほうがうれしいと思うのだが。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 00:56:48

たぶん、よほど売れてるアプリじゃなきゃ無理だね。
オーダーメイドみたいな開発なら絶望的。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 01:27:24

Niagara のスレッドをきれいに埋めて走った最初のプログラムは JavaVM だったでしょ?
そんな特殊なもんじゃないけど。C と Pthread でガリガリ書くのは確かに
難しいけどね。だけど必要があれば自然と出てくるもんだよ、違うものがね。
そのためのハードウェアは Niagara で提示されたわけだし。
Bill Joy はパラダイムシフトは言語から起きるだろう、ってずっと前に言ってたね。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 01:44:11

Pthreadなんて捨ててOpenMP

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

>>392
諦めたらそこで試合終了ですよ
http://journal.mycom.co.jp/articles/2006/10/12/idf1/images/Photo74l.jpg

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 02:47:11

また陰℡の妄想プレゼンか

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 03:23:14

どの辺が妄想？

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 03:34:21

儲の思考は摩訶不思議
Intelは妄想でｻｿは妄想じゃない

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 03:52:57

淫はクライアントで、惨はサーバーだから
淫のは妄想で、惨のは妄想ではない

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 10:25:26

>淫はクライアントで、惨はサーバーだから
この驕りがNiagaraの悲惨な性能の原因なのですが。。。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 10:34:04

>>400は妄想そのものだが、>>401も負けてないな。

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

性能について触れてはいけないらしい。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 11:16:49

淫telのスレッドは汚いスレッド、Sunのスレッドは綺麗なスレッド

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 14:13:33

どっちも糞

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 15:18:36

>>405
IBMとAMDはもっと糞♪

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 17:16:22

SUNはAMDの子会社じゃないか

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 18:14:14

Kentsfield(1P4C) vs Woodcrest(2P4C)
http://www.hardwarezone.com/articles/view.php?id=2102&cid=2&pg=4
Opteronサーバー死んだな…
Clovertown 1.60GHz $455*2 >>> Opteron 2220 SE $786*2
Clovertown 2.33GHz $851*2 >>> Opteron 8220 SE $2149*4

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 18:21:33

ｳﾋｮｰ

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:13:18

>>407
影のボスはFASL LLCの非公開部門ですｗ

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:13:51

インテルがNetBurstやってたのは、
堅実なアーキテクチャを選ばなくてもやっていける余裕があった
ということなのだと思う。
シェアNo.1なのだから、積極的にブレークスルーにチャレンジする責任があるわけで。

AMDに追い上げられた結果、インテルは余裕かましていられなくなって、
堅実なアーキテクチャを選択して引き離しにかかる、と。
ある程度距離が取れたら、また、堅実ではないアーキテクチャに移行すると思われ。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:19:00

あれは積極的にブレークスルーにチャレンジした結果じゃないけどな。
シェアを持っていたから、クロック神話から抜け出せなかっただけ。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:20:46

ニコイチは堅実なアプローチとはいえませんｗ
前回の似非デュアルのときと状況が違うのは、Core2がそれなりに優れているってだけだな。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 19:46:12

>>408
これさ、Win XP x64 Edition を使ってないって事は 32bit でテストしてるんだよね。
Core MA は 64bit だと性能出ないって話だけど（AMD は 64bit の方が速い）、
そこら辺どうなの?

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 22:23:24

>>414
これ聞く場所間違えると激しく罵倒される質問だから注意。
スレ荒らすための煽りレスとかに使っちゃ駄目だからね？
絶対だぞ。
閑話休題。IA32eだと性能は10%程度「しか」向上しないよ。
ベンチによっては30%以上ブーストするNetburstがどう見ても最強です。
絶対性能では勝てないんだけどね。

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 22:27:38

>>415
日本語でおk

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 22:33:41

>>416
だが断る(えげれす語)
http://www.xbitlabs.com/articles/cpu/display/core2duo-64bit.html

**名無しさん＠お腹いっぱい。** · 2006/11/05(日) 23:08:24

>>417
FP と SIMD が速いのは（どうでも）いいんだけど、サーバ用途なら整数演算、マルチスレッド性能、
メモりアクセス性能のベンチは無いの?

そこにも書いてあるけど、EM64T で Macro-Fusion が無いのと LCP の問題がどれだけ性能に
影響するのか知りたい。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 08:01:46

なんで最近の若者はSPEC見ないんだろう。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 11:29:36

HP-UXは消えるのか！？という質問に答えとして。

Itanium系はLinuxが多いだろうし、PA系は縮退しているから・・・減る。
ただし、Itanuim系でもHAを考慮したものなら、HP-UXは以前、残るでしょう。

HP-UXの利点としては、LVMがLinuxのLVMと仕様互換なので、汎用性は高い。
SolarisのSVMと比較して、IBM/HPのLVMはEnterprise Volume Management System
との親和性も高いので、乗り換え易い。
VxVMの真の機能は、HP-UXに実装したものなので。

中規模以上のシステムを考慮した場合、HP－UXはまだまだ残る。

大規模：AIXかHP-UX
中規模：AIX/HP-UX/Linux/Solaris
小規模：Solaris/Linux

中規模以上において、次期LVMとしてのEVMSの使用を考慮するなら、
Solarisは使っちゃいけない。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 12:59:28

同時走行スレッド数が多い=スループットが稼げるってのがSUNの主張。
ところで、CPUキャッシュのサイズが数十～数百Kのコアを並べて、そこに載るプログラム
って一体・・・

現実、JVM上のスレッドは載るとしても、そこにデプロイされて動作するアプリのデータ構造
や実際のプログラムのサイズを考えれば、SUNが主張するほど効率よく動けない。

実際にある程度のキャッシュサイズを持った上、個々のシングルスレッド処理能力もまとも
でないと、各スレッド間の調整やらも含め、オーバヘッドが大きいんじゃないのかな？！

まともなコア(Power4レベル）のマルチコアチップが出てくるまで、多くのユーザは様子見。
で、SUNにはまともなコアが無いので・・・・終わってるって結論でおｋ？？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:00:32

ZFS は?

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

>>419
SUNのSPECによる見積もりツールの精度の荒さを見れば、誰も信じなくなるわな。
Oracleの性能をSPECで見積もったシステムを知っているが、悲惨。

SUNがSPECしかベンチマークを出さない（出せない）から、余計、信用が・・・・

OASとかでも、SPEC見積もりツールをOracleコンサルが全否定してるしな。
SUNユーザの前でHPならこう見積もるって力説してたから。

少々、CPUが遅くても、まともな見積もりが出せるような基準をSUN営業が用意しないと
商売にならないよな。

ま、まともな見積もりツールで見積もったら、HP/IBMとかのサーバ台数と勝負できない
のがモロバレで余計まずいのか！？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:13:03

LVMなんて使いにくいやん。
特にミラーリングのところ。
LV単位でのミラーリングってアホですか？なんでいちいちPVとLVの位置関係を確認せんといかんｗ
その点はVxVMやZFSの場合は、ディスクボリューム（ディスクグループやプール）に対してミラーなりストライプなりを指定するから、
物理デバイスの配置はよきに計らってくれる。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 13:54:11

そのため、ミラーリングに関しては、HP-UXではMirror/UXで別にしてんじゃねーの？！
しかも、LVMを使ったミラーの場合、VG単位でミラー化するのが普通。
#RAID１なんかは玉単位だろ。

逆にストライプ単位の設定の方が訳判らん。
エンタープライズ環境では、PV単位(玉）で考えるだろ。
ストライプとかLV単位でミラーなんて、せこい事はしないよ。

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

ぷららのSunサーバで玉交換間違えてシステムダウンさせたのはどこの会社だっけ？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:05:25

>>426
CTCか新日鉄あたり？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:24:35

LVMはMirrorDisk/UX使わなきゃミラーリングできないんだから。
＞VG単位でミラー化するのが普通。
コマンドわからん。そんなのあったっけ？

通常ミラーリングするときって、lvextend -mじゃないの？
当然、このコマンドで実行すると、同じPV上にあるLV同士でもミラーリング出来てしまうから、
レイアウトを意識する必要がある。

ミラーリングに関しては、SDSやVxVMの方が圧倒的に使いやすいしわかりやすい。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 14:45:28

>>428
LinuxのLVM1&2及びAIXのLVMではLVMでミラー化できまする。

んで、HP-UXなら”無い”。
管理考えるならVxVMだろうね。

LVMなんて、あと2年の命なんだから。
EVMSに置き換わって、終わりですよ。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 16:14:25

volume manager だけ見て OS の選定するのは何か間違ってる気がする。
俺が使いやすいからこれにしたい、って言うなら、そうですか、って感じなんだけど。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 16:35:42

そうだね。
ただし、エンタープライズの分野なら信頼性のある、且つ、汎用性の高い
VMを選択すべき。

なぜなら、それを”自分”や部下が設定・メンテするとは限らないから。
外注や他社のエンジニアが行う可能性が高いんですから。

そういう点を考慮して、OSってのは選ぶべきですね。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 17:08:50

互いのLVMのパーティションが読めても、大概FSは読めないし。
全てのOSでVxVM/FSに統一すれば読めるけど。
結局WindowsサーバはEVMSになんか対応するはず無いので、あまり意味なし。
イメージレベルでバックアップやスナップショットくらいなら取れるんだろうけど、
そんなのストレージレベルでも出来るしな。

あくまで、非機能要件のひとつに過ぎないから、アプリケーションやミドルの要件より優先度は低いしな。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 18:03:11

>>432
いや、VMの抽象化概念すら違う（SVM）ものがあると、そのための
概念から揃えるのが大変。

ヘテロジニアスな環境で、膨大なデータを相手にするようなシステムだと
当然、VMの選択=OSの選択となる。
DWH系なんかは、VMの比重も大きいよ。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 21:36:20

> SUNにはまともなコアが無いので・・・・終わってるって結論でおｋ？？

今のCPUはISAやアーキ以前に、キャッシュとメモリシステムの実装で性能が決まるんだろ？
まともなコアとか、いってんのはキャッシュ、メモリシステムのことかい？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 22:55:22

>>433
そらまたごたいそうなことで。Multics みたいな状況ですか?

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 22:58:43

ふと思ったんだが、Oracle10gのASMってwindows、Linux、Unix間でデータファイルをそのままやり取りできるんかな？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 23:48:36

>>436 CPUによるエンディアンの影響があるのでは？

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 23:52:19

Solarisならば今後はZFSだろ。
次期versionで待望のdual parity、hot spareがサポート。記憶が怪しいが
SunClusterの共有diskとしても使えるようになるんじゃなかったかな？
system disk(root filesystem)対応も近いと聞いている。

**名無しさん＠お腹いっぱい。** · 2006/11/06(月) 23:56:30

>>422 をかるくすっとばしてるから、たぶん知らないんだろw

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 01:17:35

まだ出てない技術は検討の対象外

Sun営業は予定の技術ばかり売り物にする

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

ZFS悪くは無いんだが、SunCluster以外にサポートしているクラスターソフトはあるの？

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 01:37:13

カタログスペックはいいけどアプリ動かすと遅かったのは HP の方だったけどねぇ。
今は違って、ずいぶん優秀になったんだね。
PA-RISC のバイナリはアホみたいに巨大だった（で、起動に時間がかかった）。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 02:05:36

たぬきの皮を数えてるまぬけなスレはここですか？

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 02:29:50

いいえ死児の歳を数える悲しいスレです

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 03:54:01

>>418
LCPってx86の盲腸だよね。
性能出す必要あるの?
IntelのCPUはx87も遅いし、必要ないところはばっさり切り捨ててるだけでは。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 07:12:04

本当に必要無いのなら最初から気にしないんですがね...

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 07:56:37

x86_64では
1. 16bitコードは動かない(LCP使われない)
2. x87は傍系(SSEが主流)
http://www.intel.co.jp/jp/developer/technology/magazine/computing/Core-programming-0606.htm

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 12:39:27

>>447
x86_64ではREXバイトが追加され拡張されたレジスタにアクセスする場合や
オペランドが64bitの場合には必ず使用される
REXバイトがあるとCoreMAの実行速度は遅くなる

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 13:19:47

66H 67HとREX Prefixesは別物

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 14:28:22

>>441
SUN儲にはSUNClusterがあればなにもいらないとさ。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 14:29:53

ZFSがどうしたって！？いまさらの投入って感じがするけど。
普通のユーザにおいて、SUNは選択肢から除外されてるし。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:00:41

>>449
REXとLCPは別物だがこれらの前置バイトが付いてるとCoreMAでは遅くなるというのは同じ
だからCoreMAでは64bitモードで遅くなる
REX前置バイトは拡張されたレジスタへのアクセスが発生する命令や
オペランドサイズが64bitの命令には必ず付く前置バイト
64bitモードでは多用される前置バイトが付くと遅くなるのは致命的

パソコン用途では64bitモードはまだほとんど使われてないが
サーバー用途では今後ますます64bitモードでの動作が重要になるはず

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:38:23

>>452
遅くなるといっても、Opteronほど遅くはならない

というベンチマーク結果を見たことがあるけど、あれは提灯だったのだろうか。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:49:08

逆だろ。
Core2の方がOpteronに比べて、64bitモードでの性能の落ち方が大きいんだろ。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 21:54:46

それでも性能は、Core2 の方が良いケースが多かったと思うけど。

ちなみに Opteron も 64bit バイナリの方が遅くなるケースもあるらしい。
64bit コードは大きいからキャッシュから溢れているだけだと思うけど。

**453** · 2006/11/07(火) 22:15:52

日本語が不明瞭で誤解を招いたようで恐縮です

CoreMAの32→64での性能低下割合が、Opteronの32→64での性能低下割合ほどではない
という意図ではなく、
32→64で性能低下したCoreMAの速度は、Opteronの64での速度ほどは遅くない
という意図でした。

Opteronと同等か、それ以上なら「致命的」というほどではないかと。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 22:31:26

もうすぐUlraSPARC-IV+ 2.1GHzが出るんじゃなかったっけ？予定では今月か来月。
同様に数ヶ月以内にUltraSPARC T1の1.4GHzが。IIIiが1.3GHz-1.6GHzだから
T1000/T2000でかなりの領域をカバーしそう。たまたまFPやVISを使っているアプリ
以外はT1で行っとけと。
ただT1000、内蔵ディスク2台入るようになったのは嬉しいんだが、CD/DVDが載ら
ないのは悲しいね。是非とも改良して欲しい。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 22:34:01

久々に米SUNのwebに行ったらラップトップ無くなっていたので悲しい。

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 23:29:27

Sunのスレだろうがどこだろうが、
関係なく出てきて、AMDけなすなあ淫厨は

淫厨の「速い」は、嘘っぱちだから、
話半分どころか、全部信じないよ
Pentium4で懲りたもんｗｗ

**名無しさん＠お腹いっぱい。** · 2006/11/07(火) 23:33:37

ここはアンチSunのスレ

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 00:25:19

SPARC64VI 2.4GHzじゃなくて？

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 00:27:20

>>457
Niagaraはsuper scalarではないので、クロックがIIIiと同じに
なってもシングルスレッド性能は半分ぐらいしかでない。floating
も爆遅。

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 03:55:21

なんか夜が長い気がするのは気のせいだろうか
いつ、夜が明けて朝日がみえますか？

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

>>452
LCPは性能低下要因でしかないが一般的に使われない。
Rex PrefixesはIA32eの仕様。
レジスタ等が拡張されてるので単なる性能低下要因ではない。
>>417を見てください、64bitで遅くなってるCPUは一つもありません。

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

>>463 あと500レスぐらい

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

>>464
>64bitで遅くなってるCPUは一つもありません。

コレどういう意味?
64bit の方が遅いベンチは幾つもあるみたいだけど

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 12:09:34

夜の闇が深いほど、夜明けが近いといいますがな。
まぁ、太陽が存在していれば、ですが。

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

>>465
それは間違い。あと500スレくらい。

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

>>467

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

>>467
>夜の闇が深いほど、夜明けが近いといいますがな。

秋の夜長が明けても、厳しい冬が到来するw

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 16:22:13

♪太陽がもしもなかったr(ry

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 16:42:52

太陽が燃えているかぎり
かならずまぶしい朝がくる
悲しみの夜がつづいても
君は負けずに朝を待て

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 17:29:58

太陽炎上

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 17:49:16

太陽に火をつけてみたいおバカがたくさんwww

**名無しさん＠お腹いっぱい。** · 2006/11/08(水) 18:03:48

サンサンごご、サンを苛める

**名無しさん＠お腹いっぱい。** · 2006/11/09(木) 22:13:35

おーれたちーのたまーしいーももーえーてーいーるー

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

いよいよ、Javaをオープンソースにして死ぬときが来たようですな。

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

Follow the sun, Catch the sun～

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

ん？4本柱政策は上手く起動に乗りつつあるとか記事が出てなかった？
Javaをオープンソースにしても大丈夫だと思うよ

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

もともとJavaではあまり儲けていないしなｗ

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

サンのミラー会長、サーバ事業の好調ぶりをアピール--
「Itaniumが好調なのは日本だけ」
http://japan.zdnet.com/news/hardware/story/0,2000056184,20308987,00.htm

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

UNIXサーバ PRIMEPOWER
国内RISC サーバ市場シェアNo.1 を獲得
http://primeserver.fujitsu.com/primepower/news/article/06/1110/

「偽物」に抜かれたようです

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

>>481
> Niagaraの次の世代のプロセッサ「Rock」も設計は終わり、予定通り2008年にリリース予定だ。

「予定通り～にリリース予定だ」に笑った

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

>>482
2006 1H に出荷台数が 40.1% も落ち込んだのって、HP? IBM?
あ、Itanium は RISC じゃない、ってオチ?

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

>>482
まぁ今回限りだろう。
2006年上半期といえばSPARCハイエンド数十台が納入された案件を知っている。
富士通が誘導して客（公官庁）のサーバ用アプリをSPARC Solaris限定にした、公取に引っかかりそうなやつ。
日電・日立・東芝は仕方なくOEMのSunサーバを納入したはず。

次回の富士通№１・Sun №2は2011年上半期になるかもなｗ

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

HPは、国外VLIWサーバ市場のシェアをほぼ独占ｗ

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

国外どころか、宇宙支配してるぜ! たのもしいな、HP!! wwww