Is the Linux kernel getting buggier

[Maaz]

"Is the Linux kernel getting buggier? According to Andrew Morton, the lead maintainer of the Linux 2.6 kernel, in a CNET report from the LinuxTag conference in Germany, there's getting to be too much bad code in the kernel.

"'I believe the 2.6 kernel is slowly getting buggier. It seems we're adding bugs at a higher rate than we're fixing them,' said Morton..."

source: http://www.softpanorama.org/Articles/Linux_vs_Solaris/comparison_of_internal_architecture.shtml

if the above is true then people should stop using Linux

[Ivan Krastev · Accepted solution]

This looks like MS press information :).

The usage of the OS always depends from the business needs, application design, etc. If you don't know what is happening in the kernel (like in Windows products) does't make it more secure/stable.

regards,
ivan

[Ragu_3]

The kernel Linux is a monolithic kernel, it is not getting buggier but getting more usable, more scalable and has more support for a range of hardware devices. The development model should be a real eye-opener for software vendors who think that the propreitary model is the only way. The GNU Project has scaled up so well to give us all a stable+free (free as in freedom) OS known as GNU/Linux. Bugs are rapidly fixed unlike propreitary software. A range of hardware archs are supported by GNU/Linux, Debian has 13 odd ports.

[Jeeshan]

:)

yeah i think the those who are oppose Linux has published that.

you can learn more about linux kernel 2.6 is here

http://kniggit.net/wwol26.html

[dirk dierickx]

Currently the linux kernel development is going at the fastest pace since the beginning some 17 years ago.

What Andrew thus refurs to is that we got a lot of exciting new thing happening in the kernel. a boatload of new features are being added, although these new things are buggy (which is logical) and the people fixing things seem to be outnumbered. His proposal was to introduce a 'freeze' period were no new features were being added and the developers only work on fixing bugs.

It used to be like this, the 2.even.x series were rock solid, they only contained fixes or every now and then a backport which was considered stable. the 2.uneven.x series were development kernels, dangerous beast that would eat your pc on boot and launch nuclear missiles!

Anyway, Linux decided to throw that all out of the windows with 2.6, and he was correct, the IT world started to evolve at a lightning speed, and spending years on a development kernel would not be a good idea (it would turn the stable kernel into an outdated platform).

Conclusion: nothing to worry about, new code is always buggy (if you compile kernels yourself, they warn you about the dangerous parts) and even solaris has this problem, zfs, for example, is still not stable enough to be production ready, so they better point the finger at themself as well.
The quality of code added to linux is still high, recent research confirms it to be among the best, the code base is growing fast, while the bug rate, _percentage_ wise!, stays about the same.

[Maaz]

good replies from Ragu, Ivan Krastev, and ahsan, but SUPER/EXCELLENT reply from Dirk Dierickx

more comments would be appreciated.

[Arthur Marsh]

It might also be that it is physically impossible for kernel developers and distribution maintainers to test kernels against all possible combinations of hardware that is supported in the Linux kernel.

The Linux kernel development process attempts to eliminate bugs at the earliest possible stage (clean code tested by the developer and widely reviewed), and continues with practices such as building kernels on multiple architectures and with multiple configuration options to help identify any problems with code that makes wrong assumptions.

Since there is support for more hardware with each new kernel, a particular combination of hardware may have problems that are first discovered by a user rather than by a kernel developer. In my case, I have a DPT 2044W SCSI card (bought in 1998) that works fine with kernels up to and including 2.6.22, but fails with 2.6.23 and later kernels. Maybe very few people are running GNU/Linux with that particular SCSI card, or do so in a stable environment with an older kernel that does not have the problem.

One can do a git bisection of the kernel code to try to find what change triggered the problem. The use of git bisection to find kernel bugs has itself been a matter of much discussion by kernel developers, but in the absence of kernel developers and distribution maintainers having the ability to build and test kernels against all possible combinations of hardware, that's what I'll do. It's better than dropping support for old hardware just because no-one could test it before release.