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

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

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

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

それではどうぞ

143 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 10:22

windowsが好きです

144 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 10:32

Windows...。忘れたころに触ることになってやけどして、
また嫌いになる。

Hiroshima　45, Chernobyl 86, Windows 95

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

FreeBSDのJava2環境はどうなっとるんじゃあああ。
頼むから、はよだして。。。

146 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 11:30

http://us.xmach.org/

147 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 15:36

>>145
ご自慢のLinux互換APIで動かせば？（藁）
SunのもIBMのも動いたと思ったが。
FreeBSD JDKにこだわるならNateのケツ叩け

# しかしLinuxバイナリに頼るなんて屈辱だな，おい（ギャハハ

148 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 16:18

>>147 は *BSD 間の共通 binary を Linux なものにしようとかいう
意見があることを知らない厨房

149 ：どっちかつーとBSD派 ：2001/04/14(土) 16:26

>>9
McKusick御大がBSDMagで「カーネルが各BSDで統一されていない」と言ってい
たことについてどう思われますか？

150 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 16:32

*BSD: ドラクエ
Linux: FF

ゲームはドラクエの方が好きだが、OS は Linux 使ってる。

151 ：147 ：2001/04/14(土) 17:45

>>148
うん，知らねぇ（ゲラ
で，共通バイナリはLinuxになんのか？
いつからなるんだ。5.0-Releaseか？
145が我慢できるほどすぐなのか。

つーか，偉そうなことはやってから言えや

152 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 18:06

関係ないけど (ゲラ っていうのがいいね。気に入った。

153 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 18:35

(ゲラはどうでもいいが、無知を素直に認めたのが気に入った

154 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 18:41

>>148
バイナリ形式は ELF で決まりだろうけど、これは Linux 由
来ってわけじゃないし、すでに FreeBSD, NetBSD とも ELF
だよね。(OpenBSD は知らん)

もしかして、ABI を Linux に合わせようって言ってるの？
それだと *BSD 独自のシステムコールが実装できなくなる
から、ありえないと思うんだが。

155 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 21:24

それよりなにより、FreeBSDもサポートしろ！！＞Sun

156 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 22:01

>>150
いいたいことはわかるけどね･･･
あなた、あんまやらなかったでしょ、ff&ドラクエ。
やりこみがたりんかも

>>154
openbsd は elf だよ。
jdk は linux のが動く。

jdk だけど、スタンフォード対バークレイってほんとかね？
なんでも sun がスタンフォートよりだからって話だよね。
もともと bsd なんだからたのんますよ。

157 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 22:55

SMP (Dual P-III)でベンチやったら、FreeBSDよりLinuxの方が一割速かったぞ。
サーバ用途でも大規模なものだと自動的にLinuxじゃねーか？（ゲラ

158 ：名無しさん＠お腹いっぱい。 ：2001/04/14(土) 22:59

157はまともなカーネルを作れなかった。

と仮定してみる。

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

一応きいとこうか。
まともなカーネルって？
*BSDだって何年も使ってるんだぜ？

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を要求されてるってことですか。
で、話がもとにもどると。

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