Re: What makes a production kernel?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Farris wrote:


In my opinion, just because the driver is closed source does not mean
there can be no improvement in how nVIDIA and linux developers work
together... and there should be improvement (in both directions).
Nevertheless, cutting edge changes cannot be made without breaking the
old, unchanged drivers -- the changes will not be made pro-actively by
the vendors because making those changes costs them money. They play
catchup, and probably always will (at least until their support of Linux
becomes a legitimate economic expense in comparison to support of the
competing OS).




This is the most solid point to come out of this discussion. I understand that NVIDIA can't patch their drivers for a kernel that isn't being used. I don't know whether its practical, but a better solution would be to let NVIDIA know that their drivers will not work on the kernels of the future, but stick to the working kernels in the mean time. To alienate the huge percentage of the PC market who have NVIDIA hardware for six months for kernel options that may not make a noticable performance difference doesn't seem like a popular way to go. I haven't compiled my own kernel in a while, but isn't the problem not the kernel itself, but the options and extra patches that are applied?

It is interesting to consider the same situation with the release of
Windows XP... where the nVIDIA driver base for Windows 2000 was
extremely unstable for use in XP for several months after the public
release. Did Microsoft not release XP, nope.
(there was probably more unilateral cooperation in that situation)


There are a few differences between that situation and this one, though. First, the 2000 drivers worked decently well, could accelerate video, but might crash on some complex game. The nvidia X driver hardlocks on the newer Red Hat kernels, and the nv driver isn't fast enough to play video without skipping. And you're extremely correct in the unilateral cooperation. NVIDIA doesn't care too much about Fedora and doesn't need to. Linux does not have the leverage to say, "We're doing this our way, now fix your stuff". The only way Linux could gain that leverage would be to gain popular support by working with the systems the populous have.

I know that there are some people who live in a 1960's UNIXy cave and say that things were better when everything was command line. But a large part of the population wants a fancy colorful system that works automatically and plays their video and games. Linux in general has made phenominal progress toward that goal in the last 5 years without losing sight of their hardcore UNIX base. But its always seemed like all the other distros have been leading the way. I know Red Hat is now focusing on their RHEL base, so they're allowed to care a little less about popularizing Linux for the home crowd, but otherwise what's the point of Fedora?

Lastly, this isn't just a NVIDIA problem. I brought this up because neither of my graphics cards work. People have been talking about random deadlocks and other strange behavior. I don't know whether the savage driver is strictly the problem, or something else. If this problem isn't well understood by now, I will try to research where the problem is with my own 2.6.5 kernels. But the actual reason I asked this was not to incite a pro NVIDIA vs. anti NVIDIA war, but to understand where the kernel is going. It seems like as FC2 comes closer, the other software freezes and becomes more stable, but the kernels keep going and become increasingly unstable and incompatible. That's why I wanted to know if FC2 would release with a stable 2.6.3 with a choice to upgrade to some super modified 2.6.5, or whether 2.6.5 was the only way to go.

-Eric Hattemer



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux