> > 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
[ Disk space snip-o-rama ]
Fine, but by your logic everyone should just pick the "Everything" option
during the install. Then they *will* get the sources installed and
ready to build.
I don't care much for that argument, either. The simple matter is that
not everyone is blessed with a brand spanking new machine. Plenty of
folks are installing SPARC Linux on legacy boxes that only have 200M
hard disks in them. Remember those? Any idea how many of those are
still in existence? Even that doesn't matter. The simple fact is that
if we start forcing tens and hundreds of megs on people, we're going to
get compared to MS all day long.
I have three machines here at home. Only one has more than 1G of drive
space.
> > 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....
You're far from the "normal" user. I'd go so far as to say that *most*
of the systems I install these days don't require a kernel compile. If
it does, it's a bug, AFAIC.
> 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
That's still not a great sample given how technical the users are,
though. My bet is that many of them recompiled for a variety of
other reasons, too.
> 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.
This certainly wouldn't be a Bad Thing(tm), but it is still my opinion
that if you have "supported hardware" (RH's definition, not the kernel's)
and it doesn't work when installed via RH media, then it's a bug. How
many of these have you seen and not reported? We can't fix it if it
isn't reported.
> 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?
I didn't realize they were unnecessarily arcane. The process is
documented in HOWTOs, books, and on lists. The point that really
matters, AFAIC, is that I think far fewer folks really need to do
this *and* can't easily figure it out than you think. All those
folks ask you about it because you're obviously a very good Linux
resource.
If not having those buttons bothers you *that* much, go add them
to make xconfig and make menuconfig. Wouldn't be hard. I'd bet
Linus will take the patches.
> 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
That means they have *unsupported* hardware by our definition. Yes,
our definition is more narrow than the kernel. But we always try to
ask folks like Alan to tell us which drivers are in good enough shape
to support. We then support those. The others have to wait for one
reason or another.
> 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.
Sounds like there was a breakdown there if RH support couldn't get the
NE2K working. My apologies for that.
> 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.
Well, we may indeed have some problems to work out, but I still don't
think many of the problems that we say "sorry" to are necessarily
fixable by simply rebuilding a kernel.
I would point out, however, that the manual does cover both installing
RPMs as well as documents *exactly* how to build your own kernel.
> 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".
I don't understand the connection to "support" and your "configuration"
problems. "RH support" is only for installation. This doesn't even
*cover* configuration, so we certainly aren't of any help via support
in this arena.
As for configuration and the way things work, most of what we do is
to add features, not convolution to make an interface easier to write.
In fact, before we even added linuxconf we did a great deal of work to
remove linuxconf's internal databases and make it use the "normal"
config file formats that we had always used. This was done *directly*
to enable sysadmins to be able to use a text editor to make changes and
have those preserved.
I would certainly concede, however, that we do need more documentation
on how things are configured underneath the hood.
> > 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
If they read the manual they do!
> and, when appropriate, walks them through a kernel rebuild? The point
No, support won't walk them through a kernel compile. If they need a
kernel compile then it's a bug. Show me a clear case where this should
have been done and we'll get it fixed.
> 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
It would certainly be nice if we had a canned response for that, but in
reality this isn't a supported issue. You simply disagree with us that
2.0 SMP is "supportable". What support tells users has no bearing on
this that I can see.
> 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
I would have to argue that those aren't the only things we're selling.
I'm fairly certain we contribute, develop, and debug LOTS of code
ourselves as well. We also sell a manual and a CD set. It's completely
irrelevant, though.
> encapsulating and supporting anything one of their customers wants or
> needs.
We support everything we feel is supportable. We will not ever support
everything every user wants that might happen to exist in some form in
the kernel.
> 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?
Robert, you're making it *very* difficult to have a civil discussion of
these issues with your snide remarks. Very.
The answer to the question, however, is that we *do* have several folks
in our support department who are involved in the exact lists you mention.
Most of those are level 2 and above support techs. My guess would be that
we have about 25% of our support staff doing that. The rest are primarily
level 1 support techs who filter out the repeat and well known problems.
We also provide those lists internally to folks via a mailtonews gateway
to make it easier on them. I do *not* agree that every one of them should
be reading all of that stuff every day. So much of it is completely
irrelevant to their job that most of it is a waste of time.
To get back to the subject at hand, I think the crux of the debate is that
you think we should support 2.0 SMP and we think we shouldn't. This is
the *only* topic relevant to this list. Please, for the sake of others,
if you want to continue to debate RH support themselves, mail me off the
list. Provide some concrete examples and I can work with those folks to
make it better. If you want to talk about why SMP isn't supportable,
that *is* a topic for this list.
--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]
