boNote

最近很摸鱼，计划中的讲解 `RNG` 和 `sch_cake` 的博文咕了好久又不想碰了，于是记录下之前让我很恼火的一件事。 ### 症状 doups 反复抢夺前台焦点，导致输入状态不停被打断。 ### 检查过程 通过 procexp 守株待兔后不难发现，抢夺焦点的罪魁祸首是 `msrdc`，其父进程是 `WSLg.exe`。 不难猜出，原因是 dopus 的树视图中有 WSL 项，因此反复试图列出 WSL 内容缓存，然后拉起 WSL 进而拉起 WSLg。 ### 解决方案 关闭 dopus 中的 WSL。 ___ 好，今年份的博文就发到这里 ：）

在 bash 脚本中使用 `set -e` 是很常见的操作了，这个命令按照 POSIX 标准有下面的作用： -e When this option is on, when any command fails (for any of the reasons listed in Section 2.8.1, Consequences of Shell Errors or by returning an exit status greater than zero), the shell immediately shall exit, as if by executing the exit special built-in utility with no arguments, with the following exceptions: 1. The failure of any individual command in a multi- command pipeline shall not cause the shell to exit. Only the failure of the pipeline itself shall be considered. 2. The -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last. 3. If the exit status of a compound command other than a subshell command was the result of a failure

近期因为 [Arc](https://t.me/arc_null) 先生推荐了 **[zitadel](https://github.com/zitadel/zitadel)**，然后我因为他说到 pgsql 支持有问题，突然想起来这个问题。 当然对于标题的问题，结论肯定是很明显的 pqsql，我们有没有一个合适的数据来证明这一点呢。 考虑到穷，所以没有太多核的机器，考虑到懒，所以一定要即开即用不做任何多余的配置，这就是下面的测试原则。 ## 太长不看 先看下面方法论，确保理解场景。 越大越好： ``` MySQL 8.0.32 QPS 8979.31 MariaDB 10.5.22 QPS 25788.07 (287% mysql) PostgreSQL 15.3 QPS 35383.99 (394% mysql) ``` 越小越好（此数字由 人工 智能采样估测）： | DB | usr time% | sys time% | io time% | ram(incl. buffer) | | --- | --- | --- | --- | --- | | MySQL | 12 | 5 | 30 | 970M | | MariaDB | 27 | 14 | 18 | 920M | | Postgre | 30 | 25 | 15 | 710M | 如何理解呢？如果不能理解的话不如加入 pgsql 夸夸人。 ## 方法论 参考 [这篇 MariaDB 声称自己吊打 MySQL 的文章](https://mariadb.com/resources/blog/benchmark-mariadb-vs-mysql-on-commodity-cloud-hardware/)，但我选择了默认参数配置的 sysbench oltp_read_write 脚本，单表 2000000 条，4 线程，20 分钟测试。 具体 workload 为，每 transaction 包含下面的内容（使用的 between 区间为 100）： - 10 个单点 SELECT `SELECT c FROM t WHERE id=?` - 1 个区间 SELECT `SELECT c FROM t WHERE id BETWEEN ? AND ?` - 1 个区间求和 `SE

## 引言 深夜睡不着想 /remake ，突然就想到了手机的闪光灯问题：之前深受索尼的垃圾手电筒之害晚上起夜永远找不到卫生纸，就测了下手上还能开机而且有闪光灯的手机的闪光灯的 CRI。 测试使用一台国产的光谱照度计进行（因为买不起进口的）：  手机被放置在由南旗盒子、kindle、路过的铁盒子堆成的测试台上，灯光对准测试仪的传感器，测试期间关闭所有灯光，多次测试取高值。 ## 测试记录 ### 常规组 常规组选择了一些普通、平凡、无趣的智能手机来进行测试。 组中有三个苹果，均手动调至最大亮度。 [TL;DR](#常规组结果) #### iPhone 13 mini  数值很好看，光谱也不像普通的 LED，可以被称为全光谱 LED 拿去做相机的补光灯了。 #### Sony Xperia 5 II  亮度低到离谱，光谱也不好看。索尼罪大滔天搞到百姓怨声载道.jpg #### 万普拉斯 8t  亮度大概够照亮你的美了。 #### Redmi K40  同上，不过这个光谱比上面的 1+8t 好一些。 #### 鬼族 16th  今日珠海小厂，亮度差些，但是 CRI 还是可以的。 P.S. with MoKee，忘了 bugme 有没有调亮度了，我估计是有的。 #### iPhone SE2  亮度是真的强，显色是真的烂。 本机为正常途径（指 W

## 为什么要用 Warp play余额充多了没处花买了warp+ ，warp 可以有效拯救服务器的媒体解锁能力，妈妈再也不怕咕噜咕噜（非洲方言：指咕鸽）把我给 `Region: CN` 了 而且还能顺便处理掉咕噜咕噜天天弹点选消失型验证码让我搜一次点一年的优异体验 （和群友吹水顺手测了下梯子落地鸡的 [RegionRestrictionCheck](https://github.com/lmc999/RegionRestrictionCheck)，看到花了不大价钱买的 Youtube Premium 不能用，感觉像吃了屎一样，正好从记忆的角落翻出来了 warp 这个东西 想起来跟着龟龟白嫖了warp+的流量 ，就顺手试试） ## 效果预览  ## 安装 Wireguard 因为 warp 使用 wireguard 协议，所以我们需要安装 wg 的客服合一p2p端软件 [Instruction 参见](https://www.wireguard.com/install/) rh 系都进 epel 了，除了 rh 系都进官方源了，我真想不出还有什么再在这件事上多费口舌的必要  ## 其他系统需求 本文基于 Debian 10，所使用的 `ipproto`这个 selector 在 18 年底才 [被引入 iproute2](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=b2e8bf158460568ec5b48cba69f657f95891c901) ，Debian 的速度当然是还算快的，但是对于[19年11月 前的 RHEL](https://bugzilla.redhat.com/show_bug.cgi?id=1678111) / [200428 前的 CentOS](https://git.centos.org/rpms/iproute/c/72258cdf3818ca898511fda04947914f6a11be

22/04/02 Update: 有一位朋友在留言中问了下面的问题： > cfw中启用Specify Protocol或者pac对访问https网站依旧无效 于是我又打开阔别已久的 Windows 开发机看了一下（顺便一提，果子也挺烂的，尤其是ARM版的，不过看在字体渲染的份上还是先用果子吧）： 问题在于 Clash for Windows 的Specify Protocol处理其实还是有问题，如果你之前没有仔细完全阅读下面那个设定代理服务器的函数，翻下去看一下它，就在倒数第二张图。 可以看到如果只是单纯地把注册表项的内容由 `127.0.0.1:7890`改为`http://127.0.0.1:7890`的话，urllib只会返回一个只有一个key也就是`http`的代理dict。 这时候从pip的请求调用链往上找，可以看到负责决定使用这个dict中哪个代理的代码是 `requests/utils.py`的`select_proxy`函数：  因为红框中的部分的限制，当你请求`https://pypi.org`的时候，只有key为`https`/`https://pypi.org`/`all`/`all://pypi.org`的代理会被使用，上面那个`http`的代理自然也就不会被使用。 BTW，因为这个代码是 requests 库的，这也就意味着在 Windows 平台上 Clash for Windows 的系统代理不会影响到大部分py应用的http请求。 而正确的做法是什么呢？让我们在IE中设置上代理，然后看一看它给出的行为：   同时，因为 urllib 中还存在代理的类型推测代码，所以正确的设置应该是： `http=http://127.0.0.1:7890;https=http://127.0.0.1:7891` 21/06/07 Update: CFW [解决了](https:/