*BSDがLinuxに勝っている点を何とか挙げていくスレ

万が一あったら書き込んでください

ありません

終了

使ってると偉そうに見える

歴史

アルファベット３文字が似合う

デーモン君の方がかわいい

各*BSDの名称の方がLinuxより文字数が多い。

-------------------------------終了----------------------------------

>>8
終了が早いってことか？

Fin.

BSDを使っている大人はこーゆー若造が立てたスレに書き込まない所が勝ちじゃね？

>>1
そんなの存在しない

ファイルシステムにsoftupdate。copy on writeとほぼ同じ。
ext3の様な単純なジャーナリングファイルシステムよりも優秀。

ブランド女の振る舞いの如く、玄人振れるとこ

「Linuxを使って居ます」と言っても「モー娘の名前を全部言えます」
程度の威力しかないが、「FreeBSDを使って居ます」と言えば
「美空ひばりのレコーディングに参加した演奏家の名前を全部言えます」
ぐらいの威力がある。NetBSDやOpenBSDだったら、凄過ぎて、
「それ何？」で終ってしまう事も多いから御用心

デーモン君のきもさ

あのペンギンも結構キモいからなあ
死体画像なみ
だからその点は甲乙つけがたい

>>13
同感
ext3 (その他のLinuxのファイルシステム使ってません)が、
ファイルアクセスすればするほど、メモリ・キャッシュ取りすぎ！
ここに何か欠陥隠しをしてるんだろうけど？
プロセス全体に負荷がかかるは、やめて欲しいな。

・・・専用機だから、仕方がない。そんな使われ方ですよ。
高負荷を与えて、ssh,telnetも出来ないのは頂けない。

ﾊﾞｶ発見

>>19
ここを説明してくれない？
空き容量、５Ｇはある、そこに４０Ｇのファイルを作ると宣言する。
Linuxは、どうぞと返事する。

さて、それを信じて書き込むとエラーだって。
ＯＳを信じるのが、バカってことか？

どうにかしてくれよ、Linuxだろ！

BSD派は確実に確保しようとする。
処理時間掛かってもね。確実に確保したいから。
確認してＯＫってＯＳが言って、後で訂正は面倒だよ。

エラー処理のコードを書くのが、面倒なんです。

では、意味ある回答を望みますw

19じゃないけど、空き容量の問題が出なくともエラー処理は必要。

　　 ／￣￣＼
　／　　 _ノ　　＼
　|　　　 （ ●）（●）
.　|　　　　 （__人__）
　 |　　　　　｀ ⌒´ﾉ
.　 |　　　　　　 　 }　　ミ　　　　　　　　ﾋﾟｺｯ
.　 ヽ　　　　　 　 }　ミ　 ／＼　　,☆＿＿__
　　 ヽ　　　　　ノ　　　　＼　 ＼ ／　　 　　＼　>>20
　　　/　　　 く　　＼.　　／＼／　─　 　 ─　＼
　　　|　　　　　`ー一⌒)　 ／ 　 （●） 　（●）　 ＼
　 　 |　　　　i´￣￣￣ ＼ |　 　 　 （__人__）　　 　 |
　　　　　　　　　　　　　　　＼＿　　 ｀ ⌒´　 　　／
　　　　　　　　　　　　　　　　／　　　 　　　　　　＼

BSD終わってるな

SCOに噛み付かれることは無いのは大きなアドバンテーーーージ！

過去に噛み付かれましたから〜

経験則的に、同じマシン2台あってLinuxとFreeBSDをそれぞれ入れて同負荷をかけた場合
（タスクは一般的なWeb兼メールサーバ）、先にマシンが死ぬのはLinuxじゃないかという気がします。
1年以内にHDDが死ぬのは決まってLinux入れた方。

>>26
んなもん ハードウェアの品質の揺らぎの方が大きい

自由自由うるさい犬っころよりもっと自由なライセンス

糞厨房のLinusとは無関係

厨房率が低いのは勝ってるとこかもしれないけど


それって 間口が狭い＝先が暗い って事だよもん？

それは両面あるんだよもん

BSDスレは厨房だらけじゃんか

× 厨房
〇 キテガイ

ウニ板のスレに限っては
真性なのか釣りなのかジョークなのかはかりかねて手出ししにくい

IPv6関連(KAME)かな。
最近のFreeBSDでは変更が激しくて少し怪しい気がするけど。

Linux って SYNC でディスクに書けと言っても、書き終わる前にリターンするとかだったけ。

あと
ttp://www.sodan.ecc.u-tokyo.ac.jp/~kei/sched/
とか見てると、スケジューラの作りもいい加減そうだし…（2.4 のころの話みたいだけど）

ちょっとでも軽くする為に、機能がちょっとぐらいいい加減でもいいというのが感じられて、
正直そんな OS は使いたいとは思わない。

>>36
定番ですな。いつまでも*BSD使っててください。

>>37
まったくだ。それが一番だよね。

>>36 って、どこのｺﾋﾟﾍﾟ？

>>39
コピペじゃなくて、ここで初めて書いたんだけど。

m:nのスレッドは良いね。1:1なんてlinux方面は脳みそ足りないんじゃないの

ttp://digest.coris.org.uk/src/20070210/digest.html

m:nでうまくいかなかった上に、バカにしていた方向にあとから
方針転換するのはカッコ悪いよねえ

*BSD(特にFreeBSD)では何度となく繰り返された道じゃないか
結果Linuxの後追いになってしまうという

ttp://jeffr-tech.livejournal.com/6268.html#cutid1

世界中でどれだけのリソースが無駄になってるかと想像すると怖くなるな(w

「Linux が好き」という人より「FreeBSD が好き」という人の方が多いらしい。

ttp://www.sucks-rocks.com/rate/windows/linux/os+x/freebsd

>>46
LinuxからFreeBSDに移行した友人がいます。
彼の話ではどのパッチを当てるのがいいとか
Linuxは問題が複雑だけれども、

FreeBSDのほうが瑣末なことにわずわらされ
ないからとのことでした。

Linuxでは「○○がしたい？それならこのパッチ当ててくれ。」って事が多いんだよな。
FreeBSDは最初はパッチでもいつの間にか正式に取り込まれてるから楽だよな。

Debianとか使ってると気持ち悪い、シンプルなNetBSDが良い

会社的な事情でGPLを避けたいときに*BSD使うこと多い

悪魔のほうがペンギンより強いだろ

ペンギンなんぞは槍で串刺しだ！
だれかAA作ってよ

焼き鳥AAでええがな

>>36
え？そうなの？
じゃぁ、
sync; sync; reboot の２回のsyncは意味がないってことか

ports collection がある限り、野良ビルドはほとんどないな。
Linux 使ってると、野良ビルドばかりするはめになる。

低能は死ぬまで野良ビルドしてな。

*BSDだと野良ビルドするが、Linuxだと野良ビルドは余りしないな

そもそもソースの配布元が、FreeBSDでもそのままビルドできるように
configureとかも含めて配布しているのに、
なぜportsのローカルなpatchを当てなければならないのか?

オリジナルに忠実にビルドするには野良ビルドが基本。
portsなんか使わない。

Debian使ってるけど、こんなスレ読んでたらFreeBSDとか試してみたくなった。
6.2と5.5ならどっちがお薦めですか？

Linuxのファイルシステムの方がディスクの寿命が短くなるって本当？

まずは新しい方試してみればどうでしょうか

>>59 5系は暗黒神話です
ディスクの寿命云々は聞いたこと無い。

ports使う理由は依存関係とそれに関連して共有ライブラリ
バージョン間互換性の問題が大きいと思う。

特定のアプリケーションしか使わないならどうでもいいん
じゃない? 自分で面倒見れるなら問題ない。

>>60
>>61
レスありがとうございます。取り合えず6.2落として、来週にでも余ってるPCに入れて遊んでみます。
ディスク云々と書いたのは>>26に経験則的に〜っていうのがあったもので、本当かなぁって思ったからです。
空きPCで遊ぶのでどうでもいい問題ですけどw

STABLE用のportsから作られたpackagesは、
内容が逐次更新されているのに、元ソースのバージョン番号が同じなら、
packagesのバージョン番号も同じ=packagesのファイル名が同じ、
で、これが非常に困る。
同じファイル名なのに中身が違っていて、しかも、
ライブラリの依存関係が変更されていて正常に動かないことがある。
packagesに、なぜ枝番を付けないんだろうか?
というわけで、ports/packagesを使ってもライブラリの依存関係は
全然解決にならないよ。

>>54
> sync; sync; reboot の２回のsyncは意味がないってことか

もっと酷い話だと A, B という順に書いて B が先に書かれるケースがある > Linux
だから Oracle/Linux もある種のロールバックを保証してなかったはず。

ずいぶんと空想力が豊かなようで

ｸｰｿｰしてから

ところでハードディスクにキャッシュがある場合、いちいちキャッシュをフラッシュ（やったっけ？）しないと
確か書き込み手順が守られないはずだけど、*BSD の場合はどうなってる？
まあ Linux は聞こうとも思わないけど…。

>>67
softupdate はバッファ内の順序認識でそれを保証してる。
つまり「Bの前にAが書かれないといけない」→「Aの書き込み成功が無いとBは書かない」
こういった順序関係の無いデータはなるべく平行して(一度に)書こうとする。

まぁLinuxはアレだ。知りたい奴はぐぐってくれ(w

>>68
67はsoftupdateの下の話をしていると思うんだが。

>>69
だから softupdate のレイヤでそれを保証してるんだってば。
わからんかったらソース読め。

ttp://www.unixuser.org/~euske/doc/openssh/theointerview2001.html

> これはファイルシステムをできるかぎり高信頼性には
> するけれど、一般的なオペレーションの速度を犠牲に
> する。たくさんの古い CSRG のテクニカルレポートを
> みれば、なぜこれがファイルシステムを安全にするか
> はっきり説明しているよ (そしてぼくは Linux コミュ
> ニティはこれに対してまったく無知だと思うね。彼ら
> はそろそろ ext2fs のような完全に非同期なファイル
> システムは危険だということを認めるときだ。Linux
> 管理者がすでにそのことを知っていなければの話だが)。

怠け者のことは怠け者と呼ぶべきだし
マニュアルページを読まない奴のことは負け犬と呼ぶべきだし

>>67
FreeBSDも6以降はフラッシュしない

>>68
softupdateは外づけRAIDユニットの中のキャッシュの
データの書き込み順序も保証してくれるのかにゃ？

RAID との責任分担を考えれば自明な気がするけど、仮
に softupdate で面倒見れないならどうやっても駄目な
んじゃ?

ではローカルのATA HDDの中のキャッシュは？

とりあえず RAID も ata もコントローラに flush リク
エスト出してるコードは見つけた。今度いつ呼ばれるか
探してみる（抽象化レイヤがややこしい…）。

>>77
他力だけど、楽しみに待ってるよ。
>>73
なぜ？

>>78
後者は多分 hw.ata.wc の扱いの話だとおも

すまん、ギブ。とりあえず flush してるとこ。

/usr/src/sys/dev/ata/ata-disk.c:ad_dump
/usr/src/sys/dev/ata/ata-raid.c:ata_raid_dump

共に長さ 0 の dump で flush の意味になってて、
attach 時に *->disk->d_dump に設定される（ioctl の
方は追い掛けきらなかった）。

トランザクションの終りはこの辺りかなと思うけどよく
わからない。

/usr/src/sys/kern/subr_devstat.c:devstat_end_transaction

>>80
サンクス

RAIDってATA RAIDのことかよ。

>>82
他の RAID も各社ドライバ毎になってるけど似たような
もんだと思う。

vfs_bio.c:bufwrite がそれかな。非同期だとバックグ
ラウンドで、同期だとその場で I/O オペレーションの
終了を待ってる。

デバイスが「write-I/O が終わった」というなら、それ
以降の責務はデバイスが持つというスタンスじゃない?

geomでファイルシステム上に作ったファイルをmountして
フォーマットしたときに、「write-I/Oが終わった」という
デバイスはどれになるの?
geom?HDD?

/usr/src/sys/geom/geom_subr.c:g_attach で割り当て
られたデバイス、つまり上の場合 HDD ではないかと想
像するが自信はない。

おっと、その前にファイルシステムレイヤが入るかも。

ttp://lists.freebsd.org/pipermail/freebsd-hardware/2004-October/001990.html

ちょっと古い情報だけど。

・きちんとしたハードウェア RAID ならドライブ内の
キャッシュを無効にするし、バッテリバックアップ付き
のキャッシュを持っている（書き込み保証がある）。

・タグつき書き込み対応ドライブなら複数の write 要
求を同時にこなせて、それぞれのステータスを取得でき
る。

・一台こっきりのディスクなら hw.ata.wc=0 にするの
が安全だけど遅すぎるのでデフォルトは 1。

ってところか。

まぁ softupdates が保証するのもファイルシステムの
整合性だけであってユーザデータがどうなろうと知った
こっちゃないわけで、バックアップ取っとけってことで
すな。

>>88
>> softupdates が保証するのもファイルシステムの整合性だけ
保証できているかが議論の対象なんですよね？

そもそも守りたいのはファイルシステムの整合性じゃなくてユーザーデータ。
ただユーザーデータを守るにはファイルシステムを守らないといけない。
鶏が先か卵が先か。

全然にわたま違うやん。
ファイルシステムを守ってもユーザデータを守れるとは限らない。
ユーザーデータを守る方法はほかにいくらでもある。

>>91
それを認めるとこのスレの趣旨を真っ向から否定することになるわけだが

>>89
>>> softupdates が保証するのもファイルシステムの整合性だけ
>保証できているかが議論の対象なんですよね？

多分それもレイヤに分割されて、

1) softupdates の考え方だと保証できる
2) 1 に基づいて正しく設計されてる
3) 2 に基づいて正しく実装されてる

という話なんだろうね。で、1 ですら懐疑的な人がいて
話が進展しなかったり…。

「え？結局バックアップ頼り？じゃあ危ない橋渡ってで
も早い方がいいじゃん」ってのもあるのかな。

>>93
ttp://journal.mycom.co.jp/articles/2007/03/13/bluffs/002.html
1でも、今世紀のデバイスでは保証できないことが多い、という状況じゃないかな。

リッチな解決：
バッテリバックアップキャッシュなRAIDを組む。
バッテリバックアップキャッシュなドライブを買う。

プアな解決：
WriteCache を無効にする。

？な解決：
安全性よりスピードを優先して WriteCache を有効にし、
バックアップ頻度を上げる。

…っていう運用の話になるのかね？

>プアな解決
実際問題として、これで運用できるのかな。
管理してるだけで自分は使ってないよっていうのはなしで。

IDEじゃなくてSCSIにする。

>>97
SCSIにしてWriteCacheをdisableにするの？

write throughなドライブを買えばよいのか。

>>98
ttp://en.wikipedia.org/wiki/Tagged_Command_Queuing

この最後に completion message がどうの、とあるんで
それ使えるんじゃないかな。

「高速化のためにディスク内で書き出し実行を入れ替え
てもそれぞれの終りが検出できれば良い（安全なものだ
け並列実行する）」というのは、ちょっと考えれば「ディ
スク内キャッシュを使わなくてもホスト側で充分に大き
な外向きバッファがある」のと結局同じ話になると思う
（softupdates はバッファ内で安全な入れ替えや統合を
行うから）。

ところが上のレポートにもあったように実際はかなり遅
くなる。すぐに思いつくのは

１）想定している「連続領域」が実際は連続していない
（ディスク側とディスク構造やエレベータに関する認識
が違う）。

２）外向きバッファが充分に効率よく稼動していない
（I/O の書き出しキューに入ってしまうと統合／入れ替
え対象外になってしまう）。

って辺りかな（外してるかもだ）。

書き出しに使ったバッファはそのまま読み出しキャッシュ
として再利用してるので、非常に遅くなるのは何か致命
的な部分がある気がする。これも SMPng みたいに特定
の状況下でチューンすべきかもね。

家族にエロ画像を覗かれない。
LINUXもその辺かなり強固だが、BSDは群を抜いている。

おれデスクトップが *.aviでいっぱい。
お袋がEnter押しただけでxineが上がって、、、、