3

我们即将发布几个支持 Linux 的软件。

对于 Mac 和 Windows，支持的版本数量非常有限（xp、2000、vista，win 7，Mac 10.4-6）。但是对于 linux 来说就是另外一回事了。

我们希望支持尽可能多的 Linux，但选择范围很大。

问题是：

  • 使用哪种分发格式（二进制文件）来支持尽可能多的 Linux？
  • 对于测试，我们可以测试什么“基础 linux”并将我们的结果扩展到其他 linux。
  • 根据我们提供具有所有依赖项的静态链接二进制文件，我们需要检查什么？我假设内核版本和 libc 版本，但我想知道。

我们的软件是用符合 ANSI 的 C 语言编写的，带有一点 BSD 和 POSIX（gettimeofday，pthreads）。

4

5 回答 5

3

所以你认为 Mac 和 Windows 各三个版本是正常的，但你回避 Linux？嗯。

只需确保它使用标准工具链构建 -和configure传统上。其余的应该照顾好自己。makemake 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。使用 rpm，您可以满足最新的 Fedora/openSUSE/RHEL/SLES（以及派生发行版，这是企业市场的相当一部分）。你已经通过静态链接处理了很多依赖问题，所以内核版本应该足够了。

使用 .tar.gz 发行版，您可以满足“所有其他人”的需求，但要注意支持和配置问题，因为它们很快就会成为时间消耗。

为了进行测试，请拥有您选择支持的每个版本的虚拟机。这些也可用于产品支持（我假设您需要提供产品支持？？）我不会尝试在 linux 版本之间推断结果，因为隐藏的“陷阱”太多。

于 2009-12-14T04:37:07.283 回答
0

您可以针对 glibc 的内核和版本发布静态编译的 Linux 二进制文件。你真的只需要担心破坏兼容性的修订。如果您有时间，您可以将所有内容设置为在同一主机上进行交叉编译。内核向后兼容。glibc 比较有气质。

如果要使用安装程序打包文件路径，可以假定为 Linux Standard Base。你在这里越灵活越好。我从来没有听过客户抱怨收到二进制文件的压缩包，我建议提供。我有客户抱怨不正确的假设。

对于正式的包格式，最好的选择可能是在 DEB（Debian Linux 和衍生产品，如 Ubuntu）和 RPM（Red-Hat 和衍生产品，如 Cent-OS）之间。拥有软件包固然好，但如果您不打算使用本机更新管理器，这只是一个令人头疼的问题。

对于测试和构建，我个人推荐 Gentoo。但是，它非常原始，因此您可能希望将 Ubuntu 视为遥不可及的第二选择。

于 2009-12-14T04:42:30.553 回答
0

这是您的产品管理团队的问题。一旦他们确定生产 Linux 版本是一个理想的想法（即在成本效益的基础上），那么您将需要找出您的客户使用或想要支持的发行版。

原则上你可以支持任何一个，但你支持的越多，它就越令人头疼，所以你想要尽可能少。

  • 支持尽可能少的操作系统/架构组合，就像你的 PM 认为你可以摆脱的那样
  • 尽快弃用操作系统/架构
  • 仅在高级支持客户要求或获得大笔交易时才采用新的，根据您的 PM 的决定。

支持它们的难度在很大程度上取决于您的产品的复杂程度（尤其是依赖项）以及其自动测试套件的完整程度。添加更多受支持的操作系统会在库使用、内核功能使用等以及测试方面束缚您的手，因此您不希望长期陷入困境。

所以简而言之，这不是软件工程问题，而是产品管理问题。

于 2009-12-14T21:25:28.553 回答