Last-modified: Tue, 28 Sep 1999 17:32:19 JST
[static,style:furuta,jconv:jcode,cache:on]
powered by tds-Tomsoft Diary System 1.01-beta0
散財が止まらない。 マシンルーム向けに 12 インチ TFT 液晶モニタがとても欲しくなる。 (今まではモニタ無しで使っていた) 今回は幸さん同伴で遠征する。
土日のアキバ、 特に日通の裏方面がこんなに人で溢れるようになったのは そう昔のことではないと思う。 しかしだ、 この混雑の中で歩き煙草は本当に迷惑なので止めて欲しい。 煙はもちろんのこと、やけどの危険性すら認識できていない やつの数が多すぎる。 私も元煙草吸いだし、 煙が苦手な人に対してどういう効果があるのか良くわかるようになったのは 結婚後だけどもねぇ… もう少しジョーシキというか、他人にかかる迷惑を考えるべきだと思うっす。
とある game 屋さんに突入。 幸さんと一緒に地下18禁コーナーに潜入。 彼女は他の客に「ジロリ」と睨まれたと憤概している。 「18禁であって女性禁制ではないのだから、私がいったて問題ないじゃないのヨー」 いや、ごもっともです。私ゃ苦笑するしかないですが。:-) ここで某 game を購入。Windows 上の game はこれがはじめてだったりする。
昨日買った某 game で一日中サル化する。 某chat の morning call について理解する。あれは目覚し時計だったのか。
1st play。 最初、単なる学園ギャルゲーだったのが、 後半突然学園さすぺんすものになってしまった。 特に舞踊会だの生徒会だの、学園さすぺんすものの王道だー。(ホントか?) しかも全然 18 禁になってないしー、 話の展開に全然追い付けなかったしー。 これって、bad ending なんだろうか? よくわからないうちに終ってしまったという感じ。
2nd play。 いとこ。 話は通ったけど、 何だか話を終結させるために、 無理矢理不幸をこしらえてる気がする。 幸さん曰く「なーんだ、18 禁と言うからもっと凄いのを期待したのに (こらこら)なーんだ」だそうです。 そりゃまーそーゆーもんでしょう。
とりあえず、Astec-X じゅーよー。
某 chat でかなりの反響なので、今までの議論について動くことにする。
とりあえず、 専用サーバハウジング全集
あー、まだ抜けがある気がする。つっこみ歓迎。
ML を作成してみたので、該当者(自分はきっと該当者だと思う人を含む) は召喚されて下さい。
majordomo@srapc132.sra.co.jp
宛に
subscribe pc-housing
を送って下さい。 closed subscribe なので、手動 approve まで少々時間がかかります。
全体として closed な設定にしてあります。 特に archive は取ってありません。
3rd play は、肉まん/まんが/鈴。 ああ、これは「まごころを君に」 *1ですね。 主人公に sync さえできれば萌壊できるつくりだと思います。 たぶん、残念ながら私は最後まで sync できませんでしたが。 どちらかと言うといちご{ジャム,パフェ,ムース} の方に感情移入して しまってます。 しかも時間がたってから効いてきている (^^; 脳内音楽がすっかり切り替わっているし。
しかし、 皆さん*2、私ゃわざわざプレイした人だけにしかわからないように書いてるのに、 (どこが?) そんなにあからさまに 固有名詞を出さないで欲しいなぁ…(笑) とりあえず、japan.videogames.key と fj.rec.games.video.characters は 5th play 終了時まで封印する。
うむ、 商業上得策なのですか。 この手の流通が全くわからないのですが、 この種の game はそっちの方に市場が形成されてしまっているということなの でしょうかね? しかし、最初からコンシュマー機向けに開発したって、 十分売れるような気もするのですが、これは素人考えなのでしょうね…
自分でも ダメ化が進行しているのがよくわかったりします。 …方針転換と言えばそう言えなくもないです。 うーむ、
のどれだろう?
ちなみに、私も motoyuki さんに同意見。 こんなにエソカイがダメになったのは、結構最近のことだと思います。 いや、ダメって悪い意味でいってる訳ではないので、為念。
あの人もはまった高倉健みたいでいいかも。:-)
うーむ、 18禁シールは「18歳未満はだめ」という意味ではなくて「18禁な内容を含むことを保証します」 という意味だったのか。
ところで、あの人のテーマとあのシーンの曲と同じだったんですね。 ということは、あれはあれなのか。納得。
しかし、固有名詞を避けると指示代名詞ばかりになりますな。訳わからん。 一応ネタバレ対応でもあるのではありますが。
どうも 450A 動作させて seti@home でも走らせようなら 良く熱死して使いものにならないようなので、 300A に戻してロードテスト中。 ケースの蓋をするとかなり熱がこもって、 開放時と比べて5℃から10℃ほど高くなるようなので、 注意が要るみたい。 ケースに付けるファンが欲しくなる。 これを「散財アバランチ効果」といいます。 *1
そうそう、 BP-6 のベースクロック設定ですが、1MHz 刻みがうまく設定できないというのは大嘘でした。 単に BIOS の設定がうまくいってなかっただけでした。 clock error の detection (だったかな?)を off にしておく必要があります。 というわけで、いろいろ ハマる調整してみることにします。
チップの温度表示等をしてくれるプログラム xmbmonは users-jp と tech-jp あたりを xmbmon で検索。 takawata さんによる lm ドライバ。
お二人ともがんばってください。
4th play はアイスクリーム。 どんな変化球かと思っていたら、思いっきりストレートだった。………。
しかもど真中。きてるみたい。すごくダメかも。
いや最近話題のというか、私が Web 日記系から影響を受けたのって、 別にかの game に限らず、
あたりかなぁ。いえね、Web 日記を読みはじめたのは、 塩崎さん が とこちゃんの宣伝をシグネチャーに入れて users-jp あたりに投稿したのが きっかけだったりします。
ええと、
Subject: Replacement for grep(1) (part 2)
で、
CC: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org
で、おとといぐらいから出火炎上の模様。そろそろ鎮火したかな?
Matt Dillon の御乱心というか、 彼は保証問題と運用問題をごっちゃにしているに 過ぎないように見えるんだけど、量が多くて読みきれない。
とりあえずの理解によると、 Solaris2 だと、mmap(2) で MAP_NONRESERVE を指定した時だけ over-commitment が発生し、 指定しないと swap space の確保を行なう。 (もちろん、writable MAP_PRIVATE の時だけ) malloc(3) を mmap(2) MAP_NONRESERVE|MAP_PRIVATE で実装してやれば、 実質的に 4.4BSD のような over-commitment なシステムと同等。 (いや、stack の扱いが違う?)
で over-commintment 問題への対応では、
あたりが議論に出ていた模様。 うむ、swap accounting はそんなに実装が難しいものなのか。
だいたい、Chris Torek の原論文「Device Configuration in 4.4BSD」では、 説明のための仮想マシン SuperSnail-1 からして
device cpu at mainbus
だったりするぞぅ。 彼は「This will be important for future multiprocessor support.」と ちゃんと書いてたりするぞぅ。
栞シナリオを途中からやりなおす。あう、泣けます。
某かっちゃんが出没する。 かっちゃんは私が既婚であることを4年と2ヶ月ほど知らなかったらしい。 …かなり驚き。
かっちゃんもかなりショックを受けていた模様である。 ライバルは soda ぽん*1だそうな。
over commitmentに関して soda ぽんよりつっこみ。召喚成功。
まず、MAP_NONRESERVE | MAP_PRIVATE で mmap(2) による malloc(3) を実装 しても、その malloc(3) を使いさえしなければ backing store が予約される わけで、swap が不足するといやおうなしに SIGKILL される 4.4BSD と同等というのはかなり変、ということ。 あと、4.4BSD では SIGKILL だけども、 Solaris では SIGSERGV で signalstack(2) で確保した代替スタックで 遺書を書く暇があるとか、ずいぶん違う。
stack に関しては、overcommit モデルじゃないと stack limit サイズ分 予約することになるので、swap 一杯になってやっとれんという 論点があるらしいが、Solaris はもちろん、そんなことはしていない。 stack の伸びに応じて動的に確保されるのは確かなようだけど、 stack の場合は overcommit の場合と違って memory fault 部分だけが予約される訳ではなくて、 中間部分も予約されるので overcommit とは言わない、らしい。
どうも allocate(割り当て) と reserve(予約)の区別がついとらんから いまいち理解できん。あと、SIGDANGER は何をやるものかも よく把握できてないことが判明した。 だから論評を書いてないんですが。(^^;
幸さんによると、 連載当時の花ゆめにはいろいろアヤしい付録がついていたそうで、 その付録の一つにアムカの巾着 *1があって愛用していたのだが、今はどこにあるかよくわからないらしい。
300A 状態で動作させるが、 止ってしまうことがあることが判明。 症状としてはいずれも、あらゆる割り込みが死んでいる模様。 ping、CAPS LOCK に反応しないばかりか、電源 switch も効かない。 さすがに reset は有効だけども。
どうも熱だけが問題なのではなくて、 FreeBSD の SMP 対応に問題があるのだろうか? 飯島さんの主張は正しい。 いろいろ思案してみた結果、 こちらを作業マシンにして現在の作業マシンのマザーボードを サーバーにすることにする。
xmbmon を入手して動作させてみる。 とりあえず /dev/io で動作させたら問題なく動作した。 これで動作中の温度がわかる。
ケースをしてあると、CPU だけでなく(どこで計測しているかわからないが) マザーボードの温度もかなり高いようす。 ケース用ファンを池袋まで買いにいくことにする。 静音なものを買ったからか、あんまり効いてないような気もする。 温度にして 2 〜 3 ℃程度下ってはいるようだ。
再度栞シナリオ。(苦笑)
Astec-X + xwd + gimp で「アイスクリームを頬張る栞さん」の bitmap を こさえたのは内緒。作業中の BGM は「夢の跡」
「そんなことをする人は、嫌いですー」
あるプログラムとある仕様と、 プログラムがその仕様を満すという証明を与えて その証明が正しいかどうかを判断する問題は P に属します。 証明の個数はたかだか可算個なので、 証明を「試行」としてパラレルに計算を実行すれば、 プログラムがある仕様を満していればどれかの試行に於て 多項式時間内でその証明が確認できます。 なので、プログラムがある仕様を満すかどうかという問題は NP に属します。
…本当かな。かなり自信がない。
あゆシナリオ終了。CG 95%
話が止ってしまったので、何とかせんとなあと思いつつ。
NetBSD 由来から OpenUSBDI に書換えなんですか? ヒジョーに気になるんですが…
A の B、4 人の内 3 人を確認 :-)
コンビニで「E-m@il なんたら」という雑誌を発見。 ぱらぱらとめくっていたら「シグネチャー作成術」という記事で users-jp や fj.os.bsd.freebsd 方面で有名な方のシグネチャーを発見。 シグネチャー中の所属はモザイクがかけられているのに、 名前の部分はモザイクがかかってないから、 名前を知っている人なら一発でわかる。 しかも、とっても覚えやすい名前の人だったり…
どういう経路って、(Jul 18 01:35)[motoyuki] だったりします。 で、4 人目の人から 召集令状メールがきたりして。なるほど、そーゆー面子だったのですね。
あら、これが佐祐理エンドか。 んで、直前のセーブからやりなおして、舞 CG を回収する。 これで全部 CG が埋まっているのに、99% と言われるのは何故?
は同じ曲(と言いきってしまうとちょっと語弊があるけど)ですね。
ううむ。最近の動向が全然わからないので、 OpenUSBDIでも読んで出直してきます。
MIDIの方なんですけど、PCM Audio が isochronous なのはよく判るんですが、 MIDI も isochronous なんでしょうか? これ信頼性がないとすごくイヤなんですけどね。
落された人からの教訓ではなくて、「落ちた人からの教訓」の間違いではありませんか? :-p
んで、はやまる必要なんか全然ないのですが、 日記というか他人が読む文章に「 時代から取り残されて」云々を書くということは、 「どなたか背中を押して下さい」と言っているの同じだと思います。:-p たぶん、たかだかゲームにはまったぐらいで院試に落ちるようならば、 ゲームにはまってなくても結果は似たようなものでしょう。
あ、私も「背中を押してくれー」って日記中でずいぶん書いてますね。 で、背中を押された結果自分できちんと責任が取れれば、それで良いのです。
ところで、「ダーメダメダメダメにんげーん、にんげーん、にんげーん♪」 って歌詞の曲のタイトル/シンガーを御存じのかたは教えてください。
allocate と reserve の違いについて、soda ぽんより。
allocate(割り当て) は実際に swap スペースを割り当てることで、 swap 関連の構造体を設定する作業が発生する。 reserve(予約) はそうした設定をせずに変数の increment をするだけ。
そうすると over-commitment 対策は mmap(2) 時 (あるいは stack access 時)に allocate でなくて reserve で 全然構わないわけで、やはしどうして実装がそんなに難しいものなのか 理解できませんです。
あと SIGDANGER は swap の空きが一定量を切った場合に発生するものらしい。 SIGDANGER による遺書を書いてる間に殺される可能性があるから、 over-commitment モデルを問題視している「保証」という点から言えば 全く役に立たないわけだ。