On Sat, May 26, 2012 at 10:59:06PM -0400, Joey Hess wrote:
> Adam Borowski wrote:
> > I think that box had jfs, but other filesystems are no different: for
> > example, ext* will fsync() during a rename() call behind your back even if
> > you don't request it, forcing every file to hit the disk pla
Your message dated Sun, 27 May 2012 10:28:03 +0200
with message-id <201205271028.04412.hol...@layer-acht.org>
and subject line Re: Bug#674662: general: While closing the Run Command
application in kde desktop, its shadow remains after its closed.
has caused the Debian Bug report #674662,
regarding
On Sun, May 27, 2012 at 05:21:04AM +0300, Serge wrote:
> 2012/5/27 Adam Borowski wrote:
>
> > I think that box had jfs, but other filesystems are no different: for
> > example, ext* will fsync() during a rename() call behind your back even
> > if you don't request it, forcing every file to hit the
On Sat, 26 May 2012, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > In fact it is the other way. We have /var/tmp for the large file since
> > about forever, and important platforms that have /tmp in memory since the
> > early 2000's (Solaris)
> >
> > And that STILL wasn't enough f
On 05/27/2012 02:55 AM, Mike Hommey wrote:
> I hope it isn't, because it's poor "security". It's easy to read the
> file from /proc/$pid/fd/$num
>
> Mike
>
If you were to trust Adobe in terms of security, then you'd be the first
person I know to do so.
Jokes set apart, I believe that they just
On 05/27/2012 02:35 AM, François Bottin wrote:
> My point is that I can't stand that the major point to not use tmpfs
> is caused by a closed source software. If you think it is faulty, then
> do not use it!
> By the way, I can't reproduce your problem. That's probably due to the
> fact that there
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
On Sat, 26 May 2012, Carlos Alberto Lopez Perez wrote:
> So please, don't argue about theoretical things about virtual memory or
> IO schedulers. If you are a desktop Linux user, you should know how ugly
> the things get when the system is swapping.
Mine is not that annoying, but certainly not bec
On Sun, May 27, 2012 at 2:42 AM, olivier sallou
wrote:
>
> Le 27 mai 2012 03:12, "Jon Bernard" a écrit :
>
>
>>
>> * Charles Plessy wrote:
>> > Hello everybody,
>> >
>> > for one of the packages maintained by the pkg-eucalyptus team
>> > (euca2ools), the
>> > upstream source moved to GitHub, and
On 05/27/2012 04:32 AM, Russ Allbery wrote:
> The root problem here is that we have multiple parameters that we want to
> set on temporary storage:
>
> 1. Space for dumping arbitrary files without assuming anything about the
>structure of the user's home directory.
>
> 2. Fast space for small t
On 05/27/2012 04:32 AM, Russ Allbery wrote:
> In an ideal world, in which we could throw out all of UNIX history and
> make up our own rules, 1 (alone) would be /var/tmp, 2 would be some new
> path (/run/tmp or something), and 3 would be /tmp. But we don't live in
> the world where it's likely we
On 05/27/2012 08:09 PM, Henrique de Moraes Holschuh wrote:
> But my point was that people will not switch to writing small temporary
> files somewhere else, because they have not switched to writing files to
> $TMPDIR even after 10 years.
>
Please define who are the people you are talking about.
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 05/25/2012 05:41 PM, Josselin Mouette wrote:
> Le vendredi 25 mai 2012 à 11:04 +0200, Salvo Tomaselli a écrit :
>
>> Apparently not everybody has experienced that, and this would explain why
>> they
>> are so happy about the idea of paging out a couple of Gigabytes.
>>
> Because pagin
On 05/25/2012 03:29 PM, Josselin Mouette wrote:
> Which means a *huge* performance
> improvement. Do the measurements yourself, it works with basically
> anything that makes heavy use of /tmp.
>
I have yet to know what application you are talking about.
Who's doing heavy use of /tmp exactly?
Th
On 27/05/12 14:53, Thomas Goirand wrote:
> On 05/25/2012 03:29 PM, Josselin Mouette wrote:
>> Which means a *huge* performance
>> improvement. Do the measurements yourself, it works with basically
>> anything that makes heavy use of /tmp.
>>
> I have yet to know what application you are talking
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 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 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/25/2012 07:44 PM, Roger Leigh wrote:
> However, the majority of
> software which finds the tmpfs too small has unreasonable expectations
> of what can be expected to be available (by default).
>
We welcome you to rewrite / patch these software then!
Good luck, the list is huge, and growing
On 05/26/2012 03:12 AM, Nikolaus Rath wrote:
> Aren't quotas only for non-root and per file system? I think we're
> already safe from non-root filling up / because of the reserved 5%.
>
> Best,
>
>-Nikolaus
>
That's a bit off-topic but...
XFS has project quota, which are directory based. I'd
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 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 UNSUBSC
On 05/27/2012 02:42 PM, olivier sallou wrote:
> Keeping an updated mirror is not a good method for me, it is a painful
> task and you are never sure of the status
Isn't it possible to keep this repo up-to-date using
some of the git hooks? Like, when you push to your
repo on Alioth, it would aut
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
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
Joey Hess dixit:
>If programs that write large files to /tmp are changed to usr /var/tmp,
>then over time a system will accumulate orphaned large tmp files in
>/var/tmp. Nothing will come along and clean them up.
This is indeed a valid point. But that’s no regression; /tmp has
always been for sma
Charles Plessy dixit:
>upstream source moved to GitHub, and we would like to try to maintain the
>Debian package there as well.
This is not a good idea: http://mako.cc/writing/hill-free_tools.html
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when
> Please define who are the people you are talking about. If they aren't
> using mktemp, please file a bug.
man 3 mktemp
BUGS
Never use mktemp() [...]
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contac
> This is indeed a valid point. But that’s no regression; /tmp has
> always been for small short-lived files, and /var/tmp for those
> that are not one of them or not both.
You just made up this difference.
Nothing nowhere says anything about the size of the files. The only thing
mentioned is th
On 27/05/12 20:01, Thorsten Glaser wrote:
> This is indeed a valid point. But that’s no regression; /tmp has
> always been for small short-lived files, and /var/tmp for those
> that are not one of them or not both.
I am still waiting for someone to tell me where is said that /tmp should
be for sma
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
Salvo Tomaselli dixit:
>> Please define who are the people you are talking about. If they aren't
>> using mktemp, please file a bug.
>
>man 3 mktemp
>BUGS
> Never use mktemp() [...]
Your manpage search order is (also) wrong:
‣ https://www.mirbsd.org/man.cgi?mktemp
(1) come before (3) secti
On 05/28/2012 02:08 AM, Salvo Tomaselli wrote:
> man 3 mktemp
>
I was talking about /bin/mktemp.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc28113.20
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 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
On Sat, May 26, 2012 at 09:11:40PM -0400, Jon Bernard wrote:
> I believe a Github pull-request must reference a commit within Github itself.
> You could still file an issue linking to an external repository, but I suspect
> they're encouraging you to use Github for packaging so they can leverage al
]] Thomas Goirand
> Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much,
> then later applications can slowly use it if they want. Worst case:
> not a lot of app uses it, and the /run/tmp tmpfs isn't used much,
> which isn't a problem. Best case: everyone that needs a fast space
2012/5/27 Adam Borowski wrote:
> First, you're benchmarking the speed of process creation, not of file
> operations. Starting up seq or mv takes ages compared to an in-memory
> file write.
They may be slower than in-memory operations, but they're definitely
faster than fsync(). So if there was f
On Sat, May 26, 2012 at 04:39:34PM -0400, Joey Hess wrote:
> Roger Leigh wrote:
> > I did want to have this for wheezy (#633299). But I lacked the time
> > and familiarity with the d-i code, and the d-i developers also have
> > higher priorities.
>
> Personally, this d-i developer has as one prio
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
* Package name: sugar-toolkit-gtk3
Version : 0.96.1
Upstream Author : Sugar Labs
* URL : http://wiki.sugarlabs.org/go/Sugar
* License : GPL-2+
Programming Lang: Python
Description : GTK3-based Su
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
* Thomas Goirand [Sun May 27, 2012 at 11:52:27PM +0800]:
> On 05/27/2012 02:42 PM, olivier sallou wrote:
> > Keeping an updated mirror is not a good method for me, it is a painful
> > task and you are never sure of the status
> Isn't it possible to keep this repo up-to-date using
> some of th
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
On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
> On 05/25/2012 07:44 PM, Roger Leigh wrote:
> > However, the majority of
> > software which finds the tmpfs too small has unreasonable expectations
> > of what can be expected to be available (by default).
> >
> We welcome you to r
On Sun, May 27, 2012 at 10:01:22PM +0200, Tollef Fog Heen wrote:
> ]] Thomas Goirand
>
> > Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much,
> > then later applications can slowly use it if they want. Worst case:
> > not a lot of app uses it, and the /run/tmp tmpfs isn't used
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
2012/5/28 Roger Leigh wrote:
> The primary cause of problems is simply that the tmpfs /tmp isn't big
> enough. [...] what guarantees are offered by the system in terms of
> minimum and maximum available space on /tmp? [...] Consider the default:
> /tmp is on the rootfs (which [...] may have lots o
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
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
Hello Michael,
First of all, I want to seize this opportunity to congratulate you about
Phoronix and all the work you do helping all the Linux community with
the nice benchmarks that you publish.
In the last days there is a growing flame on debian-devel mailing list
about if "tmpfs for /tmp" is a
On 05/28/2012 05:32 AM, Roger Leigh wrote:
> On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
>> On 05/25/2012 07:44 PM, Roger Leigh wrote:
>>> However, the majority of
>>> software which finds the tmpfs too small has unreasonable expectations
>>> of what can be expected to be availa
+++ 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
+++ 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
Salvo Tomaselli writes:
>> This is indeed a valid point. But that’s no regression; /tmp has
>> always been for small short-lived files, and /var/tmp for those
>> that are not one of them or not both.
>
> You just made up this difference.
No he didn't, it's common practice from unix-days-of-yore (
56 matches
Mail list logo
