Date: Wed, 28 Apr 1999 20:18:39 -0700 From: Darryl Okahata <darrylo@sr.hp.com> To: Thomas David Rivers <rivers@dignus.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding desktop support (please don't) Message-ID: <199904290318.UAA24935@mina.sr.hp.com> In-Reply-To: Your message of "Wed, 28 Apr 1999 20:35:55 EDT." <199904290035.UAA18606@lakes.dignus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thomas David Rivers <rivers@dignus.com> wrote:
> Darryl Okahata writes:
>
> > * Probable less disk space. It sounds as if adding an icon to an
> > executable will only add a few tens of bytes. If you make the icon a
> > separate file (per icon), the disk space requirements skyrocket
> > (what's the default frag size for FFS -- I forget?). Of course, you
> > could have an icon database to get around this, but you make icon
> > maintanance much more difficult. Disk space is also pretty cheap
> > these days but, if people are screaming over a piddly few bytes,
> > they'll scream even louder when you start talking about Kbytes.
>
> I'd have to disagree here...
>
> Consider, hypothetically, 20 executables each with the same icon
> in them... let's say the icon is absurdley small... only 10 bytes
> (and, let's neglect file system/inode blocking.) So, we've consumed
> 20*10 = 200 bytes. Not much you say.
>
> Well - the icon all by itself consumes 10 bytes. We went from
> 10 to 200. Seems quite an increase to me.
Well, not quite. The icon by itself consumes one filesystem
fragment (default 1K). The system allocates space for files in chunks
of disks (one "fragment", if I understand how the FFS works, which I may
not). Your 10 byte file is now occupying an additional 1K. Assuming
executable sizes are randomly distributed, you need, on average, this
many executables with identical icons before an additional fragment is
used:
(<frag_size> - <average_frag_size>) / <number_of_icon_bytes>
or:
(1K - 1K / 2) / 10 --> ~51 executables
[ I *think* this is right -- I may be off by a factor of 2. I was never
very good at statistics. ;-( ]
In other words, icons in executables will almost always occupy less
space, unless you have lots of executables with identical icons, which
is probably not likely. You'll have lots of data files that'll use
identical icons, but data files won't have icons. We're only talking
about executable files.
> Also, clever ways of defining these 20 executables as an equivalence class
> would provide the association of the 20 executables without much
> of a maintenance burden.
Again, with the exception of a few ports/packages (e.g.,
imagemagick, sox, etc.), most executables will (hopefully) have
different icons. The majority of ports/packages have few executables,
and so the case of lots of executables with the same icon is rare.
> And, I would also argue that the 20 executables would need to be an
> equivalence class of some sort - if nothing else they are related
> by the fact that they have icons. At that point, higher-level
> management becomes easier, not more difficult...
If you have lots of executables with the same icon, yes -- but the
usual case is lots of data files (without icons) with the same icon.
I don't know what the answer is.
--
Darryl Okahata
darrylo@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904290318.UAA24935>