Sirius -旧ブログ、更新されません-

受信機として使うとき、KURO-RS は受光部がシールドされているのでちょっと離れたり向きが合わなかったりするとうまく受信できません。

そこで分解してシールドを取ることにしました。



裏のねじをはずしてケースを開いた状態です。





基盤の表





基盤の裏





受光部の正面





赤丸部分が受光部のシールドです。









シールドをニッパーで切っちゃいました。



ところが、シールドを完全に取ってしまうと、過敏になってしまいリモコン以外にも反応して使い物になりませんでした。

しょうがないので、シールドは前方のみを開放することにしてテープで止めました。







ちょっと汚くなってしまいました。一応、離れたところからも受信できるようになりました。これでもたまにリモコン信号以外にも反応してしまいますが、実用上問題はないようです。ニッパーで切らずにはじめから前面のシールドを開けばよかったと思いました。

コマンド類の修正や説明ファイルの作成もほぼ終わりました。連続運転はまだ二日目なのでもう少し動かして様子を見ます。

あとは、サポートする気はありませんが、掲示板を準備しようと思っています。自分の環境や使用法では問題ありませんが、異なった環境ではいろいろと問題が出ると思います。気が向いたら修正するかもしれません。公開予定は 3/6 です。

内部データの構造をバイナリツリーに変えて検索速度を上げました。今まで固定配列でやっていたのでデータセクションの値の個数を固定にしていましたが、個別に確保するようにしたのでメモリが確保できる限り制限なしになります。



連続稼動して動作確認していましたが、KURO-RS daemon を再起動したところ、socket を bind するところで既に使われているというエラーになってしまいました。どうも終了処理に問題があるようです。この見直しと、他のコマンド類の引数を変更すること。さらに内部データを変えたので再度連続稼動テストを行います。3 月の初め頃に公開する予定です。

DivX をインストールした後、再生時のロゴを非表示に設定していてもアップデートをしているうちにいつの間にかまたロゴが表示されるようになったりします。あるいはインストールした直後に非表示にしようと思っても、コーデックの設定までたどり着けなかったり、コーデックの設定そのものがなくてどうしようもない場合があります。

単純にレジストリの値を変えるだけなのでコーデックの設定までたどり着けなくても再生時のロゴを非表示に出来ます。

"HKEY_CURRENT_USER¥Software¥DivXNetworks¥DivX4Windows¥Disable Logo" の値を 1 に変更するだけです。



あるいは、"C:¥Program Files¥DivX¥DivX Codec¥config.exe" を使って設定します。

ビデオエンコード専用にしている Core2 QUAD のマシンでエンコード時間が以上に長くなってしまいました。普通なら 4 時間程度で終わるものが 12 時間たっても終わりません。一応最後までエンコードして再生できました。どうもおかしいと思い、エンコード中に CPU 温度を見てみたら 100 度を越えていました。取り付けていたファンが外れたようです。エンコードに時間がかかったのは、 CPU 温度が高くなったためクロック周波数が下がってしまったためだと思います。ファンを取り付けなおすことで CPU 温度は元に戻りました。なぜ CPU ファンが外れたのかは不明です。

玄箱だけでなく、普通の PC で kuro-rs daemo を動かしてみました。x86_64 な Fedora12 を入れたマシンがあったので kuro-rs をつないで見ました。



NetworkManager を動かしていると、問答無用に modem-manager がデバイスを開こうとするので modem-manager を停止する必要があります。modem-manager を停止するには、/usr/share/dbus-1/system-services/org.freedesktop.ModemManager.service の中身を全てコメントアウトして下さい。(行頭に#を入れます)。



はじめに、カーネルモジュールを動かします。

# modprobe -r ftdi_sio

# modprobe ftdi_sio vendor=0x0411 product=0x00b3

次に kuro-rs をつなぎ、daemon を動かします。問題なく動くようです。まあ、PC を連続稼動させるよりは玄箱を連続稼動させたほうが省電力なのは確かです。しかし、連続稼動させている PC があればそれにつないでもいいでしょう。

参考にしたページ

せっかちな人のための git 入門 - git をインストールし、共同で開発できる環境を整えるまで : 僕は発展途上技術者

はじめてのgit - IDEA*IDEA 〜 百式管理人のライフハックブログ

Git ユーザマニュアル (バージョン 1.5.3 以降用)



以前からソース管理のツールを使ってみたいと思っていました。仕事で SCCS を使ったことはあるのですがどうも面倒で個人的には使っていません。最近は git というものが使われているようなので使ってみました。意外と使いやすいかもしれません。

基本は次のようになります。



３台のマシンを考えます。サーバとクライアント２台です。クライアントはクライアントのマスターをクライアントＡ、もう一台をクライアントＢとします。また、サーバとクライアントのやり取りは ssh を使うことにします。



１、サーバ側 リポジトリの作成



# mkdir /var/git/アプリケーション名

# cd /var/git/アプリケーション名

# git --bare init

空のリポジトリが作成されます。なお、ディレクトリ等のアクセス権はユーザに対して書き込みが出来るように設定しておかないとクライアントからアップロードに失敗します。今回は所有者を変更します。

# chown ユーザ名 /var/git/アプリケーション名 /var/git/アプリケーション名/* /var/git/アプリケーション名/*/*



２、クライアントＡ側(master) でプログラムを作成する。

% mkdir アプリケーション名

% cd アプリケーション名

% git init

カレントディレクトリに .git ディレクトリが作成され、初期設定されます。

ファイルの追加

% git add ファイル名

% git commit -m 'コメント'

add で対象ファイルを追加する。ワイルドカードが利用可能です。コミットする際コメントが必要です。コメントを省略すると vi が起動して（たぶん環境変数の EDITOR を見ていると思います）コメントの入力が促されます。



３、クライアントＡからサーバへ転送

% git remote add origin ssh://ユーザ名@ホストURL/var/git/アプリケーション名

origin を指定する。

git では、origin がサーバ上のリソース、master をローカルなリソースのことをいうみたいです。

% git push origin master

master を origin へコピーします。



４、他のクライアントＢにプロジェクトを持ってくる（チェックアウト）

git リポジトリからソースを持ってくることをチェックアウトといいます。

% git clone ssh://ユーザ名@ホストURL/var/git/アプリケーション名

アプリケーションのディレクトリが作成され、その下にファイルが作成されます。



５、他のクライアントＢからサーバへ

% git push origin master

クライアントＢで修正した内容をサーバのリポジトリに反映させます。ここはどのクライアントでも同じです。



６、origin と同期する。

% git pull origin master

サーバ上のソースと合わせます。場合によってはコンフリクトとか起るんじゃないでしょうか。



・ブランチって何だ？

つまりは枝でしょ。分岐しなくてもブランチを作ることでマークを付ける意味があるんじゃないかな。ブランチしたところまで戻るのは簡単そう。間違ったブランチは後で削除できるだろうし。



ブランチの仕方。

% git branch

ブランチの様子を表示する。

% git branch ブランチ名

実際にブランチする。たとえば機能追加時に行うといいのかも。

ただし、まだ枝には移っていないので移動する。

% git checkout ブランチ名

% git branch

で実際に移動したかどうかを確認できます。以降の操作はブランチに対しての操作になります。

ブランチを統合することをマージといいます。

% git merge ブランチ名

運が良ければ成功します。運が悪いとコンフリクトが起きるので対処する必要があります。



修正ログをみる。

% git log

pcscd が自動起動できないのは、udev の前に pcscd サービスを起動しているのでうまく動かないようです。ちょっと困った感じです。

udev で bcs-perl.pl を動かそうとすると pcscd が動いていないので失敗します。udev より先に pcscd を動かそうとしても動きません。udev で bcs-perl.pl を動かすのはあきらめました。

udev が S26udev_post なので、pcscd は S30pcscd にリンクを張りなおしました。再起動して無事に pcscd サービスが動いているようになりました。

bcs-perl.pl は、rc.local のなかで起動します。

これで外部から再起動しても BonCasServer が自動で動くので大丈夫です。

一番初めに買った Android タブレットの M001 を壊しました。



1m ほどの高さから落としたらタッチパネルが割れてしまいました。以前は1.5m 位から落として大丈夫だったのですが落ちた角度が悪かったのでしょう。

もう少しで1年くらいになります。液晶保護シートを張っていたので飛び散ることはありませんでしたが、タッチパネルは死んでしまいました。操作ができません。まあ、1 万位で買ったのでそれほどのショックではありません。他のタブレットがあるし、まあ、いろいろ勉強させてもらったし。後は部品取り用として箱にしまっておきます。

赤外データの送受信を socket を使って外部からの要求に応えるようにする部分の修正が終わりました。他のマシンからも送受信が出来るようになりました。

また、Buffalo の Remote Station(PC-OP-RS1) を入手したのでこちらでも試してみましたが、当然、使えました。

残りの作業は内部データの持ち方を変えようかと思っています。が、ほぼ目的のものが出来上がったのでモチベーションが下がってきています。このまま公開してしまうかもしれません。またしばらく連続稼動させてリソースを食いつぶさないかを確認しつつ修正するかどうか考えます。

今まで BD ドライブに付属してきた PowerDVD 8 で BD の再生をしていましたが、最新にアップデートしても、LEON の再生がうまく行きません。途中で PowerDVD がハングアップしてしまいます。メディアに傷は無いのでメディアの所為ではないと思っていました。ほかの BD ディスクは再生できるので、そのまま使っていましたが、そろそろ PowerDVD をアップグレードしようと思い、PowerDVD 10 Ultla を購入しました。

早速、 LEON を再生したところ、最後まで無事に再生できました。やはりバージョンが古くて対応できなかったようです。

今回購入した PowerDVD は 3D 対応なので、モニタを対応したものに変えれば 3D 環境が出来上がります。まあ、今すぐは無理ですが。

デバイス監視はデバイスファイルがあるかどうかで判断します。KURO-RS を接続するとキャラクタデバイスの /dev/ttyUSB0 が作成され、取り外すとデバイスファイルは削除されるので、監視スレッドを作成し、そのスレッドで stat システムコールを使い 1 秒ごとに監視するようにします。状態が変わったら KURO-RS に割り込むようにします。これで通常のデーモンとしてスタートアップ時に起動できるようになりました。デバイスの取り外し、取り付けをして動作確認しました。デバイスをはずした状態で起動しても大丈夫です。

次はソケットの実装ですが、データのやり取りをどうするかを考えています。

4日ほど デーモンを動かし続けましたが特に問題も無く、メモリの使用量が増えることもありませんでした。大きな問題は無いようです。このあたりで公開してもよいのですが、USB デバイスなのでデバイスが取りはずされたりした場合の対応を盛り込みたくなりました。



１、デバイスが接続されない状態で起動されたときは、接続されるまで待つ。

２、デバイスが取り外されたときは、動作を停止しデバイスが接続されるのを待つ。



上記の動作をさせるには、デバイスの監視の必要があり、スレッドプログラミングしなければなりません。調べてみると pthread は POSIX 定義なので、pthread を使っても GPL にはならないようです。



どうせスレッドにするなら、外部からの送受信要求もシグナルではなく、ソケットを使ったサービスとして実装したくなりました。ソケットを実装できれば他のホストからの要求も受け付けられるので利用範囲が広がります。したがって公開はもう少し先になります。

yum でアップデートかけてももうアップデート対象となるパッケージはなくなってしまいました。この状態で外部につなぐのはちょっと心配です。

外部とつないでいるのは ssh だけなので、open-ssh の最新版を手動でコンパイルしてインストールすることにします。それ以外は外部と遮断するように iptables を設定しています。本当はメールサーバにもしたかったんですが・・・。

再配布を制限したいのはなぜかというコメントをいただいたきました。純粋な疑問だと思います。

そういった意見が欲しくて実は記事にしました。公開時にいきなり再配布を禁止してしまうとどのような反応があるのか分からないので試してみました。



理由は単純で、自分が作ったソフトウェアが自分の管理下になくなってしまうのが嫌だということです。ネット上で一度公開したものは、なかなかコントロールが難しいと思います。例えば何らかの事情があって公開を停止しようと思っても再配布されていては意味がなくなってしまいます。



自分自身も、オープンソースソフトウェアや、フリーウェア等さまざまな無料ソフトにお世話になっています。中には GPL なソフトウェアもあります。確かに、GPL にすることによってすばらしいソフトウェアが開発されることもあるでしょう。



しかし、個人的な意見として GPL については疑問を持っています。GPL は開発者（配布者）を制限するものであり、場合によっては私のように公開をためらう開発者も出るでしょう。そんな制限がつくなら公開しないよってことです。仕事でということであればいろいろなメリット／デメリットを考えて決めるでしょう。個人の趣味でということであればデメリットが強いように感じます。公開するメリットと、デメリット。個人の趣味で作ったものであれば公開する／しないはその個人の自由です。実際のところ、同じ理由で今まで作ったソフトウェアの中で GPL であるがために公開していないソフトウェアがあります。自分としては便利に使っています。同じようなことがしたい人もいるだろうなと思いますが、公開していません。（そのうちのいくつかは Windos プログラムなので GPL 部分を排除してバイナリのみ公開したいと考えています。）



今回は実験として GPL を回避するために工夫して公開してみる(ゼロからソースを作成しソースのみを公開する)ことにしました。(GPL であれば公開はしないでしょう)



実際問題として再配布を禁止したとしても、それを検証するすべは私にはありません。ソースが流用されたことを確認する手段も無いでしょう。しかし、場合によっては見つけてしまうかもしれません、そういったリスクを負ってまでやることではないでしょう。(その程度のソフトウェア／ソースです)



私もソフトウェアを作るものとして、利用にあわせてソースを改変したいと思います。だから改変を禁止することはしませんし、その改変部分をパッチとして公開することを制限しようとは思いません。



GPL はすばらしいとも思いつつ、同時に足かせになっているとも感じるため、いろいろな意見があるでしょうが、今回はこのようにしようと決めました。