[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120805164652.GJ544@brightrain.aerifal.cx>
Date: Sun, 5 Aug 2012 12:46:52 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl 0.9.3 released
On Mon, Aug 06, 2012 at 12:31:12AM +0800, orc wrote:
> On Sun, 5 Aug 2012 01:22:20 -0400
> Rich Felker <dalias@...ifal.cx> wrote:
>
> > If I were going to switch to x86_64 cpu, which I will probably do in
> > the next few years, x32 would certainly be appealing. Not decided for
> > sure, but it seems very nice to get all the important benefits of a
> > 64-bit cpu with none of the bloat.
>
> Somewhat bloated, but not so much. Often I see only that massive apps
> like web browsers eat much of RAM usually. 2G usually enough for me to
> run 3-4 qemu-kvm's and bloated Firefox 12 (eats about 700M usually,
> critical was 1G and 100M swap, 1 month of it's uptime). Now I use 4G
> (additional 2G is for tmpfs. I like to store large blobs in /tmp often).
> I use x86_64 for 3 years without any problems. If Firefox (or any
> application of same class, chromium probably) will continue to grow,
> then five or seven years will be enough to make x32 be obsoleted
> (compared with ff3, it's maximum memusage was 300M, and for 3.6 it was
> 400M).
Assuming the market is shifting to battery-powered mobile devices
possibly intended to run for days or even weeks without charging, I
think we're going to start seeing some more efficient apps. I don't
doubt the old behemoths will still be around for a while, but musl is
developed with the assumption/intention that efficiency is going to be
one of the important design criteria for future software. If we were
happy with the level of bloat you're describing above, I think lots of
people in this community would just forget about musl and use glibc...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
