Must UNIX be a memory hog?

Chris Calabrese[mav] cjc at ulysses.homer.nj.att.com
Thu May 11 06:48:33 AEST 1989


In article <159 at zebra.UUCP>, vern at zebra.UUCP (Vernon C. Hoxie) writes:
> [introduction to /etc/TZ and HDB LCK files deleted]
> 
> 	Is there not some other mechanism by which the functionality of
> these sparse files is accomplished but require much less storage space?
> 
> [...]
> 
> 	My basic question is: Is this good programming form?  Should
> not these processes been implemented with something of the nature
> of 'semaphores' or 'signals' or some other system level concept?  A
> conception which will accomplish the desired result without hogging so
> much memory.

Well, these files live on the disk where space costs about 1 cents per k
(say a 40meg disk for $500).
Such system level structures would have to live in memory, which costs
about 50 cents per k (say a 1meg sim for $500).

After the support code for keeping these structures around, you might
be approaching 1k anyway.  Besides, IPC is optional in the svid :-)/2.

I think everyone will agree on not having these things as 'system level
concepts'.  The kernel is bloated enough already.

Now that I think about it, where would you put the TZ info if not in /etc/TZ
(you could just have it as a line in /etc/profile (instead of having
/etc/profile run /etc/TZ), but TZ is easier to edit)?  Would this have
to go into the battery backup memory like the clock?  Not exactly portable.

Excuse my bitching, but let's not try to turn UNIX into THE GREAT OPERATING
SYSTEM FROM OUTER SPACE.  Its main attraction is the simplicity of the kernel
(though it's getting a little un-simple these days) and the ease of changing
such things as how to store the timezone and create lock files for UUCP
(which, BTW, is just a plain old application, not part of the "system").
-- 
Name:			Christopher J. Calabrese
Brain loaned to:	AT&T Bell Laboratories, Murray Hill, NJ
att!ulysses!cjc		cjc at ulysses.att.com
Obligatory Quote:	``Now, where DID I put that bagel?''



More information about the Comp.unix.wizards mailing list