アカウント名:
パスワード:
必要なのはportsの手直しじゃなくて、オリジナルのソースコードの変更では?portsでpatchを当ててごまかすよりも可能ならば本体のコードをclangでコンパイルできるように改造したほうがみんなが幸せになれると思うのだけれど。
クロスコンパイル環境の充実とかコンパイルエラー時のわかりやすいエラー出力とかメモリープロファイリング機能とかGPLを忘れてもclangでコンパイルできるようになるメリットは色々とあると思うのだけど。
....あとpccのこともたまには思い出してあげてください ;p
必要なのはportsの手直しじゃなくて、オリジナルのソースコードの変更では?
Portsは23947種類 [freebsd.org]あるが、これらのオープンソース・プロジェクト全てにFreeBSD側から誰かが参加してFreeBSDのclangで一発でコンパイルできるようにしてもらい、かつ今後もそれで開発を継続してもらうのって無理では。
Debianが29050種類 [debian.org]ものパッケージを提供するのは不可能だったのか。知らなかった。
むしろDebianは自分流の方針に合わせるためにパッケージで独自修正入れまくるタイプでは。
だからそういうことが自由にできるライセンスであることが必須なんだな。別にGPLである必要はないが
Debianのパッケージって全部、Debian向けのパッチをオリジナルの方にマージしてオリジナルのプロジェクト側でそれを継続メンテナンスさせた上で、オリジナルのソースコードを一発コンパイルしてパックしただけなんですか?
ったく、そういう話じゃないよ。
メインストリームなLinux+GCC向けコードを、Unixとは言えアーキテクチャの違うBSD+旧GCC向けで動くようにカスタムするのがportsの役目。オリジナルがBSDをサポートしてたらportsでパッチ当てる必要はないけれど、オリジナルがBSDをサポートするよう働きかけて継続的にメンテナンスするのは至難の業。だからpor
その2割なら5,000くらい?まぁ、全部参加するのは現実的ではないけれど、全部patchを当てるのも現実的ではないような。どこかで対応していないportsの大整理が行われ、消されたくない場合はports変えるか本体変えるかの選択を求められるんでしょうね。
PAOを見てたからか本家と関係ないところで開発をすすめるというのはどうも筋が悪いように見えてしまう。まぁ、パッチを送っても「FreeBSDなんて弱小OS知らんな」と無視されることも多々あるだろうけどさ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
やった! (スコア:5, 参考になる)
Portsの手直し? (スコア:0)
必要なのはportsの手直しじゃなくて、オリジナルのソースコードの変更では?
portsでpatchを当ててごまかすよりも可能ならば本体のコードをclangでコンパイルできるように改造したほうがみんなが幸せになれると思うのだけれど。
クロスコンパイル環境の充実とかコンパイルエラー時のわかりやすいエラー出力とかメモリープロファイリング機能とかGPLを忘れてもclangでコンパイルできるようになるメリットは色々とあると思うのだけど。
....あとpccのこともたまには思い出してあげてください ;p
Re:Portsの手直し? (スコア:3)
必要なのはportsの手直しじゃなくて、オリジナルのソースコードの変更では?
Portsは23947種類 [freebsd.org]あるが、これらのオープンソース・プロジェクト全てにFreeBSD側から誰かが参加してFreeBSDのclangで一発でコンパイルできるようにしてもらい、かつ今後もそれで開発を継続してもらうのって無理では。
Re: (スコア:0)
Debianが29050種類 [debian.org]ものパッケージを提供するのは不可能だったのか。知らなかった。
Re: (スコア:0)
むしろDebianは自分流の方針に合わせるためにパッケージで独自修正入れまくるタイプでは。
Re: (スコア:0)
だからそういうことが自由にできるライセンスであることが必須なんだな。別にGPLである必要はないが
Re: (スコア:0)
Debianのパッケージって全部、Debian向けのパッチをオリジナルの方にマージしてオリジナルのプロジェクト側でそれを継続メンテナンスさせた上で、オリジナルのソースコードを一発コンパイルしてパックしただけなんですか?
ったく、そういう話じゃないよ。
メインストリームなLinux+GCC向けコードを、Unixとは言えアーキテクチャの違うBSD+旧GCC向けで動くようにカスタムするのがportsの役目。
オリジナルがBSDをサポートしてたらportsでパッチ当てる必要はないけれど、オリジナルがBSDをサポートするよう働きかけて継続的にメンテナンスするのは至難の業。
だからpor
Re: (スコア:0)
その2割なら5,000くらい?
まぁ、全部参加するのは現実的ではないけれど、全部patchを当てるのも現実的ではないような。
どこかで対応していないportsの大整理が行われ、消されたくない場合はports変えるか本体変えるかの選択を求められるんでしょうね。
PAOを見てたからか本家と関係ないところで開発をすすめるというのはどうも筋が悪いように見えてしまう。まぁ、パッチを送っても「FreeBSDなんて弱小OS知らんな」と無視されることも多々あるだろうけどさ。