rerofumiのつぶやき

メインマシンを Windows8 にしてから久しく。
時たま動かなかったり挙動が怪しいアプリもありつつ、楽しく使い込んでいる日々。

しかし、Windows8 には Vista と 7 であった「デスクトップガジェット」なる小物の仕組みが無くなっているのだよな。これだけが不満。
私は、今 PC がどれだけ仕事をしているのか見えていて欲しい人なので、いわゆる CPUメーターの類のガジェットを常用していた。けど、Windows8 ではこれがかっぽり欠落してしまっている。
しょうが無いからタスクマネージャを開いてパフォーマンスビューを眺めていたりするけれどもなんか違う。

やっぱりデスクトップに CPUメーター欲しいよ、CPUメーター。
しかしま、大したアプリではないからこれくらいの小物自作するか。ということで、初めて触る WPF と XAML を叩いてそれっぽいのを作っている。
デスクトップアプリに回帰とか単なる昔の懐かしみなのかもしれん。

一応CPUの数でバーの数が変わる。左が 6コア12スレッドで、右が 2コア4スレッド。

取り敢えず動いた所のプレビュー版。
Download: fmCpuWatch.zip
.NET Framework 4.0 以上が必要。
Win8 は .NET Framework 4.5 なので何も気にせず動くはず。

取り敢えず、終了時に座標をレジストリ記録とかで覚えて毎回同じ場所に表示させたい。
それくらいはやる予定。

VOICEROIDという紛らわしい愛称のAI-Talkエンジン使用文章読み上げソフト、月読ショウタ/アイが発売となった。
かつては種類があった文章読み上げソフトもすっかり数が減り、動画やコンテンツ作成といったホビー用といった需要が高まりつつある様に見えるなか選択子が妙に少ないといった世界になっている。AquesTalkの独壇場にもなるわけだ。

さてそんな前振りはともかく、月読兄妹が届いたので早速インストールをした。ところが「DBが存在しません」と出て利用ができない状態となる。
まあ、それだけでなんとなく原因がわかったのでトラブルシュート。これは 64bit の Windows7/Vista 環境で起こる現象。
結論としては、インストール後 C:/Program Files (x86)/AHS/Voiceroid/dbpath.dat にインストールされる設定ファイルを編集すれば良い。
上記のパスを見ればわかるように、64bit Windows において 32bit アプリケーションをインストールすると C:/Program Files (x86)/ というパスに入れられる。C:/Program Files/ は64bit アプリケーションのパスなので。でまあ、VOICEROID は C:/Program Files/ にインストールされたと思い込んでいて、音声データベースの設定パスも C:/Program Files/ になっているのですな。
なので dbpath.dat を編集して C:/Program Files (x86)/ に変更すれば解決。無事利用できる。

そもそもで、VistaからDBの様なプログラムそのものではなく32/64bitに依存しないデータ類については C:/ProgramData/ フォルダにインストールすることが推奨されることになっているはずである。インストーラが最初からここに、DBをインストールするようになっていれば良いだけの話だと思う。でもそうなっていないのは XP と Vista/7 でインストーラーの動作を分けなければいけないからでしょうな。
でもそれをやらずして Windows7 compatibility が語れるもんなのかね。

と、ここまで書いて気がついたのだけれども、32bit Windows しか動作保証していないのねこれ。
よく見たら VOCALOID2 も 64bit Windows を保障してないや。普通に使えていたから気にしていなかった。
もっとも VOCALOID2 も同じ問題があるはずで、インストール時に標準インストールのままだと VOCALOID DB が C:/Program Files (x86)/ にインストールされてしまい苦労するはず。私は、DB は ProgramData に入るべきでしょとカスタムインストールを選んで DB インストール先を ProgramData にしていたので最初から問題なかったのですが。
ま、よするにちょいと気をつければ VOICEROID も VOCALOID も 64bit Windows で使えますよ、と。

インプライス(元Borland)が Linux版 Delphi の開発技術者を求めているらしい。
Windows上での開発環境では Delphi を愛用していてそれくらいしか持っていない
私としてはちょっとうれしいお話ではある。

各種IDE(統合開発環境)がいくつかリリースされつつあり、GTK+＆Glideの組み合わ
せでウィンドウアプリのプロトタイピンク化が促進されつつある。これで Linux上
でのRAD(Rapid Apprication Develop)が整って来たと言うところか。ここに Delphi
が飛込めばその方向性はさらに高まるに違いない。
とか色々考えてわくわくしている次第。
もっとも、Windows 上ではとうに実現している世界なのは言うまでもないわけだけど。

それにしても GNU OpenStep Project ってのもあったっけなあとふとふりかえる。
私のRADへのあこがれは総て大学で見つけた黒い箱、NEXT-CUBE に触れたところから
始まっているもので。
いまではめずらしいかも知れないNEXT-CUBE の写真(仲間が卒業後大学へ遊びに行った
際写真撮影してきたもの)→http://www.kiwi-us.com/~ohta/NeXT/index.htm

なにやら「WinNT vs Linux」で盛り上がっているようだ。
どこぞのMicrosoftの息がかかったところが「NTはLinuxの4倍早い」とか言ったのに
対してLinux陣営が「そんなことはない」と鼻息を荒げているとか。
んで、立ち会いのもと再度リターンマッチをしたらやっぱりNTの方が2倍ほど早かっ
たとかいう。
んで、このベンチマークテスト、Webサーバーファイルサーバーの応答能力を試して
いるとか。つまり、ファイル処理時間とネットワーク能力にかかってくるわけだ。
ふと思うと Linux ってそのへん弱かったんでなかったけか？
私は Linux 1.0.* のころからいじって遊んでいるんだけど、昔からファイル周りは
馬鹿早いってわけじゃなかったと思う。その昔ファイルサービスと言えば NFS だっ
たんだが(今でもそうだけど)、Linux の NFS は他のUNIX系OSにくらべかなり遅い事
で有名でそのへんカーネルレベルで早くするとかいって改良していった経緯を覚えて
いる。だから、今回のベンチマーク結果を聞いても「あ、そうかもね」とか思ったり
して。
しかもファイルサーバーはsambaで試しているとか。純正の WindowsFileService に
勝負を挑んでいるわけだからなんとなく部が悪そう。

今回の件で RedHat のおじさんはすっかり熱くなっているようだけれども、Linux
コミュニティーの(深い)人はそんなに気にしていないようで。
「Linux にはベンチマークより大切なものがいっぱい詰まっている」
という言葉には至極納得。