@libook #114 更正一下，是两代三个人、三代五个人、三代更多人，反正就那个意思

再分享一个细节，我和老婆散步的时候，有的时候会一起哼歌，有的时候会观察一些路人、动物、植物，有时候会讨论一些问题。最近她对车标产生了兴趣，让我教她路上看到的每种车标是什么，然后下次遇到的时候考她。

老婆想散步，知道我喜欢宅在家里，于是跟我说不想去可以不去，我是觉得是陪老婆出去也就半小时，问题不大，于是绝大多时间都陪她出去。
她散步是有明确的时间计划，比如定好几点去散步，然后我可以灵活安排我的事情，最近几周散完步我俩会一起在家里用 NS 在电视上同屏玩 MC 。

两个人、三个人、两代五个人、三代更多人一起生活，肯定会有些变化，生活习惯也不得不去调整，当然也取决于你自己愿不愿意走出原来的舒适圈，去构建一个兼容新环境的新的舒适圈。

我是换电池频率低的就用一次性电池；换电池频率高的就用充电电池，比如 XBox 手柄；顺便说一下，XBox 手柄也是可以插线用的，我之前用 VR 玩精英危险，因为全程坐在电脑前玩（椅子精），所以索性插线用了，免得换电池。

用啥 RAID 方案，然后去看对应的 RAID 方案的 requirement ，要求内存大小。
然后再看看 PT 软件的 requirement ，要求多大内存。

@Shook #16 我目前在用的方案是在 Windows 上用 Cygwin 装 XServer ，然后在 WSL2 里跑 IDE ，用 Windows 上的 XServer 显示出来。

JetBrains 家的 IDE 在代码分析方面很无敌，可以在某种程度上“理解”代码，推导出大量没有被开发者显式声明的信息，用于检查问题、提供重构方案。

如果项目很简单，没必要用此种能力，可能也没必要用付费产品了。

拿来吃饭的家伙，既然你都用过了，那就都以你自己的体验为准，哪个顺手用哪个。

个人认为，核心问题在于类型和值通常是两种概念，且大多静态类型系统都预期开发者在声明类型的时候填的是类型，而不是值，比如严格来讲，x 的值是 10 ，但类型是 number ，TS 不认为类型“10”等价于值为 10 的 number 类型，就好比 10 平米面积不等价于底面积为 10 平米的体积。

如果非要这种特性的话，就得允许开发者不止在声明类型的地方写类型名称，而是可以写值，甚至表达式来算值，然后编译器负责按照值推算成对应的类型+值，再限制对应的类型，并额外增加限制对应的值。
这样会有个问题，类型系统就不止做类型校验的工作了，还杂糅了值校验的工作，就看语言的设计者和使用者是否接受这种设计了。

个人认为作为类型系统来说，做到类型校验就足够了，值校验本身就不是类型系统的份内事，真搞出来就应该不算“类型系统”了，而是另一种类型与值的复合系统。

HTTPS 是点对点加密，除了域信息意外其他的数据基本都是加密的，谁有域的证书谁就能解密，即通常在浏览器加密、在网站服务器解密。

网络数据是像包袱一样层层包裹的，HTTP 数据包被 TLS 包裹成为了 HTTPS 数据包，HTTPS 数据包又被包成了 TCP 数据包，然后再互联网上传输，视网络情况又会被包成其他数据包，这样层层包裹再层层拆开，最终网站服务器才会拿到 HTTP 的明文数据，反向传输也一样。

clash 、ss 是软件，实际上支持多种数据包协议，比如 Shadowsocks 协议、VMess 协议，更复杂的有 Vless 、Trojan 协议，它们实际上就是包裹皮，用来包任何它们支持的数据包格式。

题主假设的线路通常是这样工作的：
用户在浏览器 A 上访问一个网站域，这个域被指向 D 的 IP ，于是 A 就会用 D 的公钥把数据加密，确保只有数据包到了 D 才能被解密，中间任何一方都只能拿到除了域以外全都无法解密的信息；
然后因为 A 配置了代理，根据代理的协议（如 HTTP 、HTTPS 、Socks 等）把请求包一层发给 B ，如果这时候用的是 HTTPS 等加密协议的话，还能确保 A 与 B 之间任何一个环节都无法解密数据包内容；
B 收到后用代理的协议（如 HTTP 、HTTPS 、Socks 等）拆包，再拿自己的数据包协议（如 Shadowsocks 、VMess 、Vless 、Trojan 等）给这个数据包了一层，而且很可能又进行了一次加密，使得 B 到 C 中间任何一方都不能解密这个包的内容，并按照用户的配置发给机场的服务端 C ；
C 把收到的包进行解密和拆包，拆出 B 收到的那个包，然后按照域信息发给 D ；
D 收到数据包后进行解密和拆包，就拿到了 HTTP 明文请求，知道了客户端要访问哪个路径，按照自己的负载均衡策略转发给合适的 E ；
E 收到后，根据自己的配置来决定发给哪个 F ；
F 收到请求后执行实际的业务，或查找相应资源，把结果原路返回，首先返回给 E ；
E 再把数据包返回给 D ；
D 将数据包用之前与客户端协商好的临时密钥把数据包加密打包成 HTTPS 数据包，返回给 C ；
C 把收到的数据包再拿自己的数据包协议（如 Shadowsocks 、VMess 、Vless 、Trojan 等）进行打包和加密，发回给 B ；
B 将数据包解密、拆包，拿到 D 制作的 HTTPS 包，然后用代理的协议（如 HTTP 、HTTPS 、Socks 等）包一层，返回给 A ；
A 将包用代理的协议（如 HTTP 、HTTPS 、Socks 等）拆开，拿到 HTTPS 包，再将 HTTPS 包解密拆包，拿到 HTTP 返回数据，并提供给页面上的 JS 程序，或者直接呈现给用户看。

当然这其中我省略了 DNS 、HTTPS 协商、各级代理服务器为数据原路返回添加的地址信息等。


现在回答题主的问题：
1. A 到 B ，如果浏览器配置的是 http://127.0.0.1:7890 ，就说明走的是 HTTP 协议，如果配置的是 socks5://127.0.0.1:7890 就是走的 socks5 协议，据我所知这俩本身都是不加密的，也就是说中间任何人拿到这个数据包，是可以拿到 A 发出的内容的，但 A 到 D 走的是 HTTPS 协议，也就是这个代理包虽然可以直接被拆开看，但看到的是加密后的 HTTPS 包，只能看到 HTTPS 未加密的部分，比如目的地 D 的域信息（域名、端口号、协议）。
2. B 到 C 用的自己的数据包协议，如 Shadowsocks 、VMess 、Vless 、Trojan 等，通常都是自带加密的，Shadowsocks 、VMess 本身提供了加密功能，Vless 、Trojan 是把原来拿到的 HTTPS 数据包又套了一曾 B 到 C 的 HTTPS 数据包，都确保 B 到 C 之间任何拿到这个数据包的节点都没法解密内容，只能知道这个数据包是 B 发到 C 的。
3. A 到 D 、D 到 E ，甚至 E 到 F 都可以走 HTTPS ，用各自的密钥对加解密，HTTPS 是点对点加密，A 用 E 的公钥来加密数据，会保证 A 到 E 之间任何环节都无法解密数据，所以安全肯定是安全的；至于要放在 E 上还是 D 上，取决于是否信任 D ，以及技术架构上是不是放在 D 上更经济、高效、易于管理。

那个 Binding 插件是我所了解的最接近的了，如果这还满足不了的话，估计只能直接去用 JB 的产品了……或者动手能力强的话自己写插件甚至魔改 VS 源码。

要么尝试接受 VS 的使用习惯？再怎么改，毕竟不是 IDEA 。

我在 Google 上关闭了地理位置采集，也删除了所有地理位置历史，现在只能通过我搜索的内容来临时推断我的地理位置，然后我就在全世界乱窜了。

找到合适的人概率比较低，但多认识人总能命中。

我自己的 NAS 用的 Debian,开了自动打安全补丁，除此之外基本也就不动了。

桌面系统用的 Manjaro （ Arch ），感觉发行版的默认搭配比 Arch 稳定很多，自带桌面应用可以自动检查是否有软件包需要更新。

另外一台 Windows 上的 WSL2 ，以及 Android Termux 里，我都跑的 Arch ，日常习惯 yay 一下，yay 可以同时更新官方源和 aur 源的包。

洗……洗厕所？

貌似有很多传言说可乐可以用来清洁一些东西。

感觉是标题党……

看起来不像是 Linus 说的，感觉像是文章编辑者的 joke 。

今天刚试了试 Boxes ，感觉过于简陋，就卸载了，后来用 QEMU+Virt-Manager ，装了 Win10 ，感觉还不错。

当然也看你干嘛，如果想折腾直通啥的就折腾 QEMU/KVM ，要想傻瓜一点也可以 VirtualBox 、VMWare 。

一般都是异常断电才自启，正常关机不会自启，我有个用来做 NAS 的华擎主板就是这样的。

可以再研究一下 BIOS ，看有没有其他的自启选项。