白 Be　2004 年 11 月

　BeOS 及びパソコン関連の日記です。といっても毎日書いているわけではありませんが(^^;)。タイトルは「はくび（白眉）」と読んで下さい。BeOS が最も優れた OS になってくれたらいいなぁ、などと期待しながら……。
　各日記の日付の部分は、その日記のアドレスへのリンクになっています。他の雑談や日記からこの日記へリンクを張る際の URL 取得用としてご利用下さい。

［ << 前の白 Be ］　［ 翔星 Be ランド　Home ］　［ 次の白 Be >> ］

2004/11/29　AT のヘッダ更新中

　自分の中でも整理しながら。
　現在は LHA Archive Translator が事実上のリファレンスアドオンになっているけど、これはどうも無理がある。もっと分かりやすいサンプルコードとしてのアドオンを作ろうと思う。

2004/11/27　AT のドキュメント

　作らないと。

2004/11/26 C　AT 仕様策定

　思っていたよりも小さな改良で済みそうな予感。

2004/11/26 B　大きな BFS 属性

　LHA Archive Translator で、大きなサイズの BFS 属性をファイルとして格納することにしたが、その際のプロトコルをどうしようか迷っていた。
　属性を格納できなかった時はアプリ側に IOExtension で通知し、アプリ側が属性を InSrc で送るようにしようかとも思ったが、アプリ側の対応が必要になってしまうのでやめ。
　属性を格納出来なかった時は、自動的にファイルとして格納しようかと思う。結果として、アプリとしては 1 つのファイルを圧縮したつもりなのに 2 つの圧縮ファイルが格納されることになるが、ファイル化された BFS は不可視にしておけば大丈夫だろう。他の OS 上ではファイルが見えてしまうが……。
　属性を格納出来なかったファイルと、属性がファイルになったものそれぞれに、互いの存在を示す印を拡張ヘッダに埋め込んでおけば対応付けが取れる。

2004/11/26 A　AT 規格策定再開はいいが

　Archive Translator 規格の策定に再び着手したのはいいけど、もう 4 年近くも前のことなので思い出すのも一苦労。
　当時の議論（メール）を読み返そうと思ったが、受信したメールは残っているけど自分が送信したメールは残っていない。しかも、受信メールもいくつかロストしてるっぽい。

2004/11/25　遠回り

　自分としては早く yu-Link の開発を進めたいんだけど……。今の状況はこんな感じ：

→ yu-Link は画像も扱えるので、64KB 以上の BFS 属性を使うことがある
→ Zip は 64KB 以上の BFS 属性を圧縮できないことが発覚
→ ならば LHA はどうか？
→ LHA もダメ（拡張ヘッダに格納できるのが 64KB まで）
→ 64KB を越える場合は複数の拡張ヘッダに分割するように LHA Archive Translator を改良しよう
→ 拡張ヘッダの合計サイズが 64KB までしか許されていなかった
→ LHA Archive Translator をいじっているうちに、Archive Translator 規格の問題が見えてきた
→ Archive Translator 規格の策定を再開

　yu-Link はなかなか進まないけど、停滞していた Archive Translator 規格策定を進めるには良い機会かも。実アプリで使いながら規格を考えていけば、机上のみで考えるより実用的になるだろうし。

2004/11/23 C　LHA 64KB の壁 / 続　▼

　64KB 制限は、1 つのファイルにつけるヘッダの合計サイズが 64KB 以下と言うこと。1 つの書庫につけるヘッダが 64KB 以下というわけではないので、1 つの書庫に複数のファイルを格納しているうちにヘッダの合計サイズが 64KB を越えてしまっても大丈夫。
　ただ、LHMelt (Ver 1.37.4.22) + UnLHA32 (Ver 1.93.1.2) の組み合わせだと、大きめの拡張ヘッダがある書庫を書庫として認識してくれない。1 つのファイル当たり 約 5KB の拡張ヘッダは大丈夫だったが、約 10KB になるとダメ。約 5KB の拡張ヘッダを持つファイルを 5 個格納した書庫（拡張ヘッダ合計約 25KB）は大丈夫。
　解凍レンジは約 40KB の拡張ヘッダを持つファイルも解凍できることを確認。

2004/11/23 B　LHA 64KB の壁　▲

　LHA Archive Translator では、BFS 属性を LHA の拡張ヘッダとして格納している。拡張ヘッダとして格納すれば、他の OS で解凍された場合は属性部分が無視されるのでうっとおしくなくなる。
　しかし、拡張ヘッダには、1 つのヘッダ当たり 64KB までのサイズしか許されていないという制限がある。このため、大きなサイズの BFS 属性は格納できない。
　そこで、大きなサイズの属性は複数の拡張ヘッダに分割して格納することにし、実際にコーディングを始めた。
　ところが、大きな落とし穴が出現。拡張ヘッダのサイズは 1 つ当たり 64KB までなのだが、さらに、全部のヘッダの合計サイズも 64KB に制限されていることが発覚。これでは分割格納も出来ない。
　う〜む、やむを得ない。属性サイズが大きい時は拡張ヘッダではなくファイルとして格納するしかない……。

2004/11/23 A　スパムは少し落ち着いた？

　Gmail に届くスパムの数が一時期よりも少なくなってきた。
　一時は月間 400 通以上だったけど、最近は 300 通を切る。

2004/11/21 D　Be88-BASIC Ver 8.2

　公開。
　Zeta Neo 用にした。その他細かいバグ修正。

2004/11/21 C　ドキュメントのファイル名を変更

　ReadMe.txt のファイル名、今までは言語別に ReadMe_Eng.txt などとしていたが、今度からはロケールファイルと似たような感じで ReadMe_enUS.txt とするようにした。ReadMe.enUS とするのは、（ユーザーからも OS からも）ロケールファイルと間違えられる可能性があるのでやめた。

2004/11/21 B　ロケールファイルのヘッダ

　今後は、ロケールファイルのヘッダに言語名と国名を、現地語表記と英語表記の両方で入れておくことにした。他にも、翻訳者名表示の関係もあって、ちょっと変更。

2004/11/21 A　連画覧 Ver 4.6

　公開。
　バージョン情報ウィンドウに翻訳者名を表示するようにした。他にも、コメント編集ウィンドウや画像情報ウィンドウの細かな修正など。
　フィンランド語のロケールファイルも追加。

2004/11/20 C　Haiku 進捗状況

　7 月と比べるとだいぶ進んでいるようだ。カーネルがアルファになったのが一番大きいかな。Translation はあと一歩で正式版ということか？
　他も、全体的に進んでいる。
　右は 7/3 時点の進捗状況。

2004/11/20 B　イタリア語

　Mattia Tristo さんがイタリア語のロケールファイルを送ってくれたので BeBits に登録。連画覧、Marble MDX Converter、Monkey's Audio Suite for BeOS の 3 つ。嬉しい限り。
　これで連画覧は、日本語（jaJP）、英語（enUS）、オランダ語（nlNL）、フランス語（frFR）、ドイツ語（deDE）、イタリア語（itIT）、ロシア語（ruRU）、ウクライナ語（ukUA）の 8 ヶ国語に対応。

2004/11/20 A　JPBE.net 掲示板

　最近 JPBE.net の掲示板書き込みがぐっと増えたと思う。
　まだ Zeta Neo を使っている人の数は少ないみたいなので、RC3 を使っている人が慣れてきて活動を活発にしてきたということなのかな？

2004/11/14 F　yu-Link Ver 2.7 Developer Release

　限定公開。
　エクスポート機能を搭載。Zeta Neo 用にした。
　エクスポートはまだ UI が整っていない。メニューからエクスポートを実行すると、people フォルダにエクスポートするか、または /boot/home/WorkData 以下に HTML としてエクスポートするかがランダムに決まる。
　旧バージョンとデータの互換性は無い（people ファイルそのものは同じだが、アイテム設定の記録形式が異なる）。コンバータを同梱したので、yu-Link 起動前に付属のドキュメントを見て下さい。

2004/11/14 E　連画覧 Ver 4.5 Release 3

　公開。
　Zeta Neo 用にした。

2004/11/14 D　Monkey's Audio Suite for BeOS Release 5 Revision 2

　公開。
　Zeta Neo 用にした。

2004/11/14 C　Marble MDX Converter Ver 2.5 Release 2

　公開。
　Zeta Neo 用にした。RC3 でも動くのかな？

2004/11/14 B　Zeta Neo に移行

　メインの BeOS 環境を Zeta Neo に変えた。
　今までの Zeta よりも使える環境になった。HDD クラッシュ以来、Zeta RC1 をインストール後に RC2 にアップデートしようと思ったら出来なかったし、RC3 はネットワークの設定で落ちるしと、Zeta の動きがいまいちだったが、Neo は大丈夫。
　インストール時、10 分とは行かないまでも、1 分ぐらい起動時にフリーズしたが、インストール後はむしろ R5 より早いくらいの時間で起動する。
　インストーラを始め、随所で日本語化も進んでいる。RC3 までのロケールファイルはほぼ JPBE.net で作成していたが、Neo への差分はほとんどピーシークラフトがやってくれた。
　問題もある。何回かに 1 度、起動時に KDL に逝く。usb ドライバが原因の模様。また、RC3 で発生したメニューショートカットキーを記憶してくれないバグは Neo でも直っていない。Ctrl/Alt 入れ替えキーマップをまだ使うしかないようだ。

2004/11/14 A　BeOS ファミリー一覧を更新

　BeOS ファミリー一覧を更新。
　いくつかのデッドリンクを生きてるところに変更。

2004/11/13 C　LHA Archive Translator も 64KB 以上の BFS 属性を格納できず

　最近 BFS 属性の話が集中してるけど、さらに。
　Zip 同様、LHA も 64KB 以上の BFS 属性を格納できない。
　BFS 属性はファイルではないので、LHA Archive Translator では BFS 属性をファイルとして圧縮はしていない。代わりに、LHA の拡張ヘッダ部分に BFS 属性を格納している。
　しかし、LHA の規格として、拡張ヘッダは 1 つ当たり 64KB までのサイズしか許されていないため、64KB を越える BFS 属性は格納できない。
　次期バージョンで改善予定。

2004/11/13 B　ついに日本でも Zeta Neo

　既にあちこちで紹介されているように、ピーシークラフト に Zeta Neo が入荷。
　日本でも Zeta Neo が離陸し始めた。

2004/11/13 A　FAT ドライバ with BFS 属性

　BFS の属性は便利だけど、他のファイルシステムにデータを移せないのが難点。もちろん普段は BFS パーティションにデータを保存すれば良いんだけど、特に Windows とデータを共有する時などは、FAT を使う必要が出てくる。1 度 FAT パーティションに移動したファイルを再度 BFS パーティションに書き戻しても、もちろん失われた BFS 属性は戻らない。
　FAT ドライバが疑似的に BFS をサポートしてくれればいいのにな。本体のファイル名の拡張子を .bfsattr とかに変えたファイルに、属性情報を書き込むような感じで。例えば、Test.txt の属性情報を Test.bfsattr に書くようにして、Test.txt に対する BNode::WriteAttr() を行うと実際には Test.bfsattr に書き込まれるという具合。もちろん、属性のパフォーマンスは BFS より劣るだろうけど、メインで FAT を使うわけではないので問題ない。
　このようなドライバがあれば、FAT パーティションにも BeOS のデータをバックアップできて便利。

2004/11/11　Zip 属性問題

　やはり Zip ファイルは、大きなサイズの BFS 属性を正しく扱えないことがあるようだ。
　70KB くらいのファイルの内容（画像）を空のファイルに属性（B_RAW_TYPE）として付加した。その属性付き空ファイルを Tracker から Zip-O-Matic に送ったところ、Zip ファイルが生成されなかった。
　B_STRING_TYPE の属性を 60KB と 10KB と 10KB の計 80KB 付加した時はきちんと Zip 圧縮できたので、圧縮できないための条件はサイズだけではなくいくつかあるのかもしれない。

2004/11/09 B　HDD パーティション

　クラッシュ後の HDD パーティションはこんな感じにした。
　まず、新しく買った 160GB の HDD。

　Win 2000 パーティションには Windows 2000 のみを入れる。アプリは入れない。これで、Windows の再インストールも少しは楽になるんじゃないだろうか。
　Data パーティションはもっと大きくしたかったが、FAT32 の限界が 32GB のようなので（それ以上にしたら、フォーマット後にエラーが出た）32GB で我慢。NTFS にしなかったのは、Zeta からも書き込めるようにするため。
　Zeta はいうまでも無し。
　続く 3 つの BeOS パーティションは、いろいろ BeOS を入れてみることが出来るように準備。しかし、BeOS をインストールすると、Windows 上でドライブレターの再配置が行われてしまって厄介なんだよな……。もともと BFS パーティションにはドライブレターを振ってないんだから、関係ないところに関係ない OS 入れたからといってドライブレターをつけ直すのはやめて欲しい。
　App は Windows アプリインストール用。
　Storage は動画などの巨大なファイルを置く場所。

　2 つ目は従来から使っている（生き残った方の）80GB の HDD。

　この HDD は完全にバックアップ用として使うことにした。
　Backup NTFS は Storage のデータをバックアップ。
　Backup FAT は Data のデータをバックアップ。また、Zeta からもここにデータを保存する。

2004/11/09 A　Firefox 1.0 がリリース

　Mozilla Firefox 1.0 の少なくとも Windows 版がリリースされた。
　BeOS では Firefox 使ってるけど、Windows では未だに Mozilla な俺。Mozilla は多少重いものの、常駐機能のおかげで起動は瞬時。Firefox には常駐機能が無いので、起動に少し時間がかかってしまうのだ。
　1.0 で常駐機能が付くかな〜と期待してたんだけど。

2004/11/08 B　嫌な予感

　もしかして、Zip ファイルって、64KB 程度以上の属性をちゃんと圧縮できなかったりするんだろうか……。

2004/11/08 A　Neo のウワサ

　メモリ 1GB 積んでいても起動するらしい（使えるのは 1GB 未満で、既報の通り、積んでいるメモリをフルに使えるようになるのは R1 以降の模様）。
　インストール時、起動画面（7 個のアイコンが順に光っていく画面）で 10 分くらいフリーズすることがあるらしい。動かないと思いがちだが根気よく待つのが吉。これは USB ドライバが未完成のための模様。ただ、インストール後、初回起動を済ませれば、あとは短時間で起動するようだ。

2004/11/07 B　持ち越し

　BeOS ファミリー一覧は更新できたけど、この土日にやろうと思っていた JPBE.net の歴史編纂と BeBits の歩き方は残念ながら時間が足りず。来週に持ち越し。

2004/11/07 A　謎の連画覧 Ver 4.5 Release 2

　HDD を見ていたら Rengaran45R2.zip なるファイルを発見。現在リリースしている連画覧は Ver 4.5 なので、そのマイナーバージョンアップ版と思われるが、同梱の History.txt を見てみても、Ver 4.5 からの進化点が見当たらない。う〜む、何がしたかったのだろう。
　よくわからないので、見なかったことにしよう。

2004/11/06　BeOS ファミリー一覧を更新

　BeOS ファミリー一覧を更新。
　Zeta の記述を一新。今までは（まだ Zeta が謎に包まれていた頃に書いた文章だったので）yellowTAB と表記していてディストリビューションの 1 つとして掲載していたが、Zeta と表記を改め、公式な BeOS の後継に格上げした。
　スクリーンショットはまた後で。
　Haiku ももっといろいろ書きたいけどまた後で。

2004/11/04　土日作業予定

　メモ。

・BeOS ファミリー文章更新
・JPBE.net の歴史編纂
・BeBits の歩き方：アプリ登録更新編

2004/11/03 B　関西オープンソース 2004 の写真

　関西オープンソース 2004 で撮影した写真を公開。クリックで拡大。
　右の写真は、東京 FXF の Zeta プリインストールマシンで Zeta が動いている様子。この Zeta は Neo じゃなかったんだっけかな？
　JPBE.net ブースの様子。
　俺は 23 日（土）しか行ってないけど、お客さんがいない時間帯はあまりなく、ほとんど常に 1 人以上のお客さんが JPBE.net ブースに来ていた。
　立地も良かった。川が 2 本あったのだが、JPBE.net ブースがある方の川は全体的にお客さんが多く、もう片方の川は閑散としていた。
　OpenBFS についての講演をする Bruno さん。
　一般的なファイルシステムについての説明や、BFS の特徴などを話してくれた。個人的には一般的な部分はいらないからもっと BFS について突っ込んだ話しをして欲しかったけど（実装の苦労話とかも）、そうすると聴きに来てくれるお客さんがいなくなってしまうので仕方ないか。
　イベント終了後に Bruno さんからいろいろ話を聞こうと思っていたんだけど、チャンスを逃してしまったな。

2004/11/03 A　ソースかバイナリか

　ここで「ソースよりもバイナリを」と書いたのに関連して、アプリはソースで公開してもらう方が良いのか、バイナリで公開してもらう方が良いのか、ランキング形式でまとめてみた。開発者というよりもむしろ、1 ユーザーとしての、一般的なアプリに対する俺の個人的な希望。

1 位：バイナリもソースも公開

　両方公開してもらえるのならそれに越したことはない。
　ただ、両方公開するのはかなり手間なので、これを希望するのは気が引ける。また、開発者が「公開は手間がかかるから更新頻度を落とそう」と思ってしまう危険性があるのが欠点。
　普段使うのはバイナリであって、ソースを見たいと思うことはまれなので、バイナリとソースは別々のアーカイブにして欲しい。

2 位：普段はバイナリのみ、たまにソースも一緒に公開

　2 位だが、1 位とは僅差。
　通常アプリを利用する際には、バイナリだけあればなんら問題はない。
　ただ、たまに「この部分のソースはどうなっているのかな？」という技術的な興味がわくこともあるので、そういう時にソースを見られると嬉しい。しかし、そのソースは常に最新のものである必要はないので、ソースの公開はたまにで十分。

3 位：バイナリのみの公開

　バイナリさえあれば、ダウンロードしてすぐに使えるので、普段はバイナリのみで用は足りる。
　ただ、もう開発を打ち切るという場合は、ソースを公開して第 3 者によるバージョンアップが期待できる環境を用意して欲しい。

4 位：ソースのみの公開

　ダウンロードした後にコンパイルしないといけないので、少し手間がかかる。コンパイルでトラブる可能性もあるし。
　できればバイナリの公開をお願いしたいところ。

2004/11/01　新バージョンに期待してるソフト達

　個人的に期待してる 3 大アプリ：

1. GuiBerry

　GUI エディタ。初のお披露目から早 4 ヵ月。どのくらいまで開発は進んだのだろう？　そして、Be-IN の消滅と共にホームページが消えてしまったけどこれからどうするのか！？

2. NetPaladin

　Zeta ネイティブの軽快なブラウザ。かえで IM よりこっちに力を入れて欲しい……。

3. Anthy IM

　日本語 IM。フリーとしては驚くべき変換効率を実現。新版が出ないのはソース公開問題で文句いわれてやる気を無くしてしまったからなのかなぁ。個人的にはソースよりもバイナリをどんどん出して欲しい。

番外編：serial midi server

　MIDI 出力。望み薄だけど、USB バスパワーに対応してもらえると嬉しい。

［ << 前の白 Be ］　［ 翔星 Be ランド　Home ］　［ 次の白 Be >> ］