Well all know this really isn't a Red Hat issue as much as a Dell issue. Dell
shouldn't be selling SMP systems without SMP enabled in the Kernel. It's
silly. I doubt I would get that from VA or Penguin. Red Hat has a fine line to
walk though, as they could start to be viewed as the M$ of the Linux community,
by not phrasing statements carefully, and allowing for all the outside interest
to come in (Dell, Intel, etc).
My 2 Cents,
Gavin
[EMAIL PROTECTED] wrote:
> > 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]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
