Re: Linux in a binary world... a doomsday scenario

[Nick Piggin <nickpiggin@yahoo.com.au>]

Al Boldi wrote:
> Arjan van de Ven wrote:
>
> > a stable api/abi for the linux kernel would take at least 2 years to
> > develop. The current API is not designed for stable-ness, a stable API
> > needs stricter separation between the layers and more opaque pointers
> > etc etc.
>
>
> True.  But it would be time well spent.

Who's time would be well spent?

Not mine because I don't want a stable API. Not mine because I
don't use binary drivers and I don't care to encourage them.
[that is, unless you manage to convince me below ;)]

Anyone else is free to fork the kernel and develop their own
stable API for it. I don't think I would go so far as to call
that time well spent, however.

> > There is a price you pay for having such a rigid scheme (it arguably has
> > advantages too, those are mostly relevant in a closed source system tho)
> > is that it's a lot harder to implement improvements.
>
>
> This is a common misconception.  What is true is that a closed system is 
> forced to implement a stable api by nature.  In an OpenSource system you can 
> just hack around, which may seem to speed your development cycle when in 
> fact it inhibits it.

How? I'm quite willing to listen, but throwing around words like 'guided
development' and 'scalability' doesn't do anything. How does the lack of a
stable API inhibit my kernel development work, exactly?

> > Linux isn't so much designed as evolved, and in evolution, new dominant
> > things emerge regularly. A stable API would prevent those from even coming
> > into existing, let alone become dominant and implemented.
>
>
> GNU/OpenSource is unguided by nature.

I've got a fairly good idea of what work I'm doing, and what I'm planning
to do, long term goals, projects, etc. What would be the key differences
with "non-GNU/OpenSource" development that would make you say they are not
unguided by nature?

>  A stable API contributes to a guided 
> development that is scalable.  Scalability is what leads you to new heights, 
> or else could you imagine how ugly it would be to send this message using 
> asm?

Let's not bother with bad analogies and stick to facts. Do you know how
many people work on the Linux kernel? And how rapidly the source tree
changes? Estimates of how many bugs we have? Comparitive numbers from
projects with stable APIs? That would be very interesting.

Thanks,
Nick

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/