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

Sun Microsystems 最大の敵はItanium

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2006/02/26(日) 01:49:21
まだまだ続く、痛厨との攻防

【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0231名無しさん＠お腹いっぱい。2006/03/26(日) 17:04:40
>>230
そりゃこのスレ的には『HP-UXを使ってるユーザなんて無視』でもいいけど
現実にはどうしても痛を使いたいユーザのほどんどはHP-UXだろ
WindowsとかLinuxを使っているならx64に移れば桶だし
本当にエンタープライズシステムクォリティが必要なら
POWERに移ればいいのだから
だから痛を日本のメーカーがコントロールするようになっちゃうと
HPが黙っていないだろ
0232名無しさん＠お腹いっぱい。2006/03/26(日) 18:20:01
> 現実にはどうしても痛を使いたいユーザのほどんどはHP-UXだろ

これだけで、Itaniumの数は伸びない...って感じがする。
HP-UXでも、PAからItaniumに移行しないで、IBM, Sunに移行していく
ユーザっていそうだし。PAユーザってまだ相当いそうだし。

HPがPAを止めたのは完全に失敗だったね。
0233名無しさん＠お腹いっぱい。2006/03/26(日) 21:13:42
ITバブルがはじけずにサーバーの出荷台数や出荷額の増加が続いていれば移行には成功したんだろうね
Itaniumは技術的にもマーケティング的にもどう考えてもすべて90年代の発想です
0234名無しさん＠お腹いっぱい。2006/03/26(日) 21:15:38
>>232
hpは何やってもダメでしょ。必要ない。
0235名無しさん＠お腹いっぱい。2006/03/26(日) 21:25:01
Sparkはいつもネタ切れだな。
0236名無しさん＠お腹いっぱい。2006/03/26(日) 21:32:29
HPってIntelにもAMDにも良い顔してて最終的にどっちからも蹴落とされるタイプ。
0237名無しさん＠お腹いっぱい。2006/03/26(日) 21:42:07
AlphaとPAとx86で頑張れば良かったのに。
0238名無しさん＠お腹いっぱい。2006/03/26(日) 21:47:12
PAとHP-UXは捨ててAlphaとTru64 Unix残せば良かったのに。
0239名無しさん＠お腹いっぱい。2006/03/26(日) 21:48:22
Alphaは合併前にCompaqが技術者とコンパイラごとIntelに
売り払っちまったんでないの？
0240名無しさん＠お腹いっぱい。2006/03/26(日) 21:57:14
>>239

Alphaの技術はXeonの方にいっちゃったけど、CPUを使ったホストは
CompaqからHPへ。で、マシンが残っている以上、サポートしないといけないし。

そうなると、HPって、いつまでもAlphaとPA, VAXをサポートしていくのね。
Itaniumへの移行をすすめつつ。まぁ途中でサポートを切るんだろうけど、
今の感じだと、Itaniumへ移行すると、今度はItaniumのサポートが早々
うち切られそうな状況なので、Itaniumを使ったホストへの移行が進みそうにないね。

0241名無しさん＠お腹いっぱい。2006/03/26(日) 22:05:16
Sparkのネタは無いけど、
http://www.asahi.com/politics/update/0326/004.html

> 総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。
>
> しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によってバージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。

確かにありがち！
0242名無しさん＠お腹いっぱい。2006/03/26(日) 22:11:45
> 総務省によると、文部科学省以外の電子申請には...

この、「文部科学省以外の電子申請には...」って何？
全省庁、Javaで統一しろよ。そういうことしてるから、税金が無駄に使われる。
文部科学省も、Javaを使えよ。
0243名無しさん＠お腹いっぱい。2006/03/26(日) 22:15:03
> しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によってバージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。

これって、具体的にどういうこと？

新版で動く ==> 旧版で動かない　っていうのは、アプリが新版で導入された新しい
インタフェース、関数を使っていて、旧版ではその呼び出しができないっていう
ことかなって思うけど、

旧版で動く ==> 新版で動かない　っていうのは、どういう場合？
アプリが新版で廃止になるdeprecateな関数呼び出しを使っているってこと？
（つまりバグ？）

0244名無しさん＠お腹いっぱい。2006/03/26(日) 22:32:24
> 旧版で動く ==> 新版で動かない　っていうのは、どういう場合？


確かに基本的にはあり得そうもないが...
0245名無しさん＠お腹いっぱい。2006/03/26(日) 22:35:02
>>243
オレの経験上では、旧版でセキュリティ的にめちゃくちゃなことやってて、
新版では手動で JVM の設定緩めないと動かなくなって、全クライアント（Web ブラウザ）機で
そんなことやってらんない、ってやつ。JRE のせいにするか普通? って思うけど。
0246名無しさん＠お腹いっぱい。2006/03/26(日) 22:47:46
>>245

そういうのは、アプリの問題で、全然Javaの問題じゃないよね。

そもそも、コーディングの仕方を知らないって言うレベルで、発注先を変えた方が
いいかも。
0247名無しさん＠お腹いっぱい。2006/03/26(日) 22:53:14
でもさ、>>245 はごく大手の、自治体向けのパッケージの話よ。都道府県向けだけどね。
全国あちこちで導入されてる。
0248名無しさん＠お腹いっぱい。2006/03/26(日) 22:55:10
>>247

官庁関係の開発って、孫外注、曾孫外注の開発で、最後は相当スキルの低いとこが
コーディングしてる例って結構あるよ。

0249名無しさん＠お腹いっぱい。2006/03/26(日) 22:57:13
Javaの場合、ネット経由で起動した時にどの位のパフォーマンスがあるかを
調べると、開発元のスキルがみえてくるよ。

スキルがないとこが開発すると、遅いのですぐ分かる。
0250名無しさん＠お腹いっぱい。2006/03/26(日) 23:04:01
>>248
うーん、でも、末端のコーディングとかの問題じゃなくて、アプレットのレイアウトとか
アプリ構成の大枠の話だったりするし、内製だったと思うけど。メンテでその大手企業の
社員さんが来てたから。
スキルとかいうより、セキュリティ感覚というか、文化というか、そういう問題と
思った。その件に関しては。
でも、外ヅラ的には客には Java の互換性問題に見えるし、その大手企業も Java のせいに
してたし、適用やってた作業者も Java に文句たれてたよ。ひどい話だけど。
0251名無しさん＠お腹いっぱい。2006/03/26(日) 23:16:43
> でも、外ヅラ的には客には Java の互換性問題に見えるし、その大手企業も Java のせいにしてたし、適用やってた作業者も Java に文句たれてたよ。ひどい話だけど。

JavaはObj指向のデザイン、コーディングが必要な上に、セキュリティモデルを最初から
設計に入れて、仕様を決めていく必要がある。その上、ネットで展開する場合は、
パフォーマンスを考慮して、詳細仕様を詰めていく必要があるので、それなりの
スキルがないと、ちゃんとしたアプリは開発できないと思うよ。

上の話をみると、請け負った大手コンピュータ？会社側にJavaでアプリを開発する
スキルがなかったということだと思う。

日本でちゃんとJavaでアプリを組めるとこって、まだあんまりないのかもね。
Javaが出てきて10年以上たつのに、何のスキルもつけてこなかったってこと？

海外じゃ、相当量の開発が行われているのに。source forgeでは、C++のプロジェクト
数をJavaが抜いたらしいし。
0252名無しさん＠お腹いっぱい。2006/03/26(日) 23:40:33
電子申請に必要なJavaアプレットなりJavaアプリケーションはそんなに複雑なプログラムでもないだろ
単純にSwingのプログラミング方法をしらないだけじゃない？
確かに、日本語の書籍を見てもSwingの解説を丁寧にしてるJavaの書籍はここ2年くらい前以降に出た
比較的新しい本ばかりだし種類も少ないし情報不足というのもあるんじゃない？
スキルの無い開発者なんて市販の日本語のJavaの書籍で勉強してそうだからな
0253名無しさん＠お腹いっぱい。2006/03/27(月) 00:24:50
Itaniumは、いつまで引っ張るのかな。

クロックを上げることよりも、スレッド数を上げることよりも、
IPC向上を至上命題にしたアーキテクチャは、開発当時は正しくても、今は正しくないよね。
0254名無しさん＠お腹いっぱい。2006/03/27(月) 00:46:01
よく知らないが、バージョン間の細かい仕様の違いがあるんジャマイカ。
Write once debug anywhere と言われていた時もある品。
0255名無しさん＠お腹いっぱい。2006/03/27(月) 10:43:03
>>253
NetBurstはどうなった？
バブル時代の体育会系の営業みたいで大嫌いなんだが。
0256名無しさん＠お腹いっぱい。2006/03/28(火) 09:45:48
>>51
NetBSDはバイナリー互換性を維持するために頑張ってるんだから、オプソOSと
一括りにしないでくれないかな。
0257名無しさん＠お腹いっぱい。2006/03/28(火) 12:54:51
> NetBSDはバイナリー互換性を維持するために頑張ってるんだから
ハハハ
居たの？って感じｗ＞NetBSD
0258名無しさん＠お腹いっぱい。2006/03/28(火) 13:15:15
>>257

NetBSDもいいじゃんか、別に。Unixなんだし。
OpenSolaris, Linux, {Open,Net,Free}BSDは、似たりよったり。
皆基本的に無料だし。

組み込みにも使われるNetBSDは、Niagaraへのポートもしやすいだろうね。
Linuxのポートができたので、次はNetBSD/OpenBSD/FreeBSDの番だね。

Windowsは無視。
0259名無しさん＠お腹いっぱい。2006/03/28(火) 23:41:58
> OpenSolaris, Linux, {Open,Net,Free}BSDは、似たりよったり。

各OSの支持者が一斉に文句を言い始めそうなことを
さらりと言ってのけましたなあ…
0260名無しさん＠お腹いっぱい。2006/03/29(水) 00:27:42
>>258
Niagaraは、その能力を十二分に使い切れてこそ意味がある。
でなければ、その辺の糞CPUにも劣る。

NetBSDなどは、ただ単に動きますというレベルには比較的容易に
もっていけるのかもしれないが、自己満足以外の何でもない。
0261名無しさん＠お腹いっぱい。2006/03/29(水) 15:55:42
>>260
それを言ったらフリーOSはほとんど自己満足だな。OpenSolarisがその出自か
らかろうじて違うくらいか。ところでOpenSolarisってNiagaraに対応済なの?
0262名無しさん＠お腹いっぱい。2006/03/29(水) 16:31:13
IBMやらHPやらSGIやらIntelやらは自己満足ってわけでもないでしょ。
ソフトウェアベンダも含めてLinuxは結構な商売道具になってる。

このスレに沿った話をすれば、Itanium機の多くはLinuxでしょ。HP-UXや
OpenVMSをItaniumで、ってところは少なそう。
0263名無しさん＠お腹いっぱい。2006/03/29(水) 23:44:44
>>262
このスレに沿えば、ItaniumではHP-UXが殆どなのだが…
実績に乏しいLinux IA64を使うリスクを冒す企業はごく僅かだろう。

唯一の例外がHPC。極めて限定的な用途。
0264名無しさん＠お腹いっぱい。2006/03/30(木) 05:06:45
ItaniumはPA-RISCの置き換え用なんだから、HP-UXだろうに。
0265名無しさん＠お腹いっぱい。2006/03/30(木) 07:30:50
> らかろうじて違うくらいか。ところでOpenSolarisってNiagaraに対応済なの?

最初から対応済みでしょ。
0266名無しさん＠お腹いっぱい。2006/03/30(木) 07:34:35
Itaniumはやっぱり商業OSでないと意味ないっしょ？
高いんだし。

でも、HPCになると、今度はCPUがない日本のメーカーがItaniumを採用して
（墓穴を掘った？）、OSがないもんだからLinuxなんだよね。

Linuxの版数があがると、追従するのが大変だよ、きっと。
ドライバの互換問題もでてくるだろうし。

アプリはさほど問題じゃないよね。

OpenSolaris + Debianの環境で、Linux + Debianのアプリ、ライブラリが動くもの。
アプリにとってはカーネルと言うより、ライブラリやコマンドといった取り巻きの
環境の方の影響が大きいから。
0267名無しさん＠お腹いっぱい。2006/03/30(木) 14:31:26
>>260
確かに NetBSD はジャイアントロックでの SMP 対応だから Niagara で上がるように
しただけでは CPU バウンドな仕事除いて Niagara の真価を発揮することはできない。
けど、SMP 実装迷宮入りしてしまった Linux なんぞに比べたらこの先の進展は
不用意な実装を避けてきている NetBSD の方が有利な可能性はあるよ。
0268名無しさん＠お腹いっぱい。2006/03/30(木) 15:14:05
>>266
> アプリはさほど問題じゃないよね。
>
> OpenSolaris + Debianの環境で、Linux + Debianのアプリ、ライブラリが動くもの。

それこそベンダのサポートがあるかないかが重要なんじゃないの？
例えばFreeBSDでOracleが動くといっても、積極的にそんなことする
ところがあるかなあ。
0269名無しさん＠お腹いっぱい。2006/03/30(木) 15:46:40
>>268

そうね。

考えてみると、libcの版数が変わっただけでも、昔は大変なことに
なってたものね。Linuxでは、互換性の維持がたしかに大変かも。

そうなると、Itaniumでは、HP-UXぐらいしかないのね。
SolarisがItaniumに移植されていたら、Itaniumも助かっただろうにね。

でも、この頃Itaniumって、ますます存在感が薄くなっている気がするのだけれど。
Intel社内でも、存在感がなくなってない？
0270名無しさん＠お腹いっぱい。2006/03/30(木) 16:15:52
Intel は今 x86 で崖っぷちだよ。ロードマップも焼き直しチップの組み合わせで
実態が見えないようにしてあるごまかしもの。今が創業以来最悪の状態なんじゃない?
Pen-M ベースの 64bit チップが AMD の次の一手に間に合わなかったら、Intel 終わるんじゃ
ないかなぁ。
メインストリームはずれるのが確定した Itanium なんかにかまってるヒマはまったくないはず。
0271名無しさん＠お腹いっぱい。2006/03/30(木) 16:35:25
いまはそうなると、Intel最後の焼き直し、とかIntel最大の賭、の時なのね。
そして、いよいよ、Intelおわってる、の時がくるのね。。
0272名無しさん＠お腹いっぱい。2006/03/30(木) 16:49:27
たしかに、UltraSPARC-T1より遅いIntel Xeonが分かった今、Intelは終わった。
0273名無しさん＠お腹いっぱい。2006/03/30(木) 18:22:17
リソースの整理をはじめたか?

AMD、インテルの「Itanium」設計者を引き抜き
ttp://japan.zdnet.com/news/hardware/story/0,2000052523,20099773,00.htm

AMD の目的が何かも気になるね。ポスト amd64 か?
0274名無しさん＠お腹いっぱい。2006/03/30(木) 18:33:33
OpteronにRAS機能を持たせよう、ってことだろうなぁ。
0275名無しさん＠お腹いっぱい。2006/03/30(木) 18:48:20
なんじゃそりゃ。そりゃ希望か?
0276名無しさん＠お腹いっぱい。2006/03/30(木) 19:52:31
Itaniumを10年近くも陣頭指揮していた中心人物がAMDに移るっていうのは、もう
IntelはItaniumへの興味を失っていて、Itaniumは実質死んでいるということじゃない。

これは後数年でItaniumは消えるね。

0277名無しさん＠お腹いっぱい。2006/03/30(木) 19:56:09
> AMD の目的が何かも気になるね。ポスト amd64 か?

Itaniumを消滅させて、X86系の64bitはX64アーキで決まりにするためだろ？

0278名無しさん＠お腹いっぱい。2006/03/30(木) 21:58:08
Itanium互換チップを作るのかもよｗ
0279名無しさん＠お腹いっぱい。2006/03/30(木) 22:23:04
決まってるだろ、amd64 の寿命が尽きたら PA-RISC に乗り換えるためだ。
0280名無しさん＠お腹いっぱい。2006/03/30(木) 22:53:29
やっぱり、Sun Microsystems 最大の敵はPA-RISC だったか...
0281名無しさん＠お腹いっぱい。2006/03/30(木) 23:13:51
AMD厨は痛い
0282名無しさん＠お腹いっぱい。2006/03/30(木) 23:46:00
これで VLIW は汎用品としては完全にケチがついたな。
0283名無しさん＠お腹いっぱい。2006/03/30(木) 23:51:55
Efficeon! Efficeon!
0284名無しさん＠お腹いっぱい。2006/03/31(金) 00:10:34
HPはOSの10年サポート宣言してる。11i ver1からかな？
PA-RISCを１０年はサポートするつもりなのかしら？
もうすぐver2のエンハンスでccNUMAやらPCI hotplugがサポートされて
エンタープライズ向け機能が出揃う。
Linux/ia64より台数多いが、Windows2003/ia64より少なめの売れ行き。
0285名無しさん＠お腹いっぱい。2006/03/31(金) 00:14:45
Efficeon は内部実装に VLIW を採用してるだけで、有望なスポンサーがつく等の
状況次第でまだ可能性あるんじゃないかなぁ。
どっかと違って、金とリソース注ぎ込みまくったのにダメだった訳じゃないから。
ただ、VLIW というキーワードはもう宣伝材料にはならんかもね。
0286名無しさん＠お腹いっぱい。2006/03/31(金) 00:17:45
>>267
確かに、NetBSDの方針は耳への聞こえが良く
誰もが理想とするところだとは思うが、タイムリーに
実装を行っていくにはリソースが足りないのが残念。

話がそれてしまうが、
「SMP実装迷宮入りしてしまった」のはFreeBSDの方では？
6.0が出て期待できるかと思ったが、結局もたついている。
Linuxも、現状以上のスケーラビリティとなると、
壁にぶち当たるのかもしれないけど。
0287名無しさん＠お腹いっぱい。2006/03/31(金) 01:22:31
SMP に関しては、「みんなで仲良く」やれるもんではない。だからリソースの問題ではない。
気合い入った人間がいるかどうか、あと、ジャマするやつがいないかどうか。
Minix が進展してきてるようだから、ひょっとするとダシ抜いたりしたりして。
「ジャマされる」要因を排除するという意味では、マイクロカーネルで切り分けられてる方が
有利と思うし。
0288名無しさん＠お腹いっぱい。2006/03/31(金) 05:55:37
いよいよGNU/Hurdの時代か！
0289名無しさん＠お腹いっぱい。2006/03/31(金) 08:45:34
SPARC版のWindowsを出してもらえばいいんだろうけどね
0290名無しさん＠お腹いっぱい。2006/03/31(金) 10:12:00
無理だよ。Alpha 版も MIPS 版も維持すらできなかったのに。
エンディアンにも構造体のパディングにもベタベタに依存してたの今は直ったのか?
0291名無しさん＠お腹いっぱい。2006/03/31(金) 11:02:14
パディングは64bit版の登場で少し改善されたんじゃないのかな。
いずれにせよ、インターフェースとして固定するしかないわけだけど。
0292名無しさん＠お腹いっぱい。2006/03/31(金) 11:03:49
ItaniumチームがゴッソリAMDに移動ってことなら、
AMD64の延長じゃなくて、その次のアーキテクチャなのかな?
AMD64の延長だとちょっとプロジェクトとして魅力低そうだから…
0293名無しさん＠お腹いっぱい。2006/03/31(金) 11:54:07
efficionはVLIWかどうかではなくて、コードモーフィングが売りじゃないの？

FR-Vはどうなった?
0294名無しさん＠お腹いっぱい。2006/03/31(金) 14:33:06
地味に売れてるらしい
画像処理系とか
0295名無しさん＠お腹いっぱい。2006/03/31(金) 14:34:25
FR-Vって富士通のマイコンだっけ？
富士通から、このチップを使った超並列機が出てたんだけど、
育てればBlue Geneまでといかないものの
成功したのでは？と思う

で、トランスメタのCPUが失敗した要員は性能だろう
CRUSOE機もってたけど、苦行に感じるくらい遅かった
0296名無しさん＠お腹いっぱい。2006/03/31(金) 14:45:09
で、悟りが開ける前に諦めてしまったのですね
0297名無しさん＠お腹いっぱい。2006/03/31(金) 15:06:05
ナームー
0298名無しさん＠お腹いっぱい。2006/03/31(金) 15:06:35
>>295
Crusoe、変換結果をdiskにcacheしたらどうだったろうなあ。
0299名無しさん＠お腹いっぱい。2006/03/31(金) 16:16:43
> AMD64の延長だとちょっとプロジェクトとして魅力低そうだから…

AMD64の延長でいいんじゃない？　64bitとしては、Itaniumよりきれい。
（というか、Itainumが汚すぎ）

正直言って、あの汚いX86がItaniumにいくと別な意味でややこしいなと
思っていたので、それをきれいにまとめたAMD64の64bitアーキがでてきて
嬉しかった。
0300名無しさん＠お腹いっぱい。2006/03/31(金) 17:24:15
俺もIA64よりはAMD64の方が良いと思うが、IA64の方が「汚い」というのが
良くわからない。何をもって「汚い」って言ってるの？
0301名無しさん＠お腹いっぱい。2006/03/31(金) 17:51:01
お金
0302名無しさん＠お腹いっぱい。2006/03/31(金) 17:52:42
>>300
パターンだよ
0303名無しさん＠お腹いっぱい。2006/03/31(金) 18:26:27
> 俺もIA64よりはAMD64の方が良いと思うが、IA64の方が「汚い」というのが
> 良くわからない。何をもって「汚い」って言ってるの？

あの巨大で複雑な仕様と、サフィックスをつけまくるアセンブラが嫌い。
最初に仕様をみたエンジニアは、まずため息をつくと思う。

それを比較すると、AMD64は美しいって思う。
0304名無しさん＠お腹いっぱい。2006/03/31(金) 18:57:47
ヒント：慣れ
0305名無しさん＠お腹いっぱい。2006/03/31(金) 19:04:33
あれに慣れるっていうのは、凄いというか、諦めの心境に達したというのか...

仕様をみればみるほど、alphaやらpaやらx86やらvaxやらmipsやらをサポートするために
混ぜこぜにしたあげく、Unixサーバー, Hirayama, VAX向けのRASを加え、最後にVLIWの
味付けをしったって感じで目まいがするアーキ。単独プラットフォームで、あの全仕様
を使うものってあるのだろうか？
0306名無しさん＠お腹いっぱい。2006/03/31(金) 19:28:25
SPARCの話題まだぁぁ？

03072922006/03/31(金) 19:50:43
>>299
いや、AMD64自体はいいと思うんだけど、
既にAMDにはそれぞれのチームが居るわけだよね。
そういうところに1+8人のチームが乗り込むわけだから、
何か新しいプロジェクト立ち上げると思うんだよね。

AMD64の新しい系列であっても、
何か新しい基軸がないとこれだけの人間が一斉に移籍することないと思う。
チャレンジングなテーマだと思ったから行くんじゃないのかな。
それはたとえばマルチコアのコア増大程度じゃないと思うんだけど。
0308名無しさん＠お腹いっぱい。2006/03/31(金) 19:53:24
>>305
ふーん、そうなんだ
こりゃItaniumの普及は絶対に阻止せねばならんね
0309名無しさん＠お腹いっぱい。2006/03/31(金) 20:15:08
お前らオタクかよ。

アセンブラでコーディングする香具師なんてOS屋のなかでも、ごく一部のコードを書く連中だけだ。
アセンブラを意識するのは、原始的なデバッガを使っている人間だろう。
時代遅れの老害どもめ。

C言語で書いたプログラムが速く走ればそれでいいんだよ。




















速く走らないItaniumは糞。
0310名無しさん＠お腹いっぱい。2006/03/31(金) 21:03:06
わーい、わーい
Itaniumは糞！Itaniumは糞！
0311名無しさん＠お腹いっぱい。2006/03/31(金) 21:42:08
相手に編む祭り
0312名無しさん＠お腹いっぱい。2006/03/32(土) 02:07:32
>>305
全仕様を同時に使うことは無い。冗長にできている。
Windowsとhp-uxの両方を素直に載せるにはx86とPA-RISCの両方を混ぜるしかなかった。
同じことするのに86方式でもPA-RISC方式でも出来て冗長なのはあえてそうしてる。
あとはその他のいいとこ取りで収拾つかず。ｗ
0313名無しさん＠お腹いっぱい。2006/03/32(土) 09:47:24
>>303
アセンブラを挙げる時点で、Itanium を分かってない
Itaniumはハードで頑張る代わりにコンパイラで頑張るというコンセプトなんだから
0314名無しさん＠お腹いっぱい。2006/03/32(土) 10:22:17
>>313
お前はもっと分かってないようだな。
0315名無しさん＠お腹いっぱい。2006/03/32(土) 11:49:35
コンパイラ支援でハードも頑張るのがEPICだろうが。
0316名無しさん＠お腹いっぱい。2006/03/32(土) 15:20:31
>>312
なんか、RISC の思想をつきつめた先の単純構造小トランジスタ数という VLIW の
見本みたいなんじゃなくて、旧来のシガラミでがんじがらめブクブクおでぶちゃんなワケね。
そんなんじゃ失敗して当然なんじゃないのか? Multics とか、メンバーが好き勝手言ったのを
全部盛り込んで自滅した OSI とか連想したよ。
0317名無しさん＠お腹いっぱい。2006/03/32(土) 16:11:31
>>316

どうでもいいが、Multicsのでかすぎる...仕様に圧倒され、AT&TのBell研は撤退した。
が、その経験からシンプルでかつ機能的なUnixが産まれた。

　　　　　素晴らしいぃぃ。。

が、その後しばらくして、Multicsは...完成したのだっ。

　　　　　素晴らしいぃぃ。。


0318名無しさん＠お腹いっぱい。2006/03/32(土) 16:24:49
unixがシンプルだと思ったことは一度もないが・・・
0319名無しさん＠お腹いっぱい。2006/03/32(土) 16:31:07
>>318
Windowsに比べればシンプルなんじゃね
0320名無しさん＠お腹いっぱい。2006/03/32(土) 16:34:14
CP/Mと比べるとえらく複雑
とかいってみるか
0321名無しさん＠お腹いっぱい。2006/03/32(土) 16:42:17
3BSD, 4BSD で VM や FFS 載るまではきわめてシンプルだったさ。
TCP/IP もなかったし。
>>317 の Multics 完成というのは文字通りの Multics なのか、スレッドや
共有メモリを持った今の「モダーンな」Unix を指すのか、どっちだろ。
0322名無しさん＠お腹いっぱい。2006/03/32(土) 16:46:28
>>305
> 仕様をみればみるほど、alphaやらpaやらx86やらvaxやらmipsやらをサポートするために
> 混ぜこぜにしたあげく、Unixサーバー, Hirayama, VAX向けのRASを加え、最後にVLIWの
> 味付けをしったって感じで目まいがするアーキ。単独プラットフォームで、あの全仕様
> を使うものってあるのだろうか？

設計された時点では、PA-RISC と x86 の後継としての意味しかなかっただろ。
Alpha や VAXのDEC系や、Himarayaとかなんて、HPがCompaq を買収後に、
初めて後継CPU、後継プラットフォームとして浮上してきたわけで、
設計や仕様を決める際には影も形もなかったぞ。
知ったかでいいかげんなこと書くな
0323名無しさん＠お腹いっぱい。2006/03/32(土) 16:51:08
BSD以前のUNIXなんて触ったヤツ何人いるんやら
0324名無しさん＠お腹いっぱい。2006/03/32(土) 16:58:49
何人かいないと Unix が Multics に対して（少なくとも最初の時期には）シンプルだったことに
ならないのか? 何の話がしたいんだおまえ?
0325名無しさん＠お腹いっぱい。2006/03/32(土) 17:04:07
まあどうでもいいや
しかしそのころは、UNICSなりMULTICSなりが正式名称でないの？
0326名無しさん＠お腹いっぱい。2006/03/32(土) 17:17:32
>>322

このスレでは、Itaniumはデブな出来損ないであるという認定が下されましたが、
何か？
0327名無しさん＠お腹いっぱい。2006/03/32(土) 17:30:16
まぁ、Itaniumはたんなる恐竜といわれても仕方がないな。
0328名無しさん＠お腹いっぱい。2006/03/32(土) 17:31:54
Itaniumは糞！
0329名無しさん＠お腹いっぱい。2006/03/32(土) 17:45:02
糞CPU相手に勝ったと喜んでいる場合じゃない。
0330名無しさん＠お腹いっぱい。2006/03/32(土) 17:45:27
そうだっ！　最大のライバルはPowerなのだっ。
0331名無しさん＠お腹いっぱい。2006/03/32(土) 17:49:55
>>325
No.

% ftp -o - http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v3/v3man.tar.gz | gunzip | tar xf -

% ls -l man0/intro
-rw-r--r-- 1 xxxx xxxx 8142 Feb 16 1973 man0/intro

% nroff -man man0/intro | head
UNIX PROGRAMMER'S MANUAL

Third Edition



K. Thompson

D. M. Ritchie

% nroff -man man0/intro | egrep -i unics | wc -l
0

3BSD は 1979 年だぞ。
■ このスレッドは過去ログ倉庫に格納されています