我的 chrome 经常几周不重启，内存占用还是比较稳定的

@wzxjiang 目前确定了社保由税务征收，但是公积金未定。不要想当然觉得公积金也肯定按照实际工资比例交了。

至于多交的社保，见仁见智吧。因为社保里占大头的是养老保险。缴纳四十年后才能领的养老保险，考虑所承担的政策风险，以及快速老龄化的人口结构，我是没什么信心的。

k8s +n

消息回执，客户端处理重发

正文的段落间距似乎有一些太大了

github 1 万 6 千 star 的小框架还行

不完全是精度的问题，V8 的运行时实现有缺陷

99**99 // 3.697296376497268e+197
Math.pow(99,99) // 3.697296376497263e+197
var a = 99;
a ** a // 3.697296376497263e+197

第一个结果不同，是因为它是编译时计算的。V8 在编译时和运行时计算使用了不同的代码。事实上，编译时计算的结果更准确。

99**99=369729637649726772657187905628805440595668764281741102430259972423552570455277523421410650010128232727940978889548326540119429996769494359451621570193644014418071060667659301384999779999159200499899

https://stackoverflow.com/questions/41679191/why-is-math-pow-sometimes-not-equal-to-in-javascript/41679584

这种情况 99%是正则写的有问题

参考 https://blog.csdn.net/ityouknow/article/details/80851338

@ragnaroks 这是一年时长的流量包，每个月都有 100G 额度，理论上用满的话是 1200G

用来存 ecs 快照还是不错的，已购

8 点上班？不知道程序员上午只会摸鱼的嘛#滑稽

bitmessage

然而去中心化的聊天工具发一条消息巨慢

漫漫长夜 杀戮尖塔 亿万僵尸

不错的想法。对暴力破解的防护效果是有的，可以应用在一些安全性要求不高的场合，并且无需收集和记录用户的任何隐私信息。

虽然 JavaScript 的执行速度已经很快了，但是在这种 CPU 密集型的运算中，依然会比 C 慢上一百倍甚至更多。登录的场景不允许让用户等待太久，同时又要考虑到用户设备的硬件差异（例如一些比较老的智能手机）。最终抵御暴力破解的能力会打折扣。

就以楼主的例子来说，普通的台式机上 300ms，放手机上可能需要 3s，而攻击者用一台稍微好一点的机器，只需要 10ms。JavaScript 是单线程的，但是攻击者可以使用所有的 CPU 核心进行并发计算。假如攻击者使用的电脑有 16 个核心，就可以每秒尝试 1600 次。

要知道，合理的风控措施能做做到在支付场景下让用户使用 6 位数字密码。而这种 POW 策略必须搭配一个复杂的密码才能起到效果。

我只在提交 PR 时才会 fork 项目……如果是为了学习，我一般只 star + clone 到本地。