動画がいくつかある。
しかし、やはりマウスとキーボードで操作するらしい。ゲームパッドで操作できないゲームは基本的にやらないので、対応してくれないかな。
2008-06-30
2008-06-29
2008-06-28
悪夢
夢の中で、飲みに行こうと思い、出かけた。しかし、飲み屋は物理的に潰れていた。何か重機で破壊されたように、ガレキがあるばかりであった。見ると、その近所の建物も皆同様に潰されている。一体これはどうしたことか。
不思議に思いつつも、仕方なく帰ろうとすると、後頭部を鈍器で殴られるような衝撃が走った。これまた奇妙な感覚だ。鈍器による攻撃は執拗に続く。とそこで、目が覚めた。目は覚めたが、なぜか身体が動かない。何か毛布のようなものに包まれて縛られているのか、あるいは薬でも盛られたか、それはよく分からないのだが、とにかく身体が動かない。鈍器のようなものによる攻撃はなおも止まることがない。
母親の声が聞こえる。「当然の報いよ」、「働きもしないで」
鈍器による攻撃が止まったかと思ったら、「さぞかしよく切れるんでしょうね」などといいながら、カッターの刃を出す音が、カチカチと聞こえてきた。コレはまずい。何とかして身体を動かし、この場から逃げなければならない。カチカチという音が止まった。まずい。やられる。動け我が身体よ。今すぐ逃げなければ命はないぞ。動け。とにかく動け。
とここで、本当に目が覚めた。なんという悪夢だ。仕事が見つからないので疲れているのか。
2008-06-27
天井にタッチするため、ピョンピョン飛び跳ねるビルゲイツ
Larry Osterman's WebLog : BillG Memories, part 1…
1985年のことだ。Valorieというインターンの女性が、夜遅く仕事をしていると、ホールでピョンピョン飛び跳ね、天井のタイルにタッチしている狂人を見かけた。奇妙なことではあったが、マイクロソフト社では、そういう変なことは日常茶飯事だったので、特に気に留めなかった。ホールではよく野球が行われていたし（誰かがバットで電灯をぶち割ったため中止になった） Windowsチームはよく屋根に登ってジャズをやったものだ。そういうことが頻繁に起こっていたので、男が一人、ホールを走り回って天井にタッチしているのは、別段珍しくもなかった。隣にいたLibbyという女性に、あれは誰なのか訊ねたところ、「ああ、私の兄さんよ」と言われた。
その後しばらくして、、Valorieは、隣の人の名札が、Libby Gates（ビルゲイツの妹）であることに気がついた。
私はこういうビルゲイツ像が好きである。ステレオタイプのビルゲイツとは違う。
なんだかよく分からないが、ビルゲイツは深夜に、ピョンピョン飛び跳ねて天井にタッチしていたらしい。
サンゴの朝日、ヘンタイの毎日
朝日新聞といえば、昔からサンゴを意味するが、毎日新聞といえば、これからはヘンタイを意味することになるだろう。
少し前から言われていたが、いまようやく広く知られることとなった。「ウォシュレットはオナニーのためにある」、「マクドナルドを食べると性的錯乱を起こす」、などと事実無根のヘンタイニュースを世界に発信し、日々、日本をヘンタイの国と認識させることに尽力したその功績は大きい。さらには、問題発覚後に、記事を削除し、hentai metaタグをはずし、robots.txtを設定して検索エンジンにクロールされないようにするなど、隠蔽工作に余念がない。世間の関心が薄れるまでシラを切り通そうと必死である。
こんなことを毎日のように続けているのが毎日新聞であり、その内容は信頼するに足らず。よって読む価値なし。
2008-06-26
FizzBuzzをもう少し分かりやすくした。
前回のコードは、既にMPLの素晴らしい恩恵を受けていたわけだが、やはり他人にとっては読みにくいだろう。なにが分かりにくいかといって、メタ関数、FizzBuzzSequence の引数が、3の倍数か、5の倍数か、あるいは3と5両方の倍数なのかを判断する部分が分かりにくい。最初はMPLのpush_backの中に書いたのだが、これでは他人が読みづらかろうと、外に押し出して、メタデータ、elem を定義した。しかし、それでもまだ読みづらい。
ここで気付いたのは、そもそも、3の倍数かどうかを判断する条件式自体が、読みづらいということだ。(x%3 == 0)なんて分かりにくすぎる。既にこれはメタプログラミングの問題ではない。こういう時、我々はどうするかというと、コメントを付け加えるか、別の関数を作るのだ。では早速。
#include <iostream>
#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_VECTOR_SIZE 100
#include <boost/mpl/vector.hpp>
#include <boost/cstdint.hpp>
#include <boost/type_traits.hpp>
#include <boost/mpl/if.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/push_back.hpp>
#include <boost/mpl/for_each.hpp>
namespace mpl = boost::mpl ;
struct Fizz{ static char * const value ; } ;
struct Buzz{ static char * const value ; } ;
struct FizzBuzz{static char *const value ; } ;
char * const Fizz::value = "Fizz" ;
char * const Buzz::value = "Buzz" ;
char * const FizzBuzz::value = "FizzBuzz" ;
template < int i >
struct GetFizzBuzzElement
{
typedef typename
// if FizzBuzz
mpl::eval_if_c< (i % 3 == 0) && (i % 5 == 0)
, mpl::identity< FizzBuzz >
// if Fizz
, mpl::eval_if_c< (i % 3 == 0)
, mpl::identity< Fizz >
// if Buzz
, mpl::eval_if_c< (i % 5 == 0)
, mpl::identity< Buzz >
// else
, mpl::int_< i >
>// Buzz
>// Fizz
>::type type ;
} ;
template< int i >
struct FizzBuzzSequence
{
typedef typename
mpl::push_back<
typename FizzBuzzSequence< i - 1 >::type
, typename GetFizzBuzzElement<i>::type
>::type type ;
} ;
template < >
struct FizzBuzzSequence<1>
{
typedef mpl::vector< mpl::int_<1> > type ;
} ;
struct print
{
template < typename T >
void operator () (T) const
{
std::cout << T::value << "\n" ;
}
} ;
int main()
{
mpl::for_each< FizzBuzzSequence<100>::type >( print() ) ;
}
このように、FizzBuzz如何を判断するメタ関数、GetFizzBuzzElementを定義すると、FizzBuzzSequence メタ関数が非常に読みやすくなった。そして、GetFizzBuzzElement メタ関数は、分かりやすいインデントと、簡単なコメントを付け加えた。なお、深さだけで見れば、GetFizzBuzzElement メタ関数内のインデントは正しくないのだが、意味で考えれば、if else if else if elseなので、あえてこのようなインデントにしている。
さて、今思うに、Linus Torvaldsは正しかった。詳しい理由は後ほど、別記事で書くことにするが、重要なことは二つ、インデントは8文字で、インデントの深さは3階までである。
追記：
ここでは、メタプログラミングの用語は、Boost.MPLの作者による著書、C++ Template Metaprogrammingに拠った。コンパイル時の関数として、メタ関数、コンパイル時の変数としてメタデータである。もし、Lispを右に、Haskellを左に置くような人には、変数の呼称には、メタデータではなく、値を名前に束縛するといったほうが理解できるかもしれない。
2008-06-25
ヘンタイな毎日新聞、普通の漫画をロリペド漫画と報道した上、言論封殺を試みる
deco★decocool: なにそれ！◆ 毎日新聞英語版サイト 「変態ニュース」を世界発信
毎日新聞にはヘンタイ記者がいて、モットーは言論封殺である。
コンパイル時計算のFizzBuzz
modを使わないFizzBuzz2 - wiseler : WAR IS PEACE
コンパイル時と実行時の合わせ技によるFizzBuzzをやられたので、純粋なコンパイル時FizzBuzzを書いてみることにする。
そもそもコンパイル時とは何か。それは、コンパイル時に1から100までの、どの値がFizzで、どの値がBuzzで、FizzBuzzで、あるいは数値で表示するかを計算してしまうことだ。だから実行時にすることは、既に計算された結果を表示するだけだ。
実行時に、あらかじめ計算しておこうとすると、100個の配列を用意して、そこに答えを格納することになるだろう。テンプレートメタプログラミングでは、型の配列、すなわちシークエンスを用いる。
#include <iostream>
#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_VECTOR_SIZE 100
#include <boost/mpl/vector.hpp>
#include <boost/cstdint.hpp>
#include <boost/type_traits.hpp>
#include <boost/mpl/if.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/push_back.hpp>
#include <boost/mpl/for_each.hpp>
namespace mpl = boost::mpl ;
struct Fizz{ static char * const value ; } ;
struct Buzz{ static char * const value ; } ;
struct FizzBuzz{static char *const value ; } ;
char * const Fizz::value = "Fizz" ;
char * const Buzz::value = "Buzz" ;
char * const FizzBuzz::value = "FizzBuzz" ;
template<int i>
struct FizzBuzzSequence
{
typedef typename mpl::eval_if_c< (i % 3 == 0) && (i % 5 == 0), mpl::identity< FizzBuzz >
, mpl::eval_if_c< (i % 3 == 0), mpl::identity< Fizz >
, mpl::eval_if_c< (i % 5 == 0), mpl::identity< Buzz >, mpl::int_< i >
>
>
>::type value ;
typedef typename mpl::push_back<
typename FizzBuzzSequence< i - 1 >::type
, value
>::type type ;
} ;
template < >
struct FizzBuzzSequence<1>
{
typedef mpl::vector< mpl::int_<1> > type ;
} ;
struct print
{
template < typename T >
void operator () (T) const
{
std::cout << T::value << "\n" ;
}
} ;
int main()
{
mpl::for_each< FizzBuzzSequence<100>::type >( print() ) ;
}
美しい。何と単純明快なコードであることだろう。実はMPLのシークエンスを使うのは初めてだったのだが、とても簡単で楽しかった。MPLは神によって書かれたコードではなかろうか。
なお、実行には、Boost.MPLのvectorの要素数を100まで用意しないといけない。すなわち、boost/mpl/vector以下に、vector60.hppからvector100.hppまでを用意する必要がある。といっても中身は単純だ。一部を単純に置き換えるだけで、後はすべてプリプロセッサメタプログラミングがやってくれる。
また当然だが、かなり規格準拠度の高いC++コンパイラが要求される。
汝、客をして哲学の学位を求むることなかれ
以下より翻訳して引用
Don't require your users to have a degree in philosophy, episode 3
あるオンラインの課金サービスに金を払おうとしたところ、以下のようなチェックボックスがあった。
メール通知が必要ではない場合は、このチェックボックスのチェックをはずしてください否定どころか二重否定のチェックボックスである。以下のどこが悪いというのだ。
メール通知を送るああ、分かってるさ。このうっとおしいチェックボックスの目的ぐらい。誰もメール通知なんて欲しくないに決まってるから、わざとはぐらかしてるんだろう。
2008-06-23
歴史に名を残す際に気をつけるべきこと
兵庫県豊岡市日高町の祢布ケ森遺跡で大量出土した木簡の中には、九九の練習で計算間違いをしているものがあった。調査した豊岡市教委は「当時の官吏の人間味が感じられる」と話している。
木簡は勉強するとき、現代のノートのようにも使用していたという。間違いが見つかった木簡は長さ三一・六センチ、幅二・九センチの細長い形で、裏面に九九を記していた。
現代とは逆に大きい数の九九から始め、六九から四九までを飛ばした後、「三九廿四（さんくにじゅうし）」と間違えている。
見つかった二百三点の大半は、この木簡のように文字や計算を練習した跡だった。
表面を削って再利用できるが、木片も多く確認されており、繰り返し勉強した様子がうかがえる。
九九が書かれた同時期の木簡は他にも例があり、今回も計三点出土。解読した奈良文化財研究所は「官吏が一生懸命活動していたことを示す史料」としている。（上杉順子）
このたび、考古学的にとても興味深い木簡が、多数出土した。荷札あり、索引あり、その中に、九九の練習に用いたと思われる木簡があったらしい。しかも、間違えている。この役人は、是非とも自分の名前を彫り付けておくべきだった。そうすれば、後世に、自分の名と笑いを残せたであろうに。
さて、歴史に名を残すには、何も偉業を成し遂げる必要は無い。ただ現代のとりとめのない記録を、はるかな未来、例えば千年後に残るようにしておけばよい。千年前の退屈な日常というのは、考古学上とても貴重な情報である。もちろん、上の例のように、わざと笑いを誘う記録を残しておくのもいい。
さて、具体的な記録の残し方だが、CDやHDD、フラッシュメモリなどは役に立たない。現代使われているストレージは、数十年もすれば、読み取るための機械すら生産されなくなってしまうだろう。紙に書くのは、数百年ぐらいならば簡単に保存できるが、それ以上となると難しい。やはりここは、木や石に彫るべきである。
内容は何でもいい。自分の一日の詳細な日記だけで、遠い未来には、とても貴重な情報になっているからだ。もし笑いを取りたいのならば、わざと字を間違えておこう。さらに、一見平凡でまじめな日記に、いくつかとんでもない嘘を書いておくのも面白い。文面の例を挙げると、「現代では、光の速度を超える通信方法が確立されており、地球の裏側の友達へのpingは1ms以内なので、一切ラグのないFPSゲームを楽しめる」などだ。もし将来、光の速度を超える通信方法が発明されていれば、オーパーツとして話題になるし、あるいはまた、結局光の速度は超えられなかったとしても、考古学者の間で議論を呼ぶことは確実だ。
さて、情報を未来に残すことはできるが、自分自身はどうだろうか。化石として未来に骨を残せば、これも貴重な資料になる。あるいは、自分の肉体を腐敗させずに未来に残すことができれば、なお良い。
さて、より貴重な資料である、肉体の残し方について考えよう。よく博物館にある、Tレックスの化石とは、実は骨ではなく、骨が鉱石によって置換されたものである。肉体を腐敗させずに百年、千年の長きに渡って残すことは難しい。しかし、不可能ではない。SF小説に良く出てくる、カプセルの中で保存するような方法はお勧めできない。なぜならば、その機械が数千年に渡って稼動し続ける保障がないからだ。簡単な方法が二つある。ひとつは、永久凍土の中で氷付けになることで、もうひとつは、タールの池のなかに身を沈めることだ。
さて、肝心の笑いだ。もし無差別殺人に快楽を見出すというのであれば、マイナーな感染力の強い伝染病にかかっておこう。そうではなく、単に笑いを誘いたいだけならば、何か奇妙なものを飲み込んでおくべきだ。千年後の考古学者達が、自分の保存状態の良い肉体を調べたところ、胃袋にMP3プレイヤーが入っていたとしたら、だいぶ笑えるはずだ。
2008-06-22
modを使わないFizzBuzz
しかし、普通に作るのは面白くない。
void FizzBuzz( int i, int t, int f )
{
if (t == 3)
{
std::cout << "Fizz" ;
t = 0 ;
}
if (f == 5)
{
std::cout << "Buzz" ;
f = 0 ;
}
if (f == 0 || t == 0)
std::cout << "\n" ;
else
std::cout << i << "\n" ;
if ( i == 100 )
return ;
else
return FizzBuzz( ++i, ++t, ++f ) ;
}
int main()
{
FizzBuzz(1, 1, 1) ;
}
VC9の32bitコードにて、再帰の展開、i, t, fのレジスタ割り当てを確認。VC9の最適化もなかなかやるなぁ。
2008-06-19
東国原知事を殴りに行ってもいいですか
宮崎県の東国原英夫知事は１８日、子どもの教育に関連し「（体罰が問題視されない）げんこつ条例というものが宮崎県ではできないか」と述べ、一定の体罰は認められるべきだとの考えを示した。県庁で記者団の質問に答えた。
東国原知事は「最近は体罰ができなくなっている中で教師の位置付けをどうするか。愛のむちという範囲ならば殴っても罰せられない、愛のむち条例とかができないか」とも述べた。
これに先立つ県議会では、自民党議員が「昔はみんな、げんこつで教えられた」などと教育現場にはある程度の厳しさが必要と指摘。東国原知事は「大変示唆に富んでいる」と述べた。
もしそれ、教師が、客観的および絶対的に正しいとするならば、拳骨でもって教育することも正しいのだろう。しかし、実際の教師は人間であり、個人の価値観で思考している。したがって、常に正しいことを教育するために殴るという保証は無い。したがって、この東国原知事の発言は、単に人気取りや知名度向上のためのパフォーマンスか、あるいは真性のバカである。そのいずれであるとしても、私の価値観からは好ましくない。
そこでだ。私の価値観を「教育」するために、東国原知事を殴りに行ったとしても、まさか東国原知事は私を訴えるようなことはすまい。なぜならば、教育に暴力要素を取り入れるべきだと主張しているのだから、自分が教育されるために殴られても、感謝こそすれ、怒りはしないだろうと考えられる。
東国原知事と宮崎県議会の自民党議員さん、いまから殴りに行ってもいいですか？
ズッパで行く
私が幼稚園から小学校をすごしたのは、今は無き、静岡は浅羽町という町で、現在は袋井市になっている。ジュビロ磐田で有名な磐田市の隣だ。そこの子供だけが使う言葉に、「ズッパ」という言葉があった。用例は次のような次第。
甲「今日暇だら。俺んちで遊ぶか」
乙「分かった。家帰ったらズッパで行くに」
「早急に」という意味で使っていた気がする。主に使うのは小学生までで、中学生ともなると、もう使っていなかった。しかし、みな意味は知っていて、高校生の頃、「そういえば、俺ら子供のときに、ズッパって使ってたら」と言うと、皆が「そういえば使ってたに」と答えたものだ。この語源が気になる。ググってもほとんど出てこない。しかし、静岡の西部では、確かに使われていたのだ。
そういえば、「ジーコン」という言葉もあった。これは自転車という意味だ。おそらくは、自転車のチェーンが発する音から来たのではないかと思われる。ただ、私が子供の頃には既に、ジーコンと言う言葉はほとんど使われていなかった。祖父母と同居している子が良く使っていたので、結構古い言葉なのかもしれない。
ついでに、子供の替え歌というのは全国的にある。類似性があるのだが、地方によってところどころ違っている。私の記憶が薄れないうちに、ここに記録しておくことにしよう。いずれ、何かの役に立つかもしれない。
以下の歌は、私が記憶している替え歌である。ちょうど幼稚園から小学校ぐらいに歌っていた。
明かりをつけましょ、爆弾に
ドカンと一発ハゲ頭
五人囃子が吹っ飛んで
今日は悲しいお葬式
明かりをつけましょ、ろうそくに
ろうそく倒れて大火事だ
家事になったら救急車
救急車ウーウーうるさいよ
ブンブンブン、ハエが飛ぶ
便所の周りや、ウンコの周りを
ブンブンブン、ハエが飛ぶ
桃太郎さん、桃太郎さん
お腰につけた、毒団子
ひとつ私にくださいな
少なくとも、「明かりをつけましょ爆弾に」という替え歌は、全国的にあるようだ。一体誰が始めたのだろう。
簡単にはいかないeGUI++ライブラリ
http://msdn.microsoft.com/ja-jp/magazine/cc534994.aspx
イージーという名を冠していて、実際に簡単である例はないし、スーパーという名を冠していて、実際に優れている例もない。eGUI++はまさにそんなライブラリだ。
理想は評価する。現在のWin32は、識別子の命名は汚く、コードもC++とは親和性が低い。だからデザインはWin32を踏襲しない。それはいい。しかしだからといって、次のようなコードは無いだろう。
wnd<rebar> w = new_(parent);
rebar::item i(rebar::item::color | rebar::item::text);
w->add(i);
wndという名前が酷すぎる。まるで、どんな識別子でも短く省略しなければ気がすまない、POSIX信者の考え方だ。確かにタイプ数は減らせるが、クラス名としてwndは無いだろうに。new_やdelete_も鼻につく。
Windowsネイティブなのに、std::stringを用いるのは実に納得できない。やはり7-bit文字圏の連中はいつまでたっても一文字一バイト気分が抜けないものらしい。Windowsネイティブの文字コードはutf-16であり（9xのサポートは既に終わっている）、ANSIは下位互換性のためだけに残されているようなものだ。faith_and_braveはこのライブラリの流行に期待をかけているそうだが、こんなライブラリが流行った日には、いつまでたっても多言語を扱う問題は解決しない。それは後からでも追加できると反論されるかもしれないが、真に多言語を考えているならば、最初からUnicode対応にするはずで、それをしないのは作者に国際化という意識がないからである。
コードからWin32臭さを締め出す思想はいいのだが、ひとつ問題がある。プログラマはGUIのためにコードを書くのではなく、機能へのインターフェースとしてGUIを用いるのだ。機能を実装するには、Win32 APIを使わざるを得ない。なぜなら、Win32 APIが必要の無い機能ならば、今どき、わざわざC++やネイティブコードにこだわる必要は無いからだ。したがってこのコードを現実世界で使おうとすると、Win32 APIの命名規則と、省略思想の命名規則のコードとが混ざって、混沌となることは確実である。
追記
219 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/19(木) 02:43:14
流行るとは思えん。
ポータブルじゃないのに、
わざわざまったく異なる思想のコードを書きたいとは思わんし、
あと、識別子の命名がやたらに省略しててキモい。
つーか今どきstd::stringを使っていて、
しかもWindowsネイティブ限定とか、ふざけているとしか思えん。
220 名前：ヽ・´∀｀・,,）っ━━━━━━┓[sage] 投稿日：2008/06/19(木) 13:18:00
Viksoe先生頼みじゃ先細りだしな
ATLはともかく
221 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/19(木) 14:46:43
>>219
一応、こんな記述になっているようだが。
#include <string>
#ifdef UNICODE
typedef std::wstring string;
#else
typedef std::string string;
#endif
222 名前：ヽ・´∀｀・,,）っ━━━━━━┓[sage] 投稿日：2008/06/19(木) 18:33:19
きたねぇ実装だな。
_tstringよかマシだが
223 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/19(木) 19:30:00
>>221
なんじゃそりゃ。
ひでぇな。
Firefox3がリリース
Firefox3がリリースされたので、このブログを意図通りに見れるブラウザが増えた。具体的には、inline-blockだ。Firefox2はinline-blockをサポートしていなかったので、右側のラベルが、縦一列に表示されていた。このli要素をinlineで表示してしまうと、要素の途中で改行が起きてしまう。だからinline-blockが必要なのだ。
2008-06-17
ペットとしてのブタ
京阪三条駅にあるブックオフに行ったところ、森鴎外全集があった。森鴎外全集といっても、森鴎外の文書の多くは、書簡や論文など、楽しみつつ読む代物ではない。その中に、ファウスト考があった。これは森鴎外が、ファウストについて総合的に解説したものである。肝心のファウスト自体はなかった。このファウスト考と、芥川龍之介の本を二冊買って、帰路に着いた。
帰り道は、鴨川の横を通る。芥川龍之介の羅生門を読みつつ、ブラブラと歩いた。やがて、羅生門を読み終わり、手塚治虫の漫画に出てきそうな偉大なる鼻を苦にしている坊主の話に差し掛かったところで、前方に、犬を連れた夫人がいることに気がついた。犬はしきりに、「ブッ、ブッ」という、妙な息を吐いている。まさに追い越そうとしたとき、その犬は、実に変わった鼻と、不思議なヒヅメを持っていることに気がついた。何ぞ知らん。その犬だと思っていた四足の動物は、果たしてイヌではなく、ブタだったのである。
私「あのう、すみません。その、これは、ブタですよね」
夫人「ええ、ブタなんです」
私「ええと、ペットなのでしょうか」
夫人「ええ」
私「ブタというのはペットショップに売っているものなのでしょうか」
夫人「最近は売っているらしいですね。でもこの子は知り合いの牧場で生まれました」
そのブタは小型犬ぐらいの大きさで、黒毛であった。今日は機嫌が悪いらしく、すぐに道端に寝転んでしまう。しかし聞くところによると、機嫌のいい日は、三条から七条まで（4kmぐらい）、トコトコ駆けていくらしい。大人しい性格をしていて、暴れることはないんだとか。雑食なので、エサにはそれほど気を使わなくても良いとか。しかし好きなように食べさせすぎると、とても大きくなってしまうので、食事制限をしているのだとか。
進め!対戦ぱずるだま 闘魂!まるたま町
たまには懐かしいゲームをということで、NINTENDO64の「進め!対戦ぱずるだま 闘魂!まるたま町」から、ドキドキ・バニラと奥方様の対戦動画をば。もうかれこれ十年前のゲームと言うことになる。思えば懐かしい。
Flash Player
236Wも電力を食うGeForce GTX 280 発表
http://www.nvidia.com/object/geforce_gtx_280.html
この省電力主義の時代にコレはないだろうに。さらにこれは、三枚差しできるというから、恐ろしい。その場合、安定を期すためには、GPU専用の電源が必要になるだろう。
2008-06-15
ASCII以前の世界
Reliving life in the time before ASCII?
もしASCIIが無かったとしたら、お前ならどうUnicodeを設計するという問いに対するブログなのだが、この最初のコメントがすばらしいので紹介する。
ASCII以前の時代から生きていた俺に言わせてもらおう。
何が嬉しかったかって、ASCIIは7bit文字ですらなかったということだ。タイプライターが原型なんだけどな。
そもそも、その頃の環境も考えてみてくれよ。1バイトは8ビットと決まってるわけじゃなかったんだぜ。大抵のコンピュータは、6ビットを文字列に使ってた。しかも、6ビット通りの文字を使ってたわけじゃない、印字可能な文字が48文字もあるなんて贅沢すぎるってもんだ。だいたいメモリが極端に少ないと来ている。32k 36-bitワード長ってなだけでバカデカいメモリだったもんだから、そんな時代に、8ビット文字ないしは、16ビット文字なんて馬鹿げたものを、わずかな文字のために使おうなんて、馬鹿げているにも程がある。
それからな、磁気テープってのは6ビットにパリティビットがついたフレーム長だったんだ。通信はシリアルで6-7ビットだったし、プリンタやディスプレイはドデカイ文字セットなんて扱えるわけがなかったんだ。
というわけで、今と同じに考えるなってこった。あとな、IBMのSystem/360なんてものが台頭したせいで、てんでバラバラな8ビットのEBCDICが出てきて、滅多に使われんASCII互換ビットなんてものもあったわけよ。
こういう事情が、ASCIIの登場を、ミニコンピュータの出現まで遅らせたってわけだ。ミニコンピュータにはASCIIを用いたタイプライターがついてて、後には、DEC VT52というASCIIベースの文字ディスプレイ、あるいは他の、これまたASCIIベースのクローンディスプレイがついてた。そんな時代にビットマップデバイスであるとか、キャラクターコードであるとか、グリフなんて洒落たもんはなかったよ。まあ、ROMに独自文字を焼きこむってのはあったが。
マイクロプロセッサは大抵、ASCIIを使ってて、しかも1バイトは8ビットだったね。でも、Unicodeや巨大なフォントやらの可能性と将来性を示したのは、やはりIBM PCだろうな。まあ、膨大な8ビット文字のコードページ集とファミリー集に悩まされた後になっての話だったんだけどな。まあ、超絶スペックのハイエンドですら64キロバイトだったから無理もないんだが。
安いレーザープリンタの普及ってのも重要でな。HPのレーザージェットが普及したのは、ASCIIができてから二十年も後の事だよ。フォントも貧弱だったしな。ドットインパクトプリンタは昔からあったが、解像度ってものが無かった。今日の安くて高画質なカラーインクジェットプリンタなんて、ASCIIの黎明期には想像もできなかったよ。
だから当時の事情を鑑みるに、Unicodeなどを発明するのは不可能だし、今のこの現状を理解するには、ここまでたどり着いた過程を知らなければならない。
かくこと左様に、Unicodeの問題点を愚痴るために必要な技術というのがたくさんあるわけで、そういう技術背景がなければ、どうしてUnicodeより優れたものを作れようか。
Having lived in a time before ASCII, I have some perspective on that.
What you need to appreciate was that ASCII wasn't even a full 7-bit character set originally, and it was driven in large part by the need to clean up teletypewriter codes.
You also need to take into consideration the limitations of media at that time. The 8-bit byte was not the norm yet, and most binary computers used 6-bit codes for characters (and not all of the code points had available graphics - 48 printable characters were considered an abundance). Also, memories were *small*. 32k 36-bit words was a large memory and telling people to go to 8-bit codes or, worse, 16 bit codes for only a small number of usable code points would have made no sense at all.
More importantly, magnetic tape tended to use 6 bit frames (with parity), telecommunication was largely serial in 6-7 bits, and printers and displays did not handle large character sets.
So the opportunity was not present. Also, the emergence of the IBM System/360 computer messed things up by introducing a sparsely-populated 8-bit EBCDIC code with a version of ASCII relegated to a rarely-used "compatibility" bit in the program state.
This basically spoiled the opportunity to establish ASCII until the end-run by minicomputers (often equipped with ASCII-using teletypewriters and, later, the DEC VT52 ASCII-based alphanumeric display and other ASCII-based clone displays). These were not bitmapped devices and the character codes and their glyphs tended to be wired in, although burning your own character-generator ROMs was not unheard of.
Microprocessors generally used ASCII (and 8-bit bytes) but it was the IBM PC being an ASCII-based computer that foretold the ultimate opportunity to migrate to Unicode, large fonts, and so on, but only after the pain of code pages and families of ISO 8-bit codes. After all, we were starting with machines where the high-end products had 64 kilobytes.
The serious availability of economical laser printers was also important, and the H-P Laserjet did not reach the market until 20 years after ASCII, and font capabilities were limited. Dot-matrix printers had been around a long time but they didn't have the resolution. Today's low cost, high-quality color inkjet printer was unimaginable in the early reign of ASCII.
So circumstances would not have allowed for Unicode much before it actually arrived and I am not sure that today's hindsight would have been understandable without going through the process that got us where we are today.
There were a large number of technologies that had to advance together for us to arrive at a place where we could be complaining about the defects of Unicode and how we could do it over better given the chance (an opportunity I do not anticipate).
なぜEBCDICがてんでバラバラかというと、その割り当てを見てみれば分かる。とても使いにくい。しかも一文字を表すのに、8ビットも必要だ。
似たようなことは、いろんな技術に対して言われる。もし16bitコードの互換性問題が無ければ、32bitコードはどうなっているか。あるいは32bitコードが無ければ、64bitは如何に。そもそもx86がなければ。もしWindowsがなければ。もしCライブラリが無ければ。what if if if if if if......
やれやれ
三日前にひどく体調を崩して、ようやく回復した。どうしてこうも病弱になったのかと愚痴をこぼしていたら、父親曰く、「お前、昔っから季節の変わり目には、決まって体調を崩していたじゃないか」と。そういえばそうだったかな。
しかし、数日寝込んでいただけで、Google Readerがたまりっぱなしだ。普段コレだけ大量のRSSフィードの中から、必要なもの、面白いものをより分けて読んでいっていたのだと考えると、不思議な気がする。
とりあえず面白いものをいくつか。
携帯年代記、あるいは、なぜ俺がTYTNⅡを捨てるに至ったか。
概要：携帯に欲しいものは、結局電話とメールである。電話とメールが簡単にすばやくできることが必要なのであって、ゴチャゴチャした機能ではない。（しかし、日本の携帯はUnicodeに対応していなかったり、RFC違反のメールアドレスを許容する。やれやれだ。）
マイクロソフトの未来デモ。ハァ？ 何コレ？ 馬鹿じゃねーの。
概要：PC環境に対して五つの不満しか持たないオッサンが登場して、完璧にフラットなキーボードで、完璧なブラインドタッチを披露するデモ。未来の時計はめちゃくちゃ狂っており。色盲は生き延びられない。
2008-06-14
VistaでHPETが使われていることの確認
HPET(High Precision Event Timer)について
Guidelines For Providing Multimedia Timer Support
今走っているPCで、タイマーには何が使われているかというのは気になるが、残念ながら確かめる方法はない。最近のチップセットは、大抵HPETを実装しているのだが、実際に使われているのかどうか気になる。
と思ったら、今使っているマザーボードのBIOS設定に、HPETの有効無効を切り替える設定があったので、試してみた。
まず、HPETが有効な状態でQueryPerformanceFrequencyを呼ぶと、14318180を返してきた。次にBIOSの設定で、HPETを無効にしてみると、3579545であった。再度HPETを有効にすると、値は元に戻った。なるほど、HPETが使われているらしい。
HPETでは少なくとも、10MHz以上の解像度が保障されている。チップセットやBIOSのバグさえなければ、マルチプロセッサ環境で、異なるプロセッサ間でも問題ないらしい（もちろん、そういうコードを書くとXP環境切捨てになるが）
ちなみに当然だが、Windows Vista以降が必要（XP出荷時には、まだHPETは規格すら決まっていなかった）
2008-06-12
利権役人「数億円かけて犯罪予告の検知ソフトつくる」 矢野さとる「0億円二時間で出来たよ」
犯行予告収集サイト「予告.in」公開 「0億円、2時間で作った」
完璧なスパムフィルタが書けないのだから、完璧な犯罪予告収集ソフトもまた、書けるはずがない。それよりは、ネット上の犯罪予告を探すのが趣味な、いわゆる暇人を使ったほうがいい。Diggのようなリンクを貼れる仕組みがいいだろう。
というわけで数億円はすべて、「犯罪予告を見たら110番」という広告に費やしたほうがマシである。
もちろん、人力検索を回避する方法はある。例えばスワヒリ語を使うなど。もちろん、日本国内における犯罪予告の役割は、既に果たしていないが。
2008-06-10
仁和寺の法師は、実は馬鹿で無いのではないか
先週、ふと思い立って岩清水八幡宮に行ってきた。その途中で、ふと考えたことがあったので、ここに書き記しておく。徒然草の第五十二段に、次のような話がある。
仁和寺にある法師、年よるまで岩清水を拝まざりければ、心うく覚えて、或る時思い立ちて、ただひとりかちよりもうでけり。極楽寺、高良などを拝みて、かばかりと心得て帰りにけり。さてかたへの人にあひて、「年頃思いつることはたし侍りぬ。聞きしにも過ぎて尊くこそおはしけれ。そも、参りたる人ごとに山へ登りしは、何事かありけむ。ゆかしかりしかど、神へ参るこそ本意なれと思いて、山までは見ず」とぞいひける。すこしのことにも、先達はあらまほしきことなり。
国語の教科書にも載っている、有名な話だ。何の予備知識もなく、この話を読んだ人は、大抵、次のように思うに違いない。
「なるほど、何でも岩清水という寺院があるのだな。仁和寺のある老坊主が、この寺院を拝みたいと思い、歩いて出かけたのだな。寺院そのものは、山の上にあるのに、この坊主はその近くにある、極楽寺、高良の二ヶ所を拝んで満足し、肝心の岩清水は拝まずに帰って行ったのだな。来る人は皆、山の上に登っているというのに、何故登るか訊ねもしなかったらしいな。この教訓から学ぶべきことは、些細なことでも、助言を求めるべきなのだな」と。
この解釈は実際、間違いではない。吉田兼好の意図も、少なくとも文面上は、そうだったに違いない。しかし、実際はどうであろうか。
まず、仁和寺がどこにあるか、ということから説明しよう。仁和寺は、京都市右京区にある。これは、京都市の中でもだいぶ北西に位置する。
View Larger Map
次に、岩清水はどこにあるか。岩清水とは岩清水八幡宮のことであって、八幡市の男山の上にある。京阪の八幡駅を降りてすぐのところだ。
View Larger Map
現在ではどうやって行くかというと、次のようになる。
View Larger Map
Googleの提案は正しい。仁和寺から京阪までは、地図上でみれば大したことがないように見えるが、実際にはとても遠い。ましてや三条から八幡市となると、歩いていくのは相当な道のりである。もちろん当時は、列車などないわけだから、わざわざ鴨川まで行く必要はないにしても、歩く距離で言えば、そう変わらない。
では以上を踏まえて、仁和寺の法師の足取りを追ってみよう。
仁和寺にいた老法師は、岩清水を拝もうと決意する。そして朝早く出発して、昼過ぎまでかかって、ようやく男山のふもとにたどり着くわけだ。歩き疲れて棒の様になった足を引きずり、ふもとにあった極楽寺や高良を見たときの法師の感動は、どれほどであろうか。実に半日歩き続けて、ようやく念願の岩清水にたどり着いたのだ。
早速、その二院を拝む。ふと見ると、皆、山の上に登っている。法師は、何故皆が山に登るのか、疑問に思ったことであろう。その山は、男山と呼ばれている、とても低い山である。山と言うよりは、ほとんど丘である。木々が生い茂っていなければ、誰が山だと思うだろうか。仁和寺から東を望めば、すばらしい霊山、比叡山を目の当たりにできる。その比叡山と比較して、みすぼらしいこと限りない男山、とても低い男山。しかも、皆山の上に上がるため、わらじで踏み固められた道は、とても登りやすい男山。そんな山に、わずかでも霊力や畏怖を感じることがあろうか。
そして法師はこう考える。「なるほど、皆が皆、あの山に登るからには、何かあるに違いない。山伏だけが登るわけでもなし、大方は社か何かだろう。しかし、拙僧は仁和寺より徒歩でここまでやって来た。そして極楽寺、高良の二院を拝むを得た。これ以上、何の尊いことがあろうか。仁和寺から歩いてくる苦労に比べれば、あんなちっぽけな山は登るに足らず」と。
そうして、満足して帰って行ったわけだ。なかなかに行を積み、教を兼ね備えた聖にはあらずや。
因云。岩清水八幡宮とは本来、神社だった。しかし後に、神仏混合になった。神社でもあり、寺でもあったのだ。日本人の宗教観は、かなりおおらかで、この世には絶対的に正しいただひとつの唯一神がいる、などとは考えない。神であれ仏であれ、皆同様に尊いもので、敬うべきだと考える。だからこそ、本来神道であるはずなのに、八幡大菩薩などというよく分からないものが出てくるのだ。明治になって、神仏分離などという、大失敗の政策が取られた。悲しいことだ。
2008-06-09
なんだかなぁ
自分もだいぶ悩んだ末にあきらめたが、まさか問題の有るコミットだけ消す手法に出るとは。しかし、x264は今後ますます、わずかな数十クロックを削るために、gccのインラインアセンブラと、スタックが16バイトアラインメントされる仕様に、ズブズブと依存していくだろう。いつまでそれを続ける意欲が継続できるのやら。
gccはスタックを16バイトアラインメントしている。すべての関数は呼び出された時点で、スタックが16バイトアラインメントされているのだ。だから現在のx264は、スタックは常に16バイトアラインメントされているという前提の下に書かれている。連中は、必要な箇所すべてで、アラインメントを合わせるのは面倒だし、余分にクロックがかかると考えているのだろう。
2008-06-07
while(0)の有効活用
以下のコードとの違いが良く分からない。
BOOL func( void )
{
#define break return FALSE
if( !test1() )
{ break ; }
if( !test2() )
{ break ; }
if( !test3() )
{ break ; }
if( !test4() )
{ break ; }
if( !test5() )
{ break ; }
testOKfunc() ; // 条件を満たせばできる処理
#undef break
return TRUE ;
}
一問だけのIQテスト
今日一日をどのように過ごすか、たった一問だけのIQテストで決めましょう。
ある口のきけない人が、歯ブラシを買いたいと思っていました。彼は歯みがきをするマネをして、店員に歯ブラシが欲しいと伝え、無事に買うことができました。
それでは、目の見えない人が、自分の目を隠すためにサングラスを買いたいとしたら、一体どのように伝えればいいのでしょうか。
答え（テキストを選択して反転させること）：口を開けて、「サングラスを買いたいのですが」と言う。
もし、この問題を間違ったならば、今すぐパソコンの電源を切って、健やかな一日を過ごしましょう。
筆者注：さて、俺も電源を切らねば。
（お前だって間違えただろ、さあ今すぐ電源を切るんだ）
PSY RDOについて
PSY RDOについての説明。
RDOを、誤解を恐れず大雑把に説明すると、画質劣化と、ビットレート削減の、ちょうど最適なところを選択する方法だ。ビットレートを下げると。もちろん画質が劣化する。しかし例え画質が多少劣化しても、それ以上にビットレートを下げることができるならば、それは画質が上がったといえる。より少ないビットレートで、よりマシな画質を得られるわけだ。
そして、このどこまで画質劣化を劣化させて、ビットレートを節約していいのかという答えを求めるのがRDOである。あまった分のビットレートは、また別に使えるという寸法。
さて、この画質劣化具合を、どのように計測するかという事が、問題になる。画質を簡単に数値で比較する方法として、PSNRとかSSIMなどがあるが、人間の目はPSNRやSSIMで画質を見ているわけではない。たとえこれらの数値が高くても、人間の目にはより劣化しているように見える画像もある。
PSY RDOは、この画質劣化具合の計測方法に対する改善で、より人間の目に対して、高画質に見えそうなものを、高く評価するという内容。何でも「複雑さ」とやらで判断しているのだとか。AQやPSY RDOを使っている場合、PSNRやSSIMで画質を語るのはもはや意味が無い。自分の目で評価すること。違いが分からないなら、それは自分の目、および再生環境では、画質が上がっても下がってもいないということだ。
しかしPSY RDOはすばらしい。
デビルメイクライ４ 体験版プレイ動画
Flash Player
psy RDOの威力は目を見張るばかり。驚くほど、人間の目に対する画質が向上する。ちなみにこの動画は、1280x720なので、フルスクリーンで見るか、あるいはダウンロードしてみることをお勧めする。どちらも、右下のボタンで行える。
2008-06-06
にわかに信じがたいC++のOverload resolutionのルール
class string {
public:
string(const char*);
} ;
void f(string, string, bool = false) ; // 1
void f(string, bool = false) ; // 2
void g()
{
f(“Hello”, “Goodbye”) ;// 2が呼ばれる
}
なぜか。まずオーバーロードの解決をするために、一つ目の引数を見る。これはどちらの関数も、string型を取る。string型はコンストラクタにconst char *型を取るので、コンパイラはstring型に変換できる。二つ目の引数はどうか。関数１はstring型を引数に取るが、関数２はboolである。人間的に考えると、関数１を呼んで欲しい。しかし、規格では、関数２が呼ばれるのが正しい挙動だ。なぜかというと、コンストラクタを使って変換するより、ポインタをboolに変換するほうが、規格上、より高い候補になるからだ。そんなわけで、コンパイラは、関数２を、正しく、呼ぶことになる。。
via Some C++ Gotchas
悪魔は泣くかもしんない４
私は昔から、流行に流されず、自分独自の価値観を持っている人間であった。もちろん、裏を返せば、流行に疎い、ということになる。
小学校のある時、クラスメート達が盛んに、福音、福音、と叫びだすことがあった。私はテレビなどには面白さを見出せず、まったく見ていなかったので、この現象を目の当たりにして、かの四人の福音者が書いた聖書、すなわちキリスト教というカルトが学校中に蔓延しているのか、と思っていた。何ぞや。私が福音だと思っていたその言葉は、カルト宗教にあらずして、新世紀エヴァンゲリオンというアニメのタイトルであったとは。
また、中学生のある時、クラスメート達が盛んに、DDR、DDR、と叫びだすことがあった。私は、「そうか、やはり、時代はDDR SDRAMか。何しろ速いからな」と、当然のごとくに信じていた。まさかそれが、足で踏んで操作する風変わりなダンスゲーム。ダンス・ダンス・レボリューションであるとは、夢にだにも思わなかった。何しろ、知らなかったのだから。
そういうわけで、上記二点に賛同してくれる、私と趣味の合う同志は、「デビルメイクライ」という言葉を聞いた時も、「悪魔は泣くかもしんない」と解釈した私に、幾ばくかの理解を示してくれることだろう。なにしろ、コンソール機のゲームといえば、スーファミ以降はまったく遊んでいない、この私なのだから。
何はともかく、デビルメイクライ４の体験版だ。
実際に遊んでみたが、あまり金をかけていない、私のPCでも、かなり快適に動作した。コントローラは、XBox360を前提にしている。私はもちろんXBox360のゲームパッドを持っているので、とても自然に遊ぶことができた。
ただ、あまり面白いとは思わない。ゲームを進めるために必要なのは、ボタンの連打だ。囲まれないように隅に追い詰めて叩いていれば、いつの間にか敵は倒せる。これではファイナルファイトとあまり変わらない。ファイナルファイトも、画面隅に敵を集めて、まとめて叩くだけのゲームだ。ただ、攻撃が連続して入るのは、一種痛快な感がある。しかし、数分ほど敵を叩いていると、奇妙な感覚を覚えた。それは手回し式オルゴールに似ている。オルゴールの美しい音楽を聴くためには、ハンドルを回さなければならない。片や、敵を倒す痛快な動画を見るためには、ボタンを連打しなければならない。いまならば、昔、ハイパーオリンピックが大流行した理由も分かるというものだ。見たいのは速く走るランナーで、そのためには、ボタンをできるだけ速く連打しなければならない。昔も今も、ゲームというものは、まったく変わっていないようだ。
太陽の下に新しきことなしとは古人の道破した言葉である。しかし新しいことのないのは独り太陽の下ばかりではない。宇宙の大に比べれば、太陽も一点の燐火に過ぎない。況や我我の地球をやである。
2008-06-05
LLVMというBSDライセンスなコンパイラ
まあ、実際にはUniversity of Illinois/NCSA Open Source Licenseなわけなのだけれど、たぶんBSDライセンスとも互換性はあるだろう。非常に緩いライセンスだ。
llvmは、いわゆるコンパイラとしての機能を提供するもので、コンパイル時、リンク時の最適化はもちろんのこと、実行時の最適化もある。処理系に依存しない仮想命令セットも用意されている。実際のコンパイラのバックエンドとしては、"X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha, SPARC, MIPS and CellSPU" をサポートしているほか、ポータブルなCコードへのバックエンドもある(Bjarne Stroustrupの書いていたCFrontみたいな形)、また、X86, X86-64, PowerPC 32/64へは、JITコンパイルも可能だ。そうそう、MSILへのバックエンドなんてのも有る。これらのバックエンドは、フロントエンドさえ用意されていれば、どのような高級言語からでも変換可能だ。
フロントエンドとしては、GCCを利用した、gccとの互換性の高いC/C++フロントエンド（ただし、実際にgccのフロントエンドを利用しているので、GPLライセンスになる）のほか、llvm独自のC/C++フロントエンドも有る。こっちはGCCのような過去の遺産に引きずられていないため、パースや最適化にかかる時間が早いとのこと。
もちろん、llvmを利用して、俺様言語からのフロントエンドを作ることもできる。llvmの多彩なバックエンドを自由に使えるわけだ（CやMSILのバックエンドまである） ライセンスが緩いので、ソースコード公開の義務は無い。
で、私個人の意見はまた別に有る。処理系に依存しないといっても、コンパイラ自身のビルド、また実行は、*unix限定だ。Windows信者としては、まあ、gccの好敵手となるのかどうかを見守るぐらいしかできない。
しかし、WindowsのC++コンパイラにも、何かVC以外の手段は無いのだろうか。iccはいいとして、bcc is so 90sだし、minGWとかcygwinは、そもそもWindows環境のコンパイラじゃなくて、posixをそのままWindowsに移植したといったほうが適切だし、ウォルター・ブライトさんのdmcは、誰も知らないし。
2008-06-04
BSD Unixは悪魔の所業である
以下に述べる事は、実話である。
先週の事なんだけどね、アタシは地元の郷土料理のレストランにテイクアウトの注文に行ったの。店員に注文をサッと言ったら、注文はすぐできるって言うの。
それでね、待っている間に、壁にかかってた農場の見取り図を眺めてたらね、二人の……なんていうか、いわゆる「土人」が近寄ってきたの。奴らったら、どっからどう見ても、典型的な最底辺のテキサス白人ですって感じでね、カウボーイの帽子にヘビ皮のブーツ、おまけに安いビールとウィスキーのにおい。
「なぁ、嬢ちゃん、ひとつ聞いてええか？」
アタシ、テキサスの人ってとってもフレンドリーだって聞いてたから、もちろんオーケーしたわ。
「お前、悪魔を崇拝しとんのか」
もーすっごいスゴんだ言い方すんのよ。
「えー、違うけど何で」
「そっか、嬢ちゃん、そりゃホンマか」
アタシ、カウボーイのチアリーダみたいに満面の笑みで言ってやったわ。「もちろんよ。オカルトなんてテレビでぐらいしか見ないわ」ってね。
「ふーん。アンタおもろいな。アンタのおっぱいの上にゃ、悪魔が乗っかってんのにな」
超ムカついたんでビンタ喰らわせてやろうって思ったら、ハッと気がついたの。その時、アタシが着てたＴシャツを。とあるオペレーティングシステムの、昔からのマスコット、ちっちゃい悪魔みたいなのがスニーカー履いてる絵。
奴らは、「な、嬢ちゃん。ワシら悪魔の絵を見せてる連中が気にくわねえんやで。特にそいつが、変になれなれしいと来ちゃあな」
この超ムカツク馬鹿は、マジになっちゃってんの。
アタシ、「あ、いや、これは悪魔じゃなくてね。その、マスコットみたいなものよ」
土人、「で、ドコのフットボールがそんな悪魔をマスコットとして使っとるんや」
アタシ、「これはそんなんじゃないわよ。オペレーティング……えーと、コンピュータね」
どうせ連中は、ATM以上の技術になんて触れたことがないだろうし、unixなんて口に出しても、話を余計ややこしくするだけだろうしね。
土人、「その悪魔のコンピュータはどこのモンや」
アタシ、「カリフォルニアよ、あと悪魔なんて関係ないわ」
この辺で、店員がイザコザに気づいたみたいだったけれど、体格も違いすぎるし、同情的な目で見て、奥に逃げ込むぐらいしかしなかったみたい。
土人、「アンタ、ウソついてるんとちゃうんか。サッサと出てってくれへんか」
ラッキーな事に、店員がすぐに、注文を持って戻ってきた。お金を払ってる間、奴らがこんなことを言ってたわ。
土人Ａ、「ポリ公はこの悪魔のコンピュータを知っとるんやろか」
土人Ｂ、「カリフォルニアのものってんなら、FBIが知っとるんちゃう」
店を出る間際に、言ってやった。「本当に馬鹿ね。この『コンピュータ』は、とても使われてるわよ。大学、研究、仕事。とても便利なのよ」
大、大、大失敗だった。後先のことを考えておくべきだったみたい。
土人、「お国もこの悪魔のコンピュータを使っとんのか」
アタシ、「ええ」
大ブーイング。
土人、「じゃ、お国はこれに金を払っとるわけか。ワシらの税金から」
アタシ、そろそろ切り上げるべきだと思ったの。
アタシ、「全然。１ペニーたりとも払ってないわ。キリスト教徒がそんなこと許すはず無いでしょ。じゃあね」
テキサス、何て国。
これはかなり昔の話らしい。少なくとも十年以上前。Windowsすらあまり有名ではなかった頃の話だとも言われている。
via Godless devil-worshiping evil computers
digg : Unix is the devil's work
2008-06-02
進化神はまっすぐ歩かない
中江兆民は、その著書「三酔人経綸問答」の中で、紳士君をして、次のように言わしめている。
嗚呼、民主の制度なる哉、民主の制度なる哉。君相専擅の制は、愚昧にして、自ら其過を覚らざる者なり。立憲の制は、其過を知りて、僅に其半を改むる者なり。民主の制は、磊々落々として、其胸中、半点の塵汚無き者なり。
そして、この、専制政治から立憲君主制に移り、そして民主制へと移っていくのが、政治の必然の進化であると言っている。
さて、ここでネパールを見てみよう。ネパールは戦後、立憲君主制に移って、だいぶ民主主義を認めたものの、依然として実権は国王にあった。2001年6月1日には、ネパール王族が殺害されるという事件があり、黒幕ではないかとの疑念もあるギャネンドラが、結果的に王位につく。アメリカから、民主主義推進と、アカの手先の毛沢東主義者を弾圧したら援助くれてやるよという甘い言葉に騙され、とりあえずアカ狩りをしたが、民主主義にはあまり興味を示さなかったため、アメリカからもハシゴをはずされ、どうしようもなく、王権剥奪される。
何ぞや、彼進化神は進むことを好みて、退くことを好まずして、其進往するに方り、幸いに道路坦直にして清潔なる時は、大に善し。即ち、岩石凸立して、輪を礙へ、荊棘茂生して蹄を没すること有るも、夫の進化神は略ぼ沮喪すること無く、更に益々奮激し、趾を挙げて一蹴し、踏過して顧みずして、頑迷なる人民が、相共に脳を裂き肝を破り、街衢上血を湛へて、所謂革命の活劇を演ずるに至るも、夫の紙は当然の結果なりと看做して、少も忶るゝこと無し。
そもそも君主とは、臣民の持つ権利を、一時的に貸し与えているに過ぎない。だから、時が来れば、臣民に返すべきなのに、自分が持つ権利であると誤解して、強引に所有権を主張すると、このように追放、処刑の憂き目にあい、後世の笑い草となる。
さて、進化の理にしたがって、ネパールに民主政治がもたらされるかというと、どうもそう簡単にはいかないようだ。というのも、一番人気の政党が、毛沢東主義で、早くも言論封殺する旨を発言しているそうだ。
では、タイはどうか。タイもまた複雑で、戦後しばらくして、民主政治に移るのだが、どうも、うまくいっていない。たびたび問題が起こり、国王のお墨付きを得た軍が征圧している。未遂も含めて、過去十六回も行われているのだ。国王による軍を動かしてのクーデーターというと、だいぶ危険な響きがするが、実情はそれほどでもなくて、タイの国内は、案外平和らしい。実際、2006年9月19日のクーデターも、野党が選挙をボイコットして、民主主義が危ういだとか、首相がインサイダー取引疑惑の結果で、無血クーデターと呼ばれている。その後、2008年2月6日には、内閣が発足し、また民主主義に戻っている。
タイには、国王に対する不敬罪などもあるが、どうも実際のところは、国王による恐怖政治の結果の法律ではなく、国民の国王に対する信頼が篤く、その結果らしい。映画上映の前には国王の映像が流され、観客は皆直立しなければならないなどの、不思議な決まりがあるらしい。また、タイのインターネットは、不敬罪にあたるサイトや、ポルノサイトを規制しているようだ。
民主制を目指そうとして、破綻しているネパール。民主制がうまくいっていないが、まあまあまともにやっているタイ。進化神は気まぐれである。