Sun Microsystems 最後の量産
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
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/
0222名無しさん＠お腹いっぱい。
2005/05/27(金) 17:11:46詭弁の一種、極論ですね。
0223名無しさん＠お腹いっぱい。
2005/05/27(金) 17:16:03内側で s/key を使うって言ってるの？ それとも外側？
今回の件はNISで始まっているから、基本的にはファイア
ウォールの内側の話だと思うだけど。
だとすると、s/key は論外だと思う。
だからといって、SSL なし の LDAP simple authentication
で生パスワードが流れるのは、いくら社内だからと言っても
避けたいというのは割と分かる話じゃない？
0224名無しさん＠お腹いっぱい。
2005/05/27(金) 17:21:32> だからといって、SSL なし の LDAP simple authentication
> で生パスワードが流れるのは、
こんなの極端なのを持ってきて、NISの方がいいって言う論法もどうかしている。
特にSolarisのLDAPによる認証とNISの認証は、
・LDAPはdefaultはclient側でcryptして認証する方式
・流れるのはcryptedなpassword
・secure RPC, SSLなどの暗号化のoptionがある
ということでほとんど変わりがない。
NIS+ならまだアクセスで個人認証ができるからNISよりは優位性がある。
0225名無しさん＠お腹いっぱい。
2005/05/27(金) 17:25:36> ・LDAPはdefaultはclient側でcryptして認証する方式
> ・流れるのはcryptedなpassword
ははあ、なるほど。Solaris 附属の LDAP の場合、
>>206 の言う 1.、>>209 の言う 2. の機能があるわけ
ですか。だとすると NIS と同じですね。
Linux が混ざったりして、PADL の実装を使う場合にまずいと。
0227名無しさん＠お腹いっぱい。
2005/05/27(金) 17:56:26タイプの認証手段を選ぶ場合、
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。
ってところかな。
0228名無しさん＠お腹いっぱい。
2005/05/27(金) 18:17:26- 適当なマシンを（無許可で勝手に）接続
- root 権限で ypcat
- おウチへ持ち帰って総当たり
は避けれないよね? NIS で指摘されてた欠点ってこういうことだったと
思うけど.. LDAP でも同じなの? ホント??
ところで、LDAP サーバー側でユーザー認証とか出てたけど、それ一体何?
なんでそんな必要があるの??? どういう利点があるの? クライアントには
OK/NG が戻るんだよね? それ盲目的に信じて動くわけ?
0229名無しさん＠お腹いっぱい。
2005/05/27(金) 18:34:23略
> は避けれないよね?
暗号化（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の項に書いてある通り。
0230名無しさん＠お腹いっぱい。
2005/05/27(金) 18:54:01わかってないヤカン。
0231名無しさん＠お腹いっぱい。
2005/05/27(金) 19:02:500232名無しさん＠お腹いっぱい。
2005/05/27(金) 19:10:01ldapsearch -x -b ほげほげ '(objectclass=*)'
のようなコマンドで、ypcatと同じことがLDAPでもできるって
ことを知らないような気がする。
PADL版で運用している場合は、こうやってもuserPassword属性
は読めないんだけど、Solaris版なら読めるのでNISと同じ。
じゃあPADL版は安全かというと生パスワードが流れるわけで。
0233名無しさん＠お腹いっぱい。
2005/05/27(金) 19:16:15IPSecで答えたつもりなのって何かおかしいような
0234名無しさん＠お腹いっぱい。
2005/05/27(金) 19:25:11できるし、特にPADL版のLDAPの場合、NISで盗聴した場合以上に、
盗聴の被害が大きいってことでしょ。
LDAPでも暗号化すれば盗聴を防げるけど、NISでもIPsecで暗号化
すればやはり盗聴できないからやはり同じ。(IPsec の鍵を知らな
い限り、勝手に接続してypcatしても失敗するだけ)
LDAP で CRAM-MD5 や DIGEST-MD5 を使えば、暗号化しなくても
盗聴を防げる。でも、>>227 ではサーバ側に encrypted password
を保存する (cleartext password をサーバ管理者に見せない)
という条件がついてるから、現在のスレの話の範疇から外れてる。
結局分かってないのは>>230だったってことでは？
0235名無しさん＠お腹いっぱい。
2005/05/27(金) 19:34:350236名無しさん＠お腹いっぱい。
2005/05/27(金) 19:38:28WindowsServerなら、時間や日付、曜日によってアクセスできなくさせたりできるし
グループを入れ子にしてアクセス権設定できる
0237名無しさん＠お腹いっぱい。
2005/05/27(金) 19:39:58流すが、実はその encrypted password 自体が認証キーとして
使われるというものなので、ほとんど cleartext 認証と変わら
んよ。駄目駄目。
だからといって、認証手段を PAM みたいに簡単に変更できるわ
けでもないし。
0238名無しさん＠お腹いっぱい。
2005/05/27(金) 19:52:43WindowsはActiveDirectory使う場合はKerberos認証なんじゃないの？
0239名無しさん＠お腹いっぱい。
2005/05/27(金) 20:02:24でもその場合は UNIX で LDAP + Kerberos するのと同じでしょ。
Active Directory の実体は LDAP なんだし。
0240名無しさん＠お腹いっぱい。
2005/05/27(金) 20:09:43ActiveDirectory使うのが普通なんだが
0241名無しさん＠お腹いっぱい。
2005/05/27(金) 20:13:24Kerberos でできると。
UNIX の場合 nsswitch と pam で、他のディレクトリ
サービス (NIS とか NIS+ とか、Active Directory
とか、あるいは独自開発したものとか) を使うことも
できるが、Windows だと選択不能だと。
0242名無しさん＠お腹いっぱい。
2005/05/27(金) 20:21:58UNIXの場合、rootは神だけどWindowsの場合、Administratorは神とよべるほと権限ないし
0243名無しさん＠お腹いっぱい。
2005/05/28(土) 00:21:370244名無しさん＠お腹いっぱい。
2005/05/28(土) 00:23:31ほとんど。Unix くらい単純にしといて、sudo で細かくやるっての
悪くないと思うけど。まあ後付けモノだけどね。
OS の認証周りの仕掛けの不具合は Unix くらい単純でもいろいろ出てくるから、
MS-Windows くらい大掛かりだとデバッグはかなり大変なはず。
0245名無しさん＠お腹いっぱい。
2005/05/28(土) 00:36:080246名無しさん＠お腹いっぱい。
2005/05/28(土) 00:53:08LDAP で各種 OS 安定して相互運用できるようになるまでそれも
いいかも。物理的なセグメントも越えられるし。
0247名無しさん＠お腹いっぱい。
2005/05/28(土) 01:05:550248名無しさん＠お腹いっぱい。
2005/05/28(土) 04:29:510249名無しさん＠お腹いっぱい。
2005/05/28(土) 09:47:110250名無しさん＠お腹いっぱい。
2005/05/28(土) 11:59:59ほとんどのLDAPサーバにAccess Control Listがあるのを知らない人?
ACLを設定して、userPassword属性を読めないようにする設定なんて、
多くのサイトでやっている人がいますよ。
NIS+だってsecure RPCで本人か管理者意外読めないようにする
DES認証モード使っているところあるしね。
無知なのに知ったかぶりは君だから。
それから、pam_ldapで、bindにKerberos認証を使うのはクレージー。
Kerberosは、login認証じゃなくて、セッション認証だから、
pam_ldapの提供しているサービスと整合性が悪い。
0251232
2005/05/28(土) 14:51:19> ACLを設定して、userPassword属性を読めないようにする設定なんて、
> 多くのサイトでやっている人がいますよ。
当然知ってますよ。一度でも PADL 版の設定をやった人間なら
知らないわけがない。でも、>>224 や
http://pc8.2ch.net/test/read.cgi/unix/1012650811/611
によると、Solaris 版ではuserPassword属性を読みとり可能に
する必要がある設定ポリシーもあり、その場合は ldapsearch を
使うと NIS の場合と同じようにパスワードが読める。
で、どうやら >>229 はそのことを理解してないように見えるので
それを指摘したんだけど、おかしい？
0252232
2005/05/28(土) 14:54:11>>224 や
http://pc8.2ch.net/test/read.cgi/unix/1012650811/611
にある記述を理解してないように見えるのは
>>229 じゃなくて、>>228 の方ね。
0253名無しさん＠お腹いっぱい。
2005/05/28(土) 14:56:36SSL かけてなければその通りなわけで、SSL かけるのがどのくらい当たり前か、
というのがポイントだってことだと思うよ。
「SSL やる手間かけるくらいなら IPsec でいいや」ってのもまあいいんでない?
0254名無しさん＠お腹いっぱい。
2005/05/28(土) 14:57:410255名無しさん＠お腹いっぱい。
2005/05/28(土) 15:38:43> いや、LDAP でもユーザー認証時に userPassword 値がネットワーク
> 流れるのはSSL かけてなければその通りなわけで
いや、ところが、PADL 版 pam_ldap を使ってると、userPassword 値は
流す必要がないし、だから普通は流さないように設定するので話がやや
こしい。ただし PADL 版のデフォルト設定だと、LDAP の simple
authentication のためにパスワードが平文で流れるので、Solaris 版
pam_ldap 以上に SSL を使うことが重要になるんだけど。
>>250 は、Solaris 版 pam_ldap のことを分かってないってことです
かね？ (ここ Sun スレなんだけど)
0256名無しさん＠お腹いっぱい。
2005/05/28(土) 15:39:23ttp://www.linux.or.jp/JF/JFdocs/LDAP-Implementation-HOWTO/pamnss.html
けど、クライアント認証は現状非サポートとも書いてある。これだと結局
「知らない」ホストにパスワード持っていかれる穴が残るね。
0257名無しさん＠お腹いっぱい。
2005/05/28(土) 15:46:39私の感覚的には、サーバー側で認証するのは論外。Samba のマネごとか?
LDAP スレ 611 は読んだけど、タワごととしか思えん。Unix の /etc/passwd の
簡潔さまで破棄してしまう必要はない。
0258名無しさん＠お腹いっぱい。
2005/05/28(土) 16:14:01本当だ。
やっぱりちゃんとしたドキュメントには当然そう書いてあるんだねえ。
問題は、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 以外の情報
については、盗まれる危険があるので、他の手段でアクセス制限しない
といけないし、デフォルト設定だとパスワードが平文で流れちゃうけど。
0259名無しさん＠お腹いっぱい。
2005/05/28(土) 21:53:26> @IT の記事みたいに、SSL を使わなくても安全だと誤解
> させる文書が出回ってて、このスレでも分かる通り、結構それを
> 信じている人が多いことかねえ。
ちょっとググって見たけど、個人の設定メモページぐらいなら
ともかく、企業や大学が提供する情報ページにも結構あるね。
@IT だけじゃない。
> access to *
> by self write
> by * read
さらに気になったんだけど、この「self write」って危険じゃない？
gecos 以外は書き込み不可にしとくべきのような…
でも、こういう設定を勧めてる記事も沢山あるなあ。
あれれれ？
0260名無しさん＠お腹いっぱい。
2005/05/29(日) 02:45:13Sun Microsystems 最後のＳＳＬ？ｗ
0261名無しさん＠お腹いっぱい。
2005/05/29(日) 09:48:060262名無しさん＠お腹いっぱい。
2005/05/29(日) 18:06:56Solarisサーバ買う場合、今の状態じゃ、SUNのサーバー買うより富士通のサーバー買った方がいいな
0263名無しさん＠お腹いっぱい。
2005/05/29(日) 18:23:59うちの客先がそれを待ってる状態。
0264名無しさん＠お腹いっぱい。
2005/05/29(日) 19:35:43当然。少なくとも無能で自己保身の塊で、社内ゴルフor社内接待ずけ漬けの
会社から勝手は駄目ダス。
エビデンスをコピるのに精一杯の会社ダス。
ほほほ。
0265名無しさん＠お腹いっぱい。
2005/05/29(日) 19:54:20略してサンクリ
0266名無しさん＠お腹いっぱい。
2005/05/29(日) 22:46:340267名無しさん＠お腹いっぱい。
2005/05/29(日) 23:14:230268名無しさん＠お腹いっぱい。
2005/05/29(日) 23:44:39最速なので、実はそう捨てたもんじゃないみたいよ。
POWER5 も Itanium も、まだ 2GHz を越えてないんだよね。
0269名無しさん＠お腹いっぱい。
2005/05/30(月) 00:19:570270名無しさん＠お腹いっぱい。
2005/05/30(月) 00:30:32少なくとも CINT2000 では SPARC64 の方が速いよ。
www.spec.org より
SPARC64 2160MHz base:1456 peak:1594
POWER5 1900MHz base:1392 peak:1452
ほらね。
しかもこれ、POWER5 1.6GHz じゃなくて 1.9GHz の値だし。
0271名無しさん＠お腹いっぱい。
2005/05/30(月) 00:52:4020年後に1-Chip SS20とかASCIIが出したら俺は買うｗ
0272名無しさん＠お腹いっぱい。
2005/05/30(月) 02:17:070273名無しさん＠お腹いっぱい。
2005/05/30(月) 05:07:380274名無しさん＠お腹いっぱい。
2005/05/30(月) 15:07:58NEXTSTEP も動く。NeWS のデモも動く。そゆのがいい。
0275名無しさん＠お腹いっぱい。
2005/05/30(月) 15:09:14欲しいなあ。
0276名無しさん＠お腹いっぱい。
2005/05/30(月) 15:26:560277名無しさん＠お腹いっぱい。
2005/05/30(月) 21:30:52XeonやOpteronはハイエンドCPUじゃないのねん。
0278名無しさん＠お腹いっぱい。
2005/05/30(月) 21:32:37エントリーCPU
0279名無しさん＠お腹いっぱい。
2005/05/30(月) 22:25:300280名無しさん＠お腹いっぱい。
2005/05/30(月) 23:03:080281名無しさん＠お腹いっぱい。
2005/05/30(月) 23:12:10「SPARC64V」
http://primeserver.fujitsu.com/primepower/concept/processor/high_a.html
この程度の信頼性を備えていてはじめてハイエンドと呼べる。
0282名無しさん＠お腹いっぱい。
2005/05/31(火) 00:26:080283名無しさん＠お腹いっぱい。
2005/05/31(火) 00:39:24ハイエンド機に使いようがないやつはハイエンド CPU じゃないだろうな。
ハイエンド機にまだ使われてないだけで、実力はハイエンド CPU ってのは
あるかもな。そうだといいな、じゃ、がんばれよ。うひひ。
0284名無しさん＠お腹いっぱい。
2005/05/31(火) 00:42:47富士通の SPARC 部隊もそれほど潤沢にリソースもらってるわけでも
ないだろうから、かなりがんばってる、ってことかな。
0285名無しさん＠お腹いっぱい。
2005/05/31(火) 01:36:530286名無しさん＠お腹いっぱい。
2005/05/31(火) 01:41:05というのが実態だろう。
0287名無しさん＠お腹いっぱい。
2005/05/31(火) 02:17:470288名無しさん＠お腹いっぱい。
2005/05/31(火) 03:12:59まるきり DEC じゃないか。
David Cutler は昔 VMS 上に Unix 互換レイヤを作ったが実際にはぜんぜん
動かなくて笑い者になったらしい。
0289名無しさん＠お腹いっぱい。
2005/05/31(火) 03:35:41一服かな。カベにぶちあたっているんじゃないか。
Pen4 の 2.4GHz と 3.8GHz は、一部の特殊な用途を除いて
性能に違いがないだろ?
消費電力は違うがな。
0290名無しさん＠お腹いっぱい。
2005/05/31(火) 05:04:32何を言ってるんだ？
日常大半の処理で明らかな差があると思うが。
0291名無しさん＠お腹いっぱい。
2005/05/31(火) 10:56:33カトラーってマイクロソフトからAMDに移ってたの？
0292291
2005/05/31(火) 10:59:20http://itpro.nikkeibp.co.jp/free/NT/WinInterview/20040621/1/
――――Windows NTを開発したDavid Cutler（デビッド・カトラー）氏ですね。
［Muglia］ええ，DaveはまさにAMD64にかかわるあらゆる所にいました。
Daveはそのチップの設計と，非常に密接して仕事をしました。
0293名無しさん＠お腹いっぱい。
2005/05/31(火) 11:24:41http://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm
つーか、アウトオブオーダなメモリアクセスって、なんですか?
0294名無しさん＠お腹いっぱい。
2005/05/31(火) 12:04:13方式になってて、複数のメモリアクセス要求をキューイングして
並列に発行し、かつ後に発行したアクセス要求が、前に発行した
アクセス要求を追い越して、先に答を返すこともあるってことでしょ。
SPARC のメモリアクセスは、デフォルトで total store ordering
として定義されてるし、partial store ordering もオプションで
OK だからね。
0295名無しさん＠お腹いっぱい。
2005/05/31(火) 14:13:06ほとんどはマシン入れ替えても気がつかないと思う。
気づくのは、マルチメディア系エンコーディング常態の人、マーゲー、
コンパイルオタクくらいなんじゃない?
「熱と騒音で」違いがわかる、ってのはあるかも。
0296名無しさん＠お腹いっぱい。
2005/05/31(火) 14:22:00OS 開発者としてアドバイスした、って程度じゃないかな。わかんないけど。
DEC 出の気心の知れた同士だったのかもねぇ。
0297名無しさん＠お腹いっぱい。
2005/05/31(火) 14:35:55↓みると、x86_64版のWindowsのために、数年間に渡って
AMDと共同作業をしたってあるよ。
ttp://www.amd.com/us-en/Weblets/0,,7832_8366_7823_8718%5E7839,00.html
別にAMDに移ったわけじゃなくて、Microsoftの仕事として
やってたみたいね。
> DEC 出の気心の知れた同士だったのかもねぇ。
これはあるかもね。
0298名無しさん＠お腹いっぱい。
2005/05/31(火) 17:10:25つまり、差額分はムダづかい、ってことだな。膨大だな。
インテルこけたら原発減らせますキャンペーンってのはどう?
0299名無しさん＠お腹いっぱい。
2005/05/31(火) 18:11:13> として定義されてるし、partial store ordering もオプションで
> OK だからね。
でもSolarisはSPARCをtotal store orderで使っているらしいね。
と、前出てたサンのブログにあった。
http://blog.sun.com/roller/page/eota
難しくてよく分からなかったけれど。
0300名無しさん＠お腹いっぱい。
2005/05/31(火) 18:46:52出来るんなら、PSO にして Niagara でグッと速くなったりすると面白いね。
コンパイラは対応してるのかな?
0301名無しさん＠お腹いっぱい。
2005/05/31(火) 19:27:17PSOやRMOはプロセッサーの機能だから、CPUがサポートしていれば、
プロセッサ単位で切替えられるはず。
理論的には、ソフトが動的に変更できると思うけど、問題はソフトが
そのメモリモデルをサポートしているかどうかだと思う。
Niagaraとかに関係なく、Solarisが本当にTSOだけしかサポートしていない
のなら、CPUをPSOモードにすればSolarisがまともに動かなくなってしまうと
思うけれど。
0302名無しさん＠お腹いっぱい。
2005/05/31(火) 19:30:50> http://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm
>
> つーか、アウトオブオーダなメモリアクセスって、なんですか?
上をみたのだが、CPUのアウトオブオーダなメモリアクセスではなくて、
メモリコントローラのアウトオブオーダなメモリアクセスのことではないの？
だから、NiagaraだとTSOとかPSOとか関係なくて、いつもアウトオブオーダな
メモリアクセスになるんじゃないの？
0303名無しさん＠お腹いっぱい。
2005/05/31(火) 19:31:39適当にバリア命令を入れてあればいいんでしょ?
ライブラリは当然共有できんけど。カーネルの出入りでちゃんと
切り替わってれば大丈夫なんでは?
0304名無しさん＠お腹いっぱい。
2005/05/31(火) 19:41:35だからと言って、CPUからみてTSO(なりPSOなり)を全く
満たさなくなるとまずいよね？
バラバラの順序で返ってきた返事を、トランザクション
IDを使ってTSO(なりPSOなり)を満たす順序に整列し直す
って意味？
0305名無しさん＠お腹いっぱい。
2005/05/31(火) 22:25:45http://www.itmedia.co.jp/enterprise/articles/0505/28/news002.html
・・デルに並ばれた
0306名無しさん＠お腹いっぱい。
2005/05/31(火) 22:42:170307名無しさん＠お腹いっぱい。
2005/06/01(水) 00:02:190308名無しさん＠お腹いっぱい。
2005/06/01(水) 03:52:16例のSC420な。
Solaris入れてるから許してたもれ。
0309名無しさん＠お腹いっぱい。
2005/06/01(水) 11:07:530310名無しさん＠お腹いっぱい。
2005/06/01(水) 14:35:43http://premium.nikkeibp.co.jp/win2000/news/kiji/030417_2.shtml
単にエミュレートが楽だからなのか、
OSサポートについて自分の意見が反映されているのか、
その辺は分からないけど。
0311名無しさん＠お腹いっぱい。
2005/06/01(水) 16:17:28Itanium は HP EPIC だからね。きらいなんでしょ。
ま、Alpha 版 WinNT はあったわけだし、64bit little-endian だからね、
ほとんど手入れる必要はないわな。改善に集中できる。
0312名無しさん＠お腹いっぱい。
2005/06/01(水) 16:19:10> IDを使ってTSO(なりPSOなり)を満たす順序に整列し直す
> って意味？
待ちが生まれても別のthreadで逃げる…ことができるのが
Niagaraだと思いたいのです。
0313名無しさん＠お腹いっぱい。
2005/06/02(木) 00:38:09そういえばAthlonはαバスだったことがあるよね。
あのころからDECの技術が入ってたの？
0314名無しさん＠お腹いっぱい。
2005/06/02(木) 01:11:19今はAMDオリジナルということを盛んに口にしているようだが
0315名無しさん＠お腹いっぱい。
2005/06/02(木) 01:14:590316名無しさん＠お腹いっぱい。
2005/06/02(木) 14:32:19ttp://pcweb.mycom.co.jp/special/2003/opteron/008.html
0317名無しさん＠お腹いっぱい。
2005/06/02(木) 21:08:37http://www.itmedia.co.jp/enterprise/articles/0506/02/news023.html
やっぱ、アンチLinuxのMS-Sun連合が補填するん？
0318名無しさん＠お腹いっぱい。
2005/06/02(木) 21:49:56アンチ linux じゃなくて アンチ redhat だと思われ。
niagara チームは debian を使ってるらしいぞ。
0319名無しさん＠お腹いっぱい。
2005/06/02(木) 22:13:190320名無しさん＠お腹いっぱい。
2005/06/03(金) 02:02:45当時のＡｔｈｌｏｎ用チプセトの400MHzのFSBのことじゃないの？
0321名無しさん＠お腹いっぱい。
2005/06/03(金) 09:17:35http://www.itmedia.co.jp/enterprise/articles/0506/03/news007.html
■ このスレッドは過去ログ倉庫に格納されています