Greg Kroah-Hartman has put the slides and a transcript to his keynote at OLS online. The title speaks volumes: "Myths, Lies, and Truths about the Linux kernel". He starts off: "I'm going to discuss the a number of different lies that people always say about the kernel and try to debunk them; go over a few truths that aren't commonly known, and discuss some myths that I hear repeated a lot."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-06-29
Your unrealistic approach to real software development is exactly the theoretical bullshit the Linux kernel developers know well to avoid. Do you develop software? If so, has your first attempt at designing any API/infrastructure/libraries ever been perfect?
There is what you read in textbooks, and then there's what actually works in the real world. Linux got its USB stack working first, they refined it with experience and now it's arguably the most efficient. To add insult to injury it has the largest support for USB drivers out of the box of the whole bunch, including Solaris. Now tell me how its unstable API is going to be its demise? What advantage does Solaris stable API gain it over Linux? Today, in practical terms absolutely nothing. Instead Solaris has to maintain legacy code and if at any point they spot design flaws in their APIs, they are stuck with it.
Providing stable APIs is not a holy grail. It doesn't automatically suggest better design, more drivers or even higher quality ones. It just gives developers blind faith and false sense of security.
Member since:2006-02-15
Your unrealistic approach to real software development is exactly the theoretical bullshit the Linux kernel developers know well to avoid.
And yet it worked well for the Unix community for nearly 30 years.
Do you develop software?
yes.
If so, has your first attempt at designing any API/infrastructure/libraries ever been perfect?
Yes. But that's not relevant. "stable" does not mean "perfect."
Providing stable APIs is not a holy grail.
That's correct. It's good engineering practice, though.
It doesn't automatically suggest better design, more drivers or even higher quality ones.
Starting from the assumption that you will not provide stable APIs, however, does automatically suggest poorer design and poorer quality implementations as the designer "evolves" the design through a random walk.
It just gives developers blind faith and false sense of security.
Nope.
Member since:
2005-07-06
Yet of all the OSes you mentioned with "stable" APIs, Linux, the OS without a "stable" API, still supports the most hardware and architectures out of the box compared to any OS known to man. All of a sudden, the stable_api_nonsense.txt begins to make sense.
Which is completely irrelevant to what I originally wrote; the original article which I replied to claimed that if they created a stable API it would then create a situation where innovation would be stifled in that they would be more concerned about API stability rather than correcting fundamental flaws in the implementation of the said API in question.
I'll use Solaris, for example, when USB was first implemented, it was implemented in a very adhoc fashion, basically, enough implemented to get basic mouse, keyboard and what-not functioning; but Sun clearly stated that a stable, long term USB DDK was in development; by the time Solaris 10 was released, it had a stable long term USB API which will allow any person to know that if they create a driver for Solaris 10's USB API, it'll work in 3 years time when, for example, Solaris 10.1/11 is release
The Linux issue, in respects to USB implementation could have been avoided had they instead decided to properly design it from day one rather than rushing out an implementation simply to get the 'look, we supported it first!" - better to support something properly the first time, than having to re-invent the wheel 2 more times because of a cock up in the original implementation.
When USB support was implemented; the first things should have been to consider future proofing it, to allow extensability at a later date if the USB standard is either enhanced or significantly changed to suite a new set of requirements. Yes, it would have taken possibly up to 6 months, but then atleast, when implemented, it would be in a position where it could remain stable for a few years rather than being in a constant state of flux.