听说是由于拒绝服务攻击导致路由黑洞

@hshpy google 的做法是渲染到 script 块里，也不需要额外请求

@hshpy （所以问题就在这里了，按拼接 html 的模式就没法解决了，要解决就只能通过让后端输出结构化数据，前端做转换才可以（

@hshpy （不应该存 html，可以存另一个结构化的表示，然后前端再重新处理回 dom 结构，全程不需要 innerHTML

窗口化和全屏其实不只是大小的区别。。。
很多执行路径都不一样
（除了某些无缝全屏模式）
全屏模式下默认不走窗口混合过程，因此程序能控制的参数更多，比如可以修改显卡的 Gamma 映射来调整对比度，乃至 HDR 输出，以及跳过垂直同步，和 G-Sync，更重要的是，这样效率也会更高，不需要多一次额外复制过程
窗口模式就相当于系统管理上面说这些东西（
当然了，现代游戏引擎理论上都能自动支持窗口模式和全屏模式，只是游戏开发商想不想选择的问题（有些老游戏就压根没做支持

要好看的，可以来用 Token2shell
（第三方 uwp 应用中少数几个设计精良的

TLS 在 TCP 之上，虽然名字包含传输层，但是实际数组应用层，socks5 协议只处理 tcp 和 udp，不代理 icmp

@a1lenyang 变量顺序是不变的，但是要注意虚表会在开头额外占用一个指针，多重继承的时候则有可能会更多，因此最好每次变更都同时更新头文件并重新编译其他依赖的库

因为虚函数是按声明顺序保存在虚表里的，所以实际上你写 x.fa()的时候编译器就会生成对虚表第一个函数的调用，所以你改变声明顺序就会导致调用错误函数

编辑文件请直接用 vim(
Sco 理论上也是过跳板的，不过这个协议过于古旧而且不适用于大量小文件的场景，建议打包上传

C++的最大黑点不应该是大小以 MB 为单位的编译器报错么（
整个屏幕 boost::mpl_.........

ftp 的问题很多，现在 0202 年如果有的选，选择 webdav 都比 ftp 好
尤其是在有 NAT 的环境 ftp 的多端口设计简直就是灾难
FTP 唯一的优势就是服务端实现简单，没了

我记得 vs 的字符串字面量限制是 65535 （宽字符 32767 ）来着

你以为优先级只是修改一下数值就可以解决问题
实际上界面涉及的东西有一大堆，意思是你要画一块区域可能还要等待别的数据准备好了才能开始画，不然就完全没法不知道怎么画，具体的例子就是各种同步操作，读取一个数值时线程被锁定了，然后动画就卡了，你优先级再高它也得卡（可能还卡的更厉害，因为别的线程得不到调度），解决问题的方法只有重写相关的逻辑，强行将 ui 和数据耦合，这是目前 chrome 浏览器的做法，但是这又会带来一个问题，内存是有限的，不可能说把所有不在当前页面上的元素的数据都准备好，通常的做法都要涉及 ui 和数据处理线程的交互，你得知道页面的哪部分是用户可见的，并且在区域变化时及时更新数据，于是这里必然会存在竞争，根本不是优先级能解决的问题
Win 上的 Edge 浏览器滚动非常流畅，代价是滑得快会白屏，出现一块一块的白块，原因也是类似

你都知道 echo c > /proc/sysrq-trigger 了。。
所以应该也可以手动
write(open("/proc/sysrq-trigger", 0), "1", 1);
(不用考虑泄漏，反正内核都跪了

用日卡卡的存储重定向，看它的日志（

(现代的写法不是写死 pthread，而是用
find_package(Threads REQUIRED)
然后加 Threads::Threads 的链接
这样就可以尽可能多的兼容不同系统
因为理论上只有用了 glibc 的 linux 才需要链接 pthread

×最后再给个建议：放弃折腾终端，随便弄个 webui 都比这个简单一万倍。。。。