【Oracle】故Sun Microsystems 最大の墓標

1 名前：名無しさん＠お腹いっぱい。 [2010/04/22(木) 07:01:01 ] (-人-)ナムナム 【前スレ】 Sun Microsystems 最大の解雇 pc12.2ch.net/test/read.cgi/unix/1263808782/ 454 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/05(木) 23:08:43 ] ARMが勢力を伸ばせばSPARCの失地回復がなるとでも思っているのかしら？ 455 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 02:23:44 ] ARM（笑） 456 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 11:26:14 ] >>451 > おいおい>>438や>>446が見えなかったのか? > >>441も見えてないようだな 見た? アホか。中身ゼロなんだよ、おまえのオツムといっしょでw 457 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 11:26:58 ] >>454 x86コケにするとムキになるやつからかうとほんとオモロイwwww 458 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 11:30:56 ] SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! 459 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 12:40:50 ] また3連投か >>456 見てないんだな。中身ゼロだと決め付けて、見てないんだな。 もし見たうえで言ってるなら、頭おかしいんだろうな。 お前がSPECは実戦的じゃないと言うので、実戦的なベンチマークの話をしてるのになー。 460 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 18:50:36 ] SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! SPEC_rate! 461 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 19:05:24 ] 科学技術系に閉じた文脈でもないのに SPEC*_rateの自慢してるバカは お前以外に見たことないんだが。 【レポート】Intel Woodcrestの性能 (1) SPECint journal.mycom.co.jp/articles/2006/06/06/woodcrest/index.html : | また、SPECint_rateとrateが付いている方は、システム内の全プロセサで | SPECintのプログラムを並列に動作させて総合スループットを測るのであるが、 | rateなしの方は、基本的に1個のプロセサコアだけで実行される。 : | 最近のプロセサは内蔵するキャッシュが大容量化し、SPECintのプログラムの | 大部分はキャッシュに収まり、殆ど、CPUコアの整数演算プログラムの | 処理性能が見えると言われている。 まあ、意味わかんねえんだろうがなwwwwwwwwwpw 462 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 19:12:22 ] マイコミ（笑） 463 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 19:21:46 ] そっとしておいてやれよ ttp://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B9%E3%83%9A%E3%83%AB%E3%82%AC%E3%83%BC%E7%97%87%E5%80%99%E7%BE%A4 464 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 20:34:48 ] >>461 なんでSPEC*_rateに執着してんの? TPC-CとかTPC-Eの話は、見えないの? 465 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 23:03:16 ] TPCって何か知らないんじゃね？ 466 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/06(金) 23:19:41 ] しーっ 触っちゃ駄目って言ってるでしょ！ 467 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 03:01:59 ] いやいや、SPEC*_rate並べてるバカがいたんだよ。 : 君だけど。ぷ ...ブーーww SPEC*_rate値がリニアじゃないマシンなんて話にならんのだがwwwwwwwwwwwkwkwkw 468 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 03:35:20 ] いつのまにかx86 vs SPARCのスレになってるな Solarisの話をするやつはいないのか？ 469 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 03:44:54 ] OpenSolarisもforkしたし、話題は無いんじゃね？ 470 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 05:28:30 ] いつの間にかって程でもないし vs SPARCって程でもない（もう相手にならんしｗ） 471 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 10:47:31 ] >>467 >　SPEC*_rate値がリニアじゃないマシンなんて話にならんのだが M9000でリニアに伸びるのは32CPUまでで、64CPUになるとサチるんだが・・・。 それにしてもx86、だいぶリニアに近い領域が広くなったよなー。 話にならないと馬鹿にしていたものが、馬鹿にできなくなってきたなー。 しかもSPARCの32ソケットに対してx86は8ソケットでしょう? ソケット数が多く必要なら、リニアに伸び続けないと話にならないが、 ソケット数が少なくて済むなら、リニアに伸びなくなる手前の領域で使うから、リニアに伸び続けなくても困らないんだよなー。 このままSPARCの性能向上が鈍化したまま、x86の性能が倍加すると、 SPARCだとラック1本、x86だと4Uサーバ1台ってなことになっちゃうぞ。 472 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 11:29:01 ] Xeon最強！ 473 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 11:57:48 ] x86 vs SPARCはおかしい だってOracleだってXeonサーバ作ってるからな 474 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 11:59:23 ] その上、一応上に上がってるSPEC CPU2006の結果では Solarisの乗ってるOracleのXeonサーバが最高値出してる 475 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 12:06:44 ] Xeon最強！SPARCイラネ！ 476 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 12:14:47 ] >>473 つか、OracleはSPARCに対し、とっくに見切りをつけている。 477 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 12:19:12 ] さすがはOracle！ 478 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 13:26:36 ] SMPサーバの処理速度は、メモリで決まる、と言っても過言ではない SPARCが優れているからスループットが高いというよりは、 SPARCサーバがメモリコントローラ&モジュールを大量に積んでいるからスループットが高い x86サーバでも、コンカレントに動作する複数のメモリコントローラを大量に積めばスループットが出る それを実証しているのがXeon7500番台を採用したサーバ 479 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 18:57:58 ] Xeon7500番台のサーバが他のハイエンドサーバに比べて安いのは 8ソケットまで対応したチップセットをIntelが提供してるからだろ だけどIntelにとっては数が出ないと採算あわないんじゃないの？ 480 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 19:32:18 ] >>479 HPのDL980 G7は8ソケットだけど、HP独自のグルー・チップを使って、スケーラビリティを確保してるよ。 8ソケットまでグルー・レスというけど、性能を出そうとしたり、可用性を高めようとするなら、グルー・チップが必要になる。 チップセットに関しては、チップセットといってもQPIとPCI Expressブリッジみたいなもんだから、ソケット数に関係ない。 481 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 20:58:04 ] F通もSPARCに対して見切りをつければいいのに。ものづくり(笑) 482 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 21:30:48 ] >>480 それだとItaniumサーバ並の価格にならないか Itaniumサーバと比べてどれくらい安くなってるの？ 483 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 21:37:44 ] Itaniumで同等性能を得ようと思ったら、64CPUとかになっちゃうと思う。 だから、Itaniumサーバよりは安いんじゃないかな。 484 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 21:39:04 ] >>481 既に富士通はPrimeQuestシリーズをItaniumからXeon7500シリーズに変更してる 富士通がハイエンドサーバーPRIMEQUESTの新版、CPUをItaniumからXeonへ変更 itpro.nikkeibp.co.jp/article/NEWS/20100331/346499/ 富士通はItaniumを搭載した旧モデルの販売を今後も続けるものの、 「従来の機種を生産し続けるだけで、新しいItaniumが出ても搭載機を出すことはしない。 2010年2月に出た『Itanium 9300番台』を搭載する予定もない」（河部本本部長）という。 485 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 22:24:04 ] >>479 モジュール使いまわしてるからXeonMPのデザインコストはかなり低いだろ 数が出ないと苦しいどころかチップセットで埋まるはずの古いプロセスにプレミア付けて売ってる状態 486 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/07(土) 22:30:18 ] ハイエンドでXeonが普及するということはWindows ServerやLinuxが ハイエンドで普及するということで 独自のOSを持たない日本のサーバメーカーにとっていい話ではあるな 487 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/08(日) 12:26:30 ] >>482 ItaniumとXeon7500じゃ、出荷台数が1桁から2桁は違うだろうから、製品価格に乗せる開発費は小さくなるだろう。 それに、用途もハードウェアの作りも保守体制やアップグレード等々なども違うだろうから、製造コストだけでは値段は決まらないだろう。 >>484 富士通はPRIMEQUESTをXeonに変更して価格1/3とか言ってたような。 >>485 技術者の経験を使いまわしている点も大きいよ。 富士通がSPARC64やれるのも、メインフレームのGPと同じ部隊が経験を共有してるからこそだろう。 488 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/08(日) 22:44:44 ] >>486 PCと一緒で台湾に仕事奪われるだけだろ 489 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/09(月) 16:41:11 ] ハードウェアは輸入でもいいが、ソフトウェアや構築、サービスなどは輸入できないので、そこで稼げばいいんですよ・・・というのが日本のIT しかも、ユーザー側がアホなので、変な要求仕様でコストを跳ね上げたり、ITゼネコンを間に入れないと仕事の発注すらできないテイタラク 490 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/10(火) 23:35:19 ] それってIT業界的には安泰なのかもしれないが 日本の国家としての競争力的にはどうなんだ？ 491 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 07:16:58 ] >>489 なりたくてなったわけじゃないと思うけどね ＩＢＭにもインテルにも勝てなかったから >>490 IT業界は安泰じゃない 492 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 12:53:56 ] 日米半導体摩擦で、NECがx86互換CPUをやめたんだよなー。 大人しくセカンドソース作っていれば良かったのに、 勝手にバグ修正する(互換性を損なう)とか、 セカンドソース契約せずに互換CPUを作るとか、 本家よりも高速な互換CPUを作るとか、 本家の商売の邪魔をするような振る舞いをしたから潰されたのだと思う。 493 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 13:21:50 ] >492 そんな企業は山のようにあったし、それぞれ判断も根拠もたどった道も ぜんぜん違うので、なんの説得力もない。バカ? その後も MIPSアーキでいいの作ってたし。 むしろ HPの OEMなんかやる必要なかったんじゃないかと思う。 494 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 15:56:24 ] >>493は、いつものアレなんでスルーしましょう 495 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 18:10:57 ] ttp://www.geocities.jp/andosprocinfo/wadai10/20100807.htm > 2010年8月5日のThe Registerが， > Oracleが旧SunのHPC営業の大部分の人員を先週レイオフしたと報じています。 > また，残っている人もHPCではなく，ExaData V2の販売に回されているそうです。 > これ以上の情報は無いのですが， > HPのx86マシンへのSolaris OEMを切り，IBMもx86 Solarisを止めるという報道が流れており， > Oracleは手間の割に儲からない商売をたたみに掛かっているようです。 SunのHPCって、 現行x86CPUと将来リリース予定のSPARC CPUの性能比較をしてみたり、 実在しないブレードサーバ (現状ではT2が1CPUで一杯のサイズのブレードにT2を4つ入れ、しかもSMP動作させる) を紹介したり、 なんともエグかったな。 結局、導入されたのはx86のブレードだった。 Sunの宣伝通りなら、演算性能が低く、それでいて消費電力がデカいはずなのに、ユーザーはx86を選んだ。 まぁ、実在しないものを買うことは、できないもんな。 496 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 18:59:32 ] HPCwww たいして儲けにもならんw PCしか使わんやつはこれだからpppp 497 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 19:01:57 ] >>494 なんでそう世間知らずなのをこんなところで発表したいの? 心底メイワクなんだが。 498 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/11(水) 19:37:06 ] >>496と>>497は、いつものアレなんでスルーしましょう。口汚く煽るだけの(彼の言葉を借りれば)「低能」ですから 499 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/12(木) 09:57:59 ] 低脳。プ 500 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/12(木) 22:57:53 ] Oracle、SPARCと「Solaris 11」の計画を明らかに (1/2) ttp://www.itmedia.co.jp/enterprise/articles/1008/12/news053.html まだやる気あるようだぞ 501 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/12(木) 23:10:43 ] フリー版が消えたSolarisにもう新規ユーザーはつかないだろ。 既存ユーザから保守料ぼったくるか、Oracleと抱き合わせ販売するか。 502 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/12(木) 23:19:47 ] Oracle: We Have Aggressive Roadmap for Sun SPARC Processors. www.xbitlabs.com/news/cpu/display/20100811154837_Oracle_We_Have_Aggressive_Roadmap_for_Sun_SPARC_Processors.html T3の次はシングルスレッド性能がT3の3倍だってさ 簡単に言ってくれるじゃないの 503 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/12(木) 23:23:01 ] T3はまだでてないんだろ。 T3をT2plusの1/3の性能で出荷して、あとで戻すだけで3倍じゃん。 504 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/13(金) 00:47:36 ] Appleよりもすげぇな… 505 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/13(金) 17:57:24 ] Oracleが「AndroidはJavaの知的所有権を侵害」とGoogleを訴える hoshi.air-nifty.com/diary/2010/08/oracleandroidja.html 旧Sun部門のニュースですよ皆さん 旧Sunの人はgoogleにも多くいますけど 506 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/13(金) 18:02:40 ] 本性を現したか。 507 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/13(金) 18:21:59 ] googleがキレてOracleを丸ごと飲み込んでくれないかな、と妄想してしまう 508 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/13(金) 18:50:07 ] Oracleもバカだな Googleはますますフリーな実装に力を入れるだけじゃん 509 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/14(土) 07:01:15 ] ttp://hoshi.air-nifty.com/diary/2010/08/googleoracleand.html この記事のコメント 落としどころがJavaFXをAndroidに実装させるというのは悪くない ただOracleとしては買収したSunの遺産の知的所有権をはっきりとさせ カネを引き出す必要はあるから 多少乱暴な振る舞いになっても仕方ないんじゃない 別にエンドユーザを訴えたわけじゃないし Sunにお人よしに振舞わせ続けたかったなら もっと製品を買ってやれば良かったんだから 今から嘆いても後の祭りでしょ 510 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/14(土) 07:44:54 ] 結局のところ、Oracleは実装のコピーの指摘なんかしか出来ないと思うんだけど、 勝算あんのかね？ DalvikってクリーンルームでしかもVMの互換性がない程度に別物なのに どこかのSCOと同じ様な事になりそうな気がするんだけど 511 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/14(土) 09:24:07 ] 特許と言ってるからにはクリーンルーム手法ではクリアーできないんだけど。 Javaが特許で囲われた技術だ、と自分で言ってしまって、自分で自分の首を絞めてるよねぇ。 512 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/14(土) 09:28:54 ] OpenJDKどうなってしまうの？ 近い将来までは影響あんま無さそうではあるけど、ポリシーのずれが… 513 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/14(土) 14:06:20 ] GoogleはOracleのパテント訴訟を根拠レスと一蹴, オープンソースいじめの悪行と呼ぶ jp.techcrunch.com/archives/20100813android-oracle-java-lawsuit/ Goslingおじさんは疲れっぱなしである 514 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/14(土) 21:07:56 ] >>512 GPLv3だから大丈夫じゃない?特許についても 515 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/14(土) 23:54:24 ] パッケージソフトウェアとライセンスで儲けてる会社は ネットワークサービスと広告で儲けてる会社と利害関係は一致しないんじゃない OracleからのJ2MEライセンスをGoogleがけった時点で訴訟は仕方がない GoogleはOSSをライセンス回避の手段として使ってるだけで コミュニティ(笑)を振り回すのはお門違いと思うけどね GoogleのようにTCO削減のために自社でサーバを設計しちゃうような会社は 訴訟に及ばずOracle製ハードウェアの大量購入を期待するのも望み薄だろう 516 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/15(日) 01:27:49 ] JavaがAndroidに必須ならSunが売りに出たときに Googleが拾えば良かった訳で それをしなかったのはGoogleの判断ミスだろ むしろ他社の知的所有権を蔑ろにした挙句 自作自演のコミュニティ(笑)を人質に 一方的にOSSの擁護者かつ被害者になろうとするGoogleの方が悪質 技術をタダでばら撒いて大物ぶりたいなら 素直にSunを買ってその技術を全部OSSにし 他社からの知的所有権侵害にも目をつぶればよかったろうに 517 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 01:31:25 ] Googleが突っぱねてもハードウェアメーカーがOracleとライセンス契約する可能性はあるかもな 携帯電話メーカーとしてはAndroidは既になくてはならない製品だからな 518 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/15(日) 01:45:59 ] そうね 個別にライセンス契約する道はあるね 大手の携帯電話会社はほとんどJ2MEのライセンスも受けているわけだし それで訴訟リスクと既得権益が守れるなら安いね 日本の現状なら自作PCみたいにSIMカード載せかえで 安く携帯の本体を履き替えるのは 一般的にはならないと思うが まぁこの不況ならなにが標準になるかは分からんけど 519 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 09:45:11 ] 金取るのは別に悪くないと思うんだけどやり方が下手。 520 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 10:13:14 ] OpenSolarisが逝ったらしいですね ご冥福お祈りします opensolaris.org/jive/thread.jspa?messageID=496203&tstart=0 Illumosがんばれ 521 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 10:28:30 ] カーネル開発は難しいが、Illumosにはそれだけの開発者がいるのだろうか？ あと、パッチはBSDライセンスでとか・・・、タダ働き要求かよ。 522 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 11:07:40 ] Solaris 10/11 が従来通りのライセンスに戻ればそれでいいよ。本スレ的には。 523 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 12:19:50 ] とりあえず今足りない部分についての開発は出来るかも知れないけど、それ以降はどうするんだろうね。 OpenSolarisベースでやってたところとは協力関係にあるので、がんばって欲しい。 BSDLにしておけば*BSDで取り込みやすいとかあるの? 524 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/15(日) 13:19:18 ] >>519 HTCを訴えたAppleのようなやり方がいいか？ 結局弁護士費用は消費者が払うことになるのは同じだがね AppleとOracleが組んでGoogle潰しをするのは悪い話ではないが 525 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 18:48:29 ] オープンといっても、しょせんは・・・ねぇ。 526 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/15(日) 19:11:57 ] 今の彼女は君が知ってる昔の彼女ではないってことに傷ついた感じ？ｗ 527 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 19:15:45 ] はぁ? 彼女の中身は何一つ変っていないが、昔は正体を分からなかった、それだけのことよ。 528 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/15(日) 19:26:54 ] ヤクザの女にされた昔の憧れの君　高嶺の花 中身は変わったんじゃない 落ちぶれて変えられたんだ 529 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 19:27:08 ] 彼女は富豪に買われて変わってしまっただけのこと 530 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 19:41:31 ] 暖かくお前たちを照らしていた太陽は もう、ない お布施をケチってこうなった気分はどう？ｗ 531 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/15(日) 23:42:29 ] Sun信者キモ 532 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 07:19:20 ] java.sun.com/javase/ja/6/download.html なんかjdk,jreのダウンロードがログインなしで出来なくなってるっぽいんだが、 本気でjava潰す気なんかね？oracleは 533 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 08:24:57 ] Java終了だな マイクロソフト大喜び 534 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 08:26:04 ] オープンソースはスクリプト系言語にシフトしていきそう 535 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 09:15:54 ] Javaは最早無くなってもいい言語 JVMさえあればなんとでもなる 536 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/16(月) 10:58:24 ] >>532 英語読めないカタワがデマばら撒いてんじゃねーよ jaに飛ぶとかどんだけ情弱なんだよksg 貼っといてやるから翻訳機にでも掛けてみろ Optional: Please Log In or Register for additional functionality and benefits. Or, click "Continue" now to proceed without Log In or Registration. 537 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 13:31:00 ] ログインするとなんかまずいの？ 538 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 18:23:06 ] >>536 マジで一時的に不可能になってたんだよコンチクショー タイミングの問題だタイミングの 539 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/08/16(月) 21:27:21 ] >>538 そーか 直ってんならよかったな ムダに熱くなって悪かったな 540 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/16(月) 21:34:35 ] こちらこそ早漏ですまなかった 541 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/18(水) 20:22:23 ] IBM、最大1024スレッドを同時実行する「Power 795」サーバーを発表 itpro.nikkeibp.co.jp/article/NEWS/20100818/351264/ 542 名前：名無しさん＠お腹いっぱい。 [2010/08/24(火) 22:39:37 ] OpenSolaris理事会が解散--オラクルの対応に不満募らせ japan.cnet.com/news/business/story/0,3800104746,20418791,00.htm 543 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/30(月) 13:02:52 ] SunのSPARCよりも、 PanasonicのUniPhier(松下オリジナルCPUのデュアルコア + メディアエンジン等々の統合LSI)のほうが、 最先端プロセスで製造されている件 UltraSPARC T2 2007年に65nm PanasonicのUniPhier、2007年に65nmから45nmに移行 UniPhierは年内に32nmに移行予定なんだが、SPARCは現在も65nmが現行。 544 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/31(火) 09:57:39 ] Itaとか。 その UniPhierとか持ち出すと、何が比較できると思ってるわけ? 545 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/31(火) 21:44:39 ] Itaniumは古いプロセスで作ってるから遅いままじゃん。 家電のシステムLSIにも遅れを取るほど、Sunは使えるプロセスが古いってことよ。 つまり、それだけx86やPOWERとの速度差が開くってこと。 546 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/31(火) 22:08:22 ] SunがFabもっているわけじゃないので、使えるプロセスうんぬん半分は的外れ。 ただ、微細化されたプロセスのFabを使わないのは、新しくCPUを製造するぐらいの ロットが揃わないのかもしれないし、採算の問題があるのかもしれないし、プロセスに 合わせて設計を変えていかないときちんとシュリンクできないので、設計を変える 余裕が無いのかもしれないしってことで、プロセスが古い云々というよりも新しいCPUを 出せないこととして考えたほうがいい。 547 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/31(火) 23:28:47 ] 自前でfabを持たない会社はCPUなんか作っちゃイカンってこったね。 548 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/31(火) 23:30:48 ] ARM「え？」 549 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/08/31(火) 23:44:01 ] ハイパフォーマンスCPU 550 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/09/01(水) 00:00:52 ] >>545 携帯端末の方がx86よりずっと進んだプロセスルールを使ってるのは昔からじゃん 今更そのネタかよｗ Itaniumが古いプロセスで作ってるから遅いとか… どう突っ込めばいいのか針が多すぎてもうね 551 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/09/01(水) 00:12:09 ] Javaがたちあがりゃ、Oracleの赤いロゴは出てくるわ Sunってもう風化してるね 552 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/09/01(水) 00:23:08 ] >>550 32nmよりも微細なプロセスで作られている携帯端末って何? 553 名前：名無しさん＠お腹いっぱい。 mailto:sage kani? [2010/09/01(水) 00:39:28 ] TSMCのCLN28LPとかそんなんやろ 計画通りならもう出荷してるはず どれに積んでるかとかは知らん 554 名前：名無しさん＠お腹いっぱい。 mailto:sage [2010/09/01(水) 00:49:33 ] 28nm詐欺

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef