This thread has produced a lot of good discussion. Thinking overnight about this discussion, it seems to me that we are looking at a number of intersecting issues:
(1) Keeping the ISO reasonably current.
We all know this is an issue. Solus needs to keep the ISO more current (perhaps every six months) and that task is complicated and time-consuming.
A problem with a rolling release is that there is no obvious point at which a new ISO can/should be released, because the parts are always moving. If, for example, an ISO were to be released tomorrow, the ISO would, presumably, be based on the 5.15 kernel, already over six months old. However, if the team waits until a more current kernel (say 5.18 or 5.19) is adopted, ISO release must necessarily be delayed. It is a never-ending, thankless cycle, as anyone who has worked in IT management knows.
The Solus team is doing a remarkable job in keeping Solus stable and up-to-date, and is aware of the issue. I agree with @elfprince and others that the best course is to encourage the Solus team and support them in this respect.
(2) Kernel support for new hardware.
In general, support for Intel-based hardware is current because Intel does a reasonable job of developing Linux drivers and pushing them into the kernel. If Intel releases a new component, chances are very high that the driver for that component is included in whatever kernel is current when the component is released, or will be included in the kernel released immediately following release of the component.
Other hardware manufacturers have a spotty record in comparison. NVIDIA has been tripping over its shoelaces, again and again, with respect to providing current, backwards compatible, working drivers, for quite a while. AMD (CPU/GPU) is often slow about developing Linux drivers and pushing them into the kernel. I mention NVIDIA and AMD because both are active in the consumer desktop (particularly gaming) market, but other hardware manufacturers are also a problem in this regard.
(3) Manufacturers don't supply drivers.
RealTek is notorious for releasing components without Linux drivers, but numerous other manufacturers, particularly aftermarket suppliers like Cudy, don't bother with Linux drivers, either. The problem seems to be getting worse rather than better. I recall, for example, looking for an aftermarket external wifi adapter about a year ago, finding numerous "n" adapters that worked with Linux OTB but no "a/c" adapters that worked with Linux OTB. I've noticed this with other aftermarket suppliers, too; older hardware seems to be more supported than newer hardware. That suggests to me that hardware support for Linux is waning rather than gaining in some market segments.
(4) Kernel driver support.
The kernel often does not contain drivers for common components, even when the drivers exist. Using RealTek wifi adapters (a perennial problem across the various forums) as an example, community-based drivers usually exist but are not incorporated into the kernel. I don't know why, but suspect that either the developers don't submit the drivers to the kernel, or the drivers don't meet standards necessary for incorporation into the kernel. Either way, the end user is responsible for installing drivers and reinstalling when the kernel is updated. That is not a workable solution if the Linux consumer desktop market is to grow beyond developers and tinkerers.
(5) Lines of responsibility.
In the Windows ecosystem, lines of responsibility are more or less clear. Microsoft bears top-to-bottom responsibility for Windows (kernel, OS and DE), publishes reasonably clear compliance standards for OEM's and component manufacturers, requires OEM's and component manufacturers to provide working drivers for all components incorporated into any computer bearing the "Windows" sticker, and includes the drivers (or a generic equivalent) in ISO builds for a "clean" installation.
In the Linux ecosystem, lines of responsibility are much less clear, and seem to an outsider like me to be frequently tangled. The kernel is maintained independently of the OS layer (e.g. Solus) and both are maintained independently of the DE layer (e.g. Budgie, Plasma). Linux does not seem to have an equivalent of the Windows "sticker" process/program for OEM computers and components. As a result, Linux (at the consumer desktop level, anyway, less so at the server, cloud level where suppliers/manufacturers appear to have developed and enforce standards) suffers from frequent upstream/downstream disconnects and hardware compatibility issues.
Bottom Line: A Systemic Issue
Thinking about all of this, I keep coming back to a systemic issue. Linux is not well-developed in or for the consumer desktop market. The primary players in the Linux ecosystem are large corporations focused on the server, cloud, and other profitable markets rather than the consumer desktop market. I don't see that changing, given the bifurcated nature of the Linux ecosystem (server, cloud, and so on versus consumer desktop) and the widely dispersed, idiosyncratic, and low-resource nature of the consumer desktop segment.
I've thought about this over the last few years, and I keep coming back to Torvalds. It seems to me that the Linux consumer desktop market is going to have to develop a higher level of discipline/cooperation if it is going to build market share, both reducing the number of distros to a handful or two and focusing on the quality of those distros, and, perhaps, banding together in a consortium (similar to the consortium(s) that exists in the server/cloud markets) to develop and enforce standards. With respect to the consumer desktop market, no matter what string I start to untangle, that is always where I end up. Herding cats.
