啊哈
@忘记、过去 之前ACE遇到这个情况但是并没有回复,现在终于知道是什么导致的问题了
啊哈
@忘记、过去 之前ACE遇到这个情况但是并没有回复,现在终于知道是什么导致的问题了
我猜对了一半,可把自己厉害坏了(叉腰)
很明显这个是deepin桌面设计bug被触发了,按照这个“导致宿主机的gvfs-udisks2-volume-monitor.service启动失败,进而造成桌面某些组件响应缓慢。”描述,只需要搞个恶意程序写入低版本配置就可以让整个桌面缓慢,说白了就是桌面系统本身的bug
按照互联网公司的标准这是个起码p1级事故
deepin v23刚发布,出现bug,可以理解。社区版嘛,本来就是用来踩坑的,期待不可变系统早日出来!
deepin v23刚发布,出现bug,可以理解。社区版嘛,本来就是用来踩坑的,期待不可变系统早日出来!
v23测试了差不多2年了还出这种p1级故障,一个应用能够影响一堆应用,如果只是某个应用受影响还可以理解
玲珑应用使用独立的目录,而dde这些系统应用,会使用到玲珑的配置文件,就离谱,绝对的重大bug,而解决方案卸载玲珑也是离谱,社区那么多人反馈,没有第一时间出一个临时解决方案,还要用户自己去尝试解决。只能说干事的人不知道,知道的无所谓。
v23测试了差不多2年了还出这种p1级故障,一个应用能够影响一堆应用,如果只是某个应用受影响还可以理解
deepin是类似Fedora的非商业化产品,更新后不保证高稳定性,如果需要高稳定建议转步UOS
玲珑应用使用独立的目录,而dde这些系统应用,会使用到玲珑的配置文件,就离谱,绝对的重大bug,而解决方案卸载玲珑也是离谱,社区那么多人反馈,没有第一时间出一个临时解决方案,还要用户自己去尝试解决。只能说干事的人不知道,知道的无所谓。
ll-package-manager是要常驻内存的,应该是这个程序启动时需要使用配置文件,错误的配置文件可能会影响到其他系统服务。
玲珑应用使用独立的目录,而dde这些系统应用,会使用到玲珑的配置文件,就离谱,绝对的重大bug,而解决方案卸载玲珑也是离谱,社区那么多人反馈,没有第一时间出一个临时解决方案,还要用户自己去尝试解决。只能说干事的人不知道,知道的无所谓。
发现bug全靠用户踩坑,认为开源就可以一切问题用户来发现,这种常用应用起码放在测试环境测试一下,性能基准测试跑一下就能发现问题,起码的尊重用户态度都没,用户可以帮你发现一些很少概率下才能触发的bug,不是帮你发现这种基础bug的
修复问题按照华为所在的运营商算,这会处罚金已经把deepin罚破产了,看看这个响应问题的速度绝壁让人头疼的服务质量
描述问题还轻描淡写,尽量不说桌面系统的设计bug,尽量把问题扯到应用层的bug,明明系统层的bug
没看懂,意识说不是完全隔离吗?玲珑应用不是只安装在容器内?
deepin是类似Fedora的非商业化产品,更新后不保证高稳定性,如果需要高稳定建议转步UOS
我只有1台转v23,有3台从v20 转ubuntu22了,我都是并行测试不同版本,这次升级是因为我的用户用的ubuntu22版本部署我的应用,我顺便测试一下deepinV23,没想到2年了v23稳定性如此之差,本来还想应用支持一下deepinV23环境的部署,现在只能放弃支持deepin环境
发现bug全靠用户踩坑,认为开源就可以一切问题用户来发现,这种常用应用起码放在测试环境测试一下,性能基准测试跑一下就能发现问题,起码的尊重用户态度都没,用户可以帮你发现一些很少概率下才能触发的bug,不是帮你发现这种基础bug的
修复问题按照华为所在的运营商算,这会处罚金已经把deepin罚破产了,看看这个响应问题的速度绝壁让人头疼的服务质量
描述问题还轻描淡写,尽量不说桌面系统的设计bug,尽量把问题扯到应用层的bug,明明系统层的bug
搞个恶意应用把系统核心文件删掉,然后导致系统起不来。按照你的想法是不是也算是系统设计存在缺陷呢?
搞个恶意应用把系统核心文件删掉,然后导致系统起不来。按照你的想法是不是也算是系统设计存在缺陷呢?
你搞清楚配置文件根删除核心文件的区别,配置文件是合法修改,你能被自己提供的配置文件接口轻松搞死难道不是设计bug?linux谁也没有说提供了删除核心文件还能正确工作的说法,你自己提供了配置文件接口,还被旧的配置文件搞死,这不搞笑么?
你搞清楚配置文件根删除核心文件的区别,配置文件是合法修改,你能被自己提供的配置文件接口轻松搞死难道不是设计bug?linux谁也没有说提供了删除核心文件还能正确工作的说法,你自己提供了配置文件接口,还被旧的配置文件搞死,这不搞笑么?
修改配置文件配置项当然是合理的。移除了本该存在的项当然就不算是合理了。
我举的例子是偏颇极端了一点。但是配置文件导致的系统异常也不是 deepin 或者 linux 上独有的问题。
修改配置文件配置项当然是合理的。移除了本该存在的项当然就不算是合理了。
我举的例子是偏颇极端了一点。但是配置文件导致的系统异常也不是 deepin 或者 linux 上独有的问题。
别洗地了,好好做好系统,别在犯这种严重低级错误,连配置接口都能把自己系统玩崩溃的,在哪里都是严重bug,尤其在一个各个上层应用都依赖的系统上犯这个错误妥妥的p0级故障,并且是连夜要修复的那种紧急故障,而不是甩锅给应用
更新了,问题还没解决,玲珑还是1.6.0,不是1.6.1
又爱又恨,我只能呵呵了!
即使是漏洞也不奇怪,windows这么多年还报漏洞呢。何况是基于内核打造的根社区版,不像ubuntu是基于成熟的debian发行版,v20也是基于debian发行版,就要稳定的多。总要有人敢吃螃蟹嘛!
还是那句话,追求稳定请选择UOS,社区版就是用来踩坑的。
背景
近期收到了来自不同渠道deepin 23用户对于系统文件管理器或其他系统组件性能大幅下降的问题,在结合deepin开源社区热心用户的参考解决方案后deepin内部研发团队针对此问题进行了相关定位、方案评估。
问题
通过应用商店安装的部分玲珑应用会向系统玲珑的目录(/var/lib/linglong/entries/share)中写入低版本的gsetting-desktop-schemas配置文件,导致宿主机的gvfs-udisks2-volume-monitor.service启动失败,进而造成桌面某些组件响应缓慢。
解决方案
加入deepin 23内测通道的修复方案
升级玲珑的版本到1.6.1, 升级完成后,可以在终端执行
ll-cli --version
,返回结果为1.6.1
代表玲珑组件升级成功,重启系统即可修复该问题。* 该修复预计随本周内测一起推送,请在接收到内测推送后升级系统。
未加入deepin 23内测通道的修复方案
考虑到部分用户暂时未有意愿加入deepin 23内测通道,需要参考以下操作进行人工修复:
/var/lib/linglong/entries/share/glib-2.0
目录systemctl --user restart gvfs-udisks2-volume-monitor.service
建议
为了获得最前卫的特性功能和更及时的问题修复,建议加入deepin 23内测通道并将系统升级至内测版本:
控制中心
==>更新
==>更新设置
==>内测通道