"Startup Applications" で立ち上げた xclock を "Always on Top" かつ "Always on Visible Workspace" にしたい。 -> devilspie を導入した

やりたかったこと
デスクトップに時計が常駐していると便利なので、多くのデスクトップ環境では端に時計表示があることが多い。
しかしながら私は「あなろぐ時計」が欲しいので、xclock 愛用している。
今までは Gnome の Startup Applications として xclock を起動していたが、
「全てのワークスペースで」「（firefoxなど他のアプリケーションのウィンドウに隠れず）いつも最前面に」xclockが常駐して欲しいと考え、devilspie で実現することに成功した。

wmctrl

まず、「gnome startup application commandline always on top」などで検索してみたのだが、なかなか望みの答えにたどり着けない。command line は gnome の startup applications はコマンドを書くようになっているからである。
検索の結果 wmctrl がまず候補に上がって、実際にインストールしてみた。(# portupgrade -N x11/wmctrl)
wmctrl は「ウインドウマネージャーにコマンドラインからちょっかいを出す道具」である。
wmctrl 本家 http://tomas.styblo.name/wmctrl/
コマンドラインからXのウインドウを操作する（kwt hrtk さんのブログ、trial and error の記事）  http://techno-st.net/2008/12/18/-x-wmctrl.html

「いつも最前面に」は wmctrl 実現できたが、「全てのワークスペースで」が実現できなかった。
ちなみに、いつも最前面には
$ wmctrl -r xclock -b toggle,above
とすればよい。

Devil's Pie
さらに検索した結果 Devil's Pie (x11-wm/devilspie)の存在を知った。
Gnomeでウィンドウを操作する（Matsue Trisen さんのページ）  http://headoffice.matsue-torisen.co.jp/~naruse/Estab/Tips/devilspie.html
Devil's pie でGnomeのウィンドウを操作 http://sites.google.com/site/fesnote/GNU_Linux/setup-debian-lenny/devilspie

devilspie では
以下のスクリプトを ~/.devilspie/xclock.ds として保存し、
$ devilspie &
と実行すればよい。
スクリプトの中身 ↓
(begin
  (if
   (is (application_name) "xclock")
   (begin
     (pin)
     (above)
    )))
スクリプトの中身終わり

まとめ
「全てのワークペースで」「いつも最前面に」ある xclock を gnome の起動時に立ち上げるには

1.上記内容のファイル ~/.devilspie/xclock.ds を用意する

2.gnome の toolbar の System -> Preference -> Startup Applications -> add
で以下の二つを書く
(1).
Name: devilspie
Command: devilspie
Comment: (空欄でよい)
(2).
Name: xclock
Command: xclock -geometry -0+0
Comment: （空欄でよい）

これで時計が常駐できた。やったね。

環境
FreeBSD 8.2
gnome 2.32.1
wmctrl 1.07
devilspie 0.22

余談
私は Scheme を愛してやまないのだが、devilspie は lisp っぽい設定ファイルで素敵だ。

バス特と定期とどちらが得か？

バスの定期券は鉄道に比べて、一般的に高い（気がする）。
また、PASMO用（Suicaでも同じ）の「バス特」という制度もあり、どうするのが一番お得なのか分かりにくい。
一度、きちんと計算しておこうと思っていたので、連休を利用して計算してみた
（嘘つきました。一時間もかからずにできました）。

前提
・都区内の都営以外の民営バス会社（小田急バス、東急バス、京王バスなど）は、ほとんど一回210円均一の料金で乗れる。
・通勤定期券（一ヶ月）は45回分、通学定期券（一ヶ月）は36回分で設定されている。
・バス得の制度はPASMOで利用したとき、おまけがつく制度。旧バスカードのおまけと同額（5000円払うと5850円分乗れる）だが、暦月ごとにリセットされてしまい、バスカードほどは得ではない。バス会社によって違う。今回は小田急の場合で計算した（が、他の会社でも大体同じ）。
http://www.odakyubus.co.jp/pasmo/pasmo2006-12.htm#ticket　（小田急のバス特）
http://www.keio-bus.com/pasmo/page04.html　（京王バスのバス特）

結果

 横軸が乗る回数、縦軸がかかる金額。線の種類は上から順に

現金（赤）、PASMO（黄緑）、定期券大人（青）、定期券学生（ピンク）

結論
学生は21往復、大人は26往復するならPASMOより定期券の方が得だ。一月の平日の数は平均30日×5/7-1日（祝日）=21日であることを考えると定期券は得ではない。
定期券は未来に乗るかを判断しなくてはならない。天気が良ければ歩こうかと思うかもしれないし、飲みすぎて終バスがないかもしれない。やっぱり、PASMOがよいと私は思う。

参考
今回の計算に用いたスクリプト。お行儀悪いけど、せっかくなので載せておく。

#!/usr/local/bin/bash
omake=0;
bustoku=0;
regular=0;
one=210
for i in {1..60}
do
    charge=$one;
    regular=`expr $one + $regular`;
    if [ $omake -gt $one ]; then
    omake=`expr  $omake - $one`;
    charge=0;
     elif [ $omake -gt 0 ]; then
        charge=`expr $charge - $omake`;
        omake=0;
    fi
    
    toku_make=`expr $bustoku % 10000`;
    if [ `expr $toku_make / 1000` -ne `expr \( $toku_make + $charge \) / 1000` ]; then
        omake=100;
        if [ `expr $toku_make / 1000` -eq 4 ]; then
            omake=450;
        elif [ $toku_make -gt 5000 ]; then
            omake=170
        fi
    fi
    
    bustoku=`expr $bustoku + $charge`;
    echo $i $regular $bustoku 9450;
done 

メールの安全性について

メールの安全性(盗聴、改ざん、なりすまし、否認を防ぐ)を確保するための手段はいくつかある。何があるかを調べたのでメモしておく。

中間者攻撃による攻撃は、PKI(公開鍵基盤)を用いない限り防げない。

DKIMは、送信メールサーバはメールの内容に、送信メールサーバのもつ暗号鍵でsignetureをつける。送信メールサーバを管轄するDNSサーバに公開鍵を置いておく。受信メールサーバは、Fromに書いてある送信メールサーバを管轄するDNSサーバの公開鍵と証明書で、送信メールサーバを秘密鍵を持っているサーバとして認証する。
オレオレ公開鍵でも中間者攻撃がなければ、文面改竄検知が可能。

SPFはFromに書いてある送信メールサーバが本当に送信メールサーバであるかを、Fromに書いてある送信メールサーバを管轄するDNSサーバに確認する。文面改竄検知は不可能。
RFCではExperimentalの扱いだから「ついてないと受け取らない」はやるべきではない。

ヘッダから手動で安全性を確保するなら、
1. Received を上から追いかけ、変なところを通っていないか調べる。
2. Received の最下行の送信者のIPからdomain nameを正引きする。($ whois xxx.xx.xx.xx)
3. 2の結果をdigする。($ dig example.com txt)
文面改竄検知は不可能


私見では、文面改竄されたら困るものはたいてい見られ困る級のものだから、そもそも暗号化して送れと思ったのだが、見られていいものに、中間者がウイルスファイルを添付するとかは攻撃としてありうる。これはオレオレDKIM級で防ぐことができるものだ。
あと、ヘッダから手動で確認はSPFに負けてないと思うがどうだろう。

ちなみに某検索最大手は DKIM(PKIによる認証)をしている。
某航空会社は SPFに対応している。
某I機構、某大学は 認証なし。しっかりしよう。

参考文献
DKIMについて RFC4871
http://www.ietf.org/rfc/rfc4871.txt
SPFについて RFC4408
http://www.ietf.org/rfc/rfc4408.txt

追記(2011年７月12日)
SPFの主目的は「Fromを偽装したスパムを弾くこと」らしい。SPFはその目的にはかなった手段だ。
それから、中間者攻撃は「技術的に可能だけれどもかなり大変。悪人がコストをかけても改竄したいと思わなければやらない」。だから普通はあまり気にしなくてよい。楽にできて、やらないよりマシな技術というものはたくさんあるから、それはやったらいい。

クラウドコンピューティングと(動画)ファイル共有の未来

先日、友人にドリームジャンボのCMを紹介しようと思った。
今はもう放送されていないが、幸いYoutubeでとってあったので、URLをメールで送った。
http://www.youtube.com/watch?v=K0swXbQmbaQ


クラウドコンピューティングの時代だなあ。

URLと動画Fileの関係は、C言語におけるポインタとデータの関係に同じだ。
別の関数がデータにアクセスするためには、データを直接やりとりせずに
データの所在地を示すポインタのやりとりだけで済ませた方が、
memory spaceとdata copyにかかる時間の節約にもなるので、
ポインタは非常に便利である。
同様に友人に動画を見せたい場合もURLをポインタとして渡せば充分だ。

必要なら、関数と同じように勝手にlocalでcopyをとればいいだけだ。

しかしながら、未だに、クラウドコンピューティングは
サーバーがサーバー群であり、ネットワークがインターネットである
サーバークライアント方式だという理解のままである。





また、技術とは別の所だが、YouTubeなどの動画(ファイル)共有システムには、

著作権法上の問題がある。CMなどは広告主がインターネット上にアップロード
してくれればいいのだが、改変されるのが嫌なのだろう(ほかにも出演者との契約とか
もあるだろうが)。
すべての再生可能なデジタルデータは技術的には改変可能なので
(暗号化しても再生可能だということは、最終的には単純なRGBデータになる。
再生ソフトとOSがバイナリでのみ配布されないかぎり、RGBを盗むことは可能
(例えば、copy不可のpdfだって画面キャプチャーしてデータを保存することは原理的には
できる。プログラムとして出回っているかは知らないが) 。
世の中には数多の動画編集ソフトがある)、それが嫌なのだろう。

しかしながら、法律と取り締まりを厳しくするか、動画再生ソフトを企業が独占販売すれば
改変されたものが出回らなくなるはずだ。そうなったとき、インターネット上の動画共有が
どうなるのか楽しみでもある。