个人感受，搭博客之类的，cpu 甚至内存都不重要，基本够用。带宽线路才是影响体验的大头

不错不错，正需要类似的服务
如果有 docker 就更舒服了

挺好，之前一直用，感觉 edge 比 chrome 省不少电

之前买了个 6g 的 p106，299，用着感觉不错

逐步转为 postgres

flex 兼容性吃过亏以后。。。
absoulte 一把梭

要真正保密只能在后端操作吧。用 js 重写一样会暴露算法，防君子不防小人。
不肯做 api，那不妨用 vba 封装 dll，每次用的时候给出动态密码，需要下载对应的临时 key 才给用。不过这种做法纯属脱裤子放屁

交叉编译是真的好用！

真希望 wsl 能支持 cuda

用勺子挖西瓜吃，才是夏天

我来组成分母

冰球，真人对战，不卡顿。。。

都用 rem 吧，省事

vba 应该足以满足要求了吧

现在推荐 CoreOS+docker 会不会被打

gevent 这种库在 docker 里最好不要用 pip 安装，推荐使用包管理工具直接安装。
实测在 alpine 里是可以成功 apk add py-gevent 的
说起来 alpine 是真的小，我以前做过一个 python+flask+gevent+mysqldb+gunicorn 的镜像，debian 要 500M+，alpine 只要 60M

楼主或许可以参考下这个
https://8chan.cc
用加密的 cookie 存储身份信息，另外设置了一个小小的防刷帖机制，没有用到验证码。
域名快要过期了，不打算继续开下去。所以请随意测试～

@Xs0ul 是的，这个不是 bloomfilter 的标准用法，在取或操作后摘要不再稀疏。 个人是觉得在文本长度不定的情况下，用局部敏感哈希按照（相同号码数量 /新用户的号码数量）计算相似度会比较麻烦，所以提了这个方法。本质上是就给号码归类以降低计算量。

最终要的就是这个不稀疏的结果，假设有三个签名，分别为 11000110，11000100，01100111，可以很容易地看出前两个数据集重合的可能性更大，这样就可以筛除海量数据中不相似的那部分。

当然，这是有误判的概率的，这个概率是和 hash 函数以及签名的长度有关的。这种 hash 函数，很好取，提一个不太好的函数--比如我希望 hash 函数要在 256bit 的空间里至多有 2 个 1，我可以把 md5 的最后 16 位分成两段 8 位的摘出来，决定这两个 1 的位置。

个人觉得数据量较大时，利用 Bloom Filter 是最佳解决方案：
1. 首先设计几个不同的 hash 函数，这些 hash 函数可以把手机号映射到 256bit 的空间里，并具有“稀疏”的特点（就是说 1 的数量很少，几乎全是 0 ）比如手机号 A 可以在 hash 后得到 00100010，手机号 B 得到 00100001。
2. 然后对用户通讯录里的每个手机号进行 hash 操作，并将所得的结果按位相加，得到一个签名。比如手机号 AB 相加，得到 00100011。不同的 hash 算法可以得到不同的签名。记录这些签名。
3. 每当有新用户注册，对其通讯录进行以上处理，得到其签名（如 00100001 ）。将新用户的签名和老用户的签名进行与操作，记录 1 的个数，1 的个数最多的，就可能是最相似的。
这样初筛时间复杂度是 O(N)，之后再进行处理就快多了。