Linux Kernel Source

[Billy Bong]

Hi guys!

I recently downloaded the Linux Kernel source code, in the hopes of
learning a thing or two about how the "pros" do it in C.

Much to my chagrin, I inevitably came across comments that included the
words "kludge" and "FIXME" in the Linux Kernel source code.

Because I'm a curious kind of creature, I decided to search the entire
Linux Kernel source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 154 occurrences
FIXME: 3120 occurrences

These results seem rather striking to me. After all, the Linux Kernel
source is "open source", and, frankly, I expected to find 0 occurrences
of both these search strings, given that we should have multitudes of
programmers working on this source and fixing the bugs in what I pretty
much expect should be real-time.

Because I'm a curious kind of creature, I decided to search the entire
Microsoft MFC source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 0 occurrence(s)
FIXME: 0 occurrence(s)

At this point, I'm feeling pretty damned hoodwinked. That desktop graphic
of the penguin sucking on a cardboard drink container with the Windows XP
logo and the words "We suck more!" on it look really appealing, but what
is really behind all that--just a dog-and-pony show?

My C question is the following:

Is it good practice to comment our code with words like "kludge" and
"FIXME"?

If so, what does that say about our requirements in specific, and our
development process in general?

And if so, shouldn't we expect nothing less than undefined behavior?

And if not, what does that say about the Linux Kernel source code?

I notice that many of the Linux Kernel source code files list Linus
Torvalds as an author. I wonder if he is aware of this apparent disarray
of the current Linux Kernel source code? If someone has his phone number,
perhaps they might try calling him to inform him of the current situation
as described above to see what he thinks, and report back here with a
transcript of the conversation.

For those of you who think I'm a pro-Microsoft dude and a Linux basher,
think again. I'm posting this from Linux. I just don't have the same
confidence in this Linux OS that I had when I installed it--based on the
evidence I presented, of course.

 

[Friedrich Dominicus]

Much to my chagrin, I inevitably came across comments that included the
words "kludge" and "FIXME" in the Linux Kernel source code.

Because I'm a curious kind of creature, I decided to search the entire
Linux Kernel source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 154 occurrences
FIXME: 3120 occurrences

These results seem rather striking to me. After all, the Linux Kernel
source is "open source", and, frankly, I expected to find 0 occurrences
of both these search strings, given that we should have multitudes of
programmers working on this source and fixing the bugs in what I pretty
much expect should be real-time.

Well I do bet that MS has more programmers working on their OSes then
Linux. And the code above just implies to me: The people see that
things are broken and they name it. The multitude of programmers is an
illusion.

Because I'm a curious kind of creature, I decided to search the entire
Microsoft MFC source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 0 occurrence(s)
FIXME: 0 occurrence(s)

Is that really a suprise? You must use MS speak for finding that
things. You can not expect them to say straigt-forward. "oh that
sucks"....

Regards
Friedrich

 

[santosh]

Hi guys!

I recently downloaded the Linux Kernel source code, in the hopes of
learning a thing or two about how the "pros" do it in C.

Unless you are fairly competent with C, it's probably going to confuse
you further.

Much to my chagrin, I inevitably came across comments that included
the words "kludge" and "FIXME" in the Linux Kernel source code.

Because I'm a curious kind of creature, I decided to search the entire
Linux Kernel source code for instances of "kludge" and "FIXME". And
here is what I found:

kludge: 154 occurrences
FIXME: 3120 occurrences

These results seem rather striking to me. After all, the Linux Kernel
source is "open source", and, frankly, I expected to find 0
occurrences of both these search strings, given that we should have
multitudes of programmers working on this source and fixing the bugs
in what I pretty much expect should be real-time.

That just shows that you are inexperienced with developing large
software systems. I would say that those figures that you have shown
above (assuming that they are correct), are actually quite acceptable
given the size of the software concerned and it's development
methodology.

Also note that "kludge" and "FIXME" don't necessarily mean bugs. It may
simply mean that the tagged code is less than ideal.

Because I'm a curious kind of creature, I decided to search the entire
Microsoft MFC source code for instances of "kludge" and "FIXME". And
here is what I found:

kludge: 0 occurrence(s)
FIXME: 0 occurrence(s)

At this point, I'm feeling pretty damned hoodwinked. That desktop
graphic of the penguin sucking on a cardboard drink container with the
Windows XP logo and the words "We suck more!" on it look really
appealing, but what is really behind all that--just a dog-and-pony
show?

If that's how you feel, then you should give Linux and pass and go play
with your shiny new Microsoft (R) Windows (R) Vista (TM) Ultimate (TM)
Edition.

My C question is the following:

Is it good practice to comment our code with words like "kludge" and
"FIXME"?

If it is used consistently within the project then I don't see any
obvious objections.

If so, what does that say about our requirements in specific, and our
development process in general?
Huh?

And if so, shouldn't we expect nothing less than undefined behavior?

Not necessarily. It really depends on a case by case basis. As I said
earlier, some instances of code tagged as such may simply indicate a
contorted solution, or a less than ideal algorithm, or more than
necessary assumptions. Such code needn't exhibit undefined behaviour at
all.

Moreover in system software like Linux, undefined behaviour is not quite
the same as it is defined by the C Standard. Generally a portion of
code will either work or not work, barring errors. Not working might
either be okay (example the device associated with a driver is not
installed), less than ideal but all right (advanced ACPI is not
enabled, but system is otherwise usable), broken functionally (a
particular peripheral is disabled), or outright panic (a fundamental
problem either with the hardware or core portions of the system
software, making the system totally unusable).

I would reserve the term undefined behaviour for describing the outcome
of the machine state after a serious error like buffer overflow has
been triggerred within the kernel.

And if not, what does that say about the Linux Kernel source code?

Form your own conclusions and don't expect anyone to give them the least
weightage.

I notice that many of the Linux Kernel source code files list Linus
Torvalds as an author. I wonder if he is aware of this apparent
disarray of the current Linux Kernel source code? If someone has his
phone number, perhaps they might try calling him to inform him of the
current situation as described above to see what he thinks, and report
back here with a transcript of the conversation.

What disarray? If you feel so passionately about perceived bugs in the
Linux kernel, why don't you go ahead and fix them and submit your
patches to Linus? Or perhaps call him and make your concerns known. Be
sure to post the transcript of your conversation with Linus. It would
be an amusing change from the usual stuff trotted out by Kenny and Co.

For those of you who think I'm a pro-Microsoft dude and a Linux
basher, think again. I'm posting this from Linux. I just don't have
the same confidence in this Linux OS that I had when I installed
it--based on the evidence I presented, of course.

A good test of a piece of software is actually trying it out under field
conditions. If, after trying it out for a reasonable period of time,
you find Linux not to your taste (or your hardware's) then fine. Use
something else. Perhaps MacOS or BSD? Or perhaps Windows? Linux isn't a
solution for all users, neither does it claim to be, unlike Microsoft.

 

[Ian Collins]

Hi guys!

I recently downloaded the Linux Kernel source code, in the hopes of
learning a thing or two about how the "pros" do it in C.

Make that Linux developers do it in gcc, which isn't the same thing!

kludge: 154 occurrences
FIXME: 3120 occurrences

These results seem rather striking to me. After all, the Linux Kernel
source is "open source", and, frankly, I expected to find 0 occurrences
of both these search strings, given that we should have multitudes of
programmers working on this source and fixing the bugs in what I pretty
much expect should be real-time.

Why? They probably aren't bugs but less than ideal or messy solutions.
Look at the code and see why the comment is there.

Because I'm a curious kind of creature, I decided to search the entire
Microsoft MFC source code for instances of "kludge" and "FIXME". And here
is what I found:

MFC is a library, not an Kernel. It also comes form a source who are
hardly likely to be open about such things. To many, MFC in its
entirety is a kludge!

Try the same thing with the Vista source...

My C question is the following:

Is it good practice to comment our code with words like "kludge" and
"FIXME"?

Yes, there are often compromises, code the works but is inelegant.

 

[Steffen Buehler]

Billy Bong wrote:
Yes, there are often compromises, code the works but is inelegant.

I remember a colleague's comment in a mobile phone source code: "I am
proud of this goto statement!" Unfortunately, exactly this part
contained the bug I had to fix, and, sad to say, I removed the goto
again.

Regards
Steffen

 

[borkhuis]

This discussion is off-topic here, and would be better in a Linux or
MS advocacy group, even as your intend was to learn C. Learning C can
be done by reading a lot of code, but it is better to start with some
small project, where you could try to get involved in the development.
Next to learning C you would also be helping the development.

I recently downloaded the Linux Kernel source code, in the hopes of
learning a thing or two about how the "pros" do it in C.

Because I'm a curious kind of creature, I decided to search the entire
Linux Kernel source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 154 occurrences
FIXME: 3120 occurrences

From MFC:

kludge: 0 occurrence(s)
FIXME: 0 occurrence(s)

Look at this from another point of view: MS is shipping a commercial
product. Wouldn't you feel bad if you bought something with labels on
it like "fixme", "broken", "kludge", etc.? I guess MS probably has
some kind of filter to get these comments out of their code before
releasing a product. The fact that there are no keywords like these in
the code to me can indicate a number of things:
- Filter (as indicated)
- Separate quality control: problems in SW are entered in a database
and not in the code
- Unqualified developers
I expect that the first 2 are in effect at MS, however I cannot
exclude the last one As MS is a large company they certainly have
some QC tooling in place.

The fact that you find these in the Linux kernel is explained by the
fact that this is a project in development. These indications are only
for other developers, to indicate that some improvements can be made.
Of course there are some places where these FIXME's indicate real
problems, but usually there are workarounds in place.
Some examples of FIXME's:
udelay(1000); /* FIXME: seems a little long */
/* FIXME: obviously we want to put this in a header file soon */
/* FIXME: i don't like this... looks wrong */

Kind regards,
Johan Borkhuis

 

[Richard Heathfield]

Billy Bong said:

Hi guys!

I recently downloaded the Linux Kernel source code, in the hopes of
learning a thing or two about how the "pros" do it in C.

Um, right. Believe it or not, that's kind of off-topic here, and it's
pretty much flamebait material - but it may be possible to contribute an
impassive note or two.

Much to my chagrin, I inevitably came across comments that included the
words "kludge" and "FIXME" in the Linux Kernel source code.

Well, there's honesty for you.

Because I'm a curious kind of creature, I decided to search the entire
Linux Kernel source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 154 occurrences
FIXME: 3120 occurrences

And there's 3274 honesties for you.

These results seem rather striking to me. After all, the Linux Kernel
source is "open source", and, frankly, I expected to find 0 occurrences
of both these search strings, given that we should have multitudes of
programmers working on this source and fixing the bugs in what I pretty
much expect should be real-time.

Why do you expect this? Have you tried fixing any of these 3274 honesties
yourself? If you're not part of the solution, you're part of the test
tube. Er, problem. That is to say, if everyone assumes that kludges and
FIXMEs are Someone Else's Problem, then nobody will ever fix them, will
they?

Because I'm a curious kind of creature, I decided to search the entire
Microsoft MFC source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 0 occurrence(s)
FIXME: 0 occurrence(s)

Perhaps they use some other way to indicate problems. TODO might be worth
grepping for, I don't know. But bear in mind that you're comparing two
very different things - a class library and a kernel. Also consider that
MFC is something that MS has been moving away from for some years; why, if
it's so perfect?

At this point, I'm feeling pretty damned hoodwinked.
Why?

That desktop graphic
of the penguin sucking on a cardboard drink container with the Windows XP
logo and the words "We suck more!" on it look really appealing, but what
is really behind all that--just a dog-and-pony show?

I don't think so. I don't pretend Linux is perfect, but I'm using an
ancient SuSE distro and it has behaved remarkably well over the years.
It's roughly contemporary with Windows 2000, but a lot more stable.

The apps? Ah, that's different. Some of the programs in the distro could
certainly do with a lot of bug-fixing! But since I'm too lazy to fix them
myself or upgrade to later versions, I can hardly complain about that.
They work well enough, even though I wish they worked better. Principal
culprits? Galeon, Mozilla, Konqueror, Knode, Kmail. Oh, and kdeinit seems
to get carried away sometimes and hog vast numbers of cycles to no good
effect. (Of these, I think only kdeinit could reasonably be called a
system program.)

I don't use Windows enough nowadays to know how the MS versions of these
programs have improved over the years, but when I last used Windows a lot,
they (and it) still seemed pretty buggy. I'm told that it's all a lot more
stable than it used to be, and I'm glad about that, because frankly it was
almost unusable up to about 2003 or so.

My C question is the following:

Is it good practice to comment our code with words like "kludge" and
"FIXME"?

It's better practice to fix the code right away, of course - but people do
so love adding features, don't they? Besides, one man's kludge is another
man's craftsmanship. It's not like there's an ISO Standard to define
"kludge" for us. What I call a kludge, you might be happy with. What you
say is a FIXME, I might consider perfectly good code.

If so, what does that say about our requirements in specific, and our
development process in general?

Very little, actually. But I think you have at least a partial point - many
of us are too keen to get the thing "working", without worrying enough
about whether it *works*.

And if so, shouldn't we expect nothing less than undefined behavior?

Quite so.

And if not, what does that say about the Linux Kernel source code?

I don't know - but I do know that I'm pretty happy with the Linux kernel
I've got.

I notice that many of the Linux Kernel source code files list Linus
Torvalds as an author. I wonder if he is aware of this apparent disarray
of the current Linux Kernel source code? If someone has his phone number,
perhaps they might try calling him to inform him of the current situation
as described above to see what he thinks, and report back here with a
transcript of the conversation.

If anyone does that, be sure to tell him he's being recorded and that you
intend to publish the transcript. Otherwise, you could be on dodgy ground
(morally, at the very least).

For those of you who think I'm a pro-Microsoft dude and a Linux basher,
think again. I'm posting this from Linux. I just don't have the same
confidence in this Linux OS that I had when I installed it--based on the
evidence I presented, of course.

The proof of the pudding is in the eating. Does Linux do all that you
require of it?

If not, FIXIT. Or use something else. Or put up with it until someone else
fixes it.

It's your choice. And remember that, if it weren't for these alternative
OSs, you wouldn't have that choice.

 

[Robert Latest]

Not necessarily. It really depends on a case by case basis. As I said
earlier, some instances of code tagged as such may simply indicate a
contorted solution, or a less than ideal algorithm, or more than
necessary assumptions. Such code needn't exhibit undefined behaviour at
all.

Moreover, sections labelled as possibly flaky are good starting points when
a bug needs to be fixed in the affected part of the source.

robert

 

[Robert Latest]

Much to my chagrin, I inevitably came across comments that included the
words "kludge" and "FIXME" in the Linux Kernel source code.

Note that "kludge" probably means that the programmer had to work around
some issue that he could't resolve for himself, like a piece of kernel API
written by somebody else, or --very likely-- something to do with some
hardware.

Even programming in pure standard C itself requires kludges at times, like
when the compare function passed to qsort() needs additional data (there was
a thread about this a while ago on this newsgroup).

And for the FIXMEs -- don't we all at times hurry through some issue with
hastily written code that we know we should get back to some time? Either
because it's potentially buggy, or algorithmically inefficient, or simply
inelegant? If I attached a FIXME note to each instance where I'm not
checking printf()s or --much worse-- malloc()s return value there would be
very little C flesh in between.

kludge: 154 occurrences
FIXME: 3120 occurrences

Given God knows how many tens of thousands code lines those number
(especially the "kludges") seem very modest.

Is it good practice to comment our code with words like "kludge" and
"FIXME"?

If we write kludges (which are often necessary) and possibly buggy code (who
doesn't?) I think it is excellent practice to mark it as such. As a reminder
to ourselves when we get back to our own code, or as a hint to somebody else
who may work on it.

If so, what does that say about our requirements in specific, and our
development process in general?

It says that we're aware of our own fallacies and don't have a reason to
hide them from our customers because we're honest, and they expect honesty.

And if so, shouldn't we expect nothing less than undefined behavior?

From marked FIXMEs and kludges and the rest of the code alike, yes.

And if not, what does that say about the Linux Kernel source code?

It says that it was written by people who often knew what they were doing
and sometimes didn't. In short, by people.

I notice that many of the Linux Kernel source code files list Linus
Torvalds as an author.

Surprise ;-)

I wonder if he is aware of this apparent disarray
of the current Linux Kernel source code?

He more than most others I'm sure.

I just don't have the same
confidence in this Linux OS that I had when I installed it--based on the
evidence I presented, of course.

Just don't read system code, from any OS. It's bad for the head.

robert

 

[Syren Baran]

Hi guys!

Because I'm a curious kind of creature, I decided to search the entire
Linux Kernel source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 154 occurrences
FIXME: 3120 occurrences

You are aware of the fact that the kernel consists of over 4 million
lines of code?
You are aware of the fact that "make menuconfig"'s first item is "code
maturity level"?

 

[Kaz Kylheku]

Because I'm a curious kind of creature, I decided to search the entire
Microsoft MFC source code for instances of "kludge" and "FIXME". And here
is what I found:

kludge: 0 occurrence(s)
FIXME: 0 occurrence(s)

Hi Billy Bong,

I hope you realize that in software engineering ``zero occurences''
really means ``no known occurences''.

Before you can document something as a kludge or fixme item, you have
to recognize that what you have written is in fact such a thing.

I suspect that if I were to review the MFC code line by line, I could
add in thousands of missing ``kludge'' and ``fixme'' comments.

 

[Kaz Kylheku]

Billy Bong said:

Why?

Because that sort of suspicion is the typical reaction of a small
mind. Someone's always out to pull that proverbial wool over his eyes
and take advantage of him! But of course, he won't let that happen
because he's too clever.

 

[Bart C]

You are aware of the fact that the kernel consists of over 4 million lines
of code?

4 million lines? Just for a kernel? I make that a stack of 70,000 A4 sheets,
some 24 ft/7m high if printed single-sided.

Surely that can't be right? Is an OS really that complex?

But then, I remember jacob navia writing about gcc, that each contributor
wanted to be remembered for what they added to the project, not for what
they removed. Or something to that effect.

So software just gets bigger and bigger, because no-one wants to be
responsible for getting rid of large chunks of someone else's code.

 

[santosh]

4 million lines? Just for a kernel? I make that a stack of 70,000 A4
sheets, some 24 ft/7m high if printed single-sided.

Surely that can't be right? Is an OS really that complex?

Ha! If you think four million lines are too much, consider the fact that
Windows 2000's LoC was estimated at around 30 million. And yes, that
was about seven years ago. Heavens knows what the LoC count for Vista
is. I don't even want to know.

But coming to your question, the bulk of the code for the Linux kernel
(and I presume most kernels) are from the device drivers. The vast
variety of devices out there and the imperative for serious OSes to
support as much of them as possible means that they end up with an
awful lot of drivers.

But then, I remember jacob navia writing about gcc, that each
contributor wanted to be remembered for what they added to the
project, not for what they removed. Or something to that effect.

Yes. Maintenance and bug fixing aren't as glamorous as being an original
contributor.

So software just gets bigger and bigger, because no-one wants to be
responsible for getting rid of large chunks of someone else's code.

Not without a good reason. In the case of Linux, there is no reason to
remove a perfectly working device driver, simply on the account of
reducing LoC count or because the associated hardware has become a
rarity. There might still exist someone who wants to use it.

Also refactoring a large software system is very difficult task and the
prime motivation for people contributing to open source projects is to
add functionality rather than spend time correcting and refactoring.

 

[Ian Collins]

Ha! If you think four million lines are too much, consider the fact that
Windows 2000's LoC was estimated at around 30 million. And yes, that
was about seven years ago. Heavens knows what the LoC count for Vista
is. I don't even want to know.

But coming to your question, the bulk of the code for the Linux kernel
(and I presume most kernels) are from the device drivers. The vast
variety of devices out there and the imperative for serious OSes to
support as much of them as possible means that they end up with an
awful lot of drivers.

<OT>
Gone are the days when kernels had to be rebuilt to add a driver, these
days with modern kernels, drivers are loadable modules.

The LOC count probably includes the userland utilities and networking. </OT>

 

[Syren Baran]

4 million lines? Just for a kernel? I make that a stack of 70,000 A4 sheets,
some 24 ft/7m high if printed single-sided.

Surely that can't be right? Is an OS really that complex?

Its just the kernel.
Well over half of it are device drivers.
Next biggest part is architecture dependent code.

But then, I remember jacob navia writing about gcc, that each contributor
wanted to be remembered for what they added to the project, not for what
they removed. Or something to that effect.

Well, try that on lkml if you wish, you'll get a spanking.

So software just gets bigger and bigger, because no-one wants to be
responsible for getting rid of large chunks of someone else's code.

Nope. Lots of new hardware. Architecture. File-systems. Optional modules.

 

[Kaz Kylheku]

4 million lines? Just for a kernel? I make that a stack of 70,000 A4 sheets,
some 24 ft/7m high if printed single-sided.

The kernel runs on i386, SPARC, MIPS, PowerPC, Alpha, HP PA-RISC,
68K, ....

It supports many, many boards, peripherals, filesystems, networking
protocols ...

Get it?

The vast majority of the kernel code is not in the central parts like
scheduling and memory management, but in drivers and other modules.

Nowhere near all of the four million lines of code are compiled in
whatever Linux setup you may be running.

This doesn't, by the way, count the kernel code that is /not/ in the
kernel. There are drivers and various other patches out there are not
part of the kernel stream.

Surely that can't be right? Is an OS really that complex?

No, and OS is not that complex. But yes, there is a crapload of
hardware out there, filesystem formats, protocols, etc. They all do
the same thing in different ways, and so all of the pieces of code to
handle them resemble each other. If you understand two or three
network drivers, you've pretty much seen them all.

So software just gets bigger and bigger, because no-one wants to be
responsible for getting rid of large chunks of someone else's code.

But you don't necessarily want to get rid of a module, even if it
drives very old hardware, or a rare, obsolete filesystem format, etc.
Someone somewhere might be using it.

What can be done is to push it back out of the kernel stream so that
it again lives as a patch or stand-alone module. Let the people who
need that code maintain it themselves.

 

[Billy Bong]

Hi Billy Bong,

Hi Kaz,

I hope you realize that in software engineering ``zero occurences''
really means ``no known occurences''.

I fully realize that.

In my experience, any piece of software that is non-trivial still has
bugs, no matter what confidence you may think you have in regards to it
not having bugs. I've been there so many times ...

"This is the final do-all-and-end-all-release that eliminates all the
bugs."

But, yes, inevitably, and without fail, someone finds a bug.

I've learned to expect that.

But, I've also learned that you or me or someone else may well find a bug
in my/our software, and I'm somewhat comforted by the fact that me/us
have done enough of a good job at following our software development
process (requirements, design, implementation, verification--and CM and
QA, if available [1]) that the type of bugs that will be uncovered are
not of the show-stopper type (e.g., crashes).

Before you can document something as a kludge or fixme item, you have to
recognize that what you have written is in fact such a thing.

Good point. What frustrates me is that a company such as Microsoft is
often privy to the types of details that can eliminate "kludges" and
"FIXMEs", whereas those such as Linux developers are not.

I suspect that if I were to review the MFC code line by line, I could
add in thousands of missing ``kludge'' and ``fixme'' comments.

I know firsthand of kludges and fixmes in MFC code. But, I doubt that
these types of bugs are in the "thousands". My estimate would be that
they are in the "hundreds", if not the "tens". When you pay someone to do
something, you can expect better results compared to when you don't pay
them. Microsoft pays people.

Best regards
--
Billy

[1] A good question is ... do Linux Kernel developers in specific, or
open source developers in general, follow a documented software
development process? Or is it all ad hoc?

 

[santosh]

Hi Billy Bong,

Hi Kaz,

I hope you realize that in software engineering ``zero occurences''
really means ``no known occurences''.

I fully realize that.

In my experience, any piece of software that is non-trivial still has
bugs, no matter what confidence you may think you have in regards to
it not having bugs. I've been there so many times ...

"This is the final do-all-and-end-all-release that eliminates all the
bugs."

But, yes, inevitably, and without fail, someone finds a bug.

I've learned to expect that.

But, I've also learned that you or me or someone else may well find a
bug in my/our software, and I'm somewhat comforted by the fact that
me/us have done enough of a good job at following our software
development process (requirements, design, implementation,
verification--and CM and QA, if available [1]) that the type of bugs
that will be uncovered are not of the show-stopper type (e.g.,
crashes).

Oh? Then why does, for example, Microsoft software, (which you'd presume
to have been the product of the best software engineering practises),
have so many "show-stopper" buffer overflow vulnerabilities that need
to be fixed by a continuous rain of patches?

Why is it that I have had Windows, which by your line of reasoning be
the superior product, crash more times than I have kept count, while I
can list the number crashes I have had with Linux on the fingers of one
hand?

Good point. What frustrates me is that a company such as Microsoft is
often privy to the types of details that can eliminate "kludges" and
"FIXMEs", whereas those such as Linux developers are not.

What details? Are you saying that Microsoft has magical methods to purge
code of all bugs, while others must flounder in the dark?

As far as I can tell, techniques to produce good software are already
known to every serious developer. It all a matter of putting it into
practise.

I know firsthand of kludges and fixmes in MFC code. But, I doubt that
these types of bugs are in the "thousands". My estimate would be that
they are in the "hundreds", if not the "tens".

Your basic comparison is flawed. You are comparing an OS kernel with a
GUI library. Maybe MFC might have only "hundreds" of kludges and
FIXMEs, but when you consider Windows as a whole, we all know who wins,
by a wide margin, on the bug count.

When you pay someone to do something, you can expect better results
compared to when you don't pay them. Microsoft pays people.

It's not as simple as this. Bad code can be produced whether someone is
payed or not. The best way to ensure that best possible code is
produced is to enable competent and interested people to work on it. A
disinterested developer is going to churn out broken code whether he is
working on an OSS from home or in Microsoft. He is likely to be bested
by an intelligent and motivated volunteer.

 

[Kaz Kylheku]

Good point. What frustrates me is that a company such as Microsoft is
often privy to the types of details that can eliminate "kludges" and
"FIXMEs", whereas those such as Linux developers are not.

Incomprehensible babbling. I think that what I said above is that just
because the comments don't say anything about kludges doesn't mean
there aren't any.

I know firsthand of kludges and fixmes in MFC code. But, I doubt that
these types of bugs are in the "thousands". My estimate would be that
they are in the "hundreds", if not the "tens".

I could probably find ten for every one you find, because, you appear
pitifully stupid.

And surely MFC isn't four million lines? Don't you think it would be
more meaningful to compare density: so many occurences of the
interesting artifact per so many lines of code?

A hundred artifacts in a hundred-thousand lines of code is the same
density as a thousand artifacts in a million lines of code.

You know. That division thing. The / button on your calculator.

When you pay someone to do
something, you can expect better results compared to when you don't pay
them.

Wrong guess. Now go read up on the psychology. It is well documented
that people produce their best work when they are internally motivated
(doing something for its own sake).

Of course, that is not incompatible with being compensated---as long
as the compensation isn't the motivation.

For instance, see the 1973 paper, "Undermining children's intrinsic
interest with extrinsic rewards: A test of the overjustification
hypothesis" by M Lepper, D Green & R Nisbett.

Microsoft pays people.

A lot of the work in the Linux kernel was paid for by someone. I'm
doing kernel development for a living, currently. Not just kernel
development, but that's a big part of the job. I write code that goes
into the kernel, or modify existing code. I have fun, and I get paid
for it.

[1] A good question is ... do Linux Kernel developers in specific, or
open source developers in general, follow a documented software
development process? Or is it all ad hoc?

They follow an incompletely documented development process. Which
isn't the same thing ad-hoc. False dichotomy.

Anyway, if I feed you any more, you won't fit under the bridge.