On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
> On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
>> > but the short version would be "You can't make an omelette without
>> > breaking eggs"
>> Which explains little about your arguments (that's a general stanza)
> Well, so is yours, unless we are talking past each other. I was
> specifically addressing only that paragraph, out of context.
I didn't know you were interested in my arguments... they can be read
> It seems to me you are expecting specific arguments about the /tmp on
> tmpfs issue. As far as I recall you did read through the debian-devel
> discussion(s), what point is there for me to repeat it here (even if my
> memory is faulty and you did not read it)?
I read the thread it was mentioned when I first asked for feedback, which
But to be sincere, I don't remember "all" of the contents of the posts
nor "who" posted there "what"... and now you tell, I can't see any post
belonging to you in that thread. Maybe you made your comments afterwards?
>> >  except 42, of course
>> Sorry, I'm afraid I don't get that :-)
> http://en.wikipedia.org/wiki/42_(Hitchhiker%27s_Guide_to_the_Galaxy)#Answer_to_ the_Ultimate_Question_of_Life.2C_the_Universe.2C_a nd_Everything_.2842.29
Thanks, firt time I see. I didn't know about it...
>> Since when getting an "out of space" error message printed at your
>> screen and a faulty operation is something that can be considered "by
>> popular decision"? Of course not, so the own nature of the error is not
>> something I'd put inside a "feature" but more close to a "bug".
>> My strong technical reason is all but personal: I failed to uncompress
>> a simple tar.gz file by this "correct" default, I never had experienced
>> this problem before. Nothing personal at all ;-)
> You expected to be able to uncompress an archive of unspecified size to
> /tmp on a testing system.
It was just the kernel source (75 MiB). Wow. How. Big. >:-)
> 1. you may have had similar issues uncompressing that on any other
> filesystem (small partition, quota, etc.)
I doubt it becasue I tend to put special care for that can't happen (my netbook
has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and "/" (the
remaining space). Since I returned "/tmp" to the root filesystem I've had no
> 2. changes in behavior are to be expected on testing, otherwise one
> should stick with stable and carefully read the release notes before
Yup and I fully agree with you in this. That's why in my first post
("[Feedback needed] Setting the right size for /tmp") I asked for
"feedback" and I wasn't complaining at all for this setting.
> 3. there is still time to adjust the defaults before the release and the
> responsible maintainer even asked for feedback in this thread.
Yes! And I already wrote some things that we should care about for this
is introduced in Wheezy "smoothly".
> How else would you suggest this to be handled?
Glad you ask. I already mentioned some points here:
- The installer (at least in the "expert" flavour) allows the user to
enable/disable this and/or set a default sane value for the "tmpfs" size,
being automatically or manually set.
- The upgrade routine asks the user for this change so this is not being
applied silently but consciously.
- This new setting is documented in the Installation Guide so people can
be at least aware of this option, how can be configured, how can be
turned off, and some user-case examples so they can make their own
estimatations based on their system configuration and needs.
- A simple tweak for modifying this option once the system has been
installed (this is already done) and how it could be applied on the fly
without rebooting a running system.
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com