In my experience, just using both the stable and LTS (Long Term Support) versions of the kernel avoids 99% of issues.

In the last two years, I have had drivers fail after an update twice. In one case, my laptop WiFi no longer worked (potentially huge problem as it does not have Ethernet). In another case, the webcam stopped working and I need it everyday. In both cases, I booted into the LTS kernel and was back up and running in under two minutes. In both cases, I tried the more up-to-date kernel a week or two later and found that things were working again. If I only had the one kernel, both of these would have been major issues. With two, they were nothing.

Out-of-date software versions cause more issues in my experience than too new versions cause on Arch. As does not having to work around software missing from the repos. In practice, I find Arch very stable and reliable.

EndeavourOS is almost indistinguishable from Arch once installed. On that we agree.

The idea that getting it there has no value is something we can disagree on. You do not have to agree with me. That is not a problem.

I just installed EndeavourOS on a 2020 T2 MacBook Air the other day. All the hardware worked flawlessly after the point and click install. Read the vanilla Arch instructions for that hardware sometime.

EndeavourOS offers a path to installing Arch that is painless and offers a high chance of success. It configures the system well. It is easy to recommend.

Same kernel as Arch, 99.9% of the software is installed from the same repos. AUR is enabled out of the box. Just works. No brainer.

And even though Arch only adds about a dozen optional packages on top of Arch, some of them are pretty useful.

This is a totally real question that I am hoping you can educate me on.

Why would you want to avoid dependency resolution?

An even better question might be, what is present in Fedora that is not also found in Debian?

Is it RPM? Because RPM was Free Software and GPL licensed for over a decade already when the Arch Linux project was started. And of course, RPM is used in many other distros including the apparently totally European driven and unfettered SUSE distro.

I cannot imagine what happened that required having to re-install EOS.

Based on your write-up, one of the Arch based distros is likely your best bet. My strong recommendation would be EndeavourOS. It is awesome.

If you use EOS, install both the current stable kernel and the LTS one. Use current day-to-day. In the very rare instance that you have a kernel or driver issue, boot into LTS.

Fedora is a great distro. As a non-American, I would say that you do not need to be so focussed on either IBM or the “American” control over Fedora.

1 - Fedora has a great community and a strong commitment to Free Software. Independence from Red Hat’s commercial agenda is the very reason it exists.

2 - Even in a worst case scenario, you are not locked into Fedora and switching is low risk and easy. There is little downside to enjoying Fedora now even if something was to happen later (however unlikely).

3 - modern Linux distros are almost all built from the exact same base elements. Fedora is really no more exposed than anything else.

4 - Red Hat is a driving force behind half the technology at the heart of whatever distro you will end up on including SystemD, Wayland, Pipewire, Glibc, GCC, and the Linux Kernel itself. To repeat point number 3, you are no less exposed to the influence of IBM/Red Hat on Ubuntu or even Arch.

I mean, you could use something like Chimera Linux that avoids SystemD, GCC, and Glibc. But you would still be using Wayland, Pipewire, and of course the kernel. And Chimera does not sound what you are looking for.

I would recommend EOS but I would not avoid Fedora for the reasons you cite.

Good job eliminating Ubuntu.

I have run both EndeavourOS and Chimera Linux on both 2009 and 2013 MacBook Pros. You would be amazed how well they run.

They are specifically interested in the ARM laptops for battery life.

To just directly answer your question, it seems the T14s is the best supported.

Ubuntu supports it in Ubuntu 25.04 but it does not look like there is support in Fedora yet.

You will probably have to install KDE yourself but it should work fine: https://linuxconfig.org/kde-desktop-installation-on-ubuntu-24-04

Um. No on Tuxedo.

The work Tuxedo is doing is on drivers for their own hardware. It has nothing to do with core Snapdragon SoC support and will do little to help other vendors. The delay has more to do with their internal priorities than anything else.

Core X Elite support has been coming into the kernel since 6.8. Support for your hardware depends on the availability of a device tree. Probably the easiest road right now is Ubuntu:

https://discourse.ubuntu.com/t/ubuntu-24-10-concept-snapdragon-x-elite/48800

The best supported hardware seems to be the Thinkpad T14s at this point. I am not sure where things are with Ubuntu 25.04. I would expect an update from Ubuntu soon.

Here is a more detailed account of support on a Yoga Slim and a screenshot of Chimera Linux running on HP OmniBook. So, Ubuntu is not the only option but it is likely the smoothest sailing.

https://www.wezm.net/v2/posts/2024/linux-on-yoga-7x-snapdragon/

It is early days for X Elite on Linux for sure. The same can be said for Apple Silicon of course.

[edit: it seems that Ubuntu 25.04 works out-of-the-box on X Elite: https://discourse.ubuntu.com/t/ubuntu-desktop-on-arm64-history-benefits-and-what-s-next/57775

Get it here: https://cdimage.ubuntu.com/daily-live/current/ ]

Amazing! Thank you for diagnosing this issue for the rest of us.

This is exactly why Open Source works and why even huge companies cannot keep up with Open Source software once it has taken hold. The users drive it forward in a way that money alone cannot match.

Old habits

The kernel part of the NVIDIA driver is Open Source now.

The NVIDIA problems are almost entirely legacy at this point. Unless you are using something that ships ancient packages (looking at you Debian Stable), you should be fine.

Started with Soft Landing Systems (SLS). Pre-Slackware. Many hours downloading floppy disk images at school.

Moved to Red Hat (pre-Fedora and pre-RHEL) until I think 7.3 or so and then Mandrake. I did trial runs with many distros over time but none of them really stuck. Fedora for a release or two. Spent a few years on Manjaro for desktop and CentOS for server. Have been on Arch for many years now (or EndeavourOS). Never used Ubuntu really.

Moved to Proxmox for server. Although I never used Debian historically, quite a few of the containers I have on Proxmox now are Debian based as is Proxmox itself.

Lately, I have been using Chimera Linux for desktop though I have an Arch Distrobox on it so I guess I am a bit of a hybrid at this point.

Glad you are enjoying Arch. I agree, it is no longer hard to install.

Do you have an example of something in the Arch wiki that does not apply to EOS?

I mean, I guess most people self-installing Arch are not choosing Dracut (though you could and the Arch wiki covers it). I cannot really think of anything else though.

I use KDE with Chimera Linux which is only in beta. Rock solid.

Arch users do not consider EOS as Arch but it absolutely is.

EndeavourOS uses the vanilla Arch kernels, the vanilla Arch repos, and the AUR. There are only a handful of packages in the EOS repos and the majority of them are theming or utils that are what you would use on Arch as well (like yay and paru). There are a few quality of life utils that are totally optional and most EOS users are probably not even aware of. Plus, I suppose, the EOS keyring and a couple of packages so that the distro identifies as EOS instead of Arch. Distro identification is the only thing that “overrrides” anything in the Arch repos.

I describe EOS as an opinionated Arch installer with sensible defaults. Once installed, it is just Arch.

It is trivial to revert EOS to vanilla Arch if you want to. I don’t think it even requires a reboot.

I have never had anything in Arch take months to fix. One tip I would have is to use both the latest kernel and an LTS. If something “breaks” with a kernel module, just boot into LTS and it is probably fine there. I also had an issue with WiFi for about a week but a quick reboot into LTS and I was good to go immediately. When I tried the latest kernel two weeks later, it had been fixed there. Something similar happened with my FaceTimeHD camera. Same solution.

Just recently repartitioned my MacBook:

1 GB for EFI (vfat)

2 GB for /boot (ext4)

11 GB for swap

224 GB for / (bcachefs)

Grub cannot load a kernel off bcachefs so I need ext4 to bridge the gap. Once the kernel is loaded, it has no problem using bcachefs as root.

This is a laptop. On a desktop that can handle more drives, I would split /home onto a drive of its own.