On Sat, 10 Apr 1999, Doug Ledford wrote:
> I disagree. First, with the 2.2.x kernel sources your talking about
> installing over 50+ MB of kernel source by default. Not only that, but
So? The smallest hard disk I can buy now holds 3.2 GB at $110. For
$150 it goes up to 6.4 GB. For $170 it goes up to over 8 GB. And this
is right now today -- by next month or the month after that the 3.2's
will utterly disappear and the 6.4's will start to disappear. Who's
going to worry about 50 MB (or even 100)? On my home system running RH
5.2, I've installed (almost) EVERY non-source package on both the
distribution CD set, the freebie accompanying CD, the RH Power Tools CD
(including Gnome in its entirety), both WordPerfect and the complete
StarOffice Suite (all 200 MB or so of it), a lot of stuff from CPAN (it
would be nice if RH included the Tk package in functional form in their
distribution perl, BTW -- I couldn't get it to work even from RPM's) and
I have source for both 2.0.36 and 2.2.4 and a whole bunch of other
things (including perl and its Tk module:-). Then there is my personal
work stuff. As of the moment, the meter reads 2 GB used out of 3.8 on
my dual boot system (the rest of the 6.4 GB is a whole Windows
installation that never gets booted at all anymore). Heck, I don't even
bother cleaning out the kernel source directory after a build -- I'm
eating 70 MB in /usr/src/linux for 2.2.4 and am too lazy to clean up.
The point being that just one GB is rather large, that NOBODY has less
than 1 GB to install into anymore and that vanilla RH 5.2 occupies less
than 1/2 a GB even WITH kernel sources.
> we are striving to provide a system where the average user should never
> need to compile their own kernel. In that case they don't need/want
<Chuckle> OK will anybody who has never needed to compile their own
kernel please raise their hands? Hmmmm, 1, 2, 3...not a whole lot of
folks out there....
Now I do recognize that this is linux SMP, but I'll wager that if I
asked this question on DULUG (the Duke Linux Users' Group) that no more
than one in four has NOT had to recompile a kernel to get something to
work on their system. So I'm not sure you'll find a lot of those
"average users" and (given my miserable experiences on WinX systems
where I have no choice) I'm not sure that I think that being able to
compile a kernel is a Bad Thing. Time might be better spent making it
EASY to recompile and reinstall a new kernel or to compile and install a
new driver module under one's existing kernel.
These days there isn't really any reason that the entire kernel
construction process shouldn't be front ended -- I keep waiting for some
clever person to add the buttons that say "Make new vmlinux", "Make new
vmlinuz", Make all modules", and "Install All" (possibly within an
install-configure main window) to the tk scripts that currently appear
when one runs "make xconfig" in the kernel sources. Why insist on
making things unnecessarily arcane?
Still, a worthy sentiment, if unrealistic in application.
I have to pass onto you my own indirect experiences with Red Hat's
default configurations and support. They are indirect because I provide
my own support and don't bug Red Hat for it. However, a number of
students at Duke, occasionally on my recommendation, have tried to
install RH 5.2 on their personal systems. Not unsurprisingly, almost
every one of them has had at least one piece of hardware in their system
that didn't work out of the box -- a sound card, a video card, a network
card -- something. In not one case has one of these students gotten
adequate help from RH, although DULUG is pretty good at identifying and
repairing the problem. The solution, of course, is almost invariably to
rebuild a kernel with the appropriate driver in place or upgrade XF86 or
to hand edit a config file or the like, but the RH support lines aren't
up to walking a novice user through a kernel rebuild. One of my
students in particular gave up on his sound card and just >>bought<< the
driver module to be done with it, in spite of the fact that the card was
supposedly supported by the kernel. This was after I gave him a network
card just so he could at least get his system onto the network -- his
NE2K clone with PnP was totally ignored by the RH kernel and I couldn't
walk him through the hand configuration of the card by phone. He is now
rather cynical about RH's and by extension linux's ability to install on
what is, after all, a fairly vanilla PC and is totally down on RH's
support.
This isn't intended to "dis" RH. It is just to point out that RH's
ability to provide meaningful hardware support is being crippled by
their NOT installing kernel sources in something like a
ready-to-build-and-install configuration. Where RH works (because the
hardware is Just Right), RH support is never called. Where it doesn't,
RH support never succeeds in resolving the problem because it cannot
without a kernel rebuild, which requires the source and some guidance,
and RH's support seems limited to "install upgrade RPM X" or "sorry".
With way too much of the latter.
This matters to me because one of my hats is 1/3 ownership of a small
software/service business that runs strictly on linux. We're converting
to RH in the office, but it isn't particularly flawless and we're far
from satisfied -- we have to work pretty hard to get everything
functioning to our satisfaction, and it involves really learning most of
the details RH wants to hide from us via its linuxconf and tksysv GUIs.
What one learns is that a lot of the stuff being done is surprisingly
ugly and difficult to deconvolve from the startup scripts -- hence the
difficulty of obtaining meaningful support from the RH support lines.
If/when something doesn't work, not even RH's support team can help you
because in all probability the support people have no idea what is
really happening in the scripts where it is breaking. So it's "RPM or
bust".
> those sources installed by default. They are always available through
> the kernel-source-.... rpm though, so it isn't like we aren't providing
> them. That includes all patches pre-applied and the .config file
> intact, just like you are asking for.
Really? And novice users know where it is and how to go about
installing it? And RH's support team tells users to go and install it
and, when appropriate, walks them through a kernel rebuild? The point
is very clear. The user in question who bought the Dell systems with RH
preinstalled should have been able to go to RH support and say: "My
second-nth CPU's don't work". RH support should have been able to tell
them "do x, y and z and voila, they will". Why should a user who buys
RH via Dell or anybody else have to go to the linux-smp list to learn
how to install an SMP kernel? It is a trivial FAQ (once you have the
preconfigured sources, of course) and can be encapsulated in a script or
even a GUI script. Given that ALL Red Hat is really selling is
encapsulation and support of source that is developed and debugged and
contributed elsewhere, I would hope that they wouldn't balk at
encapsulating and supporting anything one of their customers wants or
needs.
A question: It seems to me not unreasonable that a support person
trying to support ANY of the linux distributions would join at the very
least linux-kernel, linux-smp, and a selection of networking and scsi
device lists. This would put the person in the way of a constant stream
of both information to learn from and exposure to feedback on the
product they were supporting. A properly organized support team might
even deliberately spread out such list membership to ensure that all
major devices have one or more of their support persons belonging. I
know that one can manage to do this and provide quite a lot of support
to people because I do both the one and the other personally. Indeed, I
cannot imagine being able to do the one (provide support) without the
other (list participation).
So, aside from yourself (an SMP-aware device driver person, not really a
direct support person) how many Red Hat direct support persons belong to
this list? I'm talking about the folks who actually provide answers to
RH customers when somebody seeks it. A show of hands again?
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[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]
