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

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

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

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

それではどうぞ

160 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 23:20

>>157
FreeBSDのSMPってBSDiのコード入っているやつ？
どんなベンチやったの？

161 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 23:48

ぼくはたこです。おしえてください。
なぜ pc 用 linux と mklinux はソースが結合されていないのですか？
netbsd 等はソース一つですよね。
よろしくおねがいいたします。

162 ：150 ：2001/04/14(土) 23:54

>>156
何となくとはいえ、分かってくれる方が
いらっしゃいましたか。サンキュー

FFは7までヤッたし、3はちょっとだけやりこんだ。
ドラクエは、7は途中で投げたが、5と6は結構やった。

てことで、言われてみればあんまりヤリこんでないや

163 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 00:09

>>160
FreeBSD 4.1とLinux 2.2.16
使用したのはubench-0.32で、これは SMP-aware なベンチ。
SMPにはLinuxに一日の長ありというのが結論。

164 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 01:00

>>155
JDK作る人だけが頑張ればいい、という問題じゃないんですよ。

*BSDのkernelにkernel level threadを導入してもらわないと、
version upごとの即時JDK公開は難しいでしょう。
*BSDのuser level threadはなかなか頑張ってるんですが。
User levelのみだとかなりレベルの高いの実装の一つかな?

Linuxみたいにkernel levelだけでもまだ少しうまくないんですね。特に効率。
http://www.cs.berkeley.edu/~brewer/cs262/
の"Scheduler Activations"のように両方あって協調しないと。

この分野で*BSD, Linux, Windowsは、
Solaris, OSF/1等に7,8年くらい遅れてます。
SolarisなんかPOSIX realtime extensionをfull supportし終りそうですから。

KernelでSMPやthreadをうまくsupportしただけでは解決しないのです。
EINTRとかlibcとかpthreadとか解決するすべきこと一杯あるので。

早く、scheduler関係も充実するといいですね〜。
SFCの徳川研でやっていた、FreeBSD on RT-Machはどうなってるんでしょう?

165 ：名無しさん＠なぽりたん ：2001/04/15(日) 02:06

どちらも食わず嫌いは良くないってことか？

全部見て歩いてるとあれいいかこれよくないかって、肌に合う合わないとか
出て来るだろうし、どこかにのめり込んで行くだろうし、そうなると余計
他のを見てないんじゃないの？

日経かぶれのおじさんはLinuxスキスキみたいだのう。
困る。

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

>日経かぶれのおじさんはLinuxスキスキみたいだのう。
>困る。
いやいや、これでも状況は良くなった方だよ
Linuxが流行る前は「UNIXなんてダメ」ってのが、
おじさん達の口癖だったわけだし（ご存知の通り）

LinuxのおかげでフリーUNIXへの抵抗感は減っているから
プレゼンで何とでもなるよ

ただ、安定性とかは数値化しにくいし、実際、超高負荷
でもなきゃ挙動は変わってこないのでそういう方法から
は説明しづらい。DBMSとか商用ソフトが対応していない
のも難点だ。エミュで動くって言ってもね

まぁ、ライセンス辺りから攻めるのが無難じゃない？
後は詐欺に近いけどBSDの伝統云々のイメージ戦略

167 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 08:36

素人ですまんが。。そもそもJavaって、OS依存部分を
VMで吸収するのでWrite Once, Run Anywareが実現できるんではないんですか？
じゃなきゃなんのためのJavaなのか。。。

ていうか、ネイティブコンパイラください。

168 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 08:45

んで、VMで吸収できないような設計だと、
なにか違うような。

169 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 10:28

>>156
>jdk だけど、スタンフォード対バークレイってほんとかね？
あれは、焼き肉屋で生まれた妄想なんじゃないかなぁ。

>>167
その、VMの移植の話だよ。(100% VM に限った話でもないけど。)

170 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 11:00

>>163
あれをSMP awareと言ってる時点でかなり頭悪い

171 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 11:23

「サーバとしてどっちがいいか」っていうのはよくわからんのだけど。
最近立て続けに Linux 狙いのクラッキングの話を聞くよね？
*BSD 狙いのクラッキングってあんのかなぁ。
それだけ見れば *BSD のほうがいいよーなきがするんだけど、どう？

ココ感じる？

172 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 11:24

>>164
NetBSD の (多分)nathan_sa ブランチが "Scheduler Activations" を
実装し始めている。 kernel level thread と言わないで
light weight process というみたいだが。

>>167
漏れも素人だが Virtual Machine で OS の欠けてる機能を完全にエミュレート
できるわけではない。 Realtime scheduler を持たない OS ではどうやっても
プロセスでしかない Java VM が Realtime な応答性を保証できるわけがない。

だからちゃんとした VM を提供するためにはその下の Kernel や library が
ちゃんとしていることが必要で、そうじゃなければそれなりのものしか提供
できない

上の話とは関係ないが
Sun の JDK よりも IBM の JDK を移植してほしいような気も

173 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 11:58

IBM JDK速いよネ！

174 ：なまえをいれてください ：2001/04/15(日) 13:10

なんでも適材適所つーことだね。
オイラもJavaサーブレットの開発機にはやはりLinux(や、GNU/Linuxね)
使ってるし。

175 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 13:27

不倫BSDデビューしたんですが、意味わかりませんでした
削除もできずにネッコろがっています。やっぱLinuxから始めるべきだったかな。

176 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 14:27

>>175
お気楽なほうに流れるのが人の性だが。
それじゃいかん、と思ってがんばろう。

# あー、FreeBSDもお気楽なほうだな（＾＾；

177 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 14:42

>>176
あー、はっきしいってFreeBSDはお気楽じゃなイッス。
CD-ROMインストールだと初心者は最初のとこで、必ずつまずくっす。
ftpインストールなら若干ましっすけど、xDSL/CATV/T1クラスじゃないと
実用にかけるっす。

お気楽ってーのは赤帽なんかのことをいうっす。

# NetBSD/OpenBSD/Debianなんかは、環境設定地獄っていうっす。

178 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 14:50

>>177
176っす。
NetやOpenと比べてお気楽だと思ったっす。
お気楽でも、勉強になるレベルだと思うっす。

モチベーションが高くない人は,転んだら嫌になっちゃうけど
やる気がある人は、たくさん転んだほうがいいよね。
# というか、俺もたくさん転んだなぁ.

179 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 16:14

>>171
マイナーOSは確かに標的にされにくいが、
FreeBSDは最近米国で「Linuxより堅牢」的な宣伝がメディアで
流れるようになってきており、マイナーとは言えない
同じx86で動くOSなのでセキュリティ・ホールもLinuxと共通な
場合が多いが、その割に安全と思ってるユーザーが多いので、
結構危険な状況にある

アーキテクチャ変えて（Alphaとか）、NetBSDとか使えば多少
はましだろうが、そういう考え方（マイナーだから安全）で
セキュリティを考えるのは根本的に間違っている

# 田舎は泥棒の心配がないって言ってるのと同じ
# 相互監視が効かなくなっていると、田舎でも危険

180 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 16:35

securityに CPU archってそんな関係するんですか?>>179
FOOFバグをいまさらつくわけでなし。
stackをいじりやすいとかいうのかしらん。

181 ：179 ：2001/04/15(日) 16:45

>>180
うひー、そうくるとは思わんかった(^^;
まぁ、あくまでScript Kiddyを防げるってことね
自分で各arch用のバイナリ仕込める相手には関係ないよ

>stackをいじりやすいとかいうのかしらん
x86なら厨房でも自動化ツールでいじれるが、非x86なら
自分で書かなきゃいけないってだけ。もちろん、アーキ
テクチャそのものに問題があるわけではないです

# マイナーOSなら安全ってのと同じ考え方だけど、
# OSとarchの両方でやれば多少は安全になる

182 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 18:01

mac の おばふろ いやそ

183 ：でもねえ・・ ：2001/04/15(日) 19:40

BSD系しかいじったことがないと、
Redhatの設定はうんざりしてくる。　　＞　177
（10年前に、ultrixからUNIXに入ったおっさん。）　

184 ：怠け者 ：2001/04/15(日) 20:15

なんだかんだ言って minor=安全 ていうのはある程度真なので…

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

結論
狙われたら最後だが、通り魔ぐらいふせげるだろうぉ

186 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 23:09

ふぃ〜疲れたッス。土日引きこもってBSDと格闘した結果、アヤシゲながらもgnomeまでは行けました。
こんなに大変とは思ってもなかった。やはりWindowsはすばらしいね。
gnomeまで行けたといってもかなりアヤシゲです。
常にroot、ヘタに電源を切ると二度と起動しない(bin/shがないと言ってくる）、英語…
gnomeになってもよく分かりません。しかし美しいね、gnomeは。登山家の気分です。
コマンドがまったく分からないので入門書を買ってくる予定
もう２０回くらいは再インストールを繰り返したかな。

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

>>186
終了の時は
shutdown -h now
ぐらい使いなさい．

188 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 23:38

>>187
普通〜, sync;sync;haltでしょ。

189 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 23:42

sync;sync;sync;halt

190 ：名無しさん＠お腹いっぱい。 ：2001/04/15(日) 23:42

終了のときはgnomeからrebootして、BSDを立ち上げる前にハード的に落とすか
BSDを立ち上げずにWindowsを立ち上げて、終了してます

191 ：名無しさん＠お腹いっぱい。 ：2001/04/16(月) 01:05

>>188
どこが普通なんじゃ。(藁

192 ：名無しさん＠お腹いっぱい。 ：2001/04/16(月) 10:32

>>189
むかーしから疑問なんだけど、なんでsyncは三回唱えなきゃいけないの?
はずかしくってだれにもきけなくて今日まで来ちゃった。

193 ：名無しさん＠お腹いっぱい。 ：2001/04/16(月) 11:33

>>192
２カイでOK。
IBMのthink think tinkoだっけ(w

194 ：名無しさん＠お腹いっぱい。 ：2001/04/16(月) 12:36

>>192
みんな臆病者だから

195 ：名無しさん＠お腹いっぱい。 ：2001/04/16(月) 16:11

appleは「tinko different!」

196 ：弱い者の味方、 ：2001/04/16(月) 21:17

月光仮面おじさん登場!!!
ホームページを作ったものの、まったくアクセスが上がらな
くて悩んでいる人のためにお役に立ちましょう。
効率よく宣伝できる共有宣伝掲示板を18個設置しました。
全部宣伝して回ればなんと1,000以上の掲示板にカキコしたこ
とになり即、効果が期待できます。さらに共有掲示板の隠し
リンクを発見してそれらも全部宣伝して回ると計2,000以上の
掲示板にカキコしたことになり、さらにアクセスアップを期
待できます。もう、今日からアクセスが無くて悩むことは無
いです。今すぐここからアタックアタック!!

http://home9.highway.ne.jp/cym10262/

197 ：CCルリたん。 ：2001/04/17(火) 00:55

>>196
UNIX板なんだから、もっと役にたつことやろうよ。

フリーソフトのインストの仕方とか、
英語のマニュアルの日本語訳とか、
OSのインストのしかたとか、

をホームページに書いて作って、FreeBSD-users-jpや
linux-usersで宣伝すれば、アクセスすぐ増えるよ。

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 とかを使うプログラムはダメかも

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