Sun Microsystems 最後の量産

**名無しさん＠お腹いっぱい。** · 2005/05/01(日) 20:00:56

ナイアガラ・・ギャラクシー・・ロック・・・・・・暁・・

【過去スレ】
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/
Sun Microsystems 最後の理不尽
http://pc8.2ch.net/test/read.cgi/unix/1110926614/

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 03:34:14

では、仮に 2.2. の方法が実現できたとして、それは安全か？
というと実は安全ではない。
結局のところ 2.2. の方法では、暗号化されたパスワード自体
が、LDAP への認証キーとして使われている。従って、パケット
盗聴してネットワークを流れる encrypted password を盗めば、
それをそのまま使って認証に通ることが可能になる。

だから、NIS は認証手段としてより安全な 1. を使っているわ
けだし、SASL は 2.2. のような危険な認証モジュールを、敢
えて提供してないわけ。

結論としては、ssl を使うように設定してない限り、pam_ldap
を使った認証は、NIS よりもむしろ危険ってことだな。
もちろん ssl を使えば安全だが、当然かなり遅くなる。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 03:48:18

> ssl を使うように設定してない限り、pam_ldap を使った認証は、
> NIS よりもむしろ危険ってことだな。

補足。
ここだけ抜き出して読むと誤解を招くかな。
危険になる原因は、
1. SSL を使ってない
というだけではなく、
2. 本人にしかパスワードアクセスをさせない
3. UNIX passwd 形式の DES ないし MD5 パスワードを使う
といった条件にもあった。
だから、2. の条件のない pam_ldap の実装があれば NIS と同レベル
には安全になるだろう。あるいは www.padl.com の pam_ldap 実装
を使うにしても、3. を諦めて
use_sasl on
pam_sasl_mech GSSAPI
として kerberos で運用するとかすれば大丈夫なんじゃないかな。
良く知らないけど。

2. の条件を課さない pam_ldap 実装ってあるのかな。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 13:04:51

> 2. の条件を課さない pam_ldap 実装ってあるのかな。

Sun の pam_ldap モジュールも、認証機構として simple を
選んだ場合には、ネットワークに平文でパスワードが流れるよっ
て書いてあるね。
ttp://docs.sun.com/db/doc/816-3966/6ma797n02?l=ja&a=view

では SASL 経由で CRAM-MD5 や DIGEST-MD5 を使うのはどうか
というと、こういうチャレンジ・レスポンス型の認証を使う場合、
パスワードデータベースには平文 (ないし平文に変換可能な情報)
で保存する必要があるから、サーバ管理者には、パスワードが
バレバレになるんだよね。
GSSAPI 経由で Kerberos を使う場合も、KDC にはパスワードを
平文で保存することになるし。

サーバ管理者に対しても、ネットワーク盗聴に対しても平文で
パスワードを見せないことを目的にするには、LDAP を使う場合
なら SSL を有効にするしかない。
SSL を使う気がないなら、NIS を使った方がまだマシ。

LDAP → 新しいから安全
NIS → 古いから危険
なんて単純な考えは実は大間違いってことだな。
まあ、技術の中身を知らない人が、単に新しいだけでそれを優れ
てるって思い込むことって、他にも色々多いよね。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 13:44:33

>>210
木を見て森を見ずというか、ボロボロなこと言っとるな。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 13:47:50

>>211
例えばどこら辺が？
おいらもパケットダンプしてみたが、確かに平文で流れてたよ。
というわけで、SSL を使うように変更中… orz

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 14:23:44

211は、既に顧客のシステムをNISからLDAPに移行させちゃってる
(当然SSLなし)ので、自分の間違いを認めることができないんじゃ
ないの？自分の誤りを認めると、お客さんのところに謝りに行っ
て設定変更する必要が生じる。だから、210が間違ってると無理
矢理信じこもうとしてると考えると辻褄があう希ガス。
つまり、ボロボロなのは210じゃなくて211の(ry

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 14:24:15

NISでencrypted passwordが平文で
絶対流れないようにするには
どうすればいいですか

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 14:24:35

NISでencrypted passwordが平文で
絶対流れないようにするには
どうすればいいですか

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 14:28:31

Solaris に限れば、secure RPC 使えばできるんじゃない？

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 14:45:30

NIS over secure RPC って、サポートされてたっけ？
NIS+ の方はデフォルトで secure RPC 上で動いてたと
思うけど。

で、NIS の場合は、IPsec の上で動かせば大丈夫だと
思う。この方法なら、Solaris に限らず動く筈。
まあ secure RPC も IPsec も、要は暗号化してるわけで、
暗号化する負荷が気にならないんだったら、LDAP で SSL
でもいいじゃんと思うけどね。

ファイアウォールの内側なので暗号化するほどの機密性は
要らないし、むしろ暗号化のための負荷が気になるっていう
場合は、SSL なしで LDAP 使うくらいなら NIS の方がマシっ
ていうのは 210 の通り。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 14:59:18

SSL は認証のところで公開鍵暗号を使うから重いイメージがある。
共有鍵設定で IPsec を使った方が軽いんじゃないかなあ。
いや、実際に計ってみたわけじゃないですが。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:00:36

>>209
> pam_sasl_mech GSSAPI
> として kerberos で運用するとかすれば大丈夫なんじゃないかな。

なんでわざわざpam-ldapからkerberos使わなきゃならんのだよ…
pam-krb5があるのにさ。

SASLでS/Key、SSLなしつーのなら分かるけども。
>>211に同意で、もうちょっと整理してから出直した方がいい。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:01:39

>>217
> NIS over secure RPC って、サポートされてたっけ？

SolarisはOK。NFSもね。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:09:38

> なんでわざわざpam-ldapからkerberos使わなきゃならんのだよ…
> pam-krb5があるのにさ。

kerberos realm と、そのマシンにアカウントのあるユーザが
一致している場合は pam-krb5 でいいけど、ユーザを realm
のサブセットにしたい場合には pam-ldap を使ってユーザを
制限して、ただし認証は KDC に頼るって運用がしたいことも
あるんじゃない？

> SASLでS/Key、SSLなしつーのなら分かるけども。

そう？ s/key って、ファイアウォールの内側で使うような
ものじゃないと思うけど。で、ファイアウォールの外側で
使う場合、SSL なしだと LDAP の TCP コネクションが乗っと
られる可能性があるから危険じゃない？

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:11:46

>>221
詭弁の一種、極論ですね。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:16:03

そうかなあ。確認だけど、219は、ファイアウォールの
内側で s/key を使うって言ってるの？それとも外側？

今回の件はNISで始まっているから、基本的にはファイア
ウォールの内側の話だと思うだけど。

だとすると、s/key は論外だと思う。
だからといって、SSL なしの LDAP simple authentication
で生パスワードが流れるのは、いくら社内だからと言っても
避けたいというのは割と分かる話じゃない？

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:21:32

>>223
> だからといって、SSL なしの LDAP simple authentication
> で生パスワードが流れるのは、

こんなの極端なのを持ってきて、NISの方がいいって言う論法もどうかしている。

特にSolarisのLDAPによる認証とNISの認証は、
・LDAPはdefaultはclient側でcryptして認証する方式
・流れるのはcryptedなpassword
・secure RPC, SSLなどの暗号化のoptionがある
ということでほとんど変わりがない。

NIS+ならまだアクセスで個人認証ができるからNISよりは優位性がある。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:25:36

> 特にSolarisのLDAPによる認証とNISの認証は、
> ・LDAPはdefaultはclient側でcryptして認証する方式
> ・流れるのはcryptedなpassword

ははあ、なるほど。Solaris 附属の LDAP の場合、
>>206 の言う 1.、>>209 の言う 2. の機能があるわけ
ですか。だとすると NIS と同じですね。

Linux が混ざったりして、PADL の実装を使う場合にまずいと。

**225** · 2005/05/27(金) 17:28:15

> >>209 の言う 2. の機能があるわけ

s/の言う 2. の機能/の言う 2. の条件を課さない実装/

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 17:56:26

勝手にまとめると、サーバ側に encrypted password を保存する
タイプの認証手段を選ぶ場合、

SSL なり secure RPC なり IPsec なりで暗号化する場合:
・LDAP と NIS+ は OK。
・NIS だと encrypted password を誰でも見れるので、お勧めできない。
　ただし *BSD 系の NIS 実装に統一できるなら、この問題を回避できる。
・SSL が使えるのは LDAP。secure RPC が使えるのは NIS+ と NIS。
　IPsec は全てで使える。

暗号化しない場合:
・Solaris の pam_ldap で適切に設定するなら OK。
・PADL の pam_ldap の場合、平文パスワードが流れるのでお勧めできない。
・NIS+ だと、普通そういう選択肢はない。(デフォルトで secure RPC)
・NIS もまあ OK。

ってところかな。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 18:17:26

「*BSD 系の NIS」ってやつだけど、

- 適当なマシンを（無許可で勝手に）接続
- root 権限で ypcat
- おウチへ持ち帰って総当たり

は避けれないよね? NIS で指摘されてた欠点ってこういうことだったと
思うけど.. LDAP でも同じなの? ホント??

ところで、LDAP サーバー側でユーザー認証とか出てたけど、それ一体何?
なんでそんな必要があるの??? どういう利点があるの? クライアントには
OK/NG が戻るんだよね? それ盲目的に信じて動くわけ?

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 18:34:23

> 「*BSD 系の NIS」ってやつだけど、
略
> は避けれないよね?

暗号化（IPsec など）を使うのであれば避けられます。

暗号化しない場合、LDAP でも、
- 適当なマシンを（無許可で勝手に）接続
- root 権限で ARP poisoning して packet capture
- Solaris の pam_ldap の場合、userPassword属性が読める。
　PADL の pam_ldap の場合、生パスワードがそのまま見える。
という危険があります。

従って、暗号化しない場合、Solaris 版だと LDAP も NIS と同程度の
危険性があり、PADL 版の場合、NIS よりむしろ危ないと思われます。

> LDAP サーバー側でユーザー認証とか出てたけど、それ一体何?
> なんでそんな必要があるの??? どういう利点があるの? クライアントには
> OK/NG が戻るんだよね? それ盲目的に信じて動くわけ?

そういうことになります。利点はLDAPスレの
http://pc8.2ch.net/test/read.cgi/unix/1012650811/611
のPADLの項に書いてある通り。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 18:54:01

>>229
わかってないヤカン。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:02:50

どこら辺が？

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:10:01

このスレでLDAPを安全だと思ってる人って、
ldapsearch -x -b ほげほげ '(objectclass=*)'
のようなコマンドで、ypcatと同じことがLDAPでもできるって
ことを知らないような気がする。

PADL版で運用している場合は、こうやってもuserPassword属性
は読めないんだけど、Solaris版なら読めるのでNISと同じ。
じゃあPADL版は安全かというと生パスワードが流れるわけで。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:16:15

NISの盗聴の危険性を聞かれてるのに
IPSecで答えたつもりなのって何かおかしいような

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:25:11

>>229が書いているのは、NISで盗聴できる場合は、LDAPでも盗聴
できるし、特にPADL版のLDAPの場合、NISで盗聴した場合以上に、
盗聴の被害が大きいってことでしょ。

LDAPでも暗号化すれば盗聴を防げるけど、NISでもIPsecで暗号化
すればやはり盗聴できないからやはり同じ。(IPsec の鍵を知らな
い限り、勝手に接続してypcatしても失敗するだけ)

LDAP で CRAM-MD5 や DIGEST-MD5 を使えば、暗号化しなくても
盗聴を防げる。でも、>>227 ではサーバ側に encrypted password
を保存する (cleartext password をサーバ管理者に見せない)
という条件がついてるから、現在のスレの話の範疇から外れてる。

結局分かってないのは>>230だったってことでは？

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:34:35

ここ見てるとUNIXはユーザ認証関係でWindowsより劣ってるように見えるぞ

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:38:28

そういえばファイル共有に関してもWindowsの方が手軽のような気がする
WindowsServerなら、時間や日付、曜日によってアクセスできなくさせたりできるし
グループを入れ子にしてアクセス権設定できる

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:39:58

Windows の認証方式は encrypted password をネットワークに
流すが、実はその encrypted password 自体が認証キーとして
使われるというものなので、ほとんど cleartext 認証と変わら
んよ。駄目駄目。
だからといって、認証手段を PAM みたいに簡単に変更できるわ
けでもないし。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 19:52:43

>>237
WindowsはActiveDirectory使う場合はKerberos認証なんじゃないの？

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 20:02:24

Active Directory の場合はそうね。
でもその場合は UNIX で LDAP + Kerberos するのと同じでしょ。
Active Directory の実体は LDAP なんだし。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 20:09:43

Windows2000やWindowsXPの場合はアカウントの一元管理する場合、
ActiveDirectory使うのが普通なんだが

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 20:13:24

で、その Windows と同じことは UNIX でも LDAP と
Kerberos でできると。
UNIX の場合 nsswitch と pam で、他のディレクトリ
サービス (NIS とか NIS+ とか、Active Directory
とか、あるいは独自開発したものとか) を使うことも
できるが、Windows だと選択不能だと。

**名無しさん＠お腹いっぱい。** · 2005/05/27(金) 20:21:58

選択不能だから、詳しくない人間に変にいじられなくてすむってのはあるな
UNIXの場合、rootは神だけどWindowsの場合、Administratorは神とよべるほと権限ないし

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 00:21:37

神はゲイシ

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 00:23:31

MS-Windows は認証周り難しいから、ユルユルか典型的設定になってるのが
ほとんど。Unix くらい単純にしといて、sudo で細かくやるっての
悪くないと思うけど。まあ後付けモノだけどね。
OS の認証周りの仕掛けの不具合は Unix くらい単純でもいろいろ出てくるから、
MS-Windows くらい大掛かりだとデバッグはかなり大変なはず。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 00:36:08

結局 N1 Grid使えば人称とかもブレイクスルーなんｄあろ？　ぐちゃぐちゃ文句いうなよね！

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 00:53:08

NIS 用に IPsec で 1 網作る、ってのは斬新だと思った。
LDAP で各種 OS 安定して相互運用できるようになるまでそれも
いいかも。物理的なセグメントも越えられるし。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 01:05:55

やたら伸びてると思ったら、既にSunは関係ねーｗ

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 04:29:51

ZFS実装の暁には！

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 09:47:11

次は「最後の実装」か？

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 11:59:59

>>232
ほとんどのLDAPサーバにAccess Control Listがあるのを知らない人?
ACLを設定して、userPassword属性を読めないようにする設定なんて、
多くのサイトでやっている人がいますよ。

NIS+だってsecure RPCで本人か管理者意外読めないようにする
DES認証モード使っているところあるしね。

無知なのに知ったかぶりは君だから。

それから、pam_ldapで、bindにKerberos認証を使うのはクレージー。
Kerberosは、login認証じゃなくて、セッション認証だから、
pam_ldapの提供しているサービスと整合性が悪い。

**232** · 2005/05/28(土) 14:51:19

> ほとんどのLDAPサーバにAccess Control Listがあるのを知らない人?
> ACLを設定して、userPassword属性を読めないようにする設定なんて、
> 多くのサイトでやっている人がいますよ。

当然知ってますよ。一度でも PADL 版の設定をやった人間なら
知らないわけがない。でも、>>224 や
http://pc8.2ch.net/test/read.cgi/unix/1012650811/611
によると、Solaris 版ではuserPassword属性を読みとり可能に
する必要がある設定ポリシーもあり、その場合は ldapsearch を
使うと NIS の場合と同じようにパスワードが読める。

で、どうやら >>229 はそのことを理解してないように見えるので
それを指摘したんだけど、おかしい？

**232** · 2005/05/28(土) 14:54:11

リンク先を間違えた。
>>224 や
http://pc8.2ch.net/test/read.cgi/unix/1012650811/611
にある記述を理解してないように見えるのは
>>229 じゃなくて、>>228 の方ね。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 14:56:36

いや、LDAP でもユーザー認証時に userPassword 値がネットワーク流れるのは
SSL かけてなければその通りなわけで、SSL かけるのがどのくらい当たり前か、
というのがポイントだってことだと思うよ。
「SSL やる手間かけるくらいなら IPsec でいいや」ってのもまあいいんでない?

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 14:57:41

ああ、>>253 は >>250 ね。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 15:38:43

>>253
> いや、LDAP でもユーザー認証時に userPassword 値がネットワーク
> 流れるのはSSL かけてなければその通りなわけで

いや、ところが、PADL 版 pam_ldap を使ってると、userPassword 値は
流す必要がないし、だから普通は流さないように設定するので話がやや
こしい。ただし PADL 版のデフォルト設定だと、LDAP の simple
authentication のためにパスワードが平文で流れるので、Solaris 版
pam_ldap 以上に SSL を使うことが重要になるんだけど。

>>250 は、Solaris 版 pam_ldap のことを分かってないってことです
かね？ (ここ Sun スレなんだけど)

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 15:39:23

例えば、下記 2.1.5 には「通信には SSL が必要」と書いてある。

ttp://www.linux.or.jp/JF/JFdocs/LDAP-Implementation-HOWTO/pamnss.html

けど、クライアント認証は現状非サポートとも書いてある。これだと結局
「知らない」ホストにパスワード持っていかれる穴が残るね。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 15:46:39

>>255
私の感覚的には、サーバー側で認証するのは論外。Samba のマネごとか?
LDAP スレ 611 は読んだけど、タワごととしか思えん。Unix の /etc/passwd の
簡潔さまで破棄してしまう必要はない。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 16:14:01

> 例えば、下記 2.1.5 には「通信には SSL が必要」と書いてある。

本当だ。
やっぱりちゃんとしたドキュメントには当然そう書いてあるんだねえ。
問題は、PADL 版のデフォルト設定が、SSL を使わないようになって
ることと、@IT の記事みたいに、SSL を使わなくても安全だと誤解
させる文書が出回ってて、このスレでも分かる通り、結構それを
信じている人が多いことかねえ。
ttp://www.atmarkit.co.jp/flinux/rensai/root02/root02a.html

> けど、クライアント認証は現状非サポートとも書いてある。これだと結局
> 「知らない」ホストにパスワード持っていかれる穴が残るね。

いや、PADL版を使う場合 slapd.conf に
access to attrs=userPassword
        by self write
        by anonymous auth
        by * none
access to *
        by self write
        by * read
といった設定を入れても動作するし、だから普通はこういう設定を
してるわけ。でも、JF の HOWTO にはこの設定の記述がないのか…

PADL 版でこの設定を行なっている場合、ldapsearch で全員の userPassword
フィールドを盗まれる危険はない。もっとも userPassword 以外の情報
については、盗まれる危険があるので、他の手段でアクセス制限しない
といけないし、デフォルト設定だとパスワードが平文で流れちゃうけど。

**名無しさん＠お腹いっぱい。** · 2005/05/28(土) 21:53:26

>>258
> @IT の記事みたいに、SSL を使わなくても安全だと誤解
> させる文書が出回ってて、このスレでも分かる通り、結構それを
> 信じている人が多いことかねえ。

ちょっとググって見たけど、個人の設定メモページぐらいなら
ともかく、企業や大学が提供する情報ページにも結構あるね。
@IT だけじゃない。

> access to *
> by self write
> by * read

さらに気になったんだけど、この「self write」って危険じゃない？
gecos 以外は書き込み不可にしとくべきのような…
でも、こういう設定を勧めてる記事も沢山あるなあ。
あれれれ？

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 02:45:13

おいおいここ何のスレだよ！？

Sun Microsystems 最後のＳＳＬ？ｗ

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 09:48:06

Sun Microsystems ラストNISバタリオンのスレです

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 18:06:56

UltraSPARC IV+搭載サーバーはまだですか？
Solarisサーバ買う場合、今の状態じゃ、SUNのサーバー買うより富士通のサーバー買った方がいいな

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 18:23:59

6900が夏じゃなかったっけか？
うちの客先がそれを待ってる状態。

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 19:35:43

>>262
　当然。少なくとも無能で自己保身の塊で、社内ゴルフor社内接待ずけ漬けの
会社から勝手は駄目ダス。
エビデンスをコピるのに精一杯の会社ダス。
ほほほ。

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 19:54:20

SunとOracleは仲良しこよし
略してサンクリ

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 22:46:34

でもOracleの開発プラットフォームはSolarisからLinuxになったけどな。

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 23:14:23

SPARCはもうだめだろうが、MSXみたいに20年後に道楽として復活すると思う。

**名無しさん＠お腹いっぱい。** · 2005/05/29(日) 23:44:39

最近でた SPARC64 2.16GHz は実はハイエンドCPUの中では
最速なので、実はそう捨てたもんじゃないみたいよ。
POWER5 も Itanium も、まだ 2GHz を越えてないんだよね。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 00:19:57

2GのSPARCV64より、1.6GのPOWER5の方が速いけどなｗ

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 00:30:32

IBM の工作員？
少なくとも CINT2000 では SPARC64 の方が速いよ。

www.spec.org より
SPARC64 2160MHz base:1456 peak:1594
POWER5 1900MHz base:1392 peak:1452
ほらね。

しかもこれ、POWER5 1.6GHz じゃなくて 1.9GHz の値だし。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 00:52:40

SPARCがダメなのではない！！Sun Microsystemsがダメなのだ！！
20年後に1-Chip SS20とかASCIIが出したら俺は買うｗ

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 02:17:07

道楽なら Tru64 on Alpha

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 05:07:38

DEC信者で道楽ならUnix on VAXとかだろ。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 15:07:58

外ヅラは Psion5 で中身が sun4c, cg6。SunOS 4.1.4 と Sprite が動く。
NEXTSTEP も動く。NeWS のデモも動く。そゆのがいい。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 15:09:14

VAX なら simh で既に楽しめるぞ。SPARCstation 1 のシミュレーター
欲しいなあ。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 15:26:56

SPARC64 2GHz 最後の希望

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 21:30:52

>>268
XeonやOpteronはハイエンドCPUじゃないのねん。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 21:32:37

>>277
エントリーCPU

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 22:25:30

ハイエンド機に載ってないもんね。

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 23:03:08

Athlon64 でよろ！！

**名無しさん＠お腹いっぱい。** · 2005/05/30(月) 23:12:10

>>277
「SPARC64V」
http://primeserver.fujitsu.com/primepower/concept/processor/high_a.html

この程度の信頼性を備えていてはじめてハイエンドと呼べる。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 00:26:08

はい、はい、はい、はい

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 00:39:24

まあ、いろんな定義の仕方があると思うが。
ハイエンド機に使いようがないやつはハイエンド CPU じゃないだろうな。
ハイエンド機にまだ使われてないだけで、実力はハイエンド CPU ってのは
あるかもな。そうだといいな、じゃ、がんばれよ。うひひ。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 00:42:47

これで SPARC のアーキに問題があるという話は一応払拭されたかな。
富士通の SPARC 部隊もそれほど潤沢にリソースもらってるわけでも
ないだろうから、かなりがんばってる、ってことかな。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 01:36:53

SPARC が亀だったのは単にＴＩがどんくさかっただけだろ？ｗ

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 01:41:05

Intelが頑張り過ぎだったのが一服して、みんな追い付いて来た
というのが実態だろう。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 02:17:47

Sun Microsystems 逆襲のSPARC64V

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 03:12:59

AMD64 の CPU 開発には VMS の David Cutler が噛んでいるらしい。
まるきり DEC じゃないか。
David Cutler は昔 VMS 上に Unix 互換レイヤを作ったが実際にはぜんぜん
動かなくて笑い者になったらしい。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 03:35:41

>>286
一服かな。カベにぶちあたっているんじゃないか。
Pen4 の 2.4GHz と 3.8GHz は、一部の特殊な用途を除いて
性能に違いがないだろ?
消費電力は違うがな。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 05:04:32

>>289
何を言ってるんだ？
日常大半の処理で明らかな差があると思うが。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 10:56:33

>>288
カトラーってマイクロソフトからAMDに移ってたの？

**291** · 2005/05/31(火) 10:59:20

ぐぐったらこんなんでてきた
http://itpro.nikkeibp.co.jp/free/NT/WinInterview/20040621/1/

――――Windows NTを開発したDavid Cutler（デビッド・カトラー）氏ですね。
［Muglia］ええ，DaveはまさにAMD64にかかわるあらゆる所にいました。
Daveはそのチップの設計と，非常に密接して仕事をしました。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 11:24:41

TLPと高速メモリアクセスで他を圧倒するSun Niagara公式発表
http://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm

つーか、アウトオブオーダなメモリアクセスって、なんですか?

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 12:04:13

メモリアクセスがコマンド／レスポンスを使ったトランザクション
方式になってて、複数のメモリアクセス要求をキューイングして
並列に発行し、かつ後に発行したアクセス要求が、前に発行した
アクセス要求を追い越して、先に答を返すこともあるってことでしょ。

SPARC のメモリアクセスは、デフォルトで total store ordering
として定義されてるし、partial store ordering もオプションで
OK だからね。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 14:13:06

>>290
ほとんどはマシン入れ替えても気がつかないと思う。
気づくのは、マルチメディア系エンコーディング常態の人、マーゲー、
コンパイルオタクくらいなんじゃない?

「熱と騒音で」違いがわかる、ってのはあるかも。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 14:22:00

>>288 >>292
OS 開発者としてアドバイスした、って程度じゃないかな。わかんないけど。
DEC 出の気心の知れた同士だったのかもねぇ。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 14:35:55

>>296

↓みると、x86_64版のWindowsのために、数年間に渡って
AMDと共同作業をしたってあるよ。
ttp://www.amd.com/us-en/Weblets/0,,7832_8366_7823_8718%5E7839,00.html
別にAMDに移ったわけじゃなくて、Microsoftの仕事として
やってたみたいね。

> DEC 出の気心の知れた同士だったのかもねぇ。

これはあるかもね。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 17:10:25

>>295
つまり、差額分はムダづかい、ってことだな。膨大だな。
インテルこけたら原発減らせますキャンペーンってのはどう?

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 18:11:13

> SPARC のメモリアクセスは、デフォルトで total store ordering
> として定義されてるし、partial store ordering もオプションで
> OK だからね。

でもSolarisはSPARCをtotal store orderで使っているらしいね。
と、前出てたサンのブログにあった。
http://blog.sun.com/roller/page/eota

難しくてよく分からなかったけれど。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 18:46:52

TSO と PSO って、プロセス単位で切り替えられたりするの?
出来るんなら、PSO にして Niagara でグッと速くなったりすると面白いね。
コンパイラは対応してるのかな?

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 19:27:17

> TSO と PSO って、プロセス単位で切り替えられたりするの?

PSOやRMOはプロセッサーの機能だから、CPUがサポートしていれば、
プロセッサ単位で切替えられるはず。

理論的には、ソフトが動的に変更できると思うけど、問題はソフトが
そのメモリモデルをサポートしているかどうかだと思う。

Niagaraとかに関係なく、Solarisが本当にTSOだけしかサポートしていない
のなら、CPUをPSOモードにすればSolarisがまともに動かなくなってしまうと
思うけれど。

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 19:30:50

> TLPと高速メモリアクセスで他を圧倒するSun Niagara公式発表
> http://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm
>
> つーか、アウトオブオーダなメモリアクセスって、なんですか?

上をみたのだが、CPUのアウトオブオーダなメモリアクセスではなくて、
メモリコントローラのアウトオブオーダなメモリアクセスのことではないの？
だから、NiagaraだとTSOとかPSOとか関係なくて、いつもアウトオブオーダな
メモリアクセスになるんじゃないの？

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 19:31:39

プロセス単位に切り替えられるならコンパイラだけの問題だと思うけど。
適当にバリア命令を入れてあればいいんでしょ?
ライブラリは当然共有できんけど。カーネルの出入りでちゃんと
切り替わってれば大丈夫なんでは?

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 19:41:35

>>302
だからと言って、CPUからみてTSO(なりPSOなり)を全く
満たさなくなるとまずいよね？
バラバラの順序で返ってきた返事を、トランザクション
IDを使ってTSO(なりPSOなり)を満たす順序に整列し直す
って意味？

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 22:25:45

サーバ販売シェアでIBMとHPが事実上タイに
http://www.itmedia.co.jp/enterprise/articles/0505/28/news002.html

・・デルに並ばれた

**名無しさん＠お腹いっぱい。** · 2005/05/31(火) 22:42:17

ここはプロセッサとプロセスが混ざってるインターネットですね。

**名無しさん＠お腹いっぱい。** · 2005/06/01(水) 00:02:19

混ぜるな危険！