WetGeek Windows is not FOSS. If they can't get their OS installed, they don't get paid for it. That's a simplification, of course, but they're highly incentivised to make sure their OS will install on any compjuter.

Yup. You've just identified the problem. Developers/maintainers of the Linux kernel have little or no incentive to shape the kernel in the direction of consumer desktop computers or waste limited resources doing so. Microsoft, on the other hand, has enormous financial incentives to do whatever it takes to continue to dominate the consumer market.

The bulk of the kernel's code and financial support comes from companies focused on the server, cloud and Android markets. To the extent that Linux on the desktop is supported, the focus is on business/enterprise computers rather than consumer computers. The financial incentives are all on the side of shaping the kernel to run efficiently on servers and business/enterprise computers.

That's why you see high levels of support for all-Intel setups and lousy support for consumer outliers like NVIDIA, AMD and RealTek. It is a chicken and egg problem, in the sense that Linux has about 1-2% of the gaming market, for example, so NVIDIA has little incentive to dump resources into well-designed Linux drivers, but the Linux gaming market isn't going to grow unless and until NVIDIA does so. Everywhere I look at the Linux consumer desktop market, I see the story replayed over and over again.

Reading Linux boards over the years, I've been impressed with the strength of the idea that Linux is community-based, developed by and for altruistic FOSS believers. I think that's a myth, myself, and I think my observation is supported by the fact that Linux dominates the server, cloud and Android markets, where there is plenty of money being made by the companies developing for and profiting from those markets, and the fact that Linux doesn't seem to be able to get its act together in the consumer desktop market, where there is no money to be made.

    tomscharbach You've just identified the problem.

    The other part of the problem is that the Windows team has thousands of developers and testers, and can pretty easily create their own device drivers once the new device specs are released. If the OEMs come up with even better drivers eventually, those can be installed later, as you suggested. There's no Linux team that can compete with that.

    Often, when I was working with Windows and checked on the availability of updated drivers, I was told that the Microsoft driver that was already installed was the best one available.

      WetGeek Often, when I was working with Windows and checked on the availability of updated drivers, I was told that the Microsoft driver that was already installed was the best one available.

      Yup. Contrast that with your experience with the Linux kernel, or, if you have not personally experienced installation failures, the experiences of others related on the various Linux forums you read.

      I am not trying to trash Linux on the desktop, but I've waited 15-16 years now for Linux on the desktop to expand beyond a 2-4% market share, and make inroads into the consumer desktop market. I've given a lot of thought, from the perspective on a retired business/enterprise IT manager, to the reasons why Linux on the desktop remains stuck. The reason, as far as I have been able to tell, is that the resources available to Linux are focused elsewhere.

      I don't know how to get out of that hole, but I can see the hole as clear as day. Look no farther than Ubuntu's website, looking at how the site is focused, and you can't avoid the fact that Ubuntu is enterprise, server and cloud focused. Move upstream from Ubuntu to Canonical, and the focus becomes even clearer -- Ubuntu, probably the most-used desktop environment in the Linux universe, is described as "The new standard secure enterprise Linux for servers, desktops, cloud, developers and things." Do you see a focus on the consumer desktop anywhere in the Ubuntu/Canonical business model?

        tomscharbach I've noticed over the years that Windows installs "generic" drivers for components when a specific driver is not in the Windows installation ISO. For example, when I do a clean install, Windows will install a generic display adapter driver and a generic display driver, as well as generic USB port drivers, on initial installation if component-specific drivers are not in the Windows ISO. Windows nags me to install proper drivers until I get around to it. The "generic" drivers are dumbed down and don't offer full functionality, but the installer doesn't end up with a blinking cursor and frozen installation, either. I've not had an installation fail with Linux (in part because I've used only Ubuntu and Solus and in part because my computers are vanilla Intel), but I'd be frustrated as hell if I got a blinking cursor when installing.

        not a fan of the foss version of this. in WIN it's all seen in the device manager. as a user its frustrating to see all the se unidentified 'generic' devices/generic drivers in the tree. even 'properties' won't tell you much. so it's 'ok you let me update it, but don't tell me what it is.' so this disconnect between user (well, me at least) and device manager. at least, if implemented in theory, I'm sure foss would me more transparent anyways.

        WetGeek , I was told that the Microsoft driver that was already installed was the best one available.

        yeah I was/am always skeptical of that stock dialogue

        WetGeek I just don't want to see the folks with new hardware after the upcoming holicay season unable to use Solus.

        it certainly won't affect all (or even most?) potential solus users with new hardware, just some, right?

          brent it certainly won't affect all (or even most?) potential solus users with new hardware, just some, right?

          Just those with new devices -- video cards, autio cards, netwrok cards, etc -- that don't have usable Linux drivers yet. It would be nice if there could be non-optimal drivers for the .ISO files that would at least allow the OS to be installed, even if they needed to be updated soon after.

            tomscharbach I've waited 15-16 years now for Linux on the desktop to expand beyond a 2-4% market share, and make inroads into the consumer desktop market.

            I like to think of us as the privileged few instead of the minority.

            WetGeek It would be nice if there could be non-optimal drivers for the .ISO files that would at least allow the OS to be installed, even if they needed to be updated soon after.

            has any other distro done this I wonder? having drivers that fluid could come with pros/cons but I get what you are saying.

              Apparently no one is inteested in supporting users with new hardware. How could that be off-topic in a thread about improving installations of working .ISO files?

                brent Has any other distro done this (developed generic drivers for the ISO files) I wonder?

                I don't see how distro developers could do that because few have the resources needed. The "big three" (Canonical, RedHat, SUSE) probably have the resources (Canonical, for example, is reported to have several thousand paid employees) but where is the incentive? Intel is good about developing Linux drivers and getting those drivers into the kernel, so there is little incentive to develop redundant "generic" Intel drivers, and none of the "big three" have any financial incentive to create "generic" drivers for consumer desktop (e.g. NVIDIA, AMD, RealTek) components, because consumer desktop market is neither a profitable nor an important market for them.

                  tomscharbach I was 100% asking naively without a clue how iso/drivers work together. Thanks for being gentle. It's not something easily accomplished by a team to make an iso install more accessible to more users via generic drivers, then. Seems unrealistic in this light.

                  WetGeek
                  Because it is a discussion about what is required to help some users who have problems not an actual user requesting help, so yes I think the tag "off-topic" is better suited. Perhaps even feedback but certainly not support.

                  There is absolutely nothing that can be done to fix these users issues other than updating the ISO. That is the real solution, no other solution is either possible or less work than just updating the ISO. I swear I have said this before.

                  Everyone on the team knows this is a problem. Everyone on the team wants a new release tagged ASAP.

                  There are updates that are supposedly planned for next week which would make sense doing before updating the ISO and last time I built an ISO I could not boot my laptop off it, it threw some errors, but my main system could. At least one other team member could reproduce it on a virtualbox I believe so that should be investigated and solved or who knows how many people won't be able to boot. etc, etc (This is not an indication that an ISO update is soon, just stating facts).

                  It is not being held back to be mean or ignoring the problem. We know exactly what we have to do.

                  Personally I would like to see us release a alpha / experimental ISO that isn't advertised on the sites download section, and just provided by a link in pinned thread on the forums for those who need it given we have gone so long without providing a refresh. No blog post, no extensive testing, no version bump, just provide a band-aid until we have shit sorted.

                    Harvey It is not being held back to be mean or ignoring the problem.

                    I don't think any of us believed that. Thanks for your contribution to our discussion. Good luck next week!

                      WetGeek I don't think any of us believed that.

                      Maybe not here but those people do exist, automod has blocked stuff before with claims in the same vein as that.

                      Going to change the tag again, I think feedback makes more sense. (Still a discussion but you know what I mean).

                      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.

                      Harvey Personally I would like to see us release a alpha / experimental ISO that isn't advertised on the sites download section, and just provided by a link in pinned thread on the forums for those who need it given we have gone so long without providing a refresh. No blog post, no extensive testing, no version bump, just provide a band-aid until we have shit sorted.

                      I think this could be a reasonable temporary solution

                      This has been a very interesting thread to follow and good discussion I believe. I'm tardy to the party, but I think Harvey's proposal of an "experimental" .iso is probably the best solution we could ask for currently. As many others have said the team is doing an amazing job keeping things updated and stable weekly, let's believe in them and support them.
                      If you're looking for more of a Tumbleweed vs Leap experience, I believe Solus can provide that currently. Just switch to the unstable repository. Yes it's not tested and verified working or safe, but essentially Tumbleweed is the arch chaotic version of SUSE. An update drops, and update is pushed, it's drinking from the fire hose. I ran tumbleweed for a while, there were sometimes dozens of updates a day.
                      When it comes to supporting newer hardware and features, Tom has done an excellent job outlining some of the major problems that not only the Solus team face, but also the larger distro community as a whole. I remember when another popular distro was being derided because they didn't offer high DPI support. The reason was because none of the team members had or could afford a 4K monitor to test on.
                      The discussion of newer vs older hardware seems to be pretty heated, but still civil and interesting. In the end as elfprince said, the team will make the decisions here, we just have to trust them. As someone who has 14 year old hardware and 6 month old hardware, it would be nice for newer hardware to be supported. i've run into a few distros that wont boot on the 6 month old build. Everything will boot on the 14 year old machine, but very few will produce a usable experience. Not all old hardware can be supported indefinitely and not all new hardware will see support right away, we have to trust the team to make the best decisions we can around these issues.

                        Brucehankins Tumbleweed is the arch chaotic version of SUSE. An update drops, and update is pushed, it's drinking from the fire hose. I ran tumbleweed for a while, there were sometimes dozens of updates a day.

                        LOL. I ran Tumbleweed in a VM last winter for a few weeks when I was testing different Budgie distos, and it drove me nuts. The ISO is huge (4.5 GB as I recall), takes forever to download and install, updates (usually hundreds of files) more-or-less daily, and (at least vis a vis the Budgie desktop, which is installed as an add-on) had stability issues. I gather Arch is like that, but I've never run anything Arch. My Tumbleweed takeaway: I learned to love the word "curated".