土偶StaticRoute

ネット上の情報によるとMAC OSX 10.4では「/etc/rc.shutdown」がシャットダウン時に実行されるらしいけど、10.5ではそんなファイルはないし、新規作成しても実行されない。
ダメ元で「/etc/rc.shutdown」から呼ばれるらしい「/etc/rc.shutdown.local」に書いてみるとなぜかちゃんと実行された。

ということで、MACのOSX 10.5でシャットダウンスクリプトは「/etc/rc.shutdown.local」となるようだ。

OSX 10.4では「/etc/rc.shutdown」から呼ばれるこのスクリプトが、10.5ではどこから呼ばれているのか激しく謎である。
色々探してみたけど結局見つからず。恐らく前バージョンまでの互換性を保つために「/etc/rc.shutdown.local」の扱いを残しているだけと推測されるので、次期バージョンではこのコマンドは実行されないかもしれない。
そうなれば、ここに書いた情報も何の役にも立たなくなるのであった…

バージョンを上げるのは良いけど、マイナーバージョンアップでこう言ったレガシーな仕様がコロコロ変わるのは、直ぐに知恵や知識が陳腐化するので微妙やなぁとおもったけど、MAC OSXをUNIX風OSとしてレガシーに使うことの方が微妙なのだと言うことにちょっとだけ気づいた。

結局この時点で一週間ほど悩みに悩んで試行錯誤を重ね、「このハードではダメなんや」と殆ど諦めかけたころ、既に別のPCにインストールしていた古い「サーバー版」のubuntuで設定してみるとちゃんと動くことに気づいた。
「悪魔の証明」ではないが、動かない理由を探すより、こいつが動いている理由を探すのははるかに楽である。

デスクトップ版とサーバー版の違いなんか、入ってるソフト以外にカーネルにしかないので、カーネルモジュールやカーネル自体の問題であろうか？
ということで、デスクトップ版のカーネルとカーネルモジュールをaptでもってサーバーのものと入れ替えてみるも動作せず。うーん。

しかし、デスクトップ版が最新版の「Ubuntu 8.10」であるのに引き換え、サーバー版が長期サーポート版の「Ubuntu 8.04 LTS」ということなので、デスクトップ版とサーバー版のカーネルの違いではなく、単純にカーネルのバージョンの違いかもしれない、ということで、デスクトップ版の「Ubuntu 8.04 LTS」を入れてみると何事も無かったように、何の問題も無く動作した…
この二つのカーネルのバージョンの違いは2.6.27と2.6.24である。この微妙なバージョンの差でこれほどの違いがあるのだろうか?
恐らくカーネル自体というよりは、カーネルモジュールであるhostapのバージョンの違いであろう。

で、繋がらない時点では無茶苦茶難しく感じた、iwconfigでWEPなアクセスポイントの設定も、hostapdでのwpa2なアクセスポイントの設定も余裕であった。linuxってスゲーなー

ということで、Linuxというか少なくともカーネルくらいは最新版よりは安定版であるstableの方が無難だとつくづく思った。
人生もカーネルもOSもStabｌeが一番である。
と無理やりまとめてみた。

今まではその「再生システム」の部分もTiMidity++なるソフトウェアで動作させていたけど、これをハードに任せる事でシステムのリソースの消費を抑えると言った考え方である。
ということで、SoundBlaster系のカードでサウンドフォントを使用するためのドライバパッケージ「awesfx」をaptでインストール、インストール後に「/usr/bin/asfxload /usr/local/share/sounds/sf2/8MBGMSFX.SF2」等とasfxloadコマンドにサウンドフォントを指定して起動させたのち、MIDI再生時にしかるべきMIDIポートの出力先を指定してやると、見事に音飛びなしで再生される。やったー。
この「/usr/bin/asfxload /usr/local/share/sounds/sf2/8MBGMSFX.SF2」なるコマンドは起動時に自動で設定されるように/etc/rc.localにでも書いておく。

私のサウンドファイルに対応したサウンドカードは音色を内蔵したMIDI音源としてのハードウェアシンセではないけど、逆にそのサウンドフォントをとっかえひっかえする事で色々な音色を楽しむ事が出来るわけである。
先ほど指定した「8MBGMSFX.SF2」はSoundBlasterのCDに入っている8MBのサウンドフォントであるけど、まぁ音としては標準的である。世の中には色々なサウンドフォントが出回っており、色々な音色が入っている物や珍しい楽器の音色、さらにはドラム専用のものやピアノ専用のもの、サイズも数百KBから数百MBのものまでさまざまである。
色々聞き比べて見た結果、私が良く聴くのはピアノであることもあり、YAMAHA Clavinova CVP-205 からサンプリングしたらしい、120MBのピアノ専用サウンドフォントが結構気に入った。

しかし、MIDIファイルの再生だけにこのサウンドフォントを利用したMIDIのシステムを使うのではなく、電子ピアノの鍵盤から入力されたMIDIデーターを、サウンドフォントを指定したMID出力で鳴らせば、私の電子ピアノがありとあらゆるサウンドフォントで再生されるわけである。
鍵盤での入力と発音のズレが全く無い。これはいい感じだ。ここに来て始めてリアルタイムカーネルの威力が発揮されたような気がする。

家のはCASIOの低価格帯の電子ピアノやけど、今一番気に入っている先ほどのサウンドフォントで高級クラスのYAMAHA Clavinova CVP-205の音を鳴らすのはもちろん、ベーゼンドルファーのImperial からサンプリングしたらしい「Realistic Piano」なる19.90ユーロサウンドフォントを使えば、二千万円オバーのピアノの音まで鳴るわけで、何とも凄い話である。
なんか久しぶりにパソコンてスゲーなーって思った。
しかし、ベーゼンドルファーインペリアルの音がするサウンドフォント、19,90ユーロで買おうかな…
と書くと妙に貧乏臭いなぁ…

ソフトウェア音源として使っていた「TiMidity++」もWindows版があるので、興味を持たれてSoundBlaster系のカードを使っていない方もサウンドフォントをとっかえひっかえ試して遊んでみるのはいかがだろうか？

リアルタイムカーネル→音声処理が凄い→ソフトウェア音源でのMIDI再生がイイ！！→ウマー
って安直に想像してたけど、良く考えれば、リアルタイムカーネルってのはレイテンシが低くなってハードやリソースからの応答速度が速くなるのを目指してるだけやねんから、処理落ちするほどの高負荷が軽減される訳では無いやん…

なんか無理やりソフトウェアシンセで鳴らそうとしてるけど、良く考えれば、昔は結構高かったサウンドカードなので、カードに音源を搭載しているはずである。
こいつを何とか使えるようにすればサウンドカードでのMIDIは上手く鳴るんじゃないだろうか。

って、本来は電子ピアノを外部MIDIとして使うだけの予定やったのに、どんどん話が違う方向に行っているような…

インストール後にソフトウェアやらプラグインやらを追加する。aptパッケージシステムなのでらくちん。
Linuxのパッケージシステムは良くできてるなぁ。そらSolarisなんかつかわへんわなと納得だ。

とりあえず良くわからんので、ネットの情報通り、aptのレポジトリを追加して、「Ubuntu Studio」なるマルチメディア系のパッケージと「KMid」なるパッケージを導入すれば、環境は整い、デフォルトでは再生されなかったMIDIとmp3はプラグインやドライバのインストール後には再生できるようになっていた。
しかしながら、電子ピアノと接続するためのMIDIケーブルが見つからないので、ソフトウェア音源だけのMIDI環境である。

Duron 1.3GHZ 768MBなubuntuマシンでシーケンサーソフトであるRosegardenでmidiファイルをALSAのソフトウェア音源で再生すると再生が結構もたつく。
私的には結構高いスペックのつもりなのだが、ソフトウェア音源でこんなに負荷がかかるとはびっくりである。
ん～何か間違ってるのか？

IOエラーが出ているけど、犬ファイルシステムは密かにあんまり信用していないのでディスクは壊れていないと見た。
インストールしてもエラー出るようならそれから交換しても遅くない。
よっぽどSolaris入れたろうかと思ったけど、sambaファイルシステムをネットワークマウント出来るのはlinuxだけやし、linuxも飼っておいて損はない。solarisでnfsマウントという手もあるけど、普通すぎてちょっとつまらん。
ここははやる気持ちと怒りを押さえてLinuxをインスコすることに。

クラッシュの時点まではSuse9.3やったので、この際10.0を入れてみる事に。
以前からSuseを選んでいるのはSuseのロゴのカメレオン「geeko」が好きだという理由のみ。あとマイクロソフトに駆逐されたnetwareの会社であるnovellが配布元ってのもちょっとあるかも。novellカワイソスということで。
システムに採用した根拠がロゴだけというのもアレだが、正直Redhat系のディストリビューションの違いはわからん。debianだけはちょっと特別やと思うけど、slackware行くほどの元気もない。
それやったらロゴが一番カワユスなSUSEでええやんと言う事なのだ。そういう意味から赤帽はout of 眼中。
まぁ、ロゴがいくらカメレオンやスジシマドジョウでカワユスかろうが、デスクトップログインせずに、リモートからsshやtelnetで使ったりrshでmp3プレイヤーを起動して使う分には全く関係ないというのは内緒だ。

と言う事でSuse10インストール。
特に問題なくインストール完了。懸念されたディスクのエラーもなし。
結局9.3カメレオンは何が壊れとってん？ext3はジャーナリングファイルシステムのはずやのに全くひどい話やと。Solarisのように根性で起動して来んかい。この腐れカメレオンが！
最近色々な意味で悶々としているので理不尽に腹が立つ自分にちょっと反省しつつも、爬虫類好きの俺としては、バージョン10でデフォルトになったリアルカメレオンの壁紙にちょっとニヤニヤする。
ちなみに冒頭の画像の左が9.3のデフォルト壁紙、右が10.0でのリアルカメレオン。
俺としてはリアルカメレオン気に入ってるけど、普通はダメなんじゃないだろうか？
このカメレオンだけで「SUSEつかわねー」と言う人がいるような気がする。

で、以前は書いてなかったので、この際リモートからmp3再生する方法を書いてみる。
mp3再生用pc (mp3 192.168.1.10)
リモートコントロールPC (pc 192.168.1.11)
再生するユーザー (user)
とし、pcからのシェルスクリプトクリック一発で、mp3のxmmsが起動してコントロールできる状態が到達点。

先ず、DVDからSUSE10をインストールしただけではライセンスの問題でxmmsでmp3が再生できないので、xmmsのmp3再生プラグインをインストールしてやる。
xmmsのmp3プラグイン配布元の（なのか？）のダウンロードからそれらしいパッケージをインストールしてやる。
suse用はなかったので、Red Hat Linux9用のrpmをインストール
rpm -ivh http://www.gurulabs.com/downloads/xmms-mp3-1.2.7-21.p.i386.rpm
これでネットワーク上からパッケージが入りxmmsでmmp3が再生できるようになる。

ここからはシステム上でリモートコマンドを受け付けるrshdを有効にし、一般ユーザーでaudioデバイスを扱えるように設定する。
お願いします！ヤッさんということで、全てYast2からの操作になる。

1. リモートからのxmms実行にrshdを使用するので、rsh-serverパッケージをインストール


2. rsh-serverを動作させる為に「ネットワーク・サービス」「shell」（in.rshdな）を「オン」に。


3. firewallが動いているとうっとしいのでこれを止めておく


4. 更に該当ユーザーからaudioデバイスを開けるように「セキュリティとユーザ」「ユーザーを作成あるいは編集する」から該当ユーザーを「audio」グループに参加させる。


5. 該当ユーザーのホームディレクトリに.rhostsを作成し、リモートのコンピュターのipアドレスを書いておく。rshdはこのファイルを読んでリモート実行するか否かを判断している。
6. リモートコントロールPC上で以下のようなシェルスクリプトを作成。rmt-xmms.shとでも名付けておけばわかりやすくて吉。



#!/bin/sh
/usr/X/bin/xhost 192.168.1.10
rsh 192.168.1.10 /home/user/bin/mp3play.bash 192.168.1.11:0.0


やってる事は192.168.1.10からのxクライアント接続を許可し、192.168.1.10の/home/user/bin/mp3play.bash をディスプレイ名の引数をつけてリモート起動
7. 次にrsh越しにmp3再生pc上でリモートから実行される/home/user/bin/mp3play.bashを作成。



#!/bin/bash
export DISPLAY=$1
export LANG=ja_JP.eucJP
xmms


2行目と3行目で環境変数DISPLAYに第一引数で与えられたリモートコントロールPCのディスプレイ名を設定し、ついでに言語をEUCに設定。最後の行でxmmsを起動。Ｘクライアントのの出力先となるＸサーバーは環境変数DISPLAYに設定された値、つまりはリモートコントロールPC上となる。

もちろん両スクリプトともにchmod 700 と実行権限をつけておく。

つーてもPDFlibだのClibPDFはライセンス上グレーになるのでpLaTeXを使ったのだが、変換自体は外部コマンド叩くだけで良いにしても、web-dbを構築するより、TeXのマクロつーかコマンドが一番ややこしくてこれに一番時間を取った。
sql文だとかphpはもうだいぶ慣れてきているけど、なにしろTeXは一から勉強したようなもんやし、しかも目指すところが表組みやったもんで。
いつもはSolarisばっかり、家でもデスクトップ機としてsolaris使ってるけど、さすがに並列処理なんか全くなくって、シングルスレッド性能が発揮されるような使用条件になりそうやったのでムリヤリSolarisで構築する意味は余りなくって、かといってLinuxも使いたくなかったので、NetBSDを使ったということになる。
日常業務をこなしながら並列処理でこれを作ったわけで、開発期間中はマルチタスクどころかマルチスレッドな気分やった。UltraSPARC T1 みたいやな俺ってば。（自画自賛）でも俺の仕様はオープンソースじゃないぞ。

いつもはsystemV系のコマンドやとか構成に慣れ親しんでいる訳やけど、NetBSDを長時間触ってるとそのBSD系のrcスクリプトの構成とかもええなーと思ってくるから不思議なもの。
何よりもインストールの初期状態のシンプルさが良い感じ。（まぁBSD系とは関係ないが…)perlは入ってないけど、iconvは入ってるというセンスが何となく気に入った。
BSDのエラい人はなんだか怖いけど、やっぱりBSDは硬派だなーと思った春。

手元のPC WindowsXP
再生用PC SuseLinux9.3

1 まず手元PCでcygwinでXを起動
startxwin.sh

2 Xサーバーとxtermが起動するのでXクライアントの接続を許可するホストを設定
xhost playerpc

3 プレイヤーを起動するためにXtermから再生PCに接続
ssh playerpc

4 ログインしたらXクライアントの出力先を指定
export DISPLAY=手元PC:0.0

5 再生ソフトを起動
xmms

これで手元のPCにxmmsが起動する。んーなかなか便利。手元に巨大なVNCの画面じゃなくて、xmmsだけが起動しているてのが良い。
これらの手順をスクリプトにでもしとけば簡単かと。

しかし、こういう使い方すると音楽再生用PCってのはこの手元PCからすれば「音楽再生用モジュール」のように見えなくはない。
「X window system」てのはソフトの演算やらはクライアントで、GUIの画面表示だけをサーバー側に送るサーバークライアントなシステムやけど、何でもサーバークライアントで処理してしまおうとするUNIX的な手法は、すべてを自分の延長としてつなぎ合わせる考え方でもあるのだと再認識。ユーザー主導なUNIX文化をちょっと感じた。ようは「便利になりそうやったら何でもええやん。」ということやね。