pipeline 水管嘛，想想现实世界中的水管，谁会用水管储水，不都拿蓄水池嘛
所以你想把上游的输出全部放到水管里以后再放到下游的水龙头，就知道这样做是不合适的了吧
但是如果你真想干这种奇怪的事，那就是想办法造一个非常大非常粗的水管了

bash 的 pipeline 只声明了会将命令程序的输出和输入连接起来，可没声称这些命令的执行开始和结束顺序。

@zhuisui 不是驱动，是固件

四年前买的 niz atom 66 ，那时候的驱动，节电模式下蓝牙信号干扰严重的时候输入有问题，居家办公的时候发现的（可能家里 2.4 G 的 wifi 信号太多），但是后来的驱动修复了发包策略，再也没出过问题。
一把键盘用到现在。现在办公室鼠标、键盘、耳机全蓝牙。也不用 wifi ，因为蓝牙省电。

我通篇看下来，包括技术和交流方式两条线，尝试分析一下
1. 先说交流方式
- 架构师嘛，我猜估计资历和年龄都不小，有点脾气也能说得过去吧。上来先是教训小朋友的口气，然后是有点不太耐心仔细的回答，最后一竿子打死看起来不怎么靠谱的新人。我想说是没那么好，但是也没那么差。这个世界就是这么浮躁。
- 题主嘛，开口就是“你说得不对”（技术的东西我一会儿说），直接莽撞，然后回答也没那么严谨仔细（第二句“但是...”，下面说），也是充满了年轻人（我猜的）的脾气，也没做到处事严谨仔细。

在我看来半斤八两。
2. 再说技术
我很久没看 MySQL 了，临时搜索了解的脏读、不可重复读、幻读三个问题，以及快照读、当前读俩读取手段，还有可重复读和串行读四种隔离级别，也看到一些文章提到可重复读对于当前读手段，会有产生幻读问题的情况。当然我也没有验证，不过人家声称是验证了的，所以我觉得这是可信的。这里又牵扯到 MySQL 版本的问题。
我想说，这个特定场景在特定时空下肯定是存在的，而且这和题主的声称（但是...）的场景也相左。（不知道题主说的修改、冲突具体指啥，也不是专有名词概念，也不一定是指“可重复读对于当前读产生幻读问题”）
可以认为题主自己的技术也不严谨，一开始声称是 MySQL 实现上用 innodb 彻底解决了幻读问题，说对方是只知道规范。但是实际上是反过来的，对方才是很了解实现的人（毕竟都在美团了应该也见过不少特殊场景了），而题主自己主要是在看文档（虽然自己做了测试，但没提到上述场景）。

所以技术我站对方。

但是再看一下这个帖子的标题吧，我觉得题主过分了。
我自己吧，不觉得架构师就应该有好人品好涵养什么的，这是一个技术称谓，又不是“大师”“方丈”😃。
over

刚查的
锂电池电量过大或过小，正负极材料更易损耗；电压越高，循环损耗越大。
不过一般不用在乎就是了

tlp

@kkocdko @Donduck 不能说激进，active 是让 cpu 自己主动管理，passive 是让 os 管理它（被动）。
tlp 最新版本的默认设置是 active ，大概这个是综合比较好的。
另外文章里附了一个性能评测，使用 active 的各个配置也是综合比较好的。其中使用 passive 的 power 是最省电的，但是频率直接被限制到了 400MHZ🌚

https://www.reddit.com/r/linux/comments/15p4bfs/amd_pstate_and_amd_pstate_epp_scaling_driver/
@nlzy 最新的驱动 amd-pstate-epp


其中提到的显卡控制、cpu 调度器、外设供电等，不就是 tlp 做的事嘛

我这里耗电有好大一部分是因为用了 wine 版的微信

windows 电源管理比较好，比如息屏的时候
如果是一直亮屏使用，这个差不太多，看具体负载了

setex 作为一个原子操作，兼顾读写，消耗较大。
300 个线程 1ms 一次，那就是 30w qps ，超时也正常。
基于这个思路改善肯定没问题。

我升级后，经常调试击中断点的时候 UI 会冻结一会儿

@main1234 如果 write 到 aof file 时候发现正在 fsync 则不会 "重复 fsync"

应该是盘符对调，最多重启就好了，如同 @NoOneNoBody 所说
复制之前最好是先变成只读

@main1234 这 21 年的文章，我看的今天的源码。。。
当时啥逻辑不知道了，你有兴趣去翻翻吧

至于 2s 的问题，fsync 的异步任务如果正在进行中，即使超过 2s ，也不会强制 fsync
如果在这类场景，比如 bio fsync 任务的系统调用一直没返回、redis 出了 bug 、断电，出现问题，都不是该考虑的

你好像搞错了这一套流程。
aof buffer 存放的是写命令，在内存里
aof write 是把 aof buffer 写到文件里
fsync 是把文件缓存内容同步到磁盘上

渲染和计算分离