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/03(火) 19:44:34

>>382
>普通はブート前のOBP/POSTの診断ではねられる
10分以上かけてチェックするくせに、意外とはねてくれない。
そのため、手動でblacklistに追加するなんて言う保守を行っているケースも
少なくは無い。
PRIMEPOWERだと一度障害を起こした箇所はPOST通っても切り離したままに
しておいてくれると聞いたけど。
APLが出れば、全て解決かな。

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

> >普通はブート前のOBP/POSTの診断ではねられる
> 10分以上かけてチェックするくせに、意外とはねてくれない。
> そのため、手動でblacklistに追加するなんて言う保守を行っているケースも
> 少なくは無い。

OBP/POSTの診断は、Diskの不良セクターとは違うよ。
サーバのは特に念入りに行うはず。

普通のPCの場合は....ダメかな。。。（ま、用途が違うので当たり前）
その代わり、お手軽に買えるので、それはそれでいい。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 19:52:37

T1000/T2000には本当にがんばってもらいたい。
これが売れなければ、ボリュームラインの1U/2UサーバはLinux/Windowsの
侵食を防ぐ事すら出来ないだろう。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 20:01:53

>>390
> OBP/POSTの診断は、Diskの不良セクターとは違うよ。サーバのは特に念入りに行うはず
念入りに行ってもPOST通ってしまう事が良くあるんだよ。
もしかして素人とでも思っている？わざわざblacklistと書いているのに

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

メモリの診断なんてそんなに念入りにやってない
cacheなら容量少ないし、念入りにやってんじゃないかな

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

メモリは指定しないと全部を確認しないよ、確か。
OSがブートできる程度ぐらいしか、デフォルトでしなかった気がする。
これだと、ブート後に2bit壊れている(UEエラー)のメモリを触ると
パニックしてしまう。パニック後は、壊れたメモリを切り離して
リブートする。

全メモリを診断して、2bit壊れている(UEエラー)のメモリを見つけると
切り離してからブートするはず。

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

> これだと、ブート後に2bit壊れている(UEエラー)のメモリを触ると
> パニックしてしまう。パニック後は、壊れたメモリを切り離して
> リブートする。

ちなみに今は、カーネルが2bit壊れているメモリを触った場合だけ
パニック。ユーザアプリが2bit壊れているメモリを触った場合は、
プロセスを停止して、そのメモリ（ページ）を切り離す。

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

>390
PC だと memtest86 実行するのにどれくらいかかるか、知らないの?

で memtest86 通らないものでも数GBメモリ積んでたら
数分(10分オーダー)かける ECC 初期化&POSTチェックは大抵通る。
まあこちらのテストはエラーチェック目的ではないけど、
エラーチェックをしようとしたらどれだけ時間がかかるかってことですね。

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

月に1回とか年に1回、エラー検出不能なエラーが出るくらいの頻度では、
POSTなんかでは検出不能だと思う。POSTに1ヶ月とか1年かけるならともかく。

検出できないエラーは、そのまま正常に処理されたデータとして扱われるので、とても厄介よ。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 22:28:51

>>386
ttp://magazine.fujitsu.com/vol51-4/paper06.pdf を読むと、一部、パリティ保護の
部分もあるようだがパリティエラーでシステムダウンとなるかどうかは不明。

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

ほんと盆暮正月はレベル下がるなぁ... サーバー落ちまくるのの原因が cache の ECC が
ないせいだなんて... 笑える。そんなレベルで機種選定するやつ実在するんだな。びっくりだ。
（ま、選定にクチはさめる立場の人間とは限らんがなw）

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

>>399
保守している経験からすると、CacheのECC errorで落ちるマシンが多いのは
事実。（UltraSPARC-IIの時代はparity error）

この部分を以って機種選定をするとは誰も言っていないでしょう。
大型のサーバでは外せない常識的な機能であると言っているだけ。
次期サーバではチップキル位は装備して欲しい。
Cacheの障害の次に多いのがメインメモリの障害だから。

>>399 パリティエラーを検知すると、もう一度トライする。
それでもダメだった場合は、395の通り。カーネルの場合はpanic

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

Sunの場合、あんまし品質が良くないんで(I、h、Fに比べて)、
エラーのリカバリ機構はふんだんに搭載して欲しいって事。
x900や20K、25Kが落ちた日には胃が痛くなるでしょ。

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

チップキルより、システムボードまたいでミラーして欲しい。
メモリRAIDなら尚うれしい。

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

サーバ機でPOSTのレベルをmaxにすると30分以上かかるんじゃなかったっけ

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

cache ECC エラーが頻発するってことは、なんか別に原因があるでしょ? >>379 みたいに
製造上の欠陥とか。ECC がないのが原因なわけがない。付いてれば継続運用はできたかも
知れないけどね。ECC 付けたら本質的な問題が解決するわけじゃない。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:26:22

>>404 みんなそう思っているんじゃ？

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:30:13

品質問題は、Sunである以上、ある程度見込んでおかないと。
エラー訂正でカバーしてあげないと怖くて使えない。
APLは富士通と共同で設計されるマシンだから期待はしているが。
＃ E10000から素晴らしく改良されたはずのsf15000やsf25000があれでは

**406** · 2006/01/03(火) 23:32:38

蛇足だけど、俺はSunが好きです。復活して欲しいと思っている一人。
でかくて高いサーバは、処理能力もさる事ながら、信頼性でも優れて
いないと売れないからね。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:34:09

FT機、大々的にやってくんないかな。売れそうも無い？

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

T1000/T2000を評価した方いる？うちの会社、まだなんだわ。
Sunが言うように、Webアプリサーバで高性能なら期待の星なんだが。
あと、メールサーバ、アンチウイルスゲートウェイとか。

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

Sun Ray スタートパック、Sun Ray 1g 2 台と Ultra20 で 20 万円かぁ。買ってみようかなぁ..

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

個人で？

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:56:05

一応会社。ほぼ個人だけどw。評価用に。

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:56:36

http://jp.sun.com/promotions/spack2006/
漢ならSun Ray スタートパック 2逝っとけ

**385** · 2006/01/03(火) 23:59:36

>>388
漏れの記憶では、ＣＰＵの１次キャッシュのデータ部や命令部分そのものはＥＣＣ
で保護されていたが、キャッシュのタグは、パリティで、エラーは検出するが訂正
はできなかった。

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

>>414
SPARC64Vでも1次キャッシュはデータだけがECCだよね。
でも、Sun含めて他の会社のCPUは、1次キャッシュはデータ含めてパリティのみ
がほとんどだから。(メインフレーム用CPUだけかな。ここまでやんの)

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

>>413 SunRayは素晴らしい機械だが、結局Windows環境は必要になるんで。
Windows2003 ServerやTaranteraを買うと割高になる。
WBTの方が安上がりなのは痛い。
IS部門からすると悪夢かもしれんけど、HotDeskは便利だよ！

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

漏れの会社はSunRayに移行中...
SunRayに限った話じゃないんだが、Thinクライアントになると、便利な
ユーティリティをインストールする事が(権限の関係で)出来なくなるのが
つらい。情報システム部門のお仕着せ環境しか使えない。
これはかなり悲しいぞ。
SunRayはUNIXベースなんだからemacs位入れて欲しい...
メーラーも使いやすい物を使わせて欲しい...

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

アプリなら自分のホームディレクトリにインスコすれば良いと思うけど。

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

さすがにgcc＋emacs＋漢字変換をホームに入れるのは...
Windows系のアプリだとレジストリいじるやつがいて...

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

>>417
業務に必要なら申請できるはずだけどダメなの？

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

>>419
Web ブラウザーのキャッシュサイズとか考えたらたいした大きさじゃないようなw。
/opt 下とかに入れてもらうほうがいいけどね。pkgadd するだけなんだし。
妙な言い訳で断られるようなら、みんなバカスカホームディレクトリに
入れ出したら管理者も考えるだろう、という線もありかも。

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

SunRayって鯖落ちたら全員死亡なのか?

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

コンピューター落ちたからって死んだ人はまだ見たことないな。

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

> SunRayはUNIXベースなんだからemacs位入れて欲しい...

漏れの会社には、あちらこちらにSunRayがおいてあって、
昼のご飯の後に適度に使わせて貰ってる。

ネットサーフ以外にも、ちゃんと{x}emacsが使えて、
ほどよく便利。

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

>>417

418のいうとおり、パーミッションの問題なら自分のホームに
インストールすれば問題なし。

全体で共用して使いたければサーバにインストールすればいいだけ。

SunRayはインテリ端末みたいなもんだから、何を使うか、
インストールするかは、SunRayとは関係ないよ。

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

エラーが頻発してるけどECCでエャ堰[訂正できてｂ驍ｩら大丈夫

なんて恐ろしいことは言えないよ

エラー検出できてない可能性だってあるんだから。

**名無しさん＠お腹いっぱい。** · 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 年代の話題。