[wplug] I'm a Linux whimp (need kernel help)

[Vanco, Don]

>-----Original Message-----
>From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
>[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
>Behalf Of Chester R. Hosey
>Sent: Monday, August 15, 2005 11:26 AM
>To: General user list
>Subject: RE: [wplug] I'm a Linux whimp (need kernel help)
>
>
>On Mon, 2005-08-15 at 11:02 -0400, Vanco, Don wrote:
>> >-----Original Message-----
>> >From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
>> >[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
>> >Behalf Of Chester R. Hosey
>> >I get the impression that Red Hat's position is that you 
>shouldn't be
>> >using a kernel other than theirs anyways. You should install their
>> >package and be happy about it.
>> 	Not as much Red Hat as the ISVs (although arguably no one tests
>> an Enterprise-designed kernel like RH).  Case in point, Oracle checks
>> for kernel checksum when requesting support in some cases.  
>> 	If you can't grasp the logic behind this type of mandated
>> package use there's likely little point in you running RHEL.
>
>Whoa, there. I didn't say that I don't understand the preference for a
>stable, known base upon which ISVs could base their tests -- I did say
>(or at least I tried to imply) that it seems that Red Hat doesn't seem
>to make it a priority to make kernel customization easier on users.
>
>You seem to be leaping to conclusions that simply aren't true. It's
>possible to provide a sensible set of default kernels (for example,
>single-proc vs. SMP) for ISVs while making it easy for those who don't
>mind an unsupported kernel to do things in a way that has 
>minimal impact
>on the remainder of the system. Saying that it's possible to 
>be friendly
>to DIYers does not lead to the conclusion that having a known kernel is
>pointless -- it merely recognizes that not everyone has the same needs.
>
>I invite you to find a single place where I have specifically spoken
>poorly of Red Hat's intent to provide a base for ISV applications. Use
>Google if you wish.

"You" as in "You, the general user".  No personal point meant here.

As far as Red Hat & making kernel customization easier, the entire point
of their relatively universal kernel was to (at least in part) reduce
help desk calls by providing a somewhat universally functional kernel.
Over 50% of calls they got (at one point circa RH9) was stupid user
error in building a custom kernel.

Further - why does recompiling a kernel need to be user friendly?  It's
a complex system whose components potentially have a high degree of
interdependence, and frankly if you've little idea what you're doing
you're better off with "one size fits all".  (again, the "you"s here are
intended as universal)


>> > I agree with your comments regarding
>> >Red Hat bloatware -- rhnsd takes a whopping 6 megabytes of 
>RAM and as
>> >far as I can tell all it does it periodically execute 
>rhn_check (heaven
>> >forbid it include some form of useful failure logging).
>> 	If this is true there is something decidedly wrong with your
>> box.  On a functional system it's barely a blip on the radar.  Once
>> again, if you can't understand / appreciate what the RHN 
>daemon is all
>> aboot you likely don't need to be running RHEL.  Also note - 
>it's not a
>> required package - just pull it.
>
>Upon further review, it does look like the resident size is 
>under a meg.
>That I misinterpreted, and I will rescind my statement. However, where
>did I say that I can't understand or appreciate the purpose of rhnsd?
1) in the fact that you state that as far as you can tell all it does is
periodically run rhn_check.  It's a daemon - it listens, it waits for
connection, it enables lots via RHN
2) in your statement that it doesn't offer any kind of useful logging on
failure.  Try configuring a machine incorrectly and running up2date,
then look at the contents of /var/log/up2date  
Here's a quick example:

 up2date Error communicating with server. The message was:

Error Message:
    Your account does not have access to any channels matching
(release='4', arch='i686-redhat-linux')
If you have a registration number, please register with it first at
http://www.redhat.com/apps/activate/ and then try again.
Error Class Code: 19
Error Class Info: Architecture and OS version combination is not
supported.
Explanation:
     An error has occurred while processing your request. If this
problem
     persists please enter a bug report at bugzilla.redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.


....dunno how much else they could include before it becomes "useful
information"......


>
>And if I "don't need to be running RHEL" if I "can't understand /
>appreciate what the RHN daemon is all aboot", then why would I 
>bother to "just pull it" but continue using RHEL?
	OK - since when is rhnsd a requirement of running RHEL? (HINT:
it's not)  There are many ways to update from and/or utilize RHN that
don't require the daemon.

>I'll admit when I'm wrong. It happens often enough that I don't
>understand your desire to make claims about my understanding 
>or position that simply aren't true.
	Again, no direct implications meant.  At least part of this
(kernel config & bloat) is based in philosophy anyway, so there's really
no right or wrong....




	And if you care to look at my posts strictly on this forum, the
only time I come out of the woodwork is when folks start to misquote
about RH or we hit the 80th OT message on "Pittsburgh DSL".  
	Why does everyone take my emails as hostile?  It's no wonder I
never post here anymore......



>-----Original Message-----
>From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
>[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
>Behalf Of Poyner, Brandon
>Sent: Monday, August 15, 2005 11:52 AM
>To: General user list
>Subject: RE: [wplug] I'm a Linux whimp (need kernel help)
>

>I have seen userland Linux in general becoming far too bloated without
>adding any real new features.  The newest libraries are sacrificing
>memory/storage for speed.  Even very simple things like /usr/bin/yes
>have increased nearly 50% since RHEL 8.0.  Don't get me started on how
>little disk space you could install earlier versions on.

	160GB drives can be had at CompUSA right now for $40 - and it's
been years since even a 10GB drive was considered "big", so I won't even
engage on disk usage as bloat as its pointless to argue with those that
long for the days of the 300GB install (which, as I am sure you know,
can still easily be realized with the correct tools as the install
methodology).  Amazingly those folks don't also miss 8-bit color or
monaural audio.  I will say that much "disk bloat" has come from package
maturation, the subsequent splitting (into new packages) of libraries
and / or features based on that growth, and the exponential dependency
issues said splits might present.  The overall simplest solution is to
install more packages.

	As far as running services "bloat" goes, I do agree that some
current releases (particularly those that call themselves "Enterprise
Level") have an inordinate number of running processes on a fresh "click
here to install" load - but then those distros are aimed at those that
really know how to use them.  If one wants a lean-n-mean distro out of
the shoot, one does not load RHEL, or one knows how to tune it... or
better yet install it in the first place (see also xCAT and kickstart)

	As a hardware & services vendor I'm glad to see this bloat -
it's what enables us to add value to a platform offering that arguably
anyone can buy anywhere.

Don