Sun Microsystems 最期の神託
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001名無しさん＠お腹いっぱい。
2009/05/11(月) 19:40:54いよいよ神託(oracle)によって最期を迎える。
「汝自身を知れ」
【前スレ】
Sun Microsystems 最上川上流
http://pc12.2ch.net/test/read.cgi/unix/1239259163/
0852名無しさん＠お腹いっぱい。
2009/06/03(水) 14:02:14いやいやいや。
小さな会社だとWindows使いしかいないって。
そんなところでLinuxなんて使おうものなら趣味だって言われるぞ。
>>851
SMBやNT ACLが糞だっていうのなら、それらを使わなければいいのよ。
WindowsだからSMBを使わなくてはいけないってことはないのよ。
NT ACLについては・・・差し替えは難しいが。
0853名無しさん＠お腹いっぱい。
2009/06/03(水) 14:13:32提案してきたのは、Windows鯖のソースコード持っていて、
修正パッチ作っているような会社も含まれてるよ。
ヘテロな環境でTSEを運用する時のノウハウ蓄積されてるから。
あんたよりWindowsは詳しい人たち。
0854名無しさん＠お腹いっぱい。
2009/06/03(水) 14:31:36設定および維持管理は誰がするの？
イニシャルコストが安いだけで後で高くついたらどうするの？
GUIが用意されていてもデスクトップのユーザーインターフェースは
統一されていないというクソな有様だし
>>851
NT ACLのクソな点について説明求む
0855名無しさん＠お腹いっぱい。
2009/06/03(水) 14:34:09何も難しくない
0856名無しさん＠お腹いっぱい。
2009/06/03(水) 14:49:25・SOHO〜１事業所、30人未満の従業員数
こうなったらもう小さくないような。DBシステムその他も連動
して動いているだろうし。
・３事業所以上、50人以上の従業員数
0857名無しさん＠お腹いっぱい。
2009/06/03(水) 15:01:55そもそもシステムをとりまとめる人がいない場合はバラバラの可能性大
0858名無しさん＠お腹いっぱい。
2009/06/03(水) 15:17:41そういう例外もあるさ。
>>854
そうそう。
少なくとも経営者には、
unix系OSよりもWindows鯖のほうが、管理者になるための敷居が低い
と思われていることが多く、
ゆえに、unix系OSで実装する選択肢は、
「お前が辞めた後、いったい誰がサーバの面倒をみるんだ?」
っていう一言で、選択肢から外れるわけですよ。
Windows鯖をちゃんと扱える管理者を一人前にするのに要するコストが意外と高く、
パソコン感覚で弄り回すと大変なことになるってことは、経営層には知られてないことが多い。
0859名無しさん＠お腹いっぱい。
2009/06/03(水) 15:19:16うむ。
昔は、その状態から、Windows Server(5CAL付)なんかに乗り換えると、いきなりコストが跳ね上がってビックリだったね。
0860名無しさん＠お腹いっぱい。
2009/06/03(水) 19:26:57ウチは、Windows機を入れようとすると
管理者に「俺が管理出来ないから無理」、と言われる。
0861名無しさん＠お腹いっぱい。
2009/06/03(水) 19:47:580862名無しさん＠お腹いっぱい。
2009/06/03(水) 21:46:31> unix系OSよりもWindows鯖のほうが、管理者になるための敷居が低い
> と思われていることが多く、
実際はどっちもたいして変わらんけどな。とっつきやすさからWindows
に軍配が上がるのは別におかしな話でもないだろう。
> お前が辞めた後、いったい誰がサーバの面倒をみるんだ?
こんなんはるか昔から言われてることなわけで、それに対するまともな
解答を示せないUnixベンダの不甲斐なさと来たら・・・
0863名無しさん＠お腹いっぱい。
2009/06/03(水) 21:54:210864名無しさん＠お腹いっぱい。
2009/06/03(水) 22:12:17NASでもあてがっとけや
家庭用のやつ
>>863
sambaのスレへ逝け
0865名無しさん＠お腹いっぱい。
2009/06/03(水) 22:18:35最初に触るのも Windows だろうし。昔は Sun の WS だったけど w
0866名無しさん＠お腹いっぱい。
2009/06/04(木) 01:26:38書籍の数といい、Solaris 10の情報の少なさは泣けてくる。
0867名無しさん＠お腹いっぱい。
2009/06/04(木) 01:28:30そういう個人に頼る環境化では、
何をサーバにしても継続性維持が困難なのは同じことなんじゃ？
今や管理も含めて外注がほとんどじゃないの？
社員10人くらいの会社ならともかく。
0868名無しさん＠お腹いっぱい。
2009/06/04(木) 01:31:46そういうレベルでのコスト削減はありなんじゃないの
0869名無しさん＠お腹いっぱい。
2009/06/04(木) 01:43:13http://www.computerworld.jp/images/_main/200906/1487707.jpg
0870名無しさん＠お腹いっぱい。
2009/06/04(木) 01:45:27言っている人がいるけど、それは昔の話でしょ？
富士通のPRIMEPOWERはHP-UX機以上に信頼性
高かったでしょ？
今のＭ９０００は富士通製なんで、信頼性は高いです。
CPU性能的にもItanium2よりはぜんぜん速い。
Power6やXeonには負けるけどなー。
0871名無しさん＠お腹いっぱい。
2009/06/04(木) 01:47:21中で処理した方が安いでしょうね。
出来る人がいるという仮定で。
0872名無しさん＠お腹いっぱい。
2009/06/04(木) 05:06:31問題は、NiagaraとRock。
その2つはSunの設計だから、信頼性が怪しい。
本当にRockはSPARC64シリーズの上を行けるのか。
0873名無しさん＠お腹いっぱい。
2009/06/04(木) 05:10:28機動性を確保するために中で処理している会社もありますよ。
機動性がコスト削減に繋がるところでは、
コンピュータ・システムを使わずに、紙と鉛筆なんていう現場も。
0874名無しさん＠お腹いっぱい。
2009/06/04(木) 09:33:22別に UltraSPARCコアに信頼性問題があったわけじゃないだろ。
0875名無しさん＠お腹いっぱい。
2009/06/04(木) 10:12:290876名無しさん＠お腹いっぱい。
2009/06/04(木) 11:02:54XeonやOpteronには、それこそ膨大なエラッタが現在進行形であるんだぞ。
まぁ自分なら、Xeonの枯れたところを選ぶがね。
0877名無しさん＠お腹いっぱい。
2009/06/04(木) 11:55:360878名無しさん＠お腹いっぱい。
2009/06/04(木) 12:00:28それは「信頼性問題」じゃないだろ..
0879名無しさん＠お腹いっぱい。
2009/06/04(木) 12:14:50会社に対する信頼の問題だな。
64bitとして売っておきながら、実際には32bitだったのなら。
0880名無しさん＠お腹いっぱい。
2009/06/04(木) 12:52:16> 64bitとして売っておきながら、実際には32bitだったのなら。
をっと、x86 core architectureに対する悪口はそこまでだ。
0881名無しさん＠お腹いっぱい。
2009/06/04(木) 13:19:520882名無しさん＠お腹いっぱい。
2009/06/04(木) 14:27:25仮想化使って過負荷にしないとバグを再現できないみたいだが
0883名無しさん＠お腹いっぱい。
2009/06/04(木) 15:42:12まともな話題全部「埋めて」くれるなオマエは。鳥頭過ぎなんだよ。くんじゃねーよ。
0884名無しさん＠お腹いっぱい。
2009/06/04(木) 15:58:460885名無しさん＠お腹いっぱい。
2009/06/04(木) 15:59:440886名無しさん＠お腹いっぱい。
2009/06/04(木) 16:11:500887名無しさん＠お腹いっぱい。
2009/06/04(木) 16:14:480888名無しさん＠お腹いっぱい。
2009/06/04(木) 17:27:31ガセか?
オレは Fire 6800と 4500が稼働する環境と付き合ったことあるけど、
uptimeでみる限り両方とも何年もノントラブルだったけどな。
0889名無しさん＠お腹いっぱい。
2009/06/04(木) 17:28:470890名無しさん＠お腹いっぱい。
2009/06/04(木) 17:52:30日次バッチ走るようになってたよ。オレはそこに寄生させてもらう小さいの
作っただけだったけど。Fire 6800の方。
ビクともしてなかったね。
4500の方は、常時負荷かかかるような環境じゃなかったけど、
突発的に処理のかかるようなシステム。自然現象相手のやつ。
やっぱデマなんだな..
0891名無しさん＠お腹いっぱい。
2009/06/04(木) 18:02:20サーブレットコンテナ走らしてて、スワップが 4GBで足りなくて 1GB増やしたら
どうの、ってガリガリ開発やってた。
かなり長期間に渡って開発に使ってて、同じ構成でたくさんユーザー先に
導入してるはずたけど、ハードウェアに問題が出たなんて聞いたことがない。
0892名無しさん＠お腹いっぱい。
2009/06/04(木) 18:29:10三桁台ならE450がひどかった
0893名無しさん＠お腹いっぱい。
2009/06/04(木) 18:35:52しかしなんだな、6800なんて詐欺みたいなマシン・・・ご愁傷さま。
0894名無しさん＠お腹いっぱい。
2009/06/04(木) 18:39:26一切聞いたことがないぞ。
ここで誰か書いてたのは E20kの話だったと思うけどな。
0895名無しさん＠お腹いっぱい。
2009/06/04(木) 18:41:57まあ、買ったのはオレじゃないし.. 大学病院。
自分じゃよー買わんわけだが、価格設定は、各社そんなに差はないだろ。
パソコンのスペック掛け算する性癖のある貧乏人には、そりゃ高いわなwwww
0896名無しさん＠お腹いっぱい。
2009/06/04(木) 18:53:266800って、ドメインで使うわけだが、結局、出番のない柔軟性だったりするんよ。
0897名無しさん＠お腹いっぱい。
2009/06/04(木) 23:28:39あったよ。だからCDMっていうfpu部のチェックツールがでてきた。
まあItaniumにも問題があってＣＰＵ交換の話があったけどね。
0898名無しさん＠お腹いっぱい。
2009/06/04(木) 23:39:462000夏のこの問題にはやられなかったんですね。よかったですね。
> Systems affected by the problem appear to be those
> based on 400-MHz UltraSPARC-II CPU modules
> using either a 4MB or 8MB cache.
これはSunがバックレたから避難の嵐だった。
逆にE20kは全く問題なかった。
i-modeの事件もE20kの問題じゃないしね。
0899名無しさん＠お腹いっぱい。
2009/06/04(木) 23:41:17柔軟性は高いけど、その分価格が高いからね。
0900名無しさん＠お腹いっぱい。
2009/06/04(木) 23:54:33Sun Microsystems 最大の企業売春
http://pc12.2ch.net/test/read.cgi/unix/1242037807/
0901名無しさん＠お腹いっぱい。
2009/06/04(木) 23:57:34Cacheエラーの問題だろ？
Sunはばっくれちゃいねーよ。
全部ミラードCacheの石に交換したｗ
UIIはひどい石だったな。
次のUIIIもダメで、結局UVIまで石の信頼性は上がらなかった。
逆に言うと、UVI以降、深刻なトラブルは起きていない。
最近のSunがダメなのはミッドレンジ以上のサーバじゃなくて
エッジ系のサーバ。
製造委託している会社があまりにもひどくて、「お前ら、絶対
出荷検査していねーだろ」と思うくらい故障率の高いモデルが
二年に1回位現れる。
その度にSunは反省するんだけど、二年経つと忘れるんだなｗ
T2搭載した5000系のサーバのファーストロットがボロボロ。
ブレードの二世代目もボロボロ。
X4150もメモリのエラーが多くてｗ
設計は優れていると思うんだが、製造委託先が間違って
いるよｗ
Oracleに救済されるまで落ちぶれたのはある意味当然。
0902名無しさん＠お腹いっぱい。
2009/06/05(金) 00:31:34これ、相手によって対応に差があったんだよ。
全部交換しますって告知はしなかった。
> 設計は優れていると思うんだが、製造委託先が間違っているよｗ
これはその通り。アメリカのメーカはそういうの結構多いね。
0903名無しさん＠お腹いっぱい。
2009/06/05(金) 00:38:28＞出荷検査していねーだろ」と思うくらい故障率の高いモデルが
＞二年に1回位現れる。
＞その度にSunは反省するんだけど、二年経つと忘れるんだなｗ
反省なんてしてねーよ。
客先別にテスト項目が違うんだ。文句言うとテストが厳しくなる。テストに落ちたものは別の客先行きになる。
0904名無しさん＠お腹いっぱい。
2009/06/05(金) 00:45:30だからまだNehalem-EXが出てないんだよ、馬鹿。
Nehalem-EXが出るまで待て。リニアにスケールとか議論する以前に
少ないCPUでも大差で勝てちゃうからそんな話題にすらならんと思うがw
あとスケーラビリティが向上するのはQPIだけじゃないんだけど、
cacheのプロトコルとかAPICの拡張とかがある。
まあここのSPARC馬鹿には説明しても理解できない内容であるが。
0905名無しさん＠お腹いっぱい。
2009/06/05(金) 00:49:23他は比較するのも可愛そうなくらいの差がついて久しいのだが。
0906名無しさん＠お腹いっぱい。
2009/06/05(金) 00:55:110907名無しさん＠お腹いっぱい。
2009/06/05(金) 00:56:05認めたくない現実から目を背けてしまったんだよ
Windowsを大昔の認識のまま語る頭のおかしい人も同じ
0908名無しさん＠お腹いっぱい。
2009/06/05(金) 01:17:230909,,・´∀｀・,,）っ-○○○
2009/06/05(金) 05:52:580910名無しさん＠お腹いっぱい。
2009/06/05(金) 06:20:010911名無しさん＠お腹いっぱい。
2009/06/05(金) 06:20:43コストカットしないと、高くて売れないから、綱渡りになるのは仕方ないと思う。
0912名無しさん＠お腹いっぱい。
2009/06/05(金) 06:23:27UltraSPARCシリーズは、まぁ、そうだろうが、
富士通のSPARC64は、かなり速いんじゃないか?
もうSPARC使わなくなって久しいので実機触れん。
0913名無しさん＠お腹いっぱい。
2009/06/05(金) 06:36:19使ってみればわかるがマジで遅くてストレスたまるレベル
0914名無しさん＠お腹いっぱい。
2009/06/05(金) 08:09:40>文句言うとテストが厳しくなる。テストに落ちたものは別の客先行きになる。
うわー外国企業にありがちな話だなw
もっとも、最近はキヤノンの品質管理が酷い話とか記事を見ると
日本企業も短期的なコスト重視で欧米化してるのかな。
0915名無しさん＠お腹いっぱい。
2009/06/05(金) 08:28:53半年ごとに担当者が入れ替わるからだろｗ
0916名無しさん＠お腹いっぱい。
2009/06/05(金) 09:26:46中国人のIT関連労働者って３−６ヶ月で仕事を変わるのが普通らしい。いくら
製造技術や品質管理の教育しても追いつかない。
0917名無しさん＠お腹いっぱい。
2009/06/05(金) 11:02:24他所の工場で教育を施された人を高給で引き抜くしか手はない。
0918名無しさん＠お腹いっぱい。
2009/06/05(金) 11:03:26台湾とか東南アジアとか、もっと良い場所はあるんだが、関連工場がないんだわ。
0919名無しさん＠お腹いっぱい。
2009/06/05(金) 11:06:24世界の工場になって技術とビジネスを吸い取るのは。
安いからといって中国に工場を移したり、中国の工場に発注したりしていると、
そのうち、中国なしには何も作れなくなって、中国に頭が上がらなくなっちゃう。
というわけで、Sunは昔からの製造委託先の日本を、もっと使ってほしいな。
0920名無しさん＠お腹いっぱい。
2009/06/05(金) 11:08:310921名無しさん＠お腹いっぱい。
2009/06/05(金) 11:14:260922名無しさん＠お腹いっぱい。
2009/06/05(金) 11:41:08今は部品工場が中国にあるから、台湾で製造するとなると、手間が増える。
0923名無しさん＠お腹いっぱい。
2009/06/05(金) 12:52:530924名無しさん＠お腹いっぱい。
2009/06/05(金) 13:03:450925名無しさん＠お腹いっぱい。
2009/06/05(金) 15:33:59http://sourceforge.jp/magazine/09/06/03/088248
0926名無しさん＠お腹いっぱい。
2009/06/05(金) 18:13:33痛リア製もあったな。なつかしい。
0927名無しさん＠お腹いっぱい。
2009/06/05(金) 19:03:220928名無しさん＠お腹いっぱい。
2009/06/05(金) 19:59:35CPUじゃなくてサーバの話さ。
>>926
Olivettiだっけ?
0929名無しさん＠お腹いっぱい。
2009/06/05(金) 20:04:010930名無しさん＠お腹いっぱい。
2009/06/05(金) 20:37:020931名無しさん＠お腹いっぱい。
2009/06/05(金) 20:58:570932名無しさん＠お腹いっぱい。
2009/06/05(金) 21:47:110933名無しさん＠お腹いっぱい。
2009/06/05(金) 21:52:26ダメダメと言われたSPARC(UltraSPARC T2/T2+)にも
性能で負けているのにｗ
Nehalem-EPと比べるのもおこがましいわ。
int/fpともに2倍の大差じゃんｗ
RISC系で期待出来るのは、富士通のSPARC64VIIIfx
だけかもな
0934名無しさん＠お腹いっぱい。
2009/06/05(金) 21:58:460935名無しさん＠お腹いっぱい。
2009/06/05(金) 22:08:200936名無しさん＠お腹いっぱい。
2009/06/05(金) 22:32:56いろんなCPU上でのビジネスアプリ走らせて見ると
SPECint_rateの比に近くなるけどな。
どちらにせよ、Xeon4500系にPower6は勝てないのは
明白。まぁ、1〜2世代の差をつけられているので
当然の事だけど。
0937名無しさん＠お腹いっぱい。
2009/06/05(金) 22:36:59エリソンに買い占めてもらうかｗ
fx大量生産して欲しいな
0938名無しさん＠お腹いっぱい。
2009/06/05(金) 23:08:34だまれ小僧！お前にサンが救えるか
＜ｵｼﾒ
0939名無しさん＠お腹いっぱい。
2009/06/06(土) 00:08:28オラクル CEOのラリー・エリソン氏はヨット好きで知られている。世界最大のヨットレース、
アメリカズカップにも出場するエリソン氏所有のヨットで、「タダでJavaの宣伝をしてくれる
かもしれないよね」とマクニーリ氏
あるいはスタジアムに、こんな名前が付くかもねと写したのは「Ultra SPARC」のロゴ付きの
スタジアム
ついにアップルのiPhoneにJavaを載せる話を付けてくれるかもしれないじゃないかとジョーク
夢がひろがりんぐ wwww
0940名無しさん＠お腹いっぱい。
2009/06/06(土) 01:02:56cache coherenceでよく使われるのは、snoopとdirectory-basedだが、directory-basedだと遅い上に
ccNUMAのように一様でなくなってしまうので、性能が劣化する。現実はsnoopが一番早いのだが、
バス飽和がある。64CPU以上でバス飽和させないためには、M-seriesのようにsuper computerの技術を
転用したバス飽和しない帯域を持つバスを展開するしかないが、これができるのは基本的にFujitsu。
IBMはCPU数を少なく（だが1 CPUは速い）して、たかだが64CPUに留めることで対応しているようだ。
その他の64CPU以上のものは、NUMAになってしまう（ので、性能が劣化する）。
それと、IBMは、Power7を開発中のはずで、8 core, 45nm processのこのCPUは、１つで256GFLOPSを
達成すると言われている。Power/SPARC/Xeon/Itaniumは当分性能争いするはず。
0941名無しさん＠お腹いっぱい。
2009/06/06(土) 02:10:45>Power/SPARC/Xeon/Itaniumは当分性能争いするはず。
なんねーよ
既になってねーし、Gflopsなんてサーバじゃ殆ど関係ねーよ、バーカ
0942名無しさん＠お腹いっぱい。
2009/06/06(土) 02:15:09x86やPOWER6には遠く及んでない。実装の規模からして違う。
Itaniumも将来性ないし、もう比較の対象じゃない。
とっくにわかりきったことだが、現実を受け入れられない珍比較が蔓延しているところが
このスレの見所だなw
0943名無しさん＠お腹いっぱい。
2009/06/06(土) 02:48:50よさそうなものだが、TOP500をみるともう嫌になるほどIBMやx86陣営ばっかり。
実はSunも6位にランクしているのだが、CPUはやっぱりOpteronであってSPARCではない。
ここ1, 2年だけみてもx86とIBMのハイエンド一色化がどんどん進行してるだけなんだが。
このスレのSPARCマンセーさん達も恐れずに現実の世界に少しは足を踏み出してみようよ。
http://www.top500.org/list/2008/11/100
0944名無しさん＠お腹いっぱい。
2009/06/06(土) 04:01:56HPCでメシが食える人はそれでもいいんじゃないの？
0945名無しさん＠お腹いっぱい。
2009/06/06(土) 07:20:51もう１つの理由は、cross barが作れないこと。cross barで接続するのが理想であることは既知だったが、
cross barはCPU数が増えれば指数関数的にpathの数が増加するために、従来より大規模コンピュータでは
事実上不可能と言われていた。事実、Tanenbaumは、その著書で64CPUがUMAとしての上限としているのは、
ここの理由から来ているようだ。また、AMDのHT Link数をみれば現実として如何にそれが容易なことでは
ないのかが分かる。(そのため、CPU数が増えればNUMAによる性能劣化をみる)
従来のSupercomputerではcross barを必要としたため、path数を押さえてcross barを製造する特許を
幾つか持つFujitsuでは、M-Seriesなどで64CPU以上をcross barで接続しているが、これを行えるのも、
今のところFujitsuだけのようである。そのため、他社はCPU数を64以下にするか、NUMAにせざるを
得ない。結局のところ、snoop/cross barを越えるものはないが、実際製造できないため、CPU数を
押さえたり（その代わりMulti Core）、他の方式にせざるを得ないというのが実際のところ。
0946名無しさん＠お腹いっぱい。
2009/06/06(土) 08:47:44京速スパコンで使うのは、コアやキャッシュが全て良品で、所定のクロックで動作するものだけだろう。
ダイは決して小さくないので、かなりの数の不良が出るはず。
コアやキャッシュを部分的にdisableにしたり、クロックを落したもの・・・富士通は外に出さないんだっけ?
SunのNiagaraのように、出してくれれば・・・。
0947名無しさん＠お腹いっぱい。
2009/06/06(土) 08:58:10Sunはsnoopとdirectory-basedの両方ともやったけど、どちらも一長一短だったね。
前者は実効帯域幅が足りないし、後者はレイテンシが大きくて。
富士通は偉いよね、見かけ倒しにならないように、ちゃんとしたものを作ってる。
0948名無しさん＠お腹いっぱい。
2009/06/06(土) 09:02:18HPCを大規模SMPでやるのはコストパフォーマンス的に、小規模SMPのクラスタに勝てない。
>>945
HPCだと、地球シミュレータもクロスバーだよ。
0949名無しさん＠お腹いっぱい。
2009/06/06(土) 09:08:31なんか言い訳くさいんだが、現実に即したアプローチは大切だ
問題は、Sunのプロセッサの開発力
レイテンシが大きいなら1コアで多数のスレッドを実行しよう、というのは良い
でも、それをNiagara系でしか、やっていないのがダメだ
SMPできないT1、T2、SMPできるがUltraSPARC IV+と交換できないT2+
Rockなんて複雑なものはいらないから、UltraSPARC V を出すべきだった。
IV+ に 4スレッドくらいのマルチスレッドを実装するだけで十分だったはずだ。
それをやらなかったのは、Fireplaneがネックだったんだろうな。
0950名無しさん＠お腹いっぱい。
2009/06/06(土) 09:44:49何年も完成のめどが立たず破棄されたな
0951名無しさん＠お腹いっぱい。
2009/06/06(土) 09:47:21Sun Microsystems 最大の企業売春
http://pc12.2ch.net/test/read.cgi/unix/1242037807/
レス数が950を超えています。1000を超えると書き込みができなくなります。