我记得 localhost 是可以不用证书也能用 pwa 的全部功能的啊

@ihwbunny 注入 dyld 是运行时的行为，不能持久化，但是肯定有别的持久化的方案保留权限

古代可以用 KDE （ native ）的来着（
实在不喜欢自带的任务栏的话，可以用 https://github.com/cairoshell/cairoshell
还有 Steam 上的那个 MyDockFinder

@ihwbunny 但是关闭 sip 之后有 root 可以随意注入 dyld 到别的已经授权了的 app ，然后就不需要任何提示了（当然关了 sip 还有很多方法也能绕过），没关 sip 的时候至少不能注入 dyld 到开了 Hardened Runtime （并且没设置例外）的 app 里

c++调试最麻烦的地方就在于，一些错误可以悄悄的传播到一个无关的代码上（几乎很难发现原始错误的地方）
并且有些错误一旦挂了调试器 /santizer 就会消失（

主要是能做到这件事的，by definition 就是叫反射（
Js 可以做是因为按定义，js object 就是 hash table

tls 不是只有版本号一条的（
有好几个算法，得双方支持了才能握手成功
旧的软件没更新自然就不支持

GDPR 的要求，谷歌终于开始遵守了（

有系统权限？试试直接在 framework 里添加一个系统服务

@CLMan 这中文还是我提交的翻译，当时有意（偷懒）保留了翻译腔，这居然被原原本本的复制了（

还记得古代 3dfx 吗，它是怎么死的，就是因为捏死专利不开放图形 api （不允许其他厂商支持它的专有 api ），然后被 nvidia 一个 geforce 玩死了
现在 nvidia 的状态也是类似，捏死 cuda ，不让第三方实现（ cuda 确实好用）
只可惜以目前现金流状态 nvidia 短时间死不了（

长文件名支持需要应用程序自己适配（
如果写死一个 wchar_t path[MAX_PATH]那神仙也救不了（

就好像英语用大写一样，看着会高级很多（

vscode 之前有个更新就说支持这个编码了（
笑死还是微软最快

迷惑回复之 yuv vs uv
这俩玩意都不是一个东西啊，texture 里的 uv ，就是指纹理坐标系里的坐标啊（你把 u 看成 x ，v 看成 y 不就好了），用 uv 这俩只是为了防止名字冲突
https://en.wikipedia.org/wiki/UV_mapping

@sillydaddy 阿里系的确认收货都是支付宝做的，实际上担保服务就是支付宝提供的，第一方就是支付宝。而闲鱼，淘宝，1688 这些都是不提供担保交易服务，这么说反而闲鱼 app 内做确认才是“第三方确认收货”。。。

有没有可能高温下硬件会提前损坏？而且坏了肯定没保修了，即使 cpu 本体能承受得住，cpu 周围的部件也不一定能用，比如有些风扇甚至会在高温下提前损坏，这样更压不住温度了

@jifengg @pursuer 实际上那 b 是 binarystring ，是在没有 typedarray （ uint8array, arraybuffer ）时代的二进制 blob 替代品，你看上去是一个文本，它实际上可以存 0-255 所有的字符，不是仅限于 ascii ，也可以包含 utf-16 禁止的字符序列（反过来你即使 atob 把 utf-16 的中文 base64 结果转换为这个 binarystring 也是不能得到正确中文的）。
可以说是非常之奇妙，这玩意的构造方法就是用 String.fromCharCode ，古代的主流用法是 String.fromCharCode.apply(undefined, [1,2,3]) 来从数组里构造一整串 binarystring （用这个方法弄出来的字符串保证是 binarystring ，在一些优化过的引擎里不会用两倍空间存储）
因为过于魔法而难以进一步优化（比如一不小心就会退化成普通 string ，占用两份空间），所以 arraybuffer 才会被发明以取代 binarystring
（然后因为 arraybuffer 不能轻易扩展长度，最近又在搞 resizable arraybuffer ）

arc 并不是灵丹妙药，而且性能不一定比得上 gc 和手动内存管理，还有额外的空间占用（所有被跟踪的对象，总得有个地方来记录引用计数吧），也没“彻底”解决内存问题（比如手动 weak 可能会炸，但不写可能会漏）
性能问题举例一个最简单的地方，因为没有额外标注，arc 必然得保证线程安全性，也就是说，即使你只在一个线程中使用，也需要通过线程同步的手段去做，虽然锁的粒度很小，但是由此带来的 happens-before 的语义也会导致很多优化失效