アカウント名:
パスワード:
私が直接ではありませんが、聞いたことがあります。友人の知り合いの彼氏が言っていたそうです。
＞A. OSデフォルトのRPMをそのまま使うのは小学生まで
だったら、いっそLFSでやったらいいじゃない。
カーネルもパッケージもTarBallから全部手でビルドする。バージョンアップしないでいいよ別に。
セキュリティホール見つかったら、手でパッチ当てて直したらいい。
ディストリビュータに一切頼らないでやってね。
ポインタでは無いけど、defaultのrpmで困る事って結構無い?最近僕が自分でcompileしたのは、server用途のものじゃなくてeditorだけど、vim。
組込みscriptとして使える言語が"ruby" or "python"の選択になってて、"ruby"も"python"も"lua"も使えて、xterm_clipboardが使えるようになっているcuiのvimは、rpmやyumでは入らなくて、自分でcompileしました。
ましてや、server aplなら、使用用途がガチ決まりしている事も多く、余計な物を外したり、特殊なcompile option指定してとかって普通にやると思うけど。だって色々な用途で使えるという汎用性がいらないんだもん。それより性能や特殊な機能を取りたい事なんて、往々にしてある。
defaultのpackage systemで入るのは、あくまで、万人がそれなりに使える間口の広い物であって、用途をしぼった物は入らない。それは、動けば良いやの小学生までは許されるけど、ある一定のクオリティを求められる中学生以上は許されないでしょう。（というギャグ)
ポインタでは無いけど、defaultのrpmで困る事って結構無い?
あるとは思います。 しかしああやって、わざわざ会社のブログでディストリビューションの開発者を煽る必要があるのかってところに疑問があります。
私も勉強がてら開発鯖をLFSベースで組んだことがありました確かに勉強にはなったし、シンプルな構成で作りあがったことに満足はしたのですが、ビルド時間も含めるとさすがに工数の無駄だろうという結論になってRHELやCentOS、Debian、Ubuntuなどメジャーどころに落ち着きました依存関係まで解決してくれるのは何だかんだいって楽ですわ
gccとかも自分たちでビルドして検証までしてるのか。凄いね!
常に自分がアタッチ、コミットできるシステムであればおっしゃるような対応は可能でしょう。特にvimみたいな独立性の高いアプリケーションなら、なおさらです。
しかし、山のようにサーバーがあり、どれに何が入っているかわからないような状況がありうる場合、独自ビルドによる環境に慣れきるのはかえってストレスをためてしまう原因になりかねません。
業種にもよるかと思いますが、「標準的な」構成に対応できるように常に気を払う（キーボードなどにしてもそうです）ことで避けられる問題は多いと思います。
文脈を察するに、前の記事 [mixi.co.jp]にある
サーバ用途として安定的かつハイパフォーマンスで使うために、特にKernelについては、標準で提供されるバイナリをそのまま使わず、独自のConfigでビルドしています。
という記載に対する、
Q. 独自でビルドとか工数もったいない。
という質問の答えが
A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。
ということなんじゃないかな。mixiを支えるサーバ用途としてカーネル周りの独自ビルドはやる価値があると思う。
# 折角注目を集めている記事なんだから、誤解を招くようなスラングで回答しなきゃいいのに
どうせどんな回答でも、このタレコミのように文脈無視され歪曲されて別の意味にされるのが目に見えているからマトモに相手してないんだろうさ
なぜかベンダから供給されているパッケージを頑なに使わない方々はいらっしゃるようです。理由を聞いてみたこともあるのですが、これといった理由は無いようでした。ちょっとした不思議です。
バイナリパッケージを[信用しない/使わない]人なら結構いたんじゃないかな。EWSが使い物になり始めた頃のUNIXを採用したワークステーションはマシンごとの差異が大きく、採用されているCPUからして、もう何種類もあったわけで。SPARCとかMIPSとかPA-RISCとか、会社の数だけCPUがあるような感じだったし。そうなると、オープンソースなソフトウェアなら利用者が最新版のソースコードを頑張って移植して、自前でコンパイルするのが基本だったと思います。ベンダのパッケージは古くて最新機能が使えない。
しかし、後にx86系のLinux系ディストリビューションが大きく普及した頃には、普通にバイナリパッケージを配布するようになりましたね。例えばDebianなんて、バイナリパッケージだけでDVDが必要な大きさでしたから、もう、各自コンパイルの手間を省いてくれるんだし、バイナリだけ配布してもいいかなと思えました。
むかぁ～し、むかぁ～し、フリーソフトをバイナリで配布するパソコンの文化（MS-DOS時代）はけしからんと言ってた人がいたなぁ（遙か彼方を見る目）
FSFの教祖様の教えに従えば、ソースコードの公開されていないソフトウェアは悪、なので。何か改造したくてもパッチあてるのが大変なのでね。さらに言うと、内部でどんなコードが動いてるのか分からないのは怖い、ということもあるかと。
だから、ざっとソースに目を通して変なところがなく、さらに手元のコンパイラを通して出てきたバイナリならまぁ安心？いや、コンパイラがバイナリ提供だとそこに仕込みが入ってる可能性もあるわけなんだけど。 [ebimemo.net]さらに言うと、陰険なコードコンテスト [srad.jp]といったものも存在するのだけど。
きっと、将来に渡って、猫も杓子もソースコードを読む時代は来ないのだろうなぁ。道路標識みたいに誰でも理解できるようになってないから。
バイナリだけでソース出さないからじゃないの？
インターネットからの接続を直接待ち受けるようなソフトウェアについては、パッチ公開～ディストリrpm公開の（数日の）タイムラグを恐れて自力ビルドする例を見かけます。（当然、パッチが出たら即座に検証できる人員と環境があることが前提）
これはあるかも知れないけど、あっても特定のパッケージのみかなでも前任者が頑張って独自ビルドを使ってたりすると、後で困ることもあるしなぁ(^^;
それと、その他大勢のパッケージまで自分でテストする手間かける暇な人は少ないでしょうwww
あと負荷テストしたら、独自ビルドの方がパフォーマンスが悪かったことがあって・・・原因調べる努力するよりもそのままデフォルトを使う方がいいよねってことになったことはあった。
ソースが公開されてても、そのソースをコンパイルしたバイナリなのかどうかは分からないなにか組み込まれているかもしれない・・いうことを考えているんじゃないですかね大学にいた先輩とかそんなことを言ってましたが
自分でビルドしても、ソースを自分で確認してないんじゃ結局同じ事だと思う、と突っ込んだら「公開されてるソースは誰でも見れるから変なもの組み込まれてないだろ」との答え
結局他人をどこまで信用して利便性とトレードするかのボーダーの違いでしかないかなぁ
内容をしっかり把握して、自分の用途にあっていればそのまま使っているんじゃないかな
小学生まで～のくだりは初めてみましたが、RPMで提供さているものでもコンパイルオプションを変えたりパッチ当ててビルドし直すのはよくあると思います。
rpm -ivh foovar-1.0.src.rpmパッチを置いて .specファイルを書き換えるrpmbuild -ba ~/rpmbuild/SPECS/foovar.specみたいな
ただ、ディストリビューションのパッケージよくできてるしデフォルトのモノ使ったほうが楽なのは同意。
同意ですね。
自分がヌルい管理者で、自分がわからないからだっていうのは確かにあります。ですが、その自分がいなくなったあと、スーパーSEが入って超カスタマイズを自在にやってくれるのだろうか。さらに、そのスーパーSEが抜けたあとに、またしても都合よくスーパーSEが入ってくれるのだろうか。そして、それが続いてくれるのか、そう考えると、デフォルトのパッチを待てない可能性がある一部のパッケージ以外は自分でコンパイルする気にはなれませんね。
よほど社内の運用体制に自信があって、かつ、その運用体制そのものを長期にわたり維持できると言う確信があるならともかく、プロとしての態度ではなく、ただのオタクが屁理屈をこねているようにしか思えません。
それについてはビルド手順をドキュメント化しておけば問題ないでしょう。
mixi程のサービスを提供してる会社が、自前ビルドで運用できる程度の人を「スーパーSE」って言ってしまうのは逆にプロ意識に欠けると思いますが。
> よほど社内の運用体制に自信があって、かつ、その運用体制そのものを長期にわたり維持できると言う確信があるならともかく、プロとしてサービスを提供する会社なら、その程度のことができて当然でしょう。
ソースから入れた方が必要最小限な構成で構築できるので安心できますけどね。ただ、すべてソースからビルドするのはなかなか難しいので、次善の策としてベンダが出しているパッケージを選択してます。
> ベンダと多数によってテストされている、 デフォルトのディストロとパッケージシステムを信頼するのが最善と想像します。しょっちゅうアップデートされてるので、そう安心できるものでもないかと。
風の息づかい感じてれば、気配があったはず
私はRPMを使うのは小学生まで
./configure --help | less./configure hogehoge; make sudo make install
をするのが大人と聞きましたが(w
make world 一発だろ常識的に考えて、と勝ち誇るのは悪魔教
個人的にはmake clean./configure hogehogemake dependmakemake testmake installかな
それはさすがにビルド用スクリプトを書いた方がいいんでは。
いや、さすがにLAMPくらいはビルドしてないと自由度低すぎるじゃないですかね安定性や簡便性、管理者マニュアルの簡素化などと引換にサーバのパフォーマンスを引き出せない慣れたOS(枯れたではない)とRPMの設定できる範囲でしかチューニングしない方針で、あとは設備投資でカバーするというのであればそれはそれで否定はしないけど独自FSを開発してOSすら鍛錬していく効率主義的なGoogleなどの方針とは真逆の運用ではありますね
ビルドとかカスタマイズとかすると、その部分のサポートが受けられなくなるという理由で、そういうカスタマイズは原則不可とお客さんから言われたことならある。
まあ自分でサポートする技術も人もなく、外部に開発もOSサポートも丸投げできる金のある会社限定の話だけど、
ポスグレ使う時点で・・・
派生ネタの「イージーモードが許されるのは(ry」の方かもしれないよ。
さすが、エロマンガマイスターともなると普通の人は知りもしないようなエロマンガのセリフにまで詳しくて聞かれもしないのに知っていることを自慢げに語りだすんですね。
「普通の人は知りもしないようなエロマンガ」だと何故わかったのw？
>「普通の人は知りもしないようなエロマンガ」これは、1. エロマンガのうち、普通の人は知りもしないようなもの2. エロマンガというのは、一般的に普通の人は知りもしないようなものという2通り（限定/説明でいいのかな）に解釈できますが、
>>さすが、エロマンガマイスターともなると普通の人は知りもしないようなエロマンガのセリフにまで詳しくて聞かれもしないのに知っていることを自慢げに語りだすんですね。の文脈では1かｗ
デフォルトのrpm使いたくないならだったらFreeBSDを使ってガリガリと自前の環境構築しろと。
バージョンの問題（最新を使いたい、ディストロのパッチがあたってるバージョン番号から状況がわからん）、コンパイルオプションの問題、この2点で自前ビルドとパッケージを使い分けてるよ。
あとツールに関して言えばrpmでインストールするとシステム全体に影響が及ぶけど,自前ビルドのツールはユーザーホームにでも置いておくことができるメリットも.バージョンアップ時の検証はこれでやっちゃうことができるのはメリットかもしれない.
私の場合(ubuntuですけど)複数のバージョンを使いわけなきゃいけないツールは,そうやってそれぞれユーザー領域に飼ってますね(そういう用途ならalternative使えっていう話はあるけど)
あと自前でビルドできるようになってると、OSやディストロ変えてもほぼ手順統一できるというメリットもある。
本当にベンダと多数がテストしているんだろうか? ただなんとなく使っている範囲ではエラーが起らなかったからOKにしていないだろうかと疑問に思っています. 本当にソースコードが検証されたのか, 変なパッチの当てすぎいじりすぎがないのか?
RedHatではOpenSSLでさえ妙なパッケージが使用されているようですが,皆さんは気づいていましたか?
http://ya.maya.st/d/201003a.html#d20100308 [ya.maya.st]
そうかもしれんけど、運用コストを考えるとそう言ってられない場合もあるわな。Windows Serverで運用ができる人間の単価と、Linuxで同程度の運用ができる人間の単価は明らかに違う。
最善かはともかく、「みんなが使ってるから使う」というのは、至極一般的な考え方だと思いますよ。なんでわざわざ設定を変えて、「動かないかもしれない」ということを試そうとするのですか？趣味でやるならともかく、仕事(運用)で？
ところで、mixiはそういったことに対して、人的リソースや機械的リソースを割けるほど余裕があるのに、RHELにはお金を掛けたくないっていうのは矛盾のような。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:5, おもしろおかしい)
私が直接ではありませんが、聞いたことがあります。
友人の知り合いの彼氏が言っていたそうです。
Re: (スコア:0)
＞A. OSデフォルトのRPMをそのまま使うのは小学生まで
だったら、いっそLFSでやったらいいじゃない。
カーネルもパッケージもTarBallから全部手でビルドする。
バージョンアップしないでいいよ別に。
セキュリティホール見つかったら、手でパッチ当てて直したらいい。
ディストリビュータに一切頼らないでやってね。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:3)
ポインタでは無いけど、defaultのrpmで困る事って結構無い?
最近僕が自分でcompileしたのは、server用途のものじゃなくてeditorだけど、vim。
組込みscriptとして使える言語が"ruby" or "python"の選択になってて、"ruby"も"python"も"lua"も使えて、xterm_clipboardが使えるようになっているcuiのvimは、rpmやyumでは入らなくて、自分でcompileしました。
ましてや、server aplなら、使用用途がガチ決まりしている事も多く、余計な物を外したり、特殊なcompile option指定してとかって普通にやると思うけど。だって色々な用途で使えるという汎用性がいらないんだもん。それより性能や特殊な機能を取りたい事なんて、往々にしてある。
defaultのpackage systemで入るのは、あくまで、万人がそれなりに使える間口の広い物であって、用途をしぼった物は入らない。それは、動けば良いやの小学生までは許されるけど、ある一定のクオリティを求められる中学生以上は許されないでしょう。（というギャグ)
安易なAC発言反対運動中
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
ポインタでは無いけど、defaultのrpmで困る事って結構無い?
あるとは思います。 しかしああやって、わざわざ会社のブログでディストリビューションの開発者を煽る必要があるのかってところに疑問があります。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
lsとかrmとかもパッケージを使わずに、全部自分たちで検証してイチから構築するぜ！なんて会社なのかしらん。mixiってそんなにヒマなのか？
Re: (スコア:0)
私も勉強がてら開発鯖をLFSベースで組んだことがありました
確かに勉強にはなったし、シンプルな構成で作りあがったことに満足はしたのですが、ビルド時間も含めるとさすがに工数の無駄だろうという結論になってRHELやCentOS、Debian、Ubuntuなどメジャーどころに落ち着きました
依存関係まで解決してくれるのは何だかんだいって楽ですわ
Re: (スコア:0)
gccとかも自分たちでビルドして検証までしてるのか。
凄いね!
Re: (スコア:0)
常に自分がアタッチ、コミットできるシステムであればおっしゃるような対応は可能でしょう。
特にvimみたいな独立性の高いアプリケーションなら、なおさらです。
しかし、山のようにサーバーがあり、どれに何が入っているかわからないような状況がありうる場合、
独自ビルドによる環境に慣れきるのはかえってストレスをためてしまう原因になりかねません。
業種にもよるかと思いますが、「標準的な」構成に対応できるように常に気を払う（キーボードなどにしてもそうです）ことで
避けられる問題は多いと思います。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:3, すばらしい洞察)
文脈を察するに、前の記事 [mixi.co.jp]にある
サーバ用途として安定的かつハイパフォーマンスで使うために、特にKernelについては、標準で提供されるバイナリをそのまま使わず、独自のConfigでビルドしています。
という記載に対する、
Q. 独自でビルドとか工数もったいない。
という質問の答えが
A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。
ということなんじゃないかな。mixiを支えるサーバ用途としてカーネル周りの独自ビルドはやる価値があると思う。
# 折角注目を集めている記事なんだから、誤解を招くようなスラングで回答しなきゃいいのに
Re: (スコア:0)
どうせどんな回答でも、このタレコミのように文脈無視され歪曲されて別の意味にされるのが目に見えているからマトモに相手してないんだろうさ
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
なぜかベンダから供給されているパッケージを頑なに使わない方々はいらっしゃるようです。
理由を聞いてみたこともあるのですが、これといった理由は無いようでした。
ちょっとした不思議です。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
バイナリパッケージを[信用しない/使わない]人なら結構いたんじゃないかな。
EWSが使い物になり始めた頃のUNIXを採用したワークステーションは
マシンごとの差異が大きく、採用されているCPUからして、もう何種類もあったわけで。
SPARCとかMIPSとかPA-RISCとか、会社の数だけCPUがあるような感じだったし。
そうなると、オープンソースなソフトウェアなら利用者が最新版のソースコードを頑張って移植して、
自前でコンパイルするのが基本だったと思います。ベンダのパッケージは古くて最新機能が使えない。
しかし、後にx86系のLinux系ディストリビューションが大きく普及した頃には、
普通にバイナリパッケージを配布するようになりましたね。
例えばDebianなんて、バイナリパッケージだけでDVDが必要な大きさでしたから、
もう、各自コンパイルの手間を省いてくれるんだし、バイナリだけ配布してもいいかなと思えました。
Re: (スコア:0)
むかぁ～し、むかぁ～し、フリーソフトをバイナリで配布するパソコンの文化（MS-DOS時代）はけしからんと言ってた人がいたなぁ（遙か彼方を見る目）
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
FSFの教祖様の教えに従えば、ソースコードの公開されていないソフトウェアは悪、なので。
何か改造したくてもパッチあてるのが大変なのでね。さらに言うと、内部でどんなコードが
動いてるのか分からないのは怖い、ということもあるかと。
だから、ざっとソースに目を通して変なところがなく、
さらに手元のコンパイラを通して出てきたバイナリならまぁ安心？
いや、コンパイラがバイナリ提供だとそこに仕込みが入ってる可能性もあるわけなんだけど。 [ebimemo.net]
さらに言うと、陰険なコードコンテスト [srad.jp]といったものも存在するのだけど。
きっと、将来に渡って、猫も杓子もソースコードを読む時代は来ないのだろうなぁ。
道路標識みたいに誰でも理解できるようになってないから。
Re: (スコア:0)
バイナリだけでソース出さないからじゃないの？
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
インターネットからの接続を直接待ち受けるようなソフトウェアについては、パッチ公開～ディストリrpm公開の（数日の）タイムラグを恐れて自力ビルドする例を見かけます。
（当然、パッチが出たら即座に検証できる人員と環境があることが前提）
Re: (スコア:0)
これはあるかも知れないけど、あっても特定のパッケージのみかな
でも前任者が頑張って独自ビルドを使ってたりすると、後で困ることもあるしなぁ(^^;
それと、その他大勢のパッケージまで自分でテストする手間かける暇な人は少ないでしょうwww
あと負荷テストしたら、独自ビルドの方がパフォーマンスが悪かったことがあって・・・原因調べる努力するよりもそのままデフォルトを使う方がいいよねってことになったことはあった。
Re: (スコア:0)
ソースが公開されてても、そのソースをコンパイルしたバイナリなのかどうかは分からない
なにか組み込まれているかもしれない・・いうことを考えているんじゃないですかね
大学にいた先輩とかそんなことを言ってましたが
自分でビルドしても、ソースを自分で確認してないんじゃ結局同じ事だと思う、と突っ込んだら
「公開されてるソースは誰でも見れるから変なもの組み込まれてないだろ」
との答え
結局他人をどこまで信用して利便性とトレードするかのボーダーの違いでしかないかなぁ
Re: (スコア:0)
内容をしっかり把握して、自分の用途にあっていればそのまま使っているんじゃないかな
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
小学生まで～のくだりは初めてみましたが、RPMで提供さているものでもコンパイルオプションを変えたりパッチ当ててビルドし直すのはよくあると思います。
rpm -ivh foovar-1.0.src.rpm
パッチを置いて .specファイルを書き換える
rpmbuild -ba ~/rpmbuild/SPECS/foovar.spec
みたいな
ただ、ディストリビューションのパッケージよくできてるしデフォルトのモノ使ったほうが楽なのは同意。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
同意ですね。
自分がヌルい管理者で、自分がわからないからだっていうのは確かにあります。
ですが、その自分がいなくなったあと、スーパーSEが入って超カスタマイズを自在にやってくれるのだろうか。
さらに、そのスーパーSEが抜けたあとに、またしても都合よくスーパーSEが入ってくれるのだろうか。
そして、それが続いてくれるのか、そう考えると、デフォルトのパッチを待てない可能性がある一部のパッケージ以外は自分でコンパイルする気にはなれませんね。
よほど社内の運用体制に自信があって、かつ、その運用体制そのものを長期にわたり維持できると言う確信があるならともかく、プロとしての態度ではなく、ただのオタクが屁理屈をこねているようにしか思えません。
Re: (スコア:0)
それについてはビルド手順をドキュメント化しておけば問題ないでしょう。
Re: (スコア:0)
mixi程のサービスを提供してる会社が、自前ビルドで運用できる程度の人を「スーパーSE」って言ってしまうのは逆にプロ意識に欠けると思いますが。
> よほど社内の運用体制に自信があって、かつ、その運用体制そのものを長期にわたり維持できると言う確信があるならともかく、
プロとしてサービスを提供する会社なら、その程度のことができて当然でしょう。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
ソースから入れた方が必要最小限な構成で構築できるので安心できますけどね。
ただ、すべてソースからビルドするのはなかなか難しいので、次善の策としてベンダが出しているパッケージを選択してます。
> ベンダと多数によってテストされている、 デフォルトのディストロとパッケージシステムを信頼するのが最善と想像します。
しょっちゅうアップデートされてるので、そう安心できるものでもないかと。
Re: (スコア:0)
風の息づかい感じてれば、気配があったはず
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
私はRPMを使うのは小学生まで
./configure --help | less
./configure hogehoge;
make
sudo make install
をするのが大人と聞きましたが(w
Re: (スコア:0)
make world 一発だろ常識的に考えて、と勝ち誇るのは悪魔教
Re: (スコア:0)
個人的には
make clean
./configure hogehoge
make depend
make
make test
make install
かな
Re: (スコア:0)
それはさすがにビルド用スクリプトを書いた方がいいんでは。
Re: (スコア:0)
いや、さすがにLAMPくらいはビルドしてないと自由度低すぎるじゃないですかね
安定性や簡便性、管理者マニュアルの簡素化などと引換にサーバのパフォーマンスを引き出せない
慣れたOS(枯れたではない)とRPMの設定できる範囲でしかチューニングしない方針で、あとは設備投資でカバーするというのであればそれはそれで否定はしないけど
独自FSを開発してOSすら鍛錬していく効率主義的なGoogleなどの方針とは真逆の運用ではありますね
Re: (スコア:0)
ビルドとかカスタマイズとかすると、その部分のサポートが受けられなくなるという理由で、
そういうカスタマイズは原則不可とお客さんから言われたことならある。
まあ自分でサポートする技術も人もなく、外部に開発もOSサポートも丸投げできる
金のある会社限定の話だけど、
Re: (スコア:0)
ポスグレ使う時点で・・・
Re: (スコア:0)
品性下劣ですと公言しているような物ですよ。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
派生ネタの「イージーモードが許されるのは(ry」の方かもしれないよ。
Re: (スコア:0)
さすが、エロマンガマイスターともなると普通の人は知りもしないようなエロマンガのセリフにまで詳しくて聞かれもしないのに知っていることを自慢げに語りだすんですね。
Re: (スコア:0)
「普通の人は知りもしないようなエロマンガ」だと何故わかったのw？
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:1)
>「普通の人は知りもしないようなエロマンガ」
これは、
1. エロマンガのうち、普通の人は知りもしないようなもの
2. エロマンガというのは、一般的に普通の人は知りもしないようなもの
という2通り（限定/説明でいいのかな）に解釈できますが、
>>さすが、エロマンガマイスターともなると普通の人は知りもしないようなエロマンガのセリフにまで詳しくて聞かれもしないのに知っていることを自慢げに語りだすんですね。
の文脈では1かｗ
-- う～ん、バッドノウハウ？
Re: (スコア:0)
セキュリティーホールが見つかってもベンダーのRPMを待っている人たちのことです。
Re: (スコア:0)
デフォルトのrpm使いたくないならだったらFreeBSDを使ってガリガリと自前の環境構築しろと。
Re: (スコア:0)
バージョンの問題（最新を使いたい、ディストロのパッチがあたってるバージョン番号から状況がわからん）、
コンパイルオプションの問題、
この2点で自前ビルドとパッケージを使い分けてるよ。
Re: A. OSデフォルトのRPMをそのまま使うのは小学生まで、と習った記憶があります。 (スコア:2)
あとツールに関して言えばrpmでインストールするとシステム全体に影響が及ぶけど,
自前ビルドのツールはユーザーホームにでも置いておくことができるメリットも.
バージョンアップ時の検証はこれでやっちゃうことができるのはメリットかもしれない.
私の場合(ubuntuですけど)複数のバージョンを使いわけなきゃいけないツールは,
そうやってそれぞれユーザー領域に飼ってますね
(そういう用途ならalternative使えっていう話はあるけど)
Re: (スコア:0)
あと自前でビルドできるようになってると、OSやディストロ変えてもほぼ手順統一できるというメリットもある。
Re: (スコア:0)
本当にベンダと多数がテストしているんだろうか? ただなんとなく使っている範囲ではエラーが起らなかったからOKにしていないだろうかと疑問に思っています. 本当にソースコードが検証されたのか, 変なパッチの当てすぎいじりすぎがないのか?
RedHatではOpenSSLでさえ妙なパッケージが使用されているようですが,皆さんは気づいていましたか?
http://ya.maya.st/d/201003a.html#d20100308 [ya.maya.st]
Re: (スコア:0)
そうかもしれんけど、運用コストを考えるとそう言ってられない場合もあるわな。
Windows Serverで運用ができる人間の単価と、Linuxで同程度の運用ができる人間の単価は明らかに違う。
Re: (スコア:0)
最善かはともかく、「みんなが使ってるから使う」というのは、至極一般的な考え方だと思いますよ。
なんでわざわざ設定を変えて、「動かないかもしれない」ということを試そうとするのですか？趣味でやるならともかく、仕事(運用)で？
ところで、mixiはそういったことに対して、人的リソースや機械的リソースを割けるほど余裕があるのに、RHELにはお金を掛けたくないっていうのは矛盾のような。
Re: (スコア:0)
Windows Serverを使いこなせるひとのほうが、Linuxをつかいこなせるひとより、貴重と思います
ドキュメントは意味わからないし、オプションの説明ももっとわけわかりません。経験で学習するしかない部分がすごく多いです
逆説的な修辞じゃないですよ。本気でそう思ってます