在 Stack Overflow Jobs 上，你可以创建你自己的 开发者故事 （ Developer Story ） 来展示你的成就，表现你的职业生涯进步。在创建开发者故事时，你可以对你使用的技术/编程语言添加喜欢或不喜欢的标签，如下图：

这就给了我们一个机会可以观察到这数十万开发者的喜好和厌恶。有许多方法可以评估一个语言的流行程度，举个栗子说，我们经常使用 Stack Overflow 访问数或问题查看数来评估这样的趋势。但是，当技术人员在他们的简历中表达他们不喜欢某种技术时，这个数据集就是一个找出技术人群不喜欢某种技术的独有方式。

（我两年前曾经在我的个人博客上发表过一些这类分析，不过这篇文章使用了更新的数据集，以及有更多可视化结果和说明。）

编程语言

作为测量每个编程语言有多流行的指标，我们将看看它出现在某人“不喜欢”标签的时间与其出现在其他人的“喜欢”或“不喜欢”标签的频率相比。那么 50% 就意味着该语言喜欢与不喜欢各占一半，而 1% 则意味着 99 个人喜欢它而剩下 1 个人不喜欢它。（我们使用了这篇文章中描述的 经验贝叶斯 （ empirical Bayes ） 方法来计算平均值，并使用这个方法来计算得到 95% 置信区间）

让我们开始看看选出的语言列表（而不是像 Android 这样的平台或像 jQuery 这样的库），所有这些都曾在开发者故事中至少提及了 2000 次以上。

最不喜欢的语言是 Perl、Delphi 和 VBA ，它们远远把其它语言抛下。接着的第二梯队是 PHP、Objective-C、 Coffeescript 和 Ruby。我们的团队很高兴地看到，R 语言相对于喜欢它的人数来说，对它不喜欢的人数是最少的。

如果你读过我们另外一些关于编程语言增长或萎缩的文章，你也许会注意到那些较少被不喜欢的语言往往是增长较快的。 在 Stack Overflow 上，R、Python、Typescript、Go 和 Rust 全是快速增长的编程语言（我们之前专门对 Python 和 R 做过分析），而且它们全都属于看法比较 分化 （ polarizing ） 的语言。类似的，大量萎缩的语言，比如 Perl、Objective-C 和 Ruby，如我们之前观察到的那样，在我们网站上它处于快速萎缩状况。

我们可以通过将每种语言的规模和增长与不喜欢它的人的百分比进行比较来进行调查，橙色点代表最不喜欢的语言。 为了使我们的分析与前几个帖子保持一致，我们将统计数据限制在高收入国家（如美国，英国，德国和加拿大）。

一般来说，编程语言的增长率和它有多不招人喜欢方面存在相关性。几乎每个在开发者故事中提及不喜欢的比率超过 3% 的语言都在 Stack Overflow 流量上处于萎缩状态（除了十分两极化的 VBA，它仍有轻度增长）。而不喜欢数量较少的语言，如 R、Rust、 Typescript 和 Kotlin，它们全处于快速增长领域（Typescript 和 Kotlin 增长的太快，以至于都跑出了上图范围）。

一个突出的编程语言是函数式编程语言 Clojure；几乎没有人表示过不喜欢它，但是它仍然处于快速萎缩中（根据问题查看情况，它在去年才开始萎缩）。另外一个例外是 MATLAB，它处于快速萎缩，但是没有很多人表示过不喜欢它。这可能是由于调查样本的数据所限：任何一个 Web 开发人员都可能对 PHP、C# 或 Ruby 有意见，但是不从事数据分析的人没理由对 MATLAB 不满意。（这也可能是 R 较少被提及“不喜欢”的部分原因）

我们不一定说这里存在因果关系——部分程序员不喜欢就会导致该语言会被抛弃。 另一种可能是，如果人们觉得这种语言已经越来越不流行，那么人们就会觉得很自然地表达他们也不喜欢了。 同样可以想象的是，开发人员经常使用这个字段来记录他们曾经使用的技术，但是不会再使用该技术了。 这将导致那些自然而然地“被替代的”技术就一直停留在“不喜欢”标签里面。

最不喜欢的和最喜欢的

上面的分析仅考虑了编程语言，不涉及操作系统、平台或库（框架）。那么就整体而言，最不喜欢的技术是什么？为了专注于我们有足够数据的更主要的技术，我们其限制为至少提及了 1000 次的技术。

最不喜欢的其中有几个是微软的技术，特别是 IE 和 VB，以及 “微软” 标签（“评估” 也出现在这个列表中，但是没那么糟糕）。有个好消息是，大多数人都不喜欢 Flash。此外，较老的语言，比如 COBOL、 Fortran 和 Pascal 也出现在此处。

值得再次强调的是，这不是对技术及其品质或受欢迎程度的批评。 这只是衡量哪些技术激起了强烈的消极情绪，至少在一部分愿意公开分享其感受的开发人员中如此。

我们也集中观察了那些最流行的技术、那些最不可能被不喜欢的技术（这次，由于喜欢标签出现的比较多，我们仅关注那些被提及至少 10000 次的）。

Git 也许是许多开发者的沮丧源头（绝对包括我！），但人们很少在简历中承认这一点，这是因为它是我们的开发者故事中最受欢迎的标签之一。 R 也出现在了这个列表，但它并不是唯一一个没有争议的与数据科学相关的语言。 机器学习被 23000 人所喜欢，而且很少被人不喜欢。 诸如 Python-3.X、CSS3 和 HTML5 等标签可能表明开发者很少指定他们不喜欢技术的特定版本（如果他们会指定的话）。 当然，jQuery 在 Stack Overflow 上一直是如此受欢迎。

分化的标签网络

我们可以把所有这些标签组合成一个网络。在最近的一篇文章中，Julia Silge 展示了我们如何构建一个代表整个软件生态系统的技术网络。 如果我们根据每个标签不喜欢的程度对节点进行着色，我们可以了解该生态系统的哪些部分比其它部分更有争议。

通过将开发者故事的标签放置到次生态系统中，该网络揭示了哪些类型的标签趋于两级分化。 在微软（以 C＃ 和 .NET 为中心，左上角），PHP（与 WordPress 和 Drupal 一起，左下角）以及移动开发（特别是 Objective-C，右下角）的子生态系统中都有一些意见分化的标签聚合。 在操作系统聚合中（右下），我们可以看到诸如 OSX 之类的系统，以及特别是 Windows 都有不喜欢的人，但是像 Linux、Ubuntu 和 Unix 这样的标签却没有。

竞争

如果某人喜欢某个特定的标签，是否意味着通常他们喜欢或不喜欢另外的标签呢？

我们可以使用出现在特定喜欢标签之间的 phi 系数来衡量它。 （当计算这些相关性时，我们只考虑那些至少有一个不喜欢标签的人。）

这突出显示了软件生态系统的一些“竞争”：Linux 和 OSX vs Windows，Git vs SVN，vim vs emacs 以及（对我来说）R vs SAS。 这些配对中的大多数并不代表“相反”的技术，而是反映了两种解决类似问题的方法。 它们中的许多表明了从以前流行的技术发展到更现代的技术（SVN 由 Git 取代，XML 由 JSON 取代，VB 由 C＃ 取代）。 这对于人们想在简历中列出的内容是有意义的；开发者通常会表明他们不愿意使用他们认为过时的东西。

总结

我对“语言战争”没有任何兴趣，我也不会对用户分享的喜欢或不喜欢的任何技术进行裁断。 对微软技术的两级分化的看法通常会鼓励我分享我的个人经验。 我是一个 Mac 和 UNIX 终身拥趸，几乎我所有的大学和研究生的编程学习都围绕着 Python 和 R。尽管如此，我很高兴能够加入一个 .NET 栈的公司，我很高兴我来了 —— 因为我喜欢这个团队、产品和数据。 我不能代表其他人说话，但我很高兴自己可以从事于自己想做的事情，而不是那些不想要做的事情。

如果您有兴趣分享您喜欢和不喜欢的技术，并想找到您职业生涯的下一份工作，那么您可以创建自己的开发者故事。

想找一份你喜欢的技术的工作？ 在 Stack Overflow Jobs 找到你的下一份工作，在那里你可以搜索你喜欢做的技术工作。

到目前为止，糟糕的文档是 Linux 用户最头痛的问题。这里还有一些其他常见的问题。

正如我在 2016 年开源年鉴的“故障排除提示：5 个最常见的 Linux 问题”中所讨论的，对大多数用户而言 Linux 能安装并按照预期运行，但有些不可避免地会遇到问题。过去一年在这方面有什么变化？又一次，我将问题提交给 LinuxQuestions.org 和社交媒体，并分析了 LQ 回复情况。以下是更新后的结果。

1、 文档

文档及其不足是今年最大的痛点之一。尽管开源的方式产生了优秀的代码，但是制作高质量文档的重要性在最近才走到了前列。随着越来越多的非技术用户采用 Linux 和开源软件，文档的质量和数量将变得至关重要。如果你想为开源项目做出贡献，但不觉得你有足够的技术来提供代码，那么改进文档是参与的好方法。许多项目甚至将文档保存在其仓库中，因此你可以使用你的贡献来适应版本控制的工作流。

2、 软件/库版本不兼容

我对此感到惊讶，但软件/库版本不兼容性屡被提及。如果你没有运行某个主流发行版，这个问题似乎更加严重。我个人许多年来没有遇到这个问题，但是越来越多的诸如 AppImage、Flatpak 和 Snaps 等解决方案的采用让我相信可能确实存在这些情况。我有兴趣听到更多关于这个问题的信息。如果你最近遇到过，请在评论中告诉我。

3、 UEFI 和安全启动

尽管随着更多支持的硬件部署，这个问题在继续得到改善，但许多用户表示仍然存在 UEFI 和/或 安全启动 secure boot 问题。使用开箱即用完全支持 UEFI/安全启动的发行版是最好的解决方案。

4、 弃用 32 位

许多用户对他们最喜欢的发行版和软件项目中的 32 位支持感到失望。尽管如果 32 位支持是必须的，你仍然有很多选择，但可能会继续支持市场份额和心理份额不断下降的平台的项目越来越少。幸运的是，我们谈论的是开源，所以只要有人关心这个平台，你可能至少有几个选择。

5、 X 转发的支持和测试恶化

尽管 Linux 的许多长期和资深的用户经常使用 X 转发 X-forwarding ，并将其视为关键功能，但随着 Linux 变得越来越主流，它看起来很少得到测试和支持，特别是对较新的应用程序。随着 Wayland 网络透明转发的不断发展，情况可能会进一步恶化。

对比去年的遗留和改进

视频（特别是视频加速器、最新的显卡、专有驱动程序、高效的电源管理）、蓝牙支持、特定 WiFi 芯片和打印机以及电源管理以及挂起/恢复，对许多用户来说仍然是麻烦的。更积极的一点的是，安装、HiDPI 和音频问题比一年前显著降低。

Linux 继续取得巨大的进步，而持续的、几乎必然的改进周期将会确保持续数年。然而，与任何复杂的软件一样，总会有问题。

那么说，你在 2017 年发现 Linux 最常见的技术问题是什么？让我在评论中知道它们。

via: https://opensource.com/article/17/10/top-5-linux-painpoints

作者：Jeremy Garcia 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

测试覆盖 （ Testing coverage ） ，指测试系统覆盖被测试系统的程度，一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。 如果在写代码的人仅为可运行而编码，那么在后边会出现一系列的连锁反应，任何没有经过真构思之后书写的代码，都会带来巨大的维护成本吧。昨天 (2017.09.05) 刚刚读到一篇 为什么你的前段工作经验不值钱，不同的人对这里边的那个题的考虑程度是不同的。但我们在每次开始编码之前，都应该以 “代码可用 - 代码健壮 - 代码可靠 - 对需求的宽容” 为规格来约束自己。

译者简介：

GHLandy —— 生活中所有欢乐与苦闷都应藏在心中，有些事儿注定无人知晓，自己也无从说起。

via: http://turnoff.us/geek/the-depressed-developer-17/

作者：Daniel Stori 译者：GHLandy 校对：wxy 合成：GHLandy 点评：GHLandy

本文由 LCTT 原创编译，Linux中国 荣誉推出

八月份，四名美国参议员提出了一项旨在改善物联网（IoT）安全性的法案。2017 年的 “物联网网络安全改进法” 是一项小幅的立法。它没有规范物联网市场。它没有任何特别关注的行业，或强制任何公司做任何事情。甚至没有修改嵌入式软件的法律责任。无论安全多么糟糕，公司可以继续销售物联网设备。

法案的做法是利用政府的购买力推动市场：政府购买的任何物联网产品都必须符合最低安全标准。它要求供应商确保设备不仅可以打补丁，而且是以认证和及时的方式进行修补，没有不可更改的默认密码，并且没有已知的漏洞。这是一个你可以达到的低安全值，并且将大大提高安全性，可以说明关于物联网安全性的当前状态。（全面披露：我帮助起草了一些法案的安全性要求。）

该法案还将修改“计算机欺诈和滥用”和“数字千年版权”法案，以便安全研究人员研究政府购买的物联网设备的安全性。这比我们的行业需求要窄得多。但这是一个很好的第一步，这可能是对这个立法最好的事。

不过，这一步甚至不可能施行。我在八月份写这个专栏，毫无疑问，这个法案你在十月份或以后读的时候会没有了。如果听证会举行，它们无关紧要。该法案不会被任何委员会投票，不会在任何立法日程上。这个法案成为法律的可能性是零。这不仅仅是因为目前的政治 - 我在奥巴马政府下同样悲观。

但情况很严重。互联网是危险的 - 物联网不仅给了眼睛和耳朵，而且还给手脚。一旦有影响到位和字节的安全漏洞、利用和攻击现在将会影响到其血肉。

正如我们在过去一个世纪一再学到的那样，市场是改善产品和服务安全的可怕机制。汽车、食品、餐厅、飞机、火灾和金融仪器安全都是如此。原因很复杂，但基本上卖家不会在安全方面进行竞争，因为买方无法根据安全考虑有效区分产品。市场使用的竞相降低门槛的机制价格降到最低的同时也将质量降至最低。没有政府干预，物联网仍然会很不安全。

美国政府对干预没有兴趣，所以我们不会看到严肃的安全和保障法规、新的联邦机构或更好的责任法。我们可能在欧盟有更好的机会。根据“通用数据保护条例”在数据隐私的规定，欧盟可能会在 5 年内通过类似的安全法。没有其他国家有足够的市场份额来做改变。

有时我们可以选择不使用物联网，但是这个选择变得越来越少见了。去年，我试着不连接网络来购买新车但是失败了。再过几年, 就几乎不可能不连接到物联网。我们最大的安全风险将不会来自我们与之有市场关系的设备，而是来自其他人的汽车、照相机、路由器、无人机等等。

我们可以尝试为理想买单，并要求更多的安全性，但企业不会在物联网安全方面进行竞争 - 而且我们的安全专家不是一个可以产生影响的足够大的市场力量。

我们需要一个后备计划，虽然我不知道是什么。如果你有任何想法请评论。

这篇文章以前出现在 9/10 月的 《IEEE安全与隐私》上。

作者简介：

自从 2004 年以来，我一直在博客上写关于安全的文章，以及从 1998 年以来我的每月订阅中也有。我写书、文章和学术论文。目前我是 IBM Resilient 的首席技术官，哈佛伯克曼中心的研究员，EFF 的董事会成员。

via: https://www.schneier.com/blog/archives/2017/10/iot_cybersecuri.html

作者：Bruce Schneier 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

提要：Linux 社区的许多开发人员对 GPL 许可证牟利者 Patrick McHardy 的行为表示担忧，美国资深开源律师对一些常见问题进行解答，并对如何应对版权牟利行为提出了建议。

针对 Patrick McHardy 强制要求 Linux 分发者遵循 GPL 许可证的举动，开源社区许多人士表示了担忧。基于与 McHardy 行动相关的公开信息，以及开源合规维权的一些法律原则，美国资深开源律师对一些常见问题进行了解答。

Patrick Mchardy 是谁？ McHardy 是 Netfilter 核心开发团队的前任负责人。 Netfilter 是 Linux 内核中的一个实用程序，可以执行各种网络功能，例如改善网络地址转换（NAT），NAT 是将 Internet 协议地址转换为另一个 IP 地址的过程。对于维护 Linux 系统的安全性来说，控制网络流量至关重要。

McHardy 对 Linux 有多少贡献？

这不是一个容易回答的问题。首先，评估贡献的重要性并不容易；我们能做的就是查看 提交 （ commit ） 的数量和大小。其次，即使去跟踪提交，跟踪机制也不完美。 Git 有一个 blame 功能，跟踪谁在名义上向 Git 数据库提交了哪些代码行。Git 的 blame 功能可以使用诸如 cregit 这样的工具，以更具细粒度的水平来报告提交，从而在文件级别上对贡献度有一个更准确的认知。Git 的 blame 机制和 cregit 是非常实用的，因为它们都使用公开易得的信息，而信息只需要被正确解释。

结合 cregit 和 blame 进行分析可以帮助评估 McHardy 的潜在贡献。例如：

• 他的大部分贡献似乎是在 2006 年到 2008 年和 2012 年期间。
• 在 McHardy 包含其版权声明的大约 135 个文件中，只有 1/3 的文件是 McHardy 贡献了该文件代码的 50％ 或以上。
• 他的贡献看起来不到内核代码的 0.25％。

McHardy 的大部分贡献似乎都给了 Netfilter；然而，blame 机制可能并不总能还原全貌。例如，提交者可以 签入 （ check in ） 许多行代码，但只进行细微修改，也可以签入其他人编写或拥有的代码。由于这些原因，提交者的作者身份可能被过低或过多报告。

在 2002 年之前对内核贡献的记录对于识别贡献者来说不是特别有用，因为在当时，Linus Torvalds 签入了所有代码。 McHardy 的贡献直到 2004 年才开始。

Hellwig 诉 VMware 一案中出现了使用开发存储库的元数据确认版权所有权的困难。法院可能不愿意接受这样的信息来作为证明作者身份的证据。

McHardy 在 Linux 内核中拥有哪些版权？

大型项目（如 Linux 内核）的版权归属复杂。这就像一个拼凑的被子。当开发者对内核做出贡献时，他们不签署任何贡献协议或版权转让协议。GPL 涵盖了他们的贡献，软件副本的接收人根据 GPL 直接从所有作者获得许可。内核项目使用一个名为 “原始开发者证书” （ Developer Certificate of Origin ） 的文件，该文件不授予任何版权许可。贡献者的个人权利与在项目中的权利作为整体并存。 所以，像 McHardy 这样的作者一般都会拥有他所创作的作品的版权，但并不享有整个内核的版权。

什么是 “社区维权” （ community enforcement ） ？

由于大型项目（如 Linux 内核）的所有权常常分散在许多作者手中，所以个体所有者可以采取不符合社区目标的维权行动。虽然社区可能会对如何以最好的方式来鼓励遵守 GPL 条款有很多看法，但大多数人认为维权应该是非正式的（不是通过诉讼），而且主要目标应该是合规（而不是惩罚）。例如， 软件自由保护组织 （ Software Freedom Conservancy ） （SFC）已经颁布了一些社区维权原则，其中优选合规，而不是寻求诉讼或赔偿金。对于非正式行为何时应该成为诉讼，或维权者应该要求赔偿多少钱，没有明确的规定。然而，Linux 社区的大多数开发人员将诉讼视为最后的手段，并不愿意采取法律行动，而与真正希望合规的用户进行合作。

为什么这么多的开源诉讼在德国提交？

一些寻求进行开源许可证维权的原告已经向德国法院提交权利主张。在德国有一些在美国或其他 普通法 （ common law ） 国家没有能够确切与之类比的寻求法律诉讼的手段。

• Abmahnung（ “警告” （ warning ） ）：“警告”是索赔人要求被告停止做某事的要求。在版权语境下，这是版权所有者发出的一封信函，要求所述侵权人停止侵权。这些信件是由律师而不是法庭签发的，通常是德国版权维权行动的第一步。在美国，最接近的方式应该是 警告信 cease and desist letter 。
• Unterlassungserklaerung（ “停止声明” cease and desist declaration 或 “禁止声明” declaration of injunction ）：“警告”通常会附有“停止声明”。这种“声明”就像合同一样，签署的话会要求被告人承担其它并不存在的法律义务。特别是，该声明可能包含 GPL 本身并不要求的义务。在德国，这样一份文件通常包含针对不合规进行惩罚的内容。在美国，类似的做法是和解协议，但和解协议很少规定违约的处罚方式，事实上在美国，合同中的“处罚”可能无法强制执行。“声明”不是法院命令，但如果被告签字，可以获得法院命令的法定效力。所以，在征求律师法律意见之前签字往往不是一个好主意。在考虑如何应对寄出停止声明的原告时，还有其他方法，包括提出修改后的处罚或义务较少的声明。此外，由于停止声明可能包含不公开的要求，签署这些文件也可能产生额外的困难，例如限制原告寻求其他被告支持或向社区公开索赔人的权利主张。
  更多详情参见：abmahnung.org/unterlassungserklaerung/ 。
• Einstweilige Verfügung（“ 临时禁令 interim injunction ”或“ 初步禁令 preliminary injunction ”）：“临时禁令”是一项类似美国临时禁令的法院命令。虽然没有要求原告在向法院提出“临时禁令”之前发出“警告”，但在被告对“警告”或“声明”不作出回应时，鼓励原告寻求“临时禁令”。侵犯版权的临时禁令可以处以 25 万欧元罚款或 6 个月的监禁。相比之下，在美国，侵犯版权的刑事处罚极为罕见，必须由政府而不是私人机构追究。此外，在美国，法院也没有为未来的侵权行为提供补救措施，它们只是要求被告停止现行的侵权行为或者支付损害赔偿金。在德国， 单方 ex parte 也可以提出临时禁令，这意味着原告可以在没有被告听证的情况下向法院提出申请，而且可以在没有被告参与的情况下发出临时禁令。如果您收到“警告”，并怀疑原告可能会随之提出 “临时禁令”，可以向法院抢先提出 “异议” opposition 。
  更多详情参见：Abmahnung.org 。
• Widerspruch（ “异议” opposition 或 “反驳” contradiction ）：“异议”是被告向法院提出否决“临时禁令”的机会。
  更多详情参见：这篇德国法院命令的英文翻译 。

McHardy 发起了多少权利主张？

由于许多德国法庭案件缺乏公开记录，因此很难确定 McHardy 的确切行动数量。据说 McHardy 已经接触了超过 50 个维权目标。有关详细信息，请参阅 “源码控制” （ Source Code Control ） 和 《2016 年开源社区 7 个显著的法律进展》 （ 7 Notable Legal Developments in Open Source in 2016 ） 。这并不一定意味着有 50 起诉讼，而是可能意味着 50 起威胁要提起诉讼的要求。但是，很难用公开信息来核实这个说法。有关详细信息，请参阅 《开源生态系统的诉讼和合规》 （ Litigation and Compliance in the Open Source Ecosystem ） 。

为什么社区没有去阻止 McHardy？

包括软件自由保护组织在内的各种社区成员已经开始试图说服 McHardy 改变策略，但到目前为止还没有成功。 Netfilter 项目最近发布了一个许可问答，解决大家对 McHardy 行为担忧的问题。

我们可以做些什么来阻止 McHardy 和其他版权牟利者？

这个问题没有确定的答案，也许没有办法能完全阻止他们。但是，这些建议可能会减少版权牟利者的数量。

• 尽可能遵守开源许可证。目前有足够的资源来学习如何遵守许可证，以及如何在贵公司设立开源合规计划。例如：

  • Linux基金会发布了 《实用 GPL 合规手册》 （ Practical GPL Compliance ） 。
  • 软件自由法律中心发布了 《GPL 合规实用指南” （第二版） 》 （ A Practical Guide to GPL Compliance ） 。
  • OpenChain 项目发布了开源管理内部流程规范。
• 在寻求法律意见之前不要签署 “停止声明” （ Unterlassungserklärung ） 。如上所述，停止声明可能让您承担 GPL 身没有的义务和处罚。不要与版权牟利者合作。你可以使自己成为一个更难攻克的目标，并争取社区其他目标的帮助。
• 支持开源开发。作者不应该诉诸投机来谋生。使用开源软件的公司不应该期望开源开发人员免费开发软件，他们应该筹集资金支持重要项目。
• 学会识别版权牟利者。了解社区导向的 GPL 维权与版权勒索之间的一般差异。面向社区的维权一般旨在通过教育和帮助实现 GPL 合规，同时尊重用户的自由。相比之下，牟利行为可能侧重以不加考究和漫无目的的权力主张和威胁要提起法律诉讼来获得经济利益。注意确认优先考虑经济利益的权利主张，警惕不合理的损害赔偿金。
• 公开权利主张。如果你是一个牟利者的目标，并且可以选择公开其权利主张，那就公开它，通过阻碍对方的行动来帮助你和其他人。作为开源社区的成员，我们都有义务向那些企图以诉讼拖垮社区的牟利者们提出反对，因为问题能够以更恰当和更少争议的方式解决。

作者简介：Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人，为客户提供技术交易和知识产权方面的建议，是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。 《最佳律师》 （ Best Lawyers ） 将她提名为 2018 年年度 IT 律师。

译者简介：张琳，集慧智佳知识产权咨询公司分析师，专业德语，辅修法律。

去年今日（LCTT 译注：本文发表于 2016 年），在非常符合 Valve 风格的跳票之后，大众迎来了 Steam Machines 的发布。即使是在 Linux 桌面环境对于游戏的支持大步进步的今天，Steam Machines 作为一个平台依然没有飞跃，而 SteamOS 似乎也止步不前。这些由 Valve 发起的项目究竟怎么了？这些项目为何被发起，又是如何失败的？一些改进又是否曾有机会挽救这些项目的成败？

行业环境

在 2012 年 Windows 8 发布的时候，微软像 iOS 与 Android 那样，为 Windows 集成了一个应用商店。在微软试图推广对触摸体验友好的界面时，为了更好的提供 “Metro” UI 语言指导下的沉浸式触摸体验，他们同时推出了一系列叫做 “WinRT” 的 API。然而为了能够使用这套 API，应用开发者们必须把应用程序通过 Windows 应用商城发布，并且正如其它应用商城那样，微软从中抽成 30%。对于 Valve 的 CEO，Gabe Newell (G 胖) 而言，这种限制发布平台和抽成行为是让人无法接受的，而且他前瞻地看到了微软利用行业龙头地位来推广 Windows 商店和 Metro 应用对于 Valve 潜在的危险，正如当年微软用 IE 浏览器击垮 Netscape 浏览器一样。

对于 Valve 来说，运行 Windows 的 PC 的优势在于任何人都可以不受操作系统和硬件方的限制运行各种软件。当像 Windows 这样的专有平台对像 Steam 这样的第三方软件限制越来越严格时，应用开发者们自然会想要寻找一个对任何人都更开放和自由的替代品，他们很自然的会想到 Linux 。Linux 本质上只是一套内核，但你可以轻易地使用 GNU 组件、Gnome 等软件在这套内核上开发出一个操作系统，比如 Ubuntu 就是这么来的。推行 Ubuntu 或者其他 Linux 发行版自然可以为 Valve 提供一个无拘无束的平台，以防止微软或者苹果变成 Valve 作为第三方平台之路上的的敌人，但 Linux 甚至给了 Valve 一个创造新的操作系统平台的机会。

概念化

如果我们把 Steam Machines 叫做主机的话，Valve 当时似乎认定了主机平台是一个机会。为了迎合用户对于电视主机平台用户界面的审美期待，同时也为了让玩家更好地从稍远的距离上在电视上玩游戏，Valve 为 Steam 推出了 Big Picture 模式。Steam Machines 的核心要点是开放性；比方说所有的软件都被设计成可以脱离 Windows 工作，又比如说 Steam Machines 手柄的 CAD 图纸也被公布出来以便支持玩家二次创作。

原初计划中，Valve 打算设计一款官方的 Steam Machine 作为旗舰机型。但最终，这些机型只在 2013 年的时候作为原型机给与了部分测试者用于测试。Valve 后来也允许像戴尔这样的 OEM 厂商们制造 Steam Machines，并且也赋予了他们制定价格和配置规格的权利。有一家叫做 “Xi3” 的公司展示了他们设计的 Steam Machine 小型机型，那款机型小到可以放在手掌上，这一新闻创造了围绕 Steam Machines 的更多热烈讨论。最终，Valve 决定不自己设计制造 Steam Machines，而全权交给 OEM 合作厂商们。

这一过程中还有很多天马行空的创意被列入考量，比如在手柄上加入生物识别技术、眼球追踪以及动作控制等。在这些最初的想法里，陀螺仪被加入了 Steam Controller 手柄，HTC Vive 的手柄也有各种动作追踪仪器；这些想法可能最初都来源于 Steam 手柄的设计过程中。手柄最初还有些更激进的设计，比如在中心放置一块可定制化并且会随着游戏内容变化的触摸屏。但最后的最后，发布会上的手柄偏向保守了许多，但也有诸如双触摸板和内置软件等黑科技。Valve 也考虑过制作面向笔记本类型硬件的 Steam Machines 和 SteamOS。这个企划最终没有任何成果，但也许 “Smach Z” 手持游戏机会是发展的方向之一。

在 2013 年九月，Valve 对外界宣布了 Steam Machines 和 SteamOS， 并且预告会在 2014 年中发布。前述的 300 台原型机在当年 12 月分发给了测试者们，随后次年 1 月，又分发给了开发者们 2000 台原型机。SteamOS 也在那段时间分发给有 Linux 经验的测试者们试用。根据当时的测试反馈，Valve 最终决定把产品发布延期到 2015 年 11 月。

SteamOS 的延期跳票给合作伙伴带来了问题；戴尔的 Steam Machine 由于早发售了一年，结果不得不改为搭配了额外软件、甚至运行着 Windows 操作系统的 Alienware Alpha。

正式发布

在最终的正式发布会上，Valve 和 OEM 合作商们发布了 Steam Machines，同时 Valve 还推出了 Steam Controller 手柄和 Steam Link 串流游戏设备。Valve 也在线下零售行业比如 GameStop 里开辟了货架空间。在发布会前，有几家 OEM 合作商退出了与 Valve 的合作；比如 Origin PC 和 Falcon Northwest 这两家高端精品主机设计商。他们宣称 Steam 生态的性能问题和一些限制迫使他们决定弃用 SteamOS。

Steam Machines 在发布后收到了褒贬不一的评价。另一方面 Steam Link 则普遍受到好评，很多人表示愿意在客厅电视旁为他们已有的 PC 系统购买 Steam Link， 而不是购置一台全新的 Steam Machine。Steam Controller 手柄则受到其丰富功能伴随而来的陡峭学习曲线影响，评价一败涂地。然而针对 Steam Machines 的批评则是最猛烈的。诸如 LinusTechTips 这样的评测团体 （LCTT 译注：YouTube 硬件界老大，个人也经常看他们节目）注意到了主机的明显的不足，其中甚至不乏性能为题。很多厂商的 Machines 都被批评为性价比极低，特别是经过和玩家们自己组装的同配置机器或者电视主机做对比之后。SteamOS 而被批评为兼容性有问题，Bug 太多，以及性能不及 Windows。在所有 Machines 里，戴尔的 Alienware Alpha 被评价为最有意思的一款，主要是由于品牌价值和机型外观极小的缘故。

通过把 Debian Linux 操作系统作为开发基础，Valve 得以为 SteamOS 平台找到很多原本就存在与 Steam 平台上的 Linux 兼容游戏来作为“首发游戏”。所以起初大家认为在“首发游戏”上 Steam Machines 对比其他新发布的主机优势明显。然而，很多宣称会在新平台上发布的游戏要么跳票要么被中断了。Rocket League 和 Mad Max 在宣布支持新平台整整一年后才真正发布，而《巫师 3》和《蝙蝠侠：阿克汉姆骑士》甚至从来没有发布在新平台上。就《巫师 3》的情况而言，他们的开发者 CD Projekt Red 拒绝承认他们曾经说过要支持新平台；然而他们的游戏曾在宣布支持 Linux 和 SteamOS 的游戏列表里赫然醒目。雪上加霜的是，很多 AAA 级的大作甚至没宣布移植，虽然最近这种情况稍有所好转了。

被忽视的

在 Stame Machines 发售后，Valve 的开发者们很快转移到了其他项目的工作中去了。在当时，VR 项目最为内部所重视，6 月份的时候大约有 1/3 的员工都在相关项目上工作。Valve 把 VR 视为亟待开发的一片领域，而他们的 Steam 则应该作为分发 VR 内容的生态环境。通过与 HTC 合作生产，Valve 设计并制造出了他们自己的 VR 头戴和手柄，并计划在将来更新换代。然而与此同时，Linux 和 Steam Machines 都渐渐淡出了视野。SteamVR 甚至直到最近才刚刚支持 Linux （其实还没对普通消费者开放使用，只在 SteamDevDays 上展示过对 Linux 的支持），而这一点则让我们怀疑 Valve 在 Stame Machines 和 Linux 的开发上是否下定了足够的决心。

SteamOS 自发布以来几乎止步不前。SteamOS 2.0 作为上一个大版本号更新，几乎只是同步了 Debian 上游的变化，而且还需要用户重新安装整个系统，而之后的小补丁也只是在做些上游更新的配合。当 Valve 在其他事关性能和用户体验的项目（例如 Mesa）上进步匪浅的时候，针对 Steam Machines 的相关项目则少有顾及。

很多原本应有的功能都从未完成。Steam 的内置功能，例如聊天和直播，都依然处于较弱的状态，而且这种落后会影响所有平台上的 Steam 用户体验。更具体来说，Steam 没有像其他主流主机平台一样把诸如 Netflix、Twitch 和 Spotify 之类的服务集成到客户端里，而通过 Steam 内置的浏览器使用这些服务则体验极差，甚至无法使用；而如果要使用第三方软件则需要开启 Terminal，而且很多软件甚至无法支持控制手柄 —— 无论从哪方面讲这样的用户界面体验都糟糕透顶。

Valve 同时也几乎没有花任何力气去推广他们的新平台，而选择把一切都交由 OEM 厂商们去做。然而，几乎所有 OEM 合作商们要么是高端主机定制商，要么是电脑生产商，要么是廉价电脑公司（LCTT 译注：简而言之没有一家有大型宣传渠道）。在所有 OEM 中，只有戴尔是 PC 市场的大碗，也只有他们真正给 Steam Machines 做了广告宣传。

最终销量也不尽人意。截至 2016 年 6 月，7 个月间 Steam Controller 手柄的销量在包括捆绑销售的情况下仅销售 500,000 件。这让 Steam Machines 的零售情况差到只能被归类到十万俱乐部的最底部。对比已经存在的巨大 PC 和主机游戏平台，可以说销量极低。

事后诸葛亮

既然知道了 Steam Machines 的历史，我们又能否总结出失败的原因以及可能存在的翻身改进呢？

视野与目标

Steam Machines 从来没搞清楚他们在市场里的定位究竟是什么，也从来没说清楚他们具体有何优势。从 PC 市场的角度来说，自己搭建台式机已经非常普及，并且往往可以让电脑可以匹配玩家自己的目标，同时升级性也非常好。从主机平台的角度来说，Steam Machines 又被主机本身的相对廉价所打败，虽然算上游戏可能稍微便宜一些，但主机上的用户体验也直白很多。

PC 用户会把多功能性看得很重，他们不仅能用电脑打游戏，也一样能办公和做各种各样的事情。即使 Steam Machines 也是跑着的 SteamOS 操作系统的自由的 Linux 电脑，但操作系统和市场宣传加深了 PC 玩家们对 Steam Machines 是不可定制的硬件、低价的、更接近主机的印象。即使这些 PC 用户能接受在客厅里购置一台 Steam Machines，他们也有 Steam Link 可以选择，而且很多更小型机比如 NUC 和 Mini-ITX 主板定制机可以让他们搭建更适合放在客厅里的电脑。SteamOS 软件也允许把这些硬件转变为 Steam Machines，但寻求灵活性和兼容性的用户通常都会使用一般 Linux 发行版或者 Windows。何况最近的 Windows 和 Linux 桌面环境都让维护一般用户的操作系统变得自动化和简单了。

电视主机用户们则把易用性放在第一。虽然近年来主机的功能也逐渐扩展，比如可以播放视频或者串流，但总体而言用户还是把即插即用即玩、不用担心兼容性和性能问题和低门槛放在第一。主机的使用寿命也往往较长，一般在 4-7 年左右，而统一固定的硬件也让游戏开发者们能针对其更好的优化和调试软件。现在刚刚兴起的中生代升级，例如天蝎和 PS 4 Pro 则可能会打破这样统一的游戏体验，但无论如何厂商还是会要求开发者们需要保证游戏在原机型上的体验。为了提高用户粘性，主机也会有自己的社交系统和独占游戏。而主机上的游戏也有实体版，以便将来重用或者二手转卖，这对零售商和用户都是好事儿。Steam Machines 则完全没有这方面的保证；即使长的像一台客厅主机，他们却有 PC 高昂的价格和复杂的硬件情况。

妥协

综上所述，Steam Machines 可以说是“集大成者”，吸取了两边的缺点，又没有自己明确的定位。更糟糕的是 Steam Machines 还展现了 PC 和主机都没有的毛病，比如没有 AAA 大作，又没有 Netflix 这样的客户端。抛开这些不说，Valve 在提高他们产品这件事上几乎没有出力，甚至没有尝试着解决 PC 和主机两头定位矛盾这一点。

然而在有些事情上也许原本 PC 和主机就没法折中妥协。像图像设定和 Mod 等内容的加入会无法保证“傻瓜机”一般的可靠，而且系统下层的复杂性也会逐渐暴露。

而最复杂的是 Steam Machines 多变的硬件情况，这使得用户不仅要考虑价格还要考虑配置，还要考虑这个价格下和别的系统（PC 和主机）比起来划算与否。更关键的是，Valve 无论如何也应该做出某种自动硬件检测机制，这样玩家才能知道是否能玩某个游戏，而且这个测试既得简单明了，又要能支持 Steam 上几乎所有游戏。同时，Valve 还要操心未来游戏对配置需求的变化，比如2016 年的 "A" 等主机三年后该给什么评分呢？

Valve, 个人努力与公司结构

尽管 Valve 在 Steam 上创造了辉煌，但其公司的内部结构可能对于开发一个像 Steam Machines 一样的平台是有害的。他们几乎没有领导的自由办公结构，以及所有人都可以自由移动到想要工作的项目组里决定了他们具有极大的创新，研发，甚至开发能力。据说 Valve 只愿意招他们眼中的的 “顶尖人才”，通过极其严格的筛选标准，并通过让他们在自己认为“有意义”的项目里工作以保持热情。然而这种思路很可能是错误的；拉帮结派总是存在，而 G胖的话或许比公司手册上写的还管用，而又有人时不时会由于特殊原因被雇佣或解雇。

正因为如此，很多虽不闪闪发光甚至维护起来有些无聊但又需要大量时间的项目很容易枯萎。Valve 的客服已是被人诟病已久的毛病，玩家经常觉得被无视了，而 Valve 则经常不到万不得已、法律要求的情况下绝不行动：例如自动退款系统，就是在澳大利亚和欧盟法律的要求下才被加入的；更有目前还没结案的华盛顿州 CS:GO 物品在线赌博网站一案。

各种因素最后也反映在 Steam Machines 这一项目上。Valve 方面的跳票迫使一些合作方做出了尴尬的决定，比如戴尔提前一年发布了 Alienware Alpha 外观的 Steam Machine 就在一年后的正式发布时显得硬件状况落后了。跳票很可能也导致了游戏数量上的问题。开发者和硬件合作商的对跳票和最终毫无轰动的发布也不明朗。Valve 的 VR 平台干脆直接不支持 Linux，而直到最近，SteamVR 都风风火火迭代了好几次之后，SteamOS 和 Linux 依然不支持 VR。

“长线钓鱼”

尽管 Valve 方面对未来的规划毫无透露，有些人依然认为 Valve 在 Steam Machine 和 SteamOS 上是放长线钓大鱼。他们论点是 Steam 本身也是这样的项目 —— 一开始作为游戏补丁平台出现，到现在无敌的游戏零售和玩家社交网络。虽然 Valve 的独占游戏比如《半条命 2》和 《CS》 也帮助了 Steam 平台的传播。但现今我们完全无法看到 Valve 像当初对 Steam 那样上心 Steam Machines。同时现在 Steam Machines 也面临着 Steam 从没碰到过的激烈竞争。而这些竞争里自然也包含 Valve 自己的那些把 Windows 作为平台的 Steam 客户端。

真正目的

鉴于投入在 Steam Machines 上的努力如此之少，有些人怀疑整个产品平台是不是仅仅作为某种博弈的筹码才被开发出来。原初 Steam Machines 就发家于担心微软和苹果通过自己的应用市场垄断游戏的反制手段当中，Valve 寄希望于 Steam Machines 可以在不备之时脱离那些操作系统的支持而运行，同时也是提醒开发者们，也许有一日整个 Steam 平台会独立出来。而当微软和苹果等方面的风口没有继续收紧的情况下，Valve 自然就放慢了开发进度。然而我不这样认为；Valve 其实已经花了不少精力与硬件商和游戏开发者们共同推行这件事，不可能仅仅是为了吓吓他人就终止项目。你可以把这件事想成，微软和 Valve 都在吓唬对方 —— 微软推出了突然收紧的 Windows 8 ，而 Valve 则展示了一下可以独立门户的能力。

但即使如此，谁能保证开发者不会愿意跟着微软的封闭环境跑了呢？万一微软最后能提供更好的待遇和用户群体呢？更何况，微软现在正大力推行 Xbox 和 Windows 的交叉和整合，甚至 Xbox 独占游戏也出现在 Windows 上，这一切都没有损害 Windows 原本的平台性定位 —— 谁还能说微软方面不是 Steam 的直接竞争对手呢？

还会有人说这一切一切都是为了推进 Linux 生态环境尽快接纳 PC 游戏，而 Steam Machines 只是想为此大力推一把。但如果是这样，那这个目的实在是性价比极低，因为本愿意支持 Linux 的自然会开发，而 Steam Machines 这一出甚至会让开发者对平台期待额落空从而伤害到他们。

大家眼中 Valve 曾经的机会

我认为 Steam Machines 的创意还是很有趣的，而也有一个与之匹配的市场，但就结果而言 Valve 投入的创意和努力还不够多，而定位模糊也伤害了这个产品。我认为 Steam Machines 的优势在于能砍掉 PC 游戏传统的复杂性，比如硬件问题、整机寿命和维护等；但又能拥有游戏便宜，可以打 Mod 等好处，而且也可以做各种定制化以满足用户需求。但他们必须要让产品的核心内容：价格、市场营销、机型产品线还有软件的质量有所保证才行。

我认为 Steam Machines 可以做出一点妥协，比如硬件升级性（尽管这一点还是有可能被保留下来的 —— 但也要极为小心整个过程对用户体验的影响）和产品选择性，来减少摩擦成本。PC 一直会是一个并列的选项。想给用户产品可选性带来的只有一个困境，成吨的质量低下的 Steam Machines 根本不能解决。Valve 得自己造一台旗舰机型来指明 Steam Machines 的方向。毫无疑问，Alienware 的产品是最接近理想目标的，但它说到底也不是 Valve 的官方之作。Valve 内部不乏优秀的工业设计人才，如果他们愿意投入足够多的重视，我认为结果也许会值得他们努力。而像戴尔和 HTC 这样的公司则可以用他们丰富的经验帮 Valve 制造成品。直接钦定 Steam Machines 的硬件周期，并且在期间只推出 1-2 台机型也有助于帮助解决问题，更不用说他们还可以依次和开发商们确立性能的基准线。我不知道 OEM 合作商们该怎么办；如果 Valve 专注于自己的几台设备里，OEM 们很可能会变得多余甚至拖平台后腿。

我觉得修复软件问题是最关键的。很多问题在严重拖着 Steam Machines 的后腿，比如缺少主机上遍地都是、又能轻易安装在 PC 上的的 Netflix 和 Twitch，那么即使做好了客厅体验问题依然是严重的败笔。即使 Valve 已经在逐步购买电影的版权以便在 Steam 上发售，我觉得用户还是会倾向于去使用已经在市场上建立口碑的一些流媒体服务。这些问题需要被严肃地对待，因为玩家日益倾向于把主机作为家庭影院系统的一部分。同时，修复 Steam 客户端和平台的问题也很重要，和更多第三方服务商合作增加内容应该会是个好主意。性能问题和 Linux 下的显卡问题也很严重，不过好在他们最近在慢慢进步。移植游戏也是个问题。类似 Feral Interactive 或者 Aspyr Media 这样的游戏移植商可以帮助扩展 Steam 的商店游戏数量，但联系开发者和出版社可能会有问题，而且这两家移植商经常在移植的容器上搞自己的花样。Valve 已经在帮助游戏工作室自己移植游戏了，比如 Rocket League，不过这种情况很少见，而且就算 Valve 去帮忙了，也是非常符合 Valve 拖拉的风格。而 AAA 大作这一块内容也绝不应该被忽略 —— 近来这方面的情况已经有极大好转了，虽然 Linux 平台的支持好了很多，但在玩家数量不够以及 Valve 为 Steam Machines 提供的开发帮助甚少的情况下，Bethesda 这样的开发商依然不愿意移植游戏；同时，也有像 Denuvo 一样缺乏数字版权管理的公司难以向 Steam Machines 移植游戏。

在我看来 Valve 需要在除了软件和硬件的地方也多花些功夫。如果他们只有一个机型的话，他们可以很方便的在硬件生产上贴点钱。这样 Steam Machines 的价格就能跻身主机的行列，而且还能比自己组装 PC 要便宜。针对正确的市场群体做营销也很关键，即便我们还不知道目标玩家应该是谁（我个人会对这样的 Steam Machines 感兴趣，而且我有一整堆已经在 Steam 上以相当便宜的价格买下的游戏）。最后，我觉得零售商们其实不会对 Valve 的计划很感冒，毕竟他们要靠卖和倒卖实体游戏赚钱。

就算 Valve 在产品和平台上采纳过这些改进，我也不知道怎样才能激活 Steam Machines 的全市场潜力。总的来说，Valve 不仅得学习自己的经验教训，还应该参考曾经有过类似尝试的厂商们，比如尝试依靠开放平台的 3DO 和 Pippin；又或者那些从台式机体验的竞争力退赛的那些公司，其实 Valve 如今的情况和他们也有几分相似。亦或者他们也可以观察一下任天堂 Switch —— 毕竟任天堂也在尝试跨界的创新。

注解: 上述点子由 liamdawe 整理，所有的想法都由用户提交。

本文是被一位访客提交的，我们欢迎大家前来提交文章。

via: https://www.gamingonlinux.com/articles/user-editorial-steam-machines-steamos-after-a-year-in-the-wild.8474

作者：calvin 译者：Moelf 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出