アカウント名:
パスワード:
パフォーマンスやコードの品質に本当に自信があるのなら、ディストリビューターに直接採用するように働きかければ良いような気もするんですが、そういうのはダメなんですかねぇ。本当にパフォーマンスが2倍になるのなら、LinuxベースのNASを出荷してるメーカーなんかがひとつくらい食いつきそうな気がするんですが。
RedHatのカーネルのSRPMを展開すると、オリジナルのカーネルソースに無いpatchが山ほど当たってます(てゆーか、オリジナルのカーネルソースをそのまま使ってるディストリビューションなんて皆無な気がする)。そうしたpatchのような形で個々のディストリビューションやLinuxベースで動いている製品に個別に採用してもらう、ということは不可能ではないと思います。そうやって自らの主張を実証しつつ、仲間を増やすという戦略もアリだと思うんですけど。
カーネルのソースツリーにマージされることって、やっぱり重要なことなんでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
そろそろLinuxも (スコア:1, 参考になる)
forkとまで行かなくても (スコア:5, 興味深い)
パフォーマンスやコードの品質に本当に自信があるのなら、ディストリビューターに直接採用するように働きかければ良いような気もするんですが、そういうのはダメなんですかねぇ。本当にパフォーマンスが2倍になるのなら、LinuxベースのNASを出荷してるメーカーなんかがひとつくらい食いつきそうな気がするんですが。
RedHatのカーネルのSRPMを展開すると、オリジナルのカーネルソースに無いpatchが山ほど当たってます(てゆーか、オリジナルのカーネルソースをそのまま使ってるディストリビューションなんて皆無な気がする)。そうしたpatchのような形で個々のディストリビューションやLinuxベースで動いている製品に個別に採用してもらう、ということは不可能ではないと思います。そうやって自らの主張を実証しつつ、仲間を増やすという戦略もアリだと思うんですけど。
カーネルのソースツリーにマージされることって、やっぱり重要なことなんでしょうか?
Re:forkとまで行かなくても (スコア:3, 参考になる)
「bugfixにしても新機能にしても、まずはupstreamに入ってからね。」ということです。
そうしないと、ディストロ側のコストが洒落にならないのでしょう。
独自patchがあたっていることもありますが、そういうのは自社でメンテナを抱えていたりするので。
#とはいえ、Xen patchなんかは、入ってたりするんだけど。