BSDがLinuxよりも優れている事の証明

1 ：名無しさん＠お腹いっぱい。 ：2001/04/08(日) 06:11

強固なLinuxユーザに困るときは有りませんか?
そんなLinuxユーザに対抗するための論理武装をしましょう。

・FreeなPC-UNIXの範囲で考えるため、SolarisやHP-UNIXは考慮しない。
・なるべく、特定のディストリビューションに依存しない話題

それではどうぞ

198 ：164 ：2001/04/17(火) 13:49

172 のいう通り。
例えば、Multi-threaded環境におけるsignal, I/OがPOSIX標準に追い付いてないです。
APIが違うとかいうのでなくて、ないに等しい。よってVM実装困難。
無理矢理実装しているのだけれど、version上がると動かなくなったりする。
Javaが悪いのでなくて、OSの機能不足。

NetBSDでは実装されつつあるのですか。やるね。こんどsource見てみよう。
LWP というのは Sun の用語に合わせたのかな。
SunのLWP: kernel level(space) thread + user spaceのdata構造(stack等)

FreeBSDやLinuxもあるね。mergeされないかなあ。
http://citeseer.nj.nec.com/rd/32324037%2C266640%2C1%2C0.25%2CDownload/http%253A%252F%252Fwww.ens-lyon.fr/%257Ebouge/Biblio/Danjean/DanNamRus00RTSPP.ps.gz
http://people.freebsd.org/~jasone/kse/
Javaと最高のコラボレーションといえるのは、これ実装してからだよな。

199 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 14:09

質問なんですが。。。
そもそもなんで、Write Once, Run Anywareなんでしょか？
Write Once, Compile Anywareでいいように、素人だと思うんですが。
VM移植する必要があるなら、コンパイラ移植すりゃいいじゃん、って思ってしまう。

200 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 14:21

コンパイル嫌いな人はいくらでもいるってこと。

201 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 14:23

>>200
まじれす？

202 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 15:01

まじかどうかは知らないけど、結局似たようなもんじゃん？
コンパイラを嫌う機械(笑)だって有るんだし。
それこそi-modeみたいに、(小さすぎて)どう見てもコンパイラ積めそうにない
機械だってあるわけで、動くプログラム(=ソースじゃない)を供給
しようと思ったら、あーなるしかないのでは？

203 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 15:02

>>199
あのね、バイトコードは他に飛んでいくんだよ。だからコンパクトなの。

そういうこと想像できないかな？　

204 ：198 ：2001/04/17(火) 15:54

>>199
Multi-threaded環境のsupportが弱いので、
CやC++で大規模multi-threaded applicationを記述する時も困ります。
JVMもその一例にすぎません。

とはいえ、今のJVMでもAPIの違いや機能不足をよく吸収、補填してくれているので、
用途によっては非常に有用です。まさしくWrite Once, Run Anywareでしょう。
Write Autoconf, Compile Anywareの応用分野の否定には繋がりません。

>VM移植する必要があるなら、コンパイラ移植すりゃいいじゃん、って思ってしまう。
compilerがapplication開発者を手助けしてくれるのは、userlandのみです。
kernelが提供すべき機能が足りない、と言っています。
Interfaceの方言程度でなく、autoconfでは吸収できないほどの機能不足。

なお、馬鹿にしているのではなく、期待しているのです。> PC-UNIXs

205 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 16:14

JVM程度の non-preemptiveな multithreadでも kernel level thread
いるん? つーか、Sunの JDKがそれを前提として書かれてるから
移植が面倒、つーことかな。

206 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 16:28

>>205
意味不明ですね。

non-preemptiveなってどういう意味でいってます。
time-sliceでcontext-switchしないって意味でいってます？

207 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 16:45

Сотрудником органов федеральной службы безопасности може
т быть гражданин Российской Федерации, способный по своим л
ичным и деловым качествам, возрасту, образованию и состояни
ю здоровья выполнять возложенные на него обязанности, гото
вый работать в любом регионе России.

208 ：198 ：2001/04/17(火) 16:55

>>205
multi threaded serverで、
大量のthreadが同時にI/Oしたい時を考えてみて。
1 kernel thread/1 processではbottle neckにならないか?

209 ：206 ：2001/04/17(火) 17:14

>>208
CPUいっこならかわらないんじゃないかな？

210 ：205 ：2001/04/17(火) 18:53

>>206 そーゆーいみです。他の意味があるん??

211 ：198 ：2001/04/17(火) 19:03

>>209
single CPUでpmpthreadsとか使っているとそういう時も多いね。良くできてるので。
けど、directory updateとか同期書き込みあるといや〜ん。
同期的で遅いsystem call全般でいや〜ん。
Multi CPUだと、非同期でもその間parallelism押えられていや〜ん。いや〜ん、いや〜ん。

212 ：206 ：2001/04/17(火) 19:20

>>210
さんくす。つーことは...

>JVM程度の non-preemptiveな multithread
ってのはやはり意味不明なんですが。
JVM自体は non-preemptive, preemptiveは不問だからですよん。したがって、

>Sunの JDKがそれを前提として書かれてる
は間違いです。JVMはなにも限定してませんよ。
あなた色に染めてねといってます。（ｗ

213 ：206 ：2001/04/17(火) 19:49

>>211
Single CPUの場合として、
同期File書きこみとか同期システムコールがbottle neckになる場合が
多いのは想像できるのですが、1kernel thread-> 1processかどうかは
その意味のbottle neckに関係ない気がするのですが。
Context Switchの頻度というかその実装が例えばGUIの応答の重さを
きめるのではないでしょうか？

もしおれがお馬鹿なこといっていたらいや〜ん。いや〜ん、いや〜ん。

214 ：205 ：2001/04/17(火) 19:52

>>212 JVM仕様では preemptiveness(?)が不問なのは知ってるけど、
その一実装である Sun JDKは preemptivenessを要求する、
ってことも考えられるかなと。
んじゃなきゃ JVMの移植ごときで kernel level threadが出てくる
理由が分からん。
kaffeとかはそんなんなくても頑張ってるし。

208のような perfomance的な理由ならかすかにわかるが、
JVMに限らず、そーゆー用途に付き物の話だろうなあ。

215 ：198 ：2001/04/17(火) 23:24

>>214
JDK実装はportablity優先でいいじゃん、というのならその通りでやんす。
当初Sunは*BSDでもJDKとっとと出せるか、
という話題だったのに、わしの話も横路にそれすぎたの〜。

スレタイトルに何の関係もないが良いのかの〜。

216 ：名無しさん＠お腹いっぱい。 ：2001/04/17(火) 23:27

いいんじゃないっすか？

つまらない煽りよりは技術的な話のほうが面白いっす。
ここでLinuxでの実装例を誰か振ってくれれば十分このスレに・・・・

217 ：名無しさん ：2001/04/18(水) 01:04

>>207 激しく同意！
って書くやつはいないのか

218 ：名無しさん＠お腹いっぱい。 ：2001/04/18(水) 05:36

>>217
>>207の内容が分かるのか。俺の英語力は、殆どゼロに限りなく近くてロシア語みたいな渋い言語は
分からないけど、よく考えるとロシア語みたいな言語を知ってると、後々に役立つと思うんだけどね。
特に、これと言った理由もないんだけどね。

　俺、昔といっても2,3年前ドイツ語の勉強をしてたよ。ドイツにも去年の一月頃行って、四週間程度ドイツ
旅行してたせいか、どちらかと言うと英語よりもドイツ語の方が話せる。

　しかし、ドイツ語ちゅーもんは、スペリングが長くて読みにくいものもあるが、一部のウムラウト記号または
特定の例外を除いて、殆どローマ字読みだから、日本人からすると難しいけど英語より馴染み安い
と思う。まあ、他に例を揚げると、男性、女性、中性名詞があったりするが、、、

英語の場合、A(エイ)、B(ビー)、C(スィー)、D(ディー)だか、
ドイツ語だと、A(アー)、B(ベー)、C(ツェー)、D(デー)とどことなく、オッサンにとって都合の良いようになっている。
name(ネーム)が、ドイツ語だとスペリングが全くおなじで、name(ナーメ)とローマ字読みで発音。

面白いよな。

219 ：名無しさん＠お腹いっぱい。 ：2001/04/18(水) 07:50

>>218
>ロシア語みたいな言語を知ってると、後々に役立つと思うんだけどね。

Crackingの本場は東欧からロシアにうつりつつあるからね。

220 ：122 ：2001/04/18(水) 08:06

>>219
要するに、もうちょっと詳しく言うと、クラッキングの本場は東欧から極東に移りつつあるってことかな。
そういわれてみれば、そうだな。
ロシア、ユーゴスラビア、セルビア、北朝鮮、中国なんかは、アメリカの国防省から目付けられてるもんな。

221 ：206 ：2001/04/18(水) 08:55

>>216
近頃、甘口の煽りが多いとお嘆きの貴兄に、辛口の技術レポートをお送りします。

ttp://www.volano.com/report.html

FreeBSD用 JDK1.3.0って Blackdownのがあったんですね。
とおもったら、Ran using the Linux emulation packageだって！
Performanceで2割減ですか。Scalabilityで6分の1以下。

Ran -> Run?(w

FreeBSD用Java 2がでないのは単にマンパワーの問題だと思われ。

222 ：206 ：2001/04/18(水) 09:01

run ran run! 躁でーす！

223 ：198 ：2001/04/18(水) 13:09

>FreeBSD用Java 2がでないのは単にマンパワーの問題だと思われ。
マンパワーで解決できるという意味では*BSD, Linux辺りは十分な能力あるけど、
例えば、linuxthreadはsignalのsemanticsがpthreadに合ってない、
などなど発展させる余地がずいぶん残っていると思う。
必ずしもJDK開発側の問題だけではない、というのがもともとの発言の主旨です。

*BSDはuser level threadのI/O dispatcherがbottle neckになるので、
Network Scalabilityが良くないのはしかたないよね。ベンチマークでは特に。

224 ：206 ：2001/04/18(水) 13:50

>>223
>発展させる余地がずいぶん残っていると思う。

はい、異論はありません。
チューニングのレベルですよね？

JDK1.1 -> Java 2の変化に限ると対応APIがふえただけ
という気がしますので、マンパワーだけかなと思ったのです。

225 ：198 ：2001/04/18(水) 17:52

>>224
Java2というのは、java.* くらいに限った話ですか?
それならportも楽で、チューニングですむかも知れませんね。

JDKに含まれる、JIT, JNI, JVMPI等は大変でしょう。
javax.realtimeのPriorityInheritanceなんかはまたまた大きな障壁でしょうね。
そんなscheduler持ってませんから。

226 ：206 ：2001/04/19(木) 08:30

>>225
>Java2というのは、java.* くらいに限った話ですか?
はい、Java 2 Standard Editionのコアパッケージ位を想定してました。

(HotSpotを含む)JITは.soであとから足せます。
JNIってただのインター(^^)ですよね。
JVMPI,javax.realtimeはコアパッケージ、APIじゃないですよ。

227 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 08:07

>>179
激しく同意

171はBSD板としては消極的で後ろ向き。
ただ、「Linuxより堅牢」というのはもはや幻想かも。

# 386BSDの頃からBSDユーザだが、最近の*BSDは最近落ちやすくなった
# ような気がする。

228 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 09:11

>>227
後半部分には同意しかねるけど、何を以ってそう思うの？

229 ： ：2001/04/21(土) 10:16

>>266
>>JNIってただのインター(^^)ですよね。
実装も当然あるでしょ。なかったらdispatch出来ない。
green threadであるから起き得る問題としては、
http://www.blackdown.org/cgi-bin/jdk/known-bugs?id=203;page=3;user=guest
など。

230 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 10:44

Linux と FreeBSD の比較ならば、純粋にカーネルの比較のみにおいて
意味がある。OSとしての比較ならば、たとえば

* Slackware と FreeBSD の比較
* RedHat と FreeBSD の比較
* Debian と FreeBSD の比較

といったレベルで議論されるべき。

231 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 10:47

しまった、Freeをはじめからつけて書いてしまった。もちろん、

*Kondara と NetBSD の比較

もオッケー。

「誰にとって便利なのか」の議論も抜けている。

ユーザーの何割が厨房なのかと考えると，厨房にとって
優れたＯＳをバカにするのはどうかな。自分が厨房じゃない
と思っているなら，勝手に自分ＯＳでも作ってろって感じ。

232 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 10:55

>>230-231
ちゃんと全レス読んだかい?
限りなく的外れ。

233 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 23:32

あるハッカーはOSのセキュリティについて
「LinuxはBSD系に比べると弱い。NTよりはだいぶいいが。一番強いのはOpenBSDだが」
と語っていた。当然だが「設定する人間がバカならどれを使っても駄目」とも。

234 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 23:44

厨房の使うLinuxとHackerさんの使う*BSDは比較できないじゃん?
逆もそうだし。
だからって 厨房Linux VS 厨房*BSD じゃ意味ないよね。

Bestの状態での Linuxと*BSDを比較しようってことでいいんじゃないの?
# Bestの定義でももめそうだなぁ。

235 ：名無しさん＠お腹いっぱい。 ：2001/04/21(土) 23:51

つまり一番重要なことは、もはやLinuxでもセキュキティとかそういうシビアなニーズに対して応えられるってことだろ。
わざわざ難しいBSDを使う必要はないってこと。

236 ：名無しさん ：2001/04/22(日) 01:36

難しいか？

237 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 02:09

俺235じゃないけど。
「難しい」を「地味な」に変えてみたりする。

238 ：CCルリたん。 ：2001/04/22(日) 02:49

>>235
難しいかは使う人次第だがな。わたしゃlinuxconfは
目的とする設定項目がどこにあるか探すのが面倒で嫌
いだ。

FreeBSDは設定ファイルがほとんど/etc/rc.confに
集約されているから、設定変えたい時は
　　　grep keyward /etc/default/rc.conf
で設定項目探して
　　　vi /etc/rc.conf
で事足りるぞ。

239 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 02:56

Linuxはまったくシランのですが、
FreeBSDでいうSecurity Advisoryみたいのは
各ディストリビューションで出とるんですか？
ports/packagesの穴まで報告してくれるのはありがたいこってす。

240 ：厨房＠お腹いっぱい ：2001/04/22(日) 04:45

セットアップはLinuxが簡単みたいです。しかし、FreeBSDでは
XconfigでＸwindow設定できましたが。VineLinuxでは、白画面
になりました。（ちなみにＦＭＶビブロ）

241 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 07:08

>>238
良かった。vim使ってる人って、俺だけかと思ってたよ。

242 ：206 ：2001/04/22(日) 10:33

>>229
green_threadsはSolarisでも同様の問題ありなんですよね。
つーかSolarisの参考実装がいかんというか。
そもそもgreen_threadsではきめこまやかな接待ができないのかな。

結局JDKのポーティングにはnative_threadsを要求されてるってことですか。
で、話がもとにもどると。

243 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 14:05

>>240

Linuxはセットアップが簡単そうに見えるだけで
本当に好みの環境にしようと思ったら、やっぱり
それなりのスキルがいるんだよ。

インストールが簡単だというふれこみでLinux使い
始めた初心者は、不満を抱えながら使い続けるか、
ディストリビューションを渡り歩くかしかない
んだと思うよ。

244 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 15:03

>>241
vimとは限らんだろう。nviで事足りるって人もいるしね。

245 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 15:32

>>243
概ね同意。
Linuxは簡単と言っているが、やはりそれ相応のスキルが必要になる。
ここで、勉強するなりして、実力をつけられる人はいいが。
「簡単だっていったのに、ぜんぜん簡単じゃねーじゃん」
と、開きなおる輩がL厨化してるのが悲しい現状。
*BSDは簡単じゃないっていうイメージが先行してるから、使う側にある程度の覚悟を持たせられる。
Linuxが簡単だなんていったのは誰だ?
日×なんちゃらとか、×経なんちゃらとかか？

246 ：名無しさん ：2001/04/22(日) 16:46

Linuxなんかにいれあげる奴は実はWindows厨房と大して変わらない。
えせUNIX使いでしかない。

247 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 17:23

>>246
5〜6年前に*BSDを使っていた事がある人かの？
少なくともその時点ではLinuxには閉塞感が無かったから

Linuxは*UNIXとは似非ですぞ、結局はスキルの話になるのならば
如何様なＯＳでも同一の次元の話であり、かつその証明たらんとなる

248 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 17:57

厨房的な視点でいうなら、
BSDは、何をするにしても必ずその行為について知識がいる。
Linuxは、製作者側の提案がセットアップにもりこまれてるので、
とりあえず使える。
で、そのうち不満を感じた点からつっついていける。これがラク。
初めから自分の方針についてめどがたってる(古参からの)ユーザ
だったら、余計なお世話だろうけど。

ある山を登るのに、まっすぐじゃなくて時間がかかる登山道を
使うのがLinuxで、BSDは道なき道をつっきっていく感じ。

249 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 18:17

> ある山を登るのに、まっすぐじゃなくて時間がかかる登山道を
> 使うのがLinuxで、BSDは道なき道をつっきっていく感じ

BSDは道なき道じゃないだろう。
むしろまともな登山道が BSD という気がする。
せっかちな厨房向けLinuxはケーブルカー。
(Windozerは最初から別の山で遊んでいる)
おれもLinuxユーザだが、やはり細かいところをきちんと
見るには地上に降りるしかないんだよ。まあ人それぞれだけどね。

250 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 21:14

>>248
BSDに過大な幻想を抱きすぎだよ。
BSDユーザでも、/etcの下のファイルを全てゼロから書けて、それぞれがどのプロセスに影響を与えるか答えられる人は一部のみだろう。
BSDとLinuxの差より、個人差の方がはるかに大きい。

251 ：名無しさん＠お腹いっぱい。 ：2001/04/22(日) 21:28

物理の教科書に

どんな学問でも奥の深さという点では物理と変わりはない。
が、物理は敷居があまりに高く、とっつきが悪いのだ。

とあった。
おれも今じゃ *BSD が Linux に比較して特別難しいとは
思わないが、Windows ユーザだったころは *BSD はえらく
難しく思えたし、実際導入に失敗した。

252 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 03:12

自分は debian 使っていてそこそこスキルもある方だと思いますが、
こんなに *BSD の人から厨房だ簡単だのといわれると、なんとなく
くらがえしたくなりますね(プ
個人的には、同じことするのに linux と *BSD で必要なスキルの
差というのはそんなにないと思うんですが。
おしきせの設定で gnome と netscape を使いたいだけなら
RedHat 系の方が楽だけどね。

253 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 07:50

BSDな人(特にNetBSD,OpenBSDな人)に質問

Linuxではglibcというへたれな標準ライブラリの
バージョンアップによって、同じCPUでも簡単に
バイナリ互換性が失われることが度々あるのですが、
BSDではないんでしょうか？

なかったら多少茨の道でもmake Worldしてみようと
思うのですが。

254 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 09:26

> 自分は debian 使っていてそこそこスキルもある方だ
これが厨房っぽいんでしょ。

255 ：/usr/local/bin/ ：2001/04/23(月) 11:59

>>249
BSDが頂上まで続いてるまっとうな徒歩の登山道だとしたら、
Linuxは中腹までしか開通してないケーブルカーなのでは。

中腹まではケーブルカーのなすがままに登れるけど、
中腹より上に行くには徒歩で行かなければならなくて、
そこまでまともな登山装備もせずにお手軽に登ってきちゃった
輩がそこから先に登れなかったり遭難してしまったり、
もしくは諦めて下山したりしてしまう。

BSDみたいに最初っからちゃんとした装備（知識の獲得）を
していれば中腹で迷うことはなく、きちんと頂上まで登れる
のだと思う。

256 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 12:27

人様の成果を使わせて貰ってるだけの厨房FreeBSDユーザとしては
まっとうなLinuxユーザに比べて知識があるとは思えない。FreeBSD
使うと決めてから泥縄式に本やwebを漁っただけなので。

ま、俺みたいなのは物の数に入らないかもね。
でも俺みたいなのでもそこそこ使える程度にはFreeBSD周りの情報
も整備されてきていると思われ。

257 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 12:37

>>253
NetBSD-current 追っかけな人だけどバイナリ互換性なんか
気にしないっす。make build すれば済むから。
んで、過去にコンパイルしたバイナリが突然動かなくなった
なんてことは殆どないよ。a.out --> elf になったときは
大変だったけど。

258 ：257 ：2001/04/23(月) 12:50

1.0 以前は知らないけど、バイナリ互換性には気を遣ってる
みたいだからあまり心配しなくていいんじゃない?
殆どと書いちゃったけど ELF 化遷移過程の /emul でハマって
たときの話で libc の major が同じなのに互換性がないじゃん、
という経験は個人的には皆無。

それとも運がよかっただけ?

259 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 17:25

Linux の場合は　shlib の　major version を変えずに
互換性を平気でばんばん崩すのが問題だろうけれど
NetBSD とかではそのような話は聞かないな。

でも　linux と同じのりがある gtk とかを使うプログラムはダメかも

260 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 18:27

>>259
gtk は死んでるね。minor version が変わっただけで互換性
のなくなる API をなんとかしてくれよ。(;;´Д｀)

まだ Java のような新規に API を追加していく方式のほうが
ましだよ。

261 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 19:44

>>260
1.2系でも何かあるの?

262 ：名無しさん ：2001/04/23(月) 20:24

Red Hut のディレクトリ構造は反吐がでるな。

263 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 20:27

>262
はいはい、タン壷に向かっててね♪

>255
あ、ちょっとひっかかるところはあるけど、そっちの方が適切な例えに
思える。うまいなぁ。

264 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 21:28

> libc の major が同じなのに互換性がないじゃん、
> という経験は個人的には皆無。

NetBSD 使っているけど、同じくそういう経験は皆無。

> それとも運がよかっただけ?

major が同じなのに、互換性がなかったら、それは普通バグと呼ぶと思う。
別に運が良いんじゃなくて、ふつう、それが当たり前なのでは？

265 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 22:08

私はもう何年も前に*BSDからLinuxに乗り換えた人なのですが、
実は同じようにLinuxに乗り換えた人って多いのではないでしょうか？
もし他にいたら手を上げてみて!
ついでに理由も述べてちょ。

ちなみに私は周りの人たちがLinuxに流れてしまって、いろいろ聞かれる
うちに自分でもユーザになってしまったのでした。

266 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 22:29

Linuxでも*BSDでもいいんだけどさ、せっかく開発中の最新の
ソースコードが手に入るのに、makeして通ったの通らないの、
動くの動かないのと騒いでおしまいの厨房が多くないか?

通るようにしたら通るようにしたでとっととcontributeする。
動かなかったらとっとと動くようにしてcontributeする。
自分が使ってるソフトウェアで、気に入らないところがあるんなら、
うだうだ掲示板で愚痴ってないで、戦え! 馬鹿どもが。

267 ：名無しさん＠お腹いっぱい。 ：2001/04/23(月) 22:30

*BSDはオンラインドキュメントがしっかりしているところがいいね。
しかし、俺も265と同じような理由でLinuxに乗り換えた。
対応しているパーツも多く、カーネルの安定度もNetBSDに負けていない。
なんでLinuxが叩かれるのか訳がわからないよ。

268 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 00:58

Linuxが叩かれるのは「出る杭は打たれる」って奴でしょう。
BSDが地味だと言われるのは「少数派」の宿命でしょう。

269 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 01:35

カーネルなどの基本的な部分に関しては枯れていることもあり
*BSD の方がソースが洗練されていると思う。
# たとえば仮想記憶
# Linux: i386 の機構をそのまま使用
# *BSD: 4.3BSD までは VAX の機構をそのまま使用 -> Mach-VM ->...
やりたいことをなんでもありで実装する人が Linux に集まっちゃったのか
ださい実装のとこも結構あるけど、ちゃんと安定して動くんだから
critical な部分以外はどっちでもいい。

漏れの場合は慣れが大きいな。 Linux についてよく聞かれるが
エノキダ君的性格からかあまり移行する気にはならん。

270 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 03:06

これからはPlan9だよ！

271 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 04:13

>>269
# たとえば仮想記憶
# Linux: i386 の機構をそのまま使用

AlphaやMIPS版のLinuxカーネルもそうだったらすごいね B-)

272 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 08:36

>>270
なかなか、それを理解できる人が多くないのだよ…

273 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 10:47

Plan9ねぇ...
考え方は賛同するけど、じゃあ使うか?と言われたら別に今のままでもいいや
と思ってしまう、そんな存在。研究室用OS止まりじゃないかねぇ。

274 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 10:56

>>271

> # たとえば仮想記憶
> # Linux: i386 の機構をそのまま使用
> AlphaやMIPS版のLinuxカーネルもそうだったらすごいね B-)

Linux の Alpha 版とかは i386 の機構をエミュレートしている。
てなわけで Linux の仮想記憶の解説はほとんど i386 の機構の説明。
というのは有名な話だと思うんだが。

275 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 11:25

>>266

contributeってそう簡単にサクサクできるものでないよ??
makeが通らないバグは、makeしてみたやつ全員が遭遇するので、
バグ報告している間にcoreチームに直されてしまってたりするし。

バカバカ言う前に自分でも一度やってみいよ。
デキるやつらの間でも、仲間内でうだうだ言っているしか
できない場合があるんだから。

276 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 21:02

>>275
contributeしたことないやつにかぎって、そういうことを言うんだ。
言う前に動け、厨房が。
誰だ? デキるやつらって?
俺の知ってる本当にできるやつらに、仲間内でうだうだ言ってるだけの厨房は
一人もいないぞ。少なくとも *BSDの関係者にはいないな。

277 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 21:27

>>276
わかったから黙ってcontributeしてれば？

278 ：名無しさん＠お腹いっぱい。 ：2001/04/24(火) 23:54

>>274
そこまで言うなら具体的なソースの場所を上げてみ。
カーネル2.2.x以上でな。
これに答えられないようならキミは知ったか厨房決定だぞ(藁

279 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 00:11

>>278

通りすがりのものですが、
なんかおまえハズカシいぞ

280 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 00:36

ん、やはりWindowsが一番です。
僕はLinux、BSDに入門、そして挫折して悟りました。「LinuxがWin9xに取って代わることはない」
電源を切っただけでシステムが壊れるとか、ルールを守らないものに対して厳しすぎる
なんだかんだ言ってWindowsは頑丈にできてるよ…君らには初心者の気持ちは分かるまい
コンシューマ用途において最強はMac/Winだろう。Linuxは足元にも及ばない

281 ：名無しさん ：2001/04/25(水) 00:40

WindowsもLinuxもBSDもSolarisも使ってるけど、
人に言うのに一番恥ずかしいのはLinux。なぜだらう

282 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 00:45

今一番流行ってるからだろ。＞Linux
「流行ってるのでとりあえず入れてみました」「これからはLinuxだよなー」みたいな
Linux自体は決してドキュソOSではないと思う

283 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 00:48

>>282
「IT革命」よりは良いかと思われ

284 ：274 ：2001/04/25(水) 00:50

>>278
/usr/src/linux/arch/*/mm 以下が一応機種依存部分ということにはなっているが,
/usr/src/linux/mm の下とかで pte などの table を直接触って
いるところがたくさんということ。

たとえば NetBSD だと /usr/src/sys/arch/i386/i386/pmap.c
に pte などの操作はカプセル化されているしいろいろとコメントされている。

また NetBSD の仮想記憶機構 UVM の解説
http://www.usenix.org/events/usenix99/full_papers/cranor/cranor_html/
内の最後のほうにある Related Works のあたりに table 直接触ることについて
の短所が書いてある。

U*ix の仮想記憶に関して真面目に読むならば、ピアソンの 「最前線 UNIX の
カーネル」などを参照のこと。ASCII の BSD マガジン No. 4 の仮想記憶につ
いての文も参考になる。

ただし前にも言ったように一人で普通に使う分にはそれほど関係ないし、
Linux カーネルはそこまで枯れていないのだからそのうち差し替えられるだろ。

わかってないと思われる芸のない煽りは
>>279 さんの言うようにかっこ悪い。
まともに反応している時点でおれも厨房だがな B-)

285 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 01:19

>>280
LinuxでなくてFreeBSDだけど、
いままでいきなり電源切って壊れたことはない。
Windowsでいきなり電源切って壊れたことはある。
どちらもいつも切ってるわけではなくて数回の結果だから
確率の問題だろうけど、どうなんだ？

286 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 01:25

おれはBSDが100%壊れる
HARD READ ERRORとか言って。

287 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 01:38

>>271 >>284
B-) なんて言う顔文字(?)、どっかで見かけたことがあるなと思っていたら思い出した。
fjとかで生○氏がよく使っていた奴だ。

もしかして点点点。

もし、271=284 だとしたら、271=274になるので、274は自分自身に返答している?

288 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 01:38

>>280
Winのいったいどこが丈夫だって？

ウイルスバスターとかノートンアンチビールスなんてソフト
入れておかないと、ウイルス付き電子メールが紛れこんだだ
けで、システムが簡単に破壊されてしまうOSのいったい何処が。

289 ：名無しさん ：2001/04/25(水) 02:32

そりゃユーザの責任
Winでも9x系はそうでもないか。普段rootで作業してるようなもんだしな

290 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 07:15

いいぞー、やれやれー
俺が思うに一番ロバストなOSはMS-DOSだ。
その安定性はどんな商用UN*Xも遠く及ばない。

291 ：スレタイトルよーくみろよ ：2001/04/25(水) 08:32

>>290
あんたスレちがい。

292 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 08:43

>>286
HARD READ ERROR というエラーを見たことがないが
fstab で async を指定しているかも
fsck で時間かかっているだけならそんなエラーでないだろうし

293 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 10:50

ケ、ちんこの小さい奴だな。

294 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 11:48

Mac の System6.0.7 もわりとロバストだったよ。

295 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 14:24

>>293
>ケ、ちんこの小さい奴だな。

普段はな。
いざというときは１８ｃｍにはなるぞ（ｗ　

296 ：ばか ：2001/04/25(水) 19:28

>>295
よっ、大砲くん。

297 ：名無しさん＠お腹いっぱい。 ：2001/04/25(水) 21:44

キャノンぢゃないよ、キヤノンだよ。

read.cgi ver5.26+ (01/10/21-)