アカウント名:
パスワード:
＞PHP 5.4やMySQL（MariaDB） 5.5、Python 2.7といった、現状の追随に胸なでおろしている方が多いのではないか、と思う。PHPは5.2系じゃないのか……
5.3系は5.2系以前と互換性がないから、まだ上げられないってシステム多い希ガス。#だからPHPなんて使うなとあれほど orz
LAMPをソースからビルドせずRPMに頼ってるあたりの意識のほうが怖い
???｢RPMを使うのは中学生まで｣
それだとRHEL使う意味ないじゃん
お子様の工作じゃあるまいし、あれこれ自前ビルドしまくったツギハギ自己満足な環境のほうが圧倒的に恐ろしい。自分の手を離れ、自分の部署の手を離れ、自分の会社の手を離れたときに安全に引き継げる可能性低すぎるだろ。何のためにディストリビューターが古いパッケージの保守に膨大な手間をかけているのか理解したほうがいい。
古いパッケージは結局古いパッケージなのです。RedHat5搭載のgrepが-oオプションをまともに扱えないバグがいつまで経っても解消されないこととか、保守といってもセキュリティに問題があるといって騒ぎになれば修正されるくらいで、そうでなければほったらかしになっているものが多々あります。
コンパイラを一度も動かさず、身元不明のパッケージを使うこともなく、システム標準のパッケージだけで運用されているシステムって、本当にどれだけあるんでしょうか。
>古いパッケージは結局古いパッケージなのです。RedHat5搭載のgrepが-oオプションをまともに扱えない>バグがいつまで経っても解消されないこととか、
保守契約のあるユーザーがBug修正をRed Hatに依頼しても、Red Hatが修正してくれないと言うことですか?
どう見ても、セキュリティホール以外も大量に修正されているし、騒ぎになってないやつも修正されているようにしか見えないんですが・・・ちゃんと契約してる？https://rhn.redhat.com/errata/rhel-server-errata.html [redhat.com]
そそそ。自前コンパイルしたとして、そうして出来上がったバイナリが安全であるとどうして自分が確認できるのか、どうして後任が確認してきちんと運用していけるのか。そういうシステムが10、20あったとしてどうやって保守していくのか。もちろんポリシ上、要件上どうしても必要なところは手をかければいいけれど。
ベンダ保守を受けられないのなら、自前で何とかしないといけないんだよねぇー。
セキュリティーホールが見つかるたびにビルドして入れ替えるの？
・・・ちょっと耐えられなそうパッケージ管理されていれば、いいタイミングでパッチ出してくれるし検証終わったらyum update xxxだけなんだけど。だめなん？
この場合のLがどこまで含まれるのかに興味があります。
僕も時々悩むのだけど。yumやaptでインストールしても古すぎるものしか無い時は、使いたいものがあるリポジトリを探すけども、無い場合は ./configure && makeしてしまう。最初からソースビルドはしなくなった。。CentOS4.9があと２つ。。そろそろ退役してもらう予定。。。はぁ
でもそういう状況の起こりやすさは、ほぼリポジトリのパッケージ量に依存し、RedHat系の弱い部分だよね。最初にDebian使ったときは天国かと思った。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
現状の追随？ (スコア:0)
＞PHP 5.4やMySQL（MariaDB） 5.5、Python 2.7といった、現状の追随に胸なでおろしている方が多いのではないか、と思う。
PHPは5.2系じゃないのか……
5.3系は5.2系以前と互換性がないから、まだ上げられないってシステム多い希ガス。
#だからPHPなんて使うなとあれほど orz
Re:現状の追随？ (スコア:0)
LAMPをソースからビルドせずRPMに頼ってるあたりの意識のほうが怖い
Re:現状の追随？ (スコア:2)
???｢RPMを使うのは中学生まで｣
Re:現状の追随？ (スコア:1)
それだとRHEL使う意味ないじゃん
Re:現状の追随？ (スコア:1)
お子様の工作じゃあるまいし、あれこれ自前ビルドしまくったツギハギ自己満足な環境のほうが圧倒的に恐ろしい。
自分の手を離れ、自分の部署の手を離れ、自分の会社の手を離れたときに安全に引き継げる可能性低すぎるだろ。
何のためにディストリビューターが古いパッケージの保守に膨大な手間をかけているのか理解したほうがいい。
Re: (スコア:0)
古いパッケージは結局古いパッケージなのです。RedHat5搭載のgrepが-oオプションをまともに扱えないバグがいつまで経っても解消されないこととか、保守といってもセキュリティに問題があるといって騒ぎになれば修正されるくらいで、そうでなければほったらかしになっているものが多々あります。
コンパイラを一度も動かさず、身元不明のパッケージを使うこともなく、システム標準のパッケージだけで運用されているシステムって、本当にどれだけあるんでしょうか。
Re: (スコア:0)
>古いパッケージは結局古いパッケージなのです。RedHat5搭載のgrepが-oオプションをまともに扱えない
>バグがいつまで経っても解消されないこととか、
保守契約のあるユーザーがBug修正をRed Hatに依頼しても、Red Hatが修正してくれないと言うことですか?
Re: (スコア:0)
どう見ても、セキュリティホール以外も大量に修正されているし、騒ぎになってないやつも修正されているようにしか見えないんですが・・・
ちゃんと契約してる？
https://rhn.redhat.com/errata/rhel-server-errata.html [redhat.com]
Re: (スコア:0)
そそそ。
自前コンパイルしたとして、そうして出来上がったバイナリが安全であるとどうして自分が確認できるのか、どうして後任が確認してきちんと運用していけるのか。そういうシステムが10、20あったとしてどうやって保守していくのか。もちろんポリシ上、要件上どうしても必要なところは手をかければいいけれど。
ベンダ保守を受けられないのなら、自前で何とかしないといけないんだよねぇー。
Re: (スコア:0)
セキュリティーホールが見つかるたびにビルドして入れ替えるの？
・・・ちょっと耐えられなそう
パッケージ管理されていれば、いいタイミングでパッチ出してくれるし
検証終わったらyum update xxxだけなんだけど。だめなん？
Re: (スコア:0)
この場合のLがどこまで含まれるのかに興味があります。
Re: (スコア:0)
僕も時々悩むのだけど。yumやaptでインストールしても古すぎるものしか無い時は、使いたいものがあるリポジトリを探すけども、
無い場合は ./configure && makeしてしまう。最初からソースビルドはしなくなった。。
CentOS4.9があと２つ。。そろそろ退役してもらう予定。。。はぁ
Re: (スコア:0)
でもそういう状況の起こりやすさは、ほぼリポジトリのパッケージ量に依存し、RedHat系の弱い部分だよね。
最初にDebian使ったときは天国かと思った。