From owner-freebsd-hackers Wed Apr 28 20:18:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 4779114C9C for ; Wed, 28 Apr 1999 20:18:51 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id UAA24582; Wed, 28 Apr 1999 20:18:40 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA045705920; Wed, 28 Apr 1999 20:18:40 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id UAA24935; Wed, 28 Apr 1999 20:18:39 -0700 (PDT) Message-Id: <199904290318.UAA24935@mina.sr.hp.com> To: Thomas David Rivers Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding desktop support (please don't) Reply-To: Darryl Okahata In-Reply-To: Your message of "Wed, 28 Apr 1999 20:35:55 EDT." <199904290035.UAA18606@lakes.dignus.com> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Apr 1999 20:18:39 -0700 From: Darryl Okahata Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thomas David Rivers 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: ( - ) / 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