Is there a promise to not break non-Intel hardware? - “A Linux OS built for Linux developers”

I am a developer and would love to use Clear Linux on my main machine but I am on AMD Ryzen and I am curious if Clear Linux makes any guarantees to not break non-Intel hardware(I understand the “optimized for Intel CPUs” part but things like LTO are helpful for everybody)?

I worry for sudden breakages.

It is safe to use on non-Intel, x86 hardware or you would not recommend it?


We publish “minimum hardware requirements”. If your system meets these requirements, then it would be a bug if it doesn’t work. We recently removed the requirement for AES, so, a lot of hardware now can run Clear Linux OS.

If we add new requirements, then we will announce this well ahead of time, for the obvious reason that we would break many existing systems/installs. Note: we have no intentions of ever doing this.

So essentially, that’s about as close as a promise as we can get.


I’ve hit some issues with some AMD options being explicitly deactivated:

Is there a way for me to change the kernel config and still receive official kernel updates(Gentoo style, somehow through mixins or something like this?) or would I need to maintain/compile my own version of the kernel?

This just needs fixing… We should put some time to enable that and provide (if we can) the microcode images just like we do for the Intel ones.

Are there any other options you’ve found?


I see CONFIG_AMD_MEM_ENCRYPT and CONFIG_AMD_NUMA activated in Ubuntu’s config files.
NUMA does not affect me directly, but I don’t know about people with Threadripper for example - the documentation says that it should work with CONFIG_X86_64_ACPI_NUMA, which is activated.

1 Like

Btw, it did brake in the end, for all Zen CPUs, through a kernel update(the kernel version was reported) and after 2 weeks(I had a backup work system, so I could wait a bit), I had no choice but to switch to a more stable distro.
It affects cloud users also.

What broke? Nobody filed a github issue on this, as far as I can see.

I am not the OP but I’ve had no issues with Clear on my Ryzen APU system I built for Christmas. It doesn’t use the “haswell” path as expected however when I benchmarked that, adding it back in didn’t impact performance in any remarkable way. Link on AVX2 benchmark

I did file the firmware enablement request on github. I could see some people, especially on a server wanting the mem encrypt functionality but I wouldn’t want that enabled by default since it has a negative performance impact (hence I didn’t file any request on that). Other distros seem to enable it but not by default so it can be turned on with kernel command line flag. The AMD Numa flag appears to only be for some legacy systems as newer ones use already enabled code.

It runs next to a Skylake laptop also running Clear and its pretty transparent to go back and forth between them.



1 Like

With the nature of the PTS tests that is kinda expected as they generally don’t use many system libs. If you test what’s actually executed, you may find the only difference of your patch in these tests is that it’s using /usr/lib64/haswell/ instead of /usr/lib64/ as the rest of the test files are compiled in a local directory for the native CPU. libc I can’t imagine is that sensitive to an AVX2 build as it already includes SSE4/AVX optimized paths where they do make a difference.

The r benchmark is the only test where I think there would be a discernable difference.