AMD の64ビットCPU オプテロンでLINUXしよう

>>937
配布形態に問題はない。
ｎｙやMX見たいなP2Pは元来そういう使い方するもんだしな。

644必死だなw

またよその板のアホウが粘着してるなあ

音沙汰無くて申し訳ない
作って流しておけば誰かが続けてくれるかなーと思って放置してたんだけど
逆に怪しがられたようだ。一応作り方を乗せておくと

１．RedHat Enterprise Linux 3.0(以下RHEL)のβ版をダウンロード
２．Athlon64マシンにインストール
３．lftpでFTPサイトからSRPMをダウンロード
４．自動リビルドスクリプトを使って全部をリビルド
５．anacondaのツールを使ってISOを構築
６．再びインストール
７．１〜５までをもう一度繰り返す

これで完成。全部をリビルドしたのはβのRHEL3には再コンパイルするために必要な
開発パッケージ(**-devel)が削除されてたからソースからそれらも作り直す必要があった

一人で全部再ビルドしたのはそっちのほうが楽だったから。
Athlon64 3400 + Mem 1GBなら自動スクリプトを動かしておけば30時間ほどで全部終わる
有志の人に仕事を振り分けて指示を取るより手っ取り速い。
(それに>>644で実行するって表明したときに誰も参加しようとしなかったし)

winny配布はi686最適化版のRedHatを作った時に
Shadow Manのロゴ等がRedHat社の商標に引っかかるらしいので
FTP等での公式の場での無料配布は駄目なことがわかったから
(多分、商用に利用しなければ問題ないと思うけど)
一応、公式なものではなくRedHat派生の開発途中の同人ディストリという
意思表示も含めてwinnyで配布している。

オプソで成り立ってるRedHatも強気な態度には出てこないと思うし
やりたいならFTP等で公開配布してもいいよ

作るときに参考にしたのはここ

http://z1.plala.jp/i686fc/

俺がi686 RH9を作った時に配布に協力してくれた人なんだけど
配布中止後も独自に研究を続けて、文書にまとめてくれたようだ

http://z1.plala.jp/i686fc/Autobuild.sh
↑ これが漏れの作った自動コンパイルスクリプトを改良したもの
今回はこれをさらに改良したものを利用した
>>659で公開済み

ところで、644の人も他のテスターの人も、もう公開してないの？
一日に12時間くらい繋いで、Disc1と3は数日で落とせたんだけど、
Disc2が15MBくらいで停まったまま2週間以上全然落ちてこない。

2週間だ？　気の長いヤシだ。

>>944

はは、漏れと全く同じだな。
あれ以来ずっと起動したまんまだけど進捗変わらずだよ。
それより先のキャッシュは誰も流してないっぽいのよ。

あきらめてFedora x86_64入れちゃったけど、以前見てみ
たいのは変わらない。
上で何か一悶着あったようだけど前も書いたけどOwnRisk
は承知の上。
てなわけで、FTPｷﾎﾞﾝに一票

ﾉ
FTP(HTTP)ｷﾎﾞﾝﾇ。

報告が少ないと思っていたらDisk2があまり出回ってなかったですか
じゃ、今週一杯winny付けときますんで吸ってください

ただネトゲがやるもんでwnnyだけに帯域を使い切れないんです。。。

再公開中
ついでに、2月までに出たパッチもコンパイルしといたんで出す

RHEL3_64_UP1.tar.bz2 FVA3GQidXp 280,685,543 011c5f67962b4aa0c4e9dc0eec8e19e0

つか漏れは
irc.2ch.net
#Linux に居るよ。遊びにおいで

分かってると思うけど一応補足

↑で公開したパッチファイルは
rpm -FUvh *.rpm で自動でアップデートできるファイルを
選択してアップデートしてくれる。

ごみんなさい
リリースしたパッチはx86_64のファイルしか含んでませんですた。(i386, i686用を含んでない)
現在3月末までにリリースされたパッチのコンパイルをして
i386, i686のパッチも含めたアーカイブを準備中です。。。

多分 x86_64だけのパッチファイルだと依存関係でrpm -FUvh できません。。。。
もうちょっと待ってね　(´・ω・｀)

3月までのパッチをまとめてコンパイルしたもの

RHEL3_64_UP2.tar.bz2 FVA3GQidXp 329,412,664 c996df729e6dbf1d2fd6403deec3b30d

一応アップデートスクリプトつき ./Update.sh で動くかもしれない(未確認)

↑ i386, i686, x86_64のパッチとgtk+1.2(i386)入り
gtk+-1.2を入れると32bit用にリリースされた商用のGTKアプリが動きます

944氏乙。

今日くだ質でも少しﾚｽしたのだが、
VT8237のSATAなHDDにFC2test2を入れるのをやってみた。
うまく認識されてやった!!

…って思ったらDiskのﾌｫｰﾏｯﾄの次の辺りでこけやがる。…＿|￣|○
PATAなHDDには問題なく入る。

しょうがないので、

・PATAにFC2test2をｲﾝｽｺ
・SATAにｲﾝｽｺした中味を移動。
・SATAのmbrにGrubをｲﾝｽｺ
・/etc/fstabをちょこちょこ書き変え。

てな感じでやってうまくいきますた。

えーとですね
3月31日までに出たのパッチの再コンパイルバイナリ集なんですが
Update.shは依存関係が複雑なため結果的にうまく動かないみたいです

jafとかjavamailとかjunintとか個別に入れた後に(別パッケージに分けられたJava関連のファイル達)
elfutils-* と binutils-* はお互いに強く依存し合っているためこれらだけをを同時に入れた後
(↑コンパイルやバイナリ解釈等に使われる中核部分)
rpm -FUvh *.rpm をすればすべてアップデートできます

gtk+1.2(i386)はglib-1.2のi386版を入れ忘れたので依存エラーで入りません。。。
ごみんなさい

AMDはまともに動くFORTRANコンパイラ、C++コンパイラを頑張って開発して
出すべき。自分では出せなければFSFに寄付でもして作らせて欲しい。

インテルのIA32e用のコンパイラの出すコードがAMD64で果してまともに
動くかどうかは、極めてあやしいと思うし、性能がたぶん発揮出来ないような
仕掛けをするだろうから。

PGIのではだめなの？

>>957
Windows版は2バイト書き換えるだけでOK

>959
意味が分からないので、もっと詳細キボンヌ。

>>957
intel の IA32 用の compiler で作ったコード普通に動くよ。
optimize も 32bit 用としてはできる。
そうじゃなきゃ P3 でもまともに動かなくなるんじゃないの？

ただ、64 native の compiler がほしいというのはその通りだけど。

>>958
PGI の性能はどうなんだろう？ 大分速いなら買うけど、
AMD でさえ spec ベンチに intel compiler 使ってる位だからなぁ。

だいぶ転送したようですが、まだ落ちてこないって人いまつか？
winny止めていい？

>>962

帰って確認しないとだけど、０時くらいまで待ってもらえるとありがたい。
今朝までで620MB程度落ちてきてたけど。

ちゃんと全部落ちてたら漏れがしばらく起動したままにしときまつ。

Wellcome to the real 64bit Linux World.


AMDは、Linux user、FreeBSD user、NetBSD userに
x86アーキテクチャベースで64bitな世界をいち早く提供しました。
Thanx AMD!!

winnyを止めました
要求があれば再開しますが、第2弾の作成が終わりつつあるので
そちらを流すことになりそうです。

ここを直せとか文句があれば今のうちにどうぞ
できれば直す方法も教えてくれると、多分直ってます

>>965

おかげで全部ﾀﾞｳｿできました。

次回の配布や差分を流すのであればトリップをつけて配布してもらえると
ダウン指定が楽で助かるのですが。

>>964
x86 にこだわらなければ 64 bit Linux は数年前からはあったんだけどな。

一応、x86-64を知らない人のために解説のリンクをはっておく
ttp://e-words.jp/w/x86-64.html

もう一つはっておく
Linux関連とずれてしまうがｽﾏｿ。（Opteron関連なので）
AMDのOpteron開発コンセプトがわかる。（ちょっと古いかも）
ttp://pc.watch.impress.co.jp/docs/article/20001025/kaigai01.htm

SUSE Linux 9.1が来月発売の予定。Professional版はAMD64にも対応。

国内ではいつになるんだろう。

>>970
Online Storeで購入できるのでは？

そろそろジスレ
990ぐらいまでいってからでいいか。

>>971
国内代理店での販売のお話です。

Online Storeは何度か使ったことがあります。(送料がいたい)

もし、32bitのソースを64bitにgccでコンパイルする場合
以下のオプションを付けて32bit→64bitへのポーティングチェックしたほうがいい

-Werror -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wcast-align -Wuninitialized -ansi -pedantic -Wbad-function-cast
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decl

自分で書いたプログラムなら、根本から見直すべき。

ポインタを使ってよほど悪さをしてなければ大丈夫なんじゃない？
速度的には落ちて、メモリの使用量も増えるかもしれないけど

>>975
>>976
もちろん、それもそうだが>>974が言うのは念の為って事では？
実は、自分もポインタ関連ではまってしまった。
＿|￣|○

忘れがちになるのがintとlongのサイズ。
オプションしておいた方が無難だと思う。

>>977
> 忘れがちになるのがintとlongのサイズ。
> オプションしておいた方が無難だと思う。

自分の書くプログラムなら、
#include <stdint.h>で、int32_t, int64_tですよ。
もちろんsizeが問題になるところだけね。

/usr/include/stdint.hは一度眺めておいた方がいい。

それにしても、Opteronはかなりの高負荷状態をかけても安定して動作してる。
さすがに凄いなOpteron。

>>977
sizeof とか使ってれば問題ないんじゃない？
俺は自分のコードでは 32, 64 bit ではまったことない。
一方 integer overflow とかしたことあるから別に威張る
つもりは毛頭ないけど。

>>979
なんせ元DEC　alpha設計チームの技術者が手がけた仕事だからな！
この（サーバー）分野は十八番だろ♪

>>980
いや侮っちゃいけない。
必ずしも自分のソースだけいじるとは限らないし。
以前、他人のソースを変更している時に
defineでlongのサイズを決め打ちで4として配列数に掛けていたし。
＃それを思い出しただけでもガクブルです。
＃(((( ；゜Д゜)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>981
>この（サーバー）分野は十八番だろ♪
だからIntelに目を付けられて(ry
それとか最近、公取が(ry　←これはAMDの競争相手だが
等、なんかいろんな状況になってるけど、がんばれAMD！
サーバ分野をOpteronでとことんぶちかましてほしい。

>>982
>defineでlongのサイズを決め打ちで4として配列数に掛けていたし

とんでもないことしてるな
まぁ、sizeof(long)に置き換えれば簡単になおるけどな

ところで新しく落として実験した人レポートください
第二段の公開を戸惑ってるんで
|ω・｀)

>>984,644
おつかれさまです。
Winnyを利用できない(したくない)人もいそうだし、
BitTorrentとかで放流してみたらどうでしょう?
rpmやaptでパッケージもでてるし。

>>982
> defineでlongのサイズを決め打ちで4として配列数に掛けていたし。

そういうヤツの書いたコードを使うってのはえらく怖いな…

>>984

ごめんよ〜
FC1入れちゃったからってのもあるんだけど、
gtk+1.2(i386)が入らないっていってたからまだ入れてないんだ
責めるつもりはないけどさ
快適かどうかパフォーマンス見ようと思ってたのがgtkアプリ
だったからさ・・・

いや、ごめんよ
もう一枚HDD都合するからさ