jinliming2

@jinqzzz sort 有个比较特殊的点是，它必须一次性把所有内容都读入才能开始输出，因为有可能最后一行的内容被排序到最前面。在输出之前，内容都是要读到内存里的，处理大文件要足够的内存。
所以可以用一些方法来延迟 tee 创建输出流的时间，确保 sort 已经读取所有内容。
如果是 cat xxx | tee xxx 这样的，cat 是支持流式处理的，也就是读多少输出多少，读取的内容可能比内存都要大，这种情况 sort 命令都肯定要失败的。这种就不建议延迟 tee 了，还是换个文件名来写，确保读取写入全部完成之后再做文件替换是比较稳妥的。

@DeWjjj #31 试想一下，apt install 某个软件，之前是直接装上这个软件。现在是只提供 docker 镜像，apt install 是先给你装个 docker ，然后自动帮你跑一个 docker pull ，创建的 bin 是个 docker run 的脚本，你再想想能不能接受了。
snap 和 docker 都有存在的价值，可以接受一个软件同时提供 snap 和 docker 的安装方式，但是不接受的是你改变原本工作正常的 apt 安装的逻辑。
想用或者需要用 snap 的人自然知道怎么装 snap 版本。

@NaiveSimpleYoung #5 走标准的 DNS over HTTPS 或者 DNS over TLS 的话，各种语言应该都有库，现在大部分公共 DNS 服务也都提供了 DoH/DoT 的解析。关键词就是 DoH 或者 DoT ，网上搜一下就有了，不用知道底层原理。
或者自己实现私有的 httpdns 的话，估计就得服务端参与支持了，得自己搞，不过其实难度也不大。

我觉得上一个示例和这一个示例逻辑上都没问题。
上一个示例是改 increment ，计时器应当每秒更新不受 increment 的影响。
而当前这一道题是改 delay ，那么既然 delay 变了，按道理计时器就应该以新的 delay 值来更新，因此重置计时器没有问题。
而如果不重置定时器的话，delay 一直在变化，那么你究竟以什么时间间隔来更新数据呢？

@fpk5 #54 刚试了，是可以的

感觉 git 本身就是这么设计的啊，分支就是文件夹。
分支分为本地分支和远程分支，本地分支在 .git/refs/heads 下，以斜杠为目录存储，比如 main 、feat/feat1 ；远程分支在 .git/refs/remotes 下，以远程名与分支名用斜杠分隔，按目录来存，比如 origin/main 、upstream/feat/feat1 。
远程名里也是可以包含斜杠的，所以你的上游不仅可以叫 origin 、upstream ，也可以叫 upstream/cn 、upstream/us 。
所以远程分支也可以是 upstream/cn/feat/feat1 ，其中 upstream/cn 是远程名，feat/feat1 是分支名。

不过，这个确实可能会存在冲突的问题，比如你本地一个分支名就可以叫做 origin/main ，这样就会和 remotes/origin/main 冲突，在 git checkout origin/main 的时候就会收到警告：warning: refname 'origin/main' is ambiguous.。这时候实际上切换到的是本地的分支，要切换到远程分支进入 detached HEAD 状态，需要指定 git checkout remotes/origin/main 。
而如果本地有个分支叫做 remotes/origin/main 的话，又会冲突，那要切到远程分支就要指定 refs/remotes/origin/main 。
如果本地又有了 refs/remotes/origin/main 分支了，emmmm ，应该就没办法直接用分支名来切换了。

@456vv #47 还真不一样。从攻击面的角度来说，密码在网上传输的次数越多，承担的风险越大。
登录这个过程，用户名和密码必须要通过网络传输，这没办法。但登录后获取 token 的意义就在于，避免后续再传密码了，用 token 来充当用户名+密码。
但如果 token 是固定不变的，那也没意义了，和 basic auth 一样，并不安全，所以 token 必须要经常变。
token 当然不用是一次性的，但是必须要有时效性，定期续期，并且时效性越短越安全。比如银行网站就可能会要求 5 分钟不操作自动退出。
用 token 来代替密码就是为了频繁更新，避免同一套字符串一直在网上传。

所以，比较推荐的做法是，密码登录，换取两个 token ，一个是有较短时效的 session token ，一个是有较长时效但是一次性的 refresh token ，然后用 session token 通信，session token 过期后，再用 refresh token 获取两个新的 token 。
这样，密码因为更新频率很低，并且长度通常相对较短，所以只在网上传输一次。refresh token 因为可以充当密码来获取新的 token ，所以只在网上传输两次（往返各一次）。session token 权限最低，只能在有限时间内使用，且不能充当密码来获取新 token ，泄漏后的影响也是有时效性的，用来进行低频敏感操作可能还会要求用密码来做二次认证。
如果存在攻击者，那么他必须精准地获取登录包或者是 refresh token 的数据包，才可以拥有较高的权限，但这样的数据在网上传输的频率非常低。那么这个攻击者就必须长期攻击监控这个用户，那被用户发现的概率就提高了，而且大概率还只能拿到 refresh token 跟用户抢续期权，用户更容易发现账号被盗。