Sun Microsystem 最大の遊撃

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 17:43:05

今更「オープンソース」とか言い出したり、
　…でも「OpenSolaris-Closed-Bins」って一体…（´Д`;）

今更「Ultra20」とか言い出したり、
　…でも「"Ultra"SPARCではなくOpteron」って一体…（´Д`;）

Fujitsu製造のSPARC64V,
AMD製造のOpteron,
TI製造のNiagara(UltraSPARC T1)などと矢継ぎ早にCPUを模索しているが、
これは縦読みで、製品群が"FAT"になる暗示か？w

【前スレ】
Sun Microsystems 最後から二番目の真実
http://pc8.2ch.net/test/read.cgi/unix/1127872934/

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 13:01:58

大気圏外ではそうやって使うんだろ、きっと。

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 13:21:15

大気圏外運用の世界では
"メモリに 1bit error 起きますた!"
"ECC にて自動修復された模様でありますっ!"
みたいな連絡・報告が人間組織の中でビビビっと飛びまくります

エラー頻発なんて状況は… 恐ろしい

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 17:37:33

製造不良を検知して自動修復する機能を入れてはどうか?

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 18:17:59

そんでその機能が初期不良なんだな。

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 18:21:18

滅多に動作しないものにこそバグが潜んでるからね

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 18:33:40

その機能が頻繁に動作すれば品質は上がる。
よいよい。

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 20:29:10

「はやぶさ」はリスタートしたんと違う?

**名無しさん＠お腹いっぱい。** · 2006/01/05(木) 22:48:05

はやぶさってイトカワに衝突してあぼん？ｗ

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 07:26:25

>>426 じゃぁ、Sunのx900は使えないね。
エラー修復のメッセージ、月1位で出るぞ

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 09:51:55

月1位で 1bit error だったら
2bit以上のエラーが起きる可能性はそこそこありそう

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 13:36:59

ﾂﾏﾝﾈ

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 13:38:04

**名無しさん＠お腹いっぱい。** · 2006/01/06(金) 17:50:13

>>435
そりゃ不良品だろ。早く直せ。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 06:19:58

「ソフトエラーは、ほかの信頼性メカニズムのすべてを含めたものの中でも、最
も高い不良率を引き起こしている」
ttp://www.ednjapan.com/content/issue/2005/02/feature/feature02.html

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 08:29:45

>>439
え？

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 08:58:40

ソフトエラーはいいんだよ、普通の頻度で発生してりゃ（稀って意味で）。
ECCでエラー訂正するんだから。

でも、素子が壊れてたりしてハードエラーになったりすると、2bitエラーに
波及しないように交換する。

1bitエラーのメッセージは、月1,2回程度の発生してECC訂正する程度であれば
抑制されるはずだから、普通は気づかない。

でも、ECC訂正の頻度が上がると1bitエラーのメッセージが出力されるので、
それを見たら2bitエラーにならないように予防保守として交換すればいい。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 14:11:48

メッセージが表示されるということは、内部である期間内に一定回数以上のエラーを検出しているということ。
ソフトエラーだとメッセージ表示まではあまり達しないと思うので、メモリがハードウェア的に悪いのかもしれない。
毎回同じビットが化けているのか、そうでないかとかにもよるけど。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 17:55:03

おまいらメモリエラーの話大好きだな。
なんでもいいからとりあえず替えとけよ。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 21:39:51

止めんのめんどい。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 21:40:31

>>444 アホだなぁ。下手に交換するとさらに悪化する場合があるんだよ。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 21:43:51

エラー起こしている間はメーカーのせい。
交換して悪化した場合土方のせい。

**名無しさん＠お腹いっぱい。** · 2006/01/09(月) 22:29:27

放射線でソフトエラーが起きやすいのはDRAM
CPUのキャッシュに使われているのはSRAM

信頼性よりも製造コスト優先の糞メーカーのDRAMだと、ソフトエラー起きやすい。

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 00:18:00

放射線によるエラーは、DRAMの静電容量だかなんだかに依存するはずで、
製造コストは関係ないんじゃないの。
タイミング関係のマージンがぎりぎりぎりでも通しちゃうために放射線
じゃなくてタイミング問題で化けるとかなら、製造コストの問題だけど。

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 04:55:24

Windows VistaのAero Glassは超高負荷みたいだね
http://pc.watch.impress.co.jp/docs/2005/1220/kaigai230.htm

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 10:58:49

Microsoft は Intel 揺さぶってるんじゃないか? 最近そういう行動が目立つような。

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 16:14:19

>>450
やっぱ（あの重い）Looking Glassより、さらに重いんだろなぁ。
ところでLooking GlassってJAVAで書かなければもう少し軽くなるの？

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 17:55:33

>>449
静電容量を大きくするのにコストがかかる。

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 19:07:47

そんなところにはコストはかからんでしょ。

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 21:31:10

製造コストが減るし、
静電容量を確保するための技術開発も不要になる。

http://pcweb.mycom.co.jp/articles/2005/12/08/iedm2/

Infineonは30fF
Samsungは25fF

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 23:14:00

> そんなところにはコストはかからんでしょ。
半導体の話になると、頓珍漢な事を言い出す奴が多いな。
大気圏外ネタとか。

**名無しさん＠お腹いっぱい。** · 2006/01/10(火) 23:37:24

【エラー】メモリを語ろう【大気圏】
でも立ててそっちでやってくれ

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 00:27:38

セル容量はチップ面積(==コスト)に直結する。
放射線はパッケージの材料から出る。高純度の材料は高い。

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 01:04:38

>>456
意地でも ECC 必須の結論に誘導したいヤツが 1 名だろ?
それもトンチンカンな状況説明で。

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 04:56:23

>>459
「備えあれば憂いなし」ではあるけどな。

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 07:42:34

損部レ炉、損部レ炉～

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 12:48:33

>>460
過剰な備えは懐が憂うよ！

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 14:24:00

いつでもrebootｵｹな環境ならECCは過剰かもな。
信頼性という言葉が出る環境でRAMまわりにECCも無い
ようでは話にならん。

**名無しさん＠お腹いっぱい。** · 2006/01/11(水) 15:33:11

スレ違いだけどちょうど今月の Design Wave に宇宙衛星の品質保証の記事あるよ
http://www.cqpub.co.jp/dwm/Contents/dwm0099i.htm

**名無しさん＠お腹いっぱい。** · 2006/01/12(木) 02:15:50

ECCが不要だとは言わないよ。

ECCの目的は、
第一にメモリにエラーが発生していないことを確認できるようにすること
(EC機能がなければ、エラーが発生しているかどうか、チェックする術がありません。)
第二に万が一エラーが発生していた場合に、リカバリできるようにすること

頻繁に化けるメモリでもECC使えば安全に使えるというのは間違い。

**名無しさん＠お腹いっぱい。** · 2006/01/13(金) 15:57:37

なんかネタ出してん

**名無しさん＠お腹いっぱい。** · 2006/01/13(金) 16:46:43

FedoraがSunのJava推奨してないのは何故？

**名無しさん＠お腹いっぱい。** · 2006/01/13(金) 18:46:55

プロプライエタリだからでしょ。

**名無しさん＠お腹いっぱい。** · 2006/01/13(金) 19:20:28

それだけの理由？

**名無しさん＠お腹いっぱい。** · 2006/01/13(金) 20:44:29

Red HatがIBMと仲良しだからだろ

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 17:20:32

ビノッドコースラ写ってるw ビートルズ赤盤青盤かよ!w

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 17:59:06

サンの創業メンバーが再会--アップルとの秘話も明らかに

http://japan.cnet.com/news/biz/story/0,2000050156,20094390,00.htm

結構面白い。

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:14:20

IntelMacになればx86なOpenSolarisが動く

の？

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:22:15

マクはビッグエンディアンじゃないの？

大口顧客がいまだにSunのSparcマシンを手放さないのも
過去のバイナリデータがSparcマシンじゃないと（簡単に）読めないから
その過去のバイナリーデータをLinuxで活用する為に
専用のソフトをリトルエンディアンに書き直して
ちゃんと動く様にするのはあまりにもコストがかかりすぎる
それよりはSparcマシンを保守維持する方が安上がり

とかの事情もあるしね

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:33:17

エンディアンネスの修正なんて嵩が知れている。
それと、BE/LE は個別の CPU の仕様だから OS は関係無い。

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:41:00

> それと、BE/LE は個別の CPU の仕様だから OS は関係無い。

そうとも言い切れん。
VMS/OpenVMS は Little Endian だけだし、
HP-UX は Big Endian だけだし (Itaでも Big Endian)、
Windows は Little Endian だけ (おかげで POWER を
Little Endian モードで動かすとか、SPARC に Little Endian
モードを加えるといったことまで)。

もちろん bi-endian な OS も沢山あるけどね。

> エンディアンネスの修正なんて嵩が知れている。

ひとつひとつの修正は簡単だけど、ソフトウェア資産が多いと
嵩が知れていると断言できるほど少ない量でもないよ。

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:51:59

そりゃ単一アーキの OS はそうでしょう。Itanium が Bi Endian なのは知らなかった。
SunOS はエンディアン依存していないし、Darwin もエンディアン非依存だよ。

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 23:21:47

SunOSがエンディアンに依存してないってどういう意味？
確かSPARC V9の%pstateあたりにエンディアン指定ビットがあったと思うけど、
あれを切り替えて動かすことが出来るの？

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 23:26:18

SPARC/x86両対応ってことでしょ

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 23:41:15

誰が作ったんだかわからないプログラムが
大量にビッグエンディアンバイナリをはき出して
そのバイナリはやはり誰が作ったんだかわからなプログラムで解析されて
あのたがたの生活を支えているのかもしれない

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 23:44:14

>>474
ユーザーデータのエンディアンは CPU がなんだろうとアプリで意識せなあかんがな。
「マクは」って何指して言ってるのか知らんがあんたが心配しているようなコストは
ないと思うよ。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 00:25:29

>>474
あと、その言い方だと構造体のパディングもだろうな。そりゃ手抜き過ぎだよ。
コンパイラのオプション変えただけで変わったりする。そこまでベンダーの面倒見の範囲には
入らん。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 01:25:49

いや、そこまでベンダーが面倒みてるからこそ、現在の
Wintel の繁栄があるんだと思うけどね。

Mac は忠誠心の強いユーザが多いから、なんとかなるのかも。
普通、そんなに忠誠心とかないから、エンディアン変更する
だけで、他のベンダーの草狩り場になりかねんような。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 01:29:58

いつの時代の話やねん。MS-DOS?

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 01:37:01

そういう話（風説）自体が FUD なんだよな。マルチプラットフォームなアプリなんで
今ではそこらじゅうにあるだろ? そんな話持ち出すんなら文字コードとかパス記法とか
リソースフォークだの考えないといけないことは他にもいろいろあるよ。
で、それを解決した実例がそこらじゅうにソースコードでごろごろあるじゃん。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 01:50:09

そういうのはゴロゴロあるが、そうじゃないのもゴロゴロあるのでは？

最近は RDB+Javaアプリケーションサーバ+Webって開発ばかりだから、
そうじゃないのは、かなり減ってきてるとは思うけどね。

ちょっと前に作られた、C/C++ アプリってのがヤバげ。
gdbm や Berkeley DB を使ってるのも、データの中身がバイナリだと
ヤバい。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 02:09:00

NeXT step が x86 に対応したとき、
エンディアンを吸収するクラスが作られなかった？

名前は確か、NSStream。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 02:11:39

XDR とか。古い話だ。1980 年代の話題。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 02:35:52

おまいらｵｯｻﾝ

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 02:55:14

知らんのなら勉強しとけ。あと htonl とかな。ネットワークやったことあるやつなら
ジョーシキなんだが。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 03:12:14

>>472
「Apple にユーザーインタフェースの統合を持ちかけたとき」って、いつごろだろ。
OpenStep のことで、ひょっとして NeXT と勘違いしてる?

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 03:49:01

以下の２つが混乱。
・同じバイナリデータをlittle/big endianのCPU上で扱う
・コンパイルしなおせば別のendian上で動く。データのendianも代わる

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 06:50:37

>>472
昔のミニコンとワークステーションの関係は
今のRISCサーバーとPCサーバーの関係みたい
SUNもDECのようにつぶれるのか？

＞DECは、Sunが初期に狙いを定めていた一番の競合相手で、
＞Sunが成功を収めたおかげでDECがその犠牲になった。
＞「VAX 750は、80Mバイトのディスクドライブと2Mバイトのメモリを搭載し、
＞1秒間に100万回の計算が可能だった」とJoyは述べ、
＞さらに「Andyの設計したマシンは標準的な部品を使っていたので、
＞(Motorola) 68010プロセッサを搭載した時には、10分1の価格で
＞同じ処理性能を持つマシンを実現できた。
＞あれは本当に革命的だった」（Joy）

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 07:01:34

SunとAppleは合併すれば相乗効果が高いと思う。

得意分野も補完関係にあるし、ともにコンピュータ専業の老舗で
Microsoftから多額の和解金を勝ち取ったwという共通点もあって
企業統合は無理なく出来るだろう。

そして、今こそ家庭向けNC(NetworkComputer)構想の復活だ！

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 07:55:24

しかし、AppleはIntelと組んでいるので、
いまさらAMDと組んでいるSunと組んで、
ワークステーションを共通ハードにする
なんてこともできない。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 09:16:24

Intel と AMD なんてソフト屋からすればどちらでも同じなわけだが

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 09:40:01

>>491
OPENSTEPは、AppleやIBMも参加する計画があったよ。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 09:41:44

>>495
IntelMacではOpenFirmwareを辞めるという噂があったがどうなったんだろ?

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 09:53:25

>>498
辞めたよ

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 11:03:47

forceが動かなきゃ嫌だ

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 11:09:59

ってことはbios搭載のただのPC-AT互換機か？

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 11:19:52

forceはjediじゃないと使えないから民生品に載せるのは無理かつ無謀かつ無意味。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 11:23:57

>>501
EFI

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 12:04:06

>>496
ハードベンダのSunにとっては、重要なことですよ。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 12:37:44

force ? forth?

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 15:38:34

>>500, 502
綴り分からないならフォースって書いとけばよかったのに・・・・よくないか

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 15:39:35

ネタにマジレスは無粋なり。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 16:40:11

...

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 17:34:21

マジにネタレス

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 20:46:45

ｶｯｺ(・∀・)ｲｲ!!

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 22:13:27

>>493
なんでこんな短絡バカが多いのか。PC の方がデキ悪いしもう消えかけだろ。
BIOS が退場して EFI からビルトイン NIC と SAS が制御できるんならまるっきり
1980 年代のワークステーションなんだよ。死んだのは PC だ。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 22:30:10

>>494
船頭が多いと船が山に登るからな。Sun 側はともかくとして、ハゲは自分がタイショウじゃ
ないとやってけない性分だろ。自分でよくわかってると思うな。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 22:45:57

クソ BIOS の退場は確定した。実質引導渡すのが Apple になりそうなのが興味深いが。
ここで EFI の出鼻をくじければ IEEE 1275 OpenFirmware にもチャンスがある。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 22:51:46

SunでOBPというとハードウェアのチェックぐらいにしか使えない印象があるけど
BIOSでハードウェアのチェックっていうと最近流行りのBIOS built inのmemtest86ぐらいだもんな

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 22:57:52

>>511-513
もっと熱く語ってくれ

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 23:12:52

あの座談、Appleに逃げられた感が漂ってるのが笑えるんだが…

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 23:29:13

GUI については Apple とくっつくより XEROX からあぶれた連中をかき集めるべきだったな。
XEROX から Apple へ行った連中も引き抜けばよかった。けどハゲは要らんだろ。
ま、当時の Sun にはそんなカネないだろうけど。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 23:52:37

UIが提唱したOPENLOOKはXEROXと組んでなかった？
当時のMacのGUIより優れてたと思うけどな

それにSUNが開発したGUIのNeWSはX Windowの普及で出荷されず
機能を縮小してX Windowに対応したOpenWindowが出たと本で読んだ
X Windowが普及しなければUNIXのGUIはもっとマシになってたかもね

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:01:28

> それにSUNが開発したGUIのNeWSはX Windowの普及で出荷されず

確かNeWSを開発したのは、JavaのGoslingだったような？
で、結局Xとくっつけて、X11/NeWSとして出てきたような気がする。
Xも動き、NeWSも動きで、いいじゃん？ってなもので。
そんで、NeWSはDisplay Postscriptかを使用してたので、PostScriptを
そのまま画面に表示できた。

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:04:10

Network extensible Window Systemはちゃんと出たぞ。
OpenWindowの一部。Postscriptベースの拡張。

Suntoolを出す→X Window Systemに負ける。
OpenWindowを出す→CDEに負け、Sunの標準デスクトップがCDEに。
Xを拡張したNeWSを出す→Adobe Display PostscriptにPostscript部で負けて撤退。

TNT(The NeWS Toolkit)は撤退と同時にオープンソースにしたな。

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:05:25

座談読むと、アップルのスカリーだっけか、ジョブズを追い出した、
あの人って、全然ジョークつうじなそうね。

で、ベクトルシャイムってバリバリのエンジニアって思ってたけど、
サンを立ち上げる前に学生の身でありながら、年収５０００万も
自分の仕事で儲けてたなんて、逆にビジネスの才の方がある人なのね。

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:05:26

> Display Postscript
これってどういう機能なの？
Postscriptのインタプリタがどっかに内蔵されてるの”

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:09:13

>>522

JavaみたいにPostscriptのインタプリターエンジンが入っていて、
実行時に解釈してイメージに変換し、表示してた。

Postscriptを中間言語に使うことで、画面表示と印刷イメージとを
一致させていた。

ような覚えがある...（昔のことだけど..）

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:09:40

>>519
そう。ゴスリンがやってた。その後NeWSご破算になって、Oakやり始めた。

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:11:28

Goslingって、こういうの好きなんだろうね。
インタプリターを搭載したモノが。

Gosling Emacs (Lispエンジン)、NeWS (Postscriptエンジン)、
Java (JVM)って結局ルーツが一緒だもんね。

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 00:12:31

Display Postscriptを最初に搭載したシステムがNeXT