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