5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Sun Microsystems 最後の理不尽

1 :名無しさん@お腹いっぱい。: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/

他にもあれば補足よろしく。

2 :名無しさん@お腹いっぱい。:05/03/16 08:23:42
2ゲット

3 :名無しさん@お腹いっぱい。:05/03/16 19:26:01
Sunゲット

4 :名無しさん@お腹いっぱい。:05/03/17 00:28:58
よん様

5 :名無しさん@お腹いっぱい。:05/03/17 01:15:11
もう駄目だぁ〜

6 :名無しさん@お腹いっぱい。:05/03/17 09:49:39
確かに理不尽だ(ナニ?

7 :名無しさん@お腹いっぱい。:05/03/17 19:01:00
http://pc5.2ch.net/test/read.cgi/unix/1103972661/997
> NFSv4 に期待!
> Solaris10 頑張れ!
> unix 厨ならnasだろーがっ!

ワラタ


8 :名無しさん@お腹いっぱい。:05/03/17 20:23:55
古い慣習にこだわってDASに執着する香具師ばかりだから
Sunのストレージはダメなんでつ。
OracleがNetAppを採用した時点で当面のスタンダードは決まりでつ。

9 :名無しさん@お腹いっぱい。:05/03/17 20:39:17
Oracle は昔っから raw デバイス推奨、つまり DAS ないし
FC-SAN 推奨であって NAS は推奨してないと思うが。
Linux が Linus の昔からのこだわりを捨てて raw デバイス
を実装したのも、Oracle 方面からの要望があったからなん
でしょ?

ファイナルファンタジーの件も、少なくとも Oracle 側の
提案ではないんじゃないの? Oracle としては、あからさまに
お客様の構成の悪口を言うわけにもいかないから、おべっか
を使ってたみたいだけど、裏ではむしろ呆れてるんでは?

10 :名無しさん@お腹いっぱい。:05/03/17 20:57:30
962 :名無しさん@お腹いっぱい。:05/03/16 16:31:52
NetAppの工作員が紛れこんでるような希ガス


11 :名無しさん@お腹いっぱい。:05/03/17 21:10:03
ググらずに
希ガス全部言える?

12 :名無しさん@お腹いっぱい。:05/03/17 21:12:23
変な姉ちゃん、ある日、狂ってセックス乱交
He Ne Ar Kr Xe Rn

13 :名無しさん@お腹いっぱい。:05/03/17 21:13:00
>>11
He, Ne, Ar, Kr, Xe, Rn のことか?


14 :名無しさん@お腹いっぱい。:05/03/17 21:17:15
>>12
一生忘れませぬ

15 :名無しさん@お腹いっぱい。:05/03/17 21:19:51
>>12 イイ!!

16 :名無しさん@お腹いっぱい。:05/03/17 21:36:16
このスレはためになるなあ

17 :名無しさん@お腹いっぱい。:05/03/17 21:38:45
>>9
オメ何にも知らねぇんだな。

ttp://www-jp.netapp.com/news/press/2004/news_rel_20040127.html

18 :名無しさん@お腹いっぱい。:05/03/17 21:56:48
>>17
これってOracle社の開発環境にNetApp使ったってだけだよね。

19 :名無しさん@お腹いっぱい。:05/03/17 22:01:55
>>12
ふっくらブラジャー愛の後、もよろしこ

20 :名無しさん@お腹いっぱい。:05/03/17 22:23:41
>>18
認めたくない香具師だな。
ちったぁぐぐってみ。少し古いけど。

ttp://www-jp.netapp.com/tech_library/3023.html?fmt=print

21 :名無しさん@お腹いっぱい。:05/03/17 22:40:27
この内容、技術的に変じゃねえ?

> 4.2 パフォーマンス
>
> まず第一に、NetApp ファイラーを使用することで、データベース・サーバが
> ローカルのファイル・システムや RAID ストレージを管理するために、貴重な
> CPU サイクルやメモリを使用する必要がなくなりました。このため、貴重なリ
> ソースを他のデータベース・サーバ機能のために使うことが可能になりました。

raw デバイスを使う場合、そもそも「ローカルのファイル・システム」なんて
ものは存在しない。DAS でも FC-SAN でも、ハードウェア側が RAID 機能を
サポートしていれば、サーバOS側では「RAID ストレージを管理」する必要も
ない。つまり、ここで「CPU サイクルやメモリを使用する必要がなくな」った
というのは間違い。
NAS を使うと、むしろ、NFS クライアントコードのために、「貴重なCPUサイ
クルやメモリ」を無駄に割かざるを得ない。

22 :名無しさん@お腹いっぱい。:05/03/17 22:45:24
> 第二に、NetApp ファイラーは、データベースを含む多くのアプリケーショ
> ン環境でローカル・ディスクよりもデータに早いアクセスを提供します。例
> えば、NFS パフォーマンスの SPEC SFS ベンチマークで明らかになった結果
> のように、NetApp ファイラーは、平均10ms (あるロード・レベルでは 2ms
> 以下) という素晴らしいレスポンス・タイムを示しました。NFS に代わるロー
> カル・ディスクでの平均検索時間も10ms 以下です。

ここ、良く読んでみよう。

NetApp を使った場合:
平均10ms (あるロード・レベルでは 2ms 以下)

ローカル・ディスク:
平均10ms 以下

なんだ、実はローカルディスクの方が速いじゃん。

NetApp が 2ms 以下で済むのは、大容量のキャッシュを積んでいるおかげで、
ディスクアクセスなしでデータを返すことができることがあるから。
でも、今やハイエンドの DAS や FC-SAN は、RAID 側に大容量のキャッシュ
を積んで同じようにディスクアクセスを避けることができる。
つまり、同じだけRAMを積めば、DAS や FC-SANの方が結局速い。


23 :名無しさん@お腹いっぱい。:05/03/17 23:58:16
NAS にアクセスするプロトコルとして、NFS や SMB を使うと
この通りなんだけど、DAFS を使えば、この問題はほとんど
回避できる筈。DAFS は NFSv4 をベースにしているんだけど、
肝心のデータ転送には VI の Remote DMA 機能を使うので、
プロトコル処理のオーバヘッドをバイパスできるから。

あとは、ネットワークのバンド幅が足りるかが問題かな。
バンド幅重視の場合は、DASがやはり一番有利。ただデータ
ベースの場合、バンド幅よりもトランザクション数の方が
重要なケースの方が多いんだけど。


24 :23:05/03/18 00:00:00
あ、この通りってのは

> NAS を使うと、むしろ、NFS クライアントコードのために、
> 「貴重なCPUサイクルやメモリ」を無駄に割かざるを得ない。

のことね。

25 :名無しさん@お腹いっぱい。:05/03/18 00:08:50
でも、VI って、VI をサポートする NIC が必要だよね?
Dellって、そういう NIC をサポートしてたっけ?


26 :名無しさん@お腹いっぱい。:05/03/18 00:24:16
>>22
snapshotとかbackupとか、ローカルでやるとウザイ事はウザイよ。

まあ今時パフォーマンスうんぬんって領域でテープにバックアップすることもないだろうが。

27 :名無しさん@お腹いっぱい。:05/03/18 00:42:35
DAFS と 単なる NFS でどれくらい違うかはここら辺参照。
ttp://www.atmarkit.co.jp/fnetwork/tanpatsu/07dafs/dafs01.html

バンド幅もCPU利用率も10倍違いますな。

これ、Linux 2.4.9 なんだけど、DAFS って、Linux に統合されて
ないよねえ? 富士通内部開発の奴なのかな? NICも富士通製?


28 :名無しさん@お腹いっぱい。:05/03/18 00:48:56
>>27
そのURLの内容は読んでないけど(w
uDAFSってNetAppの製品でしょ?

http://www.netapp.com/news/press/2003/news_rel_20030203.html

つーか、ここはおじいさんの集まりか? SANかよ!?

29 :名無しさん@お腹いっぱい。:05/03/18 00:53:01
で、Dell で DAFS って使えるの?

30 :名無しさん@お腹いっぱい。:05/03/18 01:04:35
ストレージスレの方でもDAFS使った人がいるか質問が
出てたけど、答がなかったねえ。
http://pc5.2ch.net/test/read.cgi/unix/1013887884/366
実は2chなんかに書き込んでる連中は、誰も使ってない?

31 :名無しさん@お腹いっぱい。:05/03/18 01:14:44
>>28
わざわざ英語読まなくても日本語のニュースリリースも出てるよ。
ttp://www-jp.netapp.com/news/press/2003/news_rel_20030203.html
ユーザレベル実装(uDAFS)はNetApp製だけど、
Linuxのカーネル実装(fDAFS)は富士通製ってあるね。


32 :名無しさん@お腹いっぱい。:05/03/18 05:10:48
>>22
オメほんとに何も知らないんだな。
NetAppの速さはNVRAMだけじゃなくWAFL(Write Anywhere File Layout)といって
ディスク書き込み時に連続したBlockに書く機能によるところもあるので、
キャッシュにヒットしない場合も十分速い。
常にキャッシュヒットする事はまずないから、実用的にはNetAppの方が速いよ。

33 :22:05/03/18 06:14:29
ん? WAFL って、もともと NFS サーバー専用に開発された
ファイルシステムでしょ?
UNIX の通常のファイルオペレーションには確かに向いてる
と思うけど、データベースみたいに、ディスク書き込みが、
既存ブロックに対するランダムな書き換え主体の場合は、
たいしてアドバンテージが期待できないんじゃない?

B+tree って、リーフノードをシーケンシャルに割り当てる
ことによって、逐次スキャン時のアクセス性能を稼ぐもの
だけど、リーフノードの書換え時にブロックを移動させて
しまったら、書き換えてない部分と書き換えた部分で
シークが必要になって、かえって遅くなる筈。
逆にこういう場合にブロックを移動させないなら、既存の
ファイルシステムと同じだから、WAFL の利点がなくなる
わけだし。

34 :名無しさん@お腹いっぱい。:05/03/18 07:36:45
>>33
「B+tree」ってB-tree+のこと?ちがうの?

35 :名無しさん@お腹いっぱい。:05/03/18 07:50:05
B+ tree とは書くけど、B tree+ とは書かないと思うよ。
参考:
ttp://www.atmarkit.co.jp/flinux/rensai/fs02/fs02a.html

36 :名無しさん@お腹いっぱい。:05/03/18 12:20:00
このスレのNetAppの宣伝を見てると、かつて勢いのあった頃のNovellの姿が重なって見える。

37 :名無しさん@お腹いっぱい。:05/03/18 12:46:15
少なくともSunとは何の関係もないな
宣伝はよそでやれ

38 :名無しさん@お腹いっぱい。:05/03/18 13:21:50
ライバルの話で盛り上がるのは、Sun自身に話題もアドバンテージもないのが悪い。

39 :名無しさん@お腹いっぱい。:05/03/18 18:39:17
だからRACだろ。
いまさら、rawなんて・・・

40 :名無しさん@お腹いっぱい。:05/03/18 18:44:17
>>39
相変わらずだなあ。
CPU使用率も比較して評価してみたの?
トランザクション数だけしか比べてないんじゃない?

41 :名無しさん@お腹いっぱい。:05/03/18 18:54:41
ここはOracleスレか?

42 :名無しさん@お腹いっぱい。:05/03/18 19:18:15
そうですよw

43 :名無しさん@お腹いっぱい。:05/03/18 19:20:04
Oracle 最後の生命線

44 :名無しさん@お腹いっぱい。:05/03/18 20:41:02
Oracleの生命線はLinuxだし

45 :名無しさん@お腹いっぱい。:05/03/18 20:54:15
>>44
SunもOracleも相互にブランド力を頼って、どさくさに紛れて売り込む案件
を狙っている希ガス。

46 :名無しさん@お腹いっぱい。:05/03/18 21:07:28
>>45
Oracleは前年比10%超の回復基調だぞ。斜陽のSunといっしょにされちゃ困る。
IBMに取られてたLinux向けのdbのシェアを取り返したから。
社内の開発環境もSolaris→Linuxに切り換えたし。

47 :名無しさん@お腹いっぱい。:05/03/18 21:08:33
>>33はSunのシンボル。

>>37
すみませんね。
でも現状ではSunとNetAppの組合せが最高だと思いまつ。
ある意味ネットアポーは他人のふんどしで相撲をとってる感じですかね。
ファイラーだけじゃ何もできませんからね。

48 :名無しさん@お腹いっぱい。:05/03/18 21:10:44
Oracleは業績回復してるよな
Linuxにも急接近してるし
といっても、最近の企業はどこもLinuxに急接近してるからあれなんだけど

49 :名無しさん@お腹いっぱい。:05/03/18 21:16:12
IBMがSunに、Javaの開発をコミュニティベースにしろとの無言の圧力
コミュニティベースで開発が続いているPHPに最近IBMはかなり資金投入した
IBMはそのPHPを持ち出して、Java批判を繰り返す

IBMめ、調子乗るな!!!!!!!!

50 :名無しさん@お腹いっぱい。:05/03/18 21:19:51
>>47
んなこと言ったら、スイッチ売ってる会社はどうなんだよ?

51 :名無しさん@お腹いっぱい。:05/03/18 21:21:14
SunにはJavaしかないんです。
もうブランド力もSolarisもSPARCも何の力にもなりません。
せめてJavaだけでも見逃してください>IBM様

52 :名無しさん@お腹いっぱい。:05/03/18 21:22:48
>>49
PHPで、批判されても苦笑するしかないな。
PHP悪かぁないが、規模と応用範囲が全然違う。

53 :名無しさん@お腹いっぱい。:05/03/18 21:32:33
>>50
FC-SANはNFSとは関係ねーよ。

>>51
JBossの開発者も言ってるけど、Javaはコミュニティベースにする必要は
ないと思うよ。
Sunは現状うまくコントロールしてる。
OSと違って言語仕様は開発元の限られたメーカがコントロールした方がイイだろ。

54 :名無しさん@お腹いっぱい。:05/03/18 21:55:15
>OSと違って言語仕様は開発元の限られたメーカがコントロールした方がイイだろ。

コントロールできてれば開発元じゃなくてもいい...


ような気もします。

55 :名無しさん@お腹いっぱい。:05/03/18 22:04:08
あげてるわりには、言い切らないんだね

56 :名無しさん@お腹いっぱい。:05/03/18 22:07:37
Javaはある意味Sunのセンスだと思います。
元々は組み込み(だっけか?)向けに開発された言語だけど
うまくnetに対応させてるので、Javaの設計センスの無い香具師に
変に拡張されていくよりはイイと思います。
コミュニティベースだと、どうしても最大公約数的になるので
Java本来の言語仕様が失われてゆく気がします。

57 :名無しさん@お腹いっぱい。:05/03/19 01:01:38
ソースは読めるんだからオプソじゃなくてもいいと言ってみるテスツ

58 :名無しさん@お腹いっぱい。:05/03/19 01:11:42
優しい独裁者がいるといいんじゃなかったっけ?

59 :名無しさん@お腹いっぱい。:05/03/19 01:21:11
Javaがコミュニティベースであるべきかどうかはさして重要なことでは無い。
問題はSunが無くなってもJavaは生き残るだろうが、Javaが無くなるとSunは
生き残れないだろうことだ。

60 :名無しさん@お腹いっぱい。:05/03/19 02:00:29
>>56
> コミュニティベースだと、どうしても最大公約数的になるので

CommonLisp (泣


61 :名無しさん@お腹いっぱい。:05/03/19 06:04:18
>>59
・SunがJavaをオプソ化しなかった場合のJavaの行く末
MSが買収→特許申請→IBMに「再びライセンスを買え」と迫る→Blackdownは著作権侵害、ひいては特許侵害で訴えられる→Javaを.Netに組み込み→Javaの名はこの世から消え、MSエッセンスたっぷりの珍奇言語の一部へと昇華


・オプソ化した場合
標準化→規格化→一般化
クラスライブラリ一般化
各アプリに取り込み
jre jdk共に最適化可能になり高速化

62 :名無しさん@お腹いっぱい。:05/03/19 06:06:59
>>61補足

…→Blackdownは著作権侵害、ひいては特許侵害で訴えられる→Javaを利用する各アプリにロイヤリティ→Javaを.Netに組み込み→…


63 :名無しさん@お腹いっぱい。:05/03/19 06:11:24
まあ、Sunが潰れたら
MSが必死になってJava周りの技術やコード類を取ろうとするだろうね
IBMあたりと喧嘩になるんじゃないかなと思う。

IBM陣営→オプソ化希望
MS陣営→プロプラ希望 特許化希望 ロイヤリティ徴収したい

64 :名無しさん@お腹いっぱい。:05/03/19 08:38:07
もうだめだぁーー

65 :名無しさん@お腹いっぱい。:05/03/19 09:37:27
だめじゃない!

66 :名無しさん@お腹いっぱい。:05/03/19 09:49:49
おまえらSunはどうでもよくてJavaが心配なんだな

67 :名無しさん@お腹いっぱい。:05/03/19 10:08:33
そのとおり

68 :名無しさん@お腹いっぱい。:05/03/19 10:39:09
>>61

MSはC#があるので今更Javaを買わないと思うよ。
Windows以外のPlatformで動くJavaはMSにとっては、大変都合が悪いからね。
もし買ったとしても、時間をかけて潰していくだろうね。

まぁ、味噌も糞も一緒にした様なEclipse作ったところには
とやかく言われたくないわな。

69 :名無しさん@お腹いっぱい。:05/03/19 10:45:22
ごちゃごちゃとしたやり取りが行われている中、
ついにCOmmonLIspの時代が来るんですね!今から勉強しておかないと。

70 :名無しさん@お腹いっぱい。:05/03/19 14:28:10
http://www.itmedia.co.jp/enterprise/articles/0503/19/news010.html
SCOのNASDAQ上場廃止めぐり公聴会
NASDAQ上場廃止の可能性を通告されているSCOはNASDAQ当局との会合を持った。
最終決定への影響は不明。
UNIXソフト開発企業米SCO Groupの担当者が3月17日、
上場企業としての行く末をめぐりNASDAQ当局と会合を持った。
SCOはForm 10-Kの年次報告書を米証券取引委員会(SEC)に提出しなかったことから2月、
NASDAQ上場廃止の可能性を通告されている。
同社は1月31日と2月15日の提出期限を守らなかった。
NASDAQ上場審査委員会では、報告書の提出が遅れた理由についてSCO担当者から事情を聴いた。
http://www.itmedia.co.jp/enterprise/articles/0503/19/news007.html
OracleもRetekの公開買い付け価格引き上げ
OracleはRetekの買収提示額を、SAPより0.25ドル高い価格に引き上げた。
米Oracleは3月17日、Retek株式の公開買い付け価格を1株当たり11.25ドルに引き上げると発表した。
Retek買収をめぐって対立しているSAPが同日、提示額を1株11ドルに引き上げたことを受けた措置。

71 :名無しさん@お腹いっぱい。:05/03/19 14:41:26
>>68
Javaそのものじゃなくて、
JVMで使われている特許技術を買うんでしょ?

72 :名無しさん@お腹いっぱい。:05/03/19 15:18:30
既にMSはそれに見合うだけの金をSunに払って訴訟を取り下げさせ、技術提携済。
落ち目のSunとしてはそうするしかなかったんだよな。

73 :名無しさん@お腹いっぱい。:05/03/19 15:31:07
ところで理不尽が最後なのは良いことではないだろうか。

74 :名無しさん@お腹いっぱい。:05/03/19 15:35:09
死人に口無しだからな

75 :名無しさん@お腹いっぱい。:05/03/19 15:45:57
Sunほどの企業がこんな短期間に窮地に追い込まれるんだもんな。
ユダヤ・アングロサクソンのビジネスってしんどすぎる。

76 :名無しさん@お腹いっぱい。:05/03/19 18:12:44
ナイヤガラ量産の暁には!!

77 :名無しさん@お腹いっぱい。:05/03/19 18:13:32
>>69
つうか、効率よく収益上げたいなら、CommonLispでやるしかねぇだろ?
ベンダの都合で予算膨らませるわけにはいかねぇんだし。

78 :名無しさん@お腹いっぱい。:05/03/19 20:12:15
来週号の日経ビジネス読んでね。
ここまでSunが国内ビジネス誌で叩かれるのもめずらしい。

79 :名無しさん@お腹いっぱい。:05/03/19 20:23:28
春は負けぼの

80 :名無しさん@お腹いっぱい。:05/03/19 20:31:07
>>68
Eclipseには積年の恨みがあるからねぇ…
豆が売れなかった事で信者共々恨みまくり っと

81 :名無しさん@お腹いっぱい。:05/03/19 23:18:47
Sunを叩けばイマいと思ってるんでしょ 屑が

82 :名無しさん@お腹いっぱい。:05/03/20 01:37:27
sunがつぶれたら世界が破滅するよ。われらが太陽だからね。

83 :名無しさん@お腹いっぱい。:05/03/20 03:08:56
>>78
なんて書いてあったの??

84 :名無しさん@お腹いっぱい。:05/03/20 03:35:27
>>77
どうして CommonLisp じゃなきゃだめなの?
まあ Java とか C# よりは効率いいだろうけど。

85 :名無しさん@お腹いっぱい。:05/03/20 05:56:51
時代はDだろ?w

86 :名無しさん@お腹いっぱい。:05/03/20 09:02:24
>>83
本屋に並ぶから、立ち読み汁。

87 :名無しさん@お腹いっぱい。:05/03/20 09:55:21
>>86 なんでここに書かないの?

88 :名無しさん@お腹いっぱい。:05/03/20 11:32:36
>>87 なんでここに書くの? 誰でも読めるのに。

89 :名無しさん@お腹いっぱい。:05/03/20 11:55:37
>>88 なんでここに書かないの? すぐ書けるのに。
海外からでも書き込みしてる人も多数いるんだから「誰でも読める」
普通なんて仮定しないでしょ。

90 :名無しさん@お腹いっぱい。:05/03/20 13:00:22
>>87
>>89
阿保っぽいからやめろ

91 :名無しさん@お腹いっぱい。:05/03/20 13:01:18
スレタイにあわせたかのように理不尽なレスがくりかえされてるよw

92 :名無しさん@お腹いっぱい。:05/03/20 13:44:06
日経ビジネスは俺が買い占めたぁー

93 :名無しさん@お腹いっぱい。:05/03/20 14:32:19
Solaris10オープンセミナーちょこっと見てみたんだが、
Solarisも結構LinuxやIBMを参考にしてるな。
SMFやZFSのコマンドをCUIで打たなきゃならんところがSunのポリシーであり、
現状から脱皮できないところでもあるのだが。
しょうがないから犬厨房には、少しだけソースを参考にするの許してやるよ。

94 :名無しさん@お腹いっぱい。:05/03/20 15:21:29
日経ビジネス2005年3月21日号
タイトル:サン・マイクロシステムズ「ITの雄、最後の戦い」
カラー6ページ企画
企画タイトル:ケーススタディ:誤算の研究
リード:
シリコンバレーのコンピューターの名門が長引く業績低迷に苦悩している。
レッドハットのリナックスOSを推進するIBMや、デルに市場を奪われた。
仇敵のマイクロソフトと提携し、生き残りを目指すが、復活の道は険しい。

95 :名無しさん@お腹いっぱい。:05/03/20 15:38:19
サン得意の抜き刷りつくってユーザーに配布してほすいw

96 :名無しさん@お腹いっぱい。:05/03/20 16:04:24
>>95
今回は抜き刷りじゃなくて記事のカラーコピーを、IBMやHPあたりが
SunからRHLのリプレイス検討課題として顧客にバラ撒くかもな。

国内のビジネス誌でここまで書かれたら辛い<CTC某氏談

97 :名無しさん@お腹いっぱい。:05/03/20 16:37:20
日経BP社員乙

98 :名無しさん@お腹いっぱい。:05/03/20 16:38:10
だいたいさあ。
Sunのベンダー試験も高すぎる値下げ汁。

99 :名無しさん@お腹いっぱい。:05/03/20 16:51:58
SJC-Pで\24,000か
MCSDと大して変わらんような気がしないでもない

100 :名無しさん@お腹いっぱい。:05/03/20 17:33:28
>>84
効率。それが答えです。数年後とにバグしか作れないおばかサンたちに、
新しい(ようにみえる)テクニカルタームのこまごまとしたことを客の金で
憶えさせるなんてばかばかしくてやってられないのです。

101 :名無しさん@お腹いっぱい。:05/03/20 18:06:06
一人か二人で開発するなら Common Lisp もいいと思うが、
十人で開発するなら Java の方がいいよ。引数型チェック
ぐらいはないと、やってられんというより問題外。


102 :名無しさん@お腹いっぱい。:05/03/20 18:07:07
10人しかいなくて、そんな問題で一々つまづくなんてちょっとお笑いですね

103 :名無しさん@お腹いっぱい。:05/03/20 18:16:06
>>97
BP社員じゃなくても定期購読者には前週の金曜の夜に届くよ<日経ビジネス

104 :名無しさん@お腹いっぱい。:05/03/20 18:16:16
引数エラーみたいなケアレスミスをテストで(==すなわち人手で)
とるなんて、大人数プロジェクトではありえないんだけど。
汚れ仕事は機械にやらせろっていうのは、今も昔も優れたプログ
ラマーの大原則。そんな無駄な仕事に人手を使うのは馬鹿だけ。


105 :名無しさん@お腹いっぱい。:05/03/20 18:33:29
えー。引数エラーみたいなテストなら自動化できるじゃん。

106 :名無しさん@お腹いっぱい。:05/03/20 18:34:42
要するに>>104の身の回りの人はケアレスミスが多すぎって事ですね
書く人間の能力が低いか注意力が欠如している証拠かな。。
チェックを自動でやっても修正は人手だから、さぞ仕事キツいでしょうね

107 :名無しさん@お腹いっぱい。:05/03/20 18:43:21
> えー。引数エラーみたいなテストなら自動化できるじゃん。

Java ならわざわざ自分で自動化するまでもなく、最初から
自動化されてるよ。Common Lisp って、Java の組み込み機能を
各自、自分で作らないといけない不便な言語なんですね…

108 :名無しさん@お腹いっぱい。:05/03/20 18:43:54
あるパートナーから聞いたSunの営業の一日 
 昼頃出社
 障害対応(それはパートナーまたーです。が決り文句)
 エビデンス?作成
 同僚と呑
 帰宅

 この繰り返し。
 



109 :名無しさん@お腹いっぱい。:05/03/20 20:03:14
サンって直販してないのに、なんで営業が居るの?

110 :名無しさん@お腹いっぱい。:05/03/20 20:31:32
>>109
自分の言ってる言葉の意味わかってるか?

111 :名無しさん@お腹いっぱい。:05/03/20 21:28:01
>>107
CommonLispにはちゃんとオブジェクト指向の環境もあるの。
そういうので、バリヤ張るべき所にははっておけるの。
そして、生産性の高さ、実行しっぱなしでも機能変更できちゃう運用面での柔軟性とか
もろもろ考え合わせると、CommnLisp がよいものになってきちゃうのよ。

ましてや、XMLベースのデータ流通をガシガシやるんならS式は最強!だったりするしね。

112 :名無しさん@お腹いっぱい。:05/03/20 21:34:54
浅知恵のJavaマンセー厨が無知を晒した

コマンド?

→ 放置
  煽る
  にげる

113 :名無しさん@お腹いっぱい。:05/03/20 21:38:34
Lisp = Emacs lispと勘違いしてる痛い厨がいるスレはこちらですか?

114 :名無しさん@お腹いっぱい。:05/03/20 21:44:55
> 今回は抜き刷りじゃなくて記事のカラーコピーを、IBMやHPあたりが
> SunからRHLのリプレイス検討課題として顧客にバラ撒くかもな。

やるとしたらちゃんと許可とってやれよな。

115 :名無しさん@お腹いっぱい。:05/03/20 21:47:28
>>93
> Solarisも結構LinuxやIBMを参考にしてるな。
> SMFやZFSのコマンドをCUIで打たなきゃならんところがSunのポリシーであり、

いつからおまえがSunのポリシーを決めるようになったんだよ( ^∀^)
で、「CUI」って何よ? (お約束)

116 :名無しさん@お腹いっぱい。:05/03/20 21:49:21
CUIってジャップが勝手に作った和製英語だって知らない香具師多いよね

117 :名無しさん@お腹いっぱい。:05/03/20 22:14:35
>>116
ttp://www.computerhope.com/jargon/c/cui.htm

118 :名無しさん@お腹いっぱい。:05/03/20 22:16:02
章の頭にもろに書いてあるからこっちのほうがいいね。
http://docs.sun.com/app/docs/doc/816-7171/6md6pohsh?a=view

119 :名無しさん@お腹いっぱい。:05/03/20 22:16:43
やはり知らないか

120 :117=118:05/03/20 22:24:13
うむ、知らん。
だがCUIと聞いて連想するのは、OSF/Motifだ。
でも、あれがCUAになったのはCharacterのほうのCUIと紛らわしいからでは
なかったか?(やはりよく知らんけど)

121 :名無しさん@お腹いっぱい。:05/03/20 22:36:16
>>115
そんな事より一行上をつっこんで欲しかったでつ。

122 :名無しさん@お腹いっぱい。:05/03/20 22:37:07
>>117
このサイト、"Command Line"の説明からしておかしいな。
"CUI"の定義はどの文章に述べられてるのかね?

>>118
このページでは、CLIが行指向型のコマンド型UI、
CUIが画面指向のメニュー型UIと使い分けられているわけだが?

123 :117=118:05/03/20 22:40:25
>>122
えーと、そうでしょ?
CUIって、cursesベースのフルスクリーン画面(あるいはPCのBIOS設定画面)
みたいなのを言うんじゃないの?

>>117のサイトはぐぐって英語のものの一番上を取ってきただけだから
よく分からん。単に日本語でしか通用しないという指摘に対する反例としては
充分だと思った。

124 :名無しさん@お腹いっぱい。:05/03/20 22:54:22
> えーと、そうでしょ?

わかってるんならいいんだ。
漏れもオープンセミナー見たんだが、"CLI"、つまりコマンドでの操作しかしてない。

> みたいなのを言うんじゃないの?

知らん。"CUI"とか"OS"みたいに定義が曖昧な言葉は
ちゃんとした文書ではあんまり使われないから。
(使うとすれば、Terminologyの章でちゃんと定義するし)

125 :名無しさん@お腹いっぱい。:05/03/20 22:56:38
で、ジャップが作ったんだ?

126 :名無しさん@お腹いっぱい。:05/03/20 22:59:05
言っとくが、124=122=115と116は別人だ

127 :名無しさん@お腹いっぱい。:05/03/20 23:00:18
つーかふつーに考えて
CUIったらGUIに対する対義語
みたいに考えていーんじゃないの??

128 :名無しさん@お腹いっぱい。:05/03/20 23:01:10
おまいさんのふつーと、世間一般のふつーは違うのだよ

129 :名無しさん@お腹いっぱい。:05/03/20 23:11:07
こんなどうでもいい話が続いてる間にも
Sunの体力はみるみる衰えていく・・・

130 :名無しさん@お腹いっぱい。:05/03/20 23:11:42
http://www.google.co.jp/search?q=GUI+CUI+CLI
やはり単なる和製英語ってのは承服しがたいな。
>>123の認識でいいように思うけど。


131 :名無しさん@お腹いっぱい。:05/03/20 23:30:58
てゆうか、セミナーでやってたからって、CLIしか存在しない
と思っちゃうIBM厨(Linux厨?)ってどうよ。
というか、セミナーに期待するのがGUIでの使い方って...

132 :名無しさん@お腹いっぱい。:05/03/20 23:32:32
>IBM厨(Linux厨?)ってどうよ。
という事にしたいのですね?:)

133 :名無しさん@お腹いっぱい。:05/03/20 23:42:50
>>130
>>116は"ジャップ"とか書いてるアフォだから気にしない。

>>131
>>93は釣りだろ?
っていうか、こんなスレにまで来てわざわざ下らないこと書いていくんだから、
Sunと利害関係があるか、でなければよほどの物好きだろう。
物好きのほうの漏れとしては、「他社の営業さんも大変でつね」が正直な感想。

134 :名無しさん@お腹いっぱい。:05/03/20 23:48:32
フルアクセスの手段としてCLIは有って然るべきだが、このご時世GUIも提供すべきだと思うヨ。

Sunも遅れ馳せながらZFSを出してきたけど、StorageはNASやSANメーカのを使うところが多いから
骨折り存な気がする。
FSはネットアポーとかと組んでやればいいのに。
ZFSは、OracleやMSが提唱してるSQLベースのFSは一応否定していると取っていいのかね。

135 :名無しさん@お腹いっぱい。:05/03/20 23:59:41
Sun が作ると GUI ださくって使えないから
結局、CLI が便利ってことになる?w

136 :名無しさん@お腹いっぱい。:05/03/21 00:00:08
>>133
>>134とかもそうかな? なんか真面目にそう思ってる
ような気がするんだが。だとすると才能。


137 :名無しさん@お腹いっぱい。:05/03/21 00:32:58
>>134
> フルアクセスの手段としてCLIは有って然るべきだが、このご時世GUIも提供すべきだと思うヨ。

しないとは言ってないじゃん。
後のリリースでSMCあたりに組み込むってのは十分考えられる。

>>136
一応建設的な提案もしているから、まあ"物好き"の部類ですかね。
まあ仮にそうだとしても、こんなところでくだ巻いてたからといって
何も変わらないとは思うけど。

138 :名無しさん@お腹いっぱい。:05/03/21 00:40:48
今年もそろそろリストラの季節。
今年はKK何人切るかな。USは何人切るかな。
UKとドイツは業績よかったみたいだから切らないかな。

139 :名無しさん@お腹いっぱい。:05/03/21 01:21:59
>>127
>CUIったらGUIに対する対義語

どこかのヘボPC雑誌の用語解説で「GUI」と共に、その反対語として
「CUI」が挙げられていたので、そう覚えていた時期もあったのだが、
気まぐれに本場の英語サイトでの「GUI vs CUI 」論を読んでみよう
と思った時に検索したらヒットする件数も内容もぱっとしなくて、少し
手探りしてみるとどうやら「CLI」という方が一般的らしいと知った。

その時に

GUI(Graphical User Interface)

に対して、

CLI(Command-Line Interface)

と言うべきである理由を推測して
「コマンドラインは、必ずしも"ユーザーインターファイス"ではない。」
と解釈したのだが、厳密な使い分けは知らない。

どうなんでしょうか。誰か詳しい人いますか?

140 :名無しさん@お腹いっぱい。:05/03/21 01:59:15
なんで他人の会社のことがそんなに気になるもんなのかね?

141 :名無しさん@お腹いっぱい。:05/03/21 02:01:50
気になるというより FUD の一貫なんじゃないの?
どこかのメーリングリストでは、UltraSPARC の
開発は中止されたと吹いていた IBM 社員がいたし。

142 :141:05/03/21 02:02:47
s/一貫/一環/

143 :名無しさん@お腹いっぱい。:05/03/21 02:12:29
シリコンオーディオに参入だ!!
ソニーの新しい奴にSunのロゴ憑くだけで
萌える  加茂
1万うpでも買う  加茂

144 :名無しさん@お腹いっぱい。:05/03/21 02:26:17
s/一環/一巻/

スシクイテー

145 :名無しさん@お腹いっぱい。:05/03/21 03:07:11
海苔巻きか? 握りか?

>>143
.auフォーマットしか対応してないとか?

# ネタは再生品です

146 :名無しさん@お腹いっぱい。:2005/03/21(月) 05:15:12
>>138
毎年KKの人減らしは年末行事だろ?
この時期は来期の人員配置でも考えてんじゃね?

147 :名無しさん@お腹いっぱい。:2005/03/21(月) 05:39:46
なんで他人の会社のことそんなに詳しいの?

148 :名無しさん@お腹いっぱい。:2005/03/21(月) 09:30:06
元社員とか

149 :名無しさん@お腹いっぱい。:2005/03/21(月) 13:11:03
>>139
Human Interfaceの研究している人たちは、かなり厳密に定義、分類しています。
昔で言うところの人間工学系の人たちね。

150 :名無しさん@お腹いっぱい。:2005/03/21(月) 18:04:39
人間工学って、女体の研究は


 いえ、なんでもありません。

151 :名無しさん@お腹いっぱい。:2005/03/21(月) 19:48:18
今のところスケーラビリティを考慮つつ正しく進化してるOSは、LinuxとSolarisくらいだろう。
SolarisをこのままSunと一緒に潰してしまうのは惜しい気がするのう。

152 :名無しさん@お腹いっぱい。:2005/03/21(月) 20:09:10
ホリえもぉおん

153 :名無しさん@お腹いっぱい。:2005/03/21(月) 22:40:42
> 正しく進化

いつからおまいさんが「正しさ」を定義できるようになったんだ?

154 :名無しさん@お腹いっぱい。:2005/03/21(月) 23:33:09
今度は窓房が必死ですか

155 :名無しさん@お腹いっぱい。:2005/03/22(火) 00:03:37
もういっそのコト、ホリエモンとリーマン・ブラザーズのコンビで
SunにLOBをかけてくれ。

36 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)