Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Apr 1999 20:35:55 -0400 (EDT)
From:      Thomas David Rivers <rivers@dignus.com>
To:        darrylo@sr.hp.com, hackers@FreeBSD.ORG
Subject:   Re: Adding desktop support (please don't)
Message-ID:  <199904290035.UAA18606@lakes.dignus.com>
In-Reply-To: <199904290014.RAA24394@mina.sr.hp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Darryl Okahata writes:
> 
> Chuck Robey <chuckr@picnic.mat.net> wrote:
> 
> > Agreed, but I think you're missing the point.  It's not the HAVING of a
> > resource fork that's the key, any programmer working in isolation can
> > have that.  It's the having a standard place to stick those resource
> > forks, and a standard method to get and find them, that's the key thing.
> 
>      Other key points:
> 
  ...
> 
> * 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.

 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.  

 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...

 But, this would have to be born out in practice.  

 My point is - it easy to cause just about any mechanism to consume
 more disk space.  It depends on how it is applied.  

 So, if you're going to associate icons with executables; it's
 probably quite individualistic which way would consume less disk space.

	- Dave Rivers -



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?199904290035.UAA18606>