@Ritter #8
.Box.mt-4{display:none!important;}
https://i.v2ex.co/504J5BO2.png

阿里云非标端口，似乎没受影响。

@lixuda #17 你（为了图方便而）用了怪异的方式启动，那自然是怪异的更新方式
不知道你在寻求什么？甚至这是否真的方便还两说。

总之需要个编配方式
不通过手动，而是某个外层监控装置去监控它的运行
systemd 不常用但也可以

@qilishasha #7 Flask 的 session 实现不是类似（还是就是？） jwt 么？
我开发用的那个整个关掉再开也没掉 session

https://vcb-s.com/archives/5610
《 madVR 渲染器配置教程》
> 高配置（ NEW ）建议使用 1070 或者性能更强的显卡

“显卡” 这个叫法可能误导，因为集成在 CPU 上的那个怎么都不像张 “卡”

显示控制器是显示输出的必要装置，虽然某些机器不一定要显示输出，比如 RPi 官方镜像，写入完成后开机自启 sshd，有约定的 root 账户密码，那确实显卡并不需要（不过 RPi 板上还是有的）。

应该是没有存储具体值的，首先 zip 本身会表述算法，但子算法很可能不会表述
man zip
...
-#
...
Though still being worked, the intention is this setting will control compression speed for all compression methods. Currently only deflation is controlled.
可知 deflation 算法才可以控制

man zipinfo
...
Finally, the sixth field indicates the compression method and possible sub-method used.
看得出具体的子算法是 `possible`，即推测出的。

实际上生成了 cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 100K | cat > file
然后 for i in {1..9}; do zip -$i v$i.zip file; done
测试的结果上来说，
zipinfo 指示 v1..v2 是 defF，v3..v7 是 defN，v8..v9 是 defX，都是 deflation 算法。
压缩结果大小上来说，v1>v2=v3>v4=v5..=v9
diff 的结果，v8==v9，v4==v5==v6==v7
就这样吧

顺便一提，zip -v 显示 2008，zipinfo -v 显示 2009…… 十年没更新了……

@IgniteWhite #35 我觉得更像 Google 为 Stadia 开发的 “负延迟”（ negative latency ）

200M/1s = 1600Mbps
就算一倍浪费，内网如果是万兆的话根本不构成问题。

@gantleman #34 哦是我没仔细看 Github Repo 内搜索的前提，同一文件只会显示前两处匹配……
不过在尝试写一个双链表 insert 写得一塌糊涂后明白自己写 C 确实太少，尤其指针的表记都得想半天。还是算了。
在我经历过的学习路线图上 C 只是 ASM 的伪代码（

奇怪的思路：FreeFileSync 的监视模式（