当然有了
菜市场搜 no screen on

可以，ssh 反向隧道

有种数据结构叫最大 /最小堆

坑不多，但是一些库的兼容性还是要考虑下的，比如 libpng 新版是 14，旧版是 12，你有些软件如果依赖这个的话就 gg 了

@monkeybrother 这这么牛逼那公司的有线局域网不是早翻天了？关键数据现在谁还用明文再传？

@nopy 不用，一众套现软件比如元＊＊啥的个人很容易注册

@simple_plan 其余的需要别人点你的链接才可以赠送

最新版的 vnc server 6.3 我的 Debian8/9 上都跑不起来，往后回退一个版本就行

@silov 公司交的部分直接统筹掉了

所以我发送一个 10000，双方时钟得跳 1000 下对吧？这效率得有多低下啊？

@ZUYI 首先 FPGA 里面没有分离式的电阻，用电阻这些就是无稽之谈，其次你这种测电压下降的方法考虑过精度没有？你 9999 个电阻并联跟 10000 个电阻并联你算算这电压表的精度得达到多少才能帮你区分出来？有没有考虑过最后电阻本身的误差就已经超过你想要实现的精度了？

@sennes 电阻并联，电流相加，我猜是这个意思
根据最终电流的大小判断到底匹配了几个

@nutting 「圆周率(Pi)压缩法」就是一个例子，常被用来开压缩算法的玩笑 —— 但不止是玩笑而已，理论上确实管用。方法是你把想要的压缩文件二进制化，然后在二进制化的 Pi 序列里找这段数据。由于 Pi 是无限不循环小数，所以任何你所选择的二进制数据最终都会在 Pi 里被找。这是个疯狂的但是尚未被彻底推翻的理论上可行的算法。但是如果我们只是要对单个文件进行压缩，而不是多个，这个方法一定管用。

于是你只需要标记 Pi 的起始位置和你文件的大小，压缩过程就愉快地完成了。这可以把任意的文件压缩到非常小的地步，而且可能会用掉你海量的时间来找到对应的二进制串，完全是拼人品的算法。

不过，理论上，如果你人品不够，找到的数据位于非常遥远的地方，那用这逗比算法得到的压缩包也可能会非常大。但是最近有一些逗比孩子对此还发表了论文，指出你可能得到比你要压缩的数据还大的压缩包。github 上就有一个这样的玩意儿叫 PIFS(Pi 文件系统)，这个开源项目声称不管怎么说，100% 的压缩率在数学上是不可能的。