On Sun, 2 Nov 2003, Tzafrir Cohen wrote: > Date: Sun, 2 Nov 2003 19:35:39 +0200 > From: Tzafrir Cohen <[EMAIL PROTECTED]> > Reply-To: Linux on 390 Port <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: RHEL3 requires 256MB to be supported? > > On Fri, Oct 31, 2003 at 03:55:52PM +0800, John Summerfield wrote: > > On Thu, 30 Oct 2003, Post, Mark K wrote: > > > > > Date: Thu, 30 Oct 2003 16:09:34 -0500 > > > From: "Post, Mark K" <[EMAIL PROTECTED]> > > > Reply-To: Linux on 390 Port <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: Re: RHEL3 requires 256MB to be supported? > > > > > > I don't think any such assumptions were made. Certainly not by me, which is > > > why I said "or as little virtual storage." > > > > > > I have RHEL3 Beta 2 running on a dual Intel box. Here's the output from > > > "free:" > > > total used free shared buffers cached > > > Mem: 2190804 2011520 179284 0 168568 1491824 > > > -/+ buffers/cache: 351128 1839676 > > > Swap: 2044072 0 2044072 > > > > > > As you can see, out of 2GB of real storage, 1.4GB is being used for cache, > > > and 0.16GB for buffers, and no swap at all. I'm betting that if I booted > > > this system with less than 256MB that it would run just fine for most things > > > I would be doing. > > > > > > My point was that since Red Hat requires 256MB to be supported, you need to > > > be able to reproduce any sort of problem while running in that > > > configuration. If the hypothetical performance problem goes away, then > > > there's no problem to report, is there? Whatever you're doing actually > > > requires that amount. If the problem remains, then you fit within Red Hat's > > > requirements for support, and they should investigate the problem. This > > > would apply to any problem, not just the hypothetical I proposed. Red Hat > > > would be within their rights to ask you to reproduce the problem while > > > running in an officially supported configuration. > > > > I ran Taroon in 128 Mbytes on IA32, and it (with the GUI) is truly > > painful. I would nt recommend such a configuration. In practice, with > > new hardware, 256 Mbytes is the minimum I'd reommend - why would you > > stuff arround with memory configurations to yield something between? > > What exactl did you run on it to make it "painful"? > > On what CPU? > > 128MB is certainly more than enough for many common uses (but please > let's not start a "my ___ is smaller than yours" contest) And if the > default installtion of Taroon is slightly bloated: unnecessary fat can > be easily removed.
Pentium II 350 or thereabouts. Red Hat insists on assorted GUI tools for configuring stuff. To my mind, if you're not going to use them, there's not a lot of point to RHL over anything else. Mine was not a default install, but it was based on my standard (kickstart) that worked moderately well on RHL 7.x on similar machines. To use the RH tools, you need GNOME librariies. Dislinking recent GNOME, I install KDE. If I want a GUI on a server, I'm inclined to FVWM which has a much lighter footprint, and is much harder to recofigure. I don't think you want people recofiguring the desktop on servers. Here, we're excluding those servers whose purpose is to run lots of remote desktops on X-Terminals and the like. My problem was not lack of CPU, but lack of RAM. It was hitting the disk very hard indeed, and sendamil was declining incoming mail on account of high loadaverages. > > I find that requirement plain silly. It is probably intended to reduce > support costs or something, assuming older hardware will have less > memory. But then again, it would mean that if you want to put a simple > file/print server and happen to have some leftovers to install it on, > those won't be supported by your "main OS". You'll have to find > alternatives. 'zactly. I can even run a L/390 (woody) desktop in 32 Mbytes under herc. Not a lot of performance, it's true, but it runs -- Cheers John. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb Copyright John Summerfield. Reproduction prohibited.
