@Andy1999 lovelive 还有 14 天就药丸了还买(ry

@icedx 大胶布

@icedx Final LoveLive!

距离飞往东京还有 13 天。

别人拿着他们的 paper 重新实现一遍而已。

PT 的话国内一般不会封
但是“共享带宽”很可能限制你的速度。

关心网卡无线是不是还是走的 480Mbps 的 USB 2.0 总线

提个问题： 6700K 对应的上一代是 4790K ，提升并没有单核 20~30%这么高。 5960X 是核多频率低，真的玩的人都是超频的。

后两者其实是可以同时存在的……
一个“完全开放”版本，你想怎么改就怎么改，但是改动结果自己负责；
一个只能看不能改的版本，代码来源可以是自己修改也可以是经过审计之后从贡献代码中吸收，然后公司对这个版本提供商业服务并盈利。

六百多天断了

登录七百天啦

@cevincheung 我不太熟 PG ……用其它 SQL 比如 mysql 不会这样么？
首先是你第一个 at 我的内容：事务隔离如果设置成序列化或者可重复读的话，你的这两个 commit 都只会有一个成功，另一个会失败。
第二个的话，会是两种情况：
1 、读 0 ， B commit 成功；
2 、读不是 0 （ Acommit 之前的值），然后 Bcommit 失败。

@cevincheung 就是这样，然后提现成功，购物扣款失败，很符合逻辑啊

没看懂……首先是事务
然后“事务”的意义是
并发事物 A ：
update table set balance = 101 where id = 1
select balance from table where id = 1

并发事物 B ：
update table set balance = 99 where id = 1
select balance from table where id = 1

两个 select 的结果都等于自己那个事务 set 的那个值，不会出现“执行了 A 的 update ”-“执行了 B 的 update ”-“执行了 A 的 select ，得出 balance=99 的结果”这样的问题（这个例子好像不太体现事务的特征但是应该没有错误……大半夜的想不起来了）
从这样的角度来讲，你的那个 B 读出 100 并没有问题，因为 A 和 B 是同时执行的，先执行完了 B （读出 100 ）后执行 A （减一）没有任何问题。

新年快乐

RC 版本尚有很多已知问题，不建议用于生产环境和用作日常的主力系统；

↑看到这一句好感就没了， RC 的意义都没有了。

blackblaze?

简单说， CloudFlare 很大一部分是跑在 openresty 平台上的。
CF 虽然国内访问不咋样，但是还是世界一流的（ Amazon 什么的国内不也……）

客户端做了 ip 白名单
只有游戏 ip 端才能加速。避免了翻墙的风险，毕竟这个大家都懂的。

服务器端麻烦也做一份。
然后就是，攻击的问题现实中是严重存在的。