.「世の中おおよそ悪意に解釈すれば何でも敵に見える」という法則がありますな。 私は「おばけの法則」と名づけてますが。 .これは、根本的には相手に対する不理解による恐怖の裏返しで、 心理的 FUD (Fear, Uncertainty, Doubt)とでも呼ぶべきものですな。 未知のもの不明確なもの(Uncertainty)に対する恐れ(Fear)が、 おばけ(Doubt)を見せてしまう。 揺れる柳の枝みたいな、どう考えても何の敵意を持つはずもないものが、 見る側のある種の悪意でおばけに見えてしまう。 .人間に特有な心理的防衛反応ですな、これは。 こういう状態になると、すべての対象を「敵か味方か」 の二色に塗り分けてしまう。 これは頭が生存本能を発揮してる状態なんですね。 生存本能というのは 「敵の息の根を止めるか、それともこっちの息の根が止められるか」 というそのギリギリのせめぎあいにおいて発揮される本能なので、 そういう思考においては敵と味方とを迅速に二分して判断するのが 合理的とされる。 玉虫色なんてのを考えていたら相手に殺されてしまう (と本人は思いこんでいる)から、 物事をなるべく単純化したほうが望ましい。 .まあ、現代でこういう生きるか死ぬかの切羽詰まった状況に陥るというのは そうそうないのですが、人間はその本能を捨てていない。 しかしながら、これはえてして不明確なところでの 判断になりがちであるということに加え、 対話と相互理解を欠いたプロセスに陥りがちなので、 その結果はあまり好ましいことにはなりませんな。 こういう「敵を創り出す思想」が戦争にまで発展した例は、 枚挙にいとまがありませんね。 .そういう本能に打ち勝てるかどうかという点において、 人としての理性が問われると思います。 今の世の中、何をするにしてもとりあえず深呼吸をしてからそれをするくらいの 時間的余裕はあるものなので、とりあえず深呼吸を忘れずに。 |
.未踏 。 「未踏に応募して受かったら辞退」 ってのをやろうかと思ったことはありますが :D .それはともかく、事あるごとに 「あんな愚にもつかない酔狂で税金を無駄づかいするのはやめろ」 と言ってる私が未踏でお金をもらうわけがない。 あれでお金を貰うのはプロとしてのプライドを捨てる必要があると思う。 さいわい、私個人はそこまで食い詰めてない。 それに、いろんな話を総合すると、 (あえて「何が」と言わないけど)怪しいよ、あれ。 .まー、私が未踏に応募したら、食い詰めたか、あるいは辞退するためだと 思ってください :D |
.なんか愚痴ばっかやね :D .テロ朝のダイオキシン報道の件、差し戻しらしいやね。 それはいいとして、テロ朝のコメントはやっぱり「報道の自由の侵害」 だから何とかの一つ覚えですな。 .あまり誰も言わないんですけど、 そもそも、「報道の自由」ってのを神聖視して、 それが無批判無秩序に行使できるべきものなんだという考えを持つこと自体が、 実はかなり危険な思想だと思うんですけどねぇ。 現代では報道が権力の一つのように数えられているということを考えればですな、 たとえば「軍部の活動の自由」が神聖化され、 それが無秩序に行使される場合と同じくらいには、 危険なことなんじゃないかなぁ。 .それに、一般的に言って、近代以降の思想としては、 自由権ってのは基本的に「他人の権利を侵害しない限りは自由」なのであって、 他人の権利を侵すような状態でも放任される自由ってのは、 社会秩序のある限り容認され得ないのよ。 .まあそういう観点では、最高裁の判断は基準としては それなりに妥当だと思う。 でも、やっぱり世の中の趨勢は報道に甘いんですけどね。 今回は多くの部分がテロ朝(というか制作会社)の独自取材に依ってたから 一次情報源としてのテロ朝の責任問題になってるけど (あるいは文藝春秋絡みの裁判もそんな感じね)、 二次情報源、つまり、「デマの砲台」としての報道機関の 責任を問うた裁判に目を向けてみると、 ほとんどの国内外での判例では全く責任が問われてないんですな。 |
.select は論外として、 poll と kqueue の違いで一番大きいのは、 機能うんぬんよりもそのセマンティックの違いだろうな。 この辺は、どうも kqueue の manpage を見てもわかりにくいんだけど、 一回使ってみればわかる。 .つまり、poll が入出力を一つの構造体の配列として表わすため、 イベントが発生したデスクリプタを探し出すためには、 poll 構造体の配列を先頭から順番に舐めないといけないのに対して、 kqueue では入力と出力が独立した構造体の配列になっているため、 出力側の配列に発生したイベントだけが詰めて格納されるようになってる。 「常に、ほとんどすべてのデスクリプタでイベントが発生している」 という(あまりありそうにない)ケースでは、 データのコピーが発生しない poll のほうがパフォーマンスは良いのだが、 あまり同時にイベントが発生しないケースでは kqueue の方が良い。 .特に、計算量という観点で見れば、非常にモデルを単純化すると、 poll では監視するファイルデスクリプタ数とイベント数のほぼ積に 比例した計算量が必要になるのに対して、 kqueue ではほぼイベント数に比例した計算量となる。 典型的には、監視デスクリプタの数とイベント数は ほぼ比例してると見なせるため、簡単に言えば poll は O(n^2) な方法、 kqueue は O(n) な方法ってことですな。 .難を言えば、kevent 関数に登録とポーリングを詰め込んでるのが気持ち悪いので、 kevent_change と kevent_poll みたいに分けたほうが良かったのもしれず。 まあこれは、システムコールの数を減らしたかったんだろうし、 使う側で分けて使えばいいだけの話だけど。 逆に言うと、登録とポーリングを同時に行うのは、 あまり良いスタイルではないかもしれないですね。 .kqueue は上みたいな利点もあるし、 イベント構造体に udata っていうクロージャを持たせられるし (これがないと上の利点を生かせないケースがあるし、意外と便利よ)、 何より受けられるイベントが豊富でしかも拡張可能だったりと、 いろいろ嬉しいのでみんな使いましょう。 .あんまり面白くないけど、何より簡単で上記のエッセンスがつまったサンプル: |
.ナイス 。 X-TT バックエンドを延命させるには、 少なくとも freetype2 に対応させる必要があるのだけども、 まああまり実りの多い作業には見えないし、 いっそのこと既に freetype2 に移行している xfsft バックエンドを使って、 上だけ互換性を取ってしまったほうがいろいろと良いでしょうな。 個人的には TTCap もさっさと安楽死させて欲しいんだけど :D .Juliusz 君、その反論はあまりにアレだと思いまーす 。 一応、XFree86 の方針として「技術的に良いか悪いか」 がパッチ受け入れの条件であって、 「コアフォントを殺すべきかどうか」 という政治的判断はそれとは無関係であるべきだったんじゃないかなぁ。 その方針が良いかどうかは別として。 .まあ私も過去に似たようなことやってるから口出さんけどね :-) |