トップページ⇒unix
982コメント268KB

Sun Microsystems 最後の提携

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2007/06/10(日) 14:45:02
富士通は「いらない子」


【前スレ】
Sun Microsystems 最大の回復
http://pc11.2ch.net/test/read.cgi/unix/1170949021/
0403名無しさん＠お腹いっぱい。2007/08/30(木) 06:43:55
>>401
けど、せっかく性能がまともになってきたのに勿体ないね。
ローエンドのリプレースだけってのは。価格性能比じゃ x86 には勝てないし。
0404名無しさん＠お腹いっぱい。2007/08/30(木) 07:28:03
>>402
プロセッサは回路図だけあってもダメなんだよ。
回路図自体には大した価値がないからこそ、
Sunはそれをオープンにするんだろうに。

>>403
価格性能比でx86に勝とうとする、
面白いチャレンジだと思うよ。
0405名無しさん＠お腹いっぱい。2007/08/30(木) 17:00:27
PRIMEQUESTって 60〜70% を海外で売り上げるつもりだったんだな。悲惨だ...
0406名無しさん＠お腹いっぱい。2007/08/30(木) 23:10:46
>価格性能比でx86に勝とうとする
寝言は自社fab建ててから
0407名無しさん＠お腹いっぱい。2007/08/30(木) 23:13:27
いやいや、建てないから今の規模でやっていけてるわけで、
そんなの建てたらあっという間に、日没ですよ。
0408名無しさん＠お腹いっぱい。2007/08/31(金) 00:23:44
CPU単体ではなくサーバとしての、コストパフォーマンスでしょう?
0409名無しさん＠お腹いっぱい。2007/08/31(金) 00:55:16
>>405
ＩＤＣ　Ｊａｐａｎ、ＷｉｎｄｏｗｓとＬｉｎｕｘ搭載ＩＡ６４サーバーの市場機会分析結果を発表
http://release.nikkei.co.jp/detail.cfm?relID=168704&lindID=1
> 国内ＩＡ６４サーバー市場をオペレーティングシステム別にみると、２００４年下半期以降の成長は、
> ＵＮＩＸ搭載ＩＡ６４サーバーによってもたらされています（図参照）。Ｗｉｎｄｏｗｓおよび
> Ｌｉｎｕｘ搭載サーバー市場では、システム導入コストの削減要求から、性能向上を加速させている
> ｘ８６サーバーの躍進が目立ち、市場の情勢は、むしろｘ８６−６４サーバーに向かっています。
0410名無しさん＠お腹いっぱい。2007/08/31(金) 01:04:56
> 市場の情勢は、むしろｘ８６−６４サーバーに向かっています。
> 市場の情勢は、むしろｘ８６−６４サーバーに向かっています。
> 市場の情勢は、むしろｘ８６−６４サーバーに向かっています。
> 市場の情勢は、むしろｘ８６−６４サーバーに向かっています。
0411名無しさん＠お腹いっぱい。2007/08/31(金) 01:57:28
回りくどいな。「PA-RISC 置き代えの HP-UX 機だけしか売れてません。」で、いいんだよ。
付け加えるとすれば、
「ええ、Linux と MS-Windows のは売れてませんよ、いっさい売れてません。そうですとも。



:
:
プッ。」
くらいでいいんだよ。
0412名無しさん＠お腹いっぱい。2007/08/31(金) 08:33:20
Itaniumってなんだったんだろうね？
0413名無しさん＠お腹いっぱい。2007/08/31(金) 09:40:45
PA-RISCの開発費が膨れていくのに堪え兼ねたhpがインテルを巻き込んだ。
インテルは濡れ手に粟で、飛びついた。

最初のMercedだっけ?
99年にリリースする予定が01年までズレ込んでしまった時点で、
失敗プロジェクトだと痛いほどわかったはずなんだよねぇ。
0414名無しさん＠お腹いっぱい。2007/08/31(金) 10:03:41
ちょっといいくらいで市場を席巻できるなら、
IntelもMicrosoftも今頃はもっと縮小していると思われ
0415名無しさん＠お腹いっぱい。2007/08/31(金) 11:21:29
この大失敗のツケはすべて x86 の価格に転嫁されてるわけで、
ちゃんと競争相手がいて競争原理が働いてれば CPU はもっとずっと安いはず。
0416名無しさん＠お腹いっぱい。2007/08/31(金) 11:28:57
x86を醜く拡張したAMDも、もはやインテルよりもコストパフォーマンス悪いしな。

AMDがIA-64互換を選び、なおかつ、素晴らしい仕事をしていればなぁ。
0417名無しさん＠お腹いっぱい。2007/08/31(金) 11:58:54
そもそも互換を出させないためのIA-64だったような
0418名無しさん＠お腹いっぱい。2007/08/31(金) 12:19:57
IA-64に色気出さなきゃ、x86-64に隙突かれることもなかったのにね。
0419名無しさん＠お腹いっぱい。2007/08/31(金) 12:33:00
おまえら本当にIA-64が大好きなんだな
0420名無しさん＠お腹いっぱい。2007/08/31(金) 12:35:09
だってPOWER君はエリートで相手にしてくれないし、
僕らしもじもで罵り合うくらいしかないじゃないですか。
0421名無しさん＠お腹いっぱい。2007/08/31(金) 12:56:57
Itanium = VirtualBoy / WonderSwan
0422名無しさん＠お腹いっぱい。2007/08/31(金) 13:21:16
CPUの性能について語るスレ
http://pc11.2ch.net/test/read.cgi/hard/1052555174/

ＣＰＵの話題ならハードウェア板だろ？
0423名無しさん＠お腹いっぱい。2007/08/31(金) 15:21:54
>>416
> AMDがIA-64互換を選び、なおかつ、素晴らしい仕事をしていればなぁ。
そんなバカなwwww 本家がロクに完成できないのに、なんで互換品作れるんだよ
どういう頭ん中?w?w
0424名無しさん＠お腹いっぱい。2007/08/31(金) 20:37:20
>>423
インテルはIA-64やNetBurstという大失敗をやらかすが、
AMDはK7、K8と大成功続きだ。
x86の64ビット拡張はAMDが作ったものをインテルがパクったほどだ。
0425名無しさん＠お腹いっぱい。2007/08/31(金) 21:11:59
Ita はたしかにゴミだが、それはつまり EPIC がゴミなんだろう。そんなもんに投資する方がバカ。
0426名無しさん＠お腹いっぱい。2007/08/31(金) 21:21:05
AMDはK7、K8と大成功続きだ。
AMDはK7、K8と大成功続きだ。
AMDはK7、K8と大成功続きだ。
AMDはK7、K8と大成功続きだ。
AMDはK7、K8と大成功続きだ。
0427名無しさん＠お腹いっぱい。2007/09/01(土) 02:10:31
大成功といっていいんじゃないの？
巨人IntelのCPUロードマップを変えさせたくらいだから。
RISCショックに引き続く方向変換だった。
0428名無しさん＠お腹いっぱい。2007/09/01(土) 02:48:06
8ビット→16ビット→32ビットと、
バイナリ互換を保たずに脱皮するチャンスをインテルがずっと無駄にしてきて、
64ビットになるときが最後のチャンスだったのに、AMDが無駄にしたんだよ?
0429名無しさん＠お腹いっぱい。2007/09/01(土) 02:51:12
x86-64は安直で目先のことしか考えてない。

レジスタを倍にするために、prefixで1バイトもコードを肥大化させやがった。
どうせ64ビットのモードでは既存の32ビットのコードが走らないのだから、
命令セットを再設計すべきだった。
0430名無しさん＠お腹いっぱい。2007/09/01(土) 04:19:33
>>427
K8 K9 K10
全部キャンセルされてるんですけど
今のK8とK10はマーケティング上後から付けられた名称というのは常識
0431名無しさん＠お腹いっぱい。2007/09/01(土) 08:24:53
>>428
＞バイナリ互換を保たずに脱皮

６４ビットが必要とされてるんならAlphaは成功してたはず。
おまけの６４ビットが使いたいならペナルティを払うのは当たり前。

本当に３２ビット以下が必要ないなら、３２ビット以下の動作モードを撤去するだけの話だろ。
0432名無しさん＠お腹いっぱい。2007/09/01(土) 09:08:58
AlphaやMIPSは会社の不振が響いたと思われ。
SPARCが残っているのが奇跡に近いというか…
0433名無しさん＠お腹いっぱい。2007/09/01(土) 09:35:48
>>431
> ６４ビットが必要とされてるんならAlphaは成功してたはず。

Alphaとx86-64では時期がまるで違うので、同列に比較できない。

> おまけの６４ビットが使いたいならペナルティを払うのは当たり前。

「おまけ」のうちはペナルティが大きくても構わないが、
命令セットにペナルティがあれば、それは将来にわたって払うことになる。

> 本当に３２ビット以下が必要ないなら、３２ビット以下の動作モードを撤去するだけの話だろ。

64ビットのモードで32ビットのコードは走らなくても、
32ビットのモードで32ビットのコードを走らせる意味は、当分はある。

x86がここまで来たのも、以前の命令セットを実行するモードを備えていたから。
0434名無しさん＠お腹いっぱい。2007/09/01(土) 09:58:10
>>433
４８６からPentiumになったときは１６ビットが遅くて３２ビットが早かったけどね

＞Alphaとx86-64では時期がまるで違うので、同列に比較できない。
時期がまるで違うからこそ６４ビット計算が必要なものは必ずAlphaを使ったはず。
今は普及したものでは、６４ビットでも３２ビットでも性能変わらないから、
６４ビットが必要なのはメモリ空間のためだけだろ。

＞x86がここまで来たのも、以前の命令セットを実行するモードを備えていたから。
うん。
だから反論した。
0435名無しさん＠お腹いっぱい。2007/09/01(土) 10:05:52
286から386になった時もリアルモードは遅くなった
0436名無しさん＠お腹いっぱい。2007/09/01(土) 10:18:03
>>434
> ４８６からPentiumになったときは１６ビットが遅くて３２ビットが早かったけどね

だから何?

> 時期がまるで違うからこそ６４ビット計算が必要なものは必ずAlphaを使ったはず。

64ビットはAlphaの専売ではなかった。UltraSPARCも64ビットだよ。

> うん。
> だから反論した。

私が言った「バイナリ互換を保たずに脱皮」というのは、互換モードを持たずに、という意味ではないよ。
0437名無しさん＠お腹いっぱい。2007/09/01(土) 10:33:47
>>436
ああそういえばそうだね。

UltraSPARCは当分つぶれる心配ないからインテルには永遠に３２ビットで頑張ってもらえばいいんじゃね？
６４ビット使いたければUNIX使え。
Windowsが使いたいなら３２ビットで我慢しろ。
これでいいんだろ？

＞だから何?
６４ビットが必要なんならペナルティ払っても３２ビットより早いはず。
３２ビットより遅くなったとしたらそれは６４ビットが必要なかったってことだろと。

＞互換モードを持たずに、という意味ではないよ。
だから２人で来られるとメイワク。
過去の書込みの話するなら名前入れてね。
0438名無しさん＠お腹いっぱい。2007/09/01(土) 10:43:04
AMDがx64をもっとまともな仕様にしてくれてたら

富士通は PRIMEQUEST を出さなかった。


F2カワイソスｗｗｗｗ
0439名無しさん＠お腹いっぱい。2007/09/01(土) 10:48:41
>>437
> これでいいんだろ？

いいわけないだろ。

> ６４ビットが必要なんならペナルティ払っても３２ビットより早いはず。

それと、
> ４８６からPentiumになったときは１６ビットが遅くて３２ビットが早かったけどね
は、話が繋がりませんが?

> ３２ビットより遅くなったとしたらそれは６４ビットが必要なかったってことだろと。

今は必要なくても将来は必要になるだろう。
いいかげんな64ビット拡張を普及させてしまうことは、今は問題なくても、将来に問題となる。
そういう話をしているのだが。
0440名無しさん＠お腹いっぱい。2007/09/01(土) 11:19:17
どの道、x86なんていい加減な拡張の集積みたいなもんじゃん。
今更なに言ってんの？
0441名無しさん＠お腹いっぱい。2007/09/01(土) 12:01:37
>>439
マイクロソフトも売れもしない64ビットOSをなん通りも出したくないだろ。
客も迷惑だしな。

インテルは６４ビットに関してはｘ８６互換を捨てたけど、AMDはｘ８６互換でいった。
ユーザーはｘ８６互換を選んだ。

それが不満ならあんた１人で勝手にIA64使ってればいいんじゃね？


ほとんどのアプリケーションは永遠に３２ビットで足りるんですよ。
ビデオエンコなんて６４ビットの方が遅かったって話だし。
つまり６４ビットのために３２ビットの実効性能を落とす意味がない。

最高性能が必要な本格サーバーではそもそもｘ８６とかWindowsとか使わないしな。
0442名無しさん＠お腹いっぱい。2007/09/01(土) 12:02:09
>>438
まじで？
0443名無しさん＠お腹いっぱい。2007/09/01(土) 12:25:58
>>441
>ビデオエンコなんて６４ビットの方が遅かったって話だし。

これってどんな環境で？
自分で試した範囲内ではPentium4とCore 2 DuoとOpteronでは、動画のエンコードみたいな処理で
いずれも64ビットモードの方が速くなったけど
0444名無しさん＠お腹いっぱい。2007/09/01(土) 12:57:05
>>443
確か６４エディションと３２ビットのWindowsにそれぞれ付属のWindowsMediaEncoderで比較だったとおも
記事探したけど消されたのか埋もれたのか見つからん。
0445名無しさん＠お腹いっぱい。2007/09/01(土) 13:51:18
>>440
16ビットから32ビットになったときは、ハードウェアと命令セットが一対一だったから、仕方なかった。
32ビットから64ビットになったときは、内部命令に変換して実行するようになっていたので、改善可能だった。

>>441
> インテルは６４ビットに関してはｘ８６互換を捨てたけど、AMDはｘ８６互換でいった。
> ユーザーはｘ８６互換を選んだ。

IA-64とAMD64どちらも、
32ビットのモードはx86互換で、
64ビットのモードはx86非互換ですが?

> ほとんどのアプリケーションは永遠に３２ビットで足りるんですよ。

ファイルポインタに64ビットが必要。
いくつものアプリが、2GBや4GBの制限を抱えている。
0446名無しさん＠お腹いっぱい。2007/09/01(土) 13:59:42
IA64は糞
Sunがx64を選んだんだから間違いない
0447名無しさん＠お腹いっぱい。2007/09/01(土) 14:01:19
off_tはCPUのビット数とは無関係。
ほとんどのアプリはフラットにメモリ2G不要。
0448名無しさん＠お腹いっぱい。2007/09/01(土) 14:14:27
>>446
x86-64の話をしていたところに、IA-64を持ち出したのは誰かな?

>>447
> off_tはCPUのビット数とは無関係。

じゃぁなんでファイルサイズに制限を抱えているアプリが多いんだ?

> ほとんどのアプリはフラットにメモリ2G不要。

知らぬが仏ってやつだな。

アプリを作る側が2GBのアドレス空間で足りるようにしてきたんだよ。
実際に使うサイズよりも、かなり広い空間が必要なんだよ。
たとえばスタック。スタックサイズを余裕をもって100MBにしようものなら、
スレッドが20個あれば、それだけで2GBだよ。
64ビット空間にすれば、スタックは事実上、無限大になる。
0449名無しさん＠お腹いっぱい。2007/09/01(土) 14:18:19
>>448
>じゃぁなんでファイルサイズに制限を抱えているアプリが多いんだ?
開発者が無知だから

>スタックサイズを余裕をもって100MB
スタックを100MBとかアホですか？
0450名無しさん＠お腹いっぱい。2007/09/01(土) 14:31:47
> x86-64の話をしていたところに、IA-64を持ち出したのは誰かな?

さあ？誰なの？
0451名無しさん＠お腹いっぱい。2007/09/01(土) 14:34:50
まとめ：
元祖 SPARC からずーっとバイナリ互換の Ultra SPARC シリーズは神ｗ
0452名無しさん＠お腹いっぱい。2007/09/01(土) 14:44:55
>>449
> 開発者が無知だから

そう考えているから>>447のような発言になるわけだ。

> スタックを100MBとかアホですか？

アドレス空間が狭いから、スタックの消費を控えるのが常識になってるの。
アドレス空間が広ければ、スタックの消費を控える必要はないんだよ。
0453名無しさん＠お腹いっぱい。2007/09/01(土) 14:49:31
＞64ビットのモードはx86非互換ですが?
ああそうだっけね。
まあDOSが動いてくれればなんでもいいよ。

>>448
システムで扱えるファイル・サイズの最大値（制限）を決める第一の要件は、ファイル・システムそのものに起因している。
あとは古いライブラリ使ったり９５系専用API使ったりじゃないかな。

>>448
＞スタックサイズを余裕をもって100MBにしようものなら、

６４ビット信者は中身すかすかにするのが好きだから邪魔。
おまえみたいのがVistaみたいな百貫デブを生み出すんだよ。

>>452
＞アドレス空間が狭いから
あんたパソコンに１TB（５００万円）もメモリ積むつもりか？
メモリだけで何ワット消費するか計算できる？
0454名無しさん＠お腹いっぱい。2007/09/01(土) 14:53:20
UNIX板で何やってんだ、この人は
0455名無しさん＠お腹いっぱい。2007/09/01(土) 14:56:43
>>453
> システムで扱えるファイル・サイズの最大値（制限）を決める第一の要件は、ファイル・システムそのものに起因している。

ファイルシステムにそのような制限があるのは、なぜか?
根っこはみな同じだよ。

> ６４ビット信者は中身すかすかにするのが好きだから邪魔。

スカスカで何か問題でも?

むしろ、本来ならスタック上にあるべきものを、ヒープ上に置いて、
ヒープの断片化にまつわるトラブルを起すほうがマズいと思うよ。

> あんたパソコンに１TB（５００万円）もメモリ積むつもりか？

アドレス空間を予約するのと、実際に物理メモリを消費するのとは、違いますが?
0456名無しさん＠お腹いっぱい。2007/09/01(土) 15:04:55
実際に物理メモリを確保しないなら、
フラットに64ビットなんか不要。

とか言ってるけど、ほんの１５年前はDS,SI,DIで
64kBでシコシコやってたんだよな。
0457名無しさん＠お腹いっぱい。2007/09/01(土) 15:07:16
>>455
＞スレッドが20個あれば、それだけで2GBだよ。
＞アドレス空間を予約するのと、実際に物理メモリを消費するのとは、違いますが?

まあ確かにCOMオブジェクト１２８個起動したらメモリ１００MBとか食っちゃったけどすごい非効率でしたよ。
物理メモリは消費しなくてもページファイル使うんじゃね？

＞本来ならスタック上にあるべきものを、ヒープ上に置いて、
固定サイズで取れって？

＞ファイルシステムにそのような制限があるのは、なぜか?
そんな先のこと考えてないからだね。
0458名無しさん＠お腹いっぱい。2007/09/01(土) 15:53:37
>>457
> まあ確かにCOMオブジェクト１２８個起動したらメモリ１００MBとか食っちゃったけどすごい非効率でしたよ。

話が飛んでますな。

> 物理メモリは消費しなくてもページファイル使うんじゃね？

そんな酷い実装のOS、どこの何ですか。

> 固定サイズで取れって？

それは、本来ならスタック上にあるべきもの、なんですかね。

> そんな先のこと考えてないからだね。

とりあえず全てを64ビットにしておかなかったのは、なぜかな。
0459名無しさん＠お腹いっぱい。2007/09/01(土) 15:55:50
Intelサイコー
AMDサイテー
Sunサイナラー
0460名無しさん＠お腹いっぱい。2007/09/01(土) 16:03:08
>>458
＞とりあえず全てを64ビットにしておかなかったのは、なぜかな。

とりあえず１２８ビットじゃない理由は、何かな。

ところで、プログラム組めるの？
使える言語何？
0461名無しさん＠お腹いっぱい。2007/09/01(土) 16:10:49
とりあえず PRIMEQUEST が脂肪なのだけはガチ
0462名無しさん＠お腹いっぱい。2007/09/01(土) 16:12:01
>>460
128ビットなんて、今後100年内に、必要になることは、なさそうだぞ。

本当は64ビットあったほうがよくても、
メモリやディスクの容量や、計算コストの節約のために、
先のことを予測して考えた上で、ケチっているのだが、
>>457には、それが理解できていないようだ。

テストのことを考えたら、
ファイルポインタだけ64ビットにするのは、
怖くてできない。
0463名無しさん＠お腹いっぱい。2007/09/01(土) 16:25:23
>>462
アンカー間違ってね？

＞ファイルポインタだけ64ビットにするのは、怖くてできない。

その程度が出来ないなんていつからプログラマやってんの？
0464名無しさん＠お腹いっぱい。2007/09/01(土) 17:41:57
>>461
開発中止？
0465名無しさん＠お腹いっぱい。2007/09/01(土) 21:04:55
>>462
> テストのことを考えたら、
> ファイルポインタだけ64ビットにするのは、
> 怖くてできない。

馬鹿ですか?
fpos_t使えばいいだけですが?
Integral typeのtypedefと思っているんじゃないだろうな?
0466名無しさん＠お腹いっぱい。2007/09/01(土) 21:15:00
Sunヨウコソー
MSサヨナラー
0467名無しさん＠お腹いっぱい。2007/09/01(土) 22:50:18
Intelサイコー
AMDサイテー
IBMサイアクー
Sunサイナラー
0468名無しさん＠お腹いっぱい。2007/09/01(土) 23:00:48
HPサイコー
0469名無しさん＠お腹いっぱい。2007/09/01(土) 23:23:30
mmapしまくるから、アドレス空間は広い方がいい
0470名無しさん＠お腹いっぱい。2007/09/01(土) 23:54:01
>>465
そんなに簡単な話なら、なぜ、制限を持ったアプリが多数あるのか。

>>469
mmapしまくるとパフォーマンスがね。
ディスクへのアクセスがランダムになりやすくなってしまう。
0471名無しさん＠お腹いっぱい。2007/09/02(日) 02:28:39
これ以上続けるならここでやれば？

＞ Solarisプログラミング教えてチョンマゲ
0472名無しさん＠お腹いっぱい。2007/09/02(日) 16:18:12

突然変なのが湧いてて、日曜には出てこないからおかしいなと思ったら
今日は夏休み最終日だったんだね。
道理で・・・
0473名無しさん＠お腹いっぱい。2007/09/02(日) 23:43:28
近年マレにみる低レベルww
0474名無しさん＠お腹いっぱい。2007/09/03(月) 00:06:42
Victoria Falls量産の暁には
0475名無しさん＠お腹いっぱい。2007/09/03(月) 02:32:32
Sunがこの先生きのこるには
0476名無しさん＠お腹いっぱい。2007/09/03(月) 03:02:19
この先生きのこ
0477名無しさん＠お腹いっぱい。2007/09/03(月) 11:15:51
やっぱ以前 Sun に負けてたやつらって遅いね。情報収集能力がないんだなwww
0478名無しさん＠お腹いっぱい。2007/09/03(月) 13:05:05
Sunってさ、
学生時代にSunのワークステーションでUNIXに初めて触れてカルチャーショックを受け夢中になった
そういう世代の半ば盲目的な支持で選択されてきと思うが、どうよ。

HP-UX? HPなんて触ったことないからダメ
Linux? あんなのオモチャ
IRIX? Onyxとか触ってみたかったなぁ
Solaris2? やっぱりSunOS 4がいいよ

そういう人をたくさん見てきた。
0479名無しさん＠お腹いっぱい。2007/09/03(月) 14:26:21
小型（オフコンやワークステーション）はいいけど、Unix なんてダメ、って人は
たくさんいたね。
盲目的ねぇ。今の若い連中の方がよっぽど盲目的だと思うけど。評価能力ないだろ。
Sun 好きな人はねぇ、たいがいネットワーク好きな人だよ。
ネットワークの意味分んなかったやつらが Sun を毛ぎらいしてる。
Linux はねぇ。Unix に MS-Windows のガワかぶせるのはやっぱくだらないでしょ。
結論自明。
やっぱ向かうべきは（本来の意味での）分散システムでしょ。
NAT（IP マスカレード）がネックだったね。功もあるが、罪の方が大きいんじゃ
ないかね。
0480名無しさん＠お腹いっぱい。2007/09/03(月) 15:35:36
さあ？NeXTSTEPから入りましたが、Sunも支持してますよ。
色んな特色(癖)を持ってる奴らばかりで、面白かったですよ。
今、残ってるのが少ないから選択肢がねぇ・・・

NeXTは綺麗な美術品。
Linuxマシンは僕の手にも届くおもちゃ。
Solarisマシンは前線で頑張るハイブリッド車。
SunOSはエコディーゼル車。
Alphaはレーシングカー。
NewsはダブルCDラジカセ。
HPはナーバスな温度計。
そんな当時のイメージを今風に喩えてみた。

>>479
いや、じゃあ当時どうやってIPが頻繁に必要になる状況を回避すべきだったかというのを考えると
既にIPv6とか他のプロトコルに全面差し替えできるホドの規模じゃ無くなってたし
局所的に対応するしかなかったんじゃないかなぁ・・・
それは良くも悪くも網を完全に管理しきれない"inter"netであるがためでしょう。
罪を負うべきはinternet。
0481名無しさん＠お腹いっぱい。2007/09/03(月) 16:05:40
ＩＰｖ４：172.255.31.1
ＩＰｖ６：3ae3:90a0:bd05:01d2:288a:1fc0:0001:10ee

ＩＰアドレスを手動設定したり割り当ての手間を考えれば最初にＩＰｖ６を採用するのはちょっとあり得ないでしょ。
だけど３２ビットじゃなく６４ビット割り当ててあれば枯渇は起きなかったし互換性も確保できたかもね。

けどＩＰアドレス不足のためのルータの発達と普及のおかげで、
末端では自由に端末を増やせるようになったし、セキュリティも確保できた。

完全ＩＰアドレス割り当てだと、端末１こ当たりいくらって計算になってしまって
ブロードバンドもきっと使いにくく料金もお得じゃなかったと思うね。
0482名無しさん＠お腹いっぱい。2007/09/03(月) 17:59:58
でも YP や NFS をみんな殺してしまったよ、IP マスカレードは。
そういうサービスを生かした形でセキュリティ対策を施していくべきだった、
つまりそれは今 IPv6 を使うってことと等価だと思うけど。
つーか、IPv6 だと手動設定の手間? なに言ってんの????
0483名無しさん＠お腹いっぱい。2007/09/03(月) 18:02:21
>>480
最善の策が NeXT や MacOS X だってことにそれほど異論はないけど、
誇大宣伝が過ぎるよ、Jobs は。そんなたいそうなもんじゃないじゃん。
0484名無しさん＠お腹いっぱい。2007/09/03(月) 18:02:28
>>482
YP(つーかNIS)やNFSは、clientがNATの中でもちゃんと使えるよ。なに言ってんの????
0485名無しさん＠お腹いっぱい。2007/09/03(月) 18:07:27
あんた放置。
0486名無しさん＠お腹いっぱい。2007/09/03(月) 18:08:21
なんか90年代の会話みたい
0487名無しさん＠お腹いっぱい。2007/09/03(月) 19:14:18
だってUNIX板ですから。
0488名無しさん＠お腹いっぱい。2007/09/03(月) 19:15:49
大学の中にいると、時が止まっているからねぇ。
0489名無しさん＠お腹いっぱい。2007/09/03(月) 21:08:39
Sun Microsystems 最後の昔話
0490名無しさん＠お腹いっぱい。2007/09/03(月) 21:30:38
aixが無い!
0491名無しさん＠お腹いっぱい。2007/09/03(月) 22:21:26
AIXはUNIXじゃないから
0492名無しさん＠お腹いっぱい。2007/09/03(月) 22:25:29
>>479
ていうか、NATとIPマスカレードを同一視してる時点で...
0493名無しさん＠お腹いっぱい。2007/09/04(火) 00:34:13
ここってFのひとがおおいの？
それとも日立の人かな？
0494名無しさん＠お腹いっぱい。2007/09/04(火) 00:42:02
昔の方がポーティングに気を使ったコードを書いてたような気がするなあ。
今だとlinuxしか考慮してないモノがおおいね。

AIX/NEWS/SunOS/Solaris/DGとかいろいろ、条件コンパイルが通るようにしながら幅広く使ってもらえるようなコードを書いてた時代が懐かしいよ。
0495名無しさん＠お腹いっぱい。2007/09/04(火) 00:48:00
>>492
IP マスカレードは NAT じゃなくなったのか?
0496名無しさん＠お腹いっぱい。2007/09/04(火) 01:13:41
つーか、IP マスカレードがネックだった、と言ってるんだが。そんなの汲めないのか?ww
0497名無しさん＠お腹いっぱい。2007/09/04(火) 02:00:24
IPマスカレード＝動的NAT
こんなんかなり昔からの定義だよね。
0498名無しさん＠お腹いっぱい。2007/09/04(火) 02:17:52
IPマスカレード≒動的NATだな。
厳密にいえば、動的NATはIPアドレスだけの変換しか行わないものを指す。
動的NATのみで使われることがあまりないから、ほぼ同じものとして扱われているだけ。
0499名無しさん＠お腹いっぱい。2007/09/04(火) 02:52:21
>>492
IPマスカレードは、NAPTの初期の実装例の名前。

油性フェルトペンという意味で「マジック」と言うのと同じだぞ。
0500名無しさん＠お腹いっぱい。2007/09/04(火) 06:45:46
NAT ⊃ NAPT ∋ IPマスカレード

おまえら、集合論得意か?
0501名無しさん＠お腹いっぱい。2007/09/04(火) 07:00:48
めちゃめちゃ得意。

オタマジャクシが１ｃｃあたり何匹いるかって問題だよね。
0502名無しさん＠お腹いっぱい。2007/09/04(火) 09:20:07
>>494
> 今だとlinuxしか考慮してないモノがおおいね。

メジャーだから目立つだけでしょ。
昔はSunOSしか考慮してないモノが多かった。
だからSunOSはいろいろと楽だと言われた。
■ このスレッドは過去ログ倉庫に格納されています