By FunnyAWM

在之前，我已经发布过了deepin 25的初上手体验。正好最近推送了deepin 25.1更新，同时我也将deepin作为开发主力系统使用了一段时间。这篇评测将从开发工具（尤其是嵌入式开发工具）的角度重新全面评测deepin 25.1和整个Linux生态。

注意：个人观点，仅供参考。如有不同观点，请在评论区友好讨论。

1. deepin的优势——deepin还是那个deepin

1.1 快速配置

首先是安装后配置方面。deepin相比其他Linux发行版对于国内用户的优势就体现出来了。一切常用软件都可以在应用商店中找到，大幅省去了其他发行版安装软件的繁琐步骤。在新安装的deepin系统上，只需要大约一个小时的配置，我就可以得到一个基本可用的嵌入式开发环境。很多工具链都对Linux提供了良好支持，就算需要的工具不在应用商店里，直接去官网下载安装脚本也可以获得非常良好的体验。其中STM32CubeMX在星火商店有直接打包版本，PlatformIO、uv、Rust Cargo等开发工具也可以通过非常方便的脚本一键安装。至于LazyVim、VS Code、JetBrains Tools等IDE的安装与使用也基本与Windows无异。同时得益于Linux良好的包管理机制与标准的路径管理，在Linux下进行嵌入式开发是一个基本无痛的过程。

1.2 良好的硬件与软件支持

众所周知，在Linux下安装NVIDIA驱动，除了Ubuntu、Mint等发行版以外，都需要相对复杂得多的安装与配置步骤。如果操作不当，在升级驱动时还有可能出现问题导致独立显卡无法使用或无法进入桌面。如果无法解决，就需要再次重装系统，浪费大量时间。我和openSUSE真是一对苦命鸳鸯

相比之下，deepin在安装时就提供NVIDIA闭源驱动的特性，极大方便了配置过程，使我能够以更快的速度开始开发工作。例如在Linux下（后面的驱动是所有Linux发行都会有的），STM32 Blue Pill、ESP32、Pico、Arduino等常用开发板（包括CH340的转换方案）甚至逻辑分析仪（尤其是Saleae的8路以及16路分析仪）不需要安装任何驱动，能够被系统直接识别。

对于一些常用软件（比如沟槽的企业微信），就算没有原生Linux版本，通过官方优化的Wine配置使用Windows转译版本，在大部分情况下也能够满足基本使用。

所以在deepin下，搭建嵌入式开发环境的步骤就只是——安装系统、安装IDE和工具链、开始开发。没有任何繁杂的配置步骤，直接开始开发。

1.3 对X11小问题的修复

在使用Linux Mint期间，X11一直有一些问题烦扰用户。这不是Linux Mint与Cinanmon的问题，而是X11的历史遗留缺陷。例如在X11下，分数缩放的实现机制是通过渲染一个更大的画面，然后将这个画面缩放到指定水平来实现的，这就势必导致游戏在渲染画面时，渲染分辨率会大于实际分辨率。这会导致非常明显的性能下降问题，例如在Minecraft下，使用2.5K 150％缩放的帧数会相比同配置下使用2.5K 100％缩放的配置降低大约30％的帧率。同时X11还有多屏幕适配的问题，尤其是两个屏幕的缩放配置不一样时根本无法使用的问题。我也不知道deepin到底用了什么deep♂dark♂fantasy魔法，神奇地解决了这些X11的问题。

1.4 Linux开发的共有优点——简单、无冗余

在Linux下进行开发——尤其是涉及到同样使用Linux的计算机的开发中，所有Linux都有一个优点——测试简单、工具链齐全、配置简单。例如在ROS开发中，Windows下需要先安装Linux虚拟机，然后根据ROS的官方文档一步一步配置ROS环境与工具链，然后才能开始开发。但是在Linux下，我可以直接使用Docker初始化ROS容器，然后通过外部IDE连接这个ROS容器进行开发。这样的好处显而易见——由于Docker的容器技术特性，我可以设置ROS代码映射到我的本地目录，在宿主机IDE中编写代码，然后在ROS容器中进行测试。现代容器技术（例如Docker、Kubernetes等）的核心技术基本都与Linux深度集成（在Windows下安装Docker需要先安装WSL，然后在WSL里安装Docker），加上大部分涉及Linux计算机的开发教程都提供了Linux下的开发与测试等的命令（例如大部分情况下测试后端API时教程会默认使用curl而非PowerShell命令）（是的，大部分AI API开发文档在提供纯命令行测试方法时使用的都是curl），使得Linux在涉及同系统开发的情况下十分吃香。

1.5 远程开发

是的孩子们，在Linux下进行远程开发的体验会比Windows下舒服很多；是的孩子们，我不一定要在我的开发机上使用Linux也能体验到Linux开发的舒适；是的孩子们，我甚至不一定要带电脑就能做开发。远程开发支持良好，意味着我在出门的时候也可以获得和在工作空间中一样的开发体验——这样的开发体验甚至不一定会要求我必须带电脑。例如在我的开发环境中，出门上课时用平板外接蓝牙键鼠，通过SSH或者网页版VS Code远程连接宿舍的单板电脑，在回到宿舍以后拉取代码到本地或者在电脑上继续用SSH，我能获得一个对网络要求相对Windows很低，但体验仍然优秀的开发环境。

2. deepin的缺点——为什么会变成这样呢？

2.1 磐石系统

目前版本中，磐石系统是作为默认选项安装在系统中的。这样的机制破坏了原本标准的Linux文件系统结构，在关闭磐石系统后，如果系统出现了任何无法正常使用的问题，由于磐石系统的特殊机制，在磐石系统下基本无法使用LiveCD正常修复。我个人认为，在安装时，安装器内可以默认开启磐石系统，但不应强制开启。可以在安装时提供一个磐石系统的开关，并配上对应的解释，供用户自行选择。我们能够理解特殊领域对不可变系统的要求，也能够理解deepin系统为这些特殊领域提供对应解决方案的初衷。但是在非定制环境下，总该给用户以选择权，以满足不同用户群体的不同需要。

2.2 专业软件缺位——是的，很要命

对于deepin——甚至整个Linux的各种发行版来说，最大的缺点就是专业软件的缺位。例如嵌入式软件开发中的Keil、设计中使用的CAD、SolidWorks、文档编写中使用的微软Office等的缺失，在部分场景下是不可接受的。在STM32的标准外设库开发中，根本不可能做到像HAL开发一样使用STM32CubeMX，甚至没有Keil工具链，根本就没办法或者很难在Linux下编译针对STM32的标准外设库固件；部分学习用开发板的ISP软件使用了专有的刷写方案，这些刷写方案和通用方案不互通，导致在Linux下直接无法刷写固件；部分外设对Linux的支持不足甚至没有，导致无法在Linux下调整外设参数与设置......这样的例子实在是太多太多了。

2.3 所谓的“平替”

当然，对于2.2提到的一些软件缺位，有些人可能会推荐使用替代品来解决。但是在这里，我要抛出一个暴论——如果替代品不能做到原软件全部甚至大部分的核心功能，那这样的替代品就只能被称为妥协，而非平替。在这里我们并不是要否定社区开发人员的精力投入——恰恰相反，我认为这些开源软件对我们日常的工作流产生了深远影响。

例如，如果我只需要给3D打印物品建模，我完全没有必要使用SolidWorks。相反，我可以使用Blender，因为Blender提供了简化的功能与操作，让我能够获得相比SolidWorks大幅度简化的建模体验；如果我需要制作软件的可视化模型（例如体系结构图、类图等），我完全没有必要使用StarUML，但是可以使用draw.io，因为draw.io提供了更多的图形、更易于操作的界面、更直观的绘图体验、纯文本的保存格式等；如果我需要对音频进行裁剪、反相等编辑的话，我完全没有必要选择功能更复杂的专有软件，但是可以使用Audacity，因为Audacity免费开源、可扩展性更强；如果我只需要做一个简单的独立游戏，我完全没有必要使用Unity，但是可以使用Godot，因为Godot提供了一切我所需要的必要功能，同时GD Script也更加接近我的已有技术栈，使我不必将精力放在框架本身的限制上。

那么“平替”的问题出在哪呢？问题不在开发人员，也不在这些软件的用户，更不在Linux与开源社区本身，而在于盲目推荐这些软件的人。这些人在不知道提问者需要专有软件的功能的情况下，盲目推荐替代品，美其名曰“平替”，但当提问者真的下载安装并打开这些被推荐的替代品时，会发现推荐的替代品和原先使用的软件就是“李鬼”和“李逵”的区别。但是如果现在提问者再去找推荐者时，却会被告知“那你要这个功能的话没办法”“我感觉很好用”一类的说辞。假设现在我们是这个提问者，经历了这样的事情以后，各位自己内心又作何感想呢？

这套“平替和妥协”理论同样也适用于AI生成代码领域。很多人不断地鼓吹所谓的“氛围编程（Vibe Coding）”，然而却忽略了这些工具的适用范围——如果在明显复杂到不便使用纯AI生成的项目中盲目引入Vibe Coding（即AI在项目中不具备人类程序员能做到的所有甚至大部分能力），那AI就不能被称为人工的平替，而是弥补个人技术栈不足与团队债务技术债务拖累的妥协。我们必须接受一个事实——工具只是工具，只存在适配当前需求与否，没有绝对优劣，也不存在要为了所谓“原教旨主义”而做出牺牲与妥协的说法。实用软件是如此，操作系统也是如此，实体工具也是如此。

2.4 碎片化——成也开放，败也开放

我们都知道，Linux的各种发行版为我们提供了非常高的自由度。理论上来说，我们在Linux下能做到的事情只取决于我们的技术水平与硬件的限制。但同时，这些自由度也带来了一个不可避免的后果——生态碎片化。这对于熟练使用Linux的用户来说可能不算一个缺点，但这对初入Linux或不能熟练使用Linux的用户来说是非常致命的。如果再叠加上我们在2.3中探讨过的推荐者的行为，相信大家也都猜到最终会发生什么了。

为什么我认为碎片化是Linux不可避免的现象呢？根本原因在于，这是Linux高开放性所带来的副作用。Linux内核的开放程度高与开源的特性，就注定了社区会为自己的受众打造一系列基于Linux内核与特定软件组的发行版。如果想要彻底解决碎片化问题，就要牺牲Linux的高自由度与开放性，这显然是社区中绝大部分人群无法接受的。开放与碎片并非一个取舍的问题，因为在Linux下开放与碎片本来就是对立统一的。相反，我们需要在开放和碎片之间寻找一个平衡点，使得Linux系统保持开放的同时对一般用户又不过于碎片化。好消息是：这个平衡点正是Flatpak、玲珑、APM等软件包管理器所致力寻找的。

3. 总结——因为仍有痛点，所以才有本文

虽然我个人十分喜爱在Linux下的开发体验，但这样的开发体验中，有一部分仍然是我们所避不开的痛点。如果我对这些痛点毫不关心或者我不喜欢在Linux下进行开发工作，那么我就不会写这篇文章。所以“我喜欢在Linux下开发”与“Linux下仍有不好用的东西”并不冲突，恰恰相反，正是同时具备了这两个前提条件，我才能写出这篇文章。所以对deepin 25.1甚至大部分的Linux发行版，我会做出什么样的评价呢？我的评价是：这些发行版已经脱离了小众系统的范畴，但因为这些痛点仍然客观存在，所以这些发行版仍然没有做好探索更广阔的用户受众的准备。