On Fri, 2006-09-15 at 11:51 -0500, Steve Bergman wrote:
> <snip>
> If I understand correctly, you feel that kernel developers should add
> some rather high level knobs, allowing admins to tell the system what
> kind of system it is.
I did not intend that. I was talking about my view of why things
were/are the way they are and I see (reviewing the 3 posts left in my
sent folder) that there are statements that would make it seem I endorse
that solution. But I do not. I mentioned it as observations, such as
<quote>
If one wants to promote *IX (any flavor) across the widest possible
potential user base, then one must continue to support swap for those
whose $s matter more than latency. But the tuning ability is needed for
those to whom latency is more important.
</quote>
And in subsequent posts I mentioned/responded without expending the
effort to constantly repeat "If one wanted to ... then". For me, it was
just consideration of some (possibly) relevant things that cause folks
to keep reviving the discussions or make the discussions irrelevant.
My real position lay in my original statement to the effect "... why I
tend to discount and ignore" these sort of discussions. From there, I
*think* we were predominately discussing why the threads constantly
reappear on swap vs. no swap... and things that were tangentially
related.
>
> My systems are considered servers. But they are, these days, really
> desktops. They do accounting. It's a server function. But from an
> admin standpoint, the resources are devoted to XDMCP Gnome sessions,
> doing Evolution, Thunderbird, Firefox, xpdf, acroread... and
> Counterpoint Business Accounting and Point of Sale.
I've not kept up with definitions. I would certainly view as a server
any unit that had the majority of its load involved in serving multiple
users with a small (or large, I guess) set of common functions in a
networked environment and a dedicated user doing admin functions or
being the source of only a very small % of load.
>
> Consequently, I feel that I admin desktop systems.
>
> So, does that make a difference? Obviously, 40 individual Linux boxes
> are going to require a different tuning technique than 40 systems
> running via XDMCP.
>
> But if we decide that adding these knobs would be a fantastic idea,
> there is still the question of who is going to do it. I'm not anywhere
> near up to the task.
First the short answer: no one is going to do it. It's counter-
productive.
Other than my "... why I ignore...", my predominate theme was that $$
and business drive this decision making. Unlike days of yore, the costs
are no longer high enough that competent technical input is needed for
management to make an effective business decision about what the
equipment configuration should be. Its 90%+ "off the shelf" with pre-
built boxes and "canned" applications. Not enough power? NP. Spend an
extra $50 and it'll run like a scalded dog. Got that working but that
caused net bog? NP. Get more "switches", do fiber-optics, finer sub-
netting ... There there may be a one-time labor-intensive cost bump.
The undertones of my replies (I hope) and my thinking (for certain) is
that the technical issues that folks like us worry about no longer
matter to anyone *but* us. Science, then technology, then industry and
lastly business (viewed as a system) are always successful in reducing
all complexity (eventually) to "apparent" simplicity. Folks like us are
a temporary annoyance on the road to business nirvana re. technical
issues being a significant influence on cost.
And now that they have "us" doing much of the work for free (FOS),
they've removed a major part of intellectual cost from *their* cost-
basis (which any cognizant being will immediately recognize as a "cost
transfer", not "reduction"). So "knobs" and any additional tunability
would be a step back towards the stone age in their POV. Why? Because
their cost would have to rise due to needed increased expertise (i.e.
increased intellectual cost).
<snip *my* rant: hope the above only *bordered* on ranting>
> -Steve
> <snip sig stuff>
You can see that I should quit this thread. ... Done.
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
