これからの家電は3時間バッテリ装備?

東京電力の計画停電はまだまだ続くようです。
家庭では停電のために冷蔵庫の心配の他さまざまな苦労に悩まされているようです。企業では事業に大きな影響が出ていることがマスコミでも報道されています。

この計画停電でパソコンもいろいろ問題が発生しているようです。普及率の高いノートパソコンにはバッテリがあるので基本的には問題がないはずです。しかし私の家のあるパソコンのほとんどはバッテリが機能していないため停電となればただちに(今年の流行語大賞候補?)使い物にならなくなってしまいます。このため停電地域の人の中には新品のバッテリを買い求めた人も多いのではないのでしょうか?

運良く直ちに機能停止しなかったノートパソコンをネットにつなごうとすると通信機器がやはり停電のために通信できない状況となっているようです。パソコンは汎用的な使い方ができるものですが今時にはネット無しでは価値が半減または全滅してしまいます。

どうもパソコン本体だけでなく周辺機器も含めてバッテリ駆動が必要のようです。しかし周辺機器にバッテリ駆動をうたうものはほとんどないようです。小さな家庭用発動発電機でも用意しなければならないようです。

今後も計画停電がずっと続くようです。きっと家庭用の発動発電機もきっと売上を伸ばしていると思います。しかし排気ガスや騒音などから発動発電機を使えない家庭も数多く存在すると思います。やはりこのような問題のないバッテリで駆動できる周辺装置が欲しいところです。

私は計画停電が続けば企業も停電に対応した機器の需要を見越して製品化されることを期待しているところです。私の住んでいる地域では計画停電はありませんが、今後私が住んでいる地域でも何らかの発電所での事故によって計画停電が行われる可能性も当然あります。計画停電については決して他人事のように考えていません。

今回の東京電力の計画停電を観察してみると3時間ずつの停電をグループごとに行っているようです。このことから停電に備えるバッテリの持続時間は3時間が一つの目安になるのでしょうか。

このように考えるとパソコン環境だけでなく冷蔵庫などの家電製品も3時間を目安に停電に備えるバッテリがあれば思ってしまいます。

このような計画停電が永遠に続くとは思いませんが、原子力発電所のように一箇所で大きな発電を行うことが今後も行われるのであれば事故により計画停電の危険性は未来永劫に続くものと思われます。

7月の地デジ完全移行は

3月11日の東北大震災からテレビ番組は数日間に渡って特別番組を放送していました。大震災のことも大変気になるところですがだんだんと通常番組へと戻って来ています。しかし戻って来ないものがあります。それは地デジ化の案内です。

私の家ではまだアナログテレビを使用しています。嫌がらせのように画面の上下が黒い帯となり、そして年末年始ごろからは常時地デジ移行の案内が表示されるようになっていました。またテレビ番組の冒頭には画面の片隅に地デジ化のマスコットが表示されて地デジ化の案内をこれでもかとしていました。

このまま地デジ化の案内が過激化してゆくのだろうと思っていましたが地デジ化の案内がぱったりと無くなってしまったのです。一体どうしたのでしょうか?

もしや今年7月の完全移行を断念したのでは?と思って総務省や地デジ化に関係するホームページを確認しましたが予定変更の案内を見つけることができませんでした。

関東地域では東京タワーから東京スカイツリーへ電波塔を切替えるのも来年のことということでアンテナの再調整や共同受信アンテナの受信エリアの変更もあることからもともと今年7月の完全実施が本当のことなのか私自身はかなり疑っていました。

なんとなく今回の大震災のこともあり地デジ完全移行は延期されてしまうのでしょうか?

いまさらながら canna をインストール

先日ハードディスクを交換したウェブサーバー(システムは FreeBSD )には大昔に canna をインストールしてあることを思い出しました。そこで canna-server が生きているのか確認してみました。今でもひっそりと稼働していました。

$ ps ax | grep canna
809 ?? Ss 0:00.51 /usr/local/sbin/cannaserver -u bin -inet

長い間放置したままでしたが、この cannaserver を活用してデスクトップパソコンとして活用している Debian Lenny や Squeeze の canna を使ってみようと思ったわけです。この共通の cannaserver にどんどん学習させておけばパソコンが異なっていてもいつも同じ学習状況で使えるので便利だと思ったためです。

早速 Debian Lenny や Squeeze へ cannna をインストールしてみました。uim-anthy がもともとインストールされていることもあって uim-canna をインストールしてみました。

# aptitude install uim-canna

インストールには依存関係から uim-canna の他 canna 本体のインストールが自動的に行われました。

インストールが終了しても canna の設定が反映されていない状況でした。そこで一度ログアウトとログインを行ってみました。するとちゃんと uim の設定項目に canna の設定項目が表示されるようになりました。

ここで cannaserver を設定する項目を発見して設定してみることとしました。localhost から webserver へ切替えるために webserver と記述してみました。しかしどうも webserver の cannaserver へ接続していないようでした。どうも設定方法が間違っているようでしたが具体的な設定事例をインターネット上で発見することができなくて困ってしまいました。

しばらく探しても見当たらなかったので外部の cannaserver へ接続することは宿題として後日解決するように努力することとしました。

最初に予定していた cannaserver の接続ができなかったこともあり uim-canna の動作状況を確かめてみることとしました。

kinput2 を使っていたときと違っていて変換の仕方が違っていました。全角スペースなどの変態的な変換(頭に@を付加する方法)が無くなっていて単純に必要とするキーを押しただけで入力できるようになっていました。意外と便利になっていることに驚きでした。

ただ kinput2 の時のような変換ができないことで困ったことは辞書登録などでした。これもインターネット上の情報を探し回ってようやく発見できました。uim のツールバーで日本語辞書ツールのボタンを追加させた後、この「日本語辞書ツール」ボタンを押して「辞書の編集」画面を出して辞書を編集するようになっていました。辞書は anthy 用と canna 用が独立して存在しているので注意が必要でした。anthy で登録していた文字を次々と cannna の辞書へ登録しました。anthy と canna の辞書を一括して変換してくれるツールが無いようなのでポツリポツリと辞書登録しなければならなかったのが少々辛かったです。

覚えられないものもスクリプトへ

先日紹介した FreeBSD のハードディスクのコピースクリプト dump & restore がなかなか人気があるようでアクセスが上昇していて少し上機嫌なこのごろです。アクセスどうもありがとうございます。

面倒な作業を便利にするスクリプトですが、今回は少し指向の変わったスクリプトについて紹介します。

今まではコマンドを入力する手間を省いたり、間違え防止のためにスクリプトを作成するというアプローチでした。初老を迎えようとして記憶力が怪しくなっている年頃の私にはとても便利です
今回はこんな記憶力だけではとても覚えられないネットワークの mac アドレスを取り扱ったものです。

さてどんなスクリプトかと言えば停止しているサーバーやパソコンに向かってマジックパケットを送りつけて起動させるものです。このマジックパケットを送り出すソフトウェアは Debian でも標準パッケージの中に用意されているほどポピュラーものですが、このコマンドと一緒に打ち込まなければならない mac アドレスも一緒に記述したスクリプトです。
省エネや環境問題もあり通常稼働させている必要のないサーバー類は wake up on LAN 機能を使って起動させては使用しています。もちろん使用終了とともにシャットダウン(停止)させて省エネを実現しています。

まずこのサーバーやパソコンの wakeup 機能を動作させるマジックパケットを送り出すソフトウェアを事前にインストールしておきます。

Debian Linux の場合 wakeonlan のパッケージをインストールしておきます。

スクリプト紹介
ファイル名:wakeup.server.sh

#!/bin/sh
/usr/bin/wakeonlan 00:10:ab:cd:ef:12

コマンドに後ろの部分に起動させたいサーバーの mac アドレスを入力します。
ファイル名はパソコンやサーバーの名前を入れた方が解りやすくなるとおもいます。
Debian Linux の場合 通常のユーザーからそのままこのスクリプトを実行できます。自分自身のユーザーディレクトリに ~/bin のディレクトリを作成して その中にこのスクリプトを保存しておくとスクリプト名だけでスクリプトを実行させることができます。

スクリプト名の例
wakeup.pc1.sh
wakeup.file-pc.sh
wakeup.http-pc.sh

しかし私のように初老だけでなく若者でもインターフェースカードの mac アドレスはそう簡単に覚えていられないものもあります。私のようにいつも休止中のサーバーを複数抱えている人にとってはとても便利なものだと思います。

Puppy Linux でも日本規格の無線LANへ対応

以前から放置していた Puppy Linux 4.3.1 の無線LANで 1ch から 11ch までしか通信できないという問題をようやく解決出来ました。何だかすっきりした感じです。


さて方法は一つ前の投稿で紹介した Debian Squeeze の無線LANの対策とほぼ同様のものです。確認のために仮想端末上で dmesg の中から cfg80211 の文字列を抽出してみると確かに US 規格となっていました。

# dmesg | grep cfg80211

ただ Puppy Linux と Debian Squeeze では /etc 以下のファイルの構成が異なっていますのでそれに対応する方法で行いました。

さて具体的には次の通りです。

編集するファイルは /etc/modprobe.conf です。最終行に次の一行を追加します。これは Debian Squeeze と同じものです。

options cfg80211 ieee80211_regdom=JP

編集が終了したところでシステムを再起動させます。

再起動したところで仮想端末から cfg80211 の設定内容を確認してみます。これで JP の規格に切り替わっていたら一応成功です。

# dmesg | grep cfg80211

念のために無線LANの設定を行ってみて 12ch か 13ch で通信できれば日本規格へ変更終了となります。この画像は実際に 13ch の無線LANアクセスポイントへ接続を試みようとしている時のものです。
以前の US 規格の時には 12ch や 13ch のアクセスポイントが表示すらされない状況でした。ちゃんと表示されて選択することもできました。


以前から気になっていた部分だけに問題解決が出来てうれしかったです。写真では Puppy Linux 4.3.1 std がインストールされている IBM ThinkPad 235 で確認しましたが、この他 ThinkPad X22 の Puppy Linux 4.3.1 smp でも同様に確認することができました。

Debian Squeeze の無線LANを日本規格へ対応

アップグレードした ThinkPad A30 の Debian Squeeze の無線LAN (Wireless LAN) の日本規格へ対応させることができました。


現在はアメリカやカナダなどの無線LAN規格の 1ch から 11ch までしか対応していませんでした。これを日本の無線LAN規格の 1ch から 14ch までに対応させるものです。これで困っている読者さんは参考にしてみてください。

無線LANの環境が入っているパソコンで Debian Squeeze を立ち上げます。仮想端末で次のコマンドを入力して dmesg から cfg80211 が記述されている部分を抽出してみます。

# dmesg | grep cfg80211
[ 8.350515] cfg80211: Using static regulatory domain info
[ 8.350523] cfg80211: Regulatory domain: US
[ 8.351213] cfg80211: Calling CRDA for country: US

ご覧のようにアメリカの無線LAN規格となっていることが判明しました。

この cfg80211 の国の識別を日本へ変更します。方法はモジュール・オプションで行います。

/etc/modprobe.d/ の中に options のファイルが存在するか確認します。存在しなければ新しく作ります。

# cd /etc/modprobe.d/
# ls options
options のファイルが存在しなければ touch コマンドでファイルを作ります。
# touch options

この options の中にモジュールオプションを記述します。

options cfg80211 ieee80211_regdom=JP

options のファイルの編集が終了したところでパソコンを再起動させます。

パソコンが再起動したところで最初に確認した cfg80211 の設定を仮想端末から確認してみます。

# dmesg | grep cfg80211
[ 9.318618] cfg80211: Using static regulatory domain info
[ 9.318626] cfg80211: Regulatory domain: JP
[ 9.319253] cfg80211: Calling CRDA for country: JP
[ 9.319365] cfg80211: Calling CRDA for country: JP

これを見るとちゃんと日本の無線LAN規格に対応していることがわかります。

この後 network manager から無線LANで接続を試みます。私の家では 13ch で設定してありましたが ちゃんと認識して接続することもできました。

Puppy Linux でも同様の現象が発生していましたが同様の方法で対応可能かもしれません。今度確認してみたいと思っています。

これで Debian Squeeze の大きな問題点の一つが解決しました!以前から Puppy Linux でも困っていたモヤモヤだったので晴れ晴れとした感じになりました。

二台目となる Debian Squeeze へアップグレード

ようやく重い腰をあげて二台目となる Debian Lenny から Squeeze へのアップグレードを行いました。

一台目と基本的に同じ手順で行いました。ここら辺の投稿参照。

前回はデスクトップパソコンでしたが、今回は無線LANなどの様子も観察したかったのでノートパソコンをアップグレードしてみました。具体的には IBM ThinkPad A30 をアップグレードしました。

作業時間は以前作業をしていた様子をブログに掲載していたこともあって順調に進んで2時間半ほどでした。アップグレード中の通信は安定性優先のために有線LANを使用した。

今回のアップグレードで分かったことは Squeeze の完成度が恐ろしく低く、Lenny から Squeeze へ引き上げるには余程の理由がなければ まだアップグレードは避けた方がよいと感じました。
以前の Etch から Lenny の時のように綺麗にすんなりとは行かず、まだまだ数多くの問題点が残されていました。もちろん私が知らないその他の問題も数多く内在していると思います。

[私が気づいた問題点]

1. 今回新しく判明した問題点は無線LANのチャンネル問題でした。以前 Puppy Linux でも体験した12チャンネル以上のチャンネルで通信できない問題が発生していました。アメリカやカナダなどの11チャンネルまでしかない地域の設定になっているようです。私の家のように常時二台の無線LANアクセスポイントが稼働している状況では一つのアクセスポイントを12か13チャンネルあたりに設定せざるをえない状況ではなかなかの難問です。今後早く対策がなされることを期待しています。

2. そしてデスクトップ画面のパネル部分へ追加するアプレットの「CPU周波数計測モニター」が root 権限で動作しないようで、周波数や動作モードの変更を行うときに「CPU周波数を変更する際に必要となる特権です」と表示されて いちいち root のパスワードを入力しなければならない状況となっていました。


Lenny 時代には以下のコマンドで「root 権限で制御する」を選ぶことができましたが現在は設定の画面すらも出ないで単純に無反応のままコマンドが終了してしまいます。ノートパソコンでバッテリーと外部電源アダプターの両方をよく使っている人はこのアプレットで切り替えをしている人も多いと思います。

# dpkg-reconfigure gnome-applets

3. それから私のようにパソコン画面のスナップショットを撮影する人には影響があると思いますが、スナップショットがデスクトップ全体しか撮影することができない状況となっています。必要としない部分までも撮影して gimp で切り抜き加工をしなければならなくなっています。

[改良されていた部分]

しかし悪いことばかりではありません。改良された部分もありました。それは GRUB2 のインストーラーでした。

一台目のアップグレードでは GRUB2 の選択画面には Debian Squeeze のカーネルしか表示されていませんでしたが、今回行ったところハードディスクの内容を検査して Windows XP などそれらしいものを探し出して一覧として表示してありました。とっても賑やかな感じです!


ただなぜか古い GRUB の menu.lst から抽出したものではないようで記述していた BackTrack4 は ubuntu 8.10 と認識されていました。そのため古い GRUB の選択画面でも BackTrack の文字などが消えてなくなっていました。どうも GRUB2 のインストーラーの影響のようです。


その他の改良点としてメーラーの icedove の諸設定がアップグレードが完了した時点で済んでいたことでした。一台目のときにはすべて手動で設定作業を行っていましたので結構楽になりました。

二回目となる Lenny から Squeeze へのアップグレードを体験した感じではまだまだ私の家では本格的に Squeeze へアップグレードすることが出来ないというのが本音です。実用的に使用しているマシンはこのまま Lenny の状態を維持したいと思っています。ぜひとも Lenny のメンテナンスの終了までに何とか Lenny 程度の完成度に引き上げて欲しいところでした。