Mono required by ubuntu-desktop

[Scott James Remnant]

On Wed, 2006-08-02 at 18:27 -0700, Dan Kegel wrote:

> On 8/2/06, Scott James Remnant <scott at ubuntu.com> wrote:
> > > So let's pick an attainable goal: no net increase in memory requirements
> > > from the status quo (unless the user starts some new huge app on purpose).
> > >
> > I'm sorry, but that's crap.  It's a stupid goal.  There are perfectly
> > legitimate reasons to increase memory requirements.
> >
> > Standing still while everything else improves around you is equivalent
> > to going backwards.  We want to be at the cutting edge of computing, not
> > the dark ages.
> 
> Gee, we seem to be miscommunicating.  All I wanted to do was
> to help make sure Ubuntu performed well on computers purchased at
> large retailers like Fry's.  That's not unreasonable, is it?
> 
Then we're both on the same page!  You appeared to be advocating a
freeze on memory usage, at all costs ("thou shalt not malloc another
byte"), where as I firmly believe that we should set realistic targets
of minimum requirements for each release based on the available
hardware.

I guess Fry's is equivalent to PC World, a typical retail park computer
store here; the kind of computers you can pick up there are exactly the
target I'm thinking about.

Ubuntu should not exceed the hardware that people are able to own at the
time of release, that's just common sense!


I don't think it's possible to limit it more than that, simply because
of the changing face of computing ... the simplest example is one of the
the discussion topics in this thread, photo manipulation.

A few years ago, most "average" people didn't own digital cameras, and
certainly didn't do much photo manipulation on their computers.  Now
most people own multi-mega-pixel digital cameras (even most mobile
phones have them now), regularly download them onto computers and edit
them.  That takes large amounts of RAM and disk space, simply because it
takes a lot of RAM to hold a 1600x1200x24 image and modify it.

Other examples of "new things" people do with their computers include
playing DVDs, video editing (from digital camcorders), music editing
(several friends have been making "mix podcasts"), etc.  All of these
things consume more resources than the typical computers of only a few
years ago are really capable of.

These are all things that we need to offer in Ubuntu, so all add to the
"sensible" minimum memory requirement.

> > Depending which cost metric you use, the typical cost of keeping up to
> > date is no more than $20 a month (a new computer every 2 years).  This
> > is not a huge amount of money for the western world, who are the kinds
> > of people who are addicted to upgrades.
> >
> > Obviously the non-western world can't afford this, but then they don't
> > care about having the latest, shiniest, blingfulness, release.  They can
> > run the older releases or other derivatives.
> > And lastly your choice is to use an Ubuntu derivative that is not
> > targeted at "current" hardware, but has had extra effort spent to reduce
> > memory requirements at the cost of features
> 
> "Let the poor run old releases" isn't going to make Ubuntu
> popular in areas that can't afford that update rate.
> 
Which update rate?  In my experience, the poorer and less able the user,
the less likely they are to be running the kinds of applications that
require resources from their hardware that they don't have.

A third-world uni student probably doesn't own a digital camcorder, so
isn't going to be doing much video editing, etc.

> I think the key here is your assumption that reducing memory
> requirements has to come at the cost of features.
> 
Not necessarily, as I said, there are some areas where memory is being
wasted or duplicated needlessly; but the only ones I know of off hand
are the ones that are already in the process of being fixed.

I personally wonder why evolution and firefox need so much RAM...  I
guess they have their reasons, but they're both worth auditing.

> My proposal was not aimed at cutting features.
> All I wanted to do was monitor RAM usage and avoid unneccessary growth.
> If you think that's silly, well, perhaps I'll take my toys and play elsewhere.
> 
No, I don't think that's silly at all -- and indeed, I've advocated it. 

All I think is silly is preventing growth, as that's inevitable.

I do believe that it's important to have a very well defined plan before
embarking on the crusade.  I've seen several people go off to cut
nautilus's memory usage down to "under 64MB" and only to realise,
eventually, that it's actually using less than 4MB and all of that is
accountable and useful.


We both seem to agree on a useful metric for minimum requirements;
namely currently available "entry level" PCs.  So that gives us a
ballpark maximum of 256MB of memory.  We have to use this wisely, and
this needs to be used for:

 * Base operating system (kernel up to, but not including, X)
 * Desktop (X, file manager, panel, applets, etc.)
 * User applications

On an i386, the base operating system uses around 32MB of memory and the
desktop uses a further 80MB of memory ... so we're using about 112MB of
memory before we've got any user applications loaded.  However a large
chunk of this memory is actually the support layer for those
applications, so it's not all bad -- applications cost less to start.

The LiveCD uses a little more simply because it has to store anything
written somewhere, so that's as much as 160MB of memory -- if you
include the installer overhead as well.

The biggest applications use about 48MB to 64MB of memory, and assuming
the user only runs one or two at a time, we fit comfortably within the
256MB of memory that we sensibly set as a minimum requirement.


However this is not something that is going to remain static, simply
because of one thing: hardware.  In order to support more hardware, we
need to have the support daemons or applets in place.  The most typical
example of this is the NetworkManager layer for dealing with wireless
and wired cards on laptops.  Supporting this hardware costs more memory.

Scott
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060803/f93c0eae/attachment-0001.pgp