ロボットの目としての画像処理も高度になれば画像処理も重くなる。
そのためにARMプロセッサーを複数、通信させてクラスタ化するのはどうだろうか。
その為に、OpenMOSIXとOpenGFSを応用してはどうだろうか。
OpenMOSIX http://sourceforge.net/projects/openmosix/
OpenGFSは、Open Global FileSystem http://sourceforge.net/projects/opengfs/
OpenMOSIXのOpenMFSを使うのは軽いかもしれない。
このGFSは「Google File System」ではない。
2008年3月31日月曜日
ロボットの目
今日は本を紹介する。
「ロボットの目をつくる」 という本。
副題が「二足歩行ロボットにカメラをつけて画像処理」だ。
ロボットが自律歩行するには画像処理は重要。
参考までにアシモ君の写真を掲載する。撮影許可は当時に頂いたものだ。随分古い写真だけどどう？
私が撮影したものだ。他人のパクリではない。当時ＮＤＡは無い。特段に禁止事項は何も言われてもいない。
「ロボットの目をつくる」 という本。
副題が「二足歩行ロボットにカメラをつけて画像処理」だ。
ロボットが自律歩行するには画像処理は重要。
参考までにアシモ君の写真を掲載する。撮影許可は当時に頂いたものだ。随分古い写真だけどどう？
私が撮影したものだ。他人のパクリではない。当時ＮＤＡは無い。特段に禁止事項は何も言われてもいない。
2008年3月29日土曜日
２００２年に撮影したロボットmorphの写真
以前、個人的に取材・撮影させて頂き許可を得て自分のホームページに掲載していたmorphの写真だ。今、改めてみても綺麗なロボットだ。２００１年当時の過去記事は今も見れる。
Google Androidで携帯電話会社（キャリア）のビジネスはかわるのか？
日本アンドロイド・ユーザー・グループで表題の投稿があった。
http://www.android-ja.net/modules/d3forum/index.php?topic_id=97
ここではGoogleへの検索トラフィックに応じた収入がキャリアがGoogleから得られると書いてある。
それも一つのビジネスなんだろう。
自分も利用者の一人としては、通話料や特にデータ通信料金は定額であってほしい。
じゃないと携帯電話からGoogleへなんてアクセスはしないだろう。
ということは、これまでのビジネスモデルと差し引きGoogleと組んだほうが特なのだろうか・・・
たぶんそうなのだろう。すごいものだ。
自分は、古い携帯電話も程度の良いものは再利用すべきと思う。もちろん広告付きでね。
http://www.android-ja.net/modules/d3forum/index.php?topic_id=97
ここではGoogleへの検索トラフィックに応じた収入がキャリアがGoogleから得られると書いてある。
それも一つのビジネスなんだろう。
自分も利用者の一人としては、通話料や特にデータ通信料金は定額であってほしい。
じゃないと携帯電話からGoogleへなんてアクセスはしないだろう。
ということは、これまでのビジネスモデルと差し引きGoogleと組んだほうが特なのだろうか・・・
たぶんそうなのだろう。すごいものだ。
自分は、古い携帯電話も程度の良いものは再利用すべきと思う。もちろん広告付きでね。
Ｊａｖａ２プラットホーム
Google Androidに搭載したグーグル独自のJava実行環境DalvikがＳｕｎと昨年もめたがその後どうなったのだろうか。まあ、両社は仲良しだから大丈夫と思うが。。。
Ｊａｖａ２プラットホームはＪ２ＭＥ関連がややこしい。
それに重たい。グーグルの意見ももっともだと自分は思う。Ｊａｖａもオープンソース化したんだからお互いに歩み寄ってほしい。
個人的には、Ｊ２ＳＥとＪ２ＭＥは同じＡＰＩにしてほしい。もうＡＲＭプロセッサーなどＰＣ用ＣＰＵと遜色ない状況で制限したＡＰＩやメモリ空間は苦痛でしかない。
アンドロイドでさくさくと使いたい。
「ＰＤＦでの透明の処理についてのメモ」と標準化関連情報
過去に、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をＷｅｂから起動してみたが・・・起動先は以下：
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
めずらしくＰＤＦのセキュリティを書かれている人がいるなーと思って見たらアドビ社のサーバを使っての話でした。
Adobe Acrobat SEやPROでも電子署名やタイムスタンプの付与・検証はできる。
iTextでも電子署名とかできる。以下を参照のこと。
http://itextpdf.sourceforge.net/howtosign.html
しかし、SunのPDF-Renderでは、署名が付いていることすらわからない・・・（残念！）
まだまだ有償ソフトが必要ということかな。
ところでＰＤＦがＩＳＯ化された。番号は、ISO 32000 だ。
参考になるブログは以下：
http://blog.antenna.co.jp/PDFTool/archives/2008/03/24/#001004
これでＰＤＦは安心して使える？ＩＳＯの仕様書を買いたくない人は、アドビのＰＤＦ１．７仕様書を見よう。
http://www.adobe.com/devnet/pdf/pdf_reference.html
ちなみにＯＤＦは、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
ＯＤＦはＪＩＳ化作業中だ。
村田氏のＸＭＬブログに情報がある。MS Office OpenXML(OOXML)についてもここに情報がある。
http://www.xmlmaster.org/murata/
ＰＤＦもＯＤＦもＩＳＯ化されたので安心して使える。
「萩さん日記」：透過レイヤーを含む 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をＷｅｂから起動してみたが・・・起動先は以下：
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
めずらしくＰＤＦのセキュリティを書かれている人がいるなーと思って見たらアドビ社のサーバを使っての話でした。
Adobe Acrobat SEやPROでも電子署名やタイムスタンプの付与・検証はできる。
iTextでも電子署名とかできる。以下を参照のこと。
http://itextpdf.sourceforge.net/howtosign.html
しかし、SunのPDF-Renderでは、署名が付いていることすらわからない・・・（残念！）
まだまだ有償ソフトが必要ということかな。
ところでＰＤＦがＩＳＯ化された。番号は、ISO 32000 だ。
参考になるブログは以下：
http://blog.antenna.co.jp/PDFTool/archives/2008/03/24/#001004
これでＰＤＦは安心して使える？ＩＳＯの仕様書を買いたくない人は、アドビのＰＤＦ１．７仕様書を見よう。
http://www.adobe.com/devnet/pdf/pdf_reference.html
ちなみにＯＤＦは、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
ＯＤＦはＪＩＳ化作業中だ。
村田氏のＸＭＬブログに情報がある。MS Office OpenXML(OOXML)についてもここに情報がある。
http://www.xmlmaster.org/murata/
ＰＤＦもＯＤＦもＩＳＯ化されたので安心して使える。
2008年3月28日金曜日
欲しいミニバンＳＵＶとカーナビ
５人で乗るにしてもアルファードやエルグランドのような大き目のミニバンは３列目に横に寝れるのが嬉しい。３列目をベットにする人は沢山いるのではなかろうか。
今、気に入っているのは日産フォーラム・コンセプト。次期エルグランドだ。
http://corism.221616.com/articles/0000074043/
でも５人乗りに絞るなら、ＶＷトゥアレグだ。
http://www.volkswagen.co.jp/cars/touareg/index.html
エアサスによる抜群な車高調整は優れもので川も渡れるほどだ。普段は車高を下げておき、アウトドアで遊ぶときは車高を上げて悪路・雪道を走りたいものだ。
デザイン的にはランドローバーコンセプトＬＲＸがすばらしい。日産も次期エルグランドでまねしてほしいデザインだ。これなら真似していても嬉しい。
http://www.carview.co.jp/news/2/65416/
これら３車をミックスした８人乗りが欲しい。
ただし、２列目シートは現状のエルグランドの形でいいかなと思う。２列目中央のシートが単独スライドするのは便利そうだ。あまりシートには凝る必要はないと思う。
ＳＵＶ型のミニバンが欲しいといってもデリカはちょっと小さい。またハンドリングに不満がある。
高速道路はスカイライン程度には走ってほしい。エルグランドＨＰＳには興味がある。
http://www.autech.jp/SV/ELGRANDRIDER/SPECIAL/index.html
ＧＴ－ＲベースのＳＵＶが出るなら「ＧＴ－ＲベースのＳＵＶ」をベースに８人のりミニバンを作って世間を驚かせるのも有りかもしれない。この前に路上でみたＧＴ－Ｒは存在感があって見とれてしまった。
でも低い車高の車にはもう乗る気はない。クリーンディーゼルのＧＴ－Ｒ＋ＳＵＶ＋ミニバンが欲しい。
有り得ないトルクの化けもの車で悠々とクルージングしてみたいところだ。カイエンが後ろから煽ってきてもきっと怖くないだろう。
そんな車に装備するカーナビは、モバイルＷｉＭＡＸで通信し、Google MAP連動のものがいい。
もちろん通信できないときでも車内の地図データで利用できるのは当たり前だ。
カーナビのＯＳはアンドロイドであってほしい。オービスＭＡＰは常に更新してほしい。
そしてちゃんと５００ｍｍ手間で安全運転を自動的に呼びかけてほしい。長距離や他所の土地では事前の標識を見落としがちになるからだ。
交通渋滞情報も自動的に教えて欲しい。迂回路のアドバイスもあると嬉しい。
Androidスマートフォンを持って旅に出かけたい。降りてからもＰＮＤとしてのアンドロイドの機能があれば街中を散策できる。そしてお勧めの店に入ろう。
今、気に入っているのは日産フォーラム・コンセプト。次期エルグランドだ。
http://corism.221616.com/articles/0000074043/
でも５人乗りに絞るなら、ＶＷトゥアレグだ。
http://www.volkswagen.co.jp/cars/touareg/index.html
エアサスによる抜群な車高調整は優れもので川も渡れるほどだ。普段は車高を下げておき、アウトドアで遊ぶときは車高を上げて悪路・雪道を走りたいものだ。
デザイン的にはランドローバーコンセプトＬＲＸがすばらしい。日産も次期エルグランドでまねしてほしいデザインだ。これなら真似していても嬉しい。
http://www.carview.co.jp/news/2/65416/
これら３車をミックスした８人乗りが欲しい。
ただし、２列目シートは現状のエルグランドの形でいいかなと思う。２列目中央のシートが単独スライドするのは便利そうだ。あまりシートには凝る必要はないと思う。
ＳＵＶ型のミニバンが欲しいといってもデリカはちょっと小さい。またハンドリングに不満がある。
高速道路はスカイライン程度には走ってほしい。エルグランドＨＰＳには興味がある。
http://www.autech.jp/SV/ELGRANDRIDER/SPECIAL/index.html
ＧＴ－ＲベースのＳＵＶが出るなら「ＧＴ－ＲベースのＳＵＶ」をベースに８人のりミニバンを作って世間を驚かせるのも有りかもしれない。この前に路上でみたＧＴ－Ｒは存在感があって見とれてしまった。
でも低い車高の車にはもう乗る気はない。クリーンディーゼルのＧＴ－Ｒ＋ＳＵＶ＋ミニバンが欲しい。
有り得ないトルクの化けもの車で悠々とクルージングしてみたいところだ。カイエンが後ろから煽ってきてもきっと怖くないだろう。
そんな車に装備するカーナビは、モバイルＷｉＭＡＸで通信し、Google MAP連動のものがいい。
もちろん通信できないときでも車内の地図データで利用できるのは当たり前だ。
カーナビのＯＳはアンドロイドであってほしい。オービスＭＡＰは常に更新してほしい。
そしてちゃんと５００ｍｍ手間で安全運転を自動的に呼びかけてほしい。長距離や他所の土地では事前の標識を見落としがちになるからだ。
交通渋滞情報も自動的に教えて欲しい。迂回路のアドバイスもあると嬉しい。
Androidスマートフォンを持って旅に出かけたい。降りてからもＰＮＤとしてのアンドロイドの機能があれば街中を散策できる。そしてお勧めの店に入ろう。
2008年3月27日木曜日
iタウンページ・ガジェットとＧＰＳ
英語版のイエローページ・ガジェットがあるが日本語のiタウンページ・ガジェットがない。http://desktop.google.com/plugins/i/USYellowPagessearch.html?hl=ja
探してみたら「iタウンページBLOGパーツ」というものを見つけた。http://townq.net/exp/about.html
Google AndroidをＮＴＴドコモさんが採用するならば、是非 iタウンページのガジェットを出してくださいね。そして、ＧＰＳを使って近隣のスーパーのチラシ情報から最安値リストを提供してくれれば、携帯電話を見ながらお店に買いに行きますよ。ついでにクーポンも提供してくれて割り引けるならＦＯＭＡを使い続けるモチベーションになると思う。ついでにＩＤで支払いをする気になるかも。今はＩＤは使っていないです。普通のお財布派です。
またお店の前でＧＰＳ情報でそのお店やＳＣ内部の各店舗のクーポン一覧を提供してくれるととっても嬉しい！
また、お財布ケイータイで地域ポイントカードの代用が斬新。
http://business.nikkeibp.co.jp/article/topics/20080325/151157/
ところでＦＯＭＡといえば・・・新しい、Ｐ５０９ｉＴＶがちょっといいかもと思った。http://www.nttdocomo.co.jp/product/foma/905i/p905itv/index.html
大きな液晶が魅力だ。タッチ操作が是非欲しい。
でもＥＭ・ＯＭＥαに通話機能とiモード・メール機能が付いたら欲しい。http://www.sharp.co.jp/em/s01sh/
もちろんアンドロイドも使いたい。でもフリーズするＯＳやハッキングされるＯＳは欲しくない。
長期署名と「真偽を確定する論理」
長期署名がJIS X 5092(CAdES)、JIS X 5093(XAdES)が官報公告されている。
http://kanpou.npb.go.jp/20080321/20080321g00057/20080321g000570057f.html
日本もとうとうETSIに影響されたようだが、利用者が理解できるか疑問だ。
ところで「真偽を確定する論理」とググると結構面白い。
長期署名は本当に「真偽を確定」できるのだとうか・・・
日本の法律は所詮は「記名押印に代えて・・・」の世界で、法によって改ざん防止が条文に出てくる程度だ。どの法律にもお上のガイドラインにも長期署名が必要とは書いてないのでは？？？
ES-X-Long程度なら電子署名に使った電子証明書の有効期間後も検証可能なので、まあいいかなと思うが、失効情報の猶予期間なる論理ははてさて実際の運用に合致するのか、またエンドユーザーが受け入れられるのかわからん。
印鑑や直筆署名と同じレベルで利用できないと長期署名に置き換える気がしないのではなかろうか。
日本の印鑑って権威の象徴みたいな部分もあるので電子署名が馴染み難いかも。
個人の実印だって象牙とか小難しい印影にするのは、その影響かなと思う。単に偽造し難いだけとは思えない。現在ではコンピュータで簡単に偽造できる印影だが十分機能しているのだから電子署名も簡単に使えるぐらいが丁度良いはず。
Googleさんはどう思う？ 見解を教えて欲しい。
http://kanpou.npb.go.jp/20080321/20080321g00057/20080321g000570057f.html
日本もとうとうETSIに影響されたようだが、利用者が理解できるか疑問だ。
ところで「真偽を確定する論理」とググると結構面白い。
長期署名は本当に「真偽を確定」できるのだとうか・・・
日本の法律は所詮は「記名押印に代えて・・・」の世界で、法によって改ざん防止が条文に出てくる程度だ。どの法律にもお上のガイドラインにも長期署名が必要とは書いてないのでは？？？
ES-X-Long程度なら電子署名に使った電子証明書の有効期間後も検証可能なので、まあいいかなと思うが、失効情報の猶予期間なる論理ははてさて実際の運用に合致するのか、またエンドユーザーが受け入れられるのかわからん。
印鑑や直筆署名と同じレベルで利用できないと長期署名に置き換える気がしないのではなかろうか。
日本の印鑑って権威の象徴みたいな部分もあるので電子署名が馴染み難いかも。
個人の実印だって象牙とか小難しい印影にするのは、その影響かなと思う。単に偽造し難いだけとは思えない。現在ではコンピュータで簡単に偽造できる印影だが十分機能しているのだから電子署名も簡単に使えるぐらいが丁度良いはず。
Googleさんはどう思う？ 見解を教えて欲しい。
クラウド・コンピューティング（cloud computing）【２回目】
レイヤーとして見ると
・OpenID、ガジェット、Ｗｅｂサービス、SaaS、クラスタ、IDC、DBなどで構成されたサービスを 誰もが見える雲に例えてアクセスするような新世代コンピューティング環境。 サービス間の連携が自由にできるのが特徴。
・マルチスレッド、マルチプロセス、オブジェクト、SOA等のビジネスロジックなどのアプリケーション環境。
・デバイスドライバ、マルチスレッド・カーネル、マイクロカーネル＆サブシステムモジュール化カーネルなどのＯＳ環境。
コンピュータ環境は、雲のように水蒸気の粒から小さな雲ができ、雲の集合体が成長する。羊雲にも、積乱雲にも、台風にもなる。コンピュータも雲に例えられるようなものになってきたといこと。おぼろ雲みたいなサービスは小さなＷｅｂサービスの集まりみたいだ。クラスタ化が一般的になり、広域ロードバランサの発達なども影響して地球規模でサービスが構築できる。利用者から概念的には、これまでと大きく違うのはパッケージソフトを買ってきてインストールするのとも違う。ネットワークが発達したおかげで流通は物流からダウンロードに代わってきた。従来のＯＳ環境の一部であるデスクトップまでもがＷｅｂサービスになり、ＲＩＡでどこでも使えるアプリが実現している。マージンを取る中間者がいない。そして安いし、無料やオープンソースまで豊富にある。見るだけなら雲はタダだが、雲を作るには膨大な費用がかかる。水蒸気を作るだけならヤカンで湯を沸かせばよい。雲が勝手に雨を降らせるのはタダだが、人工的に雲を呼び雨を降らせるにはクラウドシーディング（Cloud seeding）とかするらしい。どこかの国の山奥では、ロケット花火を打ち上げて人工降雨をやっているらしい。コストがかかる何かをしないと雨を降らすことはできない。
昔は、集中型のホストコンピュータが主流で、オープンシステムのクライアント／サーバ環境、分散コンピューティングやらと実態ありきの考えだった。今では、実態を包み隠し細胞が増えるがごとく増殖できるコンピュータ環境となった。それがクラウド・コンピューティングだと思う。
強さについては、昔とあまり考え方が代わらないかなと思う。ＩＤＣに設置するインフラの規模、つまりＣＰＵパワーの大きさと、回線の大域の太さ、ストレージの大きさなどがビジネスパワーに繋がっている。貧乏人はコバンザメに徹するとオコボレにあずかり安心してビジネスができる。Googleはさしずめジンベイザメかな。大規模なデータセンターほどビジネス効果が得られる。回線は回線を保有するキャリアが有利だが、大量に借りる事業者は神様のごとく有利だ。ストレージやサーバを買うのも大量に買うほうが有利。大きなショッピングセンターとビジネス集約化の考えは同じということか。町の商店街がつぶれるのと似たような弊害はきっとあるのだろう。
ＩＤＣでは免税軽油が使える？
ＩＤＣで軽油を使う場合、電気通信設備の電源の用途に供するなどの道路以外の用途なので法的には税の対象からはずれる。ディーゼルの自家発電によるコストと他の電力供給とコスト比較をしたはないが、この減税効果は大きいと思う。少なくともバックアップ電源としてのディーゼル自家発電のために申請するメリットがある。大量に軽油を使う場合はこの減税効果は大きい。従って大規模ＩＤＣに有利だ。
2008年3月26日水曜日
ロータリー・ディーゼル・エンジン・ハイブリッドがあったなら
最近は、自動車も数十個から百数十個のＣＰＵを搭載し車内ネットワークがある。
家電がコンピュータによりデジタル化したのが少し前のトレンドだったが今は自動車のデジタル化がトレンドだ。ハンドル制御からアクセル制御などさまざまなデジタル化が進んでいる。
エンジン制御は早くからコンピュータ制御になっている。
そんなわけで、自動車のエンジンについて一言。
クリーン・ディーゼルとしてのロータリー・エンジンが存在し、軽油で走行できるならばロータリーの課題であるトルク増強が楽にできるはず。またホンダ方式のハイブリッド・モータのようにローターの３つ目を薄型モーターにすることにより低速時のトルクを稼げる。
マツダはロータリー・エンジンをフロント縦置きにしたがるが、個人的にはＦＦもしくはＲＲにすべきだと思う。フロント縦置きだとモーターボートと同じく回転による慣性モーメントがハンドリングを邪魔をする。
三菱自動車のアイのような発想はできないものだろうか・・・
またマツダは電子制御に弱く、デジタル化が遅れているように見える。昔のマツダのエンジンはどれもストールを起こしやすかった。エンジンの燃料制御がちゃんとしていれば大丈夫だと思うのだが・・・
ディーゼルエンジンは、軽油は地方税なので、自治体はクリーン・ディーゼルを推奨すれば田舎でも税収があがるはず。ディーゼルカーを購入時に価格アップ分の減税をすれば利用者は増えると思う。
今、都の某銀行で悪評が高い知事のおかげで日本からディーゼルが消えて、軽油の地方税としての収入はトラックやバスに頼っているのが現状だが、これに自家用車が昔以上に増えれば地方の財政は楽になるのではないのだろうか・・・
ついでにカーナビもグーグル・マップと連携し、新しい道路の発見と地図データの更新をタイムリー化できれば開発の進むニュータウンなどはより便利になる。
現状の仕組みでは早いペースで開発が進む地域のカーナビ対応は無理があるというもの。これまでの手法や体制では改善できるとは思えないので提案をする。
家電がコンピュータによりデジタル化したのが少し前のトレンドだったが今は自動車のデジタル化がトレンドだ。ハンドル制御からアクセル制御などさまざまなデジタル化が進んでいる。
エンジン制御は早くからコンピュータ制御になっている。
そんなわけで、自動車のエンジンについて一言。
クリーン・ディーゼルとしてのロータリー・エンジンが存在し、軽油で走行できるならばロータリーの課題であるトルク増強が楽にできるはず。またホンダ方式のハイブリッド・モータのようにローターの３つ目を薄型モーターにすることにより低速時のトルクを稼げる。
マツダはロータリー・エンジンをフロント縦置きにしたがるが、個人的にはＦＦもしくはＲＲにすべきだと思う。フロント縦置きだとモーターボートと同じく回転による慣性モーメントがハンドリングを邪魔をする。
三菱自動車のアイのような発想はできないものだろうか・・・
またマツダは電子制御に弱く、デジタル化が遅れているように見える。昔のマツダのエンジンはどれもストールを起こしやすかった。エンジンの燃料制御がちゃんとしていれば大丈夫だと思うのだが・・・
ディーゼルエンジンは、軽油は地方税なので、自治体はクリーン・ディーゼルを推奨すれば田舎でも税収があがるはず。ディーゼルカーを購入時に価格アップ分の減税をすれば利用者は増えると思う。
今、都の某銀行で悪評が高い知事のおかげで日本からディーゼルが消えて、軽油の地方税としての収入はトラックやバスに頼っているのが現状だが、これに自家用車が昔以上に増えれば地方の財政は楽になるのではないのだろうか・・・
ついでにカーナビもグーグル・マップと連携し、新しい道路の発見と地図データの更新をタイムリー化できれば開発の進むニュータウンなどはより便利になる。
現状の仕組みでは早いペースで開発が進む地域のカーナビ対応は無理があるというもの。これまでの手法や体制では改善できるとは思えないので提案をする。
Motus社のDarwinコントローラー
Ｗｉｉのコントローラのようなもの
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
こんなコントローラが、マルチコアＣＰＵの小型ＢＯＸでＢＤ－Ｒとか搭載したものがあって、Google Androidが搭載されていればＷｉｉみたいにつかえるのではないかと思うのだが・・・
家庭のコンピュータとして、携帯電話としても同じＯＳならお年寄りも子供も簡単に使える。
また、携帯電話は加速度センサーやＧＰＳを搭載するのでＷｉｉコントローラのような操作はできるはず。
操作系が共通ならば分かりやすいものです。
インテルさん、ゲーム機を作ってみてはどうかな？
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
こんなコントローラが、マルチコアＣＰＵの小型ＢＯＸでＢＤ－Ｒとか搭載したものがあって、Google Androidが搭載されていればＷｉｉみたいにつかえるのではないかと思うのだが・・・
家庭のコンピュータとして、携帯電話としても同じＯＳならお年寄りも子供も簡単に使える。
また、携帯電話は加速度センサーやＧＰＳを搭載するのでＷｉｉコントローラのような操作はできるはず。
操作系が共通ならば分かりやすいものです。
インテルさん、ゲーム機を作ってみてはどうかな？
FileMakerライクなカード型ＤＢサービスの必要性
未だにFileMakerの人気がＭａｃとWindows両用環境及びグラフィックの含むアプリの作成環境として人気がある。
Googleはサービスを作らないのだろうか？
もしＦｉｌｅＭａｋｅｒ互換なら、ＦｉｌｅＭａｋｅｒのアプリが移植できる。
例えば電子カルテが日米でFileMakerベースのオープンソース版があったりする。
特に日本ではFileMakerで作られた電子カルテなどが沢山存在する。
Googleはサービスを作らないのだろうか？
もしＦｉｌｅＭａｋｅｒ互換なら、ＦｉｌｅＭａｋｅｒのアプリが移植できる。
例えば電子カルテが日米でFileMakerベースのオープンソース版があったりする。
特に日本ではFileMakerで作られた電子カルテなどが沢山存在する。
2008年3月25日火曜日
Ｏｆｆｉｃｅアプリの電子署名とＵＳＰＳのＥＰＭ電子消印
MS OfficeやOpenOffice.orgの電子署名機能には正直言って残念だとしか言えない。
理由は電子署名を付けても付けたのかどうか利用者にはわかりにくい。
Adobe Acrobatの不可視署名ぐらいは参考にすべきだと思う。
OpenOffice.orgの以前のバージョンで試したことがあるが、日本の電子署名法にもとづく認定認証業務発行の電子証明書による電子署名にはOpenOffice.org内部のＮＳＳが対応していない。だから署名できない。
利用者がほとんど居ないから誰も気づかないのが寂しい・・・
電子署名できるアプリケーションとしては、PDF系アプリが圧倒的だ。Adobe Acrobat、SkyPDF、アンテナハウスのPDF電子署名モジュールなどはどれも認定認証業務発行の電子証明書による電子署名に対応できている。
これらは、不可視署名や可視署名の機能があり、とっても分かりやすいと思う。
できればＯＤＦ系アプリは、せめてＵＳＰＳのＥＰＭみたいな機能を実装してほしい。
http://www.microsoft.com/japan/showcase/postalus.mspx http://www.usps.com/electronicpostmark/welcome.htm
iTextも電子署名が可能だが認定認証業務発行の電子証明書による電子署名は試したことがないのでなんともいえない。唯一の解説ページは以下。
http://itextpdf.sourceforge.net/howtosign.html
理由は電子署名を付けても付けたのかどうか利用者にはわかりにくい。
Adobe Acrobatの不可視署名ぐらいは参考にすべきだと思う。
OpenOffice.orgの以前のバージョンで試したことがあるが、日本の電子署名法にもとづく認定認証業務発行の電子証明書による電子署名にはOpenOffice.org内部のＮＳＳが対応していない。だから署名できない。
利用者がほとんど居ないから誰も気づかないのが寂しい・・・
電子署名できるアプリケーションとしては、PDF系アプリが圧倒的だ。Adobe Acrobat、SkyPDF、アンテナハウスのPDF電子署名モジュールなどはどれも認定認証業務発行の電子証明書による電子署名に対応できている。
これらは、不可視署名や可視署名の機能があり、とっても分かりやすいと思う。
できればＯＤＦ系アプリは、せめてＵＳＰＳのＥＰＭみたいな機能を実装してほしい。
http://www.microsoft.com/japan/showcase/postalus.mspx http://www.usps.com/electronicpostmark/welcome.htm
iTextも電子署名が可能だが認定認証業務発行の電子証明書による電子署名は試したことがないのでなんともいえない。唯一の解説ページは以下。
http://itextpdf.sourceforge.net/howtosign.html
安いノートＰＣとかＵＭＰＣのＯＳは・・・
最近Linux搭載の安価なノートＰＣがどんどん出てきた。とうとうＨＰまでも２１３３というモデルを発表した。どこのメーカーも何故か日本ではWindows・・・何故？
値が上がるだけでなく、サービスパックで少ない記憶領域があっというまにオーバーフローしないのだろうか？
最近のWindowsのサービスパックに嫌気がさしているとＭａｃＯＳ Ｘがとっても魅力的に見える。
マイクロカーネルMach3.0とサブシステムがFreeBSDのＵＮＩＸ系ＯＳのDarwinということをまったく意識させない垢抜けたＯＳだ。でもLinusがファイルシステムをけなしていたけどね。
NEXTSTEPはMach2.5べーすだったかと記憶にあるが、Mach3.0ベースでよくあそこまで実用的にしたと感心する。
単に実用だけを考えるとLinuxベースで垢抜けたＧＵＩを搭載できるばいいように思う。だからGoogle AndroidをHP 2133に搭載したらどうなんだろうかと創造した。きっとサクサク動くような気がする。
タブレット型兼用のノートＰＣならきっとアンドロイドがぴったりではないだろうか。
フラッシュメモリ系のシステムディスクを主流にする小型ＰＣはアンドロイドを搭載してみてはどうだろうか？ ＳｕｎのJavaより軽くて軽快ではないかな。
それからグーグルさんに提案なんだけど、ＯＳパッケージをＳＬＡＸ化しては如何だろうか。
ただしＧＵＩはＧＮＯＭＥとかこのブログの過去記事のお勧め環境でお願いしたい。
モジュールはインストールではなくダウンロードしモジュールへのマウントを変更するだけで更新できる。
利用者が安心したら古いモジュールのファイルを削除するのは簡単だ。
また、ＳＤメモリに開発中のＯＳバージョンを用意してＳＤブートが可能であればザウルスなどのファーム更新みたいな面倒なことをせずに動作検証ができる。絶対に楽だし工数も圧縮できるはず。
ノートＰＣとスマートフォンのＯＳが同じアンドロイドなら開発が楽ですね。
値が上がるだけでなく、サービスパックで少ない記憶領域があっというまにオーバーフローしないのだろうか？
最近のWindowsのサービスパックに嫌気がさしているとＭａｃＯＳ Ｘがとっても魅力的に見える。
マイクロカーネルMach3.0とサブシステムがFreeBSDのＵＮＩＸ系ＯＳのDarwinということをまったく意識させない垢抜けたＯＳだ。でもLinusがファイルシステムをけなしていたけどね。
NEXTSTEPはMach2.5べーすだったかと記憶にあるが、Mach3.0ベースでよくあそこまで実用的にしたと感心する。
単に実用だけを考えるとLinuxベースで垢抜けたＧＵＩを搭載できるばいいように思う。だからGoogle AndroidをHP 2133に搭載したらどうなんだろうかと創造した。きっとサクサク動くような気がする。
タブレット型兼用のノートＰＣならきっとアンドロイドがぴったりではないだろうか。
フラッシュメモリ系のシステムディスクを主流にする小型ＰＣはアンドロイドを搭載してみてはどうだろうか？ ＳｕｎのJavaより軽くて軽快ではないかな。
それからグーグルさんに提案なんだけど、ＯＳパッケージをＳＬＡＸ化しては如何だろうか。
ただしＧＵＩはＧＮＯＭＥとかこのブログの過去記事のお勧め環境でお願いしたい。
モジュールはインストールではなくダウンロードしモジュールへのマウントを変更するだけで更新できる。
利用者が安心したら古いモジュールのファイルを削除するのは簡単だ。
また、ＳＤメモリに開発中のＯＳバージョンを用意してＳＤブートが可能であればザウルスなどのファーム更新みたいな面倒なことをせずに動作検証ができる。絶対に楽だし工数も圧縮できるはず。
ノートＰＣとスマートフォンのＯＳが同じアンドロイドなら開発が楽ですね。
2008年3月24日月曜日
シンビアンＯＳ（Psion EPOC）
元々は、サイオン社のＰＤＡ用ＯＳであるＥＰＯＣとして始まったSymbian OSだが、ノキアの後押しもあって携帯電話では筆頭ＯＳと言える。
マイクロカーネルを採用し、バグを徹底的に排除するポリシーで開発がされているＯＳだけにＷＭのようにハングアップすることが極めて少ない。さすが数学者二人が創ったＯＳだ。正直惚れ惚れする。
しかし、アプリの開発者は元々はＰＣ上で育った人がベースだとしたらＷＭやLinux/Java系に負けるのではないかと予測する。（ＰＤＡでPalm OSがメジャーだったけどザウルスの人気が未だにあるのを見れば納得する諸兄は多いのではないだろうか・・・）
私がGoogleへ期待することは、Ｊａｖａ環境だけでなく追加でLinux GNOMEアプリの移植環境（ＧＰＥ？）の用意とWindowsアプリの移植環境（Ｃ＃とＭｏｎｏ）を用意することだ。
これによりＰＣで培ったノウハウやこれまでのアプリが簡単に移植できるはず。
独自路線はいつかは消える運命ではないだろうか。オープンソースは長く愛されると思う。
最近はマイクロソフトもオープンソース化に戦略変更しているようだが、本物だろうか？
意外とReactOSが急成長するだけかもしれないよ。＞ＭＳさん
マイクロカーネルを採用し、バグを徹底的に排除するポリシーで開発がされているＯＳだけにＷＭのようにハングアップすることが極めて少ない。さすが数学者二人が創ったＯＳだ。正直惚れ惚れする。
しかし、アプリの開発者は元々はＰＣ上で育った人がベースだとしたらＷＭやLinux/Java系に負けるのではないかと予測する。（ＰＤＡでPalm OSがメジャーだったけどザウルスの人気が未だにあるのを見れば納得する諸兄は多いのではないだろうか・・・）
私がGoogleへ期待することは、Ｊａｖａ環境だけでなく追加でLinux GNOMEアプリの移植環境（ＧＰＥ？）の用意とWindowsアプリの移植環境（Ｃ＃とＭｏｎｏ）を用意することだ。
これによりＰＣで培ったノウハウやこれまでのアプリが簡単に移植できるはず。
独自路線はいつかは消える運命ではないだろうか。オープンソースは長く愛されると思う。
最近はマイクロソフトもオープンソース化に戦略変更しているようだが、本物だろうか？
意外とReactOSが急成長するだけかもしれないよ。＞ＭＳさん
ＰＤＡ用のＬｉｎｕｘパッケージ
シャープのZaulus用に、OpenZaulusというパッケージがある。
ＱｔベースのOpieと、ＧＴＫ＋ベースのGPEの２つの環境を持つ。
OpieのＧＵＩはタブ型のデスクトップを持ってオリジナルのQtベースのシャープ・ザウルスのLinux環境に近い。
個人的には、Qtが元々がビジネスライクなライセンスに始まっているのでLinux愛好家としては心理的な抵抗がありアプリを作る気になれなかった。
シャープの努力（？）で、ザウルスでＪａｖａが使えるようになった時は喜んだが、シャープの中途半端な対応には正直がっかりしたものだ・・・
そんな気持ちもあり、Google AndroidがＪａｖａアプリを主体としているのを見て喜んだ。
しかし、AndroidでＧＮＯＭＥアプリやＭｏｎｏ環境によるC#.NETアプリが移植できるようになってほしいと切望する。
GNOMEアプリのＧｌａｄｅ ＧＵＩビルダーが扱えれば、ＸＭＬのＵＩ作成も楽になるのではないだろうか・・・
また、Windows Mobileアプリ作成者をアンドロイドに興味を向けるにはＭｏｎｏ環境は必須だと思う。
Googleには、シャープの中途半端なＬｉｎｕｘ戦略のようなことをして、前車の轍を踏まないで欲しい。
未だにZaulus愛好家が沢山いて、OS改造に励んだり、OpenZaulusやGoogle Androidに変えたりする人が絶えない。
シャープのLinuxを指揮する人が亡くなりWindows Mobileへの方針変更はザウルス愛好家をがっかりさせた。自分もハングアップするWMは嫌いだ。たとえＥＭ・ＯＮＥαの特売があってもLinuxが移植できることができない限りZaulusの代わりには使えないと心に誓うのだった。５月に販売されるウイルコムの新型機は、ＷＭでJIS2004日本語文字環境らしいが、Linuxの移植情報はリークして欲しい・・・
さもなければ、移植情報のあるＨＴＣが選択肢になるだけだと思うが・・・
今でも以下ＵＲＬへはアクセスできる・・・ （ザウルス愛好家へのメモ）
Ｓｕｎの「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
＃ この記事は丁度、０時のベルのなっているときに投稿作成のページに
＃ 入ってしばらく思案してから書きはじめた。
＃ ブログの記録時間としては０時丁度を指している。
＃ 電波時計の０時のベルで試した。
ＱｔベースのOpieと、ＧＴＫ＋ベースのGPEの２つの環境を持つ。
OpieのＧＵＩはタブ型のデスクトップを持ってオリジナルのQtベースのシャープ・ザウルスのLinux環境に近い。
個人的には、Qtが元々がビジネスライクなライセンスに始まっているのでLinux愛好家としては心理的な抵抗がありアプリを作る気になれなかった。
シャープの努力（？）で、ザウルスでＪａｖａが使えるようになった時は喜んだが、シャープの中途半端な対応には正直がっかりしたものだ・・・
そんな気持ちもあり、Google AndroidがＪａｖａアプリを主体としているのを見て喜んだ。
しかし、AndroidでＧＮＯＭＥアプリやＭｏｎｏ環境によるC#.NETアプリが移植できるようになってほしいと切望する。
GNOMEアプリのＧｌａｄｅ ＧＵＩビルダーが扱えれば、ＸＭＬのＵＩ作成も楽になるのではないだろうか・・・
また、Windows Mobileアプリ作成者をアンドロイドに興味を向けるにはＭｏｎｏ環境は必須だと思う。
Googleには、シャープの中途半端なＬｉｎｕｘ戦略のようなことをして、前車の轍を踏まないで欲しい。
未だにZaulus愛好家が沢山いて、OS改造に励んだり、OpenZaulusやGoogle Androidに変えたりする人が絶えない。
シャープのLinuxを指揮する人が亡くなりWindows Mobileへの方針変更はザウルス愛好家をがっかりさせた。自分もハングアップするWMは嫌いだ。たとえＥＭ・ＯＮＥαの特売があってもLinuxが移植できることができない限りZaulusの代わりには使えないと心に誓うのだった。５月に販売されるウイルコムの新型機は、ＷＭでJIS2004日本語文字環境らしいが、Linuxの移植情報はリークして欲しい・・・
さもなければ、移植情報のあるＨＴＣが選択肢になるだけだと思うが・・・
今でも以下ＵＲＬへはアクセスできる・・・ （ザウルス愛好家へのメモ）
Ｓｕｎの「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
＃ この記事は丁度、０時のベルのなっているときに投稿作成のページに
＃ 入ってしばらく思案してから書きはじめた。
＃ ブログの記録時間としては０時丁度を指している。
＃ 電波時計の０時のベルで試した。
2008年3月22日土曜日
お進めなLinux環境（アンドロイドにもお勧め？）
まず、OS屋さんはドライバーもカーネルやツールもＣ言語なので、Ｃ言語とGNOME環境。GTK＋アプリは、Windowsにも移植できる。GNOMEはアプリも豊富だ。Mozillaアプリ群やOpenOffice.org、GIMP、Inkscapeなどメジャーなアプリがある。PDA用途のGPE:（The GPE Palmtop Environment）もある。
そういえば、ＸＭＬデータ形式のＧＵＩビルダーのGlade(http://glade.gnome.org/)がある。
スマートフォン用のGladeがあれば、開発者はＧＵＩの調律（チューニング）が楽だと思う。
自分としては好みでは無いがプログラマー人口の割りといるＣ＃とMonoによる.NET環境は必要と考えている。MonoはGNOMEと親和性が高いみたいだ。Windows MobileのアプリもGoogle Androidに移植できるかどうかは不明だが、期待できるのではないかと考える。
マルチプラットホームやWebアプリのためにJava。携帯アプリもJavaだ。個人的にはJavaMEは制限が多いのでGoogleに賛成したい・・・マインドマップツールのFreeMindをJavaベースのアプリとして紹介する。文書管理サーバは、Nuxeo 5がいいかもしれない。
ＰＫＩセキュリティは"The Legion of the Bouncy Castle"がすばらしい。JavaとＣ＃（Mono）に対応している。Ｃを使うなら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は電子署名の付与・検証ができる。携帯電話でもＰＤＦドキュメントのニーズは高いみたいだ。ワークフローでの利用から、電子ブックや電子漫画など利用価値が高いと思う。
フォントエディタは、Ｃベースで古いＧＵＩのFontForge(誰かGNOMEに移植して欲しい。)とJavaベースのTypecastがある。文字デザインは大事だ。ドキュメントを長く残すためにも重要。とくに活版印刷の文字のような味のある日本語フォントの登場を望む。
ＫＤＥは確かに奇麗だが、存在するアプリがどれも中途半端に思える。またQtのライセンスも気になる。奇麗な実装が一番になるとは限らない。
個人的には環境は問題対策として紙から電子ファイルに移行すべきだと思う。そのためにISO化が進んでいるPDFとODFを推奨する。紙に置き換わるフォーマットとして一日の長があるPDFとXMLベースのODFと組み込みフォント用途のフリーなフォントが重要と考える。Embedded OpenType（EOT）のようにＸＭＬでも組み込みフォントが使えるようになってほしいものだ。ページめくりなど紙の利便性を追求したアプリに今後期待したい。
Linuxが誕生した頃から考えるとかなり充実してきたという実感がある。しかし一般の人々が使える環境はまだまだこれからが勝負だと思う。
RIAやクラウドコンピューティングとアンドロイドの今後に注目したい。
そういえば、ＸＭＬデータ形式のＧＵＩビルダーのGlade(http://glade.gnome.org/)がある。
スマートフォン用のGladeがあれば、開発者はＧＵＩの調律（チューニング）が楽だと思う。
自分としては好みでは無いがプログラマー人口の割りといるＣ＃とMonoによる.NET環境は必要と考えている。MonoはGNOMEと親和性が高いみたいだ。Windows MobileのアプリもGoogle Androidに移植できるかどうかは不明だが、期待できるのではないかと考える。
マルチプラットホームやWebアプリのためにJava。携帯アプリもJavaだ。個人的にはJavaMEは制限が多いのでGoogleに賛成したい・・・マインドマップツールのFreeMindをJavaベースのアプリとして紹介する。文書管理サーバは、Nuxeo 5がいいかもしれない。
ＰＫＩセキュリティは"The Legion of the Bouncy Castle"がすばらしい。JavaとＣ＃（Mono）に対応している。Ｃを使うなら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は電子署名の付与・検証ができる。携帯電話でもＰＤＦドキュメントのニーズは高いみたいだ。ワークフローでの利用から、電子ブックや電子漫画など利用価値が高いと思う。
フォントエディタは、Ｃベースで古いＧＵＩのFontForge(誰かGNOMEに移植して欲しい。)とJavaベースのTypecastがある。文字デザインは大事だ。ドキュメントを長く残すためにも重要。とくに活版印刷の文字のような味のある日本語フォントの登場を望む。
ＫＤＥは確かに奇麗だが、存在するアプリがどれも中途半端に思える。またQtのライセンスも気になる。奇麗な実装が一番になるとは限らない。
個人的には環境は問題対策として紙から電子ファイルに移行すべきだと思う。そのためにISO化が進んでいるPDFとODFを推奨する。紙に置き換わるフォーマットとして一日の長があるPDFとXMLベースのODFと組み込みフォント用途のフリーなフォントが重要と考える。Embedded OpenType（EOT）のようにＸＭＬでも組み込みフォントが使えるようになってほしいものだ。ページめくりなど紙の利便性を追求したアプリに今後期待したい。
Linuxが誕生した頃から考えるとかなり充実してきたという実感がある。しかし一般の人々が使える環境はまだまだこれからが勝負だと思う。
RIAやクラウドコンピューティングとアンドロイドの今後に注目したい。
2008年3月21日金曜日
Linuxの進化とアンドロイドとクラウドまで
Linux 0.95だか96だった頃のLinuxは、MINIXファイルシステムを採用した単純なモノリシックカーネルだった。
それがＸ１１が動くという評判からクライアントＯＳとして認知され、ＧＵＩ無しのサーバＯＳとして利用が進んだ。
組み込み用途に使えそうだと頑張った人たちもいた。ルーターやプリンターやストレージコントローラにも採用された。
拍車がかかったのは、インテルやＩＢＭ及びその他の大手ＩＴベンダーがエンタープライズＯＳとしてテコ入れをしてからだと思う。その結果ＳＣＯが倒れてしまった・・・
日本もPANIXとかいつのまにか無くなった。
大学などを中心にクラスタリングが盛んになり、ＯＳＳのＤＢの分散化も相まって、Global File System(GFS)やFibreチャネルストレージまでLinuxで利用可能になった。
それがとうとうクラウドにまで進化しGFS(Google File System)にまでなったようだ。
この２つのGFSの関係性は知らない。
ＧＳＭの携帯電話にもLinuxは実装され、日本のＮやＰの携帯電話にまでも採用された。
今では、Linuxは組み込み用途、携帯電話、モバイルＰＣ，グラフィックスＷＳ、グループサーバ、エンタープライズサーバ、クラスタサーバ（含むスパコン）まで幅広く採用されることになった。幅広さで言えばＴＲＯＮが目指したところとかなり被る。
TRONほどのリアルタイム性は無いにしてもロボットでも制御ＯＳとして利用されている。これだけ広範囲に採用されたＯＳは珍しい。
その為、エンジニアにはありがたい。Linux一つでいろんな仕事ができるから。
以前は商用ＵＮＩＸが必要だったこともLinuxで十分だったりする。
たぶんアンドロイドは、１つのLinuxパッケージとして市民権を得るかもしれない。
クラウドコンピューティングも当たり前になるかもしれない。
クラスタサーバ群を維持するのは大規模なサービス事業者のほうが回線のコストと効率やストレージコストと性能で絶対に有利だからだ。そしてＤＢの運用も。
ＲＩＡがどこまでクラウドコンピューティングを広めるキーになるのか今後が楽しみだ。
それがＸ１１が動くという評判からクライアントＯＳとして認知され、ＧＵＩ無しのサーバＯＳとして利用が進んだ。
組み込み用途に使えそうだと頑張った人たちもいた。ルーターやプリンターやストレージコントローラにも採用された。
拍車がかかったのは、インテルやＩＢＭ及びその他の大手ＩＴベンダーがエンタープライズＯＳとしてテコ入れをしてからだと思う。その結果ＳＣＯが倒れてしまった・・・
日本もPANIXとかいつのまにか無くなった。
大学などを中心にクラスタリングが盛んになり、ＯＳＳのＤＢの分散化も相まって、Global File System(GFS)やFibreチャネルストレージまでLinuxで利用可能になった。
それがとうとうクラウドにまで進化しGFS(Google File System)にまでなったようだ。
この２つのGFSの関係性は知らない。
ＧＳＭの携帯電話にもLinuxは実装され、日本のＮやＰの携帯電話にまでも採用された。
今では、Linuxは組み込み用途、携帯電話、モバイルＰＣ，グラフィックスＷＳ、グループサーバ、エンタープライズサーバ、クラスタサーバ（含むスパコン）まで幅広く採用されることになった。幅広さで言えばＴＲＯＮが目指したところとかなり被る。
TRONほどのリアルタイム性は無いにしてもロボットでも制御ＯＳとして利用されている。これだけ広範囲に採用されたＯＳは珍しい。
その為、エンジニアにはありがたい。Linux一つでいろんな仕事ができるから。
以前は商用ＵＮＩＸが必要だったこともLinuxで十分だったりする。
たぶんアンドロイドは、１つのLinuxパッケージとして市民権を得るかもしれない。
クラウドコンピューティングも当たり前になるかもしれない。
クラスタサーバ群を維持するのは大規模なサービス事業者のほうが回線のコストと効率やストレージコストと性能で絶対に有利だからだ。そしてＤＢの運用も。
ＲＩＡがどこまでクラウドコンピューティングを広めるキーになるのか今後が楽しみだ。
電波時計とＰＣのリアルタイムクロック
２０日の書き込みをしようと文章を書いていたら、電波時計である腕時計がちょうど０時を鳴らしたのであせって投稿した。鳴り終わった頃に書き込んだので２１日のブログになったかとあせったが、なんとか２０日の日付になっていた。よかったよかった。そういえばグーグルのブログ表示には時刻は表示されないね。
いや本当は良くない！
編集画面で見るとなんと２３：０７となっている。腕時計は０：００のアラームが鳴り終えていた。（※ 後で気づいたのだが、20日はＰＣで書いていたので書き始めた時間が採用されているようですね。ただそれがどれだけ正しい時刻かは利用者からはわかりません。できれば投稿されるブログ記事としての採用される日時が何になるのか作成ページで表示されていると嬉しいです。）
電波時計はＮＩＣＴの原子時計を基準にするＵＴＣに電波により同期をしているので世界的にも正しい時間だ。それなのにグーグルのサーバはずれているということになる。通常はＮＴＰで時刻を合わせるので一見すると正しい時間で動いているように思うのだが、ＮＴＰサーバの連携する段数が多いとだんだんと時刻はずれていく、これはクラスタリングされたサーバではあまりいいことではない。
自分が計画するならば、セシウム原子時計がコスト的に合わないのであれば、せめてルビジウム原子時計は導入を指示する。人によっては、ＧＰＳとタイムサーバでいいという人もいるが、その場合はタイムサーバを２系統用意させて一方をＧＰＳと接続させ、片方を他の時刻ソース（経路の異なるもの）を使うように設計者に指示する。
以下に時刻合わせに関して面白いＨＰがある。
「電波時計＋Clock Keeperの時刻精度の測定結果」
http://nap.dip.jp/~michi/soft/ClockKeeper/seido.html
ＰＣの時計はいまだにＲＴＣだ。精度も悪くWindows XPでようやくＮＴＰが使われ始めたのだがコンシューマではまだまだ認知度は低いかと思う。ＭＳも自社のＮＴＰサーバを増強したようだが、この方式ではＮＴＰサーバの提供者の負担が大きい。何故、電波時計を搭載しないのだろうか。
マキシムのＤＳ５２５０チップなどは耐タンパな不揮発性機能付きクロックを持つみたいだ。これに電話時計モジュールを連動させてユーザーがＰＣや携帯電話などの時刻を勝手に変更できなくすべきではないかと思う。
なぜそんなことを望むかというと、迷惑メールで年月日が大幅にずれていてとっても迷惑なメールが非常に多いからだ。送信者は確信犯で意図的に日時をずらして設定し送っているはずだ。そんなことができないようにしてほしい。
内部時計はＵＴＣ世界協定時で動作させ、利用者の位置をＧＰＳ等で認識したらその土地の時刻で表示するようになれば、モバイル環境がとっても使いやすくなるはずだ。
是非、Google Androidでは時刻の正確性もテーマにして欲しい。
2008年3月20日木曜日
クラウドコンピューティング（Cloud Computing）
まったく雲を掴むような話だ。
昔と違ってサーバの実態がどこかに確実にあるかというと今は違う。
広域ロードバランス技術やルーティング技術、クラスタリング、分散ストレージなどの技術が進化したおかげで、インターネット上に存在するＷｅｂサービスが何処にあっても、ＰＣや携帯電話端末からアクセスする人には遅いとか感じなくなってきた。まあ、検閲をしている国の場合は顕著に遅くなるのでストレスを感じるかな。
東京ー大阪間が数ミリとしたら東京ーサンフラン間は十数ミリぐらいな距離でしかないのでわからないだろう。欧州など他国はまだちょっと距離があるかも。
２０年ぐらい前は、東京からサンフランシスコのサーバへアクセスするとリモートプロシージャコールでタイムアウトすることが多いくらいだったかな。今は百ミリを超えるような距離ではないのでタイムアウトなんて「そんなの関係ねー」とふざけて言えるぐらいだ。
GoogleとKDDIの新しい海底ケーブルが開通したら距離は東京ー大阪間と差があまりないかもしれない。たぶん北海道や九州から東京のほうが遠いかもしれない。
そうなってくると、安全のために実態のある場所は不明なほうがいい。利用者から見た場合、災害や事故があっても使えるほうがいい。
ＫＤＤＩがZigBeeを用いて混雑して輻輳するような場所でもストレスなく使える技術の発表をしたが、歓迎できることだ。通常、ＰＨＳや携帯電話（データ通信含む）は展示会場などまともに使えないことがおおい。地震災害などあったばあいも極端に輻輳するので使えなくなる。
ZigBeeは電話交換機のような網制御を取り入れているので使えるようなので、個人的には非常に好みな通信技術だ。
電話交換網はだんだんと無くなろうとしている。自分が社会に出たときにデジタル化された電話網だが、インターネットに移り変わろうとしている。ＮＴＴもＮＧＮというクローズドＩＰ網に変わろうとしている。
フレッツの分断された地域網が横に全て繋がるようなのでよいのかも・・・
昔のＤ６０交換機が懐かしいかな。といっても勉強のため展示されているものを見ただけだが、中を開けると某社の構成部品が７割ぐらいだった覚えがある。今はルーターが交換機の変わりだ。
確かその当時は、中○の交換網などは既にアナログ交換網のケーブルなどボロボロでデジタル化の全盛期で先輩がよく長期海外出張していた。今では沿岸部は海外とかわらないみたい。
そう、今では主要な世界都市と準都市はインターネットによってせいぜい百ミリ以下の距離でしかない。それだけ近づいたということだね。
だからクラウド（雲）なんていう表現ができるほど一瞬で大量のデータを転送できるようになったからこそ分散化や広域化が実現できるのだろう。５年ちょい前ぐらいは国際間のデータ転送は速度はあってもコストが高かったものだがね。
昔と違ってサーバの実態がどこかに確実にあるかというと今は違う。
広域ロードバランス技術やルーティング技術、クラスタリング、分散ストレージなどの技術が進化したおかげで、インターネット上に存在するＷｅｂサービスが何処にあっても、ＰＣや携帯電話端末からアクセスする人には遅いとか感じなくなってきた。まあ、検閲をしている国の場合は顕著に遅くなるのでストレスを感じるかな。
東京ー大阪間が数ミリとしたら東京ーサンフラン間は十数ミリぐらいな距離でしかないのでわからないだろう。欧州など他国はまだちょっと距離があるかも。
２０年ぐらい前は、東京からサンフランシスコのサーバへアクセスするとリモートプロシージャコールでタイムアウトすることが多いくらいだったかな。今は百ミリを超えるような距離ではないのでタイムアウトなんて「そんなの関係ねー」とふざけて言えるぐらいだ。
GoogleとKDDIの新しい海底ケーブルが開通したら距離は東京ー大阪間と差があまりないかもしれない。たぶん北海道や九州から東京のほうが遠いかもしれない。
そうなってくると、安全のために実態のある場所は不明なほうがいい。利用者から見た場合、災害や事故があっても使えるほうがいい。
ＫＤＤＩがZigBeeを用いて混雑して輻輳するような場所でもストレスなく使える技術の発表をしたが、歓迎できることだ。通常、ＰＨＳや携帯電話（データ通信含む）は展示会場などまともに使えないことがおおい。地震災害などあったばあいも極端に輻輳するので使えなくなる。
ZigBeeは電話交換機のような網制御を取り入れているので使えるようなので、個人的には非常に好みな通信技術だ。
電話交換網はだんだんと無くなろうとしている。自分が社会に出たときにデジタル化された電話網だが、インターネットに移り変わろうとしている。ＮＴＴもＮＧＮというクローズドＩＰ網に変わろうとしている。
フレッツの分断された地域網が横に全て繋がるようなのでよいのかも・・・
昔のＤ６０交換機が懐かしいかな。といっても勉強のため展示されているものを見ただけだが、中を開けると某社の構成部品が７割ぐらいだった覚えがある。今はルーターが交換機の変わりだ。
確かその当時は、中○の交換網などは既にアナログ交換網のケーブルなどボロボロでデジタル化の全盛期で先輩がよく長期海外出張していた。今では沿岸部は海外とかわらないみたい。
そう、今では主要な世界都市と準都市はインターネットによってせいぜい百ミリ以下の距離でしかない。それだけ近づいたということだね。
だからクラウド（雲）なんていう表現ができるほど一瞬で大量のデータを転送できるようになったからこそ分散化や広域化が実現できるのだろう。５年ちょい前ぐらいは国際間のデータ転送は速度はあってもコストが高かったものだがね。
2008年3月19日水曜日
ＬＥＤで文字表示と心拍測定機能の表示機能の兼用
PUMA CARDIAC ブラック A4.1 心拍測定機能付き メンズ 時計
http://astore.amazon.co.jp/puma04-22/detail/B000WF7K06
のＬＥＤみたいなものが、Androidスマートフォンに付いていて、機能的には実は・・・Nokia3220のように手を振ったらLEDで文字を表示する機能だったら、山で遭難した時に役立つと思う。
http://plusd.itmedia.co.jp/mobile/articles/0406/14/news063.html?c
心拍測定機能もあれば、スポーツだけでなく介護や救急対応に活躍できるはず。
デジフラッシュみたいなＬＥＤ配置なら時系列でパフォーマンスメータのような表示もできるかも。
http://www.elekit.co.jp/product/promo/digiflash/index.php
メタボで悩む諸兄は、海や山などのフィールドに出よう。こんな機能がスマートフォンにあればきっと助かると思うのだが・・・
http://astore.amazon.co.jp/puma04-22/detail/B000WF7K06
のＬＥＤみたいなものが、Androidスマートフォンに付いていて、機能的には実は・・・Nokia3220のように手を振ったらLEDで文字を表示する機能だったら、山で遭難した時に役立つと思う。
http://plusd.itmedia.co.jp/mobile/articles/0406/14/news063.html?c
心拍測定機能もあれば、スポーツだけでなく介護や救急対応に活躍できるはず。
デジフラッシュみたいなＬＥＤ配置なら時系列でパフォーマンスメータのような表示もできるかも。
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）スマートフォンのような端末でラジコン・プロポのアプリケーションを動かし、遠隔操作で二足歩行のアンドロイド（ロボット）を動かすこと。感覚的には、ビデオカメラを搭載したラジコン・ヘリコプターみたいなものかな。
もう一つは、携帯電話でＩＣカード化された運転免許証などを認証してAndroid端末から公的なサービスなどへのアクセスを実現すること。
先は長そうだ。
今日は、voitでグーグルのブログを解説しようとしたが、既に取られていた。しかたがなく、関連するキーワードを追加してこのブログを開設した。ググってみて驚いた。Googleとは仲良くしようと思う。。。
このブログは、できるかぎりZaurusで作文することに決めた。 所有している２台のザウルスを活用しようと思う。
以前は、独自ドメインでホームページを開設していたが、光りへの移行時に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コンテンツをリンクさせたいと思う。
そんな話よりロボットのほうが、良いだろうから、本日の〆として、ホンダのアシモについて一言。ちょっと前にショーの準備を見学した時はクレーンでつっていたのが、今では自ら走れるのには感激の思いだ。日本のロボット技術にはもっともっと頑張って欲しいと切望する。いつかは、動かなくなった身体の部品を換えたくなるかもしれないから。
面白い時代になりそうだ。
もう一つは、携帯電話でＩＣカード化された運転免許証などを認証してAndroid端末から公的なサービスなどへのアクセスを実現すること。
先は長そうだ。
今日は、voitでグーグルのブログを解説しようとしたが、既に取られていた。しかたがなく、関連するキーワードを追加してこのブログを開設した。ググってみて驚いた。Googleとは仲良くしようと思う。。。
このブログは、できるかぎりZaurusで作文することに決めた。 所有している２台のザウルスを活用しようと思う。
以前は、独自ドメインでホームページを開設していたが、光りへの移行時に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コンテンツをリンクさせたいと思う。
そんな話よりロボットのほうが、良いだろうから、本日の〆として、ホンダのアシモについて一言。ちょっと前にショーの準備を見学した時はクレーンでつっていたのが、今では自ら走れるのには感激の思いだ。日本のロボット技術にはもっともっと頑張って欲しいと切望する。いつかは、動かなくなった身体の部品を換えたくなるかもしれないから。
面白い時代になりそうだ。
登録:
投稿 (Atom)