自分がDebianとNetBSDのユーザなので無理矢理話をBSDに変換してしまうと、「FreeBSDがあるんだからNetBSDやOpenBSDなんかいらない」とは絶対思わないってことです。かつてFreeBSDを使っていて、newconfig vs new-bus の醜い争い(当事者たちはどう思ってたか知らないが、傍目からは実に醜かった)を見てFreeBSDを捨てた時、NetBSDという選択肢があったことを実にありがたいと思ったものです。
日本だとどうしても「kernel屋 == デバドラ屋 or ネットワーク屋」となってしまい、4.4BSD本(今となっては古すぎる)を参考にすれば十分とか、穴埋め式で書いていけばkernelなんて簡単に作れると思い込んでいる人達が目についてしまいます。穴埋めが効かない、問題の定式化から手作りで始めなければならない、しかもOSなんて100や200もあるわけではなく、参考にできるものが少ないところにOS作りの本当の難しさがあります(wfjが386BSD本で述べたことは21世紀になった今でも通じている)。ネットワーク屋さんはある程度意識しているかも知れませんが、デバドラ屋になるといまだにあの赤い本を振り回す人がいて、そんなものが使いものにならない私からすればむなしく見えてしまいます。
なぜにLinux? (スコア:2, 興味深い)
BSDなOSを使ったほうが良いのでは? 確か、日本のある公共団体
の施設では、上記の理由でオールBSDで運用していたぞ。
やはり、あまりにもマイナー路線なのも話題不足で駄目なのだろうか…
Re:なぜにLinux? (スコア:2)
FreeBSDが駄目だと思ったらOpenBSDというわけにはちょっといかないですよね。そりゃWindowsよりはずっと移行は楽だと思いますが。
後は・・・高性能なJava VMが存在するのも押さえておきたいポイントだと思います。
いずれにしても、砂上の楼閣アンチパターンにみんなようやく気づきだしたと言うところですか。
Re:なぜにLinux? (スコア:2)
素朴な疑問ですが、世の中の多くの人に、トラブルがkernelにあるのか、それともuserlandにあるのか判断する能力があるのでしょうか? また、Unixではほぼすべてのapplicationについてin-kernelの性能が影響を及ぼすことがどれくらい周知されているのでしょうか? これらがわからないので、distroが選択できるといわれても有り難みが感じられません(あるとしても一時的、限定的なもの)。
逆にいえば、その判断基準を身に付ければ、たとえSolarisのようにsourceからの構築が難しい、あるいはfreeなOSとの差異が大きいものでも使いこなすことはできますけどね。GiantさえとれてしまえばFreeBSDはSolaris8と十分張れる、7以前に対してはより高い性能を出せる可能性すらあるとか(Solaris7およびそれ以前ではslab allocatorがSMPの足かせになっている、8ではDynixっぽくしたらしい)。
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 の醜い争い(当事者たちはどう思ってたか知らないが、傍目からは実に醜かった)を見てFreeBSDを捨てた時、NetBSDという選択肢があったことを実にありがたいと思ったものです。
そうやって選択肢を残しつつお互いのいいところを取り入れ合ってみんながどんどんよくなっていくのが理想でしょう。感情的なものもあるから、なかなかそうはいかないのも確かだけど。
技術交換は実は難しい (スコア: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が出てきたことあたりです。
Re:なぜにLinux? (スコア:2)
>利点だと思えます。
わたしは逆に欠点だと思いますねぇ(汗)。
#Turboの流儀がSlackで通じない、ってね。
#わたしにしてみれば、「同じLinuxなのになんでコマンドが違うんだ?」なんて
#感じますし、「この設定コマンドが」なんて、Distribution指定せずに
#いきなり切り出したりする人もいるし。
#コミュニケーション能力の不足は経験で補うとしても、
#話をするベースの部分での知識にばらつきがあるのではねぇ・・・。
#みんながみんなkernel hackerの知識があるわけではないのだし。
#あと、各Distributorでkernel patchが出るって状況、
#本当にそれでいいんですかね??
>FreeBSDが駄目だと思ったらOpenBSDというわけにはちょっと
>いかないですよね。
何故?
そう「いかない」という根拠を、まず述べるべきでは??
個人的経験談でいいのだけど・・・。
#ちなみに、派生元が同じなので、基本の設定コマンドはほとんど共通です。
#ドライバについては、FreeBSDは数の多い機器から、NetBSD/OpenBSDは
#開発者が興味を持った機器から作られて、お互いにportingしてるような状況です。
#ファイルシステムは、BSD系OSはsolarisのufsやext2すらマウントできるしねぇ。
#お互いのffsくらいは当然、素のkernelでマウントできますよ。
#ただ、ffsのendian independencyはまだ実装中・・・なのかな?
>高性能なJava VMが存在するのも押さえておきたいポイント
クローズドソースに用はない。
ソースがあればBSD系OSでも動くし、セキュリティ考えたら
Java VMの導入はもっと慎重な態度を取るべきでは?
#セキュリティの話してるのにBlackBox入れてどーすんだ??
>いずれにしても、砂上の楼閣アンチパターンにみんなようやく
>気づきだしたと言うところですか。
ここは同感。
---- redbrick
Re:なぜにLinux? (スコア:2)
#そりゃ、その気になればCだって十分書けますが。
アプリケーションの開発が難しい環境を標準に、というのは難しい話だと思います。それに、セキュリティを考えてJavaでアプリケーションを構築する事例だってあります。不用意にプログラミングしてもBuffer overrunのような問題がほとんど発生しないし。
エンタープライズアプリケーションの実行環境として、BSDは残念ながら現状でLinuxに大きく水をあけられていると思いますよ。適材適所でほかの使いどころは十分にありますが。
Re:なぜにLinux? (スコア:2)
>たとえばFreeBSDで使えるデバイスがNetBSD/x86で使えるとは限らないでしょう。
それはkernel verisionの統一を考えていない、各Linux Distributionでも同じですよね?
porting問題はおっしゃるとおり手間が生じる"可能性"がありますが、これはLinuxでも
生じない事ではないですよね?
#kernel versionの差でサポートデバイスは変わる"可能性"はあるし。
だとすると、それで、BSD系の間の場合とLinux Distribution間の場合を区別して
「移行が難しい」と主張する根拠にならないと思いますが。
#・・・間違ってますか? 間違っていましたら、論理的にご指摘いただければ、訂正の上謝罪いたします。
>これは一般人にとって十分な差異と思われますが?
これは、わたしの個人的見解ですが、サポートデバイスを調べないで移行をしようとするヒトは
一般人じゃなくて、うっかり者です(苦笑)。
#そんなの、Windows間だってLinux間だっておんなじ。
#移行しない、という選択肢が他に比べて妥当、ということもありますし。
>>FreeBSDが駄目だと思ったらOpenBSDというわけにはちょっと >いかないですよね。
サーバを前提として考えて、実行環境の移行を想定していたのですが、ディスクなどの
必須デバイスでのサポートの差異は現状ほとんどないはずです。
#RAIDカードのサポートはもしかしたらOpenBSDの方が進んでる?
#あ、SMPのサポートはFreeBSDが進んでる・・・かな?
以下、個人的見解による意見ですが・・・。
ドライバ開発などのサポートが遅れているのはsound等のサーバ業務には必要のない
デバイスや新規のもので、この辺りは必要ないか、portingのスタートが変わらないので
あんまり差がでないと思います。
サーバアプリケーションの用意は、日本語の問題をXで解決すると、BSD間での差異は
ほとんどないはずです。
#そもそもコンソールで日本語を通すにはkon2等の特殊なコンソールドライバがどのBSDだって必要。
#NetBSDはwscons(標準コンソールドライバ)でのm17n化が進んでいる?
で、最後にディスクはどのBSDでも、i386同士ならば問題なく読めます。
ここまで考えて移行が「ちょっと(すぐには)いかない」とおっっしゃるのは不思議に思ったんで、
「個人的経験談でいいのだけど・・・。」
と書いたのですけどね。
#特殊な事情や、移行を妨げる特別な事例があったのかと思いまして。
#でもJAVAが制約になっている、ということなのですよね(詳細は後述します)。
>私は基本的にJava屋なので、Javaが動かないところでソフトウェアの開発は厳しいんですよ。
JAVAの件は、"FreeBSDでは存在しないorLinuxバイナリを動かしてる"といううろおぼえの記憶が
念頭にあったのと、サーバ系でセキュリティ重視という場合で考えていましたので、
開発者の方と見解が異なってしまうのはあると思います(汗)。
こちらで前提を説明せずに論を展開してしまって申し訳ありませんでした。
この点については謝罪いたします。
#でも、BlackBoxなシステムは、個人的意見としてセキュリティ重視のものには使いたくないですが、
#それはわたしの個人の主張ですしね・・・。
ここでの「あなたにとって、他より妥当な選択肢」が、*BSDではない、って事ですよね。
#やるせないことだ・・・。
>エンタープライズアプリケーションの実行環境として、BSDは残念ながら現状でLinuxに
>大きく水をあけられていると思いますよ。適材適所でほかの使いどころは十分にありますが。
この点は同意です。
#わたし自身は、PC-Unix上ではクローズドソースのアプリケーションは使わないポリシーですけど。
#あと、BSD系のi386だとLinuxのi386バイナリを直接実行することも出来ますが、
#結構ライブラリの整合性とかで苦しむor動かないこともあるようで、ちょっと残念です・・・。
---- redbrick
Re:なぜにLinux? (スコア:1)
ふむふむ、実行環境として水をあけられていたのか...俺はてっきりLinuxブームと共に、エンタープライズアプリケーションを作ってる/売ってる連中がLinuxに進出してきただけだと思ってました。で、参考までにお聞きしたいのですが、実行環境として、どういう点でLinuxがBSD一派よりも優れているのでしょうか?あるいはBSD一派に足りないものは何でしょうか?
ちなみにjavaに関しては、FreeBSD本家内 [freebsd.org]に情報があります。(別投稿でACさんも書いていますが)SunはLinux以外のFree UNIXはお嫌いみたいですね。
Re:なぜにLinux? (スコア:2)
Javaについては、別の場所で書きましたがやはり非常に熱望されているのでSunも含めて何とかしてほしいところです。
もし出たら、Linux/FreeBSDのJDK対決を見てみたいな・・・
Re:なぜにLinux? (スコア:0)
> ポイントだと思います。
いやね FreeBSD にも JDK はきちんとあるのですよ。
もちろんネイティブで JDK1.3 相当の。
ちゃんと port されてるにも関わらず Sun が配布 OK 出して
くれないだけ
Re:なぜにLinux? (スコア:2)
それで「高性能」なんでしょうかね?せめてLinuxのJDK1.3.1レベルは実現しておいてほしいところですが。
実はテストにとおっていないとか、そういう理由ではないのですか?一応、 [BugId:4288745]/ [sun.com]はRFEのトップ得票なんですがねえ。ま、Sunにどうにかしてほしいと言うのは同意です。Re:なぜにLinux? (スコア:1)
ええまぁ、いろいろあってですね
法律的な問題を抱えているようで、1.2.2 にしても 1.3 にしても Sun が JCK を通していないそうです。こればっかりはどうしようもない。
サーバーサイドの場合 Java 2 以降の Java 2 SDK は似たり寄ったりな気がしますけど。(注意: 元が Sun ではない実装は別)#それに FreeBSD 上の Java 2 SDK で運用してる商用サイト結構知ってます:-)。
ところで元ネタの話だと、BSD がどうたらと書いてありますが、どっちでもいいんじゃないでしょうか。私は FreeBSD が好みですが、適材適所で Linux も使いますし、それぞれ長所短所を持ちます。
セキュリティがらみの話ならどんなプラットフォームでもセキュリティホールがあるわけですし、そのプラットフォームでどれだけセキュリティに気を使って運用するかの方が大事だと思うのですが。
FreeBSD JDK (スコア:0)