What's easier for a clueless user, reading gui instructions and screenshots when your gui might look different (due to different configuration/theme, different screen res, different monitor layout, maybe even different language etc)... Having to go through each step individually in a laborious process...
Or
Cut and paste a bunch of commands from a website and check that the output matches what its supposed to.
Personally i much prefer being able to paste commands, i ABSOLUTELY DETEST the recent craze of having video based instructions, especially when you have to try and haphazardly skip through several minutes of waffle just to get to the bit where he tells you the pertinent information.
Most linux users with a pre built system (eg phones, tv sets etc) have no problems... Most linux users on desktop computers have to install their own system with no support from the hardware manufacturer, thats where problems come in... Preinstalled linux systems on fully supported hardware would be able to compete on a more level playing field with windows and macos.
As for CLI... If someone asks me for support, i will generally give them cli commands... Not because it's the only way to do things, but because in this case it's the best way... A command line is much easier to explain in a verbal or textual forum, explaining a gui is far more time consuming and really requires a visual communication method to do correctly.
If i read out a string of commands over the phone, someone can simply transcribe what i type and read back anything the computer responds with. Similarly with a text based online forum, they can paste my commands, and paste back any output.
Try explaining a gui over the phone, especially when the user has changed some of the defaults, you'll see what i mean.
Most windows boxes are installed by people who understand windows (ie the OEMs), with the full support of the hardware manufacturer(s)... Most linux installs are done by end users.
Give a user a random machine, a retail windows cd and a stable ubuntu cd and they're likely to have more problems with windows than linux. When you don't get an OEM install of windows there is all manner of futzing around to be done, trying to work out exactly what hardware you have based on the pci ids (since windows has no pci.ids database), trying to manually download the drivers from a website which offers thousands of different drivers, trying to install generic drivers only to find they don't work and you need the oem specific drivers (this is also where the codec problems occur with things like sound on linux, some manufacturer implements an intel hd audio compatible soundcard, but doesnt configure it in a standard way, so on windows you need the oem specific drivers and on linux the drivers are generally configurable enough to handle it but you need to fuck around with settings)..
Windows is absolutely not suitable as a system to be managed and run by average joe, sure you may be able to keep a preinstalled version limping along with limited knowledge but you will soon succumb to malware and become a ddos or spam drone, or break the system in some other way and then need someone else to fix it. Linux may not be suitable either, but it's at least not as bad. On the surface windows may look simple, but it is actually orders of magnitude more complicated than linux especially when something goes wrong.
Something like an ipad, a games console or some other appliance is actually far more suitable for average joe.
If you buy hardware which is preinstalled, you have every reasonable expectation that everything will work out of the box. The only problem is that such preinstalls are less widely available for linux at the moment.
1, there are no comments like you'd have in a text based config file, making manual editing more painful than it needs to be. 2, you need specialised tools to edit or view it, not just a standard text editor 3, backing up and revision control is much more difficult (i store my text based config files in git) 4, because its large binary files rather than individual text files, disk corruption is more damaging and harder to recover from
most of the cruft is not the registry itself at fault, rather applications which create the cruft and then don't uninstall cleanly, which is mainly because there is no proper package manager.
Gentoo stores its package database as a series of text files, so the risk of the whole database getting corrupted is much lower unless you have a total disk failure (and then the package database is the last of your concerns)... If one or two package entries get corrupted its no big deal to reinstall them.
That said, even with a binary package database i've not had problems like you describe for a long long time.
Disturbingly enough, my Amiga 3000 from 1990 is faster than any modern hardware for "booting the os"... And it doesn't have any remotely modern hardware anywhere near it.
"enterprise worthy" ? That's a bad thing... I have worked with a lot of software which is deemed "enterprise worthy" and it's generally slow, bloated, dated, unreliable, inflexible and requires all kinds of nasty kludges to get working and use... Generally "enterprise worthy" means "comes with an expensive support contract, so someone will show you the dodgy kludges necessary to get it limping along".
MS have always taken a soft stance on piracy for a very important reason...
So long as cracked windows is available for free, a lot of people will use that instead of free alternatives like linux... If you make windows impossible to pirate, then millions of people who can't or won't buy it will stick with the old version and eventually move to something else.
In many countries it is almost impossible to find someone who isn't running a pirated windows...
If a good proportion of those who pirate switched to linux, you would create a critical mass and you would remove the key selling point of windows. With a significant enough proportion of users using linux, third parties like hardware manufacturers would be unable to ignore it... You would rapidly get a situation where virtually everything supports both windows and linux. Once you level the playing field like this, then the primary factor will become cost.. With Linux able to do everything windows can, and with their friends running a mix of both, linux will become the primary choice because its cheaper (and those who want to pay for what they perceive to be a premium product are likely to turn to apple).
Windows just isn't a compelling product in its own right, the only thing keeping it alive is its ubiquity - the fact everyone else runs it, everything else runs on it, and its widely available.
HP have been screwing their customers for a while already... Killing PA-RISC and Alpha, forcing customers onto IA64 which now looks like it will die soon too... With each processor transition, customers at the very least have to recompile their code or run it under slow emulation...
Sun and IBM snapped up a lot of customers from HP over the IA64 transition, and i fully expect them to do the same when HP finally abandons IA64 and moves its customers onto something else.
Introducing a new, incompatible CPU was never going to work...
Too much code is only available in binary form, and so ran on ia64 very slowly under emulation. Vendors had no incentive to port their code because there were so few users, and users had no incentive to buy into the architecture because there was no software. Who wants to pay 5 times more for a cpu that when saddled with emulation is actually slower than the cheaper cpus?
The hardware was never cheap enough to attract hobbyist developers, so even open source code was often not well tested on them (nor are new risc cpus from other vendors, but old ones can be had cheaply). Had the hardware been cheap, it would have gained a lot more traction in the linux market at least.
A fight between huge players like Apple and Samsung serves to scare any new players from entering the market... These big companies know how to deal with other big companies, what they are most scared of is new, innovative and nimble upstarts.
For one thing many countries have at one point or another funded groups which were considered terrorists... Also the US developed nuclear weapons too, it's a double standard to punish iran for trying to do so. The US is also the only country to have actually USED nuclear weapons.
And these restrictions only hurt the less affluent/powerful civilians of such countries. The powerful in Iran will simply continue buying whatever technology they want either from the black market, or from countries that don't have any such restrictions.
Meanwhile they hurt legitimate businesses in countries which do enforce the restrictions, as they lose potential business to black market businesses and less restrictive countries.
On the contrary, one of the biggest problems people had with Vista was a lack of drivers, many drivers made for XP didn't work with it.
The in-kernel drivers on Linux tend to be far less hassle than binary drivers on any platform. Plus they provide all manner of other advantages, for example the vast majority of USB devices supported by x86 linux will also run on ARM, whereas Windows RT will require the hardware vendors to port their drivers, and many won't be willing to do so. Windows for Alpha, MIPS, IA64 and PPC suffered from a lack of drivers, as did the x64 version for quite some time (and still lacks support for older devices). Linux on all these architectures was able to use the vast majority of existing device drivers, many of which were never intended for use on anything other than x86 but still worked fine.
Driver ABIs have been deprecated many times, not just by Linux... There are all manner of people out there using proprietary hardware with ancient versions of Windows or DOS because the drivers don't work with anything newer.
The fact is that an ABI which seems suitable today, will become obsolete in the future.. It doesn't matter how much design work you do, sooner or later you will need to do something that requires a clean break. If you create an ABI and encourage binary drivers, then those drivers will become useless when the ABI inevitably requires updating. That's why binary drivers are discouraged, if we have source then we *can* update drivers to continue working.
MS also have serious security problems as a result of all the deprecated libraries they keep around...
Unstable drivers are also frequently blamed as the chief cause of windows instability, so MS earns a bad reputation and can't do anything about it because they don't have the source for all these drivers.
And the Linux userland does have a stable ABI and API. Binaries from the earliest versions of Linux (in a.out format no less) will still run on modern systems, although you do have to make sure you have the libraries they require (which many modern distros no longer bother distributing). The API goes back even further, software written for ancient unix systems can be compiled and run on Linux usually with no changes necessary.
What your advocating is that Linux users settle for the same level of hardware support present in proprietary systems... But the fact is, many people use Linux because it offers advantages over those proprietary systems, some of which you are advocating throwing away.
Linux drivers only die when there are no longer any users using them... The current Linux kernel has support for all manner of ancient hardware, and at least the hardware i've tried lately actually still works. For just one example, I booted a fairly recent 2.6.x Linux kernel on an Amiga just last week, and support for all of its hardware was still present and working.
If you do that, then it will be seen as "good enough" and noone will write drivers to take advantage of new kernels, all drivers will end up limping along.
Implementing a stable driver ABI impedes progress... Even MS have had to deprecate their old ABI several times, the most recent of which was vista.
As for writing drivers in a reasonable time frame there are several factors at work here... One is that a lot of code only needs to be written once, and then adapted or added to for new hardware, once you have a stable working driver for a previous generation card modifying it to support the latest hardware is considerably less work than a from scratch implementation. The other is that "outsiders" only get access to the hardware once it is released to the public, while internal developers have access to the hardware specs even before any actual hardware exists and can start developing the drivers alongside the hardware.
Ideally, driver development should be done in the open, ie its kicked off by internal employees of the hardware company and available in a working form when the hardware is, but then outside developers can contribute improvements, bugfixes and continued maintenance going forward... These improvements can then be built upon when making the next generation of hardware and so on.
And incidentally, the open AMD drivers are actually very good and improving all the time... They are far more stable than the closed counterparts, they work on hardware which is no longer supported by the closed drivers, they are faster and more reliable when it comes to 2d use, they provide a more seamless experience and allow you to update the rest of the system without risk of them breaking. The only area where they are currently lacking is 3d performance.. The 3d support is stable, but generally not as fast, so unless you have specific requirements where performance is king (eg gaming) the open drivers are a much better choice. If you have older hardware, chances are you not only don't care about gaming and 3d performance at all but also don't even have the choice of using the closed drivers.
It's not the hardware, i have several linux boxes which use the open radeon drivers including some where the hardware is not supported by the closed drivers anymore. The performance is variable, in some areas its faster than the closed drivers and in other areas slower.. Ofcourse this is a moot point on the older hardware where the closed drivers don't work at all. Stability on the other hand is far better with the open drivers, and any problems that occur i at least have a chance of trying to pinpoint and/or fix the problem.
So those are problems that have occurred because the hardware uses binary drivers...
The moral of this story is don't use hardware that requires closed source out of tree drivers.
And were you just installing security updates on ubuntu LTS, or were you actually going to different releases?
I have several ubuntu servers and many other non ubuntu linux boxes, which are regularly updated and never had a problem. I also intentionally avoid hardware which requires proprietary drivers for this reason (among others).
And this is not just a linux problem, i have seen windows boxes and even macs fail after updates because of badly written third party binary drivers. The only difference is that windows users just seem to accept problems, while linux users are vocal about how unacceptable such problems are and want to do something about them.
High end hardware is already a niche, for the vast majority of users the integrated Intel GPU is more than adequate, while also being far better supported. Intel chips are more than adequate for general desktop use, and even playing lighter weight or older games...
AMD are in a slightly different boat, since they are able to offer cheap integrated lowend CPU/GPU combinations to compete with Intel, nvidia aren't able to do this so the only market they can go after is the high end. And when it comes to GPUs, high end basically means hardcore gamers and those using GPUs for processing, with Linux taking a significant share of the latter.
Compare that to all the data needed for Intel's CPU... All the information needed to write programs to run on Intel CPUs is out there, and yet other processor manufacturers are still behind. Intel may produce lowend GPUs, but their CPUs are more than competitive on the high end.
Competitors can employ people to reverse engineer if they really want to copy... While keeping the specs closed might make copying slightly more difficult, it also makes it harder to prove.
You could say that linux is significantly invested in x86 too, and yet it also has support for mips, arm, etc... If the driver is even remotely well written, then it should require absolutely minimal effort to support other architectures. There are plenty of drivers for pci and usb devices in the linux kernel that work on other architectures pretty much by accident, try building a sparc or alpha linux box and throwing some random pci cards in. And let's not forget that until a few years ago, there were nvidia drivers for macos on powerpc.
Depends how the code is written... There shouldn't be a lot of architecture specific code in there. To put it another way, i have used linux on various architectures, often using combinations of pci cards that i doubt anyone ever expected to be used together... I used to use sun ethernet cards in my alphastation for instance. I also used an (older, pci based) radeon card in that alphastation. Similarly, i have used some old pci nics on a modern amd64 box, microsoft has 32bit drivers for these but didn't bother to compile 64bit versions so i doubt there are many people trying to use a similar setup to me.
They don't need opengl code to release hardware documentation... Given appropriate documentation, people could implement a clean room version of opengl and replace the bits that can't be released. There are already several open source implementations of opengl which could be adapted.
Slashdot Mirror
Have you looked into WHY?
What's easier for a clueless user, reading gui instructions and screenshots when your gui might look different (due to different configuration/theme, different screen res, different monitor layout, maybe even different language etc)... Having to go through each step individually in a laborious process...
Or
Cut and paste a bunch of commands from a website and check that the output matches what its supposed to.
Personally i much prefer being able to paste commands, i ABSOLUTELY DETEST the recent craze of having video based instructions, especially when you have to try and haphazardly skip through several minutes of waffle just to get to the bit where he tells you the pertinent information.
Most linux users with a pre built system (eg phones, tv sets etc) have no problems...
Most linux users on desktop computers have to install their own system with no support from the hardware manufacturer, thats where problems come in... Preinstalled linux systems on fully supported hardware would be able to compete on a more level playing field with windows and macos.
As for CLI... If someone asks me for support, i will generally give them cli commands...
Not because it's the only way to do things, but because in this case it's the best way... A command line is much easier to explain in a verbal or textual forum, explaining a gui is far more time consuming and really requires a visual communication method to do correctly.
If i read out a string of commands over the phone, someone can simply transcribe what i type and read back anything the computer responds with.
Similarly with a text based online forum, they can paste my commands, and paste back any output.
Try explaining a gui over the phone, especially when the user has changed some of the defaults, you'll see what i mean.
wget "http://www.google.com/search?q=site%3Aslashdot.org+dumbass"
The most important difference is that:
Most windows boxes are installed by people who understand windows (ie the OEMs), with the full support of the hardware manufacturer(s)...
Most linux installs are done by end users.
Give a user a random machine, a retail windows cd and a stable ubuntu cd and they're likely to have more problems with windows than linux.
When you don't get an OEM install of windows there is all manner of futzing around to be done, trying to work out exactly what hardware you have based on the pci ids (since windows has no pci.ids database), trying to manually download the drivers from a website which offers thousands of different drivers, trying to install generic drivers only to find they don't work and you need the oem specific drivers (this is also where the codec problems occur with things like sound on linux, some manufacturer implements an intel hd audio compatible soundcard, but doesnt configure it in a standard way, so on windows you need the oem specific drivers and on linux the drivers are generally configurable enough to handle it but you need to fuck around with settings)..
Windows is absolutely not suitable as a system to be managed and run by average joe, sure you may be able to keep a preinstalled version limping along with limited knowledge but you will soon succumb to malware and become a ddos or spam drone, or break the system in some other way and then need someone else to fix it. Linux may not be suitable either, but it's at least not as bad. On the surface windows may look simple, but it is actually orders of magnitude more complicated than linux especially when something goes wrong.
Something like an ipad, a games console or some other appliance is actually far more suitable for average joe.
If you buy hardware which is preinstalled, you have every reasonable expectation that everything will work out of the box. The only problem is that such preinstalls are less widely available for linux at the moment.
It's not just cruft, its:
1, there are no comments like you'd have in a text based config file, making manual editing more painful than it needs to be.
2, you need specialised tools to edit or view it, not just a standard text editor
3, backing up and revision control is much more difficult (i store my text based config files in git)
4, because its large binary files rather than individual text files, disk corruption is more damaging and harder to recover from
most of the cruft is not the registry itself at fault, rather applications which create the cruft and then don't uninstall cleanly, which is mainly because there is no proper package manager.
Gentoo stores its package database as a series of text files, so the risk of the whole database getting corrupted is much lower unless you have a total disk failure (and then the package database is the last of your concerns)... If one or two package entries get corrupted its no big deal to reinstall them.
That said, even with a binary package database i've not had problems like you describe for a long long time.
The gov interferes in markets all the time, copyrights and patents for instance are government interference in the market.
Without rules imposed by government, corporations would become extremely ruthless and would be abusing even more than they are now...
The robust and established ecosystem of x86 applications provides the best customer experience at this time and in the immediate future
Yes, there's no windows apps for arm, and noone will ever write any if there's no hardware or users.
It has a Commodore A2065 10mb ethernet card, which is still compatible with today's ethernet networks.
Disturbingly enough, my Amiga 3000 from 1990 is faster than any modern hardware for "booting the os"... And it doesn't have any remotely modern hardware anywhere near it.
"enterprise worthy" ?
That's a bad thing... I have worked with a lot of software which is deemed "enterprise worthy" and it's generally slow, bloated, dated, unreliable, inflexible and requires all kinds of nasty kludges to get working and use...
Generally "enterprise worthy" means "comes with an expensive support contract, so someone will show you the dodgy kludges necessary to get it limping along".
MS have always taken a soft stance on piracy for a very important reason...
So long as cracked windows is available for free, a lot of people will use that instead of free alternatives like linux... If you make windows impossible to pirate, then millions of people who can't or won't buy it will stick with the old version and eventually move to something else.
In many countries it is almost impossible to find someone who isn't running a pirated windows...
If a good proportion of those who pirate switched to linux, you would create a critical mass and you would remove the key selling point of windows. With a significant enough proportion of users using linux, third parties like hardware manufacturers would be unable to ignore it... You would rapidly get a situation where virtually everything supports both windows and linux.
Once you level the playing field like this, then the primary factor will become cost.. With Linux able to do everything windows can, and with their friends running a mix of both, linux will become the primary choice because its cheaper (and those who want to pay for what they perceive to be a premium product are likely to turn to apple).
Windows just isn't a compelling product in its own right, the only thing keeping it alive is its ubiquity - the fact everyone else runs it, everything else runs on it, and its widely available.
HP have been screwing their customers for a while already...
Killing PA-RISC and Alpha, forcing customers onto IA64 which now looks like it will die soon too...
With each processor transition, customers at the very least have to recompile their code or run it under slow emulation...
Sun and IBM snapped up a lot of customers from HP over the IA64 transition, and i fully expect them to do the same when HP finally abandons IA64 and moves its customers onto something else.
Introducing a new, incompatible CPU was never going to work...
Too much code is only available in binary form, and so ran on ia64 very slowly under emulation. Vendors had no incentive to port their code because there were so few users, and users had no incentive to buy into the architecture because there was no software. Who wants to pay 5 times more for a cpu that when saddled with emulation is actually slower than the cheaper cpus?
The hardware was never cheap enough to attract hobbyist developers, so even open source code was often not well tested on them (nor are new risc cpus from other vendors, but old ones can be had cheaply). Had the hardware been cheap, it would have gained a lot more traction in the linux market at least.
A fight between huge players like Apple and Samsung serves to scare any new players from entering the market... These big companies know how to deal with other big companies, what they are most scared of is new, innovative and nimble upstarts.
Such restrictions are utterly stupid...
For one thing many countries have at one point or another funded groups which were considered terrorists...
Also the US developed nuclear weapons too, it's a double standard to punish iran for trying to do so. The US is also the only country to have actually USED nuclear weapons.
And these restrictions only hurt the less affluent/powerful civilians of such countries. The powerful in Iran will simply continue buying whatever technology they want either from the black market, or from countries that don't have any such restrictions.
Meanwhile they hurt legitimate businesses in countries which do enforce the restrictions, as they lose potential business to black market businesses and less restrictive countries.
On the contrary, one of the biggest problems people had with Vista was a lack of drivers, many drivers made for XP didn't work with it.
The in-kernel drivers on Linux tend to be far less hassle than binary drivers on any platform. Plus they provide all manner of other advantages, for example the vast majority of USB devices supported by x86 linux will also run on ARM, whereas Windows RT will require the hardware vendors to port their drivers, and many won't be willing to do so.
Windows for Alpha, MIPS, IA64 and PPC suffered from a lack of drivers, as did the x64 version for quite some time (and still lacks support for older devices). Linux on all these architectures was able to use the vast majority of existing device drivers, many of which were never intended for use on anything other than x86 but still worked fine.
Driver ABIs have been deprecated many times, not just by Linux... There are all manner of people out there using proprietary hardware with ancient versions of Windows or DOS because the drivers don't work with anything newer.
The fact is that an ABI which seems suitable today, will become obsolete in the future.. It doesn't matter how much design work you do, sooner or later you will need to do something that requires a clean break. If you create an ABI and encourage binary drivers, then those drivers will become useless when the ABI inevitably requires updating. That's why binary drivers are discouraged, if we have source then we *can* update drivers to continue working.
MS also have serious security problems as a result of all the deprecated libraries they keep around...
Unstable drivers are also frequently blamed as the chief cause of windows instability, so MS earns a bad reputation and can't do anything about it because they don't have the source for all these drivers.
And the Linux userland does have a stable ABI and API. Binaries from the earliest versions of Linux (in a.out format no less) will still run on modern systems, although you do have to make sure you have the libraries they require (which many modern distros no longer bother distributing). The API goes back even further, software written for ancient unix systems can be compiled and run on Linux usually with no changes necessary.
What your advocating is that Linux users settle for the same level of hardware support present in proprietary systems... But the fact is, many people use Linux because it offers advantages over those proprietary systems, some of which you are advocating throwing away.
Linux drivers only die when there are no longer any users using them... The current Linux kernel has support for all manner of ancient hardware, and at least the hardware i've tried lately actually still works. For just one example, I booted a fairly recent 2.6.x Linux kernel on an Amiga just last week, and support for all of its hardware was still present and working.
If you do that, then it will be seen as "good enough" and noone will write drivers to take advantage of new kernels, all drivers will end up limping along.
Implementing a stable driver ABI impedes progress... Even MS have had to deprecate their old ABI several times, the most recent of which was vista.
As for writing drivers in a reasonable time frame there are several factors at work here...
One is that a lot of code only needs to be written once, and then adapted or added to for new hardware, once you have a stable working driver for a previous generation card modifying it to support the latest hardware is considerably less work than a from scratch implementation.
The other is that "outsiders" only get access to the hardware once it is released to the public, while internal developers have access to the hardware specs even before any actual hardware exists and can start developing the drivers alongside the hardware.
Ideally, driver development should be done in the open, ie its kicked off by internal employees of the hardware company and available in a working form when the hardware is, but then outside developers can contribute improvements, bugfixes and continued maintenance going forward... These improvements can then be built upon when making the next generation of hardware and so on.
And incidentally, the open AMD drivers are actually very good and improving all the time... They are far more stable than the closed counterparts, they work on hardware which is no longer supported by the closed drivers, they are faster and more reliable when it comes to 2d use, they provide a more seamless experience and allow you to update the rest of the system without risk of them breaking.
The only area where they are currently lacking is 3d performance.. The 3d support is stable, but generally not as fast, so unless you have specific requirements where performance is king (eg gaming) the open drivers are a much better choice. If you have older hardware, chances are you not only don't care about gaming and 3d performance at all but also don't even have the choice of using the closed drivers.
It's not the hardware, i have several linux boxes which use the open radeon drivers including some where the hardware is not supported by the closed drivers anymore. The performance is variable, in some areas its faster than the closed drivers and in other areas slower.. Ofcourse this is a moot point on the older hardware where the closed drivers don't work at all. Stability on the other hand is far better with the open drivers, and any problems that occur i at least have a chance of trying to pinpoint and/or fix the problem.
So those are problems that have occurred because the hardware uses binary drivers...
The moral of this story is don't use hardware that requires closed source out of tree drivers.
And were you just installing security updates on ubuntu LTS, or were you actually going to different releases?
I have several ubuntu servers and many other non ubuntu linux boxes, which are regularly updated and never had a problem. I also intentionally avoid hardware which requires proprietary drivers for this reason (among others).
And this is not just a linux problem, i have seen windows boxes and even macs fail after updates because of badly written third party binary drivers. The only difference is that windows users just seem to accept problems, while linux users are vocal about how unacceptable such problems are and want to do something about them.
High end hardware is already a niche, for the vast majority of users the integrated Intel GPU is more than adequate, while also being far better supported. Intel chips are more than adequate for general desktop use, and even playing lighter weight or older games...
AMD are in a slightly different boat, since they are able to offer cheap integrated lowend CPU/GPU combinations to compete with Intel, nvidia aren't able to do this so the only market they can go after is the high end.
And when it comes to GPUs, high end basically means hardcore gamers and those using GPUs for processing, with Linux taking a significant share of the latter.
Compare that to all the data needed for Intel's CPU...
All the information needed to write programs to run on Intel CPUs is out there, and yet other processor manufacturers are still behind. Intel may produce lowend GPUs, but their CPUs are more than competitive on the high end.
Competitors can employ people to reverse engineer if they really want to copy... While keeping the specs closed might make copying slightly more difficult, it also makes it harder to prove.
You could say that linux is significantly invested in x86 too, and yet it also has support for mips, arm, etc...
If the driver is even remotely well written, then it should require absolutely minimal effort to support other architectures. There are plenty of drivers for pci and usb devices in the linux kernel that work on other architectures pretty much by accident, try building a sparc or alpha linux box and throwing some random pci cards in.
And let's not forget that until a few years ago, there were nvidia drivers for macos on powerpc.
Depends how the code is written... There shouldn't be a lot of architecture specific code in there.
To put it another way, i have used linux on various architectures, often using combinations of pci cards that i doubt anyone ever expected to be used together... I used to use sun ethernet cards in my alphastation for instance. I also used an (older, pci based) radeon card in that alphastation.
Similarly, i have used some old pci nics on a modern amd64 box, microsoft has 32bit drivers for these but didn't bother to compile 64bit versions so i doubt there are many people trying to use a similar setup to me.
They don't need opengl code to release hardware documentation... Given appropriate documentation, people could implement a clean room version of opengl and replace the bits that can't be released. There are already several open source implementations of opengl which could be adapted.