@baoshu #50 > 别人爱看不看
> 总是对有些人有帮助

我也没捂着别人眼说「不准看」「不准收藏」啊…… 不知道你想说什么。

> 不然我的帖子怎么可能有很多人收藏

我在这个帖子下还没有看到任何清晰的用例。且大部分人收藏多半出于「低价捡漏」的心态，或者不清楚免费证书和付费证书的区别。当然这些不是我能揣测到的，但我想说明的是 即使帖子客观上没多大帮助，也会有人收藏。所以，你说的和「推荐低价证书对 V 站个人用户有没有意义」没啥关系。

---

我也不打算就这个问题吵下去了，你我两人必定有一人对网安一知半解，完全鸡同鸭讲。等其他人来补充科普吧。

@xmumiffy #46 朋友，孤例不证啊，我们说的不是 全有或全无 而是 普遍现象。否则我要说「我所在的企业买证书和兼容性没一点关系」了……

@baoshu #45 > 我并没有说 兼容性是主要原因，也没有说安全是主要原因。

那就结了，没啥好吵的。

---

另外，「对企业花钱买证书的主要原因理解有问题」也不是我的落脚点，请你再回头看看 #31 我发的第一段话，结尾是：「所以说感觉（推荐低价证书）意义不大」。

我想说的实际上是：

1. 推荐低价证书意义对 V 站个人用户不大；
2. （但从你的阐述可以提出反驳「怎么不大？个人难道不需要考虑兼容性和安全吗」，所以）我再补充说明：你的理解有误，兼容性和安全 并不是企业买付费证书的主要原因，而是 [我说的 1.2.3. 点] 。

@xmumiffy 另外，如果你认为我的观点是「企业绝不可能因为兼容性问题买证书」，那你也没看明白在讨论什么。我以为我说的够清楚了……我再把 #35 的关键词复述一遍：

> 我说的是「你对企业花钱买证书的 [主要] 原因」理解有问题

@xmumiffy 你没有读完我的第二句话。我再复述一遍：

1. 当然可能你又要说「企业协调的方式就是购买兼容性更好的付费证书」，但这真是「主要」原因吗？
2. 每个企业都有下游 Windows 2000 大客户？这没办法解释为什么所有企业都不约而同都选择购买。
3. 所以兼容性的论点站不住脚。

@xmumiffy > 兼容性是针对用户的

对用户也没有任何区别啊，什么样的用户会 (1) 无法升级自己的极远古系统（比 XP 、Ubuntu 12.04 还老）；且 (2) 没有能力向上游提出协调 HTTP 的要求？个人用户不满足 (1)，企业客户不满足 (2)。什么场景才会遇到这种兼容性问题呢？

当然可能又要说「企业协调的方式就是购买兼容性更好的付费证书」，但这真是「主要」原因吗？每个企业都有下游 Windows 2000 大客户？这没办法解释为什么企业不约而同都选择购买。所以兼容性的论点站不住脚。

@baoshu > 企业花钱主要是兼容性和安全。你说的保险就是安全的范畴。

我是只针对前一点反驳。后一点本来你说得就模糊不清，就权当我帮你补充解释并确认了一下吧。

@baoshu #34 第一，你发的网页里清楚写了 Windows >= XP SP3 ，macOS >= 10.12 ，Ubuntu >= 12.04 ，我不觉得会有人用比这还老的服务器。退一万步，如果真的有企业需要运行更老的机器，那个年代的系统、软件基本都没有适配 HTTPS ，而因为 TLS 证书只能用于认证自己的域名，我想知道有什么因素让他们选择「花钱买更古老的 TLS 证书」而不是「给自家服务器开一个内网访问的 HTTP 端口」？总之，一定要选前者的覆盖面太小了，构不成主要原因。

第二，我说的是「你对企业花钱买证书的主要原因」理解有问题，不是对「 Let's Encrypt 兼容性好不好」理解有问题。你的回复不在一个频道上……

@baoshu #25 > 花钱的证书兼容性好点，安全一点

你的理解有问题。企业花钱买证书为的是 保险 和 售后服务。

保险：Let's Encrypt 之类的是免费，但同时意味着如果他们某天倒闭或者撤回所有证书，用户没有立场指责他们，毕竟没花一分钱。但如果是商业证书，交的注册费相当于签订合同时给付保险费，如果证书出现类似的情况，对方要负全部违约责任。

售后服务：有的商业 SSL 证书签发公司会提供售后服务，比如指导部署证书或者搭建网站。

还有一个不太重要的点是，付费购买方便了审计和会计。

---

但是这三点对个人都没有意义，而企业又不太需要省这一两块的成本，所以说感觉意义不大。

@w568w 漏了几个字，应为

Rust 是一坨屎，意义不明的垃圾发明，只要碰了这语言就是「魔怔人」「教徒」。上面所有认为 Rust 好写的用户都应该被出警

尝试过，很爽。但这里是 V 站，所以我要说

Rust 是一坨屎，意义不明的垃圾发明，你只要碰了这语言就是魔怔人、教徒，并且对上面所有认为 Rust 好进行出警

划重点：

为什么支持 Extension 这么困难：

> 开始动手之后发现，这的确是一个非常庞大的项目。普通的功能一般都是按周来计算或最多按月来计算的，而 Extension 这个功能得是按年来计算的。最终我们花了一年多的时间，才让 Extension 成功登陆了 Edge Android 平台。

为什么 Kiwi 停更：

> 对于 Arnaud 来说，这个项目经过几年维护已经趋于稳定，他不太想继续花更多精力只是在维护上面，而是想要尝试其他更有挑战性的项目。

为什么 Kiwi 给 Edge 官方站台：

> 我也将（实现 Extension ）这中间的很多辛酸历程都写在了上面的那篇文章里，[...] Kiwi 浏览器的作者居然也看到了这篇文章，并且就是因为这篇文章，巧合般地让 Kiwi 和 Edge 建立了联系。
> 现有的 Kiwi 用户怎么办呢？这时 Arnaud 想起了我之前写的文章，他认为 Edge Android 已经很好地支持了 Extension 功能，成功接过了 Kiwi 的接力棒。
> Kiwi 的这一突然声明把我们也搞了个措手不及。

给楼上补个链接： https://learnxinyminutes.com/zh-cn/go/

Go 本身简直太简单了，几个我初学时觉得比较迷惑的点：

- channel 的行为，select 和 context
- goroutine 的同步
- package 的组织方式
- 错误处理
- 数组和切片的差别
- interface 对象的类型擦除和泛型的实现方式

1. 要省电就上硬件 DSP 方案，但很难搞，需要底层框架支持，可以看这个： https://source.android.com/docs/automotive/voice/voice_interaction_guide/app_development?hl=zh-cn#dsp-hotword-detection

2. 没 DSP 的话有软件指令检测，文档也在上面链接里。缺点是还是需要底层框架支持，优点是不会一直占用麦克风，耗电稍微低一些

3. 底层框架也没有的话，就只能纯软件识别了，缺点就是会一直占用麦克风。方案看 #1 发的

很多人用了 Linux DE 才知道桌面占用还能这么低。

https://everybytecounts.org/