我也是常年只用 wm 而不用 de 的，但事实求是地说，wm 和 de 之间的差距还是挺大的。

这几天讨论 linux 桌面的帖子里，我感觉用户分化的主因是心态，而不是技术方案。能接受的人看重的是 linux 的长处，发挥优势。不能接受的人看重的是全面，不能有短板。所以接受不了 linux 就更接受不了 wm 。

我用过一段时间的 plantuml ，不过画架构图的话元素定位比较蛋疼，各种隐藏线，还控制不准。

蹲个解决方案。

站里有 zed 节点，不过讨论不多。

现在有几个项目在用它的 gui ，印象还有国人开发的。

https://v2ex.com/t/1056672 这个帖子里我有比较详细的评论。

我用了四五年了，作者 dnkl 的其他项目也都很优秀。

我感觉作者对于很多底层技术了解非常透彻，随便列举一下 foot 的优秀之处：

- 基于作者自己开发的 fcft 做文字渲染，fcft 的代码也非常值得一看，简单、可靠

- 基于 damage tracking 的渲染架构，速度和很多基于 gpu 实时渲染的不相上下

- 正确实现控制序列，支持 kitty keyboard 协议，主要是用于正确传递键盘事件，比如 gui->vte->multiplexer->app ，另外就是支持 OSC52 远程复制之类的指令，做 shell 交互集成

- 正确实现 wayland 分数缩放协议，text-input-v3 输入法协议

上面随便拿出来一条能做好了都非常难得。

另外还有一些可能不属于技术，但符合我技术审美的选择：

- ini 风格的配置文件

- server/client 架构的 daemon 模式

- 自带自身的 bash/zsh/fish 补全

- 很少见做对了 alpha blending （虽然方式是基于 hsl 转换）



PS

关于 alpha blending 解释：

这个过程几乎无处不在，但是由于历史遗留问题，加上又是基础组件中的实现，所以直到今天都存在大量且普遍的错误实现。

由于人眼对于暗部比亮部更敏感的特性，sRGB 之类的色彩空间是经过 gamma 矫正的，更多的编码精度留给了暗部。所以对 sRGB 来说，数值翻倍不代表亮度翻倍。所谓 alpha blending 就是模拟真实世界中光线混合，在一个背景色上显示一个前景色文字的过程，需要先将 gamma 矫正过的 sRGB 还原为线性空间，两种颜色在线性空间中混合之后，重新映射回 sRGB 空间来渲染。

如果 vte 或者其他任何应用不能正确处理 alpha blending 很容易出现混合区域变暗的情况，这一点在字符光栅化抗锯齿方面提现很明显。对于 vte 类应用可以观察一下在各种配色主题下的表现。

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 捷径，主流应用的适配基本上就是敷衍一下。