On Mon, 28 May 2012 13:03:47 +0200 Toni Mueller <t...@debian.org> wrote: > It's not, see below. Also, most of the time, /tmp goes into / (on > smaller systems), and is thus typically *very* much limited in space.
If the theory is to design for the "trained chicken" install (and it still is, right?), then / gets the entire disk minus whatever gets assigned to swap. The sort of administrator who knows why she would want /home, /usr, and /var mounted separately can also be trusted to do whatever the right thing for her situation is with /tmp. HOWEVER, what's currently missing is the ability in the installer to put /tmp on / (AFAICT). Giving it a partition puts it on disk, not doing anything puts it on tmpfs. Yes, it's a single-line change to fstab on your first boot, but still. Over the past decade or so of writing one-off scripts I have (rightly or wrongly) formed the habit that /tmp is a 1777 area of disk where I can dump large things I don't want in memory at the moment (and therefore also a poor man's very asynchronous IPC domain -- yes, it's not supposed to be, but I think we'll also all admit we've done that at some point). Much better developers than me seem to have formed this opinion too (cf browsers' behavior while it waits for you to tell it what to do with an unknown content-type: it's a disk-based pipe to whatever program you pick to open it, except now it's a memory-based pipe, and I think /tmp on tmpfs is breaking those developers' expectations). We may be wrong, but apparently a lot of us don't yet trust the swapping algorithm to put the right stuff on disk yet. Also, I'd be more comfortable with tmpfs if it could be quota'd with standard quota tools. > Having /var/run on a tmpfs may be a good idea, though. Gah! I want *somewhere* I can park stuff on disk. Why are people so against that? Can we at least keep /var/tmp? (But I'm more worried about /var filling up than /, personally.) And how many of these are we going to do? Right now on my Squeeze laptop I have /lib/init/rw, /dev/shm, and /tmp. Do we really need more things that look like on-disk directories but aren't? (Then again I'm still grumpy about sysfs.) Though actually /var/run makes more sense than /tmp, since it's pretty much just for pids and sockets. > > I request that the bug be tagged wontfix. Despite what I said above, I agree. The argument about web applications' session info is persuasive, and that's probably the hardest set of apps to change. As long as we are sure programs aren't dropping arbitrarily large files into it (I'm looking at you, Iceweasel...) and as long as there's *some* section of actual disk somewhere that's 1777. Also, this is rapidly approaching two sets of choir-preaching, so I'll bow out after this. Cheers, Weldon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528082652.f9a53baa.wel...@b.rontosaur.us
