Re: Win2000 has 63,000 'defects'

[pontius@twonky.btv.MBI.com.invalid (Dale Pontius)]

In article <952459361.11185.0.nnrp-12.d4e5bde1@news.demon.co.uk>,
        "Mike Dimmick" <mike@dimmick.demon.co.uk> writes:
...
> I did an analysis of some of the competition -- the one the press are
> all hyping, Linux -- when I first heard about this article, and read it.
> I examined kernels only, versions 2.0.0 thru 2.0.38.  These releases
> occurred over 38 months, an average of one a month.  It's interesting to
> note that 2.0.36 - 2.0.38 appeared six months apart, so some of the
> releases occurred far more frequently.
>
> What I did was as follows:
> Obtained all the patches;
> Ran them through 'grep' looking for the '@@@' sequence to mark the
> beginning of a patch hunk.  I then used 'wc' to count the number of
> hunks in each patch.
> I don't have the complete listing available, but I do remember the final
> figure was of the order of 16,000 fixes.  Given that the total source
> for kernel 2.0.38 was around 5Mb, I'm quite worried by that statistic.
> It also appears the trend is worsening; kernel 2.2 has been out for six
> months and is on something like patchlevel 20 right now.
>
The other art of this exercise would be examining the changelogs
for that same timeframe. There are bugfixes to the base OS, to be
sure. But there are also platform and hardware fixes - that same
source tree targets multiple platforms and CPU architectures, as
well including the device drivers - implemented as kernel modules.
There is also some feature creep. The 2.0 series was notorious for
that, but even if it's only the support of a new device, it still
shows up as a kernel change. So IMHO treating your count as bugs
is somewhat inaccurate. It would be interesting if the changelogs
could be correlated to your count to get a more accurate number.

Not to mention that one of those patches roughly in the 2.0.35
timeframe was a fix for the Intel F00F bug. NT had a fix for that
one, too. But in both cases, I'd count the OS patch as a plus.

Considering the hardware support issue, where does a bug cross the
line between an OS bug and a driver bug? In Linux, the drivers are
kernel modules, and show up in your analysis. NT ships with some
number of drivers, in the box. Have driver bugs been counted in the
63000 number? How complete is driver coverage of the GA ship CD?
How common is it to need hardware manufacturer CDs to install, even
before you consider hardware developed after GA ship?

Side question, though more relevant...

Isn't GNAT supposed to get included into the mainline gcc distribution
at some point? If/when that happens, how feasible would it be to
write a Linux kernel module/device driver in Ada?

Dale Pontius
NOT speaking for IBM