On Wed, Jan 23, 2008 at 10:10:14PM +0200, Alexey Eremenko wrote: > Think of a developer. An OSS GPL one :) > > It takes 100 hours to make a driver (LKM), plus 1 hour per month to > update it. But what happens, when he decided to move to another > project ? > > If there are users to his project, but no developers among them, they > are in trouble, because no-one will help them.
Ah, this is a simple one, turn the code over to the 300+ developers at linuxdriverproject.org, who are willing and able to clean up the driver, get it into the main Linux kernel tree, and maintain it over time. That is exactly why that project is there, and what it is currently doing already. So I don't really see the problem here :) > Now - the newbie user: > It is *really* daunting to update a kernel and find, that Nvidia > driver (and X.org) do not run on my desktop anymore. Then don't buy nvidia hardware. Again, simple answer :) Seriously, I really don't care about companies that violate the license of the Linux kernel, and I'm not going to do ANYTHING to help them out. Why would you expect me, or any other kernel developer to do otherwise? Do companies help other companies out that violate their licenses? No, they take legal action against them. > > How do you measure "too fast"? What rate of change would be acceptable > > for you? Can you quantify that based on the need for change in the > > market and environment that Linux is in? > > > > Do you even know what our rate of change is? I just ran the numbers > > last week, and they are much larger than has ever been reported in the > > past... > > > > Yes I know... ~2 million lines of code per month, or ~6m lines of code > per kernel release (3 months). Any rate is acceptable by me, and no > need to slow-down. Linux gains features very quickly now. > But I'm not speaking about that - but about changes that break things. > > Other OS kernels (Windows NT 5.x, Solaris UNIX) have also hi rate of > changes, yet they manage to stay more compatible. "compatible" with what? New hardware? No. New operating environments? No. Both of them are having major problems with these very things. And if you find problems that are regressions that break things, please let the kernel developers know, they are more than willing to fix them. > But generally, I can tell how it can happen: we need to look after > ourselves and see which kernel commit requires other LKM developers > most pain - i.e. most broken modules (both in-kernel LKMs and > third-party, out-of-tree), then revert those changes back. How can I, the person who makes the kernel change, see into the closed source modules of third-party developers, and see how it will affect them? How can I even know what kernel drivers that are open source out there floating around outside of the kernel tree do? The model doesn't work that way, sorry. If I change a kernel api, I go through the whole tree and fix up every usage of it to work properly. By doing that, the original developer doesn't have to worry about it at all, so in the end, they do even less work than any other operating system driver developer would (including the fact that Linux drivers are, on average, 30% smaller than other operating system drivers.) thanks, greg k-h -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
