EeePCとSSDと、E-mobileのユーティリティが常にログを書いている話
最近、SSDがブームですね。SSD採用のノートパソコンが欲しかったのですが、普段使っているLet's noteが保証の問題などでSSD換装できなかったので、EeePC S101を購入しました。もちろん、メモリは2GB（2500円程度！安くなったものですねぇ）に取り替えました。このへんを参考にRAMディスクを設定し、FirefoxのキャッシュフォルダをRAMディスク上に移動しました。（ちなみに、IO-DATA製品だとRAM Phantom LEというRAMディスクドライバが使えるとの情報をあてにして、わざわざIO-DATAの廉価版メモリ（型番に/ECがついている）を購入したのですが、廉価版だとRAM Phantom LEは使えないそうです。仕方なくERAMというソフトを使いました。）
さて、もちろん、色々対策するのは、SSDは書き込み回数に制限があるため、SSDへの無用な書き込みを減らしたいから、なわけです。SSDに置くのは、「書き込みは一度でよいが何度も読み出さないといけないデータ」であることが望ましいわけです。「これでもう、SSDへの書き込みが頻繁に起こることはないだろう」と思っていると・・・
なぜか、SSDのランプがチカッチカッと点灯している。
あれ？と思って、FileMonというソフトで、ファイルへのアクセス履歴を調べてみました。そしたら・・・・
どうやら、E-mobileユーザは、みんなインストールしているであろう、E-mobile HW Utilityが、Cドライブ（SSD)にログをはいているらしい。
証拠：
接続中でなくても、常駐しているだけで、常にログをはいてます、この人。このソフト、別に、E-mobileのUSBモデムを接続したときだけ、立ち上がってくれていればいいわけです。というわけで、早速、E-mobile HW Utilityの「ツール(T)→オプション(O)→ユーティリティ設定→起動設定→OS起動時にユーティリティを自動起動する」のチェックを外した上で、このユーティリティを終了させました。
結果：チカチカとまりました。Filemonで見ても、どのソフトも書き込み命令は出していません。やった！
というわけで、E-mobileを使用されているEeePC S101ユーザ、SSDユーザ（特にノートパソコン）の方は注意しましょう。まぁ、実際には、これを放置しておいても、大して劣化しない(ていうか、全く問題ない)のですが。ちょっと気になったというだけです、はい、すみません。
振り込め詐欺とパターン認識
NHKの新番組、追跡AtoZを見た。バンキシャのNHK版のような構成だが、NHKだから取材力が段違い。
今日のテーマは振り込み詐欺（オレオレ詐欺）。振り込め詐欺を行うためには、金を引き出せる他人名義の銀行口座がいる。この銀行口座がどのように供給されているのかに踏み込んでいる。結論から言えば、派遣切りやフリーターなどを中心とする生活困窮者が、犯罪組織に売り渡してしまう。その価格の安いこと安いこと。4口座が2万とか、5口座で6万とか。
さらに、銀行口座は子供でも作れるので、親が生活に困り、子供名義で銀行口座を作って売ってしまうということもよくあるらしい。口座を売ったのがばれると私文書偽造になり、前科が付く上、その口座の名義人は一生、銀行口座を作れなくなる。親が自分名義で口座を売ってしまったために、一生口座を作れなくなる可能性が高い子供が増加しているとか。
で、銀行側も手をこまねいているわけではない。この番組では「みずほ銀行」を取材した。銀行側の従来の対策は、被害の電話がかかってきてから、口座の入出金パターンを見て、明らかに怪しそうだったら口座を凍結する、というもの。で、その映像を見ていたのだが、本当に預金通帳に印刷されるような入出金パターンを、銀行員が目で見て判断していた。機械学習やパターン認識をかじっている自分のような人間からすると、もう、ここで、ピクッとなる。
え、これ、思いっきり機械学習（パターン認識）向きの問題じゃね？凍結された口座を教師データにして教師付き学習して、怪しげな口座を犯罪に使われる前にリストアップさせれば警戒できるんじゃね？
だって、まず、銀行口座の入出金情報って定型データじゃない。非定型データより、処理しやすい。また、みずほ銀行の銀行口座を全部あわせても2500万件らしい。その中で毎日動いている口座がどれぐらいあるのかわからないが、技術的には、十分、処理可能な量だと思う。さらに、銀行は24時間365日のシステムではないはずなので、処理時間に余裕もあるのではないだろうか。
具体的には、これまでに凍結された銀行口座を教師データにして、教師付き学習に落とせばいい。「小額入金後、すぐ出金しているケース場があるか」（口座凍結確認）とか「口座にお金を振り込む人の数が、突然増えたりしていないか」など、思いつく限りの特徴量を列挙していって、特徴ベクトルを作ればいい。もちろん、年齢とか性別とか、人に関する特徴量も入れることは技術的には可能。実際に、どの特徴量が実際に有効なのかは、教師付き学習が勝手に決めてくれる。間違って、全く効かない特徴量を入れてしまっても、そういう特徴量は学習の過程で「有効でない」ということが自動的に獲得され、判断基準からはずされるから大丈夫。
どの手法を使うべきかは場合によるけど、オーソドックスには、まずSVMのGaussianカーネルを試してみて、学習に時間がかかりすぎるようだったら、高速に学習できるonlineな手法を使う、とかでよいのではないだろうか。
で、そうやって思ってみていると、既に、今年から、みずほ銀行も、警戒システムを導入しているらしい。ただし、自分のところで作成したりはしていなくて、このFORTENTという外資系と思われる企業のシステムを、そのまま導入しているだけっぽい。このFORTENTのシステムが、機械学習を使っているかどうかは不明。ただ、番組では、この警戒システムが、怪しい口座として出力する口座の数が多すぎて対処できない、という問題が述べられていた。
思うに、どの入出金パターンを怪しいと見なすべきかは、国や制度によって大きく違うのではなかろうか。ある国で怪しいと思われる入出金パターンと同じようなパターンを取る職業が、他の国ではあるかもしれない。日本特有の商習慣にも多く依存するわけなのだから、警戒システムの作成にあたっては技術よりも、「日本の銀行員」が、大量の「日本人の口座」の入出金パターンを見て獲得した、「怪しい」という直感をコンピュータに伝えることが重要だと思う。そのためには、やはり、警戒システムを大量の「日本人の口座」に触れさせて、銀行員の直感を覚えさせるしかないのではないかと思う。で、これをやっているのが、教師付き学習。
さて、この程度のことは、誰か他の人が思いついてやっていると思うのだが、どれぐらいやられているのだろうか。詳しい方がいらっしゃったら、教えてください。
OSがシングルタスクだった、あの頃
自分が、初めてプログラミングをした春からカウントして、今年で13年目になる。
ちょっと懐かしのPC-98x1時代のキーワードを列挙してみる。
- system（トントカイモ）
- gosub
- 行番号
- beep
- MASM
- INT 21H
- INT 18H
- CONFIG.SYS
- EMM386.exe
- HIMEM.SYS
- UMB
- 常駐
- autoexec.bat
- COMMAND.COM
- Ver. 3.1
- Ver. 5.0
- MENUコマンド
- FD98
- far/near pointer
懐かしい！懐かしすぎる。OSがシングルタスクだった、あの頃。
GREEの第17回オープンソーステクノロジー勉強会「誤解と実際 〜 「パブリックイメージ」と自身が関わってきた「でびあん」について」参加記録
第17回オープンソーステクノロジー勉強会に行ってきた@六本木。参加動機は、大学１〜２年までは、LinuxはずっとDebianを使っていたから。Fedoraが騒がれ始めたころから、Fedoraに移ってしまったけど。この記事で言いたいのは、次の二つ。
- Debianプロジェクトの体制は、Wikipediaの体制とよく似ている
- この手の「誰でもwelcome」な巨大組織で責任を持つ立場になっているかどうかは、コミュニケーション能力の有無の非常に良い指標になっている
ということ。
まず、Wikipediaの体制との類似性について。自分は、Wikipediaの方で少し活動していたことがあるのだけれど、基本的には誰でもwelcomeな組織で、ちゃんと仕事を進められる組織にしようと思うと、組織の作り方はどの世界でも似た形になるのだと思う。
- 責任者（責任を持って仕事してくれる人）を作る
- 責任者になる人を選挙/既存の責任者の推薦、などで決める
こうすることで、そのコミュニティで仕事をした人が評価される仕組み出来るのだろう。「誰でもwelcomeだけど、仕事をやる以上は、ちゃんとやって欲しい」というのはどこにでもあるニーズなのだと思う。
Wikipediaの場合は、（このネーミングは悪いとされているが）管理者という存在がいて、記事を削除する権限を持てる。この管理者が、上記の「責任者」になるわけだ。管理者は、選挙権を持つメンバーの選挙で決まる。選挙権の有無は、直近の編集回数などの基準で決められており、管理者もメンバーも票の重みは同じ。細かいことは、直接対話で決まる。（Wikipediaでは、どのメンバーがどの記事をいつどのように編集したかがすべて記録・公開されている）
で、Wikipediaの選挙の様子をいくつもみているが、立候補して皆が管理者になれるわけではなく、落選するケースもボロボロでる。Wikipedia日本語版は管理者不足なので「基本的には管理者を増やすべきだ」というコンセンサスが既存の管理者/選挙権者の間であるにも関わらず、だ。
さて、皆、どういうところで落ちているというのを見ると、実は、コミュニケーションの問題で落ちているケースが大半。なので、Wikipediaの管理者をやっていたか否かは、コミュニケーション能力を見る、非常に良い指標になっている。企業がどれぐらい重視するか知らないが、コミュニケーション能力を10段階で評価しろ、と言われて、Wikipediaの管理者をやっている人がきたら、僕は、それだけで、４〜５点プラスして考えてもよいとさえ思う。それぐらい、こういう民主的なコミュニティで指導的な立場に立てるかどうかというのは、重要な指標だ。
なぜって、Wikipediaの活動の間に、「この記事は削除すべきでしょうか」とか、「何でこの記事のこの部分を消したんでしょうか」とか、色々細かい意見のやりとりが延々と続く。そういう時に一時的にでも攻撃的になってしまったり、脅しつけるようなことを言ったりすると、管理者になるのはかなり難しくなるのだ。管理者への立候補の時に反対票を入れる人が出るからだ。立候補時に受けた質問について、的確な回答ができない場合も、落選する大きな原因の一つだ。
単純な比較はできないかもしれないが、WikipediaとDebianが似たような体制を取っているのなら、Debianで指導的な立場にある人は、コミュニケーション能力がかなり高い人だと思う。しかも、英語の。（Wikipedia日本語版では、コミュニケーションは基本的に日本語）大学生が就職する時に、「サークルで指導的な立場に立って、新入生を何人入れました」みたいなことをエントリーシートに書いて評価されるのであれば、「Wikipedia日本語版/Debianで管理者/Developerやってました」というのは、その2倍ぐらい評価されていいと思う。
Wikipediaで何回も管理者に立候補しているのに、何回も落ちている人は、たまに見かける。そういうのを見ていると、ちゃんと、コミュニティ上におけるコミュニケーションの取り方に対するマニュアルみたいなものが必要だ、と感じる。この勉強会のスライドは、そのマニュアルとして使えるぐらい、いい資料になっていたと思う。Debianに興味がなくても、コミュニケーション能力のHOWTOだと思って読むだけでも価値があると思った。
キーワード・面白かったこと：
- 若い人と年寄りが多い
- FTBFS bugs- fail to build from source
- 私の嫁は実に出来ている嫁です
- RFP
- Request for package(パッケージにしてよ)
- 公式パッケージ以外の方法
- alien
- checkinstall
- equivs
- でも、出来れば、公式パッケージにして共有してください。
- この辺りの資料は、Debian勉強会に載っている
- パッケージの作り方
- dh-make
- debhelper
- などなど
- PolicyとTool
- パッケージはDebian Policyに従って作成される
- パッケージは2万超もある
- Useful tools for check
- Policy compliant
- lintian
- cleanroom build
- pbuilder, quemubuilder, cowdancer
- install, uninstall, upgrade test
-
- piuparts
-
- Policy compliant
- litian.debian.org
- パッケージがちゃんとどこでも動くパッケージになっているかチェックできる
- DEHS
- Debian External Health Checker
- Debian BTS (Bug Tracking system)
- 何度も出てきた
- 非常に重要
- 開発プロセス
- Eat your own dogfood!
- release often, release early
- Debianがリリース遅いのは、安定版と認められるまでのチェックが厳しいから
- experimental->unstable->testing->stable
- 活動は頻繁に行われている
- packages.debian.org
- qa.debian.org
- packages overview for maintainers
- Releaseが遅いと言われるが・・・・
- 色々なアーキテクチャを扱う方法
- buildd
- ビルドデーモン
- 様々なアーキテクチャでの、ビルド時のログが参照可能
- 運用は各個で実施
- 企業からの援助も多い
- buildd
- 寄付してください
- Archive Service
- Snapshot Serviceのためのマシン募集中
- Debian runs on
- Bug fix and "unblock" request
- 半年ぐらいかかる
- OfficeやExchangeなどを丸ごとリリースしているのと同じであることを考えれば、特に遅くはない
- どこで使われているのか
- QNAP
- Lenny
- Nokia i810
- QNAP
- Rubyのプラットフォーム
- どこから参加するか？
- 出来ることから！
- 使うこと
- 翻訳の査読（日本語）
- バグ報告をメーリングリストに投げる
- 出来ることから！
- 変化はゆっくりだが起きている
- Debian JP Project (http://www.debian.or.jp/)
- 東京/関西エリア Debian 勉強会
メモ：
- はじめに
- Universal OS
- あらゆるマシンでフリーなソフトウェアによるシステムを作り上げ、誰もが使えるOSを。
- 様々なアーキテクチャ
- 州の公的な機関での使用実績（商用ソフトではpayしないような分野にも進出できるので）
- DzhonkaLinux:ゾンカ語版Linux
- GnuLinEx
- 63ヶ国語サポート
- フリーソフトウェアガイドライン（DFSG)
- Free以外を拒絶しているわけではない
- mainが完璧フリー
- contrib
- non-free
- debian-multimedia.org
- ボランティア運営
- この規模としては稀有
- 誰でも参加できるよ
- Official Developers: 1200人
- ただ、メインの部分はDebian Developer (DD)が作っている
- なるためにはNM (New Maintainer Process)を経る必要がある
岩松信洋氏の話
-
- Debian JP Project Leader
- New Maintainer Processとは
- このチェックを通らないとDebian Developerにはなれない
- Debian Developerになると何ができるのか？
- NMプロセスの流れ
・・・この辺りで、メモを中断
ブログの名前
多くのブログは、「〜のブログ」とか「徒然日記」とかいう名前になっている。これでは、よっぽどおもしろいことを書かないと注目されないし、何より、検索するときに同じようなタイトルのブログがたくさんひっかかることになってトップに来ない。検索時に自分のブログだけが確実にトップに来るようにする簡単な方法は、自分だけの造語を作ってしまって、それをブログのタイトルにすることだ。現にこれを意図的にやって、このキーワードで検索すると自分のブログがトップに来るようになった、という方を知っているので、それに倣ってみることにした。
最初は「積み重ね」の送り仮名を取って「積重」という造語を作って、「これで引っかかるし意味も分かるだろ」と思っていたのだが、当たり前だが日本人しか分からないわけで・・・これでは、面白くない。で、解決策として、アルファベットで造語を作ってしまえ、と思った。
そこで、とりあえず、"Linguisci"という造語を作ってみた。"Linguistic Knowledge"（言語知識）の「知識」をラテン語に直すと"scientia"（・・・になるはず）なので、頭の部分をそのままくっつけただけ。ちなみに、"scientia"はラテン語で「知る」を表す動詞"scio"の派生語で、Scienceも当然ここから来ている。普通は、このスペルだと、"Linguistic Science"（言語科学）を連想するのかな。まぁ、どっちにも興味があるからいいや。
blogeyeが北朝鮮のミサイル発射を捉えていた
大倉務氏がIPAの未踏事業の協力を受け開発した、blogeyeというシステム。ブログ界で話題になっているキーワードが分かるのだが、「何県の」「何十歳代の」「男性/女性」の間で話題になったキーワードかも分かる。今回の北朝鮮のミサイル発射が、どこでどのように受け止められているのだろう、と疑問に思い、このシステムのことを思い出して、早速アクセスしてみた。
以下は、2009年4月5日（日）16:34頃に取得した内容：
530point
テポドン@4時間前
男性
秋田県
「桜満開 4/5」 「違和感の休日と、こにぴーと、ベル」 「タイトルなし」 「＜北朝鮮ミサイル発射＞」 「テポドン２号か？〜〜速報。」 「所詮は虎の威を借りた狐か」 「誤算」 「誤報って・・・」 「テポドン2」 「テポドンが来るぞ〜」 「テポドン」 「テポドン除けのニュー呪術」 「[news]テポドン」 「テポドンキタ」 「誤報」 「テポドン？」 「[NEWS]国際速報＜時事通信より＞
ちゃんと「秋田県」の「男性」の間で話題になっていますね！このシステム、県判定・性別判定は、あらかじめブログ単位で行った結果を使っているはずなので、記事の内容につられている、ということはあまり考えにくい。
今回の北朝鮮のミサイル発射の第一報と思われるニュースがNHKで流れたのは、NHKのサイトを見る限り、4月5日11:39頃。アクセスしたのが16:34頃で、4時間前に話題になった、と書いてあるので、発射のニュースが流れてから1時間程度でブログ記事が書かれ、blogeyeが検知した、ということになるだろう。
いやぁ、みんな、ちゃんと反応してブログを書くものなんですね！
単体法と内点法
- 作者: 田村明久,村松正和
- 出版社/メーカー: 共立出版
- 発売日: 2002/04/01
- メディア: 単行本
- 購入: 2人 クリック: 27回
- この商品を含むブログ (8件) を見る
非常にナイーブな発想をすると、単体法は頂点をジャンプしていく方式なので、頂点が非常に多い時、もっと極端にいえば、許容領域が１億角形だったりすると、不利になるような気がしますが、この発想は合っているのでしょうか。１億角形なんてそうそうないだろう、と一瞬思いましたが、本来、非線形な許容領域を線形で無理やり近似してやろうと思うと、出てきそうな気がします。極端なことを言えば、許容領域が円のとき、「円を１億角形で近似してLPで解く」という発想をしたら、１億角形でてきますよね。まぁ、頂点の数が増えても、xの次元が増えれば、少ないジャンプで最適解まで到達できそうな気がしますが。
ちなみに、この本は、最適化法の入門書でもありますが、同時に、内点法について、かなり詳しく書かれています。この本の２章で、線形計画を解くのに使っている内点法は、パス追跡法の一種らしいです。
