アカウント名:
パスワード:
「srpm から一発ビルドしたものを配布するのが常識」であるっっ (断言っ!)
いや、複数の同じプロセッサのマシンの場合はね。srpm を作るときに、特定のCPU用の最適化を限界までかけたオプションを付けてビルド。できた rpm を配布するのさ。
大抵のソースは、プログラムを除去したり更新したりすることを考えていないので、たとえ source からビルドする場合でも srpm を作り、rpm にしてからインストールした方がよい。
.
あとは必要なパフォーマンスとのご相談だよね。CPUやメモリ消費量に対して、srpm を作ってそこからビルドする手間が見合うか、と考えればよい。世の中に出回っているrpmは、セキュリティも含めてほぼ100%全自動で対応してくれる(定期的に update さえしていればよい)。update ができない/怖くてやれない/プロプラエタリなソフトが追従してくれないので動かなくなる とかいうのでなければ、何も考えずに毎日 yum -y upgrade して、特定の時間帯に shutdown -r した方が、よほど信頼性があるシステムになる。
# 唯一気を付けるのは grub の upgrade。たまーに再起動しなくなる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
うむ。そいつは間違っている (スコア:1)
「srpm から一発ビルドしたものを配布するのが常識」であるっっ (断言っ!)
いや、複数の同じプロセッサのマシンの場合はね。srpm を作るときに、特定のCPU用の最適化を限界までかけたオプションを付けてビルド。できた rpm を配布するのさ。
大抵のソースは、プログラムを除去したり更新したりすることを考えていないので、たとえ source からビルドする場合でも srpm を作り、rpm にしてからインストールした方がよい。
.
あとは必要なパフォーマンスとのご相談だよね。CPUやメモリ消費量に対して、srpm を作ってそこからビルドする手間が見合うか、と考えればよい。世の中に出回っているrpmは、セキュリティも含めてほぼ100%全自動で対応してくれる(定期的に update さえしていればよい)。update ができない/怖くてやれない/プロプラエタリなソフトが追従してくれないので動かなくなる とかいうのでなければ、何も考えずに毎日 yum -y upgrade して、特定の時間帯に shutdown -r した方が、よほど信頼性があるシステムになる。
# 唯一気を付けるのは grub の upgrade。たまーに再起動しなくなる。
fjの教祖様
Re: (スコア:0)