任天堂の苦しい言い訳？

WiFiのWEP暗号化が無意味だという話題が世の中を席捲していますが、PCやPDA等の主要なWiFi機器はWPAに既に対応しているので、設定さえ変えれば特に問題無かったりします。

しかし、世の中に大量に普及していて、WiFi機能があり、更にWEPにしか対応していないという機器があるのです。

そう。それが任天堂DSです。

ITmedia: WEPは一瞬で解読 — ニンテンドーDSはどうなる

IT業界人はゲームも大好き、ということで早速槍玉に挙がっています。まぁ、ああいった低価格なゲーム機器で複数の暗号化方法に対応するのは、製造原価の観点から見送らざるを得なかった判断なのかも知れませんが、任天堂広報室の最後のひと言が面白い。

「ただ乗りはマナー違反。家の鍵が壊れていたからといって、侵入していいというものではない。マナーの向上を期待する」

え〜！家の鍵が壊れていたら、泥棒なら喜んで侵入しますよね？
今問題にしているのは、たまたま脇の甘いWiFi電波をただ乗りするという比較的無害なユーザではなく、そこを踏み台にして悪さをする様な犯罪者ユーザの事なんだと思いますが・・・。

ただ乗りされるだけなら一時的に自分がお金を払っている回線の帯域をタダで使われてしまうだけで、まぁ悔しいという程度で済んでしまう話ですが、仮に犯罪を起こされた場合、侵入されたWiFiを持っている方にISPが割り当てたグローバルIPでインターネットに接続して犯罪を犯すわけで、下手するとWiFiに侵入されてしまった方は無実の罪で捕まってしまうことにもなりかねません。問題にすべきはこういったシチュエーションで、マナーとかそういう次元では無いと思うんですが・・・。

まぁ、広報担当者はITの専門家でもなく、ましてやセキュリティの専門家でも無いんでしょうけれど、ちょっとこのコメントは的外れ過ぎるかなぁ、という気がしました。

WEP暗号化はもはや用を為さず？

あまりに衝撃的な記事を見てしまったので、慌てて自宅と職場の無線LANの暗号化方式をWEPからWPA2に変更しました。

ITmedia - 「WEPを一瞬で解読する方法」を研究者グループ発表　プログラムも公開予定

プログラムが公開されるまでの期間が言わば「執行猶予」だったわけだけれど、もしそんなプログラムが公開されてWEPキーのクラッキングがカジュアルに行えるようになってしまったら、もはやWEP暗号化なんて何の意味も無くなってしまう。

というわけで、この記事を読まれた方は一刻も早くWEPを捨ててWPAもしくはWPA2 (AES暗号)へ！

C言語プリプロセッサ

現在、仕事で組込向けプログラムをC言語で実装しているのですが、ネットで調べても載っていなかったことを備忘録代わりに書いておきます。

C言語のプリプロセッサ命令に文字列結合の”##”という命令があるのですが、ネットのどこを調べても載っていません。私が以前Cを勉強したとき(もうかれこれ10年以上前ですが・・・)には確かに習った記憶があるのですが、最近は教えないんでしょうか？？

ともあれ、手元のコンパイラ(gcc v4.0.1 for MacOS X)ではちゃんと機能しますので、私の記憶違いでは無さそうです。

そういえば、私がCを勉強していたときも、関数ポインタについて記述している書籍は殆ど皆無でしたので、ある意味プロフェッショナル向けの隠し機能みたいな考えられ方をしてるんでしょうかね。

Cプログラミング雑記

すっかりこちらの更新が滞っていました。

最近、C言語でのプログラミングを仕事でやっているんですが、組込向けなので自前でライブラリ関数レベルの機能を実装しなければいけなくて、結構ハマる事もしばしば。

最近ではBASE64エンコード/デコードのコードを書いたのですが、細かなビットシフト演算の部分でミスがあったりして、1週間くらい格闘する羽目に陥りました。結局は全て解決して、やっとちゃんとしたコードになりました。

あともう一つハマったのは、CでBASE64エンコードしたデータを受け取る側のPHPスクリプトの問題です。Content-Typeをapplication/x-www-form-urlencodedで送ると、URLエンコード特有の処理をPHPが裏でやってくれてしまうんですよね。いわゆる、空白文字をプラス文字(+)に置き換えている処理を、PHPスクリプトでは自動デコードしてくれてしまうのです。

BASE64は、アルファベット(A-Za-z)と数字(0-9)と記号(+/)にデータを変換するのですが、URLエンコードの自動でコード処理をされてしまうと、+にエンコードされていたデータが空白に戻されてしまっておかしな事になります。

これもだいぶハマりました。。。

まぁ、うまく行った時の達成感は得がたい物がありますが、C言語は本当に全てがプログラマ任せで大変です。Javaがメインだった頃が懐かしい・・・

Fireworks

今日は、東京湾大華火祭でしたね～。

昨年は、ホテルの高層階にあるレストランで鉄板焼きをほうばりつつ観覧した花火ですが、やはり間近にあの迫力を感じたいということで今年は原点に立ち返り、芝浦埠頭の会場に見に行きました。芝浦では、今まで一般に開放された(とは言いつつ人数制限は有る)会場で見ていましたが、今年は相方が港区民専用の会場をゲットしてくれたので、おかげさまで「19時の花火を観る為に15時から行列して待つ」という荒行をせずに済みました。

ちなみに、今回はクーラーバッグにドリンク＆保冷剤を装備し、行きがけのミッドタウンで食べ物も調達したりして、準備は万端。冷えたドリンクを飲みながらつまみを食べ、ど迫力の花火を楽しむ、という最高な夜でした。東京湾の花火は、とても大きなサイズの玉が高いところまで打ちあがるので、近くで観ると仰角が高く首が痛くなります。ちょうど映画館の最前列で映画を観ている様な感じですかね。

しかし、明日は朝からゴルフ。果たして無事4時半に起床出来るのでしょうか！？

すべらない話

IT史に輝く「すべったテクノロジー」ベスト25 (前編 | 後編)

前々職の同僚の方が日記に書かれていたので読んでみたところ、非常に面白いランキングです。

「すべった」と言うと「失敗した」というイメージが強いかなと思いますが、物によっては「早過ぎた」とか「時代がまだ受け入れる準備をしていなかった」という物もあるかなと思います。気になったものだけピックアップしてみますと:

25位: IBM PS/2

私もリアルタイムでは知らないIBM PS/2ですが、ひと昔前までのパソコンには必ず付いていたPS/2ポート(キーボードとマウスを接続する為に各1つずつある)にその名残がありますね。キーボードとマウスに限定されているとは言え、ここまでしぶとくその名が生き残ったという意味では、何というか執念のような物を感じます。

22位: OpenDoc

実は、OpenDocがもてはやされた頃に私の親は情報システムを担当していて、自宅にあった「OpenDocジェネシス」という本を読んだことがありました。当時の、コンピュータを全く理解していない高校生だった私にはちんぷんかんぷんの内容でしたが、今考えるとOpenDocは非常に先進的な事をやろうとしていたという事が理解できます。ただ、惜しむらくは当時のハードウェア性能ではこれを実用的なレベルにまで引き上げる事が出来なかったのではないだろうかということです。私の理解が正しければ、OpenDocと類似の技術としてMicrosoftのOLEがあり、それらは依然としてMicrosoft Office等のアプリケーションで利用されています。そういった意味では、Appleには先見の明があったのでしょうね。

19位: GNU Hurd

今日のLinuxの繁栄を支えているのは、間違いなくGNUプロジェクトの数々の成果物であり、その為GNUプロジェクトの創始者であるRichard M Stallman (通称RMS)は、「LinuxではなくGNU/Linuxと呼べ」とのたまわっている程です。つまり、Linuxは単なるUNIXライクなカーネルであり、その周りにGNUソフトウェア(例えばbash: Borne Again SHell)を配置する事で、やっと実用的なOSとなるという事を言っているのですね。しかし、面白い事にGNUプロジェクトの根幹たるカーネルは未だ存在せず、その名前はGNU Hurdと呼ばれているが未だにリリースされていません。

GNU Hurdの実用化にどの様な障害が存在するのかは分かりませんが、恐らくはカーネルとしてのLinuxとGNU Hurd以外のGNUソフトウェアとの組み合わせがあまりにもうまく行き過ぎたために、人々がGNU Hurdをそれ程強く望まないことが理由なのではないか、と思われます。もしくは、単にマイクロカーネルを採用するGNU Hurdに、マイクロカーネルに有りがちな性能面などの問題があり、未だに実用に至っていないだけかも知れないですが。ちなみに、その辺りを現実的な選択肢で乗り切ったLinuxは、分類としてはモノリシックカーネルです。

10位: Itanium

Itanium、いやIA64と言った方が良いかも知れないですが、この全く過去との互換性を断ち切った新しい64ビットCPUのアーキテクチャを作り上げるプロジェクトは、現在のところ商業的な成功を収めているとは言い難いかも知れません。しかし、実行時にCPUがアプリケーションの並列性を判断するのではなく、コンパイル時にコンパイラがそれを判断するというアプローチに変えた事は、非常に先見の明があったと言えるのではないでしょうか。

現在、IA32とその64ビット拡張であるx64では、パイプラインの増大と動作クロック向上によるCPU性能の向上は限界を迎え、IPCの高い命令セットで複数のコアをダイに載せるというアプローチに代わりました。しかし、同時に多数のプロセスが走る事が前提のサーバ用途では良いですが、デスクトップ用途ではこんなアプローチは気休めに過ぎないという事は誰でも気付く事だと思います。そもそも同時に走るべきプロセスの数は少なく、アプリケーションは並列化に対応していないとなれば、コアを増やしたところで遊んでしまうだけなわけです。そこでIA64で取り入れられた「コンパイラによる並列化」が活きるのではないかと思うのです。

7位: 64ビットPC

確かに、コンシューマ向けのPCに64ビットのアドレス空間は不要です。しかし、32ビットのアドレス空間、つまり4GBというアドレス空間は、Windows Vistaという非常にgreedyなOSの登場によって、「あるいは食い尽くされてしまうかも知れない」程度のサイズとして認識されるようになったのは確かです。Windows Vistaがユーザに支持されているとは言い難いですが、それでもMicrosoftがこの手のリソース食いなOSを出し続ける場合、必然的に32ビットでは対応しきれないアドレス空間を必要とする日が来るでしょう。それが良いかどうかは別として、ですが。

2位: Windows Vista

今更Vistaについてコメントは不要だと思われますが、私にとっての驚きは、Vistaの価値をWinFSに置いていた人が私以外にも意外に多かった事ですね。少なくとも、Vistaの価値がAeroだなんて、悪い冗談にしか聞こえないです。

*****

さて、皆さんはこの記事を読んでどの様な感想を持たれたでしょうか。

仮想化

ハイパーバイザの価値とは

サーバ仮想化の市場では、先行するVMWareとそれを追従するXenSource、またサーバOSにハイパーバイザを統合したMicrosoftが主立ったプレーヤだ。しかし、それぞれは出自が違うこともあり、仮想化に対する考え方も随分と違う。

元々、VMWareはハイパーバイザ型の仮想化をやっていたわけではなく、後になって製品を追加して対応した。しかし、Xenはそもそもがハイパーバイザの研究から生まれたプロジェクトであり、XenSourceを買収したCitrixがその技術を積極的にMSに供与して作られたのがHyper−Vだ。

ただ、この記事から何となく読み取れるのは、もはやハイパーバイザ機能はサーバ機のハードウェアの一部として、ある種のBIOSの様な形で搭載され、顧客にとってはシームレスな存在として出荷される、という流れが出来つつある事だ。

今後の普及に期待感はあるが、純粋な仮想化技術自体に関して言うと、もはやエキサイティングな状況を過ぎた様に思えるのが少し寂しい。