[HEADS-UP] Rawhide: /tmp is now on tmpfs
simo at redhat.com
Fri Jun 1 19:28:57 UTC 2012
On Fri, 2012-06-01 at 11:56 -0700, Adam Williamson wrote:
> On Fri, 2012-06-01 at 14:46 -0400, DJ Delorie wrote:
> > IMHO *telling* the user how to manage /tmp is wrong, whichever side of
> > the argument you're on. *Asking* them how to manage it is the right
> > way. That was my point in that mail.
> > *I* want /tmp on disk. I still don't want someone else telling me I
> > have to do it that way.
> You are entirely free to configure it through /etc/fstab. But to say
> that 'the system' should ask 'the user' to make every major config
> choice for it is just untenable and absurd.
Ok, say I have installed my new laptop and discover that the new /tmp
arrangement is not good for me and I'd rather keep /tmp on disk, how do
you go about that ? (No I do not have any un-partitioned space left, and
using the root file system is fine by me)
> Yes, it's 'just' another checkbox in the installer. Feel free to join
> #anaconda and see how easy it is to keep track of the seventy zillion
> checkboxes (i.e. codepaths) we currently have in the installer when
> trying to redesign it in a way that makes any goddamn sense.
I think the question here is can someone please point to a page with
numbers that justify /tmp -> tmpfs be the default for the most common
laptop / vm with limited RAM.
> Philosophically: the whole _job_ of a distribution is to make choices
> for 'the user'. That's what we do. We look at the bewildering array of
> choices you can make in deploying a bunch of bits to a system in order
> to be able to actually use it, and make lots of those choices, so that
> people can go ahead and stick a disc in a drive and click a few buttons
> and get a working system, instead of spending three weeks researching
> what a tmpfs even _is_.
Absolutely correct, but there should be some good rationale when a
change impact decades of use and habit and has the potential of breaking
> Let's make some logical extensions of your position. When I start
> installing Fedora, it should ask me whether I want to install grub,
> grub2, or lilo. Then ask me what framebuffer mode and console font I'd
> like to use. Then it should probably ask me whether to use udev or a
> static /dev tree. Then it could maybe ask what system initialization
> daemon it should use, systemd or upstart. Then ask whether we want to
> use dpkg or rpm, and access a different repository accordingly. Then we
> could get into the real meaty stuff, like do I want ash or bash. Do I
> want chronyd or ntpd.
> It's just freaking absurd. Our job is to deploy a cohesive system - i.e.
> to make choices about basic system design. Not to create a giant
> choose-your-own-adventure interface to encapsulate all the possible
> options of system configuration policy.
I totally agree here, we do not want to have this kind of choices, but
we want *safe* defaults.
The current /tmp setup is reasonably safe and fast enough for current
needs, the transition to tmpfs has the potential of breaking a lot of
stuff, so what is so good in tmpfs to warrant this big change ?
Where are the numbers ?
Simo Sorce * Red Hat, Inc * New York
More information about the devel