某日記

(中期)

平成15年9月11日(木曜日)

ねむ。

客観の功罪

フレームの功罪 。 まあ、 文字サイズ固定のススメ よりは論点がはっきりしてるものの (私には後者の文章に関して論点というか必然性がさっぱり把握できなかった)、 この手の話を読むにつけ、ある種のむなしさを感じる。

個人的には、主観にかかる事項の一方のスタンスへの 「客観を装ったある種の批判のようなもの」に対抗する形で 客観的事実の羅列によって反論を行っても、 結局のところは(相手を論で打ち負かすという意味以外では) 大した意味はないんじゃないかと思うし、どちらかといえば、 主観は主観のままとして、両者の立場を「客観的な切り口」から比較して、 その判断は読み手の主観的判断にまかせ、 筆者自身の (主観的)判断に関してはせいぜいページの最後で軽く述べるにとどめる、 という形にしたほうが、目的が明確になる気がしますな。

上の文章は、 「フレーム利用への攻撃に対する反撃を行う」 という意図においてはおそらく成功してると思うのだけど、 それ以上の何らの意味をも為していないと思う。 それで筆者の目的が達成される/されたのならば、 それでかまわないと思うのだけれども (黙らせるというのは、それはそれで場合によっては有効な手段だな)。 しかし、もし、それ以上の、たとえば「もっと良いページが増えてほしい」 という意図をもって行っているのだとしたら、 多分それはこういうやり方では達成されないんじゃないかと思う。 率直に言えば、 意見をどう見せるかという点から見て述べ方が下手なんじゃないかなと。

なお、フレームに関して私個人の立場は「どーでもいい」です。 便利だと思うときは便利だと思うだろうし、 面倒だと思うときは面倒だと思うでしょうな。うん。

平成15年9月12日(金曜日)

昨日

ドルフィンネットのネットワークが重くてメールのフェッチも ままならなかったのでふて寝。

みやげ話

ううむ 、 「ちん○すう」じゃなくてまだ良かったと思う午後。

今週のチャンピオン

昨日書くの忘れてた。記憶を辿ろう。

フェイスガード(1)。奥義・引き出し昆布。

フェイスガード(2)。見えたッ

萌え遊戯王。首輪+スク水とは、また飛び道具を……

ファンタジーゾーン。別モノ新作だよ。

×。 9/11

Imakeicide

imake 抹殺 。 ぃぇぃ!

夜中

虹裏が久しぶりに安定。

5回も噛まれた人間には「その犬を見捨てる権利」がある

発想がすごいよな。本来なら、「犬がかわいそう」で済む話なんだけど、 もはやそれがわからない人が増えたんだろうなぁ……。

そういう感覚的な話をひとまず置いておくと、 「権利」という言葉の濫用がすごく気になる。 権利というのは法的なものなので、そういう観点では、 法律上犬の所有権をもつ飼い主にその犬を処分する自由(という権利)は 確かにあると言えるんだけども、ポイントは、 それはあくまでも法に限定した話に過ぎない、ということだね。

どうも世の中、法というものを誤解してる人が多いんじゃないかと思うのだけど、 法というのは人間が社会生活を営むうえで守るべき規範の、 ほんの一部に過ぎないのよ。法を守っていればそれで十分かというと 全くそうではなくて、法と両輪をなすものとしてのいわゆる道徳というのが 存在する。それは、(法にはできないから)法にはなってないんだけど、 法でないからといって守らないでいいというものではない。

しかるに、上のような身勝手な理由で犬を処分してよいかどうかというのは、 もはや法的な話ではなくて道徳にかかる話なのよ。 だから、権利を持ち出すような話では最初っからない。 こういうのは権利という言葉、あるいは権利そのものの濫用といえるだろう。 「命を大事に」というのが万人にとってごく当然の道徳だと私は思っているし、 たとえその道徳の「正しさ」が万人に直感的でなかったとしても、 少なくとも身勝手な理由でその道徳を無視して、 それを「権利」の名の下に正当化するというのはすごく情けないことだと思うし、 恐いことだな。 馬鹿に刃物というけれど、馬鹿に権利を与えるのも危険だ。 だからといって「馬鹿に権利を与えるな」と言えるかというと、 それはそれで民主主義というものの原則からして危険ではあるんだけど。

ただ、民主主義というのは、 みんなそれが絶対的に良いものだと信じてるけれども、 実際にはあくまでも「馬鹿があまりいないこと」 というのを前提として成り立ってるので、 馬鹿が増えたら「もう民主主義では駄目だ」ということになる。 ようするに、 「子供というのは判断力がまだ弱いから、大人によって管理されるべきであり、 結果、子供の自由は制限されるべきものである」という理屈と同じ。 自由を守りたいのならば、そこはみんな自覚しといたほうがいいね。

閑話休題、まあなんだかんだ言っても、何が情けないって、一番情けないのは 「犬がかわいそう」で済まない大人がいるってことだな。 話が最初に戻るけども。

詳細は この方の日記の 9/9 を どぞー

平成15年9月14日(日曜日)

土曜

5 人で福袋 DVD 鑑賞会@ごうちゃ宅。結局宿泊。

日曜

辞去してから 4 人で何故か箱根。マジスパ経由で帰宅。

平成15年9月15日(月曜日)

敬老の日=尊敬に値する老人を敬う日

夕方。秋葉に行っていろいろ見たり買ったり。

汝の右頬を叩かれたら、相手の左頬を叩こう

命を大切に 。 矛盾というか、欺瞞ではありますな。 そこは私が半ば意図的に無視した部分ではあります --- 「万人に直感的でなかったとしても」というフレーズあたりに 込められた気持ちをお察しください。

蚊を殺してよいけど、犬を殺したら悪いということの理由について (あるいは、前者をウィルス、後者を人間に置き換えてもよいぞ)、 私は(それを少なくとも客観的に行うことが無理なことがわかってるから) 最初から説明しようとも思わないし、 そこは多分に主観による程度問題に過ぎないとは思います。 まあ、日本だって公の機関(保健所)が犬を殺しているという事実はあるわけで (あるいは死刑や戦争で人は殺されているし)。

ただ、逆に言えば程度問題であるからこそ、 「命を大切に」という原則が完全に死んでしまってるわけでもない。 欺瞞に満ちているからそんな原則は無視していいんだ、とか、 保健所が殺してるから私も犬を殺していいんだ、 という考え方は成熟したものではないですよね。 一方で、「命を大切に」というのがそのように欺瞞に満ちた言葉だということを 理解することなしに、無邪気にそれを鵜呑みにするのもそれはそれで 成熟しているとは言えないと思うけど。 わたしゃ宗教のたぐいは何も信仰してないのでもちろん仏教徒ではないけど、 仏教で言うところの「業を背負う」というのは、 きっとその欺瞞を消化するということに他ならないのでしょうな。

元の話に戻せば、結局のところ、そういう欺瞞を消化しないで それを権利のせいにするという未熟さが情けないし恐ろしいわけですね。 それも、私よりふた回りくらい上の人間だからのう。

メモ

買うもの: CR2032 ボタン電池 + 電池ボックス

さようなら

ま、/.J だしな 。 編集者どもがスラッシュドット(本家)の「崇高な\」理念を 理解してなくても仕方がない。

消せるものは全部消させてもらった。もう読むことも書くこともないでしょう。 さようなら /.J。

平成15年9月16日(火曜日)

ねむいにゃー。

地震対策キターーーーーー!!

少なくとも、モルタルボードの天井と棚の間に突っ張り棒を入れても、 強度的に無意味に近い行為である上に(時間稼ぎ程度の意味はあるが……)、 (ネジとかで固定できない以上)その突っ張り棒自体が凶器になりかねないと 思うぞ。スチール製の頑丈な突っ張り棒は、当たったら痛いだろうなぁ。

ヘルメットと軍手は……まあいいか。 今買わずに来週買えば、もっと安くなると思うけど。

完全に思いつきで無計画。経営と同じ(ぉぃ。

bitcount

9/11 。 櫛抜き。

8 bit の場合に図にするとこんな感じ:

ボックスの幅が 2 倍のところは 2bit 幅、 4 倍のところは 4bit 幅を表わします。 ここで確認すべきことは次のとおり:

  1. 各部分演算がオーバーフローしてないと仮定した場合に Z が bit 0..7 の和になってること → 自明
  2. すべての部分演算がオーバーフローしていないこと → これは「2 つの n bit 整数の和は高々 n+1 bit の整数」 であることから明らか(X と Y は 3bit で足りるし Z は 4bit で足りるんだけど、図は便宜上 2^n にしてある --- あたりまえだけど、 n 段めの和の結果は各 n+1 bit あれば本当は足りる)。
一般に、n bit 整数のビットカウントを求めるには、 上のようなたたみ込みを log2(n) 回やればよい。

この手の櫛抜きは、ベクトル手抜き演算方面でもいくつか応用がありまするな。

コード

カトゆーさんとこから こういうページ

Rumbling hearts は、ランブリングハァハァカラオケ版(注)を聴くかぎり、 以下のほうが近いはず:


(注)ランブリングハァハァ --- ランブリングハートの yar-3b カバーバージョン。 みこみこナース仮歌版に先んじること 2 年、 ボイスチェンジャーをエロゲソングに導入した金字塔(ウソ)。 カラオケ版は俺のコピーバージョン。 ちょっと聴いた感じでは本物と区別がつかないが、 並べて聴けば分かる程度には細かいところが違う。 一番大きな違いは、レゾナンスを効かせたアルペジエーターの音を 入れてないことだが、もしかしたらコードも微妙な味つけをしたかもしれないけど 覚えてない。

平成15年9月17日(水曜日)

陰謀

忘れてやれよ :D

平成15年9月18日(木曜日)

昨日

しーぽん。来週しーぽんが生きてたら駄作認定(ぉ

今日

こういうの を書いてみた。

今週のチャンピオン

今のチャンピオンには馴染みません。……昔からか(ぉ

ラーメン(2)。G との闘争。

ぱんつはいてない姫。父上萌え。

名無しさん。津田島さん萌え。

萌え遊戯王。萌え。

フェイスガード(2)。来週からはこれが×になります。

×。ある意味死んでからもイジメられる義介。

平成15年9月20日(土曜日)

昨日

しゃぶった。

今日

読書とかいろいろ。

夜中

日本が世界に誇る世紀の「と OS(と表現する以外に表現しようがない)」 であるところの OSASK の話題で盛り上がる。

んー、まあいいんじゃないですかね。人畜無害だし。 税金がもったいないけど。

延期

キターーーー!!!

gcc3.3.1

スイッチした。

うちのマシンで 2.95.x 時代に 2 時間ちょうどだった make release が、 2 時間 40 分かかるようになった。さもありなん。 次回は /usr/bin/gcc が 3.3.1 になるから tools のコンパイルに余計時間がかかるようになると推測。

UNIX v6

眺めてみたが、すごいなぁ。カーネルがたった 1 万行だし。

struct buf について知りたかったのだが、

struct buf
{
        int     b_flags;                /* see defines below */
        struct  buf *b_forw;            /* headed by devtab of b_dev */
        struct  buf *b_back;            /*  "  */
        struct  buf *av_forw;           /* position on free list, */
        struct  buf *av_back;           /*     if not BUSY*/
        int     b_dev;                  /* major+minor device name */
        int     b_wcount;               /* transfer count (usu. words) */
        char    *b_addr;                /* low order core address */
        char    *b_xmem;                /* high order core address */
        char    *b_blkno;               /* block # on device */
        char    b_error;                /* returned after I/O */
        char    *b_resid;               /* words not transferred after error */
} buf[NBUF];
なんて感じで、最後の行で目が点になりますな。 ちなみに NBUF は 15 らしく、なかなかいい時代ですな。

いまの NetBSD の struct buf は、 もはやバッファキャッシュエントリだけのものでもないのに いまだにバッファキャッシュエントリとしての構造と 切り離せてないのがアレといえばアレですわな:

struct buf {
        LIST_ENTRY(buf) b_hash;         /* Hash chain. */
        LIST_ENTRY(buf) b_vnbufs;       /* Buffer's associated vnode. */
        TAILQ_ENTRY(buf) b_freelist;    /* Free list position if not active. */
        TAILQ_ENTRY(buf) b_actq;        /* Device driver queue when active. */
        struct  proc *b_proc;           /* Associated proc if B_PHYS set. */
        volatile long   b_flags;        /* B_* flags. */
        struct simplelock b_interlock;  /* Lock for b_flags changes */
        int     b_error;                /* Errno value. */
        long    b_bufsize;              /* Allocated buffer size. */
        long    b_bcount;               /* Valid bytes in buffer. */
        long    b_resid;                /* Remaining I/O. */
        dev_t   b_dev;                  /* Device associated with buffer. */
        struct {
                caddr_t b_addr;         /* Memory, superblocks, indirect etc. */
        } b_un;
        void    *b_saveaddr;            /* Original b_addr for physio. */
        daddr_t b_lblkno;               /* Logical block number. */
        daddr_t b_blkno;                /* Underlying physical block number
                                           (partition relative) */
        daddr_t b_rawblkno;             /* Raw underlying physical block
                                           number (not partition relative) */
                                        /* Function to call upon completion. */
        void    (*b_iodone) __P((struct buf *));
        struct  vnode *b_vp;            /* File vnode. */
        void    *b_private;             /* Private data for owner */
        off_t   b_dcookie;              /* Offset cookie if dir block */
        struct  workhead b_dep;         /* List of filesystem dependencies. */
};
たとえば UBC 使ってても、 ディスクドライバの strategy にはあいかわらず struct buf を渡さんといかんので、 genfs の getpages では次のようにでっちあげてる:
        s = splbio();
        mbp = pool_get(&bufpool, PR_WAITOK);
        splx(s);
        BUF_INIT(mbp);
        mbp->b_bufsize = totalbytes;
        mbp->b_data = (void *)kva;
        mbp->b_resid = mbp->b_bcount = bytes;
        mbp->b_flags = B_BUSY|B_READ| (async ? B_CALL|B_ASYNC : 0);
        mbp->b_iodone = (async ? uvm_aio_biodone : 0);
        mbp->b_vp = vp;
この mbp は、条件があえば VOP_STRATEGY() の引数として使われる。 b_hash とかは全然使われてない。バッファキャッシュエントリではないのだから 当たり前だ。 getblk() 相当のことは代わりに ubc_alloc() あたりが適宜なんとかしてくれる。

聞きかじった話によれば、この b_ ってのは当時の C コンパイラが 構造体のフィールド名をグローバルスコープとして扱ってた名残りらしいですな。