(为啥不整个正经的 matrix 呢*

设置 SWAP 其实只会影响内核对可回收页面的判断（
本来必须是有文件映射的页面才可以被回收，
现在没有文件映射的页面也可以被回收了（当然其他限制还是在的）
而回收策略依然是根据使用情况做预测（具体算法比较复杂）
所以如果不设置 swap，内核就只能在内存压力高的时候把文件映射的页面给回收掉，而这对于终端用户来说卡顿的感觉就很明显了。。。
设置了 swap 之后，内核会更为公平的回收页面，换句话说，更不容易把用户感知明显的页面回收掉（

不一定，有很多因素可以导致差异，有些好解决，有些只能规避
比如前面提到的共享库版本问题，这个解决起来就是整一个容器或者最简单一个 chroot 环境，在里面编译就肯定兼容了
必须规避的就是由于 cpu 指令集的差异造成的问题，这个时候就得对着目标设备的 cpu 特性开编译选项了。。。

外部脚本操作有官方的 chrome drive，何必绕一圈呢（
当然我不是说这个不好，只是对于这个用例来说没必要

模拟断网的话你可以直接用 cutter 等软件关闭连接

https://man.archlinux.org/man/stress.1
stress 可以模拟 CPU 内存 资源的问题，以及磁盘 IO

其实说到底就是 windows 的坑，0202 年还在折腾编码问题，以至于不能 utf-8 走天下。。。如果假设所有终端程序都用 utf-8，就不会做出先解析输出内容的设计决策。。。

用 pwsh https://aka.ms/PSWindows

首先确保边界坐标按一定顺序排列，指可以一笔画完的那种，然后保证都是逆时针或者都是顺时针（这里假设是逆时针），可以存在交叉，凹陷，甚至在多边形内部挖孔，只要确保最终是封闭的就好。
然后做个矩形范围快速检测，也就是确保目标点落在图形的矩形范围内。
然后可以选择一个参考轴，这里假设是水平 x 轴，其实可以为任何角度，选择一个就好。
接着从目标点出发向那个方向发出一个射线，然后对每一个图形上的每一个线段做相交判定，这就是一个初中数学问题，计算射线和线段的交点，如果不相交，跳过，反之，通过线段 y 轴坐标之差的符号，判定是进入了图形还是离开了图形。
然后遍历完所有线段后，将离开图形的次数和进入图形的次数相减（算法实现上可以在相交的时候计算），只有 3 个可能的值，出现别的说明你算法写糊了或者图形有重叠，-1 说明你点的顺序拿反了，整个图形的外部被认为是内部，0 说明点没进图形，1 说明点在图形内部

相关文章
https://web.dev/color-scheme/

<meta name="color-scheme" content="light dark">

我记得 github 有个账户继承的操作，可以设定死亡后转移给某个人）

@sarvatathagata 为了调用系统 api 的（不是为了提高性能

@lchy （ PC 单机限定的话完全可以用，反正别的选项不会比这个更好，这里说的是能用，如果你数据库有几十个 T 的话，不要指望能实现快速查询）

SQLite3 存大量数据根本不是问题，唯一的问题是只能单机用，所以只要没有水平扩展的需求，基本都能用 SQLite3 解决。。。

用斐波那契数列做缩进（
还有用质数
vscode 有插件做

Sciter 用 dx/opengl 糊界面，其他的可能直接用更轻量的方法糊了

msvc 2019 是支持的

v2 不是自带套娃功能吗，参考这个 https://www.v2ray.com/chapter_02/protocols/http.html 里面的注解