War on Inconsistency II

In my former study of Gentoo Linux I encountered certain problems with GNU/Linux that are the more apparent as one strays from mainstream distributions, such as Ubuntu, Fedora/Red Hat and OpenSUSE/SUSE. Those problems do not exist in the BSD world, where the core operating system is an intrinsically functional platform for add-on applications. As laid out in the FreeBSD Handbook, it’s a chaos vs order issue. Chaos, unfortunately, gives rise to inconsistency. Dedoimedo has a great comparison of Ubuntu flavors illustrating that.

A typical user expects their operating system of choice to just work. Would that be the case for GNU/Linux, selecting a favorite distribution would rely primarily on visuals. While slightly undermining flexibility, it would mean every end-user would be allowed to enjoy the GNU/Linux ecosystem fully and not worry about driver issues, being vastly different on each distribution. One such quite ridiculous case was when the proprietary Broadcom driver failed to work on Debian, but worked perfectly fine on Ubuntu. Theoretically, the same driver. Practically, different everything else.

For now a lot of companies support only the top 3-5 GNU/Linux distributions. They cannot and will not extend that support to the whole GNU/Linux ecosystem, because they actually care that their products work well, even if only on a small number of most popular platforms. The issue could be partially addressed by releasing the source code of the product, so that patches and adjustments can be applied. Then, revenue may still be generated via technical support and various other forms of counseling. It is perfectly viable and companies do so. Another way would be to work on some level of consistency within the Linux kernel and the basic userland (compilers, command-line monitoring and diagnostic tools, partitioners, etc). Frankly, it’s quite ridiculous that the very base of the operating system (the kernel) can differ so much between distributions that troubleshooting driver issues is but a lesson in futility.

To be perfectly clear, no flexibility has to be sacrificed. It would be enough to agree on the basic modules, features and tools, still making the setup perfectly viable to build upon. In addition, nothing new needs to be created, because all of the components are already present. Not such a bad idea, right?

Advertisements

2 thoughts on “War on Inconsistency II

  1. > They cannot and will not extend that support to the whole GNU/Linux ecosystem, because they actually care that their products work well, even if only on a small number of most popular platforms.

    no. no, no, no. look at nvidia, perfect example. companies do the absolute minimum; always have– thats why theyre still doing it. note please, i dont expect them to support the top 50 distros or anything. but their “support” is abysmal, reality doesnt fit what youre saying about this point at all.

    i know that sometime the non-free driver “works better” than the non-free. thats not because of any real effort on the companies part; its because it contains extra snippets that link the driver to the features you need to get non-sucky performance (non-free drivers are still notoriously, hilariously low quality.)

    > The issue could be partially addressed by releasing the source code of the product, so that patches and adjustments can be applied. Then again, this kills the financial viability of the product as it can no longer be sold.

    this is not entirely true, but its getting there. the (arguable, possible) fact is that by releasing above-mentioned “extras” only found in the non-free drivers, they might tip their hand about the design of the hardware, and in that case they *might* have an issue. theyre playing it safe, fine, but not for the customers sake– at all.

    the reason non-free drivers “suck” while being higher-quality is that theyre carefully “reverse-engineered” (in the legal sense; there are tedious, legal ways to do it) that barely scratch the surface extended-features-wise.

    so you have carefully written drivers with fewer (performance) features, and absolute messes of crap that are tied to higher performance simply by being on the other side of the velvet rope. please do elaborate if i got anything wrong here; this has always been my understanding of the free vs. non-free drivers issue, philosophy aside (i have no desire to run non-free drivers, personally. but you notice i didnt really make it about that.)

    Like

    • I feel nVidia is a bit of a special case, because they do provide drivers for a lot of platforms, also including unusual ones, like OpenSolaris. More so, the driver support extends to very old hardware from the legacy 7000 series. All of those drivers are fully native. On the other hand, those drivers lack Linux-specific features (KMS among others), something nVidia is tentatively pursuing (there was a talk on that last year and an article on Phoronix: http://www.phoronix.com/scan.php?page=news_item&px=MTgxMDE).

      The radeon and intel drivers are collaboration products from their respective vendors. However, nouveau was reverse-engineered, hence it lacks the ‘extras’ you mentioned.

      I think the ‘how do we get money out of open-source’ argument I presented is probably moot, I agree. There are more valid and ‘free’ ways of generating revenue, such as providing technical support and counseling. Will include that :).

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s