「 SuSE Linux=?ISO-2022-JP?B?GyRCISEbKEI=?= Desktop=?ISO-2022-JP?B?GyRCIVckTkgvST0kLCQiJGokXiQ3GyhC?= たけど ...
M. Takeyama です。 「SuSE Linux Desktop」の発表がありましたけど... http://www.suse.com/us/business/products/sld/ 基本的に、SuSE 8.2 Proとどこが違うのでしょうか？ ＃SuSE XXX Desktop というのは、「 Codeweaver Crossover Office」 ＃のパッケージが追加されたようなもので、特にすごい ＃というイメージが無いのです。 ＃個別に”Codeweaver Crossover ”を買わなくとも良いので ＃お買い得感はあるのですが... 実際には、どのようにおこなうかわからないのですが、 Remote administration via SuSE YaST Online Update (YOU) ＋ Customers buying SuSE Linux Desktop receive free maintenance for 12 months as part of the SuSE Linux Maintenance Program これって、SuSE版 Redhat Networkなものですかね。 YOU自体の機能の有効さは、最近認識しましたが、スクリプトか 何かで自動化できるようになるまで使い込んでいません。 あと、”Agfa Monotype fonts”は、日本語サポートしているか／ いないかがきになるところです。 プレスリリースを読みましたが良くわかりませんでした。 http://www.suse.com/us/company/press/press_releases/archive03/sld.html ----- M. Takeyama
takezou <takezou@kde.gr.jp> さんは書きました:
あと、”Agfa Monotype fonts”は、日本語サポートしているか／ いないかがきになるところです。
このフォントは日本語サポートしません。 -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
M. Takeyama です。 On Wed, 11 Jun 2003 09:05:47 +0200 Mike FABIAN <mfabian@suse.de> wrote: [...]
あと、”Agfa Monotype fonts”は、日本語サポートしているか／ いないかがきになるところです。
このフォントは日本語サポートしません。 回答ありがとうございます。
日本語環境では、freetype 2.1.4 + opentypeのフォントなどで、 表示系と印刷系がうまくいくようしてやれば良いということかな。 ----- M. Takeyama
takezou <takezou@kde.gr.jp> さんは書きました:
On Wed, 11 Jun 2003 09:05:47 +0200 Mike FABIAN <mfabian@suse.de> wrote:
[...]
あと、”Agfa Monotype fonts”は、日本語サポートしているか／ いないかがきになるところです。
このフォントは日本語サポートしません。 回答ありがとうございます。
日本語環境では、freetype 2.1.4 + opentypeのフォントなどで、 表示系と印刷系がうまくいくようしてやれば良いということかな。
「SuSE Linux Desktop」が SLES8 に基づいていますが、KDE と Gnome と XFree86 が SuSE Linux 8.2 に含まれているバージョンまでアップデートされ ました。SLES8 は SuSE Linux 8.1 に基づいているので、「SuSE Linux Desktop」は SuSE Linux 8.1 と SuSE Linux 8.2 から混ざったシステムです。 「SuSE Linux Desktop」には日本語のサポートは少ないです。 日本語環境を使用する、普通のユーザーが、SuSE Linux 8.2を使った方がいい と思います。「SuSE Linux Desktop」にくらべると、SuSE Linux 8.2の方が 新しいです。それ以上、もっと沢山日本語に関するソフトウェアが含まれてい ます。 「SuSE Linux Desktop」の利点はサポートです。サポートが要求する大きい な会社向けの SuSE Linux バージョンです。 -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
M. Takeyama です。 On Thu, 12 Jun 2003 09:43:58 +0200 Mike FABIAN <mfabian@suse.de> wrote: [...]
「SuSE Linux Desktop」が SLES8 に基づいていますが、KDE と Gnome と XFree86 が SuSE Linux 8.2 に含まれているバージョンまでアップデートされ ました。SLES8 は SuSE Linux 8.1 に基づいているので、「SuSE Linux Desktop」は SuSE Linux 8.1 と SuSE Linux 8.2 から混ざったシステムです。 そうですか。ありがとうございます。
個人的には、現在 SuSE 8.1 Proを使っていますが、 XとSAX2は最新版にした方が良いという印象を持っています。 XFree86-4.3.0 --- ドライバーなどの自動認識率が良さそう。 (最新機種でなくともノートPCなどを使用する時はベター) SAX2 --- 最新版、確か日本語のメッセージまわりなどのバグも フィックスもされていましたね。 ＃KDE は、kde.org(本家)から公開されいるものを使っています。 ＃GNOMEは普段使っていないので良くわかりません。ごめんなさい。
「SuSE Linux Desktop」には日本語のサポートは少ないです。
日本語環境を使用する、普通のユーザーが、SuSE Linux 8.2を使った方がいい と思います。「SuSE Linux Desktop」にくらべると、SuSE Linux 8.2の方が 新しいです。それ以上、もっと沢山日本語に関するソフトウェアが含まれてい ます。 ＫＤＥまわりの日本語化は、日本人がやらない(or 日本人が協力しない)と できないので...
「SuSE Linux Desktop」の利点はサポートです。サポートが要求する大きい な会社向けの SuSE Linux バージョンです。 そうですか。 ということは、”SuSE Linux Desktop”に限っていえば、「サポート体制が ないと日本では売れない。売らない。」ことですね。
P.S. 個人的な、SuSEヘの要望として2点ばかり。 ＃良い意味で、改善して欲しいと願っています。 ・特定のアプリにおいて(例として、sambaのJP版)みたいな日本ローカライズ版 は必ず必要だと思います。 ---- 必要なら自分で作れば良いわけですけど。 ・Suse-securityチームが最初に発見したようなバグ対応は 早いけど、それ以外のモノは全体的対応が遅いと感じます。 いろいろなプラットフォーム(i386, ia64, sparc, ...)に 対応するのに時間が必要なのはわかりますが... ＃これも、sambaの例を出して申し分けないのですが、samba 2.2.8 ＃の対応はすごく速かったような気がします。 ----- M. Takeyama
takezou <takezou@kde.gr.jp> さんは書きました:
SAX2 --- 最新版、確か日本語のメッセージまわりなどのバグも フィックスもされていましたね。
バグを見つけると教えて下さい。 -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
At Thu, 12 Jun 2003 18:22:22 +0900, takezou wrote:
「SuSE Linux Desktop」には日本語のサポートは少ないです。
日本語環境を使用する、普通のユーザーが、SuSE Linux 8.2を使った方がいい と思います。「SuSE Linux Desktop」にくらべると、SuSE Linux 8.2の方が 新しいです。それ以上、もっと沢山日本語に関するソフトウェアが含まれてい ます。 ＫＤＥまわりの日本語化は、日本人がやらない(or 日本人が協力しない)と できないので...
そうですね。 YaST2 の日本語メッセージなども、おかしな表現などは、この ML などで 教えて頂ければありがたいです。 また、最新版の日本語訳に関しては、うまく organize できれば、ML 上での 開発も可能だと思います。 (…といっても、まだ妄想の段階などですけれどもね :)
「SuSE Linux Desktop」の利点はサポートです。サポートが要求する大きい な会社向けの SuSE Linux バージョンです。 そうですか。 ということは、”SuSE Linux Desktop”に限っていえば、「サポート体制が ないと日本では売れない。売らない。」ことですね。
これに関してはまだ不明なので、今のところ明言は控えますが、 「英語でのサポート」が受け入られるのならば、日本での販売自体には 問題はないでしょう。 ただし、英語でのサポートにどれほど需要があるか、は別問題です。
P.S. 個人的な、SuSEヘの要望として2点ばかり。 ＃良い意味で、改善して欲しいと願っています。
・特定のアプリにおいて(例として、sambaのJP版)みたいな日本ローカライズ版 は必ず必要だと思います。 ---- 必要なら自分で作れば良いわけですけど。
いやぁ、これが結構厄介なところで…。 SuSE としては、なるべく統一パッケージで望みたいわけでして、できれば localize 版よりは i18n モノを使いたいわけです。 パッチを当てて、一つのパッケージで済むのなら、その方が良い、という 判断です。 ところで、samba の JP版 ですが、upstream に取り込まれる可能性はあるの でしょうか？
・Suse-securityチームが最初に発見したようなバグ対応は 早いけど、それ以外のモノは全体的対応が遅いと感じます。 いろいろなプラットフォーム(i386, ia64, sparc, ...)に 対応するのに時間が必要なのはわかりますが...
確かに。 内部の人間もそう思ってます :-) -- Takashi Iwai <tiwai@suse.de> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
Takashi Iwai <tiwai@suse.de> さんは書きました:
At Thu, 12 Jun 2003 18:22:22 +0900, takezou wrote:
「SuSE Linux Desktop」には日本語のサポートは少ないです。
日本語環境を使用する、普通のユーザーが、SuSE Linux 8.2を使った方がいい と思います。「SuSE Linux Desktop」にくらべると、SuSE Linux 8.2の方が 新しいです。それ以上、もっと沢山日本語に関するソフトウェアが含まれてい ます。 ＫＤＥまわりの日本語化は、日本人がやらない(or 日本人が協力しない)と できないので...
そうですね。 YaST2 の日本語メッセージなども、おかしな表現などは、この ML などで 教えて頂ければありがたいです。
また、最新版の日本語訳に関しては、うまく organize できれば、ML 上での 開発も可能だと思います。 (…といっても、まだ妄想の段階などですけれどもね :)
これはいい提案だと思います。ML のメンバーに翻訳に興味がある方がいれば、 ML 上で翻訳できるでしょう。ML のメンバーが協力すると嬉しいです。 -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
M. Takeyama です。 On Wed, 18 Jun 2003 16:21:43 +0200 Takashi Iwai <tiwai@suse.de> wrote: [...]
P.S. 個人的な、SuSEヘの要望として2点ばかり。 ＃良い意味で、改善して欲しいと願っています。
・特定のアプリにおいて(例として、sambaのJP版)みたいな日本ローカライズ版 は必ず必要だと思います。 ---- 必要なら自分で作れば良いわけですけど。
いやぁ、これが結構厄介なところで…。 SuSE としては、なるべく統一パッケージで望みたいわけでして、できれば localize 版よりは i18n モノを使いたいわけです。 パッチを当てて、一つのパッケージで済むのなら、その方が良い、という 判断です。
ところで、samba の JP版 ですが、upstream に取り込まれる可能性はあるの でしょうか？ パッチという意味でしょうか？ それとも日本語ソースファイルのアーカイブ？ (オリジナルソース+ 日本語パッチ+日本語メッセージフ＋日本語helpなど)
sambaの日本語化のローカライズは日本sambaユーザー会が行なっています。 samba.org(本家)の開発者(or メンテナー)として、たかはし もとのぶ(高橋基信) さんがおられて日本語パッチはupstream に取り込まれているようです 日本sambaユーザ会のパッチの管理の仕方を十分把握していませんが、 現時点では、日本語版は、日本語ソースファイルからrpmを作成する のが一般的だと思います。--- 作る側は一番楽。 sambaに限定して言えばlocaleに合わせてswat(webベースの管理ツール)、 sambaのdefault設定ファイル、各種テンプレート、help, docが各国 ごとパッケージングされていているi18n-rpmみたいなものとsambaコアRPM に分かれていて、インストール時などで選択するようになっていない限り 統一版のi18nモノは難しいと思います。 ＃当面は、localize 版も平行して存在する必要があると思います。 samba３では、HEX, CAPの機能が取り込まれなかったので、別途日本語 パッチを準備することが必要になったようです。 ＃(sambaのことを細かく追っかけていないので、多少、思い込みがあるかも)
・Suse-securityチームが最初に発見したようなバグ対応は 早いけど、それ以外のモノは全体的対応が遅いと感じます。 いろいろなプラットフォーム(i386, ia64, sparc, ...)に 対応するのに時間が必要なのはわかりますが...
確かに。 内部の人間もそう思ってます :-) そうですか。 それでは、良い意味でもforkしたパッケージがあった方が良いかも。
----- M. Takeyama
At Thu, 19 Jun 2003 20:24:37 +0900, takezou wrote:
M. Takeyama です。
On Wed, 18 Jun 2003 16:21:43 +0200 Takashi Iwai <tiwai@suse.de> wrote:
[...]
P.S. 個人的な、SuSEヘの要望として2点ばかり。 ＃良い意味で、改善して欲しいと願っています。
・特定のアプリにおいて(例として、sambaのJP版)みたいな日本ローカライズ版 は必ず必要だと思います。 ---- 必要なら自分で作れば良いわけですけど。
いやぁ、これが結構厄介なところで…。 SuSE としては、なるべく統一パッケージで望みたいわけでして、できれば localize 版よりは i18n モノを使いたいわけです。 パッチを当てて、一つのパッケージで済むのなら、その方が良い、という 判断です。
ところで、samba の JP版 ですが、upstream に取り込まれる可能性はあるの でしょうか？ パッチという意味でしょうか？ それとも日本語ソースファイルのアーカイブ？ (オリジナルソース+ 日本語パッチ+日本語メッセージフ＋日本語helpなど)
パッチの方です。 もちろん、日本語リソースも取り込み可能ならば upstream に入っていると ありがたいのですが、そうはいかない場合が多いですしね。
sambaの日本語化のローカライズは日本sambaユーザー会が行なっています。 samba.org(本家)の開発者(or メンテナー)として、たかはし もとのぶ(高橋基信) さんがおられて日本語パッチはupstream に取り込まれているようです
なるほど。
日本sambaユーザ会のパッチの管理の仕方を十分把握していませんが、 現時点では、日本語版は、日本語ソースファイルからrpmを作成する のが一般的だと思います。--- 作る側は一番楽。
sambaに限定して言えばlocaleに合わせてswat(webベースの管理ツール)、 sambaのdefault設定ファイル、各種テンプレート、help, docが各国 ごとパッケージングされていているi18n-rpmみたいなものとsambaコアRPM に分かれていて、インストール時などで選択するようになっていない限り 統一版のi18nモノは難しいと思います。 ＃当面は、localize 版も平行して存在する必要があると思います。
了解しました。 要は、core-package + sub-package(s) の形でないと、インストーラでの扱い がすごく面倒になるので、samba の様な主要パッケージでは、パッケージをダ ブらせるのは、特に嫌がられるのです。 ということで、samba 関連の同僚に聞いてみます。 あまり期待しないで待っていてください :-)
samba３では、HEX, CAPの機能が取り込まれなかったので、別途日本語 パッチを準備することが必要になったようです。
バージョンアップの際には、いつも注意が必要ですね。
・Suse-securityチームが最初に発見したようなバグ対応は 早いけど、それ以外のモノは全体的対応が遅いと感じます。 いろいろなプラットフォーム(i386, ia64, sparc, ...)に 対応するのに時間が必要なのはわかりますが...
確かに。 内部の人間もそう思ってます :-) そうですか。 それでは、良い意味でもforkしたパッケージがあった方が良いかも。
いや、fork すると対応する数が増えるので、逆に時間が倍になるだけの ような…。 -- Takashi Iwai <tiwai@suse.de> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
M. Takeyama です。 ＃思い込みとがあって間違っていたらごめんなさい。 On Fri, 20 Jun 2003 20:29:00 +0200 Takashi Iwai <tiwai@suse.de> wrote: [...]
sambaの日本語化のローカライズは日本sambaユーザー会が行なっています。 samba.org(本家)の開発者(or メンテナー)として、たかはし もとのぶ(高橋基信) さんがおられて日本語パッチはupstream に取り込まれているようです
なるほど。 現時点は、日本におけるsambaの情報は、日本sambaユーザー会に集約 (情報、開発者など)されていると言って良いと思います。 ＃仕事(本業)で、sambaを使う機会があり、調べ物をする場合は、 ＃ http://www.samba.gr.jp/ を利用しています。
日本sambaユーザ会のパッチの管理の仕方を十分把握していませんが、 現時点では、日本語版は、日本語ソースファイルからrpmを作成する のが一般的だと思います。--- 作る側は一番楽。
sambaに限定して言えばlocaleに合わせてswat(webベースの管理ツール)、 sambaのdefault設定ファイル、各種テンプレート、help, docが各国 ごとパッケージングされていているi18n-rpmみたいなものとsambaコアRPM に分かれていて、インストール時などで選択するようになっていない限り 統一版のi18nモノは難しいと思います。 ＃当面は、localize 版も平行して存在する必要があると思います。
了解しました。
要は、core-package + sub-package(s) の形でないと、インストーラでの扱い がすごく面倒になるので、samba の様な主要パッケージでは、パッケージをダ ブらせるのは、特に嫌がられるのです。
ということで、samba 関連の同僚に聞いてみます。 あまり期待しないで待っていてください :-)
私の書き方だと、誤解を招きそうなのでここでも補足しておきます。 ＃元々の本題からかなり外れた話題になっているかもしれませんが。 ＫＤＥを例にしますが、ＫＤＥの場合インストール後、最初に起動した 時に kpersonalizerが起動されて各種の起動パラメータの設定します。 ＃インストールだけでは、必ずしも日本語環境に合わせることができないが、 ＃簡単に各localeの環境が設定できるところが良いと思います。 sambaの場合、i18nという意味では、結構完成度は高いと思いますが 「イントール直後に日本語環境に合わせて問題がなく起動できるか？」 というとそうではないと思います。swatなり、設定ファイルを 編集する必要があると思います。 ＃(あくまで一般論、SuSEのパッケージは検証したことありません) 本来、sambaプロジェクトがパッケージングなどのことも考えて開発して くれたらとも思います。 もう１工夫は欲しい。 ----- M. Takeyama
岩井です。 ちょっと前のポストで At Mon, 23 Jun 2003 19:08:29 +0900, takezou wrote:
On Fri, 20 Jun 2003 20:29:00 +0200 Takashi Iwai <tiwai@suse.de> wrote:
ということで、samba 関連の同僚に聞いてみます。 あまり期待しないで待っていてください :-)
と書きましたが、結局、 「samba-jp 2.x は、取り込むのが大変なのでパス」 ということになりそうです。 trivial なパッチまたは l10n リソースだけなら喜んで採り入れるけど、 tarball を見てみると他の変更がかなりあるので、samba の様なクリティカル な物にはちょっと、ね、ということになりました。 次のリリース (9.0 になるらしいです) の際には、samba 3.x がオプションと して使える(かもしれない)ので、i18n および l10n に関してはこっちの方に 期待した方が良いだろう、と。
私の書き方だと、誤解を招きそうなのでここでも補足しておきます。 ＃元々の本題からかなり外れた話題になっているかもしれませんが。
ＫＤＥを例にしますが、ＫＤＥの場合インストール後、最初に起動した 時に kpersonalizerが起動されて各種の起動パラメータの設定します。 ＃インストールだけでは、必ずしも日本語環境に合わせることができないが、 ＃簡単に各localeの環境が設定できるところが良いと思います。
sambaの場合、i18nという意味では、結構完成度は高いと思いますが 「イントール直後に日本語環境に合わせて問題がなく起動できるか？」 というとそうではないと思います。swatなり、設定ファイルを 編集する必要があると思います。 ＃(あくまで一般論、SuSEのパッケージは検証したことありません)
本来、sambaプロジェクトがパッケージングなどのことも考えて開発して くれたらとも思います。 もう１工夫は欲しい。
samba 3.x だと UTF-8 対応(らしい)ので、パッケージングも楽になるんじゃ ないかと期待してます。 -- Takashi Iwai <tiwai@suse.de> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
M. Takeyama です。 On Fri, 18 Jul 2003 16:41:25 +0200 Takashi Iwai <tiwai@suse.de> wrote:
岩井です。
[...]
「samba-jp 2.x は、取り込むのが大変なのでパス」
ということになりそうです。 回答、ありがとうございます。 了解しました。
trivial なパッチまたは l10n リソースだけなら喜んで採り入れるけど、 tarball を見てみると他の変更がかなりあるので、samba の様なクリティカル な物にはちょっと、ね、ということになりました。
次のリリース (9.0 になるらしいです) の際には、samba 3.x がオプションと して使える(かもしれない)ので、i18n および l10n に関してはこっちの方に 期待した方が良いだろう、と。 samba-jpのソースリリースには、疑問をもっている一人なので samba-jpの人に, ここらあたりの話をしてみます。 => SuSEの正式パッケージャーは、samba-jp 2.0.xのリリースをあきらめた。 ＃samba-jpのソースパッケージは、パッケジャー泣かせ。 ＃日本人のことしか考えていない。
[...]
私の書き方だと、誤解を招きそうなのでここでも補足しておきます。 ＃元々の本題からかなり外れた話題になっているかもしれませんが。
ＫＤＥを例にしますが、ＫＤＥの場合インストール後、最初に起動した 時に kpersonalizerが起動されて各種の起動パラメータの設定します。 ＃インストールだけでは、必ずしも日本語環境に合わせることができないが、 ＃簡単に各localeの環境が設定できるところが良いと思います。
sambaの場合、i18nという意味では、結構完成度は高いと思いますが 「イントール直後に日本語環境に合わせて問題がなく起動できるか？」 というとそうではないと思います。swatなり、設定ファイルを 編集する必要があると思います。 ＃(あくまで一般論、SuSEのパッケージは検証したことありません)
本来、sambaプロジェクトがパッケージングなどのことも考えて開発して くれたらとも思います。 もう１工夫は欲しい。
samba 3.x だと UTF-8 対応(らしい)ので、パッケージングも楽になるんじゃ ないかと期待してます。 WebDAV(元情報は、yosshy@debian.or.jp さん)の情報をKdeveloper@kde.gr.jp で読みましたが、Samba や WebDAVの(日本語パッチ)がglibcのCVSに取り込まれ たみたいなので、次のglibc-2.3.3以降とのセットだと期待できるのでは ないかと思っています。
----- M. Takeyama
M. Takeyama です。 On Fri, 20 Jun 2003 20:29:00 +0200 Takashi Iwai <tiwai@suse.de> wrote: [...]
・Suse-securityチームが最初に発見したようなバグ対応は 早いけど、それ以外のモノは全体的対応が遅いと感じます。 いろいろなプラットフォーム(i386, ia64, sparc, ...)に 対応するのに時間が必要なのはわかりますが...
確かに。 内部の人間もそう思ってます :-) そうですか。 それでは、良い意味でもforkしたパッケージがあった方が良いかも。
いや、fork すると対応する数が増えるので、逆に時間が倍になるだけの ような…。 すみません。私にコメントが曖昧でした。
SuSEの内部の人さえ、対応に時間がかかっていて問題であるという意識が あるならば、コミニュティ側がforkしたパッケージがあっても良いのでは ないかという考えです。 ＃SuSE自体でforkしたパッケ―ジを作ってくださいという意味ではありません。 ＃(純粋にsecurityパッチ関係での話です。glibc(RPC)の対応は遅かったですから) [使い方として] 多少問題があっても、早く出るコミニュティ側パッケージ。 ---> 自己責任で使う。(当面のセキュリティホールは防げるでしょう) ＃ディトリビューション(SuSE)から正式パッケージが出たら入れ替え ＃ても良いわけですし。 少し待っても安心感を要求するならディトリビューション(SuSE)から のパッケージを使う。 というようなイメージです。 ----- M. Takeyama
At Mon, 23 Jun 2003 19:08:30 +0900, takezou wrote:
M. Takeyama です。
On Fri, 20 Jun 2003 20:29:00 +0200 Takashi Iwai <tiwai@suse.de> wrote:
[...]
・Suse-securityチームが最初に発見したようなバグ対応は 早いけど、それ以外のモノは全体的対応が遅いと感じます。 いろいろなプラットフォーム(i386, ia64, sparc, ...)に 対応するのに時間が必要なのはわかりますが...
確かに。 内部の人間もそう思ってます :-) そうですか。 それでは、良い意味でもforkしたパッケージがあった方が良いかも。
いや、fork すると対応する数が増えるので、逆に時間が倍になるだけの ような…。 すみません。私にコメントが曖昧でした。
SuSEの内部の人さえ、対応に時間がかかっていて問題であるという意識が あるならば、コミニュティ側がforkしたパッケージがあっても良いのでは ないかという考えです。 ＃SuSE自体でforkしたパッケ―ジを作ってくださいという意味ではありません。 ＃(純粋にsecurityパッチ関係での話です。glibc(RPC)の対応は遅かったですから)
ああ、了解しました。
[使い方として] 多少問題があっても、早く出るコミニュティ側パッケージ。 ---> 自己責任で使う。(当面のセキュリティホールは防げるでしょう) ＃ディトリビューション(SuSE)から正式パッケージが出たら入れ替え ＃ても良いわけですし。
少し待っても安心感を要求するならディトリビューション(SuSE)から のパッケージを使う。
というようなイメージです。
同感です。 おそらくディストリビュータの側にしても、各自がパッケージングする事自体 は、賛成するのではないかと思います。 外から contribute されたパッケージを SuSE でビルドする、という手法もあ るのですが、結局管理する手間はあまり変わらないので、結局いつもボツになっ ているようです。 理論的には、ftp 上で anonymous 書き込み可能な incoming ディレクトリを 作って、後は自動的に build というのも可能なのですが。ま、セキュリティ 云々もありますしね。 -- Takashi Iwai <tiwai@suse.de> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
participants (3)
-
Mike FABIAN -
Takashi Iwai -
takezou