Al Boldi wrote:
Nick Piggin wrote:
Al Boldi wrote:
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 ;)]
The fact that somebody may take advantage of a stable API should not lead us
to reject the idea per se.
Of course not, but the fact that they do nothing to help us means
that it doesn't carry a lot of weight (IMO, of course).
So: who's time well spent?
Anyone else is free to fork the kernel and develop their own
stable API for it.
That would be sad.
The objective of a stable API would be to aid the collective effort and not
to divide it.
As Arjan said, this is how kernel development works. I was using it
to highlight the fact that nobody has done so yet, which gives some
indication that it is not time well spent.
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?
If you are working alone a stable API would be overkill. But GNU/Linux is a
collective effort, where stability is paramount to aid scalability.
I hope the concepts here are clear.
No, they're not. I see no reason why your conjecture would be true and
you have failed to provide even any theories as to why it might be.
What's more, I'm not even clear what you mean by the scalability of a
development process. So, please elaborate -- this is not a rhetorical
question because I'm interested as to why you think this is the case, and
I have not had much experience with closed software development.
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?
The same goes for OpenSource in general, but GNU/OpenSource has a larger
community and therefore is in greater need of a stable API.
Yes, the same goes for OpenSource in general, fine. But what I'm asking
is: how is non-OpenSource different? What can we do better? How can we
learn from them?
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.
You got me here! It's really common sense as in:
stability breeds scalability, and instability breeds chaos.
But you might not be far wrong in saying that Linux has one of the most
chaotic and scalable development processes in the world.
We have unstable APIs, but IMO we have a great and stable software.
Arjan van de Ven wrote:
I think Linux proves you wrong (and a bit of a troll to be honest ;)
No troll! Just being IMHO. I hope that's OK?
That's fine, but Linux and the development process is a personal
achievement and creation of many here, so you have to try to be
respectful :)
Of course, if your aim is not to be scalable then please ignore this message
as it will not have any meaning.
I think most believe what I do: that our development model is scalable
(scalability seems to be the least of its worries), and that unstable
APIs are not a bad thing.
Everybody is also open to try to improve, however "stability breeds
scalability, and instability breeds chaos" is simply not "common sense",
so please explain and justify it before going further.
--
SUSE Labs, Novell Inc.
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]