Re: [nottingham] Tales of 2.4

From: Matthew Sackman (matthew@sackman.co.uk)
Date: Sat 09 Mar 2002 - 14:23:36 GMT


On Wed, Mar 06, 2002 at 03:50:41AM +0000, Jon Masters wrote:
> Hi,
>
> I am currently pondering the wonderous lack of stability which has been
> series 2.4 of the Linux kernel. We all know about the various trials and
> tribulations, the vm switchover and many other things. The fact remains
> that I have seen a certain java process repeatedly kill 2.4, dead. The
> latest problem for me has been with loopback (some probably saw my post to
> lkml on that one - its now in private discussion)[0].
>
> Anyway, I've had numerous very bad experiences with 2.4 which have been
> both embarassing and as an outsider would have put me off for use in a
> commercial environment (quite frankly, Solaris and friends are far more
> stable than 2.4 has ever been*). Please, no flamewars or personal attacks,
> let's just see what people honestly think from their experiences.

(this may turn into a long ramble in which case, sorry!)

I've run 2.4 kernels on 2 gateways and my workstation for a while and all
are now on 2.4.17 +0(1) schedular patches. My own experience is that they
are at least as stable if not more stable than 2.2 kernels.

But if you are having stability problems then you have to ask why? I personally
often put my machines (uni proc) past load avgs of 10 and have no problems.
I run dual head and a few other exotic bits and still have no problems.
One of the gateways is always on, and runs seti permanently. No problems
at all.

Which version of GCC are you using to compile? AFAIK, gcc-3 is still not
guarenteed to compile a kernel reliably.

OTOH, if you really are putting your machines through hell then maybe you
should be expecting problems: the vm layer is still largely buggy, I've read
that RH managed to patch it up to get it to a better state but Linus won't
apply the patches. This has happened with a lot of patches (rmap, ide etc)
and a lot of ppl are really not happy with Linus for not applying their
patches but what is the alternative?

If you apply every patch then sure, it may fix some problems, but it is also
likely to break a lot of other things, and if that happens then no-one is
going to know why, or how to fix the problems: it is *only* because Linus
has personally reviewed every patch that has gone into linux that linux
is as stable as it is. The fact that things are now developing slower
I would suggest is because of the extreme complexity of the kernel, the
fact that so few people understand the entirity of the kernel and that it
is a monolithic kernel.

I'm sure that Linus still views this whole thing as his baby, in which case
put yourself in his position: would you really allow other people who you
don't know and don't trust to apply patches to your kernel? I think not.

Just because it's been very successful doesn't mean it's perfect at all.
Just because it has hundreds of developers working on the kernel alone
doesn't mean there arn't bugs in it. Are you sure that you wouldn't have
the same problems if you used a *BSD or a commercial *nix like Solaris?

My own opinion is that if the same number of developers had spent the same
amount of time with a microkernel system (like HURD) then the resulting
system would be far ahead of linux as it is now simply because by segmenting
the system so heavily you remove the possibility that code in one deamon
depends on code in another. All that needs to remain is the API. Whereas
in linux, large areas of code can simply not be changed at the moment because
too much other code depends on structs etc that are being exported.

I suppose it's a dumb idea to querey your hardware?

Just my 2p,

Matthew

-- 

Matthew Sackman Nottingham England

BOFH Excuse Board: Computers under water due to SYN flooding. -------------------------------------------------------------------- http://www.lug.org.uk http://www.linuxportal.co.uk http://www.linuxjob.co.uk http://www.linuxshop.co.uk --------------------------------------------------------------------



This archive was generated by hypermail 2.1.3 : Sat 09 Mar 2002 - 14:31:12 GMT