仙石浩明の日記

2008年12月25日

香港の旺角で GSM ケータイ Motorola ZN200 を買ってみた

円高のおかげか、香港パック旅行が格安で売られていた (残念ながらサーチャージは改訂前だったので原油安の恩恵は受けられず) ので、 連休 (KLab は 12/22 が休みなので 12/20-23 が四連休) に休みを追加して香港へ行ってきた。

香港といえば (SIM ロック フリー) 携帯電話。 ホテルが旺角の近くなので、 まず先達廣場へ行ってみる。 携帯電話屋が多数集まっていることで有名な先達廣場だが、 安いのは Nokia 1208 (HK$200 くらい) などの 2バンド GSM (dual-band, 900/1800) 機ばかりで、 これだと 1900MHz 帯をサポートしていないので米国などで使えない。 4バンド GSM (quad-band, 850/900/1800/1900) 機だと結構高め (HK$1300～)。 安さを求めるなら先達廣場はあまり向いていないのではないか？ そもそも旺角の物価が (新界に比べると) 少々高め。

まあ、最近の為替レートだと HK$1 = 12円以下なので、 高いと言っても高々 15,000円程度ではあるのだが、 海外旅行中に通話専用として使う携帯電話としては安いに越したことはない (データ通信にも使う携帯電話としては HTC P3600 を既に持っているので)。

先達廣場を出て、西隣にあった家電量販店 國美電器 を覗いてみると、 Motorola ZN200 を HK$899 で売っていた。 期間限定のキャンペーン価格のようだ。 零細ショップより大手量販店の方が安くなるのは、 旺角も秋葉原も同じ、ということなのだろうか。 それまで見た 4バンド GSM 機の中では一番安かったので、 これに決めた (約 1万円)。

続いてプリペイド SIM カード Super Talk Stored Value SIM Card の Starter Pack HK$48 を、 PEOPLES Shop (China Mobile) で購入 (HK$43)。 2枚買って、Motorola ZN200 と HTC P3600 にそれぞれ入れた (2枚で約 1000円)。

たまたま登打士街 (Dundas st) を歩いているときに、 PEOPLES の看板が目に入ったので PEOPLES Shop で SIM カードを買ったが、 Distribution Channels によれば 7-Eleven などでも売っているらしい。 でも、忙しそうな 7-Eleven の店員に SIM カードのことをあれこれ尋ねて買うのは気が引けるのだが... その点、PEOPLES Shop は 「マル優」 マーク付なので安心かも。

通話料は繁忙時間帯 (12:00～20:59) で HK$0.12/分 (1.4円)、 それ以外の時間帯だと HK$0.05/分 (0.6円) であり、 香港の物価水準から考えても、えらく安い。 4日間の滞在では SIM カードの度数がほとんど減らず、 HK$40 以上が残ったままだった。

デフォルトで国際ローミングを行なう状態になっているようで、 日本に戻ってきてから香港の電話番号 010-852-XXXX-XXXX へかけたら、 ちゃんと HTC P3600 が鳴った。 SoftBank あるいは NTT DoCoMo のいずれの UMTS (Universal Mobile Telecommunications System) 網に接続していても着呼できた。 もちろん Motorola ZN200 は GSM 専用なので日本では使えない。

ただし、データ通信 (Mobile Data Service) は HK$0.04/KByte もするので、 ちょっと画像が多いページを閲覧したりすると、 SIM カードの度数が一瞬で無くなってしまう (1.2MB ダウンロードするだけで HK$48 になるから当然だが) ので、 少しでもデータ通信するなら Mobile Data Package (データ定額 HK$98/月) を利用すべき。 実は、 香港滞在の最終日に、 ごく短時間のアクセスのつもりで PC に HTC P3600 を接続して Web ブラウズしたのだが、 たまたまアクセスしたページに画像が沢山貼ってあった ;-( おかげで、 HK$40 以上残っていた SIM カードが、 そのページを表示しただけで無くなってしまった。

なお、 Mobile Data Service を利用するには、 * 1 0 6 * 0 1 # へ電話をかけてサービスを有効に (activate) する。 私は利用しなかったが、 Mobile Data Package を利用するには、 Mobile Data Service を有効にした上で、 * 1 0 3 * 0 1 # へ電話をかけて利用開始 (subscribe) すればよいらしい。

Mobile Data Package 利用中は、 30日経つたびに HK$98 が SIM カードから差し引かれるので、 利用しないときは、 * 1 0 3 * 0 2 # へ電話をかけて Mobile Data Package を利用中止 (cancel) する。

Mobile Data Package を利用しなかった (できなかった) のは、 インターネット接続はホテルの無線LAN を利用すればよい、と考えていて、 携帯電話でのデータ通信に関して下調べを怠っていたから。 旅行前に、 滞在するホテル The City View (旧 YMCAインターナショナルハウス) は、 「部屋からインターネット接続できる (らしい)」との記述を見つけて安心していた:

部屋からインターネット接続出来る。（らしい）
以下、文面のコピー。

＜ブロードバンドインターネットアクセス＞

当ホテルでは、客室・ロビー・会議室・レストラン・ラウンジ内の どこからでも高速インターネットにアクセスできる 「ブロードバンド・インターネット接続サービス」がご利用いただけます。
お客様のご利用されるパソコンに、 ワイヤレスでのインターネット接続に必要な802.11b/Wi-Fiが搭載されていない場合、 専用アダプターもご用意いたしております。
詳しい内容については、 ホテルのビジネス・センターまでお問い合わせください。

※ご利用にあたっての重要なお知らせ※

「ブロードバンド・インターネット接続」サービスをご利用いただくにあたり、 以下の内容にご承認・ご同意下さるようお願い申し上げます。
インターネットを通じたメッセージの安全な送受信は100％保証することは出来ません。 インターネットによる通信では、 更新の中断や送信の遮断・ネットワークの繁忙状態による送信の遅れ、 誤ったデータの送信などのエラーが生じる可能性があります。
当ホテルおよびサービスプロバイダーは、 細心の注意を払って同サービスの提供に努めておりますが、 お客様が「ブロードバンド・インターネット接続」サービスを ご利用されることによって・もしくは利用出来ないことによって、 万が一、何らかの直接的・間接的な、 もしくは偶発的・必然的な損失やダメージ・負債・補償請求などの被害を被った場合、 当ホテルおよびプロバイダーは一切の責任を負いません。

実際、部屋にはこの文面と同じ紙があった。 ところが、 この「ブロードバンドインターネットアクセス」に接続してみると、 Systech Telecom が提供している有料サービスだった。 それも香港の物価水準と比較すると法外に高い HK$100/日。 誰がこんなサービスを利用するんだ？ (泣く泣く利用したけど...) 「※ご利用にあたっての重要なお知らせ※」を書くなら、 真っ先に有料であることを書くべきではないのか？ ＞ ホテル

一ヶ月の携帯電話データ定額より、 一日の無線LAN の利用料の方が高いとわ... (*_*)
ちゃんと下調べして Mobile Data Service を利用すればよかった...

おまけ:

こういうのを見ると ↓ 香港の物価の安さを実感する。

More...
Filed under: SIM,香港 — hiroaki_sengoku @ 09:17
2008年12月9日

freeRADIUS 2.1.3 のバグ: ログを stdout/stderr へ出力できない

無線LAN の脆弱性について警告が飛び交う昨今、 WPA2 (Wi-Fi Protected Access) といえど、 パーソナル (PSK, Pre-Shared Key) モードだとパスワード破りの可能性が 無いわけでも無いので、 エンタープライズ (EAP, Extensible Authentication Protocol) モードに乗り換えてみた。

EAP (社員支援プログラムではなくて、 拡張認証プロトコル) の認証方式には EAP-MD5, EAP-FAST, EAP-SKE, EAP-SRP, MS-CHAP, EAP-GTC, EAP-GTC, Cisco LEAP, EAP-TLS, EAP-TTLS, PEAP, EAP-MAKE, EAP-SIM などがあるが、 対応機器/ソフトウェアが多そうな EAP-TLS を使ってみることにした。 EAP-TLS とは、 TLS (Transport Layer Security) すなわち SSL (Secure Sockets Layer) のサーバ認証とクライアント認証を行なって、 RADIUS サーバと無線LAN 端末が相互に認証を行なう仕掛けである。

RADIUS サーバとしては、 free RADIUS 2.1.3 を使用した。 自前の認証局 でサーバ証明書とクライアント証明書を発行し、 それぞれ RADIUS サーバと無線LAN 端末 (Windows マシン) へインストールする (自分で発行する証明書だが、 認証する側が自分の管理下なので、 いわゆる「オレオレ証明書」ではない)。

まず radiusd をデバッグ モードで走らせてみる: 

# radiusd -X
FreeRADIUS Version 2.1.3, for host i686-pc-linux-gnu, built on Dec  6 2008 at 17:50:58
Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. 
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE. 
You may redistribute copies of FreeRADIUS under the terms of the 
GNU General Public License v2. 
Starting - reading configuration files ...
including configuration file /usr/local/etc/raddb/radiusd.conf
including configuration file /usr/local/etc/raddb/clients.conf
including configuration file /usr/local/etc/raddb/eap.conf
group = radius
user = radius
including dictionary file /usr/local/etc/raddb/dictionary
        ...(中略)...
Listening on authentication address * port 1812
Ready to process requests.

とりあえず動いているようだ。 Windows マシンからアクセスポイントへ接続してみると、 アクセスポイントを介して Windows マシンと RADIUS サーバ間で、 TLS サーバ/クライアント認証が行なわれ、 無事 WPA2 エンタープライズ モードで接続が完了した。

では、radiusd を daemontools 配下で動かそうと、 次のような /service/radius/run スクリプトを書いて動かしてみる: 

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
exec 2>&1
exec radiusd -fxxx

-x を指定して詳細なデバッグ情報を出力させるようにする。 daemontools 配下で動かす場合、 multilog プログラムがログをどんどんローテートしてくれるので、 通常運用でもデバッグ情報を出力させておける。 ログを標準出力 (stdout) へ出力させるため、 設定ファイル radiusd.conf において、 次のように指定しておく。 

log {
        destination = stdout
}

これでログが /service/radius/log/main/current に書き出されるはず、 と思ったら何も出力されない... 何故に...?

radiusd(8) によれば、-X オプションは 「-sfxx -l stdout」 と等価らしい。 -s オプションは、 RADIUS サーバを単一スレッド/プロセスで走らせるための指定。 個人で使う分には単一スレッドでも構わないといえば構わないので、 ログを stdout に出力する目的で -X オプションを使ってしまっても構わないのだが、 せっかくだからともうちょっと追ってみることにした。

まず上記 run スクリプトにおいて 「-l stdout」 を指定してみる。 すると、/service/radius ディレクトリに stdout というファイルができて、 そこにログが出力された。 ダメだこりゃ。 -l オプションはマニュアルには記載されていないので、 -l に続く 「stdout」 をファイル名と見なすのも一つの「仕様」と言えなくもないが...

ソース radiusd.c を見てみると、 確かに -l オプションの処理では続く引数をファイル名としてしか扱っていない。 では設定ファイル radiusd.conf に指定した場合はどうかと、 mainconfig.c を見てみる。 「log { ... }」 の中で 「destination = stdout」 を指定すると、 mainconfig.radlog_dest に RADLOG_STDOUT が代入されるようだ。 ところが、mainconfig.radlog_fd を設定するコードがない。 これでは stdout にログが出力されるはずがない。

「-l stdout」 の件は百万歩譲って「仕様」でも構わないが、 mainconfig.radlog_dest に RADLOG_STDOUT を代入しておきながら mainconfig.radlog_fd に代入し忘れるのは、 仕様うんぬん以前にソースとして首尾一貫していないので、 明らかにバグである。

そこで以下のようなパッチをあてて、 mainconfig.radlog_dest が RADLOG_STDOUT あるいは RADLOG_STDERR のときは、 mainconfig.radlog_dest に STDOUT_FILENO あるいは STDERR_FILENO を それぞれ代入するようにしてみた。 

--- src/main/mainconfig.c~        2008-12-06 01:37:56.000000000 +0900
+++ src/main/mainconfig.c        2008-12-06 16:16:27.455277946 +0900
@@ -738,6 +738,10 @@
                                 cf_section_free(&cs);
                                 return -1;
                         }
+                } else if (mainconfig.radlog_dest == RADLOG_STDOUT) {
+                        mainconfig.radlog_fd = STDOUT_FILENO;
+                } else if (mainconfig.radlog_dest == RADLOG_STDERR) {
+                        mainconfig.radlog_fd = STDERR_FILENO;
                 }
         }

これで無事、 ログが stdout に出力され、 /service/radius/log/main/current に書き出されるようになった。

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 08:02
2008年11月25日

10階以上のホテルの部屋から公衆無線LAN に接続する方法 hatena_b

休暇をとってハワイ (オアフ島) へ行ってきた。

泊まったのはワイキキの安ホテル。 部屋はもちろんマウンテンビュー (つまり海が見えない側)。 一般に階数が高いほどいい部屋とされるが、 公衆無線LAN を使いたい場合は低層階のほうがいい。 もう少し上のランクのホテルだと、 各階に無線LAN のアクセスポイントが設置されていたり、 あるいは各部屋に LAN が敷設してあったりするが、 私が泊まったホテルだと無線LAN が使えるのは一階ロビーだけ。 部屋でインターネットにアクセスしたければ、 屋外で利用可能な公衆無線LAN を利用するしかない (もちろん電話でダイアルアップ接続する手も無くはないが、 あくまでそれは最後の手段)。

こういう場合、部屋が高層階だとやっかいである。 公衆無線LAN のアクセスポイントは、たいてい地上近辺に設置されているので、 階数が高いほど接続しにくくなるからだ。 今回は運悪く (フツーの意味では運良く) 最上階に近い 15階。 厳しいんじゃないかなぁと思いつつ、 ノートPC 内蔵の無線LAN 端末で接続を試みたら案の定、全く接続できず。 ラナイ (Lanai, ハワイ語で「ベランダ」) から身を乗り出して、 ノートPC を外に突き出して (落下注意!) みたのだがダメだった。

高層階だと当然遠くの街路まで見渡せるわけで、 やたらと沢山のアクセスポイントが見通し距離範囲に入ってくる。 が、こちらから出す電波が、 同じチャンネルで電波を出す機器に届かなければ衝突回避してもらえない (CSMA/CA, Carrier Sense Multiple Access/Collision Avoidance) わけで、 ノートPC 内蔵のアンテナではどうにも力不足である。

こんなこともあろうかと、 私は長期旅行には La Fonera+ を持っていくことにしている。 ノートPC 内蔵の無線LAN 端末と違って、 La Fonera+ には外部アンテナがあり、 また内蔵アンテナもあるので、 組合わせてダイバーシチ送信/受信が可能である。

La Fonera / La Fonera+ (FON ソーシャル ルータ) は、 本来は無線LAN アクセス ポイントなのであるが、 中身は普通の Linux マシンなので何でもアリである。 もちろん 無線LAN 端末として 使うこともできる。 まずは La Fonera+ をラナイの端ギリギリ (落下注意!) のところに置き、 ノートPC と Ether ケーブルでつなぐ。 ノートPC で試したときに比べてはるかに多くのアクセスポイントが見つかった (実に 49個!)。

無線LAN 端末としての La Fonera+ が見つけたアクセスポイントの一覧 (信号強度 dBm 順):

More...
Filed under: Hawaii,La Fonera — hiroaki_sengoku @ 08:17
2008年10月27日

initramfs シェル環境 (initramfs shell environment) でジョブ制御する方法 (aka “can’t access tty; job control turned off” を消す方法) hatena_b

GNU/Linux OS のブート時に、init(8) を経由せずにシェル (/bin/sh) を実行すると、 このシェル上ではジョブ制御 (job control) が行なえない。 つまりこのシェル環境は制御端末 (controlling tty) に成れない。 これがどんなに不便かというと、 自動的に止まらないプログラム (例えばオプション無しで ping を実行したときなど) を止める方法が無いわけで、 いったんそういうプログラムを動かしてしまったら最後、 CTRL-ALT-DEL で reboot させる他なくなってしまう。

そもそも、なぜ init(8) を起動する前に /bin/sh を実行したいかというと、 ミニルート (initramfs) 上で 作業を行ないたいから。 initramfs の init (これは init(8) ではなくシェル・スクリプト) の中で、 BusyBox の /bin/sh (/bin/ash) を exec する (つまり PID=1) ことによって、 initramfs 上での作業を可能にする。

init(8) は、 GNU/Linux OS の全てのプロセスの親プロセスだが、 その万物の親すら生まれていない創世記以前に作業を行なえるメリットは数多い。 例えば、ルート・ファイル・システム (root file system) すらマウントしていない段階なので、 マウント後 (つまり init(8) 起動後) には実行不可能な操作 (xfs_repair などのファイルシステム修復操作とか) を行なうことができる。 しかもこのシェルはプロセスID が 1番なので、 このシェル環境上で root file system を「/」にマウントし、 続いて init(8) を exec すれば、 そのまま GNU/Linux OS を起動することができる。

root file system のメンテナンス等は、 別の起動ディスク (CD-ROM や USB メモリ等) からブートして行なうのが一般的だが、 CD-ROM ドライブや USB メモリを準備したり、 あるいは CD-ROM や USB メモリの抜き差しが必要になったりと、 なにかと面倒である。 メンテナンス用の起動パーティションを root file system とは別に用意する、 という方法も考えられるが、 メンテナンス専用のパーティションを維持管理するのが面倒くさい (普段使わないものほど陳腐化して、いざというとき役に立たない)。
initramfs だとハードディスクすら不要 (例えば PXE ブート) でメンテナンスが可能になるし、 普段 GNU/Linux OS 起動用として使ってる initramfs が、 そのまま非常用のメンテナンス環境になるため、 陳腐化する心配がない。
実は「突然死したハードディスクを復旧させる『お手軽パック』」は、 initramfs そのものだったりする。 しかも「復旧」用として作った initramfs というわけではなく、 私が普段 GNU/Linux OS を ブートするときに使っている initramfs と 全く同じものである (だからこそ ハードディスクの突然死問題 が勃発した直後にリリースできた)。

というわけで、 いいことづくめの initramfs シェル環境 (initramfs shell environment) なのだが、 「復旧お手軽パック」実行例 にもあるように、 init(8) 以前の段階で /bin/sh を実行すると 

/bin/sh: can't access tty; job control turned off
#

と表示してジョブ制御がオフになってしまう。 つまりこのシェル環境では、 プログラムを実行中に control-C (^C) を押しても止める (正確にいうと SIGINT シグナルを送る) ことができない。

ジョブ制御 (^C などでシグナルを送ること) ができない状態に陥って 初めて沸き起こる制御端末 (controlling tty) に対する感謝の念なのであるが、 initramfs が役目を終えて init(8) が起動して (GNU/Linux OS がブートして) しまうと、 喉元過ぎればなんとやらで 「can't access tty」をなんとかしようという意欲は雲散霧消し、 そのままになっていた。

制御端末になれない initramfs シェル環境に対して何十回目かの悪態をついた後、 ようやく対策を立てるべく原因を調べてみることにした。

Linuxカーネル（ドライバ）のソースを読んでみたところ、 以下の端末デバイスは制御端末に成れないのです。 興味がある人は、ソース、 drivers/char/tty_io.cのtty_open()を見てみてください。

* /dev/console -- カーネルの起動時の端末。
* /dev/tty0 -- tty1～の「Linux Virtual Terminal」のうち、現在表示している物を示す。
* /dev/tty -- 現在使っている端末を示す。
* PTYのマスター側
Linux:制御端末 から引用

initramfs シェル環境で使っている端末は /dev/console だから制御端末になれない。 だから BusyBox には /dev/console という仮想的な端末ではなく、 本物のデバイスを探すための cttyhack というプログラムが付属している。 /bin/sh を実行する代わりに cttyhack /bin/sh を実行すれば ジョブ制御ができると BusyBox のマニュアルには書いてある。

...という解説は上に引用したページをはじめ、 WWW 上のあちらこちらのページで見かけるし、 私としても当然そんなことは先刻承知で、 

/bin/sh: can't access tty; job control turned off
# tty
/dev/console
# cttyhack sh
sh: can't access tty; job control turned off
# tty
/dev/tty1
#

などと、確かに cttyhack の働きにより /dev/console ではなく /dev/tty1 を使うようになったものの、 相変わらず「can't access tty」エラーが出ているので困っているわけである。 cttyhack を使っているのにジョブ制御できないわけで、 cttyhack-- と思っていた。

前置きが長くなったが、ここからが本題である。

More...
Filed under: システム構築・運用 — hiroaki_sengoku @ 07:38
2008年8月25日

ギガビット・スイッチング・ハブ CG-SW08GTV2 が故障したと思ったら… hatena_b

自宅サイト GCD の 2台のゲートウェイ (senri と asao) の NIC が同時に link down した。 

Aug 18 10:31:30 senri [144077.315932] tg3: eth0: Link is down.
Aug 18 10:33:57 senri [144201.921009] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 18 10:33:57 senri [144201.921228] tg3: eth0: Flow control is on for TX and on for RX.

Aug 18 10:31:30 asao [894103.906436] tg3: eth0: Link is down.
Aug 18 10:33:57 asao [894253.756472] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 18 10:33:57 asao [894253.756472] tg3: eth0: Flow control is on for TX and on for RX.

この日 8/18 はたまたま早朝から出張だった (帰宅したのは翌日 8/19 23:00 近く) ので link down に気付かなかった (もちろんヘルスチェックは行なっているが自宅なのでタイムアウトは長め)。 留守中、 link down 後しばらくたつと link up (正常状態に復旧)、 という繰り返しが何度も起きたようだ。 ログから down 時間を集計してみるとこんな感じ:

link downupdown秒数
8/18 10:31:3010:33:57147
8/18 10:34:1210:47:45813
8/18 10:54:3410:54:373
8/18 18:18:0718:21:50223
8/18 18:22:3718:42:511214
8/19 15:38:1315:40:35142
8/19 15:45:0515:51:06361
8/19 16:05:5416:05:573
8/19 16:07:4816:07:502
8/19 16:08:2616:10:08102
 　
link downupdown秒数
8/19 16:10:1016:10:122
8/20 08:00:1208:02:59167
8/20 08:03:0408:07:47283
8/20 08:07:5708:09:57120
8/20 08:10:2908:22:47738
8/20 08:31:3308:31:363
8/20 08:32:3709:00:141657
8/20 12:56:0613:00:05239
8/20 13:00:2713:08:02455
8/20 13:32:5013:37:15265

3 秒で復旧することもあれば、 20分以上落ちたままのこともあり規則性がないが、 いったん link down/up すると、 down/up を何度か短時間に繰り返す傾向がある。 また次第に down する頻度が上がり、 down している時間も長くなる傾向にあった。 複数のマシンで同時に link down することから、 ハブの故障だと判断できる。 ハブは、 コレガ製 1000BASE-T/100BASE-TX/10BASE-T 8ポート スイッチングHUB CG-SW08GTV2。 2005年11月9日に購入したものなので1年の保証期間は切れているものの、 まだ3年弱しか経過しておらず自宅LAN の中では比較的新しいハブである。

ちょっと壊れるのが早すぎなんじゃないかと思いつつ、 とりあえず余っていた 100Mbps スイッチング・ハブと置き換えて急場をしのぎつつ、 秋葉原に新しいハブを買いに行った。 買ったのは同じくコレガ製の、 1000BASE-T/100BASE-TX/10BASE-T 8ポート スイッチングハブ CG-SW08GTR。 T-Zone で 3742円だった。 8 port の gigabit が 4000円以下とは、 ずいぶん安くなったものだ (標準価格は 9975円)。

というわけで故障したハブを新しいハブで置き換えて一件落着なのであるが、 3年たたずに故障し、 しかも断続的に down するという症状が腑に落ちなかったので、 壊れた CG-SW08GTV2 の筐体を開けてみた。 すると...

More...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:52
2008年7月22日

技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき hatena_b

先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。

ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで意義あることだとは思うのですが、 彼のような優秀な技術者には、 「サポート」という目的だけに捕らわれず、 もっと自由に興味の赴くまま学び、 自らのスキルを伸ばしていって欲しいと思ったのです。

OSS 関連のビジネスというと、 すぐ、 サポートでお金を稼ぐとか、 OSS 活用のコンサルティング事業とかの発想をする人が多いのですが、 誰もが思いつく事業だけに、 ビジネスモデルとしては稚拙な部類と言わざるを得ません。 高い技術力がそのまま売りにつながった前世紀ならいざ知らず、 競争が激化してビジネスモデルの巧拙が事業の成否を大きく左右する昨今、 いまだに何の「ひねり」もない「OSS サポート」に固執するのは、 いかがなものかと思うのです。

技術コンサルティング事業というと聞えはいいのですが、 要は「人月ビジネス」です。 どんなに優秀な技術者 (「ピンからキリまで」 の「ピン」ですね) であっても、 一人月 1000万円払ってくれるお客がいるはずはなく、 素人技術者 (以下「キリ」と略記) の 5～6倍の人月単価を稼げば御の字というのが実状ではないでしょうか。 だからコンサルティング事業といいつつ、 高額のソフトウェアを売り付けてライセンス料を稼ぐことのほうが、 メインの目的だったりする会社もあるわけです。

ただあいにく OSS の場合は高額のライセス料を請求するのは無理があります。 せいぜい保守料と称してわずかばかりの費用を請求するのが関の山でしょう。 だから OSS のコンサルティングというのはあまりよいビジネスモデルとは言えません。 ものすごい労力とコストをかけてピンをそろえて (お客に高いね～と言われつつ) 5倍の人月単価を設定するくらいなら、 コストをかけずにキリを大量に集めて格安な人月単価で売りさばく (いわゆる派遣ビジネス) 方が、 経済合理性にかなうというものです。

キリに成長の機会も与えずに 「若いだけが取り柄の労働力」 として派遣して使い捨てにする事業は当然非難されるべきですが、 労働時間では測りしれない価値を持つはずのピンを人月換算してしまう事業もまた、 非難されるべきではないでしょうか？ 人月ビジネスでは売上を増やすには人員を増やさざるを得ず、 売上が拡大しても決して余裕は生まれません。 いやそれどころか、 どんどん仕事を片付けてくれる優秀な技術者にどんどん仕事が集中して、 優秀な技術者ほど疲弊する、 という理不尽なことも起り得ます。

頼りにされるあまり、多くの仕事がその人に任されることになる。 できる人に、仕事が集中するのは、よくある話で、 その人は、回りの期待にこたえようとして、遅くまで残業して、 休日も出社したりする。 この状態が、一過性のものだったら良いんだけど、 慢性的なものになると、肉体も精神もぼろぼろになっていく。

ピンとキリでは生産性で何十倍～何百倍 (私は 3桁の差があると日頃から主張していますが) もの差があるのに、 わずか 5～6倍の売上の差しか出せないのは、 「儲ける仕掛け」が無いからです。 ピンの労働時間を人月換算するのではなく、 ピンの技術なしには実現できないような (つまり競合他社には構築不可能な) 儲ける仕掛けを編み出して売上を増幅し、 それによって生じた余裕でピンの仕事量を思いきって抑えることによってこそ、 その優秀さに報いることができるのだと思います。

そうすれば仕事の負荷が軽くなったピンは、 ピンならではの新しい価値を産み出すことに注力できます。 新しい事業のシーズを産み出す研究開発でもいいですし、 あるいは OSS から恩恵を受けている企業であれば、 ピンの人が (勤務時間中も) OSS コミュニティで活躍することを奨励することによって、 OSS の世界に「恩返し」することもできます。

前世紀は技術力が高ければ儲ける仕掛けを誰でも作ることができた時代でした。 つまり優れたソフトウェアなら結構な値段で売ることができたのです。 マーケティングがしっかりしていれば、 開発費を大幅に上回る売上も達成できました。 典型例はマイクロソフトですね。 ピンが作ったソフトウェアを何億本も売ったわけで、 ピンの労働力が人月単価の何万倍もの価値を生んだことになります。 その後 OSS の発展と普及により、 ソフトウェアを売るだけというビジネスモデルは行き詰まりました。 今ほど新しいビジネスモデルが重要となった時代はないと言えるでしょう。

さらにいうと、 技術者が優秀であればあるほど、 その「シーズ」は一般人の「ニーズ」からかけ離れていく、 という難しさもあります。 例えば、 優れたカーネル・ハッカーの技術を、 真に必要とする人が世の中にどれだけいるのか？という問題です。 技術の素人である大多数の消費者にとっては、 小難しい技術のことなんか全く分からないし興味もありません。 高い技術力が売れるどころか、 逆にその高度さが「需要」を減らしてしまう原因となりかねません。

高度な「シーズ」と一般の「ニーズ」を結び付けるには、 高度なビジネスモデルが求められるわけで、 技術者がハッキングの合間に思いつくようなビジネスモデルではお話になりません。 優れたカーネル・ハッカーが、 四六時中寝る間も惜しんでカーネル・ソースのことばかり考えているのと同様、 優れたビジネスモデルを考え出すビジネスの戦略家 (以下、戦略家と略記) は、 四六時中寝る間も惜しんで儲ける仕掛けのことばかり考えています。 素人考えのビジネスモデルが通用すると思うのは、 C言語を覚えたばかりの素人技術者が、 カーネル・デバッグに挑もうとするくらい無謀なことでしょう。

当たり前のことですが餅は餅屋であり、 技術のことは技術者に任せるべきですし、 儲ける仕掛けのことは戦略家に任せるべきです。 優秀な技術者は、優秀であればあるほど、 優秀な戦略家と組むべきなのです。 ところが世の中の大半の会社はそうなっていません。

超優秀なハッカーは互いに認め合う技術者同士ばかりで集まり、 ビジネスモデルの重要性を軽視してしまいます。 ビジネスモデルなんて自分たちだけでも考え出せると思ってしまい、 社員のほとんどが技術者、なんて会社になってしまいます。 実地に売り歩く営業の必要性にはさすがに気付いて営業担当者を数人雇ったり、 あるいは社長が自ら売り歩いたりするようになるものの、 儲ける仕掛けの構築には無頓着で、 旧態依然としたビジネスモデルのままだったりします。 そのため事業を拡大しても余裕が生まれず、 ちょっとした外部環境の変化でたちまち立ち行かなくなる恐れがあります。

逆に、優れた儲ける仕掛けを生み出すことができる有能な戦略家は、 一日24時間、儲ける仕掛けを考え出すことばかりに夢中で、 その仕掛けを下支えする高度な技術のことは軽視してしまいます。 技術なんて下請けをいじめればなんとでもなると考えてしまい、 決して技術者をパートナーとは考えません。 技術者を、売るものを作ってくれる便利な人と考えてくれればまだマシなほうで、 下手するとコストばかりかかる必要悪くらいの勢いで、 原価削減の手法をあれこれ考え始めたりします。 しかし技術を軽視したツケは、いろいろな形で払うことになるでしょう。 事業を下支えする技術が脆弱であれば事業の継続性が危ぶまれますし、 技術面で他社との差別化が行なえずに他社の参入を許してしまうかも知れません。

これでは技術者と戦略家の利害はどんどん対立してしまいます。 この悪循環をくい止める唯一の方法は、 技術者が ──特に、優秀であればあるほど── ビジネスモデルの良し悪しを嗅ぎ分ける嗅覚を持つことです。 誰が優れた「儲ける仕掛け」を生み出すことができるのか、 技術者が判断できるようになれば、 人月ビジネスから抜け出す見込みのない会社を見限ることが できるようになるでしょう。

対称性を考慮すれば、 戦略家が技術の優劣を嗅ぎ分ける嗅覚を持つことによっても、 利害対立の悪循環をくい止めることが (理論上は) 可能ですが、 高度に専門化・細分化してしまった技術を、 技術者ではない戦略家に (優劣を判断できるほどに) 理解してもらうことは現実的とは思えません。 戦略家と技術者が協力しあうには、 まず技術者の側が相手を理解する必要があるのです。

そうすれば、 より優れた戦略家のもとに優秀な技術者が集まるようになり、 戦略家と技術者の利害が一致する方向へ淘汰圧が働きます。 すなわち、 戦略家が優秀な技術者と組むことにより、 技術者には (従来想像していた以上に) 優劣の差があって、 どのレベルの技術者と組むかが事業の成否を大きく左右する、 ということが明らかになってくるはずです。

優秀な技術者が事業にどれだけ貢献し得るか実感できれば、 優秀な技術者に対して、その能力に見合った待遇 ──報酬はもちろんですが、 仕事量を減らして OSS コミュニティへの貢献を推奨するなど── を提供すれば優秀な技術者が集めやすくなる、 ということも実感できるようになることでしょう。

技術者の側からすると信じられないことだとは思いますが、 ピンもキリもそんなに大した差ではない (せいぜい 5～6倍) と、 技術者でない人の大半は感じています。 縁遠い技術になればなるほどこの傾向は強まるようで、 例えばカーネル技術者の中でもメンテナとデバイス・ドライバの開発者とでは、 (技術者の目から見れば) だいぶレベルの差がありますが、 (技術者以外の人で) その能力差を実感できる人は皆無でしょう。

技術者の待遇向上の鍵は、 技術者がビジネスモデルの良し悪しにもっと敏感になること、 すなわち会社における技術職以外の職種の役割についてもっと理解し、 技術職以外の人達についても、 その能力の優劣を見分けられるようになることにこそ、 あるのだと思います。

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 07:46
2008年7月14日

なぜ DELL PowerEdge SC440 は ICH7R の Watchdog Timer 機能を利用できないのか？

DELL PowerEdge SC440 は、 インテル 82801GR I/O コントローラー・ハブ (ICH7R) を使っている。 ところが、ICH7 にあるはずの ウォッチドッグ・タイマ (Watchdog Timer) 機能が利用できない。 例えば Linux だとブート時に 「reboot disabled by hardware」すなわち 「ハードウェアによってリブートが禁止されている」とカーネル・ログに出力される: 

iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
iTCO_wdt: failed to reset NO_REBOOT flag, reboot disabled by hardware
iTCO_wdt: No card detected

この「reboot disabled by hardware」とは何なのかを調べてみると、 Intel I/O Controller Hub 7 (ICH7) Family Datasheet の 78ページ、 Table 2-23. Functional Strap Definitions (Sheet 3 of 3) に、

SignalUsageWhen SampledComment
SPKRNo RebootRising Edge of PWROK The signal has a weak internal pull-down. If the signal is sampled high, this indicates that the system is strapped to the "No Reboot" mode (ICH7 will disable the TCO Timer system reboot feature). The status of this strap is readable via the NO REBOOT bit (Chipset Config Registers:Offset 3410h:bit 5).

と書いてある。 つまり ICH7 の SPKR 端子 (Ball# A19) はスピーカ出力なのであるが、 入力端子としても使われていて、 PWROK 入力端子 (Ball# AA4) の立ち上がりエッジ時 (すなわち電源投入時) において SPKR 端子が H レベルであれば、 「No Reboot」モードに固定される。

「No Reboot」モードというのは、 TCO タイマ (つまり Watchdog Timer) による再起動を行なわないモードで、 通常はソフトウェアでこのモードの設定/解除が可能なのであるが、 SPKR 端子によって「固定される」と No Reboot モードのまま変更できなくなる。

具体的には、 「No Reboot」モードの設定/解除は、 ICH7 の「NO REBOOT bit」に 1/0 を書込むことによって行ない、 逆にこの「NO REBOOT bit」を読むことによって現在のモードを確認できる。 Linux カーネルの drivers/watchdog/iTCO_wdt.c に、 このビットを解除し、解除できたか確認するコードがある: 

static int iTCO_wdt_unset_NO_REBOOT_bit(void)
{
        ...
        /* Unset the NO_REBOOT bit: this enables reboots */
        if (iTCO_wdt_private.iTCO_version == 2) {
                val32 = readl(iTCO_wdt_private.gcs);
                val32 &= 0xffffffdf;
                writel(val32, iTCO_wdt_private.gcs);

                val32 = readl(iTCO_wdt_private.gcs);
                if (val32 & 0x00000020)
                        ret = -EIO;
        ...
        return ret; /* returns: 0 = OK, -EIO = Error */
}

この iTCO_wdt_unset_NO_REBOOT_bit 関数は、 GCS (General Control and Status Register, オフセット 0x3410) のビット5 に 0 を書込むことによって No Reboot モードの解除を試み、 続いてこのビットを読んで正しく 0 に変わっているか確認し、 確認結果を返す。 つまりこの関数が正常に 0 を返せば、 ICH7 の Watchdog Timer が利用可能であることを示し、 -EIO を返せば、 (No Reboot モード固定なので) 利用不可能であることを示す。

というわけで、 DELL PowerEdge SC440 で Intel TCO Watchdog Timer が利用できない理由は、 電源投入時に SPKR 端子に電圧がかかってしまっていて、 No Reboot モード固定になっているためだろう。 SPKR 端子は内部的にプルダウン (20kΩ) されているので、 SPKR 端子につながっているスピーカを切り離せば SPKR 端子は L レベルになり、 Watchdog Timer が利用できるようになるはず。

More...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:45
2008年7月11日

外国のメーカに修理/交換してもらうとき課税される関税・消費税を減免する方法 hatena_b

ハードディスクが故障したので、RMA 手続きを行なった上でメーカへ送り返したら、わずか4日で代替品が返ってきた (6月28日)。 RMA++ と思っていたら、 10日後の 7月8日にシンガポールのフェデラル・エクスプレスから 「請求書在中」と書かれた AIR MAIL な封書が送られて来た。 え～ せっかく RMA を誉め称えるブログを書いたのに、 今になって何か追加で請求されるとわ... orz と、 暗澹たる気持ちで開封してみると...

どきどきしながら「請求書 INVOICE」と書かれた一枚目の書類に目を通すと、 請求額は 1000円。 そんなに高額の請求ではなかったので一安心。 内訳を見ると、

Other Charges　 消費税／付加価値税(Consumption Tax/VAT) 500
Other Charges　 関税・消費税特別手数料(D/T Advancement Fee)　 500
合計(Total)　1,000

関税？ 日本って工業製品に対して関税なんてかけていたっけ？ と思いつつ
二枚目の「輸入許可通知書」に目を通すと、

税科目税額合計個数
D 関税￥00
F 消費税￥4001
A 地方消費税￥1001

なるほど、 メーカが申告した価格 (CIF) $108.00 に対して約 5% の消費税がかかる、 ということで納税額が 500円なのか。 でも「関税・消費税特別手数料」って何なのだろう？ 少なくともこの「輸入許可通知書」には「特別手数料」の文字は見当たらない。

まあ高々 1000円だから払っちゃおうか、という考えが頭をよぎる。 ご丁寧にコンビニ払いの用紙まで添付されている。 コンビニ払いか銀行振込を選択可能なようだ。

消費税ってのはいわゆる付加価値税のことである (なぜ VAT (= 付加価値税) という世界的に一般的な名称ではなく、 「消費税」という聞きなれない名称にしたのやら...)。 物品に価値が加わったときにその増分に対して一定割合 (現在は 5%) を納税するのが趣旨であるが、 故障したハードディスクを交換したことが「付加価値」に該当するのだろうか？

確かに私にとっては、 故障したハードディスクは価値ゼロで、 交換してもらったハードディスクは 13000円 (現時点での WD10EACS の小売価格) くらいの価値があるから一見価値が増えたように見えるが、 より厳密に考えると「故障したハードディスク」には「RMA 保証」がついていた (だからこそ交換してもらうことができた) ので、 13000円の価値があったと言ってもよい。

そもそも消費税は、このハードディスクを買ったときに支払っている。 当時は 28140円もしたから、なんと 1340円 (本体価格 26800円の 5%) も、 消費税を払っているわけである。 この上、さらに 500円も消費税を払わされてはかなわない。 これは同一物に対する二重課税ではないのか～っ。 もんもんと考えているうちに、だんだんハラが立ってきた (^^;)。

というわけで、 なんとかこの理不尽な課税を回避できないか試みることにした。 もちろん、たかが 500円の課税であるので回避できたところで、 かけた労力に見合うわけはないのだが、 まあなにごとも経験である。 軽減できる税金は最大 500円であっても、 軽減交渉という経験はプライスレス。

More...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 10:25
2008年7月3日

Western Digital RMA チームから届いた文字化けメールを解読してみた hatena_b

「故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた」で書いたように、 RMA 手続きを行なった上で Western Digital へ故障したハードディスク ドライブ (以下 HDD と略記) を送ったら、 激しく文字化けしたメールが送られてきた。

あとは HDD が送られてくるのを のんびり待つだけと思っていたら、 わずか一日後 6/26 18:44 に Western Digital からメールが来た。 しかし文字化けがひどくて読めない。 最初は何語で書いてあるかすら判然としなかったのだが、 どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に なにか問題があったようだ。 例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。 置換が規則的でないので、 暗号解読よろしく一文字一文字置き換え規則を推測していくしかない。

文面を再現するのに時間がかかりそうだなぁ～と思っている間に、 交換品の HDD が届いてしまったので、 「暗号」解読するモチベーションを失ってしまっていたのだが、

Posted by 通りすがり 2008年07月02日 00:36
結局、メールにはなんて書いてあったのでしょうか？

というコメントを頂いてしまったので、 暗号解読してみることにした。

以下、Western Digital からの文字化けメールを全文引用 (一部伏字) する: 

From: "Western Digital RMA" <noreply@wdc.com>
To: <sengoku@gcd.org>
Date: Thu, 26 Jun 2008 02:44:25 -0700
MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-OriginalArrivalTime: 26 Jun 2008 09:44:25.0728 (UTC) FILETIME=[3861F800:01C8D771]

HIROAKI SENGOKU -l,=D6=81A

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
,=CCfXfe=81[f^fX,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B  RMA
,=C9S=D6,=B7,=E9,=A8-=E2,=A2=8D?,=ED,=B9,=CD,=B1,=CCf=81=81[f<,=C9.=D4=90=
M,=B5,=C4,=AD,=BE,=B3,=A2=81B
=8F=EE.=F1,=AA=90=B3,=B5,=A2=8F=EA=8D?=81A,=B1,=CC"dZqf=81=81[f<,=C9,=CD.=
=D4=90M,=B5,=C8,=A2,=C5,=AD,=BE,=B3,=A2=81B


RMA "=D4=8D?=81F 8083XXXX

--------------------------------------------------------------

O=F0S=B7fhf?fCfu,=F0 5=81`7 ?c<=C6"=FA'?,=C9"=AD'-,=B5,=DC,=B7=81B

^=C8?=BA,=CCfhf?fCfu,=F0 Western Digital =
,=CDZ=F3-=CC,=B5,=DC,=B5,=BD=81F

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
Z=F3-=CC"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJxxxxxxx     WD10EACS-00ZJB0      6/25/2008

--------------------------------------------------------------

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
"=AD'-=8F=F3<=B5,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B

-A'-<=C6Z=D2,=CCfVfXfef?,=CC=8DX=90V,=C91?c<=C6"=FA,=AA,=A9,=A9,=E8=81A,=BB=
,=CCO=E3"=AD'-'=C7=90=D5"=D4=8D?,=AA-LO=F8,=C9,=C8,=E8,=DC,=B7,=CC,=C5=81=
A,=B2-=B9=8F=B3,=AD,=BE,=B3,=A2=81B

O=F0S=B7fhf?fCfu,=CC'-.t=90=E6=81F

     HIROAKI SENGOKU
     XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
     KAWASAKI, Japan 213-XXXX
     JAPAN

"z'-<=C6Z=D2=81F     Fedex
"z'-'=C7=90=D5"=D4=8D?=81F XXXXXXXXXXXX

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
"=AD'-"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJXXXXXXX     WD10EACS-32ZJB0      6/26/2008

--------------------------------------------------------------

S=D6~AfSf"fN=81F
RMAZ=E8=8F?ZwZ=A6=8F=EE.=F1,=CC?{--/^=F3=8D=FC
  - =
http://websupport.wdc.com/rd.asp?t=3D102&l=3Djp&p=3Dm&r=3D8083XXXX&f=3De

"=AD'-,=C6=8D=AB.=EF,=CC=8F=EE.=F1
  - http://websupport.wdc.com/rd.asp?t=3D103&l=3Djp&p=3Drp

RMAfXfe=81[f^fX,=CC?{--
  - =
http://websupport.wdc.com/rd.asp?t=3D104&l=3Djp&p=3Dv&r=3D8083XXXX&z=3D21=
3-XXXX

Western Digital fTf|=81[fgfz=81[f?fy=81[fW
  - http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

^=C8=8F=E3=81A
WD RMA f`=81[f?
http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

ヘッダに「quoted-printable」と書いてあるとおり、 quoted-printable エンコーディングを行なったのだろうが、 のっけから「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となっていて、 一体何語なんだ？と思わせる始まり方である。

ちなみに quoted-printable というのは 8bit データを、 「印字可能 (printable)」つまり 7bit の英数字・記号だけで表現するための方法 (エンコーディング) で、 印字可能でない 8bit データは 16進数で表わして前に「=」をつける (「=」自身は「=3D」で表現する)。 例えば「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」は、 16進数で書くと 「5E C8 3F BA 2C C9 2E 5C 5A A6 2C B3 2C EA 2C BD」 という 8bit データ列を意味する。

腕に覚えのあるかたは、解答を見ずに解読を試みてはいかがだろうか？

More...
Filed under: ハードウェアの認識と制御,プログラミングと開発環境 — hiroaki_sengoku @ 07:36
2008年6月30日

故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた hatena_b

廉価な 1TB SATA ハードディスク ドライブ (以下 HDD と略記) として有名な、 Western Digital 製 WD Caviar GP WD10EACS は、 省電力・静音を謳っている。 環境に優しいのは結構なことだが、 その実現方法:

IntelliPower - きめ細かく調整された　ディスク回転速度　転送速度　及びキャッシュサイズの調和により飛躍的な省電力と確実なパフォーマンスを提供します
IntelliPark - 風損を減らす為のアイドル時の自動ヘッド退避によりドライブは消費電力を低減する
IntelliSeek - 電力消費量、ノイズおよび振動を低減させるために、最適なシーク速度を計算します。

のうち、特に「アイドル時の自動ヘッド退避」というのがいただけない。 ヘッドを退避すれば空気抵抗が減ってモーターの負荷が減るから 低消費電力が実現できる (実際、アイドル時の消費電力は際立って低い)、 ということなのだろうが、 常時使用する PC (特にサーバ) だと「自動ヘッド退避」の回数が とんでもないことになる。 SMART 情報を見ると: 

# smartctl -a /dev/sdb
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD10EACS-00ZJB0
Serial Number:    WD-WCASJxxxxxxx
Firmware Version: 01.01B01
User Capacity:    1,000,204,886,016 bytes
        ...
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  RAW_VALUE
        ...
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always   3826
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always   24
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always   19
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always   11327
        ...

わずか 3826 時間 (159日、約5ヶ月) で、 実に 11327回もの自動ヘッド退避が行なわれている。

この異常な回数の自動ヘッド退避が原因かどうかは分からないが、 この 1TB HDD は 2007年11月30日に 28140円で購入してから わずか 5ヶ月余りの 2008年5月2日に故障した。 こんなに早く故障するとは思ってもいなかったので、 T-Zone の延長保証 (200円の追加で通常3ヶ月保証を最長6ヵ月保証) を掛けていなかった。 6ヶ月ではどーせ故障しないから保証を掛けるだけ無駄と判断したのだった (ついでに言うと、6ヶ月では故障しないだろうと高を括っていて、 まだ一部バックアップしていないデータがあったので、 復旧にえらく手間取った。1TB もあると復旧も一筋縄にはいかない)。

運が悪かったとあきらめるしかない (二度とグリーン・パワー・ハードディスクは買わないぞっ！) と思っていたら、 RMA (Return Merchandise Authorization, 返却承認) という メーカによる保証があるということを同僚から教えてもらった (社内IRC で HDD の故障を嘆いていたら、哀れに思って教えてくれたらしい ^^;)。 RMA番号を取得した上で故障品をメーカへ送ると、 代替品を送り返してくれる、という保証。

ステップ3
製品が故障していて交換が必要と判断された場合、 RMA タイプを下から選択して RMA（返却承認）手続きを開始してください。

Standard Replacement
お客様から故障製品を受け取ったあとに代替製品を送付します。 RMA が作成されてから30日以内に故障製品を返送してください。

Western Digital の エンドユーザー向け保証確認ページで、 故障した HDD のシリアル番号を入力してみると、

交換に適合するドライブ

おお、「限定保証期間内」と表示された。 有効期間は再来年の 12月まで、三年間もあるらしい。 もしかしたら交換してもらえるかも？と期待が膨らむ。 といっても RMA なんて今まであることすら知らなかったわけで、 どうやって故障品を送ったらいいのか見当もつかない。

More...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 08:12
2008年6月13日

HP ProLiant ML115 で、IPMI ハードウェア・ウォッチドッグ・タイマー ipmi_watchdog を使ってみる hatena_b

「ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ」へのリンクを張って頂いた:

HP ML115 には IPMI (Intelligent Platform Management Interface) という 便利なインターフェイスが内蔵されています。 ... (中略) ... IPMI 機能の一つ、watchdog timer 機能を利用してみようと思います。
... (中略) ...
watchdog timer の動作に関しては、 こちらの方が 詳しいので興味ある方はご確認ください。 さて、どうやって watchdog を起こすかというと、 先ほどインストールしたドライバと ipmitool を利用します。

うっ、ML115 の IPMI には、 ウォッチドッグ・タイマーの機能もあったのか (何たる不覚 orz)。 今まで ML115 では、 ソフトウェア版ウォッチドッグ (softdog.ko モジュール) を 使っていたので、 速攻で IPMI のハードウェア・ウォッチドッグ・タイマーに乗り換えてみた。

Linux カーネル・ソースの Documentation/IPMI.txt を見ると、 

A watchdog timer is provided that implements the Linux-standard
watchdog timer interface.  It has three module parameters that can be
used to control it:

  modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
      preaction=<preaction type> preop=<preop type> start_now=x
      nowayout=x ifnum_to_use=n

ブート時に「modprobe ipmi_watchdog」を実行するだけで使えそうである。 タイムアウトを「timeout=<t>」で指定できるが、 私のマシンでは「蹴り代行」デーモンを走らせている (「ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ」参照) ので、 デフォルトのタイムアウトである 10 秒のままでも問題無い。

「action=<action type>」には、タイムアウト時の挙動を指定する。 「reset」(ハードウェア・リセット)、 「power_cycle」(電源OFF してから電源ON)、 「power_off」(電源OFF) を指定できるが、 デフォルトは「reset」なので、これも指定しなくて構わない。

「nowayout=0」を指定すると、 /dev/watchdog をクローズ時にウォッチドッグ・タイマーが止まる。 ウォッチドッグ・タイマーは、 いったん動き出したら何が起ろうと止めるべきではないと思うし、 デフォルトは「nowayout=1」(つまりクローズしても止まらない) なので、 これも指定する必要はない。

というわけで、ipmi_watchdog を使ってみる: 

# modprobe ipmi_watchdog
# echo @ > /dev/watchdog

/dev/watchdog が存在しない場合は、「mknod /dev/watchdog c 10 130」を実行して、 /dev/watchdog を作成しておく。

10秒後、勝手にリセットがかかった (めでたしめでたし)。 リセットを防ぐには 10秒以内に /dev/watchdog へ書込み続けなければならない。 例えば、 

#!/bin/sh
while true; do
    echo @ > /dev/watchdog
    sleep 5
done

といったスクリプトを走らせ続ける。 このスクリプトだとシンプルすぎて、 システムに異常が起きたときも動き続けてしまう (だからタイムアウトが発生しない) 恐れがあるので、 while ループの中にシステム異常を検知する (異常が起きたときは 10秒以上時間がかかる) ようなコマンドを入れておくとよい。

何かの都合でタイマーを止めたい (止めるべきではないが) ときは、 「V」を /dev/watchdog に書込む。

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 08:17
2008年5月12日

x86_64 な Linux カーネルで i386 プログラムを実行するときの注意点 ── ivtv ドライバの ioctl インタフェース hatena_b

64bit Linux (x86_64 別名 amd64) は、 CONFIG_IA32_EMULATION を有効にしておくことにより、 32bit プログラム (i386 別名 ia32) を走らせることができる。 したがって 64bit へ移行する際は、 全プログラムを一度に 64bit 化する必要はなく、 まずカーネルだけ 64bit 化しておいて、 各プログラムは (バージョンアップの機会などに) 徐々に 64bit 化していけばよい。 ただし 32bit プログラムがカーネルの機能を呼び出す場合は、 各機能それぞれが 32bit プログラムからの呼び出しに対応していることが前提となる。

32bit プログラムからの呼び出しに対応するといっても、 基本的には引数の型を変換するだけである。 x86_64 の整数データモデルは LP64、 つまり long int 型とポインタ型が 64bit で (引数の型として多用される) int型は 32bit のままなので、 変換が不要なケースも多い。

例えば ioctl システムコールはファイル・ディスクリプタ (file descriptor, 以下 fd と略記) ごとに カーネルが実行すべき機能は変わってくるわけで、 その実装は各デバイス・ドライバに委ねられることが多い。 したがって 32bit プログラムからの ioctl 呼び出しに応えられるか否かは、 各ドライバが 32bit 対応しているか否かに依存する。 不幸にしてドライバが対応していない場合は、 

ioctl32(tv:11028): Unknown cmd fd(5) cmd(40045613){t:'V';sz:4} arg(081ec8b4) on /dev/video0

などといったカーネル・メッセージ (dmesg) が出力される。 このメッセージは、 カーネル・ソース中 fs/compat_ioctl.c の compat_ioctl_error が出力している: 

static void compat_ioctl_error(struct file *filp, unsigned int fd,
    unsigned int cmd, unsigned long arg)
{
    ...
    compat_printk("ioctl32(%s:%d): Unknown cmd fd(%d) "
            "cmd(%08x){t:%s;sz:%u} arg(%08x) on %s\n",
            current->comm, current->pid,
            (int)fd, (unsigned int)cmd, buf,
            (cmd >> _IOC_SIZESHIFT) & _IOC_SIZEMASK,
            (unsigned int)arg, fn);
    ...
}

fs/compat_ioctl.c は 32bit 版 ioctl システムコールを実装していて、 32bit プログラムが ioctl システムコールを呼び出すと、 この中の compat_sys_ioctl ルーチンが呼ばれる: 

asmlinkage long compat_sys_ioctl(unsigned int fd, unsigned int cmd,
                unsigned long arg)
{
    ...
        if (filp->f_op && filp->f_op->compat_ioctl) {
            error = filp->f_op->compat_ioctl(filp, cmd, arg);
            if (error != -ENOIOCTLCMD)
                goto out_fput;
        }
    ...
            compat_ioctl_error(filp, fd, cmd, arg);
    ...
 out_fput:
    fput_light(filp, fput_needed);
 out:
    return error;
}

つまりドライバ側で file 構造体の compat_ioctl 関数ポインタ (filp->f_op->compat_ioctl) が定義されていればそれが呼ばれ、 未定義ならば上記のような「Unknown cmd」エラーが出力される。

ちなみにこのエラーメッセージの「tv:11028」は、 ioctl を呼び出した 32bit プロセスの名前 (コマンド名) とプロセスID であり、 fd(5), cmd(40045613), arg(081ec8b4) は、 それぞれ ioctl システムコールの第一 (つまり fd 番号)、 第二 (ioctl リクエスト番号)、第三引数 (ioctl リクエストの引数) であり、 最後の on /dev/video0 は (第一引数の) fd 番号に対応するファイルのパス名である。

そして、この tv コマンドは 「ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画」で紹介した perl スクリプト であり、 その名称から推測できるとおりテレビ録画を行なうためのスクリプトである。

このスクリプトでは Video::ivtv モジュールを利用していて、 このモジュールが /dev/video0 つまり TV キャプチャ・デバイスに対して、 ioctl システムコールを呼び出している。 上記エラーはスクリプト中 $IvTV->stopEncoding($TunerFD); を実行したときに発生した。

その名称から推測できる通り、 stopEncoding メソッドはキャプチャ・デバイスに対して エンコーディングの停止を指示するためのもので、 内部で ioctl(fd, VIDIOC_STREAMOFF) などと ioctl 呼び出しを行なっている。 VIDIOC_STREAMOFF は videodev2.h にて、 

#define VIDIOC_STREAMOFF    _IOW  ('V', 19, int)

と定義されていて、このマクロを展開すると 40045613 (16進) となり、 上記カーネル・メッセージ「cmd(40045613)」と一致する。

というわけで、(少なくとも Linux 2.6.24.7 に含まれる) ivtv ドライバは、 残念ながら 32bit 対応していないことが分かった。 もちろん x86_64 なカーネルではなく、 i386 カーネルを使えば 32bit プログラムから ivtv ドライバを使うことができるが、 x86_64 なカーネルでは、32bit プログラムからの ioctl システムコールを 64bit カーネルが受付けられる形に変換できないということだ。

とはいうものの、 32bit だろうが 64bit だろうが ioctl のインタフェースに大した変わりはないはずだ。 どうして ivtv ドライバは 32bit 呼び出しをサポートしていないのだろう？ と 思いながらドライバのソースを眺めていると... drivers/media/video/compat_ioctl32.c を見つけた。 名前からしていかにも 32bit 版 ioctl のように見える。

compat_ioctl32.c の中の v4l_compat_ioctl32 ルーチンは、 32bit な ioctl 呼び出しを受付けて 引数を 64bit へ変換し (といっても int 型はどちらも 32bit だが)、 本来の (64bit な) ioctl を呼び出し直す仕組みになっている。 なぜ ivtv ドライバは、このルーチンを利用していないのだろうか。 

static int do_video_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
    ...
    /* First, convert the command. */
    switch(cmd) {
        ...
    case VIDIOC_STREAMOFF32: realcmd = cmd = VIDIOC_STREAMOFF; break;
    };

    switch(cmd) {
        ...
    case VIDIOC_STREAMOFF:
        err = get_user(karg.vx, (u32 __user *)up);
        compatible_arg = 1;
        break;
        ...
    };
    if(err)
        goto out;

    if(compatible_arg)
        err = native_ioctl(file, realcmd, (unsigned long)up);
    else {
        mm_segment_t old_fs = get_fs();

        set_fs(KERNEL_DS);
        err = native_ioctl(file, realcmd, (unsigned long) &karg);
        set_fs(old_fs);
    }
    ...
    return err;
}

long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg)
{
    ...
        ret = do_video_ioctl(file, cmd, arg);
        break;
    ...
    return ret;
}

ざっと見た感じ、 ivtv ドライバからこの v4l_compat_ioctl32 ルーチンを呼んでも 特に問題は無いように思われる。

そこで、ivtv ドライバの file 構造体 (の中の file_operations 構造体) の compat_ioctl 関数ポインタに、 v4l_compat_ioctl32 を設定してみた。 

--- linux-2.6.24.5.org/drivers/media/video/ivtv/ivtv-streams.c        2008-01-25 07:58:37.000000000 +0900
+++ linux-2.6.24.5/drivers/media/video/ivtv/ivtv-streams.c        2008-05-04 09:10:07.581416212 +0900
@@ -49,6 +49,7 @@
       .write = ivtv_v4l2_write,
       .open = ivtv_v4l2_open,
       .ioctl = ivtv_v4l2_ioctl,
+      .compat_ioctl = v4l_compat_ioctl32,
       .release = ivtv_v4l2_close,
       .poll = ivtv_v4l2_enc_poll,
 };
@@ -59,6 +60,7 @@
       .write = ivtv_v4l2_write,
       .open = ivtv_v4l2_open,
       .ioctl = ivtv_v4l2_ioctl,
+      .compat_ioctl = v4l_compat_ioctl32,
       .release = ivtv_v4l2_close,
       .poll = ivtv_v4l2_dec_poll,
 };

このパッチをあてることにより、 x86_64 なカーネル上で i386 な Video::ivtv モジュールを使って、 ビデオキャプチャ・カード GV-MVP/RX2W を コントロールすることができるようになった。 一週間ほど使ってみた (多数の TV 番組を予約録画した) が、 今のところ問題は起きていない。

Filed under: ハードウェアの認識と制御,プログラミングと開発環境 — hiroaki_sengoku @ 09:12
2008年4月23日

学生のうちに身につけて欲しい、たった一つの能力 hatena_b

母校の教壇に立ちました。

20年前に学んだ教室 (私が情報工学科で学んだのは 1987年～1990年) で、 20歳年下の後輩に対して行なった、 私にとって初めての授業体験でした。 勉強会やセミナーで講師をしたり、 学会で発表したりは何度もあるのですが、 授業というのは、 また趣きが異なりますね。 2コマ (約三時間) 自由に話してよい、 ということだったので、 そんなに長時間は話がもたないんじゃないかなぁ、 と少々不安を感じながら臨んだのですが、 幸い多くの質問を頂けて、 気づいたら 30分ほど時間を超過していました。

聞き手の学生さん達は現在 4回生で、 そのほとんどは大学院に進学予定ということだったので、 「学生のうちに身につけて欲しい、たった一つの能力」 というテーマでお話しました。 もちろん、「たった一つ」だけだと 3時間も話を引っ張れないので (^^;)、 私が卒業してから現在までの 16年間の社会人生活で学んだことの中で、 一番重要と思うことを三つ挙げてお話したのですが、 三つもあると覚えてられないでしょうから、 ということで「たった一つ」を強調したのでした。 それは、

質問すること

です。

産業界(特に IT 業界) が大学教育に求めること、 というと「コミュニケーション能力」なんかが 筆頭に挙がってしまうことも多い今日このごろですが、 「みんなと仲良くできる」だけでいいのは小学生までで、 社会で活躍していく上で本当に必要な能力といえば、 間違いなく「考える力」でしょう。

で、どうやって考える力を伸ばしていくかですが、 教科書を読んだり問題集を解くだけで身につくわけもなく、 いろんな人の考えを見聞きしながら自分なりに考えてみて、 次第に考える力が身についていくものだと思います。 だから、 出会った人それぞれから、 どれだけその人の「考え方」を吸収できるかが、 一生の間にどれだけ考える力を身につけられるかを左右することになるでしょう。

もちろん、より多くの人に出会うように努めれば、 より多くの人の考え方を参考にできるわけで、 だからこそ「コミュニケーション能力」が重要と主張する人もいるのでしょうが、 スゴイ人に出会えても、 その人から学べなければ折角の機会も生かせません。 優れた人からどれだけ多くのものを引き出せるか、 すなわち臆せずどんどん質問できるかこそが、 考える力を伸ばす最大の原動力になるのだと思います (もちろん質問する能力も一種のコミュニケーション能力ですが、 「コミュニケーション能力が重要」と言ってしまうと範囲が広すぎて、 焦点がぼやけてしまいます)。

例えば、講演会等で、質疑応答の時間になった時、誰も質問しなくって、 大きな会場が静まり返る、という状況はよくありますよね？ その静寂を打ち破って質問できるでしょうか？ ほとんどの人は、たとえ質問したいことがあっても、 なかなか声を出せないんじゃないでしょうか？
私が個人的に尊敬している人って、 ほとんど例外なくそういう場でも臆することなく質問できる人なんですよね。 「分からない」と言える勇気を持つことと、スキルアップできること、 との間には強い相関があるように思えてなりません。

というわけで、 今日の私との「出会い」を最大限生かすべく、 講演を途中で遮っても構わないので、 (空気を読まずに) 遠慮無く質問してください、 と話してから本題へ移りました。 まあ、私との出会いが 大した足しにならなかったとしても、 恥ずかしがらずに質問する練習だけでも 2コマの授業時間を費やす価値は充分にあると思います。 「出会い」は今後もたくさんあるでしょうから。

ちなみに、「重要と思うこと三つ」の残り二つは、

技術者の地位を向上させるには、 技術者以外の視点にも立ってみて、 技術者自身が視野を広げていかなければならない

と、

これから社会に出ていく学生さん達が最優先で取組むべきことは、 会社と対等に渡り合える実力を身につけるために、 いま何をすべきか考えることでしょう。 そんな実力を身につけることは自分には永遠にムリと思う人がいるかもしれませんが、 ムリと思えば思うほど実現は遠退きます。

です。

授業で使ったスライドを PDF 化したもの と、
FlashPaper で Flash 化したもの ↓ を公開します。

More...
Filed under: 元CTO の日記,技術者の成長 — hiroaki_sengoku @ 06:56
2008年4月15日

ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画 hatena_b

ついに Linux 2.6.24 で I-O DATA 製 ハードウェア MPEG-2 エンコーダ搭載TVキャプチャボード GV-MVP/RX2W (2006年7月5日生産終了) が標準カーネルのままでテレビ視聴が可能になった。 もはやカーネルのバージョンを上げるたびにパッチを当て直す必要はない。 仕様が公開されていないハードウェアを解析してドライバを開発し、 それを標準カーネルにマージすべく働き掛けた方々の努力に敬意を表したい。

この TVキャプチャボードのおかげで、 私はリアルタイムでテレビを視聴する習慣を無くすことができた。 録画したものを見れば「飛ばし読み」や「斜め読み」が可能だし、 1TB のディスクに録りだめしておいて優先順位をつけて見ることもできる。 ニュースやスポーツ以外であれば放送日に見る必要はそもそもないし、 下らないと判明した時点で視聴を打ち切って 別の録画した番組を見るようにすれば、 駄作をだらだらと見続けて時間を無駄にすることもない。

この手のハードウェアは、 Linux などのオープンソースな OS で動いてこそ真価を発揮するのだと思う。 視聴方法は人によって様々であるから、 全てのユーザニーズを満たすような万能なソフトウェアを、 ハードウェアメーカが製品出荷時に開発することなど、 そもそも無理な話ではないのか？

ハードウェアメーカはドライバ (あるいはハードウェア仕様) の公開だけにとどめ、 ソフトウェアの開発は他者に任せてはどうか。 餅は餅屋というではないか。 一つの万能ソフトウェアより、 ニーズに応じて単機能なソフトウェアを使い分ける方が合理的だし、 さらに言えばどんな OS 上でそのソフトウェアが動いて欲しいかは、 ユーザによって異なるだろう。

例えば私の場合、 24時間365日、安定して録画し続けることが最優先であるし、 「使い易い」グラフィカルなユーザインタフェースよりは、 perl スクリプトから 自由にコントロールできることのほうが重要である。 私もノートPC では Windows VISTA を使用しているが、 録画サーバの OS に Windows を使う気にはなれない。

GV-MVP/RX2W は生産終了になって久しく、 後継の GV-MVP/RX3 や GV-MVP/GX2W はまだ Linux では使えないらしい (はたして地上アナログ停波までに使えるようになるだろうか?)。 I/Oデータの製品は Linux で使えないことが多いので注意が必要だろう。 Windows のみ対応しているハードウェア製品だと、 サポートが打ち切られて Windows の新 OS に対応しなくなった段階で、 使うことができなくなってしまう (サポート終了を理由に VISTA 対応版を出していないハードウェア製品は多い)。 もっとも、メーカ側からすると早く使えなくして、 新製品に買い換えてもらいたいのだろうが。

なお冒頭で「パッチを当て直す必要はない」と書いたが、 GV-MVP/RX2W には DeEmphasis (DEM) モードを設定すると常にモノラル音声になるという問題がある。 標準カーネルでは DEM ON がデフォルトになっているので、 Linux 2.6.24.4 に以下のパッチをあてて、 DEM OFF をデフォルトにしてみた。 このパッチをあてることにより、 デフォルトで二か国語/ステレオ放送の録画ができるようになる。 

--- linux-2.6.24.4.org/drivers/media/video/tda9887.c        2008-01-25 07:58:37.000000000 +0900
+++ linux-2.6.24.4/drivers/media/video/tda9887.c        2008-04-13 11:41:30.232518786 +0900
@@ -227,8 +227,7 @@
                 .name  = "NTSC-M-JP",
                 .b     = ( cNegativeFmTV  |
                            cQSS           ),
-                .c     = ( cDeemphasisON  |
-                           cDeemphasis50  |
+                .c     = ( cDeemphasisOFF |
                            cTopDefault),
                 .e     = ( cGating_36     |
                            cAudioIF_4_5   |
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:57
2008年4月7日

なぜ、「購入 VS 賃貸」 という比較がナンセンスなのか？ hatena_b

分譲マンション (あるいは一戸建) を (ローンで) 購入するのと、 賃貸マンションを借りる (賃借) のと、どちらが得か？ という比較の話をよく聞く。 大抵は、ケース・バイ・ケースで片付けてしまうか、 「購入派 VS 賃貸派」などと個人の価値観に帰着させてしまうことが 多いようである。 例えば、 「ローンも家賃も月々の支払いは似たようなものであるが、 購入の場合はローンを完済すれば資産になるのに対し、 借りる場合は家賃を永遠に払い続けなければならない。 一方、 購入の場合は地価が下がったり住環境の変化などのリスク要因もあるから、 購入が得とも限らない」等々...

本当に、ケース・バイ・ケースあるいは価値観の問題なのだろうか？

まず注意しておきたいのは、 「購入」と「賃借」は、対立概念ではないということ。 当たり前の話だが、 「購入」の反対は「売却」であり、 「賃借」の反対は「賃貸」である。 マンションを購入しても、 必ずしもそこに住まなければならないわけではない (税制などを考えれば住む方が得であるケースも多いが)。 購入するにしても借りるにしても、 どこかに「住む」はずであるから、 共通部分である「住む」は除外して比較を行なうべきであろう。

どうやって「住む」を除外したらよいか？

マンションを購入して (他者に賃貸するのではなく) 自らそこに住む場合、 自分自身に対して「賃貸」したと考えればよい。 つまり「賃借人」である自分が、「大家」である自分に家賃を払ってそこに住む、 と考えるわけである。 このように考えれば、 「自宅としてマンションを買う」という行為は、 「マンションを買って (自分自身に) 賃貸」という行為 (つまり不動産投資) と、 「マンションを賃借して住む」という行為に分解できる。

買う　⇒　不動産投資 + (自分から)賃借して住む
借りる　⇒　(他人から)賃借して住む

このように考えれば、 「賃借して住む」の部分は両者に共通であるから除外して比較することができる。

つまり「買うか？ 借りるか？」という比較は、
「不動産投資を行なうか？ 行なわないか？」という比較になる。

4000万円の新築マンションを購入するとして、 頭金を800万円（購入価格の2割）、 残り3200万円を金利3％、 35年返済で借りるとした場合、 月々の返済額は12万3000円となる。 頭金800万円を加えた総返済額は約5970万円。 これに固定資産税、維持管理費等の支払いが約1700万円。 結局7670万円の支払いをして、マンションが自分の資産となるわけである。

ここで、 (自分自身に) 月額 12万3000円の家賃で賃貸すると考える。 もちろん家賃の額は任意に設定して構わないのであるが、 ここでは簡単化のため、 家賃をローンの月々の返済額と同額の 12万3000円に設定してみる。

4/19追記: 任意に設定して構わないといっても、 賃借人としての自分が「払ってもよい」と思える額であることが大前提である。 どーせ自分自身に払うのだからいくら高くても懐は痛まない、 などと考えてはいけない。 月々のローン返済額と同程度の家賃を払うくらいなら購入したほうがお得 (つまり 12万3000円以上だと払いたくない)、 と考える人が多数派であるようなので、 設定する家賃は月額 12万3000円を上限とすべきだろう。

すると、賃借人 (つまり自分) から払ってもらった家賃を、 そのままローンの支払いにあてることができて、 固定資産税と維持管理費等の支払いだけでマンションが自分の資産になるわけである。 つまり「大家」としての自分は、 頭金800万円と固定資産税と維持管理費等の1700万円の合計 2500万円だけで、 (35年後には) 4000万円のマンションを手にいれることができる。

おいしい話のように聞こえるだろうか？

もしこの話がおいしい話に聞こえるなら、 マンションは購入すべきという結論になるわけだが、 よく考えてみて欲しい。 まず、 35年後に 4000万円の価値をもっているかどうかは、 そのときのマンション相場次第である。

ここで考慮しなければならないのは、 「果たして地価が今後どのように変動していくか」である。 地価が毎年上昇し続ければマンションの資産価値も上がり続けるので問題ないが、 今の景気を考えると地価の上昇はしばらく期待できず 「地価はもう上がらない」という意見が多い。 正直そのあたりが誰にも明言できないところに 「買うか？借りるか？」の議論がいつの時代もされ、 結局「どっちなの？」に終始してしまうのである。
ここで地価が変動しないと仮定すると、35年後の資産価値は2510万円となる。

地価が変動しないと仮定すると、この話は 「頭金800万円と固定資産税と維持管理費等の1700万円の合計 2500万円で、 (35年後には) 2510万円の資産価値を持つマンションが手にはいる」 という話に変質してしまう。

おいしいと思えた話に影が差してこないだろうか？

とはいえ、 2510万円の資産価値を持つマンションが (35年後とはいえ) 手に入るのだし、 もしかしたら地価が上昇してマンション相場が大幅に値上がりするかも知れない。 先行きが見えない株に投資するよりは、 大化けするかもしれない「不動産」に投資したい、 と判断する人もいるかもしれない。

賃貸の場合は頭金800万円と税金等の1700万円も不要なので、 購入しなければ2500万円の現金資産が残り、 結局は地価が変動しなければどちらも同じなのである。

「結局は地価が変動しなければどちらも同じ」だから、 ケース・バイ・ケースあるいは価値観の問題ということなのだろうか？

実はそうはならない。

なぜなら、 「頭金800万円と固定資産税と維持管理費等の1700万円の合計 2500万円で、 (35年後には) 2510万円の資産価値を持つマンションが手にはいる」 という理解は間違っているからだ。

支払額が合計 2500万円と思った人は、 800万円を (例えば) 銀行に預けておけば、 (低金利の昨今とはいえ) 35年もたてばそれなりの利息がつくということを忘れている。 毎年払い続ける固定資産税と維持管理費等だって、 総額 1700万円も払うわけだから、 同じ金額を 35年間もかけて積み立てていけば 利息が加算されて 1700万円を大きく上回る額になる。

不動産投資を行なうか、行なわないか、という比較をするのであれば、 不動産投資を行なわない場合に 同じ元手 (総額 2500万円) を 他の投資先へ振り向けた時の収益を含めて考慮しなければ、 フェアな比較とは言えないだろう。 他への投資でどのくらいの利回りが期待できるかは投資先に依存するが、 ここでは簡単化のため、 (ローン金利と同率の) 3% の利回りが期待できると仮定してみる。

最初に 800万円を投資し、 1700万円を毎年均等に (つまり毎年 49万円ずつ) 追加投資して、 3% の利回りがあると仮定すると、 35年で 5214万円にもなる。

つまり、

新築価格が 4000万円のマンションを 35年ローンで買ってもいいのは、
ローン完済時に 5214万円以上で売却することが期待できる場合に限られる。

あるいは、(2/3 追記)
値上がりが期待できないのであれば、 自分自身に支払う家賃は月額 12万3000円ではなく、 月額 14万円ということになる。 なぜなら、家賃を 1万7000円増額することにより 年間 20万円を積み立てることができて、 値上がり期待分 1200万円を補填できるからである。
つまり、
「月々のローン返済額と同程度の家賃を払うくらいなら購入したほうがお得」 という考え方は、 ローン完済時に値上がりが期待できない (築35年のマンションを新築価格以上の値段で売却できるだろうか？) 状況下では正しくない。
一般的には、 値上がりどころか老朽化などの理由により 2510万円程度に値下がりしてしまうので、 「補填」すべき額は 2700万円にもなり、 「みなし」家賃は 15万8000円となる。

「土地神話」が崩れた今、 マンションを買うという行為は、 「投資」以外のなにものでもない。 そして、 「個人の投資は必ず余裕資金ですべき」という鉄則は なにも「株投資」の場合だけに当てはまるものではなく、 どんな投資についても当てはまる金言である。

結構な高金利で借金して得たお金で投資する人がいたらどう思うだろうか？ 「借金して得たお金」というのは 「余裕資金」から最もかけ離れた資金と言えるだろう。 そんな投資はやめておけ、と誰しも思うのではなかろうか？

しかしながら多くの人が行なっている 「ローン組んでマンションを買う」という行為は、 「借金して得たお金で投資する」という行為となんら変わらないのである。

More...
Filed under: 経済・投資・納税,自己啓発 — hiroaki_sengoku @ 08:30
« Newer Posts — Older Posts »