少し前に、gccの最新版らしい、gcc-2.95.2をインストールした。コンパイル作業を別のディレクトリでやることを除けば特に注意することもなく、簡単にインストールできました。コンパイラの動作は若干速くなったような気がします。で、JAVAがネイティブコンパイル出来るらしいということを知って、ライブラリのlibgcj-2.95.1をコンパイルしようとしたら、うまくいかなかった。たしか、こんな感じのエラーだった。
../../../libgcj-2.95.1/libjava/prims.cc: In function `void catch_segv(int)': ../../../libgcj-2.95.1/libjava/prims.cc:62: invalid use of undefined type `struct sigcontext_struct' ../../../libgcj-2.95.1/libjava/prims.cc:62: forward declaration of `struct sigcontext_struct' ../../../libgcj-2.95.1/libjava/prims.cc:62: invalid use of undefined type `struct sigcontext_struct' ../../../libgcj-2.95.1/libjava/prims.cc:62: forward declaration of `struct sigcontext_struct' ../../../libgcj-2.95.1/libjava/prims.cc: In function `void catch_fpe(int)': ../../../libgcj-2.95.1/libjava/prims.cc:72: invalid use of undefined type `struct sigcontext_struct' ../../../libgcj-2.95.1/libjava/prims.cc:72: forward declaration of `struct sigcontext_struct'
残念。このライブラリが素直にコンパイルできている人もいるので、きっと私の環境に問題があるのでしょう。これぐらいなら、自分で何とかなるかな? それとも、JAVAするには素直にJDKを手にいれた方がいいかな。まあ、JAVAは現在もっともまともな設計の言語だと思うので、是非使ってみたいが、なんだか色々めんどくさいな〜
前述のコンパイルエラーだが、prims.ccの頭に
#include <asm/sigcontext.h>
#define sigcontext_struct sigcontext
を加えることで解決した。but...
../../../libgcj-2.95.1/libjava/java/util/natDate.cc: In method `class java::lang::String * java::util::Date::toString()': ../../../libgcj-2.95.1/libjava/java/util/natDate.cc:59: `ctime_r' undeclared (first use this function) ../../../libgcj-2.95.1/libjava/java/util/natDate.cc:59: (Each undeclared identifier is reported only once ../../../libgcj-2.95.1/libjava/java/util/natDate.cc:59: for each function it appears in.) ../../../libgcj-2.95.1/libjava/java/util/natDate.cc:67: warning: control reaches end of non-void function `java::util::Date::toString()'
今度はこんなエラーが!!! 解決法はどうも思いつかないので、素直にけつをまくって、HAVE_CTIME_Rをundefしてもうた。よしよし、うまくいったぞ・・・と思いきや、
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:69: parse error before `('
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:69: parse error before `double'
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:76: warning: type defaults to `int' in declaration of `hx'
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:76: `gh_u' undeclared here (not in a function)
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:76: warning: data definition has no type or storage class
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:76: parse error before `}'
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:77: warning: type defaults to `int' in declaration of `hy'
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:77: `gh_u' undeclared here (not in a function)
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:77: warning: data definition has no type or storage class
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:77: parse error before `}'
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:78: warning: type defaults to `int' in declaration of `x'
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:78: `sh_u' undeclared here (not in a function)
../../../libgcj-2.95.1/libjava/java/lang/s_copysign.c:78: warning: data definition has no type or storage class
でも、こいつも、直前でcopysignを#undefしてやったら片付いた。よし、コンパイルが通ったぞ!! おなじみのHello Worldを「gcj Hello.java --main=Hello」とかやってコンパイルして、ちゃんと動いたし、言うことないね。こりゃ。
public class Hello {
public static void main(String[] args){
System.out.println("Hello World!!");
}
}
最近知ったんですけど、「法の華」って「ほうのはな」って読むんですね。ずっと、「ほうのか」って読むのだと思ってました。恥かいちゃいました。
そういえば、以前にMicro$oft製品には「セキュリティーホールが無い」という話を聞いたことがあります。そのときは「はぁ?」とか言っちゃったんですけど、これって実はジョークだったのですね。わかります? つまり、「セキュリティーが皆無だから、そもそも穴は存在しない。」って理屈です。「ドーナツが無ければ、ドーナツの穴があるわけ無い。」と同じことです。気がついて笑ってしまいました。こういうジョークは嫌いじゃないです。
Microsoft等のソフトメーカー7社(Microsoft, JUSTSYSTEM, ロータス・デベロップメント, Adobe, オートデスク, インターコム)が、ソフトの不正利用で東京都内の地質調査会社を相手取って総額2000万円の損害賠償を求める訴えを東京地裁に起こす方針を決めたそうです。毎日新聞朝刊で、気になったのは「7社は、ライセンス料相当額の約1000万円分を基準に、ソフトの不正による経済的な損害額を2倍と推定して2000万円の賠償を求めることにした。」という部分です。どうやって、2000万円という数字を計算したのでしょうか。気になります。多分、裁判には勝つでしょうけど、賠償額は2000万円以下でしょう。それと、「ソフトの不正」という表現はGOODです。記者が、キーを押し間違えて、本音を書いちゃったんでしょうね。(ちょっと、フロイトよりの解釈かな・・・)
疲れた〜 でも、今週は土曜日も学校があるんです。うわー、めんどくさ。
そういえば、アマゾンがネット決済に関する技術が特許を侵害しているとして、同業の会社を訴えていたようです。今日、新聞を読んでいて初めて知りました。問題となったのは、「ワンクリック」とかいう技術だそうです。「消費者がネット上で二回目以降に購入する際、住所やクレジット番号を再入力せずに買物が出来る仕組み」らしいです。でも、それって普通にクッキーとCGIを使えばできる事だと思うんだけどね〜 なにか新しい工夫でもあるのでしょうか? 気になります。
タイトルのように、僕は今、BackSpaceとDeleteを使い分けたい。状況によって、emacs(Mule)に対するキーの挙動が異なるのが最初に気になった。という事で、表にしてみた。ちなみに、Plamo Linuxではデフォルトで、BackSpaceとDeleteを入れ換えているが、それは無効にしてある。
| キー＼状況 | Linux/98のコンゾール上 | X Window System | kterm / xterm | rxvt |
|---|---|---|---|---|
| BackSpace | ○ | ○ | C-hを押したことになる | C-hを押したことになる |
| Delete | ○ | バックスペースと同じになってしまう | バックスペースと同じになってしまう | 無効(ビープ音が鳴る) |
bashの行編集(readline)もターミナルによって挙動が異なるようだ。
| キー＼状況 | Linux/98のコンゾール上 | kterm / xterm | rxvt |
|---|---|---|---|
| BackSpace | ○ | ○ | ○ |
| Delete | ビープ音と共に、チルダが入力される | バックスペースと同じになってしまう | ビープ音と共に、チルダが入力される |
ただ、Deleteキーをカーソルのある場所の文字を削除するように変更するのは、どこかで聞いたことがある。.inputrcで設定するのだそうだ。Ctrl + d はそのように動作しているので、Deleteキーにも同じキーを割り当てれば良いだろう。というわけで、
"\d": delete-char
としたら、なんとDeleteじゃなくて「d」にその機能が割り当てられてしまった。
と、せっかく悩んでいたらJFのConfig-HOWTOにこれらの設定法が書いてあった。それらの方法を試みると、見事にreadlineでDeleteとBackspaceを使い分けられるようになった。rxvtについてはめんどくさそうだし、使わないので、諦めた。muleについては以下の通り。多少は改善したので、今日はこれで良しとしよう。
| キー＼状況 | Linux/98のコンゾール上 | X Window System | kterm / xterm |
|---|---|---|---|
| BackSpace | ○ | ○ | ○ |
| Delete | ○ | バックスペースと同じになってしまう | 無効(ビープ音が鳴る) |
Configuration HOWTO に書いてあった通りにやったら、簡単にrxvtでもDeleteが使えるようになった。具体的には、「.bashrc」に
if [ "$COLORTERM" != "" ] ; then stty erase ^? ESC=^[ echo -n "$ESC[36l" fi
を加えることで、実現できた。(ただし、「^[」はそのままの文字ではなく、0x1Bです。emacsならC-qでESCキーを押せば入力できます。)
kterm/xterm上のemacsでは、「.emacs」に
(global-set-key "^[[3" 'delete-char);
を加えたらDeleteを使えるようになった。
(これも、「^[[3」はそのままの文字ではなくて、「0x1b 0x5b 0x33 0x7e」というバイト列です。kterm上のemacsでC-qの後にDeleteキーを押すことで入力できました。)
X Window Systemのemacsには、BackspaceもDeleteも共に「^?」(DEL: 0x7f)が送られて来ているようです。(少なくとも、C-qで入力した結果はそうだった。) これは、この方法では対処できないかな。また、rxvt上のemacsでも、Ctrl+hとBackspaceが両方とも「^?」(DEL: 0x7f)を受け取るようだ。それと、気がついたのだが、kterm/xterm/rxvt上のemacsでは、テンキーが無効になってしまっている。(それぞれの、ターミナル上のシェルでは使えるにも関わらず。)
一般に、システムを構成する様々なコンポーネントは、上位のコンポーネントがより下位のコンポーネントを利用する形で、階層立てて組み上げられているべき。階層を無視した構成は柔軟性と保守性を低下させる。という話は耳タコだが、それと同じような問題を感じる。PC UNIX には一般にこのような問題が多いと思われる・・・ (もっとも、Windowsやら、商用のUNIXならば大丈夫というわけでもないと思う。)
昨日、友人に、以前の日記で「封神演義」を「封神演技」と書き間違えていたのを指摘されてしまいました。はずかしー
今日の日経新聞朝刊(19面)で、「遺伝子データ圧縮処理」という記事がありました。要は、「医薬分子設計研究所というところが、膨大な遺伝子データを少ない情報量に圧縮してIDを付ける"Eigen-ID"という新しい情報処理手法を開発した。」と言う話なのですが、どうもアレです。記事を読むとハッシュを応用して160bitのデータにするという話です。ところが、ハッシュなんかは昔からあるわけで、記事を見る限りどこも目新しくなく見えます。大体、ハッシュの「衝突」はどう扱うのでしょうか? 本当の新技術があるとしたら、そのあたりだと思うのですが・・・ ちなみに、1人の人間のDNAのデータ量は3Gバイトほどらしいです。ビックリしちゃいました。もっと、大きいと思い込んでましたです。
3日ほどBackspaceとDeleteと格闘してみて、気がついたことをまとめてみようと思う。
キーの情報が伝達される経路はアプリケーション側から見たら、こんな感じに階層化されているように思える。(テーブルを使って表現する都合上、「↓」はそのまま下に情報が伝わるものだと思ってね。) もっとも、僕の誤解はけっこうありそうですけど。
| telnet等で送られてくるキーの情報 | キーボードの押下 | ||||
| kernelのキーマップによる変換 (loadkeysコマンドでカスタマイズ) |
X Window Systemのキーマップによる変換 (xmodmapコマンドでカスタマイズ) |
||||
| ターミナル(linuxターミナル, xterm, kterm, rxvt, etc...) | ↓ | ||||
| ↓ | |||||
| ttyドライバ (sttyコマンドでカスタマイズ) |
termcap/terminfo | ↓ | |||
| readline (.inputrcでカスタマイズ) |
↓ | curses | ↓ | ||
| アプリケーション | |||||
ここで、気がついて欲しいのは「キー情報がアプリケーションに送られる際に、必ず経由する層が存在しないこと」です。もし、そのような層が存在すれば、カスタマイズは今よりずっと容易だったでしょう。これは、UNIX + X Window System というアーキテクチャーを採用している限り、どうしようもないことなのかも知れません。(そう考えると、BeOSのようなアーキテクチャにも興味がわいて来ます。)
僕が困惑した訳を書こうと思うが、その前に話題に関係する制御文字(制御バイト等と呼んだ方が適当な気はするが)について簡単にまとめてみようと思う。(書いていて僕が混乱して来たので・・・) 以降の説明にもこの名前を使います。ここでは(面倒臭いので)書かないが、他の制御文字についても興味があったら、調べてみると良いと思う。
| バイト値(16進数) | 名前 | 表示 | 備考 |
|---|---|---|---|
| 0x08 | BS | ^H | - |
| 0x1B | ESC | ^[ | エスケープシーケンスの開始バイト |
| 0x7F | DEL | ^? | - |
一般的なLinuxでは、BackspaceとDeleteが入れ替わっているらしいです。たしか、友達のPCにインストールしたときも、そのようになっていたと思います。これには、"The Linux Keyboard HOWTO"によれば2つの理由があります。
一方、Linux/98のキーマップ(defkeymap_pc9800.map)では、そうではなくて、ちゃんとキーの刻印通りになっているように見えます。(デフォルトの状態では素直な設定になっていることは、僕はとても大事だと思います。) Linux/98のキーマップで、もう一つ特徴的だったのは、コンソール上のemacsでC-hとBackspaceを使い分けられることでした。どこから聞いたのか、コンソールではC-hとBackspaceが使い分けられないと思ってました。さて、emacsにはどのようなバイトが送られているのでしょうか。
| キー | バイト(列) |
|---|---|
| Backspace | DEL |
| Delete | ESC 0x5b 0x33 0x7e (表示は「ESC [ 3 ~」) |
| Ctrl + h | BS |
あれ、BackspaceとDeleteはやはり入れ替わっているように見えます。(もっとも、PC AT互換機用のLinuxでここまで調べたことはないので、これが正常なのかも知れません。) しかし、それでもキーの刻印通りに使えているということは、どういったことでしょか? 私は困惑するばかりです。
さらに、昨日の設定によって、kterm上でDeleteが使えるようになりましたが、C-h kでDeleteを押すと、「ESC [ 3 ~ runs the command delete-char 〜以下略〜」というような説明が出て来ます。昨日の設定をする前は、コンソールでは「ESC [ 3 ~」の部分が「deletechar」になっていました。C-qでは同じ「ESC [ 3 ~」(ESC 0x5b 0x33 0x7e)なのに、こっちでは異なるのです。この状況に対して、自然に考察するならば、「コンソール上ではバイト列 ESC 0x5b 0x33 0x7e が、deletecharとして認識されているのに、kterm上ではそう認識されていない。」といったところでしょうか。こうなると、問題はtermcap/terminfoにあるというのがもっとも有望だとは思います。きっと、「X Window Systemのキーマップの設定を変えて、BackspaceとDeleteを使い分ける」ような事を想定していない設定がtermcap/terminfoにしてあるのでしょう。もっとも、僕はtermcap/terminfoはチンプンカンプンなので、どうしようもありません。
一方、X Windows System上のemacsで、DeleteとBackspaceが区別できないのも謎です。上の方の「キー情報の伝達経路」の表のどの部分が問題なのでしょうか? つい、すべての部分が問題なんじゃないだろうか?、と疑心暗鬼になってしまいます。僕の表が間違っているってのもかなり確立高いですけど。
今日も、特に日記に書くような事もなく一日を終えてしまった。でも、こうしてコンピュータをいじったり、問題集を解いたり、読書したりしながら何事もなく日々をすごしているってことが、どんなに恵まれているかとか、ふと考えるんですよね。まがりなりも先進国と呼ばれる国に生まれ、理解ある両親に育てられ・・・ 要するに、たまには自分の境遇に感謝しなくちゃいけないなと思ったんですよ。世の中には、自分の努力だけではどうしようも無いことっていっぱいありますよね。運命を呪うことなく生きていけたら良いな。僕は、そう思う。でも、これも自分勝手かな? わからない。僕にはわからない。
さてさて、今日、新聞でトレンドマイクロ社の広告を見ました。それに、ウイルス対策診断で、ウイルス感染の可能性が高くなるシステム運用環境というのがありました。その条件とは・・・
という条件のようです。まあ、正しいんでしょう。ただ、一つ大事な条件が抜けていると思いませんか? もし、僕なら、この項目を絶対に加えます。
これらの、最凶ソフトの使用を制限することで、ウイルス - 特にマクロウイルス - の被害は激減するでしょう。(もっとも、その代替として使用する製品が安全だとは限りませんが。) これらはマクロウイルスの温床です。それどころか、勝手に(ウイルスが含まれる可能性のある)添付ファイルやマクロを実行すると言う点で、これ自体「トロイの木馬」ウイルスに分類しても良いと思う。本当に、Outlook Express とか Office をウイルスとして検出するようなソフトがあったら面白いだろうな〜
それと、UNIXをとかだと一般ユーザーがウイルスを実行したとしても、システムの実行ファイルは一般にrootとかでないと書き込み権限がないので、あまり感染できないよな。だから、最悪でもそのユーザーの環境を破壊するだけ。それに、UNIX用のメーラーで、添付ファイルを勝手に開いたりするものも無いと思う。UNIXでは、ユーザーが十分気をつければウイルスは避けられるように思える。あ、本当はこれが正常なんですよ。異常なのは、今のWindows等の状況の方です。
最近は、またgimpのプラグインとかいじっている。で、人のプラグインを見ていて思ったのだが、よくこんなコードを書く気になるよな〜 はっきりいって、かなり凄まじいですよ。あ、別に悪く言ってる訳じゃないですよ。ただ、僕には真似できないな〜と思った次第。gimpのAPIは非常に柔軟で、いろんなことが出来るのだが、それだけを使って、あれだけの物を書けるんだから、凄いもんだ。色調を変換するプラグインを書くだけでアレはね〜 さすがバリバリのハッカーですな〜 僕だったら、例えば、色を変換するコールバック関数を引数に持つようなヘルバールーチンでも作って、手を抜きます。楽だけど、速度と柔軟性は低下しますね。僕の書いたDibasのプラグインのdbssushoも、上位のクラスをヘルパールーチン的に使っていたんだけど、あれは設計を失敗しましたね〜 何をどのように隠蔽するか、それが問題です。あ、いまさら言うまでもありませんね。判っている人は良いんです。理解していない自分のためにメモしておこうかな〜と思ってさ。
そういえば、GIFでも使われているLZW圧縮の特許ですが、ライセンスを結んでいない場合は、どういうことするとまずいんでしょうか? 例えば、こういうのはどこまでがセーフなんでしょうか? だれか、是非教えて下さい。境界がかなり不明瞭に思えます。
久しぶりに、Linux/98のカーネルを再構築した。シャットダウン時に電源が切れるようにするにはAPMを有効にすれば良いのではないか、ということの気がついたのだ。とりあえず、設定でAPMを有効にして、その後Makefileの「SMP = 1」となっている部分をコメントアウトしてSMP(Synmetrical Multi Processing)を無効にした。(APMとSMPは排他利用らしいので。) で、コンパイルしたらエラーになるじゃないですか・・・調べてみると、/usr/local/binにパスが通ってたので、こないだ入れた新しいgccが使われていたのですね。カーネルの2.1.57は新しめのgccじゃ、コンパイルできないのですね。しょうがないので、/usr/local/binをパスから外してコンパイルしましました。(環境変数CCに明示的に指定するって手もあったかな) 今度はうまく行きました。しかし、起動時のメッセージはこれでした。
APM BIOS version 1.12 Flags 0x03 (Driver version 1.2)
Entry f680:6 cseg16 f680 dseg 0 cseg len ffff, dseg len ffff
Power status not available
残念でした。ちゃんちゃん。
メールでは、というよりInternetの世界では、 ファイルの種類はDOS/Windowsの拡張子や、Macintoshのファイルタイプではなく、 MIME Type という物で識別します。 Mewでも、添付ファイルの画面の、「Content-Type:」という項目に 「Image/Jpeg」だとか、「Text/Html」だとか、 「Application/Octed-Stream」だとか表示されていますね。 これがそうです。 良く使う、MIME Type をいくつかあげておきましょう。 まずはデキストの形式です。 Text/Plain プレーんテキスト Text/Html HTML形式 ちなみに、「Text/」の後に来る識別子が認識できない場合は 「Text/Plain」として処理できるように、MIME Type は 主型(この場合は「Text」)と副型(この場合は「Plain」)からなっています。 次は、画像。 image/png PNG形式 image/jpeg JPEG形式 image/gif GIF形式 テキスト以外では、型が未知の場合は一般に 後述する「Application/Octed-Stream」として処理します。 (もちろん、テキストの場合も同じようにするソフトもありますね。 Mewもそうです。) サウンド audio/midi MIDI形式 audio/basic AUフォーマット その他 application/octed-stream 任意のバイナリ形式 message/rfc822 Internet Message (メールや、ネットニュースなど) 大体、こんなところがメジャーですね。 ちなみに、大文字と小文字は区別されませんです。 でも、規格を直接読んだことがないので良くは知らないのですが、 MIME Type は私製のものも定義できるようです。 例えば、image/x-ms-bmp というタイプで、Windows Bitmap を表したりとかです。 もっとも、知らないタイプは、すべて「application/octed-stream」として 処理されるので、特に問題はないんですけどね。
昨日今日と、沢山のソフトを再構築した。glib-1.2.6, gtk+-1.2.6, gnome-libs-1.0.54, gnome-core-1.0.55, gimp-1.0.14, mc-4.5.42・・・以外と少ないか・・・それにしては時間がかかったけど・・・
gimpは再コンパイルするつもりはなかったのだが、glibを作り直したら、起動時に「/usr/local/lib/gimp/1.1/plug-ins/script-fu: can't resolve symbol '__register_frame_info'」というメッセージが出て起動しなくなってしまったので、コンパイルしなおすことにした。gimpで、カラーピッカーのモジュールが使えなかったのは、--with-included-gettext付でコンパイルしていたのが原因だったようだ。しかし、--with-included-gettext無しではコンパイルが通らない・・・gettextのインストールの仕方がマズlかったか?
相変わらず、gnomeが文字化けする原因は不明である。再構築しても、やはり解決しない。怪しそうなのは、gnome_init_cb関数内のputenv ("LC_CTYPE=en_US");ぐらいしか思いつかないが・・・
GIMPプラグインのMathMapをインストールしました。日経Linuxで紹介されていたので、興味を持ったのです。・・・手軽ですね。数式を与えるだけで、画像を変形したり出来ます。プラグインを組む手間と比べたら大違い。速度は、Nativeなプラグインには当然劣りますが、意外に速かったです。
何か、最近の日本の謝罪問題とか見てると妙な気分になる。「謝罪せよ」とか「謝罪するべきだ」と言う人は、よく「自虐史観」という批判を受ける。それに対する反論も大体決まっている。「過去を正しく認識し、過ちを過ちを認めることの何処が自虐か!!」である。はっきり言って、随分退屈な議論じゃないっすか? ここ数年、そっから先に話が進んでいない気がするんだよね。あ〜あ。もちろん、「過去を正しく認識し、過ちを過ちと認めることの何処が自虐か!!」ってのは正論だよ。But... そう発言している人間に限って、過去を正しく認識してるかどうか、随分と怪しいのだ。(もちろん、すべての人がそうだ、と言う気はないけどね。) 「自虐史観」と批判されても仕方のない発言をしている人も随分と多い。それに、この手の議論を見ていて思うのが、「こいつらは国際政治を知らんとちゃうのか?」ってこと。過去の問題であっても、それが現在の政治のコンテキストで論じられるからには、その議論が現在の政治においてどのような意味を持つかも考えるべきだろう。それに、人道問題を政治のカードにするどっかの政治家もムカツク。まあ、それが政治ってのも正論でしょうけどね。大体、謝ってそれで済む問題なのか? 結論としては、こういうウザイ話に耳を貸す必要は無いってこと。
・・・それにしても最悪だ。新しいページのFTPは、何故かmirrorでアップデートできない。Why!!! mirrrを普通に実行すると、
package=default ftp4.nifty.com:/homepage -> /home/susho/public_html/nifty/ Cannot cd to original remote directory at mirror/mirror line 3116.
と言われてしまう。また、"-n"オプションを付けるといつも通り沢山のメッセージが表示される。そのなかで問題なのは
150 Opening ASCII mode data connection for /bin/ls. timed out
という部分だろう。perlにチンプンカンプンな僕に直せるわけ無いし・・・ 困った、困った。しかも、emacsのange-ftpでも、ディレクトリを一度に送ったりしようとするとエラーになる。Midnight Commander だと大丈夫だけど、GNOMEは文字化けするし、コンソールで使うのも面倒だ。というわけでIglooFTPをインストールしてみた。見た感じの使い勝手は良さそうだ・・・ さあ、アップロードしてみよう。
一昨日、昨日と調子が良かったのだ。ドライバを改造することで、内蔵のPCM音源(Microsoft Sound System)と内蔵のFM音源を使用できるようになった。これで、MIDIも再生できるぞ。ただし、音質はいまいち。もっとも、TiMidity++というソフトウェアシンセサイザをインストールする予定だから、こっちは音質が悪くてもそれほどかまわない。その分、負荷も軽いしね。
そして、今日はMP3のプレイヤーを入れた。XMMSのようなのを入れても良かったのだが、とりあえずコマンドラインのmpg123と、そのGUIフロントエンドのGQmpegをインストールした。そのうち、エンコーダもインストールしよ〜と。「BladeEnc」、「午後のこ〜だ」、「Lame」あたりが有力な選択肢。(というか他にある?) う〜ん。どれにしようかな〜
内蔵FM音源を使用できるようにするドライバの改造は一般化した上でパッチにまとめてアップロードできた。内蔵PCM音源についてはちょっと不可解な現象が確認されたので、まだパッチにはしていない。ただし、SoundIDが5の場合でもMSSとして認識する部分については、Linux/98のソースツリーに取り込んでも良いと思う。
それと、僕のCu13はWindowsの時には「98 Canbe Sound MPU401」というドライバ名で、MPU401互換(?)なMIDIのインターフェースが本体前面にあった。それをLinux/98でも使えたらと思い、MLの過去のログやらDOS用の初期化ツールやらMPU401関連の資料を集めて来た。MLの過去のログによると、118ボードのドーターボードのMPU401音源については既にDOS用の初期化ツールを使用することで成功しているだ。さてさて、うまく行くでしょうか。ウヒヒ
おお、遂にこの日がやって来ました。Y2Kバグ。さて、何が起こるのでしょうか。とりあえず、オイラのPCには関係ないはず。ハードウェアは対応しているはずだし、Linux自体も問題ない。某M$製品のような出来の悪いブラックボックスが入っていないというだけでかなり安心します。ところで、人工呼吸機が危ないとかいう話も聞きました。でも、本当に人工呼吸機が日付情報を使っているのでしょうか? それに、日付が1900年になると核ミサイルが発射されるとか言う根拠レスな噂も飛び交っていますね。一人歩きする情報は恐ろしいです。一番ありそうな線としては、0時前後に多くの機器の電源が切られたりすることによって、送電が不安定になり、混乱が発生するってところでしょうか。
MIDIインターフェースはDOS用の初期化ツールでは無理でした。118ボードが無いとか言われちゃいました。残念残念。