トップページ⇒unix
982コメント270KB

FreeBSD current 一握の砂

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。NGNG
はたらけど　はたらけど猶 わが生活
楽にならざり ぢつと手を見る

>> Shut up and code!!!

前スレは>>2-5あたり
0341名無しさん＠お腹いっぱい。2005/11/11(金) 00:36:34
　 　, -‐－-､　　ヽ∧∧∧ //　　|
. 　/////_ﾊ ヽ＜ 釣れた！＞　ハ
　 ﾚ//ｊ け ,fjlﾘ　/ ∨∨V ヽ　　h. ﾟl;
　ﾊｲｲﾄ､"ヮノﾊ　　　　　//　　　|::: ｊ　　｡
　 /⌒ヽヾ'ﾘ、　　　　　// 　 　　ヾ､≦ '
.　{ 　　j｀ｰ' ﾊ 　 　 　//　ヽ∧∧∧∧∧∧∨/
　 ｋ～'ｌ 　　ﾚﾍ. 　 ,r'ス　＜ 初めてなのに　＞
　 |　ヽ ＼　ト､ ヽ-kヾｿ　＜ 釣れちゃった！＞
.　 l　　＼ ｀ｰ‐ゝ-〈/´　　　/ ∨∨∨∨∨∨ヽ
　　l 　 　 `ー-､___ﾉ
　　ﾊ 　 ´￣｀　〈/‐-､
0342名無しさん＠お腹いっぱい。2005/11/11(金) 08:53:38
>>336
>けど62件じゃ定訳といえる程浸透している
>ともいえないか...

「POLA」を翻訳する試み自体が少ないということでしょうね。
「わざと、まわりくどい表現をする文化」を尊重するならば訳も

「驚き最小の原則」

が適当かも知れませんが、字面から意味がわかる点で>>328の
「踏襲原則」というのも付加して

「驚き最小の原則」(踏襲原則)

などと書いておくと、解説上はより良いでしょうね。
0343名無しさん＠お腹いっぱい。2005/11/11(金) 10:05:21
ここでいってるPOLAはRuby方面の驚き最小原則と同じものなの?
だとすると、他の部分の仕様からの類推・同じ文化圏のメジャーな慣習・
同種の別のものの知識・その他常識など(以前の仕様はその一つ)から
ユーザが自分の知らない部分に関して「おそらくこうであろう」と
意識的・無意識的に期待する予想からなるべく外れないようにしようと
いうものなので、
先例の存在を強く示唆する踏襲原則というのはいまいち意味が狭いんじゃ
ないかと思うけど。驚きという言葉を使わないで意訳するという方向
そのものはよいと思う。

意識的・無意識的な予想を前提としてそれに反することを指すのに、
英語ではastonishmentやらsurpriseやらと随分大味な言葉が使われても
日本語にはもう少し的確な言葉がある。「驚き」よりも「案外」でどうか。
ユーザの予期という案に相違することを表すわけだから。そういうわけで、
案外最小原則、もしくは案外回避則でどうだろうか。
「案外」という言葉は副詞で使われることが多いので、
慣れないと多少変に見えるかも知れないが。

勝手に提案する類語集
・予想通り 案の定 予想の範囲内
・驚き 案外 予想の範囲外

ひっくり返して「予想の範囲内優先則」でもいいけど。
0344名無しさん＠お腹いっぱい。2005/11/11(金) 10:29:58
「互換性優先」というのとは同じではないのか?
0345名無しさん＠お腹いっぱい。2005/11/11(金) 18:57:40
MRTGをrrdtoolに変えるときみたいな事すんな。

でいいんじゃね。
0346名無しさん＠お腹いっぱい。2005/11/11(金) 22:06:41
無難主義
表音文字の癖して略すなってーの
0347名無しさん＠お腹いっぱい。2005/11/11(金) 22:20:58
BSD も TCP も IP も MAC も GPT も翻訳しないんだから、POLA も
POLA<sup>*1</sup> <footnote>*1 Principle of Least Astonishment、原則として
直感的でないことをなるべく避けること</footnote>
程度でいいじゃん。
0348名無しさん＠お腹いっぱい。2005/11/12(土) 00:23:13
>>347
うん。いいんじゃねそれで。
0349名無しさん＠お腹いっぱい。2005/11/12(土) 00:24:17
>>347
そこの一行目で引かれた例よりも
MFCとかのほうがいいかも。レスの趣旨には同意だけど。
0350名無しさん＠お腹いっぱい。2005/11/13(日) 18:26:24
今の current って7?
0351名無しさん＠お腹いっぱい。2005/11/13(日) 23:59:43
pflogでログ取れなくなったの俺だけ?
0352名無しさん＠お腹いっぱい。2005/11/14(月) 13:26:53
>>351
そう言われてみるとうちもだ.
FreeBSD 7.0-CURRENT #8: Sat Oct 29 19:06:16 JST 2005.
な奴だが, いつからだろう?
03533512005/11/14(月) 21:57:57
自己解決スマスタ

options DEV_PFLOG=1
0354名無しさん＠お腹いっぱい。2005/11/25(金) 22:24:40
P^HBill ;-)
ttp://lists.FreeBSD.org/pipermail/freebsd-current/2005-November/058424.html
0355名無しさん＠お腹いっぱい。2005/11/25(金) 22:37:52
絶妙なコミットログにﾜﾛﾀ
ttp://docs.freebsd.org/cgi/mid.cgi?200511240053.jAO0rEi6024317
0356名無しさん＠お腹いっぱい。2005/11/25(金) 23:55:09
あいかわらずwpaulはマジギレしてるのか
0357名無しさん＠お腹いっぱい。2005/11/26(土) 20:26:00
>>355
-longbio_resid;/* Remaining I/0 in bytes. */
+longbio_resid;/* Remaining I/O in bytes. */

暴カニ男みたいなもんかw
03583542005/11/27(日) 19:53:16
>>356 いや、あれずっとキレ芸やと思っててんけど
0359名無しさん＠お腹いっぱい。2005/11/29(火) 21:57:07
なんか凄いのｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058514.html
0360名無しさん＠お腹いっぱい。2005/11/29(火) 22:55:07
>>359
なんかもうある、とか、2個作ってどないすんねん、みたいな展開になっておりますか？
0361名無しさん＠お腹いっぱい。2005/11/29(火) 23:27:02
もうある、ってのは赤黒木の実装の部分についてだから
あんまり重要な話じゃないよね。

そういや、一年ほど前にphkがこんなこと言ってた。
http://lists.freebsd.org/pipermail/freebsd-arch/2004-September/002693.html
0362名無しさん＠お腹いっぱい。2005/12/01(木) 02:14:40
2個あるならいい方を採用すればいいじゃん
0363名無しさん＠お腹いっぱい。2005/12/01(木) 10:49:06
やっときたか.
> Subject: HEADS UP: Adding /usr/local/etc/rc.d to the base rcorder
未対応な ports ってどのくらいあるんだろ?
0364名無しさん＠お腹いっぱい。2005/12/01(木) 19:06:28
port maintainerにもわかるrcNGみたいな文書がいるんじゃないか。
メンテナって有象無象だから賢いのからアホなのまでピンキリなのよね。
0365名無しさん＠お腹いっぱい。2005/12/01(木) 19:27:16
rcNG非対応のもstartupのときには実行してくれるように見えるんだけど。
03663652005/12/01(木) 19:32:01
あ、shutdownのときもstop付けて実行してくれるのか。
…だいじょうぶかなぁ。
0367名無しさん＠お腹いっぱい。2005/12/01(木) 20:43:24
賢い/アホ とかじゃなくて ガイダンス文書くらいないと
よくわからないよー

well commented example でいいんだけど
0368名無しさん＠お腹いっぱい。2005/12/01(木) 23:39:23
rc.d(8) 実態は rc(8)
0369名無しさん＠お腹いっぱい。2005/12/02(金) 00:30:45
>>365
ports A, B, C が起動順に依存関係があって, A, C は対応してるけど
B だけ取り残されてる場合とかって大丈夫なんかい?

# 今, 出張先なんで変更部分まだ見てない.
0370名無しさん＠お腹いっぱい。2005/12/02(金) 01:46:14
そーゆー時は A C が依存関係通りに動いて、最後に B になるんじゃない?
B もよしなに動いて欲しければ send-pr。
0371名無しさん＠お腹いっぱい。2005/12/02(金) 02:17:20
とりあえず実行スクリプト名を順序通り変えておくくらいの
work around は可能だね。
0372名無しさん＠お腹いっぱい。2005/12/02(金) 06:40:27
>>369
B は rcNG 非対応だけど C が rcNG 対応って状況は存在しにくいんじゃない？
C は B に依存するってことで、C の rc script に REQUIRE: B を書いてしまうと、
B の provider はいないということでエラーになるはず。

0373名無しさん＠お腹いっぱい。2005/12/02(金) 09:51:46
部分的にportupgradeし忘れ、みたいな
0374名無しさん＠お腹いっぱい。2005/12/02(金) 22:37:06
rcorderが適当にアルファベット順で
0375名無しさん＠お腹いっぱい。2005/12/03(土) 09:06:43
アルファベット整列モードとrcorder通常モードとあって、
通常モードの場合はルールが書いていないと警告を出して欲しいのだけど...
0376名無しさん＠お腹いっぱい。2005/12/03(土) 11:20:28
*.sh はこれまでどおり文字コード順、拡張子を持たないものが
rcorder されるみたい。
0377名無しさん＠お腹いっぱい。2005/12/03(土) 12:04:34
げ、使いたくないものを hoge.sh => hoge.sh.OFF みたいに
してるんだけどアカンちゅうことか?
0378名無しさん＠お腹いっぱい。2005/12/03(土) 12:29:57
chmod -x
0379名無しさん＠お腹いっぱい。2005/12/03(土) 12:32:04
今回の変更について、freebsd-portsに流れたメールを紹介しておこう
http://lists.freebsd.org/pipermail/freebsd-ports/2005-December/027897.html
0380名無しさん＠お腹いっぱい。2005/12/03(土) 12:36:19
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.diff?r1=1.336&r2=1.337
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.subr.diff?r1=1.43&r2=1.44
"# PROVIDE:" があるスクリプトは rcorder して実行
無いスクリプトはこれまで通り *.sh に限って実行
0381名無しさん＠お腹いっぱい。2005/12/03(土) 14:53:00
>380
解説 thx.
0382名無しさん＠お腹いっぱい。2005/12/06(火) 17:09:46
12/3 早朝の current で、ブート時に /etc/rc.d/* の方で起動させている
cron, inetd, sendmail(実体はpostfix), sshd
が立ち上がらなくなった。
仕方なく /etc/rc.local に書いてしのいでいる。
natd, nfsd, syslogd, ...
あたりは問題なく立ち上がるのに。
0383名無しさん＠お腹いっぱい。2005/12/06(火) 17:28:29
これで直ったはずだよ
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.subr.diff?r1=1.44&r2=1.45
03843822005/12/06(火) 17:58:10
>>383 thanks. 試してみる。
0385名無しさん＠お腹いっぱい。2005/12/06(火) 19:26:17
/src/sys/kern/uipc_mqueue.c
nt_ksi.ksi_mqdないー
0386名無しさん＠お腹いっぱい。2005/12/07(水) 17:38:11
#include<sys/signalvar.h>かな orz
0387名無しさん＠お腹いっぱい。2005/12/15(木) 03:38:02
6.x がstableになってからcurrentから離れたのですが
現在どんな状況ですか?
0388嫌われ者のVipper2005/12/15(木) 08:39:33
currentのgccのバージョンはいくつですか？
0389名無しさん＠お腹いっぱい。2005/12/15(木) 11:16:47
wwwwwwwwwwww>388のFrom
3.4.4かな
0390嫌われ者のVipper2005/12/15(木) 11:36:07
>>389 私のような者へのお答え
0391嫌われ者のVipper2005/12/15(木) 11:36:32
ありがとうございます　
0392名無しさん＠お腹いっぱい。2005/12/24(土) 13:23:49
誰かPC送ったげて...
ttp://lists.freebsd.org/pipermail/freebsd-current/2005-December/059260.html
0393名無しさん＠お腹いっぱい。2005/12/24(土) 22:51:54
>392
住所わかる？
0394名無しさん＠お腹いっぱい。2005/12/25(日) 00:26:46
viが複数ウィンドウに対応していない理由みたいだ
0395名無しさん＠お腹いっぱい。2005/12/25(日) 08:09:41
良くある展開ということですか。
0396名無しさん＠お腹いっぱい。2005/12/25(日) 10:44:11
クラッシュしちゃって「もうやらねーよ、うわーん」となる話ってよくありそうじゃない？
まあ、今回はdelayと書いてあるけどさ。
0397名無しさん＠お腹いっぱい。2005/12/25(日) 23:49:42
>>394 対応してるでしょ? :E とか。
0398名無しさん＠お腹いっぱい。2005/12/27(火) 01:26:06
>>397
Unixの1/4世紀でBill Joyが対応をやめたって書いてあったけど、
素のviにもあるの？
0399名無しさん＠お腹いっぱい。2005/12/27(火) 11:24:19
>>398
『ホゲゆに』には、
最近Joyのviをサポートする連中がガンバってるって
0400名無しさん＠お腹いっぱい。2005/12/27(火) 22:31:53
7-currentで nVidiaのドライバって動きますか？
0401名無しさん＠お腹いっぱい。2005/12/31(土) 13:25:28
>400
nvidia-driverがコンパイルエラーになってインストールできない件？
うちがそんな状況。
0402名無しさん＠お腹いっぱい。2005/12/31(土) 18:26:45
>>401
レス サンクス

やっぱり動かないんだ...
まだ-current入れてないんだけど、動くなら-curerntを入れようかなって
思ったんだ。
0403名無しさん＠お腹いっぱい。2006/01/01(日) 12:03:33
一応、src/sys/pci/agpvar.hの1.3での変更を元に戻して、kernel,nvidia-dirverを作り直せば、今のcurrentででも動くよね。

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/agpvar.h
0404名無しさん＠お腹いっぱい。2006/01/01(日) 15:28:28
>>403
ttp://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/agp.c.diff?r1=1.48&r2=1.49
これと同じことをやればコンパイルはできるんじゃないの?
0405名無しさん＠お腹いっぱい。2006/01/01(日) 18:41:24
7-currentについて、方向性とか新機能についてまとめている
サイトとかありますか?
0406名無しさん＠お腹いっぱい。2006/01/01(日) 23:30:05
基本的に-currentで、デバッグオプションによる速度低下を
防ぐには、以下の２つをコメントアウトするだけで良いのでしょうか?

options WITNESS
options WITNESS_SKIPSPIN

KDBをコメントアウトすると xfs のコンパイルで、KDB関連のオプションを
有効にしろとエラーメッセージが出ます。
0407名無しさん＠お腹いっぱい。2006/01/02(月) 04:53:19
>>403
>>404
OS側のAGPではなくNVIdia のAGPドライバを使えばいいのでは?
0408名無しさん＠お腹いっぱい。2006/01/02(月) 13:51:55
>>406
ln -sf aj /etc/malloc.conf
0409名無しさん＠お腹いっぱい。2006/01/03(火) 14:38:59
最近、なんか-current安定しているよね。

MLで奴が怪しげなこと言っているときはいつも警戒していたのに...
0410名無しさん＠お腹いっぱい。2006/01/03(火) 17:10:24
>>409 「奴」って誰よ?
0411名無しさん＠お腹いっぱい。2006/01/03(火) 23:02:22
そういやlinuxpluginwrapperが使えなくなったな
中の人は何か考えているらしいが
ttp://blog.ninth-nine.com/diary/20060101.txt
0412名無しさん＠お腹いっぱい。2006/01/14(土) 21:56:06
malloc新しくなったから入れてみたらX起動しなくなった　orz
かなり遅いし、戻すか…( ´・ω・`)
0413名無しさん＠お腹いっぱい。2006/01/14(土) 22:24:38
>>412
libcのmalloc(3)を切り替えたよ。今はデバッグ、検査、統計収集用のオプションが
全部有効になってるから、プログラムは遅くなるしメモリも余計に食う。移行期間の
バタバタがおおよそ終わったらここらへんのは切れるから。
パフォーマンスが気になるなら、src/lib/libc/stdlib/malloc.cの中にある下の
いくつかをundefineして。これらのせいでプログラムが遅くなって、メモリも
余計に食ってるんだ。
MALLOC_DEBUG MALLOC_STATS MALLOC_REDZONES
もしmallocがらみの実行時エラーを見つけたら、malloc(3)でチューニング用の
フラグを調べて関係あるのを使いながら、問題の種類をみきわめてほしい。特に
A J Q Zフラグは便利だね。この実装が見つけるアプリケーションのバグは
0414名無しさん＠お腹いっぱい。2006/01/14(土) 22:37:52
* バイト境界に対する誤った仮定: このmallocはたとえ非常に大きい領域の割り当て
についても16バイト境界しか保証しない。正当だけど、あまり一般的じゃない。
phkmallocはここらへんがとても寛容だった。もしこういうバグをみつけたら
posix_memalign(3)を見て直してね。
* バッファオーバラン: このmallocはboundary tagを使っているので、割り当て
の外側に書き込むとmalloc内部のデータ構造を壊す可能性がある。小さいオーバ
ランはredzoneで検出できるけど、大きいのは無理だ。

この変更によって沢山の問題の報告が来るだろうと思う。その場合、たいていは
アプリケーションのバグだと思うけど、malloc自身のバグという可能性もある。
みんな、広い心で原因の究明に取りくもう。
0415名無しさん＠お腹いっぱい。2006/01/15(日) 01:31:15
アメリカのドラマの吹き替え口調みたいな文体だな
0416名無しさん＠お腹いっぱい。2006/01/15(日) 05:59:11
結局、mallocで一番、高速に動作するオプションはどれ?
0417名無しさん＠お腹いっぱい。2006/01/15(日) 12:04:57
つうか、なんで新しいmallocが入ることになったの？
>>413-414の解説を読むとあまり利点を感じないのだが。
0418名無しさん＠お腹いっぱい。2006/01/15(日) 13:30:10
>>417
SMP 環境でマルチスレッドのプログラムの性能を向上させるためらしい。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=783829+0+archive/2005/freebsd-current/20051225.freebsd-current

kris が4CPUのamd64マシンでベンチマークをやっているけど、スレッド数3の場合で以前のmallocより107倍早かったそうな。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=138177+0+archive/2005/freebsd-current/20051218.freebsd-current
0419名無しさん＠お腹いっぱい。2006/01/15(日) 15:54:41
最後の三行だけ抜き出すと
So libthr is *much* faster than libpthread with both malloc
implementations, but jemalloc is still 1.7 times faster for 1 thread
and 80 times faster for 5 threads than phkmalloc.

0420名無しさん＠お腹いっぱい。2006/01/15(日) 20:55:47
でもマルチスレッドでmallocしまくるような状況って
それほどあるの?
0421名無しさん＠お腹いっぱい。2006/01/15(日) 23:45:42
特にOO系の言語ではメモリアロケータのパフォーマンスが重要だから、
恩恵を受けるプログラムは結構多いんじゃない?

それに、libpthreadやlibthrによるカーネルレベルでのスレッドサポートが
せっかく入ったのに、今までのmalloc()は単一のspinlockによる
原始的な排他しかしてなかったからなあ……
0422名無しさん＠お腹いっぱい。2006/01/16(月) 02:54:56
>>412
XについてはXorg-snapを入れるというworkaroundがあるようで。
ぶっちゃけ、dlopen使えってことだな。
0423名無しさん＠お腹いっぱい。2006/01/18(水) 08:27:44
これで MySQL と FreeBSD の組み合わせが最強になるとうれしい。
関係ないですか？
0424名無しさん＠お腹いっぱい。2006/01/18(水) 09:51:46
mallocの性能の悪さも性能が劣化する原因の一つだろうからこれで少しは変わると思うよ。
つうか、こういう単純なベンチマークじゃなくてもっとリアルなアプリケーションで
ベンチマークをやった人って居ないんだろうか....
マルチスレッドのアプリケーションと言えば、MySQL、BIND、Apacheといろいろ
ありそうなのだけど。
0425名無しさん＠お腹いっぱい。2006/01/18(水) 17:13:34
実務や現場を知らない香具師の寝言。
0426名無しさん＠お腹いっぱい。2006/01/18(水) 23:21:48
そういう香具師が往々にして決裁権を持っている件について
0427名無しさん＠お腹いっぱい。2006/01/19(木) 00:00:45
現場的には今回の変更はどうなの？
新しいもの勝手に入れるなゴルァ！
今動いているのが動かなくなったらコロスケなりよ
なんだろうか。それとも、速くなりそうなので歓迎なんだろうか。
0428名無しさん＠お腹いっぱい。2006/01/19(木) 02:11:17
>>427
現場の人はcurrentには興味なしと思われ。
0429名無しさん＠お腹いっぱい。2006/01/19(木) 12:40:59
そもそも、性能に影響あるところには極力mallocを使わないようにコード書くしなぁ。
0430名無しさん＠お腹いっぱい。2006/01/21(土) 09:26:12
qemuが動かなくなっとる。。
0431名無しさん＠お腹いっぱい。2006/01/23(月) 06:46:08
mallocってマロックって読むの？
俺ずっとエムアロックと読んでて不安になった。
メモリ・アロケーションだよね？
0432名無しさん＠お腹いっぱい。2006/01/23(月) 08:09:55
どっちでもいいんじゃない？
stdioはスタンダードアイオーと読んで、スタジオと読んだりはしないけど。
0433名無しさん＠お腹いっぱい。2006/01/23(月) 09:50:14
俺はエスティーディーアイオーと四㌦
0434名無しさん＠お腹いっぱい。2006/01/23(月) 12:36:32
UNIXに関する言葉のひらがな読みスレッド
http://pc8.2ch.net/test/read.cgi/unix/1001358861/
0435名無しさん＠お腹いっぱい。2006/01/30(月) 00:29:24
12/31のvm(キャッシュ)の修正で久しぶりに動かなくなった。
オラ、ワクワクして来たぞ。
0436名無しさん＠お腹いっぱい。2006/01/30(月) 04:44:13
>>435
12/31?
0437名無しさん＠お腹いっぱい。2006/01/30(月) 20:52:35
2005/12/31 14:39の↓のコミット
古いCPUだとのdetection of the cache sizeでストールする。

MI changes:
- provide an interface (macros) to the page coloring part of the VM system,
this allows to try different coloring algorithms without the need to
touch every file [1]
- make the page queue tuning values readable: sysctl vm.stats.pagequeue
- autotuning of the page coloring values based upon the cache size instead
of options in the kernel config (disabling of the page coloring as a
kernel option is still possible)

MD changes:
- detection of the cache size: only IA32 and AMD64 (untested) contains
cache size detection code, every other arch just comes with a dummy
function (this results in the use of default values like it was the
case without the autotuning of the page coloring)
- print some more info on Intel CPU's (like we do on AMD and Transmeta
CPU's)

Note to AMD owners (IA32 and AMD64): please run "sysctl vm.stats.pagequeue"
and report if the cache* values are zero (= bug in the cache detection code)
or not.
0438名無しさん＠お腹いっぱい。2006/01/31(火) 08:50:16
仮想端末のデバイス名が /dev/pts/* に変更されつつある件について
0439名無しさん＠お腹いっぱい。2006/01/31(火) 09:21:36
デバイス名だけの変更じゃないよ。
0440名無しさん＠お腹いっぱい。2006/01/31(火) 11:03:38
そろそろcvsupしても大丈夫かな?
■ このスレッドは過去ログ倉庫に格納されています