一个写于 1997 年的 C++ 窗口管理器,到了 2026 年 8 月 6 日还在发新版本。IceWM 4.1.0 刚刚上线,没有追逐任何时髦概念,更新日志里写着三件小事:默认把 Alpha 设为 false 以避开罕见的视频性能问题,要求在释放 pixmap 前先释放 XRender picture 防止报错,以及给 icesh 工具加上 mousemove 命令和 ignoreUserTime 窗口选项。

搜这个名字的人,通常只想搞清楚它在今天的位置。IceWM 是 X Window System 下的轻量级堆栈式窗口管理器,由 Marko Maček 创建,以 GNU LGPL 协议开源,覆盖 Debian、Ubuntu、Arch、antiX、NixOS 及主流 BSD 系统。和 JWM、Fluxbox、Openbox 这批同行相比,它省内存的底子相当,但胜在自带任务栏、系统托盘、动态菜单和超 450 款主题(含 91 款精选 Extra 主题),不用拼凑第三方组件就能直接干活。

省那两兆内存是假命题,开箱即用才是真护城河

极客圈聊轻量级窗口管理器,总喜欢拿着几兆的内存占用比高低。把历史测试账本摊开看,这种争论其实抓错了重点。

一张桌面壁纸吃掉的内存,抵得上三款管理器争十年的差额(示意图)
一张桌面壁纸吃掉的内存,抵得上三款管理器争十年的差额(示意图)

在 antiX 16 无背景图的整机空闲内存对比中,JWM 占 35.9 MB,IceWM 占 37.3 MB,Fluxbox 占 37.7 MB,Openbox 为 65.3 MB(禁用 Wicd 网络管理器后降至 54.8 MB)。早年基于 Ubuntu 12.04 下 Xephyr 环境的单进程增量测试也显示,JWM 带来约 3 MB 变化,IceWM 为 4.5 MB,Openbox 为 7 MB,Fluxbox 为 16 MB。

antiX 16 整机空闲内存对比(单位:MB) JWM(无壁纸) 35.9 MB IceWM(无壁纸) 37.3 MB Fluxbox(无壁纸) 37.7 MB IceWM(开默认壁纸) 47.9 MB (+10.6 MB) Openbox(禁 Wicd) 54.8 MB 注:开启一张默认壁纸带来的约 10 MB 内存涨幅,是前三款管理器自身差距的 5 倍以上

看懂这张图,就能看穿所谓的轻量级内卷。JWM、IceWM 和 Fluxbox 之间的内存差距只有 1 到 2 MB。但在同一场 antiX 16 测试里,只要打开一张默认桌面背景图,整机内存就会立刻上涨约 10 MB(IceWM 升至 47.9 MB,JWM 升至 46.5 MB)。

一张壁纸吃掉的内存,抵得上三款窗口管理器争上十年的差额。

我更在意的是工程完成度。很多极简窗口管理器为了数字好看,把面板、托盘、快捷键管理全剥离出去,用户装完还得自己花半天配齐一套工具链。IceWM 把任务栏、工作区切换器、Alt+Tab 快速切换、全键盘流控制和约 36 种语言翻译(4.1.0 刚更新了简繁体中文、乌克兰语等)全包在了一起。它不靠抠那 1.4 MB 的极限内存赢,而是靠装上就能用、用起来不挡路留住老用户。


给 Wayland 贴上 wontfix,是一笔算得很清楚的生死账

把视野拉回 2026 年的 Linux 桌面全局,最扎眼的反差不在功能表里,而在 GitHub 的 Issue #70 里。

团队给 Wayland 提案盖章拒修,腾出手拧紧 X11 的每颗螺丝(示意图)
团队给 Wayland 提案盖章拒修,腾出手拧紧 X11 的每颗螺丝(示意图)

当主流发行版和大型桌面环境全面倒向 Wayland、逐步弃用 X11 时,社区里要求 IceWM 支持 Wayland 的呼声一直没断过,讨论一路延续到 2026 年 4 月。有人提议借道 labwc,也有人设想结合 River 窗口管理协议来做过渡。但维护团队的态度干脆利落:Issue #70 处于关闭状态,挂着醒目的 wontfix 标签,没有任何实现承诺。

《孙子兵法》讲,途有所不由,军有所不击。打仗最怕在没有胜算的战场上硬耗主力,维护有 29 年历史的开源老项目也是同理。

核心协作者 gijsbers 把账算得很透。他在 2024 年 9 月就警告过,同时维护一个兼容的 Wayland 版本,会让维护负担至少翻倍;到了 2026 年 4 月 5 日他再次重申,IceWM 从根子上深度绑定了 libX11、EWMH 和 ICCCM 规范,做 Wayland 版本等于从零另起一个完全不同的项目。

这不是技术保守,而是开源人力经济学下的冷酷自保。回看 PC 软件史,当年无数从 DOS 往 Windows 迁移、或者从经典 Mac OS 往 OS X 迁移的独门小工具,大多不是死于旧系统消亡,而是死于作者在重写底层架构的半路上精力耗尽,既弄丢了旧版本的稳定性,又没做成新世界的半成品。

IceWM 的架构分野与用户去向 坚守 X11 阵地(IceWM 4.1.0) • 深度绑定 libX11 / EWMH / ICCCM • 修补 _NET_STARTUP_ID 与视频性能 • 适配老旧硬件与 antiX 等轻量发行版 代价:高分屏与休眠唤醒偶发历史摩擦 转向 Wayland 路线(标记 wontfix) • 底层图形与窗口协议完全不兼容 • 双线并行导致维护负担至少翻倍 • 社区 labwc / River 设想停留纸面 对策:原生需求者需直接迁移其它合成器

拒绝掉必输的消耗战,团队才能腾出手去拧紧 X11 下的每一颗螺丝。这也是为什么在 4.1.0 里,我们还能看到针对未闭合配置字符串、_NET_STARTUP_ID 解析错误的修补。

旧地基撞上 4K 多屏,裂缝藏在边角里

守住 X11 的决定保住了基本盘,但旧地基终究要面对 2026 年的新硬件。官网文档里写着通过 RandR 和 Xinerama 支持多显示器,这话没错,只是没把高分屏与现代电源管理下的摩擦写出来。

1997年的旧协议地基接驳现代4K多屏时难免露出边角裂缝
1997年的旧协议地基接驳现代4K多屏时难免露出边角裂缝

把历史 Issue 翻出来对账,多屏边缘场景的坑其实不少。早在 2020 年 11 月的 Issue #517 中,就有用户遇到 3840×2160 的 4K 显示器在摆放任务栏时被识别为 1920×1080;到了 2025 年 3 月关闭的 LXQt Issue #980 里,记录了显示器休眠唤醒后窗口移位、分辨率恢复异常的问题,这个现象在 Openbox 和 IceWM 下都被复现过。此外,现有文档在涉及 NVIDIA 显卡的 XRRDisable 选项默认值表述上,也留有前后不一致的尾巴。

虽然维护者在 3.8.2 等版本里陆续修补过工作区扩大时最大化窗口尺寸调整、屏幕边缘菜单行为等多屏细节,但受限于 X11 协议栈本身的历史包袱,它在复杂多屏与混合缩放面前注定不如原生现代合成器从容。

  • 建议.手握老旧笔记本、工控设备或依赖稳定 X11 会话的用户,可以直接升级 4.1.0 拿走默认关闭 Alpha 带来的视频性能修复;但如果你打算拿它去推 4K 双屏且频繁休眠唤醒,动手前最好先测一遍外接屏唤醒后的窗口复位表现。

当年 1997 年写下的那句速度、极简、不打扰用户,放到 29 年后的今天,变成了一种体面的撤退与死守。那些执意要上原生 Wayland 的用户早就该转头去找新船,而只要主流发行版和 XLibre/Xorg 生态还没拔掉 X11 的最后一根电源线,IceWM 就会继续在它的旧城堡里,把最后一批坚守者的桌面打扫得干干净净。