Hをhash関数としたとき強い衝突性を突破するには \(\exists h \exists x, x^' H(x) = H(x^') = h \) をみたせばよい.
これに対して弱い衝突性を破るには \( \forall h \exists x, x^' H(x) = H(x^') = h \) を示す.
ここでいう「存在する」は「無いと矛盾する」ではなくて, 上記命題の否定に対する反例を構成するという意味です.
強い衝突性のほうが条件が弱いわけですが, それは攻略者視点から見てるのでそう見えるのです. Hash関数を作る側からすれば, 強い衝突性を実現するのはどんな値に対しても Hash 関数をごまかすような元データが見つからないようになっている必要がある, ということなのでキビシイ条件です.
これに対して弱い衝突性を破るのは攻略者からすると大変です. どんな Hash値に対しても, 「明日もういちど来てください. 偽者のデータをお見せしますよ」 と言えなければならないのである.
ネットワークの port 使ってるプロセスは誰や? という記事を10年ぐらいまえに書いたけど, ファイルシステムを使っているやつはどうやって探せばいいのか?
fuser -v ファイル名
で当該ファイルを使っているプロセスを探すことができる. これの弱点は個別のファイルじゃないと動かないところで, fuser -v /dev/sda0 とかやっても, 実際にそのデバイスファイルをどうこうしているプロセスだけがひっかかるのであり, その下にぶら下がっているファイルを使っているプロセスは知ったことじゃない. そういう場合は,
fuser -vm デバイスファイル
あるいは
fuser -vm マウントポイント
でオッケーである. ひっかかったプロセスに逐次(あるいはまとめて)シグナルを送信するオプションもあるが, サーバプロセスの場合はいきなり死亡してめんどくさいことになったりするので, 実際の場面ではあまり出番が無いかもしれない.
ふじこキーボード(qwerty配列)は, 左手と右手でどっちがたくさん使うか選手権!
qwerty left right letters で検索して出てきた記事から, 左手文字のリストを作成しよう.
["a", "b", "c", "d", "e", "f", "g", "q", "r", "s", "t", "v", "w", "x", "z"]
さて, 集計対象の英語の語彙のセットを適当に見繕おう. ここでは以前こしらえた, 発音しやすい anagram を作るコードにおまけでつけた語彙リストを使った. 文字ごとに一行にして出力(split("") が担当)して, これを sort | uniq -c して集計する.
ruby -e 'puts Marshal.load(File.open("bt.wl").read).join.split("")' | sort | uniq -c
403041 a
118312 b
216535 c
211982 d
655388 e
--中略--
5759 z
これから左手の合計は 3251673 一方総計は 5517998 なので, 左対右はおよそ 3:2 だ.
左手なんて, 小指がコントロールキーをタイプするのにしか使ってないと思っていたが, じつは, (自然言語に関する限り)左手の方が仕事が多そうだ. では, 日本語ならどうだろうか? コマンドが長すぎるので複数行にわけました.
w3m -dump *html | nkf -j | kakasi -Ka -Ha -Ja -Ea -ka
| tr -dc '[:alpha:]' | tr '[:upper:]' '[:lower:]'
| ruby -e 'puts STDIN.read.split("")' | sort | uniq -c
手元のラクガキのhtmlから集計してみたよ. 入力はローマ字モードでやってるので, 日本語文字列をローマ字に戻して集計すればタイピングの頻度を集計できる. 上のコマンドでは, 日本語文字列をローマ字に変換するのに kakasi を使っている.
結果は左対右で 2088635 : 2464716 であり, 比率は 5:6 ぐらいか? なんと英文と逆転である! 断然右手の方が多いぞ! どういうことだキバヤシ!
そうかわかったぞ!!! 日本語は母音の入力が伴う場合が多いので, 右手の負担が増えるのだ!!!!1111!
ときにおちつけ.
ソースコードではどうだろうか? 記号も含めたリストをどこかから拾ってくるのは面倒だから, 左手で順にタイプして, リストを作るのが手っ取り早いかもしれない. ただし, シフトキーはシンボルをタイプする手と反対側が担当するので, シフトキーを使わずに打てるシンボルだけを集計するのが公平だとか, なんか面倒くさそうな話が出てきそうなので, もう俺は興味が無くなった. 誰か引き続き興味がある人はお願いします. なんかおもしろいことが判ったら教えてください.
ちなみに, 今使ってる sort のバージョンは, 入力ファイルがクソでかくて到底メモリに収まらないようなサイズでも問題なく動作し, 二つのプロセッサを余すところ無く使って仕事をやってくれるので, とても素晴らしいが, プロセッサの温度が見たこと無いぐらいに上がって, ちょっと焦って, sort 実行中に空気を吸い込む穴のところを歯ブラシで掃除したりしてみた.
掃除してもプロセッサの温度が下がることはなかった.