@Jirajine
不是 LTS 的 ubuntu ，难道 apt 仓库里的 chromium 就不是 snap 的了？
https://packages.ubuntu.com/mantic/chromium-browser 2310 版本里的 chromium 一样是 snap 版的壳。

再退一步，用 LTS 的版本就是为了能够长时间不升级，怎么到你这里就成了用 LTS 反而就该用更新的版本了？

再再退一步，你想某个整体系统长时间不升级，但是某些特定包更新，那也应该给用户自己选择。同时在 apt 仓库里维护一个版本，snap 提供另外一个版本，交给用户自己选择想要哪个版本，而不是强制推 snap 版。

第一条算什么槽点，多半是你自己哪里没搞对。

debian 从某个版本开始（可能是 Buster ），bash 的非 root 用户的 PATH 里不再包含 sbin 的路径。如果此时你直接通过`su`切换为 root 用户的话，PATH 路径就不会包含 sbin ，但如果是`su -`切换的话，PATH 就会包含 sbin 。

你在其他发行版上直接`su`过去能够找到多半是因为其他发行版默认加入了 sbin 到非 root 用户的 PATH 里。

snap 最让我反感的是 canonical 为了强推这玩意儿把 apt 仓库里的包换成了 snap 的。

说起来 canonical 的推的几乎全都被其他取代了 upstart vs systemd 、mir vs wayland 、unity vs gnome 、snap vs flatpak 。

@kidlj 让系统 bug 和后门不复存在不可能。能大量减少也许还有可能。
写一个程序，来判断另外一个程序有没有 bug ，这类问题最终是个停机问题，是不可解的。

AI 能做到的无非是和现在杀软的工作类似，能有多少的准确率预测出是否有 bug 。
而且对于一个 AI 算法来说，存在对抗样本，肯定会有人发明出能欺骗 AI 的后门代码的。

@yankebupt #37

各大发行版的官方包维护者已经是类似的机制了。要成为官方的包维护者，必须要得到一个甚至多个 sponsor 的支持才能让你加入。

然而这套方案在开发者身上显然不适用，开发者并没有必要非要让某个软件加入到你信任关系里。更直白一点就是，我写的代码你爱用不用，我又没求你用干嘛还要申请入伙。

这次的问题是，各大发行版的包维护者都无条件地信任了上游的代码，导致带后门的包进入了官方仓库，还好在进入 stable 之前被人发现了，从而限制了影响范围。

真要说解决这类问题的方案，估计也就只能增加包维护者的责任了。但实际上，很多包维护者和开源软件作者一样，本来就是志愿工作。以前成为了某个包的维护者，但是现在没太多精力 review 代码，导致后门悄悄溜进了下游。

局域网能正常连的那台机器和你从公网连的机器是同一台吗？

不是同一台的话估计是你没开密码认证，只开了公钥认证，而局域网的机器有公钥，公网机器没公钥。

我更喜欢加密的，因为中间可能有 CDN ，虽然 CDN 是可信中间人，但是多一层保险比没有好。

试试蓝牙？

不如作为一个使用 linux 的程序员，反过来思考为什么不喜欢 windows 。

在 windows 上遇到问题，搜索问题得到的解决方案通常是图形化的步骤，虽然有步骤，但你不知道你在做什么，为什么这么做，你只是重复着别人给你的过程。比如有时候遇到网络问题，无法打开网页之类的，如果在 windows 上，通常会让你点某个界面，然后重置一下网络。至于问题的原因出在哪，为什么这么做，根本一无所知。这种做法对计算机不熟悉的用户来说，是很合适的。但是对于程序员来说，这就让人难受了，作为程序员，你总会想知道是 DNS 问题还是路由问题又或者是其他什么原因导致的。

在 linux 系统上，即使不是每一方面都理解，但整体上你有掌控这台计算机的感觉。而在 windows 上，完全没有这样的感觉。所以我是无论如何都不会觉得所谓的 WSL 能提供任何 Linux 的体验的，因为 windows 无法掌控的那部分过于巨大完全无法忽略。

把身份调换一下，为什么一般用户没法适应 linux 。由于 linux 的用户大都是有基础知识的，并且相较于图形化界面，更愿意使用命令行来解决问题，加上碎片化的各种发行版，你搜索到的解决方案有时候还需要你根据实际情况修改一些参数。一个毫无相关知识的小白很难顺手使用 linux 。

看看 https://matrix.org/cdn-cgi/trace 显示的地址，看看是不是代理的地址。

了解一下 SPF/DKIM/DMARC 这几个机制是怎么工作的，然后手动检查邮件里一些重要的 header ，比如 Return-Path 、DKIM-Signature 、Authentication-Results 。如果这几个 Header 都没有，多半就是伪造的。

除了一些特殊情况，Return-Path 是表示邮件是从哪个邮件服务器发送过来的，这个地址有可能和 From 不是同一个地址。RFC 5321 要求 Return-Path 是最后一跳邮件服务器加上的，也就是你的邮件服务提供商。

一般来说，你的邮件服务提供商会通过 SPF 机制验证 Envelope From ，然后把 Envelope From 的地址填到 Return-Path 里。要注意的是，Envelope From （ SMTP 协议通信时使用的地址）和邮件里的 From header （邮件里的 header ，客户端显示的就是这个地址）是两个东西，因此一封信即使通过 SPF 验证，仅仅能保证 Return-Path 写的是真的，而不能保证 From 是真的。

DKIM-Signature 是这封邮件的签名，里面通常带有哪个域名给这封邮件签过名，来保证邮件的完整性。但也要注意的是，签名域名和 From 也可以是不同的。比如 DKIM-Signature 里签名的域名可以是 outlook.com ，而 From 的地址却是 [email protected] 这种毫不相关的地址，这种情况下，DKIM-Signature 只能保证邮件是由 outlook.com 这个域名签名过的，不能保证 From 就是真的。

SPF/DKIM 和 DMARC 结合一起使用，才能保证 From 的真实性。DMARC 有 Alignment 要求，要求 SPF 和 DKIM 里的域名和 From 对齐。

Authentication-Results 则包含了以上几种机制 spf 、dkim 、dmarc 的验证结果。

以上只是理论上，但实际上，我发现很多邮件服务提供商，都缺少相关的东西。比如 qq 邮件收到的邮件，偶尔就会少 Return-Path 这种重要的 header ，很多学校使用的 Coremail 邮件系统则是没有一封邮件会有 Return-Path 信息。