> Hmmmm, it might be worth noting that linux has never worked on
> "everything" and probably never will -- the hardware side moves, the
> software side moves, everything is dynamic and there are always bugs and
> broken things. So your observation that there are occasional problems
> with 2.0.36 (or any other revision) SMP isn't really an adequate excuse
> for not supporting it even on a "at your own risk" basis with RPM's.
> After all, 2.0.36 UP has occasional problems on at least some hardware
> but it doesn't stop RH from selling Linux with 2.0.36 UP, and 2.0.x SMP
> has run on "most" hardware combos for years now. I find the conservative
> turn RH is taking to be a bit disturbing.
First, there's a huge difference, by percentage, of the amount of UP boxes
that don't work vs the amount of SMP boxes that don't work.
Second, this isn't a "RH" conservative turn at all. RH has *never* provided
or supported an SMP kernel, EVER. There is no turn. This is the way it
always has been. So, this issue lies with whether Dell wants to go out on
a limb and do something custom.
> Still, corporate policy is corporate policy, so let's accept it for the
> moment. The real question, Doug, is why doesn't RH provide "make
> install"-ready kernel sources in /usr/src/linux, installed by default,
> in the 5.2 installation? To quote from the GPL:
We do provide all sources, but we do *not* install them all by default.
That would be dumb. We've never done that and we likely never will.
*Most* people don't need to recompile their kernel and thus don't need
the kernel sources. But, there is a kernel-source binary RPM (as Doug
has ALREADY pointed out) that does include 'make install' ready kernel
source.
> For example, if you distribute copies of such a program, whether
> gratis or for a fee, you must give the recipients all the rights that
> you have. You must make sure that they, too, receive or can get the
> source code. And you must show them these terms so they know their
> rights.
>
> Now, you can argue that anybody who wants can get linux source from the
> net, but not everybody has net access and many who do have 56K or slower
> access. One of the major reasons for buying a distribution CD,
> actually. Downloading kernel sources at 56K is painful to say the
> least. It is also not clear how RH (or anybody else) can properly "show
> them these terms so they know their rights" any more simply than by just
> providing the source where it belong.
We do. It's on the SRPM CD *and* in the set of binary RPMs. If you
simply mirror the binary install tree, you DO get the kernel-source RPM.
> RH is complying with the letter, but not with the spirit, of the GPL and
> linux itself by not providing the kernel sources (the sine qua non of
> the package, of course) of all the sources possible, with each
> distribution, whether or not a user knows enough or has the means to be
> able to go find them or retrieve them by other means.
You're just plain wrong. We do include those sources and always have.
We used to install them by default, but stopped I believe at the release
of the 2.0 kernel because the kernel sources are 25M and most people
just didn't need them. If we chose to do that then *you* would be
happy but we'd have tons of whiners on the redhat-list claiming we
were "bloated" or some such nonsense.
> Of course, the main PRACTICAL reason to provide the sources in EXACTLY
> the form used to build and install the RH kernel is that, given the
> .config file and the mods to the Makefile required to make it install
> according to the RH prescription (make all the modules, install in
> /boot, create various symlinks and so forth) one could, if one wished,
> go to the kernel source directory, edit the Makefile to uncomment the
> SMP = 1 line, and type "make install". It's not just novices that would
> appreciate this -- I wouldn't mind it myself. And of course it would
> make supporting Dell's entire line of SMP servers straightforward, since
> their hardware is known to work fine with the stock 2.0.36 kernel.
I've done exactly the above in the past.
> Isn't RH taking a terrible risk by NOT doing this that both Dell and
> innocent users who buy high end Dell 2300 and 6300 systems with the not
> unreasonable expectation of being able to run a supported SMP linux on
> the systems will get irritated enough to bag linux altogether and RH in
> particular? You've already heard from at least ONE user who bought from
> Dell with precisely this expectation and was astounded to learn that
> after all the media hooraw over RH linux on Dell servers, only one
> processor worked of his many and neither Dell nor RH was prepared to
> help him get the rest going!
You're arguing too many issues here. The question is whether or not
2.0 SMP is supportable or not. We don't really think it is, especially
given how close we are to 2.2 SMP shipping.
> I know for a fact that Dell can manage an SMP NT install on those
> particular beasts...however poor it may be.
So?
--Donnie
--
Donnie Barnes http://www.redhat.com/~djb [EMAIL PROTECTED] "Bah."
Challenge Diversity. Ignore People. Live Life. Use Linux. 879. V.
The more you cry, the less you'll pee.
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
