lkml.org 
[lkml]   [2000]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Standard Linux (Was What is up with Redhat 7.0?)
Date
On Sat, 30 Sep 2000, Michael Peddemors wrote:
>On Sat, 30 Sep 2000, Marc Lehmann wrote:
>
>> However, I think attacking other free softwrae projects because of *bugs*
>> is just childish at this point - after all, this discussion was about
>> supporting distributions that - without technical reasons - make their
>> products incompatible to what one would call "standard linux", and that I
>> do not think that the kernel should support such doings.
>>
>
>
>That RedHat Thread was degrading into a name calling match...
>But it does have one core element that maybe should be discussed, and that can be a
>relevant and productive discussion for this list.
>
>'Standard Linux'
>Should the core kernel define a standard Linux??
>And what does the community think of distros that veer from the standard?
>Should the 'standard' be set in stone?
>
>ie should we say that ALL distros have to ship with, and be compatible with the
>standard kernel? If a distro has a patch that they want in the kernel, and the
>mainstream kernel doesn't feel it belongs, should it be labeled differently?
>Do we go with a Debian Linux, Redhat Linux, etc.. accepting that they are all
>different, but from a common heritage or should there be a 'seal of approval' so that
>a distro can indicate it is 100% linux mainstream, as in
>SomeDistro Linux, '100% Linux Standard Compliant'

This has come up in the past.

1. Most of the "distribution" is actually code from a totally independant (from
Linux) project - the FSF Hurd.
2. Linux only refers to the kernel. Not the distribution.
Most of the utilities (when you get away from device/kernel
setup/logging/initialization) is from that project.

I believe R. Stallman would prefer that the distributions be referred to
differently (Hurd/linux? That wasn't quite it... I don't remember what he said
specificly). It had to do with the source of most of the things that make a
system work - cp, ls, mkdir, gcc, libc,... These all come from a different
location, they are not part of Linux, although the Linux kernel is useless
without them.

>Thoughts?? I know our Linux Distro is non-conformant because of our FreeS/WAN and
>encryption patches.. Yes, we are still Linux, but I know we shouldn't get the '100%
>...Compliant' label.. Of course, from a marketing standpoint, I would hate to carry
>that stigma, but I think it is prudent that our customers have the right to know that
>their experience with other Linux's may not be sufficient, or that down the road they
>may be forced to use us for support, or get/buy 'LinuxMagic' software rather than
>'100% .... Compliant' versions of the software if we choose to not be compliant.
>That is the risk of using our product if we are not compliant, even if we perhaps
>happen, or claim to be the best/greatest/fastest thing since sliced bread, and blow
>away the '100% Compliant' version. At that point we aren't really Linux but a Linux
>variant that is still opensource, uses the Linux metholdolgy, and albeit a close
>dirivitive.. but still not really Linux..

No distribution is "Linux". That is the name of the kernel. Now it does happen
that I would (personal preference here) have those utilities that are built to
interface directly with the kernel (ifconfig, init, hdparm, ...) to be provided
from the same location as the kernel. That way the dependancies between kernel
and these applications would remain consistant. But.. they arn't. No big deal.
Even these utilities (frequently I understand) come from BSD/netBSD/OpenBSD
(whereever) distributions.

Each distribution appears to be aimed at a specific user base, some larger than
others. These distributions should not be penalized for providing additional
support. After all, that is what they make their money from.

Penalizing distributions for "compliancy" doesn't make sense - Would that also
apply to a specialty hardware vendor that provides a driver? After all, it's not
in the "standard"...

The areas of non-compliancy are usually in specific bug patches, and drivers.
Sometimes even in the compiler used. This IS up to the vendors. They have to
support their customer base, and I have no problem with it. I do believe they
should be documenting the uniqueness better.

As far as I've seen, the distributions accept what are "best practices" from
a variety of places, AT&T System V, BSD, Sun OS 4.x, Sun Solaris 2.x, whereever
something worked, and worked well, it has been adopted. There were/are some
"adjusting" to make it all be relatively seamless; and that is another place
of "compliancy" as well as "if it works cleanly, and well.... then that is
the direction to go".

Linux runs in some systems that are NOT considered a "Unix" environment. It is
still Linux even if it does have custom drivers, and applications.

>Some companies are using 'open-source' monickers as a marketing ploy... As if
>'open-source' means that it is some sort of industry standard.. And although the
>freedom of open source in the development community means great things for all, the
>end consumer wants standards. Maybe it is time that standards, (And accepting patches
>or changes to the kernel while rejecting others IS a standard whether we call it such
>or not) are openly claimed to be such, even if those standards are dictated by Linus
>himself, the community at large by consensus, or a representing body.


>Either that or I see a very real possiblilty of fragmentation of the development of
>Linux products as the corporate needs start to dictate what 'Linux' is..
>Oh, and don't get me wrong, fragmentation will happen as two people differ on what
>they think is best.. Otherwise we wouldn't have so many flavours of Unices out there
>too. Some guys at Berkely might still be dictating their thoughts of what is best..
>and we would all be using it..
>
>Linus?? I wouldn't mind hearing you thoughts on formally declaring a 'standard' on
>kernels..rather than an assumption that it is :>
>
>(Side Note: had one of my sysadmins that needed to install a server with a DAC960 Raid
>controller.. The standard Linux kernel had no support for it so he had a choice.
>Patch it, or use the RedHat version. Do we say that this controller is not supported
>by Linux, but is supported by RedHat Linux? Are we not then saying we have two
>different OS's??)

No. The DAC960 hardware you are using just doesn't happen to be fully supported
by the kernel/raid utilities as provided by vendor X. Since that is a Mylex
board, I would expect it to be available/supported within a few months (weeks?)
of the availability of the hardware. Just because there may be some oddity that
Red Hat has already figured out is no reason to penalize Red Hat - either ask
for the driver separately from Red Hat, or contact the vendor/supplier of the
hardware.... (or the maintainer of the driver...)

--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.206 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site