アカウント名:
パスワード:
「ウィルスやハッカーの標的になりやすい」のが嫌であれば、 BSDなOSを使ったほうが良いのでは?
えー、私自身BSDに反対するわけではないんですが、Linuxの場合同じカーネルに複数のディストリビューター(派閥)があるのも利点だと思えます。RedHatが駄目だと思ったらSuSEを使おうとか、ま、そう言う選択ができるのも必要ではないかと。
FreeBSDが駄目だと思ったらOpe
素朴な疑問ですが、世の中の多くの人に、トラブルがkernelにあるのか、それともuserlandにあるのか判断する能力があるのでしょうか? また、Unixではほぼすべてのapplicationについてin-kernelの性能が影響を及ぼすことがどれくらい周知されているのでしょうか? これらがわからないので、distroが選択できるといわれても有り難みが感じられません(あるとしても一時的、限定的なもの)。
逆にいえば、その判断基準を身に付ければ、たとえSolarisのようにsourceから
>ありがたみを激しく感じてる者のひとりです. Debian >がなかったら Linux は使ってません.
いや, ですからここでの話の流れではDebianで良ければRedHatやSUSEはいらないでしょう? じゃあRedHatやSUSEの存在価値は? ってことです.
ですからここでの話の流れではDebianで良ければRedHatやSUSEはいらないでしょう?
なぜ? 選択肢があることはいいことだと思いますけど? Debian のリリーススケジュールのルーズさや、主要ソフトウェアのdeb化がワンテンポ遅れる傾向があることを嫌う人だっているはず。
自分がDebianとNetBSDのユーザなので無理矢理話をBSDに変換してしまうと、「FreeBSDがあるんだからNetBSDやOpenBSDなんかいらない」とは絶対思わないってことです。かつてFreeBSDを使っていて、newconfig vs new-bus の醜い争
選択肢が多いことと、それらの間で技術交換ができることが私の頭の中では結びつきません。例えばFreeBSDのSMPngはBSD/OS 5.0を参考にしていますが、実際に手を動かしてみると(私だけでなく、関わっている人の多くの結果に共通して)BSD/OSとはまるで違ったものができ上がってしまいます。私が関わっているprocess groupやsessionについても、全くもってFreeBSD独自の実装をせざるを得ませんでした(御存知ないでしょうが、BSD/OSのsession managementはSVR4-basedです。BSD-basedな方法ではありません!)。
日本だとどうしても「kernel屋 == デバ
選択肢が多いことと、それらの間で技術交換ができることが私の頭の中では結びつきません。
そりゃ結びつかないんだから当然でしょう。例えば、ApacheとIISはいずれもHTTPサーバの選択肢ではありますが、これらの間でサーバサイドスクリプトの技術交換ができるかといえば、一部できないこともないけど、そんなことハナっから期待なんかしないでしょ。だからこそ、選
長々と書いたのは、「技術交換が理想である」とあまりに簡単に片付けているので、それが決して簡単にできるものではないという実例として出しました。case studyにはすぎませんが、実際に使える事物や方法論を抜きにしては「○○ができる」「場合がある」といっても実感が沸かないんです。
長々と書いたのは、「技術交換が理想である」とあまりに簡単に片付けているので
「技術交換が理想である」と書いたつもりはないんだが、ひょっとして「選択肢を残しつつお互いのいいところを取り入れ合ってみんながどんどんよくなっていくのが理想」と書いたところを捉えてそう言われるのかな。
newconfig vs new-bus 云々を持ち出したのが誤解の遠因になっているのかもしれないけれど、「ドライバを融通しようよ」とか「ほげほげの実装をこっちに持ってきて」という意味を込めたつもりはないです。もちろん、そうできりゃそれこそ理想的だけど、技術的な理由でなかなかそうもいかないのも理解できてるつもり。どちらかといえば、例えばWebサービスのプラットフォームとしてのBSDの選択肢があってよかったね、というところですね。「お互いのいいところを取り入れ合う」という記述の時念頭にあったのは、BSDにおけるOpen Package [openpackages.org]だとか、最近rpmをバックエンドにするaptが出てきたことあたりです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
なぜにLinux? (スコア:2, 興味深い)
BSDなOSを使ったほうが良いのでは? 確か、日本のある公共団体
の施設では、上記の理由でオールBSDで運用していたぞ。
やはり、あまりにもマイナー路線なのも話題不足で駄目なのだろうか…
Re:なぜにLinux? (スコア:2)
えー、私自身BSDに反対するわけではないんですが、Linuxの場合同じカーネルに複数のディストリビューター(派閥)があるのも利点だと思えます。RedHatが駄目だと思ったらSuSEを使おうとか、ま、そう言う選択ができるのも必要ではないかと。
FreeBSDが駄目だと思ったらOpe
Re:なぜにLinux? (スコア:2)
素朴な疑問ですが、世の中の多くの人に、トラブルがkernelにあるのか、それともuserlandにあるのか判断する能力があるのでしょうか? また、Unixではほぼすべてのapplicationについてin-kernelの性能が影響を及ぼすことがどれくらい周知されているのでしょうか? これらがわからないので、distroが選択できるといわれても有り難みが感じられません(あるとしても一時的、限定的なもの)。
逆にいえば、その判断基準を身に付ければ、たとえSolarisのようにsourceから
Re:なぜにLinux? (スコア:0)
>有り難みが感じられません(あるとしても一時的、限定的なもの)。
ありがたみを激しく感じてる者のひとりです. Debian がなかったら
Linux は使ってません.
Debian が ほげほげBSDで動くんなら, そっちに移行するかも
しれないです.
# 所詮私は寄生虫
Re:なぜにLinux? (スコア:1)
>ありがたみを激しく感じてる者のひとりです. Debian
>がなかったら Linux は使ってません.
いや, ですからここでの話の流れではDebianで良ければRedHatやSUSEはいらないでしょう? じゃあRedHatやSUSEの存在価値は? ってことです.
Re:なぜにLinux? (スコア:2)
なぜ? 選択肢があることはいいことだと思いますけど? Debian のリリーススケジュールのルーズさや、主要ソフトウェアのdeb化がワンテンポ遅れる傾向があることを嫌う人だっているはず。
自分がDebianとNetBSDのユーザなので無理矢理話をBSDに変換してしまうと、「FreeBSDがあるんだからNetBSDやOpenBSDなんかいらない」とは絶対思わないってことです。かつてFreeBSDを使っていて、newconfig vs new-bus の醜い争
技術交換は実は難しい (スコア:2)
選択肢が多いことと、それらの間で技術交換ができることが私の頭の中では結びつきません。例えばFreeBSDのSMPngはBSD/OS 5.0を参考にしていますが、実際に手を動かしてみると(私だけでなく、関わっている人の多くの結果に共通して)BSD/OSとはまるで違ったものができ上がってしまいます。私が関わっているprocess groupやsessionについても、全くもってFreeBSD独自の実装をせざるを得ませんでした(御存知ないでしょうが、BSD/OSのsession managementはSVR4-basedです。BSD-basedな方法ではありません!)。
日本だとどうしても「kernel屋 == デバ
Re:技術交換は実は難しい (スコア:2)
そりゃ結びつかないんだから当然でしょう。例えば、ApacheとIISはいずれもHTTPサーバの選択肢ではありますが、これらの間でサーバサイドスクリプトの技術交換ができるかといえば、一部できないこともないけど、そんなことハナっから期待なんかしないでしょ。だからこそ、選
Re:技術交換は実は難しい (スコア:2)
長々と書いたのは、「技術交換が理想である」とあまりに簡単に片付けているので、それが決して簡単にできるものではないという実例として出しました。case studyにはすぎませんが、実際に使える事物や方法論を抜きにしては「○○ができる」「場合がある」といっても実感が沸かないんです。
Re:技術交換は実は難しい (スコア:2)
「技術交換が理想である」と書いたつもりはないんだが、ひょっとして「選択肢を残しつつお互いのいいところを取り入れ合ってみんながどんどんよくなっていくのが理想」と書いたところを捉えてそう言われるのかな。
newconfig vs new-bus 云々を持ち出したのが誤解の遠因になっているのかもしれないけれど、「ドライバを融通しようよ」とか「ほげほげの実装をこっちに持ってきて」という意味を込めたつもりはないです。もちろん、そうできりゃそれこそ理想的だけど、技術的な理由でなかなかそうもいかないのも理解できてるつもり。どちらかといえば、例えばWebサービスのプラットフォームとしてのBSDの選択肢があってよかったね、というところですね。「お互いのいいところを取り入れ合う」という記述の時念頭にあったのは、BSDにおけるOpen Package [openpackages.org]だとか、最近rpmをバックエンドにするaptが出てきたことあたりです。