Slashdot Mirror
Missing Kernel Patches
BlueEar writes: "There is an interesting, short story posted on the Gentoo Linux site. It talks about kernel patches created by Linux distributors that while publically available never get submitted. It even gives an example of one 'no brainer' patch that has been sitting over a year, without being incorporated into the 2.4.x distribution. The article ends with an appeal to Linux community to keep those patches flowing to Marcelo."
What most people don't realize that someone who puts together these releases like Linus or Marcelo is by no means omniscient. The kernel is a huge piece of work, and no one person can know what's happening in every corner of the thing. Most of Marcelo's time goes to merging patches, so he surely cannot go around the net looking for what ever fixes some distributor might have used or even checking out how come some fix that was circulating around before was never submitted to him.
What's nice is that nowadays there seem to be a couple of "patch harvesters" on the lkml who create their own releases (Alan Cox is now one of these people!) and persistently keep submitting forgotten patches.
Many of the distributor's fixes are ad hoc kludges that are designed to quickly making the thing *work*, ignoring elegance and maintainability... even when they do fix things, in the long run we don't want to take all of them into the kernel.
An example of why a particular patch might not be accepted, even though it seems like a "no-brainer", is because it would be for too specific a purpose. It might optimize the kernel for one particular application, at the expense of others. One of the best things about Linux is that it is general-purpose: suitable for everything from palmtops and embedded systems to servers and enterprise applications.
A patch to aggressively cache the disk in memory, for instance, might be good for servers but not for embedded systems. So, I could understand how a patch would be rejected in this case.
As an example, a company I once worked for made many minor changes to the Linux kernel. Since Linux is GPL, I made a webpage publishing these changes, and unlike the company, my webpage is still in existence!
Splash Open Source Page
These changes would be too narrow in focus to apply to the Linux kernel for everybody, so we never submitted them.
Dr. Demento On The 'Net!
I am wondering if the distributors themselves don't have too much interest in offering patches upstream, not only with the kernel. Commercial distros have a chance to become "pseudo-proprietary" this way.
I think this is a rather childish behavior and use Debian instead.
This sig is a true statement, but I cannot prove it.
Actually the pre-patched code seems to be reserving one LESS page than is actually needed, and forgetting to reserve the last page required.
Admittedly this can't be giving that bad an effect, as it would have been fixed in the main kernel but it looks like it could make the system go BOOM !
"Free software as in beer, copy protection as in racket" - Telsa Gwynne
The same thing sometimes happens to the BSDs, where a bug will be fixed (usually in Open) and nobody gets around to integrating the same fix into the others.
It seems to me that much of this could be automated... for each patch which gets added into the xBSD source tree, compare the contexts to the yBSD and zBSD source trees and alert a human if it looks like there's a match.
But for this to be effective, I think that patches would have to have labels attached, since it's really only bug fixes for which this is necessary.
Tarsnap: Online backups for the truly paranoid
... because once their patches are included they wouldn't have to maintain them themselves. So i don't see, how it could be a waste of time to send obvious patches in, or alert the kernel-maintainer of problems with recent patches that came up in their testing.
--
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
What good is a stable tree if all vendors have to apply 500 patches to it for it to be useful?
I would stay away from visual sourcesafe if your repositories grow beyond a normal size. We had database corruption at a former company once a week as some of our databases where getting huge.
We pushed and pushed for a change (2/3's of us wanted vanilla cvs over VS!) but management would never listen. And in fact we could not do any remote development with VS as it was not TCP aware... it only worked across MS networks (netbios). We later found another product that integrates TCP support into VS for you. But that added another point of failure for our remote developers (across the country). And those of us that preferred a unix workstation where SOL.
Basically we never used any features that make VS compelling over cvs. And its lack of support for anything but Netbios is unexcusable (especially for java developers who need that cross platform support). The parent poster has probably never used another version control system, and is just pushing MS products.
As a maintainer of a package which is distributed via many linux and *BSD distributions, I'd like to complain on the behalf of software authors everywhere. The linux distributions are nutoriously bad about applying patches to their rpms (say) but never submitting them back to the authors of the package themselves. The BSD distributions are just as bad. The infamous FreeBSD port tree also frequently houses patches that never make their way back to developers.
I'm not sure how this could ever be considered a good thing, as the project authors must spend time searching through distribution source releases looking for patches, which takes time. The distributions must continually apply their patch to a changing source tree (and I'm sure it'll eventually break and need reworking), so they loose time as well. This is one case where communication really could be a very positive thing.
sigh... It's about time I went to search for patches again...
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
It is extremely difficult to be proprietary when you are bound by the GPL. If your referring to Red Hat's using Rick's VM, there would be no stopping you from nabbing a
I also use Debian and must tell you that they make changes to the kernel. That is good, however. It just isn't practicle for a distro to try and update to the latest kernel. Plus if you like me, the first thing you do on any distro is nab a tarball from ftp.kernel.org.