Re: The Kernel

[Rick Jones <rickya@siservices.net>]

William T Wilson wrote:
> 
> Is not the purpose of the core to have a system which developers and users
> alike can call a standard?  I would think that would imply some degree of
> standardization...

I have to say that I am also a bit dissmayed at the disro leaders idea
of, seemingly, having a core that enforces no standard.

When I conceptionalize a core, I think of the smallest collection of
Linux binaries, to include a basic GUI layer, that will allow me to run
*ANY* program made for Linux.  That does not count programs that require
specialized libraries or toolkits that provide a specific functionality,
i.e. Motif, although the *ability* to add those specialized items *and*
have them work properly is paramount.

That means that, *functionaly*, the filesytem, kernel, libc, xlib's,
Xserver, installation program, init, login authentication, /proc/*,
/dev/*, configuration files, and a host of others I'm sure I've left
out, have to *all* be predictable.  Right now there is a margin of
predictability between distro's at the core, but they should all be
perfectly predictable.

That does not mean each distro can't *add* to the core to make it *their
own*.  They just absolutely can not add anything that takes away the
least bit of fundamental functionality from the core.  If they want to
be core compliant.  They should be able to offer *optional* packages to
install,to their distro,that may break that rule *after* the user is
fully briefed on the consequences of making such a decision.  Such as no
longer being able to rely on the core version number when it's required
for some software package.

Now, we are all experenced enough with Linux to know what has to be in
the OS for it to run.  We also know that kernel patches, for the most
part, *add* to a kernel without removing existing functionality.  It's a
must for backwards compatability.  There are those that remove
functionality by design, and as a bug.  As long as the kernel is 100%
backwards compatable with the *core* kernel there should never be a
problem including that in a base distro.  Note the distinction between
*base distro* and *optional*.  Base is required for that particular
distro (in addition to core) where optional is just that.

If a distro wants to *add* a specific filesystem tree for their
purposes, so be it, but the files that aren't specific to their distro
have to comply with FSH.  i.e. If Debian wants to put /usr/doc/Debian/*
in /Debian so be it, it only effects Debian specific files/programs. 
Putting /etc/* under /Debian/etc/ is forbidden to remain compliant.

I don't think any of that is unreasonable for any distro to follow.  It
only stablizes Linux as a whole.  The number one key to it is 100%
backward compatabilty in reguards to standards.

If something is *not* required to make Linux backwards compatable it
isn't required in core.  It may be added due to an emerging need or
requirement that wasn't previously noted or something similar, i.e.
IPv6.  If you can't remove something from core without breaking
backwards compatability then it must stay, unless the need for it has
become obsolete, i.e. MSDOS filesystems, well, some day =).

That is where I see the boundaries in my mind.  The finished guidelines
may vary from my idea somewhat, after all we are a *group* of
experienced Linux folks and we all have something to bring to the table.