トップページunix
1001コメント336KB

Sun Microsystems 最大の滝壷

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2006/02/01(水) 18:32:00
NOW IN NAIAGARA!
"Rock" on the table?


【前スレ】
Sun Microsystem 最大の遊撃
http://pc8.2ch.net/test/read.cgi/unix/1134031385/
0300名無しさん@お腹いっぱい。2006/02/07(火) 19:51:13
x86サーバーで一番利用されているOSがWindowsなんだから
本気でOpteronサーバーを売ろうとしたらWindowsの保守は当然のこと
0301名無しさん@お腹いっぱい。2006/02/07(火) 19:54:22
>>299
wabiとかSunPCiとか、Windowsアプリケーションを実行するソリューション
はあったけど、確かにWndowsマシンそのもののサポートは初かも。

まあ、Ultra20の前身wのJavaWorkstaiton(JavaStationじゃないよ)が出た
時に既にMicrosoftとの技術提携と合わせてSunが自社製品群の補完と
して「Windowsマシンを投入」したものだと目されてたかと。
0302名無しさん@お腹いっぱい。2006/02/07(火) 19:57:29
>>281
>まぁ少なくともSolarisをクライアント用途で使うのは無意味だな。

もうクライアントはMacOSXでいいよ。
0303名無しさん@お腹いっぱい。2006/02/07(火) 20:15:47
>>281
> まぁ少なくともSolarisをクライアント用途で使うのは無意味だな。

俺は現在もPC-UNIXを使っているから、
勝手アプリもパケージ管理が一元的になれば、
Solarisにしても大局に影響ない。

しかしそれすら叶えられない状況だからやっぱつらいわねえ。
0304名無しさん@お腹いっぱい。2006/02/07(火) 21:20:23
> >Solaris 10を使って仕事を……できなかった
> ttp://pc.watch.impress.co.jp/docs/2006/0207/ws02.htm

でもさ、これ↑って、ほんとに馬鹿な話よ。

だいたい、「Solaris 10を使って仕事を……できなかった」っていってるのは、
Winと動かすアプリが違ってて、同じようには動きませんって話で、アプリが
違うんだから当たり前じゃん。

こんなの同じアプリが動いてたら、問題ない話でさ、Winの上でOpenOfficeを
普段から使ってりゃ問題なかったのよ。日頃から、マルチ・ヘテロな環境で
運用することを意識してりゃ、MSのOfficeなんて使わんわな。

んでもって、Solaris10のインストールを失敗するなんて、素人でもあり得ん。
そんでリセットするつもりで電源をon/off繰り返したんじゃないの?
電源Offしてから間も空けずにOnなどを繰り返していたもんだから、グリッチか
なんかのって、ハードもいかれちまったってなことかぁ。

こいつ、バリバリの文系。ハードのこともソフトのこともナンも知らないで
コンピュータいじってんのね。

そんなやつがコンピュータの記事かくなよなぁ、、て感じだね、こりゃ。
Winの世界は、こんなやつが書く記事でも有り難く読んでんのかね、読者。
素人相手だから、書いているやつが何も分かって無くても問題ないのかな?


0305名無しさん@お腹いっぱい。2006/02/07(火) 21:20:35
>>303
> 俺は現在もPC-UNIXを使っているから、
> 勝手アプリもパケージ管理が一元的になれば、
pkgsrc を地道に充実させるのが一番近道かな、と。Solaris のパッケージ機構もよくできてるけど、
こればっかりは人数多い方が効く。
NFS で共有しといて最初に使った時点でデフォルトセッティングひととおり
やってしまう仕掛けは是非取り込んで欲しいとこ。
0306名無しさん@お腹いっぱい。2006/02/07(火) 21:23:17
>>301
> はあったけど、確かにWndowsマシンそのもののサポートは初かも。
実態は単に業務を外注するだけだろうから、他メーカーで呼んでも同じサポート会社が
来たりするんでしょ。Sun にとっては単にお金の問題だよ。
0307名無しさん@お腹いっぱい。2006/02/07(火) 21:40:07
pkgsrcは、solarisだと満足にコンパイルできないのが多いな。大物は、
どこかどこかでひっかかって手直しが必要なのが面倒。その辺、FreeBSDの
portsはメンテナンスも結構ちゃんとしてる。たまにコンパイルできなく
なる奴もあるが、だいたいすぐ解消される。
0308名無しさん@お腹いっぱい。2006/02/07(火) 21:41:35
あれ? 最近の ports は Solaris でも使えるの?
0309名無しさん@お腹いっぱい。2006/02/07(火) 21:54:30
>>308
使えないよ。
portsは、BSD makeを辞めない限り他OSでの普及は無理だな。
あと、可能性があるのは RPM。Solaris用SRPMが充実して、
rpmbuild --rebuild一発でパッケージが作れるようになるといい。
0310名無しさん@お腹いっぱい。2006/02/07(火) 21:58:03
なんじゃそりゃ。じゃ、ports の機構自体を Solaris に持ってくるってこと? >>307
pkgsrc のひっかかるやつのバグ取りした方がずっと近道だよww
pkgsrc は最初のブートストラップで BSD make 入れちゃうからね。
あと pax や lukem-ftp とかも入る。便利よ。
0311名無しさん@お腹いっぱい。2006/02/07(火) 22:00:23
>>309
RPM はきらい。古いから仕方ないけど。あんまりよく考えてあると思わない。
0312名無しさん@お腹いっぱい。2006/02/07(火) 22:04:29
RPMはSolarisやBSDのパケージ形式より千倍マシだろ。
0313名無しさん@お腹いっぱい。2006/02/07(火) 22:04:38
rpm(srpm): 可もなく不可もなく。依存関係の捌き方が明快で作るのが楽。
deb: ソースを一緒に配るときに不便。結局、Makefileベース。
portage: openbsdのportsチック?
freebsdのports: なんとかしてよ。。。。
0314名無しさん@お腹いっぱい。2006/02/07(火) 22:07:02
>>312
BSD ってかいてあるのは FreeBSD ports と NetBSD pkgsrc として、その 4 つのうち、
RPM は最低だと思うよ、オレは。SuSE のやつの方がいい。
0315名無しさん@お腹いっぱい。2006/02/07(火) 22:13:06
信者キタ━━━━(゚∀゚)━━━━ !!!!!
0316名無しさん@お腹いっぱい。2006/02/07(火) 22:36:29
>>310
どう読んだらそう読めるんだか。FreeBSDのportsのように、
pkgsrcもちゃんとメンテナンスしろってことだよ。pkgsrc自体は
良くできてると思うが、各ソフトのメンテナンスができてないと
使いものにならない。
0317名無しさん@お腹いっぱい。2006/02/07(火) 22:40:12
はあぁ?? NetBSD に対しては十分ちゃんとメンテされてるけど? なにその二重基準。
0318名無しさん@お腹いっぱい。2006/02/07(火) 22:42:26
ports ベースで solaris での動作を目指す(?)のが
なかったっけ? ゾラリスとかそんなん
0319名無しさん@お腹いっぱい。2006/02/07(火) 22:44:19
>>317
> NetBSD に対しては

「NetBSDに対しては」な。で、今はSolaris上でのpkgsrcの話を
しているわけだが。字の読めない馬鹿は消えろよ。
0320名無しさん@お腹いっぱい。2006/02/07(火) 22:44:31
はい、それを指して今では単に pkgsrc。旧 zouralis。
0321名無しさん@お腹いっぱい。2006/02/07(火) 22:44:40
FreeBSDのportsは、全部が一体不可分なのが癌。
ソフト毎に分離して使用できるようにならないと普及は無理。
というか、このままじゃソフトの数が増大して破綻するじゃないか。
あ、もう破綻してるか。
0322名無しさん@お腹いっぱい。2006/02/07(火) 22:45:17
>>319
で、ports は _まったく_ 対応してないんだろ、Solaris に。ダメじゃん。
ほら、一周したぞ。
0323名無しさん@お腹いっぱい。2006/02/07(火) 22:47:39
>>319
比較にならんもんヨコにならべてるバカはおまえ。消えろ。
0324名無しさん@お腹いっぱい。2006/02/07(火) 22:50:54
>>321
バイナリは分離してるし、ソースも要るとこだけあったらそれで使えるんだけどね。
ツリーのうち要るとこだけ取ってくる(自動で cvs update する)仕組みがあればいいのかな。
そんなに難しそうじゃないけど。
0325名無しさん@お腹いっぱい。2006/02/07(火) 23:00:16
>>322
portsがSolarisに対応してるなんて、最初から誰も言ってないだろ。
字が読めない上に頭もおかしいときてるようだな。

>>323
ハア?pkgsrcはSolarisもサポートプラットフォームに入ってるわけだが。
お前はまさに低能の中の低能だなw
0326名無しさん@お腹いっぱい。2006/02/07(火) 23:03:16
2種類の底辺バカがいるようだな。

・字の読めないバカ = >>308 >>310 >>322
・話の流れが追えてないバカ = >>317 >>323
0327名無しさん@お腹いっぱい。2006/02/07(火) 23:10:58
>>325
昔は FreeBSD ユーザーにはおまえみたいなこというバカはいなかったんだがな。
ほんとうんざりするね。
でさ、pkgsrc を Solaris である程度のレベルまで使えるようにできるのは NetBSD の
ユーザーじゃなくて Solaris のユーザーなんだよ、意味わかるか?
「ports の方がデキがいい」ってここに書いてなんの意味がある?
pkgsrc は NetBSD と Solaris 以外でも使えるように考えられてるけど、そいつら全部の
対応状況を NetBSD のユーザーがカバーしきれると思ってんの?
Debian とかでも同じことだと思うがな。
0328名無しさん@お腹いっぱい。2006/02/07(火) 23:18:47
>>327
まぁ、落ち着けよ。
ここであんまり煽り立てるのは止めてくれ。
0329名無しさん@お腹いっぱい。2006/02/07(火) 23:32:42
ports信者は馬鹿が多い。
0330名無しさん@お腹いっぱい。2006/02/07(火) 23:32:50
>>328
胴衣
最大の滝壷ぢゃなくて
最大の痰壷と化してるなw
0331名無しさん@お腹いっぱい。2006/02/07(火) 23:33:35
まともなports使いが可哀想。
0332名無しさん@お腹いっぱい。2006/02/07(火) 23:47:53
>>324
> ツリーのうち要るとこだけ取ってくる(自動で cvs update する)仕組みがあればいいのかな。
参照されたファイルを含むディレクトリが存在しなかったら cvs checkout 呼び出すように
仕掛けられるファイルシステムを作ればいいかな。
0333名無しさん@お腹いっぱい。2006/02/08(水) 00:01:40
send-prもできないチキンの為にpkgsrc専用スレ立てたんだからそっち逝け。
http://pc8.2ch.net/test/read.cgi/unix/1138535932/l50
0334名無しさん@お腹いっぱい。2006/02/08(水) 00:13:24
solarisのパッケージシステム(pkgaddとか)のことかと思ったら、NetBSD由来の
独自ツールなのか
solarisなら、pkgaddでいいじゃん
0335名無しさん@お腹いっぱい。2006/02/08(水) 00:18:08
うん、品揃えさえ充実しそうなら、あれでもいい。
0336名無しさん@お腹いっぱい。2006/02/08(水) 00:50:26
http://news19.2ch.net/test/read.cgi/newsplus/1139304938/

Sunも応援してください。
0337名無しさん@お腹いっぱい。2006/02/08(水) 04:38:40
>>304
そのライターは以前に、
100WオーバーのTDPのCPUをファンレスで動作させて
熱暴走するのはいかがなものか
という記事を書いた前歴がある。
0338名無しさん@お腹いっぱい。2006/02/08(水) 07:34:07
>>334
Solarisのpkgaddだと、出来合いのバイナリのインストール用という
イメージが強く、ソースから自分でpkgadd形式にするという習慣が、
普通のユーザーには定着していない。

OS付属はpkgaddで、ソースからmakeは未だに/usr/local/binに
パッケージ管理なしで入れるというのが、大半のSolarisユーザーの現状。
0339名無しさん@お腹いっぱい。2006/02/08(水) 09:27:18
pkgsrc on Solaris は、もともと pkgsrc に通じていて、Solaris も NetBSD
も Mac OS X も同じように管理しないといけない、というような環境では、非
常に重宝されていると聞きます。リアルの運用で使っている方も多いはずです。

ビルドに失敗するものも少くないですが、基本的なところはかなり抑えられて
いると思いますよ。KDE or GNOME みたいのは少々苦しいと想像しますけど。

(どちらにしろ、「初心者」向けではありません。)
0340名無しさん@お腹いっぱい。2006/02/08(水) 10:14:59
>>334
sunfreeware.comとかNSUGあたりに上がってるソフトは古いのが多い
んだよね。数も少ないしね。
管理者みたいなのはどうでも良いんだよ。ビルドに失敗しようがどう
しようが自分で何とかするだろうからな。デスクトップ用として見た
場合に、現状のSolarisのパッケージシステムで満足行くものが無い
ってこった。
0341名無しさん@お腹いっぱい。2006/02/08(水) 10:29:44
もうRPMにしとけ
0342名無しさん@お腹いっぱい。2006/02/08(水) 11:10:47
>339
* FreeBSD/i386 に特化したような感じでひたすら充実させる > ports
* NetBSD にて複数アーキテクチャ対応を目指す > pkgsrc
* そもそも特定 OS への依存度を下げた汎用パッケージシステム > OpenPackage??? とかその他
それぞれに目的とかがあるんだから仕方ない。

ports の充実度が他所でも使えればそれは便利だけど
ports maintainer の負荷が高くなってしまう。
現状でも末端の一メンテナとしては FreeBSD の各ブランチの
検証もきちんと行えているかというと微妙な人は多いと思われ
(そういう人にも ports メンテナになるよう推奨しているからこそ
数が充実しているわけだ)

ましてやパッケージに凝るようなユーザーの絶対数が少ないであろう
Solaris で他所のパッケージシステムの悪口を言っても始まらないと思う
0343名無しさん@お腹いっぱい。2006/02/08(水) 12:15:24
>>342
誰も ports の文句を言いたい訳じゃないんだから、そろそろ巣に帰ってくれ。
0344名無しさん@お腹いっぱい。2006/02/08(水) 12:39:58
OpenPackageは、かけ声倒れに終って、結局 pkgsrc で
複数アーキテクチャだけでなく複数OSサポートを目指すって
感じになったっぽいよ。
もちろん、一番ちゃんと動くのがNetBSDという状況は変わって
ないと思うけど、DragonflyBSD でも正式パッケージシステムに
なったし、徐々に移植性は向上しているぽい。

ってだけだとスレ違いなので…

実は Sun も pkgsrc のためにハードウェアを寄付しているそうな。
ttp://www.netbsd.org/Foundation/press/sun-donation.html

ftp://ftp.netbsd.org/pub/pkgsrc/packages/SunOS-5.9/sparc/pkgsrc-2005Q2/All/
とかいった場所に、Solaris/sparc 用 pkgsrc バイナリが転がってるんだけど、
これってどれぐらい使われてるのかな。
0345名無しさん@お腹いっぱい。2006/02/08(水) 13:01:34
SunのOpen Solaris戦略は成功するか
http://japan.cnet.com/column/pers/story/0,2000050150,20082670,00.htm
0346名無しさん@お腹いっぱい。2006/02/08(水) 13:40:49
Solaris10のライセンスが400万超えたってね。
0347名無しさん@お腹いっぱい。2006/02/08(水) 14:35:16
ダウンロードしてインストールしたが、あまりに使い物にならないので
即Windowsや外のUNIXに入れ替えられてるんじゃないか?
0348名無しさん@お腹いっぱい。2006/02/08(水) 14:41:38
>>347
おれは違うぞ。
落としたが、インストールするマシンがないだけ…orz
0349名無しさん@お腹いっぱい。2006/02/08(水) 14:50:39
捨てられたライセンスは360万以上。
0350名無しさん@お腹いっぱい。2006/02/08(水) 14:52:36
使われずに捨てられたLinuxのCDROMは一億枚以上だな
0351名無しさん@お腹いっぱい。2006/02/08(水) 14:54:06
>SunのOpen Solaris戦略は成功するか
失敗した。
0352名無しさん@お腹いっぱい。2006/02/08(水) 15:35:46
ま、まだ早いよ。1年は頑張ろうよ
0353名無しさん@お腹いっぱい。2006/02/08(水) 15:41:41
1年でもだめだろ
成果がでるまでに3年はかかるんじゃないか
0354名無しさん@お腹いっぱい。2006/02/08(水) 15:49:40
成果がでるまで生き残れよ、Sun…
0355名無しさん@お腹いっぱい。2006/02/08(水) 15:49:50
おまえらががんばれよ。
0356名無しさん@お腹いっぱい。2006/02/08(水) 16:09:20
対応デバイスがLinuxと比べて少ないからなぁ。
ギ蟹もnevadaじゃないとだめだし。
0357名無しさん@お腹いっぱい。2006/02/08(水) 16:46:30
もうLinuxでええやんか
0358名無しさん@お腹いっぱい。2006/02/08(水) 17:57:59
>>345
議事の前提となってる知識に問題があるね。Java について。まず、ゴスリンやジョイ等古参の
ソフト開発者(研究者)は昔の Unix 周辺の研究者と同様分散システムにずっと興味が
あったこと。JavaSpaces から JAXTA への方面ね。今だと P2P 方面、と言った方が
わかりやすいか。
それと、少なくともジョイは Unix の「C++ の改良版」のような言語での書き直しを
したい、この先はプログラミング言語を軸に進むべき、みたいなことを 1980 年代後半に
言っているということ。
分散システムの基盤として Java を位置づけていることから、Java を手放さないのは、
妙な仕様を入れられたくないのがいちばん底にある理由と思う。
セットトップボックス用の云々... という面白く脚色された小話を 100% 真に受けて
その上に根拠を置いてるのはちょっといただけない。Emacs や NeWS をやった Lisp の
大物があとさき何も考えずに Oak をやってた、と思ったら大間違いと思うね。
0359名無しさん@お腹いっぱい。2006/02/08(水) 19:23:58
でも、Linuxのドライバ対応には感心するよね、確かに。
あれって、Solarisにポートするのって大変なものなの?
0360名無しさん@お腹いっぱい。2006/02/08(水) 19:45:10
Looking Glassはそれなりにオリジナリティを感じたが
Novellのはアレだな
0361名無しさん@お腹いっぱい。2006/02/08(水) 20:57:37
SPARCオワタ
というかUNIX WorkStation自体終わった。
これからはLinuxとMac OS Xの時代。
UNIXの環境はミニコン→WS→PCと変わってきたが、
ここ数年はWSからPCの過渡期だったんだな。
0362名無しさん@お腹いっぱい。2006/02/08(水) 21:12:15
ttp://pc.watch.impress.co.jp/docs/2006/0208/sun.htm
既出?
0363名無しさん@お腹いっぱい。2006/02/08(水) 21:26:04
>>361
Windows一色の時代の間違いだろう。UNIX陣営は腰抜けぞろいだし、
Mac OS Xなんて悪い冗談でしかないな。
0364名無しさん@お腹いっぱい。2006/02/08(水) 22:14:39
「パソコン」てカテゴリーは今後急速に置き去りにされる対象だよ。
末端はソフトウェア的には今よりずっと簡易なものになる。MS-Windows みたいな
応用の効かない OS は不要。あとはヘッドレスな形態の筐体で計算リソースや
メモリリソースをどう配置していくかの問題。「ホームサーバー」とかいうのも
まあそのうちに含んでいいかと。この場合も応用の効かない MS-Windows は不要。
居場所はないね。
0365名無しさん@お腹いっぱい。2006/02/08(水) 22:55:33
>>361
>というかUNIX WorkStation自体終わった。
>これからはLinuxとMac OS Xの時代。

MacOS Xマシンは、実態としてはUNIX Workstationだろう。
0366名無しさん@お腹いっぱい。2006/02/08(水) 22:55:57
>>361
Niagara2 はデスクトップ機に応用してメリット大と思われる。
科技ファームの構成要素にも有用と思われる。これから先はいわゆる RISC が有利。
0367名無しさん@お腹いっぱい。2006/02/08(水) 23:26:30
デスクトップには向かんよ。
シングルスレッド性能が重要だから。
0368名無しさん@お腹いっぱい。2006/02/08(水) 23:31:09
マルチスレッドにしたら効きそうなアプリはごろごろあるよ。マルチメディア方面特にね。
ワープロも効くんじゃね? Web ブラウザーも効くんじゃね?
逆に、シングルスレッドの性能差がすごく効くアプリって少ないと思うけど。
通常用途じゃ。
0369名無しさん@お腹いっぱい。2006/02/08(水) 23:34:06
> マルチスレッドにしたら効きそうなアプリはごろごろあるよ。
> マルチメディア方面特にね。

エンコーダ/デコーダは確かに、わりとマルチスレッド向きだね。

> ワープロも効くんじゃね? Web ブラウザーも効くんじゃね?

これは全然向かん。
top で見れば分かるけど、瞬間的にCPU能力を必要とするだけなので、
シングルスレッド性能が重要。

> 逆に、シングルスレッドの性能差がすごく効くアプリって少ないと思うけど。

甘い。
0370名無しさん@お腹いっぱい。2006/02/08(水) 23:35:23
>>344
僕はいわゆるホビーユーザーで初心者なので勘違いも甚だしいかもしれないけど、
pkgsrcをダウンロードしたらでかいし、./bootstrapしたらいきなりコンパイルして勝手にインストール始めたから
キモくて即刻消した。
BSD使ったこと無くて、solarisのパッケージみたいなのを想像していたからびっくりした。
BSDのユーザーさんって、あんな勝手にダウンロードしてコンパイルするシステム気持ち悪く無いのかな?
その後、必要だったdvdrecordのコンパイルに成功したから、もうどうでもよくなった。
やっぱりmakeして自分の好きな所にインストールするのが一番だと思ったよ。
0371名無しさん@お腹いっぱい。2006/02/08(水) 23:38:34
Solarisしか動かんデスクトップマシンなんて考えただけでも使い難そうだな。
Window$で充分だよ。
痰壷は鯖だけでいいよ。
0372名無しさん@お腹いっぱい。2006/02/08(水) 23:40:41
>>370
基本的には、/usr/pkg/ 下にしか入らないよ。一部例外はあるけど。
pkg_info -L <パッケージ名> で入ったファイルの一覧が出る。
それと、bootstrap 終わったら、後のは一般ユーザーでやる。bmake install で
コンパイル後、実際のインストール直前に root パスワード聞かれる(su が走る)。
...って、事前情報ないと確かにキモいかも。書いてなかった?
0373名無しさん@お腹いっぱい。2006/02/08(水) 23:44:57
>>370
> あんな勝手にダウンロードしてコンパイルするシステム気持ち悪く無いのかな?
元になった FreeBSD の ports の発想からしてそうなんだけど、手作業で落としてきて
(必要ならパッチ当てて、)コンパイル、導入するのを自動化しただけのものなんだけどね。
多少知識が付けばそれぞれの作業を別々にも実行できるよ。
0374名無しさん@お腹いっぱい。2006/02/08(水) 23:45:01
>>369
だからヘテロジーニアスマルチコアっていうものが考えられているんだよね。
AMDに期待かなぁ...
0375名無しさん@お腹いっぱい。2006/02/09(木) 00:03:56
>>369
> top で見れば分かるけど、瞬間的にCPU能力を必要とするだけなので、
それは今のプログラムがそいういう風に書いてあるからだと思うけどなぁ。

>> 逆に、シングルスレッドの性能差がすごく効くアプリって少ないと思うけど。
> 甘い。
実際に、オフィスワークや一般の人が家庭で使ってる用途で、Pen4 の 3.6GHz なら
快適だけど 1.8GHz だと不便で使う気もしない、なんてもんはあんまり無いと思うけど。
0376名無しさん@お腹いっぱい。2006/02/09(木) 00:04:38
>>372さん
親切な回答ありがとうございます。
でも、ほんとにビックリしました。
得体の知れない物とか入ってきたらどうするんだろう・・・・
自分は勝手にダウンロード&インストールするのはもうpprosvcで十分です。
0377名無しさん@お腹いっぱい。2006/02/09(木) 00:20:12
>>375
もしお前の思うとおりなら
世の中、ナイアガラもどきのマルチコアが
あふれているんだがな
0378名無しさん@お腹いっぱい。2006/02/09(木) 00:21:50
>>376
んー、一応、各パッケージのディレクトリ下の distinfo にチェックサムがあって
すり替えのチェックはしてますけどね。一致しないと止まります。
自分で取ってきたい場合は、そうですねぇ、例えば FETCH_CMD=/usr/bin/false とか
/etc/mk.conf に書いておくとファイル取得にコケますから、エラー表示を見て
自分で取ってくる、という方法はあります。
慣れますけどねぇ。楽だからw
mk.conf については pkgsrc/mk/defaults/mk.conf 参照してください。
0379名無しさん@お腹いっぱい。2006/02/09(木) 00:23:19
>>377
ふっ、もうすぐそうなるさ。
それまでに Sun がどれぐらい稼げるのか、がとりあえずポイントだな。
0380名無しさん@お腹いっぱい。2006/02/09(木) 00:49:51
make fetch-list を実行すると、ダウンロードするスクリプトを
吐いてくれるから、それを実行しておいてまずダウンロードして、
中身を確認して、それから make するって手もあるけどね。

でも、distinfo の SHA1/RMD160 検査で、まあ十分だと思うけどなあ。
0381名無しさん@お腹いっぱい。2006/02/09(木) 00:53:16
>>379
シングルコアの性能もそこそこいいマルチコアCPUじゃないとね。
Niagaraをシングルスレッドで使うと笑っちゃうよね。
0382名無しさん@お腹いっぱい。2006/02/09(木) 01:00:33
>375 って天然物?
0383名無しさん@お腹いっぱい。2006/02/09(木) 01:01:03
まあ今の Niagara だとそのままは難しいかもね。Niagara2 には期待。
ところで、コアあたりのスレッド数可変にしたりするのは難しいかな?
0384名無しさん@お腹いっぱい。2006/02/09(木) 01:04:32
そのうちインテルのマルチコアでいっぱいになります。
0385名無しさん@お腹いっぱい。2006/02/09(木) 01:05:35
>>383
>コアあたりのスレッド数可変

縮退で良いなら今でも可。単にスレッド殺すだけだけど、その分パイプラインは空くよ。
0386名無しさん@お腹いっぱい。2006/02/09(木) 01:10:06
>>384
ずっと繰り返し繰り返し出てるんだけど... インテルじゃ有効利用できる OS がないよ。
つまり作ってもムダ。ざんね〜ん。
0387名無しさん@お腹いっぱい。2006/02/09(木) 01:12:06
>>385
つまりそれは、FGMT 的に 300MHz 4Threads が 600MHz 2Threads になったりする、と
いうこと?
0388名無しさん@お腹いっぱい。2006/02/09(木) 01:12:15
OS は Solaris/x86 でいいじゃん。
それより、Niagara くらいシンプルなコアだと、x86→内部RISC変換に
必要なトランジスタが馬鹿にならんことの方が問題だと思われ。
0389名無しさん@お腹いっぱい。2006/02/09(木) 01:28:41
Intel CPUのみもしくは自社x86機以外で多コア使う場合有料の
アクティベーションが必須になったりしてw
まぁOSそのものの普及を考えた場合は無制限にライセンス出した方がいいでしょうが
H/Wの売上とOS保守契約等々のサービス売上のバランスでどの程度
Sunが耐えられるかの方が問題かも
ただSunは全てのSunのソフトウェアはOSSにするって言ってるから
Solaris/SPARCに全てを賭けるという意気込みなんだろうなぁ
0390名無しさん@お腹いっぱい。2006/02/09(木) 01:29:51
>>387
そのはず。明示的にオフラインにしなくても、LWP 数が少なければパイプラインに
空きが生じる訳だし、スレッド数を減らすメリットは無いと思うけどね。
0391名無しさん@お腹いっぱい。2006/02/09(木) 01:38:53
>>390
ふーん... それなら、別に「シングルスレッドだと笑うほど遅い」ってこともないんじゃないの?
300MHz 相当になるのかと思ってたよ。
0392名無しさん@お腹いっぱい。2006/02/09(木) 01:45:39
1.2GHz と言っても、OoO どころかスーパースカラーもないから、
Pentium-M 1.2GHz とかと比べると、かなり遅いと思うよ。
0393名無しさん@お腹いっぱい。2006/02/09(木) 01:49:16
>>391
設計上の選択で、パイプライン自体が短いし、演算ユニットもコア毎に一個だから。
その分、マルチスレッドだと超っ速だよ。電気喰わないし、熱も出ないし、サーバには最適。
0394名無しさん@お腹いっぱい。2006/02/09(木) 02:01:42
いいねぇ。マルチメディアエンコードやゲームとコンパイルにしか性能の出ない
非効率巨大 CPU を一般用計算機に強要するメーカーとはぜんぜん違うねぇ。
大鑑巨砲主義はひっこめてもらいたいもんだ、ほんと。
0395名無しさん@お腹いっぱい。2006/02/09(木) 02:06:26
Intel は SMT で突っ走ると思ってたんだけどな。その為に DEC から特許を取得したらしいのに、
結局引っ込めちゃったね。
0396名無しさん@お腹いっぱい。2006/02/09(木) 02:17:50
メモリレイテンシ問題は今後も悪化する一方だから、
SMT復活の目はあるんじゃないかと思ってるけどね。
Niagaraみたいなのだと、FGMTで十分だけど、OoOの
CPUではSMTにするのが自然だし。

そこで疑問なんだけど、なんでOlympusはOoOなのに
CGMTなんだろうね。SMTを設計するのが面倒だったん
かな。
0397名無しさん@お腹いっぱい。2006/02/09(木) 03:15:52
業界的に SMT を採用しない/出来ない理由があるのなら俺も知りたいな。
0398名無しさん@お腹いっぱい。2006/02/09(木) 04:30:52
よく知らんけど、POWER5あたりは、SMTだと聞いたことがあるので、
別に業界的に採用しないとかできないとかいうことはなかろう。
0399名無しさん@お腹いっぱい。2006/02/09(木) 04:33:24
あー、でも富士通が採用しなかったのはIntelあたりがDECから
買って持ってる特許を避けたかったから…って可能性はあるかな。

富士通とIntelって、包括的クロスライセンス契約とか結んで
ないんだっけ。
■ このスレッドは過去ログ倉庫に格納されています