Fedora 也把 kde 从 spin 提升至和 gnome 版一样的官方支持的 edition 了。

我很好奇，有没有人现身说法一下日常使用 freebsd 是什么体验，毕竟相比 linux 生态还是弱了点。

https://imgur.com/5dvnkIS.png

上面图链接不对

https://imgur.com/a/5dvnkIS.png

随便从 /r/linuxmemes 里找的，没有恶意，搜 Not The Same 有很多

这个思路有意思，手动点赞

大佬的逆向工具都挺好用的 :D

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

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

这个系列把系统更新完整打包，如果某次更新造成异常，可以省去确定是哪个软件造成的这个过程，直接做完整的回退。但是 atomic 依赖的 rpm ostree 在定制软件包方面不是那么灵活。

现在有基于 bootc 的非官方项目 universal blue ，和 ostree 实现的区别在于 bootc 就是标准的可以引导 oci 镜像。这个应该是未来 fedora 的发展方向。现在已经可以手动尝试了。

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://v2ex.com/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://v2ex.com/t/1129403 可用，但不一定好用。Windows 和 Linux 情况差不多。

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