最后 6 分钟是苹果重新定义过的，其实就是在往硬盘写数据，你硬盘差的话就要很久，可以打开控制台看看

总之就好我不需要的功能都是臃肿都是流氓，别人需要关我屁事

拖拽的思路都是 mousedown 绑在要拖的元素上，触发时在 document 上绑定 mousemove 和 mouseup ， up 时注销 document 上的事件，这样保证不会鼠标动太快移出元素事件丢失
另外 ie 有 setCapture 功能， ff 有类似的，自己搜吧

10.5 寸的重点在于窄边框，拿手上舒服多了

@drw2w tb2 接口能满足 dp1.2 ，带宽也就 tb2 的一半多点，只要你的线没问题就能连上去

好麻烦，这货有 dp 接口，你买一条 minidp - dp 的线直接接上去就行了

whatwg 差不多是 w3 的技术更新 beta 版，我建议看 whatwg 再结合浏览器实际实现的进程

@elone 我做过万条数据排序的优化，大概知道这个耗时的量级，删除和插入复杂度比排序低得多，完全没问题的

首先我不太相信你的数据量真的会很大，万条以内做 filter 根据 id 找一下不会消耗什么时间的
其次删除用 filter ，添加用 concat ，这还是比较简单的
不建议同时维护一个 id 的 Set ，这种同步的代价比较大，除非你设计出一个 SortedSet 的结构来

分支随用随开， merge 完就删，楼上这样要看做了哪些事的，用 no-ff merge 就能看了

@fyibmsd pm2 深入进程的监控能提供很多操作系统层面拿不到的信息

看漫画写邮件偶尔 ssh 连着写点代码

魔都以前是 20 块一个月升 20M 上传，现在是 200M 宽带自带 20M 上传

用 top 看内存正常说明这些内存已经和 node 这个进程无关了，就算用 profile 都查不出来，只能瞎猜了，先去掉 pm2 看看能不能正常，不行再去掉几个功能模块半分法找？

受不了 x1c （哪怕低配）屏幕的人， 5300 的 air 11 的屏幕居然能忍，感情眼睛有选择性地为 mac 补充细节来着

买了会员的话能投诉啊，没会员那就安静着吧

因为这货是个数学符号，初中高中都用过吧……

@ffx0s 一张 200x200 的 96dpi 的图片，变成 100x100 就是 132dpi 了，所以你要提高 dpi 就是在原有希望尺寸上把宽高放大，然后再显示到小的容器里去

canvas 本身是位图绘制的，所以 canvas 就这么大生成的图片也只能这么大，放大就会失真，你要高 dpi 的只能一开始就搞一个超大的 canvas 出来