2007年04月05日(木) [過去の今日]
#1 アキバ一周ルート
「Google マップ」上に“マイ地図”を作れる新機能 という記事を見つけたので、さっそくやってみた。
最近行ってないからだいぶ変わってるんだろうなあ……。東京に通ってた頃は毎日のように歩いてたのに。
(@973)
2006年04月05日(水) [過去の今日]
#4 WinnyよりWindowsのほうがリスクが高い理由
こないだのリスクウェアの件について、いささか誤解を持つ方がいらっしゃるようなので *2 少し書き足そうと思う。
まあこちらの書き方も悪いのだろうが、もちろん俺はセキュリティリスクだけをもってWinnyよりWindowsのほうがリスクが高いと言ったわけではない。両者をそれぞれ一つのプラットフォームとして見た場合の危機管理におけるリスクを言っている。
そもそも SirCamによってFBI等の文書が流出した のは2001年と、AntinnyはおろかWinnyすら出現していない時期のことだ。同様の情報流出系ウィルスがWindows及びそのコンポーネントの脆弱性を用いて感染・拡散したという事例は見付けていないが、それがそう難しくないことは今までの事例からも明らかであろう。
今回はたまたま国内でWinnyによる流出の発覚が多かっただけのことで、実際にはそれ以前からWindows上で流出事件は起きていた。そしてそれが起きる可能性も、セキュリティホールの無いWinnyより、それが次々見つかるWindowsのほうが高いということだ。
@ 本質と根本:
もっとも、「インターネットから流れて来たファイルを無検査で開いて感染」という経路はSirCamもAntinnyも変わらない。だから根本的な問題はプラットフォームではないというのも明らかではあるが、それは今回の話の本質ではない。
(@575)
うは、むちゃくちゃ厳しくなるなあ。田舎にいる分には駐車場に困ったりはしないけども、都会は大変だろうなあ。
特に運送業はそうとうコストがあがることになるようで。宅配便は車を使わない配達にシフトしはじめてるそうだし、コンビニ等の小売店への配送もかなり大変なことになるようだ。
特に恐ろしいのは引っ越し。表題記事から引用するが
引っ越し業務では、地元の警察署から許可を得なければならなくなる。申請から「4〜5日」とされ、警察署ごとのばらつきも予想される。
ようするに引っ越しも警察の胸先三寸ってことか。来春の引っ越しシーズンは混乱を極めそうだなあ。引っ越しをスムーズに行かせるために警察への賄賂なんかが流行りそうな予感がするのは、気のせいか?
(@529)
とうとうウェブ版ができたようなのでやってみた。
狐志庵の79%は犠牲で出来ています 狐志庵の14%は純金で出来ています 狐志庵の4%はマイナスイオンで出来ています 狐志庵の3%は心の壁で出来ています
犠牲が主成分かい。
Koshianの56%は気合で出来ています Koshianの24%はマイナスイオンで出来ています Koshianの8%はミスリルで出来ています Koshianの6%はで出来ています Koshianの6%は玉露で出来ています
koshianの86%はやましさで出来ています koshianの8%はミスリルで出来ています koshianの5%は理論で出来ています koshianの1%はお菓子で出来ています
大文字小文字で結果が違うのね。 しかしミスリルの配合比は同じか。
Sugano Yoshihisaの57%はビタミンで出来ています Sugano Yoshihisaの32%はマイナスイオンで出来ています Sugano Yoshihisaの7%は心の壁で出来ています Sugano Yoshihisaの3%は理論で出来ています Sugano Yoshihisaの1%は濃硫酸で出来ています
ふーむ、本名でも成分が似てるのは不思議。あ、そういえばファーストネームが姓であることを示すために、(E) *1 を付けてたんだった。
Sugano Yoshihisa(E)の88%は罠で出来ています Sugano Yoshihisa(E)の5%は魂の炎で出来ています Sugano Yoshihisa(E)の5%は濃硫酸で出来ています Sugano Yoshihisa(E)の1%はお菓子で出来ています Sugano Yoshihisa(E)の1%は理論で出来ています
主成分が罠かよっ!
(@463)
昨日のリスクウェアの話 だが、別にそこはツッコミどころじゃないと思う。
UNIXサーバ向け製品でもWinnyを検知するのは、ファイルサーバとして運用されてるUNIXでは必要無いとまでは言えない(samba経由で実行可能)だろうし、58種類というのも各バージョンを総合すればそれくらいの数にはなるだろう。実際にはもっと多いんじゃないだろうか。よくそれだけサンプルを入手して対応したものだと、むしろ感心したポイントだ。
(@458)
2005年04月05日(火) [過去の今日]
ほれ、やっぱりね。必ずこういうことが起きると思ってたが、実際に起きちまったか。現実に事件にならないと、危険性ってのは認識されないものなのかね。アクティブRFIDも同じ運命を辿るんだろうなあ。とほほ……
(@695)
2004年04月05日(月) [過去の今日]
#1 perlのマルチバイト文字のマッチング
5.8くらいになればもう完全対応だろうとかタカを括ってたのだが、どうもそうもいかないらしい。日本語の「あ」は正規表現の/../にマッチしたりする。つまり二文字として扱われてるわけだな。そういうわけで /[??]/ なんてのがうまくマッチしてくれなくて悩んでた。
そしたらIRCで やすたん からアドバイス。use Encode; とか use utf8; あたりじゃないのみたいな話を教えてもらった。Encodeは変換ライブラリかな。とりあえず use utf8; し、スクリプトをUTF-8で書いてみると、見事に正しくマルチバイト文字が扱われてた。なるほど、perl 5.8 はそういう解決か。これからはperlはUTF-8で書くことにするしかないかな。
(@709)
@ 翌日追記:
ということでperlスクリプトを編集するときは基本的にUTF-8にしちまおう。hookを使ってこうしてみた。
(add-hook 'perl-mode-hook (lambda () (set-buffer-file-coding-system 'utf-8-unix)))
うしうし、うまくいったな。ってまてよ。これじゃ今まで書いたスクリプトも開いたとたんにUTF-8にされちまうじゃねえか。んー、回避策はあるのかな?
(@020)
@ さらに追記:
とりあえず開いたときにバッファサイズが0ならUTF-8、という解決。
(add-hook 'perl-mode-hook (lambda () (if (<= (buffer-size) 0) (set-buffer-file-coding-system 'utf-8-unix))))
んー、でもどうせなら、バッファ内にマルチバイト文字が存在するか否かで判定したいよなあ。そういう処理どうやればいいんだろう。
(@067)
@ Encode必須:
むう、最初から全部UTF-8ならいいんだけど、他の文字列持ってこようとするとダメダメだな。JocdeでUTF-8にしても日本語を使った正規表現にマッチしなくなる。なぜかEncodeを使ってUTF-8にdecodeしてやらにゃならん。でもどっちを使っても変数に入ってるデータは同じなんだけどなあ。謎い、謎過ぎる。perl-techネタか?
というか、5.6.1ではどうしたらいいんでしょうね。woodyではきっついなあ。
(@272)
2003年04月05日(土) [過去の今日]
#1 本日のヒット数
1123ヒットだと。また例によって行儀の悪い検索エンジンのrobotが押し寄せて来たのだろうけど、負荷的には問題があった形跡も無く、大丈夫だったみたいだな。今までだったら落ちてたかもしれない。やはり、こないだ変更したapacheの設定が効いてるのだろうか。
(@630)
2002年04月05日(金) [過去の今日]
先日作った./-j on sidebarもふくめ、他のニュースサイトも加えて早くもリニューアル。
Bulknews というサイトが、いろんなニュースサイトのRSSを配付してくれてたのを発見したんで、それを利用させて頂こうというわけ。これでめんどくさかったニュースサイトめぐりも楽になるかな。ちなみにZakZakは俺の趣味じゃありません、
さかどん のリクエストです(笑)
(@399)
#1 目が根っ子
などと変換してしまうので、アレゲ人のためのアレゲ辞書を目指すために、めがねっ子、めがねっ娘、眼鏡っ子、眼鏡っ娘と登録。しかし、どれもピンと来ないのだなあ。どう書くのが萌えるんだろうか。めがねっこ萌えの方の意見を求む。
(@675)