ぱぱネット（仮）

_ [Linux] udevによる自動実行(うまくいってません)

recfriior4のreadme.txtから HDUSでas11loaderを自動実行するべくudevのルールを設定 をたどって、/etc/udev/rules.d/026_hduc.rulesというファイルを作った。 これがudev経由で実行されれば、不意のUSBハブ断などでHDUCを見失っても、 再度発見したときに自動でas11loaderが実行されてクラックファームウェアがアップロードされるはず.... なのだが...。

# udev rules file for MonsterTV HDUC
SUBSYSTEM=="usb", ACTION=="add" \
ATTRS{idVendor}=="1738", ATTRS{idProduct}=="5211", \
RUN+="/usr/local/bin/as11loader"

SUBSYSTEM=="usb", ACTION=="add" \
ATTRS{idVendor}=="3275", ATTRS{idProduct}=="7080", \
MODE="0664", GROUP="video"

しかし/etc/init.d/udev reloadしてもudevcontrol reload_rulesしても全く読み込まれている気配がない。 いろいろ試してみたが埓があかなかったので、ふと

 # udevtrigger

を 実行したらas11loaderが実行された。 ということはスクリプトはあっていると。 しかしなんで自動認識できないのだ...全く意味がないぞ。なんとなくだが....LOG-J200に対応するべく カーネルを自分でコンパイルしたものに差し替えている関係で、udevそのものがまともに動いてない予感!!!!

_ デカイナマジデ

2時間ほどとってみたがこれは...

-rw-r--r-- 1 root root 5422171356 2009-05-29 16:03 09052915_Ch18.ts
-rw-r--r-- 1 root root 7128234884 2009-05-29 17:03 09052916_Ch18.ts
-rw-r--r-- 1 root root  228229120 2009-05-29 17:05 09052917_Ch18.ts

なんにも考えないで実装すると当然こうなる、 1時間7GB。

これを素で扱えるソフトウェアは、x86-32bit環境だとあんまりない。glib-2.2以降であれば-D_FILE_OFFSET_BITS=64を定義して、 かつ注意深くコーディングすれば、4GB以上のファイルに対応することはできる。 しかし既存の....ほとんどのソフトウェアはそんなこたしてない。 どうも世間の趨勢としては Windowsみたいにドライバで苦労するわけじゃないんだからとっととx86-64bitにこいや らしいのだが.......ぱぱサーバの場合サーバ再インストールになってしまふ。困ったもんだ。

次点としては保存ファイル形式の変更...つまり分割なのだが、分割ルールが激烈に変わってしまうと今までのアプリが 使えなくなってしまう。本当はperlrtmpの作者様みたいに別ライブラリに追い出しておけばよかったのだが、 無計画な俺様としては当然そんなことはしてない(汗;)

どうしたものか.....

_ [ワンセグ野郎] フルセグ野郎が流行らない訳

このまま続けるとたった1チャンネル24時間で168GB。21日録画したら3.6TBだ。やる前からわかってたことではあるが。

フルセグ野郎が流行らない訳だ。そういう意味では ワンセグ野郎は本当に目のつけどころがシャープ だったと思う。 コンセプトの勝利というか。最初から「いやいやワンセグなんて汚いしフルセグが当然でしょー」とか正攻法に思うと、 その激烈なデータ量を前に後込みする。実はコンセプトの段階で 既に罠に ハマっているのだ。 一度そう思ってしまうと、日経某雑誌の「動かないコンピュータ」を地でいく展開となる。

まずは 四の五の言わずに早期に具現化すること、具現化してポテンシャルを見極めること が大切だと感じるな。