Dec 28, 2005

サニタイズ言うなキャンペーンについて

隣のオフィスの人がこんなことを書いていました:

高木浩光@自宅の日記 - プログラミング解説書籍の脆弱性をどうするか, 「サニタイズ言うなキャンペーン」とは何か, ASPとかJSPとかPHPとかERBとか、逆だ..

なるほどね、「サニタイズ言うなキャンペーン」とはそういう意味でしたか。私自身、PHPやPerlで適当に書き散らしたものをこのブログで公開してしまっているわけでそれらについてすべてケアできているとは到底思えない、これから気をつけようと思いました(笑)。

で、やっぱり思ったのは、PHPにしろPerlにしろSQLにしろ、String Processingの範疇にあるプログラムは、ほとんど常に処理中の文字列が指し示す「型」を意識しなければ作れないにも関わらず、最もベーシックな型である「文字列型」だけを使って実装されていることに、一番の問題があるのではないか、ということです。

それゆえ、型を意識せずにプロトタイピングした後で正常に動作するように「サニタイズコード」を挿入するという流儀が一般的になっていて、その「手順のシンプルさ」や「(結果として得られる偶発的な)コードのミニマムさ」が、滑稽にも(!)一種の美意識のように思えてしまうのでしょう。

型の話に戻ると、例えばフォームから入力された文字列とそれを「エスケープした」文字列とは異なる型を持っていると考えることができます。その指し示す「内容」は同じだとしてもそのまま比較したり、結合したりすることは、できないか意味がないと考えるのが自然です。それを「型」だと認識していないプログラマであっても仮想的にはその事実を意識してプログラムを書かざるを得ません。

また、HTMLの出力やSQLでの問い合わせの際に何らかが変換が必要になるのは、それらの生成に先立ってプログラムが保持していた値の型と、HTMLの持つべき型・SQL文の持つべき型が異なるため(あるいは問い合わせ結果に含まれる文字列の型とプログラムで保持すべき値の型が異なるため)です。

高木さんの主張は、こうした「暗黙的には存在する」型システムを開発者が強く意識すべきだという主張にほぼ等価に思えます。サニタイズという言葉は単なる文字列から文字列への変換操作だけを連想させ、型に対するプログラマの認識を不確かなものにしてしまいます。例えば、

'名前:'.htmlspecialchars($row['name'], ENT_QUOTES)

は、何かの文字列と「サニタイズされた」文字列を結合したものを返しますが、それはちゃんとサニタイズされた文字列になるのでしょうか。今我々はたまたま固定の安全な文字列「名前:」と結合したことを知っているから、これが安全であることを認識するに過ぎません。そしてそれがたまたまHTMLとして安全に出力するに足る性質を持っているというだけです。それに引き換え、htmlspecialcharsを一種の型変換子と考えれば、

htmlspecialchars('名前:'.$row['name'], ENT_QUOTES)

は、二つの文字列を結合し、それを安全な型に変換したものを返すことになります。したがって安全であると自明に分かります。重要なのは方法が貧乏か富豪かということではなく、確認できるべきことが容易に確認できるかどうかです。

さら言うと、本来なら左辺値の型に自動的に変換してくれるような気の利いたプログラミングシステムがあればなお間違いを減らすことができますが、それは多くの処理系で望めません。苦肉の策というわけではないですが、高木さんはhtmlout_tagとかhtmlout_quoteとかいう関数を用意して安全な文字列への変換と出力を行うこと薦めています。これがベストという訳ではなく、安易に思いつくAlternativeとしては、CGI.pmのオブジェクト指向スタイルのように、出力用の文字列を生成するコンストラクタを用意してやるのも悪くない方法でしょう(CGI.pmが必要な変換を行うかどうかは別にして)。

Google Analyticsのトラッキングコード

Google Analyticsのトラッキングコードは、当初head要素の中に書くことになっていたと思うのですが、いつの間にかbody要素の末尾に書けばいいようになっていたようです。全然気が付いていませんでした。

Google Analytics - ウェブ サイトにトラッキング コードを追加するにはどうすればよいですか。

このコードをコピーし、解析したい全てのページ下部にある、</body>タグの真上に貼り付けてください。

地味な話で恐縮ですが、これは助かりますね。

head部分に書いてあるとトラッキングコードの実行が済むまで、それ以降に記述してあるコードの実行が遅延されてしまいますが、bodyの末尾部分(</body>の直前)に書いてあれば(特定のイベントに結び付けられているコードを除けば)最後に実行されることが保証されます。したがって、一般的にはページの表示遅延の最小化が期待できます。もちろん、User Agentがトラッキングコードの実行以前にページ遷移してしまうと正しくGoogle Analyticsにカウントされなくなってしまうというデメリットもありますが。

また、Movable Typeのようなblogging system(≒マクロプロセッサ)を使っている場合には、テンプレートの役割によってhead部分は異なるが、bodyの末尾部分は共通というケースが案外多いものです。こうした場合、他のフッタのテンプレート片とGoogle Analyticsのトラッキングコードをまとめてテンプレートモジュールにしておけば、そのモジュールをMTIncludeするだけで済みます。

例えばこのブログのフッタ用のテンプレートモジュールは以下のようになっています。

<div id="footer">
<ul>
<li>Copyright &copy; 1994-<$MTDate format="%Y"$> Hirotaka Ogawa</li>
<MTBlogIfCCLicense>
<li><a href="<$MTBlogCCLicenseURL$>" title="Except where otherwise noted, this weblog is licensed under a Creative Commons License.">cc by-sa</a></li>
</MTBlogIfCCLicense>
</ul>
</div>
<script type="text/javascript" src="<$MTBlogURL$>scripts/accesskey.js"></script>
<script type="text/javascript">modifyAccessKey('span','accesskey');</script>
<script type="text/javascript" src="http://www.google-analytics.com/urchin.js"></script>
<script type="text/javascript">_uacct="UA-00000-0";urchinTracker();</script>

こうしておくと、Google Analyticsを一時的あるいは恒久的に中止したくなった場合にも上記のモジュールを最後の2行を削除するだけで済みますね。他の大抵のツールでももちろん同様の対処ができるはずです。

2006-03-10追記:

Google Analyticsを使っていると、http://www.google-analytics.com/urchin.jsがたまに空の文書を返すことがあり、その状態でurchinTracker()を呼び出すとJavascriptエラーになってしまいます。割とどうでもいいことですが、Firefox+WebDeveloperを使っていると猛烈に気になります。

なのでurchinTracker()を呼ぶ前にちゃんとロードできているかどうかチェックするとよいでしょう。

<script type="text/javascript" src="http://www.google-analytics.com/urchin.js"></script>
<script type="text/javascript">
if (typeof urchinTracker == 'function') {
    _uacct='UA-00000-0';
    urchinTracker();
}
</script>

Dec 26, 2005

Google Directory

いまさらなのですが、このブログがGoogle Directoryに登録されていました。パチパチ
現在のところ、Google Dancing状態でリストに表示されたりされなかったりするようです。

ウェブディレクトリ - World > Japanese > コンピュータ > インターネット > ウェブ上の情報 > ウェブログ > ツール

ODP - Open Directory Projectのディレクトリには前から載っていたのですが、結構delayがあるものなのかそれともGoogleの単純なミスなのかは定かではありません。

Open Directory - World: Japanese: コンピュータ: インターネット: ウェブ上の情報: ウェブログ: ツール

それにしてもそこそこPagerankが高いっぽいのは、Movable Typeのプラグインを公開してSix Apartからリンクを張ってもらっているせいですかね。

Dec 23, 2005

MT 3.2日本語版 UO Pacth (12月更新分)

Movable Type 3.2日本語版Release-2(以下、MT)が出て2か月ほど経ち、すでに多くのユーザが移行されているのではないかと思います。さて、以下のWikiページではこのMTに対するUnofficial Patchを公開しています。

MT_3_2_ja2_UO_Patch - ogawa - Google Code

このパッチは、通常のMTの利用では問題にはならないものの、よりadvancedなユーザ(XMLRPCインタフェースを利用するユーザ、プラグイン開発者など)にとっては問題となるようないくつかのバグを修正することを目的としています。特に不具合を認識していない場合には適用する必要はありません。

12月に入ってから3件新規のパッチを追加しましたので、関心がある方は上記ページをご参照ください。

  • FastCGI環境などでMT::App::Searchが正常に動作しない。(lighttpd FastCGI 上で MT3.2 を動作させる方法 :: Drk7jp)
  • MT::App::CMSのlist_authors画面において、plugin_itemset_action_loopが正しくセットされないためにプラグインでitemset actionを定義してもプルダウンメニューが空のままになる。
  • MT::App::CMSを用いてエントリーを保存した場合にmt-config.cgiの設定オプションPublishCommenterIconが無視される。PublishCommenterIconはドキュメントされていないオプションである。(drry @->Weblog - TypeKey 投稿者のアイコン)

Dec 21, 2005

[CFP] 第9回 プログラミングおよび応用のシステムに関するワークショップ (SPA 2006)

第9回 プログラミングおよび応用のシステムに関するワークショップ (SPA 2006)
2006年3月5日(日)~7日(火) 塩原温泉
日本ソフトウェア科学会 ソフトウェアシステム研究会 主催

ワークショップの目的・内容

ソフトウェアに関する先端的な学術研究と実際的なソフトウェア開発を行うことは、ソフトウェア研究の大きな目標ですが、それらを両立させることは容易ではありません。ソフトウェアシステム研究会では、これら二つの大きな目標を目指す研究者が一堂に会し、最新の研究成果の発表および、新たな研究課題に付いての討論やアイディア交換を行うことを目的として、毎年、ワークショップ SPA(Systems for Programming and Applications) を開催し、30件近い発表と80名を越える参加者を集めております。

SPA は合宿形式のワークショップで、討論の時間を十分にとった研究発表により、参加者の研究の発展の契機となることに重点をおいています。そのため、完成した研究の成果の発表だけでなく、萌芽的な研究の報告も歓迎します。

本ワークショップの主たるテーマは、

  • ミドルウェア
  • オペレーティングシステム
  • ネットワーク
  • アプリケーション
  • プログラミングシステム (プログラミング言語・開発・支援環境 他)
  • インタラクティブシステムの基盤ソフトウェア
  • その他ソフトウェアシステム全般

ですが、これら以外でもソフトウェアシステムに関連する発表であれば歓迎します。

詳しくは、SPA2006をご参照ください。Web関係の企業の皆様のご発表・ご参加も歓迎しております。

Dec 15, 2005

Structured Bloggingについて思うこと

Structured Blogging的な話が盛り上がるのはとてもよいことだ。このエントリーではStructured Bloggingに関して私の思うところを述べる。ちなみに私はStructured Bloggingのコンテキストで述べられているような共通のデータ交換形式にはさほど興味がない。その試みは…多分またしても…思ったよりうまく行かない予感がする、XMLフィードに挿入するようなMicro Annotationを除けば。私が興味を持っているのは、Blogging SystemがStructured Dataを扱うことができるようになることでプラットフォームとしての機能を増すこと、である。

Structured Bloggingとは- at Syndicate - Speed Feed [ITmedia オルタナティブ・ブログ]

一年くらい前にSAKKに行ったときに平田さんとももっと構造のあるデータを扱いやすいようになれば(あるいはそのプラットフォームにMovable Typeがなれば)、ビジネス面でのBlogの利用価値がもっと向上するのではないか、とそういう話をしていたのを思い出した。いずれ向かう道としては非常に正しいと思う。

最近のMovable TypeのバージョンやWordPressではStructured Bloggingにあるプラグインが使えるし、宮川さんが紹介(RightFields - Turn your MT into Google Base!: blog.bulknews.net)しているようにRightFieldsというプラグインもある。CustomFieldsもあるけどね。また、Google Baseだってそのインプリメンテーションのひとつだという言い方ができる。

これらはいずれも、単にタグや位置情報やお天気情報をBlogの記事に付与するというだけのToyな「構造」だけでなく、本質的に「構造をもったデータ」として格納しておき、それらを加工して、Blogや他の形態での「ビュー」を与えられるということである。

さて、これらの共通の問題はスキーマの拡張性やデータベース機能がほとんど、あるいはまったくないということである。例えば、映画レビューBlogをStructured Dataとして格納したとして、後からスキーマに一個レビュー項目を追加したくなったらどうするのか。映画レビューBlogと俳優データBlogがあったとき、それらを連携したくなったらどうするのか。賃貸アパート・マンションBlogとレストランガイドBlogを連携したくなったらどうするのか。現状いずれにしてもその手段がない。

かなり構造データ指向であるはずのGoogle Baseだって事情はそんなに変わりがない。データベースを横断的にアクセスしようとしても、タグかラベルのような比較的ルーズな方法しか用意されていないように見える。また、スキーマに変更があれば再度バルクでアップロードし直してくれ、というアプローチのようだ。「タグやラベルで十分じゃん。アップロードし直しでいいじゃん。」という意見ももちろんあろう。しかし、従来のBlogやブックマークの場合にはたまたまタグ以外に構造データがなかったのでそれなりに使えるように見えていただけだとも言える。実際に特定のデータ型を持つ特定のフィールドをキーにexact matchを取れるのと比較すれば(あるいはspatialなデータのハンドリングなどを考えてもよい)、圧倒的に精度も信頼度も低いだろうことは想像に難くない。またFTPによるアップロードインタフェースはGoogleの産物とは思えないほどアナクロだ。

要するに私が言いたいのは、Structured Bloggingに現在本質的に不足しているのは結合演算や副問い合わせを含めたデータベース機能である、ということである。JOINすることができれば、別テーブルにスキーマの拡張分を定義すればよいだけだし(Alterしてもよいし)、複数の異なったStructured Blogを連携するのも実現できる。

もっとも外部からのアクセスメソッドをちゃんと定義してくれさえすれば、クライアントサイドで計算するという方法も選択肢としてはあり得るという意見もあろう。しかし、効率の点では圧倒的にサーバーサイドで計算する方が望ましい。また、Google Baseのようなリモートデータベースの場合には一般にクライアントサイドでの処理時間や消費メモリ量が予測できないので、できればやりたくないし、やるべきではない。

さらに言えば。「これからは『2.0』(括弧付き)の時代だぎゃ」「複数のサービスをMash-upするみゃ」とか言っている人たちともこの話は関わりがないこともない。まずサービスとは、入力メッセージに対して出力メッセージを返すプログラムであり、これは入力と出力のメッセージのペアの集合だと見なすことができる。このこと自体は別に新しい考え方でも何でもなく、プログラムの「関数」の数学的な意味を入出力のタプルの集合と考えるのは、Denotational Semanticsの伝統的な手法のひとつに過ぎない。

この抽象の下では、一つのサービスリクエストは一つの入出力データベースへの問い合わせを意味する。独立な二つのサービスを並行に利用する場合には実質的にJOIN演算を行っているのに等しいし、また連携させる場合にも実質的にやりたいことは、他データベースへの副問い合わせや複数の表の結合に帰着するだろう、と。

要は、Structured Bloggingと「2.0」(しつこく括弧付き)でやりたい、やろうとしていることは案外近い。そして両者がよりハッピーになる方法は単にアクセッサを公開することだけでなく、データ統合できるほどの粒度までインタフェースを公開して提供してしまうことなのだ、と思えるのだが…さて。

そこでグリッドの登場ですよ…(嘘つき!!)。

Dec 14, 2005

Yahoo!検索 Webサービスを使った割とありがちなサイト内検索

ありがちですが、このブログのサイト内検索をYahoo!検索(Yahoo!デベロッパーネットワーク - 検索Webサービス)とAjaxを使うようにしてみました。

また、ysearch-json.cgi、ysearch-json.fcgiは単体で使用すると(queryオプションを与えないと)フォームを表示するので動作確認などに使用できます。

注意点

  • YSearch.jsの58行目の'uri'の値は、ysearch-json.{cgi,fcgi}のURLを指定する必要があります。
  • ysearch-json.{cgi,fcgi}の10行目の$YJWS_APPIDにセットするアプリケーションIDはYahoo!デベロッパーネットワーク - アプリケーションIDの登録から適宜取得してください。
  • ysearch.html, ysearch-inc.html中、「YSearch.init('[Your Hostname]',10);」の引数はそれぞれ「自分のサーバーのホスト名」「一度に表示する検索結果の個数」です。適宜変更してください。
  • ysearch-inc.htmlは相当手抜きです。ちゃんと動くようにするためにはインターバルタイマーを真っ当に使う必要があります。ま、簡単なのでいろいろ試してみてください。

Dec 9, 2005

FeedBurner の Item Stats をオフした件について。

FeedBurner(RSSやAtomなどのXMLフィードを中継配信してくれるサービス)を300日ほど使用し続けています。私の借りているサーバーの代わりに各種形式でXMLフィードを配信してくれるのに加えて、ブラウザヴィジブルにしてくれたり、統計を取ってくれたりと重宝しています。

Ogawa::Buzz: FeedBurnerに移行した件について。

この手のフィードの中継・変換サービスで重要になるのは機能だけでなく、中継配信の信頼性や、もし何らかのマニピュレーションをフィードに対して施すのであれば、その操作の透明性も重要です。Web上のサービスである以上「信頼性」に関しては「それなり」のものでしかあり得ませんし、「操作の透明性」に関しては仕様が明文化されているとは言い難くやや不満が残ります。

さて、Item StatsはFeedBurnerの機能の一つでフィードに含まれるitemのクリック数をトラックすることでitemごとの利用統計を与えるサービスです。クリック数をトラックするために、FeedBurnerはitemのlink要素を「http://feeds.feedburner.com/ogawa?m=18」などに書き換え、このURLへのアクセスは元のlink要素のURLへリダイレクトされるようになっています。

FeedBurnerのフィードをブラウザ経由で利用する場合にはこれで問題ないのですが、そのフィードを操作するソフトウェアでは問題が起き得ます。例えば、naoyaのはてなダイアリー - はてなブックマークの概要取得の処理の、

  1. 該当エントリーに Feed Auto-Discovery を実行する
  2. その中で最初に見つかった Feed (link タグで一番上にあるもの) を GET する
  3. Feed を parse して、ブックマークされた URI を link 要素にもつ要素を探す
  4. その要素に content 部分 (RSS 1.0 なら content:encoded、Atom なら content) があればそれを取得、なければ description を取得

という処理を考えてみると、link要素がリダイレクトURLに書き換えられているFeedBurnerフィードでは、このロジックが機能しません(だから中途半端な概要がはてなブックマークに引用されてしまう)。bulkfeeds.netやlivedoorブログ検索などがうまくインデックスしてくれないのも似たような事情なのではないかと疑っています。link要素のURLを全部HEADしてから比較してもらえばよいのかもしれませんが、すべてのサービス・アプリで対応することを期待するのは馬鹿げています。

また、無料アカウントでもItem Statsが使えるのに、PROアカウントでないとAwareness API経由でItem Stats情報を取得できません(GetItemStatできません)。この非対称性には正直苛っとさせられますね。

さらに、他の人のブログで引用されるときにリダイレクトURLをReferされたり、リダイレクトURLをブックマークされたりしても、Item Statsのページ以外の方法では観測できません。というより、Item Statsのページは各アイテムのクリック数しか表示しませんから、実際には観測不可能だということになります。前述のようにAPI経由で利用するためには有料アカウントが必要で、APIで取得できる情報は(Item Statsのページ同様)やはりサマリー情報だけに縮約されます。要は、ユーたちの大事なREFER(R)ER情報がFeedBurnerに掠め取られているんだゼ、ということです。

ではどうすればよいのかというと、実はItem Statsの機能をdisableするとFeedBurnerはlink要素を書き換えないので、disableすればすべてが解決します。デメリットはItem Statsが使えなくなるというただ一点です。私は問答無用でdisableしました。

方法はいたって簡単。(1) 各フィードのAnalyze画面で「StandardStats」を選び、(2) 「Feed item link clicks」のチェックボックスを外し、(3) 「Save」するだけです。

この件でお悩みの方はお試しあれ。

2005-12-12追記:

この設定を行うと既存のリダイレクトURLはすべて無効になり、「http://feeds.feedburner.com/ogawa?m=18」はそのフィードURL自体を指すようになるようです。つまり、すでに誰かがリダイレクトURLをブックマークしている場合には到達不可能になってしまいます。これはまあデメリットですね。

フィードURLとItem IDから実URLをresolveするAPIを提供してくれてもいいのだが>FeedBurner

Dec 8, 2005

Gmailのさまざまな機能追加

毎日使っているGmailが今日なんだかドラスティックに変わっていました(英語版)。

  • RSSフィードを表示するWeb Clips機能が付きました(Gmail: Help Center - What is 'Web Clips'?)。

    邪魔だし役に立たないのですぐOFFにしました。まだすべてのアカウントにこの機能が追加されているわけではないようです。
  • 添付ファイルのプレビュー機能が付きました(Gmail: Help Center - How do I view attachments?)。もともと添付された画像ファイルのプレビュー機能はついていましたが、Microsoft Officeの各種形式(Word, Excel, PowerPoint)やPDF形式のときでもプレビューできます。これらの形式の添付ファイルのすぐ横に「View as HTML」というリンクが表示されるので、それをクリックしてやるとHTMLでプレビュー表示できます。いちいちダウンロードすることを考えると非常に手軽になりました。
  • メール本文中の住所を読み取ってGoogle Mapsへのリンクを表示したり、FedEx、UPSなどのtracking numberを読み取ってSearch By Numberへのリンクを表示したりする機能が追加されたらしいです(Gmail: Help Center - What are these links?)。でも確認できていません。
  • ゴミ箱のクリーンアップ機能がちゃんと機能するようになっています。

個人的にはプレビュー機能は非常に重宝しそうです。いつもだとダウンロードした添付ファイルでデスクトップが溢れ返ってしまうので。

Dec 5, 2005

医療保険(+ガン保険)を契約してみた

自動車保険や住宅ローンの団信には加入しているが、「保険って訳わかんね。」と思ってずっと放置してきた。年齢的にもリスクが増しつつあり、ガン家系であるという認識も多少はあり、掛け捨ての医療保険(+ガン保険)くらいは入っておくべと思って、週末に何度か目のチャンレンジ。

「訳わかんね。」と思うのは、パラメータが多すぎるせいだ。

自動車保険だったらパラメータが限られているので比較が容易だし、契約も一年単位なので「やっべー間違った!」と思っても翌年契約し直せば済む。

それに比べて医療保険には、入院時の保険金(日額、一時金)、手術時の保険金、通院時の保険金、ガン入院時の保険金、交通事故障害入院時の保険金、特定疾病診断時の一時金などさまざまな金額のパラメータがある。また、これらのうちどれが独立なパラメータになっているのかが保険会社によってまったく異なっている。さらには抱き合わせ損害賠償責任保険などの有無と金額でもバリエーションがある。1・3・10年ごとに保険料の一部がリファンドされるとかいうのも一種の抱き合わせ保険だと言える。職業の種類や既往病によるリスクを反映しているか否か、またその度合い、という隠しパラメータっぽいのもある。

ついでに明治安田やアメリカンホームは保険金・給付金の不適切な不払いが多数あって業務改善命令を受けている。他の会社も大なり小なりその手の問題を抱えていて、各社Webページに調査結果を発表している。かと言ってその調査の精度が各社で一致しているわけでもなかろう。つまりは保険会社によって不払いリスクが異なり、それも明示されないパラメータとして存在する、ということだ。

さらに保険料の支払い方法でも、(1)10年ごとに再契約して値段が変わる、(2)一生変わらない、(3)一生変わらない上に60歳までに支払いを終える、とかいろいろな種類がある。

当然(1)の方が年齢リスクをより保険料に忠実に反映するため安くなり、(2)や(3)では割高な保険料を予め支払うことになる。外的条件も考えると頭が痛くなる。例えばインフレリスクを考えた場合、インフレならば必要になる医療費は当然増加すると考えねばならない。(1)だと年齢リスクとインフレ分の上乗せされるであろう10年後の保険料が心配になる。(2)(3)のように保険料が固定だったとしても、結局はその定額保障では不足する可能性がある。ということは契約を中途変更するか追加で保険商品を購入することになるということだ。

なんなんだよこれは、って感じ。

数時間悶絶しまくった挙句にようやく契約にこぎつけた。月額X千円以内という制約を課してみたら案外すんなり決まってしまった。いいのかなあ、これで。まだ、生命保険とか学資保険とか養老保険とかいろいろあるんだよね。面倒だな。

Dec 1, 2005

VMware Workstation 5.5

世間がFirefox 1.5で騒がしい(Web Developerdel.icio.usしかextensionを入れていないので特にトラブルこともなく、つまんない)が、VMware Workstation 5.5がリリースされていたので5.0からとっととアップグレードしてみた。

Workstation 5.5 Release Notes

Guest OSに64-bit OSをサポートしたことや、2つまでのVirtual SMPに対応したことなどが目玉なのだが、前者はHost OSが64-bit OSでプロセッサが「AMD™ Athlon™ 64, revision D or later; AMD Opteron™, revision E or later; AMD Turion™ 64, revision E or later, AMD Sempron™, 64-bit-capable revision D or later (experimental support); and Intel® EM64T VT-capable processors」でなくてはならず、後者はもちろんPCがマルチプロセッサでなければならない。そういうわけでポータブルPCがメインマシンの私には意味がない。

体感速度は上がっているような気がする。気がするだけかもしれない。

また、レジュームがバックグラウンドで行われるようになったので、二つのGuest OSを切り替える操作(一方をサスペンドして他方をレジュームする)がサクサク行える。言い方を換えると、ポータブルPCのように多少メモリ制約がきつい環境での利用時の問題が(少)なくなった、とも言える。今までなら、待たされるのが面倒で二つのVMを動作させっぱなしにしておかざるを得なかったし、それゆえにメモリを節約する必要があってGuest OSのGUIはまったく使いものにならなかった。

+0.5のわりには格段の進歩と言える。

ついでにVMware Playerが同梱されていたので少しだけ使ってみた。

「んー、Guest OSのFreeBSD 6.0がサスペンドできないの?」

...少し修行が必要なのだろう。

About Me

My Photo

つくばで働く研究者LV15

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com