@mafic
基本就是需要一个 theme 框架和一个分发配置的框架
http://stackoverflow.com/questions/8811594/implementing-user-choice-of-theme
https://github.com/Avocarrot/json2view

@inksong
问代码至少要贴一下错误输出吧。

这显然是 IO bound 的情况， 1G 带宽打满也用不了一个核。。。
epoll kqueue 是正解，开几千个线程也马马虎虎吧，起那么多进程就有点浪费了。

淘宝这些都是每次到了要过节之前的更新，打包节日用的界面资源。到了过节服务器发参数过来，渲染一下就 OK 。还有些直接就是 hybrid ，那就跟网页没什么区别了。

PCI Passthrough 还是需要 host 来转发 interrupts 的。
nv-docker 稳定性确实有点捉急，但多调试也能用。
GPU 虚拟化成熟的解决方案只有 Grid ，不过那就不是个人和小公司能买得起的了。

放狗一搜
https://nmap.org/book/man-version-detection.html
http://null-byte.wonderhowto.com/how-to/hack-like-pro-fingerprint-web-servers-using-httprint-0151242/

@rogwan
是 flask 么
filestorage 本身就是个文件的啊，试试直接 Image.open(form.img.data)

这显然不是 Pillow 的问题，仔细读读 API 吧。

USB 2.0 ？？？
5G 路由下 FTP 是个好方法。

@rogwan
又在 SO 上逛了一圈。
两点建议吧，
1. seek(0) 试试。
2. 检查原始数据，可能 form 过来的 data 就是有问题。

@rogwan
先检查一下 form.img.data.read() 的类型，再 dump 一下 form.img.data.read() 的内容，和直接 get 的做一下对比。

@neoblackcap 高精度也要撞到 32bit 的墙上，你数组最多有 2^32 个元素，其实就是 @lishunan246 的意思，在具体机器下讨论时间复杂度都是扯淡。时间复杂度就得在某种约定好的计算模型下来讨论。

@menc

http://imgur.com/a/Y29Qw

放张图吧，要是有人觉得 slide 作者也是民科我也没办法。

@ipoh 输入规模被框定了，比如 G(V, E)，最多有 2^31-1 个节点，最多有 2^31-1 条边。任何给定宽度的原始数据类型都面临这个问题，能够表达的数据规模是有限的。有限的就是常数时间。如果非要说 int 是 32 位的，楼主的算法时间复杂度是无穷大，因为输入的规模 32bit 没有变，运行时间发生了变化。

这种事情没什么好争的， 能插得上嘴的都知道双方纠结的点在哪。我只是觉得很多人嘲讽楼主不对，指数和线性的观点都有合理性。

@ipwx 黑人问号？？？ 算法属于理论计算科学，和电脑，和工程有什么关系？
算法不认识任何实际计算机，只认识图灵机模型， RAM 计算模型。 1 至少用 1 个 bit ， 2^31 至少用 32 个 bit 很难理解么？

这让我想起当年，因为 int 是 32bit 的，所以所有算法都是常数时间的梗了。

楼主是对的，这题跟整数价格 0-1 背包伪多项式时间 O(mn) 一样。多项式时间和伪多项式时间不是一个概念。 RAM 计算模型读入一个 64bit 的数只需要 32bit 的数一倍的时间，但是这个程序需要跑平方那么多的时间，不就是 O(2^n)。平时说的排序 O(nlogn)，读的可是 n 个数。仔细思考一下，不要给人乱扣什么民间计算机科学家的帽子。

pillow 很好，但是不要和 server 布置在一台物理机上。 pillow 在处理大图片的时候会调用外部库并行处理，很吃 CPU ，如果和 server 在一台物理机上会严重影响吞吐的。

@muyunyan mk 大把机型还是 cm 的底包， device tree 这种事情不是随便搞两台编译服务器的就能行的。搞机型适配要的是大把大把的 human hour ，没有社区，手机厂商和 CM 3 方共同推动根本不行。首先，手机厂商不给 kernel source 谁都搞不了。其次，没有社区志愿者搞 device tree 不可能编译过。再次，没有统一的 CM 代码和免费编译服务器社区志愿者也抓瞎。 CM 挂了之后，不知道 XDA 社区力推的继任者 LinearOS 能不能顶上。最坏的情况， Android ROM 基本上可能就要退回到，只有销量大的，有志愿者亲自用的机型，而且志愿者手上有可用的编译服务器的情形下，才可以适配 ASOP(因为 CM 已经挂了，不会有官方拿工资的人写代码了) 的境地了。比较好的情况是 LinearOS 完全取代 CM ，改为纯社区维护（我不看好社区维护，没有动力），另外机型适配者自己搞 device tree ，加上 LinearOS 的代码，自己找服务器编译。最好的情况是有新的大金主愿意给大家免费送编译服务器，这基本就是 CM 改名叫 LinearOS 。