dnf 降级还是比较简单的，麻烦的是确定什么导致的，特别是问题来自底层依赖而非上层应用的时候。

Fedora workstation 版本只能支持内核版本降级（回滚/回退），作为更新相对激进的半滚动发行版，官方的思路是 atomic desktop ，对应 gnome 的版本是 silverblue 。

这个系列把系统更新进行

我没在工作中见到从传统架构渐进式过渡到云原生的成功案例，甚至没有听说过。所以就我个人的经验来说，在非云原生架构上加入 k8s 基本上只是当作运维工具来用，或者迁移一部分比如配置管理之类的功能过去。我理解造成这种现状的原因主要还是迁移对于团队技术要求太高了，在权衡过迁移成本和风险之后，大多数团队可能会选择重写。

传统架构中很少有真正意义上的分布式，多数业务的实现都是大单体应用，无法像微服务那样以非常细的粒度对功能模块进行拆分。所谓分布式的实践大多数停留在主从复制、负载均衡的层面上。k8s 之类的平台是将开发和运维的工作进行解耦，开发者（理想情况下）不再用关心运维层面的事情。实现的方式本质上是尽可能暴露应用内部状态，让数据流动公开化，最终的结果就以微服务的形式表现出来。

简单总结就是，我不看好任何形式的架构层面的迁移。要么坚守传统架构，要么从零开始云原生，我也不相信换个软件框架就能实现过渡。

估计要懂 webrtc 才行，挂在 React 节点可能不太好找人。

市面上的 sdk 大多都是类 webrtc 实现，然后在上层封装对接了供应商的网络服务，做成付费业务。

会的。甚至包括第三方依赖的引入，都会专门开会讨论各种实现的优劣再决定。

初次编写代码的成本，比起长期维护的成本可低多了。这个成本总需要有人付出，无非就是写代码的那个或者审代码的那个。

引入 ai 之后，就算写的人用 ai 写，审的人用 ai 审也无所谓，最终还是这两个人来承担责任。

所以当我是提交代码的人的时候，肯定会看代码的。当我是审代码的人的时候，一样也会看，只是会在去掉注释和脱敏之后让 ai 一起检查一下。

理论上隔离广播域可以在二层用 vlan 交换机做，也可以三层用路由器做。

楼上说 wifi 路由器的 guest 实现方式是 vlan 子网划分和独立 dhcpd 服务。

可以在支持 openwrt 的路由器上自行实现类似的功能。

我也有自己写的工具，大致看了一下代码，随便说说想法：

1. 监控剪贴板内容变化，win 有 api 可以注册监听，mac 有 api 提供变化计数，linux 取决于窗口管理器，移动设备基本没戏。轮询不是一个好的做法。

2. 你的思维模型过于复杂了，本质上你不需要解决完全分布式的同步问题，只需要把同步的模型改为星型连接，这个同步问题可以简化。

具体说就是，所有节点设备之间只需要一个中转节点，也就是上面 #3 提到的覆盖逻辑。剪贴板更新行为是有方向性的，一定是从写端传递到读端。

3. 使用网盘同步很慢，如果服务器和费用是障碍，可以考虑用各种 serverless 服务实现。

搞个用爱发电还行，这种业务太容易被黑灰产利用了。

“非内置的 APP 基本都需要单独适配”，这就是 APP 厂家最后的反抗了。APP 对于大部分互联网服务来说就是个入口，一旦 MCP 化之后这个入口的作用更会淡化。

可以看看 iOS 捷径，主流应用的适配基本上就是敷衍一下。

@Donduck #41

uclamp 一样支持增加频率 hints ，uclamp 出现的时候还是 dvfs 的时代，现在也是支持 epp 的。严格来说 uclamp 并不直接参与控制，而是通过加权参数影响 governor 对于 cpu 的调度。

我认为 windows 在电源管理和异构调度上的逻辑不是很清晰，至少它没有明确区分 scheduler 和 governor ，所以你会觉得 Windows 有的 Linux/Mac 都没有。实际情况是，Windows 非要自创逻辑和概念，这才是问题所在。

@Donduck #37

为什么 Linux 要有 Windows 的 QoS 控制，这个逻辑不合理，毕竟是两个不同的系统。我猜你想说的是 Linux 没有类似 Windows QoS 的机制？在我看来，Windows 和 Linux 还真就差不多。



我在 https://ex.noerr.eu.org/t/1129403 这个帖子里解释得比较清楚了，（自动，非指定 affinity ）异构调度是个加权调度，依赖四个方面的参数：

1. soc 向系统汇报自身拓扑、容量以及频率温度等等运行时信息
2. 任务本身的特性定义，这个定义可以是历史数据统计而来，也可以手动指定
3. 用户意图
4. 调度器加权算法

调度行为的数学本质是将 1/2/3 作为参数，通过 4 的算法转化为特定的加权数值。

目前 1 是 soc 厂家提供的，仅取决于硬件平台。

加权算法方面，对于 Linux 来说有代码可以参考，对于 Windows 来说是个黑盒。尽管 Linux 的实现依旧 naive ，但我不认为 Windows 能比 Linux 好到哪里去。这是个约束优化的问题，可能不存在求解全局最优的多项式算法。

对于 2 来说，据我所知 Windows 可以通过任务管理器为某个进程设定“效率模式”来影响对于 P/E 核心的偏好。我对 Windows 了解不深，说错见谅。Linux 对应的实现叫 uclamp ，使用标准 cgroup 机制来手动定义任务特性。

对于 3 来说，Windows 应该是基于电源计划，现在（基于 hwp 的 governor ）应该叫 power mode overlay 了。Linux 对应的入口是 tuned （过去是 power profile ）。两者思路上基本一致。

Windows QoS 或者 Linux 的相关机制，本身只是额外的加权信息，至于它叫什么名字，如何与系统其他部分集成对接，是取决于系统原有框架的。

自动异构调度的未来，以当下的眼光来看就是两条路，要么手动标定所有的任务，要么拉长时间获得足够好的历史参考数据来自动标定任务。调度算法反倒不是很重要（我个人甚至认为 naive 的算法就很好了），毕竟只是个加权，底层逻辑还是公平。

换句话说，只要不用强制 affinity 的手动方式，目前所有依赖动态信息自动做异构调度的效果都差不多，不可能存在质的差异。顶多是有多少人工就有多少智能。

购买方面，Ultra 200H 系列相比 100H 进步很大，所以建议买新不买旧。另外不带 Ultra 的都是马甲别上当。

使用方面，关于核心调度可以参考这个 https://ex.noerr.eu.org/t/1129403 可用，但不一定好用。Windows 和 Linux 情况差不多。

另外 LPE 核心 intel 是有想法的 https://github.com/intel/intel-lpmd 类似手机上 idle 的时候将负载转移到 LPE 关闭 P/E 来省电。

这个好像是 Google 在全键盘手势之后增加的一个修改，大概 A12 前后有的，也就是说它是 navigation bar 的一部分。

你可以进设置中搜索键盘或者导航条，有可能会有隐藏那个条的选项，我用过的几个 rom 对应设定的名字不一样。

TLDR：正常用几乎不会有负面影响，暂时也不用指望有太智能的调度。建议使用 6.12 之后的内核，如果是最新的 cpu 平台建议 6.14 。



我简单凭印象解释一下关于 linux 调度的逻辑，这个是比较复杂的，可能有说的不对的地方，需要详细了解建议根据关键词去查询。

如果把任务调度理解成数学问题，逻辑一定是从完全公平（ CFS ）开始，之后一般化到根据需要加权获得有偏向的调度，比如 EAS/CAS 等等。具体实现方面，除了加权逻辑之外，还需要运行时参数，比如程序运行了多久，消耗多少能量，想好多少算力，这又是一个约束优化问题。

目前所有的调度都是 CFS 完全公平调度的扩展实现。调度过程是：先估算每个任务短期 cpu 占用（这个机制叫 PELT ），然后决定下一个调度任务（这个算法叫 EEVDF ）。推荐 6.12 内核就是因为 6.12 完成了重大改动的合并。

与异构相关调度加权有 Energy Aware Scheduling 和 Capacity Aware Scheduling 。前者 EAS 是 arm 大小核诞生之后就有了，逐渐完善至今，多用于低功耗设备。后者相当于是前者的数学拓展，优化的目标不再是单一能耗比，是未来异构调度的核心。

在 CAS 逻辑中，CPU 硬件向系统汇报核心的拓扑、相对容量/性能以及负载、温度和频率这些运行时状态，然后 CAS 算法根据目标：比如性能、能耗、公平性等等决定如何执行核心迁移。

可以简单认为，Intel/Amd 目前的补丁都能正确告诉内核硬件拓扑，Linux 也能正确理解基础的高性能、平衡和长续航情况下的核心使用优先级，但 CAS 算法以及基础参数都非常 naive 。

一点点使用建议：

异构核心上的（自动最优）任务调度是个很难的事情，这里有两条路可以走，一个是苹果的手动黑白名单，比如将商店进程放到能效核心上，另一个就是全自动，也就是 CAS 的做法。

所以如果你是自己写程序，那完全可以绕开自动逻辑，手动绑定核心。

如果你是要改变 CAS 的优化方向，不是很推荐也没有直接控制的手段，通常是建议保持 SCHED_NORMAL 。

另外 scheduler 和 governor 是不同的，这里只讨论调度器。

1. 通过链式调用来写，比如

z.Add(&x, &y)
.Mul(&z, &p)
.Div(&z, &q)

这样可以减少中间值的使用，还是比较直观的

2. 使用 dot import ，如果你能将代码作用域规划得非常清晰，可以做到

var i Int // big.Int
j := NewInt()

不推荐但是确实有用

3. 直接使用 ai 的 tab 补全，用注释写数学表达式，配合人工或者测试用例做 review 即可

AndroidX 只是个支持库，楼主描述的问题核心是 gradle 这种构建系统复杂，与使用什么样的支持库没有关系。我不是专业的 Android 开发，只是经常做一些逆向或者开发个人用的工具，经验不一定靠谱，以下我说的仅供参考。

简单说，一劳永逸解决心智负担的方法就是学明白构建原理以及构建工具的使用方法。

我认为这个问题本质上就和 git 图形化插件一样，你对 git 越熟悉，用图形化插件就越不容易出错。假如对 git 理解不到位，用图形化插件就容易爆炸，最终很可能还是要回到命令行去排错。

构建本身就是个非常复杂的过程，可能很多专业开发写了很多年 Android 都没有尝试过手动构建，因为 IDE 隐藏了构建工具（ gradle ）的细节，构建工具又隐藏了构建过程的细节。当底层构建过程出错的时候，经过两层抽象之后暴露给开发者的信息就非常有限，容易让人摸不着头脑。

我们就用手动模拟 gradle 工作流程的方式，从最简单的开始一步一步说。首先要 Java 编译，所以要配置 jdk ，同时要配置依赖，这里依赖的来源可以是线上仓库，可以是本地引入等等。假如引入的依赖有 C 之类的原生库，就要引入 ndk 做交叉编译。这里就不深究了，假设直接用 CMake 构建工具完成了。

以上只是编译出各个组件，离完整的应用包还有距离。这里字节码要打包成 dex ，资源文件要用特定工具压缩，最终还要把各个模块再打包成 apk ，还要处理签名等等。

如果只看核心的构建过程并不是很复杂，构建 variants 、测试和缓存等等一系列功能不影响理解这个过程。因为 gradle 的配置本身是个 DSL ，如果你不理解 DSL 背后所代表的实际工作过程，想要通过修改 DSL 代码来排错 debug 就不现实。

在理解 gradle 的原理和 IDE 的使用方法的基础上，手动排错 debug 就不是特别难的事情。当然这个事情不绝对，有些项目时间跨度很长，而某些支持依赖没有语义化版本，对应的 gradle 配置可能无法向后兼容，甚至出现版本一换循环依赖解析失败的问题，这时候就要手工重构替换掉特定依赖了。

@burtnonald2 #21

感谢总结，相对来说原帖不如后面回帖里讨论的东西有价值。

一般来说 SoC 层面没什么问题。上市前半年官方分支就开始加驱动代码，这样产品上市的时候，相关驱动才能赶上合并的时间节点。有问题的一般是键盘、触摸板、声卡（严格来说是 dac/adc ）、摄像头、指纹以及 bios/ec 这些。

Intel 阵营这边，越是公版设计，越是丐版没什么外设的越能做到开箱即用，最典型的就是小米。

有个比较简单的方式，通过 https://linux-hardware.org/ 来查找，比如 https://linux-hardware.org/?probe=a81f6be044 看到检测到的硬件，以及对应的驱动状态。一般来说 works/detected 都没什么问题，failed 不代表就不行。当然这个数据库一定要有人上传数据才行，属于前人栽树的行为。如果没有的话，可以考虑去品牌线下店，用内核比较新的 linux live 引导，然后 hw-probe 上传一下。

随便说一下容易出现没驱动设备的解决方法：

- 键盘，一般是因为硬件上走了比较特殊的连接方式，比如键盘先连 ec ，ec 再连 ps2 这样，厂家可以通过 ec 拦截某些按键组合实现硬件上的功能调整。这个驱动不了的话一般只能等 fix 。

- 触摸板，比较新的触摸板有可能只是没适配，驱动多数是走 libinput 的，看看相同型号有没有其他设备支持的，有的话一般来说写个 quirks 文件就可以了。

- 声卡，如果是固件问题多数时间要等上游修，和上面触摸板 quriks 修正差不多。另一个常见的问题就是用了 XX 牌子扬声器，本身声卡驱动是没问题的，只是无法正确激活响应的 dac/adc ，也要等上游修。

- 摄像头，驱动不了的摄像头大多数是走了 IPU 而不是 usb 。目前 linux Intel IPU 支持也慢慢跟上来了。还是等修……

- 指纹，看厂家，基本没得修。因为厂家不提供驱动的情况下，指纹类设备就是黑盒，想做驱动只能逆向。指纹的驱动不在内核里，看 libfprint 的支持列表吧。

- bios/ec ，看厂家也看型号，现在来说做得比较好的是 thinkbook/thinkpad ，其他的都半斤八两。