「白いクスリ」騒動に思うこと。

 どうせ色々書いたところでウザいだけなので、ちょっとだけ。

 初音ミク(とその仲間たち)が、単なる音源とか楽器とかにしか見えない人は、つまらない生き方しているよな、と。
 楽器や音源なんだから自由がどうの、とか言い出すのは、なんというか、残念な発想だな、と。

 個人的にはコレ、どうせなら「がくっぽいど」or「Megupoid」でやって欲しかったな、というのはやや黒過ぎですかね。
 ミク(or クリプトン扱のVocaloid )でやったら削除要請が飛んでくるのはデッドボールPの事例から割と想像し易い状況だったと思うし、2度目だから新鮮味無いし。

 これが「×××っぽいど」となると、音源ネタ的には声優より遥かに扱い辛いブツなのだが、一方でクリプトンより遥かにニコ動寄りで、NMMなんてモノまで提供している株式会社インターネットの場合、どういう反応するのかな、と思って。

 ♯あと中のアレを誰か黙らせろっての。

以下、8/18追記:

 ちゃんとがくぽでもやってくれたのね>投稿主。で、ニコ動経由で警告ですか。ふ~ん。
 ・・・で、その「ニコ動経由の警告」ってスキーム、以前からあったのかな?
 インターネット(会社ね)がニコ動と仲が良いから出来ちゃった、なんて話でなけれぱ良いのだが。

 あと、開発元のYAMAHAを巻き込んだVocaloidの利用規約がどうのというまた面倒な話に火が付いてしまったようで。
 ったく、相変わらず迷惑なことしかしないよ>中のアレ。

Share

OS入替が見えてきたらやること。

 当方も含めて、XP→Vistaを見送ったという方は世間でもそう少なくはないようで。

 とはいっても、当方元々64bit環境マンセー、な人種。
 XP 64bitのドライバの無さに挫折して暫く・・・Vistaのお陰で漸く64bitドライバも「普通に使う分には」問題無いレベルに充実してきたこともあり、当方もWindows 7への乗り換えを割と本気で考えている一人だったり。

 なので、各種アプリ・ツールの動作確認するため、MSDN公開直後に実験検証機へWindows7インストール、なんてやってしまったワケなのだけど。
 chkdsk周りのトンでもないバグが出てきた一方で、個人的には一番心配していた某ツール(システムに近いトコロでかなりトリッキーな動作をするブツ)があっさりと動いてしまったので、「その気」は急ブレーキ後やや再加速中といったところ。

 ♯つまり、正確には「Windows 7に移行したい」ではなく「まともに使える64bit Windows環境に移行したい」なのよね。
 7が出てしまった以上、今からVista x64ってのはどうかと思うし、さすがにこれだけ恥ずかしいネタはそう遠くないうちに修正されるだろ・・・。

 そこで気になるのが、既にゴチャゴチャになった数々のアプリ類。
 丁度良いタイミングなので整理しないと。既にHDDの肥やしにしかなってないモノもあるし。

 #具体的にはVistaですら対応せずに開発終了してしまったツールとか、以前はフル活用していたものの現在は見向きもしなくなったツールとか、同じ理由でバージョンアップをしてない故に手元のVerではVistaですらロクに動かないモノとか。

 ということで、現在一番悩ましいのはメール。現在当方はgmailをメインに使っているのだが、プロバイダのメールボックスも使っているし、古いメールも捨てられない。
 しかも、古いメールの中にはパスワード通知類もあったりして、この辺りどうしようかと。

 取り敢えず、旧メール類は圧縮して転がしておくことにして、コピーをMailStore Home辺りに放り込んでおけば検索出来るかなあ・・・とか思いつつ。

 ・・・つーか、XPから7に飛ぼうとしている皆さん、アプリ周辺はどうする気なんだろ。
 当方のように「使えるからい~や」と古めの環境を引っ張ってきていて、いざ移行となると実はかなり面倒、なんて人、少なくはないと思うんだけどなぁ。

Share

Windows7 x86版「は」省メモリ。

 えっと、前回の検証のおまけ。

 Aero無効のx86版、起動直後には412MBしかメモリ喰ってなかった。
 x64版ではAero無効にしても、1.06GB喰ってる。

 ・・・あの、いくらいっぱいメモリ積めるからって、何か間違ってないかい?>下逸クン。

 つ~か、この辺りの話、そこらのニュース系サイトにはさっぱり出てないのな。
 メモリ使用量が減った、軽くなった、なんて騒いでる連中は、要するにx86版しか使ってない、と。所詮その程度か。

 x86でいいなら、素直にXP使っていればいいやん。
 別に今更変える必要も価値もないと思うが?

Share

Windows7 chkdsk /r の挙動について。

 ちょっと実験してみて分かったこと。

・対象ドライブにあるファイルの大きさに応じてメモリを喰い尽くす。
 但し、システム側からメモリ割当を拒否されたりすると、そこで占有メモリ膨張は止まる。

・x86版では32bitアプリの制限上(に引っ掛かっているようにしか見えない)、約1.75GBでこの占有メモリ膨張が強制的に停止する。逆に言うと、そこまでは膨らみ続ける。

・x64版では64bitアプリはメモリをもっと喰えるので、4GBだろうが8GBだろうが占有メモリは膨張し、先にシステム側がメモリ不足になって「メモリ喰い過ぎ」と怒られて、割当拒否される。

 ・・・設計ミスって言うんじゃないの、コレって。
 何でchkdskに物理メモリ喰い尽くされないといけないのよ。

 こんな挙動されたら、x64版で巨大ファイル置かれたらどれだけメモリ積んでも足りないじゃないの。
 というか、x86版の方も、これはこれできちっとチェック出来てるのか心配になるし。

 ちなみに、青画面を見てみようと、VMwareと32bit版Windows7を使ってイロイロしてみたのだが、残念ながら青画面は見られず。
 その前にシステムに「メモリ喰い過ぎ」って怒られて、蹴られてしまいましたとさ。

 本日のおまけ画像は、テスト準備中のスクリーンショット。
 取り敢えず物理メモリ4GB割当て、空っぽの950GBドライブをchkdsk /r して、コケてない。
 あと、VMware Workstation 6.5はWindows7 x64に普通にインストール出来るし、GuestでWindows 7 x86は普通に動きますよ、ということで。

Win7 on VMWare on Win7

Share

Windows7 ・・・これは酷い。

 Windows 7 RTM版に「深刻なバグ」の指摘
 >http://www.computerworld.jp/topics/win7/157689.html

  >クラッシュが発生するのは2基以上のハードディスクを搭載したPCで、「CHKDSK [drive letter:] /r」コマンドを実行した場合だという。
 >コマンドがメモリを使い果たしてPCをクラッシュさせ、ブルー・スクリーンになるという現象

 コレ、x64のRTM版でも出ますな。

 手元では20回程やってみたがクラッシュ「は」一度もナシ。
 その前に「メモリ喰い過ぎだからchkdsk落とすぞ」と言われます。
 但し、1/3ぐらいの確率でDWMが落っこちてAeroが無効に。

 #DWMって落ち易いの?

 ・・・まあ取り敢えず、これかなりアレですな。
 致命的・・・ではない、とは言えないと思うがなあ。

 ちなみに、ドライバ云々という話はあるかも。

 取り敢えず手元環境の初期導入ドライバは、動いてはいるものの完成度は「ん?」みたいなトコロがぽろぽろと。
 例えばMS純正のGeForce用VGAドライバ、EDID読み込み周りの挙動が明らかにヘン。このせいで、ディスプレイの解像度設定が吹っ飛んだり、マルチディスプレイの後から検出に必ず失敗したり、なんていう症状が出たりしているので。

 とはいえこの環境、検証用ということもあってSATA I/Fは「Classic IDE互換」設定なのだが。
 汎用IDEドライバの修正はMSにやってもらわないと、なぁ。

 以下、笑っちゃうような参照画像。本当はもっとメモリ喰ったトコロを捕りたかったのだが、PrintScreen連打してもこれが限界(最後に撮れた画像)でした、はい。
 にしてもこれだけメモリ喰えるってことは、x64版chkdskはきちんと64bitアプリになってるのね。
 もっとメモリ積めばもっと行けるか?・・・4GBモジュールは¥が高いから当方にはムリだけど、ね。

Win7 chkdsk Bug screenshot

Share