Sun Microsystems 最後の理不尽
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。
05/03/16 07:43:34【過去スレ】
Sun Microsystem最大の失態
http://pc.2ch.net/test/read.cgi/unix/1006171354/
Sun Microsystems最大の敗退
http://pc.2ch.net/test/read.cgi/unix/1064134161/
Sun Microsystems最大の反省
http://pc.2ch.net/test/read.cgi/unix/1067603469/
Sun Microsystems最大の虚勢
http://pc.2ch.net/test/read.cgi/unix/1073745032/
Sun Microsystems最後の航海
http://pc3.2ch.net/test/read.cgi/unix/1078795800/
Sun Microsystems最後の晩餐
http://pc5.2ch.net/test/read.cgi/unix/1083085439/
Sun Microsystems ラストダンス
http://pc5.2ch.net/test/read.cgi/unix/1086081133/
Sun Microsystems 最後の反撃
http://pc5.2ch.net/test/read.cgi/unix/1088605878/
Sun Microsystems 最後の一葉
http://pc5.2ch.net/test/read.cgi/unix/1094886926/
だまれ小僧!お前にサンが救えるか
http://pc5.2ch.net/test/read.cgi/unix/1103972661/
他にもあれば補足よろしく。
0002名無しさん@お腹いっぱい。
05/03/16 08:23:420003名無しさん@お腹いっぱい。
05/03/16 19:26:010004名無しさん@お腹いっぱい。
05/03/17 00:28:580005名無しさん@お腹いっぱい。
05/03/17 01:15:110006名無しさん@お腹いっぱい。
05/03/17 09:49:390007名無しさん@お腹いっぱい。
05/03/17 19:01:00> NFSv4 に期待!
> Solaris10 頑張れ!
> unix 厨ならnasだろーがっ!
ワラタ
0008名無しさん@お腹いっぱい。
05/03/17 20:23:55Sunのストレージはダメなんでつ。
OracleがNetAppを採用した時点で当面のスタンダードは決まりでつ。
0009名無しさん@お腹いっぱい。
05/03/17 20:39:17FC-SAN 推奨であって NAS は推奨してないと思うが。
Linux が Linus の昔からのこだわりを捨てて raw デバイス
を実装したのも、Oracle 方面からの要望があったからなん
でしょ?
ファイナルファンタジーの件も、少なくとも Oracle 側の
提案ではないんじゃないの? Oracle としては、あからさまに
お客様の構成の悪口を言うわけにもいかないから、おべっか
を使ってたみたいだけど、裏ではむしろ呆れてるんでは?
0010名無しさん@お腹いっぱい。
05/03/17 20:57:30NetAppの工作員が紛れこんでるような希ガス
0011名無しさん@お腹いっぱい。
05/03/17 21:10:03希ガス全部言える?
0012名無しさん@お腹いっぱい。
05/03/17 21:12:23He Ne Ar Kr Xe Rn
0013名無しさん@お腹いっぱい。
05/03/17 21:13:00He, Ne, Ar, Kr, Xe, Rn のことか?
0014名無しさん@お腹いっぱい。
05/03/17 21:17:15一生忘れませぬ
0015名無しさん@お腹いっぱい。
05/03/17 21:19:510016名無しさん@お腹いっぱい。
05/03/17 21:36:160017名無しさん@お腹いっぱい。
05/03/17 21:38:45オメ何にも知らねぇんだな。
ttp://www-jp.netapp.com/news/press/2004/news_rel_20040127.html
0018名無しさん@お腹いっぱい。
05/03/17 21:56:48これってOracle社の開発環境にNetApp使ったってだけだよね。
0019名無しさん@お腹いっぱい。
05/03/17 22:01:55ふっくらブラジャー愛の後、もよろしこ
0020名無しさん@お腹いっぱい。
05/03/17 22:23:41認めたくない香具師だな。
ちったぁぐぐってみ。少し古いけど。
ttp://www-jp.netapp.com/tech_library/3023.html?fmt=print
0021名無しさん@お腹いっぱい。
05/03/17 22:40:27> 4.2 パフォーマンス
>
> まず第一に、NetApp ファイラーを使用することで、データベース・サーバが
> ローカルのファイル・システムや RAID ストレージを管理するために、貴重な
> CPU サイクルやメモリを使用する必要がなくなりました。このため、貴重なリ
> ソースを他のデータベース・サーバ機能のために使うことが可能になりました。
raw デバイスを使う場合、そもそも「ローカルのファイル・システム」なんて
ものは存在しない。DAS でも FC-SAN でも、ハードウェア側が RAID 機能を
サポートしていれば、サーバOS側では「RAID ストレージを管理」する必要も
ない。つまり、ここで「CPU サイクルやメモリを使用する必要がなくな」った
というのは間違い。
NAS を使うと、むしろ、NFS クライアントコードのために、「貴重なCPUサイ
クルやメモリ」を無駄に割かざるを得ない。
0022名無しさん@お腹いっぱい。
05/03/17 22:45:24> ン環境でローカル・ディスクよりもデータに早いアクセスを提供します。例
> えば、NFS パフォーマンスの SPEC SFS ベンチマークで明らかになった結果
> のように、NetApp ファイラーは、平均10ms (あるロード・レベルでは 2ms
> 以下) という素晴らしいレスポンス・タイムを示しました。NFS に代わるロー
> カル・ディスクでの平均検索時間も10ms 以下です。
ここ、良く読んでみよう。
NetApp を使った場合:
平均10ms (あるロード・レベルでは 2ms 以下)
ローカル・ディスク:
平均10ms 以下
なんだ、実はローカルディスクの方が速いじゃん。
NetApp が 2ms 以下で済むのは、大容量のキャッシュを積んでいるおかげで、
ディスクアクセスなしでデータを返すことができることがあるから。
でも、今やハイエンドの DAS や FC-SAN は、RAID 側に大容量のキャッシュ
を積んで同じようにディスクアクセスを避けることができる。
つまり、同じだけRAMを積めば、DAS や FC-SANの方が結局速い。
0023名無しさん@お腹いっぱい。
05/03/17 23:58:16この通りなんだけど、DAFS を使えば、この問題はほとんど
回避できる筈。DAFS は NFSv4 をベースにしているんだけど、
肝心のデータ転送には VI の Remote DMA 機能を使うので、
プロトコル処理のオーバヘッドをバイパスできるから。
あとは、ネットワークのバンド幅が足りるかが問題かな。
バンド幅重視の場合は、DASがやはり一番有利。ただデータ
ベースの場合、バンド幅よりもトランザクション数の方が
重要なケースの方が多いんだけど。
002423
05/03/18 00:00:00> NAS を使うと、むしろ、NFS クライアントコードのために、
> 「貴重なCPUサイクルやメモリ」を無駄に割かざるを得ない。
のことね。
0025名無しさん@お腹いっぱい。
05/03/18 00:08:50Dellって、そういう NIC をサポートしてたっけ?
0026名無しさん@お腹いっぱい。
05/03/18 00:24:16snapshotとかbackupとか、ローカルでやるとウザイ事はウザイよ。
まあ今時パフォーマンスうんぬんって領域でテープにバックアップすることもないだろうが。
0027名無しさん@お腹いっぱい。
05/03/18 00:42:35ttp://www.atmarkit.co.jp/fnetwork/tanpatsu/07dafs/dafs01.html
バンド幅もCPU利用率も10倍違いますな。
これ、Linux 2.4.9 なんだけど、DAFS って、Linux に統合されて
ないよねえ? 富士通内部開発の奴なのかな? NICも富士通製?
0028名無しさん@お腹いっぱい。
05/03/18 00:48:56そのURLの内容は読んでないけど(w
uDAFSってNetAppの製品でしょ?
http://www.netapp.com/news/press/2003/news_rel_20030203.html
つーか、ここはおじいさんの集まりか? SANかよ!?
0029名無しさん@お腹いっぱい。
05/03/18 00:53:010030名無しさん@お腹いっぱい。
05/03/18 01:04:35出てたけど、答がなかったねえ。
http://pc5.2ch.net/test/read.cgi/unix/1013887884/366
実は2chなんかに書き込んでる連中は、誰も使ってない?
0031名無しさん@お腹いっぱい。
05/03/18 01:14:44わざわざ英語読まなくても日本語のニュースリリースも出てるよ。
ttp://www-jp.netapp.com/news/press/2003/news_rel_20030203.html
ユーザレベル実装(uDAFS)はNetApp製だけど、
Linuxのカーネル実装(fDAFS)は富士通製ってあるね。
0032名無しさん@お腹いっぱい。
05/03/18 05:10:48オメほんとに何も知らないんだな。
NetAppの速さはNVRAMだけじゃなくWAFL(Write Anywhere File Layout)といって
ディスク書き込み時に連続したBlockに書く機能によるところもあるので、
キャッシュにヒットしない場合も十分速い。
常にキャッシュヒットする事はまずないから、実用的にはNetAppの方が速いよ。
003322
05/03/18 06:14:29ファイルシステムでしょ?
UNIX の通常のファイルオペレーションには確かに向いてる
と思うけど、データベースみたいに、ディスク書き込みが、
既存ブロックに対するランダムな書き換え主体の場合は、
たいしてアドバンテージが期待できないんじゃない?
B+tree って、リーフノードをシーケンシャルに割り当てる
ことによって、逐次スキャン時のアクセス性能を稼ぐもの
だけど、リーフノードの書換え時にブロックを移動させて
しまったら、書き換えてない部分と書き換えた部分で
シークが必要になって、かえって遅くなる筈。
逆にこういう場合にブロックを移動させないなら、既存の
ファイルシステムと同じだから、WAFL の利点がなくなる
わけだし。
0034名無しさん@お腹いっぱい。
05/03/18 07:36:45「B+tree」ってB-tree+のこと?ちがうの?
0035名無しさん@お腹いっぱい。
05/03/18 07:50:05参考:
ttp://www.atmarkit.co.jp/flinux/rensai/fs02/fs02a.html
0036名無しさん@お腹いっぱい。
05/03/18 12:20:000037名無しさん@お腹いっぱい。
05/03/18 12:46:15宣伝はよそでやれ
0038名無しさん@お腹いっぱい。
05/03/18 13:21:500039名無しさん@お腹いっぱい。
05/03/18 18:39:17いまさら、rawなんて・・・
0040名無しさん@お腹いっぱい。
05/03/18 18:44:17相変わらずだなあ。
CPU使用率も比較して評価してみたの?
トランザクション数だけしか比べてないんじゃない?
0041名無しさん@お腹いっぱい。
05/03/18 18:54:410042名無しさん@お腹いっぱい。
05/03/18 19:18:150043名無しさん@お腹いっぱい。
05/03/18 19:20:040044名無しさん@お腹いっぱい。
05/03/18 20:41:020045名無しさん@お腹いっぱい。
05/03/18 20:54:15SunもOracleも相互にブランド力を頼って、どさくさに紛れて売り込む案件
を狙っている希ガス。
0046名無しさん@お腹いっぱい。
05/03/18 21:07:28Oracleは前年比10%超の回復基調だぞ。斜陽のSunといっしょにされちゃ困る。
IBMに取られてたLinux向けのdbのシェアを取り返したから。
社内の開発環境もSolaris→Linuxに切り換えたし。
0047名無しさん@お腹いっぱい。
05/03/18 21:08:33>>37
すみませんね。
でも現状ではSunとNetAppの組合せが最高だと思いまつ。
ある意味ネットアポーは他人のふんどしで相撲をとってる感じですかね。
ファイラーだけじゃ何もできませんからね。
0048名無しさん@お腹いっぱい。
05/03/18 21:10:44Linuxにも急接近してるし
といっても、最近の企業はどこもLinuxに急接近してるからあれなんだけど
0049名無しさん@お腹いっぱい。
05/03/18 21:16:12コミュニティベースで開発が続いているPHPに最近IBMはかなり資金投入した
IBMはそのPHPを持ち出して、Java批判を繰り返す
IBMめ、調子乗るな!!!!!!!!
0050名無しさん@お腹いっぱい。
05/03/18 21:19:51んなこと言ったら、スイッチ売ってる会社はどうなんだよ?
0051名無しさん@お腹いっぱい。
05/03/18 21:21:14もうブランド力もSolarisもSPARCも何の力にもなりません。
せめてJavaだけでも見逃してください>IBM様
0052名無しさん@お腹いっぱい。
05/03/18 21:22:48PHPで、批判されても苦笑するしかないな。
PHP悪かぁないが、規模と応用範囲が全然違う。
0053名無しさん@お腹いっぱい。
05/03/18 21:32:33FC-SANはNFSとは関係ねーよ。
>>51
JBossの開発者も言ってるけど、Javaはコミュニティベースにする必要は
ないと思うよ。
Sunは現状うまくコントロールしてる。
OSと違って言語仕様は開発元の限られたメーカがコントロールした方がイイだろ。
0054名無しさん@お腹いっぱい。
05/03/18 21:55:15コントロールできてれば開発元じゃなくてもいい...
ような気もします。
0055名無しさん@お腹いっぱい。
05/03/18 22:04:080056名無しさん@お腹いっぱい。
05/03/18 22:07:37元々は組み込み(だっけか?)向けに開発された言語だけど
うまくnetに対応させてるので、Javaの設計センスの無い香具師に
変に拡張されていくよりはイイと思います。
コミュニティベースだと、どうしても最大公約数的になるので
Java本来の言語仕様が失われてゆく気がします。
0057名無しさん@お腹いっぱい。
05/03/19 01:01:380058名無しさん@お腹いっぱい。
05/03/19 01:11:420059名無しさん@お腹いっぱい。
05/03/19 01:21:11問題はSunが無くなってもJavaは生き残るだろうが、Javaが無くなるとSunは
生き残れないだろうことだ。
0060名無しさん@お腹いっぱい。
05/03/19 02:00:29> コミュニティベースだと、どうしても最大公約数的になるので
CommonLisp (泣
0061名無しさん@お腹いっぱい。
05/03/19 06:04:18・SunがJavaをオプソ化しなかった場合のJavaの行く末
MSが買収→特許申請→IBMに「再びライセンスを買え」と迫る→Blackdownは著作権侵害、ひいては特許侵害で訴えられる→Javaを.Netに組み込み→Javaの名はこの世から消え、MSエッセンスたっぷりの珍奇言語の一部へと昇華
・オプソ化した場合
標準化→規格化→一般化
クラスライブラリ一般化
各アプリに取り込み
jre jdk共に最適化可能になり高速化
0062名無しさん@お腹いっぱい。
05/03/19 06:06:59…→Blackdownは著作権侵害、ひいては特許侵害で訴えられる→Javaを利用する各アプリにロイヤリティ→Javaを.Netに組み込み→…
0063名無しさん@お腹いっぱい。
05/03/19 06:11:24MSが必死になってJava周りの技術やコード類を取ろうとするだろうね
IBMあたりと喧嘩になるんじゃないかなと思う。
IBM陣営→オプソ化希望
MS陣営→プロプラ希望 特許化希望 ロイヤリティ徴収したい
0064名無しさん@お腹いっぱい。
05/03/19 08:38:070065名無しさん@お腹いっぱい。
05/03/19 09:37:270066名無しさん@お腹いっぱい。
05/03/19 09:49:490067名無しさん@お腹いっぱい。
05/03/19 10:08:330068名無しさん@お腹いっぱい。
05/03/19 10:39:09MSはC#があるので今更Javaを買わないと思うよ。
Windows以外のPlatformで動くJavaはMSにとっては、大変都合が悪いからね。
もし買ったとしても、時間をかけて潰していくだろうね。
まぁ、味噌も糞も一緒にした様なEclipse作ったところには
とやかく言われたくないわな。
■ このスレッドは過去ログ倉庫に格納されています