-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/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 c
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.
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 de
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 noticea
Miles Bader 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 debian-deve
Thomas Goirand 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 temp
On Tue, 2012-05-29 at 12:15 +0800, Thomas Goirand wrote:
> What's the folder structure in /tmp then? /tmp//$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 uncharact
]] Thomas Goirand
> What's the folder structure in /tmp then? /tmp//$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 UNSUBSCR
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 p
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, s
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
[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 T
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 wa
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
b
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 „multi-use
* Ben Hutchings [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 persistent
data tha
+++ 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 .ta
+++ 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/ for every page/image. To open an image-heavy
> >256Mb .ppt I have lying a
On Mon, 2012-05-28 at 10:40 +1000, Russell Coker wrote:
> On Mon, 28 May 2012, Thomas Goirand 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
On Mon, 28 May 2012, Thomas Goirand 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 script foo
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 s
On Sun, May 27, 2012 at 4:43 PM, 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
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
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 wheth
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 fo
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
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
> >b
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, b
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 UNSUBSC
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 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
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 dire
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/ for every page/image. To open an image-heavy
> 256Mb .ppt I have lying about here, generates 382MB of file
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.
On Sun, 27 May 2012, Iustin Pop 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
filesystem for /tmp
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 syst
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
> 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 deb
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
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 machin
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
>
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
On Fri, 25 May 2012 15:25:58 +0300
Serge 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 resource
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
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 doe
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.
> 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
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
> 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 t
On Fri, 25 May 2012 02:22:24 +0300
Serge 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 of the time when
51 matches
Mail list logo
