From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RRkfp-0007v6-IN for garchives@archives.gentoo.org; Sat, 19 Nov 2011 13:09:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C8D3D21C071; Sat, 19 Nov 2011 13:09:28 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id CE8D421C040 for ; Sat, 19 Nov 2011 13:08:41 +0000 (UTC) Received: from mail-bw0-f53.google.com ([209.85.214.53]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1RRkex-000XnG-EH for gentoo-user@lists.gentoo.org; Sat, 19 Nov 2011 20:08:43 +0700 Received: by bkaq10 with SMTP id q10so5556460bka.40 for ; Sat, 19 Nov 2011 05:08:36 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.16.67 with SMTP id n3mr7700153bka.6.1321708116709; Sat, 19 Nov 2011 05:08:36 -0800 (PST) Received: by 10.223.74.16 with HTTP; Sat, 19 Nov 2011 05:08:36 -0800 (PST) Received: by 10.223.74.16 with HTTP; Sat, 19 Nov 2011 05:08:36 -0800 (PST) In-Reply-To: References: <201111170654.17684.michaelkintzios@gmail.com> <201111181742.51438.michaelkintzios@gmail.com> <201111191129.32115.michaelkintzios@gmail.com> Date: Sat, 19 Nov 2011 20:08:36 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Out of memory error From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=00032555f6eacb131c04b21626a7 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: c3eb1f33-79f7-4804-850a-be345c05617e X-Archives-Hash: c207e6804b3aa2139be7aec55595e7f9 --00032555f6eacb131c04b21626a7 Content-Type: text/plain; charset=UTF-8 On Nov 19, 2011 7:28 PM, "Michael Mol" wrote: ----- >8 snip > And, finally, yeah..that isn't just "not much", that's a terribly small amount of memory. Assuming you've kept the software current, some of your applications have certainly not been maintained with 600MB of system memory in mind. > Indeed. With less than 800MB, gcc fails to upgrade. Always. For some RAM-constrained systems (e.g. the VMs in my company's cloud), I even have to do an "out-of-the-box" upgrade, i.e., upgrade an identical copy on the physical data center, grab the binpkg tarball, and upload the tarball to the cloud. Rgds, --00032555f6eacb131c04b21626a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 19, 2011 7:28 PM, "Michael Mol" <mikemol@gmail.com> wrote:

----- >8 snip

> And, finally, yeah..that isn't just "not much", that&= #39;s a terribly small amount of memory. Assuming you've kept the softw= are current, some of your applications have certainly not been maintained w= ith 600MB of system memory in mind.
> =C2=A0

Indeed. With less than 800MB, gcc fails to upgrade. Always. For some RAM= -constrained systems (e.g. the VMs in my company's cloud), I even have = to do an "out-of-the-box" upgrade, i.e., upgrade an identical cop= y on the physical data center, grab the binpkg tarball, and upload the tarb= all to the cloud.

Rgds,

--00032555f6eacb131c04b21626a7--