deepin /usr/local只是个别会用到，还不够“一般”。日常开发你会遇到大量使用/usr/lib /usr/share ……等各个目录的情况。举个最常见的例子，/usr/share/applications这个目录会存放很多应用的启动图标文件，按照常用惯例也是写入这个文件的，遇到这种你就只能改代码。
有的应用图标是白标，自己添加图标还要关闭磐石，可以更精细化，但目前磐石系统做得不行
我好奇如果可以自由关闭开启磐石，在知道的情况下，到底是关闭的多还是开启的多，毕竟关闭再开启要重启两次，也很麻烦
deepin 有的应用图标是白标，自己添加图标还要关闭磐石，可以更精细化，但目前磐石系统做得不行
我好奇如果可以自由关闭开启磐石，在知道的情况下，到底是关闭的多还是开启的多，毕竟关闭再开启要重启两次，也很麻烦
我的话，会关掉磐石后，不再开启
因为这玩意儿给我造成的麻烦，远大于带来的收益
deepin 磐石系统文档太少，不了解原理。无法评价。但就使用体验来说，是负面的。
deepin /usr/local只是个别会用到，还不够“一般”。日常开发你会遇到大量使用/usr/lib /usr/share ……等各个目录的情况。举个最常见的例子，/usr/share/applications这个目录会存放很多应用的启动图标文件，按照常用惯例也是写入这个文件的，遇到这种你就只能改代码。
偏服务端开发，日常涉及大多数的组件和引用库，在用户级目录都可以处理，以往我在ubuntu,fedora等发行版一概如此，其他领域我没涉及过，可能是这样吧。
deepin 偏服务端开发，日常涉及大多数的组件和引用库，在用户级目录都可以处理，以往我在ubuntu,fedora等发行版一概如此，其他领域我没涉及过，可能是这样吧。
接你举例的应用写入图标或者快捷方式，我认为大多部分的桌面应用在这步都是写入用户级目录的（~/.local/share/applications），至少我在fedora kde上看是这样的
deepin 有的应用图标是白标，自己添加图标还要关闭磐石，可以更精细化，但目前磐石系统做得不行
我好奇如果可以自由关闭开启磐石，在知道的情况下，到底是关闭的多还是开启的多，毕竟关闭再开启要重启两次，也很麻烦
有的应用图标是白标，自己添加图标还要关闭磐石
这个应该是不用的。 ~/.local/share/ 也是会生效的，不是一定要放到 /usr/share/ 下。实际你可以观察一下 XDG_DATA_DIRS 的值，会是一个列表，里面所有的路径只要存在就都能用/生效。
作为用户（财务工作），我只关心日常办公功能，能用就行，具体底层怎么执行，我不关心
目前磐石对你的日常使用有影响吗？
我几乎感受不到磐石存在，只有在卸载玲珑应用后，要清除玲珑的一些文件不让删除时才感受到这个系统的存在，其他时间升级备份这些感受有一点点，就是升级需要等待的步骤多了1-2个
磐石无感知的体验也是我们想要达到的最终目的
deepin 这些选项都太标签化了，除了引发骂战或妥协以外想不到其他可能的出路。我们能不能看看到底引发了哪些软件不可用的问题，我现在看到反馈的就是ollama、virtualbox、一个VPN软件，还有啥？
还有导入Fcitx5皮肤、安装Tailscale等，我在Discussion #11921里列举了一些
deepin 首先，磐石不完全是个负面的技术引入，对于非技术人员来说，如果用好了，稳定性、安全性、备份恢复移植都有巨大好处。
但是咱也得承认，磐石的引入确实带来了一些问题，特别是对我们这些技术人员来说，干扰很大，一些开源工具，需要本地自行编译的，都需要在/usr/*下释放文件和各种lib库，有磐石的情况下无法写入会编译失败，小工程还能靠修改make file或configure进行调整临时顶一下，但遇到各种依赖多的大型工程，这简直是个不可完成的任务。座技术开发的兄弟们都懂！
介于目前系统架构的问题，建议还是加个开关更好，同时满足非技术人员和技术人员的需求，不要一刀切，也符合用户体验。
你可能需要这个：
[经验分享] 在deepin25环境中创建无磐石的deepin25子系统
deepin 非要写/usr的，完全可以做一个deb包，把需要的程序文件传递进去。
一般情况下，/etc，$HOME/.local/share，$HOME/.local/bin，这些可写的目录，很够用了。
deepin 放到 ~/.local/bin 或者自己加 PATH呢？
加一个界面，可以让用户图形化加path吧，这样大家都好。
想了想还是投了“支持磐石，安装系统时应提供选项，控制中心时提供图形开关。”
原子更新、自动回滚、系统快照这些功能非常有用，一切问题都出在只读挂载上。
为了系统稳定性，破坏了系统兼容性。这是不是有点得不偿失了？
设计出现在这套系统的人貌似对unix-like文件系统结构各级目录的作用都不清楚。即使要满足信创认证“不可变系统”的要求，也没必要实现成现在这个鬼样子啊。为什么不利用一下OverlayFS呢？让磐石系统拥有三种模式：
这么干的好处是在三种模式切换不需要重启，相比于现在的方案应该是一大改进。
deepin 想了想还是投了“支持磐石，安装系统时应提供选项，控制中心时提供图形开关。”
原子更新、自动回滚、系统快照这些功能非常有用，一切问题都出在只读挂载上。
为了系统稳定性，破坏了系统兼容性。这是不是有点得不偿失了？
设计出现在这套系统的人貌似对unix-like文件系统结构各级目录的作用都不清楚。即使要满足信创认证“不可变系统”的要求，也没必要实现成现在这个鬼样子啊。为什么不利用一下OverlayFS呢？让磐石系统拥有三种模式：
这么干的好处是在三种模式切换不需要重启，相比于现在的方案应该是一大改进。
赞👍
deepin 想了想还是投了“支持磐石，安装系统时应提供选项，控制中心时提供图形开关。”
原子更新、自动回滚、系统快照这些功能非常有用，一切问题都出在只读挂载上。
为了系统稳定性，破坏了系统兼容性。这是不是有点得不偿失了？
设计出现在这套系统的人貌似对unix-like文件系统结构各级目录的作用都不清楚。即使要满足信创认证“不可变系统”的要求，也没必要实现成现在这个鬼样子啊。为什么不利用一下OverlayFS呢？让磐石系统拥有三种模式：
这么干的好处是在三种模式切换不需要重启，相比于现在的方案应该是一大改进。
确实，这样对用户的干扰比较小
deepin UOS可以在打开开发者和关闭安全中心的允许应用安装的时候提示关闭磐石
那么deepin如何让用户能够有感知到开启了这个东西和会关闭，就成了一个需要思考的问题
毕竟别的系统安装成功的deb，到这里都安装失败，然后再发帖，别人再说关闭磐石
这个过程就很掉磐石的好感度 => 已经看了不只一个贴因为不知道磐石这个东西，导致问题，然后下面都是教怎么关闭的
不是这个东西不好，是交互和对开发者不友好
不无所谓，我就是有其他观点要说。关于磐石这件事，因为uos和deepin面对的大多数都是技术上不够过硬或者不太了解linux的同学，所以磐石默认开着是很好的选择。但是关于关闭磐石，我有话要说。 在产品设计上，有一种防止手抖的设计是“确认连续”（非专业人员，自己造的词），为了防止有人不看不理解就同意，会让用户手动输入一些重要后果比如“数据永久删除无法恢复，确认注销”之类的词。deepin、uos在开启开发者模式（当然deepin本来就没有锁root权限）后终端关闭磐石也好，控制中心关闭磐石也罢，然后将确认数据传送至deepin服务器这样（？或许有可以优化的地方，请各位大佬不吝赐教）。 正如大佬所言，对于默认啥都不懂的用户，把他们的系统保护起来总比让他们瞎搞搞坏了强。如果用户真的想要关闭磐石的话，那么手动输入确认信息会再起一次强调作用，就像申请银行卡和手机卡一样，需要手写一些确认不转租转借之类的。 说到这里了，我更想说一句虽然deepin和uos关于应用商店里上传的包的想法很好，但是不太建议继续延续uos标准了。标准deb本身就很好，希望deepin和uos可以在自身系统稳定后考虑重新恢复标准deb标准。有个相关的想法是，留一个1G左右的小live环境（用于修复、恢复或者跨大版本升级之类的）隐藏起来，按F8或者什么Ctrl+F12之类的才可以启动，然后备份的话其实完全可以取消掉（这个已经有可选了，赞！） 嗯，就先这样吧，关于磐石我目前想不到什么想说的了。
deepin 磐石初衷是好的，最终目标也是 用户无感，当前肯定是 用户有感
站在官方角度，肯定希望大家用磐石，以便发现问题，加以改进
站在用户角度，当前的磐石，多多少少会造成干扰，带来不便，倾向于关闭磐石
中国人讲究中庸，看看如何找出对双方都有利的方案
deepin 最典型的场景就是遥望/usr/bin丢一个二进制软件，这就很麻烦。
为什么要丢在/usr/bin? 放在opt里面不也一样吗,然后再添加环境变量路径到PATH.
deepin /usr/local只是个别会用到，还不够“一般”。日常开发你会遇到大量使用/usr/lib /usr/share ……等各个目录的情况。举个最常见的例子，/usr/share/applications这个目录会存放很多应用的启动图标文件，按照常用惯例也是写入这个文件的，遇到这种你就只能改代码。
可以放在~/.local/share/ icons和applications文件夹里面，不是一定是usr/share里面的
Popular Ranking
ChangePopular Events
More
中文 
Will Deepin Video player get AI subtitle translation?
磐石话题，经久不衰，各有各的理，那就让数据说话吧，有具体问题的请详细说明，这很重要。