使用Red Hat安装程序的发现

在我开始在威斯康星大学麦迪逊分校研究生院学习之前，我从未听说过开源。 但是，任何年龄和身材的计算机科学部门都使用开源软件来支持其基础架构。 部门系统管理员总是将Linux的一个或另一个变体安装在我们的桌面上，并且许多学术程序都是开源的。 当我发现它时，我或多或少地接受了整个情况。

在开源文章中查看有关Women的完整文章集

当我加入协作错误隔离（ CBI ）项目时，开放源代码对我而言变得更加重要。 该项目使用开源软件作为自动查找错误的测试对象。 我的项目主管Ben Liblit教授撰写了一篇简短的论文， 《开源试验场》 ，描述了他的经验，并评估了开源软件对像他这样的漏洞发现项目的适用性。 尽管该论文于2005年发表，但他的许多观察仍然与今天相关。

一旦我开始考虑开源软件，尤其是当我开始研究某些单独的应用程序时，我很沮丧地发现其中一些软件编写得很差，因此到处都是bug。 天真的，我以为任何人都会选择发行的任何软件都至少要像我自己，只是一名研究生，写的软件一样精心制作。 然后，就像现在一样，人们会使用软件，只要它能很好地满足他们的目的，而不管代码是什么样子，即使代码公开给所有人看。

后来，我在Chromium项目中扩展了一些宏，以收集CBI类型的数据。 这些扩展绝不打算以任何永久方式并入项目。 您今天肯定不会在这里找到它们。 Chromium项目是一个纪律严明的项目，即使我编写的代码永远不会成为项目的一部分，我的补丁也必须符合全面详细的规范，并在接受之前进行了全面的审查。

我的个人计算机是Mac，但是众所周知，那只是Unix的底层，所以我下载，安装并经常使用许多开源应用程序。 我已经看到一些应用程序，例如LyX，已经成熟。 随着我对LyX的了解，我的个人评价已经从“无用”演变为“迄今为止最好的选择”。 我仍然想了解像LyX这样的雄心勃勃的开源项目如何在其脆弱的早期阶段持续下去。

到我离开CBI项目时，我已经与各种开源项目进行了某种形式的交互，其中一些显然来自混乱，而另一些则来自非常严格的开发过程，有些令人印象深刻，而另一些则没有。 毕业后，我担任了一系列教学职务，并退而求其次。 我很感激该软件在那里，经常使用它，贡献了奇怪的错误报告，对它的考虑很少。 有时候，我认为我应该更多地了解这种开源现象以及它如何自我维持，但是我总是太忙了。

当我决定离开学术界并进入行业时，我的机会就来了。 我以前没有在工业界编程，但是我已经为CBI项目使用多种语言和多种用途完成了广泛的开发工作。 直到去年夏天我加入Yocto项目之前，我对一个可能在地理位置上分散的团队中的开源开发或交流机制一无所知。 我了解了每个人不可避免地收到的大量电子邮件，以及IRC的实用性。 正是通过这种实习，我才开始熟悉git。

自从我于2013年9月加入Red Hat以来，我一直在学习有关开发周期及其要求的更多信息，尽管由于时间不长，所以我还没有经历一个完整的周期。 自从成为开源贡献者以来，我开始将开源本身视为一种优点，并且越来越有可能寻找各种应用程序的开源替代方案。 我也更有可能在bug食物链中发布更高一些的bug报告-例如，在Python标准库中，而不是在某些用Python编写的应用程序中。 与以前相比，我将更多的问题视为开源协作的机会。 我从来没有梦想过开源会如此成功，只希望开源的成功会增长。

在Red Hat，我几乎所有的时间都花在安装程序上，主要专注于其存储组件blivet。 安装程序Anaconda保证，在您做出所有选择并按红色的大按钮之前，它实际上不会对磁盘​​做任何操作。 此时，它应该实现您的所有选择而不会崩溃。 这是一个很难解决的问题，因为Anaconda依赖的各种工具可能会执行哪些令人惊讶的限制，并且您做出的不同选择之间存在令人惊讶的交互作用。 在为用户提供最大的灵活性与同时确保他们可以进行选择之间始终存在压力。

存储组件Blivet负责处理设备和设备格式化。 它必须为各种不同的文件系统，各种不同的设备以及各种不同的体系结构提供统一的接口。 这就像设备驱动程序问题，其中各个设备可能有很大的不同，但是驱动程序必须都具有相同的应用程序编程接口（API）。 例如，文件系统可能彼此非常不同，因为文件系统设计人员在设计其文件系统时，根本就不会想到安装程序的问题。 而且，大多数文件系统不提供API。 blivet必须为每个文件系统的命令行界面（CLI）生成必要的命令，而命令行界面可以是移动目标。

尽管Anaconda本身是一个重要的应用程序，而blivet是一个重要的库，但就其本质而言，它们必须依赖其他重要的应用程序（例如，软件包安装程序和文件系统实用程序）来协调这些各种应用程序的操作并询问它们以发现相关的内容。系统状态。 通常，使这些交互变得更加脆弱，因为必须通过其CLI调用应用程序，并且必须通过读取和解析输出来询问该应用程序，该输出的格式可能在下一次更新时更改。

像Anaconda这样的安装程序无疑是必须依赖其他应用程序的极端示例。 但是，自动化是今天的规范，而不是例外，许多应用程序，尤其是Anaconda和blivet所依赖的那种应用程序，可能希望自动调用的次数与人类调用的次数一样多。 它们越成功，情况就越可能发生。

我相信，如果更多的开放源代码开发人员将API和关联的绑定视为主要资源，而将CLI作为第二重要资源，则整个开源社区都将从中受益。 理想情况下，应从一开始就使用定义明确的API，随该API演变而来的一组绑定以及使用该绑定的脚本语言定义的CLI（如果需要）来设计应用程序。 这不仅会使应用程序变得自动化成熟，而且还可能具有使API更好定义和更健壮的额外好处。

---

在“开源周”文章中查看完整的“女性”系列。

翻译自: https://opensource.com/business/14/2/observations-red-hat-software-engineer