从很早的版本就开始关注FydeOS，主要身边的设备从Core2Duo到11代酷睿都有，我看了一下其他类似的方案都是一个镜像包包含所有的架构，为什么就FydeOS需要特立独行搞成不同的镜像，我身边4种架构的设备都有，要运行要写4张优盘，实在是没动力使用了，整合成一个有那么困难么？Debian，AndroidX86等也都是一个镜像啊，真的希望不要这样继续拆分了，只有合并成一个通用镜像才有希望。。。
chromeos是每个设备一个恢复镜像，你觉得是为啥不整成一个包？Google太闲了，喜欢维护那么多镜像么 
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，也小小期待一下，哈哈哈。
国庆中秋快乐！
晚安。
这个问题，我觉得选择权在你手里，只要你只采购一种架构，那么就只需要一个镜像包。