分类 观点 下的文章

有时我会觉得自己的计算机是一栋非常大的房子,我每天都会访问这栋房子,也对一楼的大部分房间都了如指掌,但仍然还是有我没有去过的卧室,有我没有打开过的衣柜,有我没有探索过的犄角旮旯。我感到有必要更多地了解我的计算机了,就像任何人都会觉得有必要看看自己家里从未去过的房间一样。

GNU Readline 是个不起眼的小软件库,我依赖了它多年却没有意识到它的存在,也许有成千上万的人每天都在不经意间使用它。如果你用 Bash shell 的话,每当你自动补全一个文件名,或者在输入的一行文本中移动光标,以及搜索之前命令的历史记录时,你都在使用 GNU Readline;当你在 Postgres(psql)或是 Ruby REPL(irb)的命令行界面中进行同样的操作时,你依然在使用 GNU Readline。很多软件都依赖 GNU Readline 库来实现用户所期望的功能,不过这些功能是如此的辅助与不显眼,以至于在我看来很少有人会停下来去想它是从哪里来的。

GNU Readline 最初是自由软件基金会在 20 世纪 80 年代创建的,如今作为每个人的基础计算设施的重要的、甚至看不见的组成部分的它,由一位志愿者维护。

充满特色

GNU Readline 库的存在,主要是为了增强各种命令行界面,它提供了一组通用的按键,使你可以在一个单行输入中移动和编辑。例如,在 Bash 提示符中按下 Ctrl-A,你的光标会跳到行首,而按下 Ctrl-E 则会跳到行末;另一个有用的命令是 Ctrl-U,它会删除该行中光标之前的所有内容。

有很长一段时间,我通过反复敲击方向键来在命令行上移动,如今看来这十分尴尬,也不知道为什么,当时的我从来没有想过可以有一种更快的方法。当然了,没有哪一个熟悉 Vim 或 Emacs 这种文本编辑器的程序员愿意长时间地击打方向键,所以像 Readline 这样的东西必然会被创造出来。在 Readline 上可以做的绝非仅仅跳来跳去,你可以像使用文本编辑器那样编辑单行文本——这里有删除单词、单词换位、大写单词、复制和粘贴字符等命令。Readline 的大部分按键/快捷键都是基于 Emacs 的,它基本上就是一个单行文本版的 Emacs 了,甚至还有录制和重放宏的功能。

我从来没有用过 Emacs,所以很难记住所有不同的 Readline 命令。不过 Readline 有着很巧妙的一点,那就是能够切换到基于 Vim 的模式,在 Bash 中可以使用内置的 set 命令来这样做。下面会让 Readline 在当前的 shell 中使用 Vim 风格的命令:

$ set -o vi

该选项启用后,就可以使用 dw 等命令来删除单词了,此时相当于 Emacs 模式下的 Ctrl-U 的命令是 d0

我第一次知道有这个功能的时候很兴奋地想尝试一下,但它对我来说并不是那么好用。我很高兴知道有这种对 Vim 用户的让步,在使用这个功能上你可能会比我更幸运,尤其是你还没有使用 Readline 的默认按键的话;我的问题在于,我听说有基于 Vim 的界面时已经学会了几种默认按键,因此即使启用了 Vim 的选项,也一直在错误地用着默认的按键;另外因为没有某种指示器,所以 Vim 的模态设计在这里会很尴尬——你很容易就忘记了自己处于哪个模式,就因为这样,我卡在了一种虽然使用 Vim 作为文本编辑器,但却在 Readline 上用着 Emacs 风格的命令的情况里,我猜其他很多人也是这样的。

如果你觉得 Vim 和 Emacs 的键盘命令系统诡异而神秘(这并不是没有道理的),你可以按照喜欢的方式自定义 Readline 的键绑定。Readline 在启动时会读取文件 ~/.inputrc,它可以用来配置各种选项与键绑定,我做的一件事是重新配置了 Ctrl-K:通常情况下该命令会从光标处删除到行末,但我很少这样做,所以我在 ~/.inputrc 中添加了以下内容,把它绑定为直接删除整行:

Control-k: kill-whole-line

每个 Readline 命令(文档中称它们为 “函数” )都有一个名称,你可以用这种方式将其与一个键序列联系起来。如果你在 Vim 中编辑 ~/.inputrc,就会发现 Vim 知道这种文件类型,还会帮你高亮显示有效的函数名,而不高亮无效的函数名。

~/.inputrc 可以做的另一件事是通过将键序列映射到输入字符串上来创建预制宏。Readline 手册给出了一个我认为特别有用的例子:我经常想把一个程序的输出保存到文件中,这意味着我得经常在 Bash 命令中追加类似 > output.txt 这样的东西,为了节省时间,可以把它做成一个 Readline 宏:

Control-o: "> output.txt"

这样每当你按下 Ctrl-O 时,你都会看到 > output.txt 被添加到了命令行光标的后面,这样很不错!

不过你可以用宏做的可不仅仅是为文本串创建快捷方式;在 ~/.inputrc 中使用以下条目意味着每次按下 Ctrl-J 时,行内已有的文本都会被 $() 包裹住。该宏先用 Ctrl-A 移动到行首,添加 $( ,然后再用 Ctrl-E 移动到行尾,添加 )

Control-j: "\C-a$(\C-e)"

如果你经常需要像下面这样把一个命令的输出用于另一个命令的话,这个宏可能会对你有帮助:

$ cd $(brew --prefix)

~/.inputrc 文件也允许你为 Readline 手册中所谓的 “变量” 设置不同的值,这些变量会启用或禁用某些 Readline 行为,你也可以使用这些变量来改变 Readline 中像是自动补全或者历史搜索这些行为的工作方式。我建议开启的一个变量是 revert-all-at-newline,它是默认关闭的,当这个变量关闭时,如果你使用反向搜索功能从命令历史记录中提取一行并编辑,但随后又决定搜索另一行,那么你所做的编辑会被保存在历史记录中。我觉得这样会很混乱,因为这会导致你的 Bash 命令历史中出现从未运行过的行。所以在你的 ~/.inputrc 中加入这个:

set revert-all-at-newline on

在你用 ~/.inputrc 设置了选项或键绑定以后,它们会适用于任何使用 Readline 库的地方,显然 Bash 也包括在内,不过你也会在其它像是 irbpsql 这样的程序中受益。如果你经常使用关系型数据库的命令行界面,一个用于插入 SELECT * FROM 的 Readline 宏可能会很有用。

Chet Ramey

GNU Readline 如今由凯斯西储大学的高级技术架构师 Chet Ramey 维护,Ramey 同时还负责维护 Bash shell;这两个项目都是由一位名叫 Brian Fox 的自由软件基金会员工在 1988 年开始编写的,但从 1994 年左右开始,Ramey 一直是它们唯一的维护者。

Ramey 通过电子邮件告诉我,Readline 远非一个原创的想法,它是为了实现 POSIX 规范所规定的功能而被创建的,而 POSIX 规范又是在 20 世纪 80 年代末被制定的。许多早期的 shell,包括 Korn shell 和至少一个版本的 Unix System V shell,都包含行编辑功能。1988 年版的 Korn shell(ksh88)提供了 Emacs 风格和 Vi/Vim 风格的编辑模式。据我从手册页中得知,Korn shell 会通过查看 VISUALEDITOR 环境变量来决定你使用的模式,这一点非常巧妙。POSIX 中指定 shell 功能的部分近似于 ksh88 的实现,所以 GNU Bash 也要实现一个类似的灵活的行编辑系统来保持兼容,因此就有了 Readline。

Ramey 第一次参与 Bash 开发时,Readline 还是 Bash 项目目录下的一个单一的源文件,它其实只是 Bash 的一部分;随着时间的推移,Readline 文件慢慢地成为了独立的项目,不过直到 1994 年(Readline 2.0 版本发布),Readline 才完全成为了一个独立的库。

Readline 与 Bash 密切相关,Ramey 也通常把 Readline 与 Bash 的发布配对,但正如我上面提到的,Readline 是一个可以被任何有命令行界面的软件使用的库,而且它真的很容易使用。下面是一个例子,虽然简单,但这就是在 C 程序中使用 Readline 的方法。向 readline() 函数传递的字符串参数就是你希望 Readline 向用户显示的提示符:

#include <stdio.h>
#include <stdlib.h>
#include "readline/readline.h"

int main(int argc, char** argv)
{
    char* line = readline("my-rl-example> ");
    printf("You entered: \"%s\"\n", line);

    free(line);

    return 0;
}

你的程序会把控制权交给 Readline,它会负责从用户那里获得一行输入(以这样的方式让用户可以做所有花哨的行编辑工作),一旦用户真正提交了这一行,Readline 就会把它返回给你。在我的库搜索路径中有 Readline 库,所以我可以通过调用以下内容来链接 Readline 库,从而编译上面的内容:

$ gcc main.c -lreadline

当然,Readline 的 API 比起那个单一的函数要丰富得多,任何使用它的人都可以对库的行为进行各种调整,库的用户(开发者)甚至可以添加新的函数,来让最终用户可以通过 ~/.inputrc 来配置它们,这意味着 Readline 非常容易扩展。但是据我所知,即使是 Bash ,虽然事先有很多配置,最终也会像上面的例子一样调用简单的 readline() 函数来获取输入。(参见 GNU Bash 源代码中的这一行,Bash 似乎在这里将获取输入的责任交给了 Readline)。

Ramey 现在已经在 Bash 和 Readline 上工作了二十多年,但他的工作却从来没有得到过报酬 —— 他一直都是一名志愿者。Bash 和 Readline 仍然在积极开发中,尽管 Ramey 说 Readline 的变化比 Bash 慢得多。我问 Ramey 作为这么多人使用的软件唯一的维护者是什么感觉,他说可能有几百万人在不知不觉中使用 Bash(因为每个苹果设备都运行 Bash),这让他担心一个破坏性的变化会造成多大的混乱,不过他已经慢慢习惯了所有这些人的想法。他还说他会继续在 Bash 和 Readline 上工作,因为在这一点上他已经深深地投入了,而且他也只是单纯地喜欢把有用的软件提供给世界。

你可以在 Chet Ramey 的网站上找到更多关于他的信息。

喜欢这篇文章吗?我会每四周写出一篇像这样的文章。关注推特帐号 @TwoBitHistory 或者订阅 RSS 来获取更新吧!


via: https://twobithistory.org/2019/08/22/readline.html

作者:Two-Bit History 选题:lujun9972 译者:rakino 校对:wxy

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

使用有效沟通的一些基本原则可以帮助你创建与你的品牌一致的、编写良好、内容丰富的项目文档。

在开始实际撰写又一个开源项目的文档之前,甚至在采访专家之前,最好回答一些有关新文档的高级问题。

著名的传播理论家 Harold Lasswell 在他 1948 年的文章《 社会中的传播结构和功能 The Structure and Function of Communication in Society 》中写道:

(一种)描述沟通行为的方便方法是回答以下问题:

  • 说什么
  • 在哪个渠道
  • 对谁
  • 有什么效果?

作为一名技术交流者,你可以运用 Lasswell 的理论,回答关于你文档的类似问题,以更好地传达你的信息,达到预期的效果。

谁:谁是文档的所有者?

或者说,文档背后是什么公司?它想向受众传达什么品牌形象?这个问题的答案将极大地影响你的写作风格。公司可能有自己的风格指南,或者至少有正式的使命声明,在这种情况下,你应该从这开始。

如果公司刚刚起步,你可以向文件的主人提出上述问题。作为作者,将你为公司创造的声音和角色与你自己的世界观和信念结合起来是很重要的。这将使你的写作看起来更自然,而不像公司的行话。

说什么:文件类型是什么?

你需要传达什么信息?它是什么类型的文档:用户指南、API 参考、发布说明等?许多文档类型有模板或普遍认可的结构,这些结构为你提供一个开始的地方,并帮助确保包括所有必要的信息。

在哪个渠道:文档的格式是什么?

对于技术文档,沟通的渠道通常会告诉你文档的最终格式,也就是 PDF、HTML、文本文件等。这很可能也决定了你应该使用什么工具来编写你的文档。

对谁:目标受众是谁?

谁会阅读这份文档?他们的知识水平如何?他们的工作职责和主要挑战是什么?这些问题将帮助你确定你应该覆盖什么内容,是否应该应该涉及细节,是否可以使用特定的术语,等等。在某些情况下,这些问题的答案甚至可以影响你使用的语法的复杂性。

有什么效果:文档的目的是什么?

在这里,你应该定义这个文档要为它的潜在读者解决什么问题,或者它应该为他们回答什么问题。例如,你的文档的目的可以是教你的客户如何使用你的产品。

这时,你可以参考 Divio 建议的方法。根据这种方法,你可以根据文档的总体方向,将任何文档分为四种类型之一:学习、解决问题、理解或获取信息。

在这个阶段,另一个很好的问题是,这个文档要解决什么业务问题(例如,如何削减支持成本)。带着业务问题,你可能会看到你写作的一个重要角度。

总结

上面的问题旨在帮助你形成有效沟通的基础,并确保你的文件涵盖了所有应该涵盖的内容。你可以把它们分解成你自己的问题清单,并把它们放在身边,以便在你有文件要创建的时候使用。当你面对空白页无从着笔时,这份清单也可能会派上用场。希望它能激发你的灵感,帮助你产生想法。


via: https://opensource.com/article/20/9/project-documentation

作者:Alexei Leontief 选题:lujun9972 译者:geekpi 校对:wxy

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

Windows 上的 Linux 正在继续发展,功能越来越强大。现在,图形化的 Linux 程序正在被整合到 WSL 中。

在微软 Build 2020 虚拟开发者大会上,微软 CEO 萨提亚·纳德拉宣布 Windows 的 Linux 子系统(WSL)2.0 即将支持 Linux GUI 和应用程序。现在这一天比以往任何时候都要近。在最近的 X.Org 开发者大会(XDC)上,微软合作伙伴开发者负责人 Steve Pronovost 透露,微软已经可以在 WSL 中运行图形化的 Linux 应用。

一直以来,虽然都可以在 WSL 上运行 GIMP 图形编辑器Evolution 电子邮件客户端LibreOffice 等 Linux 图形程序,但这并不容易。你必须安装一个第三方 X Window 显示服务器,比如 Windows 10 中的 VcXsrv Windows X Server,然后对 Windows 和 Linux 做一些调整,让它们顺利地一起工作X Window 系统几乎是所有 Linux 图形用户界面的基础。

现在,微软已经将 Wayland 显示服务器移植到 WSL 中。Wayland 是最流行的 X Window 兼容的显示服务器。在 WSL2 中,它通过远程桌面协议(RDP)连接将图形化的 Linux 应用程序连接到主 Windows 显示器上。这意味着你可以在同一个桌面屏幕上同时运行 Linux 和 Windows GUI 应用程序。

Pronovost 解释道:

WSL 本质上是在 Windows 托管的虚拟机里面运行 Linux,我们将应用程序(控制台程序,现在还有 GUI 程序)整合回你的 Windows 桌面,这样你就可以在统一的体验里面同时运行 Win32 和 Linux 应用程序。由于 Linux 是在虚拟机中运行,我们不能运行期望直接访问 GPU 的原生 GPU 驱动程序(除非我们做一些类似于离散设备分配的事情,并将其中一个宿主机 GPU 分配给虚拟机......但那样宿主机将失去对该 GPU 的访问!)。有了GPU-PV(GPU 准虚拟化),我们基本上可以在 Linux 中投射宿主机 GPU,让 Linux 和 Windows 进程共享同一个物理 GPU,而不需要固定的资源分区。

微软 WSL 项目经理 Craig Loewen 在 Twitter 上补充道,使用第三方 X 服务器和内置 Wayland 服务器的关键区别在于。“你不需要启动显示服务器,我们会为你处理。”此外,它还带有“与 Windows 的完美集成”,例如投影和 Linux 图标支持。

Loewen 还表示,你可以在其中运行 Linux Web 浏览器。“我们还没有用完整的桌面环境(DE)对它进行充分测试,因为我们想先专注于运行经常被问及的应用,主要是 IDE(集成开发环境),这样你就可以在一个完整的 Linux 环境中运行这些应用,”他说。

不过,先别太兴奋。Loewen 继续说道:“我们还没有制定测试通道的时间表,不过,这项工作通常会在接下来几个月内提供给 Insiders 试用。”

微软将 Linux 整合到 Windows 中已经有一段时间了。四年前,微软推出了 WSL,将 Linux Bash shell 带到了 Windows 10 中。通过 Bash 和 WSL,你可以运行大多数 Linux shell 工具和流行的 Linux 编程语言。

随着时间的推移,Linux 更成为 Windows 桌面上的一等公民。多个 Linux 发行版,从 Ubuntu 开始,随后是红帽 Fedora 和 SUSE Linux 企业桌面版(SLED) 都进入了 Windows 商店。随后,微软用 WSL 2 取代了将 Linux 内核调用转换为 Windows 调用的 WSL 翻译层。这一更新是在精简版 Hyper-V 管理程序上运行的微软自己的 Linux 内核附带的。

最近,从 Windows 10 Insider Preview build 20211 开始,Windows 用户可以访问 Linux 文件系统。这包括访问 Windows 本身不支持的 Linux 文件系统,例如 ext4。这也意味着,如果你用不同的磁盘双启动 Windows 和 Linux,现在可以从 Windows 访问 Linux 文件。有了这个功能,你可以通过管理权限从 Windows 文件资源管理器和 PowerShell 窗口访问 Linux 文件。

按照现在的发展速度,我对 Windows 11 可能会运行在 Linux 之上的“疯狂”预测,也许会成为现实!

很多读过我们的技术文章评论的人都知道,每个技术问题的答案都是“切换到 Linux”。而如果你对 Linux 是什么以及它是如何工作的感到好奇,微软可以提供帮助。

如果你曾经经历过痛苦的 Windows 更新,或者不敢置信地看着你的 MacBook 慢到像爬行,并将其风扇切换到巨型喷气式飞机起飞模式,你知道有一个也只有一个答案来解决你的困境:“切换到 Linux”。

当然,我是开玩笑的,但如果你浏览一下这些技术评论,你会发现这个建议是认真的,有一支开源布道者大军定期宣讲圣莱纳斯的福音,以回应关于其他平台的哪怕是最模糊的相关新闻。

你知道吗?我认为那些评论者的观点是合理的。任何有志于了解现代计算环境的人都应该对他们经常使用的操作系统平台以外的平台有一些经验,因为今天你在 Windows、MacOS 和 Linux 中看到的很多东西都来自于相同的 DNA。

为了跟上 Linux 的新动向,我自己每隔一两年就会进行一次这样的练习。所以,想象一下我的惊讶吧,今年我能够在几分钟内搭建一个功能完善的 Ubuntu Linux 机器,而不干扰我当前的 Windows 10 设置。更令人惊讶的是,微软为此做了大部分的工作。

使这一切成为可能的魔法是每台运行 Windows 10 专业版或企业版的 PC 所包含的 Hyper-V 虚拟化软件。(对不起,Windows 10 家庭用户,如果你想玩这些,你得先升级)。用 Hyper-V 的“快速创建”陈列栏,只需点击几下就可以建立一个新的虚拟机,其中包括了独立的 Ubuntu 镜像,而且不是一个而是三个,包括新的 Ubuntu 20.04 版本。

Hyper-V 快速创建工具包括了三个 Ubuntu Linux 版本

最重要的是,这些自定义镜像能够在 Hyper-V 增强会话中运行,这意味着你可以选择自定义的显示分辨率,或者在全屏中运行,甚至跨越多个显示器,其性能接近于在裸机上运行的性能。在增强型会话中,你的虚拟机可以共享主机上的 Windows 剪贴板、本地存储和音频硬件。

一旦你把一切都弄好了,你就可以在全屏模式下启动 Ubuntu 虚拟机,并与它一起工作,就像 Windows 10 宿主机不存在一样。

唉,关于所有东西都能正常工作的那部分话并不是说说而已。好消息是,两年前的 Ubuntu 18.04.3 长期支持(LTS)版本工作得很完美,不需要任何操作。但两个较新的版本却让我欲哭无泪。我需要手动编辑一个受保护的 Linux 配置文件,然后才能让增强的会话在最新的 Ubuntu 版本(20.04)中工作,19.10 版本的虚拟机挂了好几次,至少需要重启十几次(包括几次硬重置)才能如期工作。

不过,在一切都结束后,我还是有了三个可以工作的虚拟机,让我对 Ubuntu Linux 中的新功能有了一个相当不错的印象。

  • 补充更新,2020 年 6 月 5 日。通过 Twitter,@Canonical 的 Ubuntu on WSL 和 Hyper-V 的开发布道师 Hayden Barnes 说,“我们知道 19.10 和 20.04 中的 xrdp bug。20.04 镜像将在即将到来的 20.04.1 LTS 更新中进行修补。19.10 已经接近 EOL,将被放弃。"
  • 补充更新 2,2020 年 10 月 1 日。20.04.1 LTS 桌面 Ubuntu 镜像于 2020 年 7 月 31 日发布,但截至 10 月 1 日,它还没有被整合到 Hyper-V 中的快速创建镜像中。

另外,正如我的同事 Mary Branscombe 所指出的那样,包括 Home 在内的所有版本的 Windows 10 都提供了对 Windows Subsystem for Linux(WSL)的访问,该系统在轻量级虚拟机中运行 Linux 内核,并且从 Windows 10 的 2004 版本开始,该系统已经全新升级为 WSL2。正如 WSL2 文档中明确指出的那样,这并不是传统的虚拟机体验,它最适合那些希望获得命令行体验并能够运行 Bash shell 脚本和 GNU/Linux 命令行应用程序的开发者。在 WSL2 环境中运行图形应用程序的能力已列入微软的路线图,应该会在 2020 年底或 2021 年初由 Windows Insiders 进行测试。

如果你想尝试在 Windows 10 中设置一个或多个 Ubuntu 虚拟机进行自己的实验,请看我的另外一篇文章。


via: https://www.zdnet.com/article/microsoft-helped-me-install-ubuntu-linux-on-my-windows-10-pc-and-its-actually-pretty-good/

作者:Ed Bott 译者:wxy 校对:wxy

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

近日,著名开源领袖、写出《大教堂与集市》的 ESR(Eric S. Raymond)撰文指出,微软的 Windows 可能最后会切换到 Linux 内核,成为一个保留 Windows 界面的 Linux。微软目前的主要收入来源于其云服务,而操作系统业务对微软来说,所能贡献的利润比例会越来越少。Windows 将来可能是运行于 Linux 内核之上的一个桌面环境和一个越来越薄的 Windows 兼容层 —— 以兼容原有的 Windows 二进制程序。

对于 ESR 的这个观点,老王是赞同的:

这些年来,随着云技术的发展,越来越多的操作系统厂商将业务重点从单机操作系统转向云基础设施。在这一点上,从著名的 Linux 发行版 Ubuntu 的发行商 Canonical 身上也可见一斑。

而另一方面,不说谷歌的 Chromebook 上运行的 Chrome OS,主流的操作系统 macOS 也早已针对 Apple 公司的硬件免费提供。在这种情况下,操作系统已经不是早些年的现金奶牛了。

从微软这几年发布的 Windows 的更新中屡屡出现严重问题所反映出的其内部质控环境的劣化,可见微软已经逐步减少了对操作系统部门的投入。因此,ESR 的这个预测可谓有一定的道理。

看来,我们终将能看到 Linux 打败 Windows 的一天,真正地、彻底地解决 “Ubuntu 第一号 bug”。或许,这不能称之为打败,相对于 Linux 在服务器领域、移动领域、高性能计算领域的高歌猛进,Linux 一直在桌面领域方面进展乏力,这应该说是 Linux 和 Windows 的融合更加合适。

以下是 ESR 的原文译文:

桌面战争的最后阶段?

在微软 Windows 操作系统最近的发展中,最令人感兴趣的两个发展是 Windows System for Linux(WSL)和他们将微软 Edge 浏览器移植到 Ubuntu。

对于那些没有注意到的人来说,WSL 允许未经修改的 Linux 二进制文件在 Windows 10 下运行。没有仿真层,没有中间层,它们只需加载就能运行。

微软开发人员现在正在 Linux 内核中提供功能来改进 WSL。而这指向了一个迷人的技术方向。为了理解其中的原因,我们需要注意到自 2010 年推出云服务以来,微软的收入来源是如何变化的。

在十年后,Azure 为微软提供了大部分的创收。Windows 的垄断地位已经成为一个旁观者,传统台式电脑(这是它唯一占据主导地位的市场)的销量在下降。相应地,花在 Windows 开发上的投资回报率也在下降。随着 PC 的销量持续下滑,它不可避免地将不再是利润中心,而变成业务的拖累。

从冷血的利润最大化的角度来看,这意味着继续开发 Windows 是微软宁愿不做的事情。相反,他们最好把更多的资本投入到 Azure 上 —— 据说现在 Azure 运行的 Linux 实例比 Windows 还多。

我们的第三个理由是 Proton。Proton 是一个仿真层,它允许在 Linux 上运行 Steam 上发布的 Windows 游戏。它还不够完美,但已经很接近完美了。我自己就用它在这个巨兽上玩《战舰世界》。

对于游戏而言,它们是对 Windows 仿真层最苛刻的压力测试,比商业软件更苛刻。我们可能已经到了类似 Proton 的技术完全可以在 Linux 上运行 Windows 商业软件的地步。如果还没有,那我们很快就会实现。

那么,如果你是微软公司的战略专家,考虑到所有这些因素,利润最大化的前进道路是什么?

它会是这样:微软 Windows 成为 Linux 内核上的 Proton 一样的模拟层。随着时间的推移,这个层会越来越薄,因为更多的支持会落在主线内核源代码上。而经济上的动机是,由于需要在公司内部完成的开发成本越来越少,因此微软可以减去越来越多的开发成本。

如果你认为这是天方夜谭,那你可以再思考一下。证明这已经是(微软的)计划的最好证据是,微软已经将 Edge 移植到 Linux 下运行。这只有这种方式是有意义的:那就是作为一个试运行,让 Windows 实用程序套件的其他部分摆脱对任何仿真层的依赖。

所以,这一切指向的最终状态是。新的 Windows 将主要是一个 Linux 内核,在它上面有一个旧的 Windows 仿真层,但 Edge 和其余的 Windows 用户空间实用程序并不使用仿真。仿真层是为了游戏和其他传统的第三方软件而存在的。

经济上的压力会让微软取消仿真层。部分原因是它完全是一个成本中心。部分原因是因为他们想降低运行 Azure 的复杂性成本。 Windows/Linux 每一点融合都有助于实现这一点 —— 可以减少管理和预期的支持费用。

最终,微软将会宣布结束对 Windows 的仿真。操作系统本身,以及它的用户空间工具,一段时间后,会在一个精心保存的旧 Windows 用户界面下成为 Linux。第三方软件供应商会停止发布 Windows 二进制文件,转而采用原生 Linux API 的 ELF 二进制文件……。

……而 Linux 终将赢得桌面战争,不是通过取代 Windows,而是通过合作。也许这一直是它必须要做的事情。

开源法规对成功有不同寻常的要求。一起来了解开源组织的律师如何帮助其雇主找到可行路径。

正如我在这个分为两部分的系列文章的第一部分中所分享的那样,我是 红帽公司 Red Hat 的一名开源律师。我工作中的一个重要部分是向其他公司(包括其内部法律顾问)提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息,并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后,这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织,他们也经常询问我如何改善他们的做法,以便更熟练地为其组织的雇员提供开源法律咨询。在这两篇文章中,我将分享我通常在这些主题上告诉内部法律顾问的那些内容。

总是要找到一条可行路径

我的雇主红帽公司在使用开源软件方面的独特之处在于,我们的开发模式始于具有数千名贡献者的开源社区,并产生了经受过尝试、测试和信任的最终产品。更具体地说,通过我们独特的开发模式,我们从社区创建的开源软件开始,并在每个项目的基础上加强安全性,修复错误,修补漏洞并添加新功能。然后,我们将这些改进回馈给每个项目,以便使整个开源社区受益。此方法的效用非常重要,包括:

  1. 通过内部团队与组织外部其他人之间的协作来利用外部创新;
  2. 当现有或潜在的社区与您在同一问题上开展工作而且能够合作时,可以避免您自己开发和维护开源解决方案的成本和效率低下的问题;
  3. 通过与合作伙伴和上游项目社区的富有成效的合作,能够避免维护主项目下游分支的昂贵代价。

    • 一些公司发现创建上游代码的非公共分支很诱人,因为它是解决特定 用例 use case 的快速方法,或者因为它们不愿意在社区中进行协作。然而,由于增加的开发成本、互操作性损失和其他原因,这种分支的长期维护负担可能是令人望而却步的。相比之下,将开发集中在原始上游社区中,可以在所有参与者之间分担开发成本。

除少数例外(例如红帽公司)外,大多数使用开源软件的组织可能都拥有专有软件许可模式(或与 SaaS 等效的概念),并在其业务中对专有软件进行许可。这些组织认为他们拥有可以提供某些竞争优势的软件组件,并且不希望看到这些组件在开源条款下对其他人可用。这是可以理解的。但是,我会鼓励任何咨询此类问题的开源律师来敦促其客户采用开源开发模式,尤其是对于所有无差异且通用的软件。

例如,如果您的公司开发了用于手机的应用程序,并且您需要一个软件模块来读取和写入 PNG 图像文件,那么使用 GitHub 上流行的开源 PNG 软件模块之一将便宜得多。对于您的业务而言,对 PNG 图像进行编码和解码可能是无差别的,那么为什么要花费宝贵的工程时间来编写自己的版本?此外,为此功能编写自己的模块也可能会导致与使用常用开源模块的其他软件的兼容性问题。这是为什么呢?尽管您的模块和开源模块可能已被编写为对已发布的 PNG 规范进行编码和解码,但有时对规范的解释可能会有所不同,也可能会出现实施错误。使用同一模块执行此功能的每个人都可以确保大多数用户的兼容性,并降低开发和维护成本。

还必须意识到,您可能需要某些软件来保持专有性,并且不受开源条款的约束。取决于您系统的软件体系架构和所使用的开源许可证,除非采取某些措施(超出本文的范围),否则打算保留专有权的软件代码可能会受到开源许可证条款的约束。在这里向客户提供一些有关许可证选择和体系架构的咨询服务将变得很有用。

寻找灵活的解决方案

之前主要许可专有软件的组织逐渐增加了对开源软件的使用,但审核和批准的要求可能会增长(以我的经验甚至成倍增长)。由于资源限制,这样的组织可能会陷入困境。下面介绍了一些可以采用的灵活的解决方案。

授权并委托他人

律师不能也不应成为看门人。那样效率低下,并且肯定会导致开发和发布时间出现瓶颈,从而产生挫败感和收入损失。相反,应将审批权限授予产品或项目管理和工程领域有能力的个人。这可以让组织有效地保持灵活性。对客户进行教育(请参阅下一节)对于成功实现这一点至关重要。

我采用的一种方法是为整个工程组织提供开源培训,以便他们可以进行基本的许可模式和体系架构选择,同时为软件开发人员提供更专业的培训,以使他们能够提供更复杂的指导和决策。也要考虑在每个级别上对权限进行明确限制,包括哪些类型的问题和决定必须上报给作为他们开源律师的您。您组织的特定授权级别将取决于您团队在开源方面的经验以及对某些开源问题的敏感性。

教育客户

我发现培训是将您的组织迁移到更具开源意识组织的最有效工具之一。培训您的软件工程师和产品经理至关重要。让我详细说明。

尽管您的软件工程师处在最前沿,并且通常可能对开源问题和软件许可非常了解,但是基于您组织的特定要求对他们进行培训仍然很重要。例如,您的公司可能只允许使用宽松的开源许可证,并且可能对其版权声明和源代码可用性有某些要求。为避免开发中出现随后必须纠正的问题(一种昂贵且耗时的实践),最好培训工程师最大程度地减少不当行为的可能性,尤其是在所有开发过程的开始时(请参阅下一节)。

产品经理也必须接受培训。在许多公司中,产品经理负责营销的经典四个环节(产品、价格、定位和促销),并负责产品从生到死的整个生命周期。产品经理工作的方方面面可能会受到使用开源软件的影响。出于上述相同的原因,了解使用开源软件的要求对他们很有用。此外,更重要的是,产品经理在组织中的重要影响,意味着他们通常能够对流程和政策进行必要的更改。产品经理可能会成为您针对“开放”进行流程变更的最强有力的拥护者之一。

早期发现

在开发过程快要结束时解决开源许可问题非常困难且成本很高。随着软件的发布日期临近,体系架构和开源软件模块都是已经选定且难以更改了。如果检测到问题,例如专有软件模块中嵌入的“左版”(copyleft)软件(当该专有模块无意受开源条款约束时),则在该开发阶段修改体系架构或模块可能非常困难且成本昂贵。相反,应该在开发过程中尽早进行架构分析和开源模块选择的过程,以便可以进行成本更低且更有效的更正。

开源法规的“奖励”

实践开源法规是一项有益的职业,因为它具有影响组织朝着“开放”方向发展的能力,这具有很大的好处。是否成功取决于您随着组织的成长和成熟而找到具备可行性和灵活性的解决方案的能力。


作者简介:Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 Red Hat 开源法务团队的资深商务法律顾问,还担任 北卡罗来纳大学 University of North Carolina 的兼职法律教授。在任职红帽公司之前,Jeffrey 曾担任 高通公司 Qualcomm 的专利和开源法律顾问。

译者简介:薛亮,集慧智佳知识产权咨询公司互联网事业部总监,擅长专利分析、专利布局、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。