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

Sun Microsystems 最上川上流

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2009/04/09(木) 15:39:23
五月雨を集めて早し最上川

【意訳】五月雨のように断続的に数々のIT企業を買収して集めても、
業績の下落ぶりはまるで急流のように早く、あとには何も残らない。
【補足】
スレッドタイトルは、一説に最上川上流に不法投棄のゴミが溜まって
いる惨状を某企業の内情なぞらえて詠んだ哀歌とも。詠人不知。

【前スレ】
Sun Microsystems 最大の超新星
http://pc12.2ch.net/test/read.cgi/unix/1233928036/
0734名無しさん@お腹いっぱい。2009/05/04(月) 21:20:51
>>732
ハードウェアが24時間365日の信頼性があっても、
その上で走るソフトが、そこまでの信頼性がないのよ。
0735名無しさん@お腹いっぱい。2009/05/04(月) 21:24:30
HAクラスタのフェイルオーバーとかも未だに恐る恐るやってるのか?
0736名無しさん@お腹いっぱい。2009/05/04(月) 21:28:17
[詳報]「SPARCを続ける覚悟はある」,富士通決算・一問一答
http://itpro.nikkeibp.co.jp/article/NEWS/20090430/329409/
0737名無しさん@お腹いっぱい。2009/05/04(月) 21:29:17
切り換えた途端に同じように落ちるっていうトラブルは、良く聞くね。

ハードウェア的な故障ではなく、ソフトウェア的な問題で落ちて、
その落ちる原因が与えられたデータにある場合、切り換えた先も落ちる。
0738名無しさん@お腹いっぱい。2009/05/04(月) 21:44:06
>>736
一瞬訃報に見えたw
0739名無しさん@お腹いっぱい。2009/05/04(月) 21:46:27
おれも
0740名無しさん@お腹いっぱい。2009/05/04(月) 21:50:30
おれも…
0741名無しさん@お腹いっぱい。2009/05/04(月) 21:58:36
奇遇だな…
0742名無しさん@お腹いっぱい。2009/05/04(月) 22:01:39
>>733
むしろなぜやらないか不思議
0743名無しさん@お腹いっぱい。2009/05/04(月) 22:03:40
x86Solarisを欲しがる客がいないから
0744名無しさん@お腹いっぱい。2009/05/04(月) 22:03:55
動作確認はやってたわ
ttp://primeserver.fujitsu.com/primergy/software/linux/products/distribution/free-os.html
0745名無しさん@お腹いっぱい。2009/05/04(月) 22:04:54
覚悟があれば何だって出来ますよねー
0746名無しさん@お腹いっぱい。2009/05/04(月) 22:06:32
>>735
そらそうよ>>817
0747名無しさん@お腹いっぱい。2009/05/04(月) 22:10:38
またロングパスか
0748名無しさん@お腹いっぱい。2009/05/05(火) 07:19:19
>>717
どこでもあの程度の失敗はあるんだけど、
起きてからの対応が悪かったから離れたんだよ。
基本無視だったからね。Ultra Enterprise 450用daughter CPU boardは。
俺の知り合いも三人、次回はSunを外したよ。
一つは結構大きなデータセンター。
あそこで大盤振る舞いしておけば信頼も勝ち得たのになあ。
0749名無しさん@お腹いっぱい。2009/05/05(火) 07:32:38
金にならない信頼などクソの役にも立たない。文句言うヒマでちゃっちゃと保守契約更新しろや豚
0750名無しさん@お腹いっぱい。2009/05/05(火) 08:29:25
IBM HPに乗り換えちゃったから保守契約いらないよブヒ
0751名無しさん@お腹いっぱい。2009/05/05(火) 08:48:47
>>749
何いってんだ。

CPU交換しても一向に納まらないのだから、保守契約とかそういう次元じゃない。
0752名無しさん@お腹いっぱい。2009/05/05(火) 10:05:46
クレーマーがまた1人減ったのでとても嬉しいです!
0753名無しさん@お腹いっぱい。2009/05/05(火) 16:26:58
http://namidame.2ch.net/test/read.cgi/auto/1239271552/

これみたい
0754名無しさん@お腹いっぱい。2009/05/05(火) 19:14:52
FreeBSD 7.2 リリースで UltraSparc-III をサポートだってさ
ttp://slashdot.jp/opensource/09/05/05/0749236.shtml
0755名無しさん@お腹いっぱい。2009/05/06(水) 05:20:48
ヲレがSunを好きなのがSunの公式web落ちてるの見たときないから
0756名無しさん@お腹いっぱい。2009/05/06(水) 08:54:24
akamai化されてるから、だったりして。
0757名無しさん@お腹いっぱい。2009/05/07(木) 02:53:50
>>756
アカマイズされてないけどね。
0758名無しさん@お腹いっぱい。2009/05/07(木) 04:59:17
ttp://d.hatena.ne.jp/rougeref/20090408
0759名無しさん@お腹いっぱい。2009/05/07(木) 22:54:36
>>758
自分は無能ですって公言するプレイですか。わかりません><
0760名無しさん@お腹いっぱい。2009/05/07(木) 23:29:38
>>759
設定で逃げられる解決方法あるの?
0761名無しさん@お腹いっぱい。2009/05/08(金) 07:40:51
逃げるも何も状況を整理することすらままならない人だろう。
0762名無しさん@お腹いっぱい。2009/05/08(金) 08:25:59
重ねて聞くけど、これはLinuxの問題ではない、設定の問題であるということ?
0763名無しさん@お腹いっぱい。2009/05/08(金) 08:37:34
ぷ、Windows未満だな。

Windows鯖だって、そういう落ち方はしないぜ。
負荷がかかったら遅くなっても落ちはしない。
0764名無しさん@お腹いっぱい。2009/05/08(金) 09:20:12
よくこんな恥しいのを公網上に晒すな...
0765名無しさん@お腹いっぱい。2009/05/08(金) 09:32:55
恥ずかしいのはRHELのことか?
結局誰も解決方法わからないんじゃん
0766名無しさん@お腹いっぱい。2009/05/08(金) 09:41:01
もちろん、「オマエ」のことに決まってんだろ。
0767名無しさん@お腹いっぱい。2009/05/08(金) 09:55:52
あーあ、人格否定にきたよ
こういうときが一番楽しい
0768名無しさん@お腹いっぱい。2009/05/08(金) 09:58:00
カーテン買って来たんですけどウチの窓よりちっちゃいんです!!
カーテンなんてどれ買って来てもぴったりなのがあたりまえじゃないんですか!!
なんとかしなさいよ、カーテン屋か窓屋のどっちかが悪いんだから!!!!!!
0769名無しさん@お腹いっぱい。2009/05/08(金) 09:58:52
しかしこのサーバ、Sun製選んでたことは賢い
Linux使えなくてもSolarisで逃げられるもん
RHELと仮想化でコスト削減(笑)なんて、甘い夢見たいよな〜
0770名無しさん@お腹いっぱい。2009/05/08(金) 10:01:31
>>768

小さいカーテンはLinux
窓はパチョコンサーバってこと?

Linux小さすぎだろJK
0771名無しさん@お腹いっぱい。2009/05/08(金) 10:11:53
まあ、順当なとこでさ、カーテン付きで家建てなおせばいいんじゃね? それが早いよw
0772名無しさん@お腹いっぱい。2009/05/08(金) 10:14:14
組み込みかよw

結局サーバにはSolarisしかないんだな…
0773名無しさん@お腹いっぱい。2009/05/08(金) 10:21:24
みんなで使えないものを使えると言ってるうちに
なんとなく使えるような気になって
でもやっぱりダメだったという不幸な話。
0774名無しさん@お腹いっぱい。2009/05/08(金) 11:02:23
チューニングと言いつつ最大キャパシティ設定(越えたらクラッシュ)が必要なOSって、ちょっとなぁ。

昔FreeBSDで何とかbufが足りなくなると云々とかいうのがあって、呆れたことがある。
ソースコードにマクロで数値が埋め込まれていて、そいつを設定してビルドし直すのだとか。

Windowsなんかはバイナリ提供onlyだから、できる限り動的にメモリを確保する。
だから、少なくとも、カット&トライで設定を調整する必要はない。
0775名無しさん@お腹いっぱい。2009/05/08(金) 11:33:20
はぁ... なんでも動的に確保すりゃいいと考えてられるようですが、
世の中そんなに甘かないですよ。
呆れて物事が解決するんならみんな呆れてればいいんだけどさ。

で、NFSはバージョンいくらでマウントされてたの? TCP? UDP?
0776名無しさん@お腹いっぱい。2009/05/08(金) 11:41:31
つか、RHELとか使うんだったら RedHatに聞けよ。あと NASのメーカーと。
聞く気もないんなら動いてる Fedora使っときゃいーだろが。
問題の切り分けもできてないのに問合せもせず商品名明示して「使えない」とか
書いてるとそのうち訴えられるぞ。

RedHatだからとか Sunだからとかまったく関係ないし。
0777名無しさん@お腹いっぱい。2009/05/08(金) 11:53:36
>>775
静的に設定すべきレベル - 動的では不可能なことをやるため
動的で良いレベル
手抜きにより静的に設定するレベル

上と下を混同するな。
0778名無しさん@お腹いっぱい。2009/05/08(金) 12:01:02
そんな文学的表現をしてないで
具体的に何をどういう理由で静的 or 動的に確保すべきで、
それぞれのOSどう実装してるのか書いたら?
もし建設的な話をしたいならね。
0779名無しさん@お腹いっぱい。2009/05/08(金) 12:13:43
> そんな文学的表現をしてないで
そんな上等なもんじゃ、ないわなww

> もし建設的な話をしたいならね。
可能性ゼロ。
0780名無しさん@お腹いっぱい。2009/05/08(金) 12:59:44
うちWindows鯖を使ったソリューション屋

あるときUNIX鯖から乗り換えた客が、
負荷試験やったら
CPU使用率が高すぎたってクレームが。

客から来たメールには、
Windowsのタスクマネージャの画像が。

そんなので云々してほしくないのだが、
高いところでも30%くらいでしかない。

彼らには、たった30%でも、いつ飛ぶかヒヤヒヤなんだってさ。
こっちは100%貼り付きでも問題ないように作ってるんだけどな。
0781名無しさん@お腹いっぱい。2009/05/08(金) 14:07:34
windowsはすぐにCPU負荷上がるからね
30%だとむしろ負荷かかってないと思う
0782名無しさん@お腹いっぱい。2009/05/08(金) 14:29:30
いやいや、Windowsは100%行かせちゃまずいだろw
0783名無しさん@お腹いっぱい。2009/05/08(金) 16:22:05
Sandy Bridgeで AVXに移行しちまうそうじゃないか。もう別のアーキになる、って
ことだ。やっぱ x86 ISAはカスだからな。やっと終るな。
0784名無しさん@お腹いっぱい。2009/05/08(金) 16:31:41
AVXはSIMDに関する部分であって、普通の命令は違うだろ。

AVXの命令エンコーディングみてゲンナリしたよ。
既存のSSE系列から変えるのに、命令長が少ししか縮まない。
もうね、アホかと。

いっそページディスクリプタにフラグを追加してだな、
ページ事に命令セットを変更できるようにしたらいいんだよ。
そしたら、同一プロセス内で複数の命令セットを混在できるっしょ。
0785名無しさん@お腹いっぱい。2009/05/08(金) 16:42:34
名前は「拡張」だが、実体は...

> そしたら、同一プロセス内で複数の命令セットを混在できるっしょ。
なに言ってんだか.. 古い方(x86な)はとっとと葬るんだよ。
両方性能出るわけないじゃん。Itaの時と同じ。互換フォロー扱いで
「それじゃ性能出ませんよ?」。全書換えの時が来ましたw
0786名無しさん@お腹いっぱい。2009/05/08(金) 16:49:24
x87 FPUは、すでにobsolateだが。
0787名無しさん@お腹いっぱい。2009/05/08(金) 16:50:21
後藤さんのとこ
ttp://pc.watch.impress.co.jp/docs/2008/0410/kaigai435.htm

| AVX/FMAを例に取ると、SSEから、オペランドモデルを変える、(..中略..)
| 簡単に言えば、RISC風のモダンな命令に切り替える。

ソフトウェアをベクタ型浮動小数点演算を多用するように書き換える、のか、
シングルイシューの多コアがうまく効くように多スレッドに書き換える、のか。
どっちが有効だろうねぇ?
0788名無しさん@お腹いっぱい。2009/05/08(金) 16:53:53
両方性能でるだろ。

Itaniumにおけるx86バイナリの実行とは、まるで違うだろ。
0789名無しさん@お腹いっぱい。2009/05/08(金) 16:57:55
>>787
とりあえずは前者だろう。
現実的に見て。

後者は、ゲームとかマルチメディアだけでなく、ワープロソフトなどにも影響を与えてしまう。
0790名無しさん@お腹いっぱい。2009/05/08(金) 17:46:29
まあ、ベクタ命令多用てのはコンパイラやライブラリーの書き換えだろうけど。
でも結局実質は x86から移行という点で Itaと同じだし、そっぽ向かれると
x86も終って Intelしゅーりょー、という目もあるわな。
Itaをもう一度くりかえす。
ただひとつだけ言えたことは、「x86 ISAはクソだった。」
おあとがよろしいようで。
0791名無しさん@お腹いっぱい。2009/05/08(金) 17:58:25
>>790
ちげーよ。
MMXからSSE2への移行と似たようなもんだよ。
0792名無しさん@お腹いっぱい。2009/05/08(金) 18:00:20
文句を言うのなら、クソなx86をストレートに拡張したAMD64をIA64にぶつけたAMDに言うべきだな。
IA64も良いものじゃないが、Intelに向かってx86がクソだって言うのはお門違いだ。
0793名無しさん@お腹いっぱい。2009/05/08(金) 18:12:23
>>792
? Intelはことあるごとに「x86はクソ」って言ってるよ。
ここらへんに巣食ってて後生大事にかばうバカがいるから、教えてやってんだよww
0794名無しさん@お腹いっぱい。2009/05/08(金) 18:17:14
SPARKサイコー
0795名無しさん@お腹いっぱい。2009/05/08(金) 18:19:40
>>791
ああ、ぜんぜん違いますよ、そんなのとは。
Intelの CPUアーキテクトが

| 今日、50%のコードがベクタライズされているとしたら、残りの 50%も
| ベクタライズしたい。(..中略..)ベクタ対応を進めて行く必要がある。
0796名無しさん@お腹いっぱい。2009/05/08(金) 18:44:49
>>793
Intelが認めているのなら、なおさら、Intelに言って認めさせようという行為はナンセンスだね
0797名無しさん@お腹いっぱい。2009/05/08(金) 18:46:20
>>795
それの分母は、
ベクタライズ可能な、ベクタライズによる性能向上が見込めるコード
だよ。

0798名無しさん@お腹いっぱい。2009/05/08(金) 18:52:30
>>797
ちげーよ。

795がコピペした部分は、AVXについての発言ではない。
ベクトル化によって性能向上を目指すのなら、現在ではベクトル化不可能なものまでベクトル化する技術を発明しなくてはならない
っていう意味。
0799名無しさん@お腹いっぱい。2009/05/08(金) 19:03:23
>>796
はぁ???? 何言ってんの? オツムだいじょーぶ? Intelになんて言ってないんだよ、
あんたに言ってんだってwwwwwwwwwwwwwwwww
0800名無しさん@お腹いっぱい。2009/05/08(金) 19:05:05
>>798
おいおいーー。後半はそうだけど、AVXについてだよー。なんでそこ分離するかな。
ベクトル化して、AVXで面倒みるんじゃんよ。ちゃんと読んでね、後藤さんの記事。
0801名無しさん@お腹いっぱい。2009/05/08(金) 19:06:05
やっぱ x86かつぐやつってアタマ悪いなw
0802名無しさん@お腹いっぱい。2009/05/08(金) 19:34:14
>>800
現時点でベクトル化できないものを、どうやってベクトル化するの? どうやってAVXで面倒みるの?

そもそも、すべてのx86命令をAVXで巻き取ったら、AVXは必要なくなる。
0803名無しさん@お腹いっぱい。2009/05/08(金) 19:37:11
>>800
釣りだろ ほっとけ
0804名無しさん@お腹いっぱい。2009/05/08(金) 20:04:02
1980年代のまだ傷が浅いうちに MC680x0 に切り替えておけばよかったんだ(´・ω・`)
0805名無しさん@お腹いっぱい。2009/05/08(金) 20:06:30
>>803
レッテル貼り乙

AVXの現物が、MMX→SSE2へのシフトと同類である以上、
AVX登場でx86と決別ということにはならんさ。
0806名無しさん@お腹いっぱい。2009/05/08(金) 20:08:05
何かキチガイのおかげで異様に伸びてるが、この1行が全てだろw
>現時点でベクトル化できないものを、どうやってベクトル化するの?
08078032009/05/08(金) 20:21:17
>>805
ああ、すまん 読み間違えてた
俺はあんたと同意見
0808名無しさん@お腹いっぱい。2009/05/08(金) 20:22:46
悲惨な思考回路だな。かわいそうに。

> そもそも、すべてのx86命令をAVXで巻き取ったら、AVXは必要なくなる。

必要なくなるのは x86命令。
念押しとくが、Intelがそう言ってるのよ、「x86 ISAはクズ」。
0809名無しさん@お腹いっぱい。2009/05/08(金) 20:25:03
いちおうパニクってるみたいだなw もう一年以上も前の記事だが。
読んどけよ、時間無駄にしたな?wwww
0810名無しさん@お腹いっぱい。2009/05/08(金) 20:25:20
>>808
AVX命令であることを示すプリフィクスが必要なくなるのよ。
そしたらそれはもう、AVXではない。
0811名無しさん@お腹いっぱい。2009/05/08(金) 20:31:39
あのー、そんなエンコーディングの方式がどうたらなんて話は
元記事の文章含めて一切してないですが。
都合の悪いことは理解しないフリする主義か?
0812名無しさん@お腹いっぱい。2009/05/08(金) 20:35:29
>>811
すべての命令をAVXで巻き取るなんて話は、
元記事の文章のどこにもありませんが。
0813名無しさん@お腹いっぱい。2009/05/08(金) 20:38:46
やっぱ後生大事に x86 ISAをかばうやつがいるだろ? あわれだよなw
0814名無しさん@お腹いっぱい。2009/05/08(金) 20:40:56
>>800は元記事を理解できてないのね。

当該の話は、AVXについてではなく、もっともっと先の将来についての話。
ベクトル化とメニーコア化どっちに進むの? っていう質問に対して、両方ヤル(どちらか片方だけでは済まない)よって話。
0815名無しさん@お腹いっぱい。2009/05/08(金) 20:41:49
>>813
あなたの脳内にいる架空の人物だね、そりゃ。

かばっているわけでもないのに、かばっていると勝手に思い込んでるんだよ、チミは。
0816名無しさん@お腹いっぱい。2009/05/08(金) 21:26:09
しかもそれが Sunのとこに貼り付いてる。キモいねぇ〜ほんと。
0817名無しさん@お腹いっぱい。2009/05/08(金) 21:31:10
>>816
っ 鏡
0818名無しさん@お腹いっぱい。2009/05/08(金) 22:17:32
Transcript of an Interview with Larry Ellison by Reuters on the Acquisition of Sun Microsystems
http://www.oracle.com/sun/lje-oracle-sun-faq.pdf

SPARCはやめへんで〜、だって
0819名無しさん@お腹いっぱい。2009/05/08(金) 23:15:01
SolarisとSPARCは、Oracle専用に成り下がるんだから
もうどうでもいい話じゃないのか?
0820名無しさん@お腹いっぱい。2009/05/08(金) 23:21:27
なるほど
0821名無しさん@お腹いっぱい。2009/05/08(金) 23:45:03
これ読むと、富士通と一緒にやりたいって言ってるから、
富士通にとっては嬉しいだろうね。

Oracleからすると、金の掛かるCPU開発は自前でやる必要が無く、
強力とはとても言えない富士通だけに自分たちの言い分は通しやすい
というおいしい関係。失敗しても、これまで通りHPと仲直りすればいい。

一方の富士通としては、鳴かず飛ばずの状況から一歩前に進む可能性の
ある千載一遇あるいは唯一のチャンスと言え、利用される立場とはいえ
乗る価値はある。

それでもドM体質の日本のベンダーのこれまでの例からすれば、
かなり有利といえるかと。
0822名無しさん@お腹いっぱい。2009/05/08(金) 23:55:41
Oracleプロセッサは富士通にどんなメリットがあるん?
0823名無しさん@お腹いっぱい。2009/05/08(金) 23:56:01
H*-UX ますます使い道なくなるね。
0824名無しさん@お腹いっぱい。2009/05/09(土) 00:04:47
これまで)
富士通のサーバ?
→そんなマイナー系、買う訳無いだろ。
これから)
Oracle(中身は富士通)のサーバ?
→OracleDB動かすのにOracle製なら安心だし買うか。

位の意味はある。
H*-UXがハイエンドでそれなりに強い理由としては、そのゾーンでは
Oracleが推してたって事情はあるからな。
0825名無しさん@お腹いっぱい。2009/05/09(土) 00:37:13
>>818
なんかヤバいな。

> We want to work with Fujitsu
> to design advanced features into the SPARC microprocessor
> aimed at improving Oracle database performance.

Rock消えたか?
0826名無しさん@お腹いっぱい。2009/05/09(土) 00:56:31
まずRockを完成させることから富士通の仕事が始まりますw
0827名無しさん@お腹いっぱい。2009/05/09(土) 00:58:36
>>825
>なんかヤバいな。

いや、むしろgdgdなRockをドサクサに紛れて「無かった事」にしてくれる
Oracleは救世主だろうw
0828名無しさん@お腹いっぱい。2009/05/09(土) 02:09:40
なかったことになんてできないだろ
今から新コア作り始めても出荷まで2-3年は必要
間を埋める玉はRockしかない
もしOracleがSunに完成させる能力がないと見切れば
富士通にRockの完成も手伝ってくれと言うに決まってる
0829名無しさん@お腹いっぱい。2009/05/09(土) 03:32:05
なんでOracleがCPU造る必要あるん?
富士通にやらせときゃえんちゃう?
0830名無しさん@お腹いっぱい。2009/05/09(土) 06:08:42
Sun+富士通:SPARC 設計
Sun:Solaris 開発
Oracle:Oracle 開発
富士通:SPARC Server, Solaris, Oracle サポート

今までの業務提携がより密になるってことだから正に win-win な関係じゃない
0831名無しさん@お腹いっぱい。2009/05/09(土) 06:22:07
SunはSPARCの開発しなくていいよ。
Solarisとピザボックス, ランチボックスの開発だけしてくれw
0832名無しさん@お腹いっぱい。2009/05/09(土) 06:28:58
CPUの開発能力は維持しないとダメだろ>Sun
実際に作るかどうかは関係ない
0833名無しさん@お腹いっぱい。2009/05/09(土) 08:06:29
phase1: Oracleと富士通でSPARCの共同開発を発表。SPARCの将来にコミット。
phase2: OracleはSPARC開発の投資を中止。代わりに開発リソースを富士通へ移管。
phase3: 富士通大赤字でCPUの開発から撤退。
■ このスレッドは過去ログ倉庫に格納されています