Subject: Re: Is gcc slow? Or is our gcc slow?
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Kevin P. Neal <kpneal@Interpath.com>
List: current-users
Date: 04/10/1996 21:14:55
At 07:35 AM 4/10/96 -0400, der Mouse wrote:
>> % Your definition of "sane" may vary; I usually allocate /tmp as MFS
>>   myself, and /var is usually 24M or more for a typical machine,
>
>But dumping those files into /var/tmp - indeed, even having /var/tmp on
>/var at all - has one major lose: it means that any person, or runaway
>program, can run you flat out of space on /var.  This then means that
>lots of things start breaking, and most of them can't log anything
>since their logfiles are normally on /var.
>

Didn't Robert Tappin Morris point this out to NSA people when he did his
security talks?

Simple: Fill up /var/tmp, and the system can't log your breakin.

>Personally, I (a) torch the clean-/tmp-on-reboot code in /etc/rc*, and
>(b) make /usr/tmp and /var/tmp symlinks to /tmp.  Oh, and (c) set up a
>cronjob to clean out /tmp periodically.

Hmmm, I'd be pretty upset if I was in the middle of something at some odd
hour, like high noon or 4 in the morning, and /tmp went away.

I wouldn't want /var/tmp/vi.recover to go away, that would be bad. I usually
make a separate partition for /var, and one for /var/tmp. No, it isn't the
most efficient use of drive space, but it means Joeuser@localhost can't
cut off my logging ability.

The NCSU machines have swap mounted on /tmp. They get cleaned when the user
logs out of the machine (single user per machine). Course, 
/var/spool/uucppublic doesn't get cleaned (heh heh heh), and neither does
/var/mail (c'mon, 8mb isn't enough quota, right?)
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \    kpneal@interpath.com
XCOMM  Frue, Secret Agent of Smerp (shh!)   \   kpneal@eos.ncsu.edu
XCOMM Visit the House of RetroComputing at  /      Perm. Email:
XCOMM  http://www4.ncsu.edu/~kpneal/www/   /    kevinneal@bix.com