@uni 你这就说反了，炒作和庞氏的时候才是机遇，落地应用稳定下来没有机会了。
很多人批判区块链和加密货币割韭菜，但他们忽视了“割韭菜”就像阳光、空气一样，是自然地存在于任何秩序体系中的固有特性。任何秩序体系下的个体都始终在被割韭菜，区块链是对现有秩序的挑战，从而存在抢到部分现有秩序体系下“割韭菜”者部分权利的机会。

@longxk 因为你这种用法不是 Arch 支持的，Arch 库里的 glibc 只保证兼容 Arch 仓库里的内核，至少是最新的 LTS 内核。而你的内核版本太低就不行了。
你用 LXC 这种共享宿主机内核的容器跑其他发行版也会遇到这种情况，只不过 Arch 内核更新稍微快一点点，内核太旧其他发行版也跑不了。

可以用 rebase -i ，或者对小白来说最万能的办法，reset 或 checkout 到最近的“正常”commit 点，然后把后面想要的 commit 的一个个 cherry-pick 上去。

说的虽然没错，但 Rust 也不是写什么都适合，可以接受 GC 且不想用开放速度换取软件质量的场景最好不要用 Rust （当然以上场景 C/Cpp 通常更痛苦），尤其是涉及 async ，async Rust 为了零开销抽象付出的代价太大了，任何可以接受开销的场景下基本都不适合。

Arch 是最简单的，想装什么装什么。不会捆绑 ufw 或 firewalld ，没有 selinux ，没有 apparmor ，没有 snapd 。以上这些你想要都可以装，但不会默认捆绑你不需要的组件搞复杂你的系统。
滚动更新不需要 dist-upgrade ，直接装就是基本最新稳定版，不用管多版本也不用手动装最新版。包管理也比 deb/rpm 简单（当然 alpine 的 apk 更简单，但 musl 会踩坑），仓库里常用命令行工具最齐全，虽然 bat/ripgrep 这些用户比较多的 Debian 之类也有，但更多的只有 Arch 库里有。Deb/rpm 系很多软件由官方支持，需要很多添加软件发行方的源，Arch 都是野的，直接装社区源就行。

把那些提 PR 的 fork 拉到本地 rebase/merge/cherry-pick 到自己的分支。

终端要性能好基本不能用 gui 框架，直接图形 API 裸写+硬件加速。
典型的如 kitty 、alacrity 等，还有个 https://wezfurlong.org/wezterm/
kitty 是 c/Python 混合，但不跨平台，后面两个是 rust 写的。

https://github.com/Eugeny/tabby
https://github.com/electerm/electerm

这两个 electron 写的 terminal 功能比较多

你可以发布二进制，并表明 GPL 许可，需要源代码者可以向你发邮件获取。
有人发邮件要代码的时候你可以把代码里的 constant 值变一变，每人发一份不一样的。如果发现有人违反协议倒卖就可以溯源了。

为什么要缓解 DNS 污染，DNS 污染的网站，难道你拿到正确的 IP 就能访问了？就算能访问，实名向运营商揭露你正在访问被 DNS 污染的网站是合适的做法？
如果用了代理，为什么不通过代理请求 DoT/DoH ？

自己用干脆自建 CA ，自己设备上信任自己的 CA 根证书。同样可以用 ACME 自动申请、续期，还不需要担心没有公网 IP 不能 http/tls challenge 申请证书的问题。

@shijingshijing 是的呀，trusted computing 从硬件开始 cryptographically 阻止 Root of Turst 以外的实体（比如购买了设备的最终用户）对系统的任何修改。
这种 trust chain 之下如果用户不被 trust ，那设备简直就是租的，而非拥有的。欧美国家反垄断应该立法使用 trusted computing 的设备必须 trust 购买者，或禁止各种应用在非 trusted 环境下拒绝工作的行为。
现在很多不能解锁的 Android 设备连内网私有 CA 签名的 HTTPS 服务都不能用，能解锁的很多应用也能通过 TEE 验证环境不可信从而拒绝工作。

@ryd994 当然，这样只能保证设备本身被篡改（变更证书等）后不会释放 key 。如果要保证设备被偷了也不能解密，那肯定得从外部输入 key （键盘、ssh ）。
即使这样也不能完全确保物理访问下的安全，要想不被物理 dump 内存，还是得连同硬件一起保护才行。

@ryd994 TPM 可信就可以构建 trust chain ，让整个系统都可信。BIOS 验证 bootloader ，bootloader 验证内核，内核验证 rootfs 。
一个最典型的例子是 Android ，Android 上的应用默认不会被 MITM （无需 ssl pinning ），这点可以由 TEE 保证。TEE 配合 bootloader 锁确保用户无法篡改 ROM ，而可信厂商（签名被信任）构建的 ROM 确保用户无法修改系统 SSL 证书。