http://at-aka.blogspot.com/2006/11/emacs-lisp-scheme.html
電卓代わりに lisp を使いたいときには Emacs Lisp のほうが
手軽なんだけど、真面目に Common Lisp や Scheme で
プログラムを書くときにはこうやるものなのね。
追記)
Emacs でバリバリ開発するなら Lisp なら slime、Scheme なら quack、
がお勧めらしい。
http://blog.livedoor.jp/dankogai/archives/50696831.html
素敵な職業だ、という宣伝が不足してるせいじゃないかなあ。
本当はわりと素敵な職業なはずなので、
なにかのきっかけで状況はコロっと変わると思うんだけどなあ。
jailの作り方
http://memo.majide.com/index.php?%A1%DABSD%A1%DBjail%A4%CE%BA%EE%A4%EA%CA%FD
Jail(仮想OS)の簡易マニュアル
http://platz.jp/howto/jail.html
jail 環境作っとこうかなあ。
そのほうが地球に優しい気もするしなあ。
http://freebsdgirl.com/2006/11/bsd_is_dying.html
このプレゼンビデオ面白いわ。
http://plusd.itmedia.co.jp/pcuser/articles/0610/06/news034.html
メニーコアに進むのは間違いなさそう。
- プロセッサ間通信
- メニーコアに適したプログラミングモデル
が課題になるのね。
http://itpro.nikkeibp.co.jp/article/COLUMN/20061121/254222/
近藤さんのコラム。
つい最近20万経路を超えたわけなんだけど、
経路が溢れるとどうなるか、という話。
- 経路がルータのメモリの上限を超えてしまう
- メモリの上限を超えると、経路情報を受けとれなったり、
ルータが再起動しちゃうことも。
- 経路フラップが発生
対策は
- ルータの切り替え
- 頑張ってアグリゲート
しかない。
IPv6 は、経路集約に配慮して設計、運用されてるんだけど、
マルチホームがあたりまえ、AS の数も増えまくり、
という現状を見ると IPv6 化されたとしても、
経路爆発は収まらないよなあ。
むしろ悪化する気も。
新ルーティングアーキテクチャが欲しい気も。
インターネットがここまで大きくなってくると、
アーキテクチャ再構築なんていう話は、
実際の実装がないと話にならないわけで、
そういうことができる立場にいるのは、
CISCO、Microsoft、Google、Intel ぐらいかのう。
そのへんで何かやってないのかしら？
http://d.hatena.ne.jp/h12o/20061111/deeside
自分の物に関しては、犬っぽい名前を付けるポリシーにしているな。
taro - 南極物語
jiro - 南極物語
kuro
shiro
tsun - 西郷さんの隣にいる犬の名前
rockey - 嫁の実家で昔飼ってた犬
max - 嫁の実家で飼っている犬
pat - フランダースの犬
このへんを適当にローテーションしながら使い回してる。
http://cellistmiya.typepad.jp/blog/2006/10/2_4c53.html
インターネットの諸問題を解決するためには、
みんなである程度は方向性を議論する必要はあるんだろうな。
河野さんが4つの方向性を上げてくれている。
1) 競争原理と参入の自由に与し、全体最適性は追求しない
2) 規制やガバナンスによる管理統制に傾ける
3) 別網を作り、Security、QoS等の分離をした上で、
現インターネットとの共存を目指す
4) 現インターネットのアーキテクチャ（アドレス、プロトコル、
機構、その他）そのものを見直す
個人的には、4を「継続的に」やれる仕組みを作らなきゃ
駄目なんだろうな、と思う。
継続的にやるには、アーキテクチャの柔軟性を高めないといけない。
今は IP に依存しすぎな気がするんだよね。
- レイヤの分離を真面目にやる
- レイヤ間のシグナルを真面目に定義する
- レイヤ内での認証の仕組みを真面目に作る
- レイヤをまたがる認証の仕組みを作る
こういう方向で、地道に作り直していくことを
やらなきゃいけない時期なのかもしれない。
全体のアーキテクチャの見直し、というか。
たとえば初期の TCP を TCP/IP として再定義したように、
IP も改めて再定義したほうがスッキリするんじゃないかなあ。
たとえば経路に関する部分を一つのレイヤにする、とかね。
関連)
経路情報付きパケットでのルーティングの話 --> [2006-11-17-6]
http://cvs.m17n.org/viewcvs/root/mixi/
via http://taka.no32.tk/diary/20061024.html#p04
へー。
でも mixi って、仕様がコロコロ変わるからなあ。
http://www.radiumsoftware.com/0611.html#061110
まあ本気を出せば CAPTCHA も破れるよな。
ニューラルネットワーク的な仕組みや、遺伝的アルゴリズム等が、
ライブラリから便利に呼び出せるようになると、
スパマーも楽になるんだろうなあ。
どんどん高度になる攻撃に対して、防御ってどうすりゃ良いんだろ。
インターネットのアーキテクチャに「認証」を入れたいよなあ。
http://www.drk7.jp/MT/archives/001155.html
Lighttpd 真面目にいじっとこうかなあ。
今のところ、動いた動いた、っていう程度にしか触ってない。
http://cell.fixstars.com/ps3linux/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
PS3 は Linux を載せることが可能で、その上で、
いろんなことができる、っていう話。
いろんなことってなんだ？、っていうのはさておき、
ここから辿れる資料を読むと Cell アーキテクチャが、
どんなものか良くわかりそう。(まだ途中みたいだけど)
Cellプログラミングチュートリアル
http://cell.fixstars.com/ps3linux/tutorial/
JANOGの宴会で、イーサネット駄目すぎ、捨てたい!、と言ってたら、
それを言ったら BGP だって、という話になった。
IP の世界では、遠くのノードと通信をしたいときには、
自分が持っている経路表を参照し、近くにあるルータに投げる。
そのパケットを受けとったルータも、それぞれが持っている
経路表を元に隣のルータに渡してやる。
それを繰り返して最終的な目的地までパケットが渡される。
ちゃんと届くためには、経路表がちゃんとしてなきゃいけなくて、
それを正しく保持するための仕組みがルーティングプロトコル。
インターネットにおいては BGP が主に使われている。
ところが、今の BGP には
- 経路情報が膨大になってきた。
20万経路を超えて、ルータも処理するのが大変。
- ルータを適切に設定してないと、偽経路情報を流されたときに
経路乗っとり等が発生する可能性がある
- トラフィックコントロールをちゃんとしたいけど、
意図したようにパケットが流れてくれないことがある
というような問題がある。
そういう問題に対しては、今のところは、
仕様だよねえ、ある程度は我慢して、
でも現状でできる最善の努力をしよう、
というふうにオペレーションで対応をしている。
IRR で頑張ろう、フィルターをちゃんとしようよ、
MEDで頑張ろう、とかとか。
でも IETF や IRTF 等では、もっと根本的に BGP に代わる
ルーティングアルゴリズムも沢山検討されてて、
良さげなものも結構あるらしい。
たとえば、パケットに経路情報を持たせりゃ良いじゃん、
という提案とか。
具体的には、制御情報を除くと、IP パケットヘッダは
- 発信元
- 宛先
の2つの情報しか持ってないけど、これを拡張して
- 発信元
- 宛先
- 途中経路1,途中経路2,途中経路3,途中経路4,,,,
みたいに経路情報をパケットに持たす、という提案。
もし経路情報がパケットに含まれていれば、
ルータは、書いてある経路に従って、転送してやるだけ。
経路情報はエンド側で作ってやる。
経路情報を作る元ネタには、IRRみたいなものを拡張した
経路情報サービスを利用する。
経路情報がパケットが入ってなかったら、
今までどおりの通信を行なうだけ。
むしろほとんどの通信は、今までの方法のままで、
あくまでも、イレギュラーな経路で通信したい、という場合だけ、
経路情報付きパケットだけ、を使う、と。
そもそも経路情報が爆発的に増えたのは、
マルチホーム等のイレギュラーな経路を実現するための、
パンチングホールが主な原因なんだよね。
そういうわがままな人達のためのコストをインターネット全体で、
払うのはやっぱり不自然な気がする。
基本サービスとして、綺麗にアグリゲートされるツリー型の
経路を用意しておいて、今までどおりの通信をする。
でもイレギュラーな経路を使いたいユーザは、
それぞれが経路情報をパケットに付ける、というようにする。
わがままなユーザは、わがままの代償として、経路情報を付ける、
という、コストを負担することになる、と。
実装もわりとシンプルにできそうだし、ルータの負荷も軽そう。
届かない場合は、経路情報なしで再送すれば、済むだけ。
アプリケーション毎に経路を選ぶことができる。
経路情報サービスは、複数の会社がそれぞれに立ちあげることが可能で、
競争によってコストも削減できそう。
将来のモデルとしては、なかなか良いアイディアな気がするね。
ひょっとするとこういう考え方は、IP ではなく、
オーバレイネットワークみたいなものの上で最初に
実装されるのかもなあ。
勉強しなきゃ、とか思った。
回線が繋がらないところで困らないように、
wwwoffle をインストールしてみた。
4年ぶりぐらいに使ってみたんだけど、ちゃんとメンテされてるのね。
wwwoffle
http://www.gedanken.demon.co.uk/wwwoffle/
Windows では Cygwin と組み合わせて使う。
Cygwin から make やら gcc やら、コンパイルに必要な、
ツールをひととおり入れておく。
wwwoffle は、展開して、Cygwin 上から make。
./configure
make
make install
これでインストール完了。
まずは wwwoffled を起動する。
wwwoffled
ブラウザのプロキシを localhost:8080 に設定。
wwwoffle を online にする。
wwwoffle -on
これで、ブラウザからウェブアクセスは、
wwwoffle に蓄積されるようになる。
回線が切れたら、
wwwoffle を offline にする。
wwwoffle -off
こうしておけば、蓄積されたキャッシュファイルを見に行くので、
一度見たサイトはオフラインでも閲覧ができる。
設定ファイルは /etc/wwwoffle/wwwoffle.conf
キャッシュファイルは /var/spool/wwwoffle/
ただ残念ながら、wwwoffle ごしでは見えないサイトもいくつかある。
たとえば mixi.jp とか。
こういうところは、ブラウザの設定で、直接見に行くようにする、と。
http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html
via http://secure.ddo.jp/~kaku/tdiary/
とても参考になる。
http://ya.maya.st/d/200611a.html#s20061107_1
そうか、SPAM フィルターで hint として使っている、
という場合もあるのね。
http://wota.jp/ac/?date=20061011#p06
以下のように設定する、と。
/etc/my.cnf
[mysqld]
default-character-set=utf8
skip-character-set-client-handshake
どんなことがあろうと utf8 を使うようにすればOK。
http://www.ringolab.com/note/daiya/archives/004764.html
音響も PC を使うほうが楽なのかもなあ。