#623 vCard (.vcf)
开发者 vCard 2021-09-01VCF 是 Virtual Contact File 的简写，虚拟通讯录文件
PS：.vcf 后缀还有一个含义是 Variant Call Format，用在基因生物学方面。
#622 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 市场撕下来一块巨大的蛋糕。
- 最初的 SCO 是一家美国软件公司，因其 Unix 业务而知名。
- SCO 一开始是专注于 Unix 的 X86 架构移植
- Xenix 是微软开发的 Unix 系统，后来以技术入股的方式，将 Xenix 转让给了合作伙伴 SCO 公司（25% 股份）
- SCO 还收购了 UnixWare
- SCO 整合手上的 Unix 资源，开发了 SCO Unix，后来又改名为 SCO OpenServer（现在还活着，由 Xinuos 所有，改成基于 FreeBSD）。
- SCO 将 Unix 业务（可能包括 SCO 这个名字）出售给了 Caldera Systems，然后就改名了。
- 后来，Caldera 更名为 The SCO Group，破产之后又更名为 The TSG Group (后面再提到 SCO 都是指这家公司)。
- SCO 的主要业务就是像各大 Linux 厂商发起诉讼
PS: 一度穷得差点没钱发起诉讼，微软立即宣布花 1300 万美元购买 SCO 许可
SCO 对很多大公司发起了诉讼，包括：
- SCO 起诉 IBM：IBM 向 Linux 贡献的代码是否侵权？
- Red Hat 起诉 SCO：红帽要求法院禁止 SCO 发起对 Linux 版权的诉讼，被驳回。
- SCO 起诉 Novell：Novell 曾经将 Unix 资产打包买给了 SCO，这次的争议是，那一次出售的范围是否包含 Novell 从 AT&T 那里获得的 Unix 版权。最后 SCO 败诉，法院判决 Novell 拥有他那一部分 Unix 版权（后来连带着 Unix 商标一同移交给了 The Open Group）。这个判决直接导致 SCO 在之后的其他官司中胜率大幅降低，可能美国的司法机关也有自己的倾向性，不希望 IT 界遭到重创。
参考资料与拓展阅读
#621 社会底层的话语权
个人 2021-08-31
知乎上刷到一个视频《在国产剧中，穷人已经被消灭了》，其中心思想非常符合我的观点，让我产生想说几句的冲动。
在过去讲求阶级斗争的年代，中央对文艺工作的领导非常重视所谓社会主义文艺发展，文艺作品非常讲求 “人民群众” 这个点。毛泽东就曾批评文化部过于注重过去封建王朝和国外资本主义的作品，不如更名叫 “帝王将相部”、“才子佳人部”，或 “外国死人部”。改革开放之后，社会的发展从 “以阶级斗争为纲” 转向到以经济建设为中心。政府对文艺工作的领导也随着改革松绑了，市场化了。
但可能是受体制或者老一派文艺工作者的影响，我在以前中小学时期看过的一些电影、电视剧也很多都是关于普通人的生活。后来慢慢的，国产电视剧、电影中的主角好多都是是什么皇家、什么家族企业，至少也得是个公司高管，剧情也往往是是后宫争宠、王子夺嫡、家产或企业控制权争夺之类，一般都经常让我感觉和自己的生活没有多大关联（有少数拍的还是不错，看的挺开心）。
不管什么剧，里面的人生活都锦衣玉食、纸醉金迷的，看起来很富足。用上面说的那个视频中的话来说，编剧和导演好像失去了对底层生活的想象力，连剧中设定的穷人 —— 家境不好的都市白领和学生 —— 生活看起来都远超我理解的普通老百姓平均生活水平，都住大房子，打扮时髦，光鲜亮丽（我好像不经意联想到了新亮剑《雷霆战将》，一个个有型兼靓仔就算了，李云龙的团部都搬到了小洋楼）。
为什么没有管控之后，文化领域自动又重新转向了王侯将相、才子佳人视角？
我想了下，应该是人之本性。普通的生活本来就过于平淡，人们就想看看别的风云人物的生活，看看皇帝到底是不是白面馍吃到饱、是不是在用金锄头种地，让自己也能在工作之余幻想一下，放松放松心情。
文艺作品本身就是阶层话语权的一部分。就好像美国的霸主地位和其文化输出能力也有很大关系。
所以，这里面有一个隐藏的小问题：谁为底层说话？
以前，我还在读书，第一次看到毛泽东的那个观点时，非常震惊，就好像发现了新大陆一样。因为我细想想之后发现好像确实是这么回事。古代的书上从来都是帝王将相的那些事，最多就是在诗歌中有描述劳动者的辛苦，关于有血有肉的普通人的生活好像没有提过，除了《金瓶梅》（在比较有知名度的书里面；从这个意义上来看，它的价值应该超过四大名著）。
底层人民的生活是不是不具备传播属性，不配出现在文艺作品中？
我也不懂啥，我也不知道应该是怎样，就觉得社会肯定是会朝着的更加公正、更加平等的方向发展。普通人的话语权肯定会越来越大，像现在这样，文艺领域被上层阶级的权谋宫斗占据也绝对不合理。
其实，又何止是文艺作品，新闻中也只会出现人民群众生活日益富足的报道，连领导视察的贫困户都让不少人羡慕。宣布全面脱贫之后，以后可能贫困户的新闻都看不到了。
我突然想到一个：现在普通人还是有话语权的，抖音和快手就挺不错的。很多学生或者都市白领（新时代的农民工）容易产生一个误区，他们的意见代表了最广泛的人民群众，其实不是这样，如果经常回老家看看的话，你会发现最广泛的人民群众在哪里（如果不被视为愚昧和落后而刻意忽视的话）。抖音和快手是我看到除了微信之外，使用最为广泛的 App，除了少数在使用老年机的长辈之外，几乎人都在用，很多长辈还一直有发布视频，相比较而言，微博的传播度都算小众产品了。
Update @ 2021-09-05
写完后回头想想，小时候看的电视里的普通人其实也不普通，不提大头儿子或者别的动画片里面小朋友家都有独栋别墅，至少没有人需要面临乡里摊派、计生委抄家、城管和税务抢劫。前两者由于当时我的年纪比较小，印象淡，城管和税务收保护费式的黑社会作风我可亲眼所见，记忆犹新。当时只要是有个人夹一个包出现在家里（我家开个小卖铺），自称某个部门工作人员，然后家里立即弥漫起一种恐怖的氛围，然后就是谄媚、巴结、拉关系。这些我可从来没有在电视上看到过，更别提我还见过多次城管当街打砸抢。现在的城管还是运动式的检查和收东西，不过不知道态度咋样，以及后面的处理流程是否合理。
《家有儿女》中的刘星、夏雨、夏雪也不会经常被小流氓抢劫，我就有多次这样的经历。
我又想起来，就在前两年，我亲眼见到有小区门口摆地摊的小贩因为没有交钱被一些身份不明的人（可能是流氓地痞）驱赶，扫黑除恶之后，可能他们现在不需要面临这些了吧，希望。
可能有些跑偏了，我说这一段不是抱怨生活中不如意的地方，或者放大社会黑暗面，我说的这些也只是普通人生活的极小一部分，我们有血有肉，有爱情，有亲情，有不如意，也有很多好玩的事情，我只是感慨普通人的生活没有机会被真实的、完整的表达出来。
#620 wget 下载时使用正确的文件名
Linux wget 2021-08-31wget 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 一下。
#619 Edge 语音朗读
Edge 浏览器 Chrome 语音合成 2021-08-29发现 Edge 浏览器邮件菜单中有一个 “大声朗读” 的选项，非常好用，读起来非常流利，远超我的想象，几乎不像是人工合成（之前那种水平的，磕磕绊绊的）。
在语音选项中可以看到，阅读中文的时候默认选中的是 Microsoft Xiaoxiao Online (Natural), 声音非常好听，爱了爱了。
我在 Chrome 92 中还没找到这个功能，但是我想应该有的，我记得看到有什么项目说是用到 Chrome 的语音引擎。
经过搜索我发现了原来有个 Web Speech 的东西，语音合成方面应该是在主流浏览器中都支持了，但 Chrome 为什么不像 Edge 一样把这个功能放在右键菜单中，方便朗读网页呢？
有两种可能：1. 调用操作系统模块有授权问题；2. Google 采用自家的网络服务方案，国内不可用。
W3C Web Speech API
- 语音识别 API (Speech Recognition)，目前只有 Chrome 支持
Demo: https://www.google.com/intl/en/chrome/demos/speech.html - 语音合成 API (Speech Synthesis)，需要操作系统的语音引擎支持，主流浏览器都支持
参考资料与拓展阅读
#618 flatpak
Linux flatpak 2021-08-29flatpak 和 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 推出了
#617 调整视频文件中音频流的顺序
视频处理 ffmpeg 2021-08-28ffprobe
ffprobe movie.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'movie.mp4':
Metadata:
major_brand : isom
minor_version : 1
compatible_brands: isomavc1
creation_time : 2020-02-20T06:07:54.000000Z
Duration: 01:43:14.16, start: 0.000000, bitrate: 2844 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1495 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)
Metadata:
creation_time : 2020-02-20T06:07:54.000000Z
Stream #0:1(und): Audio: ac3 (ac-3 / 0x332D6361), 44100 Hz, stereo, fltp, 448 kb/s (default)
Metadata:
creation_time : 2020-02-20T06:08:03.000000Z
Side data:
audio service type: main
Stream #0:2(und): Audio: ac3 (ac-3 / 0x332D6361), 44100 Hz, 5.1(side), fltp, 448 kb/s (default)
Metadata:
creation_time : 2020-02-20T06:09:02.000000Z
Side data:
audio service type: main
Stream #0:3(und): Audio: ac3 (ac-3 / 0x332D6361), 44100 Hz, 5.1(side), fltp, 448 kb/s (default)
Metadata:
creation_time : 2020-02-20T06:09:29.000000Z
Side data:
audio service type: main
ffmpeg
ffmpeg -loglevel info -i movie.mp4 -ss 00:29:08.0 -to 00:31:25.0 -s 1280x720 -c copy -map 0:v:0 -map 0:a:0 -map 0:a:1 -map 0:a:2 test.mp4
# 输入，复制，设置第一个音频流为默认，输出
# 发现其他几个音频流不见了，输出文件中只有一个音频流
ffmpeg -i movie.mp4 -c copy -disposition:a:1 default 冰雪奇缘2_new.mp4
ffmpeg -i movie.mp4 -c copy -map 0:v:0 -map 0:a:1 -map 0:a:0 -disposition:a:0 default -disposition:a:1 0 冰雪奇缘2_new2.mp4
解析：输入，复制（不重新编码），
-map 0:v:0
-map 0:a:1
-map 0:a:0
-c / -codec
-c:v
-c:a
-c:s
-c:d
[mp4 @ 0x556a8afca7c0] track 1: codec frame size is not set
ffmpeg -i test.mp4 -frames 1 -f image2 /tmp/image.png
#616 为什么我还没有用上 IPv6？
计算机网络 IPv6 2021-08-27- IPv6 是个好东西
- 我们都知道 IPv6 是个好东西
- 我们都想用上 IPv6
那么问题来了，为什么现在还没有大规模普及 IPv6 呢？我想了半天，得到了一个答案：因为我没做好准备。
确切的说，应该是：无数个我一样的人没有做好准备。
IPv4 很简单的一串数字，虽然世界上大部分人可能都不知道它是个啥，但肯定也存在相当比例能够理解这个概念的人，这对于一项技术的普及很有必要。
但是 IPv6，我作为一个开发者都说不清楚，更别提其他普通用户了。
#615 什么是一个设计良好的系统？
软件设计 2021-08-24
在满足需求、有良好的使用体验（基于真实的用户看法，不是开发者自己觉得）基础上，进一步提更高的要求：
- 接口响应超时
- CPU load 升高
- 内存
- GC 频繁
- 死锁
- 大数据量存储
一、三高（高可用 + 高性能 + 高并发）
1.1 高可用(可用性) Availability
可用性强调的是服务的总体持续时间，比如可用性级别为三个九（99.9%）意味着一年 365 天里总共停止服务 8.76 个小时。
可靠性 Reliability
- 功能如预期运行（宁可抛出异常，不要默默地给错误运行）
- 出现故障的频率
- 出现故障也应该不对系统造成太大的影响
- 可维修性：故障定位容易、修复步骤简单、修复成本低廉
和高可用的区别：
- 大部分时候，这两个指标都是密切相关的
- 如果我有一个电视机，每天都准时看儿童频道的《动漫世界》一个小时，然后过去三年也都用得挺好，没有送去修过（导致我看不了），那可以说高可用了（正常运行时间 / 预期运行时间），但是如果这个电视机每次看的时候可能隔一会儿需要拍一巴掌（中间出雪花的时间可以忽略），那这就不能说这个电视机是可靠了。
-
又比如说，我又买了另一个电视机，不需要拍巴掌了，我看的挺开心，不过才高兴两年，坏了，看不了了，楼下电器维修店的小哥搞不定，联系厂家售后维修，一下就是两周看不了电视。对于一个家用电器，两年坏一次可以说高可靠，但是可用性就有问题了（
(365 - 7) / 365 = 98%）。 -
MTBF Mean Time Between Failure 无故障时间，每隔多久遇到一次故障
- MTTR Mean Time To Repair 修复时间，每次遇到故障需要维修多久
-
MTTF Mean Time To Failure
-
根据当前的可用性级别，然后指定合理的可行性目标
- 操作规范/最佳实践
- 预防性维护 Preventive Maintenance
- 合理的 PM 计划：可实施，正确的时机
- 重点是影响最大的故障
- 不断的改进和优化
稳定性 Stability
- 系统运行平稳（不一定如预期执行）
连续性 Continuity
故障出现之后的处理能力：故障能否快速修复，能否不影响主要业务的运行。
比如我有两台电视机，坏了一台，我还有另一台可以看，虽然另一台是之前淘汰的一台黑白电视，效果差点，好歹能用啊。
这台电视就是我们常说的灾难备份，或者说容灾备份。
1.2 高性能 HP Performance
- 处理速度快
- 资源占用低
1.3 高并发 HC Concurrency
- 响应时间
- 吞吐量
- 并发用户数
二、安全性
- 基础设施安全：操作系统、网络、数据库
- 数据安全
- 脱敏：降低数据泄漏所产生的消极影响
三、易用性
四、其他
3.1 可测试性
3.2 可维护性
运维方便，运营方便，二次开发方便
- 代码注释与文档
- 合理的日志
- 监控与数据统计
- 误操作发生率低
- 可理解性：代码可读性，合理的技术框架/系统架构
- 可拓展性：新增功能不需要修改现有结构的能力。分层，合理的耦合度（尽可能的高内聚、低耦合），合理的功能抽象，数据结构可拓展
3.3 可伸缩性 Scalable/Scalability
在系统不需要修改（顶多改改配置）的前提下，通过增加或减少硬件资源来动态提升或降低系统各项能力。
- 通常采用服务器集群的方式。
- 集群一上来，就和高可用有很大关联。
3.4 可扩展性 Extensibility
通过合理的设计，使得新增功能时，不需要改动现有功能，或者只需要对现有系统进行少量调整就行。
总之，将新功能对现有业务逻辑的影响降到最低。
3.5 可观测性
能够方便快捷的了解到程序运行情况。
合理的日志，指标数据的暴露（Pull/Push）。
#614 Golang 学习资料
Golang 2021-08-24- 官方文档镜像：https://docs.studygolang.com/
- Golang PlayGround: https://play.golang.org/ (自动跳到 https://go.dev/play/)
- https://awesome-go.com/
- https://github.com/avelino/awesome-go
- https://github.com/jobbole/awesome-go-cn 中文版
- Go语言爱好者周刊
- 开源图书
- 《Go 入门指南》
《The Way to Go》中文版 - 《高效的 Go 编程》
《Effective Go》中文版 - 《Go语言标准库》
《The Golang Standard Library by Example》中文版 - 极客兔兔，七天用Go从零实现系列