3

Linux をサポートするソフトウェアをいくつかリリースしようとしています。

Mac と Windows に関しては、サポートするバージョンの数はかなり限られています (xp、2000、vista、win の場合は 7、Mac の場合は 10.4-6)。しかし、Linux の場合は別の話です。

できるだけ多くの Linux をサポートしたいと考えていますが、その選択肢は膨大です。

質問は次のとおりです。

  • できるだけ多くの Linux をサポートするには、どの配布形式 (バイナリ) を使用すればよいですか?
  • テストのために、どの「ベース Linux」でテストし、結果を他の Linux に拡張できますか。
  • 静的にリンクされたバイナリをすべての依存関係とともに提供するとしたら、何を確認する必要がありますか? カーネルのバージョンと libc のバージョンを想定していますが、疑問に思っています。

私たちのソフトウェアは、BSD と POSIX (gettimeofday、pthreads) を少し使って ANSI 準拠の C で書かれています。

4

5 に答える 5

3

では、Mac と Windows でそれぞれ 3 つのバージョンがあるのは普通だと思いますが、Linux は敬遠されますか? うーん。

configure標準のツール チェーンを使用してビルドできることを確認してmakeくださいmake install。残りは自分で処理する必要があります。

それ以外の場合は、快適なものを選択してください。私にとっては Debian/Ubuntu ですが、他の人は Fedora を好みます。他の標準については、Linux Standards Base や FreeDesktop.org などを参照してください。カーネルと libc は、ハードウェアまたはドライバー固有の何かを実行している場合を除き、重要ではありません。

于 2009-12-14T04:16:33.667 に答える
0

カーネルは、下位互換性のあるバイナリ API を維持するよう努めています。1.0 シリーズのカーネルに対してビルドされた静的にリンクされたバイナリは、最新の 2.6 シリーズのカーネルで今日まで問題なく動作するはずです。

すべて (libc を含む) と静的にリンクしている場合、直面する可能性が高い主な問題はファイルシステムの配置の違いであり、これは大きな問題ではないかもしれません。（しかし、テストは見つける唯一の方法です）。

于 2009-12-14T04:17:02.537 に答える
0

アイデアは、提案された顧客ベースを調査して、彼らが実行している Linux バージョンを確認し、フィードバックから短いリストを作成することです。しかし、私が知っていることから（これは主観的です！）...

rpm と .tar.gz という 2 つの異なるディストリビューション タイプを実行することをお勧めします。rpm を使用すると、最新の Fedora/openSUSE/RHEL/SLES (および企業市場のかなりの部分を占める派生ディストリビューション) に対応できます。あなたはすでに静的リンクによって多くの依存関係の問題を処理しているため、カーネルのバージョンは十分なはずです。

.tar.gz ディストリビューションを使用すると、「その他すべて」に対応できますが、サポートと構成の問題がすぐに時間の浪費になるので注意してください。

テストのために、サポートすることを選択した各バージョンの仮想マシンを用意します。これらは製品サポートにも使用できます (製品サポートを提供する必要があると思いますか??) 隠れた「落とし穴」が多すぎるため、Linux バージョン間で結果を推定しようとはしません。

于 2009-12-14T04:37:07.283 に答える
0

glibc のカーネルとバージョンに対して、静的にコンパイルされた Linux バイナリをリリースできます。互換性を壊すリビジョンについてのみ心配する必要があります。時間があれば、同じホストでクロスコンパイルするようにすべてをセットアップできます。カーネルは下位互換性があります。glibc はより気まぐれです。

インストーラーでパッケージ化する場合、ファイル パスは Linux Standard Base であると見なすことができます。ここで柔軟に対応できるほど、より良い結果が得られます。提供することをお勧めするバイナリの tarball を受け取ったことについて顧客が不満を言うのを聞いたことがありません。私は顧客から間違った仮定について苦情を言われたことがあります。

正式なパッケージ形式の最善の策は、おそらく DEB (Debian Linux & 派生物、Ubuntu など) と RPM (Red-Hat & 派生物、Cent-OS など) の間です。パッケージはあると便利ですが、ネイティブの更新マネージャーを利用する予定がない場合は頭痛の種です。

テスト＆ビルドに関しては、個人的にはGentooをお勧めします。ただし、それはかなり未加工であるため、Ubuntu を遠く離れた 2 番目の選択肢として検討することをお勧めします。

于 2009-12-14T04:42:30.553 に答える
0

これは、製品管理チームの問題です。Linux バージョンを作成することが (つまり、費用対効果に基づいて) 望ましいアイデアであると彼らが判断したら、顧客が使用している、またはサポートを望んでいるディストリビューションを見つける必要があります。

原則として、どれでもサポートできますが、サポートすればするほど頭痛の種になるため、できるだけ少なくする必要があります。

  • PM が解決できると考える数の OS とアーキテクチャの組み合わせをサポートする
  • OS / アーキテクチャをできるだけ早く非推奨にする
  • PM の決定に従って、プレミアム サポートの顧客が要求する場合、または大きな取引を得る場合にのみ、新しいものを引き受けます。

それらをサポートするのがどれほど難しいかは、製品の複雑さ (特に依存関係) とその自動テスト スイートの完成度に大きく依存します。サポートされている OS を追加すると、ライブラリの使用、カーネル機能の使用など、およびテストに関して手を結ぶことになるため、長期的に苦労することは望ましくありません。

要するに、これはソフトウェア エンジニアリングの問題ではなく、製品管理の問題です。

于 2009-12-14T21:25:28.553 に答える