Re: [Sheflug] RAID and kernel upgrading.

[Alex Hudson <nospam [at] york.ac.uk>]

On Fri, 9 Jun 2000, Stephen J. Turnbull wrote:

>     Al> I think it's more interesting to compare the speed of
>     Al> development with the money going in - most people think that
>     Al> the development has speed up dramatically, notwithstanding the
>     Al> commercial code going in (i.e., ports from other OSes, etc.)
> 
> Dunno.  This is really interesting.  But are people counting vaporware
> features or solid code when they talk about development speedup? 

Possibly, but not necessarily. For example, it would be possible to count
XFS, JFS, ReiserFS, etc., but they really count as commercial code
(possibly not ReiserFS). But I think in general, actual bona-fide kernel
development has sped up. It certainly seems like it, anyway. 

> most people I know think that Linux SMP, while cool in principle,
> basically doesn't give you anywhere near the extra BogoMIPS that Linux
> on a single processor does.  SMP is hard, but so are all the really
> core things about improving stability, reliability, and conformance.

Hmmm. John Carmack coded an SMP Quake at one point, and while it was
probably quite a noddy version he reckoned it gave 10% improvement. Here,
we're talking complete io-bound process, in which case there ain't a lot
you can do without extending the bus arch, etc. With compute-bound
processes, such as SETI [at] HOME for example, performance is pretty much 100%
improvement. Personally, though, I don't worry much about extra bogomips
;). Certainly, SMP is an interesting system (race conditions, deadlock,
atomic actions, all real Djikstra stuff ;)

> I just don't know.  Nobody really knows how to _measure_ that kind of
> thing.

Look at it. Use it. If it feels faster, all is good. ;)

> Will> They ARE NOT general releases. They are available to use at
> Will> your own risk.
> Al> That kind of then defeats the 'many eyes' principle also,
> Al> surely? As many people as possible should be running the dev
> Al> kernels, on many architectures, otherwise you end up with
> Al> broken stable releases.
> I guess; but that's besides Will's point (even though I disagree with
> him).  Nobody, Linus least of all, suggests using dev kernels to
> manage nuclear reactors.

Absolutely, I wasn't arguing with the 'general release' point. But
certainly, they need to be tested. And you can only test by using, so by
definition there have to be a set of people using dev kernels, other than
those writing the code (wood, trees, etc. ;). 

> Al> If it's labelled 'experimental', and hooks nowhere else, I
> Al> don't see what the problem is?
> Precisely.  The point being that it is possible to add features and
> whole subsystems with minimal impact on the kernel.  Certain ones,
> anyway.  I was shocked when I read that.  Pleasantly, of course.

Oh right. I thought you were railing against it ;)

> Al> I think there was also talk of remodelling part of the PCI
> Al> spec to be more like USB.. USB also requires devfs I
> Al> believe. Ho hum...
> 
> devfs would cause some problems; not least with Linus.

Er, AFAIK devfs is IN. And is the default ... I /think/. Personally, I'm
in favour of devfs (and people I've mentioned it to seem to like the
idea), but it doesn't half break, er, *everything*. Plus, I think all the
names are changing. No more hda1, etc. etc. Ahhhhh......

Cheers,

Alex.


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.