[Beowulf] scheduler policy design

[Mark Hahn]

> As an operating system <http://en.wikipedia.org/wiki/Operating_system>, *

this is a common use of the word.  it's a bit sloppy: Linux is, strictly
speaking, just the kernel.  why make the distinction?  mainly because Linus
and the kernel team don't have that much to do with ongoing development of 
anything in user-space (libc, tools, compilers, X, desktop environments,
etc).  it's not some kind of major sin to avoid naming the thousands of 
independent projects which are tossed like a salad to form a distro.

> Do you not consider Knoppix a Linux, or do you consider "openMosix" to come
> from kernel.org?

Linux is the kernel; it is unitary (ignoring versioning).  when people talk
about flavors of linux, you know they're probably talking about distributions 
which contain Linux as their kernel.  "openMosix is a Linux kernel extension" - 
that's from their website.  the naming is a bit blurry because the extension
requires a bunch of user-space stuff to work, too.  then again, the bare 
Linux kernel doesn't do much without, for instance, at least a libc,
and probably a bunch of other user-space infrastructure like shells 
and daemons.

openMosix's kernel is a customized version (not really a fork) of the
kernel.org "mother" kernel.  RH's kernels are too, or Suse's or SGI's or
HP's, etc.

> me. Perhaps I need to distinguish "kernel, the minimum machine-dependent
> component"

everything is machine-dependent.  besides, most of the kernel is _not_
terribly machine-dependent (it's the drivers which depend on the hardware 
they're driving - but that's almost a tautology!)

"Linux" in the non-strict sense, is a bit of a shorthand for the kernel
and all the usual user-space do-dads.  perhaps it needs a snappy acronym
like LAMP or AJAX, but it would have too many letters!

> from "kernel, what is in memory after boot ends" but I would

that would be a very strange definition.  how about this: apps call libc
to do almost everything.  libc calls the kernel to do almost everything, but 
adds some value by providing a slightly higher-level interface (eg printf()
rather than write().)  the kernel calls drivers to do a lot, but also 
does the higher-level-interface thing (such as filesystems rather than 
block-level disk interfaces).

strict Linux-ness stops at the user/kernel line, but since most of the 
lower-level parts of userspace are pretty linux/kernel-specific, they get 
lumped into the name.  this is why certain notable people have advocated
for the use of "GNU/Linux" rather than just "Linux".  in fact, I use the 
latter specifically because I oppose this (RMS's) nomenclature.  when someone
talks about their linux desktop, they're not discounting the contribution 
of GNU - in fact, there are lots of non-GNU projects which are critical to 
the linux desktop, many of which predated Linux, some of which are not even
Unix-specific.

> expect that a kernel optimized for a compute node would vary even in the
> first defintion from a single kernel published at kernel.org.

there's not much to optimize in the kernel for a compute node.  you can
certainly omit stuff, but that's a normal part of configuring a kernel.org 
kernel.  what makes a good compute node is mainly user-space, so not strictly
Linux, but more in the distro realm.  that said, most distros use almost 
identical parts to their salad - it's mainly the dressing or perhaps just 
the sprinkles and crutons that distinguish distros ;)

this is fun!  some distros use slightly fresher greens; others have mouldy 
old tomatoes.  damn, gotta find a way to fit the kernel into that metaphor - 
maybe the salad's bowl!?!