PuppyLinux の方向性と JP版リリースについての意見
Posted: 09/11/22(日) 04:35
まだ日本語版を一週間しか使っていないから、勘違いしている部分もあるますが、いろいろ気付いた点をお知らせします。「そんな事もうやっている」という事なら無視して下さい(というか、そう御教示下さい)。 トピック毎に副題を付けていきますが、長くなると思いますので、副題を参考に飛ばして読んで貰ってかまいません。たいくつかも知れませんが、パピーの魅力を高め、あわよくば商品化したいと思っている人は是非読んで下さい。
パピー本家の姿勢を考察してみる。 そして提案。
私の見る所、バリー氏とその周辺は現在の基本姿勢を大きく変更する気が無い様だ。つまり、私の目からすると、PuppyはこのままToyOSでありつづける。別にサーバとして使っても構わないかもしれないが、それはCommercialGradeではない。SingleUserModeを付ける気がない事でもそれが分かる。本家がこれだから、それ以上の物を日本語仕様で作る事は限界がある。(逆に日本語版PuppyLinuxの運用の時は、この事実を考慮する必要がある)
さらに日本語チームとのやりとりの様子から、口ではInternationalizationやLocalizationが必要でサポートするといいながら、行動が伴っていない。(多分本人に自覚が無い)。
日本語化というか i18n と l10n を本気でサポートする気があるなら、それが難しいもの(JWMのメニュー等)は、英語版は"_en"という接尾語(suffixって英語で言うんですがね、日本語では?)を付けてもらい、英語版はそれに ln -s するようにしてもらう。 それなら bash や sed/awk を駆使して、ブート時に選択した言語にl10nファイルを自動設定できる。 この手法を本家にとってもらえば、日本語版だけでなく、英語以外の全ての言語をサポートする事が楽になる。この方法のもう一つの利点は、JWMのメニューに言語切り替えを付加できる事。 シェルスクリプトで、指定した言語に ln -fs すれば良いだけ。
日本語版の開発とリリース方法
日本語版は本家版に欠陥が無いと仮定して開発を行う。本家版はかなりテストして出していると思われるから、そう仮定しても問題は無いと思われる。 また、もし重大な欠陥がリリース後に見つかれば、そのBugFixは早いと思われる。その際、欠陥版の日本語版のリリースは見合わせても問題ないと思う。(時間と労力の無駄)。
日本語化は、基本的に幾つかのPETを準備する事で行う。例えば本家4.30に導入し、そのままリマスターすれば日本語リリース版と同一の物が出来るPETの集合体を準備する。 (そうであるべきと思い、英語版4.31に ftp://www.ring.gr.jp/pub/linux/puppylin ... iginal2ja/
を導入してみたんですが、失敗しました。ちょうど手元に431 しか無かったから431で実験。これでも行けるはずと思ったんですが。scim -d で Failed to load x11 FrontEnd module でしたね。430だと動く保証があるなら一度試してみたいです)。
何故そうするかというと、日本語追加パッケージがバグの原因になっているのか、本家版にもともとバグがあったのか見極める必要があるから。 もし日本語PETsに問題がある時、デバグチームはVirtualMachine(以下VM)上で英語版を使用して報告されたバグが起こる環境まで持っていく。そこでVMをセーブ。あとは一つづつ日本語化PETを入れていき、問題が無ければ巻き戻し。 これでどのPETが問題か検討がつく。(ま、バグ報告において、どのアプリケーションが問題か、明確に分かる時はこの手法は使わなくてよいが、VMはとにかく便利)。 ーーー でも多分、日本語化のバグは、システム設定の問題に起因する事がほとんどなんでしょうね。わざわざstripしていないバイナリを持ってきてgdb走らせる必要なんて無いのかな?
もう一つついでに。日本語版CDの発表の際、本家版のsmall.isoを使用してはどうでしょう? 実際電話線のモデムを使っている人って日本では居ないのでは? 海外で日本パピー・モデム付きが必要な人は、本家版に日本語化PETを当てる。
PET パッケージについて
もう本家のほうも日本もぐちゃぐちゃ。 <ー 言い過ぎですかね。
私がここで言いたいのは、OfficialとされるPETはコアチームか、信頼の置けるコミュニチイ(Communityってカタカナでうつのは難しい、以下コミュで勘弁して下さい)メンバーが、リリースされた版に対応するdevxを使用して製作。 コンパイル・オプションを明示し、ある程度のテストをへて正式パッケージとする。 それ以外はコミュ・パッケージ等と命名し、Officialとは区別する。 Officialのパッケージはある程度保証されたものだが、コミュ・パッケージはほぼ何の保証も無い。 このコミュ・パッケージはrpmやdebが元になっていてもOK. Officialには高い品質と信頼性が求められ、たとえばwindowManagerなら、そのメニューもPuppyLinux現行版に対応しておく必要がある。 現行のオフィシャル?のPETはこのような配慮が残念ながら無い。
ユーザー側が、自分が導入しようとしているパッケージがどういった物なのか知っておけば掲示板での変な質問も減るだろう。Officialパッケージが増えるという事は、日本版PuppyLinuxのユーザが拡大したという意味になる。コミュの層が厚くなり、質も向上すれば次なるステップも見えてくる。 その第一歩は信頼がおける出自のPETだと思う。
現実的に本家はそう思っていても実行しそうにないから、日本側だけでも努力してみてはどうでしょう? 一応私の考えたカテゴリーは、
い。 オフィシャル
ろ。 コミュ (投稿者がPETを管理、デバグ等の責任を持つ)
は。 テスト (ユーザからのバグ報告を真摯に聞く。ここで高評価なら(ろ)に昇進)
に。 Poop (誰が作ったのか分からない。製作者がバグに対応する事が期待できない。あやしい匂いがする。そんなPETはこのクラス)
もう一つついでに。 http://openlab.jp/puppylinux/index.html
において 動作条件が 「CPU: Pentium 166MMX, RAM: 128MB, CDROM: 20倍速以上」とあるから、パピーのベースは勿論、PETパッケージも --arch=i586 で作成。ただし、バイナリのサイズを小さくする事は、ページフォルト(page fault)を減らす事になり、処理速度が結果的に早くなる事が考えられるし、RAMを節約するためにも --arch=i386 を選択する事が一部のアプリケーションでは有効と思われる。 (これはアライメントのオプションも関係してくると思うので、この辺に精通した人に、i586 と i386の両方を作って貰い、サイズの比較と処理速度の比較を行い、総合的に判断するべき)
アプリケーション・・・これさえあれば・・・
OOを入れればオフィスはバッチリなんですが・・・少し重すぎるし、ライブ版で持ち歩くのも面倒(<ーそれくらい我慢しろという声が聞こえてきそう)。 Office系に関して、gnumericに文句を言う人はほぼ居ないだろう。 問題はabiwordとプレゼンテーション。 abiwordは軽くて良いのだが、日本語入力という点において少し問題がある。せめて入力中の文字列が書き込み箇所(もしくはその近辺)であれば使う気になるが・・・離れすぎ。いちいち入力している所を探さないといけないので、使っているとイラついてくる。(私だけですかね?)。これはAbiWordの開発チームにお願いするしかない。(オープンソースだから、このコミュから有志をつのって改善するという手もある)。
プレゼンテーションはOOのそれに匹敵する物は無いみたいだ。自分の場合はTeXでOKだけど、素人にそれは無理。 なにかWYSIWYGのアプリケーションは無いですかね?
ーー 今、書いていて思いついたんですが、OOスペシャルisoてのを発表してみては? isoの中身は、普通の日本語PuppyLinuxとOO_with_JRE.sfs で、デスクトップにOO導入用のアイコンを表示。これが実行されると、/opt 以下にJREとOOをマウント。 /opt/OpenOffice/bin を ln -s する。 又、 JAVA_HOMEを/etc/profile に追加。 ようは、明示的にOO_...sfsをマウントしない限りは普通のPuppyLinuxと一緒。OOが導入されれば、そのアイコンを追加し、その間はCD取り出しをさせない。
最後にオフィス以外で多くの人が移植を望んでいるであろう人気のアプリケーションとしてiTunesがある。現在wine上で導入しようと努力しているが、成功していない。(いろいろ検索してみたが、とても難しいようだ)
フォーラムでのバグ報告
掲示板では、いちおう4.x等のメジャー数字では区別されているが、ユーザーはマイナー数字も報告し、それがフル・インストールなのか、Frugalなのか、CD-Rom(このばあい、pfixの値も)か報告。バグが一過性の場合はその旨を報告。再現性がある場合で、再現方法が分かっているばあいはその旨を報告; この場合はバグ修正が迅速に行われる事が期待できる。 ライブラリー等の特殊なPETを導入していない事を確認。 Official以外のPETの導入の場合は、影響があるライブラリ等を確認。 -- 本当はBugzilla等を使うべきなんでしょうが、素人には煩雑だと思われる。
フォーラムのフォーマット
あまり良い例ではないかもしれませんが、以下を参照:
http://snesorama.us/board/showthread.php?t=2642
ここは息の長いフォーラムで、やっている事はさておき、フォーラムが長続きしている秘訣が凝縮しています。つまり、ボードメンバー(管理者)がしっかりしており、それぞれの持ち場をいつもチェック。一つのスレッドにおいて、その最初にsummary(「まとめ」とでも訳しますか)を置き、それを管理者がしばしば編集している。 これさえ読めば、そのスレッドを全て読む必要はない。 ここの例をPuppyLinuxのフォーラムにそのまま適用する事は出来そうもないが、非常に参考になる。 (この手のサイトは短命であるが、ここは本当に長い)。
最後に、もう一点。 現在の状況では、ここを訪れる人は少ないので、Anonymousでの投稿を許可する。 広告やくだらない質問が増えた時点で登録制にした方が良いと思います。 一応クッキーの一部、もしくはIPアドレスを表示すれば、同一人物による妨害工作は最小限に抑える事ができる。 (クッキーを削除し&新規に作り直し+IPアドレスもリセットしてまでAnonymousで投稿する人はほぼ皆無だと思いますよ。やるとすれば朝日新聞本社の一部社員くらいかな ) ーー Anonymous(匿名)での投稿を非表示のオプションを付ける。 Anonymousで投稿する人には、登録をしてからの投稿よりも回答が遅れる又は少ない旨を警告。
とりあえず以上です。
パピー本家の姿勢を考察してみる。 そして提案。
私の見る所、バリー氏とその周辺は現在の基本姿勢を大きく変更する気が無い様だ。つまり、私の目からすると、PuppyはこのままToyOSでありつづける。別にサーバとして使っても構わないかもしれないが、それはCommercialGradeではない。SingleUserModeを付ける気がない事でもそれが分かる。本家がこれだから、それ以上の物を日本語仕様で作る事は限界がある。(逆に日本語版PuppyLinuxの運用の時は、この事実を考慮する必要がある)
さらに日本語チームとのやりとりの様子から、口ではInternationalizationやLocalizationが必要でサポートするといいながら、行動が伴っていない。(多分本人に自覚が無い)。
日本語化というか i18n と l10n を本気でサポートする気があるなら、それが難しいもの(JWMのメニュー等)は、英語版は"_en"という接尾語(suffixって英語で言うんですがね、日本語では?)を付けてもらい、英語版はそれに ln -s するようにしてもらう。 それなら bash や sed/awk を駆使して、ブート時に選択した言語にl10nファイルを自動設定できる。 この手法を本家にとってもらえば、日本語版だけでなく、英語以外の全ての言語をサポートする事が楽になる。この方法のもう一つの利点は、JWMのメニューに言語切り替えを付加できる事。 シェルスクリプトで、指定した言語に ln -fs すれば良いだけ。
日本語版の開発とリリース方法
日本語版は本家版に欠陥が無いと仮定して開発を行う。本家版はかなりテストして出していると思われるから、そう仮定しても問題は無いと思われる。 また、もし重大な欠陥がリリース後に見つかれば、そのBugFixは早いと思われる。その際、欠陥版の日本語版のリリースは見合わせても問題ないと思う。(時間と労力の無駄)。
日本語化は、基本的に幾つかのPETを準備する事で行う。例えば本家4.30に導入し、そのままリマスターすれば日本語リリース版と同一の物が出来るPETの集合体を準備する。 (そうであるべきと思い、英語版4.31に ftp://www.ring.gr.jp/pub/linux/puppylin ... iginal2ja/
を導入してみたんですが、失敗しました。ちょうど手元に431 しか無かったから431で実験。これでも行けるはずと思ったんですが。scim -d で Failed to load x11 FrontEnd module でしたね。430だと動く保証があるなら一度試してみたいです)。
何故そうするかというと、日本語追加パッケージがバグの原因になっているのか、本家版にもともとバグがあったのか見極める必要があるから。 もし日本語PETsに問題がある時、デバグチームはVirtualMachine(以下VM)上で英語版を使用して報告されたバグが起こる環境まで持っていく。そこでVMをセーブ。あとは一つづつ日本語化PETを入れていき、問題が無ければ巻き戻し。 これでどのPETが問題か検討がつく。(ま、バグ報告において、どのアプリケーションが問題か、明確に分かる時はこの手法は使わなくてよいが、VMはとにかく便利)。 ーーー でも多分、日本語化のバグは、システム設定の問題に起因する事がほとんどなんでしょうね。わざわざstripしていないバイナリを持ってきてgdb走らせる必要なんて無いのかな?
もう一つついでに。日本語版CDの発表の際、本家版のsmall.isoを使用してはどうでしょう? 実際電話線のモデムを使っている人って日本では居ないのでは? 海外で日本パピー・モデム付きが必要な人は、本家版に日本語化PETを当てる。
PET パッケージについて
もう本家のほうも日本もぐちゃぐちゃ。 <ー 言い過ぎですかね。
私がここで言いたいのは、OfficialとされるPETはコアチームか、信頼の置けるコミュニチイ(Communityってカタカナでうつのは難しい、以下コミュで勘弁して下さい)メンバーが、リリースされた版に対応するdevxを使用して製作。 コンパイル・オプションを明示し、ある程度のテストをへて正式パッケージとする。 それ以外はコミュ・パッケージ等と命名し、Officialとは区別する。 Officialのパッケージはある程度保証されたものだが、コミュ・パッケージはほぼ何の保証も無い。 このコミュ・パッケージはrpmやdebが元になっていてもOK. Officialには高い品質と信頼性が求められ、たとえばwindowManagerなら、そのメニューもPuppyLinux現行版に対応しておく必要がある。 現行のオフィシャル?のPETはこのような配慮が残念ながら無い。
ユーザー側が、自分が導入しようとしているパッケージがどういった物なのか知っておけば掲示板での変な質問も減るだろう。Officialパッケージが増えるという事は、日本版PuppyLinuxのユーザが拡大したという意味になる。コミュの層が厚くなり、質も向上すれば次なるステップも見えてくる。 その第一歩は信頼がおける出自のPETだと思う。
現実的に本家はそう思っていても実行しそうにないから、日本側だけでも努力してみてはどうでしょう? 一応私の考えたカテゴリーは、
い。 オフィシャル
ろ。 コミュ (投稿者がPETを管理、デバグ等の責任を持つ)
は。 テスト (ユーザからのバグ報告を真摯に聞く。ここで高評価なら(ろ)に昇進)
に。 Poop (誰が作ったのか分からない。製作者がバグに対応する事が期待できない。あやしい匂いがする。そんなPETはこのクラス)
もう一つついでに。 http://openlab.jp/puppylinux/index.html
において 動作条件が 「CPU: Pentium 166MMX, RAM: 128MB, CDROM: 20倍速以上」とあるから、パピーのベースは勿論、PETパッケージも --arch=i586 で作成。ただし、バイナリのサイズを小さくする事は、ページフォルト(page fault)を減らす事になり、処理速度が結果的に早くなる事が考えられるし、RAMを節約するためにも --arch=i386 を選択する事が一部のアプリケーションでは有効と思われる。 (これはアライメントのオプションも関係してくると思うので、この辺に精通した人に、i586 と i386の両方を作って貰い、サイズの比較と処理速度の比較を行い、総合的に判断するべき)
アプリケーション・・・これさえあれば・・・
OOを入れればオフィスはバッチリなんですが・・・少し重すぎるし、ライブ版で持ち歩くのも面倒(<ーそれくらい我慢しろという声が聞こえてきそう)。 Office系に関して、gnumericに文句を言う人はほぼ居ないだろう。 問題はabiwordとプレゼンテーション。 abiwordは軽くて良いのだが、日本語入力という点において少し問題がある。せめて入力中の文字列が書き込み箇所(もしくはその近辺)であれば使う気になるが・・・離れすぎ。いちいち入力している所を探さないといけないので、使っているとイラついてくる。(私だけですかね?)。これはAbiWordの開発チームにお願いするしかない。(オープンソースだから、このコミュから有志をつのって改善するという手もある)。
プレゼンテーションはOOのそれに匹敵する物は無いみたいだ。自分の場合はTeXでOKだけど、素人にそれは無理。 なにかWYSIWYGのアプリケーションは無いですかね?
ーー 今、書いていて思いついたんですが、OOスペシャルisoてのを発表してみては? isoの中身は、普通の日本語PuppyLinuxとOO_with_JRE.sfs で、デスクトップにOO導入用のアイコンを表示。これが実行されると、/opt 以下にJREとOOをマウント。 /opt/OpenOffice/bin を ln -s する。 又、 JAVA_HOMEを/etc/profile に追加。 ようは、明示的にOO_...sfsをマウントしない限りは普通のPuppyLinuxと一緒。OOが導入されれば、そのアイコンを追加し、その間はCD取り出しをさせない。
最後にオフィス以外で多くの人が移植を望んでいるであろう人気のアプリケーションとしてiTunesがある。現在wine上で導入しようと努力しているが、成功していない。(いろいろ検索してみたが、とても難しいようだ)
フォーラムでのバグ報告
掲示板では、いちおう4.x等のメジャー数字では区別されているが、ユーザーはマイナー数字も報告し、それがフル・インストールなのか、Frugalなのか、CD-Rom(このばあい、pfixの値も)か報告。バグが一過性の場合はその旨を報告。再現性がある場合で、再現方法が分かっているばあいはその旨を報告; この場合はバグ修正が迅速に行われる事が期待できる。 ライブラリー等の特殊なPETを導入していない事を確認。 Official以外のPETの導入の場合は、影響があるライブラリ等を確認。 -- 本当はBugzilla等を使うべきなんでしょうが、素人には煩雑だと思われる。
フォーラムのフォーマット
あまり良い例ではないかもしれませんが、以下を参照:
http://snesorama.us/board/showthread.php?t=2642
ここは息の長いフォーラムで、やっている事はさておき、フォーラムが長続きしている秘訣が凝縮しています。つまり、ボードメンバー(管理者)がしっかりしており、それぞれの持ち場をいつもチェック。一つのスレッドにおいて、その最初にsummary(「まとめ」とでも訳しますか)を置き、それを管理者がしばしば編集している。 これさえ読めば、そのスレッドを全て読む必要はない。 ここの例をPuppyLinuxのフォーラムにそのまま適用する事は出来そうもないが、非常に参考になる。 (この手のサイトは短命であるが、ここは本当に長い)。
最後に、もう一点。 現在の状況では、ここを訪れる人は少ないので、Anonymousでの投稿を許可する。 広告やくだらない質問が増えた時点で登録制にした方が良いと思います。 一応クッキーの一部、もしくはIPアドレスを表示すれば、同一人物による妨害工作は最小限に抑える事ができる。 (クッキーを削除し&新規に作り直し+IPアドレスもリセットしてまでAnonymousで投稿する人はほぼ皆無だと思いますよ。やるとすれば朝日新聞本社の一部社員くらいかな ) ーー Anonymous(匿名)での投稿を非表示のオプションを付ける。 Anonymousで投稿する人には、登録をしてからの投稿よりも回答が遅れる又は少ない旨を警告。
とりあえず以上です。