赋能 Linux 开发者,迎接创新浪潮

作者:Evan Dandrea

每天都有以软件为核心的新企业创立。开发者是正在构建的众多事物和技术创新的生命线,他们对于整个业务运营也变得越来越重要。那么,我们为什么不赋能他们呢?

特别是机器学习和物联网为开发者提供了巨大的机会,尤其是那些面临其他平台拥挤市场的开发者,可以与庞大且未开发的受众互动。

Linux 的开源特性使其成为创新的绝佳温床。开发者不受封闭生态系统的约束,这意味着长期以来,Linux 一直是开发者的首选操作系统。因此,通过与 Linux 互动,企业可以吸引最优秀的开发者技能。

Linux 生态系统一直以来都致力于追求高品质。历史上,Linux 社区独自承担软件包的打包责任,对每个应用程序更新进行仔细审查,以确保其在 Linux 的每个发行版上都能按广告宣传的那样工作。事实证明,这对各方来说都很困难。

需要广泛访问代码,并且可以通过应用商店提供开源软件。用户支持请求和错误通过 Linux 发行版进行渠道化处理,并且报告量如此之大,以至于很难将信息反馈给合适的软件作者。

随着应用程序和 Linux 发行版数量的增长,越来越明显的是,这种模式无法进一步扩展。软件作者开始自行处理,通常选择支持单个 Linux 发行版,并完全跳过应用商店。因此,他们失去了应用程序的可发现性,并增加了运行重复基础设施的复杂性。

这在开发者角色期望已经不断扩大的时候,增加了他们的责任。他们不再仅仅是制造者,他们现在承担着因代码导致机械臂损坏或因补丁导致 MRI 机器瘫痪的风险。

作为一个行业,我们承认这个问题——您可能会遇到糟糕的更新,而且软件并非精密科学——但我们随后要求这些开发者掷骰子。您是冒着妥协或自残的风险吗?

与此同时,表面积也在增加。该行业继续稳步推进自动化,创建越来越多的软件组件来连接在一起,并在其上分层解决方案。开发者不仅面临自己代码的更新问题,他们还必须信任所有开发者在他们自己代码之下的所有代码中面临的相同决定。

开发者可以通过将代码视为不可变的来换取软件的演进和增长,从而获得安全感。代码交付后永远不会更新,只会完全替换。许多设备制造商都采用了这种方法,他们认为最终用户因设备恢复而堵塞其支持线路的风险远大于面临安全漏洞的深夜电话。

过去一年已经向许多人证明,虽然软件更新对于最终用户来说并没有变得更容易管理,但安全漏洞的频率和影响使得这个过程不可避免地成为必要。将任何连接互联网的软件视为成品已不再可行。软件维护必须延伸到硬件产品的生命周期。

在没有强制更新的模式下,这可能意味着维护补丁集,并将大量支持成本投入到长期支持的版本中。

那么,在这些压力下,开发者如何才能以可预测的成本兑现其软件的承诺呢?答案可能在于 snaps。

Snapcraft 是一个将应用程序发布给数百万 Linux 用户的平台。它使作者能够推送自动安装的软件更新,并在发生故障时回滚。错误更新导致设备变砖或降低最终用户体验的可能性大大降低。如果应用程序使用的库中发现安全漏洞,应用程序发布者会收到通知,以便可以使用提供的修复程序快速重建应用程序并推送出去。

由于应用程序包 snaps 捆绑了它们的运行时依赖项,因此它们无需修改即可在所有主要的 Linux 发行版上工作。它们是防篡改和受限的。一个 snap 无法修改任何其他应用程序,也无法被任何其他应用程序修改,并且对系统超出其限制的任何访问都经过明确授权。这种精确性为安装和管理应用程序带来了更简单的文档。加上自动更新消除了长期支持的版本,更可预测和更低的支持成本是典型的。QA 部门测试的内容与应用程序在众多最终用户系统配置上的行为方式之间的差异极小。

Snapcraft 提供了强大的工具,可以将您的版本组织成不同的质量等级(通道)。一套工具可用于将应用程序更新从自动 CI 构建推送到 QA、beta 测试人员,最后推送到所有用户。它可以可视化您的更新在这些通道中的流动,并帮助您跟踪用户群增长和保留率。

在人工智能和物联网正在 spurring 新一轮创新之际,简单而强大的工具让企业中最关键的创新者——开发者——有信心发布世界上一些最常用的软件。

Evan Dandrea 是 Canonical 的工程经理。

加载 Disqus 评论