#82 SCO 与 IBM 之间的和解

Linux Unix 法律 版权 2021-08-31

开源中国上看到一篇资讯：《18 年后，起诉 IBM 盗用 System V 源码的 SCO 选择以 1425 万美元和解》, 提到 SCO 将要和 IBM 和解，只需要 IBM 向 SCO 托管人（SCO 早破产了，只剩这点官司一直拖着没有结束，根据美国破产法，由托管人代理）支付 1425 万美元。虽然他们继续坚持自己的立场，但是最后都认为这一次的和解协议是符合双方最大利益的，实在是心累，不愿再继续到下一个十年。
这一次总算把这片狗皮膏药彻底给撕掉了，SCO 也可以安心的死去了，Linux 基金会也可以摆酒庆祝一下了。

开源界两件最大的纠纷就是 AT&T Unix 和和这次的 SCO Linux，并且这两个纠纷有很大的渊源。

前者源自 AT&T 管理层所做的一个愚蠢决定，为了一个自己根本不在乎的市场，向一个庞大用户群简单粗暴地发起一场战争。折腾十年（从 1984 年 AT&T 分拆之后向 BSD 提出版权要求，到 1994 年收购 AT&T Unix 资产的 Novell 与 BSD 和解）也没有获得任何好处，BSD 最后也只是做了一点简单的修改就算了事，而发起这场战争的 AT&T 却在官司结束之前，提前抽身去做别的事情去了。但这却直接导致了 Unix 市场长达十年的沉寂，以及 Linux 的诞生，或许 MS-DOS 以及后来 Windows 的诞生都与此有关（我相信如果有合法的、免费的 BSD 可用，IBM 不会选择 MS-DOS，微软可能也会作为一家 Unix 厂商继续经营自己的 Xenix）。

后者也是悬挂在 Linux 厂商头上的一柄达摩克利斯之剑。
SCO 发起诉讼的理由是，SCO 拥有 Unix 版权（可能是部分），IBM 向 Linux 贡献了大量代码，其中有一部分侵犯了 SCO 的版权（IBM 曾经和 SCO 联合开发 X86 架构的 Unix），从而 SCO 拥有 Linux 的部分版权。
不过时代变了，Linux 厂商与 SCO 的体量对比，相较于 AT&T 那会儿完全是反过来的。

SCO 先后多次发起对 Unix/Linux 厂商的诉讼，一旦获胜，就可以在巨大的 Linux 市场撕下来一块巨大的蛋糕。

  1. 最初的 SCO 是一家美国软件公司，因其 Unix 业务而知名。
  2. SCO 一开始是专注于 Unix 的 X86 架构移植
  3. Xenix 是微软开发的 Unix 系统，后来以技术入股的方式，将 Xenix 转让给了合作伙伴 SCO 公司（25% 股份）
  4. SCO 还收购了 UnixWare
  5. SCO 整合手上的 Unix 资源，开发了 SCO Unix，后来又改名为 SCO OpenServer（现在还活着，由 Xinuos 所有，改成基于 FreeBSD）。
  6. SCO 将 Unix 业务（可能包括 SCO 这个名字）出售给了 Caldera Systems，然后就改名了。
  7. 后来，Caldera 更名为 The SCO Group，破产之后又更名为 The TSG Group (后面再提到 SCO 都是指这家公司)。
  8. SCO 的主要业务就是像各大 Linux 厂商发起诉讼
    PS: 一度穷得差点没钱发起诉讼，微软立即宣布花 1300 万美元购买 SCO 许可

SCO 对很多大公司发起了诉讼，包括：

  1. SCO 起诉 IBM：IBM 向 Linux 贡献的代码是否侵权？
  2. Red Hat 起诉 SCO：红帽要求法院禁止 SCO 发起对 Linux 版权的诉讼，被驳回。
  3. SCO 起诉 Novell：Novell 曾经将 Unix 资产打包买给了 SCO，这次的争议是，那一次出售的范围是否包含 Novell 从 AT&T 那里获得的 Unix 版权。最后 SCO 败诉，法院判决 Novell 拥有他那一部分 Unix 版权（后来连带着 Unix 商标一同移交给了 The Open Group）。这个判决直接导致 SCO 在之后的其他官司中胜率大幅降低，可能美国的司法机关也有自己的倾向性，不希望 IT 界遭到重创。

参考资料与拓展阅读

#81 wget 下载时使用正确的文件名

Linux wget 2021-08-31

wget use correct filename when download

因为使用 wget 下载文件总是会使用 URL 最后一串字符作为文件名，但这有时不是我们想要的，比如：

download?xxxxxxxxxxxxxxxxxx
index.html?xxxxxxxxxxxxxxxxxx

我查阅了 wget 的帮助文档，发现只有个 --trust-server-names 参数有点像，但是文档总说这个参数的作用是使用重定向 URL 的最后一段作为本地文件名，试验之后确实没啥变化。

然后仔细找了一下，发现了 --content-disposition，这个才对嘛，使用响应头的 Content-Disposition 字段作为文件名，试了一下，有效！

PS：不过文档中说这个选项是实验性的。
PS：我的 wget 版本是 1.21，根据官网上的信息，这是最新版本，不过我看到有一个命名为 wget2 的新版本正在开发中，支持 HTTP/2, HTTP compression, parallel connections, use of If-Modified-Since HTTP header, TCP Fast Open. 期待！！！

还有一个参数，有些时候或许有用：--restrict-file-names=windows,unix, 限制文件中出现操作系统禁止的特殊字符。mark 一下。

#80 flatpak

Linux flatpak 2021-08-29

flatpak 和 snap 是目前轻量级 Linux 应用程序虚拟化的两个主流方案。
PS: 还有一个存在很久的方案: AppImage，一直不温不火的存在着。

所谓 Application Virtualization，就是给应用程序弄一个标准的执行环境，屏蔽下面各种发行版的差异。他们采用的技术或许有相通的点，也可能完全不一样，我也没有深入研究。

我感觉这是大趋势，最后可能会出现一个像类似 Google Play、 Apple Store, Windows Store 这种东西，统一 Linux 应用分发市场。当然，这会涉及了很大的利益，谁都想能获得这个市场的主导权，所以这里面的斗争可能很难出最后结果。

flatpak 来自红帽，snap 来自 Ubuntu，两种方式目前都没有能够有足够的话语权（可能他们都不能走到最后，被别的新方案淘汰）。我比较看好 flatpak，毕竟红帽的技术实力在那里，大部分技术都是红帽在推动，相比较而言，Ubuntu 多次想把自己的技术推广出来都是失败。

可能是因为我用的 Ubuntu 的缘故（默认就有一些应用是 snap 安装），感觉好像 snap 出镜率比较高，但我有几次使用 snap 的经历，每次都不是很舒服，最后都是狼狈的回退（和我尝试过 homedrew 体验一样糟糕）。flatpak 我这还是第一次使用。因为今天看到新闻说 GNOME 推出了 , 里面都是一些精选的 Flatpak。

#79 使用 nohup 的一个小问题

Linux Shell nohup 2021-07-22 
function fq () {
    # ...
    nohup qv2ray &>> /tmp/qv2ray.log &
    # ...
}

每次关闭终端，qv2 就一起崩溃了。

然后我改成：

nohup sh -c "qv2ray &>> /tmp/qv2ray.log &"

就好了。

分析：可能是后面日志和改后台运行的部分被 nohup 拿走的缘故吧。

#78 scp 拷贝文件引发的一次故障

Linux scp 2021-07-15

背景：有一个服务会定时读某个目录下的文件，然后逐个进行处理。

今天出于某些原因，我通过 scp 拷贝文件到那个目录下，结果意外的发现服务挂掉了，就是因为读到了一个空文件，抛出一个没有被处理的错误。

我知道这是程序设计上存在的一个缺陷，但之前我们一直通过 rsync 在传输文件，从来没有遇到过这样的问题。

我查了文档并进行了实验，确认了 rsync 会在文件传输时创建一个 .文件名.随机串 的临时文件，然后在传输完成后重命名。而 scp 则不会这样做，它会创建空文件，然后逐渐填充内容。

If the target file does not yet exist, an empty file with the target file name is created, then filled with the source file contents. No attempt is made at "near-atomic" transfer using temporary files.

我的理解是，文档里面说的 near-atomic 应该就是指 rsync 那种模式，而 atomic 的意思应该是指连临时文件都不用创建的模式。也不知道有什么文件系统支持这种模式。

#76 网卡名称的变迁（ethX -> enpXsY）

计算机网络 Linux 2021-03-15

早几年前，Linux 系统的网卡名称都是 eth0、wlan0，后来都变了个风格，就拿我的电脑举例：enp7s0, wlp6s0。
这到底是是什么原因呢？
最近突然好奇，去查了资料才知道为什么。
在 Fedora 的技术资料中找到，这个和 Systemd 有关，然后又在 freedesktop 官网 Systemd 的手册中找到了详细的说明。
现在的命名方案有好长一段，估计要看个半个小时（如果感兴趣可以仔细阅读一下），解开我的疑问却不需要那么复杂。

#74 使用 jq 命令解析 JSON 数据

Linux 开发工具 jq JSON 2021-03-04

JSON Logo

jq 是我在命令行中解析 JSON 的一个常用工具，用起来非常顺手。

  • https://github.com/stedolan/jq
  • https://stedolan.github.io/jq/

用法

curl https://24pullrequests.com/users.json | jq

# 取第一个元素
curl https://24pullrequests.com/users.json | jq '.[0]'
# 取第一个元素的指定字段
curl https://24pullrequests.com/users.json | jq '.[0].nickname'

# 切片
curl https://24pullrequests.com/users.json | jq '.[:2]'

# 遍历
curl https://24pullrequests.com/users.json | jq '.[] | .nickname'

# 取字段
curl https://24pullrequests.com/users/changeworld.json | jq .nickname

# 取多个字段
curl https://24pullrequests.com/users/changeworld.json | jq '.nickname,.contributions_count'

# 获取列表长度
curl https://24pullrequests.com/users.json | jq length

# 列出 Keys
curl https://24pullrequests.com/users/changeworld.json | jq keys
curl https://24pullrequests.com/users/changeworld.json | jq "keys[]"
curl https://24pullrequests.com/users.json | jq ".[0] | keys[]"

# 列出 Keys 和 值类型
cat a.json | jq ".[0] | keys,map(type)"
cat a.json | jq ".[0] | to_entries | map([.key, (.value | type)])"
cat a.json | jq '.[0] | to_entries | map("\(.key) : \(.value|type)")[]'

还有很多更强大的用法，可以参考文档，我就会上面几个，在命令行中简单搜索 JSON 也够用了。

刚在文档中学会一招，重新组合 JSON：

curl https://24pullrequests.com/users/changeworld.json | jq '[.nickname, .organisations[].login]'
curl https://24pullrequests.com/users/changeworld.json | jq '{name:.nickname, orgs:[.organisations[].login]}'

👍🏻 Nice!!!