On Tue, 12 Feb 2008, Greg KH wrote:Umm. Have you read a lot of books on evolution? It doesn't sound like you have. The fact is, evolution often does odd (and "suboptimal") things exactly because it does incremental changes that DO NOT BREAK at any point. The examples are legion. The mammalian eye has the retina "backwards", with the blind spot appearing because the fundmanetal infrastructure (the optical nerves) actually being in *front* of the light sensor and needing a hole in the retina to get the information (and blood flow) to go to the brain! In other words, exactly *because* evolution requires "bisectability" (any non-viable point in between is a dead end by definition) and does things incrementally, it doesn't do big flips. It fixes the problems on an incremental scale both when it comes to the details and when it comes to both "details" (actual protein-coding genes that code directly for some expression) and "infrastructure" (homeobox and non-coding genes). So quite frankly, you're the "intelligent designer" here. You're the one who seems to claim that we need those leaps of faith and wild jumps. No, overall, they have *not* been rare lately. We've had them all over. And not just the one introduced by you. I don't think that's a valid argument. Sure, we have lots of changes, but 99.9% of them have no cross-subsystem effect what-so-ever. You didn't listen at all. I said that the threshold should be high, not that it should be impossible. I also said that we should strive for making it unnecessary to have the painful total synchronization points. The fact is, we *have* been able to do things like this gradually and well, without introducing breakage. Take the VM changes, for example: those were pretty damn fundamental, where we've changed the calling convention totally for fault handling. But that thing was done without at any point really seriously breaking code. It involved adding the new interface, and letting the old one live in parallel. The last remnant of the old "nopage()" interface still exists, but I think right now it's only used by DRM. Did it require the drivers to be updated? Yes. But it did NOT require the total synchronization, because it still worked with the old interface. And I violently disagree. It should not be "once of twice a kernel release". It should be "once or twice a year" that you hit a flag-day issue. The rest of the time you should be able to do it without breakage. It's doable. You just HAVEN'T EVEN TRIED, and seem to be actively against even doing so. Linus --
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Christoph Lameter | [00/41] Large Blocksize Support V7 (adds memmap support) |
| Linus Torvalds | Linux 2.6.27-rc5 |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Nick Piggin | Re: Mainline kernel OLTP performance update |
