From owner-freebsd-hackers Wed Apr 28 17:43:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 7FBDF14F42 for ; Wed, 28 Apr 1999 17:43:33 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id UAA19100; Wed, 28 Apr 1999 20:37:10 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id UAA33217; Wed, 28 Apr 1999 20:35:55 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id UAA18606; Wed, 28 Apr 1999 20:35:55 -0400 (EDT) Date: Wed, 28 Apr 1999 20:35:55 -0400 (EDT) From: Thomas David Rivers Message-Id: <199904290035.UAA18606@lakes.dignus.com> To: darrylo@sr.hp.com, hackers@FreeBSD.ORG Subject: Re: Adding desktop support (please don't) In-Reply-To: <199904290014.RAA24394@mina.sr.hp.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Darryl Okahata writes: > > Chuck Robey 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