二合一响应式布局，没有移动版

让用户习惯 app 一挂后台就死，以为大内存真的没有用

@linglin0924 请继续试

@linglin0924 #9 你试试就知道了，都是重复的

一台轻量 66 一年，100 个就是 6600

自己单排，匹配的就是同水平的对手，组排匹配的是你朋友水平的对手

->该应用无法安装在 x86 架构上
装个翻译插件就行了

没有 8G 还是别入了

有什么理由不选无锡 65W ？

@LifStge #13 用 PWA 的拦截 api ？这或许是个好办法，可以尝试一下

@cpstar 现在又出现一个新问题，由于播放器播放视频的时候默认会缓冲 3 个 ts ，但是这三个 ts 是串行缓存的。这就导致了把这三个 ts 存在三个不同的服务器上跟在一台上实际上效果是等同的(只针对一个人看视频而言)。我去查了 hls.js 的 issue ，发现他们并没有打算做并行缓存这个特性

@cpstar 现在发现瓶颈出在播放器用的 hls.js 上，这个库下载 m3u8 的 ts 切片是按顺序来的，不能并行下载，即使做了切片的负载均衡，任意时刻也只会下载其中一个

@anubu #3 感谢，可是这个不是前端的，是个客户端。客户端的方案确实多，但是前端的难找

@ruxuan1306 #1 也考虑过 m3u8 ，不过这样太死板了，每一个切片只能固定由一台服务器提供

C 语言真正有价值的是 unistd 这些跟操作系统密切相关的库函数
你不学操作系统，没必要学 C 语言，特别是非常通用的计算，C 的精髓并不在这上面，比如网络编程现在有更专精于这一领域的 Go
除了几个特定领域比如嵌入式啥的非 C 不可，其它大部的工作还是面向 x64 展开的，性能强资源管够，压根没多少纯 C 的出场机会

@nevin47 #130 真正使得 Control Group 有实际应用场景，还是得 Go 写的 Docker 跟 K8s 出马。C 语音写的沧海遗珠多了去了，要是没有能用得上的伯乐，就只是个普通的砖头。教堂再宏伟，跟你能成为哪块砖哪块瓦是两回事。

@Kasumi20 #52 一个例子：机器码不支持 32 位立即数的，汇编就能支持。汇编也有语法糖的，只是一行汇编翻译成了另外几个指令的组合，编译原理编译到汇编就够了，没必要直接到机器码

100W 大列表排序，前端是怎么展示的？

@Chism #4 目测不超过 10 个