メインメモリを 2GB に増設したので、RAMディスクを増量(188MB → 504MB)しても残り 1.5GB。WindowsXP で使うにはメモリ周りの余裕は十分にできた。また、色々と考えた末、あまりリスキーなところへは踏み込んでいなかったCドライブの削減も、もう一歩進めた。具体的には、

  • C:\WINDOWS\inf 以下のモデム用ドライバファイルをDドライブに作った退避用ディレクトリへ移動(約 30MB の削減)

  • C:\WINDOWS\Driver Cache\i386 以下のドライバキャッシュもDドライブの退避場所へ移動(約 80MB の削減)

  • dllcache (C:\WINDOWS\SYSTEM32\dllcache) の削除(キャッシュサイズをゼロに。約 270MB の削減)


これらは俗に言う“虎の巻”に載っていることなので珍しくも何ともないことだが、以前「システムの復元」を切ったことと併せ、何かあったら即リカバリーコースの危険性がより高まったことは言う間でもない。

が、反面これらの措置でCドライブは 380MB 削減された。Cドライブの残量が 1.21GB だったので、効果はかなり大きい。私的にはCドライブの空き容量は(何かあった時の為に)1GB くらいは空けておきたい。できれば 1.2GB あたりが目標。なので、今回空けた 380MB 分がまるまる使えることになる。

さらにDドライブもプロアトラスまでインストールしてもまだ 3GB 以上の空きがあるので、追加でソフトウェアをインストールすることとした。

…などとやっているうちに、いつしか動画編集や写真編集ソフト、Visual Studio などの開発用統合環境を除けば、一番最近に Windows をメインノートとして使っていた Lavie RX で使っていた環境と、ほとんど変わらなくなっていた。動作速度は多少遅いものの、十分実用的と言っていい。Atom プロセッサの5万円台廉価ノートで、ここまでできるとは、本当に驚いている。

メイリオフォント (C)

先のブラウザ比較の記事でも書いたが、メイリオフォントを導入した。日本語で小さなフォントサイズまで綺麗に表示されるのはコレくらいしかないから、ベストなフォントではないが、とりあえずこれで。

メイリオフォントは MS P ゴシックと比べてフォント幅が広く、また行間も空くので嫌っている向きも少なくなく、そのために MS P ゴシックと同じフォント幅、行間に改造する MeiryoKe もあって、それを使うことも考えたけれど、むしろ元々 MS Pゴシックの行間は狭すぎて見づらいので、メイリオをそのまま使っている。

Bullzip PDF Printer 5.0.0.609 (D)

フリーの PDF プリンタドライバ。普段印刷を全然しないものの、メールでの諸々やり取りで PDF 生成は必須。無料で使える PDF プリンタドライバはいくつもあって、今までデスクトップ機その他では別のものを使ってきたが、Cドライブにサイズの大きい .NET Framework 2.0 のインストールを要求するものだった。

そのため、.NET Framework 2.0 を入れずにそれなりの機能がある PDF プリンタドライバということで改めて探してみて見つかったのが、コレ。.NET Framework を追加要求はしないが、Ghostscript Lite 8.61 を入れる必要があるものの、Ghostscript Lite のサイズは 10MB 弱。本体が 12MB 強で、併せても 22MB 程度。これなら我慢できる。

機能的には日本語も問題なしなのは言う間でもなく、品質などの各種設定、パスワードや閲覧時制限などセキュリティ機能、透かし、既存 PDF への追加など、一通りの機能は揃っている。透かしで日本語を入れると文字化けするのだけが残念だが、あとは基本的な機能は網羅している。

何よりも宣伝やスパイウェア的なものが含まれてない。これは大きい。他の無料 PDF プリンタドライバでは宣伝が入ったりするものが多いが(それはそれで無料が故に止むを得ないとは思うが)、これは気持ち良く使える。ということで、他の Windows PC も PDF ドライバはコレに変更だな…

HWMonitor (D)

パソコン内部の温度センサ情報を取得・表示するソフト。別に入れなくても良いと思っていたが、Dドライブにまだ余裕があるのでインストールした。

MacBook Pro その他 CPU パワーに余裕のあるパソコンでは大抵、温度センサ監視(+ファンコントロール)ソフトを常駐させているのだが、CPU リソースに余裕のない EeePC では常駐させるつもりがなく、必要な時に起動して温度情報を見られれば良いので、これを選択。

CPU-Z (D)

CPU の詳細情報を取得するためのソフト。全く入れておく必要はなく、入れるつもりもなかったが、 HWMonitor と同じくDドライブに余裕があるので、一応インストールしておいた。EeePC の動作モードによって、CPU や FSB の動作状況がどう変わっているのか?というのも知りたかった。

実際 CPU-Z を起動した状態で、EeePC 付属の動作モード・コントロールソフト Super Hybrid Engine を変えて状態を見てみると、

  • High Performance Mode(AC駆動時のデフォルトモード)では FSB 133MHz で、CPU クロックはその6倍の 800MHz で駆動。EeePC 901 に搭載されている Atom プロセッサの公称クロック数が 1.6GHz だから、アイドル時には約半分の速度で稼働していることになる。そして負荷がかかると 1.6GHz まで跳ね上がる。このコントロールでバッテリ駆動時間を稼いでいるわけだが、こういうことは今の CPU では当然どれでも行われている。

  • 次に Power Save Mode(バッテリ駆動時のデフォルトモード)では、FSB が 100MHz に落ちる。よって、通常時の CPU クロックも 600MHz に落ち、負荷時でも 1.2GHz までクロックダウンされている。購入当初、バッテリー駆動で使っている時に反応が悪いなー、と思ったのは当然だったわけだ。FSB までクロックダウンされているのは結構動作速度に影響するが、バッテリの保ちにも利くのだろう。

  • 最後に Super Performance Mode。このモードでは FSB 140MHz となり、通常状態の CPU は 840MHz、負荷時には 1.68GHz まで上がる。FSB クロックを定格より上げての、純正オーバークロック状態になる。


Super Hybrid Engine でのモード変更は、上記の CPU 周りのクロック速度を変えるだけでなく、液晶の輝度その他も変わるのだが、CPU-Z で見てもバッテリ駆動時間を延ばすために色々とやっていることが判る。当然と言えば当然のことだが、実際に使っているとバッテリ駆動時でも必要なら High Performance Mode に変える必要があることが判ってくる。

Apache 2.2.9 (C)

説明不要のウェブサーバーソフト。軽さを考えて lighttpd とかも考えたが、他の環境と揃える意味もあって Apache をインストール。当初Dドライブにインストールしていたが、Cドライブに多少の余裕もできたし、サービス系のソフトを遅いDドライブにあまり入れたくないので、Cドライブへインストールし直した。サイズは 22MB 強。

当初は常駐するプロセスを削減したかったので、WindowsXP 起動時にサービスを起動せず、必要なときだけ Apache を起動するスタイルにしていたが、MacOS X 各パソコンは全て常時 Apache が起動している状態で使っているし、実際に Apache を起動しっぱなしにしても意識できるほど遅くなってなかったので、今ではシステム起動時から Apache も常時起動するようにし、他のマシン同様、ブラウザの初期表示ページは localhost となっている。

ただ、httpd.conf その他の設定でリソースを無駄に食わないように、最小限の環境になるようにはしている。そのあたりの利用環境に応じたカスタマイズは apache を使っているなら基本なので、特筆すべきものはなし。

PHP 5.2.6 (C)

公私ともども PHP で書いたウェブアプリはあるので、apache を入れるなら PHP も当然ということで。こちらも速度的なことを考えてCドライブへ。pear で追加モジュールを入れない状態で 30MB 強。

ただ、久しぶりに Windows の Apache + PHP 環境を使ったせいもあるが、PHP 5.2.6 と後述する PostgreSQL を組み合わせたら、動くべきウェブアプリが全く動かず焦った。原因は Windows 用 PHP 5.2.6 の PostgreSQL 用 DLL が腐っていて、元から使えない状態になっていることだった。

結局 PostgreSQL 用 DLL のみ、5.2.5 のものを引っ張ってきて使えているが、こんな大バグを何ヶ月も放置プレイしているところが、今イチ PHP が信用できないところでもあるんだよなぁ。便利なんだけど…

PostgreSQL 8.3.3 (C)

MySQL を使う人は多いだろうが、個人的にはずっと昔から PostgreSQL 派なので、PostgreSQL もインストールした。Dドライブで使うと、Random Write の遅さで実用的な速度が出ないので、本体もデーターベース領域もCドライブへ。初期状態では 56〜57MB を消費する。

それでも Core2Duo + HDD な環境と比べると待たされ感が強いが、数万件レベルまでならそれなりに使える。緊急時の開発環境としては、まぁ悪くない。というか、Atom 搭載廉価マシンでここまでできたら十分かな?と感じている。

後述の SQLite もそうだが、データーベースということで SSD の書き換え回数限界が気になるところだが、サーバーとして常用するわけでもなく、また開発環境としても緊急用でしかないので、そのあたりは特に気にしてない。当初はデーターベース領域を SDHC に置こうかと思ったが、SDHC はデジカメのデーターを取り込むために抜くこともあるし、まぁそこまでパワフルに使うこともないので、現在はCドライブに設定してある。

ただ、注意すべきはCドライブにデーターベース領域を作ってあると、データーベース内容によっては、あっという間に容量を消費していくこと。今時の大容量 HDD を使っていれば全く気にならないサイズでも、残り 1GB 少々でやりくりしている場合には注意が必要。

私もちょっと入れただけで、300MB くらい取っているので、さすがにDドライブに戻そうか?それとも SDHC へ?と悩んでいるところ…(Dドライブにしろ、SDHC にしろ、劇的に遅くなるのは目に見えているから難しい)

SQLite 3.6.1 (C/D)

これも説明不要の簡易 SQL データーベース。DLL 本体は Windows ディレクトリに入れるのでCドライブ、sqLite3 コマンドはDドライブへインストール。PostgreSQL 同様に速くはないが、元々 SQLite で処理するデーターベースは小さいものが多いので、特に気になるところはなし。

Ruby 1.8.7-p72 (C)

愛用の Ruby もインストール。これも特筆すべきことはなし。インストール先は迷ったが、それでなくても速くない Ruby なので、Cドライブへインストール。

Ruby の Windows 実装はいくつもあり、私の他の Windows 環境では概ね cygwin をインストールしてあるので、cygwin 版を入れていることが多いのだが、EeePC には cygwin をインストールする余裕もないので、mswin32 版ベースの ActiveRuby を久しぶりに使ってみている。インストールサイズは約 21MB 強。

ノーマルの mswin32 版ではなく ActiveRuby にした理由は、単にアレコレと必要なライブラリを入れるのが面倒だっただけ。あくまで予備環境で、Windows 上では ruby で使ったスクリプトを動かすこともほとんどないので、適当に入れば良いや、後述する rails が動けば良いや、という感じだったので。

以前は one-click ruby installer という便利ものがあったが、こちらはしばらく前から更新されていない。ActiveRuby は今でもきちんとセキュリティパッチにすぐ対応してくれているようなので、感謝の意味も含めて使ってみることにした。昔から本当にずっと、きちんとメンテナンスされていることには頭が下がる。

Rails 2.1 (C)

Rails は迷ったけれど、Ruby も入れたんだし、毒を食らわば皿までな感じで(別に毒でもなんでもないけど)インストール。実用になる速度で動くかどうかは疑問だったが、Cドライブにインストールしたこともあって、まぁちょっとしたアプリのテスト開発レベルなら悪くない。Mongrel の起動とかはそれなりに遅いのは仕方ない。

ただ、Ruby 本体は 20MB そこそこで済むのに、gem で rails 関連のモジュールをインストールすると、RDoc 関連もあって 50MB 以上のサイズが食われる。貴重なCドライブでは馬鹿にならない。それを考えると、無理して入れることもなかったかな?と思う。再インストール時には削ってしまう可能性は小さくない。

QuickTime 7.5 (D) + iTunes 7.7.1 (D)

一度インストールしたものの、インストール先をDドライブに指定してもCドライブに勝手にインストールしまくる物が多く、また常駐するプロセスの多さから嫌気がさして削除したが、Cドライブ容量の増加とともに復活。ただし、インストール方法については、ほんの少し工夫した(後述)。

基本的に GOM Player や MPC Classic などの軽量かつ多機能なメディアプレイヤーがあれば、重い&サイズ大きい&対応ファイル形式に制限ありまくりの QuickTime など、はっきり言ってお呼びじゃない。ので、普通なら EeePC には無縁のソフトの一つのはず。

例えば、EeePC 901 で 740x480 pixels 程度の H.264 ビデオファイルを再生すると、ビットレートによっては QuickTime では High Performance Mode にしないとコマ落ちが発生することもあるが、GOM Player などの軽量プレイヤーでは Power Save Mode でも難なく再生される。当然 CPU の使用率も全然違う。

その上、H.264 フォーマットでもエンコード方法によっては QuickTime では再生できないことも多い。ある筋では QuickTime が糞呼ばわりされるのも道理である。おまけに iTunes をインストールすると、iTunes とは本来関係ないソフトを色々とCドライブにインストールされるし、いくつものプロセスを常駐させるしで、糞呼ばわりされない方がおかしい。

最近のパワーが有り余ってる PC ならともかく、EeePC みたいにリソースに余裕のないマシンに QuickTime と、それをベースにした iTunes は絶対向かない。EeePC のような制約環境下で使うには、QuickTime も iTunes も、とても他人には勧められない。

しかし私の場合、LAN サーバーが iTunes サーバーにもなっていて、HDD/DVD レコーダーで録画したものを転送&再エンコードして iTunes サーバー上に貯まっているという事情がある。そのため、EeePC でも(どこでも持ち運べる EeePC だからこそ)iTunes からネットワーク越しで視聴できる環境は、やっぱり欲しかった。

そのため、リソース食いの問題と利便性の中で悩みまくったものの、メモリ増設と併せて復活させた。

ただ、2度目の今回は、Cドライブへの勝手にインストールされるものを最小限に抑えるために、インストール方法を単に iTunes をDドライブ指定でインストールするのではなく、QuickTime を先にインストールする方法を採った。

通常 iTunes をインストールすれば QuickTime も同時にインストールされるのだが、この場合、iTunes のインストール先をDドライブに指定しても、自動的にインストールされる QuickTime はCドライブにインストールされてしまう。iTunes 本体 80MB はDドライブにインストールされても、残り 210MB がCドライブに入れられてしまう。

余裕のないCドライブに 200MB 以上も入れられては、たまったものじゃない。ここで iTunes のインストール時にCドライブへインストールされるのは、QuickTime が 60MB 以上ある他、 Apple Software Updater、Bonjour、Apple Mobile Device Support がある。

そこでまず、iTunes を入れる前に、QuickTime 単独のインストーラーをダウンロードしてきて、QuickTime を単独でDドライブへインストールする。QuickTime 単独のインストーラーならば、QuickTime をDドライブへインストールすることが可能だ。この場合も共有ライブラリなどが約 70MB もCドライブに入れられてしまうが、それでも QuickTime プレイヤー関係の 60MB ほどをDドライブへ移行できる。

その後 iTunes をDドライブ指定でインストールしても Apple Software Updater、Bonjour、Apple Mobile Device Support がCドライブにインストールされてしまうが、このうち自動アップデート機能のための Apple Software Updater を削除し、MobileMe を使わないならば Apple Mobile Device Support も削除できる。

現状、MobileMe の Windows サポート(というか Mac と Windows の同期)は使い物にならないことを実感しているので、MobileMe を使っている私だが Apple Software Updater とともに Apple Mobile Device Support も削除した。これでCドライブは 40MB 程度削減できる。Bonjour は iTunes の共有ライブラリを探すのに必要なので、私の場合はインストールしたままにしておく。

これだけやっても結構なサイズ(50〜60MB)をCドライブにインストールされてしまうが、単純に iTunes をインストールするよりはCドライブ使用量を削減することができる。常駐するプロセスは iTunes を入れている限り、3つも4つもあるのだが、これはどうしようもない。iPod を EeePC の iTunes に接続するつもりはないから、iPodService なんかは切りたいところだが…

そういうわけで、仕方なく再びインストールした iTunes (+ QuickTime) だが、iTunes で LAN 上の共有ライブラリからビデオ視聴をする場合、iTunes は視聴するビデオファイル全体をCドライブをキャッシュする構造になっている。つまり 1GB のビデオを LAN 経由で見ようとしたら、1GB のファイルがCドライブにできるわけだ。Cドライブの残量をギリギリでやりくりしている EeePC の場合、この仕様はかなり厳しい。

実際、Cドライブに 1.2GB 程度の空きがあっても、1GB 程度のビデオを LAN 経由で見ていてしばらくすると「Cドライブの空き容量が少なくなっています」という Windows の警告が出る。1GB のファイルを転送してきているのだから当然だ。これでは LAN 上の共有ライブラリのビデオを見るために iTunes を入れたのに意味がなくなる。

というわけで、再度インストールしたものの、いずれまた削除する可能性は小さくない。少なくとも再度リカバリーする機会が来たらインストールすることはない気がするし、来月登場と言われる iTunes 8.0 でまた肥大化したら問答無用でアンインストール予定。


Safari 3.1 (D)

Firefox 3 とともにインストールしたものの、狭い画面解像度下の利用では Firefox 3 の全画面モードの使い勝手の良さには敵わず、あまり使わないならリソースの無駄と思って一度は削除した Safari を復活インストール。

Mac の Safari に慣れた身としては、見た目はフォントが綺麗な Safari の方が好きだけど、Mac 版 Safari では必需品ともいえる Safari Stand がないので、実際には Safari の魅力も半減。Dドライブに余裕があるから入れておく、程度なので、状況によってはまた削除する可能性も…



といった感じで、色々と突っ込んでしまっている。ま、iTunes & Safari といった Apple モノは、インストールしては抜き、またインストールしているが、やはり EeePC には向かないと思っているので、きっと次の何かの機会にはまたアンインストールしていると思う。

Apple のソフトが肥大化する原因は理解できなくもないのだが、それでもやはり iTunes をインストールする際に、無闇に色々入れることや、MobileMe を使いたいだけでも iTunes を入れなければならないのはやりすぎだし、QuickTime や iTunes での対応映像フォーマットの偏狭さもどうにかしてもらいたいものだ(iPod はさらに対応映像フォーマットの範囲が狭いのも、だ)。

ともあれ、これでとりあえずは一段落という感じで、しばらくは特に大きな変更はないだろう。次に何かあるとすれば、32GB or 64GB SSD を導入したり、もしくはシステムがおかしくなってリカバリーをしなければならない時だろう。それまでは、これでもう十分“使える”環境になった、と感じている。

なお、前回その1、今回その2でインストールした結果、Cドライブの空き容量は 1.2GB 強で、その後 PostgreSQL 絡みのデーターなどで現在は 1GB 強の空きになっている。ま、最低限これくらい空いていれば問題ないかな、と思っているので、さらに削減とかはしないつもりだ。

Apache, PHP, Ruby, PostgreSQL あたりをDドライブで一時使っていた時と、Cドライブにインストールし直してからのレスポンスの差は、それなりにあるのを体感できるだけに、よく使うソフトはCドライブへ、というのは外せないと思っている。