没有比对象对象存储 s3 这些更适合的网盘了。
可靠性好，速度快，按量付费，有 API 无论备份还是分享都很方便。

以微信的尿性，只要敢这么用登录直接封号。解封需要好友输入银行卡号 /人脸识别辅助验证。

你要用 clash 就自己仔细阅读文档自己配置，网上流传的和各种鸡场托管的绝大多数都极度不安全。
另外不建议用任何闭源客户端，有被收编的风险。

@iceorange #22 结果“乱七八糟”哪里是主观感觉了，你的程序存在 race condition，运行的结果是不确定的，那就是乱七八糟啊。
同样，这个后果造成的影响就是多数情况正常工作，偶发性的突然出现无法连接、没有回收等各种问题（出现冲突时时运行结果本身就是不明确的）。当然很容易让用户非常困惑并且难以排查（复现）。
又看了下你这个 pid，你的程序可能会使用自己的 pid，也可能会使用目标程序的 pid，当然存在 pid 回收后再次分配导致你的名称冲突，进而因为缺乏原子性造成 race condition 。

当然也不是说没有原子性就一定会有问题，但你需要考虑各种不同的情况，子进程嵌套调用、不同方式调用、僵尸进程、被 kill 后未回收等，这是非常 error prune 的。

@iceorange #9 因为操作 iptables 不是原子性的，一个进程在添加 /删除规则的同时正好有其他进程也在添加 /删除规则，最终的结果就是乱七八糟。
我看了一下你是用 pid 区分链名，多数情况下应该没有问题，但要是恰好有回收的 pid 导致重复就会导致非常令人困惑且难以排查的 bug 。
另外你的大多数逻辑甚至连文件 IO 都不写代码而是用 shell 命令实现，与其把 shell 脚本嵌入到代码里，直接用 shell 脚本不方便吗？
解析命令行参数和信号处理同样可以用库。至于检查错误，shell 脚本检查 shell 命令的错误当然比 rust 容易。

@iceorange 想象一下用户用你的工具并发启动多个进程，多个进程同时操作 iptables 会怎样。
nftables 一大亮点就是提供了多个程序并发操作防火墙的原子性。
因为你的核心逻辑基本是 shell 命令实现的，每次都需要需要启动多个外部进程，开销不小。
既然用 shell 命令实现，为啥不用 shell 脚本呢。

还以为是又发明了什么新的魔法，一看是操作防火墙的。
而且是通过调用 iptables 命令操作，十分不合适。
没有原子性、性能也不好，并发启动很可能出问题。
正确的做法应该是通过 libnftnl 这样的库。
而且你这样没必要用 rust 啊，直接用 shell 脚本更合适。

第一反应 halt

cpp 目前支持最好的应该是 clangd 吧，要是不行那就没办法了。

@okampfer #12 snowpack 是基于 rollup 实现的，不启用优化的情况下使用 rollup 把依赖的包编译成一个个的 ESM 。
启用优化后则在这个基础上再使用 bundler 把这些 ESM 打包到一起。

https://github.com/snowpackjs/snowpack/blob/main/snowpack/package.json#L51

暂时忘掉你所知的 OOP 和命令式的编程语言，然后学一下 haskell 。

@xarthur 这个不是激励问题，被审查的内容难以大规模地传播。
对于来自外部的内容，可以容易地绕过审查获取。
对于来自内部的内容，即使可以容易地绕过审查获取，但因为难以大规模传播而缺少收益，进而作者不再创作，内容从源头上就被扼杀了。

说的没错，即使审查容易被绕过，其对人们对信息的获取也造成了极其显著的影响。

但我觉得更为严重和令人惋惜的是不是对外部信息的审查，而是内部的。
前者可以很容易的绕过，比如无法过审或被阉割的海外影视、游戏等，你仍然可以取得。
后者就可惜了，很多优秀的作品被从源头上扼杀，你无法通过任何方式取得。因为作者无法获得收益，本来会被创作出来的也不会存在了。

@okampfer 不是啊，snowpack 也绑定了 rollup 。
它用 rollup 把你引用的所有模块都编译成一个个 ESM，开发部署就可以直接饮用了。
然后提供 bundle 作为一种优化选项，以前是推荐 plugin-webpack，现在已经是内置 esbuild 了。并且无论用什么 bundler 配置都很简单，因为打包步骤分离，代码的转译预处理之类的都由 snowpack 做完了，bundler 只需要把编译好的一个个 ESM 打包到一起。