アカウント名:
パスワード:
パフォーマンスやコードの品質に本当に自信があるのなら、ディストリビューターに直接採用するように働きかければ良いような気もするんですが、そういうのはダメなんですかねぇ。本当にパフォーマンスが2倍になるのなら、LinuxベースのNASを出荷してるメーカーなんかがひとつくらい食いつきそうな気がするんですが。
RedHatのカーネルのSRPMを展開すると、オリジナルのカーネルソースに無いpatchが山ほど当たってます(てゆーか、オリジナルのカーネルソースをそのまま使ってるディストリビューションなんて皆無な気がする)。そうしたpatchのような形で個々のディストリビューションやLinuxベースで動いている製品に個別に採用してもらう、ということは不可能ではないと思います。そうやって自らの主張を実証しつつ、仲間を増やすという戦略もアリだと思うんですけど。
カーネルのソースツリーにマージされることって、やっぱり重要なことなんでしょうか?
%% あ、ブランチだから朝飯の後か...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
そろそろLinuxも (スコア:1, 参考になる)
forkとまで行かなくても (スコア:5, 興味深い)
パフォーマンスやコードの品質に本当に自信があるのなら、ディストリビューターに直接採用するように働きかければ良いような気もするんですが、そういうのはダメなんですかねぇ。本当にパフォーマンスが2倍になるのなら、LinuxベースのNASを出荷してるメーカーなんかがひとつくらい食いつきそうな気がするんですが。
RedHatのカーネルのSRPMを展開すると、オリジナルのカーネルソースに無いpatchが山ほど当たってます(てゆーか、オリジナルのカーネルソースをそのまま使ってるディストリビューションなんて皆無な気がする)。そうしたpatchのような形で個々のディストリビューションやLinuxベースで動いている製品に個別に採用してもらう、ということは不可能ではないと思います。そうやって自らの主張を実証しつつ、仲間を増やすという戦略もアリだと思うんですけど。
カーネルのソースツリーにマージされることって、やっぱり重要なことなんでしょうか?
Re:forkとまで行かなくても (スコア:4, 参考になる)
Reiser4はLinuxに難しい問題を投げかけています。が、ディストリビューションやNASが食いついてこないのはこれらの議論とはあまり関係なく、時々Reiser4からまずいバグ [lkml.org]が報告されてるからではないかと。ReiserFSだって不安定だって言われてなかなかディストリビューションに相手にしてもらえなかった過去があります。ファイルシステムの性格上、ext系等と比較して簡単に「安定だ」とかいわれても信じがたいところがありますし。
> やっぱり重要なことなんでしょうか?
本家にマージされないと本家に置き去りにされて使えなくなってしまう恐れがあるんですよ。特にReiser4みたいに堂々とカーネル側が推奨する規格に従ってないものの場合。本家が変更されるたびにパッチ作りなおす、で済めばまだいいですけど、どうにも対応できなくなっちゃう恐れもありますから。
ただ、Ext3からReiserFSに移行してその性能に感動した人間として、Reiser4には頑張ってほしいところですが。
# Reiser4(パッチ)とSquashFS [sourceforge.net](パッチ)と
# UnionFS [am-utils.org](パッチ)で極限までディスクIOを
# 減らしパフォーマンスを高めるのだ
Re:forkとまで行かなくても (スコア:3, 参考になる)
「bugfixにしても新機能にしても、まずはupstreamに入ってからね。」ということです。
そうしないと、ディストロ側のコストが洒落にならないのでしょう。
独自patchがあたっていることもありますが、そういうのは自社でメンテナを抱えていたりするので。
#とはいえ、Xen patchなんかは、入ってたりするんだけど。
Googleブランチ? (スコア:3, 興味深い)
Googleブランチができるのでしょうか
Re:Googleブランチ? (スコア:4, おもしろおかしい)
%% あ、ブランチだから朝飯の後か...
の
Re:Googleブランチ? (スコア:1)
朝ごはんはまだかね (スコア:1)
"Patriotism is the last refuge of a scoundrel." - Samuel Johnson
Re:そろそろLinuxも (スコア:2, おもしろおかしい)
Re:そろそろLinuxも (スコア:2, おもしろおかしい)
# 最後まで言わない
Re:そろそろLinuxも (スコア:1)
#今更某社が拝金主義とかがめついとか批判するつもりはないですが語感が・・・
Re:そろそろLinuxも (スコア:1)
RTLinuxみたいな仕方のforkもあったけど、あれはあれで微妙にGPLv2に引っかかるような感じのライセシングだったので問題はありましたが。
いい加減、GPL v3 CompliemntなBranchとLinus氏の主張に沿ったBranchにわかれてもいい気がします
…特にリバースエンジニアリングが必要なドライバ書くときなんかはGPLv3 Complientな方が都合いいんですけどねぇ。
GPL v2だと曖昧な部分があるんでいっそv3公布と同時にGPL v3を採用してクリアにしておきたいことが出てきてしまうので、今のVanilla KernelがGPL v2に固執してるとややこしいんですよねぇ(;´Д`)
ここまでカーネル本体が高性能かつ複雑になると、ほとんどの部分の流用は避けられないですし、Linux 2.6と同等の物をスクラッチから起こすのも何だか無理があるような(;´Д`)
# GPL v2のコードをGPL v3のコードに流用するときの制限ってあるんでしょうか?
Re:そろそろLinuxも (スコア:1, 参考になる)
当然ですが、GPL2 only なコードを勝手に GPL3 にすることはできません。
Re:そろそろLinuxも (スコア:1, すばらしい洞察)
Re:そろそろLinuxも (スコア:0)