fork(2)
forkで作った子プロセスは親プロセスとI/Oディスクリプタを共有しているとbitの別冊に書いてあった。 だから、子プロセス側でもfork前にlistenにしておいたsocketでaccept(2)を呼び出すと接続要求を受けることが出来る。 Continue reading fork(2)
bugyoのlog。決してblogではない。
forkで作った子プロセスは親プロセスとI/Oディスクリプタを共有しているとbitの別冊に書いてあった。 だから、子プロセス側でもfork前にlistenにしておいたsocketでaccept(2)を呼び出すと接続要求を受けることが出来る。 Continue reading fork(2)
NAT越えってどうやってやるんだろう、と思って引いてみました。 http://www.faqs.org/rfcs/rfc3489.html http://d.hatena.ne.jp/keyword/UPnP http://www.newport-networks.com/whitepapers/nat-traversal3.html http://dev.ariel-networks.com/articles/networkmagazine/search_technology http://homepage3.nifty.com/toremoro/p2p/p2p.html Continue reading NAT越え
http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.japanese.html Continue reading SambaでWindows NT Server と同じ転送速度を確保する方法
http://docs.freebsd.org/doc/3.4-RELEASE/usr/share/doc/ja/books/faq/book.html http://hp.vector.co.jp/authors/VA012337/freebsd/toheart.html Continue reading To Heart について
コマンドが実行に要する経過時間やシステムが処理に要した時間、コマンドが処理に要した時間などを出力するにはtimeコマンドを使う。 timeコマンドは,csh または tcsh の内部コマンドと /usr/bin/time の2種類ある。 (csh内部コマンドの出力) 1.219u 0.000s 0:01.65 73.3% 25+390972k 0+0io 4pf+0w (1) (2) (3) (4) (5) (6) (7) (1) … ユーザCPU時間(1.219秒) (2) … システムCPU時間(0.000秒) (3) … 経過時間(1.65秒) (4) … 使用された資源率(73.3%=((1)+(2)/(3))) (5) … システムメモリ量+利用者メモリ量(kB) (6) … ファイルの書き込み回数+読み込み回数(ここではともに0回) Continue reading コマンド time
PCクラスタ関係の資料(日本語) http://www.is.doshisha.ac.jp/~tomo/paper/2002/1116cluster.pd http://www.aist.go.jp/infobase/pcp/platform/uconf2/6_suzuki.pdf http://www.jstage.jst.go.jp/article/jspf/79/8/752/_pdf/-char/ja/ TFCC http://www.ieeetfcc.org/ 超並列計算研究会 http://www.is.doshisha.ac.jp/SMPP/ Beowulf http://www.debian.org/ports/beowulf/index.ja.html http://ja.wikipedia.org/wiki/Beowulf http://www.linux.or.jp/JF/JFdocs/Beowulf-HOWTO.html Continue reading PCクラスタの作り方
http://japan.cnet.com/news/sec/story/0,2000056024,20345072,00.htm 最近はtkドメインを無料で大安売りするところが現れてtkドメインの格がぐんと下がったのに加えてこれ。 なんだか悲しい。 Continue reading .tkは評判が悪い
GZIPのRFC(RFC1952)にCRCのサンプルコードが載っていた。 http://tools.ietf.org/html/rfc1952 日本語訳があった。 http://www.futomi.com/lecture/japanese/rfc1952.html Continue reading CRC
MovableTypeを入れているサーバにログインしたら、loadが13を超えていて驚いた。 psしてみると、MovableTypeのコメント処理用のCGIプロセスがいっぱいあって、どうやらコメントスパムにアタックされ中だったみたい。 10分ぐらいでおとなしくなったのでログインして見てみると、スパムコメントが35件入っていた。 意外と少ない。 そう言えば、ドライバが無いからHDDとの通信モードがDMAになっていないのだった。 早いとこマザーボードを買い換えようと思ってたところだったんだっけ。 それにしてもMobableTypeって重いな。 使ってるデータベースを変えたらどうだろう、と思ってDBMの速度について引いてみたりした。 結果はいろいろ。 http://www.syon.co.jp/syontech/tech017.html によると、特に設定しない場合ではどのDBMも100%の以上差は出て無かった(FreeBSD)。 http://www.jpring.net/jitaku/MovableType-mysql.html では5~10倍も差が出ている様子。 入っているエントリー数でも差がある様。 ( http://30smash.main.jp/mt/customize3/sqlite.html ) MT3.2ではBerkeleyDBでは再構築時に問題が起こっていたらしい。 ( http://bizcaz.com/archives/2006/08/02-065216.php ) それが負のイメージを喚起するのかどうかは分からないけど、巷ではBerkeleyDBが遅いという事になっているらしい。 http://nlogn.ath.cx/archives/000426.html 適切に設定すればMySQLやPostgreSQLなどは数倍早くなるらしいからその状態での話なのかもしれない。 http://www.sixapart.jp/movabletype/developers/naoya/archives/2004/08/movable_type_rd_1.html によると運用・保守性を求めるならMySQLやPostgreSQLを使うのがよろしいとのことだった。 データの数が多い大規模運営する場合はいろんな面でMySQLやPostgreSQLにしたほうがよいかも。 つまり小規模で、SQLとかを使いこなせてないとどれも変わらないということか。 と言うことにしておいたけど、中身を知っている人に聞くのが一番いいかも。 マザーボードを買い換えるのが先決ということは分かった。 http://takusato.net/article/bdb_oboegaki.html Continue reading DBの速度
Intelが出しているオープンソースの画像処理ライブラリらしい。 ライセンスはBSD。 Windows、Linuxで使えるらしい。 FreeBSDでmakeしたひともいるみたい(MacOSXでも)。 速そう。 Continue reading OpenCV