- Related Stories
-
VMware-friendly change likely for Linux
April 13, 2006 -
Device support 'key' to desktop Linux
April 5, 2006 -
Novell hopes its next desktop will leapfrog Windows
March 9, 2006 -
Novell seeks to boost Linux graphics
February 6, 2006 -
Defender of the GPL
January 19, 2006 -
Linux gets Intel help with Centrino
March 10, 2004
(continued from previous page)
Red Hat shuns proprietary drivers for business reasons, said Chief Technology Officer Brian Stevens. "Why wouldn't you want the army of users to resolve it and make the driver a better driver? There are a lot of smart people who work on open source," Stevens said.
The company is urging graphics chipmakers to help open-source programmers by sharing hardware details, Stevens added. "We have made a direct request to them to open their specs fully. That's something they're not able to do at this time, but that request came from me," Stevens said.
On the flip side, Intel believes it can use open-source drivers to gain against Nvidia and ATI. The strategy parallels the chipmaker's earlier move with wireless networking support, and it has won an ally in Red Hat. "Their partnering with the open-source community is a pretty strong advantage," Stevens said.
Intel has new plans for its open-source graphics driver work, though Hohndel wouldn't reveal details. "Our (graphics) drivers are open source. We are bringing out some interesting new stuff. It's not released yet," he said.
Warning shot across the bow
Users got a taste of an open-source-only world last month from Red Hat. The company inadvertently suppressed the ability to use proprietary kernel modules when it shipped the new version 5 of its popular Fedora Core Linux. The unplanned experiment wasn't pretty for newbies.
"I do not believe the intention was to promote open-source modules and to attack proprietary modules," Larabel said. "One of the reasons I personally believe this is the fact that beginning Linux users who tried Fedora Core 5 would experience problems with loading mainly ATI or Nvidia modules and ultimately tarnish Fedora's reputation due to a troubling experience--or so I have gathered from the countless e-mails I received from those beginning users."
Red Hat unblocked proprietary modules in an update. However, other snags persist. Fedora and Novell's equivalent, OpenSuse, don't ship with the proprietary drivers, requiring users to jump through extra hoops to obtain and install them. On top of that, updating the kernel sometimes requires a corresponding video driver update.
One change that could ease driver difficulties is a stable interface to the Linux kernel. A stable interface provides a fixed and documented way for a driver to communicate with the kernel. Even if the kernel interior changed, the method of communication would remain the same, and drivers wouldn't have to change with kernel updates, for example.
"I understand the reasons why kernel developers try to steer clear of that," Fear said, giving as an example the wish to preserve maximum freedom to innovate. But a stable interface "would make our lives and the lives of the end users easier," he added.
With the existing fluid interface in Linux, programmers must provide drivers for numerous kernel variations, and old drivers--open or proprietary--stop working, said Miguel de Icaza, vice president of development at Novell. "Contrast this with Windows, where there is a stable interface for drivers in the kernel. A driver developed against NT 4 works on XP," he said.
ATI is willing to accommodate Linux's fluid style. "ATI accepts that as part of our day-to-day responsibilities in Linux," Tippett said.
Some worry that a stable interface could lead to more proprietary drivers. Arjan van de Ven, a former Red Hat kernel programmer who now works for Intel, described a speculative "Linux doomsday scenario in which Linux kernel developers accept binary modules and a stable interface. In his scenario, posted on the Linux kernel mailing list in December, hardware companies reverse current open-source support and ultimately leave users unable to respond to a serious security vulnerability.
Only some steps of the scenario are unlikely, van de Ven said. Despite this, he remains hopeful. "I believe that the advantages of freedom in the end are strong enough to overcome the counter forces," he said.
See more CNET content tagged:
graphics chip company, intellectual property, Linux, open source, ATI Technologies
If a user wants to avoid closed drivers or other closed software that is their choice. Who is FSF or Redhat to limit choice.
Odd that Microsoft has to my knowledge never suggested that users should be blocked or legally prevented from running open source on Windows, but the "Lets Be Free" guys are now about "My Way or No Way."
A few more legal threats like these and I can see vendors and key business suppliers of Linux drivers and tools wiping their hands of the whole thing.
This type of internal dogma an restriction is more harmful to Linux than and silly SCO lawsuit.
Open source users are afraid that once closed source drivers are allowed to exist than proprietary companies will take over the Linux market. Think about this... the first major video chip to make their drivers open source is going to get a whole lot of support from the community. More development is going to be done for their hardware, and more Linux users will buy their hardware. We don't need the FSF to hard ball open software for Linux. The incentive to open their software is already there.
History is ridden with examples of this:
* Microsoft - leveraged their virtual OS monopoly into an Office app monopoly, then into a browser monopoly.
* Electric Boat - in 1898 Isaac Rice used his virtual storage-battery monopoly to buy out several of his customers including John Philip Holland's submarine company.
* Standard Oil - leveraged a monopoly in the oil refining business into distribution and extraction.
History is ridden with examples of this:
* Microsoft - leveraged their virtual OS monopoly into an Office app monopoly, then into a browser monopoly.
* Electric Boat - in 1898 Isaac Rice used his virtual storage-battery monopoly to buy out several of his customers including John Philip Holland's submarine company.
* Standard Oil - leveraged a monopoly in the oil refining business into distribution and extraction.
Red Hat will not generally include closed source drivers with their products, because in doing so imposes restrictions on the distribution of their product. So, for those vendors that don't release specs for their hardware yet provide binary drivers, a user needs to download the driver from the vendor (or obtain it on a CD). This is the situation for Windows -- where every piece of hardware needs a separate driver, and only a small subset actually ship with the OS itself. However, for Linux, generally you have all the drivers to start with -- with the rare but notable few exceptions.
The advantage to open-source drivers is, of course, that the life-cycle of the driver is much longer -- support becomes effectively indefinite and matures (which is rare for commercial drivers, which typically fall out of active development and support faster). Further, open-source drivers are more rapidly updated, optmized, and ported.
Ostensibly, hardware vendors (even the majority today that develop their hardware and test it under Linux before writing Windows drivers) don't wish to release hardware programming specs so as to preserve "trade secrets" related to their hardware. That's the only excuse that makes any sense, and it's a poor one. It's hardly difficult for an experienced computer engineer to elucidate the hardware programming specs from a binary driver.
But businesses don't need fancy video cards and sound cards. Those types of hardware are mostly for home users. The leaders of the Linux development community are trying to adopt Linux in the home, but know that video, audio and optical media drivers are needed to help that adoption.
So nVidia and ATI are in a position where they have leverage to violate the GPL license. And they will continue to violate the license while they have leverage to do so.
They pay developers to code software, and can license it any way they please. Only a pure dogmatist would insist, having made a monetary investment, that they now must give it up for free.
The only thing I can see out of proprietory drivers is that the hardware manufacturer may have some ability to keep ahead of their competition be not giving away their work, as so much is processing control of the hardware is now done with control code. Letting the chip manufacturer sell their fancy new chip to many parties for them to fully develope it to various potentials. Admittedly, a sneaky competitor could still reverse engineer their drivers, BIOS, etc. Yet, without the code being fully deciphered that may be much harder to execute. Until better protection is functioning for the hardware developers, I suspect at least a well delayed release of the 'source' will likely persist. Yet after that concern is addressed, one would think that reliably getting the best possible interface with the rest of the system would be to best for both hardware seller and the end user.
Sincerely,
Gregory D. MELLOTT
I would have no problem with distro maintainers who want to make "only free software" a point of distinction, but it would be a problem if the kernel went that way. They shouldn't limit my ability to interact with other entities, whether I, as a user and owner, want to stay all open or mixed. I personally want the fastest box I can get, and the nvidia drivers help me get more out of my $150 card than the open source drivers. If the kernel wouldn't allow me to use the nvidia driver I wouldn't have the freedom to do what I wanted to with my box unless I got a different kernel, and in this case I think we're talking a *BSD kernel. As much as I would miss Slackware, I'd be a BSD user inside a week (though Slackware would probably be the last to force that on users).
Besides, the GNU guys are going to have the Hurd (herd?) kernel any day now, right? They can go that way with their kernel and let Linux go its own way.
Cheers,
joe f.
I think a stable kernel interface should be a high priority, so I can get drivers for Linux and know they will work, be they open-source or closed-source. I don't like having to recompile my drivers for each new kernel version. Sometimes the recompile fails, because of internal kernel changes.
If they wish, the kernel maintainers can add an optional restriction to block closed-source drivers, so those who prefer only open-source drivers can get their wish.
But I feel most people just want to use their systems to do what they want. So, by trying to force all Linux users to use only open-source drivers, the FSF is depriving users of their freedom NOT to use only open-source drivers.
It's like saying the freedom to practice religion means you MUST practice a religion. IMO, freedom to do something MUST entail the freedom NOT to do it---without choice, something is not freedom.
So, basically, I'd like to see users to have the option for closed-source or open-source drivers, and have the tools to enforce their wishes on THEIR system.
Not only that, but the Linux community is showing very little appreciation for the effort NVIDIA (in particular) has put forth in porting its excellent drivers to Linux.
If the FSF is truly taking this strident of an anti-proprietary software approach, I may have to reexamine my use of Linux. I also find the lack of stable kernel interfaces and the associated 'reasoning' very questionable from an engineering perspective.
If the open-source community wants linux to evolve into a true replacement for windows, they will have to allow businesses to be BUSINESSES.
Just because a driver ties to the kernel doesnt mean it should have to adhere to the GPL of the kernel. Since my mouse driver ties to the kernel... and it drives my mouse... does that mean that my mouse design has to be open and patent free also? What about the document I created with my open-source editor... do I have to provide that document to the open-source world since I created it with open-source software?
That might sound silly but it isnt any silly'er than saying the drivers have conform to the GPL because it ties to the kernel.
If FSF keeps on this path it may just kill Linux. No company is going to want to use a GPL or GPL v3 OS that requires every thing developed on it to be open to the public.
That's unfortunate, because Linux may regress to the sad driver situation pervasive in Windows, and that will do no good for anyone.
for open source 3D graphics development. We don't require that
our projects release source code, but we find that once the benefits
are well understood, that our customer quite often prefers the cost
savings of the open approach. Given a choice, and full
understanding of the tradeoffs, we consistently see development
okay'ed for open source release. We have found the graphics driver
development community to be very capable, and we're quite happy
to see our work released.
It would be really cool if the entire software industry, heck all businesses used open and freely available software, just wondering who they would hire to work these jobs since nobody could pay any bills?
need to grow my beard and ponytail and start wishing for this exciting make believe world!
If all software could be copied for free, at worst it would mean that the programmer would have to be paid for developing the software rather than royalty copies. Fancy that, people would only get paid for doing *real* work!
How insanely communistic must that vision be - NOT!
If you just want to be a consumer user go buy Windows or (god forbid) OS X. Why would you even care about Linux in the first place?
Despite what zealots may say or attempt to do, nothing prevents a kernel distribution from being made with the main goal of a fixed kernel API. This API would act as an abstraction layer between the official kernel API and a kernel API friendly to hardware manufacturers.
While the kernel developers would try to make the API even less concrete or make obvious attempts to thwart such a kernel distribution, it would be hard to prevent, since it would be easier for the hardware manufacturers to write for the fixed API and support the effort to counter the obfuscation of the original kernel.
The effort wasted by the original kernel developers and the desire to concentrate on performance and not politics, will eventually cause the original kernel developers to agree to a fixed API...
Just my 2 cents.
With an OS, it has always been about the drivers. OS2 Warp failed because the drivers were not there. Microsoft succeeded because they made it policy to make sure all the drivers were present for all hardware.
Look, the highway should be drivable without paying a toll, but I am willing to pay for the car. Get it? To all the Yugo drivers out there, well, granola and tofu are great sometimes and in Santa Cruz, you can walk the streets knowing with confidence, that it is a nucUlar free zone. Right.
2. You may not give someone else a ride.
3. You are not allowed to fix it.
4. You may not even be allowed to know what went wrong.
5. The car will be fixed on a schedule and at the discretion of the company.
6. The fix may be incorporated into the next model year of the car, which you will have to pay for.
7. Your car's computer has kept track of all the places you've driven, and a report will be generated and evaluated by the company at the time of service...
You get the idea. If this is what you choose so that you can have your "leather seats" more power to you I guess. A fool and his money are soon parted.
As for me, I'll be happy on my (free software) bicycle, which comes in many colors, with hundreds of accessories, is easy to fix, is faster than your car, and was given to me (and all my friends) for free.
OpenSuse. So what? How many of us have gotten Windows
installed without visiting half a dozen manufacturers sites to get
drivers? Not many, and even less of those ended up with a
stable system via windows install media + windows update
alone.
Proprietary drivers are a reality. An unfortunate one to a chunk
of the LK dev community, who wants to not have a stable kernel,
and no stable API/ABI for kernel modules.
interested in software development save for what
minimal portion they need to do to make their
hardware a compelling purchase.
Andrew Fear of Nvidia stated that: there's no
demand for open-source drivers, that drivers are
difficult to write, so it wouldn't help, and
that intellectual property (sic) is a secondary
concern.
He's wrong on all three. Nvidia and ATI are
quite consistently requested to open-source
their drivers OR release specs so that at least
people wouldn't have to reverse-engineer their
hardware. Drivers for these cards are also not
especially complex compared to drivers for other
hardware that's already been written
open-source, save for the fact that there's no
documentation about the hardware that could be
referred to which is a confounding problem. If
Nvidia could simply provide specs to open-source
developers and toss in their input to assure
they obtain the performance and feature levels
they want -- that would save them quite a bit of
money on software development, assure a timely
maturation of their products, prolonged support
life, and reach into new markets.
One has to assume, therefore, that the reason
that Nvidia and ATI don't provide information
about their products and don't open-source their
drivers is that they feel that doing so would
compromise and intellectual property (sic)
position that would exceed the goodwill and
development savings that they'd reap from going
open-source. ATI's probably more honest in
saying that they have contracts that prohibit
divulging certain third-party information --
whether that makes sense or not.
As a result ATI and Nvidia's products cost more
and they expend more effort working out issues
that may very well be more readily addressed by
another party.
I suspect that slowly, these two companies --
like other hardware vendors -- will adapt to the
demands of the modern IT landscape and
open-source development. The time will come when
without an open-source driver, they no longer
qualify for use in high-security applications.
No audit, no use.
Without the FSF's hardline stance about Free Software, the GNU/Linux operating system would not exist. You may want to read that last sentence again.
Stallman and company have never waivered in their belief that software should guarantee the users the freedom to use, copy, modify, and redistribute software. It is their "hardline" views that have kept the movement *moving*. Had they caved in at any point along the way (as many of the previous commentors have suggested they should) then the "Linux" operating system would have frightening similarities to Apple's OSX. Sure, there may be some free stuff in there, somewhere, but it's so intermingled with non-free, "secret" code, that the users are hogtied and beholden to a corporation for improvements, features, bug fixes, etc.
If you wish to be reliant on a company to feed you your software at their whim, and to be not entirely sure what your computer is doing behind the scenes, please feel free to use OSX or Windows. If YOU want to be in control of YOUR computer, then support Free Software.
My expectation is a very small percentage, so the whole access to the source code is of little use to them.
As a user of computers I believe the ideal of free software as in FSA definition is fantastic and I applaud their work and dedication. The only thing is that it only really works in an ideal world where commercial pressures do not exist. For some software this may be possible, as it is a soft product requiring no physical manufacturing process. Software can be coded and distributed without paying somebody.
For hardware this is a different situation. For any company to manufacturer a product they need to incur a real expense. This needs to be recouped in some way so they can do R&D and build the next version with improved performance.
On the specific topic of video driver. I remember the first nVidia Detonator drivers, which had quite poor performance. nVidia updated them and the performance was vastly increased, so for video cards the drivers make a huge difference to the performance and in some cases can be the difference between being the first or second in the speed race. For this reason I can understand why nVidia and ATI would keep their drivers closed source.
Now my personal perspective as a user is that as long as I have the right to use it I don?t care if the software is closed or open source. If a vendor will provide me with free (not FSA definition) drivers to improve my experience I?m going to take them and say thank you very much. In an ideal world FSA Free would be perfect, but until then or even without that being a realistic option I?ll take what?s on offer and enjoy it.
It's about as point-and-click as things get
these days. Really, that's not the problem so
much as the majority of people don't know what a
kernel is or why you'd want to 'compile' it.
As for video driver performance, closed/open
source doesn't matter. Presuming that both sets
of developers have documentation on the chipset,
both would be equally capable. Further, the OSS
developers would typically be more knowledgable
about writing video drivers in general, the
specific kernel, and the target feature sets.
nVidia's binary drivers, for example, lag behind
other vendors' open-source drivers in API,
feature, and kernel support. nVidia spends a lot
of money on drivers that they know are "behind
the curve" -- which is OK for them since they
make better hardware than much of their
competition, it just means that they aren't
everything they could be.
As a user, I'd certainly prefer the open-source
driver over the binary, but use the binary if
possible. I could be assured that the device
would work if I upgrade the OS, it would work if
I applied security patches, it would work if I
switched to a 64-bit platform, etc. With the
binary driver -- no such luck. And I can't use
all the features that the platform offers
either, because the vendor hasn't implemented
support for it or provided documentation that
would let someone else do it.
In the case of Nvidia, I've run into that issue.
I had to revert to using the lower-performance
reverse-engineered open-source driver, which was
slower but provided more features, while I
waited for Nvidia to support a newer kernel that
provided improved support for another piece of
hardware. The open-source driver worked, and it
was solid, but it's 3D performance was not
great. I eventually got the Nvidia driver, which
was higher performance, but less stable (and
lacked support for some X extensions -- which
was alright since I really didn't use them).
A business might get by with Windows 98- for all the power required of office software. It's only when you start to power Photoshop, 3D software, & games that you run into needing real power.
Having said that, it's a common thing to read threads that say, to the effect, "if I could play my games/run my graphic apps on Linux, I'd switch".
Linux needs to support driver useage- or it will soon be out of the picture.
typical Linux distribution ships with drivers
for about 5x as many devices as Windows does out
of the box -- that's not the issue.
Linux currently also supports binary-only
drivers, such as those from Nvidia and ATI.
The issue that this article is attempting to
address is whether or not doing so is a good
idea. Only a handful of hardware manufacturers
these days do not contribute open-source drivers
or don't provide hardware specs to allow others
to do so.
The open-source drivers themselves have several
advantages: they mature and evolve with the OS,
they are auditable, when necessary, and
accommodate new OS features when they appear.
They don't break with security patches, OS
upgrades, etc., and they are supported
indefinitely rather than the vendor's relatively
short product lifecycle. They are also much
cheaper for the vendor to maintain and typically
integrate better with the OS.
Binary-only drivers have some drawbacks: they
frequently lag behind supporting current
versions of the OS, they are not auditable and
can break following upgrades and updates to the
OS. They are comparatively expensive for a
vendor to maintain, and support is for a short
period of time. And, of course, technically they
are violating the kernel license by
appropriating portions of the kernel source code
for use in the driver itself.
The article is about that last point. The Linux
kernel maintainers have granted special license
to vendors to make binary-only drivers for Linux
despite it being against the general license.
It's the gentlemen's agreement that's an issue
here.
It's not a small issue either. ATI and Nvidia
both have drivers for Linux, for example. They
do break when apply patches to the OS, and they
are far less stable than their open-source
reverse-engineered-but-slow counterparts, and
they are lagging farther-and-farther behind the
rapid evolution of the rest of the Linux
graphical environment.
So, Linux developers are making exceptions to
the rules to allow vendors to work with Linux
while sharing nothing, but in doing so, the
quality, completeness, and stability of those
same drivers suffers -- an ultimately the user
does to. A catch-22. So how, and where, do you
draw the line?
If someone comes up with a near-equivalent 3D
card with full hardware documentation /
open-source support, Nvidia and ATI can kiss the
Linux / Kiosk / Telecom / UNIX scientific and
engineering markets good-bye.
- by 3rdalbum July 22, 2008 5:43 AM PDT
- It's interesting to read these comments from 2006 in the light of ATI's considerable opening-up. It's also funny to hear "They're going to stop allowing proprietary drivers, this is the end of Linux!" comments because of course we know now that this was never in danger of happening.
- Like this Reply to this comment
-
(38 Comments)Suggestions that "they should just let the drivers be in the kernel whether or not they are open-source" are ridiculous. You're effectively suggesting that the whole kernel project move to the BSD or MIT licenses - an actual physical impossibility. Saying that there should be a stable kernel interface is not a bad idea, but the lack of stable kernel interface currently doesn't deter anyone from building drivers as they simply make a small open-source wrapper library that links against the kernel headers each time.
Not having a stable kernel API is good in some ways not mentioned in the article, for instance you can choose not to install the kernel headers and make it more difficult for attackers to root your system.
Finally, AMD/ATI has shown that you can open up your specifications and get drivers written mostly by the community. I'm sure Nvidia are looking very seriously at opening up their drivers, because a lot of people are now eying off ATI cards. Why wouldn't you? 3D with an open-source driver! Having just downgraded to the nv 2D driver (which is open-source) and experienced fewer crashes and glitches, I'm really thinking that there's something to all this open graphics stuff.