ちらほら雪も積もってスキー・スノボっ子には嬉しい季節になりました。
ところで今年はメインのケータイをガラケーからiPhone4Sに変え、
所持しながら滑るか、それともロッカーに預けておくべきなのか悩みました。

毎年、何だかんだで友達とはぐれてしまってケータイのお世話になります。
頑丈でもなく、防水でもないガラケーでしたが、胸ポケットに入れていて壊れたことはありません。
しかし今年は繊細で弱点(画面)丸出しのiPhone、対策なしで一緒に滑れる気がしません。

ネットで調べてみると、やはり"預けましょう"の一点張り。
いつも事前に場所を決めておきますが、ケータイ無しだと周りに迷惑かけるし時間がかかります。
なので、やっぱり壊れやすいiPhoneもなんとか持っていきたい!ということで、
頑丈なケースを買ってみました。

GRIFFIN iPhone4/4S対応 Survivor
GRIFFIN iPhone4/4S対応 Survivor
 

特徴:米国国防総省の規格「MIL-STD-810 516」という条件に準拠していて
衝撃、雨、落下、砂などから守ってくれ、なおかつiPhoneのすべての操作ができるらしい。

Firefox8 透明化

| コメント(0) | トラックバック(0)

以前、Firefox4の透明化の話を書きましたが、ちょっと気を抜いてしまって2011/11/25 時点での
Firefoxのバージョンは8になってしまいました。以前のエントリで書いたStylishのテーマも、
いくつかリンク切れになっていました…。
 

リリース間隔の云々はさておき、透明化の需要もそこそこあるようなので現バージョンで、
「これならいいかな」程度の透明化方法を書いておきます。

いつものようにStylishテーマをインストールする方法ですが、完全透明化のテーマだとブックマーク
ツールバーが真っ黒
で見えなくなってしまったので、ブラウジングに支障がない程度の、

・なかなかの透明化(その1)
・そこそこの透明化(その2)

の2通り紹介します。ご自分で適用してみて、お好きなテーマを採用してください。
先にbefore / after を貼っておきます。

                          before(デフォルト)

fire8_glass_b.png

                           after(その1)                                                                after(その2)

fire8_glass_a2.pngfire8_glass_a1.png

 

透明化方法は続きをどうぞ。

FermiではL1キャッシュが利用できるようになった。L1は従来のSharedメモリと同じSM上にある。
L1/Sharedメモリの容量はGTX480の場合、

  ・L1が16KBならSharedは48KB、
  ・L1が48KBならSharedは16KB、
という二択になっている。

グローバルメモリやコンスタント、テクスチャメモリからのロード回数が多いプログラムの場合、
L1のサイズを優先し、上記のメモリからのロードを殆どしない、もしくはキャッシュヒットが
見込めないプログラムでは、Sharedメモリのサイズを優先したほうが効率がよさそうである。

そして、この2択は、cudaFuncSetCacheConfig(func, cacheConfig) 関数を使って選択できる。
func にはCUDAで実行するkernelのfunction名を、cacheConfigには、次のいずれかの設定値を入れる。

cudaFuncCachePreferNone:    L1/Sharedのサイズ選択をnvccにお任せ(default)
cudaFuncCachePreferShared: L1を16KB、Sharedを48KBに
cudaFuncCachePreferL1:         L1を48KB、Sharedを16KBに

エラー処理も含めるとこんな感じ。

         CUDA_SAFE_CALL(cudaFuncSetCacheConfig(
               cuda_Kernel,cudaFuncCachePreferL1) );
        

文献:CUDA API Reference Manual PDF 4.7.2.3 p38

PukiWikiでユーザー・パスワードによる閲覧制限をもうけたい場合、
まず、pukiwiki.ini.phpの243行目あたりにユーザーを追加する。
// User definition
$auth_users = array(
 'hogehoge' => 'password',  //追加ユーザー
     // Username => password
     //'foo' => 'foo_passwd',// Cleartext
     //'bar' => '{x-php-md5}f53ae779077e987718cc285b14dfbe86',// PHP md5()'passwd'


そして260行目あたりのRead auth設定を有効にし、($read_auth=1)
制限を設けるwikiページ名を#の間に指定して (正規表現も可)、閲覧できるユーザーを記述する。
// Read auth (0:Disable, 1:Enable)
$read_auth = 1;

$read_auth_pages = array(
	// Regex		   Username
	'#SecretPage#'		=> 'hogehoge',
	//'#(NETABARE|NetaBare)#'	=> 'foo,bar,hoge',
);

これはどこのPukiwiki解説ページでも書かれていること。

しかし自分の場合、pukiwiki.ini.phpのPKWK_READONLYを1に設定しているため、
(これはPukiWiki全体がリードオンリーになり、編集ページを現れないようにする設定)
define('PKWK_READONLY', 1);の状態で、制限を設けたページを閲覧しようとすると、BASIC認証がコケてしまう。

PKWK_READONLYを0にすれば認証は問題なくできて、閲覧制限ページを見れるのだが
それはちょっと・・ということで、pukiwiki/lib/auth.php内のbasic_auth関数の200行目あたりを以下のようにいじった。
//
 if (PKWK_READONLY ==2 || //デフォルトは==2はないが、此処を無効化したいので有り得ない設定に
  ! isset($_SERVER['PHP_AUTH_USER']) ||
  ! in_array($_SERVER['PHP_AUTH_USER'], $user_list) ||
  ! isset($auth_users[$_SERVER['PHP_AUTH_USER']]) ||
  pkwk_hash_compute(
    $_SERVER['PHP_AUTH_PW'],
    $auth_users[$_SERVER['PHP_AUTH_USER']]
  ) !== $auth_users[$_SERVER['PHP_AUTH_USER']])
    {
なぜ、PKWK_READONLYが1のとき、Read auth(閲覧制限)が弾かれる仕様になっているか
分からないが、とりあえず回避策として。

MPICH2で、次のような条件で自ノードを含んだ複数台のノードとハンドシェイクをしようとした。

     ホスト名  :   IPアドレス
自ノード  i11server13 : 192.168.0.13
ハンドシェイクするノード  i11server14 : 192.168.0.14


自ノード(i11server13)の ~/mpd.host に2台のIPアドレス(もしくはホスト名)を書きこんで、
ハンドシェイクするコマンドを打つと

	%mpdboot -n 2 -f ~/mpd.hosts

	mpdboot_i11server13 (handle_mpd_output 407): failed to handshake with mpd on 192.168.0.14; recvd output={}

というエラーが返ってきた。もちろん、ハンドシェイクは出来ていない。一方、自分だけの(1台での)ハンドシェイクは

%mpdboot -n 1 -f ~/mpd.hosts

のコマンドで出来ているのでMPICHがおかしい訳ではなさそう。

MPICHの407エラーでググったところ、望ましい結果がなかったので、いつも良くコケる原因の一つである、
ハンドシェイクするノードの /etc/hosts が共通になっているか調べたところ、ホストネームが載る一番上の行は
次のようにコメントアウトしてあり、どちらも共通だと解釈がされているはずだ。

%cat /etc/hosts]

#127.0.0.1    i11sever13    localhost.localdomain    localhost
::1           localhost6.localdomain6 localhost6
192.168.0.13  i11server13
192.168.0.14  i11server14

そこで --debugオプションを付けることで、詳細なエラーメッセージを吐くということが分かったので、実行してみた。

% mpdboot -n 2 -f ~/mpd.hosts --debug

debug: starting
running mpdallexit on i11server13
debug: launch cmd= /usr/local/mpich2/bin/mpd.py   --ncpus=1 -e -d
debug: mpd on i11server13  on port 50158
debug: info for running mpd:{'ncpus': 1, 'list_port': 50158, 'entry_port': '', 'host': 'i11server13', 'entry_host': '', 'ifhn': ''}
debug: launch cmd= rsh -n 192.168.0.14 '/usr/local/mpich2/bin/mpd.py  -h i11server13 -p 50158  --ncpus=1 -e -d'
debug: mpd on 192.168.0.14  on port 35639
mpdboot_i11server13 (handle_mpd_output 407): failed to handshake with mpd on 192.168.0.14; recvd output={}

と出力されたが、有力な情報は得られなかった。
なんとなく分かるのは、ハンドシェイクしようとしている192.168.0.14のマシンが、ハンドシェイクを拒否している感じ。


最終的に分かったことが、ハンドシェイクする際の ~/.mpd.conf に記述するパスワードの書き方が
共通ではなかった事だった。というのも、

i11server13% cat .mpd.conf
MPD_SECRETWORD=hogehoge
i11server14% cat .mpd.conf
MPD SECRETWORD=hogehoge

上記のように、MPD SECRETWORDの書き方が違った(アンダーバーを付ける・付けない)ことが原因であり、
これを共通にしたところ複数台でハンドシェイクできた。
なんとも初歩的なミスなのかもしれないが、MPICHのエラーメッセージが出ない事も不親切だ。


そんなことでMPICH2のハンドシェイク時に407エラーが出るときの対処まとめ。

  • /etc/hostsがハンドシェイクするマシンと共通になっているか?
  • .mpd.conf はパスワードだけでなく、その入れ子の名前も共通か? (これについては下記で詳細)

ところで、他のMPICH解説サイトを見ると、.mpd.confは

secretword=共通のパスワードを記入

みたいな書き方をせよ! って解説されているけど実際は、
.mpd.confに書かれている文字列が同じかどうか で判断しているよう。

試しに、両ノードの.mpd.conf に "hogehoge" としか書かなくてもハンドシェイクできちゃったし。
まぁ無事ハンドシェイクできて良かった。


ちなみに、MPICH2の420エラーは "~/.mpd.conf "のパーミッションが正常ではない、というエラーです。

%chmod 600 ~/.mpd.conf

でOK。