2008年3月31日月曜日

画像処理にクラスタ・システム

ロボットの目としての画像処理も高度になれば画像処理も重くなる。
そのためにARMプロセッサーを複数、通信させてクラスタ化するのはどうだろうか。
その為に、OpenMOSIXとOpenGFSを応用してはどうだろうか。

OpenMOSIX http://sourceforge.net/projects/openmosix/
OpenGFSは、Open Global FileSystem http://sourceforge.net/projects/opengfs/
OpenMOSIXのOpenMFSを使うのは軽いかもしれない。

このGFSは「Google File System」ではない。

ロボットの目

今日は本を紹介する。

「ロボットの目をつくる」 という本。
副題が「二足歩行ロボットにカメラをつけて画像処理」だ。

ロボットが自律歩行するには画像処理は重要。


参考までにアシモ君の写真を掲載する。撮影許可は当時に頂いたものだ。随分古い写真だけどどう?
私が撮影したものだ。他人のパクリではない。当時NDAは無い。特段に禁止事項は何も言われてもいない。

2008年3月29日土曜日

2002年に撮影したロボットmorphの写真


以前、個人的に取材・撮影させて頂き許可を得て自分のホームページに掲載していたmorphの写真だ。今、改めてみても綺麗なロボットだ。

2001年当時の過去記事は今も見れる。




ベンディングマシン・レッドとアンドロイドのコス・・だと

このビデオには笑った。
http://www.youtube.com/watch?v=MYKSw35TLOw
YouTube楽しいね。

Google Androidで携帯電話会社(キャリア)のビジネスはかわるのか?

日本アンドロイド・ユーザー・グループで表題の投稿があった。
http://www.android-ja.net/modules/d3forum/index.php?topic_id=97
ここではGoogleへの検索トラフィックに応じた収入がキャリアがGoogleから得られると書いてある。
それも一つのビジネスなんだろう。
自分も利用者の一人としては、通話料や特にデータ通信料金は定額であってほしい。
じゃないと携帯電話からGoogleへなんてアクセスはしないだろう。
ということは、これまでのビジネスモデルと差し引きGoogleと組んだほうが特なのだろうか・・・
たぶんそうなのだろう。すごいものだ。

自分は、古い携帯電話も程度の良いものは再利用すべきと思う。もちろん広告付きでね。

Java2プラットホーム

Google Androidに搭載したグーグル独自のJava実行環境DalvikがSunと昨年もめたがその後どうなったのだろうか。

まあ、両社は仲良しだから大丈夫と思うが。。。
Java2プラットホームはJ2ME関連がややこしい。
それに重たい。グーグルの意見ももっともだと自分は思う。Javaもオープンソース化したんだからお互いに歩み寄ってほしい。

個人的には、J2SEとJ2MEは同じAPIにしてほしい。もうARMプロセッサーなどPC用CPUと遜色ない状況で制限したAPIやメモリ空間は苦痛でしかない。

アンドロイドでさくさくと使いたい。

「PDFでの透明の処理についてのメモ」と標準化関連情報

過去に、PDFクローンのiTextやPDF-Renderの記事を出したが、これらのソフトで透明の処理ができるか未確認だった。以下記事を見つけてしまったのでメモを取っておくことにする。

「萩さん日記」:透過レイヤーを含む PDF 生成における問題
http://hagi-san.blog.ocn.ne.jp/hagisan/2008/03/pdf_c4a0.html
透過レイヤを含むPDFを生成できない問題を回避するには、アプリケーションソフトから直接 PDF を書き出すことが唯一推奨されるのかもしれない。

「PDF千夜一夜」:透明の扱いについて(メモ)http://blog.antenna.co.jp/PDFTool/archives/2008/03/25/#001005
透明をWindowsGDI画面に表示するのは比較的簡単にできる。「書けまっせ!!PDF」では、透明度を設定したPNGを画面に表示することもでき、PDFに出すこともできる。(GDIプリンタにはちゃんと出せない。プリンタ・メーカの責任か?)

試しにPDF RenderをWebから起動してみたが・・・起動先は以下:
https://pdf-renderer.dev.java.net/demos/latest/launch.html
次に「透明のあるPDF.pdf」を以下からダウンロードして、
http://blog.antenna.co.jp/PDFTool/200803/%E9%80%8F%E6%98%8E%E3%81%AE%E3%81%82%E3%82%8BPDF.pdf
PDF-Renderの「SwingLabs PDF Viewer」で表示したが見事に真っ白にしか表示しない・・・(残念でした。)まだまだ使い物になりませんね。> サン・マイクロシステムズさん・・・

余談:「萩さん日記」:PDF のセキュリティ
http://hagi-san.blog.ocn.ne.jp/hagisan/2007/09/pdf__b885.html
めずらしくPDFのセキュリティを書かれている人がいるなーと思って見たらアドビ社のサーバを使っての話でした。
Adobe Acrobat SEやPROでも電子署名やタイムスタンプの付与・検証はできる。
iTextでも電子署名とかできる。以下を参照のこと。
http://itextpdf.sourceforge.net/howtosign.html
しかし、SunのPDF-Renderでは、署名が付いていることすらわからない・・・(残念!)

まだまだ有償ソフトが必要ということかな。

ところでPDFがISO化された。番号は、ISO 32000 だ。
参考になるブログは以下:
http://blog.antenna.co.jp/PDFTool/archives/2008/03/24/#001004
これでPDFは安心して使える?ISOの仕様書を買いたくない人は、アドビのPDF1.7仕様書を見よう。
http://www.adobe.com/devnet/pdf/pdf_reference.html

ちなみにODFは、ISO/IEC 26300:2006 だ。
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43485
OASISのページにもある。
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
ODFはJIS化作業中だ。
村田氏のXMLブログに情報がある。MS Office OpenXML(OOXML)についてもここに情報がある。
http://www.xmlmaster.org/murata/

PDFもODFもISO化されたので安心して使える。

2008年3月28日金曜日

欲しいミニバンSUVとカーナビ

5人で乗るにしてもアルファードやエルグランドのような大き目のミニバンは3列目に横に寝れるのが嬉しい。3列目をベットにする人は沢山いるのではなかろうか。
今、気に入っているのは日産フォーラム・コンセプト。次期エルグランドだ。
http://corism.221616.com/articles/0000074043/
でも5人乗りに絞るなら、VWトゥアレグだ。
http://www.volkswagen.co.jp/cars/touareg/index.html
エアサスによる抜群な車高調整は優れもので川も渡れるほどだ。普段は車高を下げておき、アウトドアで遊ぶときは車高を上げて悪路・雪道を走りたいものだ。
デザイン的にはランドローバーコンセプトLRXがすばらしい。日産も次期エルグランドでまねしてほしいデザインだ。これなら真似していても嬉しい。
http://www.carview.co.jp/news/2/65416/
これら3車をミックスした8人乗りが欲しい。
ただし、2列目シートは現状のエルグランドの形でいいかなと思う。2列目中央のシートが単独スライドするのは便利そうだ。あまりシートには凝る必要はないと思う。

SUV型のミニバンが欲しいといってもデリカはちょっと小さい。またハンドリングに不満がある。
高速道路はスカイライン程度には走ってほしい。エルグランドHPSには興味がある。
http://www.autech.jp/SV/ELGRANDRIDER/SPECIAL/index.html
GT-RベースのSUVが出るなら「GT-RベースのSUV」をベースに8人のりミニバンを作って世間を驚かせるのも有りかもしれない。この前に路上でみたGT-Rは存在感があって見とれてしまった。
でも低い車高の車にはもう乗る気はない。クリーンディーゼルのGT-R+SUV+ミニバンが欲しい。
有り得ないトルクの化けもの車で悠々とクルージングしてみたいところだ。カイエンが後ろから煽ってきてもきっと怖くないだろう。

そんな車に装備するカーナビは、モバイルWiMAXで通信し、Google MAP連動のものがいい。
もちろん通信できないときでも車内の地図データで利用できるのは当たり前だ。
カーナビのOSはアンドロイドであってほしい。オービスMAPは常に更新してほしい。
そしてちゃんと500mm手間で安全運転を自動的に呼びかけてほしい。長距離や他所の土地では事前の標識を見落としがちになるからだ。
交通渋滞情報も自動的に教えて欲しい。迂回路のアドバイスもあると嬉しい。

Androidスマートフォンを持って旅に出かけたい。降りてからもPNDとしてのアンドロイドの機能があれば街中を散策できる。そしてお勧めの店に入ろう。

2008年3月27日木曜日

iタウンページ・ガジェットとGPS

英語版のイエローページ・ガジェットがあるが日本語のiタウンページ・ガジェットがない。http://desktop.google.com/plugins/i/USYellowPagessearch.html?hl=ja


探してみたら「iタウンページBLOGパーツ」というものを見つけた。http://townq.net/exp/about.html


Google AndroidをNTTドコモさんが採用するならば、是非 iタウンページのガジェットを出してくださいね。そして、GPSを使って近隣のスーパーのチラシ情報から最安値リストを提供してくれれば、携帯電話を見ながらお店に買いに行きますよ。ついでにクーポンも提供してくれて割り引けるならFOMAを使い続けるモチベーションになると思う。ついでにIDで支払いをする気になるかも。今はIDは使っていないです。普通のお財布派です。
またお店の前でGPS情報でそのお店やSC内部の各店舗のクーポン一覧を提供してくれるととっても嬉しい!

また、お財布ケイータイで地域ポイントカードの代用が斬新。

http://business.nikkeibp.co.jp/article/topics/20080325/151157/


ところでFOMAといえば・・・新しい、P509iTVがちょっといいかもと思った。http://www.nttdocomo.co.jp/product/foma/905i/p905itv/index.html

大きな液晶が魅力だ。タッチ操作が是非欲しい。


でもEM・OMEαに通話機能とiモード・メール機能が付いたら欲しい。http://www.sharp.co.jp/em/s01sh/

もちろんアンドロイドも使いたい。でもフリーズするOSやハッキングされるOSは欲しくない。

長期署名と「真偽を確定する論理」

長期署名がJIS X 5092(CAdES)、JIS X 5093(XAdES)が官報公告されている。
http://kanpou.npb.go.jp/20080321/20080321g00057/20080321g000570057f.html

日本もとうとうETSIに影響されたようだが、利用者が理解できるか疑問だ。

ところで「真偽を確定する論理」とググると結構面白い。
長期署名は本当に「真偽を確定」できるのだとうか・・・
日本の法律は所詮は「記名押印に代えて・・・」の世界で、法によって改ざん防止が条文に出てくる程度だ。どの法律にもお上のガイドラインにも長期署名が必要とは書いてないのでは???

ES-X-Long程度なら電子署名に使った電子証明書の有効期間後も検証可能なので、まあいいかなと思うが、失効情報の猶予期間なる論理ははてさて実際の運用に合致するのか、またエンドユーザーが受け入れられるのかわからん。

印鑑や直筆署名と同じレベルで利用できないと長期署名に置き換える気がしないのではなかろうか。
日本の印鑑って権威の象徴みたいな部分もあるので電子署名が馴染み難いかも。
個人の実印だって象牙とか小難しい印影にするのは、その影響かなと思う。単に偽造し難いだけとは思えない。現在ではコンピュータで簡単に偽造できる印影だが十分機能しているのだから電子署名も簡単に使えるぐらいが丁度良いはず。

Googleさんはどう思う? 見解を教えて欲しい。

クラウド・コンピューティング(cloud computing)【2回目】

レイヤーとして見ると

・OpenID、ガジェット、Webサービス、SaaS、クラスタ、IDC、DBなどで構成されたサービスを 誰もが見える雲に例えてアクセスするような新世代コンピューティング環境。 サービス間の連携が自由にできるのが特徴。

・マルチスレッド、マルチプロセス、オブジェクト、SOA等のビジネスロジックなどのアプリケーション環境。

・デバイスドライバ、マルチスレッド・カーネル、マイクロカーネル&サブシステムモジュール化カーネルなどのOS環境。

コンピュータ環境は、雲のように水蒸気の粒から小さな雲ができ、雲の集合体が成長する。羊雲にも、積乱雲にも、台風にもなる。コンピュータも雲に例えられるようなものになってきたといこと。おぼろ雲みたいなサービスは小さなWebサービスの集まりみたいだ。クラスタ化が一般的になり、広域ロードバランサの発達なども影響して地球規模でサービスが構築できる。利用者から概念的には、これまでと大きく違うのはパッケージソフトを買ってきてインストールするのとも違う。ネットワークが発達したおかげで流通は物流からダウンロードに代わってきた。従来のOS環境の一部であるデスクトップまでもがWebサービスになり、RIAでどこでも使えるアプリが実現している。マージンを取る中間者がいない。そして安いし、無料やオープンソースまで豊富にある。見るだけなら雲はタダだが、雲を作るには膨大な費用がかかる。水蒸気を作るだけならヤカンで湯を沸かせばよい。雲が勝手に雨を降らせるのはタダだが、人工的に雲を呼び雨を降らせるにはクラウドシーディング(Cloud seeding)とかするらしい。どこかの国の山奥では、ロケット花火を打ち上げて人工降雨をやっているらしい。コストがかかる何かをしないと雨を降らすことはできない。

昔は、集中型のホストコンピュータが主流で、オープンシステムのクライアント/サーバ環境、分散コンピューティングやらと実態ありきの考えだった。今では、実態を包み隠し細胞が増えるがごとく増殖できるコンピュータ環境となった。それがクラウド・コンピューティングだと思う。

強さについては、昔とあまり考え方が代わらないかなと思う。IDCに設置するインフラの規模、つまりCPUパワーの大きさと、回線の大域の太さ、ストレージの大きさなどがビジネスパワーに繋がっている。貧乏人はコバンザメに徹するとオコボレにあずかり安心してビジネスができる。Googleはさしずめジンベイザメかな。大規模なデータセンターほどビジネス効果が得られる。回線は回線を保有するキャリアが有利だが、大量に借りる事業者は神様のごとく有利だ。ストレージやサーバを買うのも大量に買うほうが有利。大きなショッピングセンターとビジネス集約化の考えは同じということか。町の商店街がつぶれるのと似たような弊害はきっとあるのだろう。

IDCでは免税軽油が使える?

IDCで軽油を使う場合、電気通信設備の電源の用途に供するなどの道路以外の用途なので法的には税の対象からはずれる。ディーゼルの自家発電によるコストと他の電力供給とコスト比較をしたはないが、この減税効果は大きいと思う。少なくともバックアップ電源としてのディーゼル自家発電のために申請するメリットがある。大量に軽油を使う場合はこの減税効果は大きい。従って大規模IDCに有利だ。

2008年3月26日水曜日

ロータリー・ディーゼル・エンジン・ハイブリッドがあったなら

最近は、自動車も数十個から百数十個のCPUを搭載し車内ネットワークがある。
家電がコンピュータによりデジタル化したのが少し前のトレンドだったが今は自動車のデジタル化がトレンドだ。ハンドル制御からアクセル制御などさまざまなデジタル化が進んでいる。
エンジン制御は早くからコンピュータ制御になっている。
そんなわけで、自動車のエンジンについて一言。

クリーン・ディーゼルとしてのロータリー・エンジンが存在し、軽油で走行できるならばロータリーの課題であるトルク増強が楽にできるはず。またホンダ方式のハイブリッド・モータのようにローターの3つ目を薄型モーターにすることにより低速時のトルクを稼げる。

マツダはロータリー・エンジンをフロント縦置きにしたがるが、個人的にはFFもしくはRRにすべきだと思う。フロント縦置きだとモーターボートと同じく回転による慣性モーメントがハンドリングを邪魔をする。
三菱自動車のアイのような発想はできないものだろうか・・・
またマツダは電子制御に弱く、デジタル化が遅れているように見える。昔のマツダのエンジンはどれもストールを起こしやすかった。エンジンの燃料制御がちゃんとしていれば大丈夫だと思うのだが・・・

ディーゼルエンジンは、軽油は地方税なので、自治体はクリーン・ディーゼルを推奨すれば田舎でも税収があがるはず。ディーゼルカーを購入時に価格アップ分の減税をすれば利用者は増えると思う。

今、都の某銀行で悪評が高い知事のおかげで日本からディーゼルが消えて、軽油の地方税としての収入はトラックやバスに頼っているのが現状だが、これに自家用車が昔以上に増えれば地方の財政は楽になるのではないのだろうか・・・

ついでにカーナビもグーグル・マップと連携し、新しい道路の発見と地図データの更新をタイムリー化できれば開発の進むニュータウンなどはより便利になる。
現状の仕組みでは早いペースで開発が進む地域のカーナビ対応は無理があるというもの。これまでの手法や体制では改善できるとは思えないので提案をする。

Motus社のDarwinコントローラー

Wiiのコントローラのようなもの
http://www.motusgames.com/page_6dof.html
http://www.engadget.com/2008/02/04/motus-darwin-controller-to-being-that-wii-feeling-to-the-pc/http://kininarunewspickup.blog15.fc2.com/blog-entry-615.html

こんなコントローラが、マルチコアCPUの小型BOXでBD-Rとか搭載したものがあって、Google Androidが搭載されていればWiiみたいにつかえるのではないかと思うのだが・・・
家庭のコンピュータとして、携帯電話としても同じOSならお年寄りも子供も簡単に使える。
また、携帯電話は加速度センサーやGPSを搭載するのでWiiコントローラのような操作はできるはず。

操作系が共通ならば分かりやすいものです。

インテルさん、ゲーム機を作ってみてはどうかな?

FileMakerライクなカード型DBサービスの必要性

未だにFileMakerの人気がMacとWindows両用環境及びグラフィックの含むアプリの作成環境として人気がある。
Googleはサービスを作らないのだろうか?
もしFileMaker互換なら、FileMakerのアプリが移植できる。

例えば電子カルテが日米でFileMakerベースのオープンソース版があったりする。
特に日本ではFileMakerで作られた電子カルテなどが沢山存在する。

2008年3月25日火曜日

Officeアプリの電子署名とUSPSのEPM電子消印

MS OfficeやOpenOffice.orgの電子署名機能には正直言って残念だとしか言えない。
理由は電子署名を付けても付けたのかどうか利用者にはわかりにくい。
Adobe Acrobatの不可視署名ぐらいは参考にすべきだと思う。
OpenOffice.orgの以前のバージョンで試したことがあるが、日本の電子署名法にもとづく認定認証業務発行の電子証明書による電子署名にはOpenOffice.org内部のNSSが対応していない。だから署名できない。
利用者がほとんど居ないから誰も気づかないのが寂しい・・・

電子署名できるアプリケーションとしては、PDF系アプリが圧倒的だ。Adobe Acrobat、SkyPDF、アンテナハウスのPDF電子署名モジュールなどはどれも認定認証業務発行の電子証明書による電子署名に対応できている。
これらは、不可視署名や可視署名の機能があり、とっても分かりやすいと思う。

できればODF系アプリは、せめてUSPSのEPMみたいな機能を実装してほしい。
http://www.microsoft.com/japan/showcase/postalus.mspx http://www.usps.com/electronicpostmark/welcome.htm

iTextも電子署名が可能だが認定認証業務発行の電子証明書による電子署名は試したことがないのでなんともいえない。唯一の解説ページは以下。
http://itextpdf.sourceforge.net/howtosign.html

安いノートPCとかUMPCのOSは・・・

最近Linux搭載の安価なノートPCがどんどん出てきた。とうとうHPまでも2133というモデルを発表した。どこのメーカーも何故か日本ではWindows・・・何故?
値が上がるだけでなく、サービスパックで少ない記憶領域があっというまにオーバーフローしないのだろうか?

最近のWindowsのサービスパックに嫌気がさしているとMacOS Xがとっても魅力的に見える。
マイクロカーネルMach3.0とサブシステムがFreeBSDのUNIX系OSのDarwinということをまったく意識させない垢抜けたOSだ。でもLinusがファイルシステムをけなしていたけどね。
NEXTSTEPはMach2.5べーすだったかと記憶にあるが、Mach3.0ベースでよくあそこまで実用的にしたと感心する。
単に実用だけを考えるとLinuxベースで垢抜けたGUIを搭載できるばいいように思う。だからGoogle AndroidをHP 2133に搭載したらどうなんだろうかと創造した。きっとサクサク動くような気がする。
タブレット型兼用のノートPCならきっとアンドロイドがぴったりではないだろうか。

フラッシュメモリ系のシステムディスクを主流にする小型PCはアンドロイドを搭載してみてはどうだろうか? SunのJavaより軽くて軽快ではないかな。
それからグーグルさんに提案なんだけど、OSパッケージをSLAX化しては如何だろうか。
ただしGUIはGNOMEとかこのブログの過去記事のお勧め環境でお願いしたい。
モジュールはインストールではなくダウンロードしモジュールへのマウントを変更するだけで更新できる。
利用者が安心したら古いモジュールのファイルを削除するのは簡単だ。
また、SDメモリに開発中のOSバージョンを用意してSDブートが可能であればザウルスなどのファーム更新みたいな面倒なことをせずに動作検証ができる。絶対に楽だし工数も圧縮できるはず。
ノートPCとスマートフォンのOSが同じアンドロイドなら開発が楽ですね。

2008年3月24日月曜日

シンビアンOS(Psion EPOC)

元々は、サイオン社のPDA用OSであるEPOCとして始まったSymbian OSだが、ノキアの後押しもあって携帯電話では筆頭OSと言える。
マイクロカーネルを採用し、バグを徹底的に排除するポリシーで開発がされているOSだけにWMのようにハングアップすることが極めて少ない。さすが数学者二人が創ったOSだ。正直惚れ惚れする。

しかし、アプリの開発者は元々はPC上で育った人がベースだとしたらWMやLinux/Java系に負けるのではないかと予測する。(PDAでPalm OSがメジャーだったけどザウルスの人気が未だにあるのを見れば納得する諸兄は多いのではないだろうか・・・)

私がGoogleへ期待することは、Java環境だけでなく追加でLinux GNOMEアプリの移植環境(GPE?)の用意とWindowsアプリの移植環境(C#とMono)を用意することだ。
これによりPCで培ったノウハウやこれまでのアプリが簡単に移植できるはず。

独自路線はいつかは消える運命ではないだろうか。オープンソースは長く愛されると思う。
最近はマイクロソフトもオープンソース化に戦略変更しているようだが、本物だろうか?
意外とReactOSが急成長するだけかもしれないよ。>MSさん

PDA用のLinuxパッケージ

シャープのZaulus用に、OpenZaulusというパッケージがある。
QtベースのOpieと、GTK+ベースのGPEの2つの環境を持つ。
OpieのGUIはタブ型のデスクトップを持ってオリジナルのQtベースのシャープ・ザウルスのLinux環境に近い。
個人的には、Qtが元々がビジネスライクなライセンスに始まっているのでLinux愛好家としては心理的な抵抗がありアプリを作る気になれなかった。
シャープの努力(?)で、ザウルスでJavaが使えるようになった時は喜んだが、シャープの中途半端な対応には正直がっかりしたものだ・・・
そんな気持ちもあり、Google AndroidがJavaアプリを主体としているのを見て喜んだ。
しかし、AndroidでGNOMEアプリやMono環境によるC#.NETアプリが移植できるようになってほしいと切望する。
GNOMEアプリのGlade GUIビルダーが扱えれば、XMLのUI作成も楽になるのではないだろうか・・・
また、Windows Mobileアプリ作成者をアンドロイドに興味を向けるにはMono環境は必須だと思う。
Googleには、シャープの中途半端なLinux戦略のようなことをして、前車の轍を踏まないで欲しい。
未だにZaulus愛好家が沢山いて、OS改造に励んだり、OpenZaulusやGoogle Androidに変えたりする人が絶えない。
シャープのLinuxを指揮する人が亡くなりWindows Mobileへの方針変更はザウルス愛好家をがっかりさせた。自分もハングアップするWMは嫌いだ。たとえEM・ONEαの特売があってもLinuxが移植できることができない限りZaulusの代わりには使えないと心に誓うのだった。5月に販売されるウイルコムの新型機は、WMでJIS2004日本語文字環境らしいが、Linuxの移植情報はリークして欲しい・・・
さもなければ、移植情報のあるHTCが選択肢になるだけだと思うが・・・

今でも以下URLへはアクセスできる・・・ (ザウルス愛好家へのメモ)
Sunの「Java Programming on the Sharp Zaurus」記事
http://developers.sun.com/mobility/personal/articles/ztutorial/index.html
J2ME[tm] Personal Profile for Zaurus
http://java.sun.com/developer/earlyAccess/pp4zaurus/
これには、Libfloatモジュールの別途インストールが必要だった。
http://husaberg.toby-churchill.com/balloon/releases/v0.7/base/armv4l/libfloat_1.0_arm.ipk

# この記事は丁度、0時のベルのなっているときに投稿作成のページに
# 入ってしばらく思案してから書きはじめた。
# ブログの記録時間としては0時丁度を指している。
# 電波時計の0時のベルで試した。

2008年3月22日土曜日

お進めなLinux環境(アンドロイドにもお勧め?)

まず、OS屋さんはドライバーもカーネルやツールもC言語なので、C言語とGNOME環境。GTK+アプリは、Windowsにも移植できる。GNOMEはアプリも豊富だ。Mozillaアプリ群やOpenOffice.org、GIMP、Inkscapeなどメジャーなアプリがある。PDA用途のGPE:(The GPE Palmtop Environment)もある。
そういえば、XMLデータ形式のGUIビルダーのGlade(http://glade.gnome.org/)がある。
スマートフォン用のGladeがあれば、開発者はGUIの調律(チューニング)が楽だと思う。

自分としては好みでは無いがプログラマー人口の割りといるC#とMonoによる.NET環境は必要と考えている。MonoはGNOMEと親和性が高いみたいだ。Windows MobileのアプリもGoogle Androidに移植できるかどうかは不明だが、期待できるのではないかと考える。

マルチプラットホームやWebアプリのためにJava。携帯アプリもJavaだ。個人的にはJavaMEは制限が多いのでGoogleに賛成したい・・・マインドマップツールのFreeMindをJavaベースのアプリとして紹介する。文書管理サーバは、Nuxeo 5がいいかもしれない。

PKIセキュリティは"The Legion of the Bouncy Castle"がすばらしい。JavaとC#(Mono)に対応している。Cを使うならOpenXAdES.orgやxmlsec、NSS/OpenSSLあたりか。"ASN.1 Editor Plugin for Eclipse"というものもある。PDFでもそのうちXAdESが使えるようになるらしいと聞いた。2010年まで
RSA1024bitとSHA-1は使うのを止めよう。

PDF環境は、JavaベースのiTextとPDF Renderが使える。iText.NETやGNOMEアプリの"Evince document viewer"もある。ちなみにiTextは電子署名の付与・検証ができる。携帯電話でもPDFドキュメントのニーズは高いみたいだ。ワークフローでの利用から、電子ブックや電子漫画など利用価値が高いと思う。

フォントエディタは、Cベースで古いGUIのFontForge(誰かGNOMEに移植して欲しい。)とJavaベースのTypecastがある。文字デザインは大事だ。ドキュメントを長く残すためにも重要。とくに活版印刷の文字のような味のある日本語フォントの登場を望む。

KDEは確かに奇麗だが、存在するアプリがどれも中途半端に思える。またQtのライセンスも気になる。奇麗な実装が一番になるとは限らない。

個人的には環境は問題対策として紙から電子ファイルに移行すべきだと思う。そのためにISO化が進んでいるPDFとODFを推奨する。紙に置き換わるフォーマットとして一日の長があるPDFとXMLベースのODFと組み込みフォント用途のフリーなフォントが重要と考える。Embedded OpenType(EOT)のようにXMLでも組み込みフォントが使えるようになってほしいものだ。ページめくりなど紙の利便性を追求したアプリに今後期待したい。

Linuxが誕生した頃から考えるとかなり充実してきたという実感がある。しかし一般の人々が使える環境はまだまだこれからが勝負だと思う。
RIAやクラウドコンピューティングとアンドロイドの今後に注目したい。

2008年3月21日金曜日

Linuxの進化とアンドロイドとクラウドまで

Linux 0.95だか96だった頃のLinuxは、MINIXファイルシステムを採用した単純なモノリシックカーネルだった。
それがX11が動くという評判からクライアントOSとして認知され、GUI無しのサーバOSとして利用が進んだ。
組み込み用途に使えそうだと頑張った人たちもいた。ルーターやプリンターやストレージコントローラにも採用された。
拍車がかかったのは、インテルやIBM及びその他の大手ITベンダーがエンタープライズOSとしてテコ入れをしてからだと思う。その結果SCOが倒れてしまった・・・
日本もPANIXとかいつのまにか無くなった。
大学などを中心にクラスタリングが盛んになり、OSSのDBの分散化も相まって、Global File System(GFS)やFibreチャネルストレージまでLinuxで利用可能になった。
それがとうとうクラウドにまで進化しGFS(Google File System)にまでなったようだ。
この2つのGFSの関係性は知らない。
GSMの携帯電話にもLinuxは実装され、日本のNやPの携帯電話にまでも採用された。

今では、Linuxは組み込み用途、携帯電話、モバイルPC,グラフィックスWS、グループサーバ、エンタープライズサーバ、クラスタサーバ(含むスパコン)まで幅広く採用されることになった。幅広さで言えばTRONが目指したところとかなり被る。
TRONほどのリアルタイム性は無いにしてもロボットでも制御OSとして利用されている。これだけ広範囲に採用されたOSは珍しい。

その為、エンジニアにはありがたい。Linux一つでいろんな仕事ができるから。
以前は商用UNIXが必要だったこともLinuxで十分だったりする。
たぶんアンドロイドは、1つのLinuxパッケージとして市民権を得るかもしれない。
クラウドコンピューティングも当たり前になるかもしれない。
クラスタサーバ群を維持するのは大規模なサービス事業者のほうが回線のコストと効率やストレージコストと性能で絶対に有利だからだ。そしてDBの運用も。

RIAがどこまでクラウドコンピューティングを広めるキーになるのか今後が楽しみだ。

電波時計とPCのリアルタイムクロック

20日の書き込みをしようと文章を書いていたら、電波時計である腕時計がちょうど0時を鳴らしたのであせって投稿した。鳴り終わった頃に書き込んだので21日のブログになったかとあせったが、なんとか20日の日付になっていた。よかったよかった。そういえばグーグルのブログ表示には時刻は表示されないね。

いや本当は良くない!

編集画面で見るとなんと23:07となっている。腕時計は0:00のアラームが鳴り終えていた。(※ 後で気づいたのだが、20日はPCで書いていたので書き始めた時間が採用されているようですね。ただそれがどれだけ正しい時刻かは利用者からはわかりません。できれば投稿されるブログ記事としての採用される日時が何になるのか作成ページで表示されていると嬉しいです。)

電波時計はNICTの原子時計を基準にするUTCに電波により同期をしているので世界的にも正しい時間だ。それなのにグーグルのサーバはずれているということになる。通常はNTPで時刻を合わせるので一見すると正しい時間で動いているように思うのだが、NTPサーバの連携する段数が多いとだんだんと時刻はずれていく、これはクラスタリングされたサーバではあまりいいことではない。

自分が計画するならば、セシウム原子時計がコスト的に合わないのであれば、せめてルビジウム原子時計は導入を指示する。人によっては、GPSとタイムサーバでいいという人もいるが、その場合はタイムサーバを2系統用意させて一方をGPSと接続させ、片方を他の時刻ソース(経路の異なるもの)を使うように設計者に指示する。

以下に時刻合わせに関して面白いHPがある。

「電波時計+Clock Keeperの時刻精度の測定結果」

http://nap.dip.jp/~michi/soft/ClockKeeper/seido.html


PCの時計はいまだにRTCだ。精度も悪くWindows XPでようやくNTPが使われ始めたのだがコンシューマではまだまだ認知度は低いかと思う。MSも自社のNTPサーバを増強したようだが、この方式ではNTPサーバの提供者の負担が大きい。何故、電波時計を搭載しないのだろうか。

マキシムのDS5250チップなどは耐タンパな不揮発性機能付きクロックを持つみたいだ。これに電話時計モジュールを連動させてユーザーがPCや携帯電話などの時刻を勝手に変更できなくすべきではないかと思う。

なぜそんなことを望むかというと、迷惑メールで年月日が大幅にずれていてとっても迷惑なメールが非常に多いからだ。送信者は確信犯で意図的に日時をずらして設定し送っているはずだ。そんなことができないようにしてほしい。

内部時計はUTC世界協定時で動作させ、利用者の位置をGPS等で認識したらその土地の時刻で表示するようになれば、モバイル環境がとっても使いやすくなるはずだ。
是非、Google Androidでは時刻の正確性もテーマにして欲しい。

2008年3月20日木曜日

クラウドコンピューティング(Cloud Computing)

まったく雲を掴むような話だ。
昔と違ってサーバの実態がどこかに確実にあるかというと今は違う。
広域ロードバランス技術やルーティング技術、クラスタリング、分散ストレージなどの技術が進化したおかげで、インターネット上に存在するWebサービスが何処にあっても、PCや携帯電話端末からアクセスする人には遅いとか感じなくなってきた。まあ、検閲をしている国の場合は顕著に遅くなるのでストレスを感じるかな。
東京ー大阪間が数ミリとしたら東京ーサンフラン間は十数ミリぐらいな距離でしかないのでわからないだろう。欧州など他国はまだちょっと距離があるかも。

20年ぐらい前は、東京からサンフランシスコのサーバへアクセスするとリモートプロシージャコールでタイムアウトすることが多いくらいだったかな。今は百ミリを超えるような距離ではないのでタイムアウトなんて「そんなの関係ねー」とふざけて言えるぐらいだ。
GoogleとKDDIの新しい海底ケーブルが開通したら距離は東京ー大阪間と差があまりないかもしれない。たぶん北海道や九州から東京のほうが遠いかもしれない。

そうなってくると、安全のために実態のある場所は不明なほうがいい。利用者から見た場合、災害や事故があっても使えるほうがいい。
KDDIがZigBeeを用いて混雑して輻輳するような場所でもストレスなく使える技術の発表をしたが、歓迎できることだ。通常、PHSや携帯電話(データ通信含む)は展示会場などまともに使えないことがおおい。地震災害などあったばあいも極端に輻輳するので使えなくなる。
ZigBeeは電話交換機のような網制御を取り入れているので使えるようなので、個人的には非常に好みな通信技術だ。
電話交換網はだんだんと無くなろうとしている。自分が社会に出たときにデジタル化された電話網だが、インターネットに移り変わろうとしている。NTTもNGNというクローズドIP網に変わろうとしている。
フレッツの分断された地域網が横に全て繋がるようなのでよいのかも・・・
昔のD60交換機が懐かしいかな。といっても勉強のため展示されているものを見ただけだが、中を開けると某社の構成部品が7割ぐらいだった覚えがある。今はルーターが交換機の変わりだ。
確かその当時は、中○の交換網などは既にアナログ交換網のケーブルなどボロボロでデジタル化の全盛期で先輩がよく長期海外出張していた。今では沿岸部は海外とかわらないみたい。

そう、今では主要な世界都市と準都市はインターネットによってせいぜい百ミリ以下の距離でしかない。それだけ近づいたということだね。
だからクラウド(雲)なんていう表現ができるほど一瞬で大量のデータを転送できるようになったからこそ分散化や広域化が実現できるのだろう。5年ちょい前ぐらいは国際間のデータ転送は速度はあってもコストが高かったものだがね。

2008年3月19日水曜日

LEDで文字表示と心拍測定機能の表示機能の兼用

PUMA CARDIAC ブラック A4.1 心拍測定機能付き メンズ 時計
http://astore.amazon.co.jp/puma04-22/detail/B000WF7K06
のLEDみたいなものが、Androidスマートフォンに付いていて、機能的には実は・・・Nokia3220のように手を振ったらLEDで文字を表示する機能だったら、山で遭難した時に役立つと思う。
http://plusd.itmedia.co.jp/mobile/articles/0406/14/news063.html?c
心拍測定機能もあれば、スポーツだけでなく介護や救急対応に活躍できるはず。
デジフラッシュみたいなLED配置なら時系列でパフォーマンスメータのような表示もできるかも。
http://www.elekit.co.jp/product/promo/digiflash/index.php

メタボで悩む諸兄は、海や山などのフィールドに出よう。こんな機能がスマートフォンにあればきっと助かると思うのだが・・・

2008年3月18日火曜日

めざすもの

今、自分が実現したいことは、Google Androidを搭載したHTC S710 (http://www.htc.com/www/product.aspx?id=568)スマートフォンのような端末でラジコン・プロポのアプリケーションを動かし、遠隔操作で二足歩行のアンドロイド(ロボット)を動かすこと。感覚的には、ビデオカメラを搭載したラジコン・ヘリコプターみたいなものかな。

もう一つは、携帯電話でICカード化された運転免許証などを認証してAndroid端末から公的なサービスなどへのアクセスを実現すること。

先は長そうだ。

今日は、voitでグーグルのブログを解説しようとしたが、既に取られていた。しかたがなく、関連するキーワードを追加してこのブログを開設した。ググってみて驚いた。Googleとは仲良くしようと思う。。。
このブログは、できるかぎりZaurusで作文することに決めた。 所有している2台のザウルスを活用しようと思う。

以前は、独自ドメインでホームページを開設していたが、光りへの移行時にIPアドレスが値上がったのでやめてしまった。しばらくドメインを放置していたので、間借りする方針に趣旨変えをした。自分でシステムを維持することはけっこう時間がかかるものだ。間借りは楽だ。

振り返ると、つい少し前にLinuxが誕生したと思ったら、もうAndroidが誕生したことが非常に嬉しいことに気づいた。またモチベーションが上がってきたことに感激した。タネンバウム教授とリーナスがOS論争でケンカしたのが懐かしい。今、マイクロカーネルとモノリシックカーネルの競争は、Apple iPhoneとGoogle Androidになった。Windoes NTもSolaris2.0も過去のものになってしまった。シンビアンOSもマイクロカーネルだ。

Windows Mobileは、フリーズしてしまうのでシンビアンを支持したいが、シンビアンにも痛い目にあったので、やっぱりLinux系パッケージを支持することにした。セキュリティは大事だ。。。TCG TPM/MTM対応環境は、Linux環境にはそろっている。マイクロソフトもセキュリティはソース公開が正解だと頷いてしまうこの頃だ。

セキュリティと言えばということで、ICカードに話を移すが、日本はFelicaが圧倒的に普及してしまったので、標準化されたTypeB非接触とFelicaを支持することにする。私の古い住民基本台帳ICカードは接触型のみ対応なので、とうに切れた公的個人の電子証明書の再取得時には取り直しにして非接触に環境を揃えようと決めた。

日本では、電子署名法があるのでタイミングをみて解説もしたいと考えている。誰も興味無いかな? 改正の動きが見えないので、何か情報を掴んだら書こうと思う。
Googleがナレッジマネジメント「knol」をやるみたいだが、実名ではなく、ペンネームで執筆できることを望む。自分の換金できるものは知識・経験・情報だろうと思っているのでknolには興味がある。このブログから同じペンネームのknolコンテンツをリンクさせたいと思う。

そんな話よりロボットのほうが、良いだろうから、本日の〆として、ホンダのアシモについて一言。ちょっと前にショーの準備を見学した時はクレーンでつっていたのが、今では自ら走れるのには感激の思いだ。日本のロボット技術にはもっともっと頑張って欲しいと切望する。いつかは、動かなくなった身体の部品を換えたくなるかもしれないから。

面白い時代になりそうだ。