I'm going to chime in once to add my thoughts... It's already way too
late for me to influence the decision (first I heard of it is "it's
decided") so my only recourse is to add it to the long list of things
I have to "undo" after installing Fedora.
> Sorry guys, this feature sucks.
+1 on this feature sucks. Perhaps not for the same reasons. It's
mostly for this one:
> And how is a random user supposed to know this?
I think any time we make a fundamental change without making the user
aware of this change and CHOOSING it, we have failed the user. How to
fix this? I don't know, but perhaps...
* Install should ask the user what they want. Since /tmp needs to be
set up early, it needs to be done in initrd anyway.
* some post-install GUI/TUI that says "the following systematic
changes are now available, please decide if you want them"
* other ideas
A note from the "About Fedora" web page:
"We also believe in empowering others to . . ."
These choices are being made without "empowering the users" at all,
since the changes happen without warning them, advising them, or
letting them choose beforehand. IMHO this is the wrong way to do it.
It seems to me this is part of a larger pattern: Fedora (or upstream)
announces that some major change has been decided. There is a heated
debate over whether it was a good idea or not. Nothing changes. Is
this the new Fedora process? Force change on users then ignore their
complaints? That seems to be my Fedora-user experience.
Also, anyone who says "they should read the documentation" is
delusional. They don't read it.
> So everyone needs to go out and buy twice as much RAM so F18+ can
> run /tmp as tmpfs without causing memory shortfalls for everything
> else they do.
My system is already maxxed out on RAM, I can't buy any more, and
*yes* I need that RAM to be process RAM:
total used free shared buffers cached
Mem: 24739484 19815180 4924304 0 4600752 1428024
-/+ buffers/cache: 13786404 10953080
Swap: 2056312 816072 1240240
> With /tmp in RAM, it's not flushed at _boot_, but at _shutdown_
Losing /tmp on system crashes makes it harder to diagnose them, if
there's information in /tmp relevent to the crash. There have been
*lots* of time I've gone digging through /tmp looking for some interim
file that turned out to be not so temporary.
> Just add the space that you would have used for /tmp to your swap.
My /tmp (/) is 1.2TB (It will be 3TB after this weekend's upgrade).
It's unrealistic to add that much swap. Yes, I've had times when I
need lots of /tmp space, and I don't want to flush my I/O buffers or
running programs to get it. I/O buffers are more important to me than
/tmp speed.
Has anyone even compared the performance of tmpfs-on-swap vs
tmp-on-ext? I'm contemplating *removing* my swap because the system
slows to a crawl anytime swap is needed. If tmp is on swap, how is
process performance affected?
> The *default* limit for tmpfs is half of physical RAM
I.e. the default limit on tmpfs is to make half your RAM unavailable
to programs and buffers. Given how bloated software is becoming
(Fedora is no exception), this is a step backwards.
In conclusion, /tmp on tmpfs is a non-starter for me, and will be
changed on my systems as soon as possible.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
