変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

IoTとは

IoTは「モノをインターネットで繋ぐ」のだが、
誰でも「モノの情報」を観れればいいのかと云えばそうでもない。
インターネットから貴方のBluetoothヘッドフォンに騒音を紛れ込ませるウイルスが入ってきたらイライラするだろう。
気温や湿度を測定するデバイスに延々とリクエストしつづけるBOT群が出現したらIoTの小さなバッテリーはすぐ切れてしまい肝心なサーバーに情報を送れなくなってしまうかもしれない。
そんなこんなでWifiやBluetoothが使えるデバイスには認証が必要な様に、IoTも『接続先を限定する囲いこみ戦略』が必要であり、一方ではUPnPの様に特に断わりも無くルータ越しに通信するものも必要だ。そのモノの情報のデータフォーマットも多種多様であり、必ずしもWEBでよく使うXMLやJSONとは限らず、訳の分からない暗号化されたテキストであることが多いだろう。
無論、IoT自体は量産化で安価になるメリットはあるものの、
誰でも簡単に盗聴マイクやカメラをどこにでも仕掛けられる様なシロモノでは物騒な世の中になるだけ。
自分が買った(あるいは貰った)IoTデバイスに盗聴マイクが仕掛けられているかどうかなぞ判る訳もなく、トラブルが続くであろうことは想像しやすい。
そう、どこでどう悪用されるか判ったものでは無いからだ。
そう云う訳で、当分の間はIoTには手を付けないつもりだ。



フォルダの背景に色とか画像を貼れないWindowsのエクスプローラーってUIはクズだ

と思う。
例えば、hostsファイルのある C:\Windows\System32\drivers\etc フォルダをエクスプローラーで表示し、幅を狭めていくと順に・・・
C:\Windows\System32\drivers\etc
Windows\System32\drivers\etc
System32\drivers\etc
drivers\etc
etc
と最後はetcのみになるが、これはetcフォルダを観ているんだからコレでいいだろうと思える。
しかし、
C:\Windows\System32\drivers\etc

C:\Windows_old\System32\drivers\etc
を見比べている時はどっちもetcしか表示されず、しかも左側でカレントのフォルダ構成を表示してるけど、上を見てもSystem32 あたりしか見えないので、目印になるフォルダが見える位置に手で調整しないといけない。
そんな場合は、デスクトップの壁紙の様に、フォルダを開いた状態の赤と青に背景色を変えられた方がずっとマシだろうけれど、なぜかできない。
プロパティのフォルダの画像で指定できるのは、特大のフォルダアイコンにした時に「フォルダに挟まってるように見える画像」のことで、フォルダの背景画像ではないのだ。
 
ぐぐってみると、IEとエクスプローラーを分離した後から、こうなったらしい。
 
という訳でクズ決定。
 
悔しかったらできる様にすればいい。(大笑
 
もっとも実装された後、
ボクが、ファイルサーバーにフォルダの背景用の画像を転送してから、
フォルダの背景にその画像を指定しても、
気に入らない誰かが、自分のパソコンの画像に貼り替えてしまった途端に、
LAN上の全てのパソコンのエクスプローラーがガチッっと音を立てた様なくらい硬直する
そんな感じの実装しかできないだろうなぁ~ってことは
容易に想像が付きますけどね。(大笑
 
ま、早い話が フォルダに 背景画像のプロパティも付けられないので
新しいUIとか云って「START」ボタンをやっぱり

何でも無くしてみるしか能がない

のがお笑い草と云う話です。
追加する時も、ツールバー多すぎなので、リボンにしました!リボンにしたらツールバー3本ぐらい太くなっちゃいました!
って感じで、低めの解像度の8インチのWindowsタブレットは大変。あっと云うまにタブレットの方が無くなりましたね。
でも、MSが実はGUIが苦手なことはずいぶんと昔からなのです。
写真や絵に図形や文字を載せてデザインしてシールに印刷するだけの小さなパッケージを納品して暫くたった後のこと、
リッチーテキストエディターの背景って「どうやって透明にするの?」って質問されたことがありました。
「(当時は)透明にするのは無理だったので、IME制御込みでリッチーテキストエディターごとハードコードしましたよ。」と答えたら・・・
ドン引きされました。
確かにシールのオマケのソフトにそんな面倒な事をする必要なんでドコにも無いですよね。(笑
でも、そうしないと文字を組み合わせるのが面倒じゃないですか?(大笑
「印刷の解像度を変えても、写真と文字の位置とか改行がズレないけどどうやったの?」って質問もあったけど、
どうやったか忘れてたから・・・
世の中、知らない方がいいこともありますよ。と答えたと思います。
少なくとも、論理インチを使っても、文字がズレるのは、今のEXCELやWORDも同じですからね。
いまだにプリンターを替えたら、あら不思議、改行の汚いWORDドキュメント、***だらけのEXCELシートに変貌!
本当にお粗末ですよね。(大笑
バカバカしい話ですが、いまでも印刷はPDF出力にして、PDFのビュワーから本当のプリンタに印刷するのが一番ですよね。
いつまでも、続くんでしょうね。(大笑



レールガン

電磁気力を使って弾頭を発射する大砲のこと。
小惑星の軌道変更や、月の様な低重力から資源を打ち出すマスドライバーとして立案されたものを大砲に応用したもの。
化学反応を利用しないので、特に弾頭の発射速度の制約は無く、理論上は地球の第一宇宙速度も越えられる。
発射の際に、弾頭が発射装置のどこかに引っかかると、ドコに向かって飛んでいくか判らないので、弾頭の周囲を樹脂製のカバーで覆い滑りやすくしているため、発射の際にはカバーの残骸や破片が火薬を使った弾頭より高速で射出され、発射時の周囲は大変危険であり、発射時の安全性に対する配慮は火薬を使った大砲が洗練されている。



逆走しやすい高速道路?

高速道路の車の逆走は224件。
内、運転手が認知症だったケースが12・1%(27件)だそうだ。
残りの87.9%(197件)は普通の人で、67・9%(152件)が65歳以上の高齢者が運転手だそうだ。
つまり、高速道路年を取るほど逆走しやすい様に作ってあるというところが一番の問題。
例えば、豪雪で広い分離帯が高い雪の壁になっていると、「本来の右折車線が次の交差点にしか見えないかった」というのは普通に起こる。
しかし、暖かくなって高い雪の壁が消えた後では逆走防止用の「侵入禁止」の標識があるのは滑稽なので付けられることは滅多に無い。
 



AI

最近、廊下、いや老化が進んでいる。
記憶違い、物忘れ、めんどくさがり などなど
FFXIVの中では・・・

  1. テレポする度に、キャラの方向が変わるので、すぐに方角が判らずとりあえず、エーテルライトの周りを一周してしまう。
  2. インスタンスダンジョンをグルグル回るどころか、2度目すら億劫になる。
  3. FATEを速攻で融かされるとイラっとくる。
  4. 時々目がかすんで画面に何が映っているのか判らない。
  5. ゲームパッドで楽をしているハズなのに手のひらが妙に痛い。
  6. 長時間プレイをして眠いのに、眠れない。

など、老化現象が進んでいる。
こうなると高機能なBOTツールのお世話になるしかないような気がするが、
DPSチェックもアナクロな方式(バトル・ログからテキスト・エディタのマクロを通して集計)してるので、
高性能なツールを適切に操作できる自信は全く無い。
それができるなら、とっくに高難易度のバハムートの真成編をクリアしているに違いない。
今のクライアントに付いているマクロ機能あたりが丁度いいのだ。
そんな老化現象に一番良いアプリは
「RESTART3回目ですよ。そろそろギブアップした方がいいですよ?」
と優しく助言してくれるAIに違いない。
昔のAIは対話形式で情報を蓄積するタイプで、些細な誤操作で無残な結果になり、AIを操作するのはAIの気質を良く知っている選任の技師に限られていたから、AIのオーナーの希望通りに育成されているかどうかは知る由も無く、長考したりエラーを吐くこともあり、とても自動車の運転を任せられるものではなかった。
そうボクが好き勝手にAIを調教したら「まるでダメな奴」にしかならないのだ。
しかし、今のAIはフレーム(解答時間の上限)の概念があり、事前にそこそこのまともな運転方法を学習しているなら、ボクが運転するよりはよっぽど上手に運転してくれそうだ。
それに誰でも「最初の事故に遭った時は完全な初心者」であり「最善と思った行動が最悪な場合」もありうるから、
人間より「最初の事故に関しては十分な経験を積んだAI」の方がマシと云える。
だが、「保険の責任(あるいは費用)分担」の問題があり、これを回避しようとして、AIが危険な行動を取る可能性もある。
ある人にとってAIは悪魔の使いらしいが、それはAIをコントロールしているつもりになっているだけではないかという疑問なのだ。
自動車のメーカーのAIと、自動車にかけている保険のAIが同居する自動運転の自動車は果たしてどんな結果になるのか?
たぶんケースバイケースで、良い時もあれば悪い時もあるのだろう。
少なくとも「AIのおかげで事故で自分の保険を使わずに済んだが代わりに自分の命を支払う・・・」様な事態は
回避したいと誰もが思うだろう。
さて、怖い話はこれくらいにして・・・
今のAIで容易に触れられるものは電脳無能アプリに近く、戯言、気の利いたジョーク、分別のある解答不能を出力する。
例えば、iOSの音声認識パーソナルアシスタントアプリのsiri がある。
「電源をオフ」と云えば「そうしたいのはやまやまですが出来ません。ご自分で電源ボタンを押してください。」と答える。
何のことはない電話サポートの録音内容を書き込んだ様なものなのだ。
便利だけど、ある公開放送中に「ドッ!(一同笑」な場面で OFFしたハズのsiri が「どうしました?何が起こったのですか?」と声を張り上げたので慌ててi-Pod Touchの電源をOFFしながら、「siriをOFFしても監視されているのか?」と思った。
しかし、本当に何かヤバイ状況であったらi-Pod Touchの電源を入れててよかったと思ったかもしれない。
次のWindows 10 の Cortana(コルタナ)は「電源をオフ」と云えば、どうするのだろう?
「そうしたいのはやまやまですが出来ません。ご自分で電源ボタンを押してください。」と云うのだろうか?
否、「シャットダウンのBGM」を流しながら電源がOFFになるような気がする。
それともいきなり「電源をオフ」してしまい、「電源をオン」すると色々壊れているのだろうか?
そして「ダメですよ。とりあえずエラーチェックを実行しておきますね。いきなり電源をオフせず、ちゃんとシャットダウンしてくださいね。」とか、タメ口になるのだろうか?
 
 
 
 
 
 
 



.NETをオープンソース化する意味

プログラムを作る側からすると何も意味はない。
と云うのも、.NETをオープンソース化され、読んでみて「これはヒドい」とAPIを綺麗に書き換えたとしよう、そうなるとサーバーの中のアプリが動かなくなるだけ、「車輪の再発明」的なことは、トラブルの元になるだけなのだ。
既にVisual Studio Expressが無償化されているが、これもWPSで何かサンプルを作って、リソースを見ている部分をデータベースに繋ぎ替えようとすると、「大半のソースをガリガリ書き直さないといけない」ので、「楽をするノウハウの詰まった有償のパッケージを買わないといけない」状況に変わりはない。
どちらかと云えば、MSにとっては、サポートがめんどくさく、しかも全く儲からない部分なので、オープンソース化して、コストダウンしたいのだろう。
どっちかと云えばMSにぜひやってほしいことは、「数年ごとにWindowsのバージョンアップをすることをやめる」ことだ。
なぜなら、数年ごとにWindowsのバージョンアップするたびに異なるUIやらAPIになるので、ウンザリする「アプリの再開発」という「車輪の再発明」みたいなことが必要になるからだ。これはぜひなんとかしてほしい。(大笑
だって、なんでこんなアプリになっているの?当時の担当者なんて居ない!誰も知らない!ってことが多すぎなんですよ。(大笑
それに、サポートが5年で切れるWindowsは「アプリの再開発」も含めると・・・

結局、Windowsって高い買い物になってしまう

と云う事態も回避できるのだから(大笑



epelのphpMyAdminがやっと更新された

# yum update –enablerepo=epel phpMyAdmin
画面に バージョン情報: 4.3.6 (最新版) と表示され無事に最新版になったと思ったら、下に変わったメッセージが表示されていた。
You are using an incomplete translation, please help to make it better by contributing.
脳内翻訳:「なんか翻訳やばいかも?気が付いたら教えてね!」
Google翻訳は言った: 「あなたが不完全な翻訳を使用している、貢献しそれを改善するために助けてください。」
確かに、
メニューにRecentとかFavoritesとか書いてあるし、チップヘルプは全部未訳のまま。
Theme: のところにテーマの文字は無く、
SQLのページのRollback when finishedが未訳で、
インポートのページは半分が未訳のまま。
確かに、翻訳の途中(im-complete )って感じだけど、Failではない。
とは云え・・・
今ではRedHatを使うことが無くなったので、
epel リポジトリィのパッケージに参加するのは気が引ける。
聞きかじりで、へぇ~RedHatではファイル名はこうなってるのか!替えとこう!・・・動かなくなりました。( ; ;
とか、やってしまいそうだし・・・

ちゃんと翻訳できる自信も無い。(大笑



スループット至上主義の結末

今時は、CUIもGUIも同じ調子でプログラミングしてしまうが、
前世期後半のコンピューティングの中で、UIが対話型のCUIから、ビデオゲーム型のGUIに変わった時に大きな変遷を遂げた。
その当時の対話型CUIの代表的なものはshellスクリプトで、ダイアグラムで図式化された通りにコードされ、ソースのあちこちで入力待ちする個所にecho とreadが散らばっていた。マルチウインドウっぽいcursesライブラリィを使ったものもあったが、大方はジャーナルリストの下に長いエントリーフィールドが1つあるだけのレイアウトばかり、と云うのもシリアル接続の端末をエスケープシーケンスでカーソル位置などを制御しているのに、朴念仁のカーネルやドライバーがログ(ディスクの空きは残り1ブロック!)を吐き出したり、同僚からのメッセージ「飯!」が飛んでくるだけで、viの画面ですら意味不な文字の羅列に成り果てるので、マルチユーザなUNIXの環境は実は地雷原同然のギスギスな環境でもあったのだ。
また当時の端末は80行25列のキャクター表示にブリンクや下線などの文字属性を少し付く程度の機能なので、小規模集積ICとメモリチップを並べて作られおり非常に高価であり、またその機能を考えると「個人で買う気になれるモノ」ではなかった。当時マイクロコントローラとビデオコントローラーの安価な組合せセットが出始めたので、これで端末を作れば安く作れるかもしれない。そう思った人が、自分用にビットマップ表示の端末を作ったのだ。マイクロコントローラのプログラムは自分で組み込むものなので、ワークステーション側でカーネルのログをバッファし、viの通信とは分けて、マルチウインドウ形式で端末に表示する様にハックしたのだろう。
同僚からのメッセージ「飯!」が飛んでくるだけで、viの画面が壊れるのにウンザリしていた人間は意外と多かったらしく、画面が壊れないと云うだけでもこのビットマップ表示の端末は注目されるに値するものだったが、マルチウインドウを操作するために3ボタンのマウスというデバイスも取り入れられ、従来のread文だけでは、プログラム同士の入力の奪い合いが始まってしまい、うまく切り分けできなかったので、誰かがまとめ役(WindowManager)になってもらい、座標入力と文字入力を切り分け、該当するウインドウの持ち主に配布してもらうことになった。これがX-Window ver1.0である。
当時ダブルフォルトぐらいしか使い道のないlongjmpのみがプログラミングとは非同期で処理分岐する方法であり、異なるプロセスであるWindowManagerから安定して入力メッセージを受信するには、受信ルーチンを1か所にした方が無難であり、GUIではプログラミング・スタイルが大きく変わることになった。
無理をすれば割り込みロジックを使い、疑似マルチスレッド化も可能だが、マルチスレッド対応のライブラリィなんてなかったし、仮にうまくいった様に見えても不定期にprintfの処理中に割り込まれているのかも?と気が付くまで、原因不明のハングアップに悩まされ続けることになっただろう。
C++が生まれるのは20年ぐらい先の未来なので、イベントハンドラはイベント分岐判定の巨大なswitch文としてハードコードされた。それは初期のWindowsも同じ。なぜイベント分岐判定をサブルーチンにしなかったのかと云えば、主メモリが数Mバイトと少ない上に、ちゃんとしたMMUが実装されていなかったので、スタックには数Kバイト程度しか割り振れず、イベント分岐判定を画面のメニュー構成に合わせ綺麗にサブルーチン化し、肝心の処理をサブルーチン・コールする時にはスタックの大半を消費していたりする間抜けが多かったからだ。その辺は同系列のCPUを使うUNIXのワークステーションも同じであった。
一方、menuプログラムがforkとexecを連打しバッチ処理を呼び出すCUIのままのプログラムも、メニューだけGUI化して生き残った。
しかし、やがてメニューとバッチ処理を一体化させるのに十分なメモリ容量が確保できたものの、HDDアクセスのオーバーヘッドが解消されない状態が続くと、一体化されたアプリと比較して、先のバッチ処理を呼び出す方式は何かボタンを押す度にHDDのアクセスランプが長く明滅する非常に応答性の悪いシロモノに成り果てることになるのだが、恐ろしいことにWindows Serverの時代になってもその子孫は生き延びるのであった。
という感じで当初のGUIはハードウェアの性能が貧弱だったこともあり、ボタンを押した後延々と待たされることになり・・・
とりあえず、カーソルを砂時計にして処理中をアピールしたり、処理時間を推定してプログレスバーを表示したりするようになる。
しかし、待機時間が長いという事実に変わりなかったのが、前世期後半のコンピューティングであった。
その反動で、今世紀のコンピューティングは、スループット(応答性の良さ)が第一の目的となった。
第一にインターネットの普及でサーバーの同時接続数が急激に増加し、まずはサーバーのスループット(応答性の良さ)をあげないと、
どんなに素晴らしいサービスを構築しても、否、素晴らしければ素晴らしい程に、容易にサーバーが陥落してしまうという現実に直面してしまうのある。
ところが、C++やSTLなどのオブジェクト志向プログラミングは遍在性分が多く、数多くのバックヤードのライブラリィを暗黙の内に必要としており、プログラムの起動時間が恐ろしいほどに長くなってしまった。
しかし、それではスループットをあげられないので、プログラムソースにimport などでライブラリィを指名することで、利用するライブラリィを厳選する以外に、ロード時間を大幅に短縮する方法がなかったのだ。こうして、一義的な解釈しかできないオブジェクト志向プログラミングが主流になった。
退行してしまったオブジェクト志向と云えば、その通りなのだが、一義的な解釈しかできないので、読み間違うことも少なく、プログラマの能力差によるバクの発生が減ったのは云うまでもない。
また、イベント分岐判定など遍在性分が多いコードは、読み慣れない普通のプログラマが修正を加えると悪い結果しか出ないのはミエミエなので、
ワークフレームと名を変え、一般のプログラマからコードを隠ぺいするのが普通になった。
こうして、今となっては、システム全体がどうなっているのか、実は誰一人知る者はいないので、
セキュリティホールがあるのかどうかは、ワークフレームをちゃんと読める人にしか判らない状況に陥るのでした。



Intel第5世代Core 【Broadwell-U】

既にCore Mプロセッサ(Broadwell-Y)が出ていたハズですが誰が使っていたのでしょうね?
Broadwell-Uが発表されたことで、やっと本格的にCPUは 14nmルールで作られることになるようです。
大雑把に

  • 3Dグラフィック性能は22%アップ
  • 動画変換は50%アップ
  • 生産性は4%アップ
  • バッテリーの稼働時間は1.4時間長くなった

だそうです。
「生産性は4%アップ」って起動時間が短くなったのかな?
TDPは28Wと15Wのものが1月から出荷され、夏にはTDP45WのLGA1150 ソケットのBroadwell-K(アンロック版?)が出る様です。
タブレット用のBay Trailも2015年上半期には14nmの「Cherry Trail」に置き換わり始めるようです。
これに連動し、Intel第5世代Coreのnuc(1月予定)や、Bay Trailでのスティックタイプ(3月予定)を出すようです。
ボクが気になるのはnucの方ですが、第5世代のi3/5なのでお高いnucになる様ですが、Core Mプロセッサよりは安くなるみたいです。しかし、日本は当面円安ですから、発売価格を見てガッカリするのは明らかですね。
また、安くしようとして、手持ちのnucからメモリや無線LANやSSDを使いまわそうにも、接続部の規格が変わっており、全部買い替えになりそうです。
今までのnucは小さいからこそお高いのが当然でしたが、やはりそのままなのでしょうか?
 



トヨタ・MIRAI

プリウスから
ガソリンタンクと内燃エンジンを外し、
代わりに
水素タンクと燃料電池を積んだものらしい。
基本設計はハイブリットカーのまま、エネルギー源はバッテリーで、モーターの回生ブレーキでマメにバッテリーに充電、放電しすぎたら燃料電池で更に充電する感じではなかろうか。
難点は

  • バッテリーの寿命 ※初代プリウス同様だったら交換費用が恐ろしく高額になる。
  • 燃料の補給  ※ほとんどの地域に水素ガス・スタンドなぞ存在しないのが実態。
  • 燃料電池 ※何10万キロ走れるのか?一切情報が無いが、車体価格が700万円台であることから、交換の際の費用はかなり高額と思われる。

なので、経済性を理由に購入するものにはなっていない。
燃料を使う航空機は燃料が減るほど軽くなり燃費が良くなるが、FCVの水素燃料タンクに入る水素は数㎏なので誤差の範囲。
バッテリーの充電時間よりも燃料を補給する時間の方が短いのは良いことだが、水素を補給できるスタンドがなければ意味がないし、EVの充電済みのバッテリーをレンタルする仕組みが出来たら、ほとんど意味がなくなる。
EVは走行距離が短く、長くするとバッテリーが重すぎ、軽快なスポーティーな走りができないという人もいるが、スポーティーなキビキビした走りをするほど、ブレーキングあるいはアクセルを緩めた時は回生ブレーキで電気エネルギーとして回収した方がお得なので、燃費を考えれば益々バッテリーを頼りにするしかないのはハイブリッドカーも同じだ。ただ、旧式のi-phoneのユーザーなら、EVに乗ると気持ちよくアクセルが踏みこめないと云うことならそれは良く理解できる。しかし、それは燃費を考えずに購入した結果でしかない。
そうEVとFCVのどっちが良いのかは、まだ趣味の領域だ。どちらもまだ数多くの欠点を持っているのだ。
今、ドコでもスマホの充電ができるような環境が整っているが、EVも同様になれば走行距離の短さはほとんど問題にならないし、FCVも十分に水素補給スタンドがあれば支障が無いので、後は燃費が1㎞あたり10円以内に収まればどっちでも構わないだろう。どちらかと云えば、ホイールインモーターにするかしないかを後回しにした方が後々問題になるだろう。四輪独立でモーターが付けば制御も複雑となる。前輪側は回生ブレーキがかかりながら、後輪側は加速する様な状況でも、電気エネルギーを回収したいなら、結構面倒な電装系になるからと、バッテリーを2~3系統に分け、それに燃料電池が加わると、とても厄介そうだし、EVも充電インフラの対応がとても大変そうだ。
また、健康第一の世の中だから、
いつも黒煙を吐いて走る中古のディーゼル・カーの後ろについて走っていると燃料電池が傷みやすくて迷惑とか
床下に水素タンクがあるので、車内は火気厳禁、タバコは絶対ダメとか
怪しい情報が出てきそうな予感もするが、
マメに吸気フィルターを掃除しないと、酸性雨や塩害で燃料電池が短命になる気はする。
その点は初代なのだから色々気が付かない不都合が生じるだろう。だから高いのだ。
よって購入対象は勿論・・・

  • 目立ちたい奴。
  • アーリーアダプター。

となる。
燃費は10円/㎞になるように、水素燃料の価格を1000円/㎏前後に設定する予定らしいので、燃料の補給に困らなければ、毎日の費用はそう高くないのかもしれない。
もし、水素燃料を水の電気分解で作るとしたら・・・いったいいくらかかるのだろう?
ある試算では、1立方メートルの水素を作るのに5kWhの電気が要るそうだ。
0℃、1気圧の1モルの気体の体積は22.4ℓ、水素はH2で分子量は2で、1立方メートルは1000ℓだから・・・
1立方メートルの水素の質量は・・・
分子量=2(g/モル)=2(g/モル) × 1000(ℓ)/22.4(ℓ/モル)/1000(㎏/g) =0.089(㎏/立方メートル)で、
1㎏の水素を作るには、5(kWh/立方メートル)/0.089(㎏/立方メートル)≒56(kWh/㎏)となり、
大雑把に1kWhの電気料金が15円すると、1㎏あたり840円の原価なら、1000円/㎏で販売できるのかもしれない。
しかし、従来通りの水蒸気改質法の方がずっとやすくできるらしいので、電気分解で水素を作るのは論外だろう。
ただ、
世の中は色々と巡り巡ってくるものなので、
安価な水素燃料電池が出回る様になり、かつ安全な水素の貯蔵方法が確立してきたら、
日中は、太陽光自家発電で発電し、水を電気分解し、水素を自宅の水素タンクに貯蔵し、
夜間は水素の燃料電池で発電して自家消費に回すのも悪くないのかもしれない。
水もタダではないので、大きな貯水槽に雨水を貯めておかないといけなくなるのかな?
水不足の時期はどうするのかな?
 
ともあれ
700万円もする自動車を買うのはやっぱり趣味の範疇だろう。
ボク的な趣味で云えば、
ずいぶんと前にずいぶんと高いメーカー製のパソコン(MacとPC98)を買ったら、普通の自動車が買えるくらいのお金がかかってしまった。
その後は、自作した方が安かったから自作ばかりになってしまったが、それはハードウェアがドンドン陳腐化していく時期であり、いくら拡張性があるとは云え、数年で必要とする性能や容量が、その拡張性を越えてしまっていた時期でもあったからだ。
今ではCPUにしろメモリにしろ速度や実装密度はほぼ限界が見えてきたので、さっぱりCPUの速度は上がっていない。
ハードウェアの並列化が必要となり、単価はガクっと下がると予想したが・・・
チップの中でCPUが並列化しただけで、単価は下がらなかった。
どのメーカーも、更にもっと限界に近づこうと悪あがきを続け、トンデモナく開発費がかかり、他が脱落していくのを待っているので、いっこうに単価は下がらない傾向にあるようだ。
そんな悪循環はいまも続いている。
今では、何か別の方法でコンピューティングした方が良いのかな?と思えるくらいだ。




top