Mono required by ubuntu-desktop

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Scott James Remnant wrote:
> On Tue, 2006-08-01 at 23:09 +0100, Jamie McCracken wrote:
> 
>> Im not saying we should not include mono apps like tomboy by default but 
>> all I ask is please keep the default sane for a 256MB machine. If mono 
>> apps can run comfortably on such a system then great!
>>
>> (A lot of people actually use Linux cause its memory demands are lower 
>> than XP - it would be crazy to change this IMO. Im also sure thin 
>> clients and third world systems would benefit from keeping the default lean)
>>
> The argument here appears to be caused by a confusion of user stories...
> 
> Users who own reasonable digital cameras, take a large amount of
> photographs with them, want to sort, catalogue, modify and tweak those
> files, etc. are also likely to have reasonably powerful machines.
> 
> Digital photo management takes a lot of resources; the owner of a Canon
> Eos Digital SLR and a complete lens set is not likely to then try and
> fiddle with those on a 486 with 32MB of RAM.
> 

A what lol "Digital photo management takes a lot of resources"

1.  mmap() the photos in when displaying them.  They're loaded when in
use, unloaded when memory is under pressure.

2.  Generate low-resolution thumbnails and keep them in a hybrid LRU/MLU
list:  cache the most likely to be used used to a certain level, and let
least recently used (and timed death) be used to fill up the rest of the
available cache.

3.  Cache thumbnails as files somewhere, and then mmap() them in.

4.  When editing, keep the image you're editing in memory; then flush it
when it's closed.

It'll take some CPU usage; but you can balance thumbnail cache and
directory cache efficiently.  Digital photo management of 1,000,000
photos should be directory cache (i.e. a path to each file) + thumbnails
for maybe 300 photos (at 160x120 24-bit, 56.25kib each, 16.5MiB).  With
the directory cache here you may see 100 bytes per existing photo, so
let's say 100 megs here.  I find this acceptable:

bluefox at icebox:/tmp/x/flac-1.1.2$ find /home -type f | wc -l
96881

Considering this, I'd have some 9 megs used for such a cache if every
file in my /home was an image file; and then 16 for the cached
thumbnails; and then let's say 10 more megs for other stuff.  35 megs.
Also note that the directory cache can be slimmed down without
sacrificing performance (indeed, this would INCREASE lookup speed) using
Patricia Tries.  We could likely on average cut this down to maybe 32
bytes (approximately the length of the file name; the directory paths
would be emitted exactly once), so about 3 megs => 29 megs.

(1000000 images -> 30 megs -> 56 megs total; also note Patricia Tries
should eventually start to scale better because file names like
"Foobar1.jpg" "Foobar2.jpg" would diverge at "Foobar" -> {"1.jpg","2.jpg"})

This argument doesn't address the fact that mmap()'d files get pulled
into memory when read; but that's ok, because they'll go out likely just
as fast.  Plus when the system is under memory pressure they'll be
forced out (without swapping; we save the overhead of writing back to
disk this way, the data just has to be read next time it's accessed),
and it's likely we only read the data once or twice anyway, we're
talking about super-transient data.

Point is, it should be feasible to not take "a lot of resources."
Moderate CPU, moderate memory, and low disk usage, and you could see
something that feels slim and reacts quickly.  Don't create the illusion
that "it's big because it has to be big."

> The simple metric here too is hard drive space; a large photo collection
> takes a lot of disk space.  An older computer isn't going to have the
> disk space to hold the collection, let along the grunt to manage it.

True; however some people have huge hard drives put in their moderate
systems.

> 
> F-Spot is an application for this group of users; it allows arbitrarily
> massive photo collections to be browsed, tagged, filtered, modified,
> etc.  It's an application for those with reasonable cameras and an
> equivalently reasonable computer to store them on.
> 
> 

[...]

> 
> 	(aside, I did a user test with this to ensure I wasn't
> 	 talking bollocks ... I asked a friend to show me how he managed
> 	 the photos on his computer.
> 
> 	 He had them all in one directory and viewed them by
> 	 highlighting them, clicking the File menu and then selecting
> 	 "Open with Image Viewer".  He used the Next and Previous
> 	 buttons to move between them, and also used eog's slideshow
> 	 feature.
> 

Oh, can you tell me how long the file names were on average?  I'm
curious as to how close my predicted directory cache numbers were in the
above theoretical argument :)

> 	 This user didn't know what GThumb was, and when showed it,
> 	 thought it was more complicated than what he did and didn't do
> 	 anything else he needed.)
> 
> 

[...]

> Scott
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBROY0Rws1xW0HCTEFAQL+kw//XnL7h0Kl+z5Web4r1IEJE9NEjVGKVSve
fkip5Hlfo3XBmm5XRsfSdfkuihu2R2GT3zMhiYYAVosCZ5gUrGiB9a48tkdv9PwA
U+vNLbzhdIdpDhJU7msqmVvzRNKlZoZDmA7ucR3fNMkoTcr/lQr5QBUZYsgEAAT2
PY71peYqC5Np/nVSOlex08L79tdA5MbgCVA+i3TnZ+oA+pmw93gYVCEvrkueSmfK
C15Gb1ybcTViEQOcge+ikHjOpHC39VWqRgIfCptx8+EFHC21IYX3ebBaAgalscE9
vDt5LPjVnZDDtFoxigk5OLm0GEgE7bOWRRs7L6VCg/vAR8yUxSJHpCBOme1/7FnO
aKVpNd8xWwIF6ac/fvohorQyTiUXFt2g7tQpIAdrWSMjibEqoTxr4haG5glb0zfM
B2sjPbafCZC8SLs4JmrJMKNPccyMHSLYPlZZYGbse+urqejtkdFcYjUHxqc31nZ9
KbhLNBVAmSnrlQyzlRrcljmvff7pAUsZuEb2r2CR3UwNJlxGX2X98wZ0vJrwQ8ed
S6wUzwnYzBsMt4KGGoQ9ppf1Cli/xcVSLVie+lNRmhvaNEezKLiwO8oKtK84fJfS
5yOCfS9nG4ttjFREhp29xS1Of1JgvT+128p0w6PSxEnQ131wnc6zI9RQrR6Vriz9
h3tVRxFYVd4=
=CPqM
-----END PGP SIGNATURE-----