@sazima #7 对啊，再说地图本来也支持一堆坐标点绘路线图吧，不需要索引的话确实这样就可以了

而且压缩之后只需保存经纬度和时间就可以了，并不复杂吧

这不就是和录音差不多原理么，按固定时间采样，比如 1 秒采样当前经纬度、速度和时间，然后压缩就可以了啊，压缩也就是去除相同方向速度的不同时间重复数据就可以了，最后数组保存就是了

一般来说应该扣余额之前检查卡是否有效就可以了额
余额的问题应该是算不算收入，算就设个定时每天扣款到消费记录就好了，不算，那就不应该扣余额

我觉得很多人过于乐观了，而且用 2g 到 3g，3g 到 4g 类比很不恰当，之前之所以会迎来巨大爆发，很大程度每一次升级确实是质变，更重要的我想还应该是，3g 和 4g 重要的商业场景都已经在 pc 有线或者 wifi 模式下完全得到了证明，比如 3g 的电商、sns、微博，4g 的在线游戏、视频语言直播，而且在 wifi 下已经完成了技术准备，缺的就是网络问题，这个谁都看到了，可是 5g 呢，有什么是成熟商业场景了么？看看现在提出的 vr、ar、自动驾驶、工业互联、万物互联，哪个是技术完备成熟的？

还有更重要的，3g、4g 依赖的场景几乎都是纯软件场景，一旦开发完成，部署几乎不需要成本，看看 5g，哪个不需要独立的硬件依赖，或许很多人没做过硬件相关的开发，现实世界总是很慢的，任何以小的功能都要很久，更别说还有很昂贵的分发部署维护成本了

再说句不客气的，5g 很多场景或许未必真的有用吧，比如万物互联，在现阶段下看来，真的会是一个有用的场景么？难道不是一个和当年大数据火爆时，啥走到门口就知道你是谁为了点好喜欢吃的菜、看妹子一眼就自动给你识别手机号微信这样现在看来有点可笑的实现么？把那么多东西连来组成一个有用的东西恐怕非一年两年可以搞得定的吧

5g 确实是一个很有用很有价值的功能，但我想认为和 3g、4g 一样会快速带来爆发点，我感觉也有点不太恰当，我相信未来 30 年，5g 和以后更先进的版本必定会彻底改变我们的生活，但是 5g 会想 4g 那样带来下一个爆点，似乎也不太可能，现在缺的可不止 5g，太多东西了，这个恐怕不是一年两年能搞得定的

纯 cpu 计算但是双核 cpu ？

if getNullTime >= 7 有啥作用，except 出 errno.EWOULDBLOCK, errno.EAGAIN 就表示数据还未准备好需要稍等通知啊，这个很正常啊，网络栈都是组合好数据一次可以读取多个 ip 包的，那么从内核 copy 到用户空间肯定比网络栈处理速度快啊，所以网络栈出 errno.EWOULDBLOCK, errno.EAGAIN 是正常的，没必要重试，下次如果数据准备好了，再调用 epoll 时又会得到通知

更细微的，就算 cpu 一直在运行，不同指令的功耗也不可能一样吧

@leafin #27 他的意思应该是覆盖整个城市的类似交流电的巨大电场吧，无负载时无功耗，但是就算有这么大功率足够完全改变整个环境了，感觉上还是没可能吧，几百年前特斯拉还提过呢，感觉核裂变聚变电池才更有可能近乎无限续航吧

从性能上看 tornado 和 twisted 差不多，好处是 twisted 实现的网络协议很多，没特殊要求我还是支持 tornado，感觉对 async await 支持更方便

asyncio 性能看似更好一些，但是其实只有 protocol，不过在 async reader 和 writer 的情况下，其实也差不多，不过不得不说 tornado 的 iostream 的实现过于复杂了，极大的拉低了性能

自己也实现过一个简单的，https://github.com/snower/sevent 差不多有 asyncio 三倍的网络性能，协议解析简单代理转发类的服务还不错

认真说还是 asyncio 吧，async 配合 await 还是比较容易写的，其实 go 的开发效率感觉还是低一些，没什么几万几十万并发的，性能啥的完全不是问题，感觉没啥特别必要，但是 go 确实方便啊

@CEBBCAT #14 更重要的是单脚操作任何情况下，你想踩刹车必定放弃油门，而人的左右脚是分左右脑控制的，所以单脚控制必定会比双脚控制对人的注意力要求更低，反应时间更短吧，单脚操作确实更合理

想买黑色，但是没有 12G 内存的。。

vpn 搭建内网，然后直接访问或者主从同步或者热备份 sync 就是了啊

cython 之前用过，似乎无法完全自动解析 struct 或是 class 提供的指针，不过标准类型比如 char 的支持还是不错的，建议可以写一个 c 文件返回 char 字节流，然后在 python 中导入调用这个函数接收字节流，再用 cython 把 python 文件编译成扩展就行了，性能也不错的，不过我觉得写一个 python 扩展也不难啊

@coderluan #8 go 的文档没有特别强调，那估计是生成的代码是一样的，没有特别优化，而且编译号运行和 go run 直接运行似乎看不出性能差距，感觉应该是一样的

用又拍或者七牛

Thrift 编码协议自己也用了很久了，我感觉设计上还是有很多缺点的，效率也不高，感觉 grpc 和 protobuf 设计更好一点吧，如果自己重写 gen，那么工作量不小吧，如果修改 thrift rpc 协议，感觉兼容性或弱很多了

nas 就是存储啊，这就是最大的价值，拓展电脑手机容量，自动备份，最大的点就是容量大，数据不丢失，访问快

就好像现实世界的储藏室一样，你说一储藏室还要有啥特殊功能，就没用么

当然有人喜欢网盘，有人喜欢 nas，看自己喜好了