Re: A linux patch for a typo

["Ronald F. Guilmette" <rfg@monkeys.com>]

In message <Pine.LNX.3.95.980525113526.10917B-100000@penguin.transmeta.com>, 
Linus wrote:

>On Mon, 25 May 1998, Ronald F. Guilmette wrote:
>> 
>> The C library, among other things, is (in effect) my interface to kernel
>> functionality... assuming that I am an applications programmer.  If I
>> happen to install a new kernel someday, and if some small, obscure, but
>> significant detail of that interface changes on me (and my application code)
>> I definitely would like to feel assured that I _will_ automatically get the
>> new #defines or dtructure definitions, or whatever when and if I recompile
>> my old code in the new environment.  It seems to me that the best way to
>> insure that there will not be a divergence between what the kernel actually
>> expects and the interface that the system include files actually provide
>> is to just make some of the system include files be links to (or includers
>> of) the actual kernel include files.
>
>This was the original reason for trying to use the kernel header files..
>
>It's a good reason, and I'm not arguing otherwise. It used to make perfect
>sense. 
>
>However, while sharing header files has a few good things going for it, it
>also has some bad things associated with it. 

Indeed.

I'll try to be brief.  I'd like nothing more than to get involved in this
whole controversy.  I certainly do have strong opinions about the whole
thing (as I do on almost every subject) but I'm afraid that I just don't
have time to do so because I'm already deep into several other controversies
elsewhere.

I will just say, as I have already said, that the system include files _are_
my interface to the kernel, at least when I am writing user-level applications
programs, and thus I really don't believe that they can be either separated
from or made fully independent of the kernel and/or the codes and structures
that it expects or produces in any of its many incarnations.  To try to make
the system include files independent of the kernel seem to me to be a hopeless
mission.  One might as well try to make the landscape independent of the
land, the clouds independent of the sky, or the waves independent of the
sea.

Having said that, I do indeed understand Linus' motivations for wishing that
it were possible to separate the two, and I myself even alluded to the
problem/issue, i.e. that often times I myself will try to upgrade _only_
my kernel or _only_ my C library, without also upgrading the other com-
ponent also at the same time.

It is of course rather a nice convenience to be able to do this (from an
end user's perspective) but that is NOT the same as saing that it makes
sense as a thing to be _supported_ from the prespective of the people who
are working on and maintaining the kernel and library code.  In fact I
would argue that it _does not_ make sense to try to support any kernel
version with any library version, and that the two should be (and in fact
are) ``joined at the hip'' as it were.

The issue of support (and what combinations are supported) is one which
should be given some more thought I think.  I'm just sitting here thinking
that Bill Gates isn't spending a lot of time trying to make every version
of the Windows library work with every version of te Windows kernel, and
in the case of Linux, we have even less ``support'' resources to draw on
(and certainly less well-paid ones :-) so I believe that it would make
sense to say that henceforth, each release of the library and include
files should be clearly stamped as only working with verison N.N.N of the
kernel, or later.  H.J. may not like that arrangement, and he might pre-
fer that it be the other way around (i.e. that each kernel is specified
as only working with certain library versions) but I do think that the
kernel has to be, and in fact will be in the driver's seat as far as this
compatability issue is concerned.

Anyway, I really do suggest that the parties to this discussion consider
maybe being not quite so liberal in future with regards to the question of
what versions of what components are considered to be ``supported'' when
used with what other versions of what other components.  In an ideal world,
every version of every components would just work with every version of
every other components, but we all know that we don't live in that ideal
world.  As a long-time Linux user, I can say that (for me at least) I will
not protest too much if someone tells me that the next time I upgrade my
kernel, I may also need to upgrade my library to go with that.  That's
still far less drastic that the Bill Gates approach, where I must start
again each time with _everything_ being new and fully tested for mutual
compatability.

In any case, I do hope that all the parties will remain every cognizant of
the fact our goals are all pretty much the same, that we all want what's
best (within the limitations of the available manpower) and that the vast
majority of all of the work on both the kernel and the library has been
done, is being done, and will be done by generous volunteers contributing
their own time without compensation.  Given that, I for one am, and always
will be, very very greatful to Linus for the thousands of hours he has
spent creating a great free kernel and also to H.J. for the thousands of
hours that he has spent maintaining the library and the software develop-
ment tools.  It is the _union_ of these efforts that makes Linux useful to
me, and to many thousands of others.

P.S.  I made a special effort above to mention Bill Gates prominently, be-
cause after all, we all know that he _is_ the real emeny.  The U.S. Government
is now about to spend some enormous sum in legal fees to try to prevent him
from being the near monopoly that he already is.  I have often fantasized
about some nbew version of WINE or WABI that (a) could run on Linux and
that (b) provided near perfect Win32 emulation.  I am frankly more than a
little suprise that neither Sun nor Novell nor Caldera ever bothered to
create such a thing.

Anyway, I really wish that people could put aside these smaller issues...
e.g. worrying about kinds of compatability that Bill Gates never even
thinks about... and spend more time thinking about how to create something
(on top of Linux) to break Bill Gates' monopoly, and therby to save the
U.S. Government a lot of money in legal fees.  Fantasy?  Perhaps.  But I
just thought I would mention it.  (I really have no idea why Sun and Novell
and Caldera don't team up to create such a thing.  Of course there are also
abous a zillion volunteers around the world who would gladly lend a hand
also.)

-- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
-- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
-- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/