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(火) 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 年代の話題。

**名無しさん＠お腹いっぱい。** · 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
辞めたよ