login
Search
"To quote you a number of years ago: 'Linux is evolution, not intelligent design'," noted Greg KH, quoting Linux creator Linus Torvalds. Linus expanded on the statement, "evolution often does odd (and 'suboptimal') things exactly because it does incremental changes that DO NOT BREAK at any point." He continued, "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." When alternative examples in evolution were pointed out, Linus suggested that the kernel was much simpler than a mammal and more similar to bacteria:
"In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA. So in an evolutionary sense, it's much closer to what the kernel should have (with occasional duplication of code and interfaces to allow new functionality, but rather aggressive pruning of the excess baggage). In other words, all of these choices are a matter of 'balance'. In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, 'just because' (or rather, because the cost of carrying it around is so small that nobody cares)."
From: Linus Torvalds <torvalds@...> Subject: Re: Announce: Linux-next (Or Andrew's dream :-)) Date: Feb 12, 3:55 pm 2008On Tue, 12 Feb 2008, Greg KH wrote:
>
> > That's the point.
>
> Not it isn't. To quote you a number of years ago:
> "Linux is evolution, not intelligent design"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.> Oh, it's been painful at times, but they are, overall, very rare.
No, overall, they have *not* been rare lately. We've had them all over.
And not just the one introduced by you.> If you look at the rate of change we are currently running at, it's
> amazing that we do not get _more_ of these kinds of problems.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.> > And simply avoiding cross-subsystem API changes unless there is a major
> > *MAJOR* reason for them is the obvious thing to do. Simply face the fact
> > that even in open source there are major reasons to stay with an old
> > interface even if it's not optimal.
>
> I strongly disagree here. We lived with that kset/ktype crap for years,
> and I finally broke down and cleaned it up, simplifying things, removing
> code, making the kernel smaller, leaner, and easier for others to change
> and use in the future. With your statement, such a change should have
> never taken place as it what we had at the time was "not optimal", but
> good enough to live with.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.> But they do happen about once or twice a kernel release, just by virtue
> of the way things need to happen.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
--
From: Roel Kluin <12o3l@...> Subject: Re: Announce: Linux-next (Or Andrew's dream :-)) Date: Feb 13, 1:12 pm 2008Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, Greg KH wrote:
>>> That's the point.
>> Not it isn't. To quote you a number of years ago:
>> "Linux is evolution, not intelligent design"
>
> 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.This is not entirely true if the pressure for changes are removed. For
instance in mammals the bones in the ear are what used to be gills in fish.
When fish became amphibians the gills weren't needed as much and evolution
took a side path.> 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).In nature there is a lot of duplication: several copies of genes can exist
and different copies may have a distinct evolution. There is also a lot of
'junk' DNA that doesn't code for anything (although it may have regulating
functions). In there some copies of genes may remain that are inactivated,
as well as parts of virusses, slowly obtaining random mutations because
there is no pressure on the evolution of them. Some may eventually become
active again and have different functions.The duplication also often ensures there is fallback when random mutations
are acquired and a protein is knocked out. Besides the two chromosomes
several proteins also can have overlapping functions. The result is more
like a balance.Evolution in nature and changes in code are different because in code junk
and bugs are constantly removed. In biology junk is allowed and may provide
a pool for future development. Linux development is intended and not
survival.
--
From: Linus Torvalds <torvalds@...> Subject: Re: Announce: Linux-next (Or Andrew's dream :-)) Date: Feb 13, 2:09 pm 2008On Wed, 13 Feb 2008, Roel Kluin wrote:
>
> In nature there is a lot of duplication: several copies of genes can exist
> and different copies may have a distinct evolution.This is true of very complex animals, but much less so when looking at
things like bacteria (and arguably, any current sw project is closer to
bacteria in complexity than anything mammalian).In bacteria (and viruses), duplication of DNA/RNA is a big cost of living
in general, and as a result there is *much* less junk DNA. So in an
evolutionary sense, it's much closer to what the kernel should have (with
occasional duplication of code and interfaces to allow new functionality,
but rather aggressive pruning of the excess baggage).In other words, all of these choices are a matter of "balance". In some
areas, excess code is not a sufficient downside, and we keep even broken
source code around with no actual function, "just because" (or rather,
because the cost of carrying it around is so small that nobody cares).That's true in the kernel as in biology: check out not just deprecated
code, but the drivers and other odds-and-ends that are explicitly marked
as non-coding DNA (we just happen to call them BROKEN in our Kconfig).Linus
--
From: Greg KH <greg@...> Subject: Re: Announce: Linux-next (Or Andrew's dream :-)) Date: Feb 12, 4:48 pm 2008On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 12 Feb 2008, Greg KH wrote:
> >
> > > That's the point.
> >
> > Not it isn't. To quote you a number of years ago:
> > "Linux is evolution, not intelligent design"
>
> 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.Hm, I think we are in violent agreement here :)
> 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, I might have mistyped previously, but I really do not believe in
this at all.> > > And simply avoiding cross-subsystem API changes unless there is a major
> > > *MAJOR* reason for them is the obvious thing to do. Simply face the fact
> > > that even in open source there are major reasons to stay with an old
> > > interface even if it's not optimal.
> >
> > I strongly disagree here. We lived with that kset/ktype crap for years,
> > and I finally broke down and cleaned it up, simplifying things, removing
> > code, making the kernel smaller, leaner, and easier for others to change
> > and use in the future. With your statement, such a change should have
> > never taken place as it what we had at the time was "not optimal", but
> > good enough to live with.
>
> 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.I agree with this. But I was reacting to your "there are major reasons
to stay with an old interface..." portion above, while I feel we should
always work to fixe those interfaces as best as possible.> > But they do happen about once or twice a kernel release, just by virtue
> > of the way things need to happen.
>
> 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.No, not at all.
I have tried, and successfully done this many times in the past. The
kobject change was one example: add a new function, migrate all users of
a direct pointer over to that function, after that work is all done and
in, change the structure and do the needed work afterward. All is
bisectable completly, with no big "flag day" needed.Same goes for a lot of USB changes. Hell, we've been slowly moving
toward changing the USB urb callback for _years_ yet, not quite getting
there, but the groundwork is done, making it much simpler and easy for
it to happen. Eventually things will flip over and the eventual patch
for all callback functions will be trivial and easily reviewed and
merged.In short, I agree that flag days are bad and should be avoided at all
costs, and that slow incremental, bisectable changes are how we evolve
properly. And that we need to always be able to do this kind of work,
and never be stuck with the "can't change an old, internal api" model.To bring it around to the original topic, -next should help us in
finding these issues out, exactly like -mm is.If we want to make a new rule of "only merging api or cross-subsystem
changes after everything else", that's wonderful with me, I have no
objection to it at all.thanks,
greg k-h
--
From: Theodore Tso <tytso@...> Subject: Re: Announce: Linux-next (Or Andrew's dream :-)) Date: Feb 12, 7:49 pm 2008On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote:
> > >
> > > Not it isn't. To quote you a number of years ago:
> > > "Linux is evolution, not intelligent design"I think this statement has been used unfortunately as a hard and fast
rule (which we all know how much Linus loves :-) to mean, in its most
extreme form, that we should *never* try to do some careful reflection
about careful API design, and that the extremes of "no interface
without an in-tree user" applies to (a) parameters in a function call
(heck, we can always sweep through all the in-tree users to add that
extra parameter later, and thats a *good* thing because it breaks
those evil out-of-tree drivers) and (b) to not even thinking if some
particular interface (that is not needed now but which reasonably will
be needed later) is even *possible* without doing a sweep of all of
the in-tree users of the interface.Related to this syndrome is the assumption that measuring the rate of
changes in lines of code changed per second implies that any
development process which causes the number of lines of code changed
second, including frequent sweeps through the tree changing all
interfaces, is a *good* thing.Yes, this is an extreme position, and I'm not accusing anyone of
holding the above in its entirety --- but I've seen aspects of all of
these from one developer or another.We come to it from the attacking another strawman, which assumes that
*all* interfaces which don't have an in-tree are evil, and that
keeping old __deprecated interfaces for a long time is an evil which
causes intolerable pain, and that it's never worthwhile to try to
anticipate future expandibility into an interface because you will
inevitably get it wrong.Clearly, we are right to mock Solaris for making claims that they will
never, ever, *ever* change an interface, not even one that goes back
sixteen years to Solaris 2.3. But it doesn't follow the opposite
point of view, that constant mutability of kernel interfaces to make
sure that things are always perfect and pure and clean is the right
one either.> > 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!Also, evolution also means that things like vestigal organs (like our
appendix) are tolerated. So are things like clearly very badly
designed things, like human backs. To the extent that we don't like
vestigal old __deprecated interfaces, and want things to be perfect,
we are actually straying into the realms where we want the sort of
things that you would get if you *did* have an intelligent designer
designing the human body from scratch.So the "Linux is evolution, not intelligent design" quote is
unfortunately getting used to imply that no amount of intelligent
foresight is worthwhile, and I think that's unfortunate. It implies
an extreme position which is not warranted.> > > But they do happen about once or twice a kernel release, just by virtue
> > > of the way things need to happen.
> >
> > 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.
>
> No, not at all.
>
> I have tried, and successfully done this many times in the past. The
> kobject change was one example: add a new function, migrate all users of
> a direct pointer over to that function, after that work is all done and
> in, change the structure and do the needed work afterward. All is
> bisectable completly, with no big "flag day" needed.Collectively, we need to try harder.
We can debate exactly where the right line is, in terms of whether
it's only "once or twice a kernel release", or "once or twice a year",
but clearly the current amount of interface changes and cross-tree
dependencies has been causing Andrew pain. And to me, that means we
need to turn the knob back a quarter turn towards tolerating
__deprecated old interfaces a little bit more, and trying to get
interfaces right just a little bit more and try building in just a
little bit more future expandability, and to try just *little* bit
harder to preserve a *little* bit more stable API.In other words, maybe we need to write a counterpoint to the
stable_api_nonsense.txt and call it unstable_api_nonsense.txt --- and
in it, we note that if we start burning out Andrew and he starts
getting really, REALLY grumpy --- and if especially we start making
Stephen (normally a very mild-mannered and not terribly excitable guy)
grumpy, that it's time that we try just a little bit harder to make
our API's a little bit more stable. Suckers^H^H^H^H^H^H^H^H, err.,
dedicated release managers like like Andrew and Stephen are very
precious resources and we shouldn't be burning them out by assuming
that "stable_api_nonsense.txt" is a license to constantly churn our
internal API's, to the point where they start complaining.- Ted
--
This whole discussion is
This whole discussion is pointless.
First, bacteria are never like multi-cellular organisms. So how can this be compared?
Second, bacteria like Escherichia coli have 4_639_221 nucleotides.
Humans have 3_253_037_807 nucleotides. That alone is a HUGE difference.
Third, evolution is multi-paradigm. Humans can think, humans can alter genomes, humans can do a lot of things, but a bacteria can not do much really. It can only produce more bacteria, and changes happen indirectly (on plasmids) much more often than on their genomes.
"In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA."
That is partially true - the more DNA, the higher the costs to replicate. However the reason for "junk" DNA is not about replication cost per se, it is about complexity. A bacteria has to do LESS than a mammal. Just think about it, the mammal has many different organs, the cells must inter-communicate much more than any bacterias that "live together".
"In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, 'just because' (or rather, because the cost of carrying it around is so small that nobody cares).""
The same is true for living things. The cost of carrying around "junk" is not that problematic. Just look at some plant genomes, they are HUGE.
I think the whole comparing of LIFE with computer science is futile. Does a computer need sunlight directly? Water? Does it need to produce new computers?
The whole kernel development is dictated by the developers. There is NO evolutionary pressure at all, the kernel folks dictate how it shall be developed.
It is fun to compare this to the "intelligent design" of the church, which claims that there is a god that did this all (ha ha hah) but it makes no sense to compare this with a model that the kernel folks put forward!
Analogy
I believe you missed out on the analogy portions of your English classes. You may want to read up on them if you plan to pass the ACT/SATs.
"The whole kernel
"The whole kernel development is dictated by the developers. There is NO evolutionary pressure at all, the kernel folks dictate how it shall be developed."
I would not be so sure about that, it's true that kernel devs are setting paths for the ways to go but to me the "evolutionary pressure" comes from the hardware vendors and the users, each one in it's own way.
it may seems pointless to discuss this matter as the kernel being a few millions bits is nowhere near DNA yet, although it raises interestings questions about the way things should/shall be done in the futur, evolution being billions years old, it had quite some time to make mistakes before us, i think this is where we can learn from it, of course not all of this complex process will be relevant to the kernel in particular. life goes in a try - test - select pattern, where now at a point where git allows to do that easily, maybe the time will come soon to turn the page to kernel 3.0, not in terms of included features, but in terms of possible futures.
btw, what about getting rid of the "old" and outdated kernel revision model and turn to a brand new "git tags to rule them all" ? :)
or just drop x.x.x.x
or just drop x.x.x.x fully?
and instead count releases from 1 (or maybe 0?) moving forward with each new release?
what would 2.6.24.2 be then?
Kernel developers do listen
agreed
Anyone that's spent any time on the kernel.org lists poking around and looking for patches, will see just exactly how wrong that statement ("The whole kernel development is dictated by the developers. There is NO evolutionary pressure at all, the kernel folks dictate how it shall be developed.") is.
While the overall design of the kernel is dictated by Linus and the rest of the inner sanctum, he's always attending working groups of people that want them to change their ways. Often they want a change that will severely impact the performance of the kernel, which he's tried already and found not to work.
In other cases, like virtualization, he's added things people want, despite not having any interest at all in the feature or understanding the useful purpose. This is the mark of someone who listens and cares about his user's needs.
He has to stand his ground in some cases. Sometimes it pisses people off but he owes it to the world to not take a step backwards for a small group of users who think they know what's best despite not having the engineering know how to understand why they are wrong and that feature sucks.
The kernel developers spend most of their time interacting with people to get information about hardware edge cases so they can fix them.
I've never seen a group of developers more devoted to their users' needs...
I strongly urge anyone that thinks they are in an unreachable ivory tower to go look at the kernel.org bugzilla.
If I had a (kernel or hardware) bug that wasn't fixed yet, I'd contribute to these reports, but they've already handled my issues by the time I find them.
-Viz
I feel all better now
I'm glad Linux devs see themselves as brute beasts competing Darwinially for food scraps, alpha status, and territory. That makes me feel so much better about their work than some uncivilized coding philosophy like intelligent design.
So ... are they saying there
So ... are they saying there is no intelligence applied to the design of the kernel, in fact no design at all, and it all happens by dumb luck ?
I think the devs need to start believing in themselves a bit more.
Let me know when the code starts writing itself.
I think you're taking it too far
The main point is that many, many ideas are tried, and some of them die off very quickly, and others show greater amounts of merit and cross-pollinate with other ideas that show merit. Sometimes ideas go away and come back in a slightly different form.
So, while the principle behind bacterial evolution is mutations introduced by corrupting RNA (either through transcription errors or through outside factors such as ionizing radiation), that doesn't mean Linux's evolution is similarly driven by random mutation. But, if you look at the whole mass of uncoordinated patches coming from all corners, it's clear that the process is not directed at all at the broadest levels, and still looks rather random. Survival of the fittest does seem to describe what happens with many of these ideas, and "fittest" may take awhile to sort out in some cases, whereas in others, non-viability is clear very quickly.
--
Program Intellivision and play Space Patrol!
I think it's a very weak
I think it's a very weak analogy.
> the process is not
> the process is not directed at all at the broadest levels
Thanks for the frank admission of guilt.
Too bad the fitness metric isn't "makes PC use easy."
If only evolution were at work. The true operational principle is not-invented-here, evolution's opposite. Everything starts from raw chemicals.
What is the latest thing? Udev. It is syntax-oriented programming. It has all the problems of half-baked language design with none of the ease of use. They couldn't have just "evolved" via XML, or bundled Prolog or Lisp or whatever, no.
To use it, you need to learn Yet Another Silly Linux Config Syntax (tm) and Yet Another Behavior Set (tm).
Now that I know all 150 strains of *nix bacteria and all their config formats, can we have some strains begin to eat others please? I'd really like to move up to mammals.
No one's making you use it
No one is making you use Linux.
If you want One Way To Do It, then perhaps you might be happier with something like a Mac? It's a free world after all.
--
Program Intellivision and play Space Patrol!
"makes PC use easy"
That is the linux *kernel* dev process, not the "make PC use easy" one. (Ubuntu and others are doing a great job in that area already).
Kernel Evolution
This looks like another proof that the kernel development model is broken. When it takes more full-time developers to maintain the kernel than what is needed to develop GNU + KDE + GNOME and all their dependencies - and these are the pieces of software that really matter to users - something must be really wrong somewhere.
Wrong viewpoint
Yes, something is wrong: the way you're looking at the problem set. Sure, the userspace is what matters to users, because the kernel should be completely invisible. It should Just Work. Now consider all the thousands of different bits of hardware you can add to your computer that needs to be supported, and the many different architectures Linux runs on, and the widely divergent workloads (from car computer to cell phone to DVR to laptop to workstation to LAMP server to huge clustered compute center) people use Linux for, etc.
The reality is that one reason the userspace developers (of whom I am definitely one!) are able to do so much with so few people is that the kernel folks work long, hard hours to HIDE all that diversity and complexity, and allow the userspace devs to concentrate on a single, simple interface or set of interfaces.
Appendix Vestigal Organs are a myth
LOL....The whole appendix as a vestigial organ thing has been debunked as a false theory. The tail bone too.
Erhm, no it hasn't.
Erhm, no it hasn't.
It's a container for intestines's bacteria
See below link.
http://www.msnbc.msn.com/id/21153898/
The function of the appendix seems related to the massive amount of bacteria populating the human digestive system, according to the study in the Journal of Theoretical Biology. There are more bacteria than human cells in the typical body. Most of it is good and helps digest food.
Analogy Police Alert
This is the Analogy Police! We have you surrounded! Step away from the keyboard!
Would anyone want to fly a
Would anyone want to fly a plane that was designed with no "design" in it, instead developed via introducing random changes into design and seeing "if it (somehow) works"? I don't think so. Looking at the resources being put into development of Linux (kernel) and the effect of them (many of the problems that were there few years ago are still there - that model doesn't work for operating systems either.
Maybe not completely random
...but certainly closer to the Linux way, IMHO.
A quote from their FAQ:
--
Program Intellivision and play Space Patrol!