日本だとどうしても「kernel屋 == デバドラ屋 or ネットワーク屋」となってしまい、4.4BSD本(今となっては古すぎる)を参考にすれば十分とか、穴埋め式で書いていけばkernelなんて簡単に作れると思い込んでいる人達が目についてしまいます。穴埋めが効かない、問題の定式化から手作りで始めなければならない、しかもOSなんて100や200もあるわけではなく、参考にできるものが少ないところにOS作りの本当の難しさがあります(wfjが386BSD本で述べたことは21世紀になった今でも通じている)。ネットワーク屋さんはある程度意識しているかも知れませんが、デバドラ屋になるといまだにあの赤い本を振り回す人がいて、そんなものが使いものにならない私からすればむなしく見えてしまいます。
なぜに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屋 == デバドラ屋 or ネットワーク屋」となってしまい、4.4BSD本(今となっては古すぎる)を参考にすれば十分とか、穴埋め式で書いていけばkernelなんて簡単に作れると思い込んでいる人達が目についてしまいます。穴埋めが効かない、問題の定式化から手作りで始めなければならない、しかもOSなんて100や200もあるわけではなく、参考にできるものが少ないところにOS作りの本当の難しさがあります(wfjが386BSD本で述べたことは21世紀になった今でも通じている)。ネットワーク屋さんはある程度意識しているかも知れませんが、デバドラ屋になるといまだにあの赤い本を振り回す人がいて、そんなものが使いものにならない私からすればむなしく見えてしまいます。
Re:技術交換は実は難しい (スコア:2)
そりゃ結びつかないんだから当然でしょう。例えば、ApacheとIISはいずれもHTTPサーバの選択肢ではありますが、これらの間でサーバサイドスクリプトの技術交換ができるかといえば、一部できないこともないけど、そんなことハナっから期待なんかしないでしょ。だからこそ、選択肢を換える時には移植だ何だが必要になるわけで。
もちろん、選択肢間で同じ技術を使える場合だってありますが、「場合だってある」というだけのことです。
ところで、後段がこのスレッドとどうからむのかが残念ながらわかりませんでした(前段も引用した1文を除いてはわからない)。どうからむんです?
Re:技術交換は実は難しい (スコア:2)
長々と書いたのは、「技術交換が理想である」とあまりに簡単に片付けているので、それが決して簡単にできるものではないという実例として出しました。case studyにはすぎませんが、実際に使える事物や方法論を抜きにしては「○○ができる」「場合がある」といっても実感が沸かないんです。
Re:技術交換は実は難しい (スコア:2)
「技術交換が理想である」と書いたつもりはないんだが、ひょっとして「選択肢を残しつつお互いのいいところを取り入れ合ってみんながどんどんよくなっていくのが理想」と書いたところを捉えてそう言われるのかな。
newconfig vs new-bus 云々を持ち出したのが誤解の遠因になっているのかもしれないけれど、「ドライバを融通しようよ」とか「ほげほげの実装をこっちに持ってきて」という意味を込めたつもりはないです。もちろん、そうできりゃそれこそ理想的だけど、技術的な理由でなかなかそうもいかないのも理解できてるつもり。どちらかといえば、例えばWebサービスのプラットフォームとしてのBSDの選択肢があってよかったね、というところですね。「お互いのいいところを取り入れ合う」という記述の時念頭にあったのは、BSDにおけるOpen Package [openpackages.org]だとか、最近rpmをバックエンドにするaptが出てきたことあたりです。