为什么FydeOS就是不能整合成一个镜像包呢?

从很早的版本就开始关注FydeOS,主要身边的设备从Core2Duo到11代酷睿都有,我看了一下其他类似的方案都是一个镜像包包含所有的架构,为什么就FydeOS需要特立独行搞成不同的镜像,我身边4种架构的设备都有,要运行要写4张优盘,实在是没动力使用了,整合成一个有那么困难么?Debian,AndroidX86等也都是一个镜像啊,真的希望不要这样继续拆分了,只有合并成一个通用镜像才有希望。。。

chromeos是每个设备一个恢复镜像,你觉得是为啥不整成一个包?Google太闲了,喜欢维护那么多镜像么 :face_with_peeking_eye:

1 个赞

这个… 你要不要看看自己在说什么?
你说同架构不同硬件想一个镜像我还能理解,不同架构一个镜像是什么逻辑?你要不要自己去看看Debian官网…

Androidx86,它都写X86架构了… 一个镜像很正常啊…

至于非X86的架构,例如arm和riscv,也是一个硬件一个镜像… FydeOS跟他们没啥不同…

1 个赞

作为工程师,正面回答一下您的问题:

首先,从编译优化角度来说,编译器对不同的CPU是有不同编译优化开关。比如新的CPU支持AVX512指令集,这对于软件解码有降低能耗的作用,但老的CPU不支持。为了能在老旧CPU运行,就不能打开新的CPU指令集支持。对于FydeOS来说,通常运行于各种不同时代低端CPU上,这类的编译器优化,有时很重要。

其次,从内核驱动的角度,尽管同是X86体系,并不是越新的内核越好。每年都有很多老旧驱动从内核中去掉,为了保持对老旧硬件的稳定支持,有时候就只能卡在一个版本号上。对于新硬件,又只有新内核才能支持。把旧驱动移植到高版本内核,或者反向移植,就是希望用一个内核版本支持更多硬件。

再次,用户空间的动态库也在更新中不断改变硬件支持。最典型的就是MESA库。从19.0到现在的25.x,无论是硬件支持还是本身的形态改变都是巨大的。每一次为了优化图形升级MESA库,都可能在某类图形芯片上遇到问题。支持旧硬件和支持新功能,变成了一个不可兼得的事情。vulkan api在新的iris上表现出色,但在旧一些的915上会出现贴图错误。

当然,以上的仅仅是困难,并不是说技术上不可克服。但要解决这些问题,需要大量人力物力和时间。现在有了AI辅助,未来有可能实现这个目标。起码在我们在v21把内核版本都同步到了6.6(放弃了legacy 版本的基础上)。

每年两个大版本更新,每次都需要在保证稳定性的基础上,升级到尽可能新的版本。如果新的版本有新的特性,就需要检测打开这个特性是否带来副作用。可能最后花费很大力气做了优化,只能带来启动速度微不可查的提高,或者图形性能提高了1%,或者解码CPU占用降低了5%,或者副作用太大返回原来……很多时候大家确实无法感知。但当把FydeOS和其他linux系统比较的时候,甚至跟ChromeOS flex比较的时候,就能展现出某些不同。(为硬件团队辩解一下,并不是只会编译现成的内核)

最后,我们现在确实有能力在x86平台支持更多的硬件功能,比如加速传感器,指纹解锁等(Fydetab duo能支持的)。但这些特性即便在ChromeOS上,也是根据硬件单独设定开启的(不是自动检测,而是预先配置)。比如我们在v18左右就移植了libfprint并且开源了代码。我们还开发了hwtuner在命令行解决硬件冲突,配置内核模块参数,连接wifi,甚至调节触摸板的参数。这些附属的代码也代表FydeOS与ChromeOS flex追求的不同。我们当然希望FydeOS能自动适配大部分硬件,提供最佳性能,但也深知能力有限,只能多提供一些支持,让大家有可能自己解决问题。

2 个赞

非常感谢您的回复,至少FydeOS我是真的觉得非常好用,但是就是因为身边设备太多了,而且一个镜像都要8g多,三个镜像就24g了,没发兼容多代设备是我一直觉得很可惜的事情,很开心能听到你说

至少证明您也有过跟我类似的想法,想要整合硬件支持,当然我知道目前有很多困难,比如您讲的图形库的支持等,只能说作为一个备选方案吧,我目前用11代酷睿比较多,所以我目前就下载了一个镜像,非常感谢FydeOS团队的伟大付出,将我们能够无缝体验ChromeOS,也小小期待一下,哈哈哈。

国庆中秋快乐!

晚安。

这个问题,我觉得选择权在你手里,只要你只采购一种架构,那么就只需要一个镜像包。