-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Friday 25 May 2012 05:55 PM, Serge wrote:
So instead of fixing the defaults you suggest everybody to drop
the programs they use (mc, firefox, mysql)? ;)
I think I'll agree with you here. The current state seems to be broken.
Having tmpfs on
2012/5/28 Thomas Goirand wrote:
The truth is that tmpfs IS FASTER in some cases. The problem is that
*nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth.
You mean you know some real applications becoming noticeably
2012/5/27 Ben Hutchings wrote:
then /tmp using tmpfs *will* lead to issues that many wont understand.
As will /tmp on a small root partition.
As will a small dedicated /tmp partition.
True. But debian does not have small root partition *by default*. And it
does not install with a small
On 05/30/2012 10:07 AM, Serge wrote:
2012/5/28 Thomas Goirand wrote:
The truth is that tmpfs IS FASTER in some cases. The problem is that
*nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth.
You mean
2012/5/30 Thomas Goirand wrote:
You mean you know some real applications becoming noticeably faster
having /tmp on tmpfs?
No, I mean that writing nobody can notice that on real applications
is a bit too extreme, that's all I'm saying.
Right, sorry. Of course, I may be wrong, there can be
+++ Thorsten Glaser [2012-05-27 17:52 +]:
Wookey dixit:
here's a case where a lot of space gets used in there: open a .ppt
(powerpoint) file in libreoffice. The conversion involves writing a
file in /tmp/mktmpdir for every page/image. To open an image-heavy
256Mb .ppt I have lying
+++ Henrique de Moraes Holschuh [2012-05-27 11:04 -0300]:
On Sat, 26 May 2012, Salvo Tomaselli wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them.
You can't do it for a .tar.gz or a
* Ben Hutchings b...@decadent.org.uk [120527 17:25]:
Creating arbitrarily large temporary files outside the user's home
directory is generally going to be unreliable.
The only thing more unreliable than that is creating arbitrary large
file in user's home directory. If it is not supposed to be
On Mon, May 28, 2012 at 01:59:24AM +0100, Ben Hutchings wrote:
I don't recall that being common practice on any multi-user Unix-like
system I've used. (It's also not something a Windows user would expect,
Well, it was back in my university days, and it still is where I work.
Maybe
On 05/28/2012 04:46 AM, Serge wrote:
The truth is that tmpfs IS FASTER in some cases. The problem is that
*nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth. And by the way, that's not the issue. The issue is potential
On 28/05/12 17:48, Thomas Goirand wrote:
On 05/28/2012 04:46 AM, Serge wrote:
The truth is that tmpfs IS FASTER in some cases. The problem is that
*nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth. And by the way,
[Ben Hutchings]
We should be thinking about implementing per-user temporary directories
and making sure that programs respect $TMPDIR.
Yes, per-user temp directories is a good idea. Installing the
libpam-tmpdir package enable this by default, and beside some problems
with the root user (bad
On 05/28/2012 04:47 PM, Bernhard R. Link wrote:
I personally think having tmpdir on /tmp might be a good default for
new systems. If systems get changed to that from something else on
upgrade without asking, I consider that quite an ugly bug.
And you're not the only one. It seems that at
On 05/29/2012 03:13 AM, Petter Reinholdtsen wrote:
Perhaps it should be
extended to allow the directory to be below ~/ instead of below
/tmp/. :)
I don't think so. As other pointed out, your /home could be
remote (over NFS?), and then slow, while /tmp is normally
on your local machine, so
Package: libpam-tmpdir
Severity: wishlist
]] Petter Reinholdtsen
[Ben Hutchings]
We should be thinking about implementing per-user temporary directories
and making sure that programs respect $TMPDIR.
Yes, per-user temp directories is a good idea. Installing the
libpam-tmpdir package
]] Thomas Goirand
What's the folder structure in /tmp then? /tmp/something/$USER?
/tmp/user/$UID is the default. It can be overridden, but not in a
manner that's compatible with Petter's suggestion.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To
On Tue, 2012-05-29 at 12:15 +0800, Thomas Goirand wrote:
What's the folder structure in /tmp then? /tmp/something/$USER?
It's the Wild West over there. You'll often see something
like /tmp/$procname/$pid/blah or /tmp/$procname/$user/blah, or
just /tmp/$some_hash_of_who_knows_what/blah.
FHS is
Thomas Goirand z...@debian.org writes:
Perhaps it should be
extended to allow the directory to be below ~/ instead of below
/tmp/. :)
I don't think so. As other pointed out, your /home could be
remote (over NFS?), and then slow, while /tmp is normally
on your local machine, so moving the
Miles Bader mi...@gnu.org writes:
bazillion packages in debian that blithely cache vast quantities of
(often very uninteresting) data in random subdirs of $HOME... and then
Fortunately there is some movement towards the use of XDG_CACHE_DIR
(defaults to ~/.cache).
--
To UNSUBSCRIBE, email to
On Sun, May 27, 2012 at 05:39:21AM +0300, Serge wrote:
2012/5/25 Iustin Pop wrote:
And no, I really can't think of any popular application is not a valid
discussion point.
But there're already popular applications and usecases that break because
of that. It can render the system
On Sun, 27 May 2012, Iustin Pop ius...@debian.org wrote:
There's a difference between tmpfs is bad and the defaults for tmpfs
are bad.
The new defaults don't seem good when they are suddenly applied on upgrade.
My workstation unexpectedly went from having 2G of free space on the root
On Sat, 26 May 2012, Salvo Tomaselli wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them.
You can't do it for a .tar.gz or a .tar.bz and they are the most common kind
of archive.
Yes,
On 05/27/2012 01:59 AM, Wookey wrote:
here's a case where a lot of space gets used in there: open a .ppt
(powerpoint) file in libreoffice. The conversion involves writing a
file in /tmp/mktmpdir for every page/image. To open an image-heavy
256Mb .ppt I have lying about here, generates 382MB of
On 05/27/2012 02:52 AM, Mike Hommey wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them. There are even fuse filesystems to do that if it doesn't want to
do it itself. Using a temporary
On Sun, 2012-05-27 at 22:43 +0800, Thomas Goirand wrote:
On 05/27/2012 02:52 AM, Mike Hommey wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them. There are even fuse filesystems to do that
On 05/27/2012 09:38 PM, Russell Coker wrote:
Sure it's easy for me to fix that when upgrading and when compared to all the
other things I have to do on an upgrade it's not much of a big deal.
It's *not* easy, this involve init.d script foo ATM. See #674517.
Thomas
--
To UNSUBSCRIBE, email
On 05/27/2012 11:25 PM, Ben Hutchings wrote:
As will /tmp on a small root partition.
As will a small dedicated /tmp partition.
Why taking just bad configurations as counter arguments?
Do you know it is as well possible to have enough space
in your /tmp? :)
Cheers,
Thomas
--
To
Wookey dixit:
But there is this issue of the way its vfs does temporay unpacking in
/tmp. That makes sense in the 'this is temporary, it should go away on
reboot' sense, but some big files will use up a lot of ram when /tmp
is tmpfs.
I don't know what the right thing to do about this is, but
Thorsten Glaser wrote:
On 25/05/2012 18:20, Salvo Tomaselli wrote:
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
That doesn't seem to happen with file-roller. Perhaps you need to file a
bug
Hm. mc
On 27/05/12 17:47, Thomas Goirand wrote:
On 05/27/2012 11:25 PM, Ben Hutchings wrote:
As will /tmp on a small root partition.
As will a small dedicated /tmp partition.
Why taking just bad configurations as counter arguments?
Do you know it is as well possible to have enough space
in your
Ben Hutchings wrote:
As will /tmp on a small root partition.
As will a small dedicated /tmp partition.
The differences between these cases and forcing tmpfs by default is that
in the above cases, the person who installed the system chose those
partition sizes. They are therefore responsible for
On Sun, May 27, 2012 at 04:25:30PM +0100, Ben Hutchings wrote:
We should be thinking about implementing per-user temporary directories
and making sure that programs respect $TMPDIR. (On Linux it's also
possible to give each user a different /tmp through mount namespaces.
I'm not sure whether
2012/5/27 Iustin Pop wrote:
There's a difference between tmpfs is bad and the defaults for tmpfs
are bad.
First, I'm not saying that tmpfs is just bad. It's GOOD. For some cases.
I use it myself when I need to be sure that (having enough RAM) some of
my *large* files will never leave the cache
On Sun, May 27, 2012 at 4:43 PM, Thomas Goirand z...@debian.org wrote:
On 05/27/2012 02:52 AM, Mike Hommey wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them. There are even fuse filesystems
Salvo Tomaselli wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them.
You can't do it for a .tar.gz or a .tar.bz and they are the most common kind
of archive.
xz compression format supports
On Mon, 28 May 2012, Thomas Goirand z...@debian.org wrote:
On 05/27/2012 09:38 PM, Russell Coker wrote:
Sure it's easy for me to fix that when upgrading and when compared to all
the other things I have to do on an upgrade it's not much of a big deal.
It's *not* easy, this involve init.d
On Mon, 2012-05-28 at 10:40 +1000, Russell Coker wrote:
On Mon, 28 May 2012, Thomas Goirand z...@debian.org wrote:
On 05/27/2012 09:38 PM, Russell Coker wrote:
Sure it's easy for me to fix that when upgrading and when compared to all
the other things I have to do on an upgrade it's not
I hesitate to prolong this thread further, but I do have a couple of
data points. (and couldn't let Neil's nonsense go).
+++ Neil Williams [2012-05-25 16:15 +0100]:
So instead of fixing the defaults you suggest everybody to drop the
programs they use (mc, firefox, mysql)? ;)
On machines
On Sat, May 26, 2012 at 06:59:35PM +0100, Wookey wrote:
I hesitate to prolong this thread further, but I do have a couple of
data points. (and couldn't let Neil's nonsense go).
+++ Neil Williams [2012-05-25 16:15 +0100]:
So instead of fixing the defaults you suggest everybody to drop the
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them.
You can't do it for a .tar.gz or a .tar.bz and they are the most common kind
of archive.
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to
2012/5/25 Iustin Pop wrote:
And no, I really can't think of any popular application is not a valid
discussion point.
But there're already popular applications and usecases that break because
of that. It can render the system unstable because of heavy swap usage.
So there must be some strong
On Fri, 25 May 2012 02:22:24 +0300
Serge sergem...@gmail.com wrote:
What's a temporary file? Really, why would applications temporarily store
its data in a file? They do that to *free some memory*. Placing those files
back to memory renders the whole process of writing the file useless.
Most
It's beginning to sound like your particular machines need either more
RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with the same use case, I don't
know if it is the
Am 2012-05-25 11:19, schrieb Salvo Tomaselli:
It's beginning to sound like your particular machines need either
more
RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with
Doing that on inferior hardware is just plain stupid. If you have
plenty of
disk space, just unpack the tar archive.
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
And those with lots of RAM but not so
On 25/05/2012 18:20, Salvo Tomaselli wrote:
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
That doesn't seem to happen with file-roller. Perhaps you need to file a bug
with your graphical archiver program.
Chow Loong Jin dixit:
On 25/05/2012 18:20, Salvo Tomaselli wrote:
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
That doesn't seem to happen with file-roller. Perhaps you need to file a bug
Hm. mc does put
2012/5/25 Neil Williams wrote:
You cannot expect to mix those two worlds and for things to just
work.
Easy. Let's leave /tmp on a real disk and both world will just work.
If program A is too resource-hungry, find (or write) program B.
Or fix the program A, right? And here we go... By
On Fri, 25 May 2012 15:25:58 +0300
Serge sergem...@gmail.com wrote:
2012/5/25 Neil Williams wrote:
You cannot expect to mix those two worlds and for things to just
work.
Easy. Let's leave /tmp on a real disk and both world will just work.
Do you not use swap?
If program A is too
2012/5/25 Neil Williams wrote:
Do you not use swap?
I use it for suspend-to-disk.
Yes you lose functionality but functionality takes up resources, so
something has to give.
Which functionality will I lose by placing /tmp on the real disk?
The vast majority of systems have large amounts of
On Fri, May 25, 2012 at 08:14:10PM +0300, Serge wrote:
2012/5/25 Neil Williams wrote:
Different hardware - different software selection.
I don't understand your point. I could understand it if we were choosing
among benefits that most users get from /tmp being on disk and /tmp being
on
51 matches
Mail list logo
